本章包含一个例子，为了给偏远、欠发达地区供应纯净水，使用SysML和基于功能分析方法设计蒸馏器的过程。这个例子从问题的描述开始,选择一个适当的方法来进行系统建模。由于这个问题的抽象性质，该系统的开发将使用传统的功能分析方法，对于许多系统工程师来说这是熟悉和直观的。这种方法方法通常与介绍在第3.4节简化的MBSE方法的一致。
-
- 问题描述–清洁饮用水的需要
考虑一个人道主义组织的需要，致力于为人类提供安全的饮用水，特别是在世界上的贫困地区纯净的饮用水是不容易获得的。为这个目的假定，为偏远、贫困地区提供一个可持续的长期来源的纯净水的经费有效的支持。
也建设，在这些目标区域的环境，研究表明水的来源，由于病毒和细菌污染，很少有安全的饮用水。由于长期将水输送到这些偏远地区的成本是很高的。人道主义组织决定开发一个非常简单的，廉价的净水器。初步研究表明，基于过滤器的水净化方法是不可持续的，因为过滤器的材料有一定的寿命，成本不好控制，且不能进行病毒过滤，且商业的过滤器需要运输到偏远地区物流的成本也相当的高。
这个人道主义组织要探索开发和部署大量的极其简单的蒸馏水的能力，一个通用的设计既满足不同地区的经济现状使用本地的能源供给。本章的这个例子的解决这种蒸馏水系统的设计与分析的问题。
许多假设都是关于各种解决方案的可行性，使这个例子问题的范围可控制的。这个例子的范围限于蒸馏设备本身的设计，但它是公认的，一个实际的解决方案必须考虑交通问题，更大的安装和操作培训，物流支持，以满足业务需要。
一种基于模型的系统工程方法的选择大量依赖于需要解决的问题的本质,期望的输出,和资源可用于解决问题。注：步骤被显示作为一个序列,它们常常被执行以并行和迭代的方式。
水蒸馏器系统的本质是不是复杂的也不是软件密集的。选择的MBSE方法学需要为系统的结构和操作提供一个框架,和对应分析它的性能。这导致一个方法学，支持功能分析域专家的来帮助定义适当的操作语境。
这个例子与描述在第3.4节简化的MBSE方法一致，概述如下。
- 模型组织（Organize the model）–被讨论在第16.3节。
- 引出和分析涉众需求（Elicit and analyze stakeholder needs）–被讨论在第16.4.1节,聚焦在捕捉利益相关者的任务陈述、顶层需求和假设。这些被随后用来建立顶层系统语境和用例。
- 指定功能、接口、物理的、和性能特性（Specify functionality, interfaces, physical, and performance characteristics）-涉众需求被使用作为一个基础来驱动和制定具体的系统需求。系统需求对应系统的一个层次被建议在第16.4.2节。这些反过来驱动系统设计。所需的系统行为被讨论在第16.4.3节,随着产生的系统关系和约束。
- 综合备选的解决方案（Synthesize alternative solutions）–初始的目标在系统综合过程中,正如涵盖在第16.5节,是来确定简单的低的成本系统，其满足整体需求。结构配置的性能被预估使用一个热平衡在第16.6节。
- 权衡分析（Tradeoff analysis）–权衡应该正常情形下被考虑，无论何时备选方案出现。这个例子讨论权衡分析的基础行为在第16.4.4节,并检查备选的来提高基础功能和用户界面在第16.7节。
- 维护可追溯性（Maintain traceability）：追溯性到系统需求被演示贯穿过程,通过需求关系和功能分配。大多数证据在第16.4.3和16.5节。
初始化一个显着的建模工作之前的一个关键步骤是建立模型的初始化组织，这被进行通过定义模型的整体包结构。该组织结构还应考虑什么样的模型库可能会有利于开发。第6章，第6.4节包含许多可以用来组织模型的方法。当组织该模型以避免过早地限制或偏置设计时，必须谨慎行事。
包图在图16.1描述这个模型的组织。图标题说明这个图的语境是(模型的根层级)Distiller Project。每个包在图上被包含在这个模型内部。用户定义的图名称对应这个包图是model organization,其可以用去区别于许多其它包图，说明它的语境是Distiller Project。这些图标题的这些约定在整个示例中都是一致的，并且对于理解模型组织中的每张图的上下文是非常重要的。参考第5.3.2节获取更多信息关于图标题。
包在这个模型中主要被用来管理基于所选择的过程开发的工件的类型，包括：需求，用例，行为和结构模型。Engineering Analysis包包含约束模块和参数模型用来分析性能。
注：Value Types包在图16.1导入SI Definitions包-一个可重用的模型库包，可供多个模型使用。Value Types包使用导入的单位制和数量类型来定义生成特定的数值类型, 随后它适用于整个模型中具有一致的单位制的数值属性。
图16.1 蒸馏器模型的包图组织
一个包对应Item Types被包含到分别捕捉流进系统事物的类型。分离项类型与拥有它的包，允许建模者聚焦在定义事物，其流动和利用可重用的库，可能存在独立于它们流的地方，或者它们是如何使用的。这种隔离是相似的，建立一个可重用的组件库。对于这个例子，水和热流动穿过系统。提供一个分离的包对应项类型允许建模者联合所有关于水和热的相关信息，和其它项类型使用在这个模型中。
建模工具的浏览器通常提供了一个这些包视图以一个类似文件夹中的结构，被填充随着模型的开发。随着时间的推移，模型的修改和更新，可以方便地修改模型的组织。例如,在一个初始设计已经被建立后,包可以被建立对应每个组件，也即详细的设计和分析的主题。
下面的章节描述需求如何被省略和详细说明驱动蒸馏器系统的设计。
蒸馏器系统的需求被捕捉和追溯在系统模型中。第16.1节提供一组任务集的说明，提供一个基础对应更特定的任务需求。这些任务需求被使用来衍生有效性测量,和随后通过分析导致一整套蒸馏器的规范的系统需求集。图16.2显示包结构，适应这些类型的需求。图16.3显示一个来自初始的任务陈述的需求表。在SysML中表格格式是一个允许的符号,代表了一种传统的和方便的方式来查看需求。这个表被生成从包含在系统模型中的需求,并与可以被显示在一个需求图上的需求包含相同的信息；即，需求id,名称,和文本。这种情况下,表依赖于编号的层次来说明包含关系也即是绘制在模型使用容器,但这可能已经被显示通过层级或使用另外一种机制。注：这些需求的每个标识符开始于字母“MS”,来说明其标识任务陈述的部分。
图16.2对应蒸馏器问题的需求组织
图16.3 捕捉任务陈述作为一组需求集
图16.4显示一个组合任务陈述需求如何已经被分离到简单的需求,不需要添加或变更它的意义。这个过程往往是有效的被称为“需求分解”，但，非常重要来认识合成与分解意味着一个非常不同的关系类型在SysML中。
蒸馏系统的目的是为了经济地提供清洁的饮用水在各种各样的偏远，欠发达地区。在这样的区域的条件下的一项调查，导致我们的后续任务的需求，也被捕获在模型中：
- 电力供应将通常是不可能的。
- 根据该地区的气候、天然植被、农业和矿产资源为蒸馏过程提供热能来源。可能需要包含太阳能、液体燃料或固体燃料。
- 不干净的水的源头可能是静止的或流动的。在某些情况下，会有足够的高程重力给水装置。在其他情况下，水将需要手动注入蒸馏器。
- 本地提供充分的人力资源来操作蒸馏器,但必须是未训练的人员提供的简单操作。
- 蒸馏器的输出将进入当地的配水系统,其可以包含任何存储的容器和管道到一系列储水罐
图16.4一个任务陈述需求使用容器
这些需求的一个初始分析产生下面的蒸馏器项目的有效性测量集,其也被绘制在模型中:
- 持续提供纯净水的单位成本。必须考虑劳动力、燃料、电力、耗材和维护成本。
- 供应的水的质量(必须高于最低接收安全阈值)。
- 每个蒸馏器的成本,包含运输。这将驱动可能采购的数量，和可以服务的人口数。
- 可用性通过本地、未培训的操作人员。
由于热源和水源的变化性必须包含, 开始将蒸馏器视为独立的，设计视为基本的蒸馏器的设计。细化的设计可能会包括水处理设备和加热源包括燃料存储，如果被视为适当的可以广泛部署。
Distiller System Context模块被生成在Distiller Structure包中。它的内部模块图被显示在图16.5。注：模块表示Water Source, Distiller, Heat Source,和Water Distribution System也被生成,和使用Distiller System Context模块的组成部分类型。其它属性类型化使用Operator和Water User 参与者包含在Distiller Use Cases包中。流进和流出蒸馏器经被描绘使用项流，类型化使用合适的项类型(H2O,Heat)包含在Item Types包中。
初始的意图是有热源采购本地的, 如果可能的话，从而最大限度地减少运输成本。由于这个原因，热源将被建模好像它处于蒸馏器的外部。水源可以是任何适合的水,或一个本地提供储水容器。注：除了蒸馏器自身，操作者（或操作人员）也需要与水源和热源相互交互。
一个初始的用例图对应蒸馏器被显示在图16.6。对应这个例子的目的,重点被放置在蒸馏器自身的操作上。清洁水的分布、随着交通运输、安装、维护和拆卸的蒸馏器是超越这个例子的范围。这种情况被限制，以呈现一个紧凑的，可管理的例子问题。一个更复杂的问题处理也应该考虑客户的传输和物流的资源,以及建议一个方法对应维护蒸馏器和培训操作者。假设这个更广泛的语境仅被考虑在一个可行的设计出发点之后，对应蒸馏器已经达到。
图16.5 建立一个语境对应蒸馏器系统
图16.6建立一个用例的初始的集对应蒸馏器系统,基于系统语境
本节介绍涉众需求的分解,假设和约束到一组有凝聚力的需求。对于蒸馏器的基本要求是明确的，它们的满足程度度可能与具体的系统设计相关。图16.7描绘了一个蒸馏器净化水的需求的最初推导，而不是在任务需求中指定的。注：也说明了这种推导的理由。
系统需求衍生自每个任务需求的一个分析。由此衍生的蒸馏系统的要求如图16.8所示。External Heat Source、Gravity Feed、Cooling和Boiling需求,一起使用在先前标识的Purification需求中,被使用来驱动初始的系统设计。注：需求构成蒸馏器规范包含“DS”在它们的ID 属性中。这些deriveReqt依赖关系可以被显示在一个矩阵中,正如描写在图16.9。
External Heat Source、Gravity Feed、Cooling和Boiling需求,一起使用先前标识的Purification需求,被使用来驱动初始的系统设计。除了id和名称, 表捕捉的衍生关系,其显示一个需求如何被衍生自另一个,随着关系的理论基础。多个关系来自一个需求树，可以被图形化的显示在需求图上。这是一种有用的方式来输入关系；然而,常常更紧凑来显示信息以表格格式。工具被期望来提供表格格式对应编辑和查看需求和其它类型的建模信息，正如描述在第5.3.5节。
建模者可以需要来利用非规范的需求类型在OMG SysML标准[1]的附录D，和/或生成用户定义的扩展使用配置文件描述在第15.3节。
图16.7 建立净化需求
图16.8 初始蒸馏器系统需求的衍生
图16.9 追溯deriveReqt 关系在一个矩阵中
本节描述技术来刻画系统行为基于功能需求。Distill Water功能的一个初始的分解被提供作为一个模块定义图在图16.10。词“功能（function）”与词“活动（activity）” 互换在整个这个例子中被使用。盒型标志在图上的代表功能不是模块,并且它们被命名使用动词。在组合关联的终点的角色名称表示调用行为动作的名称包含在Distill Water中，其调用每个相关的活动, 例，动作a2调用Boil Water活动。这与活动层次方法是一致的讨论在第9.12节。
图16.10 蒸馏器工程的初始分解
一个满足（Satisfy）关系被建立在Boiling需求和Boil Water功能之间,和Cooling需求和Condense Steam功能之间。冷却的需求可能无法完全满足，简单通过冷凝蒸汽，由于所产生的冷凝水仍然太热，很难简单分配。为了简单起见，假定的冷凝水被允许在外部收集设备冷却之前分配。
一个Satisfy关系也被建立在Purification需求和顶层的Distill Water功能之间。这种关系随后增强通过添加satisfy关系在需求衍生自Purification需求之间(例，最低水温超高最低时间),和蒸馏器的附加功能（例，监控温度、监控流量)。
加热水是一个必须的功能,即使它并没有立刻满足满足一个既定的需求。如果我们假设来自水源的水温将于环境温度相同，加热的和沸腾的水必须加以区别，因为传热机制是不同的。Heat Water功能提高水的温度不需要变更它的形态。功能Boil Water改变水的状态不需要变更它的温度。没有什么是暗示这些功能是如何或在哪里执行的，事实上，它们可能进行在相同的装置中,例，一个水壶在一个火炉上；它们是两个独立的功能，必须进行相应的处理。
水被建模作为一个模块在Item Types包中。分析蒸馏器性能时，水流经蒸馏器时的状态必须是清楚的。状态机在图16.11表示水的状态变更在液态和气态之间，随着水被处理在Distill Water过程中。必须加入汽化潜热从液体到气体的过渡。汽化潜热同样必须从气体转变为液体时。隐藏的汽化热必须被添加到从液态到气态的变化中。当从气态到液态变化时，同样的隐藏的汽化热必须被删除。
三个功能的关系，构成Distill Water功能被绘制在活动图中显示在图16.12。封闭的框架指定一个活动称为Distill Water，正如标题显示的。正如描述在第9章,第9.3节,带圆角盒子表示动作(用法)，其可以调用活动(定义)。虚线是控制流其定义动作序列；虚线是一个可选的符号替代实线,和帮助来更明确的区分控制流和对象流。动作和动作引脚包含它们的功能名称(用法)和类型(定义)使用角色名称:类型名称符号。
Distill Water功能的输入和输出活动参数功能输入使用模块来自Item Types包(Heat, H2O)。项类型的这种使用方式维护流动在系统中的事物的一致表示。活动参数external:Heat有一个Satisfy关系到蒸馏器规范需求External Heat Source,说明热是蒸馏系统外部产生的。
组成Distill Water的其它功能中每个有活动参数标识，输入Item Types包中的模块。引脚的类型在调用行为动作在活动图(a1,a2,a3)是协调的与或从参数类型在活动上(即,功能)它们调用。
动作序列对应Distill Water功能被表示通过控制流来自初始节点,通过虚线连接动作,到终点。这个序列被虽有重新检查，作为行为模型被更完整的开发。
图16.12所示的对象流，说明水在动作之间流动的各种类型和阶段。Distill Water功能的输入是cold dirty:H2O,和输出是pure:H2O和waste:Heat。输入参数external:Heat是一个输入到Boil Water和Heat Water功能。由于它需要是顺序的,并不仅被使用一次, external:Heat必须是一个流的参数。类似的, Condense Steam有一个waste:Heat作为一个输出参数。
图16.11 H2O的表示状态
功能Boil Water仅有一个输出stream:H2O。然而这并没有解释事实，煮沸分离挥发性物质诸如，水,和非挥发性物质,诸如，沉淀物,盐,金属器皿,和硝酸盐。这不能被注意到由于潜在使用高污染的水源。为了处理积累的残留的需要，一个新的需求被衍生,和一个新功能建议将被执行通过蒸馏器。与这伴随相关的原理被显示在图16.13。对应Distill Water的活动图被更新显示在图16.14。
图16.12蒸馏水的初始活动图
图16.13排除残留的需求的衍生
图16.14 更新活动图合并排干残留物动作
本节定义技术对应精化蒸馏器行为,和引入行为分配。在最初定义整体行为之后，这是常见的，用来完善系统的行为与系统结构的并行。功能分解的一个关键原则是独立地考虑行为和结构(至少在一个抽象的给定的层级),并来具体的分配一个到另一个。这种分离的关注点有助于探索各种结构的替代方案可用来实现一个特定的功能需求。在这个例子中, 满足需求的可选的行为构件将被提交到权衡分析,和最简单可能的结构，有效的支持那些将被选择的行为的结构。
批处理对比持续过程是两个必须被考虑的可选方案。图16.15的左侧显示一个批处蒸馏器，其包含一个锅炉和一个冷凝器。在批处理过程中,锅炉中裝满了水。一个热源被使用来加热锅炉中的水、随后蒸汽产生、和蒸馏水从冷凝器中收集。当锅炉中没有更多的水时，这个过程就停止了；净化更需要补水锅炉。图16.15的右侧显示一个持续的蒸馏器，可以有持续的水流动通过它。它包含一个带有一个内部加热元素和一个热交换器的锅炉，热交换器有冷却液流动在线圈中，蒸汽凝结在他们周围。
图16.15 一台批处理蒸馏器 (左) 和一台个持续的蒸馏器 (右)
先前显示在图16.14中的控制流与一个批处理蒸馏器的行为是一致的，每个动作终点在下一个动作开始之前：当Heat Water完成时,动作Boil Water被初始化。当Boil Water完成时，Condense Steam和Drain Residue被初始化。当这些动作被完成时, Distill Water活动完成,和一批纯净水可用。整个过程必须重新开始处理下一批水。
图16.16显示一个持续蒸馏器行为的活动,使用相同标识在前面的概念。每个动作都同时执行，每个动作引脚或活动参数都是{streaming}，意味着在执行时它提供或接收对象，和它的构造类型作为«continuous»,意味着，发送/接收对象之间的时间是任意短的。这个准确的建模蒸馏器的行为，热和水在系统中是持续流动。
批处理和持续方式的活动模型可以被构建来执行，并作为两个备选方案的性能比较的基础。这个例子假设这两种方式的一个适合的定量比较，显示持续方式从蒸馏器输出纯净水更多，由于批处理蒸馏器的冷却和补充需要额外的时间。一个设计决策做出设计一个持续的蒸馏器,并且该原理被记录在模型中。
Distill Water功能有作为一个输入和一个输出的热。简化功能设计和提高蒸馏器的有效性, 建议来使用热输出通过a3:Condense Stream动作作为a1: Heat Water动作的一个热源。图16.17显示一个蒸馏行为的这种类型的修订的活动模型。注：waste:Heat不再出现作为Distill Water功能的一个输出参数。
本节描述模块、组成部分、和端口的使用，对应蒸馏器的结构和行为分配的建模。
图16.16 初始化持续方式蒸馏器活动图
图16.17 持续方式的蒸馏器活动图使用恢复热
图16.18是一个模块定义图对应蒸馏器系统。图显示模块被命名为Distiller,其由一个模块命名为Heat Exchanger,一个模块命名为Boiler, 和一个模块命名为Valve组成。组合关系显示，蒸馏器构成中的一个Heat Exchanger履行condenser角色,一个Boiler履行evaporator角色,和一个Valve履行drain角色。
图16.18 初始的蒸馏器结构
模块Distiller显示一个舱段说明，它满足需求Simple Distiller，这不意味,当然,那个Distiller一致满足初始的任务陈述必要的, 而是说，它是断言满足它, 当制作决策影响蒸馏的设计时,所以需求需要将被仔细考虑。符合任务语句需求Simple Distiller, 这个项目的设计理念是有效操作所需的最小数量的零件。在保持设计的简单性上，三个组件显示是一个好的开始。所需的行为现在必须被映射到这个结构上，所产生的设计分析的可行性和性能。。
行为的初始分配到结构已经被指定使用分配活动分区 (即,泳道)：在活动图上的分配活动分区中出现的一个动作表示动作和分区所表示的组成部分之间的分配关系。在图16.19中, 行动的初始分配是通过使用分区指定的来表示组成部分 condenser:Heat Exchanger、 evaporator:Boiler和drain:Valve。关键字«allocate»使用在分区中意味着，分区是一个分配活动分区，它有一个明显的分配关系来表示分区的组成部分,正如描述在第14章,第14.6.3节。这反过来又指定了在分区内执行动作是组成部分的职责。
例如, evaporator组成部分是Boile模块的一个用法，和动作a2:Boil Water被分配到evaporator:Boiler。注：角色名称被定义对应每个组成部分,和每个组成部分类型是一个模块。例如,角色drain是一个类型Valve组成部分。这种区别是重要的由于其它阀门使用相同的定义可以有不同的角色, 如在后面的例子中很明显。组成部分和模块的规范被描述在下一节作为蒸馏器结构的部分。
图16.19 Distill Water活动建模使用动作分配到蒸馏器的组成部分
这个方法表示分配的用法。换句话说,仅调用行为动作a2被分配到组成部分evaporator。没有事物被陈述关于更通用的情形在Boil Water活动和Boiler模块之间。这种分配的用法仅被应用到Distill Water活动的语境中，分配在Distiller模块语境的内部。在一个不同的语境中,模块锅炉可以煮沸一个不同类型的流体。行为分配的定义(分配一个活动到一个模块) 应该仅被进行，如果一个特定的块的每一个使用，预计将表现出的行为的分配活动。
内部模块图可以被开发基于模块定义图来显示，组成部分如何被互相连接。然而, 在执行这之前,模块在模块定义图被进一步详细说明通过标识端口在模块上和它们的定义上，所以端口可以被连接在内部模块图上。
端口被标识在模块上，在模块定义图在图16.20。端口在这个例子中都是代理端口,意味着，它们被使用来指定可以流进和流出模块的项,和没有它们自己的固有行为。它们也是单向的，这意味着接口模块的属性，该类型的端口只有一个方向的流属性。Valve有代理端口对应in:Fluid和out:Fluid，器通常应用到一个二端口阀门的所有使用。Heat Exchanger有一个冷循环(c in和c out) 和一个热循环(h in和h out)；两个特征是通用到所有逆流热交换器。仔细注意来指定配置可以促进它们的重用。Boiler有3个端口对应Fluid (top, middle,和bottom)和一个对应Heat (bottom)。操作锅炉中的沉积物和蒸汽的分层，使它有效地从顶部提取蒸汽，从底部排除污泥，并在中间注入进水。
下一步是来显示这些模块的使用在蒸馏器系统的语境中在一个内部模块图上, 包含它们之间的连接和流。
图16.21是一个内部模块图对应Distiller系统。标题标识封闭的模块为Distiller。用户定义的图名称为initial distiller internal configuration。组成部分表示模块如何被使用在Distiller语境中，并有相同的角色名称正如被显示在模块定义图。代理端口与它们在块定义图上的定义是一致的。被首先显示在图16.19的动作分配到组成部分上也显示在这里，在三个组成部分中每个使用一个舱段符号。这些分配关系显式地描绘在分配舱段中；allocatedFrom说明关系的方向—即, 从在舱段中指定的元素到组成部分。
图16.20 蒸馏器分解使用端口
附加的的信息在内部模块图上不在模块定义图上，是在连接器上的组成部分和项流之间的连接器的表示形式。连接器连接端口并反映蒸馏器的内部结构。项流表示什么项流动在连接器中并输入和输出端口。
正如讨论在第7.4节, 项流描绘流动在连接器上的对象。它们指定什么流动,和流动的方向。在这个例子中,所有模块用来类型化事物，流被保持在Item Types包中。这些随后被用来作为活动参数、动作引脚、接口模块的流属性的类型,和属性引用通过项流(选择项属性)、消息、信号、等。使用一个通用的存储库对应所有类型的事物，流动是一个有效性接口管理的主要原则。
图16.21 初始蒸馏器内部配置使用流动项和分配
一个命名约定对应项属性被使用来标识项流动通过系统。水的主要流动(H2O)通过蒸馏器被显示如下:main1是H2O流进系统到流进热交换的冷循环；main2 是H2O流出热交换的冷循环和进入锅炉；main3 是H2O (流)流出锅炉并到热交换的热循环；main4 是H2O流出热交换 (冷凝物,或纯净水)并输出系统。沉淀物的流动同样已被同样指定：sludge1流出锅炉并到排水阀门,和sludge2流出排水阀门并流出系统。仅附加流q1,表示热流进系统到锅炉。
蒸馏器系统的结构被定义在模块定义图上, 和如何使用这些元素的连接和上下文，以及物理流，表示在内部模块图上。行为的分配(动作)到结构(组成部分)处于蒸馏器系统语境中,使用分配活动分区在图16.19中。现在是适当的分配流在活动模型中到流在结构模型中。
在活动图中，流通过名称和动作引脚的类型被指定；对象流提供上下文和引脚之间的连接。指定流作为结构的部分时，端口指定什么可以流动在模块和组成部分上,和项流指定什么事实上流进拥有模块的语境。在这个例子中，对象流直接分配到项属性，必须检查对象流连接的动作引脚的类型与项属性的类型的一致性。每个对象流在活动图上(图16.19)被分配到一个相应的唯一项属性在内部模块图上(图16.21)。系统性能后续的分析聚焦在这些项属性的相关特征上,诸如，温度和质量流量。
矩阵在图16.22 被使用来描绘流分配。箭头在矩阵中表示分配关系的方向。一个矩阵通常提供一个流分配更清晰的表示超过使用标注或舱段。
图16.22 分配流从蒸馏水对象流到蒸馏器属性
在本节中,蒸馏器系统性能被分析来确定设计的可行性。
蒸馏器性能的关键方面是通过系统的质量流量和热热流的适当的平衡。为了评估流的平衡，分析聚焦在水和热的物理流动上，正如表达通过在内部模块图中的项属性。一种替代的分析方法，聚焦于活动图中的流动进行了简要探讨，但丢弃有利于更直观的方法，在内部块图中分析物理流。
设计的可行性可以被评估通过分析水通过系统的质量流量，并分析需要加热水的热流和相关的相变。这种分析是通过整个系统等压简化；即整个系统压力假定均匀大气。
图16.23是一个Distiller Isobaric Heat Balance模块的参数图，其被使用来支持 参数分析。这个图被使用来表达物理流之间的简单数学关系。6个正方形盒子环绕图边(main1:H2O,main2:H2O,等等)表示项属性在Distiller内部模块图上。每个项属性可以有唯一的相关的数值属性，它的使用,诸如，温度和质量流量。特定的热和潜藏的热是通用的,H2O不变的(只读)属性，其也需要将被考虑在分析中,和所以它们包括在内。三个圆角盒子在图的中心表示Distiller Isobaric Heat Balance模块的约束属性；每个有一个相应的约束表达，作为一个数学公式。该约束被标识通过花括号({}),和可以或被直接显示在约束属性上或显示在一个分离的标注约束中。
基于蒸馏器的拓扑,水的质量流量输入(main1) 必须等于换热器的水输出的质量流量(main2)，由于水没有别的去处。这种等效被描绘在图16.23提供直接绑定main1:H2O 项属性的mass flow rate数值属性和性main2:H2O 项属性的mass flow rate数值属性。同样的,输出来自锅炉(main3)的质量流量必须等于水的质量流量来自Distiller (main4),和相同的绑定类型被使用。
系统需要来加热水和冷凝流在同时正如指定活动图。单相传热方程,其被应用当加热流体水、相关质量流量、温度的变化、和特定的热到热流(q rate)。注：约束s1 : Single Phase Heat Xfer Equation显示这些参数中的每个在一个小的正方形盒子中。绑定连接器被使用来绑定数值属性与main1和main2的mass flow rate和temperature，并指定水的比热到该约束的参数。q rate参数在不同的约束中被直接绑定到另一个,正如反过来被绑定到项属性的数值属性。q rate来自condensing:Phase Change Heat Xfer Equation被绑定到q rate对应s1:Single Phase Heat Xfer Equation,由于能量用来加热水来自冷凝的流。
一个简单的相变等式被使用来确定，需要提取多少热对应一个给定的流的质量流量。在这个例子中,约束模块Phase Change Heat Xfer Equation, 被使用对应冷凝流和煮沸水。这个等式仅被定义一次作为一个约束模块，和用来类型化两个约束: condensing和boiling。condensing和boiling约束有相同的参数，但被绑定到不同的属性。也需要注意，那个specific heat和latent heat被表示作为H2O只读属性,由于它们不变化。这些被说明通过{readOnly}在图上。
这个参数图定义属性之间的数学关系,但它不执行分析。显式约束流动通过蒸馏器项的属性。下一步是通过评估等式来执行分析。
图16.23 定义参数关系作为分析的前奏
等式和值表示在参数图中被输入到一个表格，其被随后用来执行计算。(注：SysML建模工具中的一些建模工具现在包含内嵌的求解器其可以执行这种类型的计算。)图16.24是一个表格捕捉来自这个分析。初始的,分析假定单位流量到蒸发器(main2:H2O into evap)并随后确定多少水被需要来流过冷凝器。结论表明，要除去足够的热量来凝聚蒸汽，几乎七倍的水的质量需要流入到系统中超过流出的！在当前的设计中,没有位置对应水去除在锅炉中,其将随后溢出。这不是一个可行的稳定状态方案和需要修改设计。
图16.24初步设计中的热不平衡分析
由于分析揭示在原来的蒸馏器设计中的一个根本性的错误，本节介绍克服性能限制的设计修改。
正如显示在修改的活动图在图16.25, 设计被修改通过添加另外一种组成部分称为diverter assembly:其被表示作为一个分配活动分区,使用动作来分流水，称为a5:Divert Feed。这现在允许多余的热水排出系统。
分配活动分区对应到一个新的组成部分,其包含另外一种先前定义的Valve模块的使用。这个新的组成部分,它的内部结构,并且相关的流被显示在内部模块图，如图16.26所示。该组件被分解成一个三通接头，来将大部分的流从系统中排出,和一个阀门来节流进入锅炉的水。diverter assembly：是一个简单的组成部分的集合。嵌套的连接器的使用避免了需要使用流端口在diverter assembly上。
这种修改的设计使能feed:Valve将被节流，所以锅炉不溢出,但仍保留足够的水通过换热器冷凝蒸汽。注：Valve模块的重用。drain:Valve和feed :Valve每个有两个端口,两个都有相同的值定义但被连接不同的。
这种简单的蒸馏器设计看起来是可行的,并表示一个适当的起点对应更详细的设计。
到目前为止，设计没有明确考虑如何用户如何与蒸馏器交互。设计看起来更像是持续的操作，但开始的和关闭蒸馏器的过程需要将被需要添加，假定一个可靠的电源来源是可用的。电力供应现在有两种方式简化蒸馏控制：它允许电加热，它也允许一个控制器/处理器的运行监测和执行常规的调整装置，从而大大简化了蒸馏操作，最大限度地减少所需的培训和技能。一个控制面板提供一种统一集成的操作接口对应蒸馏器。
原始的用例图在图16.6是一直有效的, 但Operate Distiller用例需要来被说明来解决启动、稳定状态操作、和关闭、使用一个控制面板基于接口。用例描述如下:
Operator开始通过打开Distiller，并观察一个Power Lamp On。当Distiller达到操作温度, Operator观察Operating Lamp On；然后蒸馏周期产生的蒸馏水。Operator关闭蒸馏器,和Power Lamp Off信号被返回通过蒸馏器。
下一节与探讨操作者、控制面板、和控制器在蒸馏操作过程中的交互。
图16.25 修订行为来适应转移注入的水
图16.26 修订蒸馏器内部结构使用分流
交互在蒸馏器操作者、控制面板、和蒸馏器控制器之间被显示在一个序列图上在图16.27。这不反映蒸馏水的详细交互，但指定了操作者使用蒸馏器的接口。这个交互利用附加的需求和相关的设计变更在蒸馏器上,包含组成部分需要对应Operator来提供输入到系统和系统状态到操作者(例，灯),和对应自动控制一些蒸馏功能。
图16.27 定义操作者交互使用一个序列图
图16.28是一个模块定义图,和图16.29是一个内部模块图，反映设计的更新来实现用例。一个控制面板已经被添加带有开关来打开和关闭蒸馏器,和操作员观察灯。一个控制器已经被添加来确保，该阀门是在适当的操作顺序，灯打开和关闭。
电力输入被提供到加热器在锅炉中来转换电能到热。用控制器为锅炉提供动力是有意义的。一个接口模块可以用来输入一个代理端口，并指定一种类型的信号，期望来传递在控制器和锅炉之间。该接口模块可包括在锅炉中的浮动开关的位置，以指示水平是高还是低。。
图16.30显示接口模块Boiler Signals。注：它使用2个流属性 control和status,和方向是合适的对应heat and valve:Controller在图16.29。evaporator:Boiler使用一个共轭代理端口使用相同的接口模块作为流端口在控制器。该共轭反转流属性的方向，并使连接兼容。
图16.28 蒸馏器结构层次使用控制器和用户界面
图16.29 蒸馏器内部结构使用控制器和用户界面
图16.30接口模块对应锅炉信号
由于系统现在使用一个控制器,启动和关闭和系统控制的其它方面可以被指定通过一个状态机图对应控制器,正如显示在图16.31。状态和转变在图中被标识通过检查序列图与Operate Distiller相关的用例。
开始使用蒸馏器处在Off状态, 在这种状态水是冷的和脏的,一些事物不得不发生在它开始蒸馏前并生成纯净的水。第一步是来注入水到锅炉中。当在诸如状态Filling, feed:Valve打开。一旦水的高度在锅炉中是充分的涵盖加热器线圈,加热器可以被打开没有损坏。系统现在可以进入Warming Up状态,其中锅炉加热器被打开和锅炉开始来加热。
一旦锅炉温度达到100oC,系统进入Operating状态。在这种状态,锅炉加热器一致处于打开，但两个子状态 Controlling Boiler Level和Controlling Residue并行出现。在这个例子中,残留的控制依赖于一个简单的计时器来转变在Building Up Residue子状态，当drain:Valve被关闭和Purging Residue子状态态，当drain:Valve打开来处理残渣。蒸馏器状态机周期性的处于关闭锅炉来限制残渣的增多。
控制水的层级在锅炉中,三个子状态之一存在:在Level OK情形下，drain:Valve和feed:Valve都需要关闭；Level Low情形下，其需要更多的水所以feed:Valve需要被打开；或处于Level High,其中drain:Valve需要被打开。
当操作被完成时,蒸馏器进入一个关闭过程；否则,腐蚀将严重影响蒸馏器的寿命。在这个过程中第一步是来冷却系统。在Cooling Off状态下,加热器被关闭和feed:Valve和drain: Valve打开,允许冷水自由的在整个系统流动。一旦锅炉温度达到一个安全级别,锅炉需要被排干。在排干状态, feed:Valve被关闭，而drain:Valve保持打开,和所有的水被排出锅炉。一旦锅炉是空的，蒸馏器电源可以安全的被关闭。
图16.31 对应蒸馏器控制器的状态机
这个例子显示SysML如何可以被用来建模一个系统使用一个传统的功能分析方法。该示例还说明了它的应用到建模物理系统与有限的软件功能。每个SysML图的例子被使用来支持规格说明书、设计、分析、伴随使用一些基础的SysML语言概念，诸如，定义和使用之间的区别。
下列问题可能最好在课堂或小组项目环境中解决。
- 客户引入新的需求:“The Distiller shall be able to operate at least 2 meters vertically above the source of dirty water.”显示新的需求对于系统设计的影响，正如表达在下面的建模构件中
- 需求图(关联新的需求到已存在的需求)
- 活动图(定义和结合新的活动来支持新的需求)
- 模块定义图(定义和结合新的模块来支持新的需求)
- 内部模块图(定义流和接口到任何新的组成部分，以支持新的需求，以及活动图中的任何功能和流分配)
- 参数图(描述这个新的需求如何影响热平衡)
- 用例图(描述任何操作场景的变更)
- 序列图(详细说明任何变更到Operate Distiller的用例)
- 状态机图(描述状态机Controller如何会被影响通过预先设计的变更)
- 讨论了适用性和物理控制流入蒸馏活动模型的意义，如图16.12所示，图16.14。在何种情况下，控制流是有用的行为表示？？
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
