汽车电子控制器处理芯片及ECU板级抽象技术研究报告资料.doc

《汽车电子控制器处理芯片及ECU板级抽象技术研究报告资料.doc》由会员分享，可在线阅读，更多相关《汽车电子控制器处理芯片及ECU板级抽象技术研究报告资料.doc（48页珍藏版）》请在三一办公上搜索。

1、 密级： 汽车电子控制器处理芯片及ECU板级抽象技术研究报告编号TM-DMP-01-RD-PRE-013拟制陈丽蓉日期 2010 年 2 月 1 日审核日期 年 月 日会签日期 年 月 日标准化日期 年 月 日批准日期 年 月 日顾客/代表日期 年 月 日修订历史记录日期&修订人修订记录版本标识备注2010/4/20陈丽蓉完成初稿V1.02010-4-29赵焕宇增加硬件特征描述V1.1目 录引言1背景1概述1缩写词和名词定义1参考资料21 AUTOSAR国际标准分析31.1 系统概述31.2 微控制器抽象层71.3 复杂驱动171.4 ECU抽象层191.6 抽象接口实现示例321.7 主要参

2、考的AUTOSAR规范列表352 主流汽车电子嵌入式微处理器及ECU硬件特性分析372.1 MPC563X嵌入式微处理器特性372.2 MPC5554特性382.3 MPC555特性392.4 9S12X特性402.5 9S12DP512特性412.6 HCS08特性412.7 STM08特性423 开发环境433.1 基础开发工具433.2 配置生成工具444 国内汽车厂商应用需求分析444.1 一汽应用需求分析444.2 上汽应用需求分析504.3 奇瑞应用需求分析504.4 长安应用需求分析505 汽车电子控制器处理芯片及ECU板级抽象软件实现策略515.1 控制器处理芯片抽象软件实现策

3、略515.2 ECU板级抽象软件实现策略51引言背景本项目来源于核高基重大专项3-1课题：实时嵌入式操作系统及开发环境，本项目为该课题的分课题：汽车电子硬件抽象技术研究。在分课题中，科银京成将以总课题组制定的汽车电子基础软件平台体系规范为基础，通过对国内外相关技术和标准的充分研究，以及汽车电子控制系统硬件平台的详细调研，研究汽车电子硬件抽象的关键技术，设计开发汽车电子基础软件平台中的硬件驱动软件模块，并实现对电子控制单元（ECU）和微控制器外部设备的抽象，为汽车电子基础软件平台中其他相关的软件组件如嵌入式实时操作系统与系统服务、存储服务、通信服务等各种服务及管理组件（包括驱动自身的管理组件）提

4、供支持和功能调用、以及系统的引导启动、系统软件加载等支撑服务；为支撑本课题组形成汽车电子应用软件设计、编程、调试、仿真、集成、测试、部署的一体化工具环境，提供与硬件适配相关的图形化配置工具、部署工具及接口，以便在进行应用开发时能有效地完成硬件相关的配置和使用。概述本文档将从以下几方面描述有关汽车电子控制器处理芯片及ECU板级抽象技术研究的内容：l AUTOSAR标准分析l 主流汽车电子嵌入式微处理器及ECU硬件特性分析l 开发环境l 国内汽车厂商应用需求分析l 汽车电子控制器处理芯片及ECU板级抽象软件实现策略缩写词和名词定义缩写、术语解 释AUTOSARAUTomotive Open Sys

5、tem Architecture 汽车开放系统结构DIODigital Input/Output 数字输入/输出ADCAnalogue Digital Converter 模数转换器SPISerial Peripheral Interface 串行外设接口PWMPulse Width Modulation 脉冲宽度调制PORT端口ICUInput Capture Unit 输入捕获单元Watchdog看门狗FLASH闪存EEPROM电子可檫除、可编程只读存储器RAM test内存测试CANController Area Network 控制器局域网Timer定时器SCI串行通信接口参考资料l

6、AUTOSAR 3.1系列规范l 各种汽车电子嵌入式微处理器芯片手册、ECU板级资料1 AUTOSAR国际标准分析以AUTOSAR 3.1为参考，对汽车电子基础软件架构进行分析，通过对AUTOSAR、OSEK国际规范的分析和研究，包括在：标准接口、配置描述语言、基本数据类型、文件组织结构、错误处理机制等内容上，集合国内整车厂商和零部件厂商的实际需求，形成自主汽车电子基础软件规范中关于汽车电子硬件抽象层（板载设备抽象、存储器抽象、通信器件抽象、I/O硬件抽象等）统一接口规范。1.1 系统概述图1展示了AUTOSAR软件架构的主要层次关系，总体上可分为应用层、运行时环境、基础层（包括操作系统与系统

