AUTOSAR를 공부하다 보면 SWC, Port, Interface, RTE 같은 용어는 빠르게 익히게 된다.
하지만 실제 프로젝트에 들어가면 가장 자주 듣게 되는 개념은 따로 있다. 바로 Runnable 과 Event 이다.
- 이 기능은 어떤 Runnable에서 동작하나요?
- 몇 ms 주기로 실행되나요?
- CAN 수신하면 바로 반응하나요?
- Init 시점에 실행되나요?
- Task랑 Runnable은 무엇이 다른가요?
이 질문들에 답할 수 있어야 AUTOSAR 실행 구조가 보이기 시작한다.
코드는 함수처럼 보이지만, 실제로는 설정된 조건에 따라 자동 실행되기 때문이다.
AUTOSAR의 핵심 구조는 다음 한 줄로 정리된다.
Runnable은 실행될 로직이고, Event는 그 로직을 실행시키는 조건이다.
이번 글은 AUTOSAR 공식 문서 AUTOSAR_CP_TPS_SoftwareComponentTemplate.pdf 기준으로
Runnable과 Event 관계를 실무 관점까지 포함해 자세히 정리한다.
공식 문서는 아래 링크를 참고한다.
https://www.autosar.org/fileadmin/standards/R25-11/CP/AUTOSAR_CP_TPS_SoftwareComponentTemplate.pdf
1. Runnable이란 무엇인가?
Runnable은 SWC 내부에서 실행되는 최소 기능 단위이다.
실제 Generate 이후에는 하나의 C 함수 형태로 구현된다.
예를 들어:
void MirrorControl_Run(void)
{
uint8 cmd;
(void)Rte_Read_PpFoldCmd_Value(&cmd);
if (cmd == 1U)
{
(void)Rte_Write_PpMotorDir_Value(FOLD_DIR);
}
}
이 함수는 Fold 명령을 읽고, 미러를 접는 출력값을 전달하는 기능을 수행한다.
AUTOSAR 관점에서는 이 전체 기능 단위를 하나의 Runnable으로 본다.
Runnable 내부에는 일반적으로 다음 코드가 포함된다.
- 입력값 읽기 (Rte_Read)
- 조건 판단
- 상태 변경
- 출력 전달 (Rte_Write)
- 서비스 요청 (Rte_Call)
즉, Application 로직의 핵심은 대부분 Runnable 안에 존재한다.

AUTOSAR 공식 문서에서는 RunnableEntity를 SWC 내부 실행 단위로 정의한다.
Runnable은 단순 함수가 아니라 모델 기반 실행 객체이다.
예를 들어 Runnable 내부에는 입력 데이터 읽기(VariableAccess), 다른 서비스 호출(ServerCallPoint), 파라미터 접근(ParameterAccess), 내부/외부 Trigger 연결 등이 포함될 수 있다.
즉, 실무에서 보이는 하나의 Runnable 함수 뒤에는 이미 모델 단계에서 다양한 동작 정보가 설계되어 있는 것이다.
2. 일반 함수와 Runnable의 차이
겉으로 보면 Runnable도 일반 함수처럼 보인다.
하지만 가장 큰 차이는 개발자가 직접 호출하지 않는다는 점이다.
일반 C 프로젝트:
MainFunction();
AUTOSAR 프로젝트:
1. Event 발생
2. RTE가 감지
3. OS Task 문맥에서 Runnable 실행
즉 개발자가 MirrorControl_Run(); 을 직접 호출하지 않는다.
실행 시점은 설정 정보와 스케줄링 구조가 결정한다.
그래서 Runnable은 단순 함수가 아니라 스케줄 가능한 실행 단위라고 이해해야 한다.
3. Event란 무엇인가?
Event는 Runnable을 실행시키는 조건 또는 트리거이다.
Runnable이 “무엇을 할지”를 정의한다면, Event는 “언제 실행할지”를 정의한다.
정리하면 다음과 같다.
Runnable = 실행 코드
Event = 실행 조건
RTE = 연결 및 호출 담당
AUTOSAR는 함수 호출을 코드에서 직접 연결하지 않고, 설정으로 연결한다는 점이 핵심이다.

