AUTOSAR Software Module Developer

아래는 TC377 기반 파워트레인 ECU에서 배터리 SOC를 CAN FD로 100 ms 주기 송신하는 일반적인 AUTOSAR Classic 절차입니다. 실제 메뉴명과 설정 가능 범위는 사용 중인 RTA-CAR·EB tresos 버전에 따라 다를 수 있습니다.

1. 통신 요구사항 정의

먼저 CAN 매트릭스와 시스템 요구사항을 확정합니다.

• CAN 채널 및 네트워크 이름
• CAN FD 사용 여부
• Arbitration Bit Rate / Data Bit Rate
• 메시지 CAN ID
• DLC 및 데이터 바이트 배치
• SOC 스케일과 오프셋
• Byte Order
• 송신 주기: 100 ms
• Timeout 및 초기값
• Alive Counter, Checksum, E2E 보호 필요 여부
• 송신 허용 조건: Ignition, Network mode, 진단 상태 등

예시:

항목	예시
메시지	BMS_SOC
CAN ID	0x180
주기	100 ms
데이터 길이	8 bytes
SOC 신호	Byte 0~1, UInt16
변환식	Physical SOC = Raw × 0.01 %
CAN 형식	CAN FD, 500 kbit/s / 2 Mbit/s

2. RTA-CAR에서 SWC 구성

2.1 Application SWC 생성

RTA-CAR에서 배터리 SOC 송신용 Application SWC를 생성합니다.

예:

• SWC 이름: BatterySocSender
• Runnable: BatterySocSender_100ms
• 실행 이벤트: Timing Event, 100 ms

Runnable에서는 SOC 값을 직접 측정하거나, 별도 Battery Management SWC의 SOC 데이터를 RTE Client/Server 또는 Sender/Receiver 인터페이스로 수신합니다.

권장 구조는 다음과 같습니다.

BatterySocProvider SWC
        │
        │ RTE Sender/Receiver
        ▼
BatterySocSender SWC
        │
        │ RTE
        ▼
COM → PduR → CanIf → Can → CanDrv → CAN FD Controller

2.2 내부 데이터 타입 정의

SOC 신호에 맞는 AUTOSAR Data Type을 정의합니다.

예:

• Implementation Data Type: uint16
• Physical range: 0~100 %
• Resolution: 0.01 %
• Raw range: 0~10000

필요하면 다음을 정의합니다.

• BatterySocRawType
• BatterySocPercentType
• Invalid value
• Range limitation
• Quality 또는 validity 상태

2.3 Sender/Receiver 인터페이스 설정

SOC를 다른 SWC에서 받아오는 경우:

• Data Element: BatterySoc
• Data Type: uint16
• Communication pattern: Sender/Receiver
• Data status 또는 validity 정보 추가 가능

예를 들어 다음과 같이 구성합니다.

BatterySocProvider → BatterySocSender
BatterySocProvider.BatterySoc → BatterySocSender.BatterySocInput

SOC가 애플리케이션 내부에서 계산되는 경우에는 입력 포트 없이 송신 Runnable에서 값을 생성할 수도 있습니다.

2.4 Runnable과 Timing Event 설정

BatterySocSender_100ms Runnable에 100 ms Timing Event를 연결합니다.

Runnable의 일반적인 처리 순서는 다음과 같습니다.

1. 최신 SOC 값 읽기
2. 유효성 확인
3. Raw 값으로 변환
4. 범위 제한
5. COM 송신 데이터에 기록
6. 필요하면 상태 비트, Counter, Checksum 갱신

일반적으로 Application SWC가 직접 Can_Write()를 호출하지 않고, RTE 또는 COM 신호 API를 사용해야 합니다.

void BatterySocSender_100ms(void)
{
    uint16 socRaw;

    socRaw = Rte_IRead_BatterySocSender_100ms_BatterySocInput();

    if (socRaw > 10000u) {
        socRaw = 10000u;
    }

    Rte_Write_BatterySocTx_BatterySoc(socRaw);
}

실제 API 이름은 RTA-CAR에서 생성된 포트와 Runnable 설정에 따라 달라집니다.

3. CAN 송신 PDU와 COM 설정

RTA-CAR 또는 통합 BSW 설정 환경에서 CAN 신호를 COM에 매핑합니다.

3.1 CAN 메시지 및 I-PDU 정의

BMS_SOC 송신용 I-PDU를 생성합니다.

• I-PDU 이름: BmsSocTxIpdu
• Direction: Send
• Length: CAN FD DLC에 맞는 길이
• Cycle time: 100 ms
• Initial value 설정
• Timeout 동작 설정

