DO-178B
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
DO-178B는 항공기 시스템에 사용되는 소프트웨어의 개발 및 인증에 대한 지침을 제공하는 표준이다. 소프트웨어 레벨은 시스템 고장이 항공기에 미치는 영향에 따라 결정되며, 치명적, 위험, 주요, 사소, 영향 없음의 5가지로 분류된다. 각 레벨에 따라 충족해야 할 요구 사항의 수와 독립성의 수준이 정해진다. DO-178B는 소프트웨어 안전성을 보장하기 위한 필수적인 시스템 안전 작업과 함께 사용되며, 계획, 개발, 통합, 검증, 형상 관리, 품질 보증, 인증 절차 등의 프로세스를 포함한다. 또한, 개발에 사용되는 도구의 인증과 요구 사항 추적성을 강조하며, 유럽에서는 EASA가 FAA를 대체하여 해당 표준을 적용한다.
더 읽어볼만한 페이지
- RTCA 규격 - DO-248B
DO-248B는 항공 전자 시스템 소프트웨어 개발 및 인증 시 DO-178B 표준 적용 과정에서 발생하는 문제와 고려 사항을 다루는 지침으로, 오류 수정 및 툴 퀄리피케이션, 구조적 커버리지, 재테스팅 등 안전 필수 소프트웨어 개발에 필요한 세부 사항을 규정한다. - RTCA 규격 - DO-254
DO-254는 항공 전자 하드웨어 설계 보증 표준으로서, 하드웨어 설계 및 검증 프로세스 전반에 걸쳐 요구 사항 캡처 및 추적 규정을 설명하고, 설계 권한, 하드웨어 설계 수명 주기, 검증 및 확인 프로세스 등을 다루며, FAA 또는 EASA와 같은 규제 기관의 인증에 중요한 역할을 합니다. - 소프트웨어 요구사항 - 유스 케이스
유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다. - 소프트웨어 요구사항 - 요구사항 분석
요구사항 분석은 소프트웨어 개발에서 시스템의 목적, 기능, 제약 조건을 정의하는 활동으로, 요구사항 수집, 분석, 기록 단계를 거쳐 고객의 요구를 정확히 파악하고 문서화하여 성공적인 시스템 구축의 기반이 되지만, 의사소통 문제, 요구사항 충돌 등의 어려움이 존재한다. - 컴퓨터 표준 - 포트란
포트란은 1950년대 IBM에서 개발되어 과학 및 공학 계산에 주로 사용되는 프로그래밍 언어이며, '수식 번역 시스템'에서 유래하여 객체 지향 프로그래밍, 병렬 처리 등의 기능이 추가되며 현대적인 언어로 발전해왔다. - 컴퓨터 표준 - PCI 익스프레스
PCI 익스프레스(PCIe)는 고속 직렬 통신을 사용하는 컴퓨터 확장 카드 인터페이스 규격으로, 점대점 연결 방식과 패킷 기반 데이터 전송, 그리고 다양한 레인 구성과 지속적인 발전을 특징으로 한다.
| DO-178B | |
|---|---|
| 소프트웨어 고려 사항 (항공 시스템 및 장비 인증) | |
| 개요 | |
| 공식 명칭 | 항공 시스템 및 장비 인증의 소프트웨어 고려 사항 |
| 약칭 | DO-178B ED-12B |
| 관련 표준 | 해당 사항 없음 |
| 후속 표준 | DO-178C |
| 선행 표준 | DO-178A |
| 제정 기관 | RTCA SC-167 EUROCAE WG-12 |
| 분야 | 항공 |
| 최초 게시일 | 1992년 12월 1일 |
| 웹사이트 | 해당 사항 없음 |
2. 소프트웨어 레벨
소프트웨어 레벨은 안전 평가 프로세스 및 위험도 분석을 통해 결정되며, 시스템 고장이 항공기, 승무원 및 승객에게 미치는 영향에 따라 분류된다. DO-178C에서는 설계 보증 레벨(DAL) 또는 항목 개발 보증 레벨(IDAL)이라고도 한다.[2]
DO-178B만으로는 소프트웨어 안전 측면을 보장할 수 없다. 설계 및 기능으로 구현된 안전 속성은 명시적인 안전 요구 사항을 충족한다는 객관적인 증거를 제시하고 확보하기 위해 추가적인 시스템 안전 작업이 필요하다. 이러한 소프트웨어 안전 작업 및 결과물은 시스템 안전성 평가(SSA)에 문서화될 위험 심각도 및 DAL 결정을 위한 프로세스의 필수적인 지원 부분이다. 인증 당국은 DO-178B에서 이러한 포괄적인 분석 방법을 사용하여 소프트웨어 레벨 A-E를 설정하도록 요구하고 명시한다. 안전에 중요한 기능을 명령, 제어 및 모니터링하는 모든 소프트웨어는 최고 DAL인 레벨 A를 받아야 한다. DO-178B에서 적절한 수준의 엄격성을 이끄는 DAL을 결정하는 것은 시스템 안전성 평가를 유도하는 소프트웨어 안전성 분석이다.
2. 1. 레벨 분류
안전 평가 프로세스(safety assessment process), 위험도 분석(hazard analysis)으로부터 결정된 레벨은 시스템의 고장 영향성을 판단하는 기준이 된다. 레벨은 다음과 같은 단계로 나뉜다.[7]- Catastrophic - 추락의 위험을 갖는 고장 위험 수준
- Hazardous - 성능 또는 안전에 큰 부정적인 요소를 갖거나 물리적인 변형 또는 과도한 업무 부하로 인해 조종사가 비행을 유지할 수 없는 위험 수준
- Major - 심각한 수준이지만 위험한 상태는 아님(예를 들어 승객이 다치는 것보다 불편한 상태)
- Minor - 고장 상태가 보이지만 Major 상태보다는 덜한 상태 수준(예를 들어 승객에게 불편을 초래하거나 비행 경로를 변경하는 상태)
- No Effect - 안전, 비행 조정 또는 조종사 과부하에 영향을 미치지 않은 고장 수준
위와 같은 소프트웨어 레벨에 따라 만족시켜야 할 요건의 수와 독립성 수준이 정해진다. 여기서 "독립성"이란 해당 개발 산출물의 개발자와 그 산출물을 검증하는 책임을 가진 사람이 명확히 분리되어야 한다는 의미이다.[7]
| 레벨 | 고장영향성 | 만족요건의 수 | 독립성 만족요건의 수 |
|---|---|---|---|
| A | Catastrophic | 66 | 25 |
| B | Hazardous | 65 | 14 |
| C | Major | 58 | 2 |
| D | Minor | 28 | 2 |
| E | No effect | 0 | 0 |
''소프트웨어 레벨''은 ARP4754에서 정의된 ''설계 보증 레벨''(DAL) 또는 ''항목 개발 보증 레벨''(IDAL)이라고도 하며, DO-178C는 소프트웨어 레벨과 동의어로 IDAL만 언급한다.[2] 이는 시스템 내의 고장 조건의 영향을 조사하여 안전성 평가 프로세스 및 위험 분석을 통해 결정된다. 고장 조건은 항공기, 승무원 및 승객에게 미치는 영향에 따라 분류된다.
충족해야 하는 목표의 수(궁극적으로 독립적으로)는 소프트웨어 레벨 A-E에 의해 결정된다. "독립적으로"라는 문구는 검증 및 유효성 검사 프로세스의 객관성이 소프트웨어 개발 팀과 "독립"함으로써 보장되는 책임의 분리를 의미한다. 독립적으로 충족해야 하는 목표의 경우, 항목(요구 사항 또는 소스 코드 등)을 검증하는 사람은 항목을 작성한 사람이 아니어야 하며, 이러한 분리는 명확하게 문서화되어야 한다.[3] 경우에 따라 자동화된 도구가 독립성과 동일할 수 있다.[4]
2. 2. 레벨별 요구사항
안전 평가 프로세스(safety assessment process), 위험도 분석(hazard analysis)으로부터 결정된 레벨로서 시스템의 고장 영향성을 판단하는 기준은 다음과 같다.[7]| 레벨 | 고장영향성 | 만족요건의 수 | 독립성 만족요건의 수 |
|---|---|---|---|
| A | Catastrophic | 66 | 25 |
| B | Hazardous | 65 | 14 |
| C | Major | 58 | 2 |
| D | Minor | 28 | 2 |
| E | No effect | 0 | 0 |
위 표에서 "독립성"이란 해당 개발 산출물의 개발자와 그 산출물을 검증하는 책임을 가진 사람이 명확히 분리되어 있어야 한다는 것을 의미한다.[7]
소프트웨어 레벨은 ARP4754에서 정의된 설계 보증 레벨(DAL) 또는 항목 개발 보증 레벨(IDAL)이라고도 하며, DO-178C는 소프트웨어 레벨과 동의어로 IDAL만 언급한다.[2]
고장 조건은 항공기, 승무원 및 승객에게 미치는 영향에 따라 분류된다.
| 레벨 | 고장 조건 | 목표 | 독립적으로 | 고장률 |
|---|---|---|---|---|
| A | 치명적 | 66 | 25 | |
| B | 위험 | 65 | 14 | |
| C | 주요 | 57 | 2 | |
| D | 사소 | 28 | 2 | |
| E | 영향 없음 | 0 | 0 | 해당 없음 |
DO-178B는 소프트웨어 레벨(A-D, E는 요건 없음)에 따라 목표를 만족시키기 위한 프로세스를 요구한다. 이 표준은 추상적인 수준으로 기술되어 있으며, 실제 프로젝트에서는 각 프로젝트 계획 단계에서 구체적인 실행 방법을 계획해야 한다.[1] 따라서 실제 프로젝트는 DO-178B의 요건을 만족시키기 위한 활동들을 진행하며, 이러한 활동들은 계획 단계에서 정의된다.
충족해야 하는 목표의 수(궁극적으로 독립적으로)는 소프트웨어 레벨 A-E에 의해 결정된다. "독립적으로"라는 문구는 검증 및 유효성 검사 프로세스의 객관성이 소프트웨어 개발 팀과 "독립"함으로써 보장되는 책임의 분리를 의미한다. 독립적으로 충족해야 하는 목표의 경우, 항목(요구 사항 또는 소스 코드 등)을 검증하는 사람은 항목을 작성한 사람이 아니어야 하며, 이러한 분리는 명확하게 문서화되어야 한다.[3] 경우에 따라 자동화된 도구가 독립성과 동일할 수 있다.[4]
3. 프로세스 및 문서
DO-178B의 목표 기반 특성은 다양한 소프트웨어 수명 주기 스타일에 유연하게 적용될 수 있게 한다. 일단 프로세스 내의 활동이 정의되면, 프로젝트는 해당 활동들을 준수해야 한다. 또한, 프로세스는 잘 정의된 진입 및 종료 기준을 가져야 하며, 프로젝트는 활동 수행 시 이러한 기준을 준수해야 한다.[1]
이러한 유연성은 처음 구현 시 어려움을 야기할 수 있는데, 이는 추상적인 특성으로 인해 작업할 "기본 세트" 활동이 없기 때문이다. DO-178B는 지시적인 것이 아니며, 실제 프로젝트가 이러한 측면을 정의하는 데는 다양한 방법이 존재한다. 이는 회사가 이 표준에 따라 민간 항공 전자 시스템을 개발하려는 첫 시도에서 어려움을 겪을 수 있으며, DO-178B 교육 및 컨설팅 시장을 창출하기도 했다.[1]
일반적인 DO-178B 기반 프로세스는 FAA가 정의한 참여 단계(SOIs)를 포함하는 [http://upload.wikimedia.org/wikipedia/commons/4/4f/DO-178B_Process_Visual_Summary_Rev_A.pdf 시각적 요약]으로 제공된다.
3. 1. 기획 프로세스
기획 프로세스의 결과물은 다음과 같다.
위에서 시스템 요구사항은 전체 프로젝트의 시작을 위한 일반적인 입력 요구조건이다. 마지막 세 개의 표준서 (SRS, SDS, SCS)는 레벨 D에 해당하는 소프트웨어에는 요구되지 않는다.
3. 2. 개발 프로세스
이 프로세스는 다음과 같은 여러 하위 프로세스로 나눌 수 있다.
개발 프로세스의 산출물은 다음과 같다.
일반적으로 시스템 요구사항에서 모든 소스 코드 또는 실행가능한 오브젝트 코드로의 추적성이 요구된다. (요구 수준은 소프트웨어 레벨에 따라 다소 차이가 있다.)
일반적으로 적용되는 소프트웨어 개발 프로세스는 다음과 같다.
DO-178B는 소프트웨어 개발 표준이 아닌, 목표와 엄격성 수준을 충족하기 위한 일련의 작업들을 사용하는 소프트웨어 보증이다.
3. 3. 통합 프로세스
통합 프로세스는 검증, 형상 관리, 품질 보증, 인증 지원으로 이루어져 있다.
3. 4. 검증 프로세스
이 프로세스에서 산출되는 문서는 다음과 같다.
이 프로세스를 완료하기 위해서는 모든 코드에 대한 검토 분석 결과와, 시험 및 시험 결과로부터 요구사항으로의 추적성 요건 만족이 일반적으로 요구된다. (소프트웨어 레벨에 따라 요건의 수준은 다소 상이할 수 있음.)
이 프로세스에서는 일반적으로 다음과 같은 도구들을 적용하게 된다.
또한 이 프로세스 내에서 다음과 같은 시험이 수행될 수 있다.
이 과정을 통해 생성된 문서 출력물은 다음과 같다:
모든 코드 분석과 테스트 및 결과에서 모든 요구 사항으로의 추적성은 일반적으로 필요하다(소프트웨어 레벨에 따라 다름).
이 프로세스는 일반적으로 다음도 포함한다.
이 프로세스에서 수행되는 테스트의 다른 이름은 다음과 같다.3. 5. 형상 관리 프로세스
형상 관리 프로세스는 소프트웨어 개발 과정에서 생성되는 산출물들을 관리하고 유지한다. 이 프로세스에서 주로 다루는 문서는 다음과 같다.
형상 관리 프로세스는 결함 보고, 변경 요청 및 관련 활동들을 정의하고 통제하며, 일반적으로 다음과 같은 데이터를 보관하고 갱신한다.
구성 관리 프로세스에 의해 유지되는 문서는 다음과 같다.
이 프로세스는 문제 보고서, 변경 사항 및 관련 활동을 처리한다. 구성 관리 프로세스는 일반적으로 다음의 아카이브 및 개정 식별을 제공한다.3. 6. 품질 보증 프로세스
소프트웨어 품질 보증 기록 (SQAR), 소프트웨어 적합성 검토 (SCR), 소프트웨어 개발실적 요약서 (SAS)는 품질 보증 프로세스를 통해 만들어지는 문서이다. 이 프로세스는 프로젝트 전반에 걸쳐 DO-178B 적합성에 대한 검토(review)와 감사(audit)를 수행한다. 또한 DO-178B 인증 기관인 FAA 또는 이를 위임한 DER에 인증에 필요한 데이터를 제공하는 등의 연결 역할을 수행한다.[1]
품질 보증 프로세스의 산출 문서는 다음과 같다:[2]
이 프로세스는 DO-178B 준수 여부를 확인하기 위해 검토 및 감사를 수행하며, 인증 기관과의 인터페이스 또한 품질 보증 프로세스에서 처리한다.[2]
3. 7. 인증 절차 프로세스
일반적으로 미국 연방 항공국(FAA)에서 권한을 위임받은 DER(Designated Engineering Representative, 지정 엔지니어링 대표)이 항공기 제조사 내에 고용되어 인증 절차를 진행한다. DER은 미국 연방 항공청 승인 신청의 일환으로 기술 데이터를 검토한다.[1]
4. 도구 인증 (Tool Qualification)
소프트웨어 도구를 사용하면 DO-178B가 요구하는 프로세스를 자동화하고 관리하며 쉽게 적용할 수 있다. DO-178B 기반의 개발 프로젝트에 사용되는 모든 소프트웨어 도구는 인증 프로세스의 부분이다. 따라서 코드를 자동으로 생성하는 개발 도구는 소스 코드와 동일하게 그 개발 도구로서의 인증(qualification)을 보장해야 한다. 이는 그러한 개발 도구가 생성한 코드가 최종 항공 시스템에 결함을 발생시킬 수 있기 때문이다. 단, 해당 생성 코드에 대해 수동으로 독립적인 검토를 수행할 경우에는 인증 데이터(qualification data)를 제출할 의무는 사라진다.
또한 검증 프로세스에서 소스 코드를 시험/검증하기 위한 도구(시뮬레이터, 시험 실행 환경, 커버리지 분석 도구, 보고서 생성 도구 등)는 대개 소스 코드 자체에 결함을 발생시킬 위험은 낮다. 따라서 검증 도구로서의 적격 검토는 개발 도구의 요건보다는 가벼울 수 있으며, 도구에 대한 동작 요구사항(Tool Operational Requirements) 정의와 그에 대한 시험을 통한 검증을 통해 데이터를 제출한다.
임베디드 코드를 생성하는 도구는 임베디드 코드와 동일한 제약 조건으로 '''개발 도구'''로 자격이 주어진다.[1] 코드를 검증하는 데 사용되는 도구(시뮬레이터, 테스트 실행 도구, 커버리지 도구, 보고 도구 등)는 도구의 포괄적인 블랙 박스 테스트로 구성된 훨씬 가벼운 프로세스인 '''검증 도구'''로 자격이 주어져야 한다.[1]
타사 도구는 검증 도구로 자격을 얻을 수 있지만, 개발 도구는 DO-178 프로세스를 따라 개발되어야 한다.[2] 이러한 종류의 도구를 COTS로 제공하는 회사는 인증 당국의 감사를 받으며, 해당 당국에 소스 코드, 사양 및 모든 인증 아티팩트에 대한 완전한 접근 권한을 제공한다.[2] 이 범위를 벗어나면 사용된 모든 도구의 출력은 사람이 수동으로 검증해야 한다.[3]
5. 요구사항 관리
요구 사항 추적성은 요구 사항의 생명 주기를 문서화하는 것과 관련이 있다. 각 요구 사항의 출처를 추적할 수 있어야 하며, 추적성을 달성하기 위해 요구 사항에 대한 모든 변경 사항을 문서화해야 한다. 구현된 기능이 배포되고 사용된 후에도 요구 사항의 사용을 추적할 수 있어야 한다.
6. 유럽에서의 항공용 소프트웨어 인증
유럽에서는 EASA, JAA 또는 CAA이 미국의 FAA을 대체한다. JAR 또는 CS는 FAR을 대체하며, AC는 AMJ로 대체된다.
7. 비판
VDC 리서치는 DO-178B가 오늘날 엔지니어의 요구와 선호도에 잘 적응하지 못하여 "다소 구식"이 되었다고 지적했다. 같은 보고서에서 이들은 DO-178C가 이 문제를 해결할 수 있을 것으로 보인다고 언급했다.
참조
[1]
웹사이트
FAA Advisory Circular 20-115B
https://web.archive.[...]
2005-11-30
[2]
간행물
"Software Considerations in Airborne Systems and Equipment Certification"
RTCA/DO-178C
[3]
간행물
"Software Considerations in Airborne Systems and Equipment Certification"
RTCA/DO-178B
[4]
간행물
"Software Considerations in Airborne Systems and Equipment Certification"
RTCA/DO-178B
[5]
간행물
"Software Considerations in Airborne Systems and Equipment Certification"
RTCA/DO-178B
[6]
문서
FAA 권고(Advisory Circular) 20-115B
[7]
간행물
"Software Considerations in Airborne Systems and Equipment Certification"
RTCA/DO-178B
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com