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

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

基于个人工作经验来谈以下几点：

• 汽车软件工程师的最重要技能
• V流程引发的所思所想
• Bug修复引发的所思所想
• 汽车软件工程师如何精进技能

01

汽车软件工程师的最重要技能

人到中年，感觉以前听的大道理都是人生真理，比如"求上得中，求中得下"。先来看参考[1]：

引自[1]: The Most Significant Skills for Automotive Software Developers
Skill 1: Industry Expertise
Software developers in the automotive industry must be familiar with various industry standards. You should know what an infotainment system and a head unit are, what components are behind them, how they can be connected and what forms of data transmission and storage exist. Tier 1 suppliers like Bosch will require hands-on experience in embedded programming. Automakers will also value your ability to develop and test software for ECUs (Electric Control Units) microcontrollers, microprocessors, debuggers, etc. Skill 2: Experience with Large-Scale Projects
In a large scale project, you will be required to communicate and interact with the teams of engineers, designers, testers as well as involved executive managers. If you’re an inexperienced software developer, brace yourself for overwhelming complexity of processes, tight deadlines and multiple interchangeable operations of geographically distributed teams. Therefore, before stepping up into any development activities, it’s better to study the entire structure of an organization, project requirements and only then, narrowing down to your specific job responsibilities. Skill 3: Technology Competency
If you are attentive to details and can demonstrate a good technology competency, you’ll be able to cope with an extensive codebase of an embedded system that can have different versions and modules, their complex logical dependencies and mathematical algorithms. In addition, it will be also valued if you understand how to alter the code to provide new functions without affecting the functionality of existing solutions. The act of balancing between technical requirements, changing business requirements and high standards to the functional safety of any in-vehicle solutions is also a part of this competency you may hardly find in any job description. Skill 4: Communication Skills
Software development in the automotive industry has many factors to consider. Among them are project requirements, project planning, basic architecture, quality requirements and process changes. At every stage of software development, you will have to put into practice your communication skills and professional approach to the entire delivery process including numerous iterations of the same feature. Skill 5: Good Knowledge of English
Frequently, automotive projects are international and people from different countries are expected to have a decent level of English to find a common language with other team members. Besides, your English fluency will be also highly estimated by the management of the project deciding on which IT service company and team to pick up during the tender. Skill 6: Responsibility
New releases in the automotive industry have far-reaching implications. The more features are added, the more complicated the entire embedded system becomes. And most importantly, these are mission-critical systems and any unnoticed mistake may incur more than just repair expenses. Perhaps, you remember a much-talked-of fatal test drive by Uber self-driving car[ that failed to recognize a pedestrian in the darkness. In this case, not only testers but also automotive software developers must have a strong sense of responsibility in terms of the code quality and deadlines. 读懂了么？发现英语重要了吧。目前以我个人经历，我觉得英语的重要性体现在：

1. 标准规范多是英文的，比如ASPICE, AUTOSAR, ISO26262等;
2. 优秀论文多是英文的，比如变速箱控制，自动驾驶，深度学习方面等；
3. 工具文档多是英文的，比如matlab，Vector，Doors等…

不管怎样，让自己的英语越来越好，将会越来越受益。说可能受限于环境，但听读写不限。当然我觉得最重要不是英语，是责任。这里不谈责任，但都源于责任。 接下来我就基于自身作为一个汽车软件工程师的工作经历，从几个角度来分享我的体会。

02

V流程

软件工程师应：

• 具备强烈的需求意识；
• 认真对待文档规范；
• 积极测试。

作为汽车软件工程师，肯定都知道图1的V流程，左边的需求，设计，右边的测试。在工作中，V流程的各环节几乎都做过，很有感触。图1 V流程，引自[2]

首先谈需求，没有需求就没有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作了比较清晰的说明，即正向地来说利益相关者先提出了一个大概需求，经与系统，技术反复沟通与反馈，确定了利益相关者需求，再据此确定了系统需求，最后再据系统需求确定了软件需求；反向地来说，具体实现过程中也可能存在软件需求不合理情况，进而依次去更新软件需求，系统需求和利益相关者需求。

图2 系统需求规范开发流程

软件工程师也许属于图2红圈的一份子吧，当然这里的目的不在于探究细节，通过这个图主要想表达是： 软件工程师应具备强烈的需求意识，不仅仅局限于代码层面，应明白从需求层面到代码层面，只有深入理解了需求，才能写出更加准确精炼的模型或代码。 很多软件工程师也需要写相应的软件需求吧，那么怎样写好一条软件需求呢？我觉得图3是一个很好的推荐.

图3 需求的书写语法

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

图4 从Mode角度组织的软件需求模板

最后谈**测试。**本质上就一句话：纸上得来终觉浅，觉知此事要躬行。从零开始的项目一般还好，边开发边测试；有base的项目，最好得主动多仿真多测试，通过数据和现象来快速理解。说到测试，分享一个小故事：曾经看着德国同事准备集成测试报告的图，类似于下图5，他创建了多个子窗口归类地来分别显示数据，调好数轴标尺等操作，以使得他人一眼就看懂测试结果。当然他就是这么想的，然后我就照学了。看个反例（图6），自行对比感受下。

图5 测试数据整理范例

图6 测试数据整理反例

03

bug修复

“这个bug对功能有什么影响？”，很喜欢听到别人这么问。 这里又想分享一个小故事：看到过有个人解决问题能力非常强，几乎来了一个bug，看看数据看看模型，咔咔两下就给解决了，但我发现很奇怪的现象，这个人天天都有bug要解决。后面不幸让我接手了，发现补丁好多好多，有些还无法追溯。后面又遇到了一位很有要求的同事，每次一有bug就问我**“这个bug对功能有什么影响？”**，刚开始我大概都这么回答“不知道，但代码层面分析了bug的影响和解决方法，该方法不会影响其他代码逻辑，能满足客户的要求，balabala. …该方法”。 故事到这，**首先得从功能层面去分析：这个bug对功能有什么影响？**如果你都不清楚功能，怎么能够确定这就一个bug呢？怎么能够保证修复方案是最佳的呢？怎么能够确保修复后仍满足需求呢？当然要更全面更理想的分析可参见图7。

图7 理想的bug分析流程

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

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。所以，把握身边的和网上的，工具肯定没问题。

图7 变速箱控制的demo

图8 模型验证的最佳实践

****图9 MATLAB/Simulink录制的研讨会

4.3 专业知识

****最后谈专业知识，以变速箱控制为例，变速箱控制目的就是开车的人踩了多大油门或多大刹车，变速箱就要自动地去操作挡位和离合器，让开车的人开加速不错，的很爽，很是舒服（当然不仅仅是变速箱的功劳）。那么怎么实现的呢？比如图10示意一个升档控制过程。

****图10

本质上就讲理解此公式：

就基本可以应付变速箱的离合器控制工作了。再深挖电液系统的话，那么牛顿第二定律和伯努利方程都来了。

****图11 电液控制系统原理图

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

****图12 变速箱系统的知识网络

所以，技术精进不只在于一个点，而在于一个面或一个体，任重而道远。

05

总结

一个人的精力是有限的，上述所说大多数人还是很难做到位。但是不管怎样，一个汽车工程师最好要具备这些意识，不管是重在广博，还是贵在专精，选好自己的方向，认真工作，一定会越来越优秀。 最后引用参考[8]的图，温故下本文的3个层面内容： 1）项目管理与软件工程层面

****图13 V流程和工具链

2）功能与软件实现层面：

****图14

3）专业技术层面

****图15 挂挡控制

参考：

[1] AUTOMOTIVE SOFTWARE DEVELOPER: TOP 6 SKILLS AT A GLANCE, https://www.infopulse.com/blog/automotive-software-developer-top-6-skills-at-a-glance/ [2] Automotive SPICE Process Assessment / Reference Mode, http://www.automotivespice.com/fileadmin/software-download/Automotive_SPICE_PAM_30.pdf [3] Essential aspects of the V-cycle software development process, https://x-engineer.org/graduate-engineering/modeling-simulation/model-based-design/essential-aspects-of-the-v-cycle-software-development-process/ [4] Mathworks官网录制的视频与网上研讨会， https://ww2.mathworks.cn/videos/search.html?s_tid=evmain_rw_bod&q=&page=1 [5] AUTOSAR_Introduction， https://www.autosar.org/fileadmin/ABOUT/AUTOSAR_Introduction.pdf, [6] The Analyzing Method of Root Causes for Software Problems， https://global-sei.com/technology/tr/bn73/pdf/73-13.pdf [7] Estimation of the Clutch Characteristic Map for an Automated Wet Friction Clutch Transmission, https://www.sae.org/publications/technical-papers/content/2016-01-1113/ [8] Model-Based Design Methods for the Development of Transmission Control Systems, https://www.sae.org/publications/technical-papers/content/2014-01-0304/

---

汽车软件行业工程师详细介绍？上

已剪辑自: https://blog.csdn.net/weixin_41542613/article/details/105972802?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-105972802-blog-107409743.pc_relevant_aa&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-105972802-blog-107409743.pc_relevant_aa&utm_relevant_index=1

​ 最近有不少童鞋、特别是初入职场的朋友，向我咨询汽车软件工程师的职业发展与选择。刚好我想写一篇文章谈谈这个问题，顺便写一些自己作为软件工程师和项目主管这些年来的职场感悟，最后给出一个非常主观的选择排行。

​ 入行这些年，我阴错阳差地当过通信诊断工程师、算法工程师、需求工程师、测试经理，现在是项目负责人，带着一个美、德、印三地十来个工程师的软件工程团队。也算是有一定发言权吧。可能有些观点大家不一定赞同，就算是我抛砖引玉，还望轻拍。

一、汽车软件工程师的职位都有哪些啊？我应该怎么选？

​ 首先要澄清一个错误的观念，那就是：**不是只有写代码的工程师才叫软件工程师！**事实上，车企（零部件企业也好、主机厂也好）的软件部门里，有一半以上的工程师是不写代码的，但是职位也叫“软件工程师”。

这里借用一张我的老帖

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

软件部门组织架构

一个汽车软件部门，至少要有以下几种职位：

1. 项目组长
2. 需求工程师
3. 软件架构师
4. 基础软件工程师
5. 应用层软件工程师
6. 系统集成工程师
7. 测试工程师

那么对新人而言，究竟什么是好的职位呢？我觉得可以从以下几个维度来考察：

• 能常常学到新知识（成长性）：这个不说了，新人最重要的是学习
• 学到的知识在行业里有通用性： 这样才好找下一份工作不是？
• 职位有灵活性，容易转岗：谁也不会在一个职位上干一辈子。
• 工作过得舒心，同事能尊重，自己有成就感
• 在公司里有曝光度，老板、同事能看得见你的工作：升职快啊。
• 钱多：简单粗暴。

还有一个维度是工作的稳定性，但是我个人认为这些职位的稳定性都差不太多，而且现在企业裁员都xjb裁，谁去谁留真的不好说，跟员工个人也有很大的关系。所以这个维度就不比较了。

我们现在一个一个说。

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

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

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

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

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

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

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

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

IBM 需求管理软件DOORS

技术大牛们当然是不屑于写文档的啦！所以国内外的现状就是“鸠占鹊巢”：技术大牛负责和客户沟通需求，而需求工程师们退化成了一帮“打字员”，只是记录技术大牛的讨论和设计，把它们被动地变成需求文档。

于是需求工程师往往就由新人来担任，在外企的话，甚至整体外包到印度、越南、罗马尼亚等等低工资国家去完成。由于新人或者外包团队对产品理解有限，往往写出来的需漏洞百出，于是被大牛怼简直是需求工程师的常态…总而言之这简直是软件团队里最糟糕的一个职位。

由于需求工程师不接触代码，也不接触算法细节，很难转岗到别的职位。需求工程师的成长路线往往是向系统工程师、质量工程师、安全工程师上靠，最终脱离软件部门。另外，非常优秀的需求工程师也是有机会成为项目主管的，但往往这种优秀工程师都不是一毕业就做需求出身。

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

综合评价： 3 – 短期做做挺好，别做久了！

3. **软件架构师：**负责软件架构设计，明确各个软件模块之间的接口，并且负责操作系统的配置和调度。

这又是一个和新人无关的岗位。不多说了。能干这个都是技术大牛，甚至比项目主管还牛，因为毕竟不是每个搞技术的人都想去做撕逼抢资源的协调工作。

软件架构师转项目主管是理所当然的事，甚至在不少项目里，架构师本身就是项目主管的备份。架构师几乎可以转软件部门的任何职位。

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

应用层软件工程师的主要工具之一：Matlab/SimuLink

应用层软件，算是ECU软件核心中的核心。无论是什么控制系统，都可以通过对应用层软件的设计获得非常深刻的理解，成长性自不必说。对于通用性而言，只要是算法工程师，招聘时候并不太关心你以前是不是做同一个ECU的，因为应用层软件都有它的相似性。但是有一点需要注意，那就是ECU的安全等级。

总体来说，高安全等级ECU （比如转向、制动、安全气囊控制器）的应用软件工程师，比低安全等级ECU（车载娱乐系统、车身控制——雨刷、车窗等等）的工程师，在找工作的时候有更大的优势。这一点我们可以后续再谈。

成就感爆棚也是应用层软件工程师的一个特点。应用层软件工程师基本上都有机会实车测试并调试自己写的算法。看着自己的算法从一行行冰冷的代码，变成能够跟驾驶员交流的实际功能，这种成就感是其他工作（哪怕是项目主管）都很难带来的。

另外，由于应用层软件工程师需要参与V型流程的全过程，基本上可以转成任何其他的岗位，转型架构师或者项目主管也是水到渠成的事。

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

综合评价： 4.5 – 对于职场小白最好的出道选择！没有之一！

6. 系统集成工程师，负责将每个工程师的软件变更正确地集成在一起，形成新的发布软件。系统集成的具体工作就涉及到SCM (Software Configuration Management) 的部分了，比如有的公司用SVN，新潮一点的公司用git ， 还有的公司用一些奇奇怪怪的工具(ClearCase, AllChange…) 等等等等。一般而言，除了巨无霸公司有专职的系统集成工程师，一般这个职位是其他工程师兼任的。

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

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

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

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

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

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

HIL测试工程师的好伙伴：dSPACE Control Desk

至于测试工程师嘛…真的是个一言难尽的职位。

首先有经验的测试工程师对整个项目而言是非常重要的。由于“V”型开发流程的存在，测试工程师甚至能通过“评价软件需求”和“讨论测试用例”两个流程来左右软件的设计。但是呢，通过我多年的观察，测试工程师一般是处在软件开发鄙视链的下层…

SIL 测试常用软件 VectorCast

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

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

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

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

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

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

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

不知道这个排名跟你心中的排名一样吗？

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

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

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

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

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

dFMEA工具 IQ-RM

功能安全工程师一般是由具有多年经验的其他职位的工程师转岗而来，毕业直接当安全工程师的也有，但机会很少。安全工程师一般是讨论会上说“不”的那个人，所以小白根本镇不住场子。新人做安全工程师的话，最开始的两年肯定要有老师傅带，而且会经常被人怼，不过熬过了这段时间就好了。成长性还是很高的，5分。

不同零部件的功能安全分析原理上是一样的，而且涉及到具体功能往往有相关的算法工程师协助，所以知识的通用性很好，找工作很容易。而且现在功能安全是热点，有3年以上工作经验（度过了前两年“尴尬期”）的安全工程师在市场上很吃香，不愁找不到工作。知识通用性非常高，5分。

安全工程师转岗比较难，基本上入了安全的坑就出不去了。当然，想硬转还是可以的，但是收入往往会下降。灵活性3分。

工作成就感嘛….主要就是在写文档和开会，其实成就感一般，给4分吧。

曝光度…安全工程师的曝光度那是相当的高啊，整天跟各个部门的经理、技术大拿开会，绝对是公司的明星， 5分。

工资嘛，安全工程师的工资相对还是比较高的，4分吧。

如果说需要注意的地方，那就是，小白们**不要去小厂当安全工程师！**安全工程师基本上没有教材可循，都是靠企业内训和师傅手把手教。去了小公司，内训一团糟，流程又混乱，可能教你的师傅自己对ISO26262的理解都不到位（这种情况非常普遍）。

比如我面试的时候喜欢问安全工程师一个很基础的问题：我们经常说"我需要一个ASIL B的信号"，你能不能解释一下到底什么是ASILB的信号？这种提法有没有问题？ 还真不是每位安全工程师都答得上来。

在这种环境里待几年，好的东西没学到，坏毛病学一身，以后再找工作就难了。

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

综合评价： 4.3 – 真遇到了就从了吧！

汽车软件行业工程师详细介绍？中

引言

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

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

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

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

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

汽车ECU软件架构示意

基于这种软件模块的划分，根据自己的经验，想成为一个优秀的软工程师，我认为需要经历三个阶段:

1. 某一模块的专才
2. 在擅长某一模块的基础上，对软件整体比较熟悉
3. 技术管理人才

某一模块的专才：

这是汽车软件工程师的第一阶段。初出校园的时候，我们总是从接触某一个具体模块开始职业旅程的。比如通信/诊断工程师，自然就开始接触通信、诊断模块。而应用层工程师会从应用层中的某个具体功能入手。

即便是需求工程师或测试工程师，也会先负责某个具体模块的需求或者测试工作。

在这一阶段，小白们需要做的是迅速掌握自己的模块。对于通信/诊断工程师而言，这个过程比较轻松，半年到一年足够了。所以我在上篇文章里说这个职位很好上手；但是对于应用层软件的工程师而言就比较蛋疼了，真正上手某个功能模块可能会持续一年以上，甚至两到三年。因为应用层软件耦合性很强，往往要对整个应用层都有了解，才能做好其中某个模块的开发。

测试工程师也是同样道理，上手会比较慢一些。

总而言之，这一阶段一般是职业生涯的第一到三年，也是每个工程师都要经历的阶段。

在擅长某一子系统的基础上，对软件整体比较熟悉 ：

职业的成长在这一阶段发生分化了。

在熟悉了自己的模块以后，我的建议是一定要抓住各种机会，对汽车软件的所有关键模块都有了解。只有这样才能进一步提升自己综合解决问题的能力，使自己的价值获得进一步提升，为以后成为架构师或者技术管理人才做准备。

测试/诊断工程师和驱动工程师第一个死在这一关。因为他们没有什么好的机会去深入了解别的模块。如果企业比较开放的话，可以多去读别的模块的需求和代码, 然后多向其他工程师请教，这就看少年你自己的技巧了。如果可能的话，这个时候也可以考虑转岗。

需求工程师和测试工程师情况稍微好点，也赶紧开始行动吧。

对于应用层软件工程师而言，此时就可以堂而皇之地熟悉各个部分的功能和代码，梳理整个软件的内在关联。你们有足够多的机会对整体软件都有了解。所以我说应用层软件工程师的成长性和灵活性是最好的。

除了对软件本身的了解，在这个阶段也要尽量熟悉功能安全。说功能安全是现在全行业最热的话题也不为过，一定不要觉得自己不是安全工程师就不需要去了解它。熟悉功能安全也能显著地提升软件工程师的竞争力。

如果顺利的话，这个成长的第二阶段会是你职业生涯的第二到五年。

有的同学会说，我就想做个螺丝钉，干好自己的本职工作，也不想做管理，熟悉好自己的模块不就完了吗！这个说法我觉得没毛病，但是呢，如果对整体软件都熟悉，第一是可以显著提升你自己在就业市场上的竞争力，同时肯定能够反哺你自己的模块，让你做得更优秀。我始终觉得这是职业成长必不可少的。

职业成长的第三个阶段是技术管理人才

在经历了第二阶段以后，一小部分工程师会进入职业生涯的第三阶段，也就是成为项目主管。可以说，这是一个全新的职业阶段，除了软件工程师本身的工作以外，项目主管还要肩负很多新的挑战，包括并不限于：

• 软硬件选型
• 客户沟通
• 招投标/报价/谈判
• 项目管理
• 团队管理
• 功能安全
• 信息安全
• 质量管理
• 法务、合规

可以说至此已经不再工作在软件开发的第一线了。

如何从第二阶段进入第三阶段是个玄学问题。常见的方法有祈祷公司开展新业务、祈祷原项目主管跳槽/高升（大雾…）、换去新部门、换公司等等，总之就是可遇而不可求了。前些年中国的汽车软件行业发展蓬勃，从无到有、从弱到强，只要有心，跨入第三阶段也是不难的。现在行业整体不景气，加上汽车软件行业的从业人员越来越多，确实要麻烦了些，但比起国外还是容易的。

汽车软件行业工程师详细介绍？下

已剪辑自: https://blog.csdn.net/weixin_41542613/article/details/107409743

在这个系列的第一篇文章 木城：听说你想做一个汽车软件工程师？（上）里，我们讨论了汽车软件工程师都有哪些职位。但是，就算是同样一个职位，比如“诊断工程师”吧！你给ADAS系统做诊断，和给乘用车柴油发动机控制器做诊断，工作内容几乎是完全一样的，但是职业发展前景可能会有天壤之别。

于是在这篇文章里，我想进一步探讨一个问题：现在汽车电控部件这么多，我该做哪个部件的开发工作？

其实现在整个汽车行业正在经历…不能说是“严冬”吧，至少也是“秋意正浓”的时期，工作机会比前两年少了不少，能有一个份工作就不错了，还要啥自行车啊。不过呢，如果你有志成为一个汽车软件工程师，而又有好几份截然不同的offer放在你面前，那么希望这篇文章对你有所启发！

要谈汽车电控零部件，不得不从电子电器架构（E/E Architecture）说起。下图就是一个简单的我自己画的新能源智能车的电子电器架构示意图：

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的三大模块，ABS/TCS/VDC ，每块拿出来复杂程度都堪比整个助力转向控制算法。所以说ESC领域很吃经验，成长相对较慢，比如在EPS算法领域工作五年就可以算是大半个专家了，而ESC的话…五年可能刚刚融汇贯通，还很难做到独当一面。

推荐度：三星半 ★★★☆

电动刹车助力器：这个部件用电机替代真空刹车助力，名字也很多，学界有些叫它e-Booster，采埃孚把e-Booster和ESC集合在一起叫IBC（Integrated Brake Control）， 博世叫iBooster （博世也有类似IBC的产品）。这个部件比较新，技术相对简单，涉及“线控底盘”这个热点，有高功能安全等级。目前市场基本是被博世把持吧?但是国内做这一块的厂家也开始出现。

电动刹车助力器的工作有一个硬伤：它不是关键控制器。制动系的关键控制器是ESC，其他如eBooster、EPB(电子手刹) 更多的是配合ESC工作，所以不那么推荐。

推荐度：三星 ★★★

安全气囊控制器：SRS还是挺不错的部件，高安全等级，有成熟的市场。虽然是传统控制器了，但是随着自动驾驶车辆的出现，无方向盘、对向布置座椅等等这些车身结构的改变会催生出新一代安全气囊产品，还是有前途的。

推荐度：三星半 ★★★☆

**其他底盘相关控制器：**其他控制器还包括空气悬架控制器、电动减震控制器、电子手刹、方向盘角度传感器、车速传感器等等，这些控制器要么没有功能安全等级，要么不是关键控制器等等，前景不如前面提到的好，这里就不作过多分析了。

推荐度：两星 ★★

2.辅助驾驶

辅助驾驶域，尤其是L2辅助驾驶现在可谓红得发紫。反倒是L3/L4开始有那么一丝寒意了。ADAS是超级大热门，未来AEB/LKA这些功能肯定会慢慢变成新车强制功能，前景可谓大好。可以说，跟辅助驾驶相关的职位基本上都是推荐的。辅助驾驶域的控制器包括摄像头系统、毫米波雷达系统、超声波雷达系统以及L3/L4自动驾驶里应用的激光雷达。

**摄像头系统：**摄像头系统包括前置单目/双目摄像头、后置摄像头和环视摄像头。一般构成一套最简单的ADAS系统也需要采用1R1V，也就是一个前置毫米波雷达和一个前置摄像头。摄像头可以说是ADAS系统核心中的核心。多的我也就不说了，看看现在一个计算机视觉/自动驾驶工程师的市场价吧…

推荐度：五星 ★★★★★

**毫米波雷达系统：**毫米波雷达可以分成长距、中距和短距等多种。ADAS系统除了最简单的1R1V布置，还可以有复杂一些的比如5R1V系统 （一个前置长距雷达、两个中距角雷达、两个后置中/短距雷达+前置摄像头）等等。其中长/中距前置雷达是实现AEB功能最主要的部件，是ADAS系统中最关键的部件之一。另外，现在量产的毫米波雷达系统可以达到至少ASIL-A的功能安全等级，所以也属于具有一定功能安全等级的部件，同时它又是大热门，也是本土公司在技术上大力追赶的部件，前景是非常好的。

和摄像头系统的工作相比，我少给了半星，那是由于计算机视觉的工程师除了在汽车行业混，还可以去其他应用摄像头的行业，比如安防甚至互联网企业。所以雷达系统工程师出路还是比摄像头系统窄一些的。因此减半星吧。

推荐度：四星半 ★★★★☆

**超声波雷达系统：**超声波雷达最主要的应用场景还是局限在“自动泊车”这一个功能上。当然，换道辅助以及极低车速下的自动驾驶场景中也应用了超声波雷达，不过还是不能改变超声波雷达“非关键控制器”的地位。和其他传感器相比，超声波雷达的应用场景有限，所以算法复杂度不及毫米波雷达系统和摄像头系统。

推荐度：三星半 ★★★☆

激光雷达系统太小众了，我也没从事过， 跟那个组的人也不熟，也就没啥好推荐的了。

除了这几个系统，我还想聊聊ADAS域控制器。域控制器的存在，实际上只是把摄像头、雷达的算法集合在一起的一个硬件载体。所以说并不存在一个工作是单独研究什么域控制器算法的。它的本质还是图形识别、雷达信号识别、路径规划和车辆运动控制（VMC）这些原本在摄像头控制器或者雷达控制器里运行的算法，只是放在一块PCB板上，传感器融合能做得好一点。