汽车软件自主开发（汽车软件开发困局）

随着软件定义汽车的持续走热，各OEM车企开始建立自己的研发创新中心，关注在软件，人工智能，等创新研发。近在眼前的案例是，上汽集团成立上汽创新开发总院。独立研发中心的建立，从组织授权和资金上给予了充分的保障。但是，这样做就万事大吉了吗？我想，答案肯定是“No”

之前的系列文章，我们描述了什么是SDV，澄清了SDV的历史渊源以及对SDV的一些误解，并提出了软件驱动汽车的概念 。

今天，我们重点谈谈目前汽车行业面临的痛点问题，如何进一步解决，让软件真正发挥其巨大潜能。

图源：互联网

通过对不同的汽车软件开发者的访谈，以及软件开发管理过程中的经验教训，@爱索咨询认为，除去组织架构的独立性之外，汽车软件的转型，目前还存在几大方面的痛点亟待解决：

1、文化思想层面的冲突

2、人员技能的转型

3、内部流程制度的升级

4、成本管理的转变

1.

文化思想层面冲突

一百多年的汽车工业史，将汽车打造成了高度模块化的集成。汽车结构与机械工程师，穷尽力量确保车内不同的零部件做到最大程度解耦，保持其独立性。但是，“成也萧何，败亦萧何”，高度模块化为并行工程及外包奠定了厚实的基础，但也导致了OEM主机厂更多关注在产品定义，造型设计，产品组装集成和品牌宣传上。而大量的工程、开发和制造工作，都交给了供应商来做。

但是，当大量的零部件及软件产品是来自内部开发团队时，传统的工作思维将面临诸多新的挑战：

• “甲方爸爸思维”与生态管理思维的转换

在多年的供应商管理过程中形成的“甲方思维”又将如何适应新的情况呢？随着软件在整车的比重和重要性的扩大，传统的客户供应商关系将会演变为生态合作伙伴（如车联网的各种生态公司），软件平台供应商（如自动驾驶平台提供商），等等。这些转变，对传统的供应链体系都将带来很大的冲击，需要思维上的转变。发生在2021年的汽车芯片危机，现在还在延续的，而这，就是对传统的供应商管理体系考验的试金石。其次，随着OEM主机厂内部研发的建立和自主研发的起步，传统的，管理供应商的方法将很难套用到内部团队管理上。“甲方爸爸”的管理思维会加剧内部的冲突。需要对外、对内两种不同的管理方式和理念，而这需要时间来磨合并消化。

下图1展示了未来智能车的生态场景。面向未来的智能驾驶，更多的互联网内容提供商（ISP）会成为汽车企业的重要生态合作伙伴，因为他们同时面对C端用户（手机或PC端），又面对车厂（车端），所以，既不是传统的供应商，又不是完全松散的“路人甲”。对于生态合作伙伴的管理，需要新的创新思维与方法。

图1

• “零部件管理”的思维与系统和功能导向的场景的解决方案思维转换

与硬件相比较，软件是无形的，抽象的。在传统的零部件开发中，软件是嵌入到硬件实体里而不可见的，OEM主机厂更多关注的是零部件如何与整车适配在一起。而各个零部件的开发是独立的，相互之间的接口协调更多的是通过基于控制信号的整车物理通信网络实现。

与之相对应的是，系统与软件的开发，则是从客户需求的功能场景出发。下图2展示了典型的V2X的应用场景，需要各个ECU零部件相互协调，通过SOA的架构，形成有机整体。所以，客户场景与市场的需求，需要的是跨场景的解决方案，更多的生态伙伴的参与。从基础网络设施提供商，城市大脑方案商，基础公共实施方案商到云端平台服务商，生态内容提供商，都考验着汽车企业的方案设计与整合能力。

图2 图源：信息通信网

• “硬件开发管理”与“软件开发管理”的思维转换

