目录：

注：本文为系列文章，第一部分关于系统建模的原则前四节介绍到此基本结束，后续会有文章不断，敬请关注。

下一篇：系统建模：核电厂的安全分析（2）

1.导言

在许多工程学科中，设计早期阶段的错误已被广泛认为是问题的主要来源。工业自动化的历史表明，大多数控制系统故障可能是由于规格不足而引起的。造成事故的故障中，多达40％可以归于需求规范（Chambers等，1999； HSE 2003）。 Fanmuy等人总结了其他几项研究。 （2011年）明确强调了需求作为系统工程（SE）领域的重要性。需求工程是开发复杂产品的关键成功因素。需求工程已经被标准化机构和国际系统工程理事会（INCOSE）等各种组织推广了20多年。尽管需求工程越来越成熟，但对它的理解和实现却常常很差。仅仅产生大量的详细需求并不能保证良好的项目性能。Fanmuy等人（2011）对工业需求工程实践的研究表明，一个常见的问题是需求通常是用自然语言编写的，这常常导致歧义和过于复杂的句子。由于在大多数情况下需要管理成千上万的需求，因此仅通过人工视觉审查来获得需求的一致性和完整性仍然很困难。图1列出了需求中的典型缺陷。从图中可以看出，许多设计师甚至不清楚需求和解决方案之间的区别。

图1.需求中最常见的缺陷(改编自Fanmuy等人)。2011年)。

对这些问题的潜在解释包括缺乏信息、持续变化以及规范阶段的抽象性和多学科性。即使在存在重大不确定性的情况下，工程师也倾向于从技术解决方案的角度来考虑，而不是考虑用户实际需要什么。收集和描述需求并使之保持最新的术语、工作方法和工具通常是模糊的。从高层次的需求到抽象的系统功能，最后再到它们的技术实现，开发路径可能不是系统的，也不是文档化的。由于缺乏设计可追溯性，很难确保需求在最终实现中得到满足。在过程控制中，早期阶段和输入信息的收集也被认为是重要的和具有挑战性的。然而，需求工程并不是一个专门的设计领域。例如，在合同文件中可以看到明确的需求，但工程师编写的规范往往侧重于技术问题。安全关键应用由监管机构控制。这就强调了需求工程的重要性。不幸的是，安全标准并没有给出很多实际的建议(Tommila等人)。2011年)。 该出版物的主要目的是促进系统系统工程(SE)和需求工程(RE)在核电厂(NPP)的设计、建造和维护方面的实践。我们的重点是在设计阶段，特别是监测和控制安全关键的过程和系统的核电厂。除了仪器和控制(I&C)系统外，我们还将考虑来自受控设备和人工操作员的需求。我们的研究方法基于以下几点：

• 要求是关于申请中遇到的实体特征的陈述。因此，不能脱离其他工程活动和系统模型来讨论需求。即使是需求和设计解决方案之间的界限也并不总是清晰的。从本质上说，RE是一项涉及多个利益相关者的多学科活动.因此，技术系统，例如I&C系统，应在其背景下被视为包括技术和人的因素在内的更大的、封闭的系统的一部分。
• 由于复杂系统中大量的需求和它们的依赖关系，以及在整个系统生命周期中修改和维护它们的需要，未来将需要计算机工具。此外，这些工具应与其他工程环境相结合。
• 为了成功地在各个涉众和工程学科之间进行沟通和协作，需要定义明确的术语。对于计算机工具和设计信息的电子交换，一个词汇表是不够的，但也需要正式和标准化的数据模型(本体)。
• 特别是，必须有明确的术语作为设计做法的基础，这是本报告背后的原因。这份报告提出了一套适合于NPP领域的建模概念、它们的性质和关系的定义，称为“概念模型”。概念模型的某些方面似乎相当理论性，但其理论依据来自于未来对计算机工具的需求。因此，我们的概念模型并不涉及真实世界中存在的哲学问题。相反，它试图定义可用于描述当前和未来世界的模型元素(设计数据库中的信息项)。为了支持当前的实践，附录B中的术语表给出了关键术语的常识定义。它们旨在促进工业专业人员之间的相互了解。此外，它们也是今后设计指导和工具开发的基础。

本文件分为两个主要部分。第一部分非正式地讨论了设计和系统建模的基本原则，包括一般的需求工程、系统的物理结构和行为、系统-生命周期、“需求”的含义和表示以及设计信息的可追溯性。第二部分代表了一个更实用的信息模型，为该行业的工具开发提供了基础。

第一部分-关于系统建模的原则

实现高质量需求和系统工程的最快途径是改进工作实践和培训设计师。我们在这里声称，对于系统和总体设计的共同的和逻辑的思考方式应该作为首要目标，而成功地引入计算机工具只有在它之上才有可能。本文第一部分的目的是简要介绍需求工程，并描述模拟人造系统及其生命周期的一些基本问题。第二部分提出了一个更结构化的信息模型。

2.需求工程基础

正如INCOSE(2007)所描述的那样，系统工程(SE)是一种跨学科的方法和手段，能够实现成功的系统。Se是一个迭代过程，它同时关注整个人工系统的社会和技术方面。在专注于工程设计的同时，系统工程还包括管理过程和与项目管理(PM)行业的重叠。SE的技术流程包括，例如，需求定义和分析，以及设计解决方案的验证和验证(ISO/IEC/IEEE 15288,2015年，INCOSE，2007年)。因此，需求工程是系统工程的重要组成部分。

2.1需求是什么？

根据许多标准和教科书，需求是一个系统或系统要素必须满足或拥有的条件或能力，以满足合同、标准、规格或其他正式施加的文件。需求是利益相关者(例如客户或用户)关于产品或其开发过程的陈述。一个需求通常由另一个利益相关者实现，例如由供应商或设计师实现。因此，需求基本上涉及到工程项目中涉众之间的沟通。这条通信链从客户一直延续到程序员和安装技术人员。一个步骤的输出可视为下一个步骤的需求。然而，这些材料的一部分并不是实际的需求，而是已经做出的问题、事实和设计决策。这使得很难准确地定义需求一词--需求和设计解决方案之间的区别并不总是很清楚。

