Object-oriented SCADA

Existing SCADA systems are built around the following main components:

• Field I/O
• Control Logic
• Monitoring and Supervision (HMI/Plant Mimics, Alarms system, Historian System)

Together, these components are known as Levels in the CIM Automation Model and are described in further detail in the Classic CIM section of this site.

Each level of control, while logically separate, maintains an internal abstraction of the lower levels. The Control System (PLC, DCS, etc) would also contain a representation of the field I/O internally (often as tables of inputs and outputs mapped to digital or analogue electrical signals. The Monitoring system would require a subset of this I/O together with the various control values from the Logic Controller. Each of these representations would need to be accurately maintained with detailed documentation for each of the interfaces.

Until quite recently, this problem has been compounded by the presentation of data at each interface as vast tables of values, with no inherent meaning attached. This has lead to numerous examples of potentially catastrophic failure caused by a simple misalignment in the I/O definitions. More recent developments in PLCs, DCSs and communications protocols have allowed named parameters and data structures to be passed between the various levels, greatly reducing the risk and documentation overhead involved.

Moreover, SCADA systems have been unable to derive the benefits of Object-oriented Software Development, namely:

• Less analysis effort – the functionality of each specified object is readily understood from its “real-world” equivalent.
• Enhanced maintainability – changes to a system component are limited to changes in the corresponding object.
• Simplified Design – each object and interaction is clearly expressible
• User Verification – a user without detailed software knowledge can understand the specification in terms of the required system
• Reusability – since an object is entirely encompassed by its defined interface, the software object becomes as reusable as the system component it represents.

In order to use Object-oriented (OO) software development techniques, a project must be able to follow these methods from Analysis through Design and finally to Implementation. Without a suitable Implementation platform, benefits of Object-oriented Analysis and Object-oriented Design are marginal and in some cases actually counter productive.

OAenterprise provides the Object-oriented Programming platform for SCADA system development, thus enabling the full OO life cycle and allowing all of the OO benefits to be realised. OAenterprise combines all of the functionality of a Supervisory Control System as an OO implementation platform (Object-oriented Plant Mimics, Alarm Systems, Historian) with Object-oriented Control Logic and Field I/O. All of the necessary CIM components are available in a control object allowing the full OOD to be implemented directly. OO prerequisites include:

• Object Classes
• Encapsulation
• Inheritance
• Aggregation

Object Classes

Object Classes are the key to an Object Oriented Implementation, they allows a class to be created which completely defines the data, functionality and visual expression of any instance of that class. Classes are far more powerful than simply copying a template, they allow changes to be made to the entire class at a single location and all instances are implicitly updated - there is no possibility of simply forgetting to update an instance.

Encapsulation

Object-oriented Design techniques produce a minimal set of interfaces to completely define a class (and therefore each instance). By removing the exact instance from the definition, Encapsulation ensures that:

• Design can focus on small, manageable parts of the system
• Implementation can be broken into independent pieces - scaling up a project is manageable
• Mimics, properties, alarms, history all come pre-configured for a newly created object.
• Testing can be comprehensive and isolated to a small part of the system
• Logic updates only affect objects of that class, reworking other parts of the system is not necessary - rework testing is not necessary.
• Class reuse - external dependencies are minimised enabling reuse of the defined components.

Inheritance

Object Classes can themselves be defined in terms of other, more general classes. This allows slight differences in the interface or logic to be accommodated without redesigning the base class properties.

As with object classes, any modifications to the base class that apply to the new, inherited class are automatically propagated into each derived object.

Aggregation

Multiple classes (including inherited classes) can be combined into a single new class. All interfaces and control logic of each aggregated class become available in the new class.

Summary

OAenterprise is the only Automation and Process Control solution that can provide all requisite Object-oriented features to enable a complete OO development.

OAenterprise is a powerful, scaleable, distributed, Object-Based Control software system for manufacturing and industrial process control that is used for systems requiring one or more of the following:

• SCADA
• Real time process control
• Supervisory control
• Historisation
• Intelligent alarming.

Example - Bicycle Class

To illustrate these points, let us begin an example, the bicycle (initially we can assume the standard type, 2 wheels, 1 person, etc). In simple terms, a bicycle is a form of transport powered by the legs (an input variable), steered by the handle bars (an input variable) and resulting in velocity (an output variable, dependant upon peddling power and steering plus internal properties and control logic). In an Object-oriented system we call this the Bicycle Class.

Any particular bicycle we create using this Bicycle Class is known as an Instance; an Instance is said to be Derived from a Bicycle. Each Instance would have the same logic, variables, mimic, limits and history - with possibly different properties (weight, wheel size, gearing, etc).

Bicycle Class Encapsulation

In this example, the class interfaces have been completely defined by input power and direction plus resulting velocity.

To fully implement the Bicycle Class we would also have to consider other factors such as:

• Visual representation (mimics). What should a bicycle look like on a screen? Which variables and properties should be displayed and how?
• Limits (alarms). What is a safe lower speed before the bicycle falls over or upper speed before it risks harm to the rider? What is a safe turning angle at the current speed? How should the system react to any breach of the limit conditions? How should an operator be informed?
• Progress (historian). Record all historical data, calculate energy expended by the rider and route taken.

Bicycle Inheritance

There is another machine, a TandemBicycle - very similar to a Bicycle but with 2 sources of power each with differing levels of input. Steering input and velocity output are unchanged.

An Inherited Class, TandemBicycle has all of the logic, variables, mimics and history of a Bicycle Class, except that there are two sources of power which need to be combined in the control logic.

It would be possible to simply extend the original Bicycle to include an optional second power source, but this would affect all existing Bicycle objects and potentially require retesting of each one. With OO design and implementation it is enough to inherit a new class with slightly different attributes and control logic.

Should any modification be required to the underlying Bicycle power to velocity calculations, all Tandem Bicycle objects would automatically receive the updated logic.

Bicycle Aggregation

Our control system also has a MotorBike - very similar to a Bicycle but the power source is greatly increased and is itself defined by a Motor Class. The Motor Class has been implemented by another engineer, but has an input variable throttle and output variable (power) as well as many local variables such as fuel level, oil level, temperature, etc.

Aggregation of a Bicycle Class and a Motor Class results in the MotorBike Class. Since the Bicycle input variable Power is now fully defined by the Motor output variable Power, it is no longer an interface for the MotorBike Class. Instead, the inputs for Motor and outputs for Bike are combined to produce the new Class. Properties for the new machine are also combined - the new properties are weight, wheel size, gearing, fuel level, oil level, temperature, etc.

If we refine our Bicycle or Motor logic, the Aggregate Class, MotorBike will automatically have the new refinements.