รวบรวมแอปพลิเคชันสำหรับใช้ในสภาพแวดล้อมที่มีกัมมันตภาพรังสีสูง

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

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

ทำงานมาประมาณ 4-5 ปีด้วยการพัฒนาซอฟต์แวร์ / เฟิร์มแวร์และการทดสอบสภาพแวดล้อมของดาวเทียมขนาดจิ๋ว * ฉันต้องการแบ่งปันประสบการณ์ของฉันที่นี่

* ( ดาวเทียมขนาดจิ๋วนั้นมีแนวโน้มที่จะพลิกคว่ำเหตุการณ์เดี่ยวมากกว่าดาวเทียมที่ใหญ่กว่าเนื่องจากขนาดค่อนข้างเล็กและ จำกัด สำหรับชิ้นส่วนอิเล็กทรอนิกส์ )

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

ตอนนี้สถานการณ์นี้ได้รับการจัดการตามปกติทั้งในระดับฮาร์ดแวร์และซอฟต์แวร์ ที่นี่ตามที่คุณร้องขอฉันจะแบ่งปันสิ่งที่เราสามารถทำได้ในระดับซอฟต์แวร์

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

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

   1. สามารถฟังคำสั่งจากระบบภายนอก
   2. สามารถอัปเดตซอฟต์แวร์ / เฟิร์มแวร์ปัจจุบัน
   3. ความสามารถในการตรวจสอบข้อมูลการทำความสะอาดการดำเนินงานขั้นพื้นฐาน

3. ... คัดลอก ... บางแห่ง ...มีซอฟต์แวร์ / เฟิร์มแวร์ซ้ำซ้อนที่ไหนสักแห่ง

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

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

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

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

4. ... สถานการณ์ที่ผิดพลาดที่ตรวจพบได้ ..ข้อผิดพลาดจะต้องตรวจพบได้โดยปกติโดยการแก้ไขข้อผิดพลาดของฮาร์ดแวร์/ วงจรการตรวจสอบหรือโดยชิ้นส่วนเล็ก ๆ ของรหัสสำหรับการแก้ไขข้อผิดพลาด / การตรวจสอบ เป็นการดีที่สุดที่จะวางโค้ดขนาดเล็กหลาย ๆ ตัวและแยกจากซอฟต์แวร์ / เฟิร์มแวร์หลัก งานหลักของมันคือเพียงสำหรับการตรวจสอบ / แก้ไข หากวงจรฮาร์ดแวร์ / เฟิร์มแวร์คือเชื่อถือได้(เช่นมีการแผ่รังสีแข็งตัวกว่าส่วนที่เหลือ - หรือมีหลายวงจร / logics) ดังนั้นคุณอาจพิจารณาแก้ไขข้อผิดพลาดได้ แต่ถ้าไม่ใช่มันก็เป็นการดีกว่าที่จะทำให้มันเป็นตัวตรวจจับข้อผิดพลาด การแก้ไขสามารถทำได้โดยระบบ / อุปกรณ์ภายนอก สำหรับการแก้ไขข้อผิดพลาดคุณสามารถพิจารณาการใช้อัลกอริทึมการแก้ไขข้อผิดพลาดพื้นฐานเช่น Hamming / Golay23 เพราะพวกเขาสามารถดำเนินการได้ง่ายขึ้นทั้งในวงจร / ซอฟต์แวร์ แต่ท้ายที่สุดมันก็ขึ้นอยู่กับความสามารถของทีมของคุณ สำหรับการตรวจจับข้อผิดพลาดโดยปกติจะใช้ CRC

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

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

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

2. กรองในการอ่าน ADC ของคุณ อย่าได้ใช้ ADC อ่านโดยตรง กรองโดยใช้ตัวกรองมัธยฐานหมายถึงตัวกรองหรือตัวกรองอื่น ๆ - อย่าเชื่อถือค่าการอ่านเดียว ตัวอย่างมากขึ้นไม่น้อย - สมเหตุสมผล

NASA มีเอกสารเกี่ยวกับซอฟต์แวร์ที่ชุบแข็งด้วยรังสี มันอธิบายงานหลักที่สาม:

