For those still not well acquainted with ‘that thing called scada’ – Adroit Technologies, local developer of advanced, 32-bit open scada systems (and a founding member of the Proudly South African campaign) discusses the fundamentals of scada functionality and design with regard to instrumentation and control.
Computer-based supervisory control and data acquisition (scada) or human machine interface (HMI) systems continue to gain in popularity with process-centric companies who harness its monitoring and control capabilities to gain competitive advantage and operational efficiencies.
Although scada systems generally perform only supervisory control and data acquisition functions, they are usually required to operate 24 hours per day 365 days per year. This differentiates them to a large extent from office applications like word processors and spreadsheets where a crash at worst means a reboot and a coffee break for the user. If a scada system crashes it often means a loss of safety, production or both. Moreover, any data presented to the user by a scada system must be both accurate and on time.
The fact that each industry-sector and plant has unique requirements means that flexible configuration is very near the top in terms of requirements. With a sufficiently flexible scada/MMI product it is possible for system-integrators and power end-users to engineer or configure a custom solution from a packaged product. Basic scada functionality harnesses technology to display, automate, supervise, monitor and control plant processes. Although functionality varies from vendor-to-vendor, most will provide these essential core components:
Realtime data storage is at the heart of any scada system. The term database is often used in this regard, but this terminology can be a little misleading, since the word database has come to be accepted for long-term historical storage of data in a much broader context. The scada offers instead, a realtime database to describe instantaneous values of all configured plant input/output (I/O) signals or tags. In addition, the realtime database will usually include any derived tags used to contain results of calculations performed on process plant variables. Key attributes of any realtime scada database are:
1. Capacity - the limit (if any) on the total number of points that can be configured into the realtime database.
2. Performance - how efficient is the run-time performance of the realtime database. Speaking typically in throughput in the order of thousands of changes in data per second, the delay associated with storing or retrieving a value should be as short as possible.
3. Configurability - once a scada system has started up and is monitoring and controlling a process, it is inconvenient to have to shut it down to make minor modifications to the system configuration. Suitably authorised personnel should be able to do this configuration while the plant is on-line.
4. Extensibility - as well as containing the basic I/O tags like, for example, analog and digital records that are built-in by the scada vendor, a realtime database should be able to accommodate record structures defined by a system integrator or power end-user to represent key entities relevant to his process. Any such user defined tag structures should enjoy the same benefits, in terms of being scannable, loggable, alarmable, displayable, etc, as do the basic built-in tag types.
5. Networkability - realtime scada databases should be locatable on potentially any computer node in a networked environment. A corollary of this requirement is that it must be possible to distribute a large database across as many or as few nodes as is appropriate to the user. This distributed nature should in no way complicate the configuration, nor compromise the performance of other scada/HMI functions.
Scanning refers to the capability of interchanging data, in a bi-directional fashion with one or more fronted devices such as programmable logic controllers (PLCs). Such a crucial function is obviously of prime importance in determining the pedigree of a scada system. A checklist of key scanning attributes is:
1. Performance - typically thousands of I/O points per second are scanned into the realtime database. It is vital for any scada system with a large number of I/O signals to be scanned as fast as possible for purposes of efficiency and realtime data integrity.
2. Medium independence - different PLCs use different communications media ranging from simple RS232/RS422 serial communications, through proprietary schemes, to Ethernet (802.3) and other network protocols. It is important that a scada system does not make any assumptions about the physical network nor protocol used to communicate with a PLC. Rather, this knowledge should be restricted to a scada component known loosely as a 'driver'. In this way the scada/HMI system is able to accommodate new PLC devices as and when they come on to the market.
3. Concurrency - with the increasing use of multiple serial and network-based communication links, it is important that a scada system can do genuine concurrent scanning. It is no good having an expensive architecture comprising multiple communication links only to have all communications serialised by the scanning subsystem, thereby causing a sever system 'bottleneck'.
4. Redundancy - communication links are a notoriously common failure point in a plant environment. It is crucial, therefore, that the scada system's PLC driver as well as supporting a configurable number of retries and automatic recovery after communications failure makes use of one of the important capabilities found in most PLCs, namely a secondary communication port. If the primary communication link fails, the driver should seamlessly transfer over to the secondary channel without adversely affecting operation of the rest of the scada system.
5. Flexibility - it is not uncommon for new PLCs to be commissioned on to an otherwise operational system. Ideally a new driver should be loadable on-line without necessitating a shutdown and consequent loss of integrity and production.
Logging records the historical process variable values as opposed to the instantaneous ones. There are two different types of historical information that need to be logged: plant or scada system events, and periodic recording of key process variable values. Scada event logging capabilities are:
1. High capacity - process plants typically generate large numbers of events over a period of time. Any event logging system should be configurable up to a very high capacity, and be able to be archived off for long-term storage before any events are overwritten.
2. Displayable - the days of reams and reams of hardcopy printout have disappeared. It is therefore important that any event logging system integrates smoothly with the rest of the HMI by being flexibly displayable.
3. Filterable - with such a vast amount of information residing in a typical event log, it is vital that the information can be filtered both by time and content. An example of time filtering would be events between last Sunday night and Monday morning. An example of content filtering would be all High Priority plant alarms.
The second aspect of historical information storage is that of process plant data values. A plant data value logging subsystem should be:
1. Space-efficient - although usually only a subset of the realtime database is historically logged, the period for which data is retained is often very long. This means that the amount of storage consumed can escalate rapidly. A key issue here is how much storage is used up per value logged, and what data compression techniques are employed.
2. Speed - with potentially large volumes of data being logged fairly regularly, it is important that system performance is not adversely impacted. A key issue in this regard is what form of disk caching is utilised. Another place where performance is important is during data retrieval, and the issue here is what search strategies have been implemented, in order to provide fast retrieval times.
3. Flexibility - any value in the realtime database should be configurable as an historically stored process variable. In addition, it should be possible to stop or start logging of any individual point, based on an event such as, for example, a motor trip, threshold level, etc.
4. Open - any data value should be able to be logged to an open database such as SQL Server, Oracle, MSAccess. This allows for a flexible knowledge-centric control strategy.
5. Transparency - data values stored away historically should be transparently accessible to the rest of the system. One example of this would be an HMI trend window showing data values from the recent past. As the current time is reached on the time axis, trend data sourcing should switch from historical to instantaneous data values without any visual indication that this is the case.
Alarming functionality on scada MMI systems must include the ability to do special alarm processing when a tag goes into or out of user-definable alarm states. Key attributes of an alarm subsystem are:
1. Flexibility - alarm strategy is an area where there is probably the least degree of standardisation or agreement between different scada MMI users. As a consequence the alarm subsystem needs to be highly flexible. It should be possible for users to define as many of their own alarm criteria as necessary, and then to alarm tags according to these alarm criteria.
2. Annunciation features - ideally there should be several different ways of annunciating alarm occurrences, ranging from local and network-wide alarm lists, through printers, audible devices, multimedia interfaces, to electronic mail and pager messaging interfaces.
3. Display integration - smooth integration with graphical plant displays is necessary so that it becomes possible to animate a graphical object on a plant display in a variety of ways according to alarm occurrence. It should furthermore be possible to navigate directly from an entry in an alarm list to a graphic display giving a detailed view of the plant item responsible for causing the alarm.
Calculations require a general-purpose and integrated calculation capability. Specifically, it should be possible to configure any number of derived result tags in the realtime database. In this way it is possible to generate values that are not readily available in the front-end device, such as totalised values, efficiencies, etc. Derived tags should be:
1. Efficient - it is important that they do not waste CPU power by needlessly calculating when none of their component inputs have changed in value.
2. Arbitrarily complex - derived tags should be the result of combining any number of other tags, including derived tags in an arbitrarily complex mathematical or logical expression.
3. Mathematical - a rich set of commonly used standard mathematical functions should be available. Examples of such mathematical functions are sin, cos, log, exp, etc. A method of integrating to provide counters should also be available.
4. Seamless - any derived tags should enjoy the same level of seamless integration with the rest of the system that conventional tags do. Specifically, it should be as easy to log, display, alarm, and scan out derived tags as other tags.
Interactive displays
The user interface (HMI) portion of a scada/HMI system is a collection of interactive, graphical displays that are used to monitor, control and otherwise interact with both the process and the system. Increasingly, user interfaces offer multimedia sound and video capabilities as well as visual graphics.
Key attributes of scada/HMI are:
1. Security - by means of the HMI, system users are able to wield enormous power over the process, such as stopping and starting drives, conveyors, pumps, acknowledging alarms, etc. It is important at any point in time, that a suitably authorised user can be held accountable for his actions. Consequently a multilevel privilege hierarchy encompassing users, passwords, protected resources and actions needs to be in place to guarantee the necessary level of accountability.
2. Consistency - above all an HMI needs to be consistent, meaning that users are able to develop a reliable conceptual model of how the user interface works. As well as providing a user-friendly 'look and feel', consistency means ease-of-use, less errors on the part of the user, and therefore improved productivity.
3. Configurable - different users will inevitably have different visual models of their process. This means that user interface displays must be fully configurable using object-oriented CAD-like drawing tools, including third-party drawing packages, image scanners, etc. Object-orientation is a much over-used phrase these days. However, in the context of scada/HMIs, what it means is that the user should be able to create visual representations of plant items and animate these visual objects in response to changes in process variables, using a wide variety of built-in animation methods. Animated visual objects should be capable of being copied from one display to another, combined into higher-level entities, inserted into organisation-wide symbol libraries, etc.
4. Networkablity - just as realtime scada databases need to be locatable on any computer node in a networked environment, so too must user interface displays. In this way, it should be possible, for example, that an engineer or manager in his office can call up live plant displays for those sections of the process that concern him. Such transparent networkability also means that suitably authorised operators on one plant section are able to view displays from other plant sections, controlled by different computer nodes in a distributed environment.
For more information contact Adroit Technologies, 011 781 3513, [email protected], www.adroit.co.za
| Tel: | +27 11 658 8100 |
| Fax: | +27 11 658 8101 |
| Email: | [email protected] |
| www: | www.adroit.co.za |
| Articles: | More information and articles about Adroit Technologies |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version