闲话安全关键系统系统(一)

帅哥

闲话安全关键系统系统(一)
6 R' E8 y4 o6 R" D. C( r
/ ^3 M3 S6 F3 r/ o1. 什么是安全关键系统(safety-critical system)?
1 |1 e7 P- H% I( y“安全关键系统”听起来比较唬人，它实际上是英文“safety-critical system”的直译，比较拗口。
简单的说，它是一类系统，这类系统如果失效，则会导致人员或财产损失，或对环境产生严重破坏。
8 s/ X  ]5 Q& ]9 ?0 n# Y! J+ J举几个例子，比如运载火箭控制系统、飞机的飞行控制系统，铁路的超速防护系统，核反应堆的安全
保护系统等等，这些都属于安全关键系统。

与这个词有关系的词还包括安全相关系统(safety-related system)。一般情况下，这两个术语的同义词，指的内容是相同的，但也有时候有些区别，比如为了区分系统的不同的安全等级，可以认为safety-critical system的安全等级比safety-related system更高。在本文中，这两个词是等价的。

有时候甚至为了简单，直接就说安全系统(safety system)。说到这儿，你也许该问了，“日常说的安全系统
不是这样的呀？”。原因在于汉语中的“安全”一词实际上对应英文有两个词，一个是security，一个是
safety。在英文中，security主要指与信息有关的安全，safety主要指与生命财产有关的安全。我们经常
# I2 m5 W1 r  t7 \$ E7 s: i听到的安全系统(准确的说是在IT领域)，多数是security system，比如加密系统、防火墙等等。而在化工
" n/ g$ u" T, w6 d  `+ c领域，一般提到安全系统就是指safety system。以后为了防止歧义，都使用英文safety system来代表我们要介绍的安全关键系统或安全相关系统。

下面这个图可以让你对security和safety有个直观的认识。
/ t$ d, u! I5 w7 S5 a9 A

2. safety-critical computer system
7 x3 o. W1 }# X6 q, Ksafety system有很多种，我们这里关心的是那些使用计算机技术实现的系统。更准确的说，是基于软件的安全系统。在没有软件之前，这类系统一般是机械的或继电器控制的，随着计算机技术的发展，在安全系统中越来越多的用到了软件，它带来了与原有的继电逻辑不同的失效模式，产生了一系列新的问题。从20世纪80年代开始，对于safety system的研究逐渐开始兴起，到了90年代末多个安全标准的出台促进了它的研究和发展。影响比较大的就是IEC 61508标准。

不过，即使是有很多安全标准，我们对safety system还是有很多东东要研究。为什么这样说? 因为标准一般都说了该做什么，不会说怎么做? 如何实现一个系统就是安全的是很值得讨论的问题。更重要的一点，与一般的系统开发不同，我们没有机会去按照try-implementation-redesign的方法来做一个safety system，这在成本上不允许，道德上和法律上也是不允许的。

2.1 典型的安全系统故障案例-1  爱国者导弹
说了半天，你也许觉得抽象，那我们举个例子。1991年第一次海湾战争期间，用于拦截飞毛腿导弹的爱国者导弹表现很差，导致多名美军士兵丧生在飞毛腿导弹的轰炸之下。我们这里不去探讨战争的对与错，仅从技术的角度说，爱国者导弹防御系统属于典型的safety system，如果它不能完成它的功能，说明它失效了(failure)。后来，调查出的原因主要是软件故障，该系统最初的设计没有考虑到系统长时间使用的情况，它属于打完了就跑的设备，到另一个地方重新布置再发射，在一个地方不会超过8小时。但实际应用的时候，超过了这个时间，导致其range gated area发生漂移，不再精确，系统在跟踪来袭导弹的过程中产生了偏差，而且使用越久偏差越大。另外，该系统最初是设计用于拦截2马赫的导弹，而飞毛腿是速度是5马赫。

爱国者导弹防御系统的问题属于安全系统开发过程中的典型问题，需求不能满足实际的要求，在过程中又没有检查出来。

7 {( K% W0 Q% Y( o6 FNotes:
On February 25, 1991, a Patriot missile defense system operating at Dhahran, Saudi Arabia, during Operation Desert Storm failed to track and intercept an incoming Scud. This Scud subsequently hit an Army barracks, killing 28 Americans.
' G; D, h7 a& j

帅哥

闲话安全关键系统系统(三)

自从有了网络以后，我觉得自己无法再长时间专注于某一件事情，用我高中老师的话说就是“三分钟热情”。一转眼有半个月没有写safety-critical的文章了。借口总是可以找到的，不过还是该坚持把这件事情做下去。

' K! z! ]$ @. Z$ O; ~4 D/ ~8 b& C1. hazard与risk
7 k$ @. V9 P6 g. L好了，不废话了，让我们回到上次未讨论完的hazard这个概念上吧。hazard的简单定义参考如下：“A state or set of conditions that, together with other conditions in the environment, will lead to an accident (loss event).”hazard是所有安全问题的起源，因此我们要研究safety，就必须先研究hazard，也就是常说的hazard analysis。
我们经常遇到一个词叫风险(risk)，在安全领域，它与hazard紧密相关，实际上，它是“The hazard level combined with the likelihood of the hazard leading to an accident plus exposure (or duration) of the hazard.”，与之对应的工作叫risk analysis（风险分析）。
9 j2 H0 E4 N+ u4 Y% O& k$ @8 F/ O
hazard analysis和risk analysis有什么区别呢？
hazard analysis是一系列技术，每种技术都是从不同的角度给人们提供了一个深入了解系统的方法。它是整个安全系统过程的核心。比如我们常用的FTA，FMEA等技术，都属于这一范畴。hazard analysis影响开发过程的所有阶段，同时又从开放过程的各个阶段得到反馈。
! U4 m% Y+ i' _! l/ N2 u而risk analysis是一个过程，它包括3个部分，风险评估(risk assessment)，风险管理(risk management)和风险交流(risk communication)。
- J- A! F, {: j8 ?6 r8 i( c实际上risk analysis是包含hazard analysis的，risk assessment的一个重要的步骤就是hazard identification，即危害识别。

hazard analysis关注的是对人和环境产生危害的条件和情况，通过不同的技术，要识别出这些情况。risk analysis关注事件产生的后果。
1 G' \3 }( @4 O1 d6 Q" z
$ b; f3 r& D7 H; s* I有关hazard analysis，我曾写了一个读书笔记，是关于论文《Hazard analysis of complex distributed railway systems》的，有兴趣的朋友可以在blog中看看
。

5 J; \/ k7 a1 f8 `0 C* b2. 多安全才算安全?
/ s0 R- r3 L. s设计任何安全系统都有一个边界的问题，即到什么程度才算安全？要解决这个问题，就是要回答我们的系统需要容忍什么样的风险，到什么程度。
7 t7 U. ~, @5 H4 Q目前世界上存在3种衡量方法，分别是ALARP、GAME和MEM。
: M! j, K* Y6 T+ F2.1 ALARP
ALARP的英文全称是“as low as reasonably possible”，在英国应用较广。它把风险分为3类，不可接受的、广泛接受的和界于这二者之间的所谓ALARP区域的风险。比如，一个人可能被从天上掉下的陨石砸死，但其概率非常小，我们认为这是可接受的风险，但如果你高诉我明天做的飞机很有可能从天上掉下来，这就是不可接受的。但界于二者之间的风险就需要考虑避免它的成本，因为任何风险的消除或减小都是要有成本的，如果你不消除它，就要承担某种代价，如果这种代价被认为是可以接受的，那么就不需要消除这个风险。但问题是，往往这种代价就是人的生命，ALARP需要对生命的价值进行定量，从道德上，我们认为“生命是无价的”，但实际生活中，它往往是有价格的，虽然我们不愿意承认。也是由于这个原因，在欧盟其它国家是反对使用这个标准的。

