높은 수준의 자율주행은 기존의 안전 콘셉트와 비교해 새로운 사양이 요구된다. 이제 안전 상태(safe state)에 도달하는 데 단순히 어느 기능을 비활성화하는 것만으로는 충분치 않다. 향후의 안전 상태에서는 동작과 기능을 요구하게 될 것이다. 이 글은 이에 필요한 메커니즘과 그것이 어떻게 모듈 단위로 결합해 효율적인 안전 상태를 확보하는지를 보여준다. 또 미래의 고장 허용(fault tolerant) 시스템이 맞이하게 될 도전에 대한 인식의 필요성과 AUTOSAR를 통해 그 도전을 효율적으로 극복할 수 있음을 설명한다.

최근의 차량 안전 시스템에서 고장에 대처하는 데 가장 많이 쓰이는 방법은 고장이 난 기능을 비활성화시키거나 리셋하는 것이다. 이것을 고장 침묵(fail-silent)이라고 한다. 이 솔루션은 효율적으로 안전 상태에 도달하고 유지할 수 있으며 구현이 용이하다. 그러나 차량 E/E 시스템에서 마이크로컨트롤러 결함과 같은 고장의 경우에도 작동을 보장해야하는 기능들이 많아지고 있다. 이를 fail-operational이라고 하며 본문에서는 고장 허용(fault-tolerant)이라고 칭한다.

앞으로 차량의 고장 허용 시스템 수요가 상당히 늘어날 것이다. 예를 들어 중형 SUV에는 운전자가 조향을 안전하게 제어할 수 있도록 조향 지원 시스템(steering assist systems)을 동작 상태로 유지해야 한다. 고장 침묵 시스템 개발은 ISO 26262를 통해 상당히 잘 이뤄졌지만, 고장 허용 시스템의 설계 문제는 ISO 26262만으로는 해결하기 어렵다. 특히 안전 상태를 정확히 정의하는 것부터가 골칫거리다. 2017년이나 2018년에 발표될 ISO 26262 제2판 역시 이를 명확히 하지는 못할 것이다. 본문에서는 표준사양의 요구 이외에 AUTOSAR 기술을 통해 기존의 안전 개념이 어떻게 고장 허용 시스템으로 확장되는지 보여줄 것이다.

고장 침묵 시스템의 모듈형 안전 개념

안전 엔지니어는 모듈 개념을 이용해 다양한 안전 메커니즘을 특정 프로젝트에 효율적으로 조정해 활용한다(그림 1). 그림은 마이크로컨트롤러의 무결성 감지 방안, 기능관련 모니터링 방안, 전반적인 기능안전성 방안에 대한 대략적인 차이를 보여준다.

마이크로컨트롤러의 무결성을 확보하기 위한 방안은 소프트웨어의 가장 높은 ASIL(Automotive Safety Integrity Level)에 맞게 선택된다. 이것은 ECU가 수행할 다른 기능과 독립되며, 해당 ASIL에 요구되는 진단 커버리지(DC)에 따라 결정된다.

마이크로컨트롤러 제조업체는 자체적인 안전 분석을 기반으로 특정 요구사양을 정하는 경우가 많다. 예를 들어, ASIL D의 DC는 소프트웨어에 의해 주기적으로 실행되는 내장 자체 테스트(BITs)를 요구한다. 일반적으로 ASIL B 등급 이상은 이른바 SEU(Single Event Upset)의 발생 가능성을 반드시 고려해야 한다. 마이크로컨트롤러의 락스텝 모드와 메모리 ECC 기능이 SEU에 대한 효과적인 보호대책을 제공한다. 두 안전 메커니즘 모두 하드웨어에서 구현되고, 소프트웨어개발 시에도 접근할 수 있어 매우 효율적인 솔루션이라 할 수 있다.

개발자는 보통 애플리케이션에 추가 메커니즘을 구현해 기능 모니터링을 수행한다. 여기에는 리미터(limiters), 프로그램 플로우 모니터링(logic 모니터링)뿐만 아니라 센서 및 액추에이터 모니터링도 포함된다. 예를 들어 프로그램 플로우 모니터링은 AUTOSAR 워치독으로 수행할 수 있다.

