AUTOSAR (자동차 표준 소프트웨어 아키텍처)

1. 개요

가. 정의

AUTOSAR(AUTomotive Open System ARchitecture)는 차량 전자제어장치(ECU)의 소프트웨어를 하드웨어로부터 분리(decoupling)하고, 표준화된 계층 구조·인터페이스·교환 포맷으로 재사용·이식·협업을 가능케 하는 개방형 자동차 소프트웨어 플랫폼 표준이다. 2003년 BMW·Bosch·Continental·Daimler·Ford·GM·PSA·Toyota·Volkswagen 등이 결성한 개발 파트너십(development partnership)에서 출발했으며, "협력할 영역은 표준화하고, 경쟁할 영역은 차별화한다(Cooperate on standards, compete on implementation)"는 철학을 바탕으로 한다.

AUTOSAR가 등장한 배경은 차량의 급격한 '소프트웨어화'에 있다. 1990년대까지 기계·유압으로 구현되던 제동·조향·구동 기능이 전자제어로 옮겨 가면서, 고급 차량 한 대에 탑재되는 ECU가 수십~~백여 개, 소프트웨어 규모가 수천만~~1억 줄(LoC) 규모로 폭증했다. 그런데 각 ECU의 소프트웨어가 특정 마이크로컨트롤러·공급사에 강하게 결합(tightly coupled)되어 있어, 부품을 바꾸거나 기능을 다른 ECU로 옮길 때마다 소프트웨어를 사실상 새로 작성해야 하는 비효율이 누적되었다. 완성차 업체(OEM)와 1차 협력사(Tier-1), 반도체사(Tier-2)가 제각기 다른 구조로 개발하다 보니 통합·검증 비용과 리콜 위험도 커졌다.

따라서 AUTOSAR의 핵심 발상은 '애플리케이션은 하드웨어를 몰라도 되게 한다'는 하드웨어 추상화와, '부품처럼 조립 가능한 소프트웨어 컴포넌트(SWC)'라는 모듈화다. 애플리케이션 로직을 가상 함수 버스(VFB) 위의 컴포넌트로 기술하고, 그 아래 표준화된 미들웨어가 통신·메모리·진단·네트워크를 책임지도록 분리하면, 같은 기능을 다른 ECU·다른 반도체에 재배치하더라도 애플리케이션 코드를 손대지 않고 재사용할 수 있다. 이는 단순한 코드 재사용을 넘어, OEM-Tier-1-Tier-2 사이의 역할 분담과 협업 계약을 표준 인터페이스로 고정한다는 산업 거버넌스의 의미를 갖는다.

나. 두 세대의 플랫폼 — Classic과 Adaptive

AUTOSAR를 정확히 이해하려면 성격이 다른 두 플랫폼을 구분해야 한다. 2003년부터 발전해 온 Classic Platform(CP)은 제동·엔진·에어백처럼 실시간·고신뢰가 요구되는 심층 임베디드(deeply embedded) ECU를 위한 정적(static) 구조다. OSEK/VDX 기반 실시간 OS 위에서 모든 자원이 빌드 시점에 확정되며, 결정성(determinism)과 기능안전([[iso-26262]])을 최우선으로 한다. 반면 2017년 발표된 Adaptive Platform(AP)은 자율주행·인포테인먼트처럼 고성능 연산과 유연성이 필요한 고성능 컴퓨팅(HPC) ECU를 위한 동적(dynamic) 구조로, POSIX 기반 OS와 C++, 서비스 지향 아키텍처(SOA)를 채택해 실행 중 서비스 발견·OTA 업데이트를 지원한다.

이 둘을 가르는 근본 이유는 '다루는 문제의 성격'이 다르기 때문이다. 바퀴를 제어하는 소프트웨어에는 1밀리초 단위의 예측 가능한 응답과 '절대 멈추지 않음'이 생명이므로 정적 구성과 단순한 실행모델이 유리하다. 반대로 카메라 수십 개의 영상을 딥러닝으로 융합해 경로를 계획하는 소프트웨어에는 멀티코어·GPU를 활용하는 풍부한 런타임과, 기능을 지속 개선하는 업데이트 능력이 필요하다. AUTOSAR는 하나의 구조로 두 요구를 동시에 만족시키려 하지 않고, 목적이 다른 두 플랫폼을 공존시키되 공통 기반(Foundation)으로 상호운용성을 보장하는 길을 택했다. 이 분리가 바로 AUTOSAR 전체 구조를 이해하는 출발점이다.

