การบำรุงรักษาเฟิร์มแวร์ระยะยาวและการสนับสนุนการอัปเดต OTA สำหรับกล่อง Android TV แบบกำหนดเอง

Android TV Box แบบกำหนดเองอาจผ่านการตรวจสอบจากโรงงาน ให้การเล่น 4K ที่เสถียร และจัดส่งให้กับลูกค้าหลายพันรายได้สำเร็จ แต่ก็กลายเป็นเรื่องยากที่จะดูแลรักษาในอีกสองปีต่อมา สาเหตุเบื้องหลังมักเกี่ยวข้องกับซอฟต์แวร์: ผู้จำหน่าย SoC หยุดบำรุงรักษาแพ็คเกจสนับสนุนบอร์ด (BSP) โดยเฉพาะ ช่องโหว่ด้านความปลอดภัยจำเป็นต้องมีแพตช์ระดับแพลตฟอร์ม การอัปเดตแอปพลิเคชันจะเปลี่ยนการพึ่งพา API หรือการเปิดตัวเฟิร์มแวร์ทำให้เกิดความล้มเหลวในการบูตในการแก้ไขฮาร์ดแวร์เฉพาะ

สำหรับผู้ให้บริการโทรคมนาคม ผู้ให้บริการ IPTV แบรนด์การบริการ และผู้จัดจำหน่าย ความล้มเหลวเหล่านี้สร้างต้นทุนตลอดวงจรชีวิตผลิตภัณฑ์ทั้งหมด ช่างเทคนิคภาคสนามอาจจำเป็นต้องกู้คืนอุปกรณ์ด้วยตนเอง แอปพลิเคชันอาจหยุดทำงานอย่างถูกต้อง และแพลตฟอร์มฮาร์ดแวร์ที่ใช้งานอาจล้าสมัยในเชิงพาณิชย์ก่อนที่ส่วนประกอบทางกายภาพจะหมดอายุการใช้งาน

การบำรุงรักษาเฟิร์มแวร์ระยะยาวจึงเป็นข้อกำหนดทางวิศวกรรมและการจัดซื้อ ไม่ใช่แค่สัญญาว่าจะให้การอัปเดตซอฟต์แวร์เป็นครั้งคราว

SZTomato รองรับการพัฒนา OEM/ODM สำหรับ Android TV Boxes รวมถึงการปรับแต่งเฟิร์มแวร์ การปรับเปลี่ยนฮาร์ดแวร์ และการรวมซอฟต์แวร์ สำหรับผู้ซื้อเชิงพาณิชย์ วัตถุประสงค์คือเพื่อสร้างสถาปัตยกรรมผลิตภัณฑ์ที่สามารถบำรุงรักษาได้โดยมีความรับผิดชอบในการอัปเดตที่กำหนดไว้อย่างชัดเจน การกำหนดค่าฮาร์ดแวร์ที่รองรับ ขั้นตอนการกู้คืน และแผนวงจรการใช้งานที่สมจริง

1. สร้างแผนวงจรการใช้งานเฟิร์มแวร์ก่อนการผลิตจำนวนมาก

การตัดสินใจบำรุงรักษาเฟิร์มแวร์ที่สำคัญที่สุดจะต้องดำเนินการก่อนใบสั่งผลิตครั้งแรก: เลือกแพลตฟอร์มฮาร์ดแวร์และซอฟต์แวร์ที่มีเส้นทางการบำรุงรักษาที่น่าเชื่อถือ

ผลิตภัณฑ์ที่ใช้ Android ขึ้นอยู่กับหลายเลเยอร์ รวมถึงเฟรมเวิร์กแอปพลิเคชัน, โค้ด Android Open Source Project (AOSP), เคอร์เนล Linux, เลเยอร์นามธรรมของฮาร์ดแวร์, ไดรเวอร์อุปกรณ์ที่เป็นกรรมสิทธิ์ และส่วนประกอบของผู้จำหน่าย SoC แพตช์ที่มีอยู่ใน Android อัปสตรีมจะไม่กลายเป็นการอัปเดตที่ปรับใช้ได้โดยอัตโนมัติสำหรับ Android TV Box เชิงพาณิชย์ทุกเครื่อง

