2008年，宝马集团成为首家将AUTOSAR汽车开放系统架构应用于量产车的汽车制造商。十年以后的今天，AUTOSAR已经普遍应用于量产汽车，但要论是否能熟练应用AUTOSAR，我们还面临很多难题。

据统计，一辆高档的汽车其内部的代码量差已经超过了1kw行，超过上百个ECU。而随着顾客对功能需求的增加，以及整车厂对顾客需求的满足，这个数字还会不断的增加。日益增加的功能需求与软件复杂度之间似乎有一个不可逾越的横沟！ 

本篇连载的主题为“熟练掌握AUTOSAR”。笔者认为这是一个相当有深度有难度的主题，但这也是一个机会，让我们从技术面和应用面来（不侧重非技术方面，否则将更难以讨论）重新审视AUTOSAR的意义。同时，本篇连载也反映了来自很多用户和JasPar AUTOSAR标准化组WG等相关人员的意见。笔者希望能够竭尽所学，将AUTOSAR的导入和操作的经验分享给大家。

本篇连载笔者规划了4~5篇的原稿。如果朋友们有更多想要了解相关内容，笔者会在继续追加更新。所以，如果大家有需求的话，欢迎与牛喀网联系，或者在文末留言。

对于AUTOSAR的具体开发实践问题，我们也邀请您来参加我们牛喀网在7月6,7号举办的AUTOSAR技术培训。

AUTOSAR的近况和趋势 

本想直接进入主题，提笔之际，笔者意识到了“改变”的重要性。AUTOSAR已经经历了几次的迭代：

第一阶段（2004-2006）：标准基本开发时期（版本1.0.2.0和2.1）

第二阶段（2007-2009）：体系和方法相关方面扩展（版本3.0，3.1和4.0）

第三阶段（2010-2013）：可维护性和可选择性的改进（版本3.2，4.1和4.2）

特别是第二阶段，这是一次重大的变化。笔者认为，作为AUTOSAR标准的用户，对AUTOSAR标准的看法是否会发生变化，还要看AUTOSAR标准是否会再继续变更。

因此，在本连载的第1篇中，简要地介绍一下AUTOSAR的现状和趋势。

 Classic Platform（CP）和Adaptive Platform（AP）

关于AUTOSAR的诞生背景以及在过去几年里的成就，在此不多赘述，有兴趣的朋友可也翻阅牛喀网的历史文章，有多篇文章有涉及到相关话题。

ECU（电子控制单元）分类的方法有很多。从用于ECU的软件平台的角度来看，笔者认为它们通常分为两种类型：基于信息娱乐的ECU和传统的基于控制的ECU。然而，近几年来，ADAS和AD的快速发展导致了具有不同特性的ECU的出现，与此相对应的自适应平台AUTOSAR（AP）应运而生（表1）。

传统控制系统ECU

基于ADAS/AD的ECU

娱乐信息ECU

表1从软件平台角度分析了ECU及其各自的特性，部分由笔者根据AUTOSAR数据添加。

* 1）表中关于AP的预期安全要求（但不限于安全方面），会根据今后AP使用方式（对软件平台的市场需求）的变化而变化，业内已有许多人士认为ASIL B的安全等级远远不够。

2018年，为了迎合未来汽车智能化、网联化的需求，AUTOSAR联盟推出了一个全新的平台，将AP加入到原有的AUTOSAR平台中，形成自适应AUTOSAR平台（AUTOSAR Adaptive Platform，AP），并于2018年10月迎来了适用于面向量产的首次发布，另外还将原有平台更名为经典AUTOSAR平台。

AP能够应对CP难以适用的领域。例如，在动态部署方面追求较高自由度的信息娱乐*2）和通信领域，以及各种类型的商务现货供应（COTS）和开源软件（OSS）被。。。

※2）虽然有部分工程师认为AP并没有包括信息娱乐ECU，但这并不意味着完全没有涉及。 此外，AP R17-10 SWS通信管理中也有对信息娱乐ECU的引用。

以上所提及的领域，由于其特性，需要基于POSIX OS来操作，话虽如此，但是从安全方面去考虑，其在使用上的限制比一般的信息娱乐ECU还更为严格。

图1 AUTOSAR R17-10时期的软件构造图

— 持续扩展的Classic Platform —

与此同时，面向传统ECU的AUTOSAR也在不断改进，并有了一个新的名称Classic Platform AUTOSAR。

在CP R4.2.x中，重点改进了通信服务层的性能，完成改进了以下功能：

