图1  带有标准CAN驱动的应用软件

近年来，汽车电子行业对ECU中基础软件的平台化和标准化的重要性已普遍认同。随着AUTOSAR标准的出现和逐步完善，越来越多的软件开发人员在接受它的同时，也显得无从下手。如何使现有的软件系统符合AUTOSAR标准，成为摆在众多开发者面前的首要难题。

自2003年末国际AUTOSAR倡议公布以来，已经获得了重大进展。它的成果表现在大量规范的制定和收集，其中包括电控单元（ECU）软件中使用的标准软件组件规范和各种描述这些组件自身适应性的基于XML格式的配置文件。由于AUTOSAR规范的数目庞大，使得一些用户感觉在现有的ECU软件系统和完整的AUTOSAR解决方案之间存在着一道难以逾越的鸿沟，于是许多企业继续保守地坚持现状或已有的标准（例如OSEK标准的操作系统），不确定是否应用AUTOSAR的时机已经成熟，并静待它的未来。

伊莱比特（EB）根据多年来的成功经验，从用户的实际情况出发，建议从目前的OSEK标准起步，或者从初期的AUTOSAR 开始实施，都是能够实现向AUTOSAR平滑升级的切实可行的方法。同时，应用软件开发者也应该意识到，面向AUTOSAR运行时环境（RTE）接口的应用软件设计的重要性，及早地将AUTOSAR应用层接口引入到实际的项目中来，为实现应用软件的重用性做好准备，从而优化整个软件开发流程。

汽车ECU软件标准化的历史

毋庸置疑，当今设计和实现高可靠性汽车ECU软件的关键是拥有标准化的软件模块，同时，最理想的情况是：存在一个预先集成好的标准化平台，成为上层应用软件的坚实基础。这样，应用软件工程师就可以将精力集中在各自的核心竞争力上，而不需花费更多时间去集成标准化的软件。

CAN驱动是首个标准化的模块

标准化的软件组件首次出现在汽车工业中，源自CAN通信总线在汽车中的应用。最初的想法是通过CAN总线把车内的ECU连接起来并实现相互间通信，但是仅仅依靠硬件无法真正实现这个目标。为了确保CAN的所有输入和输出信息一致，统一的驱动软件必不可少。于是CAN的使用者就要求进行驱动软件的标准化（见图1）。

基于OSEK标准的平台

实际项目中，经常有对时间性要求严格的需求（如周期性例程调用），这时把CAN驱动集成到现有的软件里并非易事。此外，我们也逐渐意识到使用通信策略可以更有效地利用CAN总线的带宽。当只有少量ECU相互连接通信时，系统里的消息收发情况似乎没有问题。但是随着系统ECU数量的增多，仍然以这种方式通信，频繁的网络冲突将导致大部分网络可用带宽的损失。

图2  基于OSEK的软件平台

这就是20世纪90年代成立OSEK组织的部分原因。最终制定的OSEK规范主要由四部分组成：实时操作系统规范（OSEK-OS）、通信系统规范（OSEK-COM）、网管系统规范（OSEK-NM）和协调具体系统工作的其他标准（见图2）。

HIS I/O library 库

接下来，原戴姆勒－克莱斯勒公司继续推进了标准化的进程。它不仅在软件开发中使用了OSEK标准的模块，还将芯片的外围进行了标准化，最后定义了HIS I/O库（见图3），而且被大众公司等一些汽车制造商所采纳。这个I/O库的定义，第一次完成了硬件的完全抽象，使真正意义上的软件移植成为可能。

今天，基于OSEK标准的软件平台在各国仍然有着广泛的应用，特别是在欧洲和日本，用户可以根据具体需求进行适应性调整。这种解决方案的稳定性和可靠性已经经受了时间的考验。

图3  基于OSEK 和HIS的软件平台

AUTOSAR一瞥

符合OSEK标准的软件平台，如果是来自不同制造商或供应商的，差别会很大。实践证明，任何单独定制，即便是基于相似解决方案的，维护起来都是费时费力的，更何况应用软件并不能完全重用。这种情况下，如果一个供应商给两个OEM厂商提供基于两种不同软件平台的相同ECU，则需要设计、开发和维护这两种不同的软件版本，却没有额外收益。这样做虽然可行，然而更好的方案是利用相同的软件服务于不同的客户，降低成本和复杂度的同时还提高了软件的可靠性。

AUTOSAR由汽车制造商和供应商（核心成员）于2003年初联合发起，同年秋公开。此后，很多企业以不同的成员身份加入了这个组织。核心成员和高级成员共同合作，不仅为独立的软件模块定义标准，还为软件模块所需的配置信息，以及为把这些软件模块整合到统一的软件平台上所必需的框架制定标准。希望通过制定统一的标准，使之不需调整地适用于不同的需求。

