SW 개발

CLASSIC AUTOSAR 기본 - 07 Interfaces

. . . 2021. 11. 24. 16:50
반응형
  • 개인적 스터디를 위해 정리한자료입니다.
  • 본문서는 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. CLASSIC AUTOSAR 기본 - 03 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. AUTOSAR-개요-classic-platform--기본-7-interfaces <- 현재 포스팅

7 Interfaces

7.1 Type of Interfaces in AUTOSAR

AUTOSAR Interface

AUTOSAR Interface는 소프트웨어 구성 요소 및/또는 BSW modules 간에 정보의 교환을 정의합니다. (특정 프로그래밍 언어, ECU 또는 네트워크 기술과는 무관합니다.) AUTOSAR 인터페이스는 소프트웨어 컴포넌트 및/또는 BSW modules의 포트를 정의하는 데 사용됩니다. 이러한 포트를 통해 소프트웨어 구성 요소 및/또는 BSW modules 은 서로 통신할 수 있습니다.(정보 전송 또는 수신 또는 서비스 호출). AUTOSAR는 로컬 또는 네트워크를 통해 소프트웨어 - 컴포넌트 및 / 또는 BSW modules 간의 통신을 구현할 수 있게 합니다.

Standardized AUTOSAR Interface

Standardized AUTOSAR Interface 는 AUTOSAR 에서 구문과 의미를 표준화시킨 AUTOSAR Interface 입니다. Standardized AUTOSAR Interfaces 는 AUTOSAR Basic Software 가 응용 프로그램 소프트웨어 컴포넌트에 제공하는 표준화된 서비스인 AUTOSAR 서비스를 정의하는 데 사용됩니다.

Standardized Interface

Standardized Interface는 AUTOSAR 인터페이스 기법을 사용하지 않고 AUTOSAR 내에서 표준화된 API이다. 이러한 Standardized Interfaces 는 일반적으로 특정 프로그래밍 언어(C와 같은)에 대해 정의된다. 이 때문에 Standardized Interfaces 는 항상 동일한 ECU에 있는 소프트웨어 모듈 사이에서 일반적으로 사용됩니다. 소프트웨어 모듈이 표준화된 인터페이스를 통해 통신할 경우, 네트워크를 통해 소프트웨어 모듈 간의 통신을 라우팅하는 것은 더 이상 불가능합니다.

7.2 Components and interfaces view (simplified)

Components and interfaces view

Note: 이 그림의 레이어 간의 가능한 상호 작용의 설명은 불완전합니다.

detail describe

Note

  • 개인노트
    • 각 레이어에서 호출에 대한 상호 규약이 제한된다.
    • ECU 레이어를 통과하여 바로 MCU 로 호출가능한 경우도있으며, 반드시 ECU 레이어를 거쳐야하는경우도있는듯하다.
    • 이러한 레이어간의 호출규약은 아래의 matrix 에서 잘나타낸다.

7.3 General Rules : Layer Interaction Matrix

아래의 matrix 는 AUTOSAR 기본 소프트웨어 계층 간의 허용된 상호 작용을 보여줍니다

Layer Interaction Matrix

7.4 Interfacing with Complex Drivers

Complex Driver

Complex Drivers 는 계층화된 소프트웨어 아키텍처의 다른 모듈과 인터페이스해야하거나 반대로 계층화된 소프트웨어 아키텍처의 모듈가 Complex Drivers 와 인터페이스해야할 수 있습니다. 이 경우 다음 규칙이 적용됩니다.

  1. 계층화된 소프트웨어 아키텍처의 모듈에서 Complex Drivers 의 인터페이스
    • 이경우 Complex Drivers 가 AUTOSAR 모듈접근에 의해 일반적으로 구성될 수 있는 인터페이스를 제공하는 경우에만 허용됩니다.
    • 대표적인 예가 PDU 라우터입니다. Complex Driver 는 새로운 버스 시스템의 인터페이스 모듈을 구현할 수 있습니다. 이것은 이미 PDU 라우터의 설정에서 사용중입니다.
  2. Complex Drivers 에서 계층화된 소프트웨어 아키텍처 모듈로의 인터페이스
    • 다시 말하지만, 이것은 계층화된 소프트웨어 아키텍처 모듈이 인터페이스를 제공하고 Complex Driver에 의해 액세스될 준비가 되어 있는 경우에만 허용됩니다.
    • 각각의 인터페이스는 재진입할수있도록 정의됩니다.
    • 콜백루틴을 호출호출되면 이름을 설정할 수 있다.
    • 모듈의 상태를 관리하는 상위 모듈은 존재하지 않는다. (병렬 액세스는 상위 모듈에 알리지 않고 상태를 변경한다).

