复杂系统设计

一艘常规军用潜艇包含40多个子系统，涵盖广泛的功能；从作战和武器处理到提供冷却和液压的服务。这些子系统高度集成，并在单个耐压壳的范围内配置。一旦潜艇投入使用，往往会出现不良的行为和特性。当然，等到潜艇建成后才发现这样的缺陷是不明智的，因为对已完工潜艇的改装成本极高，可能会造成国家的一项重要资产损失。

在最早的设计阶段（当变更成本相对较低时），越来越多地使用计算机建模来定义健壮的系统架构，并预测设计的紧急行为和特性。 通过集成同一系统的不同计算机模型，可以进一步提高设计的完整性、一致性和可追溯性。在系统的整个生命周期中，使用集成的计算机模型来管理系统的规范、设计、评估和支持的实践被称为基于模型的系统工程（MBSE）。

基于模型的系统工程（Model-Based Systems Engineering）在过去十年中，MBSE在多个行业的应用有所上升，最显著的是在国防、航空航天和铁路领域。因此，许多不同的MBSE方法已经由一系列从业者发布，使用了各种不同的过程、模型和工具。 一个完整的多学科“系统模型”是大多数MBSE方法的核心，可以用SysML来表达。 本文的目的是概述在早期设计阶段在SysML中规范和设计潜艇子系统的MBSE方法。

首先介绍一些重要的概念，为本文后面讨论MBSE方法论做好准备。这些概念是设计过程框架的基础，设计过程框架应用于各个设计层次，从整个潜艇到其子系统及其组件，在系统工程“V”生命周期的左侧递归进行。 该框架与ISO-15288中定义的技术系统工程过程和面向对象系统工程方法（OOSEM）中定义的建模活动保持一致。解释了该框架的创建和发展，以支持早期潜艇设计。 本质上，矩阵是由ISO-15288过程和反轴上的OOSEM活动定义的。在这个矩阵中发现的过程和活动之间的交叉点被分组到下图所示的四个过程区域中。在这个图中，圆角矩形代表过程，直角矩形代表产品。

需求开发和架构设计过程组分别涉及系统规范和架构的开发，是MBSE在工业中应用最广泛的领域。

工艺技术评估组定义工程分析和权衡研究，用于评估系统需求和设计人工制品。

最后，在整个潜艇设计层次上，综合过程组定义了传统的船舶设计实践，包括潜艇初始尺寸和估算、空间设计和集成（使用CAD）、静水压设计、水动力设计和潜艇船体结构设计。

在设计的子系统级，综合过程包括设备性能的初步估计、初步系统示意图和尺寸计算。

文中描述的每个概念首先使用大多数系统工程师熟悉的术语进行介绍，然后在SysML中定义该概念的相应实现。讨论的概念包括：

• 黑盒规范
• 需求可追溯性
• 抽象
• 继承
• 架构
• 变体建模
• 模型组织
• 设计综合

黑盒规范Black-Box Specification

在系统需求的开发过程中，将感兴趣的系统视为“黑匣子”是有用的；它与外部环境和其他实体的接口，以及它在该环境中的功能和执行方式。 黑盒定义不假设或暴露系统的内部结构、行为或属性。 这种方法从任何特定的“解决方案”（系统如何实现）中勾勒出“规范”的定义（系统期望做什么）。

系统的黑盒规范至少应定义以下特性：系统要执行的功能；该系统的关键性能或性能指标，以及；外部接口。这些特性源于为感兴趣的系统执行的需求获取和分析任务（通常在几个设计迭代中执行），并由这些任务进一步细化。

可以在SysML中使用“block”元素定义黑盒规范。块定义了直接映射到系统功能（作为操作）、属性（作为系统特性，例如权重和值）和接口（作为端口）的特性。

需求可追溯性 Requirements Traceability

系统规范可以被视为该系统的文本需求的有组织的集合。超过某个阈值，具有大量需求的规范会受益于在电子存储库中进行管理。潜艇子系统规范当然就是这种情况，每个规范都可以包含 1000 多个要求。在这样的工具中，除了其唯一标识符和文本之外，每个需求还可以使用性能界限、优先级、验证方法和合规状态等属性进行注释。

