4.4.0
4.4.0 baseline에서 application과 platform의 경계를 이해하는 상황
Classic에서는 SWC, RTE, BSW와 ECU configuration의 관계가 중요하다. Release는 표준 문서 집합의 기준이며 공급사 package와 generator의 버전은 별도다. 기능의 이름과 실제 지원 interface를 구분하면 version 변경의 영향을 구체적으로 설명할 수 있다.
4.0.3 → 4.2.2 → 4.4.0 구조 비교
4.0.3·4.2.2·4.4.0의 비교 축은 Communication Stack, Crypto Stack, Partition과 ECU Configuration이다.
세 버전 모두 Classic Platform의 Application / RTE / BSW 계층을 공유한다. 4.4.0은 Adaptive Platform으로 전환하는 버전이 아니다. Classic은 정적으로 구성한 ECU software와 실시간 제어를 계속 담당하며, Ethernet 기반 서비스 통신을 사용한다고 Adaptive ECU가 되는 것도 아니다.
버전별 비교 범위
| 기준 | 4.0.3 | 4.2.2 | 4.4.0 |
|---|---|---|---|
| 위치 | 초기 4.x 계열의 기준점 | 4.0 계열 이후 확장된 network·보안·설정 모델을 비교하는 기준점 | 4.2 이후의 추가 변경을 포함한 후속 기준점 |
| 공통 구조 | SWC, RTE, BSW와 ECU Configuration | 공통 계층을 유지하면서 모듈 및 설정 정의 확장 | 공통 계층을 유지하면서 서비스·보안 등 상세 모델 발전 |
| 비교 항목 | 기존 프로젝트가 전제한 API와 설정 구조 | 4.0.3 대비 달라진 기능과 책임 경계 | 4.2.2의 기능을 계승한 부분과 후속 구조 변경 구분 |
| 버전 해석 | 표준 baseline과 공급사 구현 버전을 별도로 기록 | CAN FD·SecOC 등의 존재를 지원 완성도와 구분 | 기능 존재만으로 해당 버전에서 최초 도입됐다고 판단하지 않음 |
표준에 모듈이 정의되어 있다는 사실과 구매한 BSW package가 그 모듈을 지원한다는 사실은 다르다. MCAL, BSW, RTE generator가 서로 다른 baseline을 사용하는 공급사 조합도 있으므로 하나의 버전 숫자로 모든 구성요소를 설명할 수 없다.
큰 변화 1 — CAN 중심의 설정에서 CAN FD를 포함하는 통신 모델로
4.0.3 기반의 기존 CAN 설정과 4.2.2의 CAN FD 설정을 비교할 때는 최대 payload만 보아서는 안 된다. CAN controller의 두 bitrate 구간, CanIf의 identifier와 frame type, CanTp의 transport 설정이 함께 달라진다. CAN FD frame을 사용할 수 있는 것과 ECU의 모든 CAN traffic을 FD로 전환하는 것은 별개다.
| 비교 축 | 4.0.3 기반 프로젝트에서 출발할 내용 | 4.2.2에서 확인되는 내용 | 4.4.0 비교 항목 |
|---|---|---|---|
| Driver timing | 기존 arbitration bitrate와 controller 설정 | CanControllerFdBaudrateConfig, CanControllerFdBaudRate | CAN FD timing parameter와 controller별 제약 |
| Frame 구분 | Standard / Extended identifier 중심의 설정 | STANDARD_FD_CAN, EXTENDED_FD_CAN 등의 enum | Identifier 폭과 Classical / FD frame 구분은 서로 다른 축이다. |
| Transport | Classical CAN에서의 diagnostic segmentation | CANTP_CANFD_PHYSICAL, CANTP_CANFD_FUNCTIONAL | CAN controller의 FD 지원과 CanTp의 FD 사용 조건을 별도로 이해한다. |
| Payload | Classical CAN의 최대 8-byte payload | CAN FD에서는 최대 64-byte payload를 사용하며 DLC 매핑도 달라짐 | 큰 frame, I-PDU 길이, transport segmentation을 같은 개념으로 취급하지 않는다. |
표의 FD parameter와 enum은 4.2.2 ECUC definition에 정의되어 있다.
큰 변화 2 — Crypto Service와 통신 보호의 책임 분리
Security를 한 모듈의 기능으로 묶으면 릴리스 간 차이가 잘 보이지 않는다. Crypto Service는 암호 연산을 제공하고, SecOC는 보호할 PDU의 authenticity와 freshness를 다룬다. Hardware key storage와 HSM driver는 다시 별도의 구현 영역이다.
| 비교 대상 | 4.2.2 기준 구조 | 4.4.0 구조 | 달라지는 관점 |
|---|---|---|---|
| Crypto service | Csm과 Cal 정의가 존재 | Csm / CryIf / Crypto Driver 구조 | Service 요청, crypto implementation 선택, 실제 연산 수행 책임을 구분한다. |
| 실행 모델 | 기존 Csm service별 configuration과 callback 모델 | Crypto Job, queue, key와 driver object의 관계 | 함수 이름만 대응시키기보다 요청·처리·완료 통지의 모델 차이를 이해한다. |
| Key | 서비스가 사용하는 key 관련 설정과 구현 제약 | Key와 key element, driver 측 key 접근의 구분 | Key ID는 비밀키 자체가 아니며, 논리 ID와 hardware 저장 위치도 같지 않다. |
| PDU 보호 | 4.2.2에 SecOC와 freshness 관련 정의가 이미 존재 | 후속 릴리스의 SecOC와 Crypto Stack 연결 | SecOC와 Crypto Stack 사이의 interface |
| HSM | 공급사와 MCU의 crypto 구현에 의존 | Crypto Driver가 hardware 구현을 추상화할 수 있음 | AUTOSAR 버전 상승이 HSM 장착이나 Secure Boot 지원을 자동으로 보장하지 않는다. |
SecOC는 일반적인 의미의 payload 암호화와 동의어가 아니다. MAC과 freshness를 이용한 authenticity / integrity / replay protection의 목적을 encryption과 구분해야 한다. E2E protection의 safety 목적 역시 SecOC의 security 목적과 다르다.
4.0.3의 세부 Crypto API와 key 모델은 해당 버전의 Csm·Cal 문서를 기준으로 읽어야 한다. 4.2.2에서 확인한 parameter 이름이나 후속 Crypto Job 모델을 4.0.3에 그대로 적용하지 않는다.
큰 변화 3 — Ethernet 연결과 Service-Oriented Communication 구분
Ethernet driver, IP 통신, SOME/IP, Service Discovery는 서로 다른 계층이다. Ethernet이 존재한다는 사실만으로 SOME/IP service를 제공하는 것은 아니다. 반대로 Ethernet·DoIP를 모두 4.4.0의 신규 protocol로 설명하는 것도 적절하지 않다.
| 영역 | 책임 | 4.2.2 원문에서 확인되는 모듈 | 4.4.0 비교의 초점 |
|---|---|---|---|
| Ethernet hardware | Frame 송수신, transceiver와 switch 제어 | Eth, EthIf, EthTrcv, EthSwt | Hardware 접근과 상위 service 모델의 경계를 유지한다. |
| IP / socket | IP stack과 socket 기반 PDU 연결 | TcpIp, SoAd | Socket connection과 PDU route의 관계를 읽는다. |
| Discovery | Service의 offer / find와 event group subscription | Sd | Service discovery를 단순한 IP address 탐색과 구분한다. |
| SOME/IP | Service message와 데이터 표현 | Sd의 존재만으로 SOME/IP 관련 모든 세부 규격을 확인한 것은 아님 | Protocol, transformer, discovery 및 큰 message 전송의 상세 규격을 분리한다. |
| Diagnostics over IP | IP network에서의 diagnostic 접근 | DoIP | DoIP transport와 Dcm의 UDS service 처리는 다른 책임이다. |
| Time synchronization | Network time과 ECU time base의 연결 | StbM, EthTSyn, CanTSyn, FrTSyn | 동기화 protocol과 time base 소비자의 역할을 구분한다. |
4.0.3과 비교할 때는 단순히 Ethernet 지원 여부만 표시하기보다 사용하려는 service model과 해당 SWS의 존재·범위를 비교해야 한다. 4.4.0에서도 SOME/IP 통신은 Classic의 정적 SWC/RTE 구성 위에서 이해할 수 있으며 Adaptive의 실행·배포 모델과 동일하지 않다.
큰 변화 4 — Multi-core와 Partition을 구별하는 구조
Core, OS Application, ECU Partition, BSW 배치, RTE 통신은 서로 다른 구성 단위다. Configuration은 이들 사이의 mapping과 호출·접근 제약을 정의한다.
| 개념 | 설명 | 혼동하기 쉬운 부분 |
|---|---|---|
| Core | 실제 CPU 실행 자원 | Core가 여러 개라고 모든 BSW가 병렬 실행되는 것은 아니다. |
| OS Application | OS object의 소속과 protection 단위 | Task 하나 또는 CPU core 하나와 일대일인 개념이 아니다. |
| ECU Partition | Software 배치와 분리의 configuration 단위 | OS Application 및 core mapping과의 관계를 별도로 읽는다. |
| RTE / IOC | Runnable과 data communication, inter-OS-application communication | 단일 core의 직접 접근 모델을 core 간 공유에 그대로 적용하지 않는다. |
| Spinlock | Multi-core resource 접근을 위한 OS synchronization mechanism | Interrupt disable과 같은 보호 범위로 해석하지 않는다. |
| BSW 배치 | BSW module의 실행 위치, 호출 경로와 partition 관계 | Module을 여러 core에서 복제해도 된다는 뜻이 아니다. |
4.2.2에는 partition 관련 reference와 OS 관련 정의가 이미 존재한다. 4.4.0 비교는 기능의 단순 유무보다 module별 partition 지원 범위와 호출·배치 제약을 중심으로 읽는 것이 적절하다.
Diagnostic와 Mode Management에서 이어지는 책임
| 모듈 | 버전이 달라도 유지되는 핵심 책임 | 릴리스 차이를 읽을 항목 |
|---|---|---|
| Dcm | Diagnostic protocol과 UDS service 처리 | Service별 지원 범위, session / security 조건, callback과 configuration 정의 |
| Dem | Diagnostic event와 DTC 상태·데이터 관리 | Event memory, status 처리, data record 및 Dcm과의 interface |
| FiM | Diagnostic 상태를 바탕으로 function permission 제공 | Dem event와 inhibition configuration의 관계 |
| BswM | Mode request와 indication을 규칙·action으로 연결 | Rule 조건과 action 종류, 다른 manager와의 연결 |
| EcuM | ECU lifecycle 및 startup / shutdown 관련 책임 | Wakeup source, state와 BswM의 책임 경계 |
| ComM / CanSM / CanNm | Communication request, bus state, network management | 같은 state machine으로 합치지 않고 interface와 coordination을 비교 |
RDBI는 DID 읽기, WDBI는 DID 쓰기, SecurityAccess는 진단 접근 권한, RoutineControl은 ECU routine 실행을 담당한다. Service의 역할과 Dcm의 callback·configuration interface는 구분된다.
ECUC와 ARXML — 같은 이름이 같은 모델을 뜻하지 않는다
| 항목 | 버전 간 차이가 생기는 위치 | 해석 |
|---|---|---|
| Schema | AUTOSAR XML schema와 metamodel | XML namespace가 같아 보여도 schema revision과 허용 구조는 다를 수 있다. |
| Definition reference | Module / container / parameter definition의 경로 | 이름이 비슷하다는 이유로 reference path를 자동 대응시키지 않는다. |
| Multiplicity | LOWER / UPPER bound, infinite 여부, 조건 | [1], [0..1], [0..*]의 차이는 값 범위가 아니라 instance 개수다. |
| Variant | Pre-compile / Link-time / Post-build 관련 정의 | 모든 parameter가 모든 variant에서 변경 가능한 것은 아니다. |
| API / callback | Module interface와 generator contract | Parameter만 복사해도 소스 호환성이 확보되는 것은 아니다. |
| Vendor extension | 공급사 정의와 표준 정의의 결합 | 표준 release와 공급사 package release를 함께 기록한다. |
사이트의 Standard Explorer는 4.2.2 definition을 표시한다. 4.4.0 문서에서 Explorer를 참고하더라도 그 tree를 4.4.0 규범으로 읽어서는 안 된다. 특히 CryIf / Crypto Driver처럼 후속 구조를 설명할 때는 4.2.2의 Cal tree로 대체할 수 없다.
이해를 확인하는 질문
표준 release가 같으면 공급사 package 간 설정을 그대로 옮길 수 있을까?
Schema와 definition reference, 지원 feature·extension 및 generator contract를 함께 확인해야 한다. 같은 release 표기만으로 설정과 생성 코드의 호환성을 보장할 수 없다.