接上一篇：系统建模：核电厂的安全分析（1）

目录：

注：本文为系列文章，第一部分关于系统建模的原则共分为8节，分别用2篇文章来介绍，本文为第2篇，从第5节开始介绍，欢迎关注。

5.需求的含义和表示

本文的重点是需求,表示一个系统应具有的特点，本章的目的是如何实际理解"需求"一词，以及如何与系统模型中的其他元素一起表示需求。

需求在当前情况、任务分析以及用户需求规格说明的早期就开始发展，但在整个生命周期中会与其他工程活动并行地进行完善和维护。如上一章所述，必须对未来的系统有一个想法，然后才能对它进行任何描述。更改和详细信息可以在设计的任何阶段提出。如图25所示，设计的起点是所有者/运营商的业务需求，源自经验问题或确定的技术或商业机会。在监管区域中，法律和标准也是这些顶级需求的来源。用户需求指定了用户要使用关注的系统和封闭系统的其他元素来完成的工作。用户需求与操作概念（ConOps）密切相关。职责的分配导致了更多的技术系统需求，然后进一步分配给子系统，软件和硬件。这些需求（通常称为“产品需求”）与关注的系统有关。其他一些所谓的“流程需求”与生命周期活动相关联。为了避免混淆“过程”一词，我们将其称为生命周期需求，并将其分为两组，即工程过程需求和O＆M需求。在所有级别上，标准和法规都为需求定义提供了额外的输入。此外，与设计和采购活动进行了沟通，可以提供反馈，从而导致对需求的修改。

图25.需求类型的流程图。

5.1 理解需求报告

如上所述，系统模型由以下内容的模型元素组成：

• 系统、系统元素和组件
• 实体类型（如设备类型）和个人
• 系统的能力和功能
• 系统运行状态
• 系统的操作模式及其功能
• 信息项和资料
• 活动、任务和行为
• 一个或多个系统和系统元素的行为（用例和场景)
• 各种实体的关系和属性

同样，我们有一个由项目组织、工件类型、活动、生命周期阶段、里程碑等组成的项目模型。

现在，让我们考虑一下设计人员在向系统模型中添加模型元素时的实际操作。 我们的解释是，她说了有关利益体系及其环境的当前或将来事务状态。 换句话说，设计者发表声明，意在其他利益相关者，有时甚至在项目后期的设计者自己也要接受。 这凸显了这样一个想法，即模型的一个目的是促进系统生命周期中所涉及的各方之间的沟通。 模型元素表示不同类型的声明，例如：

• 系统元素的存在
• 系统元素的属性
• 两个或多个系统元素之间的关系
• 系统元件的动态行为

此外，还可以用言语行为理论(Searle&Vanderveken，1985)对利益相关者之间的讨论进行分类。话语的“言外之意”描述了它的意旨意义，例如请求、命令、承诺等。利益相关者在与工程师沟通时的话语旨在促进利益相关者的个人愿望、意图、信念和态度。工程师应将其内容与其言外之意区分开来，以便知道是否将内容表示为一种需求(Jureta等人)。(2008年)。重要的是事先就具体的关键字和条款达成一致，这表明在其他非强制性声明中存在一个需求(iso/iec/ieee 29148,2011年，第9页)。一种常见的方法是使用诸如“应该”、“应该”和“可以”这样的词。当应用于系统建模时，我们可以说声明有各种“交流意图”来描述它们的言外之意，例如：

• 事实： ”目前的发电厂已有30年历史了”
• 问题： ”现有的自动化系统过时了“
• 计划： ”自动化升级项目将于明年启动”
• 目标： ”在控制室的设计中应仔细考虑可用性“
• 规范： ”新的控制系统将包括一个单独的保护系统"
• 需求： ”保护系统的可用性应超过99.9％“
• 需求： ”保护系统的所有组件均应具有认证“

我们可以从上面的例子中看到，这些声明表示了一些关于其他声明(或它们所代表的真实世界实体)的内容。例如，上述保护系统的指定存在是一条声明，与其关联的可用性需求也是如此。还请注意，一个声明可以涉及一组完整的实体，就像最后一个例子中的情况一样。

通常，所有模型元素都可以理解为可以与一个或多个其他语句相关联。这种情况如图26所示，其中（指定的或实际的）物理系统元素显示为矩形，其他语句附加为椭圆。

图26。需求和其他类型的语句附加到表示未来系统元素的模型元素上。

表5给出了我们对主要声明意图的定义草案。 其中最有趣的是目标，需求和规格。 即使无法在它们之间画出明确的边界，也应弄清它们之间的差异。 目标是不强烈的，因为它们给出了方向，但没有给出应达到的确切目标（图27）。 需求是强制性的，但请避免说出应如何满足。 反过来，规格与需求的不同之处在于，规格与设计人员的联系更为精确。

注意：一些看似严格的需求实际上可能是目标，因为稍微放松一下可能会带来更好的整体解决方案。

表5.声明的意图。

图27。目标和需求的典型价值功能（改编自Hull等人，2002年）。

将系统模型的元素被理解为“语句”更有意义。可以用任何适合于该领域和目的的建模形式来表达，如自然语言、列表或图表。这也适用于需求。当设计人员出于传达意图将其理解为“需求”时，任何需求（无论是自然语言还是形式功能框图）都成为需求。 优点是可以灵活地选择用于需求表示的表示法。

5.2 将需求与系统模型相关联

声明表示了一些关于现实世界的东西，因此需求也有一个目标。如下文所示图28，不同类型的需求与不同工厂层次上的元素相关联。业务需求涉及整个工厂及其操作，而软件需求则侧重于I&C系统。从最终用户的角度来看，用户需求与几个工厂元素的相互作用有关。

