이러한 요구사항은 FlexRay 개발 툴을 이용하여 신속하면서도 포괄적으로, 그리고 경우에 따라서는 완전히 새로운 방식으로 수행된다. 이 글에서는 효과적인 개발 플랫폼에 대한 요구사항에 대해 논의한다. 이 개발 플랫폼은 잔여 버스 시뮬레이션, 상위 레벨 프로토콜, 진단, 고도로 전문화된 테스트 및 AUTOSAR 개발 방법론에 대한 FlexRay 버스의 특별한 요구사항을 충족한다.

신속하고 안정적인 ECU 시뮬레이션
ECU 개발 프로세스에서는 ECU를 전체 시스템에 통합하기 전에 먼저 단독으로 동작시킬 수 있어야 한다. 그러기 위해서는 FlexRay 네트워크의 다른 ECU를 통신 파트너로 한 시뮬레이션을 진행해야 하는데, 이를 잔여 버스 시뮬레이션(Remaining Bus Simulation)이라고 한다. FlexRay의 엄격한 시간 요구사항은 유지하기가 매우 어려운데, 이는 FlexRay 버스에 대한 시뮬레이션이 실행 시 대개 비결정적(non-deterministic)이기 때문이다. 그 결과로 발생한 슬롯 누락은 버스 데이터를 오버샘플링 혹은 언더샘플링 하게 만든다. 따라서 일반적으로 이러한 시뮬레이션은 전용의 지터(Jitter)가 발생하지 않는 결정적(실시간 가능한) 플랫폼에서 실행하도록 권장한다. 여기에 사용 가능한 솔루션으로는 값비싼 HiL 시스템과 구현이 까다로운 고속 프로토타이핑(Rapid Prototyping) 플랫폼이 있다. 물론, 테스트 시 잔여 버스 시뮬레이션만을 위해 특별히 고안된 효과적이면서 경제적인 솔루션도 있다. 이 솔루션을 통해서는 버스 시뮬레이션 및 분석이 가능한 툴의 하드웨어 인터페이스를 가지고 시뮬레이션을 진행한다. 예를 들어, 고성능 인터페이스 VN89xx (2010년 중반)을 사용할 수 있는 CANoe RT 시스템(그림 1)에서는 사용자가 전체 시스템에 대한 시뮬레이션을 실시간으로 실행 또는 벡터의 FlexRay 인터페이스를 사용해 하나의 ECU에 대한 시뮬레이션 실행이 가능하다. 이 솔루션은 시뮬레이션 및 테스트 툴인 CANoe에 원활하게 통합됨으로써 개발자가 (알고리즘 개발을 위한) 순수 시뮬레이션을 구현하든, (개발하고 있는 ECU를 실제 장착해 진행하는) 잔여 버스 시뮬레이션을 구현하든, 혹은 버스에 대한 실제 ECU를 테스트하든 관계없이 항상 동일한 플랫폼과 코드를 사용할 수 있게 한다.
이러한 툴과 플랫폼은 개발자에게 잔여 버스 시뮬레이션을 위한 추가 기능도 제공한다. 예를 들어, 상호작용 계층(Interaction Layer)에서의 ECU 전송 동작은 글로벌 시스템 상태(예: 점화장치 온/오프)에 따라 자동으로 수정된다. 또한 얼라이브 카운터(Alive Counter)는 점진적으로 증가되며, 보완 체크섬(Supplemental Checksums) 역시 독자적으로 계산된다. 따라서 개발자들은 ECU 애플리케이션의 개발 또는 테스트에만 주력할 수 있다. 물론, 통신 레벨에 오류를 발생시켜 테스트를 수행할 수도 있다.