• 零部件的管理，是通过严苛的质量阀门的管理，供应商交付的零部件产品（软件 硬件）将会被组装到整车上，其生产过程，版本和发布是严格计划管控的。但软件产品却可以做到“柔性生产”。每天甚至每小时“生产”，随时随地发布，更新替代。版本和功能的多样性，硬件的依赖关系，等，都带来与零部件开发管理不一样的技能和思维挑战（图3）。
• 硬件产品开发过程中，很多依赖是无法调和的，例如，如果芯片没有，开发工程师就无法完成电路板的焊接。但是，对于“柔性”的软件，很多依赖却可以找到不同的变通方法，未必是“Hard Dependency”。这需要管理层的敏捷性（Agility）以及经验的积累，团队的精诚合作。

图3

• “硬件产品管理”与“软件产品管理”的思维转换

硬件产品的“刚性”与软件产品的“柔性”，决定了二者存在不同的产品策略。未来趋势的判断，随着技术大鳄的参与，硬件会逐步标准化，通用化；而软件的柔性却会因主机厂的不同，客户及市场的需求不同，展现了其多样性，成为未来竞争的战略要地。但正是这种柔性，也必将给OEM主机厂的各个职能系统，如生产制造系统，财务系统，采购系统，质量管理系统，技术中心，甚至人力资源部门带来思维的冲击与变革。这里简单摘取两点进行描述。

• 从产品的可靠性来看，硬件产品通常存在“浴盆曲线”（见图4），但作为软件产品，却是不同的可靠性曲线。随着软件产品的独立发布与演进，软、硬件产品的质量管理将出现不同的方向和手段。

图4

• 硬件产品的生命周期与软件产品呈现不同的形态 – 硬件产品一旦装配，将伴随着车辆10~15年而不可更改。如有问题，只能是“召回”，无论是物理召回或返回4S店维修。但软件产品却是“发布”和“更新”。现代互联网的ICT技术，支持了远程OTA。在整辆车的生命周期内，将会出现多轮新功能的迭代（图5）。

软硬件的解耦，形成独立的产品路线图（Roadmap）；而独立演进，导致产品生命周期的不同，演化为不同的思路：硬件产品的标准化，通用；软件产品的多样化。这必将产生新的问题，如软硬件兼容性的问题，后向兼容等，这都是对传统零部件产品管理的思维挑战。而这点，也同样冲击着OEM主机厂的生产制造系统 – 是要求软件功能面面俱到还是“最小可靠”软件？OEM主机厂的财务系统，如何更好地定义及使用软件资本？

图5

• “硬件成本”的管理思维与全生命周期成本的思维转换

传统上，OEM主机厂更关注的是零部件的成本（Per Unit Cost），软件开发成本更多地是分摊到零部件上。

当面对软件供应商提供的软件产品，Unit Cost又将如何定价，又如何转化为可盈利的软件商业模式呢？同样，如果是内部开发的软件产品，开发成本如何摊销？软件资本如何合理配置？因为软件是“柔性”的，当管理不善，软件的开发成本将大大超过了零部件硬件成本的节省。

BMW公司的Christian Salzmann曾经提供过一组数据：对于每年需求量为500K的一款ECU，如果每年降低硬件成本20Euro每件，在7年的生产周期内，共计可以节省70MEuro。但是，如果软件开发没有做到更好的重用，却会浪费额外的100MEuro。

图6

另外，“开源节流”，传统的硬件成本的管理模式关注的是“节流”。但是，作为前车之鉴的ICT行业，如摩托罗拉，诺基亚，苹果公司，汽车界的“鲶鱼”（见上图6），特斯拉，他们的软件销售却打开了一扇“开源”的窗户，通过硬件的预留，虽然短期内硬件成本上升了，但是，通过软件的OTA迭代升级，却创造了更大的销售收入。这种全生命周期的成本考核，是对传统汽车人的新的思维和管理体制上的挑战。

2.

人才技能转型

汽车软件相对而言是复杂的，并且是分布式部署的。其应用领域，覆盖了从车机娱乐软件到安全实时控制软件，跨度大且分散。根据其应用领域及对安全实时性要求来划分，汽车软件可以概括为这些领域（如图7示例）：

• 车内多媒体及HMI相关的软件开发。这部分通常对实时性要求不高，也是目前车联网软件的重点域
• 车内智能驾舱相关的语音识别，手势识别等AI软件。这部分通常对实时性要求不高，更多的是基于事件的处理，部件之间的通信是通过服务请求与反馈的形式实现
• 车辆底盘、动力控制，车内通信等相关的软件及算法。这部分通常对实时性和安全要求高，需要非常高的可靠性。部件之间的通信是基于信号的控制来实现
• 车内与自动驾驶相关软件，如ADAS， AVP等。这部分通常对实时性要求高，需要安全设计的考虑；同时，对算力有更高的要求，需要高性能的处理器来满足系统功能的要求
• 云端软件及移动通信基础架构：这部分通常不依赖于具体的硬件，根据应用场景，对实时性要求各不相同。同时，通信网络的开放，对信息安全的要求日益苛刻。

图7 图源：瑞萨网站

通过上述简单的软件划分，我们可以分析：

• 和整个汽车软件关系最大的，可能就是OEM主机厂的电子电气架构部门。但是，观察一下各大车企技术中心、研究院的负责人，基本都是传统底盘、发动机等领域出身。他们对智能驾舱，自动驾驶和云端及移动通信，以及信息安全的知识短板需要补足（见图8）。

图8图源：QNX网站

• 目前，OEM主机厂基本是提供类似“Black Box”的零部件规格（SOR或RFQ），具体的实现和技术上的Know-how，基本上都掌握在供应商手里。
• 如图9所示，是来自OEM主机厂的典型VDC （Vehicle Dynamic Control）子系统功能规格书，除了这种黑盒的接口定义，软件与硬件的实现，基本掌握在供应商手中。所以，传统汽车产业链当中，对软件了解最多的，应该是Tier1供应商中的汽车电子软件部门。而知识产权从供应商手里转移到汽车OEM开发人员手里，几乎是不可能的。尤其是，传统上的汽车OEM企业，基本不会为软件开发单独支付NRE成本 （某种意义上讲，就是“白嫖”）。所以，要获得这部分知识产权，更是难上加难。

图9

• 受限于整个行业的发展趋势，汽车电子软件的主流开发大部分还局限在微控制器（MCU）层面。最近五、六年，随着车联网和自动驾驶的发展，逐步转向了基于ARM的SOC平台，多核的芯片处理器。
• 目前汽车行业的从业人员，基本是利用基于AUTOSAR的自动代码生成工具，如Etas， Mentor Graphic， EB Tresos等，通过图形化的界面配置应用程序，自动产生代码。但是，随着自动驾驶，智能驾舱的新功能出现，汽车对算力的要求越来越高，分层的软件架构，操作系统和高性能SOC平台的采用成为常态。之前的开发工具链开始面临挑战，新的工具链还不成熟。这对于传统汽车行业软件从业人员，将是新的挑战。多年使用类似于AUTOSAR CP的工具链，已经让大部分汽车软件开发人员沦为了简单的配置工程师，逐步丧失了底层软件0到1的开发能力； 对底层芯片的理解更是捉襟见肘。这种挑战将触及灵魂。缺少必要的，成熟工具链来支撑代码的自动生成与测试，将会产生发自内心深处的焦虑感。
• 图10是节选自互联网的一张HPC的系统架构图。复杂的系统结构，对传统ECU的从业人员的挑战是巨大的。代码运行从传统的单核到现在的多核，如何合理地，动态分配资源而不是之前的静态资源分配，都对传统汽车电子软件开发人员带来挑战与技能的转型。

图10 图源：互联网

• 汽车电子软件属于嵌入式软件开发范畴，是在专用计算机系统上进行软件开发，一般要求开发人员具有一定的硬件基础。主流的嵌入式平台包含ARM、DSP、FPGA等，开发语言主要是汇编/C/C 。
• 相对应的是，IT与互联网大部分的软件开发人员，都属于在通用计算机系统上的软件开发，一般是在某种操作系统上，如Windows，Linux，Android，IOS等，进行应用软件开发，主要包含电脑端，手机端，服务器端等设备，以X86与ARM架构为主。大部分开发人员都会使用某种高级语言，如C ，JAVA，JS，PYTHON，MySQL，等，进行特定任务的开发。
• 但是，对来自汽车产业外部的互联网开发人员，虽然人数巨大（据估计，有100万的从业人员），但如果从事汽车电子软件的开发，却需要了解整车架构及汽车本身的know-how（图11）。这个限制了互联网软件开发人员的选择。
• ICT行业与智能硬件的公司，以及芯片公司，也培养了大量的通信精英（移动通信，Wifi，Ethernet 等）和底层BSP或Firmware固件开发团队，他们属于软件团队中最懂电子硬件的人。这部分人将是汽车电子软件开发的最佳人选。但是，对整车架构和汽车本身的know-how的理解（图11），也同样限制了这部分嵌入式软件开发人员能够快速上手。

图11 复杂的整车架构，需要多年的知识沉淀与积累 图源：互联网

• AI智能的发展，互联网公司培养了大量的算法人员(图像/语音/数据）。开放的互联网精神，也培养了一批技术深厚的信息安全团队。而应用软件的多样化和成熟的C/S框架，如Restful，RCP等，也练就了一批优秀的前端和后端开发人员。因其更多的独立于具体的硬件，或者倾向于云端和熟悉的PC及移动端打交道，切换成本会很少。这部分人才是实现车联网的云端软件，以及大数据分析的专业人才。当然，对于整车的架构，汽车产业法令、法规的了解以及B端市场的规律，仍然需要一定时间的磨合与历练。

3.

管理流程升级

百年的汽车工业开发，形成自己特色的，基于质量阀门的整车开发流程。通过这种流程，把OEM主机厂和其Tier1，Tier2供应商密切地联系在一起，形成有机的开发整体。但是，随着基于功能和场景的解决方案逐步发展，软件占据主导地位，现有的OEM开发流程却不能很好地适应软件系统与软件工程，流程面临巨大的挑战，需要全方位的系统建设。这种流程的系统化建设，需要流程的架构与设计，它涵盖了组织制度，角色和职责等维度(具体参阅公众号文章：行云流水般的流程)：

• 需求管理流程

传统的开发模式是OEM主机厂负责系统和子系统的功能及接口定义。但是，很多子系统的划分是根据物理的机械件（ECU）及接口进行了划分，相应的负责工程师也跟随相应的硬件耕耘多年，形成自己的专业know-how；但是，专业化的分工，形成“I”字型的知识架构。不同的零部件之间的技术壁垒逐步产生，甚至各自为政，“老死不相往来”。问题是，如图12所示，基于场景的需求开发需要多个子系统的联动；需要“T”字型的知识架构。如何分解需求；如何进行需求管理；分层管理；如何做到需求的重用；如何减少各功能之间的依赖，都对原有的流程产生新的挑战。

汽车OTA功能的实现，如何管理汽车上市后的OTA功能与需求，如何连接运营，4S售后服务等功能需求，如何随时提供云端服务功能，都需要对原有基于零部件开发的流程进行改造。

图12智能汽车功能需求

• 架构设计与接口定义流程
• 汽车工业的传统模式，软件的know-how 基本被有实力的供应商把控，具体的软件实现，接口定义，对OEM是不可见的。所以，如何确保不同的ECU软件有机结合，协调实现必要的场景，相应的工作机制需要建立。
• 而车、管、端三位一体的未来发展方向，三者的联动的架构设计，同样需要合理的流程机制来保障。伴随着SOA架构的逐步实现和车内通信线路的以太网化，接口的定义将逐步从基于信号的定义或者简单的消息结构的定义C/S模式转向更复杂的SOA架构与接口定义（如图13所示）。当冲突发生，需要相应的技术仲裁流程进行合理评估。

图13 接口定义将由简单的C/S模式向更复杂的接口定义演进

• 代码与集成流程
• 汽车的造型设计形成不同的车型及零部件的Fit和Form。传统的零部件开发模式，不同Fit的零部件的软件代码各不相同。如何有效地重用代码；如何构建软件架构平台；如何将不同代码集成在一起，成为新的挑战。需要新的流程来确保软件代码的重用性及软硬件的集成。
• 产品与项目管理流程
• 传统的零部件产品与项目常常合二为一。一旦硬件最终认可，软件将随之冻结，直至生命周期的终结。但是，智能车的软件产品却可以随时增加新的功能，形成新的版本，通过远程OTA进行更新。可以想象，未来同一款硬件，将会预装不同的软件版本，在市场上销售。如何管理客户车辆的软件版本，如何管理软件的兼容性，等等，需要新的流程改造。而项目管理，如图14所示，可能会以软件开发管理为主，在硬件产品的生命周期内，通过项目的模式组织软件的交付。

图14

• 售后服务的流程
• 随着软件远程诊断的开启，以及AI及IOT技术的落地，基于数据的售后服务体系终将建立。传统的4S服务的模式将逐步转移到线上。如图15所示的远程服务体系的场景将成为常态，相应的流程体系的改造也势在必行。多生态合作伙伴的介入，如何管理端到端的场景解决方案，提供更高的服务质量，都是OEM主机厂面临的问题。

图15 复杂的智能汽车场景

• 开发工具链的挑战
• 各种自动驾驶，人工智能，软件算法，云端软件的开发诉求，将会促使新的开发工具链。或者传统的工具链进行演化，如基于AUTOSAR CP开发的工具链将进一步进化为AUTOSAR AP等（见图16）。而流程的优化和改造，同样需要类似JIRA，禅道，Synopsys，RobertFramework之类的软件开发测试验证等工具链的引进。

图16 AUTOSAR工具链 图片源自CSDN

4.

成本管控方式转变

做过汽车Tier1供应商的小伙伴，我相信都经历过那种血淋淋的汽车零部件的商务报价过程 – “没有最低，只有更低”。最后的后果，不管你是否相信，会是产品质量的丧失。这从一个维度，充分反映了目前传统OEM主机厂的思维定式：一辆汽车的功能决策，更取决于零部件的价格。在过去以机械结构为主的汽车中，这个做法可以理解。但是，随着软件驱动汽车的发展，如前面几篇文章所述，全生命周期的成本的权重要远大于目前单件成本的争夺。对比来看，在新势力造车的蔚小理中，交付让消费者眼前一亮的功能却被视为更为重要的决策依据。

在零部件采购中，这种“砍到骨头”的低价策略，会带来负面影响。工程师们，不管是来自供应商或者OEM主机厂，会不断地降低处理器的算力，内存，通信带宽等关键计算资源，从而降低硬件成本。如此一来，却对软件带来根本的损害及不可预测的后果：

• 软件工程师们将不得不优化软件代码，以适应有限的计算资源。但因为系统的复杂性，这样的后果是，在未来的性能测试中发现各种莫名其妙的问题，导致很难查找根本原因，从而增加了工程成本，甚至延误了产品的上市周期。另一方面，尽管没有找到问题的根源，迫于项目的进度，工程师们也是“拆东墙补西墙”，采用临时方案应对项目的交付，为量产后的产品质量种下隐患，增加了售后服务的成本。
• 软件工程师不得不压缩他们的代码，确保其足够的小，可以被调入有限的内存运行。代码要足够地精简，确保内存的每一位（Bit）都能被充分利用。如此一来，任何新功能的增加将变得几乎不可能。更有甚者，甚至缺陷的修复也将无从下手，而不得不进行硬件的召回。这些，在增加了工程师成本同时，进一步加剧了公司的售后服务成本，消减了公司的软件销售收入来源。
• 由于代码的过度优化，会导致后期的代码维护尤其困难。复杂的语句，让后期维护人员不敢有丝毫的触碰。对代码的修改成为每个人心中的噩梦。
• 过度精简代码，将会很难做到代码的重用及其可移植性。也无法做到功能的预埋。如此一来，唯一的途径是通过OTA进行从上到下的固件和应用软件的更新。从客户成本的角度，浪费了客户的时间，增加了流量成本。从业务的角度，增加了内部的运营成本及软件工程成本。

图17 全生命周期成本

这里，我们并不是强调传统的Cost Per Unit的成本管控不重要。我们强调的是全生命周期的成本概念。如图17所示。所以，在评估零部件的单件成本时，除了零部件相关成本之外，必须考虑其带来的项目延迟风险，产品上市窗口，工程成本，调试成本，售后服务成本，代码复用以及未来新的销售收入增长的机会成本。

消费者需求的多样性和定制化的诉求，驱使主机厂在配置上形成不同的配置版本，产生不同的汽车Variant。以“简单的动力系统控制的应用功能来讲，会有3488中不同功能配置”（注：来自Manfred Broy）。而目前的奢华车，基本配备120个左右的ECU，简单的“有”或“没有”的配置，会有2120种Variants，供消费者选择。除了市场和用户的驱使，在整车长达10~15年的生命周期内，各种小改款，中期改款，大改款，VAVE层出不穷，同样结构的ECU，会有不同的FIT，FORM，也可能预装了不同的软件版本。如此众多的Variant，需要巨大的验证与确认工作，必将产生庞大的汽车工程成本。同样，庞大的汽车Variant，也对售后服务的备件，服务技能和召回预算形成巨大的压力 。

汽车行业的“赖特定律”（注：莱特定律由美国航空工程师西奥多·赖特在1936年提出，他将制造效率和制造经验联系起来，其核心是每生产一定单位的产品，其制造成本将下降恒定的百分比）指出，“单个型号的汽车产量每累计增加一倍，成本的价格就会下降15%”。这终将会驱动硬件的标准化，降低汽车的Variants，从而降低汽车工程成本；功能的差异化实现，则更多地通过软件来竞争。

图18 某品牌汽车OTA升级新闻

然而汽车软件带来的成本增加，将越来越显现。如何管控软件的劣质质量成本，将成为摆在每一位汽车从业人员面前的一道关卡。图18是关于某品牌汽车的OTA升级的一则新闻（德国《汽车与体育》(Auto Motor und Sport) 报道），12小时的升级过程，7.5小时的软件安装过程。按4G网速计算，升级包高达30G，单车流量费将高达三位数。更令人大跌眼镜的是，电池电量居然被耗光，这让消费者情何以堪？

汽车工程成本的另一个维度，是汽车软件的Variant。传统的ECU零部件，在整车的生命周期内，会有不同的FITs，Form等。但是，不同外观尺寸的ECU与ECU之间的软件差异可能不超过10%。不幸的是，因为软件的不重用性以及单位硬件成本的管控理念、采购理念，导致软件很难从一个ECU很快地移植到另一个ECU。这使得大部分软件不得不被重写（据德国汽车工业提供的数据，大部分软件的改动其实只有10%的差异性。）。随着车子智能化的发展，底层硬件的通用化，软件重用的趋势是必然。如此一来，软件产品的观念（见图19示例图）急需在整车厂建立并实践。

图19 软件产品概念示意图

5.写在最后

SDV,软件驱动汽车，毋庸置疑，已经是实实在地摆在每一个组织，每一位汽车从业人员面前的课题。尽管汽车软件，相对硬件而言，体量仍然渺小，其在成长的道路上需要“水”，“土壤”和“阳光”，需要企业管理者和每一个汽车从业人员的爱护和浇灌。但是，面对这个汽车产业这个百年未有之大变局，软件必将撬动整个汽车的产业链，在汽车生命周期的各个环节，如图20所示，产生新的价值，驱动创新与再造。

图20 汽车生命周期生态链

在这个过程中，觉醒的OEM开始与外部公司合作，例如零束汽车软件与爱索管理咨询的云端发布DevOPS改造；极氪汽车的整车流程优化、再造，软件审核等。这些都是顺应软件驱动汽车之大变局，通过广泛的生态连接，构建健康的软件生态链；另一方面，也正反映了企业开始正视面临的问题，通过价值洞察，积极推进组织变革，思维变革，技术know-how, 人才储备以及流程制度的建设。

只有这样，才能构建软硬融合的产业生态，让智能汽车，乃至自动驾驶技术越走越远。

,