图28。业务需求（BR）通常附属于整个电厂，用户需求（UR）描述主要电厂元素的编排，系统需求（SR）附属于特定电厂元素，如仪控系统。

工程师倾向于用技术术语来思考，例如设备和软件。 这也许不是理想的方法，但是在技术系统的设计中可能是实用的。 物理系统（例如工业加工厂）的层次分解可以提供其他模型元素所连接的骨架，如图29所示。例如，整个工厂具有制造活动和运行状态。 需求可以与任何类型的模型元素相关联，例如 系统，活动，状态，功能，甚至还有其他需求。 如果尚未指定系统详细信息，则可以以适当的形式将需求与相关的更高级别的元素相关联。

图29。过程工厂元素附带的活动，状态，功能和需求。

最后，我们应该观察到系统模型在其生命周期中不断发展和壮大。 随着时间的流逝，系统元素（例如，I＆C系统的仪器）可能会具有多个描述，例如客户“按需求”，设计者“按指定”和修改后“按安装”的描述。 例如，可以在购买工业过程测量和控制设备时有这种想法（Löffelmann等，2007； IEC 61987-10 2009）。 如图30所示，由过程工程师需求并由控制工程师指定进行温度测量。 供应商可以提供和交付超出查询中指定的性能特征的仪器。 在工厂维护期间，可以用更好的设备代替它。 所有这些知识都应存储在系统模型中，以进行追溯和将来的修改。

图30。跟踪现场仪表的需求、规定和竣工特性。

5.3 如何表示需求报告

所有这些模型元素都带有各种利益相关者（例如，客户和设计师）关于现有或将来的现实世界实体的声明，有时还包含关于模型元素本身的声明（作为元数据）。 声明具有各种交流意图，例如事实，问题，目标，需求和规格。 所有这些在需求定义中都是必需的。 显式intent属性的好处是，语句本身的内容可以用任何适合该目的的形式表示。 例如，图31中的旧接线图可以标记为关于当前状况或新的升级控制系统的功能需求的事实。

图31。事实上，任何描述都可以用表示意图来表示需求而不是设计（改编自Malm&Kivipuro 2004）。

如果将其理解为模型元素、需求、事实、假设等，则可以将其存储在关系数据库中，并将其作为带有各种属性的记录存储在自然语言声明中。表6给出了一个实例，其中一个功能需求与称为“I&C System”的模型元素相关联，并链接到单独的图形对象“CSF-001”。只显示了一些需求属性。

表6.表格形式的一些需求属性。

先就表示存在的特定关键字和术语达成共识非常重要的需求。 常见方法是规定以下内容（ISO / IEC / IEEE 29148 2011）：

• 需求是强制性的，具有约束力的规定和使用‘应该’。
• 关于事实，未来性或目的的声明是非强制性的，非约束性的规定并使用“Will”。 “ Will”也可以用于建立上下文或使用限制。 但是，“意愿”可以解释为具有法律约束力，因此最好避免将其用于需求。
• 偏好或目标是想要的，非强制性的，非约束性的条款和使用“应该”。
• 建议是非强制性，无约束力的规定，并使用“可能”。
• 诸如描述性文字之类的非需求使用诸如“是”，“是”和“是”之类的动词。 最好避免使用“必须”一词，因为这可能会引起误解。

在文本需求声明的情况下，很容易应用此指南。 但是，语句可以用其他方式表示，例如 使用图形，语音或视频剪辑，不一定包含“应”之类的字眼。 此外，最初被视为强制性需求的声明可以降级为目标。 因此，我们建议将语句的交流意图作为单独的属性保留，如表6所示。出于可读性考虑，文本需求可以使用上述指南，即使该冗余信息在语句意图发生变化时也必须进行更新。

如ISO / IEC / IEEE 29148（2011，p.9），EARS（Mavin等人2009）和Boilerplates（Hull等人2002）所建议，通常需求以格式正确的自然语言表示。 此外，还可以使用计算机工具来创作和分析以受控自然语言编写的需求，该语言提供了有限的词汇和一组句子模板。 可以在Tommila＆Pakonen（2014）中找到文献综述和用于模型检查I＆C功能的工具概念。

为了结束对需求本质的讨论，图32展示了需求建模的主要概念。 原则上，系统模型中的所有元素都可以理解为关于当前或将来事务状态的声明。 语句的内容可以是例如文本，图形或形式语言。 一条语句说明了实际工作中的实体，因此，涉及在模型中表示实体的其他模型元素。 声明的交流意图阐明了是否应将其解释为目标，事实，假设等。需求表达了强制性特征，但避免过早指定解决方案。 术语约束是指出于某种原因故意这样做的需求。 可以使用各种标准（例如原始利益相关者，相关目标或内容）对需求（以及其他声明）进行分类。 图32仅给出了一些常见示例。

图32。与需求相关的主要概念。

6.可追溯性关系

在复杂和关键的应用程序中，有必要管理模型元素之间的依赖关系。这是验证和确认设计解决方案以及评估和管理在设计过程中所做的更改所必需的。可追溯性对于开发人员以及工厂所有者和运营商而言都是宝贵的，例如通过更好地管理依赖关系和利用设计知识的方式。如今，可追溯性已成为软件安全标准的基本原则之一，也是软件认证的关键前提（Nejati等，2011）。因此，本节对该主题进行了介绍，并概述了描述可追溯性信息的简单概念模型。有关该主题的文献综述，请参见Tommila（2013）的报告。

可追溯性的基本思想是古老的，已被广泛接受，但其确切含义和实用方法仍在开发中。因此，先进的可追溯性在行业中并不常见（Gotel等，2012）。取而代之的是，可追溯性仍然倾向于以临时性的方式进行，其结果无法预测（Mäder等人，2009a）。标准和指南从总体上描述了对可追溯性的需求，但缺乏针对特定实践的明确指导（Gotel等人，2012）。尽管被广泛认为是有益的，但与可追溯性相关的成本可能很高。必须通过添加新链接，删除现有链接以及更改现有链接来更新可追溯性信息。如果不进行维护，元素之间的可追溯性关系将丢失或代表虚假信息。 （Mäder＆Gotel，2011年。）

