페이퍼요약 - 자동차 시스템의 모델 기반 테스팅 by Bringmann

제목: 자동차 시스템의 모델 기반 테스팅(Model-based Testing of Automotive Systems)

저자: Eckard Bringmann 외 2인, 독일, Industry

문서유형: 컨퍼런스 페이퍼(총 9 페이지), 2008년

 

자동차 시스템 모델 기반 테스팅에서 요구되는 이슈들을 기술하고, 모델 기반 테스팅 방법인 TPT에 대하여 소개한 자료

---

배경

• 자동차 산업 분야에서 소프트웨어 기반 장치의 비중이 몇 년 사이 20%에서 80%로 급격히 증가
• 향후 10년 내 자동차 시스템 기능의 90% 이상을 소프트웨어가 결정할 것으로 예측됨(자동차 산업 분야에서 소프트웨어 중요성 증가)
• 자동차 시스템 개발에 모델 기반의 개발 방법론 적용 증가

모델 기반 자동차 시스템 개발의 장점

• MATLAB/Simulink, Statemate, MatrixX, LabView와 같은 모델 기반 기술은 자동차 도메인에서 가장 중요한 데이터 타입인 ‘지속적인 신호와 이벤트(continuous signals and events)’를 처리 할 수 있는 강력한 메커니즘 제공
• 개발 프로세스 초기에 시뮬레이션이 가능한 상위 레벨 모델이 개발됨(자동차 개발은 소프트웨어 공학, 전자 공학, 기계 공학 등의 여러 분야에 걸치는 작업이므로 그래픽 모델과 모델의 시뮬레이션을 통해 설계 초기에 엔지니어들간의 커뮤니케이션과 상호 이해를 돕는데 기여)
• 비즈니스 중심의 설계와 특정 기술에 종속적인 구현을 분리하여 효율성 증대(컴포넌트 재사용으로 시장 출시 기간 단축)
• 모델 기반 개발은 시스템 엔지니어가 가상 환경에서 시스템을 테스트 하도록 해준다. 코드가 실제 작성되기 이전 또는 최종 하드웨어(ECU)에 통합되기 이전이므로 결함 수정 비용이 낮음

과거의 임베디드 디바이스(자동차) 테스팅

약 15년 전에는 임베디드 디바이스 테스팅이 아래와 같은 4개 주요 영역으로 구성되었으며, 기능 복잡도가 비교적 낮았기 때문에 별도의 전담 기능 테스트 방법들은 필요하지 않았다.

①     전자 호환성(electromagnetic compatibility): EMC 테스트라고도 함

②     전기 테스트(electrical tests): 예, short-circuit, creeping current, stress peaks

③     환경 테스트(environmental tests): 예, 극도의 기후 조건 아래서 테스팅

④     필드 테스트(field tests): 지상, 도로에서 확인

자동차 시스템 모델 기반 테스팅의 이슈들

자동차 산업분야에서 모델 기반 테스팅(model-based testing)은 모델 기반 개발 프로젝트에서 이루어지는 모든 테스팅 활동을 지칭한다. 자동차 시스템의 모델 기반 테스팅 요구사항으로 아래와 같은 것들이 있다.

 

테스트 자동화(Test automation)

소프트웨어, 하드웨어, 전자, 기계, 유압 부품(hydraulic parts)들의 복합체인 자동차 시스템 개발에서는 반복 프로세스를 통해 중간 단계 결과물(interim releases)들이 여러 차례 나온다. 즉, 개발 기간 동안 반복적인 테스트를 필요로 하므로 테스트 자동화가 필수적이다. 또한 동력 전달 시스템과 본체 시스템(power-train and chassis systems)에서는 마이크로초(μ-sec) 단위로 시간에 민감한 액션(time-sensitive actions)들을 매우 정확한 순서로 검증하는 테스트 시나리오가 종종 있는데, 이런 시나리오를 실행할 수 있는 유일한 방법은 자동화이다. 

통합 단계들간의 이식성(Portability between integration levels)

모델 기반 개발에서는 여러 단계의 통합이 존재하는데, 시스템의 기능은 통합 단계와 상관없이 일정하므로 관련된 테스트 케이스들도 통합 단계와 구현 전반에 거쳐 일관성을 유지해야 한다. 특히, 재사용을 최대화하기 위해서 모델 기반 개발 방법론의 테스트는 여러 통합 단계의 다양한 플랫폼들 간의 테스트 케이스 이식성(또는 재사용성)을 지원해야 한다. 아래는 자동차 시스템 개발 프로세스의 대표적인 통합 단계들이다.

 

①     Model-in-the-Loop(MiL): 모델링 프레임워크에서 모델과 그 주변 환경을 시뮬레이션 하여 개발 초기에 테스팅을 가능하게 한다.