ชิปเซ็ต, เวอร์ชัน Android, BSP ของผู้จำหน่าย, ไลบรารีที่เป็นกรรมสิทธิ์, บูตโหลดเดอร์ และการกำหนดค่าบอร์ดที่เลือก จะกำหนดว่าการเปลี่ยนแปลงใดที่สามารถบูรณาการได้อย่างปลอดภัย

ประเมินการพึ่งพาการบำรุงรักษา SoC และ BSP

ในระหว่างการเลือกแพลตฟอร์ม ทีมจัดซื้อและวิศวกรควรจัดตั้ง:

• การสนับสนุนผู้จำหน่าย SoC: ยืนยันความพร้อมใช้งานของ BSP รุ่นต่างๆ การแก้ไขไดรเวอร์ การอัปเดตที่เกี่ยวข้องกับความปลอดภัย และเอกสารทางเทคนิคสำหรับชิปเซ็ตที่เลือก

• ความเข้ากันได้ของระบบปฏิบัติการ: ตรวจสอบว่า BSP ที่มีอยู่รองรับ Android เวอร์ชันใด และการอัพเกรดจะต้องใช้ไดรเวอร์หรือการเปลี่ยนแปลงแอปพลิเคชันจำนวนมากหรือไม่

• การบำรุงรักษาเคอร์เนล: ระบุสาขาเคอร์เนล Linux การแก้ไขผู้จำหน่ายที่เกี่ยวข้อง และกระบวนการในการรวมการแก้ไขอัปสตรีมที่เกี่ยวข้อง

• การพึ่งพาอุปกรณ์ต่อพ่วง: รองรับเอกสารสำหรับ Wi-Fi, บลูทูธ, อีเธอร์เน็ต, USB, เสียง, HDMI, รีโมทคอนโทรล และอินเทอร์เฟซเฉพาะโครงการ

• การขึ้นต่อกันของแอปพลิเคชัน: บันทึกเวอร์ชัน SDK ที่จำเป็น สิทธิ์ของระบบ บริการเบื้องหลัง และอินเทอร์เฟซมิดเดิลแวร์

• สร้างความสามารถในการทำซ้ำ: รักษาการแก้ไขซอร์ส การกำหนดค่าบิวด์ เวอร์ชันของ toolchain และบันทึกการพึ่งพาสำหรับอิมเมจเฟิร์มแวร์แต่ละอิมเมจที่เผยแพร่

ข้อกำหนดเหล่านี้มีความสำคัญอย่างยิ่งเมื่อผลิตภัณฑ์มีการกำหนดค่าหน่วยความจำหลายรายการหรือมีการแก้ไข PCBA อิมเมจเฟิร์มแวร์ที่ทำงานบนรุ่น RAM 4 GB พร้อมโมดูล Wi-Fi หนึ่งโมดูลอาจเข้ากันไม่ได้กับรุ่นที่ใช้พื้นที่จัดเก็บข้อมูล ฮาร์ดแวร์ไร้สาย หรือตัวควบคุมอุปกรณ์ต่อพ่วงที่แตกต่างกัน

ผู้ผลิตควรรักษาเมทริกซ์ความเข้ากันได้โดยระบุชุดการแก้ไขบอร์ด หน่วยความจำ โครงสร้างระบบปฏิบัติการ บูตโหลดเดอร์ และเวอร์ชันแอปพลิเคชันที่รองรับ

กำหนดความมุ่งมั่นในการบำรุงรักษาในแง่ที่สามารถวัดผลได้

คำมั่นสัญญาทั่วไปในการสนับสนุนระยะยาวไม่เพียงพอสำหรับสัญญาจัดซื้อจัดจ้างแบบ B2B

ข้อตกลงการบำรุงรักษาควรระบุระยะเวลาการสนับสนุนที่คาดหวัง ขอบเขตการอัปเดต กระบวนการรายงานข้อบกพร่อง จังหวะการเผยแพร่ เป้าหมายการตอบสนอง และความรับผิดชอบสำหรับซอฟต์แวร์ของบริษัทอื่น นอกจากนี้ยังควรแยกแยะระหว่างการแก้ไขด้านความปลอดภัย การปรับปรุงการทำงาน การอัปเดตความเข้ากันได้ และการอัพเกรดระบบปฏิบัติการหลัก