' |2 O9 {, Z5 M8 r0 P2.2 GAME
+ B, [- m( n3 }; z' ]2 UGAME是德国标准，它要求任何新布置的系统的安全性都不能比现有的同类系统差，至少要一样的好。这是我们常见和常用的衡量标准，因为人们已经接受了目前的系统，包括它可能的危害，新的系统一定要至少和现有的一样好，这是符合人的心理预期的。不过，这个衡量标准也有些问题，已经有的系统的安全标准是什么呢？如果它由于技术原因存在某种风险，我们还能接受吗？

2.3 MEM
& ^' A, {) t9 z5 C: z7 v' ~MEM的英文全称是“minimum endogenous mortality”。它要求任何安全系统对一个人的产生致命风险的概率不允许超过每年0.00001。这个衡量标准实际上要求是很高的，相当于每小时的危险概率小于0.000000001，基本没有系统能够达到这个标准。
. _: b/ B  m% v6 B( N/ i" }
上面提到的三个风险容忍的标准，实际上都没有得到统一的认可，也就是说，还不存在一个统一的风险容忍的标准，每个行业都有所不同，不存在所谓的“银弹”。
, r3 q. _- c0 r
注：
2 c' S7 Y% u% m* d关于我们日常认为的不可能的事件，我发现煎蛋上一篇比较有意思的文章列出的数据很有意思。
' |! i; s: K2 u7 k$ [/ u被狗咬死的几率： 两千万分之一
成为圣人的几率： 两千万分之一
0 C0 F0 Q- M" `7 E成为总统的几率： 一千万分之一
6 o. m6 t* N9 _' D: A被天上飞机掉下来的东西砸死： 一千万分之一
上厕所受伤的几率： 一万分之一
第一眼找到一个四叶草（四叶苜蓿）一万分之一
+ m( ?9 ^  m" N2 w3 g3 q6 A今天看到UFO的几率： 三百万分之一
) C0 Z( i7 I# p; t& g今天死于食物中毒的几率： 三百万分之一
* B2 V7 I" ?- \1 w7 ^: }' Z被鲨鱼咬死的几率： 三亿分之一
死于麻疹： 三亿分之一
1 n- P% {7 e- q8 I. C) V# ]1 G儿童遭遇恶性交通事故的几率： 两万三千分之一
# ^3 t9 U/ |+ B  H1 ]1 L由于社会安全数据输入错误所导致
"误杀"（你还没死，系统说你死
了）的几率： 两万三千四百八十三分之一
8 T: p. V% h! c2 O, F% t/ g: Q( O得到纽约时报Best Seller的几率： 二百二十分之一 （以后还看这个推荐买书么？看吧）
和百万富翁约会的几率： 二百一十五分之一
不戴套套得艾滋的几率： 五百万分之一
* n- l! `& d# `' ^8 j被热水搞死的几率： 5005564分之一
在未来100年里死于彗星撞地球： 五十万分之一
普通人被枪杀： 五十万分之一
; G$ B$ k+ L$ ^0 t$ Q空难的一员： 五十万分之一
! h: w1 i" N( R! G

帅哥

闲话安全关键系统系统(五)

! J- U# \1 a9 k! O2 Y任何理论的发展最终到实际中都要以某种形式固定下来，这些形式的东西，术语称之为“过程”。比如软件开发过程、项目管理过程等等。
- s% ]! K6 I7 h" r: [7 N1 i; ~安全系统也不例外，它也有一个过程，我们称为“安全过程”，更时髦一点，叫“安全生命周期”。
& g8 ]/ Z$ d2 `, Y: J0 F  N
" a8 |1 [( ~' R- U如果你对软件开发很熟悉，那么这些概念并不陌生，常见的软件生命周期模型有瀑布模式，螺旋模型，V模型。一般来说，从V&V的角度看，V模型更合适。我们也可以对照V模型，把安全生命周期套用一下。如下图所示。

+ d/ Y8 L- Q4 z* t# d  L9 o

图1. 安全生命周期与系统开发生命周期示意图
+ e& X# S: U3 }9 s, l  A

& b" W. ]& Q! o5 J
对于开发安全系统来说，这两个过程是相互关联和相互影响的，不过现实中，往往只是重视了开发过程的生命周期，而把安全生命周期忽略了，或者认为在开发过程中嵌入一些安全生命周期的内容就可以了，这些都是不正确的方法。严格来说，安全生命周期要有一个独立的团队来完成，通常意义上的软件工程师或硬件工程师是不能胜任这个工作的，需要安全工程师这个重要的角色。
上图中的系统开发过程中的活动的含义和内容你很容易google到，这里就不废话了。我们说说与之对应的安全生命周期中的相关活动。
* {0 x  U% R& G5 R0 F( \
安全生命周期包括6个阶段：
! y5 D: o& M2 O( X" W9 P, l1.危害识别(Hazard Identification)
安全系统开发一开始，就要考虑如何识别基本的危害。开发人员要管理、消除这些危害，并在整个系统开发过程中进行记录。危害的记录一般采用危害列表或危害日志的形式。这些危害往往是通过对开发阶段中需求分析或规格进行研究得到的。
( H8 O. W- C; a2 a1 T& P2 u
9 v/ G4 I' U' ]# G7 C2.风险评估(Risk Assessment)
风险评估阶段要对识别出的危害进行研究，确定它们的严重程度和可能性。根据安全标准的不同，这个阶段采用的方法也有所不同。这个阶段是产生系统安全需求的源头，而且产生的安全需求对软硬件需求和设计也存在影响。风险评估的一个重要概念就是“可容忍的风险”（tolerable risk）。达到可容忍的分析的一个方法就是把风险降低到尽可能的小（ALARP原则，还记得我们第三讲中提到的这个概念吗？）。

3.初步系统安全评估(Preliminary System Safety Assessment, PSSA)
PSSA要对系统体系结构进行系统的评估来确定失效是如何导致已识别的危害。这个阶段你可以使用FTA或FMEA或HAZOP这些方法。这个过程有助于确认系统设计是否满足安全需求，也有助于更准确的阐述安全需求。这个阶段对软硬件体系结构和设计都有影响。

4.共因分析(Common Cause Analysis, CCA)
事实上，共因分析在整个系统开发过程中都是要做的。CCA主要是为了识别功能的独立性或功能之间的依赖关系。一般常用3种方法：区域分析（zonal analysis），检查系统是否存在一个特定位置使得故障影响独立性；特殊风险分析（particular risks analysis）检查系统对环境事件是否免疫；共因模式分析（common mode analysis）识别系统失效是否独立，包括检查软硬设计缺陷。
8 a0 {8 u) W* g& i' a
5.系统安全评估(System Safety Assessment, SSA)
, m' Q2 A- p0 m* L: c8 m8 [SSA是安全生命周期的确认阶段。在这个阶段中，要搜集那些能够证明安全需求得到满足、达到所希望的完整性的证据。这个阶段与软件开发过程联系比较紧密，比如，通过软件测试保证实现与需求符合，开发过程符合安全标准， 这些都属于证据。
: u0 [# p6 Z/ u* B
6.提交安全案例(Delivery of Safety Case)
事实上，这个阶段大部分都是文档性质的工作。安全案例就是一个文档，它描述了整个系统的安全相关的重要内容，为系统的安全性提供论据和论证。这个文档是给评估机构的，目的就是让别人确信你的系统是安全的。这个文档实际上是整个安全生命周期过程的总结，是对整个安全生命周期过程的关键点的索引。

参考文献：Philippa Mary Conmy,Safety Analysis of Computer Resource Management Software, PhD Thesis, University of York, 2005.