GE iFix: FDS (FixDataSystems) & Performances

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)

iFix run over Microsoft platform and it's programmed using VBA and a set of custom ActiveX which provide access to all SCADA functionalities.

FixDataSystem ActiveX (abbreviated to FDS) is one of the iFix components (ie EDA, etc.) which provides access to the PLCs data.

We found a huge performance lack in FDS in an high-reliable iFix deployment.

From the previous image (a typical high-reliable configuration):

• There is a Front-End iFix with Terminal Server installed. The server is in charge:
• To provide the user interface to operators
• To process all VBA scripts (the scripts are executed in the contexts of an iFix workspace)
• The Back-End iFix servers which are in charge:
• Communication management,  I mean getting and sending data within PLCs (Level 1)
• Providing high-Level data access to iFix Terminal Server.
• Active-Node is the node currently connected to iFix Terminal Server
• Stand-By Node is the hot backup and it will be connected to iFix Terminal in case of failure of currently Active-Node.

It's very important to understand that VBA scripts are executed in iFix Terminal Server so FDS ActiveX must create a remote connection to the Active-Node.

With this configuration the performance is very lacking and if you have a lot of tags to be initialized you've to wait tens of seconds which is unacceptable in every operating conditions.

Anyway FDS ActiveX is very fast when it's used locally by the Active-Node (also keep in mind that you can have only 1-instance of FDS for a workspace).

So in the following diagram it's depicted our approach based on COM+ (implemented in .Net using Enterprise Services) which leverage the performance of FDS when it's invoked locally:

As you can see the idea is to create a .Net wrapper (TiQ .Net FDS) to FDS which could be invoked using COM+ (which has good performance for remote calls):

• The wrapper (TiQ .NET FDS) is executed in iFix Active-Node
• The VBA scripts execute by iFix Workspaces call TiQ.Net FDS using a remote COM+ component (in this way the wrapper is also exposed using a COM interface accordingly to VBA requirement on interface).

Well that's not so easy because to to guarantee high-performance:

• We've used hash-tables bypassing FDS COM collection providing access to DataItems.
• Net thread-pooling is used to optimize the threads usage during internal blocking call.
• .Net Object Pooling with Just-In-Time activation is required to guarantee that only 1 instance of FDS is created.

I will not go into implementation details because it's out-of-scope and..., well it's company know-how and there is a little bit of magic from my colleagues in TiQ-Industrial.

Spatial Memory

From Wikipedia:

In cognitive psychology and neuroscience, spatial memory is the part of memory responsible for recording information about one's environment and its spatial orientation. For example, a person's spatial memory is required in order to navigate around a familiar city, just as a rat's spatial memory is needed to learn the location of food at the end of a maze. It is often argued that a person's, or an animal's, spatial memories are summarised in a cognitive map.

This is very important stuff to consider when you design User Interface interaction.

Think to your bench when you drop a pen or a note. When you need it, you'll find it without thinking (and if you're right-hand usually you organize stuff on your right). That's spatial memory!

When you design user interactions, all state-driven command (navigation tree, state information, ..-) should be kept on the right side of your screen (well that's not true for left-handed people and you should have a configuration option).

So why in every application the commands are on the left?

Because when the developers begin the implementation, first they think to the commands menu and menu-bar plumbing them on the left (...you read from left 2 right) and after that he will think to the "application meat", that will fit the right area.

The application will leverage "the dev way of thinking" not the spatial memory.

nLite & Deployment

Being crazy trying to install a new HP ML 150, I've found a nice tool that could be very useful for large deployment.

Take a look to:

http://www.nliteos.com/download.html

The tool will build an iso image/CD/DVD with all the setup files to deploy an OS, giving the options to choose SP, Hot-Fixes, additional drivers, etc. to your deployment CD also for unattended setup.

I need it to create a Win2003 Setup CD for HP ML 150 with the SATA drivers.

It's not possibile to setup the ML150 with a standard Win2003 because the HD aren't recognized!