[AUTOSAR] AUTOSAR Architecture - Classic

seopppio·2024년 11월 21일

AutoSAR

목록 보기
2/4

Autosar Classic Architecture


BSW

BSW(Basic SoftWare)

하드웨어와 SWC 사이의 인터페이스 역할
OS, 메모리 서비스, 통신 서비스 등 기본적인 기능 제공

MCAL(Microcontroller Abstraction Layer)

하드웨어 추상화 계층, Micom과 직접 상호작용하며, 하드웨어 독립성 보장

ECU Abstraction Layer

ECU 하드웨어에 대한 추상화 제공, 상위 소프트웨어 모듈이 하드웨어 독립적으로 동작할 수 있도록 함

MCAL과 ECU Abstraction Layer 모두 하드웨어를 추상화 하지만, MCAL은 Micom 수준의 하드웨어(ADC, GPIO, PWM) 등을 추상화한다. ECU Abstraction Layer에서는 MCU를 포함하여, ECU 전반에 있는 센서, 엑추에이터와 같은 전반적인 모든 하드웨어를 추상화한다

Service Layer

메모리 관리, 통신 서빗, 진단 서비스 같은 시스템 서비스 제공

Complex Drivers(CDD)

특정 기능이 필요한 것을 따로 구현하여 직접 하드웨어와 상호작용 직접 하드웨어와 상호작용

RTE

Runtime Environmnet

SWC와 BSW 사이의 인터페이스 역할
SWC-SWC 간의 인터페이스도 하고, SWC-BSW 간 인터페이스도 제공

기능

  • Inter-Component Communcaton : SWC간 데이터 교환
  • Scheduling : SWC 실행 스케줄링
  • Service Access : BSW 서비스 SWC에 제공

Software Component, SWC

특정 기능을 수행하는 소프트웨어 모듈

Architecture - System services


각각은 모두 모듈이다

AUTOSAR OS

OSEK OS 탑재
ASIL에 대응되는 System Safety, Real-Time Scheduling, Alarm&TImer 등 us/ms 단위 반응성과 Fail-Safety 내용 포함

오류 관리 예시
ASIL 낮은 모듈이 높은 등급의 모듈 Access 하여 Write 하려고 하면, 메모리 프로텍션 에러 발생해서 이를 실행하지 못하게 한다

EcuM(Ecu State Manager)

ECU의 전원과 부팅을 관리

BswM(Basic SW Mode Manager)

BSW 모듈간의 모드 전환 을 관리 및 제어
EcuM과 연계하여 작동

WdgM(WacthDog Manager)

Watchdog 에 대한 관리 및 트리거링 ( 와치독은 MCU 내부/외부에 존재 )

FiM(Function Inhibit Manager)

기능 억제 혹은 활성화 목적의 모듈, 진단과 같이 작동한다

Dem(Diagnostic Event Manager)

진단 이벤트, DTC 관리, 고장코드 저장 목적

계기판에서 보는 경고등은, DEM에서 DTC 식별 되면, DTC를 Cluster로 전송해서 경고 뜨게 하는 것이다

Det(Develop Error Tracing)

개발 과정에서 소스코드 수행 오류 확인

Architecture - System services


메모리 읽고 쓰는 과정

NvM(Non-Volatile Memory)

Rom관리 및 데이터 쓰기/읽기/삭제 등을 위한 인터페이스 제공

Memlf(Memory Abstraction Interface)

NvM과 Fee 간 추상화 및 인터페이싱

Fee(Flash EEPROM Emulation)

메모리의 데이터를 블록 단위로 관리 , Fls와 NvM 사이에서 명령 수행

Fls(Flash Driver)

실제 MCU 플래시 메모리에 접근하여 쓰기/삭제 수행

Architecture - COM

차량 네트워크는 차량 내부 및 외부 장치들 간 데이터 교환에 사용 됨
다양한 통신 프로토콜을 사용한다 ex CAN, LIN, FlexRay, Ethernet
커뮤니케이션 관련 모듈은, 해당 프로토콜을 관리하고, 실제 통신 메세지를 관리하고, 통신으로부터 파생된 기능을 위한 인터페이스도 제공한다


Architecture - MCAL

MCU와 SW 간 인터페이스를 추상화하고, 표준화된 인터페이스 제공이 목적
실제적으로 하드웨어에 접근, 제어하는 레이어

  • DMA : MCU 메모리 개입 없이 데이터에 접근할 수 있는 기능이 있는 모듈

Microcontroller Drivers

  • Gpt
    Timer, 인터럽트 사용
  • Wdg
    정상/비정상 동작 확인 -> 재부팅
  • Mcu
    물리적인 채널, 클럭 관리
  • CorTst(CoreTest)

Memory Drivers

  • FlshTst
  • RamTst
  • Fls
    내장 롬 접근
  • Eep
    외장 롬 접근

Communication Drivers

  • Fr(FlexRay), Eth(Ethernet)
    ADAS, 영상 ECU 같이 사이즈 큰 통신 필요할 대
  • Spi, Can. Lin
  • Spi
    IC와 통신에서 주로 사용 됨

I/O Drivers

  • Icu(Input Capture Unit)
    MCU로 들어오는 파형 감지
    ex) Rising Edge 변환 있을 때, 동작과 연결해서 코드 수행하게 한다
    ex) CAN 기반으로 Edge Detection 하여 ECU Wake up

  • Ocu, Pwm, Adc, Dio

  • Pwm
    인터럽트 사용, MCU는 PWM 처럼, 파형 발생해서 인터럽트 기반으로 파형 발생 시킴

  • Port
    핀 마다 물리적으로 할당된 기능 어떻게 사용할지 설정하는 모듈

Architecture - I/O

각종 센서기반 데이터를 외부 ASIC 으로 부터 Application까지 전달하기 위해서는 I/O HW Abstraction Service 존재

이를 통해, 하드웨어와 독립적인 소프트웨어 개발이 가능해짐
-> 다양한 플랫폼에서 SW 사용 가능 및 유지보수 용이

MCAL, RTE 사이에서 API로 추상화 해준다

Sensor, Actuator Data가 MCAL -> I/O Hardware Abstraction -> RTE -> SWC 까지 올라가고, 다시 내려가면서 제어를 위한 Acutator 가동

Architecture - CDD

Autosar 사양에 존재하지 않거나, OEM이 따로 요구한 그런 추가 SW를 AUTOSAR SW에 포함시켜야할 때 CDD로 구현한다

과제

1. Can, Canif, CanSM, CanTp, CanNM 모듈 Configuration 수행해보고, 각 모듈이 어떤 레이어에 위치하고 어떤 역할을 하는지 적어보시오

2. CAN Bus에서 여러 ECU들이 송수신하는 메시지 중 수신해야 하는 메세지는 어떻게 식별할까요?

3. CAN IC Pin Map과 동작정의를 참고하여 Normal Mode를 구현하기 위해서 어떤 모듈에 대한 설정이 필요할지 고민해보고, Aurix TC38X Datasheet 참고하여 CAN10 채널에 Assign 가능한 Port Interface 구성해보시오


  • CANL, CANH는 CAN BUS와 연결, MCU와 연결 X

  • TxD, RxD

    Aurix의 특정 포트의 저 기능 할당

  • NEN, NRM

최종

0개의 댓글