문서요약 - 고위험 및 고임무 우주항공 소프트웨어의 인증 프로세스 by Nelson

제목: 고위험 및 고임무 우주항공 소프트웨어의 인증 프로세스(Certification Processes for Safety-Critical and Mission-Critical Aerospace Software)

저자: Stacy Nelson, ARC/Nelson Consulting, 미국

문서유형: 기술 보고서(총 36 페이지), 2003년

 

미항공우주국(NASA)과 미연방항공국(FAA)에서 고위험(safety-critical) 또는 고임무(mission-critical) 비행 소프트웨어를 인증하는 프로세스를 소개한 자료

---

핵심 용어 정의

• 인증(Certification): 소프트웨어 제품이 요구사항에 부합함을 인증 기관이 공식적으로 인정
• 고임무(Mission-critical): 소프트웨어 문제가 본연의 임무 완수를 못하게 할 수 있음(예, 무인 우주선)
• 고안전(Safety-critical): 소프트웨어 문제가 인명 피해를 줄 수 있음(예, 원자로, 자동차, 화학 공장, 항공기, 우주선 등)

항공 소프트웨어의 인증(Certification)

• 미국에서 항공 소프트웨어는 반드시 여러 규제 기관(NASA, FAA 등)의 표준에 기술된 인증 프로세스를 거쳐야 함. 영국과 유럽도 유사한 인증 프로세스를 가진다.
• 미항공우주국(NASA)의 여러 센터들과 FAA는 소프트웨어 타입에 따라 각기 다른 고유의 인증 프로세스를 가진다. 예를 들어, 우주 셔틀(the Space Shuttle)과 우주 정거장(the Space Station)은 서로 다른 나름대로의 인증 프로세스를 가진다.
• 미연방항공국(FAA) 공역(airspace) 안의 항공기에 탑재되는 모든 소프트웨어는 FAA의 인증 프로세스를 준수해야 한다.
• 해당 소프트웨어가 고위험(safety-critical) 소프트웨어인지 고임무(mission-critical) 소프트웨어 인지에 따라서도 인증 프로세스가 달라진다.
• 다양한 인증 프로세스가 존재하지만 기본 아이디어는 동일(규제 기관들은 모든 잠재적인 위험이 식별되었고 이를 다루기 위한 적절한 단계를 밟았다는 증거를 원함)

NASA와 FAA의 인증 프로세스

본 자료는 아래의 세 가지 인증 프로세스를 설명한다.

1)      FAA의 고위험(safety-critical) 소프트웨어 인증 프로세스: DO-178B 표준을 기반으로 함

2)      NASA 드라이든 비행 연구 센터(the Dryden Flight Research Center: DFRC)의 고위험(safety-critical) 소프트웨어 인증 프로세스

3)      NASA 제트 추진 랩(the Jet Propulsion Lab: JPL)의 고임무(mission-critical) 비행 소프트웨어 승인(approval) 프로세스

고위험 우주항공 소프트웨어를 위한 표준

• 표준(Standards)은 소프트웨어 개발 프로세스가 지속적으로 개선되고 개발자들이 같은 실수를 반복하지 않도록 이전 프로젝트들로부터 얻은 교훈을 모아놓은 것에 지나지 않는다.
• 안전하고 품질 높은 항공 소프트웨어를 빠르고 값싸게 생산하려는 노력으로 항공 소프트웨어 프로젝트로부터 얻은 교훈들을 기술한 표준이 개발됨
• 고위험 항공 소프트웨어와 관련된 표준들은 아래와 같은 세 카테고리로 나눌 수 있다.
  - NASA 표준: 드라이든 비행 연구 센터(DFRC) 같은 특정 센터의 고유한 표준을 포함
  - RTCA DO-178B: 상용 항공 소프트웨어 규제를 위해 FAA가 사용
  - MIL-STD 498: 군사 표준

1) MIL-STD 498 표준

아래 그림은 주요 미국 표준들의 역사를 보여주고 있다.