7、服务、存储服务、通信服务、硬件抽象与驱动层）。图1 AUTOSAR嵌入式软件架构图2 AUTOSAR嵌入式软件分层架构图3 AUTOSAR嵌入式软件各层次模块目标硬件环境适配层处于汽车电子基础软件平台中最底层的位置，其作用是向上层软件屏蔽微控制器和ECU硬件设备驱动的细节和差异，是降低汽车电子应用软件与硬件的相关性，提高汽车电子应用软件和功能组件可重用性和可移植性的重要技术手段。本课题中目标硬件环境适配层由硬件抽象层和设备驱动层组成，如下图所示：图4 目标硬件环境适配层注：上图中Flash Check，Ext Watchdog Driver，Ext EEPROM Driver，Ext Flas

8、h Driver，Ext Can Driver，Ext FlexRay Driver，Complex Driver等7个基础软件模块目前不属于AUTOSAR 3.1的规范。设备驱动层提供控制和访问设备的功能，由以下模块组成：1、 通信驱动程序ECU板上（如SPI）和车辆通信（如CAN）的驱动程序。2、 I/O驱动程序模拟和数据I/O（如ADC、PWM、DIO）的驱动程序。3、 存储驱动程序片上存储设备（如内部FLASH、内部EEPROM）及内存映射的外部存储设备（如外部FLASH）驱动程序。4、 微控制器驱动程序其它内部设备（如Watchdog、通用时钟）的驱动程序；直接访问微控制器的功能（如

9、核心调试）。设备抽象层对ECU板上设备的物理特性进行抽象，向操作系统、系统服务和支撑服务提供统一的访问接口。汽车电子硬件抽象技术的研究必要性，主要由于汽车电子系统应用的硬件环境差异软大，因此，如何有效地使汽车电子系统软件应用于各种不同的应用环境是汽车电子发展中必须解决的关键问题，经过不断的发展，在操作系统内核和各类服务层软件与微控制器硬件之间新增加抽象技术，包含操作系统内核和各类服务层及硬件所要求的所有功能，通过标准统一的接口与上层操作系统和各类服务进行交互，向底层硬件传递信息，这样就有效地屏蔽了底层硬件的多样性，上层操作系统和各类服务不再直接面对具体的硬件环境，使硬件系统与软件系统得到了很好

10、分离，大大提高了移植性和重用性。对汽车电子硬件抽象技术的研究主要达到的目标是：隐藏特定平台的硬件接口细节，为操作系统实时内核、系统服务、存储服务、通信服务、提供所需硬件支持的所有功能和统一的标准接口，使其具有与硬件无关性，可在多种硬件平台上进行移植，从软硬件测试的角度来看，软硬件的测试工作都可分别基于硬件抽象层来完成，使得软硬件测试工作的并行进行成为可能。1.2 微控制器抽象层图5 微控制器抽象层模块图1.2.1 通信驱动通信驱动层主要包括：SPI驱动、LIN驱动、CAN驱动、FlexRay驱动等内容。1.2.1.1 SPI驱动（SPI Handler Driver）SPI驱动提供外设的SPI

11、读写通信控制驱动。在很多ECU中，许多板载硬件设备如外部EEPROM，外部I/O ASIC，外部看门狗等，通过SPI与微控制器连接，如下图所示。图6 通过SPI接口访问各种板级外设SPIHandlerDriver允许多个客户端对一个或多个SPI总线的并发访问。为了抽象SPI的特征，SPIHandlerDriver要直接处理微控制器中的片选引脚。这就意味着这些引脚对DIO驱动无效。SPI总线是一种主从多节点总线系统，主节点设置片选（CS）来选择一个从节点来进行数据通信。SPI有一个4线的同步串行接口。使用片选线来激活数据通信。SPI模块提供基于通道的对SPI总线上的不同设备的读、写和传输访问。S

