SW 개발

CLASSIC AUTOSAR 기본 - 03 Software Layer

. . . 2021. 11. 24. 16:39
반응형
  • 개인적 스터디를 위해 정리한자료입니다.
  • 본문서는 classic AUTOSAR general(autosar 4.4) 문서 : AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf 를 정리하였습니다.
  • 잡담
    • 아무래도 주로 tier 에서 사용하는 시스템이다 보니 보안상의 이슈로 인해 한글자료가 많이 없는 느낌입니다.
    • 업무상 AUTOSAR 내용파악을 위해 구글 검색해봐도 잘안나오길래, 그냥 무작정 스펙서를 기반으로 스터디한 자료를 공유합니다.
    • 틀린부분이 있다면 댓글달아주세요.

글순서

  1. CLASSIC AUTOSAR 기본 - 01 CLASSIC AUTOSAR Layer 및 기본구조
  2. CLASSIC AUTOSAR 기본 - 02 Base Software Module Type
  3. AUTOSAR-개요-classic-platform--기본-3-software-layer <- 현재 포스팅
  4. CLASSIC AUTOSAR 기본 - 04 Software Layers in Multi-Core Systems
  5. CLASSIC AUTOSAR 기본 - 05 Software Layers in Mixed-Critical Systems
  6. CLASSIC AUTOSAR 기본 - 06 Overview of Modules
  7. CLASSIC AUTOSAR 기본 - 07 Interfaces

3 Software Layer

Libraries 는 관련 기능들에 대한 묶음입니다.

  • Libraries 에 대해서...
    • BSW 모듈 (RTE), SW-CS, 라이브러리 또는 통합 코드로 호출 할 수 있습니다.
    • protection environment 에서 caller 의 context 에서 프로그램 실행
    • library 재호출하여 사용할 수있음.
    • 내부상태없음
    • 초기화가 필요하지 않음
    • 동기식 호출 (호출 대기점이 없음)

Introduction to Libraries

다음의 라이브러리들이 AUTOSAR 내에 포함되어있다.

  • Fixed point mathematical,
  • Floating point mathematical,
  • Interpolation for fixed point data,
  • Interpolation for floating point data,
  • Bit handling,
  • E2E communication,
  • CRC calculation,
  • Extended functions (e.g. 64bits calculation, filtering, etc.)

3.1 Microcontroller Abstraction Layer

Microcontroller Abstraction Layer

Microcontroller Abstraction Layer 는 다음 모듈 그룹으로 구성됩니다.

  • Microcontroller Drivers
    • Drivers for internal peripherals (e.g. Watchdog, General Purpose Timer)
    • Functions with direct MCU access (e.g. Core test)
  • Communication Drivers
    • Drivers for ECU onboard (e.g. SPI) and vehicle communication (e.g. CAN).
    • OSI-Layer: Part of Data Link Layer
  • Memory Drivers
    • Drivers for on-chip memory devices (e.g. internal Flash, internal EEPROM)
    • memory mapped external memory devices (e.g. external Flash)
  • I/O Drivers
    • Drivers for analog and digital I/O (e.g. ADC, PWM, DIO)
  • Crypto Drivers
    • Drivers for on-chip crypto devices like SHE or HSM
  • Wireless Communication Drivers
    • Drivers for wireless network systems (in-vehicle or off-board communication)

Microcontroller Abstraction Layer - detail

3.1.1 Microcontroller Abstraction Layer - SPI Handler

SpiHandlerDriver는 여러 클라이언트에 대해 하나 이상의 SPI 버스로 동시에 액세스 할 수 있습니다.

SPI Chip Select 핀의 모든 기능을 추상화하려면 SpiHandlerDriver가 직접 처리해야합니다. 해당 핀은 DIO 드라이버에서 사용할 수 없음을 의미합니다.

SpiHandlerDriver

SpiHandlerDriver - example

3.2 Complex Drivers

  • Complex Driver 는 basic software stack 내에서 표준화되지 않은 추가 기능을 구현하기 위한모듈입니다.
  • 예를 들어 특정 interrupt 혹은 MCU 에 추가장착된 복합장치 (예 : PCP, TPU) 를 사용할때, 하여 MCU 에서 직접 직접 액세스하여 복잡한 센서 및 액추에이터등을 제어 및 구현하는 것입니다.
    • Injection control
    • Electric valve control
    • Incremental position detection

