자율주행을 위한 ECU 아키텍처 및 통합 절차

2016년 09월호 지면기사  /  글│게오르그 니드리스트(Georg Niedrist) 박사, TTTech Automotive GmbH

도메인 ECU는 플랫폼 아키텍처를 기반으로 중앙에서 데이터를 처리한다. 예를 들어 ADAS 도메인에서 센서 퓨전을 하기 위해서는 중앙에서 센서 퓨전과 애플리케이션 컨트롤러 아키텍처가 필요하다. ADAS 시스템의 ECU 아키텍처 요구사항과 현재 양산 개발에 사용되는 새로운 솔루션에 대해 설명한다.

문의│(주)한일프로텍, hanilprotech@hanilprotech.com

 

티티텍 컴퓨터테크닉(TTTech Computertechnik AG)는 견고한 네트워크 안전성 제어기술의 리더로서 우주, 항공, 전력, 철도 시스템 및 산업 공정 자동화 등의 다양한 안전 관련 분야에서 활약하고 있다. 자회사인 티티텍 오토모티브(TTTech Automotive GmbH, 이하 티티텍)는 미래 자동차 기술을 선도하기 위한 솔루션을 제공하고 있다. 이 솔루션은 첨단 운전자 지원 시스템(ADAS)에 사용되는 혁신적인 도메인 ECU 플랫폼으로 2017년부터 독일의 한 프리미엄급 양산 차량에 적용될 예정이다.

이 플랫폼에서는 여러 고성능 멀티코어 프로세서와 미들웨어를 사용해 30개 이상의 다양한 ADAS 기능을 통합하고 모니터링할 수 있다. 특히 티티텍에서 개발한 TTIntegration 소프트웨어를 사용해 다양한 안전성 레벨(ISO 26262 기준의 최대 ASIL D)을 가진 애플리케이션을 손쉽게 통합하고 실행할 수 있다. 내장 네트워크로는 최대 1 Gbps 대역폭을 지원하는 Deterministic Ethernet을 사용한다.

티티텍은 전기차 또는 동적 차체 자세제어 시스템과 같은 효율적인 시스템 솔루션과 안전성이 검증된 모듈을 기반으로 하는 하드웨어 및 소프트웨어 솔루션도 제공하고 있다. 또한 FlexRay, MOST 및 CAN과 같은 버스 시스템의 데이터 로깅 장비들도 공급한다.

자동차는 첨단 운전자 지원 시스템(ADAS), 인포테인먼트 시스템, 차량 동역학 시스템 그리고 하이브리드 및 전기 구동계와 같은 많은 전자 기능들을 포함하고 있다. 이러한 기능들은 모든 차량 분야에서 계속해서 증가하고 있다. 이전에는 새로운 사용자 기능이 추가될 때마다 새로운 전자제어장치(ECU)를 구현했으나, 비용 상승, 패키징, 와이어링 및 열 부하 등의 문제들로 인해 이런 방식이 더 이상 적합하지 않게 됐다.

따라서 최근에는 소프트웨어 변경만으로 새로운 기능을 구현하고 자동차 전자 시스템을 모듈화해 ECU 개수를 효과적으로 줄이거나 가능한 더 늘리지 않는 추세다.

이러한 기술적 변화와 함께 공급망과 협력 모델도 변화하고 있다. OEM은 특정한 티어1 공급자로부터 센서, ECU 및 액추에이터를 하나의 시스템으로서 공급받는 대신, 보다 오픈 된 “체리피킹(cherrypinking)”모델로 점차 변화하고 있다. 이 모델은 OEM이 여러 티어1과 SW 공급자 중에서 가장 좋은 요소들(센서, 센서 처리 소프트웨어, ECU HW와 플랫폼 SW, 애플리케이션 SW 모듈들 및 액추에이터들)을 개별적으로 선택하고, OEM이 직접 혹은 협력 업체 네트워크를 통해 전체 시스템을 통합하는 형태다. 협력 모델의 변화는 OEM이 차별화의 필요성을 인식하고, 자체적으로 개발하는 기능이 증가하면서 OEM의 주도로 진행되고 있다.

이러한 트렌드의 변화로 인해 도메인 ECU가 출현하게 됐다. 도메인 ECU는 플랫폼 아키텍처를 기반으로 중앙에서 데이터를 처리한다. 예를 들어 ADAS 도메인에서 센서 퓨전을 하기 위해서는 당연히 중앙에서 센서 퓨전과 애플리케이션 컨트롤러 아키텍처가 필요하게 된다. 특히 많은 비용과 기능 검증을 필요로 하는 ADAS 도메인은 다른 자동차 모델에서도 SW를 재사용해야 하기 때문에, 어느 모델에서나 보편적으로 사용할 수 있는 제네릭 플랫폼이 필요하다.

협력 모델의 변화와 기술적 복잡도의 증가로, SW를 통합하는 새로운 역할이 필요하게 됐다. 또한 ECU 아키텍처, SW 플랫폼 그리고 통합 절차에 대한 요구사항도 많이 변화하게 됐다. 다음 섹션에서는 ADAS 시스템의 ECU 아키텍처의 요구사항과 현재 양산 개발에 사용되는 새로운 솔루션에 대해 설명한다.