CAN FD에서는 실제 데이터 길이에 따라 DLC가 결정되므로 8, 12, 16, 20, 24, 32, 48, 64 bytes 중 하나를 사용합니다. 예를 들어 8-byte 메시지는 Classical CAN과 동일한 DLC 8을 사용할 수 있습니다.

3.2 COM Signal 설정

SOC 신호를 COM Signal로 등록합니다.

예:

• Signal name: BmsSocSignal
• Bit position: 0
• Bit length: 16
• Endianness: Intel 또는 Motorola
• Data type: UINT16
• Update bit: 필요 시 사용
• Init value: 예를 들어 0 또는 Invalid 값

3.3 Signal-to-I-PDU 매핑

SOC 신호를 I-PDU에 매핑합니다.

BmsSocSignal
    └── BmsSocTxIpdu
            └── CanIf Tx PDU

필요하면 다음도 함께 매핑합니다.

• Alive counter
• CRC 또는 checksum
• SOC validity
• Battery status
• Diagnostic status

E2E 보호가 요구되는 경우, 일반적으로 COM 직접 처리 또는 E2E Transformer 구성을 시스템 아키텍처에 맞춰 선택합니다.

3.4 RTE와 COM 연결

RTA-CAR에서 SWC의 Sender Port를 COM 신호 또는 관련 BSW 통신 객체에 연결합니다.

일반적인 데이터 경로는 다음과 같습니다.

Rte_Write()
  → COM signal buffer
  → COM I-PDU
  → PduR_ComTransmit
  → CanIf_Transmit
  → Can_Write

주기 송신은 다음 두 방식 중 하나로 구성할 수 있습니다.

• Application Runnable이 100 ms마다 데이터를 갱신하고 COM이 주기 송신
• COM의 I-PDU Mode와 Tx mode를 100 ms 주기로 설정

대부분의 경우 COM의 주기 송신을 사용하고, Runnable은 데이터를 갱신하는 역할만 담당하는 구성이 명확합니다.

4. RTA-CAR에서 BSW 통신 모듈 연결

다음 BSW 모듈 간 연결을 확인합니다.

RTE
 └── COM
      └── PduR
           └── CanIf
                └── Can
                     └── CanTrcv

필요한 주요 설정은 다음과 같습니다.

• COM Tx I-PDU
• PduR routing path
• CanIf Tx PDU
• CanIf HTH 연결
• CAN Controller 연결
• CAN Hardware Object 연결
• CAN Transceiver 연결
• CAN FD frame 설정
• Bus-off 및 Controller mode 처리
• Notification 함수 또는 polling 방식

CAN FD 송신은 Classical CAN 프레임과 구분되는 설정이 필요하므로 CanIfTxPduCanIdType, FD frame 허용 여부, bitrate switching 여부를 확인해야 합니다.

5. EB tresos에서 MCAL CAN 설정

EB tresos에서는 TC377용 MCAL을 설정합니다.

5.1 CAN 클록과 핀 설정

먼저 MCU 및 포트 설정을 확인합니다.

• CAN 모듈에 공급되는 클록
• CAN controller instance
• TX/RX 핀
• Port alternate function
• Pin direction 및 pad 설정
• Transceiver enable 또는 standby GPIO

TC377 보드에서 외부 CAN transceiver의 STB/EN 핀이 별도 GPIO로 연결되어 있다면 Dio 또는 Port 설정도 함께 구성해야 합니다.

5.2 CanGeneral 설정

CanGeneral에서 다음을 설정합니다.

• Development error detection
• Version info API
• Set controller mode API
• Interrupt 또는 polling mode
• CAN FD 지원 옵션
• CAN hardware source configuration
• Wake-up 기능 필요 여부
• Bus-off notification 사용 여부

프로젝트의 안전 요구사항에 따라 DET, DEM, 오류 알림을 개발 단계에서는 활성화하는 것이 일반적입니다.

5.3 CanController 설정

사용할 CAN controller를 설정합니다.

• Controller ID
• Default baud rate
• CAN FD 활성화
• Nominal bit rate
• Data bit rate
• Bit rate switching, BRS
• Sample point
• Synchronization jump width
• Controller mode
• Bus-off 처리 방식

예:

Nominal bitrate : 500 kbit/s
Data bitrate    : 2 Mbit/s
CAN FD          : Enabled
BRS             : Enabled

실제 bit timing은 네트워크 전체 노드와 CAN transceiver 사양에 맞춰 계산해야 합니다. 단순히 nominal/data bitrate만 맞추는 것으로 충분하지 않을 수 있습니다.

5.4 CanHardwareObject 설정

