AUTOSAR Classic Platform은 AUTOSAR가 펴내는, 깊이 임베디드된 ECU를 위한 표준이다. 이런 ECU의 소프트웨어는 입력 신호와 다른 ECU의 정보를 바탕으로 전기 출력 신호를 제어한다.[1] Classic Platform은 소프트웨어를 마이크로컨트롤러 위에서 도는 응용 계층, RTE, BSW(Basic Software) 세 계층으로 나눈다. 응용 소프트웨어는 RTE를 거쳐 다른 소프트웨어 컴포넌트와 통신하고 BSW에 접근하며, RTE가 응용에 대한 인터페이스 전체다.[2]
범위
Classic Platform의 대상은 실시간 요구가 마이크로초 수준으로 높고, 안전 중요도가 ASIL D까지 높으며, 연산 능력은 약 1000 DMIPS(Dhrystone Million Instructions Per Second)로 낮은 ECU다.[3] 계층의 구성은 AUTOSAR 계층 구조에서, 설정과 코드 생성의 흐름은 AUTOSAR 방법론에서 다룬다.
Classic Platform의 운영체제인 AUTOSAR OS는 핵심 기능을 OSEK OS에 두고, OSEK OS의 기능 일부를 제한하거나 확장한다. AUTOSAR OS는 정적으로 설정되고 규모가 정해지며, 우선순위 기반 스케줄링 정책을 둔다.[4]
RTE 생성기가 만든 RTE 코드는 다른 BSW 모듈, 소프트웨어 컴포넌트의 코드와 함께 컴파일되고 링크된다. 멀티코어 ECU에서는 RTE를 한 이미지로 링크할 수도 있고, 코어마다 이미지를 나눌 수도 있다.[5]
AUTOSAR 소개 자료에 따르면 Classic Platform의 AUTOSAR 스택은 여러 벤더가 내놓는다.[3] BSW 모듈은 자기 구현의 벤더 ID를 AUTOSAR 벤더 목록에 따라 <MIP>_VENDOR_ID로 공개한다.[6] 벤더 ID는 AUTOSAR 제품을 파는 회사가 신청하면 AUTOSAR가 내주며, AUTOSAR 누리집은 할당한 벤더 ID와 회사 이름의 목록을 공개한다.[7]
BSW 설정을 어느 단계에서 하는지는 AUTOSAR 방법론에서 다룬다.
개정 이력
AUTOSAR는 2003년 결성 때부터 3년씩 이어지는 세 계약 단계로 일했다. Phase I은 2006년에 첫 규격 묶음을 내고 끝났고, Phase II는 2009년에 Release 3.1과 4.0을 내고 끝났으며, Phase III는 Release 4.0.3을 냈다. AUTOSAR는 Phase III 계약이 2012년 말에 끝난 뒤로는 기한을 정한 단계 대신 끝나는 날을 두지 않는 연속 작업 방식으로 가기로 했다.[8]
- 2005년 5월: 첫 릴리스인 Release 1.0이 나왔다.[9]
- 2006년: Release 2.0(5월)과 Release 2.1(11월)이 나왔다.[9] Release 1.0이 주로 RTE 아래 BSW의 일부를 다룬 뒤, AUTOSAR는 BSW 구성요소를 더하고 RTE를 구현하는 데 힘을 쏟았다.[10] Release 2.0의 명세는 운영체제, 통신, 하드웨어 추상화, RTE를 정의했고, AUTOSAR는 Release 2.1로 표준의 모듈 명세 부분이 완성된다고 밝혔다.[11] Release 2.1에는 진단 모듈 Dcm(Diagnostic Communication Manager)과 Dem의 규격이 이미 들어 있었다.[12]
- 2007년 12월과 2008년 8월: Release 3.0과 Release 3.1이 나왔다.[9]
- 2009년 12월: Release 4.0이 나왔다.[9] 기능 안전 개념과 멀티코어 아키텍처 개념을 새로 넣고, Ethernet 드라이버·인터페이스·State Manager 규격을 담았다. 새 기능 안전 개념에는 메모리 분할, 프로그램 흐름 감시, E2E(End-to-End) 통신 보호 등이 든다.[13]
- 2011년 5월: 3.x 계열의 Release 3.2가 Release 4.0보다 뒤에 나왔다. 3.1을 바탕으로 Partial Networking 같은 기능을 더하고, 4.0에 있던 기능 일부(E2E 통신 보호 등)를 역이식했다.[9][14]
- 2013년 3월: Release 4.1.0이 AUTOSAR Timing Concept, Ethernet Partial Networking, 응용이 TCP/IP로 통신하는 소켓 인터페이스, 대형 상용차와 J1939 지원 등을 새로 넣었다.[15]
- 2014년 6월: 인수 시험이 Classic Platform 릴리스와 따로 Acceptance Test Release 1.0.0으로 나왔다.[9]
- 2014년 10월: Release 4.2.1이 이더넷과 CAN FD로 큰 데이터를 주고받는 통신(이더넷 스위치 지원 등)과 safety·security 개선에 집중했다.[16]
- 2016년 11월: Release 4.3.0이 Crypto Interface와 Crypto Driver로 암호 스택을 완성하고, V2X(Vehicle-to-X) 통신을 처음 지원했다.[17]
- 2018년 10월: Release 4.4.0이 나왔다.[9] 번호로 이름을 붙인 마지막 Classic Platform 릴리스다.[18]
- 2019년 11월: 릴리스 이름을 Ryy-mm(릴리스의 연도와 월) 꼴로 바꿔 R19-11이 나왔다. 이때부터 Classic Platform, Adaptive Platform, Foundation을 한 AUTOSAR 릴리스로 함께 낸다. 번호는 내부 릴리스 번호로 이어져, R19-11은 R4.5.0, R25-11은 R4.11.0이다.[18]
- 2020년 11월: R20-11이 IdsM과 Software Cluster Connection(SwCluC)의 명세를 처음 넣었다.[19][20] R20-11의 CAN Interface 명세는 Pretended Networking을 뺐다.[21]
- 2022년 11월: R22-11이 MACsec Key Agreement(Mka), CAN XL Driver, Data Distribution Service(Dds)의 명세를 처음 넣었다.[22][23][24]
- 2023년 11월: R23-11이 Firewall과 L-SDU(Link Layer Service Data Unit) Router(LSduR)의 명세를 처음 넣었다.[25][26]
- 2024년 11월: R24-11이 I2C(Inter-Integrated Circuit) Driver의 명세를 처음 넣었다.[27] R24-11의 LSduR 명세는 LSduR를 모든 통신 인터페이스 모듈 위에 반드시 두는 층으로 정했다.[26]
- 2025년: 현행 릴리스 R25-11이 나왔다.[2] R25-11 문서는 2025년 11월 27일 자로 나왔고, R25-11은 R24-11을 대체하는 Evolution 단계의 minor release다. 새 개념으로 VDP(Vehicle Data Protocol), COM Handler, Classic Platform의 DDS(Data Distribution Service)에 서비스 지향 아키텍처 기능을 더하는 개념이 들어왔다. COM Handler는 Large Data COM(LdCom)의 기능을 COM에 합쳤고, CAN 시간 동기화 명세는 순수 프로토콜을 담은 Foundation의 PRS(Protocol Specification)와 AUTOSAR 안에서의 구현을 정하는 명세로 나뉘었다. Flash Driver, EEPROM(Electrically Erasable Programmable Read-Only Memory) Driver, LdCom, TTCAN(Time-Triggered CAN) Driver, TTCAN Interface의 명세와 Franca 통합 TR이 빠졌고, V2X와 무선 이더넷 드라이버의 명세는 obsolete가 되었다. VFB 문서는 문서 종류가 EXP(Explanation)에서 TR로 바뀌었다. R25-11의 스키마 버전은 AUTOSAR_00054다.[18]
Adaptive Platform과의 차이
AUTOSAR Adaptive Platform은 Classic Platform을 대체하지 않고, Classic Platform, 비AUTOSAR 플랫폼과 함께 동작하며 하나의 시스템을 이룬다.[1]
| 항목 | Classic Platform | Adaptive Platform |
|---|---|---|
| 통신 | CAN 같은 기존 차량 내 통신 기술에 맞춰 설계·최적화됐고, 이더넷도 지원한다. 시그널 기반 COM 스택이 CAN, LIN, FlexRay에서 오는 PDU(Protocol Data Unit)를 다룬다. | 서비스 지향 아키텍처를 따르고[1], 통신을 서비스 지향 통신으로 한정한다.[28][29] |
| 스케줄링 | OSEK OS의 고정 우선순위 스케줄링을 쓰고, 멀티코어에서도 태스크를 코어에 동적으로 배정하지 않는다. | 운영체제가 POSIX 스케줄링 정책 SCHED_OTHER, SCHED_FIFO, SCHED_RR을 지원해야 하고, 응용 벤더는 SCHED_DEADLINE 같은 정책을 더할 수 있다.[4][30] |
| 운영체제 | 운영체제로 AUTOSAR OS를 정한다. | 새 운영체제를 정하지 않고, 응용이 POSIX PSE51(IEEE 1003.13) 함수와 C++ 표준 라이브러리를 쓰는 실행 문맥과 인터페이스를 정한다.[4][30] |
| 프로그램 실행 | AUTOSAR가 대상으로 하는 ECU는 내부나 외부 플래시 메모리에서 프로그램을 실행한다. | Process는 Executable을 메모리에 올린 인스턴스이고, Execution Management가 시작하고 끝낸다. Process가 쓰는 RAM에는 코드도 든다.[28][31] |
| 주소 공간 | AUTOSAR OS는 멀티코어에서 적어도 공유 부분은 단일 주소 공간이라고 가정하고, memory protection에 하드웨어 MPU(Memory Protection Unit)를 요구한다. | 운영체제가 각 Process를 전용 주소 공간에서 실행하고, 이 주소 공간은 가상화된다.[4][30] |
Adaptive Platform에 대해서는 AUTOSAR가 규격을 내부 구현인 Adaptive Platform Demonstrator로 함께 검증하고 구현 CAPI(Common Adaptive Platform Implementation)를 내놓았으며, 그 이력은 AUTOSAR Adaptive Platform에서 다룬다.[32][33] Classic Platform 쪽으로는 AUTOSAR가 CAN으로 이은 ECU 두 개로 된 워크플로 예제의 산출물을 ZIP으로 내놓고, 요청하면 응용 소프트웨어의 C 소스 코드도 준다.[2]