【AutoSAR 架构介绍】

这篇具有很好参考价值的文章主要介绍了【AutoSAR 架构介绍】。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

AutoSAR简介

AUTOSARAutomotive Open System Architecture(汽车开放系统架构)的首字母缩写,是一家致力于制定汽车电子软件标准的联盟。

AUTOSAR是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立,各成员保持开发合作伙伴关系。

2003年起,各伙伴公司携手合作,致力于为汽车工业开发一个开放的、标准化的软件架构。AUTOSAR这个架构有利于车辆电子系统软件的交换与更新,并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。

此外,AUTOSAR在确保产品及服务质量的同时,提高了成本效率。整车软件系统可通过AUTOSAR架构对车载网络、系统内存及总线的诊断功能进行深度管理,它的出现有利于整车电子系统软件的更新与交换,并改善了系统的可靠性和稳定性。

目前支持AUTOSAR标准的工具和软件供应商都已经推出了相应的产品,提供需求管理,系统描述,软件构件算法模型验证,软件构建算法建模,软件构件代码生成,RTE生成,ECU配置以及基础软件和操作系统等服务,帮助OEM实现无缝的系统软件架构开发流程。

AUTOSAR计划目标主要有三个:1)建立独立于硬件的分层软件架构;2)为实施应用提供方法论,包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU3)制定各种车辆应用接口规范,作为应用软件整合标准,以便软件构件在不同汽车平台复用。

【AutoSAR 架构介绍】,经验分享AutoSar伙伴

核心合作伙伴(9)

宝马、大众、戴姆勒、PSA、博世、大陆集团、福特,通用汽车、丰田

高级合作伙伴(58+)

沃尔沃汽车、本田、长城、矢量,Mentor Graphics

。。。。

发展合作伙伴(49+)

【AutoSAR 架构介绍】,经验分享

AutoSar组织

【AutoSAR 架构介绍】,经验分享

工作组的工作重点如下:

指定AUTOSAR运行时环境,以提供车辆网络所有节点之间的ECU内部和内部通信。

定义基本软件模块和汽车操作系统领域现有解决方案的需求和分析。

定义方法和数据交换格式,以描述车辆E/E系统架构的交换相关元素。

定义AUTOSAR运行时环境的API和服务接口。

定义不同车辆领域的标准化接口。

定义验收测试。

集成自适应平台的示例AUTOSAR软件实现。

成员包括核心、高级和发展合作伙伴以及与会者,他们代表了来自各个领域的合作伙伴的广泛知识和经验。

AutoSar Working Groups

所有活动都被分配用于开发和维护经典平台、自适应平台、验收测试、应用程序接口和跨标准功能。

【AutoSAR 架构介绍】,经验分享

【AutoSAR 架构介绍】,经验分享

AutoSar标准

Classic Platform (CP)

Classic Platform 是AUTOSAR为具有严格实时性和安全性约束的嵌入式系统提供的解决方案。

软件体系结构概述(CP)

自适应平台是AUTOSAR的高性能计算ECU解决方案,用于为自动驾驶等用例构建故障操作系统。

软件体系结构内容(CP)

经典平台和自适应平台的通用部分作为一个名为AUTOSAR Foundation的单独标准发布。

公共部分是例如总线协议和方法的公共方面。

AUTOSAR验收测试是总线级和应用程序级的系统测试,用于验证AUTOSAR堆栈相对于应用软件组件和通信总线的行为。

AUTOSAR在以下五个车辆领域的语法和语义方面标准化了大量应用程序接口:车身和舒适性、动力传动系统发动机、动力传动系变速器、底盘控制以及乘员和行人安全。

CLASSIC平台与ADAPTIVE平台技术特性比较

CLASSIC PLATFORM

ADAPTIVE PLATFORM

Operating system based on OSEK

Operating system based on POSIX (PSE51 with optional extensions)

Execution of code directly from ROM

Application is loaded from persistent memory into RAM

Same address space for all applications (MPU support for safety)

Each application has its own (virtual) address space (MMU support)

Optimized for signal-based communication (CAN, FlexRay)

Designed for service-oriented communication

Fixed task configuration

Support of multiple dynamic scheduling strategies

Specification

Specification and code

