Tip:
Highlight text to annotate it
X
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 that 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 to 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 of those types of objects. We are seeing the configuration screen
for Pipeline Instruments. That is, instruments that measure some value associated within
the pipeline gas 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 or instrument 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 relate 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 configure 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 particular 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 is related to Pipeline Instruments specifically.
This means no configured generators, fault indicators 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 a 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 to be 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 a 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 it relates to. We are currently running in a "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 relates. 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 be 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.
Here's an example of the property configuration of another MVX 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 as you want 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 the 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 no longer 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 the 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.