2. 전체 구조 — Classic·Adaptive·Foundation과 방법론

AUTOSAR 표준은 세 개의 표준 묶음으로 구성된다. Classic Platform(CP), Adaptive Platform(AP), 그리고 두 플랫폼이 공유하는 공통 산출물·규약을 정의하는 Foundation(FO)이다. 여기에 더해, 소프트웨어를 어떻게 기술·구성·배포할지를 정의하는 방법론(Methodology)과, 모든 산출물을 기계가 읽을 수 있게 교환하는 XML 포맷인 ARXML(AUTOSAR XML)이 전 과정을 관통한다. 즉 AUTOSAR는 '실행 플랫폼' 둘과 '공통 규약' 하나, 그리고 이들을 묶는 '개발 방법론'으로 이뤄진 체계다.

graph TD
  subgraph STD["AUTOSAR 표준 체계"]
    FO["Foundation (FO)<br/>공통 요구·규약·프로토콜(SOME/IP 등)"]
    subgraph CP["Classic Platform (CP)"]
      CPA["심층 임베디드 ECU<br/>정적 구성·실시간·기능안전"]
    end
    subgraph AP["Adaptive Platform (AP)"]
      APA["고성능 컴퓨팅 ECU<br/>동적·SOA·OTA"]
    end
    METH["방법론 & ARXML<br/>모델 기반 기술·구성·교환"]
  end
  FO --> CP
  FO --> AP
  METH --> CP
  METH --> AP
  CP -. "SOME/IP·DDS 게이트웨이" .-> AP

위 구조도가 보여 주듯 Foundation은 두 플랫폼이 서로 통신·연동할 수 있도록 공통 프로토콜과 메타모델의 최소 교집합을 정의한다. 예컨대 서비스 지향 통신 프로토콜 SOME/IP는 Foundation에 규정되어 Classic과 Adaptive가 같은 규약으로 이더넷 상에서 서비스를 주고받을 수 있게 한다. 과거에는 각 플랫폼이 독자적으로 요구사항을 중복 정의했으나, Foundation 도입으로 한 번 정의한 공통 규약을 양쪽이 참조하게 되어 중복과 불일치를 줄이고 CP↔AP 혼합 아키텍처의 상호운용성을 확보했다.

방법론과 ARXML의 역할도 핵심이다. AUTOSAR는 코드를 직접 짜기 전에 소프트웨어 컴포넌트·포트·인터페이스·ECU 자원을 ARXML 형식의 모델로 먼저 기술하고, 이 모델로부터 RTE·통신 스택 구성 코드를 자동 생성한다. 실제 양산 프로젝트에서 OEM은 시스템 설계를 ARXML로 Tier-1에 전달하고, Tier-1은 이를 받아 ECU 구성(ECU Configuration)을 세분화하며, 반도체사가 제공한 MCAL 설정과 합쳐 최종 바이너리를 생성한다. 이처럼 ARXML은 회사 간 설계 책임을 넘기는 계약 문서이자 자동화의 입력으로, AUTOSAR가 단순한 코드 규약이 아니라 '모델 기반 협업 방법론'임을 드러낸다.

3. Classic Platform — 계층 구조와 구성요소

Classic Platform의 뼈대는 철저한 계층화(layered architecture)다. 최상단의 애플리케이션 계층(Application Layer)에는 제동 제어·엔진 토크 관리 같은 기능 로직이 소프트웨어 컴포넌트(SWC, Software Component) 단위로 들어간다. 그 아래 런타임 환경(RTE, Runtime Environment)이 컴포넌트 사이의 통신과 하위 기본 소프트웨어 호출을 중계하며, 맨 아래 기본 소프트웨어(BSW, Basic Software)가 통신·메모리·진단·OS·드라이버를 제공하고, 최하단 마이크로컨트롤러가 이를 실행한다.

graph TD
  APP["Application Layer<br/>SWC(제동·조향 등 기능 로직)"] --> RTE["RTE (Runtime Environment)<br/>VFB 구현·컴포넌트 간 통신 중계"]
  RTE --> SVC["Services Layer<br/>OS·통신·진단·메모리·NM"]
  SVC --> ECUAL["ECU Abstraction Layer<br/>온보드 장치·드라이버 추상화"]
  ECUAL --> MCAL["MCAL<br/>Microcontroller Abstraction Layer"]
  RTE -. "직접 접근" .-> CDD["Complex Device Drivers (CDD)<br/>고속·특수 하드웨어 직접 제어"]
  CDD --> MCU
  MCAL --> MCU["Microcontroller (하드웨어)"]

