AUTOSAR技术分析报告.docxVIP

AUTOSAR技术分析报告 （科银京成：王瑜、余鹏、曾英哲、鲁阳、杨宝泽） AUTOSAR简介 汽车电子领域的软件主要属于嵌入式软件。因此，其发展阶段类似于其他嵌入式系统的软件发展。由于受限于嵌入式硬件本身资源的匮乏，各种硬件产品的种类繁多和各自差异，以及整体嵌入式系统软件的逐步发展，起初的软件设计开发主要是封闭式的。这样有助于开发针对于特定硬件体，充分优化利用资源而特定设计的软件系统。这样的软件系统，是针对于特定硬件和特定应用而设计，其对于硬件资源的充分应用，以及软件本身的执行效率无疑是非常高。 然而，随着硬件本身的逐步发展，其可用资源已经十分充分。另一方面，汽车电子领域应用需求也日趋复杂，软件本身也变得越来越复杂。因此，无论汽车厂还是部件商都感到软件的标准化问题。软件的可管理性，可重复使用性，可裁减性，以及质量保证等等问题被提上了议程。AUTOSAR 的提出正是基于以上一些软件发展的要求，由几大主要汽车厂商以及部件提供商联合提出的，其中包括BWM, DaimlerChrysler, Ford Motor, PSA Peugeot, Toyota Motor, Volkswagen AG, Bosch, Continetal, Siemens VDO等。 AUTOSAR是针对特定的汽车电子这一领域，提出的一套开放式软件结构。其主体思想是使得软件设计开发更易于管理，软件系统更易于移植、裁剪，以及更好的维护性和质量保证。AUTOSAR组织所提出的目标以及它所关注的功能领域在下表中列出： 项目目标 功能领域 ·解决汽车的可用性和安全性需求 ·保持汽车电子系统一定的冗余 ·可以移植到不同汽车的不同平台上 ·实现标准的基本系统功能作为汽车供应商的标准软件模块 ·通过网络共享软件功能 ·集成多个开发商提供的软件模块 ·在产品生命周期内更好的进行软件维护 ·更充分的利用“货价产品” ·在车辆整个生命周期中进行软件更新与升级 为了实现上述的项目目标，针对在汽车电子行业中面临的一些挑战，AUTOSAR所采用的解决方案及其好处可以概述如下： 挑战 解决方法 好处 不成熟的过程，因为ad-hoc模式/缺少对功能需要的追踪能力。 缺少兼容的工具（供应商、OEM） 标准化的规范交换格式 对规范的改进（格式、内容） 提供无缝的工具链。 浪费在实现和优化组件上的努力，而顾客并不承认这些努力的价值。 基础软件核 软件质量的加强。 将工作集中在有价值的功能上。 微控制器模型缺乏可用性，很难适应现有软件。 （由新功能引起的）微控制器性能的扩展需求所导致的升级需要（如重新设计）。 微控制器抽象 微控制器能在不需要改变更高软件层的情况下调换。 重定位ECU之间的功能时需要做大量的工作。 功能重用时也需要做大量的工作。 运行时环境(RTE) 功能封装导致的通信技术的独立性。 通过标准化机制，使得通信更加简单。 使功能分区和功能重定位变得可能。 非竞争性功能必须适应OEM的特定环境。 因为需要从其它组件供应接口需要很多功夫，所以哪怕是很微小的革新，也需要做很多工作。 基础软件和模型生成的代码间缺少清晰的接口。 接口标准化 减少/避免OEM和供应商之间的接口。 通过使用通用接口目录，使独立于软件功能的硬件实现所耗费的工作量。 简化模型驱动的开发，允许使用标准化的AUTOSAR代码生成工具。 OEM间的模型的可重用性。 不同供应商之间模块的可交换性。 AUTOSAR软件结构 AUTOSAR软件的组成与分层 AUTOSAR的软件组件可以用下图来表示： 对于上图所示的一些组件，可以根据功能及相互关系对其进行分层，如下图所示： · 微控制器抽象层 这一层是基础软件中的最低一层。它包含驱动，这些驱动是软件模块，用来对μC内部设备和映射了μC外部设备的内存进行访问。 · ECU抽象层 这一层与微控制器抽象层进行对接。它也包含了外部设备的驱动。它为访问外设提供了API，不管这些外设的位置(μC内部或外部)，也不管它们与μC的连接(端口针脚，接口类型)。 · 服务层 这层是基础软件中的最高层，而且它与应用软件之间有关联：当对I/O信号的访问包含ECU抽象层中时，服务层提供： 操作系统功能 车辆网络通信及管理服务 存储管理（NVRAM管理） 诊断服务（包括UDS通信及错误内存） ECU状态管理 RTE 运行时环境RTE是AUTOSAR ECU体系结构的核心组成部分。RTE是AUTOSAR虚拟功能总线（Virtual Function Bus，VFB）的接口（针对某个特定ECU）的实现，因此，它为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含OS的基本软件组件。 应用程序软件组件包含独立于CPU和所处位置的系统软件。这就意味着，为了满足系统设计者所做的一些限制，应