文献对术语“可追溯性”给出了许多定义（Tommila 2013）。为了本报告的目的，尤其是基于模型的设计，我们对术语进行以下解释：

可追溯性是有关系统（系统模型）的设计信息的特征，它使得有可能找出如何（何时，由谁……）以及为什么从外部信息源（涉众和标准），从先前版本中衍生出模型元素。 或来自其他模型元素。

注意：此定义并不旨在涵盖现实世界中的个人的可追溯性，例如核材料或当前安装在系统中的特定设备。 为此，将需要其他信息来记录系统配置的状态和演变。

此定义意味着可追溯性应该同时涵盖派生路径和各个模型元素的进度（图33）。 此外，设计信息应同时支持向后追溯（从需求到其来源）和正向追溯（从需求到设计解决方案）。 这种可追溯性信息应该在链接的两端都可见（从可追溯性到可追溯性，Kotonya＆Sommerville 1998）。

注意：可追溯性涉及所有设计(和维护)信息，而不仅仅是需求。

图33。模型元素之间可追溯性链接的示例。

可追溯性除了基本设计数据外，还需要一些信息，以及要创建和维护的跟踪。 首先，必须将模型元素的先前版本与相关的更改历史记录一起存档。 其次，需要维护模型元素及其版本之间的可追溯性关系，可能包括许多属性数据。 系统模型中有几种类型的可追溯性关系，例如：

• 系统元素满足需求（如软件开发人员所述）。
• 模型元素细化了一般条款中所述的需求（例如，用例）。
• 用于细化基于文本的功能需求（OMG 2010）。
• 通过推理或分解等方式，从更高层次的需求（可用性需求可分解为与系统可靠性、维修可达性和维修组织能力有关的需求）衍生出需求。
• 模型元素的一个版本取代了以前的版本。
• 测试计划和测试结果验证是否满足需求。
• 一项需求取决于另一项需求。

需求本身通常彼此关联，特别是因为一个（原子）需求仅应说明一件事。 例如，句子“反应器温度应以1°C的精度测量。” 实际上包括两个需求声明：R1，“应测量反应器温度”，R2，“反应器温度测量的精度，R1应为1°C”。

可追溯性通常以矩阵形式表示。然而，当信息量增加时，这具有许多缺点。超链接文档使可追溯性信息可见，但也难以维护。在设计空间中遍历链接时，用户也可能迷路。可追溯性最容易通过某种数据库支持来实现，最好将可追溯性信息与设计数据分开存储（Hull等，2002）。

维护可追溯性链接是向前迈出的重要一步，但是高级可追溯性可能需要一些其他信息。赫尔等。 （2002年，第143页）引入满意度论点，以明确说明如何满足需求。有趣的是，这种想法似乎与用于评估许多应用领域中关键安全系统的安全案例方法（Kelly 1999）相似。更一般而言，术语“保证案例”用于指结构化，根据一组顶层声明评估系统属性，例如可靠性，安全性或可用性（请参见Tommila等人，2014年）。如图34所示，设计和评估是相互联系的，并且可以应用类似的推理原理，尽管争论有时会朝相反的方向发展。

图34。将设计（综合）和安全评估（分析）中的推理联系起来。

如果不要求设计要素具有更高的结构和精确度，解决可追溯性问题是不可能成功的，因为在结构不良和不精确的要素上无法充分定义可追溯性链接(nejati 等人，2011年)。此外，必须定义”可追溯性信息模型” ，以指定模型元素之间可追溯性联系的内容和格式良好的标准(mäder 等人，2009a，nejati 等人，2011年)。可追溯性信息模型的思想接近于 sareman 项目中使用的方法。事实上，下面用一个简单的跟踪信息模型来补充我们的概念模型。

我们将上述的可追溯性解释为系统和项目模型的定性特征。一个可追踪的模型包含可追踪性信息，跟踪，允许相关方确定设计解决方案是如何出现的。该模型可以回答以下问题

• 人工制品基于什么信息？
• 它在哪里被用作输入信息？
• 为什么这是一个好的解决方案？
• 是谁做的，什么时候做的？
• 如何对其进行验证？
• 它是如何被修改的（什么时候，为什么，谁）？
• 它对其他人工制品的变化有什么依赖性和影响？

设计数据本身，结合向用户提供的智能查询和视图，可以给出其中一些问题的答案。但是，必须添加更多的信息，以记录设计者的历史和推理。这意味着模型元素的新属性以及它们之间的附加关系。项目组织需要决定要记录的信息以及粒度级别。在安全系统中，标准通常由法规和安全示范的需要来确定。在下面，我们将研究跟踪可能包含的信息类型以及如何建模。

6.1 记录修改

变更可以分为几个维度，例如模型结构，含义或目的。 例如，我们可以确定以下结构变化类型（从Sivertsen等人2005和Mäder等人2009b修改）：

• 创建一个没有先前历史记录的新模型元素
• 删除现有元素分割现有元素，从而创建一些新元素
• 将现有元素组合成一个新元素
• 以“产品分解结构”中(完全)新的元素移动模型元素取代现有元素
• 以外部可见的方式(例如界面或行为)修改元素，而不改变其含义(例如编辑更正)

上面的列表着重于模型的内容和结构，而没有考虑更改的原因和目的。 我们通常可以说，可以通过以下方式触发模型元素的更改：1）设计活动的正常进行； 2）在当前版本中观察到的缺陷； 或3）外部变更。 对某些元素进行修改很容易导致必须更改其他元素的属性或结构的情况。 根据模型元素，链接及其属性的类型，更改可能会使链接的模型元素处于“可疑”状态，并导致添加/改进，修改或删除/减少系统功能。 因此，我们介绍了以下（重叠的）语义更改类型：

