ISO 26262 FFI 요구사항 검증 방안

자동차 소프트웨어를 개발 출시할 때는 자사에서 공급하는 소프트웨어가 ISO 26262에서 요구하는 Freedom From Interference의 항목을 준수하는지 증명해야 한다. 이 글에서는 ISO 26262에서 요구하는 FFI에 대해 살펴보고, 자동차 소프트웨어 개발자들이 이에 대응할 방안에 대해 살펴본다.

글 | 김지은 FAE_jieun.kim94@hancomit.com, 한컴인텔리전스 커넥티비티사업부 ADS팀

 





하나의 소프트웨어에 기능안전성, 보안, AUTOSAR 등 다양한 요소들이 결합되면서 자동차 소프트웨어의 구조는 점점 복잡해지고 있다. 특히, 반도체의 집적도가 증가하면서 하나의 제어기(ECU)에 다양한 기능들이 통합되고, 하나의 제어기를 여러 팀이나 회사가 모듈별로 협업해 개발하는 경우가 증가하게 됐다. 이와 동시에 발생하는 문제는, 하나의 제어기에 서로 다른 안전 등급(ASIL)의 모듈들이 상호 간섭할 수 있는 가능성이 증가된다는 점이다. 이런 간섭은 제어기의 비정상적인 (또는 의도하지 않은) 동작을 야기해 자동차 기능안전성 표준인 ISO 26262에는 소프트웨어 간 상호 간섭 현상을 막는 항목 (ISO 26262 Part 6 7.4.11, Part 9)을 규정하고 있으며 이를 Freedom From Interference(FFI)라는 용어로 정해 관리를 요구하고 있다. 즉, 자동차 소프트웨어를 개발해 출시할 때는 자사에서 공급하는 소프트웨어가 ISO 26262에서 요구하는 FFI의 항목을 준수하는지 증명해야 하는 상황이다. 

이 글에서는 ISO 26262에서 요구하는 FFI에 대해 살펴보고, 자동차 소프트웨어 개발자들이 이에 대응할 수 있는 방안에 대해 살펴보고자 한다.



Fail Safe의 의미 

자동차, 항공기, 무기체계 등 흔히 Safety Critical 분야로 구분되는 시스템에서 Fail Safe 개념은 매우 중요하다. 도미노 효과를 예로 들면, 도미노에서 하나의 칩이 무너지기 시작하면 다른 칩들도 무너진다. 이와 마찬가지로, 안전이 중요한 시스템에서 한 시스템의 결함이 이와 연결돼 있는 다른 시스템의 결함으로 확산될 수 있다는 것이다. Fail Safe는 한 시스템에서 결함이 일어나도 다른 시스템이 영향을 받지 않고 정상적으로 동작하는 것을 말한다. 기능안전성 표준인 ISO 26262에서는 Fail Safe를 보장하기 위한 방법으로 시스템의 오작동에 따른 위험에 따라 시스템 또는 서브 시스템들을 ASIL(Automotive Safety Integrity Level) 등급으로 구분하고 서로 간섭하지 못하도록 규정하고 있다. 

ISO 26262에서 규정하는 ASIL은 QM, ASIL-A, ASIL-B, ASIL-C, ASIL-D 등급이 있다. QM 등급은 안전에 치명적이지 않은 Non-Safety 등급을 의미하고, ASIL-D 등급은 가장 높은 안전을 요구하는 등급이다. 이때, QM 등급을 가진 소프트웨어 모듈(컴포넌트, 아이템 등)이 안전에 치명적인 ASIL-D의 소프트웨어 모듈에 영향을 주거나 간섭하는 일이 없도록 해야 한다. 그렇게 해야 한 시스템의 결함이 다른 시스템에도 영향을 주는 도미노 현상이 발생하지 않기 때문이다.



ISO26262 7.4.11: Freedom From Interference

ISO 26262-6의 7.4.11절의 내용 중 일부분을 살펴보면 다음과 같다.


임베디드 시스템이 서로 다른 ASIL 등급을 가진 소프트웨어 컴포넌트(Components)들로 구성되어 있을 때, 준수해야 하는 항목은 다음과 같다. 
7.4.11 소프트웨어 분할(부속서 D 참조)이 소프트웨어 컴포넌트 사이의 간섭이 없도록(Freedom From Interference) 구현하는데 사용된다면 다음의 사항을 보장해야 한다.
a) 소프트웨어 분할(Partition)이 컴포넌트 간 간섭이 없음을 보장하는 방식으로 공유된 자원이 사용됐다.
... (중간 생략) ... 
c) 소프트웨어 분할을 구현하는 소프트웨어 부분은 소프트웨어 파티션의 요구사항에 할당된 최고 ASIL과 같거나 보다 상위의 ASIL에 부합하도록 개발된다.
(출처: ISO 26262-6:2018 7.4.11)


