孙　媛，赵建军，周伟祝

(海军航空工程学院, 山东 烟台　264001)

安全关键系统(safety-critical system,SCS)[1-2]，泛指具有潜在破坏力的一类系统，此系统一旦失败，就能够造成严重后果，比如：人员伤亡，财产损失或环境破坏等。在软件体系结构设计中的一个常见的做法是从模型和文档不同的体系结构的视角进行软件体系结构设计。一个体系结构视图用一组系统类和它们之间相互关系来表示[3]，同时采用多个视图从不同的角度加以补充，形成一个完整的软件系统体系结构。而安全关键系统的软件架构建模，除上述的软件体系结构建模外，还应包括安全工程相关模型，如故障树、故障模式[6]和影响分析等。

1　问题描述

本文以航空电子设备控制系统软件为研究案例，分析软件体系结构设计对安全的需求。航空电子系统是现代化飞机的一个重要组成部分，与飞机的作战性能密切相关[2]。一些事故报道表明：航空电子系统的故障可能会导致灾难性的后果，导致生命损失。通常航空电子设备控制系统必须满足数以百计安全需求问题。表1为航空电子设备控制系统研究案例对安全性需求的子集。

表1为可能引起危险(Hazard)的因素，而软件的安全性关注那些导致危险条件发生的失效，以及与该类失效相关的设计缺陷和外部输入条件[4,6]。表2列出了危险可能出现的原因、危险类型和风险。其中，HZ1到HZ4的危险类型确定为灾难性的，因为这些危险的可能后果是飞机坠毁。例如，如果一个高空显示，不是正确的值时，会影响飞行员对高度的判断，造成与地面碰撞，导致飞机坠毁，人员伤亡，系统损耗及环境破坏。HZ5危险类型确定为可忽略不计，因为这种危险的结果仅造成地面站的通信错误。

表1　航空电子设备控制系统研究案例对安全性需求的子集

表2　案例研究的危险识别

危险识别确定之后，需要确定安全需求(SRn)。表3中列出了与HZ1相关的安全需求。

表3　HZ1的安全需求

针对上述问题的描述，采用UML组件图，进行了研究案例的架构设计[5，7]，如图1所示。通常一个航空电子设备控制系统软件由前台的显示系统类G1、G2，平台控制系统类P，通信系统类C和导航系统类N组成。P负责接收燃料传感器提供的飞机燃油数据Fuel1和Fuel2；N接收高度表提供的高度数据Alti1和Alti2、陀螺仪提供的飞机姿态数据Gyro1和Gyro2以及GPS提供的飞机位置数据GPS1和GPS2；C主要接收射频数据Radio；G1、G2中显示P、C、N中的飞机的高度、姿态、位置、燃料和射频数据信息并显示出来。

应该注意的是，现有的通用视图，包括图1的组件图并没有直接涉及到安全问题。例如，关于一个组件是否是安全关键的信息是不明确的；安全关键部件没有体现出来；相关的策略和模式也没有体现。在这种情况下，所有的应用知识的安全性都是隐含的，将很难建立设计决策和分析的体系结构与安全问题之间的关系。为了解决安全问题，在图1体系结构设计的基础上，考虑安全工程领域的指导方针和策略，重塑图1的体系结构。

2　软件安全性元模型

鉴于上述分析，提出了软件安全性元模型，如图2所示，用于分析软件安全性问题。图2重用现有元模型的共同概念，提供了一个集成模型。它由3个部分构成：相关危险、安全策略和安全关键模型。元模型的底部为相关危险，主要用来描述存在情况潜在危险所造成或导致的事故。其中，安全需求来自危险识别，危险识别产生相应的后果；根据危险识别生成故障树的结点，故障树分析[8]中主要是“与”、“或”的布尔逻辑操作；故障树分析的目标是分析设计系统中可能的故障。元模型的中间部分为与设计应用相关的安全策略，主要包括：故障避免，故障检测和故障容错3种策略。其中，故障避免策略旨在防止故障发生。当发生故障时，故障是通过施加故障检测策略进行检测[9-11]。故障容错策略是系统时发生故障，以正确地继续并保持一个安全的操作条件的能力。元模型的顶部部分包含呈现在体系结构的设计类。这些类包括：被监控类M、安全关键类SC和非安全关键类NSC。其中，体系结构类F是它们的父类。一个F可以读取另一体系结构元数据，写数据到另一个F中，并控制另一个F。监控类可以通过检查其状态监控一个或多个SC。如果有一个SC出了问题，它可以通过停止/启动/重新启动/初始化等相关的操作做出反应。SC又包含SC。其中一个SC可以是另一个SC的子类。SC可以将发生故障通报给其他安全的关键要素。SC有状态类进行状态描述。如果检测到故障，可能导致发生危险，但该类危险是可以防范的，这时SC可以切换其状态到安全状态。SC中不应该包括那些没有安全关键操作的类。因此，NSC的定义来表示为不包括安全关键操作的类。一个NSC可以是另一个NSC的子类。M或SC能够保证系统的安全性安全策略实现。SC可以提供所需功能实现一个或多个安全需求类(SR)。