12、PI通道代表数据元素（8到16比特）。这些通道可能是顺序组合的，不能够被中断。通道有一个静态配置定义的波特率、片选等等。SPI设备通常由所使用的SPI硬件单元和相关的片选线来标识。这个模块能够作为SPI主节点来使用。这个软件模块的功能范围应该是可静态配置的，以尽可能多的适应每个ECU的时间需要。那就是说，比如同步的、异步的、或者两者都有的SPI访问都可以存在于ECU。因此，两个SPI驱动可以存在，但仅有一个处理接口。SPI处理程序/驱动提供了一些服务来对通过SPI总线连接的设备进行读写。它提供了所需的机制来配置片上SPI外设。单片式的SPI处理程序/驱动包含处理和驱动功能。它的主要目标是充分利

13、用每个微控制器的特性，使得依赖于静态配置的实现最优化，以尽可能多的适应ECU的需要。1.2.1.2 LIN驱动LIN驱动为上层的LIN 接口模块提供硬件抽象接口，负责对LIN 硬件进行控制，比如初始化。对于属于相同LIN硬件单元LIN驱动模块支持多路通道。只支持LIN2.0主节点。其软件架构如下图：图7 LIN Driver架构LIN驱动是最底层的一部分，执行硬件访问和为上层提供硬件无关的API。上层唯一能够访问到LIN驱动的就是LIN接口。一个LIN驱动能够支持一个以上的通道。LIN驱动能够处理一个或多个属于相同LIN硬件单元的LIN通道。1.2.1.3 CAN驱动CAN驱动为上层的CAN

14、接口模块提供硬件抽象接口，负责对CAN硬件传输进行初始化，实现事件通知，控制属于相同CAN硬件单元的CAN控制器。CAN驱动尽可能合理地隐藏了相关CAN控制器的硬件专用性。CAN驱动是最底层的一部分，为上层执行对硬件的访问和提供硬件无关的API。上层中唯一能够访问CAN驱动的是CAN接口。如果几个CAN控制器属于相同的CAN硬件单元，那么它们能够由CAN驱动来控制。一个CAN控制器总是与一个物理通道相关联。它被允许与总线上的物理通道相连接，不管CAN接口是否将相关的CAN控制器分别对待。1.2.1.4 FlexRay驱动FlexRay驱动为上层的FlexRay 接口模块提供硬件抽象接口，负责对

15、FlexRay 硬件传输进行初始化，实现事件通知，控制属于相同FlexRay 硬件单元的FlexRay 控制器。FlexRay驱动模块必须为FlexRay接口模块、API的使用者提供统一接口，以访问许多FlexRay通信控制器，这些控制器通常是相同类型的。FlexRay驱动是一个软件层，它将抽象功能请求映射到CC专用硬件的序列上。CC的硬件实现将从FlexRay接口隐藏。1.2.2 I/O驱动1.2.2.1 ICU驱动ICU输入捕获单元驱动：对周期性输入信号进行频率检测以及占空比测量，计算脉冲，解调脉宽调制信号，捕获非周期输入信号，产生相应的中断或唤醒中断。ICU驱动提供了下列特性：周期性的、

16、低端的、高端的时间测量边缘检测和通知边缘计数边缘时间戳，可用于获取非周期的信号唤醒中断对于信号边缘检测来说，需要使用捕获比较单元的边缘检测器或外部时间的中断控制器。对于信号测量来说，需要一个捕获计时器以及至少一个捕获寄存器。ICU调制PWM信号，计算脉冲，测量频率和责任（duty）周期，产生简单的中断以及唤醒中断。为了保证数据一致性，应该提供可重入的代码。时间单元节拍为了从寄存器值中获得时间，需要知道振荡器频率、预定标器等等。因为这些设置是在MCU模块中或其它模块中产生的，不可能计算这些时间。因此，时间和节拍之间的转换是由上层负责的。1.2.2.2 PWM驱动PWM脉宽调制驱动负责对微控制器内

17、部PWM端口进行初始化和控制。每个PWM通道都连接到一个属于微控制器的硬件PWM上。该驱动提供了初始化和控制微处理器内部的PWM的服务。PWM模块产生有不同脉冲宽度的脉冲。1.2.2.3 ADC驱动ADC模数转换驱动：负责对微控制器内部ADC端口进行初始化和控制。ADC驱动初始化并控制微控制器内部的模数转换单元。该驱动包含一系列的基本功能函数。为了能够在某些特殊的应用中进行信号的频率分析（例如，快速傅立叶变换），就需要加强流式存取的功能。ADC驱动提供以下服务：信号值结果的访问模式流式访问。通常，ADC通道的变换请求通过ADC通道组来进行控制。通道组可以运行于持续的变换模式或者单触发变换模式。

