2022年AUTOSAR技术分析报告.doc

《2022年AUTOSAR技术分析报告.doc》由会员分享，可在线阅读，更多相关《2022年AUTOSAR技术分析报告.doc（37页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

2、本身也变得越来越复杂。因而，不管汽车厂依然部件商都感到软件的标准化咨询题。软件的可治理性，可重复使用性，可裁减性，以及质量保证等等咨询题被提上了议程。AUTOSAR 的提出正是基于以上一些软件开展的要求，由几大主要汽车厂商以及部件提供商结合提出的，其中包括BWM, DaimlerChrysler, Ford Motor, PSA Peugeot, Toyota Motor, Volkswagen AG, Bosch, Continetal, Siemens VDO等。AUTOSAR是针对特定的汽车电子这一领域，提出的一套开放式软件构造。其主体思想是使得软件设计开发更易于治理，软件系统更易于移植

3、、裁剪，以及更好的维护性和质量保证。AUTOSAR组织所提出的目的以及它所关注的功能领域在下表中列出：工程目的功能领域处理汽车的可用性和平安性需求保持汽车电子系统一定的冗余能够移植到不同汽车的不同平台上实现标准的根本系统功能作为汽车供给商的标准软件模块通过网络共享软件功能集成多个开发商提供的软件模块在产品生命周期内更好的进展软件维护更充分的利用“货价产品”在车辆整个生命周期中进展软件更新与晋级为了实现上述的工程目的，针对在汽车电子行业中面临的一些挑战，AUTOSAR所采纳的处理方案及其好处能够概述如下：挑战处理方法好处不成熟的过程，由于ad-hoc形式/缺少对功能需要的追踪才能。缺少兼容的工具

4、（供给商、OEM）标准化的标准交换格式对标准的改良（格式、内容）提供无缝的工具链。浪费在实现和优化组件上的努力，而顾客并不承认这些努力的价值。根底软件核软件质量的加强。将工作集中在有价值的功能上。微操纵器模型缺乏可用性，特别难习惯现有软件。（由新功能引起的）微操纵器功能的扩展需求所导致的晋级需要（如重新设计）。微操纵器抽象微操纵器能在不需要改变更高软件层的情况下互换。重定位ECU之间的功能时需要做大量的工作。功能重用时也需要做大量的工作。运转时环境(RTE)功能封装导致的通讯技术的独立性。通过标准化机制，使得通讯更加简单。使功能分区和功能重定位变得可能。非竞争性功能必须习惯OEM的特定环境。由

5、于需要从其它组件供给接口需要特别多功夫，因而哪怕是特别微小的革新，也需要做特别多工作。根底软件和模型生成的代码间缺少明晰的接口。接口标准化减少/防止OEM和供给商之间的接口。通过使用通用接口目录，使独立于软件功能的硬件实现所耗费的工作量。简化模型驱动的开发，同意使用标准化的AUTOSAR代码生成工具。OEM间的模型的可重用性。不同供给商之间模块的可交换性。2 AUTOSAR软件构造2.1 AUTOSAR软件的组成与分层AUTOSAR的软件组件能够用以下图来表示：关于上图所示的一些组件，能够依照功能及互相关系对其进展分层，如以下图所示：微操纵器抽象层这一层是根底软件中的最低一层。它包含驱动，这些

6、驱动是软件模块，用来对C内部设备和映射了C外部设备的内存进展访咨询。ECU抽象层这一层与微操纵器抽象层进展对接。它也包含了外部设备的驱动。它为访咨询外设提供了API，不管这些外设的位置(C内部或外部)，也不管它们与C的连接(端口针脚，接口类型)。效劳层这层是根底软件中的最高层，而且它与应用软件之间有关联：当对I/O信号的访咨询包含ECU抽象层中时，效劳层提供：l 操作系统功能l 车辆网络通讯及治理效劳l 存储治理（NVRAM治理）l 诊断效劳（包括UDS通讯及错误内存）l ECU状态治理2.2 RTE运转时环境RTE是AUTOSAR ECU体系构造的核心组成部分。RTE是AUTOSAR虚拟功能