3　软件安全性视角定义

图2给出了软件安全元模型，主要包括：危险、安全策略和安全关键模型3个部分，本节针对这3个部分，提出其安全性视图。表4给出了危险视图。其目的是支持的危险辨识过程，显示每一个危险的故障树，能够引起的危险，相关的安全需求和可能的危险后果。

表4　危险视图

表5提出了安全策略视图，用于确定危险的安全策略。安全策略分为故障避免，故障检测和故障容错策略。在前面，定义了故障检测和故障容错策略的关系，通常一个故障可以处理不同的安全策略，这里定义了一个处理故障的安全策略类应具有的属性，并构建安全策略和故障之间的关系，而不是将每个处理的故障作为一个类。这种方法提高了可读性的视图，并能体现故障和安全策略之间的可追溯性。

表5　安全策略视图

表6为安全关键视图。在元模型的定义，定义了一个M和SC及其安全策略。一个安全策略可以通过不同的M或SC实现。因此，定义了一个实现策略的属性，这个视图中，以M、SC、NSC为核心，同时还能够修改SC和SR之间的关系。

表6　安全关键视图

4　体系框架的应用

前面已经采用了观图的方法来描述在第2节中描述的案例研究。下面的小节说明定义的视图在案例研究中的应用。

4.1　危险视图

图3是HZ1危险视图。为简单起见，其他危险被排除。以接受的危险作为参数，并表示出了仅与指定的危险相关的故障和安全需求。这种视图反映了案例研究以下几个问题：

哪些安全需求是来自于哪些危险？与HZ1相关的安全需求在图3中显示。这些安全需求在表3中定义。

确定的危险可能产生的后果是什么？如图3所示，坠机是HZ1的可能后果。

哪些故障能引起哪些危险？通过使用故障树分析能引起HZ1故障，这是一种公知的方法[7]中产生的故障树叶节点。故障编号从F1到F13。它们的定义在表7中的FTA节点的名称中给出。N1和N2注明“Alti1丢失”和“Alti2丢失”。N3和N4代表“，在Alti1故障”和“Alti2故障”。当发生下列条件之一的，可以显示错误的测高数据：当Alti1丢失并且在Alti2(N5)，错误时Alti2丢失并且在Alti1(N6)，错误时有错误在这两个高度计和它们之间的差不小于阈值(N7)，当在G1的故障和G2失败(N8)，当G2在的误差更大和G1发生故障(N9)所示，G失败。

错误描　　述错误描　　述[F1]Alti1丢失[F9]G1故障[F2]与Alti1的通信丢失[F10]G2故障[F3]Alti2丢失[F11]Alti1失败[F4]与Alti2的通信丢失[F12]Alti2通信丢失[F5]Alti1故障[F13]N失败[F6]与Alti1通信故障[F14]G1失败[F7]Alti2故障[F15]G2显示失败[F8]与Alti2通信故障

4.2　安全策略视图

安全策略视图显示了在体系结构中实现的安全策略以及处理故障的策略。图4显示了处理相关的故障的典型策略。故障容错策略的命名为T1、T4、T5、T8、T9。T1是高度数据冗余策略，主要指从两个不同的Alti接收到的高度数据。运用策略T1，处理从F1到F8故障。T5显示高度数据冗余策略。高度数据显示在两个不同的显示系统上。策略T5处理F9、F10故障。T4是高度数据预警的策略，包括：一个高度警告时产生的有两个高度值；从两个不同的高度计接收之间的差异；或当海拔数据是从唯一的高度计接收，或当海拔数据不能从高度计接收时(不同的警告产生区分这些情况)。运用策略T4，处理从F1到F8故障。T8是N恢复策略，主要指当N故障时，重新恢复。策略T8处理F11、F12和F13故障。T9是G恢复策略，主要指当一个G故障时，重新恢复。策略T9处理F14、F15故障。

