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

1.1 复杂装备产品发展趋势

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

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

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

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

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

以航电系统为例：

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

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

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

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

复杂装备产品发展趋势 放大图片

图1 复杂装备产品发展趋势

1.2 协同设计现状分析

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

●沟通交流、一堵墙

沟通协调层层关卡，处处碰壁 放大图片

图2 沟通协调层层关卡，处处碰壁

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

●表意模糊、分歧多

文档协同瓶颈分析 放大图片

图3 文档协同瓶颈分析

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

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

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

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

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

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

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

异构模型难集成 放大图片

图4 异构模型难集成

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

●信息传递、断点多

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

信息断点多 放大图片

图5 信息断点多

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

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

国内协同平台建设模式 放大图片

图6 国内协同平台建设模式

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

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

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

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

1.4 国外趋势分析

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

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

DoD数字化工程生态构建 放大图片

图7 DoD数字化工程生态构建

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

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

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

洛马数字化织锦 放大图片

图8 洛马数字化织锦

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

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

波音集成产品开发框架构建 放大图片

图9 波音集成产品开发框架构建

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

●Thales（法国泰雷兹集团）：MBSE&数字样机建设

Thales MBSE&数字样机建设 放大图片

图10 Thales MBSE&数字样机建设

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

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

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

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

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

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

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

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

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

2.1 建设核心思路

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

“五位一体”的协同研发体系 放大图片

图11 “五位一体”的协同研发体系

◆模型：统一设计表达

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

模型定义 放大图片

图12 模型定义

◆流程：流程驱动设计

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

流程的分层定义 放大图片

图13 流程的分层定义

◆知识：知识沉淀重用

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

知识沉淀与重用 放大图片

图14 知识沉淀与重用

◆集成：数据信息集成框架

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

模型集成与数据流转 放大图片

图15 模型集成与数据流转

◆方法：创新方法体系构建

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

创新方法体系构建 放大图片

图16 创新方法体系构建

2.2 平台应用框架

平台应用框架 放大图片

图17 平台应用框架

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

●流程驱动的协同研发

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

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

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

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

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

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

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

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

●集成化测试验证

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

●一体化模型协同与管控

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

三、典型应用场景剖析

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

基于模型协同场景 放大图片

图18 基于模型协同场景

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

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

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

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

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

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

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

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

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

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

四、总结

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

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

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

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

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

◆标准体系重构

◆基础数据梳理

◆……

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