• 完善：在正常设计过程中，其他细节会添加到系统模型中
• 增强功能：改进了系统设计以更好地满足声明的需求
• 减少：删除不必要的功能
• 校正：消除了观察到的设计缺陷
• 适应性：由于外部环境的变化或修改而对设计进行了修改

结构和语义变化的全面分类法超出了我们的范围。 图35的上半部分说明了与更改历史记录有关的简化的主要概念。 模型元素要执行称为更改的操作，而新版本是更改的结果。 更改对象包含描述旧版本和新版本之间关系的信息。 属性更改类型可用于指示发生了什么（请参见上面的列表）。 请注意，旧版本和新版本都存储在设计数据库中，因此在这里被视为不同的对象。 变更动作通常（但不一定）是变更请求的一部分。 更改和更改请求均应说明更改和要进行的更改的原因。

图35。变更历史和设计推理的概念。

6.2 记录设计师的推理

变更历史记录描述了进行了哪些类型的修改以及原因。但是，它并不一定说明产生的伪像为何是真实的，即它们是如何从输入数据中得出的。必须添加一些东西来记录设计者的推理。在这种情况下，新的模型元素或它们的版本是从外部信息和/或其他将不被修改的模型元素衍生而来的。这些痕迹需要告诉您使用了什么信息，如何以及为什么使用。变化的历史与时间的演变有关，而其他轨迹则与因果关系有关。

为了记录选择解决方案的原因，我们需要两种信息，即来源和设计依据。源描述了新模型元素与输入数据的关系。关系的类型很多，下面将简要讨论。反过来，设计原理包含了设计者的论点。这本身就是一个复杂的问题（例如，Shum＆Hammond 1994，Tang 2007），因此我们在这里不能更深入地探讨设计原理领域。

设计数据中的多种因果关系可以在标准和文献中找到。每个组织都必须确定适合其需求和可用资源的链接类型及其语义。下面的一组可能的链接类型及其解释是来自多个来源的组合：

• 提炼：声明模型元素包含另一个模型元素的附加信息。例如，功能框图可用于完善基于文本的功能需求（改编自OMG 2010）。逆关系可以称为“精炼”。
• 源自：设计者的声明，它说另一个模型元素已被用作输入数据，因此影响了所得的模型元素。逆关系是“用于”。
• 分配给：一条语句，该语句告诉模型元素在实现另一个模型元素中定义的目标方面具有角色（责任）。倒“负责”。例如，可以将系统级需求分配给系统功能。可以将功能分配给物理系统元素，也可以将任务分配给设计者。
• 满足：设计者的声明声称，模型元素是通过满足需求的方式指定的。逆“满足于”。请注意，先前的关系“分配给”是需求工程师的声明，而这是设计者对需求的回应。
• 实施：指出设计的设备或软件旨在满足规范，例如执行功能。 依赖：模型元素是相互依赖的。
• 验证：说明计划中的设计评审或测试用例旨在验证模型，元素满足附加或分配给它的需求
• 报告：说明活动实例或任务执行的结果实现了计划的意图。例如，测试报告报告一个测试案例。

注意，一些关系可以被描述为需求或计划，即在下一个设计步骤中需要考虑的一些关系。其他一些历史数据则报告设计者已决定或测试人员已完成的工作。与上面的更改不同，因果关系在修改后保留其身份。换句话说，它们被保留为设计数据的一部分，而更改是快照，一旦关闭便无法修改。因此，因果关系可以具有许多相关联的更改，以记录对其所做的修改。这些关系通常是多对多的，并且可能涉及所有类型的模型元素，而不仅仅是需求及其解决方案。上面的讨论总结在上面的图35的下部。

我们从（Tommila 2013）进行的一次小型调查中了解到，可追溯性并不是一个小问题。有关安全关键系统的标准和法规需求它。但是，实施起来可能很复杂且昂贵。即使这个想法很古老，也找不到单一的定义或实现可追溯性的方法。用于需求管理和工程的商业软件工具为可追溯性提供了一些但相当有限的支持。但是，这一问题已被广泛认为是一个关键问题，并且围绕它进行了大量研究，尤其是在模型驱动的开发领域。从长远来看，可追溯性信息模型被视为管理跟踪并增强（自动）创建，维护和利用以进行变更影响分析和系统评估的一种方法。同时，应寻求切实可行的解决方案。要被接受并有效，可追溯性策略应适应域的当前实践和需求。但是，可追溯性不是孤立发展的，而是设计工件的基本原理和结构以及设计和管理流程应同时加以改进。

7.核电厂系统建模

前几章以非常笼统的术语讨论了系统建模。目的是介绍某些基本概念，并提出一些可能对核领域有价值的新观点。本章的目的是将一些概念映射到NPP领域中常用的术语，也许会有一些新的解释和定义。这一分析的目的是最终得到一套有限的实用术语(见附录B)。

7.1对当前术语的讨论

本文的定义和与领域专家的讨论引起了以下问题 ：

导语：

