EHB最新技术路线
与海内外合规要求
研发、量产、功能安全、网络安全与市场准入综合分析报告
面向研发决策、量产导入与海内外市场准入的系统分析
报告摘要 EHB不是单一泵、电机或助力器产品,而是连接制动执行、能量回收、智能驾驶、软件更新与整车安全的一条关键证据链。技术路线的核心评价标准,不仅是能否建压,更在于能否在整车生命周期内持续证明制动安全、网络安全、更新安全、量产一致性与责任可追溯。 |
执行摘要
本报告将技术路线、法规准入和工程证据分开分析。研究认为,当前量产仍以集成式EHB作为现实平衡点,EMB/干式制动属于更长期的发展方向;法规约束的是制动性能、失效与后备能力、网络安全、软件更新和型式批准结果,而不是某一种产品拓扑。ISO 26262、ISO/SAE 21434、ISO 21448和ISO 24089属于工程标准,其项目约束力主要来自法规引用、OEM合同、认证方案和供应商审核。
图1用于说明技术路线选择,图2用于说明合规责任边界,图3用于说明验证证据如何逐级收敛,图4用于说明故障、攻击和软件更新失败如何进入售后与持续改进。
第一章 EHB技术路线演进与量产判断
EHB不应仅被理解为传统真空助力器的电动替代,而应被视为连接制动执行、能量回收、ADAS、自动驾驶、底盘域控制和软件更新的一条安全关键链路。研发阶段应首先冻结系统边界:踏板是否与压力生成解耦,制动力由液压还是轮端电执行器生成,是否保留液压后备,驻车制动和再生制动由谁负责,以及EHB与ESC/AEB/底盘域控制器如何分工。

图1 EHB技术路线四象限:区分当前量产主流、高可用架构与EMB长期方向。
1.1 路线一:电机液压增压
第一阶段为电机驱动液压增压。该方案保留液压制动的成熟执行介质,通过电机、泵、阀体和控制器实现快速建压,并在一定程度上解耦驾驶员踏板输入与轮端制动力。该路线对现有底盘、卡钳和法规测试方法具有较好继承性,适合用于纯电和混动车型的再生制动融合。
1.2 路线二:踏板解耦的集成式EHB
第二阶段为踏板解耦的集成式EHB。该路线将助力、建压、阀控、压力感知和部分稳定性控制集中到更紧凑的执行器中。Continental公开资料将MK C2描述为具有踏板解耦、两个独立分区和冗余fallback的第二代电液制动方案,并强调与再生制动和自动化驾驶协同。 该类资料可用于说明行业路线,但不足以证明所有车型的量产规模、ASIL目标或具体市场准入状态。
1.3 路线三:EMB与干式制动
第三阶段为EMB与干式制动。EMB将执行器进一步移至车轮端,理论上可以取消从踏板到卡钳的液压传力,实现逐轮独立控制。Brembo将SENSIFY定位为逐轮独立控制、软件与机电融合的fluid-free平台,代表更长期的EMB/干式方向。 该路线的量产障碍主要集中在轮端环境耐久、热管理、驻车保持、非簧载质量、供电冗余、失效后的安全状态和法规接受度等方面。
路线判断 当前量产平台不宜盲目追求完全无液压。集成式EHB在再生制动融合、响应速度、布置和成本之间仍具有现实平衡;面向L3/L4或高可用底盘,应优先建设双电源、双控制逻辑、独立感知、故障降级和明确的机械/液压后备边界。 |
第二章 研发与量产技术路线
2.1 基础制动架构:先定义后备边界
项目初期应冻结液压回路、踏板耦合、再生—摩擦制动分配、驻车制动和后备机制。对于踏板解耦架构,应明确驾驶员能否直接建立足够制动力、单回路或单执行器失效后保留多少制动能力,以及电源和通信同时受影响时的安全状态。
2.2 执行器、电机、阀体与控制器
应把泵、电机、阀体、压力/位移/轮速传感器、制动ECU、供电、通信、线束和机械接口作为整体管理。单个部件合格不等于系统合格,不能只验证常温满电下的建压时间。
2.3 冗余与降级:高可用制动的核心
冗余不应简单理解为增加一套同样硬件。有效冗余应降低共因失效,使控制逻辑和感知链路能够交叉监测,使故障检测具备可证明的覆盖率,并使降级路径能够被驾驶员理解、与纵向控制和能量回收协调。
2.4 软件与OTA:制动控制进入持续交付时代
应建立软件版本、标定参数、硬件兼容性、依赖关系、签名、密钥、更新包、回滚、失败恢复和更新后再验证机制。ISO 24089可作为软件更新工程基线,R156则将车辆软件更新管理纳入型式批准语境。
2.5 测试验证:从模型到法规实车
应建立“模型—软件—硬件—台架—环境/耐久—实车—法规—量产”验证阶梯。MIL/SIL/HIL用于控制逻辑和故障注入,台架用于验证压力、流量、响应和耐久,实车用于验证制动距离、稳定性、驾驶员接管、能量回收切换和整车网络行为。
2.6 量产质量:把安全设计变成一致性
将DFMEA/PFMEA、控制计划、PPAP、关键参数冻结、二供管理、批次追溯、EOL泄漏/电气/诊断测试、软件刷写和密钥管理纳入同一变更流程。

