The Elsmar Cove Business Standards Discussion Forums More Free Files Forum Discussion Thread Post Attachments Listing Elsmar Cove Discussion Forums Main Page
Welcome to what was The Original Cayman Cove Forums!
This thread is carried over and continued in the Current Elsmar Cove Forums

Search the Elsmar Cove!

Wooden Line
This is a "Frozen" Legacy Forum.
Most links on this page do NOT work.
Discussions since 2001 are HERE

Owl Line
The New Elsmar Cove Forums   The New Elsmar Cove Forums
  ISO 9001/4:2000
  7.3 Design and Development

Post New Topic  Post A Reply
profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone! next newest topic | next oldest topic
Author Topic:   7.3 Design and Development
Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 20 September 2000 09:09 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
I actually value most of the changes in the new ISO 9000:2000, i think it makes it a much more user friendly beast.

However Design and or Development still has me confused.

Can you help me out, can we take an unusual example ie the design of a NASCAR Racecar, and specify what each section could be. This is my understanding;

7.3.1 Design and/or development planning
OK so we need a procedure for how design is going to be done.

7.3.2 Design and/or development inputs.
Could the NASCAR regulations be described as design inputs? ie Car shall weigh at least 450Kgs and not be wider than 1.8 Meters etc

7.3.3 Design and/or developement outputs.
Could this simply be the drawings that come of the CAD machines for the chassis and suspension etc?

7.3.4 Design and/or development review
Could this simply be the weekly project meeting?

7.3.5 Design and/or developement verification.
What could this be? Can you offer any realistic suggestions. How can you verify designs,? FEM is the only thing that crosses my mind.

7.3.6 Design and/or development validation
What could this be? In this example does it actually mean doing a product test? ie taking the car to the race circuit. This seems to be more like a product test than a design test.

7.3.7 Control of Design and/or development changes.
This should be relatively clear, some form of Engineering Change System.

Any help greatfully accepted.

------------------
Andy B

[This message has been edited by Andy Bassett (edited 20 September 2000).]

IP: Logged

Sherri O
Lurker (<10 Posts)

Posts: 6
From:Brighton, MI, USA
Registered: Sep 2000

posted 20 September 2000 10:57 AM     Click Here to See the Profile for Sherri O     Edit/Delete Message   Reply w/Quote
Andy, this may help. My company build racks that hold car parts (just for brief background). Here is how we respond to those items:
7.3.2 Inputs: Input is infomration received in order to begin. This can be written/verbal instructions from an engineer, parts, math data, etc.
7.3.3 Outputs: Ours are in the form of prints, disk, prototype racks, etc.
7.3.4 Review: FMC requires us to document reviews. We have concept(preliminary ideas/sketches), protoype(design only and sometimes includes an actual proto rack) and final design. The reviews are with the designer and the engineer and may include, estimating, production, and QC.
7.3.5 Verification: From our business we can verify a design by building a prototype for approval.
7.3.6 Validation: Our company cannot do validation for our products in house. Besides 95% of our customers who have us do design do the validation testing(which by the way for a rack usually means SHAKE / IMPACT tests)for us and copy us on the results(sometimes).
7.3.7 Changes: You're rights, you need to develop a way to track changes and how you relay these changes to the operations involved. We use a Design Revision Form with a distribution list on the bottom.
I hope this helps, I'm new to this site and don't want to make a fool of myself.

IP: Logged

isodog
Forum Contributor

Posts: 51
From:Vernon Hills, IL, USA
Registered: Apr 2000

posted 20 September 2000 10:31 PM     Click Here to See the Profile for isodog   Click Here to Email isodog     Edit/Delete Message   Reply w/Quote
hope this helps.

Verification checks whether the design meets the original specifications (design input).