例如，一项要求可能涉及整个社会技术系统，如工业装置、过程控制系统或其单一组成部分。因此，不应该孤立地对待需求，而应该将其附加到“集成系统模型”中。换句话说，需求可以看作是系统的一个方面。在一开始，只有一个新系统的想法可能是可用的，高层次的需求是附加到它。当细节添加到系统模型中时，可以将更精确的需求附加到它们。细化的需求是从更高层次的需求中派生出来的，例如，通过分解它们或将它们分配给已知的系统元素。其他信息源，如标准和领域经验，在这里是必不可少的。然而，这种需求的向下流动不仅是自顶向下的，而且现有的实现或选定的解决方案可以导致不同层次的需求之间的迭代。因此，一个社会技术系统的模型包括一个层次化的需求网络，这些需求在不同的分解层次上附加到系统元素上（图2）。需求之间的可追溯关系，以及所有其他类型的模型元素，允许人们解释决策背后的原理，跟踪以前版本的链，并在需求必须修改时识别受影响的模型元素。如果没有这种可追溯性，就几乎不可能给出一个可靠的论据来证明已经满足了要求，例如控制系统是安全的。

图2.对工厂层次结构中各个元素的需求（Tommila等，2011）。

需求可以根据几个标准进行分类。其中最常见的是功能需求和非功能需求之间的区别。一个功能需求指定系统应该做什么，例如系统必须能够提供的服务，而不考虑其实现。一个非功能性需求描述，例如，系统结构，或告诉如何良好的系统表现，即它的预期性质，如准确性，响应时间，可用性，可维护性和可靠性。此外，可以根据它们所代表的利益来识别不同的需求类型。利益相关者需求在系统的操作环境中查看系统，并指定涉众想要做什么而不涉及任何技术细节。例如，业务需求、用户需求和来自监管当局的许多需求都是涉众需求的子类型。系统需求与分配给正在设计的系统的涉众需求相对应。它们通常由工程师指定，并以技术术语重新表述.这些与整个系统有关的需求将进一步分配给软件需求、硬件需求以及与系统的操作和维护相关的需求。系统通常是较大系统的一部分，必须与外部实体(如制造设备、其他计算机系统和人类用户)进行交互。因此，外部接口构成了一种重要的需求类型，取决于它们的内容，可能与系统的行为、实现或性能有关。

应当指出的是，需求不仅可以附在未来的系统上，也可以附在其发展过程中。生命周期需求通常被称为过程需求，例如，在项目和质量计划中。它们可以对设计者的能力和资格提出需求，或限制开发工作的开展方式，例如需求使用某些工具、文档方法或软件开发标准。

不管它的类型如何，一个需求应该保持利益相关者的观点，并给那些负责接下来的步骤的人留出足够的自由。过度指定和过早的需求，例如坚持特定的硬件平台，往往是不必要的设计。约束。有时它们是需要的，例如，当解决办法是在法律和规章中规定或由其他学科决定时。否则，约束可能会阻碍设计人员为用户的需求提供一个好的解决方案。

表1.良好的需求功能(改编自ISO/IEC/IEEE 29148,2011年；Garcia&Flisher，2010年)。

一个好的需求规范是完整的，明确的，内部一致的，结构良好的，可理解的和可追踪的.正如文献中通常建议的那样，良好的需求语句应该具有如下所示的特性：表1。很容易看出，大多数这些特性不仅限于需求，还适用于其他类型的设计工艺品。为了履行其交际功能，所有相关利益相关者的需求都应该是可以理解的，但这取决于细节和预期受众的水平。当用自然语言表达时，描述应该使用简单的结构和简洁的领域特定术语。此外，还可以使用各种更结构化的技术，例如用例、类图、数据流图，甚至形式化方法来澄清所需要的东西。

2.2需求工程是什么？

正如ISO/IEC/IEEE 29148(2011年)所描述的那样，需求工程(RequirementEngineering，RE)是一种跨学科的活动，它在客户和供应商的领域之间进行调解，以建立和维护所利益系统、软件或服务所要满足的需求。这似乎包括需求工程仅限于系统生命周期的早期阶段的想法。然而，需求并不是用户和系统需求的终结，而是可能在所有设计步骤中出现的细节。因此，生命周期包括有需求的多个“客户”链和为这些需求提供解决方案的“供应商”。此外，需求可能会发生变化，并且在系统运行期间也必须进行维护。Re是一个迭代过程，它涵盖了系统的整个生命周期，并且与其他工程活动密切相关。因此，准确地定义RE中发生的内容是很困难的。

图3.需求工程的主要活动。

我们认为RE是整个设计过程中的一个“学科”和活动线。Re定义需求并将它们附加到正在开发的系统的共享模型上。这里分为两个主要的活动，需求定义和需求管理(图3)。需求定义包括发现、分析、记录(建模)以及验证和验证需求。分析包括谈判和优先排序过程，这些过程将导致一组商定的需求。需求定义还包括维护需求的可跟踪性。反过来，需求管理也可以看作是配置管理，例如，应用于需求的标识、可跟踪性评估和更改控制。总之，RE是一个工程过程，它产生一组一致的需求，然后在许多其他活动中使用，例如详细的设计和测试计划(图4)。另一方面，质量管理和项目管理是指导和监督项目组织工作的组织过程。质量管理组织尤其应独立于设计人员。

图4.需求工程生成并维护了需求，但将其用于许多其他生命周期活动（从Raatikainen等人2011年修改而来）。

通常，设计应该以自上而下的方式进行，尽管迭代是必需的，但如今，例如在敏捷软件开发中，甚至还需要迭代。根据上一节中概述的要求级别，建模应从集成的社会技术系统（如加工厂）开始。该总体模型有时称为操作概念（ConOps）（IEEE Std 1362 1998，INCOSE 2007，ISO / IEC / IEEE 29148 2011），描述了主要元素协作以实现其共同目标的方式（有关更多信息，请参见Tommila et al.2013）。 ConOps的元素提供了利益相关者需求可以附加到的结构。它还为系统要求提供了一个固定点。此后，该模型随具有附加要求的子系统，软件，硬件等一起增长。添加更多详细信息时，需求会以更多技术形式分配给较低级别​​的系统元素。在此分配和向下流动过程中，必须考虑需求的可追溯性。

定义需求始于引起利益相关者的意图（称为需求，目标或目的）。最初的利益相关者意图不能作为利益相关者的要求，因为它们通常缺乏明确的定义，一致性和可行性（ISO / IEC / IEEE 29148 2011）。通过需求分析，在成为有效的利益相关者需求之前，意图就变得更加清晰。需求建模，需求验证和验证以及需求管理是RE中的连续活动。需要记录需求，以实现与利益相关者的沟通以及系统的未来维护。描述需求之间的关系也是需求文档的一部分。需求验证试图确认需求是正确的，即，它们符合真实的用户需求或与其他称为“良好”的参考点相对应。需求验证确认需求是完整且一致的，并且已正确地从更高级别的需求，标准，法规和其他源信息中得出。需求管理，尤其是检查可追溯性，应该与需求定义并行进行，而不是随后作为单独的任务进行。