18、变换处理和交互作用：在同一时刻，ADC驱动要管理一个以上的被配置成不同变换模式的组。转换过程：通常，ADC通道的转换请求通过ADC通道组来进行控制。一个组可以运行于持续的转换模式或者单触发转换模式。单触发转换模式的触发条件也要被配置和控制。如果通道运行于不同的模式（例如，在普通操作时采用持续的转换模式，在特定时间点的特殊转换时使用单触发或者按照命令的转换方式），通道必须被分配给拥有不同操作模式的多个组。为了改变组间共享的通道的操作模式，应用程序必须停止任何对包含指定通道的组的当前转换，然后启动包含指定通道的新组的转换。为了让应用程序能够在任何时候执行立即转换，就要定义一个按照命令的转换方式。它

19、必须挂起组转换，然后在按照命令的转换活动完成后重新激活它。1.2.2.4 DIO驱动DIO数字化I/O驱动负责对DIO通道的管脚和组以及端口进行读写。DIO驱动提供基于端口和通道的、对内部通用I/O断点的读和写访问。这里的读和写并不被缓冲。这个驱动的基本行为是同步的。DIO驱动提供了用于对下列设施进行读、写的服务：DIO通道（引脚）DIO端口DIO通道组这些服务的行为是同步的。该模块工作于引脚和端口上，由PORT驱动来对它进行配置。因此，在DIO驱动里面就没有对该端口结构进行配置和初始化。端口驱动模块：很多端口和端口引脚是由端口驱动模块分配给各种功能的，比如常规I/OADCSPIPWMDIO驱

20、动抽象了对微控制器硬件引脚的访问。此外，它还能够对这些引脚进行分组。DIO驱动提供以下服务：一个一个地修改端口或通道组的输出通道的等级。一个一个地读取端口或通道组的输入和输出通道的等级。DIO驱动中的所有读写服务必须是可重入的。理由是：这些DIO驱动可以被不同的上层处理程序或驱动程序访问。这些上层模块可以并行的访问驱动。1.2.2.5 PORT驱动PORT(端口)驱动提供微控制所有端口的初始化。该模块初始化微控制器的整个端口结构。很多端口和端口引脚可以被分配给不同的功能，比如：通用I/OADCSPISCIPWM由于这个原因，必须对这个端口结构进行总的配置和初始化。这些端口引脚的配置和使用是依赖

21、于微控制器和ECU的。该模块应该提供用于初始化微控制器的整个端口结构的服务。很多端口和端口引脚可以被分配给各种不同的功能。由于这个原因，必须有该端口结构的全部配置和初始化。这些端口引脚的配置和模式是依赖于微控制器和ECU的。该端口驱动模块应该完成端口结构的全部配置和初始化，该端口结构是用在DIO驱动模块中的。因此，DIO驱动工作再引脚和端口之上，由端口驱动对它进行配置。端口和端口引脚的配置顺序是由配置工具负责的。端口驱动应该在使用DIO功能之前进行初始化。否则DIO驱动会产生未定义的行为。端口访问的原子性：端口驱动应该通过使用原子指令或者利用OS的中断屏蔽功能来提供对端口的原子访问。1.2.3

22、 存储器驱动存储器驱动层主要包括内部EEPROM驱动、内部Flash驱动、RAM测试等内容。1.2.3.1 EEPROM驱动EEPROM驱动提供读、写、擦除EEPROM的服务。也提供了用于比较EEPROM中数据块和内存中数据块的服务。这些服务是异步的。有两类EEPROM驱动：内部EEPROM驱动外部EEPROM驱动内部EEPROM驱动直接访问微控制器硬件，并且定位在微控制器抽象层。外部EEPROM驱动使用处理程序（handler）或驱动访问外部EEPROM设备。它定位在ECU抽象层。两种类型的驱动的功能需求和功能范围都是相同的。所以API在语义上是相同的。1.2.3.2 flash驱动如果受到

