工作思考 —— ECU软件合作开发

传统ECU开发都是供应商自己设计控制器的软硬件，作为系统性方案的供应商牢牢地把握着ECU的软件产权，并以附带的出售所有相关电喷零配件。但如果是供应商进行软件开发，就不可避免的有以下问题存在：

开发时间周期长需求变更响应慢开发价格高没有核心知识产权甚至拒绝开发

随着基于模型设计（MBD）的普及，Mathworks/Etas的代码自动生成技术的推广，以及OEM整体水平的提高，OEM开始不甘心在软件功能上受制于供应商的限制，提高在软件开发过程中的话语权，甚至希望能直接参与软件的开发与标定，从而来降低系统供应商的垄断地位，从而降低采购成本。

提供人力

客户直接指派工程师到供应商公司里，使用供应商所提供的工具链进行软件开发。这种开发模式有以下几个特点：

工作产品归供应商所有客户需要按照供应商流程进行开发供应商来保证软件开发质量

这种工作方式，供应商是十分满意的，相当于客户直接派人帮忙进行软件开发工作。对于OEM方面肯定是拒绝的，派自己人给别人干活。

OEM与供应商根据软件需求规范，分别开发ECU软件的一部分功能。开发后将各部分组合在一起形成最终的产品软件。在开发过程中，双方都只专注于各自部分的功能开发，而自己的代码对于对方来说都是黑盒的。我个人认为这种方式对于供应商来说内心是拒绝的，原因如下：

由于客户代码是黑盒的，供应商无法把控未知代码给ECU运行带来的风险。合作开发并不意味着开发时间的缩短，相反有很大可能增加开发的工作量。包括软件集成，问题排查等各个方面。降低了供应商在软件与标定方面的话语权，系统性供应商的地位下降。

反过来，OEM方面内心是欢喜的，对于频繁变更的模块与功能，它可以自己参与开发也可以报给第三方，第四方工程软件供应商（比如AVL，里卡多，舍弗勒等等）来做。但话说回来，谁开发谁负责。如果因为OEM自己开发的软件模块而造成售后或召回事件，那这苦果也只能OEM自己承担了。

公众号：QCECUSJ

氨气“ 携手进步共同成长 ”

钟意作者

工作思考 · 目录

工作思考 —— ASPICE 工作思考 —— 敏捷开发（1）

阅读原文