3.系统建模原则

本章的目的是以非正式的方式介绍我们对工厂及其I&C系统的基本理解。下面的前两节讨论了系统的本质及其模型。其次，第3.3和3.4节讨论了系统的结构和功能方面。第二部分将提出一种更有条理的建模方法。

正如ISO/IEC/IEEE 42010(2011年)所强调的那样，可以从多个角度来看待系统架构。换句话说，与系统有关的所有信息，即系统模型应该组织得很好。在我们的例子中，系统模型包括各种“抽象级别”，如

• 目标：此图片涵盖了总体目标和局限性
• 行为：系统的操作场景和功能，包括系统处理的信息项（和其他工件）
• 结构：系统的物理元素的组成
• 布局：将系统元素放置在操作环境中

其次，不仅要考虑系统本身，还要考虑系统的生命周期和环境.在需求定义和概念设计中，外部系统接口和内部体系结构是最重要的描述层次。这将导致以下基本的“视点”

系统

1. O环境中的系统：系统如何在其环境中与外部实体交互
2. 体系结构：系统和交互的主要元素和功能是什么？

生命周期

1. 工程：系统将如何开发(项目)
2. O&M：系统将如何操作和维护(设计解决方案的一部分)

这些“视点”和“抽象级别”是定义“系统描述矩阵”的独立维度，如表2下面。这里的信息是，项目组织也可以被看作是一个系统，我们需要一对相互关联的模型：系统模型和项目模型。。此外，如何使用和维护系统是设计解决方案的一部分。而不仅仅是一些事后可以添加的东西。

表2.系统和生命周期模型的整体组织。

3.1什么是系统？

从共同的角度来说，系统是一组相互作用的元素组成一个完整的整体。一个系统，如一个人类观察者所看到的，有一个边界，系统通常与它的环境相互作用。一个系统可以是抽象的(例如在数学中)，也可以是具体的，可以在现实世界中观察到(例如自然、社会和技术系统)。我们在这里最利益的是人为的、有意构建的系统，这些系统通常同时具有技术和人的元素。换句话说，我们谈论的是社会技术系统。人为造成的一个重要后果是，一个系统具有与外部世界的目的和接口。该系统旨在完成特定的任务，并在指定的操作中达到一定的目标。语境。这一系统环境通常包括人类组织、其他技术系统和环境的相关物理、社会和文化方面。语境也受空间特征的影响。运行环境由系统元件所在的区域、建筑物和构筑物提供。在设计新系统时必须考虑到这些因素。

我们可以在这里使用iso/iec/ieee 15288(2015年)中给出的定义，并说系统是相互作用的组合系统要素为了达到一个或多个明确的目的而组织起来的。系统要素可以是设备、结构、软件、数据、人、程序(例如操作人员指令)、材料和自然存在的实体(如水、生物、矿物)或任何组合。不同于ISO/IEC/IEEE 15288，我们将“进程”从系统元素类型列表中排除在外。这是因为我们认为系统是物理的(虽然不是在现实世界中存在的实体1。事件和事件发生并可以在现实世界中被观察到，但仅仅是物理系统元素所产生的行为。特别是，人类既可被视为用户，也可视为系统的要素。图5显示正在发展中的系统，即“利益系统”，在其更广泛的范围内。系统上下文。它由系统元素、处理工作项和与各种外部实体交互组成。

图5.与所设计的系统有关的基本实体的示例。 一个系统由系统元素组成，并与一个较大的封闭系统的外部元素交互，所有这些元素均位于运行环境中。 广泛的系统环境还涵盖商业环境，文化问题等。

环境与环境之间的清晰界限利益系统设计师在系统模型中的考虑是重要的，无论是在原则上还是在设计组织的责任方面。然而，边界是一个商定的问题，取决于观察员的观点。一个人的利益体系可以看作是另一个人利益体系中的一个系统要素(iso/iec/ieee 15288,2015年)。因此，不同的系统利益在原则上可以重叠。然而，在许多领域，例如在核能领域，清洁的树状分解层次结构是首选的。作为一个例子，从iso/iec/ieee 15288改编而来的系统层次结构用一个非正式的图表在图6。系统分解由两种系统元素类型建模：复合元素。系统(制度-)

1在形式本体论中，这类实体常被称为持久体或连续体。它们在任何时候都可以被看作是完整的实体。例子包括物质对象，也包括抽象对象，如组织或计算机软件。由耐力产生的“事件”被称为持续性或事件，例如具有非零持续时间的事故。在给定的时间点，我们只能看到耐久物的一部分。

兴趣本身是它的特例)和原子元素元件它不会被进一步分解，而是被视为具有指定接口的黑匣子。请注意，除了政治和文化问题之外，系统上下文还包括可以用(外部)系统元素来描述的外部系统。

图6.将利益系统分解为子系统和原子组件，这些子系统和原子组件可以使用适当的产品类型来实现。

可重用的子系统和商业组件可以作为产品发布。在工业应用中，本文的主要主题是系统的组件，甚至更大的部分，通常都是作为商用的货架(Cots)产品获得的。例如，核工业的标准反应堆设计可视为产品。此外，整个子系统的开发常常分配给投资项目中的分包商。从开发人员的角度来看，系统元素是一个利益系统(图6)然后，可以将其规范或数据的相关部分集成到主承包商的总体设计存储库中，例如，作为一个文档，产品类型在类型库中或作为设计数据库的一部分。系统元素是指产品类型并由产品个体当系统实际构建并安装在其运行环境中时。我们在这里关注设计数据，但跟踪个人也很重要，例如，在系统运行期间的维护和配置管理中。还要注意的是，内部开发的子系统(在利益系统所有者那里)也可以被看作是产品类型。这有助于一致的模型集成，而不管子系统的供应商和设计的重用，例如在冗余系统元素的情况下。

根据定义，系统元素相互作用，并与外部实体交互。这通常是通过交换材料、能量、力量或信息来实现的。有些流动是连续的，例如热水在集中供热网络中流动。离散流由工作项目，G.

