汽车电子技术框架

标签：功能 架构 OEM 框架 电子 整车厂 汽车 测试 整车

0 Preface

写在汽车行业发展的拐点。

最近这十年，汽车行业已经从传统行业一跃转变为高科技产业。随着电动化和智能化的发展，汽车形态已经从传统的燃油车转变为智能终端。同时，汽车已经从硬件主导转变为软件定义，最近随着AI大模型的突破，隐隐的升级为AI定义汽车。

技术的发展对于传统行业的冲击和重塑使整个行业发生了天翻地覆的变化，身处其中，冷暖自知。最近各个整车制造企业的消亡也说明了行业正在加速洗牌，留在牌桌上对于整车厂和工程师同样意义非凡，却也不尽相同。人在历史的车轮下过于渺小和无助，只能随着大势滚滚向前，未来的路尚不可知，但来时的路却尚未走远，记录这些年的点滴只对个人才有意义，却也是最大的意义。

1 Overview 

        汽车的研发离不开OEM(Original Equipment Manufacturer)对于用户需求的收集、对于汽车产品的定义、对于产业链的整合；离不开零部件Supplier/Tier1 对于汽车电子产品的硬件设计、软件设计、结构设计、试验验证、生产；离不开Tier2 提供传感器、执行器、芯片、工具等等。

        在一个汽车电子系统工程师的视角里，整车电子电器与零部件开发各有侧重，所需要的知识和技术框架也并不相同。本文及后续的文章将记录整车开发以及零部件产品开发的汽车电子技术框架。在逐渐梳理技术的同时也会逐渐完善各个技术路径，本文算是一个持续更新的目录。另一方面，由于能力有限，很多方面都是浅尝辄止，希望在这个过程中进行补充和学习。

2 OEM

        在传统整车厂的视角里，整车开发包含但不限于造型、车身、底盘、内外饰、动力总成、电子电器、性能耐久、尺寸公差、试制试验等各个专业，而电子电器开发是其中一个环节。

        到了如今的时代，电子电器意味着传感器和执行器，智能化是新的方向。所以一些整车厂会将上述专业称作传统专业，新型专业则包括了智能驾驶，座舱娱乐以及各大厂纷纷布局的芯片设计。

        传统的电子电器又可根据其不同专业方向大致分为线束，空调、雨刮、开关、灯具等执行器，车身电子、底盘电子、辅助驾驶、仪表、HMI等娱乐的控制器。

        在电动化和智能化到来之后，原有的各个专业被打散，增加了三电（电池、电驱、电控）专业，原有的动力相关的控制器在增程车上变更为增程器，同时各整车厂纷纷布局、大量投入的智能驾驶、智能座舱、智能车控、智能底盘被推到重要位置，硬件继续按照两冬一夏进行整车试验验证，而智能化软件由于可以OTA更新，可以与硬件解耦，独立迭代。

​

2.1 Brief Description of Vehicle Develoment Process

        整车开发是依托于整车开发流程，目前行业用的比较多的是来自通用和Ford的开发流程，不同整车厂的开发流程略有不同，但总体上可以在上述两家找到一些影子，比如吉利汽车的NPDS(New Product Development System)流程。

        随着华为加入汽车行业，一套IPD(Integrated Product Development)流程也随之导入到传统汽车行业，越来越多的企业也开始学习华为，适应性的定制自己的IPD流程。

2.2 Brief Description of EEA

