1 Introduction

With the development of computer and information technology, consumers have put forward higher requirements for product quality and delivery time. At the same time, manufacturing products usually contain multi-level assembly structures and complex process routes, and the production process requires the collaboration of multiple enterprises. However, there are great differences in data definitions and semantic syntax between various corporations, which lead to low efficiency of production collaboration and inconsistent data among enterprises. Facing the challenges of rapid production response and efficient resource utilization, manufacturers have to spend much time on organizing and coordinating production resources distributed in different places. To perform large scale collaborative manufacturing, cloud manufacturing is proposed based on internet and aims to build a new networked production organization mode, which can provide users with flexible and on-demand shared manufacturing resources [1]. Driven by the virtualization and servitization of manufacturing resources, the speed of digital transformation of manufacturing enterprise has been significantly accelerated [2].

Product lifecycle refers to the whole process of production from demand analysis, design process, manufacturing, operation to maintenance and scrap [3]. The purpose of PLM (product lifecycle management) is not only to realize efficient management of the information and knowledge but also to achieve data integration from all involved stages of product lifecycle, which helps to improve the profitability and competitiveness of enterprises [4]. Due to the large temporal and spatial distance in various stages of the whole life cycle, production data of services are usually stored in heterogeneous information systems, resulting in model non-interoperability and data inconsistency among stages [5]. In order to fully manage model data of whole life cycle, the closed-loop PLM, which regards the product lifecycle stages as an end-to-end whole, has been proposed and developed to maintain data integrity and traceability throughout the whole life cycle stages [6]. However, the main limitations of these approaches are that they interpenetrate data among different lifecycle stages mainly based on integration and lack of specific transformation methods. As the service data in different lifecycle stages has characteristics of modularization and componentization [7], this would lead to inaccurate and time-consuming interpenetration results.

In this paper, we focus on the analysis of data characteristics in different lifecycle stages. The proposed approach explored and extracted the general and individual data to establish a generic model and transformation method, so as to realize the interpenetration at model level. Furthermore, to effectively cope with model transformation at different lifecycle stages, we summarized and defined eight operators, based on which the model transformation can be executed more instructively. In addition, we also studied the model propagation mechanism when data changes.

In summary, the major contributions of this paper are threefold:

  1. 1.

    A generic service model and transformation method is established to realize data interpenetration at model level.

  2. 2.

    Eight transformation operators are summarized and mathematically defined, based on which the model transformation can be carried out more instructively.

  3. 3.

    The model propagation mechanism is proposed when data changes to solve the synchronization problem of life cycle model.

The remainder of this paper is organized as follows. Section 2 gives a brief review of the related research. In Sect. 3, the business model of life cycle manufacturing services in cloud manufacturing is analyzed, and the novel service model transformation method based on general and view service is elaborated. Section 4 presents the definition of the life cycle service model, studies the eight transformation operators, and summarizes the logic process and change propagation which the model transformation follows. Section 5 shows a case study and prototype system applied in an instrument enterprise, which illustrates the feasibility and effectiveness of the proposed methodology. Section 5.2 concludes the whole paper.

2 Related work

In the industrial field, the product lifecycle refers to all life cycle stages of the whole production and application process. In order to ensure the accuracy and consistency of data in the whole life cycle, manufacturing data in different life cycle stages or various enterprises need to be modeled and searched uniformly [8]. At the beginning of research, the attributes and relationships of manufacturing resources, including basic attributes, usage attributes, and state attributes, are main the consideration components for modelling, but these are mostly static attributes [9]. Subsequently, multi-granularity resources (including workflow, activity and resource) are gradually taken into account to model services over different granularities [10]. With the deepening of research, dynamic attributes of resources are gradually considered, and the real-time operation data are also fed back to the service model [11]. To consider the diversity and heterogeneity of resource data, several novel spectral clustering methods are proposed for data partitioning [12, 13], which reduces the complexity of resource modelling. To ensure data consistency, the ontology semantic method is introduced into modelling and matching [14], and some ontology languages, such as OWL, OWL-S, are also applied to describe the model [15, 16]. Moreover, in order to meet the requirements of personalized customization, service modelling by means of considering the relevant relationship between demands and services has emerged as one of the most primary research directions [17, 18]. In addition, some researchers present new modelling method of data and information expansion based on the source model, such as extending [19] or enhancing [20] 3D model data to expand information of other life cycle stages, thereby improving the universality of the source service model. However, these methods mainly modelling based on the data of a certain stage, and then expand or enhance data to other stages, which cannot achieve global interpenetration at model level.

