항공용 SW의 안전성을 위한 DO-178C / DO-278A 프로세스

개요

"DO-178C/DO-278A는 미국 연방항공국(FAA)에서 소프트웨어가 탑재된 항공기와 항공/지상장비 부품의 감항인증에 적용하고 있는 항공기 소프트웨어 안전성을 위한 감항인증 규격입니다. DO-178C/DO-278A는 민수 항공기 뿐만 아니라, 무인기를 포함한 군용항공기 개발을 위한 기준인 '군용항공기 표준감항인증 기준(Part1~Part3)' 에서도 요구되고 있습니다.

본 교육을 통해 DO-178C/DO-278A의 항공 시스템에 요구되는 안전성수준(Level A,B,C,D)에 따른 Objectives, Activities, Outputs를 이해하고, 시스템 요구사항으로부터 할당된 SW 요구사항에 대한 구현 완전성, 정확성, 추적성을 보증하기 위한 문서화 방법을 습득할 수 있습니다. 또한 Tool Qualification 규격인 DO-330과 DO-178C/DO-278A의 부속규격인 DO-331(모델기반 개발 규격)을 이해할 수 있습니다."

중점

RTCA DO-178C/DO-278A 개요SW Level(SIL: SAFETY INTEGRITY LEVEL)별 Objectives, Activities, Outputs 이해시스템 요구사항으로부터 할당된 SW 요구사항 구현의 완전성, 정확성, 추적성 보증을 위한 문서화 방안 이해DO-330(Tool Qualification 규격) 및 DO-331(모델기반 개발 규격) 소개

참석대상

프로젝트 매니저시스템 엔지니어 소프트웨어 엔지니어품질보증 관리자

교육 프로그램

일정

세부내용

강사

1 일차

10:00-17:00

1. Course Introduction

2. RTCA DO-178C/DO-278A Overview

3. System Aspects Relating to Software Development

4. Software Life Cycle

5. Software Planning Process

6. Software Development Process

장정훈 부장

강유선 책임

(모아소프트)

2 일차

10:00-17:00

7. Software Verification Process

- Software Reviews and Analyses

- Software Testing

8. Software Configuration Mangement Process

9. Software Quality Assurance

10. Certification Liaison Process and Process Overview

장정훈 부장

강유선 책임

(모아소프트)

3 일차

10:00-17:00

11. Software Life Cycle Data

12. Additional Considerations

13. DO-330 Software Tool Qualification Considerations

14. Supplements to DO-178C/DO-278A

- DO-331 Model-Based Development and Verification

장정훈 부장

강유선 책임

(모아소프트)

* 상기 강의 일정은 진행에 따라 다소 변경될 수 있습니다.

교육 일정 안내

교육장소

서울 송파구 가락동 175-14 연암빌딩 4층 모아소프트 교육장

교육기간

2019년 연내 4회

교육비

33만원 (유저/비유저 모두 유료)

교재

자체제작

교육장

교육신청 및 안내

http://www.moasoftware.co.kr/edu/edu.asp

02.6945.2182 (hmnam@moasoftware.co.kr)

 

 

모아소프트 3월 교육과정 안내

​무엇이든 새로 시작하기 참 좋은 3월, 모아소프트의 교육장으로 여러분을 초대합니다.

(주)모아소프트 3월 정규 교육과정 일정 안내드립니다.

3월 모아소프트 교육센터에서는 

상용 EM 시뮬레이션 소프트웨어 FEKO를 사용하는 방법을 교육하는 "안테나 및 전자파 해석(기초)"

업계 이슈에 따른 모아소프트 인기교육 "항공용 SW의 안전성을 위한 감항인증 프로세스(RTCA DO-178C)",

무기체계 소프트웨어 신뢰성 시험에 대한 방위사업청 요구 수준이 향상됨에 따라 무기체계 소프트웨어 개발에 참여하는 고객에게 신뢰성 시험의 준비, 시험시행, 시험평가에 대한 완벽한 솔루션을 제공하기 위한 신설 교육 "국방소프트웨어 신뢰성 시험"이 3월 진행됩니다.

아래 일정에 맞춰 진행되는 3월 교육은 현재 홈페이지를 접수중이오니 빠른 수강신청 부탁드립니다.

감사합니다. 



* 모아소프트 3월 정규 교육과정 신청 안내

http://www.moasoftware.co.kr/edu/edu.asp?curDate=2017-03-01

 

 


 

 

  


