前几天回答一个问题，讲述汽车行业的写代码的一些习惯，引来了不少争议，因此今天在这儿谈谈软件在汽车行业的现状。

之前有人问我，汽车行业也有码农吗？

确实，以前机械控制的时代，汽车行业确实没有码农一说，不过电控时代好多年了，而且随着电气化，智能化的深入发展，汽车行业对软件工程师的需求也越来越大。汽车软件属于嵌入式软件开发，跟互联网行业软件开发差别很大。

基于模型的开发MBD

MBD的全称是Model Based Design，基于模型设计能够节省开发时间和成本。MBD 的主要优势在于：

1、图形化设计

汽车软件大部分是基于模型的软件开发。这一点在大公司尤为明显，我们用Simulink将要实现的逻辑用图像的形式表现出来。图形化的设计逻辑明确，清晰，便于交流和维护。对于代码的第一任作者以及以后可能的作者，他们只需要看懂图形，就能知道代码实现了什么功能。而如果不看图，要去重新翻阅成千上百行代码，非常耗时。

对于软件工程师来说，最重要的任务是算法的实现。比如我现在有一个自适应巡航系统，汽车需要根据前车位置，速度来决定自己的跟车速度，以及要不要切换跟车目标，这些“做出决策”的过程就是逻辑判断，都需要软件工程师设计。

2、代码自动生成

在模型开发里，图像化的算法最后依靠工具来自动生成代码。代码效率明显提高，手工代码耗费时间长，且容易出差错。自动代码只要工具好使，就不会有差错，比手工代码质量高。

代码书写标准统一

无论软件是自动代码生成还是手工书写，都需要遵循一定的标准。汽车行业为了规范软件形式，提出了很多统一的代码书写标准，比如我们熟知的MISRA标准。

MISRA C Coding Standard是一个工业标准的C编程规范，全称是 (The Motor Industry Software Reliability Association 汽车工业可靠性联合协会) ，成员包括了大部分的欧美汽车厂商。

这个标准包括了大概100多条C语言编码标准，目的是为了帮助汽车厂商开发出安全，高可靠性的嵌入式软件。有些编码标准让其他行业码农看上去都觉得可笑，比如下面这几条：

Rule 1: 不得使用三元操作符；

Rule2： 所有标识符不得超过31字符；

Rule3：不得残留被注释掉的代码；

Rule4：不得使用goto以及continue；

如果完全按照这个标准来书写代码，则你的代码是可读性强，可靠，可移植性强和易于维护的。遵循这个标准对于代码的质量也能起到很好的管理作用，不过Misra标准过于严苛，一般企业都会根据实际情况执行。

软件架构的统一

代码编写由规范，软件架构就更有统一规范了。

这就是AUTOSAR(AUTOmotive Open System Architecture 汽车开放系统架构)。

AUTOSAR联盟由欧美主要汽车厂商成立，致力于为汽车工业开发一套支持分布式，功能驱动的汽车电子软件开发方法和软件架构标准化方案，也是为了应对越来越复杂的汽车电子系统。在电动化，智能化背景下，汽车ECU日益增多，迫切需要一套全新的整车软件设计标准来应对复杂的设计，使基本的软件元素，接口和总线系统能够实现标准化，降低开发成本。

通过AUTOSAR架构，整车软件对车载网络，系统内存及总线的诊断功能进行深度管理。AUTOSAR的分层设计目标主要有三个：

1、建立独立于硬件的分层软件架构

2、提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU

3、制定各种车辆应用接口规范，作为应用软件整合标准，方便软件构件再不同汽车平台复用

AUTOSAR整体框架为分层式设计，以中间件RTE为界，隔离上层的应用层以及下层的基础软件层。

AUTOSAR的优点在于可以模块化设计，并将“配置”的理念深入到软件开发中，真正让软件变成可设计的，能即插即用的软件结构。

汽车行业与互联网行业软件开发区别

