[CAN] AUTOSAR Rte_COMCbk 함수는 왜 필요한가 (SignalGroup Notification)

AUTOSAR CAN 통신 설정을 하다 보면 다음과 같은 상황을 자주 경험하게 된다.

 

- CAN 메시지는 정상적으로 수신됨

- Rte_Read()로 값도 정상적으로 확인됨

- 하지만 특정 Runnable이 전혀 실행되지 않음

 

또는

 

- 값은 들어오지만 처리 타이밍이 일정하지 않음

- Signal Group 데이터가 일부 이전 값과 섞여서 보임

 

이런 문제를 디버깅하다 보면 공통적으로 확인하게 되는 요소가 있다.

 

Com SignalGroup Notification 설정 여부와 자동 생성되는 Rte_COMCbk_* 함수이다.

 

이 글에서는 이 두 가지가 실제로 어떤 역할을 하는지 코드 흐름을 기반으로 구조를 풀어서 설명한다.

 

1. “데이터 수신”과 “Runnable 실행”은 별개의 단계이다

 

많은 경우 아래처럼 생각한다.

CAN 수신 → 데이터 갱신 → Runnable 실행

 

하지만 AUTOSAR 구조에서는 이 두 단계가 분리되어 있다.

 

실제 동작 흐름은 다음과 같다.

CAN 수신
→ COM 데이터 업데이트
→ Notification (선택적)
→ RTE Event 조건 갱신
→ Runnable 실행

 

여기서 중요한 포인트는 COM이 데이터를 업데이트하는 것만으로는 Runnable 실행이 보장되지 않는다.

Runnable 실행은 반드시 RTE Event 조건을 통해 결정된다.

 

2. Com_Cfg.c에서 Notification 설정이 의미하는 것

 

아래와 같은 코드는 단순한 함수 포인터 등록처럼 보일 수 있다.

CONST(Com_SigNotifCbk, COM_CONST) Com_GaaSigNotifCbk[] =
{
    {
        &Rte_COMCbk_ComISignalGroup_MsgGr_BCAN_BDC_FD_02_200ms
    },
};

 

하지만 이 설정은 단순 콜백 등록이 아니다.

이 설정이 의미하는 것은 “해당 Signal Group이 정상적으로 수신 처리가 완료되면 이 Callback 함수를 호출하라” 이다.

 

여기서 중요한 포인트는 “수신 완료” 이다.

 

Signal Group의 경우 내부 Signal들이 개별적으로 업데이트된 후

COM이 하나의 Group으로 재구성하고 완료 시점에 단 한 번 Notification이 호출된다

 

즉, 이 Callback은 “이 Signal Group이 유효한 상태로 갱신되었다”는 시점을 나타낸다.

 

3. Rte_COMCbk_* 함수의 실제 역할

 

자동 생성된 Callback 함수는 보통 다음과 같은 형태다.

FUNC(void, RTE_CODE) Rte_COMCbk_ComISignalGroup_MsgGr_BCAN_BDC_FD_02_200ms(void)
{
    Rte_ComHookRx_ComISignalGroup_MsgGr_BCAN_BDC_FD_02_200ms();

    if (Rte_CheckInitFlag(RTE_START) == RTE_SET)
    {
        Rte_Gst_ComPartition_...bl_EuFlag = (RTE_SET) ^ (Rte_Gst_SRFlags_...bl_EuFlag);
    }
}

 

겉으로 보면 단순한 플래그 연산처럼 보인다.

하지만 이 코드의 실제 핵심 역할은 단순 콜백 실행이 아니다.

 

3.1 Trace Hook

Rte_ComHookRx_ComISignalGroup_MsgGr_BCAN_BDC_FD_02_200ms

 

이 함수는 디버깅 및 트레이스 용도이다.

실제 동작에는 직접적인 영향이 없다.

 

3.2 Event Flag 변경

bl_EuFlag = (RTE_SET) ^ (기존 값);

 

이 코드는 단순 XOR 연산이 아니다.

