1 Introduction

The optimal process for minimising remanufacturing costs and maximising profits varies with core availability, quality, and demand [1]. Yet, the quantity and quality of returned cores are unpredictable, so the outcome of the remanufacturing operation is highly uncertain [2]. This affects remanufacturing forecasting and operations management [3]. Improving certainty of core quantity [4] and quality [5] using through life data is seen as an opportunity to make “smart” decisions on end-of-life (EoL) product processing [6].

Key smart remanufacturing enablers include cyber physical systems (CPS), the Internet of Things (IoT), artificial intelligence (AI), and big data analytics (BDA) [7]. Using these emerging technologies enables the identification [8], location [9], and determination of the condition [10] of in-use middle-of-life (MoL) remanufacturable products and allows for a level of remote interaction [11], or EoL processing [2, 12], that has previously been unavailable. This has the potential to extract more value to feed the remanufacturing business [13, 14].

As the IoT can digitally link suppliers and customers [15], it may support remanufacturing, providing greater visibility of core availability and quality, reducing reverse supply chain risks [16]. The proliferation of these technologies can enhance remanufacturing forecasting using forward information to alleviate the dual-source uncertainties they face [17]. Embedded sensors combined with condition monitoring can contribute to management in remanufacturing by reducing uncertainties [18]. However, currently, the capturing of accurate, complete, and timely whole lifecycle data presents a challenge [19], as does effectively mining and utilising this information using BDA [20]. Currently, data flows generally breakdown once the product is delivered to the user, and during the MoL stage, it experiences different operating conditions [21] resulting in variance in EoL attributes. Additionally, a level of intelligence and decision-making is required to provide meaningful product MoL information for EoL processing [9].

The digital twin (DT) is identified as a Gartner strategic technology for 2019 [22]. They combine some of the Industry 4.0 (I4.0) technologies to generate a virtual representation of a product, process, or system from inception, through production, to operation (MoL) and finally disposal [23]. DTs have also been proposed to virtually represent operators in human-interfacing CPS [24]. Interestingly, DTs may be applied to conventional products, processes, people, or systems, but its presence does not necessarily imply or preclude intelligent collaborations.

Whist the definition of the DT and associated standards are still in development [25,26,27,28], industry leaders are already exploring the concept in high-value asset applications such as wind turbines [29] and jet engines [30]. However, as the maturity level of the DT concept is so low, there exists many challenges to implementation in this sector [31]. Additionally, competing, but potentially synonymous concepts battle for research resources including the emerging Asset Administrative Shell (AAS) [32] that forms part of the Reference Architectural Model Industrie 4.0 (RAMI 4.0) [33] and the evolving CPS. Both concepts are subtly different from the DT, but have the potential to be harmonised and integrated to become one and the same [34]. It is worth noting that RAMI 4.0 offers an architecture for I4.0 product and process management, based on existing standards, within the production environment (with little to no apparent consideration for products destined for non-production environments). RAMI 4.0 defines the structure that the product or process should exhibit. However, the architecture remains very generalised and provides limited information regarding practical implementation [35], enabling others to exploit the gaps and offer alternatives [36].

As remanufacturing has a greater chance of success in the same high-value sectors [37], and assuming more of these entities reach EoL with associated DTs, it may be possible to consider exploiting the DTs for remanufacturing purposes, as suggested in previous reviews [38]. What is clear is that production planning and control in remanufacturing are more complicated to manage than in manufacturing [4]. There is also a general expectation that the assessment, measuring, capturing, modelling, and presenting of product health and degradation information through advanced technologies that support life extension strategies [39] could be leveraged [40, 41]. To target the unique issues faced by the remanufacturing industry, it is necessary to first understand them. The research question is then, how can product DTs enable smarter remanufacturing?

Following a literature review to highlight issues with uncertainties in remanufacturing and the potential to use DTs to mitigate them, this article will determine the functional requirements for a DT fit for high-value asset remanufacturing and propose a DT model of a generic asset expressed in the Unified Modelling Language (UML). The article will conclude with an example to illustrate a possible application of the proposed model and identify where it could be improved.

2 Literature review

The complications in production planning and control for remanufacturing over manufacturing relate to several issues including:

  • uncertainty in timing and quality of returns

  • the need to balance returns with demand

  • inherent issues found during the disassembly of returned entities

  • uncertainties in materials recovered from returned items

  • the requirement for a reverse logistics network

  • complications of material matching restrictions

  • problems of stochastic routings for materials for remanufacturing operations leading to highly variable processing times [4]

Current manually based data acquisition approaches, widely used during asset recovery only, are inaccurate, and untimely, so decisions based on such data are usually ineffective [21].

2.1 Timing and quality of returns

