iFIX Whitepaper

The Fix SCADA Database

01/06/98
Al Chisholm
Scope

This paper will discuss the basic functionality, design and use of the iFIX SCADA
Process Database. We will discuss how it relates to the other parts of iFIX and will
attempt to create a good high level understanding of the system so as to allow the end
user to make the best possible use of the system.

What it does for the User

The FIX Process Database holds the various function blocks that can be defined using the
FIX Database Manager. The main purpose of these function blocks is

• To map device specific I/O Addresses into meaningful tag names

• To take 'raw' data from a device or PLC as provided by a FIX I/O Driver or OPC
Server and scale it to a meaningful real world value
• To monitor and report alarm conditions on these values
• To perform other higher level processing functions using this data such as PID
control and Statistical Monitoring.

Raw device data is typically addressed as a register number such as 40001. It is difficult
for an operator to remember the meaning of the data in this register. Associating that data
with a TAG such as BOILER5_TEMP makes it easier for the operator as well as the
engineer building displays, recipes and trends to know the meaning of the data. In
addition to the identifying TAG, the database function blocks also include descriptive
information in the form of a user defined 40 character string.

Typically, devices provide 'raw' integer data from an A/D converter or a single digital bit
from a contact input. The analog data might be in the form of a value from 0 to 1023
however it might actually represent a 'real world' value such as a level, pressure, flow or
temperature. In this case the job of the operator as well as the various system applications
is greatly simplified if this value is converted from its raw form into a scaled real world
value. While the individual applications could each be made to do this conversion, such
an approach would be highly inefficient and error prone. The database function blocks
provide a single place to store the information needed to do this conversion and also
provide built in code to perform the conversion automatically.

It is often necessary to monitor analog or digital values for various alarm conditions.
Usually the devices which gather this raw data do not have this capability. Logic could be
built into an operator display via a scripting language such as VBA to perform such
monitoring however such an approach does not scale well in a distributed environment.
Also in such a design the alarm monitoring might take place only when the display
containing the logic was active. Function blocks in the FIX SCADA Database provide a
single central place to define alarm parameters for each tag and thus allow analog and
digital values to be easily and efficiently and monitored as part of the system background
processing. These centrally detected alarm conditions can then be recorded, reported and
routed in sophisticated ways to the rest of the system.

Various different types of function blocks in the system perform a variety of specific
operations which can be combined together into more complex functions. For example
the database includes numerous special purpose function blocks including some simple
sequencing logic in the form of the PROGRAM block. It includes some basic statistical
processing in the Statistical Data block. It provides some basic relational database
interfaces via the SQL Data and SQL Trigger blocks.

Note that in some cases, higher level devices may provide data that is already scaled,
processed and alarmed. If an OPC Server is available for such a system then it can
provide data directly to the iFIX Displays. In such cases there is no need to create
'duplicate tags' in the SCADA database. Thus the creation of a FIX SCADA database is
not a requirement when applying iFIX. Rather, the FIX SCADA Database is a valuable
service which need only be used when it is required by the particular end user
application.

How it is built and Maintained

The user creates a SCADA Database using the Database Manager Program which
provides a spreadsheet like view of the function blocks. In larger systems, the SCADA
database can be distributed over many individual processing nodes for better performance
and reliability. Note that these node specific databases can be created and administered
remotely and independently. That is, a user running the Database Manager on node A can
create and maintain SCADA databases on any number of nodes throughout his plant. It
also means that changes made in a particular database on a particular node need only be
made that one time in that one place.

Database Builder
Application

SCADA Database SCADA Database SCADA Database

on Node B on Node C on Node D

I/O I/O I/O

Applications can get access to the values in the databases on nodes throughout the system
using our distributed database access system which is described in another Whitepaper.

One key design feature of this system is that each database function block is defined in
only one place. Any application needing access to that data will read the data as needed
from that single source. No changes are required elsewhere in the system when a function
block is added and no additional overhead is created on other nodes as tags are added to a
particular node. This results in a system with exceptionally easy maintenance and strong
scalability.

Advanced Topics

Now that you understand the basics as described above, we can go into a few additional
features.

