CN112612709A - 一种用于铁路信号系统的软件架构安全分析实现方法 - Google Patents

Abstract

本发明公开了一种用于铁路信号系统的软件架构安全分析实现方法，包括：根据软件安全功能分配到各个软件模块的过程与软件模块之间的调用关系，确定软件模块对于整个软件系统的安全影响，得出需要进行安全分析的软件模块；选取需要安全分析的每个软件模块，确定分析范围内的每个软件模块的分析层级；建立每个软件模块的分析模型；基于建立的分析模型对软件模块进行错误影响分析。

Description

一种用于铁路信号系统的软件架构安全分析实现方法

技术领域

本发明涉及软件安全分析领域，特别涉及一种用于铁路信号系统的软件架构安全分析实现方法。

背景技术

随着铁路信号系统向着集成化和智能化的方向发展，软件在信号系统安全关键功能的控制和防护中发挥的作用越来越大，软件在整个系统中的作用也越来越重要，保障软件的安全性成为保证系统安全性的关键环节。近年来，在安全关键领域的许多事故的发生，都是由于软件本身的失效引起的。因此，需要对软件本身开展安全性分析，针对软件的架构设计，识别安全关键系统中软件设计本身引入的危险行为，得出新的安全性需求，或对系统分配给软件的安全性需求的完整性进行验证，确保软件安全需求在软件架构设计阶段正确实现，保证软件设计符合其预定的安全目标。

传统的软件安全分析，采用系统的危害分析方法对软件功能展开安全分析，比如软件失效模式和影响危害分析(SFMECA)，软件故障树分析(SFTA)等，主要集中在功能失效分析，随着系统功能在软件级的细化，完整的功能分析内容很多，耗时较长。另一方面，传统的安全分析得出的安全需求大多能够由系统级的安全活动分析出的安全需求覆盖，使得在软件级开展传统安全分析性价比不高。

同时，传统的功能安全分析通过将系统分解的方法逐步分析单个组件或者模块的失效，并提出防护措施，从而避免系统的失效。但是，这一假设对复杂的软件可能存在不适用的情况。软件的失效，除了传统分析方法能分析到的软件组件模块的功能失效外，有一部分可能是由于组件模块之间的不安全交互引起的，问题不是源于单个模块的故障，分离和单独分析交互模块往往会使得软件整体的结果失真。软件本身设计方案的选取，比如性能需求与设计实现的临界条件，都可能衍生出新的安全需求，仅进行传统的功能分析角度可能会遗漏这些安全需求。因此，对大规模复杂的软件的安全分析，需要把软件当作一个系统工程，更多针对软件本身的错误影响进行分析。

发明内容

本发明的目的是提供一种用于铁路信号系统的软件架构安全分析实现方法，将软件错误影响分析作为一系统工程，针对软件本身的架构设计展开安全分析，建立分析模型，注重组件模块交互导致的软件失效，聚焦对软件安全失效影响大的环节，弥补传统对软件分解之后进行安全分析的不足，提高了分析的效率。

为了实现以上目的，本发明是通过以下技术方案实现的：

一种用于铁路信号系统的软件架构安全分析实现方法，其特点是，包括：

步骤S1、根据软件安全功能分配到各个软件模块的过程与软件模块之间的调用关系，确定软件模块对于整个软件系统的安全影响，得出需要进行安全分析的软件模块；

步骤S2、选取需要安全分析的每个软件模块，确定分析范围内的每个软件模块的分析层级；

步骤S3、建立每个软件模块的分析模型；

步骤S4、基于建立的分析模型对软件模块进行错误影响分析。

所述的步骤S1包括：

步骤S11、根据软件需求文档中系统向软件级安全需求的分配标签，建立软件安全需求清单；

步骤S12、根据软件架构设计文档与软件需求文档之间的标签追踪关系，建立功能模块与软件安全需求之间的映射关系；

步骤S13、分别从软件模块的控制流角度、数据流角度和运行环境的角度，分析各个软件模块对于整个软件系统安全影响。

