Standards...

[Don Y]

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?

 

[John Larkin]

On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Every company seems to have its own standards for development,
engineering documentation (if any!), production drawings,
drawing/product/part numbers, BOMs, ECOs, software development,
manuals, specs, everything. Some loose commonality is created by
people moving about between companies.

None of this stuff seems to be mentioned in engineering schools.

Is there some documentation on how to run an electronics engineering
company?

One big company assigns a 12-digit number to anything. Products,
drawings, manuals, buildings, employees, everything. I think they just
pick the next number when they want one.

Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

Yes. One of my customers (a giant national lab) has asked us to tell
them how we do reliable design! I should write something up.

DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

\"Good engineering practice\" is usually emotional prejudice. Sometimes
people sniff \"That\'s not professional\" or \"Customers won\'t approve\" of
that screw head, or color, or something.

There are crazy ideas about grounding.

Abs max ratings are another issue. Some people won\'t get anywhere
close to abs max, guardbanding the manufacturer with a second
guardband. Some people go way over. I run some parts at 2x abs max
voltage and get real performance advantages over the timid.

Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?

We just rolled our own, but the rules are themselves well documented
in our PNP (policies and procedures) folder on a server. Low-level
design (what that lab wants) isn\'t much documented.

Somebody should write a book about how to manage electronic design and
documentation. Is there one?

And maybe they could sell the system to startups.

 

[server]

Years ago, I did analog safety circuits for medical electronics. These days it all done with a second safety processor or fpga. I had to do worst case analysis and single point failure analysis. I don\'t remember how much guidance 60601, 610xx or the FDA gave on it, but they needed to be done. I do recall some military docs that were useful in writing them.

I really didn\'t want more bureaucracy in the design process. There were necessary rules for the documentation submitted at the end and the testing that proved the design (verification and validation). I was a believer in writing theories of operation. Most of the other engineers weren\'t. The process started with me writing a document describing the specification and requirements of the design and getting that approved. I would then do the schematic and theory of operations. I liked having two review meetings. One with the project, system, mech, software, production, and compliance engineers and another peer review with the other EE\'s. Some liked to have just one big review with everyone. Then prototyping and testing and then another pair of review meetings. Then system integration and more review meetings, then compliance testing and production release and more document reviews meetings. The electronics design really wasn\'t the biggest part of the job. Guiding the design through the process and making sure everyone was happy with it and all the paper work that accompanied it was. Adding more standards so some QC guy could bother me while I was working on the design is not somethin
g I would want.

 

[Wim Ton]

I am always a bit surprised by the medical sector. Technically, they, want equipment with space, mil, or better qualificalitions. But OTOH, it is totally accepted that people are treated by trainee doctors putting in 80 hour working weeks, that doctors that are banned for malpractice can start afresh in another state or country, that the statistics on the effectiveness of treatments are often very thin, etc.

Wim

 

[Wim Ton]

On Sunday, 20 November 2022 at 17:49:51 UTC, Wand...@noplace.com wrote:

Years ago, I did analog safety circuits for medical electronics. These days it all done with a second safety processor or fpga. I had to do worst case analysis and single point failure analysis. I don\'t remember how much guidance 60601, 610xx or the FDA gave on it, but they needed to be done. I do recall some military docs that were useful in writing them.

I really didn\'t want more bureaucracy in the design process. There were necessary rules for the documentation submitted at the end and the testing that proved the design (verification and validation). I was a believer in writing theories of operation. Most of the other engineers weren\'t. The process started with me writing a document describing the specification and requirements of the design and getting that approved. I would then do the schematic and theory of operations. I liked having two review meetings. One with the project, system, mech, software, production, and compliance engineers and another peer review with the other EE\'s. Some liked to have just one big review with everyone. Then prototyping and testing and then another pair of review meetings. Then system integration and more review meetings, then compliance testing and production release and more document reviews meetings. The electronics design really wasn\'t the biggest part of the job. Guiding the design through the process and making sure everyone was happy with it and all the paper work that accompanied it was. Adding more standards so some QC guy could bother me while I was working on the design is not something I would want.

The process sounds familiar to IT security certification. The manufacturer must show convincingly that the threats are mitigated. This will be independently evaluated at the documentation level and by a penetration test. In some schemes, the evaluators are under tight quality control. Not only their processes must be up to scratch, but occasionally the same product is evaluated by several labs, and the overseer checks if the results are comparable. For the evaluator, it is walking on a tightrope; too fussy and you lose your customers, too lenient and you lose your accreditation.

Wim

 

[legg]

On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?

Electronic hardware min/max are tied to environment and mtbf
requirements. ~ a specification.

Layout and mech have to tightrope walk through production
capabilities. ~ a financial decision.

Quality is established, demonstrated and maintained through vigilence
or testing; before, during and after fab. ~ by savvy personnel.

If it\'s not designed in and competently conveyed, it won\'t be there.

