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.
Software documents
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.
Functional specification
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.
Nevertheless, an audit of the PLC control system integrator or system supplier is required to determine the level of quality and structural testing built into the standard product and to examine system quality. A good CSDS will provide the end-user a certain level of confidence about the justification expectation. The CSDS shall cover the design standard on instruments; device controls system controls, structure or software, standards approach or programming and the like.
Another area of CSDS includes the software structure and general programming standard. The importance of producing a CSDS is clear when a programmer has to reverse engineer the control functions of a system only from the several hundred lines of source code found in the controller itself. Certainly, anyone who has attempted such a task will agree that it is a frustrating exercise and difficult to completely understand the concepts behind the code. However, if the end-user knows that the system integrator has SOPs for software development methodology, and a justification programme, he will feel confident about the ability of the product to achieve its design requirements. As such, the PLC software structure layout should follow process order and data process. For example, the main tree in a code shows the order of data flow and the process area order as well. Regarding the detail code development, the IEC 61131-3 standard should serve as a reference. In practice, a good rule of the thumb is the development of reusable code wherever possible since this reduces large amounts of system programming and simplifies troubleshooting and justification effort.
Programming tools for justification
The following tools are used for programming a PLC in IEC 61131-3:
- Function Block Diagram (PBD) is a graphical language using defined function blocks from the system library or user-defined function blocks from the system library or user-defined library and writing them together on the screen to accomplish certain functions. There are two types of FBDs, where the predefined FBDs are developed by the programmer to accomplish a certain project- oriented function
- Ladder Diagram (LD) is the traditional method of representing logical equations and simple actions as if these are relay switches. LD and FBD may be freely mixed - Structured Text (ST) is a high-level structured text language similar to Pascal but more intuitive to the automation engineer
- Instruction List (IL) is a low level language that is highly effective for smaller applications or optimizing parts or an application
Plan of PLC application software
PLC application softwares strategy depends on the size of the target process and its complexity. The strategy referred to here is not for simple machine control with few devices, but rather a large size application with various functional process areas. First, all devices or control components are stand-alone based on their function. A typical classification in a plant comprises control valves, solenoid valves (2-way/3-way), On/Off valve, constant pump/motor variable speed pump/motor, variable speed pump/motor, conveyer (single direction/bi-direction) and others. The ladder logic should serve to programme the basic control function for each classified device, and this D should be packaged as a generic user-defined FBD named after each type of device. Also in FBD, there should be one separate section for mode control, programmed by using either LD or FBD.
The next step is to classify the process into functional areas. There is also a good time to define the software structure. Once process classification into areas/units/cells takes place, the programming on the process level may tart. The programming approach depends on the nature of the functions. If sequential controls are heavily involved, FC can be applied, otherwise FBD should be considered as a general way because it provides the programmer - who is not necessary knowledgeable about the process - a clear way to trace process, troubleshooting and more important justification.
Overall, the concept of using modular software blocks dominates application software development. The software modules/FBDs are the basic cell, and go together in a human readable hierarchy organisation. The work of troubleshooting, debugging, testing and justification can fit into different levels like device control level or process control level or system control level. This way a huge software development breaks down into modules and FBDs, sets up the foundation for the development, integration and testing. More important, it defines a clear path to software documentation.
Case study
Application of Micro PLCs in a packaging machine - The object passes through the machine and the weight is measured using weighing systems. After the scanner records necessary parameters like barcode, he object is transferred to the next stage by robotic controls. The speed of the drive is also controlled during the machine operation. The entire sequence of operations is controlled by the micro PLC.
The micro PLC can perform bit logic, compare, timer, counter, pulse output and simple math instructions. The micro PLCs are installed in the machine with some operator interface for indicating the reading of few parameters like low; pressure and temperature in case of pump controls. This enables the operator to take note of the readings for recording purpose as well as adjust the setpoint of critical parameters that affect the operation of the machine.
The logic for controlling the machine operations is written in the PLC using IEC 61131-3 standards. The programming steps are documented as per the requirements of the above standards to enable the operator to make changes, if required in the future. The programming approach depends on the nature of the functions. For example, for sequential controls, SFC should be applied, and the logic should be implemented; otherwise, FBD should be considered as a general way because it provides the programmer - who is not necessarily knowledgeable about the process - a clear way to trace process, troubleshooting and most important, justification.
Conclusion
Thus, using engineering or software development methodology that supports the requirements for qualification and compliance to GMP requirements, pharmaceutical manufacturers can achieve USFDA justification of automation systems. This will enable them to enter regulated markets.
