개정기록표 (RECORD OF AMENDMENTS) 개정차수 (Revision No.) 제 / 개정일자 (Revision Data) 원판 차 철입일자 (Insertion Data) 철입자 (Insertion by) 근거 (Referenc

Transcription

1 4-3 (Software Approval Guidelines) 항공정책실 항공기술과

2 개정기록표 (RECORD OF AMENDMENTS) 개정차수 (Revision No.) 제 / 개정일자 (Revision Data) 원판 차 철입일자 (Insertion Data) 철입자 (Insertion by) 근거 (Reference) 제정 ( 항공기술과기술지침서제 1 호 ) 개정 (FAA Notice 장에반영 ) 제정 : i -

3 목차 (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 제1조 ( 소프트웨어검토절차에대한추가고려사항 ) 9 제11조 ( 소프트웨어검토준비 ) 9 제12조 ( 소프트웨어검토신청자통지 ) 9 제13조 ( 소프트웨어검토수행 ) 1 제14조 ( 소프트웨어검토결과의기록 ) 1 제15조 ( 소프트웨어검토종결회의 ) 1 제16조 ( 소프트웨어검토보고서 ) 11 제17조 ( 주요사안검토서식별및준비 ) 11 제 3 장소프트웨어프로젝트에대한인증 제 18 조 ( 참여도의결정 ) 11 제 4 장소프트웨어합치성검사 제19조 ( 소프트웨어합치성검사 ) 14 제2조 ( 소프트웨어부품합치성검사 ) 14 제21조 ( 소프트웨어설치합치성검사 ) 15 제 5 장현장로딩가능소프트웨어 (FLS) 의승인 제22조 (FLS의승인 ) 16 제23조 (FLS의설치에대한고려사항 ) 18 제24조 (FLS 유지보수및부품표식고려사항 ) 18 제정 : ii -

4 제6장부품등제작자증명절차를통해동일성을판정하는현장로딩가능소프트웨어의승인 제25조 ( 동일성수립 ) 19 제26조 (TSO의적용성 ) 21 제7장사용자수정가능소프트웨어 (UMS) 를포함하는항공용시스템및장비의승인 제27조 (UMS 안전성고려사항 ) 21 제28조 ( 시현데이터에대한고려사항 ) 22 제29조 ( 항공기성능파라미터의변경 ) 22 제3조 ( 보호 ) 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 제 1 장 RTCA DO-178B 를이용한레거시시스템의소프트웨어변경승인 제 39 조 ( 레거시시스템의소프트웨어변경 ) 3 제 4 조 ( 레거시시스템의소프트웨어변경승인절차 ) 32 제 11 장소프트웨어변경영향분석 제 41 조 ( 변경영향분석 ) 34 제 42 조 ( 변경영향분석절차 ) 36 제 12 장소프트웨어라이프사이클데이터 제43조 ( 재사용에적합한소프트웨어 ) 37 제44조 ( 안전성고려사항 ) 38 제45조 ( 재사용에영향을주는인자 ) 38 제46조 ( 재사용승인 ) 39 제 13 장공급업체관리등 제47조 ( 공급업체감독 ) 39 제48조 ( 소프트웨어문제보고 ) 41 제49조 ( 항공용시스템데이터베이스및항공데이터베이스의확인 ) 43 제정 : iii -

5 제 5 조 ( 소프트웨어개발및검증환경관리 ) 44 [ 별지 1] 46 [ 별지 2] 47 제정 : iv -

6 (Software Approval Guidelines) 제정 ( 항공기술과기술지침서제 1 호 ) 개정 ( 항공기술과기술지침서제 1 호 ) 제 1 장총칙 제1조 ( 목적 ) 이지침서는항공용컴퓨터에사용되는소프트웨어를승인함에있어감항엔지니어등이 RTCA DO-178B(Software Considerations in Airborne Systems and Equipment Certification) 를적용하는보다바람직한방법과절차등을안내함을목적으로한다. 제2조 ( 적용 ) 이지침서는감항엔지니어등이다음각호의규정이정하는증명또는승인업무 ( 이하 증명등 이라한다 ) 를수행함에있어서소프트웨어승인업무에관한세부적인절차와방법등을안내한다. 다만, 본지침서에수록된방법과절차이외에다른방법등을적용하는것이바람직할경우, 인증신청자가다른방법과절차등을활용해서적합성등을입증및적용하도록할수있으며감항엔지니어등도다른절차와방법등을활용할수있다. 1. 국토해양부고시항공기기술기준 (KAR) Part 국토해양부훈령항공기형식증명지침 3. 국토해양부고시항공기기술표준품형식승인기준 제3조 ( 정의 ) 이지침서에서사용하는용어의정의는다음각호와같다. 1. 인증당국 이라함은소프트웨어라이프사이클데이터를수락및 / 또는승인하는정부기관을말한다. 소프트웨어승인을담당하는인증담당자는국토해양부항공기술과의감항엔지니어및국토해양부장관이지정한항공기등의인증에관한전문검사기관의엔지니어이다. 2. 인증신인도 (credit) 라함은소프트웨어절차, 소프트웨어제품, 실증등이인증요구조건을만족하였다는인증당국의수락을말한다 (RTCA DO-178B 용어정의와 RTCA DO-248B 3.47항을참조 ). 3. 형상아이템 이라함은 (1) 소프트웨어형상관리목적으로, 하나의유닛으로간주되는하나이상의소프트웨어컴포넌트또는 (2) 소프트웨어형상관리목적으로, 하나의유닛으로간주되는소프트웨어라이프사이클데이터를말한다 (RTCA DO-178B 용어정의와 RTCA DO- 248B 3.46항을참조 ). 제정 :

7 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. 재사용 이라함은이전의승인된소프트웨어라이프사이클데이터를변경하지않고계속하여사용하는것을말한다. 1. 검토 라함은 RTCA DO-178B의목표에대한적합성을평가하기위해소프트웨어라이프사이클데이터, 소프트웨어프로젝트진행상황, 기록, 그외증거등을검사하고조사하는활동을말한다. 11. 샘플링 이라함은검사나분석을위해소프트웨어라이프사이클데이터의대표적인표본을선정하는것을말한다. 12. 소프트웨어 라함은컴퓨터프로그램과컴퓨터시스템의운용에관련된문서와데이터를말한다 (RTCA DO-178B 용어정의참조 ). 13. 소프트웨어형상색인 (Software Configuration Index, SCI) 이라함은소프트웨어제품의형상목록을말한다. 14. 소프트웨어라이브러리 라함은소프트웨어개발, 사용, 변경에도움을주도록계획된소프트웨어및관련데이터와문서의관리저장소를말한다 (RTCA DO-178B 용어정의참조 ). 15. 소프트웨어라이프사이클데이터 라함은계획, 지시, 설명, 정의, 기록, 활동의증거를제공하기위해소프트웨어라이프사이클동안생성되는데이터를말한다 (RTCA DO-178B 11.항참조 ). 16. 소프트웨어라이프사이클환경형상색인 이라함은소프트웨어라이프사이클환경의형상목록을말한다 (RTCA DO-178B 11.15항참조 ). 17. 소프트웨어계획과표준 이라함은소프트웨어개발절차와통합절차를지시하기위한일련의데이터를말한다 (RTCA DO-178B 4.항및 항참조 ). 18. 소프트웨어툴 이라함은다른프로그램을개발, 시험, 분석, 생성, 변경, 문서화하는데도움을주는컴퓨터프로그램을말한다 (RTCA DO-178B 용어정의 제정 :

8 참조 ). 19. 차후인증프로젝트 라함은최초인증프로젝트에서생성된소프트웨어라이프사이클데이터를재사용하는후속프로젝트를말한다. 2. 인증신인도시험 이라함은규정에따라적합성을입증하기위한목적으로인증당국의승인을받은시험계획하에서시행되는시스템인증시험을말한다. 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. 소프트웨어프로젝트가그승인된소프트웨어계획및절차를준수한다는객관적증거 제정 :

9 소프트웨어프로젝트에대한인증당국의참여도는프로젝트라이프사이클에서가능한빨리결정되어문서화되어야한다. 소프트웨어검토유형과횟수는프로젝트의소프트웨어레벨, 신청자및 / 또는소프트웨어개발자의경험과이력, 정비애로사항이력, 기타다른요소등에따라달라진다. 인증당국의검토절차는소프트웨어라이프사이클초기에시작하여야한다. 여기에소프트웨어제품및절차에영향을줄수있는계획결정에서신청자와인증당국사이의시의적절한의사소통이필요하다. 이를위해신청자와인증당국간에정기적인연락이수립되어야한다. 검토의 4가지유형은다음과같다. 이장에서 4개의소프트웨어검토단계가정의되어있지만, 일부프로젝트에서는검토단계가통합되거나더세분화될수있다. 1. 소프트웨어계획검토는초기소프트웨어계획절차가완료될때 ( 즉, 대부분의계획서와표준이완료되어검토되었을때 ) 수행되어야한다. 이러한검토는일반적으로개입단계 (Stage Of Involvement, SOI) #1로명칭한다. 2. 소프트웨어개발검토는소프트웨어개발데이터 ( 즉, 요구조건, 설계, 코드등 ) 의상당부분 ( 일반적으로약 5%) 이완료되었을때수행되어야한다. 이러한검토는일반적으로 SOI #2로명칭한다. 3. 소프트웨어검증검토는소프트웨어검증및시험데이터의상당부분 ( 일반적으로약 5%) 이완료되어검토되었을때수행되어야한다. 이러한검토는일반적으로 SOI #3으로명칭한다. 4. 최종인증소프트웨어검토는최종소프트웨어빌드가완료되고, 소프트웨어검증이완료되며, 소프트웨어합치성검토가수행되어소프트웨어어플리케이션이정식으로시스템인증승인을위한준비가된이후에수행한다. 이러한검토는일반적으로 SOI #4로명칭한다. 소프트웨어라이프사이클데이터의가용성은그러한데이터들이항상완료되었음을의미하지는않고, 데이터들은타당한검토가수행될수있을정도는되어야한다. 유사하게, 모든전환기준은프로젝트의검토시점에서완료될필요는없지만, 프로젝트에적용되었음을보증하도록충분한전환기준증거가존재하여야한다. 신청자와인증당국간의논의는프로젝트라이프사이클초기에있어야하며, 소프트웨어검토의유형, 필요, 횟수, 깊이, 형식등이결정되어야한다. 인증당국의관여는프로젝트환경에기반하여변동된다. 제6조 ( 소프트웨어계획검토 : SOI #1) 소프트웨어계획수립프로세스는소프트웨어프로젝트의라이프사이클에서초기절차로, 소프트웨어라이프사이클데이터를개발, 검증, 관리, 보증, 생성하기위해필요한다양한소프트웨어계획, 표준, 절차, 활동, 방법, 툴등을수립하는단계이다. 소프트웨어계획검토는소프트웨어계획수립프로세스의초기완료이후에수행되어야한다. 소프트웨어계획절차가소프트웨어라이프사이클에서지속될지라도그리고계획과표준이프로젝트진행상황에따라변경될수있어도일반적으로관련된초기전환기준이만족되었을 제정 :

10 때에는완료되었다고간주한다. 다음전환기준은일반적인소프트웨어계획수립프로세스완료에대한기준이될수있다. 1. 소프트웨어계획및표준이회사의규정된기준에따라내부적으로검토되고, 결함이해결됨 2. 소프트웨어계획및표준이소프트웨어품질보증 (Software Quality Assurance, SQA) 가평가하고, 결함이해결됨 3. 소프트웨어계획및표준이승인되고, 형상관리됨 4. RTCA DO-178B 부록 A 표 A-1의목표가만족됨 인증당국은신청자로하여금아래표 " 소프트웨어계획검토활용데이터 " 의소프트웨어계획및표준을작성하여, 인증당국이이용할수있도록하여야한다. 보조소프트웨어데이터는소프트웨어레벨에맞게형상관리되어야한다. 소프트웨어계획검토활용데이터 소프트웨어데이터 소프트웨어인증계획서 (Plan for Software Aspects of Certification, PSAC) RTCA DO-178B 조항 11.1 소프트웨어개발계획서 (Software Development Plan, SDP) 11.2 소프트웨어검증계획서 (Software Verification Plan, SVP) 11.3 소프트웨어검증결과 (DO-178B 부록 A 표 A-1 이적용된것 ) 4.6, 소프트웨어형상관리계획서 (Software Configuration Management Plan, SCMP) 소프트웨어품질보증계획서 (Software Quality Assurance Plan, SQAP) 소프트웨어요구조건, 설계, 코드표준 * 11.6, 11.7, 11.8 도구검증계획서 12.2, 소프트웨어품질보증기록 *( 계획활동이적용된것 ) 4.6, * 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-1( 목표 1-2) 이다. 계획은또한계획을따라수행하였을때모든해당 RTCA DO-178B의목표가만족된다는것을보증하도록평가되어야한다. 추가하여, 신청자의안정성평가, 고장조건, 소프트웨어의레벨도평가한다. 또한, 소프트웨어계획및표준과소프트웨어레벨의연관성도평가되어야한다. 제정 :

11 제 7 조 ( 소프트웨어개발검토 : SOI #2) 소프트웨어개발절차는소프트웨어 요구조건, 설계, 코드, 통합절차로, 소프트웨어검증, 형상관리, 품질보증등의통합 절차와인증지원절차에의해지원받는다. 따라서인증당국의소프트웨어개발 검토에서는소프트웨어라이프사이클데이터특히, 소프트웨어개발데이터및이와 관련된통합절차데이터의조사를통해신청자의계획및표준의실제적이행을 평가하여야한다. 이검토동안, 신청자와인증당국은발견된계획및표준의변경 또는성능표준불일치 (deviation) 에대해합의하고문서화할수있다. 소프트웨어 개발검토수행전에, 소프트웨어개발데이터는충분하게갖추어지고완성되어야 한다. 다음전환기준은소프트웨어개발절차의성숙도에대한일반적인기준이될 수있다. 1. 고수준요구조건이문서화되고, 검토되었으며, 시스템요구조건에대해추적 가능함 2. 소프트웨어아키텍처가정의되고, 검토와분석이완료됨 3. 저수준요구조건이문서화되고, 검토되었으며, 고수준요구조건에대해추적 가능함 4. 소스코드가저수준요구조건을구현하고, 소스코드가저수준요구조건에 대해추적가능하며, 소스코드가검토됨 소프트웨어개발검토를위해, 아래표 " 소프트웨어개발검토활용데이터 " 의 소프트웨어데이터를인증당국이이용할수있어야한다. 보조소프트웨어데이터는 소프트웨어레벨에맞게형상관리되어야한다. 또한, SOI #1 에있는계획도검토 전에인증팀에게제공되어야한다. 소프트웨어데이터 소프트웨어개발검토활용데이터 RTCA DO-178B 조항 소프트웨어요구조건, 설계및코드표준 * 11.6, 11.7, 11.8 소프트웨어요구조건데이터 11.9 설계명세 11.1 소스코드 소프트웨어검증절차 (DO-178B 부록A 표 A-2 ~ A-5가적용된것 ) 소프트웨어검증결과 (DO-178B 부록A 표 A-2 ~ A-5가적용된것 ) 소프트웨어라이프사이클환경형상색인 문제점보고서 소프트웨어형상관리기록 소프트웨어품질보증기록 (DO-178B 부록 A 표 A-2 ~ A-5 가적용된것 ) 6.3.1, 6.3.2, 6.3.3, 6.3.4, , 6.3.2, 6.3.3, 6.3.4, * RTCA DO-178B 부록 A 표 A-1 에따라, 레벨 D 에는요구되지않음. 제정 :

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-1( 목표 1-2) 이다. 추가하여, 개발절차에서계획및표주에대한신청자의이행효력을판정하기위해소프트웨어라이프사이클데이터를평가하여야한다. 제8조 ( 소프트웨어검증검토 : SOI #3) 소프트웨어검증절차는일반적으로검사, 실증, 검토, 분석, 시험, 커버리지분석등의조합으로이루어진다. 다른검토와마찬가지로, 소프트웨어형상관리와품질보증절차가이러한검증활동동안에이루어진다. 검증활동은규정된소프트웨어제품이빌드된소프트웨어제품이라고확인한다. 따라서소프트웨어검증절차는이러한확인을제공하고, 제품이충분하게시험되었고의도된제품이라는객관적증거를제시한다는것을보증하여야한다. 소프트웨어검증절차의목적은신청자의검증계획과절차의효과와이행평가, 관련소프트웨어형상관리및품질보증업무의완성보증, 소프트웨어요구조건, 설계, 코드, 통합등이검증보증, 소프트웨어검증절차가 RTCA DO-178B 부록 A 표 A-7의요구조건-기반시험커버리지와구조적커버리지기준달성등을보증하는것이다. 소프트웨어검증검토를수행하기전에, 소프트웨어검증절차는충분하게갖추어지고완성되어야한다. 다음전환기준은검증절차의성숙도에대한일반적인기준이될수있다. 1. 개발데이터 ( 예를들어, 요구조건, 설계, 소스코드, 목적코드, 링크및로딩데이터, 실행가능파일 ) 가완성되었고, 검토되었으며, 형상관리됨 2. 시험케이스및절차가문서화되고, 검토되었으며, 형상관리됨 3. 시험케이스및절차가이행됨 ( 공식 / 비공식 ) 4. 완료된시험결과가계획문서에서협의된대로문서화됨 5. 소프트웨어시험환경이문서화되고, 관리됨 인증담당자는소프트웨어검증검토에서적합성판정을위해, 해당소프트웨어레벨에맞게아래표 " 소프트웨어검증검토활용데이터 " 에서제시하는소프트웨어데이터를이용할수있어야한다. 보조소프트웨어데이터는소프트웨어레벨에맞게형상관리되어야한다. 또한, SOI #1 및 SOI #2에있는데이터도검증검토동안이용할수있어야한다. 소프트웨어검증검토활용데이터소프트웨어데이터 RTCA DO-178B 조항소프트웨어요구조건데이터 11.9 설계명세 11.1 소스코드 오브젝트코드 제정 :

13 소프트웨어검증사례와절차 6.3.1~6.3.6, 소프트웨어검증결과 소프트웨어라이프사이클환경형상색인 ( 시험환경포함 ) 소프트웨어형상색인 ( 시험기준선 ) 문제점보고서 소프트웨어형상관리기록 소프트웨어품질보증기록 소프트웨어도구검증데이터 ( 해당하는경우 ) 인증담당자는 RTCA DO-178B 부록 A에서검증에적용되는목표를소프트웨어검증검토에대한평가기준으로사용하여야한다. 평가하는 RTCA DO-178B 부록 A의목표는표 A-5( 목표 7), 표 A-6( 목표전체 ), 표 A-7( 목표전체 ), 표 A-8( 목표전체 ), 표 A-9( 목표 1-2), 표 A-1( 목표전체 ) 이다. 제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의모든소프트웨어라이프사이클데이터는인증당국이이용할수있어야한다. 아래표에서제시하는데이터는이검토에서특별히관심을두는데이터이다. 보조소프트웨어데이터는소프트웨어레벨에맞게형상관리되어야한다. 제정 :

14 소프트웨어데이터 최종소프트웨어검토의활용데이터 소프트웨어검증결과 소프트웨어라이프사이클환경형상색인 소프트웨어형상색인 문제점보고서 소프트웨어형상관리기록 소프트웨어품질보증기록 ( 소프트웨어합치성검토보고서포함 ) RTCA DO-178B 조항 소프트웨어구현요약서 11.2 인증담당자는이검토에대한평가기준으로 RTCA DO-178B 부록 A의모든목표를사용하여야한다. 추가하여, 사용자는소프트웨어와관련된문제점보고서 (problem report), 실행항목 (action item), 인증문제, 기타등모두를인증, 허용, 승인전에언급하여야한다. 제1조 ( 소프트웨어검토절차에대한추가고려사항 ) 이조에서는인증당국의현장검토에대한 4가지유형의검토를제시한다. 다만, 검토의유형, 횟수, 정도는모든인증프로젝트와신청자에게적절하지는않다. 추가적인고려나대체방안이더적절할수있다. 인증담당자는다음사항을고려하여전자하드웨어검토절차의인증당국참여도를결정한다. 1. 시스템안전성평가에따라결정된소프트웨어레벨 2. 제품특성 ( 크기, 복잡성, 시스템의기능또는새로운고안, 소프트웨어설계등 ) 3. 새로운기술또는일반적이지않은설계특성의사용 4. 새로운소프트웨어방법이나라이프사이클모델의제안 5. 소프트웨어개발에서 RTCA DO-178B 목표의적합성에대한신청자의지식과이전성공사례 6. 프로젝트에서 RTCA DO-178B의 12장에관련된문제의존재여부 7. 인증프로젝트에서소프트웨어관련된주요사안검토서의발생 제11조 ( 소프트웨어검토준비 ) 소프트웨어승인을담당하는인증담당자는인증팀을구성하여야한다. 팀에는소프트웨어엔지니어링, 형상관리, SQA 등에능통한인원 1명이상과시스템안전성평가와시스템요구조건을잘알고있는인원 1명이포함되어야한다. 인증팀의팀장은소프트웨어검토전적어도 6주전에신청자와조율을하여야하고, 의제를제안한다. 제 12 조 ( 소프트웨어검토신청자통지 ) 인증팀장은소프트웨어검토에서인증당국이 제정 :

15 바라는목표에대해적어도검토 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 의목표, 인증기준, 정책, 지침, 기타인증문서를 제정 :

16 참조하여제시하여야한다. 신청자및 / 또는개발자에게지적사항및관찰사항에답할 수있는기회를제공하여야한다. 제 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 프로젝트의초기에, 인증당국, 신청자 제정 :

17 는프로젝트의필요와 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 8 상상중하 8<TSR 13 상중중하 13<TSR 중중하하 1. TSR이 TSR경계치 ( 즉, 8 또는 13) 에근접하면, 가장적절한 LOI를결정하기위해소프트웨어레벨과공학적판단을사용한다. 2. 별지 1의기준이적용되지않으면, 평가자는평균값을적용하거나 참여도결정 의경계치를조정할수있다. 정책적문제가필요한프로젝트는특별한고려사항이요구된다. 일반적으로, 정책 제정 :

18 적문제가있는레벨 A 또는 B 프로젝트는 참여도결정 의결과에상관없이 LOI 상 (High) 이요구된다. 또한정책적문제가있는 C 또는 D 프로젝트도일반적으로 LOI 중 (Medium) 이상이요구된다. 일단 LOI 평가가수행되면, 인증당국의참여도가별지 2에따라문서화되어야한다. 인증프로젝트계획 (CPP, Certification Project Plan) 또는이와동등한문서에포함시키기위해, 인증당국관여사항은별지 2의양식을이용하여문서화되어인증당국의프로젝트관리자에게제출되어야한다. LOI 결과에따른프로그램결정사항예시 인증당국참여도 상 중 일반적인프로그램결정사항 인증당국, 해당분야전문가의관여가능성높음 인증당국은모니터링, 현장검토, 사무실검토등을포함한 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 제출 특수고려사항 1. 중간프로젝트조정. LOI 기준은주로인증프로그램초기에이뤄지는평가와결정에기초한다. 인증프로그램과소프트웨어개발동안, 신청자와개발자모두는모니터링되어야한다. 예측하지못한문제가발생하면, 인증담당자는 LOI 결정을재평가하고참여도를조정할필요가있다. 일부신청자는프로그램진행동안 LOI를낮출수있다 ( 예를들어, 입증된기술의변경, 기타 ). 별지 2의양식은중간프로젝트조정의기록서식을제공한다. 2. 프로젝트위험. 프로젝트진행동안일정지연, 기능축소또는변경같은 제정 :

19 프로젝트위험이발생하는경우, 인증담당자는신청자및 / 또는개발자의위험관리전략을평가하여 LOI를조정할필요가있다. 3. 인증당국업무부하. 다중프로젝트에관여된인증당국요원은다른프로젝트의참여도를고려하여야한다. 다수의참여도상 (High) 의프로젝트를담당하는것특히, 원격지를방문하는여러프로젝트에관여하는것은실용적이지못하다. 일반적으로, 소프트웨어레벨과시스템신규성은프로젝트에더많이참여할지덜참여할지를결정하는중요한요소이다 ( 예, 레벨 A 시스템에는현장검토, 레벨 D 시스템에는사무실검토또는검토없음 ). 최적활동결정및추가인원소요에대한식별등을결정하기위해과도한업무부하는관리자에게보고되어야한다. 일부의경우다른사무소의인원을활용할필요도있을수있다. 4. 인증당국자원. 업무부하에추가하여, 인증당국의 LOI 결정에는현장검토에대한출장비등과같은가용자원을고려하여야한다. 제 4 장소프트웨어합치성검사 제19조 ( 소프트웨어합치성검사 ) 합치성검사의목적은제작한제품 ( 하드웨어및소프트웨어 ) 이형식설계에합치한다는것을보증하는것이다. 소프트웨어합치성검사는 소프트웨어부품합치성검사 와 소프트웨어설치합치성검사 가있다. 신청자가인증신인도를위한실험실시스템하드웨어시험을수행하고자할때그리고항공기수준의지상및 / 또는비행시험을수행하기위한목적으로탑재소프트웨어를시스템에설치할때소프트웨어부품합치성검사와소프트웨어설치합치성검사가요구된다. 소프트웨어합치성검사는다음을보증하기위함이다. 1. 시험대상유닛의형상이인증당국의인증신인도를위해수행되는시험에승인된올바른하드웨어및소프트웨어의형상을반영함. 2. 이미수행된시험이후에하드웨어및 / 또는소프트웨어에변경이있는경우시험대상유닛의형상이잘기록됨. 3. 인증당국이승인한형식설계데이터에합치하는항공기수준의시험을수행하기위해시스템이항공기에설치되고소프트웨어가시스템에로딩되었음. 4. 인증을위해제시된최종소프트웨어및하드웨어형상제품기준선이형식설계에합치함. 제2조 ( 소프트웨어부품합치성검사 ) 시험대상, 시험설비, 사용된시험절차, 시험결과의유효성등에대한합치성은인증신인도를위해수행된개별시험에서수립되어야한다. 인증당국의인증신인도를만족하기위해수행되는시험의예는 RTCA DO-16E 환경검증시험, 시스템기능시험, 시스템통합시험, 항공기지상기능시험, 항공기형식검사승인 (TIA) 시험비행시험등이있다. 제정 :

20 감항엔지니어는다음업무를수행한다. 1. 소프트웨어기준선이인증당국의사무실검토및 / 또는현장검토를수행하여형식설계및관련소프트웨어계획에적합하다는것을확인한다. 일부에서, 환경검증시험을위해특별한목적의소프트웨어가사용된다. 이러한경우, 제작자는특별한목적의시험소프트웨어의형상을검증, 확인, 관리하여야한다. 시험소프트웨어는검증시험전에수행되는시험설비합치성의일부로포함되어야한다. 2. 소프트웨어시험기준선에적합하여 LRU에설치되는소프트웨어의시험형상을확인한다. 3. 시험기준선과관련된모든소프트웨어가공품은형상관리하에서적절히식별되고, 시험중인소프트웨어의현재상태가반영되는지확인한다. 4. 검증이필요한모든소프트웨어개발툴또는소프트웨어검증툴이검증되었음을확인한다. 그러나합치성검토시점에서툴검정활동이완료되지않은경우, 툴과보조데이터는그형상이문서화되어야한다. 5. 항공기등형식증명지침 별지제15호서식 합치성검사요청서 를작성 제출하여인증당국의검사관이다음사항을수행하는지침을마련하도록한다. 가. 적절하게빌드되어로딩한파일이소프트웨어형상관리라이브러리에서제거되었음을확인한다. 나. 소프트웨어빌드및로딩절차동안승인된빌드및로딩지침이준수되었는지확인한다. 다. 모든데이터의무결성이점검되고, 소프트웨어부품번호 ( 버전번호포함 ) 가 LRU에서검증되었는지확인한다. 라. 시험시설이승인된엔지니어링시험계획에식별된시험시설형상에합치하는지확인한다. 6. 소프트웨어라이프사이클데이터의보유, 보관, 호출에사용되는절차가승인된소프트웨어형상관리계획 (SCMP) 에적합한지확인한다. 인증당국의검사관은상기제2조 5항에서언급되고 항공기등형식증명지침 별지제15호서식 합치성검사요청서 에식별된업무를수행하여야한다. 소프트웨어부품합치성검사는소프트웨어설치합치성검사요청전에성공적으로수행되어야한다. 제21조 ( 소프트웨어설치합치성검사 ) 소프트웨어설치합치성검사는형식검사승인 (TIA) 에따라수행되는시험처럼인증당국의항공기수준지상또는인증비행시험중에언제든요구된다. 주요목적은다음과같은것을입증하기위함이다. 1. 승인된시스템장착설치및 / 또는소프트웨어로딩절차에적합하게승인되고관리되는소프트웨어버전이타깃시스템에성공적으로로딩됨. 2. 시스템에올바른버전이로딩되어성공적으로초기화됨 감항엔지니어는다음사항을보증하여야한다. 제정 :

21 1. 이전소프트웨어부품합치성검사가성공적으로수행되었음. 2. 로딩절차가승인되었음. 3. 항공기등형식증명지침 별지제15호서식 합치성검사요청서 또는별지제19호서식 형식검사승인서 가작성되어장착합치성검토가요청된소프트웨어의부품번호및 / 또는버전넘버가포함되었음. 소프트웨어의부품번호및 / 또는버전넘버는식별가능하고, 형상관리되며, 재생성가능하여야하며소프트웨어형상색인 (SCI) 또는이와유사한형상문서에기록되어야한다. 합치성검사요청에는다음사항을포함하여인증당국의검사관이검증하여야하는실행활동이포함되어야한다. 가. 올바른소프트웨어버전이시스템에로딩되고, 항공기에올바른시스템하드웨어 ( 부품번호및일련번호 ) 가장착됨을확인. 나. 로딩절차가올바른소프트웨어부품번호 ( 및버전넘버 ) 가올바른시스템하드웨어구성품 ( 일련번호및부품번호 ) 에로딩됨을보증하는지확인. 소프트웨어로딩절차또는지상보조장비가부품번호및버전번호의불일치 (mismatch) 또는성공적이지못한로딩을탐지하면오류표식을언제든표시하여야한다. 설치합치성검사에서는제작자의로딩절차가준수되는지그리고소프트웨어로딩이올바르게초기화되는지를판단하여야한다. 불일치는식별되어기록되어야한다. 인증당국의검사관은다음 2가지방법중하나로 항공기등형식증명지침 별지제15호서식 합치성검사요청서 또는별지제19호서식 형식검사승인서 에언급된소프트웨어설치합치성검사를수행하여야한다. 1. 항공기가설치되었거나설치될실제시스템에올바른소프트웨어부품번호및버전 ( 즉, 실제부품번호및일련번호 ) 이성공적으로로딩되도록물리적입회. 성공적인로딩은무결성확인에서소프트웨어로딩확인 ( 예, 순환중복검사 (CRC) 의비교 ) 을입회하거나, 소프트웨어가초기화절차가성공적으로수행되었음을입회하여결정한다. 소프트웨어로딩절차는감항엔지니어가검토하여승인한소프트웨어로딩절차에따라수행되어야한다. 2. 실제소프트웨어로딩결과가기록된제조검사기록을획득. 이러한기록에는해당하는항공기식별정보, 시스템하드웨어부품번호및일련번호, 소프트웨어부품번호및버전번호등이포함되어야한다. 제공되는기록은인증당국의검사관이항공기에장착된시스템을추적할수있도록하드웨어유닛부품번호와일련번호정보가식별되어야한다. 또한제공되는기록에시스템하드웨어로로딩되는소프트웨어부품번호를표시하여야한다. 기록에는언제어떻게소프트웨어가로딩되었는지그리고로딩및초기화절차가성공적이었는지를표시하여야한다. 제 5 장현장로딩가능소프트웨어 (FLS) 의승인 제정 :

22 제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의프로젝트인경우, 신청자가내장장비, 휴대장비, 기타 제정 :

23 적절한방법으로항공용장비의소프트웨어부품번호를검증할수있음을확인. TSO 프로젝트의경우, KAR 21.67(d) 를따르는적절한부품표식데이터는어떤지형적위치에서도지상에서확인가능하여야한다. 9. FLS의변경은안전성영향및중또는경변경분류를결정하기위해소프트웨어변경영향분석을수행함을확인.( 그러지않으면, FLS은이지침서의 7장에서언급하는사용자변경가능소프트웨어이다 ). 1. 로딩보호메커니즘이비행중 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 부품번호를필요한정비로그에기록함을보증하는절차가있어야한다. 제정 :

24 4. 하드웨어와소프트웨어가분리된부품번호를갖는항공용장비의경우, 전자적질의형태로확인할수있으면소프트웨어부품번호는유닛의외부에표시할필요는없다. 소프트웨어부품번호가기록되었음을보증하는것은정비요원의책임이다. 새로운소프트웨어가유닛에로딩되었을때, 동일한요구조건이적용되어유닛이서비스를재개하기전에승인된소프트웨어부품번호가확인되어야한다. 5. 소프트웨어와하드웨어의특정형상을표현하는하나의부품번호를갖는항공용장비에대해, 새로운소프트웨어가로딩될때, 명판의유닛식별사항은변경되어야한다. 새로운소프트웨어가로딩될때, 데이터로딩후에타깃컴퓨터에저장된소프트웨어의부품번호는전자적으로검증하여야한다. 유닛의서비스재개전에전자적소프트웨어부품번호와명판에표시된유닛의부품번호는승인된형상임을확인하여야한다. 6. TSO 승인된제품에 FLS가사용되어신청자가 FLS에대해전자적부품표식을원하는경우, FLS는 KAR 21.67(d) 의부품표식요구조건을만족하여야한다. KAR 21.67(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). 승인된소프트웨어는정비회보또는기타인증당국이승인한방법을이용 제정 :

25 하여항공기에장착될수있다. (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와동일한방법으로적용하기전에입증하고승인받아야한다. 라고기술하고있다. 다. 인증당국의책임. 인증당국의검사관은면허협약에의한동일성을다룬다. 제정 :

26 반면, 감항엔지니어는다른 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를포함하는시스템의초기승인단계에서평가되어야한다. 사용자에의한시스템변경이보호메커니즘에 제정 :

27 영향을주지않는다는것을보증하여야한다. 제28조 ( 시현데이터에대한고려사항 ) 정보가비행승무원에게시현되고 UMS로부터유래하는경우, 정보는인증당국이항공기형식설계의일부로승인하지않은 참고데이터 (advisory data only) 라고구분하여식별하여야한다. 시현되는정보가해당운용승인당국으로부터항공기의운용절차의일부로운용승인을받은경우, 이구분은필요하지않을수있다. 두가지유형의정보에대한구분오류를합당하게배제할수있고비행승무원이쉽게볼수있도록설계, 장비의고유특성, 사용자수정가능구성품등이승인된정보와비승인정보를구분한다면, 참고데이터 (advisory data only) 라는정보의직접적인식별은요구되지않을수있다. 요구되는곳에서, 수정불가구성품이이런식별을제공하여야하고, 비행승무원이인증또는운용승인당국이승인하거나수락한정보들을쉽게구별하도록하여야한다. 참고데이터 (advisory data only) 정보는항공기의다른출처로부터비행승무원이검증할수있어야하고, 오해하기쉬운데이터를표시하는잠재적최악경우의고장조건이경고장조건보다큰경우어떠한정보도시현하는데사용하지않아야하거나, 비행승무원이항공기운용절차를수행하는데사용되지않아야한다. 제29조 ( 항공기성능파라미터의변경 ) 안전여유, 항공기운용역량, 승무원작업부하등에영향을줄수있는변경에는항공기성능파라미터를결정하기위해비행승무원이사용하는시현데이터또는기타데이터의변경은인증당국의승인이필요하다. 이러한파라미터를제공하거나개정하는사용자수정가능구성품의변경은파라미터들이 1차정보또는참고정보로제공되는지에상관없이인증당국의승인이필요하다. 이러한변경은사용자수정가능이란소프트웨어의분류를무효로하고, 설계승인및부품번호개정이필요하다. 제3조 ( 보호 ) 항공용시스템의수정불가소프트웨어구성품은 UMS 구성품으로부터보호하여야한다. 시스템요구조건에는시스템안전성, 운용역량, 비행승무원작업부하등에영향을주는사용자수정을방지하기위한보호메커니즘을명시하여야한다. 시스템요구조건에사용자수정에대한방책을포함하지않으면, 사용자는소프트웨어를변경하지않아야한다. 보호메커니즘은시스템안전성평가에서결정된시스템의가장심각한고장상태의보증레벨을할당하여야한다. 소프트웨어가 UMS에대한보호메커니즘을제공한다면, 그소프트웨어보호에는시스템안전성평가에의해결정된시스템의가장높은소프트웨어레벨을할당하여야한다. 보호는변경또는보호손실로야기되는 UMS의고장을방지하여야한다. 보호무결성은사용자의활동에의존해서는안된다. 보호무결성은우연히또는고의적으로침해될수없도록하여야한다. 신청자가제공하는 UMS 수정방법은수정가능구성품을변경할수있는유일한방법이어야한다. 제정 :

28 제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 구성품의모든점과소프트웨어수정에사용되는툴에대한책임을갖고있다. 이런것에는소프트웨어형상관리, 소프트웨어품질보증, 소프트웨어검증도포함된다. 사용자수정은승인된툴을사용하여시스템요구조건및소프트웨어데이터에의해수립된승인된절차에따라수행하여야한다. 사용자가수정불가소프트웨어구성품, 보호메커니즘, 승인된절차, 승인된툴 ( 시스템요구조건및승인된절차에의해수립된것이외 ) 에수정을 제정 :

29 가한다면, 사용자는형식설계에위반하는것이고, 항공기의형식증명은취소될수있다. 인증동안, 인증당국은현장에서항공기형상변경승인 ( 예를들어, 운용승인 ) 을담당하는규정당국과조율하여야한다. 소프트웨어변경을추적하거나기록하는시스템은필요한경우관할당국이변경의인증및감항성유지모두를검토할수있음을고려하여야한다 ( 해당하는경우 ). 제 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는타깃어플리케이션에서수락가능하지않은고장조건이발생하지않음을보장한다. 인증당국은이러한평가를확인하여야한다. 다중소프트웨어레벨의소프트웨어어플리케이션이주어진시스템및 / 또는구성품 제정 :

30 에포함된경우, 시스템및 / 또는구성품의최상위소프트웨어레벨의목표를만족하기위해상이한소프트웨어레벨사이의보호및관련메커니즘 ( 예 : 파티셔닝, 안전모니터링, 감시타이머 ) 을검증하여야한다. 또한신청자는식별된기능또는공동자원의공통원인및공통모드손실은최초에개별시스템에할당된것보다나쁜고장조건을유발하지않음을검증할필요가있다. 이러한경우, 개발노력의일부는 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 항의기준이어떤유형의툴에적용 되는지결정하는데사용할수있다. 툴검정에적용되는 RTCA DO-178B 의기준 기준개발참조검증참조 결정론적툴만이검증될수있다 ( 더자세한것 은이장의제 38 조에서설명한다 ) 예 12.2 예 12.2 검증은특정시스템에만적용한다. 의도는 PSAC 예 12.2 예 12.2 에언급되어야한다. 파티셔닝을입증할수없다면, 조합된툴은예 12.2.b 예 12.2.b 제정 :

31 RTCA DO-178B의 항에따라검증되어야한다 ( 더자세한것은제38조에서설명한다 ) 검증될툴에소프트웨어형상관리및품질보증절차목표를적용하여야한다.( 더자세한것은이지침제38조에서설명한다 ) 항공용소프트웨어처럼검증은동일한목표를만족하여야한다. 예 12.2.c 예 a 예 12.2.c 아니오 툴의소프트웨어레벨은감소할수있다. 예 b 아니오 툴작동요구조건에대한적합성입증을위한 수단으로시운전기간이사용될수있다. 예 c 예 툴작동요구조건이검토되어야한다. 예 d(1) 예 정상작동조건에서툴작동요구조건에대한 적합성이입증되어야한다. 예 d(2) 예 비정상작동조건에서툴작동요구조건에대한 적합성이입증되어야한다. 예 d(3) 아니오 요구조건기반의커버리지가분석되어야한다. 예 d(4) 아니오 툴의소프트웨어레벨에해당하는구조적커버리지가완료되어야한다. 예 d(5) 아니오 툴의소프트웨어레벨에해당하는강건성시험이완료되어야한다. 예 d(6) 아니오 잠재적오류가분석되어야한다. 예 d(7) 아니오 제 37 조 ( 검정에필요한데이터및그가용성 ) 툴검정에필요한데이터는다음과같 다. 개발툴검정시, PSAC 은툴검정계획을참조하여야한다. 그리고 SAS 는툴 검정구현요약서를참조하여야한다. 검증툴검정시, 신청자는툴검정계획서와툴 검정구현요약서를개발할수있다. 데이터 툴검정에필요한데이터 적용성 가용 / 제출 RTCA DO-178B 참조 소프트웨어인증계획서 (PSAC) 검증및개발제출 12.2, a, 툴검정계획서개발제출 a(1), , 툴작동요구조건검증및개발가용 c(2), 소프트웨어구현요약서 (SAS) 검증및개발제출 툴검정구현요약서개발제출 c(3), 제정 :

32 툴검정기록 ( 예를들어, 시험케이스, 절차, 결과 ) 툴검정개발데이터 ( 예를들어, 요구조건, 설계, 코드 ) 검증및개발가용 개발가용 소프트웨어검증툴검정에대해, 다음데이터제출및가용성을고려한다. 1. 검증툴에대해, 신청자는 PSAC에서검증툴의사용의도를명확히한다 (RTCA DO-178B 12.2항참조 ). PSAC은인증당국에제출하여야하고, 의도한툴검정일정을포함하여야한다. 인증당국은 PSAC의검증툴검정접근방식을검토하여시의적절하게 PSAC에나열되거나참조된접근방식에대한수락성을신청자에게서면으로제공하여야한다. 2. 검증툴검정에대해, 툴작동요구조건은문서화되어인증당국이활용가능하여야한다 (RTCA DO -178B의 항참조 ). 툴작동요구조건데이터에대한요구조건은제38조에서논의된다. 3. 툴작동요구조건의모든요구조건이검증되었음을보이는데이터는인증당국의검토를위해문서화하여활용가능하여야한다. 신청자는이러한검증데이터를신청자가선정한어떤문서에도담을수있다. 4. 검증툴검정결과를요약하는내용 (entry) 을 SAS에포함하여야한다. SAS를인증당국에제출하여야한다. 신청자는소프트웨어검증툴에대해 PSAC과 SAS에서기입내용으로, 참조되는툴검정계획과툴검정구현요약서를따라제공하는것을선택할수있다. 소프트웨어개발툴검정에대해, 다음데이터제출및가용성을고려한다. 1. 실제검증접근방식과제공할데이터를툴검정계획서에명시하여야한다. 인증당국은신청자로하여금툴검정계획서를제출하도록하여야한다. 2. 툴검정구현요약서도인증당국에제출하도록하여야한다. 툴검정구현요약서는툴검정절차의결과를요약하고관련툴검정데이터를설명하고인용한다. 3. 인증당국은신청자로하여금PSAC 과 SAS를제출하고인증당국의승인을받도록하여야한다. 그러나이러한문서들은툴검정계획서와툴검정구현요약서문서를참조하는데만사용된다. 4. 툴작동요구조건은문서화되어인증당국이활용가능하여야한다 (RTCA DO-178B 항참조 ). 툴작동요구조건데이터에대한요구조건은제38 조에서논의한다. 5. 툴작동요구조건의모든요구조건이검증되었음을보이는데이터는인증당국의검토를위해문서화하여활용가능하여야한다. 정상및비정상조건하에서툴이작동하는것을입증하는데상당한검증데이터가필요하다. 데이터는툴의복잡성및목적, 어떻게툴이사용되는지에따라달라진다. 인증당국은신청자가이러한검증데이터를신청자가선정한어떤문서에도포함시킬수있도록 제정 :

33 할수있다. 6. 설계, 코드, 시험케이스, 절차등과같은기타의툴검정데이터도인증당국의검토를위해활용가능하여야한다. 인증당국은신청자가사용하는문서형식및매체유형을사용하기위해노력하여야한다. 인증당국에제출하기위해재패키지하는것은신청자가제공하는방식으로인증당국이데이터를검토할수없거나신청자가관련규정에대한데이터보관규정을만족시키지못할때에만수행한다. 제38조 ( 작동요구조건데이터의수락성평가 ) 검증이필요한툴의작동요구조건은완성되어인증당국의검토를위해활용가능하여야한다. 툴작동요구조건은툴의모든기능적기술적특성과툴이장착될환경을식별하여야한다.(RTCA DO-178B 의 항참조 ). 필요한정보는툴의유형에따라달라진다. 검증툴에대해, 툴작동요구조건에서는최소한다음과같은정보가제공되어야한다. 1. 툴검정시험의일부로검증되는특정요구조건으로표현되는툴의기능 2. 작동시스템과기타고려사항을포함한툴작동환경의정의 ( 예 : 툴이수행하지않는것에대한분석, 그부족을포함하기위해필요한것 ( 점검표, 시험케이스의확대같은 ), 특화된하드웨어요구조건 ( 프로세서, 특별시험장비, 인터페이스등 )) 3. 툴작동요구조건에포함되어야하는툴장착또는작동에필요한기타정보 ( 사용자매뉴얼등 ) 개발툴은검증툴에서나열한모든정보를포함하여, 최소한다음과같은정보가제공되어야한다. 1. 툴이수행하는소프트웨어개발절차 2. 비정상작동조건에서예상되는응답. 일부의경우, 사용자매뉴얼또는기타공급업자의문서가필요한정보를포함할수있다. 추가적인정보가필요한정보를포함한경우, 필요한정보를명확하게식별하여야한다. 툴공급업자가불충분한정보를제공하는경우, 신청자는누락된정보를제공하여야한다. 개발및검증툴은툴작동요구조건의검증이필요하다. 검증툴의경우, 정상작동조건에서의검증만이요구된다. 개발툴의경우에는비정상작동조건에서의검증이추가로요구된다. 작동요구조건에는검증활동과직접적으로연관되지않은추가정보가포함될수있기때문에 ( 메뉴의형상, 다이얼로그박스, 구성등 ) 검증툴에대한불필요한검증을줄이기위해추가적인안내가필요하다. 검증툴에대해서만, 작동요구조건의그런부분이툴검정의일부로검증되어야하는검증의구성, 수행, 감시, 보고등에서직접적으로사용된다. 신청자는사용되지않는검증툴의이러한특성부분이사용되는특성부분에약영향이없음을보증하여야한다. 추가적인특성이나중에사용된다면, 추가적인검증이필요하다. 툴결정론의해석에대한지침 1. 결정론적툴만이검증될수있지만 (RTCA DO-178B 의 항참조 ), 결정론의 제정 :

34 축소적해석이란명백한동일입력은필연적으로정확하게동일한결과로인도된다는것을말한다. 그러나툴의결정론에대한더정확한해석은툴에의한출력의정확성을결정할수있는능력이수립되어있다는것을말한다. 주어진입력으로부터출력의모든가능한편차는그결과의적절한검증하에서올바르다는것을입증할수있다면, 툴은툴검정에서결정론적이다라고간주하여야한다. 2. 결정론에대한해석은툴의출력이사용자의통제를넘어다양해질수있으나변동이출력의의도된사용 ( 예를들어, 기능 ) 에악영향을주지는않고출력의정확함에대한사례가존재하는모든툴에적용되어야한다. 그러나이러한결정론의해석은항공용시스템에탑재되는최종실행가능이미지에영향을주는툴에는적용되지않는다. 최종실행가능이미지의생성은결정론의축소적해석을만족하여야한다. 예로서, 툴은도표적방식으로사용자와상호작용하는그래픽사용자인터페이스 (GUI) 를가질수있다. 이툴의기초가되는것은그러한도표의의도된의미를획득하는데이터표이다. 그러나종종이러한툴의출력은그러한데이터표에서입력사항의물리적순서에의해부분적으로조종된다. 그리고데이터표의입력사항의순서는툴사용자가통제하지않는다. 하지만툴출력의정확성은수립할수있다. 결정론의축소적해석으로는이러한툴은검증할수없지만, 해석을확대하면검증이가능할수있다. 조합된개발및검증툴의검정에대한지침 1. 이항은개발및검증기능의양쪽출력이 RTCA DO-178B 의절차를제거, 축소, 자동화하는데사용되는조합된개발및검증기능을제공하는툴에만적용한다. 개발목표만을또는검증목표만을제거, 축소, 자동화하는데사용되는조합툴은그툴에서제공하는다른역량에상관없이검증하여야한다. 2. 개발및검증기능모두가 RTCA DO-178B의목표를충족하거나교체하는데사용될때두기능간의보호 / 파티셔닝을입증할수없다면, 항공용소프트웨어의레벨과동일한지침에따라조합된툴의검증을수행하여야한다. 이보호 / 파티셔닝의수락가능한증거는툴의한가지기능의출력이툴의다른기능의출력에영향을주지않는다 ( 즉, 툴역량이기능적으로분리되었다 ) 는것을보여주는것이다. 3. 개발및검증기능간의보호 / 파티셔닝을입증할때, 보호 / 파티셔닝기능은기능이개발과검증툴로나눠진것처럼검증될수있다. 즉, 검증기능은검증툴의기준에따라검증할수있다. 검증된툴사용에대한신인도를받기위해 ( 즉, RTCA DO-178B의목표를충족하거나대체하기위해 ), 이러한툴들은형상관리하에있어야한다. RTCA DO-178B의 b항에서는개발및검증툴의검정데이터에대한관리등급을언급하고있다 (RTCA DO-178B의 7.2.9b항참조 ). 개발툴의검증데이터에대한관리등급은동일레벨의항공용소프트웨어에필요한관리등급과같다. 한편, 검증 제정 :

35 툴검정데이터는 CC2 로분류할수있다. 이전에검증된툴의모든변경에대해소프트웨어변경영향분석을수행하여야한다. 변경의영향하에있는다른툴뿐만아니라제품에대한툴의영향을평가하는데충분하도록분석을철저히하여야한다. 회귀적분석이변경영향분석의일부를구성할수있다. 툴이이장의지침을만족한다면, RTCA DO-178B 제정이전의프로젝트에사용된소프트웨어툴은 RTCA DO-178B가적합성입증방법인프로젝트에사용한것에대해검증받을수있다. 대안으로, 그런툴에대해서비스이력이고려될수있다. 제 1 장 RTCA DO-178B 를이용한레거시시스템의 소프트웨어변경승인 제39조 ( 레거시시스템의소프트웨어변경 ) 레거시시스템의소프트웨어레벨이고려되는제품장착에서요구하는것과동일하거나더낫다는것을입증하지못하면, 소프트웨어는 RTCA DO-178B 의 항 개발기준선의상향 에따라등급을올려야한다. 이러한것은 RTCA DO-178B의해당목표에대한보증을입증하기위해완전한재평가가필요할수있다. 레거시시스템의소프트웨어를변경하기위한대응에필요한조치에영향을줄수있는 4가지변수가있다. 1. 최초제품또는레거시소프트웨어를포함하는레거시시스템의장착에대한인증기준 ( 즉, 규정, RTCA DO-178 버전, 최초승인에적용된소프트웨어레벨 ) 2. RTCA DO-178B 또는이전버전이고려중인제품또는설치에대한소프트웨어의수락가능한적합성입증방법인지여부 ( 그리고최초인증의소프트웨어레벨에대해소프트웨어레벨이동일하거나동등한지여부 ) 3. 소프트웨어의수정또는비변경여부 ( 그리고최초인증이후변경된횟수및그러한변경의이유 ) 4. 소프트웨어및레거시시스템이장착되는항공기또는엔진이동일한지다른지여부 소프트웨어레벨이동등하다는것을입증할수있다고가정하면, 관심대상인레거시시스템의문제대부분은다음과같은그룹으로분류할수있다. 1. 레거시시스템소프트웨어가수정되지않고원래항공기에재설치된다. 2. 레거시시스템소프트웨어가수정되지않았지만소프트웨어의적합성입증방법으로 RTCA DO-178B가적용되지않은다른항공기또는엔진에장착된다. 3. 레거시시스템소프트웨어가수정되어원래항공기또는엔진에재장착된다. 4. 레거시시스템소프트웨어가수정되어소프트웨어의적합성입증방법으로 RTCA DO-178B가적용되지않은다른항공기또는엔진에장착된다. 제정 :

36 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. 이전승인과일치하기위해, 변경, 변경된소프트웨어구성품, 소프트웨어변경에 제정 :

37 영향을받는구성품을만드는데사용된절차를평가하기위해 RTCA DO-178B를사용한다. 이지침의 11장의지침과 RTCA DO-178B의 ~12.1.6항을활용한다. 소프트웨어변경에대한변경영향분석을수행하고기타구성품, 인터페이스, 타이밍, 메모리등에대한영향을식별하여영향을받는구성품을확인하여야한다.( 예 : 컨트롤흐름분석, 데이터흐름분석, 타이밍분석, 메모리사용분석 ) 또한이러한분석에서변경사항을검증하는데필요한회귀시험의수준과범위를식별하여야한다. 4. 소프트웨어의영향을받지않는부분은이미승인기준을가지고있으며제39조 에따라수락가능하다. 대부분의경우, 소프트웨어에잔존하는잠재적오류의위험은이전승인의서비스경험이점을고려하여더완화될수있다. RTCA DO-178B 의 항 제품서비스이력 에는서비스경험의사용을허용하기위해만족되어야하는기준이포함된다. 신청자가충분한관련서비스이력데이터를갖고시스템이사용중문제가없었다면, 항하에서서비스경험에관해신청자는적은데이터가필요하거나추가데이터가필요없을수있다. 5. 일부 TSO는명판에 DO-178[ ] 과해당레벨을명시하도록요구한다. 중변경이 RTCA DO-178B로승인되고소프트웨어의대다수가 RTCA DO- 178B에적합하다면, 명판에는 DO-178[ ] 과해당소프트웨어레벨을표시할수있다. 6. 일단 DO-178B 에적합한변경절차가소프트웨어중변경을기술하기위해적용되면, 그절차는해당소프트웨어의다음모든변경에적용되어야한다. 제4조 ( 레거시시스템의소프트웨어변경승인절차 ) 인증당국은신청자로하여금레거시시스템의소프트웨어레벨과제안된장착의소프트웨어의동일성을아래 소프트웨어레벨의동등성 을활용하여입증하도록하여야한다. 1. 소프트웨어레벨의동등성 에는동등성을결정하기전에추가적인분석이필요할수있는 2개의입력사항이있다. 이러한것들은 소프트웨어레벨의동등성 에서는 분석 이라고제시된다. 추가분석이필요한경우, 인증당국은신청자와이를협의하여야한다. 2. 소프트웨어레벨의동등성 으로동등성을확인할수없다면 ( 즉, 표에서 아니오 라는입력이면 ), 소프트웨어레벨을향상하기위해소프트웨어어플리케이션또는파티셔닝에 RTCA DO-178B 항의규정을적용하여야한다. 제정 :

38 장착에필요한 RTCA DO-178B 소프트웨어레벨 소프트웨어레벨의동등성 RTCA DO A 에따른레거시시스템소프트웨어레벨 중요 (critical) 레벨 1 기본 (essential) 레벨 2 비기본레벨 3 A 예 / 분석 아니오 아니오 B 예 아니오 / 분석 아니오 C 예 예 아니오 D 예 예 아니오 E 예 예 예 레거시시스템의소프트웨어가수정되지않고 RTCA DO-178B가요구되지않는동일한항공기 / 엔진또는다른항공기 / 엔진에재장착된다면, 최초의보증절차와관련제출데이터는수락될수있다. 레거시시스템의소프트웨어가수정되고소프트웨어적합성입증방법으로 RTCA DO-178B가적용되지않는동일한항공기 / 엔진또는다른항공기 / 엔진에장착된다면, 최신개정판이사용된것을제공하여최소장착의적합성입증방법또는최소레거시시스템의적합성입증방법이사용될수있다. 소프트웨어수정을평가하고적절한회귀시험을적용하기위해, 이지침의 11장에서정의된변경영향분석을수행하여야한다. 레거시시스템의소프트웨어가수정되고소프트웨어적합성입증방법으로 RTCA DO-178B 가적용되는다른항공기 / 엔진에장착된다면, 제39조과 11장의지침에따라경변경인지결정한다. 경변경으로결정된변경사항은제4조에서논의한변경하지않은경우와동일하게처리할수있다. 변경이경변경이라는결정은 11장의지침을사용하여인증당국의판단에따른다. 1. 변경이경변경이아니면, 소프트웨어의모든변경과그변경에영향을받는모든구성품은제39조에따라 RTCA DO-178B를사용하여보증하여야한다. 영향을받는구성품을결정하는데변경영향분석이일반적인방법이다. 변경영향분석에대한설명은 11장에포함되어있다. 그러나프로젝트계획및절차, 변경활동과그증거는 RTCA DO-178B의목표를충족한다는것을보여야한다. 2. 추가적으로영향을받으나변경되지않은구성품은내부구조적커버리지에대해평가하지않을수있으나, 통합시험을사용하여다른구성품과인터페이스를하는구성품에변경이없음을검증하여영향을받는기능에대한요구조건기반의시험커버리지뿐만아니라데이터흐름및컨트롤흐름커버리지에대한목표는만족하여야한다. 레거시시스템의소프트웨어가변경되지않고보증을입증하는수단으로 RTCA DO-178B가적용된다른항공기 / 엔진 ( 즉, 다른형식증명 ) 에장착된다면, 소프트웨어에대한별도의적합성판정을하지않아야한다. 시스템의 제정 :

39 운용사용 (operational use) 이상당히다르다고예상되지않으면최초의승인이소프트웨어장착승인으로인정할수있다. 운용사용이최초또는차후장착승인과상당히다를때, RTCA DO-178B 지침에대한보증을수행하여야한다. 운용사용의변경에대한중요성결정은인증당국의판단에따른다. 레거시시스템소프트웨어의모든변경과이러한변경을승인하는데사용된절차는특정프로젝트에맞게 PSAC, SCI, SAS 등에문서화되어야한다. 레거시시스템에대한운용이력을주장하려면, 이러한데이터가마찬가지로 SAS에요약되어야한다. 향후에변경이제안된경우, 이장에서규정된기준을사용하여언급되어야한다. 제 11 장소프트웨어변경영향분석 제41조 ( 변경영향분석 ) 인증당국은신청자가제품에통합될소프트웨어변경을식별하고, 변경영향분석을수행하도록하여야한다. 변경영향분석은항공기의계속적인운용안전에대한변경의잠재적영향을결정하기위해규정된절차를따라야한다. TSO 형식승인장비에대해, 분석에서분석에대한기초를형성하는의도된타깃항공기환경을식별하여야한다. 이분석은또한인증당국의관여정도를결정하기위한기준을제공한다. 변경영향분석에서다음사항을적절하게언급하여야한다. 1. 추적성분석은소프트웨어변경으로영향을받을수있는분야를식별한다. 여기에는아래에서기술하는것과같이영향을받는요구조건, 설계, 아키텍처, 코드, 시험, 분석등이포함된다. 가. 요구조건및설계분석은변경으로영향을받는소프트웨어요구조건, 소프트웨어아키텍처, 안전관련소프트웨어요구조건을식별한다. 추가적으로, 분석으로시스템에서실행되는추가적인특성 / 기능을식별하고, 추가기능이적절하게검증되었음을보증하며, 추가기능이기존기능에악영향을주지않음을보증한다. 나. 코드분석은변경에영향을받는소프트웨어구성품과인터페이스를식별한다. 다. 시험절차및케이스분석은변경을검증하기위해재실행될필요가있는특정시험절차와케이스를식별하고, 추가기능이나이전에불충분한시험에대해새롭거나수정된시험절차와케이스를식별하여개발하며, 변경의결과로악영향이없음을보증한다. 악영향이없음은변경되는소프트웨어의소프트웨어레벨에적정하게적절한계층수준 ( 항공기비행시험, 항공기지상시험, 실험실시스템통합시험, 시뮬레이터시험, 벤치시험, 하드웨어소프트웨어통합시험, 소프트웨어통합시험, 모듈시험등 ) 에서회귀시험을수행하여검증할수있다. 2. 메모리여유분석은메모리할당요구조건및수락가능한여유가유지되는지를 제정 :

40 보증한다. 3. 타이밍여유분석은타이밍요구조건, CPU 작업스케줄링요구조건, 시스템자원경쟁특성, 인터페이스타이밍요구조건, 수락가능한타이밍여유가유지되는지를보증한다. 4. 데이터흐름분석은데이터흐름의변경, 구성품간의연동을식별하고, 악영향이없음을보증한다. 5. 컨트롤흐름분석은컨트롤흐름의변경, 구성품간의연동을식별하고, 악영향이없음을보증한다. 6. 입출력분석은변경이제품의입출력 ( 버스로딩, 메모리접근, 하드웨어입출력디바이스인터페이스등을포함 ) 요구조건에악영향을주지않는다는것을보증한다. 7. 개발환경및절차분석은소프트웨어적용또는제품에악영향을줄수있는변경 ( 예를들어, 컴파일러옵션또는버전및최적화변경, 링커, 어셈블러, 로더지침또는옵션변경, 소프트웨어툴변경 ) 을식별한다. 8. 운용특성분석은변경 ( 이득, 필터, 한계, 데이터확인, 인터럽트및예외처리, 결함완화등에대한변경 ) 이악영향을유발하지않음을평가한다. 9. 인증유지보수요구조건 (Certification Maintenance Requirement, CMR) 분석은소프트웨어변경으로인한새로운또는수정된 CMR이필요한지를결정한다. 1. 파티셔닝분석은변경이설계에통합된보호메커니즘에영향을주지않음을보장한다. 11. 기타 변경영향분석은변경이시스템또는제품의안전운용에악영향을줄수있는지를판단하여야한다. 다음은안전성또는운용에악영향을줄수있는영역이다. 1. 안전관련정보가변경된다. 가. 시스템안전성평가에의해식별된이전의위험요소가변경된다. 나. 시스템안전성평가에의해식별된고장조건분류가변경된다. 다. 소프트웨어레벨이변경된다. 특히새로운소프트웨어레벨이이전레벨보다높은경우. 라. 시스템안전성평가에의해식별된안전관련요구조건이변경된다. 마. 안전여유가감소한다. 2. 비행안전에악영향을줄수있는항공기의운용또는절차적특성의변경가. 항공기의운용또는감항특성이변경된다. 나. 비행승무원의절차가변경된다. 다. 조종사의작업부하가증가한다. 라. 상황인식, 경고, 경보가변경된다. 마. 비행의사결정을하는시현정보가변경된다. 바. 조립및장착요구조건이변경된다. 사. 다른장비와의장비호환성및 / 또는상호운용성이변경된다. 제정 :

41 아. CMR이변경되거나추가된다. 3. 비행안전에악영향을줄수있는기존시스템기능에새로운기능또는특성이추가된다. 4. 안전성에악영향을줄수있는쪽으로프로세서, 인터페이스, 기타하드웨어구성품또는환경이변경된다.(RTCA DO- 178B의 항참조 ) 5. 안전성에악영향을줄수있는쪽으로소프트웨어라이프사이클데이터 ( 요구조건, 코드, 아키텍처 ) 가상당하게변경된다. 가. 소프트웨어요구조건, 설계, 아키텍처, 코드구성품에대한변경 ( 특히안전관련기능, 파티셔닝, 중복, 안전성모니터등에영향을주는구성품 ) 나. 안전관련기능을수행하는코드 ( 소스코드, 목적코드, 실행가능목적코드 ) 구성품에대한변경또는안전관련기능을수행하는구성품에입력을제공하는구성품의변경 ( 이지침에서는안전관련기능이탐지되지않고잠재적으로중, 위험, 치명고장조건을유발할수있는기능을말한다.) 다. 실행가능목적코드에영향을주는개발환경특성의변경라. 메모리여유에악영향을주는메모리할당요구조건의변경 ( 예를들어, 5% 이하의여유가남을것 ) 마. 타이밍여유에악영향을주는타이밍요구조건의변경 ( 예를들어, 여유가예측불가하거나 1% 이하의여유가남을것 ) 바. 입 출력성능에악영향을주는입 출력요구조건 ( 버스부하와같은 ) 의변경 ( 예를들어, 5% 이하의여유가남을것 ) 사. 데이터및컨트롤흐름특성에악영향을주는데이터및컨트롤흐름특성의변경 ( 예를들어, 커버리지분석의 5% 이상이재수행되어야하는정도까지 ) 아. 인터페이스특성의변경 추가적으로, 다음사항이변경영향분석에서식별되어야한다. 1. 소프트웨어변경이요구조건, 설계, 아키텍처, 소스및목적코드, 추적성등을포함하여적절한라이프사이클데이터에통합된다는것을보증하기위해필요한갱신사항 2. 변경사항과시스템에악영향이없음을검증하는데필요한검증활동. 변경및비변경된소프트웨어가안전운용에대한요구조건을계속적으로만족하기위해변경영향분석에서시스템또는항공기의안전운항에악영향을줄수있는변경이어떻게검증되는지를다루어야한다. 이러한검증활동에는기존분석의재분석, 기존시험의재시행, 새로운시험절차와케이스 ( 추가기능도는이전에결함이있던시험에대한 ) 등을포함하여검토, 분석, 회귀시험, 요구조건기반의시험, 비행시험, 기타등이포함될수있다. 제 42 조 ( 변경영향분석절차 ) 인증당국은신청자가소프트웨어변경을중또는경으 로분류하는절차를정의하여따르도록하고, 이러한절차에대해검토, 피드백및 승인하여야한다. 최소한, 이러한절차는이행되기전에다음사항을언급하여야 제정 :

42 한다. 1. 경또는중의변경분류를정당화하기위해변경영향분석을사용하는신청자의절차및사용자가변경을분류하는데사용하는기준가. 변경영향분석의광범위성과형식성은변경의복잡성, 치명도, 광범위성에따라다양하다. 나. 신청자의문서에는변경분류에대한인증당국의합의를획득하기위해해당규정 ( 예를들어, KAR 21.93, , ) 에따른경또는중변경의분류가명시되어야한다. 2. 변경분류를검토하고승인하는신청자의절차 3. 경변경결정에후속되는절차 4. 중변경결정에후속되는절차 5. 제안된모든소프트웨어변경과분류를인증당국에게통보하는절차 6. 제안된분류에대한인증당국승인을획득하는절차. 인증당국이소프트웨어변경분류절차를승인한후에는신청자가제안된모든소프트웨어변경에대해그절차를따르도록한다. 승인된절차와의차이는인증당국의동의가필요하다. 인증당국은신청자가인증당국이승인한소프트웨어변경분류절차를갖고있지않는경우, 신청자로하여금소프트웨어변경이계획된경우인증당국에게이에관한정보를제공하도록하여야한다. 이러한경우, 신청자로하여금다음활동을수행하도록하여야한다. 1. 이장의제41조를사용하여변경영향분석을수행한다. 2. 이장의제41조에서언급한변경영향분석과안전성영향에기반하여변경에대한중또는경분류를제안하고, 분류에대한인증당국의피드백과동의를구한다. 3. 안전성영향의부재및 / 또는변경의제한된범위에대한근거와변경을검증하는방법으로제안된경분류를지원한다. 인증당국이신청자의데이터와근거자료에동의한이후, 신청자는더이상의인증당국의감독없이경변경에대해서진행할수있다. 4. 중변경에대해서는적절한문서를인증당국에제출한다. 경변경의경우, 개발절차에대한인증당국감독은관련규정에대한중 / 경결정을하는것에관한신청자의변경영향분석절차및관련기준의승인과주기적검토가관여되어야한다. 일단변경전략과변경그자체가수행되었으면, 전략과변경영향분석은 SAS에문서화되어야한다. 새롭고, 변경되었으며, 재사용한소프트웨어라이프사이클데이터또한 SCI에서식별되어야한다. 경변경의경우, 관할인증당국에 SAS와 SCI를제출하는것은인증당국과의협의에따르도록하여야한다. 1. 해당하는경우, 인증당국은변경분류절차와회사의절차준수를감독하는것에관여하여야한다. 2. 제작사가경으로분류하고아직인증당국이수락하지않은변경을포함하는장비는인증당국이그분류를수락할때까지비행항공기에장착해서는안된다. 중변경의경우, 인증당국은신청자의 PSAC 또는변경영향분석데이터의요약 제정 :

43 및변경문제를처리하기위해제안된전략을검토하여야한다. 일단변경전략과변경그자체가완료되었으면, 인증당국은전략과변경영향분석결과가 SAS에문서화되는것을보증하여야한다. 또한새롭고, 수정되었으며, 재사용하는소프트웨어라이프사이클데이터는 SCI에식별되어야하고, 인증당국 ( 중변경을승인하는권한을갖은경우 ) 에제출하도록하여야한다. 제 12 장소프트웨어라이프사이클데이터재사용의승인 제43조 ( 재사용에적합한소프트웨어 ) 적절하게계획되고준비되었다면, 소프트웨어라이프사이클데이터는한프로젝트에서다음프로젝트로최소의재작업을통해재사용될수있다. 재사용에적합한예시아이템은다음과같은것들이포함된다. 1. 소프트웨어계획과표준 2. 툴검정데이터 3. 소프트웨어라이브러리 4. 소프트웨어요구조건, 설계, 코드, 검증절차, 검증결과 5. 형상항목 RTCA DO-178B를사용하지않은프로젝트는이장에서기록되지않은추가적인고려사항이있을수있다. 인증당국은사례별로추가적인고려사항들을평가하여야하며신청자가지침을위해지역인증당국과연락을취하도록하여야한다. 인증당국은항공기컴퓨터소프트웨어의인증당국, 해당분야전문가등필요한조직과조율하여야한다. 제44조 ( 안전성고려사항 ) 인증당국이소프트웨어라이프사이클데이터의재사용이수락가능하다고판정하면, 더이상의설계승인이필요하지않다. 재사용승인고려사항 에서인증당국이소프트웨어재사용을승인할지를좌우하는고려사항을설명한다. 재사용승인고려사항 다음과같으면인증당국은재사용을승인. 재사용이다음과같으면인증당국은재사용을승인하지않음. 1. 최초의시스템안전성여유에악영향을주지않는다. 2. 안전성이정당한증가로구현한경우외에최초의운용성능에악영향을주지않는다. 1. 안전성에악영향을준다. 2. 이전승인된데이터또는파라미터의범위를초과한다. 3. 장비성능특성을초과한다. 제정 :

44 제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을검토하여신청자에게제안서가수락가능한지여부를적절한근거와함께통지하여야한다. 제정 :

45 제 13 장공급업체관리등 제47조 ( 공급업체감독 ) TC/STC/TSOA 신청자가시스템및소프트웨어를개발, 검증, 인증활동에공급업체또는하부공급업체를활용하는경우에는이조항을적용한다. 신청자는공급업체또는하부공급업체가인증프로그램에적용되는규정, 정책, 지침서, 표준등에부합하도록감독계획및절차를수립하여야한다. 다음은적용되는문서의예시이나, 이것만으로한정하지는않는다. 1. 감항기술기준 2. 국토해양부고시및훈령 3. 시스템, 하드웨어, 소프트웨어개발에적용되는신청자의표준 ( 요구조건표준, 설계표준, 코딩표준포함 ) 4. 신청자의품질보증계획, 절차, 프로세스 5. 신청자의형상관리계획, 절차, 프로세스 6. 시스템공급업체의표준, 계획, 절차, 프로세스 7. 소프트웨어변경영향분석에대한신청자의프로세스 신청자의인증계획서또는소프트웨어인증계획서 (PSAC) 에서신청자가공급업체또는하부공급업체의활동을어떻게감독할지를기술하여야한다. 여기에는상용소프트웨어구성품의공급업체도포함한다. 신청자는프로그램초기에이러한계획을인증당국에제출하여승인받아야한다. 계획을변경하는경우, 신청자는인증당국에게검토할시간을주어야한다. 신청자는공급업체관리계획또는다른적절한계획문서에서다음사항을기술하여야한다. 인증당국은이러한사항들이계획서에설명되어있는지검토한다. 1. 규정, 정책, 계획, 표준등에대한적합성 : 신청자는계획서에서모든적용문서가공급업체또는하부공급업체에전달, 조율, 합의되는방법을제시하여야한다. 2. 통합성관리 : 신청자는계획서에서시스템구성품의통합방법과소프트웨어및통합시스템의확인및검증책임자가누구인지기술하여야한다. 가. 요구조건의구현, 관리, 확인방법 ( 안전성요구조건, 파생요구조건, 요구조건변경포함 ) 나. 설계통제및승인방법다. 통합시험환경의관리방법라. 소프트웨어빌드및배포프로세스의관리방법 ( 신청자와공급업체의배포전략차이점은일치시킨다 ) 마. 인증요구조건을보조하는제품보증활동의대상및그이행자바. 시스템통합및검증에대한신청자의전략 ( 요구조건-기반시험및구조적커버리지분석포함 ) 3. 문제보고및해결 : 계획서에는문제보고서를추적하는시스템을구축하여야한다. 여기에는신청자와공급업체간에문제를보고하는방법이설명되어야한 제정 :

46 다. 문제보고시스템은문제가해결되고, 그보고서와변경사항이형상관리시스템에기록되도록보증하여야한다. 4. 통합검증활동 : 계획서에서공급업체가적용문서에적합하도록검증활동을수행하는지통합검증활동의책임자가누구인지식별하여야한다. 5. 형상관리 : 계획서에서모든소프트웨어라이프사이클데이터의형상관리를돕는절차와툴을기술하여야한다. 공급업체와형상관리가어떻게유지되는지도기술하여야한다. 6. 적합성입증및자료보관 : 계획서에는공급업체가적합성을입증하고자료를보관하는것을신청자가확인하는방법을기술하여야한다. 계획서에는최소한다음인증자료가설명되어야한다. 가. 적합성이입증되었다는증거나. 검증및확인자료다. 소프트웨어라이프사이클데이터 신청자의공급업체관리계획 ( 또는그와동등한계획 ) 에서는신청자의프로세스와공급업체의프로세스사이에라이프사이클데이터의이관에대해기술하여야하고, 요구조건관리, 문제보고, 표준사용, 변경영향, 검토등을포함하여모든프로세스에서의확인및검증에대해설명하여야한다. 계획서에서인증자료는한국의시설에보관되거나인증당국이접근할수있음을명확히언급하여야한다. 혼동을피하기위해, 인증자료는한국어 ( 또는영어 ) 로작성되도록한다. 제48조 ( 소프트웨어문제보고 ) 소프트웨어를포함하는항공기시스템의개발과정에서탐지되는문제를관리하는책임이 TC/STC/TSOA 신청자의공급업체또는하부공급업체에있을경우이조항을적용한다. 소프트웨어문제관련하여일관되게보고 / 해결하기위해, 신청자는소프트웨어형상관리계획서또는동등문서에서공급업체또는하부공급업체의문제보고프로세스를어떻게감독할것인지기술하여야한다. 다음사항이언급되어있는지확인하여야한다. 1. 문제가보고, 평가, 해결, 실행, 재검증 ( 회귀시험및분석 ), 종결, 관리됨을보증하는신청자의공급업체또는하부공급업체의문제보고프로세스를기술하여야한다. 계획에서는시스템에서사용하는소프트웨어, 데이터베이스, 데이터항목, 전자파일및항공기에장착하는장비에관련한모든문제를고려하여야한다. 2. 계획서에서는문제보고서를분류하는방법을수립하고, 각문제보고서는이에따라분류하여야한다. 가. 안전성에대한잠재적영향, 기능, 성능, 운용, 설계보증등을가지고문제를분류한다. 나. 인증전에해결할것과인증이후로연기할수있는문제로분류다. 문제해결유예를수락할수있는기준을정의하여야한다. 제정 :

47 3. 계획서에서는안전성, 성능, 기능및운용특성, 소프트웨어보증, 적합성등에영향을줄수있는문제에대해신청자의공급업체또는하부공급업체가신청자에게보고하는방식을기술하여야한다. 가. 신청자는자체의문제보고및추적시스템에문제를등록할수있다. 이런경우, 달성되는방법을계획서에기술하여야한다. 공급업체의문제보고시스템이신청자의시스템과호환되지않는경우, 문제보고시스템사이의전환을검증하는프로세스를계획서에기술한다. 나. 신청자는자체의문제보고시스템에공급업체또는하부공급업체가접근하도록할수있다. 이렇게하는경우, 신청자는공급업체또는하부공급업체의문제보고서를적절하게접수 / 관리한다는보증에도움이된다. 신청자가이를허용하는경우, 적절한형상관리유지를위해접근을제한하고, 문제보고시스템의적절한사용을위해공급업체를교육하여야한다. 다. 계획서에신청자의문제보고시스템에등록되기전에신청자의공급업체또는하부공급업체가후속조치기록또는신청자의검토및승인을위해사용할툴을명시하여야한다. 라. 계획서에신청자가모든문제를파악할수있도록공급업체는하나의문제보고시스템만을보유하도록명시하여야한다. 마. 다른적용에영향을주거나또는시스템전반에영향을줄수있는문제는적절한분야로표시하여야한다. 4. 계획서에서는개별공급업체또는하부공급업체의문제해결프로세스에대한검토에비행시험, 인적요소, 시스템, 소프트웨어, 기타엔지니어가참여하는방식을기술하여야한다. 또한, 담당엔지니어가문제보고서검토위원회및변경통제위원회에참여하는방식을설명하여야한다. 5. 계획서에서는신청자가인증이후로연기하도록제안하는미해결문제보고서의수락을결정하는데사용하는문제보고서검토위원회및변경통제위원회의기준을수립하여야한다. 가. 위원회에서는안전, 기능, 운용에대한미해결문제보고서의잠재적영향을고려하여야한다. 나. 다수의미해결문제보고서는소프트웨어가완전히성숙되지못하고그보증에의문이있다는것을나타내기때문에, 신청자는형식증명이후까지연기될수있는문제보고서에대해상한또는예정일을수립하는프로세스를설명하여야한다. 다. 계획서에서는인증이후로연기될수있는미해결문제보고서를해결하는시한결정방법을수립하여야한다. 이러한방법은신청자, 공급업체, 하부공급업체에의해생성된문제보고서에적용한다. 인증담당자는 TIA 및인증전에미해결문제보고서에관련된의사결정에참여하여야한다. 인증담당자는다음과같은일을수행한다. 1. 인증이후로연기하고자제안하는문제보고서를검토한다. 이러한검토에는비행 제정 :

48 시험, 시스템, 기타전문가가필요할수있다. 안전에영향이있다고우려된다면, 특정문제보고서의연기를불허할수있다. 2. 신청자가이전개발소프트웨어 (PDS, Previously Developed Software) 를사용한다면, 신청자가인증된항공기또는시스템의기준선에대한잠재적영향성에대해미해결문제보고서를재평가하였는지확인한다. 3. 신청자가다중미해결문제보고서의상호연관성을고려하여다른관련문제보고서와연계하여고려했을때보다문제보고서가더치명적인지평가하였음을확인한다. 4. 신청자가 AD, SB, 운용제한및다른필수시정조치와관련된미해결문제보고서를검토하였는지확인한다. 5. 인증당국비행조종사가시험비행에참여하기전에, 운용제한및절차가필요한지결정하기위해잠재적안전성또는운용영향과함께미해결문제보고서를검토한다. 6. 신청자가 DO-178B 11.2(j) 항에적합함을확인한다. 제49조 ( 항공용시스템데이터베이스및항공데이터베이스의확인 ) 신청자의항공용시스템또는장비가항공데이터베이스또는항공용시스템데이터베이스를활용하는경우이조항을적용한다. 1. 항공데이터베이스 : 항공용시스템에사용되는것으로, 일반적으로개발프로세스는 RTCA DO-2A(standards for processing aeronautical data), FAA AC 2-153(acceptance of data processes and associated navigation databases), FAA order (how to evaluate and accept process for aeronautical database supplier) 의지침을사용하여승인된다. 2. 항공용시스템데이터베이스 : 항공용시스템에사용되는것으로, 항공기또는엔진형식설계의일부로승인된다. 이러한데이터베이스는실행코드에의해실행되어경로에영향을줄수있고, 소프트웨어구성품및기능을활성또는비활성화하는데사용될수있고, 항공기형상에따라소프트웨어계산을조절할수있으며, 계산데이터로사용될수있다. 이러한데이터베이스의보증은통상 RTCA DO-178B 항공용시스템및장비소프트웨어프로세스의환경에서획득된다. 신청자및항공용시스템공급업자는항공데이터베이스가해당규정및인증당국지짐에적합하다는것을보증하기위해다음사항을확인하여야한다. 1. FAA AC 절또는 RTCA DO-2A의요구조건에적합한항공데이터베이스에대한수락가능한방법에서제공하는지침을따르는지확인한다. 현재유형 2의 LOA(Letter of Acceptance) 는항공데이터베이스가장착적격성과사용운용승인의도움으로 DO-2A에적합하다는증빙을제공한다. 2. 항공데이터베이스가 RTCA DO-2A( 부록 B), FAA AC 2-153, 기타수락가능한방법 (FAA order 참조 ) 을사용하여해당보증수준의요구조건을만족하는지확인한다. 제정 :

49 신청자및항공용시스템공급업자는항공용시스템데이터베이스가해당규정및인증당국지짐에적합하다는것을보증하기위해다음사항을확인하여야한다. 1. 신청자의항공기및시스템안전성평가를검토하여, 개별항공용시스템데이터베이스에대해다음사항을검증한다. 가. 데이터베이스를사용하는개별시스템에대해데이터베이스오류및훼손가능성이고려됨나. 각데이터베이스에대해적절한소프트웨어레벨이할당됨다. 시스템및항공기또는엔진에대해오류또는훼손이야기할수있는최악의잠재적위험요소에대해할당된소프트웨어수준에기초하였음. 라. 식별된위험요소와할당된소프트웨어레벨이인증당국과협의됨. 2. 개별데이터베이스는 DO-178B 또는다른수락가능한방법을사용하여해당소프트웨어레벨에맞게보증되고, 기능소프트웨어, 시스템, 전체항공기환경에서다음사항을검증하여확인한다. 가. 데이터베이스소프트웨어레벨에적절한검증커버리지수준이달성됨. 이러한것은요구조건-기반시험, 데이터만제공하는데이터아이템의데이터커플링분석, 소프트웨어실행에영향을받는데이터아이템에대한제어커플링분석등의조합으로달성할수있다. 나. 각데이터베이스에대한신청자의제안검증커버리지기준을검토하여인증당국이동의함 ( 동의하지않으면근거자료를제공함 ). 다. 소프트웨어실행영향등을포함하여, 데이터베이스에대한강건시험조건을적용하였음을확인함. 항공및항공용시스템데이터베이스에대해다음과같은조치를적용한다. 1. 개별데이터베이스에대해현장로딩가능한소프트웨어의로딩절차를검토한다. 데이터베이스전송및매체오류, 로딩및내용오류, 데이터베이스부품번호와항공기시스템또는탑재소프트웨어사이의오류, 사용중데이터베이스내용또는메모리의훼손등을탐지하는안전장치를확인한다. 2. 규정된시간이내에서사용하는것만이데이터베이스의내용이유효하다면, 데이터베이스갱신을위해유지보수지침및적절한제한사항을제공함을확인한다. 3. 신청자가각데이터베이스갱신에대한프로세스를제공하는지확인한다. 프로세스에는 STC, 경미한변경 ( 개조수준변경 ), 시스템부품번호변경, 소프트웨어부품번호변경등과같은감항성승인및 / 또는사용허가를획득하는방법이포함되어야한다. 이프로세스에는할당된자체부품번호를갖는데이터베이스를언급하여야하고, 데이터베이스는작동소프트웨어의일부로간주됨도설명하여야한다. 제 5 조 ( 소프트웨어개발및검증환경관리 ) 신청자가타깃컴퓨터를완전하게대표 하지못할수있는소프트웨어개발및검증환경을사용하는경우이조항을적용한 다. 신청자는소프트웨어개발및검증환경의형상관리를수립하여유지하고, 그 제정 :