일반적으로 Complex Drivers 는 다음 모듈에 액세스할 수 있습니다.

  • SPI driver
  • GPT driver
  • IO드라이버는 groups/channels/etc 이 각각 존재할때만 재 진입에 대해 제한 됩니다.
    • 동일한 groups/channels/etc 대한 병렬 액세스는 대부분 허용되지 않습니다. 이러한 접근은 설정 중에 되어야 해야 합니다.
  • NVRAM Manager 를 통한 memory stack 에 대한 독점 액세스 포인트
  • Watchdog Manager 를 통한 watchdog stack 에 대한 독점 액세스 포인트
  • PDU Router 를 통한 communication stack 에 대한 전용 버스 및 프로토콜 독립 액세스 포인트
  • specific interface modules 를 통한 communication stack 에 대한 전용 버스 특정 액세스 포인트
  • NM Interface Module 를 통한 네트워크 관리 스택에 대한 전용 액세스 포인트
  • Communication Manager (only from upper layer) 와 Basic Software Mode Manager 를 통한 state management 에 대해 전용 엑세스 포인트
  • Det, Dem and Dlt
  • OS 내의 사용하는 OS 개체중 사용되지 않은 계층화된 소프트웨어 아키텍처의 모듈
  • 그래도 각 모듈마다 각각 기능이 재진입으로 표시되어 있는지 확인할 필요가 있다. 예를 들어, 'init'기능은 대개 재진입하지 않으며 ECU State Manager에 의해서만 호출되어야 합니다.

멀티 코어 아키텍처의 경우 다음과 같은 추가 규칙이 있습니다.

  • BSW는 여러 코어에 걸쳐 분산될 수 있습니다. BSW 서비스에 대한 호출을 실행하는 core 응답은 BswOperationInvokedEvent 의 태스크 매핑에 의해 결정된다.
  • master/satellite 구현을 사용하여 모듈 내부 통신에만 파티션과 코어 간의 경계를 교차할 수 있습니다.
  • CDD 가 BSW 의 표준화된 인터페이스에 액세스해야하는 경우는 동일한 코어에 있어야 합니다.
  • CDD 가 다른 코어에 있는 경우, 일반 포트 메커니즘을 사용하여 AUTOSAR 인터페이스 및 표준화된 AUTOSAR 인터페이스에 액세스할 수 있습니다.
    • 이러한 방법은 운영 체제의 IOC 메커니즘을 사용하여 요청을 다른 코어로 전송하는 RTE를 호출합니다.
    • 그러나 CDD가 BSW의 표준화된 인터페이스에 액세스해야하며 동일한 코어에 있지 않으면, - 표준화된 인터페이스를 제공하는 satellite은 CDD가 있는 코어에서 실행되어 다른 코어로 호출을 전달할 수 있습니다 - 또는 CDD의 스터브 부분은 다른 코어에서 구현되어야하며, 통신은 RTE가하는 것과 유사한 운영 체제의 IOC 메커니즘을 사용하여 CDD 로컬로 구성되어야 합니다.
  • 또한, 후자의 경우 CDD의 초기화 부분도 다른 코어의 스터브 부분에 있어야 합니다.

7.5 interaction of layers Example 1 - Memory

7.5.1 Interfaces: Interaction of Layers - Example "Memory" Introduction

다음 페이지는 메모리를 사용에는 예제로 설명합니다.

  • 소프트웨어 계층은 어떻게 상호작용하는가?
  • 소프트웨어 인터페이스는 어떻게 생겼는가?
  • ECU 추상화 층 안에는 무엇이 있는가?
  • 추상화 계층을 어떻게 효율적으로 구현할 수 있을까?

7.5.2 Example "Memory" - Example and First Look

First Look

이 예는 NVRAM Manager와 Watchdog Manager가 가정된 하드웨어 구성에서 드라이버와 상호 작용하는 방법을 보여줍니다.

  1. ECU 하드웨어는 외부 EEPROM 및 동일한 SPI를 통해 마이크로컨트롤러에 연결된 외부 와치독을 포함한다.
  2. SPIHandlerDriver는 SPI 하드웨어에 대한 동시 액세스를 제어하며 와치독에게 EEPROM 액세스보다 높은 우선 순위를 부여해야 합니다.
  3. 마이크로컨트롤러는 외부 EEPROM과 병렬로 사용되는 내부 플래시를 포함한다.
  4. EEPROM 추상화와 플래시 EEPROM 에뮬레이션은 동일한 동작의 동일한 API를 가지고 있습니다.
  5. 메모리 추상 인터페이스는 다음과 같은 방법으로 구현할 수 있습니다.
    1. 장치 인덱스 기반 런타임 동안 라우팅(int/ext)
    2. 블록 인덱스에 기초한 런타임의 라우팅 (e.g. 0x01FF = external EEPROM)
    3. NVRAM 관리자 내부에 기능 포인터가 있는 ROM 테이블을 통해 구성 하는 동안의 라우팅 (이 경우 메모리 추상 인터페이스만 가상으로 존재함)

