复杂产品维修构型变更管控方法

周春柳，刘晓冰，潘瑞林，王元云

(1.安徽工业大学 管理科学与工程学院，安徽 马鞍山 243032；2.安徽工业大学 复杂系统多学科管理与控制安徽普通高校重点实验室，安徽 马鞍山 243002；3.大连理工大学 经济管理学院，辽宁 大连 116023；4.安徽工业大学 化学与化工学院，安徽 马鞍山 243032)

0 引言

在产品全生命周期中，复杂产品运营阶段是最长的，大约20年～50年。维修活动作为产品安全可靠运行的基本保障，贯穿于产品运营过程中。相对于日常产品维护活动，不同维修活动间隔时间可能是半年、一年、两年或更长的周期。如果将产品运营时间描述为一条线，则多次维修活动类似于线上不同间距的散点，而且不同散点代表不同的维修级别。对每一次的维修活动来说，了解当前产品实际组成和零部件的维修历史是进行本次维修活动的基础。从维修角度来看，产品或零部件的变更是维修活动的天性，重要的是如何控制变更过程，准确记录产品的维修变更，从而避免错装和产品数据不一致的情况。

从新造产品出厂服役到产品报废的整个生命周期来看，维修活动会使产品组成和零部件状态不断发生变更[1]，尤其是大修活动，会根据产品实际状态更换绝大部分零部件。维修活动的这种特性使得产品组成和零部件状态随着维修活动的执行不断变化。同时，由于复杂产品，尤其是可移动的复杂产品，存在不同维修服务商，产品维修信息会分散在各个服务商处。针对多次维修活动，需要保证每次维修数据的准确性和连续两次维修数据变更的连续性，这种变更记录形成了产品和零部件的维修履历或维修历史记录。正常情况下，本次维修后的产品组成和状态与下次维修前的产品组成和状态需保持一致，但期间在日常维护或临时修理过程中也存在由于零部件临时故障引发的更换活动，使得产品组成或状态发生变更，因此需要对产品修前和修后数据进行记录和管控，避免产品数据不一致的情况发生。

目前的变更管理的研究主要集中在产品设计[2]和制造阶段[3]，在维修阶段产品数据变更管控研究较少。在数据模型方面，主要以BOM(bill of material)和构型管理为主，如飞机等复杂产品则以构型管理为主[1]。WHYTE等[4]通过对3个大型复杂项目产品交付过程或使用中的产品变更进行案例研究，说明了在大数据时代要依靠数字技术来管理大型数据集，提出通过基线管理和构型管理实现变更管控。胡浩等[5]以维修状态BOM为设备维修状态看板与管理工具，用维修状态演化表记录设备维修状态和管理维修历史。ZHOU等[6]根据产品设计、制造数据和维修需求建立了初始维修构型，由面向业务的通用维修构型和面向具体产品的实例维修构型组成。TEKIN[7]建立了As-built产品数据模型进行航空工业竣工产品的数据追溯，并将其分为需求管理和物料管理两个层面。徐建新等[8]提出服务BOM(Service BOM, SBOM)的概念，基于构型理论，将SBOM与构型管理结合，实现在役飞机维修过程中的产品结构变化管理。相对于BOM，构型管理更加适合复杂产品或装备的数据管理，并拥有一套成熟的理论体系来支撑构型的应用。产品构型数据指描述产品特征的所有数据，可以是和产品相关的全生命周期的数据，如需求数据、设计数据、工艺数据、生产数据、销售数据、维护数据和财务数据等。构型管理是一个过程，它致力于在产品全生命周期中，建立和维护产品需求与产品构型数据及产品属性之间的一致性[9]，可实现维修过程中产品数据的一致性维护。根据美国国防部制定的《构型管理手册》[10]可知，构型管理五大功能中的构型计划与管理、构型标识、构型更改管理、构型状态纪实和构型验证及审核等均可应用在维修管理中，用于解决维修数据变更管控的问题。因此，本文以构型管理理论为基础，研究单个装备在维修过程中的变更管控问题。

基线(baseline)可以用在建筑、管理、工程等领域，代表一个状态的起点，是进行对象衡量和比较的基础。在构型管理中，基线是描述产品在某个时间点的产品组成或产品特征属性，也可以是某个时间点产品的技术状态。基线管理是一种对照管理思想，通过对比之前的状态来了解变更后的产品状态。基线管理包含3个要素：①有固定的参考结构；②具有正式的审批环节；③具有里程碑式的事件发生或确定某一个具体的时间点。从产品全生命周期的角度来看，产品基线是按照客户需求确定(as-required)、产品设计(as-designed)、产品制造(as-manufactured/built)、产品运营检修(as-maintained)和产品报废处理及回收(as-disposal/recycled)这几个大阶段进行划分，下一个阶段的产品数据管理均会继承上一个阶段的数据和信息。而在每一个阶段内，根据过程复杂度和管理需求，又可设置若干个不同的基线，从而提高管理效率，保持整个过程的一致性。构型基线是进行构型变更管理的基础，在进行构型计划、批准或执行构型变更时，需要了解当前的构型状态及变更需求。构型基线应用于产品研发阶段，该阶段建立了功能基线、分配基线、开发基线和产品基线4种不同程度的基线，4种基线分别代表不同粒度或不同层级的构型项或零部件所关注的不同的功能，是实现产品一致性和变更连续性的重要技术。然而，基线管理在产品维修阶段却很少有学者提及或应用。面对复杂产品维修构型的变更管理，也可以定义不同的基线实现产品维修构型的一致性管理。

