汽车基础软件漫谈——第四回：欧美OEM对“软件定义汽车”的早期实践

面对日益复杂的汽车软件，尤其是域控制器等中央计算平台，仅凭一家之力难以完成，共建软件开发生态，联合多家生态伙伴共同开发是“软件定义汽车”实现的必由之路。而这种多家联合开发控制器软件的模式其实在行业内早已有之，尤其是国外OEM，早在上个世纪就开始了“软件定义汽车”的探索，只不过那时的软件主要聚焦车辆的性能，而今天的软件更多强调终端消费者的使用体验，即所谓的“千人千面”。了解这些早期“软件定义汽车”理念的具体实现方法对于实现今天的“软件定义汽车”无疑具有重要的指导意义。本节介绍作者所了解到的传统控制器中存在的各种软件联合开发模式，希望能有助于国内同行以更务实的态度推进“软件定义汽车“的落地，少走弯路。

相对于软件和硬件均由供应商完全开发的传统控制器开发模式，控制器软件由两方及以上共同进行开发的项目都可认为属于软件联合开发模式，Bosch还专门将这种开发模式定义为Software-Sharing。OEM参与软件开发程度的不同以及数据交互形式的不同，对于实际合作方法的影响巨大，因此必须区别对待。以下以常见的针对应用软件的联合开发为例，根据联合开发程度由浅到深的顺序进行介绍，供大家参考。

联合开发模式一
该模式是指OEM以非源代码的形式，如Simulink模型或UML模型，提供一小部分应用层功能的控制策略详细需求，源代码仍由供应商进行开发，且供应商需要开发双方软件之间的交互接口层，如图中灰色部分所示。

这一模式是程度最小的一种软件联合开发模式。对OEM而言，无需掌握软件开发能力，也能够提出自己对某部分控制功能的独特见解，使得最终的系统功能有别于供应商提供的标准解决方案。模式一适用于在个别应用层功能点采用自主方案，同时具备功能建模能力但不具备软件开发能力，软件仍由供应商开发，且同意自主方案对供应商公开的OEM。

联合开发模式二
该模式是指OEM以目标代码（软件编译之后的Object文件）的形式提供一小部分应用层功能的控制策略。

相对于模式一，由于合作方交互过程中看不到具体的控制策略，因此这一模式可以保护OEM的自主创新不泄露，不过同时要求OEM具备软件开发能力，这对于双方的合作提出了更高更细的要求，比如提前约定好各自的函数与变量的命名空间，编译器的具体版本等，而且由于供应商得不到源码，导致软件调试难度增大。模式二适用于在个别应用层功能点采用自有方案，同时具备功能建模能力和一定的软件开发能力，软件集成仍由供应商负责，且自主方案要求保密，不对供应商进行开放的OEM。该模式在发动机控制器领域较为常见。

联合开发模式三
该模式是指OEM除了自身参与应用层软件开发以外，还邀请了其它若干家第三方供应商提供部分应用层软件，大部分应用层软件均不再使用控制器供应商的标准方案，并且最终的软件集成由OEM进行。这就使得OEM能够将各家供应商之所长集于一身，更大程度地掌控系统控制策略，同时又能依托控制器供应商深厚的硬件、软件、功能安全和信息安全等开发能力和强大的生产能力。

相对于模式二，涉及的合作方更多，合作各方直接的接口数量大幅度增加，且都要求访问基础软件的提供的接口，因此合作的难度大幅增加，同时对于OEM的软件开发及系统集成与测试能力都提出了更高的要求。模式三适用于在较多应用层功能点采用自有方案和第三方方案组合的形式，同时具备功能建模能力和较强的软件开发能力，软件集成仍由供应商负责，且自主方案和第三方方案要求保密，不对供应商进行开放的OEM。

联合开发模式四
该模式是指OEM开发大部分应用层软件，仅有一小部分应用层软件继续采用控制器供应商的标准方案。该模式的合作方法与模式三基本类似，对于OEM的自主开发能力要求大幅提高，但由于不涉及其它供应商，因此项目合作难度有所降低。该模式能够使OEM重用其自身已有的较为全面的能力，基本掌控系统控制策略。

模式四适用于大部分应用层功能采用自有方案，同时具备很强的软件开发能力，能够负责软件集成，且自主方案要求保密，不对供应商进行开放的OEM。

联合开发模式五
该模式是指OEM开发全部应用层软件，控制器供应商仅提供硬件和基础软件（含复杂驱动）。该模式的合作方法与模式四基本类似，但由于不涉及其应用层软件之间的交互，因此项目开发难度有所降低。该模式同样能够使OEM重用其自身已有的较为全面的能力，并完全掌控系统控制策略。

模式五适用于全部应用层功能采用自有方案，同时具备较强的软件开发能力，能够负责软件集成，且自主方案要求保密，不对供应商进行开放的OEM。该模式在变速箱控制器、整车控制器等领域较常见。

总结
通过以上对各种软件合作开发模式的细分介绍可见，不同的合作模式所支持的“OEM自由度”是不同的，同时自由度越高，所需的软件开发能力要求也越高，当然投资也会更大。下表以OEM视角，从多个角度对各种软件联合开发模式进行了定性对比。实际项目中，OEM（或者仅负责应用功能开发的组织）可以根据自己所期望的“自由度”，结合自身技术能力和公司资源情况，并考虑对知识产权的保护，量力而行，选择最适合自己的联合开发模式，稳妥推进自己“软件定义汽车”的梦想。

最后，需要强调的是，基础软件对于控制器软件联合开发的影响极其重大。这是因为在联合开发过程中，基础软件决定了整个系统的状态管理及任务调度、内存模型、底层API接口、开发与调试工具、软件构建方法（各类文件解析与编译）等整个软件开发所依赖的基础设施。

因此，OEM们最头疼的就是由于各家供应商的基础软件在上述各个方面的差异而导致的巨大的移植工作量。这种问题与手机领域中一个APP通常至少要开发Android和iOS两个版本在本质上是一样的。

讲到这里，相信大家就明白了为什么AUTOSAR Logo中间那个字母“O”最特殊，绝不是仅仅出于设计美感的考虑，而是强调Open，开放！逆向思考一下：谁不开放了？谁想开放？自然是OEM希望Tier1们对自己更加开放。于是，BMW等一众OEM强拉着Bosch等Tier1巨头对基础软件进行标准化，从而形成了以架构、应用接口和方法论为三大支柱的AUTOSAR标准，以期减少OEM软件的移植工作量。

汽车的基础软件还在持续不断的发展，AUTOSAR将只有进行时，没有完成时。