기능 모니터링과 마이크로컨트롤러 무결성은 특정 프로젝트별로 정의되고 구현된다. 그러나 안전과 관련된 거의 모든 ECU에 사용되며 기능 및 ASIL과 독립된 메커니즘도 존재한다. ASIL 소프트웨어가 탑재된 ECU는 대부분 QM 소프트웨어를 실행한다. ISO 26262에 의거해 ASIL 소프트웨어와 QM 소프트웨어가 공존하기 위해서는 메모리 분할과 시간제한 모니터링이 필요하다[1]. 메모리 분할은 요구되는 ASIL과 함께 MPU(Memory Protection Unit)을 제어하는 AUTOSAR OS SC3로 구현된다.

워치독은 데드라인 모니터링에 따라 시간 요건 모니터링을 처리한다. ECU 사이에 안전과 관련된 데이터가 교환되는 경우, 통신 보호가 필요하다. AUTOSAR는 이를 위해 종단 간 보호(E2E Protection)의 형태로 효과적인 안전 메커니즘을 제공한다. ASIL D까지 인증된 벡터의 제품을 통해 이와 같은 종합적인 측정을 구현할 수 있다.

고장 허용 시스템으로의 전환

최근의 하드웨어는 비용 상의 이유로 중복된 기능이 거의 없이 설계된다. 따라서 하드웨어의 결함은 심각한 기능 저하를 초래하며, 전체적인 고장을 일으킨다. 다른 한편으로는 IEC 62380과 SN29500에서 정의된 것과 같이 표적 고장률을 예상해 하드웨어 고장을 정량화하는 방법이 있다[2].
소프트웨어의 결함은 전적으로 시스템적인 오류이기 때문에 소프트웨어 고장은 정량화하기가 쉽지 않다[3].

소프트웨어의 결함에 대해 타이밍 보호는 고장 허용 향상에 적합한 안전메커니즘이 된다. 타이밍 보호기능으로 소프트웨어 컴포넌트 무한 루프와 같은 본래 기능의 실행을 방해하는 결함을 방지할 수 있다. 타이밍 보호에서 개발자는 태스크 및 인터럽트루틴의 수행시간과 인터럽트 및 리소스에 의한 차단시간에 대해 시간 예산을 할당할 수 있다. 각 태스크 간, 인러텁트 루틴 간의 시간 간격 역시 모니터링된다(그림 2). 고장이 발생하면 AUTOSAR 운영체제가 고장을 유발한 태스크나 인터럽트 루틴을 중단시켜 추가적인 실행이 되지 않도록 배제할 수 있다. 하지만 이러한 타이밍 보호는 향후 필요한 고장 허용 시스템을 향한 첫걸음일 뿐이다.

고장 허용 시스템으로의 전환

최근의 하드웨어는 비용 상의 이유로 중복된 기능이 거의 없이 설계된다. 따라서 하드웨어의 결함은 심각한 기능 저하를 초래하며, 전체적인 고장을 일으킨다. 다른 한편으로는 IEC 62380과 SN29500에서 정의된 것과 같이 표적 고장률을 예상해 하드웨어 고장을 정량화하는 방법이 있다[2].
소프트웨어의 결함은 전적으로 시스템적인 오류이기 때문에 소프트웨어 고장은 정량화하기가 쉽지 않다[3].

소프트웨어의 결함에 대해 타이밍 보호는 고장 허용 향상에 적합한 안전메커니즘이 된다. 타이밍 보호기능으로 소프트웨어 컴포넌트 무한 루프와 같은 본래 기능의 실행을 방해하는 결함을 방지할 수 있다. 타이밍 보호에서 개발자는 태스크 및 인터럽트루틴의 수행시간과 인터럽트 및 리소스에 의한 차단시간에 대해 시간 예산을 할당할 수 있다. 각 태스크 간, 인러텁트 루틴 간의 시간 간격 역시 모니터링된다(그림 2). 고장이 발생하면 AUTOSAR 운영체제가 고장을 유발한 태스크나 인터럽트 루틴을 중단시켜 추가적인 실행이 되지 않도록 배제할 수 있다. 하지만 이러한 타이밍 보호는 향후 필요한 고장 허용 시스템을 향한 첫걸음일 뿐이다.

고장 허용 시스템에 대한 AUTOSAR 소프트웨어 아키텍처