On the basis of manufacturing service modelling, research on data integration of manufacturing service model is also developed simultaneously. To achieve the traceability of service data, the block chain technology [21], a product configuration knowledge sharing mechanism [22] and a customized sales strategy [23] are introduced and applied into modelling in different lifecycle stages. In order to accomplish the information feedback function of closed-loop PLM, an ontology-based reasoning platform is put forward to connect the after-sales stage and the design stage [24]. Furthermore, a centrally driven system workflow is established to achieve knowledge sharing among design, manufacturing and supplier departments [25]. In addition, some emerging technical methods and intelligent algorithms are constantly applied to data integration of models. The machine learning methods is adopted to realize the sharing of quality data among the manufacturing, inspection and after-sales stage [26]. Li et al. [27] propose a novel event-adaptive concept integration algorithm which learns the sematic correlation from the concept vocabulary and emphasizes on the most related concepts for the zero-shot event detection. In addition, the categorical theory [28] and DTM (dynamic time warping) method [29] is adopted to connect the product data between design and manufacturing stage, so that designers can obtain the manufacturing data to make the optimal product design decisions. Moreover, the rapid development of the Internet of Things can promote the interconnection of physical information with the support of embedded technology, which raises the concern over application to data integration [30]. The research of these integration methods has greatly promoted the data sharing in different lifecycle stages. Nevertheless, due to the lack of the definition of a universal life cycle model, the scope and integrity of data penetration are limited.

Because of the complexity and heterogeneity of manufacturing service data, not all types of data can be integrated, the research on model transformation is gradually carried out. Model transformation is the process of selecting appropriate model transformation method to obtain the target model according to the source model and the pre-defined mapping rules [31, 32]. Model transformation method includes some mapping rules, and the source model needs to maintain semantic consistency with the target model during the transformation process [33, 34].

The initial research is to transform by identifying the common model characteristics in different stages. Rondini et al. [35] put forward the service reference model and standardize the service model delivery process by identifying key attributes of models. Gradually, semantic identification method is applied to the model transformation. A hierarchical semantic mapping method is proposed to achieve data model transformation while still ensuring the semantic consistency [36]. In order to maintain semantic and topological relationship of the 3D model, a multi-scale semantic information transformation model is presented [37]. With the in-depth study of model transformation, the focus of research gradually falls on new technologies of model transformation and mapping methods. A bilateral model transformation method based on file and API is proposed to realize the transformation and sharing of models among different departments [38], and a generic neural network architecture suitable for heterogeneous model transformations is proposed to learn the manipulation operation [39]. To improve the efficiency of model transformation, a translation schema is developed to translate ATL transformations to Java [40], and Petri net is widely used as a process modelling method to transform process semantic information to model data [41]. Subsequently, more and more attention is paid to the quality of model transformation. A method for using proper patterns called MUPPIT is proposed to detect anti-patterns in the transformation [42], and an approach to symbolic execution of transformation to detect logical errors was also presented [43]. Moreover, Chu et al. [44] put forward a transformation method based on UML profile general extension mechanism, which restricts model transformation by establishing templates in extension files to ensure the high quality of model transformation. In addition, some researchers study from the perspective of model evolution and maintenance. A multi-department virtual alliance is constructed to analyze heterogeneous service models within the alliance [45], and the approach which leverages contract-based model testing techniques is proposed to assist engineers in model transformation evolution and repairing [46]. These studies have explored the transformation methods of models from different perspectives, but the effectiveness is not strong due to the lack of summary and refinement of specific transformation operations.

To summarize, the current manufacturing service modelling, integration and model transformation methods have contributed a lot to the resource virtualization and service encapsulation. However, the existing researches mainly focus on partial lifecycle stages, while studies on modelling and transformation methods considering the global life cycle have been rarely carried out. Following these approaches, this paper studies the manufacturing service modelling and transformation method based on the product lifecycle, comprehensively considers the difference and relationship of service models in different stages, and provides a generic modelling and transformation method for manufacturing services from product lifecycle perspective.

3 Service business model and transformation framework

3.1 Life cycle service business model

In cloud manufacturing environment, the life cycle service model refers to resources and capabilities encapsulated and published from all stages of product lifecycle. The process of manufacturing service model sharing environment is shown in Fig. 1. Manufacturing enterprises describe and model their resources and capabilities in life cycle stages, then publish them to the cloud platform as services, which are available for consumers to search and obtain [47]. In this process, accurate modelling and efficient transformation of manufacturing services are the key issues of resource sharing and collaborative manufacturing.

Fig. 1
figure 1

Manufacturing service model sharing environment

Full size image

