关于功能安全的几大误区

制造商通常只会计算其系统或子系统的PFD/PFH值，并在之后给出一个SIL。PFH/PFD表示安全相关系统（或子系统）每小时（PFH）或者按需（FPD）的危险失效率。这两个值说明了随机硬件失效，而且通常使用FMEDA计算。达到具体的安全完整性水平（SIL）不仅要求控制硬件的随机失效，而且还要避免和控制硬件和软件的系统失效。后者表示为系统水平（SC，值为1至4，对应SIL的 4个等级）而且反映了安全相关系统开发过程中使用的方法和技术。因此，SIL始终包括：PFD/PFH以及开发过程稳健性的指标，比如SC。

有时系统集成商和装置制造商要求其供应商提供具有一定SIL水平且可以确保系统正常操作的控制系统，以确保控制系统和/或公用设施具有一定的可靠性。但是安全功能（通过安全相关系统执行）的目的是让受控设备（EUC）处于安全状态，而不是提高其可用性。

受控设备安全状态是危害和风险分析的结果，而且取决于其不同的操作模式。在这种情况下，我们经常会观察到一些对于故障安全情景方法和概念理解错误情况，比如在失效情况下关闭受控设备；以及对于失效时运行情景，比如让受控设备尽可能地运转。

随机硬件失效（和可靠性）是根据失效率计算的。在功能安全方面，失效率分为安全和危险失效。在计算PFD/PFH值时，只需考虑危险失效（阻止安全功能发挥预期作用）。因此，SIL仅代表当受控设备处于安全状态时设备按照预期实现安全功能的一定程度的可靠性。

微控制器的看门狗往往只能重置控制器，不能直接独立控制任何输出。当微控制器内发生故障时，要求其输出行为是确定的。使用内部看门狗并不足以获得该功能，因为无法保证输出达到预期状态：内部看门狗是微控制器缺陷的一部分，因此，无法保证正确运行。

我们还根据运行经验，声称现有软件系统能力的方法（IEC 61508中的路线2S）。根据IEC TS 61508-3-1，所有软件故障需要在观察期中检测和报告，而且所有输入数据组合、执行顺序和时间关系也必须记录在文件中。这种方法通常不切实际。

我们通常遵守非安全组件与安全组件混合的系统设计。但是，采用混合安全完整性水平设计方法时，需要提供避免干扰自由的证据。分析需要在详细硬件或软件层面执行（取决于系统），考虑到不安全组件的任何可能失效模式以及对安全组件的相关影响（比如，不安全零部件过压、错误数据、短路等）。

在开发安全关键性软件时，现在，最先进的方法是使用自动化工具确定效率和安全性。但是，我们已多次发现此类工具的一些错误使用。单元测试规范首先应该根据软件单元/模块规范编写，而不是通过源代码白盒分析。目的是测试软件单元的预期功能行为。代码层面的测试覆盖率是否满足的证据必须提供，在这种情况下要求白盒分析，但这并不是单元测试的唯一目标。

在现代复杂的安全相关系统中，智能传感器的使用越来越重要。传感器的功能应当具有要求的完整性或者应当合理证明不影响总体安全功能。有些系统设计错误地基于这样的假设：复杂智能传感器的失效模式（比如,带逻辑处理器、通信协议等）可以使用某些外部安全装置在规定的诊断覆盖率和失效检测/反应时间内诊断出并得到缓解。

我们看到电源保护/监督缺失相关的问题复发。安全标准没有具体说明应该如何具体实施过压/欠压措施，但是应该根据要求的SIL水平制定适当的保护机制。对于要求HFT>1的架构，使用非冗余过压保护机制，是一个典型的复发问题。电源电压监测（包括要求的反应，比如关闭和安全状态）应当采用单独的零部件完成，该零部件能够在更广泛的电压范围内使用，不会受到过压/欠压条件影响。即使短时过压也可能不明显地造成微控制器组件永久损坏。因此，过压后对微处理器重置并不是妥当的措施；只要欠压没有持续，在欠压条件之后重置是可行的。