ISO 26262에서는 모듈 간 상호 간섭이 일어나서는 안 된다고 규정하며, 이를 Freedom From Interference라고 한다. 예를 들어 QM 등급의 컴포넌트가 있고, ASIL-D 등급의 컴포넌트가 있을 때, 이 둘 사이의 Read/Write/Execute(Call)을 하는 코드가 있다면, 서로 다른 등급의 파티션 사이에서 간섭(Interference)이 일어나고 있는 것이다.  




그림 2에서는 QM등급인 SW-C1이 ASIL-D 등급인 SW-C2의 변수에 값을 쓰고 있다(Write). 이와 같은 소스코드가 있다면, 해당 소프트웨어 모듈은 ISO 26262의 FFI 항목을 위배하고 있는 것이다. 
ISO 26262를 준수하려고 하다 보면 자칫 비용의 증가가 발생할 수 있다. ISO 26262-6 7.4.11의 c 항목 규정대로라면 ASIL-D 등급의 시스템을 개발할 때 해당 시스템을 구성하는 소프트웨어 모듈 중 하나라도 ASIL-D 등급을 요구할 경우, 해당 시스템을 구현하는 나머지 모듈도 ASIL-D 등급을 따라야 한다. 이렇게 표준을 준수하려다 보면 ASIL-D 등급일 필요가 없는 부분도 ASIL-D 등급을 따라야 하기 때문에 비용의 증가가 동반될 수 있다. 







그림 3에는 한 시스템을 구성하는 4개의 소프트웨어 모듈이 있다. 한 시스템을 구성하는 모든 모듈들은 ISO 26262-6 7.4.11의 c 항목을 준수해야 하기 때문에 시스템에 할당된 최고 ASIL 등급을 가져야 한다. 이렇게 될 경우, 파티션을 구성하는 몇몇 모듈은 ASIL-D 등급일 필요가 없음에도 불구하고, ISO 26262의 규정대로 ASIL-D 등급이어야 한다. 

이렇게 ISO 26262-6 7.4.11의 c 항목 때문에 모든 컴포넌트들이 ASIL-D 등급이어야 한다는 점은 비용의 증가를 초래할 수 있다. 이와 관련해, AUTOSAR와 ISO 26262에서는 일종의 유연한 구조를 제공한다.




AUTOSAR의 해결책: 메모리 분할(Memory Partitioning)

도미노를 쌓을 때, 하나의 칩이 모든 칩을 무너뜨리게 되는 상황에 대비해 중간에 칸막이를 두거나 여유 공간을 두기도 한다. AUTOSAR도 이런 방식을 적용한다. 서로 다른 등급을 가진 모듈들이 상호 간 간섭하지 않도록 하기 위해 ‘메모리를 분할’하는 방식을 적용하며, 이를 파티션(Partition)이라고 한다. 





그림 4는 AUTOSAR 공식 문서에 있는 이미지를 통해 파티션을 구분한 예를 보여주고 있다. AUTOSAR의 애플리케이션 소프트웨어(ASW) 단은 여러 개의 소프트웨어 컴포넌트(SW-C)로 이루어져 있는데, 이 컴포넌트들을 여러 ASIL 등급을 가진 파티션으로 구분하도록 한다. 구분하는 것뿐만 아니라, 메모리 간 분할 후 각 파티션 간의 간섭이 없음을 보장 및 증명해야 하는데, 이 부분을 규정한 부분이 바로 ISO 26262-6 7.4.11의 a 항목이다. 



메모리 간섭을 방지하기 위해 현존하는 방식과 한계점

