AUTOSAR RTE (Runtime Environment)AUTOSAR Classic Platform에서 Application Layer와 BSW의 경계에 위치하는 계층. Virtual Functional Bus(VFB)의 특정 ECU 구현체 이며, SW-C 간 통신, Runnable 활성화, BSW 서비스 접근을 자동 생성된 함수 인터페이스로 제공한다. SW-C는 RTE API만 보고 작성되므로 ECU 간 재배치·매핑이 가능해진다. 입력 산출물은 Software Component Description + ECU Configuration Description.

4단계 설계 관점

AUTOSAR는 애플리케이션 설계부터 RTE 코드 생성까지를 4단계로 본다.

AUTOSAR RTE 4단계 설계: 애플리케이션 → VFB → ECU 할당 → RTE

①~②는 ECU 무관 설계, ③에서 배치가 확정되고 ④에서 RTE 코드가 생성된다.

VFB → RTE의 관계

VFB(Virtual Functional Bus)는 설계 시점의 논리적 통신 버스 추상화. 차량 전체를 하나의 가상 버스로 본 뒤, 이를 다수 ECU에 mapping하면 각 ECU별로 RTEBSW가 자동 생성된다.

[VFB view]          →   [Mapping to ECUs]  →   [RTE + BSW per ECU]
 SW-C끼리 직접 연결된       SW-C ↔ ECU 할당          통신이 intra-ECU /
 것처럼 보이는 논리 뷰                                inter-ECU로 구체화
  • Intra-ECU 통신 — 같은 ECU 내 SW-C 간. RTE 함수 호출로 최적화
  • Inter-ECU 통신 — 서로 다른 ECU의 SW-C 간. RTE가 BSW Communication Services를 통해 CAN/FlexRay/Ethernet 프레임으로 변환

SW-C 입장에서는 상대가 같은 ECU인지 다른 ECU인지 몰라도 된다 — 이것이 VFB의 추상화 가치.

Tool-based Workflow

RTE는 손으로 작성하지 않고 도구가 자동 생성한다.

ARXML 단일 소스에서 4개 Generator로 분기되는 RTE 도구 체인

ARXML은 AUTOSAR의 configuration 교환 포맷 (XML 스키마). 설계 도구가 ARXML을 출력하면 각 Generator가 이를 읽어 대상 파일을 뽑아낸다.

RTE API

RTE가 자동 생성하는 함수는 세 종류로 나뉜다.

API용도통신 스타일
Std_ReturnType Rte_Send_<port>_<data>(<type> val)Sender-Receiver 송신비동기
Rte_Receive_<port>_<data>(...)Sender-Receiver 수신비동기
Rte_Call_<port>_<operation>(...)Client-Server 호출동기 (원격이어도)

<port><data>는 SW-C 설계 시 정의된 Port 이름·데이터 요소 이름으로 치환된다. 통신 모델의 의미는 Communication Models 참고.

AUTOSAR는 이 Rte_* API 외에도 Standardized AUTOSAR Interface(표준 Port 기반 Rte_*)와 Standardized Interface(Com_SendSignal 등 BSW 직접 호출, RTE 우회) 두 유형을 추가로 규정한다. 3종 분류와 결정 흐름은 AUTOSAR Interface 참고.

RTE가 자동 생성하는 API는 위 3종 외에도 Rte_Switch_*, Rte_Mode_*, Rte_IWrite_*, Rte_IRead_*, Rte_Call_*, Rte_Result_*, Rte_Trigger_* 등 총 12개 Access Point 카테고리로 확장된다. 전체 목록은 Access Point (12종 + RTE API) 참고.

Runnable-to-Task Mapping

SW-C 내부의 RunnablePeriod별 그룹으로 묶여 OS Task에 할당된다. SW-C 자체는 OS를 모르고, 통합 단계에서 도구가 Runnable을 Task에 mapping한다.

예: 5ms/10ms/100ms Runnable이 있을 때

Runnable이 Period별로 묶여 OS Task로 매핑되는 합류 구조

Task 내부 — Runnable Sequencing

Task는 자신에 매핑된 Runnable들을 순차 호출한다.

TASK(task_10ms)
{
    runnable1A();
    runnable2A();   // 의존 관계(Runnable Sequencing) 고려
    runnable3A();
    runnable4A();
    runnable5A();
    TerminateTask();
}

Runnable Sequencing — 한 Task 내에서 Runnable 호출 순서는 Runnable 간 데이터 의존성에 따라 결정된다. runnable1Arunnable2A의 입력을 만든다면 1A가 먼저 와야 한다. 이 순서 역시 도구가 Runnable 간 data dependency를 분석해 결정한다.

실제 Task·Alarm 할당과 PositionInTask 결정은 RteEventToTaskMapping에서 이루어진다.

같이 보기