Ariane 5의 Flight 501의 역사적 영향은 무엇입니까?

처녀 항해 ( 501 편 ) 에서 발사 된 지 37 초 후 Ariane 5 로켓의 붕괴 는 일반적으로 역사 ¹ 에서 가장 비싼 소프트웨어 버그 중 하나로 언급됩니다 .

유럽 ​​우주국 (European Space Agency)은 발사 할 때마다 3 톤 위성 쌍을 궤도로 돌릴 수있는 거대한 로켓 인 Ariane 5를 생산하는 데 10 년과 70 억 달러가 걸렸으며, 유럽이 상업 우주 사업에서 압도적 인 우위를 점하게하려고했다.

작년 6 월, 프랑스 령 기아나의 맹그로브 늪지에 불 같은 잔해가 흩어지고 1 분도 채 지나지 않아 로켓이 폭발하기 시작한 것은 64 비트 숫자를 16 비트 공간에 넣는 작은 컴퓨터 프로그램이었습니다.

하나의 버그, 하나의 충돌. 컴퓨터 과학의 연대기에 기록 된 모든 부주의 한 코드 라인 중에서이 코드는 가장 파괴적인 효율성을 보여줍니다. 로켓 전문가와의 인터뷰와 우주 기관을 위해 준비된 분석에서 산술 오류에서 전체 파괴까지 명확한 경로가 등장합니다.

Flight 501의 실패와 그에 따른 조사에서 안전에 중요한 시스템 및 소프트웨어 테스트에 대한 주요 변화는 무엇입니까?

버그 자체에 대한 설명을 찾고 있지는 않지만 버그의 조사에서 영감을 얻거나 직접 관련된 연구와 관련하여 버그의 역사적 영향에 대한 설명을 찾고 있습니다. 예를 들어이 백서 는 다음과 같은 결론을 내립니다.

정적 분석을 사용하여 다음을 수행했습니다.

• 변수 초기화 확인
• 공유 변수에 대한 잠재적 인 데이터 액세스 충돌의 전체 목록을 제공합니다.
• Ada 시맨틱의 잠재적 인 런타임 오류를 철저히 나열하십시오.

우리가 아는 한, 부울 기반 및 비 부울 기반 정적 분석 기술이 산업 프로그램의 유효성을 검증하는 데 처음으로 사용됩니다.

마찬가지로이 백서 ^(pdf) 에서는 다음 과 같이 설명합니다.

Ariane 5 Launcher의 내장 ADA 소프트웨어 및 ARD의 정적 분석에는 추상 해석 기반 정적 프로그램 분석이 사용되었습니다. 정적 프로그램 분석기는 스칼라 및 부동 소수점 오버플로, 배열 인덱스 오류, 0으로 나누기 및 관련 산술 예외, 초기화되지 않은 변수, 데이터 레이스와 같은 런타임 오류의 정의, 잠재력, 불가능 또는 액세스 불가능의 자동 감지를 목표로합니다. 공유 데이터 구조 등. 분석기는 Ariane 501 비행 오류를 자동으로 감지 할 수있었습니다. 항공 안전 소프트웨어와 같은 임베디드 안전 핵심 소프트웨어의 정적 분석은 매우 유망 합니다.

이 단일 이벤트가 소프트웨어 테스팅 접근 방식 및 툴에 미치는 영향에 대해 자세히 설명하고 싶습니다.

_{¹ 70 억 달러 규모의 수치는 Ariane 5 프로젝트의 총 비용을 의미하며 Wikipedia는이 실패로 인해 3 억 7 천만 달러 이상의 손실이 발생했다고보고했습니다. 여전히 비용이 많이 들지만 70 억 달러에 가까운 곳은 없습니다.}

기술적으로 말하자면, " 소프트웨어 썩음 " 의 경우가 더 많았습니다 . 비행 제어 소프트웨어는 이전의 Ariane 4 로켓에서 재활용되었습니다. 소프트웨어 개발 비용이 비싸기 때문에 특히 상용 소프트웨어가 대부분의 상용 소프트웨어보다 훨씬 엄격한 표준에 따라 테스트되고 검증되어야 할 때 합리적인 이동입니다.

불행히도, 운영 환경의 변화에 ​​어떤 영향을 미치는지 테스트하지 않았거나, 그렇게했을 경우 충분히 철저한 표준에 따라 테스트하지 않았다.

이 소프트웨어는 특정 매개 변수가 특정 값 (추력, 가속도, 연료 소비율, 진동 수준 등)을 초과하지 않도록 설계되었습니다. Ariane 4의 일반 비행에서는 이러한 매개 변수가 이미 눈에 띄는 잘못없이 유효하지 않은 값에 도달하지 않기 때문에 문제가되지 않았습니다. 그러나 Ariane 5는 훨씬 강력하고 4에 어리석은 것처럼 보이는 범위는 5에서 매우 쉽게 발생할 수 있습니다.