23、底层硬件的支持，闪存驱动提供读、写和擦除闪存的服务，以及设置写/擦除保护的配置接口。闪存驱动提供了一个内置加载器，以加载闪存存取代码到RAM中，并在需要的时候执行写/擦除操作。在ECU应用模式下，闪存驱动只用于闪存EEPROM仿真模块写数据。在应用模式下并不将程序代码写到闪存中。这应该由启动模式处理，超出了AUTOSAR的范围。有两类闪存驱动：内部闪存驱动外部闪存驱动内部闪存的驱动直接存取微控制器硬件，并且定位在微控制器抽象层。外部闪存通常通过微控制器数据/地址总线连接，然后闪存驱动使用总线的处理程序/驱动访问外部闪存设备。外部闪存设备的驱动定位在ECU抽象层。两种类型的驱动的功能需求和功能范

24、围都是相同的。所以API在语义上是相同的。1.2.3.3 RAM测试RAM测试：负责RAM单元（包括用于寄存器的单元）的物理性诊断（非数据检测），不同的诊断方式需要预编译然后更据系统或用户需要实时运行。1.2.4 微控制器驱动微控制器驱动层主要包括看门狗驱动、通用定时器GPT驱动、微控制器单元MCU驱动等内容。1.2.4.1 看门狗驱动看门狗驱动：设定片内看门狗模式以及触发看门狗设备，触发程序由上层系统服务层的看门狗管理器模块进行调用。内部看门狗驱动控制MCU的内部看门狗计时器。它提供触发器功能和模式选择服务。1.2.4.2 通用定时器GPT驱动通用定时器GPT驱动：为定时服务程序提供定时中断

25、。GPT驱动允许产生单触发或持续的计时器通知。这个模块使用通用计时器的硬件计时通道，因此就为操作系统中或者其它基本软件模块（在这类模块中，OS警告服务有过多的开销）中的使用提供了精确的、短期的计时。GPT驱动提供了用于启动和停止硬件计时模块中的功能计时实例（通道）的服务。它能够产生单个超时周期以及重复超时周期。如果必须调用一个通知，那么当所请求的超时周期过期时，用户就能够对它进行配置。可以在运行时启用或禁用通知。不管是从上一个通知发生以来的相对时间消耗，还是到下一个通知之间的剩余时间，都可以进行查询。图8 GPT时序注意，GPT驱动仅产生时间基础，而不服务于时间计数器。这个功能是由另一个模块（

26、ICU驱动）提供的。GPT驱动可以用来唤醒ECU，不管预定义的超时周期是否过期。模式转换服务将GPT驱动在普通操作和睡眠模式之间进行转换。该驱动不提供超时周期，这些超时周期超过了被时钟源、预定标器和计时寄存器所限制的最大值。用户必须对这个进行处理。1.2.4.3 微控制器单元MCU驱动微控制器单元MCU驱动负责微处理器的各项设定，包括复位，初始化，电源管理，唤醒，时钟设定等。MCU驱动提供用于基本微控制器的初始化，下电，复位和其它MCAL软件模块需要的微控制器特定功能的服务。初始化服务提供了灵活性，同时，除了启动代码之外，还提供了应用程序相关的MCU初始化。启动代码是完全特定于MCU的。MCU

27、驱动直接访问微控制器硬件，它位于微控制器抽象层（MCAL）中。MCU驱动的特征：初始化MCU时钟，PLL，时钟预定标器和MCU时钟分布初始化RAM部件激活微控制器节电模式激活微控制器复位另外，还有提供一个服务来从硬件处获得复位的原因。MCU驱动微时钟和RAM初始化提供MCU服务。在MCU配置集中，特定于MCU的时钟（例如，PLL设置）和RAM（例如，段基地址和大小）设置必须被配置。注意：外部设备驱动是属于ECU抽象层而非微控制器抽象层的，但内存映射型外部设备(如外部flash存储器)的驱动是个例外，因为可以直接通过微控制器访问它们。这些外部设备的驱动位于微控制器抽象层。1.3 复杂驱动图9 复

28、杂驱动层示意图复合驱动（如图3-2所示）使用对微控制器的直接访问来实现复合的传感器评估和致动器控制，它所访问的微控制器使用指定的中断和/或复合的微控制器外设（如PCP，TPU），例如：注入控制（injection control）整流管控制（Electric valve control）增量位置检测（Incremental position detection）例子：图10 复杂驱动内容任务：满足处理复合传感器和致动器的特殊功能和时间需求。复杂驱动在实现上高度依赖于C、ECU和应用。1.4 ECU抽象层1.4.1 通信硬件抽象图11 通信硬件抽象层次图通信硬件抽象是从通信控制器的位置和ECU硬