复杂产品维修变更管控从内容上来看，主要是在已有的构型模型基础上，对维修业务产生的构型变更进行管理和控制。现有研究多集中在维修数据的演化和追踪管理上，并偏重技术实现。程曜安等[11]针对动态实例BOM的需求，提出借鉴数据起源思想，在履历表中增加归属关系和维修操作描述，通过汇总履历信息、提取归属关系、增加零部件增减变更操作得到某个时间点的设备快照或关键件的归属。任艮全等[12]利用数据起源分析产品维修阶段的3种典型演化需求，实现任意时间段的产品BOM结构查询、BOM演化追溯和零部件隶属关系追踪，提出了产品和零部件在维修阶段的追踪技术。李青等[13]研究了单个飞机运营期间的构型管理和追溯，通过对每一个构型项建立产品有效期档案来管理产品数据和进行构型版本追溯。SUN等[14]提出了针对大修过程的识别、记录、审核、跟踪、追溯构型变化方法，将构型管理分为零件的状态变化(物料状态、技术状态和质量状态)和构型需求(识别和记录状态、控制和审核、追踪和追溯)。以上研究仅从变更结果上记录变更内容，没有从具体零部件类型或维修方式上分析作业层面的变更机制。

本文延续已有研究，将表达具体产品数据或信息的构型称为实例构型，维修阶段的实例构型称为实例维修构型，随着维修活动的开展而发生动态变化。现有研究中提出的维修变更管理多从数据管理角度，研究实例构型多次维修下的数据演化和追溯技术。针对某次维修业务过程中的数据变更原理和不同维修业务的变更机制的研究较少，缺少与不同维修策略、不同维修方式以及零部件类型等具体业务情况下的数据变更或演化研究。本文兼顾复杂产品维修变更管控的宏观视角和微观视角，从系统层面提出相应的变更管控方法。

1 维修构型变更管控需求分析

复杂产品维修活动反复出现在产品运营阶段不同时间点上，根据产品状态开展具有不同深度和范围的维修业务。从宏观角度来看，复杂产品在不同维修事件下(尤其是大修活动，构型会发生较大面积的零部件变更)会发生多次构型变更。为了保证产品安全运行并快速应对紧急故障，需要时刻掌握产品构型结构及状态并实时跟踪复杂产品构型。从维修企业角度，复杂产品返厂大修涉及上万个零部件的维保、更换、修理和升级等作业，同时也存在同一零部件在不同产品之间的周转使用(周转件)，企业在维修前需要确定产品的修前状态，从而明确本次维修范围和修后的效果，进行产品履历的登记，并根据修后情况进行维修成本核算。同时，本次维修的修后构型又可作为下次维修的修前构型，进而实现产品构型的变更。维修后的构型状态与维修前的构型状态所产生的差异是本次维修活动造成的，产品中多个零部件会根据自身状态经历不同的维修作业，由作业驱动零部件数据的变更，形成新的构型数据。产品零部件的不同维修策略、维修方式和零部件类型都是影响零部件数据变更的因素。长周期上的多次维修变更与单次维修活动之间的变更管控关系如图1所示。

根据所描述的维修阶段产品构型的变更业务以及产品实例维修构型变更的特点，可以总结出在维修阶段的产品构型变更管控需求：

(1)建立实例维修构型基线的需求

由于复杂产品在整个运营周期内会存在多次维修活动，每次维修活动之前，都需要明确产品目前的组成及状态，从而为本次维修确定维修需求和制定维修计划提供依据。在维修作业结束后，需要根据实际维修作业进行产品及零部件信息的更新，将更新后的产品组成和产品状态作为下次维修决策的依据，故维修前后都需要对产品实例维修构型建立基线，并将关键维修信息作为基线内容。

(2)维修前后实例维修构型基线自动化变更需求

在信息化时代，所有实体产品都可以用数字化产品形式来表示。复杂产品实例维修构型即为实际物理产品关键信息的数字化表示，而维修作业过程是触发实例维修构型变更的钥匙。需要通过对维修作业和构型变更的关联分析，总结维修构型变更的规则，实现维修构型的自动变更，进而提高产品数据变更的准确性和变更效率。

要实现实例维修构型的变更，需要对变更过程进行管控，才能实现整个变更流程的无差错，确保变更后信息的准确性。需要明确作业如何驱动变更、信息以哪种形式传递、如何将维修业务过程和结果以数字化的形式反映在实例维修构型上。该过程会贯穿整个维修过程，从维修需求确定到所有维修文档和产品相关信息更新完成，实现产品维修数据变更的无缝管理。