Research suggests that through implementing emerging technologies, the timing of returns can be incentivised [42], encouraged, and even managed [43]. The timing of returned cores is dependent on a number of factors including sales profile, life expectancy, MoL utilisation, the host environment, and life-extension activities [44]. Other factors include the articulation of actions taken by entities themselves based on their awareness, perception, intelligence, and extroversion of their environment [14]. The approach taken by the OEM or remanufacturers to manage (or not) the return profile also affects the quality of cores available [45] and subsequent profitability [46]. Currently, before (proactive) or after (reactive) the cores arrive at the remanufacturer, quality classification is conducted to determine remanufacturability and to facilitate purchasing (Fig. 1).

Fig. 1
figure 1

Current quality classification methods used in remanufacturing

Full size image

During the life of high-value entities, advancements in technology will occur whereby more efficient offerings will become available. The scale of the difference between the product in use and the new, state-of-the-art, more advanced model, will affect the duration of the former’s life as users balance investing in life extension methods against purchasing new [47]. The application of life extension techniques on only some components within a host asset is associated with an increase in unexpected/unpredictable failure modes, issues with spare parts availability and loss of original manufacturing data, further complicating EoL timing and quality predictions [44].

2.2 The need to balance returns with demand

The demand profile for the remanufactured entities is also volatile, affecting core inventory planning and acquisition [48]. A high demand can allow remanufacturers to increase the selling price but against a low supply it can force them into processing more cores of inferior quality, increasing costs [1]. Contrastingly, low demand and high returns generally offer better quality cores but ties up cash in inventory. Influencing factors include the sequence of processing the cores of different quality classification [1], changes in the condition of existing in-use entities (deterioration etc.), core availability, market behaviour, and the shifting needs of the customers or society [49]. This is further complicated in mixed or hybrid manufacturing and remanufacturing operational environments [50, 51] where the impact of returns can affect the provisioning for the next generation in terms of volume and quality [42], and when the capacity and capability of the facility is overlaid [46].

2.3 Issues found during the disassembly of returns

Disassembly is a significant step in the remanufacturing process [52]. The level of disassembly can vary from partial to complete performed using destructive or non-destructive methods [53]. However, there are several factors that influence the disassemblability of an asset [54] that may not be recognised until the process is underway. These include the solidification of supposedly removable fasteners [55], wear, or cross-threaded components. Other potential hurdles that may or may not be recognised before the process commences include one-way fittings, the use of welded joints or adhesives, and modifications made to the asset during the MoL phase.

Disassembly using robots is a growing research subject [56] but additional functionality is required to deal with the issues found in-process. Researchers have proposed smart [57], reconfigurable [58], collaborative [59,60,61,62], and moveable [63] factories to manage these uncertainties; however, robotics in remanufacturing, and automated testing before disassembly, is not commonplace. Pre-disassembly testing can be performed to minimise the risk of finding issues later in the remanufacturing process. Multi-level inspection cells that contain highly automated testing and scanning equipment [44], combined in some cases with additive manufacturing (AM) facilities [64], have been proposed. Structural integrity of components can also be assessed using ultrasonic inspection methods [65]; however, issues are generally identified during a predominantly manual inspection process [54], and are dealt with on a case-by-case basis.

2.4 Uncertainties in materials recovered from returns

Intellectual property rights can be a barrier to obtaining asset data that can be used to facilitate remanufacturing [66]. This barrier is even higher if the remanufacturers are not partnered with the OEM [67]. Without this information cores can still be processed but the level of uncertainty in the properties of the materials contained within the product can be high.

The state of the materials recovered from returns will be dependent on the core quality, and MoL component exchanges/upgrades. However, the material type depends on the components original manufacturing process. Knowing this information is particularly important if the asset contains hybrid materials or structures [68].

2.5 The reverse-logistics network

Successful management of the reverse supply chain is one way to improve customer perception and loyalty [69,70,71]. It can also play a large part in the profitability of opportunistic 3rd party remanufacturers [72]. The recovery or purchasing of core and its disassembly forms a large part of this network but the design of this system depends on the remanufacturing strategy, the original design philosophy, incentives, and legislative drivers [72].

Other uncertainties that affect the reverse-logistics network include the state of the asset and its whereabouts with respect to the remanufacturing facility [73]. In order to recover the asset, there needs to be a trigger to start the process that makes the remanufacturing agent aware of its availability and location [74]. Once on-site, the management of cores remains a challenge and the tracking of the disassembly through the process needs to be optimised and controlled [75].

2.6 The complications of material matching restrictions

