Design validation challenges - Suggestions for an effective validation method

normzone

Trusted Information Resource
:bigwave:

Hello, and once again I begin by singing my praises for this forum. Thanks to the host, moderators, and all participants for all your help.

Today's question: Any suggestions for an effective method to validate product?

In my example, we supply ruggedized computer equipment to one of the big boys, who then builds it into a suite and presents it to their customer, the military. Sometimes they present the discrete components (workstation, displays, storage) to the military.

Not having access to the end use environment (ships, planes, bunkers), how can we effectively validate? We've used the "we sent you a letter and if we don't hear back from you, it is assumed validated" approach, but the return rate on those letters is as low as you'd expect, and we're not entirely comfortable with the method.

Any and all suggestions appreciated.
 

Randy

Super Moderator
Re: Design validation challenges - Customer

Do it the same way manufacturers of a satellite validate their system....simulation.

If you're in San Diego, coming up with boat and ham fisted personnel can't be that hard (I'm a Marine and I know how close " 'Dago is to the water). Take that stuff for some trips up the coast and back to get it banged around and in a sea environment.

Get a Hummer or something and head out across the desert (I lived in Barstow for 18 years and I know the desert isn't that far away) You may need to wait until summer though to really test it good.

Take your equipment up to Parris and Elsinore and see if you can put it on a plane and bang it around their, up and down a few times (Also drive across the mountains to the desert)

Use you imagination..........like drive across the desert and toss it out the back while moving, just like a GI, and see if it still functions.
 

Marc

Fully vaccinated are you?
Leader
Re: Design validation challenges - Customer

I agree with Randy, except think about it and list all of the *potential* life cycle aspects. Will it be stored in a quonset hut in the tropics (think temperature, humidity and fungus testing)? If so, for how long? What are all the possible transportation methods - Jet, truck, etc. (think vibration test profiles). Don't forget human factors. When we weren't sure of exactly where a product would be used, transportation methods, etc., we used to do a matrix and note *anticipated* life cycles. We would submit that matrix to the government for contract requirements clarification(s). Think MIL-STD-810, if I remember correctly. All the simulations (such as explosion atmosphere testing, altitude, vibration, thermal shock, etc.) were done in laboratories like Wyle.

I don't know what your specific contract requirements are. Years go we had to write specific test plans and submit them prior to contract approval. I used to write them (like 20 years ago...). We called them Environmental Design Criteria Test Plans.
 
Last edited:
M

MIREGMGR

I don't have formal expertise in Mil validation, but I've been around product work for a long time including Mil projects and combat environments.

Validation of ruggedization other than by retrospective reports of field survival (or not) is a need that's been recognized at least since 1942, to my knowledge. There are a bunch of MIL STDs pertaining to environmental conditions. Rather than arbitrarily creating a nonreproducible ruggedization-test environment, why not apply at least subsets of MIL STDs for the conditions that are appropriate elements of validation, given the design inputs as to intended use?

I'm kind of surprised that the procurement contract didn't include any MIL-STD-based specifications for product performance, coordinated with a validation requirement.
 

normzone

Trusted Information Resource
I came here today to pose this question, only to find that I already did so almost four years ago. [Randy], [Marc], [MIREMGR], thank you for your input.

Some of our customers have strict testing requirements and MIL Std references as referenced above, but others just say "we want this hardware, and we can't tell you what we're going to do with it". We do design our products to take anticipated abusive environments in general.

When it comes to specific customer requirements we can deal with that. The ISO 9000 2008 7.3.6 Design and development validation requirement is my primary concern here - and my internal and external auditors.

Can I make the case that hardware testing with the applicable software(s), inputs and outputs available for the configuration satisfies 7.3.6 "the resulting product is capable of meeting the requirements for the specified application or intended use, where known." , for those cases where it's not known and we won't get the opportunity for feedback from the end user?
 
M

MIREGMGR

Assuming that you're only going to declare qualification for capabilities that you've determined your products actually have, would it work better to define your own boundaries and let those customer that aren't willing to work with you, figure out on their own whether their intended use is within those boundaries?

So, you determine that you're OK up to 300 Gs from low frequencies up to 10KHz, or whatever. They know that their intended use is 290 Gs up to 9KHz, so they're good to go. Ditto for your specs for temperature, humidity, shock, dust, magnetic fields, whatever. You wouldn't have a way to prove customer satisfaction, but you could document that you'd established an objective alternate approach that's suitable for a secrecy context.
 
Top Bottom