图3 EHB验证证据阶梯:每一项测试都要回溯到需求、故障假设、软件版本和目标市场法规。
第三章 海内外法规与标准合规框架

图2 EHB合规边界一张图:法规/强标、工程标准、OEM证据和CRA的责任边界。
EHB合规不宜将标准、法规、认证和客户要求混为一谈。建议按照“适用对象、具体要求、证明主体和证据流向”进行分层管理。
数据口径校核 本版已按官方页面复核关键日期和属性:GB 21670-2025为强制性国家标准,2025-05-30发布、2026-01-01实施;GB 44495/44496为强制性国家标准,2024-08-23发布、2026-01-01实施;CRA主要求自2027-12-11适用,主动遭利用漏洞和严重事件报告义务自2026-09-11适用。ISO 26262与ISO/SAE 21434仍应表述为国际工程标准,不可替代型式批准或强制性国家标准。 |
层级 |
典型文件 |
主要责任主体 |
EHB交付证据 |
中国强制性要求 |
GB 21670-2025;GB 44495/44496;工信部准入 |
车辆/整车体系及供应链 |
制动性能、信息安全、软件升级、准入与一致性 |
欧盟/UNECE型式批准 |
EU 2018/858;EU 2019/2144;UN R13/R13-H、R140/R139、R155/R156 |
整车制造商及申请主体 |
制动/稳定性/辅助功能、CSMS/SUMS和型式批准文件 |
工程标准 |
ISO 26262;21434;21448;24089;GB/T 34590 |
OEM、Tier 1、Tier 2 |
HARA/FSC/TSC、TARA、SOTIF场景、软件更新和安全案例 |
OEM合同/最佳实践 |
APQP、FMEA、PPAP、DV/PV、漏洞SLA |
按合同约束的供应链成员 |
过程能力、追溯、变更、现场监测与召回协作 |
欧盟横向数字法规 |
CRA 2024/2847 |
数字元素产品制造商、进口商等 |
风险评估、技术文档、漏洞、SBOM、支持期和事件报告 |
第四章 功能安全:ISO 26262与GB/T 34590的工程应用
ISO 26262:2018面向量产道路车辆中的安全相关E/E系统,重点处理由故障行为导致的危害。针对EHB,应从传感器、控制器、执行器、通信和供电故障出发,以Item边界开展HARA,再形成安全目标、功能安全概念、技术安全概念、硬件/软件安全需求、验证确认和安全案例。 中国GB/T 34590-2022为对应推荐性系列,其项目约束力取决于法规、OEM合同、认证方案或项目安全计划的引用。
需要区分三件事:ASIL是整车危害分析和安全目标的结果,不是产品标签;ISO 26262解决故障安全,不替代制动性能法规、EMC、产品责任或网络安全;安全案例不是一份证书,而是由需求、假设、分析、验证和独立确认措施组成的可审计论证。
项目底线 对外宣传可说“按ISO 26262流程开发”或“具备某项目安全案例/评估结果”;除非明确第三方范围和证书,不要笼统写成“EHB已获得ISO 26262认证”或“所有EHB必须ASIL-D”。 |
第五章 网络安全、软件更新与R155/R156
ISO/SAE 21434:2021覆盖道路车辆E/E系统从概念、开发、生产到运行、维护和退役的网络安全风险管理。对EHB,典型工作产品包括资产与接口清单、TARA、网络安全目标和需求、供应商依赖、测试验证、漏洞处理、SBOM、密钥与诊断口控制以及事件响应。
R155和R156的直接责任通常落在车辆制造商的型式批准和CSMS/SUMS上。供应商不会因为交付EHB而自动取得独立R155/R156批准,但会通过OEM供应商管理、接口控制和证据审核被纳入责任链。合同应明确整车CSMS/SUMS、产品TARA、SBOM、漏洞接收、更新签发以及更新对制动性能和安全目标的影响由谁负责。
中国GB 44495-2024和GB 44496-2024属于强制性国家标准:前者覆盖汽车整车信息安全,后者覆盖具备软件升级功能车辆的软件升级;官方信息显示二者均于2024-08-23发布、2026-01-01实施。 零部件供应商不能以“不是整车”为理由不准备相关证据。
第六章 CRA与汽车型式批准的边界
Regulation (EU) 2024/2847(CRA)是面向具有数字元素的硬件、软件及远程数据处理解决方案的横向法规。CRA于2024-12-10生效,主要求自2027-12-11适用;主动遭利用漏洞报告义务自2026-09-11适用,Chapter IV自2026-06-11适用。
EHB控制器、嵌入式软件以及诊断/更新接口具有进入CRA分析范围的事实基础,但不能仅因“汽车零部件”就断言一定豁免,也不能仅凭产品名称断言一定需要单独贴CRA CE。应结合是否单独投放、产品品牌、硬件/软件边界、远程数据处理、进口商/分销商角色及汽车专门法规逐项判断。
CRA核心要求包括风险评估、技术文档、安全默认配置、漏洞管理、第三方组件尽调、SBOM、补丁与安全分发、支持期和事件报告。建议提前建立产品TARA、SBOM、漏洞SLA、修复验证、版本追踪和OEM协同机制。
三个常见误区 “CRA合规=整车型式认证”;“ISO/SAE 21434证书=R155批准”;“供应商交付TARA=供应商独立取得R155批准”。三者都不准确。 |
第七章 中国、欧盟与美国市场准入
市场 |
主线文件 |
准入机制 |
EHB供应商重点 |
中国 |
工信部准入;GB 21670-2025;GB 44495/44496 |
强标、公告/准入、生产一致性 |
按整车/车型和国家标准准备,证据通过OEM传递 |
欧盟/UNECE |
EU 2018/858;EU 2019/2144;UN R13/R13-H、R140/R139、R155/R156 |
型式批准、系统/部件投放、市场监督 |
冻结法规系列号、车型类别、R155/R156责任与技术文件 |
美国 |
FMVSS 135及49 CFR 571.135 |
制造商自我认证 |
准备车辆级性能与故障证据,不能以UNECE证书替代 |
其他市场 |
当地采纳的UN法规、国家强标和认证制度 |
因国家/地区而异 |
单独核对车辆类别、法规系列、实施日期和责任主体 |
中国项目应优先冻结车辆类别、GB 21670-2025适用性和实施安排,再将EHB故障策略、再生制动接口、诊断和软件升级纳入整车验证。欧盟项目需同时冻结EU 2018/858、EU 2019/2144、实施法规、UN法规系列和车型日期;美国项目应按FMVSS 135准备车辆级性能和故障证据。
第八章 产品责任、数据治理与供应链证据

