중요한 생명 또는 죽음의 시스템에서 사용되는 소프트웨어는 어떻게 테스트됩니까?

예를 들어 웹 사이트와 달리 비행기는 비행 모니터링과 같은 오류로 인해 자동 조종 장치가 오작동하여 다이빙을 할 수 있기 때문에 특정 시스템의 모든 고장을 완전히 수용 할 수없는 시스템입니다. Boeing과 Airbus의 뛰어난 엔지니어가 자동 조종 장치를 점검하여 다이빙이 완벽하게 수용 가능하고 안전한 기동임을 갑자기 결정하지 않도록하기 때문에 분명히 이런 일이 발생하지 않습니다. 또는 컴퓨터가 충돌하여 최신 플라이 바이 항공기의 조종사 가 더 이상 비행기를 조종 할 수 없습니다. 물론, 이러한 시스템에는 소프트웨어와 항공기의 충돌을 방지하기 위해 다양한 안전 절차와 중복성이 내장되어 있습니다.

그러나 소프트웨어가 완벽하지 않다는 것은 명백합니다. 오픈 소스 및 폐쇄 소스 소프트웨어는 정기적으로 충돌하며 가장 단순한 "Hello World"프로그램 만 실패하지 않습니다. 항공, 의료 및 기타 생명 또는 사망 산업에서 소프트웨어 시스템을 설계하는 엔지니어는 어떻게 소프트웨어가 실패하지 않도록 (그리고 실패하면 최소한 정상적으로 실패) 소프트웨어를 테스트 할 수 있습니까?

_{"오, 나는 보잉 / 에어 버스 / (일부 다른 회사)에서 일하지만 그렇지 않습니다! 다음 비행기 / 병원 방문에서 재미있게 지내십시오."}

산업용 제어에서 많은 작업을 수행했습니다. 항공 우주와 같은 영광스러운 산업에있을 필요는 없습니다. 거의 모든 산업 기계에는 심각한 부상이나 사망을 유발할 수있는 충분한 잠재적 에너지가 있습니다. 사람들이 다쳤을 때 주변에있었습니다. 대부분의 시간을 사무실의 책상에서 보내면 대부분의 공장 작업이 얼마나 위험한 지에 대해 놀랄 것입니다 (그리고 최근까지도). 이제 더 나은 기계 보호 방법이 있습니다. 실제 사용 방법은 다음과 같습니다 (관할 지역마다 다름).

미국에는 OSHA 표준이 있으며 EU에는 비슷한 (보통 더 엄격한) 지침이 있습니다. 이는 일반적으로 위험 분석을 요구하여 시작됩니다. 즉, 위험에 노출되는 빈도, 위험을 피하는 것이 얼마나 쉬운 지 (속도에 따라 등)를 고려하여 모든 위험 목록을 작성한 다음 해당 위험을 분류합니다. 결과의 심각도입니다 (절단, 절단, 사망 등).

많은 분석은 보호 위험과 관련이 있습니다. 기계 주위에 큰 케이지를 넣고 단단히 조이면 기계의 구성 요소가 보호 장치를 위반할 수없는 경우 기계가 안전하다고 간주됩니다. 들어올 도구가 필요한 경우 유지 관리 작업으로 간주되며 유지 관리 담당자는 기계에서 안전하게 작업하는 방법에 대해 교육을 받아야합니다. 그러나 실제로 대부분의 기계는 작업자와 정기적으로 상호 작용해야하므로 경비실이나 라이트 커튼 등에 액세스 도어를 배치해야합니다. 이러한 도어와 라이트 커튼을 모니터링하고 작업자가 자신에게 노출시키는 위험에 대한 힘을 모니터링해야합니다. "신뢰할 수있는 제어"방식으로 차단해야합니다.

이 분석을 기반으로 위험은 다양한 범주로 분류됩니다. 일반적인 분류 척도는 카테고리 1 ~ 카테고리 4입니다 (EN 954-1 표준 기준). 이러한 범주에 따라 법적으로 특정 수준의 기계 보호 및 안전을 제공해야합니다.

예를 들어 카테고리 4에는 다음이 필요합니다.

이러한 각 부품의 단일 결함으로 인해 안전 기능이 손실되지는 않습니다.