이 구조의 핵심 개념은 가상 함수 버스(VFB, Virtual Function Bus)다. 애플리케이션 개발자는 자신의 SWC가 어떤 ECU·어떤 통신선(CAN/LIN/FlexRay/Ethernet)에 올라가는지 모른 채, '포트(port)'를 통해 다른 컴포넌트와 논리적으로만 연결한다고 가정하고 설계한다. 실제 물리적 배치가 결정되면 RTE가 VFB를 구현(realize)하여, 같은 ECU 내부면 함수 호출로, 다른 ECU면 통신 스택을 거친 메시지로 자동 연결한다. 덕분에 '제동력 신호를 보내는 컴포넌트'를 A ECU에서 B ECU로 옮겨도 애플리케이션 코드는 바뀌지 않는다 — 이것이 AUTOSAR가 내세우는 재배치(relocatability)의 실체다.

기본 소프트웨어(BSW)는 다시 세 계층과 한 예외로 나뉜다. 가장 아래 MCAL(Microcontroller Abstraction Layer)은 특정 MCU의 레지스터·주변장치(ADC·PWM·SPI 등)를 표준 API로 감싸 상위가 반도체 종류를 모르게 한다. 그 위 ECU 추상화 계층(ECU Abstraction Layer)은 보드에 실장된 외부 소자(센서·트랜시버 등)를 추상화하고, 최상위 서비스 계층(Services Layer)은 OS·통신 관리·진단(UDS)·메모리(NvM)·네트워크 관리 같은 플랫폼 서비스를 제공한다. 다만 고속 카메라나 특수 액추에이터처럼 표준 계층의 지연을 감내할 수 없는 경우를 위해, 계층을 우회해 하드웨어를 직접 제어하는 복합 장치 드라이버(CDD, Complex Device Driver)를 예외로 허용한다. 이 'MCAL로 반도체를 추상화한다'는 설계 덕분에, OEM은 반도체 공급사를 르네사스에서 인피니언으로 바꾸더라도 상위 애플리케이션을 그대로 유지할 수 있다.

BSW 계층	역할	대표 모듈·예시	추상화 대상
Services Layer	플랫폼 서비스 제공	OS, Com, Dcm/Dem(진단), NvM, NM	하드웨어 독립 서비스
ECU Abstraction	온보드 장치 추상화	드라이버 상위 래퍼, I/O 핸들러	보드 실장 외부 소자
MCAL	마이크로컨트롤러 추상화	ADC·PWM·CAN·SPI 드라이버	MCU 내부 주변장치
CDD(예외)	표준 계층 우회 직접 제어	고속 센서·특수 액추에이터	지연 민감 하드웨어

Classic Platform의 실행 모델은 OSEK/VDX에서 유래한 정적·우선순위 기반 실시간 OS다. 태스크·이벤트·자원이 빌드 시점에 고정되고, 동적 메모리 할당을 지양하며, 메모리 보호(MPU)로 ASIL 혼재 시 간섭을 막는다. 이런 정적 성격은 자율주행 같은 유연성과는 상극이지만, "무슨 일이 있어도 10밀리초 안에 제동 명령이 나가야 한다"는 결정성·안전성 요구에는 최적이다. 실제로 승용차의 거의 모든 파워트레인·섀시·바디 ECU가 지금도 Classic Platform 위에서 동작한다.

4. Adaptive Platform — 서비스 지향 아키텍처와 동적 실행

Adaptive Platform은 Classic의 한계, 즉 '정적·단일목적·업데이트 곤란'을 정면으로 뒤집는다. 핵심 실행 환경은 ARA(AUTOSAR Runtime for Adaptive Applications)로, POSIX(PSE51 프로파일) 기반 OS 위에서 C++로 작성된 애플리케이션이 기능 클러스터(Functional Cluster)가 제공하는 표준 API를 호출하며 동작한다. 멀티코어·가상메모리·동적 적재를 전제로 하므로, 카메라·라이다 융합이나 고화질 인포테인먼트처럼 연산량이 큰 작업을 다룰 수 있다.