* 모아소프트 연간 정규 교육과정 안내

http://www.moasoftware.co.kr/cscenter/notice_view.asp?idx=27&cPage=1



* 교육비 및 기타 교육 문의

전화  02 - 6945 - 2182 (남혜미 과장)

E-mail  hmnam@moasoftware.co.kr

 

DO-178C SOFTWARE PLANNING PROCESS Objective-5의 이해


* 시작에 앞서 용어는 Section4 의 게시물을 참고하면 된다.

 

1. Objective – 5 의 개요

생산될 소프트웨어에 대해 시스템 안전 달성요건(system safety objective)에 부합하는 소프트웨어 개발 표준을 정의한다.

 

2. Activity


4.2 Software Planning Process Activities


b. 프로젝트에 사용될 소프트웨어 개발 표준은 정의되거나 선택되어야 한다.

g. 소프트웨어 계획 프로세스가 완료 될 때까지, 소프트웨어 계획과 소프트웨어 개발 표준은 변경 통제 및 검토완료 되어야한다.

 

4.5 Software Development Standards

소프트웨어 개발 표준은 소프트웨어 개발 프로세스에 대한 규칙과 제약을 정의한다. 소프트웨어 개발 표준은 소프트웨어 요구사항 표준, 소프트웨어 설계 표준, 소프트웨어 코드 표준을 포함한다. 소프트웨어 검증 프로세스는 이러한 표준을 실제 산출물과 의도한 산출물 간의 적합성을 평가하기 위한 기준으로써 사용한다. 소프트웨어 표준 개발에 대한 활동은 아래를 포함한다.


a. 소프트웨어 개발 표준은 11장을 따라야 한다.

b. 소프트웨어 개발 표준은 주어진 소프트웨어 제품 또는 관련된 제품의 집합이 균등하게 설계되고 실행될 수 있도록 해야 한다.

c. 소프트웨어 개발 표준은 입증 될 수 없거나 안전관련 요구사항과 호환 가능하지 않은 산출물을 생산하는 방법 또는 구성물의 사용을 불가능하게 해야 한다.

d. 강건성은 소프트웨어 개발 표준에서 고려되어져야 한다.

 

3. Applicability by Software Level

해당 ObjectiveSW 레벨 A-C에서는 모두 수행해야 한다.

 

4. Outputs(산출물)

SW Requirements Standards

  소프트웨어 요구사항 표준 자세한 내용은 DO-178C11.6 항목 참조

• SW Design Standards

  소프트웨어 설계 표준 자세한 내용은 DO-178C11.7 항목 참조

• SW Code Standards

  소프트웨어 코드 표준 자세한 내용은 DO-178C11.8 항목 참조

     

    
5. Control Category by Software Level(SW
레벨에 따른 형상관리 수준)

SW 레벨 A, B에서의 산출물 SW Requirements Standards, SW Design Standards, SW Code StandardsCC1 수준으로 형상 관리한다.

SW 레벨 C에서는 산출물 SW Requirements Standards, SW Design Standards, SW Code StandardsCC2 수준으로 형상 관리한다.

 

6. 달성방법

시스템 안전성 목표에 일치하는 요구사항 표준, 설계 표준, 코드 표준을 정의함

요구사항 표준에는 구조적 방법, 식별체계, 표현방법(data flow diagram, UML), 요구사항 개발 및 관리 tool(DOORS), 제약사항. 파생 요구사항 제공 방법 등을 정의함

설계 표준에는 표현방법, 명명규칙, 제어조건, 설계도구 사용상의 제약사항, 복잡도 제한사항 등을 정의함

코드 표준은 Programming 언어, 소스코드 표현방식, 변수/함수 명명규칙, 조건사항, 코딩도구에 대한 제약사항 등을 정의함

 

다음에는 Objective – 6에 대해 알아보도록 하자.

모아소프트 9월 교육과정 안내

​기분 좋은 가을, 모아소프트의 교육장으로 여러분을 초대합니다.

(주)모아소프트 9월 정규 교육과정 일정 안내드립니다.

9월 모아소프트 교육센터에서는 시스템차원(HW+SW)의 통합된 ILS 개발에 도움이 되고자 SW ILS 프로세스, SW 군수지원절차, SW ILS 요소개발을 위한 교육과정 "SW 종합군수지원 기본과정"상용 EM 시뮬레이션 소프트웨어 FEKO를 사용하는 방법을 교육하는 "안테나 및 전자파 해석(기초)" 교육을 진행합니다.

