AUTOSAR技术分析报告（DOC36页）

AUTOSAR技术分析报告（科银京成：王瑜、余鹏、曾英哲、鲁阳、杨宝泽）1．AUTOSAR简介汽车电子领域的软件主要属于嵌入式软件。因此，其发展阶段类似于其他嵌入式系统的软件发展。由于受限于嵌入式硬件本身资源的匮乏，各种硬件产品的种类繁多和各自差异，以及整体嵌入式系统软件的逐步发展，起初的软件设计开发主要是封闭式的。这样有助于开发针对于特定硬件体，充分优化利用资源而特定设计的软件系统。这样的软件系统，是针对于特定硬件和特定应用而设计，其对于硬件资源的充分应用，以及软件本身的执行效率无疑是非常高。然而，随着硬件本身的逐步发展，其可用资源已经十分充分。另一方面，汽车电子领域应用需求也日趋复杂，软件本身也变得越来越复杂。因此，无论汽车厂还是部件商都感到软件的标准化问题。软件的可管理性，可重复使用性，可裁减性，以及质量保证等等问题被提上了议程。AUTOSAR的提出正是基于以上一些软件发展的要求，由几大主要汽车厂商以及部件提供商联合提出的，其中包括BWM,DaimlerChrysler,FordMotor,PSAPeugeot,ToyotaMotor,VolkswagenAG,Bosch,Continetal,SiemensVDO等。AUTOSAR是针对特定的汽车电子这一领域，提出的一套开放式软件结构。其主体思想是使得软件设计开发更易于管理，软件系统更易于移植、裁剪，以及更好的维护性和质量保证。AUTOSAR组织所提出的目标以及它所关注的功能领域在下表中列出：项目目标功能领域·解决汽车的可用性和安全性需求·保持汽车电子系统一定的冗余·可以移植到不同汽车的不同平台上·实现标准的基本系统功能作为汽车供应商的标准软件模块·通过网络共享软件功能·集成多个开发商提供的软件模块·在产品生命周期内更好的进行软件维护·更充分的利用“货价产品”·在车辆整个生命周期中进行软件更新AUTOSAR底盘动力系安全（主动/被动）人机接口乘坐舒适性多媒体/信息通信以车辆为中心以乘客为中心与升级为了实现上述的项目目标，针对在汽车电子行业中面临的一些挑战，AUTOSAR所采用的解决方案及其好处可以概述如下：挑战解决方法好处不成熟的过程，因为ad-hoc模式/缺少对功能需要的追踪能力。缺少兼容的工具（供应商、OEM）标准化的规范交换格式对规范的改进（格式、内容）提供无缝的工具链。浪费在实现和优化组件上的努力，而顾客并不承认这些努力的价值。基础软件核软件质量的加强。将工作集中在有价值的功能上。微控制器模型缺乏可用性，很难适应现有软件。（由新功能引起的）微控制器性能的扩展需求所导致的升级需要（如重新设计）。微控制器抽象微控制器能在不需要改变更高软件层的情况下调换。重定位ECU之间的功能时需要做大量的工作。功能重用时也需要做大量的工作。运行时环境(RTE)功能封装导致的通信技术的独立性。通过标准化机制，使得通信更加简单。使功能分区和功能重定位变得可能。非竞争性功能必须适应OEM的特定环境。因为需要从其它组件供应接口需要很多功夫，所以哪怕是很微小的革新，也需要做很多工作。基础软件和模型生成的代码间缺少清晰的接口。接口标准化减少/避免OEM和供应商之间的接口。通过使用通用接口目录，使独立于软件功能的硬件实现所耗费的工作量。简化模型驱动的开发，允许使用标准化的AUTOSAR代码生成工具。OEM间的模型的可重用性。不同供应商之间模块的可交换性。2．AUTOSAR软件结构2.1AUTOSAR软件的组成与分层AUTOSAR的软件组件可以用下图来表示：对于上图所示的一些组件，可以根据功能及相互关系对其进行分层，如下图所示：·微控制器抽象层这一层是基础软件中的最低一层。它包含驱动，这些驱动是软件模块，用来对μC内部设备和映射了μC外部设备的内存进行访问。·ECU抽象层这一层与微控制器抽象层进行对接。它也包含了外部设备的驱动。它为访问外设提供了API，不管这些外设的位置(μC内部或外部)，也不管它们与μC的连接(端口针脚，接口类型)。·服务层这层是基础软件中的最高层，而且它与应用软件之间有关联：当对I/O信号的访问包含ECU抽象层中时，服务层提供：操作系统功能车辆网络通信及管理服务存储管理（NVRAM管理）诊断服务（包括UDS通信及错误内存）ECU状态管理2.2RTE运行时环境RTE是AUTOSARECU体系结构的核心组成部分。RTE是AUTOSAR虚拟功能总线（VirtualFunctionBus，VFB）的接口（针对某个特定ECU）的实现，因此，它为应用程序软件组件之间的通信提供了基本的服务，同时也便于访问包含OS的基本软件组件。应用程序软件组件包含独立于CPU和所处位置的系统软件。这就意味着，为了满足系统设计者所做的一些限制，应用程序组件能够在系统配置期间被映射到任何有效的ECU上。RTE负责确保这些组件能够通信。RTE和OS,AUTOSARCOM和其他的基础软件模块（BSW）是VFB（VirtualFunctionalBus）概念的实现。RTE实现了AUTOSARVFB的接口，从而实现了AUTOSAR软件组件之间的通信。RTE是AUTOSARECU体系的核心,它提供了在AUTOSAR软件组件间通信的基础服务，扮演了一些方法，通过这些方法AUROSAR软件组件能访问包括OS和通信服务在内基础软件模块的。2.3系统服务系统服务是一组可以由所有层次模块使用的模块和功能。例如实时操作系统、错误管理器和库功能。为应用和基本软件模块提供基本服务。它包含下图所示功能：2.3.1AUTOSAROSAUTOSAROS为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理，以及错误检测机制。所有服务都隐藏在良好定义的API之后。应用与OS和通信层的连接只通过API。AUTOSAROS的基本特征包括：·静态配置·能够推断实时系统性能·提供基于优先级的调度策略·提供运行时保护功能（存储、计时等）·可宿主在低端控制器上，并且不需要其他资源它包含以下几个方面：·实时操作系统在嵌入式汽车ECU中的实时操作系统构成软件动态行为的基础。它管理任务和事件的调度，不同任务间的数据流，并且提供监控和错误处理功能。但是，在汽车系统中，对操作系统的需求集中在特定领域。所使用的操作系统必须高效运行并且所占存储空间小。在多媒体和远程信息处理应用中，操作系统提供的特征集以及可用计算资源有很大不同。在纯粹的任务管理之上，OS中还包含了复杂的数据处理（例如，流、快速文件系统等）、存储管理甚至图形用户接口。汽车OS的典型领域涵盖了调度和同步的核心特征。在AUTOSAR中，上面讨论的附加特征在OS的范围之外，其他WP4.2.2.1工作包（例如SPAL）涵盖了这些特征。在AUTOSAR的体系结构约束之下不可能把其他OS（例如，QNX、VxWorks和WindowsCE等）的特征集合集成到整体的OS/通信/驱动结构中。因此，AUTOSAROS只考虑核心特征。·核心操作系统OSEK/VDK操作系统广泛应用于汽车工业，并且已经证明了可以在现代车辆的所有ECU类型中使用。OSEKOS引入的概念被广泛地理解，汽车工业领域在设计基于OSEKOS的系统方面有多年的经验。OSEKOS是一个事件触发的操作系统。这为基于AUTOSAR的系统的设计和维护提供了高度的灵活性。事件触发使得可以自由地选择在运行时驱动调度的事件，例如角反转、局部时间源、全局时间源、错误出现等等。由于这些原因，AUTOSAROS的核心功能必须基于OSEKOS。OSEKOS特别提供了以下特性以支持AUTOSAR：固定的基于优先级调度处理中断的功能只有中断有高于任务的优先级一些防止错误使用OS服务的保护措施StartOS()和StartupHook启动接口ShutdownOS()和ShutdownHook关闭接口AUTOSAROS基于OSEKOS意味着应用程序是向后兼容的。为OSEKOS编写的应用程序可以在AUTOSAROS上运行。但是，使用AUTOSAROS引入的一些新特性需要对已存在的OSEKOS特性的使用有所限制。例如：为定时器回调实现定时和内存保护效率就会很低。此外，AUTOSAROS扩展了一些已存在的特性，例如直接通过定时器驱动计数器。AUTOSAROS提供的API向后兼容于OSEKOS的API。新的需求作为功能扩展来集成。AUTOSAROS对OSEKOS扩展的API如下表：服务名语法GetApplicationIDApplicationTypeGetApplicationID(void)GetISRIDISRTypeGetISRID(void)CallTrustedFunctionStatusTypeCallTrustedFunction(TrustedFunctionIndexTypeFunctionIndex,TrustedFunctionParameterRefTypeFunctionParams)CheckISRMemoryAccessAccessTypeCheckISRMemoryAccess(ISRTypeISRID,MemoryStartAddressTypeAddress,MemorySizeTypeSize)CheckTaskMemoryAccessAccessTypeCheckTaskMemoryAccess(TaskTypeTaskID,MemoryStartAddressTypeAddress,MemorySizeTypeSize)CheckObjectAccessObjectAccessTypeCheckObjectAccess(ApplicationTypeApplID,ObjectTypeTypeObjectType,…)CheckObjectOwnershipApplicationTypeCheckObjectOwnership(ObjectTypeTypeObjectType,…)StartScheduleTableRelStatusTypeStartScheduleTableRel(ScheduleTableTypeScheduleTableID,TickTypeOffset)StartScheduleTableAbsStatusTypeStartScheduleTableAbs(ScheduleTableTypeScheduleTableID,TickTypeTickvalue)StopScheduleTableStatusTypeStopScheduleTable(ScheduleTableTypeScheduleTableID)NextScheduleTableStatusTypeNextScheduleTable(ScheduleTableTypeScheduleTableID_current,ScheduleTableTypeScheduleTableID_next)IncrementCounterStatusTypeIncrementCounter(CounterTypeCounterID)SyncScheduleTableStatusTypeSyncScheduleTable(ScheduleTableTypeSchedTableID,GlobalTimeTickTypeGlobalTime)SetScheduleTableAsyncStatusTypeSetScheduleTableAsync(ScheduleTableTypeScheduleID)GetScheduleTableStatusStatusTypeGetScheduleTableStatus(ScheduleTableTypeScheduleID,ScheduleTableStatusRefTypeScheduleStatus)TerminateApplicationStatusTypeTerminateApplication(RestartTypeRestartOption)DisableInterru