- จากผลการวิเคราะห์เหตุการณ์ล่าสุดที่เกิดขึ้นกับ เครื่องบินตระกูล A320 พบว่า การแผ่รังสีจากดวงอาทิตย์ที่รุนแรง อาจทำให้ข้อมูลสำคัญที่จำเป็นต่อการควบคุมการบินเกิดความเสียหาย
- แอร์บัสจึงระบุว่า เครื่องบินตระกูล A320 ที่ยังปฏิบัติการอยู่จำนวนมาก อาจได้รับผลกระทบ
- บริษัทได้ออก Alert Operators Transmission (AOT) ร่วมกับ หน่วยงานการบิน เพื่อให้มีการดำเนินมาตรการป้องกันทันที โดยมีแนวโน้มให้ข้อกำหนดนี้ถูกนำไปบรรจุเป็น คำสั่งการรับรองความปลอดภัยการบินฉุกเฉิน (Emergency Airworthiness Directive) ของ EASA
- แอร์บัสยอมรับว่ามาตรการดังกล่าวอาจทำให้เกิดความล่าช้าหรือการรบกวนกำหนดการเดินทางของผู้โดยสารและลูกค้า และกำลังร่วมมืออย่างใกล้ชิดกับ สายการบิน เพื่อรับมือ
- ความสำคัญสูงสุดของมาตรการทั้งหมดคือ การรับประกันความปลอดภัยการบิน
ภาพรวมการดำเนินมาตรการเชิงป้องกันตระกูล A320
- จากการวิเคราะห์เหตุการณ์ล่าสุดที่เกี่ยวข้องกับ เครื่องบินตระกูล A320 พบว่า การแผ่รังสีดวงอาทิตย์ที่เข้มข้น (intense solar radiation) อาจทำให้ข้อมูลหลักที่จำเป็นสำหรับระบบควบคุมการบินเสียหายได้
- สภาพการณ์นี้อาจส่งผลต่อความสมบูรณ์ของข้อมูลที่จำเป็นสำหรับ การควบคุมการบิน (flight controls)
- แอร์บัสประเมินว่า เครื่องบินตระกูล A320 ที่ปฏิบัติการอยู่ขณะนี้จำนวนมาก อาจได้รับผลกระทบจากปัญหานี้
มาตรการป้องกันและความร่วมมือกับหน่วยงานกำกับดูแล
- แอร์บัสออก Alert Operators Transmission (AOT) เพื่อให้มีมาตรการป้องกันทันทีโดยร่วมมือกับ หน่วยงานการบิน
- AOT ระบุคำแนะนำในการใช้ มาตรการปกป้องซอฟต์แวร์และ/หรือฮาร์ดแวร์ เพื่อรับประกันความปลอดภัยในการปฏิบัติการเครื่องบิน
- มาตรการนี้คาดว่าจะถูกนำไปเป็นทางการเป็น คำสั่งการรับรองความปลอดภัยการบินฉุกเฉิน (Emergency Airworthiness Directive) ของ EASA
ผลกระทบต่อการเดินทางและการตอบสนอง
- แอร์บัสยอมรับว่ามาตรการนี้อาจทำให้เกิดความล่าช้าหรือการรบกวนการเดินทางของผู้โดยสารและลูกค้าได้บ้าง
- บริษัทจะร่วมมือกับ ผู้ให้บริการการบิน อย่างใกล้ชิดเพื่อสนับสนุนการปฏิบัติตามมาตรการ และ ยืนยันความปลอดภัยเป็นภารกิจสูงสุด
- แอร์บัสได้แสดงความขอโทษต่อความไม่สะดวกที่เกิดขึ้น
เอกสารที่เกี่ยวข้อง
- มีเอกสาร PDF ที่มีเนื้อหาเดียวกับข่าวประชาสัมพันธ์ขนาด 126.02 KB ให้ดาวน์โหลดได้
- ชื่อเอกสาร: Airbus update on A320 Family precautionary fleet action
- ลิงก์ดาวน์โหลดเผยแพร่บนเว็บไซต์ทางการ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อยากรู้จริง ๆ ว่าปัญหานี้ถูกพบใน ตระกูลไมโครคอนโทรลเลอร์ ใด
ถ้านี่เป็น safety processor ที่ใช้ lockstep, ECC ฯลฯ ก็แปลว่าเกิด bit flip ในระดับที่ ECC ตรวจไม่พบ
ถ้าเป็นข้อมูลเสียหาย ก็อาจไม่ใช่แค่การรีสตาร์ตธรรมดา แต่อาจเป็นกรณีที่หลายบิตในหนึ่ง word พลิกพร้อมกัน
ถ้าสภาพแวดล้อมไม่ได้ต่างไปเป็นพิเศษ ก็อาจเป็นไปได้ว่ามีการลดสิ่งอย่าง voltage margin ลง
อยากรู้เหมือนกันว่าเป็น NVM หรือ SRAM
มันไม่ใช่ MCU แต่เป็นระบบที่ประกอบจากหลายชิป และถูกออกแบบมาตั้งแต่ยุค 90 ก่อนจะมีฮาร์ดแวร์เวอร์ชันใหม่ที่เพิ่ม EDAC เข้ามาในปี 2002
ในสถานการณ์แบบนี้ bit flip ก็เกิดขึ้นได้มากพอสมควร
รายละเอียดอยู่ใน รายงาน ATSB
โดยเฉพาะแฟลชซีนอนเป็นปัญหา
ดูตัวอย่างได้จาก โพสต์ในฟอรัม, การถกเถียงเพิ่มเติม, บล็อกทางการ, วิดีโอบน YouTube
ดาวเทียมทำงานที่ระดับความสูงมากกว่า A320 มาก และส่วนใหญ่ใช้ Triple Modular Redundancy
ดู คำอธิบาย TMR, แนวคิด SEU
NASA เพิ่มค่า N เป็น 5 สำหรับการบินที่มีมนุษย์โดยสาร
ยังมีวิธีอย่างปิดแคชทั้งหมด หรือรีเฟรช ECC RAM อย่างต่อเนื่อง
และยังมีมาตรการฮาร์ดแวร์เพื่อป้องกัน latch-up ในวงจรดิจิทัล
ถ้าอยู่ในวงการคอมพิวเตอร์มานานพอ คุณจะเจอ เหตุการณ์ bit flip แบบนี้หลายครั้ง
ECC ช่วยได้ในเกือบทุกกรณี แต่บางครั้งซอฟต์แวร์ก็ถูกออกแบบให้ตรวจจับค่าแปลก ๆ แล้วเมินทิ้ง
ในระบบเรียลไทม์หรือระบบสำคัญต่อความปลอดภัย บางทีก็มีหลายระบบช่วยกัน โหวต เพื่อตรวจสอบความผิดพลาด
เคยต้องทรมานอยู่หลายเดือนเพราะ bit flip ใน cache line ของ CPU ช่วงยุค 90
ในบริการที่รองรับทราฟฟิกขนาดใหญ่ เราสรุปค่าที่เป็น enum แล้วพบค่าที่เป็นไปไม่ได้อยู่ไม่กี่ค่า
เมื่อเห็นว่าสตริงถูกบันทึกผิดไปแค่หนึ่งบิตพอดี ก็เลยเดาว่าอาจเป็นผลจาก รังสีคอสมิก
ทั้งที่จริง ๆ เป็นบั๊กที่ทำซ้ำได้ แต่กว่าจะยอมรับว่าเป็นความผิดตัวเอง ก็สงสัยไปหมดตั้งแต่เคอร์เนล ไดรเวอร์ ไปจนถึงไคลเอนต์
ถึงอย่างนั้นเขาก็เป็นอัจฉริยะ และสำหรับเหตุการณ์ A320 ครั้งนี้ เขาอาจจะพูดถูกจริง ๆ ก็ได้
The Aviation Herald มีรายละเอียดเชิงเทคนิคมากกว่า
“ช่องโหว่นี้ในกรณีเลวร้ายที่สุดอาจทำให้เกิด การเคลื่อนที่ของ elevator ที่ไม่ได้รับการควบคุม จนเกินขีดจำกัดโครงสร้างของอากาศยานได้”
วงการอากาศยานและอวกาศมี มาตรการรับมือ bit flip มานานแล้ว
การแก้ไขของ Airbus/Thales ครั้งนี้คือเพิ่มความเข้มงวดในการตรวจสอบข้อผิดพลาด และรีสตาร์ตคอมโพเนนต์ที่มีปัญหาโดยอัตโนมัติ
รายละเอียดอยู่ใน รายงาน BEA
มีกลิ่นอายแบบ BoFH อยู่เหมือนกัน
“เข้าทำงานเช้าวันศุกร์แต่เช้า โทรศัพท์ก็ดังขึ้น พอเปิดแผ่นชีตข้ออ้างดูก็เห็นคำว่า ‘solar flare’ จ้องกลับมา...”
ลิงก์
สงสัยว่าเหตุการณ์นี้ถูก วินิจฉัย อย่างไร
ไม่แน่ใจว่า FDR (เครื่องบันทึกข้อมูลการบิน) บันทึกข้อผิดพลาดระดับล่างไว้ด้วยหรือเก็บแค่ค่าป้อนเข้าระดับสูง
ถ้าเป็น bit flip จากรังสี เขารู้ได้อย่างไร?
หรืออาจมีการบันทึกสิ่งอย่าง ความผิดพลาดจากการโหวต ระหว่างคอมพิวเตอร์การบินหลักไว้ด้วยก็ได้
มี รายงาน postmortem ที่ยอดเยี่ยมเกี่ยวกับกรณี SEU (single-event upset) ที่คล้ายกัน
เป็นปฏิกิริยาแนวล้อว่า “บินเข้าใกล้ดวงอาทิตย์เกินไป”
สงสัยว่าจำเป็นต้อง หยุดบินทั้งฝูง เพราะเรื่องแบบนี้หรือไม่
ถ้าเป็นเหตุการณ์หนึ่งครั้งในรอบหลายปีจากเครื่องนับหมื่นลำ ก็น่าจะให้เวลาสักสองเดือนเพื่อแก้ไขได้ไม่ใช่หรือ
วิธีแก้คือดาวน์เกรด หรือเปลี่ยนกลับไปใช้ฮาร์ดแวร์เวอร์ชันก่อนหน้า
ในมุมของ Airbus ความเสียหายโดยตรงจากการหยุดบินอาจไม่มาก แต่ถ้าเกิดอุบัติเหตุขึ้นมา ความเสี่ยงด้านชื่อเสียงและคดีความจะสูงกว่ามาก
ทำนองว่า “เราแก้เชิงรุก แต่คู่แข่งรอให้เกิดอุบัติเหตุก่อนแล้วค่อยลงมือ”
ตามรายงานข่าว มาตรการครั้งนี้คือการ ย้อนกลับการอัปเดตซอฟต์แวร์
เลยสงสัยว่าเดิมทีอัปเดตนั้นมีเป้าหมายเพื่ออะไร และ ซอฟต์แวร์คอมพิวเตอร์การบินถูกอัปเดตบ่อยแค่ไหน