如何成为一名汽车软件工程师？

已剪辑自: https://www.ednchina.com/technews/16005.html

首先谈需求，没有需求就没有V流程后面的设计和测试。先看下需求的标准定义：

引自：ISO/IEC/IEEE 15288:2015(E) terms and definition
requirement：statement that translates or expresses a need and its associated constraints and conditions. 再看图1的需求类别：

• stakeholder requirement(利益相关者需求),
• system requirement（系统需求）,
• software requirement(软件需求) 。

这些需求之间有什么关系呢觉得下图2作了比较清晰的说明，即正向地来说利益相关者先提出了一个大概需求，经与系统，技术反复沟通与反馈，确定了利益相关者需求，再据此确定了系统需求，最后再据系统需求确定了软件需求；反向地来说，具体实现过程中也可能存在软件需求不合理情况，进而依次去更新软件需求，系统需求和利益相关者需求。

其次谈文档规范。认真对待文档规范，你将会有意想不到的收获。软件工程师一般都不喜欢写文档，写了一份又一份，关键最后还可能几乎没人看，但规定要去写那还必须得写，些许无奈。那何不换个角度，先从认真对待开始，接下来就会逐渐思考如何写何写好什么文档模板这么安排知不觉就会去看一些标准规范，通过这些就能逐渐去理解文档的别有用心以及这些模板的由来，一般标准会提供一些参考模板，比如图4（源引自：IEEE Recommended Practice for Software Requirements Specifications，IEEE Std 830-1998）。然后结合自身工作经验，再来理解这些文档，会发现文档不再那么抽象，其实非常科学，非常严谨，最后会学着利用这些文档来帮助自己形成一个更有逻辑更有层次的表达。所以认真对待文档规范（也包括流程），有了这方面的强烈意识，我觉得一方面不管是要符合ASPICE，还要AUTOSAR，应该都可以很快遵循这些规范来指导实践；另一方面也极有助于我们从项目管理和软件工程角度来看待项目。

所以，应该加强从功能层面理解好软件，当然模型或代码层面也很重要，这样宏微观上都能切换自如，软件就会被你玩的溜溜的。

04

技能精进

4.1 软件方面

先谈软件方面，曾经为了了解从软件到硬件的最终执行，我花了几个月听计算机科学课程，从计算导论与C语言基础（北京大学，李戈）：记得当时听明白了计算机硬件如何实现0101，图灵机怎么工作等等，讲得非常精彩。

再到计算机系统要素（Build a Modern Computer from First Principles: Nand to Tetris,希伯来大学）: 记得讲到布尔运算（*两个结论：Any Boolean function can be represented using an expression containing AND and NOT operation. Boolean function can be represented using an expression containing only NAND operations*），寄存器，CPU，汇编语言，编译原理，特别有意思。

最后到数据结构（*清华大学,邓俊辉）：记得讲到搜索算法改进，最终我都买了本邓教授的书。*

整个听课过程下来，虽然我没有做作业，忘了绝大部分，但是我觉得从软件到硬件怎么运行，我基本上有个概念，假如真要我去做这方面的深入，给我时间肯定没问题。

总的来说，从广度上对软件要有一定的认识。当然，从深度上对软件也需要很深的认识。比如：运行时序问题，一定要明白先有谁后有谁；精度（scaling）问题，配置就要求很细致；内联函数问题，使用就要特别小心。

4.2 工具方面

再谈工具方面，以MATLAB/Simulink为例。我个人受益于两方面：一方面是来自同事，有同事的悉心指导和用心分享，也有看同事怎么做的，去模仿学习怎么做，去思考谈论为什么这么做（当然更多时候后者去看去试去悟）；另一方面来自mathworks提供的demo和研讨会视频。比如入门变速箱控制模型时，我就找到了一个特别有用的demo包，如图7示意，通过这个demo包做仿真做调试，这样很快就上手建模操作。另外通过一系列的研讨会视频，很快就入门了MBD，以及如何使用Simulink工具做模型检查，验证与确认等，如图8。所以，把握身边的和 上的，工具肯定没问题。

图8 模型验证的最佳实践

**

本质上就讲理解此公式：

如果还觉得不够的话，那么还可以继续，如图12。（技术真是个黑洞）

**

**

3）专业技术层面

**

中的软件部门组织架构图：

汽车软件开发流程和职位示意

