基于模型的协同设计工程实践与应用

一、行业现状与国外发展趋势分析

1.1复杂装备产品发展趋势

随着复杂装备产品的发展呈现小型化、集成化和多专业融合等趋势，技术要求与难度越来越高，同时要求的研发周期也越来越短，竞争形势也越来越激烈。随着国家提出的体系级作战要求，产品无论在作战能力、系统集成度、系统复杂度以及系统构型等多个维度都呈现较大的转变，仅通过系统或单机的局部改进和优化已难以满足来自军方、市场的要求。系统复杂度越来越高，核心体现在：

1）互操作有独立向基于共享资源进行交互；

2）接口定义从功能性松耦合向高度综合发展；

3）系统间的关联从离散向高度网络化互联发展；

4）失效模式分析困难，系统功能间交互耦合度高。

以航电系统为例：

△ 分立式（上世纪40~50年代）：各个子系统互相独立，分别有传感器、信号采集、处理到显示和控制一整套设备。

△ 联合式（上世纪60~70年）：可进行统一的信息调度和系统管理，解决了部分信息共享和综合显示控制的问题，其标志是1553B总线的应用。

△ 综合式（上世纪80~本世纪00年代）：将系统划分为不同的功能区，形成模块化的航电系统架构，应用高速光纤总线，实现任务信息和数据的综合处理。

△ 高度综合式（近年来）：进一步加强通用化、模块化和标准化的架构特点，并重点解决成本、重量、体积、功率和可靠性等问题。

1.2协同设计现状分析

随着复杂装备产品高度综合化的发展，用户需求不断随战局或市场变化而变化，逐渐发现传统的研发手段已不能满足产品发展的趋势，核心体现在如下三点：

△ 沟通交流、一堵墙

在协同与沟通层面，目前国内的产品研发的组织模式，多按专业进行部门的划分，在产品研发过程中，设计到各个专业间的协同与协作，随着系统复杂度的提升，协同协作、快速敏捷、持续迭代的模式，对于传统基于专业的部门组织模式带来了冲击。协同过程中部门墙明显，沟通协同层层关卡、出处碰壁，严重制约着产品协同的效率。

△ 表意模糊、分歧多

目前专业间跨过部门墙的手段就是相关的设计文档、任务书等文档，但此种文档协同模式，也逐渐体现出其瓶颈，难以满足高度并行的协同研发需要，主要体现在：

1）设计信息不显性：设计的信息要素都在文档中，通过文档进行数据的交换，文档中对于设计要素阐述的规则、标准难统一，描述质量层次不齐；

2）文字理解存差异：项目中每个人的专业领域不同，文字的描述和定义，不同设计师的理解存在差异性；

3）关联信息难一致：设计信息在不同的文档中反复引用，一旦更改，存在更改不全面的风险，易造成信息不一致，影响设计技术状态的控制；

4）信息追溯不连贯：在文档中难以显性化的描述信息间的关联性，例如：对于需求分解、实现、验证过程，目前多通过文档承载，对于需求是否验证满足，需要人工进行核查；

5）经验知识难复用：方案设计对于产品成败的影响深远，往往80%的产品成败取决于方案，但此部分的设计思路、分析过程多通过文档进行承载，知识多存储与有经验的设计师头脑中，知识难以沉淀与服用；

6）文档交互时效差：目前多基于文档结果进行串型的专业间协同，迭代周期较长。敏捷的快速迭代过程，则需要设计的过程要素显性可交互，目前文档的模式较难支撑。

为解决文档协同的上述瓶颈，很多单位通过过去10年的信息化、数字化投入，已开始通过模型对产品进行定义，但各类专业语言间语法不通、产品定义的维度不通，在协同沟通层面依然存在以下问题：包含沟通模型语言差异大，专业间理解不统一；专业模型仅专业内部使用，异构模型难以集成应用，难以对产品进行综合评估；在定义接口时，不通模型语言的表达方式难以统一等。

△ 信息传递、断点多

