GE iFix - Scheduled Task - Architectural Patterns

Summary

iFix is a SCADA software used in industrial application to write the supervisory applications and sometimes simple process control(http://www.gefanuc.com/as_en/products_solutions/hmi_scada/products/proficy_ifix.html)

In these kind of application, sometimes (...very often) you need to write code for delivering background processing, event-management, implementing watch-dog, storing report informations and so on..

Scenario

There are different features in iFix which could be leveraged but all of them are based on the "concept" of schedule.

An schedule is like an event for form-based applications and could be on timely bases, or triggered by a real world event (ie an alarm, a tag treeshold passed, etc.)

An schedule is implemented through VBA script (in iFIx v4.0)

The schedule could be hosted by different iFix modules (I'm considering a complex iFix deploy with Terminal Server)

• iFix Workspace (on users sessions)
• iFix Workspace (on a dedicated protected session)
• iFix Background Server

iFix Background Server is a dedicated host tailored for background processing because it's like and iFix Workspace lacking of all user interface features so that the process footprint is very light.

We could think to an iFix Workspace like a Windows Form application, and iFix Background Server like a Windows Service.

The development of background processing in iFix is very hard and challenging due to iFix architecture.

Both iFix Workspace and iFix Background Server use Microsoft VBA as a script languages platform development and execution.

VBA is very easy to use so that people which hasn't good programming skill could write iFix application but that's also a BIG drawback when server code has to be delivered!

VBA has been created to delivery macro functionalities to Word/Excel not to write server application and the engine is for single threaded.

This mean that each event has to be singly processed by the hosting iFix process, so possibily issues could arise:

• Memory Leaks due to COM object (each object must be explicity deallocated with Set x = Nothing)
• DB Connection management
• Performance on each I/O operation (ie DB). If a query needs 2 sec to be completed, no more scripts could be processed
• Exception Management

To avoid this problem you need to decouple the iFix hosting process from the event management scripts.

Architectural Pattern

The interaction betwen the VBA scripts and iFix is done through COM objects which exposes iFix functionalities. So you could create and external application in .Net and through interop leverage the iFix COM objects.

The requirement is that the external application is deployed in the same machines where iFix is running

COM+

• Creates a .Net library component and register it in COM+
• Implements a method for each event management script using iFix COM objects (ie EDA)
• When the script is raised from an iFix host (Workspace or Background Server), from the VBA code invoke the .Net method.
• The .Net method should be asynchrounous and must use the .Net threading pool to complete the event management. In this way the method completed immediately, enabling the the iFix host to continuee the event management.

External Agent

• Creates a .Net Win32 service which will be executed on the same machine of iFix
• Creates a library component proxy to send message to the Win32 agent
• This component could be a .Net component which send data using different kind of queue (msmq, sql server 2005 broker, etc...)
• A VBA custom function to send message to .Net component in an easier way (SQL Server tables, files, etc..)
• When the script is raised from an iFix host (Workspace or Background Server), from the VBA a message will be sent to the agent which will be asynchrously processed
• In this solution, comparing it to the COM+ approach, it's not possibile to send COM object as parameters to the external hosts! So the COM+ approach it's the better one.