CN114077782A - 一种准确识别损失场景的stpa方法和装置 - Google Patents

一种准确识别损失场景的stpa方法和装置 Download PDF

Info

Publication number
CN114077782A
CN114077782A CN202010828296.1A CN202010828296A CN114077782A CN 114077782 A CN114077782 A CN 114077782A CN 202010828296 A CN202010828296 A CN 202010828296A CN 114077782 A CN114077782 A CN 114077782A
Authority
CN
China
Prior art keywords
state machine
model
control action
unsafe
loss
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010828296.1A
Other languages
English (en)
Other versions
CN114077782B (zh
Inventor
钟德明
孙睿
郭锐
宫浩原
查云
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beihang University
Original Assignee
Beihang University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beihang University filed Critical Beihang University
Priority to CN202010828296.1A priority Critical patent/CN114077782B/zh
Priority claimed from CN202010828296.1A external-priority patent/CN114077782B/zh
Priority to PCT/CN2021/111488 priority patent/WO2022037430A1/zh
Priority to US18/021,598 priority patent/US20230305550A1/en
Publication of CN114077782A publication Critical patent/CN114077782A/zh
Application granted granted Critical
Publication of CN114077782B publication Critical patent/CN114077782B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0224—Process history based detection method, e.g. whereby history implies the availability of large amounts of data
    • G05B23/0227—Qualitative history assessment, whereby the type of data acted upon, e.g. waveforms, images or patterns, is not relevant, e.g. rule based assessment; if-then decisions
    • G05B23/0235—Qualitative history assessment, whereby the type of data acted upon, e.g. waveforms, images or patterns, is not relevant, e.g. rule based assessment; if-then decisions based on a comparison with predetermined threshold or range, e.g. "classical methods", carried out during normal operation; threshold adaptation or choice; when or how to compare with the threshold
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0259—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterized by the response to fault detection
    • G05B23/0275—Fault isolation and identification, e.g. classify fault; estimate cause or root of failure
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/24—Pc safety
    • G05B2219/24065—Real time diagnostics

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

本发明提供了一种准确识别损失场景的STPA方法和装置。该方法包括：确定分析目标，包括确定损失；利用有限状态机生成系统状态机；利用确定的损失和生成的系统状态机，识别不安全控制动作；利用模型检测技术和识别的不安全控制动作识别损失场景。根据本发明的方法利用状态机和模型检测技术，实现了对复杂系统的损失场景的准确且高效的识别。

Description

一种准确识别损失场景的STPA方法和装置
技术领域
本发明涉及系统安全分析领域，特别涉及一种准确识别系统损失场景的STPA方法和装置。本发明特别适合于例如交通、航空、航天、核电等复杂工程系统的安全性分析。
背景技术
对于系统进行准确高效的安全分析，一直是工程系统安全分析业界研究的方向。尤其随着大系统以及复杂系统例如交通、运输、海洋运输、航空航天等领域的快速发展，对于这一类复杂大系统进行高效准确的安全分析和诊断，就成为迫切需要研究和解决的课题。
过去常规的安全理论认为，系统的物理失效才是系统安全性的指标，物理失效即事故是由直接相关的一连串事件造成的，可通过分析导致损失的事件链来弄清事故和评估风险。因此之前的研究方法和关注重点多为传递事件链，如果组件或系统没有故障，事故就不会发生，安全性则随着系统或组件可靠性的提高而增强。因此，基于事件链的概率风险分析是本发明之前评估和表达安全与风险信息的常规和最佳途径。
但是，随着系统越来越复杂，人们对于之前理论的怀疑越来越强烈。尤其是在2004年，麻省理工学院的Nancy G.Leveson教授提出了“系统理论事故模型与过程”(STAMP：System-Theoretic Accident Model and Processes)，该理论认为系统的安全性是系统的涌现特性，即系统结构和系统环境以及它们之间关联关系，决定了系统的整体性和功能。根据此理论，系统整体性与功能是内部系统结构与外部系统环境综合集成的结果，也就是复杂性研究中所说的涌现(Emergence)。涌现过程是新的功能和结构产生的过程，是新质产生的过程，而这一过程是系统结构和系统环境以及它们之间相互作用的产物。涌现来源于系统理论中“整体大于部分之和”的思想。涌现属性是系统部件交互作用中呈现出来的属性。而对这种涌现特性的控制方法就是对系统的部件行为和部件交互进行约束，即认为系统的安全状态是通过对部件行为和部件间的交互施加安全约束而得到保持或加强。与传统事故致因模型认为事故由部件失效导致不同，STAMP理论认为事故是由不恰当的控制导致。在此基础上，基于STAMP理论的危险分析方法，Leveson教授又提出了系统理论过程分析(STPA：System-Theoretic Process Analysis)。目前，一些关于STPA的标准正在制定，例如：美国机动车工程师学会(SAE：Society of Automotive Engineers)正在制定《SAE AIR6913-Using STPA during Development and Safety Assessment of Civil Aircraft》、《SAEJ3187-Applying System Theoretic Process Analysis(STPA)to AutomotiveApplications》；中国也正在制定国家标准《系统理论过程分析(STPA)方法》。
2018年3月，Nancy G.Leveson和John P Thomas发布了《STPA Handbook》，这是当前国际STPA标准制定、工业应用、学术研究、方法改进参照的主要文件。在《STPA Handbook》中的STPA，主要包括四步工作步骤，分别是：
第一步：确定分析目标
包括的工作内容有：确定损失(Identify losses)、确定系统级危险(Identifysystem-level hazards)、确定系统级安全约束(Identify system-level safetyconstraints)，以及精化危险(Refine hazards)。
第二步：构建层级化控制结构模型
构建的层级化控制结构模型，包括控制器、被控过程、控制动作、反馈以及其他部件之间的输入输出。其中控制器包括控制算法和过程模型。
第三步：利用控制结构模型识别不安全控制动作(To identify Unsafe ControlActions)
不安全控制动作(UCA：Unsafe Control Action)是在特定上下文和最坏环境下会导致某个危险的控制动作。不安全控制动作是来源(Source)、UCA类型(Type)、控制动作(CA：Control Action)、上下文(Context)、关联危险(Link to Hazards)的组合。来源是提供控制动作的控制器。Type是UCA的类型，包括提供、未提供、过早或过晚、停止太早或持续太久共四类。控制动作指控制器发出的控制动作。关联危险指该UCA可能导致的危险(或子危险)。
在UCA识别过程中，首先生成来源(Source)、UCA类型(Type)、控制动作(CA)和上下文(Context)的组合，然后判断该组合是否导致已识别的危险，或者是否为一个新危险。
第四步：识别损失场景(To identify loss scenarios)
损失场景描述了能够导致UCA和危险的致因因素。
在此考虑两类致因场景:a)为何会出现不安全控制行为？b)控制行为为何会出现执行不利、未执行的情况而导致危险？
第一类场景，考虑控制器物理失效、不充分的控制算法、不充分的控制输入、不充分的过程模型等因素相关的损失场景；
第二类场景，考虑与反馈或信息未收到、收到不充分的反馈信息等因素相关的损失场景。
STPA方法特别适合于针对复杂的工程系统的安全性分析。目前，STPA方法已经在交通、航天、航空、核电等复杂的工程系统中得到广泛应用。
然而，现有的STPA方法也存在突出的问题，主要体现在以下方面：
1、采用自定义方法构建层级化系统控制结构模型
这种方法虽然建模方式很简单，但是不利于将STPA分析工作与已有系统工程相结合。在工业界，系统主要使用SysML、AADL、AltaRica等语言构建模型。如果按照《STPAHandbook》的要求构建模型，意味着需要重新构建系统模型，这不仅将增加工作负担，更重要的是，重构系统模型可能带来语义变化，导致影响STPA分析的可靠性。
另外，《STPA Handbook》提供的建模方法，只反映了部件之间的静态输入和输出关系，对部件之间的动态行为缺乏描述，因此不具备支撑在系统的动态涌现行为中识别损失场景的能力。
2、损失场景识别存在问题
A.采用人工方式识别损失场景。
STAMP认为危险是一种涌现特性，是系统部件相互作用出现的状态。而《STPAHandbook》中的STPA方法，在损失场景识别时采用人工分析的方式识别损失场景。当系统规模大、交互行为多时，很难通过人工方式识别损失场景。
B.在局部部件中寻找和识别损失场景
根据《STPA Handbook》中的STPA方法，损失场景识别被分成两种类型。第一种类型主要考虑控制器和传感器如何形成损失场景，第二种类型主要考虑作动器和被控过程如何形成损失场景。两种类型的损失场景识别均是在局部部件的交互中识别损失场景。但是这与该方法所依据的STAMP理论相矛盾。STAMP理论认为危险是系统部件交互涌现的结果，而《STPA Handbook》中的STPA方法在损失场景识别时割裂了系统部件之间的联系。这使得一些涉及系统全部部件交互的危险场景难以被识别。
3、场景识别中所使用的UCA概念错乱
A.将UCA当作控制器的输出
一方面，《STPA Handbook》承认UCA是一种危险，即一种系统状态。STPA认为UCA是以下元素的组合：来源(Source)、UCA类型(Type)、控制动作(CA：Control Action)、上下文(Context)。根据这个定义，UCA并不存在于控制器的输出端。但是，《STPA Handbook》在进行第一种类别的场景识别时，却认为UCA是控制器的输出(参见《STPA Handbook》图2.18)。这样会导致分析过程的不准确。
B.CA定义错误
根据《STPA Handbook》，其将这里的CA定义为控制器发出的CA。UCA是系统危险，而危险是跟被控过程直接关联的，因此UCA所包含的CA应当指被控过程接收到的控制动作，而不是控制器发出的CA。只有直接作用在被控过程上的CA-PR才更有助于清晰地判断被控过程是否进入危险。
在识别UCA时，由于层级化控制结构中不包括作动器和传感器，被控过程接收到的CA-PR也即控制器发出的CA，因此此时《STPA Handbook》错误定义CA的问题并未暴露。
但是，当按照《STPA Handbook》开展STPA损失场景识别工作时，由于所使用的层级化控制结构添加了作动器和传感器，由于作动器对信号传输可能带来改变或延迟，因此此时控制器输出的CA并不是被控过程接受的CA-PR。控制器发出的CA和被控过程接收到的CA-PR分别是作动器的输入和输出。由于作动器本身的作用，可能使得两者出现差异。
损失场景识别工作要求识别UCA的发生场景，这时的UCA的组成元素应当是被控过程接收到的控制动作，而不是控制器发出的CA。《STPA Handbook》中的STPA方法，在识别损失场景工作时，错将控制器输出的CA当做UCA组成元素，导致了其UCA场景识别工作混乱。
基于以上原因，采用传统的STPA方法进行的系统安全分析，存在损失场景识别分析不准确、效率低甚至错误识别的问题。
发明内容
有鉴于此，本发明旨在解决上述问题，并提供了一种准确识别损失场景的STPA方法和装置。
根据本发明的一种准确识别损失场景的STPA方法包括：
确定分析目标，包括确定损失；
利用状态机构建系统控制结构，生成系统状态机；
利用确定的损失和生成的系统状态机，识别不安全控制动作；
利用模型检测技术以及识别出的不安全控制动作识别损失场景。
根据一优选实施例，所述系统状态机包括控制器状态机、被控过程状态机，以及控制器状态机和被控过程状态机之间的交互关系。
根据一优选实施例，所述系统状态机包括识别不安全控制动作所需要的控制器全部行为、被控过程全部行为，以及控制器和被控过程之间的全部交互行为。
根据一优选实施例，所述不安全控制动作是控制动作、类型以及上下文之间的组合。
根据一优选实施例，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，时间无关不安全控制动作的类型包括：不提供控制动作和提供控制动作；时间相关不安全控制动作的类型包括：过早、过晚或以错误顺序提供控制动作、控制动作持续太长或结束太快。
根据一优选实施例，所述控制动作是被控过程接收到的控制动作，所述不安全控制动作是系统级危险。
根据一优选实施例，利用确定的损失和生成的系统状态机，识别不安全控制动作包括：
利用所述系统状态机，确定控制动作和上下文；
根据所述控制动作和上下文，确定控制动作、上下文和类型之间的组合的实例；
根据所述实例识别所述不安全控制动作。
根据一优选实施例，利用模型检测技术以及识别出的不安全控制动作识别损失场景包括:
更新所述系统状态机，经更新的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系；
利用所述经更新的系统状态机，生成模型检测模型；
利用所述不安全控制动作和模型检测模型识别损失场景。
根据一优选实施例，所述经更新的系统状态机包括识别损失场景所需要的控制器全部行为、被控过程全部行为、传感器全部行为、作动器全部行为，以及控制器、被控过程、传感器和作动器之间的全部交互行为。
根据一优选实施例，所述系统状态机是使用SysML、AADL或AltaRica构建的，所述模型检测模型是使用NuSMV或UPPALL构建的。
根据一优选实施例，所述系统状态机包括时间信息。
根据一优选实施例，所述时间信息是通过MARTE元素描述的。
根据一优选实施例，所述模型检测模型是使用NuSMV构建的，其中通过时钟变量描述时间信息。
根据一优选实施例，利用所述不安全控制动作和模型检测模型识别损失场景包括：
根据所述不安全控制动作，确定系统的安全性约束；
利用模型检测逻辑语言对所述系统安全性约束进行描述，形成待检验性质；
利用模型检测模型对所述待检测性质进行模型检测，识别损失场景。
根据一优选实施例，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，所述时间相关不安全控制动作包含过早、过晚、错误顺序、持续太长、或结束太快的时间信息，所述时间信息由所述模型检测模型中的时钟变量表达。
根据一优选实施例，所述待检验性质使用逻辑语言TCLT、CTL、LTL或RTCTL描述。
本发明还提供了一种准确识别损失场景的STPA装置，包括：
分析目标确定单元，用于确定目标，包括确定损失；
状态机生成单元，用于利用状态机构建系统控制结构，生成系统状态机；
不安全动作识别单元，用于利用确定的损失和生成的系统状态机，识别不安全控制动作；
损失场景识别单元，用于利用模型检测技术和识别出的不安全控制动作识别损失场景。
根据一优选实施例，所述系统状态机包括控制器状态机、被控过程状态机，以及控制器状态机和被控过程状态机之间的交互关系。
根据一优选实施例，所述系统状态机包括识别不安全控制动作所需要的控制器全部行为、被控过程全部行为，以及控制器和被控过程之间的全部交互行为。
根据一优选实施例，所述不安全控制动作是控制动作、类型以及上下文之间的组合。
根据一优选实施例，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，时间无关不安全控制动作的类型包括：不提供控制动作和提供控制动作；时间相关不安全控制动作的类型包括：过早、过晚或以错误顺序提供控制动作、控制动作持续太长或结束太快。
根据一优选实施例，所述控制动作是被控过程接收到的控制动作，所述不安全控制动作是系统级危险。
根据一优选实施例，所述不安全控制动作识别单元具体用于：
利用所述系统状态机，确定控制动作和上下文；
根据所述控制动作和上下文，确定控制动作、上下文和类型之间的组合的实例；
根据所述实例识别所述不安全控制动作。
根据一优选实施例，所述损失场景识别单元具体用于:
更新所述系统状态机，经更新的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系；
利用所述经更新的系统状态机，生成模型检测模型；
利用所述不安全控制动作和模型检测模型识别损失场景。
根据一优选实施例，所述经更新的系统状态机包括识别损失场景所需要的控制器全部行为、被控过程全部行为、传感器全部行为、作动器全部行为，以及控制器、被控过程、传感器和作动器之间的全部交互行为。
根据一优选实施例，所述系统状态机是使用SysML、AADL或AltaRica构建的，所述模型检测模型是使用NuSMV或UPPALL构建的。
根据一优选实施例，所述系统状态机包括时间信息。
根据一优选实施例，所述时间信息是通过MARTE元素描述的。
根据一优选实施例，所述模型检测模型是使用NuSMV构建的，其中通过时钟变量描述时间信息。
根据一优选实施例，利用所述不安全控制动作和模型检测模型识别损失场景包括：
根据所述不安全控制动作，确定系统的安全性约束；
利用模型检测逻辑语言对所述系统安全性约束进行描述，形成待检验性质；
利用模型检测模型对所述待检测性质进行模型检测，识别损失场景。
根据一优选实施例，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，所述时间相关不安全控制动作包含过早、过晚、错误顺序、持续太长、或结束太快的时间信息，所述时间信息由所述模型检测模型中的时钟变量表达。
根据一优选实施例，所述待检验性质使用逻辑语言TCLT、CTL、LTL或RTCTL描述。
本发明还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行上述的方法。
根据本发明的技术方案，由于采用状态机建模，使用更简单，而且可以复用已有系统模型；由于使用了模型检测技术，可以自动化识别损失场景；由于在控制器、被控过程、传感器、作动器完整的交互行为中考虑了涌现危险场景，使得分析更充分；另外，由于UCA的定义使用了被控过程实际接受的控制动作，结合状态机和模型检测技术的使用，可以使得STPA的架构更清晰。因此，本发明的技术方案能够实现对复杂系统的损失场景的准确且高效的识别，增强了识别的准确度，同时提高了损失场景的识别效率。
附图说明
图1为根据本发明实施例的损失场景识别方法的流程图；
图2为列车车门控制示例中的系统状态机图；
图3为列车车门控制示例中的列车员状态机图；
图4为列车车门控制示例中的列车门控制器状态机图；
图5为列车车门控制示例中的列车门状态机；
图6为列车车门控制示例中的障碍物状态机图；
图7为列车车门控制示例中的补充传感器作动器后的系统状态机图；
图8为列车车门控制示例中的补充传感器作动器后的列车门控制器状态机图；
图9为列车车门控制示例中的补充传感器作动器后的列车门状态机图；
图10为列车车门控制示例中的列车门作动器状态机图；
图11为列车车门控制示例中的列车门传感器状态机图；
图12为列车车门控制示例中的障碍物传感器状态机图；
图13为列车车门控制示例中的列车门控制器UPPAAL Template；
图14为列车车门控制示例中的列车门作动器UPPAAL Template；
图15为列车车门控制示例中的列车门UPPAAL Template及其函数；
图16为列车车门控制示例中的列车门传感器UPPAAL Template；
图17为列车车门控制示例中的列车员UPPAAL Template；
图18为列车车门控制示例中的障碍物UPPAAL Template及其函数；
图19为列车车门控制示例中的障碍物传感器UPPAAL Template；
图20为列车车门控制示例中的注入延迟后障碍物传感器状态机图；
图21为列车车门控制示例中的注入延迟后列车门作动器状态机图；
图22为列车车门控制示例中的注入延迟后列车门作动器UPPAAL模型；
图23为列车车门控制示例中的注入延迟后障碍物传感器UPPAAL模型；
图24为列车车门控制示例中的SpecH1反例路径图；
图25为列车车门控制示例中的SpecH2反例路径图。
具体实施方式
为了使本发明的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明进行详细描述。
以下结合图1详细描述根据本发明实施例的损失场景识别方法。
根据本发明实施例的损失场景识别方法包括四个大步骤。
第一步：确定分析目标
与现有技术中的STPA方法的第一步类似，本发明实施例中的第一步主要确定分析目标，包括确定损失(Identify losses)。根据优选的实施例，确定分析目标还可以包括确定系统级危险(Identify system-level hazards)、确定系统级安全约束(Identifysystem-level safety constraints)以及确定精化危险(Refine hazards)。
第一步中至少需要确定出损失。通过确定出的损失，可以在后续步骤中识别出不安全控制动作。损失涉及对相关参与方具有价值的东西。损失可能包括失去生命或人身伤害、财产损失、环境污染、任务失败、敏感信息丢失或泄露或利益相关者无法接受的其他损失。
在第一步中，还可以确定系统级危险、系统级安全约束以及精化危险等目标，以便减少后续步骤的工作量。
在本发明中，系统是指共同作用以实现共同目标的一组部件。一个系统可能包括多个子系统，也可能是更大系统的组成部分。危险是指在特定最坏环境条件下，将导致损失的一种系统状态或一组条件。系统级安全性约束规定了预防危险(最终预防损失)需要满足的系统条件或行为。《STPA Handbook》第17页和第20页分别对系统级危险和系统级安全性约束进行了具体的解释。
精化危险是指将系统级危险细化成若干个子危险。例如：“飞机与地面其他物体距离过近”，该危险的一个子危险是：“飞机滑行期间加速过大”。《STPA Handbook》第21页对精化危险进行了具体解释。
第二步：构建系统状态机
本发明的一个改进是使用系统状态机替代常规STPA方法中的层级化控制结构模型。在第二步中，利用有限状态机构建系统状态机。
层级化控制结构模型在2018年麻省理工学院Nancy Leveson和John Thomas公开的《STPA Handbook》中被描述和采用。层级化控制结构是由反馈控制回路组成的系统模型。一个有效的控制结构将对整个系统的行为施加约束。控制结构包括控制器、控制动作、反馈、控制动作、被控过程以及其他件的输入和输出。在进行损失场景识别时，通常还会在层次化控制结构中添加作动器和传感器。控制器提供控制动作以控制过程，并且对被控过程的行为施加约束。控制器包括控制算法和过程模型。控制算法表示控制器的决策过程，它决定了要提供的控制动作。过程模型是控制器对被控制过程以及其他系统或环境相关方面的认知，该认知用于控制器做决策。反馈用于观察被控过程。实现控制器对被控过程施加作用的装置称为作动器(也可称为“执行器”)。帮助控制器从被控过程感知反馈的装置被称为传感器。
层级化控制结构中“层级化”的含义指：系统可能具有多个层级的控制器，高层级控制器可以向低层级控制器和被控过程发送控制动作，低层级控制器和被控过程向高层级控制器提供反馈。每个层级的控制器在控制低层级控制器和被控过程的同时，接受高层级控制器的控制。
虽然层级化控制结构模型建模简单，但是如上所述，其只反映了部件之间的静态输入和输出关系，对部件之间的动态行为缺乏描述，因此STPA方法虽然意识到动态涌现行为的重要性，但是所采用的层级化控制结构模型由于上述缺陷，因此不具备支撑在系统的动态涌现行为中准确识别损失场景的能力。
作为一种创造性的改进，本发明利用有限状态机表达系统层级化控制结构所提供的信息。有限状态机是表示有限个状态及状态间迁移的数学模型，它包括状态、迁移、迁移条件等元素。迁移是指从一个状态转移到下一个状态的行为。迁移之前的状态可以被称为当前状态，迁移之后的状态可以被称为目标状态。迁移条件是迁移的依据，可能包括时间条件、状态条件、同步条件等。根据需要，可以在有限状态机中添加附加元素，例如，在SysML状态机图中可以添加Effect，在UPPAAL构建的状态机中可以添加Clock和Update。
有限状态机是工业界常用的建模技术，易于使用。另外，采用SysML、AADL以及AltaRica等语言构建系统状态机，有助于STPA分析工作与已有系统工程工作融合，有利于使用已有系统工程的成果，减少STPA建模所需要的时间，同时也可以减少重构模型带来的语义变化，从而影响分析质量。
本发明的系统状态机不仅能提供控制结构模型所能提供的全部信息，而且可以详细地描述系统或部件的交互行为。状态机不仅可以描述系统的高层行为，也可以描述部件内的细节行为。因此，状态机可以描述系统完整的行为信息，控制器、被控过程、传感器、作动器都可以使用状态机描述。
本发明的用于识别不安全控制动作(UCA：Unsafe Control Action)的系统状态机可以只包括控制器状态机、被控过程状态机以及它们之间的交互关系。根据本发明，UCA识别所需要的控制器行为、被控过程行为以及它们之间的交互关系全部使用状态机建模。
本发明的用于识别损失场景的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系。根据本发明，损失场景识别所需要的控制器行为、被控过程行为、传感器行为、作动器行为以及它们之间的交互关系全部使用状态机建模。用于识别损失场景的系统状态用于识别损失场景的系统状态与用于识别不安全控制动作的系统状态机相比，增加了新的内容，因此可以是通过更新用于识别不安全控制动作的系统状态机而获得的。
在本发明中，系统或部件的输入与输出、系统状态的定义及改变、系统控制动作和反馈、环境因素和干扰，都可包含在系统状态机中。UCA识别和损失场景识别所需要的过程模型信息和控制算法信息，都通过控制器状态机表达。
在本发明中，可以使用多种语言构建系统状态机，例如SysML、AADL、AltaRica、甚至可以是模型检测(Model Checking)技术提供的建模语言。以下使用SysML语言为例举例说明构建系统状态机的建模过程，此时系统状态机即SysML系统状态机图。
1.为系统建立SysML系统状态机图。在SysML系统状态机图的“General”属性中定义全局变量及其初始值。在SysML系统状态机图中添加State Machine元素，为控制器、被控过程、传感器、作动器构建状态机。
2.State Machine元素的建模方法如下：
2.1在State Machine元素的“General”属性中定义局部变量及其初始值，在StateMachine元素中添加所需的Initial元素、State元素和Transition元素；
2.2由Initial元素指向State Machine元素的初始状态；
2.3状态不变量由State元素的“Invariant”约束属性表示，状态不变量通过布尔式表达，表示满足状态不变量时方可迁入该状态，不满足状态不变量时需要迁出该状态；
2.4状态的迁移过程由Transition元素表示，Transition元素为有向元素，必须从起始状态指向目标状态；使用Transition元素的“Guard”属性表示迁移条件，使用Transition元素的“Effect”属性表示更新；
2.5如果系统中存在同步，那么使用Synch元素描述同步信息，具体方法如下：
1)添加Synch元素指向需要同步的Transition元素；
2)确定Synch元素的标识符，相同的标识符表示同步的Transition元素；
2.6如果State Machine元素需要包括下一级State Machine元素，即状态机嵌套，则在该State Machine元素中添加下一级State Machine元素，并按照第2.1、2.2、2.3、2.4、2.5步所述对下一级State Machine元素建模；根据需要，在下一级State Machine元素中还可以继续添加State Machine元素；3.如果SysML系统状态机图需要描述时间信息，那么使用MARTE(Modeling and Analysis of Real Time and Embedded Systems)元素描述时间信息，具体方法如下：
1)在SysML系统状态机图中添加Clock元素表示全局时钟；
2)在存在时间信息的State Machine元素中添加Clock元素表示局部时钟；
3)如果State元素中存在时间相关状态不变量，那么在State元素的“Invariant”约束属性中添加“TimedConstraint”元素表达状态不变量；
4)如果Transition元素中存在时间更新，那么在Transition元素的“Effect”属性中添加“ClockConstraint”元素表达时间更新；
5)如果Transition元素中存在时间约束，那么在Transition元素的“Guard”属性中添加“TimedConstraint”元素表达时间约束。
第三步：识别不安全控制动作
在第三步中，利用第一步确定的损失以及第二步生成的系统状态机，可以识别不安全控制动作。以下将具体介绍第三步中执行的操作。
1、不安全控制动作(UCA)是指控制动作(CA-PR：Control Action-ProcessReceived)、UCA的类型(Type)、上下文(Context)之间的组合{CA-PR、Type、Context}，并且这个组合能够导致某个系统级危险。该危险可能是已识别的系统级危险，也可能是通过当前第三步即将确认的新危险。
与《STPA Handbook》相比，本发明中对UCA的定义进行了改进，将UCA定义为一项危险，是3项元素的组合，这3项元素是：被控过程接收到的控制动作(CA-PR)、UCA的类型(Type)、上下文(Context)。
每个CA-PR的属性包括该CA-PR的发出者、接收者以及其他数据定义。CA-PR处于被控过程的输入位置。当系统状态机中不包括作动器时，CA-PR同时也处于控制器的输出位置。当系统状态机中包括作动器时，CA-PR同时处于作动器的输出位置。
UCA一共有四种“类型”(Type)，如下所示，UCA Type1和UCA Type2是时间无关“类型”，UCA Type3和UCA Type4是时间相关“类型”。包含时间无关“类型”的UCA被称为时间无关UCA，包含时间相关“类型”的UCA被称为时间相关UCA。
1)UCA Type1：不提供控制动作导致危险(Not providing the control actionleads to a hazard)
2)UCA Type2：提供控制动作导致危险(Providing the control action leadsto a hazard)
3)UCA Type3：提供了一个控制动作，但是提供得过早、过晚或错误顺序(Providing a control action too early,too late,or in the wrong order)
4)UCA Type4：控制动作持续太长或结束太快(The control action lasts toolong or is stopped too soon)(适用于连续控制动作，而不是离散控制动作)
Context是UCA所处的系统和环境状态，被定义为上下文状态变量CVari的组合{CVar1,CVar2,…,CVari，…,CVarn}。CVari可能是：环境条件、被控过程状态、控制器状态、之前的控制动作以及参数等。
UCA是系统级危险。UCA有时也被称为不想要的控制动作(Unwanted ControlAction)、不期望的控制动作(Unexpected Control Actions)、危险控制动作(HazardousControl Action)等。
2、根据SysML系统状态机确定Context的上下文变量CVari及其可能的取值，列出Context全部实例。
3、通过遍历，给出{CA-PR、Type、Context}的所有实例。每个{CA-PR、Type、Context}的实例都被认为是一个潜在不安全控制动作(PUCA：Potential UCA)。包含时间无关“类型”(Type)的PUCA被称为时间无关PUCA，包含时间相关“类型”(Type)的PUCA被称为时间相关PUCA。
4、根据确定的损失，逐一分析每一个PUCA，确定其是否为UCA。
对于时间无关PUCA，可直接根据{CA-PR、Type、Context}确定PUCA是否为UCA。
对于时间相关UCA，需要对时间相关“类型”(Type)进行实例化，也即确定“太早”、“太晚”、“太长”、“太快”等词的具体含义，更准确地描述时间特性，然后确定PUCA是否为UCA。
当一个PUCA确定为UCA时，该UCA将是以下两种情况中的一种。
第一种情况：UCA包含于已识别的系统级危险。此时，则不需要更新已识别的系统级危险；
第二种情况：UCA不包含于已识别的系统级危险，那么可以判断该UCA为新的系统级危险。此时，需要对该UCA进行标识，并纳入已识别的系统级危险当中。
第四步：识别损失场景
在第四步中，利用第三步识别的不安全控制动作和模型检测技术识别损失场景。
模型检测是一种自动验证技术，构成要素包括待检测模型、待检验性质和模型检测算法。模型检测的优点是能够证明待检测模型是否满足待检测性质，如果不能满足，还能通过“反例”展示待检测模型如何运行以致违反待检测性质。反例是待检测模型一条运行状态轨迹，表明了待检测模型如何从初始状态演变成违反待检测性质时的状态。在本发明中，使用反例识别损失场景。待检测性质有时也称为待检测规约、待检测约束或待检测属性。在本发明中，将系统安全性约束列为待检测性质。通常，模型检测通过有限状态迁移图描述待检测模型，通过形式逻辑描述待检验性质。根据本发明，通过模型检测技术对状态机进行形式化分析，将系统状态机转换成模型检测模型，可以准确且自动高效地地识别损失场景。
以下详细介绍第四步执行的操作。
1、更新系统状态机
经更新的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系，也包括控制器、被控过程、传感器、作动器内部部件的状态机以及子部件之间的交互关系。
当存在下述三种情况中的一种时，经更新的系统状态机需要构建时间特性。
1)需要识别时间相关UCA的损失场景；
2)后续注入的致因因素(CF：Causal Factors)包括时间特性；
3)系统本身包括时间特性。
可以使用多种语言构建系统状态机，例如SysML、AADL、AltaRica、模型检测技术提供的建模语言等。本发明优选推荐使用SysML和AADL构建系统状态机，原因是这两者均是工业标准，都支持状态机嵌套和时间特性建模。
使用SysML构建系统状态机的方法请参见上述第二步的第1、2、3步，其中第二步的第3步描述了时间特性的建模方法。
2、根据经更新的系统状态机形成模型检测模型
UPPAAL是目前应用广泛的实时系统模型检测工具，它通过建立时间状态机模型，利用模型检测方法验证实时系统的性质。这里形成的UPPAAL模型可以直接通过UPPAAL进行模型检测。以下根据SysML系统状态机说明UPPAAL模型的形成方法：
2.1将SysML状态机图中的所有变量及其初始值转换为UPPAAL模型中的系统声明；
2.2如果SysML状态机图不存在状态机嵌套，即State Machine中不包含StateMachine，依照步骤2.3和2.4将SysML状态机图中的每个State Machine元素转换为一个UPPAAL模板Template；
2.3依据State Machine元素形成UPPAAL模板Template的方法如下：
1)将State Machine元素中State元素转换为UPPAAL模型中的location元素，将State元素的“Invariant”约束属性转换为location元素的“Invariant”，将State Machine元素中的初始化元素Initial转换为UPPAAL模型中标记为Initial的location元素；
2)将State Machine元素中Transition元素转换为UPPAAL模型中的edge元素，将State Machine元素中Transition元素的“Guard”属性转换为UPPAAL模型中edge元素的“Guard”，将State Machine元素中Transition元素的“Effect”属性转换为UPPAAL模型中edge元素的“Update”；
3)将State Machine元素中的同步元素Synch转换为UPPAAL模型迁移中的“Sync”。
2.4将描述时间信息的MARTE元素转换到UPPAAL模型中的方法：
1)将MARTE模型中的Clock元素转换成UPPAAL模型中的时钟；
2)将MARTE模型中ClockConstraint元素转换为UPPAAL模型迁移中的“Update”；
3)将MARTE模型中的TimedConstraint元素转换为UPPAAL模型中迁移中的“Guard”或UPPAAL模型中的“Invariant”。
2.5如果SysML状态机图存在状态机嵌套，即State Machine中包含StateMachine，形成UPPAAL模型的方法如下：
1)将SysML状态机图直接包括的State Machine元素称为最高级State Machine，并标记为第1级State Machine，将第1级State Machine直接包括的State Machine标记为第2级State Machine，将第2级State Machine直接包括的State Machine标记为第3级State Machine，以此类推，将最低级State Machine标记为第N级State Machine；
2)选择一个第N级的State Machine，依照2.3、2.4的步骤，将其转换到UPPAAL模板Template。重复本步，直到所有第N级的State Machine都转换到相应的UPPAAL模板Template。令i依次取值1、2、3、…、(N-1)，每次取值后均执行第3)步操作；
3)选择一个第(N-i)级的State Machine，剔除其中所包含的第(N-i+1)级的StateMachine，将剩余部分依照2.3、2.4的步骤转换到UPPAAL模板Template。重复操作，直到对所有第(N-i)级的State Machine进行了本步操作。
3、根据系统级危险确定系统的安全性约束，并使用模型检测技术支持的逻辑语言描述安全性约束，形成待检测性质
本步结束之后，每条系统级危险对应一条系统的安全性约束，而每条系统的安全性约束又对应一条待检测性质。
系统的安全性约束可以定义为UCA的补集(complement of set)。UCA的构成元素CA-PR，处于被控过程的输入位置，也即作动器的输出位置，但不是控制器的输出位置。
时间相关UCA中的“过早”、“过晚”、“错误顺序”、“持续太长”、“结束太快”等情况，都可以通过时间信息来表达。在状态机组成元素中添加时间信息，通过设置时间信息之间的关系即可以表达上述时间关系。
针对时间无关UCA构建模型待检测性质与针对时间相关UCA构建模型待检测性质两者之间的区别在于后者在描述系统安全性约束的时候需要使用时钟变量。
当使用包括时钟变量的模型检测技术，可以直接使用其支持的逻辑语言描述时间相关的系统安全性约束。例如，当使用UPPAAL时，可以直接使用TCTL(Time ComputationTree Logic)描述时间相关的系统安全性约束。TCTL是UPPAAL工具检测使用的时态逻辑语言，它可以描述以时间为基准，通过树状结构展开的系统路径。
当使用不包括时钟变量的模型检测技术时，可以利用模型检测技术提供的建模语言自定义时钟，然后利用模型检测技术支持的逻辑语言描述时间相关的系统安全性约束。例如，当使用NuSMV时，可以自定义Clock变量，然后使用CTL、LTL或RTCTL等逻辑语言描述时间相关的系统安全性约束。
以下以UPPAAL所支持的TCTL逻辑语言为例，说明待检测性质的生成方法：
1)待检测性质包括“全称/存在量词”、“现在/未来描述符”、“系统安全性约束状态描述”这三部分，三部分的顺序不能更改。
2)确定量词性质。如果系统安全性约束描述所有的系统状态，那么使用全称量词“A”，如果系统安全性约束描述的是某一个或某一些系统状态，那么使用存在量词“E”。
3)确定描述符。如果系统需要从初始状态就满足安全性约束，则使用现在描述符“[]”，如果系统在未来某个状态满足安全性约束，则用使用未来描述符“<>”。
4)确定系统安全性约束状态描述。使用“与”(and)、“或”(or)、“非”(not)，“蕴含”(imply)连接系统安全性约束中的状态。如果系统安全性约束涉及死锁，则使用关键字“deadlock”。
4、利用模型检测技术分析第2步所形成的模型检测模型是否满足第3步所形成的待检测性质。如果违反，模型检测技术给出反例，该反例即导致系统级危险的损失场景。重复本步，直到UPPAAL模型对所有待检测性质都完成了模型检测。
本发明损失场景的定义是：系统在致因因素的参与下产生系统级危险的过程。
5、生成“增加CF的系统第二状态机”，将其转换成模型检测模型，并对待检测性质进行检测。
5.1在第1步的系统第二状态机中，注入致因因素(CF：Causal Factors)，形成“增加CF的系统第二状态机”。
状态、迁移的目标状态、迁移条件(包括时间条件、状态条件、同步条件等)、迁移动作是状态机的组成元素。每个CF都可以通过改变一个或若干个状态机组成元素来实现。
选择一个或若干个CF，通过改变状态机组成元素将其注入系统第二状态机，形成一个“增加CF的系统第二状态机”。重复操作，直到生成需要的所有“增加CF的系统第二状态机”。
也可以将所有可能的CF同时注入系统第二状态机，形成一个“增加CF的系统第二状态机”。依据该系统第二状态机开展的模型检测工作，可以发现系统在多部件、多CF交互作用下的危险涌现行为。
5.2依据“增加CF的系统第二状态机”生成模型检测模型，生成方法见第2步。
5.3利用模型检测技术分析第5.2步的模型检测模型是否满足第3步所形成的待检测性质。如果违反，模型检测技术给出反例，该反例即导致系统级危险的损失场景。
以上介绍了本发明的一种准确识别损失场景的STPA方法。本发明还涉及一种准确识别损失场景的STPA装置。
根据本发明实施例的一种准确识别损失场景的STPA装置包括四个单元：分析目标确定单元，状态机生成单元，不安全动作识别单元、以及损失场景识别单元。以下具体介绍这四个单元。
第一，分析目标确定单元：
分析目标确定单元负责确定分析目标，包括确定损失(Identify losses)。根据优选的实施例，确定目标还可以包括确定系统级危险(Identify system-level hazards)、确定系统级安全约束(Identify system-level safety constraints)以及确定精化危险(Refine hazards)。
分析目标确定单元至少需要确定出损失。通过确定出的损失，可以在后续步骤中识别出不安全控制动作。损失涉及对相关参与方具有价值的东西。损失可能包括失去生命或人身伤害、财产损失、环境污染、任务失败、敏感信息丢失或泄露或利益相关者无法接受的其他损失。
分析目标确定单元还可以确定系统级危险、确定系统级安全约束以及确定精化危险等目标，以便减少后续步骤的工作量。
在本发明中，系统是指共同作用以实现共同目标的一组部件。一个系统可能包括多个子系统，也可能是更大系统的组成部分。危险是指在特定最坏环境条件下，将导致损失的一种系统状态或一组条件。系统级安全性约束规定了预防危险(最终预防损失)需要满足的系统条件或行为。《STPA Handbook》第17页和第20页分别对系统级危险和系统级安全性约束进行了具体的解释。
精化危险是指将系统级危险细化成若干个子危险。例如：“飞机与地面其他物体距离过近”，该危险的一个子危险是：“飞机滑行期间加速过大”。《STPA Handbook》第21页对精化危险进行了具体解释。
第二，状态机生成单元：
状态机生成单元负责利用有限状态机生成系统状态机。
层级化控制结构模型在2018年麻省理工学院Nancy Leveson和John Thomas公开的《STPA Handbook》中被描述和采用。
层级化控制结构是由反馈控制回路组成的系统模型。一个有效的控制结构将对整个系统的行为施加约束。控制结构包括控制器、控制动作、反馈、控制动作、被控过程以及其他件的输入和输出。在进行损失场景识别时，通常还会在层次化控制结构中添加作动器和传感器。控制器提供控制动作以控制过程，并且对被控过程的行为施加约束。控制器包括控制算法和过程模型。控制算法表示控制器的决策过程，它决定了要提供的控制动作。过程模型是控制器对被控制过程以及其他系统或环境相关方面的认知，该认知用于控制器做决策。反馈用于观察被控过程。实现控制器对被控过程施加作用的装置称为作动器(也可称为“执行器”)。帮助控制器从被控过程感知反馈的装置被称为传感器。
层级化控制结构中“层级化”的含义指：系统可能具有多个层级的控制器，高层级控制器可以向低层级控制器和被控过程发送控制动作，低层级控制器和被控过程向高层级控制器提供反馈。每个层级的控制器在控制低层级控制器和被控过程的同时，接受高层级控制器的控制。
虽然层级化控制结构模型建模简单，但是如上所述，其只反映了部件之间的静态输入和输出关系，对部件之间的动态行为缺乏描述，因此STPA方法虽然意识到动态涌现行为的重要性，但是所采用的层级化控制结构模型由于上述缺陷，因此不具备支撑在系统的动态涌现行为中准确识别损失场景的能力。
作为一种创造性的改进，本发明利用有限状态机表达系统层级化控制结构所提供的信息。有限状态机是表示有限个状态及状态间迁移的数学模型，它包括状态、迁移、迁移条件等元素。迁移是指从一个状态转移到下一个状态的行为。迁移之前的状态可以被称为当前状态，迁移之后的状态可以被称为目标状态。迁移条件是迁移的依据，可能包括时间条件、状态条件、同步条件等。根据需要，可以在有限状态机中添加附加元素，例如，在SysML状态机图中可以添加Effect，在UPPAAL构建的状态机中可以添加Clock和Update。
有限状态机是工业界常用的建模技术，易于使用。另外，采用SysML、AADL以及AltaRica等语言构建系统状态机，有助于STPA分析工作与已有系统工程工作融合，有利于使用已有系统工程的成果，减少STPA建模所需要的时间，同时也可以减少重构模型带来的语义变化，从而影响分析质量。
本发明的系统状态机不仅能提供控制结构模型所能提供的全部信息，而且可以详细地描述系统或部件的交互行为。状态机不仅可以描述系统的高层行为，也可以描述部件内的细节行为。因此，状态机可以描述系统完整的行为信息，控制器、被控过程、传感器、作动器都可以使用状态机描述。
本发明的用于识别不安全控制动作(UCA：Unsafe Control Action)的系统状态机可以只包括控制器状态机、被控过程状态机以及它们之间的交互关系。根据本发明，UCA识别所需要的控制器行为、被控过程行为以及它们之间的交互关系全部使用状态机建模。
本发明的用于识别损失场景的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系。根据本发明，损失场景识别所需要的控制器行为、被控过程行为、传感器行为、作动器行为以及它们之间的交互关系全部使用状态机建模。用于识别损失场景的系统状态用于识别损失场景的系统状态与用于识别不安全控制动作的系统状态机相比，增加了新的内容，因此可以是通过更新用于识别不安全控制动作的系统状态机而获得的。
在本发明中，系统或部件的输入与输出、系统状态的定义及改变、系统控制动作和反馈、环境因素和干扰，都可包含在系统状态机中。UCA识别和损失场景识别所需要的过程模型信息和控制算法信息，都通过控制器状态机表达。
在本发明中，可以使用多种语言构建系统状态机，例如SysML、AADL、AltaRica、甚至可以是模型检测(Model Checking)技术提供的建模语言。以下使用SysML语言为例举例说明构建系统状态机的建模过程，此时系统状态机即SysML系统状态机图。
1.为系统建立SysML系统状态机图。在SysML系统状态机图的“General”属性中定义全局变量及其初始值。在SysML系统状态机图中添加State Machine元素，为控制器、被控过程、传感器、作动器构建状态机。
2.State Machine元素的建模方法如下：
2.1在State Machine元素的“General”属性中定义局部变量及其初始值，在StateMachine元素中添加所需的Initial元素、State元素和Transition元素；
2.2由Initial元素指向State Machine元素的初始状态；
2.3状态不变量由State元素的“Invariant”约束属性表示，状态不变量通过布尔式表达，表示满足状态不变量时方可迁入该状态，不满足状态不变量时需要迁出该状态；
2.4状态的迁移过程由Transition元素表示，Transition元素为有向元素，必须从起始状态指向目标状态；使用Transition元素的“Guard”属性表示迁移条件，使用Transition元素的“Effect”属性表示更新；
2.5如果系统中存在同步，那么使用Synch元素描述同步信息，具体方法如下：
1)添加Synch元素指向需要同步的Transition元素；
2)确定Synch元素的标识符，相同的标识符表示同步的Transition元素；
2.6如果State Machine元素需要包括下一级State Machine元素，即状态机嵌套，则在该State Machine元素中添加下一级State Machine元素，并按照第2.1、2.2、2.3、2.4、2.5步所述对下一级State Machine元素建模；根据需要，在下一级State Machine元素中还可以继续添加State Machine元素；
3.如果SysML系统状态机图需要描述时间信息，那么使用MARTE(Modeling andAnalysis of Real Time and Embedded Systems)元素描述时间信息，具体方法如下：
1)在SysML系统状态机图中添加Clock元素表示全局时钟；
2)在存在时间信息的State Machine元素中添加Clock元素表示局部时钟；
3)如果State元素中存在时间相关状态不变量，那么在State元素的“Invariant”约束属性中添加“TimedConstraint”元素表达状态不变量；
4)如果Transition元素中存在时间更新，那么在Transition元素的“Effect”属性中添加“ClockConstraint”元素表达时间更新；
5)如果Transition元素中存在时间约束，那么在Transition元素的“Guard”属性中添加“TimedConstraint”元素表达时间约束。
第三，不安全控制动作识别单元
不安全控制动作识别单元负责利用第一步确定的损失以及第二步的生成的系统状态机，识别不安全控制动作。以下将具体介绍不安全控制动作识别单元。
1、不安全控制动作(UCA)是指控制动作(CA：Control Action)、UCA的类型(Type)、上下文(Context)之间的组合{CA、Type、Context}，并且这个组合能够导致某个系统级危险。该危险可能是已识别的系统级危险，也可能是通过当前不安全控制动作识别单元即将确认的新危险。
与《STPA Handbook》相比，本发明中对UCA的定义进行了改进，将UCA定义为一项危险，是3项元素的组合，这3项元素是：被控过程接收到的控制动作(CA-PR：Control Action-Process Received)、UCA的类型(Type)、上下文(Context)。
每个CA的属性包括该CA的发出者、接收者以及其他数据定义。CA处于被控过程的输入位置。当系统状态机中不包括作动器时，CA同时也处于控制器的输出位置。当系统状态机中包括作动器时，CA同时处于作动器的输出位置。
UCA一共有四种“类型”(Type)，如下所示，UCA Type1和UCA Type2是时间无关“类型”，UCA Type3和UCA Type4是时间相关“类型”。包含时间无关“类型”的UCA被称为时间无关UCA，包含时间相关“类型”的UCA被称为时间相关UCA。
1)UCA Type1：不提供控制动作导致危险(Not providing the control actionleads to a hazard)
2)UCA Type2：提供控制动作导致危险(Providing the control action leadsto a hazard)
3)UCA Type3：提供了一个控制动作，但是提供得过早、过晚或错误顺序(Providing a control action too early,too late,or in the wrong order)
4)UCA Type4：控制动作持续太长或结束太快(The control action lasts toolong or is stopped too soon)(适用于连续控制动作，而不是离散控制动作)
Context是UCA所处的系统和环境状态，被定义为上下文状态变量CVari的组合{CVar1,CVar2,…,CVari，…,CVarn}。CVari可能是：环境条件、被控过程状态、控制器状态、之前的控制动作以及参数等。
UCA是系统级危险。UCA有时也被称为不想要的控制动作(Unwanted ControlAction)、不期望的控制动作(Unexpected Control Actions)、危险控制动作(HazardousControl Action)等。
2、根据SysML系统状态机确定Context的上下文变量CVari及其可能的取值，列出Context全部实例。
3、通过遍历，给出{CA、Type、Context}的所有实例。每个{CA、Type、Context}的实例都被认为是一个潜在不安全控制动作(PUCA：Potential UCA)。包含时间无关“类型”(Type)的PUCA被称为时间无关PUCA，包含时间相关“类型”(Type)的PUCA被称为时间相关PUCA。
4、根据确定的损失，逐一分析每一个PUCA，确定其是否为UCA。
对于时间无关PUCA，可直接根据{CA、Type、Context}确定PUCA是否为UCA。
对于时间相关UCA，需要对时间相关“类型”(Type)进行实例化，也即确定“太早”、“太晚”、“太长”、“太快”等词的具体含义，更准确地描述时间特性，然后确定PUCA是否为UCA。
当一个PUCA确定为UCA时，该UCA将是以下两种情况中的一种。
第一种情况：UCA包含于已识别的系统级危险。此时，则不需要更新已识别的系统级危险；
第二种情况：UCA不包含于已识别的系统级危险，那么可以判断该UCA为新的系统级危险。此时，需要对该UCA进行标识，并纳入已识别的系统级危险当中。
第四：损失场景识别单元
损失场景识别单元负责利用第三步识别的不安全控制动作和模型检测技术识别损失场景。
模型检测是一种自动验证技术，构成要素包括待检测模型、待检验性质和模型检测算法。模型检测的优点是能够证明待检测模型是否满足待检测性质，如果不能满足，还能通过“反例”展示待检测模型如何运行以致违反待检测性质。反例是待检测模型一条运行状态轨迹，表明了待检测模型如何从初始状态演变成违反待检测性质时的状态。在本发明中，使用反例识别损失场景。待检测性质有时也称为待检测规约、待检测约束或待检测属性。在本发明中，将系统安全性约束列为待检测性质。通常，模型检测通过有限状态迁移图描述待检测模型，通过形式逻辑描述待检验性质。
模型检测通过状态转换过程(一般是状态机，还包括可以描述状态转换的其它形式语言，如Promela语言，活动图等)描述待检测模型；通过形式化的语句定义待检验性质；通过算法判断系统模型是否满足待检验性质，并能给出不满足带检验性质的示例。待检验性质是用来描述设计者或其他人员期望检测的属性和行为，属性通常使用形式逻辑描述，在软硬件系统中通常使用时序逻辑描述。根据本发明，通过模型检测技术对状态机进行形式化分析，将状态机构建系统控制结构模型转换成模型检测模型，可以准确且自动高效地识别损失场景。
以下详细介绍损失场景识别单元负责执行的功能。
1、更新系统状态机，经更新的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系，也包括控制器、被控过程、传感器、作动器内部部件的状态机以及子部件之间的交互关系。
当存在下述三种情况中的一种时，经更新的系统状态机需要构建时间特性。
1)需要识别时间相关UCA的损失场景。
2)后续注入的致因因素(CF：Causal Factors)包括时间特性；
3)系统本身包括时间特性；
可以使用多种语言构建系统状态机，例如SysML、AADL、AltaRica、模型检测技术提供的建模语言等。本发明优选推荐使用SysML和AADL构建系统状态机，原因是两者均是工业标准，都支持状态机嵌套和时间特性建模。
使用SysML构建系统状态机的方法请参见上述状态机生成单元负责执行的第1、2、3步，其中状态机生成单元执行的第3步描述了时间特性的建模方法。
2、根据经更新的系统状态机形成模型检测模型。
以下根据SysML系统状态机说明UPPAAL模型的形成方法：
2.1将SysML状态机图中的所有变量及其初始值转换为UPPAAL模型中的系统声明；
2.2如果SysML状态机图不存在状态机嵌套，即State Machine中不包含StateMachine，依照步骤2.3和2.4将SysML状态机图中的每个State Machine元素转换为一个UPPAAL模板Template；
2.3依据State Machine元素形成UPPAAL模板Template的方法如下：
1)将State Machine元素中State元素转换为UPPAAL模型中的location元素，将State元素的“Invariant”约束属性转换为location元素的“Invariant”，将State Machine元素中的初始化元素Initial转换为UPPAAL模型中标记为Initial的location元素；
2)将State Machine元素中Transition元素转换为UPPAAL模型中的edge元素，将State Machine元素中Transition元素的“Guard”属性转换为UPPAAL模型中edge元素的“Guard”，将State Machine元素中Transition元素的“Effect”属性转换为UPPAAL模型中edge元素的“Update”；
3)将State Machine元素中的同步元素Synch转换为UPPAAL模型迁移中的“Sync”。
2.4将描述时间信息的MARTE元素转换到UPPAAL模型中的方法：
1)将MARTE模型中的Clock元素转换成UPPAAL模型中的时钟；
2)将MARTE模型中ClockConstraint元素转换为UPPAAL模型迁移中的“Update”；
3)将MARTE模型中的TimedConstraint元素转换为UPPAAL模型中迁移中的“Guard”或UPPAAL模型中的“Invariant”。
2.5如果SysML状态机图存在状态机嵌套，即State Machine中包含StateMachine，形成UPPAAL模型的方法如下：
1)将SysML状态机图直接包括的State Machine元素称为最高级State Machine，并标记为第1级State Machine，将第1级State Machine直接包括的State Machine标记为第2级State Machine，将第2级State Machine直接包括的State Machine标记为第3级State Machine，以此类推，将最低级State Machine标记为第N级State Machine；
2)选择一个第N级的State Machine，依照2.3、2.4的步骤，将其转换到UPPAAL模板Template。重复本步，直到所有第N级的State Machine都转换到相应的UPPAAL模板Template。令i依次取值1、2、3、…、(N-1)，每次取值后均执行第3)步操作；
3)选择一个第(N-i)级的State Machine，剔除其中所包含的第(N-i+1)级的StateMachine，将剩余部分依照2.3、2.4的步骤转换到UPPAAL模板Template。重复操作，直到对所有第(N-i)级的State Machine进行了本步操作。
3、根据系统级危险确定系统的安全性约束，并使用模型检测技术支持的逻辑语言描述安全性约束，形成待检测性质。本步结束之后，每条系统级危险对应一条系统的安全性约束，而每条系统的安全性约束又对应一条待检测性质。
系统的安全性约束可以定义为UCA的补集(complement of set)。UCA的构成元素CA，是指被控过程接收到的CA，处于被控过程的输入位置，也即作动器的输出位置，但不是控制器的输出位置。
时间相关UCA中的“过早”、“过晚”、“错误顺序”、“持续太长”、“结束太快”等情况，都可以通过时间信息来表达。在状态机组成元素中添加时间信息，通过设置时间信息之间的关系即可以表达上述时间关系。
针对时间无关UCA构建模型待检测性质与针对时间相关UCA构建模型待检测性质两者之间的区别在于后者在描述系统安全性约束的时候需要使用时钟变量。
当使用包括时钟变量的模型检测技术，可以直接使用其支持的逻辑语言描述时间相关的系统安全性约束。例如，当使用UPPAAL时，可以直接使用TCTL(Time ComputationTree Logic)描述时间相关的系统安全性约束。
当使用不包括时钟变量的模型检测技术时，可以利用模型检测技术提供的建模语言自定义时钟，然后利用模型检测技术支持的逻辑语言描述时间相关的系统安全性约束。例如，当使用NuSMV时，可以自定义Clock变量，然后使用CTL、LTL或RTCTL等逻辑语言描述时间相关的系统安全性约束。
以下以UPPAAL所支持的TCTL逻辑语言为例，说明待检测性质的生成方法：
1)待检测性质包括“全称/存在量词”、“现在/未来描述符”、“系统安全性约束状态描述”这三部分，三部分的顺序不能更改。
2)确定量词性质。如果系统安全性约束描述所有的系统状态，那么使用全称量词“A”，如果系统安全性约束描述的是某一个或某一些系统状态，那么使用存在量词“E”。
3)确定描述符。如果系统需要从初始状态就满足安全性约束，则使用现在描述符“[]”，如果系统在未来某个状态满足安全性约束，则用使用未来描述符“<>”。
4)确定系统安全性约束状态描述。使用“与”(and)、“或”(or)、“非”(not)，“蕴含”(imply)连接系统安全性约束中的状态。如果系统安全性约束涉及死锁，则使用关键字“deadlock”。
4、利用模型检测技术分析第2步所形成的模型检测模型是否满足第3步所形成的待检测性质。如果违反，模型检测技术给出反例，该反例即导致系统级危险的损失场景。重复本步，直到UPPAAL模型对所有待检测性质都完成了模型检测。
5、生成“增加CF的系统第二状态机”，将其转换成模型检测模型，并对待检测性质进行检测。
5.1在第1步的系统第二状态机中，注入致因因素(CF：Causal Factors)，形成“增加CF的系统第二状态机”。
状态、迁移的目标状态、迁移条件(包括时间条件、状态条件、同步条件等)、迁移动作是状态机的组成元素。每个CF都可以通过改变一个或若干个状态机组成元素来实现。
选择一个或若干个CF，通过改变状态机组成元素将其注入系统第二状态机，形成一个“增加CF的系统第二状态机”。重复操作，直到生成需要的所有“增加CF的系统第二状态机”。
也可以将所有可能的CF同时注入系统第二状态机，形成一个“增加CF的系统第二状态机”。依据该系统第二状态机开展的模型检测工作，可以发现系统在多部件、多CF交互作用下的危险涌现行为。
5.2依据“增加CF的系统第二状态机”生成模型检测模型，生成方法见第2步。
5.3利用模型检测技术分析第5.2步的模型检测模型是否满足第3步所形成的待检测性质。如果违反，模型检测技术给出反例，该反例即导致系统级危险的损失场景。
以上描述的装置实施例仅是示意性的。各单元的划分可以是基于逻辑功能的划分，在实际实现时可以采用其他的划分方式。例如多个单元可以结合或者可以集成到另一个单元或系统中。上述各个单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
上述各个单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本发明的技术方案可以采用软件产品的形式体现，该计算机软件产品存储在一个存储介质中，包括若干指令用以使计算机设备的处理器执行本发明各个实施例的方法的全部或部分步骤。存储介质包括但不限于闪存盘、只读存储器(ROM)、随机存取存储器(RAM)、移动硬盘、磁盘或者光盘等可以存储程序代码的介质。
以上实施例中，采用SysML/MARTE构建系统状态机，采用UPPAAL进行模型检测。本发明亦可使用其他语言构建系统状态机，同样地，也可以使用其他模型检测工具识别损失场景。
使用NuSMV进行模型检测
可以使用NuSMV替代以上实施例中的UPPAAL进行模型检测。使用NuSMV替代UPPAAL之后，主要涉及两项改动。第一项是待检测性质使用NuSMV所支持的CTL、LTL、RTCTL逻辑语言描述，这项工作可以根据CTL、LTL、RTCTL的规格说明完成。第二项改动是将原技术方案中依据SysML/MARTE模型形成UPPAAL模型的工作，替代为依据SysML/MARTE模型形成NuSMV模型。
依据SysML/MARTE模型形成NuSMV模型的具体方法如下：
1、将SysML状态机图中的全局变量转换为NuSMV以VAR关键字声明的全局变量，将其初始值转换为NuSMV main MODULE中的init语句；
2、将SysML状态机图中的State Machine元素转换为NuSMV模型中的状态机，使得SysML状态机图中的各个State Machine元素分别对应一个NuSMV状态机，具体转换方法如下：
1)将SysML状态机图中的State Machine元素中的变量转换为NuSMV main MODULE中的变量声明；将其初始值转化为init语句；
2)将SysML状态机图中的State Machine元素的name转换为NuSMV状态机名称标识符；将SysML状态机图中State Machine元素的所有的State元素名称转换为NuSMV状态机状态标识符；将SysML状态机图中的State Machine元素中的初始化元素Initial转换为NuSMV模型中的init语句；
3)将SysML状态机图中State Machine元素包含的Transition元素转换为NuSMV状态机；将SysML状态机图中State Machine元素包含的Transition元素的迁移条件转换为NuSMV模型中迁移语句的迁移条件；将SysML状态机图中State Machine元素的Transition元素迁移的目标状态转换为NuSMV模型迁移语句的状态标识符；
将State元素的“Invariant”属性转换为NuSMV模型中以该State元素为目标状态的迁移条件，将State元素的“Invariant”属性取非操作后转换为NuSMV模型中以该State元素为起始状态的迁移条件；
4)将当前State Machine元素的名称标识符写入NuSMV模型默认迁移语句；
5)由于NuSMV自身状态机支持同步，不需要对同步进行额外处理。
3、如果SysML系统状态机模型中使用了MARTE元素描述时间信息，转换方法如下：
1)将MARTE模型中的Clock元素转换成NuSMV模型中的integer变量，并用next(clockname):＝clockname+1定义Clock；
2)将MARTE模型中ClockConstraint元素转换为NuSMV状态机模型，并将其“Update”属性定义为状态机转换语句；
3)将MARTE模型中的TimedConstraint元素转换为NuSMV状态机中迁移语句的迁移条件。
使用AADL构建系统模型
可以采用AADL构建系统模型，然后将AADL构建的模型转换为UPPAAL构建的模型。
AADL系统模型建模方法如下：
1、为系统建立AADL模型的package，并将package命名为系统模型名称；
2、在package中的public部分声明全局变量，全局变量以Data组件的形式添加，并在系统组件(System Component)的features中初始化系统变量。系统同步关系以port的形式添加在System Component的features中；
3、为系统行为建立AADL的行为模型，行为模型使用系统附件behavior annex描述，具体建模方法如下：
1)在AADL模型的System Component中添加Annex behavior_specification。当存在组件嵌套时，需要在系统子组件(System Subcomponent)中添加Annex behavior_specification；
2)在Annex behavior_specification的variables中定义状态机的变量；
3)在Annex behavior_specification的states中定义状态机的状态；
4)在Annex behavior_specification的transitions中的guard定义状态机的迁移条件，在action中定义变量的更新；
4、同步关系通过connection连接的port进行定义；
5、时钟变量通过定义标识符为Clock的Data组件来实现，系统的时间关系通过Clock变量在transitions中的guard和action表达；
6、组件嵌套关系可以通过在System Component中添加System Subcomponent实现，如果需要，可以在System Subcomponent中继续添加System Subcomponent。按照第3、4、5步所述对System Subcomponent建模。
在本发明中，依据AADL模型形成UPPAAL模型的方法如下：
1、将AADL中的package名称转换为UPPAAL模型的名称；
2、将AADL模型中的全局变量转换为UPPAAL模型中的全局变量，具体方法如下：
1)将AADL模型的Data类型的组件及其初始化信息转换为UPPAAL模型中的系统声明及其初始化信息；
2)将AADL模型的System Component中通过connection相连的port转换为UPPAAL模型中chan类型的变量；
3、将AADL模型的System Component转换为UPPAAL的Template，具体方法如下：
3.1将AADL模型的System Component的名称转换为UPPAAL的Template名称；
3.2将AADL模型的System Component的Annex behavior_specification中的variables转换成UPPAAL模型局部变量的声明。将Annex behavior_specification中states的state转换成UPPAAL模型中的location。将Annex behavior_specification中transitions的guard(除port外)转换成UPPAAL模型中的guard，将Annex behavior_specification中transitions的action转换成UPPAAL模型中的update；
4、将behavior annex中transitions的port转换为UPPAAL模型中的Sync；
5、时间变量的转换同3.2中transitions的转换；
6、如果AADL模型中存在组件嵌套，则将组件嵌套结构平展化后按照2、3、4、5步进行转化。
使用AltaRica构建系统状态机
本方案采用AltaRica构建系统状态机，然后将AltaRica模型转换为NuSMV模型。如果存在以下情况：1)系统状态机不需要构建时间特性；2)不需要在系统状态机中注入与时间相关的CF；3)不需要识别时间相关UCA的场景；4)不需要使用状态机嵌套机制，那么可以使用AltaRica构建系统状态机。
AltaRica系统状态机模型构建方法如下：
1、在AltaRica模型中定义全局变量，并使用domain关键字声明各状态机；
2、在AltaRica模型的block System中定义变量和各状态机的名称和状态，随后使用init语句定义系统各状态机的初始值；
3、在AltaRica模型的block System中用switch-case语句描述各状态机的迁移过程，switch-case语句的条件表示迁移条件，switch-case语句的结果表示迁移的目标状态，switch-case语句中的default关键字表示各状态机的默认状态。
依据AltaRica模型形成NuSMV模型的方法如下：
1、将AltaRica模型中的全局变量转换为NuSMV模型中使用VAR关键字声明的全局变量；将AltaRica模型中block System模块转换为NuSMV模型main MODULE模块；
2、将AltaRica模型中定义的状态机转换为NuSMV模型的同名状态机，具体转换方法如下：
2.1将AltaRica模型block System中的变量及初始化转换为NuSMV main MODULE中的变量声明；
2.2将AltaRica定义的状态机的状态转换为NuSMV对应状态机的状态；将AltaRica状态机的init语句转换为NuSMV状态机的init语句；
2.3将AltaRica模型switch-case语句定义的状态机迁移过程转换为NuSMV状态机迁移过程；将AltaRica模型switch-case语句中的状态迁移条件转换为NuSMV状态机迁移条件；将AltaRica模型switch-case语句中迁移的目标状态转换为NuSMV状态机迁移的目标状态；将AltaRica模型switch-case语句中使用default关键字表示的默认状态转换为NuSMV状态机的默认迁移状态。
下面以列车车门控制为例，详细描述本发明的控制示例以及技术方案实施过程。当然本发明不限于列车车门控制应用场景，本领域技术人员可以理解本发明可以应用在其他类似的需要进行安全分析的任何场景和系统。
第一步：确定分析目标(To define the purpose of the analysis)
1、完成以下工作：确定损失(Identify losses)、确定系统级危险(Identifysystem-level hazards)、确定系统级安全约束(Identify system-level safetyconstraints)、精化危险(Refine hazards)。
为了使示例更简洁、清晰，本发明只考虑列车静止、并且车门对准站台时的相关危险。
通过这步确定的损失(L：Loss)有：
L：门挤压门道上的人或物，导致人、物、门损伤。
识别的系统级危险(H：Hazard)有：
H1：门处于完全打开状态时，并且门道存在障碍物时，门收到关门命令。
识别的系统级安全性约束(SC：Safety Constraint)有：
SCH1：门处于完全打开状态时，并且门道存在障碍物时，门不能收到关门命令。
第二步：构建系统状态机(To model system statemachine)
1、为系统建立SysML系统状态机图。在SysML系统状态机图的“General”属性中定义全局变量及其初始值。在SysML系统状态机图中添加State Machine元素，为控制器、被控过程、传感器、作动器构建状态机。
General属性中定义的全局变量如下表所示：
Figure BDA0002637022880000271
表1
系统状态机图如图2所示，包含列车员、列车门控制器、列车门、障碍物四个子状态机。
2、State Machine元素建模
具体步骤见技术方案，此处仅展示结果。
列车员状态机图如图3所示。有1个idle State和2条Transition，Initial元素指向idle State，2条Transition由于均为同步迁移，分别用Synch元素指向，其中synDriverClose表示列车员向列车门控制器发出关门指令，synDriverOpen表示列车员向列车门控制器发送开门指令。
列车门控制器状态机图如图4所示。列车门控制器接收列车员的开门指令和关门指令并对列车门发出开门命令和关门命令，并且在障碍物出现在门道时，会发出开门命令。具体的元素类型与列车员状态机图类似。
列车门状态机图如图5所示。列车门包含完全关闭、开门过程、完全打开和关门过程四个状态，由于列车门开门过程和关门过程需要时间，因此需要描述相关的时间信息。在此，实施例采用MARTE元素来进行描述。以physicalOpening State为例，指向迁入转移的ClockConstraint元素表示对tDoorOpening时钟变量进行更新，开始计时；指向State的TimedConstraint元素表示在physicalOpening状态需要满足的时间约束，即tDoorOpening<＝10；指向迁出转移的TimedConstraint元素表示迁移发生需要满足的时间约束，即tDoorOpening>＝10；上述三个MARTE元素组合起来表示开门时间为10个时间单位。关门过程同样需要10个时间单位。当然时间单位可以根据具体场景进行调整。
障碍物状态机图如图6所示。列车员可以观测到门道中是否存在障碍物。
第三步：识别不安全控制动作(To identify Unsafe Control Actions)
1、将不安全控制动作(UCA)定义为控制动作(CA-PR：Control Action)、UCA的类型(Type)、上下文(Context)之间的组合{CA-PR、Type、Context}，并且这个组合能够导致某个系统级危险。该危险可能是第一步中已识别的系统级危险，也可能是通过当前第三步即将确认的新危险。
列车门控制器提供的控制动作CA包括：开门命令(Open Command)，关门命令(Close Command)。由于此时系统状态机不包括作动器，因此CA与CA-PR相同。
CA-PR可取值有Open Command或Close Command。
UCA的类型(Type)包括：Type1：不提供控制动作导致危险(Not providing thecontrol action leads to a hazard)；Type2：提供控制动作导致危险(Providing thecontrol action leads to a hazard)；Type3：提供了一个控制动作，但是提供得过早、过晚或错误顺序(Providing a control action too early,too late,or in the wrongorder)；Type4：控制动作持续太长或结束太快(The control action lasts too long oris stopped too soon)(适用于连续控制动作，而不是离散控制动作)。因此Type集合如下：
Type的可取值有Type 1,Type 2,Type 3,Type 4。
2、根据SysML系统状态机确定Context的上下文变量CVari及其可能的取值，列出Context全部实例。
上下文变量分别是列车门的状态PhysicalDoor和障碍物的状态PhysicalBlock。Context＝{PhysicalDoor，PhysicalBlock}。
PhysicalDoor可取值有1:Closing，2:Opening，3:Closed，4:Opened。
PhysicalBlock可取值有1:NotBlocked，2:Blocked。
因此，Context可取值有(1,1),(1,2),(2,1),(2,2),(3,1),(3,2),(4,1),(4,2)。
3、通过遍历，给出{CA-PR、Type、Context}的所有实例。每个{CA-PR、Type、Context}的实例都被认为是一个潜在不安全控制动作(PUCA：Potential UCA)。包含时间无关“类型”(Type)的PUCA被称为时间无关PUCA，包含时间相关“类型”(Type)的PUCA被称为时间相关PUCA。
Potential UCA＝{CA-PR,Context,Type}，共有64种情况。作为示例，本发明仅列举了少数几种情况，请见下表。
Figure BDA0002637022880000281
Figure BDA0002637022880000291
表2
4、根据第一步确定的损失，逐一分析每一个PUCA，确定其是否为UCA。
对上述64种情况逐一分析，并将结果汇总到下表。
ID Hazardous Annotation
1 Yes Identified in step1
2 No …
… … …
55 Yes Too late for 2time period
56 No …
… … …
64 … …
表3
以下以ID为1和55的PUCA为例，说明分析过程。
ID为1的PUCA，即列车门控制器在列车门处于完全打开状态(PhysicalDoor＝Opened)且障碍物位于门道(PhysicalBlock＝Blocked)时，列车门收到了(Type＝Providing)关门命令(CA＝Close Command)，是第一步已经标识的危险H1，因此在上表Hazard列填写H1。
ID为55的PUCA，即列车门控制器在列车门处于关闭过程状态(PhysicalDoor＝Closing)且障碍物位于门道(PhysicalBlock＝Blocked)时，列车门太晚(Type＝Tooearly,too late,out of order)收到开门命令(CA-PR＝Open Command)，系统将出现危险(该危险会导致损失)，并且该危险未出现在已标识危险中，是一处新增危险。本发明将其标记为H2。此外，根据系统的设计要求，将“太晚”的含义确定为晚于2个时间单位。
至此，已识别危险更新为两个，分别是H1和H2：
H1：门处于完全打开状态时，并且门道存在障碍物时，门收到关门命令。
H2:门处于关闭过程时，并且门道存在障碍物时，门晚于2个时间单位收到开门命令。
系统级危险H的可取值有H1,H2。
第四步：识别损失场景(To identify loss scenarios)
1、更新系统状态机，经更新的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系，也包括控制器、被控过程、传感器、作动器内部子部件的状态机以及子部件之间的交互关系
经更新的系统状态机全局变量如下表所示。
Figure BDA0002637022880000301
Figure BDA0002637022880000311
表4
经更新的系统状态机图如图7所示。
列车员和障碍物状态机图未发生变化，因此不再重复展示。
由于加入了列车门作动器，列车门控制器状态机图发生了变化，由原来的直接向列车门发出控制命令转为向列车门作动器发出开门命令和关门命令。变化后状态机图如图8所示。
由于加入了列车门作动器和列车门传感器，列车门状态机图同样发生了变化，由原来的直接接收列车门控制器的命令改为接收列车门作动器的信号输出，同时反馈信号改为经由列车门传感器传递。变化后的列车门状态机图如图9所示。
列车门作动器状态机图如图10所示，用于接收列车门控制器发出的关门命令和开门命令，向列车门输出关门信号和开门信号。
列车门传感器状态机图如图11所示，用于感知列车门的状态，向列车门控制器发送相应的列车门状态信息。
障碍物传感器状态机图如图12所示，用于感知障碍物是否处于门道，并向列车门控制器发送对应的信息。
2、根据第1步形成的经更新的系统状态机形成模型检测模型
具体的生成过程请见技术方案，此处仅展示生成结果。
列车门控制器UPPAAL Template如图13所示。
列车门作动器UPPAAL Template如图14所示。
列车门UPPAAL Template如图15所示，其中clear()和start()函数分别对时钟变量counter进行清零和开始计时；block变量为布尔值，true表示障碍物位于门道，false表示障碍物不位于门道；counter是为了记录障碍物出现至列车门转为打开状态这一过程的时间而定义的时钟变量；SysML系统状态机中没有表达counter、clear()、start()等信息的变量和函数，为了验证安全性约束，因此在UPPAAL Template中添加了上述变量和函数。
列车门传感器UPPAAL Template如图16所示。
列车员UPPAAL Template如图17所示。
障碍物UPPAAL Template如图18所示，其中start()函数的引入是为了验证安全性约束，start()函数用于对时钟变量counter开始计时。
障碍物传感器UPPAAL Template如图19所示。
3、根据系统级危险确定系统的安全性约束，并使用模型检测技术支持的逻辑语言描述安全性约束，形成待检测性质；本步结束之后，每条系统级危险对应一条系统的安全性约束，而每条系统的安全性约束又对应一条待检测性质
根据第三步确认的系统级危险H1和H2，确定系统的安全性约束(简写为SC，下标表示对应的系统级危险)如下：
SCH1：门处于完全打开状态时，并且门道存在障碍物时，门不能收到关门命令。
SCH2：门处于关闭过程时，并且门道存在障碍物时，门必须在2个时间单位内收到开门指令。
再将安全性约束转换为TCTL约束(Specification，简写为Spec，下标表示对应的系统级危险)，即待检测性质：
SpecH1：
A[]not(PhysicalDoor.physicalOpened and PhysicalBlock.physicalBlockand actuatorOutput＝＝0)
SpecH2：
A[]not(PhysicalDoor.physicalClosing and actuatorOutput＝＝0 andcounter＞＝2)。
4、利用模型检测技术分析第2步所形成的模型检测模型是否满足第3步所形成的待检测性质，如果违反，模型检测技术给出反例，该反例即导致系统级危险的损失场景；重复本步，直到UPPAAL模型对所有待检测性质都完成了模型检测。
验证SpecH1结果：通过。
A[]not(PhysicalDoor.physicalOpened and PhysicalBlock.physicalBlockand actuatorOutput＝＝0)满足该性质
验证SpecH2结果：通过。
A[]not(PhysicalDoor.physicalClosing and PhysicalBlock.physicalBlockand counter＞2)满足该性质.
验证结果表明第1步建立的经更新的系统状态机模型满足上述安全性约束。
5、生成“增加CF的经更新的系统状态机”，将其转换成模型检测模型，并对待检测性质进行检测
在第1步所建立的经更新的系统状态机中，障碍物传感器和列车门作动器的信号转换和传输不存在延迟。在这里通过改变状态机状态和迁移，分别向障碍物传感器和列车门作动器注入1到2个时间单位的信号传输延迟，共计两个CF，形成增加CF的经更新的系统状态机模型。
向障碍物传感器状态机注入信号延迟的方法如下：
新定义局部时钟变量tBlockSensorDelay为局部时钟变量，用来表达障碍物传感器延迟时间，增加了一个中间状态(图20左上状态)，对其迁入Transition元素的“Effect”属性添加“ClockConstraint”元素对tBlockSensorDelay置零，中间状态的“Invariant”约束属性添加“TimedConstraint”元素(tBlockSensorDelay＜＝2)，迁出Transition元素的“Guard”属性添加“TimedConstraint”元素(tBlockSensorDelay＞＝1)，通过上述元素共同表达障碍物传感器从接收到synBlock信号到发出synBlockSensorOutputBlock信号的延迟为1-2个时间单位。
注入延迟后的障碍物传感器状态机图如图20所示。
向列车门作动器状态机注入信号延迟的方法如下：
新定义局部时钟变量tActuatorDelay，用来表达列车门作动器延迟时间，增加了一个中间状态(图21上部状态)，对其迁入Transition元素的“Effect”属性添加“ClockConstraint”元素对tActuatorDelay置零，中间状态的“Invariant”约束属性添加“TimedConstraint”元素(tActuatorDelay＜＝2)，迁出Transition元素的“Guard”属性添加“TimedConstraint”元素(tActuatorDelay＞＝1)，通过上述元素共同表达列车门控制器从接收到synControllerOutputCommand信号到输出开门信号(actuatorOutput＝1)的延迟为1-2个时间单位。
注入延迟后列车门作动器状态机图如图21所示。
用“增加CF的SysML系统状态机”生成模型检测模型，由于其他状态机保持不变，此处仅展示注入了CF的障碍物传感器和列车门作动器状态机图生成的UPPAAL模型：
注入延迟后列车门作动器UPPAAL模型如图22所示。
注入延迟后障碍物传感器UPPAAL模型如图23所示。
对注入了CF的UPPAAL模型进行验证。
SpecH1验证结果：未通过。
A[]not(PhysicalDoor.physicalOpened and PhysicalBlock.physicalBlockand actuatorOutput＝＝0)不满足该性质.
SpecH1反例路径(损失场景1)：
①.列车员发出开门指令(synDriverOpen)；
②.列车门控制器接收到指令后，向列车门作动器发出开门命令(synControllerOutputOpenCommand)；
③.列车门作动器收到开门命令后，延迟1-2个时间单位，向列车门输出开门信号(actuatorOutput＝1)；
④.随后列车门由关闭状态(physicalClosed)转为开门过程状态(physicalOpening)，同时列车门传感器也转为感知开门过程状态(sensoredOpening)；
⑤.经过10个时间单位后，列车门转为完全打开状态(physicalOpened)，同时列车门传感器也转为感知完全打开状态(sensoredOpened)；
⑥.接着列车员发出关门指令(synDriverClose)；
⑦.列车门控制器向列车门作动器发出关门命令(synControllerOutputCloseCommand)；
⑧.列车门作动器输出关门信号(actuatorOutput＝0)；
⑨.障碍物出现在门道，门道处于存在障碍物的状态(physicalBlock)，列车门传感器(tBlockSensorDelay)出现1-2个时间单位延迟。
此时，门道处于存在障碍物的状态(physicalBlock)，列车门处于完全打开状态(physicalOpened)且列车门作动器输出关门信号(actuatorOutput＝0)，SpecH1安全约束被违反，系统处于危险状态被违反。
如图24所示，左侧为最后变量取值，右侧为反例时序图。
SpecH2验证结果：未通过。
A[]not(PhysicalDoor.physicalClosing and PhysicalBlock.physicalBlockand counter>2)不满足该性质.
SpecH2反例路径(损失场景2)：
①.列车员发出开门指令(synDriverOpen)；
②.列车门控制器接收到指令后，向列车门作动器发出开门命令(synControllerOutputOpenCommand)；
③.列车门作动器作动器收到开门命令后，延迟1-2个时间单位，向列车门输出开门信号(actuatorOutput＝1)；
④.随后列车门由关闭状态(physicalClosed)转为开门过程状态(physicalOpening)，同时列车门传感器也转为感知开门过程状态(sensoredOpening)；
⑤.经过10个时间单位后，列车门转为完全打开状态(physicalOpened)，同时列车门传感器也转为感知完全打开状态(sensoredOpened)；
⑥.接着列车员发出关门指令(synDriverClose)；
⑦.列车门控制器向列车门作动器发出关门命令(synControllerOutputCloseCommand)；
⑧.列车门作动器输出关门信号(actuatorOutput＝0)；
⑨.随后列车门由完全打开状态(physicalOpened)转为关门过程状态(physicalClosing)，同时列车门传感器也转为感知关门过程状态(sensoredClosing)；
⑩.障碍物出现在门道，门道处于存在障碍物的状态(PhysicalBlock)，障碍物传感器接收到synBlock信号，此时counter由start()函数置零，开始计时；
Figure BDA0002637022880000341
由于障碍物传感器向列车门控制器发送synBlockSensorOutputBlock信号的过程存在1-2个时间单位的延迟，因此counter此刻记录了1-2个时间单位；
Figure BDA0002637022880000342
列车门控制器发出开门命令(synControllerOutputOpenCommand)；
Figure BDA0002637022880000343
由于列车门作动器输出开门信号的过程存在1-2个时间单位的延迟，因此counter此刻记录了2-4个时间单位，表示从门道内存在障碍物到列车门接收到开门命令经过了2-4个时间单位。
列车门处于关门过程状态(physicalClosing)，门道处于存在障碍物的状态(physicalBlock)，从门道内存在障碍物到列车门接收到开门命令经过的时间(counter)大于2个时间单位，SpecH2被违反，系统处于危险状态。
这条损失场景包含了向障碍物传感器和列车门作动器注入的两个与信号传输延迟有关的CF，它们共同作用，在系统的交互运行中导致危险。
如图25所示，左侧为最后变量取值，右侧为反例时序图。
与现有的STPA方法相比，本发明的基于一种准确识别损失场景的STPA方法具有以下优点：
1、采用状态机构建系统控制结构。
1)状态机是工业界常用的建模技术，易于使用；
2)采用SysML、AADL以及AltaRica等语言构建系统状态机，有助于STPA分析工作与已有系统工程工作融合，也有利于使用已有系统工程的成果，减少STPA建模所需要的时间，同时也可以减少重构模型带来的语义变化，从而影响分析质量；
3)状态机不仅可以描述部件之间的输入、输出信息，而且可以描述系统行为，这可以为在动态行为中识别危险场景提供模型基础；
4)可以通过状态机嵌套机制构建复杂的系统状态机，满足系统控制结构层级化建模的需要。状态机不仅可以描述系统的高层行为，也可以描述部件内的细节行为。因此，状态机可以描述系统完整的行为信息，控制器、被控过程、传感器、作动器都可以使用状态机描述。
5)模型检测技术可以对状态机进行形式化分析。利用状态机构建系统控制结构模型，有助于将该模型转换成模型检测模型，从而发挥模型检测技术的优势。
2、采用模型检测技术自动识别损失场景
1)可以自动识别损失场景。不仅可以自动识别时间无关UCA/时间无关危险的发生场景，也能自动识别时间相关UCA/时间相关危险的发生场景。
2)由于模型检测是一种形式化证明技术，因此，如果通过模型检测表明系统模型满足某条安全性约束，那么该系统模型在任何场景下都将符合该条安全性约束。通过人工分析难以给出这样的结论。
3)可以在复杂的系统部件交互行为中自动识别损失场景。
4)在控制器、被控过程、作动器、传感器的自身行为、交互行为、内部行为作为整体用于模型检测，能否发现更多、更难识别的系统涌现危险发生场景。这是现有任何STPA方法都不能做到的。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (33)