• DOD-STD 2167A와 DOD-STD-7935A를 종합하여 현재 군사 소프트웨어 개발에서 사용되는 MIL-STD 498 작성
• ISO/IEC 12207과 J-STD-016-1995를 종합한 정보와 여러 IEEE 표준들을 업데이트하고 불분명한 부분을 구체화하여 IEEE/EIA 12207 작성. IEEE/EIA 12207은 아래와 같은 세 개의 볼륨으로 나뉜다.
  - 12207.0: Software Life Cycle Processes
  - 12207.1: Software Life Cycle Processes Life Cycle Data
  - 12207.2: Software Life Cycle Processes Implementation Considerations
• NASA 아메스 연구 센타(Ames Research Center)에서 성공적인 우주 미션들로부터 얻은 교훈과 기타 관련 연구들을 반영하여 IEEE/EIA 12207 표준을 개선하는 작업을 진행 중

2) NASA의 Dryden, Ames, JPL 센터에서 다양한 표준을 참고하고 있음

원본 영문 문서의 13페이지 참고

3) RTCA DO-178B 표준

• 항공 시스템과 장비의 소프트웨어 측면이 감항성 인증 요구사항(airworthiness certification requirements)에 부합하는지 판단하기 위한 가이드 제공
• 미국 항공 라디오 기술 협회(the Radio Technical Commission for Aeronautics: RTCA)에 의해 1980년 작성되어 1985년과 1992년에 개정을 거침
• DO-178B와 유사한 유럽의 표준으로 EUROCAE가 작성한 ED-12B가 있음
• RTCA는 DO-178B의 이해를 돕기 위해 아래와 같은 문서도 펴냄
  - DO-248B: DO-178B 적용에 있어 모범 사례(best practices)
  - DO-278: 지상 기반 설비(ground-based facilities)를 위한 표준 확장 

고위험 소프트웨어와 고임무 소프트웨어

NASA와 FAA 둘 다 소프트웨어를 고위험(Safety-critical)과 고임무(Mission-critical meaning)의 두 개 카테고리로 분류한다.

 

1) 나사의 소프트웨어 레벨 정의(NASA Software Level Definitions)

NASA 센터마다 약간씩 다르긴 하지만 큰 틀은 동일. 나사 드라이든(NASA Dryden) 센터의 경우 고임무 소프트웨어(mission-critical software)를 Class B로 고위험 소프트웨어(safety-critical software)를 Class A로 분류한다. Class A 소프트웨어의 장애는 항공기와 조종사를 위험에 빠뜨릴 수 있으므로 Class B 소프트웨어 비하여 Class A의 인증(certification)은 더 엄격한 테스팅이 수반된다.

2) DO-178B 표준의 소프트웨어 레벨 정의(Software Level Definitions)

DO-178B은 소프트웨어를 아래의 5개 레벨로 더 상세하게 분류하지만 전반적인 개념은 NASA의 경우와 마찬가지로 고위험 소프트웨어에 더 엄격한 인증 프로세스와 방법을 적용하는 것이다.

• Level A: 소프트웨어의 이상 동작이 안전한 비행과 착륙을 막는 재앙 상황(a catastrophic failure)을 초래
• Level B: 소프트웨어의 이상 동작이 항공기나 승무원의 기능을 크게 저하시켜 안전에 치명적인 피해를 줄 수 있는 심각한 위험 상황(a severe major failure condition) 초래
• Level C: 소프트웨어의 이상 동작이 승무원의 작업량을 늘리거나 효율성을 저하시키고 승객들에게 상해를 입히거나 불편하게 만드는 위험 상황(a major failure) 초래
• Level D: 소프트웨어의 이상 동작이 항공기의 안전을 크게 저하시키거나 승무원의 업무를 방해하지는 않지만 사소한 문제나 불편(a minor failure)을 초래
• Level E: 소프트웨어의 이상 동작이 항공기 운영이나 승무원의 업무에 영향을 주지 않음

FAA의 고위험 소프트웨어 인증 요구사항(DO-178B 기반)

1) 고위험 소프트웨어 인증 프로세스(Safety-Critical Certification Process)

①     지원자(항공 소프트웨어 공급자)는 대상 항공기 또는 엔진에 대한 인증 기준(the certification basis or criteria)을 세우기 위해 인증 기관(특정 나라/지역의 인증을 책임지는 조직)과 만난다.

