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 developed. 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.