자동화 프로세스의 장점으로는 휴먼 에러의 최소화, 검증에 필요한 인력 및 비용 절감을 들 수 있다. 또한 ISO 26262나 ASPICE에서 요구하는 타이밍 검증 프로세스에 대응할 수 있다.

자동차 SW 타이밍 검증 프로세스의 중요성

최근 자동차 SW는 ADAS와 같은 최신 기술들이 적용되고 있다. 이러한 기술들이 추가됨에 따라 안전과 관련된 기능들이 많이 요구되며 SW의 타이밍에 대한 관리도 매우 중요해지고 있다. 이미 국내외 자동차 OEM들은 자동차 기능안전 국제표준인 ISO 26262나 ASPICE(Automotive Software Process Improvement and Capability dEtermination)에 명시된 타이밍 요구사항을 만족하기 위한 SW 개발 프로세스를 개선하기 위해 노력하고 있다. 특히 최근에는 SW 검증 결과에 대한 신뢰성을 확보하기 위해 레벨 3 이상의 ASPICE 인증도 필수로 요구하는 추세이다.

ASPICE는 SW 개발 프로세스 전반의 심사를 통해 개발사에 대한 능력을 평가 및 향상시키는 데 목적을 두고 있다. 실제로 타이밍 검증과 관련된 항목을 살펴보자. ASPICE 표준의 SWE.2.BP4와 SWE.2.BP5에서는 SW 아키텍처를 설계할 때 SW의 동적 행동(태스크, 인터럽트 등의 동작 방식)을 서술하고 리소스 소모(CPU 사용량, 메모리 사용량 등)에 대한 목표를 정의하도록 명시하고 있다. 또한 SWE.5.BP3에서는 SW 통합 테스트를 위한 명세서를 개발할 때 SW 아이템 간 데이터가 정확한 시간 내에 잘 주고받았는지, 또 리소스 소모에 대한 목표가 준수되었는지에 대한 객관적인 증거를 제출할 수 있어야 한다.



V사이클 기반 타이밍 검증 프로세스 현황

SW 개발 프로세스는 V사이클을 기반으로 이루어진다. V사이클을 타이밍 관점에서 살펴보자. 각 단계는 타이밍 요구사항 수립, 타이밍 설계, SW 구현, SW 통합 환경 성능 테스트, 실차 환경 최종 성능 검증 단계로 나누어 볼 수 있다. 그리고 타이밍 검증에 필요한 각 단계별 업무 및 필요한 결과물을 정의하고 이를 효율적으로 수행할 수 있는 전체 프로세스 관리가 필요하다.

타이밍 요구사항 수립 및 타이밍 설계 단계에서는 SW 기능별 WorstCase에 대한 실행시간, 응답시간, CPU 사용량 등과 같은 품질 기준과 관련된 타이밍 요구사항을 정의한다. 그리고 수립된 타이밍 요구사항을 만족하기 위해 BSW(Basic SoftWare)를 설계한다(태스크/인터럽트들의 실행 주기, 우선순위, 실행 순서, offset 등의 스케줄러 설계).

SW 구현 단계에서는 앞서 설계한 타이밍 모델링 결과를 기반으로 실제 코드를 개발하고 실 타깃에서 동작되기 위한 바이너리를 생성한다.

SW 통합/실차 환경 성능 테스트 단계에서는 각 기능들이 통합된 SW가 동작하는 실제 타깃 환경에서 타이밍을 측정하고 분석하여 타이밍 요구사항에 위반되는 사항이 있는지를 확인한다. 이를 위해 실제 주행과 비슷한 테스트 환경을 구성하거나 실차 환경에서 타이밍 측정을 할 수 있어야 한다. 위반 사항이 발견되면 측정된 타이밍 결과를 기반으로 이를 해결하기 위한 최적화 작업 또는 타이밍 설계 수정 과정을 다시 수행한다.

우리는 이미 개발 초기 단계에서 타이밍 요구사항 정의와 설계가 명확하지 않으면 전체 개발 비용에 크게 영향을 줄 수 있다는 사실을 알고 있다. 하지만 SW 개발 완료 기간을 단축하기 위해서 타이밍 설계 과정을 생략하거나 SW 구현과 동시에 성능 테스트를 같이 진행하기도 한다. 결국 검증 단계에서 TASK 누락, 우선순위 역전현상, 스택 오버플로, 높은 CPU 사용량과 같은 문제를 겪게 된다. 이러한 문제를 미리 대비하고 최소화하기 위해서는 요구사항 정의 및 설계 단계에서부터 리소스 사용량에 대한 목표를 설정하고 이를 개발 및 테스트 단계에서 추적 관리할 필요가 있다. 또한 타이밍 측정 결과를 바탕으로 WorstCase에 대한 타이밍 위반사항 여부를 검출해 낼 수 있어야 한다. 이를 위해서는 정확한 타이밍 측정과 시뮬레이션을 통한 분석 및 검증이 필요하다.