Example "Memory" Example and First Look

7.5.3 Example "Memory" - Closer Look at Memory Hardware Abstraction

메모리 하드웨어 추상화를 자세히 살펴보기

Architecture Description

NVRAM Manager 는 Memory Abstraction Interface 를 통해 드라이버에 액세스합니다. 디바이스 인덱스를 사용하여 서로 다른 메모리 장치를 처리합니다.

Interface Description

메모리 추상 인터페이스는 다음 인터페이스를 가질 수 있습니다 (e.g. for the write function):

Std_ReturnType MemIf_Write
(
  uint8 DeviceIndex,
  uint16 BlockNumber,
  uint8 *DataBufferPtr
)

EEPROM Abstraction 뿐만 아니라 플래시 EEPROM 에뮬레이션은 다음과 같은 인터페이스를 가질 수 있습니다. (e.g. for the write function):

Std_ReturnType Ea_Write
(
  uint16 BlockNumber,
  uint8 *DataBufferPtr
)

7.5.4 Example "Memory" - Implementation of Memory Abstraction Interface

메모리 추상 인터페이스의 예제

Situation 1: only one NV device type used

한가지 NV device만 사용하는경우.

이것은 일반적인 사용 사례입니다. 이러한 상황에서, 메모리 추상화는 소스 코드 가용성의 경우, 디바이스 인덱스 파라미터를 무시하는 간단한 매크로로 구현될 수 있습니다. 다음 예제는 쓰기 기능만 보여줍니다.

File MemIf.h:

#include "Ea.h" /* for providing access to the EEPROM Abstraction */
// 생략...
#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \
Ea_Write(BlockNumber, DataBufferPtr)

File MemIf.c:

// Does not exist

Result:

  • 런타임에 추가 코드가 없으면 NVRAM Manager는 EEPROM 추상화 또는 플래시 에뮬레이션에 직접 액세스합니다.

7.5.5 Example "Memory" - Implementation of Memory Abstraction Interface

메모리 추상 인터페이스 구현

Situation 2: two or more different types of NV devices used

두개혹은 그이상의 다른타입의 NV device 사용

In this case the DeviceIndex has to be used for selecting the correct NV device. The implementation can also be very efficient by using an array of pointers to function. The following example shows the write function only:

이 경우 DeviceIndex는 올바른 NV 장치를 선택하는 데 사용되어야 합니다. 또한, 포인터의 배열을 사용하여 기능을 수행함으로써 구현이 매우 효율적일 수 있습니다.

다음 예제는 쓰기 기능만 보여줍니다.

File MemIf.h:

extern const WriteFctPtrType WriteFctPtr[2];
#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) \
WriteFctPtr[DeviceIndex](BlockNumber, DataBufferPtr)

File MemIf.c:

#include "Ea.h" /* for getting the API function addresses */
#include "Fee.h" /* for getting the API function addresses */
#include "MemIf.h" /* for getting the WriteFctPtrType */
const WriteFctPtrType WriteFctPtr[2] = {Ea_Write, Fee_Write};

Result:

  • 함수 포인터 테이블이 NVRAM 관리자 내부에 있는 것처럼 동일한 코드와 런타임이 필요합니다.
  • 메모리 추상 인터페이스는 오버헤드를 발생시키지 않습니다.

7.5.6 Interfaces: Interaction of Layers - Example "Memory" Conclusion

메모리에서의 layer 간 상호작용예제

Conclusions:

  • 추상층들을 매우 효율적으로 구현할 수 있다
  • 추상 레이어를 확장할 수 있습니다
  • Memory Abstraction Interface는 NVRAM Manager의 액세스를 하나 이상의 EEPROM 및 플래시 디바이스를 쉽게 접근할 수 있게 한다.

7.6 interaction of layers Example 2 - communication

통신의 예제

7.6.1 PDU Flow through the Layered Architecture

layer 구조를 통한 PDU 흐름

PDU Flow through the Layered Architecture

