对这个问题感兴趣的人有两类,一类是汽车软件从业者,一类是 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 语言,将是入行汽车软件的必要条件。
联系客服