随着汽车电子系统的复杂性不断增长，软件代码量也急速上升，为了解决硬件平台更换后导致的底层软件变化，进而导致上层软件也需要重写的问题，AUTOSAR得到了越来越广泛的应用。

AUTOSAR的软件架构分层非常的严格、细致，所以AUTOSAR系统更加的复杂，系统越复杂，开发难度也越大。这时就需要有一种对开发过程、开发步骤的说明指导，这就需要用到AUTOSAR的方法论。

1.什么是AUTOSAR的方法论？

方法论存在于我们生活和工作的各个方面，它是指人们用什么样的方法处理某个特定的问题，简单的说方法论就是要告诉你遇到了某个问题时，该“怎么办”？

比如我们要做一道菜，做这个菜的方法论就是告诉你做个菜要分几步，每一步要怎么做？比如如何洗菜、如何切菜、如何炒菜、如何调味等等，直到最终完成。

再比如生产1个汽车零部件，生产的方法论就是告诉你要分几道工序，每个工序怎么做？比如线路板如何贴片、软件如何烧录、结构件如何装配、功能如何校验、标签如何粘贴等等，相当于操作说明书，流水线越长，步骤越多，这个操作说明就越重要。

生产过程中的步骤往往比较清晰，容易区分。但是研发过程，尤其是AUTOSAR的软件开发，由于架构比较庞大和复杂，软件模块相互交织、包含抽象的事情又太多，工作边界难以划定。

而AUTOSAR的方法论就是把汽车软件的开发过程也看成是一种流水线，针对这种特殊的流水线，也进行了详细的切割、划分，按步骤、角色、分工制定出一种通用的研发方法，每个工程师通常都只是负责整个开发过程中的一环，例如整车架构师、app算法工程师、底层架构工程师、底层软件开发工程师等等。有了方法论，各个工程师只要按照AUTOSAR的方法论开发，就可以做出符合AUTOSAR规范的产品。

2.AUTOSAR方法论的作用

AUTOSAR的方法论聚合了AUTOSAR的各种元素，展示了如何将它们聚集在一起来开发一个完整的系统。

AUTOSAR方法论不仅对开发工程师有指导作用，它对项目组织的管理、工具的设计都有指导作用。

2.1组织

AUTOSAR软件是模块化的分层架构，在具体的项目中，可以根据不同的模块和不同的软件层建立多种项目组织，不同的组织间需要直到如何分工合作。

而AUTOSAR的方法论是以模块化的格式建模，这样不同的项目组织可以针对所需的模块进行定制，并将方法组合到它们自己的内部开发流程中，同时确定它们与其他项目组织交互的点，也就是接口。

比如OEM与Tier1(一级供应商)的接口，Tier1与Tier2（二级供应商）的接口，Tier1内部组织之间的接口等等。

2.2工程师

各个项目组织成立后，就会按软件层次、模块、流程分配不同的工程师角色，各个工程师必须根据角色准确的识别出自己的详细工作内容。

方法论可以让各种角色的工程师快速找到与他们的特定需求相关的AUTOSAR信息。

2.3工具供应商

由于AUTOSAR系统非常复杂，几乎无法通过手写代码完成，所以实际的开发过程中必须要用到各种工具链配置和生成，AUTOSAR的方法论在所有的AUTOSAR成员间提供了一种共同语言以及对工具应该支持哪些功能的共同期望，给工具的供应商提供了指导。

3.AUTOSAR的工作流程

AUTOSAR采用了自顶向下的设计方法，‌它强调从系统的整体出发，‌首先对最高层次中的问题进行定义、‌设计、‌编程和测试，‌然后将未解决的问题作为子任务放到下一层次中去解决，逐步求精。

根据自顶向下的设计原则，其开发顺序是OEM先进行整车的功能定义，分析整车需要哪些功能、整车有多少个ECU、每个ECU要实现哪些功能、ECU内部如何实现等等，AUTOSAR把这些过程都做了明确的划分和完整的标准定义。