범위를 벗어난 매개 변수가 무엇인지 확실하지 않지만 (가속도 일 수 있으며 확인해야 할 것입니다), 소프트웨어를 처리 할 수 ​​없었고 산술 오버플로가 발생했습니다. 불충분 한 오류 검사 및 복구 코드가 구현되었습니다. 안내 컴퓨터는 엔진 노즐 짐 벌에 쓰레기를 보내기 시작했고, 결국 엔진 노즐을 거의 무작위로 가리 키기 시작했습니다. 로켓이 넘어지기 시작하고 자동 자체 파괴 시스템이 로켓이 안전하지 않은 태도로 감지되어 작업을 마쳤습니다.

솔직히 말해서,이 사건은 모든 종류의 시스템에서 이전에 종류의 문제가 발굴되어 왔으며 이미 오류를 발견하고 해결하는 전략이 있기 때문에 새로운 교훈을 가르치지 않았을 것입니다. 이 사건을 겪은 것은 이러한 전략을 따르는 데 허약 한 것이 엄청난 결과를 초래할 수 있다는 점을 지적하는 것이 었습니다.이 경우 수백만 달러의 파괴 된 하드웨어, 일부는 고객을 극도로 화나게하고 Arianespace의 명성에 못생긴 찌그러진 곳입니다.

돈을 저축하기위한 지름길은 돈과 명성 상실 모두에서 막대한 비용이 들기 때문에이 특별한 경우는 특히 눈에 띄었습니다. 소프트웨어가 원래 Ariane 4 용으로 개발되었을 때와 마찬가지로 Ariane 5 시뮬레이션 환경에서 강력하게 테스트 된 경우 소프트웨어가 출시 하드웨어에 설치되어 명령을 내리기 훨씬 전에 오류가 발생했을 것입니다. 실제 비행. 또한 소프트웨어 개발자가 의도적으로 소프트웨어에 넌센스 입력을 던졌다면 Ariane 4 시대에 오류가 발생했을 수 있습니다. 오류가 발생한 오류 복구가 부적절하다는 사실을 강조했기 때문입니다.

간단히 말해서, 실제로 새로운 교훈을 가르치지는 않았지만, 오래된 교훈을 기억하지 못하는 위험을 가중 시켰습니다. 또한 소프트웨어 시스템이 작동하는 환경이 소프트웨어 자체만큼 중요하다는 것도 입증했습니다. 소프트웨어가 환경 X에 대해 검증 가능하다는 것이 단지 유사하지만 별개의 환경 Y에 목적에 적합하다는 것을 의미하지는 않습니다. 마지막으로 미션 크리티컬 소프트웨어가 없어서는 안되는 상황을 처리 할 수있을 정도로 강력해야하는 것이 얼마나 중요한지를 강조했습니다. 일어난.

501 편과 아폴로 11 편, 그리고 컴퓨터 문제를 대조하십시오. LGC 소프트웨어는 착륙 중 심각한 결함으로 고통을 받았지만, 우주 비행사를 위험에 빠뜨리지 않고 트리거 할 수있는 소프트웨어 경보에도 불구하고 매우 견고하고 작동 상태를 유지할 수있었습니다. 임무를 완료하십시오.

주로 재사용 문제 및 관리 문제였으며 코딩 문제는 아닙니다. 이 보고서에 대한 회상 (아마도 잘못된 점이 있습니다)에서.

• 하나의 하위 시스템은 Ariane IV 용으로 설계되었습니다. Ariane IV의 궤적은 오버플로를 초래할 수 없었으며, 이것이 발생하면 하드웨어 문제이고 서브 시스템을 종료하고 여분으로가는 것이 옳은 일이라고 의도적으로 결정되었습니다.

• Ariane V의 경우, 해당 서브 시스템을 재사용하고 가정 및 코드를 검토하지 않고 테스트에 의존하기로 결정했습니다.

• 또한 전체 테스트를 중단하기로 결정했습니다.

Ariane V의 다른 비행 매개 변수로 오버플로가 발생했습니다. 기본을 종료하십시오. 스페어를 종료하십시오. 자동 파괴.

내가 기억하는 다른 것들 :

• 오버 플로우 시점의 서브 시스템은 더 이상 유용하지 않았습니다. 실패로 인해 자동 파괴가 발생해서는 안된다고 주장 할 수 있습니다. 반면에 추가 된 복잡성 자체가 문제의 원인이 될 수 있습니다.

• 버스로 보내 져서는 안될 디버그 데이터가 버스에 전송되었습니다. 구체적인 내용이 기억 나지 않습니다.

다른 사람들이 언급했듯이, 산업계는 일반적으로 재사용 개념을 재검토하고 구성 요소를 개별적으로 평가하지 않고 전체 시스템의 맥락에서 평가하는 더 큰 기준 틀에 배치했습니다. 구성 요소를 변경하지 않고 재사용 할 수 있어도 새로운 가정을 사용하여 분석해야하기 때문에 재사용의 매력이 크게 줄어 듭니다. 또 다른 결론은 동일한 소프트웨어를 실행하는 백업 하드웨어가 거의 매력적이지 않다는 것입니다. 대부분의 최신 하드웨어는 최신 소프트웨어보다 훨씬 안정적입니다. 일부 방어 계약에는 적절한 구현을 확인하기 위해 동일한 사양에서 작동하는 다른 기술을 사용하여 서로 다른 팀이 개발 한 두 개의 별도 소프트웨어 시스템이 필요하다고 들었습니다.