Complex Drivers

  • 구현목적 :
    • 복잡한 센서 및 액추에이터를 위한 특별 기능 및 타이밍 요구 사항을 위해 구현
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU, ECU, 어플리케이션에 모두 종속적
    • 상위 인터페이스 구현컨셉 (to SW-Cs) : AUTOSAR 에 API에 구현 (AUTOSAR interface)
    • 하위 인터페이스 구현컨셉 : 표준화된 인터페이스의 제한된 사용

Complex Drivers - detail

3.3 ECU Abstraction Layer

3.3.1 I/O Hardware Abstraction

  • I/O Hardware Abstraction 는 주변 I/O 장치 (온칩 또는 온보드) 및 ECU 하드웨어 레이아웃 각 모듈 그룹입니다. (예:MCU 핀 연결 및 신호 레벨 반전).
  • I/O Hardware Abstraction 가 센서/액추에이터를 추상화하지 않습니다!
  • 각각 다른 I/O 장치는 I/O signal interface를 통해 액세스 할 수 있습니다.

IO Hardware Abstraction

  • 구현목적 :
    • ECU 하드웨어에 연결된 I/O 신호를 나타냄. (전류,전압,주파수같은...)
    • 상위 레이에어에 ECU나 하드웨어 레이아웃과 별개로 구현할수있도록 한다.
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU 에 독립적, ECU 하드웨어에 종속적
    • 상위 인터페이스 구현컨셉 : MCU,ECU 에 독립적. signal 타입 및 Autoser 인터페이스에 따른 종속적인 구현

IO Hardware Abstraction - example

3.3.2 Communication Hardware Abstraction

Communication Hardware Abstraction

  • The Communication Hardware Abstraction 는 communication controllers 와 the ECU hardware layout 사이에 위치하는 추상화하는 모듈 그룹입니다.
  • 모든 통신 시스템에 대해 특정 통신 하드웨어 추상화가 필요합니다 (예 : LIN, FlexRay).
    • Example: ECU에는 2 개의 내부 수 채널이있는 마이크로 컨트롤러와 4 개 CAN 컨트롤러가있는 추가 온보드 ASIC가 있습니다. CAN-ASIC은 SPI를 통해 마이크로 컨트롤러에 연결됩니다.

통신 드라이버는 특정 bus interface (ex. CAN Interface)를 통해 액세스 할 수 있습니다.

Communication Hardware Abstraction - example

  • 구현목적 :
    • 칩안(on-chip)이던, 칩밖(off-chip)이던 위치에 관계없이 동일한 엑세스 매커니즘 제공을 위한 통신 버스를 제공
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU 에 독립적, ECU 하드웨어와 외부장치에 종속적
    • 상위 인터페이스 구현컨셉 : 통신버스에 족속적, MCU 와 ECU 하드웨어에 독립적

3.4 Memory Hardware Abstraction 관점에 대한 접근

Memory Hardware Abstraction 는 peripheral memory devices (온칩 또는 온보드)와 ECU hardware layout 사이에 위치하는 모듈 그룹입니다.

  • Example: 내부 EEPROM 및 외부 EEPROM 장치는 동일한 메커니즘을 통해 액세스 할 수 있습니다.

Memory Hardware Abstraction - Scope

memory drivers 는 메모리 특정한 추상화/에뮬레이션 모듈 (예 : EEPROM Abstraction) 을 통해 액세스됩니다.

플래시 하드웨어 단위 상단에서 EEPROM 추상화를 에뮬레이트함으로써 두 가지 유형의 하드웨어에 대한 Memory Abstraction Interface를 통한 공용 액세스가 활성화됩니다.

  • 구현목적 :
    • 칩내부외부의 메모리장치(EEPROM, FLASH 같은 메모리) 하드웨어에 엑세스하는 동일 메커니즘제공
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU 에 독립적, 외부장치에 종속적
    • 상위 인터페이스 구현컨셉 : MCU, ECU, 메모리디바이스에 독립적

Memory Hardware Abstraction - example

3.5 Onboard Device Abstraction

Onboard Device Abstraction에는 내부 또는 외부 워치 독과 같은 센서 또는 액추에이터로 볼 수없는 ECU 온보드 장치 용 드라이버가 포함되어 있습니다. 이러한 드라이버는 MCU Abstraction Layer 를 통해 ECU 온보드 장치에 액세스합니다.

