↑点击上方蓝色字体,关注“嵌入式软件实战派”获得更多精品干货。
之前的文章《老板说项目要上AUTOSAR,我慌得一批》讲到了,面对日益复杂的汽车E/E架构,在欧洲大地上诞生的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到底长什么样?以下截取一段来熟悉下:
<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的各项标准。
关注公众号号“嵌入式软件实战派”,获得更多关于AUTOSAR相关的内容。
往期精彩内容推荐>>>
老板说项目要上AUTOSAR,我慌得一批
我硬生生地把C代码塞进了Python和Ruby
SREC、Hex、Bin等烧录文件格式完全解读