计算机网络中的数据包，在系统元素之间移动。无论如何，需要一种机制来使交互发生。例如，在工艺系统中，需要管道在工艺部件之间输送液体和气体。在控制系统中，铜线携带基本的测量信号，网络组件在控制器之间传递消息。描述系统连接性的最常见方法是定义系统元素的端口或终端，并将它们与连接“连接”在一起。然而，也存在其他交互模式。特别是在计算机系统中，具有请求和回复信息的消息广播和服务得到了广泛的应用。交互也可以是间接的，甚至是无意的，并且由第三个实体来调解，例如两个软件组件使用的共享内存位置。因此，相互作用与系统行为有关，但可能是由物理系统元素造成的。因此，需要在两个抽象级别上考虑接口和连接性，如图7.

图7.连接对于控制系统功能和执行这些功能的物理设备都至关重要。

3.2什么是系统模型？

工程师的主要工作是提供图纸、文件和说明，根据这些图纸、文件和说明，可以购买、建造、安装、操作和维护系统。工程师需要开发该系统的“模型”。例如，iso/iec/ieee 42010(2011年)定义了一个模型如下：“如果M可以用来回答关于S的问题，M是S的模型。”原则上，模型是任何能够描述系统的东西，例如文字描述、图形、数学公式、仿真模型、模拟模型、视觉模型或虚拟原型。在这个意义上，为指定或描述系统而创建的各种典型的工程工作产品(人工制品)都是模型。

传统上，设计数据最初是以图纸和书面文档的形式创建的。今天，设计信息最好是以一种结构良好的电子形式来进行开发、存储、处理和计算机传输。一般来说，设计越来越多地由模型驱动。例如，在模型驱动的软件开发(MDSD)中，只有模型被创建和维护，实现，例如应用软件，由模型自动生成(见Stahl&V lter 2005)。正如INCOSE所定义的，“基于模型的系统工程(MBSE)是建模的正式应用，用于支持系统需求、设计、分析、验证和验证，从概念设计阶段开始，并在整个开发和以后的生命周期阶段持续进行”(Friedentalet Al)。(2007年)。这并不意味着不使用文档，而是意味着MBSE不是基于在文件上。因此，文档的作用发生了变化：在MBSE中，文档是一种表示信息的手段，而不是信息的容器。这一事实鼓励使用自动或半自动的文档生成，这在传统SE中是不可能的.系统元素及其环境的需求、物理体系结构和行为以及它们之间的关系可以建模(见图8)。INCOSE列出了MBSE所提供的几个好处。(2007年)：清晰明确地表述了概念，改进了利益相关者之间的沟通，并提高了Ena管理复杂性的能力

从多个角度来看待一个系统模型，增强的知识获取、学习和重用信息精确系统模型可以被评估为一致性、正确性和完整性，自动或半自动文档生成。

这些也是NPP系统工程的重要方面。MBSE对目前的NPP发展并不陌生。例如，系统建模语言SysML一直是核部门利益的领域之一(例如，Pihlanko，2013年)。然而，要充分利用MBSE的好处，仍然需要与更正式的模型一起工作的实践和工具。

图8.在基于模型的系统设计中，设计人员的工作产品是以系统的方式组织的。

传统的基于文档的设计和成熟的基于模型的系统工程(MBSE)可以看作是规模的两个极端。在本文中，我们更喜欢中间的“数据”。面向基的方法，其中设计存储库既可以包含传统文档，也可以包含结构化文档。模型例如，存储在关系数据库或XML文件中。在这里，我们期望模型部分基于域的一个良好的概念模型，以便它可以被计算机工具处理，例如用于进行各种检查和生成人类可读的文档。

图9.系统模型的元素描述了现实世界实体的相关方面。

应区分模型和系统元素本身。在下面我们集中讨论模型元素，也就是可以用来描述现实世界实体的设计信息片段(图9)。一般来说，我们说系统模型由模型元素它代表了实际系统的相关方面。，见图10。由于需要传统文档来补充结构化系统模型，我们也使用了这个术语。工程工艺品涵盖设计组织产生的所有信息，即文档和模型元素。

为了涵盖系统的所有必要方面，我们需要几种类型的模型元素来描述系统的目标、结构、特性和行为。一些模型元素，如功能，是抽象的，在现实世界中没有直接的对应物。除了技术内容之外，模型元素还包括与系统生命周期(元数据)相关的信息，例如版本、修改日期、作者和验收状态。特别是，模型元素应该具有允许对其进行引用的标识符。模型元素的粒度各不相同。例如，最小的模型元素可能只包含一个属性值或一个需求，而另一些则包含大量信息，可能以许多低级模型元素的形式存在。为了便于设计信息的管理，将小模型元素分组为配置项的行动配置管理。而且信息包(2006年NIST采用的术语)是将模型要素转化为在不同项目参与方之间交换(电子)设计数据的适当格式的集合。传统的文档可以理解为已转化为人类可读形式的信息包。

图10.系统模型的元素表示现实世界中存在的系统。

3.3系统的物理结构

一个系统的结构可以理解为它的元素的排列。要描述它，工程师应该指定：系统的元素，元素是如何相互关联的，元素所在的位置。

下文讨论了这些问题。例如，对系统结构的实际说明还应包括每个要素的目的和形式。

3.3.1系统要素

我们的系统不是抽象的，而是由现实世界中存在或将要存在的具体(物理)元素组成的。它们可以是物化对象，如人和计算机硬件或信息，如配置数据或运行在计算机上的软件。我们将系统视为具有可用于执行活动的功能的资源。这些现实世界系统的其他值得注意的特点包括：

系统包括一组从属系统元素。通常，利益系统本身就是一个更大的封闭系统的一部分。系统元素之间有层次关系和其他关系。

特定系统、其边界、体系结构和系统元素的感知和定义取决于观察者的兴趣和责任(ISO/IECTR 24748-1 2010年)。这有几个后果：

1. 分解一个复杂系统的方法不止一种。
2. 在一般情况下，系统元素可以是多个系统的一部分。
3. O任何层次的分解中的实体都可以被看作是一个系统。

系统的元素可能会随着时间的推移而改变，而不会失去系统的身份。因此，系统的元素可以理解为实际组件个体的位置持有者，在许多情况下，这些个体是商业产品或设备类型的实例化，并且具有制造商的序列号。例如，图11显示了一个功能泵对象P 101。它不同于最初安装为P 101的个别“泵1”，后来被备件项目“泵2”所取代。包含时间维度不仅对设计和系统建模很有用，而且对于系统操作期间的配置管理和可跟踪性也很有用。

贯穿于利益系统的整个生命周期，需要外部系统提供服务，例如培训或维护系统。称为使能系统，它们促进了整个生命周期利益系统的发展(iso/IEC/ieee 15288,2015年)。

