军工产品基于模型的系统工程技术状态管理研究

军工产品基于模型的系统工程技术状态管理研究

田建华

西安爱生技术集团有限公司  710065

摘要：

基于模型的系统工程（MBSE）作为系统工程的新范式，利用模型提高系统理解和沟通效率。在全球和全国范围内，MBSE均在快速普及和发展。本文讨论了MBSE背景下的技术状态管理相关问题，包括技术状态管理对象、过程实施在新条件下的新变化、新特点以及和传统管理要素的对应关系。通过对管理对象和管理过程的分析，发现MBSE借助模型定义和产品生命周期管理系统可以在降低人员工作量的同时显著提升产品和管理质量，其持续推进对于我国制造业向高端化智能化转型升级具有重要的现实意义和战略价值。

关键词：基于模型的系统工程、技术状态管理、SysML

1 概述

基于模型的系统工程（Model-Based Systems Engineering，简称MBSE）是一种系统工程实践的新范式，其核心在于利用模型作为系统描述、分析、设计和管理的主要载体。与传统的基于文档的系统工程方法相比，MBSE强调通过构建和利用系统模型来促进更高效、精确的系统理解和沟通，从而提高系统工程的效率和质量。

在全球范围内，MBSE自20世纪90年代末期开始逐渐受到关注，并在21世纪初迅速发展成为系统工程领域的重要趋势。国际系统工程学会（INCOSE）和电气与电子工程师协会（IEEE）等机构在推广MBSE理念和标准方面发挥了关键作用，国际标准组织（ISO）围绕MBSE发布了大量相关标准，包括ISO/IEC/IEEE 15288（系统生命周期模型）[1]、ISO/IEC/IEEE 29148（需求工程）[2]、ISO/IEC 19501（统一建模语言UML） [3]、ISO/IEC 19514（系统建模语言SysML） [4]、和ISO/IEC/IEEE 18018（配置管理工具能力指南）等。美国国防部（DoD）、欧洲航天局（ESA）和众多跨国公司都在其重大项目中广泛应用MBSE，特别是在航空、航天、国防和汽车等行业，MBSE已成为系统工程实践的标准配置。

在中国，MBSE的概念和实践也在快速发展。近年来，随着我国对自主创新和高质量发展的重视，MBSE作为提升系统工程能力的关键技术，得到了政府、科研机构和企业的广泛认可。国防科工局、中国航天科技集团、中国船舶重工集团等单位积极推动MBSE在重大项目中的应用，同时，在国内工业界推广MBSE本身也是一个规模巨大的系统工程，需要在建模技术和工具链、管理技术和工具以及人员培训方面长期持续努力。在转型过程中，传统系统工程管理体系和技术也会面临新的挑战。

在MBSE的发展过程中，从用于软件工程的统一建模语言（UML）中发展而来的，专门用于系统工程的系统建模语言（SysML）逐渐成为了系统工程领域中的主流建模语言。SysML的主要特点为使用组件元素和九种视图对系统需求、功能分析、架构设计、系统结构和行为进行建模，已广泛应用于航空航天、国防、汽车等领域，是基于模型的系统工程(MBSE)核心工具。

技术状态管理（Configuration Management，CM）在系统工程中扮演着至关重要的角色，它是确保项目成功和系统可靠性、可维护性和成本效益的关键因素。技术状态管理确保了系统定义在全生命周期的一致性和可追溯性，通过变更控制降低了研制过程风险和成本。随着MBSE的不断推进，产品定义的载体从文档、图纸转向数字模型，产品技术状态管理的对象和管理活动也因此发生了相应变化[9]。本文旨在研讨在MBSE条件下的技术状态管理相比传统技术状态管理在内容对象和管理活动方面的变化。

2 MBSE条件下的技术状态管理对象

依据2022年发布的GJB3206B-2022技术状态管理 [6]，技术状态的定义为“在技术文件中规定的及在产品中的达到的功能特性（产品的功能、性能和设计约束条件）和物理特性（产品的组成、形状、尺寸、配合、公差、质量等）”。规定功能特性和物理特性，或从这些内容发展而来的关于试验、生产、使用、维修和退役报废处理要求的技术文件（或技术状态信息数据）即技术状态文件。技术状态管理的主要对象即为技术状态文件。MBSE条件下，技术状态文件的形式转向数字模型，但系统模型的具体内容与GJB3206B-2022中要求的技术状态文件类型如何对应还缺乏统一、一致的理解。本章首先分析各类技术状态文件的内容要求，再对应描述相应的系统模型形式。

