[AUTOSAR] AUTOSAR_Tutorial

AUTOSAR : System Architecture

→ 코딩 전단계까지 (Configuration까지)

AUTOSAR 장점

OTA 시 테스팅 시간, 비용 절감 가능 → 무선으로 가능하므로 잘못되면 수정 가능
(조건 : OTA 를 위해 메모리 기본 2배 이상 되어야 함 (다운로드 + 기존 동작 위함))

AUTOSAR Main Working Topics

1 .Architecture : 소프트웨어 스택
2. Methodology 
   ① 소프트웨어를 어떻게 개발할것인지?
   ② 저장 포맷(표준화함) → arxml(확장자) 생성
3. Application Interfaces

Mobilgene : Authoring tool

→ arxml 파일 읽어서 C코드 생성해주는 tool

Technical Scope of AUTOSAR

AUTOSAR 개발 시 하드웨어 결정되지 않음 → VFB(Virtual Function Bus)이라는 가상환경 사용
New concepts에서 주로 봐야하는 부분 : Virtual Function Bus(VFB), RunTime Environment

Use Case 'Pedal Management' view for one ECU

SW Component : ECU 하나에서 동작할 수 있는 기본 단위

① Component 기반으로 구성
② Module 단위로 구성되어 있음

• distribute_v, v_warn 2개의 Component는 하나의 ECU와 mapping이 불가능함
  → 하나의 ECU는 하나의 Component와 mapping 가능함
• 하나의 ECU와 다수의 Component를 연결하기 위해서는 RTE와 전역변수를 사용해야함
  (전역변수 저장 → 전역변수 읽어오는 방식으로 동작)

1. distribute_v가 전역변수를 RTE에 저장
2. v_warn이 RTE에서 전역변수를 읽음

AUTOSAR 목적

Hardware의 독립적인 Application을 만들겠다는 것
→ Application은 변화가 없고 RTE만 Generate 해줌

 

AUTOSAR Key Topics

① Architecture
 : 하드웨어 독립 SW 애플리케이션을 위한 통합 플랫폼으로써 ECU를 위한 완전한 기본(환경) 소프트웨어 스택을 포함하는 소프트웨어 아키텍처
② Methodology
: 기본 소프트웨어 스택의 원활한 구성 프로세스와 ECU에서의 응용 소프트웨어 통합을 가능하게 하는 교환 형식(템플릿)
③ Application Interfaces
: 응용 소프트웨어 모듈 표준으로서 응용 인터페이스 규격

Standardized AUTOSAR Interfaces

① SW Component 끼리는 데이터만 주고 받음
② SWC = SW-Component, 하나의 ECU에 mapping될 수 있는 기본 단위, C언어로 구성되어 있음
③ Application이 사용하는 서비스 제공 → Configuration & Generation

SW Component1 & SW Component2
: 변수 통해서 통신 불가능 → AUTOSAR RTE 통해서 주고받음

AUTOSAR Interface 종류

① 데이터 관점 : Sender Receiver Interface (데이터 주고받는 종류)
② 오퍼레이션 관점 : Client Sender Interface (요청을 주고받는 종류, 함수)
→ 요청하는 대상 = 함수 call(실행시키는 애) : Client
→ 함수 : Server

① AUTOSAR Interface으로만 사용 가능
② (RTE가 통신 부르는 부분) RTE도 BSW이므로 Standalized
③ AUTOSAR 기반인데 표준+이름 정해져 있는 것
→ 진단, 메모리 등.... 애플리케이션과 연결되어 있지만 서비스 정의가 되어 있어야 함
④ (C언어로 이루어진 것들 사이에서) 본인들끼리 통신, Standalized Interface 사용
→ AUTOSAR에서 표준 정해둠
⑤ RTE 아래에 있는데도 AUTOSAR Interface 사용
→ Application이 사용하는 것들 → Application은 AUTOSAR Interface만 사용 가능
→ 즉, ASW와 연결되기 위해 사용

* Complex Device Drivers
: 복잡한 device → 표준이 없는 내용+재사용이 필요 없는 것을 구현하는 부분

 

AUTOSAR Basic Software

① Service Layer : 서비스를 제공해줌, 하드웨어 구성과 연관 없음, 호출만 함
→ Interface로 묶여 있는 곳에 호출(access)
② MCAL Layer : MUC 내부 주변 장치에 추상화 → 추상화 계층

*MCAL = MicroController App Session Layer

③ ECU Abstraction Layer : ECU 보드를 추상화(MCU 외의 ECU 장치들) + 통합 Interface 제공
→  ①에서 Interface로 붂여 있는 곳에 호출한 다음, Abstraction Layer와 MCAL Layer를 Interface로 묶음
→ 하나의 Interface로 제공(통합 Interface)
* ECU Abstraction Layer 필요성 : 재사용성을 위해 통합 interface 제공

* Complex Drivers(COD) : 많이 사용됨
→ 목적 1. 비표준화된 것 구현
     목적 2. 재사용성 필요없는 Driver 구현

*OS : 하드웨어를 직접 이용해야하므로 MCAL을 거치지 않고 바로 HW로 연결

Layer로 추상화 하는 이유

: 일부가 변경되었을 때 영향을 최소화하기 위함 (재사용성을 위함)

 

NVRAM Manager (Example)

① NVRAM Manager : (하드웨어와 상관X) if&else 로 호출함
→ 블록 ID만 호출함
② Ext. EEPROM Driver : SPI 통해서 Driver 생성 → read&write 함

SPI : Mcal과 외부가 Serial 통신하도록 SPI가 MCU 내부에 있음

→SPI 장치를 통해 통신 및 제어

③ Memory Drivers : MCAL의 Device Driver

 

 

---

 

AUTOSAR Methodology

① ECU Description : ECU와 관련된 Resource 정보
② System Constraint Description : 어떤 통신을 하는지 등에 대한 정보
③ SWC Description : 문서
*VFB view : 하드웨어가 정해져 있지 않은 경우, AUTOSAR Interface만 사용해서 개발해야 함

어떤 통신을 하는지까지 알게 되었을 때 이후 과정
① ECU Mapping (임의로 Mapping)
② ECU Extract
③ (RTE, BSW Configuration) ECU Configuration
④ ECU Generation (C코드 생성됨)
⑤ Compile
⑥ 결과

System Design - Implementation Process

1a 단계 : ASW 개발 과정
→ 구조, 어떤 형태의 구성으로 이루어져 있는지
SW Component : 동작 구현(Implementation)
3 단계 : ECU 각각 개발 단계
4 단계 : '.c'와 '.h' 확장자로 Generate

AUTOSAR : Interface 제공까지
→ 구현은 AUTOSAR 아님, Hand Coding, Simulink 등을 통해 구현