1. การตรวจสอบหน่วยความจำอย่างสม่ำเสมอเพื่อหาข้อผิดพลาดจากนั้นทำการขจัดข้อผิดพลาดเหล่านั้นออกไป
2. กลไกการกู้คืนข้อผิดพลาดที่มีประสิทธิภาพและ
3. ความสามารถในการกำหนดค่าใหม่หากสิ่งที่ใช้ไม่ได้อีกต่อไป

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

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

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

พวกเขาหารือเกี่ยวกับเทคนิคที่เหมาะสมสำหรับภาษาเชิงวัตถุเช่น C ++ ตัวอย่างเช่น

1. ซอฟต์แวร์ ECCs สำหรับวัตถุหน่วยความจำต่อเนื่อง
2. การเขียนโปรแกรมตามสัญญา : การตรวจสอบสิ่งที่จำเป็นและ postconditions จากนั้นตรวจสอบวัตถุเพื่อตรวจสอบว่ายังอยู่ในสถานะที่ถูกต้อง

และมันเกิดขึ้นเพียงเพื่อนาซ่าได้ใช้ภาษา C ++ สำหรับโครงการที่สำคัญเช่นดาวอังคารโรเวอร์

คลาส C ++ ที่เป็นนามธรรมและการห่อหุ้มช่วยให้สามารถพัฒนาและทดสอบได้อย่างรวดเร็วในหลายโครงการและนักพัฒนา

พวกเขาหลีกเลี่ยงฟีเจอร์ C ++ บางอย่างที่สามารถสร้างปัญหาได้:

1. ข้อยกเว้น
2. แม่แบบ
3. Iostream (ไม่มีคอนโซล)
4. หลายมรดก
5. ผู้ประกอบการเกินพิกัด (นอกเหนือจากnewและdelete)
6. การจัดสรรแบบไดนามิก (ใช้พูลหน่วยความจำเฉพาะและตำแหน่งnewเพื่อหลีกเลี่ยงความเป็นไปได้ที่ระบบฮีปจะเสียหาย)

นี่คือความคิดและความคิดบางอย่าง:

ใช้ ROM อย่างสร้างสรรค์ยิ่งขึ้น

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

ใช้ RAM ที่ดีที่สุดของคุณสำหรับสแต็ก

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

ใช้งานตัวจับเวลา timer และ watchdog

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

ใช้รหัสแก้ไขข้อผิดพลาดในซอฟต์แวร์

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

จำแคช

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

ใช้เครื่องมือจัดการข้อบกพร่องของหน้าอย่างชาญฉลาด

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

ใช้ภาษาแอสเซมบลีสำหรับสิ่งที่สำคัญ (ซึ่งอาจเป็นทุกอย่าง)

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

ใช้ objdumpเพื่อดูภาษาแอสเซมบลีที่สร้างขึ้นจริงและคำนวณจำนวนรหัสของรูทีนแต่ละครั้งที่ใช้

หากคุณใช้ระบบปฏิบัติการขนาดใหญ่เช่น Linux คุณจะต้องพบปัญหา มีความซับซ้อนมากมายและหลายสิ่งหลายอย่างที่ผิดพลาด

จำไว้ว่ามันเป็นเกมแห่งความน่าจะเป็น

ผู้วิจารณ์กล่าวว่า

รูทีนทุกครั้งที่คุณเขียนเพื่อตรวจจับข้อผิดพลาดจะต้องล้มเหลวจากสาเหตุเดียวกัน

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

ใช้ฮาร์ดแวร์ที่ซ้ำซ้อน

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

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

ที่สำหรับเริ่มอ่านคือบทความของ Huang and Abraham ในปี 1984 เรื่อง " ความผิดพลาดของอัลกอริธึมที่ใช้สำหรับการปฏิบัติการของเมทริกซ์ " แนวคิดของพวกเขาคล้ายกับการคำนวณแบบเข้ารหัส homomorphic (แต่มันไม่เหมือนกันจริง ๆ เนื่องจากพวกเขาพยายามตรวจจับ / แก้ไขข้อผิดพลาดในระดับการทำงาน)

ผู้สืบทอดล่าสุดของกระดาษชิ้นนั้นคือ Bosilca, Delmas, Dongarra และ Langou ของ " การยอมรับความผิดตามอัลกอริทึมที่ใช้กับการคำนวณประสิทธิภาพสูง "