• “需求”的定义与其他领域的教科书或标准没有太大区别。换句话说，它是笼统的定义，有些含糊不清。监管问题的重要性显而易见，尤其是在国际原子能机构（2007年）的词汇表中。诸如“监管需求”之类的复合短语可能是表明所采取观点并避免歧义的一种方式。
• 在核电厂中，系统由“子系统”，结构和组件组成，但它们的本质特征和关系没有明确定义。术语“系统”具有技术上的解释，这意味着人类被视为系统的外部用户，而不是其组成部分。一个系统元素（子系统或组件）只能是一个更高级别系统的一部分。
• 除“无线电活动”外，“活动”一词在NPP标准中似乎没有特定用途。它以其一般含义使用，例如“人类活动”。通常使用术语“功能”代替“活动”。但是，说功能和活动是同义词是令人误解的，因为在我们看来，活动可以通过使用几个替代的系统功能来实现。相反，可以用更笼统的术语来谈论“工厂级别所需的功能”，例如基本安全功能，然后将其实现为各种工厂系统的具体功能。
• 在能源生产中，过程一词是指将输入转化为输出的活动链，而不是用于该过程的过程系统（过程设备）的过程。这与第3章中的建议是一致的。在工程领域，过程由项目组织执行。
• “任务”和“行动”一词经常没有精确的定义。动作可以理解为任务的一部分，但尚不清楚任务是活动还是流程的一部分。而且，对于“任务”是仅分配给人类还是分配给人类或自动化系统，似乎存在不同的观点。我们认为人类和技术系统都可以执行任务和动作。动作在没有进一步分解的意义上是“原子的”。
• 在NPP标准中尚未明确定义“功能”一词。在类似“安全功能”的表述中，应将其理解为“目的或目标”，而无需参考用于实现该目的的资源即可对其进行描述。但是，有时在其上下文中使用术语“功能”，例如，术语“功能”。 “工厂功能”，或与特定系统相关联，例如“其功能由微处理器执行的I＆C系统”。有些标准甚至没有明确区分目标和职能。
  可以通过与许多其他工业自动化领域类似的方式来理解操作状态和操作模式。核反应堆可以具有标准状态，例如动力运行，冷热关闭，加油等。关于安全性，国际原子能机构（2007年）的运行状态涵盖正常运行以及预期的运行事件和事故情况，包括设计基准事故和严重事故。
• 在事件的报告和分析中，“事件”是指从保护或安全的角度来看，其后果或潜在后果不可忽略的任何事件（国际原子能机构，2007年）。此定义非常接近实际事故或潜在事故，没有说明事件的持续时间是否为零。相关术语“场景”是假设的或假定的条件和/或事件集，也可以理解为事件。

上述例子使我们认为，应当澄清在核领域中使用的术语。以下各节包括讨论和一些建议。

7.2 NPP系统结构和行为建模

图36说明了核电厂的主要物理组成部分。 我们说核电厂是一种社会技术系统，它由各种“ NPP要素”（对应于系统要素的助手类）组成，例如组织单位（人员，例如轮班），此处称为工厂项目和区域的工厂设备 （空间，例如受控区域）。 工厂项目包括技术系统（设备，软件，数据，例如过程系统或I＆C系统），结构（建筑物，墙壁，管道支架）和原子组件。 NPP元素位于一个区域内，该区域是根据结构元素（如墙）定义的。 所有NPP元素都可以按层次分解为较低级别的元素。 与3.1节中讨论的一般系统概念不同，NPP元素恰好是一个较大元素的一部分。 该图显示不允许所有组合。 例如，过程设备显然不应该是组织单位的一部分。

图36.某核电站的主要构成元素及一些具体实例。

图37说明了与核电厂及其元素有关的一些功能概念。这些NPP要素用于开展活动，主要是能源生产过程。 “活动”是一种以目标为导向的活动，旨在为实现目标做出贡献，但保持手段开放。 “过程”是对活动网络的一种看法，从特定的角度突出了通过它的工作项目和物料的流动。活动可以分解为较小的“子活动”，任务和原子动作，它们之间具有物质，能量和信息的流动。术语任务在这里宽松地指可以明确定义的活动的一部分，例如根据要执行的顺序动作。例如，启动流程部分可以称为任务。作为活动的一部分，任务和动作不一定在设计时分配给任何NPP元素。但是，在工厂运行期间，任务是由特定的技术系统和人员执行的。例如，反应堆操作员可以通过按下显示器上的按钮来执行“启动过程系统”的动作。此操作将触发I＆C系统提供的“启动序列”功能。因此，一个NPP元素执行的操作将使用另一NPP元素作为功能提供的服务。

图37.与电厂系统有关的功能概念。

各种NPP要素（例如技术系统和组织单位）旨在提供用于执行活动的某些功能。与活动不同，功能不是“悬而未决”，而是系统的（必需，设计或实际）功能。例如，IEC 61513（2011）将I＆C功能定义为“控制，操作和/或监视过程的定义部分的功能”。过程工程师使用该术语来构建I＆C系统的功能需求。安全功能是一种I＆C功能，从安全角度来看很重要（YVL B.1 2013）。其中一些功能旨在为外部“客户端”提供服务，而其他一些功能则是在系统边界之外不可见的内部功能。即使与系统关联，对功能的描述也不应（绝对不要在初始设计步骤中）指定功能的实现方式或将其分配给系统内部元素的方式。这反映了工程设计的总体思想，即需求，流程和功能应先于其技术解决方案。一个活动可以由几个NPP要素及其功能分别或合作执行。功能可以理解为特定系统的功能，而活动（或过程）可以分配给具有适当功能的任何系统。活动和功能的区别取决于建模者的需求。对于核电厂，我们可以选择仅使用功能。可以通过以不同的方式组合工厂系统和组件提供的功能来实现工厂级别的功能（例如基本安全功能）。因此，能源的生产和余热的去除可以理解为整个工厂的功能。

所有功能都可以分解为“子功能”，物质，能量和信息之间的流动可以降低到遇到原子作用的程度。软件开发中的数据流图和控制工程中的逻辑图是可能表示的示例。子功能分配给系统的元素。这种分配可以以多种方式进行，例如。将功能分配给一个系统元素，多个冗余系统元素或具有共同责任的几个元素。分配还可以取决于情况，从而导致人员和技术系统要素之间形成复杂而动态的协作模式。这意味着子系统具有自己的功能，这些功能共同完成更高级别的功能。