29、件布局中抽象出来的一组模块。对所有的通信系统来说，都需要特定的通信硬件抽象（如：LIN，CAN，MOST，FlexRay）。它提供平等的机制来访问总线通道（如：LIN、CAN、SPI、FlexRay），而不管这些总线通道的位置（在片上或在板上）。例子：一个ECU有一个带有两个内部CAN通道的微控制器，以及一个带有四个CAN控制器的板载ASIC。CAN-ASIC通过SPI与微控制器连接。通信驱动通过总线特殊接口来访问（如CAN接口）。通信硬件抽象在实现上与微控制器无关，而依赖于ECU硬件和外部设备。其上层接口依赖于总线，而与微控制器和ECU硬件无关。通信抽象层主要是LIN接口、CAN接口和CAN

30、收发驱动、FlexRay接口和FlexRay收发驱动构成。图12 通信硬件抽象层和通信驱动层1.4.1.1 LIN接口LIN接口(包括LIN TP)：为上层LIN SM模块和PDU Router模块提供驱动抽象接口，通过下层驱动模块对LIN硬件设备进行控制。功能主要包括：根据上层通信模块切换调度表，执行LIN数据帧的收发，控制设备的唤醒和睡眠，错误处理以及诊断服务。其向下层的软件架构如下图所示。图13 LIN Interface架构LIN接口被设计成硬件无关的。到上层模块（PDU路由器）和下层模块（LIN驱动）的接口被很好地定义。LIN接口可以处理一个以上的LIN驱动。一个LIN驱动能够支持一

31、个以上的通道。这指的是LIN驱动能够处理一个或多个LIN通道。LIN接口负责向上层提供LIN 2.0主要功能有：（1）为每个与ECU连接的LIN总线执行当前选择的调度。（2）当上层请求到来时，切换调度表。（3）从上层接收帧的传送，并传送数据部分作为适当LIN帧中的响应。（4）当相应的响应在适当的帧中接收时，为上层提供帧接收通知。（5）睡眠和唤醒服务（6）错误处理（7）诊断传输层服务1.4.1.2 CAN接口CAN接口：为上层CAN SM模块，CAN NM模块，CAN TP模块以及PDU Router模块和下层CAN控制驱动和CAN收发驱动提供接口。提供了唯一的接口来访问管理CAN硬件设备，为上

32、层服务层抽象了CAN硬件设备的分布和数量。其与下层软件结构关系如下图：图14 CAN Interface下层软件结构CAN接口提供标准化的接口，通过ECU的CAN总线系统来支持通信。其API与专用CAN控制器及其通过CAN驱动层的访问无关。CAN接口能够通过统一的接口访问一个或多个CAN驱动。CAN接口仅能用于CAN通信，并且是为操作一个或多个底层CAN驱动而专门设计。涵盖不同CAN硬件单元的几个CAN驱动模块由一个在CAN驱动规范中指定的通用接口来表示。CAN之外（也就是LIN）的其他协议不支持。1.4.1.3 CAN收发器驱动CAN收发器驱动负责对CAN收发器硬件进行控制驱动，为上层CAN

33、接口模块提供CAN收发器硬件抽象接口。CAN收发器驱动负责处理ECU上的CAN收发器，依据的是与整个ECU当前状态相关的总线专用NM的状态。CAN收发设备驱动的目标：CAN收发设备驱动抽象使用CAN收发设备硬件芯片。它向更高层提供硬件无关接口。它也可以通过MCAL层的API从ECU设计中抽象出来，访问CAN收发设备硬件。 CAN收发设备硬件必须提供功能和接口，以映射到AUTOSAR CAN收发设备驱动的运行模式模型上。下层驱动（SPI和DIO）使用的API必须同步。不支持同步行为的下层驱动的实现不能与CAN收发设备驱动一起使用。1.4.1.4 外部CAN驱动外部CAN驱动（AUTOAR范围之外

34、）：为上层的CAN接口模块提供外部CAN硬件抽象接口。1.4.1.5 FlexRay接口FlexRay接口为上层FlexRay SM模块，FlexRay NM模块，FlexRay TP模块以及PDU Router模块提供驱动抽象接口，通过下层驱动模块对FlexRay硬件设备进行控制。提供的功能包括：初始化，收发数据，设定FlexRay运行模式，状态信息捕获以及各种定时。FlexRay接口提供一种标准化的接口以访问FlexRay通信系统/硬件。FlexRay接口必须与所使用的专用FlexRay CC及其通过FlexRay驱动的访问无关。FlexRay接口提供通过统一接口的对一个或几个FlexRa

