本文将讨论创建满足功能安全（FB）通用要求的设备的必要步骤。 还将提出最简单的“安全”电压发生器的架构。 由于控制电压，因此几乎可以控制任何设备。
该站点上有关于该主题的精彩
文章 （
一 ，
二 ）和一
本我成长为FB工程师的
书 。
一系列标准GOST R IEC 61508（IEC 61508）是俄罗斯标准的基础，该标准确定了提出FB要求的设备的开发顺序。 如您所知，在开发与FB相关的设备时，存在控制开发程序的行业标准（对于铁路，这些标准是GOST R 52980-2015“软件要求”，GOST R 34012-2016“铁路设备的一般要求”等）。 e）。
根据GOST R IEC 61508和IEC 61508标准，故障分为两种类型：系统性故障和随机性故障。
系统性故障取决于规格，设计，软件编码中的错误，并通过组织生命周期来建立针对这些
故障的保护措施，其中包括：验证生命周期中各个阶段是否符合要求以及对最终产品进行验证（验证测试）。
随机故障的计算方法是硬件故障的可能性，通常通过体系结构决策来确定对故障的保护。
按照标准，所有方法可以分为两组：组织和技术。 组织方法包括：实施生命周期，应用编码标准，监视硬件的生产。 技术方法包括：破坏活动（来自英语的多样性-多样性），冗余，免受环境影响，组件的独立性和分离性，自我诊断（必须在单独的文章中对每种方法进行描述）。
GOST R IEC 61508的附录中介绍了防止系统错误的主要组织方法。例如，我们考虑软件的系统组件。 编写代码时，应特别注意编码中使用的编码规则和标准。 MISRA-C是使用SI语言进行编程的著名标准之一；它的使用提高了系统的安全性。 此外，还有可以检查是否符合MISRA-C标准的静态分析器（通常用于分析器检查任何代码是否有错误），其中之一就是
PVS-Studio 。
可以通过使用各种软件开发算法来实现部分软件转移。 仅当存在两种不同的软件需求规格，不同的程序员团队，不同的生产中编程设备手段时，才能实现完整的软件多样化系统。 这些程序应该完全不同，并且编程设备的过程也应该不同。 另外，在开发软件工具时，有必要防止工具错误。 就工具而言，最关键的软件是与标准库和链接器结合使用的编译器。 使用ARMCC和GCC编译器可以实现多种工具。 但是，某些版本的ARMCC已通过IEC 61508的SIL-3认证的TUV认证，并且GCC已成功用于
Falcon 9软件的开发。
考虑编译“写入端口”命令的结果：
| 以SI语言（ISO / IEC 9899）发出的命令：MDR_PORTE-> CLRTX = 0x0040 |
|---|
| 海湾合作委员会 | “ ARMCC” |
|---|
| LDR r3，[pc，＃20] | MOVS r0，＃0x40 |
| MOVS r2，＃64； 0x40 | LDR r1，[pc，＃16]； @ 0x0000072C |
| STR r2，[r3，＃36] | STR r0，[r1，＃0x24] |
即使通过这样一个简单命令的示例（从表中可以看出），微控制器的命令顺序也不同，并且使用了不同的工作寄存器。 这以某种形式为我们提供了“多样性”，从而减少了由于工具故障的
常见原因而导致错误的可能性。
以控制电磁继电器的设备为例，考虑一下防止意外错误的方法，如图所示。 为了确定保护方法，必须确定危险的设备故障。 如您所知，继电器是通过向其绕组供电来控制的，在这种情况下，该设备的危险故障将是未经授权的足以使继电器工作的电压出现。 该设备基于2的体系结构2。在这种体系结构中，MCU_A和MCU_B应该通过物理上分离的网络接收命令。
图-安全配对图在本文的框架中，我们将不会完全描述故障树，因此，我们将考虑导致危险故障的最可能的事件链之一：
- 光耦合器U1突破
- 钥匙K2突破
- 变压器突破
此类事件的发作强度由以下公式确定
。 由于这三个失败都是相关的，因此该链的强度将由公式确定
。 在粗略的假设下，假设故障可以在24小时内累积，则此链的故障率小于（10e-15）1 / h。
让我们考虑另外一种故障：MCU_A和MCU_B的故障，以便它们“随机地”在输出端生成一系列脉冲。
“随机”表示微控制器执行至少九个命令（端口的三个条目），而两个微控制器将检测输出电压，并且在接收到的“发出的命令”之间将产生错误。 这些事件的强度极低，因为：两个MK必须同时执行9个命令（更不用说MK必须以一定的间隔将相反的值写入端口，以便生成继电器在输出端运行所需的电压）。
总之，应该指出，作为提高功能安全性的方法，建议应用：
- 软硬件多元化；
- 所有微控制器资源（RAM，ROM，ALU，工作寄存器等）以及设备节点的自诊断；
- 减少相对于极限值的电路元件参数（降额），以确保更好的工作特性并减少故障的可能性。
所有这些方法都可以用于开发满足FB要求的设备。
附言 在所考虑的示例中，为了减少由于常见原因导致的故障可能性，可以用FPGA代替其中一个微控制器。
谢谢大家的关注（这是我的第一篇文章）！