Last summer, during the ARC Industry Forum 2022, Michael Hotaling of ExxonMobil shared a great talk on digital twin sustainment, from the standpoint of an industrial Owner Operator. The 20min talk is well worth listening to, as it is packed with much hard-learned facts:
1:30 ‘From an O&M standpoint, we were a little sleepy in terms of catching up”
As highlighted in our Overkill BIM post, most operators, particularly in the AEC industry, believed that applying the same approach as the EPCs could also serve the operation & maintenance use cases. That is simply not possible if only because of different timescales: decades of operations and people/organizations turnover take their toll.
2:20 “we’ve seen solutions looking for a problem”
At Samp, we are a few industry veterans, and are proud to say that the inception of our company and solution stems from the will to solve in a scalable manner a universal problem plaguing our industry: the ever-widening gap between technical data and the REAL state of industrial assets, and all of its consequences, which can be tragic.
2:50 “there’s a lot of input about the work that’s going on about greenfield capital projects”
True, and this is not a surprise: EPCs create (and sometimes re-use) all the engineering data, which can then populate a digital twin. As said above, a greenfield project will last for a few years at most, with some of the key personnel stable from A to Z.
All of this is the exact opposite of O&M: engineering data is partial/outdated and staff careers shorter than the decades-old sites lifespan.
3:10 “how do operators actually keep digital assets moving forward?”
The main focus of O&M teams is day-to-day operations, not engineering nor IT. From day 1 after the initial plant handover, as operators rarely have quality information nor efficient ways to find it, how could one expect them so sustain a Digital Twin? Until now, it was mission impossible for understandable reasons.
4:05 “we have somewhere between 80 & 90 use cases”
A Digital Twin is designed to serve Use Cases, not the other way around. This is stating the obvious, but solution vendors should not forget it, otherwise we may become victim of the law of the instrument, aka “If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail”.
4:15 “I didn’t hear a single thing about the efforts or organization to sustain this”
Until now, time was not ripe for that, no-one cracked this nut. It was so hard to establish a static Digital Twin, that no one thought about the next step, sustaining it. Yet some owner operators are now emerging from the “trough of disillusionment”, and some of our clients who experience the “slope of enlightenment” will be glad to share their experience (hint: testimonies are on our website homepage).
It is great that you collectively wrote a white paper on the “sustainment of 3D models”, is it publicly available?
6:40 “Instead of asking me to maintain these 2D drawings we have the same or even better information in a 3D image of those activities”
This is absolutely true, and we experience this with information such as ATEX zones or asbestos sampling points. Our clients are compliant and maintain this information in drawings or tabular form. Yet such type of records is difficult to share, and even more to understand by people not already familiar with the site. Projecting this information – from its existing system of record – into the 3D changes the game and is an excellent educational material for the regulatory authorities to help them accept new ways of working!