AUTOSAR与OSEK的区别相当于Windows操作系统与MS-DOS的区别，AUTOSAR合并了OSEK，还对OSEK根本无法解决的问题提供了方案。几乎所有的OSEK规范都被写进了AUTOSAR，包括操作系统、通信系统、网管系统和一些OSEK的配置格式。同样，也涵盖了HIS I/O库，它是AUTOSAR微处理器抽象层（MCAL）的来源。除此之外，AUTOSAR还为CAN、LIN和FlexRay定义了通信层驱动和专用的MCU驱动、诊断程序和基本服务（如CRC）等。

AUTOSAR运行时环境（RTE）是它最独特的模块。作为虚拟功能总线（VFB）为应用软件提供接口。允许应用层请求任何数据的输入，却不必关心数据的实际来源。这样，应用软件在不需知晓信息来源的情况下，可以直接通过RTE 来完成。被请求的信息或许是ECU的一个物理引脚的输入，或许是一个经过计算的值，也或许是另一个ECU发送来的CAN消息。不管获取方式如何，RTE都负责提供这些数据。所有涉及信息来源的细节描述都需要被提前配置进RTE，为开发过程中处理信息源改变的情况提供了便利。这也就实现了车载网络内ECU之间功能的可移植性。

除了定义标准化的软件模块，AUTOSAR还定义了一个从系统描述、系统约束到标准核模块源代码API的完整工作流。工作流涵盖了ECU和网络开发过程中所涉及到的不同的参与者，提供的方法不仅对制造商和供应商之间已有的工作流程有效，而且还可以应对诸如综合来自多个厂商的硬软件、将多个供应商软件集成到一个ECU上的新情况。

图4  完整的AUTOSAR标准核

AUTOSAR的应用和系统平滑升级

AUTOSAR的应用对汽车ECU的开发来说到底意味着什么呢？首先让我们从AUTOSAR的角度展望一下软件开发的终极目标，顺着这条主线找到平滑升级的方法。

1. AUTOSAR的观点

AUTOSAR 继承了OSEK配置基础软件的思想，而且还把这种模式扩展到了更大规模，因为静态配置至今仍然是实现代码高度优化的最佳办法。

AUTOSAR定义了标准的软件开发工作流程：首先，软件组件描述和系统约束说明由AUTOSAR开发商提供；其次，预期的ECU需求将被定义在ECU描述中；再次，就是软件组件描述和ECU描述之间的匹配工作，这一步决定了哪个功能运行在哪块ECU上，它生成ECU配置描述；接下来，这个ECU配置描述要被用来组织和配置AUTOSAR模块；最后为每个ECU生成配置文件。

在所有的ECU配置中，RTE的配置特别重要。它包括了所有AUTOSAR里软件模块的API，它的配置结果将影响其他所有模块的配置。它还包含所有使用到的网络数据信息和本地数据信息。无论什么时候这个信息变化了，任何涉及到的ECU里的RTE配置信息也要随之改变，这种变更还会继续被传播到本地的其他模块上，如CAN驱动模块就会因为需要接收不同的CAN消息帧而改变配置。所以，采用这种配置软件的方法，应用软件开发者的首要工作就是要绝对明确各应用之间的相互依赖关系。

RTE提供的统一API给应用软件开发模式带来了新的观念。应用层要想与AUTOSAR标准核共享信息，只需通过向RTE发送和请求信息就可以完成。任务——来自OSEK操作系统的概念，将不再属于应用层代码，而被安排到应用层和RTE之下。显然，AUTOSAR的一整套思想将给整个ECU软件开发流程带来深远影响。

2． 基础软件向AUTOSAR平滑升级

如果您当前的工作还没有涉及到软件平台的概念，我们推荐您现在从初期的AUTOSAR开始入手，逐步实施。这种初期的AUTOSAR 平台包括一些AUTOSAR 模块、不兼容AUTOSAR 的模块或者是自己开发的可以延续使用的模块。根据具体需求来设计您的初始平台。当然首先过渡到基于OSEK标准的软件平台，再由OSEK升级到AUTOSAR也是一个不错的可选方案。

如果当前您正在使用OSEK操作系统或者已经建立了基础软件平台，一个可行的方法是逐步地将独立的软件模块替换成相应的AUTOSAR 模块。根据具体情况规划实施步骤，例如可以优先配置AUTOSAR NVR 管理器，它可以用来集中处理非易失性存储器（EEPROM、flash及M-RAM等），对大多数应用软件都有帮助。