용어 설명 :

  • SDU (Service Data Unit)
    • SDU is the abbreviation of Service Data Unit. It is the data passed by an upper layer, with the request to transmit the data. It is as well the data which is extracted after reception by the lower layer and passed to the upper layer.
    • SDU는 서비스 데이터 단위 (Service Data Unit)의 약칭 입니다. 상위 계층에서 데이터 전송 요청시 데이터도 함께 전달 됩니다. 하위 계층에 의한 수신 후 데이터가 추출되어 상위 계층으로 전달되는 데이터도 마찬가지이다.
    • SDU는 PDU 부분입니다.
  • PCI (Protocol Control Information)
    • PCI is the abbreviation of 'Protocol Control Information'. This Information is needed to pass a SDU from one instance of a specific protocol layer to another instance. E.g.
    • PCI는 프로토콜 제어 정보(Protocol Control Information)의 약어입니다. 이 정보는 특정 프로토콜 계층의 한 인스턴스에서 다른 인스턴스로 SDU를 전달하기 위해 필요합니다. ( 소스 및 대상 정보가 들어 있습니다.)
    • PCI는 전송측 상의 프로토콜 층에 의해 추가되고 수신측에서 다시 제거됩니다.
  • PDU (Protocol Data Unit)
    • PDU is the abbreviation of 'Protocol Data Unit'.
    • PDU는 프로토콜 데이터 단위(Protocol Data Unit) 의 약어입니다. PDU 는 SDU 와 PCI 를 포함합니다.
    • 전송 측에서 PDU는 상위 계층에서 하위 계층으로 전달되며, 이는 이 PDU를 SDU로 해석합니다.

7.6.2 Interfaces: Interaction of Layers Example "Communication" (1)

SDU and PDU Naming Conventions

Interaction of Layers Example - communication

PDU 및 SDU의 명명은 다음의 규칙을 추천합니다.

For PDU: <bus prefix> <layer prefix> - PDU
For SDU: <bus prefix> <layer prefix> - SDU

The bus prefix and layer prefix are described in the following table: 버스 접두사와 레이어 접두사는 다음 표에 설명되어 있습니다.

bus prefix and layer prefix

  • SF: Single Frame
  • FF: First Frame
  • CF: Consecutive Frame
  • FC: Flow Control

프레임 유형에 대한 자세한 내용은 CAN, TTCAN, LIN 및 FlexRay에 대한 AUTOSAR 전송 프로토콜 사양을 참조하십시오.

  • Examples:
    • I-PDU or I-SDU
    • CAN FF N-PDU or FR CF N-SDU
    • LIN L-PDU or FR L-SDU

7.6.3 Interfaces: Interaction of Layers Example "Communication" (2)

Components

  • PDU Router:
    • 서로 다른 추상 통신 컨트롤러와 상위 계층 간에 PDU 라우팅을 제공합니다
    • 라우터의 크기는 ECU에 따릅니다. (만약, 단 한개의 통신 컨트롤러만 있다면 사이즈는 없습니다.)
    • TP 라우팅을 즉시 제공하고, 전체 TP 데이터가 버퍼링되기 전에 TP 데이터의 전송을 시작합니다.
  • COM:
    • 서로 다른 I-PDU 간에 개별 신호 또는 신호 그룹 라우팅 제공합니다.
  • NM Coordinator:
    • NM 코디네이터가 처리하는 네트워크 관리를 통해 ECU에 연결된 서로 다른 통신 채널의 네트워크 상태 동기화합니다.
  • Communication State Managers:
    • 인터페이스를 통해 통신 시스템의 하드웨어 장치를 시작하고 종료합니다
    • Control PDU groups

7.6.4 Interfaces: Interaction of Layers Example "Communication" (3)

Interaction of Layers Example - commnunication

Note: 이 이미지는 모든 내부 통신 경로에 대해 완전하지 않습니다.

  1. The Interface between PduR and Tp differs significantly compared to the interface between PduR and the Ifs.
  2. PduR과 Tp 사이의 인터페이스는 PduR과 Ifs 사이의 인터페이스와 비교하여 크게 다릅니다. 이경우, TP 가 관여하는 핸드쉐이킹 메커니즘은 I-Pdus 에서의 전송에 대해서 구현합니다.
  3. TTCAN 을 탑재한 CanIf 은 TTCAN이 있건 없건 CanDrv 을 제공합니다. TTCAN 이 없는 CanIf 는 TTCAN 과 CanDrv를 제공할수없습니다.

