NASA สร้างคอมพิวเตอร์ทนความขัดข้องของ Artemis II อย่างไร

 (cacm.acm.org)
7 คะแนน โดย GN⁺ 19 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คอมพิวเตอร์การบินของ Orion ยานอวกาศพร้อมมนุษย์ไปดวงจันทร์ มีสถาปัตยกรรมที่ มีความยืดหยุ่นต่อความขัดข้องและความสามารถในการควบคุมอัตโนมัติสูงกว่าระบบในยุค Apollo อย่างมาก โดยจัดการฟังก์ชันสำคัญทั้งหมด เช่น ระบบยังชีพ พลังงาน และการสื่อสาร
  • เพื่อให้ทำงานได้ต่อเนื่องโดยไม่สะดุดแม้อยู่ห่างออกไป 250,000 ไมล์ในวงโคจรรอบดวงจันทร์ จึงออกแบบให้ทนต่อความผิดพลาดของฮาร์ดแวร์และผลกระทบจากรังสีผ่าน โครงสร้างซ้ำซ้อนทั้งทางกายภาพและตรรกะ รวมถึงคอมพิวเตอร์การบินหลายชุด
  • Flight Control Module(FCM) แต่ละตัวประกอบด้วยคู่หน่วยประมวลผลที่ตรวจสอบกันเอง ทำให้มี CPU ทั้งหมด 8 ตัวรันแบบขนาน และใช้ การออกแบบแบบ fail-silent กับอัลกอริทึมเลือกเอาต์พุตตามลำดับความสำคัญ เพื่อแยกความผิดพลาดออกจากระบบ
  • ระบบรักษาสถานะซิงก์สมบูรณ์ผ่าน time-triggered Ethernet และสถาปัตยกรรมแบบ deterministic พร้อมแก้ไขข้อผิดพลาดระดับบิตเดี่ยวโดยอัตโนมัติด้วยเครือข่ายและหน่วยความจำแบบสามชุดซ้ำซ้อน
  • หากระบบหลักล้มเหลวทั้งหมด Backup Flight Software ที่ใช้ฮาร์ดแวร์และระบบปฏิบัติการอิสระจะเข้ารับการควบคุมแทน ซึ่งโครงสร้างนี้ถูกมองว่าเป็นต้นแบบของ โมเดลความยืดหยุ่นแบบ always-on สำหรับระบบอัตโนมัติในอนาคต