Second generation entities can be formed from multiple cores, and multi-parameter evaluation metrics have been proposed aimed at identifying the best EoL asset to remanufacture [76]. The tracking of components from an asset through the remanufacturing process is also desirable [77]. However, ensuring traceability is particularly important in remanufacturable safety critical entities like battery packs [78] or aircraft engines [79]. In the aerospace industry, where identicality and functionality of the remanufactured asset must be proven, a higher level of testing and certification is applied [80] making the material matching, tracking, and labelling more complex.

2.7 Highly variable processing times

Due to the issues discussed in Sects. 2.1–2.6, there is great variability in remanufacturing routings and processing times. As soon as an asset reaches EoL its routing is likely to differ as its location and state will drive different reverse logistics or disposal requirements [74]. Once at the remanufacturing facility, the objective (to remanufacture-to-order or disassemble-to-order etc.) will also drive different solutions [2].

The disassembly process, whether it be manual or automated, smart or otherwise, needs to be planned with its optimisation being a popular topic [81] and on-line re-planning may be beneficial [82]. However, the stochastic nature of the volume and quality of the returns makes fully automated disassembly challenging [83]. The remanufacturer can aim to minimise the variability or allow it to exist and install flexible solutions [84], but much of this is currently performed manually, in-process, by the operations team which is why the process times are highly variable.

2.8 The digital twin

There is growing interest in the fusion of sensors and data to form DTs [85] for products [86], people [24], or processes [77] in manufacturing that can be applied to remanufacturing [87].

The DT concept first proposed in the early 2000s comprises three main elements (Fig. 2):

  • a real product in real space

  • a virtual product in virtual space

  • the connections of data and information that tie the “products” together [88].

Fig. 2
figure 2

The three elements of a digital twin

Full size image

This has been expanded, and DTs can now represent individual components, products (assets), operators, systems, or processes [89] referred herein as “entities.” They can also be combined depending on the insight required; e.g. product and production processing data can be leveraged to represent operational performance [90]. NASA justified the need to develop DTs in 2012 for advancing fleet design and management through virtually mirroring the life of the real aircraft, describing the DT as an integration of ultra-high-fidelity simulations with the aircraft’s on-board health management system, maintenance history, and all available historical and fleet data [91]. If a fleet, in a space agency/military environment, is a collection of ships, aircraft, or vehicles that operate under a unified control [92], in non-military terms, this could translate to a family of similar products that are operated, managed, or owned by the same organisation. The DT concept first proposed for the management of military fleets has already started to crossover into non-military applications [93]. In this manuscript, “fleet” will be used to describe aggregates of the military and non-military kind. In summary, the DT structure relies on connectivity to the real asset, where local systems perform condition monitoring and management considering the immediate environment, where real-time performance data is collected and fed into simulation tools and or, storage for performance predictions calculations and historic analytics, respectively. The data store can also accept fleet data for analysis of the real entity with others in the field (Fig. 3).

Fig. 3
figure 3

Data flows in a basic digital twin

Full size image

With the exception of people, the real and virtual assets are expected to be connected from creation, to manufacturing, through in-use operation and finishing at EoL [94] forming a through life digital thread [95]. DTs can exist as a single instance corresponding to a specific asset (DTI), an aggregate of similar entities (DTA), or an environment (DTE) applicable to both the DTIs and DTAs depending on its purpose [94].

In summary, different strategies to mitigate the uncertainties in remanufacturing have been explored but findings suggest these are generally visionary. Additionally, research published in 2019 suggested that no tool had yet been designed, proposed or recognised as a complete solution [79], and only 6% of articles focused on remanufacturing decision-making considered two or more uncertainty types in 2020 [96]. The AAS from RAMI 4.0 has been described by some as a DT, but it remains immature. The term “digital twin” is referenced only once in the standard [97], lacks implementation detail, and is focused on manufacturing industry based equipment, processes and systems only.

There are many benefits to be had from enabling asset visibility throughout its lifecycle. In remanufacturing, these are associated with planning and controlling operations and assessing an entities suitability for processing [19]. There does not appear to be any research published on leveraging DTs to resolve some of the uncertainties in remanufacturing, and there is a clear requirement to demonstrate the benefits of I4.0 for this sector. It is for these reasons that the DT as potential solution will be explored to reduce uncertainties in high value asset remanufacturing planning and control.

3 Requirements for DTs in high-value asset remanufacturing

This section defines the functional requirements for DTs to reduce the impact of the challenges found in remanufacturing. Section 3.1 derives boundary conditions and assumptions from the information presented in Sect. 2.8. Section 3.2 translates the findings from the literature review (Sects. 2.1–2.7) into high-level requirements and discusses how they may be fulfilled with respect to product life cycle management. Section 3.3 considers the need for instantaneous digital instances, and Sect. 3.4 allocates out the requirements to develop a simple UML model of a generic asset.

