01

DEXT와 다른 진단 데이터 포맷의 차이

DEXT는 AUTOSAR 4.2.1과 함께 처음 공개되었다. 초기 단계

에서는 UDS를 통해 전송된 데이터와 UDS 폴트 메모리(fault

memory)의 디스크립션(description)을 표준화했다. AUTOSAR

4.3.0은 OBD-II, WWH-OBD, FIM(AUTOSAR Function Inhibition

Manager) 및 SAE J1939를 위해 이에 상응하는 확장 기능을 추가

했다. 결과적으로 이 수준의 콘텐츠에서는 DEXT가 AUTOSAR에

서 지원되는 모든 진단용 베이직 소프트웨어 모듈의 구성을 처리

한다. DEXT의 경우 해당 프로토콜을 사용해 전송되는 데이터를

설명할 수 있을 뿐만 아니라 ECU의 어플리케이션 소프트웨어 내

에서 데이터 출처도 설명할 수 있다. 두 가지 유형의 정보를 모두

사용할 수 있어야만 진단용 베이직 소프트웨어를 완벽하게 설정

할 수 있다. 진단 프로토콜, 특히 진단 서비스 설명과 네트워크상

에서의 데이터 전송은 기술되지 않는다. 여기서 AUTOSAR는

UDS 및 OBD-II 표준의 요구사항을 참조한다.

반면, ODX는 그 자체를 일반 진단 테스터를 위한 데이터 형식으

로 설정했다. ODX는 진단 프로토콜뿐만 아니라 ECU와 테스터

간의 전송 데이터와 이 데이터가 진단 테스터에서 해석되는 방법

을 함께 설명한다. ECU의 데이터 소스는 테스터에서 처리할 때

중요하지 않으므로 ODX에서 지정되지 않는다. 그럼에도 불구하

고 ODX는 초기 구성 입력으로 사용할 수 있으며, 주로 네트워크

상의 진단 데이터의 존재 및 구조를 설명한다. 그러나 진단 데이

터는 수동으로, 또는 특별한 프로세스 단계를 통해 ECU 어플리

케이션에 연결해야 한다. ODX 및 ECU 소프트웨어는 폴트 메모

리를 설명할 때 서로 간의 정보 차이가 가장 크게 나타난다. 예를

들어, 오류 검색을 위해 사용되는 디바운싱(debouncing) 또는 변

위 알고리즘(displacement algorithm)은 베이직 소프트웨어에서

기본적으로 매우 중요한데, ODX에는 이 정보가 전혀 없다. 자동

차 제조사들 간에 볼 수 있는 ODX 저작 지침 간의 커다란 차이

가 ECU 구성의 교환 가능성을 더 복잡하게 만든다.

실제로 데이터 교환을 위한 AUTOSAR-ECUC 포맷과 베이직 소프

트웨어에서 적용되는 초기 데이터를 사용하는 프로세스는 목표

에 도달하는 경우가 거의 없다. ECUC 포맷은 빈번히 변경되며 새

로운 버전의 표준이 나올 때마다 조정된다. 이 포맷은 주로 임베

AUTOSAR를 활용한 진단 시스템 개발 – OEM과 부품 협력업체의 이점OEM 및 1차 부품 협력업체는 차량 진단을 개발하기 위해 다양한 프로세스를 활용한다. 다양한 교환 포맷이 사용되며, 대개 이에 필

요한 툴들을 각 회사의 프로세스에 맞추어 사용하게 된다. 그러나 개발 파트너들과 진단 디스크립션을 교환한 후 각 회사의 툴 체인

을 사용하기 시작할 때 문제가 발생하기 시작한다. 아무런 정보 손실 없이 데이터 교환이 가능하더라도 이는 늘 시간이 많이 소요되

는 고된 작업이다. AUTOSAR Diagnostic Extract Template(DEXT)은 진단 개발 영역에서 완전히 새로운 영역의 가능성을 제공한

다. 일례로, 진단과 관련된 베이직 소프트웨어 모듈을 그 어떤 업체와 협업하더라도 문제가 없도록 OEM과 1차 협력업체 혹은 OEM

