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.