所述的步骤S13包括：

步骤S131、选取未开始分析的软件模块确定其是否属于分析范围；

步骤S132、判断分析选取的软件模块的功能是否为控制、监视或者验证与安全相关的软件和硬件的行为；

步骤S133、判断分析选取的软件模块的功能是否为安全相关的决策关键信息；

步骤S134、判断分析选取的软件模块的功能是否对安全相关的系统的运行产生影响；

步骤S135、将分析的软件模块纳入安全分析范围列表。

所述的步骤S2包括：

步骤S21、选取分析范围内的其中一个软件模块；

步骤S22、判断软件模块是否满足设定的安全规则表；

步骤S23、根据软件模块与安全规则表的匹配关系，确定分析层级。

所述的步骤S22包括：

步骤S221、所述的判断模块是否仅执行非安全功能，若是则执行步骤S222，否则执行步骤S223；

步骤S222、对软件模块的输出数据开展安全影响分析，分析软件模块的输出对其他安全模块的影响；

步骤S223、判断软件模块是否是经过证明的复用模块，若是，执行步骤S224，否则执行步骤S225；

步骤S224、对软件模块进行接口数据流、控制流安全分析，进行复用模块的使用符合性验证，然后执行步骤S229；

步骤S225、对软件模块进行安全关键度分析，然后执行步骤S226和步骤S227；

步骤S226、判断软件模块的安全关键度是否超过阈值，若没有超过，执行步骤S224，若超过，执行步骤S228；

步骤S227、判断软件模块是否采用了易错的架构，若是，进一步执行步骤S228和S231，若不是，执行步骤S226；

步骤S228、进行软件模块内部逻辑分析，并验证在软件需求阶段分配的安全需求在模块内部被正确实现；

步骤S229、对软件模块开展耦合度分析，对非复用的安全功能模块，判断其与执行安全功能模块之间的耦合程度；

步骤S230，判断软件模块与执行安全功能模块之间的耦合程度是否超过阈值，若不是，分析结束；若是，执行步骤S231；

步骤S231，开展模块间时序和临界资源分析，并对模块接口间数据流和控制流进行分析。

所述的步骤S3包括：

步骤S31、根据软件模块的架构设计文档的特征分别建立模块安全需求清单、调用模块清单和临界资源清单；

步骤S32、根据软件架构设计文档中的处理逻辑描述，将调用模块按照调用的先后顺序排列；

步骤S33、根据软件需求阶段的状态转换描述和软件架构设计文档中的处理逻辑描述，确定在逻辑链路上软件的运行状态和运行状态转换时刻，并确定软件模块的安全需求作用于逻辑链路上的环节，得到软件模块的分析模型。

所述的步骤S31具体包括：

步骤S311、根据软件架构设计文档对软件需求文档中安全相关需求的继承标签，建立与分析模块相关的安全需求清单；

步骤S312、根据软件架构设计文档中的模块、进程调用描述建立调用模块清单；

步骤S313、根据软件架构设计文档中的使用资源和模块输入输出描述，建立模块相关的临界资源清单。

所述的步骤S32之前还包括：

多次对获取的清单信息数量进行判定，若信息数量没有满足预设值时，则继续执行步骤S31。

所述的步骤S4包括：

步骤S41、对每个软件模块进行标准符合化验证；

步骤S42、对于每个分析的软件模块，根据分配的功能确定其与安全相关的失效模式；

步骤S43、基于得到的软件模块的分析模型，确定导致软件模块安全功能失效的原因及失效的时间节点；

步骤S44、对所述软件模块执行对应的安全补救行为。

本发明与现有技术相比，具有以下优点：

(1)本发明制定了安全相关度评价准则，在分析前先根据安全需求的分配和安全度评价准则确定了分析层级，通过量化的方法确定了安全分析的重点，对安全关键度高的模块进行重点深入分析，减少了工作量，提高了分析效率；

