MBSE方法论之State Analysis

1、State Analysis方法论详细介绍

状态分析（State Analysis，SA）是喷气推进实验室 （Jet Propulsion Laboratory，JPL）开发的基于模型的系统工程（Model Based Systems Engineering，MBSE）方法，它可以用来支撑基于模型和状态的控制框架。其中，“状态”定义为“一个演化的系统在特定时刻的表现形式”，而“模型”则描述了状态是如何演化的。

图1描述了SA基于模型和状态的控制框架。

SA过程能够以明确的模型形式来获取系统和软件需求，从而有助于减小系统工程人员对软件的需求和软件工程人员对于这些需求的实现程度这二者之间的差距。传统上来说，软件工程人员必须将这些需求在系统行为中加以体现，期望能够准确地掌握系统工程人员对于系统行为的理解，而这往往很难说清楚。在SA中，基于模型的需求直接映射到软件中。

在SA中，准确地区分系统的状态和该状态的知识（knowledge）这两个概念是很重要的。实际的系统状态很可能是极其复杂的，但是却通常以较为简单的表现形式进行描述，这些抽象的表现形式对于描述系统状态而言是充分且必要的，称其为状态变量。系统的已知状态是状态变量在相应时刻的取值。状态和模型共同作用，实现了操控系统、预测系统未来状态、控制系统使之达到所需状态以及评价系统行为的需求。

在SA背景下所定义的“状态”拓展了传统控制论中对于“状态”的定义（例如，航天器的位置、高度以及相应的速度），将系统工程人员为了控制系统所感兴趣以及为了评估系统所需要的所有方面都包括在内。比如，这可能包括设备运转模型和健康程度、温度和压强还有能源水平（如推进剂，稳定和不稳定存储等）以及其他为了达到控制的目的所关心的方面。

在上述给定状态和状态变量定义的基础上，有必要对基于模型和状态的控制框架的关键特征进行清晰地说明：

• 1）状态是明确的。被控制系统状态的全部知识是以一组状态变量来表示的。
• 2）状态评估与状态控制是分开的。评估和控制只有通过状态变量才能联系到一起，保持二者的独立性有利于对系统状态进行客观的评价以及保证系统状态的一致性，从而实现简化设计，促进模块化，有利于软件上的实施。
• 3）硬件适配器提供了被控制系统和控制系统的之间的唯一接口。它们构成了状态框架的边界，并提供了控制和评价系统的所有度量和命令的抽象表示，同时也直接影响着翻译和管理初始硬件的输入和输出。
• 4）模型是在整个框架中无处不在的，不仅用于执行对系统状态的评估和控制，同时也有利于更高层次上的规划（例如资源管理）。SA要求必须采用最便于应用的方式来清晰地阐述模型。

该框架强调了以目标为导向的闭环运转。不同于描述预期行为的低层次开环指令，SA用目标进行描述，它是时间区间上状态变量的约束。

该框架提供了一个直接到软件的映射。主要的控制要素可以直接被映射到软件结构模块的元件上，如任务数据系统（Mission Data System , MDS）。

作为SA的理论基础，除了上述特征，基于模型和状态的控制框架还有三个核心原则作为SA方法的指导准则：

• 1）控制包括系统操作的所有方面，这一点只有通过被控制系统的模型才能充分理解并有效体现出来。因此，必须对控制系统和被控制系统进行明确地界定。
• 2）为了满足系统工程人员的需求，必须对被控制系统的模型进行详细的刻画，能够成功地建立模型的基础就是要理解状态的含义。我们所需要了解以及想要做的一切都可以表示为被控制系统的状态。
• 3）软件设计和操作的方式都应该是直接的，尽可能需要较少的翻译。

SA方法定义了一个状态变化和建模的迭代过程，确保所建立的模型在整个项目的生命周期过程中尽可能合理地演化。

此外，还要详细阐述设计软件和操作产品的模型机制。总的来说，SA为下面三种主要工作提供了一种严密有效的方法：

