我淡定地撸了一遍AUTOSAR的基本概念

之前的文章《老板说项目要上AUTOSAR，我慌得一批》讲到了，面对日益复杂的汽车E/E架构，在欧洲大地上诞生的AUTOSAR组织，提出了解决方案。

而且做了标准化：

• 软件接口
• 交换格式
• 方法论

首先，其目标要：

软件功能模块在不同车型之间被重用

标准化接口（也可见上图）：

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分类：

• Atomic component (最小的逻辑单元，无法再分)

• Application（普通应用类）

• Sensor/actuator（给Application提供I/O控制等）

• Composition（可以包含数个SWC的逻辑集合）

方法论描述了从系统底层配置到ECU可执行代码产生过程的设计步骤。所以，这个ARXML文件也是挺复杂的。我们先看个图感受下：

• RTE需要配置(e.g. 把runnables对应到OS的tasks中去)

• 通过RTE的事件触发runnables的运行

• 生成调用runnables的task代码

• 配置OS的一部分 (tasks, events, alarms)

• 实现SWC之间的通信

• 每个ECU的RTE因SWC的需求而异

• RTE抽象了OS，防止SWC直接访问OS和BSW

可以看出，其内容非常丰富，严格遵循着AUTOSAR的各项标准。