2 基于基线的多维修事件构型变更管理

2.1 维修构型基线的定义与实质

(1)复杂产品维修构型基线的概念

复杂产品运营阶段会发生多次维修(大修)活动，每次维修都伴随着产品构型的改变，这就需要不同的维修构型基线记录对应关键时间点的产品技术状态，为维修提供准确的数据。每次维修需要先确定维修前的产品组成和技术状态，然后根据维修需求制定维修计划。根据维修执行情况进行产品数据的变更，形成修后的产品组成及技术状态数据，作为下次维修的基础信息。本文将复杂产品每次维修活动前后的产品技术状态作为构型基线的设置点，建立维修前基线(Baseline before Maintenance, BBM)和维修后基线(Baseline after Maintenance, BAM)，控制产品实例维修构型的变更。维修构型基线是一种管理概念，指运用于产品维修阶段的，用来描述某时刻或某阶段的产品构型，即产品组成、零部件特征和相关技术状态。维修构型基线所包含的内容并不是产品的所有数据，而是维修所关心的数据。当发生的维修活动对产品产生影响时，产品的组成和零部件信息会发生改变。维修构型基线的确立主要根据管理需求确定，并不是每时每刻的产品状态都需要建立相应的维修构型基线。随着维修活动的开展，复杂产品实例维修构型不断变化，维修构型基线同样处于不断变化中。下文分别以“修前基线或BBM”和“修后基线或BAM”来代表不同的构型基线。

对于大修活动之间发生的临时维修，则不单独建立维修构型基线，本文将模仿飞机的“服务通告”概念，引入复杂产品“临修通告”的概念，将所有涉及到产品构型变更的信息以临时文件的形式存储起来，在复杂产品下次入厂维修时，将该类通告信息及时更新到产品构型中。由于产品运营数据的变化和临修活动的存在，使得复杂产品上次维修结束后的BAM与本次维修活动之前的BBM存在一些信息上的变化，故在本次维修活动开展之前，需要进行复杂产品的构型检查，依照BAM进行产品现有结构组成及相关信息的确认，信息无误后建立新的BBM，为本次维修活动提供数据基础。对于同一次维修而言，BBM是维修开始的初始构型，随着维修活动的进行，根据维修变更规则，实例维修构型发生变化，逐渐形成BAM，为下一次维修提供决策依据。与研发阶段的基线管理相同，所有构型基线都需要各方利益相关者(复杂产品的所有者或运营商及维修主体)进行审核和确认。

(2)复杂产品维修构型基线的实质

维修前基线或维修后基线是产品实例维修构型在整个产品运营周期内不同时刻的描述，相当于动态产品数据在不同时刻的快照。从数据存储角度来看，产品实例维修构型相当于动态变化的构型源数据(或实时数据)，而维修构型基线相当于根据某个时刻源数据建立的数据副本或快照，如图2所示。

当源数据发生变化时，已经建立的数据快照不会发生变化，故数据快照可以理解为对复杂产品关键时刻产品状态的历史记录。创建维修构型基线后，若实例维修构型发生变化，则快照系统会首先将原始数据拷贝到快照卷上对应的数据块中，然后再对源数据进行改写。在完成源数据和快照数据的改写后，会生成一张映射表，源卷上数据变化的逻辑地址和快照卷上的数据变化的逻辑地址会在该表的两列分别记录。在上层业务数据发生变化时，实际上会发生两次写操作，一次是将源数据写入快照卷，一次是上层业务数据写入源卷中。

2.2 维修构型基线的内容与更新

(1)维修构型基线的内容

由于维修构型基线是具体时刻下的产品实例维修构型，故维修构型基线相对于产品实例维修构型来说要多一个基线本身的信息管理。维修构型基线的内容，类似于实例维修构型的内容，可以从结构要素和属性要素两个角度进行考虑。从结构要素角度，维修构型基线的作用主要是记录需要进行全寿命周期管理的零部件(包括可维修件和周转件)状态(即构型项)，故对于维修构型中的必换件及不需要记录全寿命周期信息的偶换件，维修构型基线无需记录；从属性要素角度，维修构型基线管理的构型项特征类似于实例维修构型管理的属性特征，具体如表1所示。

表1 维修构型基线及构型项的管理内容

(2)维修构型基线的信息更新

通过对上次维修活动的修后基线与产品现有数据状态进行核对，将上次维修的修后基线更新为产品目前的状态，即形成了复杂产品的修前基线。需要更新的产品数据主要包括如下几个方面：①产品运营数据更新，包括运营里程或时间、积累运营里程或时间；②临修过程中的数据变更更新，如零部件更换等维修活动导致产品构型的变化、维修历史的变化等；③配属信息更新，如果运营过程中发生了配属变化，则需更新产品配属信息。如果没有上次维修活动的修后基线，也可根据产品状态临时建立本次活动的修前基线，作为维修需求、备件准备和维修计划等开展的基础。修前基线建立时，需要产品运营商和产品维修商同时审批和发布，确保维修工作顺利启动。

