차량용 SW 타이밍 요구사항과 대응 방안

글│김 현 용 대리 _ hyunyong@mdstec.com, MDS테크놀로지
2017년 05월호 지면기사

OEM의 타이밍 요구사항 관리 현황
 

 최근 차량용 SW는 복잡도가 점점 증가해 성능에 대한 관리가 반드시 필요하다. 간단한 예로, 멀티코어 SW의 경우 각 코어별 자원 사용량을 파악해야만 코어 간 로드 밸런싱을 할 수 있다. 만약 이러한 관리가 이루어지지 않으면 Overload(CPU 사용량이 100%가 넘어가는 상황)가 발생하고 SW에 치명적인 문제를 유발할 수 있다. 국내외 주요 OEM에서는 SW 타이밍과 관련된 요구사항 항목들을 별도로 관리하고 각 요구사항을 만족시키기 위해 많은 노력을 기울이고 있다. 
 

앞서 말한 주요 타이밍 요구사항의 항목으로는 CPU 사용량, SW의 WorstCase 수행시간 등이 있다. 실제로 이러한 항목들은 자동차 기능 안전성 국제 표준인 ISO 26262나 전장 SW 국제 표준인 AUTOSAR에서 반드시 만족해야 하는 필수항목으로 관리되고 있다.

 

CPU 사용량 측정 기준 및 방법

 

일반적으로 타이밍 요구사항 문서에서 “CPU 사용량 측정” 항목은 항상 포함되어 있다. 하지만 CPU 사용량을 어떤 기준과 방법으로 측정해야 할지에 대한 내용이 없는 경우가 대부분이다. 지금부터 이에 대한 정의와 측정 방법에 대해 알아보겠다. 

먼저, CPU 사용량이란 Processor Idle 시간을 제외한 나머지 수행시간을 백분율(%)로 나타내는 것을 의미한다. 이를 수식으로 표현하면 아래와 같다.

 

CPU 사용량(U) = 수행시간(To)/Duration(Te) *100

 

위 식에서 가장 중요한 것은 Duration 시간(To)의 기준이다. To의 값에 따라서 CPU 사용량의 측정 결과가 달라질 수 있다. To의 값을 선정하는 기준은 “CPU Reset 이후 측정한 전체 수행시간”과 “특정 시간 주기” 2가지로 구분한다. 

CPU Reset 이후 측정한 전체 수행시간을 기준(To)으로 잡는 경우, Idle의 시간을 측정하여 수행시간(Te)에 반영한다. 이렇게 계산된 수치를 100%에서 빼면 CPU 사용량이 된다. 이 방식은 오랫동안 측정할수록 더욱 정확한 사용량을 파악할 수 있고, 평균 CPU 사용량을 매우 쉽게 측정할 수 있다. 하지만 WorstCase에 대한 CPU 사용량을 측정할 수 없다. 

특정 시간 주기로 기준(To)을 잡는 경우, 주기 내의 수행시간(Te)을 측정하여 반영한다. CPU 사용량은 각 주기마다 계산되기 때문에 BestCase, WorstCase, 평균 CPU 사용량을 측정할 수 있다. 하지만 각 주기마다 측정된 CPU 사용량의 정보를 모두 저장하기 위한 별도의 버퍼가 필요하다. 
 

위 2가지 방법 중 정확한 CPU 사용량을 관리할 수 있는 방법은 특정 시간 주기로 기준(To)을 잡는 것이다. 예를 들어 1 ms, 2 ms, 5 ms, 10 ms TASK가 있다고 가정하자. 이 때 TASK들의 Activation Event는 10 ms마다 동일한 Timing layout을 보이게 된다. 만약 CPU Reset 이후 측정을 멈춘 시점이 8 ms라면 이후 2 ms 동안 1 ms, 2 ms TASK에 대한 수행시간이 누락된다. 하지만 10 ms를 기준으로 잡고 CPU 사용량을 계산하면 누락된 수행시간 없이 정확한 결과를 볼 수 있다. 

즉 요구사항 항목 중 “CPU 사용량 측정”은 측정 기준 또는 방식에 따라 완전히 다른 결과가 나온다. 그렇기 때문에 국내외 주요 OEM들은 타이밍 요구사항 명세서에 CPU 사용량 측정 기준과 방법을 정확히 제시하거나, 결과 리포트 내용에 측정 방식을 반드시 명시하도록 관리하고 있다.

 

WorstCase 수행시간 측정 기준

 

