DO-178C

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

DO-178C, 항공 시스템 및 장비 인증에 대한 소프트웨어 고려사항은 FAA, EASA 및 캐나다 교통국과 같은 인증 기관이 모든 상용 소프트웨어 기반 항공우주 시스템을 승인하는 주요 문서입니다.이 문서는 RTCA, Incorporated에 의해 EURCAE와 공동으로 발행되며 DO-178B를 대체한다.새로운 문서는 DO-178C/ED-12C로 불리며 2011년 11월에 완성되어 2011년 12월에 RTCA에 의해 승인되었습니다.2012년 [1][2][3]1월에 판매 및 사용이 가능하게 되었습니다.

FAR 33/JAR E를 제외하고, 연방 항공 규정은 소프트웨어 내공성을 [4]직접 참조하지 않는다.2013년 7월 19일, FAA는 AC 20-115C를 승인하면서 DO-178C를 "항공 시스템 및 장비 [5]인증의 소프트웨어 측면에 대한 적용 가능한 FAR 내공성 규정 준수를 보여주는 유일한 수단이 아닌 인정된 수단"으로 지정했다.

배경

DO-178B의 출시 이후, DER(FAA Designated Engineering Respons)는 DO-178B의 주요 개념인 높은 수준의 요건, 낮은 수준의 요건, 파생된 요건 간의 정의와 경계에 대한 명확화/정리와 출구/진입 기준 시스템의 더 나은 정의를 요구해왔다.요건과 시스템 설계(ARP4754 참조), 소프트웨어 요건과 소프트웨어 설계(DO-178B의 영역)의 요건과 시스템 설계.다른 우려사항으로는 모델 기반 개발 패러다임에서의 검증의 의미와 일부 또는 모든 소프트웨어 테스트 활동을 모델 시뮬레이션 또는 공식 방법으로 대체하기 위한 고려사항이 포함되었다.DO-178C 및 부속 문서 DO-278A(지상 시스템), DO-248C(각 DO-178C 목표에 대한 근거가 있는 추가 정보), DO-330(공구 자격), DO-331(모델링), DO-332(개체 지향), DO-333(공구 지향) 및 DO-333(공구 형식적 방법)의 공개SC-205 위원들은 ARP4754A와 위에 언급된 DO-xx 문서가 상호 보완적 기준과 함께 통합되고 연계된 프로세스를 제공하도록 SAE S-18 위원회와 협력했다.

전반적으로 DO-178C는 DO-178B 텍스트의 대부분을 보관하고 있으며, 이로 인해 낮은 수준의 요건의 개념에 대한 모호성과 같은 DO-178B 관련 문제가 완전히 [6]해결되지 않을 수 있다는 우려가 제기되고 있다.

위원회 조직

RTCA/EUROCAE 공동 위원회 작업은 7개의 하위 그룹으로 구분되었다.

  • SG1: SCWG 문서 통합
  • SG2: 문제와 근거
  • SG3: 툴 인정
  • SG4: 모델 기반 개발 및 검증
  • SG5: 객체 지향 테크놀로지
  • SG6: 정식 방식
  • SG7: 안전 관련 고려 사항

모델 기반 개발 및 검증 하위 그룹(SG4)은 작업 그룹 중 가장 큰 규모였습니다.모든 작업은 협업 작업 관리 [7]메커니즘인 웹 사이트를 통해 수집 및 조정됩니다.작업 유물 및 초안 문서는 그룹 구성원만 사용할 수 있는 제한 구역에 보관되었습니다.

이 작업은 현재 소프트웨어 개발 관행, 도구 및 [8][9]기술과 관련하여 DO-178B/ED-12B를 최신 상태로 유지하는 데 초점을 맞췄습니다.

