卫星互联网MBSE建模规范

1本文件适用于卫星互联网体系、系统以及配2规范性引用文件ISO15288系统与软件工程-系统生命周期过程（SystemsandsoftwareenISO/IEC19540-2:2022信息技术-对象管理组统概要（UAFPInformationtechnology-ObjectManagementGroupUnifiedArchitectureFramework(OMGUAF)Part2:UnifiedArchitectureFrameworkProfil国际系统工程协会INCOSE.INCOSE3.3体系systemofsystems2BlockDefinitionDiagramProductLifecycleManagementChinaSatelliteNetworksGroupCo.司DepartmentofDefenseDepartmentofDefenseArchitectureFrameworkEnterpriseArchitectFailureModeandEffectsAnalysisFunctionMock-upInterfaceFunctionMock-upUnitEngineeringM&SModelingandSimulationMBSEModelBasedSystemEngineeringMBSOSEModelBasedSystemofSystemsEngineering3MoDAFMinistryofDefenseArchitectureFrameworkMOEMeasuresofEffectivenessMOPMeasureofPerformanceMOSObjectManagementGTextBasedSystemEngineerUnifiedArchitectureFrameworkUnifiedModelingLanguageVerification,ValidationandAccreditationWBSWorkBreakdownStructureMDOMultidisciplinaryDesignOptimization5.1建模原则f)可读性：命名包含中文名称，以便于查看者理解。5.2命名规则5.2.1结构命名规则模块命名规则为：“本层级标识符_父层级名称缩写_本层级名称缩写_中文全称_后缀标识”a)“本层级标识符”标识模块所在层级，采用“L+数字”字符组合，其中数字为“0”代表系统网络，4符，用于区分一代、二代，对卫星互联网系统功能拆解应符e)“后缀标识”为可选项，使用“设计”或“集成”，用于区分不同模型中的同一个设计对象。模型中名使用“集成”后缀，不同层级的Block命名规则及应符“端口名称_类型_方向”b)“类型”用于标识能量流、信息流、物质流的形式，如信息流的协议类型：“TCP”、“UDP”、c)“方向”为可选项，采用“in”、“out”或“inout”标识方向，命名不包含“方向”时“连接符”也同时省5.2.1.3交互项命名规则交互项命名规则为：“层级标识符_类型_英文缩写_中文全称_后缀标识”a)“层级标识符”标识模块所在层级，采用“L+数字”字符组合，其中数字为“0”代表系统网络，“1”b)“类型”用于标识不同设计阶段的交互项，使用“逻辑”或“物理”类型，逻辑类型用于概念设计阶段交互项定义，推荐用“L”字母表示；物理类型用于物理实现详细设计阶c)“英文缩写”为产生交互项源模块的英文名称的字母缩写；d)“中文全称”为交互项的中文名称全5.2.2需求传递编号规则需求传递编号规则适用于在模型中给下级团队定义下（Block）前缀_需求类型标识”+“.”+“编号数字”a)“对应模块（Block）前缀”指当前需求针对的模块（Block）的名称中“中文全称”之前的内容，“RR”代表可靠性需求，更多需求类型标识可在此基础上扩展；d)“编号数字”为需求的流水编号，采用阿拉伯数字1、2、3顺序增加；5.2.3行为命名规则用例命名方式为：“对应模块（Block）前缀_元素名称”5活动（Activity）命名方式为：“对应模块（Block）前缀_元素名称”规划子系统（MPS）的提供任务需求筹划b)“元素名称”为用例或活动的中文名称。5.2.4可靠性分析命名规则可靠性分析命名规则对FMEAItem元素的编号方式进行约扩展分析代码_序列号”a)“对应模块（Block）前缀”中的“对应模块（Block）”指可靠性分析针对的模块（Block使用可靠性分析条目；c)“序列号”为4位阿拉伯数字，从“0001”开始编号，依次向上增加。5.2.5体系模型命名规则体系级命名规则主要对各体系建模领域及视图以及下发给系统总体的需求进行标准化描述，包括领域名缩写、视图名缩写和下发需求缩写见表65.3模型表征样式a)表达结构分解的BDD图，建议仅展示模块（Block）和模块之间的关联关系，不展示模块内部a)IBD图用于展示Block内部的各部分之间的接口连接关系；b)SysML的IBD图可表达多种类型的接口关系，如供电、数据总线、软件协议等，对于一张图中存在多种不同类型端口连接时，建议使用不同颜色区分不同类型的端口和c)对于复杂IBD图，建议按照特定划分原则拆分为多张子IBD图，对图中内容进行局部展示，确75.3.3活动图样式布局a)活动图中的活动（Action）的输入输出引脚（pin需要同时展示pin的名称（Name）和类型b)跨泳道的对象流（ObjectFlow）上需明确定义跨泳道的ItemFlow；5.3.4用例图样式布局d)用例图在表达用例分析时，需要包含用例所属上下文、外部交互对象和用例本身。5.3.5注释信息注释信息用于对模型进行注释和说明，通过在模型中添加不同文字描述进行表达，a)对于需要后续解决的各类问题，通过添加“问题（Problem）”元素对当前问题进行文字描述；b)对于某些原理、依据类的文字阐述，通过添加“原因（rationale）”元素进行阐述和澄清。基于UAF复杂组织体系架构指南与领域建模实践，构建了一套通用的复杂网本文件体系建模采用复杂组织体架构建模语言UAFML（UnifiedArchitectureFra8为适应不同应用领域的情况，通常对UAF联网工程建模需求，使用UAF建模时一般不考虑人员、安防、项目等视角，行、服务、资源4个视角及其相应架构视图，并以迭代方式，执行复9b)规划战略愿景，包括能力演进的条件和状态，并识别能力所需的时间尺度；d)描述所需能力与阶段结构之间的映射，以及与相关挑战和驱e)识别复杂组织体系内部能力之间，及与外部能力f)将能力追溯到复杂组织体系的整体实际持久任务、价a)捕获顶层运行概念，并确定运行的约c)捕获运行行为，包括场景、活动动作、以及运行交换，如信息，物质c)捕获服务功能动作所隐含的结构关系d)指定服务接口，如提供和要求的服务方法、信号接收和/或流属性，以确保服务的兼容性和可b)定义资源架构间关系；c)建立任务成功度量MOS与能力有效性测度MOE步骤主要包括分析使命任务、捕获任务能力、分析能力关系、识别能力依推荐采用战略动机视图、战略分类视图、战略连接视图、战略流程视图、战略状态视a)推荐采用战略动机（St-Mv）运行流程描述支持或展现体系运行场景与业务活动、运行要素以及信息交互，现典型业务能力的运行场景、过程、活动，运行节点的组织关系、信息流和相步骤主要包括分析使命任务、捕获任务能力、分析能力关系、识别能力依e)推荐采用运行参数（Op-Pm）视图和运行约束（Op-Ct）视图，定义运行效能指标，以及指标f)推荐采用运行追溯（Op-Tr）视图，定义运行活动步骤主要包括设计服务结构、定义服务功能、定义推荐采用服务分类视图、服务结构视图、服务流程视图、服务状态视图、服务e)推荐采用服务参数（Op-Pm）视图和服务约束（Op-Ct）视图，定义服务元素效能指标，以及f)推荐采用服务追溯（Op-Tr）视图，定义服务元素资源架构分析的目的是捕获由各种资源（如软件、制品、运行架构中的运行元素或需求）组成的解决方案架构，为服务将使用的资源功能，以及基于资源架构规范可以为服务需要提供的信步骤主要包括建立系统需求、设计系统结构、定义系统功能、定义系统交析系统追溯，并为运行流程和网络服务提供物理实现，推荐采用资源分类视图、资源结构视图、资源流程视图、资源状态视图、资源e)推荐采用资源参数（Op-Pm）视图和资源约束（Op-Ct）视图，定义资源元素效能指标，以及本文件规定了一种通用的卫星互联网系统建模流程与方法，用于开展复杂卫星互联网系统建模工本文件采用OMGsystemsmodelinglanguage（SysML）标准建模本方法框架以面向对象建模思想为基础，遵循“需求-组成-行为-参数-可靠性”的五个支柱，深化提口等建模；“行为”面向场景、行为建模；“参数7.2.1.1获取并综合利益相关方7.2.1.3.2识别完整的利益相7.2.1.3.5规格化利益相关方a)利益相关方需要描述：从利益相关方视角，通过功能说明或指标量化的方式描述；b)利益相关方需要分类：需求分类包括但不限于功能性需求、非功能性需求和设计约束；d)使用SysML的需求列表或需求图，综合并建模利益相关方原始需要；a)确定系统的边界范围，识别和定义属于系统和不属于系统的部分；b)识别系统与外部的交互内容，协调系统级的交互接口，为后续系统级设计分析提供接口约束。a)系统上下文引入所有与系统有交互的外部元素，外部元素可为单个目标系统定义多个系统上b)系统上下文中的元素包括外部系统和用户、与目标系统交互、交换信息、物质、能量等；7.2.2.3.2定义系统与外部元素7.2.2.3.3定义系统与外部元素的接口确定目标系统需交互的外部元素，设计相应的外部接口b)使用SysML的内部块图定义系统与外部元素之间的交互项和交互关系、接口关系。a)将利益相关方的功能需求转换为系统功能实现、业务流程的描述；b)系统运行行为分析通过“场景”化描述，将利a)用例模型需展示系统在不同任务上下文中的预期结果及用户期望，明确的业务目标；b)构建系统用例，以“场景”描述的方式明确系统的利益相关方功能性需要；7.2.3.3.2定义系统用例行为b)每一个用例应该有一个主要场景及可选的替代场景。a)基于系统运行场景，从用户视角分析系统为满足功能要求的运行行为方式；b)从系统顶层视角细化业务流程，说明活动单元如何协同形成整体功能并对外提供服务；b)建议使用SysML活动图或时序图阐明用例实现的业务流程、“动作”分配关系及“动作”之间的交d)建议使用活动图，建模业务流程的运行逻辑、功能顺序。定义系统效能指标的目的是基于利益相关方性能要求，结合利益相关方功能要求和业务流程梳理b)确定参数，以描述用户对系统能力要求的量化程度。任务级失效模式与影响分析的目的、步骤、方法应符7.2.5.3.3生成任务级可靠性分析系统逻辑架构过程分析系统逻辑架构的目的、步骤、方法应符分析系统逻辑架构的目的是基于系统功能分解，定义系统内部的逻辑结构和各逻辑单元间的接口a)依据分析系统功能过程中所定义的功能组，识别出功能组对应的系统逻辑单元。b)逻辑单元可以分解为更细化的结构，分解的迭代次数取决于目标逻辑架构的颗粒度。7.3.1.3.2定义逻辑单元交互a)基于已识别的功能交互关系，梳理逻辑单元间的接口关系；b)定义逻辑单元的接口及其交互项，交互项涉及信息、物质或能量的交换。a)使用块定义图，建模系统逻辑单元、逻辑单元的组织、分类方式等；b)使用内部块图，建模逻辑单元交互关系、接口关系等。b)将利益相关方需要转变为系统需求，包括系统功能性需求和非功能性需求。a)识别系统功能，功能由系统任务和需求分析阶段的用例分析确定；a)基于用例生成的行为活动和识别的复杂系统功能进行系统功能分解；b)复杂系统功能细分为可识别的子功能，并确定系统内部功能和交互；b)功能架构的构建过程会产生多个备选方案，需要基于方案选择要求进行决策选a)每个逻辑单元负责执行一个或多个功能，但单一功能不得分配给多个逻辑单元；b)若存在将单个功能分配给多个逻辑单元的情况，则需进一步拆分并细化该功能；7.3.3.3.1分析逻辑单元性能a)根据系统效能指标和逻辑单元架构对系统性能指标进行分解、分配和计算；b)从利益相关者非功能性需要中直接提取性能指标；7.3.4.1开展逻辑单元级失效模式与影响逻辑单元级失效模式与影响分析的目的、步骤、方法应符合图17.3.4.3.3生成逻辑单元级可靠a)明确利益相关者需要与系统功能和逻c)明确表述需求层次之间以及需求与设计之间的关联关系，支持需求变更对相关需求和设计的定义系统需求的目的是将系统任务和需求分析、系统功能和逻辑架构分析中的利益相关方需要转b)系统需求分析流程从功能分析开展，进而进行系统性能量化分析，以及系统接口分析；d)系统性能需求用于量化系统功能，性能需求分析需考虑系统成本、实现f)系统需求应考虑环境需求、人因工程需求、可靠性需求、可维护性需求等；7.4.1.3.2建立系统需求与利益相关方需要间的追7.4.1.3.3建立系统需求与系统效能指标间的7.4.1.3.4建立系统需求与系统功能/逻辑架构间的追溯a)基于系统功能和逻辑架构分析过程中所识别出的功能架构和逻辑架构，明确每个逻辑单元的物理实现方式，形成由一系列物理单元组成的系统解决b)基于物理接口定义明确不同物理子单元的交互关系和方式。7.4.2.3.1定义系统解决方案7.4.2.3.2建立系统逻辑架构与解决方案架构的关7.4.2.3.3定义系统内部接口关系交a)使用SysML块定义图，建模系统解决方案，建立系统逻辑架构与解决方案架构关联关系；b)使用SysML内部块图，建模系统内部接口关系与交互项。7.4.5.1开展系统级失效模式与影响分系统级失效模式与影响分析目的是在继承任务级和逻辑单元级失效模式与影响分析的结果后，对7.4.5.3.3生成系统级可靠性使用SysMLFMEA表，对系统级失效模式、系统级失效影响和系统级可靠性需求等进行建模。组织相关人员通过在线预览方式查看模型，并借助批注工具完成审b)在本地创建好相关模型后，提交至协同建模环境上。a)采用模型分支方式开展模型下发的，模型集成采用分支模型合并方式开展；a)设计师完成模型搭建后，通过协同建模环8.5.3数据存储8.5.4关联信息记录b)用户启动PLM平台中的系统架构设计工具客户端后，打开所选模型文件或通过检索定位到协8.6.1基于协同建模环境的模型版a)用户建模完成后需提交至协同建模环境，可根据实际情况添加标签和说明；b)进行模型下发时创建分支下发；c)出现设计偏差时，可使用模型历史版本回溯恢复a)基于PLM平台，MBSE模型数据可借鉴文档的方式进行管理；b)模型数据审批到已发布，数据不能编辑修改；9卫星互联网MBSE模型早期验证方法9.1概述a)应用场景验证：基于体系仿真工具/体系效能评估工具，在具体业务应用场景中进行体系视角b)逻辑验证：基于SysML模型的活动图、状态机图、时序图进行卫星互联网业务流程、运行逻9.2应用场景验证规范9.2.1概述本文件规定了一种综合运用体系架构设计模型与体系仿真工具和效能评估工具，开展体系模型早b)验证输入：基于体系架构方法构建的卫星互联网体系模型。2)卫星互联网关键要素：运营策略、目标、服务区域、运行体系边界与约束；9.2.2验证目的c)能力指标拆解：分析卫星互联网能力指标，为系统和分系统能力需9.2.3验证步骤9.2.4验证方法9.3逻辑验证规范本文介绍了一种基于系统建模工具的逻辑验证通用方法。主要通过在系统建模工具中构建行为图实现对卫星互联网业务运行流程、状态切换、内部组成交互等9.3.2验证目的9.3.2.1基于活动图的业务流程验证目的a)验证业务运行流程中各参与d)验证业务运行流程中系统内部各组成部分间、系统内外之间交互项与接口匹配性。9.3.2.2基于状态机的系统状态转移验证目的9.3.2.3基于时序图的系统交互验证目的9.3.3验证方法1)针对业务流程验证，使用活动图的方法，明确活动内容和活动的输入输出；9.4参数场景验证规范9.4.1概述a)支持卫星互联网内部复杂系统不同设计、仿真工具之间的9.4.2验证目标9.4.3验证步骤9.4.3.1确定验证参数9.4.3.2确定参数验证条件9.4.3.3构建参数验证模型b)构建仿真流程模型中的各节点模型，并定义每个仿真节点模型中与系统设计模型对应