Thomas Riegraf
글로벌 제품 라인 관리자, 「네트워크 및 분산 시스템용 툴」 제품군 담당
Vector Informatik GmbH

Siegfried Beeh
CANoe의 테스트 툴, 진단 및 모델링 담당 팀 리더
Vector Informatik GmbH

Dipl.-Inform. Stefan Krauß
테스트 툴 제품 관리자
Vector Informatik GmbH

지난 10여 년 동안 자동차 전자장치의 위상은 근본적으로 바뀌었다. 초기에는 자동차에 단지 몇 개의 ECU가 사용된 정도였지만 지금은 일부 최고급 자동차에 60개 이상의 ECU가 사용된다. 그 외의 기타 전자 시스템은 안전, 편의, 에너지 절약 분야에서 각각 향상된 기능을 제공한다. 현재 전자장치는 자동차 기술 혁신의 중요한 기반이 되었고 또한 기술혁신의 많은 부분을 소프트웨어가 차지하고 있다.
복잡성의 증가로 인해 광범위하고 효율적인 테스트의 중요성도 그만큼 커졌다. 수많은 전자 부품의 광범위한 사용은 여러 가지 잠재적 오류 발생의 원인이 되었다. 오류를 조기에 검출하거나 수정하고 가능한 한 비용을 낮추기 위해 ECU 개발의 전(全) 단계에서 테스트는 필수적인 요소다. 일부 부품의 고장은 모든 부품이 조립되어 자동차가 만들어진 후에야 비로소 드러나는 경우도 있다. 이러한 이유로 테스트는 부서간, 제조업체간 원칙으로 자리잡게 되었다.
초창기 발생한 수많은 전자적인 문제들은 이러한 사실을 고려하지 않고 체계적인 테스트를 무시할 경우 어떤 일이 벌어지는 지 알려준다. 개발 과정에서 문제 발견의 시점이 늦어질수록 이 문제로 인한 비용은 더욱 증가하게 된다. 이러한 사실은 제품 출하 후 발견된 오류로 인해 큰 비용이 들어가는 리콜 조치가 내려지는 극단적인 경우에 잘 드러난다. 자동차 산업계에서 활동하는 기업들은 시행착오를 통해 지금은 테스트에 큰 비중을 두고 있다. 그러나 가용한 자원의 일관된 적용으로 테스트의 효율성을 더 한층 높일 수 있는 여지가 있다.
테스트 비용이 프로젝트 예산의 상당 부분을 차지하긴 하지만 ECU의 성능은 보증되어야 한다. 따라서 중요한 점은 명확한 개념으로 최대한의 테스트 품질과 깊이를 확보하는 것이다. 예를 들어 충분히 자동화되지 않은 테스트 단계를 최신 방법론과 툴로 대체하는 것이다.

분석, 시뮬레이션 및 테스트를 위한 툴

ECU 네트워킹은 자동차 전자장치들을 상호 동작시키기 위한 필수적인 기반이다. 이러한 관점에서 잔여 버스(remaining bus) 시뮬레이션 기법은 ECU 테스트 수행의 중요한 토대를 제공한다. ECU 네트워킹에 대해 적어도 기초적인 시뮬레이션이라도 하지 않고는 대부분의 경우 ECU를 제대로 작동시킬 수 없다. 예를 들면 많은 ECU들은 네트워크 관리 기능을 제공하는 경우에만 올바르게 동작한다.
Vector의 CANoe는 분산 임베디드 시스템(그림 1)에서 폭넓게 사용되는 분석, 시뮬레이션 및 테스트 툴이다. 이 툴은 잔여 버스 시뮬레이션에 널리 사용되며 Vector가 제공하는 PC 인터페이스를 통해 CAN, LIN, MOST, FlexRay를 비롯한 모든 주요 버스 시스템을 지원한다. 일반적인 인터페이스 카드를 사용하더라도 CANoe에서 ECU의 I/O 라인을 처리할 수 있다. 또한 Vector는 이러한 범용 기능에 테스트를 위한 기능(예: ECU 단자에 부하를 걸어주거나 단자를 단락시키는 것)을 추가한 I/O 하드웨어 제품도 발표했다.
다양한 분석 기능, 시뮬레이션 요소, 테스트 시퀀스는 ECU의 데이터베이스 파일을 기반으로 한다. 데이터베이스 파일의 종류는 CAN용 DBC, FlexRay용 FIBEX, MOST용 XML 함수 카탈로그, LIN용 LDF 파일 등이 있다. 또한 진단 기능용 데이터베이스 파일로는 CDD와 ODX가 있다. 데이터베이스 파일에는 시스템에 대한 필수 정보 외에 신호, 메시지, 진단 서비스 등을 위한 기호 명칭(symbolic name)도 포함된다. 이는 테스트 사용자 및 테스트 개발자의 작업을 간소화하는 데 도움을 준다. CANoe는 Windows OS를 사용하는 일반적인 PC에서 동작한다. 실시간 테스트가 필요한 경우에는 실시간 기능을 갖춘 보다 강력한 테스트 시스템을 설치하면 된다. 이를 위해서는 실시간 운영체제(Windows CE)에서 실행되는 전용 컴퓨터에서 잔여 버스 시뮬레이션과 실제 테스트를 수행하고, 별도의 PC에서 그래픽 사용자 인터페이스(GUI)와 평가를 처리한다(그림 2). 이 시스템은 한 개의 ECU를 실제 상황처럼 테스트할 수 있는 HIL 테스트 환경을 제공하기도 한다.

