페이퍼요약 - 컴포넌트 기반 임베디드 시스템을 위한 테스트 케이스 설계 by Fleisch

제목: 컴포넌트 기반 임베디드 시스템을 위한 테스트 케이스 설계(TEST CASE DESIGN FOR THE VALIDATION OF COMPONENT-BASED EMBEDDED SYSTEMS)

저자: Wolfgang Fleisch, 독일

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

 

ECU와 하드웨어 컴포넌트가 아직 가용하지 않은 개발 초기 단계에 임베디드 시스템 제어 소프트웨어를 테스트 하는 방법을 기술한 자료. 임베디드 시스템(예, 자동차)의 유스케이스로부터 테스트 케이스를 설계하고 시뮬레이션을 통해 해당 테스트 케이스를 실행하고 확인함

---

임베디드 시스템

• 임베디드 시스템은 기술적인 시스템에 내장된 제어 시스템(control systems)을 의미하며, 특정 입력 값에 대하여 그 반응인 액션(actions)을 계산하도록 설계된다.
• 대개 마이크로컨트롤러 기반의 ECU(electronic control unit)에 의해 작업이 수행되고, ECU는 감지기(sensors)와 구동기(actuators)를 통해 자신의 환경과 의사소통 한다.
• 분산 임베디드 시스템은 통신 네트워크를 통해 정보를 교환하는 ECU들의 네트워크로 구성됨. 분산 임베디드 시스템의 전형적인 예가 오늘날의 자동차로서 거의 모든 종류의 제어/감독 기능(예, 안티블로킹 브레이크 시스템, 트랜스미션 콘트롤, 연료 주입 등)이 분산 ECU들에 의해 제어된다. 

임베디드 시스템 제어 소프트웨어의 컴포넌트 기반 개발

• 특정 임베디드 시스템을 위한 신규 애플리케이션 소프트웨어가 구성가능한(configurable) 소프트웨어 컴포넌트들의 집합으로 구성됨을 의미. 기성 컴포넌트(components off the shelf)를 사용하여 거의 완전한 ECU 하드웨어가 개발되는 일이 흔한 반면 사전정의된 소프트웨어 컴포넌트를 가지고 제어 소프트웨어를 설계하는 것은 상대적으로 새로운 접근 방법임
• 컴포넌트와 컴포넌트 모델을 적용하는 것은 개발 시간 감소나 제어 소프트웨어의 품질 증가 같은 장점을 가져옴. 즉, 개발 동안 이미 폭 넓게 테스트된 사전 제조(prefabricated) 컴포넌트 사용이 고품질 달성을 가능하게 하고, 컴포넌트 모델에 의해 제공되는 일정한(uniform) 통신 및 실행 메커니즘은 잠재적인 설계 에러 수를 감소시킨다.
• 제어 소프트웨어 구축에 사용된 컴포넌트들은 컴포넌트 인터페이스 간의 커넥션(connections)에서 이벤트와 데이터를 교환함으로써 정보를 교환한다.

컴포넌트 기반 제어 소프트웨어 테스팅의 어려움

1) ECU 및 제어되는 하드웨어 컴포넌트의 가용성 문제

• 임베디드 시스템을 위한 제어 소프트웨어는 실시간 요구사항, 분산, 복잡도 증가의 특징을 가지며, 개발된 컴포넌트 기반 제어 소프트웨어의 기능 요구사항과 실시간 요구사항을 테스트 하는 것은 어려운 작업이다.
• 제어 소프트웨어 테스팅을 위해서는 ECU, 제어되는 하드웨어 컴포넌트(controlled hardware components), 실시간 데이터 모니터링을 위한 특수한 디버깅 기기 등이 필요함. 하지만 하드웨어 컴포넌트(예, 차 또는 차의 일부분)와 ECU가 소프트웨어 개발 초기에는 종종 가용하지 않아 개발되는 제어 소프트웨어의 테스팅이 지연되게 만든다. 이는 제어 소프트웨어의 설계 에러 발견이 늦어지게 하며 결과적으로 에러 수정 비용을 증가시키고 프로젝트 일정이 지연되게 만든다.
• 이런 이유로 개발 단계 초기에 컴포넌트 기반 제어 소프트웨어의 테스팅을 가능하게 하는 시뮬레이션이 활용됨 

2) 제어 소프트웨어에 사용된 블랙박스 컴포넌트의 관측성 문제