graph LR
  subgraph APP["Adaptive 애플리케이션 (C++)"]
    A1["지각(Perception)"]
    A2["경로계획(Planning)"]
  end
  subgraph ARA["ARA: 기능 클러스터"]
    COM["ara::com<br/>서비스 지향 통신"]
    EXEC["ara::exec<br/>실행 관리·상태"]
    UCM["ara::ucm<br/>OTA 업데이트"]
    DIAG["ara::diag / per / crypto"]
  end
  OS["POSIX OS (PSE51)"]
  A1 --> COM
  A2 --> COM
  A1 --> EXEC
  COM -->|"SOME/IP · DDS"| NET["차량 이더넷 백본"]
  EXEC --> OS
  UCM --> OS
  DIAG --> OS

Adaptive의 가장 큰 패러다임 전환은 서비스 지향 통신(ara::com)이다. Classic이 '신호(signal)'를 고정된 경로로 주기 전송하는 방식이라면, Adaptive는 서비스 제공자가 서비스를 등록하고 소비자가 실행 중 이를 발견(service discovery)해 연결하는 방식이다. 전송 계층으로는 Foundation이 규정한 SOME/IP(Scalable service-Oriented MiddlewarE over IP)나 DDS(Data Distribution Service)를 사용한다. 이 동적 결합 덕분에, 예컨대 신규 센서 융합 서비스를 OTA로 추가하면 기존 소비자들이 재컴파일 없이 그 서비스를 발견·구독할 수 있다. 즉 '배선처럼 고정된 통신'에서 '인터넷 서비스처럼 느슨하게 결합된 통신'으로의 전환이 Adaptive의 본질이다.

실행 관리(ara::exec)와 업데이트 관리(ara::ucm)도 Classic에는 없던 능력이다. ara::exec는 애플리케이션의 시작·종료·상태전이(Machine State·Function Group)를 관리해, 주행 중에도 필요한 기능 집합만 적재·전환할 수 있게 한다. ara::ucm은 무선 업데이트(OTA)를 표준화해, 테슬라가 보여 준 '차량 기능의 지속 개선' 모델을 전통 OEM도 구현할 수 있게 한다. 실제로 폭스바겐의 소프트웨어 자회사 CARIAD, BMW·메르세데스의 차세대 OS, 현대차그룹의 SDV 전략이 모두 Adaptive Platform(또는 그 변형)을 고성능 존(zonal)·중앙 컴퓨팅 아키텍처의 기반으로 채택하고 있다.

다만 이 유연성은 기능안전·결정성과의 긴장을 낳는다. POSIX의 동적 스케줄링과 가상메모리는 Classic의 정적 결정성만큼 '최악 실행시간(WCET)'을 보장하기 어렵다. 그래서 Adaptive는 ASIL B 수준까지의 안전을 목표로 하면서, 결정적 이더넷([[tsn]])·안전 인증 하이퍼바이저·실행 격리로 부족분을 메운다. 요컨대 Adaptive는 '성능과 유연성을 얻는 대신 결정성 증명이라는 새 숙제를 떠안은' 플랫폼이며, 그래서 당분간은 제동·조향 같은 최고 안전등급 기능은 Classic이, 인지·계획·HMI는 Adaptive가 담당하는 역할 분담형 공존이 현실적 해법이다.

5. Classic vs Adaptive 비교와 개발 방법론

두 플랫폼의 차이는 단순한 기술 선택이 아니라 '어떤 안전·성능·수명주기 요구에 응답하느냐'의 차이에서 비롯된다. 아래 비교는 항목 나열이 아니라, 각 차이가 왜 생기는지를 함께 읽어야 한다.

구분	Classic Platform(CP)	Adaptive Platform(AP)	차이가 생기는 이유
대상 ECU	심층 임베디드(수백 KB~MB)	고성능 컴퓨팅(GB급 메모리)	제어 vs 인지·연산
OS	OSEK 기반 RTOS	POSIX(PSE51)	결정성 vs 풍부한 런타임
언어	주로 C	C++(14 이상)	모듈성·객체지향 요구
구성 시점	정적(빌드 타임 고정)	동적(런타임 적재·발견)	안전성 vs 유연성
통신	신호 기반(CAN/LIN/FlexRay)	서비스 지향(SOME/IP·DDS)	고정 경로 vs 느슨한 결합
업데이트	전체 플래싱(정비소)	OTA(ara::ucm)	폐쇄계 vs 지속 개선
안전등급	ASIL D까지	주로 ASIL B(보완 설계로 상향)	결정성 확보 난이도