可以使用“requirements”元素在 SysML 中定义文本需求声明。 这些元素包含用于需求文本及其唯一标识符的字段。可以避免需求管理工具和系统建模工具之间的重复需求，因为大多数已建立的 SysML 建模工具都支持需求元素与其在外部需求管理工具存储库中的对应元素的同步，包括可追溯性信息。

通过在系统模型中表示需求，可以在黑盒规范中将这些元素与其相应的特性联系起来。 在本文中，一个«refine» 需求和黑盒特征之间的关系被用来说明前者的文本陈述“refine”了后者。柴油发电机系统的SysML黑匣子规范示例如下图所示。在本图和后续图中，“系统”一词可与“子系统”互换使用；由于柴油发电系统是潜艇的一个子系统。

下表中的图表总结了需求类型和黑盒特性之间的映射。一个填充的黑盒规范，其特性与相应的需求相连接，代表了为感兴趣的系统开发一个或多个替代架构的起点。

抽象

抽象是处理潜艇子系统设计复杂性的重要技术。对于特定的抽象层次，只暴露系统的相关信息和属性，隐藏不相关的底层细节。抽象层次通常与设计阶段相关。 例如，黑盒规范是一种极其抽象的系统表示，它几乎隐藏了设计的所有细节。相反，具有高物理细节和精度（如生产图纸所示）的系统设计是非常低的抽象级别。

继承

本文描述的建模方法利用了SysML中体现的几种面向对象的设计技术，包括 继承和实例化 。回想一下，黑盒规范定义了一组特性、功能、属性和接口。通常， 此规范由一个逻辑架构和一个或多个物理架构。期望这些架构中的每一个共享相同的黑盒特性集；实际上，这些架构是从一个常见的黑盒规范“继承”这些特性的。 这个想法与前面描述的抽象概念有关；由于每个备选架构可以用附加的功能、属性或接口来重新定义和扩展继承的特性，以表征该特定架构。

在SysML中，如果使用“泛化”关系关联其他块，则这些块可以从其他块继承特征，如下图所示（作为带有未填充箭头的线）。这种技术的优点是黑盒特性在系统模型中只定义一次，但可以根据需要多次重用或重新定义。

架构

可以定义系统架构的三个不同层次；功能的、逻辑的和物理的，按抽象层次递减的顺序列出， 如下图所示。

功能架构（architecture）定义了与解决方案无关的设计表示；由纯功能组成。 在本文中，功能架构被定义为整个潜艇系统层次结构中包含在黑盒规范（as operations）中的系统功能。

逻辑架构表示功能体系结构和物理体系结构之间的中间抽象。 逻辑架构的组件表示物理解决方案的抽象。例如，考虑两个不同供应商交付的两台柴油发电机组。这些装置具有许多不同的物理特性（例如，一个是涡轮增压的，另一个不是），但它们有许多共同的特性，例如功率输出和重量，它们执行一组共同的功能（例如，发电）。因此，逻辑系统的一个组件定义了一系列物理设计方案所共有的功能、属性和接口。最重要的是， 逻辑架构在很大程度上仍然独立于技术或供应商，并提供了一个合理稳定的基线，物理架构可以从中派生和发展。 逻辑系统和组件在SysML中实现为带有«logical»的构造型。

物理架构由为特定潜艇子系统设计选定的有形设备组成。 如果信息可用，可通过其供应商数据表（例如，供应商X提供的柴油发电机）对物理部件进行描述。物理架构还考虑了诸如冗余（例如柴油发电机的数量）以及特定潜艇概念的布置和空间布局等限制。物理系统和组件在SysML中作为带有«physical»的构造型。

整个架构的每个层次都定义了完整的设计可追溯性。功能作为块操作被分配给逻辑和物理系统，从黑盒规范继承而来。其次，SysML«allocate» 关系用于将逻辑架构的组件与其物理架构对应的组件相关联。

示例表示出了在系统黑盒规范中定义为操作（由名称后面紧跟一组闭括号识别）的功能，该操作由使用泛化关系（带有白色闭箭头的线）的逻辑和物理系统表示继承。

变体建模 Variant Modelling

前面的部分介绍了作为抽象层次的架构，并区分了逻辑架构（一个或多个物理解决方案的抽象）和物理架构（特定的设计实现）。

