AUTOSAR技术分析报告

1、AUTOSAR技术分析报告（科银京成：王瑜、余鹏、曾英哲、鲁阳、杨宝泽）AUTOSARR简介汽车电子领域的的软件主要属属于嵌入式软软件。因此，其其发展阶段类类似于其他嵌嵌入式系统的的软件发展。由由于受限于嵌嵌入式硬件本本身资源的匮匮乏，各种硬硬件产品的种种类繁多和各各自差异，以以及整体嵌入入式系统软件件的逐步发展展，起初的软软件设计开发发主要是封闭闭式的。这样样有助于开发发针对于特定定硬件体，充充分优化利用用资源而特定定设计的软件件系统。这样样的软件系统统，是针对于于特定硬件和和特定应用而而设计，其对对于硬件资源源的充分应用用，以及软件件本身的执行行效率无疑是是非常高。然而，随着硬件件本身的逐

2、步步发展，其可可用资源已经经十分充分。另另一方面，汽汽车电子领域域应用需求也也日趋复杂，软软件本身也变变得越来越复复杂。因此，无无论汽车厂还还是部件商都都感到软件的的标准化问题题。软件的可可管理性，可可重复使用性性，可裁减性性，以及质量量保证等等问问题被提上了了议程。AUUTOSARR 的提出正正是基于以上上一些软件发发展的要求，由由几大主要汽汽车厂商以及及部件提供商商联合提出的的，其中包括括BWM, DaimllerChrryslerr, Forrd Mottor, PPSA Peeugeott, Toyyota MMotor, Volkkswageen AG, Boscch, Connti

3、nettal, SSiemenns VDOO等。AUTOSARR是针对特定定的汽车电子子这一领域，提提出的一套开开放式软件结结构。其主体体思想是使得得软件设计开开发更易于管管理，软件系系统更易于移移植、裁剪，以以及更好的维维护性和质量量保证。AUUTOSARR组织所提出出的目标以及及它所关注的的功能领域在在下表中列出出：项目目标功能领域解决汽车的可可用性和安全全性需求保持汽车电子子系统一定的的冗余可以移植到不不同汽车的不不同平台上实现标准的基基本系统功能能作为汽车供供应商的标准准软件模块通过网络共享享软件功能集成多个开发发商提供的软软件模块在产品生命周周期内更好的的进行软件维维护更充分的利用用

4、“货价产品”在车辆整个生生命周期中进进行软件更新新与升级为了实现上述述的项目目标标，针对在汽车电电子行业中面面临的一些挑战，AUTTOSAR所所采用的解决决方案及其好好处可以概述述如下：挑战解决方法好处不成熟的过程，因因为ad-hhoc模式/缺少对功能能需要的追踪踪能力。缺少兼容的工具具（供应商、OOEM）标准化的规范交交换格式对规范的改进（格格式、内容）提供无缝的工具具链。浪费在实现和优优化组件上的的努力，而顾顾客并不承认认这些努力的的价值。基础软件核软件质量的加强强。将工作集中在有有价值的功能能上。微控制器模型缺缺乏可用性，很很难适应现有有软件。（由新功能引起起的）微控制制器性能的扩扩展需

5、求所导致的升级需要（如如重新设计）。微控制器抽象微控制器能在不不需要改变更更高软件层的的情况下调换换。重定位ECU之之间的功能时时需要做大量量的工作。功能重用时也需需要做大量的的工作。运行时环境(RRTE)功能封装导致的的通信技术的的独立性。通过标准化机制制，使得通信信更加简单。使功能分区和功功能重定位变变得可能。非竞争性功能必必须适应OEEM的特定环环境。因为需要从其它它组件供应接接口需要很多多功夫，所以以哪怕是很微微小的革新，也也需要做很多多工作。基础软件和模型型生成的代码码间缺少清晰晰的接口。接口标准化减少/避免OEEM和供应商商之间的接口口。通过使用通用接接口目录，使使独立于软件件功能

6、的硬件件实现所耗费费的工作量。简化模型驱动的的开发，允许许使用标准化化的AUTOOSAR代码码生成工具。OEM间的模型型的可重用性性。不同供应商之间间模块的可交交换性。AUTOSARR软件结构AUTOSARR软件的组成成与分层AUTOSARR的软件组件件可以用下图图来表示：对于上图所示示的一些组件件，可以根据据功能及相互互关系对其进进行分层，如如下图所示：微控制器器抽象层这一层是基础软软件中的最低低一层。它包包含驱动，这这些驱动是软软件模块，用用来对C内部设备备和映射了C外部设备备的内存进行行访问。ECU抽抽象层这一层与微控制制器抽象层进进行对接。它它也包含了外外部设备的驱驱动。它为访访问外设

7、提供供了API，不不管这些外设设的位置(C内部或外外部)，也不不管它们与C的连接(端口针脚，接接口类型)。服务层这层是基础软件件中的最高层层，而且它与与应用软件之之间有关联：当对I/OO信号的访问问包含ECUU抽象层中时时，服务层提提供：操作系统功能车辆网络通信及及管理服务存储管理（NVVRAM管理理）诊断服务（包括括UDS通信信及错误内存存）ECU状态管理理RTE运行时环境RTTE是AUTTOSAR ECU体系系结构的核心心组成部分。RRTE是AUUTOSARR虚拟功能总总线（Virrtual Functtion BBus，VFFB）的接口口（针对某个个特定ECUU）的实现，因因此，它为应应

