항전 소프트웨어

Avionics software

항전 소프트웨어는 항전기에 사용되는 법적 의무의 안전성과 신뢰성에 관한 문제가 있는 임베디드 소프트웨어다. 항전소프트웨어와 기존 임베디드소프트웨어의 주요 차이점은 개발과정이 법으로 요구되고 안전에 최적화돼 있다는 점이다. 아래에 기술된 프로세스는 상용 소프트웨어에 사용되는 일반적인 특별 프로세스보다 약간 느리고 비용이 더 많이 든다고 주장한다(아마도 15퍼센트). 대부분의 소프트웨어가 실수로 인해 실패하기 때문에 가능한 한 빨리 실수를 없애는 것도 소프트웨어를 생산하는 비교적 저렴하고 신뢰할 수 있는 방법이다. 그러나 일부 프로젝트에서는 사양의 실수가 배치될 때까지 감지되지 않을 수 있다. 그 때, 그것들은 고치는데 매우 비쌀 수 있다.

모든 소프트웨어 개발 모델의 기본 개념은 설계 프로세스의 각 단계에 "전달 가능"[citation needed]이라고 불리는 산출물이 있다는 것이다. 만약 그 결과물들이 정확하고 고정되어 있다면, 정상적인 인간의 실수는 위험하거나 값비싼 문제들로 쉽게 자라날 수 없다. 대부분의 제조업체는[citation needed] 설계 제품을 조정하기 위해 폭포 모델을 따르지만, 거의 모든 제조업체는 이전 작업의 수정을 명시적으로 허용한다. 결과는 나선형 모델에 더 가까운 경우가 많다.

임베디드 소프트웨어의 개요는 임베디드 시스템 및 소프트웨어 개발 모델을 참조하십시오. 이 글의 나머지 부분은 그 정보에 익숙하다고 가정하고 상업용 임베디드 시스템과 상업용 개발 모델 간의 차이를 논한다.

일반 개요

대부분의 항전 제조업체가 소프트웨어를 가중치 없이 가치를 더하는 방법으로 보기 때문에 항전시스템에 임베디드 소프트웨어의 중요성이 높아지고 있다.

오토 파일럿을 탑재한 현대 상용 항공기는 대부분 비행 컴퓨터, 이른바 비행 관리 시스템(FMS)을 사용해 특정 비행 단계에서 조종사의 적극적인 개입 없이 항공기를 조종할 수 있다. 또한 개발 중이거나 생산 중에 있는 무인 차량도 있다: 비행 조종사의 개입 없이 이륙, 순항, 착륙할 수 있는 미사일과 드론이다.

이 시스템들 중 많은 곳에서, 실패는 용납될 수 없다. 공수차량(민간 또는 군사)에서 운행하는 소프트웨어의 신뢰성은 대부분의 공수사고가 수동 오류로 발생한다는 사실에서 알 수 있다. 불행히도 신뢰할 수 있는 소프트웨어가 반드시 사용하기 쉽거나 직관적이지 않은 사용자 인터페이스 설계가 많은 항공우주 사고와 사망의 원인이 되어왔다.[citation needed]

규제 이슈

안전 요건으로 인해 대부분의 국가는 항전학을 규제하거나, 동맹국 또는 관세동맹이 사용하는 표준을 채택한다. 국제 항공 발전에 가장 큰 영향을 미치는 세 가지 규제 기관은 미국, EU, 러시아다.

미국의 경우 항전 및 기타 항공기 구성요소는 연방항공규정(Federal Aviation Regulations), 수송기는 Part 25, 소형기는 Part 23, 로터크래프트는 Part 27 및 29가 위임한 안전성과 신뢰성 표준을 가지고 있다. 이 표준은 FAA의 "지정된 엔지니어링 대표자"에 의해 시행되며, FAA는 보통 제조사가 지불하고 FAA의 인증을 받는다.

유럽 연합에서 IEC는 안전 중요 시스템에 대한 "권장" 요건을 기술하고 있으며, 이러한 요건은 대개 정부에 의해 변경되지 않고 채택된다. 안전하고 신뢰할 수 있는 항전술에는 "CE 마크"가 있다. 규제안정은 미국과 캐나다의 화재안전과 현저히 유사하다. 정부는 시험소를 인증하고, 실험실은 제조된 품목과 단체 모두를 인증한다. 본질적으로, 공학에 대한 감시는 정부와 제조업체에서 시험소로 아웃소싱된다.

안전성과 신뢰성을 확보하기 위해 국가 규제 당국(예: FAA, CAA 또는 DOD)은 소프트웨어 개발 표준을 요구한다. 대표적인 표준으로는 군사 시스템을 위한 MIL-STD-2167 또는 민간 항공기를 위한 RTCA DO-178B와 그 후속 DO-178C가 있다.

