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

지금까지 살펴본 커버리지 분석에 대한 DO-178 가이드라인은 우리가 실제 커버리지 분석을 수행하기 위한 배경이 된다. 그런데 아무리 이런 배경을 완벽하게 숙지하고 있다고 하더라도 막상 실전에 들어가면 가이드라인에서는 전혀 언급하지 않았던 여러 가지 문제들과 의문점들을 마주치게 된다. 어쩌면 그것이 당연하고 실전에서 그런 부분들을 극복하는 것 역시 과정의 일부일 수 있지만 (가능하면 전문가의 도움을 받아서) 그런 사례들을 미리 살펴볼 수 있다면 예상치 못하게 마주치는 어려움들을 극복해 나가는데 조금이라도 도움이 될 것이다.

 

사실 구조적 커버리지와 관련된 자료들은 구글링을 하고 관련된 사이트를 통하게 되면 ‘넘치게’ 찾을 수 있다. 그 중에는 특히 커버리지 관련 도구를 판매하는 업체에서 제공하는 자료들이 상당히 많다. 문제는 그런 자료들 중 무엇을 볼 것인지, 그리고 그 내용을 어떻게 이해할 것인가이다. 사실 업체에서 제공하는 자료에는 아무래도 업체의 제품을 판매하고자 하는 의도가 녹아 있기 마련이다. 그럼에도 지금까지 필자가 자료들을 보면서 느끼게 되는 것은 그런 장삿속(?)을 고려하더라도 기본적으로 자료 자체가 사실과 데이터에 기반해서 제시하고 있고 일부 기술적인 설명을 포함해서 유용한 정보들을 많이 담고 있기 때문에 학습 자료로써의 가치는 충분하다고 생각된다. 그런 의미에서 필자가 확인한 자료들 중 도움이 될 만한 자료들이 정리되는 대로 수시로 소개하려고 한다.

 

첫 번째 소개자료는 RAPITA SYSTEMS에서 제공한 자료이다.

 

-       제목: Eight top code coverage questions for DO-178B/C

