2003年11月，福特公司作为核心伙伴加入，12月标致雪铁龙和丰田汽车加入。接下来的11月通用汽车也作为核心伙伴加入。自从西门子VDO被大陆在2008年2月收购后，它就不再作为AUTOSAR的独立核心伙伴。

在2013年，AUTOSAR联盟进入一种持续改进模式，主要用来维持标准和提供所选择的改进

随着汽车电子的发展，一款现代豪华汽车可能包含多达100个ECU 包括从简单的传感器接口到复杂的信息娱乐及远程信息单元。

今天的汽车从过去的机械液压的启动转到今天的机械电子的启动，电子化的程度越来越高，要解决这个问题。AUTOSAR联盟提出了个口号“在标准上合作，在实现上竞争”。预计到2020年，所有车辆都将拥有一些基于AUTOSAR的ECU，因此该标准不能被忽视。改用AUTOSAR的一些原因和好处如下表所示：

德国大众在AUTOSAR会议上展示了使用AUTOSAR带来的收益如下：

AUTOSARarchitecture的分层式设计，用于支持完整的软件和硬件模块的独立性(Independence)，中间RTE(Runtime Environment)作为虚拟功能总线VFB（Virtual FunctionalBus）的实现，隔离了上层的应用软件层（Application Layer）与下层的基础软件（Basic Software），摆脱了以往ECU软件开发与验证时对硬件系统的依赖。

软硬件分离的分层设计，对于OEM及供应商来说，提高了系统的整合能力，尤其标准化交互接口以及软件组件模型的定义提高了各层的软件复用能力，从而降低了开发成本，使得系统集成与产品推出的速度极大提升。

算上复杂驱动层（Complex Device Drivers），AUTOSAR架构中共分六层：

1. 应用层（Application）

应用层由一个个Software component（SWC）组成，主要包括Application Software Component（控制策略、软件算法）、Sensor Software Component（传感器参数计算）、Actuator Software Component（执行器控制）。其中Application可以完全与MCU、ECU无关，甚至与互相关联的SWC组件所在位置无关，而Sensor和Actuator类型的SWC调用与ECU硬件平台相关。同时多个SWC可组合成为一个Composition合集被调用。

2. 实时环境（RTE）

AUTOSAR架构中各个Component之间无法直接进行的数据交换，必须通过RTE封装的API。因此RTE使ECU应用层与基础软件层无需形成映射关系就实现了SWC之间和SWC与BSW之间的数据交互。同时在AUTOSAR架构中还存在虚拟功能总线VFB（VirtualFunctional Bus）的概念。VFB是AUTOSAR提供的所有通信机制的总和，所有的Component（包括SWC、ECU抽象、服务、复杂驱动）之间的通信组成了VFB。所以说RTE属于VFB在单个ECU上的实现实例                 

3. 基础软件（BSW）

 BSW被抽象划分为3个层面和一个组件，分别是MCU层、ECU层、服务层，以及复杂设备驱动组件。

 MCU层的目的在于使上层软件与MCU处理器的型号选型剥离开。其中包括了关于MCU的驱动。

 ECU层的目的在于使上层软件与ECU硬件电路设计剥离开。其中包括了关于ECU上的芯片驱动和外部设备的IO接口。

服务层的目的在于提供给应用层可用的服务内容，主要包括：诊断、操作系统、通信、内存管理等

复杂设备驱动组件的目的在于提供复杂传感器和执行器的驱动，使应用层可直接访问硬件资源。通常对于实时性有着非常高需求的应用可以利用该组件实现控制管理，或是将过去已经应用非常成熟的功能代码移植到该架构下时可放在该组件中，比如ECU的喷油点火，MCU的PWM控制等

AUTOSAR为符合该标准的汽车电子软件系统开发过程定义了一套通用的技术方法，这种方法即被称为AUTOSAR方法论（AUTOSAR Methodology）。汽车OEM作为整车系统功能的规划和设计者，需要了解并掌握AUTOSAR提供的这套开发流程，才能主导和推进符合AUTOSAR标准的系统的开发过程。

主要步骤可划分两个阶段：