功能是系统功能架构的建模元素，并构成其功能规范的核心内容。功能主要来自功能需求，并实现为物理NPP元素（例如设备或软件）。可以使用格式正确的句子和一致的，特定于应用程序的术语以自然语言描述许多功能需求甚至功能。但是，同样，需要更长的场景，表格和图形。在系统和软件工程中，统一建模语言（UML）的图形表示被广泛使用。例如，活动图和状态图可用于描述电厂过程和运行状态。在UML及其派生版本中，甚至可以找到控制工程师熟悉的功能块范例功能，例如系统建模语言（SySML）。更多特定于域的方法可用于控制系统设计。例如，功能框图（FBD，IEC 61131-3 2013）和顺序功能图（SFC，IEC 60848 2002）适用于以独立于实现的方式描述I＆C功能。挪威标准“系统控制图”（NORSOK I-005 2005）是为控制系统供应商定义精确但与平台无关的功能的方法的另一个示例。也可以找到关于该方向的其他建议，但是目前还没有被广泛接受的“自动化规范语言”。

图38。核电站领域的概念总结和几个例子

图38总结了上面的讨论，并列举了一些来自核电厂的示例。这个数字是根据80年代的詹斯·拉斯穆森（Jens Rasmussen）在80年代提出的抽象但又有争议的抽象层次结构（Lind 1999，Vicente 1999，Lintern 2006）自由地改编而来的。在我们修改后的图中，目标，流程（活动），功能和系统是垂直排列的，作为均值端层次结构。较低级别的元素是达到较高级别目的的手段。为了不被目标和职能所迷惑，我们将“目标”解释为期望的但不是强制性的事务状态，例如“高效电厂”。目标可能具有“子目标”，例如“良好的安全文化”和“可靠的工厂系统”。在这里，我们通过认为过程是未分配的“工厂功能”，而功能是用于完成过程的各个工厂系统的功能来区分过程和功能。水平维度用于分别显示在均值端层次结构的每个级别上元素的层次结构分解。例如，工厂的最终目标是获利，包括效率和安全性这两个主要的“子目标”。控制反应性是支持实现安全目标所需的一种过程。它包括控制棒的位置作为其“子过程”之一。该“子过程”是在反应堆操作员执行的任务（“手动移动”）和杆控制系统中设计的功能（“位置监控”和“位置控制”）的帮助下进行的。

7.3 关于NPP系统建模中的安全性方面

在核电厂中，即使也要考虑所有者的经济利益，安全也是一个主要问题。上面的部分总体上讨论了核电厂的术语。在这里，我们对安全需求和安全评估发表一些意见。

如今，辩论的焦点似乎集中在安全法规上，而其他利益相关者的利益和需求则被分别对待（Raatikainen等，2011）。通常，从广义上讲，安全被理解为对人类，环境和资产都没有危险。在核电厂中，主要的关注点是核安全，即在保护人员和环境免受辐射风险方面（IAEA 2007）。观点对术语有影响。例如，国际原子能机构安全术语表（2007年）对“需求”一词给出了以下定义：“（国家或国际）法律或法规或《国际原子能机构安全基本原理或安全需求》所需求的。对必要事物的更一般意义应该用其他词语来表达。”

各个利益相关者和工程学科的不同兴趣和背景可能导致术语不一致和混乱。部分补救措施可以是始终清楚地表明所采取的观点，例如，通过将命名空间与计算机编程中经常使用的每个概念相关联。命名空间指代术语的定义，并使其含义明确。一种更实用的方法是将复合短语用于各种观点。例如，在某些IEC SC45A文档中，区分了以下类型的需求（IEC 61513 2011）：

• 安全需求–当局在NPP生命周期对个人，社会和环境的影响3方面对NPP安全提出的需求。
• 运营需求–对运营能力的需求。

除了阐明术语外，还应维护与安全相关的信息，并在系统模型中从需求到实现对其进行追溯。 为此需要一些特殊的概念，属性和关系。 图39说明了对安全方面进行建模所需的一些基本概念。

图39。核电站安全需求建模的基本安全概念示例。

在本文中，我们将术语“安全需求”理解为对安全性足够重要的任何需求。安全需求可以从法规需求和拟议设计中确定的风险中得出。危险通常被理解为“可能对工厂人员，组件，设备或结构造成损坏的事件”（IEC 61513 2011）。在这里，核事件（例如，INES数据库中报告的事件）被理解为事件，而不是系统状态的瞬时变化。核事件可以是“单个事件”（设备故障），也可以是由单个事件和条件组成的复杂事故场景（IAEA 2007）。正如在3.4.5节中讨论的那样，我们建议至少将事件理解为持续时间为零的事件，至少是在考虑I＆C系统设计时。因此，危险被解释为描述可能的核事件的不想要的情景。假定的启动事件（PIE）是由于与模型元素相关联的故障模式而导致的事件，并触发危险情况，例如预期的操作事件或事故。

危害与一个或多个文档和模型元素相关联。 各种系统元素和功能的已知故障模式可用于识别问题的潜在根源（Authén等人，2014）。 在与设计活动同时进行的风险评估过程中，识别并分析危害。 根据潜在后果的严重性及其可能性，使用确定性和概率性方法来分析与危害相关的风险。 为了将风险降低到可接受的水平，建议采取一些缓解措施。 例如，这可能导致现有人工制品的变化，或者增加有关工厂系统及其设计过程的新安全需求。 在I＆C系统中，已识别的启动事件通常会导致添加安全功能以防止事件的发生。

