一、产业发展现状
1.1 国外整体产业发展现状
什么是电子电气架构?在2007年由德尔福(DELPHI)首先提出E/E架构的概念,具体就是在功能需求、法规和设计要求等特定约束下,把汽车里的传感器、中央处理器、电子电气分配系统、软件硬件通过技术手段整合在一起;通过这种结构,将动力总成、传动系统、信息娱乐系统等信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、电源管理等电子电气解决方案。
关于汽车电子电气架构演进, 行业内讨论最多的是博世提出的电子电气架构发展六阶段,如下图所示。博世将整车 EEA 划分为六个阶段:模块化(Modular) 、 集成化(Integration)、域集中(Domain Centralization) 、 域融合(Domain Fusion) 、 整车中央计算平台(VehicleComputer) 、 车-云计算(Vehicle Cloud Computing)阶段。该演进概念清晰指明了未来汽车电子电气架构算力会逐渐集中化, 最终会发展到云端计算。当前主流架构处于功能域控制器集中阶段, 正在朝多域控制器融合架构方向发展。
博世 EEA 发展六阶段
为了适应市场对电动化的需求, 实现从分布式向集中式电子电气架构转变。国内外整车企业已开始建立适合未来的车辆电子电气架构和汽车软件架构, 使其可以在不同的车辆计划、开发单位和组织之间进行协调, 从而提高开发的灵活性和创新性, 减少开发时间与风险。国外整车企业如特斯拉和大众已实现整车集成至 4 个主控 ECU, 实现整车域控制器软件开发,实现软硬件解耦设计, 并多次通过 OTA 升级整车功能。
特斯拉 Model S、 Model X 再到 Model 3 /Y 的电子电气架构演变, 推动力是商业模式及技术路径的变革, 充分体现了软件定义车辆的技术创新。
目前最有名的是特斯拉 Model 3 采用的架构, 如上图。Model 3 车载中央电脑和区域控制器架构, 采用 Autopilot(自动驾驶) +IVI(信息娱乐系统) +T-BOX(远程信息处理器)三合一计算平台, 将三块控制板集成到同一壳体中, 新引入 BCM-F/L/R 三个区域控制器, 实现 ECU 整合并对执行器供电。彻底抛弃了功能域的概念, 实现集中式电子电气架构和区域控制器方案, 通过中央计算模块(CCM) 对不同的区域 ECU 及其部件进行统一管理,并通过CAN((控制器局域网) ) 进行通信, 并实现了高度集成, 高度模块化, 对传统汽车电子架构进行了全方位的创新, 实现了“软件定义汽车”, 加快了汽车产品迭代速度。实现了算力集中化、 服务附加值提升、 内部拓扑结构简化。特斯拉的准中央计算 EEA 已带来了线束革命,Model S/Model X 整车线束的长度是 3 公里, Model 3 整车线束的长度缩短到了1.5 公里, ModelY 进一步缩短到 1 公里左右。
特斯拉的集中控制功能集成在三个域控制器中, 中央计算模块直接整合了智能驾驶与信息娱乐域控制模块, 以及外部连接和车内通信系统域功能, 架构方案较之前车型简化, 即:AICM(智能驾驶与信息娱乐域控制模块):连接各类自动驾驶传感器, 综合执行逻辑计算功能, 以及完成人机交互;FBCM(前车身控制模块) /智能配电模块:负责 12V 的电池、 电源分配和热管理的功能;LBCM(左车身控制模块) 和 RBCM(右车身控制模块):分别负责剩下的车身与便利系统、 底盘与安全系统和部分动力系统的功能。
大众为了适应市场对电动化的需求, 推出了 MEB 平台, 实现从分布式向域融合电子电气架构转变。MEB 电子电气架构分为整车控制器(ICAS1) 、 智能驾驶(ICAS2) 和智能座舱(ICAS3) 三大域控制器。ICAS1 实现整车所有控制类功能集成, 如高压能量管理、 低压电源管理、 扭矩控制、 车身电子控制、 网关、 存储等功能;另外 ICAS1 连接诊断接口和 T-BOX,实现信息安全设计, 并作为 OTA 主控 ECU 实现整车并行刷写。ICAS2 作为智能驾驶运算中心, 通过以太网接收 ICAS1 的雷达和摄像头信息, 实现运算处理, 并实现对于制动和转向系统的请求。ICAS3 采用一机多屏控制方式, 通过以太网接收 ICAS1 和 ICAS2 的需求。另外大众推出自身 VW.OS, 并采用 Adaptive AUTOSAR(又称 AUTOSAR AP, AUTOSAR 自适应平台) 和 SOA 实现不同应用的集成。
沃尔沃的区域电子电气架构包括 Core System(核心系统) 和 Mechatronic Rim(机电区域) , 如下图 所示。沃尔沃的 VIU(Vehicle Integration Unit, 整车集成单元) 对应不同整车区域的感知、 控制与执行。沃尔沃的 VCU(Vehicle Computation Unit, 整车计算单元/整车控制器) 对应车载中央计算机, 提供整车智能化所需的算力与数据存储。
沃尔沃 EEA 架构示意图
奥迪将采取中央集群计算方案(Central Computing Cluster ) 。 如下图所示, 整车划分为: 驱动域、 能源域、 横纵向控制域、 驾驶辅助域、 座舱域、 车身舒适域、 信息安全域;不同的域之间通过高速以太网来进行信息交互, 域内采用 CANLIN 等进行实时低速通信;新架构分为传感器与执行器层和承载不同功能的域层; 车辆的中央计算单元会与企业的后台相连接, 奥迪的后台会与 HERE 后台相连, 接进行数据共享。
奥迪 EEA 架构示意图
1.2 国内整体产业发展现状
目前, 国内主流汽车企业三化融合车型的电子电气架构方案已从完全分布式控制, 进入域集中式控制。 国内造车新势力普遍直接采用功能域控到域融合的过渡方案, 域融合方案普遍集中在智能驾驶和智能座舱。
1.2.1 小鹏汽车G9电子电气架构具领先性
势力三强中小鹏汽车在电子电气架构方面走得比较领先,随着车型从 G3、P7和P5,迭代到 G9 的这套X-EEA3.0电子电气架构,已经进入到中央集中式电子电气架构。凭借领先一代的架构,搭载更高算力SOC芯片及更高算力利用率,小鹏G9或成首款支持 XPILOT 4.0 智能辅助驾驶系统的量产车。
小鹏P7搭载小鹏第二代电子电气架构,具备混合式的特点:
分层域控——功能域控制器( 智驾域控制器、车身域控制器、动力域控制器等模块)与中央域控制器并存;
跨域整合——域控制器覆盖多重功能,保留局部的传统 ECU;
混合设计——传统的信号交互和服务交互成为并存设计。
因此 CAN 总线和以太网总线并存,大数据/实时性交互均得以保证;以太网节点少,对网关要求低。
因此CAN总线和以太网总线并存,大数据/实时性交互均得以保证;以太网节点少,对网关要求低。小鹏第二代电子电气架构实现传统ECU数量减少约60%,硬件资源实现高度集成,大部分的车身功能迁移至域控制器,中央处理器可实现支持仪表、信息娱乐系统以及智能车身相关控制的大部分功能,同时集成中央网关,兼容 V2X 的协议,支持车与车的局域网的通信,支持车与云端的互联,车与远程数字终端的连接功能。小鹏汽车的智能驾驶域控制器,集成了高速NGP、城市GNP及泊车功能。小鹏辅助驾驶采用激光雷达视觉融合方案,与特斯拉的纯视觉方案不同,这就导致两者硬件架构不同,对于通讯带宽、计算能力的要求也不一样。
小鹏汽车电子电气架构演进历史
小鹏汽车将其X-EEA3.0电子电气架构称为“让智能汽车在未来永不落伍的秘密”。根据公司披露的首搭于 G9的电子电气架构的信息,未来 G9可以升级和优化的潜力较大。
X-EEA 3.0硬件架构方面,采用中央超算(C-DCU)+区域控制(Z-DCU)的硬件架构,中央超算包含车控、智驾、座舱3个域控制器,区域控制器为左右域控制器,将更多控制件分区,根据就近配置的原则,分区接管相应功能,大幅缩减线束。
得益于小鹏汽车的全栈自研能力,新架构做到了硬件和软件的深度集成,不仅实现软硬件解耦,也实现软件分层解耦,可使得系统软件平台、基础软件平台、智能应用平台分层迭代,把车辆的底层软件和基础软件与智能、科技、性能相关的应用软件脱离开,在开发新功能时,只需要对最上层的应用软件进行研究和迭代就可以,缩短了研发周期和技术壁垒, 用户也能够享受到车的快速迭代。
系统软件平台:基于外购代码做部分定制开发,随整车基础软件平台冻结而冻结, 可复用于不同车型;
基础软件平台:多个整车基础功能软件均形成标准服务接口且在车辆量产前冻结, 可复用于不同车型;
智能应用平台:如自动驾驶、智能语音控制、智能场景等功能,可实现快速开发和迭代。
X-EEA 3.0 数据架构方面,域控制器设置内存分区,升级运行互不干涉,便用车边升级,30分钟可升级完成。
通信架构方面, X-EEA3.0 在国内首次实现了以千兆以太网为主干的通信架构,同时支持多通讯协议,让车辆在数据传输方面更快速。从G9 搭载的新一代电子电气架构可以看出,小鹏在骨干网络的建设和面向 SOA 的方向起步较早。
X-EEA 3.0 电力架构方面, 可实现场景式精准配电,可根据驾驶、第三空间等不同用车场景按需配电,比如在路边等人时,可以只对空调、座椅调节、音乐等功能供电,其他部分断电,这样就能实现节能耗节省,提高续航里程。车辆定期自诊断,主动发现问题,引导维修,以科技手段赋能售后。
小鹏汽车第三代电子电气架构实现千兆以太网+中央计算+区域控制
1.2.2 极氪001汽车电子电气架构
极氪汽车已量产(车型:极氪 001) 的电子电气架构是功能域集中式架构 ,由四大功能域主控承担整车级别的各域功能逻辑软件部署中心的角色, 将绝大多数传感器和执行器的控制逻辑与整车功能应用进行分离, 大部分普通 ECU 作为纯粹的传感和执行控制单元, 功能域内跨子系统和子系统内部的逻辑接口交互在域控内部即可完成, 跨域信息交互通过 Flexray(高速容错网络协议) 和以太网为主干网的双网实现。ECU 实现功能业务应用和执行器控制逻辑的解耦, 功能接口模块化、 标准化、 开放化。在电子硬件集成度上, 域控集成了大量的简单 I/O 驱动 ,复杂的执行器和传感器作为独立的电子单元通过CAN/LIN/A2B/LVDS 等网络连接在各自的域控上, 一定程度上缩减了 ECU 数量、 降低了整车成本。
极氪汽车 EEA 架构示意图
1.2.3 华为CCA架构
华为基于自身的 ICT 技术为积累, 推出华为 CCA 架构为基础的全栈式解决方案 。其中底层的基础是“计算+通信”为核心的 CCA 架构, 用以太环网作为车载通信主干网络, 实现了“功能域”+“区域”的集成。以太环网+VIU 区域控制器构建车内通信架构。整车网络架构设置 3-5 个 VIU, 相应的传感器、 执行器甚至部分 ECU 就近接入, 实现电源供给、 电子保险丝、 I/O 口隔离等功能。VIU 之间通过高速以太网的环形网络进行连接, 确保整车网络高效率和高可靠。在整车通信架构之上, 设置智能座舱域控制器 CDC、 智能驾驶域控制器 MDC 和整车控制VDC, 共同完成信息娱乐、 自动驾驶、 整车及底盘域的控制。
1.3 国内外架构整体方案对比
总体而言, 国内整车企业电子电气架构整体方案与国外传统整车企业方案相当, 都处在功能域控或功能域控到域融合的过渡阶段。 不过, 国内方案相对比在行业内处于领先地位的特斯拉架构方案, 大概有 3~5 年的的差距,这些差距主要体现在:
a. 功能软件设计模型方面, 国内整车企业自主设计车载核心功能较少, 缺少开发和验证能力积累。
b. 架构设计的模型库方面, 尤其是在智能驾驶功能方面, 国外主流整车企业在开发智能驾驶功能时均基于较为完善的功能模型库进行设计和验证, 以确保智能驾驶的可靠性和安全性。而国内各整车企业在智能驾驶功能模型的开发领域还处于空白阶段, 大部分需要依靠国外供应商或者第三方技术支持才能开展智能驾驶设计工作。另外, 智能驾驶的场景数据库也是目前国内整车企业的储备软肋。
c. 控制器底层软件方面, 市场底层软件多为国外产品, 我国产品的应用范围少、 用量少, 很难发展完善;
d. 主流车载总线技术方面, 技术被国外垄断, 难以满足国内智能网联汽车在通信方面需求;
e. 汽车电子基础软件方面, 国外汽车行业已较成熟(日本汽车软件标准化组织 JASPAR和欧洲 AUTOSAR 体系) , 而国内属于发展初期。另外, 汽车电子底层软件主要依赖国外零部件供应商。
f. 网络架构设计方面, 智能网联汽车的通信网络需要满足大带宽、 高实时性的要求,车载以太网作为车载网络中的主干网是新型网络架构的必然趋势。国际上基于车载以太网的新型网络拓扑结构以及通信协议已经基本成型,而国内车载以太网的研究和应用较少, 无法在车载以太网标准发布后快速进入应用阶段。
g. 冗余技术方面, 冗余技术在保证未来智能汽车安全性和可靠性方面具有十分重要的作用, 国际上领先的电子电气架构研发团队提出多种冗余方式, 将冗余技术应用在整个电子电气架构的开发过程中。国内目前更多将冗余技术应用于高级别自动驾驶系统的开发中。
二、产业技术发展趋势
2.1 电子电气架构演进
传统汽车采用的分布式 EEA 因计算能力不足、 通讯带宽不足、 不便于软件升级等瓶颈,无法满足现阶段汽车发展的需求, EEA 升级将助力智能汽车实现跨越式革新。博世提出了众所周知的电子电气架构技术路线图, 并描绘了未来电子架构的主要特征及可能的实现时间点。其中的两个重要标志性节点依然值得强调, 即 DCU(域控制器) 或 HPC(高性能计算机)平台的出现, 以及统一的基础软件平台的出现, 标志着 EEA 的本质进化。
a.在基于域控的集中式架构之下, 各个功能部件均成为独立的域, 在每个域之下有相应的控制功能集合。域与域之间可以做到安全隔离, 也可以根据需求进行通信和互操作, 形成类似以太网总线上的计算机局域网, 变成了松散耦合的架构。各域控制器完成各自的的数据处理, 并在域本地完成决策, 只通过中央网关与其它域控制器交换所需数据。其中, 与自动驾驶相关的传感数据由自动驾驶域控制器处理后进行决策。
b.跨域融合架构:为进一步提升性能, 满足协同执行又减少成本, 跨域融合集中化方案应运而生, 即将两个或者多个集成型域控制器合并为一个域控制器。比如动力域和底盘域的合并、 车身域与智能座舱域的合并, 座舱域和自动驾驶域再集成至同一控制器硬件, 达到部分程度的中央域控。该架构示意图如下图所示:
c.在未来, 随着高级别自动驾驶的规模化应用, 汽车电子及软件功能大幅增长, 架构形式将向基于中央计算平台的整车集中式电子电气架构演进:各采集、 执行节点将原始数据通过网关传输到中央控制器处理, 所有数据的处理与决策制定都在这里完成。其中, 与自动驾驶相关的传感数据也将由中央控制器处理后进行决策。
d.最终电子电气架构将向车路云协同架构发展。车路云协同架构是利用新一代信息与通信技术, 将车、 路、 云的物理层、 信息层、 应用层连为一体, 进行融合感知、 决策与控制,可实现车辆行驶和交通运行安全、 效率等性能综合提升的一种信息物理系统。
而整车中央集中化阶段和跨域融合阶段的本质不同是:一, 软硬件完全分离, 且所有的ECU/DCU 共享同一套基础软件平台。二, 相互独立的功能应用搭载在一套高算力的车载计算机(HPC) 上, 且它的算力远超阶段二的 DCU。三, 基础软件平台+功能独立+HPC 将带来规模化, 即一套架构可以承载任何形式、 数量的功能及服务。
2.2 整车计算平台形态演进
整车计算平台主要分为三个部分, 自动驾驶集成平台(ADIP, Automated Driving Integration Platform) 、 车控集成平台(VIP, Vehicle Integration Platform) 以及座舱集成平台(CIP, Cockpit Integration Platform)。VIP 的主要功能范围是集成动力控制、 车身控制、 网关功能以及区域控制器控制和管理;
ADIP 的主要功能范围是高阶自动驾驶、 驾驶辅助以及车辆运动控制;
CIP 的主要功能范围是娱乐以及网联的功能集。同时它们之间都有功能交集,正是因为这些功能交集的存在, 整车计算平台的形态也会存在多种, 如下图
整车计算平台功能交集(博世)
针对 ≤ SAE Level 2+ 应用场景, 如下图所示有三种模式:
整车计算平台三种模式(≤ SAE Level 2+)
Pattern A: 三个集成平台之间相对独立, 适合于 L2+应用;
Pattern B1: CIP 集成了 L2+的驾驶辅助功能;
Pattern B2: VIP 集成了 L2+的驾驶辅助功能;
Pattern C: xIP(Cross-domain Integration Platform, 跨域集成平台) 集成了所有, 通常 ADIP 和 CIP 整合在一起也属于这个范畴;
Pattern B2 方案, 目前的解决方案主要还是外扩一个单独的算力芯片进行驾驶辅助的感知等处理。
Pattern B1 方案, 目前以及下一代的座舱芯片已有足够的算力去直接集成驾驶辅助的功能, 无需单独的硬件芯片, 一些整车企业已经把集成泊车功能作为第一步, 进一步集成 L2+的行车功能。
VIP 功能主要用来实现动力控制、 网关以及车身等基础功能, 对于实时性有很高的要求。驾驶辅助功能是以数据驱动的开发方式, 持续频繁地进行软件迭代。把 VIP 和辅助驾驶功能糅合在一起, 复杂程度会很大, 并且在成本效率上也没有明显优势。因此 Pattern B1 方案会优于 Pattern B2 方案。
总体而言, Pattern A 目前仍然会是实现 L2+的主要架构形式, 单独的 ADIP 允许接入更多的传感器, 可以实现更多的功能场景;针对 L2+的应用, Pattern B1 会优于 Pattern B2;长期发展方向会向着 Pattern C 去演变。
针对 ≥ SAE Level 3 应用场景, 如下图所示有三种模式:
整车计算平台三种模式(≥ SAE Level 3)
针对≥L3 应用, 自动驾驶的冗余是必要的:
Pattern A:ADIP 内部或外部冗余
Pattern B1: ADIP 和 CIP 组成冗余
Pattern B2: ADIP 和 VIP 组成冗余
Pattern C: xIP 内部实现冗余
总体而言, 针对 L3 或以上的应用, Pattern A 优于 Pattern B1, Pattern B1 优于 Pattern B2;长期发展方向会向着 Pattern C 去演变。
2.3 构建 SOA(面向服务架构)
2.3.1 SOA
面向服务的架构 SOA(Service-Oriented Architecture) 是一种软件架构设计的理念和方法论, 也是 IT 行业企业软件的一种主流架构风格, 是一个架构组件模型, 将软件组件(称为服务) 通过定义良好的标准接口和服务契约联系起来。SOA 架构需从传统电子电气架构的“面向信号”转变为“面向服务”, 将功能独立出来。
其核心内涵即从本质上通过复用、 松耦合、 互操作等机制来提高软件质量、 加快软件研发效率、 使研发出来的产品能够交互并灵活适应业务变化。
目标是如何最大限度地减少应用(或业务) 变化对已部署或正在运行的软件系统带来最小的冲击, 以满足长期治理的需求, 实现服务架构随应用变化可持续性演化。
2.3.2 软件的工业化生产
面对车载软件庞大且仍在增加的软件代码量, 汽车行业开始借鉴 ICT(信息通信技术)行业的“软件工厂”理念。比如戴姆勒旗下的全资软件开发公司 MBition 正在打造软件工厂,根据开发项目需求, 通过对软件组件的标准化、 结构化运用, 实现快速开发。正如传统制造业在上世纪初引入福特式流水线生产那样, 软件开发也正在从“定制化手工制作”向“自动化产线制造”转变。
软件工厂需为开发者提供可行的软件框架、 配套的开发指令、 预设的程序模板、 可复用的代码以及伴随开发进程可以连续测试的环境。在此基础上, 当软件工厂收到一项开发需求时, 开发者能够根据工厂现有能力拆解需求模块, 并将其分配至各个“产品线”, 每个产品线再根据新需求识别可以复用和需要新开发的部分, 判断开发工作所需资源, 最后部署开发、测试工具并完成任务。相比于传统的“手工”开发模式, 软件工厂可以提升软件产品的一致性、品质和开发效率, 提前识别开发工作量, 前置风险, 使整个开发和部署流程更可预测,大大提升了车企对软件工作的资源配置和进程管控能力。
2.3.3 软件与服务成为差异化的关键
汽车电子电气架构的变革使得汽车硬件体系趋于集中化, 软件体系的差异化成为汽车价值差异化的关键。科技公司进入汽车行业推动了供应链生态体系的变化, 汽车产业链逐渐从整车企业、 一级、 二级供应商的线性关系演变为更加复杂的整车企业、 供应商和科技公司均参与的汽车新生态体系, 以及整个产业覆盖汽车全生命周期的网状关系。商业模式上也从出售汽车硬件发展为出售硬件与后续服务的转变。研发流程也从软硬件集成开发转变为软硬件解耦的独立开发。新的整车电子电气架构构成了未来智能网联汽车的核心, 软件和服务能力将成为未来汽车产业里最为重要的竞争力。
2.3.4 标准化的软件架构将逐步建立
汽车软件架构走向分层化、 模块化, 使得应用层功能够在不同车型、 硬件平台、 操作系统上复用, 并且可以通过标准化接口对应用功能进行快速迭代升级。未来随着智能网联汽车的应用场景越来越丰富和逐渐固化, 在面向服务设计思想下, 在容器化和虚拟化技术的支持下, 汽车硬件设备趋向于具备通用性、 算例化和标准化特性。系统软件和功能软件将是汽车行业技术研发和应用的重点。整车企业将更多聚焦在产品定义、 应用算法开发及系统集成匹配等方面, 而底层共性的基础软件架构等可由专业的供应商提供。
2.3.5 汽车产业格局将被重塑
在软件定义汽车时代, 整车企业为了掌握主导权并降低高昂的研发成本, 往往会选择直接与具备较强的独立算法研发能力的软件供应商合作, 因此这些软件供应商一跃成为了 Tier1厂商。未来, 软件供应商的盈利模式有望发生转变, 基础平台开发以许可费的形式收费, 功能模块以版权费的形式收费及定制化的二次开发费用等。“硬件预埋, 软件升级”成为当下车企的主流策略, 至 2025 年将成为 L3 及更高级别自动驾驶发展的关键节点, 具有领先软件和算法能力的车企、 软件供应商有望获得重要发展机遇。
从长期来看, SOA 将重构汽车生态, 汽车行业或将复制 PC 和智能手机的软件分工模式。车企可通过自建或与供应商合作搭建操作系统和 SOA 平台, 引入大量算法供应商和合作伙伴等形成开发者生态圈, 汽车行业上下游参与者各自的角色与定位将发生根本
2.4 通信架构升级
随着新一代架构的发展和自动驾驶的应用, 车载网络技术的发展趋势为高带宽、 低延时、高可靠、 车云协同。汽车网络通信系统朝向多网络、 高带宽、 低延时、 多冗余、 高可靠等方向发展, 同时打破核心技术垄断, 提升自主化率, 逐步实现引领超越。
车载网络技术趋势
预计至 2025 年, CANFD-XL、 10Base-T1S、 2.5G+Base-T1 等车载总线技术将趋于成熟,逐渐量产应用。
预计至 2025 年, 随着中央计算+区域控制器的架构逐渐实施, 将逐渐发展为以 1G+车载以太网为骨干网的网络架构, 结合 AVB/TSN、 SOME/IP、 DDS 等传输协议, 解决低时延、 高带宽、 高同步、 高冗余应用场景传输需求。
通信技术正在快速演进中, 从 CAN 到 CANFD 到 CAN XL, 从 100M 以太网到 1G 以太网到 2.5G 以太网, 甚至 10G 以太网的技术。
自动驾驶需要以更快速度采集并处理更多数据, 传统汽车总线无法满足低延时、 高吞吐量要求。因此, 集带宽更宽、 低延时等诸多优点的以太网有望成为未来车载网络骨干。2015 年首个车载以太网规范 100Base-T1 发布,仅需要一对双绞线进行传输, 可以减少 70-80%的连接器成本, 减少 30%以上的重量, 并且能够有效的满足车内 EMC(电磁兼容性) 电磁干扰的要求。随着 1000BASE-T1 以及更高带宽 NGBase-T1 以太网标准的不断推出, 以太网有望成为未来智能汽车时代的车载主干网络。不过为了不使零部件成本和线缆重量急剧增加, 并且尽可能降低技术升级带来的安全风险, 各域内依然保持 CAN/CAN FD 的连接架构。
我们深知加工与定制类服务商的价值和重要性,因此,我们倾力为您提供最顶尖的营销资源。在我们的平台上,您可以直接接触到100万的研发工程师和采购工程师,以及10万的活跃客户群体...详细>>