Eagle library editor

become

An Engineering Change Order is a directive to take exception to a specific, named, released manufacturing document. It's pretty clear to us what's an ECO and what isn't.

Everything manufacturing makes or tests is done in compliance with released documents, created by engineering, signed by me. An ECO is one such document. Of course we can do anything.

John

become

So you have ECOnnnn abd DEVmmmm ?

Why bother?

I'm the Chief Engineer, so I review and sign all ECOs, both for technical content and clarity and to ensure that they fit logically into the documentation. And so that I know what's going on.

John

then to

numbers for

that

didn't

changes.

Joerg specified a replacement parts that was FFF identical. That just requires us to add an approved vendor/VPB to our inventory database.

If a value needs to be changed, that takes an ECO.

No, we just roll the rev letter and (formally) release the new documentation set. Some people cut an ECO whenever they release (or do) anything, but we don't issue an ECO to release letter revs of drawings.

When we roll a rev for any reason, The Brat looks up all ECOs and all comments in the NEXT file for the current assembly. NEXT is a text file that anybody can edit, to make notes or request changes. Manufacturing or test may make a suggestion to make something easier to assemble and test, for example, or someone may suggest a part substitution, a feature, whatever. Engineering reviews all the changes, of course.

The NEXT thing is great. It's part of our institutional memory. Bratinella also documents what was actually done, and why, in a README file that gets released with the docs.

John

then to

numbers for

that

didn't

changes.

I've done NASA flight hardware, where every single part on every single board had to be traceable, had a CofC, and had incoming test records on file. And government inspectors came in and inspected everything. I decided to do none of that in my company.

A board that was etched as "A" is always "A" to us.

I promise I won't.

John

writing home

design is

defined by

he

ECOed

separate

BOMs,

There

the

So we know which schematic to print when we want to work on a board!

John

become

of

Sure, but if whatever *you* say is an ECO is an ECO, then what's the point? ECOs have "buy-in" from all relevant parties. In every such process I've seen, ECOs and deviations are different things (sometimes there is a gray area).

Then why bother with ECOs? Just send a memo to Joe in manufacturing with the header, "Build This".

way.

Ok, would you be happier if I spelled it "Aerospace life sustaining"?

The processes do, I assume.

What's the difference? Someone's dead.

become

of

Sure. Deviations are made to ECOs.

Because a deviation is a temporary measure. It changes an ECO controlled product or process. It's only used when something is wrong with the normal process and gets revoked when the process goes back to normal. ECOs are forever.

But what about your purchasing guy, your manufacturing guy, the engineer who did the work? Where are there John Hancock's? Everyone has to agree that this is what we're going to do. If it's just the guy in the front office, what's the point?

become

of

be

The point is that we build things to released documents, and we know exactly what we did and why/when we did it.

One of my gigabuck customers - the people who use Agile, with a zillion sign-offs on every document - has shipped a half dozen of their new gadgets, at about $15e6 a pop, which is a subassembly of a fab tool that goes for $120e6 each. Nobody knows what actually went into those first six systems, but there are a few guys trying to figure it out. We don't do that.

How do you identify a "gray" document? ECO214, DEV8816, GRY2403? Now we have three forms of exception documents.

We have an ECO form we fill out and release. It's a released ECO, or it isn't.

That is absolutely forbidden. As is verbal direction to take exception to drawings. You should understand the difference and implications between released, archived documents and hearsay.

John

become

of

So, after a while, you forget that the deviation ever happened. That could get interesting.

Whoever authors an ECO signs it. I approve it for release by signing it somewhere else. How else could it work?

John

[...]

Ok, but if assembly rev A has a problem, which gets fixed, which turns the assy into a rev B, then the board is still rev A. I thought you kept those rev levels together.

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

writing home

design is

defined by

he

ECOed

separate

BOMs,

There

the

At all of the companies I've ever worked with the rev level of a raw (bare) board, meaning the etched one, has no bearing whatsoever on the schematic. The PCB is merely one item on the BOM that goes with that schematic. So the bare board could be rev A and the schematic rev C. The assy must of course, also be rev C.

--
Regards, Joerg

http://www.analogconsultants.com/

then to

numbers for

is that

didn't

ECO

changes.

Dangerous. FFF identical for this board, yes. But on another board that can backfire if you release it as a full 2nd source part for everything. For example some really old designs may go berserk if the new part switches faster than the old one.

[...]

--
Regards, Joerg

http://www.analogconsultants.com/

part

become

out of

That's

intended

be

So? A process is only as good as the people using it. A great process can be subverted quite easily. If you want another cliche, a computer will only make your disorganization faster.

No, silly. You choose the one that you think fits the situation best. Sometimes the future is unknown so you go with the best information at the time. Fix it later, if necessary.

...but you still don't have input from the relevant people and their buy-in.

Your "ECO" is essentially an order to "build this". It's a one-way street.

part

become

out of

That's

*I* might forget but Agile doesn't. The records of each S/N tell which ECO and any deviations it was built under.

You said that your signature was the only one on ECOs.

for

We used the same sort of "whiteboard" but only for the assembly/BOM rev. The raw board rev was in the silk. There was no good way to go from an engineering number to a production number (so engineering numbers were only used for boards with about zero chance of ever making it to production).

then to

numbers for

is that

didn't

ECO

changes.

That's OK but can lead to problems (parts aren't exactly the same) with tracability, if that's needed. OTOH, it's no different than two suppliers up front.

A different board without an ECO? Ohhhhh! We'd have an ECO (bare board rev + BOM rev) for the kludged board and another ECO (different bare board rev + BOM rev). Because the boards are different part numbers, the BOM has to change. That's reason enough for an ECO.

We'd do a similar thing, though the notes were kept on a "working" copy of the schematic.

That should be in the ECO documentation. "Why was this ECO done."

writing home

design is

defined by

he

ECOed

separate

BOMs,

There

the

Because the schematic is what produced the raw board. The two are linked.

part

levels become

out of

That's

are

be

intended

a

was

to be

Fix it later? Decide that an ECO should have been a "deviation" and change it after the fact, after it's released? Nightmare.

Of course we do. Engineers control drawings: that's our job. We get input from everyone. I'm the untimate sign-off on all documents, and I check with whoever I think might be affected. That's a heap better than having an ECO take weeks to be signed off by a list of suits who have no ability to understand what's happening.

Of course it's a one-way street. Manufacturing is required to build and test per released documents and nothing else. All our documents say "build this."

Engineering creates those documents: that's our function.

Who creates design documents in your company?

John