1 维修性设计分析的信息需求

    在产品维修性设计分析的过程中，不同的产品层次、不同的研制阶段、不同的维修性工作项目所需要的维修性信息是不一样的。产品的层次通常可划分为产品层、部件层以及可更换单元层：装备研制阶段通常可以归纳为战术技术指标论证阶段、方案论证与确认阶段以及工程研制阶段；维修性设计与分析的工作项目主要有：维修性参数选择与指标确定、维修性定性要求的确定、维修性分配、维修性预计、FMEA一维修性信息分析、维修性设计准则的制定、维修性符合性检查以及维修性综合分析等。通过分析维修性信息与产品层次、研制阶段及维修性工作项目之间的三维结构关系，可以发现各种各样的信息实体。其包含的信息不是孤立的，而是反映在实体属性中，依靠实体间的关联来相互联系。通过对维修性信息进行实体抽象和封装，然后在分析各个实体间关联的基础上建立维修性设计与分析的ER(Entity Relationship)模型。如图1所示。

图1 维修性设计人析ER模型

2 基于PLM的产品维修性设计分析管理与控制解决方案

    在PLM平台下开展维修性设计分析工作，有效地控制维修性工作流程，实现对维修性信息及设计分析流程的管理，主要分以下四个环节实现：(1)在PLM平台下配置维修性设计分析环境；(2)建立基于产品结构树的维修性信息主模型；(3)维修性设计分析工具与PLM平台的集成；(4)基于PLM项目协同和工作流管理和控制维修性设计分析流程。

    2.1 PLM平台下维修性设计分析环境的配置

    在PLM平台下维修性设计与分析的任务主要是对维修性设计对象的设计与分析、设计与分析结果的校对与审核、审核通过后的发布共享，为了方便在PLM平台下开展维修性设计分析工作而又不与产品开发中的人员组织结构相冲突，需要在维修性设计与分析环境中定义设计组、审核组与发布组这样三个虚拟工作组。为了与型号研制中的三师系统组织结构相对应，应为组中的用户定义真实姓名、主要职务和兼任职务三个属性，这样就可以将虚拟组中的每一个用户和三师系统以及可靠性维修性专项组中的每一个用户和三师系统以及可靠性专项组中的人员相对应。此外，还需要为维修性设计与分析创建查看人员、设计人员、审核人员、批准人员及项目负责人等角色，并为每个角色分配了相应的操作权限。整个系统至少有一个系统管理员，系统的组织由多个组，而一个用户或组可以有多种角色，同样一个角色可以指派给多个用户或组；用户通过角色配置来对文档和数据对象进行访问。

    此外，PLM平台通常具有专门的客户化开发语言，可以定义新的抽象类、实体类和关系类及其属性，设计系统的菜单、选项、对话框等操作界面，也能够通过编写方法文件(*.Mth)实现类或对象的功能和操作效果。PLM平台已经定义了大量的支持产品研制开发的业务类，例如产品类(Part)、装配件类(Assembly)、构件类(Component)等，为了支持装备RMS设计分析活动，通常还需要定义RMS数据类、RMS数据类与Part类的关系类、RMS文档类、RMS文档与Part类之间的描述关系类等。

    2.2 基于产品结构树的维修性信息主模型

    产品的维修性信息主模型是指一个集成了产品生命周期内与维修性有关的所有信息的逻辑组织。它在结构上能清楚地表达这些信息的关联，所有授权用户均可以通过这个单一模型完成他们的技术任务。数据的生成和修改都基于这个模型，避免了数据的重复；各个设计过程在同一个设计主模型上操作，保证了模型数据的一致性和安全性：通过应用的封装，各种数据都放入其统一管理之下，用户对这些数据的存、取等操作，都必须通过该信息模型进行，而不能在操作系统下对这些数据直接操作，由此保证数据的一致性和完整性。

    总的来说，维修性相关信息主要有三类，一是包括大量不规则信息的描述性的大纲、报告、规定、报表等文件的文档类，我们可以用业务对象对其基本属性进行描述，然后将具体的数据文件与之相关联；二是用一组简单的属性即可将信息表达清楚的信息即属性类。主要有各种数据单元类如故障率、平均维修时间等：三是维修任务类，它用一个业务对象来定义和描述一个维修任务，然后有一组维修任务仿真相关的义件通过分层的文件夹与维修任务业务对象相关联，以支持维修仿真。所有的维修性相关信息在PLM平台下都是通过产品结构树来进行组织的，将相关的信息与产品结构树的零部件(业务对象)建立关联关系，使信息结构化、层次化，图2即为PLM下基于产品结构树的维修性信息主模型，该维修性信息主模型不仅可以集成产品生命周期各阶段相关的所有信息，而且在该模型下通过一系列规则设置，可以生成满足不同需要的维修性信息视图。

    在产品的维修性设计分析过程中，维修性设计分析人员往往需要借助一些先进的维修性设计分析工具进行精确的分析和计算，因此，将这些工具与PLM平台进行有效集成是在PLM平台下开展维修性设计分析工作的前提条件。针对不同类型和特点的维修性设计分析工具，通常有封装、接口和紧密集成三种不同的实现途径和集成方式，其中紧密集成是PLM平台与维修性设计分析工具最为理想的集成模式，它需要调用相应的API函数基于维修性设计工具的源程序作二次开发，通过建立互动的共享信息模型，以实现维修性设计工具与PLM平台之间数据交互的同步一致性。2.4 PLM平台下维修性信息与维修性设计分析流程的管理与控制

    PLM内涵就是集成并管理与产品相关的信息与过程。因此，PLM平台对维修性信息的管理可以分为两个方面：一是管理静态的产品维修性信息，二是对动态的维修性设计分析工作流程的控制。

   产品维修性信息的管理主要是通过PLM平台自身的管理模块对生命周期的维修性信息进行集成、管理和控制。在PLM平台中，文档管理模块可采用文件夹、目录的方式对维修性文档和文件进行管理，产品结构管理模块可对关联在产品结构树下的维修性数据单元进行管理，零部件管理模块可对装配件和零部件的基本信息进行管理，人员组织管理模块可有效组织和管理维修性设计分析人员的角色、权限等用户信息。