1. 项目组长：负责整个项目的总体规划、任务分配、资源整合、客户对接，定义任务优先级，在技术路线发生争执的时候做出决策，并监督整个项目的进行。用人话讲就是一个“**对外忽悠客户、对内忽悠组员”**的职位。

基本上在软件团队里，这个职位是最好的，但是跟职场新人也是基本上绝缘的。你不把技术、流程用几年时间理清楚，咋能出去忽悠人呢对吧。 所以这个职位新人基本上就不用关心了。

• 成长性： 5
• 知识通用性：5
• 转岗灵活性：5
• 工作成就感：5
• 曝光度： 5
• 工资： 5

综合评价： 5 – 少年你还在想什么呢/strong>

2. 需求工程师：和客户沟通软件需求，讨论确认所有技术细节，并撰写详尽的需求文档。

坦白而言，说需求工程师是一个项目最重要的职位也不为过。一份准确、清晰的需求文档是一个优秀项目的基石，而一个优秀的需求工程师团队更能够直接大幅提升整个项目的效率，甚至能引导整个项目组以最优的路径开发。需求工程师本来应该是由经验丰富的老工程师担任的。

但是呢，需求工程师同时也是一份非常枯燥的工作。平时有一半以上的时间都在写文档。如果你足够不幸， 那还得在一个叫DOORS的挨千刀的软件平台里写，可以写得你怀疑人生。

架构师的常用工具软件：Enterprise Architect

• 成长性： 5
• 知识通用性：4
• 转岗灵活性：5
• 工作成就感：5
• 曝光度： 4
• 工资： 5

综合评价： 4.7 – 和项目组长不相上下的选择

4. 基础软件工程师：其实基础软件工程师还可以再细分。包括软件驱动工程师、通信/诊断工程师等等。驱动工程师就包括Hardware/ECU Abstraction Layer的设计和编程啊、Bootloader编写啊、AutoSAR的配置啊、内存Layout的设计啊、操作系统啊等等，范围很广。而通信诊断工程师就是字面上的意思：负责总线通信接口的配置和诊断的配置。

驱动工程师其实蛮吃香的，尤其现在AutoSAR是个热门，知识通用性很好，因为各个ECU其实驱动部分的开发都差不太多。但是底层软件跟ECU的具体功能离得蛮远，并不容易转成算法工程师。驱动的测试和软件应用层的测试差别比较大，所以也比较难转成整体软件的测试工程师或者测试经理。

另外，虽然知识通用性好，但是驱动工程师的市场需求总体来说是比较小的。因为一个ECU软硬件平台定型以后，基本上驱动部分未来3到5年都不会进行大规模开发了，而是成为一个平台解决方案，被各个项目借用，所以驱动工程师团队并不需要很大，这意味着一旦失业可能还是不如其他职位好找工作。

• 成长性： 4
• 知识通用性：5
• 转岗灵活性：2
• 工作成就感：4
• 曝光度： 3
• 工资： 4

综合评价： 3.7 – 我觉得还行

通信/诊断工程师，这也是我进入汽车行业的第一个职位。怎么说呢。。。真的超级枯燥且没有成就感。这也是我在做了两年多以后选择跳槽的主要原因。通信/诊断容易上手，适合新人。市面上绝大多数车企都用的是CAN通信和UDS诊断协议。如果做德国车企项目的话，再看看FlexRay就可以了。

然而通信/诊断职位在技术上没有太大上升空间，虽然知识通用性很好，不愁找工作，但很难接触ECU的核心功能算法，算是对职业发展有一定的限制。通信/诊断工程师是可以转成测试工程师的，但是几乎不可能成为总体软件的架构师或者项目主管。

而且由于上手快，工资也不是特别有竞争力。

• 成长性： 3
• 知识通用性：5
• 转岗灵活性：3
• 工作成就感：3
• 曝光度： 3
• 工资： 3

综合评价： 3.4 – 有点鸡肋啊，还是尽量转岗吧

5. 应用层软件工程师，在很多公司也被叫做算法工程师或者控制工程师。看过我以前帖子的童鞋都知道，我做过很长一段时间的转向助力算法工程师和制动系统算法工程师。我觉得这段经历是最让我获益匪浅的。

ClearCase, 集成工程师要给每个模块定义好不同的分支和标签，来形成正确的最终软件

系统集成工程师工作比较枯燥，而且系统集成总是发生在软件发布周期的最后，压力超级大。由于集成工程师往往也负责一部分集成测试，所以转做测试工程师/测试经理还挺常见的。另外的职业上升途径就像需求工程师一样，转做质量或者系统工程师。除此之外，转岗并不是很容易。

