더욱 합리적으로 구성된 ECU 테스트
ECU 테스트 위한 우수한 확장성 및 유연성
2012년 07월호 지면기사  / 

ECU 개발 과정에서는 항상 수많은 테스트가 수행된다. 테스트 요구 사항은 개발 단계에 따라 크게 다르며, 일반적으로 회사 내 다른 여러 부서로부터의 요구사항을 포함한다. 만약, 이들 부서에서 사용하는 플랫폼이 각기 다르면 테스트 생성 및 관리를 위해 많은 리소스가 요구된다. 시뮬레이션 및 테스트를 위한 툴인 CANoe 기반의 솔루션을 사용하면 훨씬 경제적이다. 이러한 툴은 확장성과 유연성이 뛰어나기 때문에 모든 개발 단계에서 테스트를 수행하기에 매우 적합하다. 


 

지그프리드 비흐 매니저
(Siegfried Beeh)
벡터 인포매틱
(Vector Informatik)

지그프리드 비흐 매니저는 독일 슈투트가르트 대학교에서 전기공학을 전공했으며, 이후 주로 임베디드 시스템 개발 부문에서 활동했다. 2002년에는 벡터에 입사해 ‘테스트 툴 및 진단 사양’그룹을 이끄는 것은 물론, CANoe 및 테스트 자동화 편집기의 표준 테스트 사양을 포함하는 제품 관리자로 근무 중이다.

ECU 테스트는 여러 개발 단계에서 실행되며 개별 부품의 검사부터 시스템 테스트 및 고객 수용도 테스트에 이르기까지 다양하다. 이러한 요구 사항을 효과적으로 수용하기 위해 툴과 테스트 장비를 다양한 부서에서 수년간에 걸쳐 제작하는 경우가 많다. 하지만 벤치 테스트의 경우, 사용자가 임의로 테스트 요구 사항에 따라 확장할 수 있는 소규모에서 중간 규모의 테스트 솔루션이 필요하다. 규모가 큰 HIL(Hardware-in-the-Loop) 시스템은 워크벤치에서 사용하기에는 필요 이상으로 성능이 높을 뿐 아니라 가격이 너무 비싸고 크기도 지나치게 크다. 대형 19인치 하우징, PC 1대, 방대한 케이블 세트가 포함된 주변장치를 고려하면 실험실이 가장 적합한 공간이다. 자동차의 도로 테스트를 수행하는 경우 테스트 담당자에게는 휴대성이 좋은 모바일 장비가 필요하다. 따라서 많은 회사에서는 다양한 테스트 플랫폼과 툴이 갖춰져 있는데, 이러한 플랫폼과 툴은 각각 테스트 요구 사항의 특정 부분을 수행하는 각기 다른 제조업체의 제품이고, 저마다 다른 데이터 포맷과 사용자 인터페이스를 지니고 있다.

시너지 효과 차단하는 이기종 테스트 환경
이러한 테스트 환경에서는 테스트 중복 및 반복 수행에 대한 문제가 발생하게 되며, 테스트 관리 업무를 일관된 방식으로 수행하기가 까다롭다. 또한, 담당자들이 다양한 테스트 언어와 작동 방법을 학습하는 데에도 시간이 많이 소요된다. 이러한 상황을 고려하면 어째서 더욱 높은 확장성, 재사용 가능성, 균일화된 테스트 시스템 조작 방법에 대한 요구가 발생하는지 납득할 수 있을 것이다. 일반적으로 ECU 테스트 과정의 핵심적인 작업은 테스트 결과를 신속하게 얻기 위한 최적의 테스트 환경을 찾는 것이다. 따라서 기업에서 경제적인 첨단 ‘테스트 문화’를 갖추려면 강력하고 포괄적인 테스트 데이터 관리 및 테스트 관리 시스템을 확보하는 일이 무엇보다 중요하다. 이러한 시스템은 이력 추적 가능성과 관련된 모든 요구 사항을 충족하고, 현재 개발 상태를 개략적으로 보여 주면서 ‘어떤 요구 사항이 충족되었으며 어떤 기능이 수행될 수 있는가?’와 같은 질문을 해결해 준다. 이를 통해 개발자와 프로젝트 매니저는 성공 여부를 모니터링하기 위한 수단을 얻게 되며, 언제든지 이러한 수단을 활용해 정확히 명기된 버전의 테스트 대상 시스템(System-under-Test)으로 최종 목표 품질을 달성할 때까지 ECU의 품질 및 성숙도가 지속적으로 올라가고 있는지 확인할 수 있다. 또한 모든 개발 단계에서 테스트 데이터를 균일하게 관리하면 요구 사항이 갑자기 변경될 때 테스트를 수정해야 하는 위치를 간단히 파악할 수 있게 된다.

