An important aspect of the MVX data model extensibility is the concept of equipment roles. The following screen casts provides an introduction to this concept and how it is applied in MVX. A transcript follows the video.
This screen cast runs through the concept of equipment roles in MVX. Items of equipment are registered in MVX using a configuration tool such as the one you are viewing now. In other screen casts, we've shown examples of data models that define how we represent equipment information in MVX.
Equipment roles are an extension to a data model that allow equipment to play different roles in an industrial automation system independently of their core nature. Examples of different equipment roles include:
Documentation
Maintenance
Video Surveillance
Electrical Circuits
Communications Networks
Steam Circuits
These roles define how an item of equipment relates to different sub system within a broader enterpise system.
Each equipment role can have its own specific properties and relationships just like the core Equipment data. Each equipment role can be applied to different items of equipment or not applied as required. A role can then be associated with a specialist display in the MVX 3D user interface. You can also add new equipment role types that are specific to your own project needs.
This ability to split up different aspects of equipment information using roles makes it a lot easier to implement User Interface systems that display all of this information consistently and with a strong organizational sense.
The screen you are seeing shows an MVX configuration program where a pipeline instrument has been selected. We've covered this configuration of equipment in other screen casts, but you can see that the pipeline instrument now has two additional tabs, one for documentation and one for maintenance. This implies that the equipment selected plays two roles in the system beyond being solely an item of equipment.
Lets segway into some theory just for a bit. This class diagram shows the structure of the MVX equipment role design.
Any item of equipment can have an arbitrary number of equipment roles associated with it.
Documented Equipment is one of the standard MVX roles.
Each item of documented equipment can have an arbitrary number of documents configured for it.
Each document belongs to a library of documents.
A more complex structure exists for the maintenance design. This design is based directly on ISA 95 maintenance concepts. Alternatively, the maintenance structure can be based on your own in-house maintenance system and simply linked to an MVX equipment item via a unique identifier.
If the equipment role gets all of its properties from an external system, then configuration can be limited to the definition of a unique identifier.
The documentation system provided by default in MVX allows you to configure which documents are associated with each item of equipment.
The documentation system can be based on the internal MVX document system or linked to an external Documentation Management System. The internal MVX document system is based on internet and intranet addresses.
The documents are organized into libraries so that the root address of a set of documents can be changed centrally as needed. Any document with a file name suffix recognized by your Windows setup can be referenced.
Now that we can see how a document role is configured, lets have a look at an example of how it is used within the 3D space.
If we find an item of equipment that we are interested and then click it, a dialog is displayed. From here we can list all of the documents associated with that item of equipment and double click to view the document. In this example a browser page is displayed but it could be a word document, an excel document, a pdf document or whatever.
If we turn around and click on the generator, we can access documents relating to that generator. We're using publicly available web pages for this demonstration but they can be any document available on your intranet.
Lastly lets scoot over to a valve and click on it to see its documentation.
In summary, the MVX equipment role functionality provides a very powerful way of organizing information on equipment in a consistent way. It allows information on equipment to be grouped so that your personnel can easily understand how everything fits together in your complex industrial automation system.
This should be the last of a burst of screen cast posts for this week. This last one discusses how MVX configuration can be used to make it easy to alter 3D scenes after an initial project delivery where you may not have access to a 3D designer or want to keep ongoing maintenance costs down. As usual a transcript follows the video:
There are a variety of scenarios where a 3D Visualization system such as MVX has significant advantages. Many customers recognize this and are excited the prospect of applying the technology. One concern customers have brought up is having to bring in a 3D designer every time some aspect of the 3D scene changes. This screen cast illustrates that MVX can be designed so that adding or modifying what equipment is displayed in a 3D scene can be done without having to alter the 3D scene graphics. It can be set up to be a configuration exercise that people who have familiarity with form based Windows programs can learn fairly easily.
The display shows two programs. On the left is the 3D visualization program, while on the right is a configuration program that can be used to define what equipment is present in the scene.
I'm looking around the scene and you can see two reclaimers that have been included as part of the 3D scene. You can choose to have equipment defined in the 3D scene at design time or have the equipment loaded purely at run time.
I'm now going to add a truck to the configuration. This truck is defined in the MVX Object Server and has not been defined in the original 3D scene apart from the fact the scene knows what a truck looks like. The communications infrastructure kicks in and informs all connected clients that a new piece of equipment has been added to the data model. The 3D visualization clients then bind this new truck object to a visual representation of a truck and one appears.
Any configuration changes I make on the server are automatically transferred to connected clients.
We can change position and orientation information.
Such as.. Roll
Pitch
and Yaw
Now let's add another item of equipment. This time a light.
You can make the standard position and orientation changes.
You can also make any state changes that are available for that item of equipment. In the case of a light we can control whether the light is on and the brightness of the light.
I'll add a another truck and change its position and orientation.
One more truck and we'll leave it at that.
This screen cast has focused on configuration. However you can link any of the position, orientation and other visual properties to external data sources such as SCADA systems, GPS systems, training systems etc.
The main message of this screen cast is that you don't need access to a 3D designer to make configuration changes in a 3D scene. Note also that these configuration changes can also be linked to external systems so that for example your asset management system is the automatic source for 3D equipment configuration information in MVX.
Following on from the MVX Object Pipeline Demo Configuration screen cast here's another one that covers how you can set up multiple deployment scenarios and use the same 3D scene for operations, historical review and training/simulation. A transcript of the presentation follows this video.
This screen cast demonstrates how MVX can be set up to work with multiple data source deployment scenarios. The example shown here illustrates how the same visual model and data model can be used with multiple data sources to display current live data from operations, review historical data and also obtain data from a simulation source such as an Excel spreadsheet. We're following on from another screen cast that demonstrated how an MVX object based data model can be configured and associated with data from multiple data sources.
The program window on the left is a 3D scene that presents a view into a compressor station on a gas pipeline. The window on the right is a configuration program that defines the data that is displayed in the 3D scene structured using an object oriented approach. This object oriented approach to structuring data in an MVX system is also the subject of another screen cast that is worth viewing if you haven't already.
The first deployment scenario we'll be showing is the display of live data from an Operational SCADA system.
The example shows a compressor on the left, gas pipes coming in from the upper left through the station via the compressor and then out to the upper right. We're starting out with the compressor running and gas flowing through the station. This scenario is communicating to a separate SCADA software system which is actually running a simulation in this case. We'll close a valve and then see the effect on the station.
The valve is closed and you can see that the visual state of the outgoing pipes change to white to indicate that no gas is flowing at that location.
The measured pressure then starts rising. We'll just let this SCADA system simulation proceed until it hits the maximum pressure of 9000.
Once the maximum pressure is reached, some fail safes kick in and the compressor is stopped and the output valve opened. The 3D scene shows that gas is now flowing through the output valve and the compressor is no longer running.
This automatic valve closure scenario is a typical scenario that may need to be reviewed after the fact. We can do this by switching to the Historical deployment mode. The data in the scene is now obtained from a process historian and the time of the data displayed can be controlled. The time controls include the ability to go to a specific time and then move back and forward in time as required.
We'll first run time backwards to find the point in time at which the output valve was closed.
I'm now playing the scene forward in time observing what happened faster than real time. This functionality can be applied to a host of issue review and training scenarios.
Lastly lets switch to a simulation deployment scenario where no SCADA system is involved. All of the values originate from an Excel spreadsheet. Changes in the spreadsheet are reflected in the 3D scene. We're using an Excel spreadsheet purely as an example of a simulation data source. You can replace it with a more in depth simulation systems as required.
Because of the nature of the MVX data architecture, you can mix and match data sources to achieve your operational, analysis, planning and training needs using one visual model and one data model of your system.
The screen casts keep coming. Here's one following on from the Pipeline Class Diagram video running through the configuration of an object server. A transcript follows the video below:
This screen cast shows how an object based MVX system can be configured based on an object model developed specifically for a domain. In this case, the domain is a compressor station on a gas pipeline. This initial screen shows the object class diagram for the demonstration pipeline system. The details of the class diagram are covered in another screen cast. It's worth going through that separate screen cast to understand the object and data structure that will be configured in a form based tool and then displayed in a 3D environment within this screen cast.
Let's bring up the configuration program. This program provides both the ability to configure an MVX system using objects as the central organization theme and to run as a data server for client programs which then display the data.
On the left side of the screen are two primary navigation sections relating the Operations configuration and general Administrative configuration. The operations configuration section displays an icon for all of the different types of object that be configured. You can see that many of these types match the object types defined in the Pipeline Demo class diagram.
Selecting one of the these object types brings up a configuration screen to add, edit and delete the configuration those types of objects. We are seeing the configuration screen for Pipeline Instruments. That is, instruments that measure some value associated with the pipeline flow.
The instruments that are configured are listed in the data grid at the top of the screen from which you can select an individual object instrument in this case to edit. Once selected, the bottom portion of the screen can be used to edit the object.
The Name, Title and Description properties are all defined in the MVX Equipment base class.
The Inputs, Outputs and Fault Indicators are relationship properties defined in the Pipeline Equipment base class. Configuring these relationships involves clicking on the Modify buttons and then selecting which other items of equipment related to the selected instrument. These relationships are then displayed as a list of named objects.
The final aspect of the instrument configuration are the properties that are specific to the Pipeline Instrument class. These are the units of measurement for the instrument and the current measured value. All values that are not relationship links are treated as configuration values by default. Through a process called externalization we can configured an object's properties as being defined in an external system. The small blue square next to the Instrument Value is an indication that the Instrument Value is externalized and is not just a configured static value.
Browsing through the other equipment configuration types shows the same editing pattern repeated. You can add, edit and remove equipment entries. A data grid allows you to browse through the current equipment configuration and then an equipment type specific form allows you to configure that piece of equipment in the system.
Let's find an item of equipment with a few more relationships to illustrate the relationship configuration functionality.
Clicking the Modify Inputs button brings up a multiple item selector. The list on the left defines all of the Pipeline Instruments that could be related to the selected pipeline instrument but currently isn't. The list on the right defines all of the currently related instruments for the selected relationship concept (which is an Input relationship in this case). Note that these lists automatically have knowledge about the type of relationship. The relationship type is a zero to many and it related to Pipeline Instruments. This means no configured generators, fault indicators etc. will be included in the list as they are not pipeline instruments.
This MVX Object Configuration can then be mapped to a 3D scene. Let's start up an MVX Visualization session that includes visual model of a gas compressor station. We have multiple models here. One model is a data model that is based on objects and relationships. It is then mapped to a visual model which in this case is a 3D scene.
I'm first editing the MVX preferences to turn on the ability to navigate in 3D space or in other words to be able to fly. The default for the settings is navigation based on what is considered the ground in the 3D scene.
You can also configure the location of servers in the scene. This allows an engineer to connect to a test server but when the functionality is made available to operators it can connect to a production server. Each 3D scene can also connect to multiple servers if needed.
Let's take a look at the compressor station from up high and then browse around a bit.
There's a couple of generators.
The gas comes in from the left, is brought into the station and then exits to the right.
There are some cooling fans for the pipeline.
There's a compressor and you can see some compressor properties displayed as 3D text next to it. The smoke provides visual indication of whether the compressor is running or not. You can choose to use other visual artefacts to get across information states to the viewer but for this demo we're using a smoke concept.
You can actually see the shadow of my flying avatar on the ground as I move around.
The outside movie screen is another visual artefact which can be used to display live video streams from site for example.
Ok... Lets position things so we can see both the configuration environment and a portion of the 3D scene that relates. We are currently running in "No Current Deployment" mode. In this mode, all values are treated as configured values with no external data sources.
Lets configure the compressor to be stopped. You will notice that the display of smoke no longer occurs. This just illustrates that values in the object data model are mapped to visual states in the 3D scene.
So far this screen cast has shown that a set of related objects can be configured within an MVX configurator. We've also shown how data model states can be reflected as a visual state within a 3D scene. The next step is to show how individual property values in the data model can be externalized by linking them to a point in an external system such as a SCADA system.
As mentioned before, the small rectangle next to the property values is blue if that property value has been externalized.
Clicking on that rectangle shows the current external data configuration for that property value.
I'm showing the external configuration for a single Valve's Closed property. An MVX system can configured with multiple data sources. Each property can then be configured to identify how that property value is obtained from the external data source. In this example, there are three data sources that can be externalized to.
The data sources in this particular configuration are an Excel file, a process historian and a live data server. Each can have its own property value configuration but two of the data sources shown here actually get their property configuration from the live data source. This is allowed to minimize the need to perform repetitive configuration.
The historical data source uses the same tag name as the live data source. We've also chosen to name cell ranges in Excel using the same tag name format to reduce our configuration overhead.
Here's an example of the property configuration of another MVX data object.
The separation of external data into multiple data sources is a powerful feature of the MVX Object Server functionality. Your developers or our team can develop data sources as needed to link a variety of disparate systems into the same MVX Object Server data model. Each data source can have its own specific data source configuration and property value specific configuration.
The MVX data source functionality is made even more useful by providing the ability to group data sources together as deployments. Our example here is a very simple grouping where each deployment configuration contains just one data source. You are free to combine multiple data sources in the same deployment if needed.
The example deployments have been labelled Historical, Operations and Simulation. These are just examples and you can have as many and name them whatever is required for your scenario.
In historical deployment mode, all data is retrieved from a SCADA or process historian and represents data at a point in time that you specify. In operations deployment mode, all data is retrieved from a live system and is current data. In Simulation deployment mode, all data is retrieved from an Excel spreadsheet which can be either manually entered or calculated values returned to replace the tag values that would come from a SCADA system in Operations mode.
The beauty of this data source and deployment infrastructure is that your core data model stays constant across the deployment options. It's just where the values originate from that varies between deployments. The shape of your system is defined by MVX configuration while the data values are obtained from different systems depending on whether you're running in Operations mode, reviewing historical data or running through a simulated training exercise.
Lets now demonstrate the live data values flowing through an MVX Object server based system. This demonstration application has a mini MacroView system built into it. MacroView is a SCADA application that we've developed and maintained for many years. Clicking the Start button starts up a number of background processes that perform tasks such as message processing, simulated PLCs and scripts, a historian and some communications services.
Let's go into Operations deployment mode and now all of the values displayed in the scene originate from our SCADA system. You can see that the gas is flowing from the visual state of the pipes.
You can also see the pressure coming out from the compressor.
Lets close the valve that lets gas out of this compressor station. You can see the pipe visual state change to indicate that gas will not be flowing.
We'll finish off this particular screen cast now and leave the demonstration of more of the operational mode functionality and switching between different deployment modes to another screen cast.
In summary, the object server functionality of MVX allows you to configure systems which have a strong sense of real world structure to them at the data level and not just at a visual level. This provides a strong base for implementing complex systems, large systems and highly functional systems without being overwhelmed by large amounts of unrelated data.
Here's another screen cast related to MVX. This one covers the how objects can be modelled in MVX as opposed to using the traditional SCADA tag based approach. It's centred around describing how to interpret a class diagram of a demonstration MVX project we've development. A transcript is included after the video:
This screen cast relates to the MVX 3D Visualization Software for Industrial Automation and in particular representing industrial automation data as objects within the software. MVX is a software product range that includes 3D Visualization Software, data management software and communications server functionality. Though the 3D graphics aspect of MVX is the most prominent due to its visual nature, we are covering the data management aspect of its functionality in this screen cast.
On your screen is a diagram called a class diagram. It is a representation of the data structures in a demonstration MVX system we call the Object Pipeline Demo. The data in this demo all relates to the data available in a gas compressor station on a gas pipeline. We actually have two pipeline demos. One implements the functionality using a traditional SCADA tag based approach whilst the Object Pipeline Demo structures the data as objects instead of tags.
The class diagram shown organizes the tag data into classes of objects. The classes of objects are named to match the names that we would use to describe the compressor station in normal spoken language. For example, it's quite clear what the purpose of the Compressor, Instrument, Valve, Fan and Generator class names refer to within the system. This is the advantage of a domain model based approach to data management. The domain in question is a gas compressor station in this case.
The class diagram was created by the Microsoft Visual Studio package simply by dragging object classes onto the diagram and then selecting which aspects of those classes are displayed. Another example of a type of class diagram is the UML class diagram, where UML stands for Unified Modelling Language. The diagram notation used on the class diagram displayed uses the Microsoft conventions rather than UML diagrammatic conventions.
The diagram shows all of the classes of objects documented in the diagram as rounded edge boxes. Relationships between the different classes are drawn as lines linking the boxes that define the classes. The grey lines with an empty triangle at the end of the line represent an inheritance relationship. An inheritance relationship can be viewed as one class being a type of another class. For example, a Generator is a type of Equipment. Similarly a Fault Indicator and Pipeline Equipment are both types of equipment in the system.
Note the use of the word Type in the previous sentences. We often use the words Type and Class interchangeably within the MVX product range. Class is more often used in programming languages than the word Type, but the latter works better with spoken English language in my opinion.
So.. the inheritance relationships are represented by lines with a hollow triangle at the end of the line. From this we can tell that Compressors, Pipeline Instruments, Valves and Pipeline Fans are all forms of Pipeline Equipment in the system being displayed here. However, Generators and Fault Indicators are items of Equipment in the system but are not specifically Pipeline Equipment.
We can tell this, by looking at the differences between the Pipeline Equipment class and the other classes that inherit directly from the Equipment base class. Pipeline Equipment is related by two zero to many relationships which have been called Inputs and Outputs. A zero to many relationship implies that each item of pipeline equipment could be configured to be related to an arbitrary number of pipeline equipment items either as Input or an Output. In this data model the Input and Output relationships define where on the pipeline an item of pipeline equipment has been installed given the normal flow of gas.
This ability to group SCADA tags into object classes and then relate those objects using a number of relationship types provides MVX with the power to manage more complex data scenarios than the traditional SCADA tag based approach. It allows people to use the same terms they would use in spoken or written language within an MVX system. In this pipe line demo system we're using terms such as compressor, instrument, valve fan, generator within the software and configuration itself. These are the same terms we would use in conversations between operators, engineers and maintenance personnel.
The relationships between these concepts that we understand are then embodied in the software itself. It allows us to write a single set of code, scripts or configuration that can work in a large number of contexts without copying or modification. This all implies a reduction in system and software maintenance costs.
Say we needed a pressure value for all pieces of pipeline equipment. We can create a property value on the Pipeline Equipment class that uses the Input and Output relationship information to find the closest pressure Pipeline Instrument to it in the gas flow and then return that value. If the traversal of relationship information encounters an item of pipeline equipment that stops flow, such as a valve, before it locates a pressure instrument then it can indicate that the pressure cannot be determined for the position of that particular piece of equipment in the pipeline. This is an example of the power of relationships in industrial automation systems.
Getting back to interpreting the class diagram. An item of pipeline equipment is also related to an arbitrary number of Fault Indicators. A fault indicator is any input that presents a boolean status value indicating a fault scenario. This general purpose approach allows fault scenarios to be modelled without the need to define classes for a wide variety of fault oriented sensors or PLC logic. Note that the relationship concept can be leveraged again in that the fault status of an item of Pipeline Equipment can be aggregated in the Pipeline Equipment class regardless of the number of fault indicators configured. In addition, the fault status of a segment of the pipeline can be identified by aggregating all of the fault statuses of the pipeline equipment connected as Input and Outputs in that segment.
Within each of the class diagram boxes, there is a section labelled properties. These can be viewed as the more traditional SCADA tag values grouped into object classes. These object properties can be mapped to SCADA tags and other type of data points in the MVX software. We will cover this mapping process in another screen cast. I hope this screen cast has been helpful in understanding how an Industrial Automation system such as a gas compressor station can be modelled as objects in MVX.
The following screencast uses a demo program as a background to describing the benefits of the MVX Object Server product that we are working on. It's a server side option for where the 3D MVX graphics client gets it real time data from. The transcript of the screencast is including for robots and humans alike.
This screen cast is titled "Managing Complexity with MVX Object Server". The MVX Object Server is a product in the MVX 3D Visualization Industrial Automation product range. It runs on the server side and is not a visual component of the software. Its more software plumbing also known as middleware.
The majority of Industrial Automation visualization systems are built around the concept of tags or points. A point represents a single input or output value monitored or controlled by the system. Tags are typically an extension of a single point with additional metadata such as scales, description and alarm information - though the exact nature of a tag varies depending on the system. The general theme in traditional Industrial Automation is a tag database which defines a potentially vast collection of points with unique names.
The premise of the MVX Object Server functionality is that as soon as you get any reasonably complex system, the tag database becomes opaque in that it is difficult to understand or get any feel for the underlying information structure without significant effort. SCADA systems typically tackle this by using a consistent naming standard to provide a basic hierarchy for the tag definitions.
We believe that there is a significant benefit in structuring this tag data into a data model where the relationships between the tags are a first class citizen of the model. This allows the structure to be clearly defined in software and for people to understand it quickly.
The application you are seeing is a small demonstration of this premise. It displays that same underlying data in the form of points, entities and objects. First lets generate a set of information and display it as points. The result is representative of the feeling you get when first viewing a large point database. There's lots of information but it's difficult to see how its related.
Next let's do the same and represent the points as entities. Entities are a SCADA concept that are embodied in the MacroView package that we developed starting back in the late 1980s. We still maintain and develop the MacroView SCADA package today. The entity concept is extremely useful for organizing data points. For those not familiar with the MacroView package, entities can be viewed as a form of configurable complex tag structure. This display of entities better organizes the point information, to reduce the concept count you have to deal with... but these are still a lot of entities to keep in your head at one time.
Lastly, lets display the point information as objects. This last diagram provides a much clearer indication that there is an underlying structure to the long list of points managed by the system. These links and relationships provide meaning to the people that maintain such systems and are also incredibly useful for implementing additional functionality without having to write reams and reams of repetitive code or system configuration.
The MVX Object Server technology manages data at its core but is presented to other software as a communications server. We can embed that server functionality into a wide variety of programs. We've actually embedded a server into this demonstration application, which I'll start now. I'll also run a utility called the Metaserver Explorer which is a client side application and connect to the server.
The metaserver explorer has connected to our demo server and is reporting on the contents of the objects it has found. All of these objects were created by the demonstration application and displayed as point, entity or object diagrams. I'll just browse around showing the types of information that is being reported on.
It also has an option for writing out the Object Structure as a JSON file. JSON is a text format originating from the javascript programming language. We're using it here as a means of saving an object structure to a text file. The benefits of this format include the ability to store complex object structures and relationships between objects.
In summary, the MVX Object Server technology helps you manage large amounts of Industrial Automation data in a consistent and structured manner. This becomes even more important when you start integrating data from non industrial automation systems such as IT systems, document management systems, maintenance systems and security systems. It provides a strong server side and information management aspect to the MVX 3D Visualization story.
Torq Software and Sentient Computing held a short morning presentation covering the work we're doing in the 3D Scada arena. Doug Bester did the first part of the presentation and then I covered some more technical aspects in the second part of the presentation. The second part was also focused on the MVX Object Server technology and less on the use of the 3D visualization. In retrospect, we should have had more visual impact from showing more of the 3D SCADA examples. However, the less visual object server concepts are still very important though they may not be as visually appealing. The following video has been split up into two portions to fit in with the 15 minutes limit provided by Youtube. We've decided to move towards Youtube hosting of video content because of the following reasons:
·Its easily playable on platforms such as ipads and iphones.
·The time limit for videos is now 15 minutes up from the original 5 minutes.
·The video resolution allowed is now practical for showing screencasts.
Man, I haven't blogged for a while and actually want to get back into it. Being a developer by nature as well as by profession, I often get into the rut of not letting people know what Torq has being doing an achieving. The theory is that being able to quickly email a blog post via Posterous will make it easier to quickly send thoughts to the ether. So this is pretty much a test post with a couple of gratuitous MVX product screenshots to test the image importation. The posterous account has been set up to automatically post to blogger, so we'll see how that goes as well.
