AutoSAR 정리

🚙 소프트웨어 플랫폼

소프트웨어 플랫폼은 소프트웨어와 하드웨어를 연결해주는 중간 계층이다.
컴퓨터에서는 OS, 드라이버 등의 소프트웨어를 통해 하드웨어에 접근하고
자동차에서는 AUTOSAR, XENON, ODIN과 같은 소프트웨어 플랫폼을 통해 접근한다. 
현재 AUTOSAR의 점유율은 약 80% 정도이고 계속 증가하는 추세이다.

구분		제어기	컴퓨터
소프트웨어	응용 SW	각 제어기별 기능 SW (ex. Auto Light, Wiper, Room Lamp, ...)	응용 SW (ex. Excel, Outlook, 프린터 기능, ...)
	SW 플랫폼	공통 기능 모듈, 표준 인터페이스 + Tool (ex. XENON, ODIN) OSEK OS, AUTOSAR	.NET 프레임워크, 윈도우 7, 리눅스 그래픽 드라이버, 오디오 드라이버
하드웨어	프로세서	MCU (ex. S12X, V850, XC2K)	CPU (ex. Intel, AMD)
	보드	ECU 보드	메인보드
외부 장치		와이퍼, 실내/외등, 멀티 Function 스위치	모니터, 키보드, 마우스

🚙 AutoSAR 란? 

AutoSAR(Automotive Open System Architecture)는1998년 독일 자동차 제조업체와 부품 공급업체가 공동으로 제작한
소프트웨어 플랫폼이다. 
자동차 소프트웨어를 개발하는 방식이 다 다르면 개발하고 연구하는데 있어 비효율 적이다. 따라서 자동차 하드웨어를 작동시키는데 필요한 여러 소프트웨어들을 표준화 한 일종의 소프트웨어 집합이다.
신뢰성 있는 소프트웨어 플랫폼 재정, ECU 소프트웨어 구조 표준화,  안정성 구축에 목적을 두고 있다.

AutoSAR 특징 

1. 표준 플랫폼 사용 
   AutoSAR에서는 표준 플랫폼과 표준 인터페이스 사용을 통해  자동차 소프트웨어 개발 및 유지보수를 통합시킨다. 
   (※ 플랫폼 : 소프트웨어가 동작하는 곳, e.g. BSW, RTE ..)
   
   
2. 하드웨어 독립성 
   AutoSAR는 하드웨어에 독립적으로 설계되어 다양한 하드웨어에서 실행 가능하다.
   이는 특정 하드웨어에 종속되지 않고 자유롭게 소프트웨어를 개발하고 재사용할 수 있음을 의미한다.
   
3. 비용 단축
   표준화된 플랫폼을 사용하기 때문에 개발 기간이 단축되고, 기존에 개발한 컴포넌트를 재사용할 수 있어
   SW 개발 비용을 절감할 수 있다.
   (※ 컴포넌트: 자동차에 사용되는 소프트웨어 및 하드웨어를 작은 기능 단위로 나눈 종합적인 용어이다.)
   
   

   하드웨어 컴포넌트	소프트웨어 컴포넌트
   1. 엔진 컴포넌트	1. 엔진 제어 유닛 (ECU)
   - 실린더, 피스톤, 크랭크샤프트, 캠샤프트	- 엔진 제어 프로그램
   - 연료 인젝터, 스로틀 밸브 등	- 연료 및 공기 흐름 제어, 진단 및 센서 통합
   2. 브레이크 시스템	2. 차량 내부 시스템
   - 브레이크 디스크, 패드, 캘리퍼 등	- 에어백 제어, 미디어, 내비게이션 시스템
   3. 전자 제어 유닛 (ECU)	3. 서스펜션 및 조향 컴포넌트
   - 엔진 컨트롤 유닛, 브레이크 컨트롤 유닛	- 서스펜션 스프링, 암, 스윙 암 등
   - 차량 시스템 감시 및 제어	- 스티어링 휠, 컬럼, 파워 스티어링 펌프
   4. 조명 및 신호 시스템	4. 전조등 및 후미등 컴포넌트
   - 헤드램프, 테일램프, 방향 지시등 등	- 전조등, 후미등, 방향 지시등 등
   5. 차체와 구조 부품	5. 기타 전장 시스템
   - 차체 프레임, 도어, 트렁크 등	- 엔진 오일, 냉각수, 변속기 오일 센서 등

