Computer system validation ? increasing supplier value 4

As this was a batch production plant, the functional specification was structured in line with the S88 model for batch automation.³ In this way, the specifications related directly to the configured elements in the system. The functional specification was supported by design specifications and project standards, where the latter defined the design and implementation principles that would be used on the project. Together, the functional and design specifications were sufficient to configure the system and, perhaps more importantly, provide the documents against which the system could be tested.
The structure of the functional specification is shown in Figure 3. Each document had its own number and revision history so that some parts of the specification could be reviewed and approved before other parts were complete. Basing the structure on the control levels defined within the S88 model results in the minimum of interaction between the documents, allowing parallel document development to be practical.

Figure 4

Also, everything about a particular level was defined in the one document. For example, the human interface aspects of control modules are defined along with other aspects of basic controls in the basic control definition document. The human interface definition covered the generic aspects of the operator interface, together with alarm management and security access. An extract from the basic control definition document is shown in Figure 4, where a motor symbol is defined.

Table 3

The traceability of requirements illustrated in Figure 2 includes the test specification. The requirements' trace process was made easier by generating a test case for each major section of the functional and design specifications so that there was a one-to-one correspondence between the FDS and the test cases. An extract from a test case document is shown in Table 3, where separate sign-off boxes are provided for internal tests and FATs. Where a particular test is not relevant to a group of tests then that box is shaded grey. Reaping the benefits
Our approach has been to make use of the work normally performed by the supplier to reduce the work that would otherwise be done on site. By simply ensuring that all test records are kept in a form that provides documented evidence that the system satisfies the requirements within the URS, we have added very little work for the supplier and opened up the opportunity for significant savings during the validation process. On one control system for an API manufacturing plant it was estimated that 11 weeks were removed from the site activities as a result of adopting this approach.
The validation master plan (VMP), IQ, OQ and PQ protocols still need to be produced, but parts of the IQ protocol and most of the OQ protocol can now be little more than lists that reference the test records from the FAT and SAT. It is often said that software does not break, it is already broken! The corollary to this is that the functionality provided by the software will not change when the system is installed on site unless the environment in which the software application is running changes; a simple justification for not repeating the tests.
The approach described in this article has been used on a number of pharmaceutical control system projects. Most of the purchasers have embraced the concept, including their validation staff, from the start. One major operating company actually provides document templates to their supplier so that all the documentation fits seamlessly into their document system. However, some have not had the courage to change their existing practice and so have missed the opportunity to reduce costs and get their products to market earlier. 
References
1. S. Haisman and P. So, "Factory Acceptance Testing", Proceedings of the ISPE 2000 Annual Meeting, San Diego, CA, USA (2000).
2. ISPE Gamp 4, GAMP Guide for Validation of Automated Systems, ISPE (Tampa, FL, USA, 2001).
3. ISA ANSI/ISA-S88.01, Batch Control, Part 1: Models and Terminology (Research Triangle Park, NC, USA,1995). Dr David James is principal engineer at Invensys Systems (UK) Ltd, UK.