②     Software-in-the-Loop(SiL): 임베디드 소프트웨어를 실제 하드웨어 없이 시뮬레이션된 환경에서 테스트한다. 테스트 되는 임베디드 소프트웨어와 시뮬레이션된 환경 모델(the simulated environment model)이 대개 동일 머신(윈도우즈나 리녹스 기반 데스크 탑)에서 돌아가며, 가상 환경이므로 실시간 환경의 재현은 하지 않는다.

③     Processor-in-the-Loop(PiL): 임베디드 컨트롤러가 하드웨어(ECU)를 장착한 임베디드 디바이스로 통합된다. 앞 단계인 SiL 테스트와 유사하지만 임베디드 소프트웨어가 실제 타겟 프로세서(또는 타겟 프로세서 에뮬레이터)를 구비한 타겟 보드상에서 돌아간다는 차이점이 있다.

④     Hardware-in-the-Loop(HiL): 소프트웨어가 최종 ECU 상에서 돌아가지만 ECU 주변 환경은 여전히 시뮬레이션이다. ECU와 주변 환경과의 인터페이스는 ECU의 디지털 및 아날로그 커넥터(the digital and analog electrical connectors)를 통해 이루어진다. HiL 단계 테스팅의 목적은 ECU의 하위 레벨 서비스와 I/O 서비스에 있는 결함을 찾아내는 것이다. 또한 부품 공급업자들이 납품한 컴포넌트의 인수 테스트(acceptance tests)도 이루어지다. HiL 테스팅에서는 ECU와의 커뮤니케이션이 실제 상황과 동일하도록 환경 모델의 실시간 동작이 필요하다.

⑤     Test rig: 임베디드 소프트웨어가 ECU 상에서 동작하며 주변 환경도 물리적 컴포넌트(전기, 기계, 유압)로 구성된다. 이 단계에서는 특수한 측정 장비나 기타 분석 툴이 자주 사용된다.

⑥     Car: 마지막 통합 레벨로써 최종 ECU가 실제 차(샘플 또는 생산 라인에서 나온 차)에 장착된다.

체계적인 테스트 케이스 설계(Systematic test case design)

여러 변수에 종속적인 물리적 컴포넌트들과 상호작용(interaction)하는 자동차 시스템은 복잡한 기능을 가지고 있으며, 전자/기계/유압 컴포넌트들에서 발생하는 오류를 발견하고 대응하는 오류 모드(failure modes) 핸들링 코드가 구현의 큰 비중을 차지한다. 따라서 중복은 피하면서 모든 관련 측면이 빠짐 없이 커버되는 체계적인 테스트 케이스 설계를 지원해야 한다. 또한 수백, 수천 개의 설계된 테스트 케이스를 관리할 수 있는 방법도 있어야 한다.

 

가독성(Readability)

자동차 시스템의 모델 기반 테스팅은 각각 다른 전문성을 가진 테스터, 시스템 엔지니어, 프로그래머의 협업이 필요하다. 모델 기반 개발의 기본 원칙은 개발에 관련된 모든 엔지니어들이 이해할 수 있는 공용 언어로 모델을 사용하는데 있다. 따라서 모델 기반 테스팅 산출물이 테스팅 전문가뿐만이 아니라 다른 관련자들도 이해가능한 가독성을 가져야 한다.

 

반응성 테스팅/폐쇄 순환 테스팅(Reactive testing / Closed loop testing)

테스트 케이스 실행이 테스트 대상 시스템이 현재 무엇을 하고 있는지에 종속적이다(즉, closed loop 상태에서 테스트 케이스가 run 된다). 이러한 reactive test case의 한 예로 엔진 컨트롤에서 엔진의 분당 회전(the revs per minute)이 특정 임계값을 초과할 때의 센서 failure를 시뮬레이션 하는 테스트 케이스가 있다. 여러 패러미터들의 복잡한 관계에 관련된 이벤트인지라 어젠 rpm 임계값을 초과할지 딱히 정해진 시점이 없기 때문에 이런 테스트 케이스를 모델링 하기 위해서는 시스템 종속성을 표현할 방법이 지원되어야 한다.

 

실시간 이슈와 연속 신호(Real-time issues and continuous signals)

앞에 언급한 듯이 HiL 단계 및 test rig 단계에서는 테스트 케이스를 실시간에서 동작시켜야 한다. 그렇지 않은 경우 커뮤니케이션에서(특히, 연속적으로 변경되는 신호 사이에서) jitter가 발생할 수수 있다. 인터페이스에서 타이밍의 아주 작은 차이도 시스템 동작에 큰 영향을 미칠 수 있고 결과적으로 추적성(traceability)과 재현성(reproducibility)에 문제가 된다. 또한 엔진 컨트롤 같은 곳에서는 시간 제약(the timing constraints)이 시스템 기능의 핵심인 테스트 케이스들이 있는데, 실시간 지원 없이는 이런 테스트를 수행하는 것이 불가능하다.

 