3.1 Asset criteria

There is a base level of technical capability needed from the asset to support the generation of associated DTs. Similarly, there are certain requirements from the initial manufacturing process needed to populate the early life of the DT. It is therefore necessary to define some assumptions that are made about the asset to be remanufactured. The assumptions based on the findings in [38] are as follows:

  • the asset to be remanufactured has been designed using CAD techniques, manufactured using processes that provide digital in-process verification measurements and are tested to applicable standards.

  • the asset to be remanufactured is sensorised, and key performance indicators are monitored.

  • the environment in which the asset is utilised is controlled (and is known) or is also monitored with data available to reference.

  • that some form of connectivity to the internet is available once the asset has been manufactured (towards the end of its BoL phase), but before it reaches the customer, and during the MoL and EoL phases.

With these capabilities, an asset can be considered a candidate for digital twinning, but the detailed requirements and how they may be fulfilled, are yet to be defined.

3.2 Translating high-value asset remanufacturing issues to requirements

The basic requirements of the DT, extracted from Sect. 2, are presented in Table 1. Categorised by issue, each of the 16 requirements have been given an ID and a short explanation of what they would enable. Whilst the requirements would need to be fully completed by the time the product reaches remanufacturing, some can be attained early in the product’s life and remain static, whilst others will need to come later and may need to be dynamic. Mapping the requirements against a closed-loop product lifecycle offers an insight into where the information to fill them can be found (Fig. 4). The BoL, MoL, and EoL stages are also shown for clarity in discussion.

Table 1 Summary of requirements for DT to support remanufacturing
Full size table
Fig. 4
figure 4

Assignment of requirements for remanufacturing to different PLM stages

Full size image

At the BoL, the product type CAD and engineering BoM (eBoM) can provide asset design information at component, sub, and complete assembly level, useful for remanufacturing process design. Model order reduction may well be needed to balance accuracy, accessibility, and speed for real-time connectivity and decision-making but at least the baseline information already exists. Additionally, the manufacturing BoM (mBoM) and as-built data provides information on the realised, uniquely identifiable, asset, and its components. This is necessary as it captures deviations within tolerances and non-conformance entities that have been processed with waivers. Examples of useful information include, as-machined geometry for component repair [98], originally applied torques for implied unscrewing requirements [99] and key product characteristics to manufacture/purchase replacement parts [100]. The as-shipped performance results (from physical tests or simulation) may be obtained (from OEM PLM, MES, or similar database) to support remanufacturing expectation limits for functionality assessment. The real asset will be connected to the IoT before being released to the marketplace with its DT (stored locally or remotely) already populated with its BoL data.

The unique identification of the core and the remanufacturable components within it is necessary to enable monitoring and processing through remanufacturing. Serialised RFID is a popular solution to store the ID [6, 9], but there are other methods that deserve consideration including basic 2D codes through to more advanced self-sensing tags [101]. Either way, the unique ID, issued during manufacturing, will be linked to metadata that describes the asset and supports the evaluation of its performance against others in the field. To accurately evaluate, the existence and location of the entities in the field can be made visible during distribution.

Once in-use the asset needs to be connected to the IoT to emit status, performance, and residual life estimates. Useful in this domain is the asset quality metric, key to evaluating remanufacturability. There is growing tendency to use data recorded in electronic devices to form part of a remanufacturing pre-inspection process but this is still rare [102]. These can be used to estimate remaining useful life that in turn can indicate quality [103], but generally, the metric comes in the form of a quality classification bestowed on the asset following a physical inspection at EoL [51]. Typically, the classes are pre-determined, and the inspection process is assumed to be perfect; however, the classification methods themselves depend on the quality distribution, and human errors are inevitable [51]. Consequently, this mismatch has led to the development of a “certainty of product quality” (CPQ) metric, populated using MoL data captured from sensors providing visibility of status, performance, quality, and quantity to support confident data-driven decision-making [5].

Location, and or, readiness of the of asset when it reaches EoL can be supported by the integration of RFID tags and sensors read by mobile data systems, Wi-Fi, or GPS to support traceability of return flows [6, 104] or inventory through the remanufacturing process [75, 105, 106]. The asset locating data can flow into the DT to allow for earlier purchasing and process management decisions.

For EoL processing, the most recent BoM is required, but this is not necessarily the original mBoM. Changes may have occurred during MoL utilisation. (Lejon, Jeppsson [107] propose a concept that enables MoL information to be integrated to a virtual product representation within TeamCenter PLM.) Access to the most recent BoM can help formulate a service BoM, the process of which could be applied to the development of a remanufacturing BoM (rBoM) [56]. Depending on the level of remanufacturing expected, the component level content of the asset may be enough. However, the release of sub-assemblies for secondary processing and coordination with purchasing becomes complicated, and where component repair through subtractive, additive, or hybrid machining methods is expected, material level data would have to be available to be truly beneficial without the need to employ reverse engineering techniques.

