คุณจัดการกับการชุบแข็งในอวกาศหรือไม่?

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

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

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

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

นอกจากนี้หากคณะกรรมการรักษาระบบที่สำคัญบางคำเตือนก่อนดูเหมือนยิ่ง

เราจะได้รับประสบการณ์นี้ได้อย่างไรจากการทดสอบและทดลองใช้ & ข้อผิดพลาด (ยกเว้นการเปิดตัวดาวเทียมส่วนตัวของคุณเอง)

ซอฟต์แวร์ Space ไม่ใช่เวทมนต์แบบอาร์เคน คุณยังคงใช้งาน 0 และ 1 ไม่ใช่ไม่ใช่ 1 และ 3 ดังนั้นอาจไม่มีปัจจัยที่เกี่ยวข้องในการอธิบายสิ่งที่จะพัฒนาซอฟต์แวร์

ความแตกต่างเล็กน้อยที่เกิดขึ้นในใจในขณะนี้คือ:

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

ฉันเพิ่งพบคำถามที่น่าสนใจของคุณ

ฉันอยู่ที่ Instrumentation Lab ระหว่างอพอลโลและอีกครั้งในภายหลังเมื่อมันถูกเรียกว่าเดรเปอร์แลปในช่วง "สงครามเย็น"

สำหรับคอมพิวเตอร์แนะนำอพอลโลแกนถูกนำมาใช้สำหรับ RAM และแกนถักแบบพิเศษถูกใช้สำหรับ ROM ตัวเครื่องทำมาจากประตู NOR ทั้งหมดและติดตั้งค่อนข้างช้าเพื่อความน่าเชื่อถือ

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

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

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

MISRA-C: กลุ่มย่อย C ของยานยนต์ เล็กน้อยเช่น Ravenscar ADA / Java

watchdogs: ตรวจสอบให้แน่ใจว่าโปรแกรมไม่ล็อค

หน่วยความจำ ecc (บางครั้ง)

checksums: กำลังมองหาการพลิกบิต ฉันเห็นทั้งสามสิ่งนี้ในระบบเดียว:

1) ตรวจสอบโปรแกรมอย่างต่อเนื่อง (อยู่ใน EPROM แต่ยังมีบิตพลิก)

2) ตรวจสอบโครงสร้างข้อมูลบางอย่างเป็นระยะ

3) ซีพียูสติตรวจสอบเป็นระยะ

4) ตรวจสอบการลงทะเบียน IO มีสิ่งที่พวกเขาควรจะมีในพวกเขา

4b) อ่านเอาต์พุตย้อนกลับไปยังอินพุตอิสระและตรวจสอบ

สิ่งที่สำคัญกว่าภาษาโปรแกรมคือข้อกำหนดของระบบพื้นฐาน (ระบบปฏิบัติการและฮาร์ดแวร์) โดยทั่วไปคุณต้องมั่นใจ (และพิสูจน์) พฤติกรรมที่กำหนดและคาดการณ์ได้ของระบบโดยรวม มีการวิจัยที่เกี่ยวข้องจำนวนมากในชุมชนเรียลไทม์ ผมขอแนะนำให้อ่านหนังสือสองเล่มถ้าคุณอยากที่จะศึกษาเรื่องนี้: ระบบ Real-Timeโดยเจนหลิวและหนังสือที่มีชื่อเดียวกันโดยแฮร์มันน์โคเปตซ์ อดีตครอบคลุมการจัดตารางเวลาในรูปแบบเชิงทฤษฎีอย่างมากในขณะที่หลังได้รับเท้าของคุณบนพื้นและสวยมากครอบคลุมทุกด้านที่เกี่ยวข้องของการออกแบบระบบ (เรียลไทม์) เช่นความอดทนความผิด

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

• Ariane 5 (นำซอฟต์แวร์ที่พิสูจน์แล้วกลับมาใช้ใหม่ภายใต้ข้อ จำกัด ที่แตกต่างกัน)
• รีบูตเครื่องนำทาง Mars Rover (ลำดับความสำคัญผกผัน)

ผมพบว่าเอกสารนี้ (ประมาณ 2009) สำหรับJPL สถาบันการเข้ารหัสมาตรฐานสำหรับเขียนโปรแกรมภาษา Cในห้องปฏิบัติการที่เชื่อถือได้ซอฟแวร์ (ลาร์ส) ที่ Jet Propulsion Laboratoryเว็บไซต์

นี่คือบทสรุปของกฎที่บันทึกไว้:

1. การปฏิบัติตามภาษา

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

2. การดำเนินการที่คาดการณ์ได้

   • ใช้ขอบเขตลูปที่ตรวจสอบได้สำหรับลูปทั้งหมดที่ตั้งใจจะยกเลิก
   • อย่าใช้การเรียกซ้ำโดยตรงหรือโดยอ้อม
   • อย่าใช้การจัดสรรหน่วยความจำแบบไดนามิกหลังจากเริ่มต้นงาน
   • * ใช้ข้อความ IPC สำหรับการสื่อสารงาน
   • อย่าใช้ความล่าช้างานสำหรับการประสานงาน
   • * ถ่ายโอนสิทธิ์การเขียน (ความเป็นเจ้าของ) อย่างชัดแจ้งสำหรับวัตถุข้อมูลที่ใช้ร่วมกัน
   • วางข้อ จำกัด เกี่ยวกับการใช้เซมาฟอร์และล็อค
   • ใช้การป้องกันหน่วยความจำระยะความปลอดภัยรูปแบบของสิ่งกีดขวาง
   • อย่าใช้ goto, setjmp หรือ longjmp
   • อย่าใช้การกำหนดค่าที่เลือกให้กับองค์ประกอบของรายการ enum

