What is the role of Validation Engineers

vinodivekar

Guest
V
I see that nowadays the demand for VALIDATION Engineers (with Electrical and Automation experience) have increased - mainly recruited by Pharmaceutical companies.

I wanted to educate myself about what are the "validation" engineers function / duties. What do they really do in this proffession??

Where can I get courses and certification to become a VALIDATION Engineer from Canada (Toronto)??

Are there already too.......many Validation Engineers in the market or there is a scarsity of them. Is the demand real???

Thanks
Vinod
 
Validation

This is from a thread some time ago. It describes the validation process.

Thanks to Allen Nelson.[/ SIZE]

"Validation 101 Post #2

I'm assuming that by the phrase "validation", you are referring to the type of proof that the system works as intended as required by the USA's Food & Drug Administration (FDA) for Good Manufacturing Practices (GMP) of Pharamaceuticals.

This is not an easy subject to explain, especially to "provide the details" for. There are companies that specialize in this, and charge big bucks for those services (I work for such a company).

The general principles is:
- Define what the system must do;
- Make a system do what you said it would do;
- Prove that the system does just that.

The way you do this is with documentation. Lots and lots of documentation. Again, the principles (not the details) are to have the following documents (at a minimum):

User Requirements Specification (URS). This describes what the system is trying to accomplish ("Make Drugs"), where it will be doing it ("Unairconditioned shack out back"), the types of interfaces needed ("One big friendly 'START' button. Oh, and an E-stop"), and any other BIG PICTURE requirements ("Electicity in Baghdad is more reliable - need this problem solved"). It should expound on every requrement listed in the URS.
Functional Requirements Specification (FRS). This goes into details as to what functions that sytem will supply. Specifying the hardware ("Green, Mushroom Head button for 'Start'; UPS & Line filtering to solve power problems"), alarms, sequence of operations.
Detailed Design Specification (DDS). Spells out exactly HOW the requirements in the FRS will be accomplished.

In summary:
URS: WHAT the system NEEDS to do.
FRS: WHAT the system WILL do.
DDS: HOW the system WILL do it.

Some folks combine one or more of these documents together, or use logic and HMI printouts to serve as the DDS. The last is WRONG - the idea is to plan things out ahead of time, not "this is how it turned out". That's not to say that you can't go back and change the documentation if you find out that a function or method you thought you were going to provide won't work the way you thought it would.

Anyway, that's the "Define" third. Presumably, you know the "Make" third (generating code). The "Prove" third again requires documentation:
Installation Qualification (IQ). - Verifies that the hardware (part numbers, tag numbers) has been installed (wire numbers, signal ranges) in the environment (power requirements, signal generation) specified, and that it 'works' - not the system, just the hardware.
Operational Qualification (OQ). - Verifies that the software makes the hardware work as specified. Screen navigation, HOA logic, sequence testing, power-up/power-loss testing. This is the big enchillada.
Performance Qualification (PQ). - Verifies that the system actually does what it's supposed to. It's all well and good to specify that the sequence will have a 10 minute rinse step to clean the tank. But is the tank REALLY clean after 10 minutes?


Again, sometimes some of the documents are combined (IOQ is common).

The whole point of these exersizes is to ensure that the drug is SAFE, CONSISTANT, and EFFECTIVE. Some have tried to correlate the IQ to "Safe" (the hardware works the first time, every time), OQ to "Consistant" (software never breaks), and the PQ to "Effective" (did we produce what we thought we were going to?), but it doesn't quite fit.

But wait, there's more. There's all of the OTHER stuff that goes into that "MAKE" step that I just glossed over. After all, you don't just write the code correctly the first time - you tweek things to fix "bugs". Well, what are your Change Control Procedures? Your company only hires "qualified" engineers to work on this, right? Well, what are your HR procedures for doing this? What determines the 'quality' of your engineers? How do they know their jobs? Have they been trained? Do they have procedures to follow when writing code ("A typical Motor Start ciruit will look like this....")? PROVE IT!!.

And that's not even the details....


__________________
©¿©¬


Last edited by Allen Nelson on October 3rd, 2003 at 05:35 PM "
 

Similar Topics

I am setting up my first ring with siemens. There are two manager roles to select. "Manager" and "Manager (auto)" What is the difference...
Replies
1
Views
1,450
Hey Guys, My company is looking to introduce a new role for a Site Systems Engineer I have been asked to define this role and I am having trouble...
Replies
4
Views
1,484
Is there a way to tie the ability to acknowledge different alarm priority or severity levels with security roles? It's not looking like there is...
Replies
0
Views
1,027
So say i wrote a program im studio 31 and i hand it to a customer that has a cpu with firmware 30 Can the program be rolled back? I know for a...
Replies
16
Views
4,082
Hello everybody, first of all I want to thank this wonderfull site for it's usefull and interactive forum and all the participants for they...
Replies
4
Views
1,685
Back
Top Bottom