8、用程序软件件组件之间的的通信提供了了基本的服务务，同时也便便于访问包含含OS的基本本软件组件。应用程序软件组组件包含独立立于CPU和和所处位置的的系统软件。这这就意味着，为为了满足系统统设计者所做做的一些限制制，应用程序序组件能够在在系统配置期期间被映射到到任何有效的的ECU上。RRTE负责确确保这些组件件能够通信。RTE和OS,AUTOSSAR COOM和其他的的基础软件模模块（BSWW）是VFBB（Virttual FFunctiional Bus）概概念的实现。RRTE实现了了AUTOSSAR VFFB的接口，从从而实现了AAUTOSAAR软件组件件之间的通信信。RTE是AUTTOSAR

9、 ECU体系系的核心,它它提供了在AAUTOSAAR软件组件件间通信的基基础服务，扮扮演了一些方方法，通过这这些方法AUUROSARR软件组件能能访问包括OOS和通信服服务在内基础础软件模块的的。系统服务系统服务是一组组可以由所有有层次模块使使用的模块和和功能。例如如实时操作系系统、错误管管理器和库功功能。为应用用和基本软件件模块提供基基本服务。它它包含下图所所示功能：AUTOSARR OSAUTOSARR OS为实实时应用提供供了所有基本本服务，即中中断处理、调调度、系统时时间和时钟同同步、本地消消息处理，以以及错误检测测机制。所有有服务都隐藏藏在良好定义义的API之之后。应用与与OS和通信

10、信层的连接只只通过APII。AUTOSARR OS的基基本特征包括括：静态配置能够推断实实时系统性能能提供基于优优先级的调度度策略提供运行时时保护功能（存存储、计时等等）可宿主在低低端控制器上上，并且不需需要其他资源源它包含以下几个个方面：实时操作系系统在嵌入式汽车EECU中的实实时操作系统统构成软件动动态行为的基基础。它管理理任务和事件件的调度，不不同任务间的的数据流，并并且提供监控控和错误处理理功能。但是，在汽车系系统中，对操操作系统的需需求集中在特特定领域。所所使用的操作作系统必须高高效运行并且且所占存储空空间小。在多媒体和远程程信息处理应应用中，操作作系统提供的的特征集以及及可用计算资

11、资源有很大不不同。在纯粹粹的任务管理理之上，OSS中还包含了了复杂的数据据处理（例如如，流、快速速文件系统等等）、存储管管理甚至图形形用户接口。汽车OS的典型型领域涵盖了了调度和同步步的核心特征征。在AUTTOSAR中中，上面讨论论的附加特征征在OS的范范围之外，其其他WP4.2.2.11工作包（例例如SPALL）涵盖了这这些特征。在在AUTOSSAR的体系系结构约束之之下不可能把把其他OS（例例如，QNXX、VxWoorks和WWindowws CE等等）的特征集集合集成到整整体的OS/通信/驱动动结构中。因因此，AUTTOSAR OS只考虑虑核心特征。核心操作系系统OSEK/VDDK操作系

12、统统广泛应用于于汽车工业，并并且已经证明明了可以在现现代车辆的所所有ECU类类型中使用。OOSEK OOS引入的概概念被广泛地地理解，汽车车工业领域在在设计基于OOSEK OOS的系统方方面有多年的的经验。OSEK OSS是一个事件件触发的操作作系统。这为为基于AUTTOSAR的的系统的设计计和维护提供供了高度的灵灵活性。事件件触发使得可可以自由地选选择在运行时时驱动调度的的事件，例如如角反转、局局部时间源、全全局时间源、错错误出现等等等。由于这些原因，AAUTOSAAR OS的的核心功能必必须基于OSSEK OSS。OSEKK OS特别别提供了以下下特性以支持持AUTOSSAR：固定的基于优

13、先先级调度处理中断的功能能只有中断有高于于任务的优先先级一些防止错误使使用OS服务务的保护措施施StartOSS()和StarttupHoook启动接口口ShutdowwnOS()和ShutddownHoook关闭接接口AUTOSARR OS基于于OSEK OS意味着着应用程序是是向后兼容的的。为OSEEK OS编编写的应用程程序可以在AAUTOSAAR OS上上运行。但是是，使用AUUTOSARR OS引入入的一些新特特性需要对已已存在的OSSEK OSS特性的使用用有所限制。例例如：为定时时器回调实现现定时和内存存保护效率就就会很低。此此外，AUTTOSAR OS扩展了了一些已存在在的特性