35、y驱动的访问。FlexRay接口的主要任务有：（1）为上层提供到FlexRay通信系统的抽象接口。（2）FlexRay接口通过一个或多个硬件专用驱动模块来访问FlexRay硬件，而不是直接访问。（3）为了访问FlexRay通信控制器，FlexRay接口使用一个或多个FlexRay驱动模块。（4）为了访问FlexRay收发器，FlexRay接口使用一个或多个FlexRay收发器驱动模块。（5）FlexRay接口可执行代码与FlexRay通信控制器和FlexRay收发器完全不相关。（6）FlexRay接口允许代码模块的对象代码提交，遵循“one-fits-all”原则。（7）FlexRay接口提供

36、给上层AUTOSAR BSW模块的功能如下：A初始化B配置/重配置C数据传送（发送和接收）D启动/停止/中断通信EFlexRay专用服务F设置运行模式G获取状态信息H各种计时器功能1.4.1.6 FlexRay收发器驱动FlexRay收发器驱动负责对FlexRay收发器硬件进行控制驱动，为上层FlexRay 接口模块提供FlexRay收发器硬件抽象接口。FlexRay收发器驱动负责处理ECU上的FlexRay收发器，其依据是总线专用NM的状态。1.4.1.7 外部FlexRay驱动外部FlexRay驱动（AUTOSAR范围之外）：为上层的FlexRay接口模块提供外部FlexRay硬件抽象接口

37、。1.4.2 I/O硬件抽象图15 I/O硬件抽象层次图I/O抽象层提供微控制器外设的硬件输入输出抽象接口，通过下层驱动模块对相应硬件外设进行控制，包括，微控制器通用I/O，ADC，PWM，ICU等。上层的汽车电子应用和组件可以通过该模块提供的I/O信号访问接口实现不同I/O设备的访问。图16 I/O硬件抽象层和I/O驱动层这主要通过把ECU信号映射到IO抽象端口上来实现。模块IO硬件抽象要提供用于初始化整个IO硬件抽象的模块。下图显示了IO硬件抽象模块。它位于MCAL驱动之上。就是说IO硬件抽象模块要调用驱动API来管理片上设备。MCAL驱动的配置依赖于将由IO硬件抽象模块提供的ECU信号的

38、质量。例如，当引脚层发生相关的改变时（上升沿、下降沿），需要进行通知。系统设计者不得不配置MCAL驱动，以允许对给定信号进行通知。通知来自于驱动，并在IO硬件抽象模块中进行处理。图171.4.3 存储硬件抽象图18 存储硬件抽象层次图存储硬件抽象是从外围存储设备位置（片上或板上）和ECU硬件布局中抽象出来的一组模块。存储硬件抽象的任务是提供相等的机制访问内部（片上的）和外部（板上的）的存储设备以及各种存储硬件（EEPROM，Flash）。例如：可以通过相等的机制访问片上EEPROM和外部EEPROM设备。通过仿真一个EEPROM接口和Flash硬件单元，可以经过存储器抽象接口访问两种类型的硬件

39、。图19 存储器硬件抽象层和存储器驱动层存储器硬件抽象层主要是内存抽象接口、EEPROM抽象、Flash EEPROM仿真。1.4.3.1 EEPROM抽象EEPROM抽象层（EA）扩展EEPROM驱动，提供片内EEPROM的访问接口，抽象了EEPROM的地址以及数量，向上层提供线性地址空间上的虚拟分段和“实际上无限制的”擦除/写循环。除此之外，它还应该提供与EEPROM驱动相同的功能。1.4.3.2 Flash EEPROM仿真闪存EEPROM仿真（FEE）按照闪存技术仿真EEPROM抽象层的行为，利用Flash来仿真EEPROM的数据存储，为上层的内存抽象接口模块提供数据的虚拟寻址。所以它

40、与EEPROM抽象层有相同的功能和API，并且给出基于下层闪存驱动和闪存设备的相似配置。1.4.3.3 内存抽象接口内存抽象接口（MemIf）对于不同内存设备提供抽象内存接口。上层的NVRAM管理器模块可以通过抽象内存接口来访问不同的抽象内存模块甚至是供应商的特殊内存驱动（FEE或EA模块），如下图所示。内存抽象接口抽象于下层FEE和EA模块的数目，并向上层提供统一线性地址空间上的虚拟分段。图20 内存抽象接口与上下层的关系1.4.3.4 外部EEPROM驱动外部EEPROM 驱动（AUTOSAR范围之外）：属于ECU抽象层，提供了对片外EEPROM设备的擦除，读，写访问的驱动，以及与RAM数