因此通过对系统工程“V”模型中各个环节剖析不难看出，在系统工程各产品层级的研发过程中，虽然引入了很多模型定义的优秀设计方法与工具手段，但信息传递存在断点，信息的一致性、完整性、有效性难以保障，上下游协同难以基于统一的上下文环境进行沟通。具体的断点问题如下图所示：

1.3国内协同设计平台建设现状

在国内，复杂装备研发企业和先进军工企业均比较注重多学科多专业协同设计平台的建设。各单位均正在开展或准备开展协同设计平台的建设。目前协同设计平台的建设主要分为如下几种建设模式：

△ 仿真为核心：其核心关注仿真经验知识的沉淀，通过仿真手段的组合，实现对产品全面的虚拟化评估与快速的迭代优化；但其依然难以解决，基于仿真结果的协调，所占立场多以专业自身为主，分歧难以协调，对系统缺乏统一的理解与评估。

△ 流程协同：其核心通过流程打破部门墙，驱动不同专业人员，面向产品研发的核心业务开展协同与协作，同时实现对工具的统型集成，并提供专业知识的推送；但此类协同模式，多以管控手段驱动协同，专业间协同的自发性较弱，设计与仿真的活动相对割裂。

△ 统一建模工具：其核心统一建模工具的导入提供了系统、专业间协同沟通的统一表达，消除专业间对系统理解上的误差，实现了对产品更加全面的定义，同时设计要素全面显性化，利于知识沉淀；但此种模式与传统模式相比转变巨大，绝非单点工具引入这么简单，需要体系化的构建，包含与仿真、专业设计间的协同，模型数据技术状态管控等问题。

△ 机电软协同：其核心解决详细设计阶段的学科间协同与协作，提升产品的实现质量，通过多场耦合对产品的物理性能提供了综合评估；但协同的层级较低，难以发现设计过程中的核心问题。

1.4国外趋势分析

基于上述对产品形态发展趋势与现有研发手段的分析，可见要想设计出满足时代发展、具有市场竞争力的产品，除了在专业知识领域的不强，还需要结合数字化、信息化的手段，对研发创新能力进行转型提升。为了寻求未来协同研发模式的转型，我们也对国外先进企业进行了分析：

DoD（美国国防部）：数字化工程生态构建

模型作为产品全生命周期过程的协同载体：模型作为产品全生命周期定义与协作的载体，实现设计模型、制造模型、审核与验证模型、系统模型、生产支撑模型、特种工程模型、管理模型之间标准化数据的无缝流通，服务于企业和项目决策 。

数字化工程生态构建：核心从5个维度进行生态构建（1、模型作为整个系统生命周期的内聚元素；2、权威性的数据来源；3、技术创新的引入；4、支撑的架构与环境；5、企业文化融入与人才培养）。

Lockheed Martin（洛马）：数字化织锦

洛马在型号研制过程中，大多数工程师在不同的学科领域中应用不同的建模活动；支持跨学科领域的集成的能力往往是有限的或缺失的；现有的集成方式更多的是“点对点”的模式。上述彼此隔离的单学科建模难以满足复杂装备系统的研发需要。因此其提出了“集成化数字样机”的构建，即通过数字化的手段，以系统架构模型为核心，将不同专业基于架构模型关联起来，构建业务依赖、学科交织、仿真协同的数字化织锦。

Boeing（波音）：集成产品开发框架构建

波音在推进全新研发模式转型时，通过构建IPA（集成开发框架）提供Boeing各专业工程师集成化的需求/架构/分析环境；可以基于集成化的数据环境，推进MBSE方法在各专业间的集成应用；通过集成化的环境架构实现一致、无缝的系统工程业务对象管理，确保更有效的系统折中权衡。

Thales（泰勒斯）：MBSE&数字样机建设

从2013年开始，推进MBSE工程化应用：在各个分支机构推行MBSE（基于模型的系统工程）在实际产品研发中的工程化应用，通过以模型为载体的研发模式变革，代替传统基于文件的研发模式。推进过程中分三个方面（ARCADIA方法论、Capella建模环境、DEVICE协同平台）齐头并进开展工作。

提升数字样机的应用深度与广度：在已经构建的结构数字样机基础上，面向产品，尤其是国防电子产品的功能和性能领域开始进行多层次、多维度的数字样机构建工作，大幅拓展了数字样机应用的深度和广度。