APCP并不是完全独立的。例如,基于APECU和基于CPECU可以连接到同一个网络,因此二者均需要与各种通信协议兼容。除此之外,在系统设计信息等交付形式上,若AP/CP也没有达成一致的话,将会有更多的麻烦,特别是对车企一方来说,他们的管理会变得更加复杂。所以,APCP之间还是有很多共同点的!

把这些共同的部分截取出来,我们将其定义被称为Foundation (FO)标准组。

AUTOSAR RoadMap

【AutoSAR 架构介绍】,经验分享

软件架构概述(CP)

架构层概述 

AUTOSAR架构在最高抽象级别上区分了三个软件层:应用程序、运行时环境和在微控制器上运行的基本软件。

分层软件体系结构描述了AUTOSAR的软件架构:

它以自上而下的方法描述了AUTOSAR软件的层次结构,将基本软件模块映射到软件层并显示它们的关系。

【AutoSAR 架构介绍】,经验分享

 AUTOSAR基础软件进一步分为服务层、ECU抽象层、微控制器抽象层和复杂驱动层。

•     服务层(Service Layer),这一层基础软件提供了汽车ECU非应用相关的服务,包括OS,网络通讯,内存管理(NVRAM),诊断(UDS,故障管理等),ECU状态管理模块等,它们对ECU的应用层功能提供辅助支持,这一层软件在不同领域的ECU中也非常相似,例如不同的ECU中的OS的任务周期和优先级不同,不同的ECU中的NVRAM的分区不同,存储的内容不同。

•     ECU抽象层(ECU Abstract Layer),这一层软件提供了ECU应用相关的服务,它是对一个ECU的抽象,它包括了所有的ECU的输入输出,比如ADDIOPWM等,这一层软件直接实现了ECU的应用层功能,可以读取传感器状态,可以控制执行器输出,不同领域的ECU会有很大的不同。

•     MCALMicrocontroller Absstraction Layer),这一层软件是对ECU所使用的主控芯片的抽象,它跟芯片的实现紧密相关,是ECU软件的最底层部分,直接和主控芯片及外设芯片进行交互,它的作用是将芯片提供的功能抽象成接口,然后把这些接口提供给上边的服务层/ECU抽象层使用。

•     复杂驱动(Complex Drivers),汽车ECU中有一些领域的ECU会处理相当复杂的硬件信号,执行相当复杂的硬件动作,例如发动机控制,ABS等,这些功能相关的软件很难抽象出来适用于所有的汽车ECU,它是跟ECU的应用以及ECU所使用的硬件紧密相关的,属于AUTOSAR构架中在不同的ECU上无法移植的部分。

【AutoSAR 架构介绍】,经验分享

最下层

可直接访问内部外围设备的驱动程序。

  • 通信驱动器(SPI、CAN)
  • I/O驱动器(ADC、PWM、DIO)
  • 存储器驱动程序(闪存、EEPROM)
  • 微控制器驱动程序(SPI,通用定时器)

取决于微控制器

任务

  • 使更高的软件层独立于μC

属性

  • 实现:取决于μC
  • 上接口:标准化和μC
  • 独立的

【AutoSAR 架构介绍】,经验分享

 微控制器抽象层驱动程序接口

访问外围设备和设备的API

  • 微控制器
  • 内部的
  • 外部的

服务层是基础的最高层

同样适用于应用软件相关性的软件:虽然ECU抽象层涵盖了对I/O信号的访问,但服务层提供:

  • 操作系统功能
  • 车辆网络通信和管理服务
  • 内存服务(NVRAM管理)
  • 诊断服务(包括UDS通信、错误记忆和故障处理)
  • ECU状态管理、模式管理
  • 必然的

任务

为应用程序、RTE和基本软件模块提供基本服务。

属性

实现:大部分μC和ECU硬件独立

上层接口:μC和ECU硬件独立

【AutoSAR 架构介绍】,经验分享

RTE是为应用软件(AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件)提供通信服务的层。

  • 在RTE之上,软件体系结构风格从“分层”变为“组件风格”。
  • AUTOSAR软件组件通过RTE与其他组件(ECU间和/或ECU内)和/或服务进行通信。

【AutoSAR 架构介绍】,经验分享

 复杂驱动程序层的范围从硬件到RTE。

  • AUTOSAR中未指定的硬件

提供集成专用功能的可能性,例如设备驱动程序:

  •  其未在AUTOSAR内指定,
  •  具有非常高的时序约束,或者
  •  用于迁移目的等。