-       출처: RAPITA SYSTEMS LTD (https://www.rapitasystems.com/)

-       사이트에서 제공하는 Whitepaper (아래)

 

RAPITA SYSTEMS라는 회사는 필자와 인연이 있는 DER을 통해서 알게 된 회사이다. 그 동안 커버리지 관련 도구를 판매하는 회사로는 VectorCAST, LDRA 정도만 알고 있었는데 이 회사 역시 커버리지 도구를 포함한 다양한 도구를 판매하는 회사로 커버리지 도구와 관련된 좋은 자료들을 얻을 수 있었다. 본 자료는 커버리지 분석과 관련된 FAQ를 정리한 자료로써 질문과 답변들이 평소 필자가 가지고 있던 궁금증을 많이 반영하는 것들이어서 유사한 궁금증을 갖고 있는 분들에게는 도움이 될 듯해서 여기에 소개한다.

 

우선 8개의 질문 목록을 살펴보자.

 

우리말로 정리해 보면 아래와 같다.

 

(1)   코드 커버리지란 무엇인가? (2)   코드 커버리지를 타겟상에서 수행해야 하는가 아니면 호스트상에서 수행해야 하는가? (3)   타겟상에서 코드 커버리지를 수행하는 경우 직면할 수 있는 어려움은 무엇이고 어떻게 극복할 수 있는가? (4)   인증을 지원하기 위해서 코드 커버리지 결과를 어떻게 사용할 수 있는가? (5)   타겟상에서 측정하는 것으로 얻게 되는 추가적인 이점은 무엇인가? (6)   여러 개의 시험 결과를 어떻게 합치는가? (7)   누락되는 코드 커버리지는 어떻게 처리하는가? (8)   코드 커버리지 툴에서 확인해야 하는 것은 무엇인가?

 

하나같이 필자가 평소에 궁금해하고 지금도 확실한 개념을 잡지 못하고 있는 내용들이다. 이 참에 필자도 제대로 정리하고 넘어가 볼까 한다.

 

참고로 위의 질문들에 대해서 답변 역시 한 줄 정도로 간략하게 할 수 있으면 좋겠지만 답변할 내용이 그렇게 간단하게 요약될 성격의 것들이 아니다. 실제로 원문에는 배경 설명이 포함되어 제법 길게 답변된 경우가 많다. 원문은 생략하고 해석을 위주로 설명한다. 이전 절에서 가이드라인을 중심으로 정리한 내용과는 또 다른 설명들이 나올 텐데 결국은 모두 연결되어 있다고 할 수 있으며 관련 지식을 좀 더 확장할 수 있을 것이다. 필자의 해설도 일부 추가했다.

 

미리 언급하자면 원문은 본 포스팅에 포함하지 않았다. 혹시 원문을 확인하고 싶은 분들이라면 조금 수고스럽더라도 해당 사이트에 접속해서 whitepaper를 받는 과정을 거쳐야 한다. 필자가 받은 자료를 그대로 공유해도 되지만 저작권 문제가 있기도 하고 혹시 최신자료가 업데이트되었을 수도 있다. 그리고 이쪽 분야의 일을 하시는 분들이라면 그런 발품(?)을 팔아보는 것도 하나의 학습 과정이 아닐까 싶다.

 

그럼 하나씩 살펴보자.

 

(1)   코드 커버리지란 무엇인가?   구조적 커버리지 분석은 완전한 시험을 위해 중요한 검증툴의 하나이다. DO-178B/C는 요구사항 기반 시험을 소프트웨어 검증 프로세스의 중요한 한 부분으로 강조한다. 요구사항 기반 시험에서 상위와 하위레벨 요구사항은 소스코드와 그 소스코드에 대한 시험을 만들어 내는데 사용된다. 요구사항, 시험 케이스 그리고 소스코드 사이의 추적성은 다음을 증명한다.   -       각각의 요구사항이 하나의 시험 케이스를 가진다 -       모든 소스코드가 요구사항으로 추적 가능하다   시험 케이스가 실행될 때 코드 커버리지를 측정하는 것은 이 프로세스에서 필수이다. 이때 커버리지가 100%보다 적다는 것은 요구사항, 시험 혹은 둘 다에 대해서 추적할 수 없는 코드를 가리키는 것이다.   서로 다른 커버리지 기준은 시스템의 DAL(Development Assurance Level, Design Assurance Level이라고도 한다)을 반영하기 위해 커버리지 측정에 대한 엄격함의 정도의 차이를 허용한다.   구조화되고 잘 작성된 요구사항과 아키텍처로부터 직접적으로 만들어진 코드가 있게 되면 상위 그리고 하위레벨 요구사항의 완전한 세트로 현재의 코드 커버리지 기준의 많은 부분을 완전하게 만족할 수 있다.

 

코드 커버리지에 대한 이해는 단어 자체만으로는 직관적으로 전체 코드 중 얼마만큼을 커버(실행)하느냐 정도로 이해할 수 있는데 DO-178에서는 그것이 요구사항 그리고 시험과 직접적으로 연결되어 있다는 것을 이해하는 것이 중요하다. 위의 내용은 코드 커버리지의 의미와 함께 코드와 연결된 요구사항과 시험, 어느 하나라도 제대로 되어 있지 않으면 결국 코드 커버리지가 완전할 수 없다는 것을 설명하고 있다.

 

(2)   코드 커버리지를 타겟 상에서 수행해야 하는가 아니면 호스트상에서 수행해야 하는가?   항공전자 시스템과 같은 임베디드 어플리케이션에 대한 소프트웨어를 개발할 때 검증 활동은 호스트(on-host) 혹은 타겟(on-target)에서 수행될 수 있다. 타겟 시험은 어플리케이션이 배치될 (타겟) 하드웨어상에서 시험되는 것이다. 그것은 또한 호스트-타겟 시험 혹은 크로스 시험으로 불려지기도 한다. 호스트 시험은 호스트 컴퓨터(어플리케이션을 빌드하는데 사용되는 개발시스템 같은)상에서 어플리케이션을 시험하는 것을 의미한다. 이것은 또한 호스트-호스트 시험으로 불려지기도 한다.   ①    타겟 시험   어플리케이션을 타겟에서 시험하는 배경의 핵심 원리는 그것이 절대 실행될 것으로 의도되지 않은 환경보다는 설계된 환경에서 코드가 실행되는 것이다. 시험 결과는 일반적으로 호스트에서 평가되고 분석된다. 이것은 다음과 같은 이득을 가진다.   -       호스트에서 실행하는 것과 타겟에서 실행하는 것 사이에 존재하는 약간의 예상하지 못한 차이점인 “신뢰성갭”이 최소화된다. 이것은 결과적으로 검출되지 않는 에러를 발생하는 false-negative 에러, 잘못된 소프트웨어가 탑재되는 것 그리고 존재하지 않는 문제점을 찾느라 시간을 낭비하게 만드는 false-positive 리포트를 줄이게 된다. -       더 적은 “신뢰성갭”은 또한 시험이 엄격함의 적절한 레벨을 달성하는 것에 대한 논거를 인증당국에 더 쉽게 제공하게 만든다. -       모든 코드를 수행하기 위한 능력. 당신 코드의 일부는 호스트에서 실행할 수 없을지 모른다. (예를 들면 장비에 특정된 코드)   ②    호스트 시험   호스트 시험은 타겟 프로세서보다는 호스트 프로세서에서 실행할 어플리케이션 코드의 컴파일을 수반한다. 일반적으로 어플리케이션은 또한 다음 고려사항들 때문에 호스트 환경에서 동작하도록 어느 정도 조율할 필요가 있다.   -       타겟의 RTOS 보다 데스크탑 OS에서 실행하는 것은 다른 API 호출을 필요로 할 수 있다. -       만약 임베디드 어플리케이션이 라이브러리를 포함한다면 이들은 호스트에서는 사용할 수 없을 수 있다. (혹은 예를 들면 그래픽 라이브러리의 경우처럼 다를 수 있다) -       애매한/정의되지 않은 프로그래밍 언어의 특성 혹은 컴파일러 버그에 대한 대체 해석방법이 호스트와 타겟 사이의 서로 다른 동작을 유발할 수 있다. -       임베디드 어플리케이션이 호스트 시스템에서는 사용할 수 없는 특정 하드웨어 특성으로의 접근을 필요로 할 수 있다.   하지만 호스트 시험으로부터 발생할 수 있는 이점이 있다.   -       시험을 수행할 필요가 있을 시점에 타겟을 사용할 수 없을 지 모르고 혹은 제한된 접근만 가능할 지 모른다. -       “빌드-탑재-분석” 주기가 타겟 시험보다 더 빠를 수 있다. -       단위 시험에 적절하다. 테스트 하네스(Harness)는 방어 프로그래밍 기법이 사용되었을 때 조차도 100% 커버리지를 달성하는 데 사용될 수 있다.   ③    무엇을 고를 것인가?   호스트와 타겟 시험 사이의 선택은 비용/편리성 그리고 결과의 신뢰성 사이의 트레이드오프에 의해서 결정된다.   많은 경우에 있어서 양쪽 기법의 조합을 사용하는 것은 두 가지 이점을 제공한다.   -       호스트에서의 단위 시험과 시험 케이스의 개발은 빠른 공정이라는 장점을 제공한다. -       타겟에서의 시스템/통합 시험은 탑재될 코드가 의도된 환경에서 시험되었다는 신뢰를 제공한다.

 

호스트 시험을 할 지 타겟 시험을 할 지는 항상 고민되고 어려운 부분이다. 그리고 이에 대한 정답은 결국 마지막 부분의 설명이 핵심이다. 이상적으로는 모든 시험을 타겟에서 수행하는 것이 원칙이겠지만 원칙만 따지기에는 주어진 시간과 리소스의 제약이 너무나 많은 것이 사실이다. 현실적인 상황에 따라서 어쩔 수 없이 선택해야 하는 지점이 있는 것이다. 실제 개발현장에서 마주치는 부분이기도 한데 이때 어느 것을 선택하든 최소한 위에서 설명된 부분들이 미리 고려되는 것이 중요하다.

 

(3)   타겟상에서 코드 커버리지를 수행하는 경우 직면할 수 있는 어려움은 무엇이고 어떻게 극복할 수 있는가?   타겟에서의 코드 커버리지에 대한 가장 큰 도전 중 하나는 임베디드 시스템에서의 리소스 제약이다. 커버리지를 측정하기 위한 기본적인 접근은 메모리 버퍼로 태그를 작성하기 위해 소스코드를 instrument하는 것이다.   이런 접근은 호스트 기반 시험에서 진화했다. 오늘날 많은 상용의 코드 커버리지 솔루션들이 호스트 기반 접근으로 시작하고 그것을 임베디드 환경으로 이전하려고 시도하는 것은 명확하다. 이러한 접근은 데이터를 큰 RAM 버퍼에 저장할 필요가 있고 각각의 instrumentation 지점은 (실행시간을 증가시키고 코드 사이즈를 증가시키는) 많은 수의 명령어가 필요하다. 리소스 제약을 가진 플랫폼에서 이것은 어려움이 된다.   리소스 제약의 정확한 특성은 시스템마다 다르다. 데이터 영역이 한계가 있을 수 있고 혹은 코드 사이즈가 제약이 있을 수 있다. 다른 시스템에서 높은 CPU 사용율은 달성할 수 있는 것에 제약이 될 수 있다. 코드 커버리지 솔루션은 이러한 제약이 존재할 수 있다는 것을 인식해야 하고 그것들을 다루는 실행 가능한 방법을 제공해야 한다.   리소스 제약을 이야기하는 다음과 같은 많은 방법들이 있다.   -       대체 데이터 수집. 많은 경우에 있어서 커버리지를 기록하기 위해 내부 메모리 데이터 구조를 사용하는 것은 충분할 것이다. 하지만 이 데이터 구조를 저장하기 위한 공간이 충분하지 않을 때 혹은 이러한 접근의 실행 오버헤드가 너무 높다면 대체 접근이 가능해야 한다. 그런 접근의 한 가지는 I/O 포트를 통한 instrumentation 지점의 추적을 기록하는 것과 관련된다. 이것은 메모리의 큰 영역에 대한 필요성을 피하고 동시에 instrumentation 오버헤드를 일반적으로 1 ~ 2 기계어 명령어 수준으로 매우 낮게 만든다. 고성능 디버거(예를 들면 Nexus 혹은 ARM ETM 기반 추적 디버거) 또한 데이터 수집에 사용될 수 있다.   -       부분적인 instrumentation. 어플리케이션을 완전히 instrument하는 것 보다 특정 부분을 instrument하고 시험을 수행하고 전체 그림을 제공하기 위해 결과를 합치게 된다.   -       최적화된 instrumentation. 특정 커버리지 유형을 측정하는 것, 예를 들면 MC/DC는 상당한 메모리 오버헤드를 필요로 할 수 있다. 커버리지를 위한 임베디드 시스템을 instrument하는 것은 instrumentation이 어떻게 수행되는가에 대한 지식을 필요로 한다. 일단 셋업이 되면 커버리지 레벨이 정확히 어떻게 달성되는지와 필요한 instrumentation의 양 사이에 트레이드오프를 만드는 기회가 있다.

 

우선 이 질문은 당연히 자주 나오는 질문이기도 하지만 한편으로는 자신들의 제품(RapiCover)이 가진 장점을 어필할 수 있는 질문이기도 하다. 일단 이 업체의 주장으로만 보자면 특히 다른 어떤 제품(필자는 VectorCAST, LDRA 툴, Suresoft 툴 정도를 알고 있다) 보다도 적은 메모리를 사용하므로 타겟 리소스의 영향을 그만큼 덜 받는다고 할 수 있다. 실제로 타겟의 메모리가 너무 적은 경우 아무리 좋은 툴이라도 커버리지를 측정하기 위한 바이너리가 타겟의 허용된 메모리 사이즈를 넘게 되면 해당 툴을 사용하는 것 자체가 불가능해질 수도 있다는 점에서 이 부분은 DO-178 인증에 필요한 커버리지툴을 사용하기 위해서 반드시 고려해야 할 사항이다.

 

이어지는 내용은 다음 절에서 정리한다.