Digital Twins - Behave!

Digital twins’ behaviour is all about data interactions

In my previous two posts, I’ve put forward a case that Digital Twins can be FAIR and enable algorithms to be built that use that FAIR-ness to find them and allow their data to interact for new purposes.?

Just to re-cap (VO: “Previously on this channel…”). Being “FAIR” means that you abide by the FAIR principles as set out by Go-FAIR.org. In short, they set out steps to make your data Findable, Accessible, Interoperable and Reusable.?

The brave new world I propose assumes that Digital Twins are the virtualisation of a real asset’s metadata, static data and streaming data. Metadata and static data are relatively self-explanatory. Metadata is data about the data you can hold about an asset: does it have a location; a manufacturer; a start-of-service date? The static data answers the questions in the previous sentence: Where is it? In Bristol, Clifton to be precise. Who made it? Isambard Kingdom Brunel. When was it opened? 1864.?

Streaming data can also be described with metadata. Does it have a Loading weight? If so, is it measured in metric or imperial tons? Does it have a temperature - measured in Celsius? Then the streaming data answers these questions every time the asset cares to report them. Now: I have 250 tonnes of load, temperature 15°C and now, 5 minutes later, I’m 180 tonnes and 14.8°C, etc.

End of recap. The continuation of my argument is this: As digital twins are built around the data of an asset, digital twins can be made FAIR and, by implication, so can their streaming data and their behaviours as these are intrinsic components of a digital twin. Allow me to elaborate...

The paragraph before last implies something. “Every time the asset cares to report them” implies that the asset is “saying” something. Well, last time I visited the Clifton Suspension Bridge, it wasn’t that chatty but, given a few sensors, it could know loading and temperature and “care to report them” on occasion. For the sake of my example, let’s assume that the loading sensor and the temperature sensor are owned and operated by separate organisations and report their data into separate databases.

Now we have some static (meta)data about the bridge and some dynamic data about the current status of the bridge in at least three different places. What’s going to bring them together and make a single, virtual version of the Clifton Suspension Bridge? The twin’s behaviour, of course. This is the simplest behaviour of a twin: interact with the real world’s and synchronise the virtual world’s view, i.e.

1. Register the existence of the asset
2. Describe it with metadata
3. Update the status of the asset at a regular interval (or on an event)

In the spirit of the Emily Dickenson poem 1 and 2 alone will do, if the current status of the bridge isn’t that important as Miranda Sharp suggests, but that only requires registering the existence of the twin somewhere where people would look. How about DBpedia, the little-known semantic database backend to Wikipedia??

But, for the sake of my argument, let’s say I do want the real-time data of the bridge and I don’t want to register it in DBpedia, because it’s not the actual Clifton Suspension Bridge, rather it’s my virtual version of it. (I could register my virtual bridge somewhere and link it to the real one using linked data, but that sounds like the topic for another post). For the real-time data to flow, something has to do something, at least occasionally. That something is the twin’s behaviour and that behaviour is adding a lot of value by bringing the disparate sources of data together in one point - the twin.

Now we come to the conversation with Andy Seaborne. He explained to me that you could either give someone some code (as a library, say) and expect them to run it themselves or you could make an API that gives access to the code and runs it for them. The digital twin’s behaviour is also doing the same thing (running some code) but it would likely give access to it by publishing - like it was on social media. No matter, we’ve just made behaviour discoverable and accessible.

Now we’ve got one behaviour, can we find some others? Perhaps another twin could “listen” to the Clifton Suspension Bridge and interact with other bridges in the area to use their loading data (and its change over time) as a poor man’s traffic sensor. That’s data re-use for you. In a similar vein, modern cars, with their temperature sensors and automatic wipers, would make excellent weather stations if only they could share their data. Far fetched? Think how Google Maps works out where the traffic congestion is...

Wait, what? (SFX car reversing). Did you just say, a paragraph or two ago: “we’ve just made behaviour discoverable and accessible”? Well yes, I think so. The behaviour of that twin was scurrying around, finding useful information about the Clifton Suspension Bridge from wherever it was hidden stored and sharing it through (and with) the context of the twin. I’ve said in a previous post that digital twins can be FAIR (Findable, Accessible, Interoperable, Reusable), so if the twin is FAIR and the twin has this behaviour, then the behaviour is FAIR, QED.? I think this also answers Andrew Padilla’s question about FAIR-ifying the algorithm that creates the data.

What about more complex behaviours? AI & ML? Well, why not? They are, after all, just behaviours which are, erm… more complex. If an AI/ML could search for things that were of interest and then understand and include their data, autonomously, into its algorithm(s), wouldn’t that be a behaviour? Aren’t algorithms just sophisticated interactions of data? I suggested in this post that algorithms could be twins and they could share their output in the form of more twins to increase the network effect of the digital twin ecosystem. Or they could have a twin of themselves and share a feed of their predictions.

There’s one behaviour we haven’t considered yet: Human behaviour. In particular, altruism. Similar to Peter Whale’s “So what?” question in the comments of my previous post, there’s the “Why bother?” question. Why should I bother to write a behaviour that makes finding data easier for others? Why can’t they find out the loading of the Clifton Suspension Bridge themselves? I can… The answer is similar to the behaviour in Open Source Software. Why should I make my code available? Why should I contribute to this project? The answer is that the world is run on enlightened self-interest. I might download Drupal, for example, and get a fully-functioning Digital Experience Platform for free. That wouldn’t be possible if others hadn’t contributed their time and energy. So I contribute mine, get kudos from others and achieve my selfish ambitions. Win-win.

This last answer might sound like the future is only for Open Data and behaviours, but it can also work in the commercial world. Value chains linking producers, suppliers, manufacturers, customers, and maintainers work cooperatively. Autonomous enterprises, with their own goals, missions and shareholders, agree to work together because it benefits each of them individually. Rolls-Royce Defence say they have 11,000 suppliers. Some of these collaborate; some compete but all could and should cooperate to increase the overall value of their products, services and companies. This cooperative behaviour already happens at a human level: from boardrooms to bars. What I propose is that technology should mirror (or twin?) this behaviour.?

“Sensors as a service” is one business model. Recoup the cost of installing your sensors by selling their data. That’s a bit direct A-to-B I-pay-you-for-a-service. How about a more cooperative example once suggested to me: if? a train runs along infrastructure operated by another company and measures track vibration and spikes in the electricity supply, don’t you think that infrastructure company would be interested in knowing that rather than sending an expensive sensor train down the same tracks at 3am??

The value added by FAIR Digital Twins, their behaviours and their data interactions acting as a new currency...