属性

实现:可能取决于应用程序、μC和ECU硬件

上层接口:可能是应用程序,μC和ECU硬件相关

【AutoSAR 架构介绍】,经验分享

基础软件层被进一步划分为功能组。服务的例子有系统、内存和通信服务。

输入/输出(I/O)

对传感器、执行器和ECU车载外围设备的标准化访问

 记忆力

对内部/外部存储器(非易失性存储器)的标准化访问

 加密

对加密原语的标准化访问,包括内部/外部硬件加速器

 表达

标准化访问:车辆网络系统、ECU车载通信系统和ECU内部软件

 车外通信

标准化接入:车载通信、车载无线网络系统、ECU车外通信系统

 系统

提供标准化(操作系统、计时器、错误存储器)和ECU特定(ECU状态管理、看门狗管理器)服务和库功能

驱动程序包含控制和访问内部或外部设备的功能。

内部设备位于微控制器内部。内部设备示例如下:

  •  内部EEPROM
  •  内部CAN控制器
  •  内部ADC

内部设备的驱动程序称为内部驱动程序,位于微控制器抽象层。

外部设备位于微控制器外部的ECU硬件上。外部设备的示例包括:

  •  外部EEPROM
  •  外部看门狗
  •  外部闪光灯

用于外部设备的驱动器被称为外部驱动器,并且位于ECU抽象层中。它通过微控制器抽象层的驱动程序访问外部设备。

通过这种方式,AUTOSAR还支持集成在系统基础芯片(SBC)中的组件,如收发器和看门狗。

 示例:具有SPI接口的外部EEPROM的驱动程序访问外部

EEPROM通过SPI总线的处理器/驱动器。

例外情况:

用于存储器映射的外部设备(例如,外部闪存)的驱动器可以直接访问微控制器。这些外部驱动器位于微控制器抽象层中,因为它们依赖于微控制器。

接口(接口模块)包含从架构上位于其下方的模块中抽象的功能。例如,从特定设备的硬件实现中抽象出来的接口模块。它提供了一个通用API来访问特定类型的设备,该设备独立于该类型现有设备的数量,并独立于不同设备的硬件实现。

该接口不会更改数据的内容。

通常,接口位于ECU抽象层中。

示例:CAN通信系统的接口提供了一个通用API,用于访问CAN通信网络,该网络独立于ECU内CAN控制器的数量,并且独立于硬件实现(片上、片外)。

处理程序是一个特定的接口,它控制一个或多个客户端对一个或更多驱动程序的并发、多个和异步访问。也就是说,它执行缓冲、排队、仲裁和多路复用。

处理程序不会更改数据的内容。

处理程序功能通常包含在驱动程序或接口中(例如SPIHandlerDriver、ADC驱动程序)。

经理为多个客户提供特定的服务。在纯处理程序功能不足以从多个客户端进行抽象的所有情况下,都需要它。

除了处理程序功能外,管理器还可以评估、更改或调整数据的内容。

通常,管理器位于服务层

示例:NVRAM管理器管理对内部和/或外部存储器设备(如闪存和EEPROM存储器)的并发访问。它还执行分布式和可靠的数据存储、数据检查、提供默认值等。

 【AutoSAR 架构介绍】,经验分享

Libraries是用于相关目的的函数集合

  • 可以由BSW模块(包括RTE)、SW C、库调用
  • 在同一保护环境中的调用方上下文中运行
  • 只能调用库
  • 重新进入
  • 没有内部状态
  • 不需要任何初始化
  • 是同步的

AUTOSAR中指定了以下库:

  •  不动点数学,
  •  浮点数学,
  •  定点数据的插值,
  •  浮点数据的插值,
  •  比特处理,
  •  E2E通信,
  •  CRC计算,
  •  扩展功能(例如64位计算、滤波等)

【AutoSAR 架构介绍】,经验分享

软件架构内容 (CP)

BSW 模块

有100多个基本软件模块。

【AutoSAR 架构介绍】,经验分享

 抽象层

μC抽象层由以下模块组组成:

  • 微控制器驱动程序
  • 通信驱动程序
  • 内存驱动程序
  • I/O驱动程序
  • 加密驱动程序
  • 无线通信驱动程序

μC抽象层由以下模块组组成:

 微控制器驱动程序

内部外围设备的驱动程序(例如看门狗、通用定时器)