3. การป้องกันการเข้ารหัส

   • ประกาศวัตถุข้อมูลในขอบเขตที่เล็กที่สุดเท่าที่จะเป็นไปได้
   • ตรวจสอบค่าส่งคืนของฟังก์ชั่นที่ไม่เป็นโมฆะหรือส่งไปที่ (void) อย่างชัดเจน
   • ตรวจสอบความถูกต้องของค่าที่ส่งผ่านไปยังฟังก์ชั่น
   • ใช้การยืนยันแบบคงที่และแบบไดนามิกเป็นการตรวจสอบสติ
   • * ใช้ U32, I16 ฯลฯ แทนประเภทข้อมูล C ที่กำหนดไว้ล่วงหน้าเช่น int, short, ฯลฯ
   • ทำให้ลำดับของการประเมินผลในนิพจน์ผสมชัดเจน
   • อย่าใช้นิพจน์ที่มีผลข้างเคียง

4. ความชัดเจนของรหัส

   • ใช้ตัวประมวลผลล่วงหน้า C อย่าง จำกัด มากเท่านั้น
   • อย่ากำหนดมาโครภายในฟังก์ชันหรือบล็อก
   • อย่าปลดมาโครหรือกำหนดมาโครใหม่
   • วาง #else, #elif และ #endif ในไฟล์เดียวกับ #if หรือ #ifdef ที่ตรงกัน
   • * วางไม่เกินหนึ่งคำสั่งหรือประกาศต่อบรรทัดของข้อความ
   • * ใช้ฟังก์ชั่นแบบสั้นที่มีจำนวนพารามิเตอร์ จำกัด
   • * ใช้การอ้อมโดยไม่เกินสองระดับต่อการประกาศ
   • * ใช้การยกเลิกการอ้างอิงไม่เกินสองระดับต่อการอ้างอิงวัตถุ
   • * อย่าซ่อนการดำเนินการตามข้อบกพร่องภายในมาโครหรือ typedefs
   • * อย่าใช้ตัวชี้ฟังก์ชั่นที่ไม่คงที่
   • อย่าใช้พอยน์เตอร์ของฟังก์ชั่นเป็นประเภทอื่น
   • อย่าวางโค้ดหรือการประกาศหน้าคำสั่ง #include

*) ทั้งหมดอยู่ในกฎจะกฎยกเว้นผู้ที่มีเครื่องหมายดอกจัน

ระบบคอมพิวเตอร์ที่ใช้พื้นที่พิสูจน์ได้ล้วนเกี่ยวกับความเชื่อถือได้ การแนะนำในเชิงลึกเกี่ยวกับสนามสามารถพบได้ในแนวคิดพื้นฐานของความน่าเชื่อถือโดย Algirdas Avižienis, Jean-Claude Laprie และ Brian Randell

เรียลไทม์ยังเป็นแนวคิดสำคัญสำหรับการคำนวณอวกาศ ในฐานะ Pankrat ฉันจะแนะนำระบบเรียลไทม์โดย Hermann Kopetz

สำหรับการให้ความรู้อย่างจริงจังเกี่ยวกับความท้าทายของการคำนวณอวกาศลองคิดดู:

• สภาวะสุดโต่งในอวกาศ: ร้อนมากเมื่อวางแนวกับดวงอาทิตย์เย็นมาก ๆ อีกด้านหนึ่งรังสีคอสมิคจำนวนมากซึ่งอาจเปลี่ยนบิตในหน่วยความจำการเร่งความเร็วและการสั่นสะเทือนขนาดใหญ่เมื่อถูก lauched ... ฮาร์ดแวร์สำหรับพื้นที่ต้องมีความแข็งแกร่งกว่าฮาร์ดแวร์ สำหรับทหาร

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

สิ่งที่ฉันเรียนรู้จากโครงการหนึ่งที่ฉันมีส่วนร่วมในการฝึกงาน:

รายละเอียดฮาร์ดแวร์ของคุณจะเปลี่ยนโดยปกติจะแย่ลงกว่าเดิม!

ตัวอย่างเช่นพื้นที่ที่ชุบแข็ง CPU ที่ถูกใช้ในการออกแบบนั้นถูกสัญญาไว้ว่าโปรดจำไว้ว่ามันจะทำงานที่ 20 MHz

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

ดังนั้นพยายามปล่อยให้ทรัพยากรพิเศษบางอย่างมีอยู่ในการออกแบบดั้งเดิมและพยายามอย่าใช้ CPU และหน่วยความจำที่มีอยู่ทั้งหมด

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

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

ฉันทำงานเกี่ยวกับอุปกรณ์สำคัญด้านความปลอดภัยและเราต้องผ่านห่วงที่คล้ายกัน

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

เรามีการเดินและการทดสอบค่าศูนย์ของการลงทะเบียนทั้งหมด ซึ่งรวมถึงตัวนับโปรแกรม!

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

บางส่วนอาจไม่เกี่ยวข้องกับโปรแกรมในอวกาศ แต่ให้ความรู้สึกถึงการตรวจสอบขนาดที่เป็นไปได้

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

หากหนึ่งสามารถประมาณระดับของข้อผิดพลาดอย่างใดอย่างหนึ่งสามารถสร้างรหัสการแก้ไขข้อผิดพลาดที่สามารถจัดการข้อผิดพลาดที่แนะนำ

• ใช่หน่วยความจำหลักอยู่ในบอร์ดการวิจัย
• หน่วยความจำแบบไดนามิกไม่ดีสำหรับระบบฝังตัว ปัญหาความน่าเชื่อถือ

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