Here's another interesting question and answer that we thought we'd share on-line with a wider audience:
Q. We are developing a standard template to help in identifying and classifying PLCs into GAMP 5 categories. Could you please guide us to develop the right tool for the same.
A. The 'questions' to include are relatively simple and relate to the GAMP definitions of the categories, specifically on the context of PLCs - for example:
- Is the PLC (or parts of the software) used 'as is' with no modification or with simple changes to parameters e.g. run time, setpoint etc (typically with a machine or piece of equipment)? [Cat 3]
- Is the PLC (or parts of the software) reconfigured using standard graphical programming languages e.g. ladder logic, function blocks? [Cat 4]
- Is the PLC (or parts of the software) programmed e.g. are you writing code to achieve a function or operation that is not a standard feature of the PLC? [Cat 5]
You should also remember that it is quite likely that PLCs will contain a combination of Cat 3, 4 and 5 software and that your validation approach should reflect this.
However, the on-going problem you will have is two-fold:
1. PLC systems have a great deal of variation in the way they they are parametrized/configured/coded, and sometimes the lines are blurred eg. some 'configuration' can be as complex and error prone (risk-likelihood) as traditional coding. You can't possibly expect to come up with questions and guidance on every type of PLC out there.
2. You need to educate people on what all of these terms mean, in the context of the PLC you are looking at. This takes time and experience.
The only time I have seen this done successfully is when a company standardises on just one or two manufacturers PLCs and then they can provide a checklist / guidance based on the manufacturers specific software development techniques.
When developing the validation approach you will also have to take into account the work that may already have been done by the supplier if the PLC is part of an embedded system.
If you are implementing a lot of PLC systems it will be worth developing an SOP or guidance document on the topic. You will however need to develop some subject matter expertise to be able to guide and support your engineers, because this is a specialist area and needs experience to do cost effectively.
Showing posts with label PLC. Show all posts
Showing posts with label PLC. Show all posts
Monday, October 8, 2012
Wednesday, August 22, 2012
Verifying Computer Clocks in Production
Another good question asked online, that we share here...
Q. In a mechanically driven process, when Time is a critical parameter, the timer would be qualified for accuracy and reliability. Probably challenged against another calibrated clock for various durations that would align with the process requirements/settings. No doubt Preventive Maintenance and Calibration schedules would be developed and approved during OQ.
For automated processes that have Time as a critical parameter and the Time is measured by the PLC internal clock, what strategies are best to provide documented evidence that the internal clock is accurate, reliable (especially over time).
A. It's a good question - I can remember a certain DCS (back in the 1980's) that had two versions of a real time clock chip. One had a ceramic chip and the other plastic. The plastic clock chips could lose more that 15 minutes in an hour (honestly - I had to write the code to work around the issue).
On the basis of risk, and following ASTM E2500 / GAMP principles of leveraging the work of your supplier, if you believe that things have improved in the last 20 years you can assume that the system is acceptably accurate and include a check of elapsed time as part of your OQ or PQ.
Confirming this across a number of intervals and process runs over time should allow you to confirm that the clock is sufficiently accurate across a range of intervals with negligible drift over time (you will need to define what 'acceptable' is in your protocol and use a time reference to measure real time).
Taking a risk based approach, I would only expect to specifically test the clock if I had reasons to suspect that their might be an issue.
Q. In a mechanically driven process, when Time is a critical parameter, the timer would be qualified for accuracy and reliability. Probably challenged against another calibrated clock for various durations that would align with the process requirements/settings. No doubt Preventive Maintenance and Calibration schedules would be developed and approved during OQ.
For automated processes that have Time as a critical parameter and the Time is measured by the PLC internal clock, what strategies are best to provide documented evidence that the internal clock is accurate, reliable (especially over time).
A. It's a good question - I can remember a certain DCS (back in the 1980's) that had two versions of a real time clock chip. One had a ceramic chip and the other plastic. The plastic clock chips could lose more that 15 minutes in an hour (honestly - I had to write the code to work around the issue).
On the basis of risk, and following ASTM E2500 / GAMP principles of leveraging the work of your supplier, if you believe that things have improved in the last 20 years you can assume that the system is acceptably accurate and include a check of elapsed time as part of your OQ or PQ.
Confirming this across a number of intervals and process runs over time should allow you to confirm that the clock is sufficiently accurate across a range of intervals with negligible drift over time (you will need to define what 'acceptable' is in your protocol and use a time reference to measure real time).
Taking a risk based approach, I would only expect to specifically test the clock if I had reasons to suspect that their might be an issue.
Subscribe to:
Posts (Atom)
Posts