图3 基于PLM的产品维修性信息与维修性设计分析管理与控制模型

    维修性设计分析工作需要产品生命周期各阶段维修性信息的支持。因此，维修性设计分析流程的管理与控制是以维修性信息的集成和管理为基础的。在产品的研制阶段，维修性设计分析工作的实质就是对工作对象(产品、零部件、图纸、文档等)的操作和管理过程进行控制，包括维修性设计分析活动的开展，工作任务的推进，设计文档的形成、更改、审批和归档过程。其中工作的推进需要采用PLM项目协同建立整个产品研制阶段的里程碑和各个任务的前后继关系以及任务分解关系，并为每一个任务指定负责人；设计文档的形成、更改、审批和归档过程等由PLM的工作流来完成，工作流是从具体的工作步骤、步骤之间的顺序、步骤的参与人员、处理的数据对象和数据对象随流程不断变化的状态以及存储位置等几个方面来描述设计过程中支持业务流程所需的生命周期的相关方面。当将项目协同中的某一任务提交到PLM中时，会自动触发一个任务工作流，PLM中的对应人员会收到相应的任务，并按要求执行，任务的结果(如生成的一份报告)可能还要经过适当的工作流(如审批流程、更改流程等)来批准与发布，当任务在PLM中完成后会返回到项目协同中并自动触发其后继任务向PLM提交。图3建立了基于PLM的产品维修性信息与维修性设计分析管理与控制模型，描述了PLM平台下维修性信息及维修性设计分析流程的管理与控制原理，其中PLM项目协同和工作流模块是实现维修性设计分析流程管理与控制的关键。

3 实例应用

    Siemens PLM Software(原UGS PLM Solutions公司)开发的Teamcenter系统是目前制造企业中应用最为广泛的PLM平台之一。笔者通过对Teamcenter系统作二次开发，以某型舰炮研制阶段为例。实现了在Teamcenter平台下开展维修性设计分析活动，验证了PLM平台下产品维修性设计分析管理与控制解决方案的正确性和可行性，其实现过程如下：

    (1)在Teamcenter中配置了维修性设计分析环境，新建了“主任设计师”、“RMS设计师”、“标准化师”、“RMS总师”、“校核组”、“审核组”等用户、用户组和角色等。采用Teamcenter的客户化语言MODEL定义了RMS数据类、RMS数据类与Part类的关系类、RMS文档类、RMS文档与Part类之间的描述关系类等。以下是定义新类和属性的实例：

    //定义RMS数据类
    define persistent class RmsData with parent ProdBI；
    //定义RMS数据类的属性
    define attribute RmsDataName；
    //将属性和RMS数据类相关联
    attach attribute RmsDataName to RmsDam；

    (2)根据不同的维修性设计分析工具的特点。采用封装、接口和紧密集成三种不同的模式实现了维修性分配工具、维修性预计工具、维修性试验与评定工具、虚拟维修性仿真评估系统、FMECA工具等维修性工具与Teamcenter系统的集成。

    (3)在对某型舰炮研制阶段维修性设计分析活动进行详细分析的基础上，通过Teamcenter项目协同和Teamcenter 工作流实现了对维修性设计分析工作流程的有效控制。

图4 Teamcenter平台下的实例应用

    如图4所示，在项目协同层采用Teamcenter项目协同建立了产品研制阶段里程碑和维修性设计分析活动各个任务的前后继关系以及任务分解关系；在工作流层为项同协同中的每一个任务建立了相应的工作流。图4描述了维修性设计分析过程中RMS文档的处理流程，首先项目协同将RMS设计分析任务提交到Teamcenter，RMS设计师A接收到任务后就会调用维修性设计分析工具辅助其进行维修性设计分析，形在RMS文档并提交到审批流程，在审批流程中RMS文档自动转换为PDF格式并提交给RMS设计师B进行校核，校核之后通过自动处理任务提交给主任设计师C进行审查，审查无误后提交给标准化师D进行标准化审查，标准化审查结束后再提交给RMS总师E进行审定，审定通过后型号总师F提交到数据仓库进行归档并分发通知。在整个工作流程中，当某次审批没有通过时会返回直接提交者或初始提交者近按要求进行修改后(图中虚线所示)，重新提交。

4 结论

    本文主要通过在PLM平台下配置维修性设计分析环境，建立维修性信息主模型，实现了维修性设计分析工具与PLM平台的集成，为维修性设计分析工作的管理提供了一种确实可行的解决方案。本文的工作对在PLM平台下开展并行维修性设计和产品全系统全寿命管理研究具有非常重要的意义。

    本文作者创新点：建立了基于PLM的维修性设计分析管理与控制模型，为在PLM平台下开展并行维修性设计和产品全系统全寿命管理提供了解决方案。