ตัวอย่างเช่น ผู้จำหน่ายฮาร์ดแวร์อาจสามารถรักษาเฟิร์มแวร์ที่ปรับแต่งเองบนเวอร์ชัน Android ที่มีอยู่ได้ ในขณะที่การอัพเกรดระบบปฏิบัติการหลักยังคงขึ้นอยู่กับความพร้อมใช้งาน BSP ของผู้จำหน่าย SoC สิ่งเหล่านี้เป็นข้อผูกพันทางวิศวกรรมที่แตกต่างกัน และควรได้รับการจัดสรรงบประมาณแยกต่างหาก

Android เผยแพร่การแก้ไขด้านความปลอดภัยผ่านกระดานข่าวความปลอดภัยของ Android อย่างเป็นทางการ ผู้ผลิตอุปกรณ์ยังต้องพิจารณาว่าการแก้ไขใดบ้างที่ใช้กับผลิตภัณฑ์ของตน และรวมการเปลี่ยนแปลงเฉพาะอัปสตรีม แพลตฟอร์ม Android เคอร์เนล และชิปเซ็ตที่เกี่ยวข้องไว้ในรุ่นที่ทดสอบแล้ว

แผนวงจรการใช้งานที่น่าเชื่อถือคำนึงถึงการพึ่งพาเหล่านี้ แทนที่จะคิดว่าแพตช์ Android ใหม่ทุกอันสามารถนำไปใช้ได้โดยไม่ต้องทำงานด้านวิศวกรรม

2. ออกแบบระบบอัปเดต OTA ที่ปลอดภัยสำหรับกลุ่มอุปกรณ์เชิงพาณิชย์

การอัปเดตแบบ over-the-air (OTA) ช่วยลดความจำเป็นในการให้บริการอุปกรณ์ทางกายภาพ แต่กลไกการอัปเดตเองอาจกลายเป็นจุดล้มเหลวได้หากความปลอดภัย ความน่าเชื่อถือในการจัดส่ง และการกู้คืนไม่ได้ออกแบบร่วมกัน

Android TV Box เชิงพาณิชย์ควรได้รับเฉพาะแพ็คเกจเฟิร์มแวร์ที่ได้รับอนุญาตซึ่งมีไว้สำหรับการกำหนดค่าฮาร์ดแวร์และซอฟต์แวร์เฉพาะเท่านั้น

ปกป้องการจัดส่งและการติดตั้งเฟิร์มแวร์

สถาปัตยกรรม OTA ที่มีการควบคุมควรมีการป้องกันหลายประการ

ความถูกต้องและความสมบูรณ์ของเฟิร์มแวร์: ใช้กระบวนการลงนามที่ปลอดภัยอย่างเหมาะสม และตรวจสอบแพ็คเกจการอัปเดตก่อนการติดตั้ง การเข้ารหัสการขนส่ง เช่น TLS ปกป้องการสื่อสาร แต่ไม่ได้แทนที่การตรวจสอบการเข้ารหัสของเฟิร์มแวร์เอง

การกำหนดเป้าหมายฮาร์ดแวร์และเวอร์ชัน: ตรวจสอบตัวระบุรุ่น การแก้ไขบอร์ด เวอร์ชันซอฟต์แวร์ปัจจุบัน และอัปเดตข้อกำหนดเบื้องต้นก่อนที่จะใช้แพ็คเกจ วิธีนี้จะป้องกันไม่ให้มีการติดตั้งอิมเมจเฟิร์มแวร์สำหรับอุปกรณ์รุ่นหนึ่งบนอุปกรณ์อีกรุ่นหนึ่ง

การจัดการการเผยแพร่ที่มีการควบคุม: แยกการพัฒนา การตรวจสอบความถูกต้อง โปรแกรมนำร่อง และรุ่นที่ใช้งานจริงออกจากกัน แต่ละรุ่นควรมีตัวระบุบิวด์ที่ไม่ซ้ำกันและสถานะการอนุมัติที่บันทึกไว้