การเขียนรหัสสำหรับสภาพแวดล้อมที่มีกัมมันตภาพรังสีไม่ได้แตกต่างไปจากการเขียนรหัสสำหรับแอปพลิเคชันที่สำคัญต่อภารกิจ

นอกจากสิ่งที่ถูกกล่าวถึงต่อไปนี้เป็นเคล็ดลับอื่น ๆ :

• ใช้มาตรการความปลอดภัย "ขนมปัง & เนย" ทุกวันที่ควรมีอยู่ในระบบฝังตัวกึ่งมืออาชีพใด ๆ : สุนัขเฝ้าบ้านภายในเครื่องตรวจจับแรงดันไฟฟ้าต่ำภายในจอภาพนาฬิกาภายใน สิ่งเหล่านี้ไม่ควรถูกกล่าวถึงในปี 2559 และเป็นมาตรฐานของไมโครคอนโทรลเลอร์สมัยใหม่ทุกตัว
• หากคุณมีความปลอดภัยและ / หรือยานยนต์ที่มุ่งเน้น MCU มันจะมีคุณสมบัติสุนัขเฝ้าบ้านบางอย่างเช่นช่วงเวลาที่กำหนดซึ่งคุณต้องรีเฟรชสุนัขเฝ้าบ้าน สิ่งนี้เป็นที่ต้องการหากคุณมีระบบเรียลไทม์ที่สำคัญต่อภารกิจ
• โดยทั่วไปให้ใช้ MCU ที่เหมาะสมกับระบบประเภทนี้และไม่ใช่ข้อมูลทั่วไปที่คุณได้รับในแพ็คเก็ตของเกล็ดข้าวโพด ผู้ผลิต MCU เกือบทุกคนในปัจจุบันมี MCU พิเศษที่ออกแบบมาสำหรับการใช้งานด้านความปลอดภัย (TI, Freescale, Renesas, ST, Infineon และอื่น ๆ ) สิ่งเหล่านี้มีคุณสมบัติด้านความปลอดภัยในตัวมากมายรวมถึงแกนล็อคขั้นตอน: หมายความว่ามี 2 แกนประมวลผลที่ทำงานรหัสเดียวกันและพวกเขาจะต้องเห็นด้วยกัน

• สำคัญ: คุณจะต้องมั่นใจในความสมบูรณ์ของการลงทะเบียน MCU ภายใน การลงทะเบียนการควบคุมและสถานะทั้งหมดของอุปกรณ์ต่อพ่วงฮาร์ดแวร์ที่สามารถเขียนได้อาจอยู่ในหน่วยความจำ RAM และมีความเสี่ยงสูง

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

  หมายเหตุ: ควรใช้การเขียนโปรแกรมป้องกัน หมายความว่าคุณต้องตั้งค่าการลงทะเบียนทั้งหมดใน MCU ไม่ใช่เฉพาะแอปพลิเคชันที่ใช้ คุณไม่ต้องการให้อุปกรณ์ต่อพ่วงฮาร์ดแวร์บางตัวตื่นขึ้นมาทันที

• มีวิธีการตรวจสอบข้อผิดพลาดใน RAM หรือ NVM ทุกชนิด: checksums "รูปแบบการเดิน" ซอฟต์แวร์ ECC เป็นต้นวิธีที่ดีที่สุดในปัจจุบันคือไม่ใช้สิ่งเหล่านี้ แต่ใช้ MCU ที่มี ECC ในตัวและ ตรวจสอบที่คล้ายกัน เนื่องจากการทำเช่นนี้ในซอฟต์แวร์มีความซับซ้อนและการตรวจสอบข้อผิดพลาดในตัวเองจึงสามารถแนะนำข้อบกพร่องและปัญหาที่ไม่คาดคิด

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

• ทำความเข้าใจและยอมรับแนวคิดของการตั้งโปรแกรมป้องกัน ซึ่งหมายความว่าโปรแกรมของคุณต้องจัดการกับทุกกรณีที่เป็นไปได้แม้แต่ในกรณีที่ไม่สามารถเกิดขึ้นได้ในทางทฤษฎี ตัวอย่างตัวอย่าง

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

