← Back to blog

Why You Need a Graph to Power Your Digital Twin

The real world, and therefore real world data and associated relationships, are inherently “graphy”. By “graphy” I mean that in addition to having attributes and associated values, various data elements are interrelated in complex webs of relationships based on various contexts. For example, a person may have attributes like name, age, address, etc. and may be part of multiple, potentially overlapping sets of relationships in different contexts such as family, work, hobby, sports team, neighborhood, etc. Indeed, it is the very diverse and complex nature of the relationships between different data entities that lends credibility to my assertion.

While traditionally we may have thought of data in tabular form (relational database style), the reality is that even then we were also often concerned not only with rows and columns of the tables but relationships between tables and between rows and columns of different tables. The graph of relationships is there whether we explicitly recognize it or not.

Figure 1 - Tabular data and implied relationships

If the questions being asked match the table structure (or schema) then the analysis effort can be relatively straightforward. More typically, to draw insights data analysts must join the tabular data from disparate sources and perform quite complicated maneuvers to be able to arrive at the answers they seek. Their ability to easily answer questions based on the data is adversely impacted by the, necessarily up-front, table design. My point is not that one cannot get the answer without graphs but rather about the extent to which one must go from a query design (not to mention debugging) perspective, about the ease of adaptation to new queries, and about computational efficiency. An approach that is flexible, can readily incorporate new data and new relationships, and easily support a wider range of questions is desirable. The use of knowledge graphs to model the relationships is such an approach. Its properties and attractions are well documented and I will not go into them here. Suffice to say, knowledge graphs mimic real world data relationships and support advanced analytics requirements.

We see this new graphy reality showing up in vendors’ approach to analytics, including digital twins, with the adoption of graph databases like Neo4j and the adoption of knowledge graphs. For example, AWS and Microsoft both incorporate a graph-based approach in their digital twin offerings (I added the emphasis):

  • AWS in its description of its IoT TwinMaker features states “You then connect these entities to your various data stores to form a digital twin graph, which is a knowledge graph that structures and organizes information about the digital twin for easier access and understanding.”
  • Microsoft in describing Azure Digital Twins states “Azure Digital Twins is a platform as a service (PaaS) offering that enables the creation of twin graphs based on digital models of entire environments…”.

While it’s great to see graph approaches becoming more mainstream, building (and maintaining) effective digital twin data models, like many worthwhile endeavors, is no walk in the park. Enterprise data is complicated, industrial enterprise data even more so. The dynamic nature (as a result of evolutions in the deployed plant and in corporate structure (due to mergers and acquisitions, etc.)) requires considerable effort to be spent in keeping the data world in order. Two of the three key challenges faced in building digital twins (the third one being visualization) relate to establishing and maintaining the underlying knowledge graphs:

  • Using data from disparate sources: A meaningful twin of say, an asset, may need to incorporate data from a multitude of sources, for example maintenance, production, environment, etc. The data from these sources will span different formats, protocols and have differing update frequencies. Yet the graph needs to tie them together in a coherent, contextualized manner to power the analytics. Difficulty in achieving this lengthens time to insight and results in lost opportunities.
  • Modeling the real world entities over time: Not surprisingly, the real world is dynamic with changes resulting from mergers and acquisitions, upgrades, maintenance, reorganizations, regulation, etc. An effective twin requires the graph to be a “correct” or useful representation over time and be able to reflect changes in a timely fashion. Difficulties in achieving this lead to drift which at best render the twin somewhat unreliable and at worst can result in poor analytics and undesirable business outcomes.

Unify Graph brings a knowledge graph approach to bear for mapping the complex data environments typical at most enterprises that data teams must operate across. It allows flexible data modeling spanning arbitrary dimensions such as processes, assets, organizations, etc. necessary for quickly building effective digital twins. With Unify Graph Element customers can more easily adopt a “think big, start small, scale fast” approach by starting small and flexibly and incrementally adding more as their needs call for, building upon existing work. The graphs can be queried and explored within Unify or exported for consumption by graph database products such as AWS Neptune or Neo4j. I cover Unify Graph in a little more detail in a separate post.

Already curious about Element Unify’s graph chops to help you with building digital twins? Reach out for a discussion.

Want to Learn More?

Register to view a live demo of Unify or sign up for a free trial to use the software for 30 days. You can also purchase a Personal License from the AWS Marketplace or Azure Marketplace.

Questions? Please contact us.