autosar를 활용한 진단 시스템 개발-oem과 부품 …...autosar를 활용한 진단...

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 벡터에서 진단 사업부의 개발팀을 이끌고 있다.