具有直接μC访问的功能(例如核心测试)

 通信驱动程序

车载ECU(例如SPI)和车辆通信(例如CAN)的驱动器。

OSI层:数据链路层的一部分

 内存驱动程序

片上存储器设备(如内部闪存、内部EEPROM)和存储器映射外部存储器设备的驱动程序

(例如外部闪存)

 I/O驱动程序:模拟和数字I/O驱动器(例如ADC、PWM、DIO)

 SHE或HSM等芯片加密设备的加密驱动程序

 无线通信驱动程序:无线网络系统的驱动程序(车内或车外通信)

【AutoSAR 架构介绍】,经验分享

SPIHandlerDriver是μC抽象层的一个组件,它允许多个客户端同时访问一条或多条SPI总线。

SPIHandlerDriver允许多个客户端同时访问一条或多条SPI总线。

为了抽象专用于芯片选择的SPI微控制器引脚的所有特征,这些特征应由SPIHandlerDriver直接处理。

这意味着这些引脚在DIO驱动器中不可用。

 【AutoSAR 架构介绍】,经验分享

复杂驱动

复杂驱动程序是在基本软件堆栈中实现非标准化功能的模块。

  • SW Cs的上层接口:根据AUTOSAR(AUTOSAR接口)规定和实现
  • 下层接口:限制访问标准化接口

任务:

满足处理复杂传感器和执行器的特殊功能和时间要求

属性:

实现:高度依赖于μC、ECU和应用程序

SW Cs的上层接口:根据AUTOSAR(AUTOSAR接口)规定和实现

下层接口:限制访问标准化接口

 【AutoSAR 架构介绍】,经验分享

I/O硬件抽象

 I/O硬件抽象是一组从外围I/O设备(片上或板上)的位置和ECU硬件布局(例如μC引脚连接和信号电平反转)中抽象出来的模块。

表示连接到ECU硬件的I/O信号(例如电流、电压、频率)。
从更高的软件层隐藏ECU硬件和布局属性。

【AutoSAR 架构介绍】,经验分享

Communication Hardware Abstraction 

通信硬件抽象是从通信控制器的位置和ECU硬件布局中抽象出来的一组模块。对于所有通信系统,都需要特定的通信硬件抽象(例如LIN、CAN、FlexRay)。

示例:ECU有一个带2个内部CAN通道的微控制器和一个带4个CAN控制器的附加板载ASIC。CAN-ASIC通过SPI连接到微控制器。

通过总线专用接口(例如CAN接口)访问通信驱动程序。

任务:

提供平等的机制来访问总线通道,无论其位置如何(芯片上/板上)

属性:

实现:μC无关,ECU硬件相关,外部设备相关

上层接口:总线相关,μC和ECU硬件无关

【AutoSAR 架构介绍】,经验分享

Memory Hardware Abstraction  

存储器硬件抽象是一组从外围存储器设备(片上或板上)的位置和ECU硬件布局中抽象出来的模块。

示例:片上EEPROM和外部EEPROM设备可以通过相同的机制访问。
存储器驱动程序通过存储器专用抽象/仿真模块(例如EEPROM抽象)访问。
通过在闪存硬件单元上模拟EEPROM抽象,可以通过存储器抽象接口对这两种类型的硬件进行公共访问。
任务:
提供访问内部(芯片上)和外部(板载)存储器设备以及存储器硬件类型(EEPROM、闪存)的同等机制。
属性:
实现:μC独立,外部设备相关
上层接口:μC,ECU硬件和存储设备独立

【AutoSAR 架构介绍】,经验分享

Onboard Device Abstraction

 车载设备摘要包含ECU车载设备的驱动程序,这些设备不能被视为传感器或执行器,如内部或外部看门狗。这些驱动程序通过μC抽象层访问ECU车载设备。

任务:
ECU专用车载设备摘要。
属性:
实现:μC独立,外部设备相关
上层接口:μC独立,部分依赖ECU硬件

【AutoSAR 架构介绍】,经验分享

Crypto Hardware Abstraction

加密硬件抽象是一组从加密原语(基于内部或外部硬件或软件)的位置进行抽象的模块。

任务:
提供平等的机制来访问内部(芯片上)和软件加密设备。
属性:
实现:μC无关
上层接口:μC、ECU硬件和加密设备独立 