本次维修业务执行完成后，需要根据已完成的维修工作对本次维修修前基线进行信息更新，更新后的基线即可作为本次维修活动的修后基线。修后基线形成过程中需要更新的产品数据主要包括：①本次产品维修相关数据，如入厂日期、维修商、维修地点、修完日期；②周转件数据更新，如已安装周转件的信息更新和周转记录，已拆卸周转件的归属关系变更及其数据库记录；③产品实例构型零部件更新(等同于基线信息更新)，可根据通用构型确定的本次维修需求及执行结果进行总体信息更新；④构型项的维修历史更新，包括维修时间、维修地点、维修人员和维修内容等。修后基线形成后，也需要产品运营商和维修商双方共同审批、发布和存档，作为产品实例维修构型的一个节点状态快照，也作为下次维修活动之前的产品状态参考依据。

3 基于过程分析的单次维修构型变更控制

3.1 不同维度的维修变更内容分析

在维修过程中，可发生变更的数据往往是动态数据，产品层面数据包括产品结构(如零部件组成)、维修履历、运营数据、故障数据、归属数据等；零部件层面数据包括零部件技术数据、寿命数据、结构数据、维修事件记录、故障数据等。不同零部件在维修过程中的不同维修方式导致不同的变更内容，具体分析如下：

(1)不同的零部件类别和维修方式

根据可维修性[15]将零部件分为可维修件和不可维修件。可维修件是指维修后可靠性能恢复到可用水平的零部件，一般是价值较高、寿命较长的零部件。该类零部件根据维修和装配方式又可分为混装件、互换件和原位原装件。混装件是指同一产品中多个型号相同的零部件在维修过程中可以互换安装位置的零部件;互换件是指可以在不同产品之间进行互换安装的零部件;原位原装件是指由于不能确定混装件的影响或客户要求必须在维修后装配在原产品上的零部件。对混装件而言，原位原装件在维修拆卸管理和库存管理上更加严苛。互换件中比较特殊的一类零部件是高价周转件，由于零部件的价值较高，维修周期较长，维修商会设置少量的周转件库存来支持产品快速维修。不可维修件包括实际故障不可恢复件和维修成本过高或维修后效果难以维持正常运行的零部件。不可维修零部件又可以分为必换件和偶换件，可以根据零部件磨损状态及更换频率来确定其具体类别。若更换周期小于或等于维修周期，为了维修管理方便，会将这些零部件在每次维修时都更换掉，该种零部件称为维修必换件。若更换周期大于维修周期，称为维修偶换件，需要根据每次维修时的零部件状态来决定是否更换新件。

在产品研制阶段，会考虑产品维修需求，根据零部件特性和成本分析，制定不同零部件的维修方式。维修方式决定了维修过程中的管理决策，可以分为如下几种[16]：①免维修,适用于零部件在产品寿命周期内不会出现影响产品功能的严重缺陷的零部件，一般情况下不对该类零部件进行大修，仅在出现局部破损时，进行必要的修复性维修。②弃件修,适用于有明确寿命规定或无法有效维修或维修成本过高/维修不经济的零部件，该类零部件在受损或有缺陷或寿命不足以支持产品运行时，通过报废旧件更换新件的方式进行维修。③换件修,适用于临时修或维修时间较长的系统或部件，可以有效缩短维修时间。通过使用完好件或修复件替换故障部件的维修方式来快速恢复产品可靠性。④一般性维修(原件修理),适用于在一定时间范围内可快速修复的零部件，在维修过程中通过恢复零部件可用性，安装到原来的产品上，直到零部件寿命到达极限后更换可用零部件。

由以上分析可知，必换件和偶换件使用的是弃件修策略，可维修件可以使用免维修、换件修(互换件或周转件)和一般的修理方式(原位原装)。可维修件在不同维修方式和安装位置下产生的产品数据演化过程如图3所示，图中：a、b表示零部件，T表示产品。

(2)不同零部件类别和维修方式下的数据变更内容

在维修过程中，免维修零部件构型结构不会发生变化，零部件不会被替换，仅需要对局部损伤进行修复。零部件仅会出现维修记录和维修历史的更新，同时运营里程/时间及剩余寿命也需要与产品同步更新。从产品维修构型上看，变更范围包括维修记录、维修历史、运营数据及产品自身寿命数据等特征数据。对弃件修的必换件和偶换件，其在构型中的变更方式是由新的同类零部件进行替换。从维修构型变更角度来看，该类变更操作需要先将原有的零部件信息删除，再将新替换的零部件的所有信息更新到维修构型中。但需要注意的是，该类零部件如果对产品正常运营有影响，需要记录其供应商信息及零部件更换日期，当零部件更换供应商时，若出现严重问题，可根据更换信息进行质量追溯和责任追溯。对换件修的零部件，需要记录产品具体位置的维修更换信息、保存被替换的零部件信息、关联新装配零部件信息到产品、更新替换件的拆装履历、更新产品维修历史、更新周转件状态及配属记录等。图4描述了不同维修方式、零部件类别和变更维度之间的关联关系，表2描述了不同变更维度的具体内容。