RTE 내부에서는 이 값을 기반으로 RTE가 관리하는 Event 조건을 갱신하는 역할을 한다.

 

이 값이 변경되면

RTE는 해당 DataReceivedEvent 조건을 만족했다고 판단하고 연결된 Runnable을 실행 대상으로 올린다.

 

4. 전체 실행 흐름을 코드 기준으로 재구성

위 내용을 종합하면 실제 흐름은 다음과 같다.

Step 1. CAN 메시지 수신

: CAN Driver → CanIf → PduR

 

Step 2. COM 데이터 처리

: 각 Signal 갱신 → Group 단위로 재구성

 

Step 3. Notification 호출

: Com_GaaSigNotifCbk[index] 실행 → Rte_COMCbk_* 실행

 

Step 4. RTE Event 조건 갱신

: bl_EuFlag 변경 → Event 조건 만족

 

Step 5. Runnable 실행

: RTE Scheduler→ Runnable 실행

 

5. Notification이 없는 경우의 동작 특성

 

Notification이 없다고 해서 항상 문제가 발생하는 것은 아니다.

하지만 다음과 같은 차이가 발생한다.

 

5.1 Runnable이 실행되지 않는 경우

DataReceivedEvent 기반 구조에서는 Runnable이 실행되지 않을 수 있음

Notification 없음
→ Rte_COMCbk 호출 없음
→ Event 조건 갱신 없음
→ Runnable 미실행

 

즉, 기능 자체가 동작하지 않는 상태가 된다.

 

5.2 Polling 기반 구조로 강제 변경 필요

Notification이 없으면 결국 이렇게 구현하게 된다.

void Runnable_10ms(void)
{
    Rte_Read_MsgGr(...);
}

 

메시지 주기는 200ms 인데, Runnable 주기는 10ms 마다 실행되므로, 20번 중 1번만 의미가 있는 상황이 된다.

즉, 동일 데이터를 반복해서 읽게 된다.

 

5.3 데이터 처리 타이밍 제어 불가

Notification이 없으면 데이터 갱신 시점을 알 수 없다.

Runnable 실행 시점과 데이터 갱신 시점이 분리된다.
즉, 데이터의 일관성이 깨져 로직 오동작이 이어질 수 있다.

 

5.4 타이밍 기반 로직 오류

예: IGN 변화 시 특정 동작 수행, 특정 상태 변화 시 모터 제어

Notification 없으면 변화 시점을 알 수 없어 아래와 같은 상태 비교 로직이 추가로 필요해진다.

if (prev != current)

이렇게 되면, 코드 복잡도가 증가하고 버그 가능성도 증가될 수 있다.

 

6. Signal Group에서 Notification이 중요한 이유

 

Signal Group은 단순 데이터가 아니라 하나의 상태 집합이다.

Signal → 단일 값
Signal Group → 상태 집합

 

즉, Signal Group은 보통 차량 상태, 제어 조건, 모드 정보와 같이 “의미 있는 상태 묶음”이다.

이러한 데이터는 “동일 시점 기준”으로 처리되어야 의미가 있다.

 

Notification을 사용하면 “해당 상태가 갱신된 시점”에 맞춰 처리가 가능하다.

하지만 Notification이 없으면 데이터 갱신 시점과 로직 실행 시점이 분리된다.

 

정리

 

Rte_COMCbk_ComISignalGroup_MsgGr_BCAN_BDC_FD_02_200ms는 단순 Callback 함수가 아니다.

이 함수는 다음 역할을 수행한다.

COM → RTE 연결
RTE Event 조건 갱신
Runnable 실행 트리거 생성

 

최종 핵심 요약

Notification 없음 → 데이터만 존재

Notification 있음 → Event 조건 갱신 → Runnable 실행

 

AUTOSAR에서 중요한 것은 단순히 데이터를 읽는 것이 아니라

데이터가 갱신되었을 때 시스템이 어떻게 반응하도록 설계하느냐이다.

그리고 그 연결 지점이 바로 COM Notification 과 Rte_COMCbk_* 함수이다.