อะไรคือผลกระทบทางประวัติศาสตร์ของเที่ยวบิน 501 ของ Ariane 5

การสลายตัวของจรวด Ariane 5 37 วินาทีหลังจากเปิดตัวครั้งแรกในการเดินทางครั้งแรกของเธอ ( เที่ยวบิน 501 ) โดยทั่วไปเรียกว่าหนึ่งในข้อบกพร่องซอฟต์แวร์ที่แพงที่สุดในประวัติศาสตร์¹ :

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

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

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

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

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

เราได้ใช้การวิเคราะห์แบบคงที่เพื่อ:

• ตรวจสอบการเริ่มต้นของตัวแปร
• จัดเตรียมรายการที่ละเอียดของข้อขัดแย้งการเข้าถึงข้อมูลที่อาจเกิดขึ้นสำหรับตัวแปรที่แชร์
• แสดงรายการข้อผิดพลาดรันไทม์ที่อาจเกิดขึ้นอย่างละเอียดจาก Ada semantics

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

ในทำนองเดียวกันกระดาษนี้^(PDF)บันทึก:

การวิเคราะห์โปรแกรมเชิงสถิตที่เป็นนามธรรมถูกนำมาใช้เพื่อการวิเคราะห์เชิงสถิตของซอฟต์แวร์ ADA แบบฝังของตัวเรียกใช้ Ariane 5 และ ARD ตัววิเคราะห์โปรแกรมแบบสแตติกมีจุดมุ่งหมายที่การตรวจจับอัตโนมัติของความเป็นไปได้, ศักยภาพ, ความเป็นไปไม่ได้หรือความไม่สามารถเข้าถึงได้ของข้อผิดพลาดรันไทม์เช่นเซนต์คิตส์และเนวิสจุดเหนือ โครงสร้างข้อมูลที่ใช้ร่วมกันเป็นต้นเครื่องวิเคราะห์สามารถค้นพบข้อผิดพลาด Ariane 501 โดยอัตโนมัติ การวิเคราะห์แบบคงที่ของซอฟต์แวร์สำคัญด้านความปลอดภัยในตัว (เช่นซอฟต์แวร์ avionic) มีแนวโน้มที่ดี

ฉันชอบคำอธิบายอย่างละเอียดถึงผลกระทบที่เหตุการณ์นี้มีต่อวิธีการทดสอบซอฟต์แวร์และเครื่องมือต่างๆ

_{¹ตัวเลข 7 พันล้านดอลลาร์อาจหมายถึงต้นทุนรวมของโครงการ Ariane 5 วิกิพีเดียรายงานว่าความล้มเหลวส่งผลให้สูญเสียเงินกว่า 370 ล้านดอลลาร์ ยังคงเป็นความล้มเหลวค่อนข้างแพง แต่ไม่มีที่ไหนใกล้กับตัวเลข $ 7 พันล้าน}

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

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

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

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

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

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

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

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

ส่วนใหญ่เป็นปัญหาการใช้ซ้ำและปัญหาการจัดการไม่ใช่การเข้ารหัส จากความทรงจำของฉัน (ฉันอาจได้รับบางสิ่งผิดปกติ) ของรายงาน

• ระบบย่อยหนึ่งระบบได้รับการออกแบบสำหรับ Ariane IV วิถีของ Ariane IV ไม่สามารถส่งผลให้เกิดการล้นและมันก็ตัดสินใจอย่างจงใจว่าถ้ามันเกิดขึ้นมันเป็นปัญหาฮาร์ดแวร์และการปิดระบบย่อยและไปอะไหล่เป็นสิ่งที่เหมาะสมที่จะทำ

• สำหรับ Ariane V นั้นมีการตัดสินใจที่จะนำระบบย่อยนั้นกลับมาใช้ใหม่และไม่ทบทวนสมมติฐานและรหัส แต่อาศัยการทดสอบ

• ต่อไปก็มีการตัดสินใจที่จะวางการทดสอบแบบเต็ม

พารามิเตอร์การบินที่แตกต่างกันของ Ariane V ทำให้เกิดการโอเวอร์โฟลว์ ปิดเครื่องหลัก ปิดอะไหล่ Autodestruction

สิ่งเพิ่มเติมที่ฉันจำได้:

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

• มีข้อมูลดีบักที่ส่งไปยังบัสเมื่อไม่ควร ฉันจำไม่ได้

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