• 사전 제조된 컴포넌트의 품질은 개발 동안 광범위한 테스팅을 거쳐 검증되지만 이 컴포넌트로 새로운 제어 소프트웨어를 구축 시 그 정확성 수준이 원래의 단일 컴포넌트의 정확성 수준과 동일하다고 볼 수는 없다.
• 시뮬레이션 동안에 컴포넌트 기반 애플리케이션 구축에 사용된 블랙박스 컴포넌트의 내부 동적 동작을 모니터링 하는 것이 불가능 함. 하지만 시뮬레이션된 동적 동작이 소프트웨어 컴포넌트 간의 커넥션 상에서는 관측가능(observable) 하다.
• 컴포넌트 기반 제어 소프트웨어의 시뮬레이션을 실행할 때 연결된 컴포넌트 간에 교환되는 이벤트를 시뮬레이션 모델이 모니터하고, 이렇게 모니터되고 레코딩된 타임스탬프 이벤트를 테스트 케이스에 명세된 예상 이벤트 시퀀스와 오프라인에서 최종 비교함으로써 테스트가 가능해진다.

시뮬레이션을 위한 ASCET-SD 케이스 도구

• 본 논문에서 제안되는 테스트 방법은 ASCET-SD(Advanced Simulation and Control Engineering Tool – Software Development) 케이스 도구를 사용함
• ASCET-SD는 단일 ECU의 컴포넌트 기반 제어 소프트웨어 모델링 및 실시간 시뮬레이션을 가능하게 해 주는 도구. 예를 들면 컴포넌트 기반 자동차 제어 소프트웨어(automotive control software)의 모델링, 시뮬레이션, 타겟 코드 생성을 지원함
• ASCET-SD는 컴포넌트와 애플리케이션 모델링을 위한 여러 그래픽 및 텍스트 에디터를 제공한다. 즉, 컴포넌트의 내부 동작이 여러 다른 표기법(콘트롤 블록 다이어그램, 상태 머신 다이어그램, Java 기반 명세 언어, 표준 C 코드)으로 명세 될 수 있음
• ASCET-SD는 실시간 데이터 모니터링과 타임스탬프 이벤트의 레코딩을 지원한다.

[ASCET-SD를 사용한 컴포넌트 기반 제어 소프트웨어 모델링 예]

제안된 테스트 방법

1) 테스트 케이스 설계

• 본 논문에서 하나의 테스트 케이스는 ‘자극 시퀀스’와 ‘예상 출력 이벤트 시퀀스’로 구성되며, 이는 ‘RES(Required Event Sequence)’ 형식으로 표기됨
• 자극 시퀀스(stimuli sequence)는 시뮬레이션 모델을 활성화(trigger) 시키는 입력 이벤트의 시퀀스를 정의
• 시뮬레이션 동안 모니터된 이벤트 시퀀스는 ‘SES(Simulated Event Sequence)’ 형식으로 레코딩 됨
• SES가 RES와 일치하면 테스트 케이스가 정상 확인된 것이고, SES와 RES 간의 불일치가 발견되면 테스트 케이스가 잠재적 에러를 발견한 것임

2) 테스트 프로세스

본 논문에서 제안된 컴포넌트 기반 개발 및 테스트 프로세스는 다음 7단계로 구성된다.

①     사용자 관점의 테스트가능한(testable) 요구사항 수집을 위해 유스케이스 분석

②     유스케이스 시나리오를 확장 UML 시퀀스 다이어그램(즉, RES)으로 변환

③     컴포넌트 기반 제어 소프트웨어의 설계 및 모델링을 수행하고 실행가능한(executable) 시뮬레이션 모델을 생성

④     테스트 케이스를 완성하기 위해 자극 시퀀스(stimuli sequences)를 정의

⑤     시뮬레이션 모델에서 컴포넌트 간에 통신되는 이벤트를 레코딩하기 위해 테스트 케이스를 시뮬레이션 함

⑥     테스트 확인 및 에러 발견을 위해 SES와 RES를 오프라인 비교(offline comparison)

⑦     불일치(잠재적 에러)가 발견되면 컴포넌트 기반 제어 소프트웨어 또는 유스케이스를 수정

[제안된 테스트 프로세스]

Step 1: 유스케이스를 가지고 테스트가능한 요구사항 수집