ADAS 도메인 ECU 요구사항

그림 1은 자율주행 시나리오와 같은 고성능 ADAS 시스템의 개요도다. 차선, 교통 표지, 사람, 다른 자동차 등 자동차 환경에 대한 기초적인 정보를 식별하기 위해 레이더, 카메라, 라이더 및 초음파 센서들과 같은 다양한 센서들이 사용된다. 이 정보들은 자동차 주변 환경과 모든 사물들의 궤도를 정확하고 일관되게 계산하기 위해 중앙 퓨전레이어에 입력된다.

애플리케이션 레이어는 퓨전된 정보를 기반으로 차량의 주행 전략을 세우고 조향, 제동 및 구동장치를 제어해 차량을 운전하기 위한 운행 및 제어 알고리즘을 구현한다. 이러한 자율주행 제어의 핵심기능 이외에도 자동 긴급제동, 차선 보조 및 서라운드 뷰와 같은 사용자 기능부터 이벤트로깅, 블랙박스 데이터 레코딩과 같은 보조기능들까지 다양한 편의 기능 및 보조 기능들이 중앙 ADAS 제어기에서 관리된다.

중앙 제어기에서 동작하는 SW는 가공되지 않은 센서 데이터를 직접 처리하거나 또는 중앙의 제어기에 연결된 스마트 센서들로부터 수신된 오브젝트 데이터를 활용한다. 어떤 경우든 기본적으로 센서 퓨전 레이어와 모든 애플리케이션 및 보조 기능들은 반드시 통합돼야 한다.

ADAS 도메인 제어기의 HW와 SW 아키텍처 요구사항은 성능, 안전성, 애플리케이션 SW 개발 및 통합 절차와 같은 여러 요소들이 포함돼야 한다. 또한 기술 복잡도를 관리하고 개별 차량 옵션들을 지원하기 위한 모듈화와 확장성을 고려해 도출된다. 오랫동안 항공우주 산업에서도 유사한 요구사항이 있었고 분산 통합 모듈형 항공전자(Distributed Integrated Modular Avionics, DIMA)라는 안정화된 아키텍처가 등장하게 됐다. 이후에 설명할 아키텍처는 DIMA로부터 파생됐으며 비용, 기능 및 확장성 측면에서 자동차 분야의 요구사항에 맞게 적용된 것이다. 


 성능:
ADAS 도메인은 센서 처리, 센서 퓨전 및 차량 제어를 위해 많은 계산이 필요하기 때문에 고성능을 요구한다. 전체 시스템 아키텍처에 따라, 고성능의 범용 처리장치뿐만 아니라 GPU와 같은 영상 처리장치들이 필요할 수 있다. 일례로 ARM A53 혹은 A57 코어 등을 기반으로 하는 멀티코어 SoC(System-on-Chip) 설계가 사용될 수 있다. 특히 사용자 기능 및 인포테인먼트에 사용되는 장치들은 높은 집적도와 고성능/전력비를 필요로 하기 때문에 이러한 설계를 사용해야 한다.


안전성: 
ADAS 도메인 제어기는 자율주행 기능들을 지원하기 위해 ISO 26262 ASIL C/D를 준수할 필요가 있다. 하지만 현재 고사양의 SoC들은 이러한 종합적인 안전성 요구사항을 만족할 수 없다. 따라서 보통 ASIL 분해(decomposition)1)와 SW 분할(partitioning) 방법을 사용한다. ADAS 도메인 제어기는 대개 더 낮은 안전성 능력을 가진 고성능 SoC 장치에 ASIL D를 만족하는 마이크로컨트롤러를 하나 이상 포함한다. HW의 안전성 기능이 애플리케이션을 완전하게 지원하려면 추가로 플랫폼 SW 메커니즘(메모리 분할, 타이밍 관리, 애플리케이션 간 통신 보호, HW 진단 및 관리)이 필요하다.

인터페이스: 
ADAS 도메인 컨트롤러는 기존 자동차 네트워크 인터페이스(CAN, FlexRay, LIN) 뿐만 아니라, 추가로 센서에 연결하기 위한 Ethernet 및 Raw 데이터 비디오 인터페이스(LVDS, CSI)를 필요로 한다.
CAN 혹은 FlexRay와 함께 보조 기능들(진단, 캘리브레이션 및 보안 기능 등)은 AUTOSAR Basic SW를 사용해 지원될 수 있다. 고성능 SoC들은 이러한 인터페이스 및 서비스를 제공하지 않을 수 있기 때문에 차량용 마이크로컨트롤러에 의해 보완돼야 한다.

