AUTOSAR架构概述
1 总体概述
AUTOSAR是Automotive Open System Architecture(汽车开放系统架构)的首字母缩写,是一家致力于制定汽车电子软件标准的联盟。AUTOSAR是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立,各成员保持开发合作伙伴关系。自2003年起,各伙伴公司携手合作,致力于为汽车工业开发一个开放的、标准化的软件架构。AUTOSAR这个架构有利于车辆电子系统软件的交换与更新,并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。此外,AUTOSAR在确保产品及服务质量的同时,提高了成本效率。
整车软件系统可通过AUTOSAR架构对车载网络、系统内存及总线的诊断功能进行深度管理,它的出现有利于整车电子系统软件的更新与交换,并改善了系统的可靠性和稳定性。目前支持AUTOSAR标准的工具和软件供应商都已经推出了相应的产品,提供需求管理,系统描述,软件构件算法模型验证,软件构建算法建模,软件构件代码生成,RTE生成,ECU配置以及基础软件和操作系统等服务,帮助OEM实现无缝的系统软件架构开发流程。
AUTOSAR计划目标主要有三个:
- 建立独立于硬件的分层软件架构;
- 为实施应用提供方法论,包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU;
- 制定各种车辆应用接口规范,作为应用软件整合标准,以便软件构件在不同汽车平台复用。
2 分层概述
AUTOSAR整体框架为分层式设计,以中间件RTE(Runtime Environment)为界,隔离上层的应用层(Application Layer)与下层的基础软件(Basic Software)。图1是AUTOSAR体系架构分层标准。
2.1 Application Layer(应用层)
应用层中的功能由各软件组件SWC(software component)实现,组件中封装了部分或者全部汽车电子功能,包括对其具体功能的实现以及对应描述,如控制大灯,空调等部件的运作,但与汽车硬件系统没有连接。
1) 软件组件SWC(software component)
软件组件SWC(software component)是由Atomic component最小逻辑单元组成。Atomic component最小逻辑单元有Application、Sensor/actuator两种类型。其中Application是算法实现类型,能在各ECU上自由映射;Sensor/actuator是为Application提供I/O端口类型,用于与ECU绑定,但不可像Application那样能在各ECU上自由映射。数个SWC的逻辑集合组合成Composition。图4是SWC组成实例。
2)端口Ports
端口Ports是用来和其他SWC通信。通信内容分为Data elements与operations。其中,Data elements用Sender/Receiver通信方式;operations用Client/Server通信方式。图5是通信方式。
发送—接收端口(Sender/Receiver)用来传输数据,具有一个通信端口可以包含多种数据类型特点。但如果一个数据类型要通过总线传输,那么它必须与一个信号对应起来,数据类型既可以是简单的数据类型(integer, float),也可以是复杂类型(array, record)。通信方式:1:n或n:1。
客户端—服务器端口(Client/Serverr)用来提供Operation服务,具有一个客户端—服务器端口可以包含多种Operation和同步或是异步通信特点,一个客户端—服务器端口可以包含多种Operations操作,Operations操作也可被单个调用。通信方式:1:n或n:1。
3)可运行实体(Runnables entities)
可运行实体(Runnablesentities),简称Runnables。可运行实体包含实际实现的函数,可以是具体的逻辑算法或是实际操作。可运行实体由RTE周期性或是事件触发调用,如当接收到数据。
2.2 Runtime environment层 (RTE)
中间件部分给应用层提供了通信手段,这里的通信是一种广义的通讯,可以理解成接口,应用层与其他软件体的信息交互有两种,第一种是应用层中的不同模块之间的信息交互;第二种是应用层模块同基础软件之间的信息交互。而RTE就是这些交互使用的接口的集散地,它汇总了所有需要和软件体外部交互的接口。从某种意义上来看,设计符合AUTOSAR的系统其实就是设计RTE。
SW-C之间的通信是调用RTE API函数而非直接实现的,都在RTE的管理和控制之下。每个API遵循统一的命名规则且只和软件组件自身的描述有关。具体通信实现取决于系统设计和配置,都由工具供应商提供的RTE Generator自动生成的。
在设计开发阶段中,软件组件通信层面引入了一个新的概念,虚拟功能总线VFB(Virtual Functional Bus)。它是对AUTOSAR所有通信机制的抽象,利用VFB,开发工程师将软件组件的通信细节抽象,只需要通过AUTOSAR所定义的接口进行描述,即能够实现软件组件与其他组件以及硬件之间的通信,甚至ECU内部或者是与其他ECU之间的数据传输。
从图中可以看到,有三种接口描述,我们先从定义的角度来看这三种接口有什么不同。
- StandardizedInterface(标准接口):标准接口是在AUTOSAR标准中被标准化的接口,但是并没有使用AUTOSAR接口技术,标准接口通常被用在某个ECU内部的软件模块之间的通讯,不能用于网络通讯。
- StandardizedAUTOSAR Interface(标准AUTOSAR接口):标准AUTOSAR接口是在AUTOSAR标准中使用AUTOSAR接口技术标准化的接口,这样的接口的语法和语义都被规定好了,这样的接口通常使用在AUTOSAR服务中,这样的接口是基础软件服务提供给应用程序的。
- AUTOSARInterface(AUTOSAR接口):AUTOSAR接口定义了软件模块和BSW模块(仅仅是IO抽象和复杂驱动)之间交互的方式,AUTOSAR接口是以port的形式出现的,AUTOSAR将ECU内部的通讯和网络通讯使用的接口进行了统一。
从上边的定义中我们可以看出不同的接口使用的场景不同,及不同的模块交互会使用到不同的接口。除了将接口归类以外,这样定义究竟有什么实际的意义呢?从实际使用的角度来看,第一和第二类接口都是语法语义标准化的接口,即接口函数的数量、函数的名字、函数参数名字及数量、函数的功能、函数的返回值都已经在标准里边定义好了。不同的公司的软件在实施这些接口的时候虽然内容算法不同,但是它们长相和功能是一致的,接口定义在AUTOSAR规范文档里边是可以查得到的。第三类接口呢,AUTOSAR仅仅规定了简单的命名规则,这类接口高度的和应用相关,比如BCU控制大灯打开的接口可以是Rte_Call_RPort_BeamLight_SetDigOut,也可以是Rte_Call_RPort_HeaderLight_Output,公司可以自己定义,又比如仪表想要从CAN总线上获得车速,改接口可以是Rte_IRead_RE_Test_RPort_Speed_uint8,也可以是Rte_IRead_Test_RE_RPort_Spd_uint8,这些接口必须通过RTE交互。
2.3 Basic software层(BSW)
虽然汽车中有各种不同的ECU,它们具有各种各样的功能,但是实现这些功能所需要的基础服务是可以抽象出来的,比如IO操作,AD操作,诊断,CAN通讯,操作系统等,无非就是不同的ECU功能,所操作的IO、AD代表不同的含义,所接收发送的CAN消息代表不同的含义,操作系统调度的任务周期优先级不同。这些可以被抽象出来的基础服务被称为基础软件。根据不同的功能对基础软件继续可以细分成四部分,分别为服务层(Service Layer),ECU抽象层(ECUAbstract Layer),复杂驱动(ComplexDriver)和MCAL(Microcontroller Absstraction Layer),四部分之间的互相依赖程度不尽相同。
- 服务层(Service Layer),这一层基础软件提供了汽车ECU非应用相关的服务,包括OS,网络通讯,内存管理(NVRAM),诊断(UDS,故障管理等),ECU状态管理模块等,它们对ECU的应用层功能提供辅助支持,这一层软件在不同领域的ECU中也非常相似,例如不同的ECU中的OS的任务周期和优先级不同,不同的ECU中的NVRAM的分区不同,存储的内容不同。
- ECU抽象层(ECU Abstract Layer),这一层软件提供了ECU应用相关的服务,它是对一个ECU的抽象,它包括了所有的ECU的输入输出,比如AD,DIO,PWM等,这一层软件直接实现了ECU的应用层功能,可以读取传感器状态,可以控制执行器输出,不同领域的ECU会有很大的不同。
- MCAL(Microcontroller Absstraction Layer),这一层软件是对ECU所使用的主控芯片的抽象,它跟芯片的实现紧密相关,是ECU软件的最底层部分,直接和主控芯片及外设芯片进行交互,它的作用是将芯片提供的功能抽象成接口,然后把这些接口提供给上边的服务层/ECU抽象层使用。
- 复杂驱动(Complex Drivers),汽车ECU中有一些领域的ECU会处理相当复杂的硬件信号,执行相当复杂的硬件动作,例如发动机控制,ABS等,这些功能相关的软件很难抽象出来适用于所有的汽车ECU,它是跟ECU的应用以及ECU所使用的硬件紧密相关的,属于AUTOSAR构架中在不同的ECU上无法移植的部分。
图14是BSW层中各个子模块说明。
2.4 Microcontroller层
底层驱动层是由芯片生产厂家提供。
3 开发工具
上图是AutoSar开发流程阶段及各个阶段可以使用的开发工具。从网上调研情况来看,Vector和EB公司有整套的开发工具链。其中,Vector中的DaVinciDeveloper和DaVinci ConfiguratorPro开发工具使用较为普遍,建议采用Vector公司开发工具链。
从开发流程上看,各个开发阶段分别都有各自的开发工具:
- 系统设计阶段即需求开发与系统功能设计,采用PREEvision开发工具(价格咨询未回邮件);
- SWC功能软件开发阶段即ECU功能描述,采用DaVinciDeveloper开发工;(价格咨询未回邮件);
- BSW基础软件及RTE设计,采用DaVinciConfigurator Pro开工具(价格咨询未回邮件);
- 头文件和C代码采用MATLAB·Simulink工具自动生成。(盗版)
上图展示Vector公司开发AutoSar时所用的功能组件,其中红色字体是Vector工具链中自带组件。根据需要,暂定需要OS、SYS、DIAG、MEM、COM、CAN、FR、ETH、MCAL组件,价格在咨询当中。
黑色字体是底层硬件供应商提供。现已咨询到,瑞萨供应商底层驱动售价$20K。
4 开发流程
MATLAB·Simulink和Real-TimeWorkshop Embedded Coder生成AUTOSAR标准的代码是透明和直观的过程,它支持两种不同的工作流程:自上而下和自下而上。我们采用自上而下开发方式。
自上而下,从架构模型到Autosar SC。在自上而下的开发流程中,系统工程师使用架构生成工具(如davinci tool suite)来设计整车ECU网络。当然,工程师也可以使用其他的架构设计工具。架构软件会输出一个XML来描述对应的组件,该文件里包含了组件的一些必要信息比如:runnables,接口,数据类型等等。Matlab软件可以利用架构软件生成的XML文件自动创建Simulink架构模型,里面包含了接口模块以及相应的Autosar相关设置。之后系统工程师就可以在该框架模型的基础上,完善内部的控制模块。