AutoSAR 운영 조직 

현재 아래와 같은 조직도를 가지고 있으며 계속해서 업그레이드 해나가고 있다.

1. Core Partner (코어 파트너)
   
   • AUTOSAR의 조직 및 행정을 담당하며, 전반적인 운영을 관리하는 주체
   • AUTOSAR 표준을 주도적으로 개발하고 확장하며, 표준을 전반적으로 이끄는 역할을 수행한다. 
   • 소속 회사 : Continental, General Motors, Toyota, Volkswagen, Volvo Cars
2. Premium Partner (프리미엄 파트너)
   • Working Group에서 선도 역할을 수행하고, AUTOSAR 표준을 개선하는 데 기여한다.
   • 개선 제안 및 표준화 프로세스에 참여하여 표준의 품질을 향상시키는 역할을 한다.
   • 소속 회사 : Hyundai, BMW, Daimler, Ford, Bosch, NVIDIA
3. Development Partner (개발 파트너)
   • 전문 지식을 제공하고, 특정 기술 영역에 대한 전문성을 활용하여 AUTOSAR 표준을 개발하고 발전시킴
   • 개발된 표준을 구현하고 테스트하여 실질적인 기술적 기여를 제공
   • 소속 회사 : Vector, Elektrobit, AVL, ETAS
4. Associate Partner (어소시에이트 파트너)
   • AUTOSAR 표준을 사용하는 단체 및 기업으로, 표준을 적용하여 제품을 개발하고 사용하는 역할을 함
   • 표준 사용 경험을 피드백하고 표준을 개선하는 데 기여
   • 소속 회사 : KG Mobility, Aisin AW, Harman, Renesas, Toshiba

🚙 AutoSAR 구성

AutoSAR는 크게 세 가지 구성 요소로 이루어져 있다.

AutoSAR 구성

 

Basic Software(BSW)
엔진 제어, 브레이크 제어, 통신 제어 등과 같은 자동차의 기본적인 소프트웨어 기능을 제공하는 소프트웨어의 집합
Service Layer, EAL, MCAL, CDD로 나누어 구분된다.

1. • Service Layer
     BSW에서 가장 위에 있는 계층으로 전반적인 제어를 위한 다양한 백그라운드 기능을 제공한다.
     (e.g. 통신 서비스, 메모리 관리, 시간 관리, 진단 서비스 등)
     
   • EAL(ECU Abstration Layer)
     서비스 레이어와 MCAL 간의 인터페이스 역할을 수행을 통해 BSW 소프트웨어가 특정 ECU에서 동작하도록
     한다.
   • MCAL(Microcontroller Abstration Layer)
     MCAL은 BSW의 가장 하ㅟ에 위치하며 각종 내부 장치를 이용하기 위한 Driver들로 구성되어 있다.
     MCAL을 통해 HW에 직접 접근이 가능하다.
     
   • CDD(Complex Device Driver) 
     MCAL 위에 구축되며 Autosar 표준에 정의 되지 않은 여러가지 복잡한 Driver로 구성되어 있다.
     
     
