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

cast-12.pdf

커버리지 분석과 관련해서 FAA에서 발행한 또 다른 문서로 CAST-12가 있다.

 

그림 13 CAST-12

 

우선 제목을 보자.

 

“Guidelines for Approving Source Code to Object Code Traceability”

 

해석하자면 “소스코드와 오브젝트 코드 추적성의 승인에 대한 가이드라인”이다. 앞서 보았던 CAST-19가 DC/CC에 대한 이해에 초점을 맞춘 것이라면 이 문서는 인증당국 혹은 DER이 소스코드와 오브젝트 코드 추적성에 대한 감사를 어떻게 해야 할 지에 대해서 조언을 하는 문서이다. 참고로 ‘인증당국 혹은 DER’로 한정했다고 해서 이것이 DO-178 인증을 준비하는 사람, 즉 지원자(Applicant)에게 별로 도움이 안된다는 의미는 절대 아니다. 오히려 감사(Audit)의 관점과 진행 과정을 이해할 수 있으므로 무엇을 어떻게 준비해야 하는지에 대해서 좀 더 명확하게 파악할 수 있다. 또한 일부 구체적인 방법을 제시하는 부분도 있기 때문에 자신에게 맞는 실질적인 방법을 찾는 데에도 분명 도움이 될 수 있다.

 

먼저 CAST-12가 작성된 배경을 살펴보자. CAST-12가 작성된 배경을 설명하기 전에 짚고 넘어가야 할 부분이 있다. 바로 CAST-12 작성의 기준이 되는 부분이 DO-178 가이드라인 버전에 따라서 다르다는 점이다. 정확하게는 DO-178B와 DO-178C에 작성된 내용이 아래와 같이 똑같지가 않다. 이것은 CAST-12가 작성된 시점(2002년)에는 DO-178C가 아닌 DO-178B가 최신 버전이었고 따라서 DO-178B를 기준으로 작성되었기 때문이다. 10년도 넘는 시간이 흐른 현재는 DO-178C를 기준으로 인증을 받아야 하기 때문에 만약 DO-178C의 관련된 내용이 다르다면 CAST-12를 참고할 수 없을 수도 있다. 이것을 정확하게 확인하기 위해서 DO-178B의 내용과 DO-178C의 내용을 직접적으로 비교해 보기로 한다.

 

우선 실제 가이드라인의 내용은 아래와 같다.

 

[DO-178B]

 

[DO-178C]

 

각각을 해석해 보자.

 

[DO-178B] b. 구조적 커버리지 분석은 만일 소프트웨어 레벨이 A이고 컴파일러가 소스 코드 statement로 직접 추적할 수 없는 오브젝트 코드를 생성하는 경우가 아니라면 소스 코드상에서 수행될 수 있다. 그 다음에는 그렇게 생성된 코드 배열의 정확성을 수립하기 위해 추가적인 검증이 오브젝트 코드상에서 수행되어야 한다. 오브젝트 코드 내에서 컴파일러 생성 배열 경계 체크가 소스코드로 직접 추적할 수 없는 오브젝트 코드의 하나의 예이다.   [DO-178C] b. 구조적 커버리지 분석은 소스코드, 오브젝트 코드 혹은 실행가능한 오브젝트 코드상에서 수행될 수 있다. 구조적 커버리지 분석이 수행되는 코드 형식과는 관계없이 만약 소프트웨어 레벨이 A이고 컴파일러, 링커 혹은 다른 방법들로 소스 코드 statement로 직접 추적할 수 없는 추가적인 코드를 생성한다면 그렇게 생성된 코드 배열의 정확성을 수립하기 위해 추가적인 검증이 수행되어야 한다.   주의: “소스코드 statement로 직접 추적할 수 없는 추가적인 코드”는 소스코드 레벨에서 즉시 식별되지 않는 분기 혹은 사이드 이펙트를 주입하는 코드이다. 예를 들면, 이것은 컴파일러 생성 배열 경계 체크가 구조적 커버리지 분석을 위해서 소스코드 statement로 직접 추적할 수 있을 것으로 간주되지 않는 것이며 추가적인 검증이 되어야 한다는 것을 의미한다.

 