The life cycle service model needs to be built according to stage-specific requirements. In this study, we take the four most representative stages of design, process, manufacturing and maintenance in product lifecycle as an example, and the business model of life cycle manufacturing service is shown in Fig. 2. The manufacturing service data in various life cycle stages are both different and related. Although the input data, participants and output data of each stage are different, the output of previous stage will become the input of later stage, and together constitute the whole life cycle model from design, production to operation and maintenance stage.

Fig. 2
figure 2

Business model of product lifecycle service

Full size image

On one hand, each stage of product lifecycle has its own manufacturing service data. For instance, in the design stage, there are requirements analysis, structural design, simulation analysis and other design data, while the manufacturing data (such as material blending, machining production and quality inspection, etc.) presents in the manufacturing stage. On the other hand, the service data in different life cycle stages are also interrelated and extended. Considering manufacturing equipment for example, the equipment data is managed as a type resource in the design stage due to the design stage primarily cares about the type of equipment, but in process or manufacturing stage, the equipment data includes both types and individual information because the latter two stages concern about the specific data of each equipment. Therefore, the equipment type data has inheritance relationship among design, process and manufacturing stage, while the individual information is the personalized attribute only belongs to manufacturing stage.

3.2 Transformation framework of service model

Selecting four most representative stages of product lifecycle (i.e. design, process, manufacturing and maintenance) for example, life cycle service model includes four sub-stage models: design service, process service, manufacturing service and maintenance service model. According to the relationship between model services and life cycle stages, the process of transformation includes two aspects: general and view service transformation, as shown in Fig. 3. The former is to update and upgrade general services, and the latter is primarily the addition and deletion operation of view services.

Fig. 3
figure 3

Schematic diagram of life cycle service model transformation

Full size image

The general service transformation must ensure the data integrity because the general service is the resource that exists in multiple life cycle stages. We assumed that the source stage model \({\mathrm{LS}}_{s}\) needs to transform to target stage model \({\mathrm{LS}}_{T}\). The general service data section of the source view model is \(\mathrm{CS}\) and the general service data section of the transformed model is \(\mathrm{CT}\). The two general service data sets need to meet this mathematical relationship: \(\mathrm{CS\subseteq CT}\), it means that the general service data in the source stage should be a subset of the data in the target view model. In other words, during the life cycle model transformation, the target general service model will be an enhanced version model of the source general service. For the view service transformation, the characteristics of life cycle stage should be taken into account since view services are the personalized service data presents in certain or several stages. Therefore, it is important to maintain the data consistency and semantic accuracy during the view service transformation.

Considering data management granularity, the life cycle service model data can be divided into three types: class, batch and piece data. During the transformation process, service model data is converted from class type in design stage to batch type in process stage, and then to batch or piece type in manufacturing and maintenance stage. The granularity of model data is managed by class type in design stage, and is organized by batch type in process stage. Then when the model data evolve to production stage, the model data needs to be associated with specific orders, materials and manufacturers, and the data management granularity becomes piece type. On summary, the service management granularity of service data has evolved from class type in design stage to batch data in process stage then to piece type in production stage. The relationship among class type, batch type and piece type can be expressed as: \(1:\mathrm{M}:\mathrm{N}\), where \(\mathrm{N}\) satisfies \(\mathrm{N}=\sum_{i=1}^{m}{M}_{i}\), and \({M}_{i}\) represents the specific number of each batch.

4 Model definition and transformation operators

4.1 Definitions of life cycle service model

The manufacturing life cycle service model is defined with the introduction of discrete mathematics knowledge in this section. This is a general model that penetrates all lifecycle stages and provides a model basis for subsequent research on transformation operations. Considering the manufacturing service is composed of resources, attributes, behaviors and structures, the modelling of life cycle service is carried out from these four aspects.

Definition 1

(Manufacturing services \(S\)) The manufacturing service is the combination of manufacturing resource \(R\), attributes \(A\) and behaviors \(B\). Manufacturing resource refers to the individual resource which completes a task independently. The attributes of manufacturing resource can be divided into static attributes and dynamic attributes, represented by \({A}_{s}\) and \({A}_{d}\) respectively. Resource behaviors include two categories: class behavior and domain behavior. Class behavior is the ability of the resource itself, represented by \({B}_{class}\). Domain behavior is the ability of business domain or life cycle stage, represented by \({B}_{Domain}\). In general, manufacturing resource is the basis, attributes are basic information description of the resource, and behaviors are capabilities and methods of the resource. Moreover, manufacturing resources include general and view resources. The formalized descriptions of manufacturing service are defined in Eq. (1):