经常看到一些观点说汽车行业是传统行业，保守；互联网行业是新兴行业，创新有活力。

就连同为造车的新公司都忙着和传统汽车企业撇清关系，说我们是造车新势力，互联网公司。

相比互联网行业软件能够快速迭代开发，远程升级；汽车行业只能按部就班走流程来设计软件，因此汽车嵌入式软件是为互联网的码农所不齿的，因为我们开发速度跟不上互联网速度。

想来想去，两个行业的软件最大的区别是什么？是代码数量还是架构不一样吗?这些只是技术层面的东西，我觉的是汽车软件更侧重安全和可靠性。

互联网的软件，如果有bug，只需要后台进行推送更新升级就行，顶多造成使用不方便，一般不会有人生事故和财产损失。而汽车软件是容不下一个Bug，以及任何有歧义的代码。软件有问题轻会影响汽车正常使用，重则会造成生命财产安全。

而且，软件造成的问题后期保养维护很麻烦，需要安排大量人力物力进行售后，这对于汽车公司都是巨大的财产损失。

所以汽车软件必须小心翼翼，按照以下方法来干活：

使用自动代码，因为机器往往比人靠谱，不太会犯错；

即使手工代码，也严格按照汽车行业标准来书写，保证没有歧义，没有意外的情况发生；

在开发过程中，我们也按照ASPICE流程来指导我们的开发和测试，保证软件符合需求，并且质量过关；

同时，汽车软件还有功能安全来进行冗余设计，防止软件可能的故障造成无可挽回的后果。

也就是因为汽车软件开发有这么多条条框框需要遵守，每一个软件使用前都有这么多流程需要走完，因此，汽车软件基本就跟“快速响应”，“迭代开发”这些名词无缘了。

所以我们一直被造车新势力称为“传统造车企业”。

汽车行业软件工程师都是些什么人

目前汽车行业无论是传统ECU开发，混动/电动控制器/自动驾驶都离不开软件工程师。不过汽车行业的码农不同于其他行业，这个行业要求码农们不仅仅要精通代码，还要有以下技能树：

1、对汽车/受控系统要十分了解。无论是传统车还是自动驾驶系统，都需要对汽车有一定的了解，不然无法开发控制算法。而汽车又是个十分复杂的机械系统，不是临时看看资料就能了解的，因此汽车行业的码农都需要有一定的机械学科背景。

2、电学知识。汽车软件要接收来自传感器的大量的外部信号输入，包括各种数字信号（开关信号），模拟信号（传感器值），软件工程师有时候需要对这些值进行滤波，计算，转换为自己有意义的输入。因此对于想加入汽车软件行业的初学者也需要一定的电学基础。

3， 需要标定能力。汽车软件很多算法是无法在开发软件的时候得到，需要后期在实车/Labcar上实验得到。所以汽车软件的标定功能是强于其他行业的，汽车软件工程师也需要一定的标定能力来测试和开发软件。

汽车软件行业趋势

1、 ECU整合度将提升

早在去年，大众就宣布力争让汽车上只有一个ECU。在一些供应商巨头内部，确实也在这么做。特别是在ADAS和自动驾驶下，整合的ECU架构尤为重要。

2、ECU将承载更多的传感器

未来汽车将需要更多的传感器来感知环境，以及保证依靠传感器来保证冗余设计。这对ECU的能力来说也是考验。不过高级算法与机器学习的发展，有望取代一部分传感器，减少传感器数量。

3、汽车以太网发展

长期以来，汽车ECU都是在一个封闭的网络环境下。不过随着智能汽车技术，物联网的发展，很有可能会催生汽车以太网，实现跨域通信。不过如何保证功能安全，这将又是对汽车软件的一大考验。

作者 | 何先生，某汽车公司，前标定工程师，现汽车软件工程师

本文来源于网络，本着学习交流的目的进行转载，已标注原始作者和出处，如存在异议，请联系editor@xingongye.cn。如您对内容有疑问，请告之，以便我们及时处理。