• อย่าเขียนโปรแกรมที่พึ่งพาพฤติกรรมที่ระบุไม่ดี เป็นไปได้ว่าพฤติกรรมดังกล่าวอาจเปลี่ยนไปอย่างมากกับการเปลี่ยนแปลงฮาร์ดแวร์ที่ไม่คาดคิดที่เกิดจากรังสีหรือ EMI วิธีที่ดีที่สุดเพื่อให้แน่ใจว่าโปรแกรมของคุณปราศจาก crap ดังกล่าวคือใช้มาตรฐานการเข้ารหัสเช่น MISRA ร่วมกับเครื่องมือวิเคราะห์แบบสแตติก สิ่งนี้จะช่วยในการตั้งโปรแกรมการป้องกันและกำจัดข้อบกพร่อง (ทำไมคุณไม่ต้องการตรวจจับข้อบกพร่องในแอพพลิเคชั่นประเภทใด?)

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

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

  ในทำนองเดียวกันใน C ++ อย่าพึ่งพาคอนสตรัคเตอร์สำหรับตัวแปรระยะเวลาการจัดเก็บแบบคงที่ ให้ constructor (s) เรียกชุดคำสั่ง "set-up" ของสาธารณะซึ่งคุณสามารถเรียกใช้ในภายหลังในเวลาทำงานได้โดยตรงจากแอปพลิเคชันผู้โทร

  หากเป็นไปได้ให้ลบรหัสเริ่มต้น "คัดลอก" ที่เริ่มต้น.dataและ.bss(และเรียกใช้ตัวสร้าง C ++) ทั้งหมดเพื่อให้คุณได้รับข้อผิดพลาดตัวเชื่อมโยงหากคุณเขียนรหัสขึ้นอยู่กับสิ่งนี้ คอมไพเลอร์จำนวนมากมีตัวเลือกในการข้ามสิ่งนี้โดยปกติจะเรียกว่า "การเริ่มต้นขั้นต่ำ / เร็ว" หรือคล้ายกัน

  ซึ่งหมายความว่าต้องตรวจสอบไลบรารีภายนอกใด ๆ เพื่อไม่ให้มีการพึ่งพาดังกล่าว

• ใช้งานและกำหนดสถานะที่ปลอดภัยสำหรับโปรแกรมไปยังที่ที่คุณจะย้อนกลับในกรณีที่เกิดข้อผิดพลาดร้ายแรง

• การใช้รายงานข้อผิดพลาด / ระบบบันทึกข้อผิดพลาดจะมีประโยชน์เสมอ

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

การประกาศตัวแปรตามที่volatileมักเป็นประโยชน์ แต่อาจไม่ใช่ยาครอบจักรวาล ความสำคัญเป็นพิเศษโปรดทราบว่าการเข้ารหัสที่ปลอดภัยมักจะต้องมีการดำเนินการที่เป็นอันตรายมีฮาร์ดแวร์ interlocks ที่ต้องใช้หลายขั้นตอนเพื่อเปิดใช้งานและรหัสนั้นจะถูกเขียนโดยใช้รูปแบบ:

... code that checks system state
if (system_state_favors_activation)
{
  prepare_for_activation();
  ... code that checks system state again
  if (system_state_is_valid)
  {
    if (system_state_favors_activation)
      trigger_activation();
  }
  else
    perform_safety_shutdown_and_restart();
}
cancel_preparations();

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

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

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

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

• ตัวแปรร้านค้าที่มีความซ้ำซ้อน หากคุณมีตัวแปรที่สำคัญxเขียนความคุ้มค่าในx1, x2และและอ่านมันเป็นx3(x1 == x2) ? x2 : x3

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

• ตรวจสอบตัวชี้สแต็ค ในตอนต้นของลูปหลักให้เปรียบเทียบตัวชี้สแต็กกับค่าที่คาดไว้ รีเซ็ตความเบี่ยงเบน

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

Watchdog เป็นคุณสมบัติฮาร์ดแวร์ / ซอฟต์แวร์แบบรวม ฮาร์ดแวร์เป็นตัวนับอย่างง่ายที่นับถอยหลังจากจำนวน (พูด 1,023) เป็นศูนย์ สามารถใช้ TTLหรือตรรกะอื่น ๆ ได้

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

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

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

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

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

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

นี่คือแนวคิดบางส่วน:

• ตรวจสอบให้แน่ใจว่าฮาร์ดแวร์ทั้งหมดของคุณมีการทำซ้ำnครั้ง ( nมากกว่า 2 และแปลกกว่า) และองค์ประกอบฮาร์ดแวร์แต่ละตัวสามารถสื่อสารกับองค์ประกอบฮาร์ดแวร์อื่น ๆ ได้ อีเธอร์เน็ตเป็นวิธีที่ชัดเจนในการทำเช่นนั้น แต่มีเส้นทางอื่น ๆ อีกมากมายที่ง่ายกว่าที่จะให้การป้องกันที่ดีกว่า (เช่น CAN) ลดส่วนประกอบทั่วไปให้น้อยที่สุด (แม้แต่แหล่งจ่ายไฟ) นี่อาจหมายถึงการสุ่มตัวอย่างอินพุต ADC ในหลาย ๆ ที่เช่น

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

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

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

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

• ใช้ฮาร์ดแวร์เพื่อสนับสนุนคุณ แต่ทำอย่างระมัดระวัง ตัวอย่างเช่นคุณสามารถรับ ECC RAM และอ่าน / เขียนเป็นประจำเพื่อแก้ไขข้อผิดพลาด ECC (และตกใจถ้าข้อผิดพลาดนั้นไม่สามารถแก้ไขได้) อย่างไรก็ตาม (จากหน่วยความจำ) คง RAM เป็นใจกว้างมากขึ้นของรังสีกว่า DRAM อยู่ในสถานที่แรกดังนั้นมันอาจจะดีกว่าการใช้งานคง DRAM แทน ดูจุดแรกภายใต้ 'สิ่งที่ฉันจะไม่ทำ' เช่นกัน

สมมติว่าคุณมีโอกาส 1% ที่จะเกิดความล้มเหลวของโหนดที่กำหนดภายในหนึ่งวันและสมมติว่าคุณสามารถทำให้ความล้มเหลวเป็นอิสระโดยสิ้นเชิง ด้วย 5 โหนดคุณจะต้องสามล้มเหลวภายในหนึ่งวันซึ่งมีโอกาสเป็น .00001% ยิ่งคุณมีความคิดมากขึ้น

สิ่งที่ฉันจะไม่ทำ:

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

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

• ใช้การตั้งค่าคอมไพเลอร์ที่ซับซ้อนในความไร้เดียงสาหวังว่าคุณจะตรวจพบความล้มเหลวมากขึ้น หากคุณโชคดีคุณอาจตรวจพบความล้มเหลวเพิ่มเติม มีโอกาสมากขึ้นที่คุณจะใช้โค้ด - พา ธ ภายในคอมไพเลอร์ซึ่งผ่านการทดสอบน้อยกว่าโดยเฉพาะถ้าคุณรีดด้วยตัวคุณเอง

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

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

แทนการใช้uint32_t(และdouble, int64_tฯลฯ ) ทำด้วยตัวเองSAFE_uint32_tซึ่งมีหลาย ๆ (อย่างน้อย 3) ของ uint32_t โอเวอร์โหลดการดำเนินการทั้งหมดที่คุณต้องการ (* + - / << >> = ==! = ฯลฯ ) เพื่อดำเนินการและทำให้การดำเนินการโอเวอร์โหลดดำเนินการอย่างอิสระในแต่ละค่าภายในเช่นอย่าทำครั้งเดียวและคัดลอกผลลัพธ์ ทั้งก่อนและหลังตรวจสอบว่าค่าภายในทั้งหมดตรงกัน หากค่าไม่ตรงกันคุณสามารถอัปเดตค่าที่ไม่ถูกต้องเป็นค่าที่พบบ่อยที่สุด หากไม่มีค่าที่พบได้บ่อยที่สุดคุณสามารถแจ้งได้อย่างปลอดภัยว่ามีข้อผิดพลาด

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

เรื่องด้าน: ฉันพบปัญหาที่คล้ายกันรวมถึงชิป ARM รุ่นเก่าด้วย กลายเป็น toolchain ซึ่งใช้ GCC รุ่นเก่าซึ่งรวมถึงชิปเฉพาะที่เราใช้เรียกจุดบกพร่องในบางกรณีที่ขอบซึ่งบางครั้งจะส่งค่าความเสียหายไปยังฟังก์ชั่น ตรวจสอบให้แน่ใจว่าอุปกรณ์ของคุณไม่มีปัญหาใด ๆ ก่อนที่จะตำหนิในกิจกรรมทางวิทยุและใช่บางครั้งก็เป็นคอมไพเลอร์บั๊ก =)

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