1.一种准确识别损失场景的STPA方法，包括：
确定分析目标，包括确定损失；
利用有限状态机生成系统状态机；
利用确定的损失和生成的系统状态机，识别不安全控制动作；
利用模型检测技术以及识别出的不安全控制动作识别损失场景。
2.根据权利要求1所述的方法，其特征在于，所述系统状态机包括控制器状态机、被控过程状态机，以及控制器状态机和被控过程状态机之间的交互关系。
3.根据权利要求2所述的方法，其特征在于，所述系统状态机包括识别不安全控制动作所需要的控制器全部行为、被控过程全部行为，以及控制器和被控过程之间的全部交互行为。
4.根据权利要求1所述的方法，其特征在于，所述不安全控制动作是控制动作、类型以及上下文之间的组合。
5.根据权利要求4所述的方法，其特征在于，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，时间无关不安全控制动作的类型包括：不提供控制动作和提供控制动作；时间相关不安全控制动作的类型包括：过早、过晚或以错误顺序提供控制动作、控制动作持续太长或结束太快。
6.根据权利要求4所述的方法，其特征在于，所述控制动作是被控过程接收到的控制动作，所述不安全控制动作是系统级危险。
7.根据权利要求4所述的方法，其特征在于，利用确定的损失和生成的系统状态机，识别不安全控制动作包括：
利用所述系统状态机，确定控制动作和上下文；
根据所述控制动作和上下文，确定控制动作、上下文和类型之间的组合的实例；
根据所述实例识别所述不安全控制动作。
8.根据权利要求1所述的方法，其特征在于，利用模型检测技术以及识别出的不安全控制动作识别损失场景包括:
更新所述系统状态机，经更新的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系；
利用所述经更新的系统状态机，生成模型检测模型；
利用所述不安全控制动作和模型检测模型识别损失场景。
9.根据权利要求8所述的方法，其特征在于，所述经更新的系统状态机包括识别损失场景所需要的控制器全部行为、被控过程全部行为、传感器全部行为、作动器全部行为，以及控制器、被控过程、传感器和作动器之间的全部交互行为。
10.根据权利要求8所述的方法，其特征在于，所述系统状态机是使用SysML、AADL或AltaRica构建的，所述模型检测模型是使用NuSMV或UPPALL构建的。
11.根据权利要求8所述的方法，其特征在于，所述系统状态机包括时间信息。
12.根据权利要求8所述的方法，其特征在于，所述时间信息是通过MARTE元素描述的。
13.根据权利要求11所述的方法，其特征在于，所述模型检测模型是使用NuSMV构建的，其中通过构造时钟变量描述时间信息。
14.根据权利要求8所述的方法，其特征在于，利用所述不安全控制动作和模型检测模型识别损失场景包括：
根据所述不安全控制动作，确定系统的安全性约束；
利用模型检测逻辑语言对所述系统安全性约束进行描述，形成待检验性质；
利用模型检测模型对所述待检测性质进行模型检测，识别损失场景。
15.根据权利要求14所述的方法，其特征在于，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，所述时间相关不安全控制动作包含过早、过晚、错误顺序、持续太长、或结束太快的时间信息，所述时间信息由所述模型检测模型中的时钟变量表达。
16.根据权利要求14所述的方法，其特征在于，所述待检验性质使用逻辑语言TCLT、CTL、LTL或RTCTL描述。
17.一种准确识别损失场景的STPA装置，包括：
分析目标确定单元，用于确定目标，包括确定损失；
状态机生成单元，用于利用状态机构建系统控制结构，生成系统状态机；
不安全动作识别单元，用于利用确定的损失和生成的系统状态机，识别不安全控制动作；
损失场景识别单元，用于利用模型检测技术和识别出的不安全控制动作识别损失场景。
18.根据权利要求17所述的装置，其特征在于，所述系统状态机包括控制器状态机、被控过程状态机，以及控制器状态机和被控过程状态机之间的交互关系。
19.根据权利要求18所述的装置，其特征在于，所述系统状态机包括识别不安全控制动作所需要的控制器全部行为、被控过程全部行为，以及控制器和被控过程之间的全部交互行为。
20.根据权利要求17所述的装置，其特征在于，所述不安全控制动作是控制动作、类型以及上下文之间的组合。
21.根据权利要求20所述的装置，其特征在于，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，时间无关不安全控制动作的类型包括：不提供控制动作和提供控制动作；时间相关不安全控制动作的类型包括：过早、过晚或以错误顺序提供控制动作、控制动作持续太长或结束太快。
22.根据权利要求20所述的装置，其特征在于，所述控制动作是被控过程接收到的控制动作，所述不安全控制动作是系统级危险。
23.根据权利要求20所述的装置，其特征在于，所述不安全控制动作识别单元具体用于：
利用所述系统状态机，确定控制动作和上下文；
根据所述控制动作和上下文，确定控制动作、上下文和类型之间的组合的实例；
根据所述实例识别所述不安全控制动作。
24.根据权利要求17所述的装置，其特征在于，所述损失场景识别单元具体用于:
更新所述系统状态机，经更新的系统状态机包括控制器状态机、被控过程状态机、传感器状态机、作动器状态机以及它们之间的交互关系；
利用所述经更新的系统状态机，生成模型检测模型；
利用所述不安全控制动作和模型检测模型识别损失场景。
25.根据权利要求24所述的装置，其特征在于，所述经更新的系统状态机包括识别损失场景所需要的控制器全部行为、被控过程全部行为、传感器全部行为、作动器全部行为，以及控制器、被控过程、传感器和作动器之间的全部交互行为。
26.根据权利要求24所述的装置，其特征在于，所述系统状态机是使用SysML、AADL或AltaRica构建的，所述模型检测模型是使用NuSMV或UPPALL构建的。
27.根据权利要求24所述的装置，其特征在于，所述系统状态机包括时间信息。
28.根据权利要求24所述的装置，其特征在于，所述时间信息是通过MARTE元素描述的。
29.根据权利要求27所述的装置，其特征在于，所述模型检测模型是使用NuSMV构建的，其中通过构造时钟变量描述时间信息。
30.根据权利要求24所述的装置，其特征在于，利用所述不安全控制动作和模型检测模型识别损失场景包括：
根据所述不安全控制动作，确定系统的安全性约束；
利用模型检测逻辑语言对所述系统安全性约束进行描述，形成待检验性质；
利用模型检测模型对所述待检测性质进行模型检测，识别损失场景。
31.根据权利要求30所述的装置，其特征在于，所述不安全控制动作包括时间无关不安全控制动作和时间相关不安全控制动作，所述时间相关不安全控制动作包含过早、过晚、错误顺序、持续太长、或结束太快的时间信息，所述时间信息由所述模型检测模型中的时钟变量表达。
32.根据权利要求30所述的装置，其特征在于，所述待检验性质使用逻辑语言TCLT、CTL、LTL或RTCTL描述。
33.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时执行权利要求1至16中任一项所述的方法。
CN202010828296.1A 2020-08-17 2020-08-17 一种准确识别损失场景的stpa方法和装置 Active CN114077782B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202010828296.1A CN114077782B (zh) 2020-08-17 一种准确识别损失场景的stpa方法和装置
PCT/CN2021/111488 WO2022037430A1 (zh) 2020-08-17 2021-08-09 一种准确识别损失场景的stpa方法和装置
US18/021,598 US20230305550A1 (en) 2020-08-17 2021-08-09 Stpa method and device for accurate identification of loss scenarios

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010828296.1A CN114077782B (zh) 2020-08-17 一种准确识别损失场景的stpa方法和装置