Onboard Device Abstraction

  • 구현목적 :
    • 보드장착된 특정 ECU 에 대한 추상화를 제공한다.
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU 에 독립적, 외부장치에 대해 종속적
    • 상위 인터페이스 구현컨셉 : MCU 에 독립적, ECU 하드웨어에 대해 부분적으로 종속적

Onboard Device Abstraction - example

3.6 Crypto Hardware Abstraction (scope)

Crypto Hardware Abstraction - scope

Crypto Hardware Abstraction는 cryptographic primitives(외부하드웨어 혹은 sw 기반의 엔진) 에 위치합니다

  • Example: AES 프리미티브는 소프트웨어 라이브러리로 제공되거나 제공됩니다.

Crypto Hardware Abstraction - example

  • 구현목적 :
    • 내외부 소프트웨어 암호화 장치 접근에 대한 동일 매커니즘 제공
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU 에 독립적
    • 상위 인터페이스 구현컨셉 : MCU, ECU, crypto device 에 대해서 독립적

3.6.1 Services: Crypto Services

Crypto Services

  • Crypto Service는 두 개의 모듈로 구성됩니다
    • Crypto Service Manager 는 암호화 작업 관리를 담당합니다.
    • Key Manager 는 키 프로비저닝 마스터(NVM or Crypto Driver)와 상호 작용하고 인증서 체인의 저장 및 검증을 관리합니다.

Crypto Services - example

  • 구현목적 :
    • 암호화 프리미티브 및 키 저장소에 방법에 대해서 일관된 방식적용. 하드웨어 장치 및 각 장치의 속성에 대한 추상화
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU, ECU 에 대해 독립적이며 관련한 설정이 가능해야함.
    • 상위 인터페이스 구현컨셉 : MCU, ECU 하드웨어에 대해서 독립적. (AUTOSAR 인터페이스에 의해 제어)

3.7 Communication 의 관점

3.7.1 Communication Services – General

Communication Service는 차량 네트워크 통신 (CAN, LIN, FlexRay 및 이더넷)을위한 모듈 그룹입니다. 이 인터페이스는 communication hardware abstraction 를 통해 communication drivers 와 인터페이스합니다.

Communication Services – General

  • 구현목적 :
    • 차량내 네트워크 통신을 위한 동일한 인터페이스 제공
    • 네트워크 관리 및 차량용 진단통신을 위한 동일한 인터페이스와 서비스 제공
    • 어플리케이션에서 프로토콜이나 메시지 속성에 대해 상관없이 구성
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU, ECU 하드웨어에 종속적, 부분적 통신버스에 대한 종속
    • 상위 인터페이스 구현컨셉 : MCU, ECU hardware and bus type independent

Communication Services – example

통신 서비스는 다음 페이지의 관련 차량 네트워크 시스템에 대해 자세히 설명됩니다.

3.7.2 Communication Stack – CAN

Communication Stack – CAN

CAN Communication Services는 통신 CAN 시스템과의 차량 네트워크 통신을위한 모듈 그룹입니다.

  • 구현목적 :
    • CAN 네트워크에 대한 동일한 인터페이스 제공.
    • 어플리케이션에서 프로토콜이나 메시지 속성에 대해 상관없이 구성

CAN 통신과 관련한 스펙은 다음의 내용을 지원해야합니다.

  • Classic CAN communication (CAN 2.0)
  • CAN FD communication, if supported by hardware

Communication Stack – example

  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU, ECU 하드웨어에 독립적. CAN 장치에 대한 부분적 종속.
      • AUTOSAR COM, Generic NM (Network Management) Interface, Diagnostic Communication Manager는 모든 차량 네트워크 시스템에서 동일하며 ECU당 하나의 인스턴스로 존재합니다.
      • Generic NM Interface 에는 디스패처만 포함되어 있으며 추가 기능은 포함되지 않습니다.
      • 게이트웨이 ECU의 경우 NM 코디네이터 기능을 포함하여 여러 개의 다른 네트워크(동일한 유형 또는 다른 유형의 네트워크)를 동기화하여 동기적으로 웨이크업 또는 종료할 수 있습니다.
      • CAN NM 은 CAN 네트워크에 고유하며 CAN 차량 네트워크 시스템에 따라 인스턴스화됩니다.
      • 통신 시스템별 CAN State Manager는 통신 시스템 종속 시작 및 종료 기능을 처리합니다. 또한 PDU를 전송하고 신호 시간 초과를 모니터링하는 COM 의 다양한 옵션을 제어합니다.

