本页目录
实务 IV · 功能安全与可靠性
层次：业界核心、学校极少讲 ｜ 本页只讲概念框架。真实项目的安全设计与认证必须依据现行标准、由有资质人员执行，本课不构成任何工程或认证指导。 当控制系统失效会导致人员伤亡、环境破坏或重大财产损失时，"性能好"就不再是首要问题。功能安全是一套系统化的方法，用来回答：这个系统失效的可能性有多大？可以接受吗？如何证明？ 它的方法论价值远超自动化领域。
学习层：用低需求安全 toy model 把潜伏危险失效记进 proof-test 账本
1. 具体工程谜题：一年一次 proof test，潜伏失效的平均暴露概率是多少？
一个低需求模式的保护功能有危险失效率 \(\lambda_D=2\times10^{-6}\ \mathrm h^{-1}\)，诊断覆盖率 \(DC=90\%\)，proof-test 间隔为一年。未被诊断发现的危险部分会在两次测试之间潜伏；工程师要估计它在随机需求到来时的平均不可用程度，并区分这个 toy 数字、SIL/PFD 指标和真正的系统认证。
预测门，必须先作答：
- 在固定 \(\lambda_{DU}\)、完美周期 proof test 和均匀失效时刻的假设下，\(T\) 加倍会怎样影响 PFDavg 近似？
- 若总危险失效率固定，\(DC=90\%\) 的直接作用是什么？
- 一个 \(PFD_{avg}\) 数字能否单独宣布某个系统已获得 SIL 认证或“风险分数”为零？
2. 正式模型：先定义危险未检测失效率，再写近似适用条件
设 \(\lambda_D\) 是总危险失效率，诊断覆盖率 \(DC\) 只作为本 toy model 中的比例假设，则
在低需求模式、恒定独立失效率、失效时刻在 proof-test 周期内均匀分布、proof test 能发现并修复潜伏危险失效、忽略修复时间、共因失效、测试覆盖缺陷和需求期间动态的条件下，
\(PFD_{avg}\) 是无量纲的平均按需失效概率近似；\(\lambda_{DU}\) 的单位是 \(\mathrm h^{-1}\)，\(T\) 用小时。它不是一个自创的总风险分数，也不是只凭一条公式就能推出 SIL、PFH、架构约束或认证结论。
3. 动手实验：调 proof-test、诊断覆盖和需求模式，保留每一项假设
先提交三项预测，再调 \(\lambda_D\)、\(DC\)、proof-test 间隔和一个外部给定的示例目标。图中画危险失效率分解与 \(PFD_{avg}\) 随测试间隔的直线；ledger 列总危险率、\(\lambda_{DU}\)（\(\mathrm h^{-1}\)）、测试间隔（h）、\(PFD_{avg}\) 以及当前是否超过该示例目标。结果明确显示“指标计算”和“安全论证/认证”是两栏。
JavaScript 失效时的静态 fallback：取 \(\lambda_D=2\times10^{-6}\ \mathrm h^{-1}\)、\(DC=0.90\)、\(T=8760\ \mathrm h\)。则
如果把测试间隔改为 \(4380\ \mathrm h\)，在同一组假设下近似值减半；这只说明 toy 公式的比例关系。它没有纳入 1oo2/2oo3 架构、共因失效、修复时间、系统性软件失效、需求频率或标准所需的完整生命周期证据。
| 证据 | 数值 | 类型 |
|---|---|---|
| 总危险失效率 \(\lambda_D\) | \(2\times10^{-6}\ \mathrm h^{-1}\) | 输入假设 |
| 未诊断危险失效率 \(\lambda_{DU}\) | \(2\times10^{-7}\ \mathrm h^{-1}\) | 比例模型 |
| proof-test 间隔 \(T\) | \(8760\ \mathrm h\) | 运行参数 |
| \(PFD_{avg}\) | \(8.76\times10^{-4}\) | toy 近似，无量纲 |
4. 误区与模型边界
- PFDavg 不是“风险分数”：风险还需要需求频率、后果、暴露、独立保护层和系统边界；不能把多个不同量纲压成一个自创分数。
- PFDavg 也不是认证：SIL 评估还涉及架构、HFT、共因失效、系统性能力、验证、测试覆盖和现行标准；本实验不声称 SIL 等级或合规。
- 诊断覆盖率不是完美检测率：诊断本身可能漏检、误报或延迟；\(\lambda_{DU}=(1-DC)\lambda_D\) 是明确标注的比例近似。
- \(\lambda T/2\) 需要低需求和小概率条件：高需求/连续模式、非恒定失效率、修复时间、测试不完全或共因失效都需要更完整模型。
5. 正式回到安全工程：用指标定位下一份证据，而不是替代它
这张账本的正确返回值是：给定假设下的 \(\lambda_{DU}\) 与 \(PFD_{avg}\) 近似、敏感参数以及尚未覆盖的失效机制。真正的安全论证还必须把需求定义、安全状态、独立性、测试程序、故障反应和变更管理接起来；“数字很小”只能告诉我们下一步该审哪一项。
迁移问题：如果 proof test 只能发现 80% 的潜伏故障、修复平均需要 12 h，且两条冗余通道共享电源，你会怎样修改 \(PFD_{avg}\) 估计并把共因/修复证据放入报告？哪些结论不能再由 \(\lambda_{DU}T/2\) 单独支持？
一、核心区分：安全 ≠ 可靠
这是本页最重要的概念区分：
- 可靠性（reliability）：系统持续正常工作的能力（不停机）；
- 安全性（safety）：系统不造成伤害的能力。
二者常常冲突。一台设备检测到异常后立即停机，是安全的（不会伤人）但不可靠的（生产中断）。
由此有两类失效：
| 含义 | 后果 | |
|---|---|---|
| 安全失效 | 系统失效但进入安全状态（如停机） | 损失生产，不伤人 |
| 危险失效 | 系统失效且丧失保护功能 | 可能伤人 |
功能安全的核心目标是把"危险失效"的概率压到可接受水平，并接受为此付出的可用性代价。
"故障导向安全（fail-safe）"是基本设计原则：失效时应自动进入安全状态。经典例子——
- 电磁制动器设计成断电抱闸（而非通电抱闸），断电时自动刹住；
- 安全回路用常闭触点串联，断线即触发停机；
- 第十三页的 4–20 mA 活零点同样是这个思想：断线（0 mA）可与真实零值（4 mA）区分。
二、风险与完整性等级
风险 = 危害发生的概率 × 后果的严重程度。
安全生命周期的第一步是危害与风险分析（HAZOP、FMEA、故障树等方法），识别可能的危害、评估风险，再确定需要多大程度的风险降低。
安全完整性等级（SIL）：按要求的风险降低量分级（SIL 1 至 SIL 4，SIL 4 最严）。对低要求模式，指标是要求时危险失效概率（PFD）：
每提高一级，要求的失效概率降低一个数量级，而成本与复杂度显著上升。
相关标准体系（各行业有专门版本）：IEC 61508（通用基础）、IEC 61511（过程工业）、ISO 26262（汽车）、IEC 62061 / ISO 13849（机械）、DO-178C（航空软件）。具体等级判定与认证必须依据现行标准原文与认证机构要求。
三、达成安全的技术手段
① 冗余与表决：
- 1oo2（二取一）：任一通道要求即动作——提高安全性（不易漏动），但降低可用性（易误动）；
- 2oo2：需两通道一致才动作——提高可用性，降低安全性；
- 2oo3（三取二）：兼顾两者，是高完整性系统的常用结构（航空、核电、高铁）。
这三个结构清晰地展示了安全与可用性的权衡——没有免费的午餐。
② 诊断覆盖率（DC）：系统能自动检测出多大比例的危险失效。未被检测到的危险失效最可怕——它潜伏着，直到需要保护时才暴露。因此有周期性检验测试来发现潜伏失效。
③ 避免共因失效：冗余通道若因同一原因同时失效，冗余就失去意义（共用电源、共用软件缺陷、同一批次元件、同一环境应力）。解法是多样性（diversity）：不同硬件、不同软件实现、不同供应商。共因失效是冗余系统最主要的残余风险，\(\beta\) 因子模型用来量化它。
④ 独立的保护层：SIS 与 BPCS 是否需要独立、独立到什么程度，应由危害分析、适用标准和架构要求决定；对需要独立保护的边界，不能共用同一失效路径而不论证。"保护层分析（LOPA)"就是评估各层独立保护的有效性。
四、软件的特殊性
硬件失效多是随机的（可用概率描述、可用冗余对抗）；软件失效是系统性的——同样的输入可能重现同样的错误。复制一份相同的软件不能消除同一个系统性缺陷，但这不等于硬件冗余对随机硬件失效完全无效；通道独立性、共因失效和系统性证据仍需按危害分析/标准验证。
因此安全相关软件依靠过程与验证，而不是把系统性错误当作随机概率：
- 严格的开发流程与文档、需求可追溯；
- 编码规范（如汽车行业的 MISRA C），禁用动态内存分配、递归、无界循环等不确定构造；
- 高覆盖率测试（语句/分支/MC-DC 覆盖）；
- 形式化方法（在最高等级中被推荐）；
- 工具链本身也需要资质认证。
安全关键软件的额外成本主要来自过程、验证和可追溯证据，而不是只来自让代码运行起来。
五、可靠性工程的基本量
- 失效率 \(\lambda\) 与 MTBF \(= 1/\lambda\)（恒定失效率假设下）；
- 浴盆曲线：早期失效（制造缺陷，用老化筛选剔除）→ 随机失效期 → 耗损期。🔗 微电子站第十四页讲的是同一条曲线；
- 可用性 \(= \dfrac{\mathrm{MTBF}}{\mathrm{MTBF}+\mathrm{MTTR}}\)——注意修复时间 MTTR 与失效率同等重要。这解释了为什么工业设备极重视可诊断性与可维护性：能快速定位并更换的设计，可用性优于故障率更低但难修的设计。
六、方法论价值：超出自动化的启发
功能安全的思维方式值得任何工程领域借鉴：
- 明确定义"安全状态"，并让系统在失效时自动趋向它；
- 区分随机失效与系统性失效，用不同手段对付（冗余 vs 流程）；
- 量化风险而非追求"绝对安全"——绝对安全不存在，工程的任务是把风险降到与后果相称的水平；
- 警惕共因：看似独立的冗余可能共享隐藏的依赖。这条在软件架构、金融风险、供应链管理中同样适用；
- 可诊断性是可用性的一半。
特别值得强调第 3 条：功能安全承认风险不可能归零，转而要求它被量化、被论证、被接受。 这种"用可验证的论证代替绝对保证"的姿态，是成熟工程学科的标志——它与第五页的水床效应、微电子站的物理极限属于同一种智识成熟度：知道什么做不到，并据此设计。
七、要点
- 安全 ≠ 可靠，二者常冲突；核心是压低危险失效概率；
- 故障导向安全是基本设计原则（断电抱闸、常闭回路、活零点）；
- SIL 按风险降低量分级，每级差一个数量级；
- 1oo2 / 2oo2 / 2oo3 清晰展示安全与可用性的权衡；
- 共因失效是冗余的最大敌人，多样性是对策；
- 软件失效是系统性的，靠流程与验证而非冗余；
- 量化风险而非追求绝对安全——这是本页最有普适价值的方法论。
线三结束。下一线进入研究生专业化：当线性、无约束的假设不再成立时，控制理论如何扩展。从非线性控制开始。