ECU 모듈화 및 확장성: 
다양한 차량 옵션들을 지원하기 위해, 도메인 제어기는 고급 시스템부터 기본적인 기능들까지 다양한 형태를 지원할 필요가 있다. 각 옵션들에 대해 개별적인 ECU SW 패키지를 개발하지 않기 위해서는 SW 재사용이 필수다. 이를 위해 하부의 HW, 운영체제 및 통신 메커니즘들을 추상화해야 한다. 또한 애플리케이션 SW 컴포넌트(SWC)는 하부 플랫폼과 완전히 독립돼야 하고, 플랫폼은 특정 애플리케이션과 관련된 요소들을 포함하고 있지 않아야 한다. 이렇게 설계된 아키텍처는 다양한 ECU 옵션들의 성능 및 안전성 요구사항에 따라 필요한 처리 요소들을 추가하거나 제거할 수 있다. 또한 각 프로세서들 간에 SWC들을 자유롭게 재사용하고 이동시킬 수 있기 때문에, SW 개발 및 검증 업무가 상당히 감소하게 된다.

개발 절차: 
신속한 프로토타입 개발을 위해, ADAS 도메인의 애플리케이션 SW는 초기에 ADTF 혹은 MATLAB/Simulink와 같은 모델링 도구로 개발된다. 이러한 방식은 PC 기반 개발에서 타깃 ECU 개발까지 매끄럽게 진행된다. 또한 완전히 동일한 코드를 PC와 타깃 ECU에 동작시키는 것이 가능해, 전체 개발 단계에서 테스트 케이스들을 지속적으로 사용할 수 있다. 이러한 SIL(Software in the Loop) 구성에서는 타깃 ECU 기반 SWC와 PC 기반 SWC를 통합한 환경설정(configuration)이 반드시 가능해야 한다.

SW 통합 절차:
HW 및 SW 플랫폼 아키텍처는 여러 팀이 만든 많은 SWC를 적절하게 통합할 수 있어야 한다. 또한 SW 통합자(OEM 혹은 서드파티)와 SWC 공급자 사이에 디버깅, 중재 및 충돌 해결 업무가 과중되지 않아야 한다. 즉 특정 SWC는 잘 동작하지만 통합된 시스템에서는 타이밍의 영향과 리소스 충돌로 인한 반복된 수정이 발생할 수 있다. 이러한 상황을 피하기 위해서는 개별적으로 테스트된 SWC들이 함께 통합되도 즉시 작동할 수 있는 결합성이 필요하다. 따라서 SWC의 리소스 사용량, 실행 시간, 데이터 흐름 지연 시간 및 실행 순서에 대한 예측가능성 또한 중요한 요구사항이다. 또한 경쟁관계인 SWC 공급자들 간의 지적재산권 보호를 위해 소스 코드 없이 익명화된 인터페이스를 사용하는 블랙박스 통합 방식을 사용하는 것이 적절하다.

복잡도 관리: 
고성능 중앙 ADAS 제어기의 복잡도는 최근 전체 차량 전자장치와 유사한 수준이 됐다. 이때 요구되는 SWC들의 모듈화, 이식성 및 인터페이스들의 간결성은 명확한 SW 아키텍처와 HW 및 운영체제의 추상화를 통해 제공돼야 한다. 또한 시스템 타이밍에 영향을 주지 않고, 차량 레벨에서도 데이터의 로깅 및 트레이싱이 가능한 디버깅 도구들을 통해 모든 ECU 내부 통신을 관측할 수 있어야 한다. 마지막으로 위에서 언급된 상호 간의 사이드 이펙트가 없는 SW 통합이 필요하다. 이러한 요구사항은 단지 편의를 위한 것이 아니라 구현할 수 있는가에 대한 문제이다.

위에서 설명한 모든 요구사항들은 OEM이 전체 시스템을 명세하고, 공급받고, 통합하는 “열린” 협력 시나리오 뿐만 아니라, 하나의 티어1 시스템 공급자가 여러 내부 팀들 및 OEM과 함께 복잡한 하나의 도메인 ECU를 통합하는 “닫힌” 환경에 모두 적용될 수 있다.
 


 
HW 및 SW 아키텍처

그림 2의 아키텍처는 차량용 마이크로컨트롤러(Infineon Aurix 혹은 Renesas RH850), FPGA 기반 범용 처리 엔진(Altera Cyclone V), 영상 처리장치(Nvidia 혹은 Renesas R-Car H3), 그리고 추가적인 특별한 센서 처리장치들로 구성된다. 모든 장치들은 Deterministic Ethernet(DE) 스위치에 의해 서로 연결된다. ECU 내부 통신의 디버깅 및 트레이싱을 어렵게 하는 직접적인 두 지점 간의 연결이 없기 때문에, 다수의 SWC들 간의 복잡한 상호작용을 통합하고 디버깅할 때 발생할 수 있는 문제들을 분명히 알 수 있다2). 또한 기존 자동차 네트워크와 연결하기 위한 CAN 및 FlexRay와 함께, 고성능 자동차 네트워크 및 디버깅 인터페이스 연결을 위한 Ethernet을 제공한다.
Deterministic Ethernet 스위치는 FPGA에 통합해 구현되거나, 표준 상용장치(NXP SJA1105T 칩 등)로 구현 될 수 있다. DE 스위치는 일반적인 Besteffort Ethernet 스위치 기능뿐만 아니라 Time-Triggered 방식도 제공한다. Time-Triggered는 FlexRay 통신 모드와 유사하게, 항상 예측 가능한 방식으로 정해진 스케줄에 따라 모든 통신과 스위칭이 일어나는 Deterministic한 동작 모드다. 모든 처리 장치들은 스위치에 동기화되고 그에 따라 내부 태스크 처리를 스케줄링한다. 따라서 DE 스위치는 ECU에 스케줄링의 기준이 되는 하트비트(Heartbeat)를 공급하고, 호스트들 상에 있는 SWC들 간에 충돌과 지터를 회피하는 Deterministic 통신을 가능하게 한다. 그러므로 DE 스위치는 앞에서 언급한 결합성과 Deterministic한 SWC 통합 특성을 보장하기 위한 핵심 요소다.

