Smartlogic

ולידציה -Testing and HW/SW Type and Maturity

ולידציה -Testing and HW/SW Type and Maturity – GAMP

Process automation systems generally comprise several elements. Categorizing these elements according to those described in GAMP 4 can assist in targeting testing and validation effort.

Some functional elements may be fully contained within the system standard packages or firmware (FW), while others may require different degrees of configuration or customization. In general, the greater the degree of customization, the greater the scope of testing required.

For example, if an item of the process equipment is to be controlled, the User may have several options for implementing the process control system functional element.

:Typical Test Phases for Process Automation Systems

Complex control exists as single, mature 'equipment level' library module, where functions can be selected/ deselected and  setup parameters entered

For example, sterilizer module with selectable cycle types

Application Life Cycle Testing: selection of functions, setup parameters

:Typical Test Phases

FAT and /or

SAT

IQ/OQ/PQ of process equipment

Complex control built up from mature, interlinked 'device level' library modules, which must have correct parameters entered

For example, sterilizer control, built up from valve, motor, PID, set-point program modules.

Application Life Cycle Testing: selection and linking of modules functions to give correct functionality, setup parameters

:Typical Test Phases

FAT

SAT

IQ/OQ/PQ of process equipment

Complex control built up from application specific modules, themselves built up from low-level library modules, or from simple coded steps within a predefined structure.

For example, sterilizer control configured in ladder logic

Application Life Cycle Testing: functionality of custom coded modules, selection and linking of modules functions to give correct functionality, setup parameters

:Typical Test Phases

Module test

FAT

SAT

IQ/OQ/PQ of process equipment

Complex control custom added

For example, sterilizer control coded in C++

Application Life Cycle Testing: functionality of custom coded modules, interaction between custom coded modules, selection and linking of modules functions to give correct functionality,setup parameters.

:Typical Test Phases

Module test

Module integration test

FAT

SAT

IQ/OQ/PQ of process equipment

:Notes

The suggested test phases listed above are typical only; they may be increased or decreased to reflect the complexity of the application, and the impact on product quality, patient safety and data integrity

The above assumes mature, 'industry proven' library modules. If these are created specifically for the application, then they need to be treated as custom code

Smartlogic expertise in validation of current and new systems to meet the most rigid requirements of the FDA and CFR protocols.

ולידציה – GAMP – Test Example – part 2

Good Automated Manufacturing Practice (GAMP) – Test Example

Testing Process Automation Systems

This article cover  the second part of  our  Good Automated Manufacturing Practice (GAMP) test example. This part will cover  the typical test phases for supplier's application SW Module Testing, supplier's Module Integration Testing and the supplier's Integration Testing – cont'd

                     Typical Test Phases

 Typical test phases for a complex process automation system. This example assumes that the system is configured by a Supplier and delivered to site after a FAT. Test system can also be configured by the system integrator or by the User. In this case, the same coverage is required, but the test phasing and location may be different.

The User and Supplier should work together to develop an overall approach to testing that reflects the risk assessment output and ensures adequate test coverage of the functionality, whilst avoiding unnecessary repeated tests.

: Typical Test Phases for Process Automation Systems

 Supplier's Application SW Module Testing

Done at the Supplier's premises after the module has been placed under configuration control and code reviewed. Before system integration. Module testing generally covers: Module data handling

 Interfaces to other modules

 Operator interfaces

 Module functionality Failure paths and response to fault conditions should be included within the tests

Supplier's Module Integration Testing

Done at the Supplier's premises.After individual module have been tested and integrated into a single unit.Before full system integration

Module integration testing generally covers: Correct operation of Interfaces between modules

Failure paths and response to fault conditions should be included within the tests

Supplier's Integration Testing –

Done at the Supplier's premises.After module testing, and before the User is invited to witness the FAT

Integration testing generally covers:

 HW

I/O interfaces

Operator interfaces

Interfaces to other equipment

System functionality

Data handling functions

Failure paths and response to fault conditions should be included within the tests

:HW tests typically include

·      Checking system build against approved HW specifications and drawings

·      Recording system components, version numbers (including SW versions) and capacities

·      Checking electrical supplies and grounding

Supplier's Integration Testing (cont'd) –

Checking correct power up of system components

Checking any self test/diagnostic information

Checking correct communication on standard interfaces

:I/O interface tests typically include

Exercising inputs and outputs to check correct configuration of ranges, alarms, etc.

:Operator interface tests typically include

System displays and navigation

Security and access controls

:Tests for interfaces to other equipment typically include

Checks of communications protocol setup

Checks that the required data can be transferred

Checks of actions in case of communications failure

Tests for system functionality typically include:

Monitoring functions

Alarm strategies

Control functions)control modules, equipment modules, procedural control(

Power failure and recovery

Component failure and redundancy

Performance checks

:Tests for system data handling typically include

Operator data entry

Data formatting and quality checks

Checks of calculated values

Checks of recipes

Checks of access to current process data, alarms and events )displays, alarm summaries, etc.(

Checks of access to historical process data, alarms and events )trends, reports, alarm histories, etc.(

Checks of audit trail functionality

Checks of data capacity and retention times

Checks of archive and restore

Checks of provisions for electronic signatures

Checks of disaster recovery procedures

End of  ולידציה – GAMP – Test Example – part 2