연속 신호 테스팅(Testing with continuous signals)

복잡한 기능과 인터페이스를 가진 자동차 제어 시스템은 연속적으로 변경하는 신호를 입출력 엔터티로 다루지만, 기존 테스트 방법들은 연속 신호를 다루는 시스템에 대해서는 제대로 지원하지 못하고 있다. 즉, 전통적인 테스트 방법들은 데이터 위주(data-driven)이고 연속 신호나 연속 타이밍 이슈를 표현할 방법을 지원하지 않는다.

TPT (Time Partition Testing)

• Daimler Software Technology Research에서 개발되어 여러 프로젝트에서 사용되고 있는 모델 기반 테스트 방법
• TPT는 체계적인 테스트 케이스 도출이 가능한 테스트 모델링 기법을 지원하고, 정확하고 간편하며 이식성을 가진 테스트 케이스 표현(representation of test cases)을 지원하며, 비실시간 또는 실시간 환경에서 자동화된 테스트 실행과 평가를 가능하게 하는 인프라스트럭쳐를 제공한다.
• 기존의 테스트 방법들과 구별되는 특징으로 TPT는 연속 동작(continuous behavior)에 대한 테스트 케이스 모델링 및 체계적인 테스트 케이스 도출을 지원한다.

TPT의 전반적인 테스팅 프로세스는 아래 그림과 같다.

테스트 케이스 설계(Test case design): 시스템의 기능적 요구사항을 기반으로 그래픽 테스트 모델링 언어(graphical test modeling language)를 이용하여 테스트 케이스를 도출하고 모델링 한다(즉, 블랙박스 테스트).

컴파일(Compiling): 테스트 케이스가 TPT-VM라 불리는 전용 가상 머신에서 실행되는 바이트 코드로 컴파일 된다. TPT에 맞추어 설계된 이 바이트 코드는 TPT 테스트를 자동화하는데 필요한 오퍼레이션(operations), 데이터 타입(data types), 구조(structures)들로 구성된다. 또한 테스트 예상 결과를 기술하는 평가 속성(assessment properties)들은 하나의 통합된 평가 스크립트(assessment script)로 컴파일 된다. 즉, 각 테스트 케이스에 대해 하나의 바이트 코드 표현과 하나의 평가 스크립트가 존재한다

테스트 실행(Test execution): 가상 머신(TPT-VM)이 테스트 케이스 바이트 코드를 실행한다. TPT-VM은 플랫폼 어뎁터(platform adapter)를 통해 테스트 대상 시스템과 지속적으로 커뮤니케이션 한다. 플랫폼 어뎁터는 테스트 런 동안의 모든 신호를 레코딩하는 역할도 담당한다. 테스트 모델링과 테스트 실행이 확실히 구분 되므로 MiL, SiL, PiL, HiL 등의 여러 다른 통합 환경에서 테스트를 동작시킬 수 있으며, TPT-VM이 실시간 run도 지원하므로 테스트를 실시간으로 수행하는 HiL 환경의 테스트도 자동화가 가능하다.

테스트 평가(Test assessment): 일차적으로 레코딩되는 테스트 데이터는 테스트 대상 시스템이 예상되로 동작하는지 여부에 대한 평가가 없는 단순 신호 데이터(raw signal data)이며, 이후 레코딩된 데이터를 컴파일된 평가 스크립트(the compiled assessment scripts)를 이용하여 자동으로 평가한다. 이러한 테스트 평가(test assessments)는 오프라인으로 수행되므로 실시간 제약(real-time constraints)과는 상관없다. 현재 TPT는 스크립트 언어로 Python을 사용한다(기존의 Python interpreter를 런타임 엔진으로 사용). 또한 신호 처리(signal handling), 신호 관찰(signal observation), 신호 조작(signal manipulation) 등의 작업을 간편하게 하기 위한 강력한 라이브러리가 제공된다,

보고서 생성(Report generation): 테스트 케이스 결과를 사람이 가독 가능한 형태로 기술한 보고서가 테스트 평가(the test assessment)를 통해 생성된다. 보고서에는 테스트 판정 결과(통과/실패/판단불가 등), 관련 신호 곡선, 데이터 테이블, 평가 결과를 설명하는 코멘트 등이 포함된다.

TPT 적용 사례

