1.AUTOSAR的架构及方法论

        在15、16年之前，AUTOSAR这个东西其实是被国内很多大的OEM或者供应商所排斥的。为什么？最主要的原因还是以前采用手写底层代码+应用层模型生成代码的方式进行开发。每个供应商或者OEM都有自己的软件规范或者技术壁垒，现在提个AUTOSAR想搞统一，用一个规范来收割汽车软件供应链的每个环节，把每个底层软件开发工程师变成点点点工程师，从代码移植、学习成本再到个人发展意愿，都是非常不可接受的。

        但是近十年，随着汽车车型迭代速度加快、控制器代码呈指数级增长以及汽车电子电气架构的更迭，老板们开始发现，以前野路子手撸的方式在新车型、新控制器的开发、芯片硬件平台、移植速度以及成本也急剧增加，再加上近几年国产AUTOSAR基础软件供应商如春笋般冒出，把AUTOSAR 基础软件价格打到令人发指的低的程度；OEM、供应商开始尝试加入AUTOSAR的大部队。

        那么，AUTOSAR到底有什么魔力，以至于现在成为了汽车软件开发的一个准入门槛？我们具体来看看（注意，这里主要讲Classic AUTOSAR；Adaptive AUTOSRA会新开专栏讲）。

1.引入AUTOSAR的目的

        前面我们聊到汽车的迭代、代码的增加等因素导致汽车软件的开发成本剧增，那么引入AUTOSAR的目的就是为了缩减这些成本、同时提升软件质量；具体而言，主要有以下几点：

• 复用应用层功能代码，减少移植成本；例如我给A客户开发的VCU某功能，现在B客户也想用，使用AUTOSAR SWC组件的方式可以快速部署架构，只要部署得当，模型生成的arxml、代码可以直接复用。
• 复用同一套基础软件栈；这个就很简单了，在AUTOSAR的BSW层级，将忽略掉最底层的硬件平台，将关键的例如通信栈、存储栈、模式管理、操作系统等统一起来，那么作为基础软件开发就有一套统一的开发方法，只需要在硬件平台上做适配即可快速迭代
• 复用开发工具和方法论

2.AUTOSAR架构概述        

        那么AUTOSAR规定的这个架构具体长什么样呢？示意图如下所示：

        在BSW、MCAL这一层采用统一的标准接口，同时硬件与软件相互解耦 ；同时采用RTE的通讯方式，基本实现了应用软件与基础软件、硬件平台的解耦。

        上面这张图，大家可能还比较陌生，那下面这张图大家一定非常熟悉。

        上图是基于AUTSRA最新的R22-11。我们着重关注BSW这一层

• 红色部分：MCAL(MicroController Abstraction Layer)；为上层提供标准接口，下层则由MCU独立开发，好处是上层使用者可以不关心具体的MCU类型，例如直接使用Can_Write发送数据，实际上有可能这个调用者都没详细看过MCU CAN模块的具体内容。
• 绿色部分：ECU抽象层(也叫接口层)和复杂驱动；更上层用户可以直接调用该层API，而不用考虑外设的片上还是片外、甚至不用考虑外设PIN脚定义；复杂驱动这里暂时不讲，太灵活了
• 紫色部分：服务层(Services Layer)，BSW中的最顶层，为相关的应用软件提供服务接口，包括操作系统服务、车内网络管理和通信、ECU管理、诊断、存储等等。

        与之前相比（主要是以前只看了4.2的标准，哈哈），R22-11提出了Off-board communication的概念，用于规范标准化V2X通信、车内无线通信和ECU离线通信系统；增加了加密栈，用于规范标准化内外部加密硬件系统的密码服务（这一块是我最近主攻的方向，详见专栏《汽车信息安全》）。

        有了AUTOSAR架构的基本概念，下面我们要来谈所谓的方法论。

3.AUTOSAR的方法论

        所谓方法论，即一种以解决问题为目标的理论体系或系统，通常涉及对问题阶段、任务、工具、方法技巧的论述。方法论会对一系列具体的方法进行分析研究、系统总结并最终提出较为一般性的原则。

        那么对于AUTOSAR的方法论来说，就是使用一套全面、详略得当的设计步骤来构建一个AUTOSAR系统。以下图为例：

图片来源： AUTOSAR_TR_Methodology

         我们可以看到，完成一个AUTOSAR系统，需要系统、子系统、VFB(Virtual Functional Bus)系统描述、应用软件、基础软件、系统集成等部门的通力合作，这么多部门有可能是同一个公司，也有可能是不同供应商，那么为了提供效率和质量，使用统一可复用的方式（例如arxml的引入）是非常有必要的，每个部门各司其职，根据预定义好的方法输出工作产出给下游。

        上面说的还是有点抽象，下面举一个实例来看。

        注意，这是系统层级的描述，不是基础软件工程师理解的开发工作。

        例如，我现在想要同时设计汽车的车轮防抱死、防侧倾两个功能，最先考虑的是这功能需要哪些输入、输出，且每个输入产生的输出可能会经过不同的软件处理才会最终通过执行机构得到响应，那么我会根据上述两个功能的时间、性能要求，以输入、中间处理、输出这种方式设计出不同的SWC；如果还有更多功能，那么就会有更多的SWC。但是我具体是不知道这些SWC会部署在哪个ECU里，那么我会把这个SWC的描述文件，作为输入给到下游，下游工程师根据SWC描述，在软件实现之前先验证这些组件的交互、接口是否完备完整，输出的产物就叫做VFB(Virtual Functional Bus)。如下图：

       除此之外，ECU设计人员、系统设计人员也会将自己的工作产物输出，这时候就需要有一个工具来将SWC分配给不同的实际ECU，同时生成ECU内外部通信接口，而在ECU描述文件里也有真正的BSW（这块也就是我们搞基础软件最常见的配置工具，以前方法就是EB配MCAL，到处arxml到普华、Vector等BSW配置工具），从而构建了一个完整的AUTOSAR系统。

       

        上面这个方法论理论是可行的，但这种自上而下的顶层设计方法论，目前我还没有接触。

        实际开发中，如果是自研的ECU，例如VCU这种件，很有可能就是一个公司，ASW组+BSW组。ASW通过MBD建模生成代码和arxml，BSW配置各种模块（通信栈、诊断栈、存储栈、模式管理等），然后集成人员通过RTE配置工具根据功能规范和接口描述，将ASW和BSW连起来生成RTE层代码，完成集成，最后编译、调试。

       最后，用一张接口图来描述AUTOSAR系统如何通信的

AUTOSAR Interface：定义SWC和BSW的数据交互接口，例如Rte_Send等

Standardized AUTOSAR Interface：用于BSW给SWC提供的标准服务接口；

Standardized Interface：同一ECU的基础软件模块的通信。这具体用处不大。

4.小结

        本节内容主要是从AUTOSAR的架构和方法论，对AUTOSAR做了一个入门的普及；虽然这里看起来还是比较简单，但在实际操作中，随着BSW层软件供应商的增加，这一块的服务和市场会占据大部分。

        所以大多数朋友还是更聚焦于BSW各个栈的实现，例如产线上某DID读取失败问题如何把供应商搞疯，标定栈测量数据的周期过小导致总线负荷剧增问题、ECU的低功耗是拉闸还是休眠实现，甚至说各个协议栈的配置技巧，我想这才是大家关心的。

        今天就在暂时聊到这里，接下来，我会慢慢以一个ECU自上而下的开发方式来梳理AUTOSAR各个模块。