2.2.1 Vehicle Platform Vs EEA

        汽车的平台和架构往往是交织在一起的，所以当谈到电子电器架构的时候不可避免的会牵扯到汽车平台的讨论。

        成功的汽车平台如大众汽车的MEB/MQB，Volvo汽车的CMA/SPA平台，这些平台在燃油车时代被广泛应用到各个品牌和各个车型，极大的提高了车辆研发效率和生产效率，降低成本。所以，汽车的平台是一种通用架构，它包括车辆的底盘、动力系统、电子系统等基本组成部分，通过使用相同的平台，OEM可以在不同的车型之间共享零部件和制造工艺，从而节省研发和生产成本‌。可以说汽车平台更侧重于车辆的机械结构和基础部件的共享。

        而汽车电子电气架构更偏重于电子电气系统的设计和整合。通过创新的设计来提升汽车的功能和智能化开发，从而实现快速的迭代与更新。电子电气架构是一个逐渐发展、迭代，带有极强整车厂平台开发理念的顶层设计。EEA希望解决的问题包括但不限于：Feature的定义，功能逻辑的设计，系统/子系统的功能分配，ECU、Sensor、Actuator的功能分配及物理、网络连接，配电的设计、通信的设计，电气原理设计，线束设计等。

2.2.2 EEA Evolution

        这里不得不谈到的就是Bosch提出的电子电气架构的演进路线。目前大部分的OEM已经跨过了集中化的阶段，处于域融合到车载电脑的阶段。这里由于电子电气架构的差异也产生了不同的设计思路，当然更多的是影响功能到控制器的分配。

        在大部分OEM还在域融合的时候，Tesla是最早采用区域+中央电脑的架构的整车厂。当年近些年几乎所有的整车厂也也意识到区域控制器的价值，开始逐步量产下一代的电气架构。回到刚才的话题，功能的分配会随着电气架构演进而变化。

        以车身电子的功能为例，对于外部灯光的控制，在域融合阶段可能是由BDCM(Body Domain Control Module)车身域控制器来逻辑和执行的，而在区域+中央的架构下，外部灯光基于其位置的不同可能由车身前部区域(近光灯、远光灯)、后部区域(刹车灯)。当然除此之外，区域控制器同时承载了配电、网关和执行的操作，给软件定义汽车提供了硬件的平台。

2.3 Brief Description of Function Domain

        虽然基于电气架构的不同功能的分配可能有差异，但是当谈论某一个功能的时候，还是会区分是哪个功能域的，因为很多功能域有其特有的实现逻辑，并且与其他功能域的交互很少。

        车身域是最传统的功能域，控制整车绝大部分的功能，诸如：外部灯光、内部灯光、洗涤雨刮、无钥匙进入启动、方向盘、后视镜、门窗控制、座椅控制等等。

        底盘域功能是控制车身的横向、纵向、垂向运动，随着电动汽车一体化底盘技术CTC(Cell to Chassis)的量产，在底盘域可以将电池系统、电驱系统、热管理系统、线控系统等关键部件和控制集成在一起，所以底盘域控在当前的电子电气发展中也是一个很前沿的方向。

        动力域从传统的发动机控制EMS(Engine Management System)，到当前的由BMS控制动力电池、MCU(Motor Control Module)控制动力驱动以及VCU(Vehicle Control Unit)控制整车的人驾部分的加减速扭矩分配等。动力域在各个阶段的电气架构中都由于其独特的功能而很少可以做融合，但随着动力域本身的演进，还是有很多架构的不同思路，比如将控制和执行分开，更好的实现软硬件解耦。

        智能驾驶是一个绕不开的话题，目前整车的智能化很大一部分围绕着智能驾驶展开，另一部分是智能座舱。当然，目前最火的AI定义汽车的概念也是从这两个域控的功能而来。

        智驾从最开始的辅助驾驶到如今的域控也经历了很多过程。从最开始分布式架构中每个功能都有相应的控制器实现，比如实现AEB的ADAS控制器和实现驾驶员监控的DMS控制器，到如今将行车和泊车功能融合一起的AD控制器。同时随着智驾算法从传统基于规则转变为BEV、大模型，智驾系统对算力要求越来越高，整车的AI能力也随着大模型而越来越高。

        而智能座舱也是近些年很火的概念，传统的座舱包括仪表、HMI(车机，而不是当前的大屏)，到后来HUD、中央大屏(副驾屏、二排屏)的配置越来越高，而带有语言模型的车内语音系统也展现出了非凡的智能化和舒适性，AI/LLM对于语音助手的加持已经真正达到了人工智能的水平，当然这一切一方面取决于整车信息娱乐域的算力，另一方面也得益于越来越普遍的信息化。

        电动化带来的动力电池管理以及智能化带来的大算力的车载电脑普及对整车的热管理也提出了更高的要求。热管理专业也从传统的发动机冷却系统、空调系统逐步转化到热泵空调和全车电子液冷。由于热管理系统主要依赖于高压供电，对于电动车来说，电量代表着里程，代表着更高的成本，所以整车对更高效率的热管理也提出了更高的要求。