อัปเดตการตรวจสอบสิทธิ์และการอนุญาต: จำกัดการเข้าถึงเพื่ออัปเดตโครงสร้างพื้นฐานและการควบคุมการเผยแพร่ ปกป้องคีย์การลงนาม กำหนดสิทธิ์การเข้าถึง และรักษาเส้นทางการตรวจสอบสำหรับรุ่นที่ใช้งานจริง

การรายงานความล้มเหลว: บันทึกความพยายามในการอัปเดต ผลลัพธ์การติดตั้ง หมวดหมู่ข้อผิดพลาด และสถานะการกู้คืน เพื่อให้ทีมบำรุงรักษาสามารถตรวจสอบความล้มเหลวทั่วทั้งฟลีต

การป้องกันเหล่านี้มีความสำคัญอย่างยิ่งสำหรับ IPTV และแอปพลิเคชันการบริการ ซึ่งอุปกรณ์อาจมีการกระจายข้ามภูมิภาค จัดการโดยทีมบริการที่แตกต่างกัน หรือเชื่อมต่อผ่านเครือข่ายที่มีแบนด์วิดท์และความพร้อมใช้งานไม่สอดคล้องกัน

ใช้การปรับใช้แบบเป็นขั้นและกลไกการกู้คืนที่ได้รับการตรวจสอบแล้ว

กระบวนการอัปเดตที่มีประสิทธิภาพไม่ควรส่งอิมเมจใหม่ทั้งหมดไปยังฟลีตทั้งหมดทันที

การเปิดตัวที่มีการควบคุมเริ่มต้นด้วยอุปกรณ์ทางวิศวกรรม ดำเนินการต่อไปยังกลุ่มนำร่องที่เป็นตัวแทน และขยายหลังจากการเปิดตัวผ่านการตรวจสอบที่กำหนดไว้ล่วงหน้าเท่านั้น การตรวจสอบควรครอบคลุมการอัปเดตเสร็จสิ้น ความสำเร็จในการบูต การเริ่มต้นแอปพลิเคชัน การเชื่อมต่อเครือข่าย และบริการหลักที่จำเป็นสำหรับการปรับใช้

ในกรณีที่แพลตฟอร์มรองรับ สถาปัตยกรรมการอัปเดตระบบ A/B จะสามารถติดตั้งอิมเมจระบบใหม่ในช่องที่ไม่ได้ใช้งาน ในขณะที่ยังคงรักษาอิมเมจก่อนหน้าไว้เพื่อการกู้คืน การใช้งานจะต้องจัดการกับการเลือกการบูต การตรวจสอบสภาพหลังการอัปเดต และพฤติกรรมทางเลือกอย่างถูกต้อง

ไม่ใช่ว่า Android TV Box ทุกตัวจะรองรับการอัปเดต A/B สำหรับแพลตฟอร์มที่ไม่มีความสามารถนี้ ผู้ผลิตจะต้องกำหนดกระบวนการกู้คืนทางเลือกโดยใช้พาร์ติชันการกู้คืนที่มีอยู่ ฟังก์ชันบูตโหลดเดอร์ หรือเครื่องมือบริการที่ได้รับอนุมัติ

การดาวน์โหลดที่ถูกขัดจังหวะ พื้นที่เก็บข้อมูลไม่เพียงพอ การสูญเสียพลังงาน แพ็คเกจที่ไม่ถูกต้อง และการอัปเดตที่เข้ากันไม่ได้ ควรได้รับการทดสอบโดยเจตนา การติดตั้งสำเร็จภายใต้สภาวะปกติไม่ใช่หลักฐานว่าอุปกรณ์จะกู้คืนจากความล้มเหลวได้

แผนการอัพเดตควรระบุว่าการย้อนกลับครอบคลุมเฉพาะเฟิร์มแวร์ระบบหรือรวมข้อมูลแอปพลิเคชันและการกำหนดค่าหรือไม่ การคืนค่าอิมเมจระบบปฏิบัติการจะไม่ย้อนกลับฐานข้อมูลที่เข้ากันไม่ได้หรือการเปลี่ยนแปลงข้อมูลแอปพลิเคชันโดยอัตโนมัติ