원칙적으로 하드웨어를 중복으로 장착하면 애플리케이션 또한 복잡해진다. 이는 제어공학의 새로운 도전으로, 중복 컨트롤러가 동시에 활성화될 때 컨트롤러의 안정성을 유지하고 액추에이터를 어떻게 제어하는가와 같은 문제 등이 있다. 네트워크에서 데이터 일관성을 평가하는 것(‘비잔틴 장군 문제’[6])도 필요하다. 시스템 아키텍처 관점에서 이러한 복잡성은 상시 대기 모드를 이용해 줄일 수 있다. 이 경우 두 채널 중 하나만이 특정 시점에 액추에이터를 제어한다. 이 채널에 오류가 발생하면 다른 채널이 즉시 제어권을 가진다. 다음과 같은 이유로 AUTOSAR 베이직 소프트웨어(그림 4)를 이용해 애플리케이션 개발 프로세스를 단순화할 수 있다.

- 재사용: 개발자는 모듈형 안전 콘셉트를 확보하기 위해 앞에서 제시한 AUTOSAR 컴포넌트를 오류 감지 목적으로 재사용할 수 있다.
- 기존 메커니즘 활용: 중복 채널의 소프트웨어를 구현함에 있어서, 다양성과 동질성의 두 가지 철학이 있다.
다양성 측면에서는 양쪽 채널에서로 다른 소프트웨어를 적용한다. 같은 방식의 채널과 동일한 마이크로컨트롤러인 경우에는 같은 소프트웨어를 사용하되 각 채널에 대해 파라미터만을 달리해 적용할 수 있다. 이는 AUTOSAR에서 ECU 베리언트 개발에 사용되는 방법인, Post-Build Selectable 메카니즘을 사용할 수 있다. 동일 타입의 채널을 사용하기 위해서는 동일한 원인에 대한 에러를 검사하는 것이 요구된다[7].

고장 발생 시 다른 채널로 신속히 제어권을 전환하기 위해서는 채널의 상태 정보, 센서와 액추에이터 값이 두 채널 사이에 교환돼야 한다(그림 4). AUTOSAR에서는 두 채널에 대한 베이직 소프트웨어의 설정을 하나의 설정으로 구현하는 것이 가능하다. 개발자는 소프트웨어 컴퍼넌트(SWC) 형태로 채널 전환 애플리케이션을 구현하거나, AUTOSAR의 유연한 BswM(Basic Software Mode Manager)과 EcuM(ECU State Manager)의 설정을 통해 명시적으로 구현할 수 있다. 현재는 각 애플리케이션에 특화된 소프트웨어가 채널 간에 오류 상태를 교환하는 데 이용되고 있지만, 앞으로는 이러한 기능을 수행하는 베이직 소프트웨어를 표준화할 수 있을 것이다.

툴 지원

향후에 가중될 복잡성을 극복하기 위해서는 개발 초기단계부터 효과적이고 종합적인 툴 지원이 필요하다. 엔지니어들이 애플리케이션 개발에 집중할 수 있게 되므로, 시스템 모델에서 중복된 신호의 일관성을 일일이 확인하는 업무와 같은 지루하고 오류가 자주 발생하는 작업에 대한 부담이 줄어들 것이다.

현재에도 AUTOSAR를 사용해 안전 관련 프로젝트를 효율적으로 구현할 수 있다. E/E 시스템에서 고장 허용의 증대가 요구된다면, 마이크로컨트롤러의 고장도 처리할 수 있는 새로운 시스템 아키텍처가 필요할 것이다. 이는 애플리케이션과 베이직 소프트웨어에 대한 새로운 도전이다. 그럼에도 불구하고 AUTOSAR 개발방법론을 이용해 이러한 시스템의 복잡성을 극복할 수 있다. 다양하게 설정가능한 AUTOSAR 베이직 소프트웨어의 설정가능성은 훌륭한 출발점을 제공한다. 관련된 툴로 필요한 중복성을 용이하게 관리할 수 있다.

앞으로 베이직 소프트웨어 및 툴에 의한 지원이 더욱 개선될 것이다. 그러나 고장 허용 시스템을 구현하는 첫 단계로 시스템 아키텍처에 대한 새로운 접근 역시 필요하다.

참고 문헌
[1] Definition of the fault tolerance time interval (FITI) 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