소프트웨어 레벨

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

  • 치명적 - 고장은 일반적으로 비행기 상실로 사망을 초래할 수 있습니다.
  • 위험 - 고장은 안전이나 성능에 큰 부정적인 영향을 미치거나 물리적 고통이나 높은 작업 부하로 인해 승무원이 항공기를 운항할 수 있는 능력을 저하시키거나 승객에게 중상 또는 치명적인 부상을 입힙니다.
  • 주 - 고장 시 안전 여유도가 현저히 감소하거나 승무원의 작업 부하가 크게 증가합니다.승객의 불편함(또는 경미한 부상)을 초래할 수 있습니다.
  • 경미한 - 고장 시 안전 여유가 약간 감소하거나 승무원의 작업 부하가 약간 증가합니다.예로는 승객 불편이나 일상적인 비행 계획 변경을 들 수 있다.
  • 영향 없음 - 고장이 안전, 항공기 운영 또는 승무원 작업 부하에 영향을 미치지 않습니다.

DO-178C만으로는 소프트웨어의 안전성을 보장할 수 없습니다.설계상 및 기능상 구현된 안전 속성은 운전 및 명시적 안전요건의 충족에 대한 객관적 증거를 제시하기 위해 추가적인 필수 시스템 안전 태스크를 받아야 한다.인증당국은 DO-178C를 요구하고 DO-178C는 소프트웨어 레벨 A-E를 확립하기 위해 이러한 포괄적인 분석 방법을 사용하여 올바른 DAL을 확립하도록 규정하고 있습니다.「소프트웨어 레벨은 DO-178C의 [10]준수를 증명하는 데 필요한 엄격함을 확립합니다.안전에 중요한 기능을 명령, 제어 및 모니터링하는 모든 소프트웨어는 최고 DAL - 레벨 A를 받아야 합니다.

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

레벨 장애 상태 목적[12] 독립성 있게
A 대재앙 71 30
B 위험. 69 18
C 주요한 62 5
D 작은 26 2
E 안전상의 영향 없음 0 0

프로세스 및 문서

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

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

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

일반적인 DO-178C 기반 프로세스의 경우, 인증기관이 EASA의 '인증 각서 SWCEH – 002: SW 승인 가이드라인 및 주문 8110 승인 가이드라인에 대한 FAA'에 정의된 시스템 또는 서브시스템 검토에 관여하는 최소 관문입니다.

트레이서빌리티

RTCA DO-178C 규격에 따라 인증 아티팩트 간에 필요한 양방향 트레이스를 나타내는 그림.빨간색 트레이스는 레벨A에만 필요합니다.레벨 A, B 및 C에는 보라색 트레이스가 필요합니다.녹색 트레이스는 레벨 A, B, C 및 D용입니다.레벨 E는 트레이스가 필요 없습니다.각 추적 화살표에 있는 참조는 각각 목표, 활동 및 검토/검증에 대한 표준에 대한 참조를 나타냅니다.

DO-178 에서는, 증명서 아티팩트간에 문서화된 쌍방향 접속(트레이스라고 불립니다)이 필요합니다.예를 들어 Low Level Requirement(LLR; 로우레벨 요건)는 High Level Requirement(HLR; 상위 레벨 요건)까지 추적되며, Low Level Requirement(LLR; 하위 레벨 요건)는 요건과 관련된 소스 코드의 정확성을 검증하기 위한 테스트 케이스까지 추적됩니다.다음으로 트레이서빌리티 분석을 사용하여 각 요건이 소스 코드에 의해 충족되고, 각 기능 요건이 테스트에 의해 검증되고, 소스 코드의 각 행이 목적을 가지고 있는지(요건에 접속되어 있는지) 등을 확인합니다.추적 분석에서는 시스템의 완전성에 액세스합니다.인증 아티팩트의 엄격함과 세부 사항은 소프트웨어 레벨과 관련이 있습니다.

DO-178B와의 차이점

