AE Wiki

AUTOSAR Timing Analysis

12 min read

AUTOSAR Timing Analysis — 여러 SW-C·Task·ECU를 거쳐 흐르는 end-to-end 타이밍을 설계·검증하는 프레임워크. 단일 Task 레벨의 WCRT로는 부족하고, Cause Effect Chain 전체가 데드라인 내에 도달하는지가 실제 차량 기능의 정당성 기준이 된다. AUTOSAR는 이를 위해 Timing Extension 스펙군을 제공한다.

왜 단일 Task가 아닌 Chain인가

센서 → 전처리 SW-C → 제어 SW-C → 액추에이터의 경로는 여러 Task, 여러 ECU, 네트워크 버스를 통과한다. 각 단계가 개별적으로는 스케줄 가능해도 조합된 지연이 데드라인을 넘길 수 있다.

알려진 이슈:

  • Preempted task를 통과하는 데이터 — 데이터가 선점된 태스크에 머물며 지연
  • 출력이 읽히기 전에 덮어씌워짐 — Sender가 빠르면 이전 값이 손실
  • 같은 데이터가 여러 번 읽힘 — Receiver가 빠르면 같은 샘플 중복 처리

이 현상들은 Runnable-Task 매핑, 주기 비율, 통신 모델 선택에 따라 발생한다.

Data Age vs Reaction Time

AUTOSAR는 end-to-end timing을 두 가지 의미로 구분한다 (출처: Specification of Timing Extensions).

Data Age

제어 공학에서 중요. 가정은 “last is best” — 경로상에서 값이 덮어씌워지는 것을 허용한다. 측정하는 양은 “마지막 자극(stimulus)부터 주어진 반응(response)까지의 지연”.

예: 휠 속도 센서값 → ECU → 제동 토크. 가장 최신 센서값이 제어에 반영되는 시간.

Reaction Time

자극에 대한 첫 반응이 중요할 때. 예: Body electronics — 버튼 누름부터 조명 on까지. 측정하는 양은 “주어진 자극부터 첫 번째 대응 반응까지의 지연”.

두 정의의 차이는 “중간값이 유실되어도 되느냐” — Data Age는 OK, Reaction Time은 첫 이벤트 보장이 필수.

Delay Model

SW-C Delay Model

단일 SW-C 내 R-Port(in) → Runnable Entities → P-Port(out) 경로의 최대 지연.

R-Port ──► RE1 ──► RE2 ──► P-Port
         └──── Max Latency (e.g., 2ms) ────┘

Inter-SW-C Delay Model

서로 다른 SW-C 간, 한 ECU 내부에서 RTE를 통한 SW-C 연쇄의 지연.

End-to-End Event Chain

여러 ECU와 버스를 가로지르는 chain. 각 segment는 Intra-ECU(RTE)와 Inter-ECU(CAN / FlexRay / Ethernet)로 구성된다.

[ECU A: Sensor Input → SW-C₁ → P-Port]
            │
            ▼  (Inter-ECU: CAN/FlexRay/Ethernet)
[ECU B: R-Port → SW-C₂ → ... → P-Port]
            │
            ▼
[ECU C: Actuator Output]

예 — Engine Control Event Chains

두 개의 서로 다른 시간 제약:

  • Requirement #1 — (raw yaw rate → delta angle → motor control)
  • Requirement #2 —

같은 경로에도 대상 상황에 따라 허용 지연이 다른 두 제약이 공존한다. Under-/Over-sampling 타임라인을 통해 Sender-Receiver 주기 비율에 따른 샘플 손실·중복을 분석한다.

AUTOSAR Timing Specification 문서

  • Doc 411 — Specification of Timing Extensions (R22-11)
  • Doc 410 — Requirements on Timing Extensions (R21-11)
  • Doc 645 — Recommended Methods and Practices for Timing Analysis and Design (R21-11)

설계 시 Doc 410의 요구사항을 Doc 411 스펙으로 모델링하고 Doc 645 방법론으로 검증하는 구조.

Logical Execution Time (LET)

물리적 실행(Physical Execution) — Activation → Start → (Preempt ↔ Suspend ↔ Resume) → Termination. 선점 여부에 따라 결과 지연이 매 주기 달라진다.

LET (논리적 실행 시간) — Release부터 Terminate까지의 논리적 구간을 사전에 고정하고, 실제 물리 실행은 그 안에서만 일어나도록 강제한다. Input은 LET 시작 시 원자적으로 읽고, Output은 LET 끝 시점에 원자적으로 쓰는 모델.

장점: 실행 타이밍이 선점·지터와 무관하게 결정적이 되어 Inter-SW-C 통신이 안정적으로 분석 가능.

12 Timing Parameters

Task·ISR의 타이밍 동작을 계량하는 표준 용어. Task A/B/C Gantt 분석에 사용된다.

IDAbr.Name의미
1IPTinitial pending timeactivation → start (대기)
2CETcore execution time선점·대기 제외한 순수 실행 시간 (= computation time)
3GETgross execution time선점·대기 포함한 실행 시간
4RTresponse timeactivation → termination (= WCRT의 응답시간)
5DLdeadlineRT의 허용 상한
6DTdelta timestart → start (측정된 주기)
7PERperiodactivation → activation (설정된 주기, 측정이 아닌 config 값)
8STslack timetermination → activation (잔여 여유 시간)
9NSTnet slack timeST − (ST 구간 내 상위 우선순위 Task/ISR의 CET 합) — “실제 쓸 수 있는” 여유
10JITjitterDT와 PER의 편차 (주기 흔들림)
11PREpreemption time상위 우선순위에 의해 선점당한 총 시간
12CPUCPU load비-idle 시간 비율 (%)