이 소프트웨어에 대한 규제 요건은 다른 소프트웨어에 비해 비용이 많이 들 수 있지만, 일반적으로 필요한 안전성을 생산하는데 필요한 최소한의 요건이다.

개발공정

항전 소프트웨어와 기타 임베디드 시스템의 주요 차이점은 실제 표준이 상용 표준보다 훨씬 상세하고 엄격한 경우가 많으며, 보통 수백 페이지의 문서로 기술된다. 그것은 보통 실시간 운영 체제에서 실행된다.

그 과정이 법적으로 요구되기 때문에 대부분의 프로세스에는 규격과 설계에 번호가 매겨진 단락부터 정확한 코드 조각까지 요구사항을 추적할 수 있는 문서나 소프트웨어가 있으며, 각각에 대한 정확한 테스트와 최종 인증 체크리스트에 박스가 있다. 이것은 특히 법적으로 의무화된 기준을 준수함을 증명하기 위한 것이다.

대체 방법의 사용 또는 낮은 안전 수준 요구 사항으로 인해 특정 프로젝트에서 여기에 설명된 프로세스로의 편차가 발생할 수 있다.

거의 모든 소프트웨어 개발 표준은 사양, 설계, 코딩 및 테스트를 수행하는 방법을 기술한다(소프트웨어 개발 모델 참조). 그러나 항전 소프트웨어 개발 표준은 안전과 인증을 위한 개발에 다음과 같은 단계를 추가한다.

휴먼 인터페이스

상당한 인적 인터페이스를 가진 프로젝트는 일반적으로 프로토타입 제작 또는 시뮬레이션된다. 비디오테이프는 보통 보관되지만, 시제품은 시험 후 즉시 폐기된다. 그렇지 않으면 고위 경영진과 고객들은 시스템이 완성되었다고 믿을 수 있기 때문이다. 안전과 가용성에 영향을 미칠 수 있는 인적 인터페이스 문제를 찾는 것이 주요 목표다.

위험분석

안전 중요 항전술은 보통 위험 분석을 한다. 프로젝트의 초기 단계들, 적어도 프로젝트의 주요 부분들에 대한 막연한 생각은 이미 가지고 있다. 한 엔지니어가 블록 다이어그램의 각 블록을 가지고 그 블록에 잘못될 수 있는 사항과 그것들이 시스템 전체에 어떤 영향을 미치는지 고려한다. 이후 위험의 심각성과 확률을 추정한다. 그러면 문제는 설계 규격에 부합하는 요건이 된다.

군사 암호 보안과 관련된 프로젝트는 일반적으로 위험 분석과 같은 방법을 사용하여 보안 분석을 포함한다.

유지보수 매뉴얼

엔지니어링 사양서가 완성되는 대로 유지보수 매뉴얼 작성을 시작할 수 있다. 수리에는 정비 매뉴얼이 필수적이며, 물론 시스템을 고칠 수 없다면 안전하지 않다.

대부분의 기준에는 몇 가지 수준이 있다. 기내 엔터테인먼트 장치(날아다니는 TV)와 같은 안전성이 낮은 제품은 설치와 조정을 위한 개략도와 절차를 가지고 탈출할 수 있다. 항법 시스템, 자동 조종 장치 또는 엔진은 수천 페이지의 절차, 검사 및 연결 지침을 포함할 수 있다. 현재(2003) 문서는 텍스트와 그림을 포함하는 표준 형식으로 CD-ROM으로 일상적으로 전달된다.

더 이상한 문서 요구사항 중 하나는 대부분의 상업적 계약에서 시스템 문서를 무한정 사용할 수 있다는 보증을 요구한다는 것이다. 이러한 보증을 제공하는 일반적인 상업적 방법은 작은 재단이나 신탁을 형성하고 자금을 조달하는 것이다. 그러면 신탁은 우편함을 보관하고 (보통 울트라피체어로) 대학의 도서관의 임대 공간(특별한 수집으로 관리)이나 (지금은 더 드물게) 동굴이나 사막의 장소에 묻혀 있는 것과 같은 안전한 장소에 사본을 보관한다.[1]

설계 및 사양 문서

이것들은 보통 다른 소프트웨어 개발 모델의 그것들과 많이 비슷하다. 중요한 차이점은 요구사항은 대개 위에서 설명한 대로 추적된다는 것이다. 대규모 프로젝트에서 요구사항 추적성은 그것을 관리하기 위해 크고 값비싼 컴퓨터 프로그램이 필요할 정도로 큰 비용이 드는 작업이다.

코드 제작 및 리뷰

코드는 작성되었다가, 대개 원래 작성하지 않은 프로그래머(또는 프로그래머 그룹, 대개 독립적으로)에 의해 검토된다(다른 법적 요건). 특수기관도 대개 발생할 수 있는 실수요자의 체크리스트를 가지고 코드 검토를 실시한다. 새로운 유형의 실수가 발견되면 체크리스트에 추가되고 코드 전체에 걸쳐 수정된다.