이 비교에서 가장 실무적 함의가 큰 지점은 업데이트 모델과 통신 방식이다. Classic의 전체 플래싱은 '검증된 바이너리를 통째로 교체'하므로 안전하지만, 작은 버그 하나를 고치려 해도 정비소 입고가 필요해 수백만 대 리콜 비용으로 이어진다. 반면 Adaptive의 OTA는 기능을 원격으로 개선해 리콜을 소프트웨어 패치로 대체하지만, 변조된 펌웨어가 안전기능을 손상시키지 않도록 [[secure-boot]]·서명 검증·롤백 같은 보안 설계가 반드시 동반되어야 한다. 즉 유연성과 보안 책임이 함께 커진다.

개발 방법론 측면에서 AUTOSAR는 모델 기반·역할 분담 워크플로를 표준화했다. 개략적으로 OEM이 시스템 수준에서 SWC·포트·인터페이스를 설계해 ARXML로 배포하면, Tier-1이 이를 ECU에 매핑(SWC-to-ECU mapping)하고 BSW를 구성하며, RTE 생성기가 통신 접착 코드를 자동 생성한다. 실제 양산에서는 Vector(DaVinci·MICROSAR), ETAS, EB(Elektrobit) 같은 상용 툴체인이 이 ARXML 모델을 입력받아 수천 개 BSW 파라미터를 구성하고 코드를 생성한다. 이처럼 '모델을 교환하고 코드를 생성'하는 방식은 수십 개 ECU·수십 개 공급사가 얽힌 대규모 프로젝트에서 일관성·추적성·자동화를 확보하는 유일하게 현실적인 방법이며, 동시에 ARXML 상호운용성·툴 종속이라는 새로운 관리 과제를 남긴다.

6. 심화 — 최신 동향(SDV 시대의 AUTOSAR)

AUTOSAR는 매년 11월 'Rxx-11' 형식으로 정기 릴리스를 낸다. 가장 최신인 R25-11(2025년 말 공개)은 Classic·Adaptive·Foundation 세 표준에 걸쳐 약 1,900건의 반영 작업을 포함했으며, 공개 발표에서 차량 데이터 프로토콜(Vehicle Data Protocol), 보안 강화, Classic Platform의 DDS 지원, Classic Platform을 위한 Rust 적용 전망, 공통 Adaptive 구현(CAPI, Common Adaptive Platform Implementation) 등이 주요 주제로 다뤄졌다(세부 변경은 공식 릴리스 개요 문서 참조). 직전 R24-11(2024)이 약 2,400건의 작업과 35만 줄 이상의 Adaptive 코드를 반영한 것과 비교하면, 최근 릴리스는 기능 추가보다 보안·메모리 안전·플랫폼 통합의 내실화로 무게중심이 이동하고 있음을 읽을 수 있다.

가장 주목할 동향은 소프트웨어 정의 차량(SDV, Software Defined Vehicle)과의 결합이다. 수십 개 ECU로 분산되던 기능이 소수의 고성능 중앙·존(zonal) 컨트롤러로 통합되면서, 하나의 하드웨어에서 ASIL D 제어와 QM급 인포테인먼트가 공존하는 혼합중요도(mixed-criticality) 환경이 보편화되고 있다. 여기서 AUTOSAR는 Adaptive로 고성능 영역을, Classic으로 안전 영역을 담당하되, 하이퍼바이저와 [[tsn]] 같은 결정적 네트워크로 두 세계를 격리·연결하는 하이브리드 아키텍처를 제시한다. 실제로 CAPI 같은 공통 구현 이니셔티브는 OEM마다 제각각이던 Adaptive 구현을 수렴시켜, 차량 소프트웨어의 '안드로이드식 공통 기반'을 지향한다.

두 번째 동향은 메모리 안전과 Rust의 부상이다. Classic Platform이 수십 년간 C에 의존해 온 결과, 메모리 오류([[memory-safety]])로 인한 잠재 결함이 누적되어 왔다. R25-11에서 Classic Platform에 대한 Rust 적용 전망이 공식 의제로 다뤄진 것은, 자동차 산업이 안전·보안의 근본 수단으로 메모리 안전 언어를 진지하게 검토하기 시작했음을 보여 준다. 세 번째는 보안-안전 공동설계로, 커넥티드카에서 사이버 공격이 곧 안전 위협이 되면서 ISO/SAE 21434(사이버보안)·UNECE WP.29 R155/R156(CSMS/SUMS)과 AUTOSAR의 암호·보안 모듈(ara::crypto, SecOC)이 유기적으로 결합되고 있다. 예상 출제 방향으로는 "SDV 전환기 Classic·Adaptive 하이브리드 아키텍처의 설계 방안", "AUTOSAR 기반 OTA의 기능안전·사이버보안 통합 전략" 같은 융합형 논제가 유력하다.