(2)本发明将与分析模块相关的调用模块和临界资源按照时序逻辑进行描述，进行安全需求集合看成针对软件系统保证安全性的控制器，确定安全需求的控制点，建立了分析模型，能有效表示模块之间的交互对系统安全性的影响；

(3)本发明在基于模型的错误影响分析时，将软件当成一个系统工程，更多考虑由于软件模块或者组件间交互的影响，能弥补传统安全分析将软件进行分解分析的不足。

附图说明

图1为本发明确定软件模块分析范围的流程图；

图2为本发明确定软件模块的分析层级的流程图；

图3为软件模块的架构安全分析模型；

图4为建立每个软件模块的分析模型的流程图；

图5为软件错误影响分析输入输出图；

图6为软件错误影响分析流程图；

图7为用于铁路信号系统的软件架构安全分析实现方法的流程图。

具体实施方式

以下结合附图，通过详细说明一个较佳的具体实施例，对本发明做进一步阐述。

一种用于铁路信号系统的软件架构安全分析实现方法，包括：根据软件安全功能分配到各个软件模块的过程与软件模块之间的调用关系，确定软件模块对于整个软件系统的安全影响，得出需要进行安全分析的软件模块；选取需要安全分析的每个软件模块，确定分析范围内的每个软件模块的分析层级；建立每个软件模块的分析模型；基于建立的分析模型对软件模块进行错误影响分析。

图1示出了确定软件模块分析范围的流程图，如图1所示，确定分析范围的依据主要有三个：一是系统级危害和安全需求对软件的分配；二是安全功能对组件或者模块的分配；三是软件架构的选取方案。

根据EN50128，软件的安全完整性等级是在系统层级确定的，软件的安全功能是在系统架构设计阶段分配的，由软件需求继承，并产生软件安全性需求。我们需要根据软件需求阶段的安全需求、软件架构设计阶段的软件模块架构设计、软件架构设计阶段模块和功能的对应关系，把软件模块当成是黑盒，从以下几个方面来衡量我们分析的软件模块是否和安全相关：

从控制流角度分析，软件是否用来控制、监视或者验证与安全相关的软件和硬件的行为；

从数据流的角度分析，软件是否提供了安全相关的决策关键信息；

从运行环境的角度检查，其是否对安全相关的系统的运行产生影响。

根据以上选取准则，我们确定了需要进行安全分析的范围：它不仅包括我们传统意义上执行安全功能的模块，还可能包括对安全功能有影响的非安全功能模块。

进一步地，软件架构设计阶段将软件的安全需求落实到具体的架构设计过程中，安全功能会分配到具体的软件模块，可以根据这一分配过程以及软件模块之间的调用关系，确定哪些模块对软件的安全性有影响，得出分析范围，具体步骤如下：

在步骤401中，根据软件需求文档中系统向软件级安全需求的分配标签，建立软件安全需求清单，然后执行步骤402。

在步骤402中，根据软件架构设计文档与软件需求文档之间的标签追踪关系，建立功能模块与软件安全需求之间的映射关系，然后执行步骤403。

在步骤403中，选取未开始分析的模块开始确定其是否属于分析范围，然后执行步骤404。

在步骤404中，根据系统架构设计阶段系统向软件安全功能的分配和软件架构设计阶段软件需求与软件模块之间的对应关系，判断分析选取的模块的功能是否为控制、监视或者验证与安全相关的软件和硬件的行为，若不是，执行步骤405，若是，执行步骤407。

在步骤405中，根据系统架构设计阶段系统向软件安全功能的分配和软件架构设计阶段软件需求与软件模块之间的对应关系，判断分析选取的模块的功能是否为安全相关的决策关键信息，若不是，执行步骤406，若是，执行步骤407；

在步骤406中，根据系统架构设计阶段系统向软件安全功能的分配和软件架构设计阶段软件需求与软件模块之间的对应关系，判断分析选取的模块的功能是否对安全相关的系统的运行产生影响，若不是，执行步骤408，若是，执行步骤407；

