Do you use any 'official' standards covering sane EE practices?
Such standards should include, for example:

• component derating (max voltage, current, power)
• transient suppression (IO clamping)
• power-supply up-down sequencing control and protection
• required review by qualified second-set-of-eyes
• testing and documentation of tests
• document control, including change control (schematics, engineering documentation, spice models, BOM, production tests, approvals)

Or do you just wing it???
Its a serious question.

Thanks for any inputs,
Best Regards, Dave

I would add SW should always be under source control.

Production should also have automated tests, that are a result of the development process.

Basically, your list are just "good practices". Official standards are things like 60601 for medical devices and DO-178C for avionics. "testing and documentation of tests" are part of official standards, as well as good practices.

I don't doubt you are asking a serious question. Are you asking about them because you need t convince management? What (engineering/product) domain are you asking them for? 

I'm not asking folks if they follow good practice, nor if they beat their wife.

I'm asking are you using any official standards as guidelines or requirements?

Thanks!
Best Regards, Dave

Yes - I both follow Good Practices, and either DO-178C or 60601, depending on the project - I'm a contract engineer.

I'm curious why you are asking.

60601 might be applicable.

I'm wondering what to suggest for organizations having, shall we say, difficulties.

Thanks!

Good luck with this. An organization that doesn't have the discipline to develop and embrace their own design best practices may be unwilling to embrace a starting point or suggested process from a contractor or consultant. It's a tough proposition, requiring buy-in up and down the organization. Good on you for trying, lead them to water and hopefully they'll take a big drink.

Ideally they'll hire engineering and perhaps manufacturing management with appropriate process sensitivity and discipline, and then upper management will let them go do their jobs! In small companies there can be someone at the top who wants control of everything and prevents this from happening, either by not hiring the right people or not taking the right advice.

I've seen this in technology companies. My brother in law is an IE who helps industrial manufacturing companies get their processes straight, he has similar stories. It's most often an upper management problem, but they get to assign the blame, so... 

DO-178C is not just SW - it can also apply to HW. Basically, DO-178C says you need to define your process, then follow it. However, you will get smacked down if you have a bogus process. It is a bit of a slog, but worth reading it.

60601 has a number of subsections. If you are looking for a general good starting point, it would work. However, as a first cut, just getting Good Practices in place can be a struggle. You might need to start with baby steps with some clients.

I was part of a HW design review. The EE started with "The purpose of this review is to keep me employed". Might be good advice for your clients :^)

You also might add automated tests early on for both SW and HW. You imply it in your list, but most tests are done by hand.

Check out youtube videos by "Uncle Bob" Martin. His usual audience is not embedded folks, but the principles are universal. Might help with some clients. YMMV.

Various design standards (coding, safety, regulatory compliance, etc.) more commonly apply to an industry. If you're working in a particular space you have to use the related standards. Opinions vary on what should be included in specific coding standards, but it is important to use one. If your industry does not mandate one for you, the organization or project team should adopt one.

Beyond design standards, there are design best practices which is what it sounds like you are equally concerned about. Right off the top of my head I'd add these to your list:

• a well defined and agreed upon target design specification
• up-front design for test and design for manufacturing analysis and requirements
• design rule checking (software/RTL coding standards, physical design rules)
• simulation and min/max internal/external timing closure for FPGA logic
• code and logic coverage analysis for software tests and logic simulations
• signal integrity analysis and related design margin
• power and thermal analysis and related design margin

Here's an excellent set of 10 articles from Jack Ganssle, his top ten reasons embedded projects wind up in the ditch. These may further help you round out your list:

https://www.embedded.com/how-embedded-projects-run-into-trouble-jacks-top-ten-number-ten/

Different organizations do things differently. Better and more successful organizations are sensitive to these issues. They take them very seriously and have a well defined development process, tailored to the types of designs they are doing, that they follow religiously. The process is tweaked as escapes are discovered.

The "just wing it" approach most often appears in small organizations with less complex projects. Sometimes you get away with it, most often you don't. It's a bad plan, you're counting on not proving everything works and getting lucky. This is basically a science fair project, and the real world doesn't award red ribbons for near misses.

An organization that is going to commit to an integrated circuit tape-out absolutely cannot just wing it. The schedule and dollar hit you take with a re-spin is substantial. You lose a lot of revenue by missing the beginning of your market window and/or not being first, the end of that window is fixed and doesn't wait for you.

Taking a product into volume production is an art in itself, hooks required for manufacturing and production test have to be factored in at design time. If volume production is a goal, you need a good manufacturing lead involved at the start of the design cycle.

Some of these bullets may not apply to a particular design, some are more universal, but they are all important if/when they apply. If you want to guarantee specifications across an operating range, you can't ignore derating. You have to pay attention to supply sequencing requirements in a device or across devices. It is a HUGE red flag when a developer or manager doesn't appreciate the importance of a version control system. It is horrifying when so-called FPGA designers program a device with no logic simulation or test coverage analysis, no min/max timing closure, and if it "works" they declare victory and flee the field.

Dave,

I will proudly say, all of the above and and then some.

I like to have lots of embedded diagnostics too.

Patrick

I am going to come at this from a very different direction.

One of the NIST publications is Handbook 44.

This is the technical specifications of any measuring devices where money changes hand based on the displayed measurement values. Berry baskets, taxi meters, weighing scales - they are all here. If you are working out how to measure or display some value there is much guidance based on literally centuries of practice and law.
Yes, there have been many lawsuits based on how much should be paid based on potentially shady measurements that could be manipulated by the buyer or seller.

https://www.nist.gov/pml/weights-and-measures/publ...

As far as guidance on electronics equipment, one of the best sources of construction practices is MIL-Handbook-454B: GENERAL GUIDELINES FOR ELECTRONIC EQUIPMENT

https://www.dla.mil/portals/104/documents/landAndM...

The practices outlined here have been tested & vetted under some of the harshest conditions most equipment will ever see. This also points you to the best industry standards to cover various aspects of contruction.

If you plan to deploy your gizmo in certain geographic areas and you want to know what to plan for - the military has a standard for that!

MIL-STD-810G: ENVIRONMENTAL ENGINEERING CONSIDERATIONS AND LABORATORY TESTS

This walks you though a process on determining what environmental conditions you may be looking for and has industry accepted test methods to verify that you will work in those conditions. If you go to most test labs and ask for one of the test, say "810G-509.5" they will know what you are talking about salt fog and probably have a test chamber to do this test.

You can get it for free of this official army site - be warned that their security certificate is out of date and your browser may flag it as a security risk. Accept the risk and proceed. I wish they would get this fixed.

https://www.atec.army.mil/publications/Mil-Std-810...

If this is too sketchy for you a google search will show other places where you can get a copy.