업체들 간의 경계를 넘어서 동일하게 설정할 수 있다. 이전에는 1차 부품 협력업체의 통합자에 의해 수행되던 업무들은 이제 DEXT

를 사용한 탈중앙화, 분산된 방식으로 실현할 수 있다.

02

기술기사 / AUTOSAR를 활용한 진단 시스템 개발

으로 구성해야 했다. DEXT를 사용할 경우 OEM이나 1차 부품 협

력업체에서 이 작업을 자동화하여 수행할 수 있다. 통합자는 많

은 수의 다양한 연결 유형을 수동으로 직접 생성하지 않고 매핑

으로 처리한다. 이를 통해 오류 발생 가능성을 낮추는 동시에 시

간을 단축시키고 품질을 높인다.

분산형 진단 시스템 개발 시나리오 및 역할

오늘날 사용되고 있는 여러 진단 시스템 개발 프로세스 간에는

상당한 차이가 존재한다. 툴 및 그 교환 포맷 외에 OEM 및 1차

부품 협력업체의 기여도에서도 큰 차이가 존재한다. 실제로

OEM의 독자적인 설계, OEM과 1차 부품 협력업체의 협업을 통

한 진단 개발 그리고 1차 부품 협력업체의 독자적인 설계에 이르

기까지 여러 가지 방식이 존재할 수 있다. 표1은 전형적인 진단

프로세스의 개요를 보여준다.

DEXT를 사용하면 세 가지 프로세스 버전을 각각 지원할 수 있다.

모든 AUTOSAR arxml 형식에서 그러하듯 DEXT에서도 거의 모든

요소를 선택할 수 있다. 개별 프로세스 단계를 통해 초기에 DEXT

를 생성 또는 보강하거나, 프로세스 종료 시 이를 확장할 수 있다.

생성된 데이터는 항상 본질적으로 유효하며 교환이 가능하다. 어

느 프로세스 단계에서 어떤 데이터가 추가되는가는 중요하지 않

으며, 이는 적용되는 프로세스에 따라 간단하게 정의할 수 있다.

디드 소프트웨어 코드 생성기의 입력용으로 설계되었다. 또한,

ECUC는 제조사에서 개별적으로 확장할 수 있으므로 여러 업체

가 공통적으로 사용할 수 있는 이른바 “중립적인(Neutral)” 교환

포맷으로는 적절하지 않다.

AUTOSAR DEXT는 베이직 소프트웨어의 입력 데이터에 관한 요

구사항을 충족하도록 특별히 설계되었으며, 주요 요소는 다음과

같다(그림1).

>진단 서비스와 UDS, OBD, WWH-OBD 및 J1939를 위한 관련 하

위 서비스의 선택

>오류 경로 및 폴트 메모리

>진단 데이터 요소 및 관련된 패키징

>진단 데이터 요소를 어플리케이션 소프트웨어에 매핑하기

>기능 제한(FIM)

아래 예는 데이터 식별자(DID)에 기초한 AUTOSAR Diagnostic

Extract의 장점을 보여준다. AUTOSAR 메타모델은 DID 모델링 방

식을 형식적으로 정의한다. ODX와 달리 여기에서는 각 업체마다

이를 다르게 해석할 여지가 없으므로 툴들 간의 데이터 교환 시

오해의 소지 역시 없다. DID의 존재는 진단 데이터 식별자의 인

스턴스에 의해 지정된다. 해당 인스턴스는 UDS에 필요한 DID의

16비트 숫자를 포함한다. 또한 해당 인스턴스는 DID 데이터의 이

름과 유형을 정의하면서 하나 이상의 데이터 요소를 집계한다.

AUTOSAR는 데이터 유형의 모델링을 위해 기존의 시스템 템플릿

메타모델을 재사용한다. DID 자체는 Diagnostic Data Identifier

를 참조하여 Diagnostic Read Data By Identifier, Diagnostic

Write Data By Identifier 또는 Diagnostic IO Control 등의 서비

스 인스턴스에 의한 진단 서비스에서 사용할 수 있다. 이를 위해

진단 베이직 소프트웨어(BSW)에서 DID의 구성을 정의하기만 하

면 된다.

그러나 DID의 읽기, 쓰기, 또는 덮어쓰기를 위해서는 베이직 소