• 1）基于状态的行为建模。针对系统状态变量及其之间的相互关系的建模行为。
• 2）基于状态的软件设计。描述实现目标的方法。
• 3）以目标为导向的操作工程。从操作者的视角获取任务目标。

基于状态的行为建模对于基于状态的软件设计和以目标为导向的操作工程有直接影响，这使得系统工程中的SA方法在理论上适用于复杂嵌入系统，自治性以及闭环控制。事实上，由于JPL管理的空间任务具有上述特点，可以完整地采用SA方法。

2、State Analysis方法论的特征

2.1、SA与功能分析和分解的关系

简单来看，SA似乎改变了应用传统系统工程功能分析和分解方法的文件和模型驱动系统设计方法。而实际上，SA是功能分析的高度补充，这两种方法在复杂系统的发展中起到了增大收益降低风险的作用。

JPL的深入研究和发展（R&D）活动命名为“基于模型的工程设计”（MBED），其目的是将“基于模型”的概念融入用于空间系统工程生命周期中的规划阶段的工程设计中。为了支撑上述过程， SA可以与模型驱动的功能分析过程相结合，成为一种更全面和严密的系统行为建模方法。

图2展示了传统功能分析分解中迭代分解过程部分的结果，最终得到由功能、物理元件（产品故障结构）和需求所构成的一系列层次关系以及功能、物理和需求层次之间的联系。

随着SA中的状态变量、要求和度量元素的增多（见图3），Vitech CORE®MBSE中的功能分析计划也可能增加（这是仿照图2中连接和元素进行的，与传统功能分析是一致的）。

将功能分析与状态分析相结合的能力凸显了这两种MBSE方法之间的互补以及通过互补阐述的重要优势，包括：

• 1）对设计行为的深入理解和说明；
• 2）及早识别出预期外的设计挑战；
• 3）改善开发软件的可追溯性；
• 4）在设计系统中对鲁棒性缺陷进行更多保护。

2.2、SA与风险分析的关系

系统安全准则的核心是风险分析，其中风险定义为“与相应环境中其他条件共同作用可能导致事故发生的一种状态或条件的集合（损失事件）”。风险分析用于开发与安全相关的需求和设计约束，确保满足这些需求和约束，并为操作程序和指南、测试计划和管理计划做准备。风险分析是为了安全而设计的框架，也是确保管理和技术安全性的检验清单。所有的风险分析方法都是基于对事故发生原因模型的分析的。大多数传统风险分析方法都是基于因果链事故模型进行分析的。传统基于事件的风险分析包括故障树分析（FTA）和故障模式及效应临界分析（FMECA）等方法。

一种风险分析的新方法是基于STAMP的风险分析，或简称为STPA。STAMP表示系统理论事故建模和过程，该事故模型设想事故是由于元件故障所导致的，而不是因为对系统安全设计、发展和操作约束的不足控制。STAMP的最基本概念不是事件，而是约束。在STAMP中，将安全视为一个控制问题，也就是说，当元件故障，外部干扰或者系统部件之间关联关系失灵这些问题无法得到有效控制的时候就会发生事故。执行这些约束的控制过程必须将系统行为限定到这些约束所指的安全适应性范围内。正是STAMP的这种基于控制方面，导出的STPA方法以及NASA关于软件安全所确立的新的技术标准，JPL才开创了一项新的任务，目标是实现基于控制的STPA风险分析方法与基于控制的SA MBSE方法的协调。

必须注意到的是，STPA并没有取代传统的或是基于模型的系统工程过程，而是在此基础上增加了系统安全过程（如下图所示）。同时要了解，风险分析只是系统安全过程整体的一个部分。其他的重要因素，如目的规范和基于组件的系统工程，它们与STPA等风险分析方法相协调，为研究关键安全性系统的系统、软件及安全性工程提供了一种集成的方法。