通过对国外企业的趋势的分析启示如下：

△ 载体显性-“模型”：模型作为协同的载体，一次建模随处可用；作为多专业、多学科间沟通的桥梁，通过统一的语言对系统进行定义描述，减少理解上的分歧；

△ 过程有序-“流程”：将全新的建模方法、手段、标准落入企业的研发流程中，通过流程牵引设计协作过程有序开展；

△ 快速迭代-“虚拟验证”：通过仿真分析手段分层级的引入，构建产品各阶段快速优化迭代模型，提升设计质量；

△ 连续传递-“模型集成”：整合企业现有研发能力建设成果，以业务串通为向导，构建基于模型信息网络，确保研发信息在完整研发体系中的无损、完整传递；

△ 体系构建：推动企业研发模式的数字化转型，并将对企业各方面（文化、人才、规范等）带来影响，因此需要多维度、体系化的进行构建。

二、模型协同能力解读与平台框架

2.1建设核心思路

因此国睿信维对于未来协同平台的构建的理解，将主要围绕如下“五位一体”的协同研发核心关注点进行构建。

模型：统一设计表达

以对象化、结构化的模型/数字机样作为跨专业协同的载体，推进基于模型的协同设计与仿真。通过描述模型以结构化建模的方式对整个系统的需求、行为、架构、性质以及相互关系进行统一描述；再通过分析模型针对描述模型所定义的架构、场景、功能性能参数等，以仿真的方式进行分析、验证；

流程：流程驱动设计

将企业研发流程与系统工程专业研发流程深度融合，驱动设计工作有序开展，通过对流程的分层分级定义，满足各层级协同工作开展的需要，因此对于流程也需要进行分层分级定义（从顶层的总体流程到底层专业设计活动）。将企业内已梳理的流程在协同研发平台中进行固化与管理，同时，对专业级的研发流程进行细化，用以指导设计活动开展。

知识：知识沉淀重用

基于全过程关联的结构化模型/方法/知识进行研发经验积累和快速重用，实现“模型知识化、知识模型化”。通过模型将过去文档中的设计要素显性化呈现，通过对模型知识的分类沉淀，构建基于模型要素的产品研发知识图谱，并基于重组后的知识相关性，通过重组建模，面向业务提供丰富的知识应用，应用产生的模型数据再沉淀转化为知识，形成循环应用的知识创新模式。

集成：数据信息集成框架

整合企业内部各研发要素（流程、设计/仿真工具、知识、平台、方法等），构建集成化研发环境，协同研发平台在整个协同研发体系中则核心承载着以下2项核心能力：1、通过统一的模型树的建立，管理面向一个型号研发过程中产生的各类模型；2、通过设计、仿真流程模型的构建，建立业务活动间的数据流转关系，并通过与工具的打通，实现模型数据在各专业建模工具间的流转。

方法：创新方法体系构建

基于模型的协同研发模式的转型，对现有的研发体系将带来巨大的冲击，因此需要在平台构建过程中，同步梳理并打造符合企业创新研发模式的方法体系，需要从顶层的规范性文件，至底层作业级的标准指南进行全面的更新与创建，并在平台推广过程中，持续推动方法体系的应用与优化。

2.2平台应用框架

因此，我们认为需要通过创新研发环境的构建，以确保模型作为未来研发过程的交互、管理的核心载体，同时保障模型信息无损、准确的逐层传播。初步的创新研发环境框架如上图所示，主要由如下4部分组成：

a. 流程驱动的协同研发

以业务流程作为基础支撑能力，同时引入综合项目管理要素，通过流程将产品研发与项目执行紧密关联，将产品结构分解与任务分解、目标成本分解紧密结合，实现计划任务流程一体化管理、研发流程管理、风险、质量、人力资源、目标成本等。

b.基于模型的多专业协同设计仿真

△ 需求管理系统：主要用以接收外部需求的输入，包含军方、用户、市场等，对此类需求进行结构化管理，并作为系统分析建模的输入。研发过程中的需求，将结合建模过程一同管理。