Whatever is adopted needs documentation to satisfy the ISO9000-ish
certification, if that alone is the aim. Honking great binders
of paper bumph used to satisfy.

RL

 

[Joe Gwinn]

On Sun, 20 Nov 2022 08:01:51 -0800, John Larkin
<jlarkin@highlandSNIPMEtechnology.com> wrote:

On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Every company seems to have its own standards for development,
engineering documentation (if any!), production drawings,
drawing/product/part numbers, BOMs, ECOs, software development,
manuals, specs, everything. Some loose commonality is created by
people moving about between companies.

None of this stuff seems to be mentioned in engineering schools.

Is there some documentation on how to run an electronics engineering
company?

One big company assigns a 12-digit number to anything. Products,
drawings, manuals, buildings, employees, everything. I think they just
pick the next number when they want one.

Most likely, as this greatly reduces the likelihood of confusion due
to accidentally reusing a number.

Modern documentation management systems allow \"drawing numbers\" to be
an arbitrary string of alphanumeric symbols up to some large length
(255 bytes?). Probably support Unicode as well, so they can be sold
in places that don\'t use any Roman alphabet. Like many Asian
countries.

Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

Yes. One of my customers (a giant national lab) has asked us to tell
them how we do reliable design! I should write something up.

Were they looking for that magical process that would allow
high-school dropouts (meaning not PhDs) to design cutting-edge
electronics?

This being exactly what I found myself in back in the day when
Knowledge Engineering was a the new new thing.

I recall being interviewed by a KE who basically asked me to tell her
everything I knew, and assumed that I was hiding things when I replied
by asking for a specific question. The interview didn\'t go well.

Nor could this have worked even in theory, because much of expertise
is in recognizing the parallels between something current and
something apparently unrelated and only dimly remembered until that
something was first encountered, and the necessary realization may
take a few nights to a week to emerge.

And back in my software days, we had a new development process that
repealed that of the year before. The underlying intent for all these
proposals was to find that magical process that would allow
high-school dropouts to write missile seeker code running in a tiny
computer that cycled at the 128 Hz necessitated by missile
aerodynamics and stability requirements.

We still have process after process, with Agile being the mature fad.
It\'s always faster faster faster, be innovative, but plan things out
in fine detail, ... (but never make a mistake).

I just love the people trying to manage innovation.

DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

DRC?

\"Good engineering practice\" is usually emotional prejudice. Sometimes
people sniff \"That\'s not professional\" or \"Customers won\'t approve\" of
that screw head, or color, or something.

Usually encapsulates the latest fads.


>There are crazy ideas about grounding.

Oh, yes.

Abs max ratings are another issue. Some people won\'t get anywhere
close to abs max, guardbanding the manufacturer with a second
guardband. Some people go way over. I run some parts at 2x abs max
voltage and get real performance advantages over the timid.

This often is decided by the customer, their objective being long
service life without much repair, so it just works when it abruptly
matters.

Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?

All that ISO 9000 requires is that you have a written process and to
follow it, with proofs all along. But ISO 9000 does not require that
the process be good for anything at all.

Your last step before delivery could be to pour 100 milliliters of
concentrated hydrochloric acid into the product and quickly install
the hermetic cover.

We just rolled our own, but the rules are themselves well documented
in our PNP (policies and procedures) folder on a server. Low-level
design (what that lab wants) isn\'t much documented.

Somebody should write a book about how to manage electronic design and
documentation. Is there one?

There must already be, and I thing I saw a bunch of similar things on
the discard shelf at the company library.

Along with many software process tomes.


>And maybe they could sell the system to startups.

Maybe...

Joe Gwinn

 

[Rich S]

On Sunday, November 20, 2022 at 11:18:36 PM UTC, Joe Gwinn wrote:

On Sun, 20 Nov 2022 08:01:51 -0800, John Larkin
jla...@highlandSNIPMEtechnology.com> wrote:

On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blocked...@foo.invalid> wrote:

[snip]
Hi Don , the answer depends on what industry your
friend & his clients are in. ISO 9000 family, for a general
manufacturer, is certainly one good place to start.

Since the 1990\'s major industry sectors, like the
automobile industry, have rolled their own
offshoots or extensions of the ISO docs.

IME, ISO 9001 was easy for take on for companies
that already had good practices and records, etc.
But was sheer hell for some small or under-resourced
companies, especially if things like \"version control\"
were foreign concepts!

Companies hire a professional QA consultant
to help them thru the ISO 900x registration process.
I recall it can take a few years of \"patching\" the
workflows across the organization, and teaching
them how to document things. Slow but steady...
Its also vital for the CEO to relentlessly push
his/her people to prioritize it.

 

[Don Y]

On 11/20/2022 12:49 PM, Wanderer@noplace.com wrote:

Years ago, I did analog safety circuits for medical electronics. These days
it all done with a second safety processor or fpga.

