4. DO-178과 커버리지 분석 – FAQ 8가지 정리 (2)

(4)   인증을 지원하기 위해서 코드 커버리지 결과를 어떻게 사용할 수 있는가?   프로젝트를 위해서 코드 커버리지가 필수라면, 예를 들어 고객이 DO-178B/C 가이드에 대한 엄격한 준수를 필요로 하기 때문에 데이터를 모으기 위해 사용된 프로세스가 올바르게 수행되어 왔는지를 증빙으로 제공할 수 있는 것 또한 중요하다.   그 증빙은 툴이 결과를 만들고 있는 것들에 대해서 개발 환경의 범위 내에서 올바르게 수행하는 것을 보여야만 한다. DO-178B/DO-330의 경우에 다음 아이템들이 툴인증을 위해 추천된다.   -       PSAC(Plan for Software Aspects of Certification). 이것은 TQP와 TAS를 참조한다. (하단 참조) -       TOR(Tool Operational Requirements). 이것은 툴이 무엇을 하는지, 어떻게 사용하는지 그리고 사용되는 환경에 대해서 설명한다. -       TAS(Tool Accomplishment Summary). 이것은 TOR의 모든 요구사항이 검증되었다는 것을 보여주는 데이터의 요약이다. -       TVR(Tool Verification Records). 이것은 시험 케이스, 절차 그리고 결과로 구성되어 있다. -       TQP(Tool Qualification Plan). 이것은 툴인증에 대한 프로세스를 설명한다.   이들 아이템들은 두 가지 유형의 주요 증빙으로 구성된다.   -       일반적인 증빙. 이것은 툴 운영 요구사항을 정의하기 위해, 그리고 툴이 요구사항을 만족한다는 것을 증명하기 위해 툴벤더에 의해서 제공될 필요가 있다. -       특별한 증빙. 툴사용자는 툴이 특별한 환경에서 올바르게 동작한다는 것을 증명할 필요가 있다. 이상적으로는 툴벤더는 가능한 이 프로세스를 간단하게 하기 위한 지원을 제공해야 한다.

 

잘 모르는 상태에서 보면 질문과 답변이 뭔가 안 맞는 것처럼 보일 수 있다. 하지만 DO-178의 관점에서는 이것이 정답이다. 이해를 위해서 부연설명하자면 위의 답변에 앞서 아래와 같은 답변이 생략된 것으로 생각할 수 있다.

 

‘DO-178 인증을 위해서 코드 커버리지를 분석하게 된다. 이때 커버리지 분석툴을 사용해서 커버리지 결과를 얻게 되는데 만약 이 커버리지 결과를 DO-178 인증을 위한 공식적인 자료로 확인 작업 없이 그대로 제출한다면 툴의 결과물을 그대로 사용해도 문제가 없다는 것을 보장하기 위한 툴인증(Tool Qualification) 자료를 함께 제출해야 한다.’

 

필자가 임의로 적은 내용이긴 하지만 툴인증(Tool Qualification)에 대해서 이해하게 되면 위의 내용이 어떤 의미인지를 알 수 있을 것이다. 혹시 툴인증에 대해서 잘 알지 못하는 분은 필자의 다른 포스팅을 참고하기 바란다.

 

이런 배경을 이해하고 위의 내용을 보면 전체적으로 툴인증 증빙으로 어떤 것을 제출하느냐에 대해서 설명하고 있다. 그리고 그러한 증빙이 벤더 관점에서 제출할 부분과 인증을 지원하는 지원자 관점에서 제출할 부분이 다르다는 점을 설명한다. 하지만 너무 포괄적으로 설명하고 있어서 아무래도 이해하기가 쉽지 않을 것이다.

 

사실 툴인증에 대한 내용은 아래와 같이 DO-330이라는 별도의 가이드라인이 있고 그 분량은 거의 DO-178에 버금간다. 그것을 위의 답변으로 모두 커버하는 것은 불가능하다. 따라서 위의 답변은 어느 정도 배경 지식이 있는 사람이라야 이해할 수 있는 내용이므로 이 부분은 필자의 별도 포스팅을 참고하고 필요하다면 추가적인 학습이 필요할 것이다.

 

그림 10 DO-330 가이드라인

 

