AUTOSAR产生背景
车辆功能的创新导致车辆E/E架构日益复杂。与此同时，开发要求通常自相矛盾：例如要求驾驶域辅助系统支持关键性驾驶操控，提高燃油经济性同时符合环境标准。信息娱乐和通信系统与实时车辆环境和在线服务的不断深入整合带来了更多挑战。
为持续满足如上需求，需要一种新的ECU软件架构，否则无法满足不断增加的客户要求和日益严苛的法律法规。
2003年，汽车整车厂和供应商创建AUTOSAR联盟。联盟的目标是阻止不断重复开发相似或相同的应用软件组件，为实现基本功能的协作奠定基础，同时为创新性新功能的竞争开发留出空间。联盟定义的AUTOSAR标准构成了未来车辆应用程序的基础，有助于弥合各领域之间的界限。在ECU网络中灵活地分布软件可以为系统范围的优化创造更多可能。
AUTOSAR联盟
AUTOSAR联盟网站：http://www.autosar.org/
AUTOSAR联盟是由汽车整车厂、供应商以及软件、半导体和电子行业的公司组成的全球发展合作组织。
在标准中合作，实现上竞争的口号下，各成员以工作组为单位，享有并承担着不同的权利和义务。核心合作伙伴决定哪些团体可加入AUTOSAR联盟，高级成员则负责制定标准。
AUTOSAR的目标如下：
- 标准化应用程序软件功能之间的接口和基本功能的接口
- 定义ECU软件参考架构
- 将分布式开发过程的数据交换格式标准化
实现这些目标后，参与的公司希望获得以下好处：
- 通过功能的灵活集成、重新分配和交换来优化ECU网络
- 掌控日益提升的产品和流程的复杂程度
- 维护整个产品生命周期
AUTOSAR 3.0版本是第一个用于ECU量产的版本。
当然，AUTOSAR标准有其局限性。例如，AUTOSAR无法描述应用软件组件的功能行为。
AUTOSAR概念
SWC（Software Components，应用软件组件）与BSW（Basic Software，基础软件）之间的明确接口是AUTOSAR架构的组成之一。BSW模块提供基本的标准服务，例如总线通信、存储管理、IO访问、系统和诊断服务。
RTE（Runtime Environment，实时运行环境）同样是AUTOSAR架构的组成之一，负责控制SWC之间的连接以及从SWC到BSW的连接。
VFB（Virtual Functional Bus，虚拟功能总线）是AUTOSAR中的概念基础，用于SWC之间的通信以及BSW服务的使用。由于SWC通信全部基于VFB，因此SWC独立于ECU硬件。从而可实现在不同项目和平台之间重用SWC。通过为每个ECU配置RTE以及相应的BSW，从而在实际车辆中实现VFB。
AUTOSAR分层模型
AUTOSAR对ECU软件进行抽象，并划分为基础软件、实时运行环境和应用软件层。
基础软件包含许多定义好的模块，并划分为不同的层。例如，MCAL（Microcontroller Abstraction Layer，微控制器抽象层）提供用于访问微控制器的存储器、通信和输入/输出（IO）的驱动程序。
ECUAL（ECU Abstraction Layer，ECU抽象层）为访问ECU的所有功能提供统一接口，例如通信、存储或IO，不管这些功能是属于微控制器还是由外围组件实现。
服务层为应用软件层提供不同类型的后台服务，例如网络服务、存储管理和总线通信服务。该层也包含操作系统（operating system）。
RTE将应用软件层从基础软件中抽象出来，控制应用软件层的运行时行为并实现数据交换。在应用软件层中，ECU的应用程序功能以单个应用软件组件的形式实现。
分层模型简化了从软件到各种硬件的移植（porting）。以前，如果软件架构设计不佳，移植需要在各个方面（直至应用软件层）进行大范围修改。基于AUTOSAR，只需替换MCAL中所有微控制器相关的驱动程序即可，重新配置ECU抽象层中的模块，其他所有层均不受移植影响。这大大减少了开发和测试工作以及相关的风险。
AUTOSAR层级模型
SWC Mapping
BSW Stack
AUTOSAR Layer Model
AUTOSAR定义三种类型的接口
- AUTOSAR接口
- 标准AUTOSAR接口
- 标准接口
AUTOSAR接口是通用接口，源自任意SWC的端口。AUTOSAR接口由RTE提供，用于SWC之间或SWC与ECU固件（IoHwAb、复杂设备驱动）之间的接口。例如，SWC可以通过这些接口读取输入值并写入输出值。
标准AUTOSAR接口是由AUTOSAR标准预定义的特殊AUTOSAR接口。SWC使用这些类型的接口访问由服务层的BSW模块（例如ECU状态管理器或诊断事件管理器）提供的AUTOSAR服务。
标准接口是AUTOSAR标准用C语言预定义的API接口，用于连接BSW模块、RTE与操作系统，或RTE与Com模块。
AUTOSAR Interface
Standardized AUTOSAR Interface
Standardized Interface
开发阶段
AUTOSAR组织在AUTOSAR方法论中定义了ECU软件的开发方法，将开发过程划分为各种操作，并通过一组XML文件对开发伙伴之间的数据交换进行标准化。
定义SWC并将其分配到ECU，从而在系统设计阶段建立应用程序架构，同时还定义网络通信。由此生成系统描述文件（AUTOSAR XML文件），并由系统描述文件为每个ECU生成系统描述的特定提取。
在ECU开发期间，开发人员实现SWC，并配置BSW和RTE。在配置期间，开发人员定义特定项目所需的基础软件内容，从而优化整个ECU软件。配置后，开发人员会获得ECU配置描述文件（AUTOSAR XML文件），该描述文件与系统描述文件的ECU提取保持一致。
代码生成器根据ECU配置描述文件生成或修改ECU软件的基础应用软件组件，同时还会生成特定的RTE代码。
应用程序的开发与此过程无关。SWC的描述文件（AUTOSAR XML文件）描述SWC的接口。基于这些描述文件，可以单独实现和测试SWC，从而简化整车厂和一级供应商（Tier1）的应用软件集成工作。
AUTOSAR交换格式
AUTOSAR定义以下交换格式：
- SWC描述文件：
供应商或整车厂定义SWC，并为每个SWC创建XML文件（SWC描述文件），描述SWC的接口和资源要求。然后，供应商或整车厂创建用于实现的相关C文件。 - 系统描述文件：
整车厂首先根据SWC定义独立于ECU的整个车辆的功能内容，然后整车厂设计通信网络并将SWC分配到现有的ECU，结果保存在系统描述文件中。
从AUTOSAR 4.0开始：
- 系统提取文件：
对于每个ECU，整车厂会将系统描述文件简化为系统描述文件的系统提取，以便分享给相关ECU的供应商。此文件替换之前用于配置BSW模块的.dbc（CAN总线数据库格式）、FIBEX（现场总线交换格式）或.ldf（LIN总线描述文件格式）文件。 - ECU提取文件（ECUEX）：
扁平化进程用于根据系统描述文件的系统提取生成系统描述文件的ECU提取。虽然与系统提取一致，但从平面角度来看ECU提取仅包含原子SWC。一级供应商可以使用内部生成的SWC扩充ECU提取。
AUTOSAR 3:
- ECU提取文件（ECUEX）：
对于每个ECU，整车厂会将系统描述文件简化为系统描述文件的ECU提取，以便传递给相关ECU的供应商。此文件替换之前用于配置BSW模块的.dbc（CAN总线数据库格式）、FIBEX（现场总线交换格式）或.ldf（LIN总线描述文件格式）文件。 - 完整的系统描述文件的ECU摘要：
以系统描述文件的ECU提取为起点，供应商开始集成自己的SWC，并生成完整且最新的系统描述文件的ECU提取，包含ECU的所有SWC的描述，不管SWC来自整车厂还是供应商。
- BSW模块描述文件：
ECU配置的另一个前提条件是BSW模块描述文件，其中包含数据结构定义以及BSW模块的所有可配置参数。这些文件与具体实现相关，并且与生成器一样，属于AUTOSAR协议栈供应商提供的BSW模块的静态代码内容。 - ECU配置描述文件（ECUC）：
供应商根据系统描述文件的最新ECU提取文件和BSW模块描述文件创建了初始ECU配置描述文件，并根据该文件配置ECU。这需要设置和检查BSW模块和RTE参数的工具。相关生成器以ECU配置描述文件为基础，生成特定ECU的RTE和BSW模块
灵活的AUTOSAR方法论可适合不同项目和不同整车厂的实际要求。例如，在系统描述文件中可自由选择是否使用SWC。
功能软件的开发
车辆的功能软件最初被描述为一个整体系统，随后细分为多个子功能，即SWC。这些SWC通过接口（端口）将信息（数据元素）传输给其他SWC。
从概念上讲，SWC之间的通信由VFB处理。由于开发早期尚未确定将哪个应用软件组件分配给哪个ECU，因此这只是一个逻辑上的观点。VFB表示ECU内部以及ECU之间的通信。应用程序并不了解底层技术，这样可以确保应用程序软件的开发和使用不受硬件影响。
设置并定义所有SWC和接口后，将其分配到相关ECU。
然后，特定ECU的实时运行环境作为实现虚拟功能总线的实现，组织应用软件组件之间的通信，并在操作系统的帮助下处理应用软件组件的执行。
可运行实体（Runnable Entity）是执行单元，最终以C函数的形式实现。对可运行实体的函数调用由开发人员配置，然后由RTE实现。例如，可以周期性或自动响应接收数据元素。
AUTOSAR提供端口作为通信接口，并定义了两种通信方式：
- 在SR（Sender-Receiver，发送方/接收方模式）通信中，数据元素从一个应用软件组件传输到另一个应用软件组件。应用软件组件之间经常使用这种通信。 语法示例：Rte_Write_<Port_Name>_<Data_Element_Name(...)
- 在CS（Client-Server，客户/服务器端）通信中，客户端异步或同步调用服务器的操作。这相当于函数调用，常在基础软件的应用程序和服务（诊断、存储管理等）之间发生。 语法示例：Rte_Call_<Port_Name>_<Operations_Name(...)
单独创建的SWC描述文件中记录了SWC及其接口和可运行实体。但AUTOSAR无法描述功能行为。
AUTOSAR工作产品：从整车厂到一级供应商
配置AUTOSAR ECU的基础是ECU提取文件（ECUEX）。这是一个由AUTOSAR定义的XML文件（*.arxml），包含ECU配置的规范，通常由整车厂生成。
AUTOSAR在内容方面提供很大的自由度，具体内容取决于整车厂。以下是可能的常规变体：
- 网络描述（用例1）
- 网络描述和应用软件组件作为规范（用例2）
- 网络描述和实现的应用软件组件（用例3）
一级供应商必须基于ECUEX生成ECU配置描述文件（ECUC），用于保存基础软件的详细配置。
在向AUTOSAR过渡期间，可能并非所有参与者都仅使用AUTOSAR方法。因此，供应商可能会从整车厂接收到.dbc、.ldf或FIBEX数据库，并基于此数据库来生成ECUC。
功能软件
在AUTOSAR中，ECU的功能软件通过应用软件组件实现，其核心原理是创建SWC的形式描述（SWC描述文件），然后从中获得SWC的C语言接口。SWC描述文件存储在AUTOSAR定义的XML文件中。
使用以下选项之一创建与SWC描述文件匹配的SWC实现：
- 手写代码开发
SWC可以通过手写代码实现。 - 基于模型的开发
模型工具用于创建SWC的行为模型， C代码基于模型自动生成。
SWC的AUTOSAR概念的特点在于SWC的实现具有独立于微控制器的接口，从而为在不同硬件平台上运行SWC提供了所需的技术条件，进而可以更好地在不同ECU中重复使用SWC。当然，由于存在其他限制，因此可能无法在任何的ECU上运行任意SWC。例如，即使提供的接口允许，在车门ECU上运行发动机控制器功能也并不合理。
为在实际开发过程中实现复用和接口兼容， SWC功能的正确至关重要。由于明确定义了SWC的接口，因此可以对SWC执行测试，例如单元测试。这样可以开发一个独立于其他SWC的SWC，然后将其作为经过全面测试的单元存放在库中，甚至可以将SWC作为COTS组件提供。
基础软件的任务
AUTOSAR系统是通过VFB（或特定于ECU的RTE）互连的应用软件组件的形式描述。此抽象概念可能表明AUTOSAR基础软件仅涵盖通信。情况并非如此。
AUTOSAR基础软件还提供内部ECU服务，例如状态管理（ECU状态和通信通道控制）、诊断服务、看门狗服务、操作系统以及非易失性存储管理，当然也包括IO。
半导体制造商通过MCAL，在IO的标准化中发挥了特殊作用。由于标准化，以前由ECU供应商解决的某些问题现在由基础软件供应商解决。
右侧的软件架构图是Vector对AUTOSAR标准的实现，即MICROSAR。
基础软件的属性
只有在BSW提供所需机制时，才能以应用软件组件的形式进行抽象。
因此，BSW会通过这些机制对RTE进行补充。在与RTE及其操作紧密交织的通信协议栈和操作系统方面，这一点表现得尤其明显。
例如，BSW必须生成事件并为RTE提供计时器。BSW还通过通信总线将数据传输到其它ECU。在执行应用软件组件的可运行实体时，程序流控制和系统状态管理都是BSW的任务。同时，BSW还提供同步机制，序列化并行进程的访问。
RTE及其最佳配置
实现应用软件组件的描述文件中所包含的通信和调用机制需要高效的实时运行环境（RTE）。
SWC的形式描述允许软件设计的自动分析以及实时运行环境的派生、生成和优化。
软件设计的形式化描述中所包含的信息包括调用可运行实体时所在的上下文，以及可运行实体与同一SWC或另一个SWC的其他部分进行交互的方式。
通过考虑基础软件的配置等其他限制，可以决定如何以最佳方式实现函数调用。
基本上，必须做出以下方面的决定：
- 如果需要，选择阻止机制，以阻止并行运行的其他可运行实体进行访问。
- 调用方法。
可以（以宏或C函数的形式）直接进行调用，也可以通过与操作系统一起触发的RTE事件进行调用。 - 读写访问类型。
可能是对变量的访问，也可能是对基础软件的API的调用。此外，必须考虑不同访问类型的语义及其实现机制。
根据具体配置，这些决定可能会对性能产生重大影响。
一般来说，实时运行环境的生成器应尽量少用OS事件和警报。适当配置系统可显著节省资源和减少执行时间。为此，需要了解在应用软件组件设计阶段每个决定带来的影响。
基础软件中的OEM依赖项
AUTOSAR基础软件的特点之一就是高度模块化，表现在水平方向的不同区域（集群）中，以及垂直方向的不同抽象层中。AUTOSAR允许使用基础软件的不同粒度（一致性分类，ICC），因此可将BSW模块组合（群集化）为单体式基础软件，该软件仅由一个包含全部基础软件功能的模块构成。
AUTOSAR基础软件不一定具有整车厂自定义特性，但在某些方面，各个整车厂的BSW协议栈通常有所不同。
例如，在非AUTOSAR标准的特定BSW模块的数量和任务方面，协议栈可能会有所不同，也可以通过添加应用软件组件的形式对AUTOSAR基础软件进行功能扩展。
在基础软件的结构中，此类差异发生在以下区域：
- DIAG：诊断事件管理器、诊断通信管理器
- SYS：通信通道处理
- COM：网络管理
- COM：网关功能
- 加密模块、专有传输协议等特定服务。
在基础软件的配置方面，不同整车厂的工作流程也有所不同：
- 整车厂需求定义的方式（.dbc文件、系统描述文件的ECU提取或单独的SWC描述文件）
- 诊断布局和参数设置（ODX、CANdela文件等）
- 对供应商的其他要求，例如通信协议栈发布后的配置能力（Post-build）、以库的形式交付
右侧的软件架构图是Vector对AUTOSAR标准的实现，即MICROSAR。
基础软件从何而来
供应商处理基础软件的方式因整车厂而异。
例如，在某些情况中，整车厂已从特定软件提供商购买了硬件无关的基础软件模块。在这种情况下，供应商只需要采购硬件相关模块。在其他情况下，整车厂会为供应商免费提供基于特定目标平台的，已经预集成的基础软件包。
整车厂也可能仅指定基础软件模块的功能，ECU的技术实现和集成则完全由供应商负责。供应商可以向各个软件提供商采购模块。然后，供应商可以自行集成所购买的模块，也可以让软件供应商完成此项工作。
一些大型供应商已经开发了自己的AUTOSAR基础软件，因此也可以充当内部的软件提供商。根据与整车厂的合作关系，可能需要就此软件的使用进行具体协商。
工具
创建AUTOSAR ECU软件需要使用不同的工具，可大致分为以下类型：
- 系统设计工具
用于定义网络架构和通信，以及SWC的设计和分发。 - 基础软件和RTE配置工具
用于创建ECU的BSW模块的配置描述文件（ECU配置描述文件）。 - BSW模块的代码生成器
根据ECU配置描述文件，为ECU生成专门配置的BSW模块。
这些任务通常由不同的工具处理。因此，标准化的XML格式是AUTOSAR的一个重要组成部分，并且是不同工具之间交换设计和配置数据的基础。
这种标准化至关重要，因为同一开发项目中通常会使用不同制造商的工具。例如，独立于微控制器的BSW可能来自一家软件公司，而MCAL及其相关的代码生成器则由半导体厂商提供。
每个BSW模块可能会使用不同的工具。但从实践角度来看，建议使用统一的工具配置BSW。
移植解决方案
AUTOSAR标准支持将非AUTOSAR方法开发的ECU软件移植到AUTOSAR体系中。为此，AUTOSAR定义了特定的复杂驱动（Complex Driver）。
复杂驱动可以理解为特殊类型的SWC，不需要基于SWC模板的形式化描述。
复杂设备驱动无需使用RTE，可以直接访问AUTOSAR基础软件。这意味着，从应用程序的角度来看，"仅"基础软件发生了更改，而应用程序可以在很大程度上保持不变。在移植的框架中，也可以将应用程序视为复杂设备驱动。这是迈向AUTOSAR软件架构的第一步。从开发工作的角度来看，第一步最具成本效益。
使用这种方法，虽然可以从部分AUTOSAR功能中获益，例如，通过RTE定期调用应用程序的内容，或经RTE进行通信和诊断，但应用程序核心的实现仍不符合AUTOSAR标准。
从长远来看，应用程序中未按AUTOSAR标准建模的部分将被消除，特别是所有任务主体和对操作系统的调用，以及所有具有中断阻塞的点和其他基础软件的访问。可使用符合AUTOSAR的标准的元素将其替代。如果使用完善的设计方法，可以比以前更有效地实现这些应用程序。
测试AUTOSAR ECU
测试期间，同样的测试方法可以用于AUTOSAR ECU和非AUTOSAR ECU。将ECU视为黑盒时，只需考虑以下事项：
- 网络管理：
AUTOSAR定义专属的NM（Network Management，网络管理）协议，不同于以前使用的OSEK NM等协议。测试环境必须考虑此NM协议，并正确准备和处理网络通道的相关报文。 - 用于描述网络通信的文件格式：
AUTOSAR网络通信描述文件属于系统描述文件。根据整车厂的要求，.dbc、FIBEX或.ldf等以前的格式将替换为新格式。测试环境必须能够处理这种格式。
AUTOSAR的标准化内部软件架构确保每个AUTOSAR ECU中都存在某些状态变量，并可在测试环境中使用这些变量从而为测试和调试ECU提供附加价值。例如，EcuM模块中提供的ECU状态，以及ComM模块中存储的各个网络通道的通信状态。通过适当配置BSW模块，可以通过XCP与ECU的连接（例如通过某一网络或者JTAG或Nexus等调试接口）来访问这些状态变量。BSW生成器可以提供这些状态变量的匹配描述文件（A2L）。作为替代方案，还可以使用AUTOSAR为此专门定义的监控和调试协议。
AUTOSAR在访问应用程序级别方面也提供了好处。例如，可以生成RTE，从而能够访问SWC之间交换的数据。同样，RTE生成器也可以生成合适的A2L文件。
Vector的AUTOSAR解决方案
本文从VECTOR官网AUTOSAR介绍整理而来，原文链接如下：