Don’t let these disasters happen to you: The top five engineering hints you’ll rarely hear
In theory, theory and practice are the same
Lewin Edwards (sysadm@zws. com), Design Engineer, Freelance
Lewin A. R. W. Edwards works for a Fortune 50 company as a wireless security/fire safety device design engineer. Prior to that, he spent five years developing x86, ARM and PA-RISC-based networked multimedia appliances at Digi-Frame Inc. He has extensive experience in encryption and security software and is the author of two books on embedded systems development. He can be reached at sysadm@zws. com.
Summary: Lewin Edwards presents five engineering tips that are crucially important to successful product engineering, but which are rarely brought up in discussions of engineering practices.
Date: 01 Aug 2006
Level: Intermediate
The Internet has exactly one and a half zillion articles (I counted them) containing lists of things to do and not to do in embedded systems design. Many of these articles focus on well-understood topics like switch debouncing and how to estimate maximum stack depth. Dozens of these articles quote our old favorites in terms of embedded disasters: Therac, Ariane, and the Mars Polar Lander. This article gives you a few choice tidbits of advice you won’t find mentioned quite so frequently in other places. It also includes some anecdotes that will show you just how easily your work life can turn into the inspiration for a Dilbert cartoon if you’re not careful. (Having just finished writing a book on related topics, I’m brimming with anecdotes I didn’t have room to print earlier).
Tip 1: Production versus development
Engineering development procedures have different needs from production procedures; never confuse the two.
Practically nothing can be done effectively in a large company unless a defined formal process for achieving the goal is in place. You might
not like this fact, but it’s true. As an engineer, you’re working with a head full of specialized knowledge while you design your widget, but at the other end of the equation there’s more than likely a factory employee or even a subcontractor following “put flap A in slot B” instructions. The huge, bureaucratic, and often exasperating machine that turns your schematic into a finished product consists largely of formal processes that turn engineering documents into flap A, slot B manufacturing and quality control documents.
While a product is in the development stage, engineering needs to be able to make quick and sometimes speculative changes. Accordingly, processes that support engineering development need to be simple and streamlined. It needs to be easy for engineering to request a build exception – for example, “build 50 of these boards; 25 matching the schematic, and the other 25 with different resistor values at certain locations.”
On the other hand, when something is in actual large-scale production, you want to be very leery indeed of making changes. Any change to the bill of materials – say, removing a resistor from your board – that appears minor from the engineering standpoint affects a huge number of production processes. The schematic has to be changed, and the bill of materials needs to be updated so manufacturing knows how many of that resistor it needs to be requesting to meet each month’s demand. Purchasing might need to renegotiate contracts with the resistor vendor, or return excess inventory.
(No Ratings Yet)