3.7.3 Communication Stack Extension – TTCAN

TTCAN 통신 서비스는 통신 시스템 TTCAN과의 차량 네트워크 통신을 위한 일반 CAN 인터페이스 및 CAN 드라이버 모듈의 선택적 확장입니다.

  • 구현목적 :
    • TTCAN 네트워크에 균일한 인터페이스를 제공합니다.
    • 어플리케이션에서 프로토콜이나 메시지 속성에 대해 상관없이 구성

nots : TTCAN과의 CAN 인터페이스는 일반 CAN 드라이버와 CAN 드라이버 TTCAN의 기능을 둘다 제공할 수 있습니다.

  • 프로그램 구현 :
    • TTCAN은 CAN의 절대적인 슈퍼셋입니다.(TTCAN을 지원하는 CAN 스택은 CAN 및 TTCAN 버스를 모두 제공할 수 있습니다.)
      • CanIf 및 CanDrv 모듈은 TTCAN 통신을 제공하기 위해 사용됩니다.
    • CAN 통신 스택의 속성(특성)은 TTCAN 기능을 가진 CAN 에도 동일하게 적용된다.

3.7.4 Communication Stack Extension – J1939

J1939 통신 서비스는 중장비 차량에서 차량 네트워크 통신을 위해 일반적인 CAN 통신 스택을 확장합니다.

Communication Stack Extension – J1939

  • 구현목적 :
    • J1939에서 요구하는 프로토콜 서비스를 제공합니다.
    • 해당 기능을 필요하지 않은 응용프로그램에서는 프로토콜 및 메시지 속성에 상관없이 구성하도록합니다.

Please Note: - CAN 스택 (CanTp 및 J1939Tp)에는 다른 채널에서 대안적으로 또는 병렬로 사용할 수 있는 두 가지 전송 프로토콜 모듈이 있습니다. (다음의 내용과 함께 사용) - CanTp: ISO Diagnostics (DCM), large PDU transport on standard CAN bus - J1939Tp: J1939 Diagnostics, large PDU transport on J1939 driven CAN bus

Communication Stack Extension – J1939 example

  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU, ECU 에 독립적 (based on CAN)
    • AUTOSAR COM, Generic NM(Network Management) 인터페이스 및 진단 통신 관리자는 모든 차량 네트워크 시스템에 대해 동일하며 ECU당 하나의 인스턴스로 존재한다.
    • 구성 시간에 알 수 없는 동적 프레임 식별자(dynamic frame identifiers)를 지원합니다.
    • J1939 네트워크 관리는 각 ECU에 고유한 주소 할당을 처리하지만 sleep/wakeup 처리 및 부분 네트워킹과 같은 관련 개념을 지원하지 않습니다.
    • J1939 진단 및 요청 처리 기능(request handling)을 제공합니다.

3.7.5 Communication Stack – LIN

LIN 통신 서비스는 통신 시스템 LIN과의 차량 네트워크 통신을 위한 모듈 그룹입니다.

Communication Stack – LIN

  • 구현목적 :
    • LIN 네트워크에 균일한 인터페이스를 제공합니다. 응용프로그램에서 프로토콜 및 메시지 속성을 숨깁니다.
  • 프로그램 구현 :
    • LIN 통신 서비스에는 다음이 포함되어 있습니다.
      • ISO 17987 호환 통신 스택
      • 다른 스케줄 테이블로 전환하기 위한 요청을 처리하기 위한 테이블 관리(LIN 마스터 노드의 경우)
      • LIN 프레임 유형별 통신 처리
      • 진단에 사용되는 전송 프로토콜
      • wakeup, sleep 인터페이스
  • 기본 LIN 드라이버 :
    • LIN 프로토콜 구현 및 특정 하드웨어 액세스
    • 간단한 UART 및 복잡한 프레임 기반 LIN 하드웨어 지원

Note: Integration of LIN into AUTOSAR: - LIN 인터페이스는 WakeUp/Sleep API를 제어하고 슬레이브가 버스를 깨어있게 할 수 있다(분권적 접근). 통신 시스템 특정 LIN 상태 관리자는 통신에 따른 스타트업 및 셧다운 기능을 처리합니다. 또한, Communication Manager 로부터의 통신 모드 요청을 제어한다. LIN State Manager는 또한 COM을 인터페이스하여 I-PDU 그룹을 제어합니다. - LIN 프레임을 보낼 때, LIN 인터페이스는 데이터가 필요한 시점에PDU 라우터로부터 프레임(I-PDU)에 대한 데이터를 요청한다. (i.e. LIN 프레임을 보내기 직전에).