每项开发内容分几步、每一步都要做什么、需要什么输入条件、完成后会输出什么工作产品、格式、接口等都做了标准化的规定,同时每一步还会有相关的测试和验证。

ECU的软件集成过程

AUTOSAR方法论将开发内容分为5个开发领域：虚拟功能总线VFB、系统System、软件组件SWC、基础软件BSW和ECU。

方法论包含了系统开发中从VFB到ECU可执行文件生成过程中的主要步骤。

3.1抽象系统开发

AUTOSAR系统的开发主要分为三步，分别由多种活动组成。第一步侧重于开发一个抽象的系统，然后描述VFB的开发，最后是进一步细化和开发系统的活动。

整个工作流从一个可选的活动开始。在这个活动中，抽象系统描述是预先开发出来的，它从一个功能或抽象的视图（功能体系结构）来表示整个系统。一方面，这个抽象的系统描述可能包含与VFB相关的部分。这些信息可以作为以后开发VFB的输入，并可以建立这两个视图之间的映射。

另一方面，抽象系统描述可能包含关于拓扑结构和到ECU的映射的信息，这是开发具体系统描述的基础。

系统的抽象视图（顶部）和VFB视图的软件映射（底部）

抽象系统的开发活动可被划分为以下的几个子活动和任务：

数据模型开发、组件模型开发、VFB定时开发、定义VFB顶级、定义VFB组件约束、

设计系统、在VFB级集成非AUTOSAR系统。

此外，AUTOSAR规定了一种新的文件格式：.arxml，这个文件格式固定，便于解析，可以由DaVinci等AUTOSAR配置软件自动生成。

3.2虚拟功能总线VFB开发

AUTOSAR系统是基于虚拟功能总线（VFB）的定义开发的。VFB是一种抽象的通信机制，它允许软件组件进行交互，VFB独立于任何所使用的ECU和网络。

如果工作流省略了可选的第一步抽象系统活动，则AUTOSAR系统的开发可以直接从整体VFB系统的定义开始。VFB是软件组件之间通信的抽象。它提供了系统所包含的所有软件组件的专用视图，独立于任何ECU和网络。

VFB视图

通过定义ECUs和网络的拓扑结构，并部署软件组件，VFB被细化为一个系统。此外，还导出了连接分布式特性所需的通信矩阵。作为通信开发的一部分，可以指定一种自定义转换技术，用于在ECU间通信的情况下转换数据，这个转换规范是实现基础软件模块的基础。

很多人知道RTE，但不知道VFB，其实它俩有着紧密的关系。VFB是一种抽象的通信机制，用于软件组件之间的通信，而RTE是VFB的具体实现，负责管理和执行通信机制；VFB关注通信机制的抽象和标准化，而RTE则涉及具体的实现细节和基础设施服务。

系统范围

VFB开发活动可分为以下几个子活动：

组件模型开发、VFB定时开发、在VFB级集成非AUTOSAR系统、定义VFB安全信息。

3.3系统与子系统

开发主要分为两个阶段，第1个阶段通常是主机厂OEM定义整个系统，而第2个阶段就是其他供应商根据整个系统同时定义子系统。在这种情况下，OEM会移交系统提取文件，它展示了整个系统的子系统，这些子系统包含子系统VFB，它们是整个VFB的一部分。

整个系统定义了主要的公共ECU和拓扑，子系统通过在系统中添加私有ECU和网络来提供子系统的设计。

主机厂交付的系统提取文件中的软件组件结构可以被接收方转换为每个ECU不同的结构（ECU系统描述）。在这种情况下，主机厂的系统提取文件可以认为是需求，由一个或多个ECU系统描述表示的接收组织的子系统可以视为解决方案，它必须满足交付的需求。

系统提取物和ECU系统描述的范围

从上图可以看出，系统提取文件可能包含不同的ECU，而ECU系统描述只针对某个ECU。