Once an asset has reached its EoL, its DT can be updated to reflect this. Some aspects of the DT may enter a state of suspended animation at this point, as in-use data is no-longer generated. However, it would be beneficial to retain frequently updated location information at least up until a decision has been made on how it will be processed. If the asset is disposed of, then the DT can also be deleted (unless a viable EoL use for the data is also established [108]). However, if the asset is to be remanufactured, the reverse logistics network needs to be utilised to recover it and the DT needs to be saved.

Making the manufacturing Bill of Process (BoP) available at the entities EoL may not help remanufacturing routings. As the process of remanufacturing includes both disassembly and assembly operations, the remanufacturing BoP (rBoP) is significantly different to the manufacturing or reverse assembly BoP. The potential for selective or partial disassembly processes also drives different equipment requirements, and applications. However, disassembly process planning required to formulate the rBoM and rBoP would benefit from information that describes the relationships between components within the asset [109] and the as-built data (previously described), along with a current state remanufacturing facility model. This would allow mapping of the core’s requirements against the facility capacity and capability and to allow disassembly simulations to be analysed [110]. The real remanufacturing process can also be represented as a DT updated with real-time information [37, 77]. However, issues found during the disassembly process are complex making it difficult to develop specific elements of a DT to assist. Tightly linked material physics level DTs may offer some support, but current CAx systems struggle replicating material warping and fastener solidification etc. Adaptive geometry modelling is being developed to allow nominal models to be updated with measured data [111] but assessing material level change is not practical when the asset is in-use. Furthermore, sensorising the real asset to feed back this data is equally challenging. This limits the impact of the DT in reducing disassembly uncertainties. Looking further afield, visibility of future entities that share components with the current generation could be useful to predict demand, as big data systems offer tools for fusing diverse information streams, improving forecasting for remanufacturing [112].

3.3 The need for instantaneous digital instances

At every stage of the asset’s life, there is a need to update the virtual twin to match that of the real one. However, as can be seen from the previous section, current state information alone is insufficient. There is still a need to access data from previous key points in the asset’s life. For example, should a DT be sufficiently advanced to reflect a worn valve seat in a cylinder-head assembly, without the original as-built data an alternative method of identifying the need for metal deposition and/or machining will need to be found to remanufacture the part. Additionally, BoL data can be used by remanufacturers to ensure they supply an asset that meets the definition of “remanufactured” by matching or surpassing “as-new” performance. This may be best managed by a set of digital instances (siblings) that reflect the real asset (current state), previous, simulated, and potential future states. The digital siblings can remain in a suspended state, without modification, to be called on at EoL (Fig. 5). This way remanufacturers have visibility of the previous state, current state, and potential future states of the asset whether that be a component, product, system, or process.

Fig. 5
figure 5

Key digital instances that need to remain in a suspended state for remanufacturing

Full size image

3.4 Assignment of digital twin requirements

Component and product DTs can be combined, just like their real counterparts, to form an aggregate process or system DT. It is therefore advantageous to set boundaries for future work by distributing the requirements between those that best relate to the component/product, or system/process level DT. It should be recognised that some cross-over is expected and will be scenario and environment dependent. Taking inspiration from Goodall et al. [87], Kusiak [113], and Kiritsis et al. [114], a generic asset and the DT remanufacturing requirements are modelled using a Visio UML class diagram (Fig. 6). UML provides a standard approach to presenting both conceptual and real processes, functions, and schemes for software systems and the UML Class diagram has been selected because they can document the key static elements of any object-oriented design [115]. The structure, metadata, and connections shown in the UML model need to be set up before the build is released to production or prior to shipment. The model is developed based on the information gathered from the literature review and following an iterative design process when applied to the example. The attributes and relationships of the model are described below.

Fig. 6
figure 6

UML class diagram model of DT enabled asset in remanufacturing

Full size image

Figure 6 is divided into three sections: level 1 “real,” level 2 “virtual,” and level 3 “process.” The relationships between the classes are denoted by the association, direct association, inheritance, aggregation, and composition connection lines arrows as documented in [116]. As can be seen from the figure, information flows back and forth between the 3 different levels. This close coupling of the physical and virtual products along with the wider process is what makes the digital twins so useful in this application.