송신용 Hardware Object를 생성합니다.

• Object type: TRANSMIT
• HOH ID
• Controller reference
• Handle type: Basic 또는 Full
• ID type: Standard 또는 Extended
• CAN ID range
• FIFO 또는 mailbox 사용 여부
• CAN FD frame 허용 여부

예시:

HTH: CanHTH_BmsSoc
Controller: CanController_0
ID type: Standard
CAN ID: 0x180
Direction: Tx
Frame: CAN FD

CAN ID와 DLC는 CanIf 및 시스템 CAN 매트릭스 설정과 반드시 일치해야 합니다.

5.5 CanConfigSet과 초기화 설정

CanConfigSet에 다음을 연결합니다.

• CAN Controller
• Baud rate configuration
• Hardware Objects
• HTH/HRH
• Notification function
• Controller baud-rate configuration

생성된 설정에서 다음 API와 구조체가 정상적으로 생성되는지 확인합니다.

• Can_Init()
• Can_SetControllerMode()
• Can_Write()
• Can_MainFunction_Write() 또는 Tx interrupt 처리
• Controller state notification
• Bus-off notification

6. CanIf, PduR, COM와 MCAL 설정 매핑

EB tresos 및 RTA-CAR에서 생성된 설정을 통합하면서 다음 ID를 일치시킵니다.

계층	확인 항목
SWC/RTE	Port, Data Element, Runnable
COM	Signal, I-PDU, Tx mode
PduR	COM Tx PDU → CanIf Tx PDU
CanIf	Tx PDU ID, HTH reference
Can	HOH, Controller, CAN ID
MCU/Port	Clock, CAN pin, transceiver pin

특히 아래 값이 서로 어긋나면 송신이 되지 않습니다.

• COM Tx PDU ID
• PduR routing PDU ID
• CanIf Tx PDU ID
• Can HTH ID
• CAN Controller ID
• CAN ID
• DLC 및 FD frame 설정

7. 코드 생성 및 통합

설정 완료 후 다음 순서로 코드를 생성합니다.

1. EB tresos MCAL 코드 생성
2. RTA-CAR RTE 및 SWC 코드 생성
3. COM/PduR/CanIf 설정 코드 생성
4. BSW와 RTE 통합
5. Application SWC 코드 구현
6. Startup 및 OS task 연결
7. 링커 설정 및 TC377 프로젝트 빌드

100 ms Runnable이 실제 OS Task에서 실행되는지 확인합니다.

OsTask_10ms
 └── Rte scheduled event
      └── BatterySocSender_100ms

100 ms 정확도가 중요하다면 10 ms 또는 100 ms 기본 스케줄링 주기와 Runnable 실행 오프셋을 검토해야 합니다.

8. 검증 및 디버깅

정적 검증

• AUTOSAR 인터페이스와 ARXML consistency check
• RTE port 연결 확인
• COM/PduR/CanIf ID consistency check
• MISRA-C 검사
• 사용하지 않는 API 및 잘못된 데이터 타입 확인
• CAN FD 설정과 네트워크 매트릭스 비교

타깃 검증

CAN 분석기를 사용해 다음을 확인합니다.

• 100 ms 주기
• CAN ID
• FD flag
• BRS flag
• DLC
• SOC raw value
• Byte order
• Counter 및 checksum
• Bus-off 발생 여부
• 송신 중 Controller mode

권장 디버깅 순서

1. Runnable이 100 ms마다 실행되는지 확인
2. Rte_Write() 호출과 값 확인
3. COM buffer에 값이 반영되는지 확인
4. PduR_ComTransmit() 호출 확인
5. CanIf_Transmit() 호출 확인
6. Can_Write() 결과 확인
7. CAN controller mailbox 상태 확인
8. 실제 CAN FD 프레임을 분석기로 확인

핵심 주의사항

• Application SWC에서 MCAL Can_Write()를 직접 호출하지 않습니다.
• SOC 송신 주기와 COM I-PDU 주기를 중복 설정하지 않도록 책임 범위를 명확히 합니다.
• CAN FD의 nominal bitrate와 data bitrate는 네트워크 전체와 일치해야 합니다.
• CAN ID, DLC, byte order, scaling은 CAN matrix와 동일해야 합니다.
• SOC의 invalid 상태와 초기값을 반드시 정의합니다.
• 파워트레인 ECU라면 timeout, alive counter, CRC/E2E, bus-off recovery 요구사항을 별도로 검토합니다.
• EB tresos의 MCAL 버전이 TC377 CAN FD 기능과 사용 중인 CanIf/COM 버전을 지원하는지 확인해야 합니다.