차량 네트워크 상의 데이터들은 대개 ECU 간의 정보 교환
(1)을 목적으로 정해진 규약에 따라 전송된다. 그러나 일반적인 Diagnostic은 이와는 다르게 테스터 장비를 이용하는 사람과 ECU의 정보 교환
(2)이 목적이다. 이러한 Diagnostic 과정은 외부에서 Diagnostic Service에 대한 요청을 하면, 요청을 받은 ECU에서 해당 내용에 대한 응답을 되돌려 주는 방식으로 진행된다.
Diagnostic에서 사람이 테스터 장비를 이용하여 원하는 바를 ECU에 요청하고 ECU 응답의 내용을 확인하기 위해서 데이터베이스화된 Diagnostic 스펙이 필요하다. 과거의 자동차 산업 분야에서는 이러한 스펙이 대부분 문서로 작성되어 실제로 이를 사용하기 위해서는 사용하려는 툴에 맞도록 해당 내용을 입력하는 작업이 필요했다. 또한 각 사용자들이 문서를 통해 스펙을 주고받으면, 이를 사용하기 위해 각자 데이터베이스화해야 하는 중복 노력이 필요하다(
그림 1). 이러한 상황에서는 전체적인 처리 비용이 상승하고 작업 중 실수가 발생할 가능성이 높다.
[그림 1] Data maintenance (과거)
이런 문제를 해결하기 위해서 모두가 공통적으로 사용할 수 있는 표준화된 규격의 필요성이 대두되었고, 그 노력 중 하나로 ODX(Open Diagnostic data eXchange)라는 데이터베이스 규격이 만들어지게 되었다.(
그림 2, 3)
[그림 2] Data maintenance (현재)
[그림 3] MVCL 프로세스 플로우
표준화 및 개요
ODX를 통한 표준화 작업은 ASAM(Association for Standardization of Automation and Measuring Systems)
(3)에서 진행하고 있다. ASAM에서는 자동차 공업의 전반적인 분야에 대한 표준화를 진행하고 있으며, MCD(Measurement, Calibration, Diagnostic) 중 하나인 ODX는 이 중 ASAM-AE라는 워킹 그룹에서 담당하고 있다.
1999년도에 ASAM MCD-2D
(4) 1.0으로 시작하여 작업이 계속 진행돼 왔으며 2004년 ASAM MCD-2D 2.0
(5)에 이르러서는 그 공식 명칭을 ODX로 결정하게 되었다(
그림 5).
[그림 4] ASAM 표준화 작업
[그림 5] 표준화의 역사
ODX는 XML(eXtensible Mark-up Language)의 형태로 표현되며 내부적으로는 크게 DiagLayerStructure, Flash, VehicleInfo, Comparam, MultipleECUJobs의 5개 카테고리로 분류된다(
그림 6, 7).
[그림 6] XML로 표현되는 ODX
[그림 7] ODX의 기술 콘텐트
DiagLayerStructure
DialLayerStructure는 Diagnostic Service에 필요한 모든 데이터가 기술되어 있는 논리적 계층이다. 이 논리적 계층은 다섯 개로 구분되어 있으며 다음과 같은 특징을 가지고 있다.
● 데이터들 간에 중복되는 요소를 최소화하기 위해 라이브러리가 있으며 ECU Variants, ECU BaseVariants, Protocols, Functional Groups 간에 상속을 지원한다. 이를 통해 좀 더 일반적인 계층의 특정 요소를 좀 더 특수화된 계층에서 그대로 사용하거나 재정의하여 사용할 수 있다.
● ECU-SHARED-DATA를 통해 라이브러리 메커니즘을 지원한다.
● 여러 ECU Variants 중 특정 ECU를 확인하기 위한 기능을 제공한다.
그림 8은 계층의 사용을 보여주는 간단한 예제이다. 가장 일반화된 계층인 Protocol Layer에서는 KWP2000이 사용되었다. Functional Group Layer에는 KWP2000을 상속받은 DoorECU의 정보가 기술되어 있고 ECU BaseVariants Layer에서는 Functional Groups가 아닌 Protocol Layer에서 바로 상속받은 BCMECU와 DoorECU에서 상속받은 DoorECUfrontLeft의 두 가지 ECU에 대한 정보가 기술되어 있으며, 다시 ECU Variants에서는 BCMECU를 상속받은 BCM_ReleaseA와 DoorECUfrontLeft를 상속받은 C_Sample, FL_ReleaseA의 정보가 기록되어 있다. 또한 모든 계층에서 사용할 수 있는 PIDs의 정보가 ECU SHARED DATA에 정의되어 있다.
[그림 8] Diagnostic Layers overview example
Protocol Layer, Functional Groups Layer, ECU BaseVariants Layer, ECU Variants Layer의 사용 목적과 데이터 상속 관계는
표 1,
표 2와 같다.
[표 1] ASAM`s hierarchical layers
[표 2] Value inherited
모든 계층들은 공통적으로 다음 요소들을 포함하고 있다.
● Diagnostic Service들의 구조
하나의 Diagnostic Service는 Request와 Response의 조합으로 이루어진다. 각 Diagnostic Service에는 반드시 한 개의 Request와 최소한 한 개 이상의 Response가 포함되어야 한다.
[그림 9] Structure of an Diagnostic Service
● Single ECU Jobs
ECU에서 받은 시드 값을 특정 알고리즘을 통해 계산 후 키 값을 되돌려 줌으로써 접속 권한을 얻는 것과 같은 일반적인 Diagnostic Service를 통해 정의하기에는 복잡한 Diagnostic Service들을 정의한다. 실제의 작업은 외부의 JAVA 코드를 통해 이루어지며 여기서는 해당 JAVA 코드의 파일 이름, 입력 값, 출력 값 등이 정의된다.
● Request들의 구조
Diagnostic을 위해 테스터로부터 ECU에 보내지는 Request들에 대한 정의이다.
● Response들의 구조
Diagnostic을 위해 ECU로부터 테스터에 보내지는 Response들에 대한 정의이다. 이 Response는 그 역할에 따라 Positive Response, Negative Response, Global Negative Response로 구별된다.
● Funct-Class 정의
각 Diagnostic Service를 카테고리 별로 분류할 수 있게 하기 위한 정의이다.
● Diag-Data-Dictionary의 정의
Diagnostic Message를 분석하기 위해 필요한 데이터 요소들의 정의이다.
이 밖에도 각 계층의 성격에 따라 Runtime 시에 다른 파라미터의 값에 의해 데이터가 동적으로 변하는 프로토콜을 지원하기 위한 Dynamically defined spec, ECU Variants의 확인을 위한 ECU Variants Patterns 등의 정보가 포함된다.
Flash
ECU와 Runtime System 간에 데이터를 전송하는 경우 중 하나는 “ECU memory programming”이라 불리는 ECU를 Programming 하거나 부분적으로 Reprogramming 하는 경우이다. Flash 카테고리에서는 이러한 기능을 지원하기 위한 Upload, Download의 절차가 명시된다. ODX에서는 Runtime System에서 ECU로 데이터가 전송되는 것을 Download, 이와 반대로 ECU로부터 Runtime System으로 데이터가 전송되는 것을 Upload라고 규정하고 있다.
이 카테고리 정의는 다음 5개의 세부 항목으로 이루어진다.
[그림 10] ODX 지원 툴을 이용한 Flash Programming
● Sessions
Sessions는 단순히 선택적인 프로그래밍을 위한 논리적인 구성 단위이다. Sessions에는 해당 Session이 결정되었을 때 사용될 DataBlock에 대한 정보가 존재한다. DataBlock이 Session에 종속된 것이 아니라 별도로 정의되어 있기 때문에 필요에 따라 각 Session에 정의 되어 있는 DataBlock을 선택적으로 프로그래밍하는 것이 가능하다.
[그림 11] Session을 통한 DataBlock의 선택적 사용
● DataBlocks
DataBlock에는 코드 영역, Calibration을 위한 요소, 프로그래밍을 위해 미리 RAM에 로딩되어야 하는 Flash driver와 같은 메모리의 논리적인 구조가 기술된다. 각 DataBlock에는 실제의 데이터가 기술되어 있는 FlashData에 대한 명시가 존재한다.
● FlashDatas
FlashData에는 ECU에 기록될 실제 데이터에 대한 정보가 정의된다. 실제 데이터를 코드 형태로 직접 기술하거나 외부에 존재하는 Motorola-S, Intel-Hex, Binary 형태의 파일을 명시해 주는 것이 가능하다.
● Phys-Mems
Phys-Mems는 ECU의 실제 메모리 Layout을 기술하는데 사용된다. 이 메모리에 대한 정보는 Flash 프로그래밍을 하는 과정에서 논리적인 구조의 데이터들을 기록(writing)할 실제 물리 주소를 결정하는데 이용된다.
● Project-Infos
Project-Infos는 Software, Hardware, Part Number, Serial Number 등을 통해 사용 가능한 ECU인지를 확인하는데 사용된다.
VehicleInfo
Vehicle Information은 두 가지의 목적으로 사용된다. 하나는 특정 값들을 통하여 차량을 확인하는 것이고, 또 다른 하나는 Runtime System이 차량에 접속할 때 물리적인 연결 상태에 대한 정보를 제공하는 것이다. 이러한 물리적 연결 상태에 대한 정보에는 Vehicle Connector의 핀에 대한 설명, 해당 핀에 연결된 차량의 물리적인 통신 네트워크, 차량의 물리적인 통신 네트워크에 대응되는 ODX 상에서의 Diagnostic Layer 등이 있다.
[그림 12] Vehicle Information
[그림 13] Vehicle topology example
Comparam
Communication Parameters(Comparam)에는 KWP2000, DiagOnCan과 같은 특정 프로토콜로 테스터와 ECU가 통신을 하기 위한 환경 설정에 대한 정보들이 정의된다. 이 정보들은 해당 프로토콜에 따라 달라지며 대개 Timeout 값이나, Tester의 Address, Target(ECU)의 Address, 에러 발생 시 전송 반복 회수처럼 특정 Diagnostic Service가 아닌 전체 Diagnostic Service에 영향을 미치는 값들이다.
이렇게 정의된 설정은 DialLayerStructure의 Protocol Layer에서 참조되며 Layer A가 Layer B를 상속받을 때 일반적인 다른 데이터들과 함께 Layer A에 상속된다. 또한 이 설정도 상속받은 각 Layer에서 필요에 따라 재정의하여 사용할 수 있다.
MultipleECUJobs
MultipleECUJobs에는 특정 ECU가 아닌 동시에 여러 ECU와의 통신이 필요할 때 이에 대한 동작이 정의된다. 특정 ECU에 배정되지 않기 때문에 Dial-Layer를 포함하고 있지 않으며 Funct-Class, Diag-Data-Dictionary, ECUJobs에 대한 정보만을 가지고 있다. 실제 동작은 ECUJobs에서 정의되며 이는 Single ECU Jobs와 마찬가지로 외부에 존재하는 JAVA 파일을 참조함으로써 이루어진다.
[주석]
1 Onboard Communication
2 Offboard Communication
3
http://www.asam.net
4 MCD-2D는 데이터 구조, MCD-3D는 MCD-2D에 접근하는 인터페이스 방법에 대한 규격
5 2008년 3월 현재, 정식으로 릴리즈된 최신 MCD-2D의 버전은 2.0.1
[참고문헌]
[1]
http://www.asam.net
[2] ASAM, “ASAM MCD-2D (ODX) Version 2.0.1 Data Model Specification”, 2005
[3]
http://www.iso.org
[4] Softing IDSC, “ODX Intro”, 2005
[5] Softing, “Venice Manual”, 2007