The classes in level 3 process show key remanufacturing process functions that are likely to pre-exist. As a result, the attributes and operations for each class have not been defined. In summary, labour (Human_Resource), materials (Material_Resource), and equipment (Equipment_Resource) combine to form the remanufacturing resources (Resources) with a mixture of attributes reflecting skill levels, availability performance and quality. Not all resources are required, but to add value to the core, there needs to be at least one. The capability (Real_Reman_Capability) is exclusively dependent on these resources. The capability of the facility is also a function of the process that has been established (Reman_Process) at the current time and location (Reman_Time_Location), the capacity (Real_Reman_Capacity), which is itself a function of the current work-in-progress (Reman_WIP). The process and the remanufacturing BoM (Reman_BoM) are related, both dependent on the requirements of the inbound core (Reman_Core) and demand (Demand).

The classes in level 1 real, towards the bottom of Fig. 6, also represent likely pre-existing remanufacturable product functions. However, identified attributes have been defined as they are needed for upstream processing. All attributes are denoted as public at this stage. High-value products go through detailed design iterations, but when the product is manufactured, it is done so to a standard set of requirements (As_Designed_Entity). The As_Designed_Entity class needs to be identifiable and specific to the remanufacturable asset. As previously described, CAD, BoM, test specifications (Test_Spec), and operating limits (Operating_Limits) can be useful to remanufacturers but so too could the asset manual (Manual), the details of interfaces and connections for test processes (Test_Interfaces), a list of fluids, lubricants, oils, pneumatics settings used (FLOPS), the related material safety data sheets (MSDS), any software details (Software_Spec), and the identity of the parent parts the child entity could belong to (Compatible_Parent_ID_Type).

The class As_Built_Entity derives from the As_Designed_Entity and reflects the specific assembly details of the entity Real_Entity. The key attributes from this class needed for remanufacturing include characteristics (critical or special) and test results, details of any deviations (Approved_Deviations) from the As_Designed_Entity, and specific details like firmware level. The class Real_Entity exists to represent the physical asset in its current state with attributes relating to its release date (approximately start of MoL), the entities parent part (Parent_ID) if applicable, and when it became associated with the parent (Child_of_Parent_Since). This becomes relevant if an asset has been modified from the As_Built_Entity state and is now a hybrid assembly (i.e. MoL maintenance activity). Every Real_Entity has a unique ID (Real_ID) and an ID_TYPE, necessary to communicate the format method (human-readable, RFID, QR (Quick Response) code etc.). They could belong to many groups (Entity_Groups) that are made up of entities that have the same As_Designed_Entity attributes, generally referred to as “product type” or “family” in industry.

As already described, for an asset to support a DT, it needs at least one sensor (Sensor). The attributes of the sensors need to be well defined to assess accuracy of measurement and confidence at both instance and aggregate level DT, whist Sensor_Data provides the value (Sensor_value) and associated timestamp (Meas._Timestamp). Both the current time and location (Entity_Time_Location) feeds the information related to the asset in its current state (Current_Status) that itself contains an incarnation attribute (Incarnations) to capture the number of life cycles the asset has been through previously, its status (Status), e.g. operational, stand-by, offline, and unserviceable and its readiness (Availability) for remanufacturing. Completing this section, modification to the asset during MoL is captured in Field_Activity for the events triggered by servicing, maintenance, or user reconfiguration, or in In_MoL_Mod_Entity for self-adjusted (where the asset makes changes to itself). Both classes support the changes that will occur in the Real_Entity following the modification/reconfiguration and do so by capturing a timestamp and description. Additionally, In_MoL_Mod_Entity contains three Boolean attributes, DMM_Init._Activity and Field_Init_Activity, that indicate whether or not the self-adjustment was enacted as a result of decisions made in the virtual environment (Decision_Making_Module) or the field activity respectively, and Auto_Release that defines whether the change activity was managed solely by the asset or involved secondary, probably human, approval and release.

The final middle section (level 2 virtual) functions in the digital world. It takes information from both the real asset and remanufacturing business, evaluates it, and then makes decisions on future activities. Starting with the digital, exclusive representation of the real asset, the As_Built_Entity combined with the Field_Activity data flows through the Real_Entity to populate the Virtual_Entity. Each virtual asset will require a unique ID (Virtual_ID) that would benefit for being linked to Real_ID. From the data available at this stage, different simulations (Entity_Simulation) can be triggered with the relevant simulation parameters (Sim._Parameters). The results from the simulations (Sim._Results) can formulate a vision and estimate of the future state (eFuture_State). Key predictions for remanufacturing process management include an estimate of RUL (eRUL). This drives the predicted EoL date (eEoL). To exemplify how the DT information could enable data-driven decision making for remanufacturing, consider the following. If the predicted EoL date coincided with a gap in the work schedule of the remanufacturing facility, the product could be actively targeted for recovery. Similarly, if a product simulation identified a future failure mode that the remanufacturing business specialised in rectifying, or where the manufacturer had unallocated replacement parts in stock, the product could again be targeted over others with different potential failure modes. An estimate of quality (eQuality) and failure mode (eFailure_Mode) at eEoL are linked and may be possible simulation outputs. The estimation of quality at EoL may not always be zero as the failure mode may affect only part of the product. For example, a piston seizure can cause a catastrophic failure and unrecoverable engine; however, a valve seizure is likely to need only a cylinder head replacement making remanufacturing a more realistic proposition. Errors in accuracy, precision, and resolution of the measurements taken by the sensors, those embedded in the virtual models and simulation algorithms amongst others need to be appreciated. This warrants a confidence level attribute (EoL_Confidence) at this class.

