对这个问题感兴趣的人有两类，一类是汽车软件从业者，一类是 Rust 社区的开发者，至少在当前，这两类人重叠度很低。我尽量写得让两类人都能理解。
AUTOSAR 分为 Classic Platform 和 Adaptive Platform, 简称 CP 和 AP。在汽车软件中，CP 和 AP 是一套API级别的标准，由 AUTOSAR 组织维护，你知道的欧美汽车大厂和主要 Tie1基本都是其会员，国内很多公司也加入了，如华为等。加入组织很简单，每年给很少的钱，再给半个到两个人帮它干活就行，不是什么了不起的事情，但是能否有影响力就难说了。（有些公司把加入 AUTOSAR 作为宣传点的，呵呵一下就行）。
CP和AP跟我们常见的协议不一样，它并不是一个文本标准，是 API 级别的标准。也就是说，它的绝大多数协议是有代码的，至少是接口代码规范。加入AUTOSAR 组织后，就可以获取它的参考代码实现，否则只能从其官网下载文档说明，好几百份。
API级别的文档，就意味着其标准必须用具体的代码来描述，CP 用于以MCU单片机作为主要计算器件的汽车控制器中， 使用的是 C 语言，AP 是基于嵌入式 POSIX 标准，是使用C++语言来实现，而且要求C++14标准。
AP 的文档中专门有一份 “Guidelines for the use of the C++14 language in critical and safety-related systems”，500多页。主要内容就是一系列的编码规范，用于规避 C++各种可能导致不安全的坑。
既然明知道这么多坑，为啥还是要用C++？因为没有其它可选项，至少在 AUTOSAR标准启动的时候，没有其它可选项。其实 AUTOSAR 组织还是很积极采用新技术的，要不然也不会一上来就应用 C++14标准。
与 CP主要用于硬实时的MCU软件不同，AP 主要运行在 Linux或 QNX 等系统上。当然如果一些RTOS也能很好的支持 POSIX 标准，AP 也可以运行在 RTOS 上。
在理解 AP时，我们要区分一下 AP Platform 和 AP Application。AP Platform 一般由专门的公司按照AP规范进行开发，然后卖给某个汽车软件企业。该企业再基于于这个 Platform 开发自己的 AP Application。
这些 AP Application 典型的以车联网车端程序和自动驾驶程序为主，一般还要求符合 SOA架构。
这些应用，尤其是自动驾驶相关的应用，要求实时性很高。必须是 Native 程序，这基本上就排除了解释性动态语言(如Python)和有垃圾收集的语言(如Java)。如果还要求很好的抽象表达能力，那么在几年前，可选的确实只有 C++。
仔细读一下那500页的 AUTOSAR CPP Guidline ，你会发现其要求的大部分规则都已经被 Rust 原生支持好了。Rust 用编译器保证的安全性，在 C++中只能靠编码规则去维护，为了弥补这个不足，又有厂商开发代码扫描工具去发现潜在缺陷，明显的缺陷很容易被扫描出来，但是更深层次的缺陷，尤其涉及到多线程的并发场景，这些扫描工具实际也无能为力。
C++ 程序的内存错误问题是根深蒂固的，微软谷歌等大厂不缺牛人，做出来的产品很大一部分缺陷都是内存错误引起的。如果是服务器端程序，宕机了无非立马重启动一下。但是在汽车软件中，这可能会导致严重的安全(Safety)问题。
Rust 既有 C++一样的性能，又保证了极高的安全性，又有丰富的抽象表达能力，是最适合汽车软件的语言。
AUTOSAR 组织开始考虑应用 Rust 的可能性，这是一个很好的开始。目前也没有提出具体的目标，可能还需要一段时间。AP支持 Rust 有几种可能的方式：
为现有的 AP C++ API 标准提供对等的 Rust API标准。这样现有的 AP Platform厂商可以继续使用基于 C++ 的AP Platform 实现。但是其客户可以使用Rust API 开发应用。这可以让Rust API 尽快可用。不过也有一些技术问题需要解决，主要是 C++ 和 Rust 的互操作要有简便高效的方法。
更彻底的方式是 AP Platform 本身就使用 Rust 实现，这样提供的 API更符合 Rust 的语言特性，而不会像前面的方案一样要迁就原有的 C++ API。
无论哪种途径，我想都不会很快实现，AUTOSAR 组织干活是出了奇的慢，而且很谨慎。但是这一次，我相信他们走在了正确的道路上。
另外，Rust 的人才培养也需要加快，希望更多的程序员，了解 Rust ,学习 Rust , 应用 Rust。
我想，10年后，掌握 Rust 语言，将是入行汽车软件的必要条件。
阅读原文，关注作者知乎！