• 유스케이스는 하나 또는 여러 액터(actor)가 특정 목표를 달성하기 위해 시스템과 상호작용하는 사용 상황을 일반화함. 하나의 유스케이스가 여러 이벤트 시퀀스(시나리오)를 커버할 수 있음
• 본 논문은 컴포넌트 기반 제어 소프트웨어의 동적 동작에 대한 테스트가능한 요구사항을 기술하기 위해 시나리오 주도의 모델링 관점인 유스케이스를 선택함(아래 그림과 같은 템플리트와 작성 규칙에 따라 유스케이스를 작성)
• 요구사항 레벨의 액터가 설계 레벨의 컴포넌트와 동일하지는 않지만 액터들 간의 이벤트 시퀀스(시나리오)를 시뮬레이션 모델의 컴포넌트간 이벤트 시퀀스와 매핑하여 비교 가능

[유스케이스 템플리트]

Step 2: RES(Required Event Sequence)로 변환

• 유스케이스가 구조적 형식으로 작성되기는 하지만 도구 기반 자동 테스팅을 수행하기에는 적합하지 않음. 요구사항의 테스트가능한 형식을 얻기 위해서 모든 유스케이스 시나리오가 확장 UML 시퀀스 다이어그램(즉, RES)으로 수동 변환된다.
• RES는 UML 시퀀스 다이어그램 표기법을 기반으로 하며 추가적으로 실시간 조건을 명세하기 위해서 확장됨. 두 이벤트 간의 타이밍 조건이 ‘최대 시간’, ‘최소 시간’, ‘시간 간격(interval time)’ 등을 통해 상대적으로 명세 될 수 있음
• RES의 그래픽한 명세는 자체 개발된 시퀀스 다이어그램 에디터에 의해 지원됨
• 이벤트 시퀀스의 요구되는 순서(order)와 타이밍을 명세한 후에는 매 RES 마다 아래와 같은 3개의 테스트 케이스 애트리뷰트가 설정됨
  i) 사전조건(precondition): 유스케이스 시나리오로부터 인계 받는 정보
  ii) 시퀀스타입(sequence type): 오프라인 비교를 위한 테스트 전략 선택 – 일반(normal), 강제(mandatory), 금지(forbidden)
  iii) 비교타입(comparison type): 이벤트 반복이 허용되는지 여부
• 시퀀스 타입 애트리뷰트가 ‘일반’인 경우 RES는 상응하는 SES에 대해서만 비교됨. 시퀀스 타입이 ‘강제’ 또는 ‘금지’인 경우 RES가 모든 SES에 대해서 비교됨. 만약 사전조건이 참(true)이 된 후에 ‘금지’ RES가 발생하면 이는 에러이다.
• 컴포넌트 기반 개발에서 컴포넌트가 동일한 이벤트를 주기적으로 전송하도록 설계될 수도 있음. 따라서 비교타입 애트리뷰트는 RES에서의 요구되는 이벤트가 레코딩된 SES에서 반복적으로 발생하는 것이 허용되는지 아닌지를 정의한다.

[RES 예]

Step 4: 자극 시퀀스(Stimuli Sequences) 도출

• 컴포넌트 기반 설계 모델이 개발되고 이것으로부터 실행가능한 시뮬레이션 모델이 생성된 후에는 테스트 케이스를 완성시킬 수 있다. 이벤트의 예상 출력 시퀀스는 이미 RES에 정의되어 있으므로 테스트 케이스를 완성하기 위해 자극을 주는 이벤트의 입력 시퀀스가 각자의 RES로부터 도출되어야 한다.
• 대개 RES 상의 첫 이벤트가 첫 자극 이벤트(stimuli event)가 된다. 아니면 이 첫 이벤트를 활성화(trigger) 시키는 다른 이벤트들이 자극 이벤트가 될 수도 있다. 또한 외부 액터(예, 스위치, 센서)로부터 전송된 RES의 모든 이벤트들이 자극 시퀀스의 자극 이벤트 후보들이다.

Step 5: 시뮬레이션 모델(Simulation Model)의 준비 및 실행

• 생성된 컴포넌트 기반 제어 소프트웨어의 시뮬레이션 모델로 테스트 케이스 시뮬레이션을 수행하기 위한 준비를 해야만 함. 아래 그림과 같이 ‘Test Driver’ 컴포넌트가 시뮬레이션 수행에 필수적인 보충물(supplements)들이 포함한다.
  - 환경 모델: 결여된 하드웨어 컴포넌트가 대개 반응 동작(reactive behaviour)을 가지므로 하드웨어 컴포넌트의 단순화된 환경 모델이 전체 시스템의 폐쇄 루프 제어 동작(closed loop control behavior)을 흉내내기 위해 시뮬레이션 모델에 추가됨
  - 자극 시퀀스: 여러 다른 테스트 케이스의 시뮬레이션 런(run)을 위해 자극을 주는 이벤트를 삽입
