在工业自动化和机器人发展的过程中，功能安全正在从一个标准合规问题，逐渐变成系统设计的底层约束。
过去，工业电子设备更多强调控制精度、响应速度、功耗、成本和可靠性。如今，随着机器人、自动化产线、移动设备以及智能控制系统与人员、设备和环境发生交互，需要确认系统故障后的风险程度，是否可以将系统切换至安全状态。
德州仪器（TI）最近的一个讲座，通过系统性解释了功能安全的基本概念、风险评估方法、硬件失效分析逻辑，以及TI如何通过产品、文档、认证和系统工程支持，帮助客户完成从芯片选型到系统级安全设计的闭环。
功能安全正在成为新门槛
随着工业自动化和机器人市场正在显著增长，根据《全球自动化市场预测》以及《2024年工业机器人市场报告》资料显示，整个工业机器人的市场2026年为244.3亿美元，2034年将成长值773.6亿美元，年复合成长率达15.5%，工业自动化市场将由2024年的1979.8亿美元成长值2033年的4264.5亿美元，年复合增长率达8.%。高速成长下，功能安全也正在变得越来越重要。
更多电子设备将被引入自动化产线、协作机器人、工业控制系统以及智能设备之后，系统本身不是封闭的控制单元，而是越来越多地参与到人与机器、机器与环境之间的交互之中。因此，设备失效所带来的后果也在扩大，它可能不只是导致停机、报错或性能下降，还可能造成人身伤害、设备损坏、生产中断甚至环境风险。
在这种趋势下，各类功能安全标准开始成为工业电子设计绕不开的依据。比如，IEC 61508作为电子、电气及可编程电子安全相关系统的基础功能安全标准，提供了通用的方法论；ISO 13849更多面向机械安全控制系统；ISO 10218则与工业机器人安全密切相关。对于中国市场而言，相关国家标准和本地化要求也在持续完善，例如GB/T 19001-2016，这意味着功能安全已经不再只是欧美市场认证中的附加要求，而是逐渐成为工业和机器人产品进入主流市场的基础约束。
但从标准要求走向工程落地并不容易。很多客户在推进功能安全项目时，首先遇到的是成本和周期问题。功能安全合规产品通常需要经过更严格的开发、验证和认证，器件成本、开发投入和项目周期都会上升。
其次是团队经验问题，功能安全并不是普通硬件设计或软件开发的简单延伸，它需要从需求定义、风险分析、架构设计、诊断机制、验证确认到文档追溯形成完整流程，如果团队中缺少熟悉功能安全标准和项目组织的人，实施难度会明显增加。
第三是供应商选择问题，不同芯片和系统供应商提供的安全产品、认证深度、文档完整度和系统支持能力并不一致，客户很难仅凭器件规格书判断某个产品是否真正适合自己的安全目标。
最后，功能安全还必须在成本、可用性、功耗、面积和产品复杂度之间取得平衡，这也是很多项目从概念阶段走向量产阶段时最难处理的地方。
功能安全的本质
功能安全的核心，并不是让系统永远不发生故障，而是让系统在故障发生时不会进入不可接受的危险状态。按照IEC 61508的思路，功能安全关注的是电子电气系统能否避免不可接受的风险。换成工程语言，它需要回答三个问题：第一，系统发生危险事件的概率是否已经低于可接受风险；第二，如果系统以危险方式运行，是否能够及时检测到这种异常；第三，一旦检测到风险，系统是否能够进入安全状态。
这三个问题实际上对应了功能安全的三层含义：预防、检测和响应。预防强调在设计阶段尽可能减少危险发生的概率；检测强调系统能够识别已经发生或正在发生的故障；响应则强调系统在故障被识别后必须采取确定性的安全动作。对于电机控制系统来说，这个安全动作可能是安全转矩关断；对于工业PLC来说，可能是切断危险输出；对于机器人来说，可能是限制速度、停止运动或进入安全监控状态；对于电源系统来说，可能是触发欠压、过压、过流或复位保护。
因此，功能安全不是单纯的可靠性设计，也不是简单堆叠冗余器件。可靠性更关注产品在规定条件下持续完成预期功能的能力，而功能安全更关注当产品无法正常完成预期功能时，系统是否仍能避免危险后果。一个系统可以很可靠，但未必具备充分的功能安全能力；反过来，一个功能安全系统也并不是完全不会故障，而是需要以可分析、可验证、可追溯的方式证明故障发生后的风险仍处在可接受范围内。
功能安全等级介绍
在功能安全体系中，安全能力通常需要通过等级表达。其中一套是SIL，也就是Safety Integrity Level，安全完整性等级；另一套是PL，也就是Performance Level，性能等级。
SIL通常用于IEC 61508、IEC 62061等标准中，从SIL 1到SIL 4，等级越高，安全完整性要求越高。PL通常用于ISO 13849等机械安全标准中，从PL a到PL e，同样表示安全能力由低到高。尽管两套体系并非完全相同，但在工程实践中存在一定对应关系，例如PL e通常可以对应到SIL 3量级，PL d通常可以对应到SIL 2量级。工业和机器人系统往往同时受到不同标准约束，工程团队需要在系统设计早期就明确目标安全等级，否则后续器件选型、架构设计、诊断覆盖率、文档交付和认证路径都会受到影响。
不过，SIL或PL并不是贴在产品上的营销标签。一个系统要达到某个安全等级，背后必须有风险评估、开发流程、硬件失效分析、软件验证、安全机制、系统验证以及第三方评估等一整套活动支撑。也就是说，安全等级不是最后才申请的证书，而是从项目定义阶段就必须倒推的工程约束目标。
功能安全风险评估
任何功能安全开发都要从风险评估开始。风险本质上由两部分组成：危害事件发生的可能性，以及危害事件造成后果的严重程度。工程团队在产品立项阶段，就需要分析系统中的各项功能是否可能导致不期望的后果，是否需要按照功能安全流程开发，如果需要，又应该达到什么安全等级。
这个过程并不是简单列出几个故障模式，而是要从系统顶层出发，分析潜在危害事件、暴露程度、出现频率、可避免性以及严重程度。比如一台协作机器人在低速轻载状态下发生控制异常，与一台高速重载工业机器人在人员可接近区域发生控制异常，风险等级显然不同；同样，一个电源监控器失效导致普通设备复位，与一个安全控制器供电异常却未被检测，后果也完全不同。
确定目标SIL或PL等级之后，后续工作本质上就是将初始风险降低到可接受范围。其中的安全标准并不是只告诉设计工程师“你要安全”，而是通过安全等级反向规定了工程团队需要做哪些活动、达到哪些量化指标、提供哪些证明文档。安全等级越高，意味着系统在开发流程、硬件架构、诊断机制、验证深度和独立评估方面都需要投入更多工程资源。
失效的意义
风险的根源来自失效，而功能安全设计首先要理解失效的类型。按照功能安全方法论，失效大体可以分成两类：系统性失效和随机硬件失效。
系统性失效通常来自设计本身的问题，例如需求定义不完整、算法设计错误、软件bug、接口理解偏差、开发流程不规范、验证覆盖不足等。这类失效的特点是具有一定重复性，往往不是器件随机坏了，而是系统在设计之初就埋下了错误。比如安全需求没有被正确分解到软件模块，某个边界条件没有被测试，某个异常状态没有被定义，最终都可能导致系统在特定场景下进入危险状态。
应对系统性失效，靠的不是提高芯片冗余数量，而是严格的开发流程。需求需要被管理和追溯，设计需要能够向上对应安全目标、向下落实到实现和验证，每一条安全需求都要能够证明自己被设计、实现、测试和确认。软件语言、编码规范、工具链、评审流程、独立验证和确认活动，也都属于控制系统性失效的重要组成部分。
随机硬件失效则来自硬件物理特性，例如器件老化、短路、开路、存储位翻转、瞬态扰动、时钟异常、电源异常等。它的特点是不可能被完全消除，因为任何硬件都会受到物理过程、工艺波动和运行环境的影响。面对随机硬件失效，工程师不能假设它永远不会发生，而是要在架构设计中引入诊断机制、冗余机制和安全响应机制，使系统能够在失效发生后检测异常，并将系统带入安全状态。
这也是硬件和软件在功能安全分析中的一个重要差异。硬件既可能存在系统性失效，也可能存在随机硬件失效；而软件本身不会像硬件一样因为老化或短路发生随机物理失效，因此软件安全更多聚焦系统性失效的控制。
通过系统架构解决功能安全
针对随机硬件失效，常见的系统架构可以分为单通道和冗余通道。单通道架构只有一条实现安全功能的路径，因此不具备硬件故障容忍能力。一旦通道中的关键环节发生危险失效，如果系统没有足够诊断能力，就可能导致安全功能失效。单通道架构并不等于不安全，但它对诊断能力要求更高，系统必须尽可能发现通道中的危险失效，并在异常出现后及时进入安全状态。
冗余通道架构则通过增加第二条甚至更多通道，使系统具备一定的故障容忍能力。例如两个传感器、两个控制通道、两个驱动链路或两个相互校验的处理单元，可以在其中一个通道发生故障时，仍然保留执行或判断安全功能的能力。这种架构可以提高系统安全能力，但也会带来成本、面积、功耗、软件复杂度和验证工作量的增加。
系统功能安全常涉及到一个名词HFT，也就是Hardware Fault Tolerance，硬件故障容忍度。HFT = 0表示系统不能容忍一个硬件故障，通常对应单通道或无冗余架构；HFT = 1表示系统可以容忍一个硬件故障，即一个通道失效后，系统仍能维持安全功能。简单来说，单通道架构通常是HFT = 0，因为只有一个通道。；双通道架构通常是HFT = 1，因为两个通道中只要一个通道仍能完成安全功能，系统就可以继续保持安全能力。
不过需要指出的是，冗余架构并不天然等于安全。如果两个通道共享同一个电源、同一个时钟、同一个参考电压或同一条关键通信链路，那么一个共同资源失效就可能导致两个通道同时失效，这就是共因失效。功能安全设计中必须认真处理共因失效问题，否则冗余只是形式上的冗余，并不能真正提升系统安全能力。
功能安全的量化指标
功能安全最终必须落到量化指标上，而不是只停留在概念层面，有几种常见的评估方法。
首先是失效率。硬件失效率可以进一步分为安全失效、危险失效、可检测失效和不可检测失效。在功能安全中，最受关注的是危险且不可检测的失效，因为这类失效最可能导致安全目标被违反，也最可能对人员、设备或环境造成伤害。
其次是PFH，也就是Probability of dangerous Failure per Hour，每小时危险失效概率。对于连续运行或高需求模式的安全系统来说，PFH是衡量随机硬件失效风险的重要指标。PFH越低，说明危险失效发生概率越低，系统越容易满足更高安全等级要求。
另一个重要指标是SFF，也就是Safe Failure Fraction，安全失效分数。SFF反映的是安全失效和可检测危险失效在总失效中的占比。换句话说，如果系统中危险不可检测失效越少，SFF就越高，说明系统对失效的诊断和安全覆盖能力越强。
PFH、SFF和HFT共同构成了硬件安全能力的重要评价维度。一个更好的安全设计，通常意味着危险失效概率更低、诊断覆盖能力更高，并且能够根据应用场景合理选择单通道、双通道或多通道架构。但这些指标之间并不是孤立的，它们最终都要与系统成本、可用性、开发周期和应用需求一起权衡。
功能安全文档
功能安全项目中，文档不是形式化交付物，而是系统能否通过评估和认证的重要证据，其中包括FMEDA、安全手册和认证报告。
FMEDA的全称是Failure Modes, Effects and Diagnostic Analysis，即失效模式、影响与诊断分析。它会系统性分析硬件电路中可能出现的各种失效模式、对应失效率、失效影响、已经实施的安全机制以及诊断覆盖能力，并最终计算出PFH、SFF等指标。对于客户来说，FMEDA的价值在于，它可以帮助客户判断某颗芯片或某个子系统是否适合自己的目标安全等级，也可以作为客户系统级安全分析的重要输入。
安全手册则用于说明供应商在产品开发时假设的系统级安全目标、使用条件、安全机制、诊断能力、客户需要执行的外部诊断、系统集成注意事项等。它实际上划清了芯片供应商和系统客户之间的安全责任边界。芯片可以提供某些安全机制和诊断能力，但客户必须按照安全手册的假设和要求使用，才能在系统级实现目标安全能力。
认证报告或评估报告则用于证明产品开发流程、硬件安全指标和相关安全机制已经经过第三方或内部评估，比如TUV认证等等，诸如TI等芯片厂商会提供第三方认证或内部评估报告，这对于客户缩短认证路径、降低安全论证难度具有直接价值。
TI的功能安全路径
以TI为例，其功能安全能力并不是从单颗芯片开始，而是建立在开发流程、产品组合、文档体系和系统工程支持之上。TI内部拥有经过IEC 61508认证的硬件和软件开发流程，安全合规产品会按照这些流程进行开发，以降低系统性失效风险。
在产品开发阶段，TI会从危害分析和风险分析出发，确定安全需求和目标安全等级，再按照相应流程完成设计、实现、验证和确认。对于随机硬件失效，TI会通过架构设计、安全机制和FMEDA分析来控制失效率并量化诊断能力。对于客户系统设计，TI则通过安全手册、参考设计、认证报告和系统工程团队支持，帮助客户理解芯片假设、使用条件和系统级安全实现方式。
这也解释了为什么功能安全不能被简单理解为“买一颗安全芯片”。真正的功能安全项目，需要产品线、系统工程与支持团队共同参与。产品线负责按照认证流程开发安全产品，并提供FMEDA、安全手册和认证资料；系统工程团队则可以从项目概念阶段介入，帮助客户理解安全架构、工具链、软件配置、参考设计和系统级验证问题。
对于很多客户来说，这种支持的意义在于降低功能安全项目的不确定性。因为安全设计最难的地方往往不是某一个技术点，而是系统级证明链条太长：从标准理解到风险分析，从安全需求到器件选型，从芯片机制到系统架构，从FMEDA输入到最终认证，每一个环节都可能影响项目进度。TI可以与客户一同，将这些环节连接起来的工程支撑能力。
TI的功能安全处理器
从应用方向看，TI将功能安全产品和方案主要放在几个工业场景中展开。
首先是安全电机控制。电机控制是工业自动化和机器人中最典型的安全场景之一，涉及运动控制、驱动保护、转矩限制、停机响应等功能。TI的C2000控制器长期面向电机控制应用，具备较强的实时控制能力，适合用于高性能电机驱动系统。同时，TI也提供基于Arm架构的MCU产品AM26系列，以满足不同客户在控制性能、软件生态和成本上的需求。围绕这些器件，TI还提供支持STO等安全功能的参考设计，使客户可以在现有架构基础上更快完成安全功能实现。
其次是安全系统控制器。工业系统中的安全控制器需要承担安全逻辑处理、状态监控、异常判断和安全输出等任务，因此对MCU或处理器的安全机制、诊断能力、软件工具链和认证资料都有较高要求。TI在这一方向提供了多类经过功能安全认证或面向功能安全应用的控制器、处理器和相关开发工具，帮助客户面向SIL 2、SIL 3等应用构建系统级方案。
第三类是安全感知。随着工业设备和机器人具备更强环境感知能力，传感器本身也开始成为安全链路的一部分。TI的毫米波雷达、传感器和相关感知类信号链产品，可以用于人员检测、区域防护、距离感知、物体识别和工业安全监控等场景。对于机器人和自动化设备而言，安全感知的价值在于让系统不仅能在故障后停机，也能更早识别潜在危险状态。
第四是安全PLC。PLC是工业控制系统的核心节点，而安全PLC则需要处理安全输入、安全逻辑和安全输出。它不仅要保证控制逻辑正确，还要确保通信、处理器、输入输出模块和电源等环节的安全相关数据能够被诊断和验证。TI围绕工业控制和PLC应用提供控制器、通信接口、隔离、电源和参考设计，使客户能够围绕完整子系统构建功能安全能力。
第五是安全通信。工业以太网和现场总线在自动化系统中的重要性不断提升，安全相关数据需要在分布式设备之间可靠传输。安全通信关注的不只是带宽和实时性，还包括数据完整性、时序正确性、通信错误检测以及安全协议支持。TI在工业通信控制器、以太网接口和相关参考设计方面的积累，可以帮助客户构建符合安全要求的通信链路。
第六是安全电源。电源系统在功能安全中经常被低估，但实际上控制器、传感器、驱动器和通信模块都依赖稳定供电。电源异常可能导致安全功能失效，因此欠压、过压、过流、复位、电源监控和冗余供电都与系统安全密切相关。TI的电源产品组合覆盖宽输入、宽输出、电源管理、监控和保护等多类器件，可以支持客户在系统层面实现更完整的安全电源设计。
广泛的产品组合
值得注意的是，TI不只提供最高等级的功能安全认证产品。对于不同客户和不同应用，TI还提供Functional Safety-Compliant、Functional Safety-Capable以及Functional Safety Quality-Managed等不同层次的产品和文档支持。
这主要是因为，并不是所有工业应用都需要最高安全等级，也不是所有子系统都必须使用完整认证产品。有些客户可能需要已经经过第三方认证、文档完整、可以直接用于高SIL等级系统的产品；有些客户则可能出于成本、架构灵活性或系统冗余设计考虑，选择结构更简单、价格更低，但仍能提供安全分析支持文档的产品。功能安全项目的关键，不是盲目追求最高等级，而是在风险评估基础上，为每个安全功能选择合适的器件、架构和诊断机制。
这也是TI强调产品组合广度的原因。客户可以根据自身系统需求，在不同产品类别、不同安全等级和不同成本区间中选择合适方案，再结合TI提供的FMEDA、安全手册、认证报告和参考设计完成系统级安全论证。
结语
功能安全正在成为工业自动化和机器人系统的新门槛。它不再只是认证阶段需要补充的一组文件，而是从项目概念、需求定义、风险评估、架构选择、器件选型、软件开发、硬件诊断到系统验证的完整工程体系。对于客户来说，真正的挑战不是理解某一个术语，而是如何把SIL、PL、PFH、SFF、HFT、FMEDA、安全手册和认证报告连接成一条完整的系统级功能安全证明链。
同时，值得注意的是功能安全不能依靠单点能力解决，而需要供应商从产品开发流程、器件安全机制、文档交付、参考设计和系统工程支持多个维度共同参与。随着工业机器人、协作机器人、安全PLC、智能电机控制、安全通信和安全电源等应用持续增长，功能安全将越来越像嵌入式系统中的基础能力，而不是少数高端项目的附加要求。
对于工程师而言，功能安全设计的起点不是先问要不要冗余，而是先问系统面临什么风险、目标安全等级是什么、哪些失效可能导致危险、哪些失效可以被检测、系统能否进入安全状态，以及这些判断能否被文档和数据证明。只有这样，功能安全才真正从标准条文变成可落地的系统工程。