汽车软件开发：目前还存在几大方面的痛点亟待解决？_汽车行业处理设备痛点

最新推荐文章于 2024-11-11 16:14:16 发布

2401_84267735

最新推荐文章于 2024-11-11 16:14:16 发布

阅读量1k

点赞数 7

分类专栏：程序员文章标签：汽车大数据网络

本文链接：https://blog.csdn.net/2401_84267735/article/details/137732353

版权

程序员专栏收录该内容

186 篇文章 1 订阅

订阅专栏

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

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

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

传统上，OEM主机厂更关注的是零部件的成本（Per Unit Cost），软件开发成本更多地是分摊到零部件上。当面对软件供应商提供的软件产品，Unit Cost又将如何定价，又如何转化为可盈利的软件商业模式呢？同样，如果是内部开发的软件产品，开发成本如何摊销？软件资本如何合理配置？因为软件是“柔性”的，当管理不善，软件的开发成本将大大超过了零部件硬件成本的节省。BMW公司的Christian Salzmann曾经提供过一组数据：对于每年需求量为500K的一款ECU，如果每年降低硬件成本20Euro每件，在7年的生产周期内，共计可以节省70MEuro。但是，如果软件开发没有做到更好的重用，却会浪费额外的100MEuro。

另外，“开源节流”，传统的硬件成本的管理模式关注的是“节流”。但是，作为前车之鉴的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、架构设计与接口定义流程*

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

接口定义将由简单的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进行从上到下的固件和应用软件的更新。从客户成本的角度，浪费了客户的时间，增加了流量成本。从业务的角度，增加了内部的运营成本及软件工程成本。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Go语言工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Go语言全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。