In the business world, justification professionals belonging to the pharmaceutical manufacturing sector, lack real and practical development experience in relation to the development and use of programmable logic controller (plc) application software. Due to the ever-expanding functionality of todays process control systems, these are no longer simple control panel implementation. To take advantage of the productivity enhancement tools available in todays process control packages, it is necessary to develop a clear and complete specification document, which contains software functional requirements. This must be done before configuring any process control system. Though learning and configuring software packages have become easier, justification of automation systems is still an uphill task.
Learning and configuring todays software packages have become easier than ever before. With respect to the control system integration or system supplier, justification professionals belonging to the pharmaceutical manufacturing sector typically are not trained in Current Good Manufacturing Practices (cGMP) or Good X Practice (GxP) (relating to FDA compliance where x can mean clinical, laboratory, manufacturing, pharmaceutical and others), nor do they possess the solid justification operational experience required for FDA compliance. The gap between supplier and pharmaceutical users is obvious, and the problems caused by this gap are numerous.
This led to Good Automation Manufacturing Practice (GAMP), which addresses these issues, as it considers the overall automation system justification methodology. Yet, even GAMP is more of a guideline rather than practical development of the PLC development cycle and practices. Therefore, the emphasis is on Good Engineering Practice (GEP), which ensures that the engineering or software development methodology generates deliverables to support the requirement for qualification or justification in the pharmaceutical industry. Hence, the control system integrator or system supplier should plan a software development strategy, which is the key to a successful compliant system.
Todays control software packages use a variety of programming languages like function blocks, ladder logic, sequential function charts, etc. These software programmes must be clearly documented and easy to update to improve the plants productivity over its expected life. Thus, the process, control system engineers and production engineers can easily develop a simple and universal system of matrix-based documentation jointly.
Such a methodology of documentation has been created, and has been applied to several batch control plants. The most recent ones include several multi-recipe and multi-product speciality chemical plants. This concept of software documentation, which involves mainly the sequence control and safety interlock logic functions, has proven to be an effective way to transfer the process technology and operational know-how of an existing pilot scale operation to a new fully automated, large-scale production plant.
Function of GMP in process plant
Most process plants consist of a combination of batch and continuous control functions. To fully document these functions, the following four components must be defined:
- Analogue (continuous) regulatory control loops (eg, the level control loop of a distillation column)
- Digital (discrete) control devices (eg, control of motors, on/off valves, etc)
- Interlock logic, which defines the relative status of two or more devices to ensure the safe operation of the plant
- Sequence control logic, which is the basis for batch process control Actions are initiated in response to trigger events such as time, special operating conditions, modification of product recipes, etc. Sequences may be fixed or variable, and may depend on the status of the process or on external factors like market demand for different product grades.
Analogue loops and digital devices can be defined using a simple list (or database) of tag numbers, point descriptions, I/O address, display information, measurement ranges, etc. Interlock logic can be documented.
FDA Submissive Justification
"Establishing documented evidence, which provides a high degree of assurance that a specific process will consistently produce a product, meeting its pre-determined specifications and quality attributes", clearly identifies FDAs intention on justification. GxPs including Good Testing Practice, Good Documentation Practice and Good Engineering Practice provide general principles and guidelines on justification requirements. Especially, the GAMP Guide for justification of Automated Systems in pharmaceutical manufacturing provides a detailed systematic approach on automation system justification but lacks several details on the programming side.
Nonetheless, compliance policy guides are in place making it very clear that PLC code is an electronic record, In addition, parts of 21 CFR 11 can be translated such that PLC code is an electronic record. The following examples of FDA warning letters explain the position the FDA is taking on this issue.
"Failure to establish and maintain documented procedures to control and verify the design of the device in order to ensure that specified design requirements are met as specified in 21CFR 820(a)(1). For example, there are no procedures for review of source codes in design controls for software justification, and there is no assurance that all the lines and possibilities in the source code are executed at least once."
"Failure to maintain adequate device master records 21CFR 820 1811. For example, your firm did not maintain or refer to the location of the software engineering change records and software test procedures."
Therefore, procedures to control and verify the design process from PLC-based control systems to firmware; to the PLC application source code must be addressed and specified clearly. SCADA packages, which often connect to PLCs, count as configurable-software packages. Thus, the system integrator or system supplier, in both cases, should undergo auditing in conjunction with their application of GxPs and GAMPs relative to entire PLC/SCADA system.
The system integrator or system supplier often has to provide sufficient documentary records to ensure that the user accepts and validates the system. Use of integrator or supplier document simplifies the overall justification process. For example, the suppliers own inspection procedures and documentation may meet the requirements of the normal installation (IQ) activities if the user reviews and approves them. Correspondingly, the suppliers development methods, quality procedures and documents may supplement or replace some normal operational qualification (OQ) activities.
Documents required for IQ and OQ are included in most compliance policy guidelines. The essential part of IQ and OQ include testing procedures. The system integrator or supplier provides two IQ testing documents named IQ1: FAT and IQ2: SAT. In IQ1 test, all hardware l/Os test on a signal simulator; software l/Os undergo verification and testing simultaneously. IQ2 proceeds once all site instruments have been calibrated and loop-checked with all electrical components that are ready. These two tests should happen in dry run.
The software OQ is the systematic and formally documented verification indicating that a customer built application control software performs its proper function as specified in the functional specification. For the control system, this means supplying evidence that all functions individually and as - a whole are operating in accordance with the specification. OQ test can also separate into OQ1 FAT and OQ2: SAT OQ1 takes place where the target process is simulated. OQ1happens in an approach from cell to unit, to process area, module by module, or function block by function block. OQ2 takes place in an operational environment and software OQ is always the essential subset of the overall system OQ.
To develop PLC software, the following three documents must be in place:
- Control System Design Standard (CSDS), which is basically, detailed Standard Operating Procedure (SOPs) for control system design; User Requirement Specification (URS) and Functional Specification (FS)
- The User Requirement Specification is critical and the end-user should take responsibility for its contents by reviewing and approving the document. In practice, the system integrators engineer may write most of URS with the assistance from the end-user. But, final acceptance by the user is essential and mandatory
- The Functional Specification should describe what the system should perform under given conditions, but not how. The supplier normally writes the FS or Control Narrative according to Process Design Report. It is very important that the end user reviews and approves the FS to authorize the detailed design, development and building of the system, in practice, the FS is continually updated and refined as the detail design process develops
The above two documents normally require a significant amount of time to interface with the end-user to create, develop and finalise. Both documents are GMP-controlled and compliant with all GMP requirements.
Control system design standard
One of the system integrator in-house standards, CSDS includes detailed SOPs of control system design, which is frequently beyond the control of the end-user.
|1 • 2 • Next|
|Posted : 8/24/2005|