This is a basic class I prepared and presented when I realized I was working with hardware, software and mechanical engineers that really didn't have any design experience whatsoever. A lot of them had graduated from college without any exposure to design. They had been maintaining designs since graduating. So when I went to the marsh board to work something out, they were seeing something they had never seen.
On the other hand, I came from power supply design, where you not only chose your topology, you often designed your own components, and wrote your own code to figure out what they should be. Specifications were notoriously incomplete, and failure was harsh.
So here are the basics of design, done up for engineers, as I have learned them. The hard way, usually.
Design? What do I do?
Why don't I know the answer?
Why didn't I think of that before now?
How do I keep everyone happy?
Where can I get some useful ideas?
How do I know when to stop?
And finally -
Why did I become an engineer?
The job of design is to define, confine, and solve problems. Normally, the word problem has a negative connotation, but for a designer, it is where you start. That is why a new designer can feel overwhelmed, even if s/he is technically capable.
Design is the second step of engineering product development, as shown below:
Requirements
Design
Analysis
Test
Engineers generally lead all these activities. The result of these activities is a drawing package, which can be used to reproduce the item in quantity.
There are pretty good resources for classical methods for Requirements Generation, Analysis, and Test. For Design, however, I have not found much that is useful to an embedded equipment designer. Resources I have seen are either too high level to be useful, or in the case of magazine articles, too focused and anecdotal on how a specific design decision was made.
In a word, no. Design occurs at all levels, from rockets to diodes, from cities to pavement mixtures.
For the purposes of this write-up, the System Engineer is the person who provides you requirements, or the next person in the design chain up from you. The implementers are the next persons down, who receive requirements from you. The requirements passed down may be in the form of text documents, drawings, files, or procedures. You then provide drawings, lists, and references to the next designers down in the chain. For an electrical engineer, that may be a CAD/Packaging person, a test developer, or a software engineer or two. Any effort has many designers at all levels, and you may have designers working in parallel with you.
Classically, a designer works with one set of solution tools on a confined section of a design - like software, ASIC design, or power conversion. A "system" engineer is expected to trade between different design characteristics, like weight vs. operator interface features, to develop requirements for the software, ASIC, and power designers.
Here is a more detailed writeup if you would like to better understand the division of System vs Design vs Implementation.
The designer has the freedom to choose many of the problems that he/she will have to solve.
A certain percentage of all design decisions are arbitrary. Not all design decisions will be constrained by your formal requirements. For many of the decisions, you do what is best/easiest for you. However, once you release these decisions for others to depend upon, they become fixed.
For example, you are required to provide a programming port. The connector type, protocol, and location, is up to you.
Unless the equipment mounts in a rack, and only one surface is available to the user. And there are other connectors on the surface. And the connector has to have a cover. And you have security requirements to meet. But it is up to the system designer (the next guy up) to tell you all of your constrictions.
In my experience, the "freedom of approach" of design breaks down something like this, by industry:
Of course, once you have published a segment of your design, it is no longer arbitrary. Others will start to depend on it as soon as it is published (maybe sooner!). This is why some engineers are reluctant to publish anything until the last minute.
Beginning designers have a real problem grasping this. One sign of inexperience is to publish decisions too early, or in the wrong order, and have to issue retractions (Engineering Change Notices).
You must also leave enough wiggle room so that the next people in the design chain (your implementers) can accomplish what you have defined. So it is important to study what your implementers can do. For you software coding people, your implementers are interpreters, compilers, assemblers, and software components. If you give them something too hard, you will pay for it, over and over.
Mutable vs. Immutable decisions
Certain portions of the design cannot be changed very easily once chosen, and more attention must be paid to those. These are the Immutable decisions.
Identify the immutable decisions first (mounting hole pattern, for example). Leave the mutable decisions till last (resistors and optional features). As a designer, it is tempting start in the center of your design, and work out. This is what a designer does in a serial design effort. But as a rule, any interface you define for others will cause pain if you change it when you get to the end. So if you are designing in parallel with other designers, you must start from the outside (system interfaces), and work in. If you find a risk, design in the ability to change (relative, spare, additional clearance). But treat your I/O very seriously. This is important to everyone else, and fixing it early will ease everyone's jobs.
As a note, the definition of Immutable has developed a more formal definition in software design. But the concept is the same whether it is hardware, software, mechanical, management or test.
An Example of Mutable/Immutable Decisions
A configurable processor is required by the specification. There are a few dozen I/O required, some with hard performance requirements, some for growth. However, the connectorization and other details are not specified, the customer will adapt.
In this case, the processor choice is an Immutable decision, changing it in while in the design process would be a huge impact. You will probably choose it using a trade off, as described below, to provide the best risk/value proposition at the very start of the job. Or the customer may specify it outright, they already have a software environment, etc. How the I/O actually makes it to the outside world is arbitrary, with many decisions left to the discretion of the designer. Eventually, it is published and accepted by the customer who will do what they have to, and the I/O then becomes immutable. This is because of its use by other groups - production test, procurement, support, the next level of integration. They will be all be affected by any changes. So don't lock in on these until you are sure you won't change them.
Could the processor be the mutable decision?
What is interesting is that while the ordering in the above example is typical in commercial systems, the situation with highly integrated military systems is almost completely reversed. By the time a black box specification is let out for execution in a military design cycle, the I/O is very well defined, the customer may have already purchased the I/O connectors for you to use (to cope with lead time issues). Cooling, volume, and and other constraints are also defined. The internal processing, however, is left to the designers to insure a particular performance or thruput number is provided under all conditions. So the processor is the mutable decision, the connectors and I/O are immutable. This is typical in large system developments.
Which problems do I tackle first?
Problems will be in three categories:
Known problems with known solutions - need to pick the best one to satisfy the established priorities.
known problems with unknown solutions - may need to get creative
Unknown problems - gotta force these into the light.
The worst are the unknown problems. How do you find them? Prototyping, mental experiment, use cases, or someone with experience will help. We even built a mockup to test our EMI shielding approach - and it really paid off. By far, finding the unknown problems quickly will give you the best chance at success in your design. Problems must be identified before they can be solved.
Design itself consists of four steps:
Understanding of Requirements
Recursion
Interaction
Closure
Overdesign and Underdesign are usually the results of poorly defined or understood requirements. As a designer, it is important to understand how requirements are generated, and the difference between specification compliance and performance. If you need it, a short primer is here.
Formal or informal, there has to be an understanding of requirements that takes place. Sometimes this ends up with the designer actually documenting them. If you are given a requirements document, you must mark it up. This is especially straightforward using wikis and other web tools. Don't generate a new document, unless you connect the requirements in the new document to the requirements in the document you were given. Even this is pretty rude.
Some designers try to negotiate the hard parts out of their designs. It is always good to simplify and challenge difficult demands, but I have seen designers negotiate themselves into being shut down, because they won't accept that a new design should work better than an existing, available one. If you take all the challenges out, the person authorizing the effort may decide there is no reason to do it at all. I have actually seen a cost reduction pitch which stated the new version would cost slightly more to produce than the existing one. The presenter was stunned that it was not accepted.
In my experience, the designs that had the most rocky and argumentative requirements phase always produced the best designs. Some feelings may get hurt up front, but I would rather have this, than an unsuccessful design, with the finger pointing that is sure to follow. Nothing spells success better than a good spec.
Specifications May Include Direction
Sometimes the stakeholders will directly define certain elements of the design as part of the requirements. System engineers know that this is hazardous, but it is difficult to avoid entirely. What you should know as a designer, is that the Requirements in an area should define the required performance, or the required approach, but not both.
For example, after extensive testing and negotiation on pricing, the requirements specify a specific GPS receiver chip by part number. By doing this, the System Engineer is accepting the responsibility for the performance of the receiver. If it is implemented as recommended or required by the vendor, then the performance is defined by the vendors specification. That is the limit of the designers responsibility.
Or: the GPS functions that are critical are specified, and it is the responsibility of the designer to select a chip and integrate a design that allows it to meet the requirements, as stated.
So the System Designer has the option to place the overall performance requirement on you, by specifying exact performance requirements, or handle the integration herself by specifying the antenna and the receiver components. Choices, choices.
This is an important concept to understand. Research and Development may provide a lot of solutions that will enable the product. If they are to be used directly (the product will use a PXA320), or simply used as guidance, then this must be made clear to find out where you have freedom, and where you don't.
Goals, hard requirements, targets, etc. Get this all worked out. The better you understand this, the better it will be for everyone.
Identify problems to be solved to meet the requirements
Define/develop/discover solutions to problems
Verify approach satisfies all requirements by estimation/simulation/analysis/review
Does the result
show success against the requirements, and
yield problems that are solvable at the next level down?
If so, then move down one level of detail and repeat
All good designs start with circles and arrows. Block diagrams and higher level conceptual drawings bring out inconsistencies and bottlenecks. There are many computer aided tools, but most people still use pencil and paper, or a marsh board, for free form thinking. Data flows, grounding diagrams, concept sketches, etc. The root of the word schematic is "scheme". What is your scheme?
An interesting technique I have seen for mechanical design is to project a rough drawing on a white board, and then "mark up" with white board markers. I am sure that an electronic version of this exists, but I have not seen it in action.
Reference Designs:
Whenever I used reference designs, I ended up doing all the math and timing over again, part by part. Either I couldn't get the exact components they used, or I found out that the reference design was a bit of a hack, and didn't work at the limits. Reference designers use what they are familiar with, not necessarily the best choice for your design. Things may be different now, but I doubt it. If you are using a reference design, check the math.
During this phase, you will be using simulation and test to verify sections of your design. It is better to decide WHAT you are looking for, and build a test or simulation for that, than to try to build or simulate the entire thing, and then go looking around for something wrong. Once you make a list of what you think you should test or analyze, take it to your boss. They are pretty good at making these decisions. That is usually how they got to be a boss, by knowing what needs to be checked, and what doesn't.
In general, you have a man-hour budget for analysis and simulation. Figure out the simulations that you can do in that time. Does it reduce the risk enough? Do you need more simulations?
Your simulations and tests should be decisive - here is the temperature, here is the timing I will look at, this is how I will figure out whether the speed is being met. Generation of a test plan, no matter how primitive, always is a good idea. A lot of testing I have seen has uncontrolled sections, which obscure the result of the test, causing backtracking (was the display on during that test?). If you make sure you know what you are testing when it works, you will have a better time figuring out why it doesn't work later on. Fewer variables.
In the process of doing your design, you should run your solutions by someone for a sanity check. Of course, this person should be sane. Believe me, I have made that mistake. I am serious.
During review of your approach, it is normal for the system engineer to discover that your solution, while technically correct, does not completely match something he was looking for - this is normal, and is the purpose of reviews. Be sure to steer them back to the requirements for definition (don't accept: It should be smaller! How small? To solve what problem?).
If you find problems that are too difficult, you may be able to see the other engineers or the System designer to get some relief. Also, you may be asked for relief, or find some in an approach that you can bubble up or out (hey, we don't need those $200 transistors - at all!). I have worked with engineers that would not communicate these finds and would not accept any modifications from others except under severe duress. But never more than once. They weren't around for the next one.
If you can make another engineers life easier, do it. It all comes back around.
How to Control Feedback Received from Stakeholders
Feedback is a dangerous, uncomfortable thing. How do you quantize it? How do you turn it on or off? Some engineers won't want to hear any feedback from anyone, while some won't stop soliciting additional requests/advice. Both are bad. How do you incorporate stakeholder feedback in a way that is effective, but not overbearing?
Here is what I did to split the difference. I called it the Belly Up Period.
Once a design was complete for review, each engineer would enter a fixed period of, oh, say, one week (the Belly Up Period). That is, that everyone downstream of the effort was notified, received a package, and had one week to respond with comments. This group could apply resources as they saw fit to review, and respond with comments/corrections. In our case this was System Engineering, Production test, CAD, Operations, Verification, Reliability, and Purchasing, and an independent engineer not working on the program, but with knowledge of the specialty. The design engineer would respond to all of their comments, either by implementing them, integrating them (they often intersected), or escalating them to the Lead/Project Engineer.
After a week, the comment period was over, and all other change requests had to go through (that SOB) Program Manager. So the groups had a fixed time to get what they wanted, or shut up about it. And the engineer and Program Manager got a fixed to do list that could be worked, or even delegated.
This provided known access to the design that the user community could prepare for. It also accommodated underdesigners and overdesigners, allowing them to incorporate the requested changes with knowledge of expectations.
Not saying it was perfect, but at least everyone knew the rules, and it did insert order into what had been chaos. After all, Hendrix proved that feedback is controllable.
This worked well in a Meritocracy. Tons of stuff came out to worry about, but all the players understood, even expected this. I have tried the same in a Colonial system, and it did not work well. Frankly, if the Governor has faith that the designer has done a good job, the designer doesn't really need anything else. The designer may or may not entertain comments from peers or users against goals or requirements in the Colonial system.
When all requirements are expected to be met by executing known implementations, or
When the design challenges have been reduced to a level that the next level can solve them
This means you are deciding what problems the next level down can solve.
Acceptance criteria of next design phase is critical. Expect to sell the design off to the implementing organization.
If the next level does not accept the design, then you are not finished.
It is clear that improvements to the design can be made by involving the next level down early.
In order of increasing risk:
Classical approaches
Internal Heritage (Boss)
Reference Designs
Conference/Papers/Current State of the Art
Totally New Concept
Each design solution should start with the classical method, and only go to a more risky approach as needed. As risk increases, verification must be more thorough, and the chance it may not work gets more distinct, so you will more likely need a backup approach. You have to take risks to be successful, but too many totally new concepts can kill a design. Success becomes statistically out of reach.
It is more straightforward to verify something you know is going to work, but most of your verification should center on the most risky items, the scary ones. This also applies to subcontracted designs. A subcontracted classical approach needs little attention, but a totally new concept will occupy much of your time, and probably needs a backup.
To evaluate the design decisions you will be making, you will need a few litmus tests. This is a good place for some system modeling and other tools to help, as long as you don't get wrapped up in the fidelity of testing. Remember that at this stage, modeling is to aid with your decisions, not be be a perfect reflection of the eventual system.
Most, if not all, designs arise from a combination of these four design methods.
Trade Off
Budgeting
Seat of Pants
Frankenstein (or Yard Sale)
Choose the right tool for the job.
The trade off (or trade study) is good for broad approaches that will have a profound effect on the design. Trades require the most effort of the four approaches, so should be used sparingly. This is used to pick communication methods, processors, location methods, operator interfaces, power hold up approaches, etc. But it could be used with lesser decisions like connectors and interface chips, if they heavily affect the outcome.
In this method, the designer selects several candidate approaches, and evaluates each in chosen rating criteria (power, cost, size, software, features, etc). The results are then weighted based on the desirability of each of the criteria. The designer then goes with the best overall score, fairly certain that this is an optimum approach.
Advantages:
Need little specific knowledge to start
Provides clear direction
Presents easily with understandable criteria, enabling stakeholders
Provides optimized approach with backup - important for those difficult decisions that everyone wants to be in on
If rating criteria change, direction is clear
Disadvantages:
Slow
Expensive
Rating criteria may be difficult to define
This may be a silver lining - if the rating criteria are in dispute, then the product is really not well understood by all the stakeholders. Back to the specification!
It is clear that it may require a great deal of effort, in that if four approaches are traded, then three approaches will not be chosen, and the work on them is discarded. Since the design must be pursued down to a level that makes the trade relevant, there could be a lot of work, and rough estimates are the rule of the day. So only use this approach for your big decisions.
To use Budgeting, the designer allocates compliance to a requirement into budgets for each category (speed, error, weight, cost, link loss, deaths, etc.) The designer uses judgement to determine that all the budgets are obtainable (that can be done in 4 nseconds, I can certainly find something to do the next step in less than 10 nseconds, etc.). The design is then implemented, making sure each element stays within the budget allocated. If each element meets its budget, the product meets the spec. If one is under, then one be over, and still meet the spec. But the overall compliance of the design is predicable.
Advantages:
Best for well understood problems with many contributors and variables, like weight, recurring cost, error, tolerances, noise, or power dissipation. 50 variables or more can be accommodated, verifying that each independently meets it design budget. This is not the case for the trade off method above.
Straight forward, easy to plan, assign, and track
Breaks apart and isolates problem solving
Moves well into analysis and test
Disadvantages:
Need a good knowledge of contributors to start. May get trapped if initial budgeting was misguided - turning simple design problems into difficult ones
Does not guarantee that the chosen allocation is the best approach, or even competitive - only guarantees that the spec is met.
Must account for some budgets not being met - for every one that is over, one must be under to meet the spec.
Safety Margins may lead to a less than optimal design.
This is used as a design technique quite often. The name comes from early aircraft attitude determination. Pick an approach, and start solving problems, one after the other, until you are done. Inexperienced designers are sometimes railroaded into this, in that it is the easiest on those depending on your design. If someone needs to know the I/O format, you just make one up and tell them right away. Unfortunately, you may be left with a few problems that cannot be solved at the end.
Advantages:
Best for problems with well known boundaries and solutions
No planning needed
Can release details on a schedule that suits the users, rather than the users having to wait while you work out budgeting or trades
Disadvantages:
Since there is no design path, it may be impossible to backtrack if a an approach must be dumped due to poor performance.
It is difficult, if not impossible, to assess how close to completion the design is. SOP leads to designs that get to 95% complete quickly, but stay there for a long time.
Your hard problems will tend to push to the end. This method tends to start fast, but really slows down for the last few problems.
The final problems may become quite difficult, as you find yourself "painted into a corner".
All designs have some SOP items. But this category should be used as little as possible. It may be very attractive to solve a few easy problems to show some progress, but you should start with the hard problems first, and leave anything in this category for the last, easiest decisions.
I have seen engineers try to just pick everything, and then change things until it works. This is a solution method that may not converge. Some trial and error is inevitable, but a good designer, like a good gambler, keeps guessing to a minimum.
I have also heard this called technique called yard sale (swap meet? flea market? rubbage sale?). The designer finds existing components that each meet some portion of the requirements. They may have other functions that are not used or disabled. The components are then connected together to form a finished product. The only design required is the glue to allow the elements to operate with each other. There may be many features on the components that are not used, these may or may not be removed or disabled. And the result may look like, well, Frankenstein's monster.
This is used quite a bit when the numbers to be built are low, and space, weight and recurring cost are not an issue.
Advantages:
Straightforward, easy to plan and track
Large sections of the design are complete through test, reducing the number of design problems to solve.
Documentation exists too!
Can provide smashing schedule and budget performance
Disadvantages
Little freedom to absorb design challenges uncovered by the system.
Since the component is in a new application, you may discover problems that you cannot address. Even if the basis is open source, fixing a new problem found could be very time consuming, due to a components complexity.
Result is obviously sub optimal, from a technical and recurring cost viewpoint.
Although Dr. Frankenstein did produce a human specimen that met or exceeded the physical spec in every regard, the result was not well received by the user community.
Always attack the hard problems first. They are what you are paid for.
Make the hard problems drive the easy problems
Be suspicious of someone who isn't working the hard problems. Trouble is coming.
Select implementations whose hard problems match your strength, or the strength of your organization.
Keep in mind that any solution must be verified. This may disqualify a particular approach.
Example: In power supply design, the Royer oscillator came briefly into vogue. Simple, elegant, reliable. But I could not use it, because I couldn't figure out how to predict its performance during load changes. Eventually, it went out of fashion and was replaced by topologies that could be analyzed using state space techniques. It's not that it didn't work well. It fell out of use because it's performance cannot be predicted by analysis in general applications.
Each solution should perform as predicted under the conditions of test, not just "work".
Example: You calculate that the unit under test will experience a 5C temperature rise under no load. You measure a 9C temperature rise during test. The maximum allowable temperature rise is 10C, so technically, the unit passes this test. But the analysis was way off. Something is wrong with either your analysis, your implementation or your test. You should have measured a lot closer to a 5C rise. Get to the bottom of it, or it will be back later, when it will be much harder to fix. Your test and analysis should support each other, under the specific conditions of testing.
Example: Feedback systems always "work", under benign conditions. All kinds of things can be wrong, and the output end up correct. Open the loop to make sure that the actual performance matches your analysis. Or it may blow up under transient conditions.
Accidental successes are a hazard. I have had several in my career. Things that should have never worked, but got through test. Eventually they screwed up, given the right conditions.
Get someone else to test your stuff. They will find problems you would never find.
If something becomes very difficult, Brain Salad Surgery is easier than it seems. On one program we completely threw out the display system software concept that was clearly not going to be acceptable. We changed to a better approach based on what we learned, and the whole thing was back up and running in two days. If we had not changed, it would have taken us weeks to get it right, if we had ever gotten it to work at all.
Design is Risky. Risk requires backups. If you use 10 high (90%) probability implementations, you will likely change to one of your backups during the course of the design. Know what your backups are, and know that it is a rare design that does not end up using some of them.