技术状态文件可分为功能技术状态文件、分配技术状态文件和产品技术状态文件。功能技术状态文件规定了产品的功能特性、物理特性和上述特性验证要求。分配技术状态文件规定了产品组成的功能特性、物理特性和上述特性验证要求。产品技术状态文件规定了产品制造或购买所有必须的功能特性、物理特性和上述特性检验验收要求的技术状态文件。

2.1 功能/分配技术状态文件

功能技术状态文件和分配技术状态文件的区别主要体现在产品层级上。对于军工产品，功能技术状态文件主要包括军方批准下发的研制任务和研制总要求等文件以及研制单位依据下发文件和其他相关信息编制的设计输入文件，此类文件还包括系统研制任务书、系统规格说明（软件）、研制方案、系统规范等。分配技术状态文件的主要输入为上级研制单位下发的研制任务书和系统设计说明（软件）等，相应文件还包括配套产品的研制方案、研制规范等。

针对此类文件中规定的内容，在SysML语境中存在相应的模型视图对相关内容进行定义。下面展开说明。

2.1.1 需求文件

在系统工程中，需求文件可分为利益相关方需求和系统需求。利益相关方也被称为用户需求或市场要求，是指系统预期的最终用户、客户以及其他利益相关方所期望系统应该满足的功能和非功能特性。这些需求通常是从外部视角提出的，反映了系统在实际使用场景中应达到的目标和期望，包括性能指标、安全性、可用性、成本限制、法律合规性等。系统需求则是从系统工程师或设计师的角度，对利益相关方需求进行细化和转换后形成的，它们描述了系统必须具备的特性和能力，以满足利益相关方的需求。系统需求通常是技术性的，详细说明了系统应该如何工作，包括功能需求、性能需求、接口需求以及约束条件。系统需求是系统设计和实现的基础，指导了系统架构的选择、设计决策和开发活动。利益相关方需求与系统需求之间存在密切的关联和转化过程。系统工程师通过需求工程活动，将模糊的利益相关方需求转化为具体、可实现的系统需求。这一过程涉及到需求的分析、分解、细化和优先级排序，确保系统需求既满足利益相关方的期望，又具备可实现性和可验证性。

在SysML中，定义系统需求的核心视图是需求图。需求图主要用于清晰地展示和组织系统需求。它通过图形化的方式，将系统需求以节点的形式呈现，并使用连接线表示需求之间的关系，如依赖、派生和跟踪。需求图帮助系统工程师和利益相关者更好地理解需求的全貌，确保需求的完整性和一致性，同时也便于需求变更管理和追溯性分析。在基于模型的系统工程（MBSE）实践中，需求图是需求工程阶段的关键工具，支持需求的定义、分析、验证和管理。其他的需求管理工具还包括Rhapsody、DOORS等。

同时，在进行需求分析的过程中，为了描述系统的行为特征还会使用用例图（明确系统边界和功能范围）、序列图（定义系统与外界交互过程）、活动图（定义系统业务流程）、状态图（定义系统状态）。

在需求模型中，基础元素为目标系统、系统交互对象、系统上下文元素、需求元素以及行为特性视图。整个需求模型按照从使命任务到具体功能的分解追溯关系组织，系统性能、接口、质量特性、约束等需求围绕具体功能展开，描述功能实现的用例、交互、状态等视图追溯功能。

值得注意的是，系统工程中进行的特性分析、FMECA分析、FTA分析、危险源分析过程等在模型上同样可以体现，相应的分析模型在需求分析阶段同样围绕功能组织构建，最终形成能够完整描述产品功能特性的系统模型。

图1 需求模型组织

通常，利益相关方需求输入以各种文本类型（研制任务、合同、研制总要求、法律法规、强制标准等）存在，组织通过整理建模汇集成利益相关方需求模型，作为系统需求分析基础；再通过对利益相关方需求进行分析、细化、展开、排序形成准确、协调的系统需求模型。装备总体的利益相关方需求模型和系统需求模型属于功能技术状态文件，配套产品的利益相关方需求模型和系统需求模型属于分配技术状态文件。

2.1.2 方案文件（含接口控制文件）

