DO-178B

DO-178B
항공 시스템 및 기기 인증에 관한 소프트웨어 고려 사항
줄임말
  • DO-178B
  • ED-12B
최신 버전1992년 12월 1일, 29년 전(1992-12-01)
조직
도메인항공

DO-178B, 항공 시스템 및 장비 인증에 대한 소프트웨어 고려사항(Software Considerations in Airbled Systems and Equipment Certification)은 특정 항공 시스템에서 사용되는 안전 중요 소프트웨어의 안전을 다루는 지침입니다.항공 무선 기술 위원회(RTCA)의 안전 중요 작업 그룹 RTCA SC-167과 유럽 민간 항공 장비 기구(EURCAE)의 WG-12에 의해 공동으로 개발되었습니다.RTCA는 문서를 RTCA/DO-178B로 발행하였고 EUROCAE는 문서를 ED-12B로 발행하였다.기술적으로는 가이드라인이지만 2012년 DO-178C로 대체되기 전까지는 항전 소프트웨어 시스템 개발에 대한 사실상의 표준이었다.

연방항공청(FAA)은 인증이 요구되는 기술표준명령(TSO)에 의해 명시될 때 소프트웨어가 항공 [1]환경에서 안정적으로 수행되는지 여부를 결정하기 위해 지침으로 사용하는 문서로서 DO-178B를 적용한다.미국에서, 내공성 인증 프로세스에 TSO를 도입하고 DO-178B를 확장함으로써, 연방 항공 규정(Federal Aviation Regulations, Part 21, SubPart O)이라고도 알려진 Title 14: Aeronomics and Space of the Code of the Federal Regulations (CFR)에 명시적으로 규정되어 있다.

소프트웨어 레벨

ARP4754에서 정의된 설계보증수준(DAL[2]) 또는 항목개발보증수준(IDAL)이라고도 불리는 소프트웨어 레벨은 시스템 고장상태의 영향을 검사하여 안전성 평가 프로세스와 위험분석에서 판단한다.고장 조건은 항공기, 승무원 및 승객에 미치는 영향에 따라 분류됩니다.

  • 치명적 – 장애가 발생하면 크래시가 발생할 수 있습니다.항공기를 안전하게 비행하고 착륙시키는 데 필요한 중요한 기능의 오류 또는 손실.
  • 위험 – 고장은 안전이나 성능에 큰 부정적인 영향을 미치거나 물리적 고통이나 높은 작업 부하로 인해 승무원이 항공기를 운항할 수 있는 능력을 감소시키거나 승객 사이에 중상 또는 치명적 부상을 야기합니다(안전 중요).
  • 중대 – 고장은 심각하지만 위험 고장보다 영향이 적거나(예를 들어, 부상보다는 승객의 불편함을 초래함) 승무원 작업 부하를 크게 증가시킵니다(안전 관련).
  • 경미한 – 고장은 눈에 띄지만 중대한 고장보다 영향이 작습니다(예: 승객 불편 또는 일상적인 비행 계획 변경).
  • 영향 없음 – 고장이 안전, 항공기 운영 또는 승무원 작업량에 영향을 미치지 않습니다.