物理架构会随着时间的推移而演变，并且会经历自上而下的变化，这种变化是由新功能的引入驱动的；或者是自下而上的变化，这种变化是由新技术、硬件/软件升级周期或更换过时设备的需要驱动的。 因此，需要一种对物理架构中的变化进行建模的方法，以尽可能减少捕获、评估和维护大量变化体系结构的总工作量。

变体建模方法，利用SysML中的泛化和重定义功能，最大限度地重用模型元素。 通过定义一个物理“options选项”树来提供模型变体，该树包含跨变量设计的一组系统元素，以及一个或多个物理变体设计。

“physical options 物理选项”树包含潜艇系统层次结构的每个级别上所有允许的物理元素。在SysML中，选项树的顶部表示为一个块。下图表示出了柴油发电机系统选项块及其作为一组物理组件的组成。任何特定的物理设计变体都是通过选择这些组件的子集来定义的。上述模式可以递归地应用于潜艇产品结构的每个层次。

可以从相应的选项树中导出感兴趣系统的任意数量的变体。子系统变体的架构定义如下：

在SysML中，变体系统由单个块表示。 下图中提供了一个示例，其定义了‘A4柴油发电机系统'; 一种用于潜艇设计的柴油发电系统称为‘A4级'. 在这个图中，可以看到变体variant 系统继承了其黑盒规范的所有特性，以及从options树中选择的可用部件。 可以用同名的不同特征替换继承的块特征。 在SysML中，这称为重定义，新特性将完全覆盖原始特性 。重新定义的好处是根据元素的多重性、值或类型来更改或扩展通用特性. 例如，在下图中，柴油发电机组部件具有‘at least one' 在A4柴油发电机系统变体中，柴油发电机系统改为四个不同的供应商X DG机组零件。

模型组织 Model Organisation

本文开发的系统模型分为三个主要包；参考架构、变体架构和模型库，如下图所示。 参考架构包含从需求管理工具导入的所有系统需求集、所有系统功能和逻辑架构以及物理选项树。变体架构包含从物理选项树派生的所有物理变体设计。模型库中还定义了许多常见的定义、类型和元素。

设计综合 Design Synthesis

许多技术设计工件是由一名工程师开发的，用于综合潜艇子系统设计，包括：

• 原理图；
• 零件清单；
• 设备数据表和CAD模型；
• 工程分析和计算；
• 风险评估，以及；
• 设计报告。

原理图 是子系统的关键文档。这些“单线图”根据设备、隔间位置以及设备与其他子系统之间的接口来定义子系统。

零件列表 还与子系统示意图相关联，并以表格格式提供与所列每个零件的重量、负荷、机械服务和冷却有关的信息。

基本设备尺寸 来自供应商数据表，这些信息与整个潜艇对维护访问、签到和冲击间隙的要求相结合，以定义可集成在潜艇 CAD 模型中的 3D 部件的包络。

工程分析和计算 通常用于从子系统需求中选择和估计设备和罐体特性。这项工作的结果反映在零件清单和提供给潜艇CAD模型的空间信息中。系统及其关键部件的系统和技术准备水平（SRL和TRL）也分别进行了估计。

设计报告 描述子系统主要元素的功能以及它们如何协同工作。本报告总结了所做的工作，包括参考已创建的工件，并建议进一步开发子系统所需的下一步步骤。最重要的是，本文件提供了在整个设计过程中做出的关键设计决策的基本原理。

MBSE方法在子系统架构设计中的应用

基本过程如下图所示，跨越了前述的规范和设计过程。当应用于子系统设计时，前三个步骤是需求开发的一部分，中间和最后一个步骤是综合的一部分，其余步骤是架构设计的一部分。这些过程也是递归的，可以应用于潜艇设计的任何层次。

A.定义黑盒规范

首先为子系统定义黑盒规范块。 关键功能、性能和接口需求从需求集中标识出来，并表示为操作、属性以及该块上的值和端口。 一些特性可以从系统的通用黑盒规范（包含在参考架构中）继承和重新定义。在下图中，上框和下框分别表示通用和特定于A4的柴油发电机系统黑匣子规范。

B.追溯需求

黑盒规范的每个特性都可以跟踪到相应的需求语句，该语句也在SysML中作为需求元素建模。使用«refine» 关系，将需求元素与其黑盒特性连接起来。

