汽车软件开发：目前还存在几大方面的痛点亟待解决？

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

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

图源：互联网

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

1、文化思想层面的冲突

2、人员技能的转型

3、内部流程制度的升级

4、成本管理的转变

一、文化思想层面冲突

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

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

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

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

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

图2源：信息通信网

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

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

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

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

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

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

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

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

二、人才技能转型

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

车内多媒体及HMI相关的软件开发。这部分通常对实时性要求不高，也是目前车联网软件的重点域；

车内智能驾舱相关的语音识别，手势识别等AI软件。这部分通常对实时性要求不高，更多的是基于事件的处理，部件之间的通信是通过服务请求与反馈的形式实现；

车辆底盘、动力控制，车内通信等相关的软件及算法。这部分通常对实时性和安全要求高，需要非常高的可靠性。部件之间的通信是基于信号的控制来实现；

车内与自动驾驶相关软件，如ADAS， AVP等。这部分通常对实时性要求高，需要安全设计的考虑；同时，对算力有更高的要求，需要高性能的处理器来满足系统功能的要求；

云端软件及移动通信基础架构：这部分通常不依赖于具体的硬件，根据应用场景，对实时性要求各不相同。同时，通信网络的开放，对信息安全的要求日益苛刻。

图源：瑞萨网站

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

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

图源：QNX网站

目前，OEM主机厂基本是提供类似“Black Box”的零部件规格（SOR或RFQ），具体的实现和技术上的Know-how，基本上都掌握在供应商手里。

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

受限于整个行业的发展趋势，汽车电子软件的主流开发大部分还局限在微控制器（MCU）层面。最近五、六年，随着车联网和自动驾驶的发展，逐步转向了基于ARM的SOC平台，多核的芯片处理器。

目前汽车行业的从业人员，基本是利用基于AUTOSAR的自动代码生成工具，如Etas， Mentor Graphic， EB Tresos等，通过图形化的界面配置应用程序，自动产生代码。但是，随着自动驾驶，智能驾舱的新功能出现，汽车对算力的要求越来越高，分层的软件架构，操作系统和高性能SOC平台的采用成为常态。之前的开发工具链开始面临挑战，新的工具链还不成熟。这对于传统汽车行业软件从业人员，将是新的挑战。多年使用类似于AUTOSAR CP的工具链，已经让大部分汽车软件开发人员沦为了简单的配置工程师，逐步丧失了底层软件0到1的开发能力； 对底层芯片的理解更是捉襟见肘。这种挑战将触及灵魂。缺少必要的，成熟工具链来支撑代码的自动生成与测试，将会产生发自内心深处的焦虑感。

下图是节选自互联网的一张HPC的系统架构图。复杂的系统结构，对传统ECU的从业人员的挑战是巨大的。代码运行从传统的单核到现在的多核，如何合理地，动态分配资源而不是之前的静态资源分配，都对传统汽车电子软件开发人员带来挑战与技能的转型。

图源：互联网

汽车电子软件属于嵌入式软件开发范畴，是在专用计算机系统上进行软件开发，一般要求开发人员具有一定的硬件基础。主流的嵌入式平台包含ARM、DSP、FPGA等，开发语言主要是汇编/C/C++。

相对应的是，IT与互联网大部分的软件开发人员，都属于在通用计算机系统上的软件开发，一般是在某种操作系统上，如Windows，Linux，Android，IOS等，进行应用软件开发，主要包含电脑端，手机端，服务器端等设备，以X86与ARM架构为主。大部分开发人员都会使用某种高级语言，如C++，JAVA，JS，PYTHON，MySQL，等，进行特定任务的开发。

但是，对来自汽车产业外部的互联网开发人员，虽然人数巨大（据估计，有100万的从业人员），但如果从事汽车电子软件的开发，却需要了解整车架构及汽车本身的know-how（下图）。这个限制了互联网软件开发人员的选择。

ICT行业与智能硬件的公司，以及芯片公司，也培养了大量的通信精英（移动通信，Wifi，Ethernet 等）和底层BSP或Firmware固件开发团队，他们属于软件团队中最懂电子硬件的人。这部分人将是汽车电子软件开发的最佳人选。但是，对整车架构和汽车本身的know-how的理解（图11），也同样限制了这部分嵌入式软件开发人员能够快速上手。

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

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

三、管理流程升级

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

1、需求管理流程

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

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

智能汽车功能需求 

2、架构设计与接口定义流程

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

3、代码与集成流程

汽车的造型设计形成不同的车型及零部件的Fit和Form。传统的零部件开发模式，不同Fit的零部件的软件代码各不相同。如何有效地重用代码；如何构建软件架构平台；如何将不同代码集成在一起，成为新的挑战。需要新的流程来确保软件代码的重用性及软硬件的集成。

4、产品与项目管理流程

传统的零部件产品与项目常常合二为一。一旦硬件最终认可，软件将随之冻结，直至生命周期的终结。但是，智能车的软件产品却可以随时增加新的功能，形成新的版本，通过远程OTA进行更新。可以想象，未来同一款硬件，将会预装不同的软件版本，在市场上销售。如何管理客户车辆的软件版本，如何管理软件的兼容性，等等，需要新的流程改造。而项目管理，如下图所示，可能会以软件开发管理为主，在硬件产品的生命周期内，通过项目的模式组织软件的交付。

5、售后服务的流程

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

复杂的智能汽车场景 

6、开发工具链的挑战

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

AUTOSAR工具链  图片源自CSDN

四、成本管控方式转变

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

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

软件工程师们将不得不优化软件代码，以适应有限的计算资源。但因为系统的复杂性，这样的后果是，在未来的性能测试中发现各种莫名其妙的问题，导致很难查找根本原因，从而增加了工程成本，甚至延误了产品的上市周期。另一方面，尽管没有找到问题的根源，迫于项目的进度，工程师们也是“拆东墙补西墙”，采用临时方案应对项目的交付，为量产后的产品质量种下隐患，增加了售后服务的成本。

软件工程师不得不压缩他们的代码，确保其足够的小，可以被调入有限的内存运行。代码要足够地精简，确保内存的每一位（Bit）都能被充分利用。如此一来，任何新功能的增加将变得几乎不可能。更有甚者，甚至缺陷的修复也将无从下手，而不得不进行硬件的召回。这些，在增加了工程师成本同时，进一步加剧了公司的售后服务成本，消减了公司的软件销售收入来源。

由于代码的过度优化，会导致后期的代码维护尤其困难。复杂的语句，让后期维护人员不敢有丝毫的触碰。对代码的修改成为每个人心中的噩梦。

过度精简代码，将会很难做到代码的重用及其可移植性。也无法做到功能的预埋。如此一来，唯一的途径是通过OTA进行从上到下的固件和应用软件的更新。从客户成本的角度，浪费了客户的时间，增加了流量成本。从业务的角度，增加了内部的运营成本及软件工程成本。

全生命周期成本 

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

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

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

某品牌汽车OTA升级新闻

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

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

软件产品概念示意图 

五、写在最后

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

汽车生命周期生态链 

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

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

来源：汽车电子与软件 ，作者宋涛