1. AUTOSAR 메모리 분할 방식과 한계점  
AUTOSAR를 이루는 여러 계층 중 애플리케이션 소프트웨어(ASW) 층은 여러 개의 소프트웨어 컴포넌트(SW-C)로 이루어져 있으며, 컴포넌트는 다시 변수와 함수들로 구성되어 있다. 이때 컴포넌트들을 구성하는 함수는 반드시 OS 애플리케이션 중 하나인 태스크(Task)에 할당되어 동작해야 한다. AUTOSAR에서 OS 애플리케이션은 반드시 구분된 메모리 영역에만 배치되어야 하는 것을 의무화하고 있으며 서로 다른 메모리 분할(Partition)에 접근할 수 없다. SW-C도 반드시 하나의 OS 애플리케이션에 할당되어야 한다. 이런 이유 때문에, 서로 다른 메모리 영역에 있는 OS 애플리케이션과 SW-C 간의 간섭은 방지가 된다. 하지만 AUTOSAR의 메모리 분할 방식에는 한계점이 있다. 바로, 한 소프트웨어 컴포넌트 내에서 서로 다른 등급을 가진 함수가 있는 경우 태스크(Task) 간의 간섭을 방지하는 것에 대해서는 의무화하지 않는다는 것이다. 

2. MPU(Memory Protection Unit)의 사용과 한계점 
서로 다른 등급을 가진 소프트웨어 컴포넌트 간 메모리 간섭이 있는지 검증하기 위해 MPU(Memory Protection Unit)를 사용하는 방법이 있다. MPU는 메모리 상의 간섭이 발견될 경우, 하드웨어 타깃이 동작 중에 트랩에 빠지도록 한다. 그러나, MPU는 런타임 중에 간섭을 발견하는 방식이라는 이유 때문에 다음과 같은 한계점이 있다. 
MPU 트랩이 발생하면 디버깅을 해야 하는데, 이는 많은 시간이 소요되는 점진적인 검증 (Incremental verification)이다. 개발자는 빌드한 후 타깃을 실행하고, 동작 중에 MPU가 트랩을 발생시키면 디버깅을 해야 한다. 버그를 수정한 후에는 다시 빌드부터 하는 작업을 반복하게 되는데, 이는 많은 시간을 요구하는 작업이다.


이와 같이, ISO 26262-6 7.4.11의 FFI 항목을 준수하기 위해 AUTOSAR에는 메모리 분할 방식과 MPU 방식이 있다. 그러나 이 방식들은 각각의 한계점을 가지고 있기 때문에 이를 보완할 수 있는 방안 마련이 필요하다. 



현존하는 메모리 간섭 검증 방식의 한계점을 극복하기 위한 해결방안
자동차 제어기를 개발할 때, 기본적으로 사용되는 TASKING 컴파일러와 연계해 사용되는 Safety Checker는 정적으로 파티션 간 접근을 확인한다. 그림 6을 보면 서로 다른 등급의 파티션(ASIL-D, QM)을 정의한 후, 각 파티션 간의 Read, Write, Execute(R|W|X) 접근 권한을 부여하는 설정을 보여주고 있다. 

그 다음 단계에서는 소스 코드 모듈들을 해당 파티션에 할당하는 방식으로 간섭 여부를 검증한다. 이는 소스코드를 정적으로 검증하기 때문에 모든 간섭 코드를 검증할 수 있어 기존 방식의 한계점을 보완할 수 있다.





하나의 소프트웨어 안에도 그 프로그램을 이루는 수많은 소스코드 파일과 함수, 변수들이 있고, 각 코드들의 ASIL 등급을 관리하기에는 큰 어려움이 따를 수 있다. Safety Checker에서는 코드들에 기능안전성 등급을 손쉽게 정의하고, 간섭 결과를 리포트로 만들어 소프트웨어 개발자들이 편리하게 소프트웨어 모듈간 간섭 여부를 관리할 수 있도록 한다. 






자동차 소프트웨어의 구조는 점점 복잡해지고 다양해지고 있다. 이로 인해, 서로 다른 모듈의 영역을 간섭할 가능성이 커졌고, Fail Safe를 보장하지 못하는 상황이 발생할 수 있게 됐다. 이를 방지하기 위해 ISO 26262에서 FFI 항목을 만들었으나 모든 모듈 간의 간섭을 검증할 수 없는 물리적인 한계점은 분명히 존재한다. 이런 한계를 극복하기 위한 솔루션들도 다양해지고 있으며, 이를 통해 자동차 소프트웨어 개발자들은 다양한 기능을 안전하게 개발할 수 있게 됐다. 자동차 플랫폼을 구성하는 각각의 모듈 혹은 그 안의 함수 및 변수 등의 등급을 정확히 관리하고 간섭을 검증할 수 있을 때, 자동차 SW의 안정성은 확보될 수 있다. 

---