มีการใช้ซอฟต์แวร์ในระบบที่มีความสำคัญต่อชีวิตหรือความตายอย่างไร


51

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

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

ฉันหวังเป็นอย่างยิ่งว่าคุณจะไม่ได้ไป: "โอ้ฉันทำงานให้กับโบอิ้ง / แอร์บัส / (บริษัท อื่น ๆ ) และมันไม่ได้! ขอให้สนุกในเที่ยวบิน / โรงพยาบาลต่อไปของคุณ"


8
พิจารณากรณีของ Therac25 และแบตเตอรี่ต่อต้านการก่อการร้ายที่ไม่ได้มีส่วนร่วมอย่างชัดเจนไม่เพียงพอ
Loren Pechtel

@ Loren ดีฉันไม่สงสัยเลยว่าจะไม่มีข้อยกเว้น ในทางกลับกันฉันไม่เคยอ่าน Airbus A320 (เครื่องบินบินด้วยสายไฟ) มาก่อนเพื่อรับประสบการณ์ข้อผิดพลาดของซอฟต์แวร์ที่สำคัญซึ่งส่งผลให้เกิดการบาดเจ็บ / บาดเจ็บ / เสียชีวิตใกล้และมีมากกว่า 4,000 รายการ
waiwai933

3
"Hello World" อาจล้มเหลว lol
xandy

1
@waiwai - ที่จริงแล้วมันเกิดขึ้นประมาณหนึ่งปีที่แล้ว - เซ็นเซอร์ที่ผิดพลาดระบุว่าเครื่องบินกำลังปีนขึ้นไปสูงเกินไปและกำลังจะหยุด ความพยายามของคอมพิวเตอร์ที่จะกลับไปสู่การบินระดับนั้นเป็นเรื่องจริง ไม่มีการชน แต่มีการบาดเจ็บ / ความเสียหายจากผู้โดยสารและวัตถุหลวมที่ถูกโยนไปรอบ ๆ ห้องโดยสาร
Tom Clarkson

6
พวกเขาไม่ใช้นักโทษประหารที่มีใบอนุญาตนักบินหรือไม่?
JeffO

คำตอบ:


29

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

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

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

จากการวิเคราะห์ความเสี่ยงนั้นแบ่งออกเป็นประเภทต่างๆ ระดับการจำแนกประเภททั่วไปคือประเภทที่ 1 ถึงหมวดที่ 4 (ตามมาตรฐาน EN 954-1) ขึ้นอยู่กับหมวดหมู่เหล่านี้คุณจำเป็นต้องมีกฎหมายเพื่อให้การปกป้องเครื่องจักรและความปลอดภัยในระดับหนึ่ง

ตัวอย่างเช่นหมวด 4 ต้องการสิ่งนั้น:

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

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

สิ่งนี้อาจเป็นเรื่องยากที่จะประสบความสำเร็จในทางปฏิบัติ แต่ทำได้ง่ายกว่าโดยความพร้อมของส่วนประกอบมาตรฐานที่ได้รับการรับรองสำหรับหมวดที่ 4 ตัวอย่างเช่นองค์ประกอบทั่วไปหนึ่งอย่างในระบบเหล่านี้คือ Safety Relay เหล่านี้เป็นมากกว่ารีเลย์เชิงกล:

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

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

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

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

ในช่วงไม่กี่ปีที่ผ่านมามีการปฏิวัติระบบความปลอดภัย ในขณะที่ไม่มีใครเชื่อถือข้อมูลความปลอดภัยในการส่งผ่านเครือข่ายดังนั้นสิ่งที่มักจะเรียกว่า "ระบบ I / O แบบกระจาย" เช่น DeviceNET และ EtherCAT ไม่ได้รับอนุญาตในส่วนความปลอดภัยของระบบ อย่างไรก็ตามโปรโตคอลล่าสุดช่วยให้อุปกรณ์ความปลอดภัยทำงานบนเครือข่ายอุตสาหกรรมเหล่านี้ โปรโตคอลใช้ประโยชน์จากข้อความที่ประทับเวลาและการประมวลผลซ้ำซ้อนคู่ที่ปลายทั้งสองของการเชื่อมต่อ

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

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


20

มีการย้ายไปสู่การยืนยันที่เป็นทางการมากกว่าการทดสอบการทำงานแบบสุ่ม

