最近想写点关于安全分析(safety analysis)的内容，在脑海里构思了有一周时间，安全分析涉及面广，这个工作可以说是功能安全产品研发的核心，开始于V模型生命周期的风险分析阶段，在产品开发中持续进行。对于安全分析，不懂功能安全的人觉得很深奥，涉及到了很多内容，比如危害识别、风险评估、风险控制，各种安全分析方法PHA、IHA、SHA、O&SHA、FMEA、FTA、HAZOP、共因失效分析等等，光看这些专业名词就会把人搞晕；而做安全分析的人感觉做了大量的危害分析报告、安全分析表格，费时费力，但对产品研发起到的作用呢，着实有限，缺少话语权，团队中安全工程师的地位不高。这篇文章并不想对安全分析的流程、方法进行讲解，一来很多标准、书籍都有很全面的讲解，二来讲具体方法应结合实例，一篇文章泛泛来说也没什么价值。笔者在十几年的功能安全从业工作中，做产品研发时做过系统级、软件和硬件的安全分析工作，也在产品开发和安全评估中与安全工程师经常交流，深知做安全分析面临的困境。在这里主要谈谈功能安全中为什么做安全分析和如何高效做安全分析两个问题。
现实中产品逆向设计的情况很多，轨道交通早期以技术吸收引进为主，拿到的是国外厂商引进的产品技术规格、硬件图纸、开发代码和生产文件，这时参考国外同类产品的设计指标，对技术进行吸收并国产化；另外，一些小的企业通过对标业内先进的产品，开发同种类型的产品，或者直接从大企业中挖来技术人才进行开发。安全分析是一个由因导果的过程活动，在已有参考结果的情况下，产品本身已经包含了安全相关的设计需求，有没有独立的安全分析就不是很重要。但对于正向设计的产品，安全分析用于发现常规产品开发不需要考虑的安全相关需求，比如对各种故障场景的防护需求，硬件诊断需求，通信协议的失效保护需求等。如果没有进行全面的安全分析，产品需求的完整性就有缺失。逆向工程的产品就完全不需要安全分析吗？也不是这样，安全产品很多问题是改出来的，由于设计修改者对于原有产品的设计初衷缺乏理解，在修改中可能会影响到产品的安全功能，产生安全隐患。因此，对于产品变更升级带来的差异，需要做变更影响的安全分析，评估对产品的安全性的影响。安全需求通过安全分析得出，对于系统的顶层安全需求很好理解。比如轨道交通中列车定位功能是安全需求，因为在安全分析中，列车的位置识别错误会造成列车之间的安全间隔建立产生偏差，间隔不足导致追尾事故。随着系统需求的逐级分配，顶层安全需求会分解到软件需求和硬件需求，同时在设计过程中的安全分析也会得出安全设计相关的需求。对于具体开发人员，细化后的安全需求就不那么直观了。举一个硬件设计的需求：列车自动防护系统硬件平台中，安全输出对于输出接点回读的诊断时间不超过50ms。这条需求如果没有跟安全分析关联，不把它定义为安全需求，对于开发工程师可能没什么感觉。但是在安全分析中，是通过一个自顶向下，系统化的分析过程，来确定一系列细化后的安全需求。就拿上面这条需求来说，需要结合系统的应用场景，以列车的安全防护功能为例，系统级的指标为从系统检测出行车安全的故障，到发出紧急制动指令，不超过750ms。首先，分析行车安全的故障包括哪些，安全输出接点状态属于其中一项，因此应对输出接点进行回读诊断，然后，在系统动作时间的分解中，对于接点故障检测时间分配应不超过50ms，以此来达到系统动作时间不超过750ms的要求。因此，开发过程如果没有持续的安全分析，会丢失很多细化的安全需求；其次，安全需求通过自上而下的分析过程，才能得出安全需求及其风险的关联关系，避免产生拍脑袋定需求的问题。经常遇到这样一种情况，某产品的软件开发流程满足功能安全SILx等级。所有的软件都符合SILx等级，貌似看来，这种要求似乎更严格。通过上面的分析可知，软件的安全需求是通过安全分析得出的，没有进行系统的安全分析，软件需求不完整，即使开发流程满足功能安全标准的要求。产品的安全需求存在缺失的情况，流程不能保障产品的安全性达到目标。但流程认证不能说没有用，可以类似于质量管理体系或软件开发体系认证，说明企业关于XX产品的开发质量过程是符合功能安全标准要求的，这对以后做产品功能安全奠定了良好的基础。
以上讲了安全产品开发中安全分析的重要性，下面结合实际工作，谈谈开展安全分析的一些实践方法。参与安全分析的人的能力是能否有效的全面的识别系统安全需求的基础，参与安全分析的人应建立一个核心小组，包括系统、安全、软件、硬件的负责人，由团队中能力较强、经验丰富的人组成，小组之间的沟通尤为重要，越早越好。有一种情况把安全分析完全看作是安全工程师的工作，把安全分析作为开发流程合规性的一个输出，这样的话安全分析能产生的价值就很有限。建议通过一些增强团队协作的方法提高各专业对安全分析的统一认识，比如：
- 包含团队的各利益相关方的核心成员，对安全方面的技术决策、一致性、变更控制形成统一意见；
- 以就事论事的态度开展对于问题的讨论，允许有不同的意见，在需要的时候，不要害怕来自外部的客户或第三方机构提出意见；
- 安全需求需要清晰、可验证、可测试，未实现安全需求或安全需求偏差对系统带来的风险是清晰的，将其文档化，并与整个团队共享。不要以莫须有的态度来揣测安全，能够对问题进行澄清，防止错误的决策；
轨道交通功能安全标准EN50126、EN50128对于项目中各专业职责有着明确清晰的定义，里面有项目经理、开发者、验证者、确认者等角色，唯独没有定义安全工程师这个角色，个人理解也是因为安全工作涉及到各个方面，在不同阶段团队中不同的角色都会承担一部分工作，如果把这个工作从职责上限定到一个角色上面，安全工作能起到的作用就很局限了。
2.2 有效开展安全分析的实践
在团队建立起关注安全的文化后，如何将团队智慧组织起来，运用适合自身的工具方法，能够高效地开展安全分析工作。方法运用的不得当，主要精力陷入到繁重的文档工作中，实施一段时间后，起不到应有的效果，就会打击团队对于安全分析重要性的信心，不愿意在这方面投入资源。安全分析方法如FMEA、FTA、HAZOP都应基于对系统应用场景，体系架构，内外部接口已有基本的逻辑，以此来驱动当前阶段应用哪种安全分析方法更合适。安全工程师尽量避免僵化地套用安全分析方法，比如对系统架构、功能分配、分析组件的故障模式没有什么概念时，也不可能分析出有价值的安全需求。
做好安全分析的策划。
在项目开始初期，就建立书面正式的安全计划，安全计划各工作的责任方和配合方是明确的、实用的，根据团队中各方的能力水平，制定合理的安全计划，并为跨专业的安全分析会议建立沟通机制。安全分析不是一蹴而就，在生命周期发生安全需求的变更迭代很正常，建立一个流程化的变更影响分析管理过程。
基于团队已有开发经验，再结合行业内标准实践，建立一个安全需求的经验库很有价值。
将功能安全标准中的技术要求，团队中有经验者的已有安全设计经验，以往发生的事故经验教训，由负责主导安全的人进行总结，把这些经验成果与导致危害关联起来，能够解释出需求背后的原因，用结构化的方式解释安全需求的来源。按照安全分析的过程逐步丰富，在产品开发中先把经验库用起来，把适用的安全需求纳入到产品架构和软硬件需求中。这样可以把分散的安全需求集集中在一起管理起来，建立起开发团队对于安全分析的统一认识，逐步升级为更上级的企业标准。
尽早开展系统级的安全分析。
尽早开展系统级的安全分析工作，决定了系统体系架构的可行性。采用哪一种安全架构、安全需求由系统内哪一个部件承担、硬件来做还是软件来做性价比更高、选择哪一种操作系统及额外安全验证的工作、采用新技术的安全风险和验证方法。这并不是一个简单的初步风险分析，而是要在概念阶段找到关键的安全需求。
使用需求管理工具，把安全需求管理起来。
安全需求应该具有明确的安全属性，对于软件开发、硬件开发、验证确认者都清晰可见。Excel表对个人而言也可以管理分类需求，但它无法在团队中按照开发生命周期流转，也不易于需求的变更跟踪。未在产品的设计过程、验证与确认过程落实下去的安全需求没有作用，安全需求应随着设计过程的深入进行分解和细化，如果没有工具进行有效管理，一两个项目没有什么问题。持续进行的话，安全需求管理的工作就成了繁重的paper work和报告整理工作，无法腾出更多精力投入到需求分析的工作。
对安全分析的输出做好验证。
伴随着安全分析的输出结果，应对安全需求进行有效的验证。在项目前期，验证主要是对安全分析的正确性、完整性、无歧义性进行，以文档评审和分析为主，随着设计的深入，安全需求分配到软件需求和硬件需求，为安全需求设计全面合理的测试用例，以确保安全需求在应用场景是否被正确地实现，则更为关键。
三、结语
从事功能安全相关领域工作的人，无论是安全工程师，系统架构师，还是软件和硬件工程师。当你所做的产品是功能安全相关时，意味着产品的设计偏差，需求不完整等缺陷，可能会导致对人的危害发生。所以功能安全从业者应保持一颗敬畏之心，把握做事之道，把安全分析做到实处。