(5)   타겟상에서 측정하는 것으로 얻게 되는 추가적인 이점은 무엇인가?   당신이 소스코드를 instrument하고 타겟에서 어플리케이션을 실행할 때 당신은 단순히 코드 커버리지뿐만 아니라 다른 정보도 모으기 위한 문을 열고 있는 것이다. 예를 들면, 당신이 트레이스를 수집한다면 (즉, 실행되는 instrumentation 지점의 순서를 기록하는) 어떤 시험 케이스들이 특정 실행 경로를 실행했는지를 구분하는 것이 가능하다. 트레이스를 사용해서 코드를 통해 앞 뒤로 단계를 이동하는 것이 가능하다.   또한 만약 트레이스가 instrumentation 지점이 실행된 특정 시간을 기록한다면 시간 정보를 결정하는 것이 가능하다. 예를 들면, RapiTime은 다음을 위해서 사용될 수 있는 광범위한 시간 측정을 제공하기 위해 그런 정보를 사용한다.   -       실행 시간 측정 -       WCET(Worst-Case Execution Time) 계산 -       성능 최적화

 

사실 이 질문은 DO-178 인증을 받기 위한 관점보다는 오히려 개발과정에서 참고할 수 있는 내용이 아닌가 싶다. 그런 의미에서 이 부분은 RapiTime이라는 자사의 툴을 홍보하기 위한 의도(?)가 담긴 질문과 답변이 아닐까라는 생각도 들게 된다. 그럼에도 내용 자체는 모두 정확하고 충분히 참고할 만한 내용이므로 혹시 관련된 부분이 필요한 경우라면 위에서 나오는 이점을 활용하거나 RapiTime과 같은 툴의 사용에 대해서 고려해 볼 수 있을 것이다.

 

(6)   여러 개의 시험 결과를 어떻게 합치는가?   시험에 대한 당신의 접근은 다양한 서로 다른 시험으로부터의 커버리지 결과를 합치는 것에 의존할 지 모른다. 이것은 다음과 같은 것들로 인해서 발생할 수 있다.   -       당신의 전략이 타겟과 호스트 시험의 결합을 포함한다. -       당신은 서로 다른 시스템 모드를 반영하는 여러 개의 시험 케이스들이 필요하다. -       아마도 시스템 제약사항들은 당신이 한 번에 당신 시스템의 한 부분만을 instrument하도록 강요할 것이다. (이 이슈를 완화하기 위한 3번째 질문에 대한 충고를 고려하라)   이들 각각의 시험들을 개별적으로 커버리지 분석을 수행하고 그 결과를 수동으로 병합할 필요가 있을지 모른다.   더 좋은 접근법은 여러 개의 결과를 하나의 리포트로 합치는 것을 지원하는 툴을 사용하는 것이다.

 

앞서 구조적 커버리지 분석을 타겟에서 할 것인지 아니면 호스트에서 할 것인지에 대한 내용이 있었다. 이 질문은 결국 그것과 연결되어 답할 수 있는 부분이다. 현실적으로는 어느 한 쪽에서 모든 것을 수행하는 것이 불가능하다고 본다면 이 질문에 대한 답은 결국 사람이 수작업으로 일일이 하나씩 합치느냐 아니면 툴을 써서 간편하게 합치느냐의 선택의 문제라고 봐야 한다. 하지만 애초에 툴이 없이는 시험하는 것 자체가 거의 불가능하다고 본다면 결국 관건은 툴을 구매하는 비용이 문제라고 할 수 있다. 필자가 확인한 부분은 아니지만 아마도 VectorCAST나 LDRA 그리고 여기서 나오는 RapiCover 모두 분산된 시험을 합치는 기능을 지원할 것이다. 따라서 구조적 커버리지 분석을 위해서 기본적으로 요구되는 기능과 함께 반드시 이 질문에 해당하는 기능도 모두 포함해서 이를 툴에서 지원하는지를 먼저 확인한 후 비용에 맞추어 구매하는 것을 추천한다. 구매 옵션에 따라서 필요 없는 기능을 빼는 것도 있을 것 같기는 한데 판매자를 통해서 정확하게 확인해 봐야 할 부분이다.

 

