글│크리스토프 래츠 (Christoph Ratz)
    Vehicle Diagnostics 부문 글로벌 제품 관리자
    Vector Informatik GmbH

자동차에서 전자부품이 차지하는 비율이 갈수록 높아지고 있다는 것은 주지의 사실이다. 다양한 ECU에 동일한 진단 구조를 적용하게 되면, 진단-소프트웨어 컴포넌트의 재사용이 가능해진다. 이를 재사용하기 위해서는 진단-소프트웨어 구조, 한 ECU에 종속적이지 않은 부분과 종속적인 부분을 파악해야 한다. 진단 요구사양 중 특정 ECU에 종속적이지 않은 부분은 서로 다른 ECU 간에 재사용할 수 있으므로 한번 작성해 놓으면 여러 차량 프로젝트에 반복하여 사용할 수 있다. 반면 한 ECU에 종속적인 부분, 즉 ECU Specific 한 부분은 다른 ECU 간에 재사용할 수 없다. 따라서 이러한 소프트웨어는 한 번 개발해서 여러 프로젝트에 사용할 수 있는 방법은 적용되지 않지만, 소스 코드 생성(Source Code Generation)을 통해 개발 프로세스를 자동화함으로써 효율을 높일 수 있다.

기존 진단 기능 개발 프로세스

대부분의 OEM과 서플라이어는 상호협력 하에 공용 진단 기능 개발 프로세스를 진행하고 있다. 이러한 기존의 진단 기능 개발 프로세스는 비효율성으로 인해 비용이 상승하고 완료하기까지 수개월에 걸친 방대한 작업을 요하는 등의 문제가 있다(그림 1).
개발 절차의 첫 번째 항목은 고객 요구사양서를 작성하는 것이다. 이 진단 사양은 워드프로세서로 작성한다. 이 문서 작성을 위해서는 많은 시간과 노력이 필요하고 작성이 완료되고 나서도 문서의 완전성이나 정확성을 확인하기 어렵다.
작성된 문서는 서플라이어에게 전달되고, 서플라이어 엔지니어가 이 문서를 읽고 해석하게 된다. 경험이 부족한 서플라이어인 경우 이 과정에서 자체적으로는 요구사항을 완전히 파악하지 못해 상당 부분 OEM의 교육에 의존하는 경우도 있다. 자연히 문서를 잘못 해석할 소지가 다분하고 그럴 경우에는 대부분 구현된 결과물이 호환되지 않는 문제로 이어진다. 이 경우 문제는 단순히 여기에 그치지 않고 여러 서플라이어가 똑같이 문서를 잘못 이해해 여러 ECU에서 같은 문제가 발생하게 될 가능성이 있다.
ECU 소프트웨어가 구현되어 OEM에 납품되면 OEM은 각 ECU가 요구사항에 부합하는지 테스트해야 한다. 프로세스의 구조 상 OEM은 각 ECU마다 모든 테스트 항목을 반복할 수밖에 없다. 즉 동일한 테스트 과정을 통해 모든 ECU를 반복 테스트해야 하는 방대한 작업이 발생한다. 결국 모든 엔지니어가 여러 ECU에서 발생하는 유사한 문제를 찾아 해결하는 데 매달리게 된다.
진단 기능은 ECU의 여러 기능 중 마지막으로 구현되는 경우가 많다. 그런데 ECU의 기본 기능 요구사항 중 많은 부분은 진단 기능 없이 테스트하기 어렵거나 테스트가 아예 불가능하다. 결과적으로 진단 기능이 구현되는 시점이 늦어짐에 따라 자연히 개발과정 초기에 기능 요구사항이 구현되더라도 그 테스트는 마지막까지 연기될 수밖에 없다. 중요한 테스트를 연기하면 중대한 문제를 개발 주기 마지막에 뒤늦게 파악하여 프로그램 출시 시기가 지연될 위험성이 커진다.
개발 엔지니어들은 다양한 조직과 작성자가 작성한 수많은 문서에서 요구사항을 파악하여 적용해야 한다. 게다가 작성자마다 관점과 사용하는 용어, 얼마나 세부적으로 작성하는지 그 정도가 다를 뿐만 아니라, 확실하지 않은 정의, 모호한 표현, 일관성 없는 용어 사용, 구체적이지 않고 자의적인 판단에 근거한 요구사항 등으로 인해 한 번에 제대로 구현하기란 사실상 불가능하다.
또한 서플라이어는 개발 도중에 OEM이 진단 기능 요구사항을 변경할 경우에도 대비해야 한다. 새로운 문서가 전달되면 작업을 다시 진행해야 하는 것은 물론, 요구사항을 잘못 이해할 가능성이 더 커져 재작업된 결과물을 또 재작업해야 하는 경우까지 발생한다.

