AUTOSAR技术分析报告.docx

AUTOSAR技术分析报告（科银京成：王瑜、余朋、曾英哲、仰阳、扬宝泽1.AI1.ToSAR倚介汽车电子领域的软件主要属于嵌入式软件。因此，其开展阶段类似于其他嵌入式系统的软件开展。由于受限于嵌入式便件本身资源的匮乏.各种硬件产品的种类繁多和各自差异.以及整体嵌入式系统软件的逐步开展,起初的软件设计开发主要是封闭式的.这样行助于开发针对于特定坡件体,充分优化利用资源而特定设计的软件系统.这样的软件系统,是针对于特定硬件和特定应用而设计，其时于硬件资源的充分应用，以及软件本身的执行效率无疑是非行高.然而.随着饿件本身的逐步开展,其可用资源已经十分充分.另一方面.汽车电子额域应用需求也H越复杂.软件本身也变得越来越复杂.因此,无论汽车厂还是部件商都感到软件的标准化问遨.软件的可管理性，可延复使用性，可裁减性，以及质量保i三等等同遨被提上了议程。AHOSAR的提出正是携于以上一些软件开展的要求，由几大主要汽车厂商以及部件提供商联合提出的,其中包括BQMDaim1.erChrys1.er,FordMotor,PSAPeugeot,ToyotaMotor,Vo1kswagenG,Bosch,Contincta1.SiemensVDO等.AUTOSAR是针对特定的汽车电子这一领域，提出的一套开放式软件结构.其主体思想是使窗软件设计开发更易于管理，软件系统更易于移植、裁剪，以及更好的维护性和痂冰保证.AUTOSARif1.织所提出的目标以及它所关注的功能领域在下表中列出：工程目标功能领域A½!,hH力：附方TR1.M，IW启KkTwe 酢次/y-叼，用IT刊T攵r±水 保持汽车电子系统一定的冗余 可以移植到不同汽车的不同平台上 实现标准的根本系统功能作为汽车供给商的标准软件模块 通过网络共享软件功能 篥成多个开发商提供的软件模块 在产品生命周期内更好的进行软件维护 更充分的利用“货价产品” 在车辆整个生命底期中进行软件更新以车辆/为中上一、（动力系,）/安全底盘/厂=（主动/）_/、被动）/（AUTOSARt信/乘坐舒/适性/以乘客/为中心U.r-1C».I-X.<W9ViT*XIJI1.0*1.与升级解决方法好处不成熟的过程,因为adhoc模式/缺少对功能需要的追踪能力.缺少兼容的J1.具（供给商、OEM>标准化的标准交换格式对标准的改良（格式、内容提供无缝的工具性.浪费在实现和优化组件上的努力,而顾.客并不成认这些努力的价值，基础软件核软件质量的加强.将工作集中在有价值的功能t.微控制器模型缺乏可用性,很雄适”现有软件.（由新功能引起的）微控制器性能的扩展需求所导致的升级密要（如由新设计）。微拄制叁抽象微控制器能在不需要改变更高软件层的情况下时换，由定位ECU之间的功能时需要做大景的工作。功能重用时也需整做大量的工作。运行时环境（RTE）功能时装导致的通信技术的独立性。通过标准化机制,使得通信更加简单.使功能分区和功能费定位变得可能.非竞争性功能必须适应OEM的特定环境.因为需要从其它组件供给接口需要很多功夫，所以哪怕是很微小的革新，也需要做很多工作。基础软件和模型生成的代码间缺少清晰的接口。接口标准化减少/防止OEM和供给商之间的接11.通过使用通用接口目录,使独立于软件功能的硬件实现所消耗的工作量.筒化模型驱动的开发，允许使用标准化的AuToSAR代码生成工具.OEM间的模型的可.用用性。不同供给商之间模块的可交换性.2.AUToSAR软件结构2.1 AUTOSAR软件的组成与分层A1.TOSAR的状件组件可以用以下图来农示:Sft*Mr1.vmIAPpaCMonSoftwareIComporwntActuMOTS(twrComponentSnorSoftwareCocnporwntAUTOSARSoftwareAOTOSARInterfaceAI11OSARInterfaceAUTOSARInterface/UTOSARRuntimeEnvironment(RTE)AP1.1.RTEr1.vrfIAPIOAPI3Pr4eImHtKMimMWt(M*C%UtfI对于上图所示的些组件,可以根据功能及相互关系而共进行分层，如以下图所示:App1.ication1.ayer微拄制Q抽象层这一层是基础软件中的最低一层.它包含驱动,这些驱动是软件模块,用来对MC内部设备和映射广UC外部设备的内存进行访问.EaJ抽象层这一层与微控制器抽象层进行对接.它也包含了外部设备的驱动.它为访问外设提供了AP1.不管这些外谀的位置（C内部或外部），也不管它们与MC的连接（端口付脚接口类型）.效劳层这层是基础软件中的最高层,而且它与陶用软件之间有关联：当对I/O信号的访问包含EC1.抽象层中时,效劳层提供：操作系统功旎 车辆网络通信及管理效劳 存储管理(XVRAY管理) 诊断效劳(包括UDS通信及错误内存 ECU状态管理2.2 RTC运行时环境RTI-是ITOSARECU体系结构的核心组成局部.RTE是UTOSAR虚拟功能总线(VirtUfI1.FunctionBus,VFB的接口(针对某个特定E3)的实现，因此，它为应用程序软件组件之间的通信提供了根本的效劳，同时也便于访问包含OS的根本软件组件.应用程序软件组件包含独立于CPU和所处位置的系统软件,这就意味薪，为了满足系统设计者所归的一些限制.应用程序组件能蜂在系统配置期间被映射到任何有效的EC1.J上.RTE负费确保这些组件能够通信.RTE和OS,AUTOSARCOM和其他的他的软件板块(BSW)是VFB(Virtua1.Functiona1.Bus)概念的实现。RTE实现了A1.TOSRVFB的接口,从而实现了AUTOSR做件组件之间的通信.RTE是A(JToSAREeU体系的核心,它提供了在ITOSR软件组件间通信的基础效劳,扮演了一些方法,通过这些方法1.'K()SR软件组件能访问包括OS和通信效劳在内基础软件模块的.2.3 系统效劳系统效劳是一组可以由所有层次模块使用的模块和功能.例如实时操作系统、错误管理器和冷功能.为应用和根本软件模块提供根本效劳，它包含以下图所示功能：SH8JO6euesco323ooJoOeJAXuJUJEESdAOQ86e8s85-UaPUnU.Sc2.3.1 AUTOSAROSAUtosarOS为实时应用提供了所有根本效劳，即中断处理、调度、系统时间和时钟同步、本地消£1处理.以及错误检测机制。所有效劳都能!藏在良好定义的API之后。应用与OS和通信层的连接只通过AP1,AUTOSAROS的根本特征包括: 静态配置 能够推断实时系统性能 提供荔于优先级的调度策略 提供运行时保护功能存储'计时等 可宿主在低端控制器上，并且不需要其他资源它包含以下几个方面： 实时操作系姚在嵌入式汽车EeU中的实时操作系统构成软件动态行为的地础，它管理任务和M件的调度，不同任务间的数据流，并且提供监控和错误处理功能。但是，在汽车系统中，对操作系统的需求集中在特定领域，所使用的操作系统必须高饮运行并且所占存储空间小.在多媒体和远程信息处理应用中,操作系统提供的特征集以及可用计蚌资源有很大不同，在纯粹的任务管理之上,OS中还包含了更杂的数据处理（例如.流、快速文件系统等）、存谛管理甚至图形用户接口.汽车OS的典型领域涵蔽了调度和同步的核心特征。在AUTOSAR中，上面讨论的附加特征在OS的范围之外，其他肥1.2.2.1工作包（例如SPA1.）涵盖了这些特征。在AUToSAR的体系结构约束之下不可能把其他OS（例如,QNX.VXWorkS和WindoWSCE等）的特征集合集成到整体的OS/'通俗俚动结构中.因此.AUT0SARN只考虑核心特征. 核心操作系统0SEK/VDK操作系统广泛应用于汽车工业,并且已经证明了可以在现代车辆的所有EC1.类型中使用.OSEK（H引入的概念被广泛地理裤.汽车工业领域在设计基于OSEKOS的系统方面有多年的羟验.OSEKOS是一个那件触发的操作系统。这为基于AUTOSAR的系统的设计和维护提供了裔度的以活性。干件触发使得可以自由地选择在运行时胆动询度的事件，例如角反转、局部时间源、全局时间源、错误出现等等.由于这些原因，Autosrros的核心功能必须施于OSEKos,OSEKos特别提供了以下特性以支持AUTaSAr： 固定的基于优先级谢度 处埋中断的功能 只有中断有而于任务的优先拨 一些防止描误使用OS效劳的保护措诙 StartoS。和StartUMOok启动接口,Shu1.downOSO和ShutdownHook关闭接口AUTOSAROS基于OSEKOS意味着应用程序是向后兼容的.为OSEKOS编写的应用程序可以在1.TOSROS上运行.但是，使用AUH）SAROS引入的一些新特性湎要对己存在的OS腐OS特性的使用有所限制.例如：为定时器回调实现定时和内存保护效率就会很低，此外，AUTOSAROS扩展了一些已存在的特性，例如直接通过定时器舞动计数器.AUTOSARoS提供的API向后兼容于OSEKOS的APk新的需求作为功能扩展来集成.A1.JToSAROS对OSEKOS扩展的API如下表:效劳名语法Gc1.App1.ica1.ionIDApp1.ica1.ionTcGctAppiicationID(void)GetISRIDISRTypeGetISRID(void)Ca1.ITrustedFunctionStatusTypeCa1.ITrustedFunction(TrustedFunc1.ionIndexTypcFunctionIndex,TrustedFunctionParameterRefTypeFunctionPanms)CheckISRMemoryAccessAccessTypeCheckISRMemoryccess(ISRTypeISRID1McmorySartAddrossTypeAddress,MemorySizeTypeSize)CheckTaskMeiDoryAccessAccessTypeCheckTaskMeiioryAccess(TaskTypeTaskID1.MemoryStartAddressTypeAddress.MemorySizeTypeSize)CheckObjectAccessObjectAccessTypeCheckObjectAccess(App1.icationTypeApp1.IDvObjectTypeTypeObjectTyc>)CheckObjectw11ershipApp1.icationTypeCheckObjectOwnership(ObjectTypeTyiwObjectTy>e,*