Interested in connecting a lot of (old) machines to the cloud and making the data more accessible? Read on and we will tell you how this can easily be done in a fast yet flexible and future-proof way with Digital Twin contracts.
What is brown-field connectivity?
The term brown-field connectivity refers to the challenges in connecting already installed and running equipment to the cloud. Many of the benefits that can be gained from IIoT will be realized in already running factories and sites. So even if there are new factories being setup with IIoT systems in place from the beginning, the majority of IIoT projects involves connecting legacy machines too.
What specific challenges exist?
One of the greatest challenges when connecting a heterogeneous factory floor to the cloud is to structure and harmonize the data. What that means is that even though the machines on the floor might look very different, you still want to extract and aggregate pretty much the same information from them. This so you can make more high-level decisions, share data across the organization and take actions based on a bigger picture than a single machine, manufacturing line or factory.
Then there is also the problem of connecting machines that might not have a control system or PLC that can communicate with the data-collection service in a standardized way. To extract information from them you will have to use proprietary protocols, software, and hardware.
Why existing solutions do not match up with using Digital Twin contracts
Existing solutions require you to make early decisions on how to parse, calculate and structure the data. This is one of the biggest obstacles trying to get going with large-scale data collection projects. There is simply not enough information at that early stage in such projects to make those decisions. Instead of collecting data, long discussions and hours are put into trying to decide what data to extract and find structures that will have to be changed later.
Other problems with simple structures?
Even in cases where you can agree on the data structure, other problems may arise. The structure that is correct for one use case may not be correct for others and the problems start again. Therefore, data should be kept in a raw format as far as possible in the data collection phase. This so information is not lost, and the data can be converted to the needs of the specific use cases when they are better defined.
Also, the data collected might be needed in the transformation of the existing local production system and that adds yet another use case that must be handled.
So how should one go about this then?
Our approach to data collection is to get going fast. Start collecting data by defining a structure that is only defined to support the collection of the data – not the usage and handling. This means that the structure should resemble the physical setup of the process from which the data is to be collected. The data is then stored in a non-structured way but with full traceability so that it can be structured later.
How can data be structured afterwards?
To be able to create structures that can use already collected data we introduce Digital Twin Contracts™. A Digital Twin Contract is a set of required properties that a specific unit in the system must provide the values for – in order to be considered as a supporter of the contract. How the different parts of your system fulfill these contracts is totally flexible and can be changed over time.
The system can contain many Digital Twin Contracts that serve different purposes and use cases. The same data signals can also be used to fulfill many different Digital Twin Contracts. This provides complete flexibility while keeping things simple and solves one problem at a time.
To create actual structures of data, contracts can be organized in hierarchies.
Sounds complicated? Well, it is not – so let us look at a very simple example next.
A simple example
Let us say you want to measure the quality of the production. We then define the quality as the number of good parts divided with the total number of produced units.
To be able to calculate and visualize the quality of any part of our system we define the Digital Twin Contract “Quality”. The “Quality” contract requires two properties Good Parts Count and Total Parts Count.
For different parts of the system, we can now fulfill this contract even if the data available is a little different. For Machine-1 we have the correct values we need, for Machine-2 only Bad Parts Count and Good Parts count is available.
Digital Twin Contract “Quality” fulfillment for Machine 1
| Contract property | Machine data signal |
| Good Parts Count | Good Parts Count |
| Total Parts Count | Total Parts Count |
Digital Twin Contract “Quality” fulfillment for Machine 2
| Contract property | Machine data signal |
| Good Parts Count | Good Parts Count |
| Total Parts Count | Good Parts Count + Bad Parts Count |
Simple as that! Now we can treat the machines similar when creating the OEE and Quality visualization or extracting the information from APIs to other systems.
What is the next step?
With the introduction of Digital Twin Contracts, you can separate the problem of connecting to the data from the problem of how to structure it for different use cases. By doing this you can get going faster while still staying flexible to be able to solve future problems easily.
So what is next is just starting to collect the data. For the data structuring problems to come – Digital Twin Contract are here to save the day!
Do you want to get your machines connected or have questions about IIoT? Please contact Us!