또한 현재 업계 이슈인 "감항인증을 위한 항공용 SW개발 프로세스(RTCA DO-178C)"와

 "LDRA User Training"교육이 9월 진행됩니다.

아래 일정에 맞춰 진행되는 9월 교육은 현재 홈페이지를 접수중이오니 빠른 수강신청 부탁드립니다.

감사합니다. 



* 모아소프트 9월 정규 교육과정 신청 안내

http://www.moasoftware.co.kr/edu/edu.asp?curDate=2016-09-01



 

 

  


* 모아소프트 연간 정규 교육과정 안내

http://www.moasoftware.co.kr/cscenter/notice_view.asp?idx=22&cPage=1



* 교육비 및 기타 교육 문의

전화  02 - 6945 - 2182 (남혜미 과장)

E-mail  hmnam@moasoftware.co.kr

감항인증을 위한 DO-178C

항공용 SW개발 프로세스 컨설팅


감항인증을 위한 항공용 SW 안전성 국제 규격인 DO-178C Level A 기준에 따른

SW 개발 프로세스 구축 및 인증획득 지원 컨설팅을 수행합니다.




1. GAP 분석 및 개선사항 도출                                     


▶ GAP 분석 및 개선 전략 수립

- DO-178C 표준 프로세스 대비 고객의 현행 프로세스와의 GAP 분석

- 효과적인 GAP 감소를 위한 개선 전략 및 일정 수립에 대한 보고서 제공




2. 개선전략 수립 및 활동                                              


▶ 개발 프로세스 구축 및 활동 수행방안 제시

- GAP 분석 결과를 토대로 DO-178C에 따른 프로세스 구축

- 71개의 Objectives 달성을 위한 단계별 검증 활동 수행방안 제시

- 자동화 도구를 이용한 단계별 요구사항 추적성 확보방안


▶개발 단계별 시험환경 구축 및 시험방안 제시

- 구현 및 통합 시험단계를 위한 arget 시험환경 구축

- 시험 자동화 도구(LDRA)를 이용한 정적분석 및 동적시험 방안 제시


▶산출물 제공

- Level A의 71개 Objectives를 달성하기 위한 검토 체크리스트 제공

- 20여종의 전체 개발 단계 산출물 템플릿 제공




3. 프로세스 및 엔지니어링 교육                                    


▶ 감항인증을 위한 DO-178C 프로세스 교육

▶ 임베디드 프로그래밍 최적화 및 SW 테스트를 위한 엔지니어링 교육

▶ 고객 방문교육 및 사내 정기교육




4. 인증획득 지원                                                          


▶ DO-178C 기준의 인증심사 활동 지원

- FAA 인증심사원(DER) 보유

- FAA SOI)Stage Of Involvement)

  #1 ~ #4 체크리스트 기준으로 모의수행 지원

  (Planning, Development, Verification, Certification 단계 리뷰)


▶ 장비품의 기술표준폼 표준서(TSO) 지원

- TSO-C9 :  자동 조종 장치

- TSO-C129a : GPS를 이용한 탑재식 추가 항행 장치

- TSO-C112, TSO-C10b, TSC-C30c 등의 기술표준서 지원


▶DO-178C Tool Qualification Suppot Pack 지원

- SW 측면의 인증 계획서 (PSAC)

- Tool Qualification 계획서 (TQP)

- Tool 수행 완료 요약서 (TAS)



===========================================================================


컨설팅 담당 장정훈 차장 02.6945.2120

기술지원 문의 강유선 선임 02.6945.2141




DO-178C SOFTWARE PLANNING PROCESS Objective-2의 이해



시작에 앞서 용어는 Section4의 게시물을 참조한다.

 

1. Objective-2의 개요

소프트웨어의 생명주기는 피드백 메커니즘, 완료 기준을 포함하는 프로세스로 결정된다.

자세한사항은 DO-178C 4.1b항목을 참조한다.

 


2. Activity 

  1. 4.2i: 사용자 수정 가능 소프트웨어(User-modifiable software)가 계획되어 있는 경우, 설계와 관련된 관련 프로세스, 도구, 환경 및 데이터 항목은 소프트웨어 계획 및 기준에 명시해야 한다. 

  1. 4.3b: 아래와 같은 소프트웨어의 계획을 정함으로써, 소프트웨어 생명주기 프로세스의 완료 기준 (transition criteria)조건을 만족할 수 있다.

  1. 다른 프로세스로부터의 피드백을 포함하여 프로세스에 입력한다.

  2. 입력에 따른 행동을 할 수 있는 통합 프로세스 활동을 한다.

  3. 도구, 방법, 계획 및 절차의 유효성이 있어야 한다.

 

