ISO

Absolutely, my understanding has always been that the only requirement that the ISO standard has that whatever you do it fullfills this standard no matter what nonsense is contained within the standard. Ultimately, common sense and interrogation of the customer to find out what he really wants is the most important (rather than: supply a machine that provides x amount of power at y rotational speed, your customer should say: I need to pull this load of z kg up a slope w and it needs to get to its destination in v seconds over a distance of u meters and any other informations that is relevant to his application like how often and for how long he wants to do this and what are the variations of his load and...and...(im getting tired now )).

We have to realize that the standards are written procedures that fit the requirements and technology and expectations of the year that they were produced in (with a couple of years of delay added to that). This means that we may know in practice how things work better, safer, quicker and more realistically than the standards tell us. So again: use common sense first then refer to the standards.

Dutchy

Bravo, indeed!
It take quite a bit of effort to work the real spec' as what the customer needs, wants and thinks he wants are often entirely separate thing.
We often get customers asking for 'xyz', but when you question them carefully you find they can do it better with just 'a,b'.
If you don't get a good spec' at trick one you end up with the..

'If I knew you could make it do that, I'd have asked you to....' syndrome.
Closely follwed by the 'Wouldn't it be nice if...' (To which I invariably reply 'Wouldn't it have been nice if you'd asked for that in the first place?')

Del

It helps to remember that ISO is an acronym for "I'm Shipping Obsfucation".

But, suppose a customer asked you for a child's swing in a tree.

Design verification gets you a check on this:

Design validation checks what the customer really wanted:

Verification means examining all of the things that you think the customer wants product to do, and checking to see if the product does these expected things. In other words verification is about checking the things that have been designed into the product and making sure the product meets those design requirements.

Validation means checking to see if the product does what the customer actually wants the product to do under actual (or at least simulated) conditions. This hence takes care of all the expected as well as unexpected circumstances.

Thus verification is with respect to anticipated goals whereas validation is with reference to actual customer expectation.

There is one more difference - that is one of intended use (verification) vs an use that can be with reasonable degree foreseen (Validation)

let us say you are designing a home lighting system, the design verification is over. But there is a reasonably foreseen circumstance - so you design to a bit lower level of voltage (110V or 230V or in factory because of the more hazard, it is 24V only on hand lamps), put ground fault relays in line to avoid shocks.

The validation hence is in real life scenario, a screw driver used as a nail to punch a hole, open a can (and some times to tighten or loses a screw). Verification is the particular screw driver must handle this much torque to tighten or loses a screw.

Unless the product is validated, all the customer needs are really not taken care of.

ISO 8402:1994 :

verification: confirmation by examination and provision of OBJECTIVE EVIDENCE that specified requirements have been fulfilled.

validation: confirmation by examination and provision of OBJECTIVE EVIDENCE that the particular requirements for a specific intended use are fulfilled.

FDA

S 820.3(z) Validation means confirmation by examination and provision of objective evidence that the particular requirements for a specific intended use can be consistently fulfilled. (1) Process Validation means establishing by objective evidence that a process consistently produces a result or product meeting its predetermined specifications. (2) Design Validation means establishing by objective evidence that device specifications conform with user needs and intended use(s).

S820.3(aa) Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled.Whereas verification is a detailed examination of aspects of a design at various stages in the development, design validation is a cumulative summation of all efforts to assure that the design will conform with user needs and intended use(s), given expected variations in components, materials, manufacturing processes, and the use environment.

In real life scenario also you will agree that once the design is verified it is validated (prototype, trial run,...)

What you say is all well and good...
But you shouldn't need Validation...that's what a Specification is for.
The design process is hardly going to meet ISO9000 if you don't have a spec'
... and if you do have a spec, it should be validated when it's issued or updated not after the project is completed!
Del

Welcome to the world of "The devil with the customer; I know what he wants a lot better than he does." This is why we get retailers blaming us because we won't buy their overpriced junk.

If everything is ideal, we understand the customers and the intended use (and misuse) exactly then what you say is true.

But it is not in real life, thst's why we do need the validation. Despite all the verification and re-verification, we still do have equipment recalls (and even by the best companies).

The wind tunnel test of the F1 cars (despite the thorough CFD analysis) and further tuning up is all the part of the validation process, and that goes on when the HD (I was seeing that in Extreme machines - either in NGC or Disovery) - does test drive of the motorcycles in their test track, and the test track was not the ideal (as in specification - level track, without any bumps, ...)

