Facility Monitoring Systems Validation: A Practical Approach 4

Module tests must be drawn up against the module specifications to ensure each module functions as stated. In the case of a panel, it is important to ask whether all the equipment has been installed, whether it has been wired correctly, and whether it meets all relevant standards.
With software, it is common for module specifications to be wider than the user requires. This allows modules to be reused on other projects. But it is important to be sure that the module, as specified, functions as stated. Again, the module specification is used to draw up a set of tests that verify that all functions have been completed and work as specified. This set of tests must include stress testing of the software to ensure that normal error conditions have been correctly handled.
After completion of module tests, the system must then be brought together, with another set of tests (Software Quality, SQ) applied to the completed system to ensure that it functions as detailed within the overall DS. Some companies do this on site, but if there is a problem, they then incur the added costs of staff working on site—and, typically, the design engineers are not on site. When it is difficult or impossible to build the system on the supplier’s site, simulators should be used.
Users may state that they wish to perform a Factory Acceptance Test (FAT). This is very common with delivery of machinery, but less so with FMS. The purpose of a FAT is for the user to be able to see how the system functions before allowing it to be delivered to site (this is also normally a payment stage). The simplest way to perform a FAT is to use the system’s Installation Qualification (IQ), Operational Qualification (OQ), and Production Qualification (PQ) documents and to state on the tests that simulators have been used as applicable or that the test is not possible. Again, if there are any test failures, it is far simpler—and less expensive—to solve problems on the supplier’s site than on the user’s.
After either SQ or FAT, the system is then shipped to site, installed, and commissioned. Once the system has been commissioned, I strongly recommend that user training be conducted before and after the final validation tests (IQ/OQ/PQ). There are two reaýons for this: There will inevitably be minor differences between what has been asked for in the URS and how the operators actually use the system. Performing training before IQ/OQ/PQ allows these small differences to be addressed under change control, with other documents being revised. Also, within IQ, there must be a test to confirm that users have been trained.
From this moment on, any change to the system must be very carefully considered. Change control must be applied. (In fact, change control should be applied before this stage, because any change may have an effect on specification documents and previous tests; in the extreme, a single, seemingly innocuous change can actually cause failure, in that a “bug” may be introduced.)