【AutoSAR 架构介绍】,经验分享

Crypto Services

加密服务由一个模块组成,即加密服务管理器。它负责加密作业的管理和密钥的存储。 

任务:以统一的方式为应用程序提供加密原语和密钥存储。
摘要来自硬件设备和属性。
属性:
实现:μC和ECU硬件独立,高度可配置
上层接口:μC和ECU硬件独立,根据AUTOSAR指定和实现(AUTOSAR接口)

【AutoSAR 架构介绍】,经验分享

Communication Services

通信服务是一组用于车辆网络通信(CAN、LIN、FlexRay和以太网)的模块。它们通过通信硬件抽象与通信驱动程序接口。

任务:
为车辆网络提供统一的通信接口。
为网络管理提供统一服务。
为诊断通信提供统一的车辆网络接口
在应用程序中隐藏协议和消息属性。
属性:
实现:μC和ECU硬件独立,部分取决于总线类型
上层接口:μC、ECU硬件和总线类型独立
每个相关车辆网络系统的通信服务将在以下页面上详细说明。
 【AutoSAR 架构介绍】,经验分享

CAN Communication Stack

CAN通信堆栈是一组模块,用于与通信系统CAN进行车辆网络通信。
为CAN网络提供统一的接口。在应用程序中隐藏协议和消息属性。

CAN2.0版本
CANFD
实现:μC和ECU硬件独立,部分依赖CAN。

  •  AUTOSAR COM、通用NM(网络管理)接口和诊断通信管理器适用于所有车辆网络系统,并作为每个ECU的一个实例存在。
  •  通用NM接口仅包含一个调度器。不包括其他功能。在网关ECU的情况下,它还可以包括NM协调器功能,该功能允许同步多个不同的网络(相同或不同类型)以同步唤醒或关闭它们。
     
  •  CAN NM特定于CAN网络,并将根据CAN车辆网络系统进行实例化。
  •  通信系统特定的Can State Manager处理与通信系统相关的启动和关闭功能。此外,它控制COM的不同选项来发送PDU和监视信号超时。

【AutoSAR 架构介绍】,经验分享

TCP/IP Communication stack

TCP/IP通信堆栈是用于与通信系统TCP/IP进行车辆网络通信的一组模块。

为TCP/IP网络提供统一的接口。在应用程序中隐藏协议和消息属性。
TcpIp模块实现TCP/IP协议家族的主要协议(TCP、UDP、IPv4、IPv6、ARP、ICMP、DHCP),并通过以太网提供基于套接字的动态通信。
 套接字适配器模块(SoAd)是TcpIp模块中唯一的上层模块。 

【AutoSAR 架构介绍】,经验分享

 Memory Services

内存服务由一个模块组成,即NVRAM管理器。它负责管理非易失性数据(从不同的内存驱动程序读取/写入)。

  • 以统一的方式向应用程序提供非易失性数据
  • 内存位置和属性摘要
  • 提供非易失性数据管理机制

以统一的方式向应用程序提供非易失性数据。从内存位置和属性中提取。提供非易失性数据管理机制,如保存、加载、校验和保护和验证、可靠存储等。
属性:
实现:μC和ECU硬件独立,高度可配置
上层接口:μC和ECU硬件独立,根据AUTOSAR指定和实现(AUTOSAR接口)

【AutoSAR 架构介绍】,经验分享

 System Services

系统服务是一组模块和功能,可供所有层的模块使用。例如实时操作系统(包括定时器服务)和错误管理器。

  • μC相关(如操作系统),并支持特殊的μC功能(如时间服务),
  • 部分依赖于ECU硬件和应用程序(如ECU状态管理器)或独立于硬件和μC。

为应用程序和基本软件模块提供基本服务。
属性:
实现:部分μC、ECU硬件和特定应用
上层接口:μC和ECU硬件独立

 【AutoSAR 架构介绍】,经验分享

SWC Component Type

【AutoSAR 架构介绍】,经验分享

 Atomic Software Components (SWC)

Atomic SWC是可以映射到ECU的最小软件单元。

【AutoSAR 架构介绍】,经验分享

SWC可以通过组件连接进行连接
端口定义了通信需求
接口和数据类型定义了通信的内容
端口可以通过部件连接器连接

【AutoSAR 架构介绍】,经验分享 

Composition Software Components (CSWC)