7:20 “I really try to avoid the word Digital Twin”
How much we understand that! So many promises that failed to materialize… So many operators were left on the side of the road. The concept increasingly sounded negative these last few years. However that may progressively evolve, as most have learned the hard lessons, and realize that a re-birth of Digital Twin is necessary.
8:00 “It’s only a dumb picture until you interlace it with data”
Precisely, and this is the very core of what we do at Samp. We infuse the essence of process plants design intelligence, ie Piping & Instrumentation Diagrams, into 3D. And we chose to rely on 3D coming from the field through reality capture. We build the missing link between the technical data stack (which may include theoretical CAD 3D), and the reality of the field. Our keystone is the equipment tag number, fetched from P&IDs.
8:50 “Allow open architecture”
We humbly believe in this open architecture approach. Why? As we can’t do everything well, we focus on our core capabilities, then ensure that Samp can be part of a larger pre-existing and evolving architecture. No heavy migration: boosting existing systems of records, this is the way to go.
9:00 “Separate hardware from software”
Hundred percent! We need to be agnostic of the reality capture device. Terrestrial Laser Scanner, Mobile Laser Scanners, LiDAR, photogrammetry or videogrammetry from smartphones, tablets, wearables, walking or flying drones, no matter how! What we focus on is to infuse process engineering intelligence into the 3D field data.
9:05 “Separate software from data”
Here again, we made our choices at Samp, and only rely on standard data formats as input. Which sometimes may be annoying for some customers who are still stuck in a vendor lock-in. This will evolve, and we are happy to nudge clients in this direction a little more.
10:00 “Sustainable use cases of Digital Twin are mostly singular”
Repeatability of deployments and concurrent use of the digital twin are key. At Samp we have bet on a short “time-to-experience” approach, where first results are available in days, where end-users see value in their day-to-day job across a variety of organizations, and where they improve data quality day after day.
Be it permanent staff or contractors, the Digital Twin cannot be restricted to specialists to deliver value at scale.
11:20 “I want to get realtime”
As soon as reality capture and process engineering data (namely, tag numbers & line IDs) are reconciled, it becomes easy to connect to realtime data sources, such as data historians, hypervision or online simulation. Combined with a field-exact representation of systems, they provide an unmatched context for robust decision-making.
11:50 “Get information by interacting with it”
Another strong decision we made at Samp was to empower field users to update the Digital Twin themselves, without the burden of a long chain of command which is the cause of the widening gap between as-built and as-documented.
Field users will trust the Digital Twin because it is updated by the field, for the field (and beyond!), using their existing devices whatever they are. Field operators become the wazers of the Digital Twin, they use it and update it!
12:50 “Chasing down the red lines & black lines of P&ID is a constant battle in terms of making sure that we stay connected”
How much time our industry heroes spent on that one! We decided to cut this short. We made the choice to rely on open intelligent DEXPI P&ID to cut the suffering of our heroes. DEXPI has the advantage of being vendor-neutral. It is nice to humans, allows them to easily follow a line across folios, to check equipment isolation sequences like a breeze.
DEXPI is also nice to machines, because it is machine-readable! This opens the door to system simulation from the P&ID, and to our patented equipment recognition AI, which helps populate the 3D reality capture with equipment tags from the P&ID. Nice!
Beyond that, and leveraging DEXPI, we have big ambitions to reverse-engineer a fully simulable twin from the sole 3D capture in the not-so-distant future.
13:00 “We will find a way to use a 3D visualization of an asset to improve upon that process”
Yes indeed, and this is exactly what drove the creation of Samp: the meeting of Laurent who experienced the pains of our industry for 2 decades (and sadly, witnessed a tragic industrial accident caused by an outdated engineering document), and Shivani a Machine Learning expert who wanted to solve a societal problem at scale.
The result: a web solution where reality capture meets with process engineering, and acts as a gateway to continuous data cleansing and update, while giving systems of records a new lease on life!
13:50 “The fidelity of the model or frequency of the updates matters”
A lot, and lots of people lost faith in Digital Twins because they were too theoretical and NEVER in sync with the reality of the field. This is why Samp chose to put field 3D first – “field 3D is eating CAD 3D models” –, and to develop a continuous update capability, where end-users can updload their own scans or pictures/video of the work they just completed, in order to have a super-short update cycle. “By the field, for the field” (and beyond!)
14:00 “I want to know the torquing specs on a bolt”

Current reality capture gets to bolt-level. By visually querying existing systems of record with the tag number of the parent equipment through Samp, the operator will get just anything from the ERP/EAM/CMMS/APM or any other system in one click. Accessing a location visually is the rosetta stone to all other systems. Conversely, any specialist using a system of record can access the visual context of a specific equipment / weld / inspection point in Samp.
14:30 “The challenge that we have is to be able to scale”
This is why we have designed a scalable approach at Samp from day one, which may sound very narrow, but is precisely aimed at enabling scalability. We only focus on closing the gap between digital twin and the field reality, and on keeping it closed day after day! We removed unnecessary intermediaries and empower end-users to publish information directly from the field.
15:00 ‘Capital projects thank you very much, we will own it and we will take it forward’
For sure the operator’s Digital Twin is too critical to be left in the hands of a third party. Yet it was so complex until now that very few operators dared or succeeded to own and maintain it. Those who tried learned the lesson the hard way, and now know exactly what they want and don’t want.
15:20 “we intend to be agnostic in terms of how the imagery gets developed”
This is our case at Samp: we only focus on 3D point clouds, no matter how they were captured or generated: via a LiDAR or camera onboard a smartphone, tablet, flying/walking/rolling drone etc.
Of course, we can also host 3D from CAD systems as “virtual point clouds” for clients who don’t want to start from the blank page or need to display non-scannable areas such as buried networks. In such case, it is interesting to see how engineering models are progressively cannibalized by point clouds coming from the field, which progressively replaces theoretical or missing 3D.