Publications (2)

Publication Number Publication Date
CN114077782A true CN114077782A (zh) 2022-02-22
CN114077782B CN114077782B (zh) 2024-07-05

Family

ID=

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180107200A1 (en) * 2016-10-19 2018-04-19 Sangmyung University Seoul Industry-Academy Cooperation Foundation Method and apparatus for analyzing hazard, and computer readable recording medium
WO2018074647A1 (ko) * 2016-10-19 2018-04-26 상명대학교서울산학협력단 위험 분석 방법 및 장치, 컴퓨터 판독가능 기록 매체
CN108376221A (zh) * 2018-02-27 2018-08-07 哈尔滨工业大学 一种基于aadl模型扩展的软件系统安全性验证与评估方法
CN108398940A (zh) * 2018-03-16 2018-08-14 南京航空航天大学 一种基于stpa形式化模型的安全分析方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180107200A1 (en) * 2016-10-19 2018-04-19 Sangmyung University Seoul Industry-Academy Cooperation Foundation Method and apparatus for analyzing hazard, and computer readable recording medium
WO2018074647A1 (ko) * 2016-10-19 2018-04-26 상명대학교서울산학협력단 위험 분석 방법 및 장치, 컴퓨터 판독가능 기록 매체
CN108376221A (zh) * 2018-02-27 2018-08-07 哈尔滨工业大学 一种基于aadl模型扩展的软件系统安全性验证与评估方法
CN108398940A (zh) * 2018-03-16 2018-08-14 南京航空航天大学 一种基于stpa形式化模型的安全分析方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MIKE HURLEY等: "Safety Guided Design Using STPA and Model Based System Engineering", BAE SYSTEMS, 31 December 2019 (2019-12-31), pages 1 - 11 *
ZHE LI等: "Extend STPA Method Using Hybrid Dynamic Theory", FOURTH INTERNATIONAL CONFERENCE ON DEPENDABLE SYSTEMS AND THEIR APPLICATIONS, 25 January 2018 (2018-01-25), pages 137 - 142 *
钟德明等: "一种准确识别损失场景的STPA", 北京航空航天大学学报, vol. 49, no. 2, 28 February 2023 (2023-02-28), pages 311 - 323 *