결론적으로 DO-178B와 DO-178C의 내용은 동일한 설명을 하고 있다. DO-178C에서 좀 더 상세하게 풀어서 설명하고 있을 뿐이다. 따라서 CAST-12는 DO-178B와 DO-178C에 관계없이 모두 참고하고 적용할 수 있는 문서라고 할 수 있다.

 

참고) DO-178은 뒤에 알파벳이 없는 DO-178에서 출발해서 DO-178A, DO-178B 그리고 가장 최신버전인 DO-178C로 버전이 업데이트되어 왔다. 이 중 DO-178B에서 DO-178C로의 변경은 일반적으로 가이드라인 자체의 변경된 부분은 그렇게 많지 않다. 즉, 본문의 대부분의 내용이 거의 동일하다는 말이다. 물론 정확하게 보자면 위와 같이 설명 자체가 일부 달라지는 부분이 있고 나중에 설명되겠지만 일부 추가된 항목도 있다. 하지만 그런 부분들 조차도 기본적인 개념 자체가 변경된 부분은 거의 없다. 그런 부분은 아예 아래와 같이 별도의 문서로 구분해서 제시하고 있다.   -       DO-330 (Tool Qualification) -       DO-331 (Modeling) -       DO-332 (Object Oriented) -       DO-333 (Formal Methods))   지금도 DO-178과 관련된 자료 검색을 위해서 구글링을 하다 보면 DO-178B를 기준으로 작성된 정보들을 많이 발견하게 된다. 이 경우 비록 DO-178B를 기반으로 작성했다고 하더라도 대부분 DO-178C에도 해당하는 내용이므로 참고하는 데에는 거의 문제될 것이 없다.

 

그럼 이제 CAST-12가 작성된 배경에 대해서 정리해 보자.

 

기본적으로 CAST-12는 앞서 정리한 DO-178 가이드라인 Section 6.4.4.2b에 대한 해석과 감사방법을 제시하기 위해서 나온 문서이다. Section 6.4.4 전체가 커버리지 분석에 대해서 설명하고 있는데 그 중에서 Section 6.4.4.2b를 어떻게 이해해야 하는지, 인증당국(DER)에서는 어떻게 감사를 수행해야 하는지를 설명하고 있는 것이다. 앞서 해석한 부분에서 다음과 같은 핵심적인 내용을 추려낼 수 있다.

 

-       구조적 커버리지 분석은 소스를 기준으로 수행한다

-       소프트웨어 레벨 A인 경우 소스코드로 추적할 수 없는 부분에 대한 추가적인 검증을 오브젝트 코드상에서 수행한다

-       컴파일러가 임의로 주입하는 코드의 예에는 배열 경계를 체크하는 코드가 있다

 

사실 컴파일러가 임의로 주입하는 코드라고 한다면 사람이 그 부분을 일일이 확인하는 것은 쉬운 일이 아니다. 그럼에도 안전을 최우선으로 하는 항공기의 경우에는 이렇게까지 해야 하나 싶을 정도로 높은 수준의 검증을 요구하는 것이 현실이다. 특히 레벨 A인 소프트웨어는 다른 레벨과 달리 반드시 이를 수행하고 인증당국(DER)에 증빙을 보여줄 수 있어야 한다.

 

CAST-12는 인증당국에서 그 증빙을 어떤 절차로 어떻게 확인하는지를 정리한 문서이다. 따라서 이러한 내용은 당연히 인증당국 뿐만 아니라 인증을 준비하는 지원자들도 반드시 알고 있어야 할 부분이다.

 

이어지는 내용은 다음 절에서 설명한다.