테스트 및 개발의 통합

오늘날의 개발 모델은 여러 개발 단계에서의 테스트를 요구한다(그림 3). 일반적으로 각 테스트는 자체적으로 필요한 요소가 완비된 개별적인 활동이며 이러한 활동은 전문 툴과 언어, 방법론을 사용하여 적절한 장비가 탑재된 전용 워크스테이션에서 전문인력에 의해 수행된다. 따라서 테스트 생성은 다른 개발 활동과 떨어져서 독립적인 작업으로 구성되는 경우가 많다. 이와 같은 구분된 작업 방식은 개발 과정의 다양한 작업들이 전문화된 작업 그룹들로 분산되는 결과를 초래한다. 단, 이러한 작업 분화를 지나치게 엄격하게 따를 경우 다양한 개발과 테스트 작업 간의 수많은 연결 지점을 제대로 활용하기가 매우 어렵게 된다. 예를 들어, 구성요소 테스트와 시스템 테스트가 적절히 조화를 이루어야만 내용 면에서 동일한 테스트를 반복하는 낭비를 막을 수 있다. 호환되는 툴을 사용하면 한 번 개발한 테스트 방법을 다양한 영역의 다른 개발 작업에서 활용할 수 있다. 이처럼 중복 개발을 방지하면 여기에 투입될 자원을 아껴 기존 테스트 방법과 이러한 방법의 진척된 개발 결과의 유효성을 확인하는 데 투입할 수 있다. 포괄적인 테스트 관리는 협력을 위한 견고한 기반을 제공하며 동일한 리소스를 투입함으로써 테스트의 깊이와 폭을 최적화한다. 협력은 테스트에서의 간극을 찾고 메우는 데에도 도움이 된다.
여러 테스트 단계를 연결하는 것 외에도 개발 및 테스트 활동 간의 상호 연계 및 상호 적응도 필요하다. 테스트는 적절한 방법론과 툴을 사용한 포괄적인 지원이 필요한, 개발의 필수적인 요소로 인식되어야 한다. 이는 절차적 통합 및 조직적 통합과 함께 보장되어야 한다. 여기에서 중요한 부분은 필요한 공식 검증 단계에서만이 아니라 개발과 연계하여 테스트를 수행할 수 있어야 한다는 점이다. 즉, 이상적인 테스트 환경이라면 ECU 개발자의 워크스테이션에서부터 바로 테스트를 수행할 수 있는 것이다.
이를 위해 CANoe는 잔여 버스 시뮬레이션 및 분석 기능과 나란히 사용할 수 있는, 테스트 수행을 위한 런타임 환경을 제공한다. 이 과정은 특히 개발자가 잔여 버스 시뮬레이션과 버스 통신 분석에 이미 CANoe를 사용 중인 경우 아주 쉽게 설정할 수 있다.
CANoe의 테스트 구성요소를 사용하면 수동, 반자동, 완전 자동으로 테스트 수행이 가능하다. 개발자는 간단한 테스트부터 시작한 후 나중에 테스트를 확장하고 완성할 수 있다. 일반적으로 일련의 복합 테스트는 개발자의 테스트를 기반으로 테스트를 수행하는 검사 부서에서 담당한다.
이러한 테스트의 중요한 토대는 잔여 버스 시뮬레이션이다. 원칙적으로 잔여 버스 시뮬레이션은 수동으로 설정되지 않고 시스템 설명의 데이터베이스로부터 자동으로 생성되고 매개변수화 된다.
실제 작업은 소위 모델링 DLL(예: 상호작용 계층, 네트워크 관리 등)에 의해 수행된다. 모델링 DLL은 툴과 함께, 또는 Vector가 OEM별 모델링 패킷으로 구성하여 제공한다. 잔여 버스 시뮬레이션이 시뮬레이션 대상 노드(node)에 공급하는 신호는 테스트 스크립트에 있는 것을 이용하거나 수동으로 발생시키거나 추가할 수 있다.
체계적으로 계획, 실행, 문서화되는 테스트 단계의 활동과 달리, 일반적으로 개발에 수반되는 테스트에서는 공식적 실행과 문서화가 생략된다. 그러나 이러한 테스트는 개발자에게 후속 테스트 단계에 보다 안정적인 제품을 전달할 수 있게 하므로 전체적인 품질 측면에서 중요한 역할을 한다.