Note

  • 개인노트
    • 각 BSW 내의 레이어마다 네트워크 계층을 나눌수있다.
      • service Layer : presentation Layer
      • ECU Layer : Network Layer
      • MCU Layer : Datalink Layer
    • 위의 각각의 네트워크 레이어 분류에 따라 N-PDU, I-PDU, L-PDU 등으로 분류할수있다.

7.6.5 Interfaces: Interaction of Layers Example "Communication" (4) - Ethernet Protocol

이 그림은 이더넷 프로토콜 스택과 내부에서의 상호 작용을 보여줍니다.

Ethernet Protocol

7.7 interaction of layers Example 3 -Data Transformation

데이터 전송에 대한 layer간 상호작용예제

7.7.1 Interfaces: Interaction of Layers Example "Data Transformation" (1) - Introduction

  • 다음 페이지에서는 데이터 변환과의 통신을 설명합니다.
    • 소프트웨어 계층은 어떻게 상호작용하는가?
    • 소프트웨어 인터페이스는 어떻게 생겼는가?

7.7.2 Interfaces: Interaction of Layers Example "Data Transformation" (2) - Example and First Look

이 예제는 데이터 변환이 ECU 간 통신에 사용되는 경우 데이터 흐름을 보여줍니다. SW-C는 설정된 데이터를 원격 ECU에 전송하고 데이터를 변환합니다. 이 데이터 변환은 in-place 버퍼 처리를 사용하지 않습니다.

Functionality

  • RTE 는 SOME/IP transformer를 체인의 첫 번째 transformer로 호출하고 SW-C에서 데이터를 전송합니다.
  • SOME/IP transformer는 변환을 실행하고 출력(byte arra)을 RTE에 의해 제공되는 버퍼에 기입합니다.
  • 이후, 상기 RTE는 transformer chain 내의 두번째 Safety transformer 를 실행시킵니다.
  • Safety transformer 의 입력은 SOME/IP transformer 의 출력입니다,
  • Safety transformer는 데이터를 보호하고 출력을 RTE에 의해 제공되는 다른 버퍼에 기입합니다.
    • 내부 버퍼 처리를 사용하지 않기 때문에 새로운 버퍼가 필요합니다.
  • RTE transfers 는 최종 출력 데이터를 바이트 어레이로서 COM 모듈로 전달합니다.

Data Transformation - example and first lock

7.7.3 Interfaces: Interaction of Layers Example "Data Transformation" (3) - Closer Look at Interfaces

example - Closer Look at Interfaces

Architecture Description

RTE 는 System Service Layer에 위치된 transformer를 이용한다.

Interface Description

이 예의 transformers는 다음과 같은 인터페이스를 가지고 있습니다.

SomeIpXf_SOMEIP_Signal1
(
  uint8 *buffer1,
  uint16 *buffer1Length,
  <type> data
)

SafetyXf_Safety_Signal1
(
  uint8 *buffer2,
  uint16 *buffer2Length,
  uint8 *buffer1,
  uint16 buffer1Length
)

7.7.4 Interfaces: Interaction of Layers Example "Data Transformation" (4) - COM Based Transformation

Goal

  • COM Based Transformer는 고정된 통신 matrix 에 기초하여 transformer chain 에 직렬화 기능을 제공합니다.
  • The fixed communication matrix allows an optimized placement of signals into PDUs.
  • 고정 통신 matrix 는 PDU에 신호를 최적화된 배치를 허용합니다.(boolean 데이터는 PDU에서 하나의 비트만 차지하도록 구성될 수 있습니다) 이를 통해 Can 또는 Lin과 같은 low payload networks 에서 transformer chains 을 사용할 수 있습니다.
  • COM Based Transformer 는 첫번째 transformer(시리얼라이저)이며, RTE 를 통해 애플리케이션으로부터 데이터를 얻습니다.
  • COM 구성(communication matrix)에 기초로하는 데이터는 COM 모듈의 것과 정확히 같은 방식으로 직렬화됩니다. (endianess, sign extension).
  • 다른 transformers는 CRC와 시퀀스 카운터(SC)를 가지도록 페이로드를 향상시킬 수 있습니다.
  • transformer payload가 Com_SendSignalGroupArray API를 통해 바이트 하나의 배열로 COM 모듈로 전달됩니다.
  • The COM module can be configured to perform transmission mode selection based on the communication matrix definition.
  • COM 모듈은 통신 매트릭스 정의에 기초하여 전송 모드 선택을 수행하도록 설정 될 수 있다.

COM Based Transformation

반응형

'SW 개발'의 다른글

  • 현재글CLASSIC AUTOSAR 기본 - 07 Interfaces

관련글

댓글

티스토리툴바