传统机械领域复杂系统产品研发技术软件工具前景简析

传统机械领域复杂系统产品研发技术软件工具前景简析

宋世轩

中国航发哈尔滨东安发动机有限公司  黑龙江省哈尔滨市 150066

摘要：传统机械领域企业面临数字化转型，其复杂系统产品研发技术软件工具（后简称软件工具）汇集了产品生命周期的优秀实践，体现了特有的核心研发能力。建设基于模型的软件工具，有助于实现协同团队的系统工作与流程、组织间的业务集成与信息集成，是当前一种较为理想的解决方案。

关键词：协同；软件工具；基于模型的软件工具

引言：

广义的软件工具指研发人员在流程中应用的技术软件；狭义的软件工具指基于模型、数据交换等技术开发，封装到集成研发平台组件中的计算机辅助业务模块，执行计算、分析等任务。软件工具之于研发能力，恰如生产工具之于生产力，软件工具的水平很大程度上代表了研发能力的水平，高水平的软件工具会促进研发能力与生产关系形成良性作用关系。现阶段建立软件工具管理业务，开发基于模型的软件工具，有助于提高业务水平，促进数字化转型。

一、架构

（一）需求

传统研发业务的优势在于，依据产品研制分工形成的领域、组织内部专业化程度高、业务效率高、人才培养快，技术团队对本专业工作内容“精雕细琢”；与之相对，“舒适圈”外的其他领域、基础学科、通用技术等受重视程度自然会下降，造成研发流程上下游信息不对称。在此基础上运行研发流程时，下游活动必然会与上游产生“冲突”，占用研发时间，降低研发效率。为了在不改变整体架构的基础上降低冲突影响，会在上游活动组织跨部门、跨学科团队平衡下游需求，但由于滑坡谬误的存在，每个下游活动都回本能地组织对上游活动的审查，并要求上游更改，生命周期内活动越多、上下游往复沟通越多，并不能直观提升效率。

针对平衡上下游活动间冲突这一典型需求，较为直观的解决方式有压缩单个活动周期、提高活动间信息交换速度等，而较为复杂的解决方式可以重塑业务流程，进而缩短往复路径。使用“业务-应用-数据”分层架构进行分析，应用能够大幅度提高活动效率，具有一定程度的专业通用性，还能兼顾数据流动，是解决上述问题的优良载体。

传统模式下，应用按业务需求开发，数据在应用中运行，应用之间需要将数据“摆渡”给下一个应用。新的研发业务要实现应用之间彼此连通，或者说“业务与数据孪生”，就需要统一数据模型。当数据模型统一、应用连通后，那么活动的边界也会模糊，业务也因此重塑。因此在传统产品建模、业务建模的基础上，融合数据治理理念，丰富数字化产品模型定义，建设基于模型的软件工具，有助于实现协同团队的系统工作与流程、组织间的业务集成与信息集成，是当前一种较为理想的解决方案。

（二）模型

为了能够顺利的实现产品研发，满足流程中频繁的数据交换与活动调用，支撑研发人员决策，需要统一的产品模型作为基础。产品研发所需求共享的、统一的、集成的产品模型应该覆盖产品生命周期的各阶段、活动，每个活动都有相应的应用。对于复杂非数字化产品，模型应当包括产品在设计、制造、试验等各个领域里的产品信息、业务信息以及在此基础上的数据分析，诸如产品的几何拓扑结构、材料、表面条件、尺寸公差、形状特征、版本、工艺规划、加工质量、动态仿真等等。

集成产品模型指产品全生命周期里状态、信息、数据的集合，是应用生成、处理和管理的对象和实现的基础。产品的需求、设计、工艺设计、制造等阶段所涉及的信息不是按照传统的方法顺序传递，而是在计算机网络通信技术的支持下，通过共享统一的产品模型，协同进行决策、执行活动。其实质就是在产品研发流程中的各阶段、活动，实施协同工作，以便能够在产品设计的早期就考虑全生命周期中诸多因素的影响，达到提高质量、降低成本、缩短周期的目的。

（三）理想场景

广义的CAX/DFX数字化工具集中的X可以代表生命周期中各种因素，如设计、分析、制造、装配等，典型的CAX有辅助设计CAD、辅助工程分析CAE、辅助工艺规划CAPP，典型的DFX有面向装配DFA、面向制造DFM、面向成本DFC等，使设计人员在早期就考虑设计决策对后续的影响。