Note:
처리장치들은 표준 Ethernet MAC 장치들을 사용하며 특별한 HW 변경은 필요 없으나, 동기화된 통신을 지원하기 위해 드라이버와 운영체제 레벨에서의 SW확장이 필요하다.
안전성은 ASIL D를 제공하는 차량용 마이크로컨트롤러, 최대 ASIL B 요구사항을 만족하는 FPGA, 그리고 QM 등급의 알고리즘에 사용되는 GPU를 비롯한 전체 장치에서 ASIL 분해를 적용해 구현된다. 모든 장치들은 메모리 보호를 제공하며 혼합 임계(mixed-criticality) 동작을 지원하기 위한 메모리 독립성을 보장한다. 안전성에 관련된 모든 SWC 간(ECU 내부) 통신에는 종단간(End-to-end) 통신 보호가 적용된다.

각 처리 장치별 운영체제(OS)는 최적 적합 방식에 따라 선택된다:

- 차량용 마이크로컨트롤러는 AUTOSAR Basic SW와 OS를 사용한다. 이 방식은 차량 통신 인터페이스와 Basic SW 서비스, 그리고 공통적으로 사용되는 오토모티브 기능들(진단, 캘리브레이션)을 위한 검증된 SW 스택을 제공한다. 또한 OEM 차량 네트워크와 동작 요구사항을 준수하고, 내부 보안 프로토콜들과 같은 OEM 전용 기능을 쉽게 통합할 수 있게 해준다.

- WindRiver의 VxWorks는 범용 SoC(FPGA)에서 안전성을 지원하는 OS이다. 여기서는 차량용 마이크로컨트롤러 사양보다 높은 성능을 필요로 하는 애플리케이션이 동작하며 최대 ASIL B를 지원한다. VxWorks는 안전성 외에도 여러 검증된 기능들 및 서비스들을 제공하며 POSIX를 준수한다.

- Linux는 특히 쉽고 즉시 사용 가능한 OpenCL, OpenCV, CUDA 등과 같은 영상 처리 라이브러리들이 제공되기 때문에, 고성능 SoC(GPU)들 상에서 안전성과 무관한 처리장치들을 위해 사용된다.

위와 같은 방식에 따르면, 여러 종류의 처리장치들을 고려해 다양한 OS들로 이뤄진 솔루션이 된다. 이 솔루션에서는 애플리케이션들이 각 호스트 별로 완전히 다른 운영 환경과 API를 가지며, 각 SW 컴포넌트는 정해진 호스트에 종속되게 된다. 또한 통신 및 데이터 관리와 같은 기본 메커니즘들은 서로 다른 운영체제들 간에 호환되지 않는다. 결과적으로 특정 OS에 있는 애플리케이션을 다른 호스트로 이동하기 위해서는 추가적인 작업이 필요하게 된다.
 

 

티티텍의 솔루션은 공통 실행 환경과 API를 제공하고 HW와 OS 추상화를 보장한다. 이를 위해 각 OS 위에 제네릭 미들웨어 레이어를 두고 AUTOSAR RTE 통신 타입을 사용한다. 또한 이 RTE 레이어에 많은 유틸리티 기능들을 추가해, 모든 호스트를 위한 제네릭 미들웨어를 구성한다. 미들웨어는 SWC에게 호스트에 독립적인 공통 API를 제공하며, 전체 HW와 OS를 추상화해 완전한 위치 투명성을 제공한다. 이를 통해 애플리케이션은 모든 호스트에서 동일한 서비스를 사용할 수 있다.

또한 SWC의 완전한 이식성도 보장하기 때문에, SWC들은 성능, 메모리 및 안전성에 대한 요구사항에 맞춰 유연하게 처리장치에 배치될 수 있다. 만약 이러한 요구사항들이 변경될 경우, SWC들을 다른 처리 코어와 호스트로 자유롭게 이동하거나 ECU의 처리 성능 및 메모리 사용량을 최적화하는 것도 가능하다. SW 통합자는 SWC의 코드를 수정할 필요 없이 바로 환경설정 단계를 진행할 수 있다.