在系统设计完成后，提取与特定ECU相关的部分，生成每个ECU的可交付物，即所谓的ECU提取文件。与之前对系统或ECU的描述相比，ECU提取文件是完全分解的，只包含原子软件组件，单个ECU会得到其需要的信息，不需要的信息就过滤掉。ECU通过这些信息就能搭建起来自己的软件，所以它是ECU配置的基础。

系统开发

子系统开发

系统约束描述文件主要包含网络拓扑、通信矩阵、总线波特率和协议等信息。

3.4软件组件SWC的开发

与系统设计并行的是，软件组件（交付的原子软件组件）是根据抽象VFB、VFB或子系统VFB所要求的定义来实现。基于VFB定义的外部接口，可以定义内部行为，最终可以实现软件组件。

软件组件交付后集成到部署的ECU中。这里要注意的是软件组件的实现在很大程度上独立于ECU的配置，这是AUTOSAR方法论一个关键特征。

SW-C开发

开发应用软件活动描述了开发应用程序软件组件的工作流程和必要的活动。工作流程应允许独立地开发软件组件的核心功能。这些活动必须为每个应用程序软件组件执行。

开发应用软件

开发专用的软件组件活动描述了工作流程和必要的活动，以开发更专门的组件，这些组件可以部分依赖于硬件或ECU。

开发一个传感器或执行器组件

开发一个ECU抽象组件

开发一个复杂的驱动程序组件

SWC的描述文件主要包含每个SWC的Data和Operations、每个软件组件需要的资源（比如存储、CPU时间）、SWC的接口（Repetition rate）和运行机制等信息。

3.5基础软件BSW的开发

由于基础软件模块BSW独立于VFB，因此可以在ECU集成之前的任何时候开发

BSW开发

当BSW模块交付包、ECU提取和所有交付的原子软件组件可用时，ECU实例的集成就开始了。在此阶段，将配置ECU实例。执行顺序由调度任务和为这些任务分配软件组件运行表来定义。最后基础软件BSW配置完成，在生成RTE后，完整的代码将被编译并链接到一个可执行文件中。

ECU的软件集成过程

ECU资源描述文件包括传感器、执行器、存储器、处理器、通信外部设备（比如外置收发器）、引脚分配等信息。

4.总结

AUTOSAR采用‌分层架构‌设计，将系统划分为应用层（ASW）、运行时环境（RTE）和基础软件层（BSW），实现硬件与软件的解耦‌。

‌通过使用虚拟功能总线（VFB）‌定义标准化的通信接口，确保不同软件组件（SWC）间的跨平台兼容性‌。

应用层‌是由独立软件组件（SWC）构成，每个组件可视为独立功能模块（如.c文件），支持跨ECU复用。组件间通过端口接口进行标准化数据交互‌（即RTE）进行交互‌。

RTE层‌作为虚拟功能总线（VFB）的物理实现，屏蔽底层硬件差异，统一通信接口‌。

‌BSW层‌划分为MCAL（微控制器抽象层）、ECU抽象层和服务层，可提供硬件驱动、通信协议栈等基础服务，实现硬件驱动与上层服务的分离‌。

AUTOSAR的方法论定义了‌角色分工体系‌（如系统架构师、ECU开发者），明确了任务与工作产品（如需求文档、接口规范）的输入输出关系‌。

方法论的总体结构

具体工作流程可分为‌系统配置、ECU配置、代码生成、集成部署‌四阶段：

系统配置阶段‌定义软件组件接口、ECU资源需求和系统拓扑关系，生成系统配置描述文件（ARXML格式）‌。

ECU配置阶段‌从系统配置中提取特定ECU的通信矩阵、软件组件映射等配置信息，生成ECU级描述文件‌。

代码生成阶段‌基于ARXML文件自动生成代码框架，开发者仅需关注应用逻辑实现‌。

‌集成与部署阶段‌通过工具链编译可执行文件，部署到目标ECU并进行功能验证‌。