静态配置定义的波特率、片选等等。SPI设备通常由所使用的SPI硬件单元和相关的片选线来标识。这个模块能够作为SPI主节点来使用。
这个软件模块的功能范围应该是可静态配置的，以尽可能多的适应每个ECU的时间需要。那就是说，比如同步的、异步的、或者两者都有的SPI访问都可以存在于ECU。因此，两个SPI驱动可以存在，但仅有一个处理接口。
SPI处理程序/驱动提供了一些服务来对通过SPI总线连接的设备进行读写。它提供了所需的机制来配置片上SPI外设。
单片式的SPI处理程序/驱动包含处理和驱动功能。它的主要目标是充分利用每个微控制器的特性，使得依赖于静态配置的实现最优化，以尽可能多的适应ECU的需要。 3.10 看门狗接口
内部看门狗驱动控制MCU的内部看门狗计时器。它提供触发器功能和模式选择服务。 外部看门狗驱动
外部看门狗驱动控制外部硬件看门狗。它提供触发器功能和模式选择服务。它有和内部看门狗驱动一样的功能作用域。
如果在一个ECU内使用了多于一个的看门狗设备和看门狗驱动（例如，内部软件看门狗和外部硬件看门狗），该模块就使得看门狗管理程序能够选择合适的看门狗驱动，以及看门狗设备。
看门狗驱动接口提供了对下层看门狗驱动的服务的统一访问，比如模式转换和触发。有设备索引选择适当的看门狗设备。看门狗驱动的服务的行为（同步/异步/计时）是受保护的。 看门狗驱动接口没有给看门狗驱动增加额外的功能。看门狗驱动接口也没有从看门狗属性中进行抽象，比如toggle或窗口模式，超时周期等，就是说，该驱动接口没有隐藏下层看门狗驱动和看门狗设备的任何特性。 4
AUTOSAR方法、模型、工具和一致性测试
4.1 AUTOSAR方法
AUTOSAR在系统开发的某些步骤需要通用的技术方法。这一方法就叫“AUTOSAR方法”。“AUTOSAR方法”既不是完整的过程描述也不是商业模型，这个方法中并没有定义“角色”和“责任”之类的东西，而且也不规定要执行那些活动。AUTOSAR方法仅仅是一个“工作产品流”（work-product flow），定义“工作产品流”中活动的相互依赖性。 AUTOSAR方法并不定义整体的时间线，也并不定义迭代怎样和何时执行。例如在系统设计中，同样的行为（即系统配置行为）会在不同的精确度上重复执行。第一个“粗糙”配置和最后一个“精确”配置依赖于实际配置甚至是ECU的实现。
AUTOSAR方法概述
上图给出了运用AUTOSAR方法描述ECU从设计到构建、集成的过程。
1. 首先要定义System Configuration Input，选择软、硬件组件，标识系统总体限制，
这是系统设计或者体系的任务。AUTOSAR倾向于通过信息交换格式（软件组件、ECU资源、系统限制）和模板来减少这些初始系统设计决定的正式描述。所以定义System Configuration Input就意味着填写和编辑适当的模板。是从头填写模板还是重用模板（可能也需要一些改动）取决于用例。基本上AUTOSAR方法允许对模板的高度重用。 2. 活动Configure System主要是将软件组件映射到关于资源和计时要求的ECU上。 3. Configure System的输出是System Configuration Description。这一描述包括所
有系统信息（如总线映射、拓扑等）和关于软件组件定位到哪个ECU的映射。 4. 活动Extract ECU-Specific Information从System Configuration Description中提
取特定ECU所需的信息。 5. 然后输出到ECU Extract of System Configuration。
6. 活动Configure ECU为实现添加了所有必需的信息，如任务调度、必需的BSW（基
础软件）模块、BSW的配置、任务中可运行实体的赋值等。 7. 活动Configure ECU的结果将输出给ECU Configuration Description，它负责收
集所有关于特定ECU的局部信息。通过这些信息可以构建该特定ECU的可执行软件。 8. 在最后一步中，活动Generate Executable根据从ECU Configuration Description
中得到的信息生成可执行软件。这一步通常涉及生成代码（如为RTE和BSW生成代码）、编译代码（编译生长的代码或编译软件组件的源代码）、将所有编译后的代码连接成为可执行软件。 9. 得到可执行ECU软件。
在这些简短介绍的AUTOSAR方法过程中，同时还需要将软件组件集成为整个的系统，比如生成组件API，实现组件功能等。虽然这些没有在上图中表现出来，不过软件组件的实现或多或少与ECU的配置无关。 4.2 AUTOSAR模型 4.2.1 起源
AUTOSAR允许通过对嵌入式控制器和对应软件执行单元组成的分布式系统的各个方
面进行精确的和正式的描述，以建立一个非常灵活却又稳定而可靠的软件工程生命周期。 这个描述的覆盖范围从高层的软件组件的接口要求，到底层的特定总线消息的字节限制。由AUTOSAR中的不同工作包决定需要从各种描述中获得的信息。而这些描述就是AUTOSAR模型。
AUTOSAR模型属于UML2.0的一个子集，是UML2.0元模型的简化。因为UML2中高度模块化的结构和对类、属性、关联重定义的过度使用，有时很难在用一两副图展现某个特定方面的同时又保持清晰的可读性。所以，这里简化了UML2.0元模型，只包含部分元素。 4.2.2 术语
名词 AUTOSAR元模型 解释 AUTOSAR元模型是一种用来定义描述AUTOSAR系统的语言的UML2.0模型。AUTOSAR元模型是模板（在AUTOSAR中，模板定义了如软件组件和ECU之类的结构来创建AUTOSAR软、硬件系统）的图形化表示。用UML2.0的类图来描述元模型的属性和相互关联。 AUTOSAR模型是AUTOSAR元模型的实例。AUTOSAR模型所包含的信息可以是任何能用AUTOSAR元模型表示的内容。AUTOSAR模型既可以作为文件存储在文件系统中，也可以是一些软件工具所需的XML流、数据库或内存。 元数据包括和数据有关的信息，如创建人、版本、访问权限、时间戳等。 模型和其元模型分别处于不同的元层。标准的元层体系是所谓的四层元模型体系，包含四个元层M0、M1、M2、M3，在M0级的实体用M2实体的方式表示，M1用M2实体表示，等等。 如果元模型可以用自身实体来描述，那么它就可以称为是反射式的。反射式元模型用于终结元模型体系。如，在OMG四层元模型体系中，M3级的元模型就是反射式的。 Profile可以用来扩展UML规范定义的实体集，以适应某个特定领域。在profile中定义的新元类称为版类（stereotype）。一般通过增加语义和限制来扩展现有的元类。 AUTOSAR模型 元数据 元层 反射式元模型 UML Profile 4.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：元对象设施（meta object facility）
为了概念上的完整性，OMG将MOF放在最后一层元层上。因为MOF被定义为是反射式的，所以不再需要进一步的元层。 4.3 AUTOSAR工具
“AUTOSAR创作工具”是指所有支持解释、修改、创建用于描述系统的AUTOSAR XML描述（AUTOSAR模型的XML表示）的工具。这些模型由以下模板产生： 1. 软件组件模板， 2. ECU资源模板， 3. AUTOSAR系统模板。
AUTOSAR创作工具包含几个重要的方面，如下图所示。
AUTOSAR创作工具
A 创作工具的特征定义
“创作工具的特征定义”建议逐步实现AUTOSAR整体概念中关于交换描述的部分，即软件组件模板、ECU资源模板、系统模板。在第一次实现的基础上，定义AUTOSAR模板子集的AUTOSAR创作工具。
B 创作工具的协同工作
“创作工具的协同工作”着重于那些在不同工具间交换AUTOSAR模型时可能会出现的问题。本文档首先描述一些数据交换的基本概念，然后简单勾勒出解决这些问题的策略。
C 行为模型的交互
“行为模型的交互”列出了AUTOSAR中行为模型的用例。并标识出与行为模型有关的部分AUTOSAR元模型。 D 图形符号
“图形符号”为AUTOSAR创作工具定义了AUTOSAR图形符号。例如，文档为图形建模CompositionTypes提供了详尽的图式。这些图形符号应作为实现AUTOSAR创作工具的指南。 4.4 一致性测试
AUTOSAR一致性测试的目的是为了验证产品是否符合AUTOSAR规范。这些产品需要在互操作性、重用/移植性、可扩展性上证明符合AUTOSAR标准。
因为AUTOSAR是一个开放标准，所以所有最终规范都是标准的一部分。 本文档关注为证明特定产品符合AUTOSAR标准所必需的几条相关路径。测试过程的复杂度应尽可能的低，但具体应根据供应商和客户之间的关系来确定最合适的测试方案。
一致性测试中的角色有： （1） （2） （3）
AUTOSAR（维护标准，监控AUTOSAR规范的使用），
Conformance Test Agency（分为第一方CTA和第三方CTA，主要任务是提供测试包，执行测试，提供支持和证明服务）， Product Supplier（开发和测试产品）。
AUTOSAR一致性测试路径
5
总结
AUTOSAR的提出对于汽车电子软件的发展，具有很大的影响，可从以下几个方面看出：
（1）
对于OEM 的影响
AUTOSAR的提出对于OEM来说最为有利。使得他们对有软件采购和控制有了更灵活和更大的权利，软件的提供商会逐步增多，使得他们又更多的选择；同时，软件系统的开放化，使得软件的质量监督也会相应提高。这些无疑对他们百益而无害。
（2）
对于部件提供商的影响
对于部件提供的影响须从两个角度来分析。从技术角度而言，软件技术的发展对于部件提供商带来的效率提高是毋庸置疑的。增强了软件的移植性，可利用率，可维护性等等，对于软件开发者带来的好处是巨大的。
从商业角度考虑，公开软件标准的提出对于所有软件提供商都是有益的。但同时，理论上讲，以前一些软件提供商的垄断模式随着这一开放式系统的提出而打破。新的市场将是开放的，竞争与机遇共存。传统部件提供商由于其基础积累仍在市场上处于优势，但新的提供商相对于以前将有更多的机会。
（3）
对于芯片提供商的影响
对于芯片提供商的影响是共同的，主要是提供一些支持工作。由于基础软件的开发仍需要芯片提供商的大力支持，因此芯片提供将不余气力的对这一标准提供支持。尽管属于非核心业务，但如果彻底放弃支持，市场份额或许会受到一些影响。