The eFuture_State class can offer an insight into the potentially recoverable parts of the asset. Virtual_Core takes this information and extracts the associated parts from Virtual_Entity to generate a virtual core that can be utilised to assess remanufacturing BoM, processing and resource requirements, opportunities, and risks (Reman_Opportunities). These can be assessed through the normal channels. Alternatively, the virtual core could be pulled into a process simulation (Process_Simulation) to assess the same, with a decision-making module (Decision_Making_Module) that considers the outputs of the future state estimates to feed into the In_MoL_Mod_Entity enabling asset self-enlightenment and adjustment, with the aim to balance RUL with remanufacturing optimisation. The Decision_Making_Module can utilise the fleet data to trigger the most relevant simulation to run in Entity_Simulation. The trigger could be the eFuture_State data being above or below thresholds that relate to the distribution of the fleet’s performance and that of the remanufacturing opportunities from Reman_Opportunities. The details of how the Decision_Making_Module would function in reality need further exploration.

The UML Class diagram has been formulated from the DT requirements. To illustrate its potential and to identify areas of improvement, an example of how it can be applied is described in the next section.

4 Example

This section utilises the remanufacturing of engines for large off-road applications as an example to analyse the applicability of the proposed model and to identify areas where it could be improved.

4.1 Overview

With a global footprint, company A employs over 100 k people and generated USD53billion in global sales and revenue in 2019, supplying products and services in construction, power generation and transportation. With over 1 million connected assets, it already utilises internet-based support systems and encourages sustainable and circular business practices including remanufacturing.

Large industrial and off-road engines form part of the company’s portfolio. They tend to have long life spans, meet the basic asset criteria defined in Sect. 3.1 and fit the high-value asset description that is the focus of this work. With design, development, manufacturing, and remanufacturing facilities in the UK, this company offers an applicable, local insight into current OEM practices that could be leveraged. It is therefore possible to evaluate the model by overlaying the pre-existing product attributes and business systems.

4.2 Model implementation

The manufacturing and remanufacturing functions exist in different locations and parts of the business. This makes the sharing of relevant information more complex. Additionally, it was not possible to use the same engine that is currently being designed and manufactured in one facility, as that being remanufactured in the other as they belonged to different product families. Instead, two different engines have had to be used from the same company, and an assumption made that the high-level manufacturing process and remanufacturing process are the same for both products. The model is populated with example data from both the manufacturing and remanufacturing functions (Fig. 7).

Fig. 7
figure 7

UML class diagram model of DT containing example information

Full size image

Starting with the product design (As_Designed_Entity), each product does belong to a family (Entity_Group), referred to as the 4006-23TAG3A. Design activity occurs in Creo (formerly Pro-Engineer). This package allows for structural, thermal, and modal analysis on 3D CAD designs in the same environments. In parallel with development, the product manual, testing, and operating requirements are defined and managed using internal quality systems and ISO 9001:2015. This product can be installed in many different systems, but a popular compatible parent product is the P800P1.

The As_Built_Entity data can be populated from the manufacturing execution system (MES) that manage the semi-automated assembly lines. All critical and special characteristic torques are applied using monitored tooling; results are captured and available for post processing or querying. Similarly, test results, certificates, and deviation approvals are available in the quality management system (QMS).

Each product is released to the build-line with its own unique ID, generated from the family, order number, manufacturing location, and year of manufacture information. This is available on the data-plate as human-readable only. (RFID chips in bolt heads fitted to the products are used in some facilities to allow process data transmission, but most in-service products have only the data-plate.) Some major components that form the product also have unique IDs (and many are both human and machine-readable with dot-matrix, bar or QR code etching), but many of the parts are referenced at an Entity_Type level and contain no part information or unique identifier.

The finished product is sensorised measuring key parameters including torque, speed, temperatures, and pressures, all linked to the engine control unit (ECU). Slave sensors are also fitted for engine performance testing but are not available in MoL. The on-product sensors that exist when it enters MoL are designed to feed PID (proportional–integral–derivative) controllers for optimising performance.