3. รักษาเฟิร์มแวร์ที่ปรับแต่งเองโดยไม่ทำให้ฮาร์ดแวร์หรือแอพพลิเคชั่นเสียหาย

ผลิตภัณฑ์ OEM/ODM มักจะมีการปรับเปลี่ยนเฉพาะลูกค้าซึ่งสร้างการพึ่งพาการบำรุงรักษาเพิ่มเติม สิ่งเหล่านี้อาจรวมถึงตัวเรียกใช้งานแบบกำหนดเอง มิดเดิลแวร์ที่เป็นกรรมสิทธิ์ ไดรเวอร์ต่อพ่วงเฉพาะทาง สิทธิ์ของระบบที่ปรับแต่งเอง และการผสานรวม SDK/API

การอัปเดตเฟิร์มแวร์อัปสตรีมอาจแก้ไขปัญหาด้านความปลอดภัยในขณะเดียวกันก็เปลี่ยนแปลงพฤติกรรมที่ลูกค้าต้องพึ่งพาด้วย การบำรุงรักษาระยะยาวจะต้องรักษาลักษณะการทำงานของแอปพลิเคชันที่ต้องการโดยไม่ปิดกั้นการปรับปรุงแพลตฟอร์มที่จำเป็น

รักษาสแต็กซอฟต์แวร์ Android/Linux ให้สมบูรณ์

การบำรุงรักษาเฟิร์มแวร์ควรจัดระเบียบตามเลเยอร์ซอฟต์แวร์ แทนที่จะถือเป็นงานเปลี่ยนรูปภาพงานเดียว

ในระดับแพลตฟอร์ม วิศวกรจะประเมินการเปลี่ยนแปลงเฟรมเวิร์ก Android ที่เกี่ยวข้อง การแก้ไขเคอร์เนล การแก้ไข BSP ของผู้จำหน่าย และส่วนประกอบที่เป็นกรรมสิทธิ์ ในระดับแอปพลิเคชัน จะตรวจสอบพฤติกรรมของตัวเรียกใช้งาน มิดเดิลแวร์ IPTV การตรวจสอบสิทธิ์ API การจัดการอุปกรณ์ และบริการเฉพาะลูกค้า

การเพิ่มประสิทธิภาพเคอร์เนลและไดรเวอร์อาจจำเป็นเมื่อแพลตฟอร์มพบกับความไม่เสถียรในการบูต แรงกดดันของหน่วยความจำ การตัดการเชื่อมต่อแบบไร้สาย ปัญหาการซิงโครไนซ์เสียง/วิดีโอ หรือปัญหาความเข้ากันได้ของอุปกรณ์ต่อพ่วง

อย่างไรก็ตาม ไม่ใช่ว่าทุกปัญหาจะต้องมีการแก้ไขเคอร์เนล ความล้มเหลวบางอย่างเกิดขึ้นในแอปพลิเคชัน ไฟล์การกำหนดค่า บริการกรอบงาน การตั้งค่าการจัดการพลังงาน หรือระบบภายนอก การระบุเลเยอร์ที่ถูกต้องจะช่วยลดการเปลี่ยนแปลงที่ไม่จำเป็นและจำกัดความเสี่ยงจากการถดถอย

กระบวนการเผยแพร่เฟิร์มแวร์ที่สามารถบำรุงรักษาได้ควรประกอบด้วย:

• พื้นที่เก็บข้อมูลซอร์สโค้ดที่มีการควบคุมและสภาพแวดล้อมการสร้าง

• บันทึกที่เป็นเอกสารของการแก้ไขเฉพาะลูกค้า

• ขั้นตอนการสร้างและแฟลชเฟิร์มแวร์ที่ทำซ้ำได้

• การทดสอบการถดถอยอัตโนมัติเมื่อเป็นไปได้