SC-205/WG-12는 DO-178B/ED-12B를 개정하여 현재의 소프트웨어 개발 및 검증 기술에 관한 최신 정보를 제공하는 역할을 담당했습니다.문서의 구조는 B부터 C까지 거의 동일합니다.변경 예는 다음과 같습니다.[13]

  • 명확한 언어 및 용어 제공, 일관성 향상
  • 기타 목표(레벨 A, B 및 C)
  • 섹션 6.4.4.2b의 DO-178B에 의해 암시되었지만 부속서 A 표에 열거되지 않은 수준 A에 적용할 수 있는 "숨겨진 목표"를 명확히 했다.이 목표는 현재 DO-178C, 부록 A, 표 A-7, 목표 9: "소스 코드로 추적할 수 없는 추가 코드의 검증이 [14]달성되었습니다."에 명시되어 있습니다.
  • 매개 변수 데이터 항목 파일 - 실행 가능한 개체 코드의 동작에 영향을 미치는 별도의 정보를 제공합니다(변경하지 않음).예를 들어 파티션화된 운영 체제의 일정 및 주요 기간을 설정하는 구성 파일이 있습니다.매개 변수 데이터 항목 파일은 실행 가능한 개체 코드와 함께 검증하거나 매개 변수 데이터 항목의 가능한 모든 범위에 대해 테스트해야 합니다.
  • DO-330 "소프트웨어 도구 자격 심사 고려사항"은 허용 가능한 도구 자격 심사 프로세스에 대한 지침을 제공하기 위해 새로운 "도메인 독립 외부 문서"가 개발되었습니다.DO-178B가 이 새로운 문서의 개발의 기초로서 사용되었지만, 본문은 도구 개발에 직접적이고 개별적으로 적용 가능하도록 수정되었고 모든 도구 측면을 다루도록 확장되었다.도메인에 의존하지 않는 독립 실행형 문서인 DO-330은 DO-178C/ED-12C뿐만 아니라 DO-278/ED-109, DO-254/ED-80 및 DO-200을 지원하며 ISO [15]26262와 같은 비항공 애플리케이션에도 사용할 수 있도록 설계되었습니다.그 결과 DO-178C에서 공구 적격성 지침이 제거되었고, DO-178C [16]맥락에서 사용되는 공구에 DO-330 공구 적격성 지침을 적용할 시기를 결정하는 지침으로 대체되었다.
  • DO-178C 문서의 지침을 특정 기법으로 확장하기 위해 기술 보완이 추가되었다.현재 및 미래의 모든 소프트웨어 개발 기술을 설명하기 위해 이전 텍스트를 확장하는 대신, 특정 기술 또는 기술에 적용하기 위한 핵심 표준의 지침을 명시적으로 추가, 삭제 또는 수정할 수 있도록 보충본을 제공합니다.이러한 부록의 모든 지침은 DO-178C의 해당 지침 요소의 맥락에서 작성되었으므로 핵심 [17]문서와 동일한 수준의 권한으로 간주해야 한다.
    • DO-331 "DO-178C 및 DO-278A에 대한 모델 기반 개발 및 검증 보완" - 모델 기반 개발(MBD) 및 검증에 대처하고 모델링 기법을 사용하여 개발 및 검증을 개선하는 동시에 일부 모델링 방법에 내재된 함정을 방지할 수 있습니다.
    • DO-332 "DO-178C 및 DO-278A에 대한 객체 지향 기술 및 관련 기술 보완" - 객체 지향 소프트웨어 및 사용 조건 설명
    • DO-333 "DO-178C 및 DO-278A에 대한 공식 방법 보충" - 테스트를 보완하는(대체하지는 않음) 공식 방법 설명

가이드라인과지침.

DO-178B는 본문에서 지침과 지침이라는 용어의 사용이 완전히 일관되지 않았다."지침"은 "지침"보다 약간 더 강한 의무감을 전달한다.이와 같이 DO-178C에서는 SCWG는 '권장'으로 간주되는 모든 문장에 대해 '가이드라인'의 사용을 결정하고 '가이드라인'의 나머지 인스턴스를 '지원정보'로 대체하고 텍스트가 '권장' 지향적이 아닌 '정보'인 경우 해당 문구를 사용한다.

DO-248C/ED-94C 문서, DO-178C 및 DO-278A의 지원 정보는 가이던스가 [18]아닌 "지원 정보" 범주에 속합니다.

DO-178B와 DO-178C의 샘플 차이

