1. E2E Protection의 정의와 필요성
E2E(End-to-End) Protection은 AUTOSAR에서 송신 애플리케이션부터 수신 애플리케이션까지 전달되는 데이터에 대해 무결성(Integrity), 순서(Sequence), 최신성(Freshness) 을 보장하기 위해, 데이터 끝단에서 수행하는 통신 보호 메커니즘이다.
즉, 중간 통신 계층(CAN, COM, PduR, RTE 등)을 신뢰하지 않고,
송신 SWC와 수신 SWC 사이에서 데이터가 변조·누락·중복되지 않았는지를 End-to-End 방식으로 검증하는 기능이다.
ECU 간 통신은 CAN, CAN FD, Ethernet 등 다양한 네트워크를 통해 이루어지지만,
다음과 같은 이유로 데이터 신뢰성을 100% 보장할 수 없다.
- 전자기 노이즈(EMI)
- 버스 상 데이터 손실
- ECU 내부 SW 오류
- 중간 통신 스택 오류 (COM, PduR 등)
특히 브레이크, 조향, 파워트레인 제어와 같은 안전 기능에서는 단 1개의 잘못된 데이터도 허용될 수 없다.
이 때문에 ISO 26262에서는 통신 데이터의 오류 검출 및 대응 메커니즘을 요구하며,
그 대표적인 방식이 E2E Protection이다.
2. E2E의 핵심 철학: “통신 경로는 신뢰하지 않는다”
E2E Protection의 핵심 철학은 단순하다.
중간 통신 계층은 신뢰하지 않고, 양 끝단에서만 데이터의 정합성을 검증한다.
즉, CAN Driver, CanIf, PduR, COM과 같은 중간 계층이 정상 동작하더라도,
데이터가 손상되었을 가능성을 항상 전제로 한다.
따라서 검증 로직은 반드시 Application 계층 (SWC 내부) 에서 수행된다.

이 그림은 E2E의 기본적인 작동 원리를 보여준다.
송신자(Sender SW-C)가 데이터를 보낼 때 E2E 헤더(CRC, Counter)를 붙여서 보내고, 중간의 복잡한 AUTOSAR 스택을 거쳐 수신자(Receiver SW-C)에게 도달했을 때 이 헤더를 검증하는 과정을 시각화했다.
중간의 Untrusted Communication Channel(CAN/Ethernet)에서 노이즈나 메시지 손실 같은 문제가 발생하더라도, 수신측(Receiver)의 E2E Wrapper가 데이터에 붙은 CRC와 Counter를 검증하여 최종 Application에는 안전한 데이터만 전달하는 것을 볼 수 있다.
3. E2E 구조 동작 원리
E2E Protection은 송신 데이터에 추가적인 보호 정보를 붙여 전송한다.
송신 측 (Sender)
Application 데이터 생성
E2E Wrapper가 CRC, Counter, Data ID 추가
RTE → COM → CAN으로 전송
수신 측 (Receiver)
CAN → COM → RTE 전달
E2E Wrapper가 CRC / Counter 검증 수행
정상 데이터만 Application으로 전달
간단히 표현하면 아래 구조이다.
Sender SWC → E2E Encode → Network → E2E Decode → Receiver SWC
4. E2E 주요 구성 요소
E2E Protection은 데이터 프레임에 다음과 같은 추가 필드를 사용한다.
1) CRC (Cyclic Redundancy Check)
데이터가 전송 중 변조되었는지를 검출하는 값이다.
비트 단위 오류 검출을 위한 핵심 요소이며, 일종의 “데이터 봉인” 역할을 한다.
2) Counter
매 송신 시 증가하는 시퀀스 번호이다.
주요 역할:
- 데이터 누락 감지
- 순서 뒤바뀜 검출
- 중복 프레임 감지
3) Data ID
해당 데이터가 올바른 송신자에서 온 것인지 식별하는 값이다.
다른 메시지와 혼동되는 것을 방지한다.
5. E2E가 보장하는 3가지 핵심 기능
E2E는 단순 CRC 검사가 아니라 다음 3가지를 함께 보장한다.
1. Integrity (무결성) → CRC 검증
2. Sequence (순서 보장) → Counter 비교
3. Freshness (최신성 보장) → Counter 기반 stale 데이터 차단
즉 “정상 데이터 + 최신 데이터”만 Application에 전달하는 구조이다.
6. Receiver 측 동작 로직 (실무 핵심)
수신 ECU에서는 E2E 검증 결과에 따라 데이터 처리 여부가 결정된다.
주요 검증 과정
CRC mismatch → 데이터 폐기
Counter jump → 패킷 손실 판단
Counter rollback → 재시작 또는 재동기화
정상 → Application 전달
E2E 상태 값
검증 결과는 단순 PASS/FAIL이 아니라 상태로 반환된다.
typedef enum
{
E2E_P_OK = 0x00U,
E2E_P_REPEATED = 0x01U,
E2E_P_WRONGSEQUENCE = 0x02U,
E2E_P_ERROR = 0x03U,
E2E_P_NOTAVAILABLE = 0x04U,
E2E_P_NONEWDATA = 0x05U
} E2E_PCheckStatusType;
E2E_P_OK → 정상 데이터, Application 사용 가능
E2E_P_REPEATED → 이전 프레임 재수신 (중복 데이터)
E2E_P_WRONGSEQUENCE → Counter 불연속 발생 (패킷 유실 또는 순서 깨짐 가능성)
E2E_P_ERROR → CRC 실패 또는 데이터 무결성 손상
E2E_P_NOTAVAILABLE → 초기화 직후 또는 통신 데이터 미수신 상태
E2E_P_NONEWDATA → 새로운 데이터 없음 (이전 값 유지 상태)
Application에서는 이 상태를 기반으로 데이터 사용 여부를 결정한다.
7. E2E Profile 개념
E2E Profile은 다양한 통신 환경에 맞게 사전 정의된 보호 템플릿이다.
중요한 개념은 다음과 같다.
Profile = 통신 환경별 설정 템플릿
CRC 길이, Counter 크기, 데이터 보호 방식이 포함됨
CAN / CAN FD / Ethernet 환경에 따라 선택됨