表2 不同变更维度的具体内容

(3)构型变更内容分析

以上变更主要是根据零部件类别进行的变更内容的分析，同样地，可以从复杂产品构型角度出发，探讨复杂产品的变更方式。复杂产品构型相当于一种产品结构，可以从构型的结构和属性两种角度来分析维修构型的变更，主要包括如下4种情况：

1)零部件或部件结构不变，属性或文档变更。此类变更发生在零部件剩余寿命周期可满足下次检修时间的寿命需求，零部件无明显故障，仅进行维护、清洗和性能试验，更新试验数据即可。记录本次维修事件，如维修事件名称、维修时间、维修地点和维修商等。

2)零件或部件替换，物料编码或序列号变更。此类变更发生在换件修方式下或零部件已经到达或即将到达寿命期限，即将报废或回收利用的零部件。在换件修方式下，对产品来说，产品结构所安装的零部件实体发生变更，该位置所关联的所有零部件数据都会随着零部件的更换而改变。更换的零部件可以是满足可靠性和寿命要求的旧件，也可以是新件。

3)零部件序列号不变，结构变更或软件升级。该类变更往往是有构型项加装改造、零部件升级、零部件具体维修等需求时，对零部件结构进行调整。零部件结构发生变化，其技术数据(如装配图、维修说明等)、供应数据(如供应商等)、寿命数据(剩余可用寿命等)一系列构型文件都要跟着改变。对软件产品说来，软件升级管理也在变更管理范围内，需要在维修项目中说明软件升级版本号、功能描述等。

4)产品变更。以上所有变更都会引起产品的变更，当零部件与产品的结构关系不变时，仅需对零部件变更进行管理；当零部件与产品结构关系改变时，需要分别管理零部件和产品，记录归属关系的变更。例如周转件，当产品更换替代件后，产品履历中需要记录周转件的更换，并将更换件信息与产品关联。而被替换件则会入库、维修、恢复可用性，下次安装到待修产品中。

3.2 基于配置的产品维修构型变更方向控制

不同零部件维修变更内容仅表明了已确定的零部件类别和维修方式所决定的该零部件在维修业务中数据会如何发生变化以及哪些数据会发生变化，在替换件、多供应商可选件和复杂的安装约束情况下，维修配置管理决定着实例维修构型的变更方向。该配置功能可根据客户需求和维修规程，在产品位置约束、组装约束和有效性约束下，决定维修产品需要更换具体供应商零部件的最优选择。

之所以会存在复杂产品维修配置问题，是产品维修多样化的需求，这些维修需求是产品维修变更的驱动力，因此需要将这些维修需求与产品变更方式关联起来，具体如表3所示。

表3 维修配置对构型变更的影响

从表3可以看出，不同维修需求会对产品实例维修构型产生可预计的变更影响。在配置过程中，除了一般性的更换和维修作业，还需要一些优化技术的支持。优化技术体现在两方面：①在满足已有约束的情况下选择不同供应商零部件时，通过成本优化选择较为合适的供应商零部件;②换件修的周转件选择需要考虑零部件剩余寿命和产品本次维修到下次维修之间的运营时长或里程，选择合理的周转件匹配，从而在满足产品及零部件可靠性的前提下，降低维修成本，实现绿色维修。文献[17]中提到轴箱轴承剩余寿命充分利用的实例：A零部件的使用寿命是270万公里，在五级修时运营里程达到230万公里，剩余的40万公里无法满足下一个检修周期60万公里的使用要求，如果直接报废会造成零部件寿命浪费。在车辆运行过程中，当同类型部件B发生故障，如果距离下一次检修小于40万公里，可以更换上A部件，从而提高配件的利用率。同样地，在多供应商选件时，可考虑成本、质量、时间等多目标进行备件选择，实现产品备件配置的优化。

3.3 基于IDEF0的维修构型变更过程分析

维修配置确定了服务级别、维修项、维修备件和后续作业等，但实际产品维修构型变更发生在维修业务执行过程中，如零部件更换、可维修件的维修以及软件的升级等。为了明确维修业务过程中的实际产品或维修构型数据的变化，本节利用IDEF0方法对维修业务过程中的活动和不同活动之间的信息流进行分析，进而形象化描述维修构型变更的过程、活动及关联。

IDEF0是一种结构化的分析方法，通过一系列的图形、语言和描述文字将复杂系统逐层分解成各个部分，使复杂系统更加容易被理解。IDEF0能同时表达系统的活动(用盒子)和数据流(用数据流)以及它们之间的联系，同时考虑了活动、信息及接口条件。对新系统来说，IDEF0能描述新系统的功能和需求，进而表达一个能符合需求及能完成功能实现的系统。对已有系统来说，IDEF0能分析应用系统的工作目的，完成功能及记录实现的机制[18]。IDEF0模型从系统的角度出发，客观揭示了系统内部的活动、联系、对象和各活动之间的信息输入输出关系，便于理解和交互[19]。IDEF0主要包含以下信息：用盒子代表活动，围绕着每一个活动，都会有输入、输出、控制和机制。输入(inputs)和输出(outputs)表达的是“是什么(what)”，控制(controls)表明了“为什么(why)”，机制(mechanisms)表明了“如何做(how)”。这些数据元素可以用ICOM进行总体表示，ICOM与活动关联起来，共同描绘系统流程、功能和数据流。