성숙도 평가 및 오류 분석

개발 중에 ECU의 성숙도(maturity level)를 평가하기 위해서는 실행된 모든 테스트에 대한 포괄적인 평가가 필요하다. 신뢰성과 적합성 측면에서 개별 테스트 결과의 품질을 고려해야 하지만, 더 중요한 점은 적절한 테스트로 필요한 속성을 넓은 범위에 걸쳐 확보하는 것이다. 따라서 비공식적으로 실행된 테스트의 결과 역시 성숙도 분석에서 도움이 된다. 테스트 수행 기록을 보존하는 것 외에 필요한 사항은 구성 관리의 일관적인 사용이다. 이는 품질 지향의 구조화된 개발 과정 측면에서도 필수적인 사항이다.
테스트 기록은 테스트 실험실에서든 개발 워크스테이션에서든 CANoe를 사용한 테스트를 실행할 때마다 사용자 또는 테스트 방법 개발자의 개입 없이 생성된다. 생성된 테스트 기록은 부가적인 작업 없이 개발에 수반되는 테스트에서 사용할 수 있다. 테스트 기록에 사용된 XML 형식은 공개 형식이므로 다른 툴을 사용하여 결과에 대해 부가적인 처리 작업을 수행할 수 있다. 예를 들어 테스트 관리 시스템을 사용하여 성숙도 분석 맥락에서 테스트 기록을 평가할 수 있다.
이 작업에서 필수적인 부분은 테스트 항목과 그 결과의 매핑(mapping), 그리고 요구사항이 반영된 테스트 항목의 매핑이다. 이는 테스트 방법 개발자가 개별 테스트 항목의 고유식별자(예: ID)를 사용하면 손쉽게 수행할 수 있다. CANoe는 이 식별자를 테스트 기록에 자동으로 복사하여 모든 테스트 항목, 테스트 결과, 요구사항이 명확하게 상호 연계되도록 한다(그림 4).
테스트 결과를 기록하고 평가하는 것만큼 중요한 것은 실제 발생한 오류의 원인을 분석하는 일이다. 대부분의 테스트 툴은 이러한 기능을 제공하지 않거나 극히 기본적인 기능만 제공한다. 오류 분석이 개발자에 대해 완전히 독립적인 작업으로 간주되는 경우가 많다는 점이 그 주된 이유다. 우선, 개발자들은 테스트에서 검출된 오류를 파악하고 그 원인을 추적하는 문제에 직면한다. 특히 오류가 테스트 실험실로부터 보고된 경우 일반적으로 개발자에게는 테스트에 사용된 시스템에 대한 액세스 권한조차 없다.
따라서 테스트 벤치에서는 테스트 절차를 정확히 기록하고 DUT, 특히 버스 통신과의 모든 상호작용을 측정해야 한다. CANoe는 분석 역할을 수행하는 동안 필요한 모든 기록(측정 기록)의 재생과 분석을 활성화한다. 따라서 개발 워크스테이션에서 테스트 벤치와 동일한 유형의 테스트 시스템을 확보하는 장점을 얻을 수 있고, 이를 통해 개발자가 독립적으로 오류 발생 테스트 항목을 재현해 볼 수 있다. 많은 경우 관련된 테스트 항목을 실행할 수 있다. 다만, 이 경우 여러 간소화 작업이 필요하다(예: 존재하지 않는 측정 하드웨어에 대한 주소 지정 방지).
신호 추상화와 진단 

