内容提要：本文提供了关于实现一个完整的AUTOSAR 4.0软件项目的信息。

摘要

汽车行业引入了AUTOSAR标准，用于开发汽车电子控制单元的软件。本文提供了关于实现一个完整的AUTOSAR 4.0软件项目的信息。

介绍

AUTOSAR一词代表汽车开放系统架构，是汽车行业的国际标准。AUTOSAR描述了电子控制单元软件的参考架构。这种标准化的目标是使数量不断增加、复杂性不断增加的软件保持可控。

除了标准本身之外，AUTOSAR一词还用于开发该标准的国际开发合作伙伴关系。汽车制造商、其供应商以及电子、半导体和软件行业的其他公司都是该合作伙伴关系的成员。

为了让学生有机会使用AUTOSAR相关的硬件和软件，上海驭捷智能科技有限公司开发了AUTOSAR教学环境。环境中包含的硬件是汽车电子控制单元(ECU)和硬件调试器，用于将开发的软件传输到ECU中的微控制器，当然还有用于调试开发的程序代码。客户可以直接连接自己的硬件，也可以在两个不同的接线盒之间进行选择。在软件方面，教育环境包括AUTOSAR实施的一部分以及用于ECU软件开发和调试的多个软件工具。

微控制器的软件开发对我们来说并不新鲜——我们为不同制造商的微控制器做过多次开发。然而，由于根据AUTOSAR标准开发软件是针对特定领域的，因此有几件事对我们来说是新的。因此，我们第一个学生项目的目标是开发一个完整的AUTOSAR 4.0软件项目，并记录建立项目所需的完整工作流程。如果遇到特定问题，创建的文档不能取代支持，但它是进一步项目的良好基础。

本文档的第一部分简要概述AUTOSAR标准的基本思想和概念。向读者介绍了根据标准建立的工作流程，即所谓的AUTOSAR方法。

本文档的第二部分概述锡根大学已实现的AUTOSAR 4.0软件项目。

第一部分：AUTOSAR标准基本思想和概念概述

本文档的这一部分并不要求对AUTOSAR标准进行完整概述。相反，对一些基本思想和概念进行了简要说明，以便更好地理解。

分层架构的实现

AUTOSAR实现了所谓的AUTOSAR分层软件架构。该架构描述了ECU软件的几个抽象层：应用层、运行时环境和基础软件。基础软件是ECU硬件之上的一层。图1(b)显示了该架构的结构。在这样的架构中，层之间的接口被明确定义。一层使用下一层提供的功能，并且它本身向上一层提供功能。如果必须在其中一层中纠正错误，则仅需要纠正该特定层的实现，因为层之间的接口保持不变。因此，层架构支持软件的模块化。

在引入AUTOSAR之前，ECU软件中不一定存在分层架构。图1(a)对此进行了说明。

分层架构可能会让人想起国际标准化组织 (ISO) 的OSI参考模型之一。OSI参考模型通常用于解释 Internet 协议 (TCP/IP) 的结构。两个参考模型背后的内涵是可比的：定义了不同层之间的接口，并且随着层的向上移动，硬件依赖性降低。

基础软件（BSW）可以看作是负责硬件抽象的操作系统。应用层包含具有应用相关代码的软件组件，运行时环境（RTE）实现不同软件组件之间以及软件组件与基础软件之间的通信。

图1. 经典ECU(a)和AUTOSAR-ECU(b)中软件结构的比较

获取ECU可执行代码的过程：AUTOSAR方法

上海驭捷智能科技有限公司提供车辆中的电子控制单元解决方案（添加微信：NewCarRen 具体咨询）。为了管理和并行开发这些车辆控制单元，引入了AUTOSAR方法。该方法描述了获取ECU可执行代码的过程或“工作产品流程”。工作产品流的必要信息通常存储在xml文件中。通常，软件工具强烈支持工作步骤，并且不需要手动修改xml文件。图2给出了AUTOSAR方法的简化概述。

该方法由三个视图组成：系统视图（红色）、ECU视图（蓝色）和组件视图（绿色）。带有系统配置的系统视图 (1) 包含有关车辆的所有软件组件、ECU、通信链路和系统限制的描述。配置系统时，软件组件将分配给特定的ECU (2)。从生成的系统配置描述 (3) 中，我们可以得出ECU之间必须交换哪些数据的结论。由于并非所有ECU和软件组件都来自同一供应商，因此可以从系统视图中提取(4)ECU视图和组件视图。不同的视图允许所有ECU和软件组件的完整开发过程并行化。借助组件视图开发的软件组件以及与其他组件并行开发的软件组件，可以作为二进制代码集成到 ECU(14) 中。

图2.AUTOSAR方法的简化概述

借助ECU相关模板(5)和系统配置的ECU特定摘录(6)，可以开发一个ECU。如果给出此信息，则可以在下一步中配置ECU(7)。该配置步骤包括，例如实现功能所需的基础软件模块的选择和配置，以及操作系统的任务调度器的配置。配置步骤(7)的结果是ECU配置描述(8)。工作步骤生成可执行文件(9)包括生成源代码（例如，用于运行时环境或基础软件）、源代码的编译（例如，生成的源代码或给定形式的源代码的软件组件）以及最终将所有目标文件链接到可执行程序（10）。

借助组件相关模板(11)，可以实现软件组件或软件组件的多个版本(12)。所实现的软件组件是目标文件(13)，其可以在可执行生成(9)的链接阶段集成到ECU(14)中。

软件组件与虚拟功能总线之间的通信

虚拟功能总线 (VFB) 描述了系统视图中软件组件(SW-C)之间的抽象通信关系。在系统配置期间，所有软件组件都将分配给相应的ECU。根据AUTOSAR方法，所有ECU的配置（图2中的编号6）都是从系统配置（图2中的编号3）中提取的（图2中的编号4）。图3说明了在软件工具的帮助下执行的这一开发步骤。

图3.软件组件在ECU中基于工具的分布

当生成ECU视图时，软件组件之间的抽象通信关系将被具体的通信连接所取代。对于此步骤，通信是否发生在同一ECU上的两个软件组件之间，或是否必须通过通信总线建立并不重要。这种灵活性是通过自动生成运行时环境来实现的，该环境实现了软件组件之间的通信连接。

如果某个ECU的CPU计算能力存在问题，则可以修改系统配置并重复提取ECU配置。软件组件分发中，这种灵活性的先决条件是通信总线上有足够的空闲通信资源。必须将两个软件组件分配给同一ECU的限制，可能会限制这种灵活性。

基础软件结构

在分层架构中，基础软件位于运行时环境下方、ECU硬件上方。除此之外，基础软件本身又分为三个水平抽象层和六个垂直部分。图4说明了基础软件在分层架构中的位置以及基础软件本身的结构。

基础软件的垂直细分分为以下六个部分（从左到右）：系统服务、设备堆栈、内存堆栈、通信堆栈、I/O堆栈和复杂设备驱动程序。三个水平抽象层是（从下到上）：微控制器抽象层（MCAL）、ECU抽象层和服务层。

系统服务部分为应用软件组件和基础软件的其他模块提供操作系统、诊断和ECU状态管理功能等基本功能。设备堆栈抽象了微控制器内部硬件，如看门狗和定时器。存储器堆栈提供对闪存和EEPROM等非易失性存储器的统一访问。

图4.基本软件的分层体系结构和子结构

通信堆栈为应用程序和基础软件提供通信服务，以便与其他电子控制单元交换数据。该堆栈中的抽象，是通过应用程序可以独立于它们使用的通信总线类型进行开发的方式完成的。I/O堆栈提供对ECU的模拟、数字和PWM I/O引脚的访问。

复杂设备驱动程序部分不属于基础软件的任何层，因此未详细指定。复杂设备驱动程序提供了将新模块集成到AUTOSAR系统中的可能性。开发复杂设备驱动程序的原因可能有三个：1. 缺少特殊功能的模块；2. AUTOSAR无法满足时序要求；3. 现有软件移植到AUTOSAR。

第二部分：已实现的AUTOSAR 4.0软件项目概述

系统硬件概述

图5中的框图概述了AUTOSAR 4.0软件项目开发过程中使用的所有硬件组件。ECU（1）是为其开发软件项目的，可以在图的左侧看到。ECU安装在接线盒（2）上。接线盒包含一些输入/输出元件，如开关、可调电阻器、LED和几种总线的连接器。本项目中使用了编号为10至12的三个LED和CAN总线的接头。安装在ECU印刷板顶部的硬件调试器（3）用于将生成的程序代码闪存到ECU，当然也可以用于调试开发的程序代码。硬件调试器通过USB链接连接到用于软件开发和调试的PC（4）。

我们系统中的主要数据源是带有附加温度传感器 (5) 的3D加速度传感器，该传感器定期在CAN总线上发送测量数据。CAN总线接口(6)用于监控CAN总线上的数据。CAN总线接口通过USB链路连接到PC。

图5.整个系统中相关组件的框图

大多数硬件，例如ECU（类型：VC 121-12）、接线盒（类型：VC121 12 EVS）和 CAN 总线接口（类型：VN5610）可以通过上海驭捷购买。硬件调试器是iSYSTEM AG公司的产品，由Vector Informatik销售（型号：VCA0301）。加速度传感器（类型：BC–3ACC#607）由2D Debus & Diebold Meßsysteme GmbH提供。

用于开发项目的软件概述

表1列出了用于开发ECU代码的所有软件。在此描述的项目中，仅存在一个ECU。因此，AUTOSAR方法的ECU视图（参见图2）内的工作步骤对我们来说非常重要。在我们的例子中，没有系统配置或系统配置描述。因此，无法从中提取ECU的配置。我们必须自己创建ECU配置。出于配置目的，使用了DaVinci Configurator Pro (1)。

为了实现下一章中描述的功能，ECU需要进行通信。它接收来自加速度传感器的消息，并在处理传感器的数据后发送消息。设置通信的最简单方法是，在数据库文件中描述总线上消息的结构，并将该文件添加到配置中。DaVinci Configurator Pro根据CAN数据库文件调整项目中的许多设置。CAN消息数据库文件本身可以使用CANdb++ (2)创建。

软件组件和应用程序代码骨架的创建已使用DaVinci Developer(3)完成。CANoe(4)是一个用于监控和分析总线数据的工具。为了将收集到的数据呈现在用户眼前，可以在CANoe中创建自定义虚拟面板。除此之外，该软件还能够模拟完整的ECU或完整的ECU网络（剩余总线模拟）。CANoe可以访问什么类型的总线取决于您拥有的总线接口类型。

winIDEA(5)是一款软件，可让您访问安装在ECU板顶部的硬件调试器。借助该软件，可以将开发的程序代码烧录到ECU中，并可用于调试。

GNU工具链(6)用于编译和链接ECU中微控制器的开发软件。

表1.该项目中使用的软件列表

已开发功能概述

ECU实现的功能可以分为两个时期。第一个周期是ECU启动后的前6秒。第二个时段是前6秒之后的时间。

在前6秒内，ECU会让LED 10、11和12依次发光。这可以看作是ECU启动后执行的自检功能的虚拟替代。

ECU通电6秒钟后，主算法启动。在主算法中，ECU通过CAN总线接收来自加速度传感器的数据，评估接收到的数据，重新传输CAN帧并控制LED 10、11和12。加速度传感器的数据和来自ECU的数据都可以在PC上的CANoe软件中进行评估和查看。

加速度传感器定期在CAN总线上传输其测量数据。该数据包括x、y和z方向的加速度以及传感器的温度。ECU根据阈值检查所有四个值，并传输CAN消息，其中包含测量值是否低于或高于相应阈值的信息。另外，如果x、y或z方向上的加速度超过相应的阈值，则ECU将使LED 10、11和12发光。如前所述，加速度传感器的数据以及ECU传输的状态值均通过CANoe进行可视化。

总结

汽车制造商要求新开发的汽车电子控制单元的软件按照AUTOSAR标准进行开发。该标准本身引入了分层软件架构和称为AUTOSAR方法论的工作产品流程，该流程描述了如何根据该标准开发ECU软件。所包含的虚拟功能总线概念提供了在ECU之间移植软件组件的可能性，从而提高了灵活性。基础软件为运行环境和应用软件提供许多服务和功能。因此，它可以看作是一个类似于操作系统的东西。与个人计算机的操作系统不同，基础软件在交付时并未进行预先配置。这是用户必须执行的任务。由于需要很大的灵活性，因此这项任务可能很困难，上海驭捷可以支持客户完成类似项目的实施。

培训咨询更多信息，详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！