在步骤407中，将分析的模块纳入安全分析范围列表，然后执行步骤408；

在步骤408中，判断是否对所有的模块完成了分析，若不是，执行步骤403；若是，分析结束。

进一步地，本方法还包括：选取需要安全分析的每个软件模块，确定分析范围内的每个软件模块的分析层级。

上述的安全分析层级的选取规则如下表：

软件分析层级确定规则表

安全相关程度的判定准则根据产品的特性确定，安全相关程度高的模块为执行产品核心功能的模块，比如通用安全平台执行安全通信、存放安全数据、二取二比较、BIT功能的模块；通用产品中的执行关键算法的模块。判定准则可以由项目团队采用评分表的方式确定。

与关键安全模块的耦合程度根据与安全关键模块之间的交互次数(函数调用、全局数据变量的使用)确定，并以规则3中确定的交互模块的安全关键度作为权值计算的加权和确定阈值。

对步骤1中确定的软件模块，在逐一确定其分析层级的过程中，可以用表1中列出的5条准则确定分析深度。

具体地，如图2所示，对步骤401到408中确定的分析范围内的每一个模块，确定分析层级的具体步骤。其中，软件安全关键度判断准则和耦合度判断准则，可以由行业的标准、公司的相关程序文件，结合项目的特点和研发阶段具体确定。步骤如下：

在步骤409中，选取分析范围内的一个模块，执行步骤410。

在步骤410中，判断模块是否仅执行非安全功能，若是，执行步骤411；若不是，执行步骤412。

在步骤411中，对模块的输出数据开展安全影响分析，分析模块的输出对其他安全模块的影响，结束分析。

在步骤412中，判断模块是否是经过证明的复用模块。若是，执行步骤413，若不是，执行步骤414。

在步骤413中，对模块进行接口数据流、控制流安全分析，进行复用模块的使用符合性验证，然后执行步骤418。

在步骤414中，对模块进行安全关键度分析，然后执行步骤415和步骤416，安全关键程度的判定准则根据产品的特性确定，安全相关程度高的模块为执行产品核心功能的模块，比如通用安全平台执行安全通信、存放安全数据、二取二比较、BIT功能的模块；通用产品中的执行关键算法的模块。判定准则可以由项目团队采用评分表的方式确定。

在步骤415中，判断模块的安全关键度是否超过阈值，若没有超过，执行步骤413，若超过，执行步骤417.

在步骤416中，判断软件模块是否采用了标准或者公司程序文件中规定的易错的架构，若是，执行步骤417和420，若不是，执行步骤415，易错的架构为采用了标准或者工程应用中不推荐的设计架构，EN50128中对软件架构和编程规范提出了要求，有推荐和不推荐的项；

在步骤417中，进行模块内部逻辑分析，并验证在软件需求阶段分配的安全需求在模块内部被正确实现，即软件模块内部的设计实现正确，满足分配的安全需求。

在步骤418中，对模块开展耦合度分析，对非复用的安全功能模块，判断其与执行安全功能模块之间的耦合程度。

在步骤419中，判断模块与执行安全功能模块之间的耦合程度是否超过阈值。若不是，分析结束；若是，执行步骤420；

在步骤420中，开展模块间时序分析，临界资源分析，模块接口间数据流、控制流分析，分析结束。

在确定了软件模块的分析层级之后，需要建立分析模型，展开软件错误影响分析。本发明需要对软件架构展开的安全分析主要集中在三个方面：软件模块之间的交互对系统安全性的影响；软件内部逻辑实现的正确性；对安全功能分配和数据定义的正确性和完整性进行验证。为便于分析：(1)我们依据软件架构中的软件逻辑描述、软件运行模式描述、软件运行的物理架构描述和软件数据定义的描述；(2)借鉴控制理论中反馈控制的思路，将安全需求集合看成针对软件系统保证安全性的控制器，将整个软件系统看成是被控对象，建立了分析模型；(3)对每个模块按照执行时序列出该模块调用的模块、模块对安全相关临界资源的操作，可以得到软件内部的耦合关系，即软件模块之间的相互影响；(4)整理出分配给该模块的安全性需求，确定软件安全操作是作用在第三步建立的时序逻辑的哪个时刻，并分析安全控制给软件系统安全性的反馈。