第一个阶段是系统配置阶段，这属于系统级设计决策工作。首先是编写系统配置输入文件，为XML类型的文件。应用软件的描述术语在 AOTUSAR中为软件构件（Software Components），该文件将确定需要使用的软件构件（即系统具有哪些功能）和硬件资源（ECU），以及整个系统的约束条件。AUTOSAR提供了一系列的模板（软件构件模板，ECU资源模板和系统模板）和标准的信息交换格式，工具供应商可据此提供相应的工具支持，从而简化系统设计的工作，最终系统设计者只需要使用工具填充或编辑相应的模板即可导出系统配置输入文件。系统配置输入包含三部分内容，第一个输入是软件构件描述，定义每个需要的软件构件的接口内容，包括数据类型，端口，接口等；第二个输入是ECU资源描述，定义了每个ECU的资源需求，如处理器、外部设备、存储器、传感器和执行器等；第三个输入是系统约束描述，定义总线信号，拓扑结构和软件构件的映射关系。系统配置阶段接下来的工作是将初步获得的系统配置输入文件借助系统配置生成器生成系统配置描述文件，同样为XML文件，这是系统配置阶段的最终工作成果。该文件将包含所有的系统信息，包括将软件构件映射到相关的ECU上（这种映射需要考虑到构件的需要、构件的连接、资源需求以及约束条件，有时也需要考虑成本等方面的因素），以及通信矩阵（整车的网络结构、时序以及网络数据帧的内容）。

第二个阶段是ECU的配置，这阶段的工作需要对系统中每个ECU分别进行。首先是使用第一个阶段的工作成果——系统配置描述文件，从中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、顶级功能组合（据此产生需映射到该ECU上的所有软件构件），将放在另一个XML文件中。提取信息的工作可借助工具完成。然后进入ECU配置的实际工作中，这一步负责往输入对象中添加具体应用所必需的信息，如任务调度、必要的BSW模块、BSW配置信息、给任务分配的可运行实体等。这一步的结果被放在ECU 配置描述文件中，它包含了具体ECU所需的所有信息。最后一步是生成具体ECU的可执行程序，此步将根据ECU 配置描述文件中的配置信息构建完成ECU的基础软件的设置和与基于AUTOSAR构件的应用软件的集成，最终生成ECU的可执行代码。

此外，要说明的是，AUTOSAR系统的设计过程使用了虚拟功能总线（Virtual Functional Bus）的概念。虚拟功能总线（VirtualFunctional Bus）将AUTOSAR软件构件相互间的通信以及软件构件与基础软件之间的通信进行了抽象，同时使用预先定义的标准接口。而对于虚拟功能总线来说，ECU内部通信和外部总线通信并没有什么区别，这种区别要等到系统布局以及ECU的具体功能最终确定才会体现出来。软件构件本身对于这种区别并不关注，因此我们可以在独立的情况下开发软件构件。在系统实现过程中，虚拟功能总线所代表的功能最终以RTE的生成来体现。

通过RTE实现AUTOSAR软件构件（即应用程序）相互间的通信以及软件构件与基础软件之间的通信的前提是，软件构件必须具有标准的 AUTOSAR接口。

目前，AUTOSAR已定义了一些典型的汽车电子应用领域（动力，车身/舒适和底盘）的标准接口。AUTOSAR按照功能逻辑分别将这些领域的系统划分成若干个模块，这些模块可被视为一个软件构件或多个软件构件的组合，这些功能性的软件构件的接口被明确定义，所定义的接口的内容包括名称，含义，范围，数据类型，通信类型，单位等。应用软件开发者在软件构件的设计与开发时需要应用这些接口定义。 这里以车身/舒适系统的雨刷管理的软件构件的接口定义为示例，如下图：

说明：雨刷管理构件（WiperWasherManager）有两个接口，CmdWashing和StaWasher,图中WWManager表示为雨刷管理软件构件的实例。针对CmdWashing接口定义了以下信息：

1）CmdWashing接口由WiperWasherManager构件提供，其数据内容为FrontWasher构件的Activation接口所使用。 

2）CmdWashing包含一个“Command”的数据元素。 

3）“Command”的数据类型为“t_onoff”。 

4）“t_onoff”属于“RecordType”，该类型描述一般的开/关信息。 

应用软件开发者应该意识到，面向AUTOSAR运行时环境（RTE）接口的应用软件设计的重要性，及早地将AUTOSAR应用层接口引入到实际的项目中来，为实现应用软件的可复用性做好准备，从而优化整个软件开发流程。

