PLC validation

COMPUTER SYSTEM VALIDATION (CSV) SCADA AND PLC's
1

hello friends…m new in the field of validation can u plz help me out to know more about validation of PLC’s…thanks

2

Welcome pkhattri,

That is a very broad question what kind of information are you looking for ???

Regards

3

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?

4

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:
[LIST=1]

  • The developer prepares the hardware and the Ladder Logic.
  • Somebody designs a control system and writes some software.
  • The system, which doesn’t perform as desired, gets tweaked to make it do what the user originally wanted.
  • The system gets handed over to validation, who is told to get it validated “real quick.” When you do it the wrong way, you discover problems during validation. That is the worst possible time to discover something amiss, because, as usual, the validation function is at the tail end of the time line and everybody is saying, “Validation won’t allow this system into production.” Then you have vice presidents and presidents banging on your door asking why you’re keeping them from making product. Changes are required though, because you discover problems and, worst of all, the defects are hidden in the system. If the right development work hasn’t been done up front, you can’t avoid the fact that there are going to be hidden problems that you won’t find until much further down the road. It’s an inconvenience for validation, but it’s a potential disaster for the business (especially if it requires a recall). Worst of all, the system will fail to meet the user’s needs. The opportunity is there, during the development phase, to make these software control systems meet the user’s needs. It only requires a little bit of paperwork up front and communication. It’s truly unfortunate when all of the effort to put a system in place is expended, and it doesn’t do what anybody really needed it to do. One of the biggest challenges with retrospective validation of PLCs is to really understand what each piece of code means; it’s not like a computer program. With PLCs, the developer has to sit down and explain to us address, alarms, input/output, the interfaces, and so forth so we can understand. And many times, as you are going through the code line by line with the developer, he will say, “Wow, I didn’t know it was going to do that.” One time when I asked a developer to walk through the code, it turned out to be the first time he had actually reviewed the code with a third party. I asked him, “What happens if you get a signal that’s greater than this conditional statement?” He shrugged his shoulders and said, “I think the program would crash. I think something disastrous would happen.” Involving validation experts early in the process will result in few changes to the system during development, and that’s always preferable. Hopefully, you’ll have no hidden defects. If the validation and testing plan has been carried out properly, there shouldn’t be any, and the system will meet the user’s needs. It costs no more to do it the right way than to do it the wrong way. The challenge is getting the people to make the investment up front rather than correcting things later on. This way of doing things requires the validation personnel to be pro-active in talking to the people who develop and create these things in their facilities. These people need to be convinced that it is in their best interests to be open with you, to tell you what’s going on, and spend time with you explaining the system.

    Tools of the Trade
    You need two things in-house to put together a PLC validation:
    [LIST=1]

  • An approved and signed-off system development methodology.
  • An SOP (standard operating procedure) for the validation of computer-related systems.The system development methodology describes how you develop, maintain, and cover change control of automated systems in your facility. I have run into some cases recently where systems were being developed and a manager argued that a systems development methodology would handcuff the creativity of his programmers. Now, there’s a facility that’s just about guaranteed to be out of compliance in short order.

    continued below

    • 5

    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:
    [LIST=1]

  • The end user.
  • The developer.
  • QA (quality assurance) validation. You need to have these people (or groups representing them) involved, and, although it’s tempting, try not to let them fill more than one role. It is very important in the development and validation of these software systems that you have different sets of eyes looking at the documents. Everybody has a different take on it; they all have different needs, and they all have things to add to the process. The end user is the expert on what he wants. (Even if, as often happens, what he says he wants is not what he needs.) The developer is the person who has to translate those wants and needs into system specifications. QA validation looks at those specifications to determine if it is a system that can be tested and will produce compliant product.

    continued below

    • 6

    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.