หน่วยงานภาครัฐเช่น NASA และหน่วยงานป้องกันบางแห่งกำลังใช้เทคโนโลยีเหล่านี้มากขึ้นเรื่อย ๆ

พวกเขายังคงเป็น PITA สำหรับโปรแกรมเมอร์โดยเฉลี่ย แต่มักจะมีประสิทธิภาพมากกว่าในการทดสอบระบบที่สำคัญ

นอกจากนี้ยังมีแนวโน้มที่จะลองใช้เทคนิคเพิ่มเติมจากสถาบันการศึกษาสำหรับสิ่งต่าง ๆ เช่นการตรวจสอบรหัสแบบมัลติเธรด


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

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

2
@Ben Voight: ถ้าฉันเป็นนักบินอวกาศฉันจะตื่นตระหนกอย่างมากจากรายงานของคุณ
Orbling

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

1
และเป็นเรื่องน่าเศร้าที่คิดว่ามีคนจำนวนไม่น้อยที่ฟัง Dijkstra ที่กำลังดำเนินการและตรวจสอบอย่างเป็นทางการมาตั้งแต่ทศวรรษ 1960 ดังที่ Nietzsche กล่าวว่า "ผู้ชายบางคนเกิดมาต้อ"
มากมาก

12

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

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

ฉันรู้ว่ามีตัวอย่างหนึ่งที่จำเป็นต้องมีการเปลี่ยนระบบเที่ยวบินอย่างง่ายมาก - ดังนั้นคุณจะงงงวยกับสิ่งที่เล็กน้อย อย่างไรก็ตามการทดสอบนี้จะใช้เวลา> 3 เดือนและมีราคาประมาณ $ 1M

เมื่อคุณเข้าสู่การแพทย์มีทั้งชุดของกฎระเบียบที่จะข้ามที่เกี่ยวข้องไม่เพียง แต่การทดสอบ แต่ยังกระบวนการพัฒนาและเอกสาร

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


ตัวอย่างของ "2 การออกแบบฮาร์ดแวร์ที่แตกต่างกันที่ใช้และสองชิ้นที่พัฒนาอย่างอิสระของ s / w หนึ่งที่จะทำงานในแต่ละ" จะน่าสนใจ ไม่เห็นด้วยเพียงแค่อยากรู้อยากเห็น
Brian Carlton

1
@Brian: ตัวอย่างที่คุ้นเคยสำหรับ 2 HW ที่แตกต่างกัน 2 SW ที่พัฒนาอย่างอิสระสามารถพบได้ในตัวควบคุมระบบเบรกป้องกันล้อล็อก ดูตัวอย่างinfineon.com/cms/jp/product/applications/automotive/safety/…ซึ่งใช้สถาปัตยกรรมซีพียูสองแบบ (8 บิตและ 16 บิต) ใน IC เดียว
Schedler

4
สามดียิ่งขึ้น ด้วยสองคุณจะรู้ว่าหนึ่งในนั้นผิด ด้วยสามคุณสามารถลงคะแนน AFAIK เครื่องบินแอร์บัส A380 มีคอมพิวเตอร์สามเครื่องจากผู้ผลิตสองราย
Jörg W Mittag

หลายปีที่ผ่านมาฉันได้พบกับหัวหน้าโรงทหารที่ออกแบบมาในลักษณะนี้ ฉันเดาว่าเนื่องจากค่าใช้จ่ายจำนวนมากเทคนิคเหล่านี้ไม่ได้ใช้เท่าที่เคยเป็น
quick_now


3

เมื่อคุณได้คำตอบที่ดีและให้ข้อมูลมากพอแล้ว

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


3

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

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

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

ฉันสามารถใช้ +1 สำหรับการอ้างอิงทุกครั้งที่ฉันพบกับซอฟต์แวร์ที่สำคัญซึ่งไม่ได้รับการออกแบบหรือทดสอบดีหรือไม่? Simson Garfinkel จัดทำเอกสารสิบกรณีในบทความเกี่ยวกับ WIRED


น่าเสียดายที่นี่แม่นยำเกินไป
Ben Voigt

แน่นอนว่าฉันขอให้คุณทำตามข้อเสนอนั้นสำหรับ -1
ไบรอันคาร์ลตัน

@Brian Carlton คุณไม่ได้ให้การอ้างอิง ...
Apalala