Also Published As

Publication number Publication date
WO2022037430A1 (zh) 2022-02-24
US20230305550A1 (en) 2023-09-28

Similar Documents

Publication Publication Date Title
CN108376221B (zh) 一种基于aadl模型扩展的软件系统安全性验证与评估方法
Alur et al. Model checking of hierarchical state machines
Loos et al. Differential refinement logic
Larsen et al. Statistical model checking: past, present, and future
Moutinho et al. Asynchronous-channels within Petri net-based GALS distributed embedded systems modeling
Quinton et al. Contract-based verification of hierarchical systems of components
WO2022037430A1 (zh) 一种准确识别损失场景的stpa方法和装置
Teixeira et al. Supervisory control of DES with extended finite-state machines and variable abstraction
Aziz et al. Formula-dependent equivalence for compositional CTL model checking
Bernaerts et al. Validating industrial requirements with a contract-based approach
Bringmann et al. Systematic testing of the continuous behavior of automotive systems
CN114077782B (zh) 一种准确识别损失场景的stpa方法和装置
Shimakawa et al. Complexity of strong satisfiability problems for reactive system specifications
Ferrando et al. Runtime verification with imperfect information through indistinguishability relations
Mambakam et al. Pattern matching and parameter identification for parametric timed regular expressions
Blackburn et al. Modeling and cross-domain dependability analysis of cyber-physical systems
Benveniste et al. Contracts for the design of embedded systems, Part II: Theory
Shoham et al. Compositional verification and 3-valued abstractions join forces
Van Tassel An operational semantics for a subset of VHDL
L'Her et al. Proving sequential function chart programs using timed automata
Scollo et al. Architectural unit testing
Mavridou et al. Bridging the Gap Between Requirements and Model Analysis: Evaluation on Ten Cyber-Physical Challenge Problems
Filipovikj et al. Model-checking-based vs. smt-based consistency analysis of industrial embedded systems requirements: Application and experience
Hassanpour Using Safety Analysis Techniques To Derive Safety Properties For Formal Verification Of Safety-Critical Systems
Grumberg 2-valued and 3-valued abstraction-refinement in model checking

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant