Timing 문제를 검증하고 해결하기 위해서 가장 중요한 것은, 우선 문제가 무엇인지부터 인식하는 것이다. 그리고 그에 맞게 가장 적합한 솔루션을 이용해 문제에 접근해야 현명한 테스트 결과를 얻을 수 있다.

Time Critical Function

Time Critical Function은 특정 시간 내에 처리해야 하는 기능을 말한다. 자동차에서는 안전과 관련된 모든 기능이 Time Critical Function에 해당한다. 만일 지정된 시간 안에 처리하지 못할 경우 탑승자의 안전에 심각한 문제를 야기할 수 있다.

그렇다면 차량에서 Time Critical Function의 수행 시간은 어떻게 고려해야 하는가? 간단히 설명하면, 센서로부터 입력된 신호에 맞게 액추에이터를 최종 제어하기까지 소요된 시간으로 계산해야 한다. 그림 1을 예로 설명하면, 센서로 측정된 신호가 첫 번째 ECU(Electronic Control Unit)에 도착(T1)하고, 처리(T2)가 이뤄진다.

그리고 액추에이터 동작을 위해 다른 ECU에 요청(T3)을 하고, 요청을 받은 ECU는 요청에 대한 처리(T4) 결과에 맞게 액추에이터를 동작(T5)시킨다. 만일 이 모든 과정 중에 하나라도 지연이 발생하면, 요구되는 시간 안에 처리하지 못해 정상적인 수행을 하지 못한다. 액추에이터는 정상 동작을 하더라도 차량은 사고가 발생할 수가 있다.

ISO 26262와
Time Critical Function

ISO 26262 Part 6, 6.4.1 항목에서는 소프트웨어 안전 요구사항에 Time Critical Operation에 대해서 관리하도록 하고 있다. 그리고 이를 측정하는 방법으로 다양한 방안을 제안하고 있다. 센서에서 액추에이터 사이의 제어 과정(Control Flow)을 외부의 장치를 이용하거나, 내부에 별도의 소프트웨어를 이용할 수 있다. 또한 최근 차량용 소프트웨어 검증 방안으로 시뮬레이션 도구를 활용하는 방안이 검토되고 있다. 이 방법을 통해 제어 과정을 분석해 WCET(Worst Case Execution Time)에 해당하는 소프트웨어의 흐름을 관찰할 수 있다. 그리고 예상되는 WCET 소요시간을 측정해 제공한다.

시뮬레이션 환경은 실제 MCU(Micro-control Unit)에서 동작하는 것과 유사한 방식을 제공하기는 하지만, 측정 결과를 살펴보면 오차가 크기 때문에 반드시 통합 과정에서는 실제 MCU에서 측정해야 한다.

특히 ISO 26262 Part 6, 10.4.3 항목에 해당되는 자원의 충분한 허용범위는 실제 MCU에서 측정하지 않으면 검토가 어려운 정보에 해당한다. Table 13의 1c 항목(Fault injection test)과 1d 항목(Resource usage test)는 MCU의 평균/최대 수행 시간, 소프트웨어의 최소/최대 실행 시간을 측정해야 한다. 그러나 이러한 정보는 시뮬레이션 측정으로는 기능상 한계가 있어 측정이 불가능하거나 신뢰할 수 있는 수준의 정보를 제공하지 못한다. 그리고 11.4.2항의 시험환경에서 최종 적합성 검증은 실제 환경에서 이뤄지기 때문에, 예상 결과와 시뮬레이션 결과는 실제 MCU와 실차 환경에서의 시험 결과로 대체된다.

Coarse-grain 측정 방법과
Fine-grain 측정 방법

Timing 측정 방법은 크게 Coarse-grain 측정 방법과 Fine-grain 측정 방법으로 나눌 수 있다.
Coarse-grain 측정 방법은 특정 이벤트 간 또는 특정 기능 간의 시간을 측정하는 방법이다. 지정된 이벤트 또는 기능 사이의 정밀한 정보를 볼 수는 없지만, 전체 시스템의 흐름을 관찰할 수 있다. 이 정보는 차량의 Control Flow를 관찰할 수 있으며, 누적돼 발생하는 Timing 문제나 장기간 측정이 필요한 경우에 활용이 가능하다.

Coarse-grain 방식의 대표적인 방법은 GPIO를 이용하는 것이다. 이는 특정 이벤트 또는 특정 위치의 시간 정보를 확인하기 위해, GPIO를 Toggle하는 Tag Code를 추가해 소프트웨어를 실행하는 방법이다. ECU의 경우에는 GPIO를 활용하기에 적합하지 않을 때 CAN/FlexRay/LIN과 같은 인터페이스를 이용해 정보를 제공하기도 한다.

반면 Fine-grain 측정 방법은 정밀한 측정방법으로 MCU에서 동작하는 소프트웨어의 Instruction의 수행 시간 수준으로 Timing 분석이 가능하다. Instruction 하나하나의 수행 시간을 기록하므로 많은 양의 정보가 기록돼 전체 Control Flow의 흐름을 관찰하는데 어려움이 따른다. 하지만 소프트웨어 단위 코드(함수나 클래스와 같이 비교적 큰 수준이 아니라, Instruction Level 수준의 코드)의 소비시간을 측정할 수 있다. 그리고 MCU 내에 공유 자원 사용에 따른 충돌로 인한 지연과 같이 Coarse-grain으로는 측정이 불가능한 정보를 측정할 수 있다.

Fine-grain 역시 Coarse-grain 방식을 이용할 수 있다. 하지만 매우 정밀한 분석의 경우, Tag Code가 측정 결과에 많은 오차를 발생시킬 수 있다. 보통 Coarse-grain 방식의 경우, 지정된 이벤트나 특정 기능에 대해서만 Tag Code가 추가되므로 평균 1% 내외로 시스템의 자원(CPU 점유율)을 이용하게 된다. 하지만 Fine-grain은 많은 양의 Tag Code를 필요로 하기 때문에 평균 10% 이상의 시스템 자원(CPU 점유율)을 이용하게 되며 코드 크기도 15% 이상 증가하게 된다. 이러한 현상을 제거하기 위해 최근 차량용 MCU는 Trace Logic을 제공해 CPU 점유율 변화나 코드 크기 변화에 영향을 주지 않으면서 정밀한 분석을 가능하게 한다.


AUTOSAR와 소프트웨어 Timing

AUTOSAR Version 4.0에서는 Timing Extension을 통해 5가지의 Timing 분석 측정 방법을 제시하고 있다. VfbTiming은 Virtual Function Bus의 소비시간을 측정할 수 있다. 이 방법을 통해 각 SWC(Software Component)의 인터페이스 간 소비시간 측정이 가능하다. SwcTiming과 BswModuleTiming은 각 SWC와 BSW(Basic Software) 모듈의 소비시간을 측정할 수 있다.

SystemTiming은 소프트웨어에 의해서 소비된 시간뿐만 아니라 통신 과정에서 물리적인 인터페이스에 의해 소비된 시간까지 측정할 수 있는 방안을 제공한다. EcuTiming은 단일 ECU 내에서 모듈과 모듈 간의 소비되는 시간을 측정할 수 있다.

Timing Extension에서 VfbTiming/ SystemTiming/EcuTiming의 경우, Coarse-grain 방식을 적용해 소비시간을 측정하면 효과적이다. 만일, 이 Timing 분석을 위해 Fine-grain 방식을 이용하게 되면, 우리가 원하지 않은 많은 불필요한 정보로 인해 정작 필요한 정보를 찾기 어려울 수 있다. SwcTiming과 BswModuleTiming의 경우, Fine-grain 방식을 적용하는 것이 효율적이다. 이를 활용하면 SWC와 BSW 모듈을 최적화할 수 있다.



실제 적용사례

Fine-grain과 Coarse-grain은 검증하고자 하는 Timing의 종류에 따라서 선택하게 된다. 산발적인 시스템 충돌로 인한 문제해결이나 시스템 최적화가 필요한 경우에는 Fine-grain 방식을 적용하는 것이 좋다. 전체 제어 흐름 분석이나 장기간 시스템의 스트레스 누적으로 인해 발생하는 문제해결에는 Coarse-grain 방식을 적용하는 것이 효과적이다.

첫 번째 사례는 다중 코어 사용으로 인해 동일한 코드의 수행 시간이 지연되는 현상에 대한 문제 검증 사례다. 보통 다중 코어를 사용하는 목적 중 하나는 연산을 여러 개의 코어에 분산시켜 목적에 해당하는 제어의 시간을 최소화하는 것이다. 이렇게 제작된 ECU는 Timing적으로 여유를 갖게 되므로, 문제가 발생할 소지를 줄일 수 있다. 그런데 멀티 코어 사용이 무조건 소프트웨어의 동작 시간을 짧게 만들어주는 것은 아니다. 연산을 얼마나 각 코어에 잘 배분하고, 최종 연산 결과를 잘 정리해 제어를 하느냐에 따라서 결과는 달라진다.