模型假设说明：

1.在不同的层级，调用模块代表不同的内容，比如需要分析软件架构阶段描述的模块内部时，调用模块代表模块内部被调用的函数，而对软件架构阶段描述的模块间的交互影响分析时，调用模块代表各个功能模块；对软件组件间的交互的影响分析，调用模块代表各个软件组件。

2.在分析模块之间交互对软件的安全影响时，假设单个模块的功能被正确实现，仅考虑软件失效是由模块之间不正确的交互引起的。

3.在建立模型时，可能由于缺乏足够的信息导致模型无法建立，这时可以返回到重新确立分析的层级。

具体地，如图3、4所示，图3为软件模块的架构安全分析模型，本发明将安全关键软件系统当成是一个带有控制器的和反馈通路的系统，其中安全需求是为保证整个系统的安全属性施加的控制。在考虑模块交互的影响时，将与分析模块相关的临界资源(比如共享内存、系统安全数据库、信号量等)和被调用的模块按照调用的逻辑顺序列出，并在时序链路上确定安全需求实现的时刻，进行标记。

图4是建立软件架构分析模型的步骤，对每个需要分析的模块，按照以下步骤建立模型：

在步骤421中，根据软件架构设计文档对软件需求文档中安全相关需求的继承标签，建立与分析模块相关的安全需求清单，然后执行步骤422。

在步骤422中，根据软件架构设计文档中的模块、进程调用描述建立调用模块清单，然后执行步骤423。

在步骤423中，根据软件架构设计文档中的使用资源和模块输入输出描述，建立模块相关的临界资源清单，然后执行步骤424.

在步骤424中，根据软件架构设计文档中的处理逻辑描述，将调用模块按照调用的先后顺序排列，然后执行步骤425。

在步骤425中，判断是否有足够的清单信息执行步骤424。如果是，执行步骤426，如果不是，则回到步骤422和步骤423补充清单信息。

在步骤426中，根据软件架构设计文档中的处理逻辑描述，将调用模块按照调用的先后顺序排列，然后执行步骤427。

在步骤427中，，判断是否有足够的信息执行步骤426。如果是，执行步骤428，如果不是，则回到步骤422和步骤423补充清单信息。

在步骤428中，根据软件需求阶段的状态转换描述和软件架构设计文档中的处理逻辑描述，确定在逻辑链路上软件的运行状态和运行状态转换时刻。然后执行步骤429。

在步骤429中，根据软件需求阶段的安全需求描述和软件架构设计文档中的处理逻辑描述，确定这些安全需求是在逻辑链路的哪个环节起作用的，并进行标注。建模完成。

图5描述了在软件开发安全生命周期中本发明的安全分析在整个流程中的承接关系。在架构阶段的安全分析，需要用到软件需求阶段安全活动输出的安全需求、安全关键功能和安全接口数据定义来建立模型。软件错误影响分析的输出又可以作为下一阶段安全分析的依据，

对分析范围内的每个模块，对照EN50128标准附录表3确认对应SIL的技术措施组合是否被采用。

通过时序分析、控制流数据流分析和结构化论证的方法，确定模块在软件的哪些运行状态，在哪个执行时间点会导致软件安全功能失效的可能。根据建立的模型，分析出的导致软件失效的原因大部分是软件本身设计不合理引起的，并确定从软件执行逻辑链路上确定软件失效发生的时间点。

确定安全相关的失效在失效发生的时间点前后是否有对应的安全措施防止失效的发生或者降低失效发生的危害。

图6是针对建立的模型开展软件错误影响分析的具体流程：

