글로벌 자동차시장 경쟁이 심화됨에 따라 자동차의 전자 네트워킹 아키텍처의 복잡성 또한 계속해서 증가하고 있다. 또 기업들은 개발 주기를 단축해야 하는 과제를 안게 되었다. 기존 시스템을 전자 제어 시스템으로 전환하는 주 목표는 비용을 절감하고, 새로운 차원의 안전성과 신뢰성 제공, 관리 용이성 향상에 있다. 그러나 이같은 모든 이점에도 불구하고 차량 내 전자 부품 수의 증가가 전자 부품과 관련된 결함 발생 가능성을 높인다는 점을 잊어서는 안 된다.
고객이 새로운 자동차를 구입할 때 신뢰성은 매우 중요한 기준이기 때문에 이러한 복잡성을 제어하고, 개발 프로세스를 가속화하며, 설치된 전자 제어 장치(ECU)가 결함 없이 작동하도록 보장할 수 있는 새로운 방식 도입이 중요해졌다. 특히 ECU에서 제공하는 진단 기능 부문에 있어 진단 서비스의 정확성은 매우 강조된다. ECU는 정비소의 정비사가 결함의 원인을 신속하게 찾고 이를 해결하는 데 도움이 되는 정보를 제공한다. 이 정보를 통해 정비사는 문제의 원인이 된 부품을 파악하고 완전 작동 가능한 상태로 복원하기 위해 교체해야 할 부품을 파악할 수 있어야 한다. 이같은 조건이 보장되지 않는다면 올바르게 작동하는 장치를 잘못 교체[1]해 보증 비용이 증가하고 고객 만족도는 떨어질 것이다.
오펠 인시그니아의 E/E 아키텍처는 여러 개의 CAN(Controller Area Network)[2] 및 LIN(Local Interconnect Network)[3] 버스 시스템으로 구성된다. 모든 버스 시스템은 그림 1의 DLC(Central Diagnostic Port)를 통해 액세스되며 통신은 GM 고유의 프로토콜로 정의된다. 이 GM 진단 사양은 KWP2000 [4] 및 CAN 2.0A 표준을 기반으로 한다. 진단 사양에는 진단 정보를 얻기 위해 ECU의 진단 시스템에 접근하도록 허용된 모든 진단 서비스가 포함된다. 이 서비스에 대한 결과가 진단 테스터를 통해 제공돼 진단 통신이 설정되며, 해당 ECU는 요청을 받는 즉시 긍정 또는 부정 응답으로 회신한다.
 
- 긍정 응답에는 진단 디바이스에서 요청한 진단 정보가 포함된다. 진단 정보가 많으면 응답에 여러 메시지 프레임이 포함될 수 있다. 
- 부정 응답에는 명확히 정의된 부정 응답 코드가 포함되며 이를 통해 부정 응답의 사유에 대한 정보가 제공된다. 부정 응답 코드는 GM 진단 사양에 따라 지정된다.
 
수신된 응답을 통해 기술자는 결함의 원인을 파악하고 적절한 작업을 수행해 문제를 해결할 수 있어야 한다. 따라서 서비스 센터에서 시행되는 정비의 성공 여부는 진단 시스템에서 도출된 데이터의 정확성 및 정밀성에 따라 크게 달라진다. 고객이 만족하는 수준의 신속하고 전문적인 서비스 또는 유지보수를 수행하려면 적절한 진단 서비스를 반드시 구현해야 한다. 또한 진단 서비스는 ECU를 프로그래밍하고 제품 품질을 보증하는데 사용되므로 최종 조립 라인 테스트에서 중요한 역할을 담당한다. 따라서 진단 기능의 포괄적 검증이 절대적으로 필요하다.

GME의 검증 프로세스 및 툴 환경

GME는 오펠 인시그니아 개발 시 처음으로 Vector Informatik의 “CANoe.DiVa”(Diagnostic Integration and Validation Assistant) 툴을 도입했다. “DiVa”는 진단 테스트의 생성 및 실행을 자동화한다. 그림 2는 오펠 코르사 및 오펠 인시그니아의 툴 환경을 보여 주며, 두 환경 모두 테스트 툴로 “CANoe”[5]를 사용하고 있다. 코르사 개발 시에는 대부분 수동으로 검증이 이뤄졌으나 인시그니아 개발 시에는 거의 대부분의 테스팅이 완전 자동화돼 이뤄졌다.
그림 3은 GME의 테스트 엔지니어가 수행하는 ECU에 대한 일반적인 진단 검증 프로세스를 보여 준다. ECU 소프트웨어의 개발은 여러 단계로 구성되는데, ECU 개발의 초기 단계에서는 진단 서비스보다 ECU 기능 구현에 더 중점을 둔다. 그리고 진단 서비스는 후속 소프트웨어 버전에서 보다 정교하게 개발된다. 그림 3에서 볼 수 있듯이 1단계(SWR 1) 소프트웨어 버전 도입 시 적은 수의 진단 서비스만 구현된다. GME에서는 진단 소프트웨어 구성 요소(“CANdesc”)를 사용함으로써 개발 시작 단계에 진단 항목 중 일부를 조기에 구현해 ECU에 보다 일찍 통합할 수 있다.
테스트할 진단 기능 수는 개발 주기마다 늘어난다. 진단 서비스를 모두 구현한 후에는 회귀 테스트(Regression Test: Test Synario 또는 Case의 재사용)를 수행한다(SWR 7). 개발 단계에서 진단 서비스에 더 이상 결함이 보고되지 않으면 ECU는 진단 서비스 실행의 측면에 있어 양산 가능한 단계가 된 것이라 볼 수 있다.
일반적으로 테스트 엔지니어는 서로 다른 여러 ECU를 동시에 테스트하기 때문에 적절한 툴 지원 없이 엔지니어가 대규모의 테스트를 수행해 각 소프트웨어 버전에 대해 구현된 진단 서비스를 모두 다루는 것이 불가능하다. 따라서 테스트 엔지니어는 새로 구현된 진단 서비스만 심도 있게 테스트하고 자신의 경험을 토대로 이전에 통합된 개별 서비스에 대해 대표적인 회귀 테스트를 수행한다. 적합한 자동화 툴을 사용하면 작업을 줄이면서도 검증 시 더 많은 테스트를 수행할 수 있다.