$$S=\langle R,A,B\rangle =\langle {r}_{i},{a}_{i},{b}_{i}\rangle$$
$$S=\langle R,A,B\rangle =\left\{\langle {r}_{gi}\cup {r}_{vj},{a}_{gi}\cup {a}_{vj},{b}_{gi}\cup {b}_{vj}\rangle \right\}$$
$$s.t. \;{{r}_{i}\in R,\;a}_{i} \in \mathrm{A}, {b}_{i}\in B,\;\mathrm{ i},\mathrm{j}\in \left\{\mathrm{1,2},3\cdots n\right\}$$
(1)

Definition 2

(Service structures \(SC\)) The relationship between services is defined as service structure. According to the type, service structure can be divided into hierarchical structure (\(SHC\)), constraint structure (\(SCC\)) and permission structure (\(SRC\)). Hierarchical structure refers to the parent–child relationship between the manufacturing service and other services, such as assembly structure between materials, assembly number, etc. The hierarchical structure can be expressed as follows:

$$SHC=\langle {s}_{i},{s}_{j},{z}_{ij}\rangle$$
(2)

where \({s}_{i}\) is the parent node, \({s}_{j}\) is the child node, and \({z}_{ij}\) is the hierarchical relationship between the two nodes. Furthermore, because of the relationship between manufacturing service and other services, the service will be constrained by other related services. The constrained relationship between services is called constraint structure, such as PBOM is constrained by EBOM, machining equipment is subject to type of process equipment and so on. Constraint structure includes active constraint and passive constraint. This service change causes other services to change, which is called active constraint. On the contrary, the change of this service is caused by other services change, this is called passive constraint. The constraint structure is described as follows:

$${S}_{s}=\left\{{s}_{i}|\exists \langle {s}_{i},s,{scc}_{i}\rangle\;\mathrm{or}\;\langle s,{s}_{i},{scc}_{i}\rangle \right\}$$
(3)

From the data security point of view, the operation of manufacturing services needs permission control. The permission relationship of manufacturing services is called permission structure, which consists of role permission and data permission. Role permission is the access control of different roles to operations, and data permission refers to the access level division of data. The permission structure of service \(S\) is represented in Eq. (4).

$${SRC}_{s}=\left\{src=\langle {s}_{i},{s}_{j},{src}_{ij}\rangle |{s}_{i}=s or {s}_{j}=s\right\}$$
(4)

Definition 3

(Life cycle service model \(LS\)) Based on the above definitions, the life cycle service model is defined as the combination of manufacturing service and service structure, as expressed in Eq. (5). Moreover, the life cycle service model includes general and view service model.

$$LS=\langle {S}_{g},{S}_{v},{\mathrm{SC}}_{g},{\mathrm{SC}}_{v}\rangle =\left\{\langle {s}_{gi},{sc}_{gi}\rangle\;\mathrm{and }\;\langle {s}_{vj},{sc}_{vj}\rangle \right\}$$
$$s.t. {{s}_{gi}\in S, s}_{vj} \in S,\mathrm{ i},\mathrm{j}\in \left\{\mathrm{1,2},3\cdots n\right\}$$
(5)

Taking the life cycle model of part \(\mathrm{p}\) for example, firstly establish the service model (including resource, attributes and behaviors) as follows:

$${S}_{p}=\left\{s=\langle r,{a}_{r},{b}_{r}\rangle |r=\mathrm{p}\right\}$$
$$\begin{aligned}{S}_{p}&=\left\{s=\langle r,{a}_{r},{b}_{r}\rangle |r=\mathrm{p}\right\}\\&=\left\{\langle {r}_{g}\cup {r}_{v},{a}_{s}\cup {a}_{d},{b}_{g}\cup {b}_{d}\rangle |r=\mathrm{p}\right\}\end{aligned}$$
(6)

Considering the relationship between part \(\mathrm{p}\) and other materials, the service structure model can be expressed as:

$${SC}_{p}=\left\{sc=\langle {shc}_{ij},{scc}_{ij},{src}_{ij}\rangle \right\}$$
$$s.t.\;i=p or j=p\;and\;\mathrm{i},\mathrm{j}\in \left\{\mathrm{1,2},3\cdots n\right\}$$
(7)

Finally, the life cycle service model of part \(\mathrm{p}\) (including service model and structure model) is created as follows:

$${LS}_{p}=\langle {S}_{p},{SC}_{p}\rangle$$
(8)

In summary, the relationship between the components of life cycle service model is shown in Fig. 4. The manufacturing service model includes resource, attributes and behaviors. The service structure describes the relationship between the service and other related services of product lifecycle. Manufacturing service model and structure model together constitute the life cycle service model.

Fig. 4
figure 4

Relationship of life cycle model components

Full size image

4.2 Operators for service model transformation