Deterministic 통합 특성은 앞에서 언급한 것과 같이 예측 가능하고, 통합할 때의 사이드 이펙트가 없다. 이러한 특성을 구현하기 위해서는 각 OS 동기화와 태스크 스케줄링/디스패칭 기능을 활용해 미들웨어에 Time-Triggered 동작 모드를 구현해야 한다.

마지막으로, 미들웨어 레이어는 PC환경에서도 구현돼 있다. 따라서 PC에 있는 애플리케이션과 타깃 ECU에 있는 애플리케이션 간의 SIL 연동을 통해 신속한 프로토타입 개발이 가능하게 할 뿐 아니라, 규격화 돼있는 SW 컴포넌트들 간의 간극을 해소시켜준다. 여기서 타이밍 관련 요소들은 그대로 유지되며, SWC의 어떤 부분도 코드를 변경할 필요가 없다.

정리하면, 성능, 안전성, 개발 및 통합절차뿐만 아니라 모듈화와 확장성에 대한 요구사항을 만족하기 위한 두 개의 중요한 요소들이 있다:

- ECU 내부의 네트워크 통신과 태스크 스케줄링에 대해 Time-Triggered 패러다임을 사용하는 Deterministic한 아키텍처

- 하부의 마이크로컨트롤러와 운영체제의 다양성을 추상화하는 공통의 제네릭 미들웨어 레이어

이 방식이 완전한 확장성을 제공한다는 것에 주목해야 한다. 처리 호스트들이 전체 아키텍처에 영향을 주지 않고 서로 다른 ECU 옵션들 혹은 자동차 모델들에 추가 될 수 있으며, 이러한 변형들 간에 SWC들을 완전히 재사용할 수 있게 해주기 때문이다. 위와 같은 아키텍처는 차량에서 분산된 방식으로 사용되는 경우, 예를 들면 ECU들간에 OABR Ethernet 인터페이스가 사용되는 경우에도 활용할 수 있다. 그리고 모든 주요 기능들이 AUTOSAR 및 POSIX와 같이 안정되고 표준화된 기술과 SAE AS6802 및 IEEE의 TSN(Time-Sensitive Networking)에 정의된 Time-Triggered 통신으로 구축됐다는 것도 주목할 만하다.
 



미들웨어 기능 및 특징

이 섹션에서는 미들웨어 기능의 자세한 개요와 활용 및 이점들을 살펴본다.

통신: 
앞에서 언급한 것과 같이 티티텍에서 구현한 통신 패러다임은 AUTOSAR RTE를 기반으로 구현됐으며, 기본적으로 모든 내부 시그널들이 Ethernet 통신으로 맵핑된다. 이 통신 패러다임은 OS에서 제공하는 상용 Ethernet 통신 스택을 사용한다. SW 통합자는 OEM과 SWC 공급자들로부터 제공받은 시그널 정보를 기반으로 컴파일 시간에 통신 레이어를 자동 생성한다. 통신은 Deterministic Ethernet 스위치를 통해 외부와 연결될 수 있으므로 투명한 디버깅 및 성능 분석이 가능하다(예를 들면 퓨전 레이어에서 시스템 타이밍에 영향을 주지 않고 입력과 출력에 접근 가능하다).
Time-Triggered 방식의 이점은 처리 성능과 지연시간을 사전에 알고 있고 SWC 동작에 영향을 받지 않는다는 것이다. 또한 프로토타입 개발 혹은 디버깅을 위한 동시 시뮬레이션을 위해 PC에서 Ethernet을 통해 SWC를 분리해 실행할 수 있으며, 이때 모든 타이밍 관련 요소들은 변하지 않고 유지된다.

동기화 및 Time-Triggered 태스크 스케줄링:
통신의 경우와 마찬가지로, 모든 주요 태스크의 시작은 미리 정해진 스케줄에 기반한 Deterministic한 방식으로 이뤄진다. 스케줄의 실행시간 제한을 초과하는 SWC는 실행이 연기되는데, 이러한 방식은 특정 상황에서는 적절하지 않을 수 있기 때문에 좀 더 유연한 방식을 사용한다. 즉 SWC는 다른 SWC들이 전부 사용하지 않은 슬롯들을 활용할 수 있으며, 또한 자신에게 할당된 슬롯에 남은 시간에 따라 자신의 동작을 동적으로 조정할 수 있다. 예를 들어 퓨전 레이어에서, 현재 사용 가능한 실행 시간에 따라 식별된 오브젝트들의 개수와 단위를 조정할 수 있다. 이 두 기능을 사용하기 위한 별도의 API 함수가 있으며, 주로 복잡한 계산을 처리하지 않는 기능들에 의해 사용된다.

안전성:
미들웨어는 하부의 OS 및 HW 메커니즘과 함께 개념적으로 ISO26262에서의 SEooC(Safety Element out of Context)로 구현돼 기본적으로 각 SWC를 위한 안전한 실행 환경과 다른 SWC와의 안전한 통신 채널을 제공한다. 같은 호스트 및 원격 호스트들 상에서 SWC 간의 메모리보호, 타이밍 관리 및 종단 간 통신 보호와 같은 보편적인 안전성 메커니즘은 AUTOSAR 메커니즘으로부터 가져온다. AUTOSAR가 아닌 환경에서는 각 운영체제와 호스트 프로세서가 제공하는 기능들을 사용해 적용된다. 추가적으로 특정 호스트에 대한 클록, 전원 공급, 메모리 및 마이크로컨트롤러 코어 모니터링과 같은 HW 종속적인 진단 및 관리기능들은 필요에 따라 구현된다.

