Kepware OPC Server CSV
Read the full post over on our blog >>
Do you need to add a new visual programming environment (VPE) to your process control system?
Perhaps you want to upgrade a programmable logic controller (PLC) or connect multiple devices to a historian, e.g. OSI PI?
Well, the same process applies for each scenario – and the model is scalable.
Let’s find out more.
Connectivity and Historians
The automation industry, including pharmaceutical automation departments, has long used Open Productivity and Conductivity (OPC) to interconnect equipment/machines and systems.
Additionally, historians such as OSI Process Information (PI) are used in conjunction with OPC server systems to collect critical data for analysis and other valuable functions, e.g. configuring alarms, and GMP audit. OPC servers can also capture data as middleware between systems.
Nowadays, in our full-blown analytical world, we connect everything to some sort of graph, computer or smart device. Even in our homes, we have smart thermostats, smoke alarms, doorbells, cameras, electronic sockets and bulbs, to name but a few. And let’s not forget the interoperability with Alexa and Google. The interconnectivity capabilities are endless.
But how do we qualify these crucial elements, and what about all of the settings, parameters (or properties)?
And how do we test them?
Let’s take a look at the example Kepware project below.
How do we qualify a Kepware OPC Server and validate the system for use in a GMP environment?
Kepware is an OPC Server application that enables the seamless interconnectivity of various automation devices and sensors to a wide variety of digital solutions. It offers the stability, performance and security essential for industrial environments.
Kepware controls data access using channels (connections made using device drivers). The channels host devices (e.g. PLCs, sensors, hardware) in which tags (addresses) exist with which the server communicates. For example, to gather information from a Siemens S7-1200 PLC, we would create a Siemens channel that uses a driver to access the device. The device is then more specifically identified by its mode of connectivity (e.g. TCP/IP) and device specifics which determine individual accessible tags and link/logic tags defined at the Kepware level.
Our Process and Computer System Validation (CSV) Documentation
First, we look at the whole system requirements per the project charter and risk assessments. The Validation Project Plan (VPP) describes the purpose of the validation, the system under validation and activities to be undertaken. It details the acceptance criteria and lists deliverables and responsibilities. Risk Assessment (RA) management applies across the lifecycle for practical purposes and complies with Annex 11 and other mandatory controlling factors. The RA is a powerful tool and should be regularly updated.
Our validation process is structured and detailed using precise CSV lifecycle documentation.
One of our primary CSV lifecycle documents is the System Lifecycle Categorisation Assessment (SLCA). It helps us determine your system’s GxP compliance category (GMP, GLP, GCP, GDP), level of novelty, risk and complexity. And crucially for us CSV folks, we need to know the GAMP category, which determines the deliverables required to fulfil the qualification portion of the project. The SLCA document includes a system boundary diagram to avoid any confusion around project scope and interfaces.
The User Requirements Specification (URS) document is self-explanatory and defines the purpose and intended use of the system, key objectives for the project, and any applicable regulatory concerns. The URS feeds into the risk assessment.
We describe what the system does and how it works in the Functional Design Specification (FDS) document, including diagrams and parameter lists as required (for larger systems, expect to see Design Specification (DS) and FDS documents for each area or building). The FDS serves as a vital resource for testing and is also required if a system incident or outage occurs. Your engineers can use the document to troubleshoot and rebuild the system using a combination of backups and design/configuration specifications.
The Configuration Specification (CS) document details the configuration parameters and how these settings meet the requirements in the User Requirements Specification (URS). Below we take a closer look at how we develop Kepware CS.
The configuration and design specifications are then verified against the built system, and this is documented in the Installation and Operational Qualification Report (IOQR). We ensure that any prerequisites are met, diagrams are correct and that the system is hosted on a qualified platform.
The URS, FDS and Test Protocols are linked in the Requirements Traceability Matrix (RTM). This ensures that all requirements defined for the system are tested. An RTA is a tool for both the validation team, ensuring that requirements are not lost during the validation project and auditors to review the validation.
Finally, the Validation Summary Report (VSR) is precisely that – a summary of the steps carried out during the project, detailing any deviations (with reasons) from the Validation Project Plan (VP). The document also identifies any limitations or restrictions on use and describes any incidents and any outstanding and corrective actions.
