In our previous post , Digital Twin – Arnold or Danny?, we introduced our view of what a Digital Twin is and defined it as:
Standardized functional structure with associated designation system containing installed items, spare parts, individuals, and documents stored in a facility register that is continuously updated in a maintenance system.
It's a sentence with content that can be a little difficult to digest. If we break it down, turn it around, and try to explain a Digital Twin using anatomical terms, will it be easier to digest? We'll start with the standardized functional structure and associated designation system.
Standardized functional structure with associated designation system
Explaining what a functional structure is to someone who has never heard of it before is like offering ice cream in a sauna. You might get a taste, but there's no chance you'll eat the whole ice cream.
But if we continue with the anatomical theme, the functional structure can be likened to a skeleton where all parts perform a function in a larger whole. All bones contribute to the whole, but one bone can be replaced while the overall function remains the same. Like a prosthesis or, for that matter, spare parts for an engine.
That is precisely whyfunctionalityis important as a concept in a maintenance system, because parts are replaced continuously, but you want to have the overall follow-up and history for the functionality. It's a bit like if you needed to replace the odometer in your car. You don't care how many miles that particular odometer has counted, but rather the total mileage.
In addition, drawings and diagrams describing a machine are always based on function, which makes it a seamless transition to represent the machine as a Digital Twin in the system, where you can easily see the connection between reality and your information.
But what aboutstructure? Why do you need it? Well, simply put, so that you have a chance of finding the right function and information about your facility. Without structure, your skeleton becomes nothing more than a pile of bones!
Finally, adesignation systemwill be required, andthere is a world-leading standard called RDS (Reference Designation System) that can be applied to all types of facilities (yes, all of them!).
RDS is an identification system that provides us with consistent rules for naming and structuring the various systems and units that make up a facility. This ensures that two similar functions or parts are never confused. Imagine breaking your thumb but not being able to tell the doctor whether it is your right or left thumb. Just as all the bones in the body have unique names, the parts of a facility also need to be uniquely identifiable.
There are tons of benefits once you have astandardized functional structure with a related naming systemin place, but the main ones are:
- The time needed to find the right information is drastically reduced.
- The likelihood that the information about your assets is accurate and up to date increases significantly, and the credibility of your system increases.
- Accurate and up-to-date information contributes to greater use and creates a positive spiral, as there is an incentive to keep the information constantly updated.
- It always looks the same in the system, and everything can be gathered in one place. Regardless of where you are in the organization or the world, you share the same view of the status of your facilities.
- For organizations that want to work more with predictive maintenance rather than preventive and reactive maintenance, this is a foundation that must first be built.
- You can require suppliers to submit drawings and information according to a standard, which greatly simplifies integration and the flow of information from third parties.
- If you have ambitions for Industry 4.0 with automation, machine learning, and the use of IoT sensors, it is more or less a prerequisite to first have control and structure in your facilities.
So, how are things looking for you? Do you have any skeletons in the closet, or perhaps a few skeletons buried?
If you need any help, don't hesitate to contact nyfiken@sqlsystems.se!
