Evolving Automotive Software Timing Requirements and Solutions in Line with Development Trends
개발 트렌드 따라 진화하는 자동차 SW 타이밍 요구사항과 솔루션

소프트웨어 정의 자동차, 자율주행, 조널 아키텍처와 같은 새로운 개발 트렌드로 지난 몇 년과는 전혀 다른 방향으로 자동차 소프트웨어 설계가 진행되고 있고, 이에 따른 소프트웨어 검증 이슈, 체계적인 소프트웨어 설계의 필요성이 크게 증가했다. 아이티브AI의 노영규 과장이 AUTOSAR 표준, RTOS 환경에서 여전히 중요하고 심각한 타이밍 이슈에 대해 말한다.  

글 | 노영규 과장, 아이티브AI youngkyu@itivai.com 
       노 과장은 아이티브AI에서 GLIWA의 T1이라는 자원 사용량 검증 솔루션을 제공 및 지원하고 있다. 







2019년을 마지막으로 팬데믹으로 잠정 중단됐던 GLIWA의 Distributor 워크숍이 올해 4월 재개됐다.
 
독일에서 개최된 ‘Embedded World 전시회’ 직후 진행된 이 워크숍에 아시아에서는 한국(아이티브AI)과 중국(Siener)이 참석했다. 워크숍을 통해, 현재 국내에서 크게 화두가 되고 있는 소프트웨어 자원 사용량에 대한 글로벌 검증 트렌드를 확인하고 싶었다. 
SDV(Software Defined Vehicle), 조널(Zonal) 아키텍처와 같은 새로운 개발 트렌드로 인해 지난 몇 년과는 전혀 다른 방향으로 소프트웨어 설계가 진행되고 있고, 이에 따른 소프트웨어 검증 이슈와 체계적인 소프트웨어 설계의 필요성도 증가하고 있다. GLIWA와의 만남을 통해 여러 주제에 관한 얘기를 나눌 수 있었고, 그동안 갖고 있던 생각과 사실관계 확인도 할 수 있었다.






AUTOSAR와
자동차 SW의 흔한 타이밍 이슈 

AUTOSAR는 2003년부터 지금까지 개정을 거듭하며 발전해 왔다. 이와 함께 많은 국내외 OEM은 이 AUTOSAR 표준을 참고해 소프트웨어 요구사항을 관리하고 있다. 

하지만 현재 버전이 완전한 것은 아니다. 실제로 AUTOSAR 기반 소프트웨어 개발자들 이야기를 들어보면 여전히 비효율적인 기준이 존재한다. 우리는 소프트웨어 타이밍 관점에서 이 내용을 확인할 수 있었다.

한 예로, 빈번하게 발생하는 RTE(Run-Time Environment) call로 인한 시스템 과부하가 있다. 인터럽트를 활성화/비활성화하는 RTE call로 인한 부하가 전체 CPU 부하 중 30%를 차지하면서 시스템 과부하의 원인이 됐다. 또 인터럽트 관련 call이 자주 발생했던 이유는 태스크 간 선점에서 데이터의 일관성을 유지하기 위해서다. 태스크 간 CPU 선점이 일어나면 데이터가 손실되지 않도록 다른 공간에 복사해 둔다. 이 과정에서 인터럽트를 활성화/비활성화하며 빈번하게 RTE call이 일어났던 것이다. 
이 문제를 해결하는 방법은 생각보다 단순했다. 바로 태스크 간 우선순위를 동일하게 설정해 CPU 선점을 최소화할 수 있다. 태스크 우선순위가 같을 땐 선점하려는 동작 없이 작업이 종료된 후 다음 태스크가 동작하기 때문이다.

두 번째 예는 AUTOSAR가 적용된 OS configurator에서 태스크를 생성할 때 발생하는 문제다. 요구사항에 따라 태스크를 설정해 생성하면 ECC(Extended Conformance Class) 태스크로 생성되기도 한다. 문제는 ECC Task로 설정하면 불필요한 복잡성이 증가하고 위험 감지에 취약하다는 것이다. ECC 태스크로 구현 시 특정 이벤트를 받아야만 동작하며, 각기 다른 주기의 기능이 하나의 태스크에 포함되기도 한다. 이 경우, 제시간에 기능이 동작하지 못해 시스템 혹은 안전 사항에 문제가 발생할 수 있다. 이를 미연에 방지하기 위해 우리는 ECC 태스크 사용을 지양하고, 가능한 단순하게(하나의 태스크에는 동일한 주기의 기능이 포함되도록) 설정하는 것을 권장하고 있다.

앞서 말한 두 가지 예는 사용자가 의도하지는 않았지만, 잠재적으로 발생할 수 있는 문제다.
AUTOSAR가 생긴 이래로 20년간 시행착오를 통해 소프트웨어 개발 수준은 많이 올라갔지만 비슷하거나 혹은 더 심각한 타이밍 이슈는 계속해서 발생한다. 

이번 워크숍에 참석하기 전까지 이런 이슈는 한국에만 존재한다고 생각했지만, 실제로 이것은 전 세계적인 이슈였고, 모두가 이를 최적화하기 위한 노력을 하고 있었다. 현재 개발자들은 우리와 같은 타이밍 전문가를 통해 컨설팅을 받거나 솔루션을 제공 받아 문제를 해결하고 있지만, 자동차 소프트웨어를 개발하는 조직마다 타이밍 전문가를 양성하는 것이 중요하다.