ปัญหาหลักที่มีกัมมันตภาพรังสีในความคิดของฉันคือการที่กัมมันตภาพรังสีสามารถสลับบิตจึงกัมมันตภาพรังสีสามารถ / จะยุ่งหน่วยความจำดิจิตอลใด ข้อผิดพลาดเหล่านี้มักจะเรียกว่าข้อผิดพลาดอ่อน , เน่าบิต

คำถามคือวิธีการคำนวณอย่างน่าเชื่อถือเมื่อหน่วยความจำของคุณไม่น่าเชื่อถือ?

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

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

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

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

• โครงสร้างข้อมูลอัลกอริธึมที่ยืดหยุ่นได้รับการแนะนำโดย Giuseppe F.Italiano, Universita di Roma "Tor Vergata"

• Christiano, P. , Demaine, ED, & Kishore, S. (2011) โครงสร้างข้อมูลที่ป้องกันความผิดพลาดแบบไม่สูญเสียพร้อมค่าใช้จ่ายเพิ่มเติม ในอัลกอริทึมและโครงสร้างข้อมูล (หน้า 243-254) สปริงเกอร์เบอร์ลินไฮเดลเบิร์ก

• Ferraro-Petrillo, U. , Grandoni, F. , & Italiano, GF (2013) โครงสร้างข้อมูลมีความยืดหยุ่นต่อความผิดปกติของหน่วยความจำ: การศึกษาเชิงทดลองของพจนานุกรม วารสารของอัลกอริทึมทดลอง (JEA), 18, 1-6

• Italiano, GF (2010) อัลกอริทึมที่ยืดหยุ่นและโครงสร้างข้อมูล ในอัลกอริทึมและความซับซ้อน (หน้า 13-24) สปริงเกอร์เบอร์ลินไฮเดลเบิร์ก

หากคุณสนใจที่จะเรียนรู้เพิ่มเติมเกี่ยวกับโครงสร้างข้อมูลที่ยืดหยุ่นคุณสามารถเช็คเอาต์งานของGiuseppe F. Italiano (และทำงานในการอ้างอิง) และรุ่นFaulty-RAM (แนะนำใน Finocchi et al. 2005; Finocchi และ Italiano 2008)

/ แก้ไข: ฉันภาพประกอบการป้องกัน / การกู้คืนจากข้อผิดพลาดนุ่มส่วนใหญ่สำหรับหน่วยความจำ RAM และการจัดเก็บข้อมูล แต่ฉันไม่ได้พูดคุยเกี่ยวกับการคำนวณข้อผิดพลาด (CPU) คำตอบอื่น ๆ ชี้ให้เห็นแล้วที่ใช้ธุรกรรมอะตอมเช่นในฐานข้อมูลดังนั้นผมจะนำเสนออีกรูปแบบที่เรียบง่าย: ความซ้ำซ้อนและเสียงข้างมาก

แนวคิดคือคุณเพียงแค่ทำการ x คูณการคำนวณเดียวกันสำหรับการคำนวณแต่ละครั้งที่คุณต้องทำและเก็บผลลัพธ์ไว้ในตัวแปร x ที่แตกต่างกัน (ด้วย x> = 3) จากนั้นคุณสามารถเปรียบเทียบตัวแปร x ของคุณ :

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

โครงการนี้จะซ้ำซ้อนอย่างรวดเร็วเมื่อเทียบกับ ECC (จริง O (1)) และให้คุณมีสัญญาณที่ชัดเจนเมื่อคุณจำเป็นต้องป้องกันความผิดพลาด คะแนนโหวตส่วนใหญ่ (เกือบ) รับรองได้ว่าจะไม่สร้างผลลัพธ์ที่เสียหายและกู้คืนจากข้อผิดพลาดในการคำนวณเล็กน้อยเนื่องจากความน่าจะเป็นที่การคำนวณ x ให้ผลลัพธ์เดียวกันนั้นน้อยมาก (เพราะมีเอาต์พุตจำนวนมากเป็นไปไม่ได้ รับแบบสุ่ม 3 เท่าโดยมีโอกาสน้อยลงถ้า x> 3)

