Validation - 11​.10 (a)

Validation - 11.10 (a)

21 CFR Part 11:

“(a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.”

AVEVA Software Verification

FDA-audited industries are required to properly validate their applications. The software world uses the term validation and verification interchangeably. However, according to the document “General Principals of Software Validation; Final Guidance for Industry and FDA Staff”, AVEVA provides software that is verified.

The partial definition of software verification in the FDA document is:

“Software verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase. Software verification looks for consistency, completeness, and correctness of the software and its supporting documentation, as it is being developed […] “

All AVEVA Software products are verified and tested extensively prior to their respective release. Furthermore, AVEVA’s commitment to a sophisticated software development life cycle ensures reliable quality.

Software validation is for a finished device or system hence it does not apply to Off-the-Shelf configurable software like AVEVA Software products. Validation applies to systems created using the configurable AVEVA Software products.

System Validation

Validation of the applications and systems created using the AVEVA Software products is entirely in the responsibility of the FDA-audited industry. Creating and maintaining a validated system state is simplified by features and functionality provided by the AVEVA Software products.

For example, AVEVA Batch Management includes batch sequencing management features with a SFC (Sequential Flow Chart) as the main interface to monitor the batch progress as depicted in Figure 2.

The software supports ISA S88.01 standards to communicate with the underlying control system. The AVEVA Batch Management capability of managing the sequence of unit procedures, operations and phases in a proper and consistent order has been thoroughly tested; as well as the proper usage of the phase control, status bits, parameter download, etc. These standard capabilities are part of the off-the-shelf product and do not need validation on their own.

Figure 2 - SFC used for batch monitoring

AVEVA Batch Management also provides a set of ActiveX and .NET controls that can be used in InTouch views or ArchestrA graphics. These controls provide capabilities for communicating with the Batch server to view or enter parameters, enter credentials, and to acknowledge entry or exit of phases, etc.

They can be used with minimal or no configuration in the customer’s HMI and their functions do not need to be validated on their own. An example of standard popup for user authentication is depicted in Figure 3.

Figure 3 - Standard user authentication popup

The configuration of AVEVA Batch Management also allows defining the data types and verifies that the specific entry corresponds to the specified data type as illustrated in Figure 4 where an error popup warns the operator about the bad entry. Once the value is entered correctly in the standard AVEVA Batch Management field, it is not necessary to validate that the entry populates the right AVEVA Batch Management phase parameter as this is a standard product feature. It is only necessary to verify that the AVEVA Batch Management phase (including all phase parameters) is correctly connected to the control system phase instance.

Figure 4 - Data type validation

Verification that the AVEVA Batch Management system is connected properly to each individual control system phase is critical and is facilitated by the AVEVA Batch Management Phase Logic tool. AVEVA Batch Management Phase Logic is an engineering tool available from the AVEVA Batch Management Environment Display that allows running a phase for testing purposes outside of a batch and test the handshake interface between the Batch Manager and the control system phase logic. The Phase Logic tool is depicted in Figure 5; it contains buttons to test all standard control and status bits for the phase as well as a simple interface to view and modify the phase parameters. Once the phases are individually tested with this interface, they can be used in a recipe with a high level of confidence that the connectivity with the control system is working and that the handshake is properly implemented in the control system.

Figure 5 - Phase Logic Tool

Another customer task is to verify that the recipes are properly defined, behave as expected in a real environment and meet the process and security requirements. Although the security features are enabled centrally from the Security Editor, the phase entry/exit signature requirements are defined in the recipe, for each individual transition and phase.

Important: Only the Ask () functions in expressions - as shown below in Figure 6 and Figure 7 - provide support for DoneBy/CheckBy. Other transitions with regular expressions do not support these CFR21 Part 11 support functions.

Figure 6 - Signature requirements for a recipe transition

Figure 7 - Signature requirements for a recipe phase

The recipe flow may be verified offline using the AVEVA Batch Management Simulator. It is recommended to use the AVEVA Batch Management Simulator at the design phase to verify that the phases are correctly defined and modular enough to be reused in different recipes.

The AVEVA Batch Management configuration uses a concept of process class to represent a certain type of unit. All units in a process share the same phase definitions; this improves consistency and reduces the development effort as the phases are defined only once for a given process. Similarly, defining tags at the process level rather than at the unit level ensures consistency between the units of a given process. It removes the need to test a recipe with all units of a given process as long as the control system (PLC/DCS) code is consistent between units. Note that the consistency of PLC/DCS code between units is outside of AVEVA Batch Management scope; AVEVA Batch Management boundary is the interface with the Control System.

AVEVA Batch Management extends the ISA S88.01 standards to represent transfer classes. Phases can be defined on these classes and several instances of transfer equipment with the same capabilities can be instantiated as connections; this has similar impact on the development and testing activities as explained for the processes and units.

In order to reduce the possible risk of tag linking errors, it is recommended to use the AVEVA Batch Management model import utility in the IDE. This generates the AVEVA Batch Management templates and objects automatically with their associated parameters. The templates may then be edited to define the desired IO assignment of the tags, using the AVEVA System Platform feature of Auto I/O Assignment. This feature generates the attributes extensions to the Control System’s tags automatically, based on the parameter name. It enforces standardization of the tag name in the Control system. Although this is not a requirement - each tag could be individually assigned for each phase instance - using the Auto I/O Assignment feature removes the risk of error in custom scripting for tag assignment.

The individual connection of the parameters and control/status bits to the control system still need to be verified for each individual phase since they depend on different additional factors like the quality of the network connection to the individual Control Systems running the actual phases in the plant.

Decisions to reduce testing scope are completely within the boundaries of currently accepted industry methodology. GAMP 5 specifically promotes the use of a risk-based approach to validation, including testing. Capabilities within the AVEVA products like those mentioned above may provide a strong case of reduced testing when properly employed within a custom-configured system.