글│서지 리프(Serge Leef)
    시스템 레벨 엔지니어링 사업부 총괄 매니저
    멘토 그래픽스

최근 떠오르고 있는 자동차 설계 소프트웨어 표준인 AUTOSAR(Automotive Open System Architecture)는 유럽 자동차 메이커와 그 서플라이어를 아우르는 업계 전반에 걸친 노력의 결과로 탄생했다. 이 표준은 자동차 내의 분산된 시스템 설계에 체계와 명확한 인터페이스, 암시적 방법론(implicit methodologies)을 제공하는 데 목표를 두고 있다.
FlexRay™는 특히 CAN(Controller Area Network)과 같은 기존 차량용 통신 프로토콜  표준의 단점을 해결하기 위해 등장한 시리얼 버스 규격으로, AUTOSAR와 마찬가지로 FlexRay 역시 많은 유력 자동차 OEM과 서플라이어의 지지를 얻고 있다. 차량 내 다른 통신 프로토콜보다 모든 면에서 뛰어난 성능을 자랑하는 FlexRay는 유일하게 전동식 조향장치와 제동장치 등 “x-by-wire” 애플리케이션에 적합하다.
그렇다면 복잡한 자동차 기능이 모두 안정적으로 작동하도록 해야 하는 설계자에게 이와 같은 발전은 어떤 관계가 있을까? 혹은 설계 비용을 최소화해야 하는 경영진에게는 어떤 의미가 있을까? 또 운전자와 승객에게는 어떤 혜택을 줄 것인가?
현재 자동차 업계는 과도기에 있다. 규제 당국과 자동차 바이어들은 보다 작고 환경친화적인 자동차를 요구하고 있다. 이러한 요구를 만족시키기 위해서는 R&D 및 인력에 보다 많은 시간과 비용을 쏟아부어야 한다. 설상가상으로 규제 당국이나 소비자가 요구하는 각각의 새로운 기능으로 인해 차량 내 네트워크의 부담이 갈수록 커지는 상황이다. 또한 안정성 개선, 설계 유연성 확장 및 개발 비용 절감에 대한 압박도 끊임없이 제기되고 있다.
이 글을 통해 AUTOSAR와 FlexRay가 이러한 목표를 달성하는데 미치는 영향을 진단하고, 자동차 애플리케이션을 위한 네트워크 최적화의 중요한 문제에 대해서도 집중 조명하고자 한다.

AUTOSAR과 FlexRay의
숙명적 만남

