1. 从“辅助”到“守护”EPS功能安全为何成为焦点最近在跟几个做底盘电子的朋友聊天话题总绕不开一个词功能安全。特别是聊到电动助力转向系统也就是我们常说的EPS大家的感觉是这玩意儿以前就是个“力气活”现在却越来越像个“技术活”而且还是个“安全活”。这种感觉很对因为EPS的功能安全已经从一项“加分项”变成了“及格线”甚至是“生命线”。为什么这么说回想一下早期的EPS核心目标很简单用电机替代液压省油同时让方向盘更轻便。工程师们关注的是助力曲线调得好不好手感顺不顺成本能不能再降一点。那时候谈安全更多是机械层面的冗余设计和失效模式分析。但今天情况完全不同了。随着汽车电子电气架构从分布式走向域集中甚至中央计算随着L2、L2级别辅助驾驶的普及EPS的角色发生了根本性转变。它不再仅仅是一个执行驾驶员转向指令的“助手”而是成为了高级驾驶辅助系统与驾驶员之间的关键“仲裁者”和“安全执行器”。想象一个典型的AEB自动紧急制动或LKA车道保持辅助场景。当系统判断需要紧急转向避让时指令会下发给EPS。此时EPS必须在极短时间内、以极高的可靠性执行这个转向请求。如果EPS在执行过程中失效——比如电机卡滞、扭矩输出错误、或者干脆不响应——后果可能是灾难性的。因此EPS的功能安全等级要求水涨船高。从过去满足基本的ASIL B汽车安全完整性等级B就够用到现在越来越多的主机厂要求EPS必须达到ASIL D这是功能安全等级的最高要求。这个趋势背后是整车电子电气功能复杂度的指数级增长以及“软件定义汽车”时代对底层执行器可靠性的严苛拷问。2. 功能安全的核心从失效管理到系统性的安全文化当我们谈论EPS的功能安全时很多人的第一反应是加个监控芯片、做双路冗余。这没错但这只是技术实现的冰山一角。功能安全的本质是一套贯穿产品整个生命周期概念、开发、生产、运维、报废的系统性工程方法。它的目标不是保证系统永不失效——这在物理世界是不可能的——而是确保即使发生失效系统也能进入或维持在一个安全的状态不会对人员造成伤害。对于EPS而言这意味着我们需要系统地识别和分析所有可能的危害。比如非预期的助力转向过轻导致车辆失控、助力丧失转向过重、反向助力向错误方向转向等。针对每一个危害我们需要评估其严重度S、暴露概率E和可控性C从而确定其需要达到的ASIL等级。这个过程就是危害分析与风险评估。确定了安全目标后才是技术实现。这里就引出了功能安全的核心概念安全机制。安全机制是为了探测、控制或缓解失效而采取的技术措施。在EPS里典型的安全机制包括扭矩传感器冗余与合理性校验主扭矩传感器和冗余扭矩传感器的信号会进行实时比对。如果差值超过阈值系统会判断传感器失效并触发安全状态如逐渐降低助力并给驾驶员明确的警示。电机位置/电流监控通过解析器或霍尔传感器监控电机实际位置和电流与基于控制模型计算出的期望值进行对比。如果电机实际出力与指令严重不符可能意味着电机、逆变器或控制逻辑出了问题。双核锁步LockstepMCU这是目前满足ASIL D高等级需求的常见方案。两个完全相同的CPU核心执行相同的程序每个时钟周期对比运算结果。一旦结果不一致说明芯片内部出现了随机硬件失效如粒子撞击导致的位翻转系统会立即采取安全措施。独立安全监控单元除了主控MCU额外设置一个简单的、高可靠性的监控MCU比如英飞凌的TLE系列。它的任务单一而明确监控主MCU是否“活着”看门狗、关键信号是否在合理范围内。一旦发现异常它有能力越过主MCU直接控制继电器切断电机电源。注意功能安全不是“堆料”。盲目增加冗余传感器或芯片如果不进行严格的失效模式与影响分析可能会导致系统更加复杂引入新的共因失效或级联失效点。例如两个传感器如果共用同一个电源或同一个接地引脚那么电源的失效就会导致两个传感器同时失效冗余就失去了意义。因此独立性分析是功能安全设计的关键一环。3. 趋势一软件复杂度的飙升与安全软件架构的挑战如果说硬件冗余是功能安全的“筋骨”那么软件就是其“灵魂”。随着EPS功能日益复杂如可变转向比、主动回正、与ADAS的协同等其软件代码量从几十万行激增至百万行级别。如此庞大的软件如何保证其功能安全这就催生了基于模型的设计和 AUTOSAR 自适应平台的应用趋势。基于模型的设计正在成为主流。工程师不再直接编写C代码而是在Simulink/Stateflow这样的图形化环境中搭建控制模型、设计状态机。这种方式的好处是模型本身就是一种清晰、无二义性的“活文档”便于团队沟通和评审。更重要的是工具链可以支持从模型自动生成代码并且能进行形式化验证和早期仿真测试在代码诞生之前就发现很多逻辑缺陷。Matlab/Simulink自身也提供了功能安全工具箱可以帮助进行需求追踪、模型覆盖率分析等以满足ISO 26262对软件开发流程的要求。AUTOSAR 自适应平台则是应对“软件定义汽车”的架构答案。传统的Classic AUTOSAR适用于对实时性、确定性要求极高的底层控制EPS的底层电机控制仍属于此范畴。而Adaptive AUTOSAR则面向需要高性能计算、灵活软件部署的复杂功能如EPS上层的与ADAS交互的仲裁逻辑、个性化驾驶模式管理。Adaptive AUTOSAR强调基于服务的通信、动态部署和更强的信息安全。对于EPS而言这意味着它的部分功能模块可能会作为“服务”发布到整车网络中供ADAS域控制器调用。此时功能安全不仅要考虑EPS控制器内部的失效还要考虑通信延迟、信号篡改等来自网络的安全威胁。这就需要功能安全与信息安全Cyber Security的融合设计也就是常说的“Safety Security Co-Engineering”。一个具体的挑战是在Adaptive AUTOSAR中功能安全应用和非安全应用可能运行在同一颗高性能SoC的不同核或虚拟机上。如何确保它们之间的资源隔离避免非安全应用的崩溃或恶意行为影响安全应用这需要依赖硬件虚拟化技术和严格的中间件调度策略。4. 趋势二芯片与系统的深度融合与“预认证”方案几年前开发一款ASIL D的EPS控制器对大多数团队来说都是一场“硬仗”。你需要挑选符合功能安全要求的MCU如英飞凌的Aurix系列、NXP的S32K3系列自己设计双核锁步、内存ECC保护等安全机制编写复杂的底层驱动和安全监控软件整个过程耗时费力且充满风险。现在的趋势是芯片厂商和Tier 1供应商正在提供越来越完整的“预认证”或“交钥匙”解决方案。以NXP的S32K3系列MCU为例它不仅仅是提供了一颗符合ASIL D标准的芯片更提供了完整的SafeAssure功能安全解决方案。这包括硬件芯片内置锁步CPU、带ECC的存储器、各类内置自检、电压/时钟监控等。软件提供符合ASIL D要求的底层安全软件如安全启动、故障收集与报告、硬件测试库等。这些软件已经通过了TÜV等权威机构的认证大大降低了用户软件开发的合规风险。工具与文档提供详细的安全手册、失效模式分布报告以及配套的配置、调试工具链。对于EPS系统厂商而言采用这样的方案意味着可以将更多精力聚焦在核心的转向控制算法、手感调校和与整车的匹配上而不是从头去构建安全基础。这显著加快了开发速度降低了准入门槛但也带来了新的考量如何在不同供应商的“黑盒”安全方案之上构建自己独特的、有竞争力的系统功能这考验的是系统集成和顶层设计能力。关于网络热词中提到的“S32K312 SAF和SCST有必要吗”这正是一个具体的选型问题。SAF是NXP S32K3 MCU中的安全架构框架它提供了一系列安全机制的基础服务。而SCST是安全核心自检软件用于在启动和运行时执行对CPU核心及存储器的诊断测试。对于目标为ASIL B的系统可能芯片内置的硬件安全机制加上基本的软件监控就已足够。但如果目标定在ASIL D或者系统非常复杂那么利用SAF和SCST这类经过认证的软件组件无疑是更高效、更可靠的选择它能提供更完整的证据链用于最终的功能安全评估。5. 趋势三测试验证的虚拟化与持续化功能安全要求“证据驱动”。你不能只说“我认为它是安全的”你必须提供从需求、设计、实现到测试的全套证据证明系统达到了设定的安全目标。其中测试验证是工作量最大、也最关键的环节。传统的测试严重依赖实车和硬件在环台架成本高、周期长、场景覆盖有限。当前的趋势是利用虚拟化技术将测试左移和持续化。仿真测试的深度应用在控制器硬件出来之前就可以在PC上运行完整的虚拟车辆模型包括高精度的车辆动力学模型、轮胎模型、驾驶员模型、虚拟的EPS控制器模型从Simulink控制模型到自动生成的代码甚至包含底层软件行为模型以及虚拟的传感器/执行器模型。在这个“数字孪生”环境中可以大规模、自动化地注入各种故障扭矩传感器信号漂移、电机绕组短路、CAN通信报文丢失或错误……然后观察系统是否按照安全需求规范进入预定义的安全状态如降级助力、发出警告。这种仿真可以覆盖成千上万个在实车上难以复现或高风险的危险场景。持续集成与持续测试在敏捷开发模式下软件频繁迭代。每一次代码提交都能自动触发一系列针对功能安全的测试用例包括单元测试针对安全相关函数、模型在环测试、软件在环测试。这确保了安全问题能在开发早期被发现和修复而不是堆积到后期造成巨大的返工成本。像Jenkins、GitLab CI/CD等工具与Matlab/Simulink测试框架、静态代码分析工具的集成已经成为先进EPS开发团队的标配。关于“Matlab 2025导出EPS”这个看似不相关的热词其实也反映了工程实践中的一个细节。在基于模型的设计中所有的设计文档、架构图、仿真结果都需要被严格管理。将Simulink模型或框图导出为EPSEncapsulated PostScript这种高精度、可缩放矢量格式便于插入到Word、PDF格式的需求文档、设计文档和安全分析报告中确保文档与模型的一致性这也是功能安全流程中可追溯性要求的一部分。6. 实操中的“坑”与经验之谈理论很美好但落地过程总是充满挑战。结合一些实际项目经验分享几个常见的“坑”1. 安全机制本身的失效处理这是最容易忽略的一点。我们设计了双路传感器校验但如果校验逻辑所在的CPU核心本身失效了怎么办我们设计了看门狗但如果看门狗电路失效了呢功能安全要求我们考虑“安全机制的诊断覆盖率”。也就是说你需要为安全机制本身设计“元安全机制”。例如对于看门狗可能需要定期注入一个测试性的喂狗失败来验证看门狗复位功能是否正常。这增加了系统的复杂度和测试用例。2. 多核系统的资源冲突与时序分析现代EPS控制器多为多核架构一个核跑高速电机控制环时间关键一个核跑功能安全监控和诊断一个核处理通信和上层应用。当高优先级的安全诊断任务突然被触发时可能会抢占电机控制任务所需的CPU或总线资源导致控制环执行时间超时这本身就可能引发功能失效。因此必须进行最坏情况下的执行时间分析和资源预留这需要深厚的实时操作系统知识和精细的系统配置。3. “灰盒”集成测试的难度当你采用芯片厂商提供的预认证安全软件包时你面对的是一个“灰盒”。你清楚它的接口和功能但不完全清楚其内部实现细节。如何对你自己的应用软件与这个安全底层的交互进行充分测试如何确保你的故障注入能有效触发底层安全机制的响应这需要与供应商紧密合作获取必要的测试接口和指导并设计针对性的集成测试用例。4. 工具链的认证与置信度ISO 26262不仅对产品有要求对开发工具也有要求。尤其是用于生成代码的模型编译器、用于验证的测试工具如果它们本身有bug可能会导致产品出现系统性失效。因此对于高安全等级ASIL C/D的开发通常需要选择具有相应工具置信度等级认证的工具链或者对工具链的输出进行额外的验证。这直接影响了工具选型和开发成本。最后功能安全不是某个团队或某个阶段的任务它必须融入整个企业的研发文化和流程。从项目经理、系统工程师、软硬件开发人员到测试工程师每个人都需要有功能安全的意识。它带来的不仅是产品可靠性的提升更是一套严谨、可追溯、高质量的工程方法论这或许是汽车行业在智能化浪潮中最值得坚守的内核之一。 EPS功能安全：从ASIL B到D的演进与系统化工程实践
1. 从“辅助”到“守护”EPS功能安全为何成为焦点最近在跟几个做底盘电子的朋友聊天话题总绕不开一个词功能安全。特别是聊到电动助力转向系统也就是我们常说的EPS大家的感觉是这玩意儿以前就是个“力气活”现在却越来越像个“技术活”而且还是个“安全活”。这种感觉很对因为EPS的功能安全已经从一项“加分项”变成了“及格线”甚至是“生命线”。为什么这么说回想一下早期的EPS核心目标很简单用电机替代液压省油同时让方向盘更轻便。工程师们关注的是助力曲线调得好不好手感顺不顺成本能不能再降一点。那时候谈安全更多是机械层面的冗余设计和失效模式分析。但今天情况完全不同了。随着汽车电子电气架构从分布式走向域集中甚至中央计算随着L2、L2级别辅助驾驶的普及EPS的角色发生了根本性转变。它不再仅仅是一个执行驾驶员转向指令的“助手”而是成为了高级驾驶辅助系统与驾驶员之间的关键“仲裁者”和“安全执行器”。想象一个典型的AEB自动紧急制动或LKA车道保持辅助场景。当系统判断需要紧急转向避让时指令会下发给EPS。此时EPS必须在极短时间内、以极高的可靠性执行这个转向请求。如果EPS在执行过程中失效——比如电机卡滞、扭矩输出错误、或者干脆不响应——后果可能是灾难性的。因此EPS的功能安全等级要求水涨船高。从过去满足基本的ASIL B汽车安全完整性等级B就够用到现在越来越多的主机厂要求EPS必须达到ASIL D这是功能安全等级的最高要求。这个趋势背后是整车电子电气功能复杂度的指数级增长以及“软件定义汽车”时代对底层执行器可靠性的严苛拷问。2. 功能安全的核心从失效管理到系统性的安全文化当我们谈论EPS的功能安全时很多人的第一反应是加个监控芯片、做双路冗余。这没错但这只是技术实现的冰山一角。功能安全的本质是一套贯穿产品整个生命周期概念、开发、生产、运维、报废的系统性工程方法。它的目标不是保证系统永不失效——这在物理世界是不可能的——而是确保即使发生失效系统也能进入或维持在一个安全的状态不会对人员造成伤害。对于EPS而言这意味着我们需要系统地识别和分析所有可能的危害。比如非预期的助力转向过轻导致车辆失控、助力丧失转向过重、反向助力向错误方向转向等。针对每一个危害我们需要评估其严重度S、暴露概率E和可控性C从而确定其需要达到的ASIL等级。这个过程就是危害分析与风险评估。确定了安全目标后才是技术实现。这里就引出了功能安全的核心概念安全机制。安全机制是为了探测、控制或缓解失效而采取的技术措施。在EPS里典型的安全机制包括扭矩传感器冗余与合理性校验主扭矩传感器和冗余扭矩传感器的信号会进行实时比对。如果差值超过阈值系统会判断传感器失效并触发安全状态如逐渐降低助力并给驾驶员明确的警示。电机位置/电流监控通过解析器或霍尔传感器监控电机实际位置和电流与基于控制模型计算出的期望值进行对比。如果电机实际出力与指令严重不符可能意味着电机、逆变器或控制逻辑出了问题。双核锁步LockstepMCU这是目前满足ASIL D高等级需求的常见方案。两个完全相同的CPU核心执行相同的程序每个时钟周期对比运算结果。一旦结果不一致说明芯片内部出现了随机硬件失效如粒子撞击导致的位翻转系统会立即采取安全措施。独立安全监控单元除了主控MCU额外设置一个简单的、高可靠性的监控MCU比如英飞凌的TLE系列。它的任务单一而明确监控主MCU是否“活着”看门狗、关键信号是否在合理范围内。一旦发现异常它有能力越过主MCU直接控制继电器切断电机电源。注意功能安全不是“堆料”。盲目增加冗余传感器或芯片如果不进行严格的失效模式与影响分析可能会导致系统更加复杂引入新的共因失效或级联失效点。例如两个传感器如果共用同一个电源或同一个接地引脚那么电源的失效就会导致两个传感器同时失效冗余就失去了意义。因此独立性分析是功能安全设计的关键一环。3. 趋势一软件复杂度的飙升与安全软件架构的挑战如果说硬件冗余是功能安全的“筋骨”那么软件就是其“灵魂”。随着EPS功能日益复杂如可变转向比、主动回正、与ADAS的协同等其软件代码量从几十万行激增至百万行级别。如此庞大的软件如何保证其功能安全这就催生了基于模型的设计和 AUTOSAR 自适应平台的应用趋势。基于模型的设计正在成为主流。工程师不再直接编写C代码而是在Simulink/Stateflow这样的图形化环境中搭建控制模型、设计状态机。这种方式的好处是模型本身就是一种清晰、无二义性的“活文档”便于团队沟通和评审。更重要的是工具链可以支持从模型自动生成代码并且能进行形式化验证和早期仿真测试在代码诞生之前就发现很多逻辑缺陷。Matlab/Simulink自身也提供了功能安全工具箱可以帮助进行需求追踪、模型覆盖率分析等以满足ISO 26262对软件开发流程的要求。AUTOSAR 自适应平台则是应对“软件定义汽车”的架构答案。传统的Classic AUTOSAR适用于对实时性、确定性要求极高的底层控制EPS的底层电机控制仍属于此范畴。而Adaptive AUTOSAR则面向需要高性能计算、灵活软件部署的复杂功能如EPS上层的与ADAS交互的仲裁逻辑、个性化驾驶模式管理。Adaptive AUTOSAR强调基于服务的通信、动态部署和更强的信息安全。对于EPS而言这意味着它的部分功能模块可能会作为“服务”发布到整车网络中供ADAS域控制器调用。此时功能安全不仅要考虑EPS控制器内部的失效还要考虑通信延迟、信号篡改等来自网络的安全威胁。这就需要功能安全与信息安全Cyber Security的融合设计也就是常说的“Safety Security Co-Engineering”。一个具体的挑战是在Adaptive AUTOSAR中功能安全应用和非安全应用可能运行在同一颗高性能SoC的不同核或虚拟机上。如何确保它们之间的资源隔离避免非安全应用的崩溃或恶意行为影响安全应用这需要依赖硬件虚拟化技术和严格的中间件调度策略。4. 趋势二芯片与系统的深度融合与“预认证”方案几年前开发一款ASIL D的EPS控制器对大多数团队来说都是一场“硬仗”。你需要挑选符合功能安全要求的MCU如英飞凌的Aurix系列、NXP的S32K3系列自己设计双核锁步、内存ECC保护等安全机制编写复杂的底层驱动和安全监控软件整个过程耗时费力且充满风险。现在的趋势是芯片厂商和Tier 1供应商正在提供越来越完整的“预认证”或“交钥匙”解决方案。以NXP的S32K3系列MCU为例它不仅仅是提供了一颗符合ASIL D标准的芯片更提供了完整的SafeAssure功能安全解决方案。这包括硬件芯片内置锁步CPU、带ECC的存储器、各类内置自检、电压/时钟监控等。软件提供符合ASIL D要求的底层安全软件如安全启动、故障收集与报告、硬件测试库等。这些软件已经通过了TÜV等权威机构的认证大大降低了用户软件开发的合规风险。工具与文档提供详细的安全手册、失效模式分布报告以及配套的配置、调试工具链。对于EPS系统厂商而言采用这样的方案意味着可以将更多精力聚焦在核心的转向控制算法、手感调校和与整车的匹配上而不是从头去构建安全基础。这显著加快了开发速度降低了准入门槛但也带来了新的考量如何在不同供应商的“黑盒”安全方案之上构建自己独特的、有竞争力的系统功能这考验的是系统集成和顶层设计能力。关于网络热词中提到的“S32K312 SAF和SCST有必要吗”这正是一个具体的选型问题。SAF是NXP S32K3 MCU中的安全架构框架它提供了一系列安全机制的基础服务。而SCST是安全核心自检软件用于在启动和运行时执行对CPU核心及存储器的诊断测试。对于目标为ASIL B的系统可能芯片内置的硬件安全机制加上基本的软件监控就已足够。但如果目标定在ASIL D或者系统非常复杂那么利用SAF和SCST这类经过认证的软件组件无疑是更高效、更可靠的选择它能提供更完整的证据链用于最终的功能安全评估。5. 趋势三测试验证的虚拟化与持续化功能安全要求“证据驱动”。你不能只说“我认为它是安全的”你必须提供从需求、设计、实现到测试的全套证据证明系统达到了设定的安全目标。其中测试验证是工作量最大、也最关键的环节。传统的测试严重依赖实车和硬件在环台架成本高、周期长、场景覆盖有限。当前的趋势是利用虚拟化技术将测试左移和持续化。仿真测试的深度应用在控制器硬件出来之前就可以在PC上运行完整的虚拟车辆模型包括高精度的车辆动力学模型、轮胎模型、驾驶员模型、虚拟的EPS控制器模型从Simulink控制模型到自动生成的代码甚至包含底层软件行为模型以及虚拟的传感器/执行器模型。在这个“数字孪生”环境中可以大规模、自动化地注入各种故障扭矩传感器信号漂移、电机绕组短路、CAN通信报文丢失或错误……然后观察系统是否按照安全需求规范进入预定义的安全状态如降级助力、发出警告。这种仿真可以覆盖成千上万个在实车上难以复现或高风险的危险场景。持续集成与持续测试在敏捷开发模式下软件频繁迭代。每一次代码提交都能自动触发一系列针对功能安全的测试用例包括单元测试针对安全相关函数、模型在环测试、软件在环测试。这确保了安全问题能在开发早期被发现和修复而不是堆积到后期造成巨大的返工成本。像Jenkins、GitLab CI/CD等工具与Matlab/Simulink测试框架、静态代码分析工具的集成已经成为先进EPS开发团队的标配。关于“Matlab 2025导出EPS”这个看似不相关的热词其实也反映了工程实践中的一个细节。在基于模型的设计中所有的设计文档、架构图、仿真结果都需要被严格管理。将Simulink模型或框图导出为EPSEncapsulated PostScript这种高精度、可缩放矢量格式便于插入到Word、PDF格式的需求文档、设计文档和安全分析报告中确保文档与模型的一致性这也是功能安全流程中可追溯性要求的一部分。6. 实操中的“坑”与经验之谈理论很美好但落地过程总是充满挑战。结合一些实际项目经验分享几个常见的“坑”1. 安全机制本身的失效处理这是最容易忽略的一点。我们设计了双路传感器校验但如果校验逻辑所在的CPU核心本身失效了怎么办我们设计了看门狗但如果看门狗电路失效了呢功能安全要求我们考虑“安全机制的诊断覆盖率”。也就是说你需要为安全机制本身设计“元安全机制”。例如对于看门狗可能需要定期注入一个测试性的喂狗失败来验证看门狗复位功能是否正常。这增加了系统的复杂度和测试用例。2. 多核系统的资源冲突与时序分析现代EPS控制器多为多核架构一个核跑高速电机控制环时间关键一个核跑功能安全监控和诊断一个核处理通信和上层应用。当高优先级的安全诊断任务突然被触发时可能会抢占电机控制任务所需的CPU或总线资源导致控制环执行时间超时这本身就可能引发功能失效。因此必须进行最坏情况下的执行时间分析和资源预留这需要深厚的实时操作系统知识和精细的系统配置。3. “灰盒”集成测试的难度当你采用芯片厂商提供的预认证安全软件包时你面对的是一个“灰盒”。你清楚它的接口和功能但不完全清楚其内部实现细节。如何对你自己的应用软件与这个安全底层的交互进行充分测试如何确保你的故障注入能有效触发底层安全机制的响应这需要与供应商紧密合作获取必要的测试接口和指导并设计针对性的集成测试用例。4. 工具链的认证与置信度ISO 26262不仅对产品有要求对开发工具也有要求。尤其是用于生成代码的模型编译器、用于验证的测试工具如果它们本身有bug可能会导致产品出现系统性失效。因此对于高安全等级ASIL C/D的开发通常需要选择具有相应工具置信度等级认证的工具链或者对工具链的输出进行额外的验证。这直接影响了工具选型和开发成本。最后功能安全不是某个团队或某个阶段的任务它必须融入整个企业的研发文化和流程。从项目经理、系统工程师、软硬件开发人员到测试工程师每个人都需要有功能安全的意识。它带来的不仅是产品可靠性的提升更是一套严谨、可追溯、高质量的工程方法论这或许是汽车行业在智能化浪潮中最值得坚守的内核之一。