②     지원자는 수립된 인증 기준을 충족하기 위한 소프트웨어 인증 계획(a Plan for Software Aspects of Certification: PSAC)을 개발한다. PSAC는 아래와 같은 것들을 포함한다.
- 시스템 개요(System overview): 시스템 기능과 이 기능을 책임지는 하드웨어나 소프트웨어, 아키텍쳐, 프로세서, 하드웨어와 소프트웨어 인터페이스, 안전성 관련 특성을 설명
- 소프트웨어 개요(Software overview): 적용된 안전성과 파티션 측면에 중점을 두어 소프트웨어 기능 설명(예, 자원 공유, 중복성, 다수 버전의 상이한 소프트웨어, 결함허용과 타이밍/스케쥴링 전략 등)
- 인증 고려사항(Certification considerations): 표준 준수 방법, 소프트웨어 레벨(A-E), 장애 상황을 초래할 수 있는 잠재적 소프트웨어 위험을 포함한 시스템 안전성 평가 결과
- 소프트웨어 생명 주기(Software Life Cycle): 상세한 소프트웨어 계획, 각 소프트웨어 개발 주기 프로세스의 목표를 어떻게 충족시키고 누가 책임을 지는지 등에 대한 설명. 인증 기관에 제출하는 최소한의 소프트웨어 개발 주기 데이터로 PSAC, 소프트웨어 형상 인덱스(Software Configuration Index: SCI), 소프트웨어 성과 요약서(Software Accomplishment Summary: SAS), 소프트웨어 검증 케이스와 절차가 있다.
- 소프트웨어 생명 주기 데이터(Software Life Cycle Data): 소프트웨어에 의해 생성되고 통제되는 모든 데이터와 이 데이터들이 서로 어떻게 관련되어 있는지를 기술. 데이터가 인증 기관에 어떻게 제출될 것인지(디스켓, CD 등)와 데이터의 형식(텍스트 파일, 바이너리 파일 등)이 무엇인지에 대한 정보도 기술
- 일정(Schedule)
- 추가적인 고려사항(Additional considerations): 도구 검증(tool qualification), 사전 개발 소프트웨어, 상용 소프트웨어(COTS) 등

③     인증 기관은 PSAC를 인증 기준과 비교하여 완전성과 일관성 측면에서 평가한다.

④     인증 기관은 지원자가 제안한 소프트웨어 레벨의 적절성에 동의해야 한다.

⑤     인증 기관은 인증 전에 반드시 충족되어야 할 이슈가 있는 경우 이를 지원자에게 알린다.

⑥     인증 기관은 SAS와 표준 준수 관련 증거를 검토하여 소프트웨어를 포함한 항공기 또는 엔진이 인증 기준에 부합하는지 결정한다. 인증 기관의 자유재량으로 소프트웨어 개발 주기 프로세스와 그 산출물을 검토할 수도 있다.

 

2) 변경된 조건/결정 커버리지(Modified Condition and Decision Coverage: MCDC)

• Level A 소프트웨어의 대하여 DO-178B에서 요구하는 구조적 커버리지 기준은 ‘변경된 조건/결정 커버리지(Modified Condition/Decision Coverage)’이다.
• MCDC는 소프트웨어에 존재하는 부울 연산(AND, OR, NOT으로 연결되는 개체간의 논리적 조합)의 실행과 관련 있다.
• MCDC는 각 부울 연산의 최상위 레벨인 결정(a decision)이 참(True)과 거짓(False)의 결과가 모두 나오도록 실행할 것을 요구한다. 또한 결정이 부울 연산자로 연결된 다수의 조건(condition)들로 구성되어 있다면, 각 조건이 전체 결정의 결과값(the outcome of the decision)에 독립적으로 영향을 줄 수 있는지 확인해야 한다. 

예) 결정이 (A and (B or C)) 라고 했을 때

아래와 같이 B가 거짓이고 C가 참인 경우 조건 A가 독립적으로 해당 결정의 결과값을 결정한다.