基于IDEF0自上而下的系统分解功能，将IDEF0绘制分为3个层次，从顶端的总体业务流程开始，到维修过程详细业务及各业务之间的关联，再到最终的维修业务执行部分，对复杂产品实际维修变更作详细的说明，如表4和图5所示。根据维修流程，可将复杂产品维修业务分解为5个子活动，而产品或维修构型变更主要发生在维修执行部分，故单独对维修执行部分进行具体业务活动的分解。在维修过程中不同零部件的维修内容是不同的，变更结果也不同，存在业务活动并列的情况，具体如活动组A43。同时，由于维修过程中存在返工返修的情况，故最底层的模型中存在活动的循环。

表4 复杂产品维修业务分解表

维修活动的分解和确定限定了IDEF0的主要范围，由于本部分内容主要针对产品维修构型变更，故不对第二层模型中的其他活动进行深入分解。而第二层的IDEF0模型则体现了不同活动的关联，阐述了维修业务执行过程中的输入和输出。根据复杂产品维修业务流程的调研及相关知识的了解，本文从IDEF0的顶层到底层，进行活动分解和每个活动的ICOM要素分析。

复杂产品维修业务流程的输入是待修产品、本次维修级别和本次维修特殊需求，所有维修活动都需要遵循维修规程，符合政府和行业的法律法规，满足维修合同。维修部门根据通用维修构型和相关管理技术，执行维修业务活动，从而获得满足客户需求的可靠产品、产品及关键部件的维修履历和具体维修明细，如图6所示。

复杂产品维修过程类似于生产管理过程，都需要进行需求确定、计划制定、资源准备和生产执行等业务活动，各活动之间的关联是活动顺利进行的关键。所有活动都是为了使维修业务顺利执行，具体如图7所示。

在具体维修业务执行过程中，产品维修基本的活动为“拆卸—维修/更换—组装”，根据不同零部件的维修策略和维修方式会有不同的维修内容，如图8所示的A43系列活动组，共同构成了维修构型变更的基本活动，这些活动会记录在产品维修记录中，形成本次维修的产品和关键零部件履历。

3.4 作业驱动的构型变更模型

(1)维修作业分类及数据变更分析

由3.3节内容可知，产品零部件在维修过程中会经历拆卸、检测、维护、维修、入库、升级或技术加改、更换、报废和组装9类维修作业。其中：检测主要对复杂产品或零部件的关键技术指标或性能指标的测量，也包括探伤作业等质量检测，为维护、维修作业提供数据基础；入库是指旧件入库待修，主要针对换件修，提高产品整体维修效率。复杂产品零部件都会经历这些维修作业中的一个或几个，这些维修作业则是维修构型变更的源头，维修作业过程对维修数据的变更影响如表5和图9所示。

表5 维修作业对维修数据的影响分析

(2)维修变更数据模型

假设实例维修构型用I表示，I包含了零部件节点集合P，物料编码/序列号ID，位置描述O，零部件关系R和零部件属性C，则维修前的构型可以表示为：

I=〈P,ID,O,R,C〉。

(1)

维修后的实例维修构型为I′，零部件、编码、零部件位置、零部件结构和零部件属性等均有可能发生变化。

为记录维修变更过程，需要引入一些操作变量来表示维修过程中的作业，如表5所示，本文用双字母来表示维修作业变量。同时，为了区别修前和修后的产品组成及特征，本文用构型基线内容来表示维修过程的输入与输出，将重点集中在全生命周期管理零部件上。变更数据模型中的修前基线用BBM表示，修后基线用BAM表示，维修作业变更用Pr表示，维修作业集合用OP表示，针对单个零部件的维修作业或维修作业组合用Op表示，则有如下形式化表达：

Pr={Pr1,Pr2,Pr2,…,Pri}；

(2)

OP={Ds,Ms,Me,Re,Iv,Up,Ch,Sp,As}。

(3)

单个维修作业OP如表5中的“作业名称”栏所示，组合作业情况如图9的“作业组合”所示，这些作业共同组成了OP集合，作为维修作业的输入。不同的操作对维修构型的影响不同，数据变更也不同，定义Fp为维修作业下的零部件数据变更逻辑，Fp的变更逻辑来源于表5所示的单项作业变更逻辑和图9所示的组合作业变更逻辑，是连接输入、操作和输出的关键。数据变更主要体现在零部件或构型结构、编码、位置、零部件关系及属性等的变化上。针对每个操作，也需要对操作发生和终止的时间进行记录，代表着数据变更的开始时间和结束时间。对每种变更处理，都有相应的输入、操作和输出，输入和输出依靠变更逻辑Fp来进行数据的变更。