안전 기능에 대한 다음 요청과 함께 또는 그 이전에 단일 결함이 감지되거나, 이것이 불가능한 경우 결함이 누적되면 안전 기능이 손실되지 않을 수 있습니다.

실제로는 달성하기 어려울 수 있지만 카테고리 4로 인증 된 표준 구성 요소의 가용성으로 인해 더 간단 해집니다. 예를 들어, 이러한 시스템의 일반적인 구성 요소 중 하나는 안전 릴레이입니다. 다음은 기계식 릴레이 그 이상입니다.

• 이중 중복 입력 채널을 모니터링하도록 설계되었으므로 가드 도어 열림과 같은 오류 상태를 감지하는 센서가있는 경우 일반적으로 이중 회로와 2 개의 접점이 있습니다. 릴레이는 두 채널을 모두 모니터링하며 둘 중 하나가 열리면 액츄에이터의 전원이 끊어 지지만 동시에 둘 다 떨어지지 않으면 고장 상태가되어 수리 할 때까지 기계를 다시 시작할 수 없습니다 .
• 릴레이는 또한 해당 라인에서 전기 펄스를 사용하고 해당 신호를 사용하여 교차 또는 단락 된 와이어를 모니터링하므로 배선 결함을 감지 할 수 있습니다.
• 출력 측에서는 출력 코일을 구동하기 위해 이중 회로 세트를 사용하므로 하나의 오류가 "온"상태 인 경우 다른 하나는 출력에 전원이 공급되지 않도록해야합니다. 또한 이들을 모니터링하고 오류가 감지되면 작동을 방해합니다. 코일 자체는 실제로 출력에서 ​​중복 물리 계전기를 의미하는 이중 힘 유도 계전기이며, 각 단일 계전기의 접점이 물리적으로 서로 연결되어 4 개 중 하나의 접점이 저절로 고착 될 수 없도록합니다. 이것들도 모니터링됩니다.
• 또한 제어하고있는 부하에서 보조 폐쇄 접점을 모니터링하는 입력도 포함합니다. 출력을 끄면 정상적으로 닫히는 접점 결합을 확인해야합니다. 즉, 모터 접점기를 끄거나 온 상태로 다시 작동하기 전에 모터 접점 기의 전원이 꺼져 있는지 확인합니다.

알다시피, 이들은 복잡한 장치입니다. 일반적인 비용은 각 안전 릴레이마다 $ 200 ~ $ 600입니다. 분명히 이러한 장치에는 소프트웨어가 있습니다. 안전 릴레이 인증을 받으려면 일반적으로 다음과 같은 디자인을 따라야합니다.

• 서로 다른 설계에 따라 일반적으로 서로 다른 공급 업체에서 제공하는 2 개의 중복 프로세서.
• 각 프로세서에서 실행되는 코드는 격리 된 조건에서 작업하는 두 팀이 개발해야합니다. 이는 단일 소프트웨어 버그가 단일 장애 지점이되는 것을 방지합니다.
• 두 프로세서의 출력은 안전 릴레이 결함에 동의해야합니다.

안전 등급의 구성 요소를 사용하여 기계의 안전 시스템을 설계 한 후에는 전문 엔지니어가 설계를 검토하고 도장을 받아야합니다. 그런 다음 머신을 빌드합니다. 그런 다음 P.Eng. 기계의 설계를 검토하여 설계에 맞게 설계되었는지 확인합니다. 그들은 그것을 문서화하고 예상대로 작동하는지 확인하기 위해 몇 가지 테스트를 수행합니다. 이를 사전 심사 검토 (PSR)라고하며 모든 관할 구역에서 수행되는 것은 아닙니다. PSR이 지나면 운영자가 기계를 작동하게 할 수 있습니다.

최근 몇 년 동안 안전 시스템에 몇 가지 혁명이있었습니다. 한동안 아무도 네트워크를 통해 안전 데이터 전송을 신뢰하지 않았기 때문에 일반적으로 DeviceNET 및 EtherCAT과 같은 "분산 I / O 시스템"은 시스템의 안전 부분에서 허용되지 않았습니다. 그러나 최근의 프로토콜은 이제 안전 장치가 이러한 산업용 네트워크를 통해 실행될 수 있도록합니다. 프로토콜은 타임 스탬프 된 메시지와 연결의 양쪽 끝에서 이중 중복 처리를 사용합니다.