• 즉, B 와 C 값이 고정되어 있을 때 조건 A를 T에서 F로 (또는 F에서 T로) 변경시키면 전체 결정의 결과값이 바뀐다. 조건 A가 독자적으로 전체 결정 결과값에 영향을 주게 만드는 B와 C 값의 또 다른 조합들이 있을 수도 있지만 한가지 조합만 찾으면 충분
• 위의 조건 A와 유사하게 조건 B와 조건 C가 독립적으로 결정의 결과값에 영향을 미치는 경우도 찾아야 한다.
• N개의 조건으로 구성된 결정의 MCDC 커버리지 기준을 만족시키기 위해서는 최소 (N+1)개의 테스트 케이스가 필요하다.
• 아래 그림은 간단한 Simulink 코드에 대한 MCDC를 포함한 코드 커버리지들의 예이다.

3) 소프트웨어 성과 요약서(Software Accomplishment Summary: SAS)

SAS는 PSAC 준수 여부를 보여주는 주요 문서로 아래와 같은 사항을 포함한다.

• 시스템 개요: PSAC의 시스템 개요에 기술했던 것과 동일한 항목들에 대하여 기술. PSAC에 기술했던 것과 달라진 점이 있으면 기술
• 소프트웨어 개요: PSAC에 기술했던 것과 동일. 달라진 점도 기술
• 인증 고려사항: PSAC의 기술 내용과 동일. 달라진 점도 기술
• 소프트웨어 특징(Software characteristics): 실행 가능한 오브젝트 코드 사이즈, 타이밍과 메모리 여유(margins), 자원 제약, 각 특징을 측정하는 방법을 기술
• 소프트웨어 생명 주기: PSAC의 기술 내용과 동일. 달라진 점도 기술
• 소프트웨어 생명 주기 데이터: PSAC와 동일. 달라진 점도 기술
• 추가적인 고려사항: 인증기관의 관심이 될 만한 인증 이슈 요약
• 변경 이력(Change history)
• 소프트웨어 상태(Software status): 인증 시점에 해결되지 못한 문제 보고서(problem reports) 요약을 포함한 소프트웨어 상태 기술
• 계획/표준 준수에 대한 진술(Compliance statement): 이 문서에 기술된 내용들을 준수했다는 진술과 준수 여부를 증명하기 위해 사용된 방법들 요약. 계획, 표준, 또는 이 문서와 관련된 추가적인 의사결정이나 차이점들이 있으면 기술

4) FAA의 승인 프로세스

아래 그림은 FAA 승인 프로세스(the FAA approval process)를 보여준다.

FAA 인증을 받기 위해 지원자는 반드시 목표(objectives)가 충족되었다는 것을 증명해야 한다. Level A 소프트웨어는 66개의 목표를 Level B는 65개의 목표, 그리고 Level C는 62개의 목표를 가진다.

NASA 드라이든 비행연구센터(DFRC)의 고위험 소프트웨어(Class A) 인증 프로세스

• 소프트웨어의 인증 준비가 완료되면 내부 프로젝트 팀이 수행하는 테스트 준비 검토회(the Test Readiness Review: TRR)에서 검토된다.
• 소프트웨어가 내부 검토를 통과하면 프로젝트에 참여하지 않은 독립적인 엔지니어 팀에 의해 비행 운영 준비 검토(a Flight Operational Readiness Review: ORR)가 수행된다. 소프트웨어가 ORR을 통과하면 DFRC의 대표 엔지니어에게 이를 알린다.
• 프로젝트 관리자(the Project Manager) 또는 임무 관리자(the Mission Manager)가 프로젝트 계획과 준비사항을 감항성 비행 안전 검토 위원회(Airworthiness Flight Safety Review Board: AFSRB)의 회장에게 설명한다. AFSRB의 회장은 DFRC 센터장에 의해 임명되고 AFSRB에는 조직의 디렉터들, 대표 조종사, 안전 사무소(the Safety Office) 대표와 기타 다른 미국 정부 기관 담당자가 멤버로 포함된다.
• AFSRB의 회장은 아래 중 하나의 결정을 내리게 된다.
  - 신중한 검토 결과 해당 소프트웨어가 비행에 만족스럽다고 판단되어 위원회의 추가적인 검토 없이 인증을 한다.
  - 프로젝트와 관련 없는 소규모의 드라이든 전문가들을 소집하여 제안된 프로젝트가 비행에 적합한지 결정하는데 도움을 받는다.
  - 검토를 위해 프로젝트의 계획과 기능/동작을 전체 ASFRB 위원들에게 설명하도록 요청한다. 위원회는 특정 프로젝트가 비행 안정성을 적절하게 고려하고 계획에 반영하였는지 판단을 내린다.
  - 프로젝트의 계획과 기능/동작을 DFRC의 독립적인 검토(Independent Review: DIR)를 통해 ASFRB에게 설명하도록 요청한다.