저장소 및 데이터 관리: 
각 호스트에 있는 SWC들은 위치 투명한 방식으로 비휘발성 메모리와 휘발성 메모리에 접근 가능하다. 이 방식은 하나의 호스트의 SWC에 의해 쓰여진 데이터를 모든 호스트에 있는 다른 SWC들이 투명하게 사용 가능하다는 것을 의미한다. 미들웨어에서 제공되는 공통 API 함수들이 전체 ECU의 저장소, 데이터 보호, 데이터 전송 및 검색을 보장한다. 이 방식의 기본적인 특징 역시 애플리케이션 SWC들의 완전한 이식성과 위치 투명성을 제공하는 것이다. SWC들은 데이터가 실제로 어디에 저장되는지 전혀 알고 있지 않으며 이를 고려할 필요가 없다. 이 방식은 PC(SIL 환경)에서 실행되는 애플리케이션들도 포함한다.

진단, 캘리브레이션, 플래싱: 
이러한 보조 기능들은 마스터/슬레이브 방식으로 구현된다. 마스터로 동작하는 AUTOSAR 기반 마이크로컨트롤러가 다른 처리 장치들(슬레이브)을 제어함으로써, 외부에서 전체 ECU를 하나의 단일한 개체로 인식하도록 한다. 따라서 도메인 ECU의 내부적인 다양성과 복잡성을 고려한 별도의 진단 및 캘리브레이션 도구가 필요 없으며, OEM 및 SWC 공급자는 이전부터 사용했던 도구들과 개발 절차를 계속 사용할 수 있다.

SW 개발 지원: 
특정한 OS 기능을 대부분 사용하고 데이터 로깅과 같은 일반적인 메커니즘을 확장해 디버깅 및 프로파일링 기능을 지원하는 도구들이 제공된다.
그 중 PC 기반 동시 시뮬레이션 환경은, ADTF 혹은 MATLAB/Simulink에서 프로토타입으로 개발된 SWC와 타깃 ECU 상에서 동작하는 SWC들의 통합을 편리하게 하기 위해서만 사용되는 것이 아니다. PC환경은 타깃 ECU에 비해 훨씬 높은 성능을 가지고 있지만 Time-Triggered 동작 모드에 의해 추상화되기 때문에, 타이밍과 관련한 영향 없이 PC와 타깃 ECU 상에서 동일한 C 소스 코드가 동작할 수 있다. 따라서 기존의 임베디드 타깃 개발 절차에 따라 매우 제한적인 디버깅 및 트레이싱 기능만을 제공하는 완전히 규격화된 컴포넌트들도 풍부한 PC 기반의 디버깅 환경을 사용하는 것이 가능하다.

미들웨어의 대부분(특히 통신)은 고도로 통합된 도구들과 스크립트들에 의해 자동 생성된다. OEM과 SWC 공급자들로부터 받은 통신 매트릭스와 다양한 추가 정보들(특히 리소스 제약, 지연시간 제약, 그리고 데이터 플로 제약)은 플랫폼을 빌드하기 위한 주요 입력들로 사용된다. 각 호스트에 해당하는 환경설정은 기존 AUTOSAR Basic SW 벤더들과 OS 공급자들이 제공하는 도구들을 활용한다.

SWC 개발 및 통합 절차

임의로 통합하는 방식을 사용하는 기존의 통합 절차에서는 모든 SWC를 해당 공급자들이 전달한다. 이후 SW 통합자가 각각의 호스트를 위한 바이너리 플래시 이미지를 빌드한 후 시스템에 로드한다. 리소스의 제약은 SWC 공급자가 전달 전에 조정해야 하지만 처음에는 거의 지켜지지 않는다.

그 결과 SW 통합자는 전체 리소스 한도가 초과되는 것이 거의 확실한 상황에서 SWC들 간의 충돌 원인을 스스로 찾아야 한다. 또한 특정 입력들에 의해 전체적인 기능과 안정성이 결정되는데, 단순한 환경에서는 충돌 원인을 원만하게 처리할 수 있지만, 복잡한 환경에서는 리소스 제한을 초과하는 시스템이 비논리적인 결함과 비일관성을 초래하게 된다. 시스템을 안정적인 상태로 만들기 위해서는 SW 통합자의 중재 작업과 SWC 공급자의 개선 작업이 반복적으로 필요하다. 또한 시스템이 동작해도 SWC 공급자가 일부라도 SWC를 변경하게 되면 전체 시스템을 다시 불안정하게 만들 수 있다. 이러한 상황은 SW 통합자뿐만 아니라 차량 레벨에서 OEM 검증 및 확인 업무를 매우 어렵게 하는 일이다.