3. Applicability by Software Level

해당 Objective는 소프트웨어 레벨 A~C 에서는 모두 달성해야 한다.


 

4. Outputs(산출물)

 

PSAC (Plan for Software Aspects of Certification)

         소프트웨어 인증계획 문서 자세한 내용은 DO-178C11.1항목 참조

  • SDP (Software Development Plan)

         소프트웨어 개발 계획 문서 자세한 내용은 DO-178C11.2항목 참조

  • SVP (Software Verification Plan)  

         소프트웨어 검증 계획 문서 자세한 내용은 DO-178C11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)

         소프트웨어 구성 관리 계획 문서 자세한 내용은 DO-178C11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)

         소프트웨어 품질 보증 계획 문서 자세한 내용은 DO-178C11.5항목 참조

 


5, Control Category by Software Level

 

소프트웨어 레벨 A, B의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1을 기준으로 형상 관리하며, 소프트웨어 레벨 C의 산출물 PSAC CC1을 기준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2기준으로 형상 관리한다.

 

 

다음에는 Objective-3에 대해 알아보겠다.

 

Objective-1 The activities of the software life cycle processes are defined.

이번 포스팅에서는 Section 4: 소프트웨어 계획 프로세스의 Objective-1을 살펴보도록 하자.

1. Objective-1의 개요

Objective-1 소프트웨어 생명주기 프로세스의 활동을 정의한다.

상세 내용으로 4.1.a “시스템 요구사항과 소프트웨어 레벨에 맞는 소프트웨어 생명주기의 소프트웨어 개발 프로세스와 공통 프로세스의 활동을 정의한다.”를 참조 한다.

 

 


2. Activities

Objective-1을 만족하는 소프트웨어 계획 프로세스에 대한 활동은 다음과 같다:

  • 4.2.a 소프트웨어 생명주기 프로세스를 수행하는 인원들에게 방향을 제공할 수 있는 소프트웨어 계획을 개발해야 한다.

  • 4.2.c 소프트웨어 개발 프로세스에서 오류 방지를 돕거나 결함 검출을 제공하는 방법 및 도구를 선택해야 한다

  • 4.2.d 소프트웨어 계획에서의 전략들 사이에 일관성을 제공하기 위하여, 소프트웨어 계획 프로세스는 소프트웨어 개발 프로세스와 공통 프로세스 간의 일치성을 제공해야한다.

  • 4.2.e 프로젝트가 진행됨에 따라 소프트웨어 계획을 수정하기 위한 절차를 명시해야 한다.

  • 4.2.g 소프트웨어 계획 프로세스를 완료하기 위해서는, 소프트웨어 계획과 소프트웨어 개발 표준을 변경 통제 하에서 검토를 완료해야 한다.

  • 4.2.i 사용자 수정 가능 소프트웨어(User-modifiable software)가 계획되어 있는 경우, 설계와 관련된 관련 프로세스, 도구, 환경 및 데이터 항목은 소프트웨어 계획 및 기준에 명시해야 한다.

  • 4.2.l 공급 업체를 통해 소프트웨어 개발 활동을 수행하는 경우, 계획은 공급 업체를 관리할 수 있도록 해야한다.

  • 4.3.c 인증 제품에 사용하기 전에, 소프트웨어 변경을 구현하기 위해 사용하는 절차를 소프트웨어 계획에 명시해야 한다. 이러한 변경 사항은 다른 프로세스로부터의 피드백 결과이거나 소프트웨어 계획을 변경시킬 수도 있다.

 

3. Applicability by Software Level

Objective-1은 소프트웨어 레벨 A, B, C, D 모두를 수행해야 한다.

 

4. Outputs(산출물)

  • PSAC (Plan for Software Aspects of Certification)
    소프트웨어 인증 계획서자세한 내용은 DO-178C 11.1항목 참조

  • SDP (Software Development Plan)
    소프트웨어 개발 계획서자세한 내용은 DO-178C 11.2항목 참조

  • SVP (Software Verification Plan)
    소프트웨어 검증 계획서자세한 내용은 DO-178C 11.3항목 참조

  • SCM Plan (Software Configuration Management Plan)
    소프트웨어 형상 관리 계획서자세한 내용은 DO-178C 11.4항목 참조

  • SQA Plan (Software Quality Assurance Plan)
    소프트웨어 품질 보증 계획서자세한 내용은 DO-178C 11.5항목 참조

 