สิ่งที่เกี่ยวกับ DO-178, MOPS สำหรับ GPS ... อย่างน้อยฉันทำงานการทดสอบอาจใช้เวลานานกว่าหนึ่งปี โปรดทราบว่าการทดสอบไม่แน่ใจว่ารหัสปราศจากข้อบกพร่องและสอดคล้องกับข้อกำหนดในทุกกรณีที่เป็นไปได้
jinawee

2

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

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

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

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

มาตรฐานไม่ได้ห้ามการพัฒนาที่คล่องตัวแม้ว่าเมื่ออ่านแล้วดูเหมือนว่ามันถูกเขียนขึ้นโดยคำนึงถึงการพัฒนาของน้ำตก

ฉันไม่รู้เกี่ยวกับการพัฒนาซอฟต์แวร์ในด้านอื่น ๆ เช่นการบินรถไฟรถยนต์ ฯลฯ แต่ฉันคิดว่ามีแนวทางทางการอื่น ๆ ที่คล้ายคลึงกันอยู่


1

มีการใช้เทคนิคหลายอย่างรวมถึง แต่ไม่ จำกัด เพียง:

  • การออกแบบอย่างเป็นทางการและ / หรือการตรวจสอบ
  • มาตรฐานการเข้ารหัสที่เข้มงวดหลีกเลี่ยงการเขียนโปรแกรมแฟนซีเช่นการจัดสรรหน่วยความจำแบบไดนามิก
  • วิศวกรที่มีคุณภาพที่ต้องการมาก
  • เทคนิคการวิเคราะห์แบบสแตติกจำนวนมากเช่นการตรวจสอบรหัสต้นไม้ความผิด FMECA, ...

แต่เทคนิคอันดับหนึ่งคือ:

  • ทดสอบ

ซอฟต์แวร์ของยานอวกาศต้องการความพยายามในการทดสอบมากกว่าการออกแบบและรหัสในตอนแรก

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


1

มีบทความ "ซอฟต์แวร์ที่สมบูรณ์แบบ" โดย Jack Ganssle ใน EETimes ลงวันที่ 3/1/2009 12:00 AM EST จากจุดนี้:

  • "ในทางทฤษฎีซอฟต์แวร์เป็นองค์ประกอบเดียวที่สมบูรณ์แบบและนี่ควรเป็นจุดเริ่มต้นของเราเสมอ" - กล่าวโดย Jesse Poore ติดตามหน้าเว็บของเขาคุณจะพบว่าซอฟต์แวร์ที่สมบูรณ์แบบสามารถทำอะไรได้มากไปกว่าซอฟต์แวร์ปกติ
  • มีผู้ให้บริการอุตสาหกรรมของระบบปฏิบัติการที่เชื่อถือได้สูง บทความที่กล่าวถึง Mircrium และ Green Hills ติดตามหน้าเว็บของ Micrium มีรายการมาตรฐานสำหรับการรับรอง สิ่งเหล่านั้นจะต้องเป็นกระบวนการและกฎที่อุตสาหกรรมปฏิบัติตาม นั่นขึ้นอยู่กับการตรวจสอบอย่างเป็นทางการ แต่เบี่ยงเบนจากทฤษฎีมาก

ที่น่าสนใจเกี่ยวกับซอฟต์แวร์เชิงพาณิชย์ข้อมูลที่เก็บรวบรวมโดย Capers Jones ชี้ให้เห็นว่า "ซอฟต์แวร์โดยทั่วไปมีประสิทธิภาพในการกำจัดข้อบกพร่อง (เปอร์เซ็นต์ของข้อผิดพลาดที่ถูกลบออกไปก่อนการจัดส่ง) 87%" เฟิร์มแวร์นั้น สำหรับฉันไม่มีสิ่งเหล่านี้ใกล้สมบูรณ์ บทความจากผู้ตอบคำถามก่อนหน้านี้ระบุว่าทีมกระสวยอวกาศของนาซ่าประสบความสำเร็จในการกำจัดข้อผิดพลาด 99% แต่ค่าใช้จ่ายอยู่ที่ 35 ล้านต่อปีสำหรับโค้ดประมาณ 400k บรรทัด

