POSIX OS는 새롭고 다이나믹한 차량용 소프트웨어 애플리케이션의 기초가 된다. 그러나 진단, 네트워크 관리, SOME/IP 등과 같은 자동차 관련 기능은 부족하다. 이러한 작업들을 지원하는 표준인 AUTOSAR Adaptive를 새로운 자동차 OEM 프로젝트에 적용할 수도 있겠지만, 차량 플랫폼이 아직 AUTOSAR Classic에 기반으로 하고 있다면 POSIX 운영 체제를 성공적으로 활용할 수 있는 방법은 무엇일까?
AUTOSAR Classic 소프트웨어 표준에 기반한 ECU 프로젝트는 현재까지 폐쇄적이며 상호 작용하는 하위 기능이 고정된 정적 시스템이었다. Linux와 같은 POSIX OS는 이제 소프트웨어를 동적으로 로딩하고 실행할 수 있는 옵션을 제공한다. 이러한 특성은 자율주행과 같은 새로운 기능을 위한 중요한 요건이 된다. 그러나 아직 모든 자동차 OEM이 AUTOSAR Adaptive를 채택한 것은 아니다. 서플라이어에 AUTOSAR Classic 모듈만 제공되는 경우 ECU 개발자는 문제에 직면하게 된다. 진단 프로토콜과 같은 검증된 AUTOSAR 베이직 소프트웨어나 이를 위해 개발된 소프트웨어 컴포넌트를 어떻게 POSIX 시스템에서 작동시킬 수 있을까?
결국 전체 AUTOSAR Classic 사양은 완전히 다른 유형의 OS, 특히 정적 구성 프로세스를 기반으로 한다. 사실, 특정 속성이 고려된다면 두 유형의 ECU 소프트웨어를 동시에 사용할 수 있다. 하지만 고려해야 할 요소는 정확히 무엇일까? AUTOSAR 베이직 소프트웨어(BSW)는 본질적으로 C언어로 구성되어 있다. 이를 별도의 POSIX 프로세스(그림 1)로 작동시키는 것은 아주 까다로운 일은 아니다. 베이직 소프트웨어의 시스템 한계에 봉착하기 전까지는 큰 어려움이 없다. 이 한계는 주변 하드웨어에 의해 결정된다.
한계를 조정하려는 경우에도 Linux 커널 스페이스는 실제로 변함이 없어야 한다는 기본 원칙이 지켜져야 한다. 특수 하드웨어 컴포넌트를 위한 드라이버 추가는 허용되지만, 기존 커널 컴포넌트는 변경되지 않은 상태로 유지되어야만 한다. 그러지 않으면 정상적인 보안 패치마저도 문제를 일으킬 수 있기 때문이다.
간단한 ECU 프로젝트에서 어떻게 AUTOSAR Classic과 POSIX OS를 실제로 구현할 수 있는지 <그림1>과 같이 도식화할 수 있다.
Linux가 ECU의 OS로 사용될 것이라고 가정해 보자. 프로젝트에 는 진단 인터페이스로 값이 읽혀지는 동작 시간 카운터가 지정되었다. 이 경우, 진단요청 수행에 이미 검증된 솔루션인 AUTOSARClassic 외에 특별히 고려되어야 할 사항은 무엇일까?
통신 인터페이스로서의 Ethernet
우선 통신 인터페이스를 확인하는 것이 중요하다. 이러한 접근 방식과 관련된 대부분의 ECU는 Ethernet을 기반으로 한다. POSIX OS는 일반적으로 하드웨어 컨트롤러 드라이버와 상위계층 TCP/IP 프로토콜 소프트웨어를 제공한다. 이를 활용하여 AUTOSAR Classic 애플리케이션은 AUTOSAR 드라이버를 통해 네트워크에 연결되지 않고, 대신 BSD 소켓으로써 연결된다. TCP/IP 인터페이스가 다른 모든 Linux 프로세스에서 일반적인 형태로 사용할 수 있다는 것이 장점이다.
TCP/IP 통신을 사용하는 애플리케이션에는 변함이 없고, 이러한 방식은 대부분의 애플리케이션에 적용된다. 그러나 타임스탬프 (TSyn) 또는 우선순위 결정(QoS)과 같은 순수 TCP/IP 데이터 스트림을 넘어서는 속성이 추가로 필요한 경우에는 한계에 도달하게 된다. 이는 커널 스페이스의 드라이버에 개입하는 것과 같은 프로젝트에 특화된 솔루션이 구현되어 있을 경우에만 가능하다.
또한, 소켓 접근법은 CAN 통신용으로도 권장된다. 이 경우 인터페이스와 전송 프로토콜로 구성된 CAN 베이직 소프트웨어는 드라이버가 아닌 소켓에 존재한다. 이 경우 애플리케이션 소프트웨어에 수신된 메시지 필터링이 필요하다. 예시와 같이 동적 시스템이 필요한 경우 드라이버를 미리 지정된 통신 매트릭스로 설정할 수는 없다. 이 접근 방식으로는 인터럽트 모드나 Full-CAN 객체가 사용될 수 없다는 것이 순수 임베디드 시스템과 다른 점이다. 그럼에도 불구하고, 실제로는 아무런 문제가 없다.
상태 관리자와 워치독
AUTOSAR Classic에서 네트워크 매니지먼트는 버스 유휴 상태와 정상 동작 간 전환을 제어한다. 이러한 방법은 POSIX 운영 체제 아래에서도 사용될 수 있지만, 상태 변경은 이 전용 프로세스에서만 유효하다. 즉, 해당 CAN 버스에서 다른 프로세스가 계속 활성화되어 있는 상황을 배제하는 것은 불가능하다. 이러한 이유로 AUTOSAR 베이직 소프트웨어(SYS 모듈) 시스템서비스의 상태관리자는 최소한의 사항만을 관리한다.
이는 AUTOSAR 프로세스의 모듈을 제어하는 데 매우 유용하고, 동시에 실행되는 다른 프로세스에는 영향을 미치지 않는다. 따라서 시스템 시작 및 ECU 종료를 모니터링하는 중앙 제어 프로세스가 추가로 필요하다. 이러한 사항은 워치독에도 적용된다.
AUTOSAR 워치독은 순수 Classic 시스템에서 사용하도록 설계되지만, 워치독이 Linux 시스템을 종료하는 것은 허용되지 않으므로 Linux에서는 통용되지 않는다. Linux에서는 Classic 프로세스 재시작을 권장하는 정도로 워치독의 역할이 국한된다. 이 제한은 하드웨어 워치독을 제어하는 것으로는 변경할 수 없으므로 AUTOSAR 프로세스의 상태를 모니터링하여 오류가 발생할 경우 POSIX 운영 체제가 직접 프로세스를 재시작하도록 한다.
진단 및 RTE 처리
진단 기능을 실행하는 것은 거의 모든 ECU에 영향을 미친다. AUTOSAR Classic은 이에 적합한 소프트웨어 모듈을 정의하고 있다. POSIX 시나리오의 장점은 이러한 진단 모듈과는 독립적으로 OS 유형을 선택할 수 있다는 데 있다. 그러나 비휘발성 메모리를 오류 메모리로 사용하는 경우는 해당하지 않는다. 위에서 언급된 동작 시간 카운터를 예로 들면, AUTOSAR 하드웨어 드라이버를 직접 액세스할 수 없고, 대신 POSIX 운영 체제의 파일 시스템을 액세스해야만 한다. 이를 위해 소프트웨어 인테그레이터는 래퍼를 사용하여 파일 시스템의 기능에 AUTOSAR 인터페이스를 매핑하게 된다(그림 2).
실제 AUTOSAR Classic 애플리케이션은 통신 모듈(COM) 또는 진단 통신 매니저(DCM)와 같은 BSW 모듈 계층 위에 위치한다. 다른 POSIX 프로세스가 AUTOSAR 인터페이스와 호스트 운영 체제의 프로세스 간 통신(IPC) 메커니즘을 연결하는 데이터를 제공하거나 처리하는 경우 적절한 래퍼가 필요하다. 물론 AUTOSAR 런타임 환경(RTE)을 사용하여 AUTOSAR 소프트웨어 컴포넌트와 베이직 소프트웨어에 접근할 수도 있다.
단, 여기서 한 가지 염두 할 점은 다른 모듈과는 달리 RTE는 AUTOSAR OS의 시스템 서비스를 매우 집중적으로 사용한다는 사실이다. 그래서 RTE는 AUTOSAR-OS와 결합해서만 사용될 수 있다.
동일한 커널에서 두 OS를 동시에 사용하는 것은 불가능하다. 이 둘은 더 많은 리소스를 차지하려고 경쟁하기 때문이다. 이 문제를 해결하는 한 가지 방법은 POSIX OS를 확장하여 또 다른 가상 시스템이 포함될 수 있도록 하는 것이다. 이 머신은 컴퓨팅 시간과 하드웨어 통제권을 AUTOSAR OS에 요청할 수 있다. 이 목적에 맞게 특별히 고안된 AUTOSAR OS 베리언트를 사용함으로써 이를 간단히 구현할 수 있는데, AUTOSAR OS 베리언트는 게스트 OS로서 하드웨어를 직접 액세스하지 않고 호스트 운영 체제의 서비스를 이용한다. Vector 베이직 소프트웨어 솔루션 MICROSAR POSIX는 이와 같은 게스트 OS가 포함되어 있어 호스트 OS의 확장이나 기타 수정 작업이 필요하지 않다는 장점이 있다.
게스트 OS의 한계
게스트 OS는 AUTOSAR 사양에 포함된 중요한 시스템 서비스를 모두 제공한다. 그러나 AUTOSAR OS가 프로세서를 완전히 제어하는 시스템에 비해서는 그 한계가 명확하다. 그 일례로 확장성 클래스 SC1만을 지원한다는 것을 들 수 있다. 게스트 OS는 사용 중인 프로세서에 대한 직접적인 제어 기능이 없기 때문에 확장성 클래스 SC2와 SC4 OS에서 지원하는 런타임 및 메모리 보호 기능을 제공할 수 없다.
이는 호스트 OS가 관장하는 인터럽트 관리 작업에도 적용된다. DisableAllInterrupts() / EnableAllInterrupts()와 같은 AUTOSAR OS의 시스템 호출은 실제로 인터럽트를 사용 또는 사용 해제로 설정하는 경우 호스트 OS와의 심각한 충돌을 일으킬 수 있다. 순수 AUTOSAR 환경에서는 이 명령어들을 한 쌍처럼 사용해 여러 태스크가 공유하는 메모리 영역에 읽기 및 쓰기 프로세스를 보호한다. 따라서 게스트 OS는 다른 메커니즘에 의해 내부적으로 이 인터럽트 비활성화를 시뮬레이션해야 한다. 예를 들어 Disable- AllInterrupts()에 의한 인터럽트 비활성화로 인해 게스트 OS는 스레드 변경(예: 작업 변경)을 허용하지 않는다. 이는 데이터 일관성이라는 목표를 달성하므로 다른 AUTOSAR 컴포넌트의 코드를 변경할 필요가 없다.
또 다른 한계는 시간 관련 행위에 적용된다. 알람은 평소와 같이 정의할 수 있으며, 작업 활성화에 사용할 수 있다. 그러나 이러한 작업을 실행할 때 호스트 시스템은 프로세스 스케줄링과 스레드 스케줄링을 간접적으로 결정하게 된다. 실제로 알람을 설정하여 5ms마다 작업을 활성화할 수 있다. 그러나 호스트 OS가 AUTOSAR 프로세스에 10ms마다 프로세싱 슬롯을 제공하는 경우 이는 거의 사용되지 않는다. 하지만 전혀 문제가 되지 않으며 오히려 호스트 시스템을 어떻게 구성해야 하는지가 중요한 문제가 된다. 결국 POSIX 기반 ECU의 주요 초점은 실시간 성능이 아닌 소프트웨어의 유연성과 동적인 리로딩에 있다.
효율적인 프로세서 간 통신을 위한 솔루션
테스터와의 통신과 같은 일반적인 응용 사례는 문제없이 앞서 설명한 예제에서 구현할 수 있다. ISO 26262 표준에 따라 엄격한 실시간 요구 사항 또는 높은 안전 수준을 충족해야 한다면 멀티 프로세서 또는 시스템 온 칩(SoC) 아키텍처가 적합하다. 이러한 아키텍처는 애플리케이션의 중요 부분을 순수 AUTOSAR 환경으로 이동시킬 수 있도록 한다. 이러한 경우 두 운영 체제 파티션들 간에 통신이 필요하다. 구현이 까다로운데, 두 운영 체제에 알려진 데이터 설명과 적절한 전송 프로토콜이 필요하다는 부분 때문에 그렇다.
벡터는 MICROSAR.IPC의 형태로 프로세서 간 통신에 사용 가능한 솔루션을 제공한다. 이 모듈 패키지는 POSIX, AUTOSAR Adaptive 또는 AUTOSAR Classic에 기반한 OS의 모든 조합의 프로세서 간 통신을 가능하게 하고 모듈러 레이아웃으로는 하드웨어 드라이버를 전환할 수 있다. MICROSAR.IPC는 멀티코어 아키텍처(공유 메모리를 통해)와 멀티 프로세서 아키텍처(직렬 전송을 통해) 모두에 사용할 수 있다.
결론
AUTOSAR Adaptive는 자동차 기능을 POSIX 환경에 결합해 구현하기 위한 개발 과정에 사용된다. AUTOSAR Adaptive는 사용 가능한 동적 환경을 효율적으로 활용하며 자동차 애플리케이션에 이상적인 런타임 환경을 제공한다(그림 3).
AUTOSAR Classic을 기반으로 하는 솔루션은 정적으로 구성되어 있어 AUTOSAR Adaptive 솔루션보다는 유연성이 덜하다. 하지만 AUTOSAR Classic을 기반으로 한 기존 솔루션은 여기에 제시된 MICROSAR POSIX 방식을 사용하여 시스템에 안정적으로 통합할 수 있으며, 이를 기반으로 공급업체는 모든 자동차 OEM에 적합한 솔루션을 제공할 수 있게 된다.
글/Helmut Brock 박사, 벡터
Helmut Brock 박사는1999년부터 Vector에서 임베디드 소프트웨어 솔루션 관리자로 근무 중이다.