2. Runtime Environment(RTE)
   AutoSAR RTE는 AUTOSAR에서 정의한 Run-Time Environment의 약자로, ECU 내에서 컴포넌트 간 통신과 컴포넌트 실행을 관리한다. 구체적인 기능은 아래와 같다.
   
   • 컴포넌트 간의 통신 관리
     
     • 포트와 인터페이스 연결
       RTE는 컴포넌트의 포트와 인터페이스를 연결하여 통신을 가능하게 한다.
     • 메시지 형식 및 전송 방법 정의
       RTE는 컴포넌트 간의 통신에 필요한 메시지 형식과 전송 방법을 정의한다. 
       예를 들어, JSON 형식으로 메시지를 주고 받으면 키-값 쌍의 형태로 구성되고
       전송 방법은 Autosar에서 제공하는 방법 중(e.g. TCP/UDP) 적합한 전송 방법을 선택할 수 있다. 
   • 컴포넌트의 실행 관리
     설정한 특정 Event 발생으로 인한 실행, 주기적 실행, 요청에 의한 실행 등 RTE는 필요할 때에 컴포넌트가 실행되도록 관리한다. 
   • 자원 할당
     컴포넌트의 실행에 필요한 각종 자원을 할당한다. (e.g. 네트워크 자원, 센서 정보, 액츄에이터 정보 등) 
   • 에러 처리
     RTE는 발생한 에러를 로그에 기록, 로그에는 에러의 종류, 원인, 발생 시점 등이 포함된다.
3. Application Software(ASW)
   도어 잠금, 에어컨 제어, 내비게이션 같은 사용자가 실제로 경험하는 자동차의 특정 기능을 수행하는 소프트웨어의
   집합이며 기능에 따라 어플리케이션, 액츄에이터, 센서로 구별된다.

AutoSAR 인터페이스

AutoSAR 플랫폼에서는 모든 컴포넌트 간의 통신은 각 포트에서 표준 인터페이스를 통해 이루어진다.
포트가 은행 창구이면 인터페이스는 은행 업무이다.
(※ 포트 : 데이터를 주고 받을 수 있는 네트워크 지점, P-Port 데이터 제공 창구, R-Port 데이터 요청 창구)

1. AutoSAR Interface 
   사용자의 요구 사항에 따라 필요한 기능을 정의하여 생성되는 인터페이스이다.
   은행으로 비유하면 특수 업무이다. 일반 업무와 달리 사용자가 지정한 특정한 여러 업무를 처리한다.
2. Standardized AUTOSAR Interface
   AUTOSAR 표준에 정의된 인터페이스를 사용한다.
   은행의 일반 업무이며 CAN 통신 인터페이스와 같은 일반적으로 사용하는 표준 인터페이스가 해당된다.
3. Standardized Interface
   은행의 통합 업무이며 다양한 소프트웨어 컴포넌트 간의 연결에 필요한 기능을 제공하는 일종의 통합 창구이다.  
   

AutoSAR 개발 순서

vector 제공 Autosar 개발 순서

AUTOSAR 플랫폼을 기반으로 하는 자동차 소프트웨어 개발은 크게 세 단계로 이루어진다. 

1. Configuration of the Overall System(전체 시스템 구성)
   자동차의 기능을 분석 -> ECU, 시스템 등 아키텍처 설계 -> ECU 간의 통신 방식 설계 
   순으로 전체 시스템의 구성원(ECU, 각종 컴포넌트)를 기능에 맞게 구성하는 단계이다.
2. Configuration of the individual ECU(개별 ECU 구성)
   ECU에 컴포넌트 배치 -> 컴포넌트 간의 통신 연결 -> ECU의 구성 파일 생성 
   순으로 주로 ECU의 하드웨어와 소프트웨어를 기술적으로 연결하는 단계이다. 
3. Implementation of the Software Component (컴포넌트 구현)
   컴포넌트 요구 사항 분석 -> 컴포넌트 아키텍쳐 설계 -> 컴포넌트 코드 작성 -> 테스트 
   순으로 컴포넌트에 대한 소프트웨어를 구현하고 테스트 하는 단계이다.

🚙 AutoSAR OS

