อัปเดตบอร์ดผ่านเน็ตแล้ว ถ้าของใหม่บูตไม่ขึ้นล่ะ

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

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

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

ต้องมีพื้นที่ให้รุ่นเดิมกับรุ่นใหม่อยู่ร่วมกัน

กลไก OTA ของ ESP-IDF ใช้ partition ของแอปและข้อมูลเลือกบูตตามการตั้งค่า สำหรับรูปแบบมาตรฐานต้องมีช่องแอป OTA อย่างน้อยสองช่องกับ OTA data เพื่อให้เขียนรุ่นใหม่ลงช่องที่ไม่ได้กำลังใช้งานอยู่ ก่อนเปลี่ยนไปบูตรุ่นนั้น

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

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

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

เปิด rollback แล้วต้องรู้ว่าระบบรออะไร

ESP-IDF มีตัวเลือก app rollback ที่ต้องเปิดและตั้งค่าให้เหมาะกับโปรเจกต์ กลไกนี้ไม่ได้เกิดขึ้นครบเองเพียงเพราะมีสองช่องแอป เมื่อเริ่มรุ่นใหม่ แอปต้องรู้สถานะของตัวเองและทำขั้นตรวจตามที่กำหนดก่อนยืนยันว่าใช้งานได้

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

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

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

กลับแอปเก่าแล้ว ข้อมูลยังอ่านได้หรือเปล่า

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

ก่อนเปลี่ยน schema จึงควรดูช่วงที่รุ่นเก่ากับรุ่นใหม่ต้องใช้ข้อมูลร่วมกัน อาจต้องรักษาความเข้ากันได้ แยกข้อมูลรุ่นใหม่ไว้ก่อน หรือออกแบบการย้ายที่ยังมีทางกู้ โดยไม่เขียนทับข้อมูลเดิมถาวรทันทีที่ยังอยู่ในช่วงทดสอบแอปใหม่

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

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

ทดลองเหตุขัดข้องกับเครื่องที่ยังเข้าถึงได้

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

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

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

ปล่อยทีละกลุ่มให้มีโอกาสเห็นปัญหา

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

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

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

สรุป

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