Software QA - PROM revision level control - Boy am I out of my league!!!

Hi All you seasoned professionals. I have been around many years with a wealth of experience BUT software QA is not my expertise and I find myself with a problem and need guidance. I do know enough about software control to get by in most cases but it's not enough this time.

I work for a company that makes antenna systems or defense. We have many sister companies that we subcontract with for various stuff. One sister company provides boards with PROMs. the rev of software on those PROMS is the root of my problem. To complicate matters that sister sends directly to another sister which does their thing then sends back to us. I cannot seem to get a handle on revisions. The PROM has 4 (this is where I show my ignorance...I can only speak in what my small brain has deciphered from conversations.....) sub programs. Two of them cannot be changed, 2 can be. The sisters tell me they don't change anything, its a field option. BUT When we get the units here or worse at the customer we determine failures due to the software rev. The boards come with a document with a tag stating the as left revision. But it seems to me thats not enough. I want a label on the PROM itself. (they tell me I'm nuts) The software is supposed to be the same rev as the board, but my gut tells me otherwise.

Can anyone send me in the right direction or give me some options?
thanks in advance cause I know you guys and gals know lots more than me !!!!
Barb

This can be handled by controlling the 4 sub programs or the entire PROM contents (firmware) by version & revision number with checksum. Traceability records can be used to link the board's serial number with the "firmware" revision. I've resorted to this once the PROMs became too small to label.

barb butrym said:

The PROM has 4 sub programs. Two of them cannot be changed, 2 can be.

Click to expand...

This probably needs further explanation as to who can do the changes and where this takes place. Is the PROM removable (socketed)?

Some memory devices are used to store runtime variables such as initialization parameters or even the unit's serial number. This needn't be considered a change to the firmware provided the mechanism has been validated and known not to adversely effect the "program".

PROMs have mostly given way to flash memory, sometimes embedded in the processor itself so we've been forced to give-up on applying sticky labels to discrete devices. It's the (initially) downloaded firmware that's controlled. I added "initially" as these systems then become field upgradable via a reflash which must be reflected in your traceability records.

Hope this helps.

Thanks for the feedback. the PROM is a plug in.

I took the bull by the horn this morning and drew the following lines in the sand...right or wrong :

The PROM or EPROM needs to have a revision tied to it for traceability purposes when changes are made.

They need to track what changes are being made when the previous version is superseded.

They could track it on a drawing or as part of the software code or on a change request or electronically. What ever makes the most sense.

In some cases they may be able to read the revision externally which also has a time stamp associated with it.

Sometimes they label the PROM or EPROM with the revision however we will always validate the actual version .

The revision of the PROM or EPROM does not have to be the same revision as the board.

The ATP will require a verification of the software recorded on the ATP report by serial number on the PROM and board...at all locations. Since all the ATP reports travel with the unit, all will be able to see where any changes occured and know/verify the most current REV immediately. When setting up the ATP, the processwill include verification to the PROM as well as the ATP from the prior operation (sister Company)

Got some resistance but they don't know any more than I do....so I decided I was the expert and stuck to my guns.
This set the ground rules, still need to put the change mechanism in place. I wasn't questioning the change method of our sisters, just the communication of the revision we receive and its interchangeability within the product optons.

How far off am I?

I've always controlled a PROM or EPROM as a subassembly of the board. The subassembly has its own assembly number, bill of materials and revision. The subassembly consists of the blank PROM or EPROM (manufactures part number), the firmware and a label. The "drawing" controlling the assembly will list the firmware identity with revision/version and checksum along with applicable programming instructions, testing instructions, packaging, handling or other special instructions. If any part of the assembly changes then the assembly is revised.