• 단일 ECU와 관련한 테스트 케이스 시뮬레이션을 위해 ASCET-SD 도구를 활용함. ASCET-SD는 제어 소프트웨어의 컴포넌트 기반 모델링 환경 뿐만 아니라 자극을 삽입하고 시뮬레이션 런 동안의 실시간 데이터를 레코딩 하는 편리한 시뮬레이션 환경을 제공한다. 타임스탬프 이벤트(Time stamp events)는 여러 다른 시뮬레이션 런에서 레코딩된 실시간 데이터로부터 오프라인으로 재구축될 수 있다.

[단일 ECU의 테스트 케이스 시뮬레이션]

Step 6 + 7: 오프라인 비교와 수정(Offline Comparison and Corrections)

• 오프라인 비교는 모든 시뮬레이션된 테스트 케이스에 대하여 SES와 상응하는 RES 간의 일치(conformance) 여부를 확인한다. RES의 모든 이벤트가 상응하는 SES에서 올바른 순서대로 발견되고 모든 타이밍 제약 또한 충족되면 일치가 확인됨. 시퀀스 타입이 ‘강제’ 또는 ‘금지’인 RES는 모든 SES에 대해서 테스트(비교) 되어야 한다.
• 유스케이스 모델과 시뮬레이션 모델 간의 이벤트명 매핑 테이블은 도구 기반 자동 체킹을 가능하게 하는데 필수적임
• 만약 오프라인 비교에서 불일치가 발견되면 컴포넌트 기반 설계 모델에(또는 명세된 유스케이스에) 존재하는 가능한 에러를 개발자가 조사하고 수정 해야 한다.
• 전형적인 설계 에러로 컴포넌트 간의 연결 결여(missing connections between components), 컴포넌트의 잘못된 패러미터 값(wrong parameter values of components), 시스템 레벨 상의 부적절한 동적 동작(improper dynamic behaviour on the system level) 등이 있다.

제안된 테스트 방법 적용 예: 자동차 와이퍼 콘트롤 시스템

• 자동차 와이퍼 제어 시스템은 분산된 차체 전자 시스템(a distributed body electronics system)의 한 부분이며, 컴포넌트 기반 제어 소프트웨어가 하드웨어 컴포넌트(비 강도 측정을 위한 비 센서, 핸들와이퍼스위치, 와이퍼 모터, 대시보드)들을 제어한다. 아래는 실험실 프로토타입 사진
• 이 제어 소프트웨어를 위한 테스트 케이스 설계와 실행에 제안된 방법을 사용함. 즉, 대부분의 하드웨어 컴포넌트가 가용하지 않은 개발 초기 단계에는 실시간 시뮬레이션과 오프라인 비교를 통해 테스트하고, 나중에 ECU를 제외한 실제 하드웨어 컴포넌트가 가용해지면 제어 소프트웨어의 루프 시뮬레이션에서 하드웨어가 실행됨

[자동차 와이퍼 제어 시스템(Automotive wiper control system)]

Step 1: 유스케이스를 가지고 테스트가능한 요구사항 수집

• 테스트 케이스 설계를 위한 시작점인 유스케이스 분석에서 일차적으로 16개 시나리오를 가진 4개 유스케이스가 수집됨
• 아래는 ‘앞 창 표준 와이핑’ 유스케이스의 메인 시나리오를 기술한 예

