浅谈汽车行业座舱系统适配及Android Automotive

开始

在以往的汽车行业里，所有的软件以供应商为汽车定制的方式集成到汽车座舱Soc中。整车厂基于供应链管理的需要，要确保汽车软硬件需要自主可控，“灵魂”要掌握在自己手里。显然，众多供应商需要通力合作才能完成整车的集成。而所谓的合作，在车厂眼里，就需要以车厂为中心，各家产品围绕车厂需求进行定制，使用车厂的接口，连接起来，组装成整车。
这种模式，导致的产业生态就是大车厂+小供应商，或者，大车厂+大供应商+小适配/集成商。而在系统软件生态中，还没有博世级别的大供应商，普遍是小供应商在适配了若干项目之后，把反复使用锤炼的软件，组合打包成所谓的座舱操作系统。由于传统小供应商众多，这类操作系统也很多，没有哪一家异军突起、一统江湖。一方面：小供应商财力不足以支撑操作系统这类复杂软件的开发；另一方面，小供应商的生态位置，不可能把自己的产品推广给其竞争对手使用。

标准化

在野蛮生长中，座舱软件，会自觉的朝着降低成本的方向演进，把整个系统分为上面的产品化层/os层/frameowrk层和下面的适配层/hal层。每个项目，只需要修改适配层，能显著降低成本提高生产力。
但实际情况不尽如人意：某公司已经制定了一套车属性的信号，确定了信号的功能、数据类型等，那么在适配这些信号时，需要做以下几件事：1. 确定车厂给的信号需求是否能被某个已经标准化的属性覆盖，如果有，尝试适配该信号，如果没有，扩展标准或者定一个项目特有的信号。2. 适配标准属性时，如果数据类型同底层传入数据不一致，则需添加类型转换。而如果标准属性粒度较粗或较细，则需要把底层数据包进行组包或者拆包，并缓存中间状态。3. 在标准信号集上运行验收测试。1和2对于适配工程师来说，相对于新增一个项目定制信号，并把底层原始值透传给上层的方式，花费的时间要更多，又由于验收测试用例不标准，没有人能够对标准的执行程度进行正确的评估，因此在实际适配工作中， 标准实现程度不高，项目定制信号很多，上层软件普遍要再做定制开发。适配成本从原本局限在适配团队，变成了分摊到整个软件团队。加上团队协作，沟通成本，管理成本，实际上整个项目的成本上升了，项目成本上升，最终整个公司被淘汰。
上面的草台班子公司例子其实不少。甚至有时，公司内部推行标准化阻力太大，大家口口声声标准化，但就是无法落实，公司内部妥协太容易。解决方案，其实是生态化，在没有生态化的方案之前，标准化很难成功。试想已经有很多生态伙伴的软件使用你的标准信号，你还能不实现标准，反而让他们根据车型定制其软件吗？倒是可以，你得出定制费用。比如，你出钱让高德、爱奇艺给你定制。

Android Automotive

Android Automotive，是Android的车载版本，应用可以通过其中的CarService API访问车辆信息和进行车辆功能控制。

图1. Android Automotive系统服务架构 （来源：https://source.android.com/docs/automotive/security/vehicle_system_isolation）

在具体车型项目上，适配商只要将车信号通过VehicleHAL适配为VehicleProperty，现有的车载应用，可以继续正常使用。无需做车型适配。

显然，由于Android生态的存在，适配商妥协Android的VehicleProperty标准的阻力会更大。只可惜，这个标准不是适配商自主定义的标准。但好就好在，这是个应用开发商，适配商，车厂都广泛知道的标准。所有人都熟知的东西，存在性更加稳固，难以歪曲。标准稳固，将会减少车型的开发成本。

总结

随着智能座舱推广到更多的车型，座舱系统对新车型的适配一直在标准化和定制的泥潭中来回拉扯，对外采购座舱系统的车厂其对座舱系统的差异化需求不能沉淀为品牌调性，甚至同一个品牌的不同车型，车型的两代间，座舱系统的延续性都没有合理管控，导致座舱系统经常要从下到上进行定制开发。也许有的岗位的存在就是为了打破规则吧。而成本也因为基层技术人员的低成本被掩盖了。这种随意的结果，就是，没有标准，软件系统无法快速推广，最后，被外来的Android Automotive系统抢占市场。
当然，Android Automotive适配商还是会对Android Automotive从下到上进行定制以体现其价值。因此，适配和定制的故事远没有结束，但似乎注定平凡了。