在步骤430中，对分析范围内的每个模块，为保证软件架构设计阶段用到的技术措施符合EN50128标准关于软件架构设计阶段的要求，需要对照EN50128标准附录表3确认对应SIL的技术措施组合是否被采用，然后执行步骤431。

在步骤431中，对每个分析的模块，根据分配的功能，确定与安全相关的失效模式，然后执行步骤432。

在步骤432中，基于分析模型，通过时序分析、控制流数据流分析和结构化论证的方法，确定模块在软件的哪些运行状态，在哪个执行时间点会导致软件安全功能失效的原因，然后执行步骤433。

在步骤433中，从软件执行逻辑链路上确定软件失效发生的时间点，对所述软件模块执行对应的安全补救行为。

所述的执行对应的安全补救行为包括：

在步骤434中，确定安全相关的失效在失效发生的时间点前后是否有对应的安全措施防止失效的发生或者降低失效发生的危害。如果有，执行步骤435，如果没有，执行步骤436。

在步骤435中，根据公司或项目的程序文件要求，判断是否需要进行代码安全检查，若不需要，执行步骤438，若需要，执行步骤437。

在步骤436中，对步骤434中没有防护措施的，提出新的安全需求反馈到系统级，或者修改软件需求到软件架构阶段的安全需求的继承。

在步骤437中，提出新的安全需求反馈到系统级，或者修改软件需求到软件架构阶段的安全需求的继承，然后执行步骤438。

在步骤438中，对照行业或公司的安全相关软件安全架构设计准则，给出软件架构的安全性评价，分析结束。

基于图5所示的软件错误影响分析在软件开发安全活动中的承接关系，建立图3所示的软件架构安全分析模型，按照图1，图2，图4和图6的步骤确定分析范围、分析层级和建立分析模型、执行安全分析，构成了完整的软件错误影响分析流程。通过图7所示的流程对这些模块进行安全分析的步骤描述如下：

步骤439中，根据步骤401到步骤408，列出需要分析的软件模块清单，然后执行步骤440；

在步骤440中，根据步骤409到步骤420，确定分析范围内每个模块的分析层级，然后执行步骤441；

在步骤441中，根据步骤421到步骤429，建立每个模块的分析模型，然后执行步骤442；

在步骤442中，判断441中的模型建立是否缺少必要的信息。若是，则返回到440，重新确定分析层级；若不是，则执行步骤443.

在步骤443中，根据步骤430到步骤438，执行软件错误影响分析，然后执行步骤444；

在步骤444中，根据443中分析的结果整理在软件阶段衍生的安全性需求，然后执行步骤445；

在步骤445中，根据443中分析的结果整理在下一阶段需要验证的安全性需求，然后执行步骤446；

在步骤446中，给出软件安全分析的结论。执行步骤447.

在步骤447中，判断分析结论是否符合软件架构设计阶段放行条件，若不符合，在软件架构设计更新后，返回步骤439进行迭代；若符合，结束分析。

尽管本发明的内容已经通过上述优选实施例作了详细介绍，但应当认识到上述的描述不应被认为是对本发明的限制。在本领域技术人员阅读了上述内容后，对于本发明的多种修改和替代都将是显而易见的。因此，本发明的保护范围应由所附的权利要求来限定。

Claims (9)

1.一种用于铁路信号系统的软件架构安全分析实现方法，其特征在于，包括：

步骤S1、根据软件安全功能分配到各个软件模块的过程与软件模块之间的调用关系，确定软件模块对于整个软件系统的安全影响，得出需要进行安全分析的软件模块；

步骤S2、选取需要安全分析的每个软件模块，确定分析范围内的每个软件模块的分析层级；

步骤S3、建立每个软件模块的分析模型；

步骤S4、基于建立的分析模型对软件模块进行错误影响分析。

2.如权利要求1所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S1包括：

步骤S11、根据软件需求文档中系统向软件级安全需求的分配标签，建立软件安全需求清单；

