Can I get some help on the following regarding validation of PLC based
automation.
Quite a few companies do not have any PLC wiring or ladder logic
diagrams or description of the functional units of the ladder diagrams.
Even the PLC code is not available. In many cases this is true even when the equipments are new and yet to be installed. Further, for several reasons (cost, confidentiality of technical information,etc.) manufacturers do not provide the information. In such a case validation based on
production data (retrospective, concurrent/prospective) seems to be the only way out.
Am I right?
In the above situation which of the following options of PLC testing is
preferrable?
a. Connect the PC to the PLC system and conduct a communication test by removing and reconnecting specific wires to the PLC. Record whether a particular operation occurs or not.
This test helps check if the system is properly wired and operational.
b. Monitor the waveform diagrams at appropriate points on the PLC with an oscilloscope. This will help monitor communication failure, timing diagrams and changes, possible component malfunction / ageing (from waveform distortion), etc.
I’d like to point out that you validate a process.
As part of the validation you qualify the functionality of your device.
I can’t see why you need code to qualify functionality. Or even ladder
diagrams. Unless there are predetermined requirements stating you need a
specific type of function that can only be verified by use of such a
diagram.
So with regards to your first question:
You know what the device can and needs to do (I presume), so you can
test al functions (qualify) and “simulate” the process it’s supposed to
do / is part of. (Retrospect. or concurrent could be fine as well) - (No
added value in PLC code, right?)
I am assuming this is an electrically safe PLC product even in single
fault condition (CE or FCC tested/qualified?)
In regards to your second question, I can’t help much as I don’t know
what your PLC is or is supposed to do.
I can only tell you to always ask yourself: "What am I trying to prove
here?"
A test is the answer to a specific question. So the test only has any
meaning if the question is legitimate (adds something) to the
qualification / validation.
Just my 50 cent on this.
If anyone else has something to add or disagrees, please tell!
The PLC is definitely a critical component of
automation, though maybe with varying impact,
based on the purpose of the machine/process it
controls. 21CFR11 and GAMP seem to require that
the PLC hardware and software including control
panels, Man machine interface, Ladder logic, etc.
be validated ( ref. PPT presentations from the
internet that I cannot attach in this reply as
LISTserv may reject the mail). PLC
ladder diagrams and code as you know are analogous to
lines of code of application software .
2.Towards this end, most in house or third party based
validation seems to undertake ONLY the
communication test. In this test, the PLC
communication cable is connected to the PC which is
loaded with the manufacturer’s software and wires
disconnected / reconnected to check that
individual functions are controlled.
This done as part of IQ/OQ/PQ.
However, this does not provide any useful information
towards preventive action (impending
failure of PLC and associated circuitry). Nor does it
provide any information on change in process timings
due to aging of / defective components,unlike waveform
distortion and timing monitoring. In situ
communication tests can anyway be performed without
the communication cable, by merely disconnecting the
very same wires indicated in the machine’s manual.
The pharma equipment operator / scientist is no
service engineer not does he have to play the
role of one. However, where validation requires an
electrical/electronics engineer to perform
certain checks, the service of the latter must be
utilised.
In many situations the end result does not necessarily
validate the process since successful end results may
not evaluate possible failure situations ( preventive
action situations) that could affect quality.
Most of the time I come across discussions on
inadequacy of documentation rather than on actual
tests required for hardware validation, corrective and
preventive action, their adequacy/inadequacy, etc. The
depth and nature of supporting information requested
also seems to depend on the auditors themselves. Of
late the software and PLC validation aspects seem to
be drawing more attention than earlier.
In the light of the above I wish to know what the
stand of the ISPE is:
Is it necessary to test GMP critical hardware from the
Preventive and corrective action angle (waveform test)
or is it sufficient to test the same merely for ideal
case functionality (communication test)
or is it sufficient to go by only the documented end
results of the process that the machine performs.
From my point of view, although I am not Computer Specialist, there are two
objectives to be met:
Computerized Machine should perform as specified in URS. I think is
enough to test machine automation - if it works as specified, than PC or PLC
do their job as specified in URS. If machine passes OQ&PQ tests, then what
should the end user know about Ladder logic, Software listings…? Why would
the end-user have to know the logic of machine software? If IQ shows that
all hardware is installed according to approved specifications, OQ&PQ tests
show that machine functions meet production requirements, what else is
interesting for end user?
There is no possibility that unauthorized operator change the machine
settings.
Again, I am not a specialist, but if GMP inspector ask you about Computer
Validation (Qualification of automated pharmaceutical manufacturing
equipment) and if you show them QA-approved and executed IQ/OQ/PQ protocols,
what they can say except - thank you, you are keeping your automated
equipment in the state of control?
Maybe other colleagues have some bad experience, but I have never heard
GMP-inspector’s complains about lack of computer systems on automated
equipment.
Honestly speaking, GMP inspectors are not neither equipment, nor a software
specialists. If you assure than equipment is tested, tests documented, test
results are OK, what may go wrong?
I met similar situation on our 10-years old manufacturing PLC-based
equipment - there is no documentation about software and hardware except of
leaflets/manuals from individual components manufacturers.
I would like to hear from other colleagues about their experience…
Regards,
[quote=maryacton]Can I get some help on the following regarding validation of PLC based automation.
Can I have some feedback ASAP?
Regds[/quote]
Hi Mary,
Having validated a number of PLC/DCS type control systems, one thing I can tell you, is that you would need the supplier to present the client with a ‘Functional Specification’ of the PLC “function block(s)” functionality (plus configuration details). In a prospective validation project this has to be produced by the supplier/vendor in order for OQ/System testing to take place. In a retrospective environment a high level Functional Spec would need to be produced (a GAMP4/common sense expectation) for OQ/System Testing to have any true meaning.
The Functional Specification of the PLC I-O modules and their functionality will/must reflect the clients URS design requirements and expectations.
Where confidentiality is a problem, client confidentiality agreements can be put in place to ease the situation (plus an escrow agreement). Alternatively, a source code sampling plan (against BSI standards) can be produced to determine the level of code review required (e.g. a 10% sample of coding and programming practices and techniques used).
Comms checks should also be conducted on/for FMEA, interlocks, screen shots and alarm testing.
A word of warning from a controls engineer (my base trade), under no circumstances should anyone “force” (via 24v signal inject) the output of any PLC/DCS/SCADA controls systems to try and test any field devices, as you WILL override in-built 'safety interlock coding’ within the PLC I-O Function Blocks, and in an automated system within a manufacturing environment, this could cause serious injury or worse!
Finally, the Validation of PLC/DCS/SCADA systems is for specialists, as you need the engineering know-how/skills. Something the industry hasn’t fully grasped, as yet, in my opinion. It is NOT just a paper work exercise for these types of systems….I hope that makes sense?
I’ve never heard of attaching an oscilloscope to validate a PLC. But then again I always “Force” I/O too when validating PLC based systems I have also validated systems that I could access the ladder and others where I black boxed the PLC. The PLC is just a tool to get a desired outcome, although to do a thorugh validation I like to have the code and documentation. I have not come across an auditor who has asked for the source code. If you never change the code, why would you need it. Couldn’t you treat it like an embedded processor, you don’t have the code for those. You have an HMI that allows you to change settings in the microprocessor.
I agree with most of points by Dave. I will like to add following points
Functional Specifications of PLC shall be in line with process requirements and functional specifications.
Traceability matrix shall be maintain
In case where supplier has not provided the PLC details then PLC system shall be validated by doing reverse engineering. There are vendors who will provide such kind of validation services. This will help you in many ways.
I always validate my web pages / sites as i design them and ensure that any errors are corrected, to do this i have been using the inbuilt validation tool in Dreamweaver CS3.
As i am currently looking at re-doing my own website so i thought itd be a good idea to apply for membership of the UK Web Design Association UKWDA as i figure it may be a useful selling point, certainly cant be harmful Anyway in order to apply it appears you need to submit 3 sites which will validate etc.
As a quick check before applying i used the validation link on their website which goes to the W3C validation service and provides the results of validation for a given page… now this is where i am confused, the url i provided is part of a site that validates in its entirity via dreamweaver, yet when it is validated directly on the W3C site it gave me 15 errors???
Has anyone else found the Dreamweaver false validation to be an issue and how have you dealt with it?
The dreamweaver validation tool is extremely useful given that it is right there in the app, no extra effort is needed etc. and it allows for the entire to be checked in a single press of the button, but what use is it the results dont match W3C??? Is there a setting i have missed?