支持通过以太网（EthSwt）和CANFD来实现大量数据量的通信CAN FD；导入了针对大数据量通信的E2E Transformer（E2EXf）通信技术，由此提高了Large Data交换（LdCom）的效率；将Sender/Receiver通信的序列化，支持SOME / IP（ComXf，SomeIpXf），支持通信端的安全保护（SecOC），改进诊断相关设计信息的交换（Diagnostic Extract，DEXT），借助通信支持全球时间同步（TSyn）等等。

在CP R4.3.x中，则首次引入了V2X通信的支持，并将AUTOSAR的加密功能扩展到完整的加密保护堆栈：Crypto Service Manager、加密接口和加密驱动程序，支持比使用SOME / IP（SomeIpTp）传输接收还更长的数据（SOME/IP数据处理扩展）。此外，还已提取了各种协议规范作为Foundation的一部分，稍后将对这部分进行讲解。

几乎每个版本的迭代变化，都在做“加法”，功能不断扩展，例如，变更架构、功能增加以及方法论相关的改进。但其实也不乏一些“减法”，比如一些BSW已经在迭代的过程中被淘汰了（Cal，DBG）。

2018年10月，R4.4.0发布。笔者也参与了修订的审查工作（重点在与通信相关的条目上）。

R4.4引入很多Topic，主要是 Focus 在对AUTOSAR Artifact上面（Formal Model Query、Blueprint Derivation Mechanisms，ASAM Units，Logical Execution Time）。除此以外，通信相关的 Topic 也引入了（LIN Slave Support, Bus Mirroring, Transport Layer Security）；通过 Security Extentions 构建安全的 ECU 和 Secure Cars，在此方面，采取了很多措施；

为了能够兼容 CP 和 AP 平台的 EndtoEnd Safety 机制、网络管理、通信时间同步机制，做了很多提升；

对 Classic AR 平台，头文件结构做了一些 Cleaning up；

图2  AUTOSAR CP 在R4.3.1时期的软件构造(红色模块从R4.2.2以后被添加或删除)。

Foundation 

AP和CP并不是完全独立的。例如，基于AP的ECU和基于CP的ECU可以连接到同一个网络，因此二者均需要与各种通信协议兼容。除此之外，在系统设计信息等交付形式上，若AP/CP也没有达成一致的话，将会有更多的麻烦，特别是对车企一方来说，他们的管理会变得更加复杂。所以，AP和CP之间还是有很多共同点的！

把这些共同的部分截取出来，我们将其定义被称为Foundation (FO)标准组。

图3  2017年年末时，FO/CP/AP之间的关系，笔者根据AUTOSAR数据制作。

AUTOSAR的未来发展

正如笔者所言，AUTOSAR的修订仍未停止。

时至今日，AUTOSAR标准化的大多数成员和实际用户依然认为，AP不会取代CP，它们是互补的。此外，CP的修订并不会因为AP的出现而停止。现在，我们还在积极地扩展和改良V2X/车载以太网等等的相关标准。同时，我们还在讨论如何改善多核系统的可操作性。

*3）AUTOSAR的修订也不是随时都能进行的，将来，除非是修订一些不会影响与旧版本兼容的微小更改和错误修复，否则应该是不会再更改了。

有人说“如果AP已经更改到足够好，那么可以完全取代CP。”事实上，这是有可能的，只是在实践中仍有许多问题有待解决。举个非常简单的例子，AP还需要大幅缩短它的启动时间。

因此，笔者认为，AP能完全取代CP这种观点是有道理的，完全否定这个观点就太偏激了。人们认为，只要有足够的时间，就能解决诸如此类的问题。笔者表示很乐意能把这些观点变为现实，但必须要向市场传达这样需求和期望，这样才能拿到更多的投资，以便于研究和修订的继续。* 4）。

*4）笔者的真心话：“靠嘴没用，要靠人力和财力。”

笔者认为，去思考“对于难题我们能做些什么去解决”这个问题对我们来说更为重要。不要总是说“不可能”“还没得到解决”，应该更多的去考虑如何才能实现需求，应该去考虑是暂时观望一段一时间还是积极地去支持，如果你想要去出一份力，那么还可以思考一下你能做是什么。

 “不管这是谁说的，都不可轻信。”“根据目前的判断和情报，这是不能长期有效的。”抱有这样的想法是理所当然的。但笔者认为，最重要的是，我们能去多关注和参与AUTOSAR标准化的会议，一起研究讨论如何去改进标准。

以上内容是对AUTOSAR的现状及其未来发展的简要介绍。笔者本来还想详细介绍一些关于未来新主题/新篇幅的信息。