티티텍의 아키텍처는 이러한 상황을 완전히 방지할 수 있도록 개별적으로 테스트된 SWC들로부터 통합된 시스템까지 안정적이고 통제된 절차를 제공한다. 이는 모든 통신 및 태스크 시작에 Deterministic 및 Time-Triggered 스케줄링을 사용함으로써 가능하다. 이 방식은 처음에는 유연성이 없어 보이지만 기본적으로 만족돼야 하는 제약사항들을 보장한다.

따라서 전체적인 시스템 결합성을 달성하기 위해 의도적으로 설계 단계에서 엄격한 리소스 사용 계획과 스케줄링을 관리한다. 여기에 모든 타이밍 동작을 사전에 알고 있다는 이점이 더해진다. 이러한 방식 덕분에 데이터 플로 지연시간을 사전에 정확하게 알 수 있다. 기존 통합 절차에서는 이를 경험적으로 측정하거나 시뮬레이션을 통해 검토할 수 있지만 여전히 가변성과 지터에 취약하다.

실제 SW 통합 절차는 SW 릴리즈마다 세 단계로 수행된다. 이 단계들은 OEM이 정의한 SW 통합 단계에서 수행하거나, SWC 공급자들 간에 동기화된 기능 릴리즈 계획에 맞춰 수행될 수도 있다.
 


 

1. 플랫폼 릴리즈: 
SW 통합자는 모든 BSW, OS 및 미들웨어를 포함하는 플랫폼 SW를 환경설정하고 빌드해 SWC 공급자에게 릴리즈한다. 리소스 사용 제한(타이밍, 메모리)은 각 SWC마다 미리 정의되고 조정되며 적절한 태스크 및 통신 스케줄을 통해 구현된다. 모든 SWC들은 ‘스텁’이 된다. 즉 비어 있는 템플릿들과 더미 함수들로 대체된다.

2. (단일)SWC 통합: 
SWC 공급자는 최종적으로 통합된 시스템과 정확히 동일한 환경에서 동일한 타이밍을 가지고, 플랫폼 상에서 스텁들을 교체해 애플리케이션을 통합하고 미리 정의된 리소스 제한 내에서 SWC를 테스트 한다. 테스트된 SWC들은 시스템 릴리즈를 위해, 사용된 테스트 케이스들과 함께 SW 통합자에게 전달된다.

3. 시스템 릴리즈:
SW 통합자는 모든 SWC 들을 통합하고 완전하게 빌드된 결과를 차량 혹은 테스트 벤치에 통합하기 위해 OEM과 SWC 공급자에게 전달한다. 모든 SWC들은 정확히 단일 SWC 구성(단계 2)에서와 동일하게 동작하며 모든 테스트 벡터가 재사용되고 그 결과도 유효하다. 추가적인 조치 없이도 전체 시스템은 즉시 안정적인 상태가 된다.

실제로는 SIL 릴리즈라고 하는 단계 0이 있다. 이 단계는 초기에 PC 기반의 환경에서 독립적으로 SWC를 개발하기 위한 환경을 제공한다.

단계 3에서 SWC들은 통합 전에 자신의 리소스 제한을 만족하는지 검사돼(승인 테스트) 만족하지 않으면 통합이 거부된다3). 리소스 제한을 만족하지 않는 SWC들이 있는 경우, 시스템이 완전히 동작하는 상태가 아닐 수 있지만, 적어도 이것을 미리 알고 있기 때문에 필요한 수정 조치를 할 수 있다. 기존 아키텍처와 통합 절차에서는 단순한 환경에서도 이러한 문제를 인식하지 못 할 수 있기 때문에, 복잡한 환경이 됐을 때는 해결하기가 훨씬 어려운 불안정한 시스템 상태를 초래할 수 있다.

각 SWC 공급자는 시스템 릴리즈 단계에서 미리 정의된 리소스 제한을 지키면서 점진적으로 자신의 SWC를 업그레이드해 추가 기능을 개발하거나 개선할 수 있다.

이러한 통제된 통합 절차와 이를 가능하게 해주는 HW/SW 아키텍처와 미들웨어 방식으로부터 얻을 수 있는 특별한 이점들과 결과들은 다음과 같이 정리할 수 있다:

- 예측 가능하고 명확한 통합 절차로, 타이밍과 메모리 충돌 없이 동작하는 시스템이 SWC들로부터 자동 생성된다.
- 실제 실행시간에 필요한 모든 SWC의 요구사항들을 알고 있다. 이 정보는 통합 리포트에서 수집된다.
- 실제 데이터 플로 지연시간과 SWC들의 시작 순서를 알고 있다. 이 정보는 통합리포트에서 수집된다(실제로는 첫 번째 단계인 스케줄링/플랫폼 릴리즈 이후에 이러한 수치들을 이미 알고 있다).
- 데이터 플로 지연시간 및 모든 타이밍 관련된 요소들을 정확히 알고 있으며, 이 값들은 고정돼 있다. 이 요소들은 가변성이나 지터가 없기 때문에, 애플리케이션 테스팅과 애플리케이션 검증 분량이 상당 부분 감소한다.
- 다른 SWC들의 수행을 멈추게 하는 등의 사이드 이펙트를 방지한다.

