hello friends…m new in the field of validation can u plz help me out to know more about validation of PLC’s…thanks
That is a very broad question what kind of information are you looking for ???
What are the important things to have in a good PLC validation program.
We have several production and packaging lines.
Should we track the PLC changes individually or as part of the over line or respective equipment validation?
What are the best ways to provide documented evidence of the functionality tests? Screen shots of functionality are not always practical or even possible. Are initials enough?
Would you recommend the PLC programers test or the line mechanics or the line operators?
First of all I will give a brief outline of what I feel is the incorrect way to perform PLC validation
The Wrong Way to do PLC Validation
This is the wrong way to do PLC validation:
Tools of the Trade
You need two things in-house to put together a PLC validation:
What goes into the development methodology? First of all, the requirements for specifications. How you specify systems, and how you get people to sign off on those specifications are critically important. There has to be a review of requirements and specifications to the system. You can’t afford to have somebody specifying a system, sketching it on a tablecloth and carrying it down to engineering. That’s not sufficient. Too many people that have interest in the system are not being allowed to know what’s going on, and there are too many opportunities for failures or hidden defects to work their way in. (You’ll find a lot of warts in there that need to be corrected.)
Development practices also need to be discussed. How code will be developed, how it will be reviewed, where it’s going to be stored, what tools will be used, security and change control, among other things, should be addressed. Finally, maintenance and change control have to be dealt with. What happens when changes come along after development? Where are the revisions kept? Who’s informed, and how does validation find out about these changes to see if more work needs to be done? All of these questions need to be answered in the system development methodology.
Your system development methodology will probably be a very extensive document.
In addition to the system development methodology, you must have an SOP for the validation of computer-related systems. The SOP should be “computer-related,” so it can cover PLCs, computers, controllers, and anything else you care to include. These can all be handled with the same kind of tools. While the development methodology has probably been created by others, you, as a validation person, can prepare this validation SOP.
The SOP should work in conjunction with the development methodology. The same language should be used, and it should address specific phases. If you don’t get the kind of cooperation you need, then you can step back and just think of it in standard validation terms which will give you a document that will work.
You need a commitment from management that this SOP is the tool that’s going to be used and that it is going to be followed. If you have that, then it becomes your big stick when it comes to internal and vendor developed systems.
This document should define your approach to the validation effort. It should talk about what you consider to be appropriate for validation effort and what you consider to be appropriate for validation of these systems in your facility. It is very important to define the terms and how they relate to computer validation (e.g., what do IQ, OQ, and PQ mean in your facility?).
This is essential, because some of the people that come from the software industry have a very different spin on OQ and PQ than those who come from the validation side. In software, module testing would probably be considered OQ and system testing PQ. In our business, we’d consider system testing to be OQ and reserve PQ for the final “three batches” when product is actually manufactured. Because of those variances in terminology, these are things that have to be included in the approach and defined in the document.
The validation SOP needs to address how you plan to go about validation. But the validation plan should do more than just list the validation activities that are going to take place. It’s an opportunity to say what standards the different validation activities will be held to, who’s going to be involved in them, and what resources are required.
This is also a great place to let people see the scope of the project before you invest a lot of time writing protocols that you may or may not need. And it’s also a good tool when you’re going to vendors, before writing the purchase order, to see what resources they can supply to validate their part of the program.
An important part of the validation SOP specifically addresses how vendors will be audited. The extent of this audit depends on your level of sensitivity, so the audit could range from a very cursory telephone call (asking the vendor if he has systems in place and what they are) to actually having a certified auditor produce a formal report.
There are three key participants in this validation process:
Many times, though, the developer is the person least qualified to develop the process because he has the most tenuous grasp on it. The relationship between end user and developer has to fill in that gap. There has to be a good line of communication to make sure that the developer understands the user’s needs. Remember, the developer is probably an electrical engineer or a contract programmer who doesn’t understand your safety or quality concerns. He is going to need some help.
QA validation (if your systems are working right) acts as an auditor. It shouldn’t be necessary for the validation person to be developing the specifications. Unfortunately, all too often, they end up doing that.
Most of your PLC systems will be developed by contractors. There aren’t many companies that keep a large staff in-house to develop software or design PLC systems.
If a piece of equipment or a large utility system is brought, then it’s important to negotiate the contracts so you can somehow hand off a large quantity of the validation effort to the supplier. After all, they know what they’re doing better than you possibly can.
An important factor that seldom gets into the discussion of these audits is looking at the contractor from a business standpoint. If you’re having someone develop software on contract, it’s good to see if their business is solvent. That way you know that they will be there in a couple of years when changes need to be made to the system.
One way to hedge against a supplier’s dissolution (which has become a common requirement in the software industry) is to have the developer’s source code placed into an escrow account. This isn’t a cure-all though, because anyone who has ever looked at several hundred lines of source code will tell you that this fall back in no way gives you the capability to understand what was written. There is no substitute for being able to go back to the original developer, who has the development documentation, in order to implement changes later on.
It is critical for the developer to have good quality programs in place. Many people who supply equipment to the pharmaceutical industry will not be excited about having you dig into the specific details of the software they develop. They will, on the other hand, be more open to your understanding their quality program and how they implement software quality assurance. That can give you a great deal of confidence in the product that they’re producing for you. If you know they have SOPs for software development, a software development methodology, and a validation program, you can feel a lot better about the product they’re producing.
Another thing to keep in mind is that many vendors say they will provide you with a certificate that says their system has been validated. The FDA will not accept that, and God help you if an investigator finds that certificate, then investigates the supplier and discovers that they were deficient. If that happens, it means your system is deficient as well, and there will be hell to pay…
To answer some of your questions directly
Q: Should we track the PLC changes individually or as part of the over line or respective equipment validation?
A: I would track the individual changes to the PLC, once the PLC is part of the overall Master Validation Plan.
Q: What are the best ways to provide documented evidence of the functionality tests? Screen shots of functionality are not always practical or even possible. Are initials enough?
A: From past experience sign and dating that individual tests have occurred and have passed should be adequate as long as there is an independent reviewer of the IQ/OQ tests.
I agree sometimes it is not possible to have screen shots depending on how the PLC has been designed (might not be possible to connect the PLC to a printer)
Q: Would you recommend the PLC programers test or the line mechanics or the line operators?
I would not recommend that the PLC programmer tests I would have an independent tester perhaps from the validation department or someone who knows how the PLC works.