人类组织甚至可以被设想为自己的系统。在今天的网络化制造中，这些组织可以超越公司(Oedewald，2011)和流程工厂的界限。此外，项目组织，通常是一个组织网络，进行投资项目也是一个系统。

进一步的问题是，系统处理的工作项(例如数据或材料)是否是系统本身的一部分。就像系统边界取决于所采取的观点一样，答案可能是肯定的，也可能是否定的。但是，一般来说，我们认为工作项通过系统而不是它的组件。尽管如此，仍有必要在工程过程中描述工作项及其属性。

图11.在过程工厂的整个生命周期中，几个产品人员可以在三维空间中使用功能泵对象P101（ISO 15926-2 2003，西部2011）。

图12展示了一个简单的图表来说明关键的想法。首先，一个系统的目的是单独或与其他系统一起开展一项或多项活动。这是目的设计器定义的系统。第二，系统由两种类型的系统元素组成。任何一个系统元素都是一个复合对象，即它自身的一个“子系统”。或者，系统元素是一个组件，从观察者的角度来看，并不关注组件的内部结构。因此，组件表示分解树的叶节点。组件可以分为几个子类型，如人员、设备、软件和信息。设备，如泵和仪器，通常是机械部件，但也可能包括嵌入式软件。结构通常被定义为被动成分。然而，他们也可以执行一个功能，今天甚至包括活跃的部分和软件。因此，分类并不是排他性的。如上所述，系统边界取决于观点。系统中包含的组件类型为整个系统的分类提供了基础。组织单位组成主要关于人的，过程系统加工设备，结构结构元素等等。社会技术系统将各种部件组合在一起。

图12.系统用途和分解，以及系统和组件类型的示例。

3.3.2系统和系统元素的连通性

为了履行其预定的功能，物理系统要素必须通过交换材料、能量和信息相互作用。例如，在SysML(OMG 2010)中使用的一种通用方法来建模这些交互，就是定义港口或接收并生成各种类型工作项的终端。在系统元素上指定端口的主要动机是允许设计具有明确定义接口的可重用块。

在本文中，我们明确区分了系统的物理结构和行为。物理系统要素根据系统功能。这也意味着必须区分系统元素之间的连接和系统功能之间的连接。系统的物理组件实现了系统功能之间的流程。因此，构成物理连接的组件也可以理解为系统元素。类似地，连接两个系统功能的流可以在更详细的视图中描述为自己的功能。因此，在物理系统结构模型中，系统元件有管道喷嘴和螺旋端子等端口，这些端口由连接部件(如管道和电缆)连接。但是，请注意，系统元素可以相互作用，例如通过传热过程，而不需要为此目的设计物理端口和连接。然后在功能模型中考虑交互作用。第3.4.3节将进一步讨论系统功能的连通性。

3.3.3空间和地点

系统和人需要一个合适的行动环境，即地理区域、场地区域和建筑物，以有效地开展工作。操作环境的属性是输入信息的一部分，是对系统设计的约束。另一方面，系统设计中的决策对系统的运行环境提出了更高的需求。因此，采纳建筑业的一些想法是有意义的。特别是，建筑部门的工业基础类(IFC)是建筑信息建模(BIM)数据的开放规范，在建筑施工或设施管理项目(IFC，2011)的不同参与者之间进行交换和共享。

图13说明了主要的泛型概念。遵循国际金融公司的术语，建筑元素是建筑物的主要部分。它们是有形的、有形的东西，如墙壁、横梁或门。在核电站里，安全壳就是一个很好的例子。一个空间表示用于提供某些功能的区域(2D)或卷(3D)。一个空间可以分解成几个部分。它可以有各种属性，如所需的设计温度、湿度、通风和空调。空间通常被像墙这样的建筑结构元素所包围。空间边界也几乎可以根据结构元素来定义。例如，爆炸性大气或核辐射的可能性可能需要在危险部件周围宣布一个分类空间。系统和系统元素可以放置在一个空间中，因此它们是“包含”的。这个位置系统元素被理解为系统元素与空间之间的关系。换句话说，它是系统元素的(可能是动态的)属性。除了建筑单元和空间外，工业系统还需要各种支撑结构，如用于加工设备的缆索托盘和钢框架，它们可以安装在这些结构上。有时，例如在计算机机柜中，这些NPP结构也可视为NPP系统的组成部分。

图13.操作环境的元素。

3.4系统行为

我们在上面说过系统都是为了某种目的而设计的，通常是为了做某事。因此，除了物理结构之外，行为也是系统的一个重要方面。为了描述发生了什么，我们需要(至少)以下概念：

• 活动：需要做什么，例如生产电力
• 系统功能：系统可以做什么，例如测量反应堆压力
• 运行状态：系统的可预见状态，例如冷关闭
• 运行模式：执行系统功能的可选方式，例如手动或自动
• 事件：事件：状态发生短暂变化
• 方案：状态，事件和动作序列的示例

3.4.1活动

一般来说，一项活动是发生或改变的事情。在我们的例子中，活动被用来描述目标导向的代理的预期行为，例如人类组织或技术系统。活动是指某种需要并且应该以某种方式完成的事情。因此，活动与“过程”一词密切相关。例如，在工艺设计早期开发的一个框图(ISO 10628 1997)描述了流程工厂应该如何处理原材料。在这一阶段，工艺设备的细节可能还不清楚。

我们可以使用旧的功能建模标准IDEF 0(1993)来描述活动。活动被建模为一个框，如图14。进入左侧的箭头是活动消耗以在右侧产生输出的输入。顶部的箭头是活动产生正确输出所需的条件(如启用信号)的控制。连接到底部的机制箭头表示用于执行活动的手段，即资源和技术。

每个活动都可以按层次结构分解为较低级别的活动以及它们之间的物质，能量和信息流。 具有有限范围和持续时间的明确定义的活动可以称为通常与人类用户相关联的任务，但也可以由技术系统执行。 任务又可以由原子动作组成，例如 打开电灯开关。 可以将动作视为事件（请参见第3.4.5节）。 活动，例如 仪器的定期测试，可以执行多次。 因此，区分活动类型（类，例如“启动工厂”）和活动实例是有意义的，这些活动实例具有特定的开始和结束时间（例如，“ 11月11日启动”）。

图14. IDEF0活动框。

活动的输入和输出通常是物质，能量或信息。 更一般而言，活动会产生，维持或有时阻止某些事务状态，例如 燃料装进 25 反应堆”。 例如，控制箭头可以理解为目标或激活命令。 该机制的有趣特征是它将活动链接到资源，例如资源。 处理设备或用于执行此操作的人员。 我们说系统具有的功能可以根据其结构，行为和属性而用于各种目的。