基于文本的系统工程过程中，系统的分配技术状态文件的重要组成部分为装备技术方案或设计报告。技术方案中依据系统需求描述目标系统的组成、工作原理、工作模式、接口、各组成需要满足的要求，并通过描述系统指标的核算、仿真、原理试验等确保系统性能指标的实现。

在基于模型的系统工程中，系统设计的过程体现为系统架构模型的构建。系统模型通过定义系统内部结构和其组件的相互关系实现系统需求。系统架构的定义通过对系统需求（功能架构）的分析，得出系统逻辑架构，进而形成系统物理架构。在架构生成的过程中，基于需求对备选架构进行效能评估，并最终通过对效能比较的权衡，确定最终的架构。

在SysML中，系统架构的结构部分通过块定义图、内部块图描述，描述内容包括系统组成和各组成之间的静态接口关系；内部组成的相互动态关系仍通过活动图、序列图和状态图描述。系统内部的动态关系，即系统功能实现过程最终需追溯系统需求中的每一条功能需求。系统性能指标实现通过SysML中的参数图或Modelica、Simulink等专业仿真模型语言建模体现。

系统架构模型追溯系统需求模型。每一条系统需求均需要系统架构模型追溯实现，实现方式包括传递（系统需求直接传递给某一组成）、分配（系统需求拆解分配给数个组成）和衍生（系统需求通过方案原理衍生出一系列组成的需求）。在基于模型的系统工程中，这种追溯关系可以通过模型显性的表达出来，便于审查核验。系统架构模型中对系统需求的分配构成了配套产品利益相关方需求的主要组成部分。配套产品的研制组织基于系统架构生成的相关需求，结合其他设计约束和行业要求形成该配套的利益相关方需求。

图2 系统模型衍生过程与分类

2.1.3 系统/研制规范

依据GJB 6387-2009武器装备研制项目专用规范编写规定 [7]中的定义，系统/研制规范规定了装备系统及其配套产品的功能特性、接口要求和验证要求，相比利益相关方需求和系统需求，系统/研制规范中主要增加了对系统功能特性的验证要求。

在SysML中，对需求的验证要求一般也通过需求元素体现。在需求元素的标准模板中，存在标识为的需求元素，此类需求元素专门用于描述对需求元素的验证要求，通过扩展此类元素内涵，可以表达对相应需求的检验分类、检验条件、检验方法、合格判据、质量一致性检验抽样方案、缺陷分类等。通过模型的显性追溯功能，实现对所有需求的完整追溯。系统/研制规范的内容要求可以通过在系统需求模型中扩展验证模型完全覆盖。

出于实际使用的需要，系统/研制规范现阶段仍不能脱离依赖文本单独以模型形式存在，但可以利用系统模型的信息直接生成文档以确保相应规范与模型的一致性。系统规范属于功能技术状态文件、研制规范属于分配技术状态文件。

2.2 产品技术状态文件

产品技术状态文件主要包括产品规范、产品试验文件、产品制造文件、产品使用维护文件等。在MBSE条件下，相应的技术状态文件也具有了新的形式。

2.2.1 产品规范

产品规范相比系统/研制规范，增加了对产品物理特性的规定。由于产品的物理特性在系统设计过程中通过系统物理架构模型进行了描述，因此产品规范中增加的物理特性内容可以追溯至系统架构模型。

同样，出于实际使用的需要，产品规范还不能脱离文本形式。因此可以使用模型工具从系统需求模型和架构模型中生成产品规范文档。

2.2.2 产品试验类文件

产品试验类文件主要包括产品研制过程中各类专项试验文件，如功能性能试验大纲、环境适应性试验大纲、电磁兼容性试验大纲、可靠性维修性试验大纲等。此类文件仍属于对产品特性的验证要求范畴，在SysML中通过对需求图加以扩展即可实现模型化。

2.2.3 产品制造类文件

产品制造类文件主要包括用于产品制造的图纸、工艺文件等。目前，产品图纸已基本实现了模型化，例如产品的三维数字模型、用于虚拟装配的数字样机等。相应的工艺文件也在产品模型化的基础上同步实现了模型化。

产品制造信息主要以由系统架构设计而来的产品物理特性为基础展开，因此产品制造模型的组织是以产品装配关系为基础组织。产品工艺定义了产品由底向上逐步组装的实施过程。基于模型的工艺（Model Based Process）通常与CAD系统和PLM系统集成，实现制造信息的数字化流转和使用。

2.2.4 产品使用/维修/退役类文件