6.1장에서는 소프트웨어 검증 프로세스의 목적을 정의합니다.DO-178C는 실행 가능 객체 코드에 대한 다음 문을 추가합니다.

  • 「실행 가능한 오브젝트 코드는, 소프트웨어 요건(즉, 의도한 기능)을 만족시켜, 의도하지 않은 기능이 없는 경우에도 안심할 수 있습니다.」
  • 「실행 가능한 오브젝트 코드는, 비정상적인 입력이나 조건에 올바르게 대응할 수 있는 소프트웨어 요건에 관해서 견고합니다.

이와 비교하여 DO-178B는 실행 가능한 객체 코드에 대해 다음과 같이 기술되어 있습니다.

  • "실행 가능한 오브젝트 코드가 소프트웨어 요건을 충족합니다."

이 설명에 의해 소프트웨어 개발자가 문서를 [19]해석할 때 발생할 수 있는 공백이 보충됩니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Timberlake Membership Software, 703-591-4232. "Rtca, Inc". Rtca.org. Retrieved 7 August 2016.
  2. ^ Charlotte Adams (1 September 2010). "DO-178C nears finish line, with credit for modern tools and technologies". Avionics Intelligence. Retrieved 23 October 2010. The industry expects the final package —DO-178C— to be released in the first quarter of 2011 and be mandated six to nine months after ratification.
  3. ^ "Summary of Difference Between DO-178B and DO-178C". FAA Consultants.com. Qualtech Consulting, Inc. Retrieved 23 October 2010. The release of these long anticipated standards will occur in mid 2011 and be recognized by the Certification Authorities in 2012.
  4. ^ 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. p. 11. Retrieved 3 March 2022.
  5. ^ "Archived copy" (PDF). Archived from the original (PDF) on 3 September 2014. Retrieved 2013-08-08.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  6. ^ Dale, Chris; Anderson, Tom, eds. (2010). Advances in systems safety : proceedings of the Nineteenth Safety-Critical Systems Symposium, Southampton, UK, 8-10th February 2011. London: Springer. pp. 298–299. ISBN 9780857291325.
  7. ^ "Archived copy". Archived from the original on 19 July 2011. Retrieved 2010-09-18.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  8. ^ Bill StClair & Tim King (7 March 2012). "DO-178C brings modern technology to safety-critical software development". Military Embedded Systems. Retrieved 17 April 2012.
  9. ^ "DO-178C Enhances Safety-Critical Avionics Software Development". Electronic Design. Electronic Design. Retrieved 17 April 2012.
  10. ^ a b RTCA/DO-178C "항공 시스템 및 장비 인증에 관한 소프트웨어 고려사항", 페이지 116. "한 가지 예는 "항목 개발 보증 수준"(IDAL)이며, 소프트웨어에 대해서는 "소프트웨어 수준"이라는 용어와 동의어입니다."
  11. ^ RTCA/DO-178C "항공 시스템 및 장비 인증 관련 소프트웨어 고려사항", 페이지 41
  12. ^ RTCA/DO-178C "항공 시스템 및 장비 인증 관련 소프트웨어 고려사항", 부록 A
  13. ^ "HighRely Synopsis of National FAA Software and Hardware Meeting Includes DO-178C Status". 2006. Retrieved 30 September 2009. DO-178C will contain more details on software modeling and the potential ability to use modeling to supplant some of the verification techniques normally required in DO-178B. DO-178C will also more fully address OO (Object Oriented) software and the conditions under which it can be used and the certification ramifications of OO in DO-178C.
  14. ^ RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, Inc. 2011.
  15. ^ Pothon, Frédéric. "Principles and benefits of using DO-330/ED-215" (PDF). validas. Retrieved 3 October 2019.
  16. ^ Pothon, Frédéric; et al. (2012). DO-178C/ED-12C versus DO-178B/ED-12B Changes and Improvements (PDF). p. 49. Retrieved 5 January 2015.
  17. ^ 포톤, 43-46페이지
  18. ^ Pothon, 페이지 14
  19. ^ "Archived copy". Archived from the original on 11 September 2014. Retrieved 2013-03-07.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)

외부 링크