7、总线（Virtual Function Bus，VFB）的接口（针对某个特定ECU）的实现，因而，它为应用程序软件组件之间的通讯提供了根本的效劳，同时也便于访咨询包含OS的根本软件组件。应用程序软件组件包含独立于CPU和所处位置的系统软件。这就意味着，为了满足系统设计者所做的一些限制，应用程序组件能够在系统配置期间被映射到任何有效的ECU上。RTE负责确保这些组件能够通讯。RTE和OS,AUTOSAR COM和其他的根底软件模块（BSW）是VFB（Virtual Functional Bus）概念的实现。RTE实现了AUTOSAR VFB的接口，从而实现了AUTOSAR软件组件之间的通讯。RT

8、E是AUTOSAR ECU体系的核心,它提供了在AUTOSAR软件组件间通讯的根底效劳，扮演了一些方法，通过这些方法AUROSAR软件组件能访咨询包括OS和通讯效劳在内根底软件模块的。2.3 系统效劳系统效劳是一组能够由所有层次模块使用的模块和功能。例如实时操作系统、错误治理器和库功能。为应用和根本软件模块提供根本效劳。它包含以下图所示功能：2.3.1 AUTOSAR OSAUTOSAR OS为实时应用提供了所有根本效劳，即中断处理、调度、系统时间和时钟同步、本地音讯处理，以及错误检测机制。所有效劳都隐藏在良好定义的API之后。应用与OS和通讯层的连接只通过API。AUTOSAR OS的根本特

9、征包括：静态配置能够推断实时系统功能提供基于优先级的调度策略提供运转时保护功能（存储、计时等）可宿主在低端操纵器上，同时不需要其他资源它包含以下几个方面：实时操作系统在嵌入式汽车ECU中的实时操作系统构成软件动态行为的根底。它治理任务和事件的调度，不同任务间的数据流，同时提供监控和错误处理功能。但是，在汽车系统中，对操作系统的需求集中在特定领域。所使用的操作系统必须高效运转同时所占存储空间小。在多媒体和远程信息处理应用中，操作系统提供的特征集以及可用计算资源有特别大不同。在纯粹的任务治理之上，OS中还包含了复杂的数据处理（例如，流、快速文件系统等）、存储治理甚至图形用户接口。汽车OS的典型领域

10、涵盖了调度和同步的核心特征。在AUTOSAR中，上面讨论的附加特征在OS的范围之外，其他WP4.2.2.1工作包（例如SPAL）涵盖了这些特征。在AUTOSAR的体系构造约束之下不可能把其他OS（例如，QNX、VxWorks和Windows CE等）的特征集合集成到整体的OS/通讯/驱动构造中。因而，AUTOSAR OS只考虑核心特征。核心操作系统OSEK/VDK操作系统广泛应用于汽车工业，同时已经证明了能够在现代车辆的所有ECU类型中使用。OSEK OS引入的概念被广泛地理解，汽车工业领域在设计基于OSEK OS的系统方面有多年的经历。OSEK OS是一个事件触发的操作系统。这为基于AUTO

11、SAR的系统的设计和维护提供了高度的灵敏性。事件触发使得能够自由地选择在运转时驱动调度的事件，例如角反转、部分时间源、全局时间源、错误出现等等。由于这些缘故，AUTOSAR OS的核心功能必须基于OSEK OS。OSEK OS特别提供了以下特性以支持AUTOSAR： 固定的基于优先级调度 处理中断的功能 只有中断有高于任务的优先级 一些防止错误使用OS效劳的保护措施 StartOS()和StartupHook启动接口 ShutdownOS()和ShutdownHook关闭接口AUTOSAR OS基于OSEK OS意味着应用程序是向后兼容的。为OSEK OS编写的应用程序能够在AUTOSAR O