由于AUTOSAR 操作系统的主要需求是向下兼容OSEK 操作系统 2.2.1，所以从OSEK 过渡到AUTOSAR 操作系统并不费力，而且OIL 配置文件的格式，当前也几乎没有更改地被AUTOSAR 操作系统采纳。

一般而言，我们推荐以基于OSEK 标准的解决方案为起点，搭建基础软件平台，继续使用某些可以继承的非AUTOSAR模块，然后逐步在这个新平台上替换掉不兼容AUTOSAR的模块，添加独立的AUTOSAR 模块，做好相应的软件集成工作，最终形成完全符合AUTOSAR标准的基础软件平台。

3. 应用软件向AUTOSAR过渡

当前，我们与AUTOSAR定义的无缝工作流的最终目标还存在一定的差距，原因是基础软件组件、用来进行系统设计和功能匹配的工具还不足。现阶段，应用软件开发者应该从设计入手，将应用软件划分成独立的逻辑功能，代表后来的AUTOSAR软件组件。设计过程中，应用软件开发者必须学会使自己的思路向AUTOSAR软件组件设计需求靠拢。同时，还需要前瞻性地思考一些问题：比如，可运行体如何被触发（周期性触发和因数据接收事件触发）、通信端口及其接口应该如何被定义等。还有一些问题，特别是通信部分的设计，可能是整个系统里所有其他ECU的设计所强制要求的。

应用软件开发者的工作重点，应该是考虑如何将应用软件的AUTOSAR 接口应用到 AUTOSAR RTE 上。对于那些完全基于功能架构、硬件接口清晰，却还没有直接连接到操作系统上的应用层软件，可以被轻松地转变为AUTOSAR 应用软件组件。对于不适合的部分，需要根据RTE 接口来重新设计，并在以后的开发周期里，采用AUTOSAR的设计理念。这样，我们就为实现应用软件的重用性做好了准备。

4. AUTOSAR使用者的反馈

正在评估和使用AUTOSAR的企业和科研机构已经传来了令人振奋的反馈消息。与以前相同规模的软件项目相比，现在出现的问题比预料的要少很多，这应该归功于AUTOSAR解决方案和原有的软件模块的配合融洽。其中出现的问题，绝大部分发生在AUTOSAR的新概念，如MAL和RTE。而对AUTOSAR操作系统的使用似乎很顺畅，显然，这是因为对OSEK更为熟悉，且他们之间存在着相似性；另外一个关键因素是配置工具，一个界面友好，配置引导和辅助功能强大的工具将极大的帮助用户熟悉和使用AUTOSAR。

结论

AUTOSAR在软件平台标准化的历程中是一个巨大的飞跃。我们需要学习和理解它，根据用户的需求和目标，从基于OSEK标准的软件平台起步，搭建AUTOSAR初期的混合平台，是一个能够实现向AUTOSAR平滑升级的可行的方法。就像当初OSEK标准被首次提出之时，重点不是单纯地使用，理解它背后的理念才最重要。AUTOSAR也一样，因为它可能对隐藏在汽车软件开发背后的工作流带来意义深远的变革。

今后，应用软件开发将需要考虑的是实体间的通信，而不再是任务乃至时隙等问题。操作系统对应用层来说是不可见的，必须通过RTE进入。各种驱动以及位于RTE之下的所有软件层也是一样。可能刚开始，这让我们感觉有些不寻常，但事实上，这恰好是完全符合我们所熟知的面向对象的软件理念。

虽然AUTOSAR的规模和复杂性似乎短时间内会令人不知所措，但是，如果AUTOSAR最初的设计构想变成了现实，它将把软件的可靠性提升到新的层面，并优化整个软件开发流程。

Smooth Upgrade of ECU Software Migrating to AUTOSAR

In recent years the significance of ECU basic software platform and standardization has been widely agreed on. With the appearance and development of AUTOSAR, more and more automotive developers are trying to accept it, but still not sure how to introduce it into their processes. The big challenge for many developers is now, how the software architecture from today will fit into the requirements of AUTOSAR systems and what can be done to be prepared? Based on users’ practical situation, we present EB’ s years of successful experiences and suggest that the best approach is to implement from the existing OSEK standards or light AUTOSAR and that the both paths are straightforward. From the applications view, the most important issue is the software design of the application regarding the interface of the AUTOSAR runtime environment. The early introduction of ATUOSAR application interfaces to actual application development projects will help to get ready for application re-usability and streamline the whole workflow.