Download - AUTOSAR를 활용한 진단 시스템 개발-OEM과 부품 …...AUTOSAR를 활용한 진단 시스템 개발 – OEM과 부품 협력업체의 이점 OEM 및 1차 부품 협력업체는
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 벡터에서 진단 사업부의 개발팀을 이끌고 있다.