프트웨어가 어플리케이션 소프트웨어와 상호 작용해야 한다. 이

때문에 DEXT에 추가 요소인 진단 매핑이 포함되어 있다. 이 매핑

이 루틴, DID 데이터, 이벤트 및 어플리케이션 레이어의 소프트

웨어 컴포넌트(SWC)와 같은 베이직 소프트웨어 내 진단 요소들

간의 연결을 설명한다. 이를 위해 AUTOSAR에 정의되어 있는 모

델링 패턴에 따른 방식으로 소프트웨어 컴포넌트의 인터페이스

를 적절하게 모델링해야 한다. 클라이언트/서버 인터페이스에서

함수 호출에 액세스하거나 송신기/수신기 인터페이스를 통해 데

이터를 읽거나 쓸 수 있는 다양한 통신 패턴이 존재한다. 이전에

는 통합자가 베이직 소프트웨어와 어플리케이션 소프트웨어의

포트들 사이에서 수천 가지에 이르는 이러한 유형의 연결을 수동

표 1: OEM과 1차 협력사 간에서 볼 수 있는 전형적인 진단 프로세스

이러한 프로세스들을 지원하는 툴 체인 관련 요구사항

진단 시스템 개발 과정에서 사용되는 툴 체인은 상기 시나리오에

맞춰 조정할 수 있어야 한다. 프로세스 시작 시 요구사항 관리 시

스템(RMS)에서 진단 요구사항을 정의해야 한다. 그런 다음, 진단

요구사항에서 어플리케이션 소프트웨어 및 관련 진단 서비스에

대한 요구사항을 도출할 수 있다. 일반적으로 요구사항의 두 유

형은 서로 다른 역할에 의해 소프트웨어 구성 요소의 형태와 적

절한 베이직 소프트웨어 구성의 형태로 구현된다. 그런 다음, 이

요구사항은 ECU 통합 과정에서 통합자에 의해 결합된다. 정확하

게 이 과정에서 DEXT의 상기 진단 매핑이 이루어진다. 전반적인

프로세스는 그림2에서 확인할 수 있다.

하향식 프로세스에서는 진단 어플리케이션 소프트웨어를 먼저

개발하거나 기존 소프트웨어를 재사용한다. 진단 입력 데이터는

어플리케이션 소프트웨어에 대한 요구사항 및 인터페이스 설명

에서 도출된다. 진단 데이터가 요구사항 및 어플리케이션 소프트

웨어에 맞춰 조정되는 많은 기존 프로세스와 비교할 때 이와 같

은 특징은 커다란 장점이다. 이러한 조정은 수동 작업으로서 종

종 시간이 많이 소요되기 때문이다.

그림 1: AUTOSAR Diagnostic Extract의 요소

03

기술기사 / AUTOSAR를 활용한 진단 시스템 개발

오일 온도 센서의 예시에서 소프트웨어 컴포넌트 포트는 현재 온

도 값을 제시하며, 포트의 인터페이스는 계측된 값이 16 또는 32

비트 값인지 정의하는 동시에 사용된 변환 공식 및 단위를 정의

한다. 그 다음, 이 워크플로우를 위해 특별히 개발된 CANdelaS-

tudio의 소프트웨어 컴포넌트 동기화 기능이 이 정보를 사용하여

다음과 같은 진단 요소에 대한 적절한 진단 데이터를 생성한다.

> 읽기, 쓰기, 그리고 I/O 제어를 위한 진단 데이터 식별자(DIDs)

> 루틴 제어 식별자(RIDs)

> 이벤트 및 DTCs

해당 예시에서는 진단 전문가가 CANdelaStudio에서 “ReadD-

ataByIdentifier” 진단 서비스를 만들었다. 여기에는 서명되지 않

은 16비트 값과 0.1Kelvin의 분해능으로 표시되는 “온도” 데이터

요소, 동일한 데이터 요소를 사용하는 I/O 제어 작업, 그리고 센

서 불량을 표시하는 DTC가 포함된다. 진단 전문가는 또한 진단

통신에서 오일 온도에 액세스하는 데 사용되는 식별자를 정의한

다.