在设计过程中，必须确定危险的风险和需求的重要性，并将其分配给解决方案。 在不同的应用领域和标准中使用了各种重要性度量。 作为安全相关性的一种度量，IEC 61508-1（2010）使用安全完整性等级（SIL）。 IEC 61513（2011）定义了I＆C功能的类别和I＆C系统的类别。 它还在功能类别和相关系统和设备的最低需求类别之间建立关系。 从国际原子能机构的角度来看，分类为A，B和C三种类别之一的I＆C功能显然成为“对安全重要的I＆C系统的安全功能”。

图40。两个安全相关系统的总体安全需求分配（IEC 61508-1 2010）。

根据IEC 61508-1（2010），风险分析导致实现或维持“受控设备”（EUC）的安全状态所需的一组“总体安全功能”。这构成了总体安全功能需求的规范。每个总体安全功能都有一个相关的“总体安全完整性需求”，该需求根据所需的降低风险或可容许的危险事件发生率指定。在下一步中，将每个总体安全功能迭代分配给一个或多个“安全相关系统”或其他“降低风险的措施”（图40）。分配给几个子系统（请参阅第3.4.2节）意味着每个子系统都负责整体安全功能的特定部分并降低了所需的风险。结果，我们可以得出结论，每个子系统必须实施一组特定于系统的安全功能，这些功能必须一起在工厂级别实施基本安全功能（请参阅IAEA 2005）。如第3章所述，系统模型可以首先包含“所需的安全功能”，随后将附带“指定的安全功能”。

7.4 I&C系统生命周期建模

对于系统需求工程，我们需要了解I＆C系统的设计过程。几乎所有相关标准和指南都定义了生命周期模型。但是，很难找到一个完善且被广泛接受的版本。本章旨在概述I＆C系统的系统工程过程。第4章中讨论的一般概念用作基础。

大型且对安全至关重要的系统（例如核电站）的建设需要在多个组织中成功实施所有过程。如图41所示，主要的安全需求和接受标准来自调节器。许可证申请人及其合作伙伴的任务是在特定情况下解释这些需求，开发解决方案，并在许可证审批过程中向监管机构证明其可接受性。与当局的联系应尽早开始，并应制定许可计划以指导该过程的实施（有关文献综述，请参见Tommila et al。2014）。在图的中间，技术工程过程显示为“ V模型”，是对开发过程的广泛使用和说明性但模糊的描述。下面的图43中给出了对V模型的更详细的解释。

图41。安全关键系统的主要生命周期过程。

工程设计通常以增量和迭代的方式进行。因此，各种活动可以分布在整个项目时间轴上。例如，需求定义在设计的早期阶段是最密集的，但也必须在以后继续进行。某些活动（例如测试）可以执行多次。这意味着活动在时间上是重叠的。然而，成功的项目管理和决策需要将生命周期划分为后续的生命周期阶段，这些阶段由里程碑分隔。在每个里程碑设计人造物都应该已经足够成熟，可以做出合理的决定。每个系统，子系统和专业工程活动（例如风险评估）都可以有自己的里程碑，其中一些里程碑应与项目级别的主要里程碑相吻合。

在工业自动化中，项目通常分为注重需求的初步设计，注重功能的基本设计和产生软件和硬件实现的详细设计。成功的工厂验收测试（FAT）之后，系统将交付给客户现场进行调试。 IEC 61508中给出了开发与安全相关的系统的需求。在核领域，IEC 61513（2011）规定了适用于执行对安全重要的功能的I＆C系统的需求。 IEC 61513采用了类似于基本安全文IEC 61508的表示格式，其中包含整体安全生命周期框架和系统生命周期框架。它解释了IEC 61508对核应用领域的一般需求，并描述了I＆C系统的典型总体安全生命周期的活动，如图42所示。作为基础，对工厂安全设计基础进行了审查。从工厂环境中收集功能，性能和独立性需求，功能分类和约束。这样就定义了对安全重要的I＆C功能，系统和设备的总体需求规范。 I＆C体系结构设计定义了整个I＆C体系结构，即所有必要的I＆C系统的布置，其中一些可能与安全性无关。然后，代表源自设计基础的功能需求的I＆C功能将分配给各个系统和设备。各个系统的实现是根据安全生命周期进行的，包括诸如需求规格书，现有设备的选择和分析，系统规格书，设计和实现以及最终的集成，验证和安装等活动。

图42. I＆C的整体安全生命周期与单个I＆C系统的安全生命周期之间的联系（IEC 61513 2011）。

系统的实际生命周期取决于特定的应用，工业领域以及所应用的标准和法规。 因此，无法提供I＆C的确切模型。 图43提供了一个建议，并显示了如何将设计内容和活动大致映射到一组通用生命周期阶段。 通过自由组合几种标准和领域，我们可以确定以下设计活动：