3 Supplier/Tire1

        电子电气架构的设计决定了功能到控制器的分配，而控制器的设计也就到了供应商/Tier 1的领域。传统的电子电气控制器全部由供应商提供，而如今更多的整车厂组建了OEM的零部件设计团队，这里全产业链的设计能力可以帮助整车厂提高研发效率，更快的响应更频繁的变更。内部的团队有时候被称作Tier0.5，介于整车和供应商之间，因为整车厂一般不会自建零部件生产工厂，这里也发展出专门为了整车厂代工零部件的代工厂。

        在供应商的视角里，接受到整车厂释放的需求包括但不限于SOR、功能规范、整车标准等等。系统工程师会将相关方需求进行汇总并进行分析和拆解，同时基于需求进行系统及架构设计。这些需求和架构将被释放给软硬件进行下一步开发。

        当然相关方还包括测试、结构、试验、生产等环节。

3.1 Brief Description of Product Development Process

        零部件开发的开发流程绕不开V流程和ASPICE，当然随着智能化的进程传统的ASPICE也遇到了很大的瓶颈，而敏捷开发则被从软件开发引入到汽车行业中。不过当前大部分的OEM还是Follow ASPICE流程，而对供应商的审核也围绕着ASPICE的各个过程。

        ASPICE在2023年也与时俱进的推出了4.0版本，增加硬件相关过程域、机器学习过程域以及验证过程域；同时精简了采购、供应支持等过程组。

        ASPICE流程是否有效对每个组织来说都是一把双刃剑，不过对于工程师来说，其实可以从ASPICE流程中获得各个过程域的基本流程和关键点，尤其对于有一定经验的工程师来说是一个总结性质的梳理。

3.2 Brief Description of SYS Process

        系统过程是零部件开发的起点，如上述流程是从获取相关方需求开始，包括了后续的系统需求分析、系统架构设计，在V流程的右边对应的是系统集成和集成验证以及系统验证，这两个验证过程属于测试环节，主要对应于系统架构和系统需求的验证。

        不过除了流程因为系统工程师与客户对接，同时离客户需求最近，所以一般对知识面的整体要求也更高，但是深度就没办法和研发工程师相比了。另一方面，知识面的要求也体现在系统架构的能力上。尤其是一个需求有多个实现方案时，对于方案的取舍更是体现系统工程师能力的关键。另外，系统工程师也对软硬件之间的协同以及不同软件模块、分层之间的协同提供帮助。尤其是对于整车功能相关的诸如：OTA功能，Log功能，时间同步功能等等。

        本文及后续内容就是站在系统工程师的视角下的整车功能和技术路线。

3.3 Brief Description of SW Process

        由于整车的舒适性、安全性功能越来越多，传统的硬件主导的整车设计开始转向软件主导，尤其是智能驾驶和智能座舱的功能越来越复杂，整车的软件也越来越复杂了。我们经常看到由于软件设计问题导致的整车OTA，也在这几年看到软件定义汽车的浪潮里，大众汽车的孤注一掷和反复放弃。

        软件承载于硬件芯片，而在汽车领域里，主要有三类主芯片：MCU用于实时控制，MPU用于非实时大计算量，xPU(GPU/BPU)等用于AI推理计算。