14、，例例如直接通过过定时器驱动动计数器。AUTOSARR OS提供供的API向向后兼容于OOSEK OOS的APII。新的需求求作为功能扩扩展来集成。AUTOSARR OS对OOSEK OOS扩展的AAPI如下表表：服务名语法GetAppllicatiionIDApplicaationTType GGetAppplicattionIDD (voiid)GetISRIIDISRTypee GetIISRID (voidd)CallTruustedFFunctiionStatusTType CCallTrrusteddFuncttion(TrusteddFuncttionInndexTyype Fu

15、unctioonIndeex,TrusteddFuncttionPaarametterReffType FuncttionPaarams)CheckISSRMemooryAcccessAccessTType CCheckIISRMemmoryAcccess(ISRTypee ISRIID,MemorySStartAAddresssTypee Addrress,MemorySSizeTyype Siize)CheckTaaskMemmoryAcccessAccessTType CCheckTTaskMeemoryAAccesss(TaskTyppe TasskID,MemorySStartAAd

16、dresssTypee Addrress,MemorySSizeTyype Siize)CheckObbjectAAccesssObjectAAccesssType CheckkObjecctAcceess(ApplicaationTType AApplIDD,ObjectTTypeTyype ObbjectTType,)CheckObbjectOOwnersshipApplicaationTType CCheckOObjecttOwnerrship(ObjectTTypeTyype ObbjectTType,)StartScchedulleTablleRelStatusTType SStar

17、tSScheduuleTabbleRell(SchedulleTablleTypee ScheeduleTTableIID,TickTyppe Offfset)StartScchedulleTablleAbsStatusTType SStartSScheduuleTabbleAbss(SchedulleTablleTypee ScheeduleTTableIID,TickTyppe Ticckvaluue)StopSchheduleeTableeStatusTType SStopScchedulleTablle(SchedulleTablleTypee ScheeduleTTableIID)N

18、extSchheduleeTableeStatusTType NNextScchedulleTablle(SchedulleTablleTypee ScheeduleTTableIID_currrent,SchedulleTablleTypee ScheeduleTTableIID_nexxt)IncremeentCouunterStatusTType IIncremmentCoounterr(CounterrType CountterID)SyncSchheduleeTableeStatusTType SSyncScchedulleTablle(SchedulleTablleTypee Sc

19、heedTablleID,GlobalTTimeTiickTyppe GloobalTiime)SetScheeduleTTableAAsyncStatusTType SSetSchheduleeTableeAsyncc(SchedulleTablleTypee ScheeduleIID)GetScheeduleTTableSStatussStatusTType GGetSchheduleeTableeStatuus(SchedulleTablleTypee ScheeduleIID,SchedulleTablleStattusReffType SchedduleSttatus)Termina

20、ateAppplicattionStatusTType TTerminnateAppplicaation(RestaartTyppe RestaartOpttion)DisableeInterrruptSSourceeStatusTType DDisablleInteerrupttSourcce (ISSRTypee DisaableISSR)EnableIInterrruptSoourceStatusTType EEnableeInterrruptSSourcee (ISRRType EnablleISR)ProtecttionHoookProtecttionReeturnTType PPr

21、otecctionHHook(StatusTType FFataleerror)静态定义的的调度在许多应用中需需要静态定义义一组互相关关联的任务的的活动。这用用于在基于数数据流的设计计中保证数据据一致性，与与时间触发的的网络同步，保保证正确的运运行时定相，等等等。时间触发的操作作系统通常作作为这个问题题的解决方法法。然而，时时间只是简单单的事件，所所以任何事件件触发的OSS，包括OSSEK OSS，会在汽车车电子控制单单元实现一个个用于静态调调度实时软件件的调度器。监控功能监控功能在适当当的执行阶段段检测错误，不不是在错误发发生的时刻。因因此，监控功功能是在运行行时捕捉失效效，而不是预预防故障

22、。保护功能AUTOSARR概念需要多多来源的OSS应用共存在在同一处理器器中。为了防防止这些OSS应用之间意意想不到的交交互，需要提提供保护机制制。计时器服务务计时器服务为应应用和基础软软件提供软件件计时器。计时机制的核心心已经由OSSEK OSS的计数器和和闹钟提供。如如果要提供通通用的软件计计时，一些补补充特性需要要添加到AUUTOSARR OS。时间触发操操作系统时间触发操作系系统在汽车电电子控制单元元实现了一个个用于静态调调度实时软件件的调度器。另外，操作系统统为实时应用用提供了所有有基本服务，即即中断处理、调调度、系统时时间和时钟同同步、本地消消息处理，以以及错误检测测机制。所有服务

23、都隐藏藏在良好定义义的API之之后。应用与与OS和通信信层的连接只只通过APII。对于特殊的应用用，操作系统统能够配置为为只包含该应应用需要的服服务。因此操操作系统的资资源需求尽量量少。BSW调度器BSW调度器是是系统服务的的一部分，因因此它向所有有层次的所有有模块提供服服务。但是，与与其它BSWW模块不同，BBSW调度器器提供了集成成的概念和服服务。BSWW调度器提供供方法用以：把BSW模块的的实现嵌入AAUTOSAAR OS上上下文触发BSW模块块的主要处理理功能应用BSW模块块的数据一致致性机制集成者的任务是是应用所给的方方法（AUTTOSAR OS提供的的），在特定定项目环境中中以良好

24、定义义和有效的方方式把BSWW模块装配起起来。这也意味着BSSW调度器只只是使用AUTOOSAR OOS。它与AAUTOSAAR OS调调度器并不冲冲突。BSW调度器的的实现基于：BSW模块的BBSW模块描描述BSW调度器的的配置模式管理模式管理簇包括括三个基本软软件模块：ECU状态态管理器，控控制AUTOOSAR BBSW模块的的启动阶段，包包括OS的启启动；通信管理器器，负责网络络资源管理；看门狗管理理器，基于应应用软件的生生存状态触发发看门狗。ECU状态管理理器ECU状态管理理器是一个基基本软件模块块，管理ECCU的状态（OOFF、RUUN、SLEEEP），以以及这些状态态之间的转换换（

25、过渡状态态：STARRTUP、WWAKEUPP、SHUTTDOWN）。详详细地，ECCU状态管理理器：负责初始化化和de-iinitiaalizattion所有有基本软件模模块，包括OOS和RTEE；在需要时与与所谓的资源源管理器（例例如，通信管管理器）协作作，关闭ECCU；管理所有唤唤醒事件，并并在被要求时时配置ECUU为SLEEEP状态。为了完成所有这这些任务，EECU状态管管理器提供了了一些重要的的协议：RUN请求求协议，调整整ECU是保保持活动状态态还是准备关关闭，唤醒确认协协议，从“不稳定的”唤醒事件中中区分出“真正的”唤醒事件，时间触发的的增多非工作作状态协议（TTime TTri

26、ggeered IIncreaased IInoperrationn - TTTII），允允许ECU更更多地进入节节能的休眠状状态。ECU状态管理理器必须支持持独立的预处处理动作和过过渡，以启动动ECU或将将其转换到低低功耗状态（例例如，休眠状状态/备用状状态）。通过过良好使用EECU状态管管理器的特性性和能力，此此模块能够用用于执行电源源消耗的预定定义策略，因因此提供了对对ECU的有有效能源管理理。ECU状态管理理器的特性和和优势包括：初始化和关关闭基本软件件模块。ECU主要要状态的标准准化定义。时间触发的的更多非工作作状态。看门狗管理器看门狗管理器是是AUTOSSAR（服务务层次）的标标准

27、化基本软软件体系结构构的基本软件件模块。它监监控与计时约约束有关的应应用执行的可可靠性。分层体系结构方方法使得应用用计时约束和和看门狗硬件件计时约束分分离。基于此此，看门狗管管理器在触发发看门狗硬件件的同时提供供了对一些独独立应用的生生存监控。看门狗管理器提提供以下特性性：监督多个处处于ECU的的单独应用，这这些应用有独独立的计时约约束并且需要要特别监督运运行时的行为为和生存状态态。每个独立的的受监控实体体都有故障响响应机制。可以关闭对对单独应用的的监督，而不不会违反看门门狗触发（例例如，对于禁禁止的应用）。通过看门狗狗驱动触发内内部或外部、标标准或窗口，看看门狗。（iinternnal or

28、r exteernal, stanndard or wiindow, watcchdog）对对内部或外部部看门狗的访访问由看门狗狗接口处理。根据ECUU状态和硬件件性能选择看看门狗模式（OOff Moode, SSlow MMode, Fast Mode）。通信管理器通信管理器收集集并协调来自自通信请求者者（用户）的的访问请求。通信管理器的目目的是：简化通信协协议栈的使用用。包括通信信栈的初始化化，以及简单单的网络管理理。调整ECUU上多个独立立软件组件的的通信栈（允允许发送和接接收消息）的的可用性。暂时禁止发发送消息以阻阻止ECU（主主动地）唤醒醒物理通道。通过为每个个物理通道实实现一个状态

29、态机来控制EECU的多个个物理通道。可以强制EECU保持物物理通道处于于“silennt 通信”模式。分配所请求求的通信模式式需要的所有有资源，简化化资源管理。通信管理器定义义了“通信模式”，表示一个个特定的物理理通道对于应应用是否可用用，以及如何何使用（发送送/接收，只只接收，即不不发送也不接接收）。诊断服务诊断事件管理器器诊断事件管理器器DEM（DDiagnoostic Eventt Manaager）是是一个子组件件，如同AUUTOSARR内诊断模块块的诊断通信信管理器（DDCM）和功功能禁止管理理器（FIMM）。它负责责处理和存储储诊断事件（错错误）和相关关FreezzeFramme数

30、据。DDEM进一步步提供故障信信息给DCMM（例如，从从事件存储器器读取所有存存储的DTCC（Diaggnostiic Troouble Code）。DDEM给应用用层、DCMM和FIM提提供接口。定定义了可选的的过滤服务。功能禁止管理器器功能禁止管理器器FIM（FFunctiion Innhibittion MManageer）负责提提供软件组件件和软件组件件功能的控制制机制。功能能由一个、多多个或部分有有相同权限/禁止条件的的可执行实体体构成。通过过FIM方法法，对这些功功能的禁止可可以配置甚至至修改。所以以，极大地提提高了功能在在新系统环境境下的适应性性。FIM意义上的的功能与可执执行实

31、体是不不同并且独立立的类型。可可执行实体主主要由调度需需求来区分。与与此相对的是是，功能由禁禁止条件来分分类。FIMM服务关注SSW-C的功功能，但是并并不局限于此此。BSW的的功能也能够够使用FIMM服务。功能被指定了一一个标识符（FFID funcction identtifierr），以及该该特定标识符符的禁止条件件。功能在执执行之前获得得它们各自的的权限状态。如如果禁止条件件应用于特定定标识符，对对应的功能将将不再执行。FIM与DEMM密切相关，因因为诊断事件件和它们的状状态信息作为为禁止条件被被提供给FIIM。如果检检测到了失效效，并且事件件报告给了DDEM，那么么FIM禁止止FID

32、和对对应的功能。为了处理功能和和关联事件的的关系，功能能的标识符和和禁止条件必必须引入到SSW-C模板板中（与BSSW等价），并并且在配置期期间构造数据据结构以处理理标识符对于于特定事件的的敏感性。这这些关系在每每个FIM中中是唯一的。RTE和FIMM之间没有功功能上的联系系。在AUTTOSAR中中，RTE按按照接口和调调度需求处理理SW-C。与与此相对的是是，FIM处处理禁止条件件并通过标识识符（FIDD）为控制功功能提供支持持机制。因此此，FIM概概念和RTEE概念不互相相干扰。开发错误跟踪器器开发错误跟踪器器DET（DDeveloopmentt Erroor Traacer）主主要用于在

33、开开发期间跟踪踪和记录错误误。API参参数给出了追追踪源和错误误类型：错误所在的模块块错误所在的功能能错误类型由软件开发者和和软件集成者者在特定应用用和测试环境境下为APII功能选择最最优的策略。可可能包括以下下功能：在错误报告APPI内设置调调试器断点计算报告的错误误在RAM缓存中中记录调用和和传递的参数数通过通信接口发发送报告的错错误到外部日日志DET仅仅是是对SW开发发和集成的辅辅助，并不一一定要包含在在产品代码中中。API已已经定义，但但是功能由开开发者根据特特定需求来选选择/实现。诊断通信管理器器诊断通信管理器器DCM（DDiagnoostic Commuunicattion MMa

34、nageer）确保诊诊断数据流，并并且管理诊断断状态，特别别是诊断对话话期和安全状状态。另外，DDCM检查诊诊断服务请求求是否被支持持，以及根据据诊断状态判判断服务是否否可以在当前前对话期中执执行。DCM为所有诊诊断服务提供供连接到AUUTOSARR-RTE的的接口。另外外DCM也处处理一些基本本诊断服务。在AUTOSAAR体系结构构中，诊断通通信管理器（DDCM）处在在通信服务中中（服务层）。DDCM是应用用和PDU路路由器封装的的车辆网络通通信（CANN、LIN、FFlexRaay和MOSST）之间的的中间层。DDCM与PDDU路由器之之间有一个接接口。在通信信过程中，DDCM从PDDU（

35、Prootocoll Dataa Unitt）路由器接接收诊断消息息。DCM在其内部部处理、检查查诊断消息，并并把消息传送送到AUTOOSAR SSW组件进一一步处理。根根据诊断服务务ID，将执执行应用层中中的相应调用用。DCM必须是网网络无关的，所所以协议和消消息配置在DDCM的下层层。这需要连连接到PDUU路由器的网网络无关接口口。DCM由以下功功能块组成：DSP - DDiagnoostic Serviice PrrocesssingDSP主要包含含了完整实现现的诊断服务务，这些服务务在不同的应应用之中是通通用的（例如如，访问故障障数据），所所以不需要由由应用实现。DSD-Diaagno

36、sttic Seervicee DisppatcheerDSD的目的是是处理诊断数数据流。这里里的处理意味味着：通过网络接收新新的诊断请求求并发送到数数据处理器。当被应用触发时时，通过网络络传送诊断响响应（AUTTOSAR SW-Coomponeent或DSP）。DSL-Diaagnosttic Seessionn LayeerDSL保证数据据流与诊断请请求和响应有有关。DSLL也监督和确确保诊断协议议计时。进一一步，DSLL管理诊断状状态。存储栈存储服务存储服务由一个个NVRAMM管理器模块块构成，负责责管理非易失失性数据（从从不同存储驱驱动读/写）。它它需要一个RRAM镜像作作为数据接口口

37、提供给应用用快速读取。存储服务的任务务是以统一方方式向应用提提供非易失性性数据。这抽抽象了存储位位置和属性。提提供非易失性性数据管理机机制，如保存存、加载、校校验和保护和和验证、可靠靠存储等。存储硬件抽象的的寻址方案存储抽象接口和和下层的闪存存EEPROOM仿真和EEEPROMM抽象层向NNVRAM管管理器提供虚虚拟线性322位地址空间间。这些逻辑辑32位地址址由16位逻逻辑块号和116位块地址址偏移量组成成。因此NVVRAM管理理器（理论上上）可以有665536个个逻辑块，每每个逻辑块（理理论上）可以以有64Kbbytes。NVRAM管理理器进一步将将16位逻辑辑块号划分为为以下部分：（16

38、-NNVM_DAATASETT_SELEECTIONN_BITSS）位的块标标识符NVM_DDATASEET_SELLECTIOON_BITTS位的数据据索引，每个个NVRAMM块最多可以以有256个个数据集NVRAM管理理器非易失性RAMM管理器（NNVRAM Managger）管理理所有非易失失性存储器中中数据的存储储。NVRAM管理理器本身与硬硬件无关，所所有直接存取取硬件的功能能，例如内部部或外部EEEPROM、内内部或外部闪闪存中的仿真真EEPROOM等，封装装在基本SWW的较低层。在在汽车环境中中，NVRAAM管理器提提供服务以根根据各个数据据的需求来保保证数据存储储和NV数据据的

39、维护。NNVRAM管管理器要能够够管理EEPPROM和/或FLASSH EEPPROM仿真真设备的NVV数据。NVVRAM管理理器为NV数数据的管理和和维护提供所所需的同步/异步服务（初初始化/读/写/控制）。NNVRAM管管理器处理对对非易失性数数据的并行访访问，并为单单个数据元素素提供可靠性性机制，如校校验和保护。为了适用于汽车车系统的所有有领域，NVVRAM管理理器需要具有有高度的伸缩缩性（如定义义请求队列的的数目和大小小，支持不同同的块管理类类型，EEPPROM仿真真，等等）。基本存储对象NV块：NV块块表示NV用用户数据和CCRC值（可可选）组成的的存储区；RAM块：RAAM块表示在

40、在RAM中用用户数据和CCRC值（可可选）组成的的区域；ROM块：ROOM块驻留在在ROM（闪闪存）中，用用于提供缺省省数据以防NNV块为空或或被破坏；管理块：管理块块在RAM中中，包含与DDataseet NV块块关联的块索索引。另外，也也包含相应NNVRAM块块的属性/错错误/状态信信息。块管理类型以下NVRAMM存储类型应应该由NVRRAM管理器器支持，并且且由以下基本本存储对象构构成：管理类型NV块RAM块ROM块管理块NVM_BLOOCK_NAATIVE110.11NVM_BLOOCK_REEDUNDAANT210.11NVM_BLOOCK_DAATASETT1.（m2256）10.

41、n1Nativee NVRAAM块是最简简单的块管理理类型。以最最小的开销存存储/检索NNV存储区。Native NVRAM块由单个NV块、RAM块和管理块组成。Redunddant NNVRAM块块有更高的容容错性、可靠靠性和可用性性，以及对数数据被破坏的的抵抗性。RRedunddant NNVRAM块块由两个NVV块、一个RRAM块和管管理块组成。Dataseet NVRRAM块是相相同大小数据据块（NV/RAM）的的阵列。应用用一次只能存存取其中的一一个。Dattaset NVRAMM块由多个NNV用户数据据和（可选）CCRC区域、一一个RAM块块和管理块组组成。NVRAM管理理器的AP

42、II配置种类为了使NVRAAM管理器适适合于有限的的硬件资源，定定义了3种不不同的APII配置种类：API配置置种类3：所有规定的APPI调用都可可用。支持最最大的功能性性。API配置置种类2：API调用的中中间集可用。API配置置种类1：特别用于满足资资源非常有限限的系统，此此API配置置种类只提供供所需要的AAPI调用的的最小集。存储硬件抽象存储硬件抽象是是一组抽象于于外围存储设设备位置（片片上或板上）和和ECU硬件件布局的模块块。例如：片片上EEPRROM和外部部EEPROOM设备应该该可以通过相相同的机制存存取。通过存储器特有有抽象/仿真真模块访问存存储驱动（例例如EEPRROM抽象）

43、。通通过仿真EEEPROM接接口和闪存硬硬件单元，就就可以通过存存储抽象接口口访问这两种种类型的硬件件。存储硬件抽象的的任务是提供供访问内部（片片上）和外部部（板上）存存储设备和存存储硬件类型型（EEPRROM、闪存存）的相同机机制。EEPROM抽抽象EEPROM抽抽象层（EAA）扩展EEEPROM驱驱动，向上层层提供线性地地址空间上的的虚拟分段和和“实际上无限限制的”擦除/写循循环。除此之之外，它还应应该提供与EEEPROMM驱动相同的的功能。闪存EEPROOM仿真闪存EEPROOM仿真（FFEE）按照照闪存技术仿仿真EEPRROM抽象层层的行为。所所以它与EEEPROM抽抽象层有相同同的功

44、能和AAPI，并且且给出基于下下层闪存驱动动和闪存设备备的相似配置置。内存抽象接口内存抽象接口（MMemIf）允允许NVRAAM管理器存存取多个存储储抽象模块（FFEE或EAA模块）。内存抽象接口抽抽象于下层FFEE和EAA模块的数目目，并向上层层提供统一线线性地址空间间上的虚拟分分段。存储驱动EEPROM驱驱动EEPROM驱驱动提供读、写写、擦除EEEPROM的的服务。也提提供了用于比比较EEPRROM中数据据块和内存中中数据块的服服务。这些服服务是异步的的。有两类EEEPROMM驱动：内部EEPPROM驱动动外部EEPPROM驱动动内部EEPROOM驱动直接接访问微控制制器硬件，并并且定位

45、在微微控制器抽象象层。外部EEEPROMM驱动使用处处理程序（hhandleer）或驱动动访问外部EEEPROMM设备。它定定位在ECUU抽象层。两种类型的驱动动的功能需求求和功能范围围都是相同的的。所以APPI在语义上上是相同的。闪存驱动如果受到底层硬硬件的支持，闪闪存驱动提供供读、写和擦擦除闪存的服服务，以及设设置写/擦除除保护的配置置接口。闪存存驱动提供了了一个内置加加载器，以加加载闪存存取取代码到RAAM中，并在在需要的时候候执行写/擦擦除操作。在ECU应用模模式下，闪存存驱动只用于于闪存EEPPROM仿真真模块写数据据。在应用模模式下并不将将程序代码写写到闪存中。这这应该由启动动模式