△ 体系级分析工具集：引入DoDAF框架，提供大系统级别的建模与分析能力，对产品顶层能力的形成进行作战场景、应用场景建模分析，明确产品能力要求。

△ 产品线/谱系管理系统：主要面向研发的不同产品线，通过市场分析、军队发展分析，规划不同产品线的谱系发展，以基础平台的开发+不同配置要求的开发，最终满足改型、变种的要求。通过产品线/谱系，对产品的架构、技术、物理产品进行集中管理，实现新变种的快速孵化和产品质量的有效保障。

△ 系统架构设计系统：支撑系统设计过程的架构建模、工作组级的在线协同与审阅、接口信息的统一管理、模型数据的输出模型数据的关联与技术状态控制，以及构建产品的指标体系，实现总体设计的快速优化与迭代。

△ 协同仿真系统：通过流程的封装，构建不同层级的协同设计仿真流程，通过流程实现工具的调用、参数的传递，并最终对仿真数据进行管理与分析。

△ 设计仿真工具集：构建设计师统一的工作入口，实现各企业现有的工具资源的集成整合。促进企业专业工具的统型，有利于模型上下游接口的打通。

c. 集成化测试验证

以测试任务流程为主线，覆盖测试业务全过程的规范化、信息化管理；以需求指标为牵引，指导测试活动的开展，形成需求→设计→虚拟验证→实物测试的有效闭环优化；构建统一的测试资源池，实现测试资源全过程高效运营管控；建立统一的测试数据存储中心，支撑测试数据采集、存储、管理、分析、知识转换的全过程。

d. 一体化模型协同与管控

有别于传统基于文档的数据管理模式，通过模型树的构建将需求、功能、逻辑、物理、仿真等模型进行集中关联组织。同时考虑长周期模型的存储归档，保障模型与文档信息的技术状态关联控制。

三、典型应用场景剖析

基于模型的协同设计模式将以模型为载体，通过各专业模型间数据链的打通，实现专业间业务协同，其主要体现在：

1）各层级需求指标关联约束：除了定义需求间的实现关系外，还需要考虑各层级产品指标间的复杂约束的定义与管理，例如指标间运算约束的定义与演算。

2）需求与架构建模的衔接：目前很多需求建模与架构建模两拨人独立进行，缺乏关联性，需求定义与架构建模两层皮，因此需要实现需求与建模过程的关联迭代。

3）体系建模与系统建模衔接：体系建模（系统黑盒分析）与系统建模（系统白盒分析）存在紧密的设计约束，两者间存在递进关系，因此需要从体系模型中获取系统基础的作战场景、作战能力等模型进行进一步分解。

4）系统/分系统协同建模：基于统一语言进行建模的同时，需要提供统一建模的环境，系统与专业人员可基于建模环境进行模型任务的分配、建模结果的合并等操作。

5）系统建模与仿真打通：“建而不仿”则无法对建模的准确性进行评估，目前建模与仿真的工作开展相对独立，需要打通设计模型向仿真模型的转换过程，实现“设计驱动仿真、仿真迭代设计”。

6）系统建模与专业详细设计打通：系统建模后，需要将相关信息向专业传递，以代替现有的基于任务书的需求下发模式，则需要打通系统模型与专业模型的信息交换。

7）专业设计仿真工具间的打通：例如MCAD进行三维建模后，模型如何可以快速的转换给热力学仿真使用，模型更改后，如何快速的在仿真模型上落实。

8）专业仿真与系统仿真间的闭环：系统仿真的精度相对较低，当专业仿真模型形成并验证后，通过对专业模型的抽象，将专业模型回归到系统模型中进行联合仿真。

9）设计与验证间打通：每一条需求最终是否验证，需要通过建立需求与测试用例间的满足度关联进行评估。

10）模型与文档技术状态关联控制：在短期内无法进行模型归档的情下，依然需要产生文档，如何保障文档中信息与模型信息的一致性，则需要建立一套完备的机制进行保障。

接下来将针对核心场景进行剖析，主要包含：

3.1方案设计协同

