Here you will find answers to the following questions:
Process control systems are identified by the fact that, " ... they take into account the entirety of all tasks (functions) that are required for controlling a process. ... in addition to the functions of the respective automatic procedures that are established in its programming, all decision processes of the person who monitors the process are also taken into account, including his resulting direct intervention in the process". [J. Heidepriem, Prozessrechnertechnik und Automatisierungssysteme, Volume 1& 2, Oldenburgverlag, 2001]
This definition clarifies that the person plays an important role in a process control system, in contrast to the control or automation technology. While control or automation technology deals exclusively with technically known and logical contexts, a process control system takes into account the decisions of a person (facility operator). Process control systems are further distinguished by the fact that the data basis to which the person or automatic procedure reacts is constantly changing and cannot be restored. Chapter 9 Computer Validation distinguishes between monitoring systems and transaction-based systems. According to this, process control systems are to be classified as monitoring systems.
Process control systems offer a multitude of possible uses. The scope of function of process control systems is just as multifarious. This chapter deals with general functions and problems (chapter 3 How to use process control systems).
Process control systems are used to monitor and control the production process across facility components. In order to correctly classify the tasks of a process control system, a few further definitions of terms are required:
- Process Data Acquisition system (PDA)
PDA systems record various measurable values from production. These can be the temperature flow, counter statuses, revolutions, etc. Depending on the relevance of the value, a relationship can be established between the measuring point (sensor, balance, etc.) and the order or batch number.
- Enterprise Resource Planing Systems (ERP)
ERP systems belong to the company management levels with strategic, commercial tasks with a longer-term time frame. The most widely used ERP system is SAP.
- Laboratory Information Management Systems (LIMS)
LIMS, like MES, belong to the plant management levels. They are used to record and document quality-related values e.g. for inspection of incoming goods or so-called In-Process Controls (IPC) for the process running time.
- Manufacturing Execution Systems (MES)
MES belong to the plant management level. They produce the connection between the process control level and the company management level. On the one hand, this includes functions such as production planning, requirements determination within a mid-term time frame and, on the other hand, it includes extensive search options for batch tracing or fault analysis.
- Batch systems
Batch systems map procedural sequences in the process control system. They manage formulations which produce the connection between the manufacturers instructions from the ERP system and the technical equipment of the process facility. Likewise, the MES provides parameters based on the raw materials.
- Process visualisation and control
These systems show the current status of each individual element of the technical equipment and make it possible to control these elements. A drive can, for example, be activated or deactivated, and at the same time the operating hours of the drive and the storage temperatures of heavily burdened gear parts can be recorded.
The limits shown here between the systems are in no way to be viewed as strict limits. They can fluctuate significantly depending on the company size, plant organisation and the systems used.
2 Features of process control systems
Process control systems differ essentially through the hardware used. While some manufacturers use their own hardware components which are specially tailored to the software supplied (system-specific hardware), other manufacturers use commercially available, usually widely used and proven hardware components by other manufacturers. In the latter case, so-called PLC-based process control systems are usually used, which use PLC as process-near components (PNC). However, display and operating components (DOC) of the process control systems, i.e. servers and client stations are becoming increasingly similar, as industry PCs (IPC) are increasingly being used with the usual operating systems. Widespread technologies such as the Ethernet with TCP/IP protocol are also becoming increasingly important for networks. Proprietary protocols are becoming rarer. Both variants have their pros and cons, which are illustrated below.
System-specific hardware with its tailored software offers uniform parameterisation and programming tools for project planners and for users alike. However, such systems require special knowledge which is not usually very widespread. From a GMP perspective, these systems offer the advantages that all programming and parameterisation changes are logged, provided they have an Audit Trail. It may be a disadvantage that such systems do not support all current interfaces. As the example of the facility configuration shows figure 4.K-2, this can play an important role.
PLC-based process control systems, on the other hand, use widely available programmable logic controls (PLC). The use of the equipment is tested in a wide range of areas. The purchase price and the spare parts storage are relatively inexpensive. In addition, spare parts availability and procurement are guaranteed for years (> 10 years). Special knowledge is not usually necessary as PLC exists in every company at machine level and the knowledge is thus already available. Often, the opinion prevails that PLCs and PCs exchange unstructured data and thus parameterisation of the process control system is not possible from PC level. Through the increasing efficiency of PLCs in recent years, the PLCs can be incorporated as "real" process control system components, i.e. the process control system can be parameterised completely from the PC level (the difference between programming and paramterisation is dealt with in more detail in chapter 5 Qualification of process control systems). From a GMP perspective, changing programmes is associated with a higher organisational effort in the context of change management (see chapter 9 Computer Validation).
The use of industry suitable PCs is also relatively inexpensive in terms of purchase costs. Here, the availability and procurement of spare parts is more problematic. The short innovation cycles, both for hardware components and operating systems, mean that in some cases, individual components are no longer available after five years. As the operating systems and programming languages used in the company are often also used in other areas, the company has sufficient technical knowledge available and specialist knowledge is not required. However, for exactly this reason, the following note is particularly important.
Please note: Although the hardware and network components of EDP workstations and PCS workstations are increasingly similar, you are urgently discouraged from operating process control components as EDP components. For as already shown, process control systems are monitoring systems for constantly changing process variables. Failure of a hardware component or network connection leads to a not reconstructible loss of information, in contrast to transaction-based systems. This means:
- The process bus is to be separated from an EDP network.
- Servers should be accommodated near the facility. Dependencies between network components of superordinate departments, e.g. backbones of IT departments and multi-site components are to be avoided.
- Software not released by the process control system vendor should not be installed, or only by agreement with the vendor.
3 How to use process control systems
Ideally, the process control system should form a standardised interface along the entire production process (value added chain), both for users and for superordinate systems.
To this end, the PCS records the status of all equipment involved in the process (drives, valves, controllers, etc.) and all kinds of measuring values (levels, temperatures, pressures, humidity, flows, masses, conductivity, etc.) and, possibly, machine runtimes and operating cycles for the next maintenance work.
This recorded information is
- forwarded to superordinate systems,
- displayed to the user,
- evaluated by automatically running processing steps.
Forwarding to superordinate system is generally used for logging and archiving and for production planning. This task is the same as that of a PDA system.
Through the visualisation of the facility, the operator obtains an overview of the entire facility. The process images are structured so that an overview of the facility can be obtained as quickly as possible. Therefore, the level of detail of the process images varies significantly.
It is crucial that the user can make decisions based on the visualised information and can intervene in the production process. This corresponds to process visualisation and control.
The control of automatically running processing steps is undertaken by batch systems, for example. A batch system offers the possibility of merging defined basic functions into a prescription, so that the entire process can take place automatically. Automatic can also mean that the process control system issues operator instructions, e.g. via radio terminals and waits for inputs by the facility operator. Furthermore, this forms the basis for later batch tracking. [DIN EN61512-1 Chargenorientierte Fahrweise] and [Applying S88, Batch Control from a User`s Perspective, Jim Parshall and Larry Lamb, www.isa.org] are recommended as further literature on batch-based procedures.
4 Carrying out a process control system project
In most cases, this will be the extension or introduction of a process control system in an existing facility, which has often developed over many years, i.e. a heterogeneous control or automation landscape will already be in place.
At control level, this can be simple control cabinets or PLC-controlled facility parts, DOS computer-based controls through to PC-based visualisations (Microsoft Windows, Linux, Unix).
Often, the introduction of a PCS project is motivated by the fact that the process data is to be forwarded directly to the company management level or that all data is to be stored centrally. This means it is necessary to provide PCS interfaces to ERP systems (SAP), MES systems and/or LIMS systems. Figure 4.K-2 shows an example of a facility configuration.
As the example of a facility configuration shows, not only production-like operating areas can be affected in a company by the introduction of a PCS, but also operating areas such as storage, requirements planning and laboratory.
This heterogeneous system landscape usually requires a number of interfaces to be realised. Usually, these interfaces are technically challenging, but can easily be realised by interface converters that are available on the market. However, this does not give any information on whether or not the information that can be acquired from the exchanged data is sufficient. This problem usually occurs if autarkic facility component controls (e.g. reactors, coaters, batch production facilities) are to be connected, which contain formulation administrations that are specific to the facility vendor. In such cases, practice has shown that it is best to replace facility component controls and integrate the functionalities directly into the control system.
This procedure is particularly advantageous in the GMP environment:
- Maintenance of the formulations is simplified as they are compiled and maintained on the PC and not in the control. This means that the formulations are included in the data backup concept. A further positive side-effect is that modern process control systems provide version tracking of the formulations so that all changes are documented in full.
- Operation of the facility parts is thus subject to access authorisations through the user administration of the process control system, or dual maintenance of the user administration is dispensed with, whose organisational costs are not to be underestimated. Operating actions by users are thus entered in the central audit trail and can then be easily copied into the batch documentation.
By contrast, this procedure is to be avoided for machines that are configured and do not allow for any manual intervention during production (e.g. packaging lines, tablet presses, etc.). This is because the runtimes for such machine controls are optimised by the manufacturers, and this cannot be achieved with process control components. Checking of the packaging material and product feed should, however, be monitored by the PCS.
5 Qualification of process control systems
At this stage, it must first be stipulated that, through the use of a process control system, the process equipment must be considered as a "computerised system" in accordance with chapter 9 Computer Validation and is therefore subject to computer validation as described in detail in chapter 9 Computer Validation.
However, an often underestimated yet very important requirement for successful and timely processing of such a project is of a non-technical nature. The close collaboration of the facility operator and process control system supplier over the entire project runtime is particularly important. This is not only because the process control system ultimately has to be validated by the facility operator together with the technical facilities and procedure, but also to achieve the highest possible acceptance of the system by the users.
For qualification of process control systems, it is important to distinguish between programming and parameterisation. Programming means software modules are compiled in a programming language, and are then translated. The logic is saved in the source code and cannot be changed during the running time. As described in chapter 9 Computer Validation, this is individual software which must be qualified in the context of the project.
Parameterisation means that a standard software system, in this case the process control system, is configured specific to the application (see chapter 9 Computer Validation). In this case, it is sufficient to document the version used and, if relevant, carry out a supplier audit.
From a GMP perspective, parameterisation of a standard software product is recommended. However, in many cases this is not possible or is not desired for plant organisation reasons. In particular, process equipment that has developed over many years often contains technical and organisational features which make it necessary to supplement the selected process control system with modules or entire applications. Examples of this are container management or software for interfaces to upstream or downstream programmes/machines, which were developed by the facility operator himself. Interfaces to current systems, such as SAP or standardised PDA interfaces can be parameterised in modern process control systems.
To achieve the best possible qualification documentation (see page 10), the following points should be taken into consideration during the technical specifications phase:
- Programme modules, or functions and functional units should be defined and named.
- On the basis of these defined modules, etc. the structure of the documentation of the process control system should be drafted.
- Change management and versioning should be defined.
According to experience, this is initially a painstaking undertaking which takes some time and does not initially indicate any visible project progress. Given the usually tight schedule, this frequently leads to intense discussions between the project team and the QM-/validation managers. However, this pays for itself many times over during the course of the project. (Author's note: Unfortunately, nobody notices as the subject of documentation barely stands out any more.)
In this way, a good basis both for the compilation of the specifications and test plans at module level, and for the documentation and testing schedules for IQ, OQ and PQ phases can be created at the start of the DQ phase.
Once the required technical specifications are completed, the agreed qualification documents, i.e. specifications and test plans for the individual modules, must be compiled and released during the DQ phase. After implementation, i.e. programming or parameterisation, the test plans must be worked through and the modules must be released during IQ. Ideally, this is carried out in several stages in the presence of a representative of the facility operator. Each of these appointments can be seen as part of the FAT. This procedure ensures that the facility operator's employees become familiar with the PCS at an early stage and can indicate that processes can be designed in an ergonomically improved manner.
The qualification documentation to be compiled should be established at the latest as part of the technical specifications compilation, i.e. very early in the DQ phase. This must, of course, agree with the facility operator's validation protocol, if already defined therein. The persons/functions who will release the individual documents should also be established. This depends on the composition of the project team and the plant hierarchy (see below.).
Usually these specifications are based on theoretical requirements, so that it must be checked if this can be implemented as such in practice. This applies both for the specifications and test plans at module level and for the documentation and testing schedules for IQ, OQ and PQ.
The following reasons could speak in favour of deviation from the theoretical requirements:
- The software structure requires a deeper nested documentation.
- Parallel work by several employees must be divided across several documents, both for the compilation of the software and also in the further qualification phases.
- The schedule provides for parts being started earlier so that release must also take place correspondingly early.
- Resources that must release documents are only available to a limited extent
- For a large software module, different knowledge is required, meaning that it is advisable to split this software module into several work packages
- To avoid repetitions, requirements that relate to several modules are to be grouped together in a separate document to ensure that the documentation can be maintained
The last point has a certain explosiveness: During the project phases, i.e. from DQ to OQ/PQ, the documentation is compiled and thus has a foreseeable end. However, it is not usually taken into account that this documentation must be adapted across the entire life cycle of the facility if changes are made. This means that if the same content is contained in several documents, all these documents must be adapted and released again in a new version. However, parts of the text can be easily overlooked and the documentation will thus no longer be coherent.
The level of detail of the contents of the documents varies and is directed towards different groups of people/functions. Experience shows that this not only depends on the type of document, but also on the group of people involved. This depends on the size of the project and on the level of detail of the requirements, e.g. in the form of user requirements, but also on the size of the company of the facility operator.
Finally page 10 contains a few more questions that must be asked from time to time at the end of the technical specifications phase, e.g. with final acceptance of the IQ or OQ, and whose answers should be reviewed. The questions may appear to some to be trivial or even unnecessary, but experience has shown that reviewing these questions has helped develop a clear and uniform vision by all those involved, both of software structures and of documentation structures, across all qualification phases.
Are the responsibilities for the release of documents and software modules regulated in the technical specifications?
Are functionalities, interfaces, applications and software modules defined, named and clearly separated from each other in the technical specifications? Is there a diagram that contains the above-mentioned elements and roughly illustrates the dependencies/links?
Are the interfaces between the standard software system and individual software known?
Can the above-mentioned elements be mapped in the documentation structure?
Can the defined documents be compiled on time by the persons involved? Can the defined documents be checked on time by the persons involved? Can the defined documents be approved on time by the persons involved?
Is the change management process defined?
Is there a definition of which version number must be increased for which changes?
How are the documents distributed?
Are those involved familiar with the project documentation?
For more information and examples of qualification documentation, see chapter 9 Computer Validation.
Good qualification documentation means that the entire documentation is clearly structured and oriented to the target groups. Even if the documentation is viewed by investigators, and contributes essentially to qualification, the target groups are nonetheless all the roles of the plant employees, such as operating staff, maintenance staff, plant managers, and employees of suppliers as well as project managers and programmers, i.e. the documentation must fully and completely reflect the installed process control system for the corresponding target group.
Process control systems are used to monitor and control the production process across facility parts. A distinction can be made between system-specific and mostly PLC-based hardware, which have different advantages and disadvantages. The challenge when introducing a PCS is the many interfaces that must be integrated, which must be taken into account for project execution, qualification and documentation. Solution approaches for this problem are illustrated.