5. Control Category by Software Level

소프트웨어 레벨 A, B의 산출물 PSAC, SDP, SVP, SCM Plan, SQA Plan CC1을 기준으로 형상 관리하며 소프트웨어 레벨 C, D의 산출물 PSACCC1을 기준으로, 산출물SDP, SVP, SCM Plan, SQA Plan CC2기준으로 형상 관리한다.

 

다음 포스팅에서는 Objective-2에 대해 알아보도록 하자.

 

Section 4: software planning process


Section에서는 소프트웨어 계획 프로세스의 objectives 및 활동을 설명하고자 한다.

이 프로세스를 통해 소프트웨어 개발 프로세스와 공통 프로세스가 지향하는 계획과 기준을 생성한다. Annex A의 표 A-1은 소프트웨어 레벨에 따른 소프트웨어 계획 프로세스의 objectives outputs이 요약되어 있다.

  

 

 

Table A-1를 보는 법은 Objective-1을 예를 들어 설명하면 아래와 같다.

1. Objective-1소프트웨어 생명주기 프로세스의 활동을 정의한다.”이고, 자세한 내용은 4.1.a의 내용을 참조한다.

 

2. 수행해야 하는 활동은 4.2.a, 4.2.c, 4.2.c, 4.2.d, 4.2.e, 4.2.g, 4.2.i, 4.2.l, 4.3.c의 각 절을 한다.

 

3. 소프트웨어 레벨 A ~ D 해당하는 소프트웨어는 Objective를 만족한다.
(○ : Objective
를 만족해야 한다, ● : Objective를 독립적으로 만족해야 한다
.)
여기서 독립적 만족이란, 개발자가 아닌 다른 사람 또는 도구를 통해 검증하는 객관적 평가로 신뢰성을 보장한다는 의미를 포함한다.

 

4. 산출물은 PSAC, SDP, SVP, SCM Plan, SQA Plan이 있고, 각 산출물은 11.1, 11.2, 11.3, 11.4, 11.5절을 참조한다.

 

5. 소프트웨어 레벨 A, B, C, D에서 로 표시된 산출물은 CC1을 기준으로 형상 관리하며, 로 표시된 산출물은 CC2를 기준으로 형상관리 한다. 통제 수준(Control Category) 기준에 따른 형상 관리 활동은 Table 7-1을 참조한다.
(
① : 산출물은 Control Category 1(CC1) objectives를 만족한다, ② : 산출물은 Control Category 2(CC2) objectives를 만족한다.)

 

 


이어 다음 포스팅에서 Objective-1에 대해 알아보도록 하자.

 

 

 

 

DO-178C(항공용 소프트웨어 감항인증)에 적합한

정적분석을 활용한 소프트웨어 동적 시험 프로세스

 

 

DO-178C는 항공기 소프트웨어 오작동으로 인한 항공기 사고 위험을 최소화하기 위한, 항공기 소프트웨어 안전성(Safety)에 대한 국제적인 감항 인증 표준 규격으로 소프트웨어 계획, 요구사항, 설계 구현 및 통합, 검증, 형상관리, 품질관리, 인증 프로세스 등의 소프트웨어 개발 프로세스를 가지며, 그 중 검증 및 테스트와 관련된 부분이 가장 중요한 이슈로 부각되고 있다. 

 

항공용 소프트웨어 안전성 확보를 위해서는 DO-178C(항공용 소프트웨어 안전성 및 감항인증 국제 규격)에 적합한 테스트를 수행하여야 하며 DO-178C Annex A. Table 7에서 테스트 수행에 대한 목표(Objectives)를 명확하게 정의하고 있다.

 

DO-178C의 테스트 요건은 테스트 절차, 테스트 케이스 생성 및 수행, 테스트 결과 분석, 테스트 커버리지-Statement Coverage(SC), Branch Coverage(BC), Modified Condition/Decision Coverage(MC/DC)- 달성 등이 있다.

 

다년간 수행한 소프트웨어 시험에서 나타난 주요 문제점 및 원인은 아래와 같다.  이에 모아소프트에서는 이러한 문제점을 개선하기 위해 “정적분석 기반의 동적시험 프로세스”를 구축하였다.

 

현상 및 문제점

원인