세이프티 릴레이는 기능 블록 다이어그램 언어로 세이프티 로직을 구축하는 방법과 같이 더 복잡한 세이프티 PLC로 대체 된 dodo bird의 길을 천천히 가고 있습니다. 다시,이 안전 PLC는 모든 것을 중복 사용합니다. 프로그램이 승인되면 기계를 수리하기 전에 P.Eng. 프로그램을 스탬프 처리하고 프로그램 / PLC가 암호로 잠 깁니다. 또한 프로그램의 해시가 필요하며 해시는 문서에 기록됩니다 (P.Eng.가 실제로 스탬핑하는 것).

안전 시스템을 설계 한 후에는 기계 자체를 제어하기 위해 작성하는 논리가 매우 중요합니다. 프로그래머는 종종 기계를 충돌시켜 수천 달러의 피해를 입지 만 적어도 아무도 다 치지 않을 것입니다.

무작위 기능 테스트보다는 공식적인 검증으로 진지한 움직임이 있습니다.

NASA와 같은 정부 기관 및 일부 방어 기관은 이러한 기술에 점점 더 많은 돈을 쓰고 있습니다.

여전히 일반 프로그래머에게는 PITA이지만 중요한 시스템을 테스트하는 데 더 효과적입니다.

멀티 스레드 코드 검증과 같은 것들을 위해 학계에서 더 많은 기술을 시도하는 경향도 있습니다.

소프트웨어가 무엇인지에 따라 다릅니다. 예를 들어, 평면에서는 일반적으로 중요한 시스템에 대한 이중 중복 처리가 있습니다. 극단적 인 경우에는 서로 다른 2 개의 하드웨어 디자인과 각각 독립적으로 개발 된 2 개의 S / W 조각이 사용될 수 있습니다. 그들은 서로를 계산하고 교차 점검합니다. 이것은 절대가 아니며 매우 비쌉니다.

항공기 시스템 테스트와 관련하여 일련의 테스트가 수행됩니다. 비행 관련 시스템 테스트에는 몇 개월이 걸리며, 변경 사항이있을 경우 전체 테스트를 다시 실행해야합니다. 이것은 일반적으로 시뮬레이터에서 이루어지며, 실제로 시뮬레이션 된 엔진 또는 이와 유사한 것으로 실제 항공기 부품 (예 : 조종석)으로 가득 차있을 수 있습니다. 당신이 상상할 수 있듯이, 이것은 또한 건축 비용이 엄청나게 비쌉니다. 공식 테스트 프로그램을 기준으로 변경 사항을 평가 한 다음 테스트 비행 중에 실제 항공기에서 실행합니다. "방해 기능"테스트와 같은 것들이 실행되는 동안, 이것은 변경된 항목이 정상적인 작업을 수행하도록 허용되는 곳이며 모든 것이 유해한 영향이 없는지 확인 / 테스트됩니다. 비용도 많이 들고 몇 주가 걸릴 수 있습니다.

나는 비행 시스템에 대한 아주 간단한 변경이 필요한 한 가지 예를 알고 있습니다. 그래서 당신은 얼마나 작은 지 놀랄 것입니다. 그러나 이것의 재시험은 3 개월 이상 걸리고 1 백만 달러와 같은 비용이 든다.

의료 분야에 들어가면 테스트뿐만 아니라 개발 프로세스 및 문서와 관련된 일련의 규제 장애물이 있습니다.

이 모든 필드는 웹 사이트에 대한 약간의 PHP 코드를 쏟아 붓는 곳에서 크게 발전했습니다. 느리고, 힘들고, 힘들고, 지루하고, 지루하고, 꼼꼼하고, 매우 비싸다. 일반적인 개발 / 테스트 비용을 가져다가 약 100을 곱하면 한계에 가까워지고 있습니다.

NASA 우주 왕복선 소프트웨어의 경우 올바른 자료 작성을 읽으십시오 . FDA (미국 식품 의약품 안전청)는 다음 내용을 읽으십시오.

당신은 이미 충분히 유익하고 유익한 답변을 얻었으므로 여기에 내가 가져갑니다.

간단합니다. 첫 번째 테스트는 항상 프로그래머 스스로 수행합니다. 버그 카운트를 낮게 유지하는 경향이 있으며, 양질의 프로그래머 만 급여를 유지하도록합니다.