C.构建需求符合性表

当黑盒被填充并跟踪到需求时，在表中查看此信息会很有帮助。下图中的需求符合性表可以在系统模型中非常快速地生成，并且打算由子系统工程师在其系统的需求评审中呈现。随着设计的进行，可以断言它（使用SysML«satisfy» 关系）设计元素满足特定要求，满足要求的每个元素的名称将出现在相应的“Satisfied By”列中。

D.定义原理图

在这一步中，设计师将重点放在他们的黑盒内部，并综合一个候选子系统架构设计，如前一节所述。这项工作在很大程度上借鉴了早期的设计、设备权衡和尺寸计算。一个关键的结果是一个示意图（“单线图”）。 子系统设计人员通常在Microsoft® Visio中使用标准符号库绘制此图 。图下给出了一个例子。该示意图用于在子系统概念设计形成过程中传达设计者的意图，通常缺乏精确性和一致性。下面解释如何使用SysML将此设计意图形式化。

E 定义块分解

有了初步的系统原理图，设计者就可以确定系统的组成部分。在系统模型中，子系统变体块可分解为其组成部分，从物理选项树中重新定义现有部分或根据需要创建新部分。 得到的系统层次结构可以在SysML块定义图（BDD）上表示 ，如下图所示。

F 定义内部块图

然后，系统示意图可以表示为SysML内部块图（IBD）。图框表示子系统边界。框架上的端口表示子系统外部接口，并从黑盒规范继承。在这个框架内，图中填充了子系统部分，这些部分可以连接在一起并连接到图框架上的端口。 部件可以在没有端口的情况下进行非正式连接，但是端口表示块或部件边界上更正式的访问点。随着设计的成熟，可以在SysML中定义端口，并增加细节，以对应更详细的接口定义。 下图表示出了示例IBD。

G. 定义零件清单

最后，可以为变体系统块拥有的所有部件生成部件列表，如下表所示。该表可以扩展列以捕获与每个部件相关的附加信息，例如其分配的隔间、构建部分或供应项目序列号。

本节中描述的方法允许子系统设计人员在支持完整设计可追溯性、子系统集成和设计变体的环境中，以较短的步骤捕获其设计的核心架构。

进一步讨论

传统的潜艇子系统设计工件以文档为中心。近几十年来，电子出版已经取代了硬拷贝报告和绘图，但 即使是 Microsoft® Word 和 Visio 或 Adobe Acrobat PDF 文件等电子文档本质上也是静态产品， 可能不精确且难以维护。 在大多数情况下，此类人工制品是由具有不同背景、使用不同工具、通常来自不同地点的不同个人开发的。

即使是最严格的桌面审查也无法检测到一组 Word 报告、Visio 原理图或 PDF 绘图内部或之间的所有不一致和错误。 这些文档发布后，设计仍会不断发生变化，并且需要在很长一段时间内保持大型文档集的质量是一项重大挑战。仔细应用，系统建模可以帮助子系统设计人员管理他们的设计工件和相关数据，通过提供一个通用和一致的模型，多个子系统可以在其中开发和集成。

使用系统模型来开发和管理子系统架构是一种相对较新的实践，并且设计方法必须让不熟悉 MBSE 的个人充分参与。 下面将讨论在 IBD 中使用符号库、故障模式和影响分析 (FMEA) 数据的集成以及来自外部工具的计算结果的集成。

A.过程简洁性

吸引领域（非系统）工程师的一个策略是采用简洁的策略。换句话说， 任何系统建模方法都必须以尽可能少的步骤生成最有用的图表。 此外，早期潜艇设计的特点是少数关键性能、主要设备属性和布局草图。将简洁性需求与数字设计定义相结合，产生了一种子系统概念设计方法，该方法集中于简化图表集。

B.行为建模

SysML总共定义了九种图类型，跨越四个类别；要求、行为、结构和参数。本文描述的方法仅限于需求和结构图类型。SysML参数将在本文后面介绍。读者可能会注意到这种方法缺乏行为模型。这种省略与传统的自顶向下的系统工程方法不同，因此下面几段将为这种方法提供一些理由。