Validation checks whether the new product works (does what it's supposed to).

Both are important, but different ways of looking at a new product.

Dave

------------------

IP: Logged

Andy Basse
unregistered
posted 21 September 2000 02:05 AM           Edit/Delete Message   Reply w/Quote
Thanks for the help so far, sometines i need real examples to fully understand how the standard can be interpreted in real-life, your example was a very good one.

Sherri O dont worry if you make a fool of yourself, you are in good company.

BTW
7.3.5 Verification: From our business we can verify a design by building a prototype for approval.

How do you verify the prototype if you arent actually testing it? Do you say 'Yes this looks lie what the engineer wanted'. Who and how do you sing it off? Does somebody approve the BoM.

Regards

IP: Logged

Fordisoman
unregistered
posted 21 September 2000 08:06 AM           Edit/Delete Message   Reply w/Quote
Andy,
Verification can begin before the prototype is built and tested. Verification should begin in the design stage using analyses, alternate calculations, simulation, modelling, whatever tools are available to the engineer.

IP: Logged

Sherri O
Lurker (<10 Posts)

Posts: 6
From:Brighton, MI, USA
Registered: Sep 2000

posted 21 September 2000 08:35 AM     Click Here to See the Profile for Sherri O     Edit/Delete Message   Reply w/Quote
To verify our prototype against the design, we do dimensional checks and also part checks. We can load the prototype with parts to make sure they fit properly. The customer's engineer will usually come to ur plant and sign off on the protoype/design if approved and/or make changes to restart the process.
Yes i agree verification can begin before a prototype, but for most of our builds, racks are similar in design/function. We use past builds, TGR/TGW etc.

IP: Logged

Rick Goodson
Forum Wizard

Posts: 102
From:Wuakesha, Wisconsin, USA
Registered: Aug 2000

posted 21 September 2000 11:55 AM     Click Here to See the Profile for Rick Goodson   Click Here to Email Rick Goodson     Edit/Delete Message   Reply w/Quote
Andy,

Re Verification and Validation

The input to your example would be the NASCR regs, but also would include and the owner/engineer/driver input. One of those inputs might have to do with the speed the vehicle needs to be capable of. That speed requirement is translated into an engine design in terms of displacement, horse power, torque, etc.

When the engine is designed and built we 'verify' that it is the displacement specified, does supply the specified torque, produces x amount of horsepower. This is design verification. We then take it to the track to determine if it can meet the speed requirement, which is the 'end user' requirement. Does it perform. This is design validation. Now, in theory, we should do the validation under use conditions, which would imply running it in a race. In fact, the validation probably is performed in a more 'sterile' condition with just that vehicle on the track.

Hope that helps.

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 22 September 2000 02:37 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
Thanks everyone, im just mulling over the responses to decide how best to translate them into a present problem. I now have a better understanding of how different companies are interpreting design verification and design validation.

My only problem at the moment is exactly how to insert the design verification into the sample NASCAR environment REALISTICALLY, ie without burdening somebody with the need to sign something that he doesnt really understand why he is doing it.

This type of environment is in someways an ISO nightmare, as development is not done in nice clean packets that can be completed and then signed off, rather development is a permanent activity taking place in the office, at the track and during the night.

Regards

------------------
Andy B

IP: Logged

Alan Cotterell
Forum Contributor

Posts: 120
From:Benalla, Victoria, Australia
Registered: Oct 1999

posted 23 September 2000 05:38 PM     Click Here to See the Profile for Alan Cotterell   Click Here to Email Alan Cotterell     Edit/Delete Message   Reply w/Quote
I think you are looking at ISO9000 to guide you in how you manage the design and development activity. Probably what you should look at is your 'project management' and 'configuration management' of the product.
The NASCAR rules could be seen as 'constraints' in a project management sense and 'inputs' in an ISO9000 sense.
Design verification is in my opinion essentially a paper based activity, validation is performance testing.
Controlling the 'data pack' involves verification and is known as 'configuration management'. It involves use of an 'engineering change control system'.
I think ISO9000 circumscribes a team activity in this application, and I suggest you follow the old axiom 'say what you do, do what you say, be able to prove it' , rather than trying to design using ISO9000 as a guide.
The following Australian Standards might be useful - AS3905.12 Guide to ISO9001 for architectural and engineering design practices. AS3905.16 Project Management. AS3907 Configuration Management.
All available from http://www.standards.com.au

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 23 September 2000 05:53 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
> ...7.3.1 Design and/or development planning OK so we need a procedure
> for how design is going to be done.

A general flow. will do. Include review points.

> 7.3.2 Design and/or development inputs. Could the NASCAR regulations
> be described as design inputs? ie Car shall weigh at least 450Kgs and
> not be wider than 1.8 Meters etc

Yes.

> 7.3.3 Design and/or developement outputs. Could this simply be the
> drawings that come of the CAD machines for the chassis and suspension
> etc?

Yes.

> 7.3.4 Design and/or development review Could this simply be the weekly
> project meeting?

Yes - you can - make sure you document the meetings and be ready to explain what you reviewed.

> 7.3.5 Design and/or developement verification. What could this be? Can
> you offer any realistic suggestions. How can you verify designs,? FEM
> is the only thing that crosses my mind.

Verification is review of the 'paper proposal(s)'. Your early stage computations.

> 7.3.6 Design and/or development validation What could this be? In this
> example does it actually mean doing a product test? ie taking the car
> to the race circuit. This seems to be more like a product test than a
> design test.

Yes. Run on track. 'Prove' design output.

> 7.3.7 Control of Design and/or development changes. This should be
> relatively clear, some form of Engineering Change System.

Yes - an engineering change system.

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 27 September 2000 05:47 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
quote:
Originally posted by Marc Smith:

> 7.3.5 Design and/or developement verification. What could this be? Can
> you offer any realistic suggestions. How can you verify designs,? FEM
> is the only thing that crosses my mind.

Verification is review of the 'paper proposal(s)'. Your early stage computations. Note: See Sherri O's 20 Sept posting


OK, maybe slowly but surely i am getting a little closer. What would be a review of the 'Paper proposal', the drawings have already been signed off in 7.3.3 Design/Development Outputs.
The complete design cannot be signed off until 7.3.6 Design Validation.

What would you suggest could or should physically happen here.

Regards

------------------
Andy B

[This message has been edited by Marc Smith (edited 27 September 2000).]

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 27 September 2000 06:23 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
> What would be a review of the 'Paper proposal', the drawings have
> already been signed off in 7.3.3 Design/Development Outputs. The
> complete design cannot be signed off until 7.3.6 Design Validation.

The review for the sign-off of the 7.3.3 outputs is your verification.

Take a read through https://elsmar.com/pdf_files/APQP_Q.pdf - look at page 8. Also check the matrix on page 10. See if this helps.

Sherry O states: 7.3.5 Verification: From our business we can verify a design by building a prototype for approval.

A prototype is not necessary for verification.

FordISOMan states: Verification can begin before the prototype is built and tested. Verification should begin in the design stage using analyses, alternate calculations, simulation, modelling, whatever tools are available to the engineer.

Yup - this is it.

Andy sez: My only problem at the moment is exactly how to insert the design verification into the sample NASCAR environment REALISTICALLY, ie without burdening somebody with the need to sign something that he doesnt really understand why he is doing it.

Not a problem. You match inputs against outputs and the responsible engineer signs off that requiremetns are met.

INPUT: Must be able to accellerate from 0 to 130 mph within 8.46 seconds. Car must weigh less than ZZZZ kg. Engine can be no larger than ZZZZ cc.

OUTPUT: XXXX cc engine, X:Y compression ratio, rear axle ratio of x:y, car weight of XXXX kg, XXXX transmission, XXXXX fuel will (theoretically) meet the INPUT REQUIREMENTS.

[This message has been edited by Marc Smith (edited 27 September 2000).]

IP: Logged

Alan Cotterell
Forum Contributor

Posts: 120
From:Benalla, Victoria, Australia
Registered: Oct 1999

posted 28 September 2000 12:40 PM     Click Here to See the Profile for Alan Cotterell   Click Here to Email Alan Cotterell     Edit/Delete Message   Reply w/Quote
I suggest there is a need for a 'Project Management Procedure' in your quality manual. In business some activities are project based and need a Gantt chart, scope statements etc, some are based in continuous production and need prototyping and SPC.
You might be interested in ISO's activities in relation to managing project risks (including quality) See: http://www.riskreports.com/protected/archive/rmr0900.html
(Also Australian Standard AS3905.16 - Project Management - quality system guidelines)

IP: Logged

Alan Cotterell
Forum Contributor

Posts: 120
From:Benalla, Victoria, Australia
Registered: Oct 1999

posted 28 September 2000 12:55 PM     Click Here to See the Profile for Alan Cotterell   Click Here to Email Alan Cotterell     Edit/Delete Message   Reply w/Quote
I suggest there is a need for a 'Project Management Procedure' in your quality manual. In business some activities are project based and need a Gantt chart, scope statements etc, some are based in continuous production and need prototyping and SPC.
You might be interested in ISO's activities in relation to managing project risks (including quality) See: http://www.riskreports.com/protected/archive/rmr0900.html
(Also Australian Standard AS3905.16 - Project Management - quality system guidelines)

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 29 September 2000 02:52 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
Funny enough we had a 'Consulting Day' with our future certification body yesterday, and one point i wanted to clear was what they wish to see as evidence of Design Verification and Evidence of Design Validation.

Interestingly confusion seems to reign from all sides. Our final agreement was, using our NASCAR example, a Track Test Report is evidence of Design Verification, and a signed off Parts List is evidence of Design Validation.

All a bit weak if you ask me, i can imagine a lot of disinterested signing going on (Especially 3 days before the audit), but i suppose the problem is not helped by the complexity of this environment.

PS Alan - For the second time in 12 months i took a little time to try to understand the concept of Risk Management by reading the link you provided. I am afraid you will have to write me off as uneducatable, i dont understand what it is and what it can do. If you have anyhwere a practical, real life example of what it is and how it works, ill have another go.

Regards

------------------
Andy B

[This message has been edited by Andy Bassett (edited 29 September 2000).]

IP: Logged

FordISO Man
unregistered
posted 29 September 2000 09:25 AM           Edit/Delete Message   Reply w/Quote
Alan,
Based on what you just reported I don't believe your certification body understands
verification or validation very well. They are way off on validation which should be a
demonstration in the customer's environment that the product meets the customer's needs.
And has been discussed above, verification should begin during the "paper design stage".

IP: Logged

FordISO Man
unregistered
posted 29 September 2000 09:31 AM           Edit/Delete Message   Reply w/Quote
Sorry Alan, my last post should have been addressed to Andy and apparently I can't edit it now.

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 September 2000 01:15 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
quote:
Originally posted by FordISO Man:
Sorry Alan, my last post should have been addressed to Andy and apparently I can't edit it now.

If you register you can edit your posts.

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4119
From:West Chester, OH, USA
Registered:

posted 29 September 2000 01:42 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
quote:
Originally posted by FordISO Man:
Alan,

Based on what you just reported I don't believe your certification body understands verification or validation very well. They are way off on validation which should be a demonstration in the customer's environment that the product meets the customer's needs. And has been discussed above, verification should begin during the "paper design stage".


I didn't read the document, but that validation takes place at the customers facility is not always true. It depends upon who your customer is and what the product is. In some cases there are multiple validations. Many companies do validation studies in-house. T&E suppliers typoically validate in-house and at a customer's facility in 'run-offs'. Tire manufacturers validate in-house on mechanical testers and on test tracks. Some consider accellerated life testing as their validation. But - in all cases, real or simulated, validation is supposed to 'prove' the design under predicted or actual use conditions.

[This message has been edited by Marc Smith (edited 29 September 2000).]

IP: Logged

Alan Cotterell
Forum Contributor

Posts: 120
From:Benalla, Victoria, Australia
Registered: Oct 1999

posted 02 October 2000 11:50 AM     Click Here to See the Profile for Alan Cotterell   Click Here to Email Alan Cotterell     Edit/Delete Message   Reply w/Quote
I hope you don't mind me answering Andy here. The following is the submission I made to the New South Wales Standing Committee on Law and Justice (Inquiry Into Workplace Safety). It give an idea what Operational Risk is about.

----------------------

Editor's note: Allan, this was pretty long. Please provide a link to it on your site. Thanks!

[This message has been edited by Marc Smith (edited 02 October 2000).]

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 05 October 2000 03:06 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
quote:
Originally posted by FordISO Man:
[B]Alan,
They are way off on validation which should be a
demonstration in the customer's environment that the product meets the customer's needs.
B]