상위 계층에서의 프로토콜
ECU는 차량 속도 및 오일 온도와 같은 신호를 단순히 교환할 뿐만 아니라, 플래싱(Flashing) 또는 보정 때 필요한 전송 프로토콜 및 네트워크 관리 프로토콜과 같은 ISO OSI 모델의 상위 계층 프로토콜을 통해 통신하기도 한다. 이러한 프로토콜은 ECU가 정상적으로 작동하는 동안 버스 통신을 조정하기 위해 요구되며, 서비스 단계에서는 ECU를 평가하거나 갱신하기 위해 사용된다. 각 ECU는 OEM 고유의 수정 사항이 포함된 전송 프로토콜과 같은 OEM 요구에 준하는 고유한 특성을 갖는다. 최신 개발 툴은 FIBEX 기술을 토대로 한 FlexRay 버스의 기본 데이터를 나타내거나 분석하는 것 외에 위에서 언급한 프로토콜과 이 프로토콜을 통해 전송하는 정보를 평가할 수 있어야 한다. 이러한 기능들은 추가 기능이나 플러그인의 형태로 제공된다(그림 2).
최신 모듈식 접근 방식을 개발 툴에 적용하면, 서로 다른 툴이라 하더라도 플러그인 방식으로 재사용 가능하고 툴 자체에 보다 원활하게 통합할 수 있다. 이상적으로 보면, 확장자들(Extensions)은 마치 툴의 자연스러운 구성 요소인 것처럼 통합된다. 프로토콜 확장자의 경우, 프로토콜의 파라미터를 설정하거나 쿼리(Query)하기 위한 특수한 대화상자를 표시한다. 플러그인 기능의 경우, 내부 인터페이스를 통해 전용 프로그램이나 스크립트에서 사용할 수 있다. 이러한 프로그램 제어를 통해 개발자는 통신에 영향을 주고 액세스할 수 있다.

진단에 의한 테스트
ECU의 진단 기능을 액세스하는 것은 매우 중요하다. 특히, 오류가 있는 메모리를 찾거나 플래싱 등의 작업을 위해 개발 프로세스의 초기 단계에서 중요하다. 진단 기능은 일반적으로 CAN 버스를 통해 ECU에 액세스하기 때문에, FlexRay ECU의 경우에는 CAN-FlexRay 게이트웨이를 필요로 한다. 그러나 이러한 게이트웨이는 대개 초기 개발 단계에서는 구할 수가 없다. 바로 이러한 이유 때문에 “진단 사양 세트(Diagnostic Feature Set)”를 갖춘 CANoe와 측정 및 보정 툴인 CANape에서는 FlexRay 버스 상에 있는 진단 데이터를 직접 액세스하도록 지원하고 있다(그림 3). 여기에는 FlexRay를 위한 특수한 전송 프로토콜(AUTOSAR, ISO 및 OEM별 변형)이 포함된다.
CANdela 또는 ODX 형식의 진단 기술 데이터베이스를 CANoe와 CANape에서 로드하면, 진단 대화상자와 관련 기능들을 사용할 수 있다. 한 예로 오류가 발생한 메모리를 읽어와 문제가 있는 코드의 기호 해석 내용과 함께 표시하는 것이 가능하다. 또한 진단 콘솔을 이용해 모든 진단 요청과 이에 대한 응답 및 파라미터를 기호적으로 전송하고 평가할 수 있다. 진단 통신은 트레이스 창 안에 해당 영역별 기호로 표시되며, 프로그래밍과 테스트, 툴을 손쉽게 제어할 수 있는 진단 전용 API도 존재한다.

ECU 테스트를 생성하는 간단한 방법
자주 사용되는 표준 테스트는 동일한 계획(Scheme)에 따라 실행되는 경우가 많다. 따라서 테스트 툴은 자주 반복되는 테스트 패턴을 지원해야만 한다. CANoe의 경우에는 Test Automation Editor라고 하는 툴을 통해 테스트와 그 단계를 순차적으로 생성하는 것이 매우 손쉬운데, 이는 사전에 준비된 라이브러리들과 사용자별 라이브러리들이 서로 연결되어 있기 때문이다. 테스트 엔지니어는 테스트 케이스를 간단히 선택하고 파라미터화 할 수 있으며, 이전의 테스트 결과를 토대로 루프(Loop) 또는 브랜칭(Branching)을 실행할 수도 있다. 또한 정적 테스트와 알고리즘 테스트를 조합하는 것이 가능하다. 버스 통신은 시뮬레이션 테스트와 함께 FlexRay 프로토콜을 고려하면서 동시에 모니터링 할 수 있다. 여기에는 널(Null) 프레임 및 오류가 발생한 프레임의 검출은 물론, 프레임 주기, 응답 시간 동작 등에 대한 모니터링이 포함된다. 모니터링 작업은 관찰 검사(Observational Check)를 통해 수행되는데, 이 기능은 이미 CANoe에 포함되어 있으며 사용 전에 활성화하고 파라미터화 하면 된다.
HiL(Hardware-In-the-Loop) 또는 환경 시뮬레이션을 수행하는 경우에는 ECU를 실제 센서 및 액추에이터에 자주 연결해야 하는데, 이때 디지털 및 아날로그 입/출력 변수를 제공하거나 읽어 와야 한다. 이 목적을 위해, 그리고 개방형 루프 시뮬레이션 및 테스트를 위해 벡터에서는 “VT System”을 개발하였다. 이 시스템은 테스트에 손쉽게 통합할 수 있는 자동차용 I/O 포트를 제공한다. 일반적인 디지털 또는 아날로그 I/O 카드와 달리, 이 시스템은 기존 부하나 센서 또는 그 밖의 적절한 입/출력 시뮬레이션에 대한 연결을 선별적으로 전환할 수 있게 한다. 동시에 적절한 신호 조절을 통해 큰 전압 범위와 전류를 처리할 수 있고, 센서 및 액추에이터의 잘못된 동작이나 단락을 시뮬레이션 할 수도 있다.