3.7.6 Communication Stack – FlexRay

FlexRay Communication Services는 communication system FlexRay 와의 차량 네트워크 통신을 위한 모듈 그룹입니다.

Communication Stack – FlexRay

  • 구현목적 :
    • FlexRay 네트워크에 균일한 인터페이스를 제공합니다. 응용프로그램에서 프로토콜 및 메시지 속성을 숨깁니다.

Please Note: - FlexRay 스택에는 두 개의 전송 프로토콜 모듈이 있으며, 이 모듈은 대체 하여 사용될 수 있다. - FrTp: FlexRay ISO Transport Layer - FrArTp: FlexRay AUTOSAR Transport Layer, provides bus compatibility to AUTOSAR R3.x

Communication Stack – FlexRay - example

  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU, ECU 에 독립적, FlexRay 에 부분적으로 의존.

AUTOSAR COM, 일반 NM 인터페이스 및 진단 통신 관리자는 모든 차량 네트워크 시스템에 대해 동일하며 ECU 당 하나의 인스턴스로 존재합니다.

일반 NM 인터페이스에는 dispatcher 만 포함되어 있으며, 더 이상의 기능은 포함되어 있지 않습니다. 게이트웨이 ECU의 경우, NM Coordinator 로 대체되는데, NM Coordinator는 (동일하거나 다른 유형의) 여러 개의 다른 네트워크를 동기화하여 동기화하거나 종료하는 기능을 제공합니다.

FlexRay NM 은 FlexRay 네트워크에 특화되어있으며, 각각의 FlexRay 차량 네트워크 시스템을 인스턴스화됩니다.

통신 시스템 용 FlexRay State Manager 는 통신 시스템 종속 스타트업 및 셧다운 기능을 처리합니다. 또한 PDU를 보내고 신호 타임 아웃을 모니터링하기 위해 COM 의 다른 옵션을 제어합니다.

3.7.7 Communication Stack – TCP/IP

TCP/IP 통신 서비스는 통신 시스템 TCP/IP와 차량 네트워크 사이의 통신을 위한 모듈 그룹입니다.

Communication Stack – TCP/IP - example

  • 구현목적 :
    • TCP/IP 네트워크에 균일한 인터페이스를 제공합니다. 응용프로그램에서 프로토콜 및 메시지 속성을 숨깁니다.
  • 프로그램 구현 :
    • TcpIp 모듈은 TCP/IP 프로토콜 패밀리(TCP, UDP, IPv4, IPv6, ARP, ICMP, DHCP)의 주요 프로토콜을 구현하고 이더넷을 통해 동적 소켓 기반 통신을 제공한다.
    • 소켓 어댑터 모듈(SoAd)은 TcpIp 모듈의 상위 레이어 모듈입니다.

3.7.8 Communication Stack – General

Communication Stack – General

  • 프로그램 구현 :
    • signal gateway 는 신호를 라우팅하기 위한 AUTOSAR COM의 일부입니다.
    • PDU 기반 게이트웨이는 PDU 라우터의 일부입니다.
    • IPDU 멀티플렉싱은 I-PDU(버스의 다른 콘텐츠와 동일한 ID)의 멀티플렉싱을 가능하게 하기 위한 정보를 추가할 수 있는 가능성을 제공합니다.
    • 컨테이너 매핑을위한 멀티 I-PDU은 여러 개의 I-PDU를 하나의 큰 (container-)I-PDU 로 결합하여 하나의 (특정버스) 프레임으로 전송할 수 있는 가능성을 제공한다.
  • 상위 인터페이스 구현컨셉 :
    • MCU, ECU, 네트워크타입에 독립적

3.8 Off-board Communication Stack – Vehicle-2-X

Off-board 통신 서비스는 ad-hoc 무선 네트워크를 통한 Vehicle-to-X 통신을 위한 모듈 그룹입니다.

Off-board Communication Stack – Vehicle-2

  • Facilities: 표준화된 V2X 메시지 수신 및 전송을 위한 기능 구현, 차량용 SW-C 인터페이스 구축
    • Basic Transport Protocol = Layer 4
    • Geo-Networking = Layer 3 (Addressing based on geographic areas, the respective Ethernet frames have their own Ether-Type)
    • V2X Management: manages cross-layer functionality (like dynamic congestion control, security, position and time)
  • 구현목적 :
    • 무선 이더넷 네트워크에 균일한 인터페이스를 제공합니다. 응용프로그램에서 프로토콜 및 메시지 속성을 숨깁니다.