3.3.1 MCU SW Architecture

        MCU(以Arm M核/R核为主)的软件架构绕不开AUTOSAR。这有点像ASPICE一样，OEM基本都会采用但褒贬不一。AUTOSAR中文称为“汽车开放系统架构”，是一个由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立的联盟。其目标是制定一个开放的、标准化的汽车电子软件架构，以促进车辆电子系统软件的交换与更新，并提高开发效率和降低成本‌。

        但由于使用AUTOSAR协议需要使用供应商的软件栈，所以是不是真的省钱就见仁见智了。一般Global OEM会指定使用Vector、EB等供应商的BSW协议栈，而Tier1们则要含泪花一大笔钱去购买。不过AUTOSAR确实提供了一整套方法论，尤其是BSW软件和硬件解耦，各个软件层分层解耦，其实对于软件开发的确是有长足的帮助的。

        基于上述原因，更多的中国企业开始自研AUTOSAR，比如华为在为整车厂提供的MDC上搭载了自研的VOS，其他整车厂也纷纷设计和开发符合自己需求的AUTOSAR协议栈

3.3.2 MPU SW Architecture

        与MCU侧不同，MPU(以Arm A核为主)，操作系统也基本以Linux和Android为主，对于安全有强要求的零部件也可能会用QNX。

        芯片厂一般会提供与芯片适配的DriveOS(基于某个版本的Linux)，当然也可以采用商业的Linux诸如Windriver或者Redhat，一般来说这些厂商会提供一整个BSP包，以节省使用者对于底层的开发，更专注于应用设计。与MCU侧类似，AUTOSAR AP也提供了类似BSW的中间件。

        不过在实际应用中，由于中间件为应用提供各种服务，所以整车厂采用统一的AUTOSAR AP反而不多，有的供应商会根据实际情况选择AP+自己的中间件的方式或是完全放弃AP。

3.3.3 xPU SW Architecture

        在智能驾驶和智能座舱产品中，传统的Arm A核不能满足对于神经网络计算的要求，于是各个芯片厂xPU的出现解决了AI处理器的问题。

        在自动驾驶领域里Nvidia的Orin系列芯片，当前处于主导地位，采用的是GPU处理器；

        国产的Horizon的征程系列芯片，采用的BPU处理器。

3.4 Brief Description of HW Process

        硬件设计需求来源于系统需求，基于需求以及典型的硬件电路做原理设计。随着技术的积累典型的硬件电路逐渐模块化，经过验证的模块化电路大大降低了出问题的可能，并且提高了效率。一些基础的硬件模块如下：

• MCU/SOC及其外部电路：一般是由芯片供应商提供的，由于芯片供应商已经在开发板上做了大量的验证，在实际使用上一般不太需要更改太多设计。
• 电源模块：MCU一般只有一个电源域，此时只需要LDO做给处理器供电，随着控制器的功能安全以及电源域增加这时候出现两个分支
  • SBC：综合了LDO、收发器、看门狗等功能并带有功能安全功能
  • PMIC：当电源域增加后，集成了多个LDO、BUCK、DCDC电源，并带有功能安全功能
  • PMU：一般指比较复杂的SOC需要更多的电源给内部不同的核以及电源域供电，并且这些电源有着比较复杂的上电逻辑
• 网络模块：当前整车的骨干网一般是CanFD，当然也辅助有Ethernet，同时对于传感器来说LIN也是常见的选择
• 内部通信：由于外部传感器的不同，可能会选择SENT、PSI5等通信协议，另一方面处理器域外设之间也会有PCIE/USB等高速通信和SPI、IIC、UART等低俗通信。
• 输入输出模块：与外部传感器输入和负载有着直接关系，所以根据不同类型的输入输出可能有不同的设计。

3.5 Brief Description of Test Process

        测试过程在V流程的右侧，根据其侧重(分层)不同有着不同的测试重点和测试手段。按照ASPICE流程来说

