OEM正在开发基于的电子系统以应对当代汽车中日益复杂的软件。AUTOSAR简化了开发流程并使得软件具有复用性。

        从2004年AUTOSAR面世开始，这项创新性的前沿技术就在许多研究性的项目中进行测试；现在，AUTOSAR开始通过产品化ECU进入真正的实现阶段。AUTOSAR软件代表了当前的技术水平，并通过不断的版本更新来保证技术上的不断进步。

       汽车工业正在面临新的时代。复杂的汽车功能越来越多，使得汽车电子的开发越来越复杂。顾客对于产品的功能和个性化要求，以及象诊断这种非功能性需求的增加，更加剧了ECU开发过程的复杂度。汽车，尤其是高级豪华车，大约有超过1000个软件功能，几条车内总线网络，以及超过70个 ECU。由于汽车电子领域硬件平台的多样性，ECU软件开发严重依赖硬件和系统配置。每次相关的约束条件的更改都将导致重新编写程序或对软件的修改。

       为了降低ECU软件开发的复杂度，AUTOSAR开发成员提供了一套经过实践验证的软件架构，并以此作为开发可重用应用程序的基础。 AUTOSAR这一开放的系统架构标准是由全世界的汽车OEM，零部件供应商以及软件、半导体和电子工业的企业共同制定。AUTOSAR可以使得用户避免因为采用私有的解决方案导致日益增长的开发成本。

       AUTOSAR将电子架构分成若干层和模块。在定义接口的同时，AUTOSAR也定义了软件组件和易于交换的硬件平台标准。 AUTOSAR开发成员不仅提供了基础软件模块的规范，还提供了用于开发分布式系统应用程序的方法。这种方法以基于模型的软件和分布式系统描述开始，以自动代码生成和可重复的测试结束。这种方法简化了工具链的使用。

       在AUTOSAR面世之后三年，AUTOSAR开发成员在2007年发布了2.1版本。此时，AUTOSAR的发展到达了一个稳定的阶段。几个不同的开发项目对AUTOSAR的实用性进行了测试。在商业领域里，“AUTOSAR评估系统”已经完成。现在，AUTOSAR已经做好进入到产品ECU的准备了。

       AUTOSAR体系结构

       为了实现AUTOSAR的目标，即实现应用程序和基础模块之间的分离，汽车电子被抽象成几个层，如图1所示。

       与实际微控制器之间的连接，也就是物理基础，抽象为微控制器抽象层（Microcontroller Abstraction Layer），用于映射微控制器的功能和外围接口。微控制器抽象层定义了内存接口、I/O驱动接口和通信连接接口，同时还可以模拟一些微控制器无法提供的功能。第二层是ECU抽象层（ECU Abstraction Layer）。这一层在ECU相关硬件的基础上，为ECU提供外围设备的驱动程序。第三层是服务层（Services Layer）。这一层提供了各种服务，例如网络服务、内存管理、网络通信和操作系统。服务层在很大程度上独立于硬件系统。第四层的RTE真正实现了应用程序和基础软件之间的分隔。RTE负责处理应用程序集成以及应用程序与基础软件模块之间的数据交换。RTE的存在是真正实现应用程序重用的基础。由于RTE 预定义了相关的接口，所以开发人员可以在对硬件一无所知的情况下进行应用软件的开发，并将这个软件应用在任何符合AUTOSAR标准的ECU中。

       虚拟功能总线（Virtual Functional Bus）形成了这些层的配置基础。通过这条虚拟总线，所有汽车电子通信组件都可以进行抽象，同时使用预先定义的端口；而对于虚拟功能总线来说，ECU内部通信和外部总线通信并没有什么区别。这种区别要等到系统布局以及ECU的具体功能最终确定才会体现出来。软件组件本身对于这种区别并不关注，因此我们可以在独立的情况下开发软件组件。软件组件被分成若干个可执行单元，即运行实体。当某一个规定的事件发生时，就会有对应的运行实体被触发。这样的事件有可能是一个新的传感器信号 ，也有可能是一个周期性定时。从虚拟功能总线的角度对电子系统的形式化描述最终定义了相关软件组件的接口。因此，应用软件的开发可以独立于具体的ECU。

       RTE实现了对于I/O、内存和其它基本服务的访问。利用基于模型的描述，可以针对指定的定制RTE，这样可以适应不同的需求并节省资源。

       方法

       在定义ECU软件体系架构的同时，标准也定义了开发AUTOSAR系统的方法。符合经过确认的开发过程是开发软件的一个重要前提。需求列表中的不足会在开发早期被发现，软件组件的重用使得开发流程变得简化，整个系统也就更加可靠。但是，这种方法也允许一定程度的自由：例如，用户可以自己决定是使用从上至下还是从下至上的开发流程。

       AUTOSAR的目的在于通过工具为软件开发流程提供通用的支持。成熟的工具用于需求的结构化实现和相应的管理，同时建立相应的配置。

       第一步包括三个主要方面的形式化描述：软件（软件组件），ECU（ECU资源）和系统约束。合适的编辑工具用于创建完整的系统描述，如图2所示。

       系统配置作为ECU配置的基础，而用户可以利用配置工具根据ECU配置生成基础软件组件。在开发流程的末期，有多种生成工具可以用来生成RTE和基础软件。开发过程中的所有设计和配置数据都用统一的文件格式保存。为此，AUTOSAR定义了一种基于XML的文件格式。一方面，统一的文件格式保证了开发流程的通用性；另一方面，它简化了开发工具之间的无缝集成。

       移植

       AUTOSAR的软件体系结构并非单一模块，它包含了大量接口定义完整的标准模块。这使得AUTOSAR的移植非常容易，即使是在项目之间进行移植；另外可以在一个项目之内同时使用标准的AUTOSAR模块和私有的软件模块。

       为了实现这样的移植工作，首先必须将已有的软件架构和AUTOSAR体系结构进行比较。通过分析重叠的功能和集成选项，进而决定哪些模块可以保留，哪些模块应该被标准的软件模块替换。

       因此，在应用程序和基础软件之间引入一个分隔层是非常明智的选择。一个可行的方法是在移植过程的早期就准备好应用程序和AUTOSAR软件组件，并将它们通过RTE集成在一起。在RTE之下，一个专用的修改层用于为已有的基础软件提供接口，如图3所示。

       如果已有的基础软件有一部分需要被AUTOSAR基础软件替换，那么重点就集中在使用统一的工具。Vector提供合适的工具，可以用于配置私有的软件模块。非AUTOSAR模块可以被AUTOSAR模块逐步取代，从而避免推倒整个体系结构所需承担的风险或重新编写模块所带来的巨大工作量。

       前景

       AUTOSAR 3.0的发布标志着AUTOSAR标准的进一步完善。参与标准制定的各家公司承诺为实现AUTOSAR的目标而进行持续的努力。当前引入的各种想法将在AUTOSAR未来的4.0版本中得到实现。

       工具供应商也提出了一些和相关的想法。Vector的AUTOSAR开发团队正在致力于将基于AUTOSAR的 开发变得更加便利和容易。一个典型例子是运行在PC上的AUTOSAR应用组件的测试工具，这个工具同时还可以作为符合AUTOSAR标准的ECU的仿真环境。这使得在PC上测试AUTOSAR软件组件的实现代码变得更加容易。广泛使用的标准化工具（例如Vector的CANoe）可以用于测试实现、可视化测试以及生成测试报告。Vector利用全套的AUTOSAR基础软件组件和通用的设计与开发工具链支持整个开发流程，如图4所示。

        Vector的AUTOSAR解决方案已经在若干个项目中得到了实际验证，同时得到验证的还有符合AUTOSAR 2.0和2.1的成熟产品（符合AUTOSAR 3.0的产品将于2008年第二季度面世）。

       总结

       AUTOSAR正在成为现实。许多OEM都计划在接下来的车型中采用AUTOSAR。Vector为AUTOSAR提供了完整的解决方案，包括AUTOSAR软件组件和开发工具。这不仅仅支持纯粹的AUTOSAR系统开发，而且支持逐步地将现有系统向AUTOSAR移植。