命名为T2、T3、T6和T7的策略是故障检测策略。T2是一个比较策略，比较来自两个不同的测高设备接收的高度值并检测是否有差别。策略T2处理从F5到F8故障。T3是一个比较策略，它将接收的高度值，其最大值和最小值来检测范围的高度值。运用策略的T3处理从F5到F8的故障。T6是一种监测策略，监控G管理的失败。策略T6处理F14、F15故障。T7是一个监控策略，监控N管理的失败。策略T7处理F11、F12和F13故障。

4.3　安全关键视图

案例研究的安全关键视图如图5所示。该视图显示了安全关键类和危险之间的关系的一个例子。其中，N读取Alti1和Alti2高度数据。G1和G2从N读取高度数据。如果N产生一个警告，通过命令关系通知G1和G2。如果Alti1和Alti2发生故障，则通过故障报告发送给N。NMonitor监控Alti1，Alti2和N，当其中一个发生故障并从故障中恢复停止/启动/初始化失败时，NMonitor可以检测到故障。同样，GMonitor监控 G1和G2，其中一个故障并从故障中恢复停止/启动/初始化失败时，GMonitor就可以检测到故障。

如从图5可以观察到，N是故障树单点，一旦失效会造成全部系统出现问题。为解决图5的单点故障，提供另一种更复杂的设计方案，如图6所示，其中冗余技术是通过定义两个N1，N2；NMonitor控制N1和N2；引入叫AltiMonitor的新监控控制Alti1和Alti2。引入的两个新的策略监控，称为高度健康检查(T10)和高度恢复(T11)。通过对N的冗余策略，解决了故障问题的单点问题。本设计提高了系统的安全性。同时，新的监控和管理器还增加了相关模块之间的关系，提高系统的性能。

5　结论

本文针对现有的方法不直接专注于软件安全问题的体系结构建模的缺陷，采用视图的方法设计安全关键系统解决安全问题。为了这个目的，提出了基于一个元建模方法的软件安全的体系结构框架，明确地解决了安全问题。这一方法为安全关键系统的详细设计提供了分析和支持的基础。

参考文献：

[1]HAVVA GULAY GURBUZ.Architecture framework for software safety[J].SAM,2014,LNCS 8769： 64-79.

[2]洪亮,张福光.军用软件全面质量管理[J].四川兵工学报,2009(6):47-48.

[3]谷青范,张丽花,等.综合化航空电子系统安全性研究[J].第六届中国航空学会青年科技论坛,2014:1366-1371.

[4]STOREY N R.Safety critical computer system[M].Boston:Addison-Wesley Longman publishing Co.,Inc.,1996.

[5]李学仁.军用软件质量管理学[M].北京：国防工业出版社,2012.

[6]徐文华,张育平.基于航电系统架构模型的安全性分析工具的设计与实现[J].计算机科学,2016,43(11A):527-538.

[7]王维锋,孙敬德,肖庆.一种基于构件的军用软件故障诊断方法[J].四川兵工学报,2014(5):102-105.

[8]王威华，王小洁，冷泳林，等.一种基于软件定义的弹性网络资源分配方案[J].重庆理工大学学报(自然科学)，2017(7):145-150.

[9]LEVESON N G.Safeware:System Safety and Computers[M].New York:Addison-Wesley,1995.

[10] CLEMENTS P,BACHMANN F,BASS L.Documenting software architectures:Views and beyond[M].Boston:Addison-Wesley,2003.

[11] KAISER B,GRAMLICH C,FORSTER M.State-event-fault-trees-a safety analysis model for software controlled systems[M].Reliability Engineering & System Safety,Berlin:Springer Berlin Heidelberg,2004,LNCS 3219:195-209.

[12] 杜轶焜，何福，陆柏村，等. 基于VCCP的QR码安全认证方案[J].兵工自动化，2017(6):24-27.