SysML中的行为图包括活动图、序列图和状态机图。 活动图根据系统功能之间的数据流或对象流定义系统行为，通常可以包含显示如何将流和功能分配给系统组件的分区。活动图与功能流程框图（FFBD）或IDEF0密切相关，通常用于说明感兴趣系统的操作场景。序列图将系统之间的交互定义为系统元素之间交换的消息的时间序列。状态机图描述了系统对外部和内部事件的响应，特别是状态和这些状态之间的转换。状态机图还定义了响应显式事件在每个状态下执行的功能。

SysML行为图非常有表现力，但是开发起来也很复杂和耗时。有鉴于此，仅在设计过程中追求简洁就构成了不强调行为建模的理由。

更重要的是，潜艇设计是一个进化的过程，在这个过程中，每一个设计都会在以前的设计基础上逐步改进。事实上，现代军用常规潜艇所使用的子系统和设备类型的清单已经确定。船舶工作分解结构（SWBS）是水面舰艇和潜艇设计人员经常用来组织子系统和设备的标准清单。此外，几十年的发展和经验证明了许多潜艇子系统的结构。例如，海水冷却和配平系统符合一种通用模式，可在不同级别的现代军用潜艇中识别。潜艇海水冷却系统通常由入口壳体阀门、管道、泵总成、热交换器（用于将热量从内部水冷却系统转移出去）和出口壳体阀门组成。潜艇配平系统的特点几乎总是在潜艇的两端罐体和泵总成，以转移罐体之间的水。

在传统的船舶设计实践中，潜艇子系统和设备的功能通常缺乏文档记录，但经验丰富的潜艇设计师对其有很好的理解。集成子系统的紧急行为还不太清楚。然而，由于潜艇概念设计主要集中在与尺寸、重量和功率相关的概念潜艇的空间定义上，捕获设备功能方面的系统行为可能对这些早期交易没有实质性贡献。

在概念设计阶段之后，可以对系统行为进行详细阐述，此时需要进行行为分析，以帮助更详细地了解硬件和软件的功能需求。 因此，在黑盒中识别子系统功能足以构成潜艇设计的初始功能体系结构的基础。作为黑盒规范的一部分捕获系统功能可用于将系统功能需求向下流动到子系统功能，并且当在后续设计阶段需要时，每个子系统功能可通过行为图进一步阐述。

当然，在设计的许多方面，必须尽早进行行为建模。例如，引进未经证实或全新的潜艇系统或设备需要了解这些系统或设备一旦与其他子系统集成后将如何工作。具有高度人机交互或包含高百分比软件的系统通常表现出非常复杂的操作行为，因此需要行为建模。在概念设计之后的阶段，预计行为建模将越来越多地用于指定子系统、设备和人-系统交互。

C.先画草图，再做模型

在SysML中设计一种标准的自顶向下的系统建模方法是可能的。这种方法可以从一组需求开始，并将函数标识为SysML活动。然后可以将这些活动分配给系统、子系统和组件（建模为SysML块）。系统分解将在BDD中定义，该系统的示意图将在IBD中定义。可以将这种方法描述为“SysML lite”。自上而下的方法将建议使用IBD来开发符合行业图纸标准的示意图，然而， 本文中描述的方法采用了不同的方法；因为Visio系统原理图的开发先于IBD系统的开发。这个决定有两个原因；为了更好地吸引领域工程师，商业SysML建模工具中缺乏标准符号库。

重要的是允许领域工程师在他们选择的工具中绘制他们的设计示意图（通常是microsoftvisio，但手绘图仍然非常常见）。这确保了工程师可以在一开始就专注于使他们的设计正确无误，而不会被使用SysML工具的复杂性所困扰或分心。 一旦领域工程师对他们的草图感到满意，那么就进行系统建模以使他们的设计正式化。 几乎所有人都发现，正式的系统建模过程有助于领域工程师从原始草图改进设计。首先，系统模型在名称和类型方面提供了更高级别的一致性。其次，领域工程师广泛报告了新接口的识别，并证明了系统模型即使在最早的设计阶段也能促进子系统集成。

此外，工程师需要用包含机械和电气部件标准符号的示意图来传达他们的设计。这些符号得到了业界的广泛认可，在SysML IBDs中使用这些符号的理由非常充分。下图提供了SysML部分的符号与ISO 14617中对应符号之间的比较。后一个符号清楚地向读者呈现了比前一个符号更多的信息。