아래는 기존 자동차 ECU의 외부 헤드라이트 컨트롤러(exterior headlight controller: EHLC)의 간단한 예를 들어 TPT 방법을 설명하고 있다.

 

EHLC 기능 명세

[#1] ON, OFF, AUTO의 세 가지 상태(states)를 가진 스위치(a switch)가 존재한다.

[#2] switch == ON 일 때 헤드라이트가 켜진다.

[#3] switch == OFF 일 때 헤드라이트가 꺼진다.

[#4] switch == AUTO 일 때 차 주의의 밝기(ambient light)에 따라 켜지거나 꺼진다. 차 주위 밝기는 0%~100% 범위의 빛 센서에 의해 얻어진다.

[#5] AUTO 모드일 때, 깜박이는(flickering) 헤드라이트를 피하기 위해서 이력 커브(a hysteresis curve)와 접점안정화 시간(a debounce time)으로 헤드라이트 on/off를 통제한다(접점안정화 시간은 아래 #7과 #8 확인)

[#6] switch == AUTO인 상태에서 시스템이 시작할 때 헤드라이트는 주위 밝기가 70% 이하면 켜지고 이상이면 꺼진다.

[#7] AUTO 모드일 때, 차 주변 밝기가 적어도 2초 동안 60% 이하로 떨어지면 헤드라이트가 켜진다.

[#8] AUTO 모드일 때, 차 주변 밝기가 적어도 3초 동안 70%를 넘어서면 헤드라이트가 꺼진다.

 

EHLC 최상위 레벨 모델

모델 기반 개발에서 위 명세된 시스템을 MATLAB/Simulink 모델로 표현하는데, 아래는 최상위 레벨 모델을 보여준다.

테스트 케이스 설계

TC1: 이 테스트 케이스는 17초 동안 지속되며 스위치가 OFF에 있을 때 시작한다. 시작한지 2초 후에 스위치는 ON으로 바뀌며 10초 동안 그 상태를 유지하다가 다시 OFF로 변경된다. TPT는 아래 그림처럼 상태 전이 다이어그램(a graphical state machine notation)으로 테스트 케이스를 모델링 한다.

TPT는 테스트 자동화를 위한 구체적 정보들을 다이어그램에 추가하는데, 아래 그림처럼 상태(the states)에 간단한 등식(simple equations)을 그리고 전이(the transitions)에 타이밍 정보(temporal predicates)을 추가한다. 이 정보들은 대개 그래프 뒤에 숨겨져 있다.

각 상태는 EHLC 시스템의 입력 신호(input signals)가 어떻게 조작되어야 하는지를 기술하며, 신호들은 일정하거나 또는 시간이 흐름에 따라 지속적으로 변할 수도 있다. 이 테스트 케이스에서는 스위치 상태 변경이 시간에만 종속적이고 센서 입력 값에는 영향을 받지 않지만, 아래처럼 이러한 정보도 표현을 해 주어야 한다(정말 센서 값이 시스템 동작에 영향을 미치지 않는지 검증하는데 필요한 정보이다).

테스트 케이스 실행

이렇게 정의된 테스트 케이스는 특정 플랫폼에 종속적이지 않으므로 MiL, SiL, PiL, HiL 같은 TPT의 여러 통합 단계에서 실행 가능하다. 테스트 실행 동안 모든 인터페이스 신호(테스트 대상 시스템의 입력 및 출력 신호)가 레코딩 된다. 아래는 테스트 실행 동안 레코딩된 데이터의 예이다.

테스트 결과 확인

테스트 케이스 실행 결과로 테스트 대상 시스템이 예상대로 작동하는 것을 확인하였다(스위치가 절대 AUTO 상태가 되지 않으며, 센서 신호가 헤드라이트의 동작에 영향을 미치지 않고, 헤드라이트의 ON/Off가 스위치 상태에 동기화됨).

TC2: 또 다른 테스트 케이스로 TC1과 동일하지만 스위치가 ON 대신 AUTO로 바뀌어 1초 동안 유지되는 테스트 케이스를 들 수 있다. TC2의 실행 결과는 TC1의 결과와 거의 동일하지만 헤드라이트 신호가 항상 0 상태를 유지한다는 점이 다르다.

 

EHLC 컨트롤러의 테스트를 위해 이런 식으로 총 72개의 테스트 케이스를 도출함.

위에서 예로 들은 테스트 케이스는 비교적 간단하지만 실질적인 테스트 케이스는 많은 수의 변수(variants)들과 그들의 조합(combination)을 고려해야만 한다. 이를 체계적으로 수행하기 위해 TPT는 잘 알려진 테스트 케이스 설계 방법인 The classification tree method와 그 지원 도구인 CTE XL을 활용한다.