搬家

由于国内有朋友抱怨blogger给封锁，所以决定把本博客移植到独立域名blog.china-safetyeng.net。希望国内更多人可以了解和交流系统安全工程。

ALARP

既然有人提起，就开个新贴讨论。首先，ALARP只适用于英国，所以其他国家有权不采用，当然法德都有类似的原则如GAMAB和MEM。其二，ALARP有法律含义：就是相关人士有义务把风险尽可能降低，只要在合理可行的前提下。这种义务制是英国特有，就像我们义务教育一样。因此如何定义某风险已经达到ALARP就是要靠义务者和权威人士的判断。这里必然带有个人的主观性。这个制度之所以通行，是基于西方发达国家内在的信任和职业道德体系上。说白了，我雇用你，你就有‘义务’在力所能及的前提下把所负责的事情办到最好。

至于如何判断所谓的合理可行，则由good practices/best practices这个概念决定。也就是说，当我们要对某个风险进行控制时，要考虑到现有已知的各种被行业接受或认同的技术或方案。最新但未成熟的肯定不是good practice。然后决定哪些该采用。这里的决定要考虑到费用和相应的安全得益的权衡比较。

补充一点，要降到ALARP，该风险必须可以容忍(tolerable)。这里容忍界限的定义考虑因素很多。不同国家和地区肯定不一样，每个地方的人都有自己可接受的安全模型，一般都是基于过去的安全数据。也就是说如果一个国家的事故率高，相应容忍界限应该要低些。所谓国情不一样，不能一概而论。其次不同行业也不一样，因为涉及的系统类型不一样。一般都是由国家定义一个可容忍的指标（如每年只能容许若个人员伤亡），然后分配到各个行业（如铁路），最后分配到不同的系统类型（如铁路信号）。必要时还要针对不同的人群来考虑容忍界限：如公众，用户，和公司职员等，因为他们的风险暴露不一样。而公司可以根据这些指标为参考来定义相应产品的风险容忍度。实践上可以使用risk matrix/graph来简化，细节以后再谈。

简单说，ALARP是一种安全风险模型，比较有名的一种。

安全管理

没有人就没有系统，即使高度自动化系统也是需要人来设计/开发，安装和维护。而人总会犯错， 不论在何时何地。所以人的行为对安全有决定性的作用。因此我们需要一个合理和严格的安全管理系统。一旦安全管理系统建立起来，它可以重复应用到不同的产品，技术开发和工程项目。这就是为什么管理这么‘值钱’。所谓管理嘛，无非就是管钱，管人，管项目流程，和管风险。从安全的角度，钱和风险捆绑在一起，所以只剩下三个：人（多个人也就是组织），安全流程，安全风险（要符合ALARP)。再细分一下：组织上要考虑安全责任和角色分配，职员能力，安全文化与培训，队伍之间的沟通与协调，和第三方组织（如供应商）合作，相关的法律义务和责任等。流程上要考虑如何计划和引入安全周期，采用最佳实践，文档纪录和改变控制等。风险上如何保证风险被足够评估和控制等。

不同行业有不同的安全管理系统。航空，国防，原子能，铁路都有相应的指引和规范。这里涉及的方面太多，以后再讨论。而每个公司应该根据这些指引来制定自己的管理系统，所谓因地制宜。个人经验来说，无论这个管理系统制定得如何严格，到执行时又另外一回事。

这就是，说就容易，做是很难滴。

形式方法

凡是涉及安全相关或关键软件开发，形式方法几乎都会谈起。形式方法是一种以（离散）数学为基础的软件开发手段。理想状态就是要像解数学题一样，从需求说明（一旦形式化建立起来）可一步步严格推导到实现。从另外一个角度来看，软件测试就变得可有可无，既然实现可以证明是符合需求。

