SCADA as you've never seen it before27 May 2011
A universal SCADA developed for nuclear power plants relies on a new approach to data management. By Aleksej Penkov and Zilvinas Binisevicius
Nuclear energy is a growth industry in Eastern Europe. Countries from the Russian Federation to the Baltic States, former Soviet Bloc nations, and beyond are building up generation capacity, to increase energy security and reduce carbon emissions. Projects include refurbishing older plants as well as constructing new ones.
Safety is a top priority, and Baltic Information Systems (BIS), based in Visaginas, Lithuania, helps meet this goal through specialized safety-related information technology (IT) for nuclear power facilities. The company’s flagship product, called BISMARC, is a universal SCADA (supervisory control and data acquisition) system that may be configured to fulfill almost any nuclear plant monitoring task. Released in 2009, BISMARC illustrates the evolution of process automation in the nuclear energy sector (and in the power generation industry as a whole) to embrace current technology and design concepts including Linux as a system platform, client/server architecture with communication via TCP/IP on Ethernet, and use of best-of-breed software components including off-the-shelf database management systems (DBMSs).
In fact, database technology was a primary focus in developing BISMARC. By its nature, SCADA is data driven (that’s the data acquisition part of the acronym, after all). Today’s state-of-the-art systems must monitor and control more complex processes and equipment than in the past, with a higher level of user flexibility in areas ranging from alarm configuration to graphical user interface. As a result, SCADA technology must capture, store, sort and analyze more data.
To meet the data management challenge, a BISMARC deployment actually includes two DBMSs: the eXtremeDB in-memory database system (IMDS) from database software developer McObject, which is integrated with real-time monitoring functions to provide the 'tag database' at the heart of SCADA processing; and PostgreSQL, a relational DBMS based on the SQL application programming interface (API), used for archiving and system provisioning.
A major BISMARC installation at the Smolensk Nuclear Power Plant in Russia illustrates BISMARC capabilities as well as the performance and data management challenges posed by real-time, safety-critical industrial control. The Smolensk facility – built in the 1980s, with output of some 20 billion KW hours annually – uses BISMARC to ensure safety and efficiency in nuclear waste disposal. For this deployment, engineers configured BISMARC’s distributed, redundant client/server architecture into two operator nodes and one administrator node, all running on Debian Linux and off-the-shelf x86 hardware. Linux has emerged as the leading operational platform in Europe’s nuclear energy industry, primarily because of its outstanding reliability but also for its familiarity (and the resulting ability to quickly address any issue and answer any question) and its efficiency on standard hardware. The “boxes” for the Smolensk deployment are Kontron ruggedized PCs, but they could be any x86 hardware.
At Smolensk, BISMARC is applied to four subsystems of radioactive waste processing:
• Preparation (vaporization, mixing, and other pre-storage processes)
• Transportation (movement of waste)
• Filling (filling containers for long term storage)
• Control (cleaning containers, weighing, radioactive contamination check, etc.)
The three BISMARC nodes receive a constant flow of information from a programmable logic controller (the RTP 2500 PLC from RTP Corp.) that controls the equipment used for these processes. On each node, eXtremeDB manages some 10,000 tags, or data points, that each represents an atomic unit of information such as a single input or output value. About 2,000 of the points describe the actual manufacturing process; others are system-reserved (for example, showing hardware resource usage). Other tags support special functions such as alarms. While the Smolensk plant uses BISMARC primarily for monitoring, the system enables operators to respond to alarms (configurable as blinking lights, sirens, etc.) by overriding the PLC and controlling machinery directly.
Tags consist of static and dynamic attributes. A static value is established at system startup and typically does not change. Dynamic value change constantly as the tag database receives updates from machinery via the PLC.
For example, assume there is a point with the ID "PLC_CPU_USAGE" that reflects the current CPU usage in the PLC. It is taken from the PLC and its dynamic value is a percentage in the range of zero to 100. The point also has the following static attributes:
1) Engineering units - percentage (the units by which data is measured. A different point might use different units, i.e. kilograms, meters, seconds, etc.)
2) Warning threshold - 70%
3) Alarm threshold - 90%
4) Description - "CPU USAGE"
5) Processing Frequency - once per second
The tag database residing on the three nodes at Smolensk is updated three times per second. Guaranteed maximum response time for the Smolensk installation is one second, while actual system response time is on the order of 100 milliseconds or less. This very fast performance facilitated by handling the point data entirely in memory, and by other eXtremeDB features, including an API that is navigational – that is, eXtremeDB API functions embedded in the code work on the database one record at a time, typically beginning with an index lookup, then iterating over the results, with application logic determining when to break the loop.
This type of API stands in marked contrast to the commonly used SQL database interface (which is also available for eXtremeDB). SQL provides a higher level of abstraction to programmers by separating database access language from the physical database implementation. This is convenient, but comes at the cost of more processing overhead, plus reliance on an optimizer that will consider different ways to carry out a given command. The result is slower and less predictable response times with SQL – compared to the fast and predictable performance of eXtremeDB’s navigational API.
As mentioned above, SQL does have a place in BISMARC. The system relies on a SQL DBMS, PostgreSQL, for data archiving and for provisioning the tag database upon startup. The “less real-time” performance of SQL is acceptable for the reporting and off-line analysis functions supported by this database – in fact, it may be preferred by analysts, due to the SQL language’s wide familiarity. PostgreSQL receives periodic snapshots of dynamic data from the tag database. It is also the site where static attributes can be configured. If the system is taken off-line, the eXtremeDB -based tag database is re-populated with static data from PostgreSQL upon re-start.
While BISMARC’s Linux support meets the needs of most European nuclear power producers, customer demand may one day lead to support additional embedded platforms, or to a 64-bit edition. We have based the design on software and hardware components that will support this future direction. Meanwhile, the existing product provides ample capacity to apply the SCADA technology to more processes and to larger installations than in current BISMARC deployments. As nuclear energy occupies a larger share of the energy portfolio in our European markets, BISMARC will be there to provide the highest degree of safety through efficient, reliable process monitoring and control.
Zilvinas Binisevicius is chief technical officer and Aleksej Penkov is senior software engineer at Baltic Information Systems (BIS), based in Visaginas, Lithuania.External weblinksNuclear Engineering International is not responsible for the content of external internet sites.More information on BIS More information on the eXtremeDB In Memory Database System