Yes, we would design analog \"limit detectors\" to invoke shutdown
circuits, in hardware, to cover the case of a rogue processor
driving the mechanism into the rails.

But, that largely to protect personnel and equipment. And,
appease customers who were terrified that they could loose
many kilobucks of investment in a few milliseconds.

[My medical instruments never had direct patient contact, but one.
And, even that was only in an advisory role -- home health \"aid\"
to dispense meds, audio/video over POTS, remote telemetry, etc.]

I had to do worst case
analysis and single point failure analysis. I don\'t remember how much
guidance 60601, 610xx or the FDA gave on it, but they needed to be done. I
do recall some military docs that were useful in writing them.

I really didn\'t want more bureaucracy in the design process.

I\'ve met few engineers who *do*! Yet, I\'ve had clients force me to
draw particular devices in particular ways, put signal names in
specific places (adhering to particular rules for choice of name),
etc.

I had a client who would leave snippets of previous revisions of
a schematic *in* the schematic on its original page to save the
viewer from having to chase down individual ECOs or old revs
of the drawing. For all but trivial changes, this quickly makes
a drawing useless!

There were
necessary rules for the documentation submitted at the end and the testing
that proved the design (verification and validation).

I have client documents that require the *capabilities* of the
designers to be catalogued along with the design. The premise
being that the designer should be *qualified* to do the design!
(WTF?! How do you make that decision?)

Software is almost always micromanaged -- each function/subr having
test criteria and \"proof\" that a particular test suite has been run
against it -- TWICE! (though no guarantee that the test cases are
actually RELEVANT to the implementation). Names for all objects to
adhere to some formulaic pattern, sometimes *size* or *type* of object
conveyed in the chosen name (because its only natural to embed all
of that information in EVERY name, right? hmDon -- for Human Male Don?)

[Some of this can now be automated to ensure \"coverage\" -- much
like automatic test vector generation for logic designs]

My personal favorite:
\"Is source code annotated clearly?\"
Wow, how do you give an objective answer to THAT?? <rolls eyes>

I was a believer in
writing theories of operation. Most of the other engineers weren\'t. The
process started with me writing a document describing the specification and
requirements of the design and getting that approved.

So, sales/marketing had to buy into *your* process. This is how I\'ve
approached clients: \"Let\'s figure out what we\'re trying to design
BEFORE we actually design it (and, this will give us an agreed upon metric
to determine if the contract has been completed, satisfactorily)\"

[No, I have no desire to finish the design and, seeing it reified, have
you complain \"that\'s not what I want\" -- pay the man and find someone
else to make a second stab at your uncertainty!]

I\'ve found that writing a detailed manual can act as a good specification.
The information contained in it has to exist *somewhere* for the user
to review so let\'s nail it down, now (instead of forgetting about it,
later). This also helps you cover many of the unexpected situations
that you might not have foreseen, otherwise (e.g., what happens if
connector X is unplugged? Now? And NOW??)

I would then do the
schematic and theory of operations. I liked having two review meetings. One
with the project, system, mech, software, production, and compliance
engineers and another peer review with the other EE\'s. Some liked to have
just one big review with everyone. Then prototyping and testing and then
another pair of review meetings. Then system integration and more review
meetings, then compliance testing and production release and more document
reviews meetings.

But, was any/all of this documented in a requirements standard? Or,
just YOUR idea of \"good engineering practice\"?