• รายการตรวจสอบการเผยแพร่ที่ครอบคลุมฟังก์ชันฮาร์ดแวร์และซอฟต์แวร์ที่สำคัญ

• อิมเมจการผลิตที่ทราบว่าใช้งานได้ดีและขั้นตอนการกู้คืนที่บันทึกไว้

สำหรับผลิตภัณฑ์ที่มีแบรนด์ ลูกค้าและผู้ผลิตควรตกลงอย่างชัดเจนเกี่ยวกับการเข้าถึงซอร์สโค้ด การลงนามความเป็นเจ้าของคีย์ การสร้างสิ่งประดิษฐ์ การดูแลเซิร์ฟเวอร์ OTA และความรับผิดชอบในการรักษาการบูรณาการที่เป็นกรรมสิทธิ์

รวมการเปลี่ยนแปลงฮาร์ดแวร์เข้ากับกระบวนการบำรุงรักษา

ไม่สามารถดูแลรักษาเฟิร์มแวร์แยกจากอุปกรณ์ทางกายภาพได้

การเปลี่ยนแปลงเค้าโครง PCBA, การกำหนดค่าหน่วยความจำ, โมดูล Wi-Fi, วงจรไฟฟ้า หรือตัวควบคุมอินเทอร์เฟซอาจจำเป็นต้องเปลี่ยนไดรเวอร์ การตั้งค่าแผนผังอุปกรณ์ใหม่ การกำหนดค่าเฟิร์มแวร์ที่แก้ไข หรือการทดสอบความเข้ากันได้เพิ่มเติม

ขอบเขตทางวิศวกรรม OEM/ODM ของ SZTomato อาจรวมถึงการดัดแปลงฮาร์ดแวร์ PCBA, เฟิร์มแวร์ Android/Linux ที่ปรับแต่งเอง, UI/UX แบบกำหนดเอง, การบูรณาการ SDK/API และการปรับฮาร์ดแวร์-ซอฟต์แวร์ตามความต้องการของโครงการ แพลตฟอร์มผลิตภัณฑ์ OEM/ODM ของ Android TV Box เป็นจุดเริ่มต้นสำหรับการอภิปรายเกี่ยวกับการปรับแต่งและการกำหนดค่า

สำหรับการใช้งานทางอุตสาหกรรมหรือการใช้งานต่อเนื่อง อาจจำเป็นต้องใช้โซลูชันการทำความเย็นแบบพิเศษด้วย การเปลี่ยนแปลงแผงระบายความร้อน การปรับเปลี่ยนกรอบ วัสดุเชื่อมต่อในการระบายความร้อน และการปรับการไหลเวียนของอากาศ อาจส่งผลต่ออุณหภูมิในการทำงานและพฤติกรรมของโปรเซสเซอร์

หลังจากเปลี่ยนฮาร์ดแวร์หรือเฟิร์มแวร์ที่เป็นวัสดุแล้ว ทีมงานควรทำการทดสอบการระบายความร้อน ความเสถียร อินเทอร์เฟซ และการเล่นที่เกี่ยวข้องซ้ำ ซึ่งจะช่วยระบุการถดถอยที่อาจไม่ปรากฏขึ้นระหว่างการตรวจสอบการเริ่มต้นซอฟต์แวร์ขั้นพื้นฐาน

ข้อกำหนดด้านการป้องกันเนื้อหาจำเป็นต้องได้รับการดูแลแยกต่างหากเช่นกัน การอัพเดตจะต้องรักษาการกำหนดค่า DRM และ HDCP ที่ได้รับการตรวจสอบตามความเหมาะสม แต่การบำรุงรักษาเฟิร์มแวร์เพียงอย่างเดียวไม่รับประกันการอนุญาตสำหรับบริการสตรีมมิ่งที่ได้รับใบอนุญาตหรือสร้างการปฏิบัติตามข้อกำหนดการรับรอง

4. สร้างรูปแบบการสนับสนุนวงจรชีวิตที่ปกป้องต้นทุนรวมในการเป็นเจ้าของ