46、处理，超超出了AUTTOSAR的的范围。有两类闪存驱动动：内部闪存驱驱动外部闪存驱驱动内部闪存的驱动动直接存取微微控制器硬件件，并且定位位在微控制器器抽象层。外外部闪存通常常通过微控制制器数据/地地址总线连接接，然后闪存存驱动使用总总线的处理程程序/驱动访访问外部闪存存设备。外部部闪存设备的的驱动定位在在ECU抽象象层。两种类类型的驱动的的功能需求和和功能范围都都是相同的。所所以API在在语义上是相相同的。通信栈AUTOSARR通信栈的概概貌如下图：AUTOSARR中的通信栈栈包含以下这这些部分：CANAUTOSSAR CAANAUTOSARR CAN模模型如下图：CAN驱动动CAN驱动为上上

47、层使用者提提供统一的接接口CAN接接口。CANN驱动尽可能能合理地隐藏藏了相关CAAN控制器的的硬件专用性性。CAN驱动是最最底层的一部部分，为上层层执行对硬件件的访问和提提供硬件无关关的API。上上层中唯一能能够访问CAAN驱动的是CAAN接口。如果几个CANN控制器属于于相同的CAAN硬件单元元，那么它们们能够由CAAN驱动来控控制。一个CAN控制制器总是与一一个物理通道道相关联。它它被允许与总总线上的物理理通道相连接接，不管CAAN接口是否否将相关的CCAN控制器器分别对待。CAN接口口（硬件抽象象）CAN接口提供供标准化的接接口，通过EECU的CAAN总线系统统来支持通信信。其APII

48、与专用CAAN控制器及及其通过CAAN驱动层的的访问无关。CCAN接口能能够通过统一一的接口访问问一个或多个个CAN驱动动。CAN接口仅能能用于CANN通信，并且且是为操作一一个或多个底底层CAN驱驱动而专门设设计。涵盖不不同CAN硬硬件单元的几几个CAN驱驱动模块由一一个在CANN驱动规范中中指定的通用用接口来表示示。CAN之之外（也就是是LIN）的的其他协议不不支持。CAN传输输层CAN传输层是是位于PDUU路由和CAAN接口模块块之间的模块块。其主要作作用是分割和和合并大于88字节的CAAN I-PPDU。根据AUTOSSAR基本软软件体系结构构，CAN传传输层提供的的服务有：发送方向的

49、数据据分割；接收方向的数据据合并；数据流控制；分割期间内的错错误检测。 AUTTOSAR体体系结构定义义了通信系统统的各个具体体的传输层（CCanTp、包包含LinIIf的LinnTp、FllexRayyTp）。因因此，CANN传输层仅涵涵盖了CANN传输协议的的细节。 CANN传输层拥有有一个接口，该该接口连接一一个单独的下下层CAN接接口层和一个个单独的上层层PDU RRouterr模块。 根据AAUTOSAAR发布的计计划，该CAAN传输层规规范包含下面面的限制： - CAN传传输层仅运行行在事件触发发模式中，- 没有传传送/接收撤撤消。CAN收发发器驱动CAN收发器驱驱动负责处理理EC

50、U上的的CAN收发发器，依据的的是与整个EECU当前状状态相关的总总线专用NMM的状态。CAN收发设备备驱动的目标标：CAN收收发设备驱动动抽象使用CCAN收发设设备硬件芯片片。它向更高高层提供硬件件无关接口。它它也可以通过过MCAL层层的API从从ECU设计计中抽象出来来，访问CAAN收发设备备硬件。 CANN收发设备硬硬件必须提供供功能和接口口，以映射到到AUTOSSAR CAAN收发设备备驱动的运行行模式模型上上。下层驱动（SPPI和DIOO）使用的AAPI必须同同步。不支持持同步行为的的下层驱动的的实现不能与与CAN收发发设备驱动一一起使用。COMAUTOSSAR COOMAUTOSA

51、RR COM层层位于RTEE和PDU路路由器之间。它它来源于OSSEK_COOM标准。AAUTOSAAR COMM提供了信号号网关功能。COM与其它模模块的依赖关关系如下图所所示：COM MManageerCOM Mannager（CCOM管理）是基本软件Basic Software（BSW）的一个组件。它是囊括了下层通信服务的控制的资源管理。COM Mannager控控制的基本软软件模块（BBSW）与通通信相关，而而不是与软件件组件或可运运行实体相关关。COM Mannager从从通信请求者者那里收集总总线通信访问问请求，并协协调总线通信信访问请求。COM Mannager的的目标是：（1）