传统的产品使用/维修/退役类文件主要包括产品技术说明书、产品使用维护说明书等文本类文件。目前相应的使用类文件已有基于模型的电子技术手册相关标准[8]，即装备交互式电子技术手册。该标准将传统的技术手册内容按照数据模块编码和数据字典的方式重新组织，形成了类似维基百科形式的相互跳转引用和以交互式互动方式说明装备使用方式为特点的手册模型。当然，出于使用方便的因素，传统的产品使用/维修/退役类文件仍将持续存在，但可以基于一定的规则从交互式电子技术手册中直接生成，保证纸介质文件和电子文件模型的一致性和协调性。

2.3 小结

综上所述，在基于模型的系统工程条件下，技术状态管理要求的各类技术状态文件均可直接采用相应的系统模型或基于模型生成。技术状态管理的对象可以直接转变为管理系统的相应模型，使用时需要的对应文档可直接基于模型生成。

图3 模型与文档的替代与生成关系

3 MBSE条件下的技术状态管理活动

基于以上分析，MBSE条件下技术状态管理的对象可以从对文档的管理转移为对模型的管理，仍需要以文档形式存在的技术状态信息可以从模型中直接生成文档，实现文档与模型的协调统一。因此，相应的技术状态管理活动也应基于系统模型相比于传统文档的相应特点进行调整。下面针对每项技术状态管理活动逐项分析。

3.1 技术状态管理策划与监督

技术状态管理策划与监督主要面向技术状态管理活动本身，是针对管理活动的管理活动。技术状态管理策划的内容主要包括确定管理目标、管理相关方的职责权限、管理过程资源需求、管理过程活动的输入输出、控制准则和方法。技术状态管理监督主要包括对本单位和配套单位技术状态管理过程的监督检查。策划的主要内容和原则应满足组织技术状态管理的实施细则，仅针对特定项目的人员赋权和资源需求进行额外要求。

MBSE条件下，技术状态管理活动必须与PLM（产品生命周期管理系统）全面融合，因此其策划过程也必然在PLM系统中完成。相比传统技术状态管理策划过程，技术状态管理信息系统内禀定义了管理过程的输入输出、控制准则和方法。单个项目的管理策划工作主要包括在组织内向负责人员授权并分配相关资源，定义技术状态管理信息的流转、审批规则。在技术状态管理信息系统中，内部监督审核过程与所有管理活动同步进行，外部审核通过调阅信息系统技术状态管理信息完成。

3.2 技术状态标识

技术状态标识是技术状态管理活动中最为重要和基础性的工作。主要包括建立维持产品结构、确立技术状态项、技术状态文件的策划及编制发放要求、产品和文件标识、技术状态基线建立。

产品结构的构建与维持与系统架构模型的建立和维持同步进行，其内容应与系统架构模型中的逻辑架构和物理架构保持一致。技术状态项从产品结构中选出，在系统架构模型中进行标识。相应技术状态项的技术状态文件在MBSE背景下转变为相应的系统模型，包括需求模型、架构模型、数字样机及工艺模型、产品交互式电子技术手册等使用文件模型。按照组织或甲方确定的标识规则对产品和模型文件进行标识。技术状态基线是在相应技术状态审核完成后获得组织批准的技术状态文件，建立基线本质上是对批准的技术状态文件进行基线标识。

技术状态标识活动在MBSE背景下完全通过信息系统完成，其输入除了组织体系定义的技术状态管理实施细则和规则外，主要来自于系统架构模型。主要管理活动包括：

1. 提取系统架构模型中的相应元素定义和块定义视图构成产品结构；
2. 在产品结构中确立标识出技术状态项，并在模型中进行标识；
3. 在技术状态项清单基础上策划所需的模型清单和文件清单，明确模型编制规范和传递要求；模型编制规范和传递要求一般为组织体系文件。模型清单和文件清单应在PLM系统中以数据库表单的形式存储；
4. 对所有产品结构组成和相应技术状态文件进行唯一标识，同步存储在PLM数据库表单中；
5. 在技术状态审核批准后，将确定版本的技术状态模型标识为技术状态基线。