Im not sure about the 'in the customers environment', but i suppose i could argue that signing off of a Parts List by a 'qualified Engineer' is evidence of design validation.

Ford ISO man - Im open to other suggestions of what could physically constitute Design Validation in this fictitional NASCAR environment.

Regards


------------------
Andy B

IP: Logged

Alan Cotterell
Forum Contributor

Posts: 120
From:Benalla, Victoria, Australia
Registered: Oct 1999

posted 06 October 2000 07:20 AM     Click Here to See the Profile for Alan Cotterell   Click Here to Email Alan Cotterell     Edit/Delete Message   Reply w/Quote
I think a file containing test results and a final report on the product performance would be more suitable evidence of design validation . The report should probably compare the test results with the design input data (customer requirements).
Checking of calculations and drawings by qualified engineers is, in my opinion 'design verification'. Validation involves performance testing.

IP: Logged

FordISOMan
unregistered
posted 10 October 2000 10:33 AM           Edit/Delete Message   Reply w/Quote
Andy,
To help clarify the difference between verification and validation, let's review the ISO spec.
Verification-ensuring that the design stage output meets the design stage input.
Validation- ensuring that the PRODUCT meets the defined USER's Needs.
Therefore,, according to ISO, validation can't be reviewing the 'signed off parts list' which is only a "paper" review not a PRODUCT review. Validation requires performance testing the Product just as Alan states in the previous post. The key difference in validation testing is that the test is based on the manner in which the Customer will actually USE THE PRODUCT in service, not just on the stated requirements.
(Verification testing which should already been accomplished proved that the PRODUCT met the STATED REQUIREMENTS.) So validation is an Operational Performance test of the Product in the way the customer will really employ it. Validation is necessary because it is extremely difficult to state all the requirements in sufficient detail to guarantee that the Product will be successful.
For your NASCAR example,validation would be performed at a race track and the measures would be such things as: acceleration, top speed, lap time, braking, handling characteristics, durability, gas mileage in race conditions, and driver ergonomics.
Hope this helps.

