汽车电子这个领域外行看着是一堆黑盒子内行看着是一张密密麻麻的网。我干了十多年汽车电子从最早的纯CAN总线节点到后来带OTA的域控制器踩过的坑比写过的代码还多。这篇东西不是教科书是我自己这些年攒下来的实战笔记围绕ECU、CAN、OTA、BCM这几个核心词把汽车电子里最常打交道的东西掰开揉碎讲清楚。不管你是刚入行的测试工程师还是想从消费电子转过来的嵌入式开发或者是修车铺里想搞明白CAN报文的师傅看完应该都能有点收获。我会尽量说人话把那些看起来高深的协议、流程、工具用实际项目里的例子讲明白。1. 从一根双绞线说起CAN总线的物理层与仲裁机制很多人学CAN上来就看报文格式结果连为什么用双绞线、为什么终端电阻是120欧姆都说不清楚。我见过太多人调试CAN通信失败最后发现是终端电阻没接对或者线束分支太长。这一章就把CAN的底子讲透。1.1 CAN收发器原理图里藏着的门道CAN收发器是连接控制器和总线的桥梁。你去看任何一个CAN节点的原理图核心就是一颗收发器芯片比如TJA1042、TJA1050这些。它的作用很简单把MCU的TTL电平转换成CAN总线的差分信号反过来也一样。差分信号是CAN抗干扰的关键。CAN_H和CAN_L两根线显性电平逻辑0时CAN_H大约3.5VCAN_L大约1.5V压差2V隐性电平逻辑1时两根线都在2.5V左右压差0V。这个压差就是接收端判断逻辑的依据。为什么用差分因为汽车里电磁环境极其恶劣点火线圈、电机、继电器都在制造噪声。差分信号在两根线上感应到的噪声是共模的接收端只取差值噪声就被抵消了。这跟平衡音频线抗干扰是一个道理。实际画原理图的时候有几个地方特别容易出错。第一收发器的VCC去耦电容必须靠近芯片引脚通常放一个100nF加一个10uF。第二CAN_H和CAN_L之间的终端电阻在总线两端各放一个120欧姆中间节点不要放。第三TVS管的选择很讲究要选结电容小的否则会影响信号边沿。我见过有人用普通的TVS结果500kbps的波特率下波形直接畸变通信时好时坏。注意终端电阻不是随便放的。如果你在台架上搭一个只有两个节点的测试系统两端各一个120欧姆并联后总线负载就是60欧姆。如果你只在一端放反射会非常严重短距离可能勉强能通长距离必挂。1.2 仲裁机制为什么CAN没有主从却有优先级CAN最精妙的设计就是非破坏性仲裁。总线上没有主从设备谁想发就发但怎么解决冲突靠ID。CAN的ID不仅标识消息内容还决定优先级。ID数值越小优先级越高。仲裁发生在报文起始的仲裁段每个节点一边发ID一边监听总线。如果自己发的是隐性1但总线上是显性0说明有更高优先级的节点在发自己立刻退出转为接收。退出后不会破坏已经赢得仲裁的报文所以叫非破坏性。这里有个细节很多人搞混CAN标准帧是11位ID扩展帧是29位ID。标准帧的仲裁段包括11位ID和RTR位扩展帧包括11位基本ID、SRR位、IDE位、18位扩展ID和RTR位。RTR位用来区分数据帧和远程帧。远程帧就是请求别人发数据现在用得很少了但有些老ECU还在用。SRR位是扩展帧里的替代远程请求位它永远是隐性。IDE位区分标准帧和扩展帧显性表示标准帧隐性表示扩展帧。这些位在报文解析的时候必须搞清楚否则你解析出来的ID就是错的。我实际调试中遇到过一个经典问题两个节点ID设成一样了而且都在发数据。结果总线上波形乱七八糟用CAN分析仪抓包发现错误帧暴增。后来查出来是产线烧录的时候ID配置错了。所以量产阶段一定要有ID唯一性检查。1.3 位定时与采样点通信不稳定的隐形杀手CAN的位定时参数如果配错通信距离一长或者节点一多就开始丢帧。位定时把每个位分成四个段同步段、传播段、相位缓冲段1、相位缓冲段2。采样点就在相位缓冲段1结束的位置。采样点位置通常设置在75%到80%之间。为什么因为信号在总线上传播有延迟收发器也有延迟采样点太靠前会采到还没稳定的电平太靠后则留给相位缓冲的余量不够。对于500kbps的波特率一个位是2微秒采样点放在1.5到1.6微秒的位置比较合适。传播段和相位缓冲段的长度要根据总线长度和节点数量来算。总线越长传播延迟越大传播段就要越长。我一般用这个经验公式估算传播延迟ns约等于总线长度米乘以5。比如40米总线传播延迟约200ns。再加上收发器延迟约100到200ns和控制器延迟总延迟要能在传播段里容纳。实际配置的时候用工具算比手算靠谱。但你要知道工具算出来的参数为什么是那个值否则出了问题不知道怎么调。我见过一个项目CAN通信在实验室好好的装车后偶发丢帧。后来发现是线束长度比实验室长了十几米采样点没调相位缓冲余量不够。把采样点从75%调到80%就稳了。2. ECU内部到底在跑什么从BCM看车身控制器的软硬件架构ECU是汽车电子的基本单元。很多人以为ECU就是个单片机加几个驱动实际上现代ECU的软硬件复杂度远超想象。这一章以BCM为例把ECU的里里外外讲清楚。2.1 BCM的硬件构成与典型输入输出BCM是车身控制模块管的是车门锁、车窗、灯光、雨刮、防盗这些。它通常挂在CAN总线上同时可能还有LIN总线连接一些子节点比如雨量传感器、车门模块。硬件上BCM的主控一般是32位MCU比如NXP的S32K系列、瑞萨的RH850系列。为什么不用更便宜的8位机因为BCM要处理CAN通信、LIN通信、多路PWM输出、ADC采样、休眠唤醒管理还要支持OTA8位机根本扛不住。输入通道包括数字输入车门开关、灯光开关、模拟输入雨量传感器、光照传感器、CAN/LIN通信输入。输出通道包括高边驱动灯泡、电机、低边驱动继电器、PWM输出车窗调速、灯光调光。这里有个设计细节高边驱动和低边驱动的选择。高边驱动接在电源和负载之间负载另一端接地。低边驱动接在负载和地之间负载另一端接电源。车身控制器里高边驱动用得多因为这样负载的一端可以直接接地线束简单而且发生对地短路时驱动芯片能保护。但高边驱动芯片贵低边便宜。所以你看BCM原理图大电流的灯光、电机基本用高边小电流的继电器线圈可能用低边。2.2 休眠唤醒策略静态电流是怎么被抠出来的整车静态电流是个硬指标一般要求低于某个值比如20mA甚至更低。BCM作为常电节点它的休眠策略直接决定整车能不能达标。BCM的休眠条件通常是所有输入无变化、CAN总线静默、内部定时器超时。满足条件后MCU进入低功耗模式外设断电只有少数唤醒源保持工作。唤醒源包括CAN总线活动、LIN总线活动、特定数字输入比如车门开关、内部RTC定时唤醒。这里有个坑CAN收发器在休眠时如果还处于正常工作模式它会消耗电流。所以要用带休眠功能的收发器MCU进入低功耗前把收发器切到休眠模式。但收发器休眠后CAN总线上的活动怎么唤醒它收发器有唤醒引脚检测到总线活动后拉高唤醒MCU。这个唤醒逻辑要仔细设计否则要么唤不醒要么误唤醒。我做过一个项目BCM装车后静态电流超标。查了半天发现是某个数字输入引脚内部上拉一直开着外部开关断开时引脚被拉到高电平但开关闭合时拉到地这个变化被误判为唤醒信号。后来把内部上拉改成只在需要的时候开问题解决。提示休眠唤醒测试一定要在整车所有节点都接上的情况下做。台架上只有BCM一个节点总线静默条件很容易满足装车后其他节点还在发报文BCM永远进不了休眠。2.3 诊断与故障管理UDS在BCM上的落地现代ECU都要支持UDS诊断。BCM上的UDS服务包括会话控制、安全访问、读写DID、例程控制、DTC读取和清除。DTC是诊断故障码。BCM会监控自己的输入输出发现异常就记录DTC。比如某个灯泡开路高边驱动芯片会报故障BCM把这个故障映射成对应的DTC存起来。诊断仪通过UDS读DTC就能知道哪个灯坏了。DTC的状态位很重要。一个DTC有多个状态位testFailed、confirmedDTC、pendingDTC、testNotCompletedThisOperationCycle等。testFailed表示当前测试失败confirmedDTC表示故障已经确认pendingDTC表示故障正在确认中。诊断仪读到的DTC状态不同维修策略也不同。我见过有人修车读到一个pendingDTC就换零件结果换完发现故障还在。其实pendingDTC只是说这个故障发生了一次但还没确认可能是偶发。正确的做法是看confirmedDTC或者看故障发生时的冻结帧数据。冻结帧是DTC发生时记录的环境数据比如车速、发动机转速、电池电压。这些数据对定位故障原因非常有用。BCM的冻结帧一般记录故障发生时的输入输出状态、电源电压、温度等。3. OTA升级从云端到ECU的完整链路与踩坑记录OTA是现在汽车电子的热词但真正把OTA做稳的团队不多。这一章把OTA的完整链路拆开从云端打包到ECU刷写把每个环节的坑都摆出来。3.1 OTA全量包与差分包的选择逻辑OTA包分全量包和差分包。全量包包含完整的固件镜像差分包只包含新旧版本的差异部分。全量包的优点是简单可靠刷写逻辑就是擦除再写入。缺点是包大下载慢对存储空间要求高。差分包的优点是包小下载快节省流量和存储。缺点是生成差分包的算法复杂刷写时要先读旧固件、打补丁、再写入逻辑复杂出错概率高。怎么选看场景。如果ECU存储空间足够网络条件好用全量包省事。如果ECU存储紧张或者网络流量贵比如通过蜂窝网络升级用差分包。但差分包有个前提必须知道ECU当前运行的固件版本而且这个版本必须是差分包的基准版本之一。如果ECU里的固件被改过或者版本不在基准列表里差分包就刷不进去。我实际项目中乘用车的座舱域控制器用差分包因为固件大全量包动辄几个G。而车身控制器固件小几百K到几M直接用全量包省得搞差分逻辑。差分包的生成算法常见的有bsdiff、hdiffpatch。bsdiff生成的文件小但内存占用大hdiffpatch内存占用小但压缩率略低。嵌入式环境一般用hdiffpatch因为ECU内存有限。3.2 OTA升级流程的每个阶段与失败回滚一个完整的OTA流程包括版本检查、包下载、包校验、刷写准备、刷写、刷写后校验、激活、回滚如果失败。版本检查云端对比ECU当前版本和目标版本决定推全量还是差分。这里有个坑ECU上报的版本号必须准确。我见过ECU版本号在某个条件下上报错误导致云端推了不匹配的差分包刷写直接失败。包下载ECU通过车载网络比如以太网、CAN FD从网关或T-Box下载包。下载过程中要支持断点续传否则网络一断就得重来。下载的包要存到ECU的备份区不能覆盖当前运行区。包校验下载完成后ECU要对包做完整性校验通常是CRC32或SHA256。校验不通过就丢弃重下。这里要注意校验算法要和云端一致否则永远校验不过。刷写准备ECU进入刷写模式关闭无关任务确保电源稳定。刷写过程中如果掉电ECU可能变砖。所以要有掉电保护机制比如双备份区或者刷写前先把引导程序锁死。刷写把包写入目标区。如果是全量包直接擦除写入。如果是差分包先读旧固件到内存打补丁生成新固件再写入。差分刷写对内存要求高因为要同时容纳旧固件、补丁、新固件。刷写后校验写入完成后再读出来算一遍校验值和预期比对。不通过就触发回滚。激活校验通过后设置启动标志下次重启从新固件启动。回滚如果激活后新固件启动失败或者看门狗超时引导程序要能切回旧固件。回滚的前提是旧固件还在所以刷写时不能擦除旧固件除非新固件已经确认稳定运行。我踩过最大的坑是差分刷写时内存不够。ECU的RAM只有几十K旧固件几百K根本放不下。后来改成流式打补丁边读边打边写才解决。但流式打补丁对Flash的读写时序要求很高搞不好就写坏。3.3 OTA提取器与镜像分析逆向理解升级包OTA提取器这类工具用途是从OTA包或者ECU里把固件镜像提取出来。做逆向分析、故障定位、版本对比的时候很有用。提取器的工作原理一般是解析OTA包的格式找到固件镜像的偏移和长度把镜像dump出来。不同厂商的OTA包格式不一样有的用标准格式比如UPTANE有的用私有格式。私有格式就得靠逆向。提取出来的镜像可以用binwalk分析看里面有哪些文件系统、压缩段、签名段。也可以用IDA或者Ghidra反汇编看固件里跑了什么逻辑。我一般用提取器做几件事第一对比两个版本的固件看改了哪些函数评估升级风险。第二从旧固件里提取标定数据刷到新固件里避免标定丢失。第三分析固件的启动流程找到引导程序和应用程序的分界方便做双备份。注意OTA提取器只能用于合法的逆向分析和故障定位。未经授权提取和修改他人固件是侵权的。自己项目的固件随便折腾别人的固件别碰。3.4 基于ESP32的OTA实践从IDF到量产ESP32在汽车电子里用得越来越多比如做蓝牙钥匙、胎压监测、车载传感器节点。ESP32的OTA功能很成熟IDF里直接有API。ESP32的OTA分两种通过WiFi的OTA和通过其他接口的OTA。汽车里一般不用WiFi而是通过CAN或者串口把固件传给ESP32然后ESP32自己刷自己。IDF里的OTA流程调用esp_ota_begin开始然后esp_ota_write分块写最后esp_ota_end和esp_ota_set_boot_partition。写的时候要注意分区表OTA分区要足够大能放下新固件。我做过一个项目ESP32通过CAN接收OTA包。CAN一帧最多8字节固件几百K要传几万帧。传输效率很低而且容易丢帧。后来改成CAN FD一帧64字节效率提升8倍。再后来直接用串口速度更快。ESP32 OTA的坑第一分区表要提前规划好OTA分区和工厂分区要留够。第二写Flash的时候要关中断否则时序会乱。第三OTA完成后要重启重启前要确保所有外设都关了否则可能启动失败。4. CAN报文解析与DBC从原始波形到可读信号CAN报文解析是汽车电子工程师的基本功。这一章把报文解析的完整流程讲清楚包括DBC文件的编写和使用。4.1 CAN报文的结构与解析工具的选择一个CAN报文包括帧起始、仲裁段、控制段、数据段、CRC段、ACK段、帧结束。数据段最多8字节CAN FD最多64字节。解析报文就是把数据段里的字节按DBC定义的规则转换成物理值。比如一个字节表示车速DBC里定义偏移量、因子、单位解析出来就是km/h。解析工具分两类硬件工具和软件工具。硬件工具比如创芯科技的CAN分析仪、Vector的VN系列。软件工具比如CANoe、CANalyzer、SavvyCAN、BUSMASTER。创芯科技的CAN分析仪我用过性价比高支持CAN和CAN FD配套软件能发能收能解析DBC。Vector的CANoe功能最强但贵一般OEM和Tier1用得多。SavvyCAN是开源的功能够用适合个人和小团队。选工具看需求。如果只是抓包看报文便宜的CAN卡加SavvyCAN就够了。如果要仿真、自动化测试、诊断得上CANoe。4.2 DBC文件详解信号、报文、节点的定义规则DBC文件是CAN数据库文件定义了总线上有哪些节点、每个节点发哪些报文、每个报文里有哪些信号、每个信号的起始位、长度、字节序、因子、偏移、单位、取值范围。写DBC最容易出错的地方是字节序。Motorola和Intel两种字节序搞反了解析出来的值完全不对。Motorola是大端高位字节在前Intel是小端低位字节在前。汽车里Motorola用得多但也不是绝对。起始位的定义也容易混。DBC里的起始位是从报文数据段的第一个字节的最高位开始算还是最低位开始算取决于字节序。Motorola的起始位是MSBIntel的起始位是LSB。写DBC的时候一定要和通信矩阵对齐否则解析全错。信号的长度、因子、偏移决定了物理值的计算。物理值 原始值 × 因子 偏移。比如原始值0到255因子0.5偏移-40物理值就是-40到87.5。这个公式看着简单但因子和偏移设错解析出来的值就离谱。我见过一个项目DBC里某个温度信号的因子设成了1偏移设成了0结果解析出来是0到255实际应该是-40到215。后来查通信矩阵因子应该是1偏移应该是-40。改过来就对了。提示DBC写完后一定要用工具验证。发一组已知的原始值看解析出来的物理值对不对。别等到装车了才发现解析错。4.3 CANoe与DaVinci在CAN配置中的分工CANoe和DaVinci是Vector的两款工具用途不同但经常配合使用。DaVinci是配置工具用来配置ECU的通信栈、诊断栈、网络管理。它生成的是代码和配置文件刷到ECU里。DaVinci Configurator配CAN控制器、CAN驱动、CAN TP、CAN NM、诊断服务。配完后生成ARXML或者C代码集成到ECU工程里。CANoe是测试和分析工具用来仿真节点、发报文、抓报文、解析报文、跑自动化测试。CANoe加载DBC和CAPL脚本可以模拟整个网络的行为。分工上DaVinci管ECU内部的通信配置CANoe管网络层面的测试验证。比如你要测BCM的CAN通信先用DaVinci配好BCM的CAN栈生成代码刷进去。然后用CANoe仿真其他节点给BCM发报文看BCM响应对不对。我实际项目中DaVinci配置完一定要用CANoe验证。DaVinci里配的参数比如波特率、采样点、过滤器在CANoe里发真实报文测一遍确认通信正常。我见过DaVinci里过滤器配错导致ECU收不到某些报文用CANoe一测就发现了。4.4 Simulink在汽车电子中的应用模型开发与代码生成Simulink在汽车电子里主要用来做控制算法的模型开发。比如BCM的灯光控制逻辑、雨刮调速逻辑、车窗防夹逻辑都可以用Simulink建模然后自动生成C代码集成到ECU工程里。Simulink建模的好处是可视化、可仿真、可自动生成代码。坏处是生成的代码效率不一定高而且和手写代码的集成需要仔细处理接口。我用Simulink做车窗防夹算法。防夹的核心是检测电机电流的变化电流突然增大说明遇到障碍物要立刻反转。Simulink里建电机模型、电流采样模型、防夹判断逻辑仿真验证后生成代码。生成的代码要手工优化把不必要的浮点运算改成定点否则MCU跑不动。Simulink和DaVinci的配合Simulink生成应用层代码DaVinci生成通信层代码两者通过接口集成。集成的时候要注意数据类型、命名规范、初始化顺序否则跑起来就挂。5. 汽车电子测试从台架到整车的验证体系测试是汽车电子的重头戏。这一章讲测试的完整体系包括台架测试、网络测试、诊断测试、OTA测试。5.1 台架测试环境的搭建与常见问题台架测试是在实验室里搭一个模拟整车环境的测试台。包括被测ECU、电源、CAN卡、负载模拟箱、信号模拟板。电源要用可编程电源能模拟整车电压变化比如9V到16V还要能模拟抛负载、反向电压这些异常。负载模拟箱模拟真实的灯泡、电机、继电器让ECU的输出有真实负载。信号模拟板模拟传感器输入比如车门开关、光照传感器。台架搭建最容易出问题的地方是接地。ECU的地、电源的地、CAN卡的地、负载的地如果接地不好通信会不稳定ADC采样会跳。我一般用星型接地所有地都汇到一个点避免地环路。另一个问题是终端电阻。台架上如果只有被测ECU和一个CAN卡两端各一个120欧姆。如果台架上还有别的节点终端电阻只在两端放。台架测试的用例要覆盖正常功能、边界条件、异常输入、故障注入。比如测BCM的车窗控制要测正常升降、防夹、堵转、过压、欠压、CAN通信丢失。5.2 CAN总线测试物理层、数据链路层、应用层CAN总线测试分三层物理层、数据链路层、应用层。物理层测试测CAN_H和CAN_L的电压、差分电压、上升下降时间、终端电阻。用示波器看波形确认信号质量。物理层不过关上层全白搭。数据链路层测试测波特率、采样点、仲裁、错误处理、总线负载。用CAN分析仪发高负载报文看有没有丢帧、错误帧。总线负载一般不要超过70%超过就有风险。应用层测试测报文的内容、周期、超时、信号值。用DBC解析报文确认每个信号的值在合理范围内。测超时处理比如某个报文停了ECU应该报DTC。我做过一个CAN总线测试发现某个节点在总线负载高的时候会偶发丢帧。查了半天发现是那个节点的CAN控制器缓冲区太小高负载时溢出。后来换了缓冲区大的控制器问题解决。5.3 OTA测试正常升级、异常中断、回滚验证OTA测试是现在最容易被忽视的测试。很多团队OTA功能开发完了随便测几下就发布结果用户升级时变砖。OTA测试要覆盖正常升级、下载中断、刷写中断、校验失败、回滚、重复升级、跨版本升级、降级。正常升级从旧版本升到新版本确认升级后功能正常。下载中断下载到一半断网看能不能断点续传。不能续传的话重新下载能不能成功。刷写中断刷写到一半断电看ECU能不能恢复。有双备份的应该能回滚没有的就变砖。校验失败故意传一个损坏的包看ECU能不能识别并拒绝。回滚新固件启动失败看能不能自动回滚到旧固件。重复升级同一个版本升两次看会不会出问题。跨版本升级从很旧的版本直接升到最新版看差分包的基准版本对不对。降级从新版本降到旧版本看ECU允不允许。有些ECU不允许降级防止安全漏洞。我踩过最大的OTA坑是刷写中断。ECU刷写到一半断电引导程序也挂了直接变砖。后来改成双备份引导程序放在独立的、不可擦除的区域刷写只动应用程序区才解决。注意OTA测试一定要在真实网络环境下做不要只在实验室。实验室网络稳定真实环境网络可能很差。我见过实验室升级百分百成功用户升级失败率百分之几就是因为网络环境不同。5.4 诊断测试与故障注入诊断测试是验证UDS服务能不能正常工作。包括会话控制、安全访问、DID读写、例程控制、DTC读取清除。故障注入是故意制造故障看ECU能不能正确检测和记录。比如断开某个传感器看ECU报不报DTC给某个输出短路看ECU能不能保护。故障注入要用故障注入箱能远程控制继电器的通断模拟开路、短路、对电源短路、对地短路。我做过一个BCM的故障注入测试模拟所有灯泡开路看BCM能不能报出对应的DTC。结果发现有一个灯的DTC映射错了报的是另一个灯的故障。查出来是DTC配置表里写错了。这种问题不测根本发现不了。6. 汽车电子工程师的日常工具链与经验杂谈这一章聊点轻松的说说日常用的工具和一些零散经验。6.1 硬件工具CAN卡、示波器、万用表的选择CAN卡创芯科技的CAN分析仪性价比高支持CAN FD配套软件够用。Vector的VN系列稳定但贵。Kvaser的也不错中档。示波器看CAN波形带宽至少100MHz采样率至少1GSa/s。差分探头看CAN_H和CAN_L的差分信号普通探头看单端也行。万用表测电压、电阻、通断。汽车电子里测静态电流很重要要用能测微安级的万用表。电源可编程电源能模拟整车电压变化能显示电流。测静态电流的时候电源的电流显示精度要够。6.2 软件工具从CANoe到开源方案CANoe功能最强仿真、测试、诊断、自动化都能做。贵但值。SavvyCAN开源抓包解析够用支持DBC。适合个人和小团队。BUSMASTER开源功能比SavvyCAN多但界面老。Wireshark抓以太网报文配合CAN网关也能抓CAN报文。Python-can用Python写CAN收发脚本灵活适合自动化测试。我一般用Python-can做自动化测试用CANoe做手动分析和仿真。Python-can配合pytest能跑回归测试效率很高。6.3 那些年踩过的奇葩坑坑一CAN线接反了。CAN_H和CAN_L接反通信完全不通。但有些收发器有极性保护接反了也能通只是波形质量差。我见过一个项目台架上接反了能通装车后不通查了半天才发现。坑二终端电阻放错位置。终端电阻应该放总线两端有人放在中间节点导致反射严重。坑三DBC字节序搞反。解析出来的值完全不对查了半天才发现是Motorola和Intel搞混了。坑四OTA包版本号写错。云端推了不匹配的差分包刷写失败。坑五休眠唤醒逻辑没考虑所有场景。台架上能休眠装车后不休眠因为某个节点的报文一直在发。坑六诊断DTC映射错。报的故障和实际故障不对应修车师傅被误导。这些坑每一个都让我加班到深夜。但踩过之后就记住了。6.4 给新入行朋友的建议第一先把CAN总线搞透。CAN是汽车电子的基础CAN不懂什么都做不了。第二学会用工具。CANoe、DaVinci、Simulink至少精通一个。第三多动手。看再多书不如自己搭一个台架发几帧报文抓几次波形。第四养成记录的习惯。每个项目遇到的问题、解决方法、参数配置都记下来。下次遇到类似的直接查。第五别怕问。汽车电子涉及的面太广没人什么都懂。遇到不懂的问同事、问供应商、查标准。第六注意安全。汽车电子涉及功能安全一个bug可能导致事故。写代码、做测试都要有安全意识。这个领域变化很快OTA、以太网、域控制器、SOA新东西层出不穷。但基础的东西不变CAN、诊断、标定、测试这些基本功扎实了新东西学起来就快。我到现在还在学每次做新项目都能碰到没见过的问题。保持好奇心保持动手的习惯这个领域还是很有意思的。