本文深切认为技术系统不应当为人们和环境带来超出允许风险范围的安全风险。完全没有风险是不现实的，所以风险可接受与否在于其严重程度。每个领域对可接受风险程度都有自己的定义，并使用不同的安全等级对其进行衡量。对于电气和可编程系统来说，得益于一系列标准建立，由此形成了关于功能安全的共识。这些标准适用于不同的应用领域，但它们都基于由IEC61508标准派生出的安全理念。
图1：常见的功能安全标准概览
IEC61508标准覆盖了系统的整个生命周期，并着重为系统中可能出现危险的部分制订了相关规范。该标准旨在提供从零开始设计系统的最安全方式。实现功能安全的普遍措施是添加额外的元器件，用于监控功能的正常运行以及在发生不正常的情况时对系统进行控制。这个理念常用于工业自动化或过程工业领域中。 IEC61508标准定义了功能安全的操作模式：低要求操作模式、高要求操作模式和连续模式。操作模式则由每年对于安全功能的使用频率决定。
同时，针对功能安全领域中的标准控制功能的设计方法是可选的。IEC61508标准中定义的连续模式包含这些信息。
通常做法是从分析所有可能对系统产生影响的关键问题开始。所有被定位的问题必须使用参数进行衡量，如暴露时间、受伤的严重程度以及脱离伤害的可能性。这是典型的风险分析措施，必须在没有额外电气保护系统的情况下对受控设备施行。系统整个生命周期的所有部分均必须使用该措施。凭借风险图，风险分析将提供要求的安全完整性等级(Safety Integrity Level，SIL)。在遵循ISO13849标准的情况下，风险图将提供要求的性能等级(Performance Level， PL)。PL与SIL相似，均定义了安全等级。在设计安全PLC(Safety PLC)、安全变频驱动器(Safety Drive Inverter)或安全编码器(Safety Encoder)等安全元器件时，通常的做法是从机器制造商处获得要求的安全等级。要求的安全等级旨在将风险降低至允许风险范围内。SIL必须通过安全功能得以满足，安全功能将由一系列安全元器件或安全设备实现。这就意味着单一的元器件无法满足SIL，仅能用作安全链中的一部分。
为了满足SIL要求，该标准涵盖了两种失效情况。第一类包含随机失效以及所有类型的随机硬件失效，而第二类包含所有系统失效。
随机失效
随机失效基于不同的参数进行计算得出，如元器件的失效概率(λ)、诊断覆盖率(Diagnostic Coverage，DC)、硬件故障裕度(HardwareFault Tolerance，HFT)、共同失效原因(β)以及测试间隔。事实上，安全与否不是与生俱来的，对于系统出现故障并进入到不安全状态的情况，IEC61508标准仅涵盖检测不到、不安全的失效概率并根据合适的模式具体说明各类限制，PFD(根据要求的失效概率，Probability of Failure on Demand)适用于低要求操作模式，PFH(每小时的失效概率，Probability of Failure per Hour)适用于高要求操作模式和连续模式。举个例子，SIL3安全功能仅限于千年一遇的危险失效。反之，低要求操作安全功能(PFD)不应当发生平均1000次安全要求出现1次失效的情况。作为额外的验收标准，IEC61508要求安全失效分数处于指定的SFF(安全失效分数，Safe Failure Fraction)范围内，这取决于HFT和SIL。
表1：安全完整性等级的PFD和PFH值
|
SIL |
PFD[要求时] |
PFH[每小时] |
|
1 |
0.01-0.1 |
0.0000001-0.00001 |
|
2 |
0.001-0.01 |
0.00000001-0.000001 |
|
3 |
0.0001-0.001 |
0.00000001-0.0000001 |
|
4 |
0.00001-0.0001 |
0.000000001-0.00000001 |
表2：安全失效分数与硬件故障裕度的关系
|
SFF |
硬件故障裕度 |
||
|
0 |
1 |
1 |
|
|
＜60% |
不允许 |
SIL1 |
SIL2 |
|
60%-90% |
SIL1 |
SIL2 |
SIL3 |
|
90%-99% |
SIL2 |
SIL3 |
SIL4 |
|
＞99% |
SIL3 |
SIL4 |
SIL4 |
危险失效的失效概率可通过实现诊断功能和冗余得以降低。冗余度需要参照硬件故障裕度(HFT)。HFT值为0的系统发生1次失效即可产生危险。也就是说，HFT值为N的系统能够承受N-1次失效。如果诊断单元能够检测到故障并将系统引入安全状态，局部诊断覆盖即可降低重大失效带来的影响。除了故障(硬错误，Hard-Error)导致的元器件失效概率，设计工程师还必须尽量减少软错误(Soft-Error)。在测算时，软错误率是非常关键的一点，因为相比硬错误导致的失效率，软错误率会提升。
FPGA器件的领先制造商莱迪思半导体公司为客户提供适用于所有推荐的安全元器件的失效概率和软错误率数据。
避免系统失效
除了上文提到的情况，另一项当务之急是尽可能避免系统失效，这取决于要求的SIL，而SIL会因为措施的数量和使用程度发生变化。产品生命周期中的每个阶段针对系统失效都有不同的要求。规范概述了以下设计流程：实现、验证和确认。针对结构完善的设计来说，推荐采用V模式(V-Model)。针对于软件设计和FPGA编程，该标准具体说明了其设计阶段和验证阶段。
图2：IEC61608-2:2010规范中针对FPGA设计的V模式
综上所述，功能安全管理技术方面的措施对于避免系统失效来说是至关重要的。安全管理包括在研发开始之前为所有的设计和验证步骤制定详细的计划。由此可见，安全管理人员必须要有一个定义明确的项目计划。
文档管理
作为安全项目的一部分，必须完善制定文档管理方面的规范。文档管理描述了如何处理、储存、发布和修改文档，以及文档的访问权限和每个团队成员的受限情况。版本控制应当作为自动化流程由工具实现。
需求管理
管理所有的需求是安全项目中非常必要的一部分。每项安全需求在整个安全项目中都应当是可追踪的。安全项目的最终目标是确保所有的需求都能够被正确地实现。相关测试可用来确认特定的需求能否降低风险。就此而论，必须根据精确的数据、完整性和一致性来组织整理要求。从架构到实现的模块，模块测试到整合，再到系统测试的整个过程中，安全项目必须要能显示需求产生于哪个部分。
组织和责任
分工明确并且结构完善的团队对于确保高效无缝地完成所有任务来说是至关重要的。团队结构和小组领导应当按照层次顺序设定。所有的联系信息都应当是可用的，特别是对于分散的团队来说，必须为团队成员制定通讯和协作的方式。这对于审核人员、开发人员和测试人员能否各司其职具有重要意义。
措施的定义
根据要求的SIL，该标准提供了一系列适用于每个生命周期的表格，包含推荐或强烈推荐的措施，可作为默认的失效避免工具使用。在研发开始之前，应当选择所有涉及到设计和验证方法的技术。IEC 61508规范的第2和第3部分列出了所有技术。第2部分涵盖了所有硬件领域以及所有ASIC或FPGA领域。第3部分涵盖了所有软件领域。FPGA编程被囊括进IEC61508标准的第2部分中，这有点让人费解，不过这不是技术问题，更多的是标准化组织的原因。不过这个不要紧，因为开发FPGA软件的方法与开发微控制器软件的方法相似。不同点在于技术。举个例子，仿真技术在FPGA设计过程中更加常用，而微控制器则更需要带有调试工具的硬件。
表3：F.2 IEC61508-2表2摘要
|
设计阶段 |
参考 |
方法 |
SIL1 |
SIL2 |
SIL3 |
SIL4 |
|
设计输入 |
1 |
结构化描述 |
HR |
HR |
HR |
HR |
|
2 |
使用（V）HDL的设计描述 |
HR |
HR |
HR |
HR |
|
|
综合 |
17 |
内部一致性检查 |
HR |
HR |
HR |
HR |
|
18a |
门网表文件仿真，用于检查时序约束 |
R |
R |
R |
R |
|
|
设置、布局和布线生成 |
28b |
使用参考模型（正式的等价型检查） |
|
|
|
|
|
29 |
设计规范检查 |
|
|
|
|
|
|
制造 |
32 |
采用经过实践验证的加工技术 |
HR |
HR |
HR |
HR |
|
33 |
采用经过实践验证的设备西系列 |
HR |
HR |
HR |
HR |
|
|
|
|
R：推荐 HR:强烈推荐 |
||||
表3展示了降低FPGA设计中系统失效的技术列表的摘要。对于一般硬件和软件设计，也有适用的类似表格。使用这些表格的原则是始终如一的。标注为“HR”的措施必须得以施行。如果不这么做，那么相关决策是不合理的。标注为“R”的措施应当在条件允许的情况下使用。
验证和确认计划
验证和确认流程也必须在安全功能实现之前计划好。所有的设计阶段都要选择故障避免文档中的措施进行验证。计划的措施必须阐明目前的项目将在真实情况中如何表现。举个例子，计划的措施可以是静态代码分析。那么对应的验证和确认计划应当覆盖所有将由代码检查器检验的软件模块(SW-Module)，包含使用该工具的流程并将如何对结果进行处理、分析和存档的说明。
另一个例子是FPGA设计过程中的网表检查。第一步是明确这个步骤必须完成，谁来执行这个任务以及输入和输出的文件是什么。下一步是定义进行该任务需要使用的工具以及发布流程。
该计划可用作针对所有验证和确认流程的检查表，能够为所有计划流程的完成度提供完整的概览。
工具认证
针对在生命周期中的所有阶段密集使用任何类型软件工具的情况，所有将用于实现安全部分的工具将按照它们对于安全功能的影响进行分析。这意味着，首先需要列出所有的工具，然后将所有的软件工具根据工具重要性等级(IEC61508-4:2010标准中的T1、T2、T3等级)进行分类。
表4：工具重要性等级
|
等级 |
定义 |
莱迪思工具 |
|
T1 |
该等级涵盖所有带输出、不会对安全功能产生直接或间接影响的工具，例如文档工具 |
|
|
T2 |
该等级涵盖所有带有输出，并会对安全功能产生间接影响的工具。通常支持测试或仿真来验证。上述工具发生的错误可产生误导性的测试结果，但不会直接足有安全功能。这些工具包括案例测试覆盖度量工具、静态分析或调试工具 |
Diamond 2.1Aldec
Active_HDL |
|
T3 |
该等级中的所有工具均带有输出，并直接或间接地影响安全功能。这些工具包括能够将库文件整合进行代码或工具的编译器或综合工具、设置和布线工具等，以及更加先进的技术 |
Diamond 2.1 LSC |
表4展示了标准中的相关定义以及莱迪思工具列表，后者按照使用FPGA实现安全相关任务时的相应等级进行分类。在真实的项目中，该列表需要填上所有使用到的工具。知晓某个工具在项目中的重要性是有用的，但这并不会让人们获得更加安全的系统。这就是为什么要进行额外的工作，比如说进行工具认证让工程师对使用的工具有把握。有把握的意思是能够确认或知晓工具发生的错误。如果该工具能够正确地满足规范要求并且使用者已经获得了该工具经过确认的凭据，那么他就可以不受任何约束地使用该工具。如果该工具无法按照规范要求工作，用户则需要相关错误的信息并暂时避开导致错误发生的情况。如果分析人员得出的结论是工具的输出不可信或规范还不够详细，用户就必须制定其他方法来检测上述错误。
分析过程有可能为用户带来潜在问题。如果用户自身不具备有关该工具的足够知识、经验或数据，就会产生问题。在这种情况下，如果该工具的制造商能够为客户提供相关支持，比如所有必要的数据，则会非常有帮助，如果工具制造商还能提供由独立机构认证和批准的数据和文档，那就更为理想了。
莱迪思已邀请TüV Rheinland按照IEC61508标准对“Diamond 2.1”工具套件进行了高达SIL 3级别的审核。这为安全项目团队提供了使用该工具链以及所有相关文档和安全手册的便利，使用者无需进行额外的确认。审核所获的结果节约了项目相关的成本和时间，并简化了为安全应用选择莱迪思FPGA的决策过程。同上述工具一道，莱迪思还可提供经过量产验证的 FPGA，可靠并且具备认可的失效概率数据。由相关机构颁发的认证让评估人员更加信任莱迪思的产品，并能加速型号审核流程。
安规产品设计的工作流程
除了所有的功能安全管理，还要实现安全设计流程以确保产品安全。让我们假设有一个需要实现SIL 2或SIL 3级别设备的项目。
项目第一步是建立安全方案。安全方案能够勾勒出具备相关细节的大致架构，如包含单通道或双通道架构、通信路径、输入和输出接口、电源等信息。安全要求规范(safety requirement specification， SRS)由安全方案和产品规范衍生。为了使方案确定下来，推荐在块层面执行第一次失效模式和影响分析(Failure Modes and Effect Analysis， FMEA)。通常情况下，FMEA结果会推进要求列表的制定。IEC61508标准提供了一些失效控制措施，包括复杂电子元器件故障模式和指令故障检测模式，用于支持结构化分析。在双通道或多通道架构中，共因失效必须得以定位和消除。对于安全设计来说，环境和EMC情况也是非常重要的。根据应用的情况，应当按需参照其他标准进行确认和检视。所有的要求都确定下来之后，就可以按照由高到低，从架构到模块的顺序开始设计。请记住一定要建立所有步骤的规范和描述，因为这些输入文件将用于所有的审核以及测试阶段。为了项目流程的顺利推进，所有的测试应当与开发同时进行。
在所有的原理图和电路导出之后，部分FMEA必须完成，随后进行安全参数的计算。部分FMEA也会被用做故障导入测试(Fault Insertion Test， FIT)规范中的输入信息。软件应当按照图2所示的流程来实现。
在完成系统和型号等所有测试后，该设计应当能够满足所有安全要求。最后一点特别关键，所有安全相关的信息必须写入新产品的用户手册中。
