1 AUTOSAR的解决方案
之前的文章《老板说项目要上AUTOSAR,我慌得一批》讲到了,面对日益复杂的汽车E/E架构,在欧洲大地上诞生的AUTOSAR组织,提出了解决方案。
而且做了标准化:
-
软件接口
-
交换格式
-
方法论
首先,其目标要:
软件功能模块在不同车型之间被重用
还有,标准化AUTOSAR的代码配置/建模工具
标准化接口(也可见上图):
AUTOSAR Interface | “ AUTOSAR Interface”定义了软件组件和/或BSW模块之间交换的信息。该描述独立于特定的编程语言,ECU或网络技术。 |
Standardized AUTOSAR Interface | “Standardized AUTOSAR Interface”是其语法和语义在AUTOSAR中标准化的“ AUTOSAR Interface”。“Standardized AUTOSAR Interface”通常用于定义AUTOSAR服务,这是AUTOSAR基本软件向应用程序软件组件提供的标准化服务。 |
Standardized Interface | “Standardized Interface”是一种在AUTOSAR中标准化的API,无需使用“ AUTOSAR Interface”技术。这些“Standardized Interface”通常是为特定的编程语言(如“ C”)定义的。 |
交换格式标准化(arxml)
arxml到底长什么样?以下截取一段来熟悉下:
<AUTOSAR>
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>DataTypes</SHORT-NAME>
<ELEMENTS>
<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>uint8</SHORT-NAME>
<CATEGORY>VALUE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<BASE-TYPE-REF DEST="SW-BASE-TYPE">/DataTypes/BaseTypes/uint8</BASE-TYPE-REF>
<SW-CALIBRATION-ACCESS>NOT-ACCESSIBLE</SW-CALIBRATION-ACCESS>
<DATA-CONSTR-REF DEST="DATA-CONSTR">/DataTypes/DataConstrs/uint8_DataConstr</DATA-CONSTR-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
<TYPE-EMITTER>Platform_Type</TYPE-EMITTER>
</IMPLEMENTATION-DATA-TYPE>
// 部分内容省略
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AR-PACKAGE>
</AR-PACKAGES>
</AUTOSAR
再来看看其他几个基本概念:
SWC
SWC,即Software Component,是封装了部分或者全部汽车电子功能的模块,其包括了其具体的功能实现以及与对应的描述。
例如,我们可以把Dimmer、Switch、Door Control设计成SWC
SWC分类:
- Atomic component (最小的逻辑单元,无法再分)
- Application(普通应用类)
- Sensor/actuator(给Application提供I/O控制等)
- Composition(可以包含数个SWC的逻辑集合)
Port
Port是SWC之间通信用,算是SWC的组成部分。
Port分两大类:S/R(Sender/Receiver)和C/S(Client/Server)
Runnables
Runnables,即Runnable entities,也是SWC的组成部分,但它是运行在RTE里面,由RTE周期事件触发或者其他事件触发时调用。Runnable包含着实际运行的函数。
2 AUTOSAR的方法论
方法论,可以说是AUTOSAR的灵魂,就像一道菜的配料和方法,如果没有这个方法,那么食材仅仅是食材,而不是一道美味的菜肴。
既然,说方法论是AUTOSAR的灵魂,那么什么能承载这个灵魂,没有载体的灵魂就是孤魂野鬼啊。ARXML就能担此重任。其实,ARXML本质就是XML格式的文本,只是被AUTOSAR组织将其披上一件美丽的外衣。
方法论具体有哪些要求呢?见下图
方法论描述了从系统底层配置到ECU可执行代码产生过程的设计步骤。所以,这个ARXML文件也是挺复杂的。我们先看个图感受下:
这个ARXML关联着整个开发的方方面面
这个开发过程简单抽象起来就像:
抽取其中BSW的配置和生成过程来看看
3 AUTOSAR的实时环境
RTE,Run Time Environment实时运行环境,是整个AUTOSAR架构运行的桥梁,各个模块SWC之间的通信不是直接交互的,而是经过该层作为运行的基础,RTE里包含着OS大量的运行策略和服务。RTE也是VFB(Virtual Functional Bus)的实现。
-
RTE需要配置(e.g. 把runnables对应到OS的tasks中去)
-
通过RTE的事件触发runnables的运行
-
生成调用runnables的task代码
-
配置OS的一部分 (tasks, events, alarms)
-
实现SWC之间的通信
-
每个ECU的RTE因SWC的需求而异
-
RTE抽象了OS,防止SWC直接访问OS和BSW
4 AUTOSAR的基础软件
基础软件,即BSW。从AUTOSAR架构看,中间一层,都是BSW。
细化后
再细化
可以看出,其内容非常丰富,严格遵循着AUTOSAR的各项标准。
BSW抽象程度比较高,包含着许多基础软件。
从图上可以看出,其分了很多类,对应不同的功能。例如Memory、Communication、System等等。
特别一提的是,Complex Driver,是应对比较复杂的驱动的,这个在AUTOSAR的标准上是没有很明确的定义的,可由用户去实现。
Classic Autosar与Adaptive Autosar的比较
当前汽车控制器,如ECU与其他功能或信息娱乐性控制器有明显的不同,基于Autosar经典平台开发的汽车控制器,具有如下特点:
1、硬实时,可在us时间内完成事件的实时处理,硬实时任务必须满足最后期限的限制,以保证系统的可靠运行。
2、高功能安全等级,其可达到ASIL-D的安全等级。
3、对CPU、RAM或Flash等资源具有较低的占用率。
4、软件功能通常是固化不可动态变更的。
而信息娱乐性控制器,则正好与上相反,其一般会占用较大的硬件资源,且一般不具有实时性,因其一般运行在嵌入式PC上,如LINUX,而不是汽车级操作系统上,所以其即使出现故障也不会造成严重的安全事故。而Apdative Autosar则是连接这两者的桥梁,其具有如下特点:
1、软实时,具有毫秒级内的最后期限,且偶尔错过最后期限也不会造成灾难性后果。
2、具有一定的功能安全要求,可达到ASIL-B或更高。
3、与经典平台不同的是,它更适用于多核动态操作系统的高资源环境,如QNX。
Adaptive Autosar与Classic Autosar相比,虽实时性要求有所降低,但在保证一定功能安全等级的基础上,大大提高了对高性能处理能力的支持,以支持智能互联应用功能的开发,因此C++将成为Adaptive Autosar平台的主要开发语言。
Adaptive Autosar的出现并而是针对不同的应用场景升级,Classic Autosar平台支持高安全性和高实时性的应用场景,因此对于深度嵌入式的软件功能需部署运行在经典平台上;而Adaptive Autosar则支持大数据的并行处理,所以对于高性能运算的功能则需要运行在Adaptive平台上。