타이밍 요구사항 문서에 기본적으로 포함되는 내용 중 또 다른 항목으로는 “모든 TASK/Interrupt의 WorstCase 수행시간”이 있다. 먼저 WorstCase가 아닌 일반적인 TASK/Interrupt의 수행시간 측정 방법에 대해서 알아본다. 

기존 수행시간의 측정 방법은 측정하고자 하는 대상의 시작과 끝에 탐침 코드를 넣어 오실로스코프로 측정해왔다. 하지만 이러한 측정 방식은 OEM에서 요구하는 수행시간을 측정한 것이 될 수 없다. OEM에서 리포트를 요구하는 수행시간은 그림 1의 C항목에 명시된 바와 같이 CET(Core Execution Time)를 의미한다. CET는 우선순위가 높은 다른 TASK나 Interrupt에 의해 선점된 시간을 제외한 순수한 자기 자신의 수행시간이다.

 

OS가 있는 시스템에서 TASK의 수행시간은 “스케줄러에서 Start 이벤트가 발생하는 시점”부터 “Stop 이벤트가 발생하는 시점”까지가 된다. 오실로스코프를 이용해 수행시간을 측정하는 방식은 다른 우선순위 높은 TASK나 Interrupt에 의해 선점된 시간까지 포함하고 있다. 그리고 TASK나 Interrupt 내부에 이미 진입한 Entry부터 Exit까지만 측정을 하기 때문에 스케줄러 관점에서 보면 정확한 수행시간이 아니다.

 

그렇기 때문에 오실로스코프를 이용한 측정 방식은 OEM의 요구사항을 만족시킬 수 없다. 그림 3에서 Timing Parameters 용어 중 오실로스코프를 이용한 측정 방식은 GET(Gross Execution Time)에 대한 측정임을 확인할 수 있다. 

이 외에도 다양한 Timing Parameters의 용어들이 있으며 SW의 ASIL(Automotive Safety Integrity Level) 등급에 따라 RT(Response Time), ST(Slack Time) 등에 대한 측정이 추가 요구사항으로 관리되기도 한다. 
 

그렇다면 WorstCase 수행시간(이하 WCET)이란 무엇일까? 말 그대로 최악 조건 상황이 발생했을 때의 CET를 의미한다. WCET를

측정하기 위해서는 다양한 WorstCase 시나리오가 ECU에 주입된 상황을 포함한 모든 시점들에 대한 수행시간을 실시간으로 측정할 수 있어야 한다.

 

타이밍 측정 요구사항 대응 위한 고려사항

 

지금까지 언급한 내용은 OEM 타이밍 요구사항에 대응하기 위한 정확한 측정 기준과 방법이다. 하지만 우리가 필수적으로 고려해야 할 사항이 몇 가지 있다.

 

측정 솔루션에 대한 신뢰성과 단일화

 

우리가 측정해온 솔루션이 과연 OEM 입장에서 신뢰할 수 있는지에 대한 것은 또 다른 문제이다. 예를 들어, Supplier에서 측정한 솔루션이 검증되지 않은 방식일 경우 OEM에서는 이를 신뢰할만한 근거가 별도로 필요하게 된다. 또한 Supplier와 OEM이 다른 측정 방법을 가지고 결과 리포트를 하면 수치에 대한 정확성이 떨어질 수 있다.

 

그렇기 때문에 Supplier에서 타이밍 측정 시 사용한 솔루션이 ISO 26262와 같은 표준에 대한 인증을 받았는지 확인을 해야 한다. 그리고 OEM에서도 Supplier와 동일한 측정 솔루션을 사용하여 SW 성능을 검증해야만 신뢰성 있고 일관성 있는 결과를 얻을 수 있다.

 

실차 환경에서의 타이밍 측정

보통 타이밍 요구사항에 대응하기 위해서는 시험실 환경뿐만 아니라 실차 환경에서도 타이밍 측정이 필요하다. 시험실에서는 단일 ECU를 대상으로 테스트를 하기 때문에 성능 측정을 하기 위해 오실로스코프, HW 기반 Trace 장비 등 다양한 솔루션이 있다. 하지만 이러한 솔루션들을 실차 환경에서도 동일하게 사용하기에는 Pinout 등의 문제로 많은 제약들이 있다.

 

만약 시험실과 실차 환경에서 동일하지 않은 솔루션을 이용한 타이밍을 측정하게 되면 역시나 일관성이 없는 결과를 얻게 된다. 즉 모든 환경에서 동일한 측정 솔루션을 사용할 수 있어야 한다. 대표적으로 차량용 표준 통신 프로토콜 중 하나인 CAN Interface를 이용하는 것이 될 수 있다. CAN Interface는 시험실과 실차 환경 모두에서 사용할 수 있기 때문에 좋은 솔루션 중 하나로 볼 수 있다.

 

