汽车开放系统架构如何去完善

自2003年成立以来，AUTOSAR（汽车开放系统架构）联盟便一直致力于改变车载网络和电子控制单元（ECU）的设计方式。AUTOSAR为原始设备制造商（OEM）及其一级供货商提供了一种产业的标准方法，以设计和开发位于现代车辆中心的ECU。该标准将有助于减少设计过程中人为错误的产生，并为供货商和制造商提供一种明确且机器也可读取的数据格式，以交换设计信息。本文将探讨AUTOSAR采用战略的一些的预期商业效益，并解释了一些基本术语和设计方法。

AUTOSAR联盟的会员包括汽车OEM以及由零部件和服务供货商组成的支持性生态系统。该联盟的宗旨是针对汽车电气/电子（E/E）架构创造和建立全球性的开放标准。该标准在车辆架构级别提供支持，让OEM网络设计人员能设计和管理车辆功能之间的复杂关系，并且还支持供货商在制造之前详细定义独立ECU接口的细节。

为何改用AUTOSAR？

一款现代化豪华汽车可能包含多达100个ECU，包括从简单的传感器接口到复杂的娱乐信息及远程信息单元。将它们一次全部改用AUTOSAR方法和标准的风险很高，但原始设备制造商和一级供货商做出这样的改变会带带来许多的效益。预计到2020年，所有车辆都将拥有一些基于AUTOSAR的ECU，因此不可忽视该标准的存在。

改用AUTOSAR的一些原因和效益包括：

能在新的汽车平台和架构中更好地重新使用电子控制单元

能更好地使用预先验证和测试过的软件组件（代表车辆功能）

能减少下游设计错误——一套AUTOSAR方法可让功能在架构级别就可定义和验证

通过改善网络效率和功能运用而减少整体硬件成本

能减少整体网络架构分析和设计审查的成本

因使用一种标准化的数据交换格式（AUTOSARXML或arxml），从而改善了原始设备制造商和一级供货商之间的通信

不论在整个内部设计周期内是否需要对ECU进行重新设计或改进，改用AUTOSAR可加速设计调整。例如新工具的工作流程，或为了有助于保持与ISO26262标准的符合性（conformance），这些都会改变工作的流程，改用AUTOSAR方法可在变更流程时同时导入。不论如何实施调整，第一个基于AUTOSAR电子控制单元设计项目所花的时间，都要比现有/传统设计流程所花的时间来得更长，这是因为设计人员需要时间来熟悉新的方法。但随后即可带来节省成本和提升效益的成果。将传统的ECU资产转向AUTOSAR标准也是有可能的，通过采用“AUTOSAR封装（AUTOSAR Wrapper）”概念，重要的现有和经过证明的电子控制单元应用代码便可重复使用。使AUTOSAR的封装能够导入其它纯AUTOSARECU。这将有助于降低转用AUTOSAR方法的风险。

什么是AUTOSAR？

就本质而言，AUTOSAR提供标准的ECU接口定义，使设计人员能够具体指定每个汽车ECU中都需要的可重复使用之标准化软件层和组件。该标准不受硬件的影响，这意味着应用软件和硬件平台是相互独立的。应用软件开发人员可在应用软件中明确地说明各个汽车功能的细节，而不用担心相关软件服务和硬件接口。过去，软件和硬件紧密地整合在一起，因此很难实现可移植性和可重复使用（图1）。

汽车开放系统架构完善车载网络和ECU设计

图1：将应用软件与硬件分开。

将设计与硬件决策分开使车辆生产商/OEM能够依据所需的车辆功能进行自上而下的设计。存在于这个设计时间的虚拟功能总线（VFB）概念让所有软件电子控制单元都能够实现互连和获得测试。这让设计人员可专注于应用层，而不是根本的软件基础建设。通过采用虚拟功能总线，应用软件组件（SWC）与其它应用软件组件也相互独立。软件组件向虚拟功能总线发出输出信号，虚拟功能总线再将信息传送给目标组件的输入埠。AUTOSAR定义了输入和输出端口，以及交换信息的格式。这种抽离式的（abstracted）方法使得在定义相关硬件之前可实现所有车辆软件功能和接口交互验证。设计调整也因此变得容易得多，同时所有功能都被定义成虚拟功能总线上的软件组件（图2）。

汽车开放系统架构完善车载网络和ECU设计

图2：在虚拟功能总线上测试软件组件。