In order to elaborate the process of life cycle service model transformation accurately, eight basic operators are summarized, namely adding, deleting, updating, replication, citing, upgrading, splitting and merging. Furthermore, mathematical symbols are introduced and eight operators are defined mathematically, i.e., addingⒶ, deletionⒹ, updatingⓊ, replicationⓇ, citingⒸ, upgradingⒼ, splittingⓈ, mergingⓂ. These operators have the same priority and are lower than parenthesis.

  1. 1.

    Adding

The adding operator is to increase resource, attributes, behaviors or structures based on the original model. During the transformation process, the target model increases resources or services with their own stage characteristics, then establish structural relationships with the existing services, as shown in Fig. 5a. Assuming that the original service model is \(L\) and the new added service is \({s}_{l}\), the adding operation can be defined as:

Fig. 5
figure 5

Basic operations of model transformation

Full size image
$$L=\langle S,SC\rangle =\langle \left\{{s}_{i},{s}_{j}\right\},\left\{{sc}_{ij}\right\}\rangle$$
$$\begin{aligned}{L}{\textcircled {A} \mathrm{s}}_{l}&=L+\left\{{s}_{l}\right\}+{\mathrm{sc}}_{li}+{sc}_{lj}\\&=\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle\end{aligned}$$
$$s.t. \;\mathrm{i},\mathrm{j}\in \left\{\mathrm{1,2},3\cdots n\right\}\; , i\ne j,l\in {N}^{+}$$
(9)
  1. 2.

    Deletion

In the transformation process of life cycle service model, some resources, attributes, behaviors or structures with stage characteristics should be deleted, so as to reduce data redundancy of service model, as shown in Fig. 5b. We assumed that the original model is \(L\), and the service needs to be removed is \({s}_{l}\), the deletion operation is expressed in Eq. (10).

$$L=\langle S,\mathrm{SC}\rangle =\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle$$
$$\begin{array}{c}{L}{\textcircled {D}\mathrm{s}}_{l}=L-\left\{{s}_{l}\right\}-{sc}_{li}-{sc}_{lj}=\langle \left\{{s}_{i},{s}_{j}\right\},\left\{{sc}_{ij}\right\}\rangle \\ s.t. \; \mathrm{ i},\mathrm{j}\in \left\{\mathrm{1,2},3\cdots n\right\}\;and\;i\ne j\end{array}$$
(10)
  1. 3.

    Updating

During the model transformation process, the value of service model often needs to be updated to meet the requirements of the target stage. The updating operator will not only modify the service itself, but also affect the structure relationship, as shown in Fig. 5c. The original model is assumed as \(\mathrm{L}\), and the service needs to be updated is supposed to be \({\mathrm{s}}_{\mathrm{l}}\). The updating operator is described as follows:

$$L=\langle S,\mathrm{SC}\rangle =\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle$$
$$\begin{aligned}{L}{\textcircled {U}\mathrm{s}}_{l}&=L-\left\{{s}_{l}\right\}-{sc}_{li}-{sc}_{lj}+\left\{\dot{{s}_{l}}\right\}+\dot{{sc}_{li}}+\dot{{sc}_{lj}}\\&=\langle \left\{{s}_{i},\dot{{s}_{l}},{s}_{j}\right\},\left\{{sc}_{li},\dot{{sc}_{lj}},\dot{{sc}_{ij}}\right\}\rangle\\&s.t.\;\mathrm{i},\mathrm{j}\in \left\{\mathrm{1,2},3\cdots n\right\}\;and\;i\ne j\end{aligned}$$
(11)

where \(\dot{{\mathrm{s}}_{\mathrm{l}}}\) and \(\dot{{\mathrm{sc}}_{\mathrm{lj}}}\) represent the updated services and the updated structural relationships respectively.

  1. 4.

    Replication

Due to some services exist in multiple life cycle stages, the target service model can obtain most of the data by replicating from the original model. Replication is one of the most efficient transformation operators. As shown in Fig. 5d, the transformation data of replication operator includes services and structures. Assuming two life cycle service models are \({\mathrm{L}}_{1}\) and \({\mathrm{L}}_{2}\), and the service \({\mathrm{s}}_{\mathrm{l}}\) in \({\mathrm{L}}_{1}\) need to be replicated to \({\mathrm{L}}_{2}\). The replication operator is represented as:

$$\begin{aligned}{\mathrm{L}}_{1}&=\langle S,SC\rangle =\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle\\&s.t.\;i,j\in \left\{\mathrm{1,2},3\cdots n\right\}\;and\;i\ne j\end{aligned}$$
$$\begin{aligned}{\mathrm{L}}_{2}&=\langle S,SC\rangle =\langle \left\{{s}_{p},{s}_{q}\right\},\left\{{sc}_{qp}\right\}\rangle\\&s.t.\;p,q\in \left\{\mathrm{1,2},3\cdots m\right\}\;and\;p\ne q\end{aligned}$$
$$\begin{aligned}{{\mathrm{L}}_{2}\textcircled {R}\mathrm{s}}_{l }\;\mathrm{from }\;{\mathrm{L}}_{1}& ={L}_{2}+\left\{{s}_{l}\right\}+{sc}_{lp}+{sc}_{lq}\\&=\langle \left\{{s}_{p},{s}_{l},{s}_{q}\right\},\left\{{sc}_{pq},{sc}_{lp},{sc}_{lq}\right\}\rangle\end{aligned}$$
(12)
  1. 5.

    Citing

Citing operator is used for the situation when the service model at one stage only need query the service model at another stage without modification. There have great differences between citing operator and copying operator. The copying operation is to create a new service object, while the citing operation is only to establish a reference relationship with the original object. Most importantly, the reference service model can only be queried but not modified. As shown in Fig. 5e, citing operation needs to create relationship between reference service and original service, and establish structural relationship. It is assumed that two life cycle service models are \({\mathrm{L}}_{1}\) and \({\mathrm{L}}_{2}\), model \({\mathrm{L}}_{2}\) needs refer to the service \({\mathrm{s}}_{\mathrm{l}}\) in model \({\mathrm{L}}_{1}\). The formalized descriptions of citing operator can be described as follows:

$$\begin{aligned}{\mathrm{L}}_{1}&=\langle S,\mathrm{SC}\rangle =\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle\\&s.t.\;i,j\in \left\{\mathrm{1,2},3\cdots n\right\}\;and\;i\ne j\end{aligned}$$
$$\begin{aligned}{L}_{2}&=\langle S,\mathrm{SC}\rangle =\langle \left\{{s}_{p},{s}_{q}\right\},\left\{{sc}_{qp}\right\}\rangle\\&s.t.\;p,q\in \left\{\mathrm{1,2},3\cdots m\right\}\;and\;p\ne q\end{aligned}$$
$$\begin{aligned}{{\mathrm{L}}_{2}\textcircled {C}\mathrm{s}}_{l }\;\mathrm{from}\;{\mathrm{L}}_{1}&={L}_{2}+\left\{{{s}_{l}}^{^{\prime}}\right\}+{sc}_{{l}^{^{\prime}}p}+{sc}_{{l}^{^{\prime}}q}\\&=\langle \left\{{s}_{p},{{s}_{l}}^{^{\prime}},{s}_{q}\right\},\left\{{sc}_{pq},{sc}_{{l}^{^{\prime}}p},{sc}_{{l}^{^{\prime}}q}\right\}\rangle\end{aligned}$$
(13)

where \({{s}_{l}}^{^{\prime}}\) is the citing model point to \({s}_{l}\), and \({sc}_{{l}^{^{\prime}}p}\), \({sc}_{{l}^{^{\prime}}q}\) represent the structural relationship between \({{s}_{l}}^{^{\prime}}\) and the original services (\({s}_{p},{s}_{q}\)) in \({L}_{2}\).

  1. 6.

    Upgrading

When service model changes during transformation, the upgrading operator will be used to ensure that the change process can be fully recorded and traced. Upgrading operations create a new service model based on the original service and increase the version number of the model, as shown in Fig. 5f. The service model of old version is converted to background only for query. Suppose that the service needs to be upgraded in life cycle model \(L\) is \({s}_{l}\), the upgrading operator is described in Eq. (14).

$$\begin{aligned}L&=\langle S,SC\rangle =\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle\\&s.t.\;i,j\in \left\{\mathrm{1,2},3\cdots n\right\}\;and\;i\ne j\end{aligned}$$
$$\begin{aligned}{L}{\textcircled {G}\mathrm{s}}_{l}&=L-\left\{{s}_{l}\right\}-{sc}_{li}-{sc}_{lj}+\left\{{s}_{ln}\right\}+{sc}_{l\mathrm{n}i}+{sc}_{lnj}\\&=\langle \left\{{s}_{i},{s}_{ln},{s}_{j}\right\},\left\{{sc}_{l\mathrm{n}i},{sc}_{lnj},{sc}_{ij}\right\}\rangle\end{aligned}$$
(14)

In the formula, \({s}_{ln}\) refers to the upgraded model based on \({s}_{l}\). The upgrading operation satisfies the expression as:

$${s}_{ln}={\mathrm{s}}_{\mathrm{l}}+\Delta {\mathrm{s}}_{\mathrm{l}}+UpdateVersionNo$$
(15)

where \(\Delta {s}_{l}\) represents the increment of transformation, and \(UpdateVersionNo\) describes the upgraded version number.

  1. 7.

    Splitting