위 그림에서 볼 수 있듯이 E2E Profile은 데이터 보호를 위한 CRC, Counter 등의 구성 방식과 강도를 정의한 “보호 템플릿”이다.
Profile 1, 5, 7은 각각 통신 환경과 데이터 요구사항에 따라 서로 다른 수준의 보호 기능을 제공한다.
Profile 1: CAN 환경에서 주로 사용되며, 비교적 낮은 오버헤드와 기본 수준의 데이터 보호를 제공한다.
Profile 5: CAN FD 등 중간 용량 데이터에 적합하며, 향상된 CRC 및 Counter 구조를 통해 더 높은 신뢰성을 제공한다.
Profile 7: Ethernet 기반 대용량 데이터 통신에 사용되며, 가장 강력한 오류 검출 능력을 가진 구조를 제공한다.
즉 Profile은 “통신 버스 전용 규격”이 아니라, 데이터 특성과 안전 요구 수준에 따라 선택되는 E2E 보호 구성 세트이다.
※ 실제 프로젝트에서는 Profile 자체보다 “설정 값 조합”이 더 중요하다.
8. 개발 실무 적용 방법 (Mobilgene 기준)
AUTOSAR 환경에서는 E2E 로직을 직접 구현하지 않는다.
개발자는 다음만 설정한다.
- E2E Profile 선택
- Data ID 설정
- Signal / PDU 매핑
- Counter / CRC offset 설정
이후 E2E Library가 자동으로 다음을 처리한다.
- CRC 생성
- Counter 증가
- 수신 검증
- 상태 반환
즉 E2E는 “설정 기반 자동 보호 기능”이다.
정리
E2E Protection은 차량 통신에서 데이터 신뢰성을 확보하기 위한 기본적인 안전 메커니즘이다.
핵심은 통신 경로를 신뢰하지 않고, 수신 측에서 데이터의 유효성을 최종 판단한다는 점이다.
즉, E2E는 데이터가 변조되지 않았는지 (Integrity), 순서가 올바른지 (Sequence), 최신 데이터인지 (Freshness)
이 세 가지를 기준으로 데이터를 검증하고, 조건을 만족한 경우에만 Application에서 사용할 수 있도록 한다.
결과적으로 E2E는 “잘못된 데이터가 Application 로직에 반영되는 것을 구조적으로 차단하는 검증 계층”이다.
'AUTOSAR' 카테고리의 다른 글
| AUTOSAR 통신 제어 구조 완전 정리: ComM, CanSM, CanNm, BswM 역할 이해 (0) | 2026.04.27 |
|---|---|
| AUTOSAR Runnable과 Event 관계 완전 이해 (0) | 2026.04.23 |
| AUTOSAR Rte_Read / Rte_Write / Rte_Call 차이 완벽 정리 (실무 + 공식 Spec 기준) (0) | 2026.04.22 |
| AUTOSAR Port Interface 종류 총정리 (SenderReceiver / ClientServer 쉽게 이해하기) (0) | 2026.04.21 |
| AUTOSAR Composition SWC란 무엇인가? 실무자가 반드시 알아야 할 계층 설계 구조 (0) | 2026.04.20 |