AUTOSAR架构简述

1、请选择 Web Layout浏览模式1. 总体概述AUTOSAR汽车开放系统架构），整车软件系统可以通过AUTOSA礫构对车载网络、系统内存及总线诊断进行深度管理， 他的出现有利于整车电子系统软件的更新及交换，并改善系统的 可靠性和稳定性。目前支持AUTOSAR标准的工具和软件供应商都 已经推出了相应的产品，提供需求管理，系统描述，软件构件算 法模型验证，软件构建算法建模，软件构件代码生成，RTE（ Run time Environment ）生成，ECU配置以及基础软件和操作系统等服务，帮 助OEM实现无缝的系统软件架构开发流程。AUTOSAR划目标主要有三个：1）建立独立于硬件的分层软件架

2、构；2）为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并 将应用软件整合至ECU3）制定各种车辆应用接口规范，作为应用软件整合标准，以便软件构件在不同汽车平台复用。2. 分层概述Application LayeRuntime environjAutosarAUTOSAF体系架构分层标准1) 应用层(Application Layer)Basic softwareMicrocontroLl应用层中的功能由各软件组件SWC(softwarecompo nent)实现，组件中封装了部分或者全部汽车 电子功能，包括对其功能的具体实现以及描述，比 如控制汽车大灯、空调等部件的运作，但是与汽车 硬件

3、系统没有连接。1.1) 软件组件(software component)软件组件 SWC(software component)是由 Atomic component(最小逻 辑单元)组成。Atomic component 最小逻辑单元有 Application、 Se nsor/actuator(传感器/执行器)两种类型。其中 Application是算法实现了类型，能在ECU中自由映射；Sen so、Actuator 是为 Applicatio n 提供的I/O端口类型，用于与 ECU绑定，但不可像Application那样能在各 ECU上自由映射。数个SWC的逻辑集合组合成Composi

4、tion。Light ControlComposition ComponentSWC组成实类1.2）端口（ ports）端口 Ports是用来和其他SWC通信的。通信 内容分别为Data element（数据元）与operations（操作）。其中，Data elements 用 Sender/Receiver 通讯方式；operations用Client/Server通讯方式。通讯方式发送-接收端口( Sender/Receiver )用来传输数据，具有一个通信端口可以包含多种数据类 型特点。但如果一个数据类型要通过总线传输， 那么它必须与一个信号对应起来，数据类型既可 以是简单的数据类型(

5、integer, float)，也可以是复杂类型(array, record) 。通信方式:1:n 或 n:1。Roof ECUData element:Light Dimmer Light_DimniXIRTEData element: DoorOpen 1mappingBus、Signal:DoDrLeft_Open客户端一服务器端口 (Client/Server )用来提供Operation服务，具有一个客户端一服务器 端口可以包含多种 Operati on和同步或是异步 通信特点，一个客户端一服务器端口可以包含多 种Operations操作，Operations 操作也可被单 个调用。