The fact that other engineers had different approaches (which, presumably,
were \"tolerated\") suggests it was just your own notion of how things should
be done (?)

The electronics design really wasn\'t the biggest part of
the job. Guiding the design through the process and making sure everyone was
happy with it and all the paper work that accompanied it was. Adding more
standards so some QC guy could bother me while I was working on the design
is not something I would want.

The problem with *most* standards is that they address the wrong issues
but, by sheer volume, try to suggest they are actually DOING something
(that adds value).

If you look at the folks drafting those standards, they often don\'t
understand the technologies that they are trying to constrain. Like
expecting an EE to set up the ACCOUNTING standards that your firm
will use... and wondering why you didn\'t pass the IRS audit!

 

[Don Y]

On 11/20/2022 4:37 PM, Rich S wrote:

Hi Don , the answer depends on what industry your
friend & his clients are in. ISO 9000 family, for a general
manufacturer, is certainly one good place to start.

But most of that addresses *process*, not the details of
(e.g., hardware) design. It says nothing about the
quality of your process but, rather, how well you have
implemented and adhered to it.

Its as if your *acknowledgement* that there needs to be
*a* process is the primary goal.

There are other corporate/organizational issues that can
render even the best processes ineffective. E.g., having
your \"Quality\" or \"Safety\" staff reporting to *Manufacturing*
lead will likely find those issues losing significance when
production quotas are at stake!

And, many criteria are hard to objectively quantify -- measure.
Is \"DoSomething\" a GOOD name for a signal on a schematic?
What about \"Signal12994\"? \"TemperatureHigh\" vs. \"HighTemperature\"?

Since the 1990\'s major industry sectors, like the
automobile industry, have rolled their own
offshoots or extensions of the ISO docs.

IME, ISO 9001 was easy for take on for companies
that already had good practices and records, etc.

I.e., firms who already had ACKNOWLEDGED THE NEED FOR A PROCESS!

But was sheer hell for some small or under-resourced
companies, especially if things like \"version control\"
were foreign concepts!

Or, any other sort of \"structure\". I recall watching JIT/MRP
being introduced at a modest size firm. The degree of
discomfort among folks who were being told NOT to pad their
schedules (as they had always done) to cover \"contingencies\".
If X claims it will have Y ready for you at time T and you
need N time units to complete your task, then COMMIT to
providing your results to your downstream consumers at T+N!

(\"But what if X *doesn\'t* have Y ready for me at time T?\"
\"That\'s not your problem! We\'ll have to fix X!\")

Small companies are notorious for implementing ad hoc
systems to address problems instead of putting procedures
and mechanisms in place to address them. E.g., silly part
numbering systems where you (think!) can determine the nature
of the item simply by examining the part number. Or, fabricate
a part number from a description of the item. (we have
machines that can associate arbitrary numbers with incredibly
complex descriptions of items and retrieve that information
in milliseconds -- at a nearby \"terminal\" or even your phone!)

[I recall trying to explain to the head of manufacturing that
ROM #1 with part number 12345 is *just* ROM #1. He has no need
to understand which bits of code reside in it because doesn\'t
have a one-to-one correspondence with any particular product
functionality. When you revise that part number, you will also
have to revise several other part numbers to obtain a working
configuration. Just like if you change a #6-32 PHMS to a #4-40,
you\'ll also have to change the mating hex nut!]

Companies hire a professional QA consultant
to help them thru the ISO 900x registration process.
I recall it can take a few years of \"patching\" the
workflows across the organization, and teaching
them how to document things. Slow but steady...
Its also vital for the CEO to relentlessly push
his/her people to prioritize it.

Yes. The JIT/MRP case I mentioned required EVERYONE in the company
(even the factory workers) to attend classes. A *huge* expense for
a modest sized firm. But, it was important for everyone to understand
the \"new mindset\" -- *why* it is important that X has Y ready at time T!)

But, the point of my question was to identify specific \"requirements\"
that folks impose on their hardware designs. If I write a piece of
code to check that a value is \"in range\", I have to test that code
with specific documented test cases. And, implement it in a way that
conforms to some \"coding guidelines\" and avoids certain idioms, etc.

OTOH, if I put a window comparator in the corner of a schematic, there\'s
no free-standing test procedure that verifies its operation and defines
how it is designed/implemented: \"Ah, the board has passed the window
comparator test! Now, we can move onto the memory bus test...\"

 

[Don Y]

On 11/20/2022 12:46 PM, Wim Ton wrote:

I am always a bit surprised by the medical sector. Technically, they, want
equipment with space, mil, or better qualificalitions. But OTOH, it is
totally accepted that people are treated by trainee doctors putting in 80
hour working weeks, that doctors that are banned for malpractice can start
afresh in another state or country, that the statistics on the effectiveness
of treatments are often very thin, etc.

Equipment is mass-produced. If doctor\'s were truly interchangeable then
certification process for them would similarly benefit from more rigorous
standardization.

And, doctors *individually* carry malpractice insurance. An equipment
manufacturer isn\'t magically indemnified by the purchaser of his kit.

Note that much medical/pharma isn\'t as definitively \"regulated\" but,
rather, adheres to a set of \"best practices\" established by their
industries. E.g., doing a radical mastectomy *today* would see
more scrutiny than 40 years ago. Similarly, a lumpectomy 40 years
ago would raise eyebrows. Both being \"outside the accepted norm\"
for current (at their times) practice.

[Much of this is likely driven by \"what will give me some sense of
LEGAL COVER if I adopt that practice vs. leaving me at risk for
deviating from it\"]

 

[Don Y]

On 11/20/2022 1:01 PM, Wim Ton wrote:

The process sounds familiar to IT security certification. The manufacturer
must show convincingly that the threats are mitigated. This will be
independently evaluated at the documentation level and by a penetration

But, that\'s a subjective criteria. *What* threats? Is that left up
to the pentester\'s discretion? (Then, how do you \"qualify\" your
pentester??)

By contrast, we can both look at a schematic and determine what the
operating conditions for component X happen to be and whether or
not the device selected for that role is up to the challenge.
This can be measured and codified, objectively.

A pentester can only evaluate the product\'s ability to ward off
a certain set of tests that *he* can conceive of at the time of test.
(more testers doesn\'t guarantee more coverage if, for example,
they are all working off the same threat lists).

E.g., I designed my network fabric to support a hostile actor
applying a 20KV pulse directly to the individual connectors
(because some network drops exist in locations lacking physical
security). Because someone could easily do that and I would need
to ensure the fault wouldn\'t propagate to the switch, etc.

Is the NIC on your AP similarly protected/tested? Or, is \"it
broke\" an acceptable failure (that you need not test for)?

test. In some schemes, the evaluators are under tight quality control. Not
only their processes must be up to scratch, but occasionally the same
product is evaluated by several labs, and the overseer checks if the results
are comparable. For the evaluator, it is walking on a tightrope; too fussy
and you lose your customers, too lenient and you lose your accreditation.

That\'s true of self-certifying industries, as well. Witness the 737MAX
issue and its fallout.

 

[server]

On 11/20/2022, Don Y wrote:

So, sales/marketing had to buy into *your* process. This is how I\'ve
approached clients: \"Let\'s figure out what we\'re trying to design
BEFORE we actually design it (and, this will give us an agreed upon metric
to determine if the contract has been completed, satisfactorily)\"

No. I was a lowly implementer. I had to write the specifications for my circuits before they would let me do anything. On top there was a System Design Spec(SDS). Then there was an Electronics Architecture Spec that laid out the requirements for all the boards, circuits, power, etc, involved in the electronics design. I would do a hardware design spec with references that linked all the way back to the SDS. I guess it proved I had read and understood the necessary parts of the other documents and knew what I was supposed to be doing. My spec would also be used to write my verification test.

Then there were phases and gateways where I would have to get stuff signed off before they let me move on to the next stage. I had some lead way on how I would get those approvals.

In the end I signed off on it. I was the engineer and it was my responsibility to make sure all the specs on the parts were correct and that the design worked. No amount of standards are going to reduce engineering to a bunch of checklists.

 

[wmartin]

On 11/20/22 15:18, Joe Gwinn wrote:

On Sun, 20 Nov 2022 08:01:51 -0800, John Larkin
jlarkin@highlandSNIPMEtechnology.com> wrote:

On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Every company seems to have its own standards for development,
engineering documentation (if any!), production drawings,
drawing/product/part numbers, BOMs, ECOs, software development,
manuals, specs, everything. Some loose commonality is created by
people moving about between companies.

None of this stuff seems to be mentioned in engineering schools.

Is there some documentation on how to run an electronics engineering
company?

One big company assigns a 12-digit number to anything. Products,
drawings, manuals, buildings, employees, everything. I think they just
pick the next number when they want one.

Most likely, as this greatly reduces the likelihood of confusion due
to accidentally reusing a number.

Modern documentation management systems allow \"drawing numbers\" to be
an arbitrary string of alphanumeric symbols up to some large length
(255 bytes?). Probably support Unicode as well, so they can be sold
in places that don\'t use any Roman alphabet. Like many Asian
countries.


Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

Yes. One of my customers (a giant national lab) has asked us to tell
them how we do reliable design! I should write something up.

Were they looking for that magical process that would allow
high-school dropouts (meaning not PhDs) to design cutting-edge
electronics?

This being exactly what I found myself in back in the day when
Knowledge Engineering was a the new new thing.

I recall being interviewed by a KE who basically asked me to tell her
everything I knew, and assumed that I was hiding things when I replied
by asking for a specific question. The interview didn\'t go well.

Nor could this have worked even in theory, because much of expertise
is in recognizing the parallels between something current and
something apparently unrelated and only dimly remembered until that
something was first encountered, and the necessary realization may
take a few nights to a week to emerge.

And back in my software days, we had a new development process that
repealed that of the year before. The underlying intent for all these
proposals was to find that magical process that would allow
high-school dropouts to write missile seeker code running in a tiny
computer that cycled at the 128 Hz necessitated by missile
aerodynamics and stability requirements.

We still have process after process, with Agile being the mature fad.
It\'s always faster faster faster, be innovative, but plan things out
in fine detail, ... (but never make a mistake).

I just love the people trying to manage innovation.


DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

DRC?


\"Good engineering practice\" is usually emotional prejudice. Sometimes
people sniff \"That\'s not professional\" or \"Customers won\'t approve\" of
that screw head, or color, or something.

Usually encapsulates the latest fads.


There are crazy ideas about grounding.

Oh, yes.


Abs max ratings are another issue. Some people won\'t get anywhere
close to abs max, guardbanding the manufacturer with a second
guardband. Some people go way over. I run some parts at 2x abs max
voltage and get real performance advantages over the timid.

This often is decided by the customer, their objective being long
service life without much repair, so it just works when it abruptly
matters.


Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?

All that ISO 9000 requires is that you have a written process and to
follow it, with proofs all along. But ISO 9000 does not require that
the process be good for anything at all.

Your last step before delivery could be to pour 100 milliliters of
concentrated hydrochloric acid into the product and quickly install
the hermetic cover.


We just rolled our own, but the rules are themselves well documented
in our PNP (policies and procedures) folder on a server. Low-level
design (what that lab wants) isn\'t much documented.

Somebody should write a book about how to manage electronic design and
documentation. Is there one?

There must already be, and I thing I saw a bunch of similar things on
the discard shelf at the company library.

Along with many software process tomes.


And maybe they could sell the system to startups.

Maybe...

Joe Gwinn

Naa, they sell them to MBA\'s that just know that if they could eliminate
all those pesky, expensive engineers and hire some cheap crank turners,
they would be the next CEO...

 

[Don Y]

On 11/20/2022 10:12 AM, Wanderer@noplace.com wrote:

On 11/20/2022, Don Y wrote:

So, sales/marketing had to buy into *your* process. This is how I\'ve
approached clients: \"Let\'s figure out what we\'re trying to design BEFORE
we actually design it (and, this will give us an agreed upon metric to
determine if the contract has been completed, satisfactorily)\"

No. I was a lowly implementer. I had to write the specifications for my
circuits before they would let me do anything. On top there was a System
Design Spec(SDS). Then there was an Electronics Architecture Spec that laid
out the requirements for all the boards, circuits, power, etc, involved in
the electronics design. I would do a hardware design spec with references
that linked all the way back to the SDS. I guess it proved I had read and
understood the necessary parts of the other documents and knew what I was
supposed to be doing. My spec would also be used to write my verification
test.

Then there were phases and gateways where I would have to get stuff signed
off before they let me move on to the next stage. I had some lead way on how
I would get those approvals.

In the end I signed off on it. I was the engineer and it was my
responsibility to make sure all the specs on the parts were correct and that
the design worked. No amount of standards are going to reduce engineering to
a bunch of checklists.

Of course. And no amount of standards is going to ensure a medical
device doesn\'t cause damage; that a mars rover won\'t \"get confused\";
that an airplane won\'t \"dive\" when it should be climbing; etc.

Standards try to codify practices that we HOPE will improve some
aspect of a product or process.

 

[Don Y]

On 11/20/2022 1:57 PM, legg wrote:

On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?


Electronic hardware min/max are tied to environment and mtbf
requirements. ~ a specification.

Yes, but a corporate STANDARD determines how those are treated
in a design. Once can \"arbitrarily\" decide that you can\'t
operate a device outside those limits. Or, within X% of either.

[And, unless there is a process in place to verify compliance with that
standard, the standard, by itself, is meaningless.]

Layout and mech have to tightrope walk through production
capabilities. ~ a financial decision.

Or a marketing one. My current designs are a bitch to lay out because
I\'ve opted on a particular size and form factor for the finished
products. Someone else could choose to abandon those constraints.

Quality is established, demonstrated and maintained through vigilence
or testing; before, during and after fab. ~ by savvy personnel.

But, largely subjective. Who decides that you have a quality product?
You? Your customer? Regulators? The courts (via damage awards)?

If it\'s not designed in and competently conveyed, it won\'t be there.

Whatever is adopted needs documentation to satisfy the ISO9000-ish
certification, if that alone is the aim. Honking great binders
of paper bumph used to satisfy.

But you don\'t need to go ISO9k unless that has value -- directly or
indirectly -- to your organization. I\'m not sure that you can be
as cavalier about standards, in general. How successful are you likely
to be if every product is designed completely without regard for
anything else you\'ve created?

The trick is to come up with standards that are appropriate for
your organization, market, industry, etc. -- not too onerous to
present an excessive burden but not to casual to be without value.

 

[legg]

On Sun, 20 Nov 2022 21:08:59 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

On 11/20/2022 1:57 PM, legg wrote:
On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?


Electronic hardware min/max are tied to environment and mtbf
requirements. ~ a specification.

Yes, but a corporate STANDARD determines how those are treated
in a design. Once can \"arbitrarily\" decide that you can\'t
operate a device outside those limits. Or, within X% of either.

[And, unless there is a process in place to verify compliance with that
standard, the standard, by itself, is meaningless.]

Once environment and mtbf are specified, the process involves
a calculation/demonstration procedure defined by the applicable
standard - mil, bellcore, ford, EIA or whatever may be written
in product specs.

Layout and mech have to tightrope walk through production
capabilities. ~ a financial decision.

Or a marketing one. My current designs are a bitch to lay out because
I\'ve opted on a particular size and form factor for the finished
products. Someone else could choose to abandon those constraints.

If it\'s not designed with mfring capabilities - specific equipment,
materials and processes that are intended, then it\'s not worth the
paper or files the design docs are recorded on. You can\'t automate
a design that isn\'t developed for automation. You can\'t build it
with unobtainable materials, or produce it with unacceptible
man-hour requirements or scrap levels.

You don\'t specify a size or form factor that you don\'t have the
means to produce.

Quality is established, demonstrated and maintained through vigilence
or testing; before, during and after fab. ~ by savvy personnel.

But, largely subjective. Who decides that you have a quality product?
You? Your customer? Regulators? The courts (via damage awards)?

I think you\'ll be able to predict potential quality problems just by
the smell coming out of the design review meetings. In the mfring
process quality problems are evident in scrap levels

If it\'s not designed in and competently conveyed, it won\'t be there.

Whatever is adopted needs documentation to satisfy the ISO9000-ish
certification, if that alone is the aim. Honking great binders
of paper bumph used to satisfy.

But you don\'t need to go ISO9k unless that has value -- directly or
indirectly -- to your organization. I\'m not sure that you can be
as cavalier about standards, in general. How successful are you likely
to be if every product is designed completely without regard for
anything else you\'ve created?

The trick is to come up with standards that are appropriate for
your organization, market, industry, etc. -- not too onerous to
present an excessive burden but not to casual to be without value.

You don\'t \'come up with\' standards. They exist and either are
complied with, or are ignored. Ignorance is not bliss.

Do you have a specific issue with a standard or it\'s imposition
on your work?

RL

 

[Don Y]

On 11/21/2022 8:19 AM, legg wrote:

On Sun, 20 Nov 2022 21:08:59 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

On 11/20/2022 1:57 PM, legg wrote:
On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blockedofcourse@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.

It\'s amusing how many companies \"roll their own\" instead of
coming up with industry standards (like GMPs). This probably most
common when it comes to documentation and \"software\".

Noticeably absent are standards governing hardware design.
E.g., how component typ and min/max values are tolerated in a
design, shake-and-bake, component derating, etc.

DRCs are relatively common -- and largely standardized. But,
so many other issues seem to just rely on the individual designer\'s
notion of \"good design practices\"; rarely anything actually
codified in a document!

Is this a common experience? Or, do you just rely on ISO 9000-ish
guidance?


Electronic hardware min/max are tied to environment and mtbf
requirements. ~ a specification.

Yes, but a corporate STANDARD determines how those are treated
in a design. Once can \"arbitrarily\" decide that you can\'t
operate a device outside those limits. Or, within X% of either.

[And, unless there is a process in place to verify compliance with that
standard, the standard, by itself, is meaningless.]

Once environment and mtbf are specified, the process involves
a calculation/demonstration procedure defined by the applicable
standard - mil, bellcore, ford, EIA or whatever may be written
in product specs.

You create standards that reflect those things.
E.g., when designing kit that resided on machines that incurred heavy
impact loads, you needed to qualify the design (and product) against
continuous vibration. When designing a piece of lab equipment that
sat on a bench in a relatively clean room, not so much. Different
standards for different markets.

Layout and mech have to tightrope walk through production
capabilities. ~ a financial decision.

Or a marketing one. My current designs are a bitch to lay out because
I\'ve opted on a particular size and form factor for the finished
products. Someone else could choose to abandon those constraints.

If it\'s not designed with mfring capabilities - specific equipment,
materials and processes that are intended, then it\'s not worth the
paper or files the design docs are recorded on. You can\'t automate
a design that isn\'t developed for automation. You can\'t build it
with unobtainable materials, or produce it with unacceptible
man-hour requirements or scrap levels.

Sure. And you can\'t *sell* a device that doesn\'t address the constraints of
the market: \"Here\'s your new, portable cell phone. And, the wheelbarrow to
cart it around with you!\"

You don\'t specify a size or form factor that you don\'t have the
means to produce.

You figure out what the *market* is willing to buy. Then, you figure out
if it can be produced in that form factor and the consequences of that
production technique. I\'m sure most folks couldn\'t build cell phones.
Yet, there are millions of them sold all the time. So, the \"means to produce\"
exist; it\'s just whether or not your quantities can make them affordable.

[We made reading machines by the *dozens*. Because making them in larger
quantities just wasn\'t practical for our market. Of course, that
labor cost further contributed to the cost/price... that limited the
market\'s size...]

Quality is established, demonstrated and maintained through vigilence
or testing; before, during and after fab. ~ by savvy personnel.

But, largely subjective. Who decides that you have a quality product?
You? Your customer? Regulators? The courts (via damage awards)?

I think you\'ll be able to predict potential quality problems just by
the smell coming out of the design review meetings. In the mfring
process quality problems are evident in scrap levels

But that doesn\'t tell you if you have a true quality problem.
I recall seeing a 30 inch diameter, stainless steel, ball bearing
\"outer\" sitting in a scrap heap at a factory. That\'s a lot of
value (materials + labor) to be discarding. Yet, the NEXT item
off the line (that wasn\'t scrap) easily paid for the discard.
And, the one after that was \"gravy\".

If it\'s not designed in and competently conveyed, it won\'t be there.

Whatever is adopted needs documentation to satisfy the ISO9000-ish
certification, if that alone is the aim. Honking great binders
of paper bumph used to satisfy.

But you don\'t need to go ISO9k unless that has value -- directly or
indirectly -- to your organization. I\'m not sure that you can be
as cavalier about standards, in general. How successful are you likely
to be if every product is designed completely without regard for
anything else you\'ve created?

The trick is to come up with standards that are appropriate for
your organization, market, industry, etc. -- not too onerous to
present an excessive burden but not to casual to be without value.

You don\'t \'come up with\' standards. They exist and either are
complied with, or are ignored. Ignorance is not bliss.

No. Every standard originates somewhere. And, a wise organization
picks and chooses which parts of which standards to adopt and/or
modify as appropriate for their market.

Many coding standards eschew the use of pointers -- because folks
often make mistakes when using them. And, as kids, we\'re taught not
to run with scissors.

Both of these are intended as ADVISORIES; adopting them as standards
to which compliance must be demonstrated is foolhardy. USE pointers.
RUN with scissors. But, be extra vigilant of the added risks that
these behaviors bring about!

Do you have a specific issue with a standard or it\'s imposition
on your work?

\"I received a request, from a colleague, for some \'standards\'
that he could use as models for a new client of his.\"

 

[Rich S]

On Monday, November 21, 2022 at 7:28:25 PM UTC, Don Y wrote:

On 11/21/2022 8:19 AM, legg wrote:
On Sun, 20 Nov 2022 21:08:59 -0700, Don Y
blocked...@foo.invalid> wrote:

On 11/20/2022 1:57 PM, legg wrote:
On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blocked...@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.
[snip]

Oh you want very-specific low -level
part specifications and work practices

of course there are the MIL
standards and HDBK (US DoD, Army,
Navy, USAF) all downloadable for
free. Might be overwhelming unless you know
where to find what you need.
I\'ve been out of that game for a few decades.

Re circuitry design, (non-Gov\'t)
there are some industry (IEEE
and ISO/IPC) standards, I recall.
SED folk will know these better than I.

But ultimately its the competition and
business survival that usually drives the
need, and specifics. (Hopefully that will also
motivate employees too, I hope they want
to keep the business afloat). IOW, what is your
competition doing & (claiming to) adhere to?
What do you need to offer customers that will
be better than the competition?
\"courage\", Don. = RS

 

[Don Y]

On 11/22/2022 8:04 AM, Rich S wrote:

On Monday, November 21, 2022 at 7:28:25 PM UTC, Don Y wrote:
On 11/21/2022 8:19 AM, legg wrote:
On Sun, 20 Nov 2022 21:08:59 -0700, Don Y
blocked...@foo.invalid> wrote:

On 11/20/2022 1:57 PM, legg wrote:
On Sun, 20 Nov 2022 02:13:10 -0700, Don Y
blocked...@foo.invalid> wrote:

I received a request, from a colleague, for some \"standards\"
that he could use as models for a new client of his.

In digging through my collection, I find standards for all
sorts of things:
- documentation
- specifications
- conformance test
- validation/certification
- randomness of RNGs
- coding
- safety
- wiring
- packaging
etc.
[snip]

Oh you want very-specific low -level
part specifications and work practices

I don\'t really know what he wants (i.e., what his *client*
wants/needs). I suspect he is just looking for some
examples to inspire his client to start thinking in those
terms.

[We tend to work with lots of small companies, startups,
pre-VC stuff, etc. so there\'s often no established
\"engineering department\" to drive that end of the business]

of course there are the MIL
standards and HDBK (US DoD, Army,
Navy, USAF) all downloadable for
free. Might be overwhelming unless you know
where to find what you need.
I\'ve been out of that game for a few decades.

Re circuitry design, (non-Gov\'t)
there are some industry (IEEE
and ISO/IPC) standards, I recall.
SED folk will know these better than I.

But ultimately its the competition and
business survival that usually drives the
need, and specifics. (Hopefully that will also
motivate employees too, I hope they want
to keep the business afloat). IOW, what is your
competition doing & (claiming to) adhere to?

That\'s not always obvious. Many of these people are
in niche markets that haven\'t yet been developed. If
you\'re the only guy selling a Fussbucket3000, then it\'s
kinda hard to see what your competition is up to!

So, others will copy *their* actions -- possibly *better*.

What do you need to offer customers that will
be better than the competition?
\"courage\", Don. = RS

The real issue is that these sorts of \"developing companies\"
often skimp on things in the beginning, thinking they don\'t
have the resources to put a good framework in place.

But, they somehow think they will have the resources and
*TIME* to do so later! (Um, if your product is a success
and you are the lone supplier in the market, you\'re going to
be busy staffing up to meet demand -- not *retrofitting*
policies and procedures into your current business model)

\"We don\'t have time to do it right -- BUT, we\'ll have time
to do it OVER!\"