내장형 소프트웨어(Embedded software)와 전자기기(electronics)는 자동차 기술에서 점차 많은 부분을 차지하고 있다. 1970년에 자동차 부품 비용의 10% 정도였던 전자부품의 비율이 2010년에는 40%에 달할 것으로 예상된다.[1] 내장형 소프트웨어와 전자기기는 자동차의 기능 전반에 사용되어 핵심 기능들인 기계 및 유압 시스템을 대체하고 단순화시키고 있다. 이 기능적인 부분에는 자동차의 조향이나 제동 시스템 및 자동차의 편리성, 편안함과 안전성 측면에서 소비자 가치를 더해 줄 수 있는 능동 안전 시스템(active safety system) 또는 운전자 정보 시스템과 같은 첨단 기능들이 있다.

그러나 내장형 소프트웨어와 전자기기가 빠르게 발전하고 이 시스템에 대한 테스트와 검증 또한 난해해짐에 따라 품질 및 리콜과 관련한 문제가 발생하고 있다. IBM에 따르면, 자동차 제조사들은 소프트웨어 문제를 해결하는 데 1년에 20억에서 30억 달러를 지출하고 있으며, 미국의 자동차 보증 보상 요구의 약 32%가 소프트웨어나 전자기기 관련 문제라고 한다.

모델기반설계(Model-Based Design)는 차량 내장형 소프트웨어를 개발하는 방법으로 그 선호도가 점차 증가하고 있는데, 이는 모델기반설계가 설계와 디자인 및 구현 단계를 향상시키기 때문이다. 이제 내장형 소프트웨어의 품질을 향상시키고 테스트 및 검증 주기를 단축시키는 과제를 풀 수 있도록 도와주는 모델기반설계에 새로운 툴과 성능을 사용할 수 있게 되었다.

시험과 검증을 위한 모델기반설계
자동차전자 엔지니어들은 통상적으로 전자제어장치(Electronic Control Unit, ECU)에서 구동하게 되는 기능들을 개발하는데 모델을 사용한다. 이 모델기반설계에서 모델은 실행 가능 명세(executable specification)를 제공하고, 시스템의 동적 거동(dynamic behavior)을 분석하고, 시스템 구성요소나 고비용의 물리적 프로토타입들을 줄이거나 제거하는 환경적인 조건을 시뮬레이션하며, 알고리즘을 설계하는 등 다양한 방식으로 사용된다. 더욱이 이 모델로부터 자동 코드를 생성하는 것은 양산 ECU 소프트웨어를 구현하는 방법으로 수용되어 왔다. 향후 많은 자동차 관련 업체가 이 방법을 통해 회사의 내장형 제어 소프트웨어를 구현하게 될 것이다.

품질의 관점에서 볼 때 자동 코드 생성은 자동적으로 생성된 코드의 반복 품질(repeatable quality)은 물론, 분석과 시뮬레이션에 의한 설계 최적화를 통해 많은 도움을 주고 있다. 또한 코드는 HIL(Hardware-in-the-Loop) 시험을 할 수 있도록 시스템 구성요소 및 환경적 모델로부터 코드를 자동적으로 생성할 수도 있다.

이제 새롭고 향상된 접근방법들은 내장형 소프트웨어와 전자 장치들을 포함한 오늘날의 복잡한 내장형 시스템의 테스트 및 검증 활동을 촉진하고 향상시킬 수 있도록 동일한 모델들에 다양하고 강력한 방법으로 영향을 줄 수 있다. 이 방법들에는 요구사항에 기반한 테스팅 및 커버리지 분석, 그리고 테스트 생성이 있다.

요구사항 추적과 검토
CMM-I과 같은 대부분의 소프트웨어나 프로세스 표준들은 전 개발과정에 걸쳐 요구사항에 관한 설계의 양방향 추적성(traceability)을 요구한다. 실행 코드는 재배열과 검증이 가능하도록 설계까지 추적되어야 한다. 모델기반설계 툴들은 엑셀이나 워드, 요구사항 관리 툴 안에서 캡처된 요구사항들을 설계와 결합시킨다. 요구사항과 부합되지 않는 설계 요소가 표시되는 것과 마찬가지로, 설계가 충족시키지 못한 요구사항이 표시된다. 요구사항이나 설계가 변경되는 경우, 툴은 이로 인해 영향을 받게 되는 해당 설계 요소나 요구사항을 표시한다. 또한 자동 코드 생성기는 HTML 링크를 생성된 C 코드 안에 삽입하여 이를 실행 시 모델을 역추적 할 수 있도록 하는데, 이러한 기능은 안전이 중요한 시스템에 있어서 특히 중요하다. 이러한 성능들은 코드부터 요구사항까지 완전한 추적 경로를 제공한다(그림 1 참조).

 

                         [그림 1] 요구사항을 추적


