| 编辑推荐: |
本文主要讲解了包含外设详解和AUTOSAR方法、模型、工具和一致性测试。
本文来自于搜狐，由火龙果软件Anna编辑、推荐。 |
|
外设
IO 硬件抽象
IO 硬件抽象是 ECU 抽象层的一部分。IO 硬件抽象模块的目标是使数据通过 RTE 来传 输，而完全不依赖于
ECU 硬件。这就是说软件组件设计者不需要更多的了解信号是如何影 响物理层的。因此，该模块是特定于
ECU 的。
这主要通过把 ECU 信号映射到 IO 抽象端口上来实现。模块 IO 硬件抽象要提供用于初 始化整个
IO 硬件抽象的模块。
下图显示了 IO 硬件抽象模块。它位于 MCAL 驱动之上。就是说 IO 硬件抽象模块要调 用驱动
API 来管理片上设备。MCAL 驱动的配置依赖于将由 IO 硬件抽象模块提供的 ECU 信号的质量。例如，当引脚层发生相关的改变时（上升沿、下降沿），需要进行通知。系统
设计者不得不配置 MCAL 驱动，以允许对给定信号进行通知。通知来自于驱动，并在 IO 硬 件抽象模块中进行处理。
ADC驱动
ADC 驱动初始化并控制微控制器内部的模数转换单元。该驱动包一系列的基本功能 函数。为了能够在某些特殊的应用中进行信号的频率分析（例如，快速傅立叶变换），就需要加强流式存取的功能。
ADC 驱动提供以下服务：
· 信号值结果的访问模式
· 流式访问
通常，ADC 通道的变换请求通过 ADC 通道组来进行控制。通道组可以运行于持续的变 换模式或者单触发变换模式。
变换处理和交互作用：
在同一时刻，ADC 驱动要管理一个以上的被配置成不同变换模式的组。
转换过程：
通常，ADC 通道的转换请求通过 ADC 通道组来进行控制。一个组可以运行于持续的转 换模式或者单触发转换模式。单触发转换模式的触发条件也要被配置和控制。
如果通道运行于不同的模式（例如，在普通操作时采用持续的转换模式，在特定时间点 的特殊转换时使用单触发或者按照命令的转换方式），通道必须被分配给拥有不同操作模式
的多个组。
为了改变组间共享的通道的操作模式，应用程序必须停止任何对包指定通道的组的当 前转换，然后启动包指定通道的新组的转换。
为了让应用程序能够在任何时候执行立即转换，就要定义一个按照命令的转换方式。它必须挂起组转换，然后在按照命令的转换活动完成后重新激活它。
DIO 驱动
DIO 驱动提供基于端口和通道的、对内部通用 I/O 断点的读和写访问。这里的读和写并 不被缓冲。这个驱动的基本行为是同步的。
DIO 驱动提供了用于对下列设施进行读、写的服务：
· DIO 通道（引脚）
· DIO 端口
· DIO 通道组 这些服务的行为是同步的
该模块工作于引脚和端口上，由 PORT 驱动来对它进行配置。
因此，在 DIO 驱动里面就没有对该端口结构进行配置和初始化。
端口驱动模块：很多端口和端口引脚是由端口驱动模块分配给各种功能的，比如：
· 常规 I/O
· ADC
· SPI
· PWM
DIO 驱动抽象了对微控制器硬件引脚的访问。此外，它还能够对这些引脚进行分组。
DIO 驱动提供以下服务：
· 一个一个地修改端口或通道组的输出通道的等级。
· 一个一个地读取端口或通道组的输入和输出通道的等级。
DIO 驱动中的所有读写服务必须是可重入的。理由是：这些 DIO 驱动可以被不同的上层处理程序或驱动程序访问。这些上层模块可以并行的访问驱动。
GPT驱动
GPT 驱动允许产生单触发或持续的计时器通知。这个模块使用通用计时器的硬件计时通道，因此就为操作系统中或者其它基本软件模块（在这类模块中，OS
警告服务有过多的开 销）中的使用提供了精确的、短期的计时。
GPT 驱动提供了用于启动和停止硬件计时模块中的功能计时实例（通道）的服务。它能 够产生单个超时周期以及重复超时周期。如果必须调用一个通知，那么当所请求的超时周期
过期时，用户就能够对它进行配置。可以在运行时启用或禁用通知。
不管是从上一个通知发生以来的相对时间消耗，还是到下一个通知之间的剩余时间，都可以进行查询。
注意，GPT 驱动仅产生时间基础，而不服务于时间计数器。这个功能是由另一个模块 （ICU 驱动）提供的。
GPT 驱动可以用来唤醒 ECU，不管预定义的超时周期是否过期。模式转换服务将 GPT 驱动在普通操作和睡眠模式之间进行转换。
该驱动不提供超时周期，这些超时周期超过了被时钟源、预定标器和计时寄存器所限制 的最大值。用户必须对这个进行处理。
ICU驱动
ICU 驱动控制微控制器的输入捕获单元。
它提供了下列特性：
· 周期性的、低端的、高端的时间测量
· 边缘检测和通知
· 边缘计数
· 边缘时间戳
· 唤醒中断
对于信号边缘检测来说，需要使用捕获比较单元的边缘检测器或外部时间的中断控制器。
对于信号测量来说，需要一个捕获计时器以及至少一个捕获寄存器。ICU 调制 PWM 信号，计算脉冲，测量频率和责任（duty）周期，产生简单的中断以及
唤醒中断。
ICU 驱动提供以下服务：
· 信号边缘通知
· 控制唤醒中断
· 周期信号时间测量
· 边缘时间戳，可用于获取非周期的信号
· 边缘计数
为了保证数据一致性，应该提供可重入的代码。
时间单元节拍为了从寄存器值中获得时间，需要知道振荡器频率、预定标器等等。因为这些设置是在 MCU
模块中或其它模块中产生的，不可能计算这些时间。因此，时间和节拍之间的转换是 由上层负责的。
MCU驱动
MCU驱动提供用于基本微控制器的初始化，下电，复位和其它 MCAL 软件模块需要的微控制器特定功能的服务。初始化服务提供了灵活性，同时，除了启动代码之外，还提供了应用程序相关的
MCU 初始化。启动代码是完全特定于 MCU 的。MCU 驱动直接访问微控制器硬件，它位于微控制器抽象层（MCAL）中。
MCU 驱动的特征：
· 初始化 MCU 时钟，PLL，时钟预定标器和 MCU 时钟分布
· 初始化 RAM 部件
· 激活微控制器节电模式
· 激活微控制器复位
另外，还有提供一个服务来从硬件处获得复位的原因。
MCU 驱动微时钟和 RAM 初始化提供 MCU 服务。在 MCU 配置集中，特定于 MCU的时钟（例如，PLL
设置）和 RAM（例如，段基地址和大小）设置必须被配置。
端口驱动
该模块初始化微控制器的整个端口结构。很多端口和端口引脚可以被分配给不同的功能，比如：
· 通用 I/O
· ADC
· SPI
· SCI
· PWM
由于这个原因，必须对这个端口结构进行总的配置和初始化。这些端口引脚的配置和使 用是依赖于微控制器和
ECU 的。
该模块应该提供用于初始化微控制器的整个端口结构的服务。很多端口和端口引脚可以 被分配给各种不同的功能。由于这个原因，必须有该端口结构的全部配置和初始化。这些端
口引脚的配置和模式是依赖于微控制器和 ECU 的。
该端口驱动模块应该完成端口结构的全部配置和初始化，该端口结构是用在 DIO 驱动 模块中的。因此，DIO
驱动工作再引脚和端口之上，由端口驱动对它进行配置。端口和端口 引脚的配置顺序是由配置工具负责的。
端口驱动应该在使用 DIO 功能之前进行初始化。否则 DIO 驱动会产生未定义的行为。
端口访问的原子性：
端口驱动应该通过使用原子指令或者利用 OS 的中断屏蔽功能来提 供对端口的原子访问。
PWM驱动
每个 PWM 通道都连接到一个属于微控制器的硬件 PWM 上。该驱动提供了初始化和控 制微处理器内部的
PWM 的服务。PWM 模块产生有不同脉冲宽度的脉冲。
SPI处理程序
SPI 总线是一种主从多节点总线系统，主节点设置片选（CS）来选择一个从节点来进 行数据通信。SPI
有一个 4 线的同步串行接口。使用片选线来激活数据通信。
下列 SPI 模块提供基于通道的对 SPI 总线上的不同设备的读、写和传输访问。SPI通道代表数据元素（8
到 16 比特）。这些通道可能是顺序组合的，不能够被中断。通道有一个静态配置定义的波特率、片选等等。SPI
设备通常由所使用的 SPI 硬件单元和相关的片选线 来标识。这个模块能够作为 SPI 主节点来使用。
这个软件模块的功能范围应该是可静态配置的，以尽可能多的适应每个 ECU 的时间需 要。那就是说，比如同步的、异步的、或者两者都有的
SPI 访问都可以存在于 ECU。因此， 两个 SPI 驱动可以存在，但仅有一个处理接口。
SPI 处理程序/驱动提供了一些服务来对通过 SPI 总线连接的设备进行读写。它提供了 所需的机制来配置片上
SPI 外设。
单片式的 SPI 处理程序/驱动包处理和驱动功能。它的主要目标是充分利用每个微控 制器的特性，使得依赖于静态配置的实现最优化，以尽可能多的适应
ECU 的需要。
看门狗接口
内部看门狗驱动控制 MCU 的内部看门狗计时器。它提供触发器功能和模式选择服务。
外部看门狗驱动控制外部硬件看门狗。它提供触发器功能和模式选择服务。它有和内部 看门狗驱动一样的功能作用域。
如果在一个 ECU 内使用了多于一个的看门狗设备和看门狗驱动（例如，内部软件看门 狗和外部硬件看门狗），该模块就使得看门狗管理程序能够选择合适的看门狗驱动，以及看
门狗设备。
看门狗驱动接口提供了对下层看门狗驱动的服务的统一访问，比如模式转换和触发。有 设备索引选择适当的看门狗设备。看门狗驱动的服务的行为（同步/异步/计时）是受保护的。
看门狗驱动接口没有给看门狗驱动增加额外的功能。看门狗驱动接口也没有从看门狗属性中进行抽象，比如 toggle
或窗口模式，超时周期等，就是说，该驱动接口没有隐藏下层看门狗驱动和看门狗设备的任何特性。
AUTOSAR方法、模型、工具和一致性测试
AUTOSAR方法
AUTOSAR 在系统开发的某些步骤需要通用的技术方法。这一方法就叫“AUTOSAR 方 法”。“AUTOSAR
方法”既不是完整的过程描述也不是商业模型，这个方法中并没有定义“角 色”和“责任”之类的东西，而且也不规定要执行那些活动。AUTOSAR
方法仅仅是一个“工作 产品流”（work-product flow），定义“工作产品流”中活动的相互依赖性。
AUTOSAR 方法并不定义整体的时间线，也并不定义迭代怎样和何时执行。例如在系 统设计中，同样的行为（即系统配置行为）会在不同的精确度上重复执行。第一个“粗糙”配
置和最后一个“精确”配置依赖于实际配置甚至是 ECU 的实现。
上图给出了运用 AUTOSAR 方法描述 ECU 从设计到构建、集成的过程。
1.首先要定义 System Configuration Input，选择软、硬件组件，标识系统总体限制，
这是系统设计或者体系的任务。AUTOSAR 倾向于通过信息交换格式（软件组件、 ECU 资源、系统限制）和模板来减少这些初始系统设计决定的正式描述。所以定
义 System Configuration Input 就意味着填写和编辑适当的模板。是从头填写模板
还是重用模板（可能也需要一些改动）取决于用例。基本上 AUTOSAR 方法允许 对模板的高度重用。
2. 活动 Configure System 主要是将软件组件映射到关于资源和计时要求的 ECU
上。
3. Configure System 的输出是 System Configuration Deion。这一描述包括所
有系统信息（如总线映射、拓扑等）和关于软件组件定位到哪个 ECU 的映射。
4. 活动 Extract ECU-Specific Information 从 System Configuration
Deion 中提取特定 ECU 所需的信息。
5. 然后输出到 ECU Extract of System Configuration。
6. 活动 Configure ECU 为实现添加了所有必需的信息，如任务调度、必需的 BSW（基
础软件）模块、BSW 的配置、任务中可运行实体的赋值等。
7. 活动 Configure ECU 的结果将输出给 ECU Configuration Deion，它负责收
集所有关于特定 ECU 的局部信息。通过这些信息可以构建该特定 ECU 的可执行软件。
8. 在最后一步中，活动 Generate Executable 根据从 ECU Configuration
Deion 中得到的信息生成可执行软件。这一步通常涉及生成代码（如为 RTE 和 BSW 生 成代码）、编译代码（编译生长的代码或编译软件组件的源代码）、将所有编译后的代码连接成为可执行软件。
9. 得到可执行 ECU 软件。
在这些简短介绍的 AUTOSAR 方法过程中，同时还需要将软件组件集成为整个的系统， 比如生成组件
API，实现组件功能等。虽然这些没有在上图中表现出来，不过软件组件的实 现或多或少与 ECU 的配置无关。
AUTOSAR起源
1.起源
AUTOSAR 允许通过对嵌入式控制器和对应软件执行单元组成的分布式系统的各个方面进行精确的和正式的描述，以建立一个非常灵活却又稳定而可靠的软件工程生命周期。
这个描述的覆盖范围从高层的软件组件的接口要求，到底层的特定总线消息的字节限 制。由 AUTOSAR
中的不同工作包决定需要从各种描述中获得的信息。而这些描述就是 AUTOSAR 模型。
AUTOSAR 模型属于 UML2.0 的一个子集，是 UML2.0 元模型的简化。因为 UML2
中 高度模块化的结构和对类、属性、关联重定义的过度使用，有时很难在用一两副图展现某个 特定方面的同时又保持清晰的可读性。所以，这里简化了
UML2.0 元模型，只包部分元素。
2.术语
3.原模型体系
完整的 AUTOSAR 模板元模型体系共有五层：
M0层：AUTOSAR对象
这是对 AUTOSAR 系统的实现：真实的 ECU 执行包雨刷控制软件的软件映像。
M1层：AUTOSAR模型
这一元层的模型是由 AUTOSAR 终端用户（汽车工程师）构建的。由他们定义名为“雨 刷”的软件组件和一系列连接其它软件组件的接口等等。在这一层
AUTOSAR 系统被细分 成可重用的组件和特定实例。
M2层：AUTOSAR元模型
这一层定义之后将被 AUTOSAR 终端用户使用的“词汇表”，比如，这层定义了在 AUTOSAR
中有名为“软件组件”的实体和另一个名为“端口”的实体。这些实体之间的 联系和语义都属于整个模型的一部分。
M3层：AUTOSAR 模板的 UML profile
M2 层的模板是由 M3 层定义的元模型构建的。正如之前讨论过的，这是 UML 加上一 个特定的
UML profile，以更好的支持模板建模工作。严格意义上 M2 层上的模板仍然是 UML 的实例，但同时也采用了模板
profile
M4层：元实施对象
为了概念上的完整性，OMG 将 MOF 放在最后一层元层上。因为 MOF 被定义为是反 射式的，所以不再需要进一步的元层。
AUTOSAR起源
“AUTOSAR 创作工具”是指所有支持解释、修改、创建用于描述系统的 AUTOSAR XML 描述（AUTOSAR
模型的 XML 表示）的工具。这些模型由以下模板产生：
1. 软件组件模板
2. ECU 资源模板
3. AUTOSAR 系统模板
AUTOSAR 创作工具包几个重要的方面，如下图所示：
创作工具的特征定义：
“创作工具的特征定义”建议逐步实现 AUTOSAR 整体概念中关于交换描述的部分， 即软件组件模板、ECU
资源模板、系统模板。在第一次实现的基础上，定义 AUTOSAR 模板子集的 AUTOSAR 创作工具。
创作工具的协同工作：
“创作工具的协同工作”着重于那些在不同工具间交换 AUTOSAR 模型时可能会出现 的问题。本文档首先描述一些数据交换的基本概念，然后简单勾勒出解决这些问题的策略。
行为模型的交互：
“行为模型的交互”列出了 AUTOSAR 中行为模型的用例。并标识出与行为模型有关 的部分 AUTOSAR
元模型。
图形符号：
“图形符号”为 AUTOSAR 创作工具定义了 AUTOSAR 图形符号。例如，文档为图形 建模
CompositionTypes 提供了详尽的图式。这些图形符号应作为实现 AUTOSAR 创作 工具的指南。
一致性测试
AUTOSAR 一致性测试的目的是为了验证产品是否符合 AUTOSAR 规范。这些产 品需要在互操作性、重用/移植性、可扩展性上证明符合
AUTOSAR 标准。 因为 AUTOSAR 是一个开放标准，所以所有最终规范都是标准的一部分。
本文档关注为证明特定产品符合 AUTOSAR 标准所必需的几条相关路径。测试过 程的复杂度应尽可能的低，但具体应根据供应商和客户之间的关系来确定最合适的测试
方案。 一致性测试中的角色有：
1.AUTOSAR（维护标准，监控 AUTOSAR 规范的使用）
2.Conformance Test Agency（分为第一方 CTA 和第三方 CTA，主要任务
是提供测试包，执行测试，提供支持和证明服务）
3. Product Supplier（开发和测试产品）。
结束语
AUTOSAR 的提出对于汽车电子软件的发展，具有很大的影响，可从以下几个方面看 出：
对于 OEM 的影响
AUTOSAR 的提出对于 OEM 来说最为有利。使得他们对有软件采购和控制有了更灵活 和更大的权利，软件的提供商会逐步增多，使得他们又更多的选择；同时，软件系统的开放
化，使得软件的质量监督也会相应提高。这些无疑对他们百益而无害。
对于部件提供商的影响
对于部件提供的影响须从两个角度来分析。从技术角度而言，软件技术的发展对于部件 提供商带来的效率提高是毋庸置疑的。增强了软件的移植性，可利用率，可维护性等等，对
于软件开发者带来的好处是巨大的。
从商业角度考虑，公开软件标准的提出对于所有软件提供商都是有益的。但同时，理论 上讲，以前一些软件提供商的垄断模式随着这一开放式系统的提出而打破。新的市场将是开
放的，竞争与机遇共存。传统部件提供商由于其基础积累仍在市场上处于优势，但新的提供 商相对于以前将有更多的机会。
对于芯片提供商的影响
对于芯片提供商的影响是共同的，主要是提供一些支持工作。由于基础软件的开发仍需 要芯片提供商的大力支持，因此芯片提供将不余气力的对这一标准提供支持。尽管属于非核
心业务，但如果彻底放弃支持，市场份额或许会受到一些影响。 |