不幸的是，当前的SysML建模工具缺乏这种“开箱即用”的能力，不希望出现的结果是领域工程师复制他们的原理图；在纸上；在Visio中；在SysML中，然后在CAD中（例如用于生产图纸）。大多数SysML工具确实提供了将图标应用于模型元素的能力，个别组织也做出了一些努力，以这种方式定制他们的SysML工具套件，从而为他们自己的工程团队提供这种能力。 然而，SysML社区仍在等待工具供应商提供商业解决方案。

D.失效模式及影响分析 FMEA

黑盒规范提供了系统功能列表，这些功能是早期故障模式和影响分析（FMEA）的有用起点。 对于每个功能，可以识别一个或多个故障模式，并且每个故障模式由一系列属性表征，包括唯一标识符、最终影响、原因、估计的严重性、可能性和危害风险指数。在概念设计阶段，故障模式的评估将是近似的，但仍允许子系统设计工程师识别和解决其设计中可能存在问题的方面。子系统设计工程师通常由熟悉典型潜艇子系统故障模式、原因和影响的可靠性工程师协助。随着子系统设计的进一步发展，对失效模式的严重性和可能性的估计也相应地进行了修改。

开发了一个元模型，用于在SysML中定义故障模式并将这些故障模式分配给黑盒功能。该模型扩展了标准的SysML语言，增加了描述故障模式的概念。 这是通过SysML构造型实现的。扩展SysML背后的技术理论非常复杂，超出了本文的范围，可以说原型是用一组自定义属性定义的。然后可以将构造型应用于模型元素，这将导致模型元素被扩展为附加属性。然后，元模型定义了不同的原型和模型元素如何相互关联。一个简单的FMEA元模型如下图所示。

例如，考虑下图中的暖通空调（HVAC）系统黑盒规范。黑盒的两个功能受FMEA约束，如“FMEAFunction”构造型所示。根据下图中的元模型，每个“FMEAFunction”可与一个或多个FMEA模型元素（每个表示分析）相关联，而每个FMEA模型元素又与表示所识别的故障模式、原因和零或多个影响的模型元素相关联。模型库中包含一组预定义的故障模式和原因，以限制创建任意或定义不清的故障模式或原因。

FMEA还可以与表示系统部件和状态的模型元素相关联。下图提供了HVAC系统的FMEA示例。

如下图所示 ，对于一个系统，多个FMEA项目的结果可以很容易地总结在一个表格中。 如果该表格中所示的FMEA数据是在微软公司Excel®电子表格中定义和管理的 ，它可以使用SysML参数与系统模型同步。

E. SysML 参数

工程分析和计算是设计综合的一个关键方面。 在大多数情况下，这项工作的结果定义或约束系统或其组件的属性。 考虑一个软件工具来计算潜艇电池系统的初始特性。这个工具可以在SysML中表示为一个约束块，它定义了一组参数和方程来表示调整大小的算法。在SysML中，参数图定义了如何将分析的参数绑定到相关系统的属性。

在下图中，（非常简化的）电池尺寸工具由约束块表示，该约束块将潜艇的期望特性作为输入并估计电池子系统的特性。

大多数SysML建模工具都提供了一个插件，可以远程执行外部数学解算器中的模型，这些解算器的参数与SysML约束块的参数匹配。这样，就可以将工程分析和计算与系统模型结合起来。这种能力通过在子系统架构（architecture）和工程（engineering）分析之间建立直接联系，提供了更高级别的设计可追溯性。

结论

本文概述了一种在SysML中建立潜艇子系统体系结构模型的方法。除了定义MBSE方法的主要目标之外，它还必须是实用的，因此本文的一个反复出现的主题是需要使不具备系统工程背景的领域工程师能够访问该方法。

以这种方式设计潜艇子系统的优势体现了MBSE的目标，即：改进设计一致性、精度、可追溯性、子系统集成和设计演化。本文概述的方法已作为综合潜艇设计活动的一部分进行了实践，并观察到了上述好处，特别是在子系统集成方面。

该方法成功的一个重要因素是使领域工程师能够访问系统建模。在造船业，传统的船舶设计实践仍然存在，这一因素不能低估。