步骤S12、根据软件架构设计文档与软件需求文档之间的标签追踪关系，建立功能模块与软件安全需求之间的映射关系；

步骤S13、分别从软件模块的控制流角度、数据流角度和运行环境的角度，分析各个软件模块对于整个软件系统安全影响。

3.如权利要求2所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S13包括：

步骤S131、选取未开始分析的软件模块确定其是否属于分析范围；

步骤S132、判断分析选取的软件模块的功能是否为控制、监视或者验证与安全相关的软件和硬件的行为；

步骤S133、判断分析选取的软件模块的功能是否为安全相关的决策关键信息；

步骤S134、判断分析选取的软件模块的功能是否对安全相关的系统的运行产生影响；

步骤S135、将分析的软件模块纳入安全分析范围列表。

4.如权利要求1所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S2包括：

步骤S21、选取分析范围内的其中一个软件模块；

步骤S22、判断软件模块是否满足设定的安全规则表；

步骤S23、根据软件模块与安全规则表的匹配关系，确定分析层级。

5.如权利要求4所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S22包括：

步骤S221、所述的判断模块是否仅执行非安全功能，若是则执行步骤S222，否则执行步骤S223；

步骤S222、对软件模块的输出数据开展安全影响分析，分析软件模块的输出对其他安全模块的影响；

步骤S223、判断软件模块是否是经过证明的复用模块，若是，执行步骤S224，否则执行步骤S225；

步骤S224、对软件模块进行接口数据流、控制流安全分析，进行复用模块的使用符合性验证，然后执行步骤S229；

步骤S225、对软件模块进行安全关键度分析，然后执行步骤S226和步骤S227；

步骤S226、判断软件模块的安全关键度是否超过阈值，若没有超过，执行步骤S224，若超过，执行步骤S228；

步骤S227、判断软件模块是否采用了易错的架构，若是，进一步执行步骤S228和S231，若不是，执行步骤S226；

步骤S228、进行软件模块内部逻辑分析，并验证在软件需求阶段分配的安全需求在模块内部被正确实现；

步骤S229、对软件模块开展耦合度分析，对非复用的安全功能模块，判断其与执行安全功能模块之间的耦合程度；

步骤S230，判断软件模块与执行安全功能模块之间的耦合程度是否超过阈值，若不是，分析结束；若是，执行步骤S231；

步骤S231，开展模块间时序和临界资源分析，并对模块接口间数据流和控制流进行分析。

6.如权利要求1所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S3包括：

步骤S31、根据软件模块的架构设计文档的特征分别建立模块安全需求清单、调用模块清单和临界资源清单；

步骤S32、根据软件架构设计文档中的处理逻辑描述，将调用模块按照调用的先后顺序排列；

步骤S33、根据软件需求阶段的状态转换描述和软件架构设计文档中的处理逻辑描述，确定在逻辑链路上软件的运行状态和运行状态转换时刻，并确定软件模块的安全需求作用于逻辑链路上的环节，得到软件模块的分析模型。

7.如权利要求6所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S31具体包括：

步骤S311、根据软件架构设计文档对软件需求文档中安全相关需求的继承标签，建立与分析模块相关的安全需求清单；

步骤S312、根据软件架构设计文档中的模块、进程调用描述建立调用模块清单；

步骤S313、根据软件架构设计文档中的使用资源和模块输入输出描述，建立模块相关的临界资源清单。

8.如权利要求6所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S32之前还包括：

多次对获取的清单信息数量进行判定，若信息数量没有满足预设值时，则继续执行步骤S31。

9.如权利要求1所述的用于铁路信号系统的软件架构安全分析实现方法，其特征在于，所述的步骤S4包括：

步骤S41、对每个软件模块进行标准符合化验证；

步骤S42、对于每个分析的软件模块，根据分配的功能确定其与安全相关的失效模式；

步骤S43、基于得到的软件模块的分析模型，确定导致软件模块安全功能失效的原因及失效的时间节点；

步骤S44、对所述软件模块执行对应的安全补救行为。

Images