The FAT is the problem

By Ian Verhappen, Contributing Editor

TO TAKE advantage of fieldbus systems, users must effectively implement new work practices. This includes everyone from the start of the project through the commissioning and operations phases of the facility’s lifecycle. One item that remains to be resolved is the Factory Acceptance Test (FAT). This usually involves testing the functionality of the:

• Hardware, such as controllers, I/O modules, power supplies, terminations, and all the various system components.
• Logic, which includes forcing both analog and discrete inputs, and then watching the logic to be sure it performs/responds as expected.
• Operator displays and alarms, which are tested in conjunction with the forced logic and signals step above.

With a conventional analog system, these procedures have been in place for many years, and the tools, such as simulators, exist to perform all these tests. Of course, because the conventional system “ends” at the I/O assembly or possibly the marshalling cabinet and all field devices are simply current signals, it doesn’t matter whether each individual input device is actually a vortex meter or a turbine meter.

However, with fieldbus systems, the I/O is in the field device, and the field device is part of the network, so it does matter whether the digital signal in engineering units is coming from a turbine, vortex meter, or orifice plate. In addition, every fieldbus device is unique as described by its DD file, which adds another degree of complexity. Fortunately, control communications don’t use all the parameters defined by and available in a fieldbus device for control, so only those variables used for control—such as Process Variable (PV), Status, Tag, Engineering Units, and a few others—are necessary for the FAT.

As a result, it’s not easy to simulate the system logic in a fieldbus system, unless we bring in all the instruments. However, many new projects now have several thousand or even tens of thousands of fieldbus instruments, so bringing them all to the FAT is impractical. So what do we do?

Unfortunately, most control system vendors don’t have Foundation fieldbus (FF) FAT simulators yet. End users have asked control system vendors to develop integrated simulators, which can appear to the DCS controllers as real FF instruments. However, to get a good logic test—and to verify the function blocks and DD/comms work as required—the actual brand and model of the field device needs to be simulated. This can be a big order for the DCS vendors, especially because there are now more than 350 different registered FF devices, which are regularly updated/revised with new features and enhancements.

The only saving grace is that each of these devices has its new DD file posted on the Fieldbus Foundation’s website, and the host system can read it using the Capabilities File. Of course, the other part of the challenge is convincing the DCS suppliers to provide the same support to everyone’s devices, and not just to their own “in-house” brands.

However, not all the responsibility for the FAT should reside with the DCS suppliers. FF is a new technology that changes the way we work. End users need to revisit their expectations of a FAT and accept that not every “loop” needs to be tested. Instead, a statistically significant representative sample of the system needs to be verified to provide the confidence that the system as a whole will work as designed. Key/critical loops will have to be part of the tested subset, though “critical loop” still needs to be defined as well.

Because it’s not practical to bring all devices to the FAT, some users eliminate the logic test at the FAT, and do the logic tests with the real hardware at the Site Acceptance Test (SAT). This is when integration of the DCS with the plant and other systems tested, not the functionality of the control system. Obviously, testing logic at the SAT isn’t the best solution partly because it’s much more expensive to test at the end of the project.

The potential risk of not having adequate procedures and tools for conduction acceptance tests is that some end users may choose not to implement a fieldbus project until they’re able to get the full functionality for the complete lifecycle, including acceptance testing. Since installations of FF are growing fast, if you have an opinion or something to contribute relative to this subject, be you one of the “big boys” (Honeywell, Foxboro, Yokogawa, ABB, Emerson) or an end user, please share it with us via the e-mail address below, and I’ll be sure it’s shared in a future column.

I am moving to a new position with a vendor company, so this is my last Inside Fieldbus column. Thank you, readers, for making this column possible. Especially those of you who took the time to send me a note commenting about Inside Fieldbus. I look forward to working with you further in the future, from the other side of the fence.