생명에 중요한 소프트웨어는 모든 곳에서 수행되므로 "작동하는 것" 이외의 다른 표준으로 테스트되지 않습니다 .

모든 투자는 비 프로그래머가 더 나은 소프트웨어 를 생산할 수 있도록 프로젝트 이전 이나 프로젝트에 효과가 있었던 것으로 간주됩니다 .

추신 첫 번째에 대한 의견은 -1없지만 -1내 진술에 반하는 각 참고 문헌에 대해 기꺼이 취하겠습니다 .

잘 설계되거나 테스트되지 않은 중요한 소프트웨어에 대한 모든 참조에 대해 +1을 사용할 수 있습니까? Simson Garfinkel 은 유선에 관한 기사에서 10 건의 사례 를 문서화했습니다 .

모든 경우에 대한 답변이 하나도 없습니다. 소프트웨어를 설계하고 테스트하는 방법을 결정하는 것은 개별 제조업체의 책임입니다. 그러나 전체 소프트웨어 개발 프로세스는 공식 사양을 준수해야합니다.

예를 들어 의료 기기 용 소프트웨어를 만들 때 의료 기기 용 소프트웨어에 대한 IEC 62304 표준을 따라야합니다 . (불행히도 Wikipedia는 무료가 아니기 때문에 wikipedia에만 연결할 수 있습니다). 전 세계 거의 모든 국가에서이 표준을 준수해야합니다.

이러한 요구 사항이 얼마나 엄격한지는 피해 위험에 따라 다릅니다. 예를 들어, 생명 유지 장치는 해를 입을 위험이 가장 클 것입니다 (시스템이 고장 나면 사망).

그러나 이것이 기본적으로 말하는 것은 요구 사항에서 소프트웨어까지 추적 성이 있어야한다는 것입니다. 소프트웨어 단위 확인을 수행해야합니다. 검증이 무엇인지 지정하지 않습니다. 단위 테스트, 코드 검토가 가능합니다. 위험도가 높은 장치의 경우 소프트웨어 장치 간의 인터페이스를 수동으로 검토해야합니다 (내가 이해하고 기억하는 한). 물론 다른 많은 규칙들도 있습니다. 아, 그리고 당신은 당신의 작업을 문서화하기 위해 많은 문서를 작성해야합니다.

표준은 민첩한 개발을 금지하지 않지만, 읽을 때 폭포 개발을 염두에두고 작성된 것처럼 보입니다.

항공, 기차, 자동차 등과 같은 다른 소프트웨어 개발 영역에 대해서는 잘 모르지만 다른 유사한 공식 지침이 존재한다고 가정합니다.

다음을 포함한 많은 기술이 사용됩니다.

• 공식적인 설계 및 / 또는 검증
• 메모리의 동적 할당과 같은 고급 프로그래밍을 피하는 엄격한 코딩 표준
• 매우 까다로운 품질 엔지니어
• 코드 검토, 결함 트리, FMECA 등과 같은 많은 정적 분석 기술

그러나 최고의 기술은 다음과 같습니다.

• 테스트

우주선의 소프트웨어는 우선 디자인하고 코딩하는 것보다 테스트하는 데 더 많은 노력이 필요합니다.

항공기는 비행기가 극한 상황에 처한 수년간의 비행 테스트를 거칩니다. 이것은 물리적 구조뿐만 아니라 소프트웨어도 테스트합니다.

Jack Ganssle의 EETimes에 2009 년 3 월 1 일 12:00 AM EST 기사 "완벽한 소프트웨어"가 있습니다. 거기에서 몇 가지 점 :

• "이론적으로, 소프트웨어는 완벽 할 수있는 유일한 구성 요소이며, 이것이 항상 우리의 출발점이어야합니다." -제시 푸어가 말 했어요. 그의 웹 페이지에 따르면 일반적인 소프트웨어보다 더 많은 비용을 들이지 않고도 완벽한 소프트웨어를 만드는 방법을 알 수 있습니다.
• 매우 안정적인 OS를 제공하는 산업 공급 업체가 있습니다. 이 기사에서는 Mircrium과 Green Hills에 대해 언급했습니다. Micrium의 웹 페이지에는 인증 표준 목록이 있습니다. 그것들은 업계가 따르는 프로세스와 규칙이어야합니다. 그것은 공식적인 검증을 기반으로하지만 이론에서 많이 벗어났습니다.

