항공용 소프트웨어 승인...

붙임 4-3

항공용 소프트웨어 승인 지침서(Software Approval Guidelines)

2011. 1. 3

항 공 정 책 실

항 공 기 술 과

국토해양부 항공용 소프트웨어 승인 지침서

제정: 2009.07.27 개정: 2011.1.3 - i -

개 정 기 록 표

(RECORD OF AMENDMENTS)

개정차수(Revision No.)

제/개정일자(Revision Data)

철입일자(Insertion Data)

철입자(Insertion by)

근 거(Reference)

원 판 2009.07.27제정(항공기술과

기술지침서 제01호)

1차 2011.1.3개정(FAA Notice

8110.110 13장에 반영)


제정: 2009.07.27 개정: 2011.1.3 - ii -

목 차

항공용 소프트웨어 승인 지침서

(Software Approval Guidelines)

제1장 총 칙

제1조(목적) ·························································································································································· 1제2조(적용) ·························································································································································· 1제3조(정의) ·························································································································································· 1

제2장 소프트웨어 검토 절차

제4조(소프트웨어 검토 협의) ·························································································································· 3제5조(소프트웨어 검토 절차) ·························································································································· 3제6조(소프트웨어 계획 검토: SOI #1) ·········································································································· 4제7조(소프트웨어 개발 검토: SOI #2) ·········································································································· 5제8조(소프트웨어 검증 검토: SOI #3)) ········································································································ 7제9조(최종 소프트웨어 검토: SOI #4) ·········································································································· 8제10조(소프트웨어 검토 절차에 대한 추가 고려사항) ·············································································· 9제11조(소프트웨어 검토 준비) ························································································································ 9제12조(소프트웨어 검토 신청자 통지) ·········································································································· 9제13조(소프트웨어 검토 수행) ······················································································································ 10제14조(소프트웨어 검토결과의 기록) ·········································································································· 10제15조(소프트웨어 검토 종결 회의) ············································································································ 10제16조(소프트웨어 검토 보고서) ·················································································································· 11제17조(주요사안검토서 식별 및 준비) ········································································································ 11

제3장 소프트웨어 프로젝트에 대한 인증

제18조(참여도의 결정) ···································································································································· 11

제4장 소프트웨어 합치성 검사

제19조(소프트웨어 합치성 검사) ·················································································································· 14제20조(소프트웨어 부품 합치성 검사) ········································································································ 14제21조(소프트웨어 설치 합치성 검사) ········································································································ 15

제5장 현장로딩가능 소프트웨어(FLS)의 승인

제22조(FLS의 승인) ········································································································································ 16제23조(FLS의 설치에 대한 고려사항) ········································································································ 18제24조(FLS 유지보수 및 부품 표식 고려사항) ························································································ 18


제정: 2009.07.27 개정: 2011.1.3 - iii -

제6장 부품등 제작자 증명 절차를 통해 동일성을 판정하는

현장로딩가능 소프트웨어의 승인

제25조(동일성 수립) ········································································································································ 19제26조(TSO의 적용성) ··································································································································· 21

제7장 사용자수정가능 소프트웨어(UMS)를 포함하는 항공용 시스템 및 장비의

승인

제27조(UMS 안전성 고려사항) ····················································································································· 21제28조(시현 데이터에 대한 고려사항) ········································································································ 22제29조(항공기 성능 파라미터의 변경) ········································································································ 22제30조(보호) ······················································································································································ 22제31조(수정 불가 구성품을 보호하는데 사용되는 툴) ············································································ 22제32조(데이터 요구조건) ································································································································ 22

제8장 이전 개발 소프트웨어: RTCA DO-178B의 레벨 D 기준 적용

제34조(레벨 D의 PDS 승인) ························································································································ 24

제9장 RTCA DO-178B를 사용한 소프트웨어 툴의 검정

제35조(검정 여부의 결정) ······························································································································ 25제36조(검정 기준의 결정) ······························································································································ 25제37조(검정에 필요한 데이터 및 그 가용성) ···························································································· 26제38조(작동 요구조건 데이터의 수락성 평가) ·························································································· 27

제10장 RTCA DO-178B를 이용한 레거시 시스템의 소프트웨어 변경 승인

제39조(레거시 시스템의 소프트웨어 변경) ································································································ 30제40조(레거시 시스템의 소프트웨어 변경 승인 절차) ············································································ 32

제11장 소프트웨어 변경 영향 분석

제41조(변경영향분석) ······································································································································ 34제42조(변경영향분석 절차) ···························································································································· 36

제12장 소프트웨어 라이프사이클 데이터

제43조(재사용에 적합한 소프트웨어) ·········································································································· 37제44조(안전성 고려사항) ································································································································ 38제45조(재사용에 영향을 주는 인자) ············································································································ 38제46조(재사용 승인) ········································································································································ 39

제13장 공급업체 관리 등

제47조(공급업체 감독) ···································································································································· 39제48조(소프트웨어 문제 보고) ······················································································································ 41제49조(항공용 시스템 데이터베이스 및 항공 데이터베이스의 확인) ·················································· 43


제정: 2009.07.27 개정: 2011.1.3 - iv -

제50조(소프트웨어 개발 및 검증 환경 관리) ···························································································· 44

[별지 1] ······························································································································································ 46[별지 2] ······························································································································································ 47


제정: 2009.07.27 개정: 2011.1.3 - 1 -

항공용 소프트웨어 승인 지침서

(Software Approval Guidelines)

제정 2009.07.27(항공기술과 기술지침서 제01호)개정 2011.1.3(항공기술과 기술지침서 제01호)

제1장 총 칙

제1조(목적) 이 지침서는 항공용 컴퓨터에 사용되는 소프트웨어를 승인함에 있어

감항엔지니어 등이 RTCA DO-178B(Software Considerations in Airborne Systems and Equipment Certification)를 적용하는 보다 바람직한 방법과 절차 등을 안내함을

목적으로 한다.

제2조(적용) 이 지침서는 감항엔지니어 등이 다음 각호의 규정이 정하는 증명 또는

승인업무(이하 “증명등”이라 한다)를 수행함에 있어서 소프트웨어 승인업무에 관한

세부적인 절차와 방법 등을 안내한다. 다만, 본 지침서에 수록된 방법과 절차 이외에

다른 방법 등을 적용하는 것이 바람직할 경우, 인증 신청자가 다른 방법과 절차 등을

활용해서 적합성 등을 입증 및 적용하도록 할 수 있으며 감항엔지니어 등도 다른

절차와 방법 등을 활용할 수 있다. 1. 국토해양부 고시 항공기기술기준(KAR) Part 21 2. 국토해양부 훈령 항공기 형식증명 지침

3. 국토해양부 고시 항공기 기술표준품 형식승인 기준

제3조(정의) 이 지침서에서 사용하는 용어의 정의는 다음 각 호와 같다.1. “인증당국”이라 함은 소프트웨어 라이프사이클 데이터를 수락 및/또는 승인하는

정부기관을 말한다. 소프트웨어 승인을 담당하는 인증 담당자는 국토해양부 항공

기술과의 감항엔지니어 및 국토해양부 장관이 지정한 항공기등의 인증에 관한

전문검사기관의 엔지니어이다.2. “인증 신인도(credit)”라 함은 소프트웨어 절차, 소프트웨어 제품, 실증 등이 인증

요구조건을 만족하였다는 인증 당국의 수락을 말한다(RTCA DO-178B 용어정의

와 RTCA DO-248B 3.47항을 참조).3. “형상 아이템”이라 함은 (1) 소프트웨어 형상관리 목적으로, 하나의 유닛으로

간주되는 하나 이상의 소프트웨어 컴포넌트 또는 (2) 소프트웨어 형상관리

목적으로, 하나의 유닛으로 간주되는 소프트웨어 라이프사이클 데이터를

말한다(RTCA DO-178B 용어정의와 RTCA DO- 248B 3.46항을 참조).


제정: 2009.07.27 개정: 2011.1.3 - 2 -

4. “현장로딩가능 소프트웨어(Field-Loadable Software, FLS)”라 함은 설치할 때 장

비를 제거하지 않고 로딩할 수 있는 소프트웨어를 말한다. FLS는 실행 코드 또는

데이터에도 적용할 수 있다(RTCA DO-178B 2.5항 참조). FLS는 또한 수리창에서

현장교환유닛(Line Replace Unit, LRU)에 로딩되는 소프트웨어를 포함한다. 5. “지적사항(finding)”이라 함은 하나 이상의 RTCA DO-178B 목표에 대한 적합성

입증 실패를 식별하는 것을 말한다.6. “관찰사항(observation)”이라 함은 잠재적인 소프트웨어 라이프사이클 절차의

개선사항을 식별하는 것을 말한다. 관찰사항은 RTCA DO-178B의 적합성 문제는

아니어서, 소프트웨어 승인 전에 언급할 필요는 없다.7. “옵션선택가능 소프트웨어”라 함은 사용자가 활성화 할 수 있거나 비행승무원이

선택하거나 지상 요원이 활성화 할 수 있는 승인되고 확인된 장비품 또는

장비품의 조합을 포함하는 소프트웨어를 말한다. (RTCA DO-178B 2.4항 참조).8. “최초 인증 프로젝트”라 함은 완료된 인증 프로젝트에서 소프트웨어 라이프사이클

데이터의 최초 사용을 말한다. 9. “재사용”이라 함은 이전의 승인된 소프트웨어 라이프사이클 데이터를 변경하지

않고 계속하여 사용하는 것을 말한다.10. “검토”라 함은 RTCA DO-178B의 목표에 대한 적합성을 평가하기 위해

소프트웨어 라이프사이클 데이터, 소프트웨어 프로젝트 진행상황, 기록, 그 외

증거 등을 검사하고 조사하는 활동을 말한다. 11. “샘플링”이라 함은 검사나 분석을 위해 소프트웨어 라이프사이클 데이터의

대표적인 표본을 선정하는 것을 말한다. 12. “소프트웨어”라 함은 컴퓨터 프로그램과 컴퓨터 시스템의 운용에 관련된 문서와

데이터를 말한다(RTCA DO-178B 용어정의 참조).13. “소프트웨어형상색인(Software Configuration Index, SCI)”이라 함은 소프트웨어

제품의 형상 목록을 말한다. 14. “소프트웨어 라이브러리”라 함은 소프트웨어 개발, 사용, 변경에 도움을 주도록

계획된 소프트웨어 및 관련 데이터와 문서의 관리 저장소를 말한다(RTCA DO-178B 용어정의 참조).

15. “소프트웨어 라이프사이클 데이터”라 함은 계획, 지시, 설명, 정의, 기록, 활동의

증거를 제공하기 위해 소프트웨어 라이프사이클 동안 생성되는 데이터를

말한다(RTCA DO-178B 11.0항 참조).16. “소프트웨어 라이프사이클 환경 형상 색인”이라 함은 소프트웨어 라이프사이클

환경의 형상 목록을 말한다(RTCA DO-178B 11.15항 참조).17. “소프트웨어 계획과 표준”이라 함은 소프트웨어 개발 절차와 통합 절차를

지시하기 위한 일련의 데이터를 말한다(RTCA DO-178B 4.0항 및 11.1～11.8항

참조).18. “소프트웨어 툴”이라 함은 다른 프로그램을 개발, 시험, 분석, 생성, 변경,

문서화하는데 도움을 주는 컴퓨터 프로그램을 말한다(RTCA DO-178B 용어정의


제정: 2009.07.27 개정: 2011.1.3 - 3 -

참조). 19. “차후 인증 프로젝트”라 함은 최초 인증 프로젝트에서 생성된 소프트웨어

라이프사이클 데이터를 재사용하는 후속 프로젝트를 말한다.20. “인증 신인도 시험”이라 함은 규정에 따라 적합성을 입증하기 위한 목적으로

인증당국의 승인을 받은 시험 계획하에서 시행되는 시스템 인증 시험을 말한다.21. “도구 검정(tool qualification)”이라 함은 특정 항공용 시스템의 환경에서

소프트웨어 도구에 대한 인증 신인도를 획득하기 위한 절차를 말한다(RTCA DO-178B 12.2항 및 용어정의 참조).

22. “사용자수정가능 소프트웨어(User-Modifiable Software, UMS)”라 함은 인증

당국, 동체 제작자, 장비 판매업자의 검토 없이도 항공기 운용자가 수정하도록

의도된 소프트웨어를 말한다. 사용자에 의한 변경은 데이터 수정, 실행코드 수정

또는 양자 모두를 포함할 수 있다(RTCA DO-178B 2.4항 참조). 23. “레거시 시스템”이라 함은 RTCA DO-178 또는 RTCA DO-178A를 사용하여

승인된 시스템을 말한다.

제2장 소프트웨어 검토 절차

제4조(소프트웨어 검토 협의) 인증당국은 개발자와 소프트웨어 검토를 위한 협의 시

다음 절차를 진행하여야 한다. 1. 수행되는 검토의 유형에 대한 협의(계획 검토, 개발 검토, 검증 검토, 최종 검토)2. 검토 일시 및 장소에 대한 협의

3. 관련 인증 당국 담당자 확인

4. 관련된 신청자 인원 확인

5. 의제와 예상 산출물의 개발

6. 가용한 소프트웨어 데이터의 목록(검토 이전 시점 및 검토 시점)7. 사용될 절차의 명시

8. 필요한 자원의 확인

9. 검토 의견을 전달하는 수단과 날짜(시정조치 및 사후-검토 활동 포함할 수 있음)

제5조(소프트웨어 검토 절차) ①인증당국은 인증 신청의 일부로 제출한 소프트웨어 제품

이 인증 기준과 RTCA DO-178B에 적합함을 확인하기 위해 소프트웨어 라이프사이클

프로세스와 관련 데이터를 검토할 수 있다. 인증당국의 소프트웨어 검토 절차는 인증

기준과 RTCA DO- 178B의 목표를 만족하는지 결정하기 위해 다음 사항을 제공한다. 1. 인증기준, RTCA DO-178B의 목표, 인증당국의 정책, 주요사안 검토서(issue

paper), 기타 해당 인증 요구조건 등에 대한 시의적절한 기술적 해석

2. 적합성 및 해당 데이터의 이행에 대한 견해

3. 소프트웨어 프로젝트가 그 승인된 소프트웨어 계획 및 절차를 준수한다는 객관적

증거


제정: 2009.07.27 개정: 2011.1.3 - 4 -

②소프트웨어 프로젝트에 대한 인증당국의 참여도는 프로젝트 라이프사이클에서

가능한 빨리 결정되어 문서화 되어야 한다. 소프트웨어 검토 유형과 횟수는 프로젝트

의 소프트웨어 레벨, 신청자 및/또는 소프트웨어 개발자의 경험과 이력, 정비 애로사

항 이력, 기타 다른 요소 등에 따라 달라진다. ③인증당국의 검토 절차는 소프트웨어 라이프사이클 초기에 시작하여야 한다. 여기

에 소프트웨어 제품 및 절차에 영향을 줄 수 있는 계획 결정에서 신청자와 인증당국

사이의 시의 적절한 의사소통이 필요하다. 이를 위해 신청자와 인증당국 간에 정기적

인 연락이 수립되어야 한다. 검토의 4가지 유형은 다음과 같다. 이 장에서 4개의

소프트웨어 검토 단계가 정의되어 있지만, 일부 프로젝트에서는 검토단계가 통합되

거나 더 세분화 될 수 있다.1. 소프트웨어 계획 검토는 초기 소프트웨어 계획 절차가 완료될 때(즉, 대부분의

계획서와 표준이 완료되어 검토되었을 때) 수행되어야 한다. 이러한 검토는 일반

적으로 개입단계(Stage Of Involvement, SOI) #1로 명칭한다.2. 소프트웨어 개발 검토는 소프트웨어 개발 데이터(즉, 요구조건, 설계, 코드 등)의

상당 부분(일반적으로 약 50%)이 완료되었을 때 수행되어야 한다. 이러한 검토는

일반적으로 SOI #2로 명칭한다.3. 소프트웨어 검증 검토는 소프트웨어 검증 및 시험 데이터의 상당 부분(일반적으로

약 50%)이 완료되어 검토되었을 때 수행되어야 한다. 이러한 검토는 일반적으로

SOI #3으로 명칭한다.4. 최종 인증 소프트웨어 검토는 최종 소프트웨어 빌드가 완료되고, 소프트웨어 검증

이 완료되며, 소프트웨어 합치성 검토가 수행되어 소프트웨어 어플리케이션이 정

식으로 시스템 인증 승인을 위한 준비가 된 이후에 수행한다. 이러한 검토는 일반적

으로 SOI #4로 명칭한다.④소프트웨어 라이프사이클 데이터의 가용성은 그러한 데이터들이 항상 완료되었음

을 의미하지는 않고, 데이터들은 타당한 검토가 수행될 수 있을 정도는 되어야 한다. 유사하게, 모든 전환 기준은 프로젝트의 검토 시점에서 완료될 필요는 없지만, 프로젝

트에 적용되었음을 보증하도록 충분한 전환기준 증거가 존재하여야 한다.⑤신청자와 인증당국 간의 논의는 프로젝트 라이프사이클 초기에 있어야 하며, 소프

트웨어 검토의 유형, 필요, 횟수, 깊이, 형식 등이 결정되어야 한다. 인증당국의 관여

는 프로젝트 환경에 기반하여 변동된다.

