The short answer
GE iFIX
iFIX is one of the oldest SCADA products still in wide use, descended from FIX32 in the Intellution era and now sold under the GE Vernova Proficy name, and it runs a large installed base of water and wastewater systems built from the late 1990s onward. Its model is a SCADA node that holds a process database of blocks, analog and digital inputs and outputs, alarms, calculations, and more, fed by I/O drivers, with pictures displayed on the SCADA node or on view clients, history in the companion Proficy Historian, and scripting in Visual Basic for Applications. Redundancy is a pair of SCADA nodes with enhanced failover, and it is licensed by the number of database points and the number of clients. A system that has been running for twenty years works, and the questions on site are the software version against the operating system, the driver in use, the failover state, and whether anyone has the picture and database backups.
Key points
- A SCADA node with a process database of blocks; I/O drivers feed the database; pictures display it.
- View clients on the network and web clients through the companion products; licensed by points and clients.
- History in the Proficy Historian; alarms and events to a database through the standard logging.
- Redundancy through enhanced failover between two SCADA nodes with synchronized databases.
- Scripting in Visual Basic for Applications inside pictures; a maintenance risk when overused.
Architecture
| Element | Notes |
|---|---|
| SCADA node | Runs the process database and the drivers; the server of the system |
| Process database | Blocks of many types chained together: an analog input block, an alarm block, a calculation block; each block is a point |
| I/O drivers | Driver products per controller family and protocol; the current industrial gateway server driver covers most; older systems run legacy drivers |
| Pictures | Graphics files with animations bound to database tags; edited in the workspace |
| View clients | Network nodes that display pictures from a SCADA node without their own database |
| Web clients | Browser access through the companion web products; editions vary by version |
| Historian | Proficy Historian, a separate product that collects from the SCADA node |
| Failover | Two SCADA nodes with database synchronization; clients switch to the active node |
The process database
Everything in iFIX flows through the database: a driver writes a value into an input block, the block scales and alarms it, a chain of blocks can calculate or delay or output, and pictures and history read the blocks. The database manager is where the tags live, the block types define what a tag can do, and the scan time on each block sets how often it is processed. A system that behaves strangely often has a block off scan, a chain broken by a deleted block, or a database that differs between the failover pair. The database export, a text file of every block, is the backup and the comparison tool.
Versions and the operating system
An iFIX system is tied to its version, and the version is tied to the operating systems it supports. Installed systems run every version from the last two decades, some on operating systems long out of support, because upgrading iFIX means upgrading the server, the drivers, the historian, and often the pictures. The plan for such a system is a supported version on supported servers, converted pictures and database, and a test period on a parallel system; the risk of not planning it is a server that cannot be replaced when its hardware fails.
Scripting
Pictures can carry Visual Basic for Applications code, and many installed systems carry a great deal of it: navigation, popups, calculations, and report triggers that live in scripts rather than in the database or the platform features. It works until the picture is converted, the operating system changes, or the author leaves. New work puts logic in the controller and the database where it can; scripts that must exist are documented and kept in the engineering library as exports.
On a site visit
- 1
Version and operating system
The iFIX version, the driver version, and the operating system; against the support lists.
- 2
Failover state
Which node is active, whether the databases are synchronized, and the last switchover.
- 3
Database
An export of the database, compared with the last one in the engineering library.
- 4
Drivers
Driver status and error counters per device; a device with errors is failing.
- 5
Backups
Pictures, database export, driver configuration, historian configuration, and the license keys, in the library and offline.
Frequently asked questions
- Is iFIX still developed?
- It continues under the GE Vernova Proficy name with periodic releases and support for current operating systems. Check the lifecycle status of the installed version and of the drivers before planning around it.
- The pictures run slowly on the new workstation.
- Legacy picture formats, heavy scripting, and driver polling settings all affect picture performance; a picture with hundreds of animations on a fast scan is slow on any workstation. Profile the picture and the database scan times before blaming the hardware.
- How do I move history to a new historian?
- The Proficy Historian has migration tools between its own versions; moving to a different historian product is an export and import project that keeps the raw data and loses the vendor-specific configuration. Plan it with the retention requirements in view.
- Can I replace one node of the failover pair at a time?
- Yes, and it is the normal way to upgrade hardware: fail over to one node, rebuild the other, synchronize, and repeat. The database and pictures must match on both, and the drivers must be configured identically.
Related topics
- SCADA ServersWhat the servers in a SCADA system do and what a utility should expect of them: the I/O, alarm, historian, and client roles, physical versus virtual, redundancy, sizing, placement, backup, patching, licensing, and monitoring.
- SCADA ClientsThe workstations, browsers, and mobile devices operators use to see and control the system: thick, thin, web, and mobile clients, roles and permissions, where control is allowed from, workstation design, session policy, licensing, and failover behavior.
- Historian ArchitectureHow process history is collected, stored, and served: the collector, the archive, and the client layers, where the historian sits relative to SCADA and the DMZ, single-server and tiered designs for a utility, the store-and-forward buffer that survives outages, and the sizing that decides how many years fit on a disk.
- Server FailureHow SCADA servers fail and what to do when one does: failure modes from a full disk to a dead hypervisor host, what the plant experiences with and without redundancy, the recovery sequence from restore to alarm verification, and the monitoring that warns.
- Patch ManagementApplying updates to SCADA servers and clients without breaking the plant: vendor qualification, a monthly cycle with a test system, priority from the exposed edge inward, backups and rollback, emergency patches, and handling software that cannot be patched.
- Other PlatformsThe SCADA and HMI products a water utility may meet beyond the common ones: Siemens WinCC, distributed control systems, independent SCADA products, hosted lift station monitoring, and open-source tools, and the questions that decide whether one belongs.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.