• 신중한 검토와 고민 후 AFSRB는 “go” 또는 “no-go”를 결정한다. 소프트웨어가 “go”를 받으면 인증에 성공하여 항공기에 적재되고, 부족한 부분이 있어 “no-go”를 받게 되면 추가적인 작업을 위해 개발자에게 되돌려 보내지고 인증 프로세스가 다시 시작된다.

NASA 제트 추진 랩(JPL)의 고임무 소프트웨어(Class B) 승인 프로세스

• 제트 추진 랩(The Jet Propulsion Lab: JPL)은 고임무 시스템과 소프트웨어(mission-critical systems and software)를 개발하며 현재 고위험 소프트웨어(safety-critical software)는 개발하지 않고 있음
• JPL에서는 소프트웨어 자체를 인증하지는 않지만, 시스템과 소프트웨어를 아래의 4개 레벨로 분류하여 평가하고(evaluate) 승인하는(approve) 프로세스가 존재한다.
  - Level A: 이 레벨의 시스템과 소프트웨어에 장애(failure)가 발생하면 임무 목표를 달성하지 못하게 됨 (“loss of mission”)
  - Level B: 과학 데이터 처리를 지원하는 시스템과 소프트웨어(예, 별도로 고립이 가능하여 장애가 생겨도 Level A 시스템에 부작용을 주지 않은 2차적 성격의 비행 소프트웨어)
  - Levels C and D: 장애의 고립이 가능하고 Level A 또는 Level B 시스템에 부작용을 주지 않는 시스템과 소프트웨어
• 모든 시스템은 항공기나 우주선에 구현되기 전에 반드시 승인되어야(approved) 한다.
• JPL의 각 팀은 고임무 시스템의 성공 보장을 위한 계획을 개발해야 한다. 이 때 각 팀들은 the Software Working Group이 개발한 NASA 표준과 JPL에서 개발되는 시스템과 소프트웨어에 대하여 기술한 아래 세 개 문서를 준수해야 한다.
  - 소프트웨어 개발 요구사항(Software Development Requirements): 권장 검토회(recommended reviews), 스트레스 테스팅, 독립적인 품질 평가(independent quality assessment) 등을 포함한 Level A 소프트웨어 개발 가이드
  - 비용 산정, 요구사항 등에 대한 가이드라인을 포함한 CMMI 기반 핸드북 모음(Set of Handbooks based on CMMI)
  - 비행 소프트웨어의 권장 설계 방법과 기법을 포함한 설계 원칙 모음(Set of Design Principles) 

대개 시스템과 소프트웨어의 승인을 위해서 아래와 같은 엄격한 검토 프로세스가 진행된다.

• 시스템과 소프트웨어가 승인 준비가 되면 내부 프로젝트 팀이 테스트 준비 검토(the Test Readiness Review: TRR)에서 검토를 한다.
• 소프트웨어가 내부 검토를 통과하면 프로젝트에 참여하지 않은 독립 엔지니어 팀에 의해 검토된다. 독립 검토 팀은 비행 운영 준비 검토(a Flight Operational Readiness Review: ORR)를 수행한다.
• 시스템과 소프트웨어가 ORR을 통과하면 프로그램 관리자(the Program Manager)에게 이를 알리고 프로젝트 계획서와 다른 준비물을 최종 검토자(the Final Reviewers)에게 제출한다.
• 최종 검토자는 구현을 위해 소프트웨어를 승인할지 아니면 추가 작업을 위해 소프트웨어 개발자에게 되돌려 보낼지 결정한다.