需要特别说明的是，技术状态文件的发放在MBSE背景下体现为相应需求、架构模型的传递，由于使用模型组织的权限不同，不同组织对于同意模型的权限也不同。为了确保整个模型体系的协调同意，技术状态标识过程中应该为模型的不同部分标识不同的读写权限。例如系统总体的需求工程师具备系统需求模型的更改权限；架构工程师具备系统需求模型的阅读权限，但不具备需求模型的更改权限，其负责更改的系统架构模型要实现对需求模型的全面追溯并形成需求分配矩阵；当模型向下一级技术状态项流转时，传递部分包括系统需求模型和系统架构模型中与下一级技术状态项相关的部分，下一级组织具备对上一级模型传递部分的阅读权限，并依据上一级模型构建本级的需求模型和架构模型。

总体而言，基于模型的技术状态标识活动主要应借助可接入模型的PLM系统完成，其主要输出的技术状态项和文件清单及相应标识应保存于PLM系统相应表单中，并与相应的技术状态模型保持一致。

3.3 技术状态控制

技术状态控制的主要内容包括技术状态变更控制和技术状态偏离许可及让步，重点是变更控制。

在变更控制方面，基于模型的变更控制和基于文档的变更控制在过程上并无不同，其主要控制对象也是针对产品的功能基线、分配基线和产品基线。GJB3206B-2009中规定了正式的技术状态变更程序要求，但同时说明了在状态基线建立前的变更控制过程要求由组织内部确定。

在研制方的实际研制过程中，由于制造、试验过程的种种需求，在批准的产品各状态基线外（主要状态分支）外，还存在用于试验测试、非产品用途的临时使用等游离于状态基线之外且必须在一定程度上实施控制的技术状态。因此在模型状态控制的实施层面，一般建议采取类似软件配置管理的“三库”体制，即开发库、受控库和产品库。开发库提供模型开发人员的工作空间，提供内部版本管理、分支管理、合并管理等配置管理功能，其变更主要为模型开发团队内部控制；受控库保存在研制过程中已被批准的基线模型，其变更必须满足GJB3206B-2009中技术状态变更的过程要求；产品库保存需要最终交付的产品模型，其变更和出入库管理需要严格控制。三库逻辑上独立，物理上一体，保持模型开发历史的可追溯性。

对于技术状态偏离和让步，由于不涉及技术状态的变更，因此其主要管理过程在PLM系统中实现。

3.4 技术状态记实

技术状态记实的主要内容为对技术状态相关信息的记录、分析评价、形成报告并归档保护。技术状态计时的主要工作应主要借助技术状态管理信息系统实现，相应管理人员完成分析评价的工作并由信息系统直接生成技术状态记实报告并归档保存。报告内容包括相应模型的状态历史和基线信息以及验证审核整改过程记录。

3.5 技术状态验证与审核

技术状态验证与审核工作主要包括验证、一致性检查和审查。

基于模型的技术状态验证（Model Based Technical State Verification， MBTSV）相比传统的技术状态验证方法，增加了早期模型验证、自动化逻辑验证、系统模型仿真、数字样机虚拟试验等验证方法，在验证过程管理中基于模型和追溯关系实现了需求全覆盖，摆脱了人员组织在验证过程中可能发生的疏漏和早期逻辑问题难以发现导致的高成本变更问题，在深度和广度上有了明显的飞跃。基于模型的技术状态验证具有以下显著特点：

1. 全面性：基于模型的验证可以全面覆盖系统的所有方面，包括功能、性能、接口、行为和约束，确保系统设计的一致性和完整性。
2. 早期检测问题：通过在设计早期阶段使用模型进行验证，可以及早发现和解决潜在的设计缺陷，避免后期更改带来的高成本。
3. 自动化：MBTSV使用自动化工具，可以自动执行复杂的验证任务，如模型检测、仿真和形式化验证，提高验证效率和准确性。
4. 可追溯性：基于模型的方法支持需求到设计再到验证结果的双向追溯，确保每个需求都被正确实现和验证。
5. 迭代验证：模型可以随设计的迭代而更新，每次迭代都可以重新验证，确保设计的持续改进和优化。
6. 多学科集成：MBTSV支持跨学科的集成验证，不同领域的模型可以在统一的框架下进行交互和验证，促进系统层面的集成。
7. 模拟和仿真：模型可以用于创建虚拟原型，通过模拟和仿真技术验证系统在不同条件下的行为，减少对物理原型的依赖。
8. 形式化方法：在某些情况下，MBTSV可以采用形式化方法，如模型检测和定理证明，确保系统设计的数学正确性。
9. 决策支持：模型验证的结果可以为决策提供依据，帮助工程师和管理者做出基于数据的决策。
10. 重用和标准化：基于模型的方法鼓励模型和验证过程的标准化，有利于模型和组件的重用，节省时间和资源。
11. 风险管理：MBTSV有助于识别和管理技术风险，通过模型分析预测潜在的问题点。
12. 持续验证：基于模型的验证是一个持续的过程，贯穿于整个系统生命周期，从需求分析到退役阶段。