요구사항을 설계에 연동시키는 것 외에 모델기반설계 툴은 설계가 어떤 요구사항을 충족시키는 지 확인하는 기능을 제공한다. 이러한 요구사항들은 설계 모델 안에서 프로퍼티(properties)나 어서션(assertion)으로 삽입되며, 포멀 메소드(formal-method) 알고리즘은 모든 유효한 상황에서 프로퍼티가 충족될 수 있는지 수리적으로 결정한다. 만일 프로퍼티를 위반하는 시나리오가 있다면 포멀 메소드 툴은 반대 사례를 생성하는데, 이는 시뮬레이션 안에서 사용할 수 있고 테스트 계획에 추가될 수 있다.

모델 스타일 점검
설계 단계에서 초기의 High-Level 모델은 실행에 필요한 특성을 포함하여 실행 목적에 알맞은 모델로 변형되는데, 이러한 것들에는 고정소수점 세부항목(fixed-point detail) 및 실행되지 않을 부분을 제거하는 것들이 있다. 소프트웨어 엔지니어들이 코드를 좀 더 쉽게 읽고, 테스트하고, 실행할 수 있도록 소스코드(source-code) 스타일의 가이드라인을 확정하는 것과 동일한 방법으로, 모델기반설계를 기반으로 작업하는 엔지니어들은 모델이 실행될 수 있고 모델을 이해하고 테스트하는 데 용이하도록 도와주는 모델 스타일 가이드라인을 확립한다.

워크플로우와 설계가 이미 존재하는 특성에 새로운 특성이나 수정 사항을 표현하는 여부에 따라 다음과 같은 두 가지 접근방법이 있다. 하나는 디자이너에게 애초부터 가능한 옵션들을 제한하는 것이고, 다른 하나는 변경이 되는 디자인의 특성을 고려하여 점검을 나중에 적용하는 것이다.

첫 번째 접근방법은 안전이 중요한 시스템이나 존재하는 실행(existing implementation)의 부분적인 변경과 같은 설계에서 빈번하게 사용되는데, 제약은 처음부터 적용된다. 통상적으로 이 전략은 기계를 제한하거나 설명하는 모델 구성요소의 제한된 서브셋을 정의하고, 툴에 의해 체계적으로 점검될 수 있기 때문에 각 디자인에서 수동으로 점검될 필요가 없는 고정소수점 양상(fixed-point aspect)들과 같은 다른 세팅과 구성을 설계(블록들이 어떻게 연결되는지)하는 데 기반을 두고 있다.

두 번째 접근방법은 개발 프로세스 말기에 가이드라인에 따라 모델을 점검하는 것이다. 이러한 방법으로 인해 디자이너들은 자유로운 설계를 시작할 수 있고 점차적으로 설계를 변경하여 견고하고 테스트 수행이 가능한 구현을 도모할 수 있다 이론적으로는 이러한 모델 점검은 모델링 환경 안에서 이루어지며, 개발자들은 문제를 신속하게 알리고 효율적이고 반복적인 방법 안에서 설계를 수정할 수 있다.

최근 툴들은 엔지니어링 팀이 모델 점검 규칙들을 정의하고 설정(customize)하게 하고, 이를 설계에 적용하고 예외사항들을 신속하게 생성할 수 있게 하고 있다.

모델 커버리지 분석 및 확인
모델은 실행에 앞서 소스코드 기반의 테스트와 함께 후반에 실행될 수 있는 일련의 유형들의 실행들을 수행하는 데 있어, 설계 초기 단계에서부터 기회를 제공한다. 엔지니어들은 제어기를 개발함에 있어 설계 통합성을 검증하고, 작동하지 않는 코드로 나중에 발견될 가능성이 있는 설계상의 미작동 부분과 같은 문제를 발견하는 것을 중요시 한다.

설계가 완전하게 작동하고 복잡하다는 것을 확인하기 위해 엔지니어들은 종종 철저하게 모델 시뮬레이션을 사용한다. 그러나 이러한 시뮬레이션은 시나리오가 실제로 작동할 때만 유용하게 쓰인다.