그림 3 예제는 메모리 중복 사용으로 인해 발생하는 문제를 재현한 코드다. 좌측 코드에 표시된 수행 시간은 코어 단독으로 수행된 결과다. 우측은 일부 변수를 두 개의 코어가 공유해 사용한 결과다. 수행 시간이, 변수를 공유함으로 인해 동일한 코어임에도 불구하고 약 30%정도 증가한 것으로 측정된다. 이는 공유된 변수를 두 코어가 동시에 접근해 발생한 충돌로 인해 발생한 지연현상으로, MCU의 자원을 적절하게 배분하면 해결 가능한 문제다. 이러한 문제는 Coarse-grain 방식을 적용할 경우 확인이 불가능하다.

두 번째 사례는 누적된 타이밍 지연으로 인해 발생한 경우의 사례다. 타이밍 지연이 누적돼 Failure 문제까지 발생하려면 어느 정도의 시간이 필요하다. 문제에 따라서는 1~2시간 정도에 발생할 확률도 있지만, 심한 경우에는 하루 이상 걸리기도 한다. Fine-grain 방식은 모든 내용을 담아두고 볼 수 있기에, 이런 타이밍 지연 누적 문제도 확인이 가능하다. 하지만 이것의 원인이 되는 현상을 연결 짓기가 매우 어렵다.

이유는 너무 많은 정보를 저장해두기 때문에 문제를 유출하기 위해 관찰해야 하는 대상이 많기 때문이다. 예를 들어 일반적으로 120 MHz에서 동작하는 MCU가 Trace Logic을 통해 출력하는 정보는 몇 분 이내에 4 Gbytes를 초과한다. 만일 1시간 관찰한다면 3-40 Gbytes의 데이터를 관찰해야 하는 경우가 발생한다. 물론 문제에 대한 정보를 담고는 있지만 해당 내용을 모두 파악하는 것은 불가능에 가까운 일이다.

그림 4는 Coarse-grain 방식을 이용해 Timing 관련 문제를 검토한 사례다. 두 번째에 나열된 정보는 일정 시간마다 TASK가 Activation되면 하나의 바가 출력된다. 정상적인 Control Flow라면 이는 정상적으로 출력돼야 한다. 하지만 표시된 위치에서 단 1회 TASK가 Activation되지 않는 현상이 발생한다.

이 문제는 Control Flow 과정에 타이밍 지연이 누적된 결과가 TASK Activation을 방해하는 현상으로 발생하게 된 것이다. 이러한 문제는 특정 시간 내에 발생하는 것이 아니라 여러 요인이 장시간 관여하며 발생하는 현상으로, Fine-grain으로 검토하기 어려운 문제에 해당한다.

결론

차량용 소프트웨어의 Timing 문제는 다양한 원인에 영향을 받아 발생한다. 특히 Timing 문제는 그 원인이 다양한 형태로 발생하게 된다. 코딩의 문제는 그 패턴이 대부분 정해져 있어 하나의 방식으로 대부분의 문제를 검토할 수 있다. 하지만 Timing 문제는 코드 자체의 영향, 데이터 사용 시 발생하는 영향, MCU 내부의 지연, 통신 지연 등 매우 다양한 형태다. 이러한 다양한 문제를 단 한 가지 방법으로 접근하는 것은 문제해결을 지연시킬 뿐이다.

Fine-grain 방식은 모든 정보를 저장할 수 있기에, 문제의 원인도 모두 기록할 수 있다. 하지만 많은 정보를 제공하는 것이 문제를 모두 해결해 줄 수 있음을 의미하지는 않는다. 문제해결에 필요한 정보를 주는 것과 모든 정보를 담고 있는 것은 다른 것이기 때문이다. 그렇기 때문에 Timing 문제를 검증하고 해결하기 위해서 가장 중요한 것은, 우선 문제가 무엇인지부터 인식하는 것이다. 그리고 그에 맞게 가장 적합한 솔루션을 이용해 문제에 접근해야 현명한 테스트 결과를 얻을 수 있다.