文章目录

安全性工程流程
Hazards
反事实推理（CounterFactual Reasoning）
- 案例1
- 案例2
- 案例3
HAZOP: HAZARDS AND OPERABILITY STUDY
- 案例1
- HAZOP 工作流程
- HAZOP 总结
Fault Tree Analysis
- Fault Tree 定义
- 案例
- Node Symbols
- analysis outcomes

这节课主要介绍了高完整性系统的 工程流程和 关键步骤。首先回顾了上一课的 安全性定义（safety），然后详细解释了 软件工程的标准流程，包括 需求收集、设计、架构实现和测试。重点强调了在 确定系统需求阶段理解可能出错的情况 以制定如何防止错误发生的策略的重要性。同时， 设计阶段也需要检查设计是否真正防止了错误的发生。(尽量在早期确立所有的问题并解决）

课程中提到了两种工具和方法：Hazard and Operability Study（危害和操作性研究，简称Hazop） 和 Fault Tree Analysis（故障树分析，简称FTA），这两种工具都用于识别和防止潜在问题。

安全性工程流程

Hazards

如何通过了解可能发生的错误和故障来工程化安全系统是这门课的目标。在安全关键系统中了解可能出错的地方的是非常重要的，为了工程化这样的系统，你需要成为你特定领域的错误专家。如果你在航空业，那么你需要理解导致飞机坠毁的原因。
“危险源”就是可能出错的事物。我们的目标就是设计出能在面对这些可能出错的事情时仍然安全的系统。了解你的系统的环境中可能发生什么，这些可能如何影响你的系统，以及你的系统应如何防止这些导致大规模故障，这就是我们需要考虑的所有事情。
仅仅知道可能出错的事情并不够，你真正需要理解的是这些错误的原因，或者说，在系统环境中发生某些事件导致了灾难性的故障，从一个事件导致了另一个事件，这种因果关系发生了什么。只有通过理解这种因果性，你才能真正地工程化你的系统，确保你打断了这种因果链，预防了错误的发生，防止了未来发生糟糕的事情。因此，理解因果性是调查过去发生的事件和事故的重要部分。

反事实推理（CounterFactual Reasoning）

这种推理方法在哲学上很有趣，但对于这个课程来说，你只需要知道，反事实推理基本上就是一个思考实验，你思考的情况与实际发生的情况不同。我们在考虑一件事是否导致另一件事，也就是说，A是否是B的原因时，我们需要进行的思考实验就是问自己：如果A没有发生，B是否仍会发生？如果答案是，即使A没有发生，B仍会发生，那么A就不是B的原因。反之，如果B在A没有发生的情况下不会发生，那么A就是B的原因。
避免因果关系推理错误是非常重要的，因为 相关性不代表因果性

案例1

人均奶酪消费量与人们因纠缠在床单中而死亡的数量：这两个因素似乎具有强烈的相关性，但实际上并没有因果关系。尽管统计数据显示它们之间的相关性，但我们可以轻易想象如果人们不吃这么多的奶酪，他们仍然可能因纠缠在床单中而死亡。这两个事件似乎是概率上独立的。
反事实分析以弄清因果关系的全部意义 在于避免推理中的错误。

案例2

溺水死亡与冰淇淋消费量的相关性：这两个事件在夏天时似乎有相关性，但并不是因为吃冰淇淋导致了溺水死亡，也不是溺水死亡增加了冰淇淋的消费。它们的共同原因是炎热的天气，这被称为混淆因素。

案例3

气压计读数变化与风暴到来的相关性：气压计读数的变化预示着风暴的来临，但并不是气压计读数的变化导致了风暴，而是风暴的来临改变了气压计的读数，这是一个反向因果的例子。

以上这些例子都在强调一个观点，那就是：相关性并不等于因果性，我们需要通过反事实推理来判断事件之间的因果关系。

安全工程师需要将过去的原因作为危险源来研究。作为安全工程师，你需要成为你工程化系统类别的错误专家，因为大多数这类系统是相似的。然而，有时 新技术的引入可能会引发新的危险源。

为了系统地理解潜在危险，以便有一个可复制的过程来进行工程设计，可以使用一些重复性的方法。这种方法可以让其他人检查他们的工作，确认他们已经考虑到所有的潜在危险。在这里，提到了两种方法，一种是一种 可重复的头脑风暴方法，叫做危险性和可操作性研究 (Hazops)，用于探索系统中可能出现的不同的危险；另一种是故障树分析，这是一种检查系统设计是否能消除潜在危险的方法。
Hazops 和 Fault Tree 分别集中在 requirements 和 design 阶段

下阶段内容，我们将开始讨论形式规范（Formal Specification），这是一种在 implementation 阶段使用逻辑（Logic）来记录系统设计，并分析设计是否确实防止了错误发生的另一种方法。届时，将使用程序验证等方法来证明实现是否符合设计，从而防止错误发生

HAZOP: HAZARDS AND OPERABILITY STUDY

HAZOP（Hazard and Operability Study）是一种系统性的头脑风暴方法（systematically brainstorming），用于探讨系统中可能出现的问题。它最早在上世纪50年代应用于化学过程的安全改进，并且后来被安全关键软件工程领域采用，作为一种可重复的方法来确定软件系统中可能出现的问题，并设计系统来防止这些问题的发生。
HAZOP的过程以系统的高级描述作为输入，将系统划分为一系列称为 “design items” 的组成部分。在HAZOP中，design items是关于系统中应该发生的事物或期望发生的事物的描述。这些描述通常采用以下形式：当某事发生时，接下来应该发生某事，或者系统应该执行某些操作。例如，"当X被触发时，阀门应立即关闭"就是一个设计项的例子。
HAZOP的方法是通过系统地思考可能发生的事物，并仔细思考如果发生了其他行为，那么它的后果会是什么，以及如何设计系统来防止发生这些行为。 在HAZOP中，你会对系统中不同行为的风险进行系统化的思考，这也是下一步要讨论的内容。通过考虑事物发生的风险，你可以确定需要付出多少努力来防止该事物的发生。如果风险很低，你可能不需要太担心它。另一方面，如果风险很高，那么这是你必须关注的事物，因此你需要考虑系统的要求，以防止该事物的发生。

关于如何评估风险，有一个正式的国际标准，我们在本课程中不会详细讨论。主要要注意的是，它是一个 形式化、标准化 的评估风险的过程，并提供了一些 风险类别。其中，第一类风险 是绝对不应该存在于系统中的风险，必须从系统设计中消除。而 第四类风险 是可以忽略的风险。
通过评估事物发生的后果和频率，可以对系统中的风险进行分类。这种分类可以让我们理解风险的严重程度，并采取相应的措施来预防和减轻风险。
HAZOP的目标是将一类风险转化为四类风险，这也是安全工程的重要任务之一。 在分析事故调查报告时，我们会看到对不同后果类别的讨论，以及针对不同风险的控制措施。这要求人们对系统设计非常了解，以正确地书写这些设计项。
总的来说，HAZOP是一种系统性的方法，用于识别系统中可能出现的问题和风险。它通过对可能发生的事物进行头脑风暴和风险评估，帮助我们理解系统的潜在问题，并采取相应的措施来预防和减轻风险。

案例1

这个案例主要讨论了汽车的电子刹车系统的设计和可能出现的问题。主讲者首先描述了系统的工作原理：驾驶员踩下刹车踏板使汽车减速，这会向嵌入式控制单元（刹车控制器）发送一个信号。一旦收到这个信号，刹车控制器就会向刹车发出信号，通过执行器对车轮施加压力，从而使车辆减速。
刹车控制器在这个过程中扮演着核心角色，可能是为了实现自动刹车等功能。然而，系统的预期行为（或称 design items）以及可能的问题，非常依赖于我们考虑问题的抽象层级。
如果我们在 嵌入式控制单元的层级 上思考，design items 可能是: 当控制单元（ECU）检测到刹车踏板压力迅速增加时，它会全力施加刹车，实现紧急刹车。
而如果我们考虑的是刹车踏板和控制单元之间的交互， design items 可能是 当脚踏板压力改变时，刹车控制器接收来自刹车踏板的信号。

因此在构建了 design items 之后，我们通常采用 what if 的思维方式来揪出可能存在的 hazards

主讲者接着讨论了一种思考系统可能出现问题的方法，他称之为"有防范性的过程"。这个过程就是 根据 design items 推测可能出现的错误情况。 比如，如果设计项是 “当脚踏板压力变化时，刹车控制器接收来自刹车踏板的信号” ，我们可以想象出许多可能的错误，如 "如果没有接收到信号怎么办"、“如果信号提前或延迟到达怎么办” 等等。

刹车信号未被接收：讲者指出，如果驾驶员在踩下刹车踏板后，信号没有被电子控制单元（即刹车控制器）接收，这可能会导致汽车无法停下来。这种情况的后果可能非常严重，可能导致车祸。
刹车信号过早接收：如果刹车控制器过早接收到信号，可能导致汽车过早停下，驾驶员可能对此反应不及。这可能会导致后车碰撞，造成车祸。
刹车信号接收过晚：如果刹车控制器过晚接收到刹车信号，可能会导致汽车无法及时停下。这种情况下可能无法阻止车辆冲入危险区域，导致事故发生。

在上面的例子中，我们系统性地使用了 “过早”(earlier) ，或者 “过晚” (later) 对 design items 的 intended behaviors 情况进行假设，其实还有一些 guidewords，可以帮我们在使用HAZOPS 系统的时候更好地总结和发现问题：

HAZOP 工作流程

HAZOP 总结

HAZOPS（Hazard and Operability Studies）是一种系统化的危险和可操作性研究方法，通常应用于工程和系统设计中。这种方法的主要目标是通过分析设计元素（design items）（或称为设计项目或预期行为）的变异(deviation)，识别潜在的风险和问题，从而可以进行预防和改进。以下是该讲者对 HAZOPS 过程的描述：
首先，确定系统的设计元素或预期行为（intended behaviors）。
针对每一个 design items，使用一系列的“指导词”（Guide Words）来诱发设计元素的变异思考。例如，“早”、“晚”、“更多”、“更少”、“部分”或“全部反向”等。
对于每一个引发的变异（也称为 deviation），思考可能 引发的原因，可能的后果（例如，是否会导致严重的事故），以及系统中已经存在的安全防护措施。这些安全防护措施会帮助确定该风险发生的实际可能性。
对于每一种可能的风险，都需要评估其影响（例如，是否灾难性，或者只是边缘性），并据此提出改进建议，可能是增加额外的安全防护措施，或者修改系统设计以降低风险。
在这个过程中，讲者强调了这是一个鼓励创新思维的过程，而不是僵化的流程。通常这不是一个人完成的工作，而是由多人共同进行头脑风暴，分享过去出错的经验，创新地进行解读。
最后，所有这些过程都需要详细地记录下来，形成大量的文档，以便别人可以检查是否遗漏了任何重要的风险。这个详尽的危害清单还可以作为制定安全案例或证明系统安全性的证据。尽管这个过程可能看起来并不刺激，但有些人可能会认为这是一个富有创造性和有趣的过程。

Fault Tree Analysis

Fault Tree 定义

故障树分析（Fault Tree Analysis, FTA）是一种用于确定系统可能发生故障的各种原因的方法。故障树分析起源于1960年代的美国航空航天领域，现已广泛应用于各种行业，包括航空、核电、化工、软件工程、安全工程等。
故障树分析的核心是使用树状图来表示故障的原因和效果。在故障树中，顶部的事件（通常表示为一个矩形）是你关心的特定系统故障，而树的其余部分则表示可以导致该故障的原因。这些原因可能包括设备故障、设计错误、人为错误等。
每个原因都可以进一步分解为更详细的原因，这些原因由“与”或“或”门连接。如果两个或两个以上的故障同时发生才会导致高级故障，则这些故障会由一个“与”门连接；如果任何一个故障发生都会导致高级故障，则这些故障会由一个“或”门连接。
通过这种方式，故障树分析可以帮助我们深入理解系统故障的复杂原因，并提供更好的决策支持来优化系统设计，以避免可能的故障。同时，FTA可以帮助确定最可能导致系统故障的原因，从而在故障预防和改进中优先处理。

案例

故障树分析是一种反向的安全分析方法，它从一个系统的 潜在危险或故障开始 ，然后探究可能导致这些危险或故障的根本原因。下面是对这个化学混合过程的故障树案例的分析：

故障树以化学混合过程中的主要危险作为起点，即：储液罐溢出，导致危险化学品泄漏。分析的目标是找出可能导致这一危险的各种可能原因。

从储液罐溢出这一主要危险出发，我们首先找到两个直接原因：

输入阀门（阀门B）打开，
输出阀门（阀门A）关闭。

这两个事件必须同时发生才能导致储液罐溢出，所以在故障树中，这两个事件通过一个"与门"（AND Gate）连接。

在这两个原因中，阀门A关闭被视为正常状态，因此不进行进一步分析。 但阀门B打开被视为异常，需要进一步研究其可能的原因。

对阀门B打开这一事件进行分析，发现它可能由以下两种情况引起：

阀门B本身故障，收到了关闭的命令但没有执行；(valve B failed )
或者是控制器没有向阀门B发送正确的控制信号。

这两个原因只要有一个发生，就能导致阀门B打开，所以在故障树中，这两个事件通过一个"或门"（OR Gate）连接。

对 控制器没有向阀门B发送正确的控制信号 这一事件进行分析，发现可能是以下两种情况：

水位传感器（传感器X和Y）故障，没有向控制器发送正确的读数；
或者是控制器本身故障（controller failed），即使收到了正确的读数，也没有发送关闭阀门B的命令。

最后，对 水位传感器故障这一事件 进行分析，发现这需要两个传感器（传感器X和Y）都同时故障，才能导致控制器没有收到正确的读数。因此，这两个事件通过一个"与门"（AND Gate）连接。

这个故障树案例通过逐步探究可能的原因，清晰地展示了如何从一个系统的潜在危险反向分析出可能的故障原因，从而提供了一个更深入理解

Node Symbols

analysis outcomes

故障树分析（Fault Tree Analysis，FTA）是一种被广泛应用于工业系统安全性分析和系统可靠性评估的方法。它通过识别导致系统故障或危害事件的一系列相关因素，能够帮助我们理解和预防系统故障。以下是故障树分析的主要作用：

识别系统故障的根本原因：故障树分析通过逆向工作，从系统故障开始，一步步追溯其可能的直接和间接原因，直到找到故障的根源。这可以帮助我们更好地理解导致系统故障的因素。
增强系统设计：通过故障树分析，可以评估现有设计的安全性和可靠性。该分析可以揭示系统的薄弱环节，并指导系统设计者对设计进行改进，以增强其对故障的抵抗能力。
提供决策支持：故障树分析可以评估不同改进措施的效果，从而为管理决策提供依据。此外，故障树分析也可以在事故调查中发挥作用，通过分析事故的可能原因，帮助决策者采取预防措施。
提高安全意识：故障树分析过程可以提高团队的安全意识，使他们对可能导致故障的各种因素有更深入的理解。

预测和防止未来的故障：通过了解故障发生的机制和原因，可以预测和防止未来的故障，降低故障率，提高系统的安全性和可靠性。

高完整性系统 (2)：Requirement 与 Design 阶段的风险控制——Hazards, HAZOP, Fault Tree相关推荐

高完整性系统（4）Formal Logic （形式逻辑和 Alloy 简介）
文章目录 Story so far 形式逻辑命题 proposition 谓词 predicate 连接词 Variables Set 集合 Set operation 集合操作 Set Relat ...
高完整性系统工程（一）： Safety Engineering, HAZOP Fault Tree Analysis
目录 1. 因果性不等同于相关性 2. HAZOP 2.1 学习HAZOP 2.2 HAZOP概览 2.3 Assessing Hazard Risks 评估 2.4 示例场景 2.5 HAZOP G ...
高并发系统—通用设计方法
文章出自:阿里巴巴十亿级并发系统设计(2021版) 链接:https://pan.baidu.com/s/1lbqQhDWjdZe1CBU-6U4jhA 提取码:8888 我们知道,高并发代表着大流量 ...
看了这个高并发系统架构，才知道我对秒杀的误解有多深
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取推荐书籍来源:33h.co/dCNy 很多小伙伴反馈说,高并发学了那么久, ...
高可用系统架构设计技术方案
背景可靠的系统是业务稳定.快速发展的基石. 那么,如何做到系统高可靠.高可用呢? 高可用方法论下面的表格里,列出了高可用常见的问题和应对措施. 可扩展扩展是最常见的提升系统可靠性的方法,系统的扩 ...
开发高并发系统的三把利器
在开发高并发系统时有三把利器用来保护系统:缓存.降级和限流.缓存的目的是提升系统访问速度和增大系统能处理的容量,可谓是抗高并发流量的银弹:而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉, ...
高并发高负载系统架构
本文作者在Cernet做过拨号接入平台的搭建,而后在Yahoo3721负载搜索引擎前端平台开发,又在猫扑处理过大型社区猫扑大杂烩的架构升级等工作,同时自己接触和开发过不少大中型网站的模块,因此在大型网 ...
12306五大焦点看高性能高并发系统
透过12306五大焦点看高性能高并发系统本文欢迎转载,转载请注明: 转载自IT168: http://storage.it168.com/a2012/0217/1313/00000131342 ...
读书笔记：《亿级流量网站架构核心技术 -- 跟开涛学搭建高可用高并发系统》
from <亿级流量网站架构核心技术 – 跟开涛学搭建高可用高并发系统> 概述一个好的设计要做到,解决现有的需求和问题,把控实现和进度风险,预测和规划未来,不要过度设计,从迭代中演进和完 ...

高完整性系统 (2)：Requirement 与 Design 阶段的风险控制——Hazards, HAZOP, Fault Tree