การออกแบบคอมพิวเตอร์ทนความขัดข้องของ NASA สำหรับ Artemis II

  • คอมพิวเตอร์การบินของ Artemis II มีสถาปัตยกรรมที่มีความยืดหยุ่นต่อความขัดข้องและความสามารถในการควบคุมอัตโนมัติสูงกว่าคอมพิวเตอร์นำร่องในยุค Apollo อย่างมาก
    • คอมพิวเตอร์ Apollo ใช้โปรเซสเซอร์ 1MHz และหน่วยความจำราว 4KB โดยการควบคุมหลักอาศัยสวิตช์แบบแมนนวลหรือรีเลย์เป็นหลัก
    • แคปซูล Orion ของ Artemis II ให้คอมพิวเตอร์จัดการฟังก์ชันสำคัญทั้งหมดโดยตรง เช่น ระบบยังชีพ พลังงาน และการสื่อสาร
  • เนื่องจากความล้มเหลวของภารกิจในระยะ 250,000 ไมล์จากโลกใกล้วงโคจรดวงจันทร์แทบไม่อาจกู้คืนได้ ระบบจึงต้องทำงานต่อเนื่องแม้เผชิญ รังสีอวกาศ บิตพลิก และความขัดข้องของฮาร์ดแวร์
    • NASA เตรียมรับมือความผิดพลาดของฮาร์ดแวร์ด้วยการเดินสายซ้ำซ้อนทางกายภาพ ระนาบเครือข่ายที่ซ้ำซ้อนทางตรรกะ และคอมพิวเตอร์การบินหลายชุด

  • พลังของแปด

    • Orion ใช้โครงสร้างที่ก้าวไปไกลกว่า triple redundancy แบบเดิม
      • ใน Vehicle Management Computer(VMC) สองเครื่อง แต่ละเครื่องติดตั้ง Flight Control Module(FCM) สองตัว รวมเป็น 4 FCM
      • FCM แต่ละตัวประกอบด้วยคู่โปรเซสเซอร์แบบ self-checking ทำให้มี CPU รวม 8 ตัวที่รันซอฟต์แวร์การบินแบบขนาน
    • ระบบยึดตามการออกแบบแบบ fail-silent โดยเมื่อ CPU เกิดข้อผิดพลาด จะไม่ส่งเอาต์พุตที่ผิดพลาดออกมา แต่จะเปลี่ยนเข้าสู่สถานะเงียบทันที
    • แทนที่จะใช้การโหวตเสียงข้างมาก ระบบใช้อัลกอริทึม เลือกแหล่งสัญญาณตามลำดับความสำคัญ เพื่อเลือกเอาต์พุตจากช่องทางที่ยังปกติ
    • NASA คาดว่าจะเกิดข้อผิดพลาดชั่วคราวระหว่างการผ่านแถบรังสี Van Allen และแม้จะสูญเสีย FCM ไป 3 ตัวได้นานสูงสุด 22 วินาที ก็ยังดำเนินภารกิจต่อด้วย FCM ตัวสุดท้ายได้
    • FCM ที่เข้าสู่สถานะเงียบสามารถรีเซ็ต แล้วซิงก์กับโมดูลอื่นเพื่อกลับเข้าร่วมการทำงานระหว่างบินได้อีกครั้ง

  • การรักษาการทำงานแบบ deterministic

    • เพื่อให้คอมพิวเตอร์อิสระหลายชุดคงสถานะซิงก์สมบูรณ์แบบ lockstep ได้ จึงใช้ สถาปัตยกรรมแบบ deterministic
    • Orion ใช้เครือข่าย time-triggered Ethernet เพื่อกระจายเวลาให้ทั้งระบบ
      • ซอฟต์แวร์การบินทำงานภายใน major frame และ minor frame ที่จัดการโดยตัวจัดตาราง ARINC653
      • การแบ่งเวลาและพื้นที่ทำให้มั่นใจได้ว่าอินพุตและเอาต์พุตจะตรงกับตารางเครือข่ายอย่างสมบูรณ์
    • FCM แต่ละตัวรับอินพุตเดียวกัน รันโค้ดเดียวกัน และสร้างเอาต์พุตเดียวกัน
    • ทุก ๆ วินาที ระบบจะวัด clock drift ของ FCM แล้วปรับเทียบใหม่ตามเวลามาตรฐานของเครือข่าย
    • แอปพลิเคชันที่ไม่สามารถทำงานทัน deadline จะถูกเปลี่ยนเข้าสู่สถานะเงียบโดยอัตโนมัติ ก่อนทำการซิงก์ใหม่
    • ฮาร์ดแวร์ใช้ หน่วยความจำแบบ Triple Modular Redundancy(TMR) เพื่อแก้ไขข้อผิดพลาดระดับบิตเดี่ยวโดยอัตโนมัติ ขณะที่การ์ดเชื่อมต่อเครือข่ายก็เปรียบเทียบ เส้นทางทราฟฟิกคู่ เพื่อจัดการแบบ fail-silent เมื่อเกิดข้อผิดพลาด
    • เครือข่ายถูกทำซ้ำซ้อนเป็นสามระนาบอิสระ และสวิตช์ทุกตัวมีความสามารถ self-checking ในตัว

  • ระบบสำรองขั้นสุดท้าย

    • NASA เตรียมรับมือ common mode failure ที่อาจกระทบทุกช่องทางหลักพร้อมกัน
    • เพื่อการนี้จึงติดตั้งระบบ Backup Flight Software(BFS) แยกต่างหาก
      • BFS ประกอบด้วยฮาร์ดแวร์คนละชุด ระบบปฏิบัติการอีกแบบหนึ่ง และซอฟต์แวร์การบินเวอร์ชันเรียบง่ายที่พัฒนาอย่างอิสระ
      • หากระบบหลักล้มเหลว BFS จะเข้ารับการควบคุมโดยอัตโนมัติเพื่อทำช่วงการบินที่เป็นไดนามิกของภารกิจให้เสร็จสิ้นได้
      • หลังจากนั้นลูกเรือยังสามารถพยายามกู้คืน FCM หลักได้
    • แม้ ตรรกะแบบ fail-silent จะเป็นสิ่งจำเป็น แต่ก็ต้องมี watchdog timer และการมอนิเตอร์หลายชั้น ควบคู่กันไป เพื่อไม่ให้ความผิดพลาดคงอยู่โดยไม่ถูกตรวจพบ
    • ระบบยังถูกออกแบบให้อยู่รอดได้แม้เกิดการสูญเสียไฟฟ้าทั้งหมด (“dead bus”)
      • เมื่อพลังงานกลับมา ระบบจะเข้าสู่ safe mode โดยอัตโนมัติ
      • จากนั้นจะหันแผงโซลาร์เข้าหาดวงอาทิตย์เพื่อฟื้นกำลังไฟ และจัดท่ายานให้ส่วนท้ายหันเข้าหาดวงอาทิตย์เพื่อรักษาเสถียรภาพด้านความร้อน
      • หลังจากนั้นจะพยายามสถาปนาการสื่อสารกับโลกอีกครั้ง และหากจำเป็น ลูกเรือสามารถปรับระบบยังชีพด้วยตนเองได้

  • อนาคตของความเชื่อถือได้

    • การเปลี่ยนผ่านจาก Apollo สู่ Artemis หมายถึง การเพิ่มขึ้นแบบก้าวกระโดดของความซับซ้อนด้านซอฟต์แวร์
      • Apollo ยังมีระบบสำรองเชิงกล แต่ใน Artemis ซอฟต์แวร์รับหน้าที่ควบคุมทั้งหมด
    • NASA ใช้เวิร์กโฟลว์การตรวจสอบสมัยใหม่ที่รวมถึง การจำลองทุกสภาพแวดล้อม การทดสอบความเครียดแบบ Monte Carlo และ fault injection ขนาดใหญ่
      • โดยใช้ซูเปอร์คอมพิวเตอร์จำลองไทม์ไลน์การบินทั้งหมด และตรวจสอบว่าซอฟต์แวร์จะกู้คืนแบบ fail-silent ได้หรือไม่แม้เกิดความขัดข้องของฮาร์ดแวร์
    • สถาปัตยกรรม zero-tolerance ของ Orion ถูกประเมินว่าเป็นต้นแบบของ ความยืดหยุ่นแบบ always-on ที่สามารถนำไปใช้กับ รถยนต์ไร้คนขับและเครือข่ายควบคุมอุตสาหกรรม ในอนาคตได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 19 일 전
