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

cast-12.pdf

CAST-12에서는 이 문서를 이해하기 위해서 미리 알고 있어야 할 내용과 정보들을 먼저 자세하게 설명하고 있다. 이번 절에서는 그에 대한 내용을 확인해 본다.

 

기본적으로 CAST-12는 인증당국(혹은 DER)이 어떤 식으로 감사를 진행해야 하는지를 구체적인 절차를 기준으로 설명하고 있다. 그리고 그런 절차를 제대로 수행하기 위해서 미리 파악하고 있어야 할 배경 지식 혹은 정보들을 아래와 같이 먼저 제시하고 있다.

 

a.     Purpose of structural coverage analysis b.     Summary of structural coverage analysis objectives c.     Identifying compiler-inserted object code d.     Verification of code that is not directly traceable e.     Clarifying a misconception f.      Compiler optimization g.     Summary of source code to object cod traceability analysis h.     Related information

 

해석을 보자.

 

a.     구조적 커버리지 분석의 목적 b.     구조적 커버리지 분석 목표의 요약 c.     컴파일러 주입 오브젝트 코드 구분하기 d.     직접적으로 추적할 수 없는 코드의 검증 e.     오해를 해소하기 f.      컴파일러 최적화 g.     소스 코드와 오브젝트 코드 추적성 분석의 요약 h.     관련된 정보

 

우리가 앞서 살펴본 내용들이 일부 포함되어 있는데 여기에서 복습한다고 생각하고 전체적으로 다시 한 번 확인해 보자.

 

a.     구조적 커버리지 분석의 목적

 

구조적 커버리지 분석의 목적이 기본적으로 요구사항 기반 시험을 통해 실행되지 않는 코드가 있는지를 확인하는 것이라는 점은 이미 설명한 바가 있다. 그리고 소프트웨어 레벨에 따라서 확인하게 되는 커버리지 분석의 기준이 다르다는 것도 이미 확인했던 내용이다. 그 부분을 다시 한 번 정리하면 아래와 같다.

 

-       레벨 A: statement, decision, MC/DC, Data and Control Coupling

-       레벨 B: statement, decision, Data and Control Coupling

-       레벨 C: statement, Data and Control Coupling

 

b.     구조적 커버리지 분석 목표의 요약

 

앞에서 설명한 것들은 아래와 같이 DO-178 가이드라인 부속물(ANNEX) A Table A-7의 objective 5에서 8까지의 내용과 일치한다. (정확하게 하기 위해서 CAST-12의 기준이 된 DO-178B에서 가져왔다)

 

그림 14 DO-178B ANNEX A Table A-7의 일부

 

특히 레벨 A 소프트웨어인 경우 직접적으로 추적할 수 없는 코드에 대한 추가적인 검증이 필요하다는 점도 확인했었다. CAST-12에서는 이를 ‘추적성 이슈’와 ‘검증 이슈’ 두 가지로 구분해서 설명하고 있다. 자세한 내용은 뒤에서 정리한다.

 

참고로 DO-178C 가이드라인으로 업데이트되면서 그와 관련된 내용이 아예 부록에 추가되었다. 즉 위의 5 ~ 8까지는 동일하고 9번으로 아래와 같은 항목이 추가된 것이다.

 

그림 15 DO-178C ANNEX A Table A-7의 일부(DO-178B와 비교해서 추가됨)

 

c.     컴파일러 주입 오브젝트 코드 구분하기

 

앞서 구분했던 ‘추적성 이슈’와 ‘검증 이슈’ 중 ‘추적성 이슈’에 대한 설명이다.

 

우선 이렇게 구분하는 것은 두 가지를 구분해서 볼 필요가 있기 때문이다. 예를 들어 컴파일러에 의해서 추가된 코드는 다른 코드들과 달리 추적을 할 수 없는 부분인데 그 자체를 하나의 이슈로 보는 것이다. 즉, ‘추적성 이슈’가 된다. 그리고 이것을 어떻게 검증할 지에 대한 부분은 그와 전혀 별개의 ‘검증 이슈’가 되는 것이다.

 

“추적성 이슈”에 대해서 DO-178 가이드라인 Section 4.4.2b에서는 아래와 같이 설명하고 있다.

 

해석을 보자.

 

b. 어떤 특성을 구현하기 위해, 일부 언어를 위한 컴파일러는 예를 들면, 초기화, 내장 에러 검출 혹은 예외 처리(6.4.4.2b를 보라)와 같은 소스 코드로 직접 추적할 수 없는 오브젝트 코드를 생산할 수 있다. 소프트웨어 계획 프로세스는 이러한 오브젝트 코드를 탐지하고 검증 커버리지를 보장할 방법을 제공해야 하며 적절한 계획문서에 그 방법을 정의해야 한다.

 

CAST-12에서는 ‘추적성 이슈’가 발생하는 원인과 추적성 활동 혹은 방법이 필요한 부분과 관련해서 다음과 같은 세 가지 행태로 정리하고 있다.

 

①    컴파일러가 추가한 코드

l  초기화 (4.4.2b)

l  내장 에러 검출 (4.4.2b)

l  예외 처리 (4.4.2b)

l  컴파일러 생성 배열 경계 체크 (6.4.4.2b)

 