一说形式方法，很多人都会集中在描述方面(formal specification)，如Z, CSP, B, VDM，而忽略了refinement/verification阶段。如果specification不能跟implementation连接话，那更完美的描述也如同废纸。而且这个连接最好是自动：通过automated theorem prover (推导形式）, 或通过model checker（搜索形式）。

个人不看好形式方法。原因一，它不能根本上解决需求问题。需求来自于用户和特定的领域(domain)，形式方法不可能证明它的描述does the right thing (i.e. validation)。而需求描述体现于知识由用户或stakeholders到开发者的传递和交流协调过程。这里涉及的问题很多，以后再讨论。而需求问题一向是软件失效的主要来源。

原因二，它的推导和证明过程都是基于理想化的abstract machine, 不能连接到最终运行的物理实现平台上，例如大到编译器，小到memory clips and logical gates。要把这一切都推导出来，现有的技术来说，是绝对不可能。

其他限制如scalability (可以通过hybrid或lightweight方法来改善）和过高的开发费用等。

当然它有一定的应用：主要是通信/加密协议，算法，或电路设计。我个人理解，也就是当软件的主要问题不是需求问题，而是特定的设计问题。

形式还是要讲究滴，呵呵。

电磁兼容性

安全工程的另外一个重要分支是电磁兼容性(EMC)。这是要保证电子设备在其电磁环境中能正常工作和抵抗电磁骚扰。原理上，保护措施主要是针对源头和如何阻止传播。具体细节涉及到电路设计，接地设置，和测试等。这都需要专门的EMC工程师负责。当中也有专门的国际规范和标准。安全工程师嘛，只能沟通协调和管理，例如协调EMC plan等。

颇复杂滴。

人因工程学

安全工程的一个重要分支是人因工程(Human Factor Engineering)或人类工效学(Ergonomics)。这个学科估计懂的人很少，国内就更加少。从事这方面的一般都是大学本科学心理学或应用心理学。查了一下wiki, 国内也有工效学学会(Chinese Ergonomics Society) - 1989成立, 但估计这方面还是很新，能听说过人因工程学这个名字的，已经很不错。

重视人因的原因很简单，就是系统理论的‘人-机-环境’合一，看作一个整体系统来分析。没有人，就没有系统，归根到底系统是为人服务。人因工程一个重要应用是人机操作界面设计，试想飞行员按错一个或多个命令键，后果可以是很严重。减少人为错误是安全工程的一个重要目标。另外是操作环境，机械零件，房间等设计，都要符合人因工程。

实践里好像都是使用相应的规范，研究上挺有意思，主要是建立合适的人为错误模型，还有虚拟三维模拟。

似懂非懂。

风险

风险一个很普及的术语，从安全工程，医学，金融到管理，几乎无处不在。不同行业对风险的定义和评估都不一样。例如交通安全，是用每年的伤亡人数来衡量。金融则从特定时间内投资的损失来衡量。总之，风险是跟特定的未来目标挂钩。例如安全风险当然离不开相应的安全功能。

在交通行业，安全风险最低的是飞机(0.01)，其次是火车(0.4)，然后是汽车(2.8)，最高是摩托车(112.6)，次高的是行人(49)。这里的比较是以每十亿乘客公里所引起的平均伤亡人数(2004年的英国数据）。呵呵，所以大家要多称公共交通。就铁路安全来说，最危险的地方是火车站，风险最大的是路人擅入轨道，其次是路人在站内跌倒/滑倒 （英国数据）。国内铁路最危险的据说是level crossings。

风险评估离不开概率。而要降低风险就只能从管理的角度出发，既然没有无风险的东西存在。

有这样一个‘传说’，剑桥有一份大学入学考试问道什么是风险，有学生回答道：这就是风险(This is risk)。万分佩服。

软件可靠性

一个具争议性的老话题。

原因之一是软件失效的概率模型跟过去的时间本身不相关，不具有随机性，而是系统性 - 归根到底，软件故障都是人为错误。当然执行时间可间接影响到软件可靠性，在软件执行周期内，运行时间越长，越有机会执行到可激发到软件潜伏故障的特定输入条件。学术研究上出了一大堆reliability growth models，和最近的context-based/conditional reliability growth models, 都是基于同一个假设：开发是一个逐步改善的匀质过程。现实中是很难实现，例如开发队伍中的人员变动，试想曼联替换一个球员，整个队伍的性能模型肯定有不同哦。其他因素如软件的需求变动等。

原因二，所有可靠性都是基于失效这个概念，而失效的定义是基于需求。和硬件不同，软件开发更灵活，任何人学过编程便可开发软件来实现多种功能，因而软件需求本质上可以很灵活。但这导致软件需求错误成为软件失效的主要来源。在系统工程，软件需求问题更多，因为涉及到特定的专业领域（如航空，铁路，医疗和石油化工）。而软件可靠性是不可能为需求错误而建立数学模型。

老生常谈。

信息安全

security 和 safety 在中文都叫安全，似乎自古以来就把两者看成同一样东西。不过老外也不是区分得很清楚，像很多互联网广告都说web safety or safe web browsing 等。本质上两者都是考虑到对于特定的系统由于各种可能而带来的损失，只不过前者是有目的和人为，后者没有。

在分析问题上，两者都是从反向思维来思考问题：如果某个环节出了差错怎办，有什么威胁或危害并有什么后果。两者都是通过风险评估，因为没有绝对安全的系统。不过具体细节方面两个学科差别很大，前者要密码学，网络协议，还要懂各种现有信息系统的漏洞和病毒。后者需要懂普遍的危害如火灾，漏电，电磁干扰等，电力和机械常识，和安全管理系统。现代safety engineering似乎更强调安全管理，重视管理和协调方面，因为有相应的专业人士如防火工程师和电磁兼容性工程师来处理。估计未来的security engineer可能也会这样，更多的是管理，其他具体问题有相应的密码学专家或特定的网络或操作系统专家来处理。

异想天开，呵呵。

系统安全工程师

干了这个行业这么久，发现系统安全工程师和其他工程师不一样，除了逻辑分析能力，大学数学和相应专业知识外，它还需要很强的协调与管理能力。说白点，挺像个manager, 什么都懂点，但又不是专家，很多时候要和不同的专业技术人员如机械，化工，电子，电力，防火，能源开会和打交道，最后还要对project manager/business manager交待，甚至要说服他们或跟他们辩论。苦差啊，呵呵。

SIL

一个颇老的话题，不过今天又提起。组里某人看了safety-critical mail list里的关于SIL 3 vs SIL4的对话，结果引发出今天team meeting的讨论。老板无奈的说，软件SIL的问题都有decades, 就是没有什么进展，唯一办法就是尽量避免使用。

我个人认为，SIL本质上是跟安全风险挂钩，而安全风险又跟tolerable failure/hazard rate联系着，但软件的可靠性一直是争议性的领域，所以就有SIL determination/allocation问题。另一方面，就算拟定的软件SIL需求没有问题，如何完成它和保证它？所有规范和标准都是泛泛而谈软件开发流程，含糊带过。试问是否任何人使用了规范里高度建议的方法和技术，是否就可以称他开发的系统达到相应的SIL需求？

有时候想，SIL和quality/maturity levels都是差不多的概念，只不过前者是针对于安全性系统开发和来自于安全风险评估，而后者不需要。

没完没了，呵呵。

安全与可靠性工程的未来

星期五老板说在月底前要搞个研讨会有关future of RAMS (Reliability, Availability, Maintenability and Safety)。理由一，现在铁路规范如ROGS对安全案例的要求有所降低，例如大型的安全案例文档已经不需要，当然危害日志，安全需求文档和SIL的需求没有变。理由二，RAMS这个行业是个老行业，有何革新。老板希望大家准备一下想法。

个人认为嘛，未来的东西可有可无，到时候就给点意见把。

系统安全与安全系统

一直有一个谜团：为何国内喜欢用“安全系统”或“安全系统工程”这一用语？ Safety System? 在国外一直惯用System Safety或Systems Safety, 而Safety System只有在特定的上下文中使用，指具体某个保护系统或安全相关系统(Safety-Related System)。

当然这里的安全还可以指security, 信息安全。

第一个博客

想了很久，终于行动了。