ความคิดเห็นจาก Hacker News

  • ตั้งแต่ปี 1989 ถึง 1995 เคยทำงานที่ Stratus เกี่ยวกับ VOS และประสิทธิภาพของฐานข้อมูล
    Stratus เป็นบริษัทที่ทำระบบ ทนต่อความขัดข้อง (fault-tolerant) แบบฮาร์ดแวร์ ส่วนคู่แข่งอย่าง Tandem ใช้แนวทางแบบซอฟต์แวร์
    สถาปัตยกรรมของ Stratus เป็นแบบ “pair and spare” โดยบอร์ดทุกใบมีการทำซ้ำ และมีการเปรียบเทียบเอาต์พุตของทุกพินในทุก tick
    ตอนย้ายจาก Motorola 68K ไปเป็น Intel ทีมฮาร์ดแวร์เจอปัญหาหนัก เพราะพินที่ไม่ได้ใช้งานของบางคำสั่งลอยค่า

  • ประโยคที่นักวิจัยจาก CMU พูดว่า “Agile และ DevOps ทำให้วินัยด้านสถาปัตยกรรมอ่อนแอลง” น่าประทับใจมาก
    ดูเหมือนทุกวันนี้เราจะลืมไปแล้วว่าจะสร้าง ระบบเชิงกำหนดแน่นอน (deterministic systems) อย่างไร
    การจัดตารางเฟรมอย่างเข้มงวดของ Time-triggered Ethernet ให้ความรู้สึกเหมือนเป็นคนละโลกกับแนวทางพัฒนาซอฟต์แวร์ในปัจจุบัน

    • ยังมีคนที่ต้องทำงานกับระบบฝังตัวที่ต้องการ การรับประกันแบบเรียลไทม์
      แนวปฏิบัติการพัฒนาสมัยใหม่บางอย่าง เช่น unit test, CI ฯลฯ ก็ยังส่งผลดีในสภาพแวดล้อมแบบนี้
    • ในยุค Apollo การคำนวณเชิงกำหนดแน่นอนที่อิงกับ WCET (เวลาในการรันสูงสุด) เป็นกระแสหลัก เพราะมีเงินวิจัยจากกลาโหมหนุนหลัง
      ตอนนี้โลกเปลี่ยนไปเป็นตลาดเชิงพาณิชย์เป็นหลัก เงินลงทุนลดลง แต่ก็ยังมีอัลกอริทึมที่น่าสนใจอยู่มาก
      งานวิจัยของ Frank Mueller หรือ Johann Blieberger น่าจะเป็นแหล่งอ้างอิงที่ดี
    • Time-triggered Ethernet เป็นส่วนหนึ่งของดาต้าบัสสำหรับการรับรองอากาศยาน โดย INRIA และ Airbus เคยทำวิจัยด้านนี้
      ในสภาพแวดล้อมอย่างเครื่องบินที่อินพุตและเอาต์พุตมีขอบเขตจำกัด การออกแบบแบบเชิงกำหนดแน่นอนเข้ากันได้อย่างสมบูรณ์
      ในทางปฏิบัติมันใกล้เคียงกับ บัสฮาร์ดแวร์เฉพาะทาง มากกว่าจะเป็น Ethernet จริง ๆ
    • ได้ยินมาว่า Tesla Cybertruck ก็ใช้แนวทางนี้กับ Ethernet เช่นกัน
    • เขาน่าจะหมายถึง SpaceWire มากกว่า

  • พอเห็น ชาเลนจ์ ‘radiation hardening’ ของ Code Golf ก็สงสัยว่าวิธีแบบนี้จะใช้งานได้จริงไหม
    ในโลกจริงคงยาก เพราะมีปัญหาซ้อนกันหลายชั้นเกินไป แต่ก็ยังคิดว่าเป็นไอเดียที่น่าสนใจ

  • แนวทางการออกแบบแบบ “fail-silent” ที่อธิบายในบทความน่าสนใจมาก
    แต่ก็สงสัยว่าถ้า CPU สองตัวคำนวณผิดพร้อมกัน แล้วได้ผลลัพธ์ตรงกัน จะตรวจจับได้อย่างไร

    • โอกาสที่ข้อผิดพลาดบิตเดียวจากรังสีจะเกิดพร้อมกันใน CPU ทั้งสองตัวนั้น ต่ำมากอย่างยิ่ง
    • CPU พวกนี้ทำงานแบบ lockstep คือประมวลผลชุดคำสั่งเดียวกันพร้อมกัน แล้วเทียบผลลัพธ์กัน
      ความน่าจะเป็นที่ CPU สองตัวจะผิดแบบเดียวกันพร้อมกัน ต่ำกว่า FIT ของ CPU เดี่ยวมาก
    • โอกาสที่ CPU สองตัวจะมีบิตเดียวกันถูกพลิกพร้อมกัน ยังต่ำกว่าความน่าจะเป็นของ ดาวเคราะห์น้อยชน เสียอีก
      แต่ในอวกาศ กฎของ Murphy มักทำงานเสมอ ก็เลยพูดแบบฟันธงไม่ได้
    • จริง ๆ แล้วแม้แต่ระบบโหวตเสียงข้างมากแบบ 3 ชุด ถ้า CPU สองตัวผิดแบบเดียวกันก็เจอปัญหาเดียวกัน
    • ถ้าระบบ 1 และ 2 ผิดพร้อมกัน และอีก 6 ระบบที่เหลือปกติ
      ผลลัพธ์ที่ผิดก็อาจถูกเลือกด้วย “เสียงข้างมาก 25%” ได้

  • อยากรู้รายละเอียดเชิงลึกของระบบนี้ เช่น CPU, RAM, OS, ภาษา ที่ใช้
    และอยากรู้ด้วยว่า FCM เข้าสู่สถานะ “fail-silent” บ่อยแค่ไหน

    • NASA cFS เขียนด้วยภาษา C และเปิดเผยไว้บน GitHub
      โดยปกติจะทำงานบน FreeRTOS หรือ RTEMS
      ส่วนตัวรู้สึกว่าโครงสร้างโปรเจกต์ซับซ้อนเกินไปจนจัดการลำบาก
    • BFS ใช้ cFS และดูได้จาก วิดีโอบน YouTube
      โค้ดหลักของ NASA ส่วนใหญ่ไม่เปิดเผย แต่ cFS เป็นแหล่งเรียนรู้ที่ดีสำหรับ การออกแบบซอฟต์แวร์การบินแบบดั้งเดิม

  • บทความไม่ได้ลงรายละเอียดเรื่อง RTOS และสถาปัตยกรรม ที่ใช้งานจริง
    ระบบควบคุมการบินหลักของ Orion เป็นโครงสร้างทำซ้ำ 4 ชุด บน Green Hills INTEGRITY RTOS และโปรเซสเซอร์ BAE RAD750
    ส่วน BFS ทำงานบนฮาร์ดแวร์ LEON3 + VxWorks ที่ต่างออกไปโดยสิ้นเชิง และใช้ เฟรมเวิร์ก cFS ของ NASA
    นี่คือ สถาปัตยกรรมแบบโมดูลาร์ที่นำกลับมาใช้ซ้ำได้ ซึ่งถูกใช้กับกล้องโทรทรรศน์ James Webb และ Mars Rover ด้วย
    โครงสร้างแบบนี้ไม่ใช่แค่ “ระบบหลัก + ระบบสำรอง” อย่างง่าย แต่เป็นแนวคิด dissimilar redundancy
    รายละเอียดเพิ่มเติมดูได้ใน เอกสารเทคนิคของ NASA 1, เอกสาร 2

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

  • การสร้างจริงเป็นหน้าที่ของ Lockheed Martin และผู้รับเหมาช่วง
    การที่สื่อเขียนเหมือน NASA สร้างเองทั้งหมดทำให้เข้าใจผิดได้

    • คิดว่า Lockheed คงไม่ได้สร้าง ระบบ PowerPC แบบทำซ้ำ 4 ชุด ราคาแพงแบบนี้ขึ้นมาเองโดยไม่มีคำขอจาก NASA
    • BFS นั้นส่วนใหญ่พัฒนาภายใน NASA (จากคำบอกเล่าของเพื่อนที่มีส่วนร่วมโดยตรง)
    • ในความเป็นจริง น่าจะเป็น ความร่วมมืออย่างใกล้ชิด ระหว่าง NASA กับ Lockheed
    • ยังมีมุก “ลองนึกถึง megacorp ดูสิ” โผล่มาด้วย

  • ตอนเป็นนักพัฒนาเว็บเมื่อ 25 ปีก่อน เคยถามเพื่อนที่เคยทำงานกับ NASA ว่า “จัดการบั๊กกันยังไง”
    เขาหัวเราะแล้วตอบว่า “ไม่มีบั๊ก”
    นักพัฒนาทุกวันนี้คุ้นเคยกับสภาพแวดล้อมที่ความล้มเหลวไม่ได้แลกด้วยชีวิตคน

    • แต่ละอุตสาหกรรมมีมาตรฐานคำว่า “ดีพอ” ไม่เหมือนกัน
      บริการเว็บอาจเสียแค่รายได้ แต่ยานอวกาศนั้นมี ชีวิตคน เป็นเดิมพัน

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

    • สมัยกระสวยอวกาศ มีการติดตั้งคอมพิวเตอร์ 5 เครื่องไว้ต่างตำแหน่งและต่างทิศทางกัน
      เพื่อทำ hardening ทางกายภาพด้วยการ กระจาย cross-section ของการชนจากรังสี

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