Technical Papers on the Development of Embedded Electronics
3rd Edition | 한국어
Vector – Automotive. Embedded. Engineering.
Dear Customer,
The automotive industry, known for its reliable and yet innovative products, is now facing the third revolution. While mechanical engineers played an important role in the design and construction process until the 1970s, electronic engineers have taken over the role as key- innovation drivers since the 1980s.
Now we all witness the ever increasing shift towards Messen/Testen/Tools Funktionale Sicherheit software-driven functions and innovations, which is present in the newest concepts of autonomous vehicles as well as user-experience interfaces.
As we did in the past, Vector will assist you – our customers – in the process of developing such applications. For this, we started a wide range of Informatik GmbH Vector Alle Bilder: Safety systematisch verankern innovation projects and formed new partnerships with Modellbasierte funktionale Sicherheit in der E/E-Systementwicklung Um funktionale Sicherheit als integralen Bestandsteil der Entwicklung von E/E-Systemen zu ermöglichen, sind neue Ansätze nötig. Schließlich gilt es, alle Ebenen von Systementwürfen zu berücksichtigen und sicherzustellen, industry leaders. We are ready to support you in your dass die Sicherheitsziele der Systeme nachweislich und gemäß der „Safety-Norm“ ISO 26262 umgesetzt sind. Autoren: Albert Habermann und Dr. Simon Burton
future tasks. In this 3rd edition of Vector Korea’s Technical ie Einführung der internationalen Norm ISO 26262 zur 61511 Prozessindustrie, IEC61513 Kernkraftwerke, EN 50128 Eisen- funktionalen Sicherheit von elektrisch/elektronischen Sys- bahn) besteht darin, das Erfüllen der Systemsicherheitsziele durch temen im Automobil hat das Bewusstsein für dieses Thema das entwickelte Systemkonzept nachzuweisen. Sicherheitsziele wer- Din der Industrie deutlich verstärkt. Viele Hersteller und Lie- den typischerweise durch Gefährdungs- und Risikoanalysen auf der feranten suchen daher nach Ansätzen, die Vorgaben aus der Norm funktionalen Systemebene identifiziert. Die aus den Sicherheitszielen Papers, you will find many interesting background pragmatisch und effizient zu erfüllen und gleichzeitig der steigenden abgeleiteten funktionalen und technischen Sicherheitsanforderungen Komplexität sicherheitsrelevanter Funktionen gerecht zu werden. sind dann Systemkomponenten zuzuordnen. Das korrekte Umsetzen Das Entwickeln sicherheitskritischer Systeme führt im Vergleich zu dieser Sicherheitsanforderungen ist durch eine geeignete Kombi- herkömmlichen Entwicklungen zu erhöhten Aufwänden. So sind nation von Reviews, Analysen und Tests sicherzustellen. zusätzliche Aktivitäten bei gleichbleibenden Rahmenbedingungen Das Erreichen der Systemsicherheitsziele hängt von einer Vielzahl information on our software and hardware solutions, as hinsichtlich Zeitplänen, Ressourcen und Kosten, unvermeidbar. Be- verschiedener Faktoren ab. Ein Beispiel hierfür sind fehlerhaft program- stehende Entwicklungs-, Analyse- und Testmethoden sowie die da- mierte Software-Funktionen oder zufällige Hardware-Fehler in kriti- zugehörenden Werkzeuge sind oft fragmentiert und lassen sich nur schen Komponenten. Solche isolierten Fehler lassen sich mit gängigen mit großem Aufwand in einen durchgängigen Prozess integrieren. Entwicklungsmethoden, wie in der ISO 26262 empfohlen, relativ ein- fach vermeiden oder zumindest entdecken und damit beherrschen. well as stories of successful projects we implemented Ganzheitliche Betrachtung von Systemarchitekturen Problematischer wird es, wenn eine Kombination verschiedener Sys- Eine wesentliche Forderung aller gängigen Sicherheitsnormen im temfaktoren aus unterschiedlichen Architekturebenen die Sicherheits- Automotive- sowie im Non-Automotive-Bereich (zum Beispiel IEC ziele beeinflusst. Mit herkömmlichen, dokumentenbasierten Entwurfs-
together with our customers. 34 Automobil ElEktronik 02/2012 www.automobil-elektronik.de
34_Vector.indd 34 12.12.2012 14:58:56
We hope that you will enjoy reading these stories.
Seoul, February 2018 Thomas Geyer Technical Papers 3rd Edition · 벡터 기술기사 모음 발행일: 2018년 3월 · 발행인: Vector Korea IT Inc. President of Vector Korea IT 사용된 상표: 회사 이름 및 제품명은 해당 회사의 상표 또는 등록 상표입니다. 언급된 제품 및 서비스는 국가/지역에 따라 제공 정도가 다를 수 있습니다. 본 자료집의 재배포는 당사의 서면 승인이 필요합니다.
본 자료집은 당사에서 배포한 기술기사 모음으로 현재 유효하지 않은 링크나 정보, 오타 및 오역, 누락 등이 있을 수 있습니다. 최신 소식 및 제품 정보는 www.vector.com 에서 확인하실 수 있습니다. Contents
Company Profile Vector – The Company 포괄적인 통신 버스 시뮬레이션에 대한 신속한 접근 3/36 전문적인 프로그래밍 지식 없이 가상 네트워크 생성 Serial Bus Systems – CAN CAN 통신의 진화 1/0 폴트메모리를 통한 효율적인 ECU 테스트 3/40 기존 CAN에서 개선된 CAN FD로의 변화 손쉬운 CAN 네트워크 분석 3/44 CAN FD를 활용한 ECU 내부 신호 측정 및 재프로그래밍 1/4 시험 주행 중 완벽한 데이터 로깅 3/46 Serial Bus Systems – LIN 자동차에서 간단하고 경제적인 데이터 교환 1/10 데이터 로거를 통한 신뢰성 높은 차량 데이터 수집 Serial Bus Systems – FlexRay AUTOSAR PDU, FlexRay 정복 1/16 FlexRay 툴, PDU 기반 통신으로 성공적 개발 지원 Vehicle Diagnostics 진단 서비스의 자동 검증 4/0 Serial Bus Systems – 차량용 이더넷 사용을 위한 과제 1/20 GM Europe의 적용 성공 사례 Automotive Ethernet 유연한 인터페이스 및 소프트웨어 툴을 통한 ECU 개발 간소화 자동 진단 검증은 로켓 과학이 아니다 4/6 AUTOSAR, 이더넷을 품다 1/24 단지 실행 가능한 기존 방안들을 활용하여 결론을 맺는 것이다
A utomotive Ethernet 차량용 네트워크의 새로운 통신 패러다임 1/28 AUTOSAR와 ODX를 이용한 진단 솔루션 4/10 새로운 첨단 기술, Ethernet과 CAN FD 1부: AUTOSAR를 이용한 진단
차량용 IP와 이더넷 통신 1/32 AUTOSAR와 ODX를 이용한 진단 솔루션 4/14 오늘날의 적용사례를 통해 알아보는 개발 툴의 도전과제 2부: AUTOSAR 개발 프로세스의 ODX Serial Bus Systems – K-Line K-Line: 클래식 프로토콜을 위한 유연한 솔루션 1/38 원격 진단 - 대화형 진단 툴을 통한 원거리 차량 진단 4/18 정밀 모니터링부터 일반적인 바이트 제어 프로토콜을 위한 데이터 조작까지 데이터 기반 자동화된 진단 구현 검증 방식 4/22 Development of distributed E/E 아키텍처 설계 및 최적화 2/0 ECU Calibration ECU 기능 개발에서의 효율적인 모델 동작 분석 5/0 Systems 차세대 모델 기반 툴로서의 PREEvision 합리적이고 유연한 대량의 측정 데이터 분석 5/4 차량에서의 서비스 지향 아키텍처와 Ethernet 2/6 모델 기반 방식의 이동식 데이터 센터를 향하여 ECU 캘리브레이션 5/8 개발 방법과 툴의 동향 및 영향 ISO 26262에 근거한 하드웨어 설계 및 분석 2/12 신규 개발 전자 브레이크 시스템(EBS)을 기초로 한 안전 평가 Case Study: HOERBIGER 5/11
기능 정의부터 서비스센터까지 2/18 캘리브레이션 데이터 관리: 더 이상의 퍼즐 게임은 그만 5/12 ‘V 사이클’을 넘어선 첨단 엔지니어링 설계 데이터의 활용 개인 및 팀, 전사 차원의 복잡한 캘리브레이션 데이터 관리
칼날위의 아슬한 질주 5/18 ECU Testing 다임러 유니모그의 타이어 압력 제어 시스템을 위한 하드웨어 시뮬레이션 3/0 드래그 레이싱 전용 엔진 제어 장치의 최적화된 파라미터 설정 모델 상에서 ECU 테스트에 의한 시간 단축 포르쉐, 게이트웨이 ECU 검증 자동화 3/4 ADAS 첨단 운전자 보조 시스템의 검증 6/0 시험 주행 실시간 분석으로 실험실 테스트 보완 실제 차량 환경과 감지된 객체 데이터의 비교 폭스바겐에서 개발한 ECU 통신 테스트 3/10 ADAS 개발을 위한 데이터 저장 6/4 OEM과 공급업체에 동일한 테스트 환경 센서와 ECU 데이터의 확장 가능한 저장 복잡한 ECU 네트워크를 위한 테스트 벤치 3/14 Case Study: Renesas 6/8 버스 산업에서 요구하는 유연성 갖춘 테스트 시스템 Case Study: Infineon 6/9 빠르게 변화하는 테스트 벤치의 세계, 개발 기간을 현격하게 줄이는 노하우 3/18 AUTOSAR AUTOSAR의 이점을 활용할 수 있는 방법론에 대한 우리들의 고찰 7/0 FATC 테스트를 위한 HIL 시스템 개발에 대하여 3/22 AUTOSAR, 이대로 완벽한가? 7/4 ECU 테스트 효과적으로 프로그래밍하기 3/28 CAPL 활용의 기초, 팁과 트릭 (1부) Case Study: FAW 7/7 ECU 테스트 효과적으로 프로그래밍하기 3/30 차세대 ECU를 위한 AUTOSAR Adaptive Platform 7/8 CAPL 활용의 기초, 팁과 트릭 (2부) 등장 배경, 특징 및 전망
ECU 테스트 효과적으로 프로그래밍하기 3/32 XCP로 AUTOSAR ECU 소프트웨어를 분석 7/12 CAPL 활용의 기초, 팁과 트릭 (3부) AUTOSAR BSW 확장으로 디버깅을 편리하게
AUTOSAR 소프트웨어 컴포넌트를 위한 플러그앤플레이 솔루션 7/18 Contents
AUTOSAR와 차량 내 진단 시스템 7/22 전문화된 소프트웨어 툴을 통한 사용자 친화적인 AUTOSAR ECU설정 7/24
AUTOSAR, 멀티코어와 기능 안전을 추구하다 7/28
AUTOSAR 고속 태스크 스케줄링 기능 7/32 AUTOSAR 시스템의 고속 어플리케이션 태스크 스케줄링 기능에 대한 고찰
Functional Safety Silent BSW: 안전 관련 ECU용 Silent AUTOSAR 기본 소프트웨어 8/0 혼합형 ASIL 시스템의 성공적인 구현 8/4 검증된 OS를 통한 안전 관련 소프트웨어 개발 간소화 향후 미래의 모습은 과연 어떻게 될 것인가? 8/8 AUTOSAR Basic Software를 이용한 고장 허용(Fault tolerant) 시스템 아키텍처 구현
Cyber Security 자동차 산업을 위한 사이버 보안 9/0 사이버 보안 적용 사례 CAN FD 네트워크상에서 AUTOSAR를 이용한 암호화된 신호 전송 9/4
E-Mobility 스마트 충전, 성공적인 E-Mobility 위한 핵심 요소 10/0 표준 규격 준수하는 충전식 전자장치 개발 및 테스트 비접촉식 충전 방식으로 밝아진 E-Mobility의 미래 10/4 ISO/IEC-15118 무선충전 방식 표준화 전기이동성의 비약적 발전 10/8 1회 충전으로 626.6km 주행
Case Study: ZSW 10/13
전기 및 하이브리드 차량을 위한 고속 계측 10/14 높은 데이터 속도와 빈번한 샘플링 횟수를 지원하는 신개념 계측
Open Networks SAE J1939 표준화 현황 11/0
CANopen 시스템 개발 위한 프로토타입 환경 및 테스트 방법 11/6
회사 소개
Vector the Company
Information at a Glance
The Vector Portfolio
벡터는 자동차 관련 사업에서 사용되는 전자 시스템을 위한 소프 분산 시스템 개발 테스트 트웨어 툴 및 임베디드 컴포넌트 분야의 선도적인 업체입니다. ECU 및 ECU 네트워크 설계 및 개발을 위한 툴 및 서비스. 전체 개발주기 동안 ECU 및 버스 통신 테스트에 필요한 환경 및 CAN에서 차량용 Ethernet에 이르는 다양한 네트워킹 솔루션을 네트워크 통신에 대한 시뮬레이션, 분석 및 테스트를 위한 툴 시나리오를 구현하기 위한 툴 및 서비스 제공합니다. 주요 제품: PREEvision 주요 제품: CANoe, CANalyzer, vTESTstudio, VT System, Data 벡터는 1988년 이래로 자동차 제조업체, 공급업체 및 관련 산업 Logger 분야의 파트너였습니다. 벡터의 툴과 서비스는 엔지니어들이 마주한 도전적이고 복잡한 주제의 영역을 최대한 간단하고 관리 하기 쉽게 만들어주는 이점을 제공합니다. 벡터의 직원들은 직원 지사 자동차 산업에서 전자 분야의 혁신을 가져오기 위해 노력하고 > 전 세계 12개국 있습니다. 전 세계 자동차, 상용차, 우주항공 및 제어 기술 분야의 2,000여 명 24개 사업소 차량 진단 ECU 캘리브레이션 고객은 미래의 모빌리티를 위한 기술 개발을 위해 독립적인 벡터 ECU 상에서 진단 서비스 실행에 필요한 진단 기능을 설명, 구현, ECU 런타임에 액세스 하기 위한 툴. 계측 데이터 및 파라미터 그룹의 솔루션과 제품을 믿고 선택합니다. 검증 및 테스트하기 위한 툴 및 서비스 수집과 수정을 통한 ECU 알고리즘 최적화 주요 제품: CANdelaStudio, Indigo, vFlash, DiVa 주요 제품: CANape, VX1000, vCDM, vSignalyzer, vADASde- 품질을 통한 믿을 수 있는 파트너 veloper 벡터는 모든 분야의 최고를 목표로 합니다. 벡터의 프로세스는 정기적으로 평가되고 인증되며 최신 글로벌 표준을 준수합니다: >>품질 관리 - ISO 9001 >>Automotive SPICE 임베디드 소프트웨어 및 시스템 컨설팅 >>기능 안전 - ISO 26262 ECU 통신 및 CAN, LIN, FlexRay, MOST 및 Ethernet을 통한 리프 벡터는 기술 제품 개발 최적화, 관련 비즈니스 프로세스 및 툴에 고객 협회 로그래밍을 위한 소프트웨어 컴포넌트, 실시간 운영 체제(RTOS), 대한 컨설팅을 제공하며, 조직 내의 지속 가능한 변화를 구현할 > 72개국 15개 위원회 AUTOSAR 베이직 소프트웨어, 진단 소프트웨어, 프로젝트 및 수 있도록 지원합니다. 7,500여 업체 참여 엔지니어링 서비스 주요 서비스: 컨설팅 서비스, 엔지니어링 서비스 주요 제품: MICROSAR, Embedded Software, VC Controller, 고객 맞춤형 프로젝트 DEVELOPMENT FEATURE
다. 또한, CAN FD의 장점인 빠른 비트 속도, 툴 공급자의 직면 과제 긴 데이터 길이를 활용하면 매우 유용하다. 예 소프트웨어 개발 툴 공급자는 고객이 를 들면 트럭에서 긴 버스 라인 때문에 더 빠 CAN FD와 같은 새로운 시스템을 도입해 첫 른 전송속도가 필요할 경우 64바이트의 데이 ECU 개발을 시작할 때 적절한 툴을 제공할 터 길이는 훨씬 더 많은 데이터를 처리할 수 수 있어야 한다. CAN FD를 기존 테스트 및 있게 해준다. 시뮬레이션 환경에 통합하기 위해서는 각종 비록 CAN FD가 CAN과 동일한 기능을 하드웨어 레벨부터 애플리케이션 레벨에까지 다수 공유하지만, 여전히 하드웨어 및 소프트 신속한 변화를 요구한다. 또한, 통신 네트워 웨어에 대한 개선된 프로토콜 확장 및 적응이 크를 기술하기 위한 관련 데이터베이스가 필 필요하다. 무엇보다도 CAN FD에는 요하다. 이러한 맥락에서 CAN FD 모델링을 EDL(Extended Data Length), BRS(Bit 위한 최선의 방법은 무엇인지, 또 64바이트 Rate Switch) 및 ESI(Error State Indicator) 의 데이터 길이를 고려했을 때 PDU 비트와 같은 3개의 새로운 비트를 제어 필드 (Protocol Data Unit) 개념이 필요한지를 먼 에 도입했다. EDL 비트는 CAN FD 포맷의 저 확인할 필요가 있다. PDU는 흔히 프레임을 기존 CAN 포맷의 프레임과 구분하 FlexRay와 함께 사용될 뿐만 아니라, 며, EDL 비트가 recessive(1)이면 CAN FD AUTOSAR System Description의 지원도 프레임이고, dominant(0)이면 CAN 프레임으 받는다. 아울러 추가적인 CRC 검사나 Tx 트 로 정의된다. 이와 유사하게, BRS 비트가 리거로도 사용된다. recessive(1)이면 데이터 필드를 전송할 때 CAN FD를 모델링하는 데 있어서 CAN이 더 빠른 비트 속도로 전환한다. ESI 비트는 가진 장점들을 가능한 많이 유지하는 것은 일 CAN-FD 노드의 에러를 식별하는데 사용된 리가 있다. 예를 들어, CAN FD를 새로운 버 CAN 통신의 진화 다. 또한, DLC(Data Length Code)는 4비트 스 시스템이 아닌 CAN의 확장으로 취급한다 로 구성돼, 데이터의 길이를 12, 16, 20, 24, 면 기존 CAN 테스트 및 시뮬레이션 시스템을 32, 48 및 64바이트 단위로 정의한다(그림 1). 신속하게 마이그레이션 할 수 있다. 이에 따라 기존 CAN에서 개선된 CAN FD로의 변화 [그림 1] CAN-FD 프레임
2012년 3월 로보트 보쉬는 새로운 CAN 프로토콜인 CAN FD(CAN with Flexible Data rate)를 인 CAN에 이미 익숙한 대부분의 개발자에게 공개했다. 이 프로토콜의 주요 특징은 데이터 길이가 기존 8바이트에서 64바이트로 확장되고 데이 Time-triggered 방식인 FlexRay로의 전환은 터 전송 속도가 훨씬 더 빨라졌다는 것이다. 자료에 의하면 CAN FD의 성능은 High Speed 작업 방식 및 사고에 큰 변화를 필요로 한다. CAN(1 Mbit/s)과 FlexRay(10 Mbit/s)의 사이에 있다. 또한 이러한 버스 시스템 간의 성능 차이 를 저비용으로 메우기에 적합하다. 본 글은 툴 공급자의 관점에서 무엇을 개선시켜야 하는지, 또 혁명 대신 진화 이러한 변화가 CAN FD 개발 및 시뮬레이션에 미치는 영향에 대해 다룬다. 하드웨어는 물론 데이 약 20년 동안 자동차 산업에선 CAN이 지 터 포맷 및 각종 통신 계층에 이르는 다양한 영역에서 변화가 이뤄지고 있다. 배적인 버스 시스템이었기 때문에 많은 개발 자들이 CAN에 대한 충분한 노하우를 가지고 글│피터 데커(Peter Decker) 매니저, 벡터 있다. 이러한 노하우는 CAN FD 프로젝트에 도 적용될 수 있는데, CAN FD가 버스 중재 자동차 산업에서 CAN FD의 등장은 차량 솔루션의 새로운 기반이 됐다. 그동안 데이터 임시방편으로 사용해왔다. 그렇다고 CAN을 고 (bus arbitration), 메시지 응답(message 내 전자장치의 데이터 트래픽 증가에 따른 병 병목현상 때문에 비용 증가를 감수하더라도 한 성능의 FlexRay로 전환하기에는 너무 높은 투 acknowledgment), Event-driven 제어 등의 목현상을 해결하기 위한 보다 나은 네트워킹 네트워크를 다수 버스로 분할하는 등의 방법을 자비용이 필요하다. 또한, Event-driven 방식 기존 CAN 콘셉트를 그대로 사용하기 때문이
90 www.autoelectronics.co.kr 2013 JUL·AUG 91
1/0 1/1 DEVELOPMENT FEATURE
경할 수 있다. 즉, 기존 CAN 이벤트에 CAN FD 비트를 더해 유용한 데이터의 길이를 더 길게 확장할 수 있다. 오직 메시지를 표시하는 분석 창만 CAN 프레임과 CAN FD 프레임으 로 구분할 필요가 있다.
상위 계층에서의 CAN FD 상위 계층에서는 진단, 네트워크 관리 (NM), 전송 프로토콜(TP), 상호작용 계층(IL) 및 Tx 모델로 초점이 맞춰진다. 전송 계층에 대한 적용은 훨씬 더 많은 프레임을 해석하는 반면, 적용 계층은 일반적으로 프레임 대신
[그림 2] Piggyback 트랜시버를 가진 CAN FD 버스 인터페이스 신호로 작업한다. 네트워크 관리, 상호작용 계층 및 Tx 모델은 모두 특정 자동차 OEM 요건에 따라 달라진다. CAN FD의 확장된 데 툴의 구성 변화도 상대적으로 적다. 테스트 스 다는 한계가 있다. 따라서 초기 CAN FD 단 이터는 상호작용 계층 및 전송 계층 모두에
크립트 및 데이터베이스를 계속 사용하는 것 계에서 더 유연하고 신속히 사용 가능한 대 영향을 미치므로 변경이 필요하다. 적절한 인 [그림 3] CAN FD 시뮬레이션 및 테스트 툴 도 가능하다. 만약 OEM 및 공급자가 초기에 안은 FPGA 기반의 인터페이스를 사용하는 터페이스를 가진 모듈 식 툴의 이점은 OEM CAN FD를 8바이트 데이터로 제한할 수 있 것이다. 이 기술은 요구되는 리얼타임 요건을 고유 특징이 실행 또는 교환하기 쉽다는 것뿐 다면 첫 프로젝트를 신속히 수행할 수 있을 충족할 뿐만 아니라, 드라이버 업데이트를 통 만 아니라 CAN FD에 요구되는 확장도 실행 application) 또는 Deterministic application 수도 있다. 이때 기존 CAN ECU에는 어떠한 것이다. DBC 데이터베이스는 CAN 응용분야 해 64바이트 지원 또는 버그 해결과 같은 새 하기 쉽다는 것이다. 적용 수준에서 개발자들 CAN에서 CAN FD로의 마이그레이션 으로 사용이 제한된다. 일부 마이그레이션은 진보된 분석, 시험 및 시뮬레이션 툴은 변화도 줄 필요가 없다. 에서 널리 사용되고 있고 유사 산업 표준을 로운 기능을 제공한다. CAN FD가 새로운 이 시작단계에서 적용을 특정 프로토콜에는 기존 CAN 시스템 내에서도 이뤄질 것이다. CAN FD ECU 및 네트워크 개발과 관련된 거 대표하는데, 이 DBC 데이터베이스를 사용하 트랜시버를 필요로 하는지는 사용 용도에 따 독립적으로 신호에는 의존하도록 설계했다면 약 50퍼센트 높은 버스 부하를 가진 네트워크 의 모든 상황에서 유용하다. 개별 네트워크 노 는 것도 가능하다. 또한, DBC는 J1939와 같 라 다르다. 예를 들면 차량 네트워크에서는, 시뮬레이션 모델, 시험 스크립트 및 그래픽 요약 및 결론 가 그러하다. CAN FD는 높은 대역폭을 통해 드를 분석하는 것에서부터 전체 네트워크를 가변형 FPGA 기반 네트워크 인터페이스와 은 프로토콜에 사용되는 64바이트 데이터를 기대속도가 2와 4 Mbit/s 사이다. 그러나 플 사용자 인터페이스를 거의 변경하지 않고 계 높은 버스 부하를 가진 네트워크를 분할하지 시뮬레이션하는 등 사용 영역도 다양하다. 이 고성능 분석, 테스트 및 시뮬레이션 툴을 바탕 처리할 수 있다. 래싱 ECU의 경우, 그 속도는 가능한 높아야 속 사용할 수 있다. 않으며, 역으로 다중 네트워크를 단일 네트워 러한 툴은 개발자가 버스 부하를 예측하고 시 으로 자동차 OEM 및 공급업체는 성공적인 하며, 여기서 사용되는 CAN 트랜시버에 따 크로 합쳐서 사용할 수 있다. 이를 통해 불필 뮬레이션 데이터를 기반으로 최적의 결정(예: CAN FD 개발에 필요한 모든 요소를 갖추고 FPGA와 변경 가능한 트랜시버에 라 8 Mbit/s 이상도 나올 수 있다. CAN (FD), LIN, FlexRay의 요한 게이트웨이의 감소로 인한 비용 절감과 네트워크 분할 필요 여부 결정)을 내릴 수 있 있다. 앞에서 설명한 시스템은 여러 데이터베 의한 플랙시블 하드웨어 Piggyback 트랜시버를 장착한 설정 가능한 새로운 판도 원치 않는 게이트웨이의 반응 시간(latency)을 도록 돕는다. 툴은 개발 과정에 걸쳐 통신 버 이스 포맷을 지원하며, 신호 및 PDU 레벨에 소프트웨어 툴의 구조와 그 툴의 기본적인 하드웨어, 즉 소형 교환 가능 플러그-온 보 새로운 버스 시스템의 도입은 기존 네트워 제거할 수 있다. 스 시뮬레이션을 수행하는데 사용되며, 이는 서 다양한 추출은 물론 오픈 인터페이스를 통 분석, 테스트, 로깅 및 시뮬레이션 기능은 드(그림 2)는 앞으로 트랜시버를 지원할 유연 크 프로토콜에 판도 변화를 가져온다. CAN 현재로선 CAN 및 CAN FD가 혼합된 네트 미 구현된 서브 네트워크와 컴포넌트를 대신 해 OEM별 특성을 구현할 수 있다. 네트워크 CAN FD에 대한 적응이 거의 모든 계층의 한 접근법을 제공한다. FD는 기존의 LIN에 더 큰 편익을 제공하지는 워크를 사용할지에 대해 아직 일치된 의견은 한다. 시뮬레이션 된 노드는 단계적으로 실제 시뮬레이션 및 통신 버스 시뮬레이션은 개발 자동차 프로토콜 스택에서 요구됨을 나타낸 통신 레벨에서, 개발자는 흔히 프레임을 묘 않기 때문에 LIN의 편의성은 그대로 유지된다. 없고, 이는 차량 제조사의 결정에 달려있다. ECU와 교체된다. 또한, 시뮬레이션은 게이트 과정 중 발생하는 모든 상황에서 최적의 테스 다. 물리적인 레벨에서, 툴은 버스 접근용 네 사하고 그 프레임의 특정 데이터로 접근할 수 그러나 단순히 CAN 프레임의 데이터를 LIN CAN 및 CAN FD를 혼합해서 사용하려면 어 웨이 역할을 할 수도 있으며, 기존 CAN 네트 트 조건을 보장한다. 트워크 인터페이스를 거의 항상 사용하는데 있는 분석 툴이 필요하다. 여기서 새로운 프레임에 복사해 8바이트보다 더 큰 데이터로 AE 떤 조치를 해야 한다는 점은 분명하다. 예를 워크와 새로운 CAN FD 네트워크에 연결될 이때 네트워크 인터페이스는 FPGA 또는 표 CAN FD 비트 EDL, BRS 및 ESI를 정확히 단순하게 TP 라우팅(또는”raw TP”)하는 것은 들어, FD 운용에서 CAN 노드는 수동으로 분 준 컨트롤러 칩에 기초해 다양한 방식으로 해석하는 것이 절대적으로 필요하고, 이는 확 불가능하다. FlexRay의 경우 LIN과 상황이 다 리돼야 한다는 것이다. 그렇지 않을 경우 EDL 실행된다. 컨트롤러 칩 기반은 경제적이지만 장된 유용한 데이터 (그림 3)에도 동일하게 적 르다. CAN FD는 이벤트 구동식 응용 시, 참고문헌 비트 때문에 형상 에러를 탐지해야 하고 에러 특정 기능 세트에만 사용할 수 있고 반드시 용된다. 프레임을 툴에 의해 발송된 이벤트로 FlexRay보다 경제적인 대안으로 선호되기 때 CAN-FD specification V1.0, Robert Bosch GmbH 프레임이 전송된다. 링크: Vector CAN Solutions: www.vector.com/can_fd CAN FD 용으로 먼저 사용할 수 있어야 한 모델링함으로써 간편하게 필요한 사항들을 변 문이다. 반면에 FlexRay는 Real-time
2013 JUL·AUG 93 92 www.autoelectronics.co.kr
1/2 1/3 그림1: CANape를 활 용하여 XCP on CAN FD를 측정
한 페이로드를 조사하였다. 데이터 전송속도는 버스 부하가 시뮬레이션 환경에서 실시하였다. CANape 측정 및 캘리브레이 100%라는 가정하에 계산되었다. CAN 및 CAN FD에 대한 프레 션 소프트웨어, 인터페이스 하드웨어, PC 기반의 ECU 에뮬레이 임 영역의 실제 크기는 표 1과 표 2에 제시되어 있다. 단, CAN이 션으로 구성된 실험 환경에서, CAN/CAN FD 드라이버의 입/출력 나 CAN FD에 대한 프레임 크기를 정확히 예측하는 것은 불가능 사이의 전파 시간을 양방향으로 측정하였다. 실험을 통해 측정된 CAN FD를 활용한 ECU 내부 신호 측정 및 재프로그래밍 하다. 버스 노드를 신호 전이 상태에 동기화시키기 위해, 컨텐츠 값이 수학적 추정값과 상당히 일치했으며(그림 2, 표 5), 이를 통 에 따라 양이 변하는 추가 스터프 비트가 해당 프레임에 삽입된 해 이용 가능한 데이터 전송 속도의 모델링을 검증하였다. 각각 CAN FD 기술은 일반적인 CAN 네트워크 기술만큼 복잡하지만, 훨씬 넓은 대역폭을 제공한다. 다. CAN과 CAN FD 사용 시 데이터를 전송하는 데 필요한 데이터를 때문에, CAN FD를 FlexRay나 Ethernet 네트워크의 대안으로 간주하고 있다. 비교하였을 때, CAN FD의 데이터 전송 속도가 시스템 환경 설정 프레임의 크기에 따라 스터프 비트의 설계하기 위해, 최상 및 최 에 따라 1.3에서 최대 5.4배까지 증가한 것으로 나타났다.(표 4) 악의 케이스 시나리오를 분석하였다. 데이터 전송 속도에 대한 계산 결과는 도표상에 부채꼴 모양으로 나타나며(그림 2, 표 3), 이미 향상된 대역폭 외에도, XCP on CAN FD 는 추가로 향상될 CAN기반의 프로토콜로 유연한 데이터 전송속도를 갖춘 CAN FD XCP on CAN FD 의 데이터 전송속도 실제 내용에 따라 프레임이 존재할 수도 있다. 이론적인 계산을 수 있는 부분이 있다. CAN과 CAN FD의 물리적인 통신 기반이 는 FlexRay 보다는 덜 복잡하면서 CAN보다 넓은 대역폭을 제공 XCP on CAN FD 대비 XCP on CAN에 대해 사용 가능한 최대 데 검증하기 위해, 실제 측정 활용 사례가 반영된 실질적인 측정을 동일하기 때문에, CAN FD로 마이그레이션 된 후에도 기존 ECU 한다. 벡터의 네트워크 전문가들은 CAN FD 시스템을 활용하여, 이터 전송속도를 추산하기 위해, 프레임 크기 대 프레임 내 가용 XCP를 통한 ECU 내부 신호 측정 및 ECU 재프로그래밍에 대해 분 석하였다.
CAN FD 상에서 XCP를 활용한 ECU 측정 ECU 개발에서 대표적인 캘리브레이션 사용 사례는 개방 및 폐쇄 루프 제어 알고리즘을 대상으로 다양한 신호와 파라미터를 측정 및 캘리브레이션하는 하는 것이다. ECU 개발자들은 ASAM e.V에 의해 표준화된 XCP 측정 및 캘리브레이션 프로토콜을 선호한다. 현행 프로토콜 버전 1.2에서 CAN FD는 새로운 XCP 전송 계층으 로 도입되었다. XCP를 활용하여 벡터의 CANape(그림 1)와 같은 측정 및 캘리브레이션 툴로 파라미터를 실시간으로 수정하고 ECU의 변경된 속성을 측정하는 것이 가능하다. CAN 시스템을 고려했을 때, 관찰되는 신호 수에 따라 전송 매체의 대역폭이 빠 르게 줄어들 수도 있다. XCP on CAN FD 는 데이터 전송 단계에 서 최대 페이로드 64바이트, 최소 데이터 전송속도 5Mbit/s까지 그 기능을 확장할 수 있다. 그림 3: 하나의 CAN FD 프레임에 통합된 XCP 패 킷에 의해 더욱 빨라진 데이터 전송 그림 2: ECU 측정시 측정 및 계산된 CAN FD 데이터 전송속도
1/4 1/5 표 3: XCP on CAN FD 를 이용한 데이터 측정 기법으로 계산한 데이터 전송속도 (fA=500 kbit/s)
표 1: CAN 프레임의 구조
그림 4: 다운로드 및 설정 시간 비교 : CAN vs. CAN FD
표 4: XCP on CAN과 XCP on CAN FD를 각각 이용하여 측정한 데이터 전송속도 비교
로그래밍을 활용하여 40~60 kB/s 수준의 다운로드 속도를 측정 는 보다 강력한 CPU를 기반으로 한 추가적인 테스트가 필요하 하고 있다. 다. 결론적으로, CAN 기술과 비교했을 때 CAN FD 기술은 월등 또한, Ethernet을 ISO 13400-2별 DoIP(Diagnostics over IP)와 함 히 빠른 데이터 전송속도를 제공하며 (그림 4), 마이그레이션 절 께 활용하여 ECU를 빠르게 재프로그래밍할 수 있다. 100Mbit 차도 매우 간단하다. Ethernet과 플래시 메모리 쓰기의 순수 속도가 180kB/s인 일반 마이크로컨트롤러를 테스트한 결과, Transfer-Data 서비스의 버 요약 및 전망 퍼 크기가 매우 중요한 요인으로 밝혀졌다. 16KiB 버퍼를 통해 다양한 마이크로컨트롤러의 종류와 여러 가지 제약들로 인해 150kB/s의 전송속도에 도달했는데, 이는 테스트에 사용된 플래 CAN FD, FlexRay 및 Ethernet 기반의 직렬 버스 시스템들을 객관 시 메모리의 최대치에 가까운 수치였다. 적으로 비교하는 것은 여전히 매우 어렵지만, 이들 사이에 차이 표 5: XCP on CAN FD 를 이용한 데이터 측정 기법으로 측정된 점은 분명 존재한다. FlexRay 의 경우, 빠른 다운로드 속도와 실 표2: CAN FD 프레임의 구조 데이터 전송속도 (fA=500 kbit/s)] CAN FD를 통한 재프로그래밍 시간 데이터 페이로드에 대한 높은 성능을 동시에 확보할 수 없 반도체 회사들이 아직 CAN FD를 지원하는 마이크로컨트롤러를 다. 100Mbit Ethernet의 경우는 가장 빠른 전송속도를 제공하긴 제공하지 않기 때문에, 벡터의 네트워크 전문가들은 CAN FD 측 하지만, 복잡한 소프트웨어 설정과 FlexRay의 하드웨어 비용이 정을 위해 FPGA 상에 CAN FD 컨트롤러가 구현된 마이크로컨트 CAN FD보다 높다는 단점이 있다. 소프트웨어의 통신 경로가 8바이트 데이터 전송으로 제한될 가 하는 것이 바람직하다. LZSS(Lempel-Ziv-Storer-Szymanski) 알고 롤러를 사용하였다. 보드 상의 소프트웨어 스택은 표준 Vector 능성이 높다. 이러한 경우, XCP를 빨라진 데이터 전송속도로 인 리즘에 의한 데이터 압축은 전송하게 될 데이터 양을 대폭 줄이 UDS 부트로더로 구성되어있다. CAN FD 지원을 위해 ISO 15765- CAN FD는 빠른 데이터 전송 속도를 제공하고, 이를 통해 저렴한 한 혜택을 받을 수는 있지만, CAN FD 프레임에서 이용가능한 최 기는 하지만, 그 효율성은 데이터 구조에 따라 매우 다르며, ECU 2 전송 계층과 CAN 드라이버를 확장하였다. 다운로드 테스트를 비용으로 추가적인 기능 개선 또한 가능하므로 가장 적절한 솔루 대 페이로드인 64바이트를 충분히 활용할 수는 없다. 따라서 데 상에서 데이터 추출로 인해 CPU에 추가적인 부담을 주게 된다. 위한 신속한 설정을 위해, CAN FD를 지원하는 CANoe 시뮬레이 션으로 여겨진다. 또한, CAN과 CAN FD 간의 유사성으로 인해 향 이터 전송속도를 최적화하기 위해서는, 소용량 XCP 패킷의 페이 반면, 파이프라인 방식의 프로그래밍은 병렬화를 지원하기 때문 션 및 테스팅 툴을 활용하였다. 해당 소프트웨어는 플래시 프로 상된CAN으로의 마이그레이션 하는 것 역시 비교적 간단하다. 게 로드를 대용량 CAN FD 프레임으로 연결할 수 있다. (그림 3) 벡 에, 하나의 데이터 세그먼트가 ECU에 저장되는 동안에 다음 데 그래밍 및 전송 계층 기능을 제공하는 외부 DLL을 사용한다. 벡 다가, 두 프로토콜 모두 동일한 물리적 구조를 가지고 있기 때문 터는 앞으로 XCP 사양에 XCP on CAN FD를 위한 패킷 연결이 가 이터 세그먼트의 전송이 동시에 실행된다. 따라서 파이프라인 방 터는 CAN FD 용 플래시 툴인 Vector ‘vFlash’ 를 출시할 예정이 에, 트랜시버, 배선 및 버스 토폴로지의 재사용도 가능하다. 통신 능한 조건을 포함할 예정이다. 식의 프로그래밍을 통한 성능 개선은 프로그래밍 시간이 데이터 다. 규약 역시 변경되지 않았기 때문에, 기존의 노하우를 역시 동일 전송 시간보다 빠를 때 최대화된다. 전송 계층의 사용과 함께, CAN FD 상에서 플래시 메모리의 이론 하게 적용할 수 있다. 또한, 캘리브레이션 및 재프로그래밍 시 소 플래시 프로그래밍 적인 최대 전송속도는 CAN FD 데이터 전송 단계에서 4Mbit/s 기 프트웨어 계층에 대한 변경사항도 상대적으로 미미한 수준이다. 플래시 메모리의 (재)설정은 두 번째 이용 사례로, 고속 네트워크 FlexRay는 10Mbit/s의 전송 속도를 제공하지만, (재)프로그래밍 준으로 270kB/s~37 kB/s 수준이다. 그러나 실제로 측정된 값은 프로토콜을 활용하여 상당한 성능 개선을 실현할 수 있다. “삭 을 완벽하게 지원하지는 못한다. TTP(Time Triggered Protocol) 이러한 최대치보다 훨씬 작다. (그림 4) 놀라운 사실은, 데이터 압 ECU 측정 및 (재)프로그래밍 시, CAN FD 를 이용해 데이터 전송 제”, “다운로드/설정”, “검증”, 이 세 가지 플래시 메모리 단계에서, 의 주기적인 통신 시퀀스의 경우, 모든 PDU(Protocol Data Unit) 축 및 파이프라인 방식의 최적화 전략이 테스트 환경 하의 CAN 속도를 상당히 개선할 수 있으며, 이로 인해 플래시 메모리에 병 일반적으로 CAN 시스템의 다운로드 시간은 매우 중요한 요소이 가 고정 슬롯에서 사전 정의된다. 예를 들어 다운로드를 하기 위 FD에 오히려 역효과를 초래했다는 것이다. 이는 연구실 환경 하 목현상이 생길 수 있다. MCU에 대한 메모리 액세스 시간을 줄이 다. 이때 FlexRay, Ethernet, CAN FD와 같이 더 빠른 버스 시스템 해 진단 서비스에 많은 슬롯을 할당할 경우, 실질적으로 사용될 에서 내장 플래시 메모리에 대한 프로그래밍 시간이 플래시 과정 기 위한 개발을 통해 추가적인 성능 개선도 가능하다. 벡터는 으로 CAN 시스템상의 다운로드 시간을 가속화 할 수 있다. 할 데이터를 위한 대역폭은 줄어들게 된다. 실제 설정은 진단 서 에서 오히려 제한 요인으로 작용했기 때문이다. 이 때문에, 다운 CAN FD에 연결된 패킷을 포함하기 위해 XCP 사양을 확장하기 전송 프로토콜과 상관없이, 데이터 압축, 파이프라인 방식의 프 비스를 위해 PDU 4개에서 8개를 주기 별로 42 바이트에서 255 로드 단계에서 최적화 작업이 효과적이지 못했다. 그러나 데이터 위한 노력을 하고 있으며, 이를 통해 신규 프로토콜의 성능 개선 로그래밍과 같이 다운로드를 위한 추가적인 최적화 기법을 적용 바이트로 제공한다. 벡터의 엔지니어들은 파이프라인 방식의 프 전송 속도와 최적화 효과에 대해 일반적인 결론을 내리기 위해서 을 기대하고 있다.
1/6 1/7 링크: 벡터 홈페이지: www.vector.com 벡터 CAN FD 솔루션: www.vector.com/can
저자:
아민 하펠(Armin Happel) 벡터 인포매틱의 ‘Research and Development for Innovative Appli- cation‘ 부서에서 근무하는 수석 소프트웨어 개발 엔지니어로, 보안 응용 분야를 담당하고 있다.
피터 데커(Peter Decker) 2002년부터 벡터 인포매틱에서 근무하였으며 현재는 CANoe/CA- Nalyzer 멀티 버스 개발 팀의 제품 관리를 담당하고 있다.
CAN FD 솔루션
에릭 스파르(Erik Sparrer) 2013년부터 벡터의 계측 및 캘리브레이션 솔루션 부서에서 근무 하고있다.
CAN 통신 관련 프로젝트를 위한 최고의 선택!
CAN FD(Flexible Data rate: 가변 통신 속도)는 보다 빨라진 비트 전송 속도와 확장된 페이로드를 제공하며, 기존의 CAN 지식을 손쉽게 CAN FD에 응용할 수 있습니다. 벡터의 검증된 솔루션은 업무의 효율성과 품질을 더욱 향상시켜 드릴 것입니다.
> CAN/CAN FD 프로젝트를 위한 포괄적인 소프트웨어 벡터의 노하우와 완벽하게 구성된 툴체인을 통해 관련 툴체인 프로젝트의 효율을 극대화하세요. > 가변적인 CAN/CAN FD 버스 인터페이스 > 휴대용 오실로스코프를 통한 편리한 신호 분석 > AUTOSAR BSW(베이직 소프트웨어)의 손쉬운 구성 > 글로벌 엔지니어링 서비스 및 트레이닝 제품 정보 및 다운로드: www.can-solutions.com
벡터 CAN FD 솔루션을 통해 한 단계 앞서 나가십시오.
1/8 1/9
Vector Korea IT Inc. | Phone +82 2 807 0600 | www.vector.com Cover Story Part. 3 Local Interconnect Network In-Vehicle Networking
반에 이미 자신들의 고유한 센서/액추에이 Part. 3 Local Interconnect Network 터 버스 시스템을 개발하기 시작했다. NCF NCF LIN Cluster 디자인 툴 이에 따라 많은 경제적이고 간단한 고유의 센서/액추에이터 버스들이 개발되었다. 그 LIN 구성 언어 사양 자동차에서 간단하고 중 2000년에 LIN이 센서/액추에이터 영역 LIN 노드 기능 언어 사양 LIN Cluster NCF 을 위한 시리얼 버스 시스템으로서 네트워킹 Generator 시장에 소개되었다. 이 기술은 광범위하게 경제적인 데이터 교환 (2) 보급되었으며 현재 거의 모든 차량에서 공 LIN LIN LIN LIN 조, 시트 조정, 도어 제어 및 미러 조정과 같 Slave Slave Slave Master 버스 애널라이저 은 편의장치에 일반적으로 사용되고 있다. LIN Bus ⓒ Vector Informatik LIN Cluster LIN 컨소시엄의 지원 【그림 1】LIN Work Flow: LIN Cluster로 가는 표준화된 신속한 경로
LIN이 빠르게 정착된 중요한 이유는 LIN 컨소시엄의 설립이었다. 컨소시엄에는 반도 계는 LDF에 정의되어 있다. 생성기 툴들은 최대 20 kbps의 단선 통신 체와 툴 메이커들은 물론 유명한 자동차 LDF를 이용하여 LIN 통신에 필요한 소프 OEM 및 서플라이어들이 참여했다. 컨소시 트웨어 구성요소들을 생성한다. 더욱이 안전이 결정적이지는 않은 센서/액추에이 엄의 목표는 센서/액추에이터 영역을 위한 LDF는 분석, 측정, 테스팅 툴 및 rest-of- 터 영역에서 시리얼 데이터 교환을 위한 저 OEM 간 통신 표준을 만드는 것이었다. 간 bus 에뮬레이터에 대해 필요한 정보를 제공 렴한 통신 프로토콜을 만드는 목표는 주로 단하고 간결한 통신 프로토콜은 물론 ISO 한다. 물리계층의 설계에 영향을 미쳤다. LIN 9141 표준에 기반한 간단하고 경제적인 물 마찬가지로, 개별 LIN 노드들(LIN Slaves) Cluster에서 물리적인 신호 전송은 CAN에 리계층의 정의로 LIN 컨소시엄은 성공을 의 기술은 Node Capability Language와 표 서 익숙한 차동 신호(differential signal) 전 위한 토대를 마련했다. 즉 간단하고 경제적 준화된 Node Capability Files(NCF)의 균일 송을 포함하지 않으며 기존의 단일 선이 사 LIN 버스는 매우 짧은 기간에 자동차에서 간단하고 경제적인 데이터 교환을 위한 기술로 자리매김했다. 오늘날 많은 자동차 인 버스 노드의 구현을 위한 무대가 마련된 한 신택스에 의해 주어진다. NCF는 LIN 용된다. 이 방법에도 불구하고 노이즈 내성 OEM들은 LIN을 통해 바디/편의 영역에서 비결정적인(non-critical) 신호를 전송하고 있다. 자동차에서 LIN 사양이 성공하게 된 것이다. Slave(프레임과 신호 정의, 비트 속도, 진단을 을 충분히 보장하기 위해 버스 레벨을 위한 이유를 구체적으로 밝히고, 기반 기술을 소개한다. LIN 컨소시엄은 LIN 통신 자체에 초점을 포함)의 성능 특성을 기술하며 시스템 설계의 기준 전압으로 ECU의 공급전압과 그라운드 두었음은 물론 개발 방법론(LIN Work 프레임워크에서는 LDF의 자동 생성을 위한 가 사용된다. LIN 트랜시버는 물리적 버스 자료제공 | Vector Informatik Flow)까지 제공하였는데, 이것은 자동차 산 기초를 기술한다. 인터페이스로 사용된다. 공급전압보다 적어 업에 버스 시스템의 승인을 가속화시켰다. 이 2가지 데이터 교환 포맷과 LIN 사양에 도 40% 낮은 레벨은 리시버에 의해 논리 LIN Work Flow는 시간과 경비를 절약하면 서 정의된 환경 설정 프로세스는 사용자에 “0”으로 해석된다. 리시버들은 적어도 공급 서도 LIN 네트워크(LIN Cluster)의 개발을 게 LIN Slave 타입(예를 들면 스테핑 모터) 전압보다 60% 높은 레벨을 논리“1”로 해석 또 다른 데이터 버스가 및 DC모터를 중앙 제어 모듈에 직접 연결하 역시 더욱 어려워졌다. 자동화할 수 있게 해준다. 개발 방법론의 기 을 LIN Cluster에 수차례 구현하게 하거나 한다. 필요한 이유 는 것이 일반적인 관행이었다. 이러한 흐름 개발자들은 버스 시스템을 통한 부품들의 본은 전체 LIN Cluster와 개별 LIN 노드를 LIN Slave를 다른 LIN Cluster들(LIN 최대 데이터 전송속도는 노이즈 방사를 운전의 편리성에 대한 자동차 유저들의 은 점차 비판에 직면하게 되었다. 즉, 이로 네트워킹이 자동차 애플리케이션 영역에서 일관되게 기술하는데 사용하는 2가지 데이 Cluster들의 재사용성)에 사용하게 해준다. 한계 이내로 유지하기 위해 20 kbps로 한정 수요가 증가하면서 이 영역의 자동차 기술 인해 배선 경비가 크게 증가하였고 공간도 는 이상적인 솔루션이라는 것을 빠르게 인 터 교환 포맷이다(그림 1). LIN의 성공에 똑같이 중요하게 기여한 것 된다. 전선의 길이 최대 40 m까지는 최대 도 폭넓게 전자화되고 있다. 이는 다수의 전 더 필요해졌으며 하중도 증가하였고 고장 식하게 되었다. 그러나 CAN 버스가 비용에 전체 LIN Cluster를 기술하는 데에 기여 은 사양의 상세한 문서화다. 2006년 11월부 추천 노드 수가 16개이다. 이것은 LIN 사양 자부품이 편의 영역으로 이동하는데 영향을 가능성도 크게 높아졌다. 또한 증가하는 개 민감한 센서/액추에이터 영역에서는 활용할 하는 것은 균일한 신택스(LIN 구성 언어)와 터 공개된 LIN 사양 2.1은 물리층, 통신 프 에서 규정한 LIN Cluster의 최대 허용 시상 미치고 있다. 오랫동안 그 수가 계속해서 늘 별화는 많은 다른 와이어 하니스와 커넥터 수 있는 후보가 아니었기 때문에 많은 자동 표준화된 LDF(LIN Description File)이다. 로토콜, LIN Work Flow, LIN API, LIN 노 수를 포함한 노드와 라인의 커패시턴스를 어나고 있는 센서, 액추에이터, 스테핑 모터 변종을 요구하며 이로 인해 생산, 설치, 정비 차 OEM들과 서플라이어들은 1990년대 중 모든 LIN Cluster의 특성들, 특히 통신 관 드들의 진단과 배치를 정의한다. 고려하게 된다.
64 AUTOMOTIVE Electronics Magazine 2008 JUN·JUL 65 1/10 1/11 Cover Story Part. 3 Local Interconnect Network In-Vehicle Networking
레임 헤더에 바로 후속하여 LIN Slave는 ID 길이는 6비트이며 짝수 패리티와 홀수 패리 LIN Slave 1 LIN Slave 2 LIN Slave 3 LIN Frame 와 연관된 프레임 리스펀스(frame response) 티 등 2가지 패리티 비트로 보호된다. ID와 LIN Maste Frame Header Frame Response Slave Task Slave Task Slave Task Min. 를 전송한다. LIN 프레임은 프레임 헤더와 2개의 패리티 비트는 PID(Protected 14 Bit 10 Bit 10 Bit 10 Bit 10 Bit 10 Bit 10 Bit Slave Task 프레임 리스펀스로 구성되는데, 이것은 ID Identifier)로 불린다. 처음 60 ID는 유용한 Sync Break Sync Byte PID Data 1 Data 7 Data 8 Check Master Task LIN Bus Sync Break 기반의 메시지 어드레싱 덕분에 각각의 LIN 데이터 통신에 이용된다. ID 60에서 63까지 min. 13 Bit 노드(방송)에 의해 수신될 수 있다. 마지막 4개의 식별자들은 진단 목적으로 사 【그림 2】Master-Slave 통신 아키텍처: 모든 LIN 노드들은 LIN Cluster에서 통신에 참여하기 위한 용된다. Slave 태스크를 갖는다. 하나의 LIN 노드는 역시 LIN 통신을 제어하기 위해 하나의 Master Sync Break Interbyte Space Response Space Interbyte Space Delimiter (optional) (optional) (optional) 태스크를 갖는다. (min. 1 Bit) Start LSB MSB 프레임 리스펀스는 최대 8개의 데이터 바 Bits Stop Bit LIN 프레임에 의한 데이터 전송 이트와 에러 검출을 위한 체크섬(checksum) Useful bits SCI Frame 으로 구성된다. 구분은 클래식과 확장된 체 t0 t1 t2 【그림 4】각각의 LIN 프레임은 프레임 헤더와 프레임 리스펀스로 이루어진다. 프레임 헤더는 항상 LIN Frame Slot 1 Frame Slot 2 Frame Slot 3 통신 컨트롤러의 부족으로, LIN Cluster에 크섬으로 가능하다. 클래식 체크섬은 모든 LIN Schedule Master에 의해 보내진다. 프레임 리스펀스는 하나의 LIN Slave나 LIN Master에 의해 보내질 t0 LIN Master Header 1 Header 2 Header 3 서 시리얼 데이터 전송은 마이크로컨트롤러의 데이터 바이트들의 인버트된 모듈로 256 섬 Frame Slot 1 수 있다. t1 Send Receive 시리얼 인터페이스(Serial Communication 이다. 모듈로 256 섬을 도착하는 데이터 바 Frame Slot 2 LIN Slave 1 Response Response t2 Interface, SCI)를 통해 처리되며 바이트 단 이트들에 추가한 결과가“0xFF"와 일치하지 Frame Slot 3 Send Receive LIN Slave 2 Response Response IFS (Inter 위로 수행된다. SCI는 먼저 LSB(Least 않으면 전송 에러가 있게 된다. 연장된 체크 이라는 2가지 프레임 타입은 이런 목적으로 Sporadic Frame에 대조적으로 충돌은 Receive Receive Frame Send LIN Slave 3 Response Response Response IFS Space) Significant Bit)를 필두로 각 바이트를 전송 섬은 인버트된 모듈로 256 섬을 형성함에 있 제공된다. 이들 부수적인 프레임 타입들을 Event Triggered Frame에서는 배제될 수
LIN Bus Frame Frame Frame Frame Frame Frame Header Response Header Response Header Response IFS 하며, 바이트는 스타트 비트와 스톱 비트로 어서 역시 PID를 고려한다. 도입함에 있어서 종래의 LIN 프레임을 없다. 충돌의 경우에 LIN Master는 모든 LIN Frame 1 LIN Frame 2 LIN Frame 3 구성된다(SCI 프레임). 즉 LIN 프레임은 프 LIN Slave들이 통상 매우 간단하고 저렴 Unconditional(무조건적) 프레임이라고 명 Event Triggered Frame에 할당된 Communication Cycle 레임 헤더와 프레임 리스펀스 사이에 분산 한 마이크로컨트롤러로 구성되기 시작한 이 명하는 것이 상식이 되었다. Unconditional Frame들의 전송에 책임이
【그림 3】중앙 메시지 분산 시스템: LIN Master는 Master Task와 LIN 스케줄에 의해 모든 LIN 프레임 되어 있는 수많은 SCI 프레임의 조합으로 래, 프레임 리스펀스의 전송을 지연하는 것 Sporadic 프레임은 다른 Unconditional 있다. 이것은“Collision Resolving 들의 송신과 수신을 제어한다. 프레임 슬롯은 연관된 LIN 프레임을 전송할 수 있을 만큼 충분 되어 있다(그림 4). (Response Space)이 허용됨은 물론, SCI 프 프레임들과 프레임 슬롯을 공유하는 Schedule”을 활성화하고 처리함으로써 행 히 길어야 한다. IFS의 길이는 주로 Master 태스크의 실행 사이클(시 기반, time base)에 의 해 정해진다. 프레임 헤더를 전송함에 있어서 LIN 레임의 전송 사이에서 센딩 펄스(Interbyte Unconditional 프레임으로 이해된다. 해진다. Master는 2가지 핵심 통신 태스크를 수행한 Spaces)를 삽입할 수도 있다. 전체적으로 이 Sporadic 프레임들은 필요에 따라 전적으로 종래의 Unconditional Frames와 특별한 다. 즉 LIN Slave들을 동기하고 sender와 것은 프레임 리스펀스를 40%까지 늘릴 수 LIN Master에 의해 전송되므로 충돌이 있 Diagnostic Frames는 LIN Slave들을 진단 반도체 기술의 관점에서 LIN Cluster는 키텍처를 기반으로 한다. 클러스터는 하나 이상의 리시버를 프레임 리스펀스에 있다. 이것은 프레임 헤더에도 똑같이 적용 을 수 없다. LIN Master가 어떤 프레임도 하는 데에 적합하다. Unconditional Open Collector 회로에 해당한다. pull-up Master 노드(LIN Master)와 적어도 하나의 할당함으로써 통신을 위임한다. 되는데, 이유는 Sync Break를 생성하는 방 필요하지 않으면 연관된 프레임 슬롯은 비 Frames는 간단한 신호 기반의 진단에 사용 저항은 모든 LIN 노드의 Tx 트랜지스터들 Slave 노드(LIN Slave)로 구성된다. 경제적 비용에 민감한 문제로 인해 LIN Slave들 법에는 다른 방법들이 있기 때문이다. 이것 어 있게 된다. 되는데 반해 Diagnostic Frames는 유저가 이 억제되는 동안 버스 레벨이 거의 공급전 인 이유에서 명시적 통신 컨트롤러는 사용되 은 주파수 허용오차가 최대 14%에 달하는 은 LIN 스케줄을 설계함에 있어서 40%의 Event Triggered Frame은 LIN Slave 규정한 진단이나 표준화된 전송 프로토콜과 압 레벨(High 레벨)로 유지되는 것을 보장 지 않는다. 대신에 LIN 통신은 각각의 노드 온칩 레조네이터를 사용할 수 있다. 따라서 시간 여유를 결정하는 데 필수적이다. 쪽의 산발적인 변화나 이벤트들을 통신하기 균일한 진단 서비스들을 위해 사용된다. 한다. 버스 레벨은 Tx 트랜지스터들 중 하 에서 소프트웨어 태스크들, 즉 Slave 태스크 LIN Master는 모든 LIN Slave들이 LIN 프 위해 도입되었다. 이것은 필연적으로 LIN 사양은“Master Request Frame"과 나가 인에이블 되는 순간에 거의 그라운드 들로 구현된다. LIN Master는 또한 Master 레임 전송이 시작되고 있음을알수있게 Unconditional Frame에 상당하지만 다른 “Slave Response Frame”이라는 2가지 레벨(Low 레벨)까지 끌어내려진다. 따라서 태스크를 가지고 있는데, 이것은 클러스터 Sync Break를 먼저 전송한다. Sync Break 산발적, 이벤트 트리거형, LIN Slave들로부터의 수많은 프레임 응답 Diagnostic Frames를 규정한다. Master Low 상태는 도미넌트(dominant) 레벨, 통신을 조정하기 위해 사용된다(그림 2). 는 적어도 13개의 연속된 도미넌트 비트들 진단 프레임들 이 프레임 헤더에 할당되는 것과는 다르다. Request Frame (ID=0x60)은 Diagnostic High 상태는 리세시브(recessive) 레벨이라 조정은 프레임 슬롯에 조직되어 있는 로 구성되어 있으며, 모든 LIN Slave들로부 Event Triggered 프레임 헤더를 완성하는 Request를 나타낸다. 이 경우에 LIN 한다. LIN 스케줄의 주기적인 실행으로 이루어진 터의 SCI 에러를 도출해낸다. 이것은 Sync LIN 사양은 LIN 스케줄에 의해 엄격하게 데에 사용되는 프레임 응답은 관련된 LIN Master는 프레임 헤더와 프레임 리스펀스 다(그림 3). Break Delimiter(적어도 하나의 리세시브 규정된 통신 사이클에 유연성과 경제성을 Slave들의 필요에 따른다. 이 필요는 만일 를 모두 전송한다. 예를 들어 CAN을 경유하 각 프레임 슬롯의 초입에서 Master 태스 비트)에 의해 종료된다. LIN Master는 통신 제공하는 규정들을 가지고 있다. 이 규정들 전송되어야 할 새로운 데이터가 있을 때에 여 Diagnostic Request가 있으면 Master Master-Slave 통신 크는 프레임 식별자(Identifier, ID)를 갖는 클록 펄스와 함께 이어지는 Sync Byte(0x55 은 통신 사이클들을 더욱 유연하고 경제적 있게 된다. Event Triggered Frame은 첫 Request Frame이 전송된다. 이 경우에 프레임 헤더를 전송하는데, 모든 LIN Slave 값을 갖는 SCI 프레임)를 전송한다. 이게 해 준다. Sporadic(산발적) 프레임과 번째 바이트에 있는 연관된 Unconditional LIN Master는 헤더를 전송하며, 특정 LIN LIN Cluster의 통신은 Master-Slave 아 들은 이것을 Slave 태스크에서 평가한다. 프 ID는 통신을 위임하는 데에 기여한다: 즉 Event Triggered(이벤트 트리거형) 프레임 Frame의 PID에 의해 인식된다. Slave는 리스펀스를 전송한다.
66 AUTOMOTIVE Electronics Magazine 2008 JUN·JUL 67 1/12 1/13 Cover Story In-Vehicle Networking
Power On www.AUTOELECTRONICS.co.kr �
Initialization
At the latest 회원 가입하고 Reception of Wake-Up- after 100 ms Signal or internal reason to wake up the LIN cluster 받고!! Sleep Operational Reception of Sleep Command 매거진 or tBUS_Idle ＞4s
【그림 5】LIN Slave의 통신 상태 모델
Management 기능 상태로 전환된다. Wake Up 신호는 길이가 최소 250 μs와 최대 5 ms의 dominant 펄스 LIN 사양은 Status Management와 로 구성되며, 어떤 LIN 노드에 의해서든 보 Network Management를 정의한다. 내질 수 있다. LIN 사양은 100 ms의 최대 Status Management는 LIN Slaves가 LIN 초기화 단계를 규정한다. 즉 LIN Master는 Master에게 패리티나 체크섬 에러들 같은 이 시간 경과 후 LIN Schedule의 실행을 개 검출된 송신에러들을 알린다. 이것은 시해야 한다. 만일 패시브로 유지하면 상당 Unconditional Frame에 있는“Response 하는 LIN Slave는 또 다른 Wake Up 신호 회원으로 가입하신 분에게는 Error Signal"에 의해 행해진다(“Status 를 보낸다. 반복 횟수와 반복시간 및 시간 종 Frame”). 그러나 이 프레임은 에러의 유형 료 간격은 규격에 정의되어 있다. 잡지 증정본을 보내드립니다. 에 대한 더 이상의 정보를 갖지는 않는다. 지금 바로 신청하세요. 참고문헌 LIN 사양은 에러 처리를 규정하지 않으며, 오히려 이 태스크를 유저에게 남긴다. [1] www.lin-subbus.org LIN Network Management의 첫 번째 [2] LIN Specification Package Revision 2.1 태스크는 LIN Cluster에 있는 모든 Slave들 [3] Road vehicles-Diagnostics on 회원 혜택 을 정상 통신 상태(Operational)에서 Sleep Controller Area Network (CAN)- 1. www.AUTOELECTRONICS.co.kr의 Part 2: Network layer services, 상태 및 다른 방향으로의 변환을 조정하는 회원이 되시면, 게시된 기사를 보실 수 International Standard ISO 15765- 있습니다. 것이다(그림 5). LIN Slaves가 4초간 어떠한 2.4, Issue 4, 2002-06-21 2. www.AUTOELECTRONICS.co.kr의 버스 활성도 감지하지 못하면 이들은 [4] Road vehicles-Diagnostics on 회원이 되시면, aeNews를 이메일을 통해 controller area network (CAN)-Part 받아보실 수 있습니다. Operational 상태에서 Sleep 상태로 전환된 3: Implementation of diagnostic 3. www.AUTOELECTRONICS.co.kr의 다. 같은 조건이 LIN Master로부터 Sleep services, International Standard ISO 회원이 되시면, 자동차 전기전자 행사를 15765-3.5, Issue 5, 2002-12-12 가장 먼저 확인하실 수 있습니다. 명령을 끌어내는데, 이것은 확실히 특수한 [5] Road vehicles-Diagnostic systems- 4. www.AUTOELECTRONICS.co.kr의 Master Request Frame이다. Part1:Diagnostic services, International 회원이 되시면, 가입하신 달의 잡지를 무 료로 받아보실 수 있습니다.(1회) 바꿔 말하면 LIN Slave가 유효(valid) 헤 Standard ISO 14229-1.6, Issue 6, 2001-02-22 더가 따르는“Wake Up Signal”을 감지하 [6] www.vector-informatik.com ※ aeNews는 국내외 자동차 전기전자 기술 면, LIN Slave는 Sleep 상태에서 초기화 및 산업계 소식을 정리한 보고서로, 2주 [7] www.vector-academy.com 에 한 번씩 월요일에 발행됩니다. (Initialization) 상태를 거쳐 Operational
68 AUTOMOTIVE Electronics Magazine 1/14 Development Feature
수 있다. 프레임의 레이아웃은 사이클에 따라 변화할 수 있기 때문에 동일한 PDU를 다양한 프레임으로 맵핑할 수 있다. PDU는 특정 사 이클에서 특정 슬롯의 FlexRay 프레임 내 위 치에 의해 개별적으로 식별된다. 벡터는 PDU 레이어를 통해 CANoe에서 PDU를 식별한다 (그림 1). PDU 레이어는 PDU 객체들을 도입 하고 버스와 사용자 인터페이스 사이에 각각 AUTOSAR PDU, FlexRay 정복 위치한다. 레이어는 적절한 데이터베이스 (FIBEX+ 또는 FIBEX 3.0)를 CANoe에 할당 FlexRay 툴, PDU 기반 통신으로 성공적 개발 지원 함으로써 활성 또는 불능화 된다. 레이어가 활 성화되면 데이터베이스를 기반으로한 완벽한 네트워크 통신 해석(PDU 명칭, 신호, 타이밍) 이 PDU 레벨에서 수행된다. 아우디(Audi)는 자사의 최신 차량에 FlexRay를 적용하고 있다. 개발된 PDU의 주요 특성은 업데이트 비트 FlexRay 네트워크 통신 기능은 AUTOSAR와 완벽하게 호환되는 PDU (Update Bit)에 의해 정의되며 네트워크상 (Protocol Data Unit)를 사용한다. PDU는 애플리케이션 간 신호를 교환하고 사 의 프레임 발생과는 분리돼 있다. 따라서 네 【그림 1】시그널 및 PDU 처리, 그리고 송신 동작(IL)에 관한 추상 계층을 포함하는 CANoe 아키텍처 용자 애플리케이션을 통신부와 더 명확히 분리될 수 있도록 지원하는 논리적인 트워크상의 프레임은 업데이트되거나 업데 데이터 컨테이너다. 아우디는 PDU를 본질적으로 처리할 수 있는 버스 분석, 시 이트되지 않은 PDU를 동시에 포함할 수 있 뮬레이션 툴인 벡터(Vector)의 CANoe를 사용함으로써 즉각적인 이익을 얻을 다. 업데이트 비트 값은 사전에 정의된 신호 수 있었다. 를 통해 시각화되거나 평가될 수 있다(즉 그 래픽 창 이용, 그림 2). 간단한 분석 또는 시 ···· 글│볼프강 브란트슈태터 (Wolfgang Brandstatter) 칼스텐 뷔케(Carsten Boke) FlexRay 하드웨어, 프로토콜 개발팀 네트워크, 분산시스템 툴 개발 선임 뮬레이션 기능을 위해 만일 수신된 PDU가 AUDI AG Vector Informatik GmbH 계속 업데이트되지 않는다면 이 PDU를 무 시하는 것이 기본 기능이다. 하지만 상세한 분석의 경우, 업데이트되지 않은 PDU는 선 프레임-지향적인 FIBEX 2.x 데이터베이 기능들을 통합할 수 있게 도왔다. 아우디에는 가 FlexRay 개발 툴 CANoe.FlexRay의 내 택적으로 디스플레이 돼 시뮬레이션 노드로 스 포맷이 발표됨에 따라 네트워크 노드들 CANoe 서비스 팩이 정기적으로 제공되었기 부 구조와 기능에 미친 영향과 아우디의 엔 전달될 수 있다. 뿐만 아니라 이들의 페이로 간 PDU 통신 정의를 위해 새로운 디스크립 때문에 PDU 통신 스택을 사용한 ECU 테스 지니어들이 벡터의 적절한 툴 지원으로부터 드(payload)를 포함하는 FlexRay 프레임들 션 시맨틱(description semantic)이 필요해 트를 초기부터 할 수 있었다. 아우디는 최신 얻은 효과에 대해 설명한다. 은 디스플레이 되어 소위 로 프레임(Raw 졌다. 아우디는 이러한 간극을 극복하기 위 FIBEX+ 데이터베이스 버전을 벡터에 제공 Frame)으로서 수신될 수 있다. 아우디는 통 해 FIBEX+ 디스크립션 시맨틱을 개발했다. 함으로써 CANoe와의 호환성을 계속해서 유 합 테스트를 진행할 때 이와 같은 PDU 기반 【그림 2】CANoe의 그래픽 및 트레이스 창에서 PDU의 갱신 비트에 대한 시각화 벡터는 자사의 툴을 통해 FIBEX+를 즉시 지할 수 있도록 했다. CANoe를 이용한 지속 네트워크 분석을 위한 PDU 레이어 분석 기능을 많이 사용했다. 지원할 수 있었다. 아우디는 FIBEX+에 대 적인 검증을 위해 아우디는 최신 FIBEX+ 데 한 경험을 얻는 동시에 ASAM(Association 이터베이스 버전들을 벡터에 제공했다. PDU는 하위 레벨의 신호(signal)들을 적 프레임들을 정의함에도 불구하고 본래의 야 한다. 분명히 데이터 업데이트가 없지만 업 for Standardisation of Automation and 이같이 아우디와 벡터 간 긴밀한 협력 관 절하게 배치한 상위 레벨의 통신 데이터 컨 네트워크 시뮬레이션을 위한 PDU는 이러한 특성을 가지고 있지 않다. 데이트 비트가 1로 설정되어 PDU의 자동 전 Measuring Systems [1])의 새로운 FIBEX 계는 툴 개발 속도를 가속화하는 동시에 테이너, 즉 메시지로 정의할 수 있다. PDU PDU 레이어 PDU가 업데이트되지 않는 경우에 수신기는 송이 요구된다면 네트워크 설계자들은 이러 3.0 표준에 PDU를 도입했다. FIBEX+와 신형 FIBEX 3.0 기반의 는 CANoe와 같은 분석, 시뮬레이션, 테스트 일반적으로 PDU를 인식하지 않는다. 수신 한 PDU가 주기적인 타이밍을 가지도록 정의 아우디의 지속적 피드백은 벡터의 엔지니 FlexRay 네트워크를 위한 전문적인 분석과 기능을 지닌 툴들을 이용해 관리한다. FlexRay 프로토콜이 (심지어 업데이트 기를 주기적으로 트리거(trigger)하기 위해 할 수 있다. 이런 이유에서 PDU 레이어의 최 어들이 툴 개발 초기 단계부터 중요한 PDU 플랫폼 개발을 가능하게 했다. 본고는 PDU FlexRay 프레임은 복수의 PDU를 포함할 사항이 없는 경우에도) 주기적으로 전송될 서 PDU는 반드시 주기적으로 업데이트되어 상위에 상호작용 레이어(Interaction Layer)
78 www.autoelectronics.co.kr 2009 APR·MAY 79
1/16 1/17 Development Feature
를 개발해 제약요소들을 처리했다(그림 3). FlexRay 프로토콜의 확장 기능으로써 PDU 는 업데이트 비트가 1로 설정되면 (거의) 임 의적인 주기로 전송되기도 한다. 아우디는 메시지 카운터와 체크섬(check sum)을 정의했는데 이것은 PDU의 선택적 【그림 3】CANoe의 상호작용 계층(IL)에 의한 PDU 송신 동작 제어(갱신 비트 세트와 함께 메시지 카운터, 인 속성이다. 사실 PDU의 업데이트 비트, 유저 CRC 등의 확장 속성 지원을 포함한다) 메시지 카운터, 체크섬 등은 상호작용 레이 어를 통해 CANoe의 애플리케이션에 상관 없이 독립적으로 설정되기 때문에 나머지 에 따라 각기 다른 프레임들에 위치하거나 플리케이션에 따라 신호의 무결성을 검증할 버스 시뮬레이션 과정을 단순화시킨다. 따 다양한 PDU 세트가 프레임에 포함될 수 수 있다. 아우디의 엔지니어들은 초기 개발 라서 엔지니어는 적절한 신호값을 설정하기 있다. 이로 인해 FlexRay 프레임에 대한 단계에서 성공적으로 부적절한 PDU 업데이 만 하면 된다. 또 다른 사용 사례로는 ECU PDU 맵핑은 전송 가능한 시간을 면밀히 트 타이밍들을 감지했다. 이러한 테스트들 의 반응을 테스트하기 위해 나머지 버스 시 고려해야 한다. 이것이 충분히 빠르지 않다 은 PDU를 위한 CANoe의 테스트 기능(Test 뮬레이션 과정에 명확한 고장 사항들을 삽 면, 프레임 슬롯 실패(frame slot miss)를 Feature Set)에서 완벽하게 지원되고 있다. 입하는 것이다. 따라서 CANoe 자동 기능은 예상해야 한다. 벡터는 VN 시리즈의 뿐만 아니라 자극 및 응답 관찰을 위해 PDU 모두 사용할 수 없고 상호작용 레이어가 고 FlexRay 버스 인터페이스에 대해 이러한 는 PDU 패널(panel)과 잔여 버스 시뮬레이 장 유발 수단으로 사용될 수 있다. 기능들이 하드웨어 상에서 동작하도록 구 션(CAPL, MATLAB 모델 등)을 이용해 상 ECU와의 통신 기능을 시뮬레이션하는 것 현했다. 호 동작할 수 있다. 이 패널을 이용해 신호를 은 특정 이벤트의 발생에 의해 좌우된다(이벤 입력하거나(Input Panel), 상위 레벨의 프로 트 기반 시뮬레이션). 가장 중요한 이벤트 중 토콜(전송, 진단)을 조작할 수 있다. 의 하나는 메시지 수신 또는 신호값 변경 등 PDU 기반 네트워크 테스트 이다. 이와 같이 PDU 수신 및 신호 변화를 알려주는 공지 핸들러(notification handler) 아우디는 물론 아우디의 티어1(Tier 1) 결론 효율적인 Ethernet Control Unit 개발 는 PDU 레이어에 의해 트리거된다. 공급업체들 역시 CANoe의 AUTOSAR 기 능들로부터 이점을 얻을 수 있었다. 이것은 PDU 기반 통신은 네트워크 변경 시나리 ECU의 AUTOSAR 통신 스택(특히 PDU 오, 예를 들어 CAN 네트워크 애플리케이션 성능측면 라우터)들을 테스트하기 위한 통신 적합성 을 FlexRay 네트워크로 포팅하는 경우뿐만 (communication conformance) 확인을 아니라 새로운 FlexRay 개발을 위해서도 사 벡터 차량용 Ethernet 솔루션 추가적인(하지만 반드시 필요한) PDU 레 포함한다. 이때 버스상의 실제 데이터인 용할 수 있다. 이어는 몇 가지 오버헤드를 생성한다. 로 프레임(Raw Frame)과 데이터베이스 아우디는 FIBEX+를 통해 경험한 교훈들 FlexRay 프레임을 수신할 때 프레임으로부 기반 해석(PDU 추상 레벨)을 비교할 수 을 통해 FIBEX 3.0 개발에 상당한 영향을 터 PDU를 추출해 애플리케이션의 해당 공 있는 성능이 매우 중요하다. 이를 통해 아 미쳤다. 벡터는 FIBEX+에 대한 경험들을 벡터의 솔루션은 차량에서 사용되는 특정 물리 계층은 물론 SOME/IP, AVB, DoIP 등의 프로토콜을 지원합니다. 지 핸들러로 전송해야 한다. 동일한 PDU에 우디 엔지니어들은 초기 단계에서부터 버 통해 새로운 FIBEX 3.0 표준을 CANoe로 상이한 프레임들이 포함될 수 있다. 따라서 스상의 FlexRay 프레임 내에서 부적절한 신속하게 지원할 수 있었다. 통신 기능이 한 > Ethernet 네트워크 및 컨트롤러의 시뮬레이션, 분석 및 > 소량 양산, 평가 및 개발을 위한 범용 Control Unit 및 PDU 레이어가 프레임들로부터 PDU를 일 PDU 또는 업데이트 비트 위치를 식별할 층 복잡해지고 광범위해짐에 따라 적절한 테스트를 위한 툴 제공. 다른 버스시스템도 병렬 사용 AUTOSAR 베이직 소프트웨어 지원 가능 > 자동차 분야의 Ethernet 기술 관련 교육 제공 종의 디-멀티플렉싱(de-multiplexing)한 수 있었다. 모델링 표준들(예를 들어, FIBEX 3.0 또는 > 왜곡 없는 Ethernet 네트워크 액세스를 지원하는 (국내 교육은 2018년 하반기 도입 예정) 다. 이러한 절차들은 상당히 최적화 돼 있다. 테스트는 2가지 범주로 구분될 수 있다. AUTOSAR)뿐만 아니라 전문적인 툴 지원 인터페이스 PDU를 전송할 때 적절한 프레임에 저장 첫째 업데이트된 PDU와 관련해 애플리케이 이 효율적인 FlexRay 개발에 있어서 필수적 > 차량용 임베디드 소프트웨어 제공 자세한 정보: www.vector.com/ae 해야만 한다. PDU는 현재의 (사이클) 시간 션의 전송 동작을 확인할 수 있으며, 둘째 애 인 요건이 되고 있다.
벡터의 차량용 Ethernet 솔루션이 귀사의 성공적인 개발을 지원합니다.
80 www.autoelectronics.co.kr
1/18 1/19
Vector Korea IT | Phone +82 2 807 0600 | www.vector.com DEVELOPMENT FEATURE
이더넷을 사용하려면 동기화 기술이 물리 계 보통 유효 패킷만 모니터 포트로 전송돼 에러 한 대기시간 또는 불완전한 패킷의 필터링 때 층(OSI 계층 1)보다 더 높은 프로토콜 계층에 를 분석하기도 어렵다. 게다가, 비용 때문에 문에 시스템이 영향 받지 않도록 하는 것이다. 서 요구된다[예: AVB(오디오 비디오 브릿징, 생산 시스템 내 미러링을 위한 스위치에는 추 이것은 물리 계층(그림 4의 경로 1)에서 데이 그림 1)]. 또한, 분석 요건도 새로운 아키텍처 가 모니터 포트가 제공되지 않는다[4]. 터를 수동으로 획득 및 라우팅하는 소위 에 맞춰 계속 증가하고 있다. 예를 들어, 만약 만약 주어진 스위치에 어떤 추가 포트도 사 TAP(테스트 접근점)(그림 3)에 의해 이뤄진다. 개발자가 백본 상의 모든 데이터 트래픽을 동 용할 수 없는 경우, 기존 연결부에 스위치를 이 과정에서, 대기 시간은 매우 짧을 뿐만 아 시에 분석하려고 하면, 접근이 모든 경로 브랜 추가할 수 있다. 그러나 이러한 추가 홉은 투 니라 일정해, 특히 AVB 시스템 분석에서 이 치 상에서 반드시 동기화돼야 한다(그림 2의 명하지 않으며, 이것은 전체 전송 경로에 걸쳐 롭다. 투명한 모니터링의 또 다른 방법은 경로 a, b, c, d). 지연을 초래한다. AVB 시간 동기화를 지원하는 스위치를 사용 두 번째 문제는 개발자가 엄청난 양의 데이 AVB 프로토콜에 의해 동기화되는 네트워 하는 것이다. AVB 프로토콜이 패킷이 라우팅 터를 처리하려면 새롭고 적절한 필터 전략을 크에서는, 상황에 따라 이러한 동적인 지연이 될 때 발생하는 대기시간을 상쇄해준다. 반드시 활용해야 한다는 것이다. 이러한 상황 시간 동기화를 방해할 수 있다. 이러한 측정 어느 방법을 선택하든지, 패킷 데이터를 정 은 초당 기가비트 범위의 전송 속도를 원하는 장치의 경우, IT 분야에 공통으로 사용되는 툴 확히 분석하려면 가능한 한 물리적 계층 가까 OEM들에 의해 더욱 심화될 전망이다. 이미 및 스위치를 활용하는 것이 가능하다. 그러나 이에서 획득된 정확한 타임스탬프가 필요하다. 이를 위한 물리 계층인 RTPGE(Reduced 자동차 업계에서 일반적으로 사용되는 또한, 네트워크 분석은 보통 1개 이상의 이더 차량용 이더넷 사용을 위한 과제 Twisted Pair Gigabit Ethernet)가 개발 단계 BroadR-Reach 네트워크에서는, 표준 이더 넷 경로에 집중하므로 설정된 타임스탬프는 에 있다. 넷(IEEE 802.3)으로의 미디어 변환이 필요하 다른 인터페이스와 반드시 동기화돼야 한다 유연한 인터페이스 및 소프트웨어 툴을 통한 ECU 개발 간소화 다. 더구나, 자동차 네트워크 개발의 관점에서, (그림 2). 인터페이스가 시스템 성능에 미치는 이러한 툴은 보통 배타적인 해결책이며, 아직 비활성 인터페이스의 경우, 투명한 작동도 영향 최소화 중요 공통 버스 시스템에 대한 어떠한 기준도 중요하다. 예를 들어, 만약 인터페이스 하드웨 올해 처음으로 이더넷이 양산 차량의 시스템 네트워크로 사용될 전망이다. 따 버스 시스템과 달리, 특별한 측정 시 시스 가지고 있지 않다. 어가 테스트 드라이브용 차량 내에 설치돼 있 라서 다음 단계는 이더넷을 CAN, FlexRay, LIN 및 MOST와 같이 이미 구축 템에 영향을 미치지 않아야 한다. 한편, 개발 다면, 그 인터페이스는 측정 애플리케이션이 된 자동차 기술과 통합하는 것이다. 이미 이기종 네트워크를 분석하기 위한 기 자는 시스템 설계 초기에 테스트 능력을 반드 투명한 이더넷 분석 비활성이어도 사전 설정된 독립형 모드를 반 능성 개발 툴은 존재한다. 그러나 이더넷의 경우 사무용 통신을 위한 표준 툴만 시 고려해야 한다(설계에서부터 테스트까지). 스위치를 인터페이스로 사용하는 방법 대신 드시 자체적으로 가정해야 한다. 그렇지 않은 존재할 뿐 자동차의 특수 물리 계층 및 IP 프로토콜을 지원할 수 있는 툴이 준 또한, 툴 생산자는 인터페이스의 영향을 반드 가능한 한 가장 투명하게 네트워크를 감시하 경우, 일부 이더넷 경로가 운전 중에 방해를 비돼 있지 않다. 따라서 이더넷 네트워크와 함께 기존 버스 시스템을 분석하고 시 최소화해야 한다. 다음은 분석 및 테스트용 는 것이 바람직하다. 여기서 중요한 것은 증가 받을 수 있다. ��� 테스트하는 데 사용할 개발 및 테스트 툴이 필요하다. 벡터가 이더넷과 기존 버 각종 측정 장치에 대해 다룬다; 이러한 장치 스 시스템 분석 테스트 툴의 조건을 말한다. 사용 시 발생할 수 있는 바람직하지 않은 결과 는 물론 이러한 결과를 최소화할 방법이 함께 글│한스-베르너 샬* (Hans-Werner Schaal), 마티아스 슈베트 **(Matthias Schwedt) 제시돼 있다. 벡터(Vector Informatik GmbH)
기존 측정 장치의 한계 이미 첨단 기술인 비차폐 꼬임 쌍선(UTP: 활용하는 것이다. 일부 OEM은 이더넷이 자동차 이더넷 테스트 솔루션의 과제 이더넷 네트워크를 분석하는 일반적인 방법 Unshielded Twisted Pair) 커넥션을 통해 경 2018년부터 백본이 될 것으로 예측한다[2]. 다 자동차 이더넷 사용 시 개발자 및 테스트 은, 시스템 내 구현된 스위치에 추가 포트(모 제적으로 차량 내 카메라 영상을 100 MBit/s 수의 전문 논설[3,4]에 기술된 바와 같이, 이더 엔지니어는 두 가지 문제에 대해 다시 생각해 니터 포트)를 사용하는 것이다(미러링). 스위치 의 속도로 전송하는 것이 가능해졌다. 이 기술 넷은 특히 인터넷 프로토콜과 결합해 자동차 보아야 한다. 첫 번째 문제는 분명한 도메인 로부터 수신된 모든 패킷은 이러한 모니터 포 은 BroadR-Reach로 알려진 기술로 OPEN 사용에 유연성, 확장성 및 비용 절감의 효과를 아키텍처(그림 2)를 구축해야 하는 것이다. 이 트에서 전송된다. 이때 모니터 포트는 수신된 Alliance SIG 컨소시엄[1]에 의해 표준화돼 있 제공한다(그림 1[1]). 더욱이 이러한 IT 기술을 아키텍처에서, 백본은 버스 시스템이 아니라 데이터 패킷에 접근할 수 있게 하지만, 이러한 다. 다음 목표는 이더넷을 2015년까지 인포테 활용한 방법은 자동차 개발 과정을 더욱 풍요 다중 전 양방 연결을 한 교환망으로 구현된다. 데이터 패킷은 공통 시간을 참고하지 않기 때 [그림 1] UDP, TCP 및 IP와 같은 이미 친숙한 사무용 통신 프로토콜과 함께 자동차에만 특별히 최적화된 프로토콜 인먼트 및 운전자 지원 시스템용 네트워크로 롭게 할 것이다. 실시간 주요 애플리케이션을 실행하기 위해 문에, 타임스탬프를 가지고 있지 않다. 더구나, 이 사용된다. 이러한 프로토콜은 ISO CD 17215-1에서 기술된다.
92 www.autoelectronics.co.kr 2013 SEP·OCT 93
1/20 1/21 DEVELOPMENT FEATURE
되기 전에 어떤 유형의 시나리오를 테스트하는
방법이다. 테스트를 위한 필요 요건은 다음과 외부 미디어 컨버터와 오피스 통신 분야의 같다. 첫째, 제한되지 않은 고성능 네트워크 접 고성능 분석 툴을 함께 사용하는 것은 매우 간 근을 허용하는 하드웨어가 필요하다. 둘째, 애 단해졌다. 그러나 언급된 요건은 오직 분석 및 플리케이션은 기록되거나 자체 발생한 데이터 시뮬레이션 소프트웨어에 딱 들어맞는 전문화 를 하드웨어로 반드시 전송할 수 있어야 한다 된 하드웨어에 의해서만 구현될 수 있다. 실제 (그림 4의 경로 4). 셋째, 하드웨어와 소프트웨 로 이미 Vector의 VN5610 Ethernet/CAN 어의 결합은 반드시 패킷을 수신하고, 패킷을 인터페이스가 CANoe.IP 개발 툴과 함께 쓰이 손상시킨 후 손상된 패킷을 전송할 수 있어야 고 있다. 현재 일부 자동차 OEM 및 공급업체 한다. 이를 통해 프로토콜 에러와 같은 특정 에 는 이러한 방법을 사용 중이다. 러에 대한 ECU의 반응을 테스트할 수 있다. 전망 유연한 인터페이스/소프트웨어 조합 다음 5년 내지 10년 동안, 이기종 네트워크 [그림 2] 향후 가능한 자동차 ＩＰ 네트워크의 도메인 아키텍처. 모든 이더넷 패킷 분석이 가능해지려면 분석 SW가 반드시 모든 이더넷 경로로 동시에 접근해야 한다. 의 주요 특성 구조는 차량 내에 확립된 버스 시스템의 클러 위에서 설명된 측정 장치는 이더넷 네트워크 스터로 계속 사용될 것이다. 카메라 애플리케 의 분석이 하드웨어 및 소프트웨어에 어떠한 이션 이후, 이더넷은 다른 시스템 도메인에도 사항을 요구하는지 보여준다. 측정 장치에 따라 사용될 것이며, 버스 시스템을 교체할 것으로 인터페이스를 변경하지 않으려면, 인터페이스 예상된다. 또한, 이더넷 및 IP 기술은 백본으로 를 TAP, 컨버터 또는 추가적인 기능을 갖춘 스 사용된 후 다른 자동차 응용 분야에도 침투할 위치로 유연하게 사용할 수 있어야 한다. 다음 것이다. 은 그 인터페이스의 바람직한 특성을 나타낸다: 차량 네트워크 개발자에게 모든 데이터 패 킷에 대한 다중 버스의 성능, 통신 버스 시뮬 - 가장 간단한 사례로 인터페이스를 TAP 레이션 및 낮은 레벨에서의 타임스탬프의 중
으로 사용할 때, 그 TAP 자체는 정확히 [그림 4] VN5610 Ethernet/CAN 인터페이스는 CANoe.IP/CANalyzer.IP와 함께 이더넷 네트워크 통신에 수 요성은 더욱 커질 것이다. 이더넷 및 IP 분야 동 및 능동적으로 참여한다. 유연한 구성은 분석 및 테스트를 위한 여러 다른 측정 장치를 지원한다. 명시 가능한 대기시간을 최소한으로 발생 에서 Vector는 모든 IP 프로토콜 계층(그림 1) [그림 3] 분석 또는 통신 버스 시뮬레이션 시 가능한 이더넷 인터페이스 배선. 기존의 자동차 버스 시스템과의 시켜야 한다. 에 걸친 신호 표현을 지원하고 AVB 및 동시성이 요구된다. - 인터페이스는 BroadR-Reach, Fast - 시뮬레이션 소프트웨어와 함께 하드웨어 터를 분석 및 조작하기 위한 분석 및 시뮬 SOME/IP와 같은 프로토콜을 통해 실시간 서 Ethernet, Gigabit Ethernet 및 향후 인터페이스는 하나 또는 여러 개의 가상 네 레이션 툴이 반드시 사용 가능해야 한다. 비스 관련 통신을 포괄적으로 점검해 다음 개
시뮬레이션을 갖춘 TAP 한 가지 방법은 두 노드 사이에 정상적인 RTPGE와 같은 모든 공통으로 사용되는 트워크 노드에 실질적인 매체 접근을 반드 - 이기종 네트워크를 지원하려면, 공통된 발 단계를 이끌어 갈 것이다. AE 순수 데이터 분석과 함께, 의도적으로 어떤 통신이 이뤄지는 동안 테스트를 위해 불량 데 매체들 사이에서 반드시 변환 가능해야 시 허용해야 한다(통신 버스 시뮬레이션). 버스 시스템을 모두 가진 인터페이스를 패킷을 전송하게 해 네트워크를 자주 테스트 이터를 추가로 전송하는 것이다(그림 4의 경 한다. 이를 통해 지금까지 필요했던 외부 - 모든 OSI 계층 및 프로토콜 수준의 데이 반드시 동기화할 수 있어야 한다. 해야 한다. 여기서도 순수 모니터링에서와 같 로 3). 이 데이터는 Vector CANoe. IP와 같 미디어 컨버터를 사용할 필요가 없어진다.
이 어떤 두 노드 간 연결에 미치는 영향은 최 은 테스트 애플리케이션에 의해 직접 공급되 - 시험 운전의 경우, 차량 내에 인터페이스를 참고자료
소화해야 한다. 그러나, 이러한 보충 패킷은 거나 정의된 버스 부하를 인터페이스에 바로 설치하는 것이 반드시 가능해야 하며, 인터 [1] OPEN Alliance SIG, http://www.opensig.org/ 물리적 계층 상에서 전송될 수 없는데, 요구되 발생시키는 패킷 발생기에 의해 공급된다(그 페이스가 사용되고 있지 않은 동안 네트워 [2] Das IP-basierte Bordnetz kommt “The[ IP-based on-board electrical system is coming”], Elmar Frickenstein, BMW AG, SEIS Statusseminar,2011- 20-09, http://www.strategiekreis-elektromobilitaet.de 는 추가적인 흐름 제어가 계층 2까지 불가능 림 4의 경로 2). 크(독립형 모드)를 방해하지 않아야 한다. [3] Ethernet und IP im Kraftfahrzeug: Neue Anforderungen an das Entwicklungswerkzeug durch denEthernet- und IP-Einsatz “Ethernet[ and IP in motor vehicles: New development tool requirements for the use of Ethernet and IP”], Hans-Werner. Schaal, Elektronik automotive, April 2012 하기 때문이다. 여기서도 역시, 동적 대기시간 - 패킷 발생기는 소프트웨어 또는 하드웨어 [4] Herausforderungen von Ethernet-Debugging “Challengesof[ Ethernet debugging”], Helge Zinner, www.elektroniknet.de, October 2012 이 발생하는데, 이것은 인터페이스에 있는 프 통신 버스 시뮬레이션 수준에서 중요한데, 분석과 함께 자동차 [5] ISO CD 17215-1 (E) of 2012-07-02 [6] Schnelle Wege zur Restbussimulation: Virtuelle Netzwerke ohne Programmier-Know-how erstellen “Quick [ paths to remaining bus simulation: 로토콜 지원(예: AVB 프로토콜)에 의해 바로 특히개별ECU를개발할때, 통신버스시 개발 과정 역시 제어된 시뮬레이션을 요 Creating virtual networks without requiring programming know-how”], Stefan Albrecht and Peter Decker, Automobil Elektronik,March 2012 [6] 상쇄될 수 있다. 뮬레이션 은 ECU가 실제 네트워크 내에 통합 구하기 때문이다. 링크: Vector 홈페이지: www.vector.com / IP 제품 정보: www.vector.com/ip
94 www.autoelectronics.co.kr 2013 SEP·OCT 95
1/22 1/23 DEVELOPMENT FEATURE AUTOSAR UIFSOFUਸ ಿ&
חSPBE33FBDI# ח ࢶਸ ਊೞ ࠛҗ ݻ ֙ ө݅ ӝࣿਸ ਊೞݶ ӝઓ ࢲ࠺झࣃఠ QBJS җ ࠺/"$ ח ؘחਸ ઁҕೞ పझఠܳ औѱ .# ױ֎ਕী %P*1ӝ߈ חীࢲ ࢎਊೞର ب೧ بݴ ߓࢶ ࠺ਊبߓա ࡅܲ ࣘ ٸ ীࢲ ؊֔ਸ Үೡର חߡझ दझమ $"/җ ాೡ ࣻ %P*1 ೠ ӝࣿ ߔࠄ ইఃژח ࣅઑ݅р ѱ ٜ ঋװ ӝ߈ਸ ۾ب ࠗ ࠁ և ࢎਊೡ ࣻ /*- झਤட ߑध ֎ਕ חҙब ୡ ؊֔ਸ ఫܳ ҳഅೡ ࣻ ݶغ ೠ ࣻਃ৬ ӝରо ࠗп ী Ӓܿ ҕೠઁ ب TXJUDIFEOFUXPSL ӝࣿী ॕܻѱ ؼ Ѫ ౠ 9CZXJSF ਊೠ ର উ ର 0&.সٜҗ ࠗಿসٜ ҙزࣗ അ ח җীࢲ ӝରա ೞ࠳ܻ٘ ט ೠ ਃҳо दझమী VEJP 7JEFP" 7#" חبਊ חա बਸ ыҊ "$%$ ഋక MFY3BZܳ ৬ Үनਸ ೧ঠ ೠ' ۄٮ যթী ѐ۽ӒܻҊ ࢜ ֎ਕ ҙܻ ١ #SJEHJOH ਃӘ ߂ ࠛߑߨ दр ੌदغ ࠁәೞѱ ѐߊ ࠁܳ Үജೞӝ ਤ೧ 5$1*1Wҗ ਊ ֛ ѱਝ &$6١ ݣ౭٣ بળ 045. ష۽җ ࣠ઁয *1 ష۽ఠ֔ ੋ ۽ 4NBSU $IBSHF $PNNVOJDBUJPO গܻா 4$$ ױয ࠙ঠ 6TFS ష۽ ۔ ࢎਊ ؘఠӒ 5$1 షਸ ਊೞѱ ؼ Ѫغഛ݀ ۽࣌ਵ ਸ Ѿೠ ؊֔ 6%1 MFY3BZ৬ ળഋ ؊֔ ରತ ா࠶ ߓࢶ ࠺ਊ %BUBHSBN 1SPUPDPM' ܻ׳ җ/"$ ా ղ ֎ਕী օܻ ਊೞӝ য۵ ؘఠ ೱ ాनীࢲ ࢲ࠺झ ೱ ࠂೞҊ Ҋо ࠺ऱ ର ח045. חೞѱ ೠ #.8מജਸ о ۽க नߑधਵܻ҅ޛ #SPBE33FBDI۽ ߡझ दझమ Ӓ۞ա ࢜ 4FSWJDF 0SJFOUFE .JEEMFXBSF ղ ాन 40.&*1 ؊֔ਸ ର ॄ۽ੑೣਵب ਸ 1): ӒܻҊ ۠ ߡझ ীޙٸ ۳ച חۄ 5XJTUFE PWFS *OUFSOFU 1SPUPDPM ӡਸ ৌ51 חࢲ࠺ ী ਊೡ ࣻ חदझమਸ ਊೞ झࣃఠ ֎ਕо ࠗ ী $"/ ৈޙٸ ೞӝ ਸ ਤೠױ ର غࢎਊ ۽৻ࠗ ࣘਊਵ Ҋ Ӓ۞ա $"/ ীޙٸ যդ ؘఠনט җ ೠػઁ दр חغؘ ࣗਃח߁ೞېӒ۽ $6ܳ& חӝ द೮ୡӝীغࠁә بীର ۽Ҋ ࣼೠ ֎ਕ ӝࣿغېয় بݶࢲ۽؊֔ ࢜ ܳઁޙ ۞ೠ ݻ ֙ غ যաѱט ղ ؊֔ ֎ਕ ѱ ର חਵա ઁغࢎਊ ݅۽ഋ ਊਵמগܻா࣌җ ӝର ױ ӝ߈ *1 ష۽ ӝࣿਸ "6504"3ী ా ೧Ѿೞӝ ਤ೧ ੋఠ֔ ؊֔ ౠࢿҗ ਸ ࢸݺೞҊ חҊ Ӗীࢲغҳഅ ب ష۽ ع ѐߊ %P*1 नా ױ חؘ ࢎਊೡ ࣻ ח গܻா࣌ਸ ҳഅೞ۽ೠ ࢜ژ ೧ ֤ೠ ীઁޙ חदః ղ ֎ਕী ؊֔ਸ ਊೠ ୭ୡ ࣗѐೠ ର ب೧ࢲ 3؊֔ झఖ ഛী"6504" غળച ۽ਵݴ *40ਵبद ӖȈ݃ܰ ߬ߡ .BSD8FCFS ҕࢳࢎ 7FDUPS*OGPSNBUJL ী ޙٸ ח և ؊֔ ীࢲ ؊֔ झఖ ઁಿ ҙܻܳ ೞҊ ੋۄ ࣗਝয ઁಿ ߭ఠ ߬٣٘ ݫੋ ইఃఫب ਫ਼ഋ ରېোѾػ ۽Ҋ Ӓܿ ]؊֔ਵغࢎਊ ۽पա ੋఠ֔ ࣘਊਵޖࢎ ۽
94 www.autoelectronics.co.kr MAR. APR 2014 95
1/24 1/25 DEVELOPMENT FEATURE
ؘחషਸ ѐߊ೮۽ TFSJBMJ[BUJPO ਗѺ ର ഐ חী מష ӝ۽ 31$ 3FNPUF 1SPDFEVSF $BMMT Ѫ ࢲ࠺झ Ѩ࢝ חషਸ ࠁ৮ೞ۽ ۽ష۽ 4% 4FSWJDF %JTDPWFSZ షਸ۽4% חয &$6غೠ ژ ా ਊ೧ ాन ݽٕী ࢲ࠺झ оਊ ৈࠗܳ ೠ &$6ীࢲ ࢲ࠺झܳ Ѩ࢝ೞҊژ ࠁೠ ࢎਊೡ ࣻ بؘী חೞ۾١ ߮ܳ
؊֔җ "6504"3 ؊֔ "6504"3 ߡ റ غ ળ ੌࠗо 3"6504" 3ইఃఫীࢲ ؊֔ ాन झఖ"6504" ۽'MFY3BZझఖٜҗ ߽۳ $"/җ -*/ ܻ׳ חਤ೧ Ӓ۞ա ܲ झఖٜҗ ٜয מ3ݽٕҗ ӝఋ ਬਊೠ ࠁઑ ӝ"6504" חӒܿ ]߭ఠ "6504"3؊֔ झఖ .*$304"3*1ী Ӓܿ ]؊֔ झఖ "6504"3٣झ݀࣌ ੌਸ ਊ೧ ࢸೠ ష ҅க *1߂ 6%1۽؊֔ ࢚ਤ ٜਸ ы୶Ҋ מ5$1ী ҙ۲ػ ౠࣻ ӝ ݎ হ מ ӝۄ חী 9$1 ష۽ೞप מਊ о ۽ࢲޙ ݽٕҗ അ೯ ળ ࠗ &UI5SDW ߡۄ٘ दߡے؊֔ 7# ೠ о ౠ ؊֔ਸ ా೧ য়" 9$1 חীٸ ࢎਊೡ ۽ࣘਊਵ ղ ؊ ؊֔ਸ ର ର 9݅&#*' חইө ۽ઁ য ঋغ߸ജೞ ؘఠ ઁҕ ӏ ۽ߑೱਵ߸ജೞѢա Ӓ ߈ ۽ ݽٕ ܲ ֎ਕ ӝ߈ਵ &UI ߡۄ٘ ؊֔ 5JNF ӝചز ٣য়࠺٣য় झܿਸ दр োѾ ۽ࢎਊೡ ܳ ా೧ ؊֔ ֎ਕী ਵ ۽٣झ݀࣌ ನݘਵ ֔ ֎ਕਊޖ 4P"E Ѫ ࣗ যఠ ݽٕ ח ӝٜࣿҗ ഐജࢿਸ оҊ ߈ݶী ؊ ۾ب࣠ೡ ࣻ ۽ ߑधਵ ݽٕ ܰ$"/ա ݽٕ ࢚ਤ ۨ߰ ݽٕী "6504"3ই "6504"3 ؊֔ ਗ ഛ ࣻ '*#&9 അ "6504"3 ػ ݽٚ &$6ܳ ܻ࠳ۨ࣌ ೡ ਃо 4ZODISPOPVT &UI*G ఠಕझੋ ֔ &&&* Ѫ ৈӝী ਃೠ חର 0&.স৬ ഈ۱ ೧ળز ੌة ח٣झ݀࣌ ನݘ ߭ఠ о ف ী ഐജػ ݶࢲغੑب ղ ؊֔ ֎ਕо ࣼೠ ର חغ3 ఃఫ ؊֔ झఖী ৮ ా"6504" חMFY3BZੋఠಕझ' /*- ష ߭ఠীࢲ द౸ "7#۽ਸ ѐߊ೮ѱਝ ࣠ ્פ೧ ܳ ਤೠ ݫழ ۽ࠁ ࣚप হ ࢲ بۄঋ؊ חೞੌز दఆ ח۽ੋఠಕझী 1%6ੋఠಕझܳ ઁҕೠ "6504"3 ؊֔ झఖਵ 1%6 ష ؘఠ ਬ۽ ਸ (FOFSJDמӝച ӝز അ दр ח ۽ ܳ ా೧ %P*1ܳ ೞਤ ؊֔ ֎ਕڷ ח߸ജदఆ ࣻ ۽ܳ ܲ ನݘਵغف ਃҳࢎ೦۽࢜ חࣻ হ ۽؊֔ ੋఠಕझীࢲ "6504"3ী ӏػ ؊֔ झఖਵ ߈ݶ חغҳഅ ۽ਵ ҅ױ חѪ *40ળ ӏѺী ӏ 1SFDJTJPO5JNF1SPUPDPMҗ ాदః חೞۄ 3 ؊֔ झఖী"6504" ۄٮ ࣠ೞ ী ۽ও ٜয ৈ۞ ѐ 1%6ীࢲ ബਯਵװ ഥदః ؊֔ਸ ాೠ 1%6࣠ࣻन ӝୡܳ ۽ਗद ؘఠܳ 5$1*1झఖਵ ח ର ী৬زয ঋ Ӓ۞ա নೠ غఠച ೡ ࣻ ۄؘఠܳ ۽ਵزࢲ "6504"3 ࢲ ۄٮ Ҋ۰೮ ӝо ݒ ൨ٜয ب೧ࢲ ೠ %P*1 ਬझாझীژ Ѣա 5$1*1झఖীࢲ ؘఠܳ ࣻनೞ ؊֔ झఖҗ ח࣌ ѐߊਸ "6504"3 ߡ ীܖ 0&. সٜ ী ਃೠ ࣛ Ӓܿ ؊֔ झఖ җ э ѐࢶ חష ҳഅ ࣗ যఠ ীࢲ۽షٜ %P*1۽ 5$1 ೠ *1ա 6%1 بӝ ݻ о ٜয അמ ୶ೞҊ ҙ۲ػ ഛ ӝع য Ѫ ؊ ܖ ۽ झఖ ۞Ӓੋਵ ݅غझఖীࢲ ܻ 1*5$1 ١ਸ ળী ؊֔ झ 40.&*1ܳ ాೠ ؘఠ ۳ച ח3ীࢲ ೞҊ "6504" מী ਬਊೠ ࠁઑ ӝޖ؊֔ਊ 9$1ܳ ాೠ प חয ঋ Ӓ "6504"3ߡীࢲغী ୭ച 3"6504" ҳࢿػ 5$1*1झఖ ۽䤎 "6504"3ݽٕ ҅ ֢۱ਸ ೯ ۞ೠ ח߭ ನೣदః۰ ೠؘמҳੑ о ۽ఖ &$6ࣗਝয ח "6504"3 ӏѺীࢲ ә೮٠ ੌױ о *1ߡਸ فܻ࠳ۨ࣌җ 6%1ܳ ਊೠ ֎ਕ 䤎 *1W߂ *1Wਗ 6$& ۾ҕా ӏѺ 5$1*1झఖਸ ࢎਊష ۽۞ מ о ۽$6ղীࢲ ѐ߹߽۳& ࣠न৬ ࣻन р ాनীࢲ ؘ ח౸ݒೞ ദী ۽ಿਵઁ חۄनҗ э ؊֔ झఖਊ গܻா ఠীࢲ .*$304"3 *1ా$$4 ۄ٘ "6504"3ࠂ ١ਸ ਗೞݴ ӂҊೠ ҙܻ מࢎਊ о /"-7 ے 䤎 о࢚ ನೣػഅ بߑध ח ઁಿ "6504"3 ఠ ۳ചܳ ਗೞ Ӓܿ ঋҊ ৬ ҙ۲ػ *40߂ Ҋ ܖҕೠ 䤎 ࣗ যఠ ࢚ 1%6 ӝ߈ ؘఠ ࣠ ࣌ਸ ઁ بఠಕझੋ חܳ োѾೞ $EE ష ҅ৌ ಁ۞ ࣗ ߡ۽ 1*5$1 ബਯࢿ ૐ ࢲߡ োѾীࢲ݅ۄਸ ઁҕೞҊ ਵݴ ۞ೠ ߑध מӒ ѐߊী ଵ ߂ ী ݺदػ ӝ ب߭ఠীࢲ ؘחೠ ࣗ যఠ ੌ %*/ળ ؊֔ झఖ ؘ 䤎 ࢚ਤ ۨ߰ ݽٕী ח "6504"3 ীࢲ ױஸ ઙ۽ ࢎਊࣗ *1ࣗ৬ ਗѺ ߈ ੋఠಕझ ઁҕ ߣ૩ ాन ݽٕ ف חࢲীࢲޙ ೞܲמਗೠ ਤীࢲ әೠ о ب షਸ ࣗ যఠীࢲ ઁೞҊ ৈ೮ӝର ߂ ೞ࠳ܻ٘ ઁઑসٜ "6504"3۽䤎 %P*1 بস ח୶ೞ ۽ਵزఠܳ ۄध߹ೡ ࣻ ࣗਸ ా೧ ఠ ۽֢٘ ನ ܻ࠙ ۽ %P*1ݽٕب߹ ݽٕ ۳ച ؘחࢸݺೞҊ بੑب ਗೞݴ بೠ ղਊ ೠ ۞ೠ "6504"3ഛী ഋ ীמҗ ࠗಿসٜ ࢎ ۽షਸ "6504"3नӏ ݽٕ۽34ZTUFN 䤎 4%"6504" חಁఉ ೱ 6%1৬ ࣘ ೱ 5$1ࢎਊ ੌࠗ ਗೠࢎਊ ౠ߹ ࢸ ۾ب࣠ࣻनೞ ۽ؘఠܳ ബਯਵ بష ਃೞ ۞ೠ ਗਸ ୭ࣗചೞৈ 40.&*1ܳ ҳഅೡ ࣻ ۽FTDSJQUJPOա &$6ীࢲ ୶ೠ 4ZTUFN নച ળী ӏػ % ژ ؘఠܳ 5$1*1 झఖীࢲ গܻா࣌ 1* ח۽ അ ֤ ੋ ܲ ѐ֛ਵع҅ ೠ .*$304"3*1 ইఃఫژ৬ળب ۾ ష "6504"3؊֔ झఖী ݒՍۣ۽ ۽1*&.40 بই ח "6504"3ীࢲ ਸ ೡ ࣻ %FTDSJQUJPOীࢲ ؊֔ ֎ਕա ۨ ۽҃ ۽ߑೱਵ Ӓ ߈ ח ߥ۽ೲ ࣗ ೡҗ ܲ ֎ਕٜҗ Ӗ ۾بਸ ҳഅೡ ࣻ מഛ ӝ ۽Ҋё߹ ח Ѫ ࢚ חغѱ ా ܖೠ ࠁܳ ഛੋೡ ࣻ *1ࣗ షҗ 4$$ ਬझாझ ߂ "7#ܳ 1%6ী ח ಁ۞ "6504"3 1%6 ѐ֛җ ١ AE ӝചز ࠁಞ ஏܻ࠳ۨ࣌ ਊೠ दр ۽ӏѺ ࢚ਵ חೠ ࠁ ೠ ঋҊ 40.&*1ҳഅী ష ҅கী۽࢚ਤ ١ ࣗ ӝ߈ ాनਸ 1%6 ৬ ನ ח ঋغ ഐജ
96 www.autoelectronics.co.kr MAR. APR 2014 97
1/26 1/27 104 ,M^MTWXUMV\.MI\]ZM
ػݫद ࣠ࣽࢲীन҃ਸॳঋҊ Ѫҗэࠂೠחۨইਓਸਬೞ 7:25.6)1)/&,+)19,(02*,'3$5$:)1 '($1& 7)51)7+) ѱۄפҳഅೡࣻࡺ݅ইܳޖস ೠמоبਗਃҳחೞ۽ాनಁ۞ ਝоਃ۽ਊ֎ਕ࢜ର عੌࣻѱ ⯈⍜ㆴ㞨ᷨᤰⴠ-\PMZVM\+)6., $"/'%ݫद࣠җэ নೠ߮ܳా೧प೯ػ ীࢲօܻࢎࠗ࠙ରחغզ೯טয়۽ߡझदझమਵח$1(&8рాनਸೞҊ& ݫदߊनߡಌооٙଲ҃ ઑসٜ&$1ਸਊೠରઁҊӒ۞աాनࣻਃо؊ૐоೞݶࢲରରغਊ ೧ػఋইਸઁҕೞҊӝઓ ৮ࢿݫदী؊ևח'(ೠೠ҅ীݶೞҊ(WKHUQHWҗ&$1֎ਕী ػ҃ܐా ਓ݅۽࢜ח'(WKHUQHWҗ&$1)ب৻ীೞҊևߡझदझమੌࠗসਸ ೧ೠఋইਓೞ п1%6ীبੑীبनಁ۞ 1%6оನೣػݫदחػറীܐ݅ ۠ח1%6חѱ ܳೠ&$6оपઁࠁղظ$6оࠗ&חਊೞҊ
ೠदաܻয় оߊ࣠ীࢶఖػীبद ఋۄ۽ਃೠؘఠܳ&$6חᤀȈⓈ㭬➄(5IZK?MJMZ>MK\WZ1VNWZUI\QS/UJ0 ਝ ࢸݺ೮$"/ߡझ 1%6оߊनਊߡಌীࠂࢎػറ۽धਵبӒܿীח ۽߸ചࣁ ೡਸೠ݅ডח ㇔䄸 ః ᱄ ㇐☸Ȉ)]\WUWJQT-TMS\ZWVQS ࣘࢿח೧$"/ߡझীࠗػ&$6о୶о җ$"/ߡझ࢚пп&$6৬ѱ दݫदܳߊनೡࣻੋ ߡझܳా೧࣠ ਸо҃%'/"$חनݫदоਃೡ҃$"/ߡझ ਝాੋ ݫदח؊࢚࠙ೞঋӒ۞ ೞѱؼ1%6ܳࠁմѱਝখࢲәೠ߄ ೠ &$1)'ೱ࢚ػ&$1ߡझ $"/'%ਊदחઓ$"/ݫद ࣠दрө$"/'%ݫदী1%6 ೞաݫदীನೣػࣻ1%6 ೠژঠೠظनࢎਊо%'/"$۽ ૐоೠ݆بनݒܼझࠂࢿాח ੋب࣠ࣘ߄ಕ $"/ߡझ୭ߣী୭ ߓૐоػݫदীࢲബਯੋ୶ӝীడ ୭ݏզాनࣻਃܳטয়חؘఠܳ࣠ೠ .CQT٘۽ӝ ২࣌"6504"3SFMFBTFח ܳ࣠ೞחҗэ୶оਃҳࢎ೦ ܳпп1%6খࠗ࠙ীب߆ী ્פݫழظযࣻनӝоݫद ࠗఠղظоࠗ IFBEFS ߈٘दन ؊חਤೠ ాनਸਤ೧֎ਕࢸ҅ܳઁޙష হࠗೞ۞ೠ۽ؘఠ৬٘۽ಕ۽ബਯਵ ݽٕী .VMUJQMFYFS ਗ *1%6ݣ౭۩ࢲ۾بബਯੋߡझਊਸਤ೧ӡо ীࢲпп1%6ܳ୶ೡࣻ ژചदெঠೠܛӒ۽ഐٜਸ֤ܻਵ ܳبо߸ؘఠ࣠ࣘחয়ߡ٘р୭࠺ਯਸਬೞӝਤ ೧Ѿ଼ೞա ী࢚ҙহࢎਊೡࣻܨ؊࢚1%6 ࢲ֎ਕઙחؘఠਊ ೠܳా೧ѱਝ٘۽ࢎী$"/ਊਵ ߄ੋಕחѪೱ ೠੌࠗदաܻয়ীࢲחਸਊೞ $"/'% Ѫਬܻ ы$"/חࢎਊೞف߄ܳݽח೧ࢲ ߸҃ࠛоחࢎਊೡࣻ ࢎীػ1%6بೠ1%6ܳ$"/'%ীࢲ۽ CQT࣠.ష୭۽١җэѐ ࢚ػ$"/ب߄௰ࣘೞӒ۞աର ਃҳೠ҃؊ӟӡಕ ѱਝܳ؊ࠂೞѱٜ݅ࣻহ۾بӝઓ$"/ী࠺೧ חਗೠܳبࠁాӒӡ ࣘח नഐ ߹ੋؘఠਃࣗ ؘఠহযઉೞաݫद٘۽ عѐࢶמоӝفীݻݻ җэޙٸೞӝޅо߄ী
O1%6 ۞ೠਃҳࢎ೦ਸೞӝਤ೧ࢲחࣻ1%6ܳ࣠ೡࣻ۽नഐ৬ೣԋ࣠ػബਯੋࢎਊਸਤ ѱਝܳా೧ೞա$"/'%ݫदח O1%6UPGSBNFNBQQJOH ؘఠ߄о؊֫ ۨݒೝ٘۽೧п$"/ݫदউীৈ۞नഐٜਸ ಕ ࢎীػࣻ$"/1%6ܳ۽ா ਸਊೠ ࣠ػ୭۽بসݒࠂೞ ࠺࣠ࣘחೞ ؘఠ߬झীࢲ ࠶ӡ١җэ$"/ܲౠ ࣠೧ঠೠחनݒܼझా ೞѱਬೞӝਤ ѱਝܳਊೠ Әөݫदղਊппੌزࢿٜਸоә ژ ػ$"/҃%#$ա'*#&9 ನೣೠؘఠ߬झفӒܿŢदझమ߂ؘఠ٣झ݀࣌ਸݽ ܳా೧ध߹೧৳ $"/*% दաܻয়ীࢲQ3'8ۨ $"/ध߹ ח3दझమ٣झ݀࣌ೠ ೧$"/ݫद؊৬ۨੌ۞"6504"ח ࣠ػ ݒೝਸࢎਊೠ ೞ݅$"/'%ݫदೞաীࣻ1%6۽بоܳਊ೧ೡؘࣻఠ߬ ࢚ੋ࠺࣠ࣘ ؊ؘ࢚חࣻनӝ ীޙٸӝغӝ оನೣ ীࢲ Ӓܿ ӡ ѱਝदաܻয়ೠߣী୭חݫद߂Ӓҳࢿਃࣗ $"/'%ݫदীחী Ӓܿ झ ؊࢚࠙ೞ ఠध߹ਊ$"/*%ܳࢎਊೡࣻহೠоؘఠо ઓ$"/ߡझ٘۽ೣԋ о߄ੋಕببোҙػ࣠ࣻनҙ҅ۄפࡺ݅ই ೠ೧Ѿ଼$"/'%ݫदղਊמо ঋৈӝࢲѐ$"/ߡझоೞաѱ оب ನೣػߓࡅܲ࠺࣠ࣘظನೣ Ѫחೞ۽ ਸؘఠ߬झীࢲҊਵחݽٚߡझ ҊظোѾ۽ؘ ਝ٘۽Ҋ߄ੋಕغनഐ৬ ࢎਊחؘఠ߬झীبӒ߆ী ҃חO1%6ۨݒೝਸࢎਊೞ غ۽࢚క MPBEMJNJU ೠ҅٘۽࣠दр߄ ߡझ ݶغషؘ ఠо࣠۽ݫदࢎ୶࢚ച҅கੋ ݫ%'/"$חؘఠ߬झ۽߈חա ৬חӝઓ ҊҊо೧ࠁ$"/ߡझীחؘఠܳ࣠ೞ٘۽ ੋಕ 1%6 1SPUPDPM%BUB6OJUT ఠਬ ೠदաܻয়מੑदоب'(ӒܿŢ&$1 1%6חನೣؼࣻ۽ࠗ࠙ਸ दղীਫ਼ਵؘఠחغ࣠۽ߡझف $"/ݫद৬࠺तೞ ݠظ
1/28 1/29 ,M^MTWXUMV\.MI\]ZM
1ਃౠೞաܳ*&.40ب ࢲ࠺झೱبٜܳয সীب$"/'%৻ী ীޙٸӝ Ҋࠂೠগܻாؘ࣌غ ా೧ҳઑചعੑبࢎਊೡࣻ ੋాनبMFY3BZա&UIFSOFUীࢲ' &$6աݠ#BTJD4PGXBSF ఠܳ۳ച೧ ܃ࠗఠ࠺۽ೡ৻ ੋఠ֔ਵחࣽ1%6ܳݽਵױݽٕ חژߊन CZUFTUSFBN ѐ࢚ೠ ػࣼೠాनಁ۞ о߄झܿفনೠ࣠ઑѤ߂بী ೠ۞ೠ۾ب֎ਕ ࣻनসܻ݅ೡࣻਗೞҊ$"/'% ରب1%6؊ನݘ ೧؊ؘ࢚ఠ߬झীࢲഛੋ۽ਵ ਬعب۽࠙ঠ ۽৬'MFY3BZ҃߄؊о חঋغ4FSWJDF%JTDPWFSZ ೠݫदۨইਓ &UIFSOFU҃߄؊ ݴ ݴغਊ ߂4FSWJDF 4% ਊػ۽оੌ߈ਵ 4%৬40.&*1ܳחPSJFOUFE.JEEMFXBSF "6504"3 ࠺Ү۽)' )OH[5D\߂(WKHUQHW֎ਕషಫ ӒܿŢ&$1 ਗೠ4%৬40.&*1ۖಬ۽ؘఠ PWFS*OUFSOFU1SPUPDPM ਵ٘۽഻ঁಕ షٜ"6504"3۽ীޙٸࢿ݀ة ١җэ 40.&*1 WKHUQHW)חӡઁҕೞ ب୭ചػౠ &$6߂ӝఋۖಬрؘఠҮജী۽ਊਵந ରפࣗਤਬח߈ ೠ۞ೠాनҙ҅חܳਊೞ CVTUPQPMPHZ ۽झషಫ UIFSOFU୭& ٸҗ࠺Үೡ/"$ Ҋ ࢎਊػغࢎਊبష۽ חۄ VOJDBTUBEESFTTJOH झࣗ TUBSUPQPMPHZ ۽झఋషಫח'MFY3BZ ؘఠӡоߓաػ ݶ٘۽ಕ חநझࣗ Әөܻפ֤ܻ ߑधਸࢎਊೠ݅ডਬ ؘחغҳഅ۽ਵܻޛ߄1%6উীࣻୌѐनഐ ܳਊ೧ /"$۽ؘఠӡ٘۽ਊ֎ਕীઓ ؊ಕର ۽ೠߡझ৬эߑधਵ ߑधݫदоݽٚ֎ਕ֢٘ژٸഅपࢿ ҙীࢲࠅ۽पઁחӝઓחੑೞܳ ؘఠ࣠ߑ۽ߊनӝ৬ࣻनӝী '%৬&UIFSOFU࢜חࣻनӝ݅ ೞয়ೠ بۄ֢٘ ߊ࣠ػೞ؊ف֎ਕӝࣿݽفҳഅػ۽ ࢎਊೞ۽হӒ۞աѱਝਊਵ ೠژࢿਸઁदೞҊמೠо೧ঠӝܳ೮ࢲ धী ݫदܳߊ࣠ೠпп֎ਕ ೧ಁఉਸܻೠܲݽٚࣻनӝ۽ OPEF MFY3BZ1%6'חژ/"$ӝઓ҃ח ઑস߂ઁ೧ಁఉਸತӝೠࠛਃೞѱ֎ ࠺झೱੋాनীࢲ $"/'%৬&UIFSOFUରח ӒܻҊ ݫदо֢٘ীೠחਬ ֢٘ٸ࣠ೡ۽UIFSOFU1%6৬&ܳ ۽ഈ۱সীदझమࢸݺࢲࢿद࢜ חࢲ࠺झܳઁҕೞח Ѫਸߑೞӝਤח ਕীҗࠗೞоѦܻ݀ة೧ܻܳೡѪੋী۽ೡࣻ$"/'%ۢೞաݫद ܳ୶оܻ ژ%'/"$ਸઁӝೞҊೞաب ৬ࢲ࠺झ ࢲߡ झਤ &$6۽ഝࢿചػ֎ਕࣘ࠺ Ѿೠ۞ೠস$"/҃ ೧۽স ਵחীࣻ1%6ܳನೣ೧࣠ೞ ӒܿŢ6HUYLFH'LVFRYHU\ܳഝਊೠࢲ࠺झೱੋాनਗܻ UIFSOFUݫदীࣻ1%6ܳੑ&ח ۄ $6&חਊೞܳ ܳ҅ױਫ਼Ӭणחझਤعੑب'MFY3BZ҃4MPU*%ܳా о ߸҃হࢎਊೡࣻ $"/*%ܳా೧ب&UIFSOFUীࢲ /"$O1%6ۨݒೝೞաחоઓೠ ೞ ݫदܳ ۽ࣗоػݾ ݫदղ Ѣറח%*فݽ҃فܞ೧ ۽ઑਵח$"/'%৬'MFY3BZ৬ UIFSOFUݫदীࣻ1%6ܳ&חژ%' ష۽4FSWJDF%JTDPWFSZחநझࣗߑध҃֎ ࢲߡפ ਬоਊೠחೠܳా೧ࢎਊ׳ؘࢎਊػೞաݫद חೞܨо ਊਸ࠙ف೧UIFSOFUী&ח3ীࢲ"6504" ਗೠ۾بࢲ࠺झ৬ ੑೡࣻחغ ਸਊ೧۠ఋदীઁҕ۽ࣻनӝীࢲߊनӝחਕ࢚ࠁ פࢎਊೡࣻਸࡺ݅ই۽ߊनೡ ਸബਯਵ۽ࢶ߹ਵ۽ࣻनӝೠױܳ ١ೠӔߑधਸೞҊز ঌ۰ળ Ӓ۞ա&UIFSOFU҃ࢎਊؘחغ׳ѱࢲ࠺झоڌࣻ যڃ֎ਕ࢚ীࢲযחೠߊनӝز நझࣗݫदפਬחझਤ ۄ ࢲ$"/җ'MFY3BZۄٮ২࣌হחߣ૩Ӕߑध$"/'%ۢ ࣻ оਊೠ ۄפؘఠܳ ఠӡૐоࡺ݅ই۽ਵزաীחۄ חীҙब 1%6 ؘఠڃೡࣻ नӝоয׳दীز֎ਕ࢚ীࢲܳ חೠୡӝীژݒ&UIFSOFUח 1%6ݣ౭۩ࢲীղػO1%6ۨ* Үജ֎ਕ ೠૐо೮؊ژO1%6ۨݒೝ সؘ߉ӝਤ೧ࢲߡݫࣗ٘ܳഐ ҳࢿػ ঌҊযঠೞݴ۽فೠ1%6 ੌઙߡझदझమ&UIFSOFUਊா ӒܿझਤੌزѪחݒೝਸࢎਊೞ ࣗߑध۽ࢲߡী ߂৬োҙػ࢜ ೞѢա 3FNPUF1SPDFEVSF$BMM ز &UIFSOFU֎ਕܳࠁৈળߣ૩ ਸా೧ݫदܳೞѱঠೠ 5FMFNFOU ୷ா࠶җ5ࣗزח۽4PDLFU ࠶ ࣻঌҊ્ܻࣗযఠ ରসীഄݺਸоઉয়Ҋز חೠറ҃ࢲߡ TVCDSJCF оੑࣻनӝоৈ۞חߣ ੌೠ1%6ܳࣻनೞف Ӓܿਤଃ&$6ীਵݴחࠗ࠙҃&UIFSOFU झਤզטয়عযܳా೧ оࢎਊظݽٕղী EBQUPS" ્פݫழ۽߮ܳా ؘఠ࠙ߓܳਤೠ࢜חݫदܳৈ۞ ౠؘఠਃࣗܳઁҕೞחژ೧1%6חী҃ח ߰ࠢযঋ&$6ীࢸۄחࣘߑधਸ ૩झਤ QPJOUUPQPJOU 3ইఃఫաݠࠗ࠙җ5$1 "6504" ࢲ࠺झೱ۽ীӒчਸߊ ࣻܳ߄ఔਵۄೞ۞ೠࣻन ೧ࢲоੑೠݽٚמоبѪח࢝ػ߽ࠗ࠙۳ݴ֎ਕ ର۹ߊ࣠ೞظUSFF ۽ਸߑೞҊܻషಫج1झఖਸোѾೡࣻࣗযఠࢎਊ ా೧* ز4PDLFU ࣠ೠࢲߡগܻாؘ࣌ఠস ੋాनਸా೧ؘఠҮജਸࠁח EBUBGBOPVU ݽٚ ӝ߹ؘఠ࠙ӝ۽न҃ాחBDUJWFMZ ীࢲрࢼਸ߉ঋ Үജزמܳਊೠ ೠ୶о UPQPMPHZীױ&UIFSOFUӝ߈ాनࣻ द पदೡࣻ"6504"3۽दఅ ਵ USJHHFS زGVMM "EBQUPSܳೠ"6504"3ীࢲऔѱҳ ؘҙ۲࣠ਸ CQT.֎ਕߑध ࣘഥࢶ୭ ೞ TXJUDIFEמੋઁযоо ۽ਗ೧࢜فਸݽ્פ അೡࣻ O1%6ۨݒೝਸా೧ೞաݫद ઁदೠݫழ ؘఠ࣠ਸਗೠӒѾҗ ࣗܳ EVQMFY$".חݽٚ&UIFSOFU֢٘ ࣻ݅ఀ ীࣻ߮ܳನೣೡࣻӒܿ ాनಁ۞ҳഅਸୢೞҊ۽߽۳҃֎ਕղ .CQTחࣗ WKHUQHWҗܲ֎ਕ ࠁਬೞҊਵݴ) оਗܻ അ"6504"3ߡ#BTJD4PGUXBSFҳഅفࢲ࠺झೱੋాनח ాनಁ۞۽ ࢜ NVMUJDBTU যաѱػ&UIFSOFUOט সীࢎਊ BEESFTTJOH QHWZRUNWRSRORJ\ Ҋਬೠࣗ ۽షಫ ߭ఠѐߊోੋ۽ೞೠמधച೧ࠁৈળ оبܳ ਗ ࢲ࠺झೱੋాनبాन CSPBEDBTU ۄפࡺ݅ই غ۽ػन."$ࣗоࣻन بؘఠӡ৻ী٘۽ಕ ࠂ ݫࣗ٘ഐ߂ؘఠসؘ҃ $"/PF৬ೣԋदػ.*$304"3ܳഝਊۄפߊ ೠ݅ড۞ೠࣗߑߨਸੜࢎਊ &UIFSOFUౠࢿࡺ݅ই ݫदܻܳೠद݈೧ח߂ࣗ ݶ֢٘۽UIFSOFU֎ਕషಫ& ؘఠӡоݒনೞ ೧$"/'%߂&UIFSOFU֎ਕ࠙ࢳҗח࣠ೞ খࢲࢸݺೠ&UIFSOFUਸ ೠ֎ਕܳਲ਼ాࢿѱઁযೞҊೞ ೞݶޅ೧ঌҊযঠೞݴݫ ೞࣻनӝীחஏݶীࢲܲ֎ਕӝࣿ नӝ BEESFTTJOH
&"Ѫ పझܳрಞೞѱप೯ೡࣻחର ৬эনೠؘఠӡܳਗೞزۄٮઑসਃҳীઁରח ഝਊೡࣻহ۽ઁ $"/ӝઓߡ दউী೧ݾࣗܳੑ۱೧ঠ Ӓܿ җ࢚ܰ
1/30 1/31 그림 1: 카메라 기 반의 운전자 보조 시스템을 신뢰성 있게 분석하려면 이더넷 네트워크의 여러 지점에서 데 이터 트래픽을 모 니터링해야 한다. 시간 오프셋이 최 소화된, 그리고 공 통된 시간축을 사 용하는 “티커플러” 가 여기에 이상적 이다.
하나의 스위치에 모든 카메라를 직접 연결할 수도 있다. 차량에 IP 개발 툴로부터의 요구사항 서 지금까지 사용해 왔던 버스 시스템들과 마찬가지로 네트워크 먼저 이전 버스 시스템들이 요구했던 개발 툴에 대한 요구사항들 의 다양한 지점에서 시간을 동기화한 상태로 데이터 트래픽을 관 은 여전히 여기에서도 적용된다. 시뮬레이션 기능으로 프로토콜 찰, 분석 및 비교해야 한다. 따라서 측정 하드웨어는 먼저 현재 버 에 대한 상세한 분석은 물론, 스크립트 기반의 테스트로 확장 가 스의 물리학적 부분(예: BroadR-Reach)을 지원하면서 미래의 물 능해야 하며, 테스트 보고서 또한 자동으로 생성될 수 있어야 한 리층도 받아들일 수 있어야 한다. 이를 위한 이상적인 해결 방법 차량용 IP와 이더넷 통신 다. 또한 시장에서 검증된 멀티버스 기능이 이더넷과 IP로도 확 은 티커플러(Tee-coupler)를 통한 멀티 채널의 사용인데, 이는 모 장되어 각기 다른 버스 시스템에서 발생하는 이벤트 간의 종속 니터링 중에 시스템 네트워크를 거의 방해하지 않기 때문이다. 오늘날의 적용사례를 통해 알아보는 개발 툴의 도전과제 관계를 편리하게 연구할 수 있기를 사용자들은 기대하고 있다. 티커플러는 시스템의 기능 검증을 위해 오류들을 주입할 수도 있 현재는 LIN과 CAN 간의 상관 관계에 관심을 갖고 있지만 미래에 어야 한다. 또한 분석 작업 외에 잔여 버스 시뮬레이션이라고 하 불과 몇 년 전까지만 하더라도 이더넷을 진단쪽 액세스 외의 차량 내 사용은 부적절하다는 의견이 지배적이었다. 하지만 이더넷 기 는 CAN과 IP 간의 상관 관계에 관심을 가지게 될 것이다. 는 네트워크 전체에 대한 시뮬레이션도 요구된다. 측정 하드웨어 술을 시스템 네트워크로 활용한 카메라 기반의 운전자 보조 시스템이 머지않아 첫 번째 적용 사례로 등장할 예정이다. IP(인터넷 프 는 이러한 것들은 확실히 해결할 수 있어야 한다. 로토콜)와 이더넷은 자동차 산업에서 새로운 네트워크 기술이기 때문에 낯선 문제들이 자동차 OEM과 공급업체, 그리고 관련 개발 전과 마찬가지로 프로토콜 분석 시에는 관련 애플리케이션 신호 툴 업체들 앞에 놓이게 되었다. 그래도 너무 걱정할 것은 없다. 이미 많은 문제들이 해결 가능하기 때문에… 를 심볼(symbol)로써 손쉽게 액세스할 수 있어야 하며, 더 나아 카메라 애플리케이션에는 시간 동기화 및 서비스 품질(QoS)과 가 이를 논리적으로 또는 그래픽 방식으로 처리할 수 있어야 한 관련한 높은 요구사항이 존재한다. 이러한 요구사항은 AVB(Au- 다. 하지만 여기에는 버스의 물리학적 부분과 광범위한 IP 프로 dio Vid¬eo Bridging) 표준의 프로토콜 확장을 통해 다뤄져야 한 토콜들로 인해 새로운 요구사항들이 생긴다. 본 기사는 현재의 다[7]. 이제 제조업체들 간에 비트 전송층(OSI Layer 1)에 대한 합 I1991년 CAN 버스가 메르세데스 S-클래스 차량에 처음 적용된 을 입증하였다. 그리고 최근들어 차량 내 다른 영역에서 이더넷 카메라 예와 차량 내 IP 및 이더넷의 네 가지 다른 적용 사례를 의는 이루어졌기에 비용 및 테스트 상의 이유로 더 높은 계층에 이후, LIN, MOST, FlexRay 버스 시스템도 자동차에 순차적으로 을 사용하는 것에 대한 논의가 늘어가는 추세인데, 이는 이더넷 토대로 작성되었으며, 이러한 측정 작업이 제품 개발 부서 내 시 서의 표준화도 추진하고 있다. 자리를 잡게 되었다. CAN은 오늘날에도 파워트레인에서부터 바 이 가진 유연성과 넓은 대역폭 확장성이 주는 장점 때문이다. 그 스템 관리자의 관점에서 어떻게 활용되는지, 그리고 개발 툴에는 디에 이르기까지 모든 자동차 분야에서 자동차 네트워크 아키텍 러나 모터 차량에 적합한 와이어링 기술의 부재로 여전히 경제성 어떠한 특정 요구사항들이 결과적으로 요구되는지를 보여준다. 만약 카메라 애플리케이션에 다른 프로토콜이 사용되는 경우 다 처로써 꾸준히 사용되고 있다. LIN 버스는 간단하면서도 경제적 이 떨어졌다. 양하고 복잡한 페이로드(Payload) 영역에서의 신호를 애플리케 인 방식으로 인해 안전성을 고려해야 하는 운전 영역이 아닌 편 1. 카메라 – 이더넷을 시스템 네트워크로 사용 이션에 맞게 보고 조작할 수 있는 측정 소프트웨어가 필요하다. 의 영역 내 신호 데이터를 교환하는데 적합하다. FlexRay와 현재 자동차 내 이더넷 사용을 가장 많이 이끌어가는 영역은 카 BMW의 카메라 기반 운전자 보조 시스템은 IP와 이더넷을 차량 표 1의 “Audio/Video” 열과 “Control Com¬munication” 열에는 MOST 버스는 실시간 요구사항이 많고 더 넓은 대역폭이 필요한 메라 기반의 운전자 보조 시스템이다. 아직까지는 LVDS(Low 내 시스템 네트워크로써 활용한 최초의 양산 구현일 것이다[1]. AVB에서 사용되는 프로토콜들이 나와 있다. 또한 대역폭 제한을 경우에 CAN을 대체해 사용된다. 다만, 고가이기 때문에 경제성 Voltage Differential Signaling)란 기술이 차량 내 카메라 애플리 OEM과 공급업체는 현재의 LVDS 기술에 비해 무게와 비용을 절 위한 프로토콜과 다른 네트워크 관리 프로토콜도 있다 (표1의 오 을 고려해야 한다. 오늘날의 차량에서는 위에 언급된 버스 시스 케이션에서 사용된다. 여기에는 전자파 적합성을 확실히 보증하 감하기 위해 새로운 BroadR-Reach 물리층을 사용할 예정이다 른쪽 네 개 열). 표에 나와 있는 프로토콜들은 다음의 적용 사례 템들을 쉽게 찾을 수 있는데, 각각의 시스템은 게이트웨이 장치 는 쉴드(Shield) 케이블이 일반적으로 사용되지만, 차량 내에서 [1], [4], [5]. BroadR-Reach는 여러 다른 제조업체들에 의해 라이 들을 토대로 추가되었다. 를 통해 분리되고 또 연결된다. 사용하기에는 비싸고 실용성도 매우 떨어진다. 최근에는 CAN과 센스화될 것이다. 유사한 방식으로 2개의 와이어 케이블을 비차폐 꼬임쌍선(UTP: 2. 진단 액세스 이더넷 사용에 대한 동기부여 unshielded twisted pair)으로 사용했을 경우 100Mbit/s의 전이 그림 1은 카메라 시스템 네트워크의 예를 잠재적인 측정 지점들 “DoIP(Diagnostics over IP)” 기술을 사용하면 고성능 이더넷 액 이더넷은 사무실 내 통신, 산업공학(OVDA 표준, 이더넷/IP, Prof- 중(Full-duplex) 전송 속도를 지닌 물리층을 가질 수 있다고 하는 과 함께 보여준다. 그림에서는 두 개의 스위치로 나뉘어 있지만 세스를 통해 여러 버스 시스템에 연결된 각기 다른 ECU들을 한 iNet) 및 우주항공산업(AFDX®)에서 오랜 시간 표준 기술로 자리 데, 다양한 발행물에서 이를 차량 내 적합한 것으로 주장하고 있 잡아 왔다. 차량 내에서는 진단쪽 액세스와 관련해 이미 그 성능 다[1], [2], [3].
1/32 1/33 표 1: OSI 레퍼런 스 모델(행)에 관 리 기능(열)을 포 함한 자동차 애플 리케이션용 IP 프 로토콜. 새로운 프 로토콜(빨간색)과 사무실용 통신으 로 알려진 프로토 콜(회색)이 모두 그림 3: CANoe.IP는 IP 또는 이더넷을 통해 통신하 사용된다. ([7] 및 는 임베디드 시스템의 개발 및 시뮬레이션, 테스트 벡터 기준 참조) 를 지원한다.
곳에서 플래시할 수 있다(그림 2). OEM의 시스템 개발 부서에서 3. 전기차 충전소 – 스마트 충전 을 막을 수 있다. 또한 연결된 차량은 저장매체로 사용될 수 있으 시스템 관리자 입장에서 보면 Car2x 애플리케이션의 측정 기술 는 이 서비스를 반드시 검증해야 한다. ECU는 게이트웨이로 사 스마트 충전은 단순하게 가정의 전기 콘센트에 플러그를 연결하 며, 전기 공급업체의 과금 업무는 자동화될 수 있다. 에 대한 관심은 개별 차량의 경계를 뛰어넘어 주변 환경의 수많 용되기 때문에 진단 데이터의 전송에 대한 분석이 연결된 여러 는 것 이상을 의미한다. 충전할 전기차는 충전소를 통해 전기 그 은 다른 차량 및 RSU(Roadside Unit)까지 확장된다. 여기서 평가 버스 시스템은 물론 IP 측면에서도 이루어져야 한다. 관련된 프 리드에 연결된다. 충전 프로세스는 그냥 시작되는 것이 아니며, 이러한 모든 과정은 차량과 충전소 간의 IP 기반 프로토콜 상의 해야 할 ECU는 차량 내 버스 시스템들과의 통신뿐만 아니라 무 로토콜은 표 1에 보여지는 것과 같이 ISO 13400과 IPv4/IPv6이 먼저 충전의 필요성을 통신을 통해 알린다. 개별적인 충전 프로 이더넷 통신을 통해 이루어지는데, 이는 ISO 15118에 정의된 표 선 인터페이스를 이용한 다른 트래픽 관계자들과의 통신까지도 다. 세스들을 잠시 지연시킴으로써 그리드에 과부하가 발생하는 것 준을 따른 것이다. 여기서 충전소는 그리드 및 차량과 통신한다. 담당한다. 따라서 개발 툴에서도 이러한 IP 기반 표준을 지원해 자동차 OEM의 시스템 관리자에게 차량과 충전소 간의 통신은 야 한다. 또한 고주파 범위(예. 5GHz 대역의 WLAN)에서는 다른 매우 중요하다. 충전 프로세스를 안전하게 지키기 위해서는 프로 요구사항들도 발생한다. 토콜에 대한 세부적인 분석과 검증이 절대 필요하다. 개발 툴 역 시 이러한 프로토콜을 지원해야만 한다 (표 1, “Smart Grid” 열 참 애플리케이션 및 측정 툴을 위한 새롭고 다양한 프로토콜 조). 표 1에는 다양한 애플리케이션 관련 전송층과 프로토콜이 예로 나와 있다. 개발 툴은 현재까지 발생한 사례를 기준으로 이러한 4. 캘리브레이션, 디버깅, 플래싱 전송층과 프로토콜을 지원해야 한다. 여기에는 사무실용 IP 통신 오랜 세월 동안 개발 쪽에서는 이더넷을 XCP 측정 및 캘리브레 에서 사용되는 일부 프로토콜들이 들어있지만 많은 항목들도 생 이션 프로토콜과 함께 ECU의 캘리브레이션, 디버깅 및 플래싱을 략되어 있고 새로운 항목들도 추가되어 있다. 표에는 사무실용 그림 2: 게이트웨 위해 사용해 왔다. 하지만 양산차에서는 비용상의 이유로 인해 통신 환경으로부터 자동차용에 맞게 조정 가능한 프로토콜들이 이에서 DoIP를 검 이더넷 액세스가 금지되어 있다. 따라서 현재는 기존의 작업 프 밝은 회색으로 표시되어 있다. 새로운 자동차 애플리케이션으로 증할 때는 데이터 로토콜(예: CAN의 XCP 또는 CCP)을 사용해 캘리브레이션 및 재 인해 추가된 항목들은 빨간색으로 표시되어 있다. 트래픽을 게이트 프로그래밍 작업을 수행하고 있다. 그러나 이더넷이 차량 내에 웨이의 왼쪽에 있 자리잡게 되면 이더넷의 XCP를 이용한 측정 및 캘리브레이션이 측정 시스템에서는 모든 관련 프로토콜들을 확인하고 모든 네트 는 DoIP 쪽과 게이 특유의 높은 측정 데이터 속도 덕분에 양산차에서 매우 매력적인 워크 이벤트들을 올바른 순서에 따라 배치한다. 여기에서는 모든 트웨이의 오른쪽 선택으로 떠오르게 될 것이다. 버스 영역들을 공통된 시간 기준 아래 충분히 정밀하게 나타내는 에 있는 연결된 버 것이 중요하다. 스 시스템 쪽 모두 5. Car2x와 WLAN 에 나타내는 것이 Car2x는 차량과 인프라 간의 외부 통신으로 간주된다. 적용 범위 IP 생성 프로젝트의 검증 중요하다. 모든 네 는 편의 기능에서 트래픽 흐름 최적화 및 엄격한 트래픽 안전(운 위 적용 사례들에서 볼 수 있듯이 시간적 분석이나 인과관계를 트워크의 모든 메 전자 보조 시스템)에 이르기까지 다양하다. 이 기술은 이미 생산 찾는 것이 여러 버스 시스템으로 확장되어 진행되기 때문에 사무 시지가 공통된 시 이전 개발 단계에까지 사용되고 있으며 표준화도 상당히 높은 수 실 통신용 표준 이더넷 툴을 자동차용 버스 애플리케이션에 활용 간을 기준으로 전 준에 올라와 있다. 또한 IP를 기반으로 하며 IEEE 802.11p 표준이 하기가 어렵거나 불가능하다. 사무실에서 사용되는 이더넷은 자 송되는 것이 이상 물리층으로 사용된다. 동차에서 사용되는 이더넷과는 다르다. 인터넷 프로토콜 또한 마 적이다.
1/34 1/35 링크: 벡터 IP 및 이더넷 솔루션: www.vector.com/vi_ip_ethernet_solu- tions_en.html CANoe.IP 제품 정보: www.vector.com/vi_canoe_ip_en.html 스마트 충전을 위한 벡터의 노하우: www.vector.com/vi_elect- ric_vehicles_en.html AFDX®는 Airbus의 등록 상표이다.
그림 4: 확장 가능 저자: 한 하드웨어 인터 페이스와 실시간 지원 옵션을 갖춘 CANoe.IP
찬가지이다. 물리층의 요구사항들이 다른 만큼 영역별 유형 및 및 멀티버스 기능을 바탕으로 개발 시간을 줄여주며 애플리케이 복잡도도 다르다. 션을 위해서는 중요한 리소스를 보다 효과적으로 활용할 수 있도 한스 베르너 스칼(Hans-Werner Schaal) 개발 툴 안에서 프로토콜의 신호 구조를 표현하고 임베디드 코드 록 도와준다(그림 3). CANoe는 기존의 CAN, LIN, MOST, FlexRay 를 생성하려면 적절한 엔지니어링 포맷의 선택이 중요하다. DBC 버스 시스템에서 자동차 네트워크 개발을 위한 표준 환경이 되어 슈투트가르트 대학교에서 통신 엔지니어링을, 미국 오레곤 주 대 포맷은 CAN에 일반적으로 사용되는 엔지니어링 포맷이며, 왔다. 마찬가지로 IP를 위해서도 똑같은 개발 편의성을 제공하고 학교에서 전기 및 컴퓨터 엔지니어링을 각각 전공했다. 스칼은 FIBEX는 FlexRay에서 일반적으로 사용된다. 하지만 DBC 포맷은 있다. 이 개발 툴은 확장성이 매우 뛰어나며, 세 가지 인터페이스 현재 벡터 인포매틱에서 개방형 네트워킹 제품 라인의 비즈니스 새로운 이더넷 및 IP 기반 시스템 네트워크의 데이터베이스 포맷 옵션을 기본적으로 제공하고 있다(그림 4). 가장 단순한 Case 1 개발 관리자로 근무하고 있다. 이전에는 다양한 업계의 여러 가 으로는 적합하지 않다. 툴 공급업체의 관점에서는 OEM들이 공 에서는 윈도우 컴퓨터에 사용되는 모든 네트워크 카드를 인터페 지 네트워크 기술을 위한 테스트 툴 부문에서 개발 엔지니어, 프 통된 엔지니어링 포맷에 합의하는 것이 도움이 될 것이다. 적합 이스로 사용할 수 있다. BroadR-Reach를 사용하거나 오류를 주 로젝트 책임자 및 프로젝트 관리자로 근무했다. 한 후보 포맷으로는 FIBEX 4.0 및 AUTOSAR 시스템 설명 포맷이 입할 수 있어야 하는 Case 2에서는 향후에 나올 장비 VN56xx 제 있다. 포맷이 선택된 이후에는 다른 산업 분야에서의 경험을 통 품을 인터페이스로 사용하면 된다. 이는 IP 채널 간에 그리고 다 해 알 수 있듯이 머지않은 시일내에 툴 제조업체들을 통해 분석 른 버스 시스템 간에 시간 동기화 기능이 대폭 개선된 제품이다. 및 코드 생성에 적합한 개발 툴들이 제공될 것이다. 실시간 동작이 요구되는 Case 3에서는 향후 CANoe.IP를 실시간 하드웨어인 VN8900에 연동해 사용하게 될 것이다. 물론 이 하드 차량 네트워크에 대한 전망 웨어는 VN56xx 인터페이스와도 원활하게 연동된다. 차량 내 CAN의 사용 추세는 앞으로 10년을 훨씬 넘어 계속 이어 질 것으로 예상되며, 여기에 거론된 다른 모든 버스 시스템도 최 소한 10년은 사용될 것이다. 하지만 대역폭, 유연성 및 경제성과 참고 문헌: 관련된 요구사항이 늘어남에 따라 IP와 이더넷의 적용이 갈수록 [1] Bogenberger, R., BMW AG: IP & Ethernet as potential main- 늘어날 전망이다. 또한 게이트웨이를 통한 IP와 여러 버스 시스 stream automotive technologies. Product Day Hanser Auto- 템과 네트워크 연결은 오늘날의 다른 버스 시스템에서 이미 볼 motive. Fellbach, 2011. 수 있는 것처럼 곧 등장할 것이다. 이더넷과 IP는 간단하게 그냥 [2] Neff, A., Matheeus, K, et al.: Ethernet & IP as application 추가될 것이다. 카메라에서 적용된 사례와 마찬가지로 앞으로 일 vehicle bus in use scenario of camera-based driver assistance 어날 IP 적용에서도 새로운 문제들이 모든 프로토콜 단계에서 발 systems [German lecture]. VDI Reports 2132, Electronics in the 생되겠지만 적절한 개발 툴을 통해 해결될 것이다. motor vehicle. Baden-Baden, 2011. pp. 491-495. [3] Streichert, T., Daimler AG: Short and Longterm Perspective IP 개발 툴에 대한 전망 of Ethernet for Vehicle-internal Communications. 1st Ethernet 자동차 분야에서는 IP 통신을 고려한 개발 툴이 계속적으로 권장 & IP @ Automotive Technology Day, BMW, Munich, 2011. 될 것이다. 이러한 툴은 모든 프로토콜 레벨을 지원해야 하면서 [4] Nöbauer, J., Continental AG: Migration from MOST and 도, 또 한편으로는 일반적인 업계 툴 환경을 갖추고 있어야 한다. FlexRay Based Networks to Ethernet by Maintaining QoS. 1st 공급업체들은 특히 OEM의 제품 개발 프로젝트를 검증하기에 적 Ethernet & IP @ Automotive Technology Day, BMW, Munich, 합한 개발 툴을 제공해 달라는 요청을 받는다. 당연히 여기에는 2011. 지원 및 툴 제조업체로부터 제품 도입을 위한 도움도 포함된다. [5] Powell, S. R., Broadcom Corporation: Ethernet Physical Lay- er Alternatives for Automotive Applications. 1st Ethernet & IP 현재 벡터의 검증된 시뮬레이션/테스트 툴인 CANoe는 IP 옵션 @ Automotive Technology Day, BMW, Munich, 2011. 을 통해 위에서 설명된 이더넷 개발 툴과 관련한 요구사항들을 이미 모두 포함하고 있다. CANoe.IP는 다양한 이더넷 관련 기능
1/36 1/37 al reserve)에 얼마나 근접하게 운영되고 있는지에 대한 지식이 필요하다.
RS232 솔루션과는 달리 K-Line 인터페이스를 통해서 통신 타이 밍을 효율적으로 정확하게 수집할 수 있으며 송수신된 K-Line 프 레임은 정확한 타임스탬프와 함께 제공한다. 또한, K-Line 인터페 이스로 Fast-Init 및 5-baud Init 초기화 패턴을 포함해 보 레이트 (baud rate)를 자동으로 감지할 수 있으며 K-Line 타이밍과 데이 터 조절 및 raw byte stream 발신이 가능하다. 이러한 인터페이 스들은 USB를 통해 모든 PC와 연결 가능하며 전용 K-Line API 등 을 통해 소프트웨어 툴과 함께 사용할 수 있다. 이를 통해, 테스 그림1: 다양한 K-Line 인터페이스 제품: 단일 채널 USB 인터페이스 트 스크립트 내의 모든 하드웨어 기능을 쉽게 사용할 수 있다. 부터 HiL 모듈까지 확장 가능한 K-Line 솔루션 A/S 서비스 제공 시, 자동차 OEM 업체의 중요한 과제 중 하나는 벡터는 K-Line 개발 제품을 테스트하고 시뮬레이션하기 위한 용 적합한 K-Line 테스트 장비를 갖춘 정비 업체를 통해 전 세계 모 도로 고품질 인터페이스 하드웨어와 고성능 소프트웨어 툴로 구 든 K-Line 차량을 지원하는 것이다. K-Line으로 ECU 개발 시, 테 성된 K-Line 컴포넌트를 제공한다. 솔루션은 가능한 모든 요구 사 스트가 필요한 새로운 기능이 생기므로, 제조 업체와 공급 업체 항에 적용할 수 있으며 단일 채널의 K-Line 모니터링 툴부터 는 K-Line 테스트 장비 및 ECU에 사용되는 K-Line 프로토콜을 지 K-Line 진단 테스트 장비, ECU 및 대형 HIL 시스템에 대한 시뮬 원하기 위해 효과적인 하드웨어 및 소프트웨어 툴이 필요하다. 레이션 솔루션까지 유연하게 확장할 수 있다. 대형 HIL 시스템은 실시간으로 운용되는 특징이 있으며 테스트 운용을 위한 멀티채 테스트 하드웨어를 위한 엄격한 요구 사항 널 환경을 시뮬레이션할 수 있다. 이때, CAN이나 LIN, FlexRay 등 모든 진단 또는 테스트 프로세스에서는 기본적으로 진단용 PC와 과 같은 다른 버스 시스템을 K-Lin과 함께 통합할 수 있다. 벡터 테스트 대상 장치를 연결할 인터페이스 하드웨어가 필요하다. 는 USB 인터페이스나 PCI 버스를 통해 K-Line에 접속 가능한 다 K-Line 장비 테스트를 위해 PC의 기존 UART/RS232 인터페이스 양한 유형의 인터페이스를 지원한다. VN1600 및 VN8900 인터 를 사용할 수도 있지만 이 인터페이스는 적합성 점검 및 기능의 페이스 제품뿐만 아니라 VT 시스템용의 VN7570 및 VT6204 등 정확성을 검증하기 위한 고급 기능이 없어서 그 사용에 한계가 과 같은 플러그인 카드가 이에 해당한다(그림 1). 최적의 K-Line K-Line: 클래식 프로토콜을 위한 유연한 솔루션 있다. 또한, DUT가 특정한 한계 수준, 즉 기능적 여유치(function- 지원을 제공하는 7269 LIN 트랜시버는 물리 계층 상에서 전송 작
정밀 모니터링부터 일반적인 바이트 제어 프로토콜을 위한 데이터 조작까지
K-Line 진단 프로토콜은 과거 다양한 차량의 진단 작업을 위한 표준이자 오래전부터 사용해온 인터페이스로 최신 하드웨어 및 소프 트웨어 진단, 개발 및 정비 업무 등을 위해 여전히 널리 사용되고 있다. K-Line이 오랫동안 사용되고 있는 이유는 K-Line이 ECU와 의 단순 통신에서부터, 바이트 레벨의 K-Line 전용 변수 지원 및 K-Line 진단 테스트 장비와 K-Line ECU에 대한 전반적인 시뮬레이 션까지 다양한 범위의 요구 사항을 다루기 때문이다.
CAN이나 Ethernet과 같은 시스템이 K-Line이 수행하던 진단 업 버스 속성을 갖춘 시리얼 UART 진단 프로토콜 무를 대체하면서 K-Line 진단 프로토콜은 신제품 개발 시 더 이 K-Line은 ISO 14230 표준을 준수하는 진단 프로토콜로, 표준 상 핵심적인 역할을 하지 않는다. 그럼에도 불구하고, 전 세계 자 RS232 시리얼 인터페이스처럼 전형적인 UART(Universal Asyn- 동차 OEM, 부품 및 정비 업체들은 여전히 K-Line을 간과할 수 없 chronous Receiver Transmitter) 회로 기술에 기반을 두고 있다. 는데 이는 K-Line 인터페이스를 갖춘 ECU가 승용차나 트럭, 오토 비동기식 전송의 경우, 발신자와 수신자는 동기화를 목적으로 시 바이 등에 여전히 사용되고 있기 때문이다. 작 비트 및 정지 비트를 사용한다. 이는 시스템이 추가적인 라인 없이 단일 회선으로도 충분하다는 것을 의미한다. RS232와는 대 K-Line 프로토콜에 대한 지속적인 수요 조적으로, K-Line 통신은 버스 시스템처럼 다양한 ECU와 통신할 중국이나 인도, 남아시아에서는 K-Line 기술이 적용된 수백만 대 수 있다. 표준 전송 속도는 10,400 baud이며 최대 속도는 115.2 의 승용차와 오토바이가 여전히 도로 위를 주행하고 있다. 일반 K baud로 플래시 메모리 프로그래밍 등을 목적으로 사용된다. 적으로 이런 차량에는 약 10~15 년 전 수준의 오래된 기술이 적 용되어있다. 약 10~15년 전 많은 유럽 차량의 생산이 라이센스 K-Line은 온보드 및 오프보드 진단에 모두 적합하며 두 종류의 계약을 맺고 아시아에서 이루어졌으며, 현재도 유럽에서는 단종 특수 초기화 패턴을 제공한다. Fast-Init는 10,400 baud 표준에 기 된 차량이 아시아에서는 계속 생산되고 있다. 특히 생산량이 소 반을 두고 있으며 활성화(wake-up) 패턴을 발신한다. 한편, 또 다 량인 제품의 후속 제품이나 관련 제품을 개발 시, 입증된 ECU 개 른 패턴인 5-Baud Init 는 주소 바이트를 5 baud의 속도로 발신 발 기술을 사용하는 것이 일반적인 관행이기 때문에 이러한 제품 하며 수신기는 이 느린 전송 속도를 감지한다. 또한, K-Line의 특 에도 K-Line은 여전히 사용되고 있다. 징 중 하나는 헤더 포맷(header format)과 타이밍 파라미터를 확 그림 2: K-Line 테스트 인 시 사용하는 특수 키 바이트(key byte)다. 및 시뮬레이션 환경
1/38 1/39 그림 3: 다양한 통신 레 벨에서의 K-Line 분석
업을 처리한다. 저자:
K-Line 전용 제품 및 바이트 제어 프로토콜 지원 벡터는 서로 대체 가능한 CANoe와 CANalyzer라는 두 가지 툴을 제공하고 있다. CANoe는 (자동화된) 테스트 및 시뮬레이션을 위 한 범용 솔루션인 반면, CANalyzer는 분석 및 모니터링에 초점이 맞춰져 있다(그림 2). 이러한 툴을 통해 모든 K-Line 파라미터 및 설정에 액세스할 수 있다. 테스트 담당자는 진단 및 통신 레벨이 나 독특한 특성이라 할 수 있는 바이트 레벨 등 다양한 레벨에서 페터 덱커 (Peter Decker) 오류 테스트 및 측정, 입력을 실행할 수 있다. 이를 통해 CANoe 2002년부터 벡터 인포마틱(Vector Informatik)에서 근무했으며, 와 CANalyzer를 표준이나 일반적인 시리얼 바이트 프로토콜에 현재 네트워크 및 분산 시스템 제품군에 대한 제품 관리자로 일 서 벗어난 K-Line 전용 배리언트를 위해 사용할 수 있다. 추적 및 하고 있다. 분석용 윈도우는 타이밍, 보 레이트, 헤더 바이트, 유용한 데이터, 바이트이나 프레임 사이의 간격 등을 매우 정밀하게 표시한다(그 림 3). 다른 윈도우를 통해서는 K-Line 프레임의 상호적인 발신이 가능하다. 응용 프로그램의 프로그래밍 언어인 CAPL은 로우 프 레임(raw frame) 발신 및 오류 입력에 사용할 수 있다. CAPL과 K-Line API를 사용하여 시뮬레이션도 할 수 있으며 이후 테스트 모듈은 자동 테스트 시퀀스와 보고서를 생성한다.
요약 오랫동안 사용된 K-Line 프로토콜은 최신 고성능 툴에도 적용 가 능하지만 여전히 진단 테스트 장비 및 ECU의 유지 보수 작업에 주로 사용되고 있다. K-Line 프로토콜을 활용해 자동차 OEM 업 체 및 부품 업체들은 고품질 테스트는 물론, 기존 K-Line 컴포넌 트의 재사용 및 원활한 부품 개발 작업을 수행할 수 있다.
그림 제공: Vector Informatik GmbH 링크: www.vector.com
1/40 E/E 아키텍처 설계 및 최적화
차세대 모델 기반 툴로서의 PREEvision
그림 1: PREEvision을 이용한 ECU 네트워크 설계
직면해 있다. 현재, 새로운 도메인을 대상으로 AUTOSAR Adap- 여기서 필요한 해결책은 항상 양극단 사이를 절충하는 것이다. tive 플랫폼이 논의되고 있다. 즉, 생산량이 적은 차량 베리언트를 위한 특수 E/E 컴포넌트들이 존재하는 반면 다른 한편으로는, 생산량은 많지만 불필요한 기능 최신 E/E 아키텍처 설계 및 최적화 작업은 아키텍처 전문가에게 그 어느 때보다 중요한 과제가 되고 있다. 아키텍처 전문가들은 수 기능 및 ECU 네트워크 들로 추가 비용이 발생하는 여러 차량 베리언트를 위한 일반적인 많은 설계 기준들을 고려하고, 기존 차량 도메인에 새로운 요구사항과 기술 트렌드를 접목해야 하기 때문이다. 도메인 컴퓨터의 출 지금까지 언급한 모든 고려사항을 어떻게 아키텍처 설계에 반영 E/E 컴포넌트들도 존재한다. 따라서, “최상의” E/E 아키텍처의 정 현, 차내 통신용 Ethernet, 커넥티비티 게이트웨이, 그리고 마지막으로 가장 중요한 기능 안전 및 정보 보안에 대해 늘어가는 요구 할 것인가? 이를 위해 가장 적합한 E/E 아키텍처를 어떻게 정의 의는 다차원적인 매우 어려운 최적화 문제이다. 사항 등을 고려해야 한다. 이러한 복잡한 과제들을 극복하려면, 다양한 엔지니어링 기능을 지원하는 PREEvision과 같은 모델 기반 할 것인가? 전체 시스템이 고려되어야 하는 것은 당연하다. 시스 개발 도구가 필요하다. 템 일부만을 설계하고 최적화한다면 부분적인 최적화만 가능하 PREEvision을 이용한 모델 기반 접근방식 게 될 것이다. 또한, 새로운 컨셉의 타당성을 조기에 평가하여 이 E/E 아키텍처와 관련된 모든 고려사항을 반영하기 위해, PREEvi- 최신 자동차들의 전기/전자(E/E) 시스템에 의해 제공되는 다양한 있다. 실제로, E/E 아키텍처의 모든 평가 기준들은 ECU 네트워크 후 개발 단계에서의 리스크를 최소화해야 한다. 마지막으로, “좋 sion은 모델 기반 접근방식을 지원한다. 즉, E/E 아키텍처의 모든 기능들은 전통적인 파워트레인, 섀시, 바디 및 멀티미디어 분야 설계 및 ECU 기능 할당에 직간접적으로 영향을 받게 된다. 은” 아키텍처의 최적화 목표도 정의되어야 한다(그림 2). 비용, 중 고려사항이 하나의 통합된 모델에 반영된다: 네트워크 및 기능 들과 관련되어 있다. 하지만, 차량의 신기술이 발전함에 따라 운 량, 설치공간에 관한 규격 및 최대 허용 전력 사용량 등 “명백한” 분산; 하드웨어, 와이어링 하네스 및 지오매트리; 통신 및 소프트 전자 보조 시스템, 커넥티비티 등과 같은 분야들이 그 어느 때보 와이어링 하네스 또는 차량 내부 통신에 대한 요구사항은 설계 목표들부터 먼저 정의되어야 한다. 웨어; 그리고, 이와 관련된 모든 기능, 특징 및 요구사항. 복잡한 다 중요해지고 있다. 더 이상 차량에만 국한되지 않고 자동차 외 초기 단계부터 반드시 고려해야 하는 중요한 기준이다. 그 외에 E/E 시스템을 처리하기 위해, PREEvision은 세 가지의 검증된 시 부에서도 사용 가능한 완전히 새로운 기능들도 등장하고 있다. 도, 다양한 고려 사항들이 존재한다: 예를 들어, 차량 외부 통신에 이러한 목표들은 하드웨어 관점에서 E/E 구성 요소에 영향을 미 스템 엔지니어링 원칙을 준수한다: 추상화, 분해 및 재사용. 또한, 설계 컨셉 단계에서 합리적인 설계 결정을 내릴 수 있다면, 이렇 대한 요구사항이 설계 기준에 반영되어야 하며, 카메라 및 레이 치며 와이어링 하네스에도 영향을 미친다(그림 3). 하지만, 아키 다양한 모델 레이어를 갖는 제품 라인들과 제품 베리언트들의 모 게 복잡하고 다양한 기능과 ECU의 네트워크를 훨씬 쉽게 처리할 더 센서가 있는 운전자 보조 시스템은 자동차 환경 모델을 제공 텍처 최적화가 이러한 목표에만 국한되는 것은 아니다. 구현된 델링도 지원한다(그림 4). 수 있을 것이다(그림 1). 한다. 필요한 통신 전송 성능을 충족시키기 위해 Ethernet 기술은 자동차 기능들과 관련된 다음과 같은 또 다른 목표들이 존재한 점점 더 많이 사용되고 있는 추세이다. 예상대로 Ethernet이 다: 버스 및 ECU에 대한 실시간 요구사항, 진단 및 서비스 요구사 PREEvision 모델에서는 설치 위치와 배선 경로는 지오매트리 레 기능 및 ECU 네트워크 CAN, LIN 및 FlexRay와 함께 사용되는 미래 표준으로 자리 잡을 항, 버스 부하 제한, 안전 및 보안 요구사항 등. 이어에서 와이어링 하네스 레이어, 전기 회로 레이어 및 ECU 네 대부분의 E/E 기능들은 개회로 제어, 폐회로 제어, 모니터링 및 경우, E/E 아키텍처의 기술적 중요성은 더욱더 커질 것이다. 트워크 레이어에 이르는 추상화 레이어에 모두 표현되고 확인할 진단 기능의 범주에 속한다. 이러한 기능들은 기계적 차량 부품 E/E 아키텍처는 궁극적으로 하나의 개별 차량을 위한 것이 아니 수 있다. 소프트웨어 및 통신 세부 사항은 이와 동시에 모델링된 들과 센서 및 액추에이터를 통해 상호 작용한다. 센서와 액추에 기능 네트워크는 더 이상 차량 내부에만 국한되지 않고, 차량 외 라 차량, 차량 베리언트 및 차량 옵션들의 구성을 지원해야만 한 다. 하드웨어 및 소프트웨어 내용은 논리 기능 아키텍처 레이어 이터는 차량 내에서 설치되는 위치가 다르므로, E/E 시스템은 자 부에서 제공되는 기능도 포함할 것이다. 이런 변화는 결국 “무선” 다. 이러한 이유로, 제품 라인 요구사항과 관련된 다음과 같은 필 에 추상적으로 표현된다; 요구사항 및 고객 기능에 관한 레이어 연적으로 기하학적으로 분산된 시스템이다. 대부분 기능은 한 도 연결을 통해 자동차가 통신망이나 서비스에 연결되기 때문에 수 목표들이 고려된다: 에서는 더욱더 추상화되어 표현된다. 메인 내에서 네트워크로 연결되지만, 도메인 경계를 넘어 연결되 E/E 아키텍처의 보안 요구사항이 더욱 증가하게 될 것이다. 차량 > 베리언트 및 옵션 는 경우 또한 존재한다. 특히, 운전자 보조 기능은 파워트레인, 조 베리언트의 증가에 따라 더 중요해지고 있는 베리언트, 제품 라 > 장비 탑재 차량의 예상 생산량 및 비율 PREEvision 모델은 같은 레이어 내에서 분해할 수 있다. Top- 향 및 제동 시스템 기능과 긴밀하게 연동된다. 이러한 이유로, 인 그리고 플랫폼 관리와 함께 더 많은 안전 요구사항을 만족시 > 기능 중심 분해 또는 컴포넌트 중심 재사용 down 혹은 Bottom-up 모델링이 가능한 계층 개념은 각 모델 레 ECU 네트워크에 기능을 분산하고 할당하는 과정은 설계의 주요 켜야 하는 자율 주행 트렌드는 새로운 도전과제가 되고 있다. 기 > 컴포넌트 및 하위 시스템에 최적화된 사용 전략을 기반으로 이어에 존재한다. 세 번째 방향은 다른 두 방향들(Top-down, 자유도를 나타내기 때문에 매우 중요한 설계 결정요소라 할 수 존 도메인에서 널리 적용되었던 AUTOSAR 플랫폼조차도 변화에 하는 빌딩 블록 접근 방식 Bottom-up)과 수직이며, 모델 레이어 및 계층 구조 수준에서 재 사용 및 변형 개념을 사용할 수 있다.
2/0 2/1 결과적으로, E/E 아키텍처는 선택된 베리언트로부터 도출할 수 기반으로 평가된다. 주로 사용되는 베리언트는 다음과 같다: 기 있고, 이것을 사용자가 정의한 아키텍처 최적화 기준(매트릭스) 본옵션 모델, 인기 모델 및 풀옵션 모델 (그림 5). 에 따라 평가할 수 있다. PREEvision은 아키텍처 설계자들이 하 기본옵션 모델은 반드시 저렴한 가격에 공급되어야 하며, 비용 나의 제품 라인상에서 동시에 작업할 수 있는 협업 플랫폼을 통 편익 비율이 가장 중요한 설계 기준이다. 인기 모델이란 생산량 해 공동 작업 환경을 제공한다. 모든 아키텍처 요소들은 버전 관 이 가장 많고 경쟁력 있는 가격에 적정 기능이 제공되는 모델을 리의 대상이 되며, 변경 및 배포 프로세스와 연계되는 티켓에 연 말한다. 풀옵션 모델의 경우, 모든 E/E 시스템과 옵션들이 중량, 결할 수 있다. 설치 공간, 버스 부하, 전력 소비량 등과 같은 모든 설계 기준들 과 제한 조건들을 충족시키면서 정상적으로 작동해야 한다. 그리 일반적으로, 모델 기반 아키텍처 개발은 일반적으로 처음부터 시 고 이 모델은 예상 생산량이 적고 차량 가격은 높으므로, 비용은 작하는 것이 아니라 기존 아키텍처를 기반으로 추가적으로 개발 중요한 기준이 아니다. 하게 된다. 따라서, 최적화 또는 혁신의 결과물은 차세대 아키텍 처에 고려된다. 일반적인 절차는 이전 아키텍처의 데이터를 가져 따라서, 최적화 목표들은 다양할 뿐 아니라 베리언트에 따라 달 온 후, 통합 및 검증을 거치는 것이다. 라진다고 할 수 있다. 또한, 초기에는 수요가 별로 없던 옵션들이 수요가 증가함에 따라 나중에는 기본으로 장착되는 것처럼 시간 그런 다음, 차세대 아키텍처에 반영할 혁신 사항들이 개념화된 에 따라 변하기도 한다. 이러한 이유로, 현재 일반적으로 적용되 다; 다양한 대안들을 평가하고 사용자가 정의한 최적화 목표들과 는 최적화 기준은 존재하지 않는다. 오히려, 최적화 전략은 자동 비교하게 된다. 최상의 아키텍처 솔루션이 결정되면, 제품 양산 차 제조업체의 지적 재산으로 간주한다. 이러한 이유로, PREEvi- 개발을 위한 기초로 활용할 수 있도록 해당 아키텍처를 내보내게 sion은 스크립트(매트릭스)를 통한 완전한 데이터 모델 접근 방 된다. 이러한 방식으로, 착수 단계에서 신규 E/E 아키텍처 컨셉의 식을 제공하므로 사용자는 PREEvision을 활용해 최적화 전략을 질을 확보할 수 있게 된다. 하지만, 아키텍처 개발은 양산 개발 프 유연하게 결정할 수 있다. 글로벌 시장을 선도하는 자동차 제조 로젝트가 시작되기 전에만 시행되는 활동이 아니라, 양산 개발 업체들이 이러한 개념을 10년 이상 성공적으로 적용한 사례들이 도중에도 지속해서 수행되고 평가해야 하는 작업이다. PREEvision의 우수성을 증명한다. 대규모 자동차 생산 라인들에 는 수백만 모델 요소들이 포함된다; 사용자와 긴밀하게 협력하며 아키텍처 설계의 평가 및 최적화 데이터 모델, 엔지니어링 도구 및 메트릭 인터페이스를 지속해서 그림 2: : E/E 아키텍처 최적화의 목표 실제로, E/E 아키텍처는 일반적인 차량 구성 및 장비 베리언트를 개발하고 있다.
엔지니어링 데이터 모델은 관련 자동차 표준에 따라 구축된다: 고장 모드 및 영향 분석), FTA(Fault Tree Analysis; 폴트 트리 분 요구사항, 고객 기능 및 테스트 케이스를 위한 RIF 및 ReqIF; 시스 석) 등과 같은 안전성 분석 도구들을 사용하여 기존 제품 라인모 템, 소프트웨어 및 통신 설계를 위한 AUTOSAR; 와이어링 하네스 델을 에 대해 분석하게 된다. 통합 모델 기반 접근 방식은 단일 및 지오매트리 사양을 위한 KBL 및 VEC. 소스 원칙을 지원 가능하게 하며, 모델의 모순 및 완성도에 대한 확인도 가능하다. 하드웨어 및 소프트웨어의 구현을 통해 추상화되는 논리 기능 아 키텍처는 또 다른 이점을 제공한다. 많은 차량 기능의 경우, 기능 고객 기능 모델을 사용하게 되면, 고객 기능을 유효하게 선택하 구현을 위한 하드웨어, 소프트웨어 및 통신 기술들은 차량 세대 도록 도와주며, 선택된 고객 기능과 연결된 다른 레이어의 모델 에 따라 변화하지만, 논리 기능 아키텍처 레이어는 수년간 변하 요소들까지 차량 베리언트에 손쉽게 포함하여 구성할 수 있다. 지 않는다. 이런 레이어들은 “매핑”이라고 하는 요소를 통해 상호 연결된다. 기능안전 측면에서는 HARA(Hazard and Risk Analy- sis; 위험/리스크 분석), FMEA(Failure Mode and Effects Analysis;
그림 3: PREEvision의 와이어링 하네스 설계 그림 4: PREEvision 모델의 레이어 구성 그림 5: 아키텍처 설계의 다면 평가
2/2 2/3 최적화된 툴 지원을 통한 안정적인 아키텍처 작업 모델 기반 E/E 아키텍처 설계는 차세대 모델들의 다양한 새로운 기능을 반영할 수 있어야 한다. 특히, 운전자 보조 시스템 및 커 넥티비티 분야는 주요 기술적 변화를 이끌고 있다. E/E 아키텍처 설계자들은 위와 같은 혁신을 전통적인 파워트레인, 섀시, 바디 및 멀티미디어 도메인과 연결해야 하는 과제에 직면하고 있다.
이런 과제를 해결하기 위해 E/E 아키텍처 설계자들은 반드시 다 양한 최적화 목표를 달성해야 한다. 비용, 중량, 설치 공간 등 전 체 모델 목표를 달성하는 것만으로는 부족하다.
미래 E/E 시스템들의 기능이 지속해서 늘어남에 따라 안정적인 아키텍처 작업과 체계적인 아키텍처 의사결정의 중요성은 더욱 증대할 것이기 때문에, 모든 분야를 지원하는 도구는 아키텍처 설계자들에게 반드시 필요하다. PREEvision은 다양한 기능을 통 해 모든 분야를 지원하고 있으며, 자동차 산업의 최신 기술과 개 발 표준도 반영하고 있다.
선택된 베리언트를 대상으로 최적화 기준을 평가할 수 있으며, 또한 기준을 유연하게 정의할 수 있다. 모델 기반 접근법의 핵심 고려사항은 아키텍처 개발 작업이 제품 양산 개발과 함께 진행되 는 프로세스이며, 관련된 모든 관계자와 긴밀한 의사소통이 필요 하다. 이러한 접근방식은 PREEvision이 최신 E/E 아키텍처의 설 계 및 최적화에 가장 적합한 툴이라는 사실을 입증하는 여러 이 유 중 하나이다.
Dipl.-Ing. Jörg Schäuffele
Vector Informatik GmbH 의 PREEvision Product Manager이다.
Translation of a German publication in Automobil Elektronik, issue 11-12/2016 이미지 권리: Vector Informatik GmbH
2/4 미들웨어를 사용하면 예전처럼 시스템을 설계할 때가 아니라 실 SOA 방법론 – 하향식 접근법 행 중에 서비스 제공자와 서비스 소비자 사이의 연결을 생성하게 OEM과 공급업체가 SOA의 장점을 발휘하기 위해서는 필요한 모 된다. 그리고 미들웨어는 과거 소프트웨어 개발에서의 여러 가지 든 개발 단계를 통해 새로운 시스템의 설계를 지원하는 적절한 방 문제들을 다루게 된다. 우선, 시스템을 부분적으로 업데이트할 법이 필요하다. 여기서 목표는 복잡성을 관리하는 동시에 품질이 수 있게 된다. 만약 이전 버전과의 호환성이 보장된다면, 서비스 보증되는 설계를 구현하는 것이다. 아래에 기술된 방법은 요구사 변경은 서비스의 모든 소비자에 대하여 소프트웨어 적용에 영향 항으로부터 서비스 아키텍처를 구성하고 통신 설계로 이어지는 을 미치지 않는다. 또한, “소프트” 마이그레이션 시나리오는 서비 전반적인 개발 프로세스를 설명하고 있다. 스 인터페이스의 버전 관리 및 리비전 제어를 사용하면 가능하게 된다. 이것은 시스템의 모든 부분이 서비스의 이전 버전을 사용 이 방법의 목표는 차량 혹은 차량의 서브 시스템을 위한 AUTO- 하는 반면, 다른 부분은 이미 서비스 인터페이스의 새로운 측면 SAR Classic 호환 시스템 디스크립션을 정의하는 것이다. 그뿐만 을 사용할 수 있도록 해준다. 또한, 설계에 고장 안전성을 도입할 아니라, AUTOSAR Adaptive 또는 AUTOSAR가 적용되지 않은 시 수도 있다. 하나의 서비스 인스턴스에 고장이 발생할 경우, 다른 스템에도 적용할 수 있다. 서비스 인스턴스 또는 적어도 호환 가능한 다른 서비스 인스턴스 차량에서의 서비스 지향 아키텍처와 가 그 기능을 대신할 수 있다. 이것은 즉, 분산 시스템에서 하나 개발 프로세스는 기능이 구체적으로 명시된 새로운 기능의 아이 의 서비스에 관련된 모든 ECU가 업데이트될 필요성이 없다는 의 디어에서 출발한다. 최근에는 이런 기능 아이디어들은 보통 사용 Ethernet 미이다. 사례에 따라 구조화된다. 통합 모델링 언어(UML) 표준의 사용 사 례 다이어그램의 표기법은 이런 목적으로 사용하기에 적합하다 끝으로, 일관성 있는 서비스 설계는 구현 단계에서 더욱 효과적 고 입증되었다. 사용 사례를 이용하여 서비스는 기능 카탈로그에 모델 기반 방식의 이동식 데이터 센터를 향하여 인 설계 또한 가능하게 만들어 준다. 예를 들어, 원격절차호출 서 도출될 수도 있다. 서비스를 구조화하고 의존성를 설명하기 위 (RPC)은 서비스 지향 아키텍처에서 흔히 사용된다. 이전에는 해서는 다양한 관점이 필요하다. ECU에서만 사용이 되었던 RPC가 이제는 차량 네트워킹에서도 클라이언트-서버 패러다임의 사용으로 인해 사용되고 있다. 결과 명백하고 이미 확립된 관점은 정보의 흐름을 지향하며, 이에 따른 적으로, 과거 차량의 통신 설계에서 당연시 되었던 신호 지향성 기능의 종속성을 보여준다. 시스템 설계 도구인 PREEvision에서 은 점점 약해지고 있다. 는 “논리 아키텍처”가 이런 목적으로 자리 잡고 있다. 논리 아키
서비스 지향 아키텍처(SOA)는 IT 산업에서 수년간 분산 시스템을 설명하고 구조화하기 위해 사용됐다. 어떻게 하면 스마트폰처럼 자동차 본래 기능의 범위를 확장하고 싶어 하는 사용자의 요구를 만족시킬 수 있을까? 이런 요구를 충족시키기 위해 서비스 지향 설계는 자동차 산업에서도 매우 중요해지고 있다. 또한, 모델 유지 관리에서 추가적인 요구사항을 처리하고 자율주행 및 V2X 통신 과 같은 기술을 도입해야 한다.
오늘날 차량 소프트웨어 개발은 어려운 도전에 직면해 있다. 수 라 차량 간 그리고 차량 주변 환경 혹은 인터넷과의 통신을 위한 년간 증가해 온 자동차 제조의 복잡성 외에도, SOA 도입은 완전 적절한 대역폭을 Ethernet 기술로 구현할 수 있다. 따라서 미래의 히 새로운 개발 패러다임과 프로세스를 초래한다. Conway는 E/E 아키텍처를 개발하려면 시스템 설계 및 유지 보수 시 이러한 1968년에 이미 아래와 같이 말했다. 요구 사항을 고려한 도구가 필요하다.
> “시스템을 설계하는 조직들은 부득이하게 조직들간의 의사 서비스 지향의 장점 소통 구조와 아주 흡사한 설계를 만들게 된다..” [1] SOA에서는 명확하게 정의된 인터페이스가 특징인 서비스 환경 이 생긴다. 이상적으로, 이러한 인터페이스는 구문론적으로나 의 그래서 오늘날 차량의 소프트웨어 아키텍처가 대부분 사일로 구 미론적으로 형식적으로 명확하게 설명된다. 그리고 이런 명확한 조를 가지고 파워트레인, 바디와 섀시 등과 같은 영역에 따라 기 정의는 서비스를 구조화할 수 있도록 해준다. 예를 들어, 서비스 존의 조직 구조를 재생산하는 것은 당연하다. 그러나, SOA를 효 에 대한 종속성을 전달하고 명확한 설계 규칙을 나타내는 계층화 과적으로 도입하려면 완전히 서로 다른 도메인 간의 조정과 통신 된 아키텍처가 일반적으로 사용된다. 또한, SOA에서 컴포넌트들 이 필요하다. 이 점에서 책임은 과거의 부서 및 조직의 경계를 넘 은 미들웨어로서의 서비스 버스와 함께 서로 느슨하게 결합한다. 어선다. SOA와 그 인터페이스를 결정하고 더 개발해 나가기 위 여기에서 미들웨어는 서비스 제공자와 서비스 소비자 사이의 중 해서는 회사 내의 협동과 협업이 내재적인 전제 조건이 된다. 이 개자 역할을 한다. 미들웨어는 시스템 시작 시 서비스 제공자와 런 조직의 변화는 인사 영역에도 영향을 미치게 된다. 회사에는 서비스 소비자 간의 통신을 제어한다. 그리고 또한 제어기의 베 새로운 업무과 직무 요구사항들이 생겨나고, 필요한 전문가들을 이직 소프트웨어(BSW)나 운영체제(OS)에 의해 관리되는 데이터 교육하거나 채용해야 한다. 직렬화를 정의한다. (그림 1)
기술적인 면에서는, 서비스 기반 통신으로 인해 차량 네트워킹에 “직렬 변환기”라고 하는 정확한 계산법은 물리적 통신 버스에서 서의 대역폭 수요가 엄청나게 증가하는 경향이 짙어진다. 이로 의 데이터 전송을 설명한다. 직렬 변환기는 데이터가 직렬 비트 인해 OEM들은 IT 산업에서 성공적으로 입증된 Ethernet 기술에 스트림으로 변환되는 방법과 수신 쪽에서 직렬화를 해제하는 방 그림 1: 서비스 및 미들웨어 다이어그램 점점 더 의존하고 있다. 응용프로그램들과 차량 내부 뿐만 아니 법을 결정한다.
2/6 2/7 그림 2: : 서비스 orchestration 의 정적 정의를 위한 논리 아키텍처
텍처는 블록 다이어그램의 형태로 나타낼 수 있으며, 하드웨어나 타입으로도 표현할 수 있다. 이것은 서비스의 정적인 동작을 완 소프트웨어의 구현과 무관하게 기능 체인(Activity chain)을 통해 벽하게 설명하게 된다. 개별 서비스 기능들의 기능적인 연결을 표현한다. (그림 2) 그림 3: PREEvision에서 논리 서비스 노드(참가자)의 정의를 위한 SOA 다이어그램 이 외에, 서비스 아키텍처를 설명하는데 사용하는 UML 프로파일 SOA 포트 간의 서비스 계약의 의미는 주로 텍스트 형식으로 기 인 “SoaML”은 “참가자”라는 논리 노드를 규정한다. 참가자는 서 술하게 된다. 이것은 서비스 역할 간의 시간 순서를 구체화하고 비스 제공자와 소비자 모두로 나타날 수 있다 – 교환은 두 경우 무엇보다도 특히 프로토콜을 보여준다. 이 설계 단계는 “service 통신 설계 요약 에 모두 소위 “SOA 포트”라 불리는 것을 통하여 일어난다. 이것 choreography”라고도 불린다. UML 표준이 제안하는 협업 또는 이후 과정에서는 사용된 통신 버스 기술과 미들웨어에 따라 데이 PREEvision은 서비스 지향 아키텍처의 방법론적이며 일관성 있 은 눈에 보일 정도의 서비스 간 의존도 – 예를 들어, 참가자가 하 메시지 시퀀스 차트(MSC)는 보통 시퀀스를 시각화하기 위하여 터 공급과 통신 정의의 구조가 달라진다. AUTOSAR는 기본값으 는 설계를 지원한다. 사용자는 통합된 작업 흐름을 통해 서비스 나 또는 그 이상의 (기본) 서비스의 소비자이고 이에 대하여 고품 사용된다. 로 인터넷 프로토콜에 의한 서비스 지향 미들웨어(SOME/IP)를 인터페이스의 정의에서부터 서비스의 상호작용에 대한 사양 및 질의 서비스를 제공하는 경우 – 를 만든다. 이러한 설계 단계를 서비스 발견과 데이터 직렬화를 위한 변환기처럼 사용한다. AUTOSAR 호환 Ethernet설계까지 할 수 있게 된다. 만일 Ether- “orchestration”이라고 부르며 제어 기능을 위해 널리 사용되고 원래 기술과 관계없이 서비스의 정식 정의는 보통 인터페이스 정 net뿐만 아니라 CAN, LIN 또는 FlexRay와 같은 다른 버스 기술 있는 이벤트 체인 관점과 유사하다. 의(인터페이스 정의 언어, IDL)를 통하여 전송된다. PREEvision과 AUTOSAR는 다른 변환기와 미들웨어 또한 제공한다. 만약에 또한 사용된다면, 혼합 토폴로지 또한 설계할 수 있다. 그래서 같은 현대적인 시스템 설계 툴에서는 AUTOSAR Class 기반의 어 Ethernet과 인터넷 프로토콜(IP)이 통신 채널로 사용된다면, IP 주 PREEvision은 시스템 설계자가 전통적인 임베디드 설계를 최근 그러나, 서비스의 다중 인스턴스가 시스템 내에서 서로 다른 버 플리케이션을 위한 구현의 외부 구조 같은 것이 여기에서 도출될 소, 전송 프로토콜 및 포트 면에서 소켓을 필수적으로 정의해야 의 서비스 지향과 필요한 백엔드 통신을 결합하는 과제를 수행할 전으로 존재하고 있는 완전히 동적인 시스템에서, 참가자에게 서 수 있다. 한다. 소켓 주소 정의가 AUTOSAR Adaptive에 충분하지만, AU- 수 있도록 도와주고 이를 통해 스마트카 설계로 나아가는 것을 비스 할당을 이렇게 나타내는 것은 런타임에서만 발생할 수 있는 TOSAR Classic에 있어서 신호 레벨도 반드시 지정되어야 한다 지원한다. 시나리오이다. 자동차 부문에서 서비스는 현재 주로 전용 하드웨 이것은 설계에 관하여 추가로 상세하게 제공하고 그것을 구현하 – 그 이유는 AUTOSAR Classic의 베이직 소프트웨어 스택이 Flex- 어에 정적으로 할당되어 있으므로 이런 표현은 ECU에 대한 서비 는데 필요한 구현체를 만든다. 나아가, 서비스의 역할과 서비스 Ray 또는 더 널리 사용되는 Controller Area Network(‘CAN’) 버 스의 역할 (제공자/소비자) 할당으로 이해할 수 있다. 이 외에, 참 인터페이스의 정의를 대신하게 된다. 이러한 일관성 있는 접근법 스와 Local Interconnect Network(‘LIN’)에서 사용되는 신호 기반 가자는 런타임에 발생하는 다양한 배열을 볼 수 있게 할 수도 있 의 장점은 서비스 역할의 변경이나 서비스 인터페이스의 정의가 의 통신을 위해 설계되었기 때문이다. 여기서 통합 시스템 설계 다. 그래서 논리 서비스 노드를 참가자처럼 표현하는 것은 유용 동기화 방식을 통하여 자동으로 특정 기술의 구현으로 이어진다 툴은 이전 단계의 작업 결과물을 기반으로 하여 신호 통신 데이 한 분석 툴처럼 보이기도 한다. 끝으로, 이런 배열에 익숙해지고 는 점이다. 소프트웨어 설계 인터페이스들은 IDL 정의로부터 도 터를 도출해낼 수 있다는 결정적인 장점을 제공한다. 서비스 정 문서화하는 것은 시스템을 테스트하고 보호하기 위한 중요한 기 출할 수 있고, 이것들은 AUTOSAR Classic 플랫폼에서 Send- 의와 시스템의 어디에서 서비스를 제공할 것인지에 관한 정보, 반이 된다.(그림 3) er-Receiver / client-Server 인터페이스로 표현된다. 기술에 적합 즉 어떤 ECU가 제공자를 구현하고 어느 ECU가 소비자를 구현하 한 파일 종류가 이미 선택된 경우에는 자동으로 인계된다. 는지에 관한 정보가 필요하다. 이 점에서 PREEvision은 서비스 및 위에서 언급한 SOA 포트는 여러 측면에서 분명하게 정의된 서비 메소드 Id와 같은 추가적인 속성을 서비스 정의로부터 통신 정의 스 인터페이스에 의해 분류된다. 우선 포트가 어떤 역할을 하는 특별한 “서비스 인터페이스”의 도입은 AUTOSAR Adaptive 플랫 로 전송한다.(그림 4) 지 – 서비스를 제공하는지 아니면 서비스의 소비자인지 - 명확히 폼을 위해 논의되었다. 이것은 위에서 정의된 속성들을 직접 포 해야 한다. 인터페이스의 속성은 여기에서 일반적으로 유효하고 함하고 서비스의 기술 독립적인 정의를 최대로 활용하기 위한 것 사용 가능한 메소드, 필드 및 이벤트와 같은 기술-독립적인 속성 이다. 목표는 버튼을 한번 눌러서 동일한 서비스 정의로부터 다 을 이용하여 구문적으로 표현할 수 있다. 뿐만 아니라 이미 알려 양한 기술을 위한 구현체를 도출해내는 것이다. 이 단계 이후에 져 있고 메소드의 변수와 같이 미들웨어에 의해 지원되는 데이터 는 미들웨어별 시작 동작을 명시해야만 하고 매개변수를 표시해 야만 한다. 이 프로세스를 “서비스 발견”이라고 한다.
2/8 2/9 그림 4: 서비스 설계에서 통신 설계까지
참고문헌:
[1] Conway’s law: http://en.wikipedia.org/wiki/Conway%27s_law (January 19, 2017)
저자
Dipl.-Ing. (FH) Markus Helmling Vector Informatik GmbH Product Management Engineer PREEvision
Originally published in “Elektronik automotive” magazine Special issue “Automotive Ethernet” – March 2017
2/10 그림 1: 추출 단계별 하드웨어 설계 모델링
ISO 26262에 근거한 하드웨어 설계 및 분석 통해 이 평가를 보완할 수 있다. 이때, 다음과 같이 두 가지 평가 통합 모델링 를 적용할 수 있다: 1) 설계의 총체적 분석이 요구되는 “랜덤 하 초기 단계에서, 관련 ASIL과 함께 안전 목표(SG)는 전체 시스템에 신규 개발 전자 브레이크 시스템(EBS)을 기초로 한 안전 평가 드웨어 결함에 대한 확률적 메트릭 평가 (PMHF)”, 2) 개별 하드 대한 위험 분석 및 리스크 평가(Hazard Analysis and Risk As- 웨어 구성요소의 개별적인 분류를 제시하는 “안전 목표 위배 원 sessment, HARA)로 부터 도출되며, 이는 요구사항 레벨에서 저 ISO 26262에 따른 자동차 기능 안전을 달성하기 위해서는 하드웨어 안전 평가 및 특정 안전 지침 개발을 위한 폭넓은 요구사항과 인에 대한 평가 (FRC 방법)“ 장된다(그림 1a). 노력이 동반된다. 본 기술 기사는 이미 모델 기반의 PREEvision 시스템 엔지니어링 툴에 통합되어 반복적인 설계/분석 프로세스를 지원하는 효율적인 방법론에 대하여 소개한다. ISO 26262에 근거한 방법론과 관련 툴을 제시하는 것 외에도, 신규 개발한 전자 브 하드웨어 안전 평가 프로세스 시스템 개선은 기능 및 기술 안전 요구사항(FSR, TSR)을 사용하 레이크 시스템(EBS)에 대한 안전 평가를 활용한 구체적인 응용 사례도 소개한다. 반복적으로 진행되는 공동 개발 프로젝트에서 모델 기반의 환경 여 실행되며, 이는 반복적으로 업데이트된다. 또한, 잔여 및 잠재 은 ISO 26262에 의해 요구되는 하드웨어 안전 평가를 지원하기 결함과 관련하여, 진단 범위에 대한 특정 값을 활용해 안전 매커 에 가장 적합한 환경이다. 특정 라이브러리 기반의 하드웨어 설 니즘을 정의하는 것도 필수적이다. 계는 저장된 결함 정보를 이용해 모델링 된다. 모델 정보를 통해 구축된 데이터베이스로 요구 안전성 평가를 보다 간편하게 수행 하드웨어 설계를 모델링하기 위해, 하드웨어 아키텍처 설계(그림 ISO 26262 “자동차 기능 안전” 표준이 시행되면서, 엄격한 안전 두 가지 설계 요구사항이 명시되어 있다: 1) 하드웨어의 아키텍 할 수 있다. [3] 1b)의 형태로 기능 및 기술 안전 컨셉이 구현될 수 있다(그림 1c). 관련 요구사항이 자동차 산업, 자동차 개발 프로세스 그리고 관 처 설계는 하드웨어 컴포넌트로 구성되어 있으며, 기초 하드웨어 라이브러리에 저장된 하드웨어 요소를 해당 다이어그램에 직접 련 제품에 적용되고 있다. ISO 26262는 안전 관련 시스템 개발에 설계에 대한 추상적, 기능적 관점으로 기술되어야 한다. 2) 반면, 계산된 평가 결과 표시를 지속해서 업데이트하는 방식으로, 각각 대입할 수 있다(그림 1d). 라이브러리에 저장된 통계적 결함 정보 대한 의무, 프로세스, 문서 및 기술과 관련하여 엄격한 규정을 적 하드웨어의 세부 설계는 하드웨어 내부 소자들로 구성되어있으 의 개발 단계별로 반복되는 작업을 지원한다. 이는 목표 지향적 는 개별 하드웨어 요소에 자동으로 전송될 수 있다. 용하고 있다. 제조사는 개발 단계에서 시행되는 부분적인 시스템 며, 전자 회로 레벨에서 하드웨어 컴포넌트의 개선사항을 나타내 인 설계 변경 절차를 간소화한다. 잘 구상된 맞춤형 운영 컨셉은 평가뿐 아니라, 사용 기간 내내 전체 시스템을 평가해야 한다. 안 야 한다. 본 기사에서는 해당 항목들을 간단히 하드웨어 설계 및 매우 사용자 친화적이며, 보고서 자동 생성으로 인해 문서 작업 전 시스템은 반드시 해당 자동차 안전 무결성 등급(Automotive 하드웨어 요소라고 언급할 것이다. 이 대폭 감소한다. 추적성 및 설계 최적화 Safety Integrity Level; ASIL)에 부합되어야 한다. 따라서 안전 기 하드웨어 요소에 대한 결함 정보는 결함 라이브러리로부터 전송 능 실행과 관련된 모든 하드웨어 및 소프트웨어 컴포넌트가 ASIL 임의의 하드웨어 결함 분석과 관련된 필수 안전 평가는 통계적인 결함 라이브러리 되기 때문에, 일관성 있고 추적 가능한 결과가 보장된다(그림 의 평가 대상이 된다. 적절한 개발 툴을 사용하여, 이와 관련된 노 결함 정보를 기반으로 시행되며, 관련 사항은 ISO 26262 5장 8항 하드웨어 요소 결함과 관련된 통계 정보(예. 결함 발생률, 결함 모 2a). 별도로 데이터를 관리할 필요가 없으므로, 엔지니어는 기능 력을 최소화할 수 있다. “하드웨어 설계 메트릭에 대한 평가”에 자세히 설명되어 있다. 이 드, 결함 모드 별 결함 발생률 분포 등)는 결함 라이브러리에 저 안전에 관한 설계 분석 및 최적화 작업에만 집중할 수 있다. 따라 평가는 “단일 결함 메트릭”과 “잠재 결함 메트릭”으로 구성되어 장된다. 결함 라이브러리는 Siemens 규약 SN 29500과 같이 잘 서, 엔지니어는 새롭게 도입되는 안전 매커니즘이나 추가적인 하 하드웨어 관점에서 본 기능 안전 있으며, 이를 통해 하드웨어 설계의 견고성에 대한 결론을 도출 알려진 산업 소스를 바탕으로 구성될 수 있으며, 기업 내부 데이 드웨어 요소에 대한 평가의 효과를 분석하는 데만 집중할 수 있 ISO 26262에 명시된 기능 안전성과 관련된 활동 및 제품[1]의 종 할 수 있다. 터베이스의 과거 자료를 저장하기 위해 쉽게 확장할 수도 있다. 다. 류는 매우 광범위해서, 체계적인 표준임에도 불구하고 이를 기존 9항에 명시된 일종의 확률적 안전 분석 단계인 “임의의 하드웨어 추가된 결함 정보는 다른 하드웨어 설계를 진행하는 타 개발 부 의 프로세스나 툴에 적용하는 것이 어려운 경우가 많다[2]. 본 표 결함으로 인한 안전 목표(Safety Goal) 위반 사항에 대한 평가”를 서에서도 재사용할 수 있다. 준의 5장에 따르면, 하드웨어 제품 개발과 관련하여 다음과 같이
2/12 2/13 조정 가능한 대기 시간 T를 기준으로 산출된다(주의: 평균값은 “ 례에서는 요구 사항 간의 인터페이스, 아키텍처, 설계 및 안전 분 조건부 결함 강도”에 해당한다. 예를 들어, 시간 T0에 결함이 전 석 결과 사이의 상관관계를 중점적으로 파악할 것이다. 무한 경우, 시간 T상의 결함 확률을 의미한다. 최악의 시나리오는 시스템 수명을 [T-T0 = 수명]으로 설정하는 것이다). 또한, 최소 안전 목표 SAF_REQ_1, “BBW 보조 에너지의 평균 손실 확률은 한의 선별 과정을 기반으로 하는 결함 트리의 정성적인 분석을 3e-09/h 미만이어야 한다”는 HARA로부터 도출되었다. 기능 안 통해 설계 제약 조건들을 파악할 수 있다. 전 개념도는 KL30_2 터미널을 통해 인접한 EBS-액추에이터 시스 템 요소에 전원을 공급한다. 보고서 ISO 26262에 명시된 문서화 요건은 매우 중요하다. 따라서 모델 필요할 경우, ALT 선택 스위치를 사용하여 두 번째 전원 공급 장 기반의 접근 방식이 매우 효과적일 수 있다. 안전성 입증을 위해, 치 VP1로 전환할 수 있다. VP1는 사용성 향상을 위한 예비 장치 그림2: “하드웨어 아키텍처 메트릭” 결과 값 및 FRC 방법이 표시된 결함 데이터 테이블 설계 단계에서 검토 보고서를 생성할 수 있으며, 하드웨어 설계 로, 비상 운전 시에 작동한다. 완료 이후에도 “안전 지침”에 관한 문서 생성이 가능하다. 이러한 안전 지침 문서는 하드웨어 인증을 위해 활용할 수 있으며, 이를 그림 4a에서 보듯이, 통합 컨셉의 적용은 결함 트리를 발생시킨 하드웨어 안전 평가 “하드웨어 아키텍처 메트릭에 대한 평가”는 하나 또는 복수의 안 자동 생성하는 것은 언제든지 가능하다. 그뿐만 아니라, 안전 지 다. “VP2의 미감지 손실”, “VP2의 손실 및 예비 장치(VP1 혹은 모델 기반의 안전 평가를 위해 다양한 에디터를 활용할 수 있다. 전 목표를 대상으로 결함 데이터 테이블 상에서 시행된다. 목표 침 문서를 통해 시스템의 하드웨어 안전성에 관한 현황을 파악할 ALT)의 손실” 혹은 “비상 작동 시 예비 장치(VP1 혹은 ALT)의 손 이러한 에디터를 사용하여 체계적으로 정리된 평가 결과를 확인 값은 안전 목표의 ASIL로부터 산출된다. “안전 목표 위반 원인에 수 있다. 실”이 발생할 경우, 상위 계층 이벤트가 발생한다. 최소 컷세트 할 수 있을 뿐 아니라 안전 평가에 대하여 다양한 관점으로 접근 대한 평가”를 위해, 각각의 안전 목표 위반 항목이 하드웨어 요소 (Cut Set : 분석을 시작한 결과부터 원인까지 이르는 트리를 통한 할 수 있다(그림 2b). 레벨에서 분석된다. 결함 발생률 등급 분류, 안전 목표의 ASIL 정 전자 브레이크 시스템 – 예시 루트) 분석을 통해, 개별적인 최소 컷세트의 발생 확률에 대한 예 의, 하드웨어 요소 레벨에서의 진단 범위 등이 해당 평가에 포함 본 사례는 현재 개발 중인 전자 제어 방식 브레이크(BBW) 시스 상 값이 할당되었고, 그림 4b와 같이 기능적/기술적 안전 요구사 ISO 26262에 따라 결함 데이터 테이블은 세 부분으로 구성된다. 된다. 달성된 목표 값은 테이블에 도표 형식으로 강조된다(그림 템의 안전 평가에 대한 사례이다. 쉽게 이해할 수 있도록, 평가 대 항과 설계 제약 조건이 도출된다. 다중 포인트 결함의 경우, 즉, 분석해야 되는 안전 목표 옆의 테이블 열과 안전 관련 항목에는 2c). 상은 EBS의 대체 예비 전력 공급 장치로 제한한다(그림 3). 본 사 컷세트의 계층이 1보다 큰 경우, 개별적인 결함에 대해 허용 가 해당 라이브러리의 주석이 달린 결함 정보가 수록된다. 그 옆에 는, 안전 목표의 직접적인 잠재 위반 및 다른 결함에 의한 잠재 PMHF에 대한 평가는 안전 목표 위반에 대한 확률적 분석을 총 위반과 관련된 정보가 제공된다. 또한, 안전 매커니즘이 테이블 체적으로 설명하며, 정성적/정량적 결함 트리 분석이 이를 지원 에 명시되며 결과 산출에 반영된다. 안전 목표에 대하여 결함 모 한다. 이를 위해, 안전 목표 위반사항 평가와 함께 결함 트리 상 드는 에디터 상에서 직접 분류되거나, 정성적인 오류 트리 분석 위 레벨 이벤트 상에서 발생 가능한 최악의 시나리오를 기준으로 (Qualitative FTA)을 통해 자동으로 분류된다. 산출된 정량적인 확률 데이터가 제공된다. 결함 발생률 평균값은
그림 4: 결함 트리 및 관련 안전 요구사 항과 설계 제약 조건 그림 3: 전자 브레이크 시스템의 전원 공급 시스템 요소에 대한 평가
2/14 2/15 능한 값이 결정되고, 성능 저하 및 최대 지속 기간, 경고 메시지 저자: 등과 같은 비상 작동 속성을 지정할 수 있다(그림 4c).
결론 하드웨어 설계 및 분석을 위한 단일 통합 솔루션을 통해 ISO 26262에 명시된 모든 하드웨어 안전 평가를 지원할 수 있다. 추 가적인 작업, 데이터 소스의 비일관성에 따른 오류, 툴 변경, 툴 결함 등을 대폭 줄일 수 있다. 라이브러리를 통해 엔지니어가 실 행해야 할 설계 및 분석 업무에 대한 부담이 줄어들고, 관련 정보 니코 아들러(Nico Adler) 에 대해 높은 재사용성을 제공한다. 또한, 하드웨어 설계 변경 또 독일 카를스루에(Karlsruhe)에 소재한 FZI 정보 기술 연구소의 임 는 안전 매커니즘 도입에 따른 결과를 평가 결과 내에서 즉시 확 베디드 시스템 및 센서 엔지니어링 부서에서 연구원으로 근무하 인할 수 있어, 이는 최적화 주기를 획기적으로 단축한다. 그뿐만 고 있다. 아니라, 협업 지원 기능을 이용하여 여러 부서가 공동으로 설계 및 분석을 할 수 있기 때문에 신속하고 안정적으로 변경사항을 적용할 수 있다.
데이터 현황에 근거하여 자동으로 생성되는 보고서를 활용하여, 개발 진행 현황을 언제든지 확인할 수 있을 뿐 아니라, 문서화 작 업도 대폭 줄어들었다. ISO 26262와 하드웨어 안전 평가에 대한 모델 기반 결합은 가능하며, 이는 바람직한 방향이라 할 수 있다. 에두아르 메쯔커(Eduard Metzker) 이를 통해 작업 결과물의 공식적인 완전성과 일관성을 자동 점검 독일 슈투트가르트(Stuttgart)에 소재한 Vector Informatik GmbH 할 수 있을 뿐 아니라, 안전 지침 등과 같이 자동화된 보고서를 에서 시스템 엔지니어링 툴을 관리하는 수석 제품 관리 엔지니어 생성하는 것도 가능하다. 로 근무하고 있다.
감사의 말: 본 기사의 저자들은 Stefan Buch 공학석사 및 Klaus D. Mül- ler-Glaser 교수와 더불어 도움을 주신 모든 분들께 감사의 뜻을 표한다.
스테판 오튼(Stefan Otten) 참고문헌: 독일 카를스루에(Karlsruhe)에 소재한 FZI 정보 기술 연구소의 임 [1] International Organization for Standardization, ISO 26262 베디드 시스템 및 센서 엔지니어링 부서에서 연구원으로 근무하 Standard, Road vehicles – unctional 고 있다. safety (2011) [2] Adler, N.; Otten, S.; Schwär, M.; Müller-Glaser, K.: Managing Functional Safety Processes for Automotive E/E Architectures in Integrated Model-Based Development Environments. In: SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 7(1), pp. 103 – 114, doi:10.4271/2014-01-0208 (2014) [3] Adler, N.; Otten, S.; Cuenot, P.; Müller-Glaser, K.: Performing Safety Evaluation on Detailed Hardware Level according to ISO 26262. In: SAE Int. J. Passeng. Cars – Electron. Electr. Syst. 6(1): 알렉산더 루돌프(Alexander Rudolph) pp. 102 - 113, doi:10.4271/2013-01-0182 (2013) 독일 프랑크푸르트(Frankfurt am Main)에 소재한 Continental AG의 차량 동력 사업부에서 세이프티 매니저로 근무하고 있다.
링크: 벡터 홈페이지: www.vector.com
2/16 Common to Architectures 1 + 2
150% Architecture
100% Architecture 2 100% Architecture 1
Common to Architectures 2 + 3
Common to Architectures 1 + 3 100% Architecture 3
그림 1: 150% 및 100% Common to all Architectures 아키텍처 간의 상관 관계
기능적 아키텍처로서 피처 목록 설명하기 둘째, PREEvision은 리치 텍스트 에디터에서 생성되는 ‘전형적인’ 벡터의 PREEvision 툴은 피처 목록을 모델링하기 위한 효과적인 텍스트 요구사항과 연동해 피처 목록 아티팩트를 보정하거나 구 환경을 제공하며, 논리 아키텍처뿐만 아니라 요구되는 하드웨어 체적으로 명시할 수 있다. (그림 3 참조) 와 소프트웨어에 관한 상관관계를 규정하고, 피처 목록을 추상 적, 그리고 기술적으로 구현할 수 있도록 지원한다. 또한, PREE- 셋째, 피처 목록을 구현하기 위해서 PREEvision은 정보 소스 기능 정의부터 서비스센터까지: ‘V 사이클’을 넘어선 첨단 엔지니어링 설계 vision 툴에 내장된 리졸버를 사용하여 피처 모델 내에 발생하는 (‘Sense’), 데이터 의사 결정 처리(‘논리적 기능’), 시스템 출력 데 데이터의 활용 종속성과 충돌을 자동으로 파악한다. 이터(‘액추에이터‘)에 관한 추상적인 요구사항을 생성할 수 있도 록 지원한다. 예를 들어, 그림 4와 같이 운전자에게 차량 속도 정 자동차 산업에서는 기술의 융합 및 복합화가 일어나면서 까다로운 시장 수요와 엄격한 법적 기준을 충족하는 다양한 첨단 시스템이 PREEvision은 피처 목록의 관리를 위해 테이블 편집 기능을 제공 보를 제공하는 기능을 추상적인 수준으로 모델링하는 것이 가능 요구되고 있다. 첨단 시스템으로 인해 자동차의 효율성과 안전성이 개선되고 있지만, 오류가 발생했을 때 복잡한 시스템의 상호 연 한다. 여기서, 피처 목록상의 각 항목이 모델 아티팩트(혹은 ‘아티 하다. 동 체계를 진단하는 일 역시 더욱 난해해지고 있다. 팩트’)가 되며, 이를 다양한 방법으로 툴에서 활용할 수 있다. 첫 째로, PREEvision은 리치 텍스트 에디터를 제공하기 때문에 피처 그런 후에, 그림 5에 표현한 예처럼, ‘vehicleSpeedLogic’ 블록의 목록상의 아티팩트를 그림 2에서 보는 것처럼 텍스트 형식 또는 내용에 대해 더욱 상세한 모델을 생성할 수 있다. 즉, 추상적인 레 일반적으로 차량의 복잡한 시스템으로 인해 발생할 수 있는 문제 포함되어 있다. 따라서, 각각의 model-variant 피처 목록이 하나 다이어그램, 사진, 스캔된 컨셉 스케치로 표현할 수 있다. 벨의 블록은 다이어그램 상의 피처를 구현하기 위한 구체적인 세 들을 해결하는 데에는 지식 기반의 서비스 센터 시스템이 가장 의 세트를 이룬다고 본다. 부사항들을 축약하여 표현한 것으로, 이 블록을 이용하여 자동차 적절하다고 여겨진다. 하지만 신형 모델이 출시된 직후에는 해당 모델에 대해 축적된 정보가 부족하기 때문에 지식 기반의 서비스 시스템 아키텍처 설계자의 역할은 모든 개별 model-variant 세트 센터 시스템이 취약하다. 또한, 이 시기에는 테스트 및 검증 단계 의 상위 세트를 지원하면서도, 각각의 개별 피처 목록의 독립성 에서 간과했던 복잡한 이슈들을 해결하기 위해 심도 있는 지식이 을 보장할 수 있는 종합적인 아키텍처를 개발하는 것이다. 100% 요구된다. 벡터는 이러한 중요한 시기에 필요한 추가적인 정보를 아키텍처의 세트를 모두 포함하는 상위세트가 ‘150% 아키텍처’ 지원하는 방법을 첨단 엔지니어링 데이터의 재사용을 통해 엔지 에 해당하며, ‘100% 아키텍처’는 각각의 개별적인 model-variant 니어와 기술자들에게 제시하고 있다. 에 해당한다. (그림 1 참조).
첨단 엔지니어링 데이터 통상적으로, 150% 아키텍처만을 단독으로 구현하는 것은 물리 신형 자동차를 개발하는 초기 단계에서, 공통 플랫폼의 variant로 적으로 불가능하다. 이는 좌측과 우측 모두에 핸들을 갖추고 있 또는 독립형 프로젝트로 사용될 아키텍처를 규정하는데 이때, 대 는 휘발유-디젤-하이브리드 쿠페-컨버터블-웨건형 차량을 개발 량의 데이터가 생성된다. 아키텍처 설계 프로세스는 플랫폼에서 하려고 시도하는 것과 다름없기 때문이다. 제공되는 피처 목록(Feature list)과 함께 시작된다. 물론, 피처 목록 상의 모든 기능 조합들을 구현할 수는 없다. 따 일반적으로 피처 목록은 차량 모델 또는 variant 별로 분류된다. 라서 아키텍처 개발의 핵심 단계는 150% 아키텍처 상의 개별 항 또한, 피처 목록은 시장 및 기업, 그리고 법적 요구사항을 충족시 목 간의 종속성과 배타성을 명확히 파악하는 것이다. 150% 아키 그림 2: 피처 목록 아티팩트에 대한 리치 키기 위해 요구사항 리스트를 수반하는데, 이 리스트에는 각 모 텍처 모델링은 이러한 종속성과 배타성 파악을 용이하게 하며, ‘ 텍스트의 정의 델의 variant 제공 방법을 한정 및 개선, 그리고 규정하는 내용이 피처 모델’ 생성을 가능케 한다.
2/18 2/19 그림 5: 차량 속도 계산에 대한 상세 논리 모델링
그림 3: 요구사항에 따른 피처 목록 아티팩트의 구체화 하기 위해 생성될 수 있다. (개별 전선과 연결 핀까지 세부적으로 이 시점에서, 설계모델은 아티팩트 간의 포괄성이나 배타성과 같 묘사하는 상세 모델링 가능; 단, 본 자료에서는 다루지 않음). 이 은 관계를 명시한 제약사항이 이미 충분히 갖추어져 있다. (예. “ 러한 하드웨어는 센서, ECU, 퓨즈 및 릴레이 박스, 액추에이터를 제논 헤드램프와 텅스텐 필라멘트 헤드램프는 상호 배타적이 포함할 수 있다. 그뿐만 아니라, 소프트웨어 블록 아티팩트와 하 다”) 또한, 각각 요구되는 Variant 모델의 내용은 피처 목록 아티 의 다양한 하위 시스템에 의해 구현될 수 있는 논리들을 체계적 세 로직들이 자동으로 피처 목록 아티팩트에 연결된다. (Activity 드웨어 블록 아티팩트 간의 맵핑이 가능하며, 다이어그램의 형식 팩트에 관하여 구체적으로 명시 된다. 그 후에 PREEvision의 자동 으로 설명할 수 있다. Chain은 Control Sequence 개념과 유사함). 따라서 150% 피처 으로 소프트웨어가 하드웨어에 맵핑되어있는 것을 보여줄 수 있 리졸버 매커니즘은 특정 100% 아키텍처의 실제 내용을 파악하 목록상의 모든 아티팩트를 구현하는 데 필요한 논리 블록의 모델 다. (그림 6 참조) 기 위해 모델 내의 맵핑을 추적함으로써, 피처 목록 내의 충돌 사 따라서 PREEvision상에서 보다 간편한 설계를 하기 위해 다이어 링이 150% ‘논리 아키텍처’를 형성한다. 항을 파악할 수 있다. 그램을 사용하고 있지만, 이 다이어그램은 논리 모델링의 단편만 아티팩트 간에 전송될 ‘데이터 요소’에 적용되는 데이터의 유형 보여주기 때문에, 실제로는 전반적인 이해를 위해 의도적으로 일 또한, Activity Chain을 이용하여 어떤 영역에 공통성과 배타성이 을 보여주기 위해, 논리 아키텍처 및 소프트웨어 아키텍처에 모 통신 구조 정의하기 부 사실을 축약하고 있다는 점을 유의해야 한다. 존재하는지 판단할 수 있고, 데이터 소스와 시스템 출력을 재사 두 주석을 달 수 있다. 이때, 주석은 AUTOSAR에 대한 요구사항 일단 한 모델이 현재 언급된 수준까지 개발되고 피처 목록상의 용하는 것이 가능하다. 시스템 구현을 위해 사용될 소프트웨어와 에 따라 제시되어야 한다. 그리고 통신구조(하기 참조)를 포함한 모든 충돌 사항이 제거되고 나면, 논리 아키텍처, 소프트웨어 아 그림 5의 블록에 표시된 ‘Type’ 레이블들을 통해 알 수 있듯이, 하드웨어 상에서 논리 아키텍처는 아티팩트의 대표적인 프로토 아키텍처의 모델링이 완료되면, 다음 제품 개발 단계를 위해 AU- 키텍처 하드웨어 토폴로지를 결합하여, ‘기능적 아키텍처’로 간 PREEvision은 사용자 정의 파트 라이브러리(User-defined part 타입으로 간주될지도 모른다. 그러나 잘 설계된 논리 아키텍처는 TOSAR System Description 파일을 내보낼 수 있다. 주한다. 논리 아키텍처 또는 소프트웨어 아키텍처는 데이터 흐름 library)의 사용을 지원한다. 모델링의 효율성을 개선하기 위해 여러 프로젝트를 거듭하더라도 안정적으로 원래의 상태를 유지 프로토타입 아티팩트를 생성하여 라이브러리에 수시로 포함할 할 수 있지만, 기술 혁신으로 인해 소프트웨어 및 하드웨어의 상 수 있으며, 별도의 ‘블록 편집기’가 필요하지 않다. 태는 변형될 가능성이 많다는 점을 주의해야 한다.
툴에서 아티팩트 사이에 맵핑을 생성함으로써, 피처 목록의 특정 소프트웨어와 하드웨어에서 논리 아키텍처 구현을 위한 모델링 부분이 논리 아티팩트와 연결된다. 이러한 맵핑은 양방향으로 논리 아키텍처의 구성과 마찬가지로, 소프트웨어 아티팩트로서 이루어지며, 자동 조회 시 설계 모델을 양방향으로 추적할 수 있 추상적인 논리를 구현하는 데 필요한 소프트웨어의 기능 간의 관 다. 복잡한 구현 과정에서 논리 블록 아티팩트의 수에 따라 많은 계를 모델링 할 수 있다. 또한, 논리 블록과 소프트웨어 블록 간 맵핑을 생성해야 하는데, 이러한 맵핑 프로세스를 간편하게 하기 의 관계를 보여주기 위해 이들이 맵핑되는데, 이러한 방식으로 위해 PREEvision은 ‘Activity Chain’이라는 개념을 제시하고 있다. 150% ‘소프트웨어 아키텍처’가 생성된다. Activity Chain으로 피처 목록상의 특정 아티팩트와 연관된 논리 블록들을 그룹화할 수 있다. 이를 통해, 피처 목록 아티팩트와 다음으로, 150% ‘하드웨어 토폴로지’는 기존의 배선 혹은 통신 Activity Chain간에 맵핑이 생성되어, Activity Chain에 포함된 상 버스를 이용하여 차량에 장착될 하드웨어 간의 상관관계를 묘사
그림 4: 추상적인 논리 모델링 그림 6: 소프트웨어 맵핑을 보여주는 하드웨어 토폴로지 모델
2/20 2/21 을 규정하며, 하드웨어 토폴로지는 데이터 흐름을 위한 경로를 에서 신호가 통과해야 하는 버스 유형에 따라 PDU가 프레임 및 처에 일반적(기능적) 통신 요구사항과 관련된 주석을 다는 것과 에, 하나의 진단 마스터(ECU 또는 프로세서)가 단일 또는 다수의 정의한다. 프레임 스케줄에 할당된다. 이를 통해, 해당 아키텍처를 위한 ‘통 동일한 방법으로, 진단 요구사항과 관련된 주석을 기능적 아키텍 ECU, (스마트) 센서, 혹은 (스마트) 액추에이터들에 대한 진단 신 구조’가 구현된다. 이러한 통신 구조가 구축되고 나면, AUTO- 처에 달 수 있다. 정보를 종합할 수 있다. DTC 외에도 진단 데이터 식별자, 진단 측 수동 프로세스로 진행할 경우, 주어진 100% 아키텍처 상에서 정 SAR 기반의 내보내기 기능과 더불어, PREEvision에서는 파일 유 정 및 진단 제어에 대한 요구사항을 포함한 모델의 구조에서 확한 데이터 흐름을 위해 경로를 설정하는 것은 매우 난해한 작 형에 따른 기존의 프로세스와의 호환을 위해 LDF, DBC 및 FIBEX 진단 아키텍처를 위한 단계 어떻게 진단 컨텐츠가 표시되는지 설명하는 예가 그림 9에 설명 업이다. PREEvision에서는 시그널 경로 매커니즘을 제공하는데, 파일들에 대해 내보내기 기능 역시 제공한다. 우선, 진단 요구사항을 충족시키기 위하여 ‘오작동’이라는 아티 되어있다. 이를 통하여, 최적의 경로를 파악하기 위해 정의된 데이터 흐름 팩트를 생성하여, 이것을 요구사항에 따라, 또는 세부 분석 연구 을 자동으로 분석할 수 있다. 이러한 자동 시그널 경로 설정 알고 서비스 관련 정보 추가하기 의 결과물로서, 기능적 아키텍처의 해당 구성요소에 맵핑할 수 상기 언급된 모델 구조를 생성 시, 하드웨어 토폴로지를 통해 기 리즘은 하드웨어 아티팩트를 벗어날 필요 없는 기능적 아키텍처 속도 신호 경로 설정을 보여주는 하드웨어 토폴로지 있다. 아래 예제에서는, 센서 및 액추에이터에 관하여 규정된 능적 아키텍처에 양방향으로 맵핑된 진단 아키텍처를 생성할 수 내의 시그널들은 제거하여 시그널 경로를 최적화한다. 예를 들 요구사항에 따라, 다음과 같은 오작동 항목들이 존재하고, 이를 있다. 이러한 모델링의 주요 목적은 하드웨어 토폴로지에 반영된 어, 시그널 소스와 시그널 리시버를 기능적 아키텍처 내의 동일 서비스 관련 정보 추가하기 진단해야 한다고 가정하였다. (추가 가정: 논리적 기능들만이 마스터/슬레이브의 상호관계를 고려하여 ECU 레벨의 진단사양 한 ECU에 맵핑하는 경우, 별도의 시그널을 생성을 할 필요가 없 시스템 오류를 지속시키며, 이러한 오류들은 양산 이전에 개발을 더욱 간편하게 하기 위해서이다. 그래서 PREEvision은 특 다. 기능적 아키텍처와 통신 구조는 제품 개발 프로세스상에서 필요 제거됨): 정 ECU에 할당된 진단 요구사항을 내보내기 위한 인터페이스를 한 추가적인 활동의 기초가 된다. 동시에, 차량 개발이 완료되고 > 센서에서는 다음과 같은 두 가지 유형의 오작동이 일어난다: 제공하는데, 벡터의 진단 툴인 CANdelaStudio 에서 이 요구사항 시그널 경로를 설정한 이후, 간편하게 클릭을 통해, 어떤 신호의 양산 단계에 접어들면 서비스센터의 역할이 중요해지기 시작하 – 전기적 오작동 – 예. 단선 을 구체화할 수 있다. 경로든 아키텍처 상에서 시각화할 수 있다. 이때, 해당 데이터 요 는데, 제품 개발 단계에서뿐만 아니라 서비스센터에서도 기능적 – 신호/성능의 오작동 – 예. 범위 초과 소의 시그널 소스(노란색으로 표시)와 시그널 리시버(연한 갈색 아키텍처 및 통신구조를 활용할 수 있다. 예를 들면, 피처 목록상 > 액추에이터에서는 다음과 같은 한 가지 유형의 오작동이 다음으로, 위에서 언급된 오작동 아티팩트를 활용하여 논리 아키 으로 표시)의 맵핑 위치는 맵핑 경로 및 추적한 게이트웨이(주황 의 특정 아티팩트의 구현을 나타낸 Activity Chain의 일부 논리 일어난다: 텍처와 진단 아키텍처를 양방향으로 연계할 수 있다. (그림 10 참 색으로 표시)와 함께 표시된다. (그림7 참조) 블록들을 PREEvision의 자동 조회 기능을 통해 추적하여 조회할 – 전기적 오작동 – 예. 단선 조) 또한, 기능 안전 컨셉 분석 시에도 오작동 아티팩트를 활용할 수 있다. 그러므로 현장 지원 엔지니어가 아직 지식 베이스가 축 수 있는데, 이러한 경우에 기능 안전 컨셉, 기능적 아키텍처 및 진 기능적 아키텍처에서 데이터 흐름 경로 설정이 완료되면, PREE- 적되지 않은 복잡한 신규 시스템상의 오류를 해결해야 한다면, 이후, 오작동 아티팩트와 기능적 아키텍처 상의 아티팩트를 연결 단 아키텍처 설계가 이미 맵핑된 것으로 간주한다. vision에서는 통합된 네트워크 설계 환경을 제공한다. 이 환경에 이러한 방식의 조회를 통해 확보한 데이터를 ‘기초’ 데이터로 활 하기 위하여 오작동 맵핑이 생성될 것이다. (그림 8 참조) 서는 신호가 프로토콜 데이터 단위(‘PDU’)에 할당 되며, 아키텍처 용할 수 있다. 이와 더불어, 논리 아키텍처와 소프트웨어 아키텍 서비스 센터에서 첨단 기술 정보 활용하기 B기능적 아키텍처 상에서 논리 아키텍처, 소프트웨어 아키텍처 진단 아키텍처에서 생성된 각각의 DTC 요구사항이 차량 양산용 그리고 하드웨어 토폴로지 사이를 맵핑을 함으로써, 이 두 가지 소프트웨어에서 구현되었다고 가정했을 때, 앞에서 언급했던 것 유형의 오작동 항목들을 검출하기 위해 어떤 진단 프로세서를 실 처럼 Activity Chain에 포함된 기능과 관련한 입력 데이터를 추적 행할지 결정할 수 있다. 그 후에, 아키텍처 상에서 해당하는Diag- 하기 위하여 자동 혹은 수동 조회를 통해 PREEvision 설계 모델 nostic Trouble Code (‘DTC’) 요구사항을 생성할 수 있다. PREEvi- 내의 링크와 맵핑을 사용할 수 있다. 그러나 논리 블록 상에서도 sion은 진단 마스터/슬레이브 관계에 대한 컨셉을 지원하기 때문
그림 7: 차량 속도 신호 경로 설정을 보여주는 하드웨어 토폴로지 그림 8: 논리 센서에 맵핑된 일반적인 오작동의 예
2/22 2/23 요약 상호 연계된 매우 복잡한 시스템의 도입으로 인해 고객에게 차별 화된 기능을 제공함과 동시에 더욱 엄격해진 차량 관련 안전 요 구사항을 준수할 수 있게 되었다. 하지만 최첨단 시스템의 복잡 성과 시스템간의 상호 작용으로 인해 오류 발생 시 진단 서비스 의 어려움도 동시에 가중되었다.
이를 해결하기 위하여, 벡터의PREEvision과 같은 최첨단 시스템 설계 툴이 개발되으며, 이러한 툴에서 개발된 설계 모델은 차량 용 원본 설계 데이터를 바탕으로한 새로운 정보를 효과적으로 서 비스센터에 제공한다.
진단 모델링 아티팩트를 PREEvision에 도입함으로써, 특정 기능 에 필요한 논리에 대한 입력 데이터를 확보할 수 있게 되었을 뿐 아니라, 해당 기능에 악영향을 미치는 DTC들도 단일 정보 출처를 통해 손쉽게 파악할 수 있게 되면서, 설계 모델에서 추출 가능한 정보의 유용성이 대폭 개선되었다.
Iain Cunningham (BEng(hons), MSc) 2013년부터 Vector GB Ltd에 근무 중이며, 프로세스 툴 및 진단 툴 분 야의 전문가로 사업개발 업무를 담당하고 있다..
그림 9: 진단 아티팩트를 나타낸 모델 구조
기능 오류를 유발할 수 있는 시스템과 관련된 DTC들을 파악할 수 있는데, 이는 서비스센터의 기술자가 복잡하고 생소한 시스템상 에서 오류를 진단할 때 매우 중요한 정보로 활용된다.
물론, 자동차 시스템과 기능의 매우 복잡한 연결 구조로 인해 차 량 전기 시스템상의 특정 오류가 다수의 오작동을 유발할 수 있 다. 또한, PREEvision 설계 모델의 링크와 맵핑이 양방향으로 연 결되어 있기 때문에, 반대의 사례도 고려해 볼 수 있다. 만약 특 정 자동차 모델에서 DTC가 검출되면, 설계 모델 상에서 조회를 통해 이 해당 DTC에 의해 악영향을 받는 모든 피처 목록 아티팩 트들을 확인할 수 있다. 이는 서비스센터에서 매우 유용한 정보 로 활용될 수 있다.
그림 10: 오작동을 통한 논리 아키텍처와 진단 아키텍처의 맵핑
2/24 Development Feature Testing & Simulation
독일의 한 사업 현장인 뵈르트 암 라인 (Worth·· am Rhein)에는 유럽 최대의 상용 트럭 제조업체 중 하나인 다임러가 위치해 있다. 이곳에서는 이미 잘 알려진 메르세데 스 벤츠의 아테고(Mercedes-Benz Atego), 악소(Axor) 및 악트로스(Actros) 트럭이 생 산되는 것 외에도 유니모그, 에코닉 (Econic), 제트로스(Zetros)와 같은 특수용 도 차량이 개발, 제조되고 있다.
유니모그의 오프로드 기동성 유니모그 U3000/4000/U5000 제품 라 인은 포털 액슬(Portal Axle), 코일 스프링, 【그림 1】 전 지형 기동성은 유니모그의 가장 중요한 특징이다. 그리고 수동으로 선택 가능한 4륜구동과 1.2 m의 물웅덩이에서도 기동할 수 있게 하는 스러스트-튜브(Thrust-tube) 기술 등 고성 능 기능을 통해 뛰어난 오프로드 기동성을 실현하고 있다(그림 1). 또한 110 kW (150PS)에서 160 kW(218PS)까지의 전력 출 력 범위를 지닌 저 배출가스 디젤 엔진도 함 다임러 유니모그의 타이어 압력 제어 께 사용된다. 이와 함께 메르세데스 벤츠는 “타이어 제어”옵션이라는 특별한 기능을 프 로그램 내에서 제공한다. 이는 운전자가 운 시스템을 위한 하드웨어 시뮬레이션 전대에서 바로 타이어 압력을 조절할 수 있 도록 타이어에 공기를 주입하거나 빼기 위 【그림 2】 주행 중 타이어 압력 제어 (현장 훼손 방지의 예) 모델 상에서 ECU 테스트에 의한 시간 단축 한 전자공기압 시스템(electro-pneumatic system)이다. 포장도로에서는 롤링 저항과 연료 소모량 다임러 AG(Daimler AG)의 개발자들은 새로운 유형의 테스트 시스템을 사용해 오프로드 차량인 유니모그(Unimog)에 적용할 을 줄이기 위해 타이어 압력을 높이지만, 오 이 높아져 타이어의 자체 정화 성능이 향상 게 있어서 조작성이 향상된다는 것을 의미 차세대 타이어 압력 제어 시스템을 위한 실제적인 테스트를 실시했다. 이 테스트 시스템에서는 ECU 환경의 모든 센서와 액추 프로드 주행에서는 다른 특성이 우선시 된 될수있다. 한다. 자동 모드 시에는 운전자가 토양 에이터의 시뮬레이션과 환경 내에서 하드웨어 및 배선에서 발생하는 고장 상황의 시뮬레이션까지 포함한 포괄적인 HIL 테스트 다. 예를 들면, 축축하게 젖어 있는 벌판을 (terrain) 유형을 선택하기만 하면 시스템 를 수행할 수 있다. 주행하는 경우에는 타이어 압력을 낮추면 타이어 압력 제어 시스템을 모델 이 자동으로 4채널 공기압 시스템을 통해 타이어 접촉 압력도 낮아져 작업 현장이 크 기반으로 개발 모든 타이어의 적절한 압력을 자동적으로 게 훼손되지 않는다(그림 2). 가용 견인력의 유니모그 시리즈에 성공적으로 적용된 선택한다. 경우 토양의 조성과 사용된 타이어 압력 간 전자 개념은 이제 성능 및 조작성의 요건을 마리오 워멜 (Mario Wirmel)은 뵈르트에 소재한 메르세데스 벤츠 트럭 사업부에서 생산 계획 에 직접적인 관계가 있다. 오프로드에서 타 충족시키기 위해 선행 개발 단계를 거치는 PC 기반의 MIL 테스트 업무를 담당했으며, 2003년 이후로는 메르세데스 벤츠 특수 차량 제품 영역의 전기/전자 개발 이어 압력을 줄이면 가용 견인력을 간단히 중이다. 차세대 타이어 압력 제어 시스템의 새로운 타이어 압력 제어 시스템의 개발 부문에서 근무하고 있다. 배가시킬 수 있는데, 때로는 이것이 작업의 선행 개발에는 새로운 고성능 하드웨어 플 과정에서는 우선 타이어가 포함된 새로운 카트자 하만 (Katja Hahmann)은 1997년 Vector에 입사하여 현재는 네트워크 및 분산 시스템 성패를 결정짓는 결정적인 요소가 된다. 또 랫폼과 그 위에 탑재되는 모델 기반의 개발 공기압 시스템 모델(“플랜트 모델”)을 작성 제품 라인의 CANoe 애플리케이션 개발 부문 그룹 매니저를 맡고 있다. 마리오 워멜 카트자 하만 한 타이어 압력이 낮으면 타이어의 변형성 애플리케이션이 포함된다. 이는 운전자에 하고, 이것을 측정된 데이터 및 설계 문서를
86 www.autoelectronics.co.kr 2010 OCT·NOV 87
3/0 3/1 Development Feature Testing & Simulation
토대로 검증한다. 이어서 애플리케이션 모 는 네트워크 시뮬레이션 및 테스트 자동화 델의 초기 구현이 이루어진다. 다임러는 를 처리한다. 개별 ECU를 테스트하기 위한 ITK 엔지니어링(ITK Engineering)이라는 이 컴포넌트 HIL 테스트 벤치(그림 4)는후 회사를 고용해 MATLAB/Simulink 모델 작 일 실제로 차량 테스트를 할 때에도 다시 사 성을 의뢰했다. 이 모델은 실제 시스템의 동 용된다. 적인 동작을 사실적으로 시뮬레이션 한다. 이 새로운 테스트 시스템의 주목적은 잘 VT System을 기반으로 하 각 타이어는 포털 액슬 중앙의 공기 채널을 는 컴포넌트 테스트 벤치는 못된 배선, 결함이 있는 센서 또는 액추에이 자동차 업계의 요구사항에 통해서 공기압 제어 시스템과 항상 상호 연 맞게 제작되어, 소규모 벤치톱 터 등에 기인하는 오류 상황을 시뮬레이션 결되어 있어 압력센서가 개별 타이어의 압 환경에서 연구실의 대규모 하는 것이다. 이러한 컴포넌트는 값을 전혀 HIL 시스템에 이르기까지 폭 력을 계속적으로 수집한다. 또한 시스템의 넓게 사용될 수 있도록 모듈 제공하지 않거나 잘못된 값을 제공하거나 식으로 구성된 강력한 테스 기준용 센서가 장착되어 데이터를 수집하는 트 시스템이다. 이를 통해 규격에서 벗어난 내부 저항 및 전류 소모량 다른 센서들을 자동으로 검증한다. 모델에 ECU에 연결된 센서 및 액추 을 발생시킬 수 있다. 예를 들면, 압력 센서 에이터의 시뮬레이션은 물론 는 순간 압력, 컴프레서 출력, 채널의 횡단면 단락, 과전압 및 부족 전압 의 경우 측정 범위를 벗어난 전압이 생성되 등의 잠재적인 오류 상황에 적 등도 포함되어 있다. 타이어 압력을 높이 대한 시뮬레이션도 구현할 면 전자 부하를 통해 밸브를 시뮬레이션하 거나 낮추면 유효 시간 상수를 포함하는 관 수 있다. 고 정상적인 값을 벗어난 소비 전력값을 파 계들이 모델 내에서 정밀하게 계산된다. 결 【그림 3】 컴포넌트 HIL 테스트 벤치의 레이아웃 【그림 4】 모듈형 컴포넌트 HIL 시스템인 VT System 라미터화 할 수 있다. 이러한 예측 불가능한 과적으로 이 개발 단계에서 PC 기반의 상황에 대한 ECU의 대응, 즉 ECU가 오류 MIL(Model-in-the-Loop) 테스트가 가능 Prototyping Platform)이 있어야만 이러한 구성된 강력한 테스트 시스템이다. 이를 통 델을 사용하는 또 다른 이점이 있는데, 그것 접 이루어지거나, CANoe의 환경 및 시스템 메모리에 올바른 항목을 생성하는지 여부에 하다. 테스트를 수행할 수 있었다. 하지만 CANoe 해 ECU에 연결된 센서 및 액추에이터의 시 은 원하는 상태를“버튼 한 번만 눌러”바로 변수를 통해 이루어진다. ECU는 표준 사양 대한 정보는 유니모그 개발자들이 시스템을 와 통합된 애플리케이션 모델을 사용함으로 뮬레이션은 물론 단락, 과전압 및 부족 전압 얻을 수 있다는 것이다. 플랜트 모델(plant 으로 관련 컴포넌트가 실제로 연결되어 있 추가로 개발하는 과정에서 많은 관심을 두 Simulink 모델을 이용한 SIL 테스트 써 더 이상 특별한 하드웨어를 설치하지 않 등의 잠재적인 오류 상황에 대한 시뮬레이션 model)에서는 타이어 및 압력 저장소 내의 는지, 센서 데이터 또는 종단 저항이 적절한 고 있는 부분이다. 이후의 개발 단계에서도 모델 기반의 접근 고도 작동 및 표시 개념을 차량 내에서 테스 도 구현할 수 있다. 이 시스템은 부하 시뮬레 압력과 특히 관련이 있다. 예를 들어, 실제 지를 확인하기 위해 해당 입력 및 출력을 검 법이 적용된다. 벡터의 시뮬레이션 및 테스트 트할 수 있다. CANoe는 차량과의 CAN 통 이션, 측정, 그리고 자극(stimulation) 입력 로 차량 테스트에서 바람이 빠진 4개의 타 사한다. 따라서 의미 있는 테스트를 위해서 전망 툴인 CANoe를 이용, 모델 통합을 통해 모델 신을 담당한다. 센서/액추에이터 모듈(예. 을 위한 각종 VT 모듈을 사용해서 모듈식으 이어를 차량 에어 컴프레서를 사용해 지정 는 실제 센서 및 액추에이터가 있어야 하고, 다임러에서 타이어 압력 시스템을 테스트 동작을 버스 통신과 함께 테스트한다. 현 수준의 ECU)은 CAN을 통해 차량 내 I/O 로 구성된다. 된 작동 압력까지 공기를 채우려면 20분 정 그렇지 않을 경우에는 ECU의 환경이 최대 할 때 실제 ECU이든 시뮬레이션된 ECU이 MATLAB/Simulink용 CANoe 블록세트를 기능을 실현한다. 이미 생성된 테스트 시퀀 VT System을 도입하기로 결정하는 과정 도가 소요되지만, 연구실 테스트 시스템에 한 실제와 가깝게 시뮬레이션 되어야 한다. 든 이제는 더 이상 차이가 발생하지 않는다. 사용하여 모델 인터페이스를 버스 신호, 시스 스는 여기에도 재사용할 수 있다. 최초의 에서 중요하게 작용한 또 다른 요인은 다임 서는 모델의 파라미터를 직접 지정하고 값 그러나 실제 컴포넌트로 합리적인 테스트 또한 개발자들은 실제 테스트 차량의 유무 템 변수 또는 환경 변수에 직접 연결한다. SIL(Software-in-the-Loop) 테스트는 요 러에서 수년 간 사용해온 CANoe 소프트웨 을 압력 곡선과 같이 그래픽으로 표시할 수 자동화를 수행하려면 많은 비용과 노력이 로 인한 제약에서 벗어나 자유를 누리고 있 CANoe 시뮬레이션 환경에 로드되는 구사항이 아직 모두 기술되지 않은 초기 단 어 시스템과의 통합성이 좋다는 것이다. 있기 때문에 이러한 과정을 즉시 수행할 수 소요되기 때문에(예. 로봇으로 작동되는 제 다. 그 결과 설계 단계에서 기능 테스트에 이 Windows� DLL은 Simulink� Real- 계에서 실행된다. 특히 CANoe에 이 모듈들이 직접 통합되기 있다. 어 상황), 환경에 대한 시뮬레이션을 수행하 르기까지 테스트 시스템을 보편적으로 사용 Time Workshop�을 통해 생성한다. 때문에 나중에 신규 프로젝트를 위해 시스 는 것이 일반적으로 바람직하다. VT 할 수 있게 되었는데, 이는 ECU에 대한 테 CANoe의 상호작용 계층(Interaction 컴포넌트 HIL 테스트 벤치 템을 확장하거나 수정하기가 편리하다. 이 HIL 테스트 벤치 컴포넌트로 활용 System은 이제 환경 하드웨어의 시뮬레이 스트 결과를 직접 비교해야 하는 경우에 요 Layer)에서는 데이터베이스 내에 정의된 전 개발자들이 항상 테스트 차량을 이용할 수 테스트 시스템은 실시간 기능의 이더넷 프 되는 VT System 션을 담당한다. 스티뮬레이션 모듈인 구되는 부분이다. 송 동작에 따라 메시지를 전송한다. 마지막 있다고는 할 수 없기 때문에, 다임러는 벡터 로토콜인 EtherCAT�을 활용하여 이더넷 플랜트 모델은 CANoe 블록세트를 통해 VT2004는 실제 차량에서 타이어 압력 센서 타이어 압력 제어 시스템에서 거둔 VT 으로 CANoe의 Test Feature Set 기능을 의 테스트 하드웨어인 VT System을 기반으 포트를 통해 테스트 컴퓨터에 연결된다. CANoe의 시뮬레이션 기능에 통합되는데, 가 연결되어 있는 ECU에 관련 전압 값을 System의 성공으로 자극받은 다임러 개발자 통해 테스트 시퀀스를 생성하고 자동 실행 로 하는 컴포넌트 테스트 벤치를 도입하기로 CANoe는 테스트 자동화 툴로서 VT 여기에서 실제 ECU가 테스트된다. 모든 입력한다. 타이어에 공기를 주입하거나 빼 들은 이미 다음 프로젝트를 계획하고 있다. 한다. 결정했다. 이 시스템은 자동차 업계의 요구 System의 모든 파라미터에 대한 액세스를 ECU의 입력 및 출력은 VT System의 관련 기 위한 스위치도 시뮬레이션 할 수 있다. 이 프로젝트에는 정수압 견인(hydrostatic 그 다음에 차량에서 초기 테스트가 이루 사항에 맞게 제작되어, 소규모 벤치톱 환경 허용한다(그림 3). 버스 신호 또는 하드웨어 채널에 연결된다. 반면, 부하 및 측정 모듈인 VT1004를 통해 traction) 구동의 선행 개발이 포함되는데, 어진다. 이전에는 프로토타입 ECU 또는 이 에서 연구실의 대규모 HIL 시스템에 이르기 실제 ECU에 대한 HIL 테스트를 위해 플 CANoe의 시뮬레이션 기능과 Simulink 모 서는 전자 부하로 밸브를 시뮬레이션하거나 이 경우 시스템은 16채널 디지털 모듈과 전원 른바 고속 프로토타이핑 플랫폼(Rapid 까지 폭넓게 사용될 수 있도록 모듈식으로 랜트 모델이 CANoe에 통합된다. 여기에 모 델 간의 통신은 신호 인터페이스를 거쳐 직 ECU 출력의 값을 측정한다. 또한 CANoe 모듈을 통해 확장될 예정이다.
88 www.autoelectronics.co.kr 2010 OCT·NOV 89
3/2 3/3 Development Feature ECU Test
아키텍처 ၟྜ ೈ៰-!ಶᢎ᳤᠂ᢎྜ ᢾᖥ ᖇᖑឥᕷ ኰ 311:ᐜ᱅ ᙋၠŰQbobnfsbűྜᙂ ᙋቸ ፭ᐇ᷌ᜥ ᷅ླ/!-!ᙏᤦᇢ ᗀᙍၟྜ ᴭ᭥ ᤦᤶ᪸ ឮᓳᓿ ᫆ᇢ 5၍᜴ ಯᐆླ ᢜᥖ ኰᙋቸ ᐆ໗ྜ ಯᢎླ/!፭ኻ HU)Hsbo!Uvsjtnp*!ಕༀ ᤤᱣ ᙂᴭ᭥ ឥ ླቷ ኰᙋྜ ᜵ᤦၟಧໆ ᥟᐇၟྜ ᢑ ႈᢜᢐឥ ᱣ᷉᷅ ᜭᓶ ᨵᇂᢎླ/!ឧ ៍ᖑ ᢎ 2;2ᇢ ࿅᷅ ᙍᖝ᷃ಶ ᅉ៰᳹ ᷌ᜥ ᷅ 4/7ኀ᱅ 7ංᱣ ឧឥᕷ 5/9ኀ᱅ 9ංᱣ ླ/!ᢎቸ ᡩ᷌ ಶᢎ᳤᠂ᢎឥྜ ಄ ኰᙋቸ ᱅ᐆ ឧឥ ᢎትංඎ ླᜭ᷃ኹ-!ᇖ ᎌ ᅉ៰᳹᷃ං ᡩ᷅ ᅉ៰᳹ ൴᭜ᢎ ᕽᤤၟኹ- ᡩྜ 331!lXឥᕷ 479!lXឥ ᢎቷླ/!ᤦ ᢎᇃ᷅ ൴᭜ឥྜ ᖜᙂ ፧ ᓿ࿅ ᳤ᰡᢉ
ၟྜ ංྣឥྜ ᳥ᤤ ዂ၀ ᎆᢾ ፧ ៍ᖑឥ ႓ ᤤᐆ៑ ွᢎ᱅ ᐇᓳ ൴᭜ᢎ ᴭ᷈ၠླ/ 칼-피터 스프링 )Lbsm.Qfufs!Tqsjoh* ᅉ ᶢᰰᢕ 5ሏ൘ၗ ᥖᷔ-!ၸ ᰤᇃ᭛ ᏽᖝ ᨵᇂ ໗ ಶᢎ᳤᠂ᢎ FDVቸ ᱣ᷉᷃ྜ ᢝ ᇮ᳨ኇಷ)Sfvumjohfo*ឥ ᡩ᭛᷅ ᷉ ංᗄ)Qpmzufdiojdbm*!࿅᷄ឥᕷ ᓶ ᢜ ං-! ᢩᷪ ಕ፯ ᥟᢐ ᷃ᢎᐸኀၽ ᥖᷔ ႆᢎ ᢜၗᨵ ᤦᤶ᪸ឥᕷ ᷔ᷅ླ/! ᳤ ၗṟ ᷄ ᐜᷓླ/! 2:::ឥ ᴭት ᴭ᷈ၡ ᗀ ᢘླ/ ᰡ៑ FDVಃ ᷈ฐ Ṣ᷃ಶ ᢝၗ᷆ ᗀ ᢘ ᘮឥ ᢖᓳŰ᳤ᰯ-!ྶ ፧ ಶᢎ᳤᠂ ᢎűᐜᕷឥᕷ FDV!ᥟ ಶᢎ᳤᠂ᢎ ឹ Qbobnfsbᢉ ᢾᢜᢧ᭛ ᜌᰨ᱐ྜ 7ಕ ၍ᇣ ᷃ᇕኻ ಶᢎ᳤᠂ᢎឥ ᢝၗ ឥᇃಃ ፯ ឮᢉ ኀ࿏ᇢᕷ Ṣၗ᷃ ᢘླ/ ᢉ DBO! ᳤ᰡឥ ᐞᓶၠ 41ಕ ᢎᓿᢉ ᔉ᷃ ᜐᜌᜥ ᷅ླ/!႓ᅉᕷ ᅉ៰᳹ ၗᢝ ಭ DBO! FDVቸ ං፭ᇢ ᷃ኹ-! ᫍ 36ಕᢉ ᙋ ླᜭ᷅ ᥖᷔ ᓿṤឥᕷ ᗀኋ ᱏᙂ᳤ MJO! ᙅᇍᢎᐸಃ ᢘྜ 23ಕᢉ MJO! ᳤ ቸ ᙏᷔ᷃ ᖆᐜᢽᢐ ᐞᕸ ᗀᷔ᷃ྜ ᢑ ᰡᇢ ᐆ៓ၠླ/! NPTU! ᎆᙂྜ ᢐᴭᱏᢐኧ ᢎ ኗ៰ ᥟ៨᷃ླ/!ൽඎ ᙏᷜᙏ ᱏᙂ᳤ ᳤ ᙋᙂ᱓ ᷅ླ/!ྶ-!ᴣᢉ ᙋᙂ᱓- ឥᕷྜ ᢖᇖ ᙍṕᢉ ᢜ൸ឥ ႓ᅉ ዂၿ ಶᢎ INJ)Ivnbo!Nbdijof!Joufsgbdf*-!ᳺ᳤ ᳤᠂ᢎᢉ ᅉ៰᳹ ൴᭜ ᗂᨵᢽᇢ Ṡᢐ ᇍᢐ-!ᔁᙋ ፧ ၑ ᜎᢾ ᡩ᷅ 7ಕᢉ ᷃ྜ ွ ᥟᤡ ၦᝀኹ-!ᇖ ᎆᙂឥᕷ ួ
DBO!ᎆᙂಃ ࿅ 3ಕᢉ MJO!ᎆᙂ៑ ᷈ฐ ᓿ ೃቸ ᅉ៰᳹ ᜑኀᥲ ࿅ᤶᷓླ/!᷃ 토마스 호만 )Uipnbt!Ipinbo*! ዂၦ ᥟ ಶᢎ᳤᠂ᢎ FDVᇢ ឰೃၠླ(그 ኊ ᴭትᘮឥᕷྜ ᢾ ፧ ᢾ ᐜᤷ-!ླ ᢑኰໆ៰ ࿅᷄)UV! Jmnfobv*ឥ 림 1)/!ಶᢎ᳤᠂ᢎྜ ᨵᇂᢉ ླᜭ᷅ ᳤ ᜭ᷅ ំ၍ ᶵᇢᳺᢑ ಒ ླᜭ᷅ ፀኀᢽ ᕷ ᭾ᶯ᱅ ᷄ ᐜᷓླ/!3118ᐜ ᱅ ᴭትᘮឥᕷ Ű᳤ᰯ-!ྶ ፧ ಶ ᰡቸ ᓿṕ ឰೃ᷃ ᳤ᰡ ᢾ፭ឥ ಫᫀ ᤶ ᷃ឥᕷ၍ ᢎᇃ᷅ ᱏᙂ᳤ቸ ᗀᷔ᷅ླ/ ᢎ᳤᠂ᢎűᐜᕷឥᕷ ಶᢎ᳤᠂ᢎ ಕ፯ ᑊቷ ွᢎ᱅ ṡᢎ ᢎሃ ᗀ ᢘ၍ᇣ ᷅ླ/ ឥ ೞឭ᷃ ᢘླ/ 실험실 테스트의 한계 지능적인 게이트웨이 기능 ᳥ᗀ ᱏᙂ᳤ ᄝྜ IJM!ᙋᙂ᱓ ᱣ᷌ ᙏ 포르쉐, 게이트웨이 ECU 검증 자동화 ᢜၗᨵឥᕷྜ ᳤ᰡ ಅឥ ᤤᐆቸ ᷜᙏឥᕷ ᔉᖄၟྜ ᱏᙂ᳤ ွᢎ᱅ಃ ᱏᙂ ࿅᷅ ᙍᖝ᷃ ྣᢽᇢ ᢾᖥ᷆ ᗀ ᢘ᜴ ᳤ᢉ ංᐉ ංྣ ᷃ྜ ಯᢎ ᓳᙏᢎኊ ᓶ 시험 주행 실시간 분석으로 실험실 테스트 보완 ᜥ ᷃ኹ-!ᢎቸ ᡩ᷌ᕷྜ ᳤ᰡ ᎆᙂᢉ ಄ ፯ᢽᢐ ឥᇃྜ ᙏᤦ ᙂ᳤ᇍᙂ ᙋໆኀោቸ ං ླቷ ࿅ឮᴮ ᇕ᷌ᜥ ᷅ླ/!ᢑ፭ᢽ ᢽ᷃ಧໆ ᄝྜ ዂၿ ᎆᙂ ᙋᙂ᱓ FDV ᇢ ಶᢎ᳤᠂ᢎྜ ᖝ DBO!ᎆᙂᢉ ᗀᙍ ಃ ᓿṕ ᢝ᷆ ჽኊ ၽᇃໆྜ ೈ៰ಃ ኋླ/ ឥ 21!ntኈླ ᥖංᢽᇢ ၍ᨶ᷃ྜ ኰᙋ ᳥ẩ ᎆᙂ ᐜ᷃ಃ ༐ ᳥ᤤ ᢎᏳ᳤ಃ ၗᙋ 카챠 하만 )Lbukb!Ibinboo* ቸ ࿅ឮᴮᢎ ᢝ ᓿ࿅ ᳤ᰡ ᨈᇢ ൷ ឥ ፯ᔉ᷃ྜ ᓿṤឥᕷྜ ᐇᢤ᷅ ឥᇃಃ ໆ ᮇྩ ࿅᷄)UV! Difnoju{*ឥ 포르쉐(Porsche)는 Panamera 모델에서 게이트웨이 ECU를 검증하기 위해 PETRA(Porsche Echtzeit ‘real-time’( ) ኊᰥ ᑊቷ ᖝ၍ᇢ ᅉ៰᳹ ᷆ ᗀ ླ/!႓ᅉ ᰰ໋ ᗀ ᢘླ/ ᕷ ᢾං ᷄ ᐜᷓླ/!2::8 ᘼᱭ TRace Analyser)를 구현하고 있다. PETRA는 테스트 툴인 CANoe를 기반으로 라우팅 테이블에서 게이트웨이 테스트를 ᳤ಃት᳤ឥ ᖜᢩ᷅ Ᏺ᱅ ᐉᓳឥ ᷉ል᷌ ᕷ ᢎᇃ᷅ ೈ៰ឥྜ 211!ntኈླ ᙍ ಌኊ Qbobnfsbᢉ ᥟ ಶᢎ᳤᠂ᢎྜ 4-111 ᤦᶤ ᅉᢐ ᳤ᰡ ፧ ᐞᓶ ᙋᙂ᱓ 자동으로 생성한다. 이러한 테스트는 시험 주행에서 라우팅 기능을 온라인으로 확인하는 데 사용된다. 실험실에서 수행되는 ᢼᖝ ᎆᙂᇢ ᢾᖥ᷌ᜥ ᷅ླྜ ွᢎ᱅ ᐇᓳ ಕ ᢎᓿᢉ ᕷᇢ ླቷ DBO! ᙍṕቸ 7ಕᢉ DBOpf!ᢂ ᶵᇢ൷ᆹ ಕ፯ ᳶᢉ ኀ࿏ ᇢ ൹ጻ᷃ ᢘླ/ 순차적 테스트의 범위를 보완하기 위해 PETRA는 버스 통신 기록을 분석하는 데도 사용할 수 있다. 포르쉐는 이제 라우팅 ൴᭜ ᖆ៳ ᗀ ᢘླ/!ኰᙋቸ ᜵ᤦ᷃ኻ ွ DBO! ᎆᙂቸ ᱣ᷌ ᗂᙌಅឥ ᅉ៰᳹ ᷅ླ/ 에러를 자동으로 감지하는 테스트 툴을 보유하게 되었다. ᢎ᱅ ᇂ ᥙᢎ ᢼᖝ ᎆᙂឥ ኔಶ ᤶᤤ ᢎ ᤤឥᕷ ಶᢎ᳤᠂ᢎྜ 36ಃᢉ ಄ං ᷆ ᗀ ᢘླ/!፭࿅ᇢ ᢼᖝឥᕷ ᖝᇢ ᢾᖥ ླቷ ᢾᖥ ᡱᷰ ᇕ᷌ᜥ ᷅ླ/!ᱏᙂ᳤ ᨵ
www.autoelectronics.co.kr 66 2011 APR·MAY 67
3/4 3/5 Development Feature ECU Test
ᇂ ᗀၗᇢ ႈᎆඋ ᷃ංឥྜ ኋ ᙋಅ ኹ ኰᙋᢉ ᅉ៰᳹ ፶ᎍ ᤤᢉ᷅ླ/!2;2ᇢ ŤŤ ᢎ ᖜ៨ၢឥ ႓ᅉ ᴭትᘮᢉ ಕ፯ᢜႁ ᅉ៰᳹ ၟྜ ኰᙋྜ ᥖංᢽ ኰᙋ-!CBT Qbobnfsb!ಕ፯ ᙋ ᢜၗᨵ ᳤ᰡᢉ ኰᙋ ፧ CBG!ኰᙋ ᡱᷰᇢ ൘ᖄၠླ/ ŤŤ ŤŤ ᢽ ᐆླ ṱᡴᢽᇢ ᴨಃ᷆ ᗀ ᢘྜ ፶ᎍ CBT!ኰᙋ)CBT!>!jnnfejbufmz!po ዂᔂᷓླ/!ᔁᇢ៲ ᙋᙂ᱓ᢉ ᥖ៨ ៨൘ᓳ dibohf*ྜ ᷌࿁ FDVಃ ᖈᕷ ႆឥᕷ ᢖᇖ ᷋ ᙏᤦ ᙋᷜ ᥖᷔᥟ ᙏᙋಅᇢ ಶᢎ᳤ ಌᢎ ᏽೈၟྜ ᙋ ᤤᓿᢽᢐ ᥖංᢽ ᢾᖥ ᠂ᢎ ွᢎ᱅ ᳤ᆵᶼ ಭ᷆ ᗀ ᢘ᜴ᜥ ᷅ ០ឥ ಃᇢ ᢾᖥ᷃ྜ ᳥ᗀ᷅ ೈ៰ᢉ ᥖං ླྜ ಯᢎᝀླ/!᷃ኊ ᱰ ᔉᓶ᪸ ፧ ᱏᙂ ᢽ ኰᙋᢎླ/! CBG! ኰᙋ)CBG! >! po ᳤ ᢾጾಃቸ ᱣ᷌ ᫆ං ᙋᢧ ᤶᓳቸ ᗀᷔ᷅ bdujwf! gvodujpo*ྜ ಶᢎ᳤᠂ᢎಃ ᢎᏳ᳤ ೃ ᜑᇕ ᢽ᷉᷅ ᱰᢎໆ ᱏᙂ᳤ ᙋᙂ᱓ ፯ᔉ ᙋ ᓳᢎᰤ ᙋಅ ᗀᤤ᷃ ᜐ ፩ᇢ ᢎ Ṡᢐ᷃ಶ ၟᝀླ/ ᅉ៰᳹ ᷌ᜥ ᷃ྜ 2;2!ኰᙋᢎླ/!ᄝ᷅ ಶ ᢎ᳤᠂ᢎྜ Sy! ኰᙋ)Űೃ᷉ ኰᙋű*ᅉྜ Porsche Echtzeit ‘real-time’ ( ) = ;!Qpstdif? ಯ ᔉᖄ᷃ ᢾᖥ᷃ං၍ ᷅ླ/!ླቷ ᗀᙍ TRace Analyser ż൷ኄ 4Ž ᪵ ᎈ᧮ ឱឥᕷ ᕻ᰻᷅ ኰᙋኊ ᱏᙂ᳤ ൘ᖄ ᔉᖄ ᙋ ᇕၠླ/ ኰᙋᇢᐜ᱅ ፮ ᙍṕႁ ಃ ኰᙋ ᴭትᘮྜ ᢎቸ ᷌ೃ᷃ං ᡩ᷌ Ᏺ᱅ ቸ ᔉᖄ᷃ ᢾᖥ᷃ྜ ಯᢎླ/!಄ Sy!ኰ )Wfdups*៑ ᷭᇖ᷌ QFUSBᅉྜ ᱰ ಕ፯ ᙋྜ ᔉᖄၠ ኰᙋឥ ᢎቷ፩ŰBhfe ᷓླ/! ᱏᙂ᳤ ፧ ᙋፔᇍᢎᖑ ᖜᶵ᳤᠂᜴ᢐ Cjuűᅉྜ ᷋ዃᢎ ᴭ᷈ၠླ/! ಶᢎ᳤᠂ᢎྜ DBOpfྜ QFUSBᢉ ᱜ࿅ ឮ᷆ ᷅ླ/!ᢎ ᥖංᢽᢐ ᗀᙍ ኰᙋឥᕷ ᷗោᨵቸ ᫆ = ;!Wfdups? ᱰ FDV!ᱏᙂ᳤ឥ ᢽṟၟ᜴ ᢘኹ-!ླ ᷃ྜ ឰᢎ ፯ᔉᷓ ಊ᷃ኻ ೃ᷉ ż൷ኄ 2Ž 7ಕᢉ DBO!ᎆᙂ៑ ࿅ 3ಕᢉ MJO!ᎆᙂቸ ಐ Qbobnfsb!ಶᢎ᳤᠂ᢎ FDV!ᇍᢎᜌ៸ ᜭ᷅ ᕽᤤ ᱣ᷌ ᎆᙂ ᙋፔᇍᢎᖑ ፀᇤ ၠ ኰᙋቸ ᅉ៰᳹ ᷃ං ᢾឥ ኧᢼ Bhfe ᢜၗ ᱏᙂ᳤ ᙋ᮰ᙂቸ ൘ᷪ᷆ ᗀ ᢘླ/!ᓟኊ Cjuቸ ᕽᤤ᷅ླ/!ᢎ Bhfe!Cjuಃ Ṣᖄṟၟ᜴ ᜌྩᅉ ᇢඋၠ ᳤ᰡ ᱣᙍ ᢩᔉ᷆ ᗀ ᢘኻ ᢎ ኰᙋಃ ൷ླ ᡱṱ᷃ ᜐླ ᢘྜ ංྣ ᓿᖆ᷅ ᱏᙂ᳤ ᐆᕷቸ ᔉᖄ ྜ ಯ ᢉ᷅ླ/
᷆ ᗀ ᢘྜ ංྣ၍ ಐ ᢘླ/!DBOpfឥ = ;!Wfdups? ᓳᢜྜ QFUSBቸ ᓳ᷌ ᅉ៰᳹ ᱏᢎ ᴭ᷈ၠ UGT)Uftu! Gfbuvsf! Tfu*ྜ ᢜၗ ᱏ ż൷ኄ 5Ž QFUSBྜ ᱏᙂ᳤ ᙏᷔ ᡩ᷅ YNM!ᱏᙂ᳤ ዂၺ DBQM!ᱏᙂ᳤ ᅉᢎᐸᇃኀቸ ᢜၗᇢ ᐻᢉ ᤤᐆቸ Ṡᢧၠ ൘ᖄ ᱏᢎᐻ၍ ᔉᖄ᷅ླ/ ᙂ᳤ ᙋ᮰ᙂቸ ൘ᷪ᷆ ᗀ ᢘ၍ᇣDBQM Fydfm!ᷰᙌᇢ ᢜၗᇢ ᔉᖄ᷆ ᗀ ᢘླ/ )Dpnnvojdbujpo!Bddftt!Qsphsbn ൷ᇅ ླ ᱏᙂ᳤ ឧྩ᜴ྜ ᢎ ᱰ ᓳ njoh!Mbohvbhf*!ᙂᰡኅ᳤ ᜶᜴ᇢ ᢝᖄၠ QFUSBྜ ಶᢎ᳤᠂ᢎ ಕᤤ ྶೊቸ ಭ᷆ ᷓླ/!᳥ẩ-!ಕ፯ ឧྩ᜴ྜ ൸ẩ ួ០ᢽ ᷌ ಶᢎ᳤᠂ᢎ ွᢎ᱅ ᳤ᆵᶼឥᕷ ᐞᕸ᷆ ᱏᙂ᳤ ංྣ ᤦ᷅ླ/!DBQM ᱏᙂ᳤ቸ ᗀ ᢘ၍ᇣ DBOpf!ᱏᙂ᳤ ዂၺ ൘ᖄ ៨ᖜ ᢐ ᓿṤ ᫆ᆵ᷃ྜ ᳥ᗀ ွᢎ᱅ ᳤ᆵᶼ ኰᙋቸ ᕻ᰻᷆ ᗀ ᢘླ(그림 3)/!᪵ ᎈ᧮ ൘ᖄ᷃ྜ ွ ᢘ᜴ D៑ ᡱᓳ᷅ ൘ጾ ᓳ ቸ ᔉᖄ᷃ྜွ-! ᢎᇃ᷅ ൘ᖄ ៨ᖜྜ ᙋᷜ ᢉ၍ᢽᇢ ᶾ᱅ኇ ᷆ ᗀ ᢘංቸ ᷓླ/ ឱឥᕷ ᅉ៰᳹ ೞೊቸ ᕻ᰻᷃ኻ ᱏᙂ᳤ ᔉ ᷃ኹ-!ኰᙋ ᗀᙍ ႆᢉ ᎆᙂ ೞᇗ ᢎᏳ᳤ឥ ᥖᷔ ᙋྜ ፀᇤ ွᢎ᱅ ංᇣ ោᶵᅉᢐឥ ួቸ ႁ᜴ ᨵᇂ ᙋၗ ᙋ ᄝྜ ᳤ᰡ ᖄංឥᕷ ᱏᙂ᳤ ൘ᖄ ኊႁჽᢎᥙᢎ ፭ᢂ᷃၍ᇣ ᷃ྜ ᳥ᗀ᷅ ංྣ ᢐᙌ᷅ླ/ ᕷ ᴨಃ᷆ ჽឥ၍ ᓳ᷆ ᗀ ᢘླ/!ឭංᕷ ᇵ ᙋ ࿅ᐜᐞᢉ ೈ៰ ᱏᙂ᳤ ᙋᙂ᱓ ጻೞ ᇕၟኹ-!ླቷ ዂၿ ኰᙋྜ ᢎ ᱏᙂ᳤ឥᕷ ᱏᙂ᳤ྜ ኀ ᤤᢉၠ ᱏᙂ᳤ ංྣ ᤦ᜴ ྜ ླᥟ ᎆᙂᢉ ኰᙋឥ ࿅᷌ ᅉ៰᳹ ᐇ ᷅ ឥᇃ ኰᙋಃ ࿅ᇂᇢ ፯ᔉ᷃ං ჽጾ ጻᙋၠླ/!ᓟኊ ᜌྩᅉ ླᜭ᷅ ᴨಃ ᤦ᷅ ᓳ ංྣ ᓳ᷌ YNM!ᳺᢑᇢ ᕽᤤ᷃ ᳺᅉ ᓳ ൴᭜ ၗᙋឥ ᴨಃ᷆ ᗀ ᢘፗᇢ ಕ ᢎླ/ ᷋ ᤤ᷆ ᗀ ᢘླ/!ួቸ ႁ᜴ ᓳᢎᰤ ᙋ ᱅ቸ ᤤ᷆ ᗀ ᢘླ/! DBOpfឥᕷ ᢾ᪸ ᱏᙂ᳤ឥᕷ ᳥ᤤ ኰᙋឥ ᥟ᷆ ᗀ ᢘླ/ ಅ ዂྩ᱅ኇឥ ࿅᷅ ᷗោᨵ៑ CBG! ፧ ŤŤ ᱏᙂ᳤ ᙏᷔ ᱏᙂ᳤ ዂၺᇢ ໆᰰ້ླ/! ᴭትᘮ ឧྩ᜴ྜ ᐜ᱅ ൄᎌᡩ᷅ ᶾ 온라인 및 오프라인 테스트에 CBT!ኰᙋឥ ࿅᷅ ᷗ ಶᢎ᳤᠂ᢎ ᙋಅ Ᏺ᱅៑ ᴭትᘮᢉ ೊᜦ ᶵᇢᤧ᳤ᇢ ಕ፯ၠ ᱅ ៍ᖑ ៨൘ᷓኹ ಶᢎ᳤᠂ᢎ ಕ፯ ឧ 적합한 성능 ᢎ ឭංឥ ᴭ᷈ၠླ/! ൷ᇅ ླ QFUSBྜ QFUSBྜ DBOpf! UGTᢉ ᶙᥘ ංྣ ፧ ྩ᜴ྜ ᳥ẩ ዂၿ ኰᙋቸ ᢾ᪸ᢽ Fydfm!ᷰᙌᢉ ᅉ៰᳹ ᱏᢎᐻ ಶᢎ᳤᠂ ᱏᙂ᳤ቸ ᙏᷔ᷃ྜွ ᶾ៨᷅ ዂၿ ᳺᢑ
Qbobnfsb!ᥟ ಶᢎ᳤᠂ᢎ FDVᢉ DBO!ಶᢎ = ;!Qpstdif? ᇢ Ṡᢐ᷆ ᗀ ᢘ ಅྶ᷅ ൘ᖄᇢ ಕ ᢎಃ ᅉ៰᳹ ᷆ ዂၿ ᙍṕ៑ ኰᙋቸ ᐆឭ ᢜၗᇢ ᔉᖄ᷅ླ(그림 4)/! YNM! ᳺᢑ ᳤᠂ᢎ ංྣ ಭ᷃ྜ ឮ᷆ ᷅ླ(그림 2)/ ż൷ኄ 3Ž QFUSBྜ ൷ᆵᶼ ᓳᢜ ᢐ᱅ᴚᢎᙂቸ ᱣ᷌ ᖟᘹಶ ൘ᖄၠླ/ ᅉ៰᳹ ೞೊቸ ᐞᕸ᷆ ᗀ ᢘྜ ᙋᙂ᱓ ᥘླ/!಄ ᥙ ᷃ໆᢉ ᅉ៰᳹ ൴᭜ឥ ᐜ᷉᷃ ᔉᖄ᷆ ᗀಃ ᢘྜွ-! ᢎ ᳺᢑᢉ ೈ៰
68 www.autoelectronics.co.kr 2011 APR·MAY 69
3/6 3/7 Development Feature ECU Test
ᢎྜ ᓿṤឥ ႓ᅉ ፩ᢎ᳤ ᄝྜ ᙍṕ ᇍᏵឥ ᕷ ᗀᷔၡ ᗀ ᢘླ/!ᄝ᷅ ᥖᷔ ᱏᙂ᳤ቸ ᡩ ᷌ ឥᇃ ፯ᔉ ᙋ ೞᇗ ኰᙋಃ ṟኻឥ ᙋ ᶙᙋၟ၍ᇣ ᙋᙂ᱓ ൘ᖄ᷆ ᗀ ᢘླ/!൷ᇃ ኻ ᤶᢝ ፶ᙌ ፧ ᥖᷔ ၗᢝឥ ႓ቷ ᅉ៰᳹ ឥᇃಃ ᙋ ፭ᐇၡ ᗀ ᢘླ/ ោᶵᅉᢐ ᱏᙂ᳤ឥᕷྜ ᙋᷜ ᥖᷔ ᥟ ං = ;!Qpstdif? ᇣၠ ᇢ൷ ᳺᢑᢎ DBOpfᢉ ᢩᔉ ᐻᇣ ż൷ኄ 6Ž QFUSBྜ ᅉ៰᳹ ፧ ᐇᓳ ൴᭜ឥ ࿅᷅ ᗂᢂᖄ ಭᓳ᷃ ᱏᙂ᳤ ᐆᕷឥ ೃቸ ᇖ᷅ླ/ ᱣ᷌ ᢩᔉၠླ/!᷅ ಃ ᡱ᷅ ႈᎆඋ ංྣ ᢽ ွᢎ᱅ᢉ ឥᇃ ፯ᔉ ᤡᇢ ፩ᇢ ᢎၗ᷆ ᗀ ᢘྜ ංྣᢎླ/!ឥᇃ ᢾṶឥ ፯ᔉ ᷃ྜ ᢎᏳ᳤ྜ ࿅ಕ ឥᇃᢉ ᢐឥ ࿅᷅ ᡱ ᷅ ᤤᐆቸ ᤦ᷅ླ/!ᄝ᷅ ឥᇃ ᱣೊቸ ᱣ ᷌ ឥᇃᢉ ᑁ၍៑ ᶤឥ ࿅᷅ ᥟ៨᷅ ᶙ ቸ ᗀ ᢘླ/!ួቸ ႁ᜴ ឥᇃಃ ೊᖝ ፯ ᔉ᷃ྜ ᜌྩኻ 2-111!lnኈླ ᷅ ᎈኊ ፯ ᔉ᷃ྜ ᄝྜ ᳥ᤤ ᓳᢎᰤ ᙋಅឥ ࿅᷅ ᡩ ፭ᢎ ኗ៰ ᰣ ᜌྩኻ ᴨ൵ឥ ᐿ᷌ ᓿ࿅ᢽ ᇢ ᢝឥ ࿅᷅ ྾ ᤦ᷆ ᗀ ᢘླ/
요약 및 전망 ᴭትᘮྜ ោᆻၗᜎ DBOpf! ᱰ ᓳ᷌ ៘ླ/! ංᤸ ᱰ ᪸ᢐ 3118ឥ QFUSBಃ ಃၟኻᕷ Ṡᢧၟ ೊᖝ ಕᕻၞླ/!ಕ፯ᢜ ECU 테스트 ྜ ᜦಅᢉ Ṹᇗኊᇢ QFUSBቸ ᓳ᷆ ᗀ ᢘླ/! ᙏᤦ ᱣᙍ ွᢎ᱅ᢉ ᅉ៰᳹ ᢜၗ ᇢ ᐞᕸ᷃ྜ ᢎ ᔁᇢ៲ ፶ᙌ ᙏᷜᙏ ᱏᙂ = ;!Wfdups? ᳤ᢉ ᢜ൸ ං፭ ᱏᙂ᳤ ᙋໆኀោቸ ᐆ៓᷅ ż൷ኄ 7Ž QFUSBྜ ᅉ៰᳹ ፧ ᐇᓳ ൴᭜ឥ ࿅᷅ ᗂᢂᖄ Ṡᢐ᷃ ᱏᙂ᳤ ᐆᕷឥ ೃቸ ᇖ᷅ླ/ ECU 테스트 과정의 시스템화 ླ/! ᴭትᘮ៑ Ᏺ᱅ྜ ᔁᇢ៲ ಶᢎ᳤᠂ᢎ ಭ ᙋᙂ᱓ ಕ፯᷃ං ᡩ᷌ ፠᷃ಶ ᷭᇖ᷌ DBOpf!Nfbtvsfnfou!Tfuvqᢉ Usbdf! 자동차 제조업체에서 사용하는 ៘ླ/!ᢎ ᱰᇢ ᢐ᷃ឭ Qbobnfsbᢉ FDVቸ ឥᕷ ᙂ᳤ኄ ᷆ ჽ ᓳ᷆ ᗀ ᢘྜ DBQM 용어로 작성되는 테스트 보고서 ಕ፯᷃ྜ ၗᜎ ᢣᢩᢽᢐ ឥᇃቸ ᤶංឥ ಊ ᶾ᱅ ፧ DBQM! ᱏᙂ᳤ ᅉᢎᐸᇃኀቸ ಃ ᱏᙂ᳤ಃ ᙏᷔၟྜ ၗᜎ ᱏᙂ᳤ ᙋᙂ᱓ ᷆ ᗀ ᢘಶ ၞኹ ᱰᢉ ᖄᗁ၍၍ ኗ៰ ༐ᜌ 체계적이고 효율적인 테스트 시스템을 통해 CAN, LIN, MOST, FlexRay 및 차량용 Ethernet을 손쉽게 개발하십시오. ᢘླ/!DBQM!ᱣ ᶾ᱅ྜ ᔉᖄၠ ዂྩ᱅ ፯ᔉ᷅ ᢎᏳ᳤ឥ ࿅᷌ ᓿᖆ᷅ ᐆᕷቸ ᤳླ/! ᱣᙍ ွᢎ᱅ቸ ᐞᕸ᷃ྜ ွ ᖜ៨ၟྜ ኇ ᢝឥ ᶾ៨᷅ ኰᙋኊ ᱣᙋᰪླ/!ᢎ ᔉᖄ᷅ླ/! ᱏᙂ᳤ ᐆᕷྜ ಶᢎ᳤᠂ᢎ ಕ ᙋಅ၍ ᢎᢾᢉ ᗀၗ ႈᎆඋឥ ᐿ᷌ ᜦ 76& > 버스 네트워크를 시뮬레이션하여 초기 개발 단계에 > 캘리브레이션, 진단 및 I/O 포트 인터페이스 등의 ංྣ DBOpf! ᱏᙂ᳤ ᙏᷔ ᡩ᷅ ංᐉ ፯ ᢾጾಃ៑ ླቷ ංᗄ ᐜᕷᢉ ၗᇵಃ ዂၦ ྶၞླ/!ᄝ᷅ ᔉᖄං ፶ᙌ ᱣ᷌ QFUSB 서부터 실제 테스트 환경을 조성 다양한 이점 > 자동 생성 테스트 환경과 테스트 리포트를 통해 ៨൘ᓳ᷋ ᷌ೃ᷅ླ(그림 5)/! QFUSBྜ ၗᢑ᷃ಶ ᢎ᷌᷆ ᗀ ᢘ၍ᇣ ᴭትᘮᢉ ᳥ᤤ ಕༀ ᆵᢉ ᢜၗᨵ ᙋኀ ፧ ᖆ࿅ឥ ᡱ 관련 제품 정보 및 다운로드: www.vector.com/test 구성 요소 및 시스템을 체계적으로 테스트 ၎ኅ ᙏᷔᷰ ᱰᢎፗᇢ ᓳᢜྜ DBOpf!ᅉ ᶵᇢᖆᙂ ፧ ᜴ឥ ᢽṟၟ᜴ ᢘླ/!᳥ᤤ ឰ᷃ಶ ᢽ᷆ ᗀ ᢘኹ-! ᶾ៨᷅ ೈ៰ > 개발과 테스트에 동일한 플랫폼을 사용해 ECU ᢎᕻᙂቸ ᕽ᭛᷃ ᜐ၍ ᱏᙂ᳤ ዂၺ ኰᙋ ᡱᷰឥ ࿅᷃ឭ ዂၿ ွᢎ᱅ ᐇᓳ ൴ GmfySbzໆ ᢎ࿏ ಒ ླቷ ᎆᙂ ᙋᙂ᱓ 테스트의 속도를 향상 ᢝᖄ᷆ ᗀ ᢘླ/ ᭜ ᡩ፭ឥ ࿅᷅ ಭᓳಃ Ṣ᷃ಶ ᢎሃኹ- ၍ QFUSB!ಕༀឥ ᱣ᷉᷆ ᗀ ᢘླ/ > 시뮬레이션 및 제어가 가능한 하드웨어를 통해 ECU의 기능을 완벽하게 테스트
70 www.autoelectronics.co.kr
3/8
Vector Korea IT Inc. | Phone +82 2 807 0600 | www.vector.com 위반, 불규칙적인 시간 주기, 단락으로 인한 버스 전압 레벨 교란 폭스바겐에서 개발한 ECU 통신 테스트 등이 있다. OEM과 공급업체에 동일한 테스트 환경 공급업체에서 재현 가능한 테스트
공급업체는 이러한 모든 제약 조건에서 테스트 대상 디바이스 OEM별 테스트 구현은 ECU 개발 프로세스 중 공급업체에게 중요한 역할을 한다. 네트워크 적합성을 확인하는 데 (DUT: Device Under Test)의 올바른 동작을 유지하고 재현해야 그림 1. VAG용 CANoe 테스트 패키지의 회로도 레이아웃 사용되고 다양한 ECU 간의 통신에 오류가 발생하지 않도록 하며 자동차 OEM의 최종 승인을 위한 중요한 기준이 할 기본적인 책임이 있다. 테스트 구현 비용은 날로 늘어나는 자동 되기도 하는 것. 폭스바겐 그룹(VAG: Volkswagen Group)의 공급업체들은 이제 VAG용 특정 테스트 소프트웨어로 VW80118 규격에 차 전자 장치의 복잡성을 고려하면 만만치 않은 수준이다. 이를 위 VAG용 CANoe 테스트 패키지는 구성 대화 상자, UDS(Unified 따라 고속 CAN 테스트 케이스를 자동으로 생성함으로써 ECU 개발 시간과 비용을 모두 최소화할 수 있게 되었다. 해 테스트 애플리케이션을 만들어 유지하거나 테스트 설비를 임대 Diagnostic Services) 및 KWP(Key Word Protocol)를 위한 해야 한다. 그리고 각각의 새로운 ECU 및 수정 작업에서는 만들어 CAPL(Communication Access Programming Language) 테스 글 가빈 C. 로저스(Gavin C. Rogers), 클라우스 테오발트(Klaus Theobald) 자료제공 벡터코리아 www.vector-korea.com 진 테스트를 포괄적으로 변경해야 한다. 트 라이브러리는 물론 잔여 버스 시뮬레이션을 위한 VAG 상호 작 이 프로세스의 문제는 공급업체이든, 테스트 설비든, OEM이든 용 계층이 포함된 테스트 구성 생성기로 구성되어 있다. 따라서 관계없이 각 당사자의 테스트 구현 중 일부 세부 사항이 어느 정 CANoe는 실제 테스트 시퀀스만 처리하는 것이 아니라 제공된 도 벗어날 수 있다는 점이다. 테스트 결과가 최신 테스트 규격과 VAG 추가 기능을 사용하여 필요한 잔여 버스 시뮬레이션까지 구 다르게 나오면 엄청난 시간이 소요되는 문제 해결 과정을 거치게 현한다. 이러한 OEM별 확장은 대개 무료로 사용할 수 있으며 시 ECU는 요구되는 기능을 충실히 수행해야 하는 것은 물론 특수 스트를 수행해야 한다. 이 테스트에서는 정상적인 조건에서는 물론 된다. 그런 다음에는 발생한 문제의 책임이 누구인지를 가려내는 뮬레이션 생성기, 상호 작용 계층(IL) 및 네트워크 관리(NM)로 구 한 OEM별 세부 사항을 고려하면서 ECU가 속한 환경에서 원활하 다양한 오류 상황에서 ECU의 동작을 시험하게 되는데, 이러한 오 달갑지 않은 사안을 처리해야 한다. 오류의 원인이 반드시 ECU 성되어 있다. 이 테스트 패키지에서는 완벽한 자동화를 위해 게 작동해야 한다. 이 때문에 기능 테스트 외에도 집중적인 통신 테 류 상황에는 공급 전압 강하, 오류 메시지 수신, 전송 시 프토토콜 자체가 아닐 수 있으며 규격 또는 해석에 차이가 있을 수도 있다. VH1100을 활용하여 ECU 및 CANstress 교란 모듈(Disturbance 오류를 나중에 수정함으로 발생되는 높은 비용을 피하기 위해 가 Module)에 전압을 공급한다(그림 1). 능한 조기에 오류를 감지하는 전통적인 지혜는 여기서도 적용되 고 있다. 교란 및 공급 전압 컨트롤 자동 생성
버튼 푸시를 통한 테스트 VH1100은 테스트 시스템에서 DUT의 다양한 전원 공급 상황을 시 뮬레이션하는 데 사용되는 제어 가능한 전압 공급 장치이다. 이 장 벡터의 CANoe 테스트 및 시뮬레이션 시스템을 VAG에서 확장한 치는 단자 점화(15), 배터리(30) 및 접지(31)를 독립적으로 스위칭 버전에서는 비용 절감과 ECU 품질 향상이 반드시 상충하지 않는 하는 계전기가 포함되어 있으며 DUT의 전류 소모량을 정밀하게 다는 사실을 입증한다. VAG용 CANoe 테스트 패키지(Test 측정할 수 있다. 또한 과전압, 부족 전압 및 순간 정전에 대한 DUT Package)는 VAG 개발자, 테스트 전문업체 및 사내 OEM 부서에 의 동작을 검사하기 위해 USB를 통해 리모컨으로 다양한 전압 패 서 원하는 목표를 신속하게 달성할 수 있도록 한다. 추가 준비 절차 턴 및 교란을 시뮬레이션할 수 있다. 하드웨어 모듈인 CANstress 없이 버튼 한 번만 눌러 고속 CAN 적합성 테스트를 자동으로 실행 는 CAN 버스의 디지털 및 아날로그 교란을 시뮬레이션하는 데 사 하기 위한 PC 기반의 테스트 구성을 만들 수 있기 때문이다. 독일 용된다. 이 USB 하드웨어는 버스 라인에 직접 연결되고 물리적 속 볼프스부르크(Wolfsburg)에 소재한 폭스바겐에서 개발한 테스트 성 및 논리 레벨을 재현 가능한 방식으로 조작하는 데 사용된다. 사 패키지 버전 2.0은 폭스바겐 그룹에서 발표한 최신 테스트 규격을 용자는 유연한 트리거 및 교란 로직을 바탕으로 CAN 메시지의 원 준수한다. 또한 VAG 공급업체의 의무 사항인 모든 VW80118 테 하는 비트 위치를 훼손시키고 비트 필드를 조작할 수 있다. 또한 스트 케이스를 다룬다. 이 패키지에서는 현재 및 이전 버전의 COM(Component Object Model)을 통한 완벽한 원격 제어 기능 VW80118 테스트 규격을 모두 지원한다. 은 VAG 테스트를 자동화하는 데 중요한 역할을 한다.
46 AUTOMOTIVE MANUFACTURING &Technology 2010•December 47 3/10 3/11 CANstress 모듈을 함께 사용하면 표준 CAN 툴을 기반으로 하는 경제적인 테스트 환경을 구성할 수 있다. 개발자, 공급업체 및 테스 트 전문업체에서는 여기에 설명된 솔루션을 통해 최소한의 노력으 로 OEM과 동일한 테스트를 수행할 수 있게 된다. 또한 구성 및 테 스트 시퀀스가 자동으로 생성되므로 시간과 개발비용이 절감된다. 이와 동시에 OEM과 공급업체는 조기 오류 탐지, 줄어든 반복 작업 및 향상된 품질을 통해 이점을 누리게 된다. VAG용 CANoe 테스 트 패키지는 폭스바겐에서 고속 CAN 부품 테스트용으로 인정한 유일한 테스트 시스템으로, 공급업체의 사내 테스트를 위해 권장되 는 제품이다. 다음 버전에서는 전체적으로 적용 가능한 VAG 테스 트 규격을 추가(예: 네트워크 관리 메시지(NM-High)에 대한 규 격)함으로써 기존 솔루션을 확장할 계획이다.
저자
그림 2. 버튼 한 번만 누르면 VAG용 CANoe 테스트 패키지에서 완전한 테스트 구성을 만들고 테스트 실행을 시작하며 보고서를 생성한다. 가빈 C. 로저스(Gavin C. Rogers, 공학 학사 및 이학 석사) 네트워크 및 분산 시스템용 툴 제품 라인의 팀 관리자이자 CANoe 테스트 패키지 의 제품 관리자로 근무하고 있다. 일에는 네트워크 및 잔여 버스 시뮬레이션에 대한 OEM별 정보가 그림 4. 성공적인 테스트 사례에 대한 세부 보고서의 예 저장되지만 TBD 파일에는 ECU 관련 세부 정보가 들어 있다. 각 클라우스 테오발트(Klaus Theobald, Dipl. Inform.(FH)) ECU에 대해 XML 형식으로 ECU 관련 정보를 제공하는 새 파일 네트워크 및 분산 시스템용 툴 제품 라인의 수석 소프트웨어 개발 엔지니어로 근 을 만들어야 한다. 이 정보에는 Tx 및 Rx 메시지 목록, 진단 파라 요약 및 전망 무하며 VAG 테스트 패키지 개발 업무를 담당하고 있다. 미터, DTC(Diagnostic Trouble Code), 규격 버전 등이 포함된다. TBD 파일에서는 VW80118 테스터를 올바르게 구성하는 데 필요 VAG용 CANoe 테스트 패키지와 VH1100 테스트 하드웨어 및 한 VAG ECU에 대한 정보를 제공한다. 또한 공급업체에서는 DTC 를 추가하는 등의 목적을 위해 VAG에서 제공한 편집기를 사용하 여 이 파일에 정보를 추가할 수도 있다. 테스트 구성 생성기에서는 벡터 CANoe에서의 CAN/LIN Conformance Test를 위한 테스트 하드웨어 TBD 파일 및 DBC 파일을 읽고 이를 통해 CANoe 테스트 구성(그 림2)을 생성하는데, 이러한 테스트 구성은 잔여 버스 시뮬레이션 VH1100은 테스트 시스템에서 DUT의 다양한 전원 공급 상황을 시뮬레이 과 XML 테스트 흐름 모듈로 구성되어 있다. 션하는 데 사용되는 제어 가능한 전압 공급 장치이다. 이 USB 하드웨어는 버스 라인에 직접 연결되고 물리적 속성 및 논리 레벨을 재현 가능한 방식 그림 3. VW80118 테스트의 테스트 실행 제어 으로 조작하는 데 사용되기 때문에 사용자는 유연한 트리거 및 교란 로직 명확한 표현의 HTML 테스트 보고서 을 바탕으로 CAN 메시지의 원하는 비트 위치를 훼손시키고 비트 필드를 조작할 수 있다. 공급업체에 테스트 기반을 제공하는 OEM Tx 및 Rx 메시지의 수에 따라 수백 가지의 테스트 사례를 생성할 또한 COM(Component Object Model)을 통한 완벽한 원격 제어 기능은 수 있다(그림 3). 각 테스트 사례에서는 자세한 HTML 테스트 보고 VAG 테스트를 자동화하는 데 중요한 역할을 한다. 테스트 환경의 성공적인 구성을 위한 핵심 요구 사항 중 한 가지는 서(그림 4)와 로그 파일을 ASCII 형식으로 변환한다. 이 테스트 보 CAN 하이 스피드를 위한 CANoe 테스트 패키지 VAG 혹은 CANoe 7.1 되어 있으며, DUT의 전류 소모량을 정밀하게 측정할 수 있다. 과전압, 부 ECU 통신을 TBD(Test Basis Documentation) 파일 및 CAN 네 고서는 VAG 테스트 규격의 번호에 해당하는 섹션 번호별로 정리 이 제공하는 LIN 자동화 테스트 등의 용도로 사용되는 이 VH1100은 단자 족 전압 및 순간 정전에 대한 DUT의 동작을 검사하기 위해 USB를 통해 트워크 데이터베이스(DBC) 형태로 일관되게 기술하는 것. OEM에 되어 있다. 오류가 색상으로 강조되어 있어 사용자는 실행된 테스 점화(15), 배터리(30) 및 접지(31)를 독립적으로 스위칭하는 계전기가 포함 리모컨으로 다양한 전압 패턴 및 교란을 시뮬레이션할 수도 있다. 서는 이러한 두 파일을 작성하여 공급업체에게 전달한다. DBC 파 트 사례의 성공 또는 실패 상태를 신속하게 확인할 수 있다.
48 AUTOMOTIVE MANUFACTURING &Technology 2010•December 49 3/12 3/13 DEVELOPMENT FEATURE
전자장치(하드웨어)는 가능한 전반적인 버스 제품 영역에서 광범위한 용도로 활용될 수 있 어야 하며 비용이 효율적인 방식으로 조정 가 능해야 한다. 기타 과제로는 연비 향상, 배기 가스 감소, 능동형/수동형의 안전 및 지원 시 스템에 대한 선행개발 등이 있다. EvoBus는 이와 같은 E/E 개념의 모든 요 구 사항을 융통성 있게 다룰 목적으로 확장 가 능한 멀티플렉스 시스템, 즉 MUX 시스템을 개발했다. 최대 9개의 모듈로 구성되는 이 MUX 시스템의 전자장치 아키텍처는 일종의 분산 시스템 내에 있는 분산 시스템이라고 할 수 있다. MUX 시스템의 하드웨어와 펌웨어는 [그림 1] MUX 시스템에서 분산 기능에 대한 예시 Side Marker Light 애플리케이션 개발을 위한 기본 컴포넌트 및 툴을 제공하는 일종의 미들웨어에 해당한다. 복잡한 ECU 네트워크를 위한 테스트 벤치 이 미들웨어는 IEC61131을 준수하는 OEM별 공급업체의 테스트 후에는 컴포넌트 테스트 는 전환, 네트워크 종료 등의 상태 전환은 오 논리 칩을 활용해 사용자가 직접 프로그래밍 를 시작으로 소프트웨어 모듈 테스트를 거쳐 류 없이 실행돼야 하며 애플리케이션 및 하드 버스 산업에서 요구하는 유연성 갖춘 테스트 시스템 할 수 있으며 애플리케이션 레벨 아래에 배치 HiL(Hardware-in-the-Loop) 테스트, 최종적 웨어와 정확하게 상호 작용하며 실행돼야 한 된다. 각 MUX 모듈은 구동장치, 차대, 내부, 으로는 실제 차량 내 테스트까지 포괄하는 V 다. 나머지 버스의 CAN 통신을 시뮬레이션하
ECU 테스트는 실제 기능의 작업 영역 및 범위에 따라 매우 복잡해질 수 있다. 이는 해당 기능이 서로 밀접히 관련돼 있고 텔레매틱스 및 진단의 5대 주요 CAN 버스로 모델 내 테스트 프로세스 체인이 시작된다. 컴 는 것 외에도 OSEK 네트워크 관리 또한 여기 차량 유형, 특징 및 특별한 고객 요구에 따라 변화하는 5~9개의 ECU로 이뤄진 네트워크를 다뤄야 할 때 더욱 그러하다. 상 구성된 전체 차량 네트워크와 여러 LIN 하위 포넌트 테스트에서는 미들웨어 기능의 정확한 에서 시뮬레이션된다. 각 MUX 모듈에서는 항 황이 이러하기에, EvoBus에서는 벡터(Vector)의 VT System에 기반을 둔 새로운 컴포넌트 테스트 벤치를 도입했다. 유연 네트워크에서 다양한 버스 분기로 분산된다. 작동 여부와 교정이 중점적으로 다뤄지며, 애플 상 다른 MUX 장치의 현재 시스템 상태를 인 하고 자동화된 테스트로 테스트 범위를 크게 넓히고 모든 테스트 케이스를 정확히 재현할 수 있게 됐다. 리케이션은 테스트 프로세스의 좀 더 뒤에 위 지하고 있어야 하므로 동기화 프로세스가 지 테스트 과제: 치한 단계에서 다뤄진다. MUX 시스템 자체는 속적으로 실행된다. 글│미샤엘 슈나이더(Michael Schneider), EvoBus � 최대 9개 모듈의 ECU 네트워크 확장 가능한 피어 투 피어(Peer-to-Peer) 시스 프로세스 이미지의 교환 과정에서, 지정된 필립 메어클레(Philipp Merkle), EvoBus �� MUX 시스템의 구성은 기능적 밀도와 높은 템이다. 차량에 사용되는 MUX 모듈의 수는 선 시간 및 실시간 요구 사항은 올바르게 충족되어 카챠 하만(Katja Hahmann), Vector ��� 수준의 자유도를 가지므로 시행해야 할 테스 택된 장비 버전과 고객의 특정 요구에 따라 달 야 하며 이는 곧 다른 테스트 기준을 나타낸다. 트의 범위가 매우 넓어진다. EvoBus 2011에 라진다. 각 MUX 모듈에는 대규모로 구성할 수 서는 시간 집약적이고 복잡한 테스트 단계를 있는 여러 디지털 및 아날로그 방식의 I/O가 환경 시뮬레이션 및 테스트 자동화 최적화할 목적으로 MUX 시스템의 요구에 맞 있다. MUX 모듈은 CAN 버스를 통해 서로 연 또한 MUX 시스템은 다양한 하드웨어 변경 ��� ��� 게 개별적으로 조정된 새로운 테스트 벤치를 결되어 전체 시스템을 형성한다(그림 1). 사항에 맞춰 자연스럽게 작동할 수 있는지 파 EvoBus 엔지니어는 VT System을 활용해 버스 부문에서의 당면 과제는 상용차로서 제공할 필요도 있다. 구체적인 고객의 요구를 호환성이 뛰어난 하드웨어를 활용함으로써 시 도입했다. 이 테스트 벤치는 벡터의 VT 악하기 위한 테스트를 거쳐야 한다. 테스트 내 자동 현가 제어장치를 위한 밸브 제어, 짐칸 갖춰야 할 기술적 요구 사항을 충족하는 동시 바탕으로 맞춤식으로 개조해야 할 경우가 있 너지 효과를 얻을 수 있고 비용도 절감할 수 System을 기반으로 한다. 이 테스트 벤치를 용에는 MUX 시스템의 하위 CAN 및 하위 LIN 및 엔진 격실문, 복잡한 내부 조명 시스템을 에 최소한 승용차와 동등한 수준의 안락함과 고 이 작업은 때로는 배송 직전에 이뤄지기도 있는 것이다. 활용하면 테스트에 필요한 MUX 환경의 모든 버스에 대한 데이터 및 진단 라우팅이 포함된 위한 차문 제어 ECU 등과 같은 방대한 기능 편의성을 제공하는 차량을 제조하는 것이다. 하는데, 이를 위해서는 본체와 편의용 전자장 어떤 면에서 버스의 E/E(전기/전자) 요구 컴포넌트 및 시스템 상태를 시뮬레이션 할 수 다. 진단 기능을 테스트할 경우에는 특별한 주 을 기초 테스트한다. 또한 차문 제어 ECU에 그 핵심은 단일 공통 하드웨어 장치에서 최대 치 영역의 아키텍처를 고도로 모듈화하고 유 사항은 승용차의 요구 사항과 크게 다를 수 있 있다. 테스트 대상에는 CAN 및 LIN 통신의 의가 요구되며, 이는 곧 MUX 시스템의 입출력 대해서는 고객의 특정 요구를 충족하기 위해 120개의 기능을 구현하는 플랫폼 시스템을 개 연하게 구성해야 한다. 버스 산업에서는 승용 는데, 이는 버스의 기능이 대부분 개별적인 고 신호뿐 아니라 다양한 하드웨어의 입출력 신 채널에서 유연하고 다양한 진단 작업 구성이 폭넓은 선택의 여지를 제공한다. 여기서 핵심 발하는 데 있다. 해당 시스템의 구성은 매우 차 산업에 비해 매우 적은 양이 생산되므로 도 객의 요구에 의해 결정되기 때문이다. 각별히 호도 모두 포함된다. 벡터에서 제공하는 허용된다는 점 때문이다. 그 결과, 진단 테스트 과제는 네트워크 관리이다. 전원 끄기 모드에 단순할 수도 있고 고도로 복잡해질 수도 있다. 심/장거리/관광 버스를 비롯한 모든 모델 시리 면밀한 모듈성과 유연성이 요구되는 E/E 개념 CANoe 테스트 및 시뮬레이션 소프트웨어가 케이스의 수가 매우 많아지게 된다. 현재 MUX 서 시동 모드로의 전환, 또는 그 반대로 바뀌 또한 개별 기능을 가능한 여러 형태로 조합해 즈에서 재사용이 바람직한 방식이다. 표준화돼 에서는 바로 이러한 점을 고려해야 한다. 각종 설치된 PC는 사용자 인터페이스 역할을 한다. 시스템 자체의 트러블 코드를 테스트하려면 가
96 www.autoelectronics.co.kr 2013 MAR·APR 97
3/14 3/15 DEVELOPMENT FEATURE
장 중요한 테스트 케이스 1,000개를 구현할 필 측정한다. 그 밖에, VT6104 모듈은 CAN 및 다시 문서화돼 저장된다. 행할 수 있었다. 테스트 시스템의 다른 긍정적 요가 있다. 그러나 시스템의 다양성으로 인해 LIN 네트워크의 네트워크 통신에 사용된다. 이 경우 Fail 결과를 추 인 면으로는 탁월한 유연성을 거론할 수 있다. 가능한 조합 수의 10배 이상이 필요해질 수도 VT6050 PC 모듈은 CANoe Realtime-PC 적할 수 있는 한편, 테스 VT 테스트 솔루션은 새로운 소프트웨어 버전 있다. 이 작업은 수동으로 실행할 수 없으며 경 이며 이를 통해 시뮬레이션과 테스트가 수행 트 대상에 관한 해당 교 의 자동화 테스트에 활용될 뿐 아니라 고객 서 제적으로도 실행 불가능하다. 현재 VT System 된다. 19인치 제어 캐비닛에 장착된 EvoBus 정 및 통계 정보를 모든 비스 및 운영 부서에 Fail 결과에 관한 피드백 은 이러한 테스트를 수 시간 안에 자동으로 실 테스트 벤치의 입출력 레벨만 각각 12개의 VT 샘플 레벨에서 확보할 을 보내기 위한 분석 툴 역할을 한다. 이러한 행 및 문서화하는 기능을 지원한다. System 모듈로 완전히 채워진 5개의 논리 레 수 있다. 보편적으로 활 상황에서는 신속한 대응이 필요하기 마련이다. MUX 테스트는 매우 복잡하고 다양하므로 벨로 구성돼 있다. 이 시스템은 현재 9개의 가 용할 수 있는 툴 집합과 따라서 하드웨어는 테스트 스크립트 작성 없 테스트 시퀀스를 체계적으로 자동화해야만 경 능한 MUX 모듈 중 5개 모듈에 대한 요구 사 최소화된 인터페이스 개 이 CANoe 사용자 인터페이스를 통해 수동으 제적으로 처리할 수 있다. 19인치 산업용 랙 항을 지원한다. 또한 제어 캐비닛에는 수동 측 수는 EvoBus에 있어서 로 실행될 수 있으며 이와 같은 방식으로 문제 형식에 모듈식으로 탑재된 VT System은 특유 정을 위해 MUX ECU의 모든 입력 핀에 개별 중요한 요구였다. 이러한 해결 및 수정에 자연스럽게 활용될 수 있다. 의 테스트 자동화 작업을 위해 최적화됐으며, 적으로 액세스할 수 있도록 패치보드가 포함 요구 사항은 테스트 요 6개의 모듈로 이뤄져 테스트 실험을 위한 대용 돼 있으며 모든 CAN/LIN 버스를 위한 분류용 건의 정의부터 테스트 EvoBus 테스트 벤치의 확장 계획
량 HiL 시스템까지 이르는 작업용 장치가 구성 접점 역시 제공된다. [그림 3] MUX 테스트 시스템의 레이아웃 실행 및 보고서 평가를 EvoBus에서 채택한 VT System은 완벽한 될 수 있도록 지원한다(그림 2). VT System은 일반적으로 포괄적인 ECU 테스트에는 정 포괄하는 벡터의 접근 기능을 갖춘 약 2M 높이의 제어 캐비닛으로 연결된 CAN 및 LIN 버스의 통신뿐 아니라 입 상적인 작동에서 벗어나는 상황의 테스트 시 다. CANoe는 자동차 애플리케이션과 관련된 방식으로 해결됐다. 이뤄지며 벡터에서 구현한 대형 VT System 력 및 출력 회로망과 관련해 ECU 환경의 포 퀀스도 포함된다. 이러한 이유로 VT System 전자장치 개발에 활용되는 산업 표준으로 인 MUX ECU 네트워크를 테스트하는 작업에 프로젝트의 일부이다. 사양 작성 단계에서 시 괄적인 에뮬레이션도 구현한다. 은 ECU 환경에 정의된 오류를 생성하도록 설 정받고 있는 동시에 MUX 모듈에 여러 이점을 서 VT System을 통해 막대한 효율성을 실현 작 및 교육 단계에 이르는 프로젝트 기간은 약 에뮬레이션의 주요 이점은 운전자, 승객, 차 계됐으며, 그 예로는 입력단에 위치한 결함이 지원하는 다양한 기능을 제공한다. 직관적인 할 수 있다. 특정 테스트 소프트웨어의 준비를 5개월에 달한다. 꾸준히 진행되는 새로운 차 량 장비 및 기타 환경적 컴포넌트의 동작을 그 있는 센서나 출력에 연결된 구동기의 전형적 사용자 인터페이스로 인해 테스트 솔루션의 포함해 이전에는 약 2주가 소요되었던 광범위 량 유형의 개발과 하이브리드 구동장치의 도 대로 재현해 시뮬레이션 할 수 있다는 점이다. 인 로드 동작 등이 있다. 시스템에서는 요청이 사용자 작업 관련 훈련은 빠르고 원활하게 실 한 테스트는 이제 단 하루 만에 끝낼 수 있게 입으로 인해 필수적인 테스트 시스템은 계속 예를 들어 차문 제어 테스트를 수행하려면 버 수신되는 즉시 연료선에서 회선 차단 및 단락 행된다. VT System의 모든 파라미터는 됐다. 이전에 ECU의 핀은 특별히 제작된 완 적으로 확장될 예정이다. EvoBus에서는 입출 스 문을 지정된 시간에 정확히 열기 위해 버튼 이 발생할 수 있고 Ground 및 배터리 전위로 CANoe로부터 액세스할 수 있다. 벡터의‘테 전 수동 테스트 박스에 삽입되었으며 이 테스 력 모듈을 추가함으로써 테스트 벤치를 확대 을 반복적으로 눌러줘야 한다. 이러한 작업은 의 단락 또는 과전압 및 저전압이 발생할 수도 스트 기능 세트’는 고성능 테스트 자동화를 위 트 박스는 개별 테스트를 실행할 때마다 수동 할 계획이다. 그 결과, 해당 테스트 벤치에서 수동으로 실행되지 않고 테스트 시스템에 의 있다. 5개의 전기 부하는 특별한 기능을 수행 한 기준을 충족한다. 그 밖에도, 테스트 시퀀 으로 전선을 갈아야만 했다. 이러한 접근 방식 최대 6개의 모듈로 구성된 MUX 시스템을 테 [그림 2] Evobus MUX 시스템의 컴포넌트 테스트 은 자동화가 불가능했으므로 제공되는 테스트 해 실행된다. 따라서 정확한 시간에 맞춰 순서 한다. 즉, 각각 소스나 싱크로, 10암페어의 전 벤치로 활용된 VT System의 모습 스를 적절히 정의할 수 있고, 테스트를 실행할 스트할 수 있을 것이다. 이 경우 제 2의 제어 대로 진행되며 어느 때든 재현할 수 있다. 류를 전도할 수 있으며 이 경우 MUX 시스템 수 있으며, 보고서를 생성할 수도 있다. 진단 옵션도 거의 없었고 근본적으로 오류에 취약 캐비닛으로 시스템을 보완할 필요가 있다. 이 은 특수한 테스트 상황에 충분한 전압을 공급 석에 사용되는 CANoe 호스트 PC에 이더넷을 규약에 맞는 재현 가능한 테스트 상황을 생성 한 편이었다. 테스트를 반복해야 할 경우 담당 과정은 총 9개의 모듈을 처리할 수 있는 완전 확장 가능한 테스트 시스템 통한 받을 수 있다. 통해 연결된다. 이러한 작업 분산을 활용하면 및 실행할 경우 CANoe Option DiVa 직원은 장시간 동안 해당 작업에 묶여 있었다. 한 시스템 구현으로 나아가는 중간 단계에 해 맞춤형 하드웨어 레이아웃 지원 전반적인 테스트 시스템에 고도의 확장성을 부 (Diagnostic Integration and Validation 한편으로, VT System을 활용할 경우 간단히 당한다. 이는 곧 대형 관광버스의 각종 기능은 이 시스템에서는 PWM 신호 생성 및 처리 모듈형 시스템 레이아웃의 실시간 기능 여하는데크게도움이될수있다(그림3). Assistant: 진단 통합 및 검증 지원)를 통해 유 버튼만 누르면 테스트 실행을 재현할 수 있다. 상당한 크기가 전제될 수 있기 때문이며, 이러 와 효과적인 값의 결정 등과 같은 더 복잡한 통신 버스 시뮬레이션에서는 Daimler 고유 용한 서비스를 수행할 수 있다. 테스트 자동화 오늘날 EvoBus에서는 새로운 시스템의 활용 한 규모에서 안락함과 편의성을 위한 전자 장 기능을 비롯해 일반적으로 사용되는 모든 아 의 상호작용 레이어 및 OSEK 네트워크 관리 테스트 벤치용 편집기에는 테스트 사양이 저장되는 DOORS 을 통해 500건의 개별 테스트(진단 제외)를 치, 실내 온도 조절기, 내부 조명, 하이브리드 날로그 및 디지털 방식의 입출력 표준을 지원 를 위해 OEM 패키지를 활용한다. 이 경우 적 프론트엔드 표준 툴 CANoe 데이터베이스에 대한 인터페이스가 포함돼 있 더 심도 깊고 폭넓고 정확하게 수행할 수 있으 차량용 분산 기능, 고속 차문 개폐 메커니즘, 한다. VT1004 유형의 로드 및 측정 모듈은 은 노력으로 데이터 버스상의 사실적인 통신 데스크톱 PC에 설치된 CANoe는 모든 사 다. VT System에서 테스트 실행이 완료된 후 며, 한편으로 이전에는 이와 동일한 조건에서 엔터테인먼트 시스템 및 기타 기능을 유지하 ECU의 출력과 연결되는 반면에 VT2516 및 동작뿐 아니라 전송 동작에 대해서도 완벽한 용자 작업, 테스트 정의 및 평가 작업에 대한 해당 결과는 데이터베이스에 XML 형식으로 약 100건의 무작위 검사 유형의 테스트만 수 려면 포괄적인 테스트가 항상 필요하다. VT2004 모듈은 디지털 및 아날로그 입력을 에뮬레이션을 수행할 수 있다. 실시간 관련 작 플랫폼 역할을 한다. EvoBus에서는 듀얼 모 작동시키기 위한 전자장치를 포함한다. 업과 통신 버스 시뮬레이션 테스트 시퀀스는 니터 설정을 통해 기본 프로그램 창, 출력 핀, 문의 VT7001 전원 공급 장치 모듈은 운영 전압을 VT6050 실시간 모듈에서 직접 실행된다. 또 입력 핀, 측정 값 표시 등을 효과적으로 정리 벡터코리아 마케팅부 김용성 매니저 조절하고 MUX 모듈에 의한 현재의 소비량을 한VT6050은사용자상호작용과표시및분 해 보여줄 수 있는 충분한 공간을 확보하고 있 서울시 용산구 한남대로11길 12 고뫄스빌딩 5층 / Tel. 02-807-0600 E-mail: [email protected]
98 www.autoelectronics.co.kr 2013 MAR·APR 99
3/16 3/17 3/18 3/19 3/20 3/21 D ESIGN IDEA
HIL 테스트 벤치(Test Bench) - VT System 야 한다. 벡터의 VT System은 차량 테스트에 필요한 기능을 반영하여 테스트 의 범주를 극대화하고, PXI 형태의 VT 모듈은 하드웨어의 유연성을 제 이러한 요구사항에 맞춰 벡터에서는 Test 공하며 HIL 장비 구축에도 용이하다. 기존의 테스트 환경 구축은 실제 Automation Editor와 vTESTstudio라는 타 ECU와 배터리, 센서, 액추에이터를 해당 ECU에 직접 연결하여 구축 2가지 테스트 케이스 생성 툴을 제공한다. 하거나 차량에 연결하여 테스트를 진행하였다. 이러한 방식은 전원 공급 Test Automation Editor - 사양서로부터 에 어려움이 있으며 시간적으로나 비용에서 비효율적이다. 도출한 테스트 사양을 간단히 테스트 케이 VT System은 이러한 측면을 고려하여 다양하고 자동화된 테스트 시 스로 만들 수 있는 툴이다. 요구사항들을 항 뮬레이션 환경을 만들어 주는 솔루션이다. VT System은 ECU가 필요로 목별로 구분하여 정형화된 테스트 스텝을 오늘날 자동차 시장에서 ECU 테스트는 주요 이슈로 떠오르고 있다. 고객사의 요구사항이 증가함에 따라 ECU의 기능은 복잡 하는 전압·저항·전류·부하 등의 자극(stimulation)을 생성하며, 출 작성하고 각각의 테스트 스텝들이 모여 하 해지고, 차량의 옵션 및 지역별 요구사항에 따른 차이는 ECU의 력에 대한 모니터링도 가능하다. 특히 실시간 모니터링을 통해 오류 상 나의 테스트 케이스를 완성한다. 테스트 케 배리언트를 증가시키기 때문이다. 요구사항의 복잡성 및 ECU 황과 같은 특정 환경을 재현 가능해 문제점 도출이 용이하다. 예를 들어, 이스의 특성에 따라 테스트 케이스들은 공 배리언트의 증가는 테스트 알고리즘 및 시스템에 직접적인 영향 BCM(Body Control Module)에서 램프 ON/OFF 제어를 위해 입력을 디 통 그룹으로 구조화될 수 있고, 테스트의 을 미치게 된다. 자료제공 | 벡터코리아(www.vector.com) 지털 입력으로, 출력은 실제 부하 ON/OFF를 컨트롤해야 한다면, 해당 최상위 레벨인 테스트 모듈을 거쳐 하나의 BCM은 실제 디지털 입력을 주기 위한 ECU와 램프를 제어하는 릴레이 패키지로 작성된다. 테스트 케이스 작성은 및 부하를 가져야 한다. 하지만 VT System을 이용하면 BCM 전원 입력, Flow Table 방식으로 하나의 테스트 스텝 디지털 입력, 릴레이 제어, 부하 등의 자극과 ECU 출력 및 피드백 신호 안에 테스트 패턴들을 이용하여 입력 자극, FATC(Full Auto Temperature Controller) 테스트를 위한 에 관한 확인이 가능하며, 실제 센서나 액추에이터가 ECU에 연결된 것 대기 시간, 출력 검사 방식의 직관적 설계 처럼 개발 환경을 조성할 수 있다. 또한, 테스트 결과를 자동으로 리포트 가 가능하다. 툴에서 제공되는 ‘Set’, ‘State 에 기록함으로써 오류 상황에 대한 추적성을 향상시킨다. check’, ‘Wait’ 등과 같은 테스트 패턴들을 HIL 시스템 개발에 대하여 이용하여 테스트 케이스를 완성할 수 있으 며, 프로그램에 대한 지식 없이도 테스트 케 이스를 작성할 수 있는 기능을 제공한다. 또 복잡한 ECU 테스트를 수행하기 위해서 드웨어의 유연성을 해결하고자 새롭고 다양한 테스트 솔루션을 연구 한, 사용자 라이브러리를 통해 기존의 작업 는 테스트 자동화를 통해 테스트 시 발생할 하였으며, 그 결과 테스트 케이스를 손쉽게 생성할 수 있는 TAE(Test 산출물을 드래그 앤 드롭 방식으로 여러 테 수 있는 휴먼 에러의 감소와 리소스 최소화 Automation Editor)와 ECU의 I/O 테스트 환경을 유연하게 구축하기 스트 케이스들을 재활용할 수 있다. 완성된 가 필요하다. 테스트 자동화는 테스트 방법 위한 하드웨어 VT System을 제공하고 있다. 이 기사에서는 TAE와 VT 테스트 케이스들은 CANoe를 통해 테스트 과 범위에 따라 매우 복잡한 과정이 될 수 System을 도입해 ECU 테스트에 최적화된 HIL 시스템을 개발한 동아전 할 수 있으며, 디버깅 및 결과 판정을 실시 있으며, 테스트 자동화를 위한 주요 고려 사 기부품의 사례로 벡터의 ECU 테스트용 HIL 시스템 솔루션을 소개한다. 간으로 모니터링할 수 있다. 동아전기부품 항은 테스트 케이스 생성 방법의 편리성과 의 프로젝트에서는 TAE가 테스트 케이스 하드웨어의 유연성이다. 동아전기부품의 연구 분야 및 개발 ECU 생성 툴로 사용되었다. [그림 2] VT System을 이용한 시뮬레이션 환경 벡터에서는 ECU테스트의 복잡성 및 하 동아전기부품은 공조기기 Control을 주력으로 AVN과 기타 자동차 부 vTESTstudio - 테스트 케이스의 작성 품을 생산하는 업체로 40년간 자동차 부품개발에 앞장서 왔다. 공조기기 테스트 케이스 설계 을 위한 통합 솔루션 툴로 직관적인 인터페 Control은 에어컨의 두뇌로서 AUTOMATIC 제어 기능을 통해 최소한의 테스트 케이스의 설계를 위해서는 다음과 같은 조건이 고려돼야 한다. 이스를 제공한다. Table Editor, Diagram 조작으로 사용자가 쾌적한 환경에서 운전할 수 있도록 자동차 공조기기 ▶ 사양은 테스트 케이스 생성을 위한 기준을 나타내므로 완성도 높은 Editor, CAPL Editor, C# Editor 총 4 를 제어하는 장치이다. 동아전기부품은 동탄에 있는 중앙연구소를 기반 사양이 필요하다. 개의 테스트 케이스 생성 기법을 제공하 으로 기구 설계, 하드웨어, 소프트웨어, 소프트웨어 검증 등의 통합 연구 ▶ 사양 변경 시 테스트 케이스 또한 변경 작업이 용이해야 한다. 며, 사용자 기호에 따라 테스트 케이스 에 를 통해 공조기기 기술 연구에 매진하고 있다. ▶ 테스트 케이스 변경 시 제 3자 수정이 가능하도록 유지 보수가 쉬워 디터를 선택적으로 활용할 수 있다. Test [그림 1] 동아전기부품의 HVAC Control Head
54 AUTOMOTIVE Report JULY 2016 55 3/22 3/23
54-61p AR 201607월호.indd 54 16. 6. 27. 오후 9:42 54-61p AR 201607월호.indd 55 16. 6. 27. 오후 9:42 D ESIGN IDEA
Automation Editor와 마찬가지로 스텝바 Out 제어 및 릴레이를 이용한 에러 유발(Fault injection) 등의 기능 제공 Automation Editor 툴에서 호출되어 사용된다. 이스텝(Step by Step) 형태의 테스트 시퀀 ▶ VT7001: 전원 공급 모듈로서 ECU의 전원 제어, 소비 전류 측정 등 테스트 파라미터의 경우 파라미터의 목적에 따라 아래 3가지 방법으로 스 작성이 가능할 뿐만 아니라, 다이어그램 의 기능 제공 정의했다. 형태로 테스트 케이스 작성이 가능하여 테 해당 ECU 테스트는 기능 동작 테스트에 초점을 맞추었으며 센서값 입 ▶ CANdb Editor: Environment Variable을 이용하여 테스트에 사용 스트 흐름을 파악하기 쉽고, 이식성·확장 력, 액추에이터 동작 및 스위치 제어 등의 기능을 VT System을 이용하 되는 General 파라미터를 정의했다. 또한, 테스트 결과 측정에 활용할 ▶Test Automation Editor: Test 성·재구성 측면에서 장점이 있다. 여 구현했다. ECU의 전원 공급은 VT7001 모듈과 VT2004 모듈을 이용 Expected 파라미터를 선언하였다. Expected 파라미터는 테스트 결과 Automation Editor에서는 테스트 모듈 하여 배터리 전원과 Ignition1, Ignition2의 전원을 공급하였다. 판단 시 CAPL 라이브러리에서 값을 호출하는 식으로 사용되며, 이는 사 에 대한 변수 생성이 가능하다. 따라서 해 테스트 자동화 프로젝트 FATC 메인 패널에는 사용자 제어를 위한 다양한 스위치들과 LED 및 용자가 향후 유지 관리 시 테스트 소스가 아닌 CANdb Editor의 파라미 당 테스트 ECU에 사용될 파라미터 중 센서 동아전기부품에서는 FATC 공조 ECU 테 온도 제어를 위한 휠 스위치 등이 있으며, 스위치값 입력과 LED 출력 확 터 변경만으로 유지관리를 할 수 있는 요소가 된다. stimulation에 사용될 파라미터와 테스트 스트 수행 시, CANoe와 VT System을 이 인은 VT2516을 이용해 구성했다. 이는 스위치 제어 및 결과값 확인을 테 파라미터를 Test Automation Editor를 통 용하여 자동화된 테스트를 수행했다. ECU 스트 수행 시 자동으로 제어할 수 있도록 지원한다. FATC는 많은 조건 해 정의하였다. 테스트 케이스의 값 입력 시 개발 초기 단계부터 기능 구현과 동시에 테 을 고려하여 쾌적한 온도 조건을 제공하는 것이 중요하며, 다양한 센서 직접 값을 대입하는 것이 아닌 변수 치환을 스트 케이스를 작성하여, 개발 시작 단계에 값들을 고려해야 한다. 이를 위해 VT2004 모듈을 이용했으며, 실제 센 통해 테스트 케이스를 완성한다. 또한, 테스 서 나타날 수 있는 문제점을 조기 수정했다. 서 모듈의 기능을 VT2004 트 파라미터는 테스트 결과 확인 시 입력 파 또한, 테스트 결과를 토대로 이전에 발생했 로 제공했다. [그림 4] CANdb 기반 파라미터 라미터로 사용했다. 던 문제점들을 자동으로 반복 테스트해 문 마지막으로 액추에이 제점 재발을 미리 방지할 수 있었으며, 결 터 동작에 대한 피드백 및 ▶System Variable: ECU의 IO 제어를 위한 변수 선언을 과적으로 요구사항에 기반을 둔 적합한 테 출력 값은 VT1004를 이 System Variable로 선언했다. ECU IO 제어에 사용되는 변수는 스트 케이스 선정과 축적된 데이터베이스 용하여 측정하고 결과값 Stimulation을 위한 변수와 Check를 위한 변수로 구분되며, 사용 를 토대로 제품의 신뢰성을 향상시킬 수 있 을 테스트 시퀀스상으로 자가 인식하기 쉬운 이름으로 정의했다. 또한, VT module이 CANoe에 [그림 6] Test Automation Editor 기반 파라미터 었다. 동아전기부품은 16개의 테스트 케 출력하도록 구성했다. 해 연결 시 제어하기 위한 변수가 자동으로 생성되는데, 자동 생성된 변수와 이스(그룹)를 도출하여 Test Automation 당 액추에이터에 대한 출 사용자가 정의한 변수를 Mapping 기법으로 연동하였다. 즉, 사용자는 테스트 패키지 Editor를 통해 테스트 케이스를 작성했다. 력 값은 CANoe의 system 테스트 케이스 작성 시 이해하기 쉬운 사용자 정의의 변수를 이용하여 테 테스트에 사용되는 모든 파일 테스트 시 variable에 할당해 패널에 스트케이스를 개발했다. 실 동작에 대한 부분은 CANoe에서 자동 생성된 퀀스(예: XML), 사용자 함수 (예: CAPL), 테스트 환경 구축 표시함으로써, 테스트 엔지 변수가 VT System을 제어하도록 구분했다. 파라미터 파일, CANoe configuration, 동아 전기에서 개발한 ECU는 5개의 액 니어는 출력값을 실시간으 Database 등은 하나의 프로젝트 폴더로 구 추에이터, 4개의 센서, 32개의 스위치 입력 로 확인할 수 있다. 성되며, 이 프로젝트 폴더의 결과물을 테스 [그림 3] VT System과 동아전기부품의 ECU를 장착한 및 LED 출력을 가진다. 이 액추에이터와 센 HIL 테스트 벤치 트 패키지라는 이름으로 사용했다. 서를 동작하기 위해 2개의 VT1004, 2개의 테스트 패키지는 CANoe 툴을 이용하여 VT2004, 2개의 VT2516과 1개의 VT7001 테스트 모듈 설계 컨셉 테스트의 자동화를 수행할 수 있다. CANoe 모듈이 장착되었다. 간략히 이들 모듈은 다 Test Automation Editor - 테이블 형태의 테스트 케이스 작성 기법으 Test Setup 윈도우에 테스트에 필요한 모 음과 같은 특징을 가진다. 로 이 툴을 이용하여 테스트 시퀀스를 구현했다. 개별적인 테스트 케이스 든 테스트 모듈을 구조화하여 정의했으며, ▶ VT1004: 아날로그 측정 모듈로서 전 의 구조화 및 관리를 담당한다. 또한, 시스템 초기화 및 Stimulation에 각각의 테스트 수행 시에는 테스트 모듈을 압 측정, 전자 부하, 릴레이를 이용한 에러 반복적으로 사용되는 기능들을 Test Automation Editor의 Template으 통해 테스트 수행에 대한 진행 상태 및 결과 유발(Fault injection) 등의 기능 제공 로 사용자 함수를 만들어 재사용했다. 를 실시간으로 확인할 수 있다. ▶ VT2004: 센서 제어 모듈로서 전압, 저 CAPL(CAN Access Programming Language) - C 언어 기반의 스크 또한, Real ECU의 동작 외에도 Real
항, 전류, PWM 출력 등의 기능 제공 립트 언어로서 테스트 결과 측정 및 판단 관련 라이브러리를 CAPL을 이 [그림 5] 매핑 솔루션 ECU의 동작에 대한 부분을 CANoe의 ▶ VT2516: 디지털 모듈로서 디지털 In/ 용하여 구현했다. CAPL에서 만든 사용자 함수는 메인 시퀀스인 Test Panel을 통해 구현함으로써 테스트 수행
56 AUTOMOTIVE Report JULY 2016 57 3/24 3/25
54-61p AR 201607월호.indd 56 16. 6. 27. 오후 9:42 54-61p AR 201607월호.indd 57 16. 6. 27. 오후 9:42 D ESIGN IDEA
였다. 또한, 테스트 시스템을 리모트로 제어하여 사용자가 테스트 시스템이 있 는 랩실이 아닌 외부 데스크에서 접속 하여 테스트를 진행함으로써 테스트의 효율성을 향상시켰다.
[그림 7] CANoe로 이식한 FATC 패널 시뮬레이션 동아전기부품에서는 기존에 개발 시, 동작 상태에 대한 부분을 손쉽게 확인할 된 테스트 프로젝트의 개선 작업으 수 있다. 로 테이블 형태의 테스트 구조를 다이 어그램 형태의 테스트 구조로 변환하 테스트 수행 및 보고서 분석 는 작업을 고려하고 있다. 이를 위해 동아전기부품에서 선정한 총 16개의 테스 vTESTstudio 툴의 활용을 계획하고 트 그룹, 182개의 테스트 케이스를 갖는 테 [그림 9] 동아전기부품에서 개발한 Rack 있으며, 프로젝트 개선 작업의 가장 큰 System 스트 시퀀스를 만들어 테스트를 진행했다. 이슈는 독립성과 재활용이 가능한 파 ECU의 전원 및 IO 제어부터 CAN 통신 데 라미터의 관리와 배리언트에 따라 테스트 케이스의 설계 변경을 최소화 이터의 처리, 테스트 시퀀스의 동작 등 테스 할 수 있는 부분에 초점을 맞추고 있다. 또한, 테스트 케이스 설계자의 트 수행에 필요한 일련의 절차를 사용자의 변경이 발생하더라도 기존 개발자의 의도를 쉽게 파악하여 테스트 케이 조작 없이 100% 자동화 처리했다. 이는 테 스 설계의 연계성을 중요한 요소로 보고 있다. 스트 수행에 필요한 인력 및 시간을 단축할 수 있는 중요한 솔루션이다. 이처럼 많은 양 결론 의 테스트 케이스를 처리하기 위해서는 반 개발자는 ECU 초기 개발 단계 시작부터 테스트 환경을 어떻게 구성할 드시 테스트 자동화 솔루션이 필요하다. 개 지를 고려해야 한다. 테스트 케이스 개발 측면에서는 접근성과 유지관리 발 초기 단계부터 양산 단계까지 보다 넓은 가 용이한 테스트 케이스 생성을 위한 툴이 필요하며, TAE는 이러한 요 범위를 테스트할 수 있으며, 이로 인해 에러 구사항을 충족할 수 있는 테스트 케이스 생성용 툴이다. 테스트 환경 개 율을 최소화시킬 수 있다. 발 측면에서는 일반적인 프로토콜부터 디지털/아날로그 입출력까지 다
구분 소요 시간 비고 양한 역할을 수행할 수 있는 솔루션을 갖춰야 한다. 특히 버스 시스템이 기존 수동 테스트 16시간 - 늘어나고 시스템의 요구사항이 대폭 증가함에 따라 범용적 하드웨어 인 신규 자동 테스트 4시간 4배의 테스트 시간 단축 터페이스 솔루션이 점차 중요시되고 있다. [그림 8] FATC 수동 테스트 시간과 VT System을 이용한 테스트 자 VT System은 고객사의 요구사항에 맞춰 대부분의 시뮬레이션 환경 동화 작업 비교 구축 및 테스트 케이스를 구현할 수 있으며, 쉽게 사용자가 접근할 수 있 프로젝트 향후 계획 도록 접근성도 용이하다. 향후 수많은 업체들이 기존의 수동 테스트를 자 동아전기부품에서는 테스트 시스템 구축 동화 시스템으로 변화하는 부분에 초점을 둘 것이며, TAE와 VT System 의 일환으로 Rack 시스템을 개발하여 테스 은 이러한 추세에 발맞춰 테스트 범위를 확대하고 테스트 환경 개발 비용 트 환경을 구축하였다. 이는 테스트를 전문 및 시간을 단축시켜 줄 수 있다. 적으로 수행할 수 있는 기반 사항이 되었으 며, 테스트가 필요할 때 ECU와 커넥션만 ▶저자 이정훈 Lee, Jung-hoon | 동아전기부품의 FATC/MTC 모듈 개발 소프트웨어 엔지니어 을 변경하여 반복 수행 테스트 및 기능 테스 유기훈 Yu, Gi-hoon | 동아전기부품의 FATC/MTC 모듈 테스트 엔지니어 트를 쉽게 진행할 수 있는 시스템을 준비하 이문주 Lee, Moonjoo | Vector Korea IT의 테스트 툴 엔지니어링 및 툴 응용 고객 프로젝트 담당자 김용희 Kim, Yong-hee | Vector Korea IT의 진단 툴 엔지니어링 및 툴 응용 고객 프로젝트 담당자
58 AUTOMOTIVE Report 3/26
54-61p AR 201607월호.indd 58 16. 6. 27. 오후 9:42 1. variables 유저 인터페이스의 표시를(시그널의 스테이트에 따라 Bit ECU 테스트 효과적으로 프로그래밍하기 2. { map을 변경하는 패널) 위한 시그널의 처리는 다소 복잡하기 3. const long kOFF = 0; 때문에, 이에 대한 구현은 별도의 함수로 분리하였으며 13행 CAPL 활용의 기초, 팁과 트릭 (1부) 4. const long kON = 1; 의 SetLightDsp는 2개의 메시지 시그널을 함수 인자로 하여 5. } 호출된다. 6. 7. on message EngineState { 마지막으로 19~28행은 송신된 시그널의 값에 따라 Lists 네 Part 1: CAPL 기초 • CAPL 프로그램은 분석 대상 시스템의 컨셉에 대해 특화 8. @sysvar::Engine::EngineSpeedDsp- 임스페이스의 시스템 변수 LightDisplay에 다른 값을 쓰는 CAPL은 벡터에서 개발된 프로그래밍 언어로서, 널리 사용되 된 데이터베이스를 사용한다. 메시지와 시그널은 데이터베이 Meter = this.EngineSpeed / 1000.0; 별도의 함수를 정의하고 있다. 본 데모 구성에서는 이 변수 고 있는 소프트웨어 툴인 CANoe와 CANalyzer에서 지원된 스 내에서 개별적인 이름을 가지며, 프로그램 코드에서 이를 9. } 에 의해 디스플레이 페널 상의 적절한 Bitmap이 선택된다. 다. 3개의 연속 기사에서 모든 수준의 사용자 이해를 돕기위 직접 사용할 수 있다. 그림1에서 메시지에 대해 “EngineS 10. 해 CAPL의 기본 뿐 만 아니라 팁과 트릭을 다룰 예정이다. 첫 tate”와 이 메시지 내의 시그널에 대해 “EngineSpeed”가 이 11. on message LightState { [각 출판물에 대해 독자를 위한 CAPL의 간략한 소개] 번째 파트에서는 CAPL의 기초를 집중적으로 다룬다. CAPL을 에 해당된다. 12. if (this.dir == RX) { CAPL은 C언어와 유사한 절차적 프로그래밍 언이이며, Vec 처음 사용하는 사람들을 주대상으로 하지만 이미 CAPL을 알 • CAPL은 “포인터 타입”을 지원하지 않는다. 이로 인해 C언 13. SetLightDsp(this.HeadLight,this. tor Informatik에 의해 개발되었다. 프로그램 블럭의 실행은 고 있는 사용자들에게도 개별적인 CAPL구조를 넘어서는 부 어에서 자주 발생하는 수많은 잠재적 프로그래밍 오류와 프 FlashLight); 이벤트에 의해 제어된다. 전용 브라우저 내에서 CAPL 프로 분에 대한 동기부여를 통해 약간의 이해을 제공할것이다. 두 로그램의 크래쉬를 근원적으로 예방한다. 하지만 에러가 발 14. } else { 그램을 개발하고 컴파일한다. 이를 통해 데이터베이스 내에 번째 파트는 CAPL의 고급 기능에 대해서 다룬다. 마지막으로 생하기 쉬운 특성을 논외로한다면 포인터는 아주 강력한 컨 15. write(“Error: LightState TX received 포함된 오브젝트(메시지, 시그널, 환경변수)뿐만 아니라 시 세번째 파트는 성능과 메모리 요구에 대해 언급하며 데이터 셉을 제공하기 때문에 CAPL에서도 예를 들면 동적 메모리 대 by node %NODE_NAME%”); 스템 변수를 접근할 수 있다. 또한 CAPL에는 개발/평가/시뮬 베이스와 associative array의 사용에 관한 팁과 트릭을 제공 신에 associative array와 같은 몇몇 기능에 대한 대안을 제공 16. } 레이션 툴인 CANoe와 CANalyzer를 다루기 위한 미리 정의 한다. 하고 있다. 17. } 된 많은 수의 함수가 제공된다. CAPL과 C언어가 공유하는 중요한 특징 중 하나는 항상 컴파 18. CAPL은 20년이상동안(CAPL은 DOS용 CANalyser에서 최초 일되는 것이다. 즉, 효육적인 실행코드와 유연한 머신 코드로 19. SetLightDsp (long headLight, long 로 사용됨) 간단한 신호 생성에서 복잡한 버스 노드의 시뮬레 변환된다. hazardFlasher) { 이션에 이르는 광범위한 작업을 효울적으로 구현하는데 사 20. long tmpLightDsp; 저자: 용되어 왔다. 이후로 CANoe와 CANalyzer 2개의 제품을 예제: 간단한 CAPL 프로그램 21. CANoe로 예를 들어 지칭하겠다. 특정 작업을 가능한한 단순 이 섹션에서는 간단한 CAPL 프로그램을 제시하였다(그림1). 22. tmpLightDsp = 0; 하게 해결하는 것이 CAPL의 일관된 목표였다. 대표적인 수행 이 예제는 버스 모니터링 툴의 기본 기능 중 하나인 버스상의 23. if(headLight == kON) 되는 작업은 수신된 메시지에 대해 특정 동작을 하거나, 시그 트래픽을 수신하고 사용자에 의해서 관측 및 모니터링되는 24. tmpLightDsp = 4; 널 값을 체크하고 설정하고 메시지를 송신하는 것이다. 프로 버스상의 몇개의 이벤트를 대비하는 기능을 수행한다. 본 예 25. if(hazardFlasher == kON) 그램은 이러한 작업에 정교하게 특화되어야하고 추가적인 제는 생략된 샘플 CANoe 프로그램이다(Easy.cfg샘플의 Dis 26. tmpLightDsp += 3; 오버헤드를 필요하지 않아야한다. play.can). 그림1이 예제 프로그램에 해당한다. 이후로 전체 27. @sysvar::Lights::LightDisplay = tmp- 기능을 간략하게 요약하고, 각 영역별에 대해서 상세하게 설 LightDsp; 물론 많은 경우가 그렇게 단순한 형태는 아니지만, CANoe 사 명하겠다. 28. } Marc Lobmeyer (Dipl.-Inf.) 은 1994년부터Vector Informatik 용자들이 일반적으로 수행하는 많은 프로그래밍 작업은 실 에서 CANoe와 CANalyzer의 개발자로 근무하고 있다. 제적으로 아래 제시된 예제와 같이 단순하고 사소한 형태일 작업 설명 것이다. 이것이 “최대한 단순화”라는 원칙에 따라 복잡한 작 • 데이터베이스에 기술된 CAN 버스의 모든 요소, 즉 버스 7~9행에서는 최소 형태의 메시지 이벤트 프로시저를 보여 업을 해결할 수 있는 툴로서 CAPL이 수년동안 지속적으로 확 노드, 메시지와 전송 시그널을 관측한다. 준다. 이 함수는 이 메시지가 버스 상에 전송될 때마다 호출 장되어온 이유이다. • EngineState 메시지가 수신되면, 이 메시지에 포함된 En 된다. CAN 통신의 경우, 이에 대한 정확한 시점은 CAN 콘트 gineSpeed 시그널을 디스플레이 패널에 표시하기위해 신호 롤러의 TX 혹은 RX 인터럽트 시점, 즉 메시지의 정확한 전송 “CAPL”은 “Communication Access Programming Lan 처리를 수행한 후 시그널이 패널로 연결된다. 완료 직후에 해당한다. 특정 함수의 호출을 트리거하게되는 guage”의 약어이다. CAN에 집중한 초기 버전은 오랜기간에 • LightState 메시지가 수신되면, 이 메시지에 포함된 Head 메시지는 이러한 문법으로 참조된다. 걸쳐 차량용 버스 시스템인 LIN, FlexRay, MOST, J1587 뿐만 Light와 FlashLight 시그널을 디스플레이 패널에 표시하기위 아니라 ARINC 및 CANopen까지 확장되어왔다. 해 신호 처리를 수행한 후 시그널이 패널로 연결된다. 8행에서는 EngineSpeed 시그널의 값이 수신된 신호로 부터 읽 Roman Marktl (Dipl.-Ing)은2012년부터Vector Informatik에 다른 많은 언어와 마찬가지로 CAPL은 C언어의 문법에 상당 프로그램의 상세 설명 혀지며, 시그널 변환(/1000.0)을 거쳐 시스템 변수에 할당된 서 CANoe와 CANalyzer의 Product Manager로 근무하고 있 한 바탕을 두고있다. C, C# 혹은 다양한 최신 스크립트 언어 행번호는 CAPL 프로그램의 일부분이 아니며, 각 행과 구역에 에 익숙한 사용자는 빠르게 CAPL 사용에 친숙해진다. 하지만 대한 참조를 용이하게 하기위해 추가되었다. 여기에서는 컴 다. 다. C 프로그램과 CAPL 프로그램이 대별되는 몇가지 독특한 특 팩트한 표현을 위해 개행 중괄호를 별도의 행에 배치하지는 성이 있다: 않았다. 11~17행은 LightState 메시지에 대한 메시지 이벤트 프로시 링크: • CAPL은 “event-driven”방식이다. 프로그램은 개별 함수로 져를 보여 주며, 여기에서 방향지시등과 관련된 정보를 송신 벡터 홈페이지: www.vector.com 구성되어 있고, 각 함수가 메시지의 수신, 신호의 변화, 타이 CAPL 프로그램에서는 전역 변수와 상수를 정의할 수 있다. 하게 된다. 이에 대한 처리는 EngineState 메시지의 처리 방 머 만료 및 “환경”의 변화등과 같이 분석대상인 시스템내에 이는 “variables” 영역에서 이루어진다(1~5행). 이 상수와 변 법과 다음을 제외하고는 유사하다. 12행에서 전송된 메시지 서 발생되는 이벤트에따라 동작하는 것을 의미한다. 예를 들 수는 이 프로그램에서 전역으로 정의되며 프로그램의 모든 의 방향 플래그(.dir)를 검사한다. 노드에서 송신된 메시지(값 어 “EngineState” 메시지에 대응하기 위해서는 “On message 곳에서 사용이 가능하지만 CANoe의 다른 프로그램에서는 이 TX)에 의해서도 이벤트 프로시져가 트리거되기 때문에, EngineState”를 사용할 것이다. (그림 1) 사용할 수 없다. 다른 영역은 이벤트에 대한 처리(7~17행)와 이 프로그램에서는 수신된 메시지(값이 RX)만을 처리하여야 보조 함수(19~28행)를 정의하고 있다. 한다. 이 경우 15행에서 오류 메시지가 출력될 것이다.
3/28 3/29 Measurement가 include 파일 및 상위 파일에 공존하는 경우 저자: ECU 테스트 효과적으로 프로그래밍하기 이다. 해당 예외 함수의 경우, 코드가 지정된 순서대로 실행 된다. 즉, include 파일의 코드 다음으로 상위 파일의 코드가 CAPL 활용의 기초, 팁과 트릭 (2부) 실행되는 구조이다. 그에 따라, include 파일을 사용하여 ‘데 이터 유형 선언‘, ‘변수 정의‘, ‘함수 라이브러리 제공‘과 같은 세 가지 작업을 실행할 수 있다:
본 기사의 1부에서는 CAPL 프로그래밍 언어의 기본 개념을 다뤘다. 2부에서는 이벤트 프로시저의 동작 시간에 관해 설명한다. #pragma library: 적합한 CAPL DLL 인터페이스를 실행하는 또한, „일반적인 프로그래밍“ 및 „조건부 컴파일링“과 관련하여 사용자들이 CAPL 프로그램을 좀 더 효과적으로 사용할 수 있는 한 CAPL 프로그램은 다른 언어에서 생성된 Windows DLL을 팁도 제시한다. 사용할 수 있다. 이러한 DLL은 지시어 #pragma library(“ca- pldll.dll”) 에 바로 연결된다. Marc Lobmeyer (Dipl.-Inf.) 은 1994년부터Vector Informatik에서 CANoe와 CANalyzer의 개발자로 근무하고 있다. 매크로: CAPL에서는, 코드 또는 조건부 컴파일링에서 사용할 수 있는 많은 사전 정의 매크로들이 제공된다. 코딩용 매크로 실행 모델 시스템 변수 업데이트: 사용자는 CAPL을 이용하여 프로그램 들은 별도의 제약 없이 코드 상에서 어디서나 사용할 수 있 CAPL 언어와 C(혹은 C++) 언어의 주요 차이점은 프로그램 밖에서 보이는 환경 변수나 시스템 변수를 변경할 수 있다. 다. C 언어와 달리, 매크로는 문자열 상수, 변수 식별자 및 함 요소의 호출 시기와 방법에서 비롯된다. 예를 들어, C 언어의 CAPL의 경우, 현 이벤트 처리가 종료되기 전까지는 값 변경사 수명 내에서 자유롭게 사용할 수 있다. 해당 매크로에는 특수 경우 main() 함수에서부터 프로세스가 시작된다. 반면, CAPL 항이 해당 변수에 적용되지 않는다. 동일한 프로시저 상에서 문자 ‘%’가 시작과 끝에 표시되며, 일반적인 프로그램 코딩 언어의 경우 프로그램이 동일한 시퀀스의 프로시저들로 구 해당 변수가 새로운 값으로 설정되었다 할지라도, 현 프로시저 작업에 주로 사용된다. 사용 가능한 코드 매크로는 노드 명 성되어 있으며, 각각의 프로시저는 다음과 같은 외부 이벤트 내에서 읽는 값은 여전히 이전 값을 리턴한다. 따라서 특정 시 칭, 현 채널 인덱스, 현 네트워크 이름, 사용되고 있는 버스 유 의 종류에 따라 독립적으로 반응한다. 간에 오직 한 번의 값 변경이 발생하는 장점이 있다. 형을 포함한다. 해당 코드는 %FILE_NAME% 으로 포함하는 파일명에 접근하거나 %BASE_FILE_NAME% 을 사용하여 현 시스템에 의해 트리거되는 이벤트: 측정 시작 및 후처리에 필 실행 모델은 환경 종속적이다. 다양한 방식으로 CAPL 언어를 재 컴파일된 프로그램 파일명에 접근할 수 있다. include 파 요한 이벤트(예. on preStart, on start, on preStop, on stop- CANoe 및 CANalyzer에서 활용할 수 있기 때문에, 실행 모델 일의 경우, 후자가 상위 파일을 의미한다. 자세한 사항은 다 Measurement 등)와 시간 제어 및 키보드 이벤트(예. on tim- 도 종류가 다양하다: CANoe의 시뮬레이션 노드는 버스와 병 음 두 예제를 참조한다. Roman Marktl (Dipl.-Ing)은2012년부터Vector Informatik에서 er, on key 등)가 이 범주에 속한다. 렬로 구성되므로, 각 노드는 다른 노드에 종속되지 않는다. 트 CANoe와 CANalyzer의 Product Manager로 근무하고 있다. 리거된 이벤트는 항상 모든 프로그램으로 전송된다. 그에 반 write(“The node name”” is %NODE_NAME%”); @ 버스 통신에 의해 트리거되는 이벤트: 통신 혹은 오류 처 해, 측정 셋업과 CANalyzer 상에서의 노드는 순차적으로 처리 Ch%CHANNEL% = 1; 링크: 리와 관련된 버스 이벤트들에 반응하는 다양한 이벤트 프로 된다: 각 노드는 다음 노드로 출력 값을 전달한다. 새로운 이벤 벡터 홈페이지: www.vector.com 시저들이 존재하며, 이러한 이벤트 프로시저들은 버스 프로 트들은 추가 처리를 위해 반드시 바로 다음 노드로 전달되어 토콜에 의해 결정된다. (예. CAN: on message, on busOff 등; 야 한다. on * 및 on [*] 프로시저들이 그러한 용도로 제공된다. FlexRay: on frFrame, on frStartCycle 등) 코드 섹션의 조건부 컴파일링을 위해, #if, #else, #elif, #en- 또 다른 유형의 프로그램은 테스트 프로시저가 외부 이벤트를 dif 처럼 사정 정의된 별도의 매크로 세트가 있다. 프로그램 변숫값에 의해 트리거되는 이벤트: CANoe와 CANalyzer 대기할 수 있는 테스트 프로그램이다. CAPL은 이벤트의 시뮬 상에서, 해당 매크로는 프로그램 유형 시뮬레이션 노드, 측정 에 공통으로 사용되는 시스템 변수 및 환경 변수, 그리고 버 레이션 시간을 기준으로 프로세스 실행을 재개한다. 그에 반 노드, 테스트 프로그램, 사용되고 있는 CANoe 버전과 같은 스 통신의 데이터 분석에 해당하는 시그널 값이 이 범주에 속 해, 대기 중인 일반적인 이벤트 프로시저의 대기 상태는 전체 변수들을 구분한다. #pragma message를 사용하는 예시는 한다. 전용 데이터베이스에서 데이터 분석을 실행하게 되는 시뮬레이션 시스템을 정지시킨다. 이는 CAPL 사용 시 발견되 다음과 같다. 데, 이에 대한 자세한 내용은 본 자료의 3부에서 다루게 된 는 주요 오류이다. 따라서 외부 DLL 환경 하에서 wait 종류의 다. 명령을 사용하는 것은 바람직하지 않다. #if (TOOL_MAJOR_VERSION == 7 && TOOL_MINOR_ 이벤트 프로시저는 최소 단위이다: CANoe의 시뮬레이션 모 CAPL에서 효율적인 프로그래밍하기 VERSION == 5 && TOOL_SERVICE_PACK < 2) || CANA- 델은 이벤트를 기반으로 한다. 이벤트 프로시저의 경우, 프리프로세서는 C 언어를 활용할 수 있는 효율적인 툴이지만, LYZER #pragma message(“This program needs at least CANoe가 시뮬레이션 모델의 이벤트 실행 시점과 동시에 관 동시에 혼란을 일으켜 오류가 발생할 수도 있다. 따라서 잘 알 CANoe 7.5 SP 3”) 련 이벤트가 트리거 된다. 이때, 사용 PC 상에서의 실제 계산 려지고 의미상으로 일관성을 갖는 C프리프로세서 지시어들만 #endif 시간은 무시된다. 이 CAPL 상에 제공된다.
시뮬레이션 시간 및 타임 스탬프: output() 함수에 의한 버스 #include: include 파일에는 임의적이지만 CAPL 프로그램의 출력과 같은 PC에서 생성되는 실제 이벤트에는 real-time 모든 섹션(includes, variables 및 procedures)이 포함되어있다. #pragma message: #pragma message 지시어를 통해 사용 clock의 타임스탬프가 할당된다. 이러한 이벤트의 순서 및 시 C 언어와 달리, include 파일의 텍스트는 단순히 CAPL 파일에 자가 컴파일링 중에도 특정 메시지(예. 현재 컴파일링 중인 점은 버스 프로토콜, 드라이버 및 하드 웨어 속성에 따라 달 삽입되지 않고, 섹션 별로 삽입된다. include 파일의 모든 섹션 CAPL 프로그램의 버전 번호)를 출력할 수 있다. 또한, 라질 수 있다. 이 “마치” 상위 CAPL 파일에 포함된 것처럼 해당 CAPL 파일에 #pragma message 지시어는 컴파일러 메시지, 경고 메시지, 100% 적용된다. 이 때, CAPL에서 섹션의 순서는 무관하다. 따 오류 메시지 등과 함께 표시된다.. 가상 버스 상에서 영향을 미치는 파라미터 일부분은 제거된 라서 컴파일러는 모든 중복 기호를 오류로 보고한다. 게다가,
다. 이 경우, 버스 이벤트들은 동시에 개시된다. 예를 들어, Include 파일 및 상위 파일의 코드와 데이터가 서로 상호적으 CAN의 경우 output()에 의해 전송되는 복수의 메시지가 신 로 사용될 수도 있다. 이러한 중복 기호 오류가 발생하지 않는 뢰할 수 있는 아비트레이션(arbitration)을 거쳐 전송된다. 예외 경우는 on start, on preStart, on preStop 및 on stop
3/30 3/31 성능 대부분의 CAPL 프로그램은 반드시 실시간 조건을 충족 의하기 보다는, Variable 영역에서 대용량 변수를 전역 변수 시켜야 한다. CAPL를 이용해 시뮬레이션된 노드의 실행 모델 로 한번만 정의함으로써 훨씬 적은 메모리를 사용할 수 있다. ECU 테스트 효과적으로 프로그래밍하기 은 어떤 속도로든 CAPL 프로그램을 실행할 수 있는 모델 컨 각각의 메시지 ID 에 해당하는 이벤트 데이터를 저장하는 것 셉을 따른다(CAPL 활용의 기초, 팁과 트릭 2부 참조). 이를 달 과 같이 많은 배열을 생성하는 것은 바람직하지 않다. CAN CAPL 활용의 기초, 팁과 트릭 (3부) 성하기 위해, CAPL 프로그램이 컴파일링 된다. 즉, CAPL은 에서 확장된 ID는 29비트로 구성되므로, 5억개 이상의 변수 특정 실행 마이크로프로세서의 기계 언어로 컴파일링된다. 가 될 수 있다. 이러한 목적으로 배열을 정의하는 것은 메모 또한, 복잡한 신호 접속 과정을 거치기 위해 최적화된 코드 리 낭비가 될 수 있다. 시퀀스가 사용된다. 사용자가 성능에 영향을 끼칠 수 있는 방 마지막 세 번째 주제는 고급 사용자들을 위한 CAPL 사용 요령과 주의사항이다. 법은 다음과 같다. 따라서, 이런 경우에는 위에서 언급한 연관 배열을 사용하는 특히, 연관 배열, 성능, 메모리 요건, 기타 데이터베이스 접속 옵션에 대한 내용을 중점적으로 다룬다. 것이 바람직하다. 연관 배열에서 실제로 사용되는 키입력에 writeEx() 대하여 조금 더 많은 메모리가 필요하지만, 사용되지 않은 키 write 기능을 사용하여 특정 텍스트를 CANoe 및 CANalyzer 입력에 대해서는 메모리를 필요로 하지 않는다. 연관 배열 의 Write window로 출력할 수 있다. 상대적으로 용량이 큰 C 같은 언어와 달리, CAPL은 포인터 객체를 참조 데이터 형 for (long akey: lastTime) 데이터 출력 시, writeEx 기능을 대신 사용할 수 있다. 또한, 유용하지만 익숙하지 않은 기능 식으로 지원하지 않기 때문에 동적 메모리 관리 기능이 없다. {[…]} … writeEx 기능을 활용하여, Trace window 또는 로그 파일에 특 마지막으로, 익숙하지 않은 신규 기능에 대해 설명한다. C와 이러한 이유로 CAPL은 매우 신뢰성이 높고, 메모리가 부족하 정 텍스트를 직접 기록할 수도 있다. writeEx를 통해 출력된 유사하게, Struct 를 사용하여 구조를 정의할 수 있다. Struct 고 디버깅이 어려운 런타임 환경에 접합한 언어이다. 특히 데이터베이스 접속 텍스트는 높은 우선 순위의 프로세싱 및 실제 버스 이벤트와 내에서 Intel 및 Motorola 포맷 간의 변환이 가능한 복사 연 CANoe의 “CAPL-on-Board”는 이러한 CAPL 의 특성을 활용 CAPL 시리즈 1부에서 이미 버스에 특화된 CAPL 데이터베이 타임 스탬프 동기화를 포함하여, 버스 이벤트와 같은 방식으 산과 함께, Struct 는 데이터 변환을 위해 사용할 수 있는 유 하여, 실시간 작동 성능을 개선하기 위해, 특정 하드웨어 버 스의 주요 용도를 설명하였다. 이 데이터베이스를 통해 메시 로 처리된다. 연한 방식이다. 스 인터페이스 상에서 프로그램을 직접 실행한다. 반면, 지와 신호의 이름을 사용하는 것이 가능하다. 프로그래밍 관 Window 런타임 환경에서는 메모리 공급 부족 현상이 거의 점에서 보면, 신호의 복잡한 측면은 효율성을 이유로 신호가 이벤트 절차 CAPL 함수 호출 시, 사용자는 값 파라미터와 더불어 참조 파 발생하지 않는다. 따라서, 이러한 환경에서 CAPL은 프로그램 메시지의 데이터 페이로드 허용 범위 내에서 빽빽히 차 있는 CAPL 프로그램은 이벤트에 응답하는 절차들의 결합으로 구 라미터도 함께 전달할 수 있는 옵션을 가지게 된다. 참조 파 실행 시 저장 용량을 알 수 없더라도, 데이터를 저장할 수 있 것을 의미한다. 따라서, 신호는 일반적으로 임의의 비트 수를 성된다. 이 중 일부 이벤트는 매우 자주 발생하기 때문에, 만 라미터를 사용하여 함수로부터 하나 이상의 결과 값을 리턴 는 연관 배열 기능을 제공한다. 연관 배열이란 다른 프로그래 나타내며, 메시지의 데이터 페이로드 내의 위치를 나타낸다. 약 이러한 이벤트만 처리될 수 있다면, 해당 프로그램의 성능 할 수 있다. 또한, 참조 파라미터는 CAPL–DLL 내에서도 사용 밍 언어들과의 맵핑 혹은 동적 배열을 뜻한다. 내부적으로, 또한, 이 신호는 Intel 혹은 Motorola 포맷으로 저장이 가능 이 대폭 개선될 수 있다. 예를 들어, 사용자가 특정 신호가 포 가능하다. CAPL은 이러한 배열을 위해 효율적인 해시 테이블을 사용한 하다. 함된 FlexRay slots만 원할 경우, “on frSlot *” 대신에 “on 다. 따라서, 메시지의 종류나 얼마나 많은 측정값이 발생할 frSlot signalname“으로 정의하는 것이 효율적이다. CAPL 프로그램을 잘못 사용 시에도, 오류가 발생해서는 안된 지 미리 예상할 수 없더라도, 이러한 특수 배열을 통해 버스 CAPL 사용자는 신호의 이름을 이용하여 접근할 수 있으므로, 다. 이러한 견고성은 일반 포인터가 없기 때문에, 언어 구조 메시지 혹은 측정 값을 저장할 수 있다. 상기에 언급된 복잡한 절차를 거칠 필요가 없다. 신호 값을 신호 에지 를 통해 확보된다. 반면, 배열 최대치, 스택 최대치 및 필수 계 CAPL에서 연관 배열은 단순 배열로 정의되지만, 일반적인 데 읽거나 설정하는 경우, CAPL 컴파일러가 자동으로 해당 신호 신호 및 시스템 변수에 대한 두 가지 버전의 이벤트 절차가 산 시간에 대한 자동 런타임 점검을 통해 안정성은 향상된다. 이터 입력 대신에 키 입력이 가능하다. 다음에 두 가지 유형 의 마스킹, 스와핑 및 전환 비트 수와 같은 정확한 비트의 패 있다. 객체 값이 전혀 변하지 않더라도, on signal_update 및 의 연관 배열이 예로 제시되어있다. 턴을 처리한다. on sysvar_update는 특정 데이터 객체에 대한 쓰기 접근 시 컴파일러 별도의 명령 행 버전도 사용 가능한데, 이 버전은 호출된다. 반면, 신호 에지만 처리되는 경우, on signal_ 스크립트 언어에서 자동 정렬시 매우 유용하다. long lastTime [long]; 사용자 친화성을 향상시키기 위해, 데이터 베이스 내의 정의 change(on signal) 과 on sysvar_change(on sysvar)는 성능적 char[30] translate[ char[] ] 가능한 객체를 사용하여 CAPL 프로그래밍의 언어 능력을 향 인 이점을 제공한다. 이러한 이벤트 절차는 값 변경에만 반응 결론 변수 lastTime은 long 키로 구분되는 배열을 long type변수 상시킬 수 있다. 예를 들어, 신호 값 상태 별로 일반 텍스트 할 수 있도록 최적화되어 있다. 본 CAPL시리즈에서는 문제 지향적 프로그래밍 언어로서 로 맵핑한다. 그리고, 변수 Translate는 최대 30 문자로 제한 이름을 사용하기 위해 상징 값 테이블을 신호에 연결할 수 있 CAPL을 소개하였다. CAPL의 익숙한 C 언어 문법을 통해 사 된 string 키로 구분되는 배열을 string type 변수로 맵핑한 다. 또한, 데이터베이스 관리자는 다른 속성 객체를 정의하여 메모리 요건 용자의 학습 과정이 단순해 졌다. 특정 기호 데이터베이스, 다. 아래 예시에서 보는 것처럼, lastTime은 CAN 버스에 생 이를 프로그램 코드에 활용할 수 있다. C언어처럼 대부분의 블록 지향적인 언어와 달리, CAPL내에 시뮬레이션에서의 CAPL 이용, 실제 버스 노드들에 대한 에뮬 성된 각각의 메시지 ID를 위해 time 값을 저장한다: 서 지역변수로 정의된 모든 변수들은 기본적으로 정적 변수 레이션과 테스팅은 각 어플리케이션 영역을 지원한다. 벡터 CAPL은 해당 기호의 이름을 기준으로 직접 데이터베이스 객 이다. 즉, 프로그램 시작 시 모든 변수들이 생성되며, 이러한 는 다양한 응용 분야를 새롭게 개척하는 것과 동시에, 기존 on message CAN1.*{ 체를 사용할 수 있다. 단, 프로그램 구현 시, 잠재적인 대상 객 변수를 저장하는 메모리도 프로그램이 종료되기 전까지는 버전과 호환 가능한 방식으로 언어를 지속해서 확장하고 있 lastTime [this.id] 체가 알려지지 않는 경우도 종종 있다. 따라서, CAPL 사용자 초기화되지 않는다. 따라서, 많은 이벤트 절차가 실제로 공유 다. = this.time; 는 네트워크 노드를 통해 전송되는 메시지 이름이나 식별자 할 수도 있는 많은 양의 동일한 타입의 변수를 정의해야 할 } 와 같은 속성 및 기호 이름에 직접 접근해야 할 수도 있다. 경우, CAPL은 대용량의 메모리를 필요로 한다. (아래 예시 참 사용자 경험을 향상시키기 위해, CAPL은 점 표기법을 사용하 (예시 참조) 조) 여 다음과 같이 연관 배열 변수를 위한 방법에 대하여 리스 CAPL 트를 제공한다. message * m; testcase test789() CAPL은 벡터 인포마틱(Vector Informatik)이 개발한 C언어 • ContainsKey : 특정 키의 포함 여부를 조회한다. int i, mx; { 와 유사한 절차형 프로그래밍 언어이다. 프로그램 블록 실행 • Size : 포함된 키 개수를 리턴한다. mx=elcount(aNet::aNode.Tx); char outBuffer[1024]; 은 이벤트에 의해 제어된다. CAPL 프로그램은 전용 브라우 • Remove : 연관 배열에서 특정 키를 삭제한다. for (i = 0; i < mx; ++i) [..] 저 상에서 개발되고 컴파일링 된다. 이를 통해 데이터베이스 • Clear : 연관 배열을 초기화한다. { 에 수록된 모든 객체들(메시지, 시그널, 환경 변수) 뿐만 아 Remove 및 Clear는 메모리 공간을 확보한다. m.id=aNet::aNode.TX[i]; CAPL 프로그램은 수 많은 테스트 절차를 갖추고 있는데, 이 니라 시스템 변수에도 접근 가능하다. 또한, CAPL은 개발, 테 Ex) lastTime.clear( ); lastTime.remove( ); write(DBLookup(m).Name); 중 정해진 시간 내에 실행되는 절차는 오직 하나 뿐이다. 각 스트, 시뮬레이션 툴인 CANoe 와 CANalyzer 를 지원하는 마지막으로, 연관 배열을 위한 명령어 for의 특별한 유형이 } 각의 이벤트 절차에서 동일한 유형의 대용량 지역 변수를 정 다양한 종류의 사전 정의된 함수들을 제공한다. 있다. 이 유형은 lastTime 배열변수에 입력된 모든 키의 수만 사용자는 이러한 기호 접속 방법과 앞에서 소개된 연관 배열 큼 반복 실행한다. 기능을 활용하여 포괄적인 프로그램을 실행할 수 있다.
3/32 3/33 저자:
Marc Lobmeyer (Dipl.-Inf.) 은 1994년부터Vector Informatik 에서 CANoe와 CANalyzer의 개발자로 근무하고 있다.
Roman Marktl (Dipl.-Ing)은2012년부터Vector Informatik에 서 CANoe와 CANalyzer의 Product Manager로 근무하고 있 다.
링크: 벡터 홈페이지: www.vector.com
3/34 제어판 및 실행 시퀀스에 의한 시뮬레이션 상위 OSI 계층의 애플리케이션으로는 신호 패널 및 신호 생성기 를 예로 들 수 있다. 이러한 애플리케이션은 사용자 작업 및 동적 프로세스를 시뮬레이션하는 데 있어 반드시 필요한 보조 수단이 다. 또한 가상 스위치, 버튼 및 디스플레이 계기가 포함되어 있어 방향 지시, 앞 유리 와이퍼 또는 윈도우 리프트의 활성화와 같은 자발적인 동작을 컴퓨터 스크린에 편리하게 입력할 수 있다. 그 뿐 아니라 테스트를 실행하는 동안 사용자에게 시스템 파라미터 를 표시하며 신호 및 변수도 구체적으로 수정할 수 있도록 한다. 따라서 첨단 테스트 환경에서는 적절한 패널 편집 기능을 표준 기능으로 제공하여 사용자 제어를 통해 맞춤형 패널을 생성하며 데이터베이스 정보로 구성된 계기 또는 표준 패널(그림 2)을 표 시한다. 시뮬레이션 및 패널이 자동으로 생성되거나 신호 할당이 순조롭게 진행되면 다음과 같은 개념이 적용된다. 즉, 연관된 데 이터베이스에 관련된 네트워크, 메시지 및 속성이 더 세부적으로 기술될수록 생성기에서 생성하는 모델의 정확도가 높아지는 것 이다. 사전 구성된 패널은 신호 정보, 값의 범위 또는 심볼의 가 능한 모든 정보를 가져올 수 있는 장점이 있다. 그림 1: 통신 버스 시뮬레이션을 통해 실제 노드가 있는 네트워크에서 시 뮬레이션된 노드의 테스트 수행 패널에서는 자발적이면서 유연한 신호 조작은 허용하지만 테스 트 시퀀스, 사용자 입력 및 다른 이벤트의 재생과 같은 기능은 할 수 없다. 이러한 기능은 일반적인 프로그래밍 영역이다. 하지만 으며, 심지어 자동으로 생성할 수도 있다. 프로그래밍 노하우가 사용자들은 모든 프로젝트마다 강력한 프로그래밍 툴을 활용하 더 이상 절대적인 요소가 아닌 것이다. 프로젝트 참가자는 통신 는 것을 원치 않는 경우가 많다. 따라서 테스트 엔지니어들이 선 데이터베이스를 드래그 앤 드롭 방식으로 시뮬레이션 설정에 추 호하는 대안은 테스트 시퀀스를 테이블 형태로 생성하는 옵션이 포괄적인 통신 버스 시뮬레이션에 대한 신속한 접근 가하기만 하면 된다. 이 작업이 완료되면 개별 네트워크 노드의 다(그림 3). 이 테이블은 명령을 단순히 선택할 수 있도록 구성되 세부적인 기능을 수정할 수 있다. 여러 버스 시스템을 네트워크 어 있으며, 이러한 명령은 서로 다른 여러 테스트 애플리케이션 전문적인 프로그래밍 지식 없이 가상 네트워크 생성 노드 하나에 할당할 수 있는데, 이는 게이트웨이와 좀 더 까다로 에서 해당하는 작업을 완벽하게 수행한다. 또한 값을 설정하고 통신 버스 시뮬레이션을 개발하는 일은 ECU 개발에서 핵심 과제이다. 이를 통해 기능적인 환경을 ECU에 적용할 수 있는데, 이렇게 운 ECU를 신호 인가하는 데 있어 중요한 역할을 한다. 대기 시간을 정의하며 신호를 수정하고 이벤트를 트리거하는 데 하지 않으면 포괄적인 테스트를 수행하기란 거의 불가능하다. 개발자의 과제는 제약 조건을 고려하여 실제와 유사한 통신 버스 사용된다. 이러한 접근 방식은 특별한 지식이나 엄청난 교육이 시뮬레이션을 신속하게 생성하는 일이다. 적절한 툴을 활용하면 프로그래밍 없이 기본적으로 드래그 앤 드롭만으로도 통신 버스 통신 버스 시뮬레이션에서는 OEM별 메타 데이터 및 전송 모델 필요한 것이 아니며 재생 가능한 소규모 테스트만으로 원하는 결 시뮬레이션을 생성할 수 있다.. 을 고려하는 일이 핵심적인 역할이다. 여기서 상호 작용 계층이 과를 신속하게 얻을 수 있다. 개입하게 되는데, 이는 상호 작용 계층이 관련된 OEM의 정의된 전송 행동을 나타내기 때문이다. 상호 작용 계층은 전송 모델에 까다로운 테스트 및 시뮬레이션에 적합한 성능 따라 각각의 메시지 유형에 대해 메시지 카운터 및 CRC 계산 등 시뮬레이션 및 테스트 시스템이 규모가 큰 테스트 시나리오를 효 통신 버스 시뮬레이션의 목적은 개별 네트워크 노드 시뮬레이션 의 예로 벡터(Vector)의 CANoe 시뮬레이션 및 테스트 시스템이 의 보호 메커니즘을 올바르게 생성한다. 상호 작용 계층은 상위 과적으로 지원한다면 요즘은 아무리 큰 규모의 테스트 시나리오 에서부터 전체 네트워크 시뮬레이션에 이르기까지 다양하다. 기 있다. 애플리케이션의 신호 기반 액세스를 버스 시스템의 메시지 기반 라도 전통적인 방식으로 프로그래밍할 필요가 없다. 예들 들어 술적인 관점에서 보면 OSI(Open Systems Interconnection) 모델 전송으로 변환한다. 또 다른 중요한 점은 OSEK-NM 및 버스별 일반적인 경우에 대하여 시뮬레이션 및 평가 기능의 설정에서 의 모든 계층에 걸쳐 ECU의 인프라를 시뮬레이션하는 것이 목적 프로그래밍이 없이 구성 AUTOSAR-NM과 같은 다양한 유형의 NM(Network Manageent) 결과 분석, HTML 문서화 및 그래픽 출력 준비에 이르기까지 모 이다. 이렇게 하려면 통신 계층부터 네트워크 관리 계층, 전송 계 최신 테스트 및 시뮬레이션 시스템은 개별 테스트의 갖가지 복잡 을 지원한다는 점이다. 든 단계를 지원하는 테스트 패턴이 준비되어 있다. 중요한 세부 층, 그리고 마지막으로 애플리케이션 계층에 이르는 모델링을 수 한 문제뿐만 아니라 통신 버스에 대한 다양한 유형의 생성 방식( 사항은 그래픽 평가 창에 표시된다. 예들 들어 CANoe의 State 행해야 한다. 구현 과정에서 고려해야 할 측면 및 작업 영역도 다 자동화, 수동화, 프로그램화)을 지원해야 한다. 예를 들어 이는 개 Tracker의 색 강조 표시 기능을 사용하면 상태, 이벤트 및 상태 양하다. 여기에는 CAN, LIN, FlexRay 및 MOST 버스 인터페이스 발자가 한 개 또는 몇 개의 시스템 기능을 테스트하기 위한 소규 변화를 신속하게 감지할 수 있다(그림 4). 이러한 유형의 표시는 에 적합한 하드웨어를 선택하고, 상위 레벨에서 MATLAB/Sim 모 시뮬레이션을 수행해야 하는지 또는, 최종 제품 개발 단계에 자동차 네트워크 또는 ECU용 Art Logic Analyzer를 통해 구현 ulink 모델을 통해 ECU의 기능을 시뮬레이션하는 작업이 포함될 서 종합적이고 세부적인 전체 테스트를 수행해야 하는지 여부에 된다. 수 있다. 시뮬레이션되는 통신 버스는 테스트 대상 시스템으로부 따라 큰 차이가 생긴다. 통신 버스 시뮬레이션의 주요 데이터 소 터 메시지를 수신하고, 메시지에 동적으로 대응하며, 결과를 메 스는 DBC(CAN), LDF(LIN), FIBEX(FlexRay) 데이터베이스 또는 기 앞서 언급한 것처럼 통신 버스 시뮬레이션에서 처리할 수 있는 시지의 형태로 ECU로 다시 보내야 한다(신호 인가). 최종 분석에 능 카탈로그(MOST)에 저장되는 다양한 버스 시스템의 통신 데이 복잡함에 대해 정의할 수 있는 상한선이 거의 없다고 볼 수 있다. 서의 통신 버스 시뮬레이션은 목적 달성을 위한 한 가지 수단에 터이다. 여기에는 CDD 및 ODX와 같은 진단 정보도 통합된다. 또 각기 다른 많은 요구 사항을 개별적으로 충족하려면 테스트 및 불과하다. 한 AUTOSAR 시스템 정보와 같은 단일 데이터베이스로부터 모 시뮬레이션 시스템이 확장성 및 모듈성 같은 속성을 갖춰야 한 든 데이터를 가져올 수 있다. 다. 버스 인터페이스의 광범위한 지원 외에 자체적인 연산력 등 또한, 고성능 개발 및 테스트 시스템에는 생성된 테스트 결과를 개발자들은 이제 적절한 구성 보조 기능과 이러한 데이터베이스 그림 2: 표준 패널을 통해 사용자가 신호 값을 양방향으로 수정할 수 있 을 갖춘 지능형 하드웨어 인터페이스가 실시간 요구 사항의 증가 다. 평가하고 문서화하는 기능이 항상 포함되어 있다. 이러한 시스템 의 도움을 받아 간편하게 통신 버스 시뮬레이션을 생성할 수 있 로 인해 중요성이 점차 커지고 있으며, 이러한 인터페이스를 통
3/36 3/37
6/2 다. 시뮬레이션 또는 흐름 제어는 신호 패널, Visual Sequencer( 독일 출판물 Automobil Elektronik 2012년 3월호 기사 번역판 그림 3), 상위 레벨 프로그래밍 언어(.NET API 활용) 또는 신호 기 반 CAPL 언어를 사용하여 구현할 수 있다. 복잡한 테스트 설정의 이미지 권리: 경우 통합된 Test Feature Set는 신호 인가, 평가, 결과 분석 및 Vector Informatik GmbH HTML 문서화를 위한 준비된 테스트 패턴을 제공한다. 또한 MATLAB/Simulink 모델의 통합과 같은 고급 기능이나 연결된 센 링크: 서 및 엑추에이터를 시뮬레이션하는 보완형 하드웨어를 통한 확 벡터 홈페이지: www.vector.com 장 가능성을 바탕으로 중간 규모의 HiLs(Hardware-in-the-Loop) CANoe 제품 정보: www.vector.com/canoe 영역으로 확장되는 기능을 구현할 수 있다. Stefan Albrecht 2003년부터 벡터 인포매틱(Vector Informatik)에서 근무하였으며 현재 전망: 통신 버스 시뮬레이션 및 전기 이동성 CANoe/CANalyzer 중앙 제품 관리 팀의 제품 관리를 담당하고 있다. 미래에는 통신 버스 시뮬레이션이라는 주제가 전기 이동성 부문 에서도 중요해질 것이다. 최근 몇 년간 이 부문이 역동적으로 발 전함에 따라 부분적인 네트워크 운영의 시뮬레이션을 통해 네트 그림 3: Visual Sequencer를 통한 시뮬레이션 및 테스팅에 사용되는 명령 워크를 관리하는 데 중점적으로 노력하고 있다. 이는 전기 자동 Peter Decker 시퀀스를 그래픽으로 생성하기 위해 어떠한 프로그래밍 지식도 필요하 차가 주차 중인 시간은 곧 충전 중인 상태이기 때문이다. 이 과정 2002년부터 벡터 인포매틱에서 근무하였으며 현재는 CANoe/CANa 지 않다. lyzer 멀티 버스 개발 팀의 제품 관리를 담당하고 있다. 에서 특정 ECU는 확실하게 전원을 끊어야 하는 반면 다른 컴포 넌트는 충전이나 모니터링을 위해 활성화된 상태를 유지해야 한 다. 부분적 네트워크 운영이라는 주제를 AUTOSAR 3.2.1에 비해 해 시간이 중요하게 고려되는 프로세스를 실행할 수 있다. 또 다 AUTOSAR 4.0에서 더 우선 순위에 두고 있는다는 것은 오늘날의 른 과제로는 유효하지 않은 메시지의 형태로 특정 오류를 발생시 전기 이동성이 갖는 중요성을 여실히 보여 주는 부분이다. 키거나, 유용한 데이터를 손상시키거나, 통신 버스를 물리적으로 교란시키는 것인데, 이는 그러한 상황에 대한 ECU 반응을 연구 하는 데 목적이 있다. 최신 테스트 및 시뮬레이션 툴은 소프트웨 어 및 하드웨어에 구현된 특수한 응력 함수를 통해 이러한 기능 을 제공한다.
CANoe를 통한 통신 버스 시뮬레이션 벡터의 CANoe와 같은 종합적인 테스트 및 시뮬레이션 툴은 단 순한 테스트 설정에서 포괄적인 테스트 설정에 이르는 모든 테스 트 설정에 대한 통신 버스 시뮬레이션의 모든 측면을 제어한다. 특히, 필요한 시뮬레이션 모델을 프로그래밍할 필요 없이 간단한 설정을 통해 수동 또는 자동으로 신속하게 생성할 수 있도록 한 다. 이러한 툴은 일반적으로 사용되는 모든 데이터 형식, 진단 정 보 및 메타 데이터를 처리하고 수 많은 OEM별 패키지로 자동차 산업을 지원할 수 있어야 한다. 메시지, 신호 및 심볼 기호에 액 세스하기 위한 많은 옵션을 통해 ECU 개발자의 업무가 간소화된
그림 4: State Tracker가 시간 축에 걸쳐 시스템 상태 및 개별 값을 그래픽으로 나타냄
3/38 3/39
6/4 평가해야 한다. 준비된 정보를 통해 오류의 원인을 매우 신속하 하며, 이를 통해 다음을 수행할 수 있다. 고 정확하게 파악할 수 있으며 결함 부품을 교체할 수 있다. > 해당 환경 데이터와 함께 개별 트러블 코드를 읽고 테스트 보 고서에서 이를 검사 및 문서화. 필요할 경우, 허용되는 트러블 폴트메모리 기능 테스트 코드 조합 또는 대체 코드 표시 가능 폴트메모리의 한 가지 강점은 차량에서 오류 상태를 감지하기 위 > 특정 상태 마스크가 있는 모든 트러블 코드 읽기 해 해당 알고리즘을 제공한다는 점이다. 하지만 이는 차량의 진 > 폴트메모리 제거 단 기능이 자체적으로 올바르게 작동하고 있는 경우에만 가능하 > 지원되는 트러블 코드 읽기 다. 그러므로 이 기능은 차량 개발 단계에서 철저히 테스트 되어 > 폴트메모리 상태 읽기 야 한다. 기존 트러블 코드가 매우 많고 광범위한 환경 데이터 및 오류 상태가 있으면 진단 기능 테스트가 매우 복잡해질 수 있다. TAE의 테스트 기능은 직관적으로 사용할 수 있으며, CANoe에서 이런 경우에 특히 복잡한 이유는 진단 요청의 파라미터가 반드시 는 통해 올바른 OEM 별 진단 서비스를 자동으로 선택한다. 이러 설정되어야 하기 때문이며, 각 테스트에서는 응답 파라미터가 확 한 자동 선택 기능 덕분에 테스트 시퀀스를 다른 ECU에서도 쉽 인되어야 한다. 그러나 이러한 과정은 테스터가 추상적 관점을 게 재사용할 수 있고 전체 시퀀스를 생성하기도 훨씬 쉬워진다. 취함으로써 상당히 간소화될 수 있으며, 이를 통해 사용자가 오 따라서 사용자는 실제 테스트 목적에 집중할 수 있어 매우 효율 류 항목을 설정, 확인, 검색 등의 통상적인 작업을 완전히 숨길 수 적으로 작업을 수행할 수 있다. 있다. 그림 2에서는 폴트메모리에 액세스하는 방법을 보여 준다. 실행 폴트메모리에 로그인된 상황으로 유도(그림 1)한 후 UDS 관련 도중 원하는 “DTC 상태 마스크”를 입력하면 ECU의 폴트메모리 양상을 모두 숨기고 진단 응답을 자동으로 확인할 수 있는 테스 가 폴링된다. 이 응답은 모든 시퀀스의 다양한 트러블 코드를 포 트 기능이 있다면 매우 유용할 것이다. 이러한 기능을 사용하면 함할 수 있으며, 트러블 코드 P000004가 보고되었는지 여부를 확 “트러블 코드 XYZ의 환경 데이터 읽기, 환경 데이터가 활성화되 인한 후, 해당 트러블 코드가 발견되면 상태 비트가 “Failed since 어 있는지 확인, 오류가 발생할 경우 11.5~12.5V의 전압인지 확 last clear”로 설정된다. 그림 2의 오도미터 읽기에서 나타난 것처 인” 등의 작업을 수행할 수 있으며, 이 기능의 테스트 코드는 매 럼 각 트러블 코드는 환경 데이터와 연관되어 있으며, 매우 쉽게 우 간결하고 정확할 것이다. 확인된다. 이 테스트 기능을 통해 제어되는 시퀀스는 복잡하지만 파라미터 폴트메모리를 통한 효율적인 ECU 테스트 폴트메모리로의 효율적인 액세스 설정은 손쉽게 수행된다. 하지만 전용 폴트메모리가 지원되지 않 앞에서 설명한 추상화 레벨(abstraction level)은 TAE(Test Auto- 는 기존 프로그래밍 언어에서 이와 동일한 기능을 구현하려면 상 차량 진단은 차량 개발 단계에서는 물론 사용 기간 중에도 중요하지만 복잡한 문제이다. 개발 및 서비스 부서는 믿을 수 있는 정확 mation Editor) 테스트 설계 툴과 결합된 CANoe 테스트 툴을 통 당한 노력이 필요하다. 한 데이터가 항시 사용 가능한 경우에 진단에 소요되는 시간을 최소화할 수 있다. 또한, ECU와 해당 ECU의 진단 기능 개발 품질을 해 제공될 수 있다. 이 두 가지 툴은 벡터(Vector)의 소프트웨어 높이기 위해서는 적절한 테스트 툴이 필요하다. 본 기사에서는 오류의 원인을 신속하고 확실하게 방지하기 위해 사용되는 테스트 툴 제품으로서 UDS 및 KWP 2000 프로토콜을 모두 지원한다. 폴트메모리 - 미지에 둘러싸인 수수께끼는 아니다 및 방법에 대해 다룬다. 또한, 폴트메모리를 테스트하기 위한 많은 테스트 기능들을 제공 결국, 1차적인 목적은 차량을 결함이 없고 견고한 상태로 유지하
완성도 높은 차량을 위한 우수한 진단 기능의 중요성은 결함이 트러블 코드는 “배터리 전압 - 전압 매우 낮음”과 같은 OEM별 오 최종적으로 해결될 때까지 수차례의 시도가 필요했던 무수한 관 류 원인을 식별한다. 또한, UDS 표준은 “구동 장치”와 같은 특정 련 보고서를 통해 확인할 수 있다. 이러한 결함은 불필요한 비용 트러블 코드 그룹을 정의한다. 각 트러블 코드에서는 8비트 상태 과 수고를 초래하며, 제조업체의 이미지를 훼손한다. 그렇기에 마스크를 통해 오류 발생 여부는 물론 발생 시기(예: “전력 상승 결함이 있는 경우 이를 신속하고 정확하게 수리해야 한다. 후 테스트 불합격”)를 알 수 있다. 추가적인 세부 사항도 선택적 환경 데이터로 저장할 수 있다. 이 데이터는 OEM 별 데이터로서 폴트메모리(Fault Memory)는 부품 고장이 발생하지 않도록 미리 오류 발생 횟수와 발생 시점 등의 유용한 측정 데이터를 기록한 이상 유무를 기록한다. 서비스 부서에서는 정기적인 차량 유지 다. 보수를 통해 바람직하지 않은 결과가 일어나기 전에 결함을 감지 하고 수리할 수 있다. 오류는 테스트 및 시험 단계에서 더 빈번하 차량 운행 도중 각 ECU는 해당 폴트메모리에서 발생한 오류 상 게 발생하기 마련이므로 제품 개발 단계에서도 진단 기능은 중요 태를 수집한다. 적절한 툴을 통해 진단 서비스를 사용하여 이 메 하다. 적절한 차량 데이터는 더욱 쉽게 진단을 수행할 수 있도록 모리에 액세스할 수 있는데 일반적인 요구 사항은 다음과 같다. 도와주며, 별도의 테스트 기기조차 필요하지 않게 해 주기도 한 > 특정 상태 마스크에 적합한 모든 트러블 코드 보고 다. 따라서 폴트메모리에서 오류 상태를 올바르게 기록하는 것은 > 특정 트러블 코드의 상태 및 환경 데이터 읽기 매우 중요하다. > 그룹 또는 개별 트러블 코드의 상태 및 환경 데이터 제거
폴트메모리의 기능적 원리 T서비스 부서 테스터가 진단 요구 사항을 생성하여 ECU에 보내 그림 1: 본 기사에서는 폭넓게 사용되는 UDS(Unified Diagnostic Ser- 면, ECU는 진단에 대한 응답을 회신한다. 이 응답에는 대개 트러 왼쪽: 개발 단계의 폴트메모리 테스트 - vice) 표준 ISO 14229 기반의 결함 진단용 데이터에 대해 설명한 블 코드, 관련 상태 마스크 및 환경 데이터를 비롯한 여러 가지 오른쪽: 차량 운행 동안 항시 차량 진단용으로 사용되고 있는 폴트메모리 그림 2: TAE를 통한 폴트메모리 테스트 다. UDS 표준의 핵심 요소는 24비트 트러블 코드인데, 대부분의 오류 메시지가 포함된다(그림 1). 그런 다음에는 모든 데이터를
3/40 3/41 6/2 는 것이다. 폴트메모리를 사용하면 차량 문제 발생 시 초기에 이 를 감지하고 해결할 수 있다. 따라서 폴트메모리를 사용한 적절 한 자가 진단이 개발 초기부터 광범위한 테스트를 통해 이루어져 야 한다. 테스트 설계 및 실행 툴을 사용하면 이러한 확인 절차를 직관적인 추상화 레벨에서 복잡하지 않고 효과적으로 설정할 수 있다. 이렇게 하면 폴트메모리를 통해 평소 주행 중 차량 고장이 발생하기 전에 해당 문제들을 조기에 감지할 수 있게 된다.
독일 출판물 “Elektronik automotive”, 2013년 2월 수록 기사 번 역판
이미지 권리: Vector Informatik GmbH
링크: 벡터 홈페이지: www.vector.com
Martin Huck 독일의 보훔(Bochum) 소재 루르 대학교(Ruhr- University)에서 전기 공 학을 전공한 후 수년 동안 통신업계에서 개발 엔지니어로 근무하였다. 2012년부터는 벡터에서 CANoe Test Feature Set의 소프트웨어 개발 업무를 진행했으며 현재 기술 교육 담당자로 근무 중이다.
Siegfried Beeh 독일의 보훔(Bochum) 소재 루르 대학교(Ruhr- University)에서 전기 공 학을 전공한 후 수년 동안 통신업계에서 개발 엔지니어로 근무하였다. 2012년부터는 벡터에서 CANoe Test Feature Set의 소프트웨어 개발 업무를 진행했으며 현재 기술 교육 담당자로 근무 중이다.
3/42 손쉬운 CAN 네트워크 분석
네트워킹 ECU와 관련한 요구 사항이 끊임없이 변화하고 있다. 나날이 복잡해져 가는 작업으로 인해 이를 처리하기 위한 툴 또한 점 추가하기만 하면 된다(그림 2). 경우에 따라 보드 레이트(Baud 링크: 점 복잡해져 가고 있는데, 빠르게 처리할 수 있는 간단한 작업들도 툴에 포함된 기능이 너무 많다 보니 오히려 사용하기 번거로운 경 rate)도 구성되며, 이후 사용자가 수행해야 할 작업을 선택하면 Vector 홈페이지: www.vector.com 우도 있다. 이러한 간단한 작업에서는 조작이 쉬우면서도 필요에 따라 다양한 기능도 사용할 수 있는 툴이 요구되고 있다. 된다. 예를 들어 측정 중에는 Trace 윈도우가 메시지 또는 채널의 CANalyzer 제품 정보: www.vector.com/canalyzer 필터를 차단하거나 전달하는 등 특정 이벤트를 필터링하기 위한 여러 가지 옵션을 제공한다. 더구나 Trace 윈도우는 매우 긴 데이 터 내역을 제공하므로, 며칠에 걸친 장기적인 측정도 전부 보존 저자: 이러한 불편은 버스 모니터링, 신호 인가, 데이터 로깅 등 일반적 CANalyzer Beginner는 CANalyzer(CAN 및 LIN 버스용)가 설치되 할 수 있다. Statistics 윈도우는 버스의 현재 상황에 대한 자세한 인 작업에서 발생한다. 예를 들어 모니터링의 경우에는, 필요로 어 있다면 즉시 사용할 수 있다. 별도의 툴을 구매하거나 설치할 요약을 제공하며, 노드 레벨 또는 심지어 메시지 레벨에서 통계 하는 정보에 따라 버스 상의 데이터 트래픽에 대해 중요시 하는 필요가 없으므로 시간과 비용이 절약된다. Beginner 모드는 완전 정보를 준비할 수 있다. 점이 다를 수 있다. 여기에서 Trace 기능은 모든 버스 이벤트의 히 바뀐 CANalyzer의 윈도우 레이아웃의 이점을 충분히 보여준 타임 시퀀스(Time sequence)를 보여 준다. 개별 파라미터를 그래 다. 고정된 바탕 화면에 따로 수정할 필요가 없거나 미리 구성된 복잡한 작업을 수행해야 하는 경우에도 아무런 문제가 없다. Be 픽으로 표시하는 것도 가능하다. 또한, 사용자는 일반적으로 버 윈도우를 이미 포함하고 있는 개별 작업이 정리되어 있다(그림 ginner 모드에서 생성한 구성을 CANalyzer에서 완벽하게 로드할 스 통계에 대한 개요를 원하는 경우가 많다. 반면에 신호 인가에 1). 따라서 수동으로 구성하느라 시간을 허비할 필요가 없다. 윈 수 있다. CANalyzer를 사용하여 로깅된 데이터에 대한 추가적인 서는 자발적 또는 주기적으로 특정 메시지를 버스에 전송해야 한 도우의 위치가 고정되어 있기 때문에 중요한 부분에 쉽게 집중할 오프라인 분석을 수행하는 것도 가능하다. CANalyzer Beginner 요흔 노이퍼 (Jochen Neuffer) 다. 물론 데이터는 나중에 이루어질 오프라인 분석을 위해 로깅 수 있다. 또한, 윈도우를 닫을 수 없기 때문에 잘못 닫힌 윈도우 에슬링겐 응용 과학 대학교(University of Applied Sciences Es 되어야 한다. 를 찾느라 소비하는 시간도 없어진다. 윈도우는 드래그 앤 드롭 slingen))에서 통신 엔지니어링을 전공했다. 2002년부터 벡터 인 또는 툴바 기능을 이용하여 손쉽게 구성할 수 있다. 포매틱(Vector Informatik)에서 근무하고 있으며, 현재 네트워크 앞에서 언급된 세 가지 핵심 업무는 벡터(Vector)의 CANalyzer 및 분산형 시스템 툴 분야의 제품 관리 엔지니어로 일하고 있다. Beginner 모드를 통해 작업할 수 있다. 이 모드는 가장 기본이 되 또한, 윈도우를 닫을 수 없기 때문에 잘못 닫힌 윈도우를 찾느라 는 핵심 작업에 초점을 맞춘 만큼 신규 사용자도 손쉽게 조작할 소비하는 시간도 없어진다. 윈도우는 드래그 앤 드롭 또는 툴바 수 있다. 개별 작업 영역을 결합할 수 있으며, 사용자가 원하면 언 기능을 이용하여 손쉽게 구성할 수 있다. 제든지 각 작업 영역을 새로이 추가하거나 제거할 수 있다. CAN 몇 번의 마우스 클릭만으로 자신만의 구성을 만들 수도 있다. 이 alyzer의 모든 기능이 처음부터 표시되지는 않지만 언제든지 불 를 위해 사용자는 각 버스에 대한 채널과 적절한 네트워크 설명 러올 수 있기 때문에 빠르고 효율적인 작업이 가능하다. 파일(CAN의 경우 DBC, LIN의 경우 LDF)을 중앙 구성 윈도우에
그림 2: CANalyzer Beginner에서 새 구성 만들기
에서 CANalyzer로의 전환은 물론, CANoe로 전환하는 경우에도 마찬가지로 수월하다. CANalyzer Beginner로 만든 구성을 CANoe에서도 로드할 수 있기 때문이다. 향후에는 CANalyzer 그림 1: 버스 모니터링 작업을 위한 고정된 구성의 바탕 화면 Beginner에서 추가적인 작업을 지원하는 방향과 CANalyzer에 컨셉을 병합시키는 방향이 논의되고 있다.
3/44 3/45 1 신에 추가할 수도 있다. 로깅 후 데이터는 대개 CANoe, CANa 로깅 중 분류 표 만들기’로 설명할 수 있다. 먼저 데이터베이스의 lyzer 또는 CANape와 같은 프로그램에서 분석할 수 있도록 PC에 Speed 및 Brake의 심볼 시그널이 LTL 코드로 자동 변환된다. 그러 서 변환된다. 면 테스트 엔지니어는 CLASSIFY operator를 통하여 분류를 위한 보충 코드를 추가하기만 하면 된다. 테스트 플릿 차량을 위한 특수 데이터 로거 VAR Speed = CAN1 DATA 200h [2 3] 언뜻 보기에는 차량 내 로깅에 노트북 기반 솔루션을 사용하는 Brake = CAN1 DATA 100h [3(0)] 것이 합리적으로 보인다. 적절한 네트워크 인터페이스를 갖춘 노 CLASSIFY 트북을 사용하면 로깅 기능을 소프트웨어로 구현할 수 있기 때문 MyClassify COUNT (Brake) 에 필요한 모든 기능을 제공할 수 있다. 하지만 시판되고 있는 노 OVER Speed (20 CLASSES OF 10 BASE 0) 트북은 요구되는 온도 범위를 처리할 수 없으며, 시스템이 먼저 이 예에서 변수 Speed 값은 20여 개의 클래스(km/h 단위)로 정 부팅되어야 하고, 고속 노트북이라 하더라도 부팅에는 어느 정도 의된다. 각 클래스의 범위는 10km/h이며 0km/h가 첫 번째 클래 시간이 소요된다. 이는 빠른 스타트업 시간이 데이터 로거에 대 스의 시작 값으로 설정된다. 그러면 다음과 같은 클래스 분포가 한 또 다른 요구 사항임을 나타낸다. 즉, 버스의 첫 번째 메시지 만들어진다. 를 로깅하기에 충분히 빠른 속도로 스타트업 되어야하며 데이터 를 수집할 수 있어야 한다. 벡터(Vector)의 GL3000/GL4000 로거 제품 라인에 포함된 디바이스(그림 1)와 같은 특수 플릿 로거는 Class Value range [km/h] 위에서 언급된 모든 요구 사항을 충족한다. 이러한 제품은 작동 온도 범위가 넓기 때문에 극단적인 환경에서도 사용할 수 있다. 1 0 - 9 또한 이러한 특수 플릿 로거에는 실시간 클럭이 있으므로 정확한 데이터 수집 시간의 확인이 가능하다. 2 10 - 19
데이터 처리 …. …. 이러한 로거는 시험 주행시에 수신 데이터의 용량을 줄이기 위해 사용자가 미리 정의한 이벤트에 대해서만 로깅을 시작할 수 있 19 180 - 189 시험 주행 중 완벽한 데이터 로깅 다. 트리거식 로깅에서는 데이터가 계속해서 링 버퍼(Ring Buf fer)에 기록되다가 트리거 이벤트가 발생하면 이 링 메모리가 닫 20 190 - …. 데이터 로거를 통한 신뢰성 높은 차량 데이터 수집 히고 데이터가 저장된다. 그런 다음 새 링 메모리에서 로깅이 재 개된다. 이 방법을 적용하면 지속적인 로깅에 비해 데이터 용량
이 대폭 줄어든다. 링 버퍼의 설정에 따라 로깅된 데이터는 트리 자동차에 다양한 버스 시스템이 적용되면 문제 해결 및 분석에 필요한 작업이 항상 증가하게 마련이다. 이제 실험실 테스트만으로 각 분류 작업의 데이터는 나중에 편집할 수 있도록 MS® Excel과 거 이전 시간은 물론 트리거 발생 이후의 시간(설정 가능) 에 대 는 전체 자동차 시스템에서 이루어지는 통신과 관련된 실제 상황을 충분히 시뮬레이션할 수 없는 상황에 이르렀다. 즉, 실제 환경에 같은 프로그램으로 손쉽게 읽을 수 있는 텍스트 기반 결과 표에 하여도 사용할 수 있다. 링 버퍼는 대개 특수한 설정 소프트웨어 서 광범위한 시험 주행을 수행해야만 필요한 테스트 세부 수준을 달성할 수 있는 것이다. 테스트 플릿에서 차량에 설치되는 데이터 저장된다. 를 통해 구성된다(그림 2). 로거는 모든 버스 및 특정 I/O 회선의 데이터 트래픽을 로깅하는 데 널리 사용되는 툴이다. 이 툴은 품질 보증 관련 작업 중 언제든 지 시험 주행 데이터에 접근할 수 있게 해 준다. 요약 특수 스크립트 언어인 LTL(Logger Task Language)을 사용하면 복 현재 다양한 종류의 많은 데이터 로거가 출시되어 있다. 하지만 잡한 로깅 작업을 처리할 수 있다. 이는 간단한 프로그래밍 예인 ‘ 자동차 분야의 가혹한 작동 환경에 적합한 제품은 플릿 로거뿐이 자동차에 대한 면밀한 테스트는 대개 양산되기 직전인 시험 주행 이 소요될 수 있기 때문에 정지 상태에서 매우 낮은 전류 소모량 단계에서 이루어진다. 테스트 적용 범위를 최대한 넓히기 위해 을 나타내야 하는데, 이 역시 데이터 로거의 또 다른 요구 사항이 이러한 테스트 중 일부는 극단적인 환경 조건에서 수행된다. 다. 그뿐만 아니라 이러한 디바이스는 첫 번째로 발생하는 메시 -30°C의 핀란드에서 수행되는 혹한 테스트나 50°C가 넘는 데스 지도 로깅할 수 있도록 가능한 한 빨리 작동 준비 상태를 갖춰야 밸리(Death Valley)에서 실시되는 혹염 테스트 또는 습도가 높고 한다. 길이 험한 브라질의 우림을 관통하는 일주일 간의 운전에서도 자 동차와 모든 부품은 끝까지 원활하게 작동해야 한다. 마찬가지로 로거는 보통 영구적으로 설치될 뿐 아니라 좌석 아래 또는 화물 자동차에 설치된 데이터 로거도 이러한 열악한 조건을 견딜 수 칸의 트림 패널 뒤와 같이 매우 접근하기 어려운 지점에 장착되 있어야 하는데, 이를 위해서는 높은 기계적 내구성과 다양한 온 는 경우가 많으며, 다른 기계 장치 때문에 접근하지 못할 수도 있 도에서 안정적으로 작동하는 특성을 갖추고 있어야 한다. 다. 따라서 테스트 엔지니어가 UMTS 또는 WLAN 무선 연결을 사 용하여 로거에서 데이터를 읽을 수 있으면 상당한 이점이 된다. 승용차나 상용차에는 CAN, LIN 및 FlexRay 등의 다양한 버스 시 이에 대한 대안으로, USB를 이용하거나 메모리 미디어를 교환하 스템이 사용되는데, 여기서 이러한 모든 버스의 데이터는 동시에 여 데이터를 직접 읽을 수도 있어야 한다. 이후의 오프라인 분석 즉, 시간상 동기화하여 로깅되어야 한다는 한 가지 기술 요구 사 및 문제 해결을 위한 시험 주행 시 나타나는 특정 오류 패턴을 명 항이 적용된다. 이때 로거는 버스 트래픽에 영향을 주지 않고 관 확하게 추적하기 위해서는 운전자가 시험 주행 중 음성 설명과 그림 1. 차량 내부용 특수 데이터 로거는 내구성이 뛰 찰만 할 수 있어야 한다. 데이터 로거는 테스트 플릿 차량에 영구 카메라 이미지를 기본 로깅 데이터와 함께 기록할 수 있어야 한 어날 뿐 아니라 실용적이고 효과적인 인터페이스를 갖추고 있다. 적으로 설치되는 경우가 많으며 일련의 테스트에는 몇 주의 기간 다. 이와 동시에 지리적 기준으로 삼도록 GPS 데이터를 버스 통
3/46 3/47
6/2 그림2. 벡터 로거 설정 프 로그램(Vector Logger Configurator)에서의 트리 거 구성
다. 로거는 시험 주행 시 오늘날의 자동차 요구 사항을 대부분 지 원하는 광범위한 기능을 제공해야 한다. 이러한 요구 사항에는 다수의 CAN, LIN 및 FlexRay 채널, 짧은 스타트업 시간, 로거의 I/O 포트 등이 있다. UMTS, WLAN, USB 및 이더넷은 로거를 설 정하고 로깅된 데이터를 전송하는 데 필요한 유연성을 제공한다. 넓은 온도 범위 및 뛰어난 내구성을 지닌 벡터의 플릿 데이터 로 거는 테스트 엔지니어가 극단적인 환경에서 사용하기에 매우 적 합한 장치이다.
독일 출판물 Automobil Elektronik 2011년 2월호 번역판
이미지 권리: Vector Informatik GmbH
링크: 벡터 홈페이지: www.vector.com
Jochen Neuffer 에실링겐(Esslingen)에 위치한 응용 과학 대학교에서 IT를 전공했으며, 2002년부터 Vector Informatik의 네트워크 및 분산 시스템용 툴 영역 에서 제품 관리 엔지니어로 근무하고 있다.
3/48 DevelopmentDevelopment FeatureFeature ECUECU DiagnosticDiagnostic
GME(GeneralGME(General MotorsMotors Europe)Europe) 개발개발 사업부는 사업부는 진단 진단 검증 검증 부문 부문 최초로 최초로 완전 완전 자동화된 자동화된 테스트 테스트 케이스 케이스 제너레이터를 제너레이터를 도입했 도입했 다.다. 이이 글은 글은 GME와 GME와 Vector Vector Informatik가Informatik가 공동으로 공동으로 작성했으며 작성했으며 새로운 새로운 오펠 오펠 인시그니아(Opel 인시그니아(Opel Insignia)Insignia) 모델을모델을 기준으로 기준으로 자동화된자동화된 진단 진단 테스트를 테스트를 구현하는 구현하는 방법을 방법을 소개한다. 소개한다. Vector Vector Informatik Informatik 툴을 툴을 기존 기존 툴 툴 환경에 환경에 통합한 통합한 결과 결과 오펠 오펠 코르사 코르사 (Opel(Opel Corsa)의Corsa)의 일반적인 일반적인 수동 수동 검증과 검증과 비교했을 비교했을 때 때 비용, 비용, 시간시간 및 및 프로세스 프로세스 측면에서 측면에서 우수한 우수한 것으로 것으로 나타났다. 나타났다.
LIN(LocalLIN(Local Interconnect Interconnect Network)[3] Network)[3] 버스 버스 시스템으로시스템으로 구성된다. 구성된다. 모든모든 버스 버스 시스템은 시스템은 그그 림1림1의의 DLC(Central DLC(Central DiagnosticDiagnostic Port)를Port)를 통 통 해해 액세스되며 액세스되며 통신은 통신은 GM GM 고유의고유의 프로토콜 프로토콜 로로 정의된다. 정의된다. 이이 GM GM 진단진단 사양은 사양은 KWP2000 KWP2000 [4][4] 및및 CAN CAN 2.0A2.0A 표준을표준을 기반으로 기반으로 한다. 한다. 진진 단단 사양에는 사양에는 진단 진단 정보를 정보를 얻기 얻기 위해 위해 ECU의 ECU의 진단진단 시스템에 시스템에 접근하도록 접근하도록 허용된 허용된 모든 모든 진단 진단 서비스가서비스가 포함된다. 포함된다. 이이 서비스에 서비스에 대한 대한 결과가 결과가 진단진단 테스터를 테스터를 통해 통해 제공돼 제공돼 진단 진단 통신이 통신이 설정 설정 되며,되며, 해당해당 ECU는 ECU는 요청을 요청을 받는 받는 즉시 즉시 긍정 긍정 또 또 는는 부정 부정 응답으로 응답으로 회신한다. 회신한다.
【그림【그림 1】 1】오펠오펠 인시그니아의 인시그니아의 E/E(ElectricE/E(Electric andand Electronic)Electronic) 아키텍처아키텍처 및 및 진단 진단 통신 통신 �� �정 �정 응답에는 응답에는 진단 진단 ��이�에� ��이�에� ��한 ��한 진단진단 정보가 정보가 포함된다. 포함된다. 진단진단 정보가 정보가 많으면 많으면 응답에응답에 여러 여러 메시지 메시지 프레임이 프레임이 포함될 포함될 수 수 있다.있다. 괄적괄적 검증이 검증이 절대적으로 절대적으로 필요하다. 필요하다. 하는하는 ECU에 ECU에 대한 대한 일반적인 일반적인 진단 진단 검증 검증 프로세 프로세 �� 부정 부정 응답에는 응답에는 ��� ��� 정의된 정의된 부정 부정 응답 응답 코 코 스를스를 보여 보여 준다. 준다. ECU ECU 소프트웨어의 소프트웨어의 개발은 개발은 드가드가 포함되며 포함되며 이를 이를 통해 통해 부정 부정 응답의 응답의 사유 사유 여러여러 단계로 단계로 구성되는데, 구성되는데, ECU ECU 개발의 개발의 초기 초기 진단진단 서비스의 서비스의 자동 자동 검증 검증 에에 대한 대한 정보가 정보가 제공된다. 제공된다. 부정부정 응답 응답 코드 코드 GME의GME의 검증 검증 프로세스 프로세스 및 및 단계에서는단계에서는 진단 진단 서비스보다 서비스보다 ECU ECU 기능기능 구현 구현 는는 GM GM 진단진단 사양에 사양에 따라 따라 지정된다. 지정된다. 툴툴 환경 환경 에에 더 더 중점을 중점을 둔다. 둔다. 그리고그리고 진단 진단 서비스는 서비스는 후 후 GMGM Europe의Europe의 적용 적용 성공 성공 사례 사례 속속 소프트웨어 소프트웨어 버전에서 버전에서 보다 보다 정교하게 정교하게 개발 개발 수신된수신된 응답을 응답을 통해 통해 기술자는 기술자는 결함의 결함의 원인 원인 GME는GME는 오펠 오펠 인시그니아 인시그니아 개발 개발 시 시 처음으 처음으 된다.된다. 그림그림 3에서 3에서 볼 볼 수 수 있듯이 있듯이 1단계(SWR 1단계(SWR 1)1) 을을 파악하고 파악하고 적절한 적절한 작업을 작업을 수행해 수행해 문제를 문제를 로로 Vector Vector Informatik의“CANoe.DiVa” Informatik의“CANoe.DiVa” 소프트웨어소프트웨어 버전 버전 도입 도입 시 시 적은 적은 수의 수의 진단 진단 서비 서비 글로벌글로벌 자동차시장 자동차시장 경쟁이 경쟁이 심화됨에 심화됨에 따라 따라 인다는인다는 점을 점을 잊어서는 잊어서는 안 안 된다. 된다. 이를이를 해결하는 해결하는 데 데 도움이 도움이 되는 되는 정보를 정보를 제공 제공 해결할해결할 수 수 있어야 있어야 한다. 한다. 따라서따라서 서비스 서비스 센터 센터 (Diagnostic(Diagnostic Integration Integration and and Validation Validation 스만스만 구현된다. 구현된다. GME에서는GME에서는 진단 진단 소프트웨어 소프트웨어 자동차의자동차의 전자 전자 네트워킹 네트워킹 아키텍처의 아키텍처의 복잡성 복잡성 고객이고객이 새로운 새로운 자동차를 자동차를 구입할 구입할 때 때 신뢰 신뢰 한다.한다. 이이 정보를 정보를 통해 통해 정비사는 정비사는 문제의 문제의 원인 원인 에서에서 시행되는 시행되는 정비의 정비의 성공 성공 여부는 여부는 진단 진단 시 시 Assistant)Assistant) 툴을 툴을 도입했다. 도입했다.“DiVa” “DiVa” 는는 진단 진단 구성구성 요소( 요소(“CANdesc”“CANdesc”)를)를 사용함으로써 사용함으로써 개발 개발 또한또한 계속해서 계속해서 증가하고 증가하고 있다. 있다. 또또 기업들은 기업들은 성은성은 매우 매우 중요한 중요한 기준이기 기준이기 때문에 때문에 이러한 이러한 이이 된 된 부품을 부품을 파악하고 파악하고 완전 완전 작동 작동 가능한 가능한 상 상 스템에서스템에서 도출된 도출된 데이터의 데이터의 정확성 정확성 및 및 정밀성 정밀성 테스트의테스트의 생성 생성 및 및 실행을 실행을 자동화한다. 자동화한다. 그림그림 시작시작 단계에 단계에 진단 진단 항목 항목 중 중 일부를 일부를 조기에 조기에 구현 구현 개발개발 주기를 주기를 단축해야 단축해야 하는 하는 과제를 과제를 안게 안게 되 되 복잡성을복잡성을 제어하고, 제어하고, 개발 개발 프로세스를 프로세스를 가속 가속 태로태로 복원하기 복원하기 위해 위해 교체해야 교체해야 할 할 부품을 부품을 파 파 에에 따라 따라 크게 크게 달라진다. 달라진다. 고객이고객이 만족하는 만족하는 수 수 22는는 오펠 오펠 코르사 코르사 및 및 오펠 오펠 인시그니아의 인시그니아의 툴 툴 해해 ECU에 ECU에 보다 보다 일찍 일찍 통합할 통합할 수 수 있다. 있다. 었다.었다. 기존기존 시스템을 시스템을 전자 전자 제어 제어 시스템으로 시스템으로 화하며,화하며, 설치된 설치된 전자 전자 제어 제어 장치(ECU)가 장치(ECU)가 결 결 악할악할 수 수 있어야 있어야 한다. 한다. 이같은이같은 조건이 조건이 보장되 보장되 준의준의 신속하고 신속하고 전문적인 전문적인 서비스 서비스 또는 또는 유지보 유지보 환경을환경을 보여 보여 주며, 주며, 두두 환경 환경 모두 모두 테스트 테스트 툴로 툴로 테스트할테스트할 진단 진단 기능 기능 수는 수는 개발 개발 주기마다 주기마다 늘 늘 전환하는전환하는 주 주 목표는 목표는 비용을 비용을 절감하고, 절감하고, 새로새로 함함 없이 없이 작동하도록 작동하도록 보장할 보장할 수 수 있는 있는 새로운 새로운 지지 않는다면 않는다면 올바르게 올바르게 작동하는 작동하는 장치를 장치를 잘 잘 수를수를 수행하려면 수행하려면 적절한 적절한 진단 진단 서비스를 서비스를 반드 반드 “CANoe”“CANoe”[5]를[5]를 사용하고 사용하고 있다. 있다. 코르사 코르사 개발 개발 어난다.어난다. 진단진단 서비스를 서비스를 모두 모두 구현한 구현한 후에는 후에는 회 회 운운 차원의 차원의 안전성과 안전성과 신뢰성 신뢰성 제공, 제공, 관리관리 용이 용이 방식방식 도입이 도입이 중요해졌다. 중요해졌다. 특히특히 ECU에서 ECU에서 제 제 못못 교체[1]해 교체[1]해 보증 보증 비용이 비용이 증가하고 증가하고 고객 고객 만 만 시시 구현해야 구현해야 한다. 한다. 또한또한 진단 진단 서비스는 서비스는 ECU ECU 시에는시에는 대부분 대부분 수동으로 수동으로 검증이 검증이 이뤄졌으나 이뤄졌으나 귀귀 테스트(Regression 테스트(Regression Test:Test: TestTest SynarioSynario 또또 성성 향상에 향상에 있다. 있다. 그러나그러나 이같은 이같은 모든 모든 이점에 이점에 공하는공하는 진단 진단 기능 기능 부문에 부문에 있어 있어 진단 진단 서비스 서비스 족도는족도는 떨어질 떨어질 것이다. 것이다. 를를 프로그래밍하고 프로그래밍하고 제품 제품 품질을 품질을 보증하는데 보증하는데 인시그니아인시그니아 개발 개발 시에는 시에는 거의 거의 대부분의 대부분의 테 테 는는 Case의 Case의 재사용)를 재사용)를 수행한다(SWR 수행한다(SWR 7).7). 개발개발 도도 불구하고 불구하고 차량 차량 내 내 전자 전자 부품 부품 수의 수의 증가가 증가가 의의 정확성은 정확성은 매우 매우 강조된다. 강조된다. ECU는ECU는 정비소 정비소 오펠오펠 인시그니아의 인시그니아의 E/E E/E 아키텍처는 아키텍처는 여러 여러 사용되므로사용되므로 최종 최종 조립 조립 라인 라인 테스트에서 테스트에서 중요 중요 스팅이스팅이 완전 완전 자동화돼 자동화돼 이뤄졌다. 이뤄졌다. 단계에서단계에서 진단 진단 서비스에 서비스에 더 더 이상 이상 결함이 결함이 보고 보고 전자전자 부품과 부품과 관련된 관련된 결함 결함 발생 발생 가능성을 가능성을 높 높 의의 정비사가 정비사가 결함의 결함의 원인을 원인을 신속하게 신속하게 찾고 찾고 개의개의 CAN(Controller CAN(Controller AreaArea Network)[2]Network)[2] 및및 한한 역할을 역할을 담당한다. 담당한다. 따라서따라서 진단 진단 기능의 기능의 포 포 그림그림 3 3은은 GME의 GME의 테스트 테스트 엔지니어가 엔지니어가 수행 수행 되지되지 않으면 않으면 ECU는 ECU는 진단 진단 서비스 서비스 실행의 실행의 측면 측면
8484 www.autoelectronics.co.krwww.autoelectronics.co.kr 20092009 OCTOCT··NOVNOV 8585 4/0 4/1 DevelopmentDevelopmentFeatureFeature ECUECU Diagnostic Diagnostic
에에 있어 있어 양산 양산 가능한 가능한 단계가 단계가 된 된 것이라 것이라 볼 볼 수 수 사용자는사용자는 언제든지“DiVa” 언제든지“DiVa”의의 테스트 테스트 제 제 있다.있다. 약약 조건을 조건을 수정할 수정할 수 수 있다. 있다. 특히, 특히, 강도 강도 패러 패러 일반적으로일반적으로 테스트 테스트 엔지니어는 엔지니어는 서로 서로 다른 다른 미터를미터를 사용해 사용해 전체 전체 테스트, 테스트, 빠른 빠른 테스트, 테스트, 긍 긍 여러여러 ECU를 ECU를 동시에 동시에 테스트하기 테스트하기 때문에 때문에 적절 적절 정적정적 케이스 케이스 테스트 테스트 등의 등의 테스트 테스트 항목을 항목을 구 구 한한 툴 툴 지원 지원 없이 없이 엔지니어가 엔지니어가 대규모의 대규모의 테스트 테스트 성할성할 수 수 있다. 있다. 또 또 서비스가 서비스가 지원되는 지원되는 경우 경우 사 사 를를 수행해 수행해 각 각 소프트웨어 소프트웨어 버전에 버전에 대해 대해 구현된 구현된 용자는용자는 테스트에서 테스트에서 특정 특정 서비스를 서비스를 제외하거 제외하거 진단진단 서비스를 서비스를 모두 모두 다루는 다루는 것이 것이 불가능하다. 불가능하다. 나나그림그림 4처럼 4처럼 데이터 데이터 맞춤형 맞춤형 조건에서 조건에서 서비 서비 따라서따라서 테스트 테스트 엔지니어는 엔지니어는 새로 새로 구현된 구현된 진단 진단 스의스의 데이터 데이터 내용을 내용을 수정할 수정할 수 수 있다. 있다. 서비스만서비스만 심도 심도 있게 있게 테스트하고 테스트하고 자신의 자신의 경험 경험 진단진단 사양(CDD 사양(CDD 파일) 파일)“DiVa” “DiVa” 를를 업데이트 업데이트 을을 토대로 토대로 이전에 이전에 통합된 통합된 개별 개별 서비스에 서비스에 대해 대해 하면하면 기존에 기존에 정의한 정의한 설정을 설정을 유지하면서 유지하면서 새 새 대표적인대표적인 회귀 회귀 테스트를 테스트를 수행한다. 수행한다. 적합한 적합한 자 자 사양으로사양으로 동기화가 동기화가 가능하다. 가능하다. 기술적 기술적 관점 관점 동화동화 툴을 툴을 사용하면 사용하면 작업을 작업을 줄이면서도 줄이면서도 검증 검증 에서“DiVa”에서“DiVa”는는 ECU에서 ECU에서 지원하는 지원하는 모든 모든 진 진 【그림【그림 4】 4】DiVa의DiVa의 테스트 테스트 제약 제약 조건 조건 설정(서비스 설정(서비스 구성 구성 그림) 그림) 시시 더 더 많은 많은 테스트를 테스트를 수행할 수행할 수 수 있다. 있다. 단단 서비스를 서비스를 테스트하기 테스트하기 위해“CANoe”테 위해“CANoe”테 【그림【그림 2】 2】오펠오펠 코르사 코르사 및 및 오펠 오펠 인시그니아의 인시그니아의 진단 진단 검증 검증 및 및 툴 툴 환경 환경 비교 비교 스트스트 모듈용 모듈용 CAPL CAPL 코드를 코드를 생성한다. 생성한다. GM GM
진단진단 사양을 사양을 충족하기 충족하기 위해“DiVa”확장은 위해“DiVa”확장은 【표】【표】오펠오펠 인시그니아의 인시그니아의 ECU에 ECU에 대해 대해 생성된 생성된 테스트 테스트 케이스 케이스 수 수 및 및 실행 실행 시간 시간 검증검증 툴에 툴에 대한 대한 요구 요구 사항 사항 GMGM 표준의 표준의 테스트 테스트 절차를 절차를 매핑한다. 매핑한다. 테스 테스 ExecutionExecution Time Time InsigniaInsignia ECU ECU Ge Generatednerated Test Test Cases Cases (w/o(w/o User User Interaction Interaction for for DTC DTC Checking) Checking) 트트 생성 생성 프로세스에서는 프로세스에서는 생성된 생성된 테스트 테스트 케 케 InstrumentInstrument Cluster Cluster 17001700 13:2513:25 min min 자동화된자동화된 진단 진단 검증 검증 툴은 툴은 다음 다음 요구 요구 사항 사항 이스에이스에 대한 대한 상세 상세 설명과“CANoe”테스트 설명과“CANoe”테스트 ClimateClimate Control Control 33503350 39:1039:10 min min 을을 충족해야 충족해야 한다. 한다. 모듈용모듈용 CAPL CAPL 테스트 테스트 코드 코드 및 및 관련 관련 AirbagAirbag 46304630 1:19:321:19:32 min min “CANoe”“CANoe”테스트테스트 환경을 환경을 도출한다. 도출한다. MobileMobile Phone Phone 11201120 11:0511:05 min min �� 기존 기존 툴 툴 �인에 �인에 ��하� ��하� �합. �합. �� ��성 ��성 및 및 ��성: ��성: 테스트 테스트 �지니어는 �지니어는 수행 수행 한한 테스트를 테스트를 추적하고 추적하고 이를 이를 반복할 반복할 수 수 있어 있어 테스트테스트 실행 실행 및 및 보고서 보고서 평가 평가 테스트테스트 범위 범위 는는 테스트 테스트 실행을 실행을 일시 일시 중지하고 중지하고 사용자가 사용자가 야야 한다. 한다. ECU를ECU를 필요한 필요한 상태로 상태로 전환하도록 전환하도록 요청한 요청한 �� General General Motors의 Motors의 기존 기존 테스� 테스� 방법에 방법에 부 부 【그림【그림 3】 3】GME의GME의 다양한 다양한 ECU ECU 개발 개발단계에서의단계에서의 진단 진단 기능 기능 범위 범위 테스트가테스트가 생성되면 생성되면 사용자는 사용자는“CANoe”“CANoe”에에 테스트를테스트를 자동화하면 자동화하면 테스트 테스트 범위를 범위를 확대 확대 다.다. 테스트 테스트 절차 절차 중 중 나머지 나머지 5%는“DiVa” 5%는“DiVa”에에 합:합: 툴은 툴은 기존 기존 테스트 테스트 방법을 방법을 지원해야 지원해야 한 한 서서 생성된 생성된 테스트 테스트 환경을 환경을 열고 열고 테스트를 테스트를 시 시 하는하는 동시에 동시에 테스트 테스트 실행에 실행에 필요한 필요한 시간을 시간을 서서 지원하지 지원하지 않으며 않으며 수동 수동 또는 또는 다른 다른 방법으 방법으 다.다. 진단 진단 부문에 부문에 있어 있어 GM의 GM의 진단 진단 사양에는 사양에는 작한다.작한다. 테스트 테스트 기간은 기간은 진단 진단 사양의 사양의 복잡성 복잡성 단축할단축할 수 수 있다. 있다. GM GM 진단 진단 사양에 사양에 설명된 설명된 테 테 로로 테스트해야 테스트해야 한다. 한다. EEPROM EEPROM 오류를 오류를 발생 발생 ECU의“GMLANECU의“GMLAN 진단 진단 서비스” 서비스”에대한필에대한필 및및 사용자가 사용자가 선택한 선택한 사용자 사용자 정의 정의 테스트 테스트 범 범 스트스트 절차를 절차를 다루는“DiVa” 다루는“DiVa”의의 범위가 범위가 아래 아래 시키고시키고 이를 이를 감지하는 감지하는 등 등 나머지 나머지 테스트 테스트 절 절 수수 테스트 테스트 절차가 절차가 이미 이미 정의되어 정의되어 있다. 있다. “CANoe”(“CANoe”( ) ) 사이의 사이의 연결을 연결을 나타낸다. 나타낸다. 능을능을 통해 통해 CAN CAN 통신 통신 수준에서 수준에서 진단 진단 데이터 데이터 위에위에 따라 따라 달라지며 달라지며 표에 표에 나와 나와 있듯 있듯 몇 몇 분에 분에 에에 설명되어 설명되어 있다. 있다. 생성된 생성된 테스트 테스트 케이스의 케이스의 차에서차에서 위험한 위험한 상태를 상태를 야기할 야기할 수 수 있는 있는 테스 테스 �� 테스트 테스트 �지니어를 �지니어를 �한 �한 테스트 테스트 ��의 ��의 � � “DiVa”“DiVa”는는 기존에 기존에 수립된 수립된 GME GME 툴 툴 체인에 체인에 원 원 흐름을흐름을 추적 추적 및 및 평가할 평가할 수 수 있다. 있다. 서서 몇 몇 시간에 시간에 이르기까지 이르기까지 다양할 다양할 수 수 있다. 있다. 품질품질 및 및 수는 수는 기계에서 기계에서 읽을 읽을 수 수 있는 있는 진단 진단 사 사 트나트나 교정 교정 데이터가 데이터가 없는 없는 ECU처럼 ECU처럼 ECU에 ECU에 장성장성 활하게활하게 통합할 통합할 수 수 있다. 있다. 개별 개별 서비스를 서비스를 확인 확인 “DiVa”“DiVa”를를 이용해 이용해 테스트를 테스트를 수행하는 수행하는 절 절 GeneralGeneral Motors에서“CANoe”테스트 Motors에서“CANoe”테스트 환 환 양(CDD양(CDD 파일)의 파일)의 완전성에 완전성에 따라 따라 크게 크게 달라진 달라진 대한대한 장기적인 장기적인 변경이 변경이 필요할 필요할 수 수 있는 있는 테스 테스 �� 테스트 테스트 케이스의 케이스의 �� �� 생성: 생성: 이를 이를 위해 위해 사양 사양 하기하기 위한 위한 테스트 테스트 케이스는“CANdela”진 케이스는“CANdela”진 차는차는 다음과 다음과 같다. 같다. 경은경은 테스트 테스트 자동화를 자동화를 위한 위한 공동 공동 플랫폼 플랫폼 역 역 다.다. 모든 모든 테스트는 테스트는 이 이 사양을 사양을 통해 통해 생성된다. 생성된다. 트가트가 이에 이에 해당한다. 해당한다. GM의 GM의 테스트 테스트 케이스가 케이스가 은은 기계에서 기계에서 읽을 읽을 수 수 있는 있는 형식이어야 형식이어야 한다. 한다. 단단 사양(CDD 사양(CDD 파일)을 파일)을 통해 통해 자동으로 자동으로 생성된 생성된 할을할을 하며 하며 기존 기존 GM GM 테스트 테스트 프로그램을 프로그램을 손 손 총총 약 약 350개의 350개의 테스트 테스트 시퀀스가 시퀀스가 GM GM 진단 진단 아닌아닌 추가 추가 테스트 테스트 케이스의 케이스의 실행을 실행을 포함시키 포함시키 다.다. 생성된 생성된 코드는 코드는“CANoe”“CANoe”프로그래밍프로그래밍 언 언 �� ECU ECU 및 및 ECU ECU �형 �형 �� �� 쉽게쉽게 재사용할 재사용할 수 수 있도록 있도록 한다. 한다. 예를 예를 들어 들어 최 최 사양에사양에 정의돼 정의돼 있다. 있다. 이 이 테스트 테스트 시퀀스에서 시퀀스에서 면면 보다 보다 심도 심도 있는 있는 테스트를 테스트를 수행할 수행할 수 수 있다. 있다. 어인“CAPL”어인“CAPL”(Communication(Communication Access Access �� 테스트 테스트 구성 구성 종종 조립 조립 라인 라인 플래시 플래시 테스트 테스트 역시 역시“CANoe”“CANoe” 는는 긍정적 긍정적 케이스와 케이스와 부정적 부정적 케이스를 케이스를 모두 모두 GME에서GME에서 오펠 오펠 코르사와 코르사와 인시그니아에 인시그니아에 사양,사양, 테스트 테스트 실행 실행 및 및 보고서 보고서 ProgrammingProgramming Language)을 Language)을 기반으로 기반으로 생 생 �� 테스트 테스트 생성 생성 프로그래밍프로그래밍 언어인“CAPL” 언어인“CAPL”로로 프로그래밍 프로그래밍 다룬다.다룬다. 테스트 테스트 절차 절차 중 중 상당 상당 부분(약 부분(약 80 80 %) %) 대한대한 검증을 검증을 비교한 비교한 결과“DiVa” 결과“DiVa”는는그림그림 6 6 평가평가 성되며성되며 언제든지 언제든지 검토가 검토가 가능하다. 가능하다. 문제가 문제가 �� 생성된 생성된 테스트 테스트 ��을 ��을“CANoe”“CANoe”테스트테스트 환 환 된다.된다. 테스트 테스트 엔지니어가 엔지니어가 쉽게 쉽게 분석할 분석할 수 수 있 있 이“DiVa”이“DiVa”의의 완전 완전 자동화된 자동화된 테스트에서 테스트에서 처 처 에에 나와 나와 있듯 있듯 생성된 생성된 모든 모든 테스트 테스트 케이스에 케이스에 발생하는발생하는 경우 경우 테스트 테스트 엔지니어는 엔지니어는 자동화된 자동화된 경에경에 추가 추가 도록도록 테스트 테스트 보고서는 보고서는 GM GM 진단 진단 사양에 사양에 맞 맞 리된다.리된다. GM GM 진단 진단 사양에 사양에 정의된 정의된 테스트 테스트 절 절 대한대한 탁월한 탁월한 자동화 자동화 테스트 테스트 실행을 실행을 통해 통해 테 테 그림그림 2와 2와 같이“DiVa” 같이“DiVa”는“CANdela-는“CANdela- 테스트테스트 시퀀스에 시퀀스에 개입하여 개입하여 문제를 문제를 해결할 해결할 �� 테스트 테스트 실행 실행 춰춰 구성된다. 구성된다. 그림 그림 5는 5는 일반적인 일반적인 테스트 테스트 보 보 차차 중 중 45개(15%)에 45개(15%)에 대해서는 대해서는 애플리케이션 애플리케이션 스트스트 실행 실행 시간을 시간을 획기적으로 획기적으로 단축한 단축한 것으 것으 Studio”Studio”(진단(진단 사양)와 사양)와 입증된 입증된 검증 검증 툴 툴 수수 있다(투명성). 있다(투명성). 또한“CANoe” 또한“CANoe”의로깅기의로깅기 �� 테스트 테스트 �고서 �고서 �가 �가 고서를고서를 보여 보여 준다. 준다. 별별 사용자 사용자 입력이 입력이 필요하다. 필요하다. 이 이 경우 경우“DiVa”“DiVa” 로로 나타났다. 나타났다. 표에서는 표에서는 오펠 오펠 인시그니아의 인시그니아의
8686 www.autoelectronics.co.krwww.autoelectronics.co.kr 20092009 OCT OCT··NOVNOV8787
4/2 4/3 DevelopmentDevelopmentFeatureFeature ECUECU Diagnostic Diagnostic
ECU에ECU에 대해 대해 생성된 생성된 테스트 테스트 케이스의 케이스의 실행 실행 “DiVa”“DiVa”에에 대한 대한 라이센스만 라이센스만 필요하므로 필요하므로 성으로성으로 인해 인해 테스트 테스트 도중 도중 특정 특정 오류 오류 상태를 상태를 도를도를 늘렸다. 늘렸다. 또한 또한 GM의 GM의 테스트 테스트 케이스가 케이스가 시간시간 및 및 수를 수를 요약해 요약해 보여 보여 준다. 준다. 시간제한으 시간제한으 새새 솔루션의 솔루션의 비용은 비용은 그리 그리 높지 높지 않다. 않다. 재현하는재현하는 것은 것은 매우 매우 어렵다. 어렵다. 아닌아닌 추가적인 추가적인 타사 타사 테스트 테스트 케이스의 케이스의 실행 실행 로로 인해 인해 수동 수동 테스트는 테스트는 극히 극히 제한적인 제한적인 경우 경우 “CANoe”“CANoe”에에 익숙한 익숙한 GME의 GME의 사용자는 사용자는 사전 사전 �� 2차 2차 결함: 결함: 오류가 오류가 발생하는 발생하는 경우 경우 자동화된 자동화된 으로으로 테스트 테스트 범위를 범위를 확대했다. 확대했다. 이전에 이전에 성공 성공 에만에만 수행할 수행할 수 수 있다. 있다. 따라서 따라서 테스트 테스트 결과는 결과는 교육교육 없이 없이“DiVa”“DiVa”테스트를테스트를 수행할 수행할 수 수 있다. 있다. 테스트테스트 툴은 툴은 테스트 테스트 엔지니어와 엔지니어와 달리 달리 초기 초기 한한 프로젝트의 프로젝트의 수동 수동 검증과 검증과 직접 직접 비교했을 비교했을 테스트테스트 엔지니어의 엔지니어의 경험 경험 및 및 주어진 주어진 시간에 시간에 “DiVa”“DiVa”는“CANoe”는“CANoe”를를 통해 통해 제공되는 제공되는 CAN CAN 결함과결함과 2차 2차 결함을 결함을 구분할 구분할 수 수 없다. 없다. 때때 기술 기술 및 및 경제적인 경제적인 측면에서 측면에서 효율성이 효율성이 크 크 따라따라 크게 크게 달라진다. 달라진다. GME는 GME는“DiVa”“DiVa”를를 통해 통해 인프라를인프라를 이용하므로 이용하므로 테스트를 테스트를 실행하는 실행하는 데 데 �� 사�자 사�자 개�: 개�: ��리�이�� ��리�이�� 테스트에서 테스트에서 게게 증가했다. 증가했다. 개발 개발 단계 단계 및 및 구현 구현 품질에 품질에 따라 따라 진단진단 사양별로 사양별로 ECU를 ECU를 완벽하게 완벽하게 테스트할 테스트할 추가추가 하드웨어가 하드웨어가 필요 필요 없다. 없다. 추가추가 하드웨어가 하드웨어가 필요한 필요한 상태로 상태로 ECU를 ECU를 전 전 효율성이효율성이 실질적으로 실질적으로 4~20배 4~20배 증가했다. 증가했다. 동 동 수수 있을 있을 뿐 뿐 아니라 아니라 모든 모든 개발 개발 단계에서 단계에서 보다 보다 환해야환해야 할 할 수 수 있으며 있으며 이 이 경우 경우 명시된 명시된 완전 완전 시에시에 품질에 품질에 대한 대한 고객의 고객의 높은 높은 기대치를 기대치를 만 만 넓은넓은 범위를 범위를 테스트할 테스트할 수 수 있다. 있다. 자동화된자동화된 방법으로는 방법으로는 처리할 처리할 수 수 없다. 없다. 족시킬족시킬 수 수 있게 있게 되었다. 되었다. 자동자동 테스트 테스트 케이스 케이스 생성 생성 및 및 테스트테스트 실행에 실행에 대한 대한 제한 제한 사항 사항 요약요약 참고자료참고자료 경제적인경제적인 측면과 측면과 효율성 효율성 증가 증가 [1][1] Thomas, Thomas, D.; D.; Ayers, Ayers, K.; K.; Pecht, Pecht, M.: M.: The The “trouble“trouble not not identified”phenomenon identified”phenomenon in in 테스트테스트 범위 범위 및 및 소비되는 소비되는 시간의 시간의 측면에 측면에 테스트테스트 자동화 자동화 툴을 툴을 사용하지 사용하지 않는 않는 경우 경우 automotiveautomotive electronics. electronics. In: In: Microelectronics Microelectronics 툴을툴을 도입할 도입할 때는 때는 경제적인 경제적인 이점이 이점이 주요 주요 서서 자동화된 자동화된 툴은 툴은 수동 수동 테스트 테스트 전략보다 전략보다 효 효 최신형최신형 차량의 차량의 진단 진단 기능을 기능을 필요한 필요한 범위 범위 내 내 reliability,reliability, Vol. Vol. 42, 42, P. P. 641-651, 641-651, 2002 2002 고려고려 사항이다. 사항이다. 새로운 새로운 오펠 오펠 코르사는 코르사는 시장에 시장에 과적이지만과적이지만 자동 자동 테스트 테스트 생성에는 생성에는 다음과 다음과 에서에서 검증하는 검증하는 것은 것은 거의 거의 불가능하다. 불가능하다. [2][2] LIN LIN Consortium:Consortium: LIN LIN Specification Specification 【그림【그림 5】 5】"DiVA"에서"DiVA"에서 자동 자동 생성된 생성된 테스트 테스트 보고서 보고서 PackagePackage Revision Revision 2.1, 2.1, OV. OV. 2006 2006 서서 매우 매우 성공적인 성공적인 제품이며 제품이며 진단 진단 관련 관련 전자 전자 같은같은 몇 몇 가지 가지 제한 제한 사항이 사항이 있다. 있다. “CANoe.DiVa”“CANoe.DiVa”는는 기존의 기존의 모든 모든 테스트 테스트 프로 프로 [3][3] Robert Robert Bosch Bosch GmbH: GmbH: CAN-Spezifikation CAN-Spezifikation 부품부품 문제에 문제에 대한 대한 부정적인 부정적인 보고도 보고도 없다. 없다. 이 이 세스를세스를 지원하도록 지원하도록 하는 하는 GM의 GM의 요구 요구 사항을 사항을 2.0,2.0, 1991 1991 러한러한 이유로 이유로 오펠 오펠 코르사에 코르사에 대한 대한 수동 수동 검증 검증 �� 사양의 사양의 품�: 품�: 사양은 사양은 테스트 테스트 �이스 �이스 생성을 생성을 준수하며준수하며 General General Motors Motors Europe의 Europe의 기존 기존 [4][4] International International Organization Organization for for Stan- Stan- dardization:dardization: Keyword Keyword Protocol Protocol 2000, 2000, ISO ISO 프로세스를프로세스를 참조 참조 프로젝트로 프로젝트로 채택했다. 채택했다. 반면 반면 위한위한 기준을 기준을 나타내므로 나타내므로 사양은 사양은 완전성 완전성 및 및 정 정 툴툴 체인에 체인에 완벽하게 완벽하게 통합된다. 통합된다. 또한 또한 새로운 새로운 14230,14230, 1999 1999 새로운 오펠 인시그니아에는 진단 서비스 검 확성을 반드시 갖춰야 한다. 즉, 테스트는 해 오펠 인시그니아의 진단 서비스 검증을 위 새로운 오펠 인시그니아에는 진단 서비스 검 확성을 반드시 갖춰야 한다. 즉, 테스트는 해 오펠 인시그니아의 진단 서비스 검증을 위 [5][5] Krauss, Krauss, S.: S.: Testing Testing with with CANoe, CANoe, Appli- Appli- 증을증을 위한 위한 기본 기본 툴로“DiVa” 툴로“DiVa”가가 사용됐다. 사용됐다. 당당 사양에 사양에 정의된 정의된 범위에 범위에 대해서만 대해서만 수행된다. 수행된다. 한한 자동화된 자동화된 테스트 테스트 툴로 툴로 사용된다. 사용된다. cationcation Note Note AN-IND-1-002. AN-IND-1-002. Vector Vector Informatik,Informatik, 2005 2005 “DiVa”“DiVa”를를 사용함으로써 사용함으로써 검증 검증 테스트의 테스트의 상당 상당 또한또한 사양은 사양은 General General Motors Motors 진단 진단 인프라 인프라 “DiVa”“DiVa”를를 통해 통해 GME는 GME는 테스트 테스트 기간을 기간을 단 단 [6][6] General General Motors. Motors. GGSE GGSE ECU ECU Diagnostic Diagnostic 부분이부분이 최초로 최초로 자동화됐다. 자동화됐다. 비교를 비교를 위해 위해 본 본 (GGSE-I)의(GGSE-I)의 요구 요구 사항을 사항을준수해야준수해야 한다 한다.[6].[6] 축한축한 동시에 동시에 회귀 회귀 테스트를 테스트를 보다 보다 자주 자주 수행 수행 InfrastructureInfrastructure Requirements, Requirements, Version Version 1.07, 2007 연구에서는연구에서는 견본 견본 ECU를 ECU를 기준으로 기준으로 검증 검증 단계 단계 �� 재현성: 재현성: 차� 차� 내 내 CAN CAN ��의 ��의 비결정� 비결정� 특 특 할수있는할수있는“DiVa”“DiVa”의의 기능을 기능을 통해 통해 테스트 테스트 강 강 1.07, 2007 의의 테스트 테스트 실행 실행 및 및 평가에 평가에 필요한 필요한 시간을 시간을 측 측 정했다.정했다. 지정된 지정된 값은 값은 그림 그림 3의 3의 SWR SWR 5 5 구현 구현 수준을수준을 기반으로 기반으로 한다. 한다. 이 이 시점에서 시점에서 대부분의 대부분의 서비스는서비스는 이미 이미 구현되어 구현되어 있으며 있으며 상당한 상당한 수의 수의 실패한실패한 테스트 테스트 케이스가 케이스가 이미 이미 확인된 확인된 상태이 상태이 다.다. 그림 그림 6은 6은 오펠 오펠 코르사의 코르사의 수동 수동 테스트와 테스트와 오펠오펠 인시그니아의 인시그니아의 자동 자동 테스트를 테스트를 위한 위한 수 수 시 시 필립필립 페티 페티 아르민아르민 티머베르그 티머베르그 토마스토마스 페퍼 페퍼 시몬시몬 뮐러 뮐러 크리스토프크리스토프 래츠 래츠 간에간에 걸친 걸친 검증 검증 작업을 작업을 보여 보여 준다. 준다. 오펠 인시그니아는“DiVa”를 사용함으로 오펠 인시그니아는“DiVa”를 사용함으로 【그림【그림 6】 6】오펠오펠 코르사의 코르사의 수동 수동 검증과 검증과 오펠 오펠 인시그니아의 인시그니아의 진단 진단 서비스 서비스 자동 자동 검증에 검증에 대한 대한 ECU당 ECU당 테스트 테스트 글글││필립필립 페티 페티박사박사 아르민아르민 티머베르그 티머베르그석사석사 작업 비교(실행 및 평가 시간) 써써 코르사에 코르사에 비해 비해 실행 실행 및 및 평가 평가 시간이 시간이 크게 크게 작업 비교(실행 및 평가 시간) 글로벌글로벌 시스템 시스템 엔지니어링 엔지니어링 그룹, 그룹, 개발 개발 엔지니어 엔지니어 글로벌글로벌 시스템 시스템 엔지니어링 엔지니어링 그룹, 그룹, 개발 개발 엔지니어 엔지니어 GeneralGeneral Motor Motor Europe( Europe(뤼셀스하임뤼셀스하임 소재) 소재) GeneralGeneral Motor Motor Europe(뤼 Europe(뤼셀스하임셀스하임 소재) 소재) 단축되었다.단축되었다. 연구 연구 결과 결과 3~5배 3~5배 향상된 향상된 것으로 것으로 토마스토마스 페퍼 페퍼석사석사 시몬시몬 뮐러 뮐러석사석사 나타났다(그림 6 참조). 특히 진단 서비스의 나타났다(그림 6 참조). 특히 진단 서비스의 글로벌글로벌 시스템 시스템 엔지니어링 엔지니어링 그룹, 그룹, 진단 진단 및 및 테스트 테스트 자동화 자동화 그룹 그룹 관리자 관리자 자동차 자동차 진단 진단 제품 제품 라인 라인 사업부 사업부, ,CANoe CANoe 및 및 DiVa DiVa 담당 담당 제품 제품 관리자 관리자 수가수가 많은 많은 ECU의 ECU의 경우 경우 시간 시간 절감 절감 효과가 효과가 컸 컸 현현 환경에서 환경에서 실패한 실패한 테스트의 테스트의 수가 수가 줄어들었 줄어들었 떠한떠한 결함도 결함도 있어서는 있어서는 안 안 되며 되며 따라서 따라서 평가 평가 GeneralGeneral Motor Motor Europe Europe ( 뤼셀스하임(뤼셀스하임 소재) 소재) VectoVector rInformatik Informatik GmbH( GmbH(슈투트가르트슈투트가르트 소재) 소재) 다.다. 또한 또한 SWR SWR 6이나 6이나 SWR SWR 7 7 등의 등의 후기 후기 개발 개발 다는다는 사실을 사실을 통해 통해 알 알 수 수 있다. 있다. 이러한 이러한 추세는 추세는 시간이시간이 실행 실행 시간과 시간과 동일하다. 동일하다. 오펠 오펠 인시그니 인시그니 크리스토프크리스토프 래츠 래츠석사(BA)석사(BA) 자동차자동차 진단 진단 제품 제품 라인 라인 사업부, 사업부, 글로벌 글로벌 제품 제품 라인 라인 관리자 관리자 단계에서는단계에서는 테스트 테스트 결과를 결과를 평가하는 평가하는 데 데 필요 필요 양산양산 시작에 시작에 들어가기까지 들어가기까지 각각의 각각의 새 새 단계마 단계마 아아 개발에서 개발에서 이 이 단계는 단계는 ECU의 ECU의 복잡성에 복잡성에 따 따 VectorVector Informatik Informatik GmbH( GmbH(슈투트가르트슈투트가르트 소재) 소재) 한한 시간이 시간이 훨씬 훨씬 줄어들었다. 줄어들었다. 이는 이는 완성된 완성된 구 구 다다 계속된다. 계속된다. 양산 양산 시작 시작 직전의 직전의 ECU에는 ECU에는 어 어 라라 효율성이 효율성이 20~40배 20~40배 증가할 증가할 수 수 있다. 있다.
8888 www.autoelectronics.co.krwww.autoelectronics.co.kr 20092009 OCT OCT··NOVNOV8989
4/4 4/5 지고 사용 범위는 더 넓어지게 될 것으로 예상된다. 따라서 진단 실행에 대한 품질 요구조건도 앞으로 더욱 증가하고 까다로워 질 것으로 예상할 수 있다.
소프트웨어 업데이트 검증 여러 가지 진단 표준화 조치에도 불구하고, ECU 소프트웨어의 업 Insert figure 데이트를 위한 과정은 여전히 OEM마다 서로 다르다. 사용되는 서 비스가 표준화되어 있음에도 불구하고, 부분 자동 업데이트(incre- mental update)나 전송 데이터(식별 데이터, 체크섬, 시그니처 등) 를 보호하기 위한 메커니즘과 같은 기능들은 실제로 상당히 다른 플래시(flash) 절차로 이어진다. 또한 각 제조업체별 프로세스 요구 사항을 충족시키기 위하여 서로 다른 플래시 컨테이너(flash con- tainer) 포맷이 사용된다. 실제로 이것은 거의 모든 OEM을 위한 개 자동 진단 검증은 로켓 과학이 그림1: CANoe.DiVa 자동 테스트 환경의 기능 블록 별적인 소프트웨어 업데이트 툴들이 존재한다는 것을 의미한다. 그러므로 공급업체는 이처럼 다양한 툴을 사용하여 작업해야 할 아니다. 뿐만 아니라, 때로는 각각의 OEM을 위한 개별적인 테스트 환경을 실제로 지금은 거의 모든 ECU에 대해 CANdela와 ODX 포맷으로 개발하고 이를 유지해야 한다. 잘 동작하는 플래시 절차는 항상 생 단지 실행 가능한 기존 방안들을 활용하여 결론을 맺는 형식을 갖춘 진단 사양 기술이 가능하다. 그러므로 이는 진단 사 산 및 정비 시의 필수적인 요소이다. 장래에 있을 소프트웨어 업데 것이다. 양부터 종합적이고 자동화된 프로토콜 테스트까지 나아가기 위 이트인 “over the air”(SOTA)를 고려하면, 신뢰할 수 있는 차량 소 한 작은 발걸음이다. 초기에 작은 노력만 기울인다면 간단하게 프트웨어 업데이트 기능은 그 어느 때보다도 더 중요하다. 아마도 프로토콜 오류를 검출할 수 있다. 앞으로는 새로운 가능을 가진 새로운 소프트웨어가 더욱 자주 탑 재될 것이다. 이러한 빈도는 아마도 우리가 현재 모바일 기기에서 AUTOSAR, 진단 프로토콜의 품질을 향상시키다 경험하고 있는 수준(예를 들면 보안 취약성 해결을 위한 업데이트 진단용 AUTOSAR 소프트웨어 컴포넌트가 사용되는 경우, 테스터 의 빈도)이 될 수 있다. 물론 업데이트 실패 끝에 ECU가 더 이상 가 유발하는 일련의 프로토콜 위반(예, 포맷 위반)은 응용 소프트 기능하지 않게 되는 상황은 반드시 피해야 한다. 하지만 유명 스마 진단 검증(diagnostic validation)에 대한 기술 기사는 대개 다음과 같은 문장으로 시작된다: 차량의 ECU의 복잡성이 점점 증가됨 웨어 레리어가 아닌 기본 소프트웨어 레이어에서 처리한다. 일반 트폰 제조업체들의 경우를 보면 정교한 보호 수단을 마련하고 있 에 따라 진단의 범위 또한 넓어지고 있으며, 진단 검증에 필요한 시간과 노력 또한 증가하고 있다. 하지만 다행히도 오늘날의 테스 적으로 ECU의 기본 소프트웨어는 가용 진단 데이터를 직접 파라 음에도 불구하고 소프트웨어 업데이트가 항상 원활하게 이루어지 트 툴 덕분에 검증에 필요한 시간과 노력은 더 이상 선형적으로 증가하는 추세는 아니다. 특히 근 수년 동안 완전히 자동화된 진단 미터로 사용하기 때문에, 대개 ECU가 테스터로 보내는 진단 응 지는 않는다. 프로토콜 테스트를 만들고 실행할 수 있게 되었다. 기능이 더욱 증가함에도 불구하고 테스트 생성과 실행에 필요한 시간과 노력은 답 또한 프로토콜을 준수한다. 따라서 AUTOSAR 소프트웨어 컴 거의 일정한 수준으로 유지되고 있다. 진단 통신 서비스 UDS와 진단 데이터 포맷 ODX에 대한 표준이 수립됨에 따라, 비교적 높은 포넌트가 사용되는 경우, 단순한 프로토콜 오류의 비율은 눈에 이미 벡터의 리프로그래밍 툴인 vFlash를 사용하여 수년 전부터 수준의 테스트 자동화를 달성할 수 있으며, 그 결과 높은 진단 품질을 제공할 수 있다. 그뿐만 아니라 진단 어플리케이션과 업데이 띄게 감소한다. 그 결과 테스트 평가와 문제해결에 필요한 시간 여러 제조업체에 공통적으로 적용되는(Cross-manufacturer) 소 트 소프트웨어의 테스트 역시 자동화될 수 있다. 오늘날 테스트 자동화에서 이처럼 높은 잠재력을 지닌 자동차 전자 개발 분야는 과 노력도 크게 줄어든다. 그럼에도 불구하고 특히 다음과 같은 프트웨어 업데이트가 수행되어 왔으며, 현재 모든 관련 차량 제조 업체의 90개 이상의 서로 다른 사양의 부트 로더에 대하여 이러한 매우 적다. 이유로 인하여 프로토콜 테스트는 여전히 중요하다: 업데이트가 수행되고 있다. 테스트 자동화 툴인 CANoe.DiVa는 > AUTOSAR 컴포넌트, 컴포넌트 통합 그리고 어플리케이션 vFlash 자동 인터페이스를 사용하고 있으며, 이에 따라 vFlash가 지난 2006년의 Unified Diagnostic Services(UDS) 표준 공하는 CANdelaStudio 툴은 진단 사양을 정의하기 위한 목적으 개발을 구성하는 도중에 오류가 발생할 수 있다. 지원하는 모든 부트로더에 대한 자동 소프트웨어 업데이트가 추가 (ISO14229) [1]의 배포는 진단 테스트 자동화를 위한 중요한 한 로 전세계적으로 도입되었다. 특히 이 툴은 국제 Open Diagnos- > ECU의 진단 데이터가 진단 테스터가 사용하는 진단 데이터와 적으로 제공된다. 유효한 플래시 절차의 변수(타이밍, 포맷 등) 외 걸음이었다: 이 표준이 진단 서비스의 규격을 통일함에 따라, 사 tic data eXchange 표준(ODX, ISO22901) [3]을 지원한다. 이 표 일치하지 않는 경우, “올바른” 실행에도 불구하고 ECU 내의 에도 플래시 절차의 다양한 지점에서의 중단이나 부족전압과 같은 상 처음으로 심도 깊은 수준으로 여러 제조업체를 대상으로 하는 준은 2008년에 발표되었으며 현재 전세계 대부분의 차량 제조업 올바른 진단이 가능하지 않을 수도 있다. 기존의 오류 시뮬레이션도 자동으로 테스트된다. 이를 통해 ECU (cross-manufacturer) 진단 프로토콜 테스트를 실행할 수 있게 되 체들이 사용하고 있다. > 어플리케이션에서 에러 처리하는 방식이 맞지 않는 경우 소프트웨어의 강건성(robustness)을 쉽고 종합적으로 테스트할 었다. 이전의 프로토콜인 KWP2000(ISO14230) [2]은 여전히 광범 따라서 진단 프로토콜의 자동 생성을 위한 기술적 전제조건은 이 악성 코드를 설치하더라도 찾아내지 못할 수 있다. 수 있다. 위한 자유도를 허용하였으며, 이에 따라 각 OEM 고유의 방식을 미 오래 전에 충족되었다. 그러므로 벡터의 CANoe.DiVa 툴과 같 통해 좀더 구체적으로 만들어야만 한다. 그리고 이것은 보편적으 은 자동 진단 테스트 생성을 위한 솔루션이 이미 마련되어10년 DoIP와 OTA(over the air) 시에는 진단 테스터와 ECU가 직접 연 설명된 테스트는 본질적으로는 블랙 박스 테스트이다. 이러한 테스 로 유효한 테스트를 구현하는 것을 더욱 어렵게 만든다. UDS의 넘게 실행되고 있음은 분명하다. 결이 필요하지 않기 때문에, 프로토콜 오류는 전체 차량군에서 트 외의 테스트는(예를 들면 식별 데이터나 시그니처와 같은 프로 개정된 버전은 2013년도에 발표되었으며, 이 개정 표준 덕분에 이러한 서비스에 부정적인 영향을 끼칠 수도 있다. 예를 들면 원 세스 관련 데이터에 대한 타당성(plausibility) 검증) 제조업체마다 훨씬 더 상세한 프로토콜 테스트를 만드는 것이 가능하다. CANdela 또는 ODX 포맷의 진단 정보 및 진단 프로토콜(예: UDS, 격 진단시 사용할 수 있는 진단 항목의 제한으로 완전한 차량 진 다른 상세한 사양을 요구한다. 이미 이러한 유형의 테스트를 위하 KWP2000, OBD, WWH-OBD, …)을 바탕으로 하여 매우 포괄적인 단이 안될 수 있다. 필요한 진단 기능이 원하는 대로 작동되지 않 여 유명 제조업체를 위한 별도의 확장(extension)이 존재한다. 소 프로토콜 정의 외에도, 형식에 맞춰 기술된 진단 데이터는 테스 테스트가 자동으로 생성된다. 이러한 테스트는 ECU 내 오류 처 기 때문에, 결국 정비소에서 정비하는데 많은 시간이 소모된다. 프트웨어 업데이트 시험은 신뢰할 수 있는 데이터 전송 및 오류 발 트 생성(test generation)을 위한 두 번째로 중요한 전제조건에 리를 테스트에 포함시키는 유효한 요청 및 유효하지 않은 요청을 최악의 경우에 프로토콜 에러는 안전에 치명적인 차량에 대한 공 생 시의 안정적인 작동과 같은 필수적인 업데이트 특성들을 보장 해당된다. 차량의 파워 윈도우의 기능적 범위는 엔진 ECU의 기 모두 다룬다. 이 테스트는 CANoe에 로드되어 자동으로 실행된 격을 허용할 수도 있다. 차량은 끊임없이 사용되기 때문에, 앞으 한다. 이러한 사항에 대한 자동화가 제공하는 편리함은 진단 프로 능적인 범위와는 본질적인 차이가 있으며, 이에 따라 실행되는 다. 이 테스트의 결과는 상세한 보고서로 작성된다 [그림 1]. 더 로 진단 기능에 관련하여 고객들이 경험할 수 있는 새로운 사용 토콜 테스트에 대한 자동화가 주는 편리함과 유사하다. 진단 기능 또한 서로 다르다. 테스트를 자동으로 생성하기 위해 큰 규모의 ECU의 경우, 중복되는 테스트 없이 빠르게 10,000개 사례가 생겨날 것이며, 아마도 진단 기능의 사용 빈도는 더 잦아 서는 ECU에서 실행되는 진단 서비스를 알아야 한다. 벡터가 제 이상의 테스트 케이스가 생성된다.
4/6 4/7 진단 어플리케이션의 검증 테스트 범위, 테스트 평가, 그리고 추가 프로세싱 분야에서 중요한 주제가 되고 있다. 소위 “over the air”, 즉 무선 ECU의 진단 기능은 형식적인 측면들을 만족시킬 뿐만 아니라 그 적절한 툴을 통하여 달성한 진단 프로토콜 검증에 대한 고도의 자 을 통한 확장된 차량 액세스는 차량 진단을 위한 새로운 어플리 내용 또한 올바른 것이어야 한다. 이것은 합리적인 차량 진단을 동화 덕분에, 꾸준한 시간과 노력을 기울여 더욱 자동화된 테스트 케이션의 영역을 열고 있으며, 결국 이것은 충분한 보호가 이루 보장하는 유일한 방법이다. 현재의 진단 포맷(예: ODX)은 특히 또는 사용자의 추가적인 자체 테스트를 통해 더욱 심도 깊은 검사 어져야 한다. 다양한 혁신들이 소프트웨어와 주요 툴에서 처음부 프로토콜의 정의에 집중하고 있다. 그렇지만, 자동 테스트 생성 를 실시할 수 있다: 점점 더 많은 OEM들이 진단 어플리케이션 케 터 사용자 친화적인 방식으로 지원되어야만 이러한 혁신들이 양 을 위하여 이것들로부터 어플리케이션 관련 정보를 추출할 수 있 이스를 체계적으로 보호하기 위하여 자동 옵션을 활용하고 있다( 산 체계(serial production)에 바로 적용될 수 있다. 이것은 복잡 다: 예를 들어 전송된 값의 타당성에 대한 자동 테스트는 이미 정 예: OEM에게 특히 중요한 생산 및 정비에 활용). 따라서 진단 기능 하고 어려운 기술이 아니라 소프트웨어 벤더들에 대한 흥미로운 의된 지정된 값의 범위로부터 얻을 수 있다. 구체적인 오류의 원 은 이미 초기 개발 단계에서 공급업체가 확실하게 보호할 수 있다. 도전일 뿐이다. 인은 경험적 방법(heuristic method) 또는 제조업체별 지식을 사 용하여 에러코드 또는 진단 파라미터로부터 얻을 수 있다. 특정 전세계에서 가장 큰 규모의 여러 OEM들이 현재 CANoe.DiVa의 한 자동 시험에서 얻은 통찰력을 실천에 옮기기 위하여(테스트) 테스트 지원에 의존하고 있다. 이 과정에서 OEM은 시험 결과의 추 환경에 대한 접근을 위한 옵션과 ECU의 시뮬레이션을 위한 옵션 가적인 프로세싱에 대한 종합적인 지원을 통해서도 이익을 얻으 독일 Hanser Automotive 3-4/2017호의 기술기사입니다. 이 무엇인지 알아야 한다. 하지만 대부분의 경우 이러한 정보는 며, 이는 실제로 많은 시간을 절약할 수 있다. [그림 3]: ECU 개발 동안 얻을 수 있다: 이미지 권리: Vector Informatik GmbH
> 네트워크 아키텍처는 AUTOSAR(.arxml) 또는 CANdb(.dbc) 참고문헌: 안에 기술된다. 신호는 버스에서 쉽게 읽을 수 있으며 잔여 [1] - [3] International Organization for Standardization: ISO 버스 시뮬레이션을 통해 조정된다. 14229 (UDS), ISO 14230 (KWP2000), ISO 22901 (ODX) > ECU의 메모리 레이아웃은 a2l 파일 내에 기술된다. 파라미터 [4] Metzger E.; 2016: Presentation: The Vector Security Solu- Insert figure 는 XCP를 통해 쉽게 읽고 조정할 수 있다. tion, Vector Cyber Security Symposium 2016 > 전기적 입출력과 테스트 구성은 대개 기계적으로 읽을 수 [5] Peti P., Timmerberg A., Pfeffer T., Müller S., Rätz C.; 2008: 있는 포맷으로 기술된다. 이것은 HiL(Hardware-in-the-Loop) Automatic validation of diagnostic services, ATZ elektronik 테스트와 벡터 VT 시스템의 조합 [그림 2]를 통해 측정되고 06I2008 시작될 수 있다.
Christph Rätz 또한 CANoe.DiVa는 Excel exchange 포맷을 통한 각 기업 고유의 Christoph Rätz는 Vertor Informatik GmbH에서 Diagnostic Product 파라미터들과 DTC를 연결시키는 기능을 제공한다. 벡터 CANoe와 그림3: 수동 검증과 자동 검증에 소요되는 테스트 시간과 노력을 Line Head이다. 같은 통합 테스트 환경에서는 이 모든 소스가 하나의 테스트에 조 비교한 실제 사례 [5] 합되어 사용될 수 있다.
가상 ECU가 개발에 사용되는 경우(예: 벡터 vVIRTUALtarget), 하 > 시험 결과의 선별적이고 필요에 기반한 검토를 위한 분류 및 Simon Müller 드웨어 I/O가 소프트웨어에서 쉽게 시뮬레이션될 수 있기 때문에, 필터링 Simon Müller는 Vertor Informatik GmbH에서 Diagnostic Product Line 어플리케이션 시험을 위한 테스트 설정은 비교적 간단하다. 어플리 > 동일한 원인의 연결 오류 의 CANoe.DiVA Product Manager이다. 케이션 테스트 동안 가능한 자동화의 정도는 분명 프로토콜 시험 > 오류와 그 원인을 분류하기 위하여 각각의 시험 결과에 동안의 자동화 수준에는 미치지 못한다. 하지만 반 자동 테스트 생 코멘트를 추가하기, 시정조치에 대한 메모 작성하기, 문제 성 또는 완전 자동 테스트 생성을 위한 다양한 옵션이 마련되고 해결방법 관리하기 있으며 이러한 옵션을 활용하는 것은 많은 도움이 된다. > 하나의 테스트 런으로부터 다른 테스트 런으로 오류 분석 결과를 전송하기 > 기존의 프로세스에 통합하기 위하여 테스트 솔루션을 기존의 테스트 데이터 관리 시스템 또는 요구사항 시스템에 연결하기
결론 및 전망 ECU의 진단 범위는 점점 넓어지고 품질 요구사항은 계속해서 증 Insert figure 가하게 될 것이다. 하지만 진단 검증에 필요한 시간과 노력을 크 게 감소시켜 주면서 한편으로는 테스트의 범위를 크게 넓히고 더 욱 심도 있게 만드는 자동화 솔루션은 지금도 이미 존재한다. 대 부분의 경우 이를 위하여 필요한 형식을 갖춘 진단 DB를 사용할 수 있다. 또한 테스트 목적을 위한 이 데이터의 재사용은 매우 간단하고 논리적이다. 차량의 경계를 넘어서는 네트워크가 점점 증가함에 따라, 자동차의 사이버 보안에 대한 문제도 더욱 빠르 그림2: CANoe.DiVa: Software 및 Hardware in-the-loop 게 증가하고 있다. “Testing security”[4]와 “Testing despite secu- rity”, 즉 “보안 검사”와 “보안과 무관한 검사”는 이제 다양한 개발
4/8 4/9 그림 1에는 이에 대한 예가 나와 있다. 즉, 기능 라이브러리 > Microcontroller Abstraction Layer: 특정 마이크로컨트롤러 디 (Function Library)에 있는 조명(Lighting)이라는 차량 기능은 세 바이스로부터 상위 레이어들의 추상화 개의 하위 기능으로 나뉘어 있다. 차량 A에서는 이러한 하위 기 능이 두 개의 네트워크 ECU로 분배되는 반면 차량 B에서는 변경 ECU 구성 설명(ECU Configuration Description)은 BSW와 RTE를 되지 않은 상태로 세 개의 ECU로 분배된다. 하위 기능들 간의 통 구성하는데 사용된다. 초기에 이 구성설명서는 ECU 추출 정보 명 신은 시스템 구성 설명에 정의되어 있다. 세(the ECU Extract of the System Configuration Description)를 AUTOSAR에서는 시스템 기능과 공급업체 관련 기능을 명시하는 통해 생성되어 진다.(예 : 네트워크 상의 통신) ECU 구성 설명은 각 ECU별 추출 정보(An ECU Extract of the System Configura- 전체 ECU 소프트웨어의 동작에 핵심적인 역할을 하며, 추가적인 tion) 파일이 있다. 개발을 진행하면서 단계적으로 확장 및 수정된다.
ECU 소프트웨어용 AUTOSAR 아키텍처의 기본 구성 요소는 다음 AUTOSAR를 이용한 진단 과 같다. AUTOSAR의 진단 소프트웨어는 DCM, DEM 및 FIM이라는 세 개 > Functional software (SWC) 의 모듈로 구성된다. 진단 통신 관리자(DCM: Diagnostic Com- > Run-Time environment (RTE) munication Manager)는 ISO 14229-1(UDS) 및 SAE J1979(OB- > Basic software (BSW) DII)에 따라 진단 통신을 구현한다. 모든 진단 요청은 먼저 DCM 을 통해 전처리 과정을 거친다. DCM에서 수행하는 작업 중 하나 가상 기능 버스(VFB : Virtual Function Bus)에 의한 통신 추상화 는 유효하지 않은 진단 요청을 포괄적으로 처리하는 것이다. 를 통해 높은 수준의 기능 소프트웨어 재사용이 가능하다. 어플 DCM은 유효한 요청을 대부분 완벽하게 처리할 수 있고 기타 다 리케이션은 내부적인 통신 메커니즘에 대한 지식이 없어도 개발 른 요청은 기능 소프트웨어로 라우팅한다. 각각의 AUTOSAR 릴 되거나 테스트될 수 있다. 이때, 필요한 통신 기능이 ECU내부에 리스에서는 DCM의 기능 범위가 증가해 온 반면 기능 소프트웨 서 수행되는지 차량 네트워크상(CAN, FlexRay, etc.)에서 수행되 어의 나머지 진단 컨텐츠는 지속적으로 감소해 왔다. DID(데이터 는지는 고려할 필요가 없다. RTE가 이를 위해 특정 ECU를 위한 ID)의 처리는 이러한 발전 과정을 보여 준다(그림 3). 버전 3까지 가상 기능 버스를 구현하고 실행 환경(Runtime Environment)을 는 신호 구조를 기능 소프트웨어에서 확인해야만 했다. 하지만 제공한다. 기본 소프트웨어는 컴포넌트 키트로 개발되어 상용화 버전 4에서는 이 작업을 DCM에서도 처리할 수 있다. AUTOSAR와 ODX를 이용한 진단 솔루션 (기성품 소프트웨어)되며, 기본적인 시스템 기능들을 포함하고 하드웨어로부터 기능 소프트웨어를 추상화하며, 세 가지 영역으 DCM은 ECU 구성 설명을 토대로 구성되며, SID(서비스 ID), Sub- 1부: AUTOSAR를 이용한 진단 로 나뉜다(그림 2). function(하위 기능), 관련 신호 구조를 지닌 DID, 파라미터 목록 > AUTOSAR는 ECU 소프트웨어를 위한 미래 지향적인 참조 아키텍처로, 명확하게 지정된 인터페이스, 표준화된 동작 및 XML 기반의 Service Layer: BSW 및 그 밖의 BSW 모듈에 대한 기본 서비 을 지닌 Routine ID가 여기에 포함된다. 또한 진단 요청은 ECU의 데이터 형식은 이 표준의 핵심 사양이다. AUTOSAR에서는 통신 담당의 DCM과 오류 메모리 담당인 DEM 모듈에서 진단 기능을 처 스 제공 현재 상태(세션 및 보안 레벨)에 따라 실행할 수 있다. > 리한다. 본 1부 기사에서는 먼저 AUTOSAR의 진단 기능 및 이와 관련된 데이터 형식에 대해 다루기로 한다. 한편, ODX(Open ECU Abstraction Layer: ECU 하드웨어로부터 상위 레이어들 Diagnostic Data Exchange) 형식의 진단 데이터베이스는 진단 소프트웨어를 구성하기 위한 대안으로 활용되고 있는데, 이를 2부 의 추상화 에서 “AUTOSAR 개발 프로세스의 ODX”라는 주제로 설명하겠다..
Vehicle A 표준화는 자동차 전자 장치 개발 부문에서 굉장히 부각되고 있는 > 모든 ECU 및 차량 등급을 포괄하는 확장성 Vehicle B 이슈이다. 개방형 아키텍처와 구성 가능한 컴포넌트를 사용하면, > ISO 26262의 안전 요건 고려 Hardware 개발자는 개발 프로세스의 혁신적이면서도 차별화를 구현하는 Topology 측면에 좀 더 집중할 수 있게 된다. 또한 표준화는 비용 절감에 오늘날 AUTOSAR는 ECU 소프트웨어를 위한 참조 아키텍처로, 기여하는 핵심적인 수단이기도 하다. 과거에는 자동차 ECU 소프 머지 않아 완전한 AUTOSAR 소프트웨어를 활용한 최초의 양산 Functional Library Software 트웨어 아키텍처가 표준화되지 않았다. 이로 인해 공급업체는 제품이 출시될 예정이다. 또한 AUTOSAR 방법론을 활용한 개발 Configuration 개발 프로세스, 개발 툴 및 데이터 교환 형식이 OEM별로 각기 프로젝트의 수도 계속해서 늘어나고 있다. 현재 AUTOSAR 컨소 Lighting 다른 소프트웨어 아키텍처를 사용해야 했다. 시엄에서는 버전 3.2 및 4.x에 대한 연구를 진행 중이다. 이보다 Seat Heating AUTOSAR(AUTomotive Open System ARchitecture)는 공통된 개 앞서 발표된 버전 2.x, 3.x 및 4.0은 이미 차량 프로젝트 구현을 위 Air Conditioning 방형 자동차 소프트웨어 아키텍처를 표준화한다는 명백한 목표 한 기초 역할을 하고 있으며, 최근 대부분의 차량 제조업체에서 를 두고 있다. 특히, AUTOSAR 아키텍처의 주된 목표는 다음과 는 버전 3.x를 따르고 있다. Distributed 같다. System > 하드웨어 추상화 기능 지향성은 전자 개발 부문에서 날로 중요성이 더해가고 있 > 명확하게 지정된 인터페이스 다. AUTOSAR에서는 개별 부품 또는 차량 기능에 대한 설명은 물 > 기본 소프트웨어 동작 표준화 론 시스템 구성 설명(System Configuration Description)이라는 ECU Extract > OEM과 공급업체 간의 데이터 교환 형식 표준화 전체 시스템에 대한 설명과 차량 기능을 ECU에 분배하는 방법까 of System Description 그림 1: > 조화로운 소프트웨어 개발 방법론 정의 지 표준화하고 있다. 따라서 개발된 기능을 변경할 필요없이 다 AUTOSAR에서의 기능 분산 > 모델 기반 기능 개발 지원 른 차량 프로젝트에서 재사용할 수 있다.
4/10 4/11 The Standard Mix does it:
Application [6] ISO 22901: Road vehicles – Open diagnostic data AUTOSAR Runtime Environment exchange (ODX) [7] Klaus Beiter, Oliver Garnatz, Christoph Rätz: Gesetzliche System Memory Comm. On-Board-Diagnose und ODX, Diagnose in mechatronischen Fahrzeugsystemen III S. 44 ff., Expert-Verlag 2010 Services Services Services I/O Signal Dr. Klaus Beiter Onboard Memory Comm. Interface Complex 클라우스 바이터(Klaus Beiter) 박사는 슈트트가르트에 위치한 벡터 인 Device Hardware Hardware Device 포매틱(Vector Informatik GmbH)에서 자동차 진단 제품 라인 개발 팀 을 이끌고 있으며, ASAM/ISO ODX 연구 그룹의 회원이다. Abstraction Abstraction Abstraction Drivers
Micro- Memory Comm. I/O controller Drivers Drivers Drivers Drivers Oliver Garnatz 올리버 가르나츠(Oliver Garnatz, 공학 석사[FH])는 벡터 인포매틱 임베 Microcontroller 디드 소프트웨어 컴포넌트 부문의 제품 관리자로, ISO 자동차 진단 및 AUTOSAR 부문의 회원이다 Microcontroller ECU Abstraction Service Abstraction Layer Layer Layer 그림 2: BSW의 구조
Christoph Rätz 크리스토프 래츠(Christoph Rätz, 공학 학사[BA])는 슈트트가르트의 협 진단 이벤트 관리자(DEM: Diagnostic Event Manager)는 오류 메 의 수, 확장된 오류 데이터(스냅샷 및 확장된 데이터 레코드) 등 동 주립 대학교(Cooperative State University)에서 전산학을 전공했으 며, 벡터 인포매틱에서 진단 제품 라인의 전 세계 제품 라인 관리자로 모리를 구현한다. AUTOSAR 버전 3.x(포함)까지 DEM은 그저 껍 과 관련된 정보를 포함한다. 근무하고 있다. 데기에 불과했는데, 이는 오류 메모리 동작에 대한 세부 사항이 OEM별로 다르기 때문이다. 버전 4부터는 OEM에 구애받지 않는 기능 제한 관리자(FIM: Function Inhibition Manger)는 유효 오류 오류 메모리 표준화를 목표로 메모리의 동작을 AUTOSAR에 정 발생 시 특정 기능이 실행되지 않도록 하고, 대체 기능을 시작하 의할 수 있게 되었다. 며, 부가적인 오류를 억제하는 역할을 한다. FIM 역시 ECU 구성 설명을 통해 구성된다. DEM에서 수행하는 주요 작업은 다음과 같다. AUTOSAR를 이용한 진단을 가능케하는 BSW 모듈 > DTC 상태 비트 관리 벡터(Vector)의 MICROSAR 제품 라인은 ECU 소프트웨어를 위한 > 오류 코드 저장소 구성 (NVRAM 포함) AUTOSAR 솔루션이다. 제품에 포함된 RTE와 BSW 모듈은 AUTO- > 스냅샷 데이터(Freeze Frame) 구성 SAR 표준의 모든 범위를 포괄하고 있다. 각각의 AUTOSAR BSW > 확장된 데이터 레코드 관리 모듈은 MICROSAR 패키지에 할당된다. 특히, MICROSAR DIAG > 오류 망각(Unlearning)에 대한 대비 패키지는 진단을 위해 특별히 제작되었으며, 세 개의 BSW 모듈 > DCM용 오류 판독 인터페이스 제공 (AUTOSAR 아키텍처의 DCM, DEM 및 FIM)이 포함되어 있다. MICROSAR DIAG를 진단 소프트웨어로 사용할 경우 차량 프로젝 진단 모니터를 위한 표준화된 인터페이스와 다양한 디바운스 알 트에서 UDS 프로토콜인 ISO 14229-1:2006을 AUTOSAR와 호환 고리즘은 다른 프로젝트간에 기능 소프트웨어를 일관된 방식으 되도록 구현할 수 있다. 로 개발될 수 있도록 도와준다. 또한 하나 이상의 오류 경로를 진 참고: 제2부 “AUTOSAR 개발 프로세스의 ODX”도 www.vector. 단 문제 코드(DTC: Diagnostic Trouble Code)에 매핑하는 것이 가 com/downloads/에서 다운로드할 수 있다. 능하다. DEM도 ECU 구성 설명을 통해 구성되며, 오류 경로, DTC 독일 출판물 Hanser Automotive 2011년 10월호 번역판
SID DID Data 참고문헌: [1] AUTOSAR specifications: www.autosar.org [2] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue Request 22 FF EE Wege zur Steuergeräte-Software Teil 1, Elektronik automotive 11.2009 Response 62 FF EE AA BB CC [3] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue Wege zur Steuergeräte-Software Teil 2, Elektronik automotive AUTOSAR 2.1 3.x 4.x 12.2009 Version [4] ISO 14229: Road vehicles – Unified diagnostic services (UDS) 그림 3: AUTOSAR DCM의 발전 과정 [5] ISO 26262: Road vehicles – Functional safety
4/12 4/13 ODX는 2008년 ISO 표준 22901-1에 발표되었다. ASAM은 2004 생성하는데 사용될 수 없다. ECU는 진단 요청에 대해 모호하지 년 ODX 2.0.0을 표준의 첫 번째 버전으로 공개했었다. ISO의 않은 방식, 곧 정의된 방식으로 반응해야 하기 때문이다. 위 두 가 발표가 있기 전에 다시 두 개의 ASAM 릴리스가 발표되면서 지 사례를 통해 진단 데이터에 요구되는 품질이 각기 다르며 정 수정 사항, 설명, 개선 사항 및 확장이 이어졌다(그림 2). 반대일 수도 있다는 점을 알 수 있다.
ODX와 ECU 소프트웨어 따라서 진단 소프트웨어 컴포넌트가 ODX를 기반으로 생성되는 ODX를 통한 진단 데이터 작성자는 사용된 구조와 관련해 자유 경우, 위에서 예시한 요구 사항을 따르지 않는 표준의 일부분(사 롭게 데이터를 수정 및 편집할 수 있게 되었다. 즉, 동일한 한 가 양 품질)은 제거되어야만 한다. 다음 목록에서는 사양이 지녀할 지 동작을 다양한 방식으로 설명할 수 있는 것이다. 이를 통해 사 특성을 위반하는 일부 데이터 구성을 보여 준다. 용자는 특정 테스트 시스템에 사용할 진단 데이터를 최적화된 방 > 진단 요청 하나에 대한 여러 개의 응답(위의 내용 참조) 식으로 준비할 수 있다. 그럼에도 불구하고 툴을 처리하는 과정 > 기본 프로토콜에 정의되지 않은 진단 서비스(예: UDS-ECU 내 에서 툴이 지원하는 표준에 대한 제약 조건으로 인해 상상 가능 KWP 서비스) 한 모든 변형을 사용하기에는 부족한 상황이 계속 이어질 것이 > 서비스 시그니처(SID/LID)가 동일해 명확하게 정의된 ECU 다. 사용된 구조가 두 영역에서 모두 지원된다면 서로 간에 데이 동작을 수행할 수 없도록 하는 여러 진단 서비스 터를 교환할 수 있다. 교환 가능한 컨텐츠를 문서화하는 데 일반 > 오류 메모리에 특수한 문맥 규칙 사용. ODX 표준의 목표가 적으로 사용되는 방법은 가이드라인과 같은 지침을 작성하는 것 오류 메모리에 대한 세부적인 설명을 ODX로 제공하는 것은 이다. 이러한 지침에서는 프로세스 파트너에게 사용할 ODX 종속 아니다. 원칙적으로는 DTC에 대한 추가 정보를 설명할 수 있 집합의 유형과 범위를 지정한다. 이 접근 방식은 현재 완전히 정 지만 이 표준은 여기서 형식만 지정한다(SDG = 이름-값 쌍의 립된 상태이다. 또한 ODX 표준화에 참여한 자동차 OEM들은 이 인터리브된 목록). 반면 데이터의 의미는 정의되지 않으므로 미 관련 프로세스에 착수해 자동차 OEM 간의 데이터 교환을 위 자동화된 툴에서의 일반적인 처리는 불가능하다. 한 작성 지침을 제작했다(ODX-RS[Recommended Style]). > 광범위하게 사용되는 ODX 버전 2.0.1에는 세션/보안 레벨에 대한 진단 서비스의 종속성을 설명하는 메커니즘이 없다. 따 ODX 표준화는 하나의 데이터베이스를 이용해 테스트 시스템의 라서 종속성 테스트와 그에 대한 결과로 얻어지는 부정 응답 파라미터화 과정을 표준화하려는 목표에서 비롯되었다. 다른 애 을 생성할 수 없다. 이러한 항목은 개별 애플리케이션에서 구 AUTOSAR와 ODX를 이용한 진단 솔루션 플리케이션 영역에서는 데이터의 호환성이 제한적인데, 이는 애 현해야 한다. 하지만 ODX 2.2.0 버전에서는 이러한 문제가 더 플리케이션 영역마다 세부 사항의 구조 및 정도에 대한 요구 사 이상 존재하지 않으며, 여기서는 상태 정보를 공식적으로 설 2부: AUTOSAR 개발 프로세스의 ODX 항이 각기 다르기 때문이다. 일반적인 테스터는 가능한 한 많은 명할 수 있다. ODX(Open Diagnostic data eXchange) 형식은 차량 진단과 관련된 데이터를 설명하기 위한 XML 기반 데이터 형식으로, 자동차 차량 구성 또는 ECU 구성을 지원해야 한다. 여기서 테스터 데이 OEM과 해당 공급업체 간에 진단 데이터를 교환하기 위해 개방형 형식으로 개념이 정립되었다. AUTOSAR는 ECU 소프트웨어를 터에 대한 다중 설명을 통해 사용자는 유연성을 얻게 된다. 예를 목록에서는 ODX 표준의 준수가 필요하지만 소프트웨어 컴포넌 위한 미래 지향적인 참조 아키텍처로, 명확하게 지정된 인터페이스, 표준화된 동작 및 XML 기반의 데이터 형식은 이 표준의 핵심 들어 ODX에서는 진단 서비스 하나에 대해 여러 개의 ECU 응답 트를 파라미터화하기에는 부족한 상황을 보여 준다. 표준에 정의 사양이다. 이 기사는 “AUTOSAR 및 ODX 기반의 진단 솔루션” 시리즈의 두 번째 기사이며, ODX에 관한 설명과 ODX 데이터를 을 설명할 수 있다. 런타임 시에는 적절한 응답을 활용해 진단 데 된 규칙에서는 주로 테스터 파라미터화와 관련된 사용 사례를 다 AUTOSAR 개발에 통합해 이점을 얻는 방법에 대해 다루고 있다. 이터를 해석하는데, 이는 특히 ECU에서 실행 중인 특정 소프트 웨어를 확실히 알지 못하는 경우에 유용하다. 반면, 사양 품질에 포함된 정확한(다중 설명이 없는) 데이터 설명은 코드 생성에 중 요한 역할을 한다. 응답이 여러 개인 설명은 ECU 소프트웨어를 ASAM/ISO 연구 그룹 내 ASAM에서 제정된 ODX는 2003년 이후 플래시 컨테이너, ECU 구성, 기능 중심적 진단 그리고 소위 다중 ISO에 의해 표준화되었다. ODX가 개발된 이유는 이전에 진단 데 ECU 작업은 위 네 개의 종속 모델로 설명되어 있는데, 이들 모델 이터 교환을 위해 승인된 표준이 없었기 때문이다. 프로세스의 의 처리와 중요성은 먼저 언급한 종속 모델들에 비해 낮다. 경계를 넘어 진단 데이터를 교환하려면 반드시 많은 노력을 거쳐 Jobs ODX-M 야 했다. ODX 표준화의 핵심 목표는 데이터의 재사용인데, 이는 이 기사에서는 ODX-D와 ODX-FD에 대해서만 자세히 다룰 예정 Function-oriented 서로 다른 업무 영역에서 여러가지 툴을 사용해 데이터를 처리하 인데, 이 두 범주는 AUTOSAR와 관련해 매우 중요한 부분이다. Diagnostics ODX-FD 기 위함이다. ODX-D에 포함된 서비스 설명에서는 진단 요청 및 이와 연관된 ECU Configuration ODX-E
응답과 함께 송신된 데이터의 해석을 정의한다. ODX-FD는 R
A Flash Data ODX-F 버전 2.2.0의 ODX 데이터 모델은 7개의 종속 모델로 구성되어 있 ODX-D가 확장된 형태로, 차량 기능의 진단 관련 측면을 설명할 S O T
다(그림 1). 표준화 작업에서는 진단 테스터를 파라미터화하는데 수 있다. 차량 기능은 필요한 조건에 따라 계층식으로 구조화 및 U Vehicle Access ODX-V A 중점을 두었다. 따라서 진단 서비스 설명, 통신 파라미터 및 차량 그룹화할 수 있으며, 각 기능에는 입/출력 파라미터와 진단 데이 Communication ODX-C 액세스 설명이 포함된 아래 세 개의 종속 모델은 표준의 실질적 터(예: DTC, DID)를 할당할 수 있다. 이 데이터는 특정 값이 지정 Parameter 인 핵심 요소이다. 동시에 이들은 데이터 해석을 포함해 ECU와 되며 ODX-D 섹션의 참조를 통해 진단 서비스에 할당된다. ODX- Off-board Tester 테스터 간의 통신에 필요한 일반적인 컨텐츠를 구성한다. FD는 본질적으로 차량 진단 정보를 기능 측면에서 문서화한다. Diagnostic Services ODX-D 차량 기능에 문제가 발생하는 경우 ODX-FD 데이터를 사용해 기능과 잠재적인 오류 원인(즉, ECU, 센서 및 액추에이터) 간의 그림 1: ODX 데이터 모델 그림 2: ODX의 역사 관계를 확인할 수 있다.
4/14 4/15 The Standard Mix does it:
Dr. Klaus Beiter AUTOSAR 4는 좀 더 강력하며 이러한 변환 정보도 포함할 수 있 ODX-E ODX-E 클라우스 바이터(Klaus Beiter) 박사는 슈트트가르트에 위치한 벡터 인 ODX-V ODX-C ODX-V ODX-C 다. 그러나 ECU 파라미터화의 사용 사례와 대개 관련이 없기 때 포매틱(Vector Informatik GmbH)에서 자동차 진단 제품 라인 개발 팀 을 이끌고 있으며, ASAM/ISO ODX 연구 그룹의 회원이다. ODX-FD Authoring ODX-FD 문에 여기서 실제로 기술되는지는 확실치 않다. 추가적으로 기능 Guidelines 중심적인 접근 방식에서는 이 기사에서 설명한 것처럼 진단 컨텐 ODX-F ODX-F ECU Specification 그림 3: ODX에 의한 테스트 츠를 차량 간에 일치시키지 못한다. 따라서 미래의 진단 데이터 시스템의 파라미터화(왼쪽). ODX-D ODX-D 가 어떤 방향으로 나아갈지는 미지수이다. 경험상 여기에서 논의 Oliver Garnatz ODX-M Tester Model ODX-M 작성 지침과 함께 ODX에 의한 된 여러 온전한 접근 방식이 보급되는 대신에 특정 개발 상황에 올리버 가르나츠(Oliver Garnatz, 공학 석사[FH])는 벡터 인포매틱 임베 SWC의 파라미터화(오른쪽). 디드 소프트웨어 컴포넌트 부문의 제품 관리자로, ISO 자동차 진단 및 맞게 수정되고 서로 혼합될 것으로 전망된다. AUTOSAR 부문의 회원이다.
통합 루고 있다. 사양 품질을 보장하려면 다양한 일관성 검사를 수행 명이 없더라도 AUTOSAR 기능에서 추출할 수 있다(그림 4, 1단 각기 다른 종속 프로세스를 해당 프로세스의 다양한 인터페이스 해 여기에 나와 있는 것 같은 데이터 배열을 제외해야 한다. 계 참조). 결과로 생성되는 ODX-FD 설명에는 ODX 형태로 나타 (인터페이스, 데이터 형식 등)와 통합하는 일은 AUTOSAR와 ODX Christoph Rätz 크리스토프 래츠(Christoph Rätz, 공학 학사[BA])는 슈트트가르트의 협 낸 AUTOSAR 기능의 구조와 그룹화 구성이 반영된다. 이 단계까 같은 신기술을 도입하는 과정에서 발생되는 가장 큰 문제들 중 동 주립 대학교(Cooperative State University)에서 전산학을 전공했으 요약하자면 다음과 같은 그림으로 정리할 수 있다. 여기서 ODX 지는 아직 ODX-D 컨테이너에 연결할 수 없다. 즉, 기능과 특정 하나이다. 과거의 경험에 비추어보면 가장 효율적인 접근 방식은 며, 벡터 인포매틱에서 진단 제품 라인의 전 세계 제품 라인 관리자로 근무하고 있다. 는 테스트 시스템을 파라미터화하는 데 필요한 요구 사항을 충족 진단 데이터를 매핑할 수 없는 것이다. 이러한 기술을 도입할 때 실무 중심적인 솔루션을 활용하는 것이 하도록 디자인되었다(그림 3[왼쪽] 참조). 하지만 소프트웨어 컴 다. 벡터(Vector)는 포괄적인 AUTOSAR 및 ODX 툴 체인을 함께 포넌트 파라미터화 시, 자유롭게 구현 가능한 정도가 사양이 요 위의 내용을 통해 소프트웨어 컴포넌트를 구성하는 데 필요한 정 공급하는 업체이다. 또한 www.autosar-solutions.de 및 www. 구하는 정도로 제한된다고 가정한다(그림 3[오른쪽] 참조). 이를 보는 기본적으로 ODX-D에서 확인할 수 있음을 알게 되었다. odx-solutions.de에 들어가면 이 주제에 대한 자세한 정보를 확 위해 작성 지침을 사용한다. AUTOSAR에서는 ECU 구성이 ECU 구성 설명에 기술되며 여기서 인할 수 있다. ECU 소프트웨어도 생성된다. 따라서 ODX-D 데이터(있는 경우) 참고: 제1부 “AUTOSAR를 통한 진단”도 www.vector.com/down- AUTOSAR와 ODX 를 ECU 구성 설명으로 전송하고 이를 AUTOSAR 프로세스에 사 loads/에서 다운로드할 수 있다. ODX와 AUTOSAR는 ECU 소프트웨어 개발이나 차량 또는 개별 용할 수 있다. ODX-D 데이터의 존재 여부와 그 정도는 자동차 ECU의 진단 데이터 설명을 위해 정립된 표준이다. 따라서 사용 OEM과 공급업체 간의 협력 모델에 따라 달라진다. 극단적인 경 독일 출판물 Hanser Automotive 2011년 11월호 번역판 가능한 ODX 데이터를 ECU 소프트웨어의 진단 컨텐츠 개발에 어 우에는 ECU를 아예 처음부터 새로 개발해야 한다(그림 4, 2a단계 떻게 통합할 것인지를 결정하는 것이 타당하다(DCM/DEM). 참조). 이 경우 OEM은 진단 컨텐츠의 많은 부분을 공유하도록 규 참고문헌: AUTOSAR 개발은 매우 기능 중심적이다(지난 호[2011년 10월]의 정한다. 다른 극단적인 경우에는 기존 ECU를 새 차량에 통합하 [1] AUTOSAR specifications: www.autosar.org 이 시리즈 기사 1부 참조). 따라서 개발 초기 단계에는 주로 기능 게 된다(그림 4, 2b단계 참조). 그런 다음에 진단 결과를 변경하 [2] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue 설명과 정의가 만들어진다. ODX-FD는 ECU 기능과 진단 컨텐츠 려면 엄청난 노력이 수반되어야 한다. 따라서 진단이 기능보다는 Wege zur Steuergeräte-Software Teil 1, Elektronik automotive 간의 격차를 메워 주지만 주로 테스터와 관련이 있다. 그러므로 ECU에 의해 훨씬 더 많은 영향을 받게 된다. 11.2009 ODX-FD 데이터는 아직 ODX-D 데이터 형태의 구체적인 진단 설 [3] Pascale Morizur, Matthias Wernicke, Justus Maier: Neue 일반적으로는 어느 쪽의 극단적인 경우도 단독으로 적용할 수 없 Wege zur Steuergeräte-Software Teil 2, Elektronik automotive 으며 각각의 접근 방식이 혼합된다. 대개 진단 요구 사항은 자동 12.2009 차 OEM과 공급업체 간에 기능 및 ECU 측면 그리고 해당 주변기 [4] ISO 14229: Road vehicles – Unified diagnostic services 기 측면에서 지정되어 최종적으로 ECU에 대한 ODX-D 데이터를 (UDS) AUTOSAR Functions 산출하게 된다. 그런 다음에는 ODX-FD 데이터를 ODX-D 데이터 [5] ISO 26262: Road vehicles – Functional safety OEM/Supplier 2a 1 에 연결할 수 있다(그림 4, 3단계 참조). 이러한 ODX-D 데이터를 [6] ISO 22901: Road vehicles – Open diagnostic data ex- Coordination 통해 ECU 구성 설명이 생성되어 소프트웨어 컴포넌트를 제작하 change (ODX) 3 기 위한 토대가 형성된다(그림 4, 4 및 5단계 참조). 그뿐만 아니 [7] Klaus Beiter, Oliver Garnatz, Christoph Rätz: Gesetzliche ODX-FD 2b ODX-D 라 ODX-FD 및 ODX-D 데이터는 테스터 런타임 형식을 생성하기 On-Board-Diagnose und ODX, Diagnose in mechatronischen ECU ECU 위한 기초가 되기도 한다(그림 4, 7단계 참조). 프로세스의 두 측 Fahrzeugsystemen III S. 44 ff., Expert-Verlag 2010 4 7 면(소프트웨어 컴포넌트와 테스터 파라미터화) 모두에 대한 토대
ECU-C 로 ODX를 사용하면 각기 다른 개발 버전의 테스터 및 ECU가 서 로 정확하게 일치하게 된다.
Generator 5 Runtime Format 여기서 반대의 프로세스도 가능한지에 대한 질문이 떠오르게 된 다. 즉, ECU 구성 설명에서 ODX-D를 생성할 수 있는지의 여부가 *.c *.h 궁금할 수 있다. 이에 대한 답변은 사용 중인 AUTOSAR 버전에 8 6 따라 부분적으로 달라진다. 3.x(포함) 버전까지의 AUTOSAR 형식 은 테스터 파라미터화에 필요한 핵심 정보를 설명할 만큼 강력하 ECU Communication 지 않다. 예를 들면 이들 버전에는 데이터 객체에 대한 변환 정보 가 없다. 그림 4: ODX와 AUTOSAR의 결합
4/16 4/17 데이터 보호 추에이터를 작동시킬 수 있다는 점이다. 이는 원격 진단이 로거 그러나, 모든 진단 데이터를 서비스센터용 테스터에 탑재해 보급 또는 온보드 테스터를 이용하는 방법과 어떤 차이가 있는지를 보 하는 것도 해결책은 아니다. 이런 경우에는 시스템에 대해 불필 여주고 있다. 요하고 매우 넓은 범위로 시스템 조정의 가능성이 있기 때문이 다. 시스템의 조정은 소수의 전문가 그룹에 맡기도록 해야 한다. 고도의 성능과 데이터 보호를 제공하는 원격 진단 그러므로 필요한 데이터와 기능은 소수의 사용자 그룹만이 보안 성공적인 원격 진단을 위해서는 진단 요청이 고속으로 지연 없이 을 유지하면서 액세스하거나 관리하도록 해야 한다. 이렇게 하면 처리되어야 한다. 벡터에서 출시한 Indigo 진단 테스터의 최신 제3자가 별도의 승인 없이 개별 시스템의 기능이 어떻게 구현되 버전(Version 4.0)에서는 위에서 설명한 대화형 원격 진단 기능을 고 수정되었는지에 대한 정보에 액세스하기 어렵게 된다. 서비스 지원한다(그림 1). 센터에는 용도에 맞는 기능만을 테스터에 탑재하고 구동 방식을 가급적 간단하게 하면, 의도하지 않은 운영상의 오류를 방지할 기존의 진단 테스터는 네트워크 인터페이스를 통해 차량에 직접 수 있다. 접속한다(그림 2). 이 경우에는 현장에서 필요한 모든 진단 데이 원격 진단 터와 진단 및 모듈에 대한 지식에 액세스할 수 있어야 한다. In 대화형 원격 진단 digo에서 원격 진단 기능을 사용하려면 기존의 진단 테스터를 액 대화형 진단 툴을 통한 원거리 차량 진단 대화형 원격 진단 툴을 사용하면, 전문가와 차량이 물리적으로 세스 포인트로 대체해야 한다. 인터넷상의 통신 서버와 함께 이 멀리 떨어져 있는 문제를 해결할 수 있다. 전문가는 마치 현장에 툴은 라우팅 허브로 작용하여 차량과 실제 진단용 테스터 간에 있는 것처럼 차량에 접속하여, 자신들의 전문 지식을 발휘할 수 진단 요청과 응답을 라우팅한다(그림 3). 실제 진단용 테스터는 있다. 전문가가 측정값을 읽고 해당 컴포넌트의 동작을 면밀하게 멀리 떨어진 곳에 전문가가 사용하고 있다. 현장에 진단 데이터 관찰하는 동안 서비스센터의 작업자들은 브레이크 페달을 작동 를 보내거나 전문가를 파견할 필요는 없지만, 차량에 직접적으로 시키는 등의 지원활동을 수행할 수 있다. 차량의 조건만 맞는다 액세스하는 것이 가능하다. 면, 전문가가 먼 곳에서 액추에이터를 작동하는 것도 가능하다. 전문가는 처음에 생각한 고장 원인이 맞는지 확인하기 위해 추가 T원격 진단을 이용하려면 차량에서 액세스 포인트를 다운로드하 적인 조치를 하든가 배제하든가 할 수 있으며, 이를 통해 문제의 여 ID와 패스워드를 입력한 후 진단 세션에 전문가를 초대하면 원인을 효과적으로 파악할 수 있다. 된다. 테스트 시스템은 즉각적으로 사용할 준비가 되기 때문에, 진단 툴은 차량 컴포넌트 각각의 오류를 신속하고 효율적으로 확인하고 수정할 수 있는 중요한 툴이다. 그러나 전문가의 도움 없이 차량에 별도의 변경을 가하지 않아도 된다. 는 오류의 원인을 찾는 것이 불가능할 때가 있다. 이제 전문가들이 현장에 출동하지 않고도 대화형 원격 진단 툴을 사용해 차량에 직 앞에서 언급한 스웨덴의 테스트 드라이버의 경우에도 문제를 해 구현된 솔루션에서는 진단 데이터나 테스트 시퀀스, 보안 알고리 결하기 위해 전문가를 신속하게 파견하거나 개발 진단 데이터를 즘 등이 보호된 환경 내에 존재하기 때문에 제어나 해석, 평가 등 접 접속하여, 차량을 점검하고 오류 원인을 체계적으로 진단할 수 있게 되었다. 보낼 필요가 없다. 전문가의 안내에 따라 문제를 해결하면 되기 모든 활동은 전문가의 컴퓨터 상에서 수행하게 된다. 단대단 때문이다. 현장에서 문제에 대해 바로 연구할 수 있기 때문에, 스 (end-to-end) 인코딩을 통해 높은 수준의 데이터 보안을 달성했 웨덴에 돌아온 후에도 문제를 재현할 필요가 없다. 이는 특정한 다. 영하 20°C의 눈으로 뒤덮인 스웨덴의 얼어붙은 호수 위에서 테 업무에 따른 진단 툴 환경적 요인이 이상에 영향을 미친 경우에 더욱 중요하다. 스트 드라이버가 테스트 주행을 하고 있다. 그는 커브에서 브레 차량 진단에서 수리 기간, 수리 비용, 작업 완성도 등은 고객 만 그러나 원격 진단의 가장 큰 장점은 전문가가 측정 결과에 직접 모든 진단 기능을 효율적으로 사용하기 위해 넓은 대역폭과 낮은 이크를 작동시켰을 때 차량이 비정상적으로 움직이는 점에 주목 족도를 높이는데 핵심 요인이다. 진단 툴은 차량 개발에서 양산, 대응하여, 추가적인 측정을 시행하고 파라미터를 수정하거나 액 지연시간을 보장하는 기술적 조치가 구현되었다. 이를 통해 대량 했다. 몇 가지 시험을 한 후, 이 테스트 드라이버는 이 비정상적 그리고 고객 서비스에 이르는 전 라이프사이클(Life cycle)에 걸 인 움직임이 특별한 조건 하에서만 발생한다는 것을 발견했다. 쳐 사용해야 하는 필수 툴이다. 차량의 각 라이프사이클 단계별 로 상당히 다른 요구사항을 설정하게 되는데, 진단 툴을 개발할 테스트 드라이버는 이 차량에 대해 잘 알고 있었지만, 시스템 개 때에는 반드시 이 점을 고려해야 한다. 차량을 개발할 때에는 발자에 의한 정밀한 분석이 필요하다. 시스템 개발자만이 비정상 ECU에 대해 심사숙고해야 하며 수많은 조정을 거칠 필요가 있다. 적인 움직임의 원인을 종합적으로 신속하게 찾을 수 있는 배경 양산 과정에서는 진단 툴이 “합격/불합격” 테스트에 사용된다. 서 지식을 가지고 있다. 그러나 이 엔지니어가 차량 진단 테스트를 비스센터에서는 편리한 트러블슈팅을 통해 특별한 지식 없이도 위한 핵심 데이터와 액추에이터를 가지고 있을 가능성은 매우 낮 고장 부분을 확인할 수 있으며, 나중에 수리가 제대로 되었는지 다. 원격 진단을 이용하면, 아무리 멀리 떨어진 곳에 있는 전문가 도 쉽게 확인할 수 있다. 라도 현장까지 갈 필요 없이 차량에 액세스할 수 있다. 결과적으로 진단용 테스터는 사용자에 의한 조정, 정밀도, 액세 사용 사례 스 성능 등 다양한 요구사항에 따라 상당히 달라지게 된다. 이에 전문가가 원격으로 차량이나 그 컴포넌트에 손쉽게 액세스할 수 따라 서비스센터용 테스터는 ECU에 구현된 진단 기능의 일부만 있다면 테스트 주행을 할 때에만 도움이 되는 것은 아니다. OEM 사용할 뿐이며, 그 외 다른 기능은 개발이나 양산용으로 사용하 과 공급업체도 양산을 시작한 후 시스템을 진단할 때 원격 진단 고 있다. 그러나 현장에서 예상하지 못한 문제가 발생한 경우, 전 기능의 혜택을 받을 수 있다. 문가가 개발 관련 정보나 기능에 접속해야 할 필요가 있을 수도 서비스센터에서도 전문가의 조언이 필요한 상황에 놓일 수 있다. 있다. 원격 진단 방식은 때때로 예측할 수 없는 복잡한 문제를 신속하 그림 1: 진단용 테스터 Indigo: 폴트 메모리 및 측정 게 해결하고 비용 면에서도 우수한 방법이다.
4/18 4/19 차이를 보인다. 진단 툴은 멀리 떨어진 곳에서 테스트 주행 중에 발생한 비정상적인 움직임을 조사하고, 서비스센터에서 예측하 지 못한 문제를 해결하는데 소요되는 시간을 상당히 단축시킬 수 있다. 특히 서비스센터에서는 원격 진단을 통한 3단계 지원을 효 율적으로 실시할 수 있어 수리에 소요되는 시간과 비용을 줄이 며, 고객 만족도를 높일 수 있다.
Rolf Weber 슈투트가르트에 소재한 벡터 인포마틱사의 진단 제품 라인 팀장이자 제품 매니저이다. 그는 진단 테스터 Indigo와 플래시 도구인 vFlash를 이용하는 진단작업에서 테스트 시스템을 담당하고 있다.
그림 2: 기존의 진단용 테스터 Christoph Rätz 슈투트가르트에 소재한 벡터 인포마틱사의 진단 제품 라인 담당 부장 이다.
의 데이터를 전송해야 하는 경우에도 세계 어디서나 차량에 신속 하게 접속할 수 있게 되었다.
요약 대화형 원격 진단을 이용하여 시스템이나 진단 전문가는 세계 어 디에서든지 차량에 접속하여 고장이 발생함과 동시에 오류를 검 사할 수 있다. 이런 프로세스에서 전문가는 현장에 비치된 고객 서비스용 테스트 시스템에만 의존할 필요가 없으며, 전문적인 툴 을 사용할 수 있다. 진단에 필요한 데이터를 다른 곳에 보낼 필요 도 없으며, 데이터는 전문 환경 내에서 보호된다.
벡터가 출시한 Indigo 진단 테스트 툴은 대화형 원격 진단을 지 원격 진단 원하고 온보드 진단 시스템의 정적인 진단 기능을 훨씬 뛰어넘으 며, 데이터 보호나 성능 면에서도 PC를 이용한 원격 시스템과 큰
전 세계를 연결하는 차량 진단 시스템
세상 어느 곳의 차량과도 직접적이고 상호적으로 접근할 수 있는 원격 진단 솔루션을 찾고 계십니까? Indigo Remote는 테 스트 드라이브 중에, 양산 중에 또는 서비스 센터에 있는 차량의 문제점을 원격으로 점검할 수 있습니다.
Indigo Remote의 장점: > 언제 어디서든 사용 가능한 원격 진단 > 하드웨어 인터페이스를 통한 포괄적인 차량 액세스. 타사 > 쉽고 빠른 셋업 인터페이스를 통해서도 액세스 가능. (PassThru API) > 최고의 데이터 보안: 진단 데이터, 프로세스, 보안 알고리 즘은 현장에서 불필요하므로 전송되지 않음 > 빠른 데이터 전송 및 매우 짧은 반응 시간 제품 정보 및 다운로드: www.vector.com/indigoremote
Indigo Remote를 이용한 원격진단은 신속하게 전문가의 의견을 제공하며, 진단 및 수리 시간을 감축시킵니다. 이는 비용 을 절감하면서 동시에 고객 만족도를 높입니다. 그림 3: Indigo를 이용한 대화형 원격 진단의 개념
4/20 그림 1: 시스템 구조: 클라스의 자동화된 진 단 기능 구현 테스트
데이터 기반 자동화된 진단 구현 검증 방식 I/O 종류 및 범위를 구체적으로 기술하고 있다면, 이것은 진단 구 이의 관계에 대해 알 필요가 있다. 진단값을 다음의 값과 비교하 현 검증 시험 방안을 만들어내는 데 사용할 수 있다. 특히 자동화 여 검증할 수 있다: 진단 프로토콜이 잘 구현되었는가를 검증하기 위해 자동으로 생성된 테스트를 사용하는 일은 수년 동안 실행되고 있다. 이러한 프 된 진단 파라미터 테스트 및 폴트 메모리 테스트(fault memory > ECU 핀의 측정값 로세스는 자동차 OEM에서 제공하는 진단 디스크립션 파일(diagnostic description file)을 바탕으로 진행된다. 검증 가능한 방법을 test)를 가능하게 한다. > 버스 신호 사용함으로써ECU의 진단 인터페이스를 효율적으로 테스트할 수 있으며, 이를 통해 제품의 품질을 개선할 수 있다. 또한, 클라스 > CCP/XCP 신호 (Claas)와 벡터의 협동 프로젝트에서 보여주고 있듯이 진단용 파라미터와 에러 코드의 검증을 자동화시키는 것 또한 가능하다. 물론 폴트 메모리 테스트 이것의 성공 여부는 진단 디스크립션이 얼마나 완전한지에 달려 있다. 폴트 메모리 데이터의 구조 및 정형화된 내용은 DID(Data Iden- 비교를 하기 위해서는 I/O 종류 및 명칭 이외에도 단위 변환 작 tifiers) 레이아웃(layout)이나 DTC(Diagnostic Trouble Codes) 설 업이 필요하다. 예를 들면, 센서의 저항값을 진단 파라미터인 온 정 조건과 같은 진단 데이터에서 가져온다. 그러나 DTC를 정의하 도값으로 변환하는 작업을 말한다. 진단 파라미터 또는 ECU 출 과제 설정되어 있는지, 에러 상태를 만든 후 그 에러가 메모리에 제대 는 방식은 일반적으로 정형화되어 있지 않다. 만약 진단 데이터 력값의 업데이트 주기 또한 반드시 고려해야 한다. 더욱이 I/O를 농업용 기계 제조업체인 클라스는 진단 데이터에 진단 파라미터 로 저장되는지를 테스트하는 것도 가능하다. 를 ECU의 주변 기기들과 상호 연관시킬 수 있도록 정리할 수 있 자극하기 위해서는 시험값이 필요한데, 그 이유는 이런 데이터는 와 ECU I/O 사이의 상호연관성 (interrelationships)을 추가로 표 다면, DTC가 폴트 메모리 내에 정확하게 저장되어 있는지 또는 진단 디스크립션 파일에 정의되어 있지 않고, 일반적으로 사양서 현하고 있다. 새로운 방식으로 구현하기 위해 에러 설정 기준을 자동화된 테스트 생성 적절한 조건을 따르고 있는지를 테스트하는 것도 가능하다. 또 도 적합한 값을 제공하고 있지 않기 때문이다. 형식에 맞춰 기술하고 있다. 과거에는 이러한 정보는 수작업으로 구현 검증 시험을 위한 테스트 생성 및 실행을 자동화하기 위해 한, DTC 상태 천이를 확인하거나 DTC를 적절히 소거하는 것도 가 테스트를 실시하거나, 테스트 담당 엔지니어가 특별한 테스트 케 서는 진단 파라미터와 ECU I/O를 서로 연관시켜야 한다. 진단 데 능하다. 폴트 메모리 테스트나 파라미터 테스트 모두 테스트할 기능을 동 이스를 구현하는 데 사용되었다. 그러나 아직 이러한 방법으로 이터 (ODX, CDD) 이외에도 간접적으로 참조할 수 있는 사양 데 작시키기 위한 전제 조건이 있는지를 확인할 필요가 있다. 예를 광범위한 테스트 범위를 모두 처리하는 것은 불가능했다. 이터 (specification data) 또한 사용된다. 여기에는 네트워크 디 각각의 DTC에 대해서는 반드시 구체적인 설정 조건을 알고 있어 들어, 농업용 세단기(field chopper)의 칼날을 갈기 위해서는 메 클라스는 진단 파라미터와 ECU I/O 사이의 관련 정보가 기존의 스크립션(dbc, arxml)이나 HIL 시스템의 인터페이스 디스크립션 야 한다. 이러한 조건에는 적어도 다음과 같은 것이 있다: 인 드라이브를 작동시켜야 하는 것과 같다. 테스트를 실행할 때 네트워크(통신 매트릭스) 및 하드웨어 디스크립션(description) 등과 같은 환경 설정이 포함된다. 이러한 시스템 정보는 테스트 > I/O 종류 (입력 또는 출력, 네트워크 또는 센서/액추에이터) 에는 이러한 상호 연관 관계를 이해하고 고려해야 한다. 에 자동으로 연결되도록 벡터와 프로젝트를 수행하였다. 환경에서 ECU의 입력 및 출력을 자극하거나 측정할 때 사용할 > I/O 이름 (메시지 이름, 채널 이름) CDD(CANdela Diagnostic Data) 또는 ODX(Open Diagnostic 수 있다. > 에러 패턴 (예를 들어, GND 단락회로). 클라스의 목표 및 이행 Data Exchange) 등과 같은 기존 사양의 데이터를 바탕으로 만든 오늘날 진단과 ECU 환경 사이의 상호 연관성을 표현하는 진단 에러 패턴은 표준화된 DTC(SAE J2012)의 FTB(Failure Type Byte) 클라스에서는 진단 구현 검증 테스트에 필요한 데이터의 상당 부 테스트 환경 내에서 완전하게 자동화된 진단 구현 검증 테스트를 데이터는 구체적으로 정의되어 있지 않은 상황이다. 이런 내용이 를 직접 사용할 수 있다. 에러 패턴에 따라 임계값, 설정 시간, 그 분이 정형화된 상태로 기술되어 있다. 그러므로 여기서 목표는 생성하여 수행하고 있다. ECU를 자동으로 자극(stimulation)하는 기술되는 경우에도 보통은 자연 언어로 기술된다. 리고 에러 정보와 같은 추가 정보가 필요할 수도 있다. 이러한 정보를 바탕으로 테스트를 생성하고 실행하는 과정을 자 환경을 이용하여 진단 기능과 연관된 하드웨어와 소프트웨어가 동화시키는 것이다. 이러한 목표를 달성하기 위해서 클라스는 벡 제대로 통합되었는지를 테스트한다. 이러한 작업은 버스 시뮬레 이 때문에 자동화된 테스트 프로세스를 만드는 것이 불가능하다. 진단 파라미터 테스트 터의 CANoe.DiVa 툴을 사용한다. CANoe.DiVa는 진단 데이터 파 이션을 통하여 신호값을 변경하거나 특정 하드웨어의 I/O를 구 여기서 경험적 지식(heuristics)이 도움이 될 수 있으며, 적어도 이 진단 파라미터 테스트(diagnostic parameter test)는 폴트 메모리 일(CDD)과 다른 소스의 I/O 정보를 임포트(import)하여 테스트 동함으로써 수행할 수 있다. 따라서 진단용 파라미터가 제대로 러한 지식을 테스트 자동화에 사용할 수 있다. 만약 OEM이 ECU 테스트와 유사한데, 이 테스트에서는 진단 파라미터와 ECU 핀 사 모듈을 자동으로 생성하기 위한 파라미터들을 설정한다. 그 후에
4/22 4/23 는 CANoe에서 DUT(Device Under Test) 테스트 환경과 함께 MS 엑셀 파일로 내보내고 DiVa가 그 파일을 읽어 들여 테스트 파 위해서는 ECU 환경에 대한 일부 전제 조건(precondition)을 충족 DiVa 테스트 모듈을 자동으로 실행시킨다. [그림 1 참조] 라미터를 설정한다. 시켜야 하는 경우이다.
클라스는 진단 구현 검증 테스트에 연관된 모든 데이터를 데이터 이 데이터를 이용하는 테스트에서는 에러 상황을 재현하기 위해 마찬가지로, 폴트 메모리 테스트도 에러 모니터링 기능이 활성화 베이스에서 관리하고 있다. 데이터는 또한 진단 디스크립션 파일 ECU의 I/O 값을 자극한다. 그다음 폴트 메모리에 정확한 DTC가 되어 DTC를 인식하고 폴트 메모리에 저장하기 전에 충족되어야 로 임포트되므로, 보통 이 진단 디스크립션 파일은 파라미터 테 저장되었는지를 확인한다. 이 에러로 발생한 DTC 상태 천이(DTC 할 전제 조건을 필요로 하는 경우가 있다. 현재 수행하고 있는 테 스트를 생성하기에 충분하다. 추가적인 단위 변환 정보는 ECU 핀 status transition)와 DTC 환경 데이터 또한 에러 상황을 정정하고 스트에 자가 복구(self-healing) 기능 테스트, 폴트 메모리 저장 장 닐스 니더마크(Nils Niedermark) 보다는 다른 단위를 사용하고 있는 I/O용 진단 파라미터에 대해 일정 시간 기다린 후 에러 상태를 다시 설정하도록 테스트함으로 소의 우선순위 설정, 그리고 동일한 DTC를 만드는 서로 다른 에 독일 하르제빈켈에 소재한 Claas의 전자 통합 개발 부서에서 개 서 필요하다. 이 데이터는 변환 규칙에 따라 신호값과 CANoe 시 써 검증할 수 있다. 각각의 안전 수준에 따른 폴트 메모리가 초기 러 상황 테스트와 같은 항목을 추가하여 보완할 수 있다. 테스트 발 담당 엔지니어로 일하고 있다. 스템 변수를 매핑 시키는 CANoe 매핑 작업에 사용된다. 화되었는지를 점검함으로써 폴트 메모리 테스트을 마무리한다. 솔루션은 향후 이 분야에서 지속적으로 발전하게 될 것이다. ECU 핀의 전압 및 전류를 측정하고 자극하기 위해 클라스는 [그 파라미터 테스트는 3가지 종류로 만들어진다: 림 2]와 같이 HIL 시스템으로 벡터의 VT 시스템을 사용하고 있다. 자동차 산업에는 또한 전기/전자 아키텍쳐에 사용되는 개발 데 진단 디스크립션 파일 및 개발용 데이터베이스의 데이터를 이용 이터를 병합하는 방향으로 나가려는 주목할 만한 경향이 있다. > 입력 테스트 : 이 테스트 환경에서는 ECU의 센서 입력단을 자 하여 자동으로 VT 시스템을 구동하기 위하여 VT 시스템 구성용 여기서 데이터베이스와 툴은 직접 또는 간접적으로 정보를 수집 극한다. 연관된 진단 파라미터를 으로 명명 규칙(name convention)이 정의되어 있다. 하고, 수집한 정보는 진단용 소프트웨어를 통해 I/O 라인의 전기 읽은 다음 이를 해당 핀에서 측정한 값과 비교한다. 적인 연결 및 기능의 전자적인 통합 상태를 자동으로 테스트하는 > 출력 테스트 : ECU에 새로운 값을 입력하는 진단 서비스 (I/O 테스트 범위의 확대 데 사용될 수 있다. Control)로 액추에이터를 구동한다. 나중에 이 출력 값을 측 클라스는 진단 기능이 있는 ECU를 콤바인(combine harvester) 초기에는 데이터의 형식화(formalization) 작업에 상당한 노력이 정한 다음 진단 파라미터값과 비교한다. 및 트랙터에서 사용하고 있을 뿐만 아니라 제초기 및 베일 프레 필요하다. 무엇보다도 데이터의 형식화는 자동화된 테스트의 최 프리드만 로브(Friedemann Löw) > 수동 테스트 (passive test) : 일부 신호는 진단 서비스에 의해 스(baling press)와 같은 기계에서도 사용하고 있다. 클라스의 최 적화 가능성을 높이게 되어 개발 노력이 헛되지 않게 할 것이다. 독일 슈투트가르트에 소재한 벡터 인포마틱의 자동차 진단용 제 제어할 수 없으며, 단지 읽기만 할 수 있다. 이 신호들은 진 대형 기계 장치는 장비 옵션에 따라 ECU를 최대 40개까지 설치 표준화 분야의 진보(예를 들어AUTOSAR)와 개발 툴의 통합 및 상 품 라인에서 개발 업무를 담당하고 있다. 단 레이어(diagnostic layer)와 상관없이 ECU 응용 프로그램 한다. 이런 모델 계열 전체에 대해서 반드시 구현 검증 테스트을 호 운용성(interoperability)은 테스트 자동화 분야에서 새롭고 다 이 제어하고 있기 때문이다. 이런 경우, 진단 서비스로 값을 수행해야 한다. 이러한 테스트을 통해 클라스 진단 시스템 (CDS) 양한 접근을 이끌어내고 있다. CANoe.DiVa 툴은 이러한 추세를 읽고 이를 ECU의 입력 또는 출력값과 비교하는 테스트를 생 은 ECU 모듈들을 검증한다. 클라스에서 설치한 최대형 ECU는 75 따르고 있으며, 이와 같은 새로운 기회를 진단 구현 검증을 위해 성한다. 개 이상의 I/O를 지원하며, 설치된 기계의 옵션에 따라 최대 15 자동화된 테스트를 더 많이 생성하는 데 사용할 것이다. 파라미터 데이터와는 달리 클라스는 폴트 메모리 테스트를 수행 가지의 기능이 구현된다. 이러한 I/O와 연관된 DTC는 200개 이 데이터 기반의 자동화된 테스트가 갖는 성장 가능성은 매우 높으 하는 데 필요한 데이터 중 일부를 진단 디스크립션 파일에 정의 상이며 반드시 테스트을 통해 검증돼야 한다. 며, 이 분야는 앞으로도 활발하게 발전할 것이다. 하고 있지 않다. 그러므로 개발 데이터베이스에서 이런 데이터를 보다 많은 구현 검증 테스트의 생성 및 실행을 자동화시키게 되 면 ECU 검증에 드는 노력을 크게 줄일 수 있다. 클라스는 DiVa의 기본 테스트 생성 기능에 클라스만의 확장 기능을 추가하여 자동 화함으로써 폴트 메모리 및 진단 파라미터에 대한 테스트 범위를 그림 제공: Vector Informatik GmbH, Claas 시몬 뮬러 (Simon Müller) 과거 55%에서 현재 95%로 크게 넓힐 수 있었다. 클라스는 자사 링크: 벡터 홈페이지: www.vector.com 독일 슈투트가르트에 소재한 벡터 인포마틱의 자동차 진단용 제 가 생산한 모든 ECU에 대해 CANoe.DiVa 툴을 이용한 자동화된 품 라인에서 제품 매니저로 일하고 있다. 구현 검증 테스트를 적용한다는 목표를 설정했다.
하드웨어 I/O를 이용한 진단 테스트는 자동화된 테스트 생성과 테스트 실행에도 불구하고 상당한 노력이 필요하다. 특히 테스트 환경을 설정하는데 많은 시간이 소요된다. 어떤 ECU의 경우 여 러 I/O 라인의 동작 연관성이 복잡하여 I/O 라인을 개별적으로 제어하며 동작시키는 것이 매우 어려운 경우도 있다. 이에 반해 네트워크 신호를 참조하여 진단 파라미터를 검증하는 것은 초기 의 환경 설정이 쉬운 편이다. 가령, 필요한 테스트 환경을 수동으 로 만드는 대신 네트워크 데이터베이스를 이용하여 잔여 버스 시 뮬레이션(remaining bus simulation)을 자동으로 생성할 수 있고 이 환경을 테스트에서 그대로 사용할 수 있기 때문이다.
요약 및 전망 벡터에서 제공하는 CANoe.DiVa 툴을 이용하여 클라스에서 수행 하고 있는 것과 같은 테스트 자동 생성 및 실행은 테스트에 대한 노력은 줄이면서도 테스트의 깊이를 늘릴 수 있는 상당한 잠재력 을 제공한다. 현재, CANoe.DiVa 툴을 이용해 모든 테스트를 처리 하기 위해서는 클라스에서 일부 기능을 수동으로 구성해야 하는 데, 그 이유는 파라미터를 자동으로 설정하기 위해 필요한 추가 그림 2: 벡터의 VT System을 이용한 클라스의 ECU 전압 자극 및 적인 정보를 정의하는 방식이 아직 공식적으로 갖춰지지 않았기 측정 시스템 때문이다. 예를 들면, 파라미터 테스트에서 제어하기 매우 복잡 한 I/O들이 있는데 이런 I/O를 원하는 대로 설정하여 사용하기
4/24 4/25 Cover StoryⅡ
ECU 기능 개발에서의 효율적인 모델 동작 분석
ECU 기능 개발 과정은 항상 최상의 제어 알고리즘과 파라미터 조합을 찾는데 있다. 이제 새로운 측정 및 보정 솔루션을 통해 사용자들은 초기 모델 디자인에서 생산 수준의 ECU까지 전반적으로 적용 가능한 단일 툴을 사용할 수 있다.
자료제공 벡터코리아 www.vector-korea.com
모델 기반 소프트웨어 개발 구조에서는 반복적인 프로세스를 통 ASAM 표준 A2L 데이터베이스(ECU 설명 파일)는 ECU의 파라 해 애플리케이션 기능을 검사한다. 이 과정에 매스웍스의 시뮬링크 미터 및 신호를 액세스하는데 필요한 모든 정보를 제공한다. 여기 (Simulink)를 이용하여 모델을 반복 실행하게 된다. 개발자는 실행 에는 특성 값(파라미터, 특성 곡선, 맵) 및 측정 변수 같은 ECU 소 결과에 따라 라이브러리에서 드래그앤드롭(Drag-and-Drop) 방 프트웨어 내 관련 데이터 객체에 대한 설명이 포함되어 있다. 식으로 기능 블록을 추가할 수 있다. 이러한 블록은 숫자 값을 가진 또한 이 데이터베이스는 객체 이름을 ECU에서의 해당 메모리 기능 블록을 통해 직접 파라미터화되거나, MATLAB 콘솔을 이용 주소로 연결하고 원시 데이터의 물리적 해석을 위한 변환 규칙을 한 파라미터 및 해당 값의 정의를 통해 파라미터화된다. 제공한다. 이러한 데이터베이스와 측정 및 보정 툴을 함께 사용하 파라미터의 수정은 모델에서 블록을 확인, 해당 값을 변경하는 방 면 사용자가 원하는 대로 신호 데이터를 얻거나 파라미터를 조정할 호스트 이름 및 서버 포트 같은 XCP 전송 계층의 설정은 블록의 대 적으로 사용할 수 있다. 식과 MATLAB 콘솔에서 파라미터 및 해당 값을 설정하는 방식, 수 있다. ECU에는 실행 시 메모리에 액세스할 수 있게 해주는 하 화 상자에서 구성할 수 있다.‘XCP-on-Ethernet’ 프로토콜이 측 M-스크립트를 수정하여 실행하는 방식이 있으며, 동일한 단계가 나의 프로토콜 드라이버만 있으면 된다. 정 및 보정 툴과 Simulink 모델 간의 상호 작용에 사용되므로 이러 모델 최적화 위한 측정·보정 기능 반복적으로 수행된다. 모델이 Simulink에서 실행될 때 발생하는 신 벡터가 제공하는 CANape 측정 및 보정 툴의‘Simulink XCP 한 설정은 꼭 필요하다(그림 1). 계층 조직에 관계없이, 그리고 모델을 추가로 기능화하지 않고, 사 호 응답을 시각화하기 위해 사용자는 스코프 블록을 원하는 각 신호 서버’옵션을 이용하면 XCP 드라이버가 Simulink 모델에 통합된 이 파라미터화 단계가 끝나면 XCP 서버를 사용할 준비가 된 것 용자는 측정 및 보정 툴인 CANape에서 원하는 측정 파라미터를 에 연결하는데, 이는 모델을 계측장비화(Instrument) 하는 것이다. 다. 따라서 모델이 가상 ECU처럼 취급된다. XCP 드라이버를 통합 이다. 모델의 A2L 설명 파일은 블록의 대화 상자를 통해 생성된다. 시각화한다. 모델 블록의 입력 또는 출력 변수를 표시할 수 있는 것 그러나 표준화된 XCP 측정 및 보정 프로토콜을 사용하는 개발 하는 일은 매우 간단하다. Simulink CANape 라이브러리의 단일 이 대화 상자에서 각 Simulink 객체에 가상 주소가 할당된다. 이를 은 물론 변수의 시간 응답을 그래픽으로 나타낼 수도 있다. 또한 시 자는 이러한 과정 없이 Simulink 모델에서 신호를 측정하면서 사 블록을 드래그앤드롭 방식을 통해 모델로 가져오기만 하면 된다. 통해 Simulink XCP 서버가 Simulink 객체에 대해 주소 지향적인 각화된 모델에서 바로 파라미터와 신호를 편리하게 표시하고 보정 용자 친화적인 방식을 통해 훨씬 효율적으로 파라미터를 관리할 수 XCP 작업을 명시적으로 구현하게 된다. 그런 다음 사용자는 일반 할 수도 있다(그림 2). 있다. 적인 방법(이름별)으로 CANape에서 객체를 선택한다. 객체의 주 Simulink 사용자는 변환이 불필요한 친숙한 모델 표현을 통해 소는 A2L에서 읽어와 모델의 XCP 서버에 정보로 전달된다. 편안함을 느낀다. 모델에서는 수정된 파라미터가 XCP를 통해 XCP-on-Ethernet 통신 다시 말해 XCP 서버에 있는 데이터 객체의 경우 애플리케이션 XCP 서버로 직접 전달된다. XCP 서버는 Simulink 블록의 값은 ASAM 프로토콜 XCP(Universal Measurement and Calibration 의 데이터 객체에 아직 실제 ECU 메모리 주소가 지정되지 않았기 물론 기본 작업 공간이나 모델 작업 공간에서의 값을 조정하는데, Protocol)는 ECU의 애플리케이션을 측정 및 보정하는 기본 솔루션 때문에 A2L 파일의 주소만 식별에 사용된다. 모델을 이렇게 기능 이는 MATLAB 콘솔을 통해 값을 직접 설정하는 것과 같다. 으로 자리 잡았다. 애플리케이션 엔지니어는 이 접근 방식을 사용하 화한 후에는 Simulink에서 블록 대화 상자 구성을 통해 직접 기능 개발자는 전체 Simulink 모델의 파라미터 또는 하나 이상 여 ECU 실행 시 표준 버스 시스템을 통해 ECU의 측정 데이터 및 그림 1. Simulink 모델에 통합된 XCP 서버와 자동 생성된 A2L 파일을 CANape 프로젝트를 생성하고 생성된 프로젝트를 사용하여 의 서브시스템 파라미터를 쉽고 편리하게 변경할 수 있다. 이에 다 파라미터에 액세스할 수 있다. 사용하면 모델 객체를 편리하면서도 효과적으로 측정 및 보정할 수 있다. CANape를 시작할 수 있으므로 CANape에서 모델을 손쉽게 효율 양한 파라미터 세트를 활용하여 Simulink 모델을 테스트하고 최
48 AUTOMOTIVE MANUFACTURING &Technology 2010•August 49
5/0 5/1 Cover StoryⅡ
그림 2. CANape에서는 Simulink 모델의 객체에 대한 편리한 탐색과 신속한 액세스를 통해 모델의 동작에 대한 효율적인 분석을 할 수 있다.
적화할 수 있다. 여기서 CANape는 서로 다른 파일 형식을 지원한 그림 3. CANape에서 수행되는 작업의 개요 및 Simulink 모델에 미치 다. 모델이 원하는 성숙도 레벨을 얻게 되면 관련 파라미터가 파라 는 영향 미터 세트 파일에 저장된다. CANape CDM(Calibration Data Management) Studio의 파라 시뮬레이션 결과는 수동으로 또는 자동화 과정을 통해 분석될 수 미터 세트 관리 기능은 모델 최적화 도중 생성된 개별 버전을 비교 있다. 이 과정 중 한 단계에서 수신된 결과를 검사하고 파라미터화 하고, 파라미터 서브세트 또는 작업 패킷을 병합하여 전체 모델에 와 관련된 사항을 결정한다. 이 역할을 수행하는 것은 CANape 스 대한 최적의 설정을 얻는 데 사용된다. 이러한 설정은 MATLAB 크립트 언어이거나 기존 자동화 인터페이스 중 하나를 통해 /Simulink 개발 환경에서 새 버전 레벨로 바로 사용될 수 있도록 CANape가 제어하는 외부 소프트웨어 프로그램이다. ECU 캘리브레이션 MATLAB M-스크립트 형식으로 내보낼 수도 있다(그림 3). 기록된 테스트 드라이브의 데이터는 실행 시 입력 벡터로써 모델 에 입력하여 실제 데이터로 모델에 자극을 가할 수 있다. 기능 개발 시간 관리자 역할‘MATLAB/Simulink’ 자는 비교 가능한 제약 조건 하에서 시스템을 분석하고 최적화한다. Simulink 모델은 모델의 복잡도 및 컴퓨터 성능에 따라 실시간보다 이렇게 하면 비용이 많이 드는 실제 테스트 하드웨어가 필요없다. 전반적인 측정, 캘리브레이션, 진단 업무를 위한 효율적인의 솔루션 느리거나 또는 빠르게 실행될 수 있다. 이로 인해 Simulink의 타임 스탬프는 반드시 필요한 항목이다. Simulink에서 각 시뮬레이션 단 갈무리 계를 수행하면 XCP를 통해 연관된 타임 스탬프가 전송된다. 그러므 측정 및 보정 툴에서 XCP를 통해 MATLAB/Simulink 모델에 액 로 시뮬레이션 단계에 소요되는 시간의 변화는 무의미하다. 세스하면 기능 개발자의 업무가 대폭 단순화된다. 그 예로 모델이 범용 툴을 통해 간소화된 ECU 캘리브레이션을 경험하십시오. 다목적 툴 CANape는 여러 응용 분야에서 편리하게 사용하실 수 있습니다. 각 시뮬레이션 단계는 실제로 필요한 시간에 관계없이 하나의 시 XCP를 통해 자동으로 기능화 되는데, 이는 수동으로 기능화하는 간 단위에 해당한다. 이 과정에서 Simulink는 일종의 시간 관리자 지루한 과정을 사라지게 하는 것이다. 측정 및 보정 작업을 위한 범 > 다양한 연결방법(CCP, XCP-on-CAN/FlexRay/Ethernet > 다양한 진단 서비스와 플래시 솔루션이 하나의 툴로 통합, (Time Master) 역할을 수행하며, 모델에 의해 전송된 측정 데이터 용 프론트엔드(front-end) 툴인 CANape는 Simulink에서의 모델 혹은 외부 테스트 장비)을 통해 측정된 데이터를 신 손쉬운 툴 환경 구성 가능. 는 CANape에서 시뮬레이션 속도로 시각화될 수 있다. 1~2시간의 테스트 단계에 편리성까지 추가로 제공한다. 속하고 안정적으로 캡처. 동기화 및 정확한 시간 측 > 광범위한 프로토타입도 신속히 생성할 수 있는 범용 툴. 실제 테스트 드라이브에서 얻은 센서 데이터는 모델의 복잡도에 따 전체 개발 과정에서 XCP를 범용 프로토콜로 사용하면 전체 프 정 가능. MATLAB/Simulink 통합 환경 구축 가능. 라 빠르게 계산될 수 있다. 사용자가 크고 복잡한 모델을 시뮬레이 로세스의 복잡성이 줄어든다. 하나의 프로토콜, 하나의 설명 파일, > ECU 직접 연결 또는 Hex 파일을 이용한 오프라인 연결을 션하려는 경우에는 두 대의 컴퓨터를 사용하는 XCP-on-Ethernet 하나의 툴이 모든 측정, 보정 및 자극 작업에 사용되기 때문에 기능 통해 ECU 알고리즘의 파라미터를 손쉽게 관리 가능. > 전체적인 시간 추적이 용이, 대형 프로젝트의 대용량 보정 제품 정보 및 다운로드: www.vector.com/calibration 의 표준화된 통신 기능을 통해 컴퓨팅 성능을 높일 수 있다. 개발 프로세스가 단순해지고 속도가 빨라질 수밖에 없다. 데이터까지도 손쉽게 관리 가능.
50 AUTOMOTIVE MANUFACTURING &Technology 기능 개발에서부터 양산 단계에 있는 ECU까지, 또한 연구실에서나 테스트 중에, 혹은 자동차 시운전 중에도 벡터는 여러 분의 프로젝트를 지원합니다.
5/2 5/3
Vector Korea IT Inc. | Phone +82 2 807 0600 | www.vector.com TESTING FEATURE
ز җೠ ৌ۱ ۞ חߊࢤೞ ী ೲਊ ݃҅ࣻܳ ୡҗೞݶ ߊࢤೠ
ࣁझ ೠ҅۽ੑૐػ ࠙ࢳ BQFஏܻ࠳ۨ/"$ חஏ ؘఠ Ѣীࢲ নೠ۽ ࣌ ోա ܲ ؘఠ ۞ীࢲ חٜযৡ ী ۽ನݘਵ ܻܳ ೮ਵݴ ҅ױ ѐߊೠ ోਸ ਊ೧ Ӓܿ ۱೮ ۽4ুࣄ ੌ. חѾҗ ীࢲ ࢤࢿೠ Ӓ۽Ӓ ী .4ুࣄ ݒ ߊࢤ ܨ য়ߡ࠭ܳ ా೧ ࢎਊо য়ې ೮ Ѿҗܳ ۾بAnalyze Large Quantities of Measurement Data Rationally and Flexibly ਸ ঈೡ ࣻ ٬۽ ਊ೧ ೧ ஏ ੌਸ $"/BQFী ܻ࠳ۨ࣌ ূ ظࢲߡী חীࢲ ࢤࢿػ ஏ ؘఠ࠙ࢳ दػ ۞ Ӓܿ ]పझ ߮ ߂ ղҳࢿ పझ ର ۽ೞݶ ୭ઙਵ ೠ ۾بযٜ ಣоೡ ࣻ פ פѦܾ ࡺ ই ې ஏ ؘఠ ࠙ࢳ ೠ Ӕߑध दр য় ܻҊ ਬোೠ оҊ݆ بա ઁೠੋ ਃࣗױ ۄ ݒ חب .4 ুࣄ ܻ ࣘ ࢶ ର 0&.ٜ पઁ ઑѤীࢲ ରزపझ ߮ա ղҳࢿ పझীࢲ ޙ ಞষդ ؘఠনҗ ઉ ܽו ೠ ਃೠ ࠁܳ ࣻೞҊ Ӓ۞ա ࢤࢿػ ষ ীزஹನք Ѣ ؊ ঈചदఅ؊ ুࣄ ప࠶ ܳઁ ী ೧ ؘఠ ਸ ഛੋೞҊޙٸ դ ؘఠনҗ ࠂೠ ࢚ഐҙ҅ ীޙٸ ೯ ࣻী ઁড ӝ ୭ חীࢲ ߸ࣘӝ పझ द ஏ ؘز࢚ೠ दр ࣗਃػ חীੌ ח࠙ࢳೞ ઁ ೠژ ؘఠ ୭ חܻೡ ࣻ ߭ఠ $"/BQFోਸ ਊ೧ חఠܳ ࠁ ࡈܻ ࠙ࢳೞӝ ਤ೧ ۞ ظೠઁ ب ২࣌ېӒ חઁҕೞ ݴغೠ ച೮زؘఠ ݃ সਸ ب࣌ਸ ѐࢶೞӝ ਤೠ ֢۱ܖ䤋䤋䤋 ۞ೠ ࣛ
%BJNMFS"( ۞ীࢲ ೧ঠ ೮ &SIBO5FQF ӖȈীܰೠ పಕ䤋
"OESFBT1BU[FS উ٘ۨইझ ಁ䤋䤋 7FDUPS*OGPSNBUJL(NC) ؘఠ ݃ਸ ాೠ ചزಣо $"/BQFܳ &$6 ח۞ীࢲ
ؘ ࢎਊೠܳ ా೧ ೠ҅ч ਤ חীࢲ ӝয ߸ࣘ ࢚కܳ ഛੋೞ۔ ୷ যӒמపझ ߮ ߂ ղҳࢿ పझ Ӓܿ ]ؘఠ ݃ ӝ ࠳ܻۨ࣌ $6& חী ҳഅೞӝ ਤ೧ࢲ؛ݽ झ ӝా റ ߧਤೠ ରې$ ߸ࣘӝܳ ѐߊ೮ షܳ ܻೡ ࣻ Ҋز ױ ֙ ח۞ ৈࠗܳ नࣘೞѱ ఐೡ ࣻ חন ߈ ۽١ਵ ಣоਊ ۾ఠܳ ୭ച೧ ܻ࠳ۨ࣌೧ঠ ೠ द ஏ ؘఠ ӝۄী ؛ݽ מীࢲࠗఠ ".(Ҋࢿର زҳܪ ࣽױ ݒ ۽զ ӝળਵטয় ח ߸ࣘӝ ী ߭ఠޙٸ ݆ࣻ ೞѱ ࢎਊೞҊ ӝ חӝ ਤ೧ࢲ֫ ܳبೠ ઁಿ ৮ࢿژী ೡ ࣻ ೠ ࢸ҅ӝࣿ әࣘೠ ߊ ಞউೣ ೱ ܰӝө নೠ ର ࢲ۽ ۖಬਵې࠙ࢳ ߂ Ӓ ۽ ߁ যܳ ా೧ ഥࢎ߹ېӒ۽ղػ ۽࣌ਸ ҳഅೞӝܖ పझ৬ ରղ ղҳࢿ ஏਸ Ѣঠ ೠݒ $"/BQFী ӝ߈ೠ ࣛ חҊ غࢎਊ بী؛ࠁ झܽఠ ߕ ੌࠗ ݽ ࣗ࠺ܐծ ো ׳۱ز ࢚ա ೱ࢚ػ ో ২࣌ ܻ࠳ۨ࣌ ח ஏ ં߹ ಣо ঌҊ્ܻਸ ࢿೡ ࣻ מ٣झۨ ӝ ېపझীࢲ ࣻػ ஏ ؘఠ Ѿ೮ Ӓ חಞউ ੌ द೯ೞ ૌѢ ୭ചػ ো࠺ ח١ নೠ ਃҳࢎ೦ ߸ࣘӝ ӝয ױ ъ۱ೠ ূ ࡈܻ ࢎਊೡ݅ೠ ࠙ࢳ ోਸ ۾بغ ח $"/BQFী ਸ ઁҕೠ ۞ যٜ ѐߊ ߂ ܻ ؘఠ ܻী ୭ചदௌҊפূ ظࢲߡী ח ৈ۞ ਃҳࢎ೦ਸ ࢿҕ חغݽࣽ ١ ࠳ ೠ थରхۄয়ߡ٘ ѱ ઁӝ೮ܳ ٜݶ܂ਸ ࢜ ஏ ഛࠁೞҊ ۞ೠ ஶࣆܳ ҳഅೞӝ ਤ೧ ࢎਊೡ ࣻ ٸ ࠳ۨ࣌ೡ חѾदௌ֙ ߸ࣘӝ ۽ਬࢿ ӝয ߂ ష ஶߡఠ ਵ ߸҃ ۞о חޖ߭ఠܳ ࢶ೮߭ఠ স ۽ ۞ೠ ؘఠ ցੌ ח ۞ ࢎղ ജ҃ ܻ؊भ ࢚ਸ ࢚ࣻ೮ ؘఠܳ ಣо ࠙ࢳೞ ӝਬध ߸ࣘ ઁয द ୶о Үীࢲ ࠁాन ӝࣿਸ ҕ೮ౣ݂Ѳ җӝࣿ۽ &SIBO5FQF ীܰೠ పಕ ಣо ঌҊ્ܻਸ $"/BQF4DSJQUܳ חীࢲ ࢳࢎਤܳ ߉ও ਗೞ &4# ೠ റ ਬۣ҃ੌ ۽ݠېӒ۽উ ز ֙ য সীࢲۄର ࢲز ١җ э য় ١ਸ ٜ ࣻ ী ೠ҅ч ୡҗա җ ৌ۱ ֙ ߸ࣘӝزഅ عਊ ۽যפ߸ࣘӝ పझ ূزо غ֙ ۞ী Ѽ दೡ ࣻ ۽ਵېపझܳ ೞҊ ਊ೧ ࢿೞҊ Ѿҗܳ Ӓ ӝয ߸ࣘ য় ੋૐ ࠙ঠীࢲ పझ ߮ ҙܻ ߂ ର ܳ ٜযੌ ח ܳܨ חغ߸ࣘӝী ࣻ೯ز۞ೠ ѐ ח߸ࣘӝز5SPOJD 1MVT ) ݃ Ѫ $"/BQF ؘఠ חೞ ۾بীࢲ ӝҕਸ ҕ೮ਃ ҙब ࠙ ী ӝࣿܖ ܳझ "OESFBT1BU[FS ա উ٘ۨইझ ಁز ח՜ ࣻ ו ա थё חܨ ఠ ୭ചۄߊ ࢎܳ ੜ ࠁৈҊ ֙ী ࢸ ݆ࣻ ஏ ߂ ઁযҕҗ ࠁ ߂ সҕ֙ गైоܰী ࣗೠ ߭ఠ ੋನ݃౮ ࢎী חঠ ؘ ח അ ஏ ؘఠܳ ࠙ࢳೞמীࢲ Ҋёҙܻ ߂ ࢲ࠺झ ਸ ݐҊ ӝੋۄ അ ஏܻ࠳ۨ࣌ ઁಿ ೠ ݃ݽী ೧ ੑࢎ೮ਵݴبաఋդ җ ۽ਸ ҟ ؏Ѣܿਵ ESJWJOH CFIBWJPS ز೯ Ѣ חN ਗೞ/ ୭ חػ (5SPOJD 1MVT҅
5/4 112 www.autoelectronics.co.kr SEP . OCT 2014 113 5/5 TESTING FEATURE
пп ೠ ߣ ӝয ߸ࣘ ؘחغद ࢚ ਤܳب חਸ աఋմ ࢎਊ ೠ҅ ߧਤ ߆ী ֬ੋ ٜਸ ഛ ۽ӝળਵ ҙ۲ ೡ ࣻ ਸ ೞա ࢶఖೞݶੋ ীࢲب חҊ ࢎਊغ٬۽ ஏ ੌ दр୷ ਤী ೧ чਸ दпചदఆ ࣻ ೧ ӝয ߸ࣘ ߊࢤೠ दрਸ ഛੋೡ ࣻ ز ହ ղ బஎо दр חBQFীࢲ/"$ ূ ী ܲ ݽٚ ହীࢲ షաޙٸ ӝغӝച ࢶ ؘח١ ౠ బஎܳ աఋղ ب ࣘ ఖೠ ؘఠ җ ஏೠ दр ഛೞѱ ೠੌ ۱݃ ۄפनഐ ࡺ ই חചदఅ $"/BQF ؘఠ ݃ ࢎਊ ੋఠಕझ ହীࢲݏ যٜ ઁदೠ ਃҳࢎ೦ীפӒܿ ]۞ ূ ب١җ э ೠ҅ч ୶ࣁࢶ য়ର ୭ दೡ ࣻ ೠ҅ ߧਤ ৻Ҙী ֬ੋ ٜ ೠ҅ч ਤ߈җ ߸ࣘস য়ܨܳ աఋմ ܳ ా೧ ݶೠ Ѩࢎо ਃೠ ӝয ী ഛੋೡ ࣻ ׀߸ࣘਸ ೠ
ஏ ؘఠ ಣо ਬোೠ যٜ $"/BQF ؘפ۞ ূ ੌ ਸ ਊ೧ ஏ ؘఠמఠ ݃ ӝ ೧ ߈ੋ ࠙ࢳਸ ࣻ೯ೞҊ ೠ҅ ী ೞ ঋ ࢎۈ߄ חژ חчਸ ਤ߈೮ ܳ ഛੋೡ ࣻ חѤ ߊࢤ೮ ѐߊٜ ӝઓ ؘఠܳ ࠁ ബ ח ࢎਊೞҊ ౠ &$6 ࣗਝয ۽ਯਵ
ܳ ࠁח೮׳ب ࣻળী بо ਃҳػ ࢿࣼ ࠁܳ ਊ೧ ղҳࢿ పझী חغ٣झۨ ହী द ࣌ ӝয ߸ࣘ ಣоࢎ ೠۑӒܿ ] ೠಣоܳೡࣻ ೞӝ ਤೠ ਃױ नࣘೞҊ ഛೞѱ ౸ ೠ җ ߸ ۽ೠ ਃҳࢎ೦ ࣘਵ ࠙ࢳী ژ ӝয ױ ࢚ ࢚ਸ ࢶೠ Ҋ $"/BQFܳ ਊ೧ ؘఠܳ ࢳೡغࢎਊ ୭ઙ Ҋёա ߭ఠী חࣁझܳ द ചೠ झ݀۽࠙ࢳ ജ ۽ӝয ױೞ ח о ߊܨஏ ੌীࢲ য় חࢎਊ ٸ ࠙ࢳೡ ߁ېӒ۽࠙ࢳ ࢲ ࣻೡ ࣻ $"/BQF חೠ റীܐ ಣоܳ ৮ Ӓܿ ೠ Ӓܿ ࢤೠ ਤܳ ഛೞѱ दೡ ࣻ $ যա ࢤࢿೠా҅ যо ࠙ೞ ঋਸ ҃ ܳܐ҅ా ח٣झۨ ղਊਸ ਃডೞ ޛѾҗ חژ ۽࠙ࢳਊਵ חBQF/"$ ࠳۞ܻܳ ࢤۄ ਸ ਊ೧؛߸ࣘਸ ড 4JNVMJOL ݽ ۽ਵױ ীࢲױ חীࢲܐࢎਊೡ ࣻ ؘఠ ӝ ۽ਊ ۖಬਵ ۽--% ܳ $"/BQFীࢲ ١ ࠁܳ ഛੋೡ ࢿೡ ࣻ ਵݴ Ѫ חഥ पद೮ #) ୭ חઁ ӓࠂ೮ਵݴ ب ೠ҅ ಣо חী ৌ ࢎਊೡ ࣻ ܳ ਊ೧ ਗೞب:9 ܳ ٜݶ Ӓܿ হ ܻೡ ࣻ ࣻ ઁޙ ؘఠܳ
ೞAEמѪ о חఠ ਤী द ܳ ࣻ೯ೞۄ ܻޛ ࢎਊо ஏ ؘఠܳ ੑ۱чਸ ܲ חҳࢿ ஏݶীࢲ ۽࢚ী ਵب חೠ ಣо ܻझীࢲ ࠙ ೡ ࣻ Ӓ Ѿҗמࢎਊ о ࢶఖೞҊ
5/6 114 www.autoelectronics.co.kr D ESIGN IDEA
기술기사
공유할 수 있다.
ECU 캘리브레이션을 위한 툴 체인 이 모든 동향은 미래의 측정, 캘리브레이 션 및 진단 작업을 위한 툴 체인에 지속적으 로 영향을 미치게 된다. ECU 캘리브레이션 을 위한 고성능 제품을 공급하는 툴 생산업 체인 벡터(Vector)는 현재와 미래의 고객에 ECU 캘리브레이션 게 최고 솔루션을 제공하기 위해 이러한 동 향들에 초점을 맞추고 있다.
벡터는 ❶보조 시스템, ❷파워트레인의 개발 방법과 툴의 동향 및 영향 [그림[그림 1] 1: ECU ECU 캘리브레이션은캘리브레이션은 차량 에서차량에서 테스트 테스트벤치 및 HIL벤치 시스템으로 및 HIL 이동되고시스템으로 있다 . 이동되고값 비싼 원형 있다. 모델 값비및 테스트 차량 싼 비용을원형 절감시키기모델 및 테스트 위해 더 많은차량 캘리브레이션의 비용을 작업절감시키기 및 최적화가 위해 실험실 더 내의많은 시뮬레이션과 캘리브레이션 모델을 작업 통하여 및 시행될 최적 것이다.] 부가가치, ❸기업의 툴 부서 또는 외부 서비 화가 실험실 내 시뮬레이션과 모델을 통하여 시행될 것이다. 스 제공업체가 벡터 제품을 자신의 솔루션 클라우드 기술의 신뢰성 있고 부가가치적인 통합 에 손쉽게 통합시킬 수 있게 해주는 유연한 ECU의 측정 및 캘리브레이션 분야에서 향후 5~10년 동안의 개발 및 도전 과제 한 데이터의 결합은 높은 데이터 속도 외 기존의 신호 지향적인 개념을 객 인터페이스, 그리고 ❹측정 및 캘리브레이 체소셜 지향적으로 미디어, 사물 표현하고 인터넷 및 정보 웹 3.0 처리은 앱을의 방향을사용하여 확장시킬 데이터의 교환것을, 연결성 요구한다. 및 확장성 이 어떻게 션 솔루션에 통합되고 신뢰성 있는 인터넷 에는 몇 가지 변화가 예상된다. 기존의 작업 방법에 그 한계가 드러나 새로운 접 근 방법이 필요하기 때문이다. 이와 관련하여 데이터에 기반한 캘리브레이션 방 간단하고 포괄적으로 실현되는지 보여준다. 과제는 이러한 접근 방식의 잠재성을 측정 및 기술의 제공과 같은 ECU 캘리브레이션 분 캘리브레이션가상 캘리브레이션으로부터 분야에서 활용할 수 있도록 자동 통합 되생성된고 신뢰성 파라미터 있는 기업 솔루션으로 세트까지 제공 하는 것이다. 야에 대한 네ECU 가지의 전략적 측정 주제를및 캘리브레이션 확인했다. 분야에서 향후 5 ~ 10 년 동안의 개발 및 도전 과제는 세계적인 법, 데이터 교환을 통한 지능형 데이터 관리, 앱을 통한 전문 지식의 통합은 애플 이 밖에도 가상 환경과 기존 데이터 세트에서 생성된 지식 및 웹 기술을 리케이션 엔지니어의 작업을 도와줄 수 있을 것으로 판단된다. 추세를 따를 것이고, 여기에는 몇 가지 변화가 예상된다. 기존의 작업 방법은 종종 그 한계가 산업측정 작업데이터 시퀀스로 분석용 어플리케이션 마이그레이션하는은 이러한 기술을것 등도 사용하여 측정 뛰어난및 캘리브레이션 잠재적 가치를 분 제공한다. 현재의 솔루션은 추가적인 자료제공 | 벡터코리아(www.vector.com) 야의 최신 동향이다. 캘리브레이션 작업이 차량에서 테스트 벤치 및 HIL 이전의 솔루션이 비싸고 특별한 소프트웨어와 많은 시간을 필요로 하는 환경설정을 필요로 하는 개발에 적합하다드러났기 때문에 업계의 새로운 접근 방법이 필요하다. 데이터에 기반한 캘리브레이션 방법, 시스템으로 이동되는 한편, 미래에는 실험실 내에서 시뮬레이션과 모델을 파워트레인에서 캘리브레이션 작업은 다 반면, 클라우드 솔루션은 측정 데이터뿐 아니라 데이터 수집을 위한 중앙 알고리즘 또한 손쉽게 통하여 더 많은 캘리브레이션 작업 및 최적화가 시행될 것이기 때문이다 각적이고, 그가상으로 범위는 측정투명한 데이터 데이터 수집부터 교환을 통한 “지능형” 데이터 관리, 앱을 통한 전문 지식의 통합은 공유할 수 있다. (그림 1). 이는 값비싼 원형 모델 및 테스트 차량이 필요한 기업들에게 도 오프라인 캘리브레이션까지 포함한다. 후자 어플리케이션 엔지니어의 작업을 도와줄 것이다. 움이 될 수 있다. 이러한 접근 방법은 더 이상 단순히 신호를 측정 및 수집 는 측정 파일 및 파라미터 값을 사용하여 작 ECU 캘리브레이션을 위한 미래가 보증된 툴 체인 자동차 산업에 종사하는 수많은 관리자 레인의 복잡성을 한층 더 가중시키게 되는데, 현대식 배기 가스 정화 시 하여 관리하는 것과는 다르고, 오히려 결과의 자동 생성에 초점을 맞춰야 업하는 데 초점을 맞춘다. 애플리케이션 엔 의 관점에서 볼 때, 향후 수 년간 이 분야에 스템을 갖춘 디젤 구동장치에서는 4, 8, 10 또는 20가지의 파생 사양을 한다. 기존의 데이터베이스는 해당 계산 알고리즘을 사용하는 새로운 파 지니어는 파생 사양을 제작 및 관리하거나 영향을 미치게 될 핵심적인 동향은 새로운 시 포함하여 6만개 이상의 파라미터를 캘리브레이션해야 한다는 게 대표적 라미터이 모든 세트 동향 및은 미래의파생 사양의측정, 캘리브레이션 생성에 대한 및 진단기초로써 작업을 사용될위한 툴 수체인에 있다. 지속적으로 영향을 최적화하고,자동차 또한 데이터산업에 세트를 종사하는 생성하기 수많은 관리자의 관점에서 볼 때, 향후 수 년간 이 분야에 영향을 미치게 될 장 관리, 차량 플랫폼 및 모듈의 표준화, 운 인 예이다. 미치게 될 것이다. ECU 캘리브레이션을 위한 고성능 제품을 공급하는 툴 생산업체인 Vector 는 위해 모델 기반 기술이나 가상 기술을 사용 핵심적인 동향은 새로운 시장 관리, 차량 플랫폼 및 모듈의 표준화, 운전자 지원 시스템, 그리고 전자 지원 시스템, 그리고 추가적인 내연 기 섀시 또는 차체 및 보조 시스템도 기타 전자 부품의 영역과 마찬가지로 한다. 다양한 오프라인 업무 영역을 위한 고 클라우드 기술의 신뢰성ECU 캘리브레이션 있고 부가가치적인 – 개발 방법과 툴의 동향 통합 및 영향 3/7 관의 최적화 등이다. 이런 것들은 당연히 작 ECU의 복잡성 및 환경설정의 필요성이 지속적으로 증가하고 있다. 섀시 소셜 미디어, 사물 인터넷 및 웹 3.0은 앱을 사용하여 데이터의 교환, 연 성능 솔루션은추가적인 현재 이미 내연 사용 기관의 가능하며, 최적화 추 이다[1]. 이는 기업과 개발 부서의 새로운 요구를 창출하고, 여기에는 업 방법의 근본적인 변화를 필요하게 만든다. 시스템에 대하여 단 5000개의 파라미터 만을 관리한다 할지라도 엔지니 결성 및 확장성이 어떻게 간단하면서도 포괄적으로 실현되는지 보여준다. 가적인 개발을 위한 이상적인 시작 기반을 다양한 작업 방법의 근본적인 변화가 필요하다. 예를 들어 새로운 시장은 소비자, 비즈니 어는 이를 80~100개의 파생 사양 차량에 적용시켜야 한다. 초음파 센서 과제는 이러한 접근 방식의 잠재성을 측정 및 캘리브레이션 분야에서 활용 형성한다. 스 파트너 및 서비스 제공자와 함께 국제적 의 경우, 일반적인 보조 시스템 부품에는 몇 가지의 캘리브레이션 값만이 할 수 있도록 통합되고 신뢰성 있는 기업 솔루션으로 제공하는 것에 있다. 팔레트에는 다음과 같이 다양한 툴이 포 인 수준의 보다 긴밀한 협업을 필요로 하는 존재하지만, 이 센서를 1000가지나 되는 각기 다른 형태의 차량에 설치 측정 데이터 분석용 애플리케이션은 이러한 기술을 사용하여 뛰어난 함된다. vSignalyzer는 측정 데이터 분석 한편, 더 많은 표준화는 그 보다 훨씬 더 많 해야 한다는 건 또다른 문제이다. 잠재적 가치를 제공한다. 이전의 솔루션은 비싸고 특별한 소프트웨어와 툴이다. CDM예를 Studio는 들어 새로운 독립적인 시장은 캘리브레 소비자, 비즈니스 파트너 및 서비스 제공자와 함께 국제적인 수준의 보다 은 파생 사양(variants)을 유도할 수 있다. 운전자 지원 시스템의 경우, 기존의 측정 및 캘리브레이션 툴에 직접 통 많은 시간을 필요로 하는 환경설정을 필요로 하는 반면, 클라우드 솔루션 이션의 데이터 취급 툴이다. vCDM은 캘리 긴밀한 협업을 필요로 하는 한편, 더 많은 표준화는 그 보다 훨씬 더 많은 파생 사양(variants)을 실제로 내연 기관을 더 개발할수록 파워트 합시키는 것만으로도 효과적으로 개발·테스트 및 검증할 수 있지만 이러 은 측정 데이터뿐 아니라 데이터 수집을 위한 중앙 알고리즘 또한 손쉽게 브레이션 데이터 관리를 위한 기업 솔루션 유도할 수 있다. 실제로 내연 기관을 더 개발할수록 이미 높은 수준인 파워트레인의 복잡성을 한층
56 AUTOMOTIVE Report JULY 2017 57 5/8 5/9
56-61p AR 201707월호.indd 56 17. 6. 26. 오후 3:50 56-61p AR 201707월호.indd 57 17. 6.ECU 26. 캘리브레이션 오후 3:50 – 개발 방법과 툴의 동향 및 영향 1/7 D ESIGN IDEA
기술기사 XCP 및 CANape를 사용한
모델 기반 개발 및 ECU 보정 답 시간을 요구하게 된다. 따라서 이제 섀시 및 보조 시스템은 최대 100Mbps의 전송 속도를 필요로 한다. VX1000 측정 및 캘리브레이 기술기사 션 하드웨어를 사용하면 빠르고 직접적이며, 비용 효율적인 인터페이 Case Study HOERBIGER 스를 사용할 수 있는데, 이는 표준 ASAM XCP on Ethernet을 사용 데이터를 편집, 관리 및 분석할 수 있게 된다. 캘리브레이터 워크 벤치의 필수적인하는 ECU를 구성 성분에는 통하여 앱 통신한다. 또한, 이는 POD(Plug-on-Device) 또는 vApps(virtual apps – 가상 앱)를 사용하는 확장성이 포함될 것이다를. 이 사용하여 경우, 엔지니어들은 공간을 절약할 수 있는 하우징에 통합시킬 수 있다. 자신의 앱을 사용하여 기존의 기능(측정 파일의 읽기 & 쓰기, 파라미터 세트팀 파일 내, 맵데이터 에디터 의등 )을교환을 위해, 신뢰성 있는 가상의 클라우드를 통해 버 다시 사용할 수 있게 될 것이고, 또한 이로써 개발 비용을 절감할 수 튼을있게 될누르는 것이다 시점에. 이처럼 작업 솔루션, 측정 값, 파라미터 세트, 보고서 등을 고객정보 장점 HOERBIGER의 사업부인 HDM (HOERBIGER Drivetrain Mecha Simulink 모델을 편리하고 효율적으로 시각화, 파라미터화 필요하면 추가적인 전문 지식을 구매할 수 있고, 이를 손쉽게 캘리브레이터공유할 워크 벤치에수 있는 통합시킬 솔루션을 준비하고 있다. 툴 제조업체에 의한 클라우드 tronics)은 전세계 자동차 시장에서 상당한 영향력을 가진 클러치 CANape의 옵션인 Simulink XCP Server는 모델 동작 분석에 매우
수[그림 있다2: 모델 .기반 서버 소프트웨어 또는 개발의 클라우드 일부로써, 반복 인프라에공정을 사용하여 어플리케이션설치된 의앱은 기능을 테스트할Vector 수 있다또는. 편리한 외부 뿐서비스 아니라 제공자에 기업의 의하여 네트워크도 이를 사용할 수 있다. 사무실이나 테스트 적합하다. [그림측정, 파라미터 2] 할당모델 및 CANape 기반와 같은소프트웨어 모델에 대한 시각화 개발의 인터페이스는 일부로써, 개발 공정을 현저하게 반복 가속시킬 수 있다.] 전문업체이다. 이 업체에서는 주로 스포츠카, 고급 세단 및 대형
공정을제공된다 사용하여. 지식 관리를 애플리케이션의 위한 중앙 노드로써 기능을 캘리브레이터테스트할 수 워크 벤치는 궁극트랙에서도적인 작업 결과에 손쉽게 대하여 데이터를 읽거나, 교체하거나, 답장을 쓰거나, 동기 트럭용 듀얼 클러치 메카트로닉 시스템을 개발한다. > 표준 XCP 프로토콜의 사용은 동일한 CANape 설정을 전체 개 있다.팀 내 데이터 편리한 교환을 측정, 위해, 신뢰성 파라미터 있는 가상의 할당 클라우드를 및 CANape와 통해 버튼을 누르는 같은 시점에 작업 솔루션, 발 공정에 걸쳐 사용할 수 있게 한다. 모델에 관계없이 래피드 간단한 클라우드 기반 공유 기능을 제공하게 될 것이다. 화시킬 수 있다. 모델에측정 값, 파라미터 대한 세트시각화, 보고서 인터페이스는 등을 공유할 수 있는 개발 솔루션을 공정을 준비하고 현저하 있다. 툴 제조업체에 의한 게 가속시킬 수 있다. 기술적 과제 프로토타이핑 플랫폼 또는 ECU가 연결된다. 클라우드 뿐 아니라 기업의 네트워크도 이를 사용할 수 있다. 사무실이나 테스트 트랙에서도 손쉽게 Simulink 모델 동작의 테스트 편의성 향상 > 최대한 실제 상황에 가깝게 모델을 테스트하기 위해 런타임 데이터를 읽거나, 교체하거나, 답장을 쓰거나, 동기화시킬 수 있다. 비전 2020: 캘리브레이터 워크 벤치 2세대 듀얼 클러치 변속기를 위한 소프트웨어 개발을 위해 엔지 동안에 기록된 측정 데이터를 모델의 입력 파라미터로 공급할
투자 보호와 함께 확장성 또한 수년 동안 고객을 위한 우선순위에 둘 니어들은 기존에 수동으로 작성한 C 코드를 MATLAB 수 있다. 비전 2020: 캘리브레이터 워크 벤치 /Simulink 모델로 변환하려 한다. 그러면 이 코드는 모델에서 자 > CANape의 다양한 창에서 측정 데이터의 시각화 및 파라미터 수 있다. 그래서 하나의 작업 스테이션으로부터 팀, 그리고 최종적으로 동으로 생성되고 AUTOSAR RTE에도 바로 통합될 수 있다. 또한 의 수정이 용이해 객체별 모델 계측이 필요하지 않다. 투자 보호와 함께 확장성 또한 수년 동안 고객을 위한 우선순위에 둘 것이다. 하나의 작업 기업 수준의 솔루션까지 이용 가능한 툴과 이러한 툴의 적용이 필요하다. 각각의 소프트웨어 모듈은 Simulink에서 시뮬레이션도 가능하 > CDM Studio에서 보정 데이터 관리 기능을 사용하면 모델의 스테이션으로부터 팀, 그리고 최종적으로 기업 수준의 솔루션까지 이용 가능한 툴과 이러한 툴의 벡터의 전문 기술자는 차세대 작업 환경 비전을 ‘캘리브레이터 워크 벤 적용이 필요하다. Vector 의 전문 기술자는 차세대 작업 환경 비전을 “캘리브레이터 워크 벤치”라고 다. 하지만 기존 MATLAB Scope의 시각화 옵션으로는 세부적인 파라미터 세트 파일을 쉽게 편집하고 관리할 수 있다. 다양한 파 치’라고 명명했다(그림 3). 명명하였다(그림 3). 여기서 의미하는 바는 균일한 사용자 인터페이스와 동일한 외관 및 느낌의 툴을 데이터 분석을 수행하기가 어렵다. 파라미터를 최적화하는 과정 라미터 세트를 복사 및 병합하는 것은 물론, Simulink 모델로 다
통합하여 제공한다는 사실이다. 툴은 유사한 방법을 제공하고, 다양한 툴을 사용하는 캘리브레이션 여기서 의미하는 바는 균일한 사용자 인터페이스와 동일한 외관 및 느 에서도 MATLAB Workspace에서 값을 수정하거나 혹은 특정 운로드 및 파라미터를 다양한 포맷(예: MATLAB의 M-Script)으로
ECU 캘리브레이션 – 개발 방법과 툴의 동향 및 영향 5/7 낌의 툴을 통합하여 제공한다는 사실이다. 툴은 유사한 방법을 제공하 GUI 요소를 생성해야 하므로 시간이 많이 소요될 뿐 아니라 불편 저장할 수 있다. 하기까지 하다. 고, 다양한 툴을 사용하는 캘리브레이션 데이터를 편집·관리 및 분석할
수 있게 된다. 캘리브레이터 워크 벤치의 필수적인 구성 성분에는 앱 또 솔루션 는 vApps(virtual apps. 가상 앱)를 사용하는 확장성이 포함된다. Simulink 모델과 ECU 내부의 데이터를 파라미터화하고 시각화 이 경우, 엔지니어들은 자신의 앱을 사용하여 기존의 기능(측정 파일의 하기 위한 사용자 인터페이스로 CANape 선택 읽기 & 쓰기, 파라미터 세트 파일, 맵 에디터 등)을 다시 사용할 수 있게 CANape를 Simulink의 모델과 접속하는 가장 간단한 방법은 Simulink XCP Server를 사용하는 것이다. 사용자는 여기서 ECU 되고, 이로써 개발 비용을 절감할 수 있다. 이처럼 필요하면 추가적인 전 에 연결할 때와 동일한 옵션을 사용할 수 있다. 즉, Drag & Drop [그림[그림 3: 3]동일한 동일한 사용자 사용자 인터페이스를 인터페이스를 장착한 “캘리브레이터 장착한 워크‘캘리브 벤치”는 툴의 모듈 방식의 시스템을 통하여 엔지니어들을 지원하게 될 것이다. 유사한 방법을 제공하고, ECU 내부 데이터의 편집, 분석 및 관리가 가능하게문 지식을 될 것이다 . 구매할사용자는 표준 수 있고, 이를 손쉽게 캘리브레이터 워크 벤치에 통합 방식으로 설명 파일에서 측정 및 보정 파라미터를 선택하고 디스 레이터 워크 벤치’는 모듈 방식의 시스템을 통하여 엔 기능을 다시 사용함으로 쉽게 개발할 수 있고 확장성을 통합시킬 수 있다.] 지니어들을 지원하게 된다. 예를 들면 유사한 방법을 시킬 수 있다. 서버 또는 클라우드 인프라에 설치된 앱은 벡터 또는 외부 플레이 및 보정 창에서 시각화할 수 있다. 또한 버튼을 누르면 필
제공하고, ECU 내부 데이터의 편집·분석 및 관리가 요한 A2L 설명 파일이 Simulink 모델에서 생성되므로 모델을 추 서비스 제공자에 의하여 제공된다. 지식 관리를 위한 중앙 노드로써 캘리 가능하게 되는 것 등이다. 사용자는 표준 기능을 다시 기술기사 가로 계측할 필요없이 모델의 파라미터를 읽고 쓸 수 있다. 사용함으로 쉽게 개발할 수 있고 확장성을 통합시킬 브레이터 워크 벤치는 궁극적인 작업 결과에 대하여 간단한 클라우드 기 수 있다. 그림 제공: Vector Informatik GmbH 독일 출판물 “ Hanser Automotive”, 2015 년 11-12 월호 기사 번역판 반 공유 기능을 제공하게 된다.
링크: 벡터 홈페이지: www.vector.com
이다. Simulink와 함께ECU 캘리브레이션통합되는 – 개발CANape 방법과 툴의 동향 및 영향 6/7 저자: 는 모델 기반의 캘리브레이션을 위한 강력 한 플랫폼이다(그림 2). 측정된 데이터의 수집 및 온라인 캘리 ▶ 저자 Michael Vogel은 벡터의 vCDM 비즈니스 개발 관리자이다. 브레이션은 대역폭의 요구사항과 빠른 응 E-mail: [email protected]
Michael Vogel Vector Informatik GmbH 의 vCDM 비즈니스 개발 관리자이다. E-mail: [email protected]
58 AUTOMOTIVE Report 본 보도자료 배포 시 최종 인쇄물을 당사에 보내주시면 감사하겠습니다. 배포와 관련하여 문의사항이 있으시면 언제든지 연락해주시기 바랍니다.
5/10 5/11 벡터 코리아 편집자 연락처: 마케팅팀 김용성 서울특별시 용산구 한남대로 11 길 12 고뫄스 빌딩 5 층 56-61p AR 201707월호.indd 58 Tel. 02-807-0600 Ext.5009, Fax. 02-807-0601 17. 6. 26. 오후 3:50 E-mail: [email protected]
ECU 캘리브레이션 – 개발 방법과 툴의 동향 및 영향 7/7 기록하고 해당 프로젝트의 진행 상황을 모니터링을 할 수 있다. 라서 추가 작업 없이도 동일한 시스템 속성을 가진 모든 배리언 CDM 시스템은 단계별 접근방식으로 데이터 통합을 관리한다. 트에 대해 일관된 파라미터화가 적용된다. 캘리브레이션 엔니지어의 모든 작업 결과가 CDM 시스템에 전달 되면 정해진 파라미터 규칙에 따라 오류 혹은 중복 파라미터화로 큰 그림을 보고 작은 것부터 실천하라 인한 문제를 해결할 수 있다. 사용자는 CDM 솔루션을 단번에 채택하여 사용하는 경우는 거의 없지만, 특정 작업 수행 시 발생하는 특정 문제에 해결을 위해 솔 이후에, 권한 오용 방지 원칙(four-eye principle)에 따라 해당 결 루션이 필요한 경우는 자주 있다. 예를 들면, 캘리브레이션 엔지 과를 검증하고 완성도를 점검한다. 이러한 검증 및 점검 절차가 니어는 모든 캘리브레이션 데이터의 갱신으로 귀결되는 분배 작 완료되어야만 해당 데이터가 통합되어 다음 데이터 수정 단계로 업에서 도움이 필요할 수 있다. 혹은, 프로젝트 팀장은 팀원들이 전달될 수 있다. 또한, 이를 통해 개발 파트너들과의 협력이 활성 시스템에 캘리브레이션 데이터 입력 시 발생할 수 있는 문제점을 화되고 다양한 기능 분야의 정확한 데이터에 접근할 수 있다. 해결하거나 예방할 수 있어야 한다. 이러한 개별적인 솔루션의 급증으로 인해 전사 차원의 통합된 데이터 관리 솔루션이 더욱 지능적인 캘리브레이션 배리언트 관리를 통한 효율성 향상 중요해지고 있다. 중앙 CDM 솔루션은 전사적인 프로세스를 나 체계적인 프로세스를 통한 캘리브레이션 작업 지원과 더불어 데 타낼 뿐만 아니라 소프트웨어 개발 및 검증과 같은 기타 프로세 이터 관리의 또 다른 핵심 기능은 방대한 양의 캘리브레이션 배 스도 지원한다(그림 2). 리언트를 생산적으로 관리하는 것이다. “캘리브레이션 배리언 트”란 엔진 배기량, 변속기 유형, 배출 기준 등과 같은 차량 속성 따라서 데이터 관리 솔루션을 통해 캘리브레이션 엔지니어는 물 집합을 의미한다. 다양한 제품 구성으로 인해 ECU 소프트웨어의 론 부서 및 전사 차원의 특정 요구사항을 모두 충족할 수 있다. 파라미터 데이터의 변경이 요구되는데 이로 인한 변경 사항을 “ 이러한 확장 가능 솔루션은 투자를 보호하면서 단계적으로 도입 파생 캘리브레이션”이라 부른다. 및 개발할 수 있다.
배리언트 관리는 예를 들면 모든 배리언트의 일관된 파라미터화 캘리브레이션 엔지니어를 위한 데이터 관리 가 자동으로 이루어질 수 있도록 보장하는 등의 메커니즘을 제공 ECU 캘리브레이션 프로세스에서 캘리브레이션 엔지니어는 테스 하기 때문에 불필요한 중복 작업을 방지한다. 시스템 속성에 종 트 벤치나 차량 내에서 소프트웨어 툴(MCD 툴)을 사용하여 시스 캘리브레이션 데이터 관리 – 더 이상의 퍼즐 게임은 그만 속된 파라미터의 경우, 종속성을 규정하는 규칙이 적용된다. 따 템 컴포넌트의 초기 가동 상태를 평가한다. 그런 다음, 엔지니어 개인 및 팀, 전사 차원의 복잡한 캘리브레이션 데이터 관리
ECU 개발 시 짧은 혁신 주기 및 고비용의 압력으로 인해 소프트웨어 개발 프로세스와 이 개발된 소프트웨어를 실질적으로 차량에 적용하는 프로세스가 개별적으로 진행되고 있다. 요즘 대부분의 차량에서는 방대한 양의 캘리브레이션 데이터 값을 차량 배리언트 Project Manager Calibration Engineers (variant)별로 결정 및 관리해야 한다. 오류 방지를 위해 실제 소프트웨어 개발 프로세스에 적용되는 동일한 품질 기준이 요구된다. 본 기술 기사를 통해 파라미터 값 관리를 위한 툴의 요구사항에 대해 설명하고 관련 솔루션을 제시하고자 한다. Generate data sets Initiate calibration Fetch ECU Authorize calibration engineers project program file Pre-calibration ECU 소프트웨어 기능 개발 시 높은 수준의 품질 기준(SPICE, 다. 요약하면, 오늘날의 자동차 업체는 엄청난 양의 파라미터 집 Hex CMMI)이 반드시 준수되어야 한다. ECU의 정확한 파라미터화는 합 파일을 생성하고 관리해야 한다. ECU 소프트웨어의 정확한 기능만큼 중요하다. 따라서 동일한 품 A2l 질 기준이 파라미터 조정 과정에 적용되어야 한다. 이러한 조정 체계적인 프로세스를 통한 품질 개선 Calibrate online e.g. 과정을 “캘리브레이션”이라고 하며, 이는 정확한 캘리브레이션 전용 데이터 관리 솔루션을 통해 복잡한 캘리브레이션 데이터 관리 with CANape, INCA, ... 값 모니터링 및 모든 가능한 배리언트에 대한 일관적인 파라미터 프로세스의 효율성을 향상할 수 있다. 전용 데이터 관리 솔루션을 사 화를 위한 프로세스 준수 및 품질 보증에 필수적인 요소이다. 용하면 수많은 차량 캘리브레이션 값에 대해 사전 정의된 차량 캘리 Release ECU Calibration program for series successful? 브레이션 배리언트에 방대한 양의 파라미터를 정확히 적용할 수 있다. vCDM 혁신 주기가 단축되고 품질 및 효율성에 대한 요구사항이 더욱 동시에, 품질 보증 차원에서 각각의 변경 사항을 정확하게 추적할 수 엄격해지면서 높은 수준의 재사용성을 확보하는 것이 매우 중요 있다(그림 1). Deliver calibrated parameters 해지고 있다. 전자 기기 개발 단계에서 다양한 모델과 차량 캘리 브레이션 배리언트를 대상으로 동일한 소프트웨어를 재사용할 위와 같이 명확히 정의된 접근 방식을 통해 프로세스 신뢰성을 확보 수 있어야 한다. ECU 상의 개별 배리언트들은 독립적인 파라미 하고 데이터 품질을 개선할 수 있다. 캘리브레이션 데이터 관리(CDM) 터 집합을 구성하므로 파라미터 집합 수가 상당히 증가한다. 시스템으로 작업 결과를 관리한 엔지니어의 원본 파일은 버전 관리의 Data review and 대상이 된다. 즉, 사용자는 어떤 파라미터 집합이 특정 배리언트에 유 Check-in data det merge calibrated Generate reports 현재 Euro-6 배출 기준에 부합하는 디젤 엔진의 ECU에는 대략 입되었는지와 더불어 이 해당 집합들이 어디서 재사용되는지를 한눈 parameters 60,000개의 파라미터가 캘리브레이션 된다. 섀시 및 차체 내의 에 파악할 수 있다. 이를 통해, 모든 관련 배리언트에 적용되는 새로운 ECU에는 상대적으로 적은 수의 파라미터가 포함되어 있지만 배 파라미터 버전이 자동으로 업데이트된다. 프로젝트 시 품질 및 완 그림 1: CDM 시스템상의 명확히 정의된 프로세스를 통해 ECU 캘리브레이션의 품질 개선 리언트의 수는 오히려 많아 전용 데이터 관리 솔루션이 필요하 성도 모델을 활용하여 데이터 통합에 필요한 각종 변경 사항을
5/12 5/13 는 목표 가동 상태에 도달하기 위해 파라미터를 조정한다. 단, 이 시스템을 통해 팀원 간 정보를 자동으로 공유할 수 있다. 이메일 다. 산업 및 기업별로 상이한 요구사항 때문에 이에 따른 다양한 라미터에 역할을 할당한다. 또한, 파라미터의 충돌을 감지하고 러한 “온라인 캘리브레이션” 방식은 필수 작업의 일부일 뿐이다. 시스템의 통합으로 데이터 변경 사항, 신규 버전 출시, 소프트웨 접근 방법이 필요하다. 데이터 관리 솔루션 적용 시, “표준 프로 해결할 뿐 아니라 데이터 변경 사항을 완벽하게 추적한다. 대부분의 경우 ECU와 직접적인 연결 없이 다양한 차량 배리언트 어 변경 사항 등의 정보가 업무 담당자들에게 통보된다. 이를 통 세스”를 규정하기보다는 기술 부서의 다양한 작업 양상이 최대 종속성 관리, 파라미터값 자동 계산, 워크 패키지 재사용 등을 통 를 대상으로 파라미터를 비교하고 수정하는 과정이 필요하다(오 해, 팀원들이 동일한 데이터를 기준으로 신속히 업무를 처리할 한 반영 되어야 한다. 해 방대한 양의 배리언트를 안정적으로 처리할 수 있다. 이를 통 프라인 캘리브레이션). 예를 들면, 소프트웨어 개발 요구사항을 수 있다. 해, 높은 데이터 품질과 함께 캘리브레이션 배리언트의 일관성을 기준으로 파라미터가 “사전 캘리브레이션” 되는 경우, 사전의 유 다양한 용도로 확장 가능한 솔루션 확보할 수 있기 때문에 데이터 마이닝 및 리포트 기능에 적용하 사한 프로젝트 결과를 채택하는 경우, 온라인 캘리브레이션 값들 자동화 기반의 정보 공유는 물론, 인터넷 환경이 취약한 작업 현 높은 수준의 캘리브레이션 데이터 품질, 프로세스 준수 및 효율 여 추가적인 품질 및 효율성 개선을 실현할 수 있다. 마지막으로, 을 서로 다른 캘리브레이션 배리언트에 적용하는 경우, 또는 수 장에서의 데이터 사용 가능성도 매우 중요하다. 이상적으로, 캘 적 배리언트 관리는 성공적인 캘리브레이션 프로젝트를 위한 필 통합 CDM Studio를 사용하여 캘리브레이션 데이터를 그래픽으 치적 방법을 모델 기반 최적화에 적용하는 경우가 이에 해당한 리브레이션 엔지니어는 노트북의 중앙 데이터베이스에 접속하 수 요건이다. 벡터는 확장 가능한 CDM 제품을 개인용 캘리브레 로 표시하고 처리할 수 있다. 이를 통해, 확장 가능한 솔루션을 동 다. 여 캘리브레이션 프로젝트를 “확인”할 수 있어야 하므로, 팀원들 이터에서부터 캘리브레이션 팀 및 전사적 차원의 캘리브레이션 일한 레이아웃으로 제공할 수 있어 사용자는 상이한 어플리케이 의 공유된 액세스를 위해 로컬 네트워크상에 캘리브레이션 프로 솔루션과 함께 제공하고 있다. 션을 자유롭게 전환하여 사용할 수 있다. 이러한 작업들을 수행하기 위해 캘리브레이션 엔지니어는 Mic- 젝트에 관한 정보가 존재해야 한다. rosoft Excel처럼 파라미터(행)와 캘리브레이션 배리언트(열)가 캘리브레이션 엔지니어에게 “CDM Studio”는 파라미터 집합 파 결론 함께 표시되어 데이터 편집이 가능한 사용자 인터페이스를 갖춘 전사 차원의 데이터 관리 일을 효율적으로 편집할 수 있는 유용한 툴이다(그림 3). ECU 캘 IECU 캘리브레이션의 경우, 캘리브레이션 배리언트 별로 방대한 툴이 필요하다. 또한, 해당 툴은 CDF2.0과 같은 ASAM 표준 형식, 데이터 관리 솔루션은 전자 기기 개발을 위한 툴 체인과 밀접한 리브레이션 프로세스에서 생성된 파라미터를 간편하게 표시, 비 양의 데이터 값을 결정하고 관리해야 한다. 요구되는 품질을 충 속성 맵, 진단 정보 등과 같은 캘리브레이션의 특정 요구사항을 관련이 있다. 캘리브레이션 데이터 변경은 요구사항 관리 시스 교 및 편집할 수 있다. 다양한 불러오기 옵션들이 제공되기 때문 족하기 위해서는 안정적인 프로세스와 범용 툴의 지원이 필요하 지원해야 한다. 템, 변경 사항 관리 시스템 및 다양한 ALM(Application Lifecycle 에 MATLAB 상의 소프트웨어 개발에서부터 온라인 캘리브레이 다. 또한, 다양한 부서 및 기업의 작업 방식도 고려되어야 한다. Management)과 직접적인 관계가 있다. 효율적인 CDM 시스템 션에 이르는 전반적인 프로세스에 적용 가능하다. CDM Studio는 Wolfgang Löwl(Robert Bosch GmbH 파워트레인 사업부의 툴 개 팀 차원의 협력 은 유연성이 탁월할 뿐 아니라 자동화 인터페이스, API(Applica- CANape, INCA, MARC 등 일반적으로 사용되는 모든 측정 및 캘 발 부문 그룹장)은 “벡터와 함께 당사의 모든 특수 요구사항을 충 ECU 캘리브레이션 작업은 대부분 팀워크로 이루어진다. 일반적 tion Programming Interface) 또는 웹 서비스 등을 통해 기존 시 리브레이션 툴을 지원한다. 족하는 고성능 CDM 시스템을 개발할 수 있었습니다. 지금까지 으로 캘리브레이션 담당 팀은 자동차 OEM 업체, ECU 공급 업체, 스템과 통합할 수 있다. 예를 들어, OSLC(Open Services for Life- 10년간 아무런 문제 없이 CDM 시스템을 사용하고 있습니다.”라 기술 지원 업체 등과 같이 다양한 업체의 팀원들로 구성된다. 세 cycle Collaboration)와의 통합을 통해 변경 사항의 공통 추적이 여러 명의 캘리브레이션 엔지니어들이 팀을 이루어 작업하게 되 고 평가했다. 계화 및 전문화 추세가 가속화되면서 캘리브레이션 팀의 효율적 가능하다. 면 안정적인 데이터 저장 및 관리 솔루션이 필요하다. “vCDM”은 인 협업이 지속해서 중요해지고 있다. 이를 위해서는 작업 결과 캘리브레이션 부서 및 전사 차원의 데이터베이스 기반 플랫폼이 전망 를 신속히 공유할 수 있어야 한다. 이메일 및 인터넷 기반의 업무 특정 요구사항도 적용 가능한 높은 수용성 다. vCDM 시스템은 워크 패키지와의 데이터 충돌을 방지하고 파 앞으로는 품질 개선뿐 아니라 부가 가치 창출 측면에서도 방대한 공유 체계가 매우 유용하지만 여전히 상이한 시스템 간의 데이터 다양한 기술 영역에 걸쳐 사용 시 CDM 시스템은 다양한 특정한 교환을 위해 수작업이 요구되고 있다. 이러한 수작업은 오랜 시 요구사항을 가지고 있다. 이는 섀시 컨트롤러의 캘리브레이션 절 간이 소요될 뿐 아니라 오류에도 취약하다. 그러나 데이터 관리 차와 엔진 컨트롤러의 캘리브레이션 절차가 매우 다르기 때문이
vCDM Enterprise Solution > Roles / rights > Processes
Team Services Team Support > Sharing > Workflows CDM Studio
Workplace Solution 그림 2: 확장 가능한 솔루션은 프로세스 보증, > Individual productivity 데이터 품질 및 캘리브레이션 배리언트 관리에 그림3: CDM Studio 는 체계적인 레이아웃으로 > Fast introduction 관한 모든 요구사항 충족 ECU 캘리브레이션 상태를 표시
5/14 5/15 양의 데이터를 효율적으로 활용하는 것이 더욱 중요해질 것이다.
예를 들어, 데이터 마이닝 알고리즘 및 모델 기반 캘리브레이션 솔루션을 활용해 기존의 캘리브레이션 데이터를 기준으로 새로 운 캘리브레이션 데이터 집합을 자동으로 생성할 수 있다. 또한, 이러한 데이터 집합을 전용 모델을 사용하여 검증할 수도 있다. 이를 통해 머지않아 차량에서 진행되던 작업 대부분을 사무실에 서 처리할 수 있게 될 것이다.
독일 출판물 “ Automobil-Elektronik”, 2015년 6월호 기사 번역판
이미지 권리: Vector Informatik GmbH
링크: Website Vector: www.vector.com General Information Calibration Data Management: www.vector.com/cdm Product Information CDM Studio: www.vector.com/cdm_studio Product Information vCDM: www.vector.com/vcdm Product Information CANape: www.vector.com/canape
저자:
Stephan Herzog Vector Informatik GmbH에서 측정 및 캘리브레이션 사업 개발 관리자 로 재직 중이다.
Andreas Patzer Vector Informatik GmbH에서 측정 및 캘리브레이션 제품군 팀장으로 재직 중이며, 고객 관리 부문도 총괄하고 있다.
Michael Vogel iVector Informatik GmbH에서 vCDM 사업 개발 관리자로 재직 중이다.
5/16 를 업체에서 독자적으로 개발했다. 소프트웨어가 물리적 모델을 기반으로 제작되었으므로 Scilab 모델링 환경이 기능 레이어의 코드 생성기에 사용된다. 기본 소프트웨어는 여전히 C 언어로 수 동으로 코딩한다. 테스트 스탠드 작업을 할 수 없고 몇 번의 짧은 주행 시험만 가 능하기 때문에 경제적인 인터페이스를 통해 ECU에서 필요한 모 든 파라미터를 안정적으로 확보하는 것이 관건이다. 그런 이유로 이더넷 기반의 표준화된 측정 및 보정 프로토콜인 XCP를 선택했 다. 팀은 초기에 만족할 만한 전문 툴을 찾기로 합의하고 벡터의 CANape 측정 및 보정 툴을 사용하기로 했다.
실시간 자동 파라미터 최적화 핵심 ECU 파라미터는 maf-map-engineering의 전문가 또는 사 설 레이싱 팀이 보정한다. 시험 주행 후에 보정하는 것이 아니라 그림 1: 엔진 제어 장치의 보정을 최적화하기 위해 수집한 측정 시험 주행 중에 수집한 측정 결과를 토대로 실시간으로 보정한 결과를 토대로 보정 파라미터를 시험 주행 도중에 실시간으로 조 다. 시험 주행 시간이 극히 짧기 때문에 운전자가 모든 데이터를 정한다. 기록하고 기록된 데이터를 토대로 판단을 내리는 동시에 ECU로 올바른 값을 전송할 정신적인 여유가 없다. 따라서 이 프로세스 소프트웨어 프로세스를 동시에 제어하면 간단해진다. 이 작업에 를 자동으로 처리하는 CANape 기능이 무엇보다 절실하다. 코드 는 코드 작성 및 소프트웨어 개발 작업부터 컴파일러/링커 실행, 는 Real-Time Workshop 코드를 사용하여 Simulink 모델로부터 A2L 생성 및 플래시 프로세스까지 모두 포함한다. 생성한다. 코드 컴파일 및 링크가 끝나면 CANape에서 DLL로 실 행된다. 시험 주행 도중에 런타임 DLL 알고리즘이 XCP 메커니즘 몇 번의 시험 주행으로 얻는 최적의 결과 및 CANape를 통해 엔진 제어 장치에서 측정 데이터를 얻고, 이 드래그 레이싱을 위한 엔진 보정 작업은 완전히 다른 작업이다. 를 사용하여 최적의 파라미터를 계산한 다음 제어 장치의 파라미 이 작업에는 연비 충족이나 다양한 엔진 또는 차량 변형 제품 지 터를 자동으로 보정한다(그림 2). 원 등의 노력은 중요하지 않다. 대신 모든 노력은 오직 한 가지 목표를 위해 집중되어야 하는데 바로 약 400m 거리를 최대한 빨 리 달리는 것이다. 그뿐만 아니라 레이싱 팀은 든든한 재정적 지 칼날위의 아슬한 질주 원이 보장되는 기업이 아니라 대부분 사치스런 취미를 즐기는 개 인일 뿐이다. 잘못된 보정으로 엔진 손상이 발생하면 새 엔진을 드래그 레이싱 전용 엔진 제어 장치의 최적화된 파라미터 설정 구입하기 위해 엄청난 비용을 부담해야 한다.
자동차의 엔진 제어 장치 (Engine controller)를 보정할 때 전자 개발자는 일반적으로 다양한 경로의 시나리오에 대해 엔진 테스트 엔진 시험을 위한 주행에 테스트 스탠드를 사용할 수도 없다. 첫 스탠드를 이용하며 수 차례 시험 주행을 강행한다. 하지만 드래그 레이싱(Drag Racing)에 사용되는 특수한 엔진 제어 장치를 위한 번째 이유로, 드래그 레이싱이라는 틈새 애플리케이션에 대한 수 보정 툴은 없다. 벡터(Vector Informatik Gmbh)의 CANape 측정 및 보정 툴을 사용하면 최소한의 예산과 몇 번의 시험 주행만으 요가 적기 때문에 적합한 테스트 스탠드가 없다는 점을 들 수 있 로 엔진이 파손될 위험을 지속적으로 감수해야 하는 상황에서도 테스트 스탠드 없이 엔진 제어 장치가 최고의 성능을 발휘하도록 보 다. 둘째로, 준정적(Quasi-static Operation) 운행 시 최고 속도 정할 수 있다. 10,000rpm 및 최대 과급 압력(Charge Pressure) 3.5bar에서 엔진 을 최적화 할 수 없다. 부하가 너무 커서 엔진이 아주 짧은 시간 동안만(기어당 2~3초) 엔진 과열 없이 이 속도를 견딜 수 있다. 주말에 자동차 경주장에 가서 수백 마력의 엔진을 장착한 중형 서 엔진을 구입한 후 개조 과정을 통해 레이싱의 요구사항에 맞 차량이 귀가 멍멍해질 정도의 소음과 엄청난 가속으로 402.34m 게 변경한다. 개조가 동전의 한 면이라면 엔진 제어 장치의 보정 레이싱 팀에게 현실성 있는 유일한 방법은 운전 시 최대한 많은 거리를 순식간에 질주하는 것을 본 적이 있다면 이는 십중팔구 은 나머지 한 면이다. 이때 온갖 난관이 펼쳐지는데 그 이유는 엔 측정 변수를 확보한 다음 이 정보를 토대로 보정 파라미터를 최 드래그 레이싱일 것이다 (그림 1). 이런 가속 경주에서는 순식간 진 제어 장치에 설정되어 있는 기존의 파라미터는 개조된 엔진에 적화하는 것이다. 하지만 이 방법 역시 갖가지 제한을 피할수는 에 최고의 엔진 성능을 발휘해야 하기 때문에 엔진 제어 장치의 는 좀처럼 들어맞지 않기 때문이다. 없다. 엔진은 몇 번 운전에 사용하고 나면 교체해야 한다. 그러면 보정에 엄청난 개발 노력을 쏟게 마련이다. 개발 팀이 쏟는 노력 서도 운전하는데 걸리는 시간은 겨우 몇 초 를 넘지 않는다. 따라 의 백미는 바로 최소한의 예산으로 최적의 결과를 얻는 것이다. ECU의 측정 및 보정은 매우 어렵지만 제품 개발에 관여하는 자 서 최적화 프로세스의 성공/실패 여부는 아주 기발한 방법을 찾 최대한 엔진의 스트레스 한계에 다가가 동력을 최대한 끌어내면 동차 제조업체 및 부품 공급업체에게 있어서는 일상적인 일이기 는 데 있다. 서도 엔진이 파손되지 않도록 해야 한다. 운전뿐 아니라 엔진의 도 하다. 보정 담당자는 테스트용 스탠드와 차량 내부에 있는 엔 보정 과정 역시 “칼날위의 아슬한 질주(A Ride on the Razor’s 진을 가지고 다양한 코스 시나리오를 실행할 때, A2L 설명 파일 시제품 대신 특수 엔진 제어 장치의 사용 Edge)”라는 묘사가 전혀 무색하지 않다. 을 통해 ECU 측정 변수 및 내부 파라미터에 액세스하여 최적의 독일 베를린에 소재한 maf-map-engineering이 드래그 레이싱에 파라미터를 찾아낸다. 이 작업은 온갖 제약 조건 때문에 매우 복 매우 효율적인 엔진 제어 장치를 개발했다. 차량 레이싱에 대한 최대의 동력을 발휘하기 위한 핵심인 엔진 제어 장치 보정의 최 잡하다. 한편으로는 다양한 변형 차량 및 엔진 제품들을 고려해 열정이 중심이 되어 설립된 이 업체는 엔진에서 얻는 동력을 극 적화 야 하고 갖가지 배출 표준까지 충족해야 한다. 이와 동시에 OEM 대화하는 완전한 솔루션을 제공한다. 이 기능은 세계에서 가장 그림 2: CANape는 ECU의 상세 데이터, 버스 데이터, 아날로그 개인적인 차원에서 드래그 레이싱용 차량을 제작하고 유지보수 별 주행 동작에 맞게 ECU가 임프린트(Imprint)되어야 한다. 또한 빠른 VW Polo로 입증되었는데 이 차량은 1,047마력을 발휘한다. 데이터 등이 입력되는 제어 알고리즘을 개발하는 데 사용할 뿐 하기 위해 시간과 비용을 투자하려면 엄청난 열정과 끈기가 필요 모든 최적화는 특정 연비 한도를 충족한다는 전제하에 이루어져 이 성능의 원천은 ECU481 엔진 제어 장치인데 모든 부품을 이상 아니라 측정 중 온라인 계산 등의 다른 애플리케이션에도 사용 하다. 여기서 가장 핵심이 되는 것이 바로 엔진이다. 대게 시중에 야 한다. 엔진 보정은 보정 담당자 및 소프트웨어 개발자가 엔진 적으로 제어하기 위해 ECU481의 전체 하드웨어 및 소프트웨어 할 수 있다.
5/18 5/19 그림 3: 여러 파라미터를 시각화하 고 편리한 보정 옵션을 제공하는 CANape.
모든 파라미터에 대해 개별 애플리케이션 모델을 개발하려면 엄 저자: 청난 노력이 필요하기 때문에 많은 파라미터는 여전히 수동으로 조정된다. CANape로 기록된 측정 데이터를 정밀 분석하면 주요 문제가 모두 드러나며 수정을 신속하게 실행할 수 있게 된다(그 림 3). 또한 CANape는 필요한 시험 주행 횟수를 최소한으로 줄 여 준다. 시험주행 결과로부터 새 파라미터 값이 생성되는데, 개 발자는 새 코드를 생성하기 전에 이 값을 새 모델 값으로 구현하 거나 온라인에서 제어 장치의 RAM에 이 값을 설정한다. 안드레아스 패처(Andreas Patzer) 이 방식이 효과가 있고 점점 인기를 끌고 있다는 증거는 2010 KOG(King of Germany) 이벤트에서 확인할 수 있는데 안드레아스 패처는 1986년부터 1993년까지 IT 분야의 전자 제품 maf-map-engineering의 엔진 제어 장치를 장착한 차량이 전륜 기술자 교육을 받은 후 독일 칼스루에 공과대학교(Technical Uni- 구동차 부문에서 1위를 차지했다. 한편, 이 일반 자동차 부문에서 versity of Karlsruhe)에서 전기공학을 공부했다. 대학에서 측정 이룬 성공으로 다른 업계의 주목을 받게 되었다. 효율적인 측정 및 제어 엔지니어링뿐 아니라 정보 기술, 산업 자동화를 전공했 및 보정 기능을 갖추고 이 특수한 애플리케이션에 맞게 최적의 다. 졸업 후에는 통신 업계에 몸담았다. 2003년 슈투트가르트에 상태로 보정된 엔진 제어 장치를 경주용 보트용으로도 제작해 주 위치한 벡터에 입사한 패처는 측정 및 보정 제품군 사업 개발 매 길 원하는 보트레이서들의 문의가 이어진 것이다. 니저로서 고객과 개발 및 영업 간의 접점을 조율하는 업무를 담 당하고 있다.
그림 제공: 메인 화보 및 그림 1: 베른트 사이델 박사(Dr. Bernd Seydel) 그림 2, 3: Vector Informatik GmbH
링크: maf-map-engineering 홈페이지: www.maf-map-engineering.de 벡터 홈페이지: www.vector.com CANape 제품정보: www.vector.com/canape CANape 옵션 Simulink XCP Server 제품정보: www.vector.com/ simulinkxcpserver
5/20 6/0 6/1 신속하고 신뢰성 있는 ADAS 개발
벡터는 ADAS 개발에 필요한 통합 솔루션을 지원합니다.
벡터는 운전자 보조 시스템 개발을 위한 임베디드 컴포넌트와 함께 소프트웨어 및 하드웨어 툴로 구성된 완벽한 솔루션을 제공합니다.
> 여러 센서의 데이터 융합으로 신속하게 멀티 센서 > 센서 데이터 획득을 위한 빠른 ECU 연결 어플리케이션 개발 > 오디오 및 비디오 데이터를 손쉽게 전송할 수 있는 > 신뢰할 수 있는 객체 검증 광범위한 AUTOSAR 베이직 소프트웨어 > OEM 별 요구사항에 맞춘 신속한 프로토타입 (by passing) 자세한 정보: www.vector.com/adas
벡터의 솔루션을 통해 운전자 보조 시스템을 빠르고 효율적으로 개발하십시오.
6/2
Vector Korea IT Inc. | Phone +82 2 807 0600 | www.vector.com ESIGN IDEA 기술기사 D
최소 초당 1기가바이트의 고속 데이터 속도 저렴한 가격
ADAS 개발을 위한 데이터 저장 이렇게 부분적으로 모순되는 요구사항들을 동시에 충족시킬 수는 없
으므로 절충이 필요하다. 프로젝트에 따라 솔리드 스테이트 드라이브 [그림 1: 광범위한 센서의 데이터를 기록하고 동시에 전송해야 한다. 센서 데이터 융합을 통해 자동차 주변에 대한 완벽한 센서와 ECU 데이터의 확장 가능한 저장 데이터를 얻게 된다.] [그림 1] 광범위한 센서의 데이터를 기록하고 동시에 전 (SSD) 또는 고전적인 하드디스크가 사용된다. 차량에 적합한 온도 범위 송해야 한다. 센서 데이터 융합을 통해 자동차 주변에 데이터 상세 기록의대한 과제 완벽한 데이터를 얻게 된다. 와 같은 요구사항을 언제나 충족시킬 필요는 없다.
하루의 작업일 동안 초당 1GB로 생성되는 자율주행을 위한 테스트 차 우선, ADAS 센서들을 레코더에 연결한다. 센서가 초당 100MB 를 전송하려면 각 센서가 레코더와 량의 데이터를 완전히 기록하기 위해 저장 시스템은 거의 30TB의 용량 기가비트(Gigabit)의 대역폭을레코더의 가지는 Ethernet 에너지으로 연결돼야 관리 한다 시스템은. ECU 와 레코더 전원사이의 연결도부 이 필요하다. 현재 이러한 메모리 크기와 여기에 필요한 전송속도를 실현 마찬가지이다. 족이나 전압 강하로 인한 이상기능이 발
할 수 있는 것은 다수의 독립적인 대형 하드디스크를 디스크 네트워크로 메모리 매체로 계획된생하지 것은 하드디스크의 않는 사용이며 한 전원을, 이것으로 아래의 끌 요구사항들이 때까지 충족돼야 시스템 한다. 결합하는 RAID 시스템뿐이다. RAID는 병렬 디스크 접속이 가능하다. > 가능한 최대의의 디스크 전원을 용량 유지하는 역할을 한다. 반면에, > 차량에 적합한 온도 범위 그 결과, 각각의 디스크 성능을 실질적으로 합칠 수 있고, RAID 레벨에 > 기계적 안정성WLAN을 통해 계측 데이터를 판독하여 전 > 최소 초당 1 기가바이트의 고속 데이터 속도 따라서는 예비 기능을 통하여 개별적인 디스크 오류에 대한 보호작용도 > 저렴한 가격송하는 중에 잠시 멈출 때 레코더가 절전 모
가능하다. 드로 전환되지 않아야 한다. 동시에, 차량 이렇게 부분적으로 모순되는 요구사항들을 동시에 충족시킬 수는 없으므로 절충이 필요하다.
프로젝트에 따라 솔리드배터리에는 스테이트 드라이브 확실하게(SSD) 또는 고전적인 재시동할 하드디스크가 수 사용된다 있는. 차량에충 저장 하드웨어 자원을 최대로 활용하기 위하여 아래의 항목들이 중요 적합한 온도 범위와분한 같은 요구사항 에너지가을 언제나 충족시킬 항상 필요는 있어야 없다. 한다.
자동차 업계가 자율주행을 위한 기술 개발에 전력을 다하고 있는 가운데, 주변 환경에 대한 인간의 인지를 대 한 역할을 한다. 최상의 레코더 하드웨어라 할지라도 최적 레코더 소프트웨어 으로 작동하는 레코더 소프트웨어는 있어 체하기 위해서는 고해상도의 레이더와 영상 센서를 갖춘 운전자 보조 시스템이 중요하다. 이러한 시스템에서 ADAS 개발을 위한 데이터 저장 - 센서와 ECU 데이터의 확장 가능한 저장 2/10 생성되는 다량의 데이터를 통신 네트워크를 통해 전송하여 실시간으로 처리해야 하기 때문이다. 그러나 이는 소프트웨어와 드라이버의 구성 야 한다. 이 소프트웨어의 일차 업무는 계측 고성능 Ethernet PHY 사용 데이터를 받아서 디스크 시스템에 기록하는 레코더 솔루션에 있어 전례 없는 도전과제를 제기하고 있다. 여러 가지 중요 사항을 고려하여 적절한 시스템을 Ethernet 메시지 길이 설정 것이다. 추가로, 소프트웨어는 개발자에게 선택해야 하는 이유이기는 하다. 글 | Andreas Patzer, 벡터 · 자료제공 | 벡터코리아(www.vector.com) 적절한 RAID 레벨 선택 기록의 시작과 정지와 같은 서비스를 제공 하며, 트리거 조건을 규정할 수 있게 한다. 레코더의 CPU는 이러한 대량의 데이터 스트림을 처리할 수 있어야 하 데이터는 다수의 Ethernet 포트를 통 현재의 레이더와 영상 센서는 대략 초 항은 더욱 많아진다. 므로 버스트(Burst) 단계에서 증가하는 데이터량을 완충시킬 수 있는 충 하여 동시에 레코더에 도달한다. 전형적 당 100MB의 계측 데이터를 전달한다. 이 분한 RAM이 있어야 한다. 으로, 여기에는 ECU로부터의 XCP-on- 외에 ECU 내부로부터 대략 초당 50MB의 데이터 상세 기록의 과제 실제에 있어서, 테스트 주행은 테스트의 범위와 지속시간 등이 매번 상 Ethernet 정보를 비롯하여 엔지니어들이 센서 융합 데이터가 생성된다. 예를 들어, 5 우선, ADAS 센서들을 레코더에 연결한다. 센서가 초당 100MB를 전송하 당히 다를 수 있다. 어떤 경우에는 계측 데이터를 다른 시스템으로 하루 자율주행 또는 ADAS 어플리케이션에 사 개의 레이더 센서와 2개의 영상 시스템을 려면 각 센서가 레코더와 기가비트(Gigabit)의 대역폭을 가지는 Ethernet 만에 전송할 수 있고, 또 어떤 경우에는 장기적인 테스트가 일주일 내내 용하는 레이더 센서와 카메라로부터의 raw 갖춘 자동차의 경우, 다른 여러 계측 데이터 으로 연결돼야 한다. ECU와 레코더 사이의 연결도 마찬가지이다. 진행될 수도 있다. 여기서 분명히 해야 할 것은 로거에 있는 디스크를 교 data가 포함된다. 데이터를 하드디스크에 를 합치면 수집과 저장에서 다루어야 하는 체함으로써 데이터 전송이 가능한지, 또는 장기간의 테스트 주행을 방해 효율적으로 전송하기 전에 레코더 소프트 데이터량은 대략 초당 1GB에 이른다. 메모리 매체로 계획된 것은 하드디스크의 사용이며, 이것으로 아래의 하지 않는 데이터를 신속하게 판독하는 방법이 있는가 하는 문제이다. 하 웨어가 해야 하는 중요 업무는 다양한 데이 따라서, 테스트 차량이 생성하는 데이터는 요구사항들이 충족돼야 한다. 루 중에 생성되는 데이터를 백업할 수단이 없는 경우 사용자는 디스크 크 터 소스의 시간 동기화다. 데이터를 저장한 시간당 약 3.6TB, 하루에 28.8TB가 된다(그 기를 조정하는 것 외에 달리 방법이 없다. 후에는 더 이상 처리할 필요가 없도록 CPU 림 1). 이것을 테스트 차량의 수와 사용 일수 가능한 최대의 디스크 용량 계측 데이터가 누구를 위한 것인가 하는 문제도 남는다. 특정 센서의 자원을 최대한 최적으로 사용하여 데이터를 로 곱하면 엄청난 양의 데이터가 된다. 더구 차량에 적합한 온도 범위 raw data를 센서 공급자에게 보내려면 모든 데이터가 하나의 계측 파일 준비시켜야 한다. 이를 위하여, 데이터 크기 나, 경험에 의하면 기술이 개발될수록 요구사 기계적 안정성 에 저장된 경우 별도의 작업 단계에서 해당 데이터를 추출해야 한다. 에 상관없이 일정하게 기록할 수 있는 계측
60 AUTOMOTIVE Report APRIL 2017 61 6/4 6/5
60-63p AR 201704월호.indd 60 17. 3. 27. 오후 12:01 60-63p AR 201704월호.indd 61 17. 3. 27. 오후 12:01 기술기사 기술기사
ESIGN IDEA 자동으로 데이터를 기록할 수 있으며, 차량에 대한 수정은 불필요하다. 시스템은 표준화된 ASAM- D자동으로 데이터를 기록할 수 있으며, 차량에 대한 수정은 불필요하다. 시스템은 표준화된 ASAM- MDF-4.1 포맷을 사용하여 데이터를 저장하므로, 계측 데이터를 평가 과정의 또 다른 툴에서 직접 MDF-4.1 포맷을 사용하여 데이터를 저장하므로, 계측 데이터를 평가 과정의 또 다른 툴에서 직접 기술기사
사용할 수 있다. 사용할 수 있다. 적인 확장성을 가지면 ADAS 데이터 기록 중에 발생할 수 있는 모든 요 완전히 확장 가능한 솔루션 구사항을 최상으로 충족시킬 수 있다. 벡터의 레코더 플랫폼은 이미 여러 개의 10-gigabit 및 1-gigabit 기술기사 Ethernet 포트가 장착된 PC 디자인에 기초한다. 확장 장치에는 최대 8 전형적인 Ethernet과 차량용 Ethernet 개의 RAID 하드디스크를 매우 빠르고 완전하게 교환할 수 있는 공간이 신호 소스 연결을 원한다면 전형적인 Ethernet과 차량용 Ethernet이 있다. 또한 무정전 전원공급장치(UPS)와 같은 추가 확장을 위한 공간 모두 적합하다. 필요한 연결의 수는 프로젝트마다 크게 다를 수 있다. 직 도 있다. VX1000 계측 및 캘리브레이션 하드웨어는 raw 센서 데이터와 접 연결을 위한 포트의 수가 레코더에 충분하지 않은 경우 스위치를 위 ECU 융합 데이터를 모두 수집하여 Ethernet을 통하여 PC로 보내는 데
쪽에 연결해야 한다. 그러면 스위치가 위쪽 소스의 데이터를 10 gigabit 사용된다.
[그림 4: 고속도로 주행지원, 사각지대 모니터링 기능이 있는 차선 변경 지원, 또는 자동 주차와 같이 움직이는 대상 및 Ethernet 케이블을 통하여 함께 레코더에 보낸다. 필요한 경우, 스위치 CANape는 레코더 소프트웨어이다. CANape version 15.0에 새롭게 [그림고정된 대상의 4] 모든고속도로 시나리오에 주행지원,적용할 수 있는 vADASdeveloper 사각지대 의모니터링 시각화 기능] 기능이 있는 차선 변경 지원, 또는 자동 주차와 같이 움직이는 대상 및 고정된 대상의
는 차량용 Ethernet을 전형적인 Ethernet으로 물리적으로 변환시키는 포함된 ‘고성능 분산 기록’ 기능은 여러 계측 인스턴스를 동시에 사용할 모든 시나리오에 적용할 수 있는 vADASdeveloper의 시각화 기능 [그림 2] XCP on Ethernet, 영상 및 레이더 raw data를 위한 ADAS [그림 2: XCP on Ethernet, 영상 및 레이더 raw data 를 위한 ADAS 환경에서 초고속 데이터 전송속도를 위한 확장 가능한 [환경에서그림 2: XCP 초고속 on Ethernet, 데이터 영상 전송속도를 및 레이더 raw위한 data 확장를 위한가능한 ADAS 분산 환경에서 레코더 초고속 게이트웨이데이터 전송속도를 기능을 위한 확장 수행할 가능한 수도 있다. 그래서 Ethernet의 기본 구조는 수 있으며, 이로 인하여 컴퓨터의 다중 코어 아키텍처를 최대로 활용할 이미지 권리: Vector Informatik GmbH 분산 레코더 솔루션] 분산솔루션 레코더 솔루션]
예를 들어 프로젝트 기간에 필요한 포트의 수가 늘어나는 경우 확장 가능 수 있다(그림 2). 따라서 인스턴스들은 하나의 PC에 한정되지 않는다. 오 링크: 루션으로 더 빠르고 더 신뢰성 있게 실현할 벡터 홈페이지: www.vector.com 하도록 만들어진다. 히려 사용자는 네트워크상의 다른 PC들에 쉽게 분산시킬 수 있다. 레코 수 있다. 다양한 종류의 센서 소스들과 이들 저자: 더 솔루션의 일부로 사용되는 PC들은 Ethernet으로 연결하기만 하면 된 을 융합하기 위한 소프트웨어 개발에는 작 하드디스크 | 상호교환 가능한 RAID 시스템 다. CANape는 계측 업무를 여러 PC에 분산시키고 시간 동기화를 보장 업 프로토타입을 사용하는 것이 도움된다. 고성능 RAID 제어기를 제공하는 것 이외에, 하드웨어에 충분한 수의 한다. 트리거에 의한 계측에서도 CANape는 모든 계측 인스턴스에 대하 벡터의 vADASdeveloper 프로토타이핑 환
하드디스크 슬롯이 있어서 프로젝트 사양에 따라 유연성 있게 장착될 수 여 프로세스의 정확한 시간 제어를 제공한다(그림 3). 사용자는 전체 설 Andreas Patzer 경과는 Karlsruhe Baselabs의 Institute of Technology Create에서 전기공학을 알고리즘 전공하였다 라이브. 전문분야는 계측 제어 기술과 정보 자동화 기술이다. 2003 년 슈투트가르트에 있는 Vector Informatik GmbH 에 있어야 한다. 여기서 중요한 것은 모든 디스크가 장착된 전체 RAID 시 정에 대하여 단 하나의 CANape 라이선스만이 필요하다. 입사하였으며, 계측과러리의 캘리브레이션 결합이 제품 라인의실제 팀장으로서 사용에서 “고객관리와 입증되었다 서비스”를 담당하고 있다.
스템이 교체가 용이하거나 데이터 다운로드를 위한 고성능 인터페이스가 사용자는 CANape를 다양한 방식의 로거 소프트웨어로 사용할 수 있 (그림 4). 본 보도자료 배포 시 최종 인쇄물을 당사에 보내주시면 감사하겠습니다. 있어야 한다는 것이다. 는 이점이 있다. 시스템은 전문가가 아닌 일반 사람들도 쉽게 사용할 수 배포와 관련하여 문의사항이검증과 있으시면 테스트 언제든지 외에도 연락해주시기 벡터는 바랍니다. 예를 들어
있다. 그래서, 어플리케이션 추가 개발에 종사하는 엔지니어들은 소프트 Hypervisor/POSIX 기반의 개념을 가진
레코더 소프트웨어 | 데이터 소스당 하나의 인스턴스 웨어의 전체 기능을 임의로 사용할 수 있다. 필요한 테스트주행 거리를 ECU 아키텍처의 정의 단계와 같은 다중코 ADAS 개발을 위한 데이터 저장 - 센서와 ECU 데이터의 확장 가능한 저장 9/10 가장 효율적인 작동은 각 데이터 소스에 대하여 데이터를 수신하여 디 달성하기 위하여 개발 지식이나 툴 지식이 없는 사람은 야간에 주행할 수 [어그림 고성능 4: 고속도로 플랫폼에서 주행지원 컴퓨팅, 사각지대 중심의 모니터링알고 기능이 있는 차선 변경 지원, 또는 자동 주차와 같이 움직이는 대상 및 스크에 저장하는 하나의 계측 인스턴스를 할당할 때 가능하다. 이 경우, 있다. CANape는 자동으로 데이터를 기록할 수 있으며, 차량에 대한 수 고정된리즘 요구사항에 대상의 모든 대한 시나리오에 특정 프로젝트 적용할 수의 있는지 vADASdeveloper 의 시각화 기능]
각 인스턴스는 별개의 계측 파일을 생성한다. 그 결과, 전체 계측은 다수 정은 불필요하다. 시스템은 표준화된 ASAM-MDF-4.1 포맷을 사용하 원도 제공한다. 나아가, 주행 조작을 위한 [[그림그림 3: 3] CANape CANape를를 이용한 이용한 센서와 센서와 ECU 데이터 ECU 기록 데이터, 알고리즘 기록, 최적화 알고리즘 및 실제 최 또는 가상 ECU 신호인가] [그림 3: CANape 를 이용한 센서와 ECU 데이터 기록, 알고리즘 최적화 및 실제 또는 가상의 ECU계측 신호인가 파일로] 나누어진다. 소프트웨어가 하는 일은 계측 데이터의 통합 여 데이터를 저장하므로, 계측 데이터를 평가 과정의 또 다른 툴에서 직 전술 알고리즘을 계산하는 자동차의 컴퓨터 적화 및 실제 또는 가상 ECU 신호인가
성과 시간 동기화를 보장하는 것이다. 그래서 추가 소스로 인하여 프로젝 접 사용할 수 있다. 에는 더욱 유연한 운영 시스템이 필요하다. 이미지 권리: Vector Informatik GmbH 데이터 포맷이 필요하다. 트가 확장되면 또 하나의 계측 인스턴스가 만들어질 뿐이다. 여기에, AUTOSAR adaptive 플랫폼이 적
ADAS 개발을 위한 데이터 저장 - 센서와 ECU 데이터의 확장 가능한 저장 7/10 요약하면, 이렇게ADAS 개발을상정할 위한 수 데이터 있다. 저장 -하드웨 센서와 ECU 데이터의 확장 가능한 저장 7/10 결론 용된다. 이것은 ECU가 미래의 요구사항에 어와 소프트웨어의 개별적인 구성요소들을 레코더 하드웨어 | 클론 선호 일관성 있게 확장 가능한 아키텍처를 갖춘 레코더 솔루션을 사용함으 링크충족하도록: 지원한다. 매우 신중하게 선택해야 한다. 하드웨어와 하드웨어 자원이 모두 고갈되고 하드디스크 슬롯과 Ethernet 포트가 로써 운전자 보조 시스템 개발자들은 거의 무한대로 확장이 가능한 매우 벡터 홈페이지: www.vector.com 소프트웨어의 완전한 솔루션은 서로 완벽하 모두 사용 중인 경우, 이 문제는 레코더를 추가로 사용하여 해결할 수 있 유연한 시스템을 가진다. 현재의 자율주행 프로젝트에서 레이더, 영상 및 게 어울려야 한다. 다. 그러나 시간 동기화를 상실해서는 안 된다. 작동 개념의 문제도 발생 ECU 데이터를 저장하기 위한 초당 500MB 내지 700MB의 데이터 속도 저자: 한다. 사용자는 어떻게 여러 레코더에서 동시에 정확한 계측을 시작하고 도 현재 단 하나의 PC로 다룰 수 있다. 요구사항이 증가함에 따라, 투자 저자 Andreas Patzer는 Karlsruhe 확장 가능한 기본 개념은 중지할 수 있는가? 이상적으로는, 사용자의 관점에서 볼 때 계측 업무를 에 대한 안전은 VX1000 하드웨어로 보장된다. 이것은 완전한 솔루션의 Institute of Technology에서 전기공 학을 전공하였다. 전문분야는 계측 최대의 유연성을 제공한다 하나의 플랫폼에서 하든 여러 개에서 하든 추가 레코더가 완전히 투명하 확장성에 의하여 ECU와 raw 센서 데이터 모두에 사용될 수 있다. 제어 기술과 정보 자동화 기술이다. 2003년 슈투트가르트에 있는 Vector 센서 연결, 하드디스크, 소프트웨어와 하 도록 만드는 것이다. 자율주행에 필요한 모든 관련 대상들과 함께 주위를 완전히 감지하는 에 입사하였으며, 계측과 캘리브레이 션 제품 라인의 팀장으로서 고객관 드웨어와 같은 모든 기능 장치에 대한 종합 것은 소프트웨어와 하드웨어 툴 및 내장된 구성요소들로 구성된 종합 솔 리와 서비스를 담당하고 있다.
Andreas Patzer 는 Karlsruhe Institute of Technology 에서 전기공학을 전공하였다. 전문분야는 계측
62 AUTOMOTIVE Report 제어 기술과 정보 자동화APRIL 기술이다 2017 63. 2003 년 슈투트가르트에 있는 Vector Informatik GmbH 에 6/6 입사하였으며, 계측과 캘리브레이션 제품6/7 라인의 팀장으로서 “고객관리와 서비스”를 담당하고 있다.
60-63p AR 201704월호.indd 62 17. 3. 27. 오후 12:01 60-63p AR 201704월호.indd 63 17. 3. 27. 오후 12:01
본 보도자료 배포 시 최종 인쇄물을 당사에 보내주시면 감사하겠습니다. 배포와 관련하여 문의사항이 있으시면 언제든지 연락해주시기 바랍니다.
ADAS 개발을 위한 데이터 저장 - 센서와 ECU 데이터의 확장 가능한 저장 9/10 RH850/V1R을 이용한 Raw 레이더 데이터 및 AURIX™ 레이더 마이크로 컨트롤러를 이용한 Raw 알고리즘 데이터 고성능 레코딩 레이더 데이터 및 알고리즘 데이터 고성능 레코딩
Case Study Renesas Case Study Infineon
파트너 장점 파트너 장점 Renesas는 자동차 어플리케이션을 위한 MCU와 SOC의 세계 RH850/ V1R 마이크로프로세서에 최적화된 end-to-end 솔루션 Infineon Technologies AG는 삶을 더 편안하고 안전하며 친환경 Infineon AURIX 마이크로컨트롤러에 최적화된 end-to-end 적인 공급업체로서, ADAS와 자율 주행을 위한 종합적인 솔루션 > 여러 센서 제조사를 위한 범용적인 계측 솔루션 적으로 바꾸어 나가는 반도체 솔루션 업계의 선두주자이다. 솔루션 인 Renesas autonomyTM platform을 제공한다. Renesas > 완전한 plug-and-play 시스템 설치 및 테스트 2천만 개 이상의 레이더 칩을 판매한 이 회사는 빠르게 성장하는 > 여러 센서 제조사를 위한 범용적인 계측 솔루션 autonomyTM의 일부인 RH850/V1R 시리즈는 더 나은 객체 해 > 단일 POD가 레이더 데이터와 XCP 데이터를 모두 포착함으로써 운전자 보조 시스템 시장에서 전 세계를 선도하고 있다. > 완벽하게 설치 및 테스트 된 plug-and-play 시스템 상도와 움직임 탐지를 위한 고도의 컴퓨팅 성능과 자유로운 프로 레이더 센서를 위한 공간 요구사항 최소화 및 통합 비용 감소 > 단일 POD가 Raw 레이더 데이터와 XCP 데이터를 모두 포착함 그래밍이 가능한 DSP를 제공한다. > 센서의 수에 대한 완전한 확장성 과제 으로써 레이더 센서를 위한 공간 요구사항 최소화 및 통합 비용 > 레이더 및 비디오 센서, ECU, 버스 시스템, 아날로그 계측 등의 Raw 레이더 데이터, 내부 컨트롤러 시그널 및 버스 메시지의 감소 도전과제 모든 계측 데이터를 CANape에서 정확하게 동기화 동시 레코딩 > 센서의 수에 대한 완전한 확장성 Raw 레이더 데이터, 내부 컨트롤러 시그널 및 버스 메시지의 Infineon사의 정교한 77-GHz 칩은 단거리와 원거리에 모두 탁월 > 레이더 및 비디오 센서, ECU, 버스 시스템, 아날로그 계측 등의 동시 레코딩 하여 적응형 크루즈 컨트롤이나 충돌 경고와 같은 레이더 기반의 모든 계측 데이터를 CANape에서 정확하게 동기화 레이더 솔루션 개발을 위해 레이더 센서로부터 두 종류의 데이터 운전자 보조 시스템에 사용된다. 최대 250미터 거리의 객체들을 를 포착하는 것이 필요하다. 이 데이터는 탐지된 객체 목록과 감지할 수 있다. XCP 데이터 형태의 FFT 계산 결과와 같은 Raw 레이더 데이터 레이더 솔루션을 개발하려면 레이더 센서로부터 두 종류의 데이 와 알고리즘 데이터이다. 이러한 시나리오에서 최대100 MB/s의 터를 획득해야 한다. 즉, 감지된 객체 목록과 XCP 데이터 형식의 Raw 레이더 데이터와 최대 50MB/s XCP 데이터를 동시에 수신 FFT 계산 결과와 같은 Raw 레이더 데이터와 알고리즘 데이터가 할 수 있다. 이 데이터는 버스 데이터 등과 같은 다른 정보와 동 필요하다. 이러한 상황에서 최대 100 MB/s의 Raw 레이더 데이 시에 레코딩되어야 한다. 프로세서는 레이더 데이터가 손실되지 터와 최대 50 MB/s의 XCP 데이터를 동시에 수신할 수 있다. 이 않도록 계측 데이터의 전송은 중단되지 말아야 한다. 러한 데이터는 버스 데이터와 같은 다른 정보와 동기화되어 기록 되어야 한다. 솔루션 컴팩트한 고성능 계측 및 캘리브레이션 시스템과 데이터 추적 솔루션 계측 인터페이스 데이터 추적 계측 인터페이스를 갖춘 소형의 고성능 계측 및 레이더 및 XCP 데이터에 대한 물리적인 접근은 VX1000 제품군 캘리브레이션 시스템 을 통해 수행된다. 플러그온 디바이스(POD)는 2개의 3.125 데이터에 대한 물리적인 접근은 VX1000 계측 및 캘리브레이션 Gb/s Aurora 인터페이스를 거쳐 RH850/V1R 마이크로컨트롤 하드웨어로 가능하다. POD(plug-on device)는 Aurora 인터페이 러에 직접 연결된다. POD는 Vector High Speed Serial 스와 4 LVDS 레인을 통하여 AURIX 레이더 마이크로컨트롤러에 Link(HSSL2)를 통해 5Gb/s의 속도로 VX1135 베이스 모듈에 데 직접 연결된다. POD는 벡터의 High Speed Serial Link 2(HSSL2) 이터를 전송한다. 그 후 베이스 모듈은 2개의 Gigabit Ethernet 를 통하여 VX1135 베이스 모듈에 최대 5 Gbit/s의 속도로 데이 연결을 통해 레이더 및 XCP 데이터를 전송한다. 특별한 계측 방 터를 전송한다. 베이스 모듈은 2 Gbit Ethernet 연결을 통하여 법은 레이더 및 XCP 데이터가 Aurora 인터페이스에 과부하를 Raw 데이터와 XCP 데이터를 CANape MCD 툴로 보낸다. 현존하 발생시켜 데이터 손실로 이어지지 않도록 한다. 모든 CAN/ 는 모든 CAN/CAN-FD 연결은 VX1135에 직접 연결될 수 있다. CAN-FD 연결은 VX1135에 직접 연결될 수 있다. 데이터는 다시 데이터는 다시 Ethernet 인터페이스를 통하여 CANape으로 전송 Ethernet 인터페이스를 통해 CANape로 전송된다. CANape의 된다. Distributed High Performance Recorder(DHPR) 개념은 서로 CANape의 Distributed High Performance Recorder (DHPR) 다른 센서 제조사의 Raw 데이터 프로토콜에서 빠르고 쉽게 사 개념은 센서와 개별 레코더들을 연결하여 여러 센서 제조사들의 용할 수 있는 개별 레코더에 센서를 직접 연결할 수 있다. 레코더 미가공 자료(Raw Data) 프로토콜을 빠르고 쉽게 사용할 수 있다. 는 PC 자원을 최적으로 사용하며, 분산 환경에서 다수의 PC에서 레코더는 PC 자원을 최적으로 활용하며, 분산 환경에서는 여러 사용될 수 있다. 이러한 아키텍처에서 CANape는 시간 동기화를 PC에 의해 사용될 수도 있다. 이러한 아키텍처에서 CANape는 비롯해 동작의 시작, 정지 및 트리거를 담당한다. 하드 드라이브 시간 동기화와 시작, 정지, 트리거 작동을 담당한다. 하드 드라이 구성에 따라 PC당 약 1GB/s의 속도로 계측 데이터를 레코딩할 브 구성에 따라 다르지만, PC당 대략 1 GB/s의 계측 데이터를 기
수 있다. 록할 수 있다. | 2017-09 V1.0
6/8 www.vector.com/contact 6/9 7/0 7/1 7/2 7/3 TECHNICAL BRIEFING
AUTOSAR, Equipped for Everything? ৮߷ೠо ۽ 3"6504"
ؘ Ѿੋחରਊ ࠙ঠܳ ҳ୷ೞҊ ߊदఃزࢶ חউ "6504"3ز ֙ դ ࣻ೯ೞҊ নೠ সٜ ࢤೠ ࣗ ۽ਸ ബҗਵמҟߧਤೠ ӝ חೡਸ ೧৳"6504"3 ఀ ࢤࢿਸ ೱ࢚दఃӝ ਤ೧ࢲ݅ חҊ Ӓ۞ա ਗೞغ ӝ߈ חਝয ਃٜࣗਸ ాೞ ҳ୷ೡ ਃо ݏ ળী۽ࣁझܳ ࢜۽߈ੋ ѐߊ ח
ࢎন ૐо ࣽೞ ঋױ חӒܿ ţ (BSUOFSо ઁदೠ )ZQF$ZDMF Ӓܿ ţ "6504"3 ӖȈޖ ग݂ )FMNVU4DIFMMJOH ࢎ 7FDUPS*OGPSNBUJL
࣌ܖܳ ా೧ ؊ ࠺ਊ ബҗੋ ࣛ ػ ਵݴ ب؛ݽ ۿҊ ߑߨغਸ ѐߊೞҊ ఠಕझо ળചର ۽ӝ߈ਵ 3ܳ"6504" ۽ೠ ഝਊೞӝ ਤ ਸ ҳഅೡ ࣻ ѱ ػ৬ ҙ۲ػ সѢ ݽٚ সо ࢚ೠ ҙबਸ оҊ "6504"3 ਸ ୭ ӝࠄ ࣗਝ $6ೞ٘ਝয ҕәসٜ& ח ҅ ܳف3 ҳࢿਃࣗ ݽ"6504" חҊ ೧ࢲܰفଵೞӝ ਤ೧ ࢲز ળച ֢۱ী ߡ ਗ दझమ ѐߊসۄ٘ ҳഅ೧ঠ݅ ೠ য ҕәসٜ ۽١ೞݶࢲ ୡӝ ݒ ֫ ਵ ળ۽ରਊ ࢜زஹೊఠ ӝ߈ ۽ୡହӝ ݃ ೠ ࠂੋ ਗ दझమ ౠ ࠗಿী ೠ ழ ٜژ ӝ ܲٮ Ӓী Ҋغ ҙबਸ ߉ѱ ے ҙܻա ূ חदী ؍ٜਸ ࢎਊೞ ࠙স ਸ ы ҕәসٜ ۽ળ ࢜ ۄٮ दр թী Ӓܿ ਤٜਸ ѱ ػױ מ١җ э пп ӝ झ࣌ ઁয ׳ ର 0&.সٜ ࠂੋ ഄनਸزର 0&. সٜ пп ز חࣽೞҊ ࠺ җѢীױ ӝসٜ ؊ Ҋغ ѱט ೠژ ࣻ חਤ೧ ѐ߹ੋ &$6ܳ ѐߊ೮۠ &$6 ࣻ೯ ܳޖؘ ਃೠ স ח ࢿ೧ ҃੬۱ਸ ֫ ࢿೠ ۽Ӓܿ &$6ਊ ળ ӏѺਸ ఫझ ࣌ਸ ਗೞӝ दೠܖܲ &$6ٜҗ ৈ۞ ѐ ઁযਊ ഥࢶٜਸ ా ਊ ബҗੋ ࣛ ҕәসী ೞਸ ઼Ӓ ೡ ࣻ ۠ ߑधਸ ా೧ ҃੬সٜ ۾ب߬ ࣗ ܳ ҳഅೞ ח"6504"3 ࠗ࠙ ҃ ܳ ٜݶ ಏझ ߸ઑ नഐ ؘחع೧ োѾ ҕәসٜਸ ਊ೧ חೞبಿ ഄनਸ ઁ Ҋ ੋधೞҊ ۞ա "6504"3ܳ ࢎਊೞݶ ߈ੋtରۄૐ ਝযמਊഥࢶ١ਸٜࣻӒ۞աӒӝ ਸੌ חܻ־ ୶ೠ नࣘೞѱ नӝࣿ ѐߊ ഌఖਸ ۽ೡ աਤ হ ۞ೠ ߬ ࣗਝ ਊ uदझమ ࢸ҅ܳ ߄ఔਵ݈ف ೠ ૐژ যਊ ഥࢶ ࣻ৬ ࠺ਊઁ ۄٮ оೣী दझమਸ ݺഛೞѱ ೠژ ਸ ࣻ ݄ ۽ӏѺਵ חೡ ࣻ ةઁ ਃҳࢎ೦ਸ ӝ҅о ౸ חݒ ਃೠ ਃࣗৈӝী חয ֙ חࢲ ࠁएېоೞӝ द೮ Ӓ ೞনೠ ҕә ҳઑച೧ ѐ߹ ਃٜࣗਸ ࢚ ࠗ࠙ ࢎਊೞמѪ о ח पઁ ࢿ೧ ҕਬೞ ਵݴ ظ֎ ৬ ాनҙܻ ࢲ࠺झо ನೣ חۄ POUSPMMFS "SFB /FUXPSL$ /"$ ೧מо بѪ ח ࣁझܳ ࢎਊ೧ ബਯਵ۽সٜ ࠁૐػ ب ۠ఋ ജ҃ ਊਸ ਤೠ ҕా ੋఠಕझ ۽షਸ ѐߊೞӝ द೮ ۽ਕ חੑೞӝ ਤ೧ࢲب ਸۿ ߑߨ۽۠ ਃҳࢎ೦ਸ ҳഅೡ ࣻ ܳ ా ۢ ࢜ ۽ ର 0&.সٜҗز ۽ ನೣػ ੌ߈ਵعন ରী ਊ ۽ష ֙ী ୭ୡ ߑߨ חী ࣘೠ ݽٚ ҕәসо ࢎਊೞݎٜ ঋҊ ഈ۱স ҕә ۽ ֢۱ਸ ୶оب߬ ೧ ߹ ٸ ജೡ ۽ ؘఠܳ ҕәসٜ "6504"3 ష &$6рী۽/"$ ਸ ࠺ೡ ਃо "6504"3ܳ ҳۿ ೠ ࠙ ਸ ৈ۞ ѐ &$6 ࣗਝযࠗఠ दೠ ߬ ࣗਝয р ੋఠಕझীࢲ ࣻળীמӝ ۽ ۞ೠ ֢۱ਵ ܳ ٜয न ݴ ژपद೧ঠ ೮ ۽সਸ ୶о ۄٮ ೮ী ۾بҮജೡ ࣻ ۽पदрਵ ীࢲࠗఠ Բળೞѱ҅ױ ୡӝ ח೧ അೞӝ ਤ೧ࢲמҊ ݆ সо ҙ স оغ ӏѺ ഛपೞѱ Ѩૐع ࠙दఆ ࣻ ѱ ۽ઁ ؘ ܲ ҕәস ী ખ ؊חౠ &$6ܳ ࢤೞ ۽ରਊਵ ظӓ بয ହࢿפѐߊ ূ ೞস ܻ ਊೡ ਃо ೧ ҅ডস חী ޙٸ ಿਸ ઁҕೞҊ ӝઁ ۲ ޙ חী҃ ח ҕәসо ଵৈೞ۽ٜ ա ࢜מ ಞ ӝ۽t,FZMFTT (Pu৬ э ࢜ ѱ ࢿݏ ӏѺਸ ഻ঁ ؊ ҮೞҊ ഋधী ח ܳ ా೧ &$6ೞ٘ਝয ೠژ Ҋ ೡ ࣻ ۄ୶ ߬ ࣗਝয ࢚ ೡ ੋ ࢶఖ חо ߊࢤೡ ҃ীઁޙ о ߊࢤ೮۠ઁ ޛߓ উա ো࠺ ೱ࢚ ١೮ਵݴ Ѣ ী ࠺೧ۿߑߨ ؍ର 0&.স ߬ ࣗਝয ೧ঠ ೠӝઓী ࢎਊೞزৈ &$6ҕәসٜ নೠ ח3"6504" ب࢚ೠ оੋ ઑ ߂ दী ൨ਸ ॔ইঠ ೮ ֙ դ Ә ب١ ࠙ঠী ҙܻ ೧ࢲ Ө җ ࣻ೯ সী ޖਬо ٜਸ ਤೠ ҕాػ ࣗਝয ۖಬਸ ࢎਊ গܻா࣌ ࣗਝয ߑߨ স ח ৈӝী ؘחର 0&. ֫ ҙबਸ ߉Ҋ زtп &$6 ೞա ۞ೠ ࢚ടਸ ѐࢶೞӝ ਤ೧ بӒ۞ա ۞ೠ Ӕߑध द স҅ ߈ חӒ ೡࣻ ా ߂ ઙद Ҋҗ ജਸ ਃҳೠ ޖ۠ &$6ٜ সٜҗ ҕәসٜ ֙ "6504"3 ৈ ѐ ӝসٜ ݆ࣻ प u߆ী ܻೡ ࣻ হਵݴמ ӝ ࢚ࣻ ؘחغ ࣁझী ߸ചܳ оઉয়ѱ۽ࠗఠ ח"6504"3 ࠛҳೞҊ ب Ӓ Ӓۢী ؘחী ଵৈ೧ ળਸ ѐߊೞҊ ܛ "65PNPUJWF0QFO4ZTUFN"3DIJUFDUVSF ࢤ೮ೠ ઁпӝ ܲ ҕәসо ѐߊ ۞ೠ ߸ചо ൨ٜ ࣻ ח ౠ ଵৈ সী݆ ח୶ ۞ೠ ࠙সীݏ ୡਸ ۽ࣁझী ۽١ ߈ੋ ѐߊ ਸ ࣻ೯ೞӝ ਤ೧ ৈ۞ ઁઑসо ࢤ ஶࣗदষਸ ହࢸ೮ ஶࣗदষ ળചܳ ࢎী "6504"3 ֎ ߣ૩ ߡמо ӝ ജӝী যٜ۠ חചػ ӝসٜҗ ҅ডਸ ೡ ࣻ അ স҅ޙ೧ ഈ۱সٜ р ੋ ࠙ঠী חࢲ ଵৈೞۄٮ അ ࢤ Ҋ пӝ ܲ ೮"6504"3ܳ ਊೠ ର بী ా೧ ঌҊ્ܻਸ ࣻೞ ঋҊٸ ೠ ৈ۞ ѐ &$6ܳ ࢎਊೡ ੌ ਸ ର 0&. সٜز ݆ Ҋ ਵݴغਵ ع ઑসٜ &$6ী ాदఆ ࣻ ѱઁ חпп &$6ܳ ઑೞҊ ܳ द ాೞ ח
NOV . DEC 2014 105
104 www.autoelectronics.co.kr
7/4 7/5 TECHNICAL BRIEFING
엔진 제어기(EMS)를 위한 AUTOSAR Complex Device Driver (CDD) 개발
ࣁझ"6504"3ܳ ਊೠ ࣗਝয ѐߊ۽Ӓܿ ţ ࠁಞ Case Study FAW
고객정보 단일 라이브러리에 액세스하며, 이를 DaVinci Configurator Pro를 “First Automotive Works”라고도 하는 FAW 그룹은 창춘(Chang- 통해 특정 엔진 제어기에 적합하게 설정. chun)에 본사를 둔 중국 최대의 디젤 엔진, 승용차, 중/대형 버스 > AUTOSAR 사양을 준수한 프로세스와 인터페이스: 엔진 제어 알 및 트럭 제조업체이다. FAW는 연간 250만 대의 차량을 생산하며, 고리즘이 Matlab 및 Simulink를 통해 개발되며 AUTOSAR 소프트
t13&&WJTJPOuۖಬ AUTOSAR를 적용한 중국 최초의 OEM 중 하나이다. 웨어 컴포넌트(SWC)로 구현된다. 이 알고리즘은 RTE를 통해ో חӒܿ ţ ݽٚ সਸ ܻೞ AUTOSAR 베이직 소프트웨어 및 엔진별 드라이버에 접속한다. 기술적 과제 AUTOSAR CDD(Complex Device Driver)를 이용한 엔진 제어 Ҋغ۠ ోী ਃ ળ ੌର ࣻ೯ সҗ ೣԋ ѐߊפѪ ই חਸ ઑࢿೞ ࣼೠ ࣻળী ݎ স৬ ೣԋ ҕә݆ חജӝী 기용 드라이버 라이브러리 개발 ળ FAW는 차세대 엔진 제어기를 개발하는 중이며, 여기에 AUTOSAR ك সী ӝ߈ਸ ޖѐߊਸ ਤೠ ֢ ܳ ా೧ प ۾ࣻળ ֫ਸࣻ מࢿ חغҳ חؘ ࢚ೠ ֢۱ਸ ӝৈঠ ೠৈӝীח 베이직 소프트웨어를 기반으로 하는 개발 프로세스를 적용하고 ب दী Ҋغ оਊࢿҗ ࢿ ਸ नࣘೞѱ ೡ ࣻ ѱ ݴغਃҳ ۽࢚ೠ ࣻળਵ ب ۱ ظटೞѱ োѾו ݎҕәܲٮ ਤ ݶ 있다. 이 소프트웨어는 가솔린 엔진과 디젤 엔진을 모두 제어할ױ ঠ ೠ୭Ӕ "6504"3ࢎন ࡅܰѱ दೡ ࣻ ѱ ػظࠁ ببӝ ࣼױ ъೠ ೱ۱ਸ о ࣻ ݅ٸ ਸ 수 있는 단일 플랫폼으로 구현될 예정이다. AUTOSAR는 엔진 제 ೞ ۽݆ࣻ ୭ୡ ࣻ೯ স द ળਸ ӝ߈ਵ ীޙٸ ӝع࠙ࢳ উࢿ ࢚ ೱ࢚ ܨपदೠ য় ۞لա ࢲبੋ ߸ച द 어기에 적합한 드라이버를 정의하지 않기 때문에 FAW는 자사의 աী ୶о সਸ ೧ ۞ೠ द AUTOSAR 드라이버 라이브러리를 확장하려 한다. 또한 필요한 ۽ীࢲ ҃ਸ ഝਊೡ ࣻ ં۽ ন ࢲې ଵৈসী ࠗ ؼ ࣻ Ӓ݆ ഝਊೡ ળਸ ࣻ೧ঠ ೠ 센서 및 엑추에이터를 툴 키트에서 선택하고, 범용 툴 체인을 통 بో מনҗী ࢚ೠ Ҋࢿ ীࢲ ӝসٜ "6504"3о ডࣘೠ ਵݴ҅ױ . 해 이를 원하는 수량 및 유형으로 구성할 수 있기를 원한다ع ೞҊ ࠺ਊ݅ ୶о ࣻ ѱޅ ఀ ࢿҗܳ ઁҕೞ݅ פt13&&WJTJPOuਸٜࣻ Ѫ ই۽՜ ࣻ Ӓ۞ա ݽٚ ߸ച ੌ۹ו ೞҊ Ҋ 솔루션 ରਊ 벡터의 기존 AUTOSAR 툴 체인을 이용한 엔진별 드라이버 구성زউ ز ֙ ࣻभ חಿ "6504"3ઁ&& ܲٮ WJTJPO "6504"3ী&&13 بхuݎ۞ೠtप Ӓܿ ࣁझীࢲۢ۽ ਸ ো 및 코드 생성ۿೠ ѐߊ ۖಬ ࠙ঠীࢲ ࢎਊೠ ѐߊ ߑߨ ࣁझ ߈ী۽uо ѐߊ ۄٮ t࢚ടী۽ଵҊ ֈѹঠ ೠӒ۞ ഛ݀ 벡터는 CDD(Complex Device Drivers)라고 하는 엔진별 센서 및 ח ળചदఅ Ѫ "6504"3 ಣ ܳ ా೧ &&ইఃఫ ࢸ҅ Ӓܿ Ѫਸ ח߸ചೞ ۽ೠ ೠ नࣘೞҊ ҅ਵמ 엑추에이터 제어용 드라이버를 구현했다. 드라이버를 구성하기 ରनࣁ ۽Ҋ ੑૐػ ߑߨਸ ӝ߈ਵغ ా ۽ో ਸ ೞաמࢲച ӝޙ ୭ച ࣻળ о ب೧ঠ ೠଵৈসٜ ࢿࣼ ۽ݾ 위해 DaVinci Configurator Kit를 사용하여 관련된 BSWMD(Basic ೠ ୭न ࣗਝয ӝמѐߊ о מӝ ਸ ਊೠ ର ೡ ࣻ ۖಬ ੋఠಕझ ۿ3ߑߨ"6504" חغী ઝ Software Module Description)파일을 생성했다. 또한 DaVinci -ղࠁղҊ оઉৢ ࣻ ࣿਸ ਊೞҊ ۞ೠ ߊ ؊ Configurator Kit로 코드 생성기도 제작했다. DaVinci Configu ۽ѐߊ ࢎস ۠ ֢۱ਸ ٜੌ݅ ೠ оо ܳ "6504"3ನݘਵ ೧ ࠂࢿҗ উী rator Pro에서는 BSWMD 파일을 읽고 연관된 코드 생성기를 연 ҅ীزചػ ҳز ਗೞӝ ۽ਸ ഛपೞѱ ࠁৈળ &&ѐߊ ࠙ঠܳ ઙਵ ࠛ 결하며, 이를 통해 엔진 제어기 및 AUTOSAR 베이직 소프트웨어 ب ӝળਸ ਃҳೠӒۢী۽ҙೠ ࢜ חܲ ਃٜࣗ ਃೞ ৈӝী חਤ೧ࢲ ҅ױtࢤࢿ ࢿࣼ חৈӝࢲ ݾ 에 대해 드라이버를 설정할 수 있게 된다. উ ػ חࢲظ ળച о ݾо Ӓ ҳೞҊ uী оә नࣘೞѱ ਃҳ ઑѤ ࠙ࢳীࢲ ഈস ۖಬ ઁҕ QMBUFBVPGQSPEVDUJWJUZ
ߧਤ 장점 חਸ ֈযࢲױ ١ ನೣػ ਫ਼ੋ ҙܻ 7BSJBOU ؘী ܻҊ ܻ߬ חࢿೞ׳ Ѫܳ ח೧ঠ ೠ׳ب ӝࣿ ӝઓ ࢎসٜ FAW에서 확장할 수 있는 도메인 별 드라이버 라이브러리 ח١ೞ ۽"6504"3ܳ ನೣೠ пп ળ ৬ ࢜ Ӓܿ ؼ Ѫب ъ۱ೠ ోٜ ח Ѫ > 모든 베이직 소프트웨어를 단일 툴로 설정 및 생성: AUTOSAR חইյ Ѫੋܳ ഛೞѱ ҙೞށ ਤਸ ղನೞҊ ਸ חਸ Ѧ ࣻ زઁ ഄनী 표준 모듈과 엔진 제어를 위한 특수 드라이버가 모두 DaVinci ର ઁઑসٜز ӝ۽ղ ؊֔u ҃ܳ ࠁݶ ਃೞ࢜ tର۽ ੌ۹ ో Configurator Pro를 통해 설정된다. ѐߊ ో "6504"3ӏѺҗ ߽೯ ѐߊ೧ पਊੋ Ӕߑधਸ ਊ೧ ۠ ਤਸ ೖ ա ҳӖ ਯ೯ରܳ ࠁݶ ۞ೠ > DaVinci Configurator Kit를 통해 드라이버 라이브러리를 확장 ୭ୡী ѐߊػ ో ೦࢚ ࢿ ೡࣻ റܳ ನೡ ࣻ AE 또는 수정 가능. (예: 새로운 센서나 엑추에이터를 도입하는 경 ঠ ೠӒ Ѿҗ 우) > 중앙 관리 부서에서 라이브러리를 유지 관리 및 확장하도록 106 www.autoelectronics.co.kr 하여 관리 시간 절감. 서로 다른 여러 차량 프로젝트에서 중앙의
7/66/6 7/76/7 7/7 D&D Feature 077 076
리돼 사용됐다. 이것이 AUTOSAR Adaptive Platform 이 등장하게 된 배경이다. 즉 미래 자동차 기능을 위해 필요한 고성능 HW 지원, 다 양한 오디오 및 비디오 드라이버 지원, 외 부 인터페이스 지원과 함께 차량 진단과 차 량 통신 네트워크 및 보안의 요구까지 동 시에 만족시켜야 하는 시대의 요구에 따라 AUTOSAR Adaptive Platform이라는 새로운 패러다임의 서막이 열리고 있다. AUTOSAR Adaptive Platform은 C++ 객체지향 언어로 코딩돼 있다는 점이 아 마도 가장 먼저 눈에 띄는 특징이자, 기존 AUTOSAR ADAPTIVE PLATFORM FOR NEXT GENERATION ECU Classic Platform과의 차이점 일 것이다. 그 러나 코딩 언어뿐만 아니라 다양한 측면에 그림 1 | AUTOSAR Adaptive Platform의 아키텍처 서 Adaptive Platform은 Classic Platform과 차세대 ECU를 위한 AUTOSAR Adaptive Platform 다른 점이 있다. 등장 배경, 특징 및 전망
ରоਸө ઁযӝܳѐߊೣী 적응성과 유연성을 지향ڃযחਸө "6504"3$MBTTJD1MBUGPSNҗعEBQUJWF1MBUGPSN৵ѐߊ"3"6504" ೠҗীޙޙחغೞݶࢶ߉ѱۄۖಬਸࢶఖ೧ঠೡө "6504"3"EBQUJWF1MBUGPSNڃযয
೧ಝࠄ AUTOSAR Classic Platform은 다양한ীݎౠ߂ EBQUJWF1MBUGPSN١ߓ҃"3"6504" 차종과 플랫폼 베리언트(Variant) 대응에 적 글│ 매니저, 임베디드 소프트웨어 사업부, 조 재 윤 Vector Korea IT 합하다. 이러한 확장성은 제어기를 구성하는 기능별 SW 모듈이 모두 표준화된 SW 스택 을 통해 구성되기 때문이다. 반면 AUTOSAR 그림 2 | SOME/IP를 통한 Proxy-Skeleton 서비스 지향 통신 Adaptive Platform은 확장성보다는 적응성 과 유연성에 방점을 찍고 있다. “Adaptive” 006년 AUTOSAR 2.0 배포 차량 분야에서 전례 없는 IT 기술융합이 활 이러한 리눅스 환경은 AUTOSAR 가 시사하는 바가 바로 이 적응성과 유연성 Adaptive Platform의 Functional Cluster 구 Service-Oriented Communication(SOC)에 를 시작으로 10여 년이 넘도 발하게 일어나고 있다. 특히 리눅스를 차량 Classic Platform이 가진 한계점을 보완하 이다. 이를 위해 Adaptive Platform은 8개의 현 자유도가 훨씬 높다. 그 기반을 두고 있다. 이는 서비스를 제공하 록 Classic Platform은 2017 에 적용하는 사례가 늘고 있는 것은 리눅스 며 많은 장점을 갖추고는 있지만, 일반적 2 Functional Cluster와 3개의 기본 서비스를 는 서버인 Skeleton과 서비스를 소비하는 년 10월 현재 AUTOSAR 4.3까지 진화하면 환경이 다음과 같은 편의성을 제공하기 때 인 차량 개발환경에 필요한 진단기능이나 제공한다(그림 1). 클라이언트인 Proxy 사이에 필요한 서비스 서 바디, 섀시, 전자, ADAS 등 다양한 영역 문이다. CAN 통신 같은 차량 네트워크를 지원하는 3개의 기본 서비스는 Middleware 가 Service Discovery와 SOME/IP(Scalable 에 널리 사용되고 있다. 특히, ISO 26262 기 우선 비디오 코덱, 스트리밍, USB, SW를 갖추지 못한 태생적 한계를 지니고 SOME/IP에 기초한 성격의 ara::com(AUTOSAR Runtime for service-Oriented MiddlewarE over IP)를 능 안정성이 화두가 되면서 AUTOSAR에 대 SD-Card, LTE, Wi-Fi, GPS 등을 위한 다양 있다. 이 때문에 리눅스 OS가 실행되는 프 서비스 지향 통신 Adaptive Applications)을 통해 호출할 수 통해 Dynamic 하게 연결하는 통신 방법이 한 관심이 더욱 커져왔다. 한 드라이버를 활용해 인포테인먼트, V2X와 로세서와 함께 차량 기능을 실행하기 위한 있고, 8개의 Functional Cluster는 각 API를 AUTOSAR Adaptive Platform과 다(그림 2). 한편, 자동차 업계에는 전기차와 같은 애플리케이션을 보다 쉽게 구현할 수 AUTOSAR OS가 실행되는 별도의 프로세서 통해 다른 애플리케이션과 통신한다. 눈여겨 Classic Platform의 가장 큰 차이점은 통 SOME/IP는 AUTOSAR Adaptive 자율주행이라는 새로운 패러다임이 형 있다. 또한 멀티미디어 라이브러리와 이미지 가 공존하여 하나의 제어기가 구성되거나, 볼 부분은 오직 API 구현에 대한 정의만 돼 신 방식에 있다. 대부분의 기존 Classic Platform에서 중요한 의미가 있다. 이는 성되면서 IVI(In-Vehicle-Infotainment), 프로세싱 라이브러리 등을 재사용하고 머신 멀티코어 프로세서가 탑재된 제어기의 경 있다는 사실인데, 이 때문에 기존 Classic Platform은 전통적인 Signal-Oriented 통 Adaptive Platform의 궁극적인 지향점인 차 ADAS(Advanced Driver Assistance 러닝, 목표물 인지, 센서 퓨전 등의 연산을 우 리눅스 OS와 일반 차량 기능을 관장하는 Platform을 구성하는 BSW 스택 구현에 비해 신에 기초하지만, Adaptive Platform은 량 애플리케이션 서버 구축과 운용에 백본 System), V2X(Vehicle-to-X) 등을 필두로 위한 ADAS용 고성능 HW 사용도 가능하다. AUTOSAR OS가 실행되는 코어가 각각 분
7/8 7/9 078 D&D Feature 079
(back-bone)이 되기 때문이다. 미래 차량 는 사실이다. 다시 말해, 운영체제는 멀티- 목적지까지 자동주행(Auto Pilot) 애플리 Inc.)에서도 실습 예제를 포함한 2일 교육과 은 스마트 센서와 스마트 액추에이터를 탑 프로세스를 지원하지만 애플리케이션은 싱 케이션을 다운받아 사용할 수도 있을 것이 정과 Linux VM Rapid Prototype 빌드를 통 재하게 되고, 이는 모두 Ethernet으로 연결 글-프로세스만을 지원한다. 다. 이러한 Adaptive Platform용 애플리케 해 프로젝트를 시작한 이후, 현재 성공적으 되어 궁극적으로 차량 애플리케이션 서버 이션은 차량 애플리케이션 서버에서 관련 로 HW 샘플 검증 지원까지 완료하고 2019 에 의해 모니터링되고 제어될 수 있다. 차량 된 스마트센서와 스마트 액추에이터를 제 년도 양산을 목표로 기술지원을 하고 있다. 애플리케이션 서버는 AUTOSAR Adaptive 유동적 소프트웨어의 전개와 어하며 운전자에게 필요한 서비스를 제공 Platform이 탑재된 시스템으로서 SOME/IP 그림 3 | 차량 애플리케이션 서버와 앱스토어 상상도 차량 애플리케이션 서버 하게 될 것으로 전망된다. 를 통해 스마트 센서와 스마트 액추에이터 차세대 ECU를 위한 새로운 를 차량 애플리케이션의 용도에 따라 자유 AUTOSAR Adaptive Platform에서 플랫폼 시대 개막 롭게 모니터링하고 제어할 수 있다. 열어주는 차량 애플리케이션 SW 개발이 가 Platform에 사용됐던 HW에 비해 연산처리 만 볼 수 있는 가장 획기적인 변화는 유동 LINUX Virtual Machine에 의한 이는 지난 10여 년간 지속된 차량 전 능해진다. 능력이 월등히 뛰어난 HW 지원이 가능하고, 적 SW 전개에 있다고 해도 과언이 아닐 것 Rapid Prototype 그러면 앞으로 AUTOSAR Classic 장 아키텍처와는 사뭇 다른 형태이다. 지금 MMU(Memory Management Unit) 및 멀티 이다. 앞서 SOC 설명을 하면서 차량 애플리 Platform 대신 AUTOSAR Adaptive Platform 까지는 하나의 제어기에 연결된 센서와 액 코어 프로세스 지원이 가능하다. 케이션 서버를 통해 새로운 기능의 애플리 현재 벡터에서 제공하는 Evaluation 을 적용해야 할까? 많은 개발자 또는 관리 추에이터는 오직 그 제어기의 기능 수행 POSIX 기반 운영체제 POSIX 운영체제 아래서 애플리케 케이션 SW를 설치할 수 있음을 잠시 언급한 패키지에는 LINUX VM(Virtual Machine) 자들이 가질 수 있는 질문이다. 결론부터 에만 할당돼 사용됐다. 그러나 Adaptive 선택 필요 이션 SW의 실행은 곧 하나의 POSIX 프로 바 있다. 미뤄 짐작할 수 있듯이, AUTOSAR 을 빌드할 수 있는 YOCTO 실행 파일과 컴 말하면, AUTOSAR Adaptive Platform과 Platform에서는 센서와 액추에이터가 여러 세스 생성으로 간주된다. 이때, 애플리케 Adaptive Platform에서는 애플리케이션 서 파일러, 소프트웨어 Linking에 필요한 제반 Classic Platform은 향후 공존하게 될 것이 차량 애플리케이션 SW에 사용될 수 있다. AUTOSAR Classic Platform은 기본적 이션은 또 다른 프로세스를 생성할 수 없 버를 이용해 기존에 설치가 됐던 SW의 업그 내용, Eclipse Mars.2(Yocto SDK plugin) 고 서로 다른 영역에서 차량 제어기를 구성 마치 스마트폰의 HW 자원이 특정 애플리케 으로 확장성(Scalability)에 따라 SC1~SC4 는 PSE51(POSIX System Environment 레이드는 물론, 새로운 SW의 설치도 가능하 와 같은 유용한 플러그인이 포함돼 있다. 하게 될 것으로 예상된다. 따라서 프로젝트 이션에만 사용되는 것이 아니라, 범용으로 까지 운영체제를 제공한다. 하지만 Adaptive Profile)을 사용한다. PSE51은 단일 프로세 다. 물론, 정비 센터가 아닌 운전자가 차량을 따라서 실제 타깃 HW가 없이도 VM만으로 에 맞은 AUTOSAR 플랫폼을 선택하는 것 모든 애플리케이션 SW에 사용되는 것과 같 Platform은 기본으로 제공하는 운영체제가 스를 위한 멀티스레드(Multi-thread) 서브셋 운용하면서 말이다. Rapid Prototype를 빌드할 수 있다. 리눅 이 중요하다. 다고 할 수 있다. 예를 들면, 후진 시 후방을 없기 때문에 사용자가 운영체제를 선택해야 (subset)으로, 287개의 API로 구성돼 있다. 이는 기존 차량 SW 배포 및 유지보 스에 필요한 커널과 라이브러리 등이 Intel 일반적으로 AUTOSAR Classic 보여주는 후방카메라를 통해 영상정보를 입 하는데, POSIX(Portable Operating System 여기서 한 가지 주의할 점이 있다. 애플리케 수 형태와는 매우 다른 혁명적 시도임이 틀 xH6 시스템에 맞추어 컴파일 되어 있고, Platform은 비교적 실시간성이 중요시되는 력받아 모션/제스처를 인식하고, 트렁크를 Interface) 기반 운영체제를 Adaptive 이션 SW만 PSE51을 사용한다는 것이지, 운 림없다. 지금까지는 차량에 탑재된 SW를 라이브러리는 ARM 계열에서 사용하는 것 작은 임베디드 시스템에 사용돼 왔다. 바디, 제어하는 액추에이터를 제어하여 트렁크를 Platform에 사용할 수 있다. 이로써 Classic 영체제가 PSE51을 사용한다는 것은 아니라 EOL(End of Line)에서 제어기에 프로그램된 과 동일하다. 섀시, 및 전장 영역에 폭넓게 사용되고 있으 이후, 사용자(운전자)가 임의로 변경 및 수정 Linux VM에 의한 Rapid Prototype 며, 이는 향후에도 지속될 것으로 보인다. 하는 것이 원칙적으로 용인되지 않았다. 음성 은 프로젝트를 시작하는 애플리케이션 개발 AUTOSAR Adaptive Platform은 차 적으로 제어기 매핑을 새로 하는 등의 행태가 자들에게 큰 도움이 된다. 실제 HW가 없는 량 애플리케이션 서버, ADAS, V2X 및 IVI 간혹 있으나, 제조사가 원천적으로 운전자에 상태에서도 VM만으로도 기본적인 테스트 와 같은 새로운 유스케이스(Use case)를 의한 순정 SW 변경을 허락하지 않기 때문이 를 수행할 수 있기 때문이다. 이러한 VM의 중심으로 적용되기 시작해 점차 미래 차량 다. 그러나 Adaptive Platform이 지향하는 바 장점을 십분 활용해 벡터 인포마틱(Vector 기능을 구현하는 데 확대 적용될 것으로 보 는 매우 다르다. 운전자 편의를 위한 새로운 Informatik GmbH)은 현재 2019년 SOP를 목 인다. 여기에는 고성능 HW 지원, 멀티미디 애플리케이션 SW의 설치는 물론, 이론적으 표로 한 Adaptive Platform 프로젝트들을 이 어와 차량 통신 및 네트워크의 융합, 차량 로는 차량 애플리케이션 서버에서 제어기의 미 2017년도부터 시작할 수 있었다. 벡터 인 과 클라우드와의 연결성 등이 유기적으로 SW까지도 업그레이드할 수 있게 된다. 포마틱은 AUTOSAR Adaptive Platform 개 작용하면서 Adaptive Platform 개발을 견
이렇게 되면 스마트폰 앱스토어와 발에 직접 참여하며 사양을 함께 정의해 나 인할 것으로 전망된다. AE ▶ C 언어 ▶ C++ 객체지향 언어 유사한 새로운 비즈니스 모델이 생겨날 아가고 있고, Adaptive Platform을 자체적 ▶ 모든 SW Stack이 사전에 정의된 표준에 따라 구현됨 ▶ API만 정의돼 있어 코딩의 자유도 증가 수 있다(그림 3). 예를 들면, 장거리 여행 으로 구현한 Adaptive MICROSAR(벡터의 ▶ 타깃 HW에 배치된 후 변하지 않음 ▶ 타깃 HW에 배치된 후에도 업데이트 가능 ▶ Static Signal-Based(정적 신호 기반) 통신 ▶ Dynamic Service-oriented (동적 서비스 지향) 통신 을 위해 적응형순항제어(Adaptive Cruise AUTOSAR Adaptive Platform 솔루션) 제 참고 문헌 ▶ 기존 차량 도메인에 계속 사용 ▶ 새로운 유스케이스(Use case) 위주로 도입 Control, ACC) 애플리케이션을 다운받아 품을 2018년 2분기 출시 목표로 활발히 개 [1] Guideline and Requirements Adaptive AUTOSAR for Application Developers V1.4 그림 4 | AUTOSAR Classic & Adaptive 비교 일정 기간 사용하거나, 가까운 주유소 및 발하고 있다. 벡터코리아(Vector Korea IT, (2017-05-19)
7/10 7/11 급한 요구 사항을 제대로 처리해 왔다. XCP는 버스 시스템을 통 생성된다. 또한 RTE 생성기는 측정에 필요한 변경 사항을 RTE 코 해 변수를 읽고 쓰기 위한 메커니즘을 제공한다. DAQ(Data Ac- 드에 삽입한다. quisition) 목록을 기반으로 여러 개의 변수를 공통 타임 스탬프 RTE 아래에 있는 모듈에서도 데이터 흐름을 추적하기 위해(그림 를 사용해 일관성 있게 측정할 수 있다. 동적 DAQ 목록을 사용 2), 벡터는 기본 소프트웨어에서 파라미터를 측정하기 위한 A2L 하면 측정시 판독도 가능하도록 데이터 기록을 재구성할 수 있는 생성기도 제공하고 있다. A2L 파일도 구성을 토대로 생성된다. 것은 물론, 통신 버스의 가용 대역폭을 최적으로 활용할 수 있다. 측정 개체는 좀 더 쉽게 찾기 위해 A2L 파일 내 디렉터리 구조에 일반적으로 하나 이상의 A2L 파일이 XCP 측정과 함께 사용된다. 계층식으로 저장된다. A2L 파일에는 ECU 내 관련 측정 개체에 대한 정보를 가지고 있 다. 이러한 각각의 개체에 메모리 주소, 데이터 유형, 기호 해석 측정 데이터 획득 및 변환 규칙과 같은 정보는 필수적이다. XCP 마스터(예: 분석 테스트 엔지니어는 오류의 원인이 되는 모듈을 종종 미리 정해놓 툴)와 슬레이브(ECU) 간 통신의 파라미터에 대한 설명과 함께 고 오류 패턴을 기준으로 분석용 데이터를 정의할 수 있다. 우선, A2L 파일은 측정 개체에 대해 계층식으로 표현된 구조 정보도 포 XCP 마스터는 XCP 슬레이브에 대한 연결을 설정한다. 연결이 설 함하고 있다. XCP는 내부 ECU 변수를 다양한 방법으로 액세스하 정된 후에는 ECU로부터 첫 번째 데이터를 읽어올 수 있다. 일반 면서도 A2L 파일을 통해 편리하게 구성할 수 있는 강력한 디버 적으로 버전 번호, 버전 ID 등의 정보가 여기에 포함된다. 테스트 깅용 프로토콜이다. 엔지니어는 이 정보를 토대로 ECU 버전 레벨과 일치하는 A2L 파 XCP 프로토콜은 전용 BSW 모듈에 구현되어 있지만, 이 모듈은 일을 선택하고 데이터 측정을 시작한다. AUTOSAR 3.x 표준에는 정의되어 있지 않다. 대신 사용되는 버스 재현하기 어려운 오류의 경우, 측정을 실행하는 동안 데이터를 시스템(CAN, FlexRay, 이더넷 등)의 관련 AUTOSAR 통신 드라이 빠르게 분석하는 것이 불가능할 수도 있다. 이러한 경우 XCP 기 버에 연결되어 있다(그림 1). XCP 드라이버는 XCP와 나머지 모듈 능이 통합된 데이터 로거 또는 XCP 마스터를 포함한 소프트웨어 을 편리하게 구성할 수 있도록 기존 BSW 구성 체인에 균일하게 툴이 측정 값을 매개체에 장기간 저장해 둔다. 그리고나서 차후 통합되어 있다. 데이터 분석을 위해 벡터의 시뮬레이션, 분석 및 테스트 툴인 CANoe와 같은 XCP 마스터 툴을 사용한다. A2L 파일 생성 위에 언급된 추가 정보를 사용하여 A2L 파일을 생성하는 것은 쉬 측정 데이터 분석 운 일이 아니다. 이 작업을 완료하기 위해 테스트 엔지니어는 정 T사용 중인 통신 버스에 구애받지 않고 ECU를 테스트하려면 XCP로 AUTOSAR ECU 소프트웨어를 분석 의된 프로세스와 적절한 툴을 필요로 한다. AUTOSAR BSW의 경 XCP 마스터가 CAN, FlexRay, 이더넷 등 다양한 버스 시스템을 지 우 다양한 구성 옵션을 갖추고 있어 A2L 파일을 생성한 후에도 원해야 한다. 더구나 디버깅에서는 여러 ECU의 데이터를 동시에 AUTOSAR BSW 확장으로 디버깅을 편리하게 BSW 구성의 변경 사항을 A2L 파일에 적용하기가 편리하다. 측정하고 평가할 수 있어야 한다. 따라서 멀티 마스터도 가능한 네트워크 ECU 환경에서 디버깅을 할 때 디버거는 사용에 제한이 많으며, 특히 오류가 산발적으로 발생하거나 테스트 매개체에서 오 SWC 간의 데이터 흐름을 측정하는 데 필요한 A2L 파일은 벡터 분석 툴을 가지고 있으면 유리하다. 류가 발생되는 경우에는 더욱 그렇다. 그러한 경우에는 검증된 측정 및 보정 프로토콜인 XCP가 유용한 서비스를 제공한다. 아래에 (Vector)의 RTE 생성기를 사용해 생성할 수 있다(그림 2). 이렇게 Option AMD(AUTOSAR Monitoring and Debugging)는 여러 슬 는 XCP를 사용하여 AUTOSAR BSW(Basic Software) 및 SWC(Software Component)에서 프로세스를 모니터링하기 위한 방법이 하면 ECU 내부의, 그리고 ECU 간의 통신 및 측정을 모니터링할 레이브의 주소를 동적으로 지정하기 위해 XCP 마스터를 사용해 설명되어 있다. 단, 이러한 측정 목적을 위해서는 특정 기능을 BSW에 추가해야 하는데, 이는 분석 툴을 통해 효율적인 디버깅 및 평 수 있고 연결된 송신기/수신기 포트도 자극할 수 있다. A2L 파일 CANoe의 기능을 확장한다. 사용자는 측정이 실행 중인 동안 가를 가능하게 한다. 은 DaVinci Developer를 사용해 만들어지는 RTE 구성을 토대로 XCP 구성을 변경할 수 있다. Option AMD를 사용하면 XCP를 통 해 측정한 변수에 대해 State Tracker(상태 추적기)(그림 3), 그래
현재 출시된 테스트툴 중 다수는 잔여 버스 시뮬레이션을 사용해 디버깅 요구 사항 개별 ECU를 테스트하는 방식을 지원한다. 사용자는 이러한 툴을 오류의 원인을 찾기 위해서는 일반적으로 다양한 소프트웨어의 사용함으로써 초기 단계에 ECU 네트워크에 상관없이 필수 기능 변수 값을 확인한다. 트리거 지점과 관련해 여러 소프트웨어 모 을 검증할 수 있다. 따라서 소프트웨어 개발의 초기 단계에 매우 듈의 변수를 동시에 확인하는 것도 중요하다. 그러면 사용자가 높은 품질을 얻을 수 있다. 하지만 ECU가 테스트 벤치 또는 테스 모듈 간의 일관성을 모니터링할 수 있다. 이에 대한 대표적인 예 트 매개체에 설치되어 있거나 기능이 네트워크를 통해 여러 ECU 로는 AUTOSAR의 “Bus State Managers”와 같은 “관리자 모듈 로 배포될 때에는 테스트 옵션이 대폭 줄어든다. 이렇게 되면 발 (Manager Modules)”과 “ComM(Communication Manager)”을 생하는 오류에 대해 원인을 한정하는 것이 쉽지 않은데, 그 이유 들 수 있다. 마찬가지로, 테스트 엔지니어는 어떤 애플리케이션 는 다음과 같다: 의 요청으로 인해 ECU가 측정 상태로 전환되었는지를 확인해야 > ECU가 액세스하기 어려운 방식으로 설치되어 있다. 한다. 모듈 간의 경계를 넘어 원인이 되는 일련의 동작을 관찰하 > 디버깅을 위한 터미널 연결이 불가능하다. 는 것도 중요하다. 예로 버스 레벨에서 애플리케이션 레벨로의 > 서로 다른 ECU 디버거들이 데이터를 균일하게 유지하지 신호 경로 추적 등과 같은 작업이 있다. 또한 분석시 오류 기록을 못한다. 재구성하기 위해 타임 스탬프가 필요하다. > 테스트 툴을 매개체 안에 넣을 수가 없다.
매개체에서 디버깅을 제한하는 위의 물리적 조건들 외에도 또 다 AUTOSAR 3.x 프로젝트에서의 XCP 그림 1: 벡터의 AUTOSAR BSW 른 한 가지 요인은 일부 오류가 산발적으로 발생한다는 점이다. AUTOSAR 3.x 표준은 원격 디버깅을 위한 메커니즘을 지정하지 인 MICROSAR는 XCP를 통해 이런 오류의 원인을 확인하기란 실험실 환경에서도 쉬운 일은 아 않는다. 하지만 지금까지 수년 동안 XCP는 매개체 개발에서 ECU ECU 데이터를 측정하기 위한 모듈을 포함하고 있다. 니다. 를 측정하고 보정하는데 효과적으로 사용되어 왔으며, 위에서 언
7/12 7/13
6/0 6/1 측정 데이터에 대한 고성능 액세스 트를 트리거하기 위해서는 ECU 코드를 수정해야 하는데, 폴 위에서 설명한 메커니즘은 AUTOSAR 버전에 관계없이 모든 ECU 링에서는 그럴 필요가 없다. 또한 XCP 이벤트는 개발 도중 애 에 대한 강력한 디버깅 툴을 제공한다. 개발자는 벡터의 CANoe 플리케이션 코드의 특정 지점에 미리 제공될 수 있다. 실행 및 CANape와 같은 검증된 XCP 툴을 사용해 ECU 내 프로세스를 시간에서의 짧은 오버헤드 외에도 XCP 코드는 수동적으로 매우 편리하게 추적하고 분석할 수 있다. ECU 실행 시간에 미치 작동한다는 이점이 있다. 측정을 위해 XCP 이벤트가 필요할 는 영향을 최소화하면서 최대 5MByte/s의 속도로 대량의 데이터 때는 XCP 마스터가 측정 도중에 활성화한다. XCP 이벤트의 를 측정하기 위해서는 측정 및 보정 하드웨어인 VX1000을 사용 또 다른 이점은 공통 타임 스탬프를 사용해 여러 데이터를 이 하는 것이 바람직하다(그림 4). 이 경우 디버그 인터페이스 JTAG 벤트 중심으로 출력할 수 있다는 것이다. 덕분에 개발자는 소 또는 NEXUS를 통해 ECU를 액세스할 수 있다. 프트웨어에서 특정 프로세스를 정밀 추적하고 변수가 서로 간에 일관된 상태로 유지되어 있는지를 확인할 수 있다. XCP 관련 추가 정보 XCP 이벤트를 사용하면 테스트 엔지니어가 통신 버스의 상 그림 2: ECU 구성을 XCP(Universal Measurement and Calibration Protocol)는 지 태에 관계없이 측정을 수행할 수 있다. 폴링의 경우에는 마스 토대로 A2L 파일 생성 금까지 수년 동안 매개체 개발 시 ECU를 측정 및 보정하는데 터로부터 측정 명령을 받아야 하므로 버스 통신이 절대적으 효과적으로 사용되어 왔다. XCP는 2003년에 ASAM(Associa- 로 필요하다. 하지만 이벤트를 사용할 때는 이 요구 사항이 tion for Standardization of Automation and Measuring Sys- 생략된다. 하지만 XCP 슬레이브는 XCP 마스터와의 통신이 tems)에서 표준화한 글로벌 표준이다. CCP(CAN Calibration 복원될 때까지 측정 데이터를 저장하는 버퍼를 제공해야 한 픽 및 데이터 분석 창도 사용할 수 있다. 또한 분석을 자동화시키 AUTOSAR 4.x 프로젝트에서의 디버깅 Protocol)는 CAN 버스로 제한되는 반면 XCP는 전송 레이어 다. ECU 내의 리소스가 극도로 제한되어 있기 때문에 지속적 기 위해 통합된 CAPL 프로그래밍 언어 혹은 Test Automation으 AUTOSAR 4.x 표준은 모듈 DBG(Debug) 및 DLT(Diagnostic Log 의 교환이 가능하다. XCP는 CAN, FlexRay, 이더넷, USB 등의 인 버퍼 저장은 당연히 불가능하다. 여기에서 두 가지 버퍼 로부터 XCP 변수에 액세스가 가능하다. and Trace)를 구현함으로써 소프트웨어에서 디버깅 옵션의 요구 버스를 지원하며 마스터/슬레이브 원칙을 기반으로 한다. 전략이 가능하다. 첫째, 꽉 찰 때까지 측정 값을 받아들이는 사항을 충족한다. 이 두 모듈은 XCP에서 제공하는 것과 유사한 XCP 마스터는 CTO(Command Transfer Object)를 사용함으 선형 버퍼(Linear Buffer)가 있다. 또 다른 버전으로는 가장 오 ECU로부터 얻은 측정 값은 측정 중에 바로 분석할 수 있다. XCP 메커니즘을 활용한다. DBG 모듈의 주 작업은 ECU 데이터를 읽 로써 버스를 통해 XCP 슬레이브로 명령을 보낸다. 그러면 래된 항목을 새 값으로 덮어쓰는 링 버퍼(Ring Buffer)가 있 마스터는 이러한 목적에 맞는 적절한 메커니즘을 제공해야 한다. 는 것이며, 이 데이터는 ECU 내에서 버퍼링되고 개발자가 추가 XCP 슬레이브가 DTO(Data Transfer Object)를 사용해 응답한 다. 이를 위해 CANoe에서는 State Tracker 창을 통해 트리거 조건( 로 평가할 수 있도록 PC로 전송된다. PC와의 통신은 전용 통신 다. XCP는 ECU 메모리에 값을 읽고 쓰는데 사용될 수 있다. XCP 이벤트를 통해 측정을 실행하기 전에 XCP 마스터에서 예: 특정 측정 값에 도달할 때 빠른 분석을 위해 창 컨텐츠를 정 프로토콜에 의해 이루어진다. XCP의 A2L 파일과 마찬가지로 XCP 마스터는 XCP 슬레이브로부터 측정 데이터를 주기적으 슬레이브 드라이버를 적절히 구성해야 하는데, 이 작업은 일 지)을 정의할 수 있고, CAPL 프로그램을 통해 측정 값에 대한 복 DBG 접근 방식에서도 측정할 데이터에 대한 설명이 생성된다. 로 요청하거나(폴링) 특정 이벤트가 발생할 때 데이터를 전송 련의 명령을 통해 이루어진다. 첫째, XCP 마스터가 XCP 슬레 잡한 평가도 수행할 수 있다. 이 설명은 측정할 모든 BSW 모듈의 모듈 설명을 토대로 생성된 받도록 한다(XCP 이벤트). 어떤 메커니즘이 사용되는지는 여 이브와의 연결을 설정한 후에 필요한 구성을 전송한다. 하지 저장된 측정 값을 상세히 평가하는 경우, 개발자는 원시 값보다 다. 러가지 요인에 의해 결정된다. XCP 이벤트를 통한 측정은 폴 만 ECU 초기화 직후에 측정을 시작해야 하는 경우에는 측정 값에 대한 기호 표현을 통해 좀 더 쉽게 작업할 수 있다. 이를 위 DLT 모듈은 런타임에서 생성된 오류 및 경고 메시지를 PC로 보 링보다 대역폭을 더 효과적으로 활용한다. 하지만 XCP 이벤 구성을 ECU의 비휘발성 메모리에 저장해야 한다. 해 A2L 파일에는 기호 이름에 대한 원시 값 배정이 포함되어야 내야 하는데, 이러한 메시지는 BSW 모듈 DET(Development Er- 하는데, 이는 C 프로그래밍 언어에서 흔히 사용되는 Enums와 비 ror Trace), DEM(Development Event Manager) 그리고 애플리케 슷하다. CANoe는 이 기호 값들에 대한 디스플레이를 담당한다. 이션의 SWC에 의해 생성된다. 또한 DLT에는 XCP와 호환되지 않 이러한 유형의 표현 방식은 대개 Enums를 사용해 코드로 표현되 는 자체 통신 프로토콜이 있다. 하지만 두 모듈(DBG 및 DLT)의 기 는 상태 시스템을 관찰하는데 매우 적합하며 어떠한 변수에도 적 능을 XCP와 함께 구현할 수 있으며, 벡터는 이미 AUTOSAR 3.x 용할 수 있다. 예를 들어, 대체 값 또는 초기화 값을 사용해 로드 솔루션에서 이러한 구현을 제공하고 있다(그림 1). 되었는지 여부를 기호로 표시할 수 있다.
그림 3: CANoe의 State Tracker 창은 XCP를 그림 4: 벡터의 측정 및 보정 하드 통해 획득한 내부 ECU 웨어 VX1000은 ECU 실행 시간에 데이터를 편리한 방식으 거의 영향을 주지 않으면서 대량의 로 시각화해 제공한다. 데이터를 확보할 수 있다.
7/14 7/15
6/3 독일 출판물 Hanser automotive 2011년 11월호 특별부록 기사 번역판
이미지 권리: Vector Informatik GmbH
Dipl.-Ing. (FH) Patrick Markl 벡터 임베디드 소프트웨어 제품 라인의 개념 개발 팀의 팀장이다.
Dipl.-Ing. (FH) Stefan Albrecht CANoe/CANalyzer Option AMD의 수석 제품 관리 엔지니어이다.
성공적인 AUTOSAR ECU 개발
사양검토부터 양산까지 전 개발과정 지원
벡터 AUTOSAR 솔루션을 통해 한 단계 앞서 나가십시오.
> 맞춤형 Basic Software 및 다양한 마이크로컨트롤러 지원 > 포괄적인 테스트: 최초 소프트웨어 모듈 배포부터 통합 > 인텔리전트 툴 체인을 통해 개발 단계 전반을 효율적으로 테스트까지 지원 지원 > 전문적인 맞춤형 AUTOSAR 엔지니어링 서비스를 통해 > 무단 액세스로부터 ECU를 보호하는 강력한 보안 기능 신속한 목표 달성 가능 > ISO 26262 표준의 ASIL D 등급을 만족하는 ECU 개발 및 인증 노력 최소화 자세한 정보 및 다운로드: www.autosar-solutions.com
벡터의 검증된 제품과 다년간의 ECU 개발 경험이 귀하의 성공적인 프로젝트를 지원합니다.
7/16 6/17
Vector Korea IT Inc. | Phone +82 2 807 0600 | www.vector.com 그림 1: AUTOSAR 계층 모델
AUTOSAR 표준은 애플리케이션 소프트웨어의 SWC에 대해 유사 로 SWC를 테스트할 수 있다. SWC 버전들이 크게 차이 나는 것 한 포스트빌드 방법을 정의하는 것이 아니므로 단 하나의 SWC 을 방지하기 위해 시스템 통합업체는 모든 SWC의 업데이트 버 를 수정하더라도 전체 ECU 소프트웨어를 컴파일하고 링크해야 전으로 정기적으로 새 ECU 소프트웨어 이미지를 생성한다. 한다. 하지만 전체 통합 횟수를 줄이는 방법은 있다. 다음 섹션부 터는 SWC 공급업체가 애플리케이션 소프트웨어의 개별 SWC를 어떤 SWC를 교환할 수 있는지에 관해서는 제한이 없다. 하지만 플래시 메모리에서 직접 교환하여 통합 부하를 줄이는 방법에 대 이에 대한 결정은 구현 및 메모리 분산에 관한 특수 사항들을 고 해 설명하기로 한다. 려해야하므로 ECU 계획 단계에서 이루어져야 한다.
SWC 교환 절차 교환 가능한 SWC의 메모리 예약 AUTOSAR 소프트웨어 컴포넌트를 위한 플러그앤플레이 솔루션 SWC 교환 시에는 기존 SWC가 ECU 메모리에서 바로 업데이트 오늘날 소프트웨어 개발에서 전체 통합이란 일반적으로 메모리 된 버전으로 교체된다. 이 프로세스는 나머지 ECU 소프트웨어에 매핑 파라미터를 지정하지 않고 SWC 프로그램 코드를 링크하는 AUTOSAR 표준에 정의된 인터페이스를 사용하면 여러 공급업체의 컴포넌트로 ECU 애플리케이션을 쉽게 조립할 수 있다. 하지만 는 영향을 주지 않는다. 이는 플래시 부트로더를 사용하여 ECU 것을 말한다. 교환 가능한 SWC의 경우 SWC 공급업체가 특정 메 개별 컴포넌트를 소프트웨어 전반에 통합시키기 위한 단계가 추가되기 때문에 소프트웨어 개발 프로세스가 길어진다. 교환 가능한 에서 온라인상에서 수행할 수도 있으며 적당한 HEX 편집기를 통 모리 매핑을 기반으로 링크 작업을 수행해야 한다. 링크 과정에 소프트웨어 컴포넌트를 사용하면 전체 프로젝트를 링크할 필요 없이 플래시 메모리에서 각 소프트웨어 컴포넌트를 교환할 수 있기 해 오프라인으로 수행 후 이를 ECU로 전송할 수도 있다(그림 2). 서 RTE 및 SWC 모두 ECU 메모리에 저장된 주소를 통해 서로의 때문에 이 전체 통합 횟수가 줄어들며 그에 따라 개별 공급업체의 소프트웨어 개발 속도가 빨라진다. SWC 교환은 일반적으로 SWC 공급업체가 수행하지만 시스템 통 인터페이스를 확인한다. 이를 위해 ECU 메모리를 다시 여러 파 합 업체가 수행할 수도 있다. 공급업체는 전체 통합에 드는 수고 티션으로 나누어 각 SWC에 독점적으로 할당한다. 파티션 크기를 를 절약하여 개발 주기(코딩 – 교환 – 테스트 – 최적화)를 단축할 결정하기 위해 SWC의 각 Runnable에 필요한 메모리 크기를 산 AUTOSAR ECU 소프트웨어는 기본 소프트웨어, 런타임 환경 및 다. 각 파트는 소스 코드나 사전 컴파일된 이진 파일로 공급되며 담 수 있다(그림 3).시스템 통합업체는 초기에 전체 ECU의 소프트웨 출한다. 처음에는 이로 인해 애플리케이션의 메모리 요구 사항이 애플리케이션의 세 부분으로 나뉜다(그림 1). 기본 소프트웨어 당 ECU 업체에서 전체 통합 작업을 통해 실행 가능한 일체형 ECU 소 어 이미지를 생성하여 SWC 공급업체가 사용할 수 있게 한다. 그 늘어난다. 하지만 이는 개발 과정에만 적용될 뿐이며 생산 환경 (BSW: Basic Software)는 드라이버 및 추상화 계층(abstraction 프트웨어로 통합한다. 그런 다음 모든 SWC 공급업체가 소프트웨어 런 다음, 공급업체가 SWC의 새 버전을 만들어 전체 소프트웨어 에서 사용할 최종 소프트웨어에서는 메모리 요구를 줄이기 위해 layers)을 통해 애플리케이션에 마이크로컨트롤러의 리소스를 제 이미지 결과물을 수거하여 이후 개발 단계에 사용한다. 이미지의 정확한 위치에 버전의 이진 파일을 배치하기만 하면 바 파티셔닝을 생략할 수 있다. 공하는 기본 프레임워크이다. 런타임 환경(RTE: Runtime Envi ronment)은 애플리케이션과 기본 소프트웨어 간의 상호 연결 계 하지만 이 방법은 시간이 매우 오래 걸리므로 소프트웨어 개발 속도 층 역할을 수행한다. RTE는 애플리케이션 섹션 간 통신을 추상화 가 둔화된다. 한편에선 ECU 업체가 SWC의 새 버전마다 지루한 전체 하므로 ECU의 경계를 넘어선 투명한 데이터 교환이 가능하다. 이 통합 작업을 수행해야 하고 또 한편에선 SWC 공급업체가 나머지 를 위해 RTE는 애플리케이션 및 기본 소프트웨어와의 인터페이 ECU 소프트웨어와의 상호 작용을 진행하면서 애플리케이션을 테스 스를 제공한다. 서로 다른 ECU에서 정적 모듈을 변경하지 않고 트하기 위해 통합 결과를 기다려야 한다. 대기 상황이 자주 발생하면 사용할 수 있는 BSW와 달리 RTE는 ECU별로 개별적으로 생성되 추가적인 노력이 많이 들 수밖에 없는데 특히 초기 개발 단계에서 이 고 반드시 필요한 인터페이스만 제공한다. 하나의 애플리케이션 런 일이 많이 발생한다. 은 소프트웨어 컴포넌트(SWC)의 조합으로 구성되는데, 이는 다 시 Runnable이라는 최소 단위를 통해 기능이 구현된다. 포스트 빌드: 링크 후 소프트웨어 수정 AUTOSAR는 컴파일 및 링크 후 특정 BSW 모듈의 동작을 수정할 분산 소프트웨어 개발 수 있게 해 주는, 기본 소프트웨어의 포스트빌드 방법을 정의하 T모듈식 AUTOSAR 아키텍처를 이용하면 소프트웨어 공급업체가 특 는데, 이는 구성 데이터를 BSW 모듈 코드와 별도로 플래시 메모 정 애플리케이션이나 컴포넌트 즉, 기본 소프트웨어, 차량 동역학, 엔 리에 저장하는 작업이다. 즉, ECU 소프트웨어를 다시 컴파일하고 진 관리 등의 분야를 전문화 하기 쉽다. 결과적으로 ECU의 소프트웨 링크할 필요 없이 런타임에 데이터를 교체할 수 있다. 그림 2: 교환 가능한 SWC가 메모리 이미지에 방출되고ECU의 플래시 그림 3: SWC 교환으로 SWC 공급업체의 소프트웨어 개발 속도가 빨라진 메모리로 전송된다. 다. 어를 여러 공급업체의 모듈과 컴포넌트로 구성하는 일이 일반화된
7/18 7/19
6/2 페이지 단위로 삭제가 가능한 플래시 메모리의 경우 일반적으로 높다. 이런 이유로 SWC 내에 메모리 영역을 예약해야 한다. 이 SWC 교환의 제약 업은 여전히 수동으로 수행해야 한다. 하지만 앞으로는 구성을 한 페이지 이상의 공간을 SWC에 할당하지만, SWC가 한 플래시 예약 영역을 설정하기 위해 SWC 공급업체가 컴파일러 명령을 여기서 설명한 대로 SWC를 교환할 수 있도록 하려면 몇 가지 조 통해 이 프로세스의 상당 부분을 자동화할 계획이다. 페이지보다 많이 작고 페이지 분할이 허용되지 않을 경우 한 플 사용하여 SWC를 정적 영역과 가변 영역으로 나눈다. 건을 충족해야 한다. 래시 페이지에 여러 SWC를 할당할 수 있다. 하지만 이 경우 플 > SWC 교환 프로세스 중에는 포트 인터페이스를 추가하거나 래시 부트로더 또는 HEX 편집기로 SWC를 교환할 때 플래시 페 정적 영역에는 SWC로 점프하는 데 필요한 영역이 있는데, 이는 제거할 수 없다. 하지만 향후 확장을 위해 RTE 생성 시 포트 이지의 나머지 내용이 변경되지 않도록 해야 한다. 기능 구현이 바뀌는 경우에도 항상 동일하게 유지되며 이를 위해 인터페이스를 추가로 할당할 수 있다. 독일 출판물 ATZ elektronik 2012년 1-2월호 기사 번역판 SWC의 Runnable이 수정된다. SWC의 Runnable에는 특정 애플 > RTE가 RTE 생성 시 알려진 모든 Runnable을 호출할 수 있기 SWC 컴파일 및 링크를 위한 소프트웨어 환경 리케이션 코드가 들어 있지 않고 함수 호출만 들어 있다. 여기서 때문에 SWC에서 Runnable 수를 변경해서는 안 된다. 개발 중 이미지 권리: SWC를 컴파일하고 링크하기 위해 공급업체는 호출된 인터페이 호출되는 소위 Runnable 함수라는 것은 SWC의 가변 영역에 저 에 Runnable을 제거하거나 새 Runnable을 추가하는 경우 그 Vector Informatik GmbH 스에 모든 SWC 종속 관계를 확인해 주는 소프트웨어 환경이 필 장되어 있고 Runnable의 실제 함수 코드가 들어 있다(그림 5). 따 에 따라 RTE를 수정하고 전체 통합을 실행해야 한다. 요하다. 이를 위한 이상적인 환경은 BSW 및 애플리케이션이 포 라서 이 코드는 필요하면 정적 영역의 Runnable 주소를 수정하 > 계획 단계에서는 SWC별로 ECU에 어떤 조건이 필요한지 미리 Alexander Zeeb, Vector M.Sc. 독일 슈투트가르트에 소재한 벡터 인포매틱(Vector Informatik GmbH) 함된 전체 Runnable ECU 소프트웨어인데 이는 전체 통합에도 지 않고 변경할 수 있다. 정의해야 한다. 이는 하드웨어 리소스와 관련이 있고 한편으 에서 임베디드 소프트웨어 콘셉트 개발부 소프트웨어 개발 엔지니어 사용된다. 이 방식은 기본적인 방법으로 전체 통합에 해당된다. SWC를 컴파일하고 링크할 때마다 Runnable의 심볼릭 점프 타겟 론 각 Runnable의 스케줄링 및 추가 수학 라이브러리와도 관 로 일하고 있다. 하지만 통합은 SWC 공급업체에서 진행된다. 이 실제 주소 또는 오프셋으로 바뀐다. 따라서 RTE에서는 Run 련이 있다. nable 함수의 실제 주소를 알 필요가 없다. > 각 공급업체의 툴 체인을 조율하여 컴파일러 버전과 옵션 차 이런 소프트웨어 환경을 만드는 일은 보통 엄청난 노력이 필요하 이 때문에 발생하는 비호환성을 예방해야 한다. 며 또 항상 가능한 것은 아니다. 따라서 그 대안으로 SWC 공급 SWC에서 포트 인터페이스 호출 업체가 자체적으로 최소한의 환경을 만들 수 있다. 이 환경은 RTE가 Runnable을 호출하는 것과 마찬가지로 Runnable 함수도 전망 SWC가 호출하는 인터페이스에 서비스만 제공하면 된다(그림 4). 그 반대 방향으로 RTE가 제공하는 포트 인터페이스를 호출해야 여기에 소개한 애플리케이션 예(여러 SWC 공급업체와 한 시스 한다. SWC 공급업체가 전체 통합의 BSW 및 RTE가 있는 소프트 템 통합업체)가 우리가 상상할 수 있는 유일한 애플리케이션 예 두 가지 방식 모두 SWC 공급업체는 컴파일 및 링크 후 이진 파 웨어 환경 전체를 사용하는 경우(“SWC 컴파일 및 링크를 위한 소 는 아니다. 교환 가능한 SWC는 바이패싱에 필요한 계기(Instru 일을 얻게 되는데 여기에는 SWC와 함께 소프트웨어 환경의 코 프트웨어 환경” 섹션 참조)에는 모든 점프 타겟이 링크 작업 때 mentation)를 교환 가능한 SWC로 ECU에 편리하게 적용할 수 있 드도 포함되어 있다. 이 추가 코드는 이후의 SWC 교환과는 무관 알려지기 때문에 추가 조치가 필요하지 않다. 기 때문에 SWC의 바이패싱을 단순화할 수 있다. 그런 다음 SWC 하므로 삭제된다. 그러면 테스트할 SWC 이진 파일이 남게 되는 하지만 최소한의 소프트웨어 환경을 사용할 경우에는 SWC가 생 를 ECU에서 테스트하면 계기를 사용하지 않은 SWC로 계기를 다 데, 이 파일에는 점프 타겟이 이미 정확한 메모리 주소에 저장되 성될 때 RTE의 포트 인터페이스가 전체 통합의 주소가 아닌 다른 시 교체할 수 있다. 어 있다. 주소에 위치하게 된다. 그러면 SWC를 링크할 때 엉뚱한 주소가 교환 가능한 SWC는 ECU 소프트웨어 개발을 지원하고 가속화할 저장되는 결과가 발생한다. 수 있는 효과적인 수단이다. SWC 및 메모리 매핑을 준비하는 작 SWC 교환 원리 플래시 메모리의 SWC를 업데이트한 후에도 RTE 또는 다른 Run SWC에서 포트 인터페이스를 호출하는 동작이 정확하게 이루어 nable이 SWC에 포함된 Runnable을 호출할 수 있어야 한다. 전 지게 하려면 교환 가능한 SWC와 함께 두 개의 AUTOSAR 기능을 체 통합 과정의 컴파일 단계에서 링커는 RTE에 저장되어 있는 심 사용해야 하는데 이는 개체 코드(Object Code)와 다중 인스턴스 볼릭 점프 타겟을 SWC 내 Runnable의 실제 주소로 바꾼다. SWC 생성(Multiple Instantiation)이다. 이 조합을 이용하여 RTE는 운 가 교환될 때 이 주소가 RTE 내에 변함없이 그대로 유지되기 때 영 중 인스턴스 핸들을 파라미터로 각 Runnable에 전달한다. 이 문에 매 컴파일 및 링크 작업마다 교환 가능한 SWC의 Runnable 핸들은 컴포넌트 데이터 구조라고 하는 RTE의 간접(Indirection) 이 항상 이 메모리 주소에 저장되도록 해야 한다. 이 조건은 수동 구조를 가리킨다(그림 6). 이 구조에 저장되어 있는 것은 SWC의 으로 지정되는 고정 주소를 개별 Runnable에 할당하는 적절한 모든 포트 인터페이스 주소이다. 따라서 SWC는 RTE 포트 인터페 컴파일러 및 링커 명령 등으로 충족할 수 있다. 하지만 ECU 개발 이스의 주소를 알 필요가 없다. 컴포넌트 데이터 구조는 각 SWC 과정에서 Runnable의 메모리 요구 조건이 커질 가능성이 매우 의 계약 단계 헤더(Contract Phase Header) 파일에 기술되어 있다.
그림 4: SWC를 교환할 때 전체 소프트웨어 환경 그림 6: Runnable이 호출되면 인스턴스 핸들이 해당 Runnable에 전달된 대신 최소한의 소프트웨어 환경이 링크에 사용 그림 5: SWC를 정적 영역과 가변 영역으로 나누어 Runnable을 고정 다. 이를 통해 Runnable 함수가 RTE의 포트 인터페이스에 액세스할 수 된다. 주소에 배치하면 RTE와 다시 링크하지 않고 호출할 수 있다. 있게 된다.
7/20 7/21
6/4 (표 1) OBD별 DCM 확장 모듈 에는 9개의 서비스가 추가로 들 어 간다.
5개사의 자동차 OEM 업체를 위한 DEM/DCM/FIM 모듈의 OBD 확 장기능은 이미 벡터에서 출시한 AUTOSAR 3 및 AUTOSAR 4 BSW AUTOSAR와 차량 내 진단 시스템 에 적용되어 있다.
파워트레인이 점점 더 전기화 되어감에 따라 OBD(On-board diagnostics)가 필요한 ECU(Electronic Control Unit)의 수도 계속 늘어나 고 있다. 이에 벡터는 AUTOSAR BSW(Basic Software)에 통합된 OBD 기능에 대한 요약과 그 사용 사례에 대해 소개하고자 한다. 링크: Vector 홈페이지: www.vector.com
배경 AUTOSAR BSW로서의 OBD 기능 내연 엔진 차량의 경우, 최근 배기가스의 배출 기준이 점차 엄격해 전기구동장치의 급속한 보급으로 포괄적인 컴포넌트 모니터링 기 저자: 지고 있다. 수년에 걸친 차량의 운행기간 동안 지속적으로 이러한 능 규제기준을 충족시키기 위해서는 OBD시스템이 차량의 컴포넌트 을 가진 Primary ECU의 수가 늘고 있다. AUTOSAR에서는 DCM(Di 와 시스템을 모니터링 해야 한다. agnostic Communication Manager) 모듈과 DEM(Diagnostic Event Manager) 모듈 그리고 FIM(Function Inhibition Manager) 이를 위해 일반적으로, 차량에는 3 종류의 ECU가 탑재된다. 하나 모듈에서 구현되어야 하는 OBD 기능을 정의하고 있다. 대부분의 의Master ECU는 데이터를 수집 및 조정하여, 운전자에게 보내는 기능은 OBD 표준 및 지침에 있는 정의를 참고하고 있으나, 구체적 경고 메시지를 관리하는 역할을 한다. Primary ECU는 각자의 내부 인 구현방식과 설정, 예를 들어 캘리브레이션 전략 및 UDS(Unified 메모리에서 폴트 데이터를 수집하여 외부 스캔 툴에 전달하는 Diagnostic Services) 폴트 메모리와의 관계 등은 소프트웨어 공급 Thomas Necker ECU로 오직 Primary ECU 또는 Master ECU에게만 수정 데이터를 업체가 OEM 업체들과 협력하여 정의해야 한다. 독일 슈투트가르트에 소재한 벡터사의 임베디드 소프트웨어 분야 보고하는Secondary ECU와는 차이가 있다. 의 팀장이다. DCM 모듈은 OBD서비스를 구현하고 있다(표 1). 더욱이, OBD re 컴포넌트 및 시스템에 대한 모니터링은 두 가지 범주로 나눌 수 있 quest는 UDS request보다 우선순위가 높게 처리되거나 병렬적으 다. 주요 모니터링 기능은 배기가스 배출기준에 직접적인 영향을 로 처리된다. DEM 모듈 역시 UDS의 추가기능에 해당하는 다양한 미치는 시스템과 관련이 있다. (예: 연료 및 배기가스 재순환 시스 OBD 확장기능을 포함한다. 여기에는 오류시의 상태동작에 대한 템). 그 외의 컴포넌트 모니터링은 주요 모니터링 기능에 필요한 수정된 내용과 DTC 저장방식 그리고 프리즈 프레임(Freeze frame) 시스템이나 배기가스에 간접적인 영향이 있는 시스템과 관련이 데이터 저장, IUMPR(In Use Monitor Performance Ratio) 계산방식 있다. 여기에는 차량 제동시의 배터리 재충전이나 배터리 관리, 공 등이 포함된다. FIM 모듈과 결합할 경우, 특정한 오작동이 탐지되 조기 시스템에 관련된 기능이 포함된다. 면 바로 IUMPR 카운터의 작동을 해제할 수 있다. Oliver Garnatz 독일 슈투트가르트에 소재한 벡터사의 임베디드 소프트웨어 분야 에 근무하는 제품 매니저이다.
6/227/22 7/23 같은 Basic Software의 모든 영역에서 유용하다. 다. 이와 더불어, OEM은 기존의 BC, LDF 및 FIBEX 포맷을 사용한 다. 또한 Tier 1업체는 예를 들어 ECU 내부의 전용 CAN 통신이 예를 들어, 에디터를 메모리 도메인 영역으로 사용할 경우, 개발 나 센서와 ECU 연결을 위한 LIN 통신에 대해서 자체 System 자는 메모리 블록을 간단히 삽입할 수 있으며, 그 메모리 블록은 Description을 사용할 가능성도 있다. 플래시 EEPROM 에뮬레이션(Fee)으로뿐만 아니라 비휘발성 RAM (NvM)에서 일관되게 설정할 수 있다. 또한, 그래픽 화면에 따라서 소프트웨어 툴은 반드시 모든 가능한 유형의 입력 데이터 표시되는 사용자 데이터 블록 크기의 비율을 통해 오버헤드를 쉽 를 식별하고, 적절한 전처리 방법을 통해 기존 포맷을 변환하고, 게 예측할 수 있다. (그림 2). ECU관련 System Extract를 생성해야 한다. 또한, 서로 다른 여러 개의 System Description을 하나의 System Descripton으로 통합 또한, 툴의 지원기능은 설정 프로세스에서 유용하다. 예를 들어, 하는 것이 가능해야만 한다. 그래야만, Base EcuC를 생성하는 것 개발자가 파라미터값을 변경할 때, 그 값에 의존하는 다른 파라 이 가능하다. 미터값 또한 규칙에 따라 자동으로 수정된다. 실행 가능한 개체 (Runnable Entity)를 OS 태스크에 매핑하는 것과 같은 더욱 복잡 이와 유사한 고려사항이 진단 모듈에도 적용된다. 모듈의 설정은 한 작업의 경우에도, 지원 기능이 도움된다. 이 지원기능을 통해 반드시 ECU의 ODX 사양과 일치해야 한다. 따라서 ODX 파일 역 개발자는 유사한 트리거 조건을 바탕으로 SWC의 실행 가능한 시 반드시 Base EcuC 에 포함되어야만 한다. 가끔, TIER1도 EcuC 개체(Runnable Entity)를 선정하고, 태스크를 할당하여, 그 태스 포맷으로 직접 사용 가능한 프로젝트용 표준 설정을 갖추고 있 크 내의 실행 순서를 정의할 수 있다. 다. 이러한 설정 요소는 Base EcuC에도 포함되어야만 한다. 설정 을 점검하는 데 필요로 하는 BSWMD 파일은 다양한 소스에서 생 모드관리 도메인에서 또 다른 예를 들 수 있다. AUTOSAR4의 성할 수 있다. 이 파일은 TIER2-BSW 공급자에 의해 제공되거나, BswM모듈에서는 다른 BSW모듈의 모드 변화에 대한 대응이나, MCAL 모듈과 일치하도록 마이크로 컨트롤러 제조자에 의해 공 모드 변화 요청에 대한 중재 규칙을 논리식과 처리 동작(Action) 급된다. 으로 사용자가 정의할 수 있게 되어 있다. 현재 지원 기능을 통해 상대적으로 조작하기 용이한 AUTOSAR 3의 ECU State Man 마지막으로, OEM이 공급업체에 제공하는 System Extract에 ager(EcuM)와 유사하게BswM이 동작하도록 설정할 수 있다. SWC가 포함되는 경우가 있다. AUTOSAR 4 방법론에서는 먼저 전문화된 소프트웨어 툴을 통한 사용자 친화적인 AUTOSAR ECU설정 System Extract를 사용하여 ECU Extract를 생성하며, 여기에서 System Description으로부터 파라미터를 도출하기 SWC 간의 구성이 표시된다. 이후에는 예를 들면 외부 공급업체 단순한 CAN ECU는 과거의 이야기이다. 이제 ECU는 AUTOSAR Basic Software의 다양한 기능을 활용하여 보다 복잡한 작업을 수 CAN, LIN, FlexRay 또는 Ethernet용 통신 모듈의 구성은 OEM에 (TIER2-SWC)에 제공할 지도 모르는 다른 SWC를 추가하여 ECU 행한다. 그러나 기능이 많아질수록, 설정 프로세스 역시 더 어렵고 광범위해 지면서, 툴의 지원 없이는 개발 활동이 점차 힘들어 서 제작한 System Description 시스템 설명과 반드시 일치해야 Extract를 확장하게 된다. 이러한 ECU Extract와 Base EcuC를 이 지고 있다. 한다. AUTOSAR에서는 System Description에서 ECU에 해당하는 용하여 ECU 개발자는 BSW와 RTE (Runtime Environment)에 대 정보(System Extract)를 추출하여 각 모듈의 기본 설정(Base 한 전체적인 설정을 만들어 낸다. 여기서, 툴은 Base EcuC에서 얻 EcuC) 도출이 가능하다. 그러나 실제 상황은 더욱 복잡하다. (그 어진 파라미터가System Extrace와의 불일치가 발생하지 쓰기 방 다음의 세 요소가 ECU 구성의 복잡성에 영향을 미친다. 으로 발전하고 있다. 새로운 버전을 출시할 때 마다 BSW 모듈의 림 3): AUTOSAR는 System Description 표준 포맷을 정의하여 왔 지(Write Protect)를 통해 보호하여야 한다. > 표준화 강화 기능성은 변경되고, 새로운 모듈로 정의되었다. 이러한 모든 모 ECU 소프트웨어의 많은 부분이 AUTOSAR를 통해 Basic Soft 듈은 자체 설정 파라미터를 갖추고 있다. 그러나 AUTOSAR 설정 프로젝트 업데이트 ware로 표준화되었다. 그러나, “구현(Implementation) 대신 접근법은 공식적으로 기술된 모듈 구조 및 파라미터을 이용해 이 프로젝트 동안, 개발자는 계속 업데이트된 입력 데이터를 받는 설정(Configuration)“이라는 AUTOSAR의 원리는 개발자들이 러한 역동성을 처리할 수 있다. 이는 BSW에 포함된 Basic Soft 다. 일반적으로, 이러한 업데이트는 각기 다른 시점에 일정하지 시작부터 일관된 설정을 만들어내도록 강요한다. 코드에서의 ware 모듈 설명서(BSWMD)를 쉽게 이해하도록 돕는다. 처음에 직접적인 연결을 제공하지 않는다. 는, 이러한 정형화된 방법으로 툴에 접근하는 것이 매력적이라고 > 더욱 풍부해진 기능 생각할 것이다. 툴 회사는 포괄적으로 적용 가능한 툴을 개발하 멀티 코어 및 메모리 보호 기능을 가진 신규 마이크로 컨트롤 여, 오늘날 알려진 파라미터뿐만 아니라 미래의 파라미터까지, 러와 이더넷과 같은 새로운 네트워크는 베이직 소프트웨어의 모든 파라미터를 개별적으로 설정할 수 있을 것이다. 그러나 누 범위를 증가시키면서 설정이 필요해지게 되었다. 구도 추가적인 지원 없이는 에디터 내에 필요한 수천 개의 파라 > 새로운 협력 모델 미터를 설정하는 것을 원치 않을 것이다. AUTOSAR 방법론은 개발 프로세스에서 새로운 역할을 하고 있다.(그림 1). AUTOSAR 베이직 소프트웨어(TIER2-BSW) 공급 전용 에디터 및 지원 기능 자와 더불어, 또한 어플리케이션 SW 컴포넌트 (TIER2-SWC) 이러한 작업을 단순화하는 소프트웨어 툴을 개발하는 다양한 방 및 하드웨어 관련 마이크로 컨트롤러 추상화 레이어 모듈 법이 있다. 특별히 개발된 에디터는 파라미터 간의 관계를 표시 (TIER2-MCAL) 공급자도 있다. 이는 설정 단계 초기에 더 많은 조율이 필요하다는 것을 의미한다. 하고, 설정 과정을 벌크 연산 별로 단순화시킨다. 또한, 이 에디터 는 모듈 경계를 넘어서까지 확장하여 파라미터를 주제별로 분류 소프트웨어 툴의 역할 할 수 있다. 에디터의 그래픽 뷰는 복잡한 구성에 대한 이해를 돕 그림 1: 개발 프로젝트에서의 역할 그림 2: 진보된 표시기능을 통한 ECU설정 단순화 AUTOSAR 표준은 새로 출시될 때마다 변화하며 역동적인 방식 는다. 이러한 툴은 통신, 모드 관리, 진단, 메모리 관리 및 I/O와
7/24 7/25
6/2 않은 주기로 발생한다. OEM은 차량 개발과정의 특정 단계에 따 동시 작업을 수행하는 개발자들을 위한 “병합(Merge)“ 기능 라 새로운 System Description을 배포하는 반면, 진단 사양은 일 소형 ECU 프로젝트라 하더라도, 항상 여러 개발자가 동시에 반적으로 훨씬 더 자주 업데이트된다. 보통, System Description 작업을 수행한다. 만약 각자의 역할이 분명히 정의되어 있다면, ( 을 받는 날짜와 ECU 납품 일자 사이의 시간 간격은 매우 짧다. 따 예를 들어, “동료 xy가 항상 운영체제를 담당하는 경우”) 동일한 라서 툴은 새로운 입력 데이터로 설정을 자동으로 업데이트 할 모듈 또는 동일한 SWC에 반복적으로 변경하는 것을 피할 수 있 수 있어야 한다. 새로운 Base EcuC를 생성하고 실제 설정을 새로 을 것이다. 그러나 일반적으로 개발자들은 동시에 작업하며 ECU 운 Base EcuC로 업데이트함으로써 프로젝트업데이트 기능을 실 소프트웨어의 모든 아키텍처 계층을 통해 수직으로 동작하는 현할 수 있다. ECU 기능을 개발한다(그림 4). 직접 손으로 C 코딩을 하던 시기 에는 SW 통합담당자는 여러 코드 분기를 텍스트 수준에서 통합 그림 4: “수직” ECU 기능의 개발 하지만 System Descriptio에 오류가 있을 경우 어떤 일이 일어날 하였을 것이다. 까? 비록 문제점들이 OEM으로 명확해졌더라도, 보통은 수정된 System Description이 즉시 입수되지 않는다. 이러한 경우, ECU 그러나 AUTOSAR의 경우, 이것은 SW 통합담당자가 XML 파일을 개발자는 도출된 파라미터를 의도적으로 무시하고, 다른 값으로 수 메가바이트 크기의 AUTOSAR 포맷으로 통합하리라는 것을 덮어쓰길 원할지도 모른다. 의미할 것이다. 일반 XML 툴을 사용하여 AUTOSAR 설정을 비교 그러나, “병합(Merge)해야 할 변경사항이 적을수록 좋다“ 라는 이는 오류를 직접 ECU 설정에서 수정하는 방법인데, 그러한 차 또는 병합하는 것이 실제로 가능하지 않을 것이다. 파일의 구조 경험 법칙이 적용된다. 예를 들어, 설정에 대한 대규모의 수정은 그림 5: DaVinci Configurator Pro 내의 Diff/Merge지원 이는 항상 중요한 문제이므로, ECU 개발자는 파라미터 상태를 툴 및 파일 내 많은 참조문서가 이러한 작업을 시행하기에는 아주 새로운 통신 매트릭스(C-매트릭스)에 대한 프로젝트 데이트 때문 내에 “사용자 정의 상태”로 명시적으로 설정할 수 있어야 한다. 복잡하기 때문이다. 일지도 모른다. 따라서 다음과 같은 실제적인 절차가 권장된다. 파라미터가 이 상태에 있는 한, 업데이트 시 툴이 기존의 값을 덮 통합시점 MS0에서부터 시작하여, 기능 개발 담당은 각각 다른 어쓰는 것을 방지할 수 있다. 오직 ECU 개발자가 상태 “사용자 정 오직 AUTOSAR 설정의 차이를 명백히 나타내고, 통합 옵션을 제 분기(branch)에서 개발 작업을 진행한다. 기능 개발 담당은 각각 발자는 AUTOSAR 프로젝트 개발에 있어 실질적으로 유용한 지원을 의 상태”를 제거할 때에만, 도출된 값을 파라미터로 채택할 것이 공하는 AUTOSAR 툴만이 이 작업에 도움이 될 것이다(그림 5). 다른 분기(branch)에서 개발 작업을 진행한다(그림 6). 이러한 받을 수 있다. 다. 이상적으로는, 사용자는 설정을 생성한 동일 에디터 내에서 직접 분기들을 가능하다면 중간 통합 단계(MS1 혹은 MS3)에서 차례 그 차이를 볼 수 있다. 이를 통해, 사용자는 편리하게 서로 다르 대로 메인 분기에 통합한다. 그 이후에서야 통합당당자는 프로젝 독일 출판물 “Elektronik automotive”, 제4호/2014년 기사 번역판 또한, 툴은 ECU 개발자와 OEM 간의 협업을 돕는데, 예를 들어 중 고 친숙하지 않은 데이터를 가지고 별도의 툴로 작업할 필요가 트를 새로운 C-매트릭스(MS4)로 업데이트할 수 있다. 그 후, 복 기입한 파라미터에 대한 보고서를 생성함으로 이를 돕는다. 없게 된다. 새로운 분기가 추가되고, 새로운 C-매트릭스에 일치하는 기능이 이미지 권리: 개발될 수 있다. 이러한 모든 것은 역시 SWC의 실행 파일을 Vector Informatik GmbH 관리하는 형상관리 CM) 시스템에 의해 지원될 수 있다. 링크: 사용 가능한 툴 Vector AUTOSAR Solution: www.vector.com/autosar 벡터의 DaVinci Configurator Pro 툴은 이미 기술된 작업 방법을 가 능하게 한다. 조만간 DaVinci Configuration Pro에서 설정 Variant를 Matthias Wernicke (Dipl.-Ing. (FH)) 울름(Ulm)의 The University of Applied Science 에서 산업 전자공학 생성하는 것이 가능하게 될 예정이다. 이는 ‘Post Build Selectable 공부를 마친 후, 울름의 다임러 연구소에서 4년간 근무했다. 2000년 Variant‘로 불리기도 한다. 여기에서도 현재 제공되는 AUTOSAR의 개 이후, 슈투트가르트(Stuttgart)의 벡터 인포마틱(Vector Informatik)에 서 차량용 분산 시스템을 설계하는 방법 및 툴의 개발을 해왔으며, 념을 툴의 기능에 지능적으로 구현하는 것이 중요하다. 그 후에야 개 현재는 DaVinci AUTOSAR 툴의 제품 관리 책임자이다.
그림 3: Vector의 DaVinci Configu rator Pro에 관한 예제에 기초하여 ECU 구성을 생성 및 업데이트 하 그림 6: 동일한 ECU설정상의 동시 기 위한 작업 흐름 작업
7/26 7/27
6/4 그림1: 개발자는 태스크를 OS 어플리케이션으 로 그룹화하고 각 코어에 배치함
, 안전과 관련된 시스템은 ASIL 분리와 같이 다양성 알고리즘의 않다. AUTOSAR 운영체제는 태스크가 과도한 런타임을 사용하거 구현을 위해서 사용된다. 개발자는 병렬처리에 기반을 두고, 안 나 장시간 동안 인터럽트를 차단하지 못하도록 점검한다. 하지만 전 컨셉에 따라 소프트웨어 모듈을 AUTOSAR에서 정의된 OS 어 태스크 시퀀스와 태스크 트리거 조건을 정확하고 안전하게 설정 플리케이션에 할당한다. 이것이 ISO26262에서 정의한 분해(de- 하는 일은 개발자에게 매우 복잡한 작업이다. TTTech와 벡터는 composition)에 해당하며, 하나의 ECU 내에서 상호 간섭을 일으 이에 대한 솔루션을 지원하고 있다. 이 솔루션은 ASIL-D에 따라 키지 않고 실행될 수 있어야 하는 영역을 의미한다. 멀티코어 개발된 프로그램 플로우 모니터 (Flow Monitor)의 형태를 띠며, ECU에서는 OS 어플리케이션이 서로 다른 프로세서 코어에 할당 이 모니터에 포함된 태스크와 함수의 실행 시간 및 순서를 모니 AUTOSAR, 멀티코어와 기능 안전을 추구하다 된다. (그림1) 터링한다. 이 프로그램 플로우 모니터의 개체는 코어 별로 생성 개발자의 관점에서는 분할의 목적이 병렬처리인지 분해(decom- 된다. 모니터는 소프트웨어와 결합된 체크 포인트들을 통해 함수 최근 차량 ECU와 관련된 소프트웨어 개발의 핵심에는 두 가지 중요한 이슈가 있다. 멀티코어 프로세서에 대한 컴퓨터 아키텍처의 position)인지는 상관이 없다. 중요한 것은 OS 어플리케이션 간 실행에 관한 정보를 수신한다. (그림2) 이 정보들은 프로그램에 추세 및 ISO26262에 의해 요구되는 기능 안전 표준에 관한 문제이다. 개별적으로도 이미 충분히 복잡한 주제인데 이 두 가지를 의 간섭을 배제하는 것이다. 이를 위해서는 반드시 런타임 모니 서 안전과 관련된 부분들이 정확하게 처리되어야만 정확한 순서 함께 적용하는 경우에는 어떤 결과가 발생할 것인가? 터링 및 안전과 관련된 메모리 컨텐츠에 대한 잘못된 수정을 피 와 타이밍에 맞춰 체크 포인트들을 통과할 수 있다. 해야만 한다. 중앙의 Watchdog Manager는 모든 모니터의 상태 메시지를 수 집하고 Watchdog을 작동시킨다. 태스크가 코어 경계에 걸쳐서 멀티코어 아키텍처를 도입하는 주된 이유는 클록 속도를 높이지 능에 대한 요구사항을 평가하고, 적절한 ASIL(Automotive Safety 런타임 모니터링 독립적이기 때문에 개별 코어를 별도로 관리하는 것은 불가능하 않고도 연산능력을 증가시키기 위해서이다. 하지만 이것은 어플 Integrity Level) 이 정해진다. 안전 관련 기능을 구현하는 데 있어 Scalability class 2에서 AUTOSAR는 런타임 모니터링을 지원한 다. 더욱이 AUTOSAR 사양은 모든 코어를 공동으로 재 시작할 수 리케이션 소프트웨어의 상당 부분이 병렬처리될 때만 가능하다. 서, 멀티코어 소프트웨어 아키텍처는 왜 중요할까? 이러한 질문 다. 하지만 안전 관련 어플리케이션에서는 이것만으로 충분하지 있도록만 허용하고 있다. 따라서 Watchdog Manager를 ECU 전 이와 관련해서 일반적으로 암달의 법칙(Amdahl’s law)을 참고한 에 답을 하기 이전에 많은 안전 관련 프로젝트에서 사용되고 있 다. 예를 들어, 50%의 병렬 처리가 가능한 듀얼코어 프로세서와 는 멀티코어 프로세서의 Lockstep 컨셉과 관련하여 몇 가지 언급 소프트웨어를 싱글코어 아키텍처와 비교하면 연산량은 단지 최 할 필요가 있다. 대 30%만이 증가한다. Lockstep 모드 가능한 최대 연산능력을 확보하기 위해서는 개발자가 소프트웨 Lockstep모드에서는 동일한 코드가 두 개의 코어가 동일한 코드 어 모듈을 배치할 때 코어 간 자원 공유를 최소화하기 위한 모든 를 실행한다. 독립적인 컴퍼레이터가 실행 결과를 비교하고 불일 노력을 기울여야만 한다. 하드웨어 레지스터와 대부분은 데이터 치가 발생하는 경우에는 트랩(Trap)을 일으킨다. 이후의 진행 과 영역이 이와 관련된 자원에 해당한다. 코어 간 자원 활용으로 인 정은 ECU의 하드웨어와 안전성에 대한 컨셉에 따라 달라진다. 하 해 발생하는 과제는 자원에 대한 접근을 조율하는 것보다는, 공유 드웨어는 트랩 발생 이후에, 반드시 안전 상태가 설정되도록 설 자원에 동시에 접근하지 않도록 하여 대기상태를 피하는 것이다. 계되어야 한다. 에러 처리 이외에는 두 개의 코어가 동일한 코드 대기 상태에서는 독립적인 데이터 처리 손실이 발생하고 병렬처 를 실행하기 때문에 멀티코어와 관련된 소프트웨어 확장자가 필 리는 효용성을 잃기 때문이다. 요하지 않다. 다시 말하면, 비록 다수의 코어가 사용되고 있지만, 이것이 연산 능력을 증가시키기 위한 멀티코어 아키텍처는 아니 ISO2626에 따른 기능 안전 라는 것이다. ISO26262에서 요구하는 기능 안전 요구사항을 구현하는 일은 차 량 엔지니어링 개발 프로세스에서 이미 필수불가결한 사항이 되 분산 소프트웨어를 갖춘 멀티코어 아키텍처 그림 2: 어플리케이션의 체크포인터를 사용하여 플로우 모니터링이 정확한 시퀀스를 보증함 었다. 리스크 분석 결과에 기초한 안전성과 관련하여 ECU의 기 멀티코어 아키텍처는 연산 능력을 증가시키기 위해 사용되거나
7/28 7/29
6/2 체를 위한 중앙 집중형 모듈로 개발해야 한다. 반대로 실제 모니 표준 솔루션의 활용 독일 출판물 “Elektronik automotive”, 2014 년 6월호 기사 번역판 터는 각각의 코어 상에서 독립적으로 수행되며 Watchdog Man- 그러므로, 멀티코어 ECU에 대하여 ISO26262에서 규정한 것처럼 ager에 코어 경계를 가로질러 각각의 상태를 통보할 수 있다. 기능안전을 확보하기란 쉽지 않다. 하지만 이를 위해서 새로운 이미지 권리: 개발이 필요하기보다는, 기존의 시스템을 정확히 활용할 필요가 Vector Informatik GmbH ECU 내에서의 메모리 보호 및 안전한 통신 있다. 이를 위해, 벡터와 TTTech는 ECU 개발자에게 멀티코어 아 완벽하게 간섭을 배제하는 것은 하드웨어에서 MPU(Memory 키텍처에서 ASIL-D까지 대응되는 운영체제, RTE, 프로그램 플로 링크: Protection Unit)가 지원될 때만 가능하므로 어플리케이션 영역 우 모니터링을 제공한다. Website Vector: www.vector.com 은 이미 규정된 메모리 영역에만 접근할 수 있다. (그림 3) 이 메 일반적으로 싱글코어보다 멀티코어 시스템이 더욱 복잡하지만, 모리 영역은 코어별로 분리되어 규정되지만, 다른 코어와 함께 이는 Basic Software의 설정에 적용될 필요는 없다. 일단 프로세 Dr.-Ing. Helmut Brock 1999년부터 Vector Informatik에서 근무중이며 현재 Operating Sys- 하드웨어 자원(RAM, …)을 공유해야만 한다. 운영체제는 중심적 서 코어에 소프트웨어가 분산되고 나면, 멀티코어 시스템과 관련 tems 제품을 담당하고 있다. 인 역할을 수행하는데, 태스크 변경이 발생하는 시점마다, 운영 된 나머지 설정 작업은 최적화된 툴의 지원을 받아 싱글코어 아 체제는 메모리 파티션의 변경이 유효하도록 MPU를 재설정해야 키텍처의 경우보다 복잡하지 않다. 개발자는 태스크, 인터럽트 만 한다. 운영체제에서 컨텍스트 변경을 담당하는 이 부분은 안 서비스 루틴 등을 OS 어플리케이션이라는 컨테이너에 함께 그룹
전과 관련된 컴포넌트이며 항상 가장 높은 안전 레벨에 부합해야 화한 후에 이를 프로세서 코어에 할당한다. (그림1) 벡터의 Da- Dipl.-Ing. (FH) Joachim Kalmbach 만 한다. Vinci Configurator Pro 설정 툴을 사용하면 이러한 작업은 간단 2006년부터 Vector Informatik에서 근무중이며 임베디드 소프트웨어 부분에서Product Manager로 AUTOSAR와 멀티코어를 주로 담당하고 한 클릭만으로도 끝낼 수 있다. 통합된 RTE 생성 툴이 소프트웨 있다. 이는 데이터의 잘못된 오버 라이팅을 예방하기 위한 것이며, 다 어 모듈 간의 정확한 통신 방법(intra-core 혹은 inter-core)에 대 양한 프로세서 코어와 태스크 간의 정확한 데이터 교환이 필요하 한 설정을 자동으로 처리한다. 기 때문이다. AUTOSAR 아키텍처 모델에서는 두 태스크 간의 데 요컨대, Basic Software와 설정 툴의 형태를 갖춘 멀티코어 ECU 이터 교환은 VFB(Virtual Function Bus)의 방식에 의해 이루어진 에 대해 많은 지원이 이미 제공되고 있다. 그러나 소프트웨어 아 다. 이 VFB는 RTE(Runtime Environment)에 의해 구현된다. 키텍처를 생성하고, 프로세스 코어에 소프트웨어 컴포넌트를 분 산하기 위해 툴을 구현하는 일은 매우 어려운 작업이다. 이는 실 RTE는 멀티코어 아키텍처를 사용하는 안전 관련 ECU를 위해 다 제로 variant 평가로 국한되어 있다. 따라서, 가까운 미래에도 음과 같은 요구를 만족해야 한다. RTE는 메모리 파티션 간의 통 ECU 개발자는 이 분야에 대한 전문성과 경험을 계속해서 요구받 신을 허용하고, 동시에 코어 경계를 가로지르는 통신 경로인지 게 될 것이다. (inter-core), 또는 동일 코어를 통과하는 두 태스크 간의 통신 경 로인지를(intra-core) 구별할 수 있어야 한다. 코어 간 데이터 전 송은 추가적인 조율 메커니즘이 필요하다. 이를 위해, 운영체제 는 RTE에 IOC라고 기능을 제공하는데, 이를 통해 다양한 코어 상 의 태스크와 인터럽트 서비스 루틴(Interrupt Service Routine) 사 이에서 데이터 교환이 가능하다.
그림 3: 메모리 보호 유닛이 각 어플리케이션에서 미리 정의된 메모리 영역만 접근
7/30 7/31
6/4 최고 수준에 달했다. 90 이상으로 확장 가능한 임베디드 소프트 > AUTOSAR OS 확장클래스 1: OSEK / VDX 표준 운영을 추가 웨어 모듈이 정의되었고 워크플로우, 방법 및 데이터 교환 포맷 스케줄 테이블로 확장 을 더욱 표준화한 세트와 강력한 설정툴 그리고 코드 생성기가 > OS 확장 클래스 2: AUTOSAR OS SC1을 타이밍 프로텍션 함께 제공됐다. 추가로 확장 > OS 확장 클래스 3: AUTOSAR OS SC1을 메모리 프로텍션 ECU 공급업체가 자신들의 ECU에 AUTOSAR 베이직 소프트웨어 추가로 확장 를 탑재하기로 선택하면 다양하고 새로운 기능의 임베디드 소프 > OS 확장 클래스 4: AUTOSAR OS SC1을 타이밍과 메모리 트웨어 모듈이 포함된 규격품 구매가 가능하다. 이제 ECU에 새 프로텍션 기능 추가로 확장 로운 기능을 추가할 때마다 소요되던 장시간의 소프트웨어 개발 시간은 더 이상 장애가 되지 않는다. AUTOSAR 베이직 소프트웨 AUTOSAR OS 내 추가기능은 자원 패널티 없이 제공되지 않고 어에서 추가할 모듈을 간단하게 체크하면 즉시 적용이 가능하기 AUTOSAR 베이직 소프트웨어의 다른 모든 모듈과 마찬가지로 때문이다. 이와 같은 편리함은 소프트웨어 설계자로 하여금 ‘달 향상된 기능성은 상당량의 마이크로컨트롤러 RAM 및 ROM 자 콤한 사탕 가게’에서 원하는 사탕을 고르는 어린아이와 같이 만 원을 필요로 하며, 추가 프로세서 런타임 오버헤드 또한 소비한 들 것이다. 다. 이러한 부차적인 요구사양에는 일반적으로 향상된 ECU 처리 능력과 더욱 확장된 마이크로컨트롤러 메모리 용량이 지원돼야 물론 이렇게 강력한 소프트웨어 모듈에는 상당한 비용이 든다. 한다. 각 모듈을 개발한 설계자의 노력을 보상하기 위해서라도 상당한 라이센스 비용이 들 뿐만 아니라 프로세서 처리량 부하 관점에서 한편 ECU 공급업체들 사이에서 AUTOSAR 소프트웨어 설계 시스 도 부담되기는 마찬가지이다. 각 소프트웨어 모듈은 마이크로컨 템을 사용하려면 내부 마이크로컨트롤러를 16비트에서 32비트 트롤러 RAM과 ROM의 자원을 상당 부분 차지할 뿐만 아니라 함 프로세서로 업그레이드해야 한다는 오해가 생겨났다. 기존의 수들의 스케줄 및 호출에는 상당한 양의 프로세서 런타임 오버헤 OSEK OS를 스케줄 표 기능만 활용하는 AUTOSAR OS SC1으로 드가 존재한다. 교체하기 위해서는 최소한의 추가 오버헤드만 발생하게 되므로 이와 같은 결론은 옳지 않다. The AUTOSAR Operating System AUTOSAR 고속 태스크 스케줄링 기능 특히 AUTOSAR 운영체제는 지금까지 이용 불가능했거나 ECU 공 또한, 이제 소프트웨어 개발자는 베이직 소프트웨어 구성 설정에 급업체에 의해 고려되지 않았던 훨씬 많은 기능을 제공한다. 과 서 간단히 타이밍 및 메모리 프로텍션 기능을 선택해 운영체제를 AUTOSAR 시스템의 고속 어플리케이션 태스크 스케줄링 기능에 대한 고찰 거에는 단일 틱이나 슈퍼 루프 스케줄러가 모든 ECU 어플리케이 업그레이드할 수 있는 옵션을 가진다. 해당 기능을 개발하는 데 오늘날 차량 내부의 전기·전자(E/E) 기능은 그 수와 복잡성이 급격히 증가하고 있다. 새로운 수준에 도달한 복잡성은 완성차 업체와 션 태스크를 관리하였다. 이제는 AUTOSAR 운영체제의 선택적 에 소요되는 시간은 더 이상 방해요인이나 심지어는 고려대상도 공급업체로 하여금 AUTOSAR 파트너십을 형성하여 ECU(Electronic Control Units)의 표준 및 다양한 기능의 소프트웨어 설계를 기능 포함으로 소프트웨어 개발자들은 새로운 운영체제 기능을 되지 않는다. AUTOSAR OS가 상용 규격품 컴포넌트로 사용 가능 구현하도록 주도하고 있다. 일반적으로 AUTOSAR 시스템에서는 고속 어플리케이션 태스크를 스케줄링할 수 없다는 오해가 있다. 즉시 사용할 수 있게 되었다. 해졌기 때문이다. 모든 AUTOSAR 베이직 소프트웨어 모듈이 비 본 기사에서는 AUTOSAR 운영시스템에서 다양한 어플리케이션 스케줄링 요구사항을 처리할 수 있는 메커니즘과 함께 소프트웨어 AUTOSAR OS는 SC1에서 SC4까지 확장되는 ‘확장 클래스(Scal 슷한 방법으로 처리되면 AUTOSAR의 새로운 기능 또한 기술적 개발자로 하여금 AUTOSAR 시스템에서 고속 태스크 스케줄을 성공적으로 계속 실행해 나갈 수 있도록 해 주는 운영체제 구성을 ability Classes)’ 범위를 제공한다. 으로 손쉽게 추가할 수 있다. 하지만 프로세서 부하량 및 메모리 설명하고자 한다. 요구사양에 상당한 영향을 주는 점은 고려해봐야 할 사항이다.
AUTOSAR 드라이버 소프트웨어 기능 그리고 메커니즘과 지원서비스를 제공하는 것 최근 차량 내부 전기·전자(E/E) 기능의 숫자와 복잡성은 기하급수 이다. 적으로 늘어나고 있다. 이러한 추세는 최종 고객이 전기·전자 기 반의 기능을 요구하는 사례의 증가, ADAS 시스템의 출현 및 확 AUTOSAR가 출범하기 전, 완성차 업체들의 ECU 임베디드 소프 산 그리고 전기·전자 시스템과 ECU의 오류 진단에 대한 법제화 트웨어 개발상 주요 초점은 네트워크 통신스택 및 진단에 한정되 요구 증가 등 자동차 산업 내 여러 가지 요인에 의해 발생하고 있 어 있었다. 그러나 AUTOSAR에서 개발한 “AUTOSAR 베이직 소프 다. 트웨어”는 CAN, LIN, FlexRay, Ethernet 및 진단 프로토콜을 위한 최신 자동차에 적용되는 기능들은 차량 전기·전자 설계로 인해 네트워크 통신뿐만 아니라 시스템 및 워치독 초기화와 상태 처 기존의 자동차 ECU 기능과 공급업체들의 개발기술로는 더는 따 리, 다양한 비휘발성 메모리를 위한 소프트웨어 스택, 마지막으 라갈 수 없는 수준에 도달했다. 2003년 당시 이러한 기능들의 복 로 마이크로컨트롤러 주변기기를 위한 드라이버 레이어 및 운영 잡성이 증폭되고 있는 가운데 일부 완성차 업체와 협력업체들이 체제(OS)와 같은 영역까지 그 영향이 확장되고 있다. AUTOSAR(AUTomotive Open System ARchitecture)라는 개발 협 력관계를 형성했다. 이들의 상호 목표는 차량 ECU에서 사용될 일 AUTOSAR, 증가된 처리량 “달콤한 사탕 가게” 반적이며 표준화된 소프트웨어 아키텍처를 정의함으로써 궁극 AUTOSAR 표준은 최신 차량의 전기·전자 요구사항을 충족시키기 적으로 전기·전자 설계에 더욱 높은 요구사항을 충족하는 다양한 위해 지속적인 성장과 진화를 겪고 있다. 2014년 말 AUTOSAR의 그림 1: AUTOSAR OS 확장 클래스 베이직 소프트웨어 4.2 버전이 출시되었을 당시 고도의 복잡성이
7/32 7/33
6/2 Steve Waldron, Vector GB Ltd. 임베디드 소프트웨어 제품라인부 지역제품라인 담당 매니저 고속 어플리케이션 태스크 스케줄링 CAT1 인터럽트는 하드웨어와 직접 상호 작용 가능한 강력한 방 하지만 이러한 요구사항을 처리하는 메커니즘 또한 이미 AUTO AUTOSAR 소프트웨어 설계에 기본적으로 32비트 프로세서가 필 법을 제공하므로 이러한 유형의 인터럽트를 이용하는 경우에는 SAR 표준에서 검토되고 있으며 여러 많은 AUTOSAR 어플리케이 요하다는 것과 유사한 오해가 또 한가지 있다. AUTOSAR 시스템 각별한 주의를 기울여야 한다. 주요 장점은 인터럽트 대기 시간 션이 OS Cat1 인터럽트를 사용하여 스케줄링함으로서 성공적으 내에서는 고속 어플리케이션 태스크 스케줄링이 불가능하다는 이 매우 짧으므로 필요한 고속 태스크 스케줄링을 달성할 수 있 로 고속 태스크를 구동 하고 있다. 아울러 벡터는 시스템 내 프로 것이다. 여러 차량 어플리케이션, 특히 파워트레인 영역 내에서 다는 것이다. 하지만 AUTOSAR OS이 제공하는 정상적인 보호기 세서 부하량 분석을 통해 다양한 기능을 지닌 AUTOSAR 베이직 Tom Dalek, Vector GB Ltd. 는 매 100마이크로 초(10kHz)의 속도로 작업이 실행된다. 이렇게 능이 아직 존재하지 않기 때문에 CAT1 인터럽트 내의 나머지 소프트웨어를 실행하는 동안에도 고속 태스크 스케줄링이 가능 임베디드 소프트웨어부 소프트웨어 개발자 도전적인 수준의 스케줄링 요구사양은 AUTOSAR OS에 매우 높 시스템 부분과의 상호작용은 구현하기 전 신중하게 고려되어야 하다는 것을 발견했다. 은 부담을 부여하고 이에 따라 마이크로컨트롤러의 처리 부하량 한다. 이 상당히 증가하게 되는 것은 분명하다. 그러나 AUTOSAR 베이직 소프트웨어 및 AUTOSAR OS가 제공하 또 다른 고려사항은 시스템 전반에 걸친 인터럽트에 우선순위를 고 있는 추가 기능은 프로세서에 더 큰 부하를 가져올 것이고 이 이러한 문제를 해결하기 위해 AUTOSAR OS는 다음과 같이 두 가 할당하는 것이다. AUTOSAR OS는 선점형 운영체제이기 때문에 로 인해 새로운 차별화가 임베디드 소프트웨어 시장에 등장했다. Alex Ghinet, Vector GB Ltd. 지 유형의 인터럽트 ‘카테고리’를 제공하고 있다. AUTOSAR 어플리케이션 작업은 서로를 방해할 수도 있다. 하지 제품화된 AUTOSAR 베이직 소프트웨어를 사용할 때 각 새로운 임베디드 소프트웨어 수석 소프트웨어 개발자 > CAT1 인터럽트는 AUTOSAR OS에 의해 ‘지원되지 않는다.’ 즉 만 AUTOSAR 태스크가 고속 태스크를 방해하거나 차단을 허용 AUTOSAR 모듈의 확장성, 설정 가능성, 효율성 및 최적화를 고려 인터럽트 핸들러 안팎으로 안전하게 드나들기 위한 코드가 하는 것은 용납되지 않으므로 우선순위를 할당해 고속 태스크가 해야 한다. AUTOSAR OS에 의해 생성되지 않으며 다른 방식으로 생성되 시스템에서 가장 높은 우선순위를 갖도록 해야 한다. 즉 고속 태 어야 함을 의미한다. [1] 스크는 AUTOSAR OS를 포함해 시스템 내 어떠한 다른 작업도 방 AUTOSAR 도입에 앞서 많은 ECU 공급업체는 도입이 초래할 여 > CAT2 인터럽트는 OS에서 지원된다. 이는 OS의 코드 생성기 해할 수 있음을 의미한다. 또한 AUTOSAR 시스템 내 모든 다른 러 복잡성에 대해 우려를 하지만 이러한 복잡성은 최종 고객이 와 라이브러리가 이식 가능한 방법으로 하드웨어로부터 인터 인터럽트는 고속 작업보다 최소 한 단계 낮은 우선순위를 가져야 요구하는 기능 조건 및 이러한 기능을 지원하는 데 필요한 기본 럽트를 추상화해야 한다는 것을 의미한다. [1] 하며 이를 ‘시스템 인터럽트 레벨’이라고 부른다. 전기·전자 설계 구성 시스템에 이미 존재하고 있다. AUTOSAR는 단지 이미 존재하는 복잡성을 관리하는 데 필요한 메커니즘과 구 CAT2 인터럽트는 일반적으로 AUTOSAR 모듈이 AUTOSAR OS와 결론 조를 제공하고 있다. 따라서 AUTOSAR 시스템 자체를 문제로 간 API (어플리케이션 프로그래밍 인터페이스)를 사용하도록 지정 AUTOSAR 표준은 이미 새로운 수준에 도달했지만 오늘날 최신 차 주하기보다는 해결방안을 제공하는 솔루션으로 봐야 한다. 된 베이직 소프트웨어와 어플리케이션 소프트웨어의 모든 태스 량의 전기·전자 요구사항을 충족시키기 위해 지속적으로 성장하고 크를 스케줄링하기 위해 사용된다. 어플리케이션이 특정 고속 태 진화할 것이다. 어플리케이션 기능 향상을 위한 AUTOSAR 시스템 스크 스케줄링 요건을 갖는 경우, 소프트웨어 개발자는 AUTO 적용이 완성차 업체에 의해 요구될 경우 ECU 소프트웨어 개발자 이미지 권리: SAR CAT1 인터럽트를 활용할 수 있으며 설정툴을 사용해 어플 에게 큰 부담으로 다가온다. 모든 AUTOSAR의 새로운 Vector Informatik GmbH / Vector GB Ltd. 리케이션 태스크를 마이크로컨트롤러의 인터럽트 테이블에 직 기능뿐만 아니라 고속 태스크 스케줄링 요구 처리에 관한 우려로 접 추가 할 수 있다. CAT1 인터럽트는 AUTOSAR 시스템의 나머 인해 AUTOSAR 아키텍처의 파워트레인 영역으로의 확산은 기타 참고문헌: 지 부분에는 본질적으로 “보이지 않는다.” 다른 영역 (예: 보디 및 섀시 어플리케이션) 에 비해서 느린 편이다. [1] Explanation of Interrupt Handling in AUTOSAR, sourced from www.autosar.org on 09/07/2015: www.autosar.org/filead min/files/releases/3-2/software-architecture/general/auxiliary/ AUTOSAR_InterruptHandling_Explanation.pdf
링크: Website Vector: www.vector.com Vector AUTOSAR Solution: www.vector.com/autosar/
그림 2: AUTOSAR 시스템 내 고속작업 스케줄링 예시
7/34 7/35
6/4 8/0 8/1 8/2 8/3 컴포넌트에 대한 간섭 배제는 보편화된 검증 방식인 코드 리뷰 위해 사용된다(그림 1). MICROSAR OS SafeContext를 보완하는 이 (code review) 등으로 검증할 수 있다. BSW(basic software)의 간 모듈은 ASIL D 등급을 받은 TTTech Automotive사가 개발한 Safe- 섭 배제를 확인하기 위해 특별히 개발한 코드 체커를 사용하는 Watchdog를 통해 가능하다[3]. 이름이 말해주듯이 이 컴포넌트는 방법도 있다[2]. 또한, 하드웨어와 관련된 문제로부터 소프트웨어 Watchdog 하드웨어를 제어하며, 오류 발생 시 ECU를 안전하게 리 를 보호하기 위한 다른 여러 방법도 있다. 셋한다. 또한, 이 컴포넌트는 어플리케이션 작업의 정확한 시간 흐 름을 모니터링한다. 개발자들은 프로그램 흐름이나 사이클 타임, MICROSAR OS SafeContext와 같은 최신 AUTOSAR OS는(그림 최대/최소 실행시간 등을 모니터링할 수 있도록 다양한 파라미터 1) 메모리 콘텐츠의 덮어쓰기 오류를 방지하기 위한 보호 기능을 값을 설정할 수 있다. 제공한다. 이러한 보호 조치는 각각의 기능 그룹을 OS 어플리케 이션으로 분할함으로써 이루어진다. 각 OS 어플리케이션의 데이 안정적인 통신을 위한 간섭 배제의 세 번째 요건은 단대단(end- 터는 별도의 메모리 파티션(Memory partition)에 할당된다. 어플 to-end) 보호를 통해 충족시킬 수 있다(그림 1). AUTOSAR에 규 리케이션 데이터와 함께 스택이나 레지스터 컨텐츠와 같은 컨텍 정된 E2ELib [4]의 도움을 받아 SafeCOM제품은 CRC와 메시지 스트 관련 데이터도 이러한 메모리 파티션에 할당된다. 메모리 시퀀스 번호(sequential message number)를 이용해 전송할 데 파티션에 대한 액세스는 MPU(Memory Protection Unit)에 의해 이터를 보호할 수 있다. 엄밀히 말하면, 이러한 조치가 안전한 통 차단되는데, 이 MPU는 마이크로프로세서 하드웨어의 한 부분이 신을 보장하는 것은 아니지만, 통신의 “무결성(integrity)”만큼은 다. 보장할 수 있다. 소프트웨어는 버스 라인 파손 등과 같은 하드웨 어 문제로 인한 데이터 오류를 보호할 수 없다. 안전한 통신을 보 OS는 현재 실행 중인 작업이나 인터럽트 서비스 루틴(Interrupt 장하기 위해서는 버스를 이중화하는 등의 하드웨어에 대한 추가 Service Routine)을 전환할 때 컨텍스트 전환을 한다. 여기서 컨 적인 조치가 필요하다. 텍스트 데이터는 저장되며, MPU는 전환 후 활성화되어있는 작 업 또는 인터럽트 서비스 루틴의 메모리 파티션만 사용할 수 있 어플리케이션과 OS의 통합 도록 재구성 된다(그림 2). 이러한 작업 전환은 OS에서만 실행되 ISO 표준에서, 외부 공급업체들이 개발하여 ECU 제조업체에 공 며, 안전과 관련되어 있다. MICROSAR OS SafeContext는 ISO 급하는 안전 관련 컴포넌트들은 “SEooC(Safety Elements out of 26262의 ASIL-D 에 정의된 프로세스에 따라 개발되었으며 ASIL Context)”라고 불린다. 여기에 포함되는 것은 앞에서 언급한 운 D 등급을 만족한다는 것이 입증된 OS이다. 영 시스템과 Watchdog 관리자, E2ELib 등이다. 개발이 진행되는 혼합형 ASIL 시스템의 성공적인 구현 동안, 이러한 컴포넌트의 공급자들은 ECU 프로젝트에 대한 기본 포괄적인 검증 컨셉 지식을 배제하고 예상되는 안전 목표에 대한 가정을 해야 한다. 검증된 OS를 통한 안전 관련 소프트웨어 개발 간소화 I안전 관련 시스템에서는 프로그램 흐름을 모니터링하는 것이 중 따라서 ECU 개발자들은 통합 작업의 일환으로 제공받은 SEooC 에 대해 가정한 안전 목표가 해당 프로젝트의 안전 목표를 달성 ISO 26262는 자동차 산업에서 안전 관련 ECU 개발 시 준수해야 할 표준 프로세스를 규정한다. 그러나 안전과 관련된 ECU에 내장된 요하다. AUTOSAR에 규정된 Watchdog Manager는 이러한 목적을 소프트웨어에서 실제로 안전과 관련된 부분은 일부에 불과하다. 따라서 안전 관련 컴포넌트를 개발하는 데 있어 불필요한 노력을 줄이는 방안이 필요하다. 첨단 AUTOSAR OS와 두 개의 BSW(basic software) 모듈을 이용하면 ASIL 기능과 인증받지 못한 기능 모두를 포함하면서 ISO를 준수하는 혼합형 ASIL 시스템을 만드는 것이 가능하다.
안전 관련 ECU 소프트웨어를 개발함에 있어 ISO 26262 표준 준 tional groups)이 서로 간섭할 수 없도록 격리되기 때문에 특정 수의 중요성이 날로 커지고 있다. 이 표준에 부합하기 위해서는 ASIL에 필요한 개별 기능 그룹에 대한 개발 노력을 줄일 수 있다. 개발자가 개발 프로세스 초기에 개발 중인 시스템의 HARA(Haz- 이는 ECU 제조업체의 별도 개발이 필요 없는 AUTOSAR OS 및 ard Analysis and Risk Assessment)를 평가해야 한다. 개발자는 두 개의 BSW(basic software) 모듈을 통한 보호 메커니즘을 통해 안전 목표를 설정하고, 각각의 목표에 대해 오류 발생 가능성, 그 가능하다. 에 따른 피해 심각도, 결함이 발생한 경우 운전자가 차량을 제어 할 수 있는 능력 등을 바탕으로 A등급에서 D등급까지의 ASIL(Au- 기능 안전 컨셉 tomotive Safety Integrity Level)을 지정해야 한다. 개발자들은 전반적인 시스템이 안전에 대한 요구사항을 충족시 키는지 확인해야 한다. 시스템의 모든 소프트웨어 컴포넌트는 안 모든 소프트웨어 요소에 대해 ASIL을 지정하게 되면 대게 각각의 전 요구사항을 충족해야 하며, 안전 관련 기능이 없는 소프트웨 기능 그룹에 대해 서로 다른 ASIL 등급이 지정되는 문제가 발생 어 컴포넌트는 간섭 배제(freedom from interference)의 원칙을 한다. 원칙적으로는 ECU 한 개에 들어가는 모든 소프트웨어에 대 반드시 따라야 한다([1] Part 9, section 6.4). 해 가장 높은 ASIL 등급을 받은 기능 그룹의 등급에 준해 개발해 소프트웨어 컴포넌트의 간섭 배제는 다음과 같은 세 가지 특징으 야 한다. 이럴 경우, 안전과 관련되지 않은 소프트웨어도 안전 프 로 정의된다 로세스상 최고의 요구사항에 맞추어 개발해야 하므로 엄청난 개 발 비용과 시간이 요구된다. > 안전한 메모리 접근(Safe memory accesses) 이러한 문제점은 혼합형 ASIL 시스템을 사용함으로써 극복할 수 > 정확한 시간 실행(Correct time execution) 그림 1: AUTOSAR 아 키텍처에서의 보호 매 있다. 적절한 보호 기준(Safety measure)으로 기능 그룹(func- > 안전한 데이터 교환(Safe data exchange) 커니즘 레이아웃
8/4 8/5
6/2 하는데 충분한지 반드시 확인해야 한다. 뿐만 아니라, ECU 개발 독일 출판물 Elektronik automotive의 특별 부록 “Funktionale 자는 공급된 소프트웨어 모듈에 대해 특별 통합 지시를 내려야 Sicherheit” 2013년 7월호 기사 번역판 할 책임이 있다. 이를 위해 각각의 SEooC는 안전 매뉴얼과 함께 제공되며, 이 매뉴얼에는 안전 목표에 대한 통합 지시와 가정이 이미지 권리: 함께 실려 있다. Vector Informatik GmbH
언뜻 보면 작업이 더 많아지는 것처럼 보일 수도 있다. 그러나 더 참고문헌: 자세히 살펴보면 자체적으로 개발한 컴포넌트들을 통합하는 것 [1] ISO 26262 - Road Vehicles - Functional Safety, 2011 과 비슷한 수준의 노력만 필요하고, 컴포넌트를 공급받기 때문에 [2] G. Heling, J. Rein and P. Markl, “Koexistenz von sicherer and 이를 만들기 위한 노력은 전혀 들지 않는다는 장점이 있다. 오히 nicht-sicherer Software auf einemSteuergerät” (“Coexistence of 려 전체적으로 보면, 이를 통해 작업량을 크게 줄일 수 있다. safety and non-safety software in one ECU”), ATZ special elec- tronics issue of electronica, pp. 62-65, November 2012 전망 [3] AUTOSAR, “Specification of Watchdog Manager” V2.3.0 벡터(Vector)가 개발한 TMS570 마이크로컨트롤러용 MICROSAR [4] AUTOSAR, “Specification of SW-C End-to-End Communica- OS SafeContext가 TÜV Nord의 인증을 받으면서, ASIL D 인증을 tion Protection Library” V3.0.0 받은 최초의 AUTOSAR OS가 되었다. 이러한 구현은 현재 다른 플랫폼에서도 진행되고 있으며, 점차 그 사용이 늘고 있는 멀티 링크: 코어 프로세서도 포함된다. 벡터 홈페이지: www.vector.com SafeWatchdog 및 SafeCOM 과 함께 사용하는 MICROSAR OS MICROSAR Safe 제품 정보: www.vector.com/vi_microsar_safe_26262_ SafeContext 는 안전 관련 ECU개발에 안전하고 최선의 환경을 en.html 제공한다. 특히, 이러한 방법은 혼합형 ASIL 시스템을 효과적인 비용으로 구현하는 데 사용할 수 있다. Steffen Keul (Dipl. Computer Science) 벡터 인포매틱(Vector Informatik)에서 현재 제품 관리 엔지니어로 근무하고 있으며, 기능 안전 관련 분야를 담당하고 있다. 어플리케이션을 보호하는 것 이외에도 이 안전 프로세스는 모든 BSW를 보호해야 한다. 이와 관련해 벡터는 ISO 26262을 준수하 여 개발한 별도의 제품을 제공한다. 특히 이 제품은 “메모리 액세
스와 관련된 간섭 배제” 라는 안전상의 목표를 달성할 수 있다는 Dr. Helmut Brock (Doctor of Engineering) 점에서 차별화된다. 벡터 인포매틱(Vector Informatik)에서 운영 체제(Operating system) 제품 매니저로 근무하고 있다.
그림 2: 하드웨어에서 MPU는 권한이 없는 액세스로부터 메모리 파티션을 보호한다. MPU의 재구성은 OS를 통해 이루어진다
8/6 어에서 구현되고, 소프트웨어 개발 시에도 접근할 수 있어 아주 에 대해 타이밍 보호는 고장 허용 향상에 적합한 안전 메커니즘 효율적인 솔루션이라 할 수 있다. 이 된다. 타이밍 보호기능으로 소프트웨어 컴포넌트 무한루프와 같은 본래 기능의 실행을 방해하는 결함을 방지할 수 있다. 타이 개발자는 보통 어플리케이션에 추가 메커니즘을 구현하여 기능 밍 보호에서 개발자는 태스크 및 인터럽트 루틴의 수행시간과 인 모니터링을 수행한다. 여기에는 리미터(limiters), 프로그램 플로 터럽트 및 리소스에 의한 차단시간에 대해 시간 예산을 할당할 우 모니터링(logic 모니터링)뿐만 아니라 센서 및 액추에이터 모 수 있다. 각 태스크 간, 인러텁트 루틴 간의 시간 간격 역시 모니 니터링도 포함된다. 예를 들어, 프로그램 플로우 모니터링은 AU- 터링된다.(그림 2) 고장이 발생하면 AUTOSAR 운영체제가 고장 TOSAR 워치독으로 수행할 수 있다. 을 유발한 태스크나 인터럽트 루틴을 중단시켜 추가적인 실행이 되지 않도록 배제할 수 있다. 하지만 이러한 타이밍 보호는 향후 기능 모니터링과 마이크로컨트롤러 무결성은 특정 프로젝트별 필요한 고장 허용 시스템을 향한 첫걸음일 뿐이다. 로 정의되고 구현된다. 그러나 안전과 관련된 거의 모든 ECU에 사용되며 기능 및 ASIL과 독립된 메커니즘도 존재한다. ASIL 소 고장 허용 시스템 아키텍처 프트웨어가 탑재된 ECU는 대부분 QM 소프트웨어를 실행한다. 우주항공 산업에서는 고장 허용 시스템 아키텍처를 오랫동안 사 ISO 26262에 의거하여 ASIL 소프트웨어와 QM소프트웨어가 공 용했다. 절대적으로 안전을 기해야 하는 항공 제어에서는 세 가 존하기 위해서는 메모리 분할과 시간제한 모니터링이 필요하다 지 또는 네 가지 ECU가 중복으로 이용되어 복잡한 시스템을 이 [1]. 메모리 분할은 요구되는 ASIL과 함께 MPU(Memory Protec- 룬다. 물론 하드웨어에서 이렇게 기능을 중복시키는 것은 상당히 tion Unit)을 제어하는 AUTOSAR OS SC3로 구현된다. 워치독은 큰 비용을 발생시킨다. 따라서 자동차 산업에 고장 허용 시스템 데드라인 모니터링에 따라 시간 요건 모니터링을 처리한다. ECU 을 적용할 때는 새로운 방법을 사용해야 한다. 위험평가단계시 사이에 안전과 관련된 데이터가 교환되는 경우, 통신 보호가 필 고장으로 인한 위험도가 상대적으로 낮은 것이 자동차 산업의 이 요하다. AUTOSAR는 이를 위해 종단 간 보호(E2E Protection)의 점이다. 형태로 효과적인 안전 메커니즘을 제공한다. ASIL D까지 인증된 적용가능한 시스템 아키텍처(그림 3)는 항상 최소 두 개의 채널 벡터의 제품을 통해 이와 같은 종합적인 측정을 구현할 수 있다. 로 이루어진다. 이 예에서 하나의 채널은 센서, 로직 유닛, 액추에 이터가 구성된다[4]. 한 채널의 마이크로컨트롤러가 고장 나면 고장 허용 시스템으로의 전환 연결된 소프트웨어와 그 기능에도 분명 고장이 발생한다. 마이크 향후 미래의 모습은 과연 어떻게 될 것인가? 오늘날의 하드웨어는 비용상의 이유로 중복된 기능이 거의 없이 로컨트롤러는 복잡하기 때문에 ECU에서 고장률이 가장 높은 경 설계된다. 따라서 하드웨어의 결함은 심각한 기능 저하를 초래하 우가 많다. 그러므로 아주 짧은 시간 동안이라도 기능이 완벽히 AUTOSAR Basic Software를 이용한 고장 허용(Fault tolerant) 시스템 아키텍처 구현 며, 전체적인 고장을 일으킨다. 다른 한편으로는, IEC 62380과 실행된다는 보장이 없다. SN29500에서 정의된 것과 같이 표적 고장률을 예상하여 하드웨 이러한 이중 채널의 시스템을 고장 허용 시스템으로 만들기 위해 높은 수준의 자율주행은 기존의 안전 컨셉과 비교해 새로운 사양이 요구된다. 이제 안전 상태(safe state)에 도달하는 데 단순히 어 어 고장을 정량화하는 방법이 있다[2]. 서는, 각 채널에서 모든 개별적인 에러를 감지하여야 하고, 각각 느 기능을 비활성화하는 것만으로는 충분치 않다. 향후의 안전 상태에서는 동작과 기능을 요구하게 될 것이다. 본 기사는 이에 필요 소프트웨어의 결함은 전적으로 시스템적인 오류이기 때문에 소 을 패시브 모드로 전환할 수 있어야 한다[5]. 이러한 요구 사양이 한 메커니즘과 그것이 어떻게 모듈 단위로 결합하여 효율적인 안전 상태를 확보하는지를 보여준다. 또한, 미래의 고장 허용 시스템 프트웨어 고장은 정량화하기가 쉽지 않다[3]. 소프트웨어의 결함 없다면, 기능의 안전한 동작을 위해 양쪽 채널이 항상 필요로 하 이 맞이하게 될 도전에 대한 인식의 필요성과 AUTOSAR를 통해 그 도전을 효율적으로 극복할 수 있음을 설명하였다.
오늘날 차량의 안전 시스템에서 고장에 대처하는 데 가장 많이 고장 침묵 시스템의 모듈형 안전 개념 쓰이는 방법은 고장이 난 기능을 비활성화시키거나 리셋하는 것 안전 엔지니어는 모듈 개념을 이용하여 다양한 안전 메커니즘을 이다. 이것을 고장 침묵(fail-silent)이라고 한다. 이 솔루션은 효율 특정 프로젝트에 효율적으로 조정해 활용한다(그림 1). 이 그림 적으로 안전 상태에 도달하고 유지할 수 있으며 구현이 용이하 은 마이크로컨트롤러의 무결성 감지 방안, 기능 관련 모니터링 다. 그러나 차량 E/E 시스템에서 마이크로컨트롤러 결함과 같은 방안, 전반적인 기능 안전 방안에 대한 대략적인 차이를 보여 고장이 난 경우에도 작동을 보장해야 하는 기능들이 많아지고 있 준다. 다. 이를 fail-operational이라고 하며 본문에서는 고장 허용 (fault-tolerant)이라고 칭한다. 앞으로 차량의 고장 허용 시스템 마이크로컨트롤러의 무결성을 확보하기 위한 방안은 소프트웨 수요가 상당히 늘어날 것이다. 예를 들어, 중형 SUV에는 운전자 어의 가장 높은 ASIL(Automotive Safety Integrity Level)에 맞게 가 조향을 안전하게 제어할 수 있도록, 조향보조 시스템(steering 선택된다. 이것은 ECU가 수행할 다른 기능과 독립되며, 해당 assist systems)을 동작 상태로 유지해야 한다. 고장 침묵(fail-si- ASIL에 요구되는 진단 커버리지(DC)에 따라 결정된다. lent) 시스템 개발은 ISO 26262를 통해 상당히 잘 이루어졌지만, 마이크로컨트롤러 제조업체는 자체적인 안전 분석을 기반으로 고장 허용 시스템의 설계 문제는 ISO 26262만으로는 해결하기 특정 요구 사양을 정하는 경우가 많다. 예를 들어, ASIL D의 DC 어렵다. 특히 안전 상태를 정확히 정의하는 것부터가 골칫거리이 는 소프트웨어에 의해 주기적으로 실행되는 내장 자체 테스트 다. 2017년이나 2018년에 발표될 ISO 26262 제2판 역시 이를 명 (BITs)를 요구한다. 일반적으로 ASIL B등급 이상은 이른바 SEU(S- 확히 하지는 못할 것이다. 본문에서는 표준 사양의 요구 이외에 ingle Event Upset)의 발생 가능성을 반드시 고려해야 한다. 마이 AUTOSAR 기술을 통해 기존의 안전 개념이 어떻게 고장 허용 시 크로컨트롤러의 락스텝 모드와 메모리 ECC 기능이 SEU에 대한 스템으로 확장되는지 보여줄 것이다. 효과적인 보호 대책을 제공한다. 두 안전 메커니즘 모두 하드웨 그림 1: 특정 프로젝트에서 모듈 개념이 효율적인 안전 메커니즘 관리를 가능하게 한다.
8/8 8/9
6/2 Is This What the Future Will Look Like?
> 기존 메커니즘 활용: 중복 채널의 소프트웨어를 구현함에 있 전망 어서, 다양성과 동질성의 두 가지 철학이 있다. 다양성 측면에 현재에도AUTOSAR를 사용하여 안전 관련 프로젝트를 효율적으 서는 양쪽 채널에 서로 다른 소프트웨어를 적용한다. 같은 방 로 구현할 수 있다. E/E 시스템에서 고장 허용의 증대가 요구된다 식의 채널과 동일한 마이크로컨트롤러인 경우에는, 같은 소프 면, 마이크로컨트롤러의 고장도 처리할 수 있는 새로운 시스템 트웨어를 사용하되 각 채널에 대해 파라미터만을 달리하여 적 아키텍처가 필요할 것이다. 이는 어플리케이션과 베이직 소프트 용할 수 있다. 이는 AUTOSAR에서 ECU 베리언트 개발에 사용 웨어에 대한 새로운 도전이다. 그럼에도 불구하고 AUTOSAR 개 되는 방법인, Post-Build Selectable 메카니즘을 사용할 수 있 발 방법론을 이용하여 이러한 시스템의 복잡성을 극복할 수 있 다. 동일 타입의 채널을 사용하기 위해서는 동일한 원인에 대 다. 다양하게 설정가능한 AUTOSAR 베이직 소프트웨어의 설정가 한 에러를 검사하는 것이 요구된다.[7] 능성은 훌륭한 출발점을 제공한다. 관련된 툴로 필요한 중복성을 용이하게 관리할 수 있다. 고장 발생 시 다른 채널로 신속히 제어권을 전환하기 위해서는 채널의 상태 정보, 센서와 액추에이터 값이 두 채널 사이에 교환 앞으로 베이직 소프트웨어 및 툴에 의한 지원이 더욱 개선될 것 되어야 한다(그림 4). AUTOSAR에서는 두 채널에 대한 베이직 소 프트웨어의 설정을 하나의 설정으로 구현하는 것이 가능하다. 개 이다. 그러나 고장 허용 시스템을 구현하는 첫 단계로 시스템 아 발자는 소프트웨어 컴퍼넌트(SWC) 형태로 채널 전환 어플리케 케텍처에 대한 새로운 접근 역시 필요하다. 그림 2: AUTOSAR의 시간 관리(timing protection) 기능을 통해 할당 시간을 초과하는 작업을 조기에 탐지하고 수정할 수 있다. 이션을 구현하거나, AUTOSAR의 유연한 BswM(Basic Software Mode Manager)과 EcuM(ECU State Manager)의 설정을 통해 명 시적으로 구현할 수 있다. 현재는 각 어플리케이션에 특화된 소 게 된다. 하지만 이러한 경우, 고장률은 기대하는 것처럼 절반으 를 어떻게 제어하는가와 같은 문제 등이 있다. 네트워크에서 데 프트웨어가 채널 간에 오류 상태를 교환하는 데 이용되고 있지 로 줄지 않고 두 배가 된다. 물론 이 시스템 아키텍처는 관련된 이터 일관성을 평가하는 것(“비잔틴 장군 문제”[6])도 필요하다. 만, 앞으로는 이러한 기능을 수행하는 베이직 소프트웨어를 표준 EUC와 중복 통신 경로가 필요하듯이 중복으로 에너지를 공급해 시스템 아키텍처 관점에서 이러한 복잡성은 상시 대기 모드를 이 화할 수 있을 것이다. 야 한다. IEC 61508 표준은 그러한 시스템을 1oo2D(1-out-of-2 용하여 줄일 수 있다. 이 경우 두 채널 중 하나만이 특정 시점에 with diagnostics)으로 부르고 있다 액추에이터를 제어한다. 이 채널에 오류가 발생하면 다른 채널이 툴 지원 즉시 제어권을 가진다. 다음과 같은 이유로 AUTOSAR 베이직 소 향후에 가중될 복잡성을 극복하기 위해서는 개발 초기 단계부터 고장 허용 시스템에 대한 AUTOSAR 소프트웨어 아키텍처 프트웨어(그림 4)를 이용하여 어플리케이션 개발 프로세스를 단 효과적이고 종합적인 툴 지원이 필요하다. 엔지니어들이 어플리 원칙적으로 하드웨어를 중복으로 장착하면 어플리케이션 또한 순화할 수 있다 케이션 개발에 집중할 수 있게 되므로, 시스템 모델에서 중복된 복잡해진다. 이는 제어공학의 새로운 도전으로, 중복 컨트롤러가 > 재사용: 개발자는 모듈형 안전 컨셉을 확보하기 위해 앞에서 신호의 일관성을 일일이 확인하는 업무와 같은 지루하고 오류가 동시에 활성화될 때 컨트롤러의 안정성을 유지하고 액추에이터 제시한 AUTOSAR 컴포넌트를 오류 감지 목적으로 재사용할 자주 발생하는 작업에 대한 부담이 줄어들 것이다. 수 있다.
그림 4. AUTOSAR에 기초한 고장 그림 3: 중복 설계로 구현되는 고장 허용 시스템에 사용되는 MICROSAR 허용 시스템 아키텍처의 예 소프트웨어 아키텍처
8/10 8/11
6/4 2015년 11월 엘렉트로니크 오토모티브(Elektronik automotive) 독일어판 번역
이미지 권리:: Vector Informatik GmbH
참고문헌: [1] Definition of the fault tolerant time interval (FTTI) in ISO 26262-1, 1.45 [2] ISO 26262-5:9 Evaluation of safety goal violations due to random hardware failures [3] ISO 26262-10:4.3 Relationship between faults, errors and failures [4] Definition of a system in ISO 26262-1, 1.129 [5] ISO 26262 Single-point fault metric (SPFM) for ASIL D [6] The Byzantine Generals Problem, L. Lamport et al, ACM Transactions on Programming Languages and Systems, 1982 [7] Definition of a Common Cause Failure in ISO 26262-1, 1.14
링크: 벡터 홈페이지: www.vector.com MICROSAR 제품 정보: www.vector.com/microsar
Jonas Wolf (Dipl. Ing.), Vector 슈투트가르트 대학에서 항공 우주 공학 학위를 받았다. 2012년에 벡터 에 입사했고, 현재 기능 안전 및 사이버 보안 시니어 제품관리 엔지니어 로 근무 중이다. ECU 및 차량 네트워크의 보안 개발
벡터의 차량 사이버 보안 솔루션
벡터가 제공하는 포괄적인 보안 솔루션(소프트웨어 툴, 임베디드 컴포넌트, 엔지니어링 서비스)의 이점을 활용해 보다 효율적으로 보안 관련 제어기를 개발하십시오.
> 보안 테스트 솔루션 - 제어기 및 네트워크 보호 > 보안 엔지니어링 및 메커니즘에 대한 컨설팅 및 보안 > Fuzz-Testing을 통한 효율적인 보안 메커니즘 테스트 컨셉 개발 서비스 제공 > 보안 요구사항 구현을 위한 효율적이고 설정 가능한 AUTOSAR 베이직 소프트웨어 > ECU 소프트웨어 업데이트 보안을 위한 플래시 부트로더 자세한 정보: www.vector.com/security_ko
벡터는 차량 내 통신 및 외부 네트워크 연결 시 발생할 수 있는 보안 문제와 관련한 다양한 솔루션을 지원합니다.
8/12 6/13
Vector Korea IT Inc. | Phone +82 2 807 0600 | www.vector.com 제공 직전의 마지막 변경이나 최초 출시 후 수년 이후의 제품 려해야 한다는 것을 보여준다. 이를 위해, 공격 트리 분석(ATA)은 개선을 포함해서 항상 이뤄져야 한다. 체계적으로 두 가지 위험을 다루기 위해 고장 트리 분석(FTA)의 도움을 받는다. “지속적인 보안을 위해 보안 아키텍처의 모든 계 거시적 접근법 층을 다뤄야 하며, 이를 통해 잘 알려진 ‘Defense in Depth’’ 개념 전체 산업에 대한 사이버 보안은 해커와 남용에 대한 절대적인 을 얻는다. 그림 3은 Cooperative Adaptive Cruise Control 보호가 없으므로 상업적 위험이 커지게 되었다. Daimler AG의 (CACC)의 예시를 보여주는데, 네트워크 내에서 다양한 보안 수단 Lorenz Slansky는 사이버 보안이 브랜드에게 점점 더 중요해졌 이 어떻게 위협을 방어하는지를 나타낸다. Hella 의 Katharina 고 결과적으로 경쟁적 우위가 될 것으로 강조한다. 차량 내 정보 Lohmann는 특히 Verification과 Validation 분야에서 발전의 필 같은 핵심 시스템의 경우, 보안이 매우 중요하며, 유용성이 부족 요성을 발견했다. SPICE 같은 프로세스 프레임워크가 엔지니어 하다고 해서 보안이 취약해서는 안 된다. 보호 시스템의 개발에 링 및 유지 보수에서 에러를 체계적으로 방지하는 데 사용되지 서 중요 문제는 보안 요구사항을 완전하게 식별하고, 보안 기능 만, 추가 테스트 및 제공에 앞서 새로운 소프트웨어 개선을 체계 의 체계적인 구현 및 관련 보안 요구사항을 모두 충족하는 일관 적으로 탐색하고, Fuzz 테스트 및 침투 테스트와 같은 새 테스트 된 증거를 목표로 하는 보안 검사이다. SAE 3061 같은 보안 표준 절차들의 도입하는 것과 같은 검증 개선이 시급하다. 벡터의 은 다른 산업의 사례를 배우고 필수 솔루션을 신속하게 구현하는 Günther Heling는 첨단 AUTOSAR 베이직 소프트웨어의 개발 및 데 도움을 준다. Lorenz Slansky는 독점적인 메커니즘은 이른바 제공에서 자신의 경험을 강조한다. 엄격한 릴리즈 기준을 갖는 가정된 보안처럼 보이는 경우가 종종 있으며, “숨김에 의한 보안 자동 공급 체인이, 필요한 품질을 달성할 수 있다는 것을 강조한 은 해커를 막지 못하며 우수한 솔루션을 지체시키기만 한다”라 다. 는 것을 명확히 한다. Porsche AG의 Christian Meineck는 “보안 개념은 차량 및 IT 네트워크 내부 그리고 차량 외부를 고려해야 솔루션으로서 암호화 한다”라고 덧붙인다. 그림 2는 일반적인 공격 시나리오들을 보여 암호화 방법은 오늘날 보안 솔루션에서 필수적인 부분이다. 주며, 제조사들이 이를 어떻게 평가하는지를 보여준다. 개별 기 Cryptovision의 Klaus Schmeh는 10에서 38개의 가능한 키의 조 능 유닛들의 중요성은 낮아지고, 복잡한 차량 시스템은 단기간의 합을 통한 AES 암호 절차가 양자 컴퓨터를 사용해서도 예측 가 연속 소프트웨어 업그레이드 및 “Over the air”(OTA) 같이 오늘날 능한 미래에 풀리지 않는다고 가정한다. 이와 기타 보안 메커니 복잡한 IT 시스템에서 이미 사용되고 있는 솔루션을 요구한다. 표 즘을 통합하는 데 겪는 주요 어려움은 차량 IT 시스템에 의미 있 준들은 여러 분야의 협력을 통해 빠르게 IT 분야의 기술을 습득 는 방식으로 보안 메커니즘을 통합하는 것이다. Michigan 대학 자동차 산업을 위한 사이버 보안 하고, 모든 산업에서 반복되는 에러를 방지할 수 있게 한다. 의 Andre Weimerskirch는 높은 성능 요건들이 종종 그리고 결 과적으로 보안을 억제하는 경우가 있다는 것을 강조했다. 차량간 사이버 보안 적용 사례 오픈 인터페이스로의 증가로 차량 내부 및 외부 간의 상호 연결 (C2C) 및 차량과 인프라간(C2I) 커뮤니케이션을 위한 세계에서 사이버 보안은 자동차 산업에 큰 영향을 미친다. 시스템이 점점 복잡해지고, 차량 자체도 오픈 인터페이스와 결합되고 있으므로 엄 된 기능들이 늘어났다. 이는 특정 기능에 영향을 줄 뿐만 아니라 가장 큰 공공 키 인프라(PKI)에서, Andre Weimerskirch는 성능 요 격한 위험 관리, 지속적인 품질 보증 및 체계적인 개발 프로세스가 필요하다. 강력한 보안 문화를 조성하기 위해 벡터는 자동차 사 시스템 그룹 및 특정 기능과 상호 연결된 기능에도 영향을 미친 건과 데이터 보호를 결합했다. 그 논리는 단순하다: “첫 번째 우 이버 보안에 대한 모범 사례를 요약했다. 본 기사에서는 Daimler, Hella, Infineon, Porsche, Thales, ZF 및 벡터의 생생한 경험을 다. 여기에는 비 전기적 특성이 포함된다. 예를 들어 기능적인 사 선순위가 기능적 안전이고 두 번째가 프라이버시이다”. Thales의 제공한다. 업계 사례 연구에서는 위험-중심 보호의 구현 방법에 대해 강조한다. 고나 버스 시스템에 대한 공격 후에 기계적 문제 및 노후에 대한 Dietmar Hilke는 첨단 보안 요건을 위한 솔루션을 개발한다. 그 경고가 더 이상 작동하지 않을 수 있다. DENSO의 Masahiro 경험에 따라 보안 설계를 하는 것은 중요한 도구이며, 의료 분야 Goto와 Martin Prisching은 안전 및 보안 측면을 한 쌍으로 고 의 면역을 IT에 접목했다. 복수의 내성 질병들이 존재하고 있는
“사이버 보안은 모든 기업의 핵심 과제가 되었다” 이는 벡터 CEO 따르면 보안은 종종 암호화와 같이 유기적으로 관리된 개별 대책 인 Thomas Beck이 전 세계의 회사들과 일한 경험을 요약한 에 제한되는 경우가 있다는 것을 보여준다. 암호화 솔루션, 키 관 한 마디이다. 2007년 벡터 그룹이 Baden-Baden에서 처음 실질 리, 코드 분석, Fuzz 테스트 및 방화벽이 필요하지만, 그 가치는 적인 기여 및 자체적인 솔루션과 함께, 기능 안전의 맥락에서 보 의식적 혹은 무의식적으로 취약점에 대한 대응이 불충분하면 반 안의 중요성 증가와 관련해서 의견을 피력했을 때만 해도 많은 감된다. 벡터가 시행한 고객 조사에 따르면 모든 보안 관련 사고 기업이 자동차 분야에서는 보안이 문제가 되지 않을 것이라고 주 의 약 90%는 사람의 실수로 인한 것이다. 장했다. 이 같은 태도는 최근 벡터 심포지엄 2016에서 볼 수 있 듯이, 완전하게 바뀌었다. Stuttgart Liederhalle에 많은 자동차 답은 보안이 전체 기능 분야에 대해 체계적으로 개발 및 지속적 제조사, 공급 업체 및 IT 기업들이 참석해 사이버 보안과 관련한 인 확인 및 검증이 되도록 명시하는 위험-중심 문화이다. 그림 1 서로의 경험을 공유했다. 본 기사에서는 이벤트 및 다양한 실용 은 이 가치 체인을 나타내는데, 이는 내부 또는 외부적으로 발생 적인 팁을 제공한다. 하는 위험을 특히 강조한다. 공격이 외부로부터만 가해진다고 가 정하는 것은 순진한 생각이다. 취약성은 부주의한 개발 프로세 절대적인 보안은 없다 스, 무계획적인 릴리즈에 의해 발생하지만, “백도어” 및 “마스터 “각각의 복잡한 시스템에는 결함이 있으므로 절대적인 보안은 접근” 같은 고의적인 에러에도 발생한다. 기업들은 전체 공급망 없다,” 벡터 컨설팅 서비스의 이사 Christof Ebert의 경고는 명 을 안전하게 지키고 이를 통해 의도적으로 자신의 관점을 바꿔야 확한 신호를 주고 있다. 각 회사는 제품, 프로세스 및 공급망에 대 한다. 그러기 위해 공격자와 같이 생각하고 엔지니어 또는 관리 한 전체 라이프사이클을 통해 안정적으로 작동하고 추적이 가능 자와 같이 예방 조치를 취하는 능력이 필요하다. 보호는, 특히 그림 1: 위험-중심 보안에서 전체 라이프 사이클을 고려해야 한다. 한 위험-중심 사이버 보안 관리를 확립해야 한다. 벡터의 경험에
9/0 9/1 가능한 지원 전략을 구현할 필요가 있다. 운영 측면에서, 이는 아 사이버 보안에 관한 자세한 정보: 키텍처의 릴리즈 및 컴포넌트 릴리즈를 책임지는 보안 관리자가 www.vector.com/security 제어할 수 있다. 전통적인 변경 관리 위원회는 기술적으로 강화 하고 그 업무 방식을 보강하며, 정의된 기준에 대한 위협을 평가 하고 구현에 앞서 다른 솔루션을 평가해야 한다. 보안에 초점을 저자 Dr. Christof Ebert는 Vector Consulting Services GmbH의 전무이사이 둔 주기적인 아키텍처 검토 및 테스트 전략 조정은 개발자들과 다. 관리자들 간에 보안 수단이 미약한 수단은 아니며 단일 프로젝트 에서 구현되어야 한다는 사실에 대한 상호 이해를 심화한다. 이 같은 개념은 간단히 형성될 수 없다. 이들은 조직 내에서 강력한 고정점이 필요하다. 벡터 프로젝트 보고서는 팀이 유형적이고 구 체적인 책임을 갖기 때문에 이 같은 행동 변화가 보안을 지속 가 저자 Dr. Eduard Metzker는 Vector Informatik GmbH의 보안 솔루션 매니저 능하게 만든다고 보고한다. 이다.
보안은 체계적인 처리가 필요하다 벡터의 사이버 보안 프로젝트는 하나의 분명한 메시지를 제공한 다. 자동차 사이버 보안의 체계적 구현과 비효율적인 현장 수단 사이의 경계가 작으므로 전문적인 지원이 필요하다. 보안 공격은 그림 2: : 차량 내 공격 시나리오 공통적인 패턴을 보인다. 강점이 약점을 이용하지 않고 지능이 부주의를 이용한다. 이는 완전히 일관된 소프트웨어 변화가 아닌 방화벽 및 게이트웨이 구성의 인스턴스 에러를 의미한다. 그리고 Translation of a German publication in Elektronik automo- 것과 꼭 같이, 공격은 지속해서 새로운 패턴을 개발한다. 체계적 로 시작해서, 개별 요소들이 개별적으로 강화되었다. ZF의 복잡한 사용자 인터페이스로 인해 보안 수단이 기본 상태에 머무 tive, special issue on Software September 2016 인 탄력성을 갖추면 저항은 지속해서 확장된다. 보안은 설계에서 Achim Fahrner는 탄력성과 견고성을 구축하는 데 있어서 계층 르고 공격에 대한 취약성이 발생하게 된다. 벡터는 위험 평가를 시작되지만 아무리 길다고 해도 전체 라이프사이클에 대한 작업 속에서 암호-프로세서 및 하드웨어 보안 모듈(HSM)의 중요성을 토대로, 검증 및 모니터링, 아케텍처 검토 및 보안 컨설팅에 이르 이미지 권리: 이다. 강조한다. Safety-Critical 서브시스템과 브레이크에 대한 커뮤니 기까지 전용 인프라 구성 요소 및 툴을 공급하며, 다양한 경험을 티저 이미지: Vector Informatik GmbH 케이션 장치는 인포테인먼트와 기타 취약 시스템에 직접 연결해 쌓았다. 일관된 라이프-사이클만이 사이버 보안을 개선한다: 최 그림 1: Vector Consulting Services GmbH 회사들은 일관된 위험-중심 보안을 ECU 및 네트워크 수준에 대 서는 안 된다. 이는 특히 점점 많이 사용되는 ‘무선’ (OTA) 업그레 초 위험 분석에서부터 아키텍처 결정 그리고 사후 변경 관리에 그림 2: Porsche AG 한패치 만으로 얻을 수 없다는 데 동의한다. 보안은 전체적인 아 이드에서 적용된다. Infineon의 Axel Freiwald는 OTA가 콜백 서 이르기까지 회기 테스트를 통한 검증을 수행한다. 벡터의 Prof. 그림 3: Denso Automotive GmbH 키텍처를 다룰 필요가 있다. 그림 4는 서브넷을 명확하게 분리한 비스의 수를 줄이지만, 기존 네트워크에서 사용하기 전에 완전하 Ebert 또한 다음과 같이 강조한다. “지속 가능한 사이버 보안은 그림 14 Vector Informatik GmbH 벡터의 기준 모델을 보여준다. 이들 서브넷들 간에는 방화벽과 게 보호를 해야 한다고 강조한다. 롤백 및 가용성과, 각 제어 유 일시적인 성공이어서는 안 되며, 전문가와의 지속적인 협력이 필 침입 탐지 시스템이 위치한다. 벡터의 Eduard Metzker는 이 같 닛에 대한 안전한 소프트웨어 배포 같은 IT 요건들은 증가한다. 요하다.” 은 분산된 보안 아키텍처가 단계별로 구현될 수 있기 때문에 현 재의 환경 조건에서는 최적의 방법이라고 간주된다. 이는 Denso 회사들은 유기적 성장 아키텍처를 점진적으로 모듈화함으로써 와Tier-1이 전파하는 것으로 계층적 보안 아키텍처가 필요하다. 사이버 보안 솔루션과 시스템 및 IT 아키텍처에서 그 경쟁력을 첨단 암호화 솔루션과 함께 하드웨어 기반의 앵커 및 AUTOSAR 강화해야 한다. 동시에, 이들은 다양한 조직 유닛들에 대한 지속
그림 3: 철저한 보호를 위해 모든 보안 계층이 필요하다. 그림 4: 보안 설계 실례: 다양한 서브넷은 가능한 분리해야 한다.
9/2 9/3 그림 1: 메시지 전송 및 암호화된 통신의 타이밍
를 가지고 있어야만 한다. 사용자 또는 OEM이 원하는 키를 자유 발신 노드가 T(오프셋) 동안 새로운 ID 키 메시지를 수신하고 처 롭게 선택할 수 있도록, 사용된 소프트웨어 모듈은 동작 중에 키 리하기는 하지만, 버스 시스템상의 과부하를 막기 위해 이러한 의 동적 할당을 허용한다. (비대칭) 키 교환 방법과 같은 고급 방 메시지가 바로 암호화된 메시지의 재전송으로 이어지지는 않는 법도 구현할 수 있으며, EOL 프로그래밍에서의 정적 할당도 가능 다. 더욱 견고한 프로토콜을 만들기 위해, 수신자는 새로운 카운 CAN FD 네트워크상에서 AUTOSAR를 이용한 암호화된 신호 전송 하다. 차량별로 특정한 키를 사용하는 경우, ECU를 교체할 때에 터 값을 기준으로 발신자의 응답을 감시하는 타이머 T(재전송)를 는, 어떠한 상황에서도 보안을 유지할 수 있는 인증 방법으로 신 사용한다. 발신자로부터 확인 메시지를 받지 못할 경우, 수신자 오늘날 차량 네트워크 분야에서 대부분의 데이터 전송이 특별한 보안 조치 없이 이루어지고 있다. 이 때문에, 차량 버스 시스템에 직 규 ECU를 설정하여야 한다. 는 새로운 ID 키를 생성하여 재전송한다. 이를 통해, 전송 ECU의 접 접속만 가능하다면 전송된 데이터를 원본 그대로 읽어내거나 데이터를 수정하여 버스 시스템상에서 전송할 수도 있다. 암호화된 작은 오류도 감지할 수 있을 뿐 아니라, 재전송 시간도 단축할 수 데이터 전송을 이용하여 이러한 정보를 인증된 수신자만이 해석하도록 보장하고, 메시지를 가로채거나 변경하려는 시도를 더욱 어 재전송 공격 방지 있다. 또한, 비휘발성 메모리에 ID 키가 저장되는 것을 방지할 수 렵게 만들 수 있다. 위와 같은 설정을 통해 메시지의 암호화된 전송이 가능하지만, 있다. 전송 대상인 정보가 여전히 정적이다, 예를 들면, 고유의 키 텍스 트를 일반 텍스트 신호에 할당할 수 있다. 즉, 원하는 통신의 일 데이터 분할 없이 CAN FD로 데이터 전송하기 부는 저장하고, 이를 후에 시스템에 다시 전송하는 재전송 공격 ISO-15765 전송 프로토콜에 대한 데이터를 분할하여 CAN을 통 언론은 차량 조작[1],[2]과 관련하여, 차량 네트워크상의 데이터 크에 대한 보안 통신 체계를 구상했다. 사용자 인증 및 재전송 공 은 여전히 가능하다. 수신자는 해당 메시지가 원하는 발신자로부 해 전송하는 것은 심각한 문제를 내포하고 있다. 데이터 전송 시 가 실제로 조작 가능한지에 대한 의문을 제기하고 있다. 원격 제 격의 방지를 데이터 보호의 주요 목표로 하여, 외부에서 모니터 터 전송되었는지를 확인할 수 없기 때문이다. 이를 확인하려면, 간이 길어질 뿐만 아니라, ISO-15765 프로토콜에 대한 데이터를 어 기능을 갖춘 조작된 장치나 내부 장치가 차량 작동에 영향을 될 수 없는 통신을 구현하고자 하였다. 통신 초기에 수신자가 ID 키라 불리는 임의의 값을 생성하여 발 분할하여 복수의 노드로 전송하는 것이 매우 어려우므로 이러한 줄 수 있을까? 그리고 이러한 조작을 막을 수 있는 대책은 무엇 신자에게 전송해야 한다. 매 전송 시 발신자는 해당 값을 증가시 방법은 고정된 1:1 관계에 국한될 수밖에 없다. 반면, CAN FD를 인가? 데이터 암호화를 위해 전문가들은 AES 알고리즘을 선택하였다 킨 후 전송 메시지에 덧붙인다. 메시지가 도착하면, 수신자는 해 통해서는 다수의 수신자들에게 암호화된 메시지 전체를 동시에 [3]. 현재, 이는 매우 안전한 암호화 방법으로 알려졌으며, 128비 당 ID 키가 예상 값과 일치하는지 확인한다. ID 키가 유효하면 메 전송하는 것이 가능하다[4]. 각 수신자는 암호화된 메시지를 해 오늘날의 자동차는 네트워크화된 다양한 센서와 액추에이터로 트의 블록 길이를 가지는 대칭형 블록 암호화를 기반으로 한다. 시지가 처리되지만, 그렇지 않으면 거절된다. 발생할 수도 있는 독하기 위해 동일한 대칭 키가 필요하다. 이때, 인증 과정을 거치 구성되어, 버스 시스템을 통해 중요한 데이터를 지속해서 전송하 이 알고리즘은 데이터를 16바이트 혹은 16바이트의 배수로 생성 메시지 손실을 허용하기 위하여, 수신자는 약간의 큰 값도 수락 기 위해서는 ID 키에 관한 두 개의 배리언트를 고려해야 한다: 1) 는 매우 복잡한 시스템이다. 대부분의 경우, 전송되는 정보는 원 하고, 이를 수신자에게 전송한다. 추가적인 장점으로는 일부 마 할 것이다. 즉, 신호의 내용이 변경되지 않더라도, 전송 메시지의 모든 수신자가 합의된 값에 동의한다. 혹은, 2) 모든 수신자가 별 시 데이터(raw data) 형식이다. 유효성 검사를 수행할 수 있다고 이크로컨트롤러가 이미 이 알고리즘을 처리하는 고속 하드웨어 카운터가 지속해서 암호화된 데이터를 변경하는 것이다(그림 1). 도의 ID 키를 생성하여 발신자에게 전송한다. 발신자는 모든 카 하더라도 그 효과는 매우 제한적이다. 수신자는 데이터가 원하는 를 내장하고 있다는 점이다. 운터를 관리하며, 이를 데이터 메시지에 첨부한다. 암호화된 메 발신자에 의해 전송되었는지, 혹은 외부 ECU를 통해 입력된 데 ID 키의 문자 수와 메시지의 전송 빈도에 따라, 해당 메시지의 카 시지에 포함된 카운터 값의 위치는 반드시 해당 수신자에게 고유 이터인지, 즉, 허가된 데이터인지를 확인할 수가 없다. 그뿐만 아 CAN 메시지는 프레임 당 최대 8 데이터 바이트까지 전송 가능하 운터 값 오버런이 발생할 수 있으며, 이로 인해 암호화 메시지의 하게 할당되어야 한다. 그림 2는 다수의 수신자들을 대상으로 한 니라, 데이터에 대한 접근이 자유롭기 때문에, 네트워크 신호의 므로, 통신 스택에 이미 포함된 ISO 전송 프로토콜(TP)을 선택하 반복 전송 현상이 발생할 수도 있다. 이를 방지 하려면, ID 키가 데이터 전송을 나타내고 있다. 먼저, 수신자가 임의로 생성된 시 내용을 파악하기 위한 버스 정보 분석이 가능하고, 데이터 전송 였다. 설정을 간소화하고 프로토콜 오버헤드를 줄이기 위하여, 일정 기간만 유효해야 한다. 이러한 유효 기간이 만료되면, 수신 작 값을 발신자에게 전송한다. 그런 다음, 해당 발신자가 전송 주 의 기밀화나 인증화가 되어있지 않다. 발신자와 수신자 간의 고정된 1:1 관계를 갖는 일방향 통신을 선 자가 새로운 값을 생성하여 발신자에게 전송해야 한다. 새로운 기별로 모든 ID 키 값을 증가시킨 후 이를 암호화된 메시지 내의 택하였다. ID 키가 수신됨과 동시에, 발신자는 암호화된 메시지를 전송한 지정된 위치에 삽입한다. 그러면, 해당 수신자가 ID 키를 확인한 이러한 문제를 해결하기 위해 벡터의 엔지니어들은 유연하면서 다. 따라서 수신된 ID 키가 내부 키와 일치하지 않을 경우, 수신 후 데이터를 수락 혹은 거절한다(그림 2). 하지만, 수신자의 수가 도, AUTOSAR-3.x Basic Software와 통합할 수 있는 CAN 네트워 대칭 암호를 사용하기 위해서 발신자와 수신자 모두가 동일한 키 자가 메시지 반복을 개시할 수 있으므로 대기 시간이 줄어든다. 증가할수록, 가용한 데이터를 위한 메시지 공간이 줄어든다. 또
9/4 9/5 움” 없이는 조작이 거의 불가능하게 만들 수 있다. 이미 수년간 양산 차량에서 사용됐으며, 일부 차량은 자동차 보험금 할인 혜 택도 받고 있다. 이 옵션을 장착하면, 보안이 강화되어 데이터 보 호뿐 아니라, 최종 사용자는 직접적인 비용 절감의 혜택까지 누 릴 수 있는 것이다.
가까운 미래에 Car2x 통신, WLAN, Bluetooth, Ethernet과 같은 원격 접속에 대한 수요가 지속적으로 증가하여, IT 보안과 관련한 요건은 더욱 강화될 전망이다. 이러한 접속 모드는 공격에 대한 방어 기능을 갖추어야 하며, 어떠한 원격 조작도 허용해서는 안 된다. 특히, 이는 다른 교통수단이나 인프라로부터 안정적인 정 보를 수신해야 하는 운전자 보조 시스템에는 더욱 중요한 부분이 다. 벡터는 운전자 보조 시스템 개발 및 분석을 위한 기술 지원 서비스 또한 제공 하고 있다. 그림 2: CAN FD – 다수의 수신자들을 대상으로 하는 ID 키 구조
그림 제공: 한, 가용한 데이터의 바이트 수는 채택된 ID 키의 문자 수에 따 요약 및 전망 Vector Informatik GmbH 라 편차가 크다. 그림1에 묘사된 통신 타이밍이 적용되었다. ID CAN FD의 경우, 특히 복수의 노드를 이용해 암호화된 데이터를 키 수신 시 발신자를 위한 변경만 요구된다. 암호화된 메시지를 안정적으로 전송할 수 있으며, 이는 기존의 AUTOSAR 환경에도 참조: 바로 전송하는 대신, 발신자는 다른 수신자로부터의 다른 ID 키 적합한 방법이다. 단 한 가지 취약한 부분은 어플리케이션 수준 [1]http://www.chip.de/news/CAN-Hacking-Tool-Autos-hacken- 메시지를 수신하기 위하여 설정 가능한 시간 T(IdKeyReply)를 기 에서의 데이터 직렬화 및 병렬화이다(그림3). fuer-20-Dollar_67066892.html 다린다. 특별한 경우T(IdKeyReply)=0 설정을 통해 초기화도 가능 [Only German] 하다. 즉, 각각의 신호 별로 RTE의 모델링 속성이 사용될 수 없다는 것 [2]http://www.can-newsletter.org/engineering/engineer- 이다. 이러한 시스템상에서 전형적인 공격 포인트에 대해 항상 ing-miscellaneous/140822_list-of-potentially-vulnerable-cars_ 벡터는 CANoe 환경에서 CAN FD를 위한 프로토콜을 구현하였 유념해야 한다. 예를 들어, 스타트업 단계에서 취약한 ID 키를 위 blackhat/ 다. 벡터의 전문가들은 ECU 및 네트워크를 개발하고 이를 시뮬 한 임의 번호 생성기 또는 대칭 키 도용 등이 이에 해당한다. [3]Advanced Encryption Standard (AES), FIPS PUB 197 레이션 및 테스트할 수 있는 소프트웨어를 사용하여 해당 프로토 [4]CAN with Flexible Data Rate – Specification Version 1.0, 콜에 대한 광범위한 테스트를 실시하였다. 재전송 공격에 대해 보안 기술 업계에 따르면, AES-128 알고리즘의 미래는 긍정적이 Robert Bosch, GmbH; April, 2012 요구되는 방어 성능은 물론이고 발신자와 수신자의 메시지 손실, 며, 알고리즘의 구현이 더욱 발전하여, 심지어 하드웨어 액셀레 http://www.bosch-semiconductors.de/en/ubk_semiconduc- 오류, 재입력, 그리고 타이밍 오류와 강력한 공격에 대한 연구가 이터에 의한 지원까지도 가능할 것으로 보고 있다. 본 기술 기사 tors/safe/ip_modules/can_fd/can.html 이루어졌다. 테스트 결과, 위의 언급된 모든 상황에서 암호화된 에 소개된 암호화된 신호 전송을 이용하여, CAN/CAN FD 통신에 시스템을 통해 데이터를 안정적으로 전송할 수 있었다. 대한 공격을 매우 어렵게 만들 수 있을 뿐 아니라, “내부인의 도 링크: Vector 홈페이지: www.vector.com
저자:
아민 하펠(Armin Happel) Vector Informatik GmbH의 ‘Research and Development for In- novative Application‘ 부서에서 근무하는 수석 소프트웨어 개발 엔지니어로, 보안 응용 분야를 담당하고 있다.
그림 3: 암호화된 전 송을 위한 소프트웨어 컴포넌트
9/6 9/7 085
084 Product Feature
PNF1MVH (SFFO( ח)Ѣ .*$304"3 7 ۽ର۹ ܳ҅ױ օܻ ഝਊ 1IBTFu৬ э ৈ۞ ۽оਊ ాन ֎ਕఊ ӝࣿ ೠ ೠ ೞ٘ਝয ਗ ߂ ର 1):ীز ਸ ਊ೧્פ प೯ػ 4-"$ ݫழ %)$1 %/4 *1W 6%1 5$1 Ҋ ਵݴغ ഋ 5$1*1ٓ झఖې1W߂ *1Wਊ * ۽নೠ ࣻળ दӒօ х࣭ਯਸ ӝ߈ਵ ח షਸ۽5-4١җ э ੜ ঌ۰ ੋఠ֔ ਗೠࣗ ઁઑসܳ ਤೠ بোѾػ ҳഅ ۽ਵܻޛ ࣗ ীࢲ חೞ ਗೠ 1-$ ୡӝ োѾ ࢸী فݽ Ѫ W&74& ח࢚ झ݃ ాनী ࢚ೞ ೧ ࣗܳ ഛ ध߹ೡ ࣻ ܘীࢲ ۅױ ೠ ࣁೠ ࢎ೦ & W&74 ݴف झী ӝ߈ਸֿܻ ӝର৬ ࣗо ࢚ਤ ߬٣٘ ݶغࣗо ध߹ ߂ %*/৬ ҙ۲ೠ$&*40* חী חغష ҅க ঐഐചػ ࠁо Үജ۽ਸ ాೠ উੋ োѾ ࢸ $"4- ݫद ࣽࢲ৬ э ݽٚ ஹನք &9* ࢚ਤ ҅க ҕਬ "7-/ਸ ҳࢿೠ 4-"$ ۄٮ ী $&*40* ର৬ ࣗ р ୡӝ ܳ ನೣೠز न ীࢲా חѐߊػ झ݃ ӝࣿਸ పझೞ ܳ۞܀ର৬ *40*&$ ஶز ױੌ োѾ ࢸ ݒ ਃೞ חп߹ೠ о ਃೞ &$6 חदझమ ؘ о ݢ ਤೠ ߬٣٘ Ҋ աݶغࣗ р ాन ҳ୷ ߂ %*/ ӏѺী ࠗ$&*40* ۄର ઁઑস ߂ ੋز ী ো ೠಞ "7-/ SMART CHARGING - A KEY TO SUCCESSFUL E-MOBILITY উೠ "7 ֤ܻ ֎ਕ ী ղػ ܲ ର ۄפ೧ঠ ೡ ࡺ ই $&*40* חਃ җઁ חѐ߹ ֎ সо ݶೞҊ חѾ೧ঠ ೠ пп "7-/ী ژহ ాؼ ࣻ যঠ ೠ ܨѪ ࠗಿҗ য় חಿਸ ࢸ҅ೞઁ חঐഐചػ ా ী ࠗೞ ೠژо ೡػ /*% ࢿҕੋ &.PCJMJUZਤೠ ೨ब ਃࣗ ਕ *% झ݃ য ظࢎप࢚ ৻ࠗী ѐߑ ח &$6 ର ઁઑসо &$6ѐߊ द ਬ ೠزध ѐߊ ߂ పझ नਸ ਤ೧ "7-/ п ֢٘ী ೧ /*%ী חળ ӏѺ ળࣻೞ ೡ ࣻب ֎ਕ ݯߡभ ఃо ਃೞ ೠ Ѿҗܳ חغݒட о ࡅܲ ߑߨ ח חରز ীࢲ҅ױ Ҵઁ ాन ࢸ ୡӝ$&*40* חध ӝରী $" ܨҮ ػ ֙ ࠆ റܐ࢚ਊചо ৮ ߭ఠ .*$304"3 מநझ ݫदܳ о٘۽࠳ &UIFSOFU ࠺ ળ ӏѺੋ %*/ ؊֔ ध ӝର ҃ $% ܨળ ӏѺਸ ਊೞҊ 7FIJDMFUP(SJE ӝࢎী ೠ ݽٚ ֎ਕ ֢٘ী ࣠ೠ೧ ݫ 7(عب ೠ স҅ ରਗ о Ѫী ח ੌࠗܳ ਊೞ$&41 ࢎਊ Ҋغந ৬ э Ѩૐפ؊֔ ਬ ח ӏ दܳ ࣻनೠ ݽٚ ࣗ۽ӝର ߂ ࣗ ઁઑࢎٜ ࢜ ೧ ળ ӏѺٜਸ ࣁ ಝࠁҊ חࢲ ࣛ ߑߨਸ ઁदೠ झ ݫदܳ ࣠ೠ ೞա ۱ ೞӝ ए ߬٣٘ חѐߊೞҊ పझೞ ۽ಿਸ ࡅܰҊ ബҗਵઁ חѺী ࠗೞ
Ѫ ח࣌ਸ ࢎਊೞܖ 䤋 䤋䤋 ா࠶ ৈ۞ ࣗী ۱ਸ ҕәೡ ࣻ Ӗ 䤋 (Dirk Grossmann) 䤋䤋 (Dr. Heiner Hild) )ର .*$304"37زషਸ ా೧ ೧ ۽ ীޙٸ ೞ֎ܰ ൧٘ ӝ झ݅۽Ȉ؊ Ӓ Vector Informatik GmbH BTJD4PGUXBSF# ח Ӓܿ о োѾػ ࣗܳ ध߹ೡ ࣻ যঠ ೠ ظҳࢿ ۽ ݽٕ #48 ೧ੋ ۽ਗ ঋ рࢼਵ بೞ݅ ࠛ೯ "6504"3৬ ঋ ਵݴغোѾ ۽ਵܻޛ ରীز೧ ࠗೞ ࢚కী ח߸ೞ ۽ೠ ݆ ӝ ীց ܳ ߈೧ ࣘਵמ दрী оૣ חର חରܳ ਬೞزղোӝҙ ӝ߈ ۽ೠ ઁಿਵמೡ ࣻ )PNF1MVH(SFFO ഐജ о بࣗ दрਸ ۱ ҕәস חೡ ࣻ ӝ о ਃೠ Ѫੋо ృӔ റա ࣳೝ റ ա݅ױҗ ݻ ࠙ ղী р ਃ ח4JHOBM -FWFM "UUFOVBUJPO ܳ ਊ೧ ࢎਊ 4-"$:(1 ࢚కо ਬؼ ࣻ ਸө झ݃Ӓܻ٘ী ઁҕೠܳ ా೧ ୭ بೞ ঋ ߓఠܻ ীױର ۢ р $IBSBDUFSJ[BUJPO ਸ ా೧ ܳ ߑೞҊ ҳࢎ೦ী ݏѱ &$6 ࣗ ࠗೞ द അ࢚ਸ ߑೡ ࣻ ࣗ ীց ҕәস ࣗਬ ର ߂ ରز חࣁझ ҙܻ ߂ ୭ച۽ োѾػ ࣗ݅ ഛೞҊ উ ਝয ಁఃܳ ઑ ۽ਵܻޛ ӒܻҊ ജ҃ੋ ஏݶীࢲ ਃ җ ઁઑস חࣗ ઁઑসٜ ݶೞҊ ध߹ೡ ࣻ 4-"$ ೦࢚ ӝ ೡ ࣻ .*$304"3 ۽ਵ :(झ݃ ࢚ӝ )PNF1MVH(SFFO1 ܲٮ ী$&*40* ۽झ݃Ӓܻ٘ ې ীցਗҗ ઁ *নೠ *40 04 ח)ਃҳࢎ೦ਸ ߈ೠrਃ 7 חغରীࢲ ࣠ ா࠶ ੌױ ೧Ѿೡ ࣻ ীց ߂ ؘఠ ѿਊ ۽ٜਸ о ബҗਵઁޙ ୶ࣁীࢲ স ࢤпࠁ ഻ әػ חغജ ೠ ҅கীࢲ ݽٚ ӝࣿ ߂ੌز दীز ೞݴز ۄٮ ߑधrী ࣽ झ݃ ਸ ਤೠ ӝࠄ ઁઑѤױ Ҋ ࢎਊоغр ۽উਵ ח ೠ ۱מࠂೞ ࣗীࢲ ࢎਊ о ঁ ؘחషਸ ਗೞ۽ ۽ࣁ࣌ ղ ݽٚ ݫदী ҕాਵ $"4- ର৬ ࣗ р উੋ ࠁ Үജزೠ ۱ ҕәী োѾ מରܳ ࢎਊ оز١җ э ӝࠄ ࣻਃ ߓఠܻ ࢚క க҅ *04 40* ٸ Ҋਬ ध߹ੋ 3VO*% חয যঠ ೞغನೣ ܻޛ ח*40*&$ীࢲ ࠺ઁযध ৬ ҙ۲೧ חೞ ۽ରܳ ୭زೠ ೧ ೧ מ दীࢲ ࢎਊ о ۄפࠁࡺ ই /*% ର৬ ࣗо ࣘೞѱ ػ *40*&$ ߂ز ۽ ࢲ )PNF1MVH (SFFO 1):ܳ ઁद۽ইࠁӝ ൨ٜ Ѫ ҅கਵ ۽খਵ חࣁझ۽ীց ਗҗ э ࠂೠ ࠁ द Ҋ۰ ܨҮ ۄٮ PNF1MVH(SFFO"7ܳ ӝ߈ਵ 4-"$ਸ ాೠ োѾ ࢸt4PVOEJOH ী( ח ۱ ೠ݆ ۽ਵ࢚ ח ӝର ী ࠺ਊ ୭ച ೠژޙٸ ঠ ೞӝظ $% ܨ "$ t"UUFOVBUJPO $IBSBDUFSJ[BUJPO 1IBTFu 1PXFS -JOF $PNNVOJDBUJPO ೠ 1-$ ۽ ࣻਃо ݆ ରҗ ীޙٸ ӝغউࢿҗ ؊ࠛয җ э ࣗݽ ࠛҳ ߑध ؘחਊ೧ ೞ ܳܨ t.BUDIJOH t7BMJEBUJPO 1IBTFu ӝઓ оਊ ӝ ߓࢶਸ 1IBTFu חೣԋ Ҋ۰೧ঠ ೠ э ࣗ ҃ ࢚ೠ ۱ ࣻਃо ߊࢤೡ ߑߨ1-$ بٜޙ ظҳࢿ ۽नী ਃೠ ࣗਝয ݽٕٜా)7 ח) Ӓܿ ţ .*$304"37 ೠژ1IBTFu߂t"NQMJUVEF .BQ &YDIBOHF ਃೞ ח۞ೠ ग ా೧ ஹೊఠ ߂ ೱ࢚ ӝӝٜਸ োѾೞ חࣁझ۽ഋ מѪ زѱ ࢎਊܳ ੋૐೡ Ѫੋо ڌয
10/0 10/1 085
PNF1MVH (SFFO( ח)Ѣ .*$304"3 7 ۽ର۹ ܳ҅ױ օܻ ഝਊ 1IBTFu৬ э ৈ۞ ۽оਊ ాन ֎ਕఊ ӝࣿ ೠ ೠ ೞ٘ਝয ਗ ߂ ର 1):ীز ਸ ਊ೧્פ प೯ػ 4-"$ ݫழ %)$1 %/4 *1W 6%1 5$1 Ҋ ਵݴغ ഋ 5$1*1ٓ झఖې1W߂ *1Wਊ * ۽নೠ ࣻળ दӒօ х࣭ਯਸ ӝ߈ਵ ח షਸ۽5-4١җ э ੜ ঌ۰ ੋఠ֔ ਗೠࣗ ઁઑসܳ ਤೠ بোѾػ ҳഅ ۽ਵܻޛ ࣗ ীࢲ חೞ ਗೠ 1-$ ୡӝ োѾ ࢸী فݽ Ѫ W&74& ח࢚ झ݃ ాनী ࢚ೞ ೧ ࣗܳ ഛ ध߹ೡ ࣻ ܘীࢲ ۅױ ೠ ࣁೠ ࢎ೦ & W&74 ݴف झী ӝ߈ਸֿܻ ӝର৬ ࣗо ࢚ਤ ߬٣٘ ݶغࣗо ध߹ ߂ %*/৬ ҙ۲ೠ$&*40* חী חغష ҅க ঐഐചػ ࠁо Үജ۽ਸ ాೠ উੋ োѾ ࢸ $"4- ݫद ࣽࢲ৬ э ݽٚ ஹನք &9* ࢚ਤ ҅க ҕਬ "7-/ਸ ҳࢿೠ 4-"$ ۄٮ ী $&*40* ର৬ ࣗ р ୡӝ ܳ ನೣೠز न ীࢲా חѐߊػ झ݃ ӝࣿਸ పझೞ ܳ۞܀ର৬ *40*&$ ஶز ױੌ োѾ ࢸ ݒ ਃೞ חп߹ೠ о ਃೞ &$6 חदझమ ؘ о ݢ ਤೠ ߬٣٘ Ҋ աݶغࣗ р ాन ҳ୷ ߂ %*/ ӏѺী ࠗ$&*40* ۄର ઁઑস ߂ ੋز ী ো ೠಞ "7-/ উೠ "7 ֤ܻ ֎ਕ ী ղػ ܲ ର ۄפ೧ঠ ೡ ࡺ ই $&*40* חਃ җઁ חѐ߹ ֎ সо ݶೞҊ חѾ೧ঠ ೠ пп "7-/ী ژহ ాؼ ࣻ যঠ ೠ ܨѪ ࠗಿҗ য় חಿਸ ࢸ҅ೞઁ חঐഐചػ ా ী ࠗೞ ೠژо ೡػ /*% ਕ *% য ظࢎप࢚ ৻ࠗী ѐߑ ח &$6 ର ઁઑসо &$6ѐߊ द ਬ ೠزनਸ ਤ೧ "7-/ п ֢٘ী ೧ /*%ী ೡ ࣻب ֎ਕ ݯߡभ ఃо ਃೞ ೠ Ѿҗܳ חغݒட о ࡅܲ ߑߨ ח חରز ীࢲ҅ױ न ࢸ ୡӝా ߭ఠ .*$304"3 מநझ ݫदܳ о٘۽࠳ &UIFSOFU ؊֔ 7FIJDMFUP(SJE ೠ ݽٚ ֎ਕ ֢٘ী ࣠ೠ೧ ݫ 7( ࢎਊ Ҋغந ৬ э Ѩૐפ؊֔ ਬ חदܳ ࣻनೠ ݽٚ ࣗ ࣛ 성공적인 E-Mobility 개발 झ ݫदܳ ࣠ೠ ೞա ۱ ೞӝ ए ߬٣٘ Ѫ ח࣌ਸ ࢎਊೞܖ ா࠶ ৈ۞ ࣗী ۱ਸ ҕәೡ ࣻ )ର .*$304"37زషਸ ా೧ ೧ ۽ ীޙٸ ӝ BTJD4PGUXBSF# ח Ӓܿ о োѾػ ࣗܳ ध߹ೡ ࣻ যঠ ೠ 빠르고 효율적인 스마트 충전 솔루션 구현 ظҳࢿ ۽ ݽٕ #48 ೧ੋ ۽ਗ ঋ рࢼਵ بೞ݅ ࠛ೯ "6504"3৬ ঋ ਵݴغোѾ ۽ਵܻޛ ରীز೧ ۽ೠ ઁಿਵמೡ ࣻ )PNF1MVH(SFFO ഐജ о بࣗ ਃ ח4JHOBM -FWFM "UUFOVBUJPO ܳ ਊ೧ ࢎਊ 4-"$:(1 $IBSBDUFSJ[BUJPO ਸ ా೧ ܳ ߑೞҊ ҳࢎ೦ী ݏѱ &$6 ࣗ .োѾػ ࣗ݅ ഛೞҊ উ ਝয ಁఃܳ ઑ 벡터는 귀사의 충전 ECU, 충전소 및 비접촉식 충전 시스템 개발을 위한 솔루션을 제공합니다 ۽ਵܻޛ ध߹ೡ ࣻ 4-"$ ೦࢚ ӝ ೡ ࣻ .*$304"3 ۽ਵ > ISO/IEC-15118 및 DIN SPEC 70121에 따라 양산한 > 완제품을 위한 깊이 있는 테스트 - 개발 및 통합 নೠ *40 04* 검증된 임베디드 모듈을 통해 기능 통신 솔루션의 시장 테스트에서 외부 전력 전자를 통한 시스템 테스트까지 테 ח)ਃҳࢎ೦ਸ ߈ೠrਃ 7 חغରীࢲ ࣠ ೠ ҅கীࢲ ݽٚ ӝࣿ ߂ 출시 기간 단축 스트 범위 확대ੌز दীز ೞݴز ۄٮ ߑधrী > > 인증 절차를 갖춘 EIM 및 PnC profile를 이용한 신뢰성 있 확장된 분석, 계측 및 로깅 기능을 통한 보다 손쉬운 문 ؘחషਸ ਗೞ۽ ۽ࣁ࣌ ղ ݽٚ ݫदী ҕాਵ $"4- 는 AC 및 DC 충전 지원 제 해결 க҅ *04 40* ٸ Ҋਬ ध߹ੋ 3VO*% חয যঠ ೞغನೣ > 충전 인프라, 개별 ECU 및 차량 네트워크 동작 시뮬레이 ର৬ ࣗо ࣘೞѱ ػ *40*&$ ߂ %*/ 션 완벽 지원 자세한 정보: www.vector.com/evز ۽ ܨҮ ۄٮ ਸ ాೠ োѾ ࢸt4PVOEJOH ী$"4- 1IBTFu t"UUFOVBUJPO $IBSBDUFSJ[BUJPO "$ ܨ %$ .ؘ 벡터의 맞춤형 ECU 소프트웨어와 종합적인 테스트 시스템이 귀사의 성공적인 개발을 지원합니다חਊ೧ ೞ ܳܨ t.BUDIJOH t7BMJEBUJPO 1IBTFu 1IBTFu
ظҳࢿ ۽नী ਃೠ ࣗਝয ݽٕٜా)7 ח) Ӓܿ ţ .*$304"37 ೠژ1IBTFu߂t"NQMJUVEF .BQ &YDIBOHF ਃೞ
10/2 112 Development Feature 113
ࠁ҃ઁظযٜѱز ݶदװदߧࢎসਸా೧ӡਸ חೞמо۽ӝࣿਵبߑधחೞ ࠺חզীט೯ೡࣻѱػয়۽݆ࣻӝসաӝҙٜ ੋఠ֔Ѩ࢝ਸ೧ࠁݶ࠺ୢध ਵ दߧࢎস ୢधӝࣿਸਊೠ࠺तೠࢎসٜۄפѪই۽োҳࢎস١ਸా೧࠺ୢधӝ ߑधഃ࢜ Үాददীࢲदղبౠ ࣁ݆҅ ݻ֙ࠗఠઓೞҊਵݴ۽Ցযৢܻӝਤ ഋక۽҅ױࣿਸदীࢲࢿࣼ ীࢲੌة ҊٜܳযغҊਸঌѱؼѪ झమীҳഅغࢎਊ۽بߥ ࣻਊ۽दী೧ӝࣿӖزೠ֢۱җ ݅ೞ ग߄ۄইझࠗܰ৬࠳ח ҕաହҊҙח۽ળചܳਤೠ֢۱ਸ߽೯ೞҊਬࢶ ೠоҙब࠙ঠ ࢎসਸ୶ח ١ীࢲӝࣿਸਊೞੋޖ؍উೱਸزীয়ۖޖݶӝର ۲সغࣘೞঋҊೞѱ۽ਵ ֙ৈܴࠗఠ߬ܳܽীࢲ ೠషܻ֢৬ ೞҊਵݴژࢎਊٜীѱഛपೠಞ ࣠दझమӝࣿחݒੌ೯ೞܳ ೯ೞҊب ؘࢎח ઁ֢ইীࢲҕҕӝߡझܳೞبࢿਸઁҕೞѱؼѪ߆ী दীبفחҊఎܻইীغӝࣿਸా೧݆ഌఖਸҳഅೡࣻ ਊ ػ߸ӝਗܻਊೠېӝߡझܳ য়ࠗఠডৈ֙חࢶߑध۞Ӓաா ࢲޖٜܳয Ӕߑध۽ী ࢜ܨ ೯೧৳۠ߡझٜߡझ ࠗध ࠺֢ചա݃ݽٸ࠶ਸোѾೡ ীࢲߑधҗ݃ଲܨನղࠗীࢸػ࠺ ߡझ۽بٸରೡ ઁޙחࢶࣚ١ী೧ߊࢤೡࣻ ѐੋਊחदജ҃ղীࢲببয۽߈ੋ ୢधܳా೧नࣘೞѱೡࣻ оۄٮী ٜਸೖೡࣻਵݴ Ӓܿ ীࢲ ޙਬ֢۱ਸծ୶ѱػҕҕࠗ QPJOUPG ߑधਸਊೞ ীஂডೠҕѺѐदۄੋח ݶӝߡझٜ ޛӝח۽Ѫਵחۄࢎ INDUCTIVE CHARGING GIVES TRIGGER TO FUTURE E-MOBILITY BUUBDL بחࣚ೯ਤ١ীೠೖ೧࢚ܳੌ ೯ೞ ߓఠبоػ ߹חࣻ ܻदрਸ Ӓܿ חഅࠁಞੋࣗীࢲ ېߋইHݽ࠽ܻ౭۽࠺ୢधߑधਵ ߓ۽ٮࣗী ыѢա۽ISO/IEC-15118 무선충전 방식 표준화 ࢎਊੋఠಕझоੌ߈ਵ ۽࠺߂ਊா࠶җೣԋղ ఠܻҮജࣗח ೡਃহز٣झۨ ח۞ೠੋఠಕझظ Ӓ࠺؊ழҊחઁחۄLQGXFWLYHFKDUJLQJ աࠁҊࢲীࢲ࠺ୢधޙHݽ࠽ܻ౭ীҙೠ֤ ۽ݽٕҗࢎਊࠁܳੑ۱ೞӝਤೠઁ ੌ࢚ਵ ಣоೡ݅ೠৈ۞оӝੋਸઁҕೞҊౠ࠺֫חӝࣿীࢲبରੋ৻ীੌחۄಞܻࢿ ೯ೡࣻظҳࢿ۽যӝ߂नਊܻ٘؊١ਵ ೞѱ೧ҊמоبѪחୢधߑधӝର೯ѢܻܳಞܻೞѱഛೞѢաч࠺ऴߓఠܻܳࣗഋചदః धߑधېഅחா ۞ೠߑ ӒܿŢࣗ৬ா࠶ਸਊೞח߈ݶী࠺ୢधߑधীࢲ যؘ݂פo߭ఠHݽ࠽ܻ౭ূ؍ରҙ۲2(0ٜҗҕәসٜଵо೮زगైоܰীࢲੌةחӖীࢲ धਸࢎਊೡ҃ۄפ࠶؊࢚ਃೞঋਸࡺই ࠺ୢधӝࣿҗӒળചীҙח9HFWRU(0RELOLW\(QJLQHHULQJ'D\ p١җэನۢীࢲ֤ػ߄ ٜೞର ೠ؊࢚ ژഋకࢎਊੋఠಕझ۠ Ҋܖ۽ೠഅউਸ߈ਵ ઙੌ೯ೞܖ ࠺ୢधחӒਬ ؘחغਃೞঋѱ ؘ࠙ೠনח ୍ܲਸ۽ߑधӔࠄਵ झ݅(Dirk Großmann), Vector Informatik۽Ӗ Ȉ؊Ӓ ٜী ীցܳऩޙٸӒܿȈVector Informatik, IPT Technology ыҊӝ ਃоקղ ҊղࠗীࢲৈࠗܳѾ೧ରର җ࠺ୢध হযѐߊٜܳࢸೠର ߓఠܻਊظചزࢎࠁҮജۄ࠺ୢधߑध ੋױחਬࢶ ਸࠁ৮ೡࣻחѾ೧ঠೞ۽ਵز ਊࣗীࣻࣗӝҙਸೠର উղ ਸ࢚ੌٸੑೡ۽ ٜܳযରղࠗޙٸળചػߑधহ ਸઁҕೞҊӝחߑधਸઁ৻ೞҊ ޙਬࣗܳߑ۽ӝਵ Ӓ ೠରҕрਵ ࣻਵݴמ दझమоزѪۢӝର ৈӝࢲߑधҗחো ೧ঠೞ ߓఠܻۄٮ ীزೡࣻ۾بೞبਸਬର۽ ߑधਸҳ࠙ೡਃо݈ର ӝࣃ ࠺ୢधӝࣿחоղী۽ӝਵب ѱ৬ӝޖ ۽ਊਵزউزחਸೞ ର۽࢚ਵాٸ߸ Hݽ࠽ܻ౭୭न҃ೱ ࢚కীਸ۽ب ਸೞѢա۾بਊ೧ߎ࢜ܳ ਤ۽بӝߡझ࠺ୢधәࣘחೠੌࣻ ӒܿŢఎܻইషܻ֢दীࢲࢎਊೞژ द۽ਵزٸҳрਸాҗೡ۽بౠ߹ೠܳ ࢸ҅ػߑधҗೣԋରח߄ՇѱؼѪੋ ೞ۽ীࢸػҕࣗীࢲীցܳҕә߉ ۞ೠߑधখਵ ನղࠗীࢸػਤীഛೞѱ۽بਸীदػ݃ܳਊ೧ର ೠ۾بର غೞѱػ ۧѱ ۽ਵزীبחਤܳ೯ೞ۽بFݽ࠽ܻ౭ীࢲਬࢶߑध ೠחӒਬ ইঠೠӘөਊ۞Ӓܳ ؘ
10/4 10/5 114 Development Feature 115
ରস҅աزߥ݃۽ઑসٜ۞ ഋചػӖઁח߂ &$6ܳࢤೞҊ *40*&$ ౠ ־ ೡࣻۄਬੌೠߑߨחࣻ ࢤসٜनٜઁۄഋਬࢶߑधਸѐߊ ੋמࢶ۱࣠ਸਤೠ*40*&$ ೠઁಿٜਸޖח ڃয٣ࢲয о݃݅ఀীցܳઁ ౸ݒೡࣻѱٜ݅যળ۽ؘࢎਊೡࣻ.*$304"37( ಿਸҴઁਵחҊೡࣻ ೞۄળഛ ۽೧ߨਵӒী ٙ೮ਵݴஂ۽ઑѤਵ ਊ&$6ܳѐ ܳా೧ࣁ҅пҴ݃࠺ਊ࢚थਸୡחղࠗীಿରઁ ޖ815ܳਊೠחળୡউઁ ݈ޙחоೞחعఋೠҳࢲоࢤࢿ ࣌ਸҳഅ೧ঠܖౠ߹ೠࣛب߹חदఃې W&74&ઁಿ ߈ݶחغؘࢎਊחҊ ߊೞܖೠੌ߈ੋࠁܳߑߨࢎӝաয়ਊ ࢶాनীחৈӝীࢎਊೞ दী۞ೠ࢚ടزઁ ࣗীࢲࢎਊೡ*40*&$ӝ߈ ೡਃоহয ߈ݶחਊࢎ۹ܳೞҊ ਸߑೡࣻযঠೠா࠶ਸਊ೧ ਵݴ ݄ ೠైܳୢदఃݴؘࢎਊػ۠ࣛ Fݽ࠽ܻ౭ীחೠਃҳࢎ೦ਸ ೠాनਸҳഅೞషী۽חэਃҳࢎ ীࢲبী҃חࣗীࢲೞ ࠁਸೞח)PNF1MVH ೠѐߊ࠺ਊਸೡࣻ ࣌ೞ٘ਝযੋఠಕझܖ ী$&*40*۽Ҋ݄݃ਵܖ $%"$߂ ೦ਊػਬࢶߑध ѐ۽4JHOBM-FWFM ѱؼѪ݅ডӝରܳҴઁਵ ߂4-"$ ۨয৬ؘఠ݂ۨয (SFFO1):Ąܻޛח֙ୡী*40*&$ ࢲח҃ী ࢶߑधਸನೣೠળചػޖ ࣁझ ߊೞҊ۽ ߆ী ܳೞҊ "UUFOVBUJPO$IBSBDUFSJ[BUJPOعળ৮ҕ חী҃חغೞѱࠁәоߑۄܲળചӝҳ ܳನೣೠ*40*&$ݽٚࣗਝ ੋبߑधਸਤೠ%*/41&$ *40*&$৻ী$%ب ীӛ VTFSBDDFQUBODF بযҙ۲ਃҳࢎ೦ٜਸਗೞҊ ࢎਊࣻਊ ܖౠ4"&ীࢲ815ܳਊೠాनࣛ ۠ળٜਬۣ ٜبળ 40ળীࢲ࠺ ੋബҗܳоઉৢѪ*ח҅ױߣ૩ف &"ೠসਸ೯݈4दझమળ ࣌ী$%$"חীࢲࢎਊೞ ਬࢶӝࣿҗ࠺ୢध۽ݽٚী࠺ ୢधदझమীਃೠݽٚӏѺਸ पઁ$&*40*ب$PNCJOFE$IBSHJOH ળী दझమాੋ ాनపझܳਤೠझ݃ܲٮӒܿŢ߭ఠীࢲदೠ97ݽٕ,62,(&ળী ࠁੋৈ۽ࠁ৮ೡѪਵܳ۽ӝࣿࢲ ۽࠺ୢधߑधਵ۽Ӓ۞ա ӏೞݶҍ߄ڷחੌࠗܳҳࢿೞҊ Ѽೡ݅ೠо $$4 नݽٕ 4ZTUFNా 40ࣗਤਗഥী ӝࢲਃೠਬࢶߑधӝୡੋ*חѪ߭ఠחਸ ೞ (# ഋ Ҵই815ীҙ۲ػҴоળמחળীࢲ$&*40* חࠁә೧ঠೠ۽ݢҴਵܳۄীӓଵৈೞҊ زࣁ ଵо೧ળചഝ ࠛҳೞҊبߑधաझ݃ ҕೠহӒۢী JOUFMMJHFOUDIBSHJOH ې߭ ߈ݶী࠺ୢधߑधكীगైоܰীࠄࢎܳޙٸӝࣿ߂ాनഐജࢿ ӝ۽ߑधਸਤೠ ҅ਵ TNBSUDIBSHJOH ޙ ١ࢶఖ١җҙ۲۞ೠٸӝରоनഐ١ীݥࢲਸ ೞ݅ӝח೧࢚ೠਫ਼۱ӝ࣌җഛ ীܖݒनࣘೞѱ815ਊࣛחݽٚҴоળ߂Ҵ ఠח ాनীҙ۲ػݽٚࢎ೦ਸӏೞҊਵ ਸഛࠁೞӝਤ೧ࢲఠٜ୭ۄೞӒ۞ա۞ೠदա ઁٜҗӝఋ݆מѪоחೞ ࢚ࣻળ߸ഋ೧ঠೡਃоܳۄ ઓੋחਬ ݽٕਸઁҕೡࣻৈӝী ળਸੌदఆਃо࠘ઁ ز ਃӘ࠺ਯഈ࢚ ೠোѾ߂ੋૐژ ೠߊৌࣻળ ݴמೲਊо աബਯࣻળ য়ܳഅपചदఃӝীӝࣿ߂ળചܻ ݶҙबغܐ߭ Ҵઁੋઑച֢۱৮חؘࢎਊೞחળӝҳٜա4"&߂*40*&$ दझమਸపझೞחীۣ ೱറझ݃Ӓܻ٘ী ҙܻ ؘఠ١ਸѾೞѱػ؊ Ѿઁמաӝఋࢿ ޙоஏݶীࢲӓࠂ೧ঠೡ݆فחۄ ࢎۄٜ࠺ୢधੋైח ח߭ఠ ನೣػٜܳযب١അ815ܳਤೠҕాળਸѐߊ ఠోٜ Ҋ݅ডܖೣԋبӝࢤழಁ ೠਃҳࢎ೦١ ೱܻޛӝఋনೠ о ઁ ଵৈೡѪੋݺഛೞѱؼبוসীয 75۽۞ೠ 754ZTUFN)*-పझఠਊਵبౠҴ ইदইח࠙ঋݶ ઁ۱חীࢲҕәೞݎѺܻࣚप ۱ QBSBTJUJDDBQBDJUBODF ѐੌ दఢझف࠺ୢधߑध ٘ Ѫۑଵೡਃо যఠܳೠౠ߹ೠ75زରীࢲद ীزҊ۰೧ঠೠ ҙܻदझమӝب೧ࢲ١ী JTPMBUJPOMPTT ਸ߄ DPVQMJOH ழ݂חࢎীࢲੌযա ࣌ӝରٜౠ߹ܖࣛز Ӓܿ ܳઁҕೞҊ SBDLDBSE %*4 ೠҴઁળী$&*40* بীցܳदҕәೡࣻ۽ਵݎ۱۽ ࠛҳೞҊӘبীઁޙউ ۞ೠݽٚزೞҊ۞ೠഅ࢚য়ۖ۽ఔਵ ࢶޖبחҳрਸ೯ೞ۽بী ࢸ҅ػ 4$$ झ݃ాनח%*4ઁ ۞ೠ࠺ ਵݴعড *40*&$r)PNF1MVH(SFFO ୡউ֙ୡীҕחਗܻ өঌ۰࠺ୢधࢎসীࢲزঌ۰ઉৡੌ߈ੋ߸ӝ ೧Ѫ۾بীցܳՑযৢࣻ۽ؘࢎਊ ਵחਸਗೞ્פա ਃೠݽٚݫழ݈֙ח҅க ৬%*4ઁܻޛࢿೞҊ 1):5.sؘఠాनਸਤೠ׳ബਯࣻળਸب ֫חೞࢿҕ೨बਃੋೞաبӝ ࠁݶ۞ೠӔߑधী۽ਸы ӝਵמӝ$"4-ח ֙ୡীҕؼ୭ઙҴઁળୡউ ೡࣻৈӝীعӝദ۽ӝࣿਸҳഅ ֙ীࢸػఎܻইदߧࢎসٜ ਵ ীޙٸࣻળബਯࢿӝ ޖ )PNF1MVH1):ాन߂18.ઁয ೠӛੋೱ֫ಣоೡ݅ೞظ۽ୡ֙חҕ '%*4 ೯ೞҊਵ۽ನ L8۱ਵ۽بؘਃೠߣ૩ӝળחೞ ݶഅغ۞ೠӝࣿਸࢎਊೞѱبӒܻҊ۞ӒোѾਸद ࠁ *&$ ࢶߑधਸਤೠ ޖ ग߄ۄ֙ী೯ਸदೠ࠳ ղࠗীࢸ աղীࢸػੌରੌҗର ই࢚ઁೠੋӝରחॄ۽ೠۨझఠ١ חL8ࣻળ۱ਸ ,62,&ഛ ,62,(&ਤೠ ޯۨ࣌ೡࣻחػରੌࢎѢܻܳ୭ࣗച೧ ӝߡझ ࣻѱؼѪܾטରա ೯Ѣܻܳѱز࣌߂పझో ನೣػ754ZTUFNӝܖ࠺ୢधߑधীࢲਬࢶ ߬٣٘ࣛۿޛ فоदझమݽفܲਃೠӝળ ਊೞҊژѪח೯೧ঠೠ ա۽ب߈Ҋࣘੌחؘࢎਊೡࣻ ӝର೯Ѣܻഛח ࣗܳदޯۨ࣌ೞ ର0&.աҕәসزѪೞঋ Ӓ۞աחਸ୭ࣗചदఃӝ L)[ࣻܳਊೞҊ ాनӝࣿਸࢎਊೞ TUSBZMPTT ਬࠗೞࣚ ۽ীࢲੌೠрѺਵ۽بदрҊࣘب өٸоѐߊؼۄ߈٘ ҙ۲স١ੋח *4004*-BZFS ۨযܻޛ חਸഛೞѱਤदெঠೠਤ೧ର ࢿೡࣻ׳ॄ۽ҳрਸాࢸೣਵ ݎೠগܻா࣌ۨ ӝܾਃоহ*40*&$ ਃড߂ژঠೠظ द߸҃ ഛೠରਤܳӝਤ೧ࠁઑ ,62,(&ਸాೠాन ױೂ۱ߊחীࢲੌةզטীࢲ ਸѪয়ޙFݽ࠽ܻ౭ࠗחߥળച۽࠺ୢधߑध࢚ࠗ࠙ Ӗܲٮࣻਃೞ GGীب *4004*-BZFS ࢲ࠺झоؼѪ ਬࢶߑधળ যחदझమо ۽߸ীਵ۽بࠗ࠙Ҋࣘ౸ݒद ӒܻҊ ؘחҳܳج ҅ױীޙٸೞӝੌز࢚ࣻоഅ ਬࢶߑधҗח࠺ୢधߑध *40*&$ࢎসਸ୶ೞ ҕҕ ܨઙ מؘযࢲষդਃࢿਸ ۠ೂ۱ߊٜࣗ࠺ୢधӝחܻ٘فਸޙ $&*ࢶ ӔߑधਸӂҊೠٜܳয*40ޖ ೡ݅ೠా ۞ೠসী۱ೞҊਵݴ܉ࢎীनۄҗੋӓࠂ ରઁޙӝࣿੋ ҳрীࢲܻੋ࠺ਊਵ۽ب۠ࢎ೦ਬࢶߑधա࠺ ਸࢸೠ ݴפ ػ߬٣ܐҊ৮غѱపझݏਸਤೠ*40*&$ળ ী 815 ݶઓೡࣻহਸѪ ۱࣠חঋܞٜೠ नઁޙܲӝࣿੋ
۱ਸҕәೡࣻѱؼѪAE۽ ೞѱਊػੌزف࣌അ߭ఠীࢲҳੑೡࣻ ୢधߑधীݽܖীೡ ਸѐߊೞҊ ٘ࣛޙ೨बੋ۽ੌ Ѫঠ݈ ࣻળܨࣻߧਤࢶҗ
10/6 10/7 Development Feature
2011 OCT ~ DEC 69 68 www.autoelectronics.co.kr
10/8 10/9 Development Feature
70 www.autoelectronics.co.kr 2011 OCT ~ DEC 71 10/10 10/11 Development Feature
CANoe 배터리 시스템의 안전성 검증
Case Study ZSW
고객정보 장점 독일 울름(Ulm)에 위치한 ZSW Laboratory for Battery Tech- 내구성능 로깅, 데이터 관리 및 모든 것을 “한 눈”에 확인할 수 있 nology(eLaB)는 독립적인 배터리 개발 및 테스트 전문 기관으 는 그래픽 시각화 로, 배터리 관리와 함께 셀, 모듈 및 배터리 시스템 테스팅 분야 > 배터리 및 BMS에 대한 광범위한 테스트 가능 에서 국제적으로 인정받고 있다. 이 기관은 배터리와 슈퍼 커패 > 매끄러운 테스트 진행을 위해 테스트벤치를 6개월 이상 연속으로 시터 분야에서 25년 넘게 경력을 쌓아온 연구원들로 구성되어 작동 있다. 전 세계 수많은 기업들과 연구기관들이 ZSW Laboratory > 주행 주기 및 전력 프로파일에 대한 로그 파일을 명확히 추적하여 for Battery Technology의 고객이다. 투명성 확보 (동작 및 오프라인 모드 모두 해당) > 사용자가 정의 가능한 트리거 조건에 기반한 다양한 로깅 전략 기술적 과제 > 그래픽 시각화를 통해 주요 배터리 파라미터들에 즉각적이고 지 증가하는 변수들을 고려한 배터리 시스템의 안전성 검증 속적으로 접근 가능 수개월에 걸친 심층적인 테스트를 통해 배터리 관리 시스템 > 다양하고 편리한 검색 기능을 활용한 오프라인 분석 가능 (Battery Management System, BMS)의 안정적인 작동과 긴 배 터리 수명을 위한 기반을 다지는데, 이 테스트 항목에는 긴급 차 단, 충전 주기 등과 같은 실제 및 가상의 성능 프로파일을 포함 한다. 여기서 기술적인 과제는 테스트의 완전 자동화를 구현하 고 방대한 양의 테스트 변수 및 데이터를 다루는 것이다. CAN 통신 데이터 하나만으로도 테라바이트에 이르는 방대한 양이기 때문이다.
솔루션 배터리를 위한 고성능 내구성 테스트벤치 구현을 위한 액티브 전 력 제어기와 CANoe의 통합 시험 대상 시스템(System Under Test, SUT)의 모든 전력 및 통신 인터페이스 장치들이 배터리 관리 시스템(BMS)과 배터리로 구성 된 배터리 테스트벤치에서 실행된다. (그림 참조) 액티브 전력 제 어기는 직류 전류를 공급하거나 소비하는 역할을 한다. PC1 상에 서 흐름 제어는 전력 프로파일을 자동으로 실행한다. 별도의 PC2 에 설치된 CANoe 테스트 툴이 버스 시뮬레이션의 CAN과 LIN 네 트워크에 대한 모델을 담당한다. 이 두 시스템은 기존의 차량 버 스를 통해 직접 통신한다. 테스트 진행 상황에 대한 지속적인 모 니터링을 위해 CANoe 패널 상에서 인터페이스가 제공된다. CAN 기반의 CANoe는 측정 결과를 적절한 크기의 바이너리 로 그 파일들로 나누어 관리한다. 해당 로그파일들은 언제든지 관련 된 내구 테스트의 Trace 데이터로 볼 수 있다.
72 www.autoelectronics.co.kr
10/12 10/13 그림 1: RAM 복사 방법 및 넥서스 클래스 2+ 인터페이스를 활용하는 측정 신호에 대한 데이터 흐름 개념
어가 다양한 ECU 작업의 주기 시간에 따라 RAM 복사 기능을 시 자는 ECU RAM에 최대 총 크기가 512kByte인 하나 내지 두 개의 작한다. 측정 신호는 XCP on Ethernet을 통해 미리 구성해야 한 모니터링 윈도우를 구성한다. 이러한 모니터링 윈도우 내의 모든 다. 신호 이름과 RAM 주소의 매핑은 A2L 파일(신호 기반 RAM 변경 사항은 추가적인 CPU 로드 없이 넥서스 클래스 3을 통해 액세스와 관련하여 ASAM에서 표준화한 ECU 설명 파일)에 기술 POD로 전송된다. 고속 시리얼 링크 케이블을 사용하면 최대 되어 있다. 모든 측정 신호가 복사되고 나면 기존 디버그 인터페 100MByte/s의 원시 데이터 전송 속도를 얻을 수 있다. 이 개념의 전기 및 하이브리드 차량을 위한 고속 계측 이스를 따라 측정 데이터에 대한 기본 모듈로 신호가 전송되는데 이점은 측정 데이터에 대한 기본 모듈에 ECU RAM의 일관되게 (그림 1), 이 개념을 “온라인 데이터 수집(OLDA: Online Data 미러링된 RAM이 항상 포함된다는 점이다. ECU 소프트웨어가 트 높은 데이터 속도와 빈번한 샘플링 횟수를 지원하는 신개념 계측 Acquisition)”이라고 한다. 이 방법을 사용할 경우 CAN에 비해 측 리거되면 측정 데이터 기본 모듈 내의 데이터 흐름이 일시적으로 정 데이터 속도와 샘플링 속도가 20배 가량 개선된다. 즉, 중단되는데, 이 경우 새로운 변경 사항은 RAM의 FIFO(First In, 전기 및 하이브리드 차량을 개발할 때는 특히 내부 ECU 신호를 측정하는 데 사용되는 계측기에 대한 요구 사항이 매우 높다. 하지 10~20kHz의 샘플링 데이터 속도로 0.5~1Mbyte/s의 측정 데이 First Out) 버퍼에 저장된다. 측정은 최대 256개의 서로 다른 소 만 최대 30Mbyte/s의 측정 데이터 속도와 100kHz의 필요한 샘플링 속도를 얻으려면 최신 세대의 마이크로컨트롤러와 지능형 계 터를 얻을 수 있는 것이다. 복사 작업 시에는 1Mbyte/s에 약 4% 프트웨어 트리거를 통해 시작되며, 미러링된 RAM의 콘텐츠는 “ 측기 솔루션을 사용해야 한다. 여기서 ECU의 CPU는 로드되지 않는다. 의 CPU가 로드된다. 고정(Frozen)”된다. 신호는 측정 구성을 토대로 측정 데이터 기본 모듈의 미러링된 RAM에서 판독되어 XCP on Ethernet을 통해 측 넥서스 클래스 3을 위한 데이터 추적 개념 정 및 보정 툴로 전송된다(그림 2). – 현재의 프리스케일 파워PC 넥서스 클래스 3 솔루션의 이점은 다음과 같다. 전기 또는 하이브리드 차량의 구동은 일반적으로 펄스 폭 변조 on Ethernet을 통해 수행된다. 물리적 연결에는 표준 CAT-5 이 현재의 프리스케일 파워PC 시리즈에 포함된 대부분의 디바이스 > 최대 측정 데이터 속도인 30 Mbyte/s는 넥서스 클래스 2+보 (PWM) 신호를 통해 제어된다. PWM 기법의 이점은 이 기법을 사 더넷 케이블이 사용된다. 측정 방법은 본질적으로 크게 두 가지 는 넥서스 클래스 3 데이터 추적 방법을 지원한다. 이 경우 개발 다 30배 높으며 XCP on CAN보다는 600배 높다. 용할 때 전력 스위치에서 발생하는 전력 손실이 매우 낮다는 점 로 나누는데, 하나는 “RAM 복사 방법”이고 다른 하나는 “데이터 이다. 전력 스위치가 완전 전도 또는 완전 차단의 두 가지 상태로 추적 방법”이다. 본 기사에서는 현재 나와 있는 마이크로컨트롤 만 작동하면 되기 때문이다. PWM 신호의 주파수는 대개 러와 곧 출시될 새로운 마이크로컨트롤러를 토대로 이러한 두 10~20kHz 범위에 있으며, 예외적인 경우 100kHz까지 올라가기 가지 방법을 각각의 장단점과 함께 살펴보기로 한다. 다른 데이 도 한다. 내부 ECU 신호에 대해 1kHz에 불과한 최대 샘플링 속도 터 추적 방법에서는 주로 파워트레인 ECU 및 이러한 ECU의 후 를 얻을 수 있는데, 이 경우 차량 개발을 위해 광범위하게 사용되 속 제품에서 사용되는 두 가지 유형의 32비트 마이크로컨트롤러 는 표준 측정 및 보정 프로토콜인 XCP와 CAN 또는 FlexRay 버스 (프리스케일 파워PC[Freescale PowerPC], 주요 시장: 미국, 인피 시스템을 통한 통신이 함께 사용된다. PWM 신호는 이 방법으로 니온 트라이코어[Infineon TriCore], 주요 시장: 유럽)를 참조한다. 는 수집할 수 없다. RAM 복사 방법 바로 이 때문에 ECU 변수에 빠르게 액세스할 수 있도록 디버그 RAM 복사는 일반적인 방법으로, 다양한 제조업체가 생산하는 및 데이터 추적 인터페이스가 사용되는 것이다. 이러한 인터페이 현재 및 미래 세대의 32비트 마이크로컨트롤러에 사용할 수 있 스는 구현되는 마이크로컨트롤러의 유형에 따라 크게 달라질 수 다. 인피니온 트라이코어 또는 XC2000의 경우에는 디바이스 액 있다. 측정 하드웨어는 “플러그 온 디바이스(POD: Plug-On De- 세스 포트(DAP: Device Access Port) 인터페이스를 통해 액세스 vice)”를 통해 ECU와 상호 작용한다. 마이크로컨트롤러의 디버그 가 이루어지고 프리스케일의 파워PC 디바이스 또는 르네사스 핀과 POD 간에 허용되는 최대 거리는 10cm이다. 계측기 모듈과 (Renesas)의 V850 E2 프로세서는 넥서스 클래스 2+(Nexus Class 테스트 PC 간의 통신은 ASAM의 MCD-1 XCP 표준에 따라 XCP 2+)를 통해 액세스가 이루어진다. 이 방법에서는 ECU 소프트웨 그림 2: 데이터 추적 개념 및 넥서스 클래스 3 인터페이스를 사용하는 측정 신호에 대한 데이터 흐름 개념
10/14 10/15 > CPU는 일반적으로 측정 시 로드되지 않는다. 전송 속도인데, 현재는 이전의 5MByte/s에서 개선된 20MByte/s 링크: > 모든 PWM 구동 신호를 아무런 문제없이 100kHz의 샘플링 속 를 자랑한다. 이를 위해 DAP 인터페이스에서 이전의 80MHz 대 벡터 ECU 보정 툴: www.vector.com/vi_calibration_solutions_ 도로 측정할 수 있다. 이 솔루션의 단점은 POD를 자체의 25개 핀 신 160MHz의 높아진 주파수를 사용하는 것은 물론 두 개의 라 en.html 을 사용하여 마이크로컨트롤러에 연결하는 데 많은 노력이 들어 인에서 병렬 전송을 허용하는 새로운 유형의 3라인 개념이 사용 VX1060 측정 및 보정 하드웨어 제품 정보: www.vector.com/vi_ 가며 100 Mbyte/s나 되는 많은 양의 원시 데이터 스트림을 처리 된다. vx1060_en.html 해야 한다는 점이다. CANape 제품 정보: www.vector.com/vi_canape_en.html DAP2 인터페이스에서 가장 크게 개선된 부분은 이제 이 인터페 차세대 마이크로컨트롤러를 위한 데이터 추적 개념 이스를 통해 극도로 미세한 세분성을 바탕으로 하드웨어 기반 데 저자: 핀 수가 25개에서 5개로 줄어들었으므로 차세대 마이크로컨트 이터 추적 필터를 설정할 수 있게 되었다는 점이다. 이를 통해 마
롤러에서는 넥서스 클래스 3 솔루션의 주된 단점이 사라질 예정 이크로컨트롤러에서 POD로 불필요하게 데이터 추적 정보를 전 이다. 하지만 측정 데이터 속도와 샘플링 속도는 변함 없이 높은 송하는 일이 대폭 줄어든다. 최대 측정 데이터 속도는 10Mbyte/ 레벨을 유지하게 될 것이다. 이 데이터 추적 솔루션은 인피니온 s지만 100Mbyte/s의 원시 데이터 대신 15Mbyte/s만 처리하면 과 프리스케일에서 향후 선보일 프로세서에서도 지원될 전망이 된다(그림 3). 측정 데이터의 처리 요구 사항이 대폭 줄어들었기 다. 그리고 여전히 100 Mbyte/s의 원시 데이터 스트림을 처리해 때문에 DAP2에는 비용이 최적화된 측정 계측기를 사용할 수 있 야 한다. 다.
현재의 인피니온 트라이코어에 대한 데이터 추적 개념 요약 넥서스 클래스 3에 필적할 만한 한 가지 개념을 DAP에 사용할 수 순수 또는 하이브리드 전기 차량의 첨단 구동 개념에 내포된 많 도 있다. 이 과정에서 측정 데이터 수집을 위해 256kByte 메모리 은 측면은 측정 데이터 수집을 위한 새로운 전략을 개발해야 할 알프레드 클레스(Alfred Kless) 범위의 ED-RAM(Emulation Device RAM)을 예약해야 한다. 넥서 필요성을 불러일으킨다. 내부 ECU 신호를 위한 기존 계측기 개 알프레드 클레스는 에슬링겐(Esslingen) 기술 대학에서 전기 공 스 클래스 3 개념의 100MByte/s와 대조적으로 원시 데이터의 추 념은 데이터 속도 또는 샘플링 속도 면에서 한계에 도달하는 경 학 학사 학위를 취득한 후 알카텔(ALCATEL)에 입사하여 테스트 적 전송 속도는 5MByte/s로 제한해야 한다. 25개 대신 4개의 핀 우가 많다. 전자 구동 시스템에 필요한 최대 100kHz의 샘플링 속 시스템의 소프트웨어 개발 및 비즈니스 개발 팀장 등을 역임했으 이면 충분하기 때문이다. RAM 모니터링 윈도우는 최대 4개까지 도는 벡터(Vector)의 VX1000 측정 및 보정 하드웨어를 사용하여 며, 2004년 5월부터 슈투트가르트에 위치한 벡터 인포매틱(Vec- 구성할 수 있으며, 추적 데이터가 초과하지 않도록 구성해야 한 기존 및 미래의 마이크로컨트롤러에 대해 구현할 수 있다. 올해 tor Infor¬matik)에 입사하여 “측정 및 보정”, “네트워크 인터페이 다. 이 경우 대개 프로세서 로드 없이 512kByte 대신 10~20kByte 프리스케일과 인피니온에서는 필요한 핀 수가 훨씬 적은 데이터 스” 제품 라인을 담당하는 비즈니스 개발 매니저로 근무하고 있 에 불과한 메모리와 이 메모리의 신호 측정값을 모니터링할 수 추적을 통해 해당 작업을 수행할 수 있는 새로운 세대의 컨트롤 다. 있다. 이러한 추적 모니터링 메모리 영역 외부의 신호는 RAM 복 러를 선보일 예정이다. 이러한 컨트롤러는 올해 하반기에 출시 사 방법을 통해 측정할 수 있다. 예정인 벡터의 고속 VX1131 측정 모듈과 함께 CPU 로드 없이 30Mbyte/s의 측정 데이터 속도를 구현하게 될 것이다. 인피니온 DAP 데이터 추적 솔루션의 이점은 다음과 같다. > 최대 측정 데이터 속도인 3Mbyte/s는 RAM 복사 방법의 3배 인피니온의 경우 마이크로컨트롤러에서 미세하게 세분화된 신 이다. 호 필터를 갖춘 DAP2 덕분에 원시 데이터 스트림을 100Mbyte/ > 측정 시 마이크로컨트롤러가 로드되지 않는다. s에서 15Mbyte/s로 줄이고, 이를 통해 매우 경제적인 측정 하드 > 모든 알려진 PWM 구동 신호를 아무런 문제없이 100kHz의 샘 웨어를 사용하여 높은 데이터 전송 속도를 얻을 수 있을 것이다. 플링 속도로 측정할 수 있다. ASAM에서 표준화한 XCP on Ethernet을 PC 인터페이스로 함께 사용하는 경우에도 이 측정 및 보정 하드웨어는 대기 시간이 짧 미래의 인피니온 컨트롤러에 대한 데이터 추적 개념 은 유연하면서도 강력한 바이패스 솔루션으로 사용하기에 적합 인피니온은 차세대 마이크로컨트롤러 부문에서 최신 세대의 하다. DAP를 선보이고 있다. 한 가지 이점은 보다 높아진 원시 데이터
그림 3: 데이터 추적 개념에서 미세하게 세분화된 필터는 DAP2 인터페이스를 통해 이동하는 원시 데이터 스트림을 15Mbyte/s로 줄여 준다.
10/16 10/17 Development Feature J1939 Standardization
Doukment Stand Status
SAE J1939 표준화 현황
새로운 애플리케이션 계층 요구사항으로 인해 SAE는 상용 차량의 파워트레인을 네트워크로 연결하는 데 주로 사용되는 J1939 표준의 개발을 지속적으로 수행하고 있다. 그러나 최적화와 확장은 물리 전송 계층에 이르는 다른 통신 계층에서도 활발히 이뤄지고 있다. 500 kbit의 물리 전송 계층 도입과 네트워크 관리 변경사항 같은 SAE J1939 연구위원회의 진행 현 황을 살펴본다. 또 AUTOSAR 릴리스 4.0 및 WWH - OBD 진단 부문의 J1939 표준화 추진 노력도 알아본다. ż൷ኄ 2ŽTBF!K2:4:!ጾᕷႁᢉ ᷪṤ )3121 : ᢩᷪ*
᪸ႁ ಃඎ៲ ᆵឥ ೃᤤ ໗ኀᇕ ᷆ ᗀ၍ ᢘ/ TBF! K28190K2698ឥ ᓳၟ࿒ ᶽ ួᐿ ᷃ ᢘླ/!ᓳᜭ K2:4:.25ᇢ ໆྏ᜴ ፯ᶙ .!ᎆᙂྜ 231! Ґᢉ ᳥ᖄ ᢕᶻ࿒ᙂᇢ ᜭᨈ ᇢ ᤤ᷅ླྜ ᤡᢎླ/! ႓ᅉᕷ K28190 ൻԘ피터 펠메스 )Qfufs!Gfmmnfui*!! ၡ ួᤤᢎླ/!ᥖ៨ ໗ ླ ಒླ/ ዂၦឥᕷ ྶၢ/! K2698!᳤ᰡྜ ࿏ ᢎᓿŰᡱᷰ JJűᢉ ྶ K2:4:-!JTPCVT-!ᢎ࿏ ፧ Dbs3y!ᐜጾ ൷ሀ ᪡ᢕ-!Wfdups!Jogpsnbujdl!HncI!! 홀거 소늘레 )Ipmhfs!Tpiomf*! ᶷᇃ൷ቸ ᱣ᷌ ᥖᖜቸ ᤤ᷆ ᗀ ླ/ K2:4:!፧ JTPCVT!ᢕᏱႈၽ ᖜᶵ᳤᠂᜴ ᐜጾ ኗྩᢼ-!Wfdups!Jogpsnbujdl!HncI*!!!! .!ၦ ፸ᢉ ᐆၽᡴ)361! lcjuಃ ᜌྫ 611 ྶ ᶷᇃ൷ឥ ࿅᷅ ᓳᜭ\5^ 611!lcju!ᢝ 피터 펠메스 홀거 소늘레 lcju*/ ၗឥ ኔಶ ಕᤤၞླ/!ᄝ ༈ᔂ ᭽ᇃ ᮔ႑ᢎ 동적 주소에 대한 SAE의 고민 .!\3^!፧ \4^ឥ ᤤᢉၠ ᨵᴩ ፧ ᐿᨵᴩ ᮃᢎ ᤤၠ ᨵᇂឥ ᔁᇢ៲Űᡱᷰ JJ)Uzqf!JJ*űᢉ ᳤ᰡ ೞኀ ឹឮឥᕷ၍ ᏽೈၠ ᐜᐞᢎ DBO! ᎆᙂ)JTP! 229:9ឥ ႓ቷ ᖝ ᇢ ൘ᖄၝ ᢘླ(그림 1)/! ᢎ ᶙᥘ ࿁᷃ 늘어난 대역폭 ᐻ ೊᖝ ᓳ ಃྣ/ ྶ ᖜᮉᢎ ᓳၟኹ ᷌࿁ ᭹᱅ ᰨ ឰೃ ፶ ᢘླ\6^/! ᷅ ၗᜎ K2:4:! ᡩṪྜ ឹ൘ᢽ DBO*ቸ ං፭ᇢ ᷃ྜ TBF!K2:4:!ᶙᥘ ྜ TBF!ᐜᖝ ᡩṪྜ ኗ 5ᨵᇞᢉ Ṫᢉ ᢩᷪඎ ዀ ၗᜎ ᢎ ᶙᥘឥ ᤤၠ .!ᱜᴰᇢྜ ࿅ ආᢎಃ 2! nᢐ ᐞං ᅉ ᙌᇢ ᢐ᷌ ᢎᢾᢉ 361! lcju!Űᡱᷰ J)Uzqf ᇢ ᷆࿁ၟྜ FDV! ᥖᖜ)beesftt*ಃ ᐜᤷ᷅ ᥖᇢ ᓿ ᨵᇂᢉ ᳺ᳤ᇍᢐ ፧ ᔁᙋ ᳤ ቸ ᱣ᷌ ᏽೈᓳ᷋ ಃ ಕ፯ ᓳ᷋ ೃᤤ ࿅ 361! lcjuᢉ ࿅ឮᴮᇢ ᢐ᷌ ᓿ ᨵᇂ ᢐᢎ ᢘྜ ᎆᙂ/! ྶ ᱰ ឰೃ᷃ං ᡩ J*űᢉ ྶ ᶷᇃ൷ྜ ᓳ᷆ ᗀ ླ/!Űᡱᷰ ᓿṤ ኀ᷃ྜ ፶ᎍឥ ࿅᷌ ኋ ༉ᢉቸ ᰡឥ ᓳၠླ/!ᢎ ᶵᇢᱜᮗ ᢾᢜ FDV ᷅ླ/! ጾᕷᢉ ᢩᷪ ᎆᢾ TBF! ᡧ ᓳᢎ᳤ ಕ፯ᢜႁ ᖄྣᓿ ᤦ᷅ ፮ኹ ឰ൘ቸ ᷌ᕷྜ ೈ៰ឥ ႓ᅉ ආᢎಃ 6!nᢐ ᐞං JJűᢉ ᶷᇃ൷ྜŰᡱᷰ Jűᖜᮉ ṕṡၠླ/!ᄝ ᷌៘ླ/!᳥ẩ ᢎྜ ᎆᙂឥ ᤢ ឰೃၟྜ ᖈ ಅᢉ ᱣᙍ ᡩ᷅ ྶᢑṟၠ ᱜ࿅ቸ ᷰᖄ᷃ ឥᕷ ಕᢽᇢ ൘ኗ᷆ ᗀ၍ ᢘኹ ᷔ᷆ ᗀ፫ឥ ᝀླ\3^/!ᱣᙍ ኻឥᕷ ᐆ ᅉᢐ)ྶ ᖜᮉឥᕷ ྶ ᱰඎ* ᓳ ླቷ ᏽṟྜŰᡱᷰ JJűྶ ᖜᮉឥᕷ ᢎᢾឥ ᕷቸ ᤦᤶ᷃ྜ ᪸ឥ ᢘ᜴ ጾᤦಃ ၞླ/!፸ ኹ ᶷᇃ൷ ᶷᇍᢎ ኀᇢ ᢝၗ᷅ླ/!ᢩᷪ ŰQbltűᅉྜ ᴆᰨᇢ ᢑ ൘ኗ᷆ ᗀ၍ ᢘ ኻ 611!lcjuᢉ ွᢎ᱅ ᢾᖥ ೊ ಕ፯ ᷅ ᓳၟ ᢘྜ K2:4:! ᶙᥘ 2:ಕᢉ ጾᕷ ླ\2^/ ᨺ ྤ ಊᢎ ᢘླ/!ᡱᇈᢉ ᓿ ᨵᇂ ᤦᤶ Ƙ ᢎ ൻ ၎ᢑ ፀ Fmfluspojl!Bvupnpujwf!3121 23ṕឥ ಶᢩၠ ໗ ᎈឮ᷅ ಯᢖྩླ/!!൷ኄᶙ ᤦ;!Wfdups!Jogpsnbujl!HncI
90 www.autoelectronics.co.kr 2011 FEB·MAR 91 11/0 11/1 Development Feature J1939 Standardization
ංಃᙂ ൴ᤦ ᗀᥘᢎ ༐ᜌ ᐆᤶ ᙋᙂ᱓ ᢽ ᥖᖜ)Eftujnbujpo! Beesftt-! EB*ឥ ࿅ ᢎ ಃၢឥ ႓ᅉ ᔁᇢ៲ ႈ፩ᢎᙂᢉ ᗀಃ ᷅ ၍ᢉ ᤤᢽ ᙌᢜቸ ኊၽྜ ፶ᙌᇢ ൾᖝẩ ಃ᷃-!ᢎឥ ႓ᅉ ᖈᕷቸ ᡩ᷅ ᢾ BVUPTBSឥᕷ ዂ၀ኇ᷆ ᗀ ᢘླ(그림 2)/ ᳤ᰡឥ ᔁᇢ៲ ᶵᇢᱜᮗ ൘ᷪ)ួ; K2:4:!᳤ᰡᢉ ዂၿ ༇ၽቸ ᜑ ᢘ ᢎᢾឥ ួᜦၠ ွᢎ᱅ ᴚᢎ ᓳ*᷃ྜ ಯ ൘ᖄ ᙋ ༇ၽ ᥖᖜቸ ᢎ ᤤᢉ᷅ ᓿᅉኻ ឥ ᢎትංඎ ኋ ࿅ᜎႁᢎ ᤦᙋၟᝀኊ K2:4:!QHቸ BVUPTBSឥ ኗ᷂᷃ංಃ ᐿ ዂၦ ಧᐜၝ ៘ླ/!ᢎಒ ᓿṤᢎ ᖝၟྜ ᢽ ᘹླ/!ᢎಒ ᤤᢽ ᳤ᰡឥᕷྜ FDV ၗᜎ TBFྜ ᔁᇢ៲ ᥖᖜቸ ಃ ᷆࿁᷃ ᥖᖜಃ ᤤၟං ჽጾᢎླ/! ႓ᅉᕷ ፯ᙍ ᜐ-! ᢎྜ FDV! ൾ᪸ឥಶ ኊᤷᙂᇈ ፧ ዃᢽ ᥖᖜಃ ᤤၟං ჽጾឥ ᤤᢽ ᙌ ዊ᷅ ᓿṤᇢ ᢾಕၞླ/!ᄝ ൾ᪸ႁ ᢜቸ ᱣ᷌ ᢝၗ᷆ ᗀ ᢘಶ ၠླ/! ᷌࿁ ᤦᶤ ႈᢜᢐᢎ ឹ൘ᢽᢐ ಃ᭛ቸ DBO!ᶵᇍᢕឥᕷ ᓳ᷆ ᗀ ᢘྜ 9፩ᢎ᳤ ྩಶ ၡ ዂትྜ ೈ៰ಃ ࿅ᐜᐞᢎᝀླ/! ಃ ྜ ွᢎ᱅ቸ ᢾᖥ᷃ං ᡩ᷌ K2:4:.32 ż൷ኄ 5ŽXXI.PCEྜ 7ಕᢉ JTP!38256!ጾᕷឥ ᙋၟ᜴ ᢘླ TBFྜ ᙍ ᎆᢾᢉ ᳤ᰡ ೞኀ ឥᕷྜ ၦ ಕᢉ ᢾᖥ ᶵᇢᱜᮗ)UQ*! ᏽᷰ )Ofuxpsl! Nbobhfnfou*ឥᕷŰBBD ᤤ᷃ ᢘྜွ-! ᷃ໆྜ ᐸᇢၽ᭭ᙂ᳤ )Beesftt! Bscjusbsz! Dbqbcmf*űFDVቸ ൘ ኰᙋ)CBN;! Cspbedbtu! Boopvodf ᷪ᷃၍ᇣ ൧ᢧ᷃ ᢘླ/!ᢎᇃ᷅ FDVྜ ᗂ Nfttbhf*ᢉ ᏽᷰᢎ ླቷ ᷃ໆྜ ឰೃ ዂ
ಅᢽᢐ ᨵᇂ ൘ᖄ)npnfoubsz!wfijdmf ż൷ኄ 3ŽK2:4:!᳤ᰡ ᜎឥᕷᢉ 3:ᐿ᳤ ᙌᢜᢉ ᇍᢎᜌ៸ ၽ ွᢎ᱅ ᢾᖥ)DNEU;!Dpoofdujpo!Npef dpogjhvsbujpo* ᱣ᷌ ᇅᰰᢕឥ ᡱ᷅ ᥖ Ebub! Usbotgfs-! SUT0DUTᅉ၍ ᷈*ᢉ ᏽ ᖜቸ ೊᓶ᷆ ᗀ ᢘླ/!ᢎಒ ᤢ൹፶ᙌ ᐉ ᷰᢎླ/! ၩ ዂၦ ᢎ BVUPTBS! ኃኀᙂ ᢽᇢ ᓿ ᨵᇂឥᕷྜ ᜶ᤦໆ ᤸᢩ᷌៘ Application 5/1ឥ ᤤᢉၞኹ 311: 23ᐜ᱅ ၞ ኊ-!ᙏᤦᇢ ൘ᷪၟಧໆ ᓳၠ ᢽᢎ ྜ MICROSAR RTE ླ/! ႓ᅉᕷ BVUPTBS! ኃኀᙂ 5/1 ᢎ MICROSAR COM ၗᢽ ᥖᖜ ᷆࿁ ኰ᭹ྩᥲ Ṣ᷃ྜ ಯ COM IPDUM NN PDUR ᡱᇈᢉ ኋ ᓿ ᨵᇂ ᤦᤶ᪸ᢉ ៨൘ᓳ
ዃᶙᇢ ᷃ ᢘླ/! BAM ᷋ ᗀ᷃ ᢘྜ ᖊᢎླ/
J1939TP CMDT ៓ᏼᖄ ༐ᢎᇕኻ ᳤ᰡ ೞኀ៑ ᷈ฐ MICROSAR DIAG 3123 ኍឥྜ BVUPTBS! 5/2 ᱣ᷌ Complex CANXCP MICROSAR IO
MICROSAR SYS Drivers ᔁᇢ ಃၠ ᢎቹ ೞኀ)Obnf!Nbobhfnfou* MICROSAR MEM CANTP K2:4:! ៨൘ᓳ᷋ ᐆླ ᖆᐜᢽᇢ ᷆ MICROSAR FR MICROSAR IP MICROSAR LIM XCP MICROSAR MOST ၍ ᜶ൾ᷌ᜥ ᷅ླ/!ᢎྜ 75ᐿ᳤ ႈ፩ᢎᙂ ᢎ MICROSAR OS CANSM ួᤤᢎླ/! ࿅ᓿឥྜ ᡱᇈ ፧ ᢑᐜ ᐝ
MICROSAR CAN CANIF
ቹᢉ ᳥ᤤ ᭾ᴭ᳤ቸ ᏽೈ᷃ං ᡩ᷅ ᶙᥘ MICROSAR CAL MICROSAR EXT ᓿ ᨵᇂ PFNᢎ ᴭ᷈ၠླ/!BVUPTBSឥ CANDRV
ṟၠ ᢐ᱅ᴚᢎᙂླ/! ᢎ ᢐ᱅ᴚᢎᙂྜ ೞᇗ CANTRCY ಃၡ ᷖᓿၠ ᥖ៨ ᓳᜭ ླ ಒླ/
ංྣ ᄝྜ ᤤ ᳺᅉ᱅ಃ ႈ፩ᢎᙂ ᢎቹ Microcontroller ឥᕷ ᳺᔉၟྜ ೈ៰ឥ ᶾ៨᷆ ᗀ ᢘླ/!႓ᅉ . ᇍᢎᜌ៸ᢎ ၗᢑ᷅ ឭᇃ ኰᙋ )ၗ ż൷ኄ 4ŽᏲ᱅ᢉ BVUPTBS!Ᏹᢎ ᖜᶵ᳤᠂᜴ឥྜ 3ಕᢉ K2:4:!ᢾᖥ ᶵᇢᱜᮗᢐ CBN DNEU ż൷ኄ 6ŽDBO!ං፭ ᶵᇢᱜᮗᇢ ᙋᷔၟྜ ᓿᢜၗᨵᢉ ំᐆၽ ྶ ᕷ ႈ፩ᢎᙂ ᢎቹ ᓳ᷌ ᢎᥟ ẗቹ ಃ ᴭ᷈ၝ ᢘླ ᢑ᷅ ᳺᅉ᱅ ൷ሀ* )evbm.gmpx*! ፸ං ᙋᙂ᱓ᢉ ២ᨈᢎໆ ោቷ . ၗᢽ ON! ᢎ)-! BBD! ᢎ*! TBF ᨈឥᕷ ፸ංಃᙂ ំ၍ ᖈᕷ)᫇ኗ ᭻ᎆ᱅ᢉ K2:4:092ឥ ႓ᅉ ᳤ᰡ ᙂ᳤ኄ ᄝྜ ླ៲ᙂ᳤ኄ*ᢉ ᡩ᭛ቸ ᙌ᷆ ᳤ ᱰឥᕷྜ ᢎಒ ᳤ᰡ ೞኀᢉ ᏽೈ ွ ༐ ೞᙑᢎ ໆᰰໆ ᢘྜ ᓿṤᢎླ/! ẩ ᤦ᷅ᢽᢐ ፶ᙌᇢኊ ಃྣ᷃ླ/ ೞᇗ ኰᙋ ᇍᢎᜌ៸ ᳺᅉ᱅ ൷ሀ)QH; .!៨᪷ ኰᙋឥ ࿅᷅ ᢂ྾ ᗀ ᢘླ/!ឭᇃ FDVቸ ᗂᕷ࿅ᇢ ᏽೈ᷌ ᳥ᤤ ᓳ᷋ ዂၦ ᷃ ᢘླ/ ൷ᇃໆ ᢎᇃ᷅ ᙋᢧᢉ ᳥ᗀ᷅ ៨൘ᓳ᷋ BVUPTBSᢉŰᤤᢽűᤢ൹ ፶ᙌ K2:4: Qbsbnfufs!Hspvq*ᢎᅉྜ ᙌᢜᢉ ᳥ᤤ ᐜ .!ྶ ᕷᐿᙂ ᙋᤡឥ Ṣᖄṟ᷆ ᗀ ᢘྜွ-!ᢎྜ ᳤ᰡ BVUPTBSቸ ಕ፯᷃ྜ ွ ᢘ᜴ ᴭ᭹ᙂ ၟ ᢉŰၗᢽűၗᢝ ࿅ᤶቸ ᢎᇽླ/!BVUPTBS ᐞឥኊ ᷆࿁ၠླ/! 3:ᐿ᳤ ᙌᢜᢉ ᢑᐜ ླ . K2:4:ቸ ᱣ᷅ ំᐆၽ ྶ)XXI.PCE* ᢉ ឭᇃ FDVឥ ᔁᇢ៲ ංྣ ၗᙋឥ ᷆࿁ 더욱 가까워진 AUTOSAR와 J1939 ᢘ ᜐླ/!႓ᅉᕷ ᢩᷪඎ ፯ᶙၠ ᜌᰨ᱐ឥᕷྜ ᤤၠ DBO! ᙌᢜ ቷ ᭾ᴭ᳤ྜ ၗᢽ ᳥ᖄ ໆᰰ໗ኹ ൘ᖄ ᙋ ᷌ᜥ ᷃ྜ ೈ៰ ႆឥ ᡱ᷆ ᗀ ᢘླ/ ᙊᨵ ೊᢉ BVUPTBS!၍ᢖ ᑊቷ ᖝ၍ BVUPTBS! ᎆᢾ ኗ៰ ᤦ᷅ᢽᢎླ/! ᳥ẩ ))Jefoujgjfs*ኊ ᷗၠླ/! -! ᤤṠẩ ᷃ໆᢉ ᤤᢉၟ ᜐྜླ/!ᢎᇃ᷅ ၗᢽ ᙌᢜྜ ᳤ Ᏺ᱅ྜ ᡱᇈ ᓿ ᨵᇂ PFN ᷈ฐ Ᏺ᱅)Wfdups*ᢉ DBObmz{fs/K2:4:! ᎆᢾ ᇢ ᷔၟ ᢘླ/!ಶླಃ ᓿ ᨵᇂ ፧ ༏ංೊ TBF!K2:4:ᢉ ៨൘ᓳ᷋ ᢩᷪᢉ BVUPTBS DBO!ᙌᢜ៑ ᷃ໆᢉ ኰᙋ ᇍᢎᜌ៸ ᓳᢎ ᰡឥᕷ ፯ᔉ᷆ ᗀ ᢘྜ ಄಄ᢉ ៰ᕻᗂᡩ ᤶ BVUPTBSឥ ࿅᷅ ᢎಒ K2:4:! Ṡᢧ ᶙᥘ 8/6!ᐞᕸ ᱰ DBOpf/K2:4:!ಕ፯ ፧ ᱏᙂ ᙋᢧឥᕷ၍ BVUPTBSᢉ ᢎᤡ Ṣ᷃ྜ ಕༀឥ ኗ᷂ ᷆ ᗀ ಧໆ ኗ᷂ ᷃࿏ᅉ၍ ᓿ࿁ ᇢ ᷆࿁ᢎ ᤤၝ ᢘླ/! ᢎ៑ ፭࿅ᇢ K2:4: ᷉-!፯ᙍ ᥖᖜ)Tpvsdf!Beesftt-!TB*!፧ ዃ ᤤ᷃ᇕྜ ༇ᇖឥ ᢽ൸ ᨺឭ᷃ ᢘླ/
92 www.autoelectronics.co.kr 2011 FEB·MAR 93 11/2 11/3 Development Feature J1939 Standardization
Ᏺ᱅ྜ ᢎ BVUPTBS!ኃኀᙂ 5/1 ං፭ ᇢ ᷃ྜ K2:4:! Ṡᢧ ᶙᥘᢎ ᢽၠ BVUPTBS! ᖠᇻᖑ ᕻᐆីླ(그림 3)/! ᢎ ᖠᇻᖑ ᡱᇈᢉ ᷅ ࿅൴ዂ ᓿ ᨵᇂ PFN ᢉ ᔉᓶ ṡೈឥ ᢽၡ ួᤤᢎླ/!BVUPTBS
ኃኀᙂ 5/2ឥ ࿅᷅ Ṡᢧ ᶙᥘ ᢩᷪ ಕ፯ ྶ ż൷ኄ 7Ž XXI.PCEྜ VETᇢᐜ᱅ ྶ ᕷᐿᙂቸ ᢎ᷅ླ ೊឥ ᢘླ/
WWH-OBD를 사용하는 상용 차량 진단 ᎌᡩ᷃ಶ ᓳၟ ᢘླ(그림 5)/! XXI. ᐆឭ ᥘླ/! ᙊᨵ ංᗄ ಕༀᢉ ᢎᢾ-! Ṡᢧ ំᐆၽ ྶ)PCE* JTPឥᕷ ᶙᥘṟ᷅ PCEᇢ ೈᤦᢽᇢ ᢾṡ᷆ ᗀ ᢘ၍ᇣ ፧ ᗀᤤ ༇ᇖ K2:4:!FDV!ಕ፯ᢉ ೈᤦᖄ ྶ ᙋᙂ᱓ᇢ-!PECᢉ ᢂ ᐜጾ ᥟ ᷃ ឥྜ DBO ᱣ᷅ ྶᢎ ᓳၡ ួᤤᢎླ/ ༐ᢎྜ ွ ዃᶙቸ ၦ ᢘླ/!Ᏺ᱅ྜ ᗀ ໆྜ ፸ංಃᙂ ፸ ᤦ᜴៑ ೞᇗၠ ᙋᙂ᱓ ᢧංᢽᇢྜ ᢎ࿏ ᱣ᷅ ᡱᕻ ᄝྜ ጻᕻ ಅ ᢽ᷅ ᳤ᰯ ೞᇗ ᢾጾ ංᗄ ᱣ᷌ ዂྩ᱅ኇ ᷃ྜ ಯᢎླ/!ᙋಅᢎ ໎ឥ ႓ ᖆᙂ ංྣ ൘ᷪ᷃ྜ EpJQ)Ejbhoptujdt ᶙᥘ ᡩṪឥ ᢽ൸ᢽᇢ ೞឭ᷃ኹ ืᥘẩ ᅉ ᢎ ᶙᥘឥᕷ ឭᇃ ឮ ᶙᥘ)ួ;! JTP pwfs! Joufsofu! Qspupdpm*ᢉ ᓳ၍ ಃྣ᷆ ංឭ᷃ ᢘླ/!ᄝ᷅ ᓿ ᨵᇂ ᢾᢜ ᢧ᭛ ಕ 26142*ᢎ ᳺᔉၞኹ ᢩᷪྜ XXI. ᢾናᢎླ/ ፯ᢜႁ ᢕᏱႈၽ ᖜᶵ᳤᠂᜴ ፧ ಕ፯ ᱰ PCE)Xpsme.Xjef.Ibsnpoj{fe! Po. ᢩᷪᢉ PCE.JJ! ᶙᥘ ྸኀ XXI. ឥ ᔁᇢ៲ ᶙᥘᢎ ᤶංឥ ಕ፯ၢឥ ႓ᅉ ᷱ Cpbse.Ejbhoptujdt*ᇢ ླᙋ ᐂ᷉ၞླ/! ᢎ PCEឥᕷྜ ᢎ JTP!2533:!ŰET)Vojgjfe ᰻ ᢘླ/ ᶙᥘ VO)Vojufe! Obujpot*ឥᕷ ፯ᢉᷓ Ejbhoptujd!Tfswjdft*űᇢ ᤤᢉၠ ᕷᐿᙂቸ
ኹ VOᢉ ᖆೊ ංᗄ ൴ᤤ)HUS.6; Ṣ᷃ ᢘླ/! ಃᇢ ᶾ៨᷅ PCE! ೞᇗ 참고문헌 Hmpcbm! Ufdiojdbm! Sfhvmbujpo! 6*ឥ ጾᕷ ᕷᐿᙂྜ ླ/! ᳥ẩ XXI.PCEឥᕷྜ \2^!iuuq;00tuboebset/tbf/psh ṟၝ ᢘླ/!JTP!38256ྜ HUS!6ቸ ංᗄᢽ 그림 6ឥᕷᇇ VET! ᕷᐿᙂቸ ᷌ᜥ \3^!Ű BO! voe! pggfof! Qspuplpmmf! jn ᇢ ൘ᷪ᷅ ಯᢎኹ-! XXI.PCEឥ ࿅᷅ ᷅ླ/! Ovu{gbis{fvhŰ\Ű BO! boe! Pqfo Qspupdpmt! jo! Dpnnfsdjbm! Wfijdmftű- ංᗄ ᤦᜦ ᓳ᷋ ᤤ᷃ ᢘླ/! XXI. 3125ᐜ᱅ ᔁᇢ ႆᇣၟྜ ዂၿ ࿅ᷰ Fmfluspojl!bvupnpujwf!603116-!qbhf!71 PCEྜ ឥྜ ᓿ ᨵᇂ ᙋᢧ ࿅ᓿ )Ifbwz.evuz*!ᓿ ᨵᇂᢎ Fvsp!WJ!ᶙᥘ \4^!TBF-! K2:4:.22-! Qiztjdbm! Mbzfs-! 361L ᇢ ᷓኊ ೃᢽᇢྜ ླቷ ᨵᇂ ᓶ ႓ᅉᜥ ᷃ං ჽጾឥ XXI.PCE!ྶ ංྣ cjut0t-!Uxjtufe!Tijfmefe!Qbjs ᇢ၍ Ṡᢧၟ ᢘླ/! ಐᜥኊ ᷅ླ/!ᔁᇢ៲ ᡱᷰᢉ ᨵᇂ ೞ \5^!TBF-! K2:4:.26-! Sfevdfe! Qiztjdbm Mbzfs-! 361L! cjut0tfd-! Vo.Tijfmefe JTP! 38256ྜ 7ಕ ᐜᐞᇢ ൘ᖄၝ ᢘླ ᇗၠ ಕ፯ ጻឥᕷྜ ᢎᐆླ 2 ᑊቷ 3124 Uxjtufe!Qbjs!)VUQ* (그림 4)/! ᢩᷪᢉ ጾᕷྜŰ൙ᤦ ᶙᥘ ᫆ᜎ 2 2ᢑᐜ᱅ ᶙᥘ ᤷ᷌ᜥ ᷅ླ/ \6^!TBF-! K2:4:.24-! Pgg.Cpbse! Ejbhoptujd Dpoofdups )EJT;!Esbgu!Joufsobujpobm!Tuboebse*űᢎኹ VET! ྶ ᕷᐿᙂྜ K2:4:၍ ᷈ฐ \7^!TBF-!K2:4:.92-!Ofuxpsl!Nbobhfnfou ᜎ 3122 ኍᇢ ួᤤၝ ᢘླ/! ᷃ྜ DBOcfeefe! ᱣᙍ ᖜᶵ᳤᠂᜴ቸ ᱣ᷌ ᪵ ᎈ᧮ ྶೊྜ ፶ᇂ ᤦ᜴ ፧ ྶ ᱣᙍ ൘ᷪ᷆ ᗀ ᢘླ/!ᢎᇃ᷅ ᖜᶵ᳤᠂᜴ྜ Ᏺ᱅ ኇᰡ; ឥ ࿅᷅ ៨൘ᓳ᷋ ᤤ᷃ྜ ᢑᢎླ/!ᢎቸ ᡩ᷌ ឥᕷ ᤦ᷃ኹ ኋ ᜭᓶ ൘ᷪ ᱣ᷌ ᙏᤦ Ipnfqbhf!Wfdups;!xxx/wfdups/dpn ᨵᇂ ൘ᷪ-!ွᢎ᱅ ᖆᙂ ፧ PCE!ွᢎ᱅ ṡೈឥᕷ ಭ ኈ᭝ ᓿླ/!ᄝ᷅ ൹ឥ Tpmvujpot!gps!K2:4:; xxx/wfdups/dpn0k2:4: ಃ ᤤၞླ/!ឭᇃ ឮ ංೞឥᕷྜ ឭᢾẩ ᤦ ྜ VETቸ ᱣ᷅ XXI.PCE! ྶ ංྣ Tpmvujpot!gps!BVUPTBS;!xxx/wfdups/dpn0bvuptbs ᷅ ᓳ᷋ ፧ ᢕೊಌ ᤤᢉ᷃ྜ ᥟᢎླ/!႓ᅉᕷ ൘ᷪ᷃ං ᡩ᷌ ᜭᓶ ṡೈឥ ፩ᇢ ᓳ ಃྣ Qspevdu!Jogpsnbujpo!DBOpf/K2:4:; ᢎṶឥ၍ ᤶṟಃ ᢎሃ ᜐ ᢾናᢎླ/ ᷅ BVUPTBS!ᖠᇻᖑᢎ ໆោං၍ ᷓླ/! xxx/wfdups/dpn0wj`dbopf`k2:4:`fo/iunm ᢩᷪ ᓿ ᨵᇂᢉ ំᐆၽ ྶ ᡩ᷌ ၦ K2:4:!ឹឮឥ ංᗄၠ ಕ፯ᓳ᷋ឥᕷྜ ᢎ Qspevdu!Jogpsnbujpo!DBOcfeefe!K2:4:; ಕᢉ DBO! ං፭ ᶵᇢᱜᮗᢐŰEjbhoptujdt ᶙᥘᢎ ᜴ᄈ ᙌᇢ ᢩᷪᢉ ៨൘ᓳ᷋ឥ ኔ xxx/wfdups/dpn0wj`dbocfeefe`k2:4:`fo/iunm po!DBOű)JTP!26876.5*!፧ K2:4:.84ᢎ ൄ ಶ ᖝᢽ-! ᤤංᢽᇢ ᤶᤤၟ ᢘྜቸ
94 www.autoelectronics.co.kr 11/4 CANopen 시스템 개발 위한 프로토타입 환경 및 테스트 방법
CANopen은 산업 자동화부터 상용 차량에 이르기까지 수많은 애플리케이션 영역에서 컴포넌트 간의 경제적이면서 유연한 네트워킹 표준이다. 표준화된 디바이스 프로필은 버스 노드 간 통신을 단순화하는 것은 물론 서로 다른 제조업체의 ECU·센서 및 액추에이터 간 상호 작용이 원활하게 이루어지도록 한다. 프로토타이핑과 테스트를 위한 특수한 툴을 이용하면 복잡한 CANopen 프로젝트 개발은 물론, 전문 영역 내 기본적인 부분을 확립하는데 유익한 서비스를 제공받을 수 있다.
자료제공 벡터코리아 www.vector-korea.com 글 마코 티셔(Mirko Tischer), CANopen 프로덕트 매니저 그림 3. CANoe.CANopen 환경
애플리케이션의 동작 정의 CANopen 시스템을 개발할 때 수행하는 테스트 구성 통한 시스템 검증 이라는 것을 사용한다. 테스트에는 특수한 작업 범위는 개별 ECU를 설계하는 것부터 측정 또는 진단 구성 외 시스템 환경을 최대 개별 ECU 노드의 애플리케이션 동작은 객 전체 시스템을 구성하고 시작하는 단계까지 전체 시스템 개발 과정에 수반되는 시스템 한 실제와 가깝게 시뮬레이션하기 위한 액추 체 디렉토리 구조만을 매핑하는 EDS 파일 그림 2. 중앙 제어 및 I/O 노드가 포함된 CANopen 네트워크를 시뮬레이션하기 위한 간단한 구성 예 이어진다. 시스템 생산업체 입장에서 테스트는 모든 개발 단계에서 반드시 수행돼 에이터도 포함된다. 에서 직접 얻어낼 수 없다. 따라서 애플리케 CANopen 같은 시스템을 처음 사용하면 초 야 한다. 대개의 경우 시스템 컴포넌트를 실 이러한 테스트 구성에는 프로젝트 규모 이션 동작을 체계화하는 과정에는 항상 추 기에 막대한 노력이 들게 된다. V 모델에서 제로 사용할 수 있게 되면 그제서야 뒤늦게 에 따라 생각보다 많은 비용과 노력이 투입 툴로 프로토타입 환경 구성 는 생성된 설명 파일(EDS: Electronic Data 가적인 프로그래밍 노력이 수반된다. 는 개발 작업의 상당 부분을 확인·검증 작 테스트를 수행하게 되는데, 이 경우 문제라 될 수 있다. 그리고 이 테스트 구성은 일반 Sheet)로 정의된다. 이 다음 단계에서는 나 CANoe에 통합된 CAPL 프로그래밍 언어 업에 할애해야 하기 때문이다. 따라서 가능 도 발생한다면 시스템 완성 날짜를 지키는 적으로 하나뿐이기 때문에 테스트 단계를 CAN을 통해 네트워크로 연결된 전체 시스 중에 버스를 통해 교환할 보정 데이터 간 상 를 활용하면 ECU 동작을 신속하게 프로그 한 한 빠른 시기에 포괄적인 테스트를 수행 것이 어려워질 수 있다. 진행하는 동안 프로세스에 병목 현상이 발 템의 프로토타입은 무엇보다도 테스트 및 호 관계를 정의한다. 예를 들어 주소가 5인 래밍할 수 있다. 또 다른 대안으로 CANoe 한다면 오류가 너무 늦게 발견되는 위험을 이에 고객의 시설에 있는 실제 시스템에서 생된다. 검증 작업을 지원해야만 한다. 또한 개별 디바이스(압력 변환기)의‘PressureValve’ 의 프로토타입 환경에 연결된 DLL 파일 안 최소화할 수 있다(그림 1). 테스트를 수행하지 않고 테스트 구성(Setup) 향후 완성될 전체 시스템의 프로토타입을 컴포넌트를 실제 혹은 시뮬레이션된 ECU 입력은 주소가 10인 디바이스(제어 모듈)의 에 ECU의 동작을 코딩할 수도 있다. 그리 손쉽게 생성할 수 있는 소프트웨어 툴을 활 로 표현하는 것도 중요하다. ‘Gas pressure’변수로 연결되는 식이다. 고 MATLAB/Simulink 모델도 손쉽게 통 용하면 이 딜레마에서 벗어날 수 있다. 뿐만 이렇게 하면 시스템 개발 과정 동안 실제 이러한 방식으로 프로토타입 시스템 내 모든 합할 수 있다(그림 3). 아니라 이 툴이 광범위한 테스트 기능까지 ECU의 작동 기능을 비교적 쉽게 테스트할 PDO(Process Data Object)의 상호 관계가 제공한다면 더할 나위 없이 좋다. 수 있다. 복잡한 전체 시스템에 대한 프로 정의된다. 토타입을 만드는 것은 적절한 툴을 사용할 이러한 매핑은 툴을 통해 자동으로 계산되 테스트 기능 만한 가치가 있을 만큼 까다로운 작업이기 어 생성되며, 이 매핑은 필요한 경우 나중에 때문이다. 수정될 수 있다. 이 구성 정보(DCF: Device 프로토타입 시스템이 완성되고 나면, 전체 이와 관련, 벡터의 CANoe.CANopen은 Configuration File)를 통해 이제 사용자는 프로젝트에 필요한 테스트를 수행한다. 이때 프로토타입 시스템의 통신 기능을 구성하 프로토타입 환경을 구축할 수 있는데, 실제 CANoe는 다시 사용자를 테스트 생성 및 로 는 데 유용하게 활용된다. 이 툴은 간소한 ECU와 비교하여 동일한 통신 속성을 지닌 깅/평가할 수 있도록 지원한다. CANopen 구성 절차를 통해 사용자가 실제 시스템의 가상의 ECU를 CANoe에서 생성할 수 있게 시스템에 필요한 테스트 기능은 다음 단계 통신 속성과 일치하는 프로토타입을 만들 되는 것이다. CANoe를 구동하면 프로토타 로 구성된다(그림 4). 수 있게 한다. 입 환경의 통신 부분은 이미 사용할 수 있는 •프로토콜 레벨: 이 레벨의 테스트에서는 그림 1. V 모델 개념 CANopen ECU의 동작은 사전에 선택 또 상태가 된다(그림 2). 개별 디바이스의 CANopen 관련 통신 프
36 AUTOMOTIVE MANUFACTURING &Technology 2010•September 37 11/6 11/7 다. 이는 예를 들어 하나의 중요한 특정 메 시지를 기다리는 동안 버스 상에 다른 특정 메시지가 주기적으로 전송되는지 여부를 결 정할 수 있게 한다. 특히 자동화된 테스트에서는 개별 테스트 단계의 결과를 자세히 기록해 두는 것이 중 요하다. 다른 CAPL 함수는 테스트 결과를 사후 처리하기 위해 XML 파일에 기록한다. CANoe의 테스트 시퀀스는 XML로도 명시 그림 4. CANopen에서의 테스트 레벨 될 수 있는데, 이는 단일 툴로 많은 테스트 흐름을 생성해야 하는 경우 유리하다. 따라 로토콜이 전체 시스템에 맞도록 규격에 스트를 공식화하기 위해 관련된 노하우를 서 CANoe는 XML에 명시된 많은 테스트 따라 구현되어 있는지를 확인한다. 반드시 보유하고 있어야 한다. 패턴을 활용하고 그에 따라 처리한다. •통신 레벨: 여기서 중요한 것은 프로토콜 의 정확함이 아니라 PDO 구성과 같은 프 로토콜 시퀀스의 올바른 논리적 순서이 테스트 절차의 생성 및 실행 갈무리 다. 객체 디렉토리 안의 PDO 관련 항목 에 대한 설명(Description)은 특정한 순 테스트 시퀀스는 CANoe에 통합된 CAPL CANopen 네트워크 시스템에서 프로토타입 서에 따라 나열되어야 한다. 프로그래밍 언어를 통해 제정된다. 각각의 을 만드는 경우 이러한 프로세스에는 많은 •애플리케이션 레벨: 애플리케이션 테스트 CAPL 테스트 모듈은 개별 테스트 케이스로 노력이 요구된다. 하지만 이 프로세스는 종 에서는 프로세스 변수 간 관계를 확인한 구성되어 있으며 각 테스트 케이스에도 수 종 기능에 대한 점검 작업이 프로젝트 중 너 다. 이 관계를 결정하는 데에도 몇 가지 많은 테스트 단계가 포함되어 있다. CANoe 무 늦은 단계까지 지연되지 않도록 하는데 사전 조건을 충족해야 한다. 먼저, 프로세 는 테스트 실행 과정 동안에 개별 테스트 케 필수적이다. CANoe.CANopen 같은 특별한 스 변수가 PDO를 통해 교환되어야 하며 이스를 순차적으로 처리한다. 테스트 흐름 툴은 사용자가 프로토타입을 생성하는데 있 시스템이 완벽하게 구성돼 있어야 한다. 을 적절히 제어하면 개별 테스트를 건너뛰 어 효율적으로 지원한다. 특히, 이러한 방식 예를 들면 밸브의 상태는 온도나 압력의 거나 반복할 수 있다. 동시에 다른 조건 및 을 사용하면 통신의 기술적 측면과 관련된 상관 관계로 확인될 수 있다. 사용자는 테 제약에 대한 준수 상태도 모니터링할 수 있 요구 사항을 다루기가 수월하다.
>>>> 벡터코리아 행사 안내
CiA Seminar 2010 제 1회 한국 벡터 컨퍼런스 •일시: 9월 7일 9시30분~17시30분 •일시: 10월 6일 9시~17시30분(디너 파티 참석 시 19시30분까지 예정) •장소: 벡터코리아 세미나실 •장소: EL 타워(서울 양재동) •내용: CAN/CANopen 프로토콜 소개, CANopen 시스템을 위한 벡터 솔루션 •내용: 전세계 자동차 IT 기술 동향, ISO 26262 소개, 최신 벡터 제품 및 •주최: CiA(CAN in Automation), 벡터코리아 솔루션, 제품별 새로운 기능 소개 및 시연, 고객 성공 사례 등 •수용인원: 16명 •주최: 벡터코리아 •비용: 무료 •비용: 무료 •참고: 점심 무료 제공, 선착순 마감 •참고: 점심 및 저녁 무료 제공, 선착순 마감 •문의: [email protected] •문의: [email protected] •아젠다 및 등록: kr.vector.com/cia •아젠다 및 등록: kr.vector.com/conference
38 AUTOMOTIVE MANUFACTURING &Technology 11/8
Get more Information
Visit our Website for: > News > Products > Demo Software > Support > Training Classes > Addresses www.vector.com