• SWE4：软件单元测试，主要针对于软件单元模块的详细设计
• SWE5：软件集成测试，主要针对于软件架构，多模块之间集成后进行测试
• SWE6：软件确认测试，主要在针对于软件需求，验证每一条软件需求
• SYS4：系统集成测试，主要针对于系统架构，验证侧重点为软硬件结合测试（如HSI
• SYS5：系统确认测试，主要针对于系统需求，验证重点为每一条系统需求

        对于测试来说，测试对象即测试需求是关键。需求来源除了针对上述每个测试过程的需求之外还包括但不限于法规、FMEA、通信协议、软硬件接口等等。

        针对于不同的测试需求需要制定测试策略，测试策略流程比较庞杂这里针对测试方法和测试的手段做一个简要说明：

        测试方法包括：功能测试、性能测试、外部接口测试、压力测试、故障注入测试、环境相关测试等等。

        测试手段以及测试工具大体包括如下：

3.6 Brief Description of ME Process

        结构及后面的试验和生产并非本职，以下描述是以系统工程师的视角进行的：

        控制器类的结构设计主要是针对壳体的设计、接插件的选型，以及更为关键的散热设计。一般的关注点如下：

• 材料要求
• 机械接口
• 电气接口
• 装配设计
• 防护设计
• 标签标识
• 异响
• 可靠性
• 散热        

        而在设计中的仿真也是提前验证的关键，结构震动的仿真、热的仿真等等。

3.7 Brief Description of Validation Process

试验验证标准一般参考OEM的标准，如果OEM没有给出自己的企标，可以参考

• ISO标准，见下表
• Ford标准，CETP: 00.00-E-412
• GM标准，GMW3172、GMW3097

试验类型	参考标准
环境试验	ISO 16750
防护试验	ISO 20653
电性能试验	ISO 16750
EMC试验	ISO 11452/ISO 7637/CISPR25/ISO 10605
阻燃试验	FMVSS 302
材料试验	According to OEM's Standard
ELV/RoHS	2000/53/EC

3.8 Brief Description of Manufacture Process

产线设计一般包括

• SMT工艺流程，包括回流焊/波峰焊、ICT、Pressfit等
• 组装工艺流程，包括软注、三防，壳体组装，EOL，包装等

        其中接插件需要根据接插件选型来确认生产流程，如果选用成品连接器一般选用回流焊或波峰焊，回流焊就在TOP面焊接的时候一起进行，波峰焊需要增加一个工位。如果选用pressfit插针工艺，则需要增加pressfit和压接检测工位。接插件选择各有优劣，工艺生产也可能反过来对结构提出要求。

        根据控制器芯片的不同，前期对于芯片可能有裸芯片注入的工位，即焊接之前就已经将软件注入到芯片的存储器NorFlash/UFS中，所以软注工位可选，并且可以和FCT工位合并。另外三防也是需要根据控制器的不同而选择，对于散热要求高或者使用了继电器的位置，则不能进行喷涂。对于重要控制器或是OEM有特殊要求，也会增加老化工位，总的来说增加的测试环节越多越可以保证出厂质量，但是生产节拍越长也增加了更多的成本。

        其中系统工程师关注的环节是软注/FCT/EOL测试，在这些流程里需要指定测试的内容规范协议等等。

4 Summary

        汽车电子产品的研发是一个复杂的流程，从OEM需求释放到供应商产品设计最终到工厂生产其中环节也相当多。本文描述的汽车电子技术的框架只是浩如烟海的技术方向一点点总结，不涉及具体技术点自然也不涉及技术实现。系统工程师的视角可能全面但绝非深入，随着技术的变革也许以后的汽车领域会发生翻天覆地的变化。

标签：功能,架构,OEM,框架,电子,整车厂,汽车,测试,整车
From： https://blog.csdn.net/HITbingdu/article/details/144606885