10. DO-178과 커버리지 분석 – Source Code to Object Code Traceability (3)

cast-12.pdf

지금까지 설명한 배경 지식을 바탕으로 CAST-12에서 제안하는 감사 절차를 확인해 보자.

 

(1)   CAST-12에서 제안하는 감사 절차

 

우선 누가 이 절차를 따라야 하는지, 즉 누가 CAST-12에서 설명하고 있는 내용을 이해하고 따라야 하는지에 대해서 다음과 같이 언급하고 있다.

 

위에서 보듯이 인증당국(Certification Authority)이 대상이다. 그리고 당연히 인증당국에서 지정한 사람(Designee)인 DER도 해당된다. 여기에 문서의 다른 곳에서 언급한 부분이긴 하지만 아래와 같이 지원자(applicant)에게도 충분히 참고가 될 수 있다고 말해주고 있다.

 

먼저 제시된 절차를 CAST-12에서 설명하는 순서대로 나열해 보자. 내용이 복잡하고 많은데 원문은 생략하고 해석으로만 정리한다.

 

a.     인증당국(혹은 가능하다면 지명자)은 MC/DC가 소스코드상에서 수행되는 레벨 A 소프트웨어에 대해서 소스코드에서 오브젝트 코드로의 추적성과 검증 접근법이 소프트웨어 계획(일반적으로 PSAC 혹은 SVP 혹은 둘 다)에 작성되어 있는지를 확인해야 한다. b.     인증당국(혹은 가능하다면 지명자)은 지원자(혹은 공급자)가 승인된 소프트웨어 계획을 따르는 지를 확인해야 한다. c.     레벨 A 소프트웨어에 대해서 인증당국(혹은 가능하다면 지명자)은 컴파일러, 링커, 라이브러리, 실시간 시스템, 운영시스템, 혹은 다른 방법으로 항공 소프트웨어 어플리케이션에 생성된, 소스코드 statement로 직접 추적할 수 없는 추가적인 오브젝트 코드를 탐지하고 구분하는 것을 지원자(혹은 그들의 공급자)가 수행해왔는지에 대한 분석을 확인해야 한다. d.     인증당국(혹은 가능하다면 지명자)은 추가적인 코드의 기능이 요약되고 문서화되었는지를 확실하게 해야 한다. 이들 분석은 여러 가지 형태가 될 수 있다. 몇 가지 예제 형식이 하단 Section 6.h에 작성되어 있다. e.     어떤 분석이든 인증당국은(혹은 가능하다면 지원자) 지원자가 대표적인 소스코드와 오브젝트 코드에 대해서 의도된 항공 시스템의 타겟 환경에 적용 가능하다는 것을 분석했는지를 확인해야 한다. 분석에 대한 컴파일러 옵션은 항공 소프트웨어 개발에 사용된 컴파일러 옵션과 동일해야 한다. f.      인증당국(혹은 가능하다면 지원자)은 지원자(혹은 그들의 공급자)가 시스템의 하드웨어와 아키텍처에 특화된 특성(예를 들면, 링커, 실시간 시스템, 운영 시스템 혹은 다른 방법들에 의해서 구현된 메모리 어드레싱)뿐만 아니라 프로그래밍 언어와 관련해서 사용된 특성을 고려했는지를 확인해야 한다. 추가되고 추적할 수 없는 오브젝트 코드의 구분과 동작 분석을 위해 사용된 대표 코드가 동일한 개발 환경에서 동일한 절차, 설정 그리고 소프트웨어 어플리케이션을 위해 의도된 빌드 명령어 그리고 의도된 항공 시스템의 타겟 환경에서 생성되었는지를 확인하기 위해 평가되어야 한다. g.     만약 추가적이고 추적할 수 없는 오브젝트 코드가 이 분석에 의해서 탐지되면 인증당국(혹은 가능하다면 지명자)은 이 추가된 코드와 관련된 검증 기록을 조사해야 한다. 그 기록은 프로그램의 동작 상황 내에서 추가된 코드의 받아들일 만한 동작이 무엇인지, 그리고 지원자 혹은 개발자가 그것을 어떻게 확인했는지를 증명해야 한다. 그 동작의 허용가능성은 분석 문서에서 포착된 동작의 요약에 기반할 것이다. 검증에는 시험, 분석, 리뷰 혹은 일부 조합을 포함할 것이다. h.     다음 단락은 컴파일러, 링커, 라이브러리, 실시간 시스템, 운영 시스템 혹은 다른 방법으로 추가된 코드의 동작의 허용가능성을 탐지하고 구분하고 규정하기 위한 두 가지 잠재적인 접근법을 설명한다. (특별히 컴파일러 복잡도가 증가하게 되면 다른 접근법이 있을 수 있다는 점을 유의하라)   (1)   완전한 프로그램의 수동 리뷰/분석 – 오브젝트 코드의 소스코드와 관련된 어셈블리 코드 리스트가 소스코드 statement의 실행에 필요한 것을 넘어서는 컴파일러에 의해서 추가된 코드를 탐지하기 위해 수동으로 조사(리뷰)될 수 있다. 인증당국은 분석/리뷰가 올바르게 수행되었고 추가된, 추적할 수 없는 구분된 오브젝트 코드가 요구되는 기능을 올바르게 구현한다는 확신을 얻기 위해 분석/리뷰 결과와 일부 대표 소스코드/오브젝트 코드 그룹을 조사해야 한다. 검증 기록의 허용가능성은 위의 Section 6.c ~ 6.g에 작성된 대로 결정되어야 한다.   (2)   사용된/구현된 프로그래밍 구성체의 완전한 셋(Set)을 분석 – 지원자(혹은 그들의 공급자)는 프로그래밍 연산과 라이브러리의 수를 프로그래밍 언어와 컴파일러 제공 라이브러리 기능들의 더 작은 서브셋으로 제한하는 코딩 표준을 프로그램 전반에 부과하기 위해 선정할 수 있다. 프로그래밍 연산은 프로그래머가 컴퓨터 프로그램을 개발하기 위해 언어의 룰내에서 결합하는 연산자(+, -, 등) 혹은 논리연산(루프, 비교, 등)과 같은 프로그래밍 언어의 컴포넌트이다. 만약 연산 프로그램과 라이브러리 함수들이 코딩 표준을 완전히 따른다는 증거를 제공할 수 있다면 인증당국은 서브셋에 대해서 수행된 분석을 받아들일 수 있다. 일단 현재 존재하는 모든 코드가 코딩 표준을 준수한다는 것을 보일 수 있게 되면 코딩 표준에서 정의된 구성체의 하나 혹은 더 많은 시험 조합이 생성되고 컴파일될 수 있다. (주의: 이것은 컴파일러 주입 코드의 모든 유형과 그들의 상호작용이 추적되고 따라가고 검증될 수 있다는 것을 가정한다. 만약 그렇지 않다면 이런 접근법은 유효하지 않을 것이다) 이러한 시험들의 결과는 그 이후에 조사되고 분석된다. 인증당국은 그 분석이 제대로 수행되었고 어떤 추가적인, 추적할 수 없는 코드가 확인된 기능을 올바르게 구현한다는 신뢰를 얻기 위해 그 분석과 일부 소스코드/오브젝트 코드 그룹을 조사해야 한다. 검증 결과의 수락가능성은 위의 Section 6.c ~ 6.g에 작성된 대로 결정되어야 한다. 시험 프로그램의 유효성을 만들기 위해 지원자는 분석결과와 실제 운용 프로그램으로부터의 일부 대표 코드 사이에 비교 결과를 문서화해야 한다. 그 대표 코드는 더 높은 추가 가능성, 추적할 수 없는 기능을 가질 것으로 보이는 복잡한 기능들(예를 들면, 소프트웨어 핸들링 배열, 라이브러리로의 잠재적인 숨은 호출, 예외 처리, 트랩 혹은 루프 구성체)로부터 선택되어야 한다. 대표적인 운영 코드는 시험 프로그램의 결론을 유효화해야 한다. 인증당국은 더 복잡한 기능들이 선택되었다는 것을 확인하기 위해 대표적인 운영 코드의 선택을 평가해야 한다. 그 비교 분석은 또한 시험 프로그램 분석의 결론이 운용 프로그램에 대해서 적용가능하고 유효하다는 것을 보장하는지를 조사해야 한다.   주의: 다른 접근법이 받아들여질 수도 있지만 적절한 인증당국 전문가들과 조율이 되어야 한다. 어떤 혹은 모든 접근법들은 검증 계획(혹은 적절한 다른 소프트웨어 계획)에 상세화되어야 하며 인증당국이 승인하도록 조율되어야 한다.   i.      인증당국은 프로그램 전체에서 컴파일러, 링커, 라이브러리, 실시간 시스템 혹은 운영 시스템에 대한 변경과 같은 소프트웨어 개발 및 운영 환경 요인이 리뷰, 분석 그리고 시험으로 고려되었다는 것을 보장해야 한다.   j.      인증당국은 만약 지원자가 현재 소스코드, 오브젝트 코드, 컴파일러, 라이브러리, 링커, 실시간 시스템, 운영 시스템, 하드웨어, 시스템 및 소프트웨어 아키텍처 그리고 운영 환경에 대한 사용성을 증명할 수 있다면 이전 분석에 대한 신뢰를 줄 수 있다.

 

상당히 많은 내용이지만 정확한 설명을 위해서 우선 전체 번역을 모두 실었다. 번역이 되긴 했지만 일단 너무 복잡하다. 이걸 좀 더 간략하게 정리해 보자.

 

a.     추적성과 검증 방법을 계획문서에 작성하기 b.     계획을 그대로 따르는지 확인하기 c.     지원자가 추가된 코드의 탐지, 구분을 하고 있는지 확인 d.     추가된 코드의 기능이 정의되었는지 문서 확인 e.     지원자가 추가된 코드가 타겟에 적용가능한지를 확인했는지 확인 f.      지원자가 추가된 코드가 타겟에 적용되는 동일한 환경을 고려해서 생성되었는지 확인했는지를 확인 g.     지원자가 발견된 코드를 실제로 검증했는지 확인 h.     추가 코드의 검증에 대한 두 가지 접근법이 있음 (1)   추가된 코드를 수동으로 리뷰/분석 l  최종 평가는 c ~ g를 통해서 결정   (2)   코딩룰을 정하고 분석한 후에 전체 프로그램이 그것(코딩룰)에 맞게 프로그래밍 되었는지 확인 l  최종 평가는 c ~ g를 통해서 결정 l  가장 복잡한 기능을 샘플로 선정해야 함 l  다른 방법을 사용하고자 하는 경우 먼저 인증당국과 협의해야 함   i.      개발, 운영 환경이 고려되었는지 확인 j.      이전 분석을 그대로 사용할 수도 있음, 단 현재와 동일한 적용이 가능함을 증명해야 함

 

최대한 단순하게 정리해 보았다. 결국 인증당국(DER)은 지원자가 제대로 수행했는지를 확인하는 것인데 그 확인을 무엇으로 하고 어떤 것에 초점을 맞추어야 하는지를 알려주고 있다. 시작단계에서 계획 문서를 작성한 후에 그 계획에 따라서 진행해야 한다는 부분은 특히 DO-178 인증에서 기본적으로 요구하는 프로세스이므로 항상 염두에 두어야 할 부분이다.

 

사실 앞서 해석해 본 내용을 포함해서 지금까지 설명된 것들에 대한 깊이 있는 이해가 없다면 위와 같은 간단한 정리가 별로 도움이 되지 않을 수도 있다. 하지만 결국 DO-178 인증을 위해서 알아야 할 내용이므로 일단 이런 정도로 정리만 해 두고 그 배경에 대한 부분을 CAST-12를 포함해서 다른 자료들을 여러 번 살펴보면서 이해하는 과정이 필요하다. 혹은 도구를 직접 사용해 보면서 관련 전문가로부터 이 내용을 포함해서 조언을 받는 것도 좋은 방법이 될 수 있다.