การบำรุงรักษาเฟิร์มแวร์มีผลกระทบทางการค้าโดยตรง ต้นทุนการเป็นเจ้าของรวมมากกว่าราคาต่อหน่วยเริ่มต้น: ยังรวมถึงการเปลี่ยนแปลงทางวิศวกรรม การตรวจสอบกลุ่มยานพาหนะ การแก้ไขด้านความปลอดภัย แรงงานสนับสนุน การดำเนินการกู้คืน และค่าใช้จ่ายในการบำรุงรักษาผลิตภัณฑ์ที่หลากหลาย

รูปแบบการสนับสนุนที่กำหนดไว้อย่างดีทำให้คาดการณ์ต้นทุนเหล่านี้ได้ง่ายขึ้น

กำหนดบทบาทการสนับสนุนและระดับการให้บริการ

สำหรับโครงการ B2B ข้อตกลงการสนับสนุนเชิงปฏิบัติควรกล่าวถึงสี่ประเด็น

ความเป็นเจ้าของในการบำรุงรักษา: ระบุว่าใครเป็นผู้ดูแลการสร้างระบบปฏิบัติการ ส่วนประกอบเฉพาะ SoC แอปพลิเคชันของลูกค้า มิดเดิลแวร์ CMS หรือ IPTV และโครงสร้างพื้นฐาน OTA

การจำแนกข้อบกพร่อง: แยกปัญหาด้านความปลอดภัยที่สำคัญ ความล้มเหลวในการบล็อกการผลิต ข้อบกพร่องด้านการทำงานที่สำคัญ และคำขอการปรับปรุงที่มีลำดับความสำคัญต่ำกว่า แต่ละหมวดหมู่ควรมีกระบวนการตอบสนองที่กำหนดไว้

การกำกับดูแลการเผยแพร่: ตกลงเกี่ยวกับวิธีการทดสอบ อนุมัติ ใช้งาน จัดทำเอกสาร และเก็บรักษาเฟิร์มแวร์บิวด์ต่างๆ การเปลี่ยนแปลงการผลิตไม่ควรข้ามกระบวนการยอมรับที่ตกลงกันไว้

การวางแผนการสิ้นสุดอายุการใช้งาน: กำหนดสิ่งที่จะเกิดขึ้นเมื่อผู้จำหน่ายชิปเซ็ตหยุดจัดหาการอัปเดตที่จำเป็น ส่วนประกอบล้าสมัย หรือการอัปเกรดระบบปฏิบัติการหลักไม่สามารถใช้งานได้ในเชิงเศรษฐกิจอีกต่อไป

เป้าหมายการสนับสนุนควรเป็นจริง ความมุ่งมั่นที่จะรับทราบข้อบกพร่องภายในระยะเวลาที่กำหนดไม่เหมือนกับการรับประกันว่าการแก้ไขจะเสร็จสิ้นภายในระยะเวลานั้น โดยเฉพาะอย่างยิ่งเมื่อสาเหตุที่แท้จริงขึ้นอยู่กับการเปลี่ยนแปลง BSP ของบริษัทอื่นหรือซอฟต์แวร์ลิขสิทธิ์

วัดความน่าเชื่อถือด้วยข้อมูลการปฏิบัติงาน

กระบวนการบำรุงรักษาที่สมบูรณ์ควรใช้ตัวบ่งชี้ที่วัดได้เพื่อประเมินคุณภาพซอฟต์แวร์และอัปเดตประสิทธิภาพ

ตัวชี้วัดที่เป็นประโยชน์ ได้แก่ อัตราความสำเร็จของ OTA อัตราความล้มเหลวในการอัปเดต ความสำเร็จในการบูตหลังการอัปเดต ความถี่ที่แอปพลิเคชันขัดข้อง อัตราการกู้คืนอุปกรณ์ การเกิดข้อบกพร่องร้ายแรงซ้ำ และเปอร์เซ็นต์ของอุปกรณ์ที่ใช้เฟิร์มแวร์ที่ได้รับอนุมัติ

