面向汽车应用的AUTOSAR设计技巧

汽车OEM正在开发基于AUTOSAR的电子系统以应对当代汽车中日益复杂的软件。AUTOSAR简化了开发流程并使得ECU软件具有复用性。从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、内存和其它基本服务的访问。利用基于模型的描述，可以针对指定的ECU定制RTE，这样可以适应不同的需求并节省资源。

方法

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

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

第一步包括三个主