DO-178B만으로는 소프트웨어의 안전성을 보장할 수 없습니다.설계에 포함되어 기능성으로 구현되는 안전 속성은 운전 및 명시적 안전요건의 충족에 대한 객관적 증거를 제시하기 위해 추가적인 필수 시스템 안전 태스크를 받아야 한다.일반적으로 IEEE STD-128-1994 소프트웨어 안전 계획이 할당되고 소프트웨어 안전 분석 태스크가 순차적 단계(요건 분석, 최상위 설계 분석, 상세 설계 분석, 코드 수준 분석, 테스트 분석 및 변경 분석)로 수행됩니다.이러한 소프트웨어 안전 과제와 아티팩트는 위험 심각도 및 DAL 결정에 대한 프로세스의 필수적인 지원 부분이다(SSA(시스템 안전성 평가)에 문서화되어야 한다.인증 당국은 소프트웨어 레벨 A-E를 확립하기 위해 이러한 포괄적인 분석 방법을 사용하여 올바른 DAL을 확립할 것을 DO-178B에 명시하고 있습니다.안전에 중요한 기능을 명령, 제어 및 모니터링하는 모든 소프트웨어는 최고 DAL - 레벨 A를 받아야 합니다.DO-178B의 적절한 수준의 엄격함을 유도하는 DAL을 결정하는 것은 시스템 안전성 평가를 주도하는 소프트웨어 안전성 분석입니다.SAE ARP 4754A와 같은 방법과 결합된 시스템 안전성 평가는 완화 후 DAL을 결정하며, 중복성, 설계 안전 기능 및 기타 구조적 형태의 위험 완화가 안전성 분석에 의해 주도되는 요건에 포함되는 경우 DO-178B 소프트웨어 수준 목표를 충족할 수 있다.따라서 DO-178B의 중심 주제는 전제조건 안전요건이 확립된 후의 설계보증과 검증이다.

달성해야 할 목표의 수(결국 독립성이 있음)는 소프트웨어 레벨 A-E에 의해 결정됩니다.'독립성'이란 소프트웨어 개발팀으로부터의 '독립성'에 의해 검증 및 검증 프로세스의 객관성이 보장되는 책임을 분리하는 것을 말합니다.독립성이 충족되어야 하는 목표의 경우, 항목을 검증하는 사람(요건 또는 소스 코드 등)이 항목을 작성한 사람이 아닐 수 있으며, 이 구분은 명확하게 [3]문서화되어야 합니다.경우에 따라 자동화 도구는 [4]독립성과 동등할 수 있습니다.단, 인적 검토를 대체할 경우 도구 자체의 자격을 확인해야 한다.

레벨 장애 상태 목적[5] 독립성 있게 장애율
A 대재앙 66 25 10−9/시
B 위험. 65 14 10−7/시
C 주요한 57 2 10−5/시
D 작은 28 2 10−3/시
E 효과 없음 0 0 없음

프로세스 및 문서

프로세스는 소프트웨어 레벨(A~D: 레벨E는 DO-178B의 범위 밖)에 따라 목표를 지원하는 것을 목적으로 하고 있습니다.DO-178B에서는 프로세스가 추상적인 작업 영역으로 기술되어 있으며, 프로세스가 어떻게 수행되는지 구체적으로 정의하고 문서화하는 것은 실제 프로젝트의 기획자에게 달려 있습니다.실제 프로젝트에서는 프로세스의 맥락에서 수행되는 실제 활동이 목표를 지원하는 것으로 보여져야 합니다.이러한 액티비티는 계획 프로세스의 일부로서 프로젝트 플래너에 의해 정의됩니다.

DO-178B의 이러한 목표 기반 특성은 다양한 스타일의 소프트웨어 라이프 사이클을 따르는 데 있어 상당한 유연성을 제공합니다.프로세스 내에서 활동이 정의되면 일반적으로 프로젝트가 프로세스 내에서 문서화된 활동을 존중해야 합니다.또한 프로세스(및 그 구체적인 활동)는 DO-178B에 따라 명확하게 정의된 진입 및 종료 기준을 가져야 하며, 프로젝트는 프로세스에서 활동을 수행할 때 이러한 기준을 준수하고 있음을 보여야 한다.

DO-178B의 프로세스와 입퇴장 기준은 유연하기 때문에 최초 구현이 어렵습니다.이러한 측면은 추상적이고 작업하는 활동의 "기본 집합"이 없기 때문입니다.DO-178B의 의도는 규범적이지 않았다.실제 프로젝트에서 이러한 측면을 정의하는 방법은 여러 가지가 있습니다.이 기준에 따라 민간 항전 시스템을 개발하려는 기업이 처음으로 DO-178B 훈련과 컨설팅의 틈새 시장을 창출하는 것은 어려울 수 있다.

일반적인 DO-178B 기반 프로세스의 경우, FAA가 정의한 "소프트웨어 및 복잡한 전자 하드웨어에 대한 지침 및 작업 지원"에 대한 관여 단계(SOI)를 포함한 시각적 요약이 제공됩니다.

계획.

일반적으로 시스템 요건은 프로젝트 전체에 입력됩니다.

소프트웨어 레벨 D에는 마지막 3개의 문서(표준)가 필요하지 않습니다.

발전

DO-178B는 소프트웨어 개발 표준으로 의도된 것이 아닙니다.이는 일련의 태스크를 사용하여 목표와 엄격한 수준을 충족하는 소프트웨어 보증입니다.

개발 프로세스 출력 문서:

일반적으로 시스템 요건에서 모든 소스 코드 또는 실행 가능한 오브젝트 코드로의 트레이서빌리티가 필요합니다(소프트웨어 레벨에 따라 다름).

일반적으로 사용되는 소프트웨어 개발 프로세스:

검증

이 프로세스에서 생성된 출력을 기록합니다.

테스트 및 결과에서 모든 요건에 이르는 모든 코드와 트레이서빌리티의 분석이 일반적으로 필요합니다(소프트웨어 레벨에 따라 다름).

이 프로세스에는 일반적으로 다음 작업도 포함됩니다.

  • 요건 기반의 테스트 도구
  • 코드 적용 범위 분석 도구

이 프로세스에서 실행되는 테스트의 다른 이름은 다음과 같습니다.

구성 관리

구성 관리 프로세스에 의해 유지되는 문서:

이 프로세스는 문제 보고서, 변경 및 관련 작업을 처리합니다.구성 관리 프로세스에서는 일반적으로 다음 항목을 아카이브 및 리비전 식별합니다.

  • 소스 코드 개발 환경
  • 기타 개발 환경(테스트/분석 도구 등)
  • 소프트웨어 통합 도구
  • 기타 모든 문서, 소프트웨어 및 하드웨어

품질보증

품질보증 프로세스에서 문서를 출력합니다.

  • 소프트웨어 품질 보증 레코드(SQAR)
  • 소프트웨어 적합성 확인(SCR)
  • 소프트웨어 성과 요약(SAS)

이 프로세스는 DO-178B 준수를 확인하기 위해 검토 및 감사를 수행합니다.인증기관과의 인터페이스도 품질보증 프로세스에 의해 처리됩니다.

인증연락처

일반적으로 지정 엔지니어링 담당자(DER)는 승인을 위해 FAA에 제출한 문서의 일부로서 기술 데이터를 검토합니다.

도구들

소프트웨어는 DO-178B 프로세스를 자동화, 지원 또는 처리할 수 있습니다.DO-178B 개발에 사용되는 모든 공구는 인증 프로세스의 일부여야 합니다.임베디드 코드를 생성하는 툴은 임베디드 코드와 동일한 제약조건으로 개발툴로서 인정됩니다.코드 검증에 사용하는 툴(시뮬레이터, 테스트 실행 툴, 커버리지툴, 리포트 툴 등)은 검증 툴로서 인정되어야 합니다.검증 툴의 포괄적인 블랙박스 테스트로 구성되어 있습니다.

서드파티제의 툴은 검증 툴로서 인정될 수 있습니다만, 개발 툴은 DO-178 프로세스에 따라서 개발되고 있을 필요가 있습니다.이러한 툴을 COTS로서 제공하는 기업은 인증기관으로부터 감사를 받아야 하며 인증기관에서는 소스 코드, 사양 및 모든 인증 아티팩트에 대한 완전한 접근을 허용합니다.

이 범위를 벗어나 사용된 공구의 출력은 사람이 수동으로 확인해야 합니다.

  • 문제 관리 도구는 변경 추적 기능을 제공할 수 있습니다.
  • SCI 및 SECI는 리비전 제어 도구의 로그에서 생성할 수 있습니다.

요건 관리

요구사항 추적성은 요구사항의 수명을 문서화하는 것과 관련이 있습니다.각 요건의 출처를 추적할 수 있어야 하며, 따라서 추적가능성을 달성하기 위해 요건의 모든 변경을 문서화해야 한다.구현된 기능을 도입하여 사용한 후 요건을 사용하는 경우에도 추적 가능해야 합니다.

비판

VDC Research는 DO-178B가 오늘날 엔지니어의 요구와 선호도에 잘 적응하지 못하고 있다는 점에서 "어느 정도 구식"이 되었다고 지적합니다.또한 같은 보고서에서 DO-178C는 이 [citation needed]문제를 해결하기에 적합한 것으로 보인다.

자원.

  • FAR Part 23/25 §1301/1301309
  • FAR 파트 27/29
  • AC 23/25.1309
  • AC 20-115b
  • RTCA/DO-178B
  • FAA Order 8110.49 소프트웨어 승인 가이드라인

「 」를 참조해 주세요.

레퍼런스

  1. ^ FAA 어드바이저리 통지 20-115b
  2. ^ RTCA/DO-178C "항공 시스템 및 장비 인증에 관한 소프트웨어 고려사항", 페이지 116. "한 가지 예는 "항목 개발 보증 수준"(IDAL)이며, 소프트웨어에 대해서는 "소프트웨어 수준"이라는 용어와 동의어입니다."
  3. ^ RTCA/DO-178B "항공 시스템 및 장비 인증 관련 소프트웨어 고려사항", 82페이지
  4. ^ RTCA/DO-178B "항공 시스템 및 장비 인증 관련 소프트웨어 고려사항", 페이지 82
  5. ^ RTCA/DO-178B "항공 시스템 및 장비 인증 관련 소프트웨어 고려사항", 부록 A

추가 정보

  • Leslie A. (Schad) Johnson. DO-178B, Software Considerations in Airborne Systems and Equipment Certification ( in the context of software development for military aircraft, a practitioner's discussion of the evolution of the current practice and application of RTCA/DO-178B). Boeing Commercial Airplane Group. Retrieved 2022-03-03.

외부 링크