12、S上运转。但是，使用AUTOSAR OS引入的一些新特性需要对已存在的OSEK OS特性的使用有所限制。例如：为定时器回调实现定时和内存保护效率就会特别低。此外，AUTOSAR OS扩展了一些已存在的特性，例如直截了当通过定时器驱动计数器。AUTOSAR OS提供的API向后兼容于OSEK OS的API。新的需求作为功能扩展来集成。AUTOSAR OS对OSEK OS扩展的API如下表：效劳名语法GetApplicationIDApplicationType GetApplicationID (void)GetISRIDISRType GetISRID (void)CallTrustedFun

13、ctionStatusType CallTrustedFunction(TrustedFunctionIndexType FunctionIndex,TrustedFunctionParameterRefType FunctionParams)CheckISRMemoryAccessAccessType CheckISRMemoryAccess(ISRType ISRID,MemoryStartAddressType Address,MemorySizeType Size)CheckTaskMemoryAccessAccessType CheckTaskMemoryAccess(TaskTyp

14、e TaskID,MemoryStartAddressType Address,MemorySizeType Size)CheckObjectAccessObjectAccessType CheckObjectAccess(ApplicationType ApplID,ObjectTypeType ObjectType,)CheckObjectOwnershipApplicationType CheckObjectOwnership(ObjectTypeType ObjectType,)StartScheduleTableRelStatusType StartScheduleTableRel(

15、ScheduleTableType ScheduleTableID,TickType Offset)StartScheduleTableAbsStatusType StartScheduleTableAbs(ScheduleTableType ScheduleTableID,TickType Tickvalue)StopScheduleTableStatusType StopScheduleTable(ScheduleTableType ScheduleTableID)NextScheduleTableStatusType NextScheduleTable(ScheduleTableType

16、 ScheduleTableID_current,ScheduleTableType ScheduleTableID_next)IncrementCounterStatusType IncrementCounter(CounterType CounterID)SyncScheduleTableStatusType SyncScheduleTable(ScheduleTableType SchedTableID,GlobalTimeTickType GlobalTime)SetScheduleTableAsyncStatusType SetScheduleTableAsync(ScheduleT

17、ableType ScheduleID)GetScheduleTableStatusStatusType GetScheduleTableStatus(ScheduleTableType ScheduleID,ScheduleTableStatusRefType ScheduleStatus)TerminateApplicationStatusType TerminateApplication(RestartType RestartOption)DisableInterruptSourceStatusType DisableInterruptSource (ISRType DisableISR

18、)EnableInterruptSourceStatusType EnableInterruptSource (ISRType EnableISR)ProtectionHookProtectionReturnType ProtectionHook(StatusType Fatalerror)静态定义的调度在许多应用中需要静态定义一组互相关联的任务的活动。这用于在基于数据流的设计中保证数据一致性，与时间触发的网络同步，保证正确的运转时定相，等等。时间触发的操作系统通常作为这个咨询题的处理方法。然而，时间只是简单的事件，因而任何事件触发的OS，包括OSEK OS，会在汽车电子操纵单元实现一个用于静

19、态调度实时软件的调度器。监控功能监控功能在适当的执行阶段检测错误，不是在错误发生的时刻。因而，监控功能是在运转时捕捉失效，而不是预防毛病。保护功能AUTOSAR概念需要多来源的OS应用共存在同一处理器中。为了防止这些OS应用之间意想不到的交互，需要提供保护机制。计时器效劳计时器效劳为应用和根底软件提供软件计时器。计时机制的核心已经由OSEK OS的计数器和闹钟提供。假如要提供通用的软件计时，一些补充特性需要添加到AUTOSAR OS。时间触发操作系统时间触发操作系统在汽车电子操纵单元实现了一个用于静态调度实时软件的调度器。另外，操作系统为实时应用提供了所有根本效劳，即中断处理、调度、系统时间和

20、时钟同步、本地音讯处理，以及错误检测机制。所有效劳都隐藏在良好定义的API之后。应用与OS和通讯层的连接只通过API。关于特别的应用，操作系统能够配置为只包含该应用需要的效劳。因而操作系统的资源需求尽量少。2.3.2 BSW调度器BSW调度器是系统效劳的一部分，因而它向所有层次的所有模块提供效劳。但是，与其它BSW模块不同，BSW调度器提供了集成的概念和效劳。BSW调度器提供方法用以： 把BSW模块的实现嵌入AUTOSAR OS上下文 触发BSW模块的主要处理功能 应用BSW模块的数据一致性机制集成者的任务是应用所给的方法（AUTOSAR OS提供的），在特定工程环境中以良好定义和有效的方式把