ดังนั้นด้วยการโหวตเสียงส่วนใหญ่คุณจะปลอดภัยจากผลลัพธ์ที่เสียหายและด้วยความซ้ำซ้อน x == 3 คุณสามารถกู้คืนได้ 1 ข้อผิดพลาด (ด้วย x == 4 จะสามารถกู้คืนได้ 2 ข้อผิดพลาด ฯลฯ - สมการที่แน่นอนคือnb_error_recoverable == (x-2)โดยที่ x คือจำนวน ของการทำซ้ำการคำนวณเพราะคุณต้องการอย่างน้อย 2 ข้อตกลงการคำนวณในการกู้คืนโดยใช้คะแนนเสียงส่วนใหญ่)

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

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

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

คำตอบคือการทดสอบหน่วยโดยอัตโนมัติ เขียนชุดทดสอบที่ใช้รหัสบนระบบการพัฒนาจากนั้นเรียกใช้ชุดทดสอบทดสอบเดียวกันบนระบบเป้าหมาย มองหาความแตกต่าง!

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

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

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

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

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

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

สิ่งที่คุณถามเป็นหัวข้อที่ค่อนข้างซับซ้อน - ไม่ตอบคำถามได้ง่าย คำตอบอื่น ๆ ก็โอเค แต่พวกเขาครอบคลุมเพียงส่วนเล็ก ๆ ของทุกสิ่งที่คุณต้องทำ

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

ถ้าฉันเป็นคุณฉันจะสร้างซอฟต์แวร์ในระดับความปลอดภัยสูงสุด(SIL-4) รับเอกสาร IEC 61513 (สำหรับอุตสาหกรรมนิวเคลียร์) และปฏิบัติตาม

มีคนพูดถึงการใช้ชิปที่ช้ากว่าเพื่อป้องกันไอออนจากการพลิกบิตได้อย่างง่ายดาย ในลักษณะที่คล้ายกันอาจใช้ cpu / ram พิเศษที่ใช้หลายบิตเพื่อเก็บบิตเดียว ดังนั้นการให้ความทนทานต่อความผิดพลาดของฮาร์ดแวร์เนื่องจากเป็นไปได้ยากมากที่บิตทั้งหมดจะถูกพลิก ดังนั้น 1 = 1111 แต่จะต้องได้รับการตี 4 ครั้งเพื่อพลิกจริง (4 อาจเป็นจำนวนที่ไม่ดีเนื่องจากหาก 2 บิตถูกพลิกมันไม่ชัดเจน) ดังนั้นถ้าคุณไปด้วย 8 คุณจะได้ RAM น้อยลง 8 เท่าและบางส่วนใช้เวลาเข้าถึงช้าลง แต่มีการแสดงข้อมูลที่เชื่อถือได้มากขึ้น คุณอาจจะทำสิ่งนี้ทั้งในระดับซอฟต์แวร์ด้วยคอมไพเลอร์เฉพาะ (จัดสรร x จำนวนพื้นที่เพิ่มเติมสำหรับทุกสิ่ง) หรือการใช้ภาษา (wrappers เขียนสำหรับโครงสร้างข้อมูลที่จัดสรรสิ่งนี้ด้วยวิธี)

บางทีมันอาจช่วยให้รู้ว่าฮาร์ดแวร์หมายถึง "ออกแบบมาสำหรับสภาพแวดล้อมนี้" หรือไม่ จะแก้ไขและ / หรือระบุว่ามีข้อผิดพลาด SEU ได้อย่างไร

ในโครงการที่เกี่ยวข้องกับการสำรวจอวกาศเรามี MCU ที่กำหนดเองซึ่งจะเพิ่มข้อยกเว้น / ขัดจังหวะข้อผิดพลาด SEU แต่มีความล่าช้าบางอย่างเช่นบางรอบอาจผ่าน / คำสั่งจะดำเนินการหลังจากหนึ่ง insn ซึ่งทำให้เกิดข้อยกเว้น SEU

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

เราระบุลำดับที่เป็นอันตราย (ไม่สามารถรีสตาร์ทได้) (เช่นlw $3, 0x0($2)ตามด้วย insn ซึ่งแก้ไข$2และไม่ขึ้นอยู่กับข้อมูล$3) และฉันได้ทำการแก้ไข GCC ดังนั้นลำดับดังกล่าวจะไม่เกิดขึ้น (เช่นเป็นทางเลือกสุดท้าย สอง insns โดยnop)