흥미롭게도 상용 소프트웨어와 관련하여 Capers Jones가 수집 한 데이터는 "일반적으로 소프트웨어는 결함 제거 효율성 (출하 전에 제거 된 버그의 비율)이 87 %이며 펌웨어는 94 %로 훨씬 우수합니다." 나에게는 이것들 중 어느 것도 완벽하지 않습니다. 이전 답변자가 언급 한 기사에 따르면 NASA 우주 왕복선 팀은 99 %의 버그 제거율을 달성했지만 비용은 약 4 억 라인의 코드 당 연간 3 천 5 백만에 달합니다.

같은 저자가 2009 년 11 월 1 일에 작성한 "신뢰할 수있는 시스템 용 소프트웨어"라는 기사가 더 관련성이 높은 것으로 보입니다. 다음과 같이 요약 할 수 있습니다.

• 개발 과정에서 업계는 DO-178B 또는 IEC61508을 준수했습니다. 커버리지가 가장 큰 테스트를 강조합니다. 그러나 이것의 효과에 대한 증거는 거의 없습니다.
• 인증 기관인 신뢰할 수있는 신뢰할 수있는 소프트웨어 시스템에 대한위원회는 "신뢰할 수있는 시스템 용 소프트웨어-충분한 증거"라는 제목의 책을 ​​출판했습니다. 좋은 참조입니다.
• 이 책은 기본적으로 다음 세 가지를 요구합니다. [1] 신뢰성 테스트를위한 명확한 규칙을 만듭니다. [2] 규칙에 대한 테스트뿐만 아니라 개발자가 사용하는 것보다 훨씬 적은 시간으로 일반 고객 또는 규제 기관이 테스트를 이해할 수 있는지 확인하십시오. [3] 소프트웨어 엔지니어링 및 문제 영역의 전문가가 개발 및 테스트를 수행하고 있는지 확인하십시오.
• 소프트웨어 공급 업체는 소프트웨어 장애에 대한 보증 또는 기타 구제책을 약속해야합니다.
• 특히 C가 아닌 안전한 언어를 사용하십시오. SPARK를 권장합니다.
• 계약 방식 설계는 SPARK의 강점 중 하나입니다. 계약 설계는 모든 함수 / 메소드 호출에 테스트를 포함하고 항상 런타임에 테스트를 실행하는 중요한 기술입니다. 예전에는 단순한 assert () 이상으로 계약에는 구조적 의도에 대한 테스트가 포함되어 있으며 원래 개발자가 주로 다른 프로젝트로 이동했을 때 유지 관리주기에서 나중에 위반이 발생하지 않도록 할 수 있습니다. 계약 설계가 매우 안정적인 소프트웨어 제품을 생산했다는 증거가 있습니다. SPARK 및 해당 도구를 사용하여 인증 테스트 사례 생성을 지원하여 인증 프로세스를 단순화 할 수 있습니다.

내 기억에 따르면 HP는 거의 10 년 전에 계약을위한 설계를 수행했습니다. 작은 팀, 5 만 줄의 코드를 사용하면 배송 후 2 개의 버그만보고됩니다. 매우 인상적.

제 생각에는 신뢰할 수 있거나 완벽한 소프트웨어는 비용이 엄청나게 높지 않은 경우에만 달성 할 수 있습니다. 프레임 워크 또는 자동화는 필수입니다.

일반적으로 페일 세이프로 사용되는 하드웨어 인터록 이 있습니다.

예를 들어 킬러 로봇을위한 표준 악의 텍스트 상자 디자인에는 항상 킬 스위치가 있습니다.

각 산업에는 안전 관련 하드웨어 및 소프트웨어에 대한 테스트 및 문서 요구 사항이있는 자체 규제 기관이 있습니다. UL 1998 표준을 소개하는 Underwriters Laboratory (UL)의이 PDF를 고려하십시오. http://www.ul.com/global/documents/offerings/industries/hightech/software/UL_softwareconformityassessment.pdf

이 문서에는 UL, CSA 및 IEC의 다른 많은 관련 문서가 있습니다.

일반적으로 안전 관련 소프트웨어에는 중복 하드웨어 회로가 있거나 안전한 작동 및 안전 장애 모드를 보장하기 위해 다른 중복 제어 기능이 필요합니다.