21、BSW模块装配起来。这也意味着BSW调度器只是使用AUTOSAR OS。它与AUTOSAR OS调度器并不冲突。BSW调度器的实现基于： BSW模块的BSW模块描绘 BSW调度器的配置2.3.3 形式治理形式治理簇包括三个根本软件模块：ECU状态治理器，操纵AUTOSAR BSW模块的启动阶段，包括OS的启动；通讯治理器，负责网络资源治理；看门狗治理器，基于应用软件的生存状态触发看门狗。2.3.3.1 ECU状态治理器ECU状态治理器是一个根本软件模块，治理ECU的状态（OFF、RUN、SLEEP），以及这些状态之间的转换（过渡状态：STARTUP、WAKEUP、SHUTDOWN）。详细地，E

22、CU状态治理器：负责初始化和de-initialization所有根本软件模块，包括OS和RTE；在需要时与所谓的资源治理器（例如，通讯治理器）协作，关闭ECU；治理所有唤醒事件，并在被要求时配置ECU为SLEEP状态。为了完成所有这些任务，ECU状态治理器提供了一些重要的协议：RUN恳求协议，调整ECU是保持活动状态依然预备关闭，唤醒确认协议，从“不稳定的”唤醒事件中区分出“真正的”唤醒事件，时间触发的增多非工作状态协议（Time Triggered Increased Inoperation - TTII），同意ECU更多地进入节能的休眠状态。ECU状态治理器必须支持独立的预处理动作和过渡

23、，以启动ECU或将其转换到低功耗状态（例如，休眠状态/备用状态）。通过良好使用ECU状态治理器的特性和才能，此模块能够用于执行电源耗费的预定义策略，因而提供了对ECU的有效能源治理。ECU状态治理器的特性和优势包括：初始化和关闭根本软件模块。ECU主要状态的标准化定义。时间触发的更多非工作状态。2.3.3.2 看门狗治理器看门狗治理器是AUTOSAR（效劳层次）的标准化根本软件体系构造的根本软件模块。它监控与计时约束有关的应用执行的可靠性。分层体系构造方法使得应用计时约束和看门狗硬件计时约束别离。基于此，看门狗治理器在触发看门狗硬件的同时提供了对一些独立应用的生存监控。看门狗治理器提供以下特性

24、：监视多个处于ECU的单独应用，这些应用有独立的计时约束同时需要特别监视运转时的行为和生存状态。每个独立的受监控实体都有毛病响应机制。能够关闭对单独应用的监视，而不会违背看门狗触发（例如，关于禁止的应用）。通过看门狗驱动触发内部或外部、标准或窗口，看门狗。（internal or external, standard or window, watchdog）对内部或外部看门狗的访咨询由看门狗接口处理。依照ECU状态和硬件功能选择看门狗形式（Off Mode, Slow Mode, Fast Mode）。2.3.3.3 通讯治理器通讯治理器搜集并协调来自通讯恳求者（用户）的访咨询恳求。通讯治理器

25、的目的是：简化通讯协议栈的使用。包括通讯栈的初始化，以及简单的网络治理。调整ECU上多个独立软件组件的通讯栈（同意发送和接收音讯）的可用性。临时禁止发送音讯以阻止ECU（主动地）唤醒物理通道。通过为每个物理通道实现一个状态机来操纵ECU的多个物理通道。能够强迫ECU保持物理通道处于“silent 通讯”形式。分配所恳求的通讯形式需要的所有资源，简化资源治理。通讯治理器定义了“通讯形式”，表示一个特定的物理通道关于应用是否可用，以及如何使用（发送/接收，只接收，即不发送也不接收）。2.4 诊断效劳2.4.1 诊断事件治理器诊断事件治理器DEM（Diagnostic Event Manager）是