분할 합산 예:

  • (선점으로 나뉜 실행 구간들의 합)

DT vs PER의 구분이 중요 — PER은 설계값, DT는 실제 관측값. 둘의 차이가 JIT (jitter).

업계 동향 — 통합 ECU 시대의 AP+MCU 타이밍 측정

SDV 전환으로 ECU는 애플리케이션 프로세서(AP)와 마이크로컨트롤러(MCU)가 동시 운영되는 통합 구조로 진화 중이다. 통합 ECU 환경에서는 AP·MCU가 공유하는 글로벌 타이머 기반의 동기화된 성능 측정이 요구된다 (ITIV AI).

GLIWA T1 (국내 총판 ITIV AI)

자동차 타이밍 분석 전문기업 GLIWA의 상용 솔루션 T1은 AP-MCU 동기화 타이밍 측정에 특화됐다. 플러그인 구조:

플러그인대상 환경기능
T1.timingMCU 수준ECU SW 성능 측정 기본 기능, 태스크·러너블 수준 모니터링 (AUTOSAR Classic Platform)
T1.posixAP POSIX 환경QNX·Linux 같은 AUTOSAR Adaptive OS 환경의 프로세스·스레드 타이밍 측정
T1.streaming통합 AP+MCU + 이더넷대용량 데이터 스트리밍 환경에서 SW 세부 동작 실시간 트레이싱

ITIV AI에 따르면 T1은 자율주행·ADAS 환경에서 AP↔MCU 공유 데이터의 타이밍을 정밀 측정해 환경 인식·경로 계획·주행 제어의 지연을 최소화하는 용도로 활용된다. ITIV AI는 현대자동차 및 글로벌 OEM의 주요 프로젝트에 SW 타이밍 분석 리포트를 제공한다고 밝혔다 (2024-12).

POSIX 환경 타이밍 — T1.posix 상세

AUTOSAR AP는 자율주행·ADAS·커넥티비티 등 고급 기능에 적용되며 POSIX 운영체제 기반. POSIX는 실시간 성능과 범용 개발 환경을 동시 제공하지만, 멀티코어 글로벌 스케줄링으로 런타임에 스레드 동적 할당 — 주기적 동작을 OS 스케줄러에서 확인 불가.

POSIX 타이밍 3구분: 대기시간·실행시간·스케줄링 지연시간. 각 프로세스/스레드 상태에 따라 타이밍 정보 읽어 처리.

T1.posix는 POSIX 타이밍과 주기적 동작에 대한 AUTOSAR 타이밍 분석을 동시 지원하며, 멀티코어 환경에서 이더넷 기반 트레이스로 OS 프로세스·태스크 실행시간·CPU 사용량·메모리 사용량 분석. AP 적용 제어기의 필수 요구사항인 CPU·메모리·실행시간 데이터 측정으로 시스템 오류 가능성 확인.

2025 후속

  • 2025-11-04 T1 Timing Conference 2025(ITIV AI + GLIWA 공동, 서울 COEX, 약 80명 참석 — 현대자동차 그룹 + 주요 티어 1). 발표 — GLIWA Director Training & Coaching Christian Wenzel-Benner Timing and resources + 현대자동차 상용통합제어개발팀
  • T1-HOST-SW 4.0 — 2025년 하반기 출시 예정

Multi-ECU 동기화 — Master/Slave 방식 (T1)

ITIV AI 진영진 대리(2025-12) 정리. 각 프로세서가 서로 다른 타이머(레졸루션·비트 수 다를 수 있음)를 사용하므로 프로세서 간 타이밍 동기화 필수.

ARM↔AURIX 동기화

  1. 각 ECU 물리적 연결(sync)
  2. Master ECU(ARM) 타이머를 Slave ECU(AURIX)로 전달 — Slave도 Master 타이머 사용
  3. 다른 코어에서도 동일 타이머 사용 효과

트레이드오프

  • Master↔Slave 간 지연·불확실성 — 연속적 지연은 보정 가능, 불특정 지연은 정확성에 영향
  • 타이머 데이터 전달 주기 — 모든 이벤트 전달 = 정확도↑/부하↑, 특정 이벤트 전달 = 부하↓/정확도↓

T1의 차별점

  • ARM↔AURIX 등 이종 아키텍처 동기화 타이밍 측정
  • POSIX + AUTOSAR OS의 AP↔MCU 동기화 측정 유일 도구
  • AP·MCU 타이밍을 한 화면에서 동시 확인 (태스크 실행 시간)

SDV 통합 ECU가 타이밍 분석에 가하는 압력

  • AP + MCU 상호작용 구조 필수화 — 각 프로세서는 서로 다른 OS(POSIX·AUTOSAR Classic)와 성격(범용·제어)을 가짐.
  • OTA 업데이트가 SW를 지속 진화시켜 타이밍 재검증이 상시 필요.
  • ADAS·자율주행이 AP↔MCU 데이터 교환 지연에 민감.
  • 통합 ECU 내부 이더넷 통신 인터페이스로 대용량 데이터가 오가므로 트레이싱 대상이 폭발적으로 증가.

같이 보기

참고 자료

그래프 뷰

백링크