이 코드는 SPAK(Ada 프로그래밍 언어의 부분집합)용 SPAK 검사기 또는 프로그래밍 언어의 C-패밀리(주로 C, 그러나)용 보풀과 같이 정확성을 분석하는 특수 프로그램(정적 코드 분석)에 의해서도 종종 검사된다. 컴파일러 또는 "lint"와 같은 특별 검사 프로그램은 데이터 유형이 해당 데이터의 작동과 호환되는지 여부를 검사하며, 또한 그러한 도구는 유효한 프로그래밍 언어 하위 집합과 프로그래밍 스타일을 엄격하게 사용하는 데 정기적으로 사용된다. 또 다른 프로그램 세트는 소프트웨어 측정 기준을 측정하여 오류가 있을 가능성이 있는 코드 부분을 찾는다. 모든 문제들은 고정되어 있거나, 적어도 이해되고 재확인되어 있다.

디지털 필터, 그래픽 사용자 인터페이스, 관성 항법 시스템과 같은 일부 코드는 소프트웨어 도구를 개발하여 소프트웨어를 작성하게 할 정도로 잘 이해된다. 이 경우 사양이 개발되고 신뢰할 수 있는 소프트웨어가 자동으로 생산된다.

단위시험

"유닛 테스트" 코드는 코드의 모든 지침을 한 번 이상 연습하여 100% 코드 커버리지를 얻도록 작성된다. "범위" 도구는 종종 모든 지침이 실행되었는지 검증하기 위해 사용되며, 그 후에 법적 이유로 시험 범위도 문서화된다.

이 테스트는 가장 강력한 테스트 중 하나이다. 프로그램 로직의 상세한 검토를 강요하고, 대부분의 코딩, 컴파일러 및 일부 설계 오류를 검출한다. 일부 조직은 소프트웨어 설계를 모듈 사양으로 사용하여 코드를 작성하기 전에 단위 테스트를 작성한다. 단위 시험 코드가 실행되어 모든 문제가 해결된다.

통합 테스트

코드 조각이 사용 가능해짐에 따라 코드 조각에 추가되고 각 인터페이스가 제대로 작동하는지 확인하기 위해 제자리에 테스트된다. 일반적으로 전자제품의 내장 테스트는 전자제품의 연소 및 무선 방출 테스트를 시작하기 위해 먼저 완료되어야 한다.

다음으로 소프트웨어의 가장 가치 있는 기능이 통합된다. 통합업체들은 간단한 메뉴 시스템으로부터, 아마도 선택된 작은 코드 조각들을 실행할 수 있는 방법을 갖는 것이 매우 편리하다.

일부 프로그램 관리자들은 최소한의 기능이 달성된 후 시스템이 시간이 지남에 따라 기능 수가 증가하면서 다음 날짜에 제공될 수 있도록 이러한 통합 프로세스를 마련하려고 한다.

블랙박스 및 합격시험

한편, 시험 엔지니어는 보통 시험 장비 조립을 시작하고 소프트웨어 엔지니어가 사용하기 위한 예비 시험을 발표한다. 어느 시점에서는 이 테스트가 엔지니어링 사양서의 모든 기능을 다룬다. 이때 항전 단위 전체의 시험이 시작된다. 합격 시험의 목적은 장치가 작동 중 안전하고 신뢰할 수 있음을 입증하는 것이다.

소프트웨어의 첫 번째 시험이며, 빡빡한 스케줄에서 가장 만나기 어려운 시험 중 하나는 유닛의 무선 방출에 대한 현실적인 시험이다. 이는 일반적으로 전자 설계에 필요한 변경을 할 수 있는 시간이 있음을 보장하기 위해 프로젝트 초기에 시작되어야 한다. 소프트웨어는 또한 테스트를 실행하고 코드 커버리지를 수집 및 분석하는 구조적 커버리지 분석을 받는다.

인증

각 단계는 문서, 코드 또는 시험 보고서를 작성할 수 있다. 소프트웨어가 모든 테스트(또는 안전하게 판매될 수 있을 정도로)를 통과하면, 이러한 테스트들은 말 그대로 수천 페이지를 가질 수 있는 인증 보고서에 묶여 있다. 완공을 위해 노력해온 지정 엔지니어링 담당자가 그 결과의 허용 여부를 결정한다. 만약 그렇다면, 그는 그것에 서명하고, 항전 소프트웨어는 인증을 받았다.

참고 항목

참조

  1. ^ 개인 정보, Robert Yablonsky, 엔지니어링 관리자, B.E. Aerospace, Irvine, CA, 1993년

외부 링크