3.4.2系统功能

“功能”一词在各个学科中有许多含义。在工程中，功能是一个基本的概念，无论是设计系统具有所需的属性，还是诊断系统为什么不能按预期工作。然而，这个词一直是无休止的讨论和定义尝试的来源(Chandrasekaran&Josephson，2000年)。尽管如此，我们仍试图在工业自动化的背景下找到一种有用的解释。

在工程设计中，将这一术语应用于以执行任务为目的的系统的一般输入/输出关系是有用的(Pahl&Beitz 1996，第31页)。功能是技术系统的一个属性，并描述了它的实现某一目标的能力(Hubka&Eder 1988，第72页)。很明显，一个系统可以服务于多个目的，因此也具有多个功能。

工程系统，如汽车、房屋和计算机，是用来执行一个功能的。，正是这个功能定义了它们。螺丝起子仍然是螺丝刀，即使新的螺丝刀用于驱动螺钉，但只用于打开油漆罐(West 2011，第152页)。因此，用户在给定情况下的意图可能与设计人员在她/他心目中的使用不同。IEC 81346-1(2007年，第14页)指出，技术系统的组成部分是过程的动态活动的静态先决条件。“功能”是指物体的任务，例如“用于加热液体的物体”，而不考虑其实现情况。

因此，功能的概念从行为的概念开始，但是(不同于自然系统)，它的区别在于某些代理人认为它是可取的(Chandrasekaran&Josephson，2000)。一些来源将功能与用户的目标联系在一起，另一些人似乎认为系统和功能是相同的。正如Chandrasekaran&Josephson(2000)所述，功能可以从以设备为中心或以环境为中心的观点来描述。前者从系统的角度描述所期望的行为，而后者则强调对外部实体的预期影响。

注：“目的”一词也可以有两种解释，一种是从用户的角度，另一种是从设计者的角度。例如，用户可能会说，对他来说，螺丝刀的目的是打开一罐油漆。设计师可能会说，它的目的是驱动螺丝。

为了为系统建模提供坚实的基础，我们需要赋予功能一词更具体的含义。为此，我们定义了系统功能作为系统做有用事情的能力。有了这个定义，目的系统是指开发人员设计或最终用户使用的活动或目标。功能在这里引用模型单元描述系统的能力及其内部逻辑(例如规则或算法)图15)。视情况而定，系统功能，如温度控制回路或启动序列，通常能够产生系统所需的许多行为。在系统模型中，系统功能可以表示为需求(“应具有温度控制回路”)或规范(功能框图)，该规范(功能框图)后来作为控制系统中的应用软件(软件组件)实现。

图15.系统具有可用于执行活动的系统功能。

在许多情况下，系统被设计成通过与外部世界交换物质、能量或信息来积极干预外部世界。然而，这并不是全部事实。例如，Lind(2005)以Georg Henrik von Wright的研究为基础，列出了一个系统可以做的一套有限的原始(主动)干预。首先，系统可以通过改变世界的状态产生一个新的事件状态。其次，它可以维持现状。通过考虑对事态的否定，我们又有了两项干预，以破坏和防止事态。此外，考虑到积极干预的负面影响，即疏漏，会导致另外四种让事情发生的方式。不对警报作出反应可以认为是控制室操作员的一种行为。特别是，维护和预防事件状态完美的匹配于 工业工厂期望的各种结构。例如，建筑的梁和柱被设计成在一个固定的位置上支持其他建筑构件。这使我们得出结论:被动结构也有功能。以核领域为例，核电站内的密封装置应能够防止(任何种类的)材料泄漏到环境中。“把材料留在里面”是容器的功能。根据之前所说的，
隔离的目的是促进称为“放射性材料隔离”的安全功能。

大系统的系统功能可以分解为“子功能”，然后分配给它的子系统(图16)。有几种选择。首先，可以将系统级功能分配给一个子系统.在这种情况下，模型元素“功能”可以与系统和子系统相关联。或者可以使用两个模型元素，例如，系统级功能被解释为需求，更详细的功能作为规范。其次，可以将系统级功能分配给多个子系统.在这种情况下，子系统必须以某种方式交互。例如，为功能执行不同部分的子系统必须交换信息。或者，一个系统元素所执行的操作可以利用另一个系统元素提供的功能，例如通过调用一个子例程或激活一个功能。此外，执行相同功能的冗余子系统必须通过切换或投票功能进行协调。这意味着系统级的功能和子系统级的功能通常不是一回事，必须用单独的模型元素建模。

如图15，活动通常代表与更大的、封闭的系统相关联的需求。例如，活动告诉我们，发电厂必须设计成发电。另一方面，系统功能通常描述发电厂系统，例如I&C系统向其“客户”提供的“服务”。为此，需要定义较低级别的内部子功能.

图16.系统级功能是通过分配给子系统及其组件的功能的各种组合来实现的。

因此，功能在这里被理解为系统的特性，而活动不一定与任何资源相关联。在设计时，可能不知道将使用什么特定系统来执行活动。然而，活动的特点和需求决定了可以使用的资源类型。同样，系统的设计者及其功能可能不知道系统将用于哪些活动。这种情况是典型的，例如，在批量化学加工中，配方对应于与工艺单元有关的程序控制职能所执行的生产活动。但是，并不总是清楚功能应该建模为活动还是功能。例如，核电站的安全功能可以看作是一种活动，或者是一种工厂级的功能。这些主要的安全功能然后通过安全功能或各种工厂系统的组合来实现。

如前所述，系统表现某些行为的能力可以定义为系统功能。在I&C系统中，这通常意味着控制和测量回路。首先，功能是以独立于实现的方式指定的。然而，可用的技术可能会对规范的语义产生影响。例如，在可编程控制系统中，功能通常作为周期性执行的软件组件来实现。这与旧的模拟解中的连续模型有很大的不同。

本文重点介绍了基本的过程控制系统，其中最重要的是控制回路、联锁和保护功能。控制应用程序的行为是按照广泛应用于基本过程控制系统开发中的“功能块范式”建模的。图17)。功能块通常被理解为面向应用程序的编程语言的元素(例如iec 61131-3)。因此，我们在这里使用这个术语I&C功能(iec 61513,2011年)当提到独立于实现的输入数据流(信号)到输出的转换时。因此，I&C功能表示对I&C系统的面向应用的视图.大多数I&C功能被认为是循环执行的。它们表示连续的控制功能，例如控制反应的压力。但是，功能也可以描述顺序活动和状态机。