16:30 “today in our plants we have people who are superhumans with a radio”
We love these real-world superhumans, and do not underestimate how they can power digital twins from the field. Their amazing skills just need to be leveraged. This is why we also built our solution for them in the first place. So that they become the trusted party keeping track of the facilities evolution like no-one else can: from the field, for the field.
16:50 “why can’t all that be rendered in a 3D model to give accurate up-to-date information”
It can. This is the name of the game: accurate + up-to-date!
Some unorthodox thinking was needed to get there though.
17:00 “you may get to the point that all you need to have to get a scan is your phone”
Absolutely. Beyond that, even for those who do not have a LiDAR on their field tablet or smartphone (ATEX-compliance does not help), a smartphone camera taking a few pictures or a short video around an area of interest after a modification will be enough to regenerate a local point cloud that will update the global scene.

17:20 “this is about taking cost out of business, this is not technology for technology’s sake”
Our thinking for our web solution is not about stacking yet another platform on top of the others, or about forcing the replacement of existing software by a new one. It is not about creating yet another set of custom data. This is about enabling the missing link between the existing systems of records, existing teams, and the field reality. This allows to extract the full value from existing human and technical investments.
17:40 “When you start enabling reuse of images in a centralized storage, you’re integrating it with data”
Sure, what a waste to have so much single-use reality capture that sits unused on servers after a specific project, rather than enriching it with data & semantic so as to share it with all teams. Some even went as far as comparing single-use spatial information to single use plastics: not the best use of such high added-value product.
17:50 “Integrating data with assets is a very very costly activity”
It is very costly because until now it was mostly a service activity: the more data needs to be associated, the more service is needed. Not only initially, but also on a continuous basis, to keep the association up to date.
Yet, with a software-based approach, what was previously very costly becomes scalable, with short cycle times. At least for core process equipment & systems, which represent the most sensitive assets from a safety and revenue standpoint. The keystone semantic object we rely upon at Samp is the equipment tag number or line identifier, extracted from the P&ID. For sure, it may differ from the identifier used in other systems, in which case we will rely on an existing (external) master tag registry to be able to query any system of record from Samp, without hosting duplicate data in Samp.

18:00 “this is not a place where I can afford to have 25 different variations of 3D models”
How much suffering around 3D models variations, LoDs, standards and viewers. At Samp we made a blunt decision, which is to solely rely on widely available 3D reality capture standards (georeferenced e57) as an input, which will be the sole source of 3D for our web solution.
The original 3D files can remain with our clients’ systems of record, we’ll just process them automatically to ensure they can be streamed and processed by our AI. This does not prevent querying 3D CAD representations of the same object from the engineering system for comparison, but in real life, most of our clients do not have any 3D at all.
18:20 “today, 3D images in terms of operations & sustainability is a cost-plus proposition”
And this is the reason why it does not work and will not work with the current way of thinking. The very reason why we wrote our initial “Overkill BIM” paper is because we wanted to share our view after many interviews with operators and service companies who all tried and failed to maintain 3D models in operations.
18:40 “you thought you were paying people to maintain P&IDs, inspections isos, now you just need to pay somebody else to maintain your 3D model”
Attending the “2022 BIM World” trade show this year just confirmed 100% this conclusion. No-one will pay for long another layer of people dedicated to manually maintaining a 3D model, even less so when it slows down the update loop from and to reality.
18:50 “That’s gonna have a short life, unless we can figure out a way in terms of using either low-cost scanning capability to integrate with that”
We believe that we have found the right approach at Samp, focusing on equipment & systems for the process industry first. What we need now is more and more data, continuous improvement of our algorithms, and hard work to progressively scale to be able to manage the largest and most dense assets in the industry, at a very acceptable marginal cost.
19:00 “At some point I’ll just stop maintaining inspection isos, P&IDs, I’d love to figure out how to do that”
Okay, let us share a secret here. What our AI creates when it parses a point cloud to understand its equipment & systems typology, is a quasi-isometric. Each line of piping is replaced by its generator line, each equipment is replaced by the symbol of its class. Rings a bell? Yes, it looks very close to an isometric drawing, from which a P&ID can be (re-)generated. Of course, we can help associate tag numbers from existing equipment lists. So in the end, we can help reverse-engineer and generate basic isometric & P&ID from 3D point clouds.

