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 section 2.8. Section 3.2 translates the findings from the literature review (sections 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 section 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 DT. 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 [39] 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 section 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
Issue
|
Req. ID
|
Requirement
|
Enable
|
Timing and quality of returns
|
a
|
To understand the quantity and quality of the entities in the field
|
The visibility of MoL status and performance
|
b
|
To predict when an asset is likely to require remanufacturing
|
An estimate of remaining useful life
|
c
|
To understand the quality of the asset during MoL and at EoL
|
An asset quality metric
|
The need to balance returns with demand
|
d
|
To understand the profile of potential returns considering the original sales volume
|
Visibility of the quantity and quality of entities in MoL at customer, and at EoL in remanufacturing stream
|
e
|
To improve demand and opportunity forecasting
|
Visibility of future entities that share components with the current generation
|
f
|
To support proactive remanufacturing operations planning
|
Mapping of core requirements against facility capacity and capability
|
Issues found during the disassembly of returns
|
g
|
To understand the quantity and type of components and fastening methods used in the asset before processing
|
Access to the original CAD models and BoM
|
h
|
To identify potential disassembly issues before the process starts
|
Visibility of the as-built in-process verification results
|
Uncertainties in materials recovered from returns
|
i
|
Ensure MoL service / upgrades are visible and to enable rectification / AM process success
|
Access to the latest BoM containing component material level data
|
The reverse-logistics network
|
j
|
Proactively manage core collection
|
Location and readiness of the of asset when it reaches EoL
|
k
|
Track through the remanufacturing process and to allocate data
|
Unique identification of entities
|
The complications of material matching restrictions
|
l
|
Enable multiple generations of parts to exist in the same product
|
Uniquely identify remanufacturable components within an asset
|
m
|
Ensure alignment with the real asset through multiple life cycles
|
Enable the “remanufacturing” of the digital asset
|
n
|
Support functionality testing
|
Access the entities original as-shipped performance results
|
Highly variable processing times
|
o
|
Virtually plan and manage routings based on core quantity and quality data
|
Access to a remanufacturing facility model
|
p
|
Optimise disassembly sequence
|
Disassembly process simulation results
|
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 [95] 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 [96], originally applied torques for implied unscrewing requirements [97] and key product characteristics to manufacture / purchase replacement parts [98]. 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 [9,6] but there are other methods that deserve consideration including basic 2D codes through to more advanced self-sensing tags [99]. 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 [100]. These can be used to estimate remaining useful life that in turn can indicate quality [101], but generally, the metric comes in the form of a quality classification bestowed on the asset following a physical inspection at EoL [52]. 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 [52]. 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,102] or inventory through the remanufacturing process [103,76,104]. 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 [105] 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) [57]. 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 [106]). 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 [107] 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 [108]. The real remanufacturing process can also be represented as a DT updated with real-time information [78,38]. However, issues found during the disassembly process are complex making it difficult to develop specific elements of DT to assist. Tightly linked material physics level DT 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 [109] 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 [110].
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.
3.4 Assignment of Digital Twin Requirements
Component and product DT 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. [88], Kiritsis et al. [111] and Singh et al. [112], a generic asset and the DT remanufacturing requirements are modelled using a Visio UML class diagram (Fig. 6). The model is developed based on the information gathered from the literature review and following an iterative design process when applied to the case study. The attributes and relationships of the model are described below.
Figure 6 is divided into three sections, level 1 ‘real’, level 2 ‘virtual’ and level 3 ‘process’. 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 (Real_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_BoL) 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 etc. The class Real_Entity exists to represent the physical asset in its current state with attributes relating to its release date (approx. 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 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, unserviceable etc. 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). 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 UML Class diagram has been formulated from the DT requirements. To illustrate its potential and to identify areas of improvement, a preliminary case study has been conducted as reported in the next section.