在产品进行概念、方案设计阶段，需要正向设计与知识驱动相结合，根据上图流程不难看出用户需求获取后，结合企业内历史经验进行对标，以确定为“改型设计需求”或“创新设计需求”。改型设计需求则快速获取历史经验进行对标，并针对差异化部分进行改型设计；创新设计需求则通过平台提供的统一架构建模方法进行多人协同设计，并确保数据向下游分系统或分包单位的传播。核心能力如下：

a. 基于需求指标体系的快速论证评估：

获取用户需求后，系统工程师针对上级单位所提出的需求，进行基于参数的快速论证。利用所内长期积累的知识经验，基于指标体系进行快速能力评估，通过功能需求获取相似需求的指标体系，通过用户性能指标与指标体系进行对标，再利用指标间约束关系进行差异部分的快速评估计算，通过各层级指标体系间的关联，实现各层级指标的逐层分析确认。

b. 统一的系统架构建模语言：

当未发现较合适可复用气象雷达，则根据需求进行正向设计分析，系统提供导航式的建模过程引导，通过5层的系统架构建模框架，对产品的需求进行分解分配。系统同时提供了需求分解与架构建模统一的环境，实现需求分解与架构建模间的紧密协同，避免两层皮的现象。在建模过程中，根据建模分解分析过程，形成需求、功能、逻辑、物理各模型间的关联约束，用户可基于关联关系评估市场需求变化对系统架构的影响。

c. 跨专业统一建模环境

在方案协同设计过程中，涉及到系统-分系统-模块间的在线协同建模。专业工程师获取系统工程师分发的功能性能分解分析任务，进行设计细化。在该过程中，基于统一视图以及统一数据源，各工程师存入各自设计数据后，系统工程师可即时查看到最新的功能性能分解分析的数据，各专业工程师可基于在线沟通方式，向系统工程师反馈设计结果，讨论系统指标分解是否合理，并基于模型进行审查协调。

d. 与下游单位数据交换模式

模式一：构建与下游单位间统一标准的数据交换协议，基于国际通用标准进行模型数据交换输出，包含FMI、XMI、AP233、AP239等。

模式二：基于模型输出的文档，完成与下游供应商间的数据交换。

3.2总体与专业协同

系统/分系统架构设计完成后，系统被逐层拆解，在分解的过程中，根据不同底层专业的关注度，需要构建总体与专业间的协同链条，以保障系统的设计意图最终通过底层专业设计进行实现，因此在总体与专业协同层面核心关注：

a. 与六性专业协同

系统工程师基于架构建模工具定义系统功能、逻辑、指标、接口关系等，通过与六性建模工具间的数据交换接口，实现架构、功能、接口信息的传递。六性建模工具基于架构层次构建FTA层级，同时基于功能定义失效规则等六性数据；最终反馈对现有功能的修改意见、故障控制需求、可靠性细分需求等信息，系统工程师根据反馈修订现有模型架构，新增故障监控模组等六性监控模块。基于上述模型协同过程，实现功能性设计与非功能性设计的协同。

b. 与结构专业协同

系统物理架构模型、PBS作为骨架模型构建的输入，通过建立系统架构建模工具与MCAD工具间的集成接口，将分解的物理组成与各组成相关的结构设计约束传递给MCAD工具，在MCAD工具中基于约束进行详细的模型骨架设计以及后续的模型详细设计。通过平台建立架构模型与物理安装模型间的关联，便于未来更改影响分析。

c. 与软件专业协同

总体在进行各层级产品架构模型分析建模过程中，软件总师介入在系统架构建模时，明确软件相关的功能及模块，并明确与硬件模块间的接口数据/控制关系。系统建模模型参数化传递给软件建模环境，将该纯软模块对应的需求、功能、逻辑信息通过集成接口传递到软件专业建模分析环境进行细化与代码实现。最终在模型树上建立系统架构模型与软件模型间的关联关系，以满足未来更改的全面影响评估。

d. 与电气专业协同