최소와 최대의 수치값을 사용한 시뮬레이션을 가동하는 모델 테스트는 오버플로우 조건이 일어나지 않는다는 것을 확인할 수 있도록 도와준다. 또한 시뮬레이션이 모든 설계 파트와 기능 및 설계 행동(design behavior)의 논리적인 부분을 작동시키는 것을 확인시켜 줄 수 있다는 점에서도 중요하다.

모델 커버리지 분석은 어떤 블록이나 상태가 시뮬레이션 과정에서 실행되고 그렇지 않은지 테스트 등의 누적 결과를 평가한다. 특정 유형의 커버리지 분석은 C나 C++, Ada와 같은 소스코드 언어 안에서 최적화된다. 그러나 이런 유형의 분석은 최근까지도 설계 단계에서는 적용할 수 없다.^[2]

수정된 컨디션/결정 커버리지(Modified Condition/Decision Coverage, MC/DC)는 안전이 중요한 시스템을 만족시키는 데 있어 가장 엄격한 커버리지 레벨로 간주된다. 이 커버리지 분석은 모델기반설계 안에서 사용할 수 있으며, 시뮬레이션 작동에 기반하여 실행된다. MC/DC가 시뮬레이션 툴 안에서 실행될 때에는 자동으로 모델에 커버리지 매트릭스를 로그하고 리포트한다(그림 2 참조). 그 결과 테스트 엔지니어는 설계 구조 안에서 테스트 시나리오의 완성도를 평가한다. 이러한 작업은 전 커버리지 안에서 효율적으로 도출될 수 있는 테스트의 일군을 정의하게 되는 것이다.


                  [그림 2] 요구사항-기반의 테스트 커버리지 분석

자동 테스트 생성
모델기반설계를 위한 새로운 일련의 툴은 모델 구조를 수치적으로 분석하고 패턴을 생성하기 위한 수학적 방법을 통해 MC/DC와 같은 조건으로 지정된 커버리지 목표를 충족시키는 테스트 유형들을 자동적으로 생성할 수 있게 된다. 이러한 구조적 분석은 실행이 불가한 모델을 파악할 수도 있는데, 이러한 모델은 설계, 구현 및 테스트 도중 누락된 부분이 있다는 것을 규명해 줄 수 있다.

이러한 테스트 유형들은 나중의 실제 실행과 더불어 시뮬레이션을 통해 철저하게 모델을 테스트하기 위해 요구사항, 테스트벤치 데이터, 몬테카를로 시나리오, 설비 및 환경 모델로부터 얻어진 다른 테스트 시나리오와 결합하게 된다.

코드 컴플라이언스 점검
MISRA(Motor Industry Software Reliability Association)는 “차량용 소프트웨어에 대한 C 언어 사용 지침서”를 출간했다. 일반적으로 MISRA-C라고 알려진 이 일련의 사용법은 점차 많은 자동차 제조사와 공급사들에 의해 채택되고 있다.[5] MISRA-C 컴플라이언스에 필요한 모델 점검 중 상당 부분은 생성된 코드를 모두 점검하는 것이 아니라 코드 생성 툴이 시스템적으로 생성하는 자동 코드를 점검하는 것으로 수행된다.

그러나 코드 생성 툴을 점검하는 것은 임포트된 수동으로 생성된 레거시 코드와 같은 경우 시나리오를 지정하지 않는다. 개방된 모델 인터페이스는 이러한 시나리오들을 자동 점검하는 데 사용된다. 이 접근방법을 사용함으로써 모델을 생성한 다음에 점검을 하게 되며, 코드를 생성하기에 앞서 임포트되거나 생성된 코드를 확인하기 위해 코드를 점검하게 된다. 또 다른 방법은 MISRA-C 코드 체커 또는 수치 분석 툴을 코드 생성에 포함시키고 프로세스를 만드는 것이다.

런타임 오류 탐지
런타임 오류는 모델 수준에서나 시뮬레이션 도중 때때로 탐지하기 어려우며, 이는 소프트웨어 개발이나 테스트 과정에서 심각한 문제를 불러일으킬 수 있다. 런타임 오류는 잠재적 오류로서 데이터 값의 특정 조합 내면에 존재하여 동적 테스팅 수행 시 검색 비용이 많이 소요된다. 사실, 런타임 오류는 작동기로 전달된 예상되지 않은 요구, 수치적 코프로세서 중단 및 설명될 수 없거나 재생산되기 어려운 소프트웨어 고장과 같은 것들을 포함하는 기능적 행동 상의 결과들을 통해 드러나는 것이 일반적이다. 이러한 경우, 긴 디버그는 비로소 문제의 원인을 추적하는 데 필요하게 된다.^[3]