AUTOSAR OS는 자동차 전장 시스템에 필수적인 운영 체제(OS)로, 기존에 사용되던 표준 OS인 OSEK OS를 기반으로
개발되었다. 따라서 OSEK OS의 API를 계속 사용할 수 있으며, 추가로 다양한 기능을 제공한다.
(※ OSEK OS : FREERTOS와 같은 실시간성 OS이며 자동차 전장 시스템에서 쓰임) 

요구 사항에 따라 OS에서 제공하는 4개의 Scalability Class를 사용한다. 

1. Scalability Class
   Scalability Class는 AUTOSAR OS의 기능을 애플리케이션의 요구 사항에 맞게 조정할 수 있는 기능이다.
   기능이 모두 포함된 SC4만 사용하면 될 것 같지만 자원 최적화를 위해 기능을 조절하여 사용한다.
2. SC1
   SC1은 AUTOSAR OS의 아래의 기본 기능을 제공한다. 
   
   • OSEK OS의 기본 기능
   • SWFRT : OS에서 사용하는 타이머를 설정할 수 있는 기능
   • Counter : OSEK OS의 카운터를 직접 제어할 수 있는 기능
   • Schedule Table : 여러 동작을 시간에 따라 수행하게 하기 위해 OS에서 제공하는 기능
     
   • Stack Monitoring : 스택이 설정된 값보다 초과되어 사용되고 있지 않은지 검사하는 기능
3. SC2
   SC2는 SC1의 기능을 포함, 추가로 Timing Protection 기능을 제공한다.
   
   • Time Protection
     ask의 수행 시간, resource 점유 시간, activation 주기 등을 감시하여 제시간에 동작하도록 보장하는 기능
     자율주행 자동차의 ECU의 경우, 자율주행 기능을 수행하는 Task가 모두 제시간에 동작해야 하여 SC2 이상의
     Scalability Class를 지원해야 한다.
4. SC3
   SC3는 SC1의 기능을 포함하며, Memory Protection 기능을 추가로 제공한다.
   
   • Memory Protection
     허가되지 않은 메모리 영역의 접근을 감지하여 메모리 영역의 무결성을 보장하는 기능이다.
     자동차의 엔진 제어 시스템의 경우, 엔진 제어에 중요한 데이터가 포함된 메모리 영역은 보호되어야 하기 때문에 엔진 제어 시스템의 ECU는 SC3 이상의 Scalability Class를 지원해야 한다
     
5. SC4
   SC4는 SC1, SC2, SC3의 기능을 모두 제공한다. .

Sca;abo;oty Class

OS Application

OS 객체들(Task, ISR, Alarm, Schedule table. Counter 등)의 모음

OS Application Model

OS-Apllication의 특징

• 모든 OS 객체는 반드시 OS-Application에 속해야 함
• Resource는 어느 App에도 속해있지 않지만 명시적으로 접근이 허용되어야 함
• 하나의 OS-Application 내의 객체는 모두 동일한 core에 있어야 함

OS-Application의 상태

• Appication_Accessible
  Appication 객체에 접근 가능한 상태, OS 시작 시의 default 상태 
• Application_Restarting
  Application 객체에 접근 불가능한 상태, AllowAccess()을 사용하여 접근 가능 상태로 변경 가능
• Appication_Terminated
  Application이 종료되어 사용 불가능한 상태
  

  

  OS-Application State Model

OS-Application간 접근 권한 

• 동일 OS-Application 에 속한 모든 객체 간에는 서로 접근 가능
• 다른 OS-Application 의 객체에 대한 접근은 설정이 필요 
  

  

  OS-Application 간 접근 권한

OS-Application의 종류

• Trusted OS-Application
  다른 Application 들에게 서비스 제공 가능
  모니터링 및 보조 비활성화로 동작 가능
  Memory, OS 모듈 API에 무제한적인 접근 가능 
