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的配置无关。
2. AUTOSAR模型
2.1. 起源
AUTOSAR允许通过对嵌入式控制器和对应软件执行单元组成的分布式系统的各个方面进行精确的和正式的描述，以建立一个非常灵活却又稳定而可靠的软件工程生命周期。
这个描述的覆盖范围从高层的软件组件的接口要求，到底层的特定总线消息的字节限制。由AUTOSAR中的不同工作包决定需要从各种描述中获得的信息。而这些描述就是AUTOSAR模型。
AUTOSAR模型属于UML2.0的一个子集，是UML2.0元模型的简化。因为UML2中高度模块化的结构和对类、属性、关联重定义的过度使用，有时很难在用一两副图展现某个特定方面的同时又保持清晰的可读性。所以，这里简化了UML2.0元模型，只包含部分元素。
2.2. 术语
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被定义为是反射式的，所以不再需要进一步的元层。
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. 一致性测试
AUTOSAR一致性测试的目的是为了验证产品是否符合AUTOSAR规范。这些产品需要在互操作性、重用/移植性、可扩展性上证明符合AUTOSAR标准。
因为AUTOSAR是一个开放标准，所以所有最终规范都是标准的一部分。
本文档关注为证明特定产品符合AUTOSAR标准所必需的几条相关路径。测试过程的复杂度应尽可能的低，但具体应根据供应商和客户之间的关系来确定最合适的测试方案。
一致性测试中的角色有：
（1） AUTOSAR（维护标准，监控AUTOSAR规范的使用），
（2） Conformance Test Agency（分为第一方CTA和第三方CTA，主要任务是提供测试包，执行测试，提供支持和证明服务），
（3） Product Supplier（开发和测试产品）。
AUTOSAR一致性测试路径