合成SWC是原子SWC和合成SWC的逻辑合成。

【AutoSAR 架构介绍】,经验分享 

组成部分边界上的港口称为外港
组合内部的端口称为内部端口
委派连接连接内部和外部端口
端口必须是“已提供”或“必需”的相同类型 

【AutoSAR 架构介绍】,经验分享

SWC Type and Prototype 

SWC类型就像一个可重复使用的软件单元
原型代表SWC类型的实例

  • 例如,组合包含参考SWC类型的组件原型
  • 例如两个原型(组件1和组件2是同一软件组件类型SWC1的实例)

【AutoSAR 架构介绍】,经验分享

Flattening Compositions

组合物可以包含原子和/或复合SWC的原型(实例)
为了避免以后的名称冲突,必须取消组合
平面合成仅包含ATOMIC组件

【AutoSAR 架构介绍】,经验分享 

SWC Design - Flow

【AutoSAR 架构介绍】,经验分享 

SWC Design - DataType

“数据类型创建” 流程

【AutoSAR 架构介绍】,经验分享

SWC Design - DataType

实施数据类型:

Type

Scene

Sample

Value

Define a datatype of base type, can add compu method data constraintinvalid value

typedef unsigned long uint32;

Type Reference

A type reference expresses a redirection to another data typenot need to choose base type

typedef MySimpleType MyTypeRef;

Data Reference

A data reference expresses a pointer type as defined by the C code statement

typedef MySimpleType * MyDataRef; or typedef void * MyDataRef;. 

Union

Only one of the union elements might hold data at a given time

typedef union{

  uint32 UnionElement0;

} MyUnitCode;

Array

The element type of the can be Value, Type Reference, Array or Record and a fixed or variable size

typedef uint64 MyArrayCode[5];

Record

define a struct type

typedef struct{

  uint16 RecordElement;

  CounterType RecordElement_1;

} MyRecordCode;

 SWC Design - Interface

“接口创建”流程

Sender/Receiver Communication

1..m Multiplicity (Multicast)

n..1 Multiplicity

Transfer of Data element
of a certain Data type (e.g. Uint8)

Data Elements are VariablesBase Typerecord

Client/Server Communication

n..1 Multiplicity

Sync or async

Transfer of Arguments to/from an Operation

Arguments are Variables

Arguments have a direction in, out, inout

Return of ErrorCodes possible using ApplicationError

【AutoSAR 架构介绍】,经验分享

SWC Design – Create Component

Define Atomic Component Sample :

 【AutoSAR 架构介绍】,经验分享

SWC Design – Runnable Design

T riggers
I nit

The runnable entity is triggered exactly once on start up of the component.

Runnables with init triggers are not allowed to have other triggers.

P eriodic

The runnable entity is periodically triggered.

【AutoSAR 架构介绍】,经验分享 

SWC Design – Runnable Design

T riggers
O n Data Reception

The runnable entity is triggered upon an incoming data element.

Can select data elements of all receiver port of the component type.

Used for unqueued communication.

On Data Reception Error

The runnable entity is triggered upon an incoming data element.

Can select data elements of all receiver port of the component type.

On Data Send Completion

The runnable entity is triggered upon completion of sending an output data element (Tx Acknowledge).

Can select data elements of all sender port of the component type.

On Operation Invocation

The runnable entity is triggered upon an incoming server call.

Can select data elements of all server port of the component type.

An operation invocation trigger may not be combined with any other kind of trigger. It may only be combined with triggers of other operations, provided that they have a compatible list of argument prototypes.

On Operation Call Return

The runnable entity is triggered upon return of an asynchronous operation

     call of a client port prototype.

Can select data elements of all client port of the component type.

Access Points
Receive Data

The runnable entity may receive data from a receiver port prototype.

This kind of port access is only available for queued data element prototypes.

Read Data

The runnable entity may read data from a receiver port prototype.

This kind of port access is only available for unqueued data element prototypes

 【AutoSAR 架构介绍】,经验分享

Access Points
Send Data

The runnable entity may send data to a sender port prototype.

This kind of port access is only available for queued data element prototypes.

Write Data

The runnable entity may write data to a sender port prototype.

This kind of port access is only available for unqueued data element prototypes

Invoke Operations

The runnable entity may invoke operations of a client port prototype

AutoSAR Interface

Type

Scene

AUTOSAR Interface