• NoN-Trusted OS-Application
  비특권 모드에서 동작, 제한된 API 및 하드웨어 자원에 접근 가능

🚙 AutoSAR IOC 

IOC(Inter OS-Application communication)는 서로 다른 OS-Application 간에 정보를 전달하기 위한 방법이다.
1:1, N:1, N:M 통신을 지원하며 데이터를 하나의 memory block으로 만들어 전달한다. 
또한 MultiCore를 지원하여 core간 정보 교환도 가능하여 빠른 데이터 처리가 가능하다.

iOC 동작 환경

전달 방법 

1. Sender SWC가 IOC Send API를 호출
   예시 : 주행 제어 SWC에서 차량 속도를 보내기 위해 IocSend_SpeedData() 호출.
2. IOC Send API는 데이터를 하나의 memory block으로 만들어 RTE(Runtime Environment)에 전달
   예시 : IocSend_SpeedData()는 현재 속도 데이터를 하나의 메모리 블록에 담아서 RTE에 전송
3. RTE는 데이터를 receiver SWC가 저장된 core로 전송
   예시: RTE는 전송된 속도 데이터를 차량 제어 SWC가 동작하는 Core로 전송
   
4. receiver SWC는 IOC Receive API를 호출하여 데이터를 수신
   예시: 차량 제어 SWC에서 IocReceive_SpeedData() 호출하여 속도 데이터 수신

IOC 과정

🚙 AutoSAR 진단 기능 

AutoSAR 진단 기능은 자동차의 상태를 진단하기 위한 기능이며 진단기는 CAN 통신을 통해 ECU와 통신하여 진단 정보를 수집하고, ECU의상태를 검사하며 아래 3가지 구성 요소로 이루어져 있다.

Autosar 진단 관련 아키텍처

• DCM (Diagnostic Communication Manager)
  진단 통신의 시작 및 종료, 데이터 전송, 각종 진단 통신의 상태를 관리한다.
• DEM (Diagnostic Event Manager)
  진단 이벤트 관련 데이터를 수집, 저장, 공유 역할을 수행한다.   
• DET (Diagnostic Event Translator)
  진단 이벤트 관련 데이터를 분석, DTC로 변환, 정보 공유 역할을 수행한다. 
  (※ DTC : 자동차의 고장 상태를 나타내는 코드)  

AutoSAR 진단 서비스

AutoSAR 진단 서비스는 ISO 14229-1:2013에 정의되어 있으며 아래와 같은 종류들이 있다. 

ID	서비스	설명
10	Diagnostic Session Control	진단 세션의 시작 및 종료를 요청합니다.
11	ECU Reset	ECU를 재시작합니다.
27	Security Access	보안 수준을 획득합니다.
28	Communication Control	정상 메시지의 전송을 허용하거나 억제합니다.
29	Enable Normal Msg Transmission	정상 메시지의 전송을 허용합니다.
3E	Tester Present	진단기가 현재의 진단 상태를 유지하기 위해 요청합니다.
85	Control DTC Setting	고장 코드의 기록 유무를 조절합니다.
20	Stop Diagnostic Session	진단 상태를 초기화합니다.
22	Read Data By Identifier	DID (Data Identifier)를 기반으로 데이터를 읽어옵니다.
23	Read Memory By Address	주소를 기반으로 메모리 영역을 읽어옵니다.
2E	Write Data By Identifier	DID를 기반으로 데이터에 값을 씁니다.
3D	Write Memory By Address	주소를 기반으로 메모리 영역에 값을 씁니다.
19	Read DTC Information	고장 코드 정보를 읽어옵니다.
14	Clear Diagnostic Information	고장 코드 정보를 초기화합니다.
2F	Input Output Control By Identifier	내부 로직의 입력, 출력 신호를 강제로 변경합니다.
31	Routine Control	정의된 로직을 수행하고 결과를 얻습니다.

참고
www.autosar.org

https://www.vector.com/int/en/know-how/autosar/