Off-board Communication Stack – Vehicle-2 - example

3.9 Services: Memory Services

메모리 서비스는 NVRAM Manager 내의 모듈로 구성됩니다. 비휘발성 데이터(다른 메모리 드라이버에서 읽기/쓰기)의 관리를 담당합니다.

Services: Memory Services

  • 구현목적 :
    • 균일한 방법으로 응용프로그램에 비휘발성 데이터를 제공합니다. 메모리 위치 및 속성을 추상화합니다.
    • 저장, 로딩, 체크섬 보호 및 검증, 신뢰할 수 있는 저장 등과 같은 비휘발성 데이터 관리를 위한 메커니즘을 제공합니다.
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU, ECU 에 독립적, 관련기능 설정
    • 상위 인터페이스 구현컨셉 : MCU 및 ECU 하드웨어 독립적, AUTOSAR(AUTOSAR 인터페이스)에 따라 지정 및 구현

Services: Memory Services - example

3.10 Services: System Services

시스템 서비스는 모든 계층의 모듈에서 사용할 수 있는 모듈 및 함수 그룹입니다. 실시간 운영 체제(타이머 서비스 포함)와 오류 관리자등이 있습니다.

  • Some of these services are:
    • MCU에 의존하는 (ex, OS)기능 및 특수 MCU 기능(ex, 시간 서비스)
    • 부분적으로 ECU 하드웨어 및 애플리케이션 의존하는기능(ex, ECU 상태 관리자)
    • 하드웨어 및 MCU 독립적 기능을 지원
  • 구현목적 :
    • Provide basic services for application and basic software modules.
    • 응용 프로그램 및 basic software modules 에 대한 기본 서비스를 제공합니다.
  • 프로그램 구현 :
    • 내부 기능 구현방향 : 부분적으로 MCU, ECU 하드웨어 및 응용 프로그램용 코드
    • 상위 인터페이스 구현컨셉 : MCU, ECU 하드웨어 독립적

Services: System Services - example

3.11 Error Handling, Reporting and Diagnostic

Error Handling, Reporting and Diagnostic

AUTOSAR에는 다양한 오류 처리 측면에 대한 전용 모듈이 있습니다.

  • Diagnostic Event Manager 는 진단 이벤트(오류) 및 관련 FreezeFrame 데이터를 처리 및 저장하는 책임을 맡고 있습니다.
  • 모듈 진단 로그 및 추적은 응용프로그램의 로깅 및 추적을 지원합니다. 사용자 정의 로그 메시지를 수집하여 표준화된 형식으로 변환합니다.
  • All detected development errors in the Basic Software are reported to Default Error Tracer.
  • Basic Software 에서 탐지된 모든 개발 오류는 기본 오류 추적기(Default Error Tracer)에 보고됩니다.
  • 진단 통신 관리자는 진단 서비스를 위한 common API를 제공합니다

Error Handling, Reporting and Diagnostic

3.12 Application Layer: Sensor/Actuator Software Components

센서/액추에이터 AUTOSAR 소프트웨어 구성 요소는 센서 평가 및 액추에이터 제어를 위한 AUTOSAR 소프트웨어 구성 요소의 특정 타입입니다. AUTOSAR Basic Software 에 속하지는 않지만 로컬 신호(local signals)와의 강한 연결성이 있습니다. 이 레이어는 통합(표준화된 인터페이스 하위 인터페이스 및 인터페이스 정의)을 위해 센서/액츄에이터의 SW 구성요소를 RTE 상위 레이어에 위치하도록 하였습니다.

raw local signals 와의 강한 상호 작용 때문에, 코드의 재배치성은 제한됩니다.

application layer - Sensor/Actuator Software Components

  • 구현목적 :
    • ECU에 연결된 하드웨어 센서 및 액추에이터의 특정 물리적 특성으로부터 추상화를 제공합니다.
  • 프로그램 구현 :
    • 내부 기능 구현방향 : MCU 및 ECU HW 독립, 센서 및 액추에이터 종속

Sensor/Actuator Software Components - example

반응형

'SW 개발'의 다른글

  • 현재글CLASSIC AUTOSAR 기본 - 03 Software Layer

관련글

댓글

티스토리툴바