Validation 101
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....