บทความที่น่าสนใจมากขึ้น "ซอฟต์แวร์สำหรับระบบที่เชื่อถือได้" โดยผู้เขียนคนเดียวกันเมื่อวันที่ 11/1/2552 ดูเหมือนว่าจะมีความเกี่ยวข้องมากกว่า สามารถสรุปได้ดังนี้:

  • สำหรับกระบวนการพัฒนานั้นอุตสาหกรรมได้ปฏิบัติตาม DO-178B หรือ IEC61508 มันเน้นการทดสอบที่มีความครอบคลุมมากที่สุด แต่สามารถพบหลักฐานเล็กน้อยเกี่ยวกับประสิทธิผลของสิ่งนี้
  • Committe ในระบบรับรองที่เชื่อถือได้อย่างแน่นอนได้เผยแพร่หนังสือชื่อ "ซอฟต์แวร์สำหรับระบบที่เชื่อถือได้ - หลักฐานเพียงพอ" มันเป็นการอ้างอิงที่ดี
  • หนังสือโดยทั่วไปจะถามถึงสามสิ่ง: [1] กำหนดกฎเกณฑ์ที่ชัดเจนสำหรับการทดสอบความน่าเชื่อถือ [2] ทดสอบกับกฎ แต่ยังตรวจสอบให้แน่ใจว่าการทดสอบสามารถเข้าใจได้โดยลูกค้าปกติหรือหน่วยงานกำกับดูแลที่มีขนาดเวลาน้อยกว่าการใช้โดยนักพัฒนา [3] ตรวจสอบให้แน่ใจว่าผู้เชี่ยวชาญด้านวิศวกรรมซอฟต์แวร์และโดเมนปัญหากำลังทำการพัฒนาและทดสอบ
  • ผู้จัดหาซอฟต์แวร์ต้องยอมรับการรับประกันหรือการแก้ไขอื่น ๆ สำหรับความล้มเหลวของซอฟต์แวร์
  • ใช้ภาษาที่ปลอดภัยโดยเฉพาะไม่แนะนำให้ใช้ C. SPARK
  • การออกแบบสำหรับการทำสัญญาเป็นหนึ่งในจุดแข็งของ SPARK การออกแบบสำหรับสัญญาเป็นเทคโนโลยีที่สำคัญในการฝังการทดสอบในการเรียกใช้ฟังก์ชัน / เมธอดทุกครั้งและเรียกใช้ในรันไทม์ มากกว่ายืนยันง่ายๆ () ในวันเก่าสัญญาอาจรวมถึงการทดสอบกับความตั้งใจเชิงโครงสร้างและตรวจสอบให้แน่ใจว่าไม่มีการละเมิดสามารถถูก slipped ในครั้งต่อมาในวงจรการบำรุงรักษาเมื่อนักพัฒนาดั้งเดิมส่วนใหญ่ได้ย้ายไปยังโครงการอื่น ๆ มีหลักฐานว่าการออกแบบสำหรับสัญญาได้ผลิตผลิตภัณฑ์ซอฟต์แวร์ที่น่าเชื่อถือมาก SPARK และเครื่องมือสามารถใช้เพื่อช่วยสร้างกรณีทดสอบการรับรองเพื่อให้กระบวนการรับรองง่ายขึ้น

ตามความทรงจำของฉัน HP ฝึกออกแบบสัญญาไว้เกือบสิบปีที่แล้ว ด้วยทีมเล็ก ๆ โค้ดขนาด 500k มีรายงานข้อผิดพลาดเพียง 2 ข้อหลังการส่งมอบ ที่น่าประทับใจมาก.

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


0

พวกเขามักจะมีฮาร์ดแวร์ลูกโซ่ที่ใช้เป็นปลอดภัย

เช่นกล่องข้อความชั่วร้ายมาตรฐานที่ออกแบบมาสำหรับหุ่นยนต์นักฆ่ามักจะมาพร้อมกับสวิตช์ฆ่า: P


0

แต่ละอุตสาหกรรมมีหน่วยงานกำกับดูแลของตนเองที่มีการทดสอบและข้อกำหนดด้านเอกสารสำหรับฮาร์ดแวร์และซอฟต์แวร์ที่เกี่ยวข้องกับความปลอดภัย พิจารณา PDF นี้จาก Underwriters Laboratory (UL) ที่แนะนำมาตรฐาน UL 1998: http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

มีการอ้างอิงในเอกสารนั้นไปยังอีกมากมายที่เกี่ยวข้องจาก UL, CSA และ IEC

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.