타이밍 측정 vs 타이밍 시뮬레이션

타이밍 측정과 시뮬레이션은 SW의 타이밍 검증 프로세스를 구축하고 이를 자동화하는 데 필요하다.

타이밍 측정은 실 타깃 환경에서 SW가 동작하는 타이밍을 측정한다. 기존에 가장 많이 활용되는 타이밍 측정 방식의 경우 오실로스코프나 코드 삽입 방식을 활용했다. 그러나 최근에는 RTOS가 적용되고 타이밍 요구사항에 따른 측정 항목이 많아짐에 따라 이를 모두 대응할 수 있는 측정 방식이 필요하다.

타이밍 시뮬레이션은 실 타깃이 없는 환경에서 SW가 동작하는 타이밍을 시뮬레이션하고 분석한다. 실제 SW를 구현하기 전에 타이밍 요구사항에 기반을 둔 타이밍 모델링 작업을 수행하고 이를 시뮬레이션하여 SW 타이밍 검증을 할 수 있다. 그림 3은 타이밍 요구사항 정의 및 SW 설계 단계에서 타이밍 모델링 기반 시뮬레이션을 활용한 예이다.



SW 설계 단계까지의 검증이 끝나면 이를 기반으로 실제 SW를 구현한다. 이때부터 실 타깃 기반 타이밍 측정을 시작하며 이 과정에서 타이밍 위반사항을 검출하기 위한 검증 프로세스가 필요하다.

보통 타이밍 측정은 실 타깃 동작 기반으로 측정하기 때문에 테스트 케이스를 100%로 만족시키지 않는 이상 WorstCase에 대한 분석을 할 수 없다. 달리 말하자면, 측정하는 시간 동안의 최대 사용량을 리포트 할 수는 있으나 WorstCase에 대한 사용량이라고 할 순 없다. 실제로 비주기적으로 동작되는 태스크/인터럽트들은 언제 수행될지 예상할 수 없기 때문에 장시간 수행 시 SW 타이밍에 어떻게 영향을 줄지 판단하기 어렵다. 즉 타이밍 위반사항에 대비하기 위해서는 WorstCase에 대한 사용량을 파악할 수 있어야 하고, 이는 타이밍 시뮬레이션을 통해 해결할 수 있다. 아래 그림 4에서는 타이밍 측정과 시뮬레이션의 최소/최대 응답시간의 커버리지에 대해 잘 보여준다. 구현이 완료된 SW 타이밍 측정 환경에서의 최소/최대 응답시간보다는 잘 갖춰진 테스트 시나리오를 이용한 시뮬레이션 환경에서 더 높은 커버리지를 갖게 되는 것을 볼 수 있다. 추가로 타이밍 시뮬레이션 환경에서 위반사항이 없더라도 테스트 되지 못한 잠재적인 타이밍 오류가 있을 수 있다. 이를 ‘Corner case’라고 하며, 이 상황도 고려되면 WorstCase에 대한 사용량까지 분석이 가능하다.

즉 타이밍 시뮬레이션을 통해 SW의 잠재적인 타이밍 오류 검출이 가능하다. 또한 검출된 문제를 시뮬레이션 환경에서 수정하고(SW 타이밍 모델 수정) 다시 시뮬레이션하여 타이밍 오류에 대해 빠르고 수준 높은 최적화 과정을 수행할 수 있다. 그리고 시뮬레이션 결과를 기반으로 제안된 최적화 방법을 실제 구현 단계에 다시 적용해 문제가 해결된 코드를 생성한다.



타이밍 시뮬레이션의 신뢰성 확보 방안

타이밍 시뮬레이션 신뢰성은 타이밍 모델링 수준에 따라 달라진다. 타이밍 모델링은 앞서 언급한 것과 같이 태스크/인터럽트들의 실행 주기, 우선순위, offset 등과 같은 스케줄러의 기본 구조와 동작 방식에 대해 설계한다. 그리고 이를 시뮬레이션하기 위해 각 태스크/인터럽트들의 예상되는 최소/최대 수행 시간(Core Execution Time, CET)을 정의해야 한다.