图4 从故障、攻击或更新失败到证据闭环、售后和持续改进。
制动安全、网络安全、软件更新和数据治理相互关联,但不是同一套法律问题。中国汽车数据规则、GDPR和欧盟Data Act应按数据字段、主体、地域、目的和角色单独判断。含VIN、驾驶人、位置、轨迹或售后关联信息的数据,不能因为来自EHB就自动被当作非个人数据。
供应链合同建议写清六类责任:产品安全目标和接口假设;安全与网络安全工作产品;软件版本、SBOM和密钥;二供、停产和替代料;漏洞、缺陷、事故和召回时限;现场数据、跨境传输和证据留存。EHB的泵/电机/阀体、传感器、线束、供电、软件工具链和摩擦制动件,应按安全影响分层。
第九章 研发与量产落地路线:24个月工程节奏
阶段 |
核心动作 |
关键交付物 |
0–3个月:边界冻结 |
确定车型、市场、车辆类别、拓扑、后备策略、软件和数据边界 |
法规矩阵、Item边界、HARA/TARA计划、接口清单 |
3–9个月:架构与样件 |
完成执行器、供电、通信、诊断、冗余和降级设计 |
FSC/TSC、网络安全概念、DV计划、初版SBOM |
9–15个月:系统验证 |
开展MIL/SIL/HIL、台架、环境、耐久、EMC、故障注入和实车验证 |
验证报告、问题闭环、更新/回滚测试、法规准备 |
15–21个月:量产准备 |
完成PFMEA、控制计划、PPAP、EOL、刷写/密钥、二供和变更流程 |
量产安全案例、过程审核、追溯、生产一致性 |
21–24个月及以后:运行监测 |
建立漏洞响应、现场失效、软件更新、召回协作和再验证 |
CSMS/SUMS接口、PSIRT、版本追踪、持续改进 |
越晚发现液压后备、电源冗余、诊断口权限或软件回滚不满足目标市场要求,返工成本越高。对准备进入欧盟的企业,CRA的漏洞和支持期要求将把售后软件能力从加分项变成产品生命周期能力。
结论:EHB供应商的核心竞争力是证据链
EHB竞争不会只围绕泵、电机或阀体展开。更重要的是:能否清晰定义制动系统边界,能否用可验证的冗余与降级处理单点故障,能否让软件更新不破坏制动安全,能否在不同制度下快速重组证据,能否把供应链和售后责任延伸到整车生命周期。建议将投资重点放在高可用制动架构、功能安全与网络安全工程、自动化测试与故障注入平台、量产一致性与变更控制、漏洞/更新/数据治理运营能力。
合规使用提示
本报告用于技术路线研判、研发策划和供应链沟通,不替代目标市场的法律意见、型式批准申请、第三方安全评估、制动试验或数据合规审查。涉及2026年以后实施、修订、欧盟CRA汽车专门边界、中国公告/认证实施细则和具体车型适用性的内容,应在项目冻结前重新核对官方文本、批准机构要求和OEM合同。
项目启动前十项核对清单
序号 |
核对项 |
完成标准 |
1 |
目标市场与车辆类别 |
冻结中国/欧盟/美国及M、N、O类别,记录适用法规系列和日期 |
2 |
EHB系统边界 |
明确踏板、液压/轮端执行、驻车、再生制动、ESC/AEB接口 |
3 |
安全目标 |
完成Item、HARA、FSC/TSC和故障降级假设 |
4 |
网络安全边界 |
完成资产、接口、TARA、诊断口、密钥和SBOM责任划分 |
5 |
软件更新 |
明确版本、依赖、签名、回滚、低电量阻断和更新后再验证 |
6 |
验证矩阵 |
覆盖MIL/SIL/HIL、台架、环境、EMC、耐久、实车和法规试验 |
7 |
量产控制 |
冻结PFMEA、控制计划、PPAP、EOL、批次追溯和二供策略 |
8 |
变更管理 |
建立硬件、软件、标定、供应商变化的安全/法规影响分析 |
9 |
漏洞与缺陷 |
明确漏洞SLA、事件升级、现场失效、召回和证据留存 |
10 |
数据治理 |
区分诊断、质量、位置、VIN和个人信息,明确跨境与最小化原则 |