정적 분석은 런타임 오류를 해결하는 하나의 접근방법이다. 최근 정적 검증 툴은 향상된 정적 분석 테크닉을 적용하는 것이나 수동 검사나 테스트를 필요로 하는 ‘false positive’ 결과 수를 줄이는 데 소개되어 왔다.^[4] 이런 툴들은 코드가 수동 혹은 자동으로 생성된 것에 관계없이 C 코드의 정적 및 동적 분석을 수행한다. 모델기반설계를 위해 이러한 검증 툴과 다른 툴들을 통합하는 것은 작업 과정에 중요한 개선점을 가져다준다. 자동 생성된 곳에서부터 분석된 코드와 모델을 연결함으로써 정적 검증 툴은 소스코드와 모델 양쪽에서의 결과를 나타낼 수 있게 된다. 코드로부터 모델로 진행할 수 있게 된 것은 변화를 만들고, 코드를 자동으로 재생산하고 재점검하게 하며, 상세하고 고급화된 관점을 사용하여 분석하고 디버그하고 수정할 수 있는 강력한 방법을 제공한다. 이러한 방법을 통해 개발 단계에서 코드에 직접 변경을 하지 않고 모델을 변경하여 프로젝트 수행 시 모델의 수명과 재사용 가능성을 높여준다.

마지막 고찰
이 글에 설명된 핵심 원리는 모델기반설계의 테스트 및 검증에 영향을 주는 최상의 세 가지 실행 방법을 보여준다.

첫째, 엔지니어들은 완성을 위해 모델을 테스트벤치로서 다시 사용해야 한다. 모델 시뮬레이션을 작동하는 것에서부터 모델에 반하여 연결된 소프트웨어를 실행하는 것, 호스트 컴퓨터나 타깃 프로세서를 작동하는 것, 테스트벤치 상에서 완전한 임베디드 시스템을 작동하는 데까지 엔지니어들은 개발 및 시험 과정에서 나중에 다시 사용될 수 있는 방법으로 지식, 테스트 데이터, 다른 정보들을 축적할 수 있다.

둘째, 엔지니어들은 가능한 한 초기에 빨리 테스트를 해야 한다. 리얼타임 전에 시뮬레이션 내에서, 실제에 적용해보기 전 벤치 상의 리얼타임 안에서, 또한 코드 생성 전에 모델을 테스트해 보아야 한다. 초기에 테스트하는 것은 종종 작업을 좀 더 쉽게 만들어주는데, 이는 분리 수준이 좀 더 높고 초기 오류 탐지의 비용 상 이점이 충분히 입증되어 있기 때문이다.

셋째, 엔지니어들은 이용할 수 있는 모든 테크닉을 사용할 수 있어야 한다. 시뮬레이션과 포멀 메소드는 시험과 검증을 완성하는 모델 기반 및 코드 기반에 영향을 미쳐야 하며, 이 모든 것은 툴 벤더 범위로부터의 모델기반설계와 함께 사용할 수 있어야 한다.
많은 자동차 원장비 제조사 및 공급사는 실행 가능 명세를 만들고, 그 성능을 시뮬레이션하고 자동으로 코드를 생성하기 위해 모델기반설계를 사용하고 있다. 이러한 회사들의 대부분이 테스트 및 검증 목적을 위해 이미 있는 모델에 영향을 미침으로써 다음 단계로 이동해 나가기 시작했다. 이 글은 품질을 향상시키고 자동차 내장형 소프트웨어 가격을 낮추는 데 사용되는 실질적인 방법을 설명하기 위해 현재 통용되고 있는 여러 가지 방법을 조사했다.

[참고문헌]
[1] Automotive Engineering International, 2005. 3
[2] B. 알드리치(Aldrich), “Using model coverage analysis to improve the controls development process,” AIAA 2002
[3] C. 호트(Hote), “Advanced Software Static Analysis Techniques that Provide New Opportunities for Reducing Debugging Costs and for Streamlining Functional Tests,” 초판.
[4] 위와 동일
[5] MISRA-C:2004, “Guidelines for the use of the C language in critical systems,” ISBN #0-9524156-2-3, www.misra-c2.com.