유스케이스 W.1	앞 창 표준 와이핑(Standard wiping front window)
목표	윈드스크린 닦기
사전조건	a) 와이퍼 모터(A3) off (와이퍼 모터 파킹 위치 센서(A2)의 상태 on) b) 와이퍼 모터(A3) on (와이퍼 모터 파킹 위치 센서(A2)의 상태 off)
사후조건	핸들와이퍼스위치(A1)의 위치가 wiper_off, 와이퍼 모터 파킹 위치 센서(A2)가 on
액터	드라이버(A0), 핸들와이퍼스위치(A1), 와이퍼 모터 파킹 위치 센서(A2), 와이퍼 모터(A3), 와이퍼 콘트롤(A4)
메인 시나리오	Step	Action
	1.1	사전조건 a)에서 드라이버(A0)가 핸들와이퍼스위치(A1)를 wiper_slow 위치로 변경
	1.2	핸들와이퍼스위치(A1)가 자신의 위치 wiper_slow를 와이퍼 콘트롤(A4)에게 전송
	1.3	와이퍼 콘트롤(A4)이 최고 지연 100ms 후에 속도 slow로 와이퍼 모터(A3)를 시작시킴
	1.4	드라이버(A0)가 핸들와이퍼스위치(A1)를 wiper_off 위치로 변경
	1.5	핸들와이퍼스위치(A1)가 자신의 위치 wiper_off를 와이퍼 콘트롤(A4)에게 전송
	1.6	와이퍼 모터 파킹 위치 센서(A2)가 on을 와이퍼 콘트롤(A4)에게 전송
	1.7	와이퍼 콘트롤(A4)이 최대 지연 20ms 후에 파킹 위치에 있는 와이퍼 모터(A3)를 속도 off로 멈추게 함

[‘앞 창 표준 와이핑’ 유스케이스의 메인 시나리오]

Step 2: RES(Required Event Sequences)로 변환

• 테스트가능한 형식을 얻기 위해 ‘앞 창 표준 와이핑’ 유스케이스의 메인 시나리오가 아래 그림과 같은 RES로 변환되고 다음과 같은 테스트 케이스 애트리뷰트가 설정됨
  - 사전조건(Precondition): 와이퍼 모터 ‘off’
  - 시퀀스타입(Sequence_type): 일반(Normal)
  - 비교타입(Comparison_type): 이벤트 반복 허용

[‘앞 창 표준 와이핑’ 유스케이스 메인 시나리오의 RES]

Step 3 + 4: 시뮬레이션 모델링과 자극 시퀀스 도출

• 컴포넌트 기반 제어 소프트웨어가 ASCET-SD에서 모델링 된 후 RES에 속하는 테스트 케이스를 완성하기 위해 RES로부터 자극 시퀀스(stimuli sequence)를 도출함
• 외부 하드웨어 컴포넌트로부터 나온 이벤트가 자극 시퀀스의 자극 이벤트가 된다. 위 RES에서는 외부 액터인 드라이버(A0)로부터 전송된 이벤트 r1.wiper_slow와 r4.wiper_off가 자극 이벤트(stimuli events)가 된다.

Step 5: 시뮬레이션 모델 실행

• 모든 자극 이벤트는 시뮬레이션 실행 동안에 TestDriver 컴포넌트에 의해 전송된다.
• TestDriver 컴포넌트는 현재 가용하지 않은 하드웨어 컴포넌트의 환경 모델을 포함(encapsulates)한다. 예를 들어 아래 SES에 나타난 삽입 이벤트 s6.current_error는 와이퍼 모터의 모델(즉, 와이퍼 모터의 동적 동작을 흉내 냄)로부터 나온 것이다.
• 아래 SES는 위 테스트 케이스 예의 시뮬레이션 결과들 중 하나임. 이 테스트 케이스는 표준 와이핑 동안 와이퍼 모터의 기계적 블로킹이 흐름 에러(a current error)를 야기했고, 이 흐름 에러가 제어 소프트웨어의 하드웨어 진단 컴포넌트에 의해 발견되어 s6.current_error 이벤트가 전송된다는 가정하에서 시뮬레이션 됨

[‘앞 창 표준 와이핑’ 유스케이스 메인 시나리오의 SES]

Step 6 + 7: 오프라인 비교와 수정

• RES를 상응하는 SES에 대조한 오프라인 비교는 SES가 불완전하다는 결론을 내림(첫 5개 이벤트는 발견되었지만 마지막 2개의 요구되는 이벤트가 발견되지 않음)
• 시뮬레이션된 와이퍼 모터의 기계적 블로킹이 컴포넌트 기반 제어 소프트웨어에서 ‘WiperCoordinator’ 컴포넌트와 ‘WiperControl’ 컴포넌트 간의 데드락을 야기함
• 이 문제는 ‘WiperCoordinator’ 컴포넌트의 간단한 재구성(reconfiguration)을 통해 해결됨
• 이 예는 컴포넌트 기반 제어 소프트웨어에 있는 에러가 어떻게 테스트 케이스 시뮬레이션에 의해 발견되는지를 보여준다.