추상화는 소프트웨어 개발과 시스템 설계에서 복잡성을 처리하기 위해 일반적으로 사용되는 중요한 방법이다. 추상화는 테스트 작업에도 적용할 수 있다. ECU의 기능 확장은 시스템의 복잡성을 증가시킬 뿐만 아니라 더 광범위하고 복잡한 테스트를 요구한다. 테스트 구성에서의 올바른 추상화 계층 선택은 테스트 항목 생성에 필요한 작업과 이에 따른 비용뿐만 아니라 테스트 항목의 품질에도 영향을 미친다. 다른 모든 소프트웨어 구성요소와 마찬가지로 테스트 항목 자체에도 오류가 포함될 수 있으므로 사용 전에 검사가 필요하다. 또 하나의 측면은 필요한 유지보수 작업이다(예: 수정된 요구사항에 대한 맞춤 작업, 테스트 항목 수정).
신호 레벨 추상화는 ECU 기능을 테스트하기 위한 일반적인 방법인데, 이는 ECU에서 실제 애플리케이션이 일반적으로 신호 추상화에 기반을 두는 이유이기도 하다(그림 5). 예를 들어, CAN 시스템에서 ECU의 상호작용 계층(Interaction Layer)은 신호 추상화를 제공한다. 이는 CANoe가 상호작용 계층을 사용하는 방식이다. 즉, 상호작용 계층은 네트워크 설명에 포함된 정보로부터 자체를 매개변수화하며, 이 정보는 ECU 소프트웨어 생성에도 사용된다. 이는 ECU와 테스트 환경이 동일한 추상화 계층을 사용하도록 하여 상호 간에 최적으로 조율되도록 보장한다.
이와 동시에 신호 추상화는 적어도 프로토콜 수준에서 잔여 버스 시뮬레이션을 나타내기도 한다. 예를 들어 신호 추상화는 주기적 신호가 실제로 주기적으로 전송되도록 보장한다. 테스트에서 ECU는 버스 통신에 대해 실제와 유사한 환경에서 재연된다. 또한 시스템의 통신 매트릭스에 변경이 가해질 경우에도 일반적으로 테스트 항목은 수정 없이 계속 사용할 수 있다. 애플리케이션이 동일한 경우 추상화는 비슷한 프로젝트에서 테스트 항목을 재사용할 수 있게 해준다.
ECU 테스트에서 신호 인터페이스만 중요한 것은 아니다. 많은 ECU 기능은 ECU에 대한 심층적인 액세스가 가능한 경우에만 의미 있는 테스트가 가능하다. 이러한 심층적 액세스는 ECU의 기존 버스 인터페이스를 통해 액세스되는 진단(diagnostics) 및 보정(calibration) 인터페이스에 의해 제공된다. 이러한 인터페이스를 단순한 메시지 순서에 따라 처리하는 것은 무의미하다. 통신 프로세스의 기반에는 정의된 프로토콜이 있기 때문이다. 진단과 보정에 적절한 추상화를 사용하는 편이 더 편리하고 안정적이다.
CANoe에서 CANdela 툴의 설명 파일 또는 ODX 설명 파일이 진단 액세스 계층의 매개변수화를 담당한다. ECU의 실제 진단 기능에 대한 설명이 없는 경우에는 CANoe와 함께 제공되는 KWP2000 및 UDS를 위한 범용 설명을 사용할 수 있다. 범용 설명, 또는 ECU에 맞춤화된 진단 설명 파일이 정의된 진단 서비스에 대한 편리한 액세스를 제공한다. 상기된 신호 추상화의 경우와 동일한 추상화 및 장점을 얻을 수 있다.
CCP 및 XCP의 측정(measurement)과 보정 프로토콜을 사용하면 CANoe의 테스트 스크립트를 통해 내부 ECU 변수를 액세스할 수 있다. 측정 및 보정 툴인 CANape는 이러한 프로토콜과 필요한 ECU 설명 파일(A2L)을 처리한다. CANoe는 COM 인터페이스를 통해 CANape를 제어한다. 이는 상기된 신호 및 진단 추상화와 동일한 목적을 달성한다.