铁路系统软件的安全性在“软件安全性离不开系统过程”中

关于铁路系统软件的安全性，各公司、科研单位均有自己的方法，在此给大家推送一篇文章，来自软件安全性与可靠性公众号。

在“软件安全性离不开系统过程”中，我们提到过：

软件安全性需求的来源：

一是来自系统给软件的分配

二是来自软件向系统的反馈

并在文章结尾给出了一个建议的安全性实施路线图，该图的左侧即是系统向软件分配安全性需求的过程。

系统向软件分配安全性需求的第一步，就是首先要做好功能危险分析（也有叫功能危害分析的）FHA——Functional Hazard Analysis。

功能危险分析FHA在SAE ARP 4761中有详细的描述。对于除民用客机外的我国工程实践来说，目前完整实践标准的FHA工作尚存很多困难，因此我们讨论在现状容易实施的和重点的内容，是对标准FHA的不严谨的简化。

功能危险分析，包含两个层次：整机级FHA和系统级FHA。这两个层次分析的开展使用同一原则。

FHA分析的过程如下:

a)识别对象系统所处层次的所有功能，包括外部功能(exchanged function)和内部功能(internal function)；

b)识别和描述这些功能的失效状态，要考虑在正常和降级运行环境中单个或多个失效；

c)确定失效状态的影响；

d)将失效状态对整机的影响进行分级（灾难性的，危险的，严重的，较大的，较小的、无影响的）；

e)给失效状态分配需求，这些需求将在后面较低层次中实现；

f)识别用于证明失效状态影响等级的支撑材料；

g)识别用于验证失效状态需求符合性的方法；

FHA的详细过程和结果表格形式，标准中有权威的介绍，这里我们不再赘述，而只讨论一些实施过程中可能的要点。

功能危险分析过程是一种自上而下的确定功能的失效状态并对其影响进行评估的方法。什么叫“自上而下”？这指的是功能的“自上而下的分解”，然后基于功能来开展FHA。

首先需要考虑，什么叫功能？

FHA第一步是“识别对象系统所处层次的所有功能，包括外部功能(exchanged function)和内部功能(internal function)”，并要求“系统级FHA确定外部接口的功能框图”，这些要求是在促使我们确定功能的概念和边界。

对于系统功能的定义，可以下图为参考。

外部功能(exchanged function)，就是外部系统能够理解的功能；

内部功能(internal function)，就是系统内部的逻辑功能（也是属于层次比较高的功能）。

确保外部功能(exchanged function)被正确识别的一个简单理解是：功能的输入输出要“从外部系统中来，到外部系统中去”，这样才能构成一个完成的功能。画外部接口图，就是要帮助分析者把住这个框儿。

需要注意的是，不能站在“实现”角度去识别功能。目前工程实践中，有外部功能，有“RS-422数据接收”这样的功能、也有“滤波计算”这样的功能、也有“看门狗”这样的功能，这些就不属于“好”的外部功能，它们没有做到“从外部系统中来，到外部系统中去”，不是外部可理解的exchanged function，尽可能不要放入FHA中。

功能识别描述不准确，后面的工作就不容易开展，就不容易感觉到“自顶向下”的必要性，会觉得好像“不知道分析什么”，再发展就是“感觉系统需求、软件任务书和软件需求差不多”。

内部功能(internal function)也是类似高层次的功能，是复杂系统内部功能逻辑的表述，也是“从内部功能中来，到内部功能中去”。切不可和下面这张图搞混了。

因为FHA阶段，系统设计刚刚确定了系统功能和对外逻辑接口，还没有交联设备和配置项的概念出现，这些是下一步系统体系结构设计要去面对的问题。

从这里看出，不严谨地说，所谓自顶向下的设计过程，也是把图1变成图2的过程，每个过程都有对应的安全性工作，而FHA就是图1阶段的安全性工作，对应图2的安全性工作是后面会提到的初步危险分析PSSA过程。

功能找准了，就可以开展FHA的“危险性”分析了，FHA分析要求对每一个系统功能，分析和识别功能的失效状态（FC：Failure Condition），所谓功能的失效状态，就是这个功能会有什么样的失效。

功能的失效状态，一般有如下指导：

无告警的功能丧失

有告警的功能丧失

功能异常等

在实际应用中，至少要将每个功能在无告警和有告警前提下的功能丧失的影响分析清楚。功能丧失还包括功能完全丧失和功能部分丧失，需要根据功能实际情况详细归纳。

功能异常也具有很多的情况，比如功能过早过快或过晚过慢地开始或结束、功能输出未定义的结果、功能输出错误的结果等。

假设有功能“点火控制”，那么有可能做出类似下面这样的FHA表格。

功能的FC，需要在不同的系统任务阶段进行后果的评估：在刚刚公开发布的预研课题“面向任务的软件系统安全性建模与验证”指南中，要求对航天导弹的“点火、起飞、飞行、再入、毁伤”任务阶段开展安全性验证。如果使用FHA方法进行系统的功能失效状态分析，那么一个功能失效状态需要考虑的阶段就应该包括下表中的内容。

那么“每个”功能要分析的呢？工作量就非常大了。

所以一般情况下，可以通过建立系统的功能失效状态数据清单，通过清单的积累维护和复用来达到有效识别功能FC的目的，以达到保证工作效果、降低工作成本的目的。

在没有数据清单的情况下，依靠工程经验来识别确认。

FHA不仅要考虑单独功能的失效状态，还要考虑多个功能的失效状态

多个功能的失效状态比较复杂，至少包括了：

多个功能失效同时发生；要考虑哪些多个功能失效状态同时发生呢？按照什么样的原则？

一个功能失效状态引起其他功能的失效状态；功能的关系如何描述？按照什么样的功能相关性来考虑“引起”的关系呢？组合？依赖？接口？数据？放到课题里去研究一下吧！

最后，功能失效状态识别会产生安全性需求，包括定量的和定性的。

功能失效状态影响的后果，可以参考下图进行定量安全性需求的制定。

定性安全性需求呢，就是在系统功能层次上做出的对失效状态的预防和控制措施，是顶层的安全性需求。

无论定量还是定性的安全性需求，都有待后续的更低层次的设计和安全性过程去实现。

——本文没有描述的FHA格式和过程，具体请参考ARP 4761中关于FHA的推荐过程。

总结：FHA是安全性工作的第一步，也是软件安全性需求来源的重要途径，它的核心是对系统顶层功能识别失效状态，并评估后果，对后果分级，提出系统安全性顶层需求，这些需求如何一步步落实到软件安全性需求中，是后续系统体系结构设计和软件需求设计的事，是PSSA过程和DO-178过程的工作。