温度过高检测和相应反应（进入安全状态，停电等）无法采用一个在温度过高条件下在规定范围以外运行的零部件完成（比如，微控制器）。单纯重置此处无用，应该假设温度过高条件持续，或者在打开期间温度已经偏高。安全标准（比如EN50129）中有时不对低温予以规定，但是应用条件（用户手册）应当确保仅在规定的温度范围内驱动设备（对于所有零部件）。

多个标准使用缩写SIL（安全完整性水平）。但在各个标准中，其流程、架构和技术要求不同。有些标准使用其他缩写，比如ASIL（汽车SIL）。有些使用相同的缩写（SIL），很容易混淆和误解。

比如，SIRF（Sicherheitsrichtlinie Fahrzeug; EBA）使用的SAS水平（德文:“Sicherheitsanforderungsstufe”代表安全完整性水平）与EN 50128 /EN 50129标准中所述的SIL水平（“安全完整性水平”）不同。SIRF (SAS)仅使用EN 50129附件E中列出的一部分措施，省去了组织和流程措施，而且没有规定的危害率限制。IEC 61508中的SIL与EN 50129中的SIL不同。有时，SIL会被解释为软件完整性水平而不是安全完整性水平（比如，EN 50657），增加了复杂性。

没有安全证据的系统或使用同类冗余系统组合，无法提高系统的SIL水平。比如，单纯结合多个SIL2系统/通道（比如，通过多个SIL2控制系统达到系统SIL3）无法提高SIL至SIL4。一个原因是，SIL2软件流程与SIL4软件流程对于系统性软件失效的防止方式（完整性）不同。IEC 61508标准规定，如果一个双通道结构使用两个独立的系统，则可将系统的系统能力提高1级。如果是同类冗余，则无法提高。其他标准（比如，EN 50129）则没有提供这种可能性。

在故障树分析（FTA）中往往会忽略常见原因。同时能影响一个系统多个组件的故障（比如，断电）必须作为基本事件包含到故障树的所有相关分支中。替代办法：使用FTA工具中的“β系数”执行常见原因。

SIL（安全完整性水平）的定义适用于从某些风险分析/分类中导出的功能。对于一个系统/零部件，我们经常会听到这样的说法，比如“SIL 2控制器”, “SIL3 制动系统”等，正确表述SIL仅与具体（安全）功能有关。风险分析的目的是确定哪些功能是安全的。更加正确的定义是“系统能够实现高达SILx”的安全功能。这意味着系统符合标准中的流程、架构和技术要求。

系统范围需要从安全角度分析，而且它们与其他系统部件的接口在项目开始往往没有明确界定。比如，没有明确哪些零部件属于系统部分，哪些传感器/执行机构变体应该考虑在内等。没有界定范围是无法开始安全分析的，没有避免多个迭代那么每次范围都会变化。

故障检测和监测块（诊断）属于具有特定SIL水平的安全功能，但是却有单独SIL水平。有些标准允许把要求的完整性水平降低1级，但是从功能安全的角度而言，诊断是安全功能的一部分。完整性要求也适用于诊断。后续分解分析也能够降低完整性水平，但通常不排除任何安全要求。

有些完整性/诊断措施是在系统每次启动时执行（比如，RAM测试，Flash CRC检查，输出测试等）。这些测试非常重要，因为它们用于测试诊断措施论证或者安全分析中的故障检测时间（测试时间间隔）。但是有时，运行条件会变化（新项目，新要求等）。定期关机的系统，较长时间处于上电状态。比如，现在轨道系列如今往往持续通电，每天早上无需重启。在这种情况下，预期的诊断措施便无效。根据安全分析需要，应该在安全手册、操作文件等中明确对定期重启做出规定。