41、据的比较功能。1.4.3.5 外部flash驱动外部Flash驱动（AUTOSAR范围之外）：属于ECU抽象层，提供了对片外Flash设备的擦除，读，写访问的驱动。1.4.4 板载设备抽象板上设备抽象模块包括除传感器/激励器外的ECU板上设备（如板上系统芯片、外部watchdog等）的驱动程序，它通过微控制器抽象层实现对ECU板上设备的访问。图21 板载设备抽象层次图板载设备抽象层和微控制器驱动层与微控制器设备之间上下层关系：图22板载设备抽象层主要是看门狗接口：针对微控制器的看门狗设备提供了相同的访问机制，抽象了看门狗设备的地址以及数量。1.4.4.2 外部看门狗驱动外部看门狗驱动控制外部硬

42、件看门狗。它提供触发器功能和模式选择服务。它有和内部看门狗驱动一样的功能作用域。如果在一个ECU内使用了多于一个的看门狗设备和看门狗驱动（例如，内部软件看门狗和外部硬件看门狗），该模块就使得看门狗管理程序能够选择合适的看门狗驱动，以及看门狗设备。看门狗驱动接口提供了对下层看门狗驱动的服务的统一访问，比如模式转换和触发。有设备索引选择适当的看门狗设备。看门狗驱动的服务的行为（同步/异步/计时）是受保护的。看门狗驱动接口没有给看门狗驱动增加额外的功能。看门狗驱动接口也没有从看门狗属性中进行抽象，比如toggle或窗口模式，超时周期等，就是说，该驱动接口没有隐藏下层看门狗驱动和看门狗设备的任何特性。

43、1.6 抽象接口实现示例外部设备驱动位于ECU抽象层上，它通过微控制器抽象层的驱动访问外部设备。下面的例子说明了如何通过SPIHandlerDriver访问外部EEPROM。图23 NVRAM管理和看门狗管理与假设的硬件配置上的驱动的相互影响这个实例展示了NVRAM管理器和看门狗管理器与假设的硬件配置上的驱动的相互影响，如上图所示。使ECU硬件拥有一个外部EEPROM（ST16RF42）和通过同样的SPI与微控制器连接的外部看门狗。SPIHandlerDriver控制对SPI硬件的并发访问，并且必须使看门狗访问的优先级高于EEPROM访问。假设微控制器还有个能和外部EEPROM并行使用的内部f

44、lash。EEPROM抽象和Flash EEPROM仿真有在语义上相同的API。内存抽象接口通过下面的方法实现：在运行期间基于设备索引（int/ext）的路由在运行期间基于块索引（如：0x01FF=外部EEPROM）的路由通过带有NVRAM管理器中的函数指针（这种情况下内存抽象接口只存在“虚拟的”）的ROM表在配置时间期间路由。结构描述NVRAM管理器通过内存抽象接口访问驱动，如图23所示。使用设备索引寻址不同的内存设备。接口描述内存抽象接口应该有下面的接口（如：为写函数）：Std_ReturnType MemIf_Write(Uint8DeviceIndex,Uint16BlockNumbe

45、r,Uint8*DataBufferPtr)EEPROM抽象以及Flash EEPROM仿真应该有下面的接口（如：为写函数）：Std_ReturnType Ea_Write(Uint16BlockNumber,Uint8*DataBufferPtr)图24 NVRAM管理通过内存抽象接口访问驱动示意图情形1:只使用一种类型的NV设备, 这是一般的使用情况。在这种情况下，内存抽象被实现为一个忽略DeviceIndex参数的简单宏。下面的例子只列出了写函数：文件 MemIf.h:#include “Ea.h”/*for providing access to the EEPROM abstraction*/#define MemIf_Write(DeviceIndex, BlockNumber, DataBufferPtr) Ea_Write(BlockNumber, DataBufferPtr)File MemIf.c: 不存在结果：在运行时没有额外的代码，NVRAM管理器虚拟地访问EEPROM抽象或直接的访问Flash仿真。情形2: 使用两个或多个不同类型的NV设备，这种情况下使用DeviceIndex来选择