19:10 “in an open architecture”
Before Samp was created, many of us had extensive experience with ad-hoc tightly integrated proprietary architectures. We understand the limits and consequences of such architectures. This is why we decided to build our web solution entirely on open standards, and with open webservices interoperability, to avoid data migration and complex integration.
20:00 “I’m not gonna change corporate-wide every place where I have my P&IDs”
We understand that our clients had better things to do than changing all their P&ID. We transparently restore P&ID intelligence based on the DEXPI open standard so that all end-users benefit from superior value of these drawings.
It is a pity that only engineers benefit from intelligent P&ID in their proprietary CAD solutions, while 90% of staff & contractors in operations have to rely on basic PDF.
20:05 “I am going to be expecting to plug that into an open operator system”
True, interoperability is the name of the game, and ensuring that a specific solution can land in an existing ecosystem without disturbing it, is the minimum to be expected. Beyond that, such new web solution could even enhance the existing systems of records, making some of their content more easily accessible to all.
We even had several cases where our solution facilitated the upgrade of our clients’ systems of records with a newer solution, helping them ensure that the new solution was well aligned with the real state of the field.

20:20 “people that have delivered 3D models, it’s all custom built”
Because we deliver on the cloud, we use a single code for all clients. This is a critical safeguard that helps us say “no” even when a client asks for a customization.
Which does not mean that we are not listening to clients. We have a working group with our clients, meet quarterly to discuss a specific use case, and see whether a common ground exists to implement new capabilities that would be valuable for the entire market, not just for a specific client.
20:40 “Lack of standards (or so many of them that nobody follows any of them)”
This is true. We have chosen to address a narrow but universal problem, and make the best possible use of the standards around it for 3D, 2D, 1D:
- e57 for 3D point clouds, ideally with EPSG geolocation: very mature
- DEXPI/Proteus for P&ID, itself related to ISO15926: slowly gaining in popularity, although it is not in the interest of established CAD vendors
- ISO81346 as RDS for equipment hierarchy: only used in nuclear and aerospace so far, yet it is a good direction to go to. For now, we just use whatever can be extracted from CMMS/EAM, or regenerate the equipment list from P&IDs.
21:10 “from all of the projects where I currently have 3D engineered models, where I’m doing reality capture, from a standard-base, the data is not in the same format”
This is the reason why, in our narrow space, we do stick to the source reality capture file format standard (e57), and do not impose proprietary mesh overlays, which are anyway dead geometry, and create yet another representation of reality. WYSIWYC: What You See Is What You Captured, period. People on the ground trust that
Colored point clouds will soon look as good as texturized artificial mesh models. For buried networks, we leverage point clouds from radar or magnetic surveys, and can also create “virtual point clouds” (e57 too!), by “pointifying” existing 3D CAD models, or virtual pipes from 2D drawings or GIS GeoJSON.
21:30 “From a vision of having a visual way of working, it’s gonna take all of the industry to get there, it’s gonna take other fellow owners operators, and quite frankly yes all of our suppliers to be key partners in this journey”
“It takes a village to raise a child”, and the Digital Twin kid has been long awaited, with an eventful childhood!
Samp will take its part, and we are eager to work with more clients to ensure that we deliver a super lean and scalable piece of the puzzle, to ensure that physical integrity meets with information integrity. Open operable system, separating data from software is the way to go.