DO - 178B - 위키백과, 우리 모두의 백과사전 DO - 178B 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 DO - 178B ( 항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항 ) 는 RTCA 사에 의해 발표된 소프트웨어 개발 표준이다. 이 표준은 RTCA SC - 167과 EUROCAE WG - 12에 의해 개발되었고, 이를 미국 연방 항공국 ( FAA ) 이 항공기 소프트웨어 인증을 위한 용도로 사용할 것을 인정하여 현재 업계에서 상용 항공기이 탑재되는 safety - critical 소프트웨어를 위한 사실 상의 ( de facto ) 표준으로 자리잡았다. [ 1 ]. 목차 1 소프트웨어 레벨 2 프로세스와 문서들 2. 1 기획 프로세스 2. 2 개발 프로세스 2. 3 통합 프로세스 2. 4 검증 프로세스 2. 5 형상 관리 프로세스 2. 6 품질 보증 프로세스 2. 7 인증 절차 프로세스 3 유럽에서의 항공용 소프트웨어 인증 4 도구 인증 ( Tool Qualification ) 5 같이 보기 6 각주 7 외부 링크 소프트웨어 레벨 [ 편집 ] 안전 평가 프로세스 ( safety assessment process ), 위험도 분석 ( hazard analysis ) 으로부터 결정된 레벨로서 시스템의 고장 영향성을 판단하는 기준으로 삼는 것으로 다음과 같은 단계가 있다. Catastrophic -
코드와 동일하게 그 개발 도구로서의 인증 ( qualification ) 을 보장해야한다. 이는 그러한 개발 도구가 생성한 코드가 최종 항공 시스템에 결함을 발생시킬 수 있기 때문이다. 단 해당 생성 코드에 대해 수동으로 독립적인 검토를 수행할 경우에는 인증 데이터 ( qualification data ) 를 제출할 의무는 사라진다. 또한 검증 프로세스에서 소스 코드를 시험 / 검증하기 위한 도구 ( 시뮬레이터, 시험 실행 환경, 커버리지 분석 도구, 보고서 생성 도구 등 ) 은 대개 소스 코드 자체에 결함을 발생시킬 위험은 낮다. 따라서 검증 도구로서의 적격 검토는 개발 도구의 요건보다는 가벼울 수 있으며, 도구에 대한 동작 요구사항 ( Tool Operational Requirements ) 정의와 그에 대한 시험을 통한 검증을 통해 데이터를 제출한다. 같이 보기 [ 편집 ] DO - 254 ( DO - 178B와 유사한 항공기 하드웨어 인증에 대한 표준 ) DO - 248B ( DO - 178B의 모호함을 보완하여 명확화하기 위한 최종 보고서, 오타 및 오기, 주요 이슈에 대한 추가 설명 등이 포함됨 ) ARINC - 653 ( 항공용 소프트웨어의 응용시 인터페이스 표준화 및 파티셔닝 정의 ) 항공용 소프트웨어 ARP4761 ( 안전 평가 프로세스 정의 ) ARP4754 ( 시스템 개발 프로세스 정의 ) 요구사항 관리 IEC61
용 소프트웨어의 응용시 인터페이스 표준화 및 파티셔닝 정의 ) 항공용 소프트웨어 ARP4761 ( 안전 평가 프로세스 정의 ) ARP4754 ( 시스템 개발 프로세스 정의 ) 요구사항 관리 IEC61508 각주 [ 편집 ] ↑ FAA 권고 ( Advisory Circular ) 20 - 115B ↑ RTCA / DO - 178B " Software Considerations in Airborne Systems and Equipment Certification ", p. 82 외부 링크 [ 편집 ] AC 25. 1309 - 1A AC 20 - 115B FAA Order 8110. 49 원본 주소 " " 분류 : RTCA 규격 둘러보기 메뉴 개인 도구 로그인하지 않음토론기여계정 만들기로그인 이름공간 문서토론 변수 보기 읽기편집역사 보기 더 보기 검색 둘러보기 대문사용자 모임요즘 화제최근 [UNK] 문서 보기임의 문서로도움말기부 도구 여기를 가리키는 문서가리키는 글의 최근 [UNK] 올리기특수 문서 목록고유 링크문서 정보위키데이터 항목이 문서 인용하기 인쇄 / 내보내기 책 만들기PDF로 다운로드인쇄용 판 다른 언어 [UNK] 링크 편집 이 문서는 2019년 5월 12일 ( 일 ) 02 : 38에 마지막으로 편집되었습니다. 모든 문서는 크리에이티브 커먼즈 저작자표시 - 동일조건변
소프트웨어 시험 도구 코드 커버리지 분석 도구 또한 이 프로세스 내에서 다음과 같은 시험이 수행될 수 있다. 단위 시험 통합 시험 블랙 박스 ( black box ) 및 수락 시험 형상 관리 프로세스 [ 편집 ] 형상 관리 ( Configuration Management ) 프로세스를 통해 관리, 유지되는 문서들은 다음과 같다. 소프트웨어 형상 색인 ( Software configuration index, SCI ) 소프트웨어 생명주기 환경 형상 색인 ( Software life cycle environment configuration index, SECI ) 이 프로세스를 통해 결함 보고 및 변경과 관련된 활동을 정의하고 통제한다. 형상 관리 프로세스는 일반적으로 다음과 같은 데이터를 보관하고 갱신하는 기능을 수행한다. 소스 코드 개발 환경 기타 개발 환경 ( 예를 들어 시험 및 분석 도구 ) 소프트웨어 통합 도구 모든 산출 문서, 소프트웨어 및 하드웨어 품질 보증 프로세스 [ 편집 ] 품질 보증 ( quality assurance ) 프로세스에 의한 산출 문서는 다음과 같다. 소프트웨어 품질 보증 기록 ( Software quality assurance records, SQAR ) 소프트웨어 적합성 검토 ( Software conformity review, SCR ) 소프트웨어 개발실적 요약서 ( Software accomplishment summary, SAS ) 이 프로세스를 통해 프로젝트 전반에 걸쳐 DO - 178B 적합성에 대한 검토
소스 코드 또는 실행가능한 오브젝트 코드로의 추적성이 요구된다. ( 요구 수준은 소프트웨어 레벨에 따라 다소 차이가 있다 ) 일반적으로 적용되는 소프트웨어 개발 프로세스는 다음과 같다. 폭포수 모델 ( waterfall model ) 나선형 모델 ( spiral model ) V 모델 ( V model ) 통합 프로세스 [ 편집 ] 검증, 형상관리, 품질보증, 인증지원으로 이루어져 있다. 검증 프로세스 [ 편집 ] 이 프로세스에서 산출되는 문서는 다음과 같다. 소프트웨어 시험 절차서 ( Software verification cases and procedures, SVCP ) 소프트웨어 시험 결과서 ( Software verification results, SVR ) 모든 요구사항, 설계, 코드에 대한 검토 결과 모든 실행 오브젝트에 대한 시험 결과 코드 커버리지 분석 결과 이 프로세스를 완료하기 위해서는 모든 코드에 대한 검토 분석 결과와, 시험 및 시험 결과로부터 요구사항으로의 추적성 요건 만족이 일반적으로 요구된다. ( 소프트웨어 레벨에 따라 요건의 수준은 다소 상이할 수 있음. ) 이 프로세스에서는 일반적으로 다음과 같은 도구들을 적용하게 된다. 요구사항 기반의 소프트웨어 시험 도구 코드 커버리지 분석 도구 또한 이 프로세스 내에서 다음과 같은 시험이 수행될 수 있다. 단위 시험 통합 시험 블랙 박스 ( black box ) 및 수락 시험 형상
erification plan : SVP ) 소프트웨어 형상관리 계획서 ( Software configuration management plan : SCMP ) 소프트웨어 품질보증 계획서 ( Software quality assurance plan : SQAP ) 시스템 요구사항 ( System requirements ) 소프트웨어 요구사항 표준서 ( Software requirements standard : SRS ) 소프트웨어 설계 표준서 ( Software design standard : SDS ) 소프트웨어 코딩 표준서 ( Software code standard : SCS ) 위에서 시스템 요구사항은 전체 프로젝트의 시작을 위한 일반적인 입력 요구조건이다. 그리고 마지막 세개의 표준서 결과물은 레벨 D에 해당하는 소프트웨어에는 요구되지 않는다. 개발 프로세스 [ 편집 ] 이 프로세스는 여러 개의 하위 프로세스로 나눌 수 있다. 요구사항 분석 설계 코딩 ( 구현 ) 통합 개발 프로세스의 산출물은 다음과 같다. 소프트웨어 요구사항 데이터 ( Software requirements data, SRD ) 소프트웨어 설계 기술서 ( Software design description, SDD ) 소스코드 실행가능한 오브젝트 코드 개발시 일반적으로 시스템 요구사항에서 모든 소스 코드 또는 실행가능한 오브젝트 코드로의 추적성이 요구된다. ( 요구 수준은 소프트웨어 레벨에 따라 다소 차이가 있다 ) 일반적으로 적용되는 소프트웨어 개발 프로세스
strophic 66 25 B Hazardous 65 14 C Major 58 2 D Minor 28 2 E No effect 0 0 프로세스와 문서들 [ 편집 ] 소프트웨어 레벨 ( A에서 D까지, E의 경우에는 DO - 178B 상 요건이 없음 ) 에 따른 목표를 만족시키기 위해서는 프로세스가 필요하다. DO - 178B에서 프로세스 자체가 구체적으로 명확히 기술되어 있지 않으며 추상적인 수준으로 기술되어 있고, 이를 구체적인 실제 프로젝트에서 실행하는 방법에 대해서는 각 프로젝트 계획 단계에서 이를 계획하도록 되어 있다. 그러므로 실제 프로젝트에서는 구체적인 프로세스를 만족시킨다기보다는 DO - 178B의 각각의 요건 ( objectives ) 을 만족시키기 위한 활동들이 진행된다. 그리고 사실 그러한 활동이 계획 단계에서 계획된다. 기획 프로세스 [ 편집 ] 이 프로세스의 결과물들은 다음과 같다. 소프트웨어 인증 계획서 ( Plan for software aspects of certification : PSAC ) 소프트웨어 개발 계획서 ( Software development plan : SDP ) 소프트웨어 검증 계획서 ( Software verification plan : SVP ) 소프트웨어 형상관리 계획서 ( Software configuration management plan : SCMP ) 소프트웨어 품질보증 계획서 ( Software
실적 요약서 ( Software accomplishment summary, SAS ) 이 프로세스를 통해 프로젝트 전반에 걸쳐 DO - 178B 적합성에 대한 검토 ( review ) 와 감사 ( audit ) 를 수행한다. 또한 DO - 178B 인증 기관인 FAA 또는 이를 위임한 DER에 인증에 필요한 데이터를 제공하는 등의 연결 역할을 수행한다. 인증 절차 프로세스 [ 편집 ] 일반적으로 미 항공국에서 그 권한을 위임받은 DER ( Designated Engineering Representative ) 이 항공기 제조사 내에 고용되어 인증 절차를 진행한다. 유럽에서의 항공용 소프트웨어 인증 [ 편집 ] Replace FAA with EASA, JAA or CAA Replace FAR with JAR or CS Replace AC with AMJ 도구 인증 ( Tool Qualification ) [ 편집 ] 소프트웨어 도구를 사용하면 DO - 178B가 요구하는 프로세스를 자동화하고 관리하며 쉽게 적용할 수 있다. DO - 178B 기반의 개발 프로젝트에 사용되는 모든 소프트웨어 도구는 인증 프로세스의 부분이다. 따라서 코드를 자동으로 생성하는 개발 도구는 소스 코드와 동일하게 그 개발 도구로서의 인증 ( qualification ) 을 보장해야한다. 이는 그러한 개발 도구가 생성한 코드가 최종 항공 시스템에 결함을 발생
링크 편집 이 문서는 2019년 5월 12일 ( 일 ) 02 : 38에 마지막으로 편집되었습니다. 모든 문서는 크리에이티브 커먼즈 저작자표시 - 동일조건변경허락 3. 0에 따라 사용할 수 있으며, 추가적인 조건이 적용될 수 있습니다. 자세한 내용은 이용 약관을 참고하십시오. [UNK] 미국 및 다른 국가에 등록되어 있는 Wikimedia Foundation, Inc. 소유의 등록 상표입니다. 개인정보 정책 위키백과 소개 면책 조항 개발자 쿠키 정책 모바일 보기
ard analysis ) 으로부터 결정된 레벨로서 시스템의 고장 영향성을 판단하는 기준으로 삼는 것으로 다음과 같은 단계가 있다. Catastrophic - 추락의 위험을 갖는 고장 위험 수준 Hazardous - 성능 또는 안전에 큰 부정적인 요소를 갖거나 물리적인 변형 또는 과도한 업무 부하로 인해 조종사가 비행을 유지할 수 없는 위험 수준 Major - 심각한 수준이지만 위험한 상태는 아님 ( 예를 들어 승객이 다치는 것보다 불편한 상태 ) Minor - 고장 상태가 보이지만 Major 상태보다는 덜한 상태 수준 ( 예를 들어 승객에게 불편을 초래하거나 비행 경로를 변경하는 상태 ) No Effect - 안전, 비행 조정 또는 조종사 과부하에 영향을 미치지 않은 고장 수준 위와 같은 소프트웨어 레벨에 따라 만족시켜야할 요건의 수와 독립성 수준이 정해진다. 표준에 따르면, " 독립성 " 이란 해당 개발 산출물의 개발자와 그 산출물을 검증하는 책임을 가진 사람이 명확히 분리되어 있어야 한다는 의미이다. [ 2 ]. 레벨 고장영향성 만족요건의 수 독립성 만족요건의 수 A Catastrophic 66 25 B Hazardous 65 14 C Major 58 2 D Minor 28 2 E No effect 0 0 프로세스와 문서들 [ 편집 ] 소프트웨어 레벨 ( A
DO-178B (항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항)는 RTCA 사에 의해 발표된 소프트웨어 개발 표준이다. 이 표준은 RTCA SC-167과 EUROCAE WG-12에 의해 개발되었고, 이를 미국 연방 항공국(FAA)이 항공기 소프트웨어 인증을 위한 용도로 사용할 것을 인정하여 현재 업계에서 상용 항공기이 탑재되는 safety-critical 소프트웨어를 위한 사실 상의(de facto) 표준으로 자리잡았다..