• 任务和范围：概念阶段从最初认识到需要一个关注的新系统或对现有系统的修改开始。这是一个初步探索、事实调查和规划阶段，评估经济、技术、安全和监管基础（改编自ISO/IEC TR 24748-1）。
• 概念设计：仪控系统在其封闭系统的环境中被视为一个过程装置或过程部分和操作组织的一部分。系统被建模为一个黑箱，没有不必要的内部结构。其主要内容 但是，如果已经知道它们在那里的话，就会对它们进行描述。因此，只有一个系统的概念，或者可能有几个仪控系统组成一个仪控系统建筑操作概念（ConOps，见Tommila et al.2013）中描述了仪控系统作为封闭系统一个元素的作用，这是引出利益相关者需求的基础。总体纵深防御（DiD）概念与ConOps相关，但侧重于安全问题。设计依据、法规需求和已识别的危险是安全需求的主要出发点。
• 需求定义：概念设计中确定的干系人需求分配给系统及其可能的已知元素，并进一步分解/制定为技术和可验证的系统需求。仪控需求源自电厂安全设计基础（IEC 61513 2011）监管需求和风险评估。最初的系统概念、足够详细的需求、技术限制和成本估算允许电厂业主作出投资决策
• 体系结构设计：结构添加到系统模型中。这包括涵盖软件和硬件的功能架构、信息架构和实现架构（见ISO/IEC/IEEE 42010 2011）。假设上述需求关注的是利益相关者的利益，架构通常是供应商对招标书中表示的需求的回答。原则上，供应商编写的功能规范应侧重于详细说明系统的应用功能。然而，也存在实施方面。达成协议后，客户与供应商之间可以签订合同。并且，当有关系统和项目组织的足够信息可用时，例如以概念设计计划或初步安全分析报告和质量计划的形式，公用事业公司可以申请建筑许可证。
• 详细设计与实现：制定详细的软件和硬件规范，并根据这些规范制造和编程系统组件。模块应单独测试，并尽可能在供应商场所进行集成，以便进行工厂验收测试。当测试成功通过后，系统可以转移到客户的现场进行安装。
• 安装和调试：在交付、验收和现场集成仪控系统后，根据规范验证其配置、功能和性能。在预调试阶段，进行非运行调整、冷对准检查、清洁和机械测试（IEC 62337 2011）。接下来，对设备和设施的运行进行测试，首先使用安全材料（冷调试），最后使用实际工艺材料（热调试）。
• 验收：调试完成，系统全部测试合格后，还有一些纸工作要做。电厂业主需要将整个项目期间收集的所有证据结合起来，并证明满足规定的需求。当涉及社会规定的监管需求时，我们在这里使用限制一词，如果成功，将产生运营许可证。但是，还需要根据其他操作需求，例如，与电厂业主的利益和控制室操作员的需要相关的需求来验证系统。
• 操作和维护：系统按照概念和开发阶段定义的政策和程序进行操作和维护。使用阶段可在监管机构颁发运营许可证后开始。在此期间，仪控系统可能会经历多次修改和升级，每次修改和升级都会以较小的规模重复生命周期阶段和活动。
• 完成：当整个实施完成或系统完全更换时，控制系统可能会达到其寿命的终点。退役可分为准备阶段和实施阶段。准备工作包括制定退役计划。退役的考虑应在设计阶段的早期开始，并一直持续到设施脱离监管（原子能机构2006年）。

图43。系统生命周期的两种观点– V型模型中显示的连续阶段和相应的设计活动。

IEC 61513（2011）强调了对来自工厂安全目标的完整而精确的需求的需要，这是对I＆C体系结构和单个I＆C系统的需求的先决条件。它对总体计划的制定提出了需求，以确保对在I＆C系统上分配的安全性至关重要的I＆C功能的需求将在系统的整个生命周期内得到实现和维持。

在关键应用程序的质量保证中，验证和确认是特别重要的工程活动。但是，术语的含义不是完全明确的，并且取决于说话者的背景和兴趣。图44试图阐明我们的解释。验证的目的是确认生命周期阶段的结果满足源自上一阶段的需求和规范。例如，将设计规范与需求进行比较，或者将系统实现与其规范进行比较。需求验证尤其是试图证明需求是一致的，并且是正确地从标准和更高级别的需求中得出的。

反过来，验证是一项活动，目的是确认任何生命周期阶段产生的伪影都描述了对预期目的和用户“良好”的系统。 通常将经过验证的文物与原始用户需求进行比较。 如果在需求中正确反映了领域知识和法规，则此方法很好用。 但是，要回答有关系统是否“良好”的问题，可能还需要使用（独立的）评估人员可用的指南或其他领域知识。 根据这种推理，需求验证旨在确保需求描述的系统，如果正确实施，将满足其用户声明或暗示的需求以及相关法规。

在文献中很难找到“限制”一词的确切含义。在一些定义中，它类似于验证(如设计确认)，在另一些定义中接近于验证。通常，这个术语与人员(如合格的NPP操作者)或已存在的产品(如适用性分析)有关。它经常有细微的差别，即预测人员或设备是否能在特定条件下成功地满足需求(例如，国际原子能机构2007)，而验证和验证则是回顾设计是否成功。从纯粹监管的观点来看，鉴定变成了将工件与官方接受标准(如图44下方所示的标准和法规)进行比较。

图44。验证、确认和鉴定活动。

在国家淘汰计划项目中，应计划并实施质量保证计划或综合管理系统。 除其他事项外，质量计划应提出（YVL B.1 2013）：

• 设计系统的组织及其职责和接口
• 设计和实施中应用的标准和准则
• 设计和实施过程的各个阶段
• 在每个设计阶段使用和产生的文件，记录和其他数据
• 完成各个阶段的审查
• 分包商监督中使用的程序
• 配置和变更管理及程序，不合格的管理
• 与设计和实施同时使用的支持流程

因此，为特定项目或组织中广泛使用而制定的质量计划似乎是记录生命周期阶段，开发过程，工程制品和所用资源的地方。 在NPP项目中还必须强调的一个方面是许可过程，需求其具有特定的里程碑和文档，以及与监管机构的持续沟通以及对不合格品和其他未解决问题的跟踪。 如今，工程流程是特定于公司的。 此外，不同国家/地区还存在各种许可和授权程序（Tommila等，2014）。 因此，公用事业及其承包商中的系统工程过程以及与安全相关的I＆C系统的许可都需要共享的参考模型。

如果您希望了解更多信息：

• 欢迎访问建模者频道 http://modeler.org.cn/
• 也欢迎直接联系我们 zhgx@uml.net.cn ，010-62670969

下载pdf版：《系统建模：核电厂的安全分析（2）》

欢迎阅读系列文章第一篇《系统建模：核电厂的安全分析（1）》

后记

希望您读了此文后有所受益。

如果您有经验乐于分享，欢迎投稿给我们。

如果您对我们的培训、咨询和工具感兴趣：