26、一个子组件，好像AUTOSAR内诊断模块的诊断通讯治理器（DCM）和功能禁止治理器（FIM）。它负责处理和存储诊断事件（错误）和相关FreezeFrame数据。DEM进一步提供毛病信息给DCM（例如，从事件存储器读取所有存储的DTC（Diagnostic Trouble Code）。DEM给应用层、DCM和FIM提供接口。定义了可选的过滤效劳。2.4.2 功能禁止治理器功能禁止治理器FIM（Function Inhibition Manager）负责提供软件组件和软件组件功能的操纵机制。功能由一个、多个或部分有一样权限/禁止条件的可执行实体构成。通过FIM方法，对这些功能的禁止能够配置甚至修正

27、。因而，极大地提高了功能在新系统环境下的习惯性。FIM意义上的功能与可执行实体是不同同时独立的类型。可执行实体主要由调度需求来区分。与此相对的是，功能由禁止条件来分类。FIM效劳关注SW-C的功能，但是并不局限于此。BSW的功能也能够使用FIM效劳。功能被指定了一个标识符（FID function identifier），以及该特定标识符的禁止条件。功能在执行之前获得它们各自的权限状态。假如禁止条件应用于特定标识符，对应的功能将不再执行。FIM与DEM亲密相关，由于诊断事件和它们的状态信息作为禁止条件被提供给FIM。假如检测到了失效，同时事件报告给了DEM，那么FIM禁止FID和对应的功能。为

28、了处理功能和关联事件的关系，功能的标识符和禁止条件必须引入到SW-C模板中（与BSW等价），同时在配置期间构造数据构造以处理标识符关于特定事件的敏感性。这些关系在每个FIM中是唯一的。RTE和FIM之间没有功能上的联络。在AUTOSAR中，RTE按照接口和调度需求处理SW-C。与此相对的是，FIM处理禁止条件并通过标识符（FID）为操纵功能提供支持机制。因而，FIM概念和RTE概念不互相关扰。2.4.3 开发错误跟踪器开发错误跟踪器DET（Development Error Tracer）主要用于在开发期间跟踪和记录错误。API参数给出了追踪源和错误类型： 错误所在的模块 错误所在的功能 错误

29、类型由软件开发者和软件集成者在特定应用和测试环境下为API功能选择最优的策略。可能包括以下功能： 在错误报告API内设置调试器断点 计算报告的错误 在RAM缓存中记录调用和传递的参数 通过通讯接口发送报告的错误到外部日志DET仅仅是对SW开发和集成的辅助，并不一定要包含在产品代码中。API已经定义，但是功能由开发者依照特定需求来选择/实现。2.4.4 诊断通讯治理器诊断通讯治理器DCM（Diagnostic Communication Manager）确保诊断数据流，同时治理诊断状态，特别是诊断对话期和平安状态。另外，DCM检查诊断效劳恳求是否被支持，以及依照诊断状态推断效劳是否能够在当前对话

30、期中执行。DCM为所有诊断效劳提供连接到AUTOSAR-RTE的接口。另外DCM也处理一些根本诊断效劳。在AUTOSAR体系构造中，诊断通讯治理器（DCM）处在通讯效劳中（效劳层）。DCM是应用和PDU路由器封装的车辆网络通讯（CAN、LIN、FlexRay和MOST）之间的中间层。DCM与PDU路由器之间有一个接口。在通讯过程中，DCM从PDU（Protocol Data Unit）路由器接收诊断音讯。DCM在其内部处理、检查诊断音讯，并把音讯传送到AUTOSAR SW组件进一步处理。依照诊断效劳ID，将执行应用层中的相应调用。DCM必须是网络无关的，因而协议和音讯配置在DCM的下层。这需要