图17. I＆C网络用作功能框图（FBD）。

3.4.3系统功能的连通性

设计人员使用系统功能，以结构化的方式描述系统如何交换和处理材料、能量和信息。每个功能都接受某些输入，并将其转换为输出，供其他功能使用。就像功能本身一样，功能之间的流动可以理解为连续的(管道中的蒸汽)或离散的(转移线上的工件)。如上文第3.1节所述，经常需要有形资源，例如通讯网络，才能进行转移。因此，流也可以看作是功能。有几种机制来实现流，并将这些功能连接起来。特别是在基于计算机的系统模型中，流被认为是离散的。信息项目表示信号值、命令、警报、服务请求等。图18，数字技术支持在平台无关的功能规范中已经可见的几个交互拓扑。我们将重点放在基本的I&C功能和功能块范例上，将讨论限制在可以使用或产生某些信息项的连接端口上。在典型情况下，语义是通过链接“连续”传输数据。对于传统的硬连线解决方案来说，这是正确的，但是在数字系统中，数据交换实际上是周期性地进行的，或者是由值的变化触发的。设计人员可能需要了解技术问题，如允许的最大延迟、循环时间和数据通信的可靠性，以及分配给不同控制器的功能的同步。此外，在数字I&C系统中还发现了其他类型的连接。

特别是，警报处理是向利益的订阅者分发事件通知的一个示例。在高级信息系统中，可以根据请求和回复消息(即系统功能提供和需要的服务)对交互进行建模。原则上，消息传递和服务也可以用不同类型的端口建模。

图18.数字系统中交互机制的示例（Tommila等，2005）。

3.4.4状态和模式

需要进一步观察的是，系统可以处于各种状态。在系统理论中，系统具有由状态变量定义的非常大或无限的状态空间。这对于设计工作来说不是很实际。为了对相关替代方案进行建模，我们使用术语“运行状态”，它可以理解为系统状态空间中的区域。它们被视为设计师和工厂人员达成的协议。通常，系统的运行状态是由控制系统声明或强制执行的，而不是由过程变量的当前值和过去值来推断的。某些运行状态是固定的，其设计意图是保持稳定的过程条件。瞬态的目的，例如工厂关闭是将系统从一种运行状态转移到另一种运行状态。因此，它们通常具有顺序特征。系统功能的可用性和性能级别取决于当前的操作状态。例如，发电厂可以具有“维护中”，“启动”和“电源运行”等运行状态（图19）。操作状态由瞬时事件和状态转换连接，因此使我们可以将行为描述为状态图。

图19.核电厂的运行状态

运行状态可以与处于不同分解水平的系统相关联，例如与整个发电厂或其每个子系统相关联。因此，每个操作状态都可以用较低级别子系统的状态来定义.此外，操作状态可能具有与同一设备实体相关联但在不同时间段内有效的子状态。这将导致分层状态图。例如，UML状态图引入分层嵌套状态。

图20.自动手动模式的状态和状态转换（NORSOK I-005 2005）。

