从今天开始，我将为大家带来专题连载《精通AUTOSAR》。

请各位耐心看这篇文章，原作者是从一个比较高的视角去为大家解读AUTOSAR，而不是上来就直接讲技术实操。我个人认为原作者的观点非常值得大家去深思，不妨跟著老师提出的问题一起深入浅出的去看文章，边看边去想问题的答案，你一定会有收获的。

AUTOSAR自面世以来，从半导体工业、工具和软体厂商、零部件供应商到汽车制造商本身，整个汽车领域内的利益相关方都给予该标准积极的支持。

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

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

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

本篇连载笔者规划了4~5篇的原稿。如果朋友们有更多想要了解相关内容，笔者会在继续追加更新。（所以，欢迎各位朋友评论留言，告知我们你想了解的内容噢！）

— 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实时性要求高中低预期安全要求ASIL DASIL B以上QM演算能力要求低中~高高动态部署支持不需要需要

* 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的现状及其未来发展的简要介绍。笔者本来还想详细介绍一些关于未来新主题/新篇幅的信息。

但是，CP AUTOSAR被大量应用于开发，学习CP AUTOSAR已经是「当下「的事情了。对于大多数人来说，以CP为中心的回顾或许更有好处吧！所以，笔者计划下篇从CP AUTOSAR开始谈起。

首先，我们先来看看以下这几个关于使用AUTOSAR的问题：

问题1：你认为AUTOSAR的工作是否有「终点」？

问题2：仅仅是是「追上」标准你认为够了吗？

问题3：标准是否「束缚「了太多开发工作呢？

下篇开始，我们会带著这些问题为大家说明「如何使用AUTOSAR「。

推荐阅读：