소프트웨어 설계문서와

소스코드의 불일치

SW개발팀이 작성한 설계문서는 초기 버전이며,

최종적으로 완료전에 현행화할 예정이므로 테스트

단계에서는 테스트 설계에 직접 활용하기 어려움

테스트 케이스 설계 시간소요

소스코드의 각 단위함수에 대한 테스트 커버리지를 위해 필요한

입력변수의 입력값이 테스트를 수행하면서 사후적으로 작성되고 있음

소스코드 실행율(SC,BC, MC/DC)

100% 달성 시간소요

소스코드 실행율 100% 달성을 위해 일부 소스코드를

수정하고 다시 적용하기까지 시간이 소요됨

2차 소스코드에 대한

재시험 수행의 비효율성

개발업체로부터 수정된 소스코드를 다시 전달받아서

재수행 하기까지 시간이 소요됨

  

[단계 1] 정적분석 도구 활용

 

정적분석 도구인 LDRA Tested의 주요 기능은 다음과 같다.

(테스트에 사용될 자동화 도구는 LDRA이며, LDRA 도구는 DO-178C 규격에 대한 Certification을 보유하고 있다.)

- 소스코드에 대한 코딩룰 검사 (MISRA coding standard 1,500 여개의 코딩표준 검사)

- 소스코드에 대한 품질 메트릭 산출 (Cyclomatic Complexity, Testability 40 여개의 Quality Metric 산출)

- 단위함수에 대한 input/output parameter call function 정보 제공

- Call graph, Flow diagram 등 소스코드에 대한 시각적 구조 정보 제공

 

 

[단계 2] 테스트 케이스 자동 생성 

LDRA Testbed에서 정적분석을 수행하면 생성되는 Quality Review Report*.glh(정적분석 결과 파일)로부터 단위함수에 대한 정보(Function I/O정보, Cyclomatic Complexity, Testability, Function Call정보)를 추출하여 테스트 케이스를 설계한다.

테스트 케이스 설계 도구(TCMAN)를 이용하여 단위함수의 input/output 변수 정보를 Excel 문서로 생성하고 동적시험에서 필요한 *.tcf (테스트 케이스 파일)를 생성한다.

 

[단계 3] 테스트 실행 및 결과보고서

동적시험 도구인 LDRA TBrun을 사용하여 *.tcf 파일을 적용하여 테스트를 수행하고, 국제 SW 분야 표준 서식(ISO/IEC/IEEE 29119, IEEE Std. 829)의 테스트결과보고서(*.doc)을 자동으로 생성하며 테스트커버리지(코드실행률) 및 결함을 기록한다.

정적분석 기반의 동적시험 프로세스를 적용하여 소스코드에 대한 정적분석 결과에서의 코드 품질매트릭과 함수 정보로부터 자동 생성된 테스트케이스에 의한 동적시험을 수행할 수 있었으며, 국제 표준의 시험결과보고서를 자동 생성하여 제공함으로써 항공 안전성 감항인증에 적합한 SW개발 및 테스트 프로세스의 효율성과 SW신뢰성 및 품질향상을 제공할 수 있다.



컨설팅 담당 장정훈 차장 02.6945.2120

기술지원 문의 강유선 선임 02.6945.2141



DO-331 규격 소개

 

1. DO-331 개요

항공분야 소프트웨어와 관련된 개발 표준으로는 RTCA에서 제정한 DO-178C DO-278A가 있다. 항공기에 탑재되는 소프트웨어에 대한 개발 표준은 DO-178C인 반면, 지상용 항공장비에 탑재되는 소프트웨어를 위한 개발 표준은 DO-278A이다.

포스팅에서 소개하고자 하는 DO-331DO-178CDO-278A 규격의 모델 기반 개발 및 검증을 위한 보충 문서이며, DO-178C 규격을 기준으로 설명한다.

DO-331에는 DO-178C를 위한 모델기반 개발 및 검증을 위해 해결해야 하는 목표(objectives), 활동(activities), 설명 텍스트(explanatory text), 소프트웨어 라이프 사이클 데이터가 포함되어 있다.