6、通信方式:1:n或n:1。1.3) 可运行实体(Runables entities)可运行实体简称 Runn ables。可运行实体包含实际实现的函数，可以是具体的逻辑算法或是 实际操作。可运行实体由RTE周期性或是事件触/ triggered ever： void SA_Door_Left Std_ReturnType ； boolean DoorOpeitatus=Rte Writt2)Run time en vir onment 层(RTE中间件部分给应用层提供了通信手段，这里的通信 是一种广义的通讯，可以理解成接口，应用层与其他软 件体的信息交互有两种，第一种是应用层中的不同模块 之间

7、的信息交互；第二种是应用层模块同基础软件之间 的信息交互。而RTE就是这些交互使用的接口的集散地，它汇总了所有需要和软件体外部交互的接口。 从某 种意义上来看，设计符合AUTOSA的系统其实就是设计RTESW-C之间的通信是调用RTE API函数而非直接实现的，都在RTE的管理和控制之下。每个API遵循统一的命名规则且只和软件组件自身的描述有关。 具体通信实现取决于系统设计和配置，都由工具供应商提供的RTEGenerator自动生成的。在设计开发阶段中，软件组件通信层面引入了一个新的概念，虚拟功能总线 VFB( Virtual Fu nctio nalBus)。它是对AUTOSA所有通信机制的

8、抽象，利用VFB 开发工程师将软件组件的通信细节抽象，只需要通过 AUTOSA所定义的接口进行描述，即能够实现软件组件 与其他组件以及硬件之间的通信，甚至ECU内部或者是 与其他ECU之间的数据传输。AUTOS ARSoftwareApplied ionSohwmeCoinponeiilAUTOSARkiterlaceSensorSoFlwareComponentAUTOSARInteiface.Finnwai*Standiird SoftwareAPIS2 VFBA RTEAUTOSAR Jn (effaceActuator Software ConipofieniAU T OSAR Ini

9、ilaceStandardized AUTOS AR Inredac eVFI从图中可以看到，有三种接口描述，我们先从定义的角度来看这三种接口有什么不同。2.1 ） Sta ndardized In terface（标准接口）：标准接口是在AUTOSAR准中被标准化的接口，但是并没有使用AUTOSA接口技术，标准接口通常被用在某个 ECU内部的软件模块之间的通讯，不能用于网络通讯。2.2）Standardized AUTOSAIRterface （标准 AUTOSAR 接口）：标准AUTOSA接口是在AUTOSA标准中使用AUTOSAR 接口技术标准化的接口，这样的接口的语法和语义都被规 定好

10、了，这样的接口通常使用在 AUTOSA服务中，这样的 接口是基础软件服务提供给应用程序的。2.3）AUTOSAIRterface （ AUTOSA接 口）： AUTOSA接 口定义了软件模块和BSV模块（仅仅是IO抽象和复杂驱动） 之间交互的方式，AUTOSA接口是以port的形式出现的， AUTOSA将 ECU内部的通讯和网络通讯使用的接口进行了 统一。从上边的定义中我们可以看出不同的接口使用的场景 不同，及不同的模块交互会使用到不同的接口。除了将接 口归类以外，这样定义究竟有什么实际的意义呢？从实际 使用的角度来看，第一和第二类接口都是语法语义标准化 的接口，即接口函数的数量、函数的名字、

11、函数参数名字及数量、函数的功能、函数的返回值都已经在标准里边定义好了。不同的公司的软件在实施这些接口的时候虽然内 容算法不同，但是它们长相和功能是一致的，接口定义在 AUTOSA规范文档里边是可以查得到的。第三类接口呢， AUTOSA仅仅规定了简单的命名规则，这类接口高度的和 应用相关，比如BCL控制大灯打开的接口可以是Rte_Call_RPort_BeamLight_SetDigOut 也可以是 Rte_Call_RPort_HeaderLight_Output ，公司可以自己定 义，又比如仪表想要从 CAN总线上获得车速，改接口可以 是 Rte_IRead_RE_Test_RPort_Sp

12、eed_uint8 也可以是 Rte_IRead_Test_RE_RPort_Spd_uint8，这些接口必须通过 RTE交互。AppHcatlonSoftwareConrtpon&ntActuatorSoftwareComponentSensorSoftwareComponentAUTOSA RinterfaceAUTOSARInterfaceAUTOSARAUTOSARSoftwareApplicationSoftwareComponentAUTOSARlntrfaeeRTEStandardizedInterfaceStandardized AUTOSAR EnterfaceStan da

13、rdlcttdInterfaceAUTOSAR interfaceServicesSommunlcatiorECU L AbstractionStandardized InterfaceStandardized InterfaceStandardized Interface0 , Ji IAUTOSAR InterfaceSystemStandardized Int舍 rfQ8ECU Hardware3) Basic software 层(BSVVrcrocontrolla AbstractionComplexDevicedriversSerUnb HandMtcrw l)ri虽然汽车中有各种

14、不同的ECU它们具有各种各样的功能， 但是实现这些功能所需要的基础服务是可以抽象出来的，比如10操作，AD操作，诊断，CANS讯，操作系统等，无非就是 不同的ECU功能，所操作的10、AD代表不同的含义，所接收 发送的CAN消息代表不同的含义，操作系统调度的任务周期优 先级不同。这些可以被抽象出来的基础服务被称为基础软件。 根据不同的功能对基础软件继续可以细分成四部分，分别为服务层(Service Layer ), ECU抽象层(ECU Abstract Layer ), 复杂驱动(Complex Driver ) 和 MCAL(Microcontroller Abstraction Laye

15、r )，四部分之间的互相依赖程度不尽相同。3.1 )服务层(Service Layer )，这一层基础软件提供了汽车ECU非应用相关的服务，包括 OS网络通讯，内存 管理(NVRAM诊断(UDS故障管理等)，ECU状态管理 模块等，它们对ECU勺应用层功能提供辅助支持，这一层 软件在不同领域的ECL中也非常相似，例如不同的 ECL中 的OS的任务周期和优先级不同，不同的ECL中的NVRAI的 分区不同，存储的内容不同。3.2 ) ECL抽象层(ECU Abstract Layer ),这一层软件 提供了 ECU应用相关的服务，它是对一个 ECU勺抽象，它 包括了所有的ECU勺输入输出，比如AD

16、 DIO, PWM等，这 一层软件直接实现了 ECU勺应用层功能，可以读取传感器 状态，可以控制执行器输出，不同领域的ECU会有很大的不同。3.3) MCAL(Microcontroller Abstraction Layer),这一层软件是对ECL所使用的主控芯片的抽象，它跟芯片 的实现紧密相关，是ECL软件的最底层部分，直接和主控 芯片及外设芯片进行交互，它的作用是将芯片提供的功能 抽象成接口，然后把这些接口提供给上边的服务层 /ECU抽 象层使用。3.4 )复杂驱动(Complex Drivers ),汽车 ECL中有一MitixxronlfoL恤f卩占：1 blag, csdn.丨些领域的ECU会处理相当复杂的硬件信号，执行相当复杂 的硬件动作，例如发动机控制，ABS等，这些功能相关的 软件很难抽象出来适用于所有的汽车 ECU它是跟ECU勺 应用以及ECU所使用的硬件紧密相关的，属于 AUTOSA构 架中在不同的ECU上无法移植的部分。Services LayerECU Abstraction LayerMicrocontroller Abstraction LaverFAppticatioiiADTOSAR Runtime Enviromnent (RTE)System Ser