Due to different granularity of service model management in various life cycle stages, splitting operator will be used in the conversion process when class data is transferred to batch or piece data. The process of splitting operation includes model service splitting and structural relationship splitting, as shown in Fig. 5g. Assuming the number of service \({s}_{l}\) contained in the life cycle service model \(L\) is \(x\left(x>1\right)\), the splitting operation for implementing piece traceability is described as follows:

$$\begin{aligned}L&=\langle S,SC\rangle =\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle\\&s.t.\;i,j\in \left\{\mathrm{1,2},3\cdots n\right\}\;and\;i\ne j\end{aligned}$$
$${L}{\textcircled {S}\mathrm{s}_{l}}=L+^{S_l}/_{x}$$
$$\langle \left\{{s}_{i},\left({s}_{l1},{s}_{l2}\cdots {s}_{lx}\right),{s}_{j}\right\},\left\{\begin{array}{c}\left({sc}_{l1i},{sc}_{l2i}\cdots {sc}_{lxi}\right),\\ \left({sc}_{l1j},{sc}_{l2j}\cdots {sc}_{lxj}\right),\\ {sc}_{ij}\end{array}\right\}\rangle$$
(16)

where \({s}_{l1},{s}_{l2}\cdots {s}_{lx}\) represent new service models after splitting. Similarly, the corresponding structural relationships are split following the same rules.

  1. 8.

    Merging

Contrary to the splitting operator, the merge operator usually happens in the transformation from batch or piece data to class data. The main purpose of merging operator is to reduce data redundancy and improve data management efficiency. Merging operator involves service model merging and structural relationship merging, as shown in Fig. 5h. Suppose two life cycle service models, \({L}_{1}\) and \({L}_{2}\), need to be merged, and the merging operation is described in Eq. (17).

$${\mathrm{L}}_{1}=\langle {S}_{\mathrm{L}1},{SC}_{L1}\rangle =\langle \left\{{s}_{i},{s}_{l},{s}_{j}\right\},\left\{{sc}_{li},{sc}_{lj},{sc}_{ij}\right\}\rangle$$
$$s.t.\;i,j\in \left\{\mathrm{1,2},3\cdots n\right\}\;and\;i\ne j$$
$${\mathrm{L}}_{2}=\langle {S}_{L2},{SC}_{L2}\rangle =\langle \left\{{s}_{p},{s}_{q}\right\},\left\{{sc}_{qp}\right\}\rangle$$
$$s.t.\;p,q\in \left\{\mathrm{1,2},3\cdots m\right\}\;and\;p\ne q$$
$${L}_{1}\textcircled {M}\mathrm{L}_{2}=$$
$$\begin{aligned}{S}_{\mathrm{L}1}&+{S}_{L2}+\left\{{sc}_{pi},{sc}_{pl},{sc}_{pj}\right\}+\left\{{sc}_{qi},{sc}_{ql},{sc}_{qj}\right\}\\&=\langle \begin{array}{c}\left\{{{s}_{i},{s}_{l},{s}_{j},s}_{p},{s}_{q}\right\},\\ \left\{{{sc}_{li},{sc}_{lj},{sc}_{ij},sc}_{pq},{sc}_{pi},{sc}_{pl},{sc}_{pj},{sc}_{qi},{sc}_{ql},{sc}_{qj}\right\}\end{array}\rangle\end{aligned}$$
(17)

4.3 Transformation process and change propagation

The transformation process of life cycle service models in different stages should follow the principle from the whole to the part. Depending on the analysis of service transformation, the overall flow chart and rule of service model are summarized into three steps (as shown in Fig. 6). Firstly the general and view model of life cycle services are distinguished and transformed, then the service structure (including hierarchical structure, constraint structure and permission structure) is converted, and finally the service model (including resource, attribute and behavior) is transformed.

Fig. 6
figure 6

The transformation logic process of life cycle service model

Full size image

As shown in Fig. 6, the common transformation rules of life cycle service model are divided into three parts, which are displayed with different color blocks. The blue blocks are the beginning part of transformation, which mainly contains life cycle model creation, the determination of transformation scope and direction and the distinguishing of general and view services. The purple blocks are the general service transformation part, which are divided into two aspects: service structure conversion and service model conversion. The service structure conversion is responsible for the transformation of hierarchy structure, constraint structure and permission structure, and the service model conversion is mainly in charge of transformation resources, attributes and behaviors. The yellow blocks are the transformation part of view service models, which primarily consist of deleting the original view service model and adding the target view service model.

In addition, due to the dynamic and complexity characteristics of the production process, the data of service model will inevitably change. In order to describe the transformation process of service model accurately, it is necessary to study and elaborate the change propagation mechanism of service model.

