如何成为一名汽车软件工程师？_powertrain body，透彻分析源码

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

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

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

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

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

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

正文

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

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的安全等级。

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

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

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

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
力转向EPS、车身稳定系统ESC、电动刹车助力器eBooster，如果是高级车，还有空气悬架控制器ASC、电动减震控制器（未画出）以及，不属于底盘但是一般都挂在底盘总线上的安全气囊控制器（SRS）。

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

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

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

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-g5N0TjoN-1713484724086)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！