7. 고려사항 및 시사점

적용 전략 — 플랫폼 혼합과 점진적 전환: 당장 모든 기능을 Adaptive로 옮기는 것은 비현실적이다. 제동·조향 등 ASIL D 기능은 검증된 Classic에 유지하고, 인지·계획·HMI·OTA처럼 유연성이 필요한 영역부터 Adaptive를 도입하는 역할 분담형 하이브리드 전환이 현실적이다. 기술사는 기능별 안전등급·실시간 요구·업데이트 주기를 축으로 어떤 기능을 어느 플랫폼에 배치할지(mapping)를 설계하는 안목을 갖춰야 한다.
트레이드오프 — 표준화 이득 vs 복잡성·툴 종속 비용: AUTOSAR는 재사용·협업·추적성이라는 큰 이득을 주지만, 수천 개 BSW 파라미터 구성, ARXML 모델 관리, 상용 툴체인(Vector·ETAS·EB) 종속, 가파른 학습곡선이라는 비용을 수반한다. 소규모·단순 ECU에는 오히려 과한 오버헤드일 수 있으므로, 도입 규모와 조직 역량에 맞춘 비용-효익 판단이 필요하다.
전망 — SDV·중앙집중 아키텍처로의 수렴: 차량이 '바퀴 달린 컴퓨터'로 진화하면서, AUTOSAR는 분산 ECU 표준에서 중앙 컴퓨팅·존 아키텍처의 소프트웨어 기반으로 역할이 확장되고 있다. OTA·서비스 지향 통신·공통 구현(CAPI)이 보편화되면, 하드웨어 생애주기와 소프트웨어 생애주기가 분리되어 '출고 후에도 계속 좋아지는 차'가 표준이 될 것이다.
연계 기술 — 안전·보안·네트워크의 통합: AUTOSAR는 단독으로 완결되지 않는다. [[iso-26262]]·[[sotif-iso-21448]]의 기능안전, ISO/SAE 21434의 사이버보안, [[tsn]]의 결정적 네트워크, [[secure-boot]]·[[memory-safety]]의 보안 기반과 유기적으로 결합되어야 비로소 안전한 SDV가 성립한다. 기술사는 AUTOSAR를 개별 기술이 아니라 이들 표준을 엮는 통합 아키텍처의 중심축으로 바라봐야 한다.
조직·거버넌스 — 공급망 협업과 모델 관리 체계: AUTOSAR의 진가는 OEM-Tier-1-Tier-2가 ARXML로 설계 책임을 주고받는 협업 거버넌스에서 나온다. 인터페이스 변경 관리, 모델 형상관리, 툴 버전·릴리스 호환성 관리가 뒷받침되지 않으면 표준화의 이득이 통합 혼란으로 상쇄된다. 따라서 기술사는 기술 규격 이해를 넘어, 다자 협업을 지탱하는 프로세스·형상관리·계약 거버넌스까지 설계·운영하는 관점을 갖추어야 한다.

참고자료

AUTOSAR, "AUTOSAR Official Website": https://www.autosar.org/
AUTOSAR, "About AUTOSAR — History": https://www.autosar.org/about/history
AUTOSAR, "Release R25-11 is Now Available": https://www.autosar.org/news-events/detail/release-r25-11-is-now-available
AUTOSAR, "Classic Platform": https://www.autosar.org/standards/classic-platform
AUTOSAR, "Adaptive Platform": https://www.autosar.org/standards/adaptive-platform

한 줄 요약: AUTOSAR는 차량 소프트웨어를 하드웨어에서 분리해 재사용·협업·이식을 가능케 하는 개방형 자동차 SW 표준으로, 정적·실시간의 Classic Platform과 동적·서비스 지향의 Adaptive Platform을 Foundation·ARXML 방법론으로 묶어 공존시키며, SDV·OTA·보안-안전 통합 흐름 속에서 중앙집중 아키텍처의 소프트웨어 기반으로 확장되고 있다.