随着软件密集型系统和信息物理系统的兴起，系统的规模剧增，系统组件间的交互、人机交互和软硬件交互越来越复杂，从而导致系统事故频发[1]。其中几乎所有涉及软件的严重事故都可以追溯到需求缺陷[2]，安全性需求在保证系统安全性中的作用日益关键。
在需求工程领域，通常将安全性需求作为非功能性需求/目标[3-4]或质量因素[5-6]进行处理，通过对安全性目标的精化和可操作化[7]、对安全性质量因素的分解和分类[5, 8]以及使用安全性需求模式[9]，由安全工程师人工分析得到安全性需求。但这种对安全性需求和功能性需求分别独立定义的方法，难以得到较完备的安全性需求，导致系统安全性问题没有被很好的解决[10]。并且该方法依赖安全工程师的人工分析和定义，费时耗力，带有一定的盲目性和倾向性。因此，结合系统功能性需求自动生成安全性需求的相关研究很有必要。
安全性需求生成的一种重要方法是安全性分析[11]，通过对系统功能模型进行安全性分析，得到安全性需求，并据此完善系统功能模型，从而得到较完备的系统功能模型和安全性需求。目前，一般用基于链式/树式事故因果模型的FTA/SFTA、SFMEA等安全性分析方法，对系统场景[12-13]或系统结构[14-15]进行分析，得到系统失效模式并生成相应的安全性需求。然而，SFTA等安全性分析方法主要针对简单的低耦合系统，不适用于软件密集型系统或信息物理系统等高耦合复杂系统的安全性分析[11]。并且其所用的链式/树式事故因果模型将事故的原因局限于系统组件失效，因此不能生成较完备的安全性需求。
为了解决传统链式/树式事故因果模型及安全性分析方法的局限性，Leveson[2]提出了基于系统理论事故模型和过程(STAMP)，将系统看作层次化的控制结构，认为事故是由系统间的控制过程没有成功施加安全性约束导致的，并在此基础上提出了系统理论过程分析(System-Theoretic Process Analysis，STPA)方法[2]。该方法分2步：①确定导致系统进入不安全状态的危险性控制活动(Hazardous Control Action，HCA)；②在控制结构中确定HCA的原因。由于STPA将系统的不完备控制作为事故原因，涵盖了系统组件失效、组件间交互不一致等原因，因此可用于生成更加完备的安全性需求。但在使用STPA生成安全性需求时面临着以下挑战：①STPA的分析对象是系统设计阶段的系统控制结构，不能直接用于对常用的系统功能性需求模型进行分析；②STPA只给出了HCA的分类，分析过程依赖于人工，缺乏详细的可用于自动化分析的方法。
本文在HCA的结构模型[16]基础上，提出一种安全性需求分析方法Auto-STPA。该方法在系统功能场景及其控制特征描述的基础上，进行系统控制结构和过程分析建模，根据控制过程中系统变量(System Variables，SV)对控制的影响构建变量影响图，然后在此基础上自动生成HCA并转化为相应的安全性需求。
1 Auto-STPA方法总体架构为了结合系统功能性需求得到较完备的安全性需求，并且借助于自动化方法保证安全性需求的生成质量和效率，在提高系统安全性的同时降低成本，本文在STPA的HCA分类[2]及结构模型[16]基础上，针对系统功能性需求场景，提出了一种安全性需求分析方法Auto-STPA，如图 1所示，该方法包括场景建模、控制结构分析、控制过程分析，以及在此基础上的安全性需求分析。
|
| 图 1 Auto-STPA方法总体架构 Fig. 1 Framework of Auto-STPA method |
图 1中所描述的Auto-STPA方法的主体处理步骤如下：
1) 场景建模。为了使用STAMP因果模型对场景进行安全性分析，本文结合控制特征的要求对时序图进行扩展，并进行规格化表示，从而用于场景建模，获得用于表示场景的控制特征时序图。
2) 控制结构分析。由于控制活动来源于系统控制结构，本文从场景控制特征时序图所描述的交互中，分析得到系统的控制过程，然后根据这些控制过程间的关系，建立系统的控制结构。
3) 控制过程分析。因为HCA是在系统控制过程中分析得到的，所以需要对系统控制过程进行分析建模。该步骤对场景控制特征时序图中的消息等进行系统变量提取，并根据其在控制过程的作用分析其关系，用变量影响图建模。
4) 安全性需求分析。根据控制结构和过程分析模型，自动构建HCA树(HCAT)进行安全性分析，得到HCA，并将其转化为安全性需求。在分析过程中，进行错误和矛盾自动检测，保证安全性需求的正确性和一致性。
2 需求场景建模与分析对需求场景进行控制结构和过程分析是进行安全性需求分析的基础。
2.1 场景及其控制特征描述场景一般包含在系统用例中，目前常用的场景建模方法有自然语言描述、规格化的自然语言描述和活动图等。控制作为一种系统不同层次间的交互，难以从这些场景模型中直接分析出来。而时序图由于能够表示场景中的交互，可以较容易地从中得到控制结构。
为了从场景的控制特征时序图模型中分析得到控制结构，时序图应能对控制的特征进行描述。根据进行控制所需的4个基本条件[2, 17]可知，有效的控制过程(见图 2)具有以下特征：①控制路径和反馈路径形成一个控制闭环；②控制活动(Control Action，CA)是不同对象间的交互，且该交互的结果应达到一定的控制目的；③通过过程模型中的系统变量，对被控制过程进行控制并反馈控制结果。标准的UML时序图对此缺乏相应的描述机制。例如，时序图中的消息缺乏对控制活动的明确标识；由于异步消息没有返回消息，时序图的交互并没有形成显式的控制闭环；时序图交互的消息只有返回值，不能完全表示控制反馈结果等。
|
| 图 2 基本控制过程示例 Fig. 2 Example of basic control process |
针对上述问题，本文对标准的UML时序图进行了扩展，使其能够满足对场景及其控制特征描述的要求。
1) 在时序图的消息上引入构造型<<control action>>标识出控制单元发出的控制活动。如果不同对象间的某个交互，其后置条件包含于场景所在用例的后置条件，则该交互的发起消息为控制活动。每个用例的“触发事件”通常对应一个控制活动。
2) 为了描述控制结果并识别控制活动，对消息添加可选的[#control results]opt: {SVi=valuei}部分，valuei表示SVi的结果。对于<<control action>>消息，[#control results]表示预期的控制结果，其响应消息的[#control results]表示实际控制结果。
3) 每条<<control action>>消息必须有控制反馈消息与其对应，用于反馈控制的结果。消息的处理过程用以消息接收为起始，以发送响应消息为结束的“执行说明”表示，从而能够对控制过程的控制闭环特征进行描述。在<<control action>>消息处理的执行说明中，最后发送的响应消息通常为其控制反馈消息，可以用构造型<<feedback>>对其进行标识。
以电梯系统Request Elevator用例的主要成功场景[13]为例，该场景触发事件为用户按动电梯按钮，电梯接收到相应命令后提取目的楼层信息，并计算电梯运行方向和运行距离，生成电梯调动命令。在电梯运行之前，系统先发送命令确保电梯门关闭。在电梯停靠在目的楼层后，发送命令打开电梯门。根据上述描述机制，该场景及其控制特征描述如图 3所示。其中，press_elevator_button、CloseDoor等消息作为控制活动，用<<control action>>进行标识，并且与其反馈消息组成控制闭环。由于消息8、11、12反馈的[#control results]包含于系统整体预期控制结果中，即消息1的[#control results]，因此该实例包含3个直接
|
| 图 3 电梯系统控制特征时序图 Fig. 3 Control characteristic sequence diagram of elevator system |
控制过程：User控制System、System控制门系统和拽引系统；消息1的[#control results]不包含消息6的[#control results]，因此System控制门系统的过程为间接控制过程。
为了便于自动化分析，本文将上述针对控制特征扩展的时序图定义如下。
定义1 控制特征时序图
控制特征时序图C-SD可以表示为5元组<O,M,E, →,ES>。
1) O={O1,O2,…,Om}为对象集合，Oi(0<i<m)为时序图中第i个对象。
2) M={mi|mi⊆[attribute=]opt [<type>.]optname [argumentlist]opt[:return-value]opt[#control results]opt}为消息集合。<type>表示消息类型：<CA>说明是CA消息；<CR>说明是控制反馈消息；<COMM>说明消息是普通的通信消息，一般可省略。
3) E=M×{s,r}为事件集合。s表示消息的发送，r表示消息的接收。对于消息mi，发送事件用<mi,s>表示，接收事件用< mi,r>表示。
4) →={<m1,m2,…mi,…,mn>|mi∈M∪COMB}为消息的偏序关系，表示时序图的消息轨迹。COMB为表示交互片段的特殊消息集合，每个交互片段由2个特殊消息组成：①片段起始消息，包含交互片段操作符构成的消息名和监护条件构成的参数列表；②片段结束消息，一般以“END_交互片段操作符”命名。
5) ES=O×Es×Ee为执行说明集合，表示交互的执行过程。Es⊆E和Ee⊆E分别为起始事件和终止事件集合。
根据定义1，图 3时序图形式化表示为
O={User,System,DoorSys,MoveSys}
M={1<CA>.press_elevator_button()#{elevator-
Pos=destinationFloor,elevator=stop,door=
open},2update_the_reguest(destinationFloor),
3,4,5,6,7,8,9,10,11,12}
→=<1,2,3,REF(SD-CloseDoor)(4,5,6)EN-
DREF,Opt(door==closed)(REF(SD-Dispatch
Elevator)(7,8),ENDREF)ENDOpt,9,REF
(10,11)ENDREF,12>
E={<mi,s>,<mi,r>|mi=1,2,3,4,5,6,7,
8,9,10,11,12｝
ES={<User,<1,s>,<12,r>>,<System,<2,
s>,<2,r>>,<System,<3,s>,<3,r>>,
<DoorSys,<4,s>,<6,r>>,<DoorSys,<5,
s>,<5,r>>,<MoveSys,<7,s>,<8,r>>,
<System,<9,s>,<9,r>>,<DoorSys,<10,
s>,<11,r>>}
式中：M中的消息除部分给出具体形式外，其他的用消息序号表示。根据消息的格式可以从中提取出系统变量以及控制结果。ES中的每个元素表示一个过程，并且满足控制过程的闭环结构特征，便于后文根据<<control action>>消息及其反馈消息分析控制过程。另外，可以发现ES中的执行说明存在嵌套情况，形成了过程和子过程的关系，这种关系在后文被用来进行控制结构分析。
与传统的自然语言等描述方法相比，本文控制特征时序图对场景的描述更加直观，其形式化定义便于进行自动化分析；与标准的UML时序图相比，本文控制特征时序图在交互描述中突出了场景中的控制特征，并且所用的消息结构可以更好地进行系统变量和控制结果等信息的提取，便于后文控制结构和过程的分析。
2.2 控制结构和过程分析在系统控制理论中，系统被看作是层次化的控制结构，每层系统对其下层系统的行为进行约束，即高层通过约束对低层的行为进行控制[2]。这种系统控制结构层次间的控制及其反馈过程形成了如图 4所示的控制环，使得系统保持动态平衡状态。控制环作为基本控制结构和过程的描述，定义如下。
|
| 图 4 基本控制环 Fig. 4 Basic control loop |
定义2 控制环
控制环CL表示为5元组<controller,CP,CR,RCA,{<CA,CEDP>}>。
1) controller表示CL所描述的控制过程中的控制单元。
2) CP∈ES表示CL所描述的“控制过程”。
ES: <obj,es,ee>为CP对应的执行说明。
3) CR:{SV=value}表示CP的“控制结果”。value为系统变量SV对应的值。
4) RCA表示controller所接收到的控制活动，即该CP所处理的控制活动。对于顶层CL，该字段为Null。
5) <CA,CEDP>表示CP中的“被控制过程”。CA为controller发出的控制活动，CEDP∈ES为CA对应的“子控制过程”。
由定义2可知，在场景的控制特征时序图中，ES集合的每个执行说明esk，满足esk∈ES且∪nk=1esk=ES，n=card(ES)。假设esk的起始事件Es对应消息mi，其终止事件Ee对应消息mj，若mi为CA消息，mj为其控制反馈消息，则esk对应一个控制环cl，且cl.CP=esk，cl.controller=esk.obj，cl.CR为mj的[#control results]，cl.RCA=mi。若esk存在子执行说明es′∈ES，使得es′对应消息序列是<mi,…,mj>的子序列，且es′为控制环，则cl.<CA,CEDP>为<es′.obj,es′>，从而从场景的控制特征时序图中自动提取出控制环。
在一个控制环CL中，如果存在<CA,CEDP>，则说明controller在对RCA的处理过程CP中生成了新的控制过程，即发生控制过程嵌套，并且CEDP是CP的子过程，CEDP对应的CLCEDP是其子控制环。
对于存在嵌套的控制过程，其嵌套的子控制过程存在3种作用：①控制过程将要进行的控制传递到子控制过程处理；②控制过程分解为多个较简单的控制在子控制过程中处理；③子控制过程通过生成父控制过程执行所需的某些条件，实现间接控制。其中，①和②是完整的控制过程，其控制结果(部分)达到整体控制目的；③不是完整的控制过程，其控制结果是父控制过程中的某些条件，没有直接(部分)达到父过程的控制目的。本文现阶段只考虑完整的控制过程，即控制环CL满足条件：$\forall $CLi，如果∃CLj使得CLj.CP⊆CLi.CEDP，即CLj嵌套于CLi，则CLj.CR⊆CLi.CR。
根据上述控制环的定义及条件，图 3所示场景中存在4个完整的控制环。
1) ControlLoop1
(User,<<1,s>,<12,r>>,{elevator-St==stop,
elevator-Pos==destinationFloor,door==open},
NULL,{<System,<1,r>,<12,s>>})
2) ControlLoop2
(System,<<1,r>,<12,s>>,{elevator-St==stop,
elevator-Pos==destinationFloor,door==open}，
press_elevator_button(),{<MoveSys,<7,r>,
<8,s>>,<DoorSys,<10,r>,<11,s>>})
3) ControlLoop3
(MoveSys,<<7,r>,<8,s>>,{elevator-St==stop，
elevator-Pos==destinationFloor}，DispatchEle-
vator(direction,distance),NULL)
4) ControlLoop4
(DoorSys,<<10,r>,<11,s>>,{door==open },
openDoorCom(),NULL)
控制结构作为一种通过系统/组件间的控制/反馈关系进行组织的系统结构，期望通过系统间的控制施加安全性约束，从而达到一定的控制目的。控制结构中的分层是通过层次间的控制过程来确定的[18]，过程之间只具有嵌套关系或不相交关系[19]，因此，系统的控制结构可以由若干个描述控制过程的控制环间的嵌套或不相交关系组成，其定义如下。
定义3 控制结构
控制结构CS={CLij | CLi+1 j′ ⊆CLij,0<i,0<j,0<j′}。CLij处于CS中第i层且为该层第j个CL，CLi+1 j′处于CS中第i+1层且为该层第j′个CL，使得CLi+1 j′ .CPCLi j.{<CA,CEDP>}.CEDP成立。
根据定义3，可以得到如图 5所示的控制结构图。从图 5可知，CL1,1=ControlLoop1，CL2,1=ControlLoop2，CL3,1= ControlLoop3,CL3,2= ControlLoop4，且CL1,1的controller将控制传递到CL2,1处理，CL2,1的controller将控制过程分解为两个子控制，分别通过CL3,1和CL3,2进行处理，达到最终的控制目的。与目前只表示系统/组件间的控制关系的控制结构定义[20]相比，本文的控制结构定义除了用控制环表示系统/组件间的控制关系外，还用控制环间的关系表示控制过程的分解和传递，从而更加便于对系统控制结构和过程进行安全性分析。
|
| 图 5 电梯系统控制结构 Fig. 5 Control structure of elevator system |
通过控制结构完整性检测，能够发现控制过程缺陷导致的危险，如缺少控制反馈等，但是由于控制结构不能表示控制过程中所施加的约束以及约束的作用过程，因此不能从中分析发现STAMP因果模型的约束没有成功施加等6种危险因素[2]。为了分析得到由于控制施加的安全性约束不完备，或约束施加过程缺陷而导致系统进入危险状态的6种HCA，本文对系统功能性需求场景进行分析，从中提取出控制过程所涉及的系统变量及其之间的关系，并用变量影响图进行建模。通过系统变量及其之间的关系对控制活动所施加的约束进行控制结果预判，发现导致系统进入不安全状态的HCA，并在控制施加约束的过程中，通过系统变量间的相互作用分析出没有达到控制目标的原因。另外，系统变量之间的关系还可以用来发现错误的HCA，以及将HCA精化到更低级别。
在控制过程中，系统变量之间的关系是控制规则的来源[2]，安全性约束往往通过对系统变量的限制来体现，并且通过系统变量间的关系进行施加，从而达到控制目的。本文根据系统变量在控制过程中的作用，将系统变量间关系分为横向关系和纵向关系，并定义如下。
定义4 系统变量间的关系
系统变量间关系SVR=｛<x,y>,x和y为SV｝，表示x在控制过程中影响y。SVR=H∪V。
1) H=SV×K_SV，SV={sv|sv∈→CL.(CP-CEDP).m}，K_SV={sv|sv∈CL.CR}，表示系统变量间的横向关系，即：如果SV通过作用于控制活动的生成和传递过程影响K_SV，从而达到控制目的，则称SV和K_SV的笛卡儿乘积组成的关系是横向关系。
2) V=SV′×K_SV，SV′={sv|sv∈CR}，表示系统变量间的纵向关系，即：如果SV′通过作用于控制活动的执行或处理过程影响K_SV，从而达到控制目的，则称SV′和K_SV的笛卡儿乘积组成的关系是纵向关系。
根据定义4，可以用以下规则判断控制环CL中系统变量间的关系：
1) CL.CP中新的系统变量与CL.CR中的系统变量是纵向关系。
2) CL.CEDP之前子过程中的系统变量与CLCEDP.CR(即该被控制过程的控制结果)中的系统变量是横向关系。
3) CL.RCA中的系统变量与CL.CR中的系统变量是横向关系。
4) CL.CP中如果存在组合片段生成的特殊消息，则组合片段条件中的系统变量与其交互片段中的系统变量是横向关系。
通过上述关系定义和判断规则，可以从控制环组成的控制结构中分析得到如下定义的变量影响图，对系统变量及其之间的关系进行建模。
定义5 变量影响图
变量影响图VEG=<SVs,H,V>。SVs为CS中系统变量的非空集合，H为SVR的横向关系，V为SVR的纵向关系。
图 6所示电梯系统的变量影响图中，节点表示系统变量对应的状态机，H边和V边分别描述了系统变量间的横向和纵向关系。控制活动直接作用于某些系统变量(如direction和distance)，利用变量影响图中系统变量间的作用关系，将约束传递到被控制对象(如elevator-Pos)，达到控制目的(如电梯对齐停靠在某楼层)。这样通过变量影响图，在一定程度上刻画了控制活动施加约束的过程。因此，变量影响图不但能够用于发现控制过程中的错误，还可以用来分析导致系统危险的控制偏差产生的原因，解决了现有的被控制系统模型SED[21]和层次过程模型[16]所表示系统变量间的函数组成关系只能用于系统危险或目标分解细化的局限性。
|
| 图 6 电梯系统局部变量影响图 Fig. 6 Part of variables effect graph for elevator system |
另外，由于目前的控制结构和过程分析模型一般由设计人员直接给出[22]，控制结构和过程分析模型与需求间的一致性得不到保证，并且使得目前STPA分析局限于系统设计阶段。本文从描述功能性需求场景的控制特征时序图中自动提取控制结构和过程分析模型，不但保证了控制结构和过程分析模型与需求描述的一致性，而且将安全性分析提前到需求阶段，降低了系统安全性保证的成本。
3 安全性需求分析安全性需求分析一般以系统安全性分析为基础，本文在STPA方法[2]的基础上，根据系统控制结构和变量影响图，对施加约束的控制活动进行安全性分析，生成可能导致系统进入不安全状态的HCA，并且根据其结构模型[16]将其自动转化为安全性需求。
3.1 HCAT和时间因素分析安全性需求一般由安全性分析得到的危险原因生成。根据STAMP因果模型，STPA将导致系统危险的HCA分为4类[2]，但STPA并没有给出HCA的分析方法[23]。本文安全性需求分析方法在STPA的HCA分类基础上，对系统进行安全性分析，生成HCA并转化为安全性需求。HCA作为STAMP因果模型的事故原因，表示因违背安全性约束而导致系统危险的控制行为。Thomas[16]将HCA定义为4元组(SC,T,CA,Co)，SC为控制单元，CA为控制单元提供的控制活动，T为CA的类型：提供(provided)或不提供(not provided)，Co为控制活动的上下文。由该定义可知，HCA主要由CA及其作用/应该作用的Co组成，其中CA可以用其作用的系统变量(称为关键SV)表示，Co也可用系统变量集合表示。因此，本文安全性需求分析方法根据控制结构和变量影响图，生成如下定义的HCAT，对控制过程中导致系统进入不安全状态的CA及其上下文进行分析。
定义6 危险性控制活动树
HCAT是满足如下性质的树结构：
1) 树的根节点为控制活动CA，有2个T节点作为其子节点，分别表示CA的不同类型T的取值。
2) T节点的子节点为关键SV节点，表示CA是否作用造成关键SV的不同取值情况。
3) 关键SV节点的每个子节点为sv的不同取值情况，sv为组成Co的系统变量，即关键SV节点的子树为Co子树，表示CA的上下文。
4) Co子树中，其根节点sv的子树是一个由其他系统变量组成的Co子树。
由于危险被定义为导致事故的系统状态或条件[2]，也可用系统变量集合表示，因此可以在HCAT中，用危险对其中路径的合法性进行检测，从而保证树中每条从根节点到叶子节点的路径都表示一个HCA。
STPA方法认为除控制活动提供与否导致的2种HCA外，在控制活动提供并执行的情况下，还存在如下与时间因素相关的4种HCA需要进行消除或控制[1]：
1) PTE(Provided Too Early)：由于提供的太早，或提供顺序错误，而导致系统进入不安全状态的HCA。
2) PTL(Provided Too Late)：由于提供的太晚，或提供顺序错误，而导致系统进入不安全状态的HCA。
3) STS(Stopped Too Soon)：由于结束太早而导致系统进入不安全状态的HCA。
4) ATL(Applied Too Long)：由于应用时间太长而导致系统进入不安全状态的HCA。
因为HCA的4元组定义[16]和定义6中缺乏明确的时间约束，所以HCAT无法直接生成上述与时间因素相关的HCA。本文对HCA中的时间因素进行了分析，得到如表 1所示的规则。通过这些规则，可以根据系统变量的状态变迁，用HCAT生成所有类型的HCA。
| HCA种类 | 时间因素对应规则 |
| PTE | 1) “关键SV”变迁后的状态+“上下文”的前一个状态； 2) “关键SV”变迁后的状态+“上下文”当前状态 |
| PTL | 1) “关键SV”不发生变迁的状态+“上下文”的当前状态； 2) “关键SV”变迁后的状态+“上下文”下一个状态 |
| STS | 1) “关键SV”变迁后状态的下一个状态+“上下文”的当 前状态； 2) “关键SV”变迁后的状态+“上下文”当前状态 |
| ATL | 1) “关键SV”不发生变迁的状态+“上下文”的当前状态； 2) “关键SV”变迁后的状态+“上下文”下一个状态； 3) “关键SV”不发生变迁的状态+“上下文”下一个状态 |
HCA可用于生成系统/组件行为的安全性需求和约束[1]。从表 2所示的安全性需求和约束可知，安全性需求和约束一般具有“系统-对象-系统行为-行为发生上下文”的结构(系统行为中可以包含行为的作用对象，行为发生上下文中可以包含时间等约束)，因此可以将安全性需求表示为与HCA对应的3元组(system,behavior,context)，system=HCA.SC,behavior=HCA.T+HCA.CA,context=HCA.Co，这样本文安全性需求分析可以在自动生成HCA后将其转化为安全性需求。
| 编号 | 安全性需求和约束 |
| 1) | Door must designed to facilitate immediate reversal of direction 门系统必须能够快速进行反向动作 |
| 2) | Door must be designed and located to withstand emergency conditions 门系统必须在紧急情况下进行开关门操作 |
| 3) | Sensor must be designed to operate in the presence of X,Y,Z materials 传感器必须在X、Y、Z物质存在时仍能正常工作 |
3.2 安全性需求分析方法
在第3.1节分析的基础上，本文提出了根据变量影响图等自动生成安全性需求的方法。首先，根据变量影响图中变量间的横向关系构造HCAT；然后，根据HCAT和表 1所示规则生成HCA；最后，根据安全性需求的表示和转换规则，将HCA转换为安全性需求。另外，在用变量影响图构建HCAT的过程中，通过路径检测保证HCAT中每条路径都能够转变为一个HCA，并且通过错误及冲突检测和处理保证生成结果的正确性和一致性。
输入：危险H，变量影响图VEG，控制结构CS。
输出：安全性需求。
1) 初始化HCAT。$\forall $CA∈CS,K_SV⊆CA-K_SV,树根节点root=CA，root.lchild=T，root.rchild=T′，K_SVi.parent=T & K_SVi.parent=T′，其中，CA-K_SV 为CA作用的“关键SV”集合，T和T′分别表示CA是否提供的T节点，K_SVi为根据K_SV取值生成的节点。
2) $\forall $sv∈VEG.SVs，如果sv与K_SV中系统变量具有横向关系，且sv不存在于HCAT中，根据系统变量间关系SVR，对其每种可能取值生成节点CO_SVi作为当前HCAT叶子节点的子节点。对于当前HCAT进行危险检测，如果$\forall $hi(vi1,vi2,…，vin)∈H,∃pj(svj1,svj2,…，svjm)∈PATH:{vi1,vi2,…，vin}{svj1,svj2,…，svjm}，其中PATH为HCAT的路径集合，说明当前路径能导致危险，标注出所导致的危险。
3) 根据HCA时间因素对应规则，在T子树上进行危险检测。之后，删除HCAT中没有标注危险的路径。
4) 如果HCAT的左右子树中具有相同Co路径，则说明这两条路径标注的危险相互冲突，根据危险优先级，删除优先级低的路径。
5) 如果HCAT中存在路径包含CLk.CP中“关键SV”及其控制路径上SV的取值，其中CLk∈CS，则说明系统目标和系统危险间存在矛盾，删除该路径。
6) 遍历HCAT中从根节点到叶子节点的所有路径，并删除路径上的K_SV，生成HCA集合。
7) 将HCA转化为相应的安全性需求。
该方法中，步骤1)和步骤2)是根据定义6构造HCAT，并且在步骤2)中对导致的危险进行了标注，另外用系统变量间的关系进行Co子树构造，避免了生成错误的HCA，保证了所生成需求的正确性。步骤3)~步骤5)是HCAT剪枝过程，其中，步骤3)是进一步做时间因素分析后剪去安全路径；步骤4)和步骤5)是进行冲突检测和解决，从而保证了所生成需求的一致性。在生成HCA后，可以根据文献[16]的方法，用变量影响图中的纵向关系对HCA进行精化。步骤6)、步骤7)是HCA及其对应安全性需求的生成。本文安全性需求分析方法不但在HCAT构造和剪枝过程中对CA所有的上下文情况进行了处理，保证了能够使用VEG和CS生成完备的HCA集合，而且根据HCA时间因素对应规则，生成了STAMP因果模型所有类型的HCA，从而保证了最终生成的安全性需求在数量和类型上的完备性。
下面以电梯系统为例，对图 6所示的变量影响图中所示的系统变量，做出如下假设：
1) SV：destinationFloor由于在场景的一次执行过程中恒定不变，因此作为常量处理。
2) K_SV：elevator-Pos的值为right和wrong，分别表示其是否在destinationFloor。
3) SV：door的值为open和closed，分别表示调度时门开和关。
4) SV：distance具有值aligned和not aligned，分别表示是否与楼层对齐。
5) SV：direction具有值right和wrong，分别表示调度方向对错。
为了表明该方法的矛盾发现和处理能力，引入2个危险。H1：门开时电梯进行调度；H2：电梯没有对齐时停止调度，且优先级H1>H2。根据上述方法，对于电梯系统的控制活动DispatchElevator，所生成的HCAT如图 7(a)、图 7(b)所示。
|
| 图 7 电梯系统HCAT Fig. 7 HCAT of elevator system |
图 7中：用H标识的路径表示HCA路径；用“×”标识的路径是在HCAT构建过程中被剪枝的安全路径；方框表示存在危险冲突；标识有“×”的方框表示经冲突处理所删除的节点。所生成的安全性需求有：
1) 电梯调度活动不能在电梯门打开且电梯与楼层对齐时进行。
2) 电梯调度活动不能在电梯门打开且电梯没有与楼层对齐时进行。
3) 电梯门关闭且电梯没有对齐楼层时必须进行电梯调度活动。
4) 电梯不能在电梯门没有完全关闭时就太早进行调度。
5) 电梯不能调度太晚，以至在电梯门再次打开时进行。
6) 电梯调度活动不能结束太早，以至在电梯没有对齐楼层时就停止。
7) 电梯调度活动应用时间太长，以至在电梯没有对齐楼层或电梯门再次打开时进行。
本文的安全性需求分析方法除了生成文献[16]定义的2种基本HCA外，还生成了文献[1]所述的4种与时间因素相关的HCA。并且在HCA的生成过程中，通过危险检测和利用系统变量间横向关系进行剪枝处理，不但提高了方法效率，而且保证了所生成HCA和安全性需求的正确性。另外，方法中的矛盾检测处理保证了HCA和安全性需求的一致性。
4 实验分析本节用人工构建的系统功能场景控制特征时序图作为输入，通过与现有的分析方法进行对比，对本文控制结构和过程分析的有效性进行评估。另外，由于本文HCA和安全性需求一一对应，本节通过对本文安全性需求分析方法生成的文本形式的HCA与文献[16]方法得到的HCA进行对比，对本文方法的有效性进行评估。
4.1 实验场景介绍为了对基于场景控制特征的安全性需求分析方法进行检验，本文设计了安全性需求提取的原型工具AutoSR用于实验分析。
利用该原型工具，本文选择Train Door Controller(TDC)[16]、ITP[1]和Nuclear Power Plant(NPP)[16]系统实例作为实验对象，对本文方法进行评估验证。其中，TDC是用于火车门开启和关闭的控制系统，要求TDC在正常或紧急情况下都能控制车门动力系统进行车门打开或关闭操作，并能够通过传感器信息采集系统获取相关信息，用于车门控制；ITP是简化的管理飞机飞行高度并保证安全间隔的空中交通管理系统，要求飞机的ITP系统能够检测飞行空域内其他相关参考飞机的信息，判断能否变更飞行高度，并能够经由所在空域控制台向空中交通管理系统发送飞行高度变更请求，接收其相关指令；NPP是简化的核电站反应堆冷却系统，用于人工或通过各种自动控制系统对冷却系统的冷却液阀门进行开关控制，并用优先级管理模块对接收到的各种控制命令进行协调，对冷却液阀门进行控制。这3个实例系统/组件间的控制关系如图 8所示。图中：每个方框代表需求中涉及的系统/组件，连接线表示系统间的关系，每个控制关系对应需求中的一个表示控制功能的需求。
|
| 图 8 TDC、ITP和NPP控制关系 Fig. 8 Control relationship of TDC,ITP and NPP |
下面分3部分对本文安全性需求分析方法进行评估。首先，对原型工具生成的控制结构进行评估，分析验证本文控制结构模型的有效性；然后，通过与安全分析常用的过程分析模型对比，分析验证变量影响图的有效性；最后，验证本文基于控制结构和过程的安全性需求分析方法的有效性。
4.2 控制结构有效性验证与分析为了验证控制结构模型的有效性，本文分别对TDC、ITP和NPP进行控制特征时序图建模，用控制结构和过程分析模块提取控制结构模型，并将其与人工构建的对应(Hierarchical Control Structure，HCS) [20]模型进行对比分析。根据实验对象的需求与图 8，可以得到实验对象相关的控制信息，如表 3所示。
| 实例 | 系统数量 | 被控制系统数 | 系统控制层次 | 控制需求数量 |
| TDC | 3 | 1 | 2 | 1 |
| ITP | 6 | 5 | 4 | 5 |
| NPP | 6 | 5 | 4 | 8 |
假设模型满足所有控制需求，即每个控制需求都有控制环描述的控制过程与之对应。本文用CLM=∑CLij表示控制环的总数，评估模型描述控制关系和控制过程的能力；控制强度CC=CLM/控制需求数量，表示平均每条控制需求对应的控制环数量，评估模型满足控制需求的程度，由于控制的传递和分解会导致一条控制需求对应多个控制过程，CC可能大于1；控制密度CD=CLM/控制模型层次数，表示控制结构中平均每层的控制环数量，评估模型平均每个控制层次所含的控制信息量。所得的各项评估结果如表 4所示。
| 实例 | HCS模型 | 本文模型 | ||||
| CLMHCS | CCHCS | CDHCS | CLM | CC | CD | |
| TDC | 1 | 1 | 0.50 | 1 | 1.00 | 0.50 |
| ITP | 5 | 1 | 1.25 | 11 | 2.20 | 2.75 |
| NPP | 8 | 1 | 2.00 | 12 | 1.38 | 3.00 |
由表 4可知，HCS模型的CLM评估普遍小于本文模型，这是由于HCS模型只描述系统间的直接控制关系，而本文模型还包含由控制分解、传递形成的非直接控制关系，表明本文模型克服了HCS模型无法描述非直接控制关系的缺陷。本文模型CC值一般大于HCS模型，这是因为一条控制需求可能需要通过控制传递和分解而被多个控制过程实现，表明本文模型相对于HCS模型包含控制需求对应的更多控制信息。因为HCS形式化定义中每个控制层次只有一个控制/被控制系统，而本文模型的每个控制层次可以存在多个控制环，本文模型CD值不小于HCS模型，表明本文模型解决了HCS模型对ITP的一对多、NNP的多对多等复杂控制结构建模的局限性。总之，对于同一系统的控制需求，本文用控制环定义的控制结构描述了系统间的直接/非直接控制关系，相对于只描述直接控制关系的传统HCS模型，其对控制信息的描述更加完备；此外，本文模型通过描述控制环间关系并形成层次结构，不但方便了后文对系统变量间关系的分析，还使得对复杂控制结构的建模更加简洁，避免了HCS模型每层只要一个控制/被控制系统可能造成大量重复的情况。
4.3 变量影响图模型有效性验证与分析在生成系统控制结构之后，用控制结构和过程分析模块对控制环所对应的控制过程进行系统变量提取及其关系分析，并进行变量影响图建模，以便进行安全性分析。为了验证变量影响图的有效性，本文将每条控制需求作为一个系统目标，并且根据文献[1, 16]所示的TDC、ITP、NPP系统危险，对这3个系统实例的全局控制过程分别用基于objectives[21]、hazards[16]、场景的方法提取系统变量及其关系，并进行变量合并、层次化等处理，构建相应的被控制系统模型SED[21]、层次过程模型HPM[16]以及变量影响图VEG，所生成的3种过程模型情况如表 5所示。
| 实例 | 基于objectives的SED | 基于hazards的HPM | 基于场景VEG | |||
| SV数量 | 关系数量 | SV数量 | 关系数量 | SV数量 | 横向/纵向关系数量 | |
| TDC | 5 | 0 | 5 | 0 | 5 | 2/0 |
| ITP | 15 | 7 | 8 | 4 | 19 | 4/6 |
| NPP | 16 | 6 | 10 | 3 | 20 | 3/12 |
对于3种过程模型，分别用SVC和SVRC对其进行评估。
SVC=模型中SV数量/SVM，SVM=所有模型SV数量和-SV重复数，表示模型构造方法提取的系统变量数量在全部系统变量中的比例。
SVRC=2×模型中关系数量/[SVM(SVM-1)]，表示模型构造方法分析出的关系数量在所有可能关系中的比例。
评估结果如图 9所示。
|
| 图 9 SVC和SVRC评估结果 Fig. 9 Results of SVC and SVRC assessment |
由图 9(a)可知，对于3个实例，VEG的SVC评估优于或等于HPM和SED，表明VEG通过对场景进行分析提取系统变量的方法，解决了HPM和SED建模方法受限于系统hazards和objectives描述简单且数量较少的问题，可以得到相对比较完备的系统变量集合。
图 9(b)中，对于简单的TDC系统，所得系统变量属于同一层次，不存在组成关系或纵向关系，其HPM、SED模型的SVRC值为0，而VEG模型中由于包含了这些系统变量间的2个横向关系，所以其SVRC值为0.2；对于较复杂的ITP和NPP系统，VEG模型的横向关系和纵向关系之和大于其HPM模型和SED模型中的关系数，因此本文VEG模型的SVRC评估结果较优。由上可知，对于同一系统，本文的VEG模型所得的系统变量间关系较完备。
4.4 安全性需求分析方法有效性验证与分析根据控制结构和变量影响图等，安全性需求分析模块自动构建HCAT并生成HCA。由于在相同系统级别下，HCA和安全性需求一一对应，本文通过HCA对安全性需求提取方法进行验证。该节对TDC、ITP、NPP相同顶层控制过程的过程模型进行简化后，分别用文献[16]方法和本文方法生成HCA，并用生成的HCA数量、HCA错误数和HCA矛盾数作为指标，在安全性需求的生成能力和生成质量方面，验证本文安全性需求分析方法的有效性，用平均空间使用度ASD验证方法的效率，ASD=当前层次存储所需空间数/(HCA数量-HCA错误数)。实验结果如图 10和表 6所示。
|
| 图 10 ASD评估结果 Fig. 10 Results of ASD assessment |
从表 6可知，本文方法生成的HCA总数少于或等于文献[16]，但去除其中错误的HCA和不一致的HCA后，本文方法所得的有效HCA数大于或等于文献[16]方法。这表明本文的安全性需求分析方法得到的安全性需求比较完备。本文在分析过程中对矛盾和错误进行自动检测和处理的方法，不但解决了文献[16]方法将矛盾检测放在后期由人工处理的不足，而且使得HCA错误数为0，克服了文献[16]方法由于缺乏错误检测机制所造成的HCA可能存在错误的缺陷。另外，由于2种方法矛盾检测原理相同，并且3个实例中不存在功能性需求和危险间的矛盾，所以检测到的HCA矛盾相同。从图 10可知，本文方法的空间使用度随模型复杂度的增加，具有明显的优势，这是因为本文在安全性需求分析过程中，使用变量影响图中的横向关系做了优化和剪枝。对同一系统，相对于文献[16]方法，本文方法不但能用较少的存储资源生成相对较完备的安全性需求，而且通过矛盾和错误检测处理，保证了所生成的安全性需求的正确性和一致性。
5 结 论本文使用STAMP因果模型，对基于需求场景的控制特征进行安全性需求分析的方法进行了研究。结果表明：
1) 通过对系统场景的控制特征时序图进行分析，在一定程度上将基于STAMP的安全性分析从设计阶段提前到需求阶段，扩展了STAMP的应用范围。
2) 使用变量影响图模型自动构造HCAT，分析得到HCA和安全性需求，弥补了STPA方法缺乏危险性活动生成方法的缺陷。
3) 通过在安全性需求分析过程中进行矛盾和错误检测处理，保证了所得到的安全性需求的正确性和一致性，并通过剪枝优化，提高了方法的分析效率。
| [1] | FLEMING C H, SPENCER M, THOMAS J, et al. Safety assurance in NextGen and complex transportation systems[J]. Safety Science, 2013, 55 : 173 –187. DOI:10.1016/j.ssci.2012.12.005 |
| [2] | LEVESON N G. Engineering a safer world:Systems thinking applied to safety[M]. Boston, Massachusetts: MIT Press, 2012 : 212 -227. |
| [3] | BLACK J,KOOPMAN P.Indirect control path analysis and goal coverage strategies for elaborating system safety goals in composite systems[C]//Proceedings of the 2008 14th IEEE Pacific Rim International Symposium on Dependable Computing.Piscataway,NJ:IEEE Press,2008:184-191. |
| [4] | SUPAKKUL S,CHUNG L.Applying a goal-oriented method for hazard analysis:A case study[C]//Proceedings of the 4th International Conference on Software Engineering Research,Management and Applications.Piscataway,NJ:IEEE Press,2006:22-30. |
| [5] | FIRESMITH D.Engineering safety-related requirements for software-intensive systems[C]//Proceedings of the 27th International Conference on Software Engineering.Piscataway,NJ:IEEE Press,2005:720-721. |
| [6] | FIRESMITH D. Engineering safety requirements, safety constraints, and safety-critical requirements[J]. Journal of Object Technology, 2004, 3 (3) : 27 –42. DOI:10.5381/jot.2004.3.3.c3 |
| [7] | CHUNG L,SUPAKKUL S.Capturing and reusing functional and non-functional requirements knowledge:A goal-object pattern approach[C]//2006 IEEE International Conference on Information Reuse and Integration.Piscataway,NJ:IEEE Press,2006:539-544. |
| [8] | FIRESMITH D.A taxonomy of safety-related requirements[C]//2004 Proceedings of the Workshop on Requirements for High Assurance Systems (RHAS'04).Piscataway,NJ:IEEE Press,2004:11. |
| [9] | CHANG W,BAO X,LI X.A study on airborne software safety requirements patterns[C]//2013 IEEE 7th International Conference on Software Security and Reliability.Piscataway,NJ:IEEE Press,2013:131-136. |
| [10] | CHEN Z,MOTET G.System safety requirements as control structures[C]//2009 33rd Annual IEEE International Computer Software and Applications Conference.Piscataway,NJ:IEEE Press,2009:324-331. |
| [11] | YANG C.Software safety testing based on STPA[C]//3rd International Symposium on Aircraft Airworthiness (ISAA).Amsterdam:Elsevier,2014,80:399-406. http://cn.bing.com/academic/profile?id=1968817134&encoded=0&v=paper_preview&mkt=zh-cn |
| [12] | ALLENBY K,KELLY T.Deriving safety requirements using scenarios[C]//5th IEEE International Symposium on Requirements Engineering.Piscataway,NJ:IEEE Press,2001:228-235. |
| [13] | VYAS P,MITTAL R K.Eliciting additional safety requirements from use cases using SFTA[C]//2012 1st International Conference on Recent Advances in Information Technology.Piscataway,NJ:IEEE Press,2012:163-169. |
| [14] | GUILLERM R,DEMMOU H,SADOU N.A safety requirement engineering method and tool[C]//2013 21st IEEE International Conference on Requirements Engineering.Piscataway,NJ:IEEE Press,2013:328-329. |
| [15] | MENON C,KELLY T.Eliciting software safety requirements in complex systems[C]//2010 4th Annual IEEE Systems Conference.Piscataway,NJ:IEEE Press,2010:616-621. |
| [16] | THOMAS J P.Extending and automating a systems-theoretic hazard analysis for requirements generation and analysis[D].Boston,Massachusetts:MIT,2013:71-87. |
| [17] | ASHBY W R. An introduction to cybernetics[M]. London: Chapman & Hall, 1957 : 202 -216. |
| [18] | CHECKLAND P. Systems thinking, systems practice[M]. New York: John Wiley & Sons, 1981 : 271 -284. |
| [19] | VANHATALO J,VÖLZER H,LEYMANN F.Faster and more focused control-flow analysis for business process models through SESE decomposition[C]//5th International Conference on Service-Oriented Computing(ICSOC 2007).Berlin:Springer,2007,4749:43-55. |
| [20] | FLEMING C H.Safety-driven early concept analysis and development[D].Boston，Massachusetts：MIT,2015:53-92. |
| [21] | INGHAM M D, RASMUSSEN R D, BENNETT M B, et al. Generating requirements for complex embedded systems using state analysis[J]. Acta Astronautica, 2006, 58 (12) : 648 –661. DOI:10.1016/j.actaastro.2006.01.005 |
| [22] | LEVESON N G. A systems-theoretic approach to safety in software-intensive systems[J]. IEEE Transactions on Dependable and Secure Computing, 2004, 1 (1) : 66 –86. DOI:10.1109/TDSC.2004.1 |
| [23] | ABDULKHALEQ A,WAGNER S.A-STPA:An open tool support for system-theoretic process analysis[C]//2014 STAMP Conference.Boston,Massachusetts:MIT Press,2014. |