Re: Release/Revision standard notation?

These days I suspect the best approach to "archiving" a system would be to create a virtual machine with all the tools installed.

Although as Joerg/Tim point out, there's still a problem if any of it is dongled.

Where I work our hardware releases are just "vX.YZ" where changes in X refer to new physical PCBs and changes in Y usually refer to some "significant" hacks (blue-wires -- or drilling out holes or something for mechanical pieces) on the board whereas changes and in Z usually refer to component value changes.

For software, we don't have any real standard, although I've generally a proponent of just stick a timestamp (full date & time) on the release -- which can be easily automated with the build tools. This completely eliminates the very common problem where someone finds a bug, some programmer fixes it (or at least attempts to), providers a test with a new binary... but the binary still claims to be the exact same version number as the buggy release. :-(

"?

"Only wimps use tape backup; *real* men just upload their important stuff on FTP, and let the rest of the world mirror it ;)" -- Linus Torvalds

...

Migrating code for tools no longer manufactured/sold actually means=20 that the simpler and cost effective solution for some markets is actually to archive complete computer systems as changing the tools means revalidation/certification. Even if you could get the new versions of tools to work with newer computers/operating systems/etc..

Especially if you have last time buy on components even at wafer level because you are making parts for aircraft, classic examples would be

=09Boeing 747 =09C130 (Hercules in UK) =09Nimrod (originally Comet airframe circa late 1950's)

Having recently looked at some testing equipment that has to work for at least 10 years, I am aware of the issues and multiple paper/CD/network storage of documents etc..

--=20 Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services Timing Diagram Font GNU H8 - compiler & Renesas H8/H8S/H8 Tiny For those web sites you hate

What is git?

Jim

I use it too.

I agree is it very fast and efficient - so much so that I am considering adding all my tools to the version control, as well as the "documents" (source code, schematics etc).

It's the revision control system used for the Linux kernel. You can get it at

Cheers,

Phil Hobbs

on"?

rd

ote

as

al

me,

r,

we

Once again, RH shows his infinite ignorance.

In article ,=20 snipped-for-privacy@pcserviceselectronics.co.uk says...>=20

r,

we

No one specified code, though that is a bigger problem. How much=20 bigger depends on the tools (another vote for VHDL vs. schematic,=20 IMO).

If you're in a lifetime buy situation the tools don't matter,=20 however documentation still matters.

Why single them out?

Why is test equipment a problem?

r,

we

t -

In my first job, all released documents were paper, even computer source-code listings which would be impractical to retype and unlikely to be redone without error. PCB artwork soource documents were hand- taped vellum.

In my last job, all released documents were electronic files archived on the local network, backed up on the corporate network across the country, and periodically archived on "tape" at a local disaster backup business. Most documents produced were part of the natural design flow (schematic diagrams, part lists (with some massaging), PCB artwork "Gerber" files, FPGA source code, etc). The most difficult and time-consuming documents to produce were Source Control Documents, a way of assigning our part number to someone else's product, which usually consisted of a cover sheet followed by pages copied from a vendor data sheet or catalog.

That's not a problem, it's a feature!

John

Everything is released to the library server, a big RAID thing. We do nightly backups to another server and weekly DVD backup, stored in multiple off-sites.

We submit files to the librarian on floppies or CDs, and after the files are copied those originals are also stored off-site. We have had media go obsolete, like tapes, and we always make sure we have good copies on current-generation media.

We have had a few files corrupted on the server, not many, and it was easy to recover them from backups. Our inventory database file has been in continuous use for over 10 years.

I do have some old 8" floppies that might be hard to read.

John

Then I wonder what the mirror of the Dash-8 was :-)

You almost have to, at least if there is as much as one little iota in assembly change cause by the artwork change. With assembly rev changes the PCB rev does not need to change, and often doesn't in my cases.

Same in medical. If the federales waltz in for a spot check you have x minutes to produce a requested document such as a design history for the inspector. With "x" being single-digit.

I have a couple half height 8" drives in storage. I saved them, because they were some of the last built, and have all DC motors.

... and pretty much all the clients I work for. Else I would most likely decline to consult for them. Without a formal release process you'd be only a few footsteps away from a major lawsuit should something happen. Because plaintiff's counsel will dig that out.

Aha. I see!

I often use two+ digit revisions for circuit etch/revisions

A original etch and circuit match A1 Etch level A modified to circuit rev A1

B Etch level B rollup match circuit Rev B

To facilitate this the ident layer has etch and circuit rev shown as letter for etch and white block for circuit rev added as part of the manufacturing/testing process.

Make sure I keep reference of what revisions are shipped.

ion

ter,

f we

There is no point archiving data that is in 90% of the time (or more) anything other than plain text, without the tools to read it, even if it is just to print out new copies.

Any archiving is for evaluations and possible modifications later, this could be many years later, that you need to rebuild then modify code for software, FPGA or even modelling of circuits or pcbs in electronic form. In some cases it is to prove again that the design process is modelled correctly or run scenarios on old simulators first.

Yes they do as any part may have to be modified later and progrrammable parts may need revised coding, even parts on wafer need alternative packaging requirements for later batches that then means a new PCB or even heatsink arrangements. =20

They were not singled out, but as it showed above "classic examples". I could have used many others.

One classic I had about 5 years ago was for an NMR scanner, where I was looking at replacing a failing part of it, and the EARLIEST date they could find for the machine was

"...in 1968 it moved to the NEW building.."

rk

Over the last 10 years more and more test equipment and test procedures are computer controlled so the test equipment, procedures, test=20 programmes, and ancillary equipment, needs to be documented and archived.

Test equipment and for testing various parts, subsystems, or systems sometimes requires dedicated testing equipment. This is part of the=20 manufacturing process. All parts of the procedures and methods from basic= =20 pcb, loading code to test procedures or programme controlled tests, needs= =20 to be archived and maintained. EVEN IF THE UNIT IS THIRD PARTY PURCHASE.

Changes in these also have to be reverified and ecrtified on changes, some of which are due to equipment changes, others due to testing=20 modifications.

Four of my designs over the last two years are specialised ASIC testers, and I have more to do in the pipeline.

--=20 Paul Carpenter | snipped-for-privacy@pcserviceselectronics.co.uk PC Services Timing Diagram Font GNU H8 - compiler & Renesas H8/H8S/H8 Tiny For those web sites you hate

That's not bad at all. Full MIL standards require an ECO to change something, so your "A1" becomes "assy 12345-1A ECO 1412 ECO 1618", with labels stuck on the poor thing somehow.

We are rarely forced to revise a drawing but keep it coherent with other rev B drawings, so we re-issue it as rev B1. This is generally to correct a drawing error.

John