An "AUTOSAR Interface" defines the information exchanged between software components and/or BSW modules. This description is independent of a specific programming language, ECU or network technology. AUTOSAR Interfaces are used in defining the ports of

software-components and/or BSW modules. Through these ports software-components and/or BSW modules can communicate with each other (send or receive information or invoke services). AUTOSAR makes it possible to implement this communication between Software-Components and/or BSW modules either locally or via a network.

Standardized AUTOSAR

Interface

A "Standardized AUTOSAR Interface" is an "AUTOSAR Interface" whose

syntax and semantics are standardized in AUTOSAR. The "Standardized

AUTOSAR Interfaces" are typically used to define AUTOSAR Services,

which are standardized services provided by the AUTOSAR Basic

Software to the application Software-Components.

Standardized Interface

A "Standardized Interface" is an API which is standardized within AUTOSAR without using the "AUTOSAR Interface" technique. These "Standardized Interfaces" are typically defined for a specific programming language (like "C"). Because of this, "standardized interfaces" are typically used between software-modules which are always on the same

ECU. When software modules communicate through a "standardized interface", it is NOT possible any more to route the communication between the software-modules through a network.

 【AutoSAR 架构介绍】,经验分享

【AutoSAR 架构介绍】,经验分享 

This example shows how the NVRAM Manager and the Watchdog Manager interact with drivers on an assumed hardware configuration 

 【AutoSAR 架构介绍】,经验分享

The ECU hardware includes an external EEPROM and an external watchdog connected to the microcontroller via the same SPI.
The SPIHandlerDriver controls the concurrent access to the SPI hardware and has to give the watchdog access a higher priority than the EEPROM access.
The microcontroller includes also an internal flash which is used in parallel to the external EEPROM. The EEPROM Abstraction and the Flash EEPROM Emulation have an API that is semantically identical.
The Memory Abstraction Interface can be realized in the following ways:
 routing during runtime based on device index (int/ext)
 routing during runtime based on the block index (e.g. > 0x01FF = external EEPROM)
 routing during configuration time via ROM tables with function pointers inside the NVRAM Manager (in this case the Memory Abstraction Interface only exists „virtually“) 

 【AutoSAR 架构介绍】,经验分享

This example shows the Example “Communication”

PDU Router:

  • Provides routing of PDUs between different abstract communication controllers and upper layers
  • Scale of the Router is ECU specific (down to no size if e.g. only one communication controller exists)
  • Provides TP routing on-the-fly. Transfer of TP data is started before full TP data is buffered

COM:

  • Provides routing of individual signals or groups of signals between different I-PDUs

NM Coordinator:

  • Synchronization of Network States of different communication channels connected to an ECU via the network managements handled by the NM Coordinator

Communication State Managers:

  • Start and Shutdown the hardware units of the communication systems via the interfaces 
  • Control PDU groups

 【AutoSAR 架构介绍】,经验分享

This example shows shows the interaction of and inside the Ethernet protocol stack.

 【AutoSAR 架构介绍】,经验分享

This example shows the data flow if data transformation is used for inter-ECU communication. A SW-C sends data configured to be transmitted to a remote ECU and subject to data transformation. This data transformation doesn’t use in-place buffer handling.

  • The RTE calls the SOME/IP transformer as the first transformer in the chain and transfers the data from the SW-C.
  • The SOME/IP transformer executes the transformation and writes the output (byte array) to a buffer provided by the RTE.
  • The RTE executes the Safety transformer which is second in the transformer chain. The Safety transformer’s input is the output of the SOME/IP transformer.
  • The Safety transformer protects the data and writes the output into another buffer provided by the RTE. A new buffer is required because in-place buffer handling is not used.
  • The RTE transfers the final output data as a byte array to the COM module.

【AutoSAR 架构介绍】,经验分享 

 文章来源地址https://www.toymoban.com/news/detail-600798.html

 

