Tag Mapping or Model Mapping

Take the example of a Pump Monitoring App.

In a pump monitoring App - you need to understand the physics of how a pump behaves, and to have access to some real process measurements to understand if these measurements show a problem.

In the past - a developer would build a pump monitoring app - and upon startup with knowledge of the physics - it would do nothing. The App did nothing as it still required a link to the process measurements.

This is where a piece of work (the first problem) would be kicked off to dig through Engineering Diagrams (P&IDs) to find the instrument tags that we should be measuring.

Often the measurements available were not the same measurements that the pump app was designed to use (the second problem) - and a piece of work would be kicked off to model the measurements the pump app was designed to use so that it could perform its original function.

A while later, some vendors came along with an idea that would solve the first problem (finding all these tags)...

The solution was to have a common database of all equipment and all tags that every app could refer to. with this in place, the Apps could simply refer to this database and there would be no need to go through the P&IDs and do all the mapping (right?).

Here is where the first problem has been made worse by current systems. Consider the effort to configure a single App - finding say 7 tags in the Engineering Diagrams, and typing them into the app. Whilst this would seem to be the bottleneck to covering your entire business with the App - it pails in comparison to the effort required to categorise every single tag in every single site, from each and every App's perspective.

Nonetheless many Oil companies are going down this route, Statoil for example advertise heavily their central common repository of equipment that is built to standards, and each app they build can use. Seems perfect, right? - within a closed system where you control all the developers and you have serious funds, this has merit - however, we all live in an open system. No matter how much budget you have, you can always do more by being able to take things from the market. So in a place where you have your own standard data model, how do you take things from the market, that cannot rely on this model (as each one is different for each client)? This is where the first problem just became bigger.

You have to start mapping models , not just tags. So your vendor has one view of the standard for equipment that is likely totally centered around what their app does. The client has a view centered around the whole plant. in order to map one to the other, the engineer has to first identify direct mappings (Pump Inlet temperature = Pump Inlet Temperature), then it gets hard.... "wait a minute, there is no Pump Inlet Pressure reading in our model..." now to get the mapping for the pump app, not only do they have to identify it in the Engineering diagrams, and enter it into the common database, they also have to map the database to their app, what was once one problem is now three. The other problem is that depending on what you are doing with the variable, you may infer it differently - if you are reporting on production daily for accounting, then a daily reading is fine, if you are looking for instability on production then you require a much more frequent reading. For this reason identifying the variables in a model can actually cause problems down the line - anyone doing mapping like this with an engineering model would insist on viewing the P&IDs to see the layout of the process and where the instruments are relative to equipment (a pressure reading which is meters below the pump will read differently to one that is centimeters below the pump).

In our office, we call this a wallpaper problem. If you have ever wallpapered a room - one problem can drive you nuts. You paste the paper, and leave it to soak so that the paper will expand as it absorbs the liquid. If you don't leave the paper long enough to soak, then it will expand on the wall - and this causes bubbles. So what happens when you put paper on the wall and the bubbles appear? The first thing you try is to press them into the wall, taking a dry pasting brush you press it in and try to run this pocket of air to the side, but no matter how you try - every time you try to squash this bubble another appears. You have not solved the problem, you have just moved the problem somewhere else. We pay great attention always to solve a problem, and to avoid simply making a problem someone else's or just as hard but in a different space.

The Data Model concept is an example of this - try as we might, the industry will never have a common data model that fully describes every plant, as each app will care about another attribute which will need to be filled into the model (the problem has only been moved to how do you build a standard model that serves everyone) - which by the way is a bottom-less pit of funds that can never be complete, and will always need to be updated.

So - what is the solution?

With Wallpaper, the solution is to strip it off and start that strip again. This is a problem for any oil company that has begun the modelling work - as no doubt a large amount of money has been spent. The analogy for this is the effort in putting up the strip of wallpaper - we are so tied to the effort that we have already put in to cutting that piece to size, pasting it etc, that we commonly spend ten times as much effort attempting to fix the problem rather than one times the effort to simply do it again right. If you don't believe me on the ten times as much effort to fix, take a look at all the different options on the internet, taking a syringe, and injecting paste, a roller - the truth is some of these may make the problem better, but will never truly solve the problem, creating a new one like a rip in the paper..

So my advice is forget standard data models ( and don't think for one minute that all the mapping you have already done will help when you come to taking something from market.)

We all talk about using Machine Learning on equipment data, and many Data Scientists then want someone to process the data before handing it to them, so that they can find an anomaly (do you see how the Data Scientists have shifted the problem there - they make it the problem of the client to pre-process the data). But this is actually where the solution lies.

We can use Data Science to process the Plant data, to identify the assets, we can even use Data Science to configure the models - (this is the hard part). then we can use Data Science to do the work (this is the easy part).

We at Intelligent Plant are pioneering the development of true Apps - these are self-aware Applications that take some of the responsibilty for mapping from the user (they work like Apps on your phone, doing something immediately, not requiring two years of effort to do tag, or model mapping). They create their own view of the world and they save time, making it possible people can actually get the benefits from their data.

Take Controller consultant for example. This App assesses controller performance across sites. It does not require anyone to do any mapping - it simply connects to the historian (or direct to the Control System if required) - and finds what it thinks are controllers then it starts monitoring them.

To compare this with other Applications that purport to monitor controllers, they tend to require around two years of Engineering effort (the client we spoke to about this had previously spent as much as they had on the Application on the effort to configure the Application. At this point they gave up and had received no value from what they had done.

If you are interested in making use of these Apps - you can download App Store Connect from the industrial App Store (https://appstore.intelligentplant.com) and start work immediately, only paying for the Apps you use. Take a look at our youtube channel to see some of the Apps that are already available..

If you don't believe us when we say that building your own model is not going to help, then come back to this page in a couple of years and consider the efforts in mapping models to others, and gathering and updating the model - we find it hard enough to keep the Engineering Data up to date, so what chance do we have with complicated models - much better to get Machine Learning to solve that so that the App's perpspective of the data world can change over time.

Feel free to get in touch with us if you would like to discuss how to go about things in a different way, we love to talk about this topic and are willing to help anyone, be they client or Collaborator.