진단 소스 코드 생성기

사무용 소프트웨어에서 웹 애플리케이션에 이르기까지, 요즘 대부분의 소프트웨어 패키지에는 사전 구축된 컴포넌트가 포함돼 있다. 이러한 구현방식은 엔지니어가 고유한 애플리케이션의 핵심 작업에 역량을 집중하고 전반적인 복잡성을 줄이는 데 도움이 된다. 또한 프로젝트 관리자의 입장에서도 개발 진행 속도를 높이고 위험을 줄이게 되는 이점이 있다. 진단 기능 컴포넌트에 있어서는 이외에 다른 중요한 장점이 있다. 여러 OEM에서 요구하는 진단 기능 사양에도 애플리케이션 프로그래밍 인터페이스는 공통적인 부분이 많다. 따라서 이러한 인터페이스를 공용으로 구현함으로써 프로그래머는 ECU에 공통 적용되는 방대한 진단 기능 사양의 복잡성을 해소하고 ECU 애플리케이션 소프트웨어 설계를 여러 OEM의 ECU에 재사용할 수 있는 것이다.
OEM은 ECU-specific 사양서를 소스 코드 생성기의 입력 데이터로 정의한다. 입력 데이터로 정의하는 방식은 기존의 워드프로세서로 작성하던 방식을 대체한다. 소스 코드 생성기는 OEM의 진단 사양서에 따라 ECU-specific 진단 기능 소프트웨어 컴포넌트를 만든다. 그러면 서플라이어가 ECU-specific 진단 부분을 개발한다. 애플리케이션 프로그래밍 인터페이스에 의해 ECU의 진단 기능을 수행하기 위한 통신 연결을 하는 복잡한 진단 프로토콜은 해소된다.

OEM의 관점에서 보는 이점

컴포넌트 개발자는 모든 ECU에 공통으로 적용되는 요구사항에 맞는 프레임워크를 수동으로 개발한다. 이는 현재 모든 서플라이어와 OEM에서 이루어지는 프로세스와 동일하다. 그러나 구현과 테스트에 있어서 동시에 진행되는 막대한 작업 부담을 제거한 것에 큰 차이가 있다. 또한 구현 상의 오류로 인한 막대한 작업 부담을 피할 수 있고 여러 서플라이어에서 동시다발적으로 발생하는 진단 기능 사양의 잘못된 해석으로 인한 문제도 방지된다. 작업이 완료돼 컴포넌트를 사용할 준비가 되면 모든 서플라이어에서 동일한 프레임워크를 공유하게 된다.
OEM은 ECU-specific 요구사항을 소스 코드 생성기의 입력 데이터로 정의해야 한다. 이러한 표준화된 요구사항의 사양은 임베디드 소프트웨어 컴포넌트를 맞춤식으로 구현하는 것에만 사용되는 것이 아니다. 이 프로세스는 워드프로세서 사양 문서를 자동으로 생성하고 테스트 시스템에 대한 입력 데이터를 자동으로 생성하는 데 재사용할 수도 있다. 데이터 입력을 지원하는 적절한 툴만 있다면 전체 진단 프로세스를 지금보다 훨씬 효율적으로 진행할 수 있다.
소프트웨어 컴포넌트의 다른 이점으로 높은 가용성을 들 수 있다. 진단용 소프트웨어 컴포넌트는 이로써 제품개발 초기에 준비될 수 있다. 그렇기 때문에 ECU의 초기 구현에도 진단 기능을 포함할 수 있다. 따라서 프로세스 후반에 도입 시 문제가 발생하여 변경되는 일이 없으므로 전체 진단 기능 구현 품질이 향상된다.