对于每种维修作业Op，都有相应的作业代码IDop、作业名称Naop、工艺Pro、所需设备Ma、人力La、作业开始时间Ts和作业结束时间Te等信息，表示如下：

Op=〈IDop,Naop,Pro,Ma,La,Ts,Te〉。

(4)

维修作业变更过程Pr的表示如式(5)，其中，In表示维修作业前的产品或零部件构型状态，Out表示维修作业后的产品或零部件构型状态，从In到Out需要有作业输入和变更逻辑的输入，从而控制产品维修构型的变更。

Pri=〈Ini,Opi,Fp,Outi〉；

(5)

Ini=〈pi,idi,oi,ri,ci〉；

(6)

(7)

综上可知，Pri最终作为零部件pi的履历记录。对于多个零部件变更的修前基线和修后基线，可以表示为：

BBM=〈{In1,In2,In3,…，Inm},Cb〉；

(8)

BAM=〈{Out1,Out2,Out3,…，Outm},Cb〉。

(9)

其中：m表示本次维修对象数量;Cb表示基线属性，包含基线名称、基线建立时间等属性。

当获得了修后基线BAM后，即可对比BAM中的零部件节点与实例维修构型I中的对应节点，进行信息的更新，获得最新的实例维修构型I′。

4 以转向架轮对组成为例的维修构型变更管控案例

动车组转向架是动车组八大关键部件之一，是动车组正常运行和安全保证的核心部件。动车组转向架维修是动车组每次高级修的必修内容，而且随着维修级别的增加，转向架的维修范围和维修深度也逐级增加。如CRH380AL型号列车的转向架三级修共有27项检修内容，四级修增加到了37项，在维修范围上更加广泛。由于转向架较为复杂，涉及的数据量较大，本文以动车车厢转向架的关键部件“轮对组成”(下文用“轮对组成(M)”表示)为例，研究动车组转向架维修过程中的产品构型变更管理与控制。

轮对组成(M)结构如图10所示，其实例维修构型信息如表6所示，选择动车车厢的“轮对组成(M)”作为研究对象的原因如下：①轮对组成(M)包含了提供动力的齿轮箱此类关键部件，是高级维修中的重点；②齿轮箱所属的供应商部件，可能存在委外维修的情况；③轮对中的各零部件会存在多种维

修方式(如换件修理、车轮可修后混装在不同位置)和多种维修作业类型(如拆卸、检测、维护、维修、更新、报废等作业)，子件均需进行全寿命周期管理和履历记录。该案例对象足以展示维修过程中动车组的构型变更和轮对中的关键件的全寿命周期履历记录的管控过程，具有典型性和代表性。

表6 轮对实例维修构型基本信息

在动车组高级修中，不同的维修级别(如三、四、五级修)代表维修范围和零部件的维修深度。但是对于关键零部件来说，维修级别仅代表不同的里程或者时间对应的维修点，仅需根据维修参数要求(如表7所示)，对比零部件状态，进行维修作业。

为了全面展示对装备维修变更信息的管控，以动车组从新车投入到经历完整的三、四、五级修为完整时间线，对动车组及轮对组成(M)在多次维修中的构型变更和单次维修作业中的关键零部件轮对履历变更进行描述，从而全面验证本文方法的可用性。

表7 轮对组成(M)各零部件维修要求

续表7

案例描述：动车组A从2012年9月16日新造出厂投入运营开始到2016年11月18日完成五级修，表8说明了每次维修前的累计行驶里程、修前修后时间、对应维修基线，以及修理完成后根据修后基线更改的产品实例维修构型。为了降低数据量，对轮对组成(M)的每次维修范围、修前状态和维修作业，本文仅选取部分具有代表性的维修事项，阐明本文方法的应用过程，具体描述如下。

表8 动车组多次维修事件及对应构型和基线信息

轮对组成(M)三级修修前基线BBM1是根据本次维修范围，从实例维修构型I0中抽取出来的零部件状态信息。由于三级修主要进行状态检修，针对车轴表面的划痕进行手工打磨，故BBM1的对象为车轴，修前状态In=车轴,0010+2234,无,父节点为轮对组成(M),轴径=D，维修作业Op=作业组合1+3,手工打磨,打磨工艺,无,工人甲,t1,t2，维修完的车轴状态Out=车轴,0010+2234,无,父节点为轮对组成(M),轴径=D′(注：下划线代表存在数据变动，下同)，此时的Fp主要为图9中的“1+3”作业组合变更，主要变更内容为轴径参数变更，增加维修记录。Pr展示车轴从修前状态经过打磨作业到修后状态变更的全过程。BAM1相对于BBM1增加了车轴的参数变更和维修记录，以及营运里程或运营时间等运营信息的更新，便于实时更新关键零部件的剩余寿命。维修基线变更记录在车轴的履历中，实例维修构型I1相对于实例维修构型I0仅存在车轴轴径的参数变化和运营数据的变化。对于关键零部件来说，都存在运营数据的变化，下文不再强调，主要突出维修作业带来的产品零部件数据的变更。