ตัวบ่งชี้เหล่านี้ควรแบ่งส่วนตามการแก้ไขฮาร์ดแวร์ เวอร์ชันเฟิร์มแวร์ ภูมิภาค และกลุ่มการใช้งาน ค่าเฉลี่ยทั่วทั้งกลุ่มยานพาหนะเดียวสามารถซ่อนปัญหาที่แยกได้จากการแก้ไข PCBA หรือส่วนประกอบไร้สายโดยเฉพาะ

ตัวอย่างเช่น หากความล้มเหลวในการอัปเดตเกิดขึ้นเฉพาะบนอุปกรณ์ที่มีพื้นที่เก็บข้อมูลว่างจำกัด การดำเนินการแก้ไขอาจเกี่ยวข้องกับการปรับขนาดแพ็คเกจ การจัดการพื้นที่เก็บข้อมูล หรือการตรวจสอบก่อนการติดตั้ง แทนที่จะออกแบบเฟิร์มแวร์ใหม่ทั้งหมด

ข้อมูลการปฏิบัติงานช่วยให้ทีมจัดซื้อประเมินประสิทธิผลของการสนับสนุนวงจรการใช้งาน และให้หลักฐานแก่ทีมวิศวกรในการจัดลำดับความสำคัญของงานบำรุงรักษา

สร้างแพลตฟอร์ม Android TV Box ที่สามารถบำรุงรักษาได้ด้วย SZTomato

การสนับสนุนเฟิร์มแวร์ระยะยาวเป็นการผสมผสานระหว่างฮาร์ดแวร์ ซอฟต์แวร์ และความรับผิดชอบในการปฏิบัติงาน ต้องใช้ SoC และ BSP ที่เหมาะสม การสร้างเฟิร์มแวร์ที่มีการควบคุม การส่งมอบ OTA ที่ปลอดภัย กลไกการกู้คืนที่ผ่านการทดสอบ การแก้ไขเฉพาะลูกค้าที่จัดทำเป็นเอกสาร และข้อตกลงการบำรุงรักษาที่สะท้อนถึงการพึ่งพาแพลตฟอร์มจริง

SZTomato ทำงานร่วมกับผู้ซื้อ B2B กล่องแอนดรอยด์ทีวี โครงการ OEM/ODM ที่เกี่ยวข้องกับการปรับแต่งฮาร์ดแวร์ การปรับเฟิร์มแวร์ UI/UX แบบกำหนดเอง การรวม SDK/API และวิศวกรรมเฉพาะแอปพลิเคชัน ขอบเขตการสนับสนุนที่เหมาะสมขึ้นอยู่กับชิปเซ็ตที่เลือก ทรัพยากรของผู้จำหน่ายที่มีอยู่ ข้อกำหนดซอฟต์แวร์ของลูกค้า และวงจรการใช้งานของผลิตภัณฑ์ที่ต้องการ

สำหรับผู้จัดการฝ่ายจัดซื้อ ผู้ดำเนินการโทรคมนาคม ผู้ให้บริการ IPTV และผู้วางระบบ ขั้นตอนต่อไปคือการกำหนดข้อกำหนดในการบำรุงรักษาควบคู่ไปกับข้อกำหนดของผลิตภัณฑ์ ระบุ SoC เป้าหมาย, เวอร์ชัน Android, การกำหนดค่า PCBA, แอปพลิเคชันที่จำเป็น, ความคาดหวังของ OTA, ขนาดการปรับใช้งาน และระยะเวลาการสนับสนุนที่ต้องการสำหรับการประเมินทางเทคนิคที่มีโครงสร้าง

เยี่ยมชม SZTomato เพื่อหารือเกี่ยวกับการปรับแต่งของคุณ กล่องแอนดรอยด์ทีวี ข้อกำหนดโครงการ OEM/ODM และวงจรการใช้งานเฟิร์มแวร์ กลยุทธ์การบำรุงรักษาที่กำหนดไว้ก่อนการผลิตจำนวนมากสามารถลดปัญหาความเข้ากันได้ที่หลีกเลี่ยงได้ ลดความซับซ้อนในการอัปเดตกลุ่มยานพาหนะ และทำให้แบรนด์ของคุณมีรากฐานที่แข็งแกร่งสำหรับการสนับสนุนผลิตภัณฑ์ในระยะยาว