Inspired by all this talk of some kind of Open Source development of a PI tool I thought I would share one of my ideas that has been hanging around my hard drives for some time now - the virtual world of PI. Now by virtual I don't mean virtual servers running PI, I mean a whole virtual world and a different twist of visualising your PI data.
I have always been a massive, massive fan of ProcessBook as far to say it is my favourite OSI tool (with AF more or less on par). Imagine your 2d schematic on the ProcessBook display, values updating nicely and then at the click of a button you enter a 3d world representing the equipment of that very 2d schematic. Wouldn't it be nicer if you could fly around the equipment and see the live data from PI on the equipment/plant/refinery... - well I thought it would be nice if we had that option, so off I went...
Now what was apparent from the start were the various 3d modeling formats out there, various graphics engines etc so I decided to stick to the big boys and I came across the Microsoft XNA framework redistributable, did I mention it is free? After some digging in to XNA I soon got up to speed with some spinning cubes, flying around the cube - pretty much the controls I need fly around my equipment. For any of you that have seen Google SketchUp, well I was "inspired" by their navigation controls.
It was a big learning curve working with XNA and 3d "game" programming in general but it was required if I was to understand the 3d world of PI.
I am going to summarise the next part as it is more involved than it sounds - I then started looking in to the various modeling formats that I could load in to XNA framework and have them rendered correctly. This is the tricky part, however I soon managed DirectX & FBX but other formats need their own set of classes & logic to load, not something that can be done overnight. For now I was happy with a couple of formats to prove the theory and it appears I proved it albeit with some optimisation issues. I was flying around looking at a pump and a pipeline. Next, I needed to see data, any data even static data - basically some text dotted around the 3d equipment.
After some more digging around and talking to more experienced XNA guys I moved on to BillBoards and soon had string values being placed around the equipment (in completely random places because I was guessing the 3d coordinates). At this point I had done enough to prove my point, plugging in live data seemed a fairly trivial task so it was time to sit back and look at the bigger picture. I have been sitting back for far too long, I feel the need to revive this and progress it further.
My plans were the following:
- Create a plugin environment for different model formats to be used within the tool. Sounds simple but I fear it is the most difficult part.
- Use AF to store meta data for a 3d model. This includes the full definition of where data points are placed in the model (or the model definitions files could be parsed for data points).
- AF meta data would also define "views" on the 3d model linked to PI Notifications. Imagine, Tag1 is shown in the model and goes in to alarm. A PI notification is raised and triggered in the tool, a link or alarm list then appears if the notification is defined with a view. User clicks on the item in the list and the camera is taken to the predefined view for the alarming PI tag - you are now looking at the alarming piece of equipment.
- Enable data to be fed from PI event pipes in to the tool and update live values in the 3d model - the billboards. Would need optimising so elements are not redrawn too often.
- Various tools to help with bulk loading models, managing the AF databases specific to this tool etc.
- Optimise, optimise, optimise every line of code.
There you go, my idea is out in the open.
Would appreciate the immediate thoughts of the community.
I am keen to work on this tool just because it is a challenge but I am also real to the size of the task ahead of me. There are probable tools out there that do something similar (I even saw 1 tool toying with the idea of PI in 3d) but I envisioned a tool tightly integrated with PI to offer a new dimension to PI data. No doubt I skipped over a few details but I am writing this post from memory, I must open my source code again...
Just to be on the same page as you, how do you envision creating a 3d model? It it by manual drawing of equipment in a by importing one of those files produced by 3-D laser scanning products?
So long as the 3d model(s) are in a supported formated by the tool (by way of a plugin) then the model can be used. Providing the data points coordinates are within range of the models world, then they can be drawn. Depending on the "size" of the model then the "speed" of flying around would need to be adjusted.
Various methods can be used to create the models, at one client I have seen a whole floor of a building dedicated to the production and maintenance of CAD models in AutoCAD. If a plugin was created for AutoCAD formats then the models would then be loaded, data from PI associated with each model drawn and away you go. The tool wouldn't be overly concerned with how the models are created, just the format and associated files. I know it sounds far too simple
I even started messing with textures for plant objects and it can start to get tricky loading the content dynamically at run time but I did find a very helpful XNA guru who showed me some tricks to do so.
AF really would be the key for storing the structure and meta data for each model and PI historians just plugged in to the model to provide the data. Essentially an existing PI user could "addon" the tool to their PI infrastructure and have browsable 3d worlds of their data.
I always imagined a refinery that you could fly around, look at equipment and their readings. Be shown alarming equipment etc If you were really ambitious, hook in the Microsoft MapPoint to plot your company's global locations and enter the 3d worlds dotted around.
I have once run into one of the people at INOVx. They list OSIsoft as one of their partners. They were trying to sell a system in Saudi, but I have no idea how successful they were. Their website says:
INOVx’s Intelligent Adapters provide live, context-sensitive links between the 3D model and external systems such as ERP (e.g., SAP), operations (e.g., OSIsoft PI, SCADA), inspection (e.g., Meridium, UltraPipe), maintenance (e.g., SAP PM, Maximo, Advantis), CAD, document management (e.g., Documentum), and other plant systems.
This is an interesting thread. I'm curious how big the market for a 3D modeler would be for our marketplace. It's not a new idea. I would be interested to hear which customers would find this valuable in their day to day operations and how they would use it.
I have 20+ years of software development in the area of manufacturing operation and control, and the idea of 3D visualization comes up every so often because it seems cool. While it sounds like a great idea to just fly through a virtual 3D plant like Harry Potter on a broomstick, the reality is that this may not really add much business value. When I look at the trends in visualization, it is more around bringing information to the knowledge worker and having this happen in a prioritized, event driven manner. This idea adds business value because it brings the appropriate information to worker that they need to action on.
Even for exploratory tools, it is much more valuable to have 2D tools that understand the context of my plant in terms of process flow and physical layout than to have 3D per se. This kind of 2D mapping is something we are looking into providing in a product from OSIsoft, and would add alot of value in terms of providing automatic navigation based on an AF model. It is hard enough to get a good 2D model that represents a customer environment, nobody has really mastered this yet in the industry, much less a 3D model.
For physical equipment troubleshooting, a 3D visualization model may make quite a bit more sense. However, this may actually take the form of real-time video (via camera) or a set of 2D pictures stiched together versus drawing the equipment with vector graphics. If you were to draw with computer vector graphics, it would make sense to get these drawings from a CAD or CAE program that has already captured a 3D model of the equipment. Either way, you could then tie real-time process variables to various points on the 3D picture to aid the user in troubleshooting. I would see this as a useful addendum to a 2D navigation world, not a replacement for it.
There is a reason they call it "eye candy", it has alot of calories and not much nutritional value.
Great discussion, please keep it coming,
One area where a customer has found value in 3d visualization is in supporting remote operational teams from a Central Engineering Center. I believe the customer plans to intergate PI data in those displays. So in this case, 3d visualization was justified separately, and real-time PI data was added later.
Being involved in PI Sales, I find myself repeating pretty much some of the things you said, i.e., that the PI System helps in "..bringing information to the knowledge worker " and "...add business value because it brings the appropriate information to worker that they need to action on." Unfortunately, many people roll their eyes when they hear this but are easily impressed by lesser solutions that show cute animated 3d oil well graphics.
So when you think about it, OSIsoft has a good Server and Data Access layer. Third-party value-added products will necessarily be categorized as Analytics or Visualization. Perhaps, deep down Analytics and Visualization are the same thing, as some consider Visualization to be Analytics that relies on eyeballs.
This kind of 2D mapping is something we are looking into providing in a product from OSIsoft, and would add alot of value in terms of providing automatic navigation based on an AF model.
Isn't this what the TreeView in AF Client is already doing?
I really tend to agree with John here.
I have thought of this before, but when I was thinking it trough I don't really see the added bussiness value here.
There is a greater demand for 'eye candy', even in our line of bussiness. But the eye candy has to be functional, and really add value for the user. Such a 3d system will take a lot of development, and wouldn't come cheap. That is where I think it will fail: costs vs added bussiness value.
In my opinion, the next step will be to create 'eye candy' visualisation applications using modern techniques and technologies (such as WPF, Silverlight and maybe XNA). Rich webbased applications that will take over the role of the desktop applications as we know them. After that, I think that the whole multi-touch thing will set in (e.g. Surface). Both of these will provide added bussiness and technical value, and have the opportunity to look and feel very nice.
This is a really interesting topic, and here are my 2 cents on the topic.
I once tried to implemment a 3D model of a plant and here are the things that we had to take care of while designing the 3d model:
- The plant should be represent by the model as faithfully as possible
- The model should have cutouts on the things that were being mesured
- Every single block of the model should be marked when hoovered and allow to be click to do a drill down
- Drill downs should have a HUD with all the variables needed
- Blocks should be divided into other blocks
- Screen could be divided in 4 sections, each one with a viewport, each one independant of each other.
- The duct section would have a series of circles that would protube away from the cut to represent, visually, the amount of flow there is in the duct.
- The burners would have a flame that will change bright, diameter, and height in order to represent the value of waste.
- The objects closest to the screen must all have a floating value next to them updated in real time
- The objects must be painted based on the colors of the real object
- The painting on the objects could change colors or be highlighted if there is an alarm or a critical path (preferably blinking from real to alarm color)
- There should be a menu that allows selecting Same kind of objects (displaying each of those in a viewport) for comparison, supply chain or plant type.
- Navigation could be done via keboard only, mouse only, or both.
- The 3D engine should replicate the Day and Night state of the site.
- If video monitors were available then video should be presented in special booths in the model (as screens or operations inside the model)
- Every sound made on the model should be 3D
- There shall be no sound alarms in the model
- Visual alarms are permitted but changing focus without user notification is not.
- Sounds for burners flickering, oil pass, meter runs, and other things in the plant are permited. Also, if mic's are installed in plant grabbing the real time audio is preferred.
I also had some screen shots and did a working model that ran on Xbox. Now adays I would have gone and do the same in the "Source Engine" that valve created as it is really flexible and somewhat easy to use. We did not continue working on this as the interface was not so bright and we couldn't achieve everything we wanted to, finishing the model was a lot of work. making it usable for another plant was really hard too. And the changes in the plant were to great of a challenge (we had the as built diagrams, but after 27 years of existance those were not near as real as they should).
On the other hand, I've been waiting for a real 3D desktop for quite a while now. I thought that windows 7 would have included some form of 3D, you know, desktops have never really been 2D. yes, it is a 2D surface but you actually use the 3D space that sits on top of it! So I won't hold my breath any longer for any of thos things to happen.
I agree with the today's technology you propose, I would even dare and go using light clients like blender (for 3d over the web cost: free, includes manual) and valve's source engine (for cheap, tested, working, 3d engine for simulation and navigation cost: 20 bucks per seat, includes SDK and Tools) or XNA (games for windows/xbox/zune; cost: depends on platform). There are many products available for this.
So, let's hope that now that we have a lot of power on the desktop someone will put it to good work!
Maybe I am biased because I am running with a prototype but I still think it is worth pursuing up to a demonstration level. Just to clear something up here is that the intention for such a tool would be it is built of free technology and made available for free, after all all it does is load 3D models and draw data in to the model from PI. I think what Cristobal put above is a very specialised version of a 3D world of PI, in fact it is just 3D ProcessBook (or Process3DBook).
The real simplicity of the tool would be it wouldn't care for the details of the 3d model input, just can I load it, display it and navigate it. If you get too specific with multistating 3D symbols, identifying symbol/object types (column, pump, flow meter...) etc then the first version would never get built. Once you can navigate it then dotting around the data and updating the data is run of the mill stuff.
I did like John's definition of eye candy although I like to think such a tool will have some protein to balance the calories.
Rhys, I like your idea. I'd like to relate some comments about "eye candy" displays. Personally, I had the same thought regarding a legacy historian system we used in the past. There was the possibility of building pretty displays using an add-on tool, but I never spent time on it. I thought I needed to spend my time on process control, not on pretty displays.
It was only after we had switched to PI, which does have several nice display features, that I realized how much the users appreciated pretty visual displays. The users generally like PI much better, due to the displays and the mouse driven interfaces, as opposed to keyboard and menu driven interfaces.
The 3D project idea you have proposed seems similar. The "eye candy" metaphor makes it seem like this idea can be dismissed. For that reason, I think the "eye candy" metaphor may not be helpful in this context. Metaphors that don't fully describe the situation can lead to decisions that don't fully fit the problem. Think of the difference between French pate plated and garnished by a top chef, and meatloaf provided by the corner deli. There IS a big difference, even though you could also describe the difference as "eye candy".
I think the users might make better use of a 3D interface to PI. Like me, developers have a 3D picture already in their mental banks when the 2D picture is shown. That's not true for all users. If the users are more likely to use it with 3D, that's a big benefit. The users are more likely to use PI than the legacy system, mostly for display and navigation reasons. In our plant, we have many older operators retiring and new operators are beginning to learn the ropes. A picture can be worth a thousand words. I think this idea could also help new or rotating Operators to better understand the connection between the PI abstract data, and the physical equipment in the plant. For those who can't quickly convert a 2D image into 3D, this might help.
I found that the pretty displays I had dismissed earlier proved to have a functional advantage. They were used more by Operations. If OSIsoft writes a 3D interface to PI, I think that could have a similar advantage.
Interesting... very interesting...
On a first hand, I definitely think that pretty displays (and, most recently, multi-touch experience) help because people tend to use stuff more when they 1) like what they see and 2) feel they don't have to think (i.e. highly intuitive) to use it. Due to the nature of our world, 3D seems to makes sense to represent objects/places that we deal with every day, but we are so used to seeing pictures and schemas that it seems like a good combination of 2D pictures and schematics would achieve pretty much the same, for much less efforts. And as John pointed out, this kind of 2D mapping is something we are looking into providing in a product from OSIsoft.
As for the notion of "eye candy". I understand that people will use what they like the best (given that this "attractive" product fulfill other basic data visualization requirements...) and may even contribute having people "go the extra mile": if people feel it's fun and easy to use (i.e. almost a game rather than work), they might dig more into the data and find things that they wouldn't have found otherwise. Yet I don't think it is right to provide eye candy just for the sake of providing eye candy... I think it needs to be thought the other way around: you first think of the business challenges and the data visualization requirements you want to address, and then if you have the expertise and it fits in the broader initiative, then go for it. In other words, just like John and Michael, I think you really need to bring business value first, and then consider how you can make this ideal data visually appealing side of things
And that's where "collaborative projects" comes into the picture We're all good at something... let's join efforts and do great things! And as I alluded to in this other post, we are seriously looking into facilitating your requests about "collaborative projects" and should be able to provide an answer in a week or so. Stay tuned! Once again, this 3D visualization engine for PI/AF is a very interesting project and I think it deserves more thinking and collaboration, so keep cogitating about this!
You might remember this discussion we had a few months ago, with regards to a 3D visualization engine for PI/AF - I alluded to some "collaborative projects" initiative going on... (see my previous posting in this thread).
Well here it is: we now have a way to host Community Projects where people can share what they did and collaborate on various small or big projects - see the announcement here and do not hesitate to contact us if you want to post/share something - like this 3D engine project, for example
I know this thread is fairly old but today I stumbled across a product called "Walkinside", which has a demonstration of linking PI data to the 3D model representation of a plant.
Scroll down to "SCADA demonstration" on: http://www.vrcontext.com/walkinside/24-movies-2.html
I would do a few things differently but you get the idea.
Looks like they call PI a SCADA
Yeah, maybe something lost in translation there.
Actually the guys have a new interface with PI now, going to get some sneak peeks next week - will keep the community updated with any findings (that I am allowed to share). Personally I think this is going to be awesome, especially over the next couple of versions... *runs off to buy shares*
keep us posted on any findings you are allowed to share :-)
It turns out that much of what is being described here has been created and demonstrated by an OSIsoft partner. At the 2007 User Conference in Monterey, Visiant Pimsoft gave a presentation called "Adding a New Dimension to PI and AF Data". It describes how to build a 3D model in PB. It shows navigation in this environment. Perhaps most importantly, it updates with live data from PI and AF. At the time, the demo did not include PI Notifications, which would be a very nice enhancement...
Here is a link to the presentation and video. Maybe someone wants to follow up with Visiant Pimsoft and find out where this 3D ProcessBook project currently stands?
PM, Data Access
Yeah the Pimsoft tool was what I have seen in the past but as I understand it uses their own graphics engine (if someone from Pimosft is a member, please spill the beans). The integration with PI/AF is what I see as key and they did it nicely. When I fished for information in the past, I was not convinced it was readily available, however that was a couple of years ago.