集成工程师的具体工作很依赖本公司的SCM软件，所以可能在公司A你是ClearCase大神，而转到用PTC Integrity的公司B你就有点蒙圈了（虽然原理都差不多）。知识的通用性不是很好。但是集成工程师往往对软件发布的流程烂熟于心，所以说转去做质量工程师的很多。

• 成长性： 3
• 知识通用性：3
• 转岗灵活性：3
• 工作成就感：2
• 曝光度： 2
• 工资： 3

综合评价： 2.7 – 这个就有点尴尬了

7. **测试工程师，**要细分的话可就多了。至少可以再细分成软件在环(SIL)测试工程师和硬件在环（HIL）测试工程师。对于底层软件的测试，还有PIL（处理器在环）测试工程师。

SIL 测试常用软件 VectorCast

我知道知乎上的测试工程师很多啦，我这么说有点得罪人。但是我观察到的是，新人一旦入了测试工程师的坑并持续三年以上，基本上在这行里就和算法工程师、架构师、项目主管无缘了。我在几个公司的几个产品线做过，还真没听说以上的职位有哪位同事是长期测试出身。欢迎知乎的同学们提出反例。我周围搞测试的同事因为这个原因离职的不少。

转岗的话，测试工程师晋升为测试团队主管是最直接的，其他转需求工程师、质量工程师等等也比较常见。

测试工程师的知识通用性还是很好的，找工作不难，但是工资…嗯，还行吧。

• 成长性： 3
• 知识通用性：5
• 转岗灵活性：2
• 工作成就感：3
• 曝光度： 3
• 工资： 3

综合评价： 3.2 – 少年你打算一辈子献身伟大的测试事业了么/strong>

最后嘛，木城想说，如果你有选择软件部门职位的机会，那h顺序应该是：

项目组长 –> 软件架构师 –> 应用层软件工程师 –> 驱动软件工程师 –> 通信/诊断工程师 –> 测试工程师 –> 需求工程师 –> 系统集成工程师

不知道这个排名跟你心中的排名一样吗/p>

—————————————-番外篇———————————————

有同学留言或者私信让讲一讲功能安全工程师职位，下面我就来说一说这位“外卡选手”。

功能安全工程师，和质量工程师、系统工程师一样，一般是不设置在软件部门里的，但又和软件开发联系非常紧密，所以我说是一位“外卡选手”。