以CAPP/DFM为例，它是把产品设计信息转换为制造信息的重要工具，它不仅需要从CAD设计部门获取成品涉及信息，而且还向后续过程提供加工、管理、检测、调度等信息，是制造信息的源头。集成研发平台/协同研发平台中建立了支持CAPP/DFM所需的制造资源模型，为CAPP/DFM提供资源信息支持。还建立了工艺信息管理模型，把工艺设计产生的结果进行重新处理，构成后续管理系统所需信息源，为MRP和制造部门管理提供信息支持。

如CAX/DFX工具实现了模型数据互通，那么凭借高效的计算机应用，设计人员可以直接将产品中的部分工艺设计活动结果计算出来，则工艺设计人员便可以进行校验，减少了模型转换、初步设计的过程。

二、约束

要实现满足协同以及产品生命周期中上下游活动信息交流的基于模型软件工具开发，首先需要满足各类基础学科技术、软件、硬件需求，这里初步划分为四个类别：A类技术定义能够做什么，如虚拟制造方法学、装配仿真技术、元模型的中性化语言、过程模型与仿真致效、设计抽象的方法学、制造工程自动化、仿真体系结构等；B类技术提供支撑，如创成式工艺规划、基于机理的过程建模、模型组件交互、元模型、模型致效工具、视觉信息处理技术、冲突求解获得最佳设计、STEP技术、工作流工具等；C类技术是前提，如过程计算机特征化、数据交换标准、视觉信息处理技术、安全技术/加密技术、高性能计算机等；D类技术则是广泛使用的技术，如基于事件的建模、大型集成数据库结构、面向对象的数据库、基于知识与规则的系统、人工智能神经网络等、可重构模块化的软件、自治代理等。传统机械领域技术树、技术地图，大多基于产品、专业等，与通用技术交叉较少，能够开发自己业务内的软件工具，对于跨领域、学科的软件工具则持保守态度，资源有限制约四类技术与产品技术的综合发展，需要专业信息化开发团队支持。

运用GPMM模型，以软件工具对产品研发业务的支撑情况作为软件工具业务结果，以软件工具的管理业务作为软件工具的过程能力，以软件工具的组织、信息化等作为软件工具的体系支撑，初步建立评估模型（业务结果指标仅供参考）。经分析软件工具对产品研发流程支撑不明显，产品与软件工具之间没有形成互锁，在实际产品研发过程中，不能直观了解各流程、活动关联的软件工具，支撑量化指标不清晰，因此无法满足“高效”、“协同”的相关需求；软件工具没有完整的全生命周期业务，软件工具的管理部门往往在业务部门与信息化之间部门摇摆不定；存量软件工具没有按照集成研发场景与数据治理需求开发，没有集成到集成研发平台或协同研发平台中，业务产生的数据离散地在各个软件中运行，模型统一程度差、没有与业务平行流动，靠人工“摆渡”、“翻译”反而降低了业务效率。因此软件工具业务成熟度相对较低。

三、展望

对于传统机械领域企业，软件工具开发、管理等业务，不是主要业务流程，因此在设计软件工具业务流程时，需与主要运营业务的各项活动中获得输出物，保证软件工具流程可运行。参照产品研发业务设计软件工具的管理业务，初步设计涵盖概念、计划、开发、验证、应用及生命周期管理等各个阶段的软件工具业务流程，能够导入技术开发成果，通过自研、协作、采购等形式，完成软件工具的载体及配套附件的开发，纳入软件工具数据库管理，供技术人员应用分析、优化迭代。

如果在某个活动应用的软件工具能够大幅度提高研发人员的研发效率，那么这一活动的组织有可能会发生变化；如果在某个跨领域集成研发项目应用的软件工具能够大幅度提高集成研发团队的研发效率，那么这一项目的流程有可能会发生变化。因此靠传统组织结构划分形成的部门难以从整理利益出发，实现上述效果，必须由企业顶层组织协同研发，在试点方向开发增量软件工具，形成特定产品专业跨领域的闭环工具，进一步促进业务重塑。基于管理流程和增量开发形成的相关经验，“完善”存量软件工具，“完善”的方式包括并不限于：合并、增加、简化等，最终形成面向IT落地、数据治理软件工具。

参考文献：

[1]熊光楞 《并行工程的理论与实践》 清华大学出版社，施普林格出版社，2000

[2]（美）约翰·M·博击等著，高星海译 《基于模型的系统工程有效方法》 北京航空航天大学出版社，2020年9月

[3]华为公司数据管理部 《华为数据之道》 机械工业出版社，2020年11月