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

本文链接：https://blog.csdn.net/2401_84264408/article/details/137808655

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

图源：瑞萨网站

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

和整个汽车软件关系最大的，可能就是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进行从上到下的固件和应用软件的更新。从客户成本的角度，浪费了客户的时间，增加了流量成本。从业务的角度，增加了内部的运营成本及软件工程成本。

全生命周期成本

这里，我们并不是强调传统的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, 人才储备以及流程制度的建设。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）