虽然虚拟功能总线不提供ECU之后在真实车辆中如何分布和互连的信息，但对架构设计时间来说，却是很有用的测试基准。可为车辆中的所有信号进行定时检查和接口定义。

一旦设计人员对各项功能感到满意，这些功能便会被映像或聚集到特定的硬件电子控制单元中。AUTOSAR可支持软件组件的映像和聚集流程。一个复杂的ECU可能包含很多软件组件，必要时可依照阶层式的方式将它们组织起来。

汽车开放系统架构完善车载网络和ECU设计

图3：将软件功能分配给真正的电子控制单元。

AUTOSAR运行环境

每个ECU都有为它量身定制的运行环境（RTE），通常可通过配套的设计工具来自动创建。真正的电子控制单元之间的实际通信将实现成CAN或Flex Ray总线的一部分，而运行环境通过产生工具进行配置，以便执行相连AUTOSAR组件所需的通信路径。运行环境可以切实执行虚拟功能总线和架构设计流程的通信和连接拓扑。由于AUTOSAR标准支持很多不同类型的软件组件，运行环境必须考虑各种软件组件存在的限制和变化。

为AUTOSAR组件提供服务——基础软件层和操作系统

基础软件（BSW）是一种标准化软件，不包含车辆应用逻辑和电子控制单元功能，但为运行环境提供依赖硬件和独立于硬件的服务。所需的服务包括内存服务（NVRAM管理器）、网络通信管理服务、诊断服务和状态管理。当应用层中定义的AUTOSAR软件组件要求服务时，运行环境的任务是在真正的电子控制单元上完成映像。

运行环境不提供任何可从远程ECU获取服务的机制，AUTOSAR规范也不允许这样做。所有服务要求都必须在“本地”电子控制单元上获得满足。在真正的电子控制单元上运行的基本操作系统（OS或OSEK）不知道AUTOSAR“可运行的（runnable）”概念。操作系统拥有一个可调度活动列表，这些活动通过调度算法进行管理。

关于硬件

AUTOSAR分层软件架构可以分离硬件的应用逻辑（application logic），以便重复利用和可以携带（portability）。运行环境和操作系统与微控制器抽象层（MCAL）相连，MCAL提供了对主微控制器上物理埠和设备的存取功能。微控制器抽象层是每一微控制器所特有的，使操作系统和基础软件能够存取数字输入/输出、模拟数字转换、FLASH和EEPROM支持等设备。图4说明了AUTOSAR电子控制单元中不同硬件和软件层之间的关系。

汽车开放系统架构完善车载网络和ECU设计

图4：组件在真正的电子控制单元中如何组装在一起。

支持新方法

汽车OEM可以通过一个自上而下的AUTOSAR设计方法，操作整个网络的完整模型。AUTOSAR设计工具可以让单一的ECU被提取，且在AUTOSARXML（arxml）中定义了连接性和接口信息。这个接口定义之后将传给一级供货商，进行进一步的细节设计和实施。由于格式已被标准化，相同的定义可以在公开投标时同时分送给几个一级供货商。标准化描述的好处在于在ECU描述中可以避免任何设计上的模棱两可，并且随着AUTOSAR标准的发展，存在误解的可能性也越来越小。由于这个标准与硬件无关，因此能够更充分地利用新产业趋势所带来的效益，如车内以太网、混合技术车辆网络（CAN/Flex ray）、异构多核平台以及车载网关布置。

想要试试看？

包括Mentor Graphics在内的一些业者已经可为AUTOSAR设计提供评估套件。这些套件包括架构设计到单个ECU配置。Mentor Graphics还拥有其VSX工具套件以及支持CAN、Flex Ray、LIN和以太网的ECU硬件开发板。这些工具以Eclipse为基础，利用开源工具链进行从源代码到运行实施的一系列设计。相对于大规模地将车内ECU一次就完全改到AUTOSAR方法来说，低风险调查和AUTOSAR试验更为可取。

AUTOSAR为车载网络和ECU设计提供预定义的标准方法，找到了进入每家汽车OEM和一级机构的方式。AUTOSAR标准提供了改善工艺和重新利用组件的机会，但是也带来了学习新ECU设计流程和工具的挑战。AUTOSAR的早期采用者一直都在把这些知识传给主流的设计和资源，而现今市面上也有多款可用于量产的工具。AUTOSAR的采用还可协助业者达到功能安全标准ISO26262的要求，因为它支持一个可重复、定义明确、且自上而下的设计流程。