다양한 타이밍 요구사항에 대응 가능

OEM 타이밍 요구사항에 대응하다 보면 측정이 필요한 항목들이 추가되는 경우도 있다. 예를 들어 기존에는 모든 TASK/Interrupt에 대한 WCET만 측정을 하다가 WCRT(WorstCase Response Time)도 추가 측정이 필요할 수 있다. 또는 Runnable 수행시간 측정, CAN 메시지 송수신 간 Latency 측정 등 다양한 요구사항이 있을 수 있다. 이러한 요구사항들을 각각 다른 방법을 이용하여 측정하게 된다면 측정 결과에 대한 신뢰성이 떨어질 수밖에 없다.

 

측정 솔루션의 Overhead에 대한 고려 

SW 방식의 타이밍 측정 솔루션은 코드를 삽입하는 방식을 이용한다. 이 경우 제어기가 동작되기 위한 SW 이외에 타이밍 측정을 위한 별도의 SW가 동작하는 것이다. 이는 제어기 입장에서 Overhead가 될 수 있다. CPU 성능에 대한 영향을 최소한으로 줄이기 위해서는 Overhead를 최소화 하는 것이 필요하다. 그리고 정확한 CPU 사용량과 WCET 측정을 위해서는 이 Overhead 수치가 얼마나 되는지를 알 수 있어야 한다. 즉 타이밍 요구사항에 대한 리포트를 할 때 Overhead 수치에 대해 명시함으로써 측정 결과물에 대한 정확한 판단을 할 수 있도록 고려해야 한다.

 

타이밍 위반사항 디버깅

타이밍 요구사항의 항목들은 결국 SW가 지정된 시간 내에 정상적으로 수행이 되는지, 그리고 안전하게 동작하기 위한 여유가 있는지를 파악하기 위함이다. 만약 요구사항의 Deadline 기준에 부합하지 않는 결과물이 있다면, 이에 대한 원인을 찾을 수 있어야 한다. 이를 타이밍 위반사항이라 한다. 대표적인 예로, SW 검증 테스트를 하다 보면 주기적으로 동작을 하고 있는 TASK가 일부 누락되는 케이스가 간헐적으로 발생한다.

 

일반적으로 이 누락되는 상황을 정확히 찾아 디버깅 하기는 매우 어렵다. JTAG 인터페이스를 이용한 디버거를 사용할 경우 타깃을 멈추는 방식으로 SW 수행여부를 관찰하기 때문에 어느 시점에 위반사항이 발생했는지를 알 수 없다. NEXUS나 AGBT 같은 Trace 인터페이스를 이용한 HW Trace 장비를 사용할 경우, Code Flow 정보를 수집하여 관찰할 수 있으나 Trace Buffer 사이즈가 정해져 있기 때문에 모든 정보를 수집할 수는 없다. 즉 타이밍 위반사항이 발생한 시점에 대한 정보가 Trace Buffer 내에 없다면 디버깅 하는 것이 불가능하다. 결국 타이밍 위반사항이 발생한 시점을 정확히 인지하여 원인을 파악하고 디버깅 할 수 있는 솔루션을 사용할 수 있어야 한다.


결론

 

국내외 OEM에서는 타이밍 요구사항을 점점 엄격하게 관리하는 추세이다. 특히 성능과 관련된 항목들은 차량용 SW의 결함과 직결되는 내용이기 때문에 OEM에서 가장 관심 있는 항목 중 하나이다. 사실 기존 싱글코어나 펌웨어 환경에서의 개발은 SW의 구조가 단순했기 때문에 Code Flow 정보나 수행시간 등을 측정할 때 큰 어려움 없이 가능했다. 하지만 멀티코어와 AUTOSAR의 도입으로 인해 개발자가 Code Flow를 예상할 수 없는 수준이 됐고, 수행시간 측정 시 코어 간 동기화 문제 등 고려해야 할 사항들이 점점 많아지고 있다.

 

기존 타이밍 측정 방식으로는 이러한 요구사항들을 모두 만족시킬 수 없는 상황까지 오게 된 것이다. 즉 앞으로는 OEM과 Supplier 모두 공통된 타이밍 솔루션을 사용함으로써 측정에 대한 기준과 방법을 단일화하고, 측정 결과에 대한 커뮤니케이션 과정에서 문제가 없도록 해야 한다.

<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>

PDF 원문보기

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)

  • 100자평 쓰기
  • 로그인


TOP