AP+MCU 동기화 세계(World)        

자율주행과 더불어 차량 기능이 고도화되면서 AP(Application Processor)와 MCU(Micro Controller Unit)가 통합된 환경의 소프트웨어 개발이 이뤄지고 있다. 

현재의 ECU는 조향, 엔진 장치 등을 제어하는 단순한 하나의 동작만 하는 것이 아니라 도로 또는 외부의 상황에 맞게 판단하고 제어하며 AP와 MCU가 유기적으로 화합해 동작한다. 그렇기 때문에 통합된 ECU 환경의 소프트웨어 동작을 관찰하고자 하는 요구가 있었다. 
GLIWA 워크숍에서는 신규 버전의 제품 공개를 통해 통합 ECU 환경의 타이밍 측정을 선보였다. 실시간으로 AP, MCU에서 동작하는 태스크, 인터럽트의 실행 시간과 CPU 부하율을 관찰할 수 있었고, 동기화된 시점의 소프트웨어 Flow를 확인할 수 있었다. 
예는 다음과 같다. 자율주행 중 도로에 동물과 같은 장애물이 튀어나오면 차량은 이를 인식하고 피해 간다. 

이 과정에 대해 ECU 기능을 예로 들어 좀 더 자세히 이야기하면:
 
1) 카메라와 이미지 센서를 통해 이미지를 인식하고(AP), 
2) 장애물 여부, 좌우 이동 판단 등을 계산한다(AP). 
3) 이 정보를 통해 MCU로 명령을 전달하고(AP) 
4) 조향장치에 입력할 값을 계산한다(MCU). 
5) 조향장치를 제어하고(MCU) 장치의 상태를 확인한다(MCU). 
6) 그리고 현재 조향장치 각도를 관찰한다(MCU, AP).






여기서 이미지 센싱과 장애물 감지의 역할은 AP에서 담당했고, 조향각을 계산하고 제어하는 역할은 MCU가 담당했다. 이처럼 각 제어기가 갖는 능력치가 서로 다르기 때문에 하는 역할 또한 다르다.

AP 환경에서의 타이밍 측정은 RTOS가 제공하는 경우가 있고, 기존에도 비슷한 기능을 가진 툴이 있었다. 그러나 AP와 MCU가 동기화된 시점의 소프트웨어 동작을 관찰하는 도구는 없었다. 
하지만 GLIWA에서 해당 기능의 출시를 통해 독립적으로 존재하던 세계를 하나로 합쳤다. 각 제어기(AP, MCU)의 기능과 이벤트에 대해 시각적으로 보여주며 이벤트와 이벤트 사이의 관계를 직관적으로 파악할 수 있게 됐다. 개발자들은 이 기능을 소프트웨어 설계와 개발된 소프트웨어를 검증하는 데 활용할 수 있어야 한다. 개발 초기 단계부터 소프트웨어의 타이밍 검증을 통해 기능의 동작과 부하를 확인해야 한다. 특히나 통합 ECU 환경에서는 각각 제어기의 역할이 다르고, 이벤트가 어떤 시퀀스로 처리되는지가 중요하기 때문에 시각적으로 확인하며 분석해야 한다. 


소프트웨어 타이밍 검증과 역할      

통합 ECU가 적용되기 시작한 지 이미 몇 해가 됐고 자동차 소프트웨어 개발 속도, 트렌드도 빠르게 변하고 있다. 선두 주자가 있고 후발 주자가 이를 따라가는 움직임을 보인다. 물론 신기술 개발도 중요하고 개발 일정을 맞추는 것도 중요하다. 8년간 이 분야에 몸담으면서 자동차 소프트웨어를 검증하는 궁극적인 목표가 무엇인지 자주 생각한다. 개인적으로는 그것은 ‘인간의 안전이 우선시돼야 한다’는 확신이다.

국내외 자동차 OEM에서는 소프트웨어 검증에 대한 요구사항을 설립하기 위해 국제 표준을 참고하기도 한다. 그러나 앞서 본 문제와 같이 문서는 현실 세계를 완벽히 반영하기 어렵다. 따라서 요구사항 수립은 OEM과 Tier 사이의 적절한 협의가 필수적이며, 현실적인 문제와 너무 동떨어진 설정은 피하는 것이 좋다.

자동차 개발에서 소프트웨어 타이밍은 작은 부분일지 모르지만, 임베디드 시스템과 RTOS 환경에서의 소프트웨어 타이밍은 매우 중요하다. 때문에 2023년 TRT(Timing Round Table)란 단체가 설립되기도 했다. TRT는 자동차 OEM, Tier 1, 실리콘 벤더, 여러 툴 벤더 등 다양한 집단이 함께 해 자동차 소프트웨어의 타이밍과 관련된 이슈를 다루며 합의점을 찾는다. 각각의 이해관계가 다를지라도 목적은 ‘안전하고 효율적인 소프트웨어를 개발’하기 위함이다. 

자동차 소프트웨어를 개발하는 개발자나 이를 위한 모든 협력사는 궁극적인 목적을 잊지 않았야 한다. 또한, 우리와 같은 툴 벤더의 역할은 솔루션을 제공하고, 그 목적의 중요성을 끊임없이 이야기하고 개발 결과물에 대한 확신을 갖도록 하는 것이다.