이 밖에 CANdelaStudio는 소프트웨어 컴포넌트가 온도를 제시

하는 포트와 이 포트에서 데이터를 읽는 진단 서비스를 저장한

다. CANdelaStudio는 이 정보를 사용하여 진단 매핑과 함께

DEXT 형식을 내보낼 수 있다. DaVinci Configurator Pro는 이를

DEXT 형식으로 읽으며 이로부터 진단 베이직 소프트웨어 모듈

의 구성을 도출한다. 그런 다음, DaVinci Configurator Pro가 진

단 베이직 소프트웨어 모듈을 위한 소프트웨어 컴포넌트 인터페

이스를 생성하고, 이를 AUTOSAR DEXT의 진단 매핑과 호환이 가

능한 방식으로 어플리케이션 소프트웨어 컴포넌트의 포트에 연

결한다.

DEXT 형식을 만들 때 ODX 데이터도 동시에 만들어야 한다. ODX

및 DEXT 데이터가 공통 소스에서 생성되기 때문에 진단 테스터

작동방식이 ECU의 진단 소프트웨어와 일치하게 된다.

그림 2: OEM과 1차 부품 협력업체 간에 수행되는 진단 프로세스

툴 체인에 기초한 예

그림3은 벡터의 툴을 사용하여 해당 요구사항을 충족시키는 진

단 시스템 개발을 위한 툴 체인의 예를 보여준다. 툴 체인은 요구

사항 및 시스템 설계를 위한 툴 PREEvision, 진단 저작 툴 CAN-

delaStudio, 그리고 베이직 소프트웨어 설정을 위한 DaVinci

Configurator Pro로 구성된다. 진단 요구사항은 초기 개발 단계

에 PREEvision에 의해 정의된다. 예를 들어 이는 오일 온도를 감

지하는 센서가 필요하다는 요구사항이 될 수 있다. 이 센서의 경

우 진단 기능으로 오일 온도 판독, I/O 제어 방식에 의한 센서 값

덮어쓰기(Overwrite), 그리고 온도 센서 오작동을 표시하는 하나

이상의 사용 가능한 DTC 지원을 포함해야 한다.

시스템 추출(system extract)의 소프트웨어 컴포넌트 인터페이스

는 이러한 요구사항에서 arxml 형식으로 도출된다. 소프트웨어

컴포넌트 인터페이스는 진단 대상에 대한 파라미터도 정의한다.

그림 3: 벡터 툴 체인의 예에 기초한 진단 워크플로우

04

기술기사 / AUTOSAR를 활용한 진단 시스템 개발

결론 및 전망

AUTOSAR Diagnostic Extract는 진단 시스템 개발 분야에서 새로

운 가능성을 열고 있다. 이러한 가능성은 베이직 소프트웨어 구

성을 도출하는 것을 포함한 데이터에 대한 명확한 설명, OEM 및

1차 부품 협력업체에서 하향식 접근방식을 통한 진단 시스템의

분산 개발, 진단 기능을 ECU에 자동으로 통합하는 작업을 포함

한다. 벡터의 툴 체인은 이러한 일련의 기능을 사용하는 동시에

ODX와 DEXT 데이터를 동기화한다.

AUTOSAR DEXT는 AUTOSAR의 두 플랫폼 모두에서 사용된다.

다시 말해 AUTOSAR DEXT는 초기에는 AUTOSAR Classic용으로

개발되었지만 이제는 AUTOSAR Adaptive의 유일한 진단 설명

형식이기도 하다. 따라서 발표한 방법은 AUTOSAR Adaptive 플

랫폼에 기초한 개발에도 사용할 수 있다.

Dipl.-Inf. Wigbert Knape벡터에서 임베디드 소프트웨어 및 시스템 사업부의 Product Manager

로 근무하고 있다.

독일 출판물 “Hanser automotive“ 2018년 9월 특별호

이미지 권리: Vector Informatik GmbH

Dipl.-Ing. (FH) Matthias Wernicke벡터에서 임베디드 소프트웨어 사업부의 AUTOSAR 툴 및 시스템

Product Manager로 근무하고 있다.

Dr. Klaus Beiter 벡터에서 진단 사업부의 개발팀을 이끌고 있다.