AUTOSAR正在成为现实，建立这样一个标准化平台并贯彻标准化，将会缩短新产品的研发时间和测试时间，从而帮助企业实现快速的市场反应。许多OEM都计划在接下来的车型中采用AUTOSAR。在市场上不少工具和软件供应商都已推出了符合AUTOSAR标准的工具或软件支撑，可为 AUTOSAR系统的设计和开发提供完整的无缝的解决方案。 

AUTOSAR是汽车电子软件平台标准化的历程中的一个巨大飞跃，我们需要学习和理解它。但是也必须看到，在整个汽车行内打破传统的软件开发平台需要相当长的一个过程。我们可以根据用户的需求和目标，在初期搭建AUTOSAR与传统软件的混合平台，这是是一个能够实现向AUTOSAR平滑升级的可行的方法。在这个过程里，重点不是单纯地使用，理解AUTOSAR的理念和思想才最重要，因为它对汽车电子软件开发的工作流程和商业模式都将带来意义深远的变革。

3月16-18日牛喀学城特邀请具备6年以上的AUTOSAR研究和应用开发经验的资深专家对AUTOSAR进行从入门到进阶到实践的三天专业技术培训，能对具体实施AUTOSAR项目起到指导作用。培训内容：

一、AUTOSAR基础知识介绍
        1.1. 为什么用AUTOSAR
        1.2. AUTOSAR的简介
        1.3. AUTOSAR软件架构
        1.4. AUTOSAR方法论
        1.5. AUTOSAR接口
        1.6. AUTOSAR开发流程
 二、AUTOSAR深入详解及例子演示
        2.1. OS操作系统详解
        WorkShop: OS操作系统配置例子演示
        2.2. Communication Stack通讯协议栈详解
       WorkShop: Communication Stack配置例子演示
        2.3 Diagnosis诊断协议栈详解
        WorkShop: Diagnosis诊断协议栈配置例子演示
        2.4 Mem Stack内存管理协议栈详解
        WorkShop: MemStack内存管理协议栈配置例子演示
        2.5 IO Stack 输入输出协议栈详解
        WorkShop: IO Stack 输入输出协议栈配置例子演示
        2.6 Wdg Stack看门狗协议栈详解
        WorkShop: Wdg Stack看门狗协议栈配置例子演示
        2.7 EcuM BswM系统服务详解
        WorkShop: EcuM BswM系统服务配置例子演示
        2.8 MCAL芯片驱动抽象层详解
        WorkShop: MCAL芯片驱动抽象层配置例子演示
        2.9 SWC 应用层组件设计详解
        WorkShop: SWC 应用层组件设计例子演示
        2.10 RTE集成详解
        WorkShop: RTE集成例子演示
三、AUTOSAR系统解决方案
        3.1. 传统软件到AUTOSAR移植解决方案
        3.2. 基于模型开发的AUTOSAR解决方案
        3.3. 主流的AUTOSAR工具链解决方案
        3.4. 多核AUTOSAR架构的解决方案
        3.5. 功能安全在AUTOSAR中的解决方案
        3.6. 信息安全在AUTOSAR中的解决方案
        3.7. 未来AUTOSAR的展望

底层工程师：掌握AUTOSAR底层MCAL和BSW以及CDD的配置和开发。

算法工程师：掌握如何基于AUTOSAR方法论进行MBD开发，生成符合AUTOSAR规范的代码。

架构工程师：掌握如何基于AUTOSAR进行系统和软件架构

集成工程师：掌握如何基于RTE进行软件自动化集成

测试工程师：掌握如何测试AUTOSAR的底层软件和系统用于组件

流程和质量工程师：掌握AUTOSAR方法论和开发流程

不同用户的技术积累不同，对AUTOSAR的需求和熟悉程度也不同，AUTOSAR本身也具备相当的复杂性，因此牛喀技研提供了一系列咨询服务，帮助用户更好应用AUTOSAR技术。服务范围：

• MCAL软件包配置咨询

• BSW 软件模块配置咨询

• 多核OS的系统方案咨询

• 传统软件到AUTOSAR移植解决方案咨询

• 基于模型开发的AUTOSAR解决方案咨询

• 功能安全在AUTOSAR中的解决方案