在系统-分系统-模块方案设计过程中完成了对各层级产品物理架构的建模，定义了初步的方案组成及各组成间的接口关系。在各层级产品详细设计阶段基于方案设计的组成接口进行电气详细设计，明确接口的类型、走线的形式和电缆类型。总体设计与电气设计衔接方式如下：在方案设计中，系统工程师对数据流、控制流、及能量流(虚线)进行定义，并对相关接口类型进行标示，但并不区分一路/多路信号；在模型结构树中建立电气设计节点，建立电气原理设计模型，将之前已完成接口定义的各模块及组件添加在电气设计节点下；基于各模块级组件的相关符号，完成电气原理图设计，并驱动完成最终的物理接线。实现对方案阶段接口定义的实现。

3.3多专业详细设计协同

专业间基于模型的协同模式随着多年专业工具的导入，已初步形成了协同能力，在数据交互层面已经形成了数据交换的统一模型或中间模型，以保障专业间数据交换的业务完整性。未来通过平台将确保模型数据的实效性、权威性，以更好的支撑专业间的协作过程。

3.4设计与仿真协同

设计与仿真间的协同涉及产品的不同层级，在各层级间需要基于典型的业务需求进行设计仿真协同模式的构建。通过国睿信维多年的协同设计仿真领域的实施与时间，我们总结出三类典型的设计仿真系统模式：

基于标准模型接口协同：目前业界有多种模型标准交换接口协同模式，主流的模式为：“基于FMI标准功能模型交换接口的联合仿真”与“基于STEP中间模型设计仿真模型交换”。

设计仿真过程实时信息交互：此种模式主要用于涉及仿真过程信息并发交互，例如雷达信号链路的仿真，需要对雷达信号的发射、接收过程进行实时状态监控，接收到信号后会出发对信号进行实时处理，整个信号链路分析过程都涉及仿真工具间的并行协同，需要通过Socket打通的方式，保障工具间的即时通讯。

基于业务需求进行中间模型的数据交换：此种模式主要结合产品研发的业务，分析专业间的业务协同点，通过促进软件原厂商间的合作，基于用户的业务进行中间模型的定义。

3.5设计与验证协同

设计与验证间的协同核心体现实物验证对需求的闭环满足过程，通过建立需求与测试用例间的关联，建立对产品需求的逐条追踪，最终通过试验结果对需求的满足进行评估；同时试验的数据可以作为仿真模型优化的数据源，通过仿真数据可以提升仿真模型的置信度，为实现数字孪生提供数据支撑。

3.6管理与技术协同

以流程管理工作包为任务节点，与专业研制活动系统、流程集成，牵引专业研制活动的开展，打通流程节点与专业研制活动的输入/输出、数据传递、交换过程，实现管理与专业的贯通融合。同时将管控相关的要素（包含：工作目标、周期、资源、成本等）融入模型分解过程中，作为模型设计的依据，例如基于系统架构模型对产品的目标成本进行分解，将产品预算成本逐层分配到各系统组成，作为各组成单元的设计约束。

3.7异构模型集成管控协同

从业务视角进行模型树结构的定义，以模型树的方式全面管理型号产品研发过程中的各类协同数据（包括需求数据、设计模型数据、仿真模型数据等），并建立模型数据之间的关联关系。便于型号研制过程中的技术状态管控、追踪追溯以及影响分析。

四、总结

通过对于基于模型协同设计模式的剖析，我们认为其能力的构建是一种全面的转型变革过程。对于组织、个人都提出了更高的要求，需要有效的组织、策划以度过转型的阵痛期，具体的转型之痛包含：

△ 思维方式转变：专业思维→系统思维

△ 工作模式转变：事件驱动→流程驱动

△ 沟通模式转变：文档→模型

△ 数据形态转变：非结构化、离散→结构化、关联

△ 标准体系重构

△ 基础数据梳理

   ……

因此面对上述挑战，企业需要借鉴国外业务变革的思路，构建完备的基于模型的数字化研发体系。以研发流程及活动的梳理再造为核心，将基于模型的方法体系、工具体系、人才体系、规范体系与技术体系融入在流程中进行清晰的规划与定义；并通过数字转型组织的构建，结合企业内部文化的培养，并通过全面的培训体系构建以及已有经验的积累重用机制构建，减少转型推进过程的阻力，推进企业向“数字化企业”构建的转型。