轮对组成(M)四级修维修任务包括：拆卸和组装轮对组成、齿轮箱加装温度传感器和轮对修形及报废，则本次的修前基线主要包括轮对组成、齿轮箱和车轮3类零部件的状态参数。用In1表示齿轮箱的修前状态，In21表示车轮[一位侧]的修前状态，In22表示车轮[二位侧]的修前状态，则有In1=齿轮箱,0030+4234,无,r,c，维修作业Op1=<作业组合0+1+5+8,加装改造,加装改造工艺,设备组1,工人组1,t1,t2>，Out1=齿轮箱,0030+4234,无,r′,c，r′相对于r增加了子节点温度传感器及其属性信息，Fp为图9中的“0+1+5+8”作业组合对应的拆装记录和改造记录。车轮修形主要涉及到轮径参数，修前状态In21=车轮,0020+3234,一位侧,r,轮径=D，维修作业Op21=<作业组合1+3,镟轮,镟轮工艺,设备组2,工人组2,t3,t4>，Out21=车轮,0020+3234,一位侧,r,轮径=D′，Fp涉及到轮径参数变更，增加维修记录。对于报废车轮，则需要记录报废原因(如轮径达不到要求)，并更换新的车轮。该变更主要发生在轮对组成上，并记录在轮对组成(M)履历中。In22=车轮,0020+3235,二位侧,r,轮径=D，维修作业Op22=作业1+7,报废,报废流程,测量设备,工人组1,t3,t4，Out22=车轮,0020+3236,二位侧,r,c，Fp涉及到报废记录的增加，车轮替换记录，将新车轮的属性增加到轮对组成(M)中。对于轮对组成(M)，经历了拆卸、轮轴超声波探伤、组装、检压测试、动平衡测试和标记刻打等作业，同时子部件结构的变更会影响到父件，故轮对组成(M)状态变化较多。用In0表示轮对组成的修前状态，In0=轮对组成,0000+1234,无,r,c，维修作业Op0=作业组合0+1+3+5+6+8,轮对组装维修,轮对组装维修工艺,设备组3,工人组3,t0,t5，Out0=轮对组成,0000+1234,无,r,c，Fp涉及了拆解、维修、加装改造、更换新件等作业，需要增加拆装记录、填写零部件替换记录、填写加改记录以及检测记录。每一个零部件的维修变更都存在一个对应的Pr记录，形成对应零部件的维修履历。本次四级修的修前基线BBM2={In1,In21,In22,In0},{2014-9-11,四级修前，维修厂A}，本次维修的修后基线为BAM2={Out1,Out21,Out22,Out0},{2014-10-18,四级修后，维修厂A}。实例维修构型I1对比BAM2中的零部件进行对应信息的更新，形成实例维修构型I2。

同样的，五级修中也会存在轮对组装的拆解、轮对修形、轮对更换、齿轮箱拆解等作业，这里假设更为复杂的情况，车轮修形后存在位置调整(混装情况)，将转向架车轮一位侧安装序列号为3236的车轮，二位侧安装序列号为3234的车轮。此时，相对于四级修案例，修前状态In和修后状态Out中的位置信息和轮径数据需要同时变动，在履历记录Pr中也会体现，这种位置变动也会体现在实例维修构型中。若存在不同列车之间共用的周转件(委外维修需求或维修时间较长，为了缩短总维修时长而设置的零部件)，存在产品和零部件的关系r变更，类似于四级修案例中换新件的流程。

以上案例足以代表不同零部件维修过程中的变更过程和方法，无论多么复杂的维修过程，根据以上变更管控过程，均可实现维修履历的记录和实例维修构型的更新，以及产品和零部件的全寿命周期管理。

5 结束语

本文利用修前基线和修后基线来控制多次维修事件之间的数据变更，确保了长周期离散时间点上维修构型变更的连续性，同时修前基线为单次维修业务变更提供了维修数据变更的起点。根据不同维度的维修变更内容分析和变更方向控制分析，利用IDEF0进行维修过程分解，将维修变更具体到每一个维修作业，实现作业驱动的维修构型变更管理。提出的复杂产品维修构型变更管控方法可支撑维修业务过程管理信息化，为产品履历管理、备件管理、维修计划管理等提供了准确的数据基础，可作为维修管理信息系统基础数据管理模块的基本技术。

本文虽然对维修数据变更做了细致的研究，但在维修构型审核等内容上只做了简单的说明，未来可进一步研究维修构型管理流程。同时，在数字化时代，区块链技术和数字孪生技术等新一代信息技术均可应用在复杂产品维修中，如HUANG等[20]将区块链技术应用在数字双生产品全生命周期管理中，从而实现了产品数据管理的高效性和安全性；张旭辉等[21]将数字孪生技术应用在设备维修指导中，提升了设备维修的效率。因此，复杂产品维修构型变更的未来研究也可结合区块链技术和数字孪生技术，实现更大范围和更加高效的产品数据管控。