최소화된 구성에서 범용 시스템까지
HIL 시스템의 요구 사항은 다양한 계층을 이루고 있으며 적용 사례별로 크게 다르다. 확장 가능 플랫폼은 가능한 모든 작업을 수용해야 하는 한편, 적정 수준의 최소 구성으로 갖추어야 한다. 수행해야 하는 작업은 ECU 신호 인가, 시스템 환경 제어, 시스템 반응 테스트부터 자동화된 테스트 실행 및 보고서 생성에 이르기까지 다양하다(그림 1). 또한, 사용자 인터페이스와 실용적인 접근 방식도 고려해 봐야 한다. 엔지니어가 어떤 식으로 테스트 모델과 시퀀스를 제작하려는지, 그리고 어떤 접근 방식을 사용해야 목표를 최단 시간 내에 달성할 수 있는지도 검토한다. 사용 가능한 옵션으로는 모델 기반 그래픽 방식에서 단순한 테스트 시퀀스 및 클래식 프로그래밍을 위한 사용자 친화적인 드래그 앤 드롭 편집기까지 다양하다.
최적의 상태로 확장이 가능한 테스트 시스템(그림 2)은 자동차 부문의 모든 관련 버스 시스템을 위한 인터페이스 하드웨어를 제공한다. 여기서 주요 시스템에는 CAN, FlexRay, LIN, MOST, 이더넷, K-라인(K-Line) 등이 있다. 도메인에 따라 외부 측정 및 제어 하드웨어와의 상호 작용을 위한 다양한 디지털 및 아날로그 인터페이스(예: GPIB 또는 RS232 인터페이스)가 필요할 수도 있다. ECU의 메모리에 접근하기 위해 NEXUS/JTAG, XCP 또는 진단 액세스와 같은 디버그 인터페이스도 고려해야 한다. 완벽한 시뮬레이션 환경은 온도 센서, 압력 센서, 스위치, 램프 또는 액추에이터 모터와 같은 ECU에 연결된 모든 센서 및 액추에이터에 대한 정확한 시뮬레이션이 포함된다. 일반적으로 ECU는 이러한 부품들의 입/출력을 통해 각 부품의 존재 여부를 체크하며, 이 과정에서 관련된 종단 임피던스와 그 밖의 전기적 속성을 검사하게 된다.

센서 및 액추에이터의 임의 신호 인가
테스트를 위해 ECU에 실제 센서 및 액추에이터를 연결할 경우 테스트 자동화가 상당히 어렵게 된다. 테스트의 일반적인 목표는 ECU를 특정 오류 상황에 놓이게 하는 것이다. 이를 통해 시스템이 단락, 과전압, 부족 전압 또는 그 밖의 테스트 중인 장애 상황에 어떤 식으로 반응하는지, 오류 이벤트가 결함 메모리에 올바르게 입력되는지 등을 확인할 수 있다. 실제 부품을 사용해 특정 오류를 생성하고 센서 및 액추에이터 동작을 조작하기란 불가능하며, 대신 ECU 신호 인가(버스 시뮬레이션)를 할 수 있도록 유연하게 구성 가능한 테스트 하드웨어가 있어야 한다. 테스트 중(이상적인 경우 자동으로 실행) 개발자의 실제 작업은 테스트 디자인, 테스트 모델, 진행 절차 및 스크립트를 생성하는 부분에 집중된다. 따라서 테스트 플랫폼의 성능은 테스트 생성을 위한 다양한 그래픽 또는 텍스트 기반 방식을 갖춘 효율적인 툴을 사용할 수 있는지에 따라 결정된다. 선호하는 방법은 주로 수행할 특정 작업, 담당자의 능력 및 지식수준, 개인적인 선호도 등에 따라 달라진다.