양산 개발

앞에서 설명한 HW 아키텍처는 실제 양산 프로젝트에서 전체 ECU 비용 중 매우 적은 비용으로 구현됐다. 앞에서 살펴본 다양한 처리장치들외에 추가로Deterministic Ethernet 스위치가 필요하다. 이 스위치는 FPGA에 통합됐으나, 처리능력과 인터페이스 유연성이 추가로 필요한 경우 NXP의 SJA1105T로 대체할 수 있다.

자동 긴급제동 기능에서 자율주행 기능들까지, 다양한 옵션 패키지들을 지원하기 위해 여러 ECU 옵션들이 구현됐다. 미들웨어에 의해 HW 및 OS가 추상화되므로, SWC들은 자신이 어디에서 실행되고 있는지 알지 못한다. 따라서 ECU 옵션에 따라 SWC들은 다른 호스트에 위치할 수 있으며, SWC 공급자들에게는 여러 ECU 옵션들을 지원하기 위한 추가적인 작업이 필요 없다.

SW 통합 절차는 의외로 작은 팀 구성으로 순조롭게 진행됐다. 통합 절차가 명확하게 정의돼 있었고 복잡하지 않았으며 여러 유용한 기능이 있는 개발 및 통합 플랫폼을 SWC 공급자들에게 제공했기 때문이다.

또한 기존의 개발 절차에서 필요로 하는 관리 기능들에 대한 부담을 대부분 덜어줌으로써 SWC 공급자들은 이 새로운 절차에 빠르게 적응했다.
기본적으로 필요한 요소들을 플랫폼과 미들웨어가 제공하기 때문에 SWC 공급자들은 단순히 알고리즘 구현에 초점을 맞출 수 있다. 물론 리소스 사용량을 추정하고 시스템 전체의 리소스 제약 사항을 사전에 조정하는 것과 같은, 모든 양산 개발에서 필요로 하는 조치들은 불가피하지만 이 외의 추가적인 노력은 발생하지 않는다.

플랫폼에서는 SWC를 코드 변경 없이 다른 처리 호스트 간에 이동하는 것이 가능하다. 이러한 상황은 특히 SW 통합 단계에서 빈번하게 발생한다. SW 통합 과정에서 반복되는 개선과 학습 및 최적화 작업을 통해 일부 SWC의 리소스 사용량이 너무 적거나 너무 많게 추정됐다는 것을 알게 되므로, SWC 들의 배치를 변경하는 일이 발생하게 된다.

현재는 센서 처리 및 다양한 센서 퓨전 컴포넌트들부터 자율주차 및 자율주행과 같은 다수의 사용자 기능들까지 10개 이상의 공급자로부터 30개 이상의 애플리케이션이 통합된다. 고도로 기술적이고 복잡한 구조를 가진 이 프로젝트는 Deterministic한 아키텍처, 제네릭미들웨어 및 엄격한 통합 절차 없이는 아마 성공하기 힘들었을 것이라고 확신한다.

지금까지 고도로 통합된 도메인 ECU를 위한 새로운 아키텍처와 통합 방식에 대해 살펴보았다. 현재 이러한 아키텍처와 통합 방식은, 기존 차량용 마이크로컨트롤러에서 고성능 그래픽 엔진까지 다양한 처리 장치를 가진 복잡한 중앙 ADAS 제어기의 양산 개발에 성공적으로 적용되고 있다. 성능, 안전성, ECU의 모듈화 및 확장성과 개발 및 통합 절차에 대한 모든 요구사항을 만족하기 위해 두 개의 주요 요소들이 사용된다:

- Deterministic Ethernet 스위치가 포함된 Deterministic HW 및 SW 아키텍처에서 내부 통신 및 태스크 스케줄링에 Time-Triggered 패러다임을 활용한다. 이는 애플리케이션 SW 컴포넌트와 통합된 시스템의 타이밍 동작을 예측 가능하게 한다.
- 애플리케이션 SW 컴포넌트를 위해 공통적이고 범용적인 AUTOSAR RTE 기반 미들웨어 레이어를 사용한다. 이는 하부에 있는 마이크로컨트롤러 및 운영체제의 다양성을 추상화한다.

이 아키텍처는 디버깅 및 유틸리티 기능들과 함께 구현되며, 애플리케이션 SW컴포넌트에 이식성과 위치 독립성을 보장함으로써 SWC를 할당하고 시스템을 분할할 때 완전한 유연성을 보장한다.

Deterministic, Time-Triggered 패러다임에 의한 통합 절차는 기존 임의 통합 방식에서의 반복적이고, 많은 시간과 비용을 소요하는 문제들 없이 매끄럽게 SWC들을 통합할 수 있게 하며, 완전한 예측 가능성과 결합성을 보장한다.  

<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>

PDF 원문보기

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)

  • 100자평 쓰기
  • 로그인


TOP