DO-178C DO-331 모델 기반 설계 사용자에게 있어 DO-178B의 오래된 문제는, DO-178B 목표를 모델 기반 설계 아티팩트(artifact)에 매핑(mapping)할 때의 불확실성이다. 이러한 매핑 문제를 해결하는 것이 모델 기반 설계에 중점을 둔 DO-178C 서브그룹(SG-4)의 주요 목표였다. 단일 매핑으로는 충분하지 않았기에 DO-331에서는 몇 가지 매핑을 추가적으로 제공했다. 일부는 설계와 코드 생성에 사용된 것과는 별개인 사양의 모델 개념을 포함하기도 한다. 이 외 또 다른 개념은, 코드 생성에 사용되는 상세한 요구사항 역할을 하는 설계 모델이다. 이렇듯 설계(시스템 및/또는 소프트웨어)에 모델을 사용할 수 있고 모델 외부의 요구사항을 사용하여 개발해야 한다.

소스 코드는 설계 모델에서 직접 생성할 수 있다(자동 또는 수동). 이 표준에서 언급한 접근 방식 중 하나는 시스템 설계에 처음 사용한 모델을 가공하여 소프트웨어 설계 및 코드 생성에 재사용하는 것이다. 이 방법은 모델 기반 설계를 사용하는 UAV 시스템 및 소프트웨어 개발자를 위해 ARP 4754DO-178C를 매우 자연스럽게 연결한다.

 

2. 모델 기반 개발 및 검증의 특성(Characteristics of Model-Based Development and Verification)

소프트웨어 개발 및 검증 프로세스의 일부로서, 모델은 부분적으로 또는 완전히 소프트웨어 요구사항 또는 아키텍처를 나타낼 수 있다.

모델링 기법에 의해 모델들은 특징지어지고 소프트웨어 생명주기를 나타내는데 사용된다. 모델링 기법은 모델링 언어와, 모델링 언어를 사용하는 특정 방법의 결합이다. 정확하고 완전한 소프트웨어 수명주기 데이터의 특정 유형을 표현하는 모델능력은 사용모델링 기법에 의존한다. 사용 모델링 기술은 유형과 모델에 의해 표현되는 정보의 추상화 수준에 적합해야 한다. 소프트웨어 모델 표준모델링 기법은, 설명하고 이 기술을 목적에 맞는 방법의 시범을 지원하는 수단이다.

 

3. 소프트웨어 시험(Software Testing)

DO-178C6.4절은 변경되지 않았으며 시뮬레이션 실행 가능한 오브젝트 코드 검증의 일부로서 사용되는 경우, 이 섹션 MB.6.8.2 DO-178C 6.4절 에 추가 적용된다.

 

4. 소프트웨어 검증 계획(Software Verification Plan)

소프트웨어 검증 계획(SVP)은 검증 절차의 설명과 소프트웨어의 검증 절차 목적을 만족하기 위해 사용되어야 한다.

 

5. 소프트웨어 코드 표준(Software Code Standards)

소프트웨어 코드 표준은 DO-178C11.8절은 변경하지 않으며 이를 적용한다.

 

6. 소프트웨어 검증 케이스와 과정 (Software Verification Cases and Procedures)

소프트웨어 검증 케이스와 과정이 어떻게 구현되는지 소프트웨어 인증 케이스 및 절차의 세부 사항으로, 세부내용은 아래와 같다:

- 검토와 분석과정 : 검토 또는 분석 방법의 범위와 깊이는 분석 방법 중 소프트웨어 인증 계획에 대한 설명에 추가하여 사용된다.

- 테스트 케이스 : 각 테스트 케이스의 목적, 입력, 조건, 예상된 결과는 테스트 커버리지와 통/실패의 기준이 된다.

- 테스트 절차 : 단계별 명령을 각 테스트 케이스가 어떻게 실행하는지, 어떻게 평가하는지, 테스트환경이 어떻게 사용되는지 확인한다.

- 시뮬레이션 케이스 : 시뮬레이션 케이스의 목적은 입력, 조건, 결과 값 기대, 그리고 통과/실패의 기준이 된다.

- 시뮬레이션 과정 : 단계별 명령을 시뮬레이션 케이스가 어떻게 실행되는지, 어떻게 시뮬레이션 결과가 평가되는지, 어떤 환경에서 사용되는지 확인한다.

 

7. 소프트웨어 검증 결과(Software Verification Results)

소프트웨어 검증결과는 소프트웨어 검증절차 진행을 통해 만들어진다. 소프트웨어 검증 결과는 다음 내용을 만족시켜야 한다.

- 각각의 검토, 분석, 시뮬레이션 그리고 테스트는 수행과정 동안의 성공 또는 실패 과정과  최종 성공/실패 결과를 나타낸다.