모델 기반 테스트 생성에서 클래식 프로그래밍까지
그래픽 기반 툴인 UML(Unified Modeling Language) 다이어그램을 토대로 테스트 디자인과 시퀀스를 매우 성공적으로 구현할 수 있다. 여기서는 도메인 및 테스트 전문가별 테스트의 그래픽 모델링부터 첨단 프로그래밍 언어를 활용한 HIL 시스템의 프로그래밍에 이르기까지 테스트의 다양한 방법이 있다. 이 단계에서 현재의 개발 환경에 대한 통합을 수행하면 이점을 얻을 수 있다.
적절한 툴을 사용해 도메인별 사용자 라이브러리의 준비된 테스트 기능 및 사례에서 드래그 앤 드롭 방식으로 테스트 시퀀스를 통합하는 것은 프로그래밍 지식이 없이도 목표를 신속하게 달성할 수 있는 매력적인 방법이다. 이를 위한 한 가지 사전 요구 조건은 버스 또는 하드웨어 신호 같은 애플리케이션별 파라미터에 대한 액세스 기능이다. 이상적인 경우라면 테스트 기능은 원하는 만큼 확장할 수 있으며 DOORS 같은 요구 사항 관리 시스템에 대한 인터페이스를 갖추고 있다.
많은 프로그래밍 전문가들은 클래식 프로그래밍 방식의 가치를 계속 신봉하고 있다. 여기에 적합한 요소는 전용 스크립트 언어 또는 .NET 언어(예: C#)이다. 개발자는 최신 통합 개발 환경(Integrated Development Environment, IDE)을 사용해 문맥에 일치하는 자동 단어 완성 기능 및 부호(symbol) 추천 기능을 이용할 수 있다. 일부 작업에서는 직접 프로그래밍하는 것이 가장 빠른 해결 방법이기도 하다.

확장성과 미래에 대한 보장
사용자가 나중에 발생하는 제한을 피하고 값비싼 보조 시스템을 구해야 할 필요성에서 벗어나기 위해서는 초기에 테스트 시스템을 선택 또는 구성할 때 몇 가지 주요 사항을 고려해야 한다. 자동차 부문에서 일반적으로 사용되는 모든 버스 시스템, 프로토콜, 디지털/아날로그 입/출력 옵션은 현재 프로젝트에서 (아직) 특정한 역할을 하지 않더라도 지원하고 있거나 손쉽게 추가할 수 있어야 한다. 버스 분기 및 입/출력 채널의 수가 늘어나면서 테스트 시스템의 실시간 요구 사항이 대폭 증가함에 따라 “지능형” 인터페이스 솔루션이 계속 중요해지고 있다. 전용 프로세서가 탑재된 이러한 솔루션은 하위 작업을 자율적으로 미리 처리할 수 있다.
벡터(Vector)는 ECU 개발을 위한 다양한 크기 및 구성을 갖춘 테스트 시스템을 공급하는 업체 중 한 곳이다. 모든 솔루션은 공통적으로 CANoe 시뮬레이션 및 테스트 툴을 토대로 하므로 시스템을 확장할 수 있으며 동일한 사용자 제어 원리를 따르게 된다. 제작된 테스트 애플리케이션은 서로 다른 구성 간에 손쉽게 교환할 수 있으므로 불필요하게 반복되는 구현을 없앤다. 벡터 테스트 시스템의 장점은 오류가 감지되는 경우 등의 상황에서 ECU 동작을 분석하는 기능에 있는데, 이러한 분석은 트레이스, 데이터 및 그래픽 창을 통해 수행된다.

링크

벡터 홈페이지: www.vector.com

제품 정보
CANoe: www.vector.com/canoe
Vector OpenTest: www.vector.com/ote
Test Automation Editor: www.vector.com/tae_en
XL interfaces: www.vector.com/interfaces
VN89xx: www.vector.com/vn8900
VT System:  www.vector.com/vt
 

CANoe 분석, 시뮬레이션 및 테스트 시스템의 예를 토대로 하는
확장 가능한 ECU 테스트 시스템의 소프트웨어 및 하드웨어 컴포넌트

CANoe(CAN open environment): 모든 관련 프로토콜, 전기 입/출력의 자극 및 측정, 잔여 버스 시뮬레이션, 세부 보고 기능을 통한 테스트 흐름 제어, 세부적으로 파악 가능한 프로세스 분석을 통해 자동차 버스 시스템과 통신하기 위한 중앙 소프트웨어로, 랩톱에서 데스크톱 워크스테이션에 이르기까지 확장성이 뛰어나며 시간이 중요한 프로세스를 처리하는 능동형 인터페이스를 사용한다. 또한 다른 시스템과의 상호 작용을 위해 ASAM HIL API 또는 FDX(Fast data eXchange) 같은 많은 인터페이스를 사용할 수 있다.

Vector OpenTest: 특히, 도메인 및 테스트 전문가별로 공유되는 하위 시퀀스와 변형별 하위 시퀀스를 모두 사용해 테스트 디자인 및 테스트 시퀀스를 제작하기 위한 그래픽 툴이다. 또한 HIL 프로그래머는 MS Visual Studio와의 통합을 위해 이 툴을 사용할 수 있다. 이 툴은 CANoe 외에 다른 HIL 시스템도 지원한다.

Test Automation Editor: 이 편집기는 프로그래밍 관련 지식 없이 드래그 앤 드롭 방식으로 테스트 시퀀스를 생성하는 데 사용되며, CANoe의 모든 기능과 네트워크 기호를 활용한다. 또한 CAPL 및 .NET 프로그램을 통해 언어 범위를 확장할 수 있으며, DOORS에 연결할 수 있다. 다른 테스트 관리 시스템에 대한 인터페이스는 공용 인터페이스이다.

Classic programming: 여기서는 Microsoft Visual Studio 개발 환경에서의 구현을 위한 C# 같은 .NET 언어 또는 CANoe에 통합된 CAPL 스크립트 언어가 해당된다.

XL interface line-up: USB 인터페이스, PCI 버스 또는 PCMCIA를 갖춘 CAN 및 LIN용 표준 인터페이스 솔루션으로, 플러그인 버스 트랜시버를 통해 서로 다른 많은 물리층이 지원된다.

VN89xx/VT60xx: FlexRay, CAN 및 LIN용 CPU가 내장된 능동 인터페이스 하드웨어로, 수동 인터페이스보다 2~8배 빠른 시스템 반응 및 버스 액세스 성능을 구현한다.

VT System: 센서와 액추에이터를 측정 및 신호인가와 단락, 과전압, 저전압 같은 오류 상황을 발생시킨다. 



<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>


  • 100자평 쓰기
  • 로그인


  • 세미나/교육/전시

TOP