engineering lore

Actual electronic design includes a zillion details of actual practice. I have a new PCB layout guy, so we're showing him how we do things.

How are drawings named and numbered? During development and released? Can released drawings be modified? What does a schematic look like? What are standard reference designators? How are pages numbered and titled? What does a title block look like? How are revisions and stuffing options controlled? Where are the official, released drawings archived? Who can change them? What does a PCB look like? What does a BOM look like? What reviews are done? What design records are kept? How are ECOs written and controlled?

and on and on. And then there's firmware.

It occurrs to me that I've picked up this engineering-convention stuff by osmosis from various employers, and made some of it up too. Some people do stuff that seems crazy to me. It's like a trade, carpentry or baking, where people just sort of learn it on the job.

I wonder if there are any industry-wide standards for this sort of thing. Are books published? Do universities teach courses?

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin
Loading thread data ...

I'm sure that there are a good thousand Eurocrats out there who have never designed anything real, but would be happy to tell you that your way is all wrong and try to make you do it in the way they just made up.

(Radiometrists and photometrists tried that, but physical-optics folk like yours truly just ignored them.)

Why not write a lore book? That stuff would make a good chapter.

Cheers

Phil "lore books rock" Hobbs

Reply to
Phil Hobbs

Hardware Design Life Cycle? Firmware Design Life Cycle? Software Design Life Cycle?

Also See RUP

You Might want to read 'Code Complete'

Cheers

Reply to
Martin Riddle

Oh, And stick it all into MS Project, or Project libre.

Cheers

Reply to
Martin Riddle

And make sure that no readme files, no source files, and no build scripts mention the author's name, the date created, or what this thing actually is or does.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

Snort... Actually all that and the Programming enviroment details should be in the Project documentation, some where.

I didn;t see 'Power Budget' in your list.

Cheers

Reply to
Martin Riddle

One general question is whether we document the calculations and assumptions of a design. Five years later, people tend to ask "Why in hell did we do THAT?"

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

The more you document the whole process, the more crap there is to wade through later when you want to work something out. DAMHIKT.

NT

Reply to
tabbypurr

The way the release process dictates.

Any release process that allows this is broken.

As pretty as possible.

1 to 9999. Gaps allowed. It should make sense (not random). ;-)
1 to 9999 sequentially.

The way the boss wants it to look but it should have a title, date(s), name(s), and page number.

Revisions should be controlled through the release process. How stuffing options are done is a function of the tool.

The, release controlled, design database. No one. They may be checked out and modified by anyone but can't be checked back in without going through the release process, with new part or EC numbers assigned. Any less and you're out of control.

Two sides and three or more edges.

What's a piece of paper look like?

Defined by the release process.

That's a *good* question.

Through the release process.

Sure but the process should be documented and followed. When some part of the process doesn't work, change it so that it does. Anticipate problems (like someone accidentally overwriting schematic files, for instance. There should be some database so this can't happen.

I've been trying to bring that home at my CPoE but so far people aren't listening.

I doubt it.

Reply to
krw

Like an ISO9001 audit?

Reply to
Michael A. Terrell

OK, it looks like engineers do have a common design methodology:

Do exactly what you boss tells you to do.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

There is this book "Engineering Documentation Control Handbook" which seems well regarded

I am not sure I like his approach to part numbers, at least as applied to electronics design / PCBs.

For example AIUI the numbers for "bare PCB" and "PCB assembly" would be essentially unrelated. This is logical since the bare PCB is "just" one of the components used to make the PCB assembly. And e.g. the assembly BOM can be revised independently of the bare PCB (resistor value change say). Occasionally the other way around, the PCB could change without changing the assembly BOM - perhaps a footprint is adjusted for better yield but the two versions are in fact interchangeable.

So by this logic "Assembly" and "bare PCB" should have separate drawings, part numbers and revision letters for example.

But in practice it causes quite a lot of confusion since they are in fact rather intimately related.

...

Another thing is his concept of "interchangeable" and "non-interchangeable" changes to a part. If the change made does not affect a parts use in any of the assemblies that use it, then the parts revision letter is bumped but the assembly BOMs do not change. (BOMs just show parts' numbers not their revisions).

If the change is non-interchangeable, then a new part number is created. Any assemblies that want to use the new part have to list the new part number and the revision of the assembly is bumped.

--

John Devereux
Reply to
John Devereux

If you documenting 'Assumptions' then I wouldn't really call that 'Design'

;) Cheers

Reply to
Martin Riddle

I understand his meaning. By assumptions he is possibly referring to the musing that led to the calculations. Calculations alone are usually insufficient.

Reply to
John S

r designed anything real, but would be happy to tell you that your way is a ll wrong and try to make you do it in the way they just made up.

ISO 6000 just insists that every board is traceable and documented - it's u p to you to work out how you do it.

And ISO is international, not specifically European, though the French do l ove working for that kind of organsiation.

You've been taking Donald Trump seriously, rather than thinking for yoursel f.

e yours truly just ignored them.)

Most place do document the stuff that John Larkin seems to imagine that eve ry potential employee ought to know.

At Cambridge Instruments any change in board layout was new issue, and the issue number was etched into the copper on the board. Cut and link modifica tions, and component changes, were "revisions" and the the revision number got written onto the board in indelible ink. Quality Control got shirty if there were more than six cut-and-link modifications on a board.

--
Bill Sloman, sydney
Reply to
bill.sloman

This assumes that the boss knows what he or she is talking about.

When it comes to design details, they almost always don't. Good bosses understand this. Bad ones are happy to impose their ill-informed opinions.

--
Bill Sloman, Sydney
Reply to
bill.sloman

I also like to document (at least partially) the various design dead ends and why those options WEREN'T chosen, so that in the future somebody doesn't come along and revert to a plan with a subtle flaw.

Reply to
Ralph Barone

No, it doesn't. The boss is the boss, right or wrong and has the power to hire and fire. My approach is to give him/her my judgement on the matter and try to explain the consequences of alternate decisions.

After that, I have the choice to do exactly as told or look for employment elsewhere.

Reply to
John S

Any design begins with a bunch of assumptions, some of which get documented as formal specifications. Why not remember the rest?

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

We like to test parts and save the results, including the bad results. I like to test parts to destruction and remember stuff.

One of my engineers is just now building and characterizing a coaxial ceramic resonator oscillator. It behaves a bit differently from the Spice sim, and some things don't simulate at all. She'll deliver a Word document that we can archive, and that may well be useful in some future design.

We work with some giant companies that have moderate turnover, and the new engineers and managers often have no knowledge or access to what their predecessors did, not even emails much less experimental and test results. So we become their (selective? no, we wouldn't do that!) institutional memory.

--
John Larkin         Highland Technology, Inc 

lunatic fringe electronics
 Click to see the full signature
Reply to
John Larkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.