到了这里,关于【AutoSAR 架构介绍】的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Matlab 使用经验分享(常用函数介绍;矩阵常见计算)

    大家好!最近有很多朋友询问我关于 Matlab 的使用,于是我决定写一篇博客来分享一下我的经验。对于数学和编程爱好者来说,Matlab 是一个非常有用的工具。我自己在数学实验和数学建模竞赛中也经常使用它。那么,为什么 Matlab 这么受欢迎呢? MATLAB 是美国MathWorks 公司自2

    2024年02月10日
    浏览(42)
  • SuperPoint和SuperGlue 的算法介绍及学习应用经验分享

    特征点提取和匹配是多视图几何的基础理论知识,在SLAM相关领域有着重要作用。比如在视觉SLAM中,著名ORBSLAM就是基于特征点法的,一般通过特征点提取和匹配,再根据匹配关系进行几何求解就可以得到位姿。 一般流程为 1.输入一对图像 2.提取特征点 3.进行匹配 4.根据匹配关

    2024年01月19日
    浏览(45)
  • GAMS---典型优化模型和算法介绍、GAMS安装和介绍、GAMS程序编写、GAMS程序调试、实际应用算例演示与经验分享

    优化分析是很多领域中都要面临的一个重要问题,求解优化问题的一般做法是:建立模型、编写算法、求解计算。常见的问题类型有线性规划、非线性规划、混合整数规划、混合整数非线性规划、二次规划等,优化算法包括人工智能算法和内点法等数学类优化方法。算法编写

    2024年02月16日
    浏览(45)
  • 技术分享| 融合通讯的架构介绍

    在融合通讯中,我们经常听到如下一些术语:MCU服务,SFU架构,MESH架构,星形网络等等。很多客户听到这些数据都是一脸雾水,经常说我们就是要一个可以把多种设备拉到同一个会议中,怎么搞这么复杂。今天我们就来聊聊这些术语都从哪来的,分别都应用在什么地方,我们

    2024年02月12日
    浏览(38)
  • 【经验分享】从事安全领域多年的攻城狮告诉你嵌入式物联网的数据安全到底要怎么做?(读《数据安全与流通 技术、架构与实践》一书有感)

    【经验分享】从事安全领域多年的攻城狮告诉你嵌入式物联网的数据安全到底要怎么做? 虽然在当下,物联网发展得非常迅猛,在各行各业都落地开花;但是在繁华的背后, 数据安全 这个敏感话题必须要提上议程。那么,在物联网领域,数据安全究竟要怎么做呢?这里面涉

    2024年02月07日
    浏览(49)
  • [AutoSar NVM] 存储架构

    依AutoSAR及公开知识辛苦整理, 禁止转载 。  专栏 《深入浅出AutoSAR》, 全文 1600  字. 图片来源: 知乎 汽车的ECU内存中有很多不同类型的变量,这些变量包括了车辆各个系统和功能所需的数据。大部分变量在ECU掉电后就会丢失,因为它们是易失性数据,无法长期保存。然而

    2024年02月08日
    浏览(56)
  • AUTOSAR 架构简要概述

    汽车ECU 嵌入式系统分为:应用软件层(Application Software Layer,ASW)、运行时环境(Runtime Environment,RTE)、基础软件层(Basic Software Layer,BSW)和微控制器(Microcontroller);如下图所示: ASW: 为应用层逻辑实现,由用户自定义开发,与控制器逻辑强相关,一般为模型; RTE: 中间接口层,起

    2024年02月07日
    浏览(42)
  • Autosar基础安全架构简介

    AUTOSAR基础安全架构(BSW Security)是AUTOSAR标准中的一个模块,旨在提供用于保护汽车电子系统的基本安全功能和服务。基础安全架构包括访问控制、身份认证、加密、数字签名、密钥管理等关键安全功能。 下面详细介绍AUTOSAR基础安全架构的主要组件和作用: 1. 安全生命周期

    2024年02月05日
    浏览(40)
  • Autosar-软件架构

    架构分层是实现软硬件分离的关键,它也使得汽车嵌入式系统控制软件开发者,得以在ECU软件开发与验证过程中,摆脱对硬件系统的依赖。 整个架构从上到下分层依次为:应用层(Application Software Layer),运行时环境(Runtime Environment,RTE),基础软件层(Basic Software Layer,

    2023年04月22日
    浏览(68)
  • 汽车架构解析:python解析Autosar架构的ARXML

    Autosar架构下arxml文件作为通用数据库文件,在数据传输和存储中起到关键作用。行业上其实有一些arxml的工具可以将arxml转换成dbc,再将dbc转换成自己想要的数据,但是拿到的数据是不完整的,arxml有一些数据dbc是没有的,也根据缺少的数据直接到ARXML拿,不用硬解ARXML。 想要

    2024年02月12日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包