At the remanufacturing facility human and material resources, BoM and WIP are managed by the cloud ERP (Enterprise Resource Planning) system “QAD Next Generation,” whilst equipment resources, capability, and capacity planning along with process design are managed by the manufacturing engineering team using Excel spreadsheets. The process itself remains highly manual, with discrete workstations that are managed at a shop-floor level. There is little to no use of simulation tools to plan the remanufacturing process and no system to provide visibility of inbound core quality, failure mode, or automated decision making on what could be salvaged at unit level.

The Virtual_Entity is utilised in the Entity_Simulation. In this fabricated scenario, fleet data suggests engines in similar environments all suffer from valve failure. With this information, the Decision_Making_Module triggers a CFD (Computational Fluid Dynamics) and FEA (finite element analysis) simulation to be run in Entity_Simulation to estimate valve guide life as per Roth [117]. In this scenario, RUL and EoL are estimated to be 3 × 109 cycles and June 2030 respectively with a current quality (eQuality) of 70%. The failure (eFailure_Mode) assessed by the Entity_Simulation indicates valve or guide wear as the leading mode, with an EoL confidence (EoL_Confidence) level of 65%. EoL_Confidence is a function of time of latest data update, accuracy of readings, the similarities between this asset and others in the fleet, and the results of the simulations. The Available_Core would list all potentially remanufacturable components from this engine should the failure mode be realised. Those components would then be used to populate the virtual core (Virtual_Core) for remanufacturing process simulation.

4.3 Discussion

Using the above example and engine failure scenario, an assessment of the proposed model can be made. Several gaps can be identified. Currently, many parts that constitute the product do not possess unique IDs. The product itself does not have an online presence. It does not have GPS or a clock for Entity_Time_Location data. Field_Activity and In_MoL_Mod_Entity data cannot be digitally populated currently (although service systems do exist). The CAD models that are available represent only the family, not the individual product. The sensors that are fitted are there for performance optimisation, not fault detection, and design (As_Designed_Entity) and production (As_Built_Entity) information exists but it is decentralised and inaccessible remotely. Some of the remanufacturing planning is done on an integrated cloud-based ERP, but much of it remains on human-driven Excel spreadsheets. Whist effective, it lacks integration and autonomy. It is possible to extract a unique virtual ID from the real product ID but beyond that the extraction of the Virtual_Core from the Virtual_Entity, the relationships it has with the information from the eFuture_State, Process_Simulation, Reman_Opportunities and the Decision_Making_Module need to be further defined and explored.

5 Conclusion

Cyber Physical Systems, Asset Administrative Shells, and digital twins are emerging from the Industry 4.0 paradigm, competing, and often overlapping in the same development space. In this work, the digital twin (DT) has been proposed as the tool to improve and automate decision-making for remanufacturing, improving visibility of inbound core quantity, quality, demand, and processing opportunities. Although the DT concept appears less mature than the other two, greater emphasis is placed on its simulation capabilities which is a significant attribute when predicting life expectancy, failure modes, and processing outcomes for remanufacturing cores.

Both remanufacturing and DTs are growing in popularity among researchers. Despite this, there are significant gaps in the definition and development of the DT and its implementation in the remanufacturing industry. This work offers a first step towards filling these gaps by first clarifying the remanufacturing issues, translating them into DT requirements, creating a universal DT model, and evaluating the model using an example. The main challenge to DTs being utilised for remanufacturing purposes is access to BoL and MoL data. Intellectual property rights as well as MoL data privacy and security are a sensitive subject and are unlikely to be resolved with current technologies and systems in many applications (e.g. military).

A limitation of this work is that it utilises only one example to evaluate the model. Whilst it offers a useful insight into one business that has a strong and celebrated remanufacturing presence in the UK, it should not be deemed representative of the entire sector. There are several potential future work streams including assessing the model for other existing or prospective remanufacturing businesses, including independent remanufacturers, and looking at how the lessons learned can be translated to other sectors. To suit different sectors, an extension to the 2D UML models presented herein may be necessary. The use of 3D UML could be explored to improve the visualisation of the data flows. Applying the model to other use cases to close the gaps identified between the model and the demonstration asset as documented in the discussion section would also be worthwhile. There needs to be more research into the decision-making module to enable the automated decision-making process to utilise data to choose whether an EoL product is remanufactured or not. Additionally, quantitative estimates of the benefits are needed to evaluate the real potential of DT for high-value assets. This too requires real-world data over extended periods of time or the extrapolation of models and assumptions that could not be obtained during this research. However, the main gaps relate to the metadata that needs to be derived, and how the individual business systems that currently manage the entire product lifecycle are coupled closer together to enable a product DT that supports remanufacturing.