31、连接到PDU路由器的网络无关接口。DCM由以下功能块组成：DSP - Diagnostic Service ProcessingDSP主要包含了完好实现的诊断效劳，这些效劳在不同的应用之中是通用的（例如，访咨询毛病数据），因而不需要由应用实现。DSD-Diagnostic Service DispatcherDSD的目的是处理诊断数据流。这里的处理意味着：通过网络接收新的诊断恳求并发送到数据处理器。当被应用触发时，通过网络传送诊断响应（AUTOSAR SW-Component或DSP）。DSL-Diagnostic Session LayerDSL保证数据流与诊断恳求和响应有关。DSL也监视和

32、确保诊断协议计时。进一步，DSL治理诊断状态。2.5 存储栈2.5.1 存储效劳存储效劳由一个NVRAM治理器模块构成，负责治理非易失性数据（从不同存储驱动读/写）。它需要一个RAM镜像作为数据接口提供给应用快速读取。存储效劳的任务是以统一方式向应用提供非易失性数据。这抽象了存储位置和属性。提供非易失性数据治理机制，如保存、加载、校验和保护和验证、可靠存储等。2.5.1.1 存储硬件抽象的寻址方案存储抽象接口和下层的闪存EEPROM仿真和EEPROM抽象层向NVRAM治理器提供虚拟线性32位地址空间。这些逻辑32位地址由16位逻辑块号和16位块地址偏移量组成。因而NVRAM治理器（理论上）能够

33、有65536个逻辑块，每个逻辑块（理论上）能够有64Kbytes。NVRAM治理器进一步将16位逻辑块号划分为以下部分：（16-NVM_DATASET_SELECTION_BITS）位的块标识符NVM_DATASET_SELECTION_BITS位的数据索引，每个NVRAM块最多能够有256个数据集2.5.1.2 NVRAM治理器非易失性RAM治理器（NVRAM Manager）治理所有非易失性存储器中数据的存储。NVRAM治理器本身与硬件无关，所有直截了当存取硬件的功能，例如内部或外部EEPROM、内部或外部闪存中的仿真EEPROM等，封装在根本SW的较低层。在汽车环境中，NVRAM治理器提

34、供效劳以依照各个数据的需求来保证数据存储和NV数据的维护。NVRAM治理器要能够治理EEPROM和/或FLASH EEPROM仿真设备的NV数据。NVRAM治理器为NV数据的治理和维护提供所需的同步/异步效劳（初始化/读/写/操纵）。NVRAM治理器处理对非易失性数据的并行访咨询，并为单个数据元素提供可靠性机制，如校验和保护。为了适用于汽车系统的所有领域，NVRAM治理器需要具有高度的伸缩性（如定义恳求队列的数目和大小，支持不同的块治理类型，EEPROM仿真，等等）。2.5.1.3 根本存储对象NV块：NV块表示NV用户数据和CRC值（可选）组成的存储区；RAM块：RAM块表示在RAM中用户数

35、据和CRC值（可选）组成的区域；ROM块：ROM块驻留在ROM（闪存）中，用于提供缺省数据以防NV块为空或被破坏；治理块：治理块在RAM中，包含与Dataset NV块关联的块索引。另外，也包含相应NVRAM块的属性/错误/状态信息。2.5.1.4 块治理类型以下NVRAM存储类型应该由NVRAM治理器支持，同时由以下根本存储对象构成：治理类型NV块RAM块ROM块治理块NVM_BLOCK_NATIVE110.11NVM_BLOCK_REDUNDANT210.11NVM_BLOCK_DATASET1.（m256）10.n1Native NVRAM块是最简单的块治理类型。以最小的开销存储/检索N

36、V存储区。Native NVRAM块由单个NV块、RAM块和治理块组成。Redundant NVRAM块有更高的容错性、可靠性和可用性，以及对数据被破坏的抵抗性。Redundant NVRAM块由两个NV块、一个RAM块和治理块组成。Dataset NVRAM块是一样大小数据块（NV/RAM）的阵列。应用一次只能存取其中的一个。Dataset NVRAM块由多个NV用户数据和（可选）CRC区域、一个RAM块和治理块组成。2.5.1.5 NVRAM治理器的API配置品种为了使NVRAM治理器合适于有限的硬件资源，定义了3种不同的API配置品种：API配置品种3：所有规定的API调用都可用。支持最