- 분석 시뮬레이션 또는 시험평가 구성항목, 모델, 소프트웨어 버전을 확인한다. 높은 수준의 요구사항, 낮은 수준의 요구사항 또는 소프트웨어 구조를 나타내는 모델을 이용한다면, 모델의 구성이 확인되어야 한다.

- 테스트의 결과, 시뮬레이션, 검토, 분석, 커버리지 분석, 추적분석 결과는 시뮬레이션을 지원하여 포함한다.

- 발견되는 불일치 문제를 기록하고 문제 보고를 통해 추적한다. 또한 증명은 소프트웨어 검증결과를 고려하는 소프트웨어 프로세스에 의해 공급된 시스템 프로세스를 평가하고 제공한다.

 

8. 소프트웨어 모델 표준(Software Model Standards)

소프트웨어 모델표준은 각각의 모델타입에 따른 모델링 기법에 의해 정의되며 모델링 기법에 대한 포함사항은 다음과 같다

- 메소드와 도구는 모델을 개발하기 위해 사용된다.

- 언어를 모델링 하는데 사용한다. 각각의 모델링 언어들은 모델 소프트웨어 생명주기 데이터의 종류에 대하여 문맥 구분과 의미를 정의하는 데이터를 참조한다. 이 모델링 언어의 일부 기능에 대해 사용을 제한할 수 있다.

- 모델링 언어와 툴의 사용을 위해 스타일 설명지침 및 복잡도를 제한한다. 예를 들어 명명규칙, 다이어그램 레이아웃, 허용요소, 중첩 레벨의 최대 수, 각 다이어그램 모델 요소의 최대 수, 레이어 구조의 최대수 등이다.

- 모델링 툴(예를 들어, 스케줄링 기법 또는 글로벌 데이터)과 모델 요소의 라이브러리 사용을 제한한다.

- 메소드는 요구사항과 기타 생명주기 간의 추적을 설정하기 위한 의미와 모델의 요구사항 범위를 설명하기 위해 사용된다.

- 메소드는 모델 및 시스템의 안정성평가 방법을 포함하여 시스템 프로세스에서 파생된 요구사항을 제공하기 위한 방법에 포함되어 파생된 요구사항을 확인하고 분리하는데 사용될 수 있다.

- 메소드는 시스템 안정성 평가 처리를 포함하여 시스템 프로세스에서 파생된 요구사항을 제공하고, 그 모델에서 파생된 요구사항의 정의와 확인을 위해 사용된다.

- 구체적 모델 또는 디자인 모델에 의해 표현되는 정보의 유형에 대한, 기술의 적합성에 대한 이론적 근거이다.

 

9. 툴 인증 요구(Tool Qualification is Needed)

이 문서의 프로세스는 제거, 감소, 또는 섹션 MB.6에 지정된 것으로 확인되는 (출력 없는) 소프트웨어 툴을 사용함으로써, 자동화 될 때 툴의 자격이 필요하다.

툴의 인증 절차의 목적은 도구가 제공하는 프로세스의 제거, 감소, 또는 자동화된 프로세스의 공급을 적어도 동등한 신뢰성을 제공한다는 것을 보장한다.

툴 인증 절차는 단일 툴, 툴 내의 도구, 또는 하나 이상의 기능의 집합에 적용 할 수 있다. 툴의 다양한 기능을 위해 툴의 기능 보호를 입증할 수 있다면 오직 그 기능들은 제거, 감소, 자동화된 소프트웨어의 생명주기 과정과 검증 되지 않은 결과는 자격이 필요하다. 보호는 도구 기능이 또 다른 도구의 기능에 악영향을 줄 수 없도록 안전한 메카니즘을 사용한다.

툴은 도구를 사용하는 의도가 시스템을 지원하는 인증의 소프트웨어 측면에 대한 계획에 언급된 특정 시스템에서 사용하기 위해 자격이 부여된다. 이전 시스템에서 규정한 툴이 다른 시스템에서 사용하기 위해 제안 되는 경우, 다른 시스템의 맥락에서 재 규정한다.

 

10. 툴 자격수준 결정(Determining the Tool Qualification Level)

DO-178C12.2.2절을 적용한다.

 

11. 툴 검증 과정(Tool Qualification Process)

DO-178C12.2.3절을 적용한다.

 


DO-178C 컨설팅 전문기업

(주)모아소프트

컨설팅 담당 장정훈 차장 02.6945.2120

기술지원 문의 강유선 선임 02.6945.2141



+ Recent posts