Software Revisioning and Verification

[daved31415]

Is there an active thread discussing what people are going with the new software verification and revisioning requirements in the new IATF?

We are tying to understand what others are doing for verification with softwares such a CMM applications and injection molding press firmware and in-house developed software.

Also, we are looking for suggestions on how software / program revision control is being managed.

 

[Ninja]

There are a couple that I'm aware of...

Such as this recent one.

IMO, software revision or upgrade is "New Software" and should be treated as such.

Some customers may see it otherwise, but I can't imagine anyone having issue with treating it as new software.

My guiding question: "How do I know that the upgrade will not alter function or output or reliability?"
My answer: "I don't...I'd better check."

HTH

 

[yodon]

I don't know what the IAFT position is but the concept of treating updated software as new may not be the best... but maybe I don't understand what you mean by "treating it as new." I presume that's just in the context of how much (re)testing is necessary?

If changes are isolated, there's no reason to re-test other areas (this does presume that the test procedures are structured to enable a limited re-test approach). It's like if you get your tires changed on your car, there would be no need to test the horn (well, maybe depending on your mechanic ). Even commercial software typically provides an overview of specific changes.

I generally take a very conservative approach to things but I can totally support a risk-based, change-driven approach to (re)testing.

 

[Ninja]

Understood. But (IMO) software changes or alterations in one section or module can have profound and possibly unintended side affects in other areas or modules.

Will it happen? Who knows...but if it does, you'd better catch it up front.

How many times has a Windows 7 security update shifted the color rendering in a JPEG printout or a PPoint animation? Plenty...
I would not consider it wise to think that an alteration on a CMM software was any safer...there is far less due diligence on that.

I would treat it as a whole new CMM, and run known parts through it to verify utility and equality to the old one...but that's me.

 

[daved31415]

Thanks for the feedback all.

I'm also interested in revisioning of programs that have been wrote. CMM programs. EOLT PLC code. Molding machine programs. Robot programs.

Is anyone interpreting IATF:16949 as requiring a complete revision history on all the above, and, if so, have you seen this implemented?

IATF requirement or not, I think this would be an intelligent move. In multiple cases I've seen "wrong version of program" listed as a root cause and I think this can be further diagnosed to be "lack of or ineffective software revision control." Has anyone investigated or implemented a SVN or version control system? I know these are very popular for programmers and I once used one successfully used one in place of a document control system and this doesn't seem like a bad idea for any organization in my opinion. Thoughts?

 

[Ninja]

Interested in how others who have handled this, but this is what I've done:
(Note: I was NOT IATF 16949...I was audited to it by customers, but did not have the cert)

For CMM, we never had a "Wrong version of program" root cause, because we removed previous versions from the equipment so it wasn't possible.
We also wrote checks into program that made it pretty hard to run a wrong program:
- Check for three features and stop on a "not found" to verify the part-program match, etc.

Having out of date programs (previous versions) available for the operator is an easily avoidable risk...avoid it.
Any given program tends to be written for a specific part shape/size. Write check steps into the front end of the program to verify the correct part and size are what's currently on the stage.
If you're using a multipart jig it's even easier...measure a symbol on the jig, and put different symbols on your jigs...very simple error proofing.
You don't have to output those measurements, but they'll stop the program if the part or jig doesn't match the program being used.
(Circle diameter, Rectangle length and width, Trapezoid interior angle...lots of measurable symbols available to you.)

HTH

 

[daved31415]

Thank you Ninja, absolutely it helps to hear how others have tackled problems in the past. Perhaps I should have specified in my previous reply, the issues stemmed from the wrong version of PLC code being loaded on end-of-line testers. In some cases a corrective action involving a change to the PLC code was put into place and somehow an older version was restored onto the PLC.

 

[Ninja]

... and somehow an older version was restored onto the PLC.

That's where I would address it. This should not remain possible after the new version was validated.