37、大的功能性。API配置品种2：API调用的中间集可用。API配置品种1：特别用于满足资源特别有限的系统，此API配置品种只提供所需要的API调用的最小集。2.5.2 存储硬件抽象存储硬件抽象是一组抽象于外围存储设备位置（片上或板上）和ECU硬件规划的模块。例如：片上EEPROM和外部EEPROM设备应该能够通过一样的机制存取。通过存储器特有抽象/仿真模块访咨询存储驱动（例如EEPROM抽象）。通过仿真EEPROM接口和闪存硬件单元，就能够通过存储抽象接口访咨询这两品种型的硬件。存储硬件抽象的任务是提供访咨询内部（片上）和外部（板上）存储设备和存储硬件类型（EEPROM、闪存）的一样机制。2.5

38、.2.1 EEPROM抽象EEPROM抽象层（EA）扩展EEPROM驱动，向上层提供线性地址空间上的虚拟分段和“实际上无限制的”擦除/写循环。除此之外，它还应该提供与EEPROM驱动一样的功能。2.5.2.2 闪存EEPROM仿真闪存EEPROM仿真（FEE）按照闪存技术仿真EEPROM抽象层的行为。因而它与EEPROM抽象层有一样的功能和API，同时给出基于下层闪存驱动和闪存设备的类似配置。2.5.2.3 内存抽象接口内存抽象接口（MemIf）同意NVRAM治理器存取多个存储抽象模块（FEE或EA模块）。内存抽象接口抽象于下层FEE和EA模块的数目，并向上层提供统一线性地址空间上的虚拟分段。

39、2.5.3 存储驱动2.5.3.1 EEPROM驱动EEPROM驱动提供读、写、擦除EEPROM的效劳。也提供了用于比拟EEPROM中数据块和内存中数据块的效劳。这些效劳是异步的。有两类EEPROM驱动：内部EEPROM驱动外部EEPROM驱动内部EEPROM驱动直截了当访咨询微操纵器硬件，同时定位在微操纵器抽象层。外部EEPROM驱动使用途理程序（handler）或驱动访咨询外部EEPROM设备。它定位在ECU抽象层。两品种型的驱动的功能需求和功能范围都是一样的。因而API在语义上是一样的。2.5.3.2 闪存驱动假如遭到底层硬件的支持，闪存驱动提供读、写和擦除闪存的效劳，以及设置写/擦除保

40、护的配置接口。闪存驱动提供了一个内置加载器，以加载闪存存取代码到RAM中，并在需要的时候执行写/擦除操作。在ECU应用形式下，闪存驱动只用于闪存EEPROM仿真模块写数据。在应用形式下并不将程序代码写到闪存中。这应该由启动形式处理，超出了AUTOSAR的范围。有两类闪存驱动：内部闪存驱动外部闪存驱动内部闪存的驱动直截了当存取微操纵器硬件，同时定位在微操纵器抽象层。外部闪存通常通过微操纵器数据/地址总线连接，然后闪存驱动使用总线的处理程序/驱动访咨询外部闪存设备。外部闪存设备的驱动定位在ECU抽象层。两品种型的驱动的功能需求和功能范围都是一样的。因而API在语义上是一样的。2.6 通讯栈AUTO

41、SAR通讯栈的概貌如以下图：AUTOSAR中的通讯栈包含以下这些部分：2.6.1 CANAUTOSAR CANAUTOSAR CAN模型如以下图：CAN驱动CAN驱动为上层使用者提供统一的接口CAN接口。CAN驱动尽可能合理地隐藏了相关CAN操纵器的硬件专用性。CAN驱动是最底层的一部分，为上层执行对硬件的访咨询和提供硬件无关的API。上层中唯一能够访咨询CAN驱动的是CAN接口。假如几个CAN操纵器属于一样的CAN硬件单元，那么它们能够由CAN驱动来操纵。一个CAN操纵器总是与一个物理通道相关联。它被同意与总线上的物理通道相连接，不管CAN接口是否将相关的CAN操纵器分别对待。CAN接口（硬

42、件抽象）CAN接口提供标准化的接口，通过ECU的CAN总线系统来支持通讯。其API与专用CAN操纵器及其通过CAN驱动层的访咨询无关。CAN接口能够通过统一的接口访咨询一个或多个CAN驱动。CAN接口仅能用于CAN通讯，同时是为操作一个或多个底层CAN驱动而专门设计。涵盖不同CAN硬件单元的几个CAN驱动模块由一个在CAN驱动标准中指定的通用接口来表示。CAN之外（也确实是LIN）的其他协议不支持。CAN传输层CAN传输层是位于PDU路由和CAN接口模块之间的模块。其主要作用是分割和合并大于8字节的CAN I-PDU。依照AUTOSAR根本软件体系构造，CAN传输层提供的效劳有：n 发送方向的

43、数据分割；n 接收方向的数据合并；n 数据流操纵；n 分割期间内的错误检测。 AUTOSAR体系构造定义了通讯系统的各个详细的传输层（CanTp、包含LinIf的LinTp、FlexRayTp）。因而，CAN传输层仅涵盖了CAN传输协议的细节。 CAN传输层拥有一个接口，该接口连接一个单独的下层CAN接口层和一个单独的上层PDU Router模块。 依照AUTOSAR发布的计划，该CAN传输层标准包含下面的限制： - CAN传输层仅运转在事件触发形式中，- 没有传送/接收撤消。CAN收发器驱动CAN收发器驱动负责处理ECU上的CAN收发器，依照的是与整个ECU当前状态相关的总线专用NM的状态。

44、CAN收发设备驱动的目的：CAN收发设备驱动抽象使用CAN收发设备硬件芯片。它向更高层提供硬件无关接口。它也能够通过MCAL层的API从ECU设计中抽象出来，访咨询CAN收发设备硬件。 CAN收发设备硬件必须提供功能和接口，以映射到AUTOSAR CAN收发设备驱动的运转形式模型上。下层驱动（SPI和DIO）使用的API必须同步。不支持同步行为的下层驱动的实现不能与CAN收发设备驱动一起使用。2.6.2 COMAUTOSAR COMAUTOSAR COM层位于RTE和PDU路由器之间。它来源于OSEK_COM标准。AUTOSAR COM提供了信号网关功能。COM与其它模块的依赖关系如以下图所示

45、：COM ManagerCOM Manager（COM治理）是根本软件Basic Software（BSW）的一个组件。它是囊括了下层通讯效劳的操纵的资源治理。COM Manager操纵的根本软件模块（BSW）与通讯相关，而不是与软件组件或可运转实体相关。COM Manager从通讯恳求者那儿搜集总线通讯访咨询恳求，并协调总线通讯访咨询恳求。COM Manager的目的是：（1）为用户简化总线通讯栈的使用。这包括了总线通讯栈的初始化和简化的网络治理处理。（2）协调与多个软件组件（在一个ECU上）无关的总线通讯栈（同意信号的发送和接收）的可用性。（3）临时性取消信号的发送以阻止ECU唤醒通讯总线

46、。（4）操纵ECU的一个以上的通讯总线通道，这通过为每个通道实现一种状态机制来实现。（5）提供使ECU保持总线处于“静默通讯”形式。（6）通过分配对恳求通讯形式必需的所有资源来简化资源治理。COM Manager包含以下根本功能：状态机制无通讯状态静默通讯状态：网络释放状态、预备总线睡眠状态完全通讯状态：网络恳求状态、预备睡眠状态扩展功能状态期间范围通讯阻止：总线唤醒阻止、静默通讯形式的限制、无通讯形式的限制总线通讯治理网络治理依赖总线错误治理CAN总线关闭处理CAN Bus Off handling网络起动指示Network Start Indication传输毛病例外网络超时例外测试支持需求阻止完全通讯恳求计数器错误分类错误检测错误通知非功能性需求AUTOSAR COM与OSEK COM的比拟依照通讯部分提供的功能，比照两者在一样功能上的API，以及两者各自所特有的API，由于AUTOSAR COM较之OSEK COM