IP: Logged

Andy Bassett
Forum Contributor

Posts: 274
From:Donegal Ireland
Registered: Jun 1999

posted 11 October 2000 07:53 AM     Click Here to See the Profile for Andy Bassett   Click Here to Email Andy Bassett     Edit/Delete Message   Reply w/Quote
Hello Ford ISO Man

I think maybe i am confusing the issue with this obtuse (but real-life) example. When designing a race vehicle it is fairly unusal to set design parameters, you are always aiming for maximum, it is very difficult to produce a set-of figures and say ' yes 200mph, thats what we are looking for', the best i can hope for is for the relevant Test Engineer to say something like 'thats the best we can do with this car in this condition on this test day-I will now sign the stźcklist and release the car'.

Regards

------------------
Andy B

IP: Logged

John C
Forum Contributor

Posts: 134
From:Cork City, Ireland
Registered: Nov 98

posted 19 October 2000 12:54 PM     Click Here to See the Profile for John C   Click Here to Email John C     Edit/Delete Message   Reply w/Quote
Andy,

Verification comes from the Latin word for truth and validation from the word meaning strength. So, it's easy. Each time you verify that the design is true to some earlier intention, then it's verification and each time you test to see if it performs like you expected, it's validation. Now these things are not just two stages, they happen, as you say yourself, continuously, as the design is developed and the performance is tested by day and by night through the prototype stages and then before and after, and even during every race. So it's very difficult to say where one or other starts or finishes. Somewhere above, someone pointed out that you should not let standard requirements dictate your design program, but approach it the other way around. You know about the design process, could patch one together, no problem, from experience, popluate the place with designers and the resources they need. I'd say that, when planning such a process, it would have to be a general description of what is going to happen; concept, bringing the general features together, checking them out theoretically, building and testing something and then continuing development from there. Then, probably record it as you go along, leaving a useful record. More than this they can't expect.
There is one other thing that contributes to the confusion; The design spec and the performance spec are quite different items. An engine may designed to to produce 300 bhp but that is not part of the design.
rgds, John C

[This message has been edited by John C (edited 19 October 2000).]

IP: Logged

All times are Eastern Standard Time (USA)

next newest topic | next oldest topic

Administrative Options: Close Topic | Archive/Move | Delete Topic
Post New Topic  Post A Reply Hop to:

Contact Us | The Elsmar Cove Home Page

Your Input Into These Forums Is Appreciated! Thanks!


Main Site Search
Y'All Come Back Now, Ya Hear?
Powered by FreeBSD!Made With A Mac!Powered by Apache!