보통 이러한 타이밍 모델링을 위한 작업은 SW의 RTOS, 네트워크, 시스템 레벨까지 전반적인 구조에 대한 높은 이해도가 필요하다. 그렇지 않으면 모델링을 위해 많은 시간과 노력을 들여야 하며, 그럼에도 신뢰성 있는 타이밍 모델링을 보장할 수 없다. 가장 좋은 방법은 현재 개발된 SW 모듈 정보를 추출하는 것이다. 예를 들어 AUTOSAR가 적용된 개발환경의 경우 태스크/인터럽트들에 대한 모든 설정 정보들이 XML 기반의 AUTOSAR 표준 포맷인 ARXML 파일에 모두 정의되어 있다. 여기에 정의되어 있는 내용을 추출한다면 실제 구현된 SW와 동일한 구조를 가진 타이밍 모델링을 만들 수 있다.

태스크/인터럽트들의 예상되는 최소/최대 수행 시간의 값 또한 타이밍 시뮬레이션 결과의 신뢰성에 큰 영향을 미친다. 수행 시간의 값이 없는 상태에서 시뮬레이션을 실행하는 것은 태스크/인터럽트들이 실행은 되지만 SW가 수행하는 기능이 없다는 것이다. 이 경우 태스크/인터럽트들은 실행되자마자 종료될 것이고, 서로 간에 선점되어 수행될 가능성도 없기 때문에 시뮬레이션 결과 역시 큰 의미가 없게 된다. 즉 타이밍 모델링에 태스크/인터럽트의 최소/최대 수행 시간의 값을 입력하는 것은 매우 중요하며, 이에 따라 시뮬레이션 결과에 대한 신뢰성이 달라질 수 있다.

먼저 수행 시간에 대한 의미를 정의해보자. 보통 우리가 생각하는 수행 시간은 측정 대상의 시작부터 끝까지 수행한 전체 시간(Gross Execution Time, GET)이다. 하지만 시뮬레이션을 위해 필요한 수행 시간은 측정 대상의 시작부터 끝까지 순수 수행 시간(CET)을 의미한다. 즉 다른 우선순위 높은 기능에 의해 선점된 시간을 제외한 정보만을 가지고 시뮬레이션을 실행해야 한다.

신뢰성 있는 최소/최대 수행 시간 값을 입력하기 위해서는 예상되는 값을 입력하는 방법과 실제 측정한 값을 입력할 수 있는 방법이 있다. 만약 SW가 구현되기 전 타이밍 설계 단계에서 시뮬레이션을 수행하고자 한다면 타이밍 요구사항으로 정의한 해당 태스크/인터럽트의 최소/최대 허용시간을 입력해야 한다. 이 경우에는 우리가 이론적으로 생각해왔던 타이밍 요구사항에 대해 위반사항이 있는지를 시뮬레이션을 통해 확인할 수 있다. 만약 SW가 이미 구현되어 있는 상황이라면 실제 타깃 환경에서 순수 수행 시간을 측정할 수 있는 솔루션을 사용하여 최소/최대 값을 추출할 수 있다. 이때 HIL 시뮬레이션과 같은 가능한 많은 테스트 시나리오들을 실행시키면 더 신뢰성 있는 최소/최대 수행 시간의 값을 측정할 수 있다. 이 경우 실제 측정한 값을 이용하기 때문에 가장 신뢰성 있는 시뮬레이션 결과를 얻을 수 있다.

이외에도 태스크/인터럽트들의 지터(Jitter)나 발생 패턴에 대한 히스토그램 등의 측정 데이터들이 있으면 더 신뢰성 있는 시뮬레이션을 실행할 수 있다.

타이밍 검증 프로세스 자동화 방안과 적용사례

자동차 SW 타이밍 검증을 위해서는 결국 타이밍 시뮬레이션과 측정이 모두 필요하며, 이를 이용하여 타이밍 오류에 대해 분석하고 최적화 작업을 진행해야 한다. 하지만 앞서 언급한 내용들과 같이 이 모든 작업을 수행하기 위해서는 많은 시간이 소요된다. 또한 타이밍 설계, 구현, 측정, 검증 등 각 단계에 대한 별도의 담당자들이 동일한 기준을 가지고 타이밍 오류 검출을 위한 의사소통을 해야 하기 때문에 시간도 많이 소요된다. 자동차 SW의 개발 일정이 점점 짧아지고 빨라지는 상황에서도 SW의 품질 및 안전성은 필수적이다.

결국 우리는 SW 타이밍을 검증하기 위해 투자되고 있는 많은 시간과 비용을 절감하는 것과 동시에 신뢰성 있는 검증 프로세스를 구축할 필요가 있다. 실제로 최근 국내 최대 자동차 OEM인 현대자동차에서는 타이밍 검증을 위한 시간/비용 절감과 신뢰성 있는 타이밍 검증 프로세스를 위해 “타이밍 요구사항 기반 성능 검증 프로세스 자동화 환경 구축”을 완료했다.

개발환경은 인피니언(Infineon)의 AURIX CPU와 ODIN AUTOSAR이며 개발 도구로는 TRACE32 디버거, T1 타이밍 측정 솔루션, INCHRON 타이밍 시뮬레이션 도구를 사용했다.




타이밍 검증을 위한 자동화 프로세스를 살펴보자. 먼저 TRACE32 디버거를 사용하여 구현된 SW의 ELF 파일을 타깃에 Flash Download 한다. 이후 타깃을 실행시키고 T1을 사용해 성능 측정 및 리포트 파일을 추출한다. 이후 INCHRON 도구에서 지원하는 python API를 통해 T1에 의해 생성된 타이밍 측정 리포트 파일, OS Configuration 정보가 포함된 ARXML 파일(태스크/인터럽트의 정보), Runnable 정보를 위한 RTE 소스 파일을 추출하여 타이밍 모델링 파일을 자동 생성한다. 추가로 타이밍 요구사항 수립 단계에서 정의한 내용이 포함된 엑셀 또는 CSV 파일을 작성하고(표 2 참고), 기 생성되어 있는 타이밍 모델링 파일에 추가 적용한다. 이렇게 최종 모델링 파일이 완성되면 INCHRON 도구를 이용한 타이밍 시뮬레이션을 자동으로 시작한다. 사용자가 지정한 시뮬레이션 시간이 지나면 자동으로 종료되고 타이밍 요구사항에 위반된 상황들을 리포트한다.



그림 7과 같이 시뮬레이션 실행 결과에서 타이밍 위반사항이 검출되면 위반사항이 발생한 위치에 대한 자세한 정보를 확인하여 분석이 가능하다. 분석한 내용을 바탕으로 타이밍 모델링 정보를 수정, 실행, 위반사항 검출 과정을 위반사항이 발생하지 않을 때까지 계속 반복한다. 즉 우리는 SW 코드 수정을 통한 타이밍 오류 검출, 검증 시간, 검증 비용을 시뮬레이션을 통해 절감할 수 있다.

그림 8은 실제 현대자동차에서 해당 자동화 기능을 수행하여 나온 타이밍 측정과 시뮬레이션 시간에 대한 비교 결과를 보여준다. 그림 3에서 보인 바와 같이 측정한 수행 시간의 최소/최대 값보다 시뮬레이션의 수행 시간 값이 더 큰 범위를 차지하고 있음을 확인할 수 있다. 즉 실제 측정 환경에서는 발생하지 않았으나 SW가 장시간 수행 시 발생할 수 있는 잠재적인 타이밍 오류를 검출하기 위한 방법을 보여준 결과라고 볼 수 있다.

결론

자동차 SW는 통합제어기나 ADAS 시스템과 같이 더 많은 기능을 ECU에서 수행하도록 설계하고 있다. 때문에 SW의 복잡도가 증가하고 높은 성능의 MCU나 CPU가 활용되고 있다. 이에 따라 타이밍 검증의 중요성 또한 계속 증가하고 있다. 기존 프로세스대로 타이밍 검증을 SW 결함이 발생할 때마다 급하게 대응하려한다면 결국은 개발 기간과 비용이 더 상승할 수밖에 없다. 이러한 이유로 최근 신뢰성 높은 SW 타이밍 검증 자동화 프로세스를 구현하기 위해 단계별 검증 프로세스를 구체화하고 이를 자동화하는 방법에 대한 필요성이 증가하고 있다. 자동화 프로세스의 장점으로는 휴먼 에러의 최소화, 검증에 필요한 인력 및 비용 절감을 들 수 있다. 또한 ISO 26262나 ASPICE에서 요구하는 타이밍 검증 프로세스에 대응할 수 있다.

자동차 SW 개발 및 양산에 있어 가장 중요한 것은 품질과 비용, 안전성이다. 하지만 프로젝트마다 개발환경과 테스트 방법이 다르기 때문에 검증 결과의 신뢰성과 일관성이 떨어지게 된다. 즉 여러 개발환경에서 동일한 방법으로 적용할 수 있는 SW 타이밍 검증 프로세스 자동화는 필수적이다.