Onvce you verify the design (internally- yes it works under the company intended function) then one validates the design (with customer or without customer, at least in simulated real life condition- It will work in customer's hand too)- Then you go to the next stage of the QFD (Quality Function deployment) ie process design, verification and validation , then the third house and so on.

Let me close with a small example (not yet sorted) - We do some painting on quite large structures - air less spray - in open.

We had been doing it with a few suppliers, without any problem.

Another supplier has now supplied. And now we have a problem.

When the paint is sprayed on the component. When sprayed, the surface is smooth, and then bubbles form. Not immediately after 10 seconds to 1 minute.

The time taken for the bubbles - depends on the component skin temperature - what we have seen is - paint in the morning, (our RH is so low thet we are able to manage the required parameters) no problem. In afternoon, the portion heated by sun (may be about 45-50 deg C) - bubble time 10 second, shaded areas (may be 40 deg C or below) 1 minute. Cold surfaces - no bubbles.

These were tested at supplier lab, before and after and in our labs too - under control circumstances. It passed the test. But as customer, definitely I can not paint these in labs, even in booths. Design is here verified, partially validated but not in simulated actual working condition.

You make a good point with a fine example but I still think it's an argument about semantics.
Basically the spec' was poor and didn't include a field trial. The real point is that no abount of auditing planning and paperwork was going to change the fact that, in the field you had a problem that needed sorting.
It got sorted by people looking at the process and the conditions and doing some tests...paperwork and planning and ISO contributed nothing.
What would have prevented the problem would have been a better test spec' in the fiirst place and a field trial.
So basically 'Validation' is bunk...If the product fails, you will soon know about it.... a load of ticks on paper don't necessarilly mean you won't have a problem in 2 weeks.
Where ISO is helpfull is in ensuring you have a system which will react to the problem when it occurs.
You don't need this extra flim flam of 'validation', just do the testing properly.
In your example, there should have been a field test anyway which would have been called 'field trial' and ticked off as verification that the product and process was fit for purpose. WE DONT NEED THE EXTRA LABEL OF VALIDATION...it's a crock of horse feathers, contrived as self justification for auditors to argue about semantics.
It don't matter what you call it, bubbling paint is bubbling paint.

Del

I agree, however there is one point concerning validation and that is that insurance companies who pay for stuff when it goes wrong in the real world (where the operating conditions are considerably worse than anything anyone anticipates) only do that if everything is done by the book and unfortunately that involves verification and validation. Now don't start me of on insurance companies, (who describe a tree falling on your car as "an act of god") but unfortunately they are a neccessary "evil".

P.S. is tuna in oliveoil OK?

I mean no disrespect, but this idea bothers me a whole lot.

Like most people, I've bubbled paint under these circumstances. I know I did it once. I might have done it twice before I realized what the problem was. But, I never did it again! It's like the old 3 Stooges line, "If it hurts when you do that, don't do that."

So, validation should not (_{Poster starts to sound like ranting old geezer here}.) ever take the place of good, common sense.

Design verification means that a person has revised the design that was intended to be developed, and that after that, an "ok" or "need to be checked or corrected" has been provided. Design validation means that a design has been approved. Designs are validated if the result is right, if the result can be improved the design should not be validated, It would have been verified since you found something to be improved but not validated because it didn't satisfy your spectations and you are going to improve it. I don´t know if I expressed myself in good english, I did my best

The essence of Verification is internally focused. Can it be produced and shipped?

The essence of Validation is that it must involve the customer. Will this meet a customer need, or be responsive to a changing need? In other words can it be sold to a satisfied customer?

You have my sympathy, we obtained ISO 9001 certification this year & have just passed our 6 month audit but it was a painful process. In our world, most products are custom in some way so the validation/verification procedure is central.

Simply stated, we validate by sending the customer a performance specification & mechanical drawing for them to approve. This may be after a period of discussion as our customers often want better performance than we can achieve or, just as often have a requirement but no idea of how to achieve it.

We verify by comparing the mechanical & electrical test results to the spec requirement. If they meet the spec all is OK, if not we either start again or ask the customer if what we have is acceptable.

It's the damn semantics again...
Customer aproval and signing off on a spec' is a good thing.
but...
I don't think it has any realtionship to the word 'valid' though?
I mean there are plenty of signed off customer spec's which turn out not to be valid for the final application.

Soooo, does this mean the customer is the one who should be ticking his own validation box.

I still think Validation is just a pants word when applied to the design process.

Let's look at a simple example, a front panel label...I will send draft artwork to the manufacturer in various forms he will produce his artwork drawing for me to approve.
Who says the label is valid? Me as I drew the darned thing up, I should run it past my boss to make sure we've invented a stupid enough name for the product, hopefully we've designed it so there are sufficient 'labelling oportunities' for the distributor to stick his logo on it, it should have all the required info on it, but these are spec issues... we specify what we want the label to do/say. Vadid just doesn't make sense to me..is it a valid foodstuff? A valid childs toy? valid what???? Valid to the end use???
But unles the end use is specified we are back to the SPEC.
All roads lead to ROME.... without a valid spec' its GIGO.(garbage in garbage out)
Thus validation is a spec' activity not a post design activity.
I rest my case m'lud and in summing up I'd like to say thankyouverymuch (to be read in Elvis voice)
My work here is done..to the catmobile dah dah dah, dah dah dah catman.
Del

things mean whatever you define them as in your procedures.

You speak wisely Grasshopper...GA _{<exits backwards bowing in admiration>}
Del _{<calm calm>}

A footnote.
After my discusion with the BS auditor, he came in the next day saying that he and his colleagues had a similar discussion the previous day and they couldn't actually agree amongst themselves what on earth validation actually meant.
Maybe they need to write themselves a procedure for clear writing???
Del

I think to make it simpler youcan think verification as testing and make sure that all the sub-assemblies and components are performing as per the specifications and validation is testing of the system as a whole. So if we put all the subassemblies and components together in a system does it meet the customer requirements. Design verification comes out of design validation test plan.

I call this the ISO/KISS methodolgy:

Document and Archive; use only documentation listed in your business/quality manual. This will save you.

Design Validation use:

First article inspections

Design of Experiment (low and high)

Capablity Study (validate your process)

Design Verification use:

Inspection (gauging and visual)

Good luck,

Ed Cofer

ASQ/CCT