AUTOSAR는 기본적으로 인터페이스와 소프트웨어 모듈 정의를 아우르는 표준이다. 또한 궁극적으로 차량의 복잡한 네트워크 기반 분산 시스템을 운용하는 임베디드 소프트웨어의 구조를 명시한다. AUTOSAR는 설계자가 독창적이면서 혁신적인 기능에 집중할 수 있도록 하는 동시에, 세부 통합 구현에서 독창적인 애플리케이션 로직을 보호할 수 있게 해주는 새로운 플랫폼으로 볼 수 있다.
이런 관점에서, 차량 내 “기능”에는 온도조절, 변속기 제어, ABS(Anti-Lock Brake System), 서스펜션을 비롯해 크고 작은 많은 부품이 포함된다. 또한 차량의 운전자/승객이나 다른 전기/전자 서브시스템과 상호 작용해야 하는 모든 서브시스템이 포함된다. 현재 이러한 기능들은 각각의 ECU (Electronic Control Unit)에 의해 제어 된다.
그러나 AUTOSAR의 세계에서는 사정이 좀 다르다. 여기서 기능은 AUTOSAR 호환 ECU에서 실행할 수 있는 하나 또는 여러 개의 소프트웨어 컴포넌트(Software Component, SWC)로 구성돼 있다. SWC는 최종 제품에 차별화된 독특한 기능을 구현한다.
AUTOSAR 접근방식과 단일 용도 ECU로 구성된 기존 아키텍처를 비교해 보자. 이전 접근방식에서는 각 ECU가 고정된 소프트웨어 정의와 연관돼 있다. 또한 특정 단일 작업에 대해 맞춤식으로 프로그래밍 되고 하드와이어링(Hard-wired) 된다. 반대로 AUTOSAR 호환 ECU는 해당 기능에 따라 차량 작동 시 ECU의 역할이 정의되는 소프트웨어 컴포넌트에 대한 중립적인 “독”(dock)이다. 두 하드웨어 모듈이 외견상 동일한 것을 감안한다면, 하나는 온도조절 시스템을 운용하고 다른 하나는 대시보드 기능을 운용할 수 있을 것이다. 따라서 재사용성 측면이 크게 증대될 수 있다.
AUTOSAR SWC는 계산, 제어 및 통신 작업을 수행하는 기본 메커니즘을 전면에 내세우는 AUTOSAR Runtime Environment라는 API(Application Programming Interface)를 통해 상호 작용한다. 그림 1에서는 AUTOSAR 호환 ECU에 나타나는 이 모델의 단순화된 개요도를 보여준다.
하부 계층은 대개 “공통적”이지만 SWC의 상부 계층은 설계자의 창의성에 따라 달라진다. 그렇다면 이것이 의미하는 것은 무엇일까? 오늘날 일반적인 차량에는 20개 이상의 다른 ECU가 들어가지만, AUTOSAR는 동작이 애플리케이션 콘텐츠에 따라 결정되는 몇 가지 서로 다른 유형으로 ECU를 줄일 수 있다. 예를 들어, 저가형 4비트 ECU는 도어록이나 창문 제어 장치에 충분할 수 있지만, 실시간 파워트레인 제어를 실행하는 데는 32비트 유닛이 필요할 것이다. 차량에는 여전히 20개 이상의 ECU가 들어가겠지만, 이들 중 하드웨어 유형이 서로 다른 것은 네 개 내지 다섯 개뿐일 수 있다.
AUTOSAR ECU의 I/O 신호 환경은 전적으로 통신 스택의 콘텐츠에 따라 결정된다. 즉, 버스 프로토콜이 작동하는 소프트웨어 컴포넌트와 격리돼 있다. 그림 1에서처럼 ECU는 유연성 있게 가장 빠른 FlexRay 버스나 가장 느린 LIN 버스를 동일하게 구동할 수 있다. 따라서 두 버스 모두 동일한 ECU 내에서 운용할 수 있다.
AUTOSAR는 차량 내 서브시스템 간의 관계를 크게 변화시킬 수 있으며, FlexRay와 함께 자동차 아키텍처와 설계 양상을 크게 바꿔 놓을 것으로 예상된다.

자동차 설계 및 생산을 위한
새로운 접근방식

기존 자동차 비즈니스 모델에서는 여러 서플라이어 계층에서 OEM에 통합을 위한 완성된 서브시스템을 제공하기 때문에 사인오프 단계가 지나면, OEM이 설계 모양을 변경하기 어려웠다. 하지만 AUTOSAR와 FlexRay는 이러한 기존 방식을 변화시킬 것이다.
AUTOSAR는 매우 복잡한 일부 설계 작업의 속도를 높이고 OEM이 각자의 차량 아키텍처를 보다 효율적으로 제어할 수 있게 해 줄 것이다. 또한 전문 벤더는 AUTOSAR 호환 부품을 제공하고 OEM은 brake-by-wire 시스템 등을 위한 구성요소 및 표준화된 ECU만 주문하면 될 것이다. OEM 설계 팀은 필요한 기능과 안전 기능을 지원하는 소프트웨어 컴포넌트(애플리케이션)를 추가하게 된다.
FlexRay는 가장 기본적인 일부 자동차 기능에 대해 새로운 접근방식을 지원하게 될 것이다. 아울러 이들 두 표준 간에는 강력한 시너지 효과가 나타날 것이다. AUTOSAR는 FlexRay 시스템의 채택을 훨씬 용이하게 해주며, FlexRay는 AUTOSAR 프로그래밍 구성 및 신호 분배 기법에 원활하게 적용된다. FlexRay는 본질적으로 이전의 유압식 플랫폼보다 x-by-wire 시스템과의 전자적 상호 작용을 모니터링하고 제어하기가 쉽기 때문에 AUTOSAR 소프트웨어 컴포넌트에 도입된 혁신적인 기능에 적합하다.

AEM_Automotive Electronics Magazine