제6조(소프트웨어 계획 검토: SOI #1) ①소프트웨어 계획수립 프로세스는 소프트웨어

프로젝트의 라이프사이클에서 초기 절차로, 소프트웨어 라이프사이클 데이터를

개발, 검증, 관리, 보증, 생성하기 위해 필요한 다양한 소프트웨어 계획, 표준, 절차, 활동, 방법, 툴 등을 수립하는 단계이다. 소프트웨어 계획 검토는 소프트웨어

계획수립 프로세스의 초기 완료 이후에 수행되어야 한다. 소프트웨어 계획 절차가

소프트웨어 라이프사이클에서 지속될 지라도 그리고 계획과 표준이 프로젝트

진행상황에 따라 변경될 수 있어도 일반적으로 관련된 초기 전환기준이 만족되었을


제정: 2009.07.27 개정: 2011.1.3 - 5 -

때에는 완료되었다고 간주한다. 다음 전환기준은 일반적인 소프트웨어 계획수립

프로세스 완료에 대한 기준이 될 수 있다.1. 소프트웨어 계획 및 표준이 회사의 규정된 기준에 따라 내부적으로 검토되고, 결함이 해결됨

2. 소프트웨어 계획 및 표준이 소프트웨어 품질보증(Software Quality Assurance, SQA)가 평가하고, 결함이 해결됨

3. 소프트웨어 계획 및 표준이 승인되고, 형상관리 됨

4. RTCA DO-178B 부록 A 표 A-1의 목표가 만족됨

②인증당국은 신청자로 하여금 아래 표 "소프트웨어 계획 검토 활용 데이터"의 소프

트웨어 계획 및 표준을 작성하여, 인증 당국이 이용할 수 있도록 하여야 한다. 보조

소프트웨어 데이터는 소프트웨어 레벨에 맞게 형상관리 되어야 한다.

소프트웨어 데이터 RTCA DO-178B 조항

소프트웨어 인증 계획서(Plan for Software Aspects of Certification, PSAC) 11.1

소프트웨어 개발 계획서(Software Development Plan, SDP) 11.2

소프트웨어 검증 계획서(Software Verification Plan, SVP) 11.3

소프트웨어 검증 결과(DO-178B 부록A 표 A-1이 적용된 것) 4.6, 11.14

소프트웨어 형상관리 계획서(Software Configuration Management Plan, SCMP) 11.4

소프트웨어 품질보증 계획서(Software Quality Assurance Plan, SQAP) 11.5

소프트웨어 요구조건, 설계, 코드 표준* 11.6, 11.7, 11.8

도구 검증 계획서 12.2, 12.2.3.1

소프트웨어 품질 보증 기록*(계획 활동이 적용된 것) 4.6, 11.19

소프트웨어 계획 검토 활용 데이터

* RTCA DO-178B 부록 A 표 A-1에 따라, 레벨 D에는 요구되지 않음.

③인증 담당자는 RTCA DO-178B 부록 A에서 계획에 적용되는 목표를 소프트웨어

계획 검토에 대한 평가 기준으로 사용하여야 한다. 평가하는 RTCA DO-178B 부록

A의 목표는 표 A-1(목표 전체), 표 A-8(목표 1-4), 표 A-9(목표 1), 표 A-10(목표 1-2)이다. 계획은 또한 계획을 따라 수행하였을 때 모든 해당 RTCA DO-178B의 목표가

만족된다는 것을 보증하도록 평가되어야 한다. 추가하여, 신청자의 안정성 평가, 고장

조건, 소프트웨어의 레벨도 평가한다. 또한, 소프트웨어 계획 및 표준과 소프트웨어

레벨의 연관성도 평가되어야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 6 -

제7조(소프트웨어 개발 검토: SOI #2) ①소프트웨어 개발 절차는 소프트웨어

요구조건, 설계, 코드, 통합 절차로, 소프트웨어 검증, 형상관리, 품질보증 등의 통합

절차와 인증지원 절차에 의해 지원받는다. 따라서 인증당국의 소프트웨어 개발

검토에서는 소프트웨어 라이프사이클 데이터 특히, 소프트웨어 개발 데이터 및 이와

관련된 통합 절차 데이터의 조사를 통해 신청자의 계획 및 표준의 실제적 이행을

평가하여야 한다. 이 검토 동안, 신청자와 인증당국은 발견된 계획 및 표준의 변경

또는 성능표준불일치(deviation)에 대해 합의하고 문서화 할 수 있다. 소프트웨어

개발 검토 수행 전에, 소프트웨어 개발 데이터는 충분하게 갖추어지고 완성되어야

한다. 다음 전환기준은 소프트웨어 개발 절차의 성숙도에 대한 일반적인 기준이 될

수 있다.1. 고수준 요구조건이 문서화되고, 검토되었으며, 시스템 요구조건에 대해 추적

가능함

2. 소프트웨어 아키텍처가 정의되고, 검토와 분석이 완료됨

3. 저수준 요구조건이 문서화되고, 검토되었으며, 고수준 요구조건에 대해 추적

가능함

4. 소스 코드가 저수준 요구조건을 구현하고, 소스 코드가 저수준 요구 조건에

대해 추적 가능하며, 소스 코드가 검토됨

②소프트웨어 개발 검토를 위해, 아래 표 "소프트웨어 개발 검토 활용 데이터"의

소프트웨어 데이터를 인증 당국이 이용할 수 있어야 한다. 보조 소프트웨어 데이터는

소프트웨어 레벨에 맞게 형상관리 되어야 한다. 또한, SOI #1에 있는 계획도 검토

전에 인증팀에게 제공되어야 한다.

소프트웨어 데이터 RTCA　DO-178B 조항

소프트웨어 요구조건, 설계 및 코드 표준* 11.6, 11.7, 11.8

소프트웨어 요구조건 데이터 11.9

설계 명세 11.10

소스 코드 11.11소프트웨어 검증 절차(DO-178B 부록A 표 A-2 ~ A-5가

적용된 것)6.3.1, 6.3.2, 6.3.3, 6.3.4, 11.13

소프트웨어 검증 결과(DO-178B 부록A 표 A-2 ~ A-5가

적용된 것)6.3.1, 6.3.2, 6.3.3, 6.3.4, 11.14

소프트웨어 라이프사이클 환경 형상 색인 11.15

문제점 보고서 11.17

소프트웨어 형상관리 기록 11.18소프트웨어 품질 보증 기록(DO-178B 부록A 표 A-2 ~ A-5가 적용된 것) 11.19

소프트웨어 개발 검토 활용 데이터

* RTCA DO-178B 부록 A 표 A-1에 따라, 레벨 D에는 요구되지 않음.


제정: 2009.07.27 개정: 2011.1.3 - 7 -


소프트웨어 요구조건 데이터 11.9

설계 명세 11.10

소스 코드 11.11

오브젝트 코드 11.12

소프트웨어 검증 검토 활용 데이터

③인증 담당자는 RTCA DO-178B 부록 A에서 개발에 적용되는 목표를 소프트웨어

개발 검토에 대한 평가 기준으로 사용하여야 한다. 평가하는 RTCA DO-178B 부록

A의 목표는 표 A-2(목표 1-6), 표 A-3(목표 전체), 표 A-4(목표 전체), 표 A-5(목표

1-6), 표 A-8(목표 1-4, 6), 표 A-9(목표 1-2), 표 A-10(목표 1-2)이다. 추가하여, 개발

절차에서 계획 및 표주에 대한 신청자의 이행 효력을 판정하기 위해 소프트웨어 라이

프사이클 데이터를 평가하여야 한다.

제8조(소프트웨어 검증 검토: SOI #3) ①소프트웨어 검증 절차는 일반적으로 검사, 실증, 검토, 분석, 시험, 커버리지 분석 등의 조합으로 이루어진다. 다른 검토와

마찬가지로, 소프트웨어 형상관리와 품질보증 절차가 이러한 검증 활동 동안에

이루어진다. 검증 활동은 규정된 소프트웨어 제품이 빌드된 소프트웨어 제품이라고

확인한다. 따라서 소프트웨어 검증 절차는 이러한 확인을 제공하고, 제품이 충분하게

시험되었고 의도된 제품이라는 객관적 증거를 제시한다는 것을 보증하여야 한다. 소프트웨어 검증 절차의 목적은 신청자의 검증 계획과 절차의 효과와 이행 평가, 관련 소프트웨어 형상관리 및 품질보증 업무의 완성 보증, 소프트웨어 요구조건, 설계, 코드, 통합 등이 검증 보증, 소프트웨어 검증 절차가 RTCA DO-178B 부록

A 표 A-7의 요구조건-기반 시험 커버리지와 구조적 커버리지 기준 달성 등을

보증하는 것이다. 소프트웨어 검증 검토를 수행하기 전에, 소프트웨어 검증 절차는

충분하게 갖추어지고 완성되어야 한다. 다음 전환기준은 검증 절차의 성숙도에 대한

일반적인 기준이 될 수 있다.1. 개발 데이터(예를 들어, 요구조건, 설계, 소스 코드, 목적 코드, 링크 및 로딩

데이터, 실행가능 파일)가 완성되었고, 검토되었으며, 형상관리 됨

2. 시험 케이스 및 절차가 문서화되고, 검토되었으며, 형상관리 됨

3. 시험 케이스 및 절차가 이행됨(공식/비공식)4. 완료된 시험 결과가 계획 문서에서 협의된 대로 문서화됨

5. 소프트웨어 시험 환경이 문서화 되고, 관리 됨

②인증 담당자는 소프트웨어 검증 검토에서 적합성 판정을 위해, 해당 소프트웨어

레벨에 맞게 아래 표 "소프트웨어 검증 검토 활용 데이터"에서 제시하는 소프트웨어

데이터를 이용할 수 있어야 한다. 보조 소프트웨어 데이터는 소프트웨어 레벨에 맞게

형상관리 되어야 한다. 또한, SOI #1 및 SOI #2에 있는 데이터도 검증 검토 동안

이용할 수 있어야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 8 -

소프트웨어 검증 사례와 절차 6.3.1~6.3.6, 11.13

소프트웨어 검증 결과 11.14

소프트웨어 라이프사이클 환경 형상색인(시험 환경 포함) 11.15

소프트웨어 형상 색인(시험 기준선) 11.16


소프트웨어 형상관리 기록 11.18

소프트웨어 품질보증 기록 11.19

소프트웨어 도구 검증 데이터(해당하는 경우) 12.2.3

③인증 담당자는 RTCA DO-178B 부록 A에서 검증에 적용되는 목표를 소프트웨어

검증 검토에 대한 평가 기준으로 사용하여야 한다. 평가하는 RTCA DO-178B 부록

A의 목표는 표 A-5(목표 7), 표 A-6(목표 전체), 표 A-7(목표 전체), 표 A-8(목표 전체), 표 A-9(목표 1-2), 표 A-10(목표 전체)이다.

제9조(최종 소프트웨어 검토: SOI #4) ①빌드된 최종 소프트웨어는 RTCA DO-178B의

모든 목표에 적합하도록 신청자가 고려하는 소프트웨어 제품의 형상을 수립하는데, 이

형상이 인증된 시스템 또는 장비에서 사용하도록 의도된 소프트웨어의 버전이다. 이

검토의 목적은 해당 RTCA DO-178B의 목적에 대한 최종 소프트웨어 제품의 적합성

판정, 소프트웨어의 모든 개발, 검증, 품질보증, 형상관리, 인증지원 활동 등이 완료되

었음을 보증하고, 소프트웨어 합치성 검토가 완료되었음을 보증하며, 최종 소프트웨어 형상 색인(Software Configuration Index, SCI)와 소프트웨어 구현 요약서(Software Accomplishment Summary, SAS)를 검토하는 것이다. 최종 소프트웨어 검토는 소프

트웨어 프로젝트가 완료되고, 다음 기준을 만족하였을 때 수행되어야 한다. 1. 소프트웨어 합치성 검토가 수행되고, 결함이 해결됨

2. SAS와 SCI가 완결되고 검토됨

3. 모든 소프트웨어 라이프사이클 데이터가 완성되고, 승인되며, 형상관리 됨

②이 검토를 위해, RTCA DO-178B의 모든 소프트웨어 라이프사이클 데이터는 인증

당국이 이용할 수 있어야 한다. 아래 표에서 제시하는 데이터는 이 검토에서 특별히

관심을 두는 데이터이다. 보조 소프트웨어 데이터는 소프트웨어 레벨에 맞게

형상관리 되어야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 9 -


소프트웨어 검증 결과 11.14

소프트웨어 라이프사이클 환경 형상 색인 11.15

소프트웨어 형상 색인 11.16


소프트웨어 형상 관리 기록 11.18

소프트웨어 품질보증 기록(소프트웨어 합치성 검토

보고서 포함) 11.19

소프트웨어 구현 요약서 11.20

최종 소프트웨어 검토의 활용 데이터

③인증 담당자는 이 검토에 대한 평가 기준으로 RTCA DO-178B 부록 A의 모든

목표를 사용하여야 한다. 추가하여, 사용자는 소프트웨어와 관련된 문제점 보고서

(problem report), 실행 항목(action item), 인증 문제, 기타 등 모두를 인증, 허용, 승인 전에 언급하여야 한다.

제10조(소프트웨어 검토 절차에 대한 추가 고려사항) ①이 조에서는 인증당국의 현장

검토에 대한 4가지 유형의 검토를 제시한다. 다만, 검토의 유형, 횟수, 정도는 모든

인증 프로젝트와 신청자에게 적절하지는 않다. 추가적인 고려나 대체 방안이 더

적절할 수 있다. 인증 담당자는 다음 사항을 고려하여 전자 하드웨어 검토 절차의

인증당국 참여도를 결정한다.1. 시스템 안전성 평가에 따라 결정된 소프트웨어 레벨

2. 제품 특성(크기, 복잡성, 시스템의 기능 또는 새로운 고안, 소프트웨어 설계 등)3. 새로운 기술 또는 일반적이지 않은 설계 특성의 사용

4. 새로운 소프트웨어 방법이나 라이프사이클 모델의 제안

5. 소프트웨어 개발에서 RTCA DO-178B 목표의 적합성에 대한 신청자의 지식과

이전 성공사례

6. 프로젝트에서 RTCA DO-178B의 12장에 관련된 문제의 존재여부

7. 인증 프로젝트에서 소프트웨어 관련된 주요사안검토서의 발생

제11조(소프트웨어 검토 준비) 소프트웨어 승인을 담당하는 인증 담당자는 인증팀을

구성하여야 한다. 팀에는 소프트웨어 엔지니어링, 형상관리, SQA 등에 능통한 인원

1명 이상과 시스템 안전성 평가와 시스템 요구 조건을 잘 알고 있는 인원 1명이

포함되어야 한다. 인증팀의 팀장은 소프트웨어 검토 전 적어도 6주 전에 신청자와

조율을 하여야 하고, 의제를 제안한다.

제12조(소프트웨어 검토 신청자 통지) 인증팀장은 소프트웨어 검토에서 인증당국이


제정: 2009.07.27 개정: 2011.1.3 - 10 -

바라는 목표에 대해 적어도 검토 4주 전에 서면으로 신청자에게 통지하여야 한다. 다음 정보가 서면 통지에 포함되어야 한다. 1. 검토의 목적과 검토 종류(계획, 개발, 검증, 최종)2. 검토 날짜와 기간

3. 검토 참여자 목록 및 연락처

4. 개별 검토 참여자에게 송부되어야 하는 RTCA DO-178B의 4.3항에서 제시하는

소프트웨어 계획에 대한 요청

5. 해당 라이프사이클 데이터가 검토시점에 이용 가능하도록 하는 요청

6. 평가될 RTCA DO-178B 목표

7. 검토 전에 신청자가 자체 평가를 수행하도록 하는 제안

8. 담당 관리자, 개발자, 검증 형상관리 품질보증 요원이 질의사항에 답변할 수 있도

록 하는 요청

제13조(소프트웨어 검토 수행) 일반적으로 검토에는 다음 요소가 포함된다. 1. 인증당국의 시작시 소개에는 인증팀원의 소개, 검토의 목적에 대한 재언급, 검토

의제에 대한 개요 등이 포함된다.2. 소프트웨어 개발자의 설명에는 시설의 가용성, 라이프사이클 데이터의 가용성,

인원 일정의 제약사항, 시스템 개요, 시스템과 다른 시스템간의 상호작용, 시스템

아키텍처, 소프트웨어 아키텍처, 소프트웨어 라이프사이클 모델(툴과 방법 포함), 이전 실행항목 또는 주요사안검토서 (해당하는 경우)에 대한 진행사항, 현 개발

상황(진행상태 결산 보고서 또는 유사 자료 포함), 자체 평가 결과의 요약(수행한

경우), 기타 추가 고려사항(RTCA DO-178B의 12장에 따른) 등이 포함된다.3. 신청자의 절차와 제품에 대한 검토(제5조 참조).

제14조(소프트웨어 검토 결과의 기록) 인증 담당자의 검토 결과 기록에는 최소한 다음

사항이 포함되어야 한다.1. 검토될 각각의 라이프사이클 데이터 아이템 목록. 여기에는 문서 제목, 관리번호,

버전과 날짜, 요구조건 식별번호(해당하는 경우), 소스코드 모듈(해당하는 경우), 항목 번호(해당하는 경우), 검토 결과 등을 포함한다.

2. 지적사항 또는 관찰사항을 설정하는데 사용된 접근방법

3. RTCA DO-178B 목표와 관련된 지적사항 또는 관찰사항에 대한 설명(상세한 설명

과 함께 문서화). 4. 신청자 또는 인증당국에게 필요한 조치

5. 현재 또는 잠재적 주요사안검토서의 전체 목록

제15조(소프트웨어 검토 종결 회의) 인증 담당자는 신청자 및/또는 개발자에 대한 종결

회의에서는 검토 지적사항과 관찰사항을 간결하고 정확하게 요약하여야 한다. 지적

사항과 관찰사항은 RTCA DO-178B의 목표, 인증기준, 정책, 지침, 기타 인증 문서를


제정: 2009.07.27 개정: 2011.1.3 - 11 -

참조하여 제시하여야 한다. 신청자 및/또는 개발자에게 지적사항 및 관찰사항에 답할

수 있는 기회를 제공하여야 한다.

제16조(소프트웨어 검토 보고서) 인증팀장은 검토 후 보고서에 모든 검토 지적사항, 관찰사항, 조치사항 등을 요약하여야 한다. 보고서는 검토 후 6주 이내에 신청자와

조율하여 송부하여야 한다.

제17조(주요사안검토서 식별 및 준비) 주요사안검토서는 인증 전에 해결하여야 하는

기술 및 인증 문제를 문서화하는 수단으로, 인증 담당자는 문제가 발견되면 가능한

빨리 식별하여 주요사안검토서를 준비하고 해결하여야 한다. 소프트웨어-관련

문제에 대한 주요사안검토서는 인증당국, 해당분야 전문가 등과 조율하여야 한다.

제3장 소프트웨어 프로젝트에 대한 인증당국의 참여도

제18조(참여도의 결정) ①인증 담당자는 신청자와 함께 가능한 초기에 프로젝트

상세사항을 계획하고 기술할 수 있도록 각각의 소프트웨어 개발 프로젝트 초기에

평가를 수행하여 문서화한다. 평가 결과는 인증당국의 참여도를 상(HIGH), 중(MEDIUM), 하(LOW)로 구분한다. 인증당국의 참여도(LOI, Level Of Involvement) 평가 결과는 소프트웨어 검토에서 인증당국의 참여도 및 시점, 기타사항 등을

결정한다. 참여도 결정기준에는 다음 2가지의 중요 영역이 있다. 1. 소프트웨어 레벨 기준. 프로젝트에서 소프트웨어의 LOI 결정에 대한 첫째 기준은

개발되거나 수정되는 시스템의 소프트웨어 레벨이다. 출발 시점에서, 소프트웨

어 레벨 기준은 아래 표 "소프트웨어 레벨 기준"에서와 같이 적용될 수 있다.

RTCA DO-178B 소프트웨어 레벨 인증당국 참여도

D 하

C 하 또는 중

B 중 또는 상

A 중 또는 상

소프트웨어 레벨 기준

2. 기타 관련 기준. "소프트웨어 레벨 기준"은 소프트웨어 A, B, C에서 불분명하다. 이러한 경우, 별지 1을 참조하여 인증당국의 참여도를 결정한다.

③소프트웨어 프로젝트에 인증당국의 새로운 정책이 필요할 수 있는 문제가 있다면

(예를 들어, 신기술, 새로운 설계방법, 일반적이지 않은 툴 등), LOI는 더 높아질 수

있다. ④소프트웨어와 관련된 TC, ATC, STC, ASTC 프로젝트의 초기에, 인증 당국, 신청자


제정: 2009.07.27 개정: 2011.1.3 - 12 -

는 프로젝트의 필요와 LOI를 평가하기 위해 함께 작업하여야 한다. 소프트웨어 레벨

은 일반적으로 프로그램 초기에 결정되고, 프로젝트의 안전성 필요에 대한 의견을

제시한다. ⑤상기 표 “소프트웨어 레벨 기준”의 평가에서 LOI가 불확실하다면(즉, 레벨 A, B, C 시스템의 경우), LOI의 상세 평가를 위해 별지 1을 사용한다. 별지 1에서 각 기준의

점수에 대한 척도는 최소, 최대 값에 가중치가 부가되어 있다. 기준에 대한 신청자

또는 개발자의 점수를 채점하는데 척도 범위 이내의 어떠한 값이라도 선택할 수

있다.⑥소프트웨어 레벨이 A, B, C인 프로젝트의 경우, 별지 1의 기준이 프로젝트의 총점

(Total Score Result, TSR)을 계산하는데 사용된다. 별지 1을 사용하여 프로젝트를

평가하기 위해, 다수의 방법이 단독 또는 조합으로 사용될 수 있다.1. 신청자 또는 개발자의 프로젝트를 가장 잘 이해하고 있는 인증 담당자가 평가를

수행한다.2. 인증 담당자는 이전 프로젝트의 성공여부 및 문제, 과거 검토 및 감사, 운용중

문제, 다른 인증 당국의 경험 등을 바탕으로 신청자 및/또는 개발자의 과거

수행이력을 조사할 수 있다.⑦신청자와 개발자 프로젝트의 결합 평가는 대부분의 프로젝트에 적용될 수 있다. 그러나 신청자와 소프트웨어 개발자에 대해 분리하여 평가가 수행될 필요가 있다. 신청자와 개발자에 대한 LOI의 결정이 다른 경우, 더 높은 결정(즉, 더 많은 참여도)을

사용한다.⑧특정 소프트웨어 프로젝트에 대한 LOI를 결정하기 위해, 제공되는 척도에 따라

각각의 기준에 대해 신청자 및/또는 개발자를 채점하여, 별지 1의 점수 란에 점수를

기록한다. 이러한 점수를 기록한 후에, 총점(TSR)을 결정하기 위해 점수 란의 점수를

합산한다. 이러한 TSR은 “참여도 결정”에 적용하여 LOI(즉, 상, 중, 하)를 결정하는데

사용한다.

총점(별지 1) S/W 레벨 A S/W 레벨 B S/W 레벨 C S/W 레벨 D

TSR≤80 상 상 중 하

80<TSR≤130 상 중 중 하

130<TSR 중 중 하 하

참여도 결정

1. TSR이 TSR경계치(즉, 80 또는 130)에 근접하면, 가장 적절한 LOI를 결정하기

위해 소프트웨어 레벨과 공학적 판단을 사용한다.2. 별지 1의 기준이 적용되지 않으면, 평가자는 평균값을 적용하거나 “참여도

결정”의 경계치를 조정할 수 있다.⑨정책적 문제가 필요한 프로젝트는 특별한 고려사항이 요구된다. 일반적으로, 정책


제정: 2009.07.27 개정: 2011.1.3 - 13 -

적 문제가 있는 레벨 A 또는 B 프로젝트는 “참여도 결정”의 결과에 상관없이 LOI 상(High)이 요구된다. 또한 정책적 문제가 있는 C 또는 D 프로젝트도 일반적으로

LOI 중(Medium) 이상이 요구된다.⑩일단 LOI 평가가 수행되면, 인증당국의 참여도가 별지 2에 따라 문서화 되어야

한다. 인증프로젝트 계획(CPP, Certification Project Plan) 또는 이와 동등한 문서에

포함시키기 위해, 인증당국 관여사항은 별지 2의 양식을 이용하여 문서화 되어

인증당국의 프로젝트 관리자에게 제출되어야 한다.

인증당국

참여도일반적인 프로그램 결정사항

상

� 인증당국, 해당분야 전문가의 관여 가능성 높음

� 인증당국은 모니터링, 현장 검토, 사무실 검토 등을 포함한 S/W 라이

프사이클 동안 관여(2번 이상의 현장 검토 권고). � 모든 소프트웨어 계획서 제출

� S/W구현요약서(SAS), S/W형상색인(SCI), 검증 결과 제출

� RTCA DO-178B 목표 적합성 매트릭스 제출 권고(이것은 RTCA DO- 178B 목표와 데이터 및 절차간의 관계 도표로, SAS에 포함될 수

있음)

중

� 인증당국은 초기(계획, 규정과 정책 해석, 일부 모니터링) 및 최종(최종 적합성) 단계에서 적당한 관여

� 인증당국, 해당분야 전문가의 관여가 필요할 수 있음

� 현장 검토 1번 이상 수행, 대부분 사무실 검토

� PSAC, SCI, SAS 제출

� SVP, SQAP, SCMP, SDP 제출 권고

하

� 인증당국은 최소 관여(예, 현장 검토 없고 사무실 검토도 소수 또는

없음)� 인증당국, 해당분야 전문가의 관여 거의 필요 없음

� PSAC, SCI, SAS 제출

LOI 결과에 따른 프로그램 결정사항 예시

⑪특수 고려사항

1. 중간 프로젝트 조정. LOI 기준은 주로 인증 프로그램 초기에 이뤄지는 평가와

결정에 기초한다. 인증 프로그램과 소프트웨어 개발 동안, 신청자와 개발자

모두는 모니터링 되어야 한다. 예측하지 못한 문제가 발생하면, 인증 담당자는

LOI 결정을 재평가하고 참여도를 조정할 필요가 있다. 일부 신청자는 프로그램

진행 동안 LOI를 낮출 수 있다(예를 들어, 입증된 기술의 변경, 기타). 별지

2의 양식은 중간 프로젝트 조정의 기록서식을 제공한다.2. 프로젝트 위험. 프로젝트 진행 동안 일정 지연, 기능 축소 또는 변경 같은


제정: 2009.07.27 개정: 2011.1.3 - 14 -

프로젝트 위험이 발생하는 경우, 인증 담당자는 신청자 및/또는 개발자의

위험관리 전략을 평가하여 LOI를 조정할 필요가 있다.3. 인증당국 업무부하. 다중 프로젝트에 관여된 인증당국 요원은 다른 프로젝트의

참여도를 고려하여야 한다. 다수의 참여도 상(High)의 프로젝트를 담당하는 것

특히, 원격지를 방문하는 여러 프로젝트에 관여하는 것은 실용적이지 못하다. 일반적으로, 소프트웨어 레벨과 시스템 신규성은 프로젝트에 더 많이 참여할지

덜 참여할지를 결정하는 중요한 요소이다(예, 레벨 A 시스템에는 현장 검토, 레벨 D 시스템에는 사무실 검토 또는 검토 없음). 최적 활동 결정 및 추가 인원

소요에 대한 식별 등을 결정하기 위해 과도한 업무부하는 관리자에게

보고되어야 한다. 일부의 경우 다른 사무소의 인원을 활용할 필요도 있을 수

있다.4. 인증당국 자원. 업무부하에 추가하여, 인증당국의 LOI 결정에는 현장 검토에

대한 출장비 등과 같은 가용 자원을 고려하여야 한다.

제4장 소프트웨어 합치성 검사

제19조(소프트웨어 합치성 검사) 합치성 검사의 목적은 제작한 제품(하드웨어 및 소프

트웨어)이 형식설계에 합치한다는 것을 보증하는 것이다. 소프트웨어 합치성 검사는

“소프트웨어 부품 합치성 검사”와 “소프트웨어 설치 합치성 검사”가 있다. 신청자가

인증 신인도를 위한 실험실 시스템 하드웨어 시험을 수행하고자 할 때 그리고 항공기

수준의 지상 및/또는 비행 시험을 수행하기 위한 목적으로 탑재 소프트웨어를 시스템

에 설치할 때 소프트웨어 부품 합치성 검사와 소프트웨어 설치 합치성 검사가 요구된

다. 소프트웨어 합치성 검사는 다음을 보증하기 위함이다.1. 시험 대상 유닛의 형상이 인증당국의 인증 신인도를 위해 수행되는 시험에 승인된

올바른 하드웨어 및 소프트웨어의 형상을 반영함. 2. 이미 수행된 시험 이후에 하드웨어 및/또는 소프트웨어에 변경이 있는 경우 시험

대상 유닛의 형상이 잘 기록됨. 3. 인증당국이 승인한 형식설계 데이터에 합치하는 항공기 수준의 시험을 수행하기

위해 시스템이 항공기에 설치되고 소프트웨어가 시스템에 로딩되었음.4. 인증을 위해 제시된 최종 소프트웨어 및 하드웨어 형상 제품 기준선이 형식설계에

합치함.

제20조(소프트웨어 부품 합치성 검사) ①시험 대상, 시험 설비, 사용된 시험 절차, 시험

결과의 유효성 등에 대한 합치성은 인증 신인도를 위해 수행된 개별 시험에서 수립되

어야 한다. 인증당국의 인증 신인도를 만족하기 위해 수행되는 시험의 예는 RTCA DO-160E 환경검증시험, 시스템 기능 시험, 시스템 통합 시험, 항공기 지상 기능 시험, 항공기 형식검사승인 (TIA) 시험 비행 시험 등이 있다.


제정: 2009.07.27 개정: 2011.1.3 - 15 -

② 감항엔지니어는 다음 업무를 수행한다. 1. 소프트웨어 기준선이 인증당국의 사무실 검토 및/또는 현장 검토를 수행하여

형식 설계 및 관련 소프트웨어 계획에 적합하다는 것을 확인한다. 일부에서, 환경검증 시험을 위해 특별한 목적의 소프트웨어가 사용된다. 이러한 경우, 제작

자는 특별한 목적의 시험 소프트웨어의 형상을 검증, 확인, 관리하여야 한다. 시험 소프트웨어는 검증 시험 전에 수행되는 시험 설비 합치성의 일부로 포함되

어야 한다.2. 소프트웨어 시험 기준선에 적합하여 LRU에 설치되는 소프트웨어의 시험 형상을

확인한다.3. 시험 기준선과 관련된 모든 소프트웨어 가공품은 형상관리하에서 적절히 식별되

고, 시험 중인 소프트웨어의 현재 상태가 반영되는지 확인한다.4. 검증이 필요한 모든 소프트웨어 개발 툴 또는 소프트웨어 검증 툴이 검증되었음을

확인한다. 그러나 합치성 검토 시점에서 툴 검정 활동이 완료되지 않은 경우, 툴과 보조 데이터는 그 형상이 문서화 되어야 한다.

5. “항공기등 형식증명 지침” 별지 제15호 서식 “합치성검사요청서”를 작성․제출

하여 인증당국의 검사관이 다음 사항을 수행하는 지침을 마련하도록 한다.가. 적절하게 빌드되어 로딩한 파일이 소프트웨어 형상관리 라이브러리에서 제

거되었음을 확인한다.나. 소프트웨어 빌드 및 로딩 절차 동안 승인된 빌드 및 로딩 지침이 준수되었는지

확인한다. 다. 모든 데이터의 무결성이 점검되고, 소프트웨어 부품번호(버전번호 포함)가

LRU에서 검증되었는지 확인한다.라. 시험 시설이 승인된 엔지니어링 시험 계획에 식별된 시험 시설 형상에 합치

하는지 확인한다.6. 소프트웨어 라이프사이클 데이터의 보유, 보관, 호출에 사용되는 절차가 승인된

소프트웨어형상관리계획(SCMP)에 적합한지 확인한다.③인증당국의 검사관은 상기 제20조②5항에서 언급되고 “항공기등 형식증명 지침” 별지 제15호 서식 “합치성검사요청서”에 식별된 업무를 수행하여야 한다.④소프트웨어 부품 합치성 검사는 소프트웨어 설치 합치성 검사 요청 전에 성공적으

로 수행되어야 한다.

제21조(소프트웨어 설치 합치성 검사) ①소프트웨어 설치 합치성 검사는 형식검사승인

(TIA)에 따라 수행되는 시험처럼 인증당국의 항공기 수준 지상 또는 인증 비행 시험

중에 언제든 요구된다. 주요 목적은 다음과 같은 것을 입증하기 위함이다.1. 승인된 시스템 장착 설치 및/또는 소프트웨어 로딩 절차에 적합하게 승인되고

관리되는 소프트웨어 버전이 타깃 시스템에 성공적으로 로딩됨. 2. 시스템에 올바른 버전이 로딩되어 성공적으로 초기화됨

②감항엔지니어는 다음 사항을 보증하여야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 16 -

1. 이전 소프트웨어 부품 합치성 검사가 성공적으로 수행되었음.2. 로딩 절차가 승인되었음.3. “항공기등 형식증명 지침” 별지 제15호 서식 “합치성검사요청서” 또는 별지 제19호

서식 “형식검사승인서”가 작성되어 장착 합치성 검토가 요청된 소프트웨어의

부품번호 및/또는 버전 넘버가 포함되었음. 소프트웨어의 부품번호 및/또는 버전

넘버는 식별 가능하고, 형상관리되며, 재생성 가능하여야 하며 소프트웨어

형상색인(SCI) 또는 이와 유사한 형상문서에 기록되어야 한다. 합치성 검사

요청에는 다음 사항을 포함하여 인증당국의 검사관이 검증하여야 하는 실행

활동이 포함되어야 한다.가. 올바른 소프트웨어 버전이 시스템에 로딩되고, 항공기에 올바른 시스템 하드

웨어(부품번호 및 일련번호)가 장착됨을 확인.나. 로딩 절차가 올바른 소프트웨어 부품번호(및 버전 넘버)가 올바른 시스템

하드웨어 구성품(일련번호 및 부품번호)에 로딩됨을 보증하는지 확인. 소프

트웨어 로딩 절차 또는 지상 보조 장비가 부품 번호 및 버전 번호의 불일치

(mismatch) 또는 성공적이지 못한 로딩을 탐지하면 오류 표식을 언제든 표시하

여야 한다. 설치 합치성 검사에서는 제작자의 로딩 절차가 준수되는지 그리고

소프트웨어 로딩이 올바르게 초기화되는지를 판단하여야 한다. 불일치는 식

별되어 기록되어야 한다.③인증당국의 검사관은 다음 2가지 방법중 하나로 “항공기등 형식증명 지침” 별지

제15호 서식 “합치성검사요청서” 또는 별지 제19호 서식 “형식검사승인서”에 언급된

소프트웨어 설치 합치성 검사를 수행하여야 한다. 1. 항공기가 설치되었거나 설치될 실제 시스템에 올바른 소프트웨어 부품 번호

및 버전(즉, 실제 부품번호 및 일련번호)이 성공적으로 로딩되도록 물리적 입

회. 성공적인 로딩은 무결성 확인에서 소프트웨어 로딩 확인(예, 순환중복검사

(CRC)의 비교)을 입회하거나, 소프트웨어가 초기화 절차가 성공적으로 수행

되었음을 입회하여 결정한다. 소프트웨어 로딩 절차는 감항엔지니어가 검토하

여 승인한 소프트웨어 로딩 절차에 따라 수행되어야 한다.2. 실제 소프트웨어 로딩 결과가 기록된 제조 검사 기록을 획득. 이러한 기록에는

해당하는 항공기 식별 정보, 시스템 하드웨어 부품 번호 및 일련 번호, 소프트

웨어 부품 번호 및 버전 번호 등이 포함되어야 한다. 제공되는 기록은 인증당국

의 검사관이 항공기에 장착된 시스템을 추적할 수 있도록 하드웨어 유닛 부품

번호와 일련번호 정보가 식별되어야 한다. 또한 제공되는 기록에 시스템 하드

웨어로 로딩되는 소프트웨어 부품 번호를 표시하여야 한다. 기록에는 언제

어떻게 소프트웨어가 로딩되었는지 그리고 로딩 및 초기화 절차가 성공적이었

는지를 표시하여야 한다.

제5장 현장로딩가능 소프트웨어(FLS)의 승인


제정: 2009.07.27 개정: 2011.1.3 - 17 -

제22조(FLS의 승인) 다음 절차는 FLS 승인을 위한 TC, ATC, STC, ASTC, TSOA 절차

의 일부로 인증 당국이 수행하여야 한다.1. 신청자와 인증 당국이 합의한 대로, RTCA DO-178B 또는 다른 수락 가능한

적합성 입증방법의 목표 만족을 확인.2. RTCA DO-178B의 2.5항에 설명된 고려사항이 언급되었음을 확인.3. 소프트웨어 및 하드웨어의 형상이 검증 절차 동안 함께 검증되었음을 확인(즉,

소프트웨어는 승인된 타깃 컴퓨터에 장착되어야 한다).4. 장착 형상(즉, 소프트웨어 부품번호, 하드웨어 부품번호, 항공기 또는 엔진 모델,

항공기 또는 엔진의 일련번호 조합 등 해당하는 것)이 TC, ATC, STC, ASTC, TSOA 절차 동안 승인된 것과 동일한 형상임을 보증하는 신청자의 형상관리

절차가 적절함을 확인.5. 항공기 또는 엔진의 예비 부품이 현장로딩가능 한 경우, 신청자가 (1) 예비 부품

에 혼합되는 다른 소프트웨어 로딩에 대한 요구조건, (2) 일부 성공적인 로딩과

일부 성공적이지 않은 로딩에 대한 요구조건, (3) 예비 부품에 대한 성공적인

로딩과 성공적이지 않은 로딩의 항공기 또는 엔진의 처리성(dispatchability) 영향 등을 정의하였음을 확인.

6. 로딩된 소프트웨어가 승인된 소프트웨어이고, 소프트웨어가 손상되지 않았음을

보증하는 절차가 적합함을 확인(예, CRC처럼 해당 데이터의 전송 무결성 검사의

검증). 신청자는 사용된 알고리즘이 로딩되는 데이터의 소프트웨어 수준에 요구

되는 무결성에 충분한지 보증하여야 한다.7. 6항에서 설명한 것을 보증하는 적합한 절차가 없다면, 검증 절차 동안 현장 로딩

되는 항공용 장비가 내장된 로딩 시스템과 호환되는지 실증하여 확인. 추가적으

로, 인증 당국은 내장된 로딩 시스템이 다음 사항을 고려하여 승인되었음을 보증

하여야 한다.가. 신청자로 하여금 내장된 로딩 시스템이 RTCA DO-178B의 2.5항 또는 신청

자와 인증 당국 간에 협의된 대체 적합성 입증방법에 적합하다는 것을 실증

하도록 하여야 한다.나. 신청자로 하여금 내장된 로딩 시스템의 작동을 정의하는 문서와 운영자가 장비

의 형상관리를 유지하기 위한 권고 수단을 제공하도록 하여야 한다. 이러한

문서에는 이 장에서 설명되는 지침을 만족하는 형상관리 절차에 대한 지침을

포함하여야 한다.다. 인증당국은 신청자의 내장된 로딩 시스템과 절차를 승인하여야 한다. 구현에

따라, 이러한 승인에는 데이터 로더와 절차가 포함될 수 있다. 라. 인증당국은 신청자가 로딩 매체를 하나 이상 제안하는 경우(디스켓, 대용량저

장장치, CD 등), 모든 매체로부터의 로딩이 이 장의 지침에 적합하도록 하여

야 한다.8. TC, STC, ATC, ASTC의 프로젝트인 경우, 신청자가 내장 장비, 휴대 장비, 기타


제정: 2009.07.27 개정: 2011.1.3 - 18 -

적절한 방법으로 항공용 장비의 소프트웨어 부품 번호를 검증할 수 있음을 확인. TSO 프로젝트의 경우, KAR §21.607(d)를 따르는 적절한 부품 표식 데이터는

어떤 지형적 위치에서도 지상에서 확인 가능하여야 한다.9. FLS의 변경은 안전성 영향 및 중 또는 경 변경 분류를 결정하기 위해 소프트웨어

변경 영향 분석을 수행함을 확인.(그러지 않으면, FLS은 이 지침서의 7장에서

언급하는 사용자변경가능 소프트웨어이다). 10. 로딩 보호 메커니즘이 비행 중 FLS의 로딩 금지를 위해 실행됨을 확인.

제23조(FLS의 설치에 대한 고려사항) 승인된 FLS는 정비회보, 기술적 변경 요청, 기타

인증당국이 승인한 방법에 따라 항공기에 장착할 수 있다. 승인된 방법은 부여되는

승인 방법에 따라 다양하다. FLS 승인은 TC, ATC, STC, ASTC, TSOA 또는 다른

승인 절차를 통해 이뤄지지만, FLS를 설치하는데 사용하는 문서는 인증 당국이

승인하여야 하고, 다음 요소를 명시하고 있는지 확인하여야 한다. 1. 예비시스템의 소프트웨어 로딩을 위한 항공기 및 하드웨어의 적용성과 상호혼용

성 허용

2. 소프트웨어가 승인되고 호환되는 타깃 컴퓨터 및 메모리 장치에 올바르게 로딩되

었음을 보증하는 검증 절차

3. 이 장에서 명시한 지침에 대한 적합성을 보이는데 필요한 사후-로딩 검증 및/또는

시험 절차

4. 성공적이지 못한 로딩 사건에서 취하는 조치(예들 들어, 항공기 배치 금지 등)5. 승인된 로딩 절차 또는 승인된 로딩 절차에 대한 기준

6. 형상관리를 유지하기 위해 필요한 유지보수 기록 기입 절차

7. 항공기 비행 매뉴얼, 항공기 비행 매뉴얼 부록, 운용자 매뉴얼 등 해당 자료에

대한 참조 문헌

제24조(FLS 유지보수 및 부품 표식 고려사항) FLS의 유지보수 및 부품 표식은 관련

규정의 해당 항목에 따라 수행하여야 한다. TC, ATC, STC, ASTC, TSOA 절차에서

FLS에 특별하게 적용되는 추가 유지보수 및 부품 표식 고려사항은 다음과 같다.1. 신청자의 항공기 정비 매뉴얼 또는 감항성 유지 지침에는 FLS를 사용하는 항공용

장비를 정비할 때 따르는 절차가 포함되어야 한다.2. 신청자의 항공기 정비 매뉴얼 또는 감항성 유지 지침에는 정비 요원이 항공용

장비에 대한 정비를 수행하기 전․후에 소프트웨어 부품번호 형상을 확인하도록

요구하는 절차가 포함되어야 한다. 소프트웨어 부품번호가 확인되지 않는 장비가

있으면, MEL에서는 영향을 받는 장비를 불능화하여 항공기를 서비스

재개(returned to service)할 수 있는지를 명시하여야 한다. 항공기 배치를 명확히

할 수 있는 방법은 MEL 제한사항에 따른다.3. 정비 요원이 로딩된 FLS 부품번호를 필요한 정비 로그에 기록함을 보증하는 절차

가 있어야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 19 -

4. 하드웨어와 소프트웨어가 분리된 부품 번호를 갖는 항공용 장비의 경우, 전자적

질의 형태로 확인할 수 있으면 소프트웨어 부품번호는 유닛의 외부에 표시할

필요는 없다. 소프트웨어 부품번호가 기록되었음을 보증하는 것은 정비 요원의

책임이다. 새로운 소프트웨어가 유닛에 로딩되었을 때, 동일한 요구조건이

적용되어 유닛이 서비스를 재개하기 전에 승인된 소프트웨어 부품번호가

확인되어야 한다.5. 소프트웨어와 하드웨어의 특정 형상을 표현하는 하나의 부품번호를 갖는 항공용

장비에 대해, 새로운 소프트웨어가 로딩될 때, 명판의 유닛식별사항은 변경되어야

한다. 새로운 소프트웨어가 로딩될 때, 데이터 로딩 후에 타깃 컴퓨터에 저장된

소프트웨어의 부품번호는 전자적으로 검증하여야 한다. 유닛의 서비스 재개 전에

전자적 소프트웨어 부품 번호와 명판에 표시된 유닛의 부품번호는 승인된 형상임

을 확인하여야 한다.6. TSO 승인된 제품에 FLS가 사용되어 신청자가 FLS에 대해 전자적 부품 표식을

원하는 경우, FLS는 KAR §21.607(d)의 부품 표식 요구조건을 만족하여야 한다. KAR §21.607(d)에서 요구하는 특정 정보는 하드웨어 부품번호가 지상에서 식별

가능하듯 어떤 지형적 위치에서도 지상에서 확인 가능하여야 한다.7. 부품등제작자증명(PMA) 절차를 통행 승인된 FLS에 전자적 부품 표식이 사용된다

면, FLS는 관련 규정의 부품 표식 요구조건을 만족하여야 한다.8. 소프트웨어 부품번호, 버전, 및/또는 운용 특성의 변경은 운용자 매뉴얼, 항공기

비행 매뉴얼, 항공기 비행 매뉴얼 부록 및/또는 기타 해당 문서에 반영하여야 한다.

제6장 부품등 제작자 증명 절차를 통해 동일성을 판정하는

현장로딩가능 소프트웨어의 승인

제25조(동일성 수립) ①동일성은 (1) 신청자가 면허 협약을 통해 설계를 획득하였다는

증거 제시, (2) 신청자의 설계를 이전 승인 설계와 비교 중 하나로 수립될 수 있다. FLS의 부품등제작자증명(PMA)은 소프트웨어에 고유한 다음의 추가 고려사항과 함

께 KAR Part 21과 부품등제작자증명 지침에 설명된 동일한 절차를 따라야 한다. 1. 면허 협약의 증거를 제시하여 동일성 판단

가. 설계 승인. 면허 협약에 관한 부품등제작자증명지침에서 PMA 신청자는 “TC 소유자가 제출한 데이터 패키지의 사용을 승인하는 적절한 문서”를

제출하도록 명시하고 있다. 면허 협약 방법으로 PMA 설계승인을 하기 위해

다음 항목을 고려하여야 한다.(1). PMA를 통해 승인되는 FLS는 사전에 TC, ATC, STC, ASTC 절차를 통해

인증당국의 승인을 받아야 하며, 이 지침의 5장에서 설명하는 절차를 보유

하여야 한다. (2). 승인된 소프트웨어는 정비회보 또는 기타 인증당국이 승인한 방법을 이용


제정: 2009.07.27 개정: 2011.1.3 - 20 -

하여 항공기에 장착될 수 있다. (3). 소프트웨어 부품번호, 하드웨어 부품번호, 항공기 모델, 항공기 일련번호

등 해당하는 번호의 조합이 TC, ATC, STC, ASTC 절차 동안 승인된 조합

과 동일함을 보증하기 위한 형상관리 절차가 있어야 한다.나. 설계 변경. 부품등제작자증명지침에서는 PMA에 대한 설계 변경 상황을 설명

한다. 면허 협의를 통해 입증된 부품등제작자증명(PMA)에 의해 승인되는

FLS는 다음과 같은 지침을 적용한다. (1). TC, ATC, STC, ASTC 소유자와 인증 당국이 항공기에 대한 변경 영향이

중 또는 경인지 평가하여 FLS의 변경을 조율한다. 이 지침의 11장은 중

또는 경 분류를 결정하기 위한 소프트웨어 변경 영향 분석에 사용되는

지침을 제공한다. (2). 부품등제작자증명지침에서는 중 변경은 “원 PMA와 동일한 방법으로 적

용하기 전에 입증하고 승인받아야 한다.”라고 기술하고 있다. (3). 변경이 경으로 판정되면, 부품등제작자증명지침에서 정의하는 절차를

따른다.2. 면허 협약 없이 동일성 판단

가. 설계 승인. 부품등제작자증명지침에서는 신청자의 동일성 확인서는 “설계가

승인된 설계에서 다루어진 부품의 설계와 모든 관점에서 동일하다”는 것을

보증하여야 한다. 면허 협약 없이 동일성을 사용하는 PMA 설계승인에 대해, 다음 사항을 고려하여야 한다. (1). 승인되는 FLS는 TC, ATC, STC, ASTC 절차를 통해 인증 당국이 이전에

승인한 소프트웨어와 동일하다는 것을 입증하여야 한다. TC, ATC, STC, ASTC 절차의 일부로 승인된 원래 FLS는 이 지침의 5장과 RTCA DO-178B의 12.5항에서 논의된 절차가 있어야 한다.

(2). 설계 동일성은 소프트웨어의 전자적 이미지가 정확하게 일치한다는 것을

입증하기 위해 비트 대 비트(bit-by-bit)의 확인 형태로 실증할 수 있다.(3). 비트 대 비트(bit-by-bit) 확인에 추가하여, 동일성 주장을 지원하는 활용

가능한 설계 증거가 있어야 한다. 설계 동일성의 증거에는 원래 승인의

일부로 요구되는 모든 소프트웨어 개발 및 설계 데이터의 가용성이

포함된다. RTCA DO-178B 또는 기타 수락가능한 적합성 입증방법에서

요구하는 데이터는 동일성을 보증하기 위해 인증당국이 가용하도록

하여야 한다. 나. 설계 변경

(1). 면허 협약 없이 동일성에 의한 FLS의 설계 변경은 중 변경으로 간주하여

야 한다. (2). 부품등제작자증명지침에서는 중 변경은 “원 PMA와 동일한 방법으로 적

용하기 전에 입증하고 승인받아야 한다.”라고 기술하고 있다. 다. 인증당국의 책임. 인증당국의 검사관은 면허 협약에 의한 동일성을 다룬다.


제정: 2009.07.27 개정: 2011.1.3 - 21 -

반면, 감항엔지니어는 다른 PMA의 접근방식을 다룬다.②하드웨어의 PMA에서, 형식 설계는 기술적 도면으로 수립된다. 그러나 소프트웨어

에 대한 접근방식은 다르다. FLS에 대한 PMA를 보증할 때, 인증당국의 검사관은

다음의 접근방식을 고려하여야 한다. 1. 최상위 기술적 도면은 SCI로 완성될 수 있다. 따라서 형식 설계 데이터로 PMA

부록에 SCI와 그 배포 날짜를 나열하는 것은 수락가능하다. 2. SCI에 SAS가 포함되지 않으면, PMA 부록에 포함되어야 한다.3. 일부 프로젝트에서 SCI를 참조하는 더 높은 수준의 도면을 가질 수 있다. 이러한

경우, 더 높은 수준의 도면은 SCI 대신에 PMA 부록에 포함될 수 있다.

제26조(TSO의 적용성) TSOA에 대한 FLS를 포함하는 유닛의 PMA 적용성은 KAR Part 21, subpart O와 부품등제작자증명지침에서 논의된 것과 동일하다. FLS를 포

함하는 TSO의 유닛에 대해 PMA 절차가 사용된다면, KAR Part 21, subpart O와

부품등제작자증명지침와 연계하여 이 장의 지침을 따라야 한다.

제7장 사용자수정가능 소프트웨어(UMS)를 포함하는 항공용 시스템 및 장비의 승인

제27조(UMS 안전성 고려사항) ①사용자에 의한 사용자수정가능 소프트웨어(UMS)의

수정은 항공기 안전성 여유, 항공기 운용 역량, 비행 승무원 작업부하, 수정 불가

소프트웨어 구성품, 시스템 보호 메커니즘 등에 영향을 주지 않도록 하여야 한다. 사용자의 UMS 일부 수정은 운용 승인 또는 수락이 필요할 수 있다.

②UMS 구성품은 사용자가 변경할 수 있도록 설계되고 의도된 항공용 시스템 내의

소프트웨어로, 신청자로 하여금 UMS 수정 제약사항을 개발하여 사용자에게 제공하

도록 하여야 한다. 다음 항목에 영향을 주는 UMS의 변경은 사용자수정가능인 소프

트웨어의 분류를 취소하여야 하고, 해당 규정 하에서 설계 승인이 요구된다.1. 안전 여유, 운항 역량, 비행 승무원 작업부하, 수정 불가 소프트웨어 구성품,

보호 메커니즘, 소프트웨어 경계

2. 데이터, 파라미터, 정비 성능 특성의 이전 승인된 범위. 안전성에 영향을 줄 수

있는 UMS로 사용되는 다중 트림 수치는 특별한 주의가 요구된다. ③UMS 변경의 잠재적 영향을 안전성 평가 절차를 통해 결정하여야 하고, 시스템

및 소프트웨어 설계 방법, 개발 및 검증 보증, 승인된 절차, 승인된 툴(해당하는 경우) 등을 통해 완화한다. RTCA DO-178B 절차의 일부로 데이터를 평가할 때, 신청자와

인증당국은 보호 메커니즘, 검증, 사용자수정가능 절차 등이 수정 불가 구성품과

보호 무결성을 방해하지 않는다는 것을 보증하여야 한다. 신청자로 하여금 프로그램

초기에 보호 메커니즘, 보호 검증, 수정 절차 및 툴에 대한 수락에 대한 인증당국과의

협력을 확보하도록 하여야 한다. 보호 메커니즘은 UMS를 포함하는 시스템의 초기

승인 단계에서 평가되어야 한다. 사용자에 의한 시스템 변경이 보호 메커니즘에


제정: 2009.07.27 개정: 2011.1.3 - 22 -

영향을 주지 않는다는 것을 보증하여야 한다.

제28조(시현 데이터에 대한 고려사항) 정보가 비행 승무원에게 시현되고 UMS로부터

유래하는 경우, 정보는 인증당국이 항공기 형식설계의 일부로 승인하지 않은 “참고

데이터(advisory data only)”라고 구분하여 식별하여야 한다. 시현되는 정보가 해당

운용 승인 당국으로부터 항공기의 운용 절차의 일부로 운용 승인을 받은 경우, 이

구분은 필요하지 않을 수 있다. 두 가지 유형의 정보에 대한 구분 오류를 합당하게

배제할 수 있고 비행 승무원이 쉽게 볼 수 있도록 설계, 장비의 고유 특성, 사용자수정가능 구성품 등이 승인된 정보와 비승인 정보를 구분한다면, “참고

데이터(advisory data only)”라는 정보의 직접적인 식별은 요구되지 않을 수 있다. 요구되는 곳에서, 수정 불가 구성품이 이런 식별을 제공하여야 하고, 비행 승무원이

인증 또는 운용 승인 당국이 승인하거나 수락한 정보들을 쉽게 구별하도록 하여야

한다. “참고 데이터(advisory data only)” 정보는 항공기의 다른 출처로부터 비행

승무원이 검증할 수 있어야 하고, 오해하기 쉬운 데이터를 표시하는 잠재적 최악

경우의 고장조건이 경 고장조건보다 큰 경우 어떠한 정보도 시현하는데 사용하지

않아야 하거나, 비행 승무원이 항공기 운용 절차를 수행하는데 사용되지 않아야

한다.

제29조(항공기 성능 파라미터의 변경) 안전 여유, 항공기 운용 역량, 승무원 작업부하

등에 영향을 줄 수 있는 변경에는 항공기 성능 파라미터를 결정하기 위해 비행

승무원이 사용하는 시현 데이터 또는 기타 데이터의 변경은 인증 당국의 승인이

필요하다. 이러한 파라미터를 제공하거나 개정하는 사용자수정가능 구성품의

변경은 파라미터들이 1차 정보 또는 참고 정보로 제공되는지에 상관없이 인증당국의

승인이 필요하다. 이러한 변경은 사용자수정가능이란 소프트웨어의 분류를 무효로

하고, 설계 승인 및 부품 번호 개정이 필요하다.

제30조(보호) 항공용 시스템의 수정 불가 소프트웨어 구성품은 UMS 구성품으로부터

보호하여야 한다. 시스템 요구조건에는 시스템 안전성, 운용 역량, 비행승무원

작업부하 등에 영향을 주는 사용자 수정을 방지하기 위한 보호 메커니즘을

명시하여야 한다. 시스템 요구조건에 사용자 수정에 대한 방책을 포함하지 않으면, 사용자는 소프트웨어를 변경하지 않아야 한다. 보호 메커니즘은 시스템 안전성

평가에서 결정된 시스템의 가장 심각한 고장상태의 보증 레벨을 할당하여야 한다. 소프트웨어가 UMS에 대한 보호 메커니즘을 제공한다면, 그 소프트웨어 보호에는

시스템 안전성 평가에 의해 결정된 시스템의 가장 높은 소프트웨어 레벨을

할당하여야 한다. 보호는 변경 또는 보호 손실로 야기되는 UMS의 고장을

방지하여야 한다. 보호 무결성은 사용자의 활동에 의존해서는 안 된다. 보호

무결성은 우연히 또는 고의적으로 침해될 수 없도록 하여야 한다. 신청자가 제공하는

UMS 수정 방법은 수정가능 구성품을 변경할 수 있는 유일한 방법이어야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 23 -

제31조(수정 불가 구성품을 보호하는데 사용되는 툴) ①RTCA DO-178B의 5.2.3항에서

는 수정 불가 소프트웨어 구성품은 그 안전 작동과의 간섭을 방지하기 위해 수정가

능 구성품으로부터 보호되어야 한다. 수정가능 구성품에 변경을 가하는 툴이 보호

를 강제하기 위해 사용된다면, 승인을 위해 신청자가 인증당국에 다음과 같은 정보를

제공하여야 한다. 1. 툴 버전 관리 계획

2. 툴 사용 관리 계획

3. 툴 검정 또는 확인 계획(RTCA DO-178B 12.2항과 이 지침의 9장 참조)4. 툴 변경 절차

②툴 구성품을 구성하고 보호 기능을 수행하는데 사용되는 소프트웨어는 시스템

안전성 평가에서 결정된 것과 같이 시스템의 최악 고장조건의 소프트웨어 레벨로

개발되어야 한다.③사용자 수정을 위한 소프트웨어 툴의 사용은 툴 검정과 툴 사용과 유지보수를

위한 절차의 승인이 요구된다(RTCA DO-178B 12.2항과 이 지침의 9장 참조). 툴

또는 절차의 변경은 툴의 재검증이 요구될 수 있다.

제32조(데이터 요구조건) ①신청자는 UMS 구성품을 포함하는 항공용 시스템의 개발

목적을 소프트웨어인증계획(PSAC)에서 명시하여야 한다. 또한 PSAC에서는 (1) RTCA DO- 178B의 적합성 입증방법(5.2.3항의 설계고려사항 포함), (2) 보호

메커니즘, (3) 보호 메커니즘의 무결성을 보증하는 방법 등을 기술하여야 한다. 소프트웨어 툴이 변경을 위해 사용되는 경우, PSAC에는 승인된 절차와 제약조건에

따라 툴이 UMS를 수정하고 수정 불가 소프트웨어 또는 보호 메커니즘에 영향을

주지 않는다는 것을 보증하기 위해 툴 검정 계획 또는 확인 절차도 명시하여야 한다.②소프트웨어 개발 계획과 설계 데이터는 사용자 수정으로부터의 보호를 보증하기

위해 설계 방법과 구현 상세사항을 명시하여야 한다.③해당하는 경우, 소프트웨어형상색인(SCI)에서 툴 검정 데이터를 포함하여 승인된

절차, 방법, UMS를 수정하기 위한 툴 등을 명시하여야 한다.④해당하는 경우, 소프트웨어구현요약(SAS)에서 툴 검정을 포함하여 수정 불가 소프

트웨어 구성품, UMS 구성품, 보호 메커니즘, 수정 절차와 툴 등의 개발 및 검증

모두를 요약하여야 한다.

제33조(기타 고려사항) ①사용자 수정 시점에서, 사용자는 UMS 구성품의 모든 점과

소프트웨어 수정에 사용되는 툴에 대한 책임을 갖고 있다. 이런 것에는 소프트웨어

형상관리, 소프트웨어 품질보증, 소프트웨어 검증도 포함된다. 사용자 수정은 승인된

툴을 사용하여 시스템 요구조건 및 소프트웨어 데이터에 의해 수립된 승인된 절차에

따라 수행하여야 한다. 사용자가 수정불가 소프트웨어 구성품, 보호 메커니즘, 승인된

절차, 승인된 툴 (시스템 요구조건 및 승인된 절차에 의해 수립된 것 이외)에 수정을


제정: 2009.07.27 개정: 2011.1.3 - 24 -

가한다면, 사용자는 형식설계에 위반하는 것이고, 항공기의 형식증명은 취소될 수

있다.②인증 동안, 인증당국은 현장에서 항공기 형상 변경 승인(예를 들어, 운용 승인)을

담당하는 규정 당국과 조율하여야 한다.③소프트웨어 변경을 추적하거나 기록하는 시스템은 필요한 경우 관할 당국이 변경

의 인증 및 감항성 유지 모두를 검토할 수 있음을 고려하여야 한다(해당하는 경우).

제8장 이전 개발 소프트웨어: RTCA DO-178B의 레벨 D 기준 적용

제34조(레벨 D의 PDS 승인) 레벨 D의 이전개발소프트웨어(Previously Developed Software, PDS) 승인에 관련된 프로젝트의 경우, 인증당국은 다음과 같은 절차를

따라야 한다.①소프트웨어 검토자는 다음 사항을 보증하기 위해 소프트웨어 계획을 검토하여야

한다.1. 계획이 존재한다.(예: PSAC, SDP, SCMP, SQAP, SVP)2. 이러한 계획들이 이행된다.(RTCA DO-178B 부록 A의 표 A-9 목표 1 참조)3. 계획은 레벨 D 소프트웨어에 대해 RTCA DO-178B 목표의 적합성을 가능하게

한다.②소프트웨어 검토자는 레벨 D의 PDS에 대해 저수준 요구조건, 소프트웨어 아키텍처, 파생된 저수준 요구조건, 소스 코드 등이 정의되고 존재한다는 것을 확인하여야 한

다. 소프트웨어 검토자는 RTCA DO-178B 목표 및 소프트웨어 라이프 사이클 데이터

의 내용 요구조건에 대한 소프트웨어 라이프사이클 데이터 아이템의 품질이나 내용

을 평가하지 않아야 한다. 다만, 소프트웨어 파티셔닝 무결성을 확인하기 위해 필요

한 곳은 예외로 한다(표 A-4의 목표 13). 이러한 목표는 표 A-6과 A-7의 목표에 의해

충족된다.③PDS를 평가할 때, 신청자는 다음 절차를 수행하여야 하고 인증당국은 확인하여야

한다. 1. 레벨 D 소프트웨어의 고장조건 또는 기능장애가 경 이하의 고장조건을 야기하거나

기여할 수 있음을 검증한다. 인증당국은 안전성 평가, 시스템 아키텍처, 소프트웨

어 레벨 결정 등을 확인하여야 한다.2. PDS에 사용될 기능, 통합될 PDS 구성품, PDS의 고장 또는 기능장애를 본질적

으로 완화하기 위해 개발되는 소프트웨어(예를 들어, 레퍼(wrapper) 코드, 파티

셔닝, 모니터) 등을 식별한다. 인증당국은 안전성 영향을 언급하고 있는지 확인

하여야 한다. 3. PDS는 타깃 어플리케이션에서 수락가능하지 않은 고장조건이 발생하지 않음을

보장한다. 인증당국은 이러한 평가를 확인하여야 한다.④다중 소프트웨어 레벨의 소프트웨어 어플리케이션이 주어진 시스템 및/또는 구성품


제정: 2009.07.27 개정: 2011.1.3 - 25 -

기준 개발 참조 검증 참조

결정론적 툴만이 검증될 수 있다(더 자세한 것

은 이 장의 제38조에서 설명한다)예 12.2 예 12.2

검증은 특정시스템에만 적용한다. 의도는 PSAC

에 언급되어야 한다.예 12.2 예 12.2

파티셔닝을 입증할 수 없다면, 조합된 툴은 예 12.2.b 예 12.2.b

툴 검정에 적용되는 RTCA DO-178B의 기준

에 포함된 경우, 시스템 및/또는 구성품의 최상위 소프트웨어 레벨의 목표를 만족하기

위해 상이한 소프트웨어 레벨 사이의 보호 및 관련 메커니즘(예: 파티셔닝, 안전 모니터

링, 감시 타이머)을 검증하여야 한다. 또한 신청자는 식별된 기능 또는 공동 자원의

공통원인 및 공통모드 손실은 최초에 개별 시스템에 할당된 것보다 나쁜 고장조건을

유발하지 않음을 검증할 필요가 있다. 이러한 경우, 개발 노력의 일부는 PDS가 상기에

기술한 것과 같이 모든 레벨 D 목표를 충족함을 입증할 수 있음을 실증한다. ⑤레벨 D 소프트웨어는 다른 레벨의 소프트웨어와 연계하여 운용될 수 있다. 그런

경우, 시스템 안전성 평가와 협력하여 철저한 보호/파티셔닝 분석을 수행하여야 한다.

제9장 RTCA DO-178B를 사용한 소프트웨어 툴의 검정

제35조(검정 여부의 결정) ①툴 검정(tool qualification) 필요성 여부는 툴의 종류(개발

툴 또는 검증 툴)에 따른다. 다음에 해당하는 경우, 툴은 검증되어야 한다.1. 툴이 그 의도된 사용범위 내에서 항공용 소프트웨어에 오류를 삽입할 수 있거나

소프트웨어에 이미 존재하는 오류에 대한 탐지에 실패한다. 2. RTCA DO-178B의 6장에서 규정하듯, 툴의 산출물이 검증되지 않거나 다른 검증

활동에 의해 확인되지 않는다. 3. RTCA DO-178B의 절차가 툴 사용으로 제거, 축소, 자동화 된다. 즉, 툴로부터의

산출물이 RTCA DO-178B 부록 A의 목표를 충족 또는 대신하는데 사용된다.②일단 툴이 검증이 필요하지 않다고 결정되었으면, RTCA DO-178B의 12.2항의 잔여

부분은 툴에 적용하지 않는다. 시의적절한 반응을 보증하기 위해, 인증당국은 인증

프로젝트의 툴 검정 협의에 빨리 관여하여야 한다. ③PSAC에 모든 소프트웨어 목록과 개별 툴에 대한 검증 필요성 여부에 대한 정당화

설명을 포함하여야 한다.

제36조(검정 기준의 결정) “툴 검정에 적용되는 RTCA DO-178B의 기준”은 검증이

필요한 툴에 적용하고, RTCA DO-178B의 12.2항의 기준이 어떤 유형의 툴에 적용

되는지 결정하는데 사용할 수 있다.


제정: 2009.07.27 개정: 2011.1.3 - 26 -

RTCA DO-178B의 12.2.1항에 따라 검증되어야 한

다(더 자세한 것은 제38조에서 설명한다)

검증될 툴에 소프트웨어 형상관리 및 품질보증

절차 목표를 적용하여야 한다.(더 자세한 것은

이 지침 제38조에서 설명한다)

예 12.2.c 예 12.2.c

항공용 소프트웨어처럼 검증은 동일한 목표를

만족하여야 한다. 예 12.2.1.a 아니오

툴의 소프트웨어 레벨은 감소할 수 있다. 예 12.2.1.b 아니오

툴 작동 요구조건에 대한 적합성 입증을 위한

수단으로 시운전 기간이 사용될 수 있다. 예 12.2.1.c 예 12.2.2

툴 작동 요구조건이 검토되어야 한다. 예 12.2.1.d(1) 예 12.2.2

정상 작동 조건에서 툴 작동 요구조건에 대한

적합성이 입증되어야 한다. 예 12.2.1.d(2) 예 12.2.2

비정상 작동 조건에서 툴 작동 요구조건에 대한

적합성이 입증되어야 한다. 예 12.2.1.d(3) 아니오

요구조건 기반의 커버리지가 분석되어야 한다. 예 12.2.1.d(4) 아니오

툴의 소프트웨어 레벨에 해당하는 구조적 커버

리지가 완료되어야 한다. 예 12.2.1.d(5) 아니오

툴의 소프트웨어 레벨에 해당하는 강건성 시험

이 완료되어야 한다. 예 12.2.1.d(6) 아니오

잠재적 오류가 분석되어야 한다. 예 12.2.1.d(7) 아니오

데이터 적용성가용/ 제출

RTCA DO-178B 참조

소프트웨어 인증계획서(PSAC) 검증 및 개발 제출 12.2, 12.2.3.a, 12.2.4

툴 검정 계획서 개발 제출12.2.3.a(1), 12.2.3.1, 12.2.4

툴 작동 요구조건 검증 및 개발 가용 12.2.3.c(2), 12.2.3.2

소프트웨어 구현요약서 (SAS) 검증 및 개발 제출 12.2.4

툴 검정구현요약서 개발 제출 12.2.3.c(3), 12.2.4

툴 검정에 필요한 데이터

제37조(검정에 필요한 데이터 및 그 가용성) ①툴 검정에 필요한 데이터는 다음과 같

다. 개발 툴 검정시, PSAC은 툴 검정 계획을 참조하여야 한다. 그리고 SAS는 툴

검정구현요약서를 참조하여야 한다. 검증 툴 검정시, 신청자는 툴 검정 계획서와 툴

검정구현요약서를 개발할 수 있다.


제정: 2009.07.27 개정: 2011.1.3 - 27 -

툴 검정 기록(예를 들어, 시험

케이스, 절차, 결과)검증 및 개발 가용 12.2.3

툴 검정 개발 데이터(예를 들어, 요구조건, 설계, 코드)

개발 가용 12.2.3

②소프트웨어 검증 툴 검정에 대해, 다음 데이터 제출 및 가용성을 고려한다.1. 검증 툴에 대해, 신청자는 PSAC에서 검증 툴의 사용 의도를 명확히 한다(RTCA

DO-178B 12.2항 참조). PSAC은 인증당국에 제출하여야 하고, 의도한 툴 검정

일정을 포함하여야 한다. 인증당국은 PSAC의 검증 툴 검정 접근방식을 검토하

여 시의 적절하게 PSAC에 나열되거나 참조된 접근방식에 대한 수락성을 신청

자에게 서면으로 제공하여야 한다. 2. 검증 툴 검정에 대해, 툴 작동 요구조건은 문서화되어 인증당국이 활용 가능하여

야 한다(RTCA DO -178B의 12.2.3.2항 참조). 툴 작동 요구조건 데이터에 대한

요구조건은 제38조에서 논의된다. 3. 툴 작동 요구조건의 모든 요구조건이 검증되었음을 보이는 데이터는 인증당국의

검토를 위해 문서화 하여 활용 가능하여야 한다. 신청자는 이러한 검증 데이터를

신청자가 선정한 어떤 문서에도 담을 수 있다.4. 검증 툴 검정 결과를 요약하는 내용(entry)을 SAS에 포함하여야 한다. SAS를

인증당국에 제출하여야 한다. 신청자는 소프트웨어 검증 툴에 대해 PSAC과

SAS에서 기입 내용으로, 참조되는 툴 검정 계획과 툴 검정 구현요약서를 따라

제공하는 것을 선택할 수 있다.③소프트웨어 개발 툴 검정에 대해, 다음 데이터 제출 및 가용성을 고려한다.

1. 실제 검증 접근방식과 제공할 데이터를 툴 검정 계획서에 명시하여야 한다. 인증당국은 신청자로 하여금 툴 검정 계획서를 제출하도록 하여야 한다.

2. 툴 검정구현요약서도 인증당국에 제출하도록 하여야 한다. 툴 검정 구현요약서

는 툴 검정 절차의 결과를 요약하고 관련 툴 검정 데이터를 설명하고 인용한다. 3. 인증당국은 신청자로 하여금PSAC과 SAS를 제출하고 인증당국의 승인을 받도

록 하여야 한다. 그러나 이러한 문서들은 툴 검정 계획서와 툴 검정구현요약서

문서를 참조하는 데만 사용된다.4. 툴 작동 요구조건은 문서화되어 인증당국이 활용 가능하여야 한다(RTCA

DO-178B 12.2.3.2항 참조). 툴 작동 요구조건 데이터에 대한 요구조건은 제38조에서 논의한다.

5. 툴 작동 요구조건의 모든 요구조건이 검증되었음을 보이는 데이터는 인증당국

의 검토를 위해 문서화 하여 활용 가능하여야 한다. 정상 및 비정상 조건하에서

툴이 작동하는 것을 입증하는데 상당한 검증 데이터가 필요하다. 데이터는 툴의

복잡성 및 목적, 어떻게 툴이 사용되는지에 따라 달라진다. 인증당국은 신청자

가 이러한 검증 데이터를 신청자가 선정한 어떤 문서에도 포함시킬 수 있도록


제정: 2009.07.27 개정: 2011.1.3 - 28 -

할 수 있다.6. 설계, 코드, 시험 케이스, 절차 등과 같은 기타의 툴 검정 데이터도 인증당국의

검토를 위해 활용 가능하여야 한다.④인증당국은 신청자가 사용하는 문서 형식 및 매체 유형을 사용하기 위해 노력하여

야 한다. 인증당국에 제출하기 위해 재패키지하는 것은 신청자가 제공하는 방식으

로 인증당국이 데이터를 검토할 수 없거나 신청자가 관련 규정에 대한 데이터 보관

규정을 만족시키지 못할 때에만 수행한다.

제38조(작동 요구조건 데이터의 수락성 평가) ①검증이 필요한 툴의 작동 요구조건은

완성되어 인증당국의 검토를 위해 활용 가능하여야 한다. 툴 작동 요구조건은 툴의

모든 기능적 기술적 특성과 툴이 장착될 환경을 식별하여야 한다.(RTCA DO-178B의

12.2.3.2항 참조). 필요한 정보는 툴의 유형에 따라 달라진다.②검증 툴에 대해, 툴 작동 요구조건에서는 최소한 다음과 같은 정보가 제공되어야

한다.1. 툴 검정 시험의 일부로 검증되는 특정 요구조건으로 표현되는 툴의 기능

2. 작동 시스템과 기타 고려사항을 포함한 툴 작동 환경의 정의 (예: 툴이 수행하지

않는 것에 대한 분석, 그 부족을 포함하기 위해 필요한 것(점검표, 시험케이스의

확대 같은), 특화된 하드웨어 요구조건(프로세서, 특별 시험 장비, 인터페이스 등))3. 툴 작동 요구조건에 포함되어야 하는 툴 장착 또는 작동에 필요한 기타 정보(사용

자 매뉴얼 등)③개발 툴은 검증 툴에서 나열한 모든 정보를 포함하여, 최소한 다음과 같은 정보가

제공되어야 한다. 1. 툴이 수행하는 소프트웨어 개발 절차

2. 비정상 작동조건에서 예상되는 응답. 일부의 경우, 사용자 매뉴얼 또는 기타

공급업자의 문서가 필요한 정보를 포함할 수 있다. 추가적인 정보가 필요한 정보

를 포함한 경우, 필요한 정보를 명확하게 식별하여야 한다. 툴 공급업자가 불충

분한 정보를 제공하는 경우, 신청자는 누락된 정보를 제공하여야 한다.④개발 및 검증 툴은 툴 작동 요구조건의 검증이 필요하다. 검증 툴의 경우, 정상

작동 조건에서의 검증만이 요구된다. 개발 툴의 경우에는 비정상 작동조건에서의

검증이 추가로 요구된다. 작동 요구조건에는 검증 활동과 직접적으로 연관되지 않은

추가 정보가 포함될 수 있기 때문에(메뉴의 형상, 다이얼로그 박스, 구성 등) 검증

툴에 대한 불필요한 검증을 줄이기 위해 추가적인 안내가 필요하다. 검증 툴에

대해서만, 작동 요구조건의 그런 부분이 툴 검정의 일부로 검증되어야 하는 검증의

구성, 수행, 감시, 보고 등에서 직접적으로 사용된다. 신청자는 사용되지 않는 검증

툴의 이러한 특성 부분이 사용되는 특성 부분에 약영향이 없음을 보증하여야 한다. 추가적인 특성이 나중에 사용된다면, 추가적인 검증이 필요하다.⑤툴 결정론의 해석에 대한 지침

1. 결정론적 툴만이 검증될 수 있지만(RTCA DO-178B의 12.2.3항 참조), 결정론의


제정: 2009.07.27 개정: 2011.1.3 - 29 -

축소적 해석이란 명백한 동일 입력은 필연적으로 정확하게 동일한 결과로

인도된다는 것을 말한다. 그러나 툴의 결정론에 대한 더 정확한 해석은 툴에

의한 출력의 정확성을 결정할 수 있는 능력이 수립되어 있다는 것을 말한다. 주어진 입력으로부터 출력의 모든 가능한 편차는 그 결과의 적절한 검증하에서

올바르다는 것을 입증할 수 있다면, 툴은 툴 검정에서 결정론적이다라고

간주하여야 한다.2. 결정론에 대한 해석은 툴의 출력이 사용자의 통제를 넘어 다양해 질 수 있으나

변동이 출력의 의도된 사용(예를 들어, 기능)에 악영향을 주지는 않고 출력의

정확함에 대한 사례가 존재하는 모든 툴에 적용되어야 한다. 그러나 이러한

결정론의 해석은 항공용 시스템에 탑재되는 최종 실행가능 이미지에 영향을

주는 툴에는 적용되지 않는다. 최종 실행가능 이미지의 생성은 결정론의 축소적

해석을 만족하여야 한다. 예로서, 툴은 도표적 방식으로 사용자와

상호작용하는 그래픽 사용자 인터페이스(GUI)를 가질 수 있다. 이 툴의 기초가

되는 것은 그러한 도표의 의도된 의미를 획득하는 데이터 표이다. 그러나 종종

이러한 툴의 출력은 그러한 데이터 표에서 입력사항의 물리적 순서에 의해

부분적으로 조종된다. 그리고 데이터 표의 입력사항의 순서는 툴 사용자가

통제하지 않는다. 하지만 툴 출력의 정확성은 수립할 수 있다. 결정론의 축소적

해석으로는 이러한 툴은 검증할 수 없지만, 해석을 확대하면 검증이 가능할

수 있다.⑥조합된 개발 및 검증 툴의 검정에 대한 지침

1. 이 항은 개발 및 검증 기능의 양쪽 출력이 RTCA DO-178B의 절차를 제거, 축소, 자동화하는데 사용되는 조합된 개발 및 검증 기능을 제공하는 툴에만 적용한다. 개발 목표만을 또는 검증 목표만을 제거, 축소, 자동화하는데 사용되는 조합

툴은 그 툴에서 제공하는 다른 역량에 상관없이 검증하여야 한다. 2. 개발 및 검증 기능 모두가 RTCA DO-178B의 목표를 충족하거나 교체하는데

사용될 때 두 기능간의 보호/파티셔닝을 입증할 수 없다면, 항공용 소프트웨어의

레벨과 동일한 지침에 따라 조합된 툴의 검증을 수행하여야 한다. 이 보호/파티

셔닝의 수락 가능한 증거는 툴의 한 가지 기능의 출력이 툴의 다른 기능의 출력

에 영향을 주지 않는다(즉, 툴 역량이 기능적으로 분리되었다)는 것을 보여주는

것이다.3. 개발 및 검증 기능간의 보호/파티셔닝을 입증할 때, 보호/파티셔닝 기능은 기능이

개발과 검증 툴로 나눠진 것처럼 검증될 수 있다. 즉, 검증 기능은 검증 툴의

기준에 따라 검증할 수 있다.⑦검증된 툴 사용에 대한 신인도를 받기 위해(즉, RTCA DO-178B의 목표를

충족하거나 대체하기 위해), 이러한 툴들은 형상관리 하에 있어야 한다. RTCA DO-178B의 12.2.3b항에서는 개발 및 검증 툴의 검정 데이터에 대한 관리등급을

언급하고 있다(RTCA DO-178B의 7.2.9b항 참조). 개발 툴의 검증 데이터에 대한

관리등급은 동일 레벨의 항공용 소프트웨어에 필요한 관리등급과 같다. 한편, 검증


제정: 2009.07.27 개정: 2011.1.3 - 30 -

툴 검정 데이터는 “CC2”로 분류할 수 있다.⑧이전에 검증된 툴의 모든 변경에 대해 소프트웨어 변경영향 분석을 수행하여야

한다. 변경의 영향 하에 있는 다른 툴뿐만 아니라 제품에 대한 툴의 영향을 평가하는

데 충분하도록 분석을 철저히 하여야 한다. 회귀적 분석이 변경영향 분석의 일부를

구성할 수 있다.⑨툴이 이 장의 지침을 만족한다면, RTCA DO-178B 제정 이전의 프로젝트에 사용된

소프트웨어 툴은 RTCA DO-178B가 적합성 입증방법인 프로젝트에 사용한 것에 대

해 검증받을 수 있다. 대안으로, 그런 툴에 대해 서비스 이력이 고려될 수 있다.

제10장 RTCA DO-178B를 이용한 레거시 시스템의

소프트웨어 변경 승인

제39조(레거시 시스템의 소프트웨어 변경) ①레거시 시스템의 소프트웨어 레벨이 고려

되는 제품 장착에서 요구하는 것과 동일하거나 더 낫다는 것을 입증하지 못하면, 소프트웨어는 RTCA DO-178B의 12.1.4항 “개발 기준선의 상향”에 따라 등급을 올려

야 한다. 이러한 것은 RTCA DO-178B의 해당 목표에 대한 보증을 입증하기 위해

완전한 재평가가 필요할 수 있다. ②레거시 시스템의 소프트웨어를 변경하기 위한 대응에 필요한 조치에 영향을 줄 수

있는 4가지 변수가 있다.1. 최초 제품 또는 레거시 소프트웨어를 포함하는 레거시 시스템의 장착에 대한

인증 기준(즉, 규정, RTCA DO-178 버전, 최초 승인에 적용된 소프트웨어 레벨)2. RTCA DO-178B 또는 이전 버전이 고려중인 제품 또는 설치에 대한 소프트웨어의

수락 가능한 적합성 입증방법인지 여부(그리고 최초 인증의 소프트웨어 레벨에

대해 소프트웨어 레벨이 동일하거나 동등 한지 여부)3. 소프트웨어의 수정 또는 비변경 여부 (그리고 최초 인증 이후 변경된 횟수 및

그러한 변경의 이유)4. 소프트웨어 및 레거시 시스템이 장착되는 항공기 또는 엔진이 동일한지 다른지

여부

③소프트웨어 레벨이 동등하다는 것을 입증할 수 있다고 가정하면, 관심 대상인 레거시

시스템의 문제 대부분은 다음과 같은 그룹으로 분류할 수 있다.1. 레거시 시스템 소프트웨어가 수정되지 않고 원래 항공기에 재설치된다.2. 레거시 시스템 소프트웨어가 수정되지 않았지만 소프트웨어의 적합성

입증방법으로 RTCA DO-178B가 적용되지 않은 다른 항공기 또는 엔진에

장착된다. 3. 레거시 시스템 소프트웨어가 수정되어 원래 항공기 또는 엔진에 재장착된다.4. 레거시 시스템 소프트웨어가 수정되어 소프트웨어의 적합성 입증방법으로 RTCA

DO-178B가 적용되지 않은 다른 항공기 또는 엔진에 장착된다.


제정: 2009.07.27 개정: 2011.1.3 - 31 -

5. 레거시 시스템 소프트웨어가 수정되어 소프트웨어의 적합성 입증방법으로 RTCA DO-178B가 적용된 다른 항공기 또는 엔진에 장착된다.

6. 레거시 시스템 소프트웨어가 수정되지 않지만 소프트웨어의 적합성 입증방법으

로 RTCA DO- 178B가 적용된 다른 항공기 또는 엔진에 장착된다.④레거시 시스템은 이미 TC, STC, ATC, ASTC, PMA, PC, TSOA 절차를 통해 장착

또는 제작에 대해 인정된 승인을 보유하고 있다. 이러한 시스템의 소프트웨어에 변경

사항이 없다면 현 장착에 필요한 소프트웨어 레벨의 동등성을 확인할 수 있고, 최초

승인에 대한 시스템 사용의 유사성이 유지된다고 가정하면 소프트웨어의 최초 승인

은 여전히 유효할 수 있다. 항공기 또는 엔진에 장착하기 전에, 레거시 시스템이

최초 장착승인에서 사용된 방법과 상당히 다른 방식으로 사용되지 않음을 평가하여

야 한다.⑤경 변경이 있는 시스템은 RTCA DO-178B를 적용할 필요 없이 원래 승인기준의

변경처럼 처리하여야 한다. 경으로 분류될 수 있는 소프트웨어 변경의 예는 다음과

같은 것들이 포함된다. ․ 새로운 이득이 최초로 시험되고 승인된 이득 설정값 영역 내에 있는 이득의

변경

․ 유지보수 정보 형식의 변경

․ 출력 인터페이스의 추가

․ 이전에 검증되고 승인된 선택사양 모음 내에 있는 특성 모듈(personality module)에서의 데이터 변경

1. 인증당국은 최초 인증 기준 및 소프트웨어 지침 하에서 이러한 변경이 올바르게

수행되었음을 쉽게 확인할 수 있어야 한다. 최초 인증에 사용된 RTCA DO-178의

개정판에 적절한 전형적인 제출 데이터는 여전히 그러한 변경이 올바르게 이행

되었음을 보증하는 평가에 필요하다. 이러한 것이 수행되지 않으면, 경 변경이

아니다.2. 경 변경이라는 결정은 코드라인(Line Of Code, LOC)의 지표 또는 계산 등으로

결정할 수 없다. 따라서 이러한 결정은 이 지침의 11장에서 설명하는 소프트웨어

변경영향 분석 절차에 기초한다. 시스템이 최초 또는 차후 설치 승인에서 사용된

것과 다르게 사용되거나 시스템이 운용중 어려움을 경험하였다면, 경 변경을

허용하는 절차를 따르지 않아야 한다.⑥레거시 시스템이 경 변경을 넘어 변경이 이루어졌을 때, 변경이 올바르게 이행되고

검증되었음에 대한 보증이 요구된다. 다음 항목을 고려하여야 한다.1. RTCA DO-178의 이전 버전에는 몇몇 목표와 지침에 대한 잘 정의된 수락기준이

포함되어 있지 않다. 2. 일부 신규 기술과 툴 검정은 RTCA DO-178의 이전 버전에서는 언급조차 되고

있지 않다. 애매함이 있는 모든 경우에, 더 정확한 해석을 제공하기 위해 RTCA DO-178B를 사용한다.

3. 이전 승인과 일치하기 위해, 변경, 변경된 소프트웨어 구성품, 소프트웨어 변경에


제정: 2009.07.27 개정: 2011.1.3 - 32 -

영향을 받는 구성품을 만드는데 사용된 절차를 평가하기 위해 RTCA DO-178B를 사용한다. 이 지침의 11장의 지침과 RTCA DO-178B의

12.1.1~12.1.6항을 활용한다. 소프트웨어 변경에 대한 변경영향 분석을

수행하고 기타 구성품, 인터페이스, 타이밍, 메모리 등에 대한 영향을 식별하여

영향을 받는 구성품을 확인하여야 한다.(예: 컨트롤 흐름 분석, 데이터 흐름 분석, 타이밍 분석, 메모리 사용 분석) 또한 이러한 분석에서 변경사항을 검증하는데

필요한 회귀 시험의 수준과 범위를 식별하여야 한다.4. 소프트웨어의 영향을 받지 않는 부분은 이미 승인 기준을 가지고 있으며

제39조④에 따라 수락 가능하다. 대부분의 경우, 소프트웨어에 잔존하는 잠재적

오류의 위험은 이전 승인의 서비스 경험 이점을 고려하여 더 완화될 수 있다. RTCA DO-178B의 12.3.5항 “제품 서비스 이력”에는 서비스 경험의 사용을 허용하기 위해

만족되어야 하는 기준이 포함된다. 신청자가 충분한 관련 서비스 이력 데이터를

갖고 시스템이 사용중 문제가 없었다면, 12.3.5항 하에서 서비스 경험에 관해

신청자는 적은 데이터가 필요하거나 추가 데이터가 필요 없을 수 있다. 5. 일부 TSO는 명판에 DO-178[ ]과 해당 레벨을 명시하도록 요구한다. 중 변경이

RTCA DO-178B로 승인되고 소프트웨어의 대다수가 RTCA DO- 178B에 적합하

다면, 명판에는 DO-178[ ]과 해당 소프트웨어 레벨을 표시할 수 있다.6. 일단 DO-178B에 적합한 변경 절차가 소프트웨어 중 변경을 기술하기 위해 적용

되면, 그 절차는 해당 소프트웨어의 다음 모든 변경에 적용되어야 한다.

제40조(레거시 시스템의 소프트웨어 변경 승인 절차) ①인증당국은 신청자로 하여금

레거시 시스템의 소프트웨어 레벨과 제안된 장착의 소프트웨어의 동일성을 아래 “소프트웨어 레벨의 동등성”을 활용하여 입증하도록 하여야 한다. 1. “소프트웨어 레벨의 동등성”에는 동등성을 결정하기 전에 추가적인 분석이 필요할

수 있는 2개의 입력사항이 있다. 이러한 것들은 “소프트웨어 레벨의 동등성”에서는

“분석”이라고 제시된다. 추가 분석이 필요한 경우, 인증당국은 신청자와 이를 협의

하여야 한다.2. “소프트웨어 레벨의 동등성”으로 동등성을 확인할 수 없다면(즉, 표에서 “아니오”

라는 입력이면), 소프트웨어 레벨을 향상하기 위해 소프트웨어 어플리케이션 또는

파티셔닝에 RTCA DO-178B 12.1.4항의 규정을 적용하여야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 33 -

RTCA DO-178 178A에 따른 레거시 시스템

소프트웨어 레벨

장착에 필요한 RTCA DO-178B 소프트웨어 레벨

중요(critical) 레벨 1

기본(essential) 레벨 2

비기본

레벨 3

A 예/분석 아니오 아니오

B 예 아니오/분석 아니오

C 예 예 아니오

D 예 예 아니오

E 예 예 예

소프트웨어 레벨의 동등성

②레거시 시스템의 소프트웨어가 수정되지 않고 RTCA DO-178B가 요구되지 않는

동일한 항공기/엔진 또는 다른 항공기/엔진에 재장착된다면, 최초의 보증 절차와 관

련 제출 데이터는 수락될 수 있다. ③레거시 시스템의 소프트웨어가 수정되고 소프트웨어 적합성 입증방법으로 RTCA DO-178B가 적용되지 않는 동일한 항공기/엔진 또는 다른 항공기/엔진에 장착된다

면, 최신 개정판이 사용된 것을 제공하여 최소 장착의 적합성 입증방법 또는 최소

레거시 시스템의 적합성 입증방법이 사용될 수 있다. 소프트웨어 수정을 평가하고

적절한 회귀 시험을 적용하기 위해, 이 지침의 11장에서 정의된 변경영향 분석을

수행하여야 한다.④레거시 시스템의 소프트웨어가 수정되고 소프트웨어 적합성 입증방법으로 RTCA DO-178B가 적용되는 다른 항공기/엔진에 장착된다면, 제39조과 11장의 지침에 따라

경 변경인지 결정한다. 경 변경으로 결정된 변경사항은 제40조에서 논의한 변경하지

않은 경우와 동일하게 처리할 수 있다. 변경이 경 변경이라는 결정은 11장의 지침을

사용하여 인증당국의 판단에 따른다. 1. 변경이 경 변경이 아니면, 소프트웨어의 모든 변경과 그 변경에 영향을 받는 모든

구성품은 제39조에 따라 RTCA DO-178B를 사용하여 보증하여야 한다. 영향을

받는 구성품을 결정하는데 변경영향 분석이 일반적인 방법이다. 변경영향 분석에

대한 설명은 11장에 포함되어 있다. 그러나 프로젝트 계획 및 절차, 변경 활동과

그 증거는 RTCA DO-178B의 목표를 충족한다는 것을 보여야 한다. 2. 추가적으로 영향을 받으나 변경되지 않은 구성품은 내부 구조적 커버리지에 대해

평가하지 않을 수 있으나, 통합 시험을 사용하여 다른 구성품과 인터페이스를 하는

구성품에 변경이 없음을 검증하여 영향을 받는 기능에 대한 요구조건기반의 시험

커버리지뿐만 아니라 데이터 흐름 및 컨트롤 흐름 커버리지에 대한 목표는 만족하

여야 한다. ⑤레거시 시스템의 소프트웨어가 변경되지 않고 보증을 입증하는 수단으로 RTCA DO-178B가 적용된 다른 항공기/엔진(즉, 다른 형식증명)에 장착된다면, 소프트웨어에 대한 별도의 적합성 판정을 하지 않아야 한다. 시스템의


제정: 2009.07.27 개정: 2011.1.3 - 34 -

운용사용(operational use)이 상당히 다르다고 예상되지 않으면 최초의 승인이

소프트웨어 장착 승인으로 인정할 수 있다. 운용사용이 최초 또는 차후 장착 승인과

상당히 다를 때, RTCA DO-178B 지침에 대한 보증을 수행하여야 한다. 운용사용의

변경에 대한 중요성 결정은 인증당국의 판단에 따른다. ⑥레거시 시스템 소프트웨어의 모든 변경과 이러한 변경을 승인하는데 사용된 절차

는 특정 프로젝트에 맞게 PSAC, SCI, SAS 등에 문서화 되어야 한다. 레거시 시스템

에 대한 운용 이력을 주장하려면, 이러한 데이터가 마찬가지로 SAS에 요약되어야

한다.⑦ 향후에 변경이 제안된 경우, 이 장에서 규정된 기준을 사용하여 언급되어야 한다.

제11장 소프트웨어 변경영향분석

제41조(변경영향분석) ①인증당국은 신청자가 제품에 통합될 소프트웨어 변경을 식별

하고, 변경영향 분석을 수행하도록 하여야 한다. 변경영향 분석은 항공기의 계속적인

운용 안전에 대한 변경의 잠재적 영향을 결정하기 위해 규정된 절차를 따라야 한다. TSO 형식승인 장비에 대해, 분석에서 분석에 대한 기초를 형성하는 의도된 타깃

항공기 환경을 식별하여야 한다. 이 분석은 또한 인증당국의 관여정도를 결정하

기 위한 기준을 제공한다. 변경영향 분석에서 다음 사항을 적절하게 언급하여야

한다.1. 추적성 분석은 소프트웨어 변경으로 영향을 받을 수 있는 분야를 식별한다.

여기에는 아래에서 기술하는 것과 같이 영향을 받는 요구조건, 설계, 아키텍처, 코드, 시험, 분석 등이 포함된다.가. 요구조건 및 설계 분석은 변경으로 영향을 받는 소프트웨어 요구조건,

소프트웨어 아키텍처, 안전관련 소프트웨어 요구조건을 식별한다. 추가적으로, 분석으로 시스템에서 실행되는 추가적인 특성/ 기능을

식별하고, 추가 기능이 적절하게 검증되었음을 보증하며, 추가 기능이 기존

기능에 악영향을 주지 않음을 보증한다.나. 코드 분석은 변경에 영향을 받는 소프트웨어 구성품과 인터페이스를 식별한다.다. 시험 절차 및 케이스 분석은 변경을 검증하기 위해 재실행될 필요가 있는

특정 시험 절차와 케이스를 식별하고, 추가 기능이나 이전에 불충분한 시험에

대해 새롭거나 수정된 시험 절차와 케이스를 식별하여 개발하며, 변경의

결과로 악영향이 없음을 보증한다. 악영향이 없음은 변경되는 소프트웨어의

소프트웨어 레벨에 적정하게 적절한 계층 수준(항공기 비행시험, 항공기

지상시험, 실험실 시스템 통합시험, 시뮬레이터 시험, 벤치 시험, 하드웨어

소프트웨어 통합시험, 소프트웨어 통합시험, 모듈 시험 등)에서 회귀 시험을

수행하여 검증할 수 있다.2. 메모리 여유 분석은 메모리 할당 요구조건 및 수락 가능한 여유가 유지되는지를


제정: 2009.07.27 개정: 2011.1.3 - 35 -

보증한다.3. 타이밍 여유 분석은 타이밍 요구조건, CPU 작업 스케줄링 요구조건, 시스템 자원

경쟁 특성, 인터페이스 타이밍 요구조건, 수락 가능한 타이밍 여유가 유지되는지를

보증한다.4. 데이터 흐름 분석은 데이터 흐름의 변경, 구성품간의 연동을 식별하고, 악영향이

없음을 보증한다.5. 컨트롤 흐름 분석은 컨트롤 흐름의 변경, 구성품간의 연동을 식별하고, 악영향이

없음을 보증한다.6. 입출력 분석은 변경이 제품의 입출력(버스 로딩, 메모리 접근, 하드웨어 입출력

디바이스 인터페이스 등을 포함) 요구조건에 악영향을 주지 않는다는 것을 보증한

다.7. 개발 환경 및 절차 분석은 소프트웨어 적용 또는 제품에 악영향을 줄 수 있는

변경(예를 들어, 컴파일러 옵션 또는 버전 및 최적화 변경, 링커, 어셈블러, 로더

지침 또는 옵션 변경, 소프트웨어 툴 변경)을 식별한다.8. 운용 특성 분석은 변경(이득, 필터, 한계, 데이터 확인, 인터럽트 및 예외 처리,

결함 완화 등에 대한 변경)이 악영향을 유발하지 않음을 평가한다.9. 인증 유지보수 요구조건(Certification Maintenance Requirement, CMR) 분석은

소프트웨어 변경으로 인한 새로운 또는 수정된 CMR이 필요한지를 결정한다.10. 파티셔닝 분석은 변경이 설계에 통합된 보호 메커니즘에 영향을 주지 않음을

보장한다.11. 기타

②변경영향 분석은 변경이 시스템 또는 제품의 안전 운용에 악영향을 줄 수 있는지를

판단하여야 한다. 다음은 안전성 또는 운용에 악영향을 줄 수 있는 영역이다. 1. 안전 관련 정보가 변경된다.

가. 시스템 안전성 평가에 의해 식별된 이전의 위험요소가 변경된다.나. 시스템 안전성 평가에 의해 식별된 고장조건 분류가 변경된다.다. 소프트웨어 레벨이 변경된다. 특히 새로운 소프트웨어 레벨이 이전 레벨보다

높은 경우.라. 시스템 안전성 평가에 의해 식별된 안전 관련 요구조건이 변경된다.마. 안전 여유가 감소한다.

2. 비행 안전에 악영향을 줄 수 있는 항공기의 운용 또는 절차적 특성의 변경

가. 항공기의 운용 또는 감항 특성이 변경된다.나. 비행 승무원의 절차가 변경된다.다. 조종사의 작업부하가 증가한다. 라. 상황 인식, 경고, 경보가 변경된다.마. 비행 의사결정을 하는 시현 정보가 변경된다.바. 조립 및 장착 요구조건이 변경된다.사. 다른 장비와의 장비 호환성 및/또는 상호운용성이 변경된다.


제정: 2009.07.27 개정: 2011.1.3 - 36 -

아. CMR이 변경되거나 추가된다.3. 비행 안전에 악영향을 줄 수 있는 기존 시스템 기능에 새로운 기능 또는 특성이

추가된다.4. 안전성에 악영향을 줄 수 있는 쪽으로 프로세서, 인터페이스, 기타 하드웨어 구성

품 또는 환경이 변경된다.(RTCA DO- 178B의 12.1.3항 참조)5. 안전성에 악영향을 줄 수 있는 쪽으로 소프트웨어 라이프사이클 데이터(요구조건,

코드, 아키텍처)가 상당하게 변경된다. 가. 소프트웨어 요구조건, 설계, 아키텍처, 코드 구성품에 대한 변경 (특히 안전관

련 기능, 파티셔닝, 중복, 안전성 모니터 등에 영향을 주는 구성품)나. 안전관련 기능을 수행하는 코드(소스 코드, 목적 코드, 실행가능 목적 코드)

구성품에 대한 변경 또는 안전관련 기능을 수행하는 구성품에 입력을 제공하

는 구성품의 변경(이 지침에서는 안전관련 기능이 탐지되지 않고 잠재적으로

중, 위험, 치명 고장조건을 유발할 수 있는 기능을 말한다.)다. 실행가능 목적 코드에 영향을 주는 개발 환경 특성의 변경

라. 메모리 여유에 악영향을 주는 메모리 할당 요구조건의 변경(예를 들어, 5% 이하의 여유가 남을 것)

마. 타이밍 여유에 악영향을 주는 타이밍 요구조건의 변경(예를 들어, 여유가 예측

불가하거나 10% 이하의 여유가 남을 것)바. 입․출력 성능에 악영향을 주는 입․출력 요구조건(버스 부하와 같은)의 변경

(예를 들어, 5% 이하의 여유가 남을 것)사. 데이터 및 컨트롤 흐름 특성에 악영향을 주는 데이터 및 컨트롤 흐름 특성의

변경(예를 들어, 커버리지 분석의 50%이상이 재수행되어야 하는 정도까지)아. 인터페이스 특성의 변경

③추가적으로, 다음 사항이 변경영향 분석에서 식별되어야 한다.1. 소프트웨어 변경이 요구조건, 설계, 아키텍처, 소스 및 목적 코드, 추적성 등을

포함하여 적절한 라이프사이클 데이터에 통합된다는 것을 보증하기 위해 필요한

갱신사항

2. 변경사항과 시스템에 악영향이 없음을 검증하는데 필요한 검증 활동. 변경 및

비변경된 소프트웨어가 안전 운용에 대한 요구조건을 계속적으로 만족하기 위해

변경영향 분석에서 시스템 또는 항공기의 안전 운항에 악영향을 줄 수 있는 변경

이 어떻게 검증되는지를 다루어야 한다. 이러한 검증활동에는 기존 분석의 재분

석, 기존 시험의 재시행, 새로운 시험 절차와 케이스(추가 기능 도는 이전에 결함이

있던 시험에 대한) 등을 포함하여 검토, 분석, 회귀시험, 요구조건기반의 시험, 비행시험, 기타 등이 포함될 수 있다.

제42조(변경영향분석 절차) ①인증당국은 신청자가 소프트웨어 변경을 중 또는 경으

로 분류하는 절차를 정의하여 따르도록 하고, 이러한 절차에 대해 검토, 피드백 및

승인하여야 한다. 최소한, 이러한 절차는 이행되기 전에 다음 사항을 언급하여야


제정: 2009.07.27 개정: 2011.1.3 - 37 -

한다.1. 경 또는 중의 변경 분류를 정당화하기 위해 변경영향 분석을 사용하는 신청자의

절차 및 사용자가 변경을 분류하는데 사용하는 기준

가. 변경영향 분석의 광범위성과 형식성은 변경의 복잡성, 치명도, 광범위성에

따라 다양하다. 나. 신청자의 문서에는 변경 분류에 대한 인증당국의 합의를 획득하기 위해 해당

규정(예를 들어, KAR § 21.93, 21.115, 21.611)에 따른 경 또는 중 변경의

분류가 명시되어야 한다.2. 변경 분류를 검토하고 승인하는 신청자의 절차

3. 경 변경 결정에 후속되는 절차

4. 중 변경 결정에 후속되는 절차

5. 제안된 모든 소프트웨어 변경과 분류를 인증당국에게 통보하는 절차

6. 제안된 분류에 대한 인증당국 승인을 획득하는 절차. 인증당국이 소프트웨어 변경

분류 절차를 승인한 후에는 신청자가 제안된 모든 소프트웨어 변경에 대해 그

절차를 따르도록 한다. 승인된 절차와의 차이는 인증당국의 동의가 필요하다.②인증당국은 신청자가 인증당국이 승인한 소프트웨어 변경 분류 절차를 갖고 있지

않는 경우, 신청자로 하여금 소프트웨어 변경이 계획된 경우 인증당국에게 이에 관한

정보를 제공하도록 하여야 한다. 이러한 경우, 신청자로 하여금 다음 활동을 수행하

도록 하여야 한다. 1. 이 장의 제41조를 사용하여 변경영향 분석을 수행한다. 2. 이 장의 제41조에서 언급한 변경영향 분석과 안전성 영향에 기반하여 변경에 대한

중 또는 경 분류를 제안하고, 분류에 대한 인증당국의 피드백과 동의를 구한다.3. 안전성 영향의 부재 및/또는 변경의 제한된 범위에 대한 근거와 변경을 검증하는

방법으로 제안된 경 분류를 지원한다. 인증당국이 신청자의 데이터와 근거자료에

동의한 이후, 신청자는 더 이상의 인증당국의 감독 없이 경 변경에 대해서 진행할

수 있다.4. 중 변경에 대해서는 적절한 문서를 인증당국에 제출한다.③경 변경의 경우, 개발 절차에 대한 인증당국 감독은 관련 규정에 대한 중/경 결정을

하는 것에 관한 신청자의 변경영향 분석 절차 및 관련 기준의 승인과 주기적 검토가

관여되어야 한다. 일단 변경 전략과 변경 그 자체가 수행되었으면, 전략과 변경영향

분석은 SAS에 문서화되어야 한다. 새롭고, 변경되었으며, 재사용한 소프트웨어 라

이프사이클 데이터 또한 SCI에서 식별되어야 한다. 경 변경의 경우, 관할 인증당국에

SAS와 SCI를 제출하는 것은 인증당국과의 협의에 따르도록 하여야 한다.1. 해당하는 경우, 인증당국은 변경 분류 절차와 회사의 절차 준수를 감독하는 것에

관여하여야 한다.2. 제작사가 경으로 분류하고 아직 인증당국이 수락하지 않은 변경을 포함하는 장비

는 인증당국이 그 분류를 수락할 때까지 비행 항공기에 장착해서는 안 된다.④중 변경의 경우, 인증당국은 신청자의 PSAC 또는 변경영향 분석 데이터의 요약


제정: 2009.07.27 개정: 2011.1.3 - 38 -

및 변경 문제를 처리하기 위해 제안된 전략을 검토하여야 한다. 일단 변경 전략과

변경 그 자체가 완료되었으면, 인증당국은 전략과 변경영향 분석 결과가 SAS에 문서

화되는 것을 보증하여야 한다. 또한 새롭고, 수정되었으며, 재사용하는 소프트웨어

라이프사이클 데이터는 SCI에 식별되어야 하고, 인증당국(중 변경을 승인하는 권한

을 갖은 경우)에 제출하도록 하여야 한다.

제12장 소프트웨어 라이프사이클 데이터 재사용의 승인

제43조(재사용에 적합한 소프트웨어) ①적절하게 계획되고 준비되었다면, 소프트웨어

라이프사이클 데이터는 한 프로젝트에서 다음 프로젝트로 최소의 재작업을 통해

재사용될 수 있다. 재사용에 적합한 예시 아이템은 다음과 같은 것들이 포함된다.1. 소프트웨어 계획과 표준

2. 툴 검정 데이터

3. 소프트웨어 라이브러리

4. 소프트웨어 요구조건, 설계, 코드, 검증 절차, 검증 결과

5. 형상 항목

②RTCA DO-178B를 사용하지 않은 프로젝트는 이 장에서 기록되지 않은 추가적인

고려사항이 있을 수 있다. 인증당국은 사례별로 추가적인 고려사항들을 평가하여야

하며 신청자가 지침을 위해 지역 인증당국과 연락을 취하도록 하여야 한다. 인증당국

은 항공기 컴퓨터 소프트웨어의 인증당국, 해당분야 전문가 등 필요한 조직과 조율하

여야 한다.

제44조(안전성 고려사항) 인증당국이 소프트웨어 라이프사이클 데이터의 재사용이 수

락 가능하다고 판정하면, 더 이상의 설계 승인이 필요하지 않다. “재사용 승인 고려

사항”에서 인증당국이 소프트웨어 재사용을 승인할지를 좌우하는 고려사항을 설명

한다.

다음과 같으면 인증당국은 재사

용을 승인.

1. 최초의 시스템 안전성 여유에 악영향을 주지

않는다.

2. 안전성이 정당한 증가로 구현한 경우 외에

최초의 운용성능에 악영향을 주지 않는다.

재사용이 다음과 같으면 인증당

국은 재사용을 승인하지 않음.

1. 안전성에 악영향을 준다.

2. 이전 승인된 데이터 또는 파라미터의 범위를

초과한다.

3. 장비 성능 특성을 초과한다.

재사용 승인 고려사항


제정: 2009.07.27 개정: 2011.1.3 - 39 -

제45조(재사용에 영향을 주는 인자) ①RTCA DO-178B 11항의 어떠한 소프트웨어

라이프사이클 데이터도 재사용에 적절하다. 제46조의 지침을 만족하기 위해, 소프트

웨어 라이프사이클 데이터는 변경되지 않아야 하고, 재사용을 고려하는 프로젝트에

적용되어야 한다.②이전 어플리케이션에서의 운용중 문제는 재사용을 제한할 수 있다. 새로운 소프트

웨어의 재사용 가능한 부분이 영향을 받는다면, 소프트웨어 라이프사이클 데이트를

수정할 변경이 이뤄져야 하거나 소프트웨어를 사용하지 않아야 한다.③인증당국은 신청자로 하여금 운용 환경과 소프트웨어 개발 환경 모두의 유사성을

평가하여 다음 프로젝트의 개발에 소프트웨어 데이터를 적용할 것인지를 결정하도록

하여야 한다. 이때 신청자가 다음 사항을 수행하도록 한다.1. 철저한 성능 요구조건과 운용 안전성 평가를 검토하여 운용 환경을 평가한다.2. 소프트웨어 개발 환경을 평가할 때 RCTA DO-178B 11.15항의 소프트웨어 라이프

사이클 환경 형상 색인을 참조한다.3. 운용 및 개발 환경이 동일하다는 것을 증명하거나, 이전 인증과 동일한 결과를

산출한다는 것을 입증한다.4. 미해결의 주요사안검토서를 평가한다.

제46조(재사용 승인) ①인증당국은 신청자가 재사용된 소프트웨어 라이프사이클 데이

터에 대한 인증 신인도를 얻기 전에 다음 지침을 만족하는지를 보증하여야 한다.1. 이전 승인 이후로 소프트웨어 라이프사이클 데이터가 변경되지 않았다.2. 어플리케이션의 소프트웨어 레벨이 최초 인증의 소프트웨어 레벨과 같거나 그

이하이다.3. 형상 품목으로의 입력 범위와 데이터 유형이 승인된 이전 승인과 동일하다. 4. 형상 품목이 동일한 타깃 컴퓨터에 탑재되고, 기능적으로 최초 인증 프로젝트와

동일하게 사용된다.5. 최초의 인증 프로젝트에서처럼 같은 타깃 컴퓨터 및 시스템에서 동일한 소프트웨

어/하드웨어 통합 시험 및 시스템 시험을 수행한다.6. 신청자는 제44조 및 제45조에 있는 안전성 고려사항과 재사용 인자를 따른다.7. 소프트웨어 라이프사이클 데이터 및 개별 아이템의 재사용에 대한 근거를

PSAC의 “추가 고려사항”에 문서화 한다. 신청자의 PSAC에는 재사용되는 형상

항목의 사용, 통합, 문서화의 방법을 포함하여야 한다. 개발 프로그램에서 가능한

빨리 PSAC을 제출하여야 한다. 또한 신청자는 PSAC에 이전에 승인된

프로젝트의 모든 참고자료와 프로젝트 번호(해당하는 경우)를 문서화 하여야

한다.②차기 인증을 담당하는 인증당국은 PSAC을 검토하여 신청자에게 제안서가 수락가

능한지 여부를 적절한 근거와 함께 통지하여야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 40 -

제13장 공급업체 관리 등

제47조(공급업체 감독) ①TC/STC/TSOA 신청자가 시스템 및 소프트웨어를 개발, 검증, 인증활동에 공급업체 또는 하부 공급업체를 활용하는 경우에는 이 조항을 적용한

다.②신청자는 공급업체 또는 하부 공급업체가 인증 프로그램에 적용되는 규정, 정책, 지침서, 표준 등에 부합하도록 감독 계획 및 절차를 수립하여야 한다. 다음은 적용되

는 문서의 예시이나, 이것만으로 한정하지는 않는다.1. 감항기술기준

2. 국토해양부 고시 및 훈령

3. 시스템, 하드웨어, 소프트웨어 개발에 적용되는 신청자의 표준(요구조건 표준, 설계 표준, 코딩 표준 포함)

4. 신청자의 품질보증 계획, 절차, 프로세스

5. 신청자의 형상관리 계획, 절차, 프로세스

6. 시스템 공급업체의 표준, 계획, 절차, 프로세스

7. 소프트웨어 변경영향 분석에 대한 신청자의 프로세스

③신청자의 인증계획서 또는 소프트웨어인증계획서(PSAC)에서 신청자가 공급업체

또는 하부 공급업체의 활동을 어떻게 감독할지를 기술하여야 한다. 여기에는 상용

소프트웨어 구성품의 공급업체도 포함한다. 신청자는 프로그램 초기에 이러한 계획

을 인증당국에 제출하여 승인받아야 한다. 계획을 변경하는 경우, 신청자는 인증당국

에게 검토할 시간을 주어야 한다. ④신청자는 공급업체 관리 계획 또는 다른 적절한 계획 문서에서 다음 사항을 기술하

여야 한다. 인증당국은 이러한 사항들이 계획서에 설명되어 있는지 검토한다.1. 규정, 정책, 계획, 표준 등에 대한 적합성: 신청자는 계획서에서 모든 적용 문서가

공급업체 또는 하부 공급업체에 전달, 조율, 합의되는 방법을 제시하여야 한다.2. 통합성 관리: 신청자는 계획서에서 시스템 구성품의 통합 방법과 소프트웨어 및

통합 시스템의 확인 및 검증 책임자가 누구인지 기술하여야 한다. 가. 요구조건의 구현, 관리, 확인 방법(안전성 요구조건, 파생 요구조건, 요구조건

변경 포함)나. 설계 통제 및 승인 방법

다. 통합 시험 환경의 관리 방법

라. 소프트웨어 빌드 및 배포 프로세스의 관리 방법(신청자와 공급업체의 배포

전략 차이점은 일치시킨다)마. 인증 요구조건을 보조하는 제품보증 활동의 대상 및 그 이행자

바. 시스템 통합 및 검증에 대한 신청자의 전략(요구조건-기반 시험 및 구조적

커버리지 분석 포함)3. 문제 보고 및 해결: 계획서에는 문제 보고서를 추적하는 시스템을 구축하여야

한다. 여기에는 신청자와 공급업체 간에 문제를 보고하는 방법이 설명되어야 한


제정: 2009.07.27 개정: 2011.1.3 - 41 -

다. 문제 보고 시스템은 문제가 해결되고, 그 보고서와 변경사항이 형상관리 시스

템에 기록되도록 보증하여야 한다. 4. 통합 검증 활동: 계획서에서 공급업체가 적용 문서에 적합하도록 검증활동을 수행

하는지 통합 검증 활동의 책임자가 누구인지 식별하여야 한다.5. 형상 관리: 계획서에서 모든 소프트웨어 라이프사이클 데이터의 형상관리를 돕는

절차와 툴을 기술하여야 한다. 공급업체와 형상관리가 어떻게 유지되는지도 기술

하여야 한다.6. 적합성 입증 및 자료 보관: 계획서에는 공급업체가 적합성을 입증하고 자료를

보관하는 것을 신청자가 확인하는 방법을 기술하여야 한다. 계획서에는 최소한

다음 인증 자료가 설명되어야 한다.가. 적합성이 입증되었다는 증거

나. 검증 및 확인 자료

다. 소프트웨어 라이프사이클 데이터

⑤신청자의 공급업체 관리 계획(또는 그와 동등한 계획)에서는 신청자의 프로세스와

공급업체의 프로세스 사이에 라이프사이클 데이터의 이관에 대해 기술하여야 하고, 요구조건 관리, 문제 보고, 표준 사용, 변경 영향, 검토 등을 포함하여 모든 프로세스

에서의 확인 및 검증에 대해 설명하여야 한다.⑥계획서에서 인증 자료는 한국의 시설에 보관되거나 인증당국이 접근할 수 있음을

명확히 언급하여야 한다. 혼동을 피하기 위해, 인증자료는 한국어(또는 영어)로 작성

되도록 한다.

제48조(소프트웨어 문제 보고) ①소프트웨어를 포함하는 항공기 시스템의 개발 과정에

서 탐지되는 문제를 관리하는 책임이 TC/STC/TSOA 신청자의 공급업체 또는 하부

공급업체에 있을 경우 이 조항을 적용한다.②소프트웨어 문제 관련하여 일관되게 보고/해결하기 위해, 신청자는 소프트웨어

형상관리 계획서 또는 동등 문서에서 공급업체 또는 하부 공급업체의 문제 보고

프로세스를 어떻게 감독할 것인지 기술하여야 한다. 다음 사항이 언급되어 있는지

확인하여야 한다.1. 문제가 보고, 평가, 해결, 실행, 재검증(회귀 시험 및 분석), 종결, 관리됨을 보증하

는 신청자의 공급업체 또는 하부 공급업체의 문제 보고 프로세스를 기술하여야

한다. 계획에서는 시스템에서 사용하는 소프트웨어, 데이터베이스, 데이터 항목, 전자 파일 및 항공기에 장착하는 장비에 관련한 모든 문제를 고려하여야 한다.

2. 계획서에서는 문제 보고서를 분류하는 방법을 수립하고, 각 문제 보고서는 이에

따라 분류하여야 한다.가. 안전성에 대한 잠재적 영향, 기능, 성능, 운용, 설계 보증 등을 가지고 문제를

분류한다.나. 인증 전에 해결할 것과 인증 이후로 연기할 수 있는 문제로 분류

다. 문제 해결 유예를 수락할 수 있는 기준을 정의하여야 한다.


제정: 2009.07.27 개정: 2011.1.3 - 42 -

3. 계획서에서는 안전성, 성능, 기능 및 운용 특성, 소프트웨어 보증, 적합성 등에

영향을 줄 수 있는 문제에 대해 신청자의 공급업체 또는 하부 공급업체가 신청자

에게 보고하는 방식을 기술하여야 한다. 가. 신청자는 자체의 문제 보고 및 추적 시스템에 문제를 등록할 수 있다. 이런

경우, 달성되는 방법을 계획서에 기술하여야 한다. 공급업체의 문제보고 시스

템이 신청자의 시스템과 호환되지 않는 경우, 문제보고 시스템 사이의 전환을

검증하는 프로세스를 계획서에 기술한다.나. 신청자는 자체의 문제 보고 시스템에 공급업체 또는 하부 공급업체가 접근하

도록 할 수 있다. 이렇게 하는 경우, 신청자는 공급업체 또는 하부 공급업체의

문제 보고서를 적절하게 접수/관리한다는 보증에 도움이 된다. 신청자가 이를

허용하는 경우, 적절한 형상관리 유지를 위해 접근을 제한하고, 문제보고 시

스템의 적절한 사용을 위해 공급업체를 교육하여야 한다.다. 계획서에 신청자의 문제보고 시스템에 등록되기 전에 신청자의 공급업체 또

는 하부 공급업체가 후속조치 기록 또는 신청자의 검토 및 승인을 위해 사용할

툴을 명시하여야 한다.라. 계획서에 신청자가 모든 문제를 파악할 수 있도록 공급업체는 하나의 문제보

고 시스템만을 보유하도록 명시하여야 한다. 마. 다른 적용에 영향을 주거나 또는 시스템 전반에 영향을 줄 수 있는 문제는

적절한 분야로 표시하여야 한다.4. 계획서에서는 개별 공급업체 또는 하부 공급업체의 문제해결 프로세스에 대한

검토에 비행 시험, 인적 요소, 시스템, 소프트웨어, 기타 엔지니어가 참여하는 방식

을 기술하여야 한다. 또한, 담당 엔지니어가 문제보고서 검토 위원회 및 변경통제

위원회에 참여하는 방식을 설명하여야 한다.5. 계획서에서는 신청자가 인증 이후로 연기하도록 제안하는 미해결 문제보고서의

수락을 결정하는데 사용하는 문제보고서 검토 위원회 및 변경통제 위원회의 기준

을 수립하여야 한다. 가. 위원회에서는 안전, 기능, 운용에 대한 미해결 문제보고서의 잠재적 영향을

고려하여야 한다.나. 다수의 미해결 문제보고서는 소프트웨어가 완전히 성숙되지 못하고 그 보증

에 의문이 있다는 것을 나타내기 때문에, 신청자는 형식증명 이후까지 연기될

수 있는 문제보고서에 대해 상한 또는 예정일을 수립하는 프로세스를 설명하

여야 한다.다. 계획서에서는 인증 이후로 연기될 수 있는 미해결 문제보고서를 해결하는

시한 결정 방법을 수립하여야 한다. 이러한 방법은 신청자, 공급업체, 하부

공급업체에 의해 생성된 문제보고서에 적용한다.③인증 담당자는 TIA 및 인증 전에 미해결 문제보고서에 관련된 의사결정에 참여하

여야 한다. 인증 담당자는 다음과 같은 일을 수행한다.1. 인증 이후로 연기하고자 제안하는 문제 보고서를 검토한다. 이러한 검토에는 비행


제정: 2009.07.27 개정: 2011.1.3 - 43 -

시험, 시스템, 기타 전문가가 필요할 수 있다. 안전에 영향이 있다고 우려된다면, 특정 문제보고서의 연기를 불허할 수 있다.

2. 신청자가 이전개발소프트웨어(PDS, Previously Developed Software)를 사용한다

면, 신청자가 인증된 항공기 또는 시스템의 기준선에 대한 잠재적 영향성에 대해

미해결 문제보고서를 재평가하였는지 확인한다.3. 신청자가 다중 미해결 문제보고서의 상호 연관성을 고려하여 다른 관련 문제보고

서와 연계하여 고려했을 때보다 문제보고서가 더 치명적인지 평가하였음을 확인

한다. 4. 신청자가 AD, SB, 운용 제한 및 다른 필수 시정조치와 관련된 미해결 문제보고서

를 검토하였는지 확인한다.5. 인증당국 비행조종사가 시험 비행에 참여하기 전에, 운용 제한 및 절차가 필요한지

결정하기 위해 잠재적 안전성 또는 운용 영향과 함께 미해결 문제보고서를 검토한

다.6. 신청자가 DO-178B 11.20(j)항에 적합함을 확인한다.

제49조(항공용 시스템 데이터베이스 및 항공 데이터베이스의 확인) ①신청자의 항공용

시스템 또는 장비가 항공 데이터베이스 또는 항공용 시스템 데이터베이스를 활용하

는 경우 이 조항을 적용한다.1. 항공 데이터베이스: 항공용 시스템에 사용되는 것으로, 일반적으로 개발 프로세스

는 RTCA DO-200A(standards for processing aeronautical data), FAA AC 20-153(acceptance of data processes and associated navigation databases), FAA order 8110.55(how to evaluate and accept process for aeronautical database supplier)의 지침을 사용하여 승인된다.

2. 항공용 시스템 데이터베이스: 항공용 시스템에 사용되는 것으로, 항공기 또는 엔진

형식설계의 일부로 승인된다. 이러한 데이터베이스는 실행코드에 의해 실행되어

경로에 영향을 줄 수 있고, 소프트웨어 구성품 및 기능을 활성 또는 비활성화

하는데 사용될 수 있고, 항공기 형상에 따라 소프트웨어 계산을 조절할 수 있으며, 계산 데이터로 사용될 수 있다. 이러한 데이터베이스의 보증은 통상 RTCA DO-178B 항공용 시스템 및 장비 소프트웨어 프로세스의 환경에서 획득된다.

②신청자 및 항공용 시스템 공급업자는 항공 데이터베이스가 해당 규정 및 인증당국

지짐에 적합하다는 것을 보증하기 위해 다음 사항을 확인하여야 한다. 1. FAA AC 20-153 10절 또는 RTCA DO-200A의 요구조건에 적합한 항공 데이터베

이스에 대한 수락 가능한 방법에서 제공하는 지침을 따르는지 확인한다. 현재

유형 2의 LOA(Letter of Acceptance)는 항공 데이터베이스가 장착 적격성과 사용

운용 승인의 도움으로 DO-200A에 적합하다는 증빙을 제공한다. 2. 항공 데이터베이스가 RTCA DO-200A(부록 B), FAA AC 20-153, 기타 수락 가능한

방법(FAA order 8110.55 참조)을 사용하여 해당 보증 수준의 요구조건을 만족하

는지 확인한다.


제정: 2009.07.27 개정: 2011.1.3 - 44 -

③신청자 및 항공용 시스템 공급업자는 항공용 시스템 데이터베이스가 해당 규정

및 인증당국 지짐에 적합하다는 것을 보증하기 위해 다음 사항을 확인하여야 한다. 1. 신청자의 항공기 및 시스템 안전성 평가를 검토하여, 개별 항공용 시스템 데이터베

이스에 대해 다음 사항을 검증한다.가. 데이터베이스를 사용하는 개별 시스템에 대해 데이터베이스 오류 및 훼손

가능성이 고려됨

나. 각 데이터베이스에 대해 적절한 소프트웨어 레벨이 할당됨

다. 시스템 및 항공기 또는 엔진에 대해 오류 또는 훼손이 야기할 수 있는 최악의

잠재적 위험요소에 대해 할당된 소프트웨어 수준에 기초하였음. 라. 식별된 위험요소와 할당된 소프트웨어 레벨이 인증당국과 협의됨.

2. 개별 데이터베이스는 DO-178B 또는 다른 수락 가능한 방법을 사용하여 해당

소프트웨어 레벨에 맞게 보증되고, 기능 소프트웨어, 시스템, 전체 항공기 환경에

서 다음 사항을 검증하여 확인한다.가. 데이터베이스 소프트웨어 레벨에 적절한 검증 커버리지 수준이 달성됨. 이러

한 것은 요구조건-기반 시험, 데이터만 제공하는 데이터 아이템의 데이터 커

플링 분석, 소프트웨어 실행에 영향을 받는 데이터 아이템에 대한 제어 커플

링 분석 등의 조합으로 달성할 수 있다.나. 각 데이터베이스에 대한 신청자의 제안 검증 커버리지 기준을 검토하여 인증

당국이 동의함(동의하지 않으면 근거자료를 제공함).다. 소프트웨어 실행 영향 등을 포함하여, 데이터베이스에 대한 강건 시험 조건을

적용하였음을 확인함.④항공 및 항공용 시스템 데이터베이스에 대해 다음과 같은 조치를 적용한다. 1. 개별 데이터베이스에 대해 현장 로딩 가능한 소프트웨어의 로딩 절차를 검토한다.

데이터베이스 전송 및 매체 오류, 로딩 및 내용 오류, 데이터베이스 부품번호와

항공기 시스템 또는 탑재 소프트웨어 사이의 오류, 사용 중 데이터베이스 내용

또는 메모리의 훼손 등을 탐지하는 안전장치를 확인한다. 2. 규정된 시간 이내에서 사용하는 것만이 데이터베이스의 내용이 유효하다면, 데이

터베이스 갱신을 위해 유지보수 지침 및 적절한 제한사항을 제공함을 확인한다.3. 신청자가 각 데이터베이스 갱신에 대한 프로세스를 제공하는지 확인한다. 프로세

스에는 STC, 경미한 변경(개조 수준 변경), 시스템 부품번호 변경, 소프트웨어

부품번호 변경 등과 같은 감항성 승인 및/또는 사용 허가를 획득하는 방법이 포함

되어야 한다. 이 프로세스에는 할당된 자체 부품번호를 갖는 데이터베이스를 언급

하여야 하고, 데이터베이스는 작동 소프트웨어의 일부로 간주됨도 설명하여야

한다.

제50조(소프트웨어 개발 및 검증 환경 관리) ①신청자가 타깃 컴퓨터를 완전하게 대표

하지 못할 수 있는 소프트웨어 개발 및 검증 환경을 사용하는 경우 이 조항을 적용한

다. 신청자는 소프트웨어 개발 및 검증 환경의 형상관리를 수립하여 유지하고, 그


제정: 2009.07.27 개정: 2011.1.3 - 45 -

환경에서 구조화된 문제보고 시스템을 구현하는 것을 확인한다.②신청자는 다음 사항을 소프트웨어검증계획서 및 소프트웨어형상관리계획서에 설

명하여야 한다. 신청자는 이러한 사항을 모든 참여 공급업체에 전달하여, 이에 적합

하도록 보증하여야 한다. 1. 소프트웨어검증계획서에는 다음 사항이 포함되어야 한다.

가. 소프트웨어 개발 및 검증 환경에 대한 설명 및 개발/검증 환경과 항공기에

장착될 시스템 하드웨어/소프트웨어의 양산 버전과의 차이점 설명

나. 시스템 소프트웨어 공급업체의 소프트웨어 개발 및 검증 환경 사용 방법과

적합성 입증에 사용될 DO-178B 목표에 대한 설명

다. 소프트웨어 실행코드의 검증에 관련된 DO-178B에 대한 적합성을 보이는데

소프트웨어 개발 및 검증 환경의 사용방법에 대한 설명. 여기서는 개별 기능

소프트웨어 구성품에 대한 것이 아닌 전체 실행 코드에 대해 기술하여야 한

다. 통합 환경에서 개발 툴이 사용된다면, 검증도 통합 환경에서 수행되어야

한다.라. 완료된 검증 활동 분석 및 소프트웨어 개발 및 검증 환경의 변경 이후 이러한

활동의 반복 필요성 평가에 대한 프로세스. 이러한 프로세스는 영향을 받는

모든 검증 활동이 반복됨을 보증하거나, 재시험의 불필요성을 제시하는 문서

화된 분석이 수행됨을 보증하여야 한다.2. 소프트웨어형상관리계획서에는 다음 사항이 포함되어야 한다.

가. 소프트웨어 개발 및 검증 환경에 사용할 형상관리 시스템에 대한 설명. 계획서

에는 이러한 시스템을 관리할 담당자를 식별하여야 한다.나. 소프트웨어 개발 및 검증 환경에서 모든 사용자에게 가용한 문제 보고 및

평가 시스템


제정: 2009.07.27 개정: 2011.1.3 - 46 -

[별지1]참여도의 결정 관련 세부 기준

기준 척도 최소 최대 점수

1. 신청자 개발자의 소프트웨어 인증 경험

1.1 민간 항공기 또는 엔진 인증 경험척도: 프로젝트 수

00

53-5

106+

1.2 RTCA DO-178B의 경험 척도: 프로젝트 수

00

52-4

105+

1.3 RTCA DO-178 또는 178A의 경험 척도: 프로젝트 수

00

34-6

57+

1.4 다른 소프트웨어 표준에 대한 경험(RTCA DO-178[ ] 이외)

척도: 프로젝트 수

00

24-6

47+

2. 신청자 개발자의 실증된 소프트웨어 개발 역량

2.1 RTCA DO-178B 소프트웨어 제품을 일관되게 생성할 수 있는 능력

척도: 능력

0하

5중

10상

2.2 협동, 개방, 자원에 대한 공약척도: 능력

0하

5중

10상

2.3 소프트웨어 개발 및 공급업체 관리 능력척도: 능력

0하

5중

10상

2.4 역량 평가(예: SEI의 CMM, ISO9001-3) 척도: 능력

0하

2중

4상

2.5 S/W 개발경험에 기초한 개발팀 평균 척도: 능력

0<2년

52-4년

10>4년

3. 신청자 개발자의 소프트웨어 서비스 이력

3.1 소프트웨어와 관련된 사고(영향을 받는 제품의 백분율)

척도: 사고

0>25%

5>10%

10없음

3.2 회사의 관리에 대한 DER의 지원 척도: 품질

0하

5중

10상

3.3 회사의 소프트웨어 품질보증 조직 및 형상관리 절차

척도: 품질

0하

5중

10상

3.4 회사 안정성 및 안전에 대한 공약척도: 안정성

0하

3중

6상

3.5 과거의 회사 인증에 대한 성공여부 척도: 성공

0없음

3>50%

6전체

4. 현재 시스템 및 소프트웨어 어플리케이션

4.1 시스템 아키텍처 기능 인터페이스의 복잡성 척도: 복잡도

0상

5중

10하

4.2 S/W 및 안전성 특성의 복잡성과 크기 척도: 복잡도

0상

5중

10하

4.3 설계의 신규성 및 신기술의 사용 척도: 혁신성

0많음

5일부

10없음

4.4 소프트웨어 개발 및 검증 환경척도: 환경

0없음

3구식

6신식

4.5 대체 방법 또는 추가 고려사항의 사용척도: 표준

0많음

3적음

6없음

5. SQA 담당자 역량

5.1 SQA 담당자의 RTCA DO-178B 경험 척도: 프로젝트 수

0<5

55-10

10>10

5.2 SQA 담당자의 권한, 자율성, 독립성 척도: 자율성

0없음

5자발적

10적극적

5.3 SQA 담당자의 협동, 개방성, 문제해결 노력 척도: 노력

0없음

5일부

10협조&적극

5.4 지정된 SQA 담당자 경험의 관련성 척도: 관련성

0없음

5일부

10밀접

5.5 SQA 담당자의 현재 업무부하척도: 업무부하

0상

5중

10하

5.6 SQA 담당자의 다른 소프트웨어 표준에 대한 경험(RTCA DO-178[ ] 이외)

척도: 프로젝트 수

0<5

35-10

5>10

총점(TSR):

주: TSO 프로젝트의 경우, 별지1의 “SQA 담당자”은 “소프트웨어 감독을 담당하

는 신청자의 직원”으로 대체될 수 있다. 신청자가 TSO 프로젝트에 검증된

인원이 관련되지 않을 경우, 기준 5.1~5.6항의 점수는 영점이다.


제정: 2009.07.27 개정: 2011.1.3 - 47 -

[별지2]인증당국 참여도(LOI) 작업표

신청자: ____________________________ 프로젝트 명칭 번호: __________________

인증당국 명칭: ______________________ 시스템 유형: _________________________

검사관 : ____________________________ 소프트웨어 레벨: _____________________

위임자 성명: ________________________ 평가 일자: ____________________________

TSR (별지 1 참조): __________________ 기타 정보: ___________________________

LOI 결과: ___________________________ 정책적 문제: _________________________

LOI 평가에 기초가 되는 계획: (예를 들어, 인증당국 현장 검토 횟수, 사무실 검토 횟수, 인증당국에 제

출되는 데이터 등)

중간 프로젝트 조정: (프로젝트 개선 또는 문제에 기반하여)

실제 프로젝트 결과: (예를 들어, 인증당국 현장 검토 횟수, 사무실 검토 횟수, 인증당국에 제출되는 데

이터 등)

항공용 소프트웨어 승인...

Documents