面向OEM的AUTOSAR汽车开放系统架构解决方案

三、 设计应用与实施

　　仍以车身/舒适领域的外部车灯控制系统的设计为例，在本例中只涉及转向灯的闪烁控制功能的实现。

　　在系统配置阶段，第一步是收集系统配置输入内容。首先收集实现该功能所需的软件构件，如图4右部边框所示，在本系统中共使用了5个软件构件，按照AUTOSAR提供的软件构件模板编写每个软件构件的描述文件；然后明确系统中所用到的ECU资源，形成ECU资源描述文件，如图4左上部边框所示，这里有3类ECU；最后是系统约束条件的描述文件，描述系统的网络拓扑关系。一般OEM需要提供软件构件描述和系统约束描述文件，以供零部件供应商在ECU系统开发时使用。

图4：系统配置输入内容。

　　以上描述文件的生成均有专门的工具（这类工具统称为AUTOSAR描述文件编辑器）支持，用户只需向工具中填充规定的内容即可。

　　软件构件描述文件的生成，需要获取每个软件构件的关于接口，行为，直接的硬件接口（I/O），运行性能需求（内存，功耗，定时等）等方面的信息；而软件构件描述文件本身将包含4部分内容：

　　* 一般特性：名称，生产商等

　　* 通信属性：端口，接口

　　* 内部结构：子构件，连接关系

　　* 需要的硬件资源：处理时间，调度，内存大小和类型等。

　　ECU资源描述文件生成之前，需要获取每个ECU的关于传感器和执行器，硬件接口，硬件属性（内存，处理器，功耗），连接和带宽等方面的信息；而ECU描述文件本身将包含7部分内容：

　　* 一般特性：名称，生产商等

　　* 温度（自身，环境，冷却/加热）

　　* 可用的信号处理方法

　　* 可用的编程能力

　　* 可用的硬件：微控制器，架构（如多处理器）；内存，接口（CAN，LIN，MOST，FlexRay），外设（传感器/执行器），连接（如引脚数目）。

　　* RTE之下针对微控制器的基础软件模块

　　* 从引脚到ECU抽象层的信号

　　系统约束描述文件生成之前，需要关于整个系统的信息，如总线系统，协议，通信矩阵和属性，功能集群，功能部署（向ECU的分布）；而系统约束描述文件本身将包含3部分内容：

　　* 网络拓扑：总线（CAN，LIN，FlexRay），连接的ECU，网关，电源供应

　　* 通信（针对每个通道）：通信矩阵，网关表

　　* 软件构件的映射

　　以上所描述的系统配置输入内容收集完整后，使用系统配置工具导出系统配置文件，这一步决定哪个软件构件运行在哪块ECU上，它生成ECU配置描述；此外还生成该系统内的通信矩阵。如图5所示。

图5：系统配置结果。

　　以上工作完成后，接下来进入ECU配置阶段。将每个ECU的配置信息从系统配置文件中提取出来，其内容包括ECU通信矩阵、拓扑结构、顶级功能组合（即需映射到该ECU上的所有软件构件的组合）。此外，还需要更具体的关于AUTOSAR的基础软件各主要部分的配置，如RTE的配置，OS 的配置，MCAL（微控制器抽象层）的配置和通信协议栈配置等。这些软件部件的配置目前均有相应的工具支持，直接生成可编译的头文件以供ECU系统软件的集成使用。在生成ECU可执行程序之前，需获得相关软件构件和基础软件的代码，然后与上述基础软件的配置头文件进行连编，最后生成ECU的可执行程序。如图6所示。

图6：ECU的配置与可执行程序的生成。

　　综上所述，整个系统设计和开发流程可用图7表示，这里要注意的是，该过程可能需要多次迭代修改，以达到最优。

图7：系统设计和开发流程。

　　四、总结

　　AUTOSAR正在成为现实，建立这样一个标准化平台并贯彻标准化，将会缩短新产品的研发时间和测试时间，从而帮助企业实现快速的市场反应。许多OEM都计划在接下来的车型中采用AUTOSAR。在市场上不少工具和软件供应商都已推出了符合AUTOSAR标准的工具或软件支撑，可为 AUTOSAR系统的设计和开发提供完整的无缝的解决方案。

　　AUTOSAR是汽车电子软件平台标准化的历程中的一个巨大飞跃，我们需要学习和理解它。但是也必须看到，在整个汽车行内打破传统的软件开发平台需要相当长的一个过程。我们可以根据用户的需求和目标，在初期搭建AUTOSAR与传统软件的混合平台，这是是一个能够实现向AUTOSAR平滑升级的可行的方法。在这个过程里，重点不是单纯地使用，理解AUTOSAR的理念和思想才最重要，因为它对汽车电子软件开发的工作流程和商业模式都将带来意义深远的变革。

　　参考文献

　　1、 AUTOSAR SPECIFICATIONS Release3.1：AUTOSAR官网发布的规范文件

　　2、 《03_AUTOSAR_Tutorial.pdf》：AUTOSAR官网文件

（发布者：chiying）