(7)   누락되는 코드 커버리지는 어떻게 처리하는가?   어떤 상황에서는 100% 코드 커버리지를 달성하지 못하는 정당한 이유가 있을 수 있다.   예를 들면, 방어적인 프로그래밍 구성을 실행하기 위한 시험 케이스들을 만들 수 없을 수가 있다. 이런 경우에는 이 코드의 검증을 위한 대안 형식이 받아들여질 만한 것으로 인정될 수 있다.   그런 경우에 어떤 코드 커버리지 리포트이든 커버되지 않은 코드를 정당화하는 기능을 제공하는 것이 유용하다. 그러면 요약 리포트는 실행된 코드, 정당화된 (하지만 실행되지 않은) 그리고 정당화되지 않은 코드를 보여준다. 목표는 모든 코드가 정당화 혹은 실행되어야 한다.

 

코드 커버리지는 소프트웨어 레벨에 따라서 각각의 레벨에 맞는 100%의 결과를 보여주어야 한다. 그런데 현실에서 100%를 달성하는 것은 거의 불가능에 가깝다. 이 질문은 그런 경우에 대한 것이고 그에 대한 답이 필자의 예상보다는 간단하게 되어 있다. 아마도 상황에 따라서 대응 방법이 다양하게 나올 수 있는 부분이어서 전체적인 개념만 설명한 게 아닌가 싶다. 결과적으로 누락되는 부분은 어떤 식으로든 채워야 한다. 그 방법 중 하나가 DER이 인정할 수 있는 리포트로 대체하는 것이다. 그리고 그 방법은 커버리지툴을 판매하는 곳이라면 대부분 작성 방법에 대해서 지원을 해 줄 것이다. 툴을 구매할 때 반드시 체크해야 할 부분이기도 하다. 참고로 다음에 나오는 내용이 바로 그런 체크항목들을 정리한 것이다.

 

(8)   코드 커버리지 툴에서 확인해야 하는 것은 무엇인가?   항공우주 산업에서 항공전자 소프트웨어 팀과 함께한 우리의 작업으로부터 모아진 지식들을 대표하는 위의 내용들을 요약하면서 우리는 코드 커버리지 역시 다음과 같아야 한다는 것을 알게 된다.   -       당신의 프로젝트에 의해서 사용되는 특별한 해석을 포함해서 코드 커버리지의 모든 클래스를 지원해야 한다. -       호스트와 타겟 시험을 지원할 수 있어야 한다. -       낮은 메모리 환경을 포함하는 서로 다른 임베디드 환경에 맞아야 한다. -       부분적인 instrumentation을 지원해야 한다. -       가능한 인증 증빙을 가져야 한다. -       다른 클래스의 정보를 모을 수 있어야 한다. -       다른 시험으로부터 커버리지 리포트를 합쳐야 한다. -       실행되지 않은 코드에 대한 정당성을 지원해야 한다.

 

위의 내용은 커버리지 분석툴을 구매하려고 할 때 반드시 체크해야 할 부분을 보여준다. 최소한 기본적으로 이 정도는 담당자로부터 100% 지원 가능하다는 것을 확인받은 후에 다음 단계를 진행해야 한다는 말이다. 보통 억대가 넘는 툴의 가격을 생각하면 만약 하나를 빼먹고 나중에 확인해 보니 애초에 지원조차 안되는 상황이라면 지원되는 다른 툴을 비슷한 혹은 더 비싼 비용을 주고 추가로 구매해야 하는 결과가 될 수 있는 것이다. 한 마디로 재앙이 된다.

 

이 자료를 제시한 RapiCover라는 툴은 당연히 위의 내용을 100% 지원하고 있다. 다만 한 가지 고려할 점은 VectorCAST(한컴MDS), LDRA(모아소프트), 그리고 국산툴인 슈어소프트 제품의 경우 국내에서의 지원이 상대적으로 원활하기 때문에 기본적으로 한국인 담당자의 직접적인 지원을 받을 수 있지만 RapiCover는 비록 국내 판매 대행업체(Architect Group)가 있긴 하지만 다른 업체와 달리 주로 외국의 담당자가 직접 지원을 해주는 것으로 알고 있다. 따라서 언어적인 이슈와 빠른 혹은 원활한 지원의 이슈가 있을 수 있다. 위에서 언급되지 않은 가격에 대한 부분을 포함해서 이런 점도 고려해서 선택할 필요가 있다.