基于以上分析，基于模型的技术状态验证应在传统实物验证的基础上，重点增加各类模型、仿真的验证方法，在管理方法上按照研制的不同阶段采用不同方式分阶段实现模型验证，从而在需求广度和验证深度两个方面提高验证质量。

同样，基于模型的技术状态一致性检查和审查也由于模型的存在使自动化、半自动化审查成为可能，相比基于文档的技术状态审查，降低了人员审查工作量的同时提高了审查质量。其主要特点包括：

1. 数字化和可视化：基于模型的审核依赖于数字模型，这些模型提供了系统的可视化表示，使审核过程更加直观和高效。
2. 一致性检查：通过比较模型与设计规范、标准或先前批准的状态，可以自动或半自动地检查一致性。
3. 自动化支持：使用自动化工具进行模型检测、仿真和分析，减少人工错误并提高审核速度。
4. 可追溯性：基于模型的审核支持从需求到设计、测试和生产过程的双向追溯，确保每个阶段都得到适当验证。
5. 实时监控：数字模型可以实时更新，使审核人员能够及时了解技术状态的变化。
6. 多学科集成：MBTSA支持跨学科的集成，确保系统的所有组成部分都符合其技术状态。
7. 决策支持：基于模型的审核提供了详细的技术状态信息，有助于管理层做出基于数据的决策。
8. 风险管理：通过模型分析，可以识别和评估技术风险，提前采取措施降低风险。
9. 持续改进：MBTSA是一个持续的过程，随着项目的进展，可以不断优化和调整审核策略。

基于模型的技术状态审核工作应重点推进模型检查工具的开发，并建立不同类型系统模型的审查规则。

技术状态验证和审查是针对技术状态开发的质量保证活动。质量保证活动的实施原则之一是尽量嵌入设计开发活动，尽可能早期发现问题，降低项目的资金和时间成本。采用基于模型的技术状态验证和审核技术，可以是自动化验证和审核有效嵌入模型开发过程，使问题得以更加早期发现和化解，能够有效降低产品的质量风险。

4 结论与展望

本文对新时代基于模型的系统工程技术状态管理对象和过程进行了全面系统分析，提出了相比传统系统工程技术状态管理方式的主要差异和对应关系。总体而言，采用基于模型的技术状态管理可以有效提高管理效率、管理准确度和管理质量，降低人员工作量和错误概率。然而实施基于模型的技术状态管理本身需要组织投入资金和专门人员进行开发、运行和持续改进，其本身也是规模复杂的系统工程。在我国制造业向高端化智能化转型升级的历史当下，推进基于模型的系统工程实施具有重要的现实意义和战略价值。

参考文献

[1] ISO/IEC/IEEE 15288:2023, Systems and software engineering -- System life cycle processes[S]. Geneva: International Organization for Standardization.

[2] ISO/IEC/IEEE 29148:2018, Systems and software engineering -- Engineering life cycle processes -- Requirements engineering[S]. Geneva: International Organization for Standardization.

[3] ISO/IEC 19501:2005, Information technology -- Open Distributed Processing -- Unified Modeling Language (UML) version 1.4.2[S]. Geneva: International Organization for Standardization.

[4] ISO/IEC 19514:2017, Information technology — Object management group systems modeling language (OMG SysML)[S]. Geneva: International Organization for Standardization[S].

[5] ISO/IEC TR 18018:2010, Information technology — Systems and software engineering — Guide for configuration management tool capabilities [S]. Geneva: International Organization for Standardization.

[6] GJB3206B-2022, 技术状态管理[S]. 北京: 国防科学技术工业委员会, 2022.

[7] GJB 6387-2009, 武器装备研制项目专用规范编写规定[S]. 北京: 国防科学技术工业委员会, 2009.

[8] GJB 6600.1-2008, 装备交互式电子技术手册[S]. 北京: 国防科学技术工业委员会, 2008.

[9] 盛步云,夏杰,陈贻堃,等.面向铁路电气产品的技术状态管理方法研究[J].机械设计与制造工程, 2020.DOI:10.3969/j.issn.2095-509X.2020.07.018.