52、为用户简简化总线通信信栈的使用。这这包括了总线线通信栈的初初始化和简化化的网络管理理处理。（2）协调与多多个软件组件件（在一个EECU上）无无关的总线通通信栈（允许许信号的发送送和接收）的的可用性。（3）临时性取取消信号的发发送以阻止EECU唤醒通通信总线。（4）控制ECCU的一个以以上的通信总总线通道，这这通过为每个个通道实现一一种状态机制制来实现。（5）提供使EECU保持总总线处于“静静默通信”模模式。（6）通过分配配对请求通信信模式必需的的所有资源来来简化资源管管理。COM Maanagerr包含以下基基本功能：状态机制无通信状态静默通信状态：网络释放状状态、预备总总线睡眠状态态完全通信

53、状态：网络请求状状态、准备睡睡眠状态扩展功能状态期间范围通信阻止：总线线唤醒阻止、静静默通信模式式的限制、无无通信模式的的限制总线通信管理网络管理依赖总线错误管理CAN总线关闭闭处理CANN Bus Off hhandliing网络起动指示NNetworrk Staart Inndicattion传输故障例外网络超时例外测试支持需求阻止完全通信请请求计数器错误分类错误检测错误通知非功能性需求AUTOSSAR COOM与OSEEK COMM的比较根据通信部分分提供的功能能，对比两者者在相同功能能上的APII，以及两者者各自所特有有的API，由由于AUTOOSAR CCOM较之OOSEK CCOM

54、，多出出了一个COOM Mannager，即即通信管理模模块部分，所所以整个AUUTOSARR COM Managger为AUUTOSARR标准所特有有，下面先对对两者的相同同功能部分作作比较。1、相同功能及及服务（1）启动与控控制服务OSEKAUTOSARRStartCOOMStopCOMMGetCOMAAppliccationnModeInitMesssageStartPeeriodiicStopPerriodiccCom_IniitCom_DeIInitCom_IpdduGrouupStarrtCom_IpdduGrouupStoppCom_DissableRRecepttionDMMC

55、om_EnaableReeceptiionDMCom_GettStatuusCom_GettConfiigurattionIddCom_GettVersiionInffo两者在通信的的启动与控制制服务部分的的对比可以看看出：首先，AAUTOSAAR提供的AAPI较多，表表明它的功能能较强；其次次，AUTOOSAR的启启动与控制服服务中包含对对I-PDUU（交互层协协议数据单元元）的处理和和控制，如CCom_IppduGrooupStaart、Coom_IpdduGrouupStopp。（2）通信服务务OSEKAUTOSARRSendMesssageReceiveeMessaageSendDyn

56、namicMMessaggeReceiveeDynammicMesssageSendZerroMesssageGetMesssageSttatusCOMErroorGetSServicceIdCOMErroor_Namme1_Naame2Com_SenndSignnalCom_RecceiveSSignallCom_UpddateShhadowSSignallCom_SenndSignnalGrooupCom_RecceiveSSignallGrouppCom_RecceiveSShadowwSignaalCom_InvvalidaateSiggnalCom_InvvalidaateShaad

57、owSiignalCom_TriiggerIIPDUSeend通过对比可以以看出，OSSEK通信服服务中包含了了对错误的一一些简单的处处理，如获得得错误服务的的Id（COOMErroorGetSServicceId），而而AUTOSSAR通信服服务仍然包含含对I-PDDU的处理，如如Com_TTriggeerIPDUUSend。（3）通知机制制支持服务（OOSEK）与与回调通知服服务（AUTTOSAR）OSEKAUTOSARRReadFlaagResetFllagCom_TriiggerTTransmmitCom_RxIIndicaationCom_TxCConfirrmatioon两者在这个

58、部部分提供的功功能差别不大大，主要是对对一些标志的的修改和设置置，以控制通通信的状态和和执行的功能能。2、不同功能及及服务（1）OSEKK为I-PDDU的处理提提供一类专门门的服务，称称为OSEKK间接网络管管理接口，包包含2个APPI：I-PPDU传输指指示（I_MMessaggeTrannsfer）和和I-PDUU超时指示（II_MesssageTiimeOutt）。（2）OSEKK通信部分提提供了一些例例行程序对通通信起扩展作作用，包含33个API：StarttCOMExxtensiion、COOMCalllouts、CCOMErrrorHoook。（3）AUTOOSAR提供供了一些调度

59、度函数，主要要是对消息或或信号的接收收或发送起路路由、调度的的作用，包含含3个APII：Com_MainFFunctiionRx、CCom_MaainFunnctionnTx、Coom_MaiinFuncctionRRouteSSignalls。（4）AUTOOSAR的通通信部分有一一个COM Managger，这是是一个通信管管理模块，是是AUTOSSAR标准特特有的，主要要负责对通信信进行监控、管管理、诊断以以及管理涉及及通信的ECCU状态。下下表列出了它它所提供的部部分API。功能定义ComM_InnitComM_DeeInitComM_GeetStattusComM_GeetInhii

60、bitioonStattusComM_ReequesttComMoodeComM_GeetMaxCComModdeComM_GeetRequuesteddComMoodeComM_GeetCurrrentCoomModee专用函数AUTOSARR通用网络管管理ComM_Nmm_NetwworkSttartInndicattionComM_Nmm_TrannsmisssionFaailureeComM_Nmm_NetwworkTiimeouttAUTOSARR诊断通信管管理ComM_DCCM_ActtiveDiiagnossticComM_DCCM_InaactiveeDiagnnosticcA