Digital twins in the Open

How ecosystems of digital twins solve problems that closed systems cannot.

Educational 22 Oct 2021 by Mark Wharton

“No man is an island, entire of itself; every man is a piece of the continent, a part of the main…”

…wrote John Donne in 1623 as part of his essay Meditation XVII and, while he was thinking about theological and geo-political concepts, in the intervening four centuries his words have been interpreted to mean that nothing exists in isolation. There’s no manufacturing process, utility provision or retail outlet that does or makes everything itself without any supply chain. Thomas Thwaites famously built a toaster from scratch, but even he confesses to “cheating” as he wore shoes made by someone else and took the occasional train.

Every Product is a Data Product

Satya Nadella, Chief Executive Officer (CEO) at Microsoft, said in 2019 “Every Company is Now a Software Company”. I won’t dispute this wisdom but would like to posit my own version:

“Every product is now also a data product”.

What I mean by this rephrasing is that almost everything has data about it and most probably data from it. This data is useful to two groups: the operators of the product and the manufacturers. Operators need the data to conduct their day-to-day business; manufacturers so they can see how their product functions throughout its life in real-world conditions. The fact that there are (at least) two consumers of the same data for different reasons is important – but later, not now.

Servitisation of Assets

Around 10 years ago, I was working with a traffic monitoring company that sold “black box” data-loggers that analysed the traffic flow on the edge and reported the results back to a central database. So far, so bog-standard IoT implementation. We suggested that an alternative business model might be preferable: Give the boxes away and sell people the data. Turn cap-ex into op-ex and servitise your offering. The advice fell on deaf ears.  “We sell boxes”.

The traffic monitoring encounter was disheartening, but led to some of the thinking behind what is now IOTICS. Strangely enough, in the same essay, John Donne also says:

“No man hath affliction enough that is not matured and ripened by it.”.

Servitisation of Assets for real

Rolls-Royce Power Systems (RRPS) have long had a servitistion model, pioneering what they call:  “Power by the Hour” . RRPS make diesel-electric powerpacks for rail, marine and combined-heat-and-power applications. Installed on Hitachi trains, their power systems were bristling with sensors reporting every 2 seconds and they had multiple ERP and PLM systems to store all the technical details of the units. Their original challenge was:

Make a “single pane of glass” visualisation of the diverse data about the power generators for the customer service engineers

RRPS could have chosen the standard approach: shove all the data into a data-base/lake/warehouse and point a BI tool at it. Their Technical Project Manager, Sean Gigremosa, bravely chose a different solution: Digital Twins. Their product now had a digital version but, crucially, every asset had its own digital counterpart. Not: one dataset with all the powerpacks in it, but: each powerpack has a separate, virtual entity.  At a very granular level this was “every product is also a data product”.

Digital Twin as solution to the Servitisation Problem

Sean’s bravery paid off. IOTICS built a digital twin of each of the power generation units (for the customer service engineers) with a real-time feed of engine data, including data about operating hours to roll up for billing.

RRPS, as manufacturers, were interested in the operations of their products in the real world. Their customer, Hitachi, also was interested in the operational data from the powerpacks in their trains: the two use-cases for consumers of data from above. Tellingly, Hitachi were only interested in the powerpacks that were installed on trains, not the ones for CHP or for Marine, so the granularity of the twin of only this powerpack found utility immediately.

The Open World Assumption

The Open World Assumption (OWA) is a philosophy that can be summarised as “Just because I don’t know something doesn’t mean it’s false”. In traditional database systems, if a record is not in your database, then the thing doesn’t exist, period. Ask the English Premier League: “Are there any football teams in Paris?” and they’ll say “no” because the EPL is a closed world. In the open world version, the answer would be: “I don’t know”. That turns out to be a very big difference.

A cross-enterprise, open-world mash-up IOTICS delivered was to link the geo-location data from the feed of the power generation unit (from the closed world) to the positions predicted by the planned route of the train from a Train Operating Company. With those two sources of data you can tell if the train is still doing what the daily route planners wanted. So what? Well, if the train deviates from its planned schedule, it won’t arrive at the correct maintenance depot in the evening and lots of expensive maintenance engineers and their equally expensive equipment will be unprepared to address the needs of the trains that have arrived instead. Not to mention the potential that safety-critical maintenance for the absent trains would be delayed.

What you know evolves over time

As the above example illustrates one of the tenets of the OWA is that what you know evolves over time. At the start of the day you have to assume that the train will continue as planned but the sheep on the track have other ideas…

Is there a closed-world solution to the problem of knowing which assets are on which trains when one party owns the powerpack and another owns the train? “What train is my powerpack on? – I don’t know” doesn’t sound like a good place to start but, in the open world someone might know – and it turns out somebody does, by a circuitous route. The locations of the powerpacks could be cross-referenced with location of the trains they were supposed to be on. Three or five powerpacks all within a small radius of the train and moving together? Great. Four powerpacks moving and the fifth suspiciously static in a location close to a maintenance depot? That’s not on the train, then, is it? This is a problem not solvable within the closed world and shows that you can solve problems in an evolutionary, heuristic way.

Other open-world use cases

Other open-world use cases followed. Link the train position and running status with pollen count data from the EU. So that you know if the engine was running in areas of high pollen as pollen clogs the air filters but only if the engine is running and drawing air through the filters.

We keep finding open-world use cases in other sectors. In utilities: link open rainfall data with private data on sewer levels and their flow to predict sewage overflows. In supply chain: a batch of vaccine is passed from the manufacturer to the shipping company to the healthcare provider to the delivery centre to the recipient, but the data about the batch of vaccines stays in each of the parties’ separate silos.

Falling down the cracks

The open-world use cases have a defining feature for me. I call them use cases that “fall down the cracks”. Here’s another example to illustrate this feature. Car manufacturers make cars that dealerships sell to customers. These cars break down and are rescued by the breakdown services and perhaps have an impact on the police and highway agency. Think of that in the “every product is also a data product” way. The car has data (position and operations), the dealership has data (maintenance schedule), the customer has data (ownership, billing), the breakdown service has data… You get the idea. Here’s my question. Where do you put this data? Not one of the organisations owns all of it. It’s fallen down the cracks between the companies involved proving that it’s not a closed world, it’s an open one, solvable using open-world solutions like digital twin ecosystems.

Here’s a picture of a graph of a social network. What do we notice? There are islands of tightly-connected things with loose connections to other islands. This is the same shape as the open-world problem space. Imagine the blue blobs are cars in the previous example; the red: customers, the green: breakdown services. There is no one place to put the data, it’s held collectively in the graph and shared when it needs to be. There’s no closed-world solution to this problem. Wrapping your arms around your data won’t protect it or you, it will isolate you from the opportunities that come from opening out to the world.


Join Our Community

We enable the world’s data to interact safely and securely with other data, of all types, in all places, dynamically.