FlexRay 시스템에서의 AUTOSAR 기능 테스트
AUTOSAR 설계 방법론에서 애플리케이션에 대한 기본 서비스로서의 통신은 명료하다. 전체 시스템 프레임워크에서 통신은 “AUTOSAR 시스템 기술(AUTOSAR System Description)”에 정의된다. AUTOSAR-ECU를 간단히 신속하게 테스트해야 하는 경우, 테스트 툴에서는 ECU에 대한 통신 기술을 인식해야 한다. FIBEX 데이터베이스가 아닌 “AUTOSAR 시스템 기술”에서 직접 읽어오는 것이 사용자 입장에서는 좀더 편리한데, 이는 CANoe.FlexRay에서 지원될 예정이다.
AUTOSAR 환경의 핵심 개념은 “소프트웨어 컴포넌트(Software Component, SWC)”, “런타임 환경(Runtime Environment, RTE)”, “가상 기능 버스(Virtual Functional Bus, VFB)”이다. ECU가 아직 물리적으로 존재하지 않더라도 여전히 해당 “소프트웨어 컴포넌트”를 테스트할 수 있어야 한다. 이를 위해 “다빈치 컴포넌트 테스터(DaVinci Component Tester)”는 SWC의 실제 ECU 코드를 테스트 환경에 통합할 수 있다. CANoe는 RTE, VFB, 기본 소프트웨어(Basic Software, BSW)를 제공한다. 테스트는 테스트 보고서의 자동 생성 등과 같은 잘 알려진 CANoe의 기능을 통해 실행된다.

전망

미래에는 AUTOSAR ECU의 수와 ECU 상의 SWC 수가 급속도로 증가하게 될 것이다. 이처럼 복잡한 시스템에는 SWC 간의 내부 통신을 테스트할 수 있는 강력한 분석 기능이 필요하다. 따라서 테스트 툴에서 VFB의 통신에 액세스할 수 있어야 하는데, 이는 일반적으로 XCP-on-FlexRay를 통해 수행된다. 하지만 매우 광범위한 테스트를 수행하려면, 보다 높은 성능이 필요하다. 그러므로 제어 장치와 테스트 환경인 CANoe는 JTAG 또는 Nexus 디버그 포트를 통해 결합된다. 이러한 방식을 통해서만 실제 AUTOSAR ECU의 VFB, RTE 또는 BSW 파라미터를 읽어와 신속하게 보정할 수 있다. 이는 실제 ECU의 VFB를 테스트 환경인 CANoe에 연결하는 방식으로 수행될 것이다. 따라서 SWC의 내부 인터페이스에서 이루어지는 테스트 및 분석은 ECU의 외부 제어 연결에서 이루어지는 오늘날과 상당히 유사한 방식으로 미래에도 수행할 수 있다. 서술된 요구사항이 개발 툴과 FlexRay 시스템의 구현에 정교한 방법으로 실현된다면, FlexRay 네트워크를 CAN 네트워크보다 효율적으로 개발할 수 있다.

AEM_Automotive Electronics Magazine