功能安全工程师的主要职责是确保汽车软件的开发全过程符合功能安全规范ISO26262。具体而言就是对软件的开发设定安全目标（Safety Goal）, 对功能进行险象和风险分析HA/RA (Hazard Analysis / Risk Assessment） ，以及编写安全需求，编写functional safety concept，最终形成功能的Safety Case （安全包。

除此之外，功能安全工程师还要领导失效性分析（dFMEA），故障树分析（FTA）等等。安全工程师同时还要参与软件需求和设计的讨论。一句话，安全工程师很忙！

引言

在本篇文章里，我们来探讨一下一位汽车软件工程师的**成长过程，**还是那句话：一家之言，姑妄听之！

想当年还在校园的时候，我们都被安排好了固定的课程和培养方案，一年一年只要按部就班地选课，最后总能拿到那张毕业证、开始人生的下个阶段。即便是研究生时写论文，也总归有大老板/中老板/小老板们给出方向。

等走出了校园才暮然发现，自己再也没有“培养方案”了，每个人的路都是那么的不同，瞬间就被卷在了滚滚红尘之中，零落成泥呀。不过呢少年，既然已经阴错阳差地选择成为了一名汽车软件工程师，那成长道路终归还是有那么一些轨迹可循的。下面我们就来仔细品一品。

由于自动驾驶技术的兴起，汽车软件行业最近正处于一个几十年未见的巨变之中，将来发展的方向仍未可知。但是就未来几年而言，无论你具体从事汽车哪个系统的软件开发，软件的基本构成并不会有太大差异。具体而言可以分成以下几个最重要的模块：

• 传感器软件
• ECU底层驱动
• BootLoader
• 内存管理/内存分配 （Memory Layout）
• 操作系统调度
• 通信模块/通信协议
• 诊断模块/失效管理
• 应用层软件

E/E Architecture

现代汽车里，基本上可以把所有电子部件分成五个控制域：

1. 底盘控制 Chassis Control
2. 高级辅助驾驶系统 ADAS
3. 车机系统 Infotainment
4. 动力系统 Powertrain
5. 车身控制 Body Control

如上图所示，每个控制域之间通过 关由某一种或者几种总线（一般就是CAN/CAN-FD/Ethernet以及欧洲车厂喜欢用的FlexRay）连接，然后域内部再用一条总线把域内控制器互相连接。

我画的图中，动力系统部件用的是新能源车的那一套，对于传统燃油车，你把“电机”换成“发动机”、“变速箱”什么的就行，没有影响。

当然，图示的E/E架构是最简单的情况，工程实际中要复杂的多。比如通用汽车GlobalA架构里，底盘总线就分了HS和CE两条；再比如同一个域内，由于IP保护等原因，一些控制器之间除了公用总线，敏感信 还会通过私有总线连接；至于ADAS系统中，各个控制器间通过Ethernet成 连接的例子也是越来越多。但是呢，万变不离其宗，我们基于图示这种最简单的架构来讨论就足够了。

在开始具体讨论之前，我想提出我自己的“选择控制器的指导思想”，那就是：

• 紧追行业热点
• 关注关键控制器
• 选择安全等级较高的控制器
• 综合考虑就业市场现状

所谓紧追行业热点，就是尽量去现在热钱和政策流入的领域工作。汽车行业现在公认有三大热门领域：**智能驾驶、智能座舱、车路协同（车联 ）。**这些领域所涉及的控制器技术很新（占坑的老油条少）、国外技术壁垒还没有完全建立（中国公司有机会占领更大市场）、人才队伍还在完善（坑多、晋升快）、符合国家政策扶植的发展方向（政策红利）。

所谓关注关键控制器，就是在同一系统中，尽量去起关键作用、应用场景更多的控制器工作。这样未来的职业发展道路才更广阔、在行业里也更有话语权。举个例子，同样是辅助驾驶系统，毫米波雷达就是比超声波雷达更为关键，这个没人反驳吧毫米波雷达系统里，前置雷达（Front Radar）就是比角雷达（Corner Radar）和后置雷达（Rear Radar）更关键。

对于第三条，高安全等级部件的工作流程、质量管理体系确实是要更完善一些，更利于工程师的个人成长。另外，车企招聘之中有一个普遍的心态，就是**倾向于招聘高安全等级零部件出来的人才。**要我说这就是个玄学，你做ASIL D系统的工程师，就一定比做QM系统的工程师更流弊、更严谨个我是不信的。但是事实就是，做制动系统出身的工程师去做车身控制里的雨刷、车窗控制器，应聘就比较容易，而反过来嘛…至少领导会多想想，对不对。

第四点太复杂了，而且瞬息万变，我们得具体情况具体分析。

下面我们一个一个讨论。

1. 底盘控制

底盘控制域主要包括这几种控制器：助力转向EPS、车身稳定系统ESC、电动刹车助力器eBooster，如果是高级车，还有空气悬架控制器ASC、电动减震控制器（未画出）以及，不属于底盘但是一般都挂在底盘总线上的安全气囊控制器（SRS）。

细心的你一定已经看出，在我的图里，底盘域的控制器大部分都标注了红名，意思是这些控制器都要符合ASIL-D的安全等级。

底盘域的控制器几乎都和智能驾驶沾边，这是个加分项。但是作为智能驾驶的执行机构，毕竟扮演的是下位机的角色，并没有起到最关键的作用，所以加分有限。同时，它们都是高安全等级控制器，这是个大加分项。

转向系统：智能驾驶执行的机构、高安全等级，属于传统控制器，控制算法成熟、上手快。高端市场被外资掌控但是新兴挑战者不少，就业市场不错。另外，在细分领域里，有一个热点是“线控底盘”，到转向这就是“线控转向”的攻关，前景也不错。

推荐度：四星 ★★★★

车身稳定系统：这个部件名字很多，采埃孚叫ESC， 博世叫ESP，其他叫法什么VSC、DSC的都有，其实就是制动系统控制器，用来实现ABS/EBD/TCS/VDC之类跟制动相关的功能。ESC也是智能驾驶的执行机构、安全等级高，也属于传统控制器，但是上手很慢。市场基本被几个外资玩家垄断，采埃孚（以前的TRW）、博世、Conti之类的，就业市场也挺好。

ESC有一个问题，就是系统算法太复杂了。可以说ESC的三大模块，