Blocks in the database can be scanned on a timed basis down to a rate of every 50ms.
Slower blocks such as minute or hour based blocks can be synchronized to the system
clock - for example you can always run a particular function block at 5 minutes past the
hour. Blocks can also be 'exception based' meaning that they will be executed only when
the I/O Driver reports that the raw value has changed. This can lead to tremendous
improvements in efficiency in systems with large tag counts and slow data rates.

Each function block in the database can be assigned to a Security Area which can be used
to restrict access to fields within that block to specific users. The FIX Security System is
described in a separate Whitepaper.

Each function block in the database that generates alarms can send those alarms to
various named destinations throughout a distributed system. The FIX Alarm System is
described in detail in a separate Whitepaper.

There are several system toolkits which can be used in combination with the FIX
SCADA database.

The Easy Database Access (EDA) toolkit allows a user to write his own applications in
C, C++ or VB and allows access to all of the data and fields within the SCADA database
function blocks on either local or remote nodes.

The Loadable Block Toolkit (BTK) allows a programmer to create new types of function
blocks to add to the list of standard blocks in the system. These blocks are created as
stand alone DLLs and do not require any changes to the existing system even though,
from the end users point of view, they integrate seamlessly with the rest of the built in
function blocks.

The System Extension Toolkit (STK) allows a programmer to replace the entire FIX
SCADA Database system including the lower level database access functions with a
design of his own. In the past, this kit has been most appropriate for large OEMs who
already have some fo rm of logic or control system and want to leverage the higher level
FIX applications. It allowed them to 'wrap' their data in a way that made it 'look like' FIX
Data. In newer applications, OPC frequently provides this capability in a more standard
way.

The Advanced I/O Driver Toolkit (ASDK) allows a programmer to create new device
specific I/O Drivers or OPC Servers and is discussed in detail in a separate Whitepaper.

iFIX also provides DDE and ODBC access to the data.

And finally, the FIX SCADA Database has both OPC Server capability which allows 3rd
party OPC Clients to read and write data fields within its function blocks and also OPC
Client capability which allows it to read raw data from 3rd party OPC Servers.

Applications

EDA DDE ODBC OPC

FIX SCADA DATABASE

Where it Fits

The FIX SCADA Database resides in memory on computers that are performing data
acquisition. It lives 'below' the FIX Distributed Database Access System and 'above' the
FIX I/O Driver system.
 Applications

Distributed
Database Access

'Local'
Database Access

The FIX SCADA

Database

Scan, Alarm and

Control (SAC)

FIX I/O Drivers

How it Works

For those who want to know some of the technical details, here is how the FIX SCADA
Database works.

The database is essentially a number of shared memory resident flat files; one for each
type of function block. Access to these shared areas is controlled by a module of the FIX
system code called Local Database Access. The entire image (all of the flat files) can be
saved to disk by user command at any time for backup and can be reloaded at system
startup or any other time under user command.

Local Database Access is actually a set of DLLs; one for each function block type, which
understands how to read and write the fields in that type of record. New function blocks
can be added by creating new DLLs without affecting the existing code or data structures.

At runtime a program called SAC (Scan Alarm and Control) scans the database and
schedules execution of the function blocks. The polled scheduling is done via a very
efficient linked list algorithm. Most of SAC is pretty 'generic'. The function block
specific runtime code is also located in DLLs; one for each function block. Again this
allows new function blocks to be added easily.
Some function blocks talk to Hardware Devices via the I/O Driver Interface. This
interface (called the 'NIO' interface) is provided by all FIX I/O Drivers. The basic idea is
that this interface always provides generic read/write analog and read/write digital
functions. This allows hundreds of different I/O Drivers to be simply plugged into the
system without changes to any of the other system internals. The I/O Architecture is
discussed in a separate Whitepaper.

Summary

• The FIX SCADA Database is Distributed - the function blocks and logic only exist,
only need be maintained and only consume resources in one place.
• The FIX SCADA Database is Component Based - The function blocks themselves are
extensible components and the entire SCADA engine is a replaceable component.
• The FIX SCADA Database is device independent - the same set of function blocks
can be used with hundreds of different types of physical I/O.
• The FIX SCADA Database is extensible and scalable - new function blocks can be
added. New or existing vendor specific databases can be added. Additional nodes can
be added. All without affecting the systems already in place.
• The FIX SCADA Database can be exception based. The logic can be set up to
execute only when the data changes leading to unmatched efficiency of execution.