②    언어적인 특성에 따라서 추적성을 탐지하기 어려운 부분이 있을 수 있음

l  레지스터 사용에 대한 최적화

l  루프 펼침(Loop Unrolling)에 대한 최적화

l  C++에서 다형성(Polymorphism)의 사용

 

③    “숨겨진” 라이브러리가 링크 시점에 포함될 수 있음

 

위에서 제시된 것들이 ‘추적성 이슈’의 대상들이며 모두 추적성 활동이 이루어져야 한다. CAST-12에서는 그러한 추적성 활동에 대해서 추가된 코드를 ‘찾아내고’ ‘구분하는’ 것이라고 설명하고 있다.

 

d.     직접적으로 추적할 수 없는 코드의 검증

앞에서 ‘추적성 이슈’를 정리했고 이제 그것을 확인하기 위한 ‘검증 이슈’를 확인해 보자. 우선 DO-178에서는 검증(Verification)에 대해서 다음과 같은 세 가지 방식을 모두 인정한다는 점은 다들 알고 있을 것이다.

 

-       리뷰(Review)

-       분석(Analysis)

-       시험(Testing)

 

따라서 위의 방식 중 현재 상태에서 적용 가능한 특정 검증을 통해서 앞서 추적성 활동을 통해서 ‘찾아내고’ ‘구분된’ 추가된 코드가 제대로 구현되었다는 것과 소프트웨어가 구동하는 동안에 잘못된 동작을 수행하거나 영향을 미치지 않는다는 것을 증명할 수 있어야 한다.

 

e.     오해를 해소하기

 

CAST-12에서는 다음과 같은 오해가 있다고 말하고 있다.

 

해석을 보자.

 

e. 오해를 해소하기: 만약 소프트웨어가 레벨 A이고 컴파일러 생성 오브젝트 코드가 직접 추적 가능하다는 것을 데이터로 증명할 수 없다면 DO-178B/ED-12B Table A-7에 있는 objective 7을 만족하기 위해 오브젝트 코드에 대한 MC/DC를 수행해야 할 것이라는 흔한 오해가 존재한다.

 

이것은 레벨 A 소프트웨어에 대해서 ‘추적성 이슈’를 해결할 적절한 방법을 찾지 못하는 경우에는 그 대안으로 오브젝트 코드(소스코드가 아닌)에 대한 MC/DC를 수행하면 되지 않겠느냐라는 잘못된 인식이 있다는 설명이다. 원문에는 이에 대해서 추가 설명이 되어 있긴 한데 필자가 판단하기에는 그 부분을 번역하는 것이 큰 의미가 없을 것 같아서 여기서는 생략한다.

 

솔직히 이 글을 보는 분들 중에 이처럼 오해를 할 분이 얼마나 될 지 모르겠다. 그런 상황까지 가는 경우가 되려면 그 이전 단계가 거의 완전하게 수행된다는 가정이 있어야 하므로 현실적으로는 이런 상황에 도달하는 것도 이런 오해를 하게 되는 것도 결과적으로는 거의 가능성이 희박하다고 봐야 한다.

 

어쨌든 여기서 말하고자 하는 것은 오브젝트 코드에 대한 MC/DC를 수행한다고 해서 ‘추적성 이슈’가 해결되는 것이 아니라는 점이다. 개념을 제대로 잡지 못하고 진행하다 보면 자칫 엉뚱한 작업으로 많은 비용과 시간을 소모할 수 있기 때문에 그런 것을 방지하고자 하는 의도로 제시된 내용으로 보인다.

 

f.      컴파일러 최적화

컴파일러 최적화는 또 다른 영역의 이슈로 CAST-12에서는 다루지 않는다.

 

참고) 컴파일러 최적화가 오브젝트 코드에 영향을 주는 것은 분명하다. 그래서 어찌 보면 CAST-12에서 언급해야 할 부분이 아닌가 싶은데 범위를 벗어난다고 설명하고 있다. CAST-12에서 초점을 맞추고 있는 ‘추적성 이슈’와 ‘검증 이슈’와는 별개의 이슈라는 것이다. 추후 관련된 자료가 확인되면 지금처럼 정리해서 공유할 예정이다.   참고로 필자가 컴파일러 최적화에 대해서 DER로부터 들었던 내용 중에는 특히 레벨 A 소프트웨어인 경우에는 컴파일러 최적화를 OFF 시키고 컴파일을 하도록 조언을 받은 적이 있다. 이는 컴파일러 최적화로 인해서 생길 수 있는 소스 코드와 오브젝트 코드사이의 차이를 최소화하기 위한 것이다.

 

g.     소스 코드와 오브젝트 코드 추적성 분석의 요약

지금까지 이야기한 내용에 대해서 요약하는 부분이다. CAST-12에서는 DO-178 인증 지원자들이 아래와 같이 세 가지 단계로 소스 코드와 오브젝트 코드 추적성 분석을 수행할 것을 제안하고 있다.

 

즉, 먼저 (1) 추가된 오브젝트 코드를 탐지 및 구분하고, (2) 그 코드의 기능을 정의하고 (3) 마지막으로 추가된, 추적성이 없는 코드 순서의 정확성을 검증하는 것이다.

 

다음 절에서는 지금까지의 내용을 바탕으로 전체적인 절차(Procedures)를 설명한다.