สิ่งที่ต้องพิจารณา ...

หากฮาร์ดแวร์ของคุณล้มเหลวคุณสามารถใช้ที่เก็บข้อมูลเชิงกลเพื่อกู้คืนได้ หากฐานรหัสของคุณมีขนาดเล็กและมีพื้นที่ทางกายภาพบางส่วนคุณสามารถใช้ที่เก็บข้อมูลเชิงกล

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

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

คล้ายกับแนวคิด Watchdog เป็นตัวกำหนดเวลา เริ่มจับเวลาฮาร์ดแวร์ก่อนเรียกใช้ฟังก์ชัน หากฟังก์ชั่นไม่ส่งคืนก่อนที่ตัวจับเวลาจะหยุดชะงักให้โหลดสแต็กใหม่แล้วลองอีกครั้ง หากยังคงล้มเหลวหลังจาก 3/5 พยายามคุณต้องโหลดซ้ำจาก ROM

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

ทุกอย่างต้องการซีอาร์ซี หากคุณใช้งาน RAM ไม่เพียงพอแม้. text จะต้องใช้ CRC ตรวจสอบ CRC อย่างสม่ำเสมอหากคุณใช้ตัวกำหนดตารางเวลาแบบวนรอบ คอมไพเลอร์บางตัว (ไม่ใช่ GCC) สามารถสร้างซีอาร์ซีสำหรับแต่ละส่วนและตัวประมวลผลบางตัวมีฮาร์ดแวร์เฉพาะสำหรับการคำนวณซีอาร์ซี แต่ฉันเดาว่ามันจะหลุดออกจากขอบเขตของคำถามของคุณ การตรวจสอบ CRCs จะแจ้งให้ตัวควบคุม ECC บนหน่วยความจำเพื่อซ่อมแซมข้อผิดพลาดบิตเดียวก่อนที่จะกลายเป็นปัญหา

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

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

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

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

นี่คือคำตอบจำนวนมาก แต่ฉันจะพยายามสรุปความคิดของฉันเกี่ยวกับเรื่องนี้

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

ฉันจะแนะนำก่อนพยายามจับสถานการณ์ที่มีปัญหาโดยการบันทึก (stack, register, function call) - โดยการบันทึกพวกเขาลงในไฟล์หรือส่งพวกเขาโดยตรงอย่างใดอย่างหนึ่ง ("โอ้ไม่ - ฉันพัง")

การกู้คืนจากสถานการณ์ข้อผิดพลาดนั้นเป็นการรีบูต (หากซอฟต์แวร์ยังมีชีวิตอยู่และเตะ) หรือรีเซ็ตฮาร์ดแวร์ (เช่น hw watchdogs) ง่ายกว่าที่จะเริ่มจากคนแรก

หากปัญหาเกี่ยวกับฮาร์ดแวร์ - การบันทึกควรช่วยคุณระบุว่าปัญหาการเรียกใช้ฟังก์ชันใดเกิดขึ้นและสามารถให้ความรู้แก่คุณเกี่ยวกับสิ่งที่ไม่ทำงานและที่ใด

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

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

และถ้าคุณจัดการให้ย่อเล็กสุดจนเต็มแอปพลิเคชั่น "hello world" - และมันยังล้มเหลวแบบสุ่ม - คาดว่าปัญหาฮาร์ดแวร์ - และจะต้องมี "การอัพเกรดฮาร์ดแวร์" - หมายถึงประดิษฐ์ cpu / ram / ... - การรวมฮาร์ดแวร์ที่ทนต่อรังสีได้ดีกว่า

สิ่งที่สำคัญที่สุดอาจเป็นวิธีที่คุณได้รับบันทึกของคุณกลับมาหากเครื่องหยุดทำงาน / ตั้งค่าใหม่อย่างสมบูรณ์ / ไม่ทำงาน - อาจเป็นสิ่งแรกที่ bootstap ควรทำ - เป็นหัวหน้ากลับบ้านหากสถานการณ์มีปัญหา

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

ฉันอ่านคำตอบที่ดีมากจริงๆ!

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

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