Digital Twin Use Case: Visualisation Twin
Read time: ~7min
The Visualisation Twin is a type of spatial digital twin that presents contextual, near real time, cross functional data to users.
Visualisation Twins are often seen as “the” digital twin of a site, and are frequently associated with high fideilty spatial data such as 3D models, LIDAR, and photogrammetry. In this short summary, we present some of the key elements of a Visualisation Twin and provide advice on creating a valuable and viable Visualisation Twin in your organisation.
What Problem does it solve?
Visualisation Twins are often “technology led” solutions that are not strongly connected to specific problems in the real world. The focus on creation and use of high fidelity spatial data sets can obscure the real world problems that such a solution can help with. This doesn’t mean a technology led twin is not valuable; rather that the probability of the solution being viable (meeting a business need and providing a measurable benefit at a sufficiently low risk and high ROI) is lower, because without a clear Problem to be solved, it’s difficult to articulate the Benefit, and hence the Return on Investment is difficult to quantify.
Advice: Visualisation Twins absolutely need focus on Problem statements and validation of Who the early users of the solution will be, and Why. A “good” Visualisation Twin will be extensible, and may anchor many future connected Capabilities and provide value to multiple situations, but early lack of adoption can place a Visualisation Twin in the “shiny thing” category.
Here’s an example:
Problem / User / Benefit
Problem: Siloed data enables siloed behaviour, which reduces total productivity and creates higher risks.
User: Everyone in a silo? That’s everyone…
Benefit: Siloed users can see data from other silos.
Here’s a better example.
Problem / User / Benefit
Problem: Everyone's view of what Work is happening on site is siloed, and sharing that information is time consuming and mostly verbal. When conditions change, the radio and the mobile phone are the means for communicating the situation and the need. As a result, we often don’t adapt to changing conditions - we just ride out the plan, or stop the planned work, because adapting takes too long and can’t be rushed.
User: Superintendents who manage execution works (maintenance, shutdowns, projects).
Benefit: Giving Superintendents a shared and contextual view of all work planned and occurring, and the ability to filter/search on other peoples’ work, creates high, shared situation awareness that enables rapid and safe re-prioritisation as conditions change or emergent work is identified.
By narrowing down to a specific problem for a specific group of users, and using specific examples, we can then work backwards to benefits that can be validated with users. If the Benefit isn’t valuable to the user, then it’s unlikely to be valuable to the business. The path from user benefit to business driver may not be linear, but following the path and agreeing how outputs create outcomes, and how we measure one or both, provides the best possible chance of creating valuable and viable solutions.
Problem Category
An alternate way to approach is to consider what “category” of problem does the solution best serve? Digital twins are considered a category of software, but in reality the digital twin must (by definition) encompass the physical reality and the digital capability. As such, there are specific categories of problems that digital twins are highly suited to solving. For a Visualisation Twin, we can consider the types of data, or the types of problems. Types of “visual” data include 3d models, GIS data and real time location. Types of problems that require “better” visualisation include situation awareness problems where near real time context is critical, planning problems that cross time and space, and problems where the addition of specific static or time series data to visual contexts enables better shared comprehension.
In many cases, high visual context is most beneficial where shared mental models are required. If the problem requires multiple users, from different silos or roles, to extract multiple data points from multiple systems, in order to agree on the “situation”, then in all likelihood each user will assemble the data in a slightly (or very) different way, and extensive time will be devoted to agreeing which model is “right”. Worse still, if the agreement phase is bypassed, then each user will project their own individual mental model of the situation forward in time as part of their decision making process. When each user “sees” a different situation, and acts accordingly, we get “siloed” outcomes.
Advice: Starting with solutions and working backwards to problems is not an ideal way to justify new technology, but it is a good sense check, and the process can reveal surprising solution/problem couplings. Re-using validated and connected data to solve adjacent problems is also a way of increasing the value of data, with low incremental cost - the twin is already built, adding UI or an additional data source to solve an additional problem, without any further infrastructure investments, can provide very high and rapid ROI.
Capabilities
Generic
A generic Visualisation Twin may seek to use all the visual data that is available to a site, in order to create the best possible conditions for that data to be used and provide benefits. In this case, a key capability selection is the visualisation engine. Being able to visualise, in near real time (or with sufficiently low latency), very large data sets or spatial models, especially if real time location or animation/simulation is involved, requires significant memory and visualisation technology. Be aware that if the use case involves critical edge requirements or redundancies (especially if its production or safety critical), that many traditional visualisation tools will struggle to meet the performance and security requirements, especially if significant pipelines up and down to the cloud are required. Many 3D models, in particular those created during BIM driven capital projects, may have extensive levels of detail (e.g. bolts, grating details etc) that are not required for the digital twin use case and are extremely large. Performance of the solution needs to be tested with users, as very slow loads or unresponsive screens will likely lead to lack of adoption and initiative failure.
For maximum extensibility of future visualisation use cases, a game engine solution such as Unity, Unreal Engine or Nvidia Omniverse could be considered. There are pros and cons to all 3, and specific limitations around data pipelines and browser capabilities. All 3 have multiple live industrial digital twin use cases, and all 3 are paired with multiple off the shelf components to enable these use cases.
If considered the over arching “twin” of the site, an underlying asset graph can enable multiple asset based use cases for visualisation. A good example of an asset twin platform as a service (PaaS) is Azure Digital Twin (ADT). ADT is very mature and Azure has a strong ecosystem to support multiple data types and many connectors and support services. We usually recommend an underlying graph for most use cases, as so many use cases touch on or benefit from knowledge of the relationships between physical assets. The knowledge graph can provide an excellent “skeleton” to hang other capabilities off, and there are increasing levels of awareness around the benefits of graphs to large data sets, or in the cases of twins, adjacent use cases.
Targeted
A targeted solution that seeks to solve a specific problem, e.g. the work visualisation twin example provided above, should align the capability stack to the specific user requirements, which in turn drive the data required, and the capabilities to be built. A targeted solution may not be “narrower” than a generic, in that there may be just as many system to be connected, but fidelity and frequency play a part here; lower fidelity data, collected less often (e.g. batched), may satisfy the use case requirements, and be very significantly lower cost and complexity.
Advice: For some use cases, a targeted approach can also be used as a pilot approach: validate the use case as cheaply and quickly as possible, and get user feedback and buy in from operational use in the field, before scaling the solution. Front End Loading applies even more to innovative solutions than large projects, and the best validation is to create and measure value. Piloting on targeted use cases also serves to test viability assumptions - what’s the real cost and effort (direct, indirect and change management) to create this value?
Conclusion
A Visualisation Twin is a very common starting point and desire for any innovation or technology team that has a mandate to create enhanced situation awareness. We highly recommend partnering with field functions (such as the maintenance/work example above) to ideate and design use cases that solve particular problems, before embarking on Build v Buy exercises. Clear problem framing and validation are essential when considering very wide digital twin use cases such as Visualisation, and discovering adjacent use cases with siloed teams can lead to surprising cross functional opportunities and also provide insights into technology capabilities that may be required. “Wide” use cases also benefit from pilot type approaches, not necessarily to prove the technology, but to exercise the muscles of user buy in and value measurement before widening the scope.
If you are looking for help with the design and implementation of digital twins, or for more information on potential use cases of digital twins and AI, reach out to the team to see how we can help.