操作状态确定什么在某些情况下，一个系统是有能力的，或者应该这样做的。概念运行模式定义多么该系统执行其功能。在过程控制中，功能通常可以自动或手动执行。模式和转换可以定义为另一个状态机，它控制实际功能(例如PID功能块)的执行方式(图20)。操作状态和模式是组织系统行为描述和确定与各种情况相关的风险和需求的宝贵工具。在某种程度上，状态和模式是应用相关的，但也可以定义更一般的分类法。例如，ISA SP 88委员会和机器自动化和控制组织( Http://www.omac.org )具有自动机器的定义状态和模式(OMAC，2006年；ISA，2013年)。

3.4.5事件

事件被理解为事态的瞬间变化。，或者是持续时间足够短的事件，从建模者的角度来看，这些事件被认为是原子的。例如，达到指定极限的温度或被按下的按钮就是事件的例子。这个想法在这里也被采纳了，即使这个行业中的事件经常被视为特别利益的事件，通常是不幸的事件，例如意外事件。例如，原子能机构术语表(原子能机构2007年)将事件定义为“经营者无意中发生的任何事件，包括操作错误、设备故障或其他事故，以及其他方面的蓄意行动，从保护或安全的角度来看，其后果或潜在后果不容忽视”。原子能机构管理的国际核和辐射事件量表(INES)将事件分为七个级别：1-3级为“事故”，4-7级为“事故”。

事件与行为上文第3.4.1节讨论了这一问题。两者的持续时间都是原子的，但是操作是由活动系统元素(参与者)执行的。例如，对操作员任务的描述可能包括“操作员启动反应堆冷却”的语句。事件还可以表示来自外部世界的观测，并以被动语态加以描述，例如“反应堆温度低于100℃”。因此，操作可以看作是事件的子类。操作的目的也是要对某些外部对象产生影响。正如上面的例子所示，外部对象可能会在一段时间后通过生成一个事件来做出反应。如果可预见的事件和动作被定义为模型元素，它们可以用于描述更复杂的系统行为，例如在顺序I&C功能以及操作状态和操作模式的状态机中，如图20上面。

3.4.6设想

场景是描述(包括期望的和不想要的)事件的故事，以及在系统运行和维护过程中预期会发生的情况。比如测试用例和模拟，场景是可能发生的情况的例子。在系统生命周期内遇到的。因此，它们不一定涵盖所有情况，例如复杂的事件组合。然而，方案对于需求、需求和解决方案的综合、分析和交流非常有用。确定可能的例外和危险将导致新的需求，并有助于使系统更安全。

许多符号可以用来描述场景。基本形式是一个短篇小说。更多的结构可以添加到一个专门的章节和表格形式的故事。例如，在软件和系统工程中，用例是一种指定系统为其用户提供的有用功能单元的方法(OMG，2010)。用例捕获了一个系统的利益相关者之间关于其行为的契约(Cockburn，2001年)。用例是一系列步骤，可能带有描述替代路径的变体，通常定义参与者和系统之间的交互，以实现目标。演员可以是人，也可以是外部系统。因此，用例可以定义一系列特定的场景。另外，一些正常的设计工艺品，如顺序过程和时序图，可以理解为场景，因为它们是潜在的、通常是预期发生的情况的例子。无论如何，场景应该使用格式良好的自然语言和领域和特定应用程序的商定术语。场景说明并验证应用程序的各个参与者(即人员、系统及其功能)如何在各种情况下协作，以便执行设计它们的活动。

图21.自动手动模式的状态和状态转换（NORSOK I-005 2005）。

总结3.4节，图21说明可用于描述系统动态行为的主要模型元素。活动和功能基本上定义系统行为所依据的规则。另一种描述系统的方法是给出有代表性的例子。这种方法，通常被称为“规范的例子”，例如，用于敏捷软件开发，试图避免正式和广泛的文档。示例帮助敏捷团队确保对系统应该做什么有一个共同的理解。实例也可用于规划验收测试。我们使用一般术语假想为了模型单元这描述了一个或多个系统元素操作中的假设但现实的插曲。

4.生命周期建模

开发、运行和维护系统涉及很多活动由不同机构进行(图22)。项目组织可以理解为一种具有结构和行为事件的系统，尽管术语可能有所不同。通常，生命周期模型被理解为系统开发和运行中不同阶段的顺序。有许多众所周知的选择，从瀑布和螺旋模型到各种敏捷方法。根据国际标准化组织/iec/ieee 15288(2015年)的规定，生命周期模型中的细节是根据这些过程、它们的结果、关系和顺序来表达的。我们在这里建议一种扩展的解释，即生命周期模型系统描述

• 要执行的活动
• 目标、输入、输出(例如设计工艺品、信息项目)和活动之间的流动
• 阶段、基线和里程碑
• 参与组织的•角色
• 实践、方法和工具

图22.使用IDEF0表示法的生命周期活动的示例。

生命周期模型可以是应用程序域或产品系列中的通用模型，也可以是特定于开发的模型。工程项目。如上文所示表3工厂周围的高层活动包括设计、(工程、采购和建筑，EPC)、部件制造、安装和操作与维护(O&M)。我们在这里对设计活动更利益，可以使用这个术语。项目模型作为一对系统模型。当与特定于应用程序的数据相结合时，系统生命周期的通用参考模型将成为一个项目模型。系统运行和维护的详细实践是设计解决方案的一部分，因此必须在系统模型的设计阶段指定。

工程活动可以通过多种方式分解为低级活动和任务.最好是在目标和预期成果的基础上进行这一工作。我们说，工程活动创建、维护或管理系统模型的某些部分。考虑由谁来执行这些活动也是合理的。ISO/IEC/IEEE 15288(2015年)建议对系统和软件工程进行一种分解。表3显示了一个简化的版本，可以自由地适应我们的环境。

表3.生命周期活动的例子(改编自ISO/IEC/IEEE 15288,2015年)。

活动和任务的网络相当大。通常需要将相关信息放在一起，以便为跨越多个过程的工程兴趣或线程提供可见性。例如，组件制造商的业务流程可能更侧重于其产品通过制造、安装和维护活动的流程。此外，安全工程师可能对生命周期活动有一个特殊的看法。为此，ISO/IEC/IEEE 15288(附件D)制定了“过程视图”，其中包括指导和建议，说明如何通过利用现有活动和任务来实现成果。图26中用粗行说明的“交付过程”就是这种想法的一个例子。因此，过程视图的概念可以为共同的术语“过程”赋予更具体的含义。

注：在我们的上下文中，过程一词主要与能源生产活动有关，

即在发电厂发生的事情(见ISO 10628,1997年)。然而，在日常语言中，“过程”一词通常指的是加工设备，即加工系统。因此，我们更喜欢谈论活动。当使用“过程”这个词时，应该区分工程过程、业务流程、制造过程等。

当在系统的同一级别上重复相同的活动时，设计方法被称为迭代。当同样的活动应用于系统结构中系统元素的连续级别时，这种方法被称为递归。由于不同的涉众通常从不同的细节级别来看待系统，因此有必要在更详细的层次上定义需求，而不仅仅是整体利益系统。这是通过将系统需求分配给系统元素来实现的。向系统元素分配需求的活动与系统架构的定义并行进行。在设计的某些部分进化之前，某些需求是无法导出的。在需求分析和架构设计之间可能存在多个迭代，以解决需求和体系结构之间的权衡(ISO/IEC/IEEE 29148,2011年)。

因此，在项目过程中对系统描述进行了细化和修正，子系统可能需要自己的设计步骤。迭代和递归可以通过这样的方式进行推广(参见表4):

• 首先有一个未来系统或情况的总体概念(黑匣子)，即某物。
• 事实，问题，威胁，需求和需求以关于其行为，属性等的声明的形式附加在其上。
• 在此知识和其他领域知识的基础上，通过添加更多详细信息来完善系统的功能和结构
• 更高级别的需求分配给了新添加的功能和系统元素
• 在每个阶段，对系统模型进行评估并在必要时进行更正

这种方法允许设计者通过概述“真实系统”的概念开始他们的工作，通常范围很广，例如整个工业工厂，而不是正在设计的控制系统。然后将更抽象的信息，如用户的需求，附加到这个概念中。

表4.系统模型的演化。

仅仅定义生命周期活动是不够的。有效的项目管理需求在某些时间点对进度进行评估，并就指导行动方向作出决定。如图所示图23，系统的生命周期除以里程碑进入连续的、不重叠的时间段，称为生命周期阶段2。活动可以跨越阶段边界，并在迭代设计中执行几次。但是说生命周期“阶段可以重叠”是没有意义的，即使在国际标准(例如iso/iec/ieee 15288和iso/iec tr 24748-1)中也是如此。在这里，我们区分了生命周期阶段和工程活动的实质.因此，我们使用了这个术语生命周期阶段并需求它们是严格顺序的。然而，子系统和相应的子项目的生命周期阶段可以及时转移.每个子项目和设计区域都可以有自己的阶段和里程碑，这些阶段和里程碑必须在整个项目的主要里程碑上同步。

图23.工程活动到生命周期阶段的分布（从Booch等人1999修改）。

图24总结了一些要点。项目的目标是建立一个新的或升级的系统。设计师项目组织参与工程活动创建和修改各种工作项，这里称为“工作区”，包括文档存储库中的部分、系统模型或物理系统的元素。例如，工作区可能包括整个项目、子系统模型或物理系统的制造和组装。围绕每个工作区域的工作被划分为生命周期阶段，每个从一个开始里程碑结束于另一个。里程碑是决策点基线被冻结，活动生命周期阶段声明为已完成，下一个阶段开始。因此，在给定的时间点上，项目正好处于一个生命周期阶段.例如，我们可以说，“既然已经作出投资决定，I&C系统项目就处于基本设计阶段”。换句话说，特定系统的生命周期阶段不重叠，并且明确区分了工程活动和生命周期阶段。

图24.项目模型的主要元素。

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

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

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

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

后记

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

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

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