When the data of service model changes, we firstly need to find the change closure, which is a collection of all service models affected by the changed model. The determination of the change closure is mainly depending on service structure relationship, i.e. hierarchical, constraint and permission structure. The transformation process of service models in change closure follow the conversion method proposed in this paper. New life cycle service models will generated after the change propagation transformation. The change propagation mechanism is described in Fig. 7.

Fig. 7
figure 7

Change propagation mechanism of service model

Full size image

In Fig. 7, \({s}_{i}\) refers to the changed service in the life cycle service model \(ls\), \(\omega \left({s}_{i}\right)\) represents the change function of service model, \(\Delta ls\) describes the service change closure based on the analysis of service structure, \(Transf\left(\Delta ls\right)\) defines the transformation function of service model, and \({ls}^{^{\prime}}\) is the new life cycle service models after change propagation transformation.

The change propagation mainly consists of service model transformation and service structure transformation. Taking the change propagation of service model from process stage to manufacturing stage as an example, the change propagation rules are described in Table 1 by using ATL language.

Table 1 Change propagation rules of service model
Full size table

5 Case study

The service model transformation methodology proposed in this study has been successfully applied in an instrument enterprise, and a software system is also developed to realize the data conversion.

5.1 A product BOM service model transformation

BOM is the important data of product life cycle service model, so the transformation process of the product BOM data is very representative. In order to explain the process of service model transformation clearly, this paper selects the BOM model transformation process of an instrument product as a verification example. Considering the confidentiality of enterprise data, materials and structure information of the BOM are fictionalized. The involved materials can be classified into four types: standard part (SP), homemade part (HP), outsourcing part (OP) and purchased part (PP).

According to the transformation method proposed in this study, the life cycle transformation process of the BOM service model is shown in Fig. 8. The shadow parts in the figure which is circled by dash line represent the general service model transformation, the operations of which include adding, updating, citing, splitting, merging and upgrading. Outside the shadow, surrounded by dash dot line is the view service model transformation, the main operations of which mainly include deleting and adding. The detailed transformation flow and operation information are identified and explained in the diagram. The service model management and integration throughout the life cycle are clearly described by the transformation process.

Fig. 8
figure 8

BOM service model transformation process

Full size image

5.2 System implementation

In order to achieve the integration and transformation of service model in different life cycle stages of the instrument enterprise, a transformation platform (TPlatform) architecture is designed, as shown in Fig. 9. The system includes eight transformation operator services (adding, deleting, updating, replication, citing, upgrading, splitting and merging), which are used to ensure the efficiency and accuracy of the conversion. The TPlatform provides a platform system for multiple life cycle BOM models transformation, which includes loading, service model, check, transform operation, publish and other functions. Because the material in manufacturing stage needs to be distinguished between military and civilian, two materials in the process stage are split into four materials in manufacturing stage by invoking the splitting operator (as shown in Fig. 10).

Fig. 9
figure 9

Transform platform framework

Full size image
Fig. 10
figure 10

Splitting operations in TPlatform

Full size image

5.3 Results discussion

Overall, we can see from the case study that the BOM service model can be transformed from one life cycle stage to another by using the method proposed in this paper. In the transformation instance, the conversation process includes general and view model transformation. The operation objects include material, attribute, relationship and relationship attribute. The complexity of attribute and relationship are significantly higher than that of attributes. Due to the complexity of BOM data, the transformation process contains almost all types of operators proposed in this paper. From the perspective of running time, updating is the shortest because it only needs attribute operation, followed by the operators of adding, deleting and citing which related to material or relationship operation, and the most complicated operators are replication, upgrading, splitting and merging which involves both material and attribute operation. Since the transformation of a service model often related to multiple objects, attributes and operators, the running time is proportional to the number of objects, attributes and operators involved.

6 Conclusion and future work

This paper has presented a novel transformation method to address the problem of data interpenetration and efficient model conversion in different stages of product lifecycle. Instead of using data integration or enhancing a stage model, we deeply analyze the data evolution relationship of product lifecycle and build a general model to achieve data interpenetration in different lifecycle stages from the model level. Since the service model in different lifecycle stages has characteristics of modularization and componentization, we propose a novel model transformation method which contains general and view service transformation. Moreover, by summarizing and mathematically defining eight transformation operators, the proposed method can provide more explicit instructions for the model conversion. Furthermore, in order to solve the propagation problem of models in different stages when data changes, we study and establish the change propagation mechanism to ensure the timely data synchronization. The successful application in the transformation of BOM service models in an instrument enterprise verifies the rationality and effectiveness of the proposed methodology.

In the future, we plan to introduce clustering to classify resource before modelling and explore machine learning algorithms to improve the transformation method.