이 그림은 AUTOSAR 공식 문서에서 Runnable과 Event의 연결 관계를 보여준다.
Event는 Runnable을 참조하여 실행 시작 조건(startOnEvent)을 정의한다.
4. 왜 Event 구조를 사용하는가?
차량 ECU는 제한된 CPU 자원으로 수많은 기능을 동시에 처리해야 한다.
모든 기능을 무한 반복 polling 방식으로 만들면 비효율이 커진다.
반면 Event 기반 구조는 필요한 순간에만 실행된다.
예:
- 10ms마다 실행
- CAN 메시지 수신 시 실행
- 진단 요청 시 실행
- 시동 직후 1회 실행
즉 AUTOSAR Event 구조는 단순 설정 기능이 아니라 실시간 시스템 최적화 방식이다.
5. 대표 Event 종류 완전 이해
1. TimingEvent
TimingEvent는 일정 주기마다 Runnable을 실행시키는 이벤트이다.
예를 들어 10ms 주기로 상태를 감시하는 기능은 다음과 같이 동작한다.
실무에서 가장 많이 사용하는 Event이다.

TimingEvent는 주기(period)를 기반으로 Runnable을 반복 실행한다.
2. DataReceivedEvent
새로운 데이터가 들어왔을 때 Runnable을 실행시키는 이벤트이다.
예:
- CAN 메시지 수신
- 버튼 입력 변경
- 다른 SWC 데이터 갱신
- 센서값 업데이트
데이터가 들어왔을 때만 동작하므로 CPU 효율이 높다.

Sender-Receiver 데이터가 갱신되면 해당 Runnable을 실행시키도록 설정할 수 있다.
3. OperationInvokedEvent
Client-Server 구조에서 특정 Operation이 호출되었을 때 실행되는 이벤트이다.
예:
Rte_Call_DiagService_Reset();
이 요청이 발생하면 서버 측 Runnable이 실행된다.
즉, 데이터 전달이 아니라 기능 요청 기반 이벤트이다.

Client의 Operation 호출이 Server Runnable 실행 조건이 된다.
4. InitEvent
시스템 시작 시 1회 실행되는 이벤트이다.
예:
- 변수 초기화
- 기본 상태 설정
- 출력 초기값 설정
- 진단 상태 초기화
주기 이벤트와 달리 시작 시 한 번만 실행된다는 점이 핵심이다.
6. Runnable과 Task는 무엇이 다른가
많은 초급자가 Runnable과 Task를 같은 개념으로 오해한다. 하지만 둘은 완전히 다르다.
Runnable은 Application 기능 단위라면, Task는 OS 스케줄링 단위이다.
즉 Task가 CPU 실행권을 얻으면, 그 안에서 RTE가 Runnable을 실행한다.
OS Task (10ms)
└─ RTE
├─ MirrorMonitor Runnable
├─ FoldControl Runnable
└─ Timeout Runnable
즉 Task는 실행 컨테이너이고, Runnable은 내부 기능 로직이다.
여러 Runnable이 하나의 Task 안에 배치될 수 있으며, 우선순위와 실행 주기는 OS가 관리한다.
정리
AUTOSAR 실행 구조는 다음 한 줄로 정리된다.
Event가 발생하면 Runnable이 실행된다.
Runnable은 기능 로직이고, Event는 실행 조건이며, Task는 운영체제 실행 단위이다.
반복 실행 → TimingEvent
데이터 수신 반응 → DataReceivedEvent
기능 요청 처리 → OperationInvokedEvent
시작 시 1회 → InitEvent
이 구조를 이해하면 AUTOSAR 코드는 단순 함수 집합이 아니라 체계적으로 설계된 실행 시스템으로 보이기 시작한다.
'AUTOSAR' 카테고리의 다른 글
| AUTOSAR 통신 모듈 관계도 완전 정리: CAN Stack 구조와 계층별 역할 이해 (0) | 2026.04.27 |
|---|---|
| AUTOSAR 통신 제어 구조 완전 정리: ComM, CanSM, CanNm, BswM 역할 이해 (0) | 2026.04.27 |
| AUTOSAR 초보자를 위한 E2E Protection (통신 보호) 완벽 정리 (0) | 2026.04.22 |
| AUTOSAR Rte_Read / Rte_Write / Rte_Call 차이 완벽 정리 (실무 + 공식 Spec 기준) (0) | 2026.04.22 |
| AUTOSAR Port Interface 종류 총정리 (SenderReceiver / ClientServer 쉽게 이해하기) (0) | 2026.04.21 |