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

2401_84253380

已于 2024-04-20 07:26:01 修改

阅读量559

点赞数 22

分类专栏： 2024年程序员学习文章标签：汽车网络

于 2024-04-20 07:26:00 首次发布

本文链接：https://blog.csdn.net/2401_84253380/article/details/137986846

版权

2024年程序员学习专栏收录该内容

109 篇文章 1 订阅

订阅专栏

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

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

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

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

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

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

正文

图2源：信息通信网

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

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

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

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

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

硬件产品的生命周期与软件产品呈现不同的形态 – 硬件产品一旦装配，将伴随着车辆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之类的软件开发测试验证等工具链的引进。