chapter1 introduction-to-design

Elec3017:Electrical Engineering Design

Chapter 1: Introduction to Design

A/Prof D. S. Taubman

July 24, 2006

1 Purpose of this ChapterThe purpose of this chapter is to introduce you to the nature of design, theprocesses which it involves and the breadth of skills which it embraces. An im-portant goal of this first chapter is to expand your view of design. Before long,you will find that the number of skills and disciplines involved in design canbecome too large to keep track of in a systematic way. For this reason, manytexts on design begin to read like lists of good ideas, rather than well organizedmethodologies. To address this difficulty, the next chapter provides you witha helpful framework to manage the conceptual complexity of your rapidly ex-panding view of design. That chapter should also help you to understand therelationship between design and your studies in the Electrical Engineering andTelecommunication disciplines.

2 Design: The Art of the EngineerOne, arguably oversimplified, distinction between a scientist and an engineer isthat the scientist is concerned with analyzing the behaviour of existing things,while the engineer is concerned with the synthesis of new things. Of course,analysis and synthesis go hand in hand; if you cannot analyze the behaviourof a system, then you cannot hope to design a system which achieves a desiredbehaviour. This is why an engineering degree involves so much fundamentalscience. You must learn how to analyze an electronic circuit, for example, todetermine the DC bias levels, the frequency response, the stability, the powerdissipated in each component, the maximum votage presented across the termi-nals of sensitive components, and so forth. These are the sort of activities withwhich you have been most concerned up until this point.Design, however, will move you into unfamiliar territory. You must find a

way to synthesize new circuits which achieve a complex array of objectives. An

1

c°Taubman, 2006 ELEC3017: Introduction to Design

easily overlooked aspect of design is the need to carefully identify and eventuallyquantify what these objectives are. This is the subject of Section 3.Assuming for the moment that it is easy to identify the design objectives

(something which is far from true in practice), one could argue that the skillsof analysis are all you need for design. The gist of the argument is captured inthe following dialogue.

Scientific products company: “We’ve got everything electrical engineersneed to design the world’s best products. We have developed an advancedset of simulation tools which can predict the behaviour of any combinationof electrical components, no matter how complex.”

Engineer: “Sounds pretty impressive.” (thinks to himself: “sounds impossi-ble”) “How could I use it to build an audio amplifier?”

Scientific products company: “No problem. Just try all combinations ofactive and passive devices — you know, resistors, capacitors, transistors,inductors, transformers and so on, simulate the result and see which onecomes closest to your design specs. Our simulator can produce an outputin less than 1 minute. You might want to write a script for automatingthe process for generating potential circuits — or you could get a bunch oftrained monkeys to do this.”

Engineer: “Hmm. What about a design for the combat systems in a newfighter plane?”

Scientific products company: “No problem. Same approach ...”

Hopefully, you can see how ridiculous it is to suggest that analysis itself issufficient for design. In fact, the absurdity of this suggestion gives us someinsight into the art of design:

Engineers develop skills which enable them to narrow the set of pos-sibilities which must be explored.

While simulation tools are very important to the design engineer, hopefully youcan also see from the above argument that over-reliance on simulation tools isnot helpful.An important element in this process is the ability to recognize sub-problems

which have been solved before. For example, if you need to develop an electronictuning fork, it is very helpful to know that you can construct an oscillator froma tuned LC circuit (possibly locked by a crystal) and an active element whichprovides positive feedback at the frequency of interest.In this way, a good design engineer can break a problem into sub-problems,

classifying them as routine, already solved, challenging or potentially infeasible.Part of what we call “engineering knowhow” is an awareness of what problemshave been solved before, or are already packaged up in VLSI circuits or algo-rithms. In this way, initial design activities can focus on those sub-problemswhich are the most challenging or could prove to be infeasible.


Another important element in the design process is the ability to transformcomplex problems into alternate representations. For example, if you want todevelop a device to sample ECG signals, it is very helpful to know that theproblem you want to avoid is aliasing and that this is best understood in thefrequency domain. In fact, the frequency domain is the natural representationin which to understand and manipulate the signals produced for or by systemswhich are linear and time invariant (a vast class of interesting physical andartificial systems). Armed with this knowledge, the engineer is able to designan appropriate pre-filter by manipulating the poles and zeros of an RLC circuit.

2.1 Design as an Optimization Process

One way to think of design is as an optimization problem. Once the objectives(requirements and specifications) are established, the problem is to find thecircuit configuration and component values which optimize these objectives.This optimization task is plagued by the following difficulties, however:

1. Some objectives may be difficult to define precisely (e.g., “it must be easyto use”).

2. Multiple objectives may be conflicting or at least have different levels ofimportance.

3. Even where objectives can be numerically quantified (e.g., “maximize thesignal-to-noise level” or “minimize the power consumption”), they are of-ten related non-linearly to circuit parameter values. As all engineers know,non-linear optimization problems are the hard ones, having numerous lo-cal optima which prevent us from being sure of finding a globally optimalsolution. Fortunately, electrical and telecommunications engineers havedeveloped many excellent strategies for solving commonly occurring non-linear optimization problems, such as filter design, but these are applicableonly to small sub-problems of the overall design.

4. While the behaviour of the system may vary continuously with parametervalues, major design decisions (e.g., which technology to use) have a dis-continuous impact on the behaviour of the system. This typically meansthat the engineer must embark on a preliminary analysis of a variety ofquite different high level designs in order to find a good solution.

5. The behaviour of the actual components used will inevitably vary fromtheir ideal designed values. Engineers must understand the impact ofthese variations and design systems which are able to work correctly withinknown component tolerances. This dramatically complicates the designproblem, particularly for analog circuits. This problem is largely avoidedwithin digital electronics, but virtually all products must ultimately inter-act with the real world through analog interfaces. Custom laser trimmingof component values at manufacturing time can also simplify the designproblem here, but it may add unnecessary cost to the product.


In view of the above issues, engineers do not usually kid themselves intobelieving they can find the best solution to anything other than the simplestof design problem. Instead, engineers blend the analytical tools available tothem with a judicious sampling of promising design approaches, progressivelynarrowing their options until a good design is achieved.

3 The Role of RequirementsAs discussed in the previous section, design must have an objective. Morecommonly, there are multiple objectives and the designer is often faced with thedifficult task of trading one against the other. Recognizing that some objectivesare more important than others, it is common practice to identify the “reallyimportant” ones as requirements.Requirements play a very important role in industrial design. Many prac-

titioners believe that it is fruitless to start the design process before you havefully documented the requirements you are trying to satisfy. Requirements alsoplay a central role in the development of standards, but we shall return to thisissue in a later chapter.Commercially successful activities must satisfy the real or perceived needs

of a customer who is prepared to pay for them. However, the need for require-ments extends beyond commercial product development (e.g., the developmentof military hardware).

3.1 Deriving Requirements

Salt and Rothery [1, Ch. 3] and Ulrich and Eppinger [2, Chapter 4] describea number of strategies for deriving requirements for a product. In the sim-plest case, a knowledgeable group of end-users is able to identify the functionswhich are central to the success of the product. Consider, for example, thedevelopment of sensing and recording equipment for nerve signal to assist inneuro-surgery. In this case, the end-users (neuro-surgeons) may be able to pro-vide an excellent description of the functionality they require: signal rise andfall times, user interface features, logging capabilities, etc. Consulting firmsoften find themselves designing solutions for such knowledgeable clients.In many cases, however, deriving requirements is not so simple. Here are

some of the methods which can prove useful:

1. Survey potential consumers. This is one of the least reliable sources ofinformation, in part because survey respondents are likely to represent abiased cross section of the market (e.g., people who are too polite to say“no”). Surveys are usually non-interactive, so respondents may not get achance to properly understand the envisaged product.

2. Focus groups. These are interactive discussions with groups of potentialconsumers — usually paid for their time. A facilitator guides the discussionin order to get people to verbalize their requirements. A common problem


with both surveys and focus groups is that of selecting good questions. InAppendix ??, we suggest some questions which can facilitate the processof deriving requirements.

3. Observe existing similar products in use. For new products, this couldpotentially be done with a prototype or even a mock up (non-functionalprototype).

4. Analyze existing similar products. Understanding how people use existingsimilar products can provide some of the most reliable information on userneeds. In some cases, features offered by existing products may becomeindispensible in the mind of the user, making them requirements for futuresimilar products. An example of this is text messaging for mobile phones.

In addition to user requirements, products may need to comply with regu-latory (government) or other industry standards (usually for interoperability).The manufacturing process may impose its own requirements. In fact, designinga product for ease of manufacture (including ease of factory testing) is an art initself. Electronics firms often have their own internal design standards, whichform part of their quality assurance system.

3.2 The Danger of Exceeding Requirements

Although the notion of requirements makes perfect sense, it is often difficult toseparate true requirements from just attractive features. The temptation, then,is to clutter the requirements list with features which are not really necessary.The problem with adding unnecessary features is that each feature adds com-plexity and cost. Of these, complexity is the greater evil, since it makes theproduct more difficult to design, more likely to fail, harder to maintain, andmuch more difficult to test.ASIC (Application Specific Integrated Circuit) design provides an excellent

example of the cost of complexity. Here, each added feature may double thenumber of test vectors, or worse. To highlight the significance of this problem,it is worth noting that the test regime for a complex design could take weeks ofcomputer time to run.At the same time, it is important to remember that the success of a new

product in the market place may depend upon its having a suitable array offeatures, even if they are not requirements. The digital camera market is anexcellent example of this. Many consumers will not purchase a camera if itdoes not offer options for manual control of the focus, exposure, lens aperture,metering modes, fill flash level, over/under exposure, etc. On the other hand,few of these consumers ever use these modes more than a few times, if at all,over the lifetime of the camera.The centrality of requirements is perhaps strongest in professional markets,

such as medical, military and scientific products. Consulting engineers oftenmust be guided principally by requirements, since these form the cornerstonesof their contract with the client. In many consumer markets, however, the


requirements can be harder to precisely identify and an extra (not required)feature might provide the Unique Selling Point (USP) needed to break into anexisting market.

3.3 The Danger of Treating all Requirements as Con-straints

In the previous sub-section, we used the word “true requirements” to distin-guish them from desirable features. In reality, however, not all requirementsare equal. It is hard to separate the user’s needs from the user’s wants, so thatsome requirements end up being softer than others. Requirements must also betempered by feasibility, cost and their impact on other requirements.Consider, for example, the design of a watch with integrated GPS (Global

Positioning System) capabilities. One requirement may be that the product beno larger than a diving watch. A second requirement, derived from focus groupinput, might be that the device’s batteries should last at least 8 days withoutrecharging, since this is a minimum expected capability of similar devices suchas mobile phones. These two requirements may well conflict, since the small sizeof the device necessitates the use of a very small battery. In the event that bothrequirements cannot be satisfied, it is more likely in this case that a reducedbattery life will be tolerated. Of course, we could go on to include additionalrequirements, such as GPS positioning accuracy, maximum acceptable cost, etc.,each of which imposes new pressures on the design. If we treat all requirementsas hard constraints, the product may turn out to be impossible to design, or atleast not commercially viable.Evidently, there is a grey zone between requirements and desirable features.

We must remember that design is a narrowing process. It is safest, therefore,to start with a minimal set of broad requirements, which are hard to dispute,particularly during the concept development phase. Once a design concept hasbeen selected which can satisfy these requirements, focus groups might be re-engaged to deliberate the need for additional (perhaps softer) requirements. Insome cases, this is done by creating “mock ups” (non-functional prototypes) forfocus groups to work with.

4 The Role of SpecificationsTo emphasize the importance of starting broad and narrowing our options asthe design proceeds, it is good practice to draw a distinction between productrequirements and detailed product specifications. At one level, the distinctionbetween requirements and specifications is really one of detail. However, thereare some useful rules of thumb which can help you to distinguish between re-quirements and specifications:

1. Requirements should be expressed in non-technical language, to the extentthat they can be readily comprehended by the consumer. This is a useful


rule of thumb, since it means that requirements can be generated andanalyzed by groups of potential consumers (e.g. focus groups).

2. In contrast to requirements, specifications should define the measurablebehaviour of the product or of sub-systems within the product. This isalso a useful rule, since it means that the specifications can be used intesting to validate a design. It is worth noting that some requirementsmay already be specifications in this sense. For example, the battery lifeof a mobile phone is a quantified requirement which is readily understoodby the consumer, but it is also a specification which can be directly tested.

3. Requirements alone may form a sufficient basis for high level design de-cisions, such as the type of technology to be employed — e.g., sensingtechnologies, digital vs. analog processing, operating principles, etc. Onthe other hand, specifications are involved in the selection of specific com-ponent values, ratings, clock speeds, etc.

4.1 From Requirements to Specifications

To move from requirements to specifications, the design engineer must translateneeds, typically expressed in everyday language, into numerical quantities. Forexample, an electric heater may be required to heat a 16 m2 room to 20◦ Cduring the Sydney winter. The engineer needs to translate this into a poweroutput specification. To do this, the engineer must obtain information on thecoldest expected winter day in Sydney (to estimate the temperature gradient),the thermal conductivity of surfaces in typical Sydney homes, typical ceilingheights, and so forth.As a much more complex example, a person with hearing impairments might

require a cochlear implant which will enable her to understand speech. The en-gineer must translate this requirement into specifications for the number ofstimulating electrodes in the cochlear transducer, the dynamic range of theelectrode amplifier, and so forth. This translation is far from trivial, requiringextensive psychophysical studies, information collected from animals with simi-lar auditory structure to the human, and ingenuity. Even then, numerous trialsmay be required before specifications for the product can be deduced.

4.2 Other Sources of Specifications

As you have probably gathered from the above discussion, the translation of re-quirements into specifications can be a very difficult process. Fortunately, thereare often other useful sources of information which can simplify the process.Where similar products already exist, others may have already done much ofthe work of translating common requirements into specifications. In this case,it may be legitimate to borrow many of your own product’s specifications fromthose of the other product. In some cases, existing products set the benchmarkagainst which your own product must measure favourably in order to succeed inthe market place. For example, consumers demand scanners which provide at


least 1200 dpi resolution, simply because this is what is offered by most exist-ing products. In reality, few consumers actually need anything more than 300dpi resolution, but the specifications have been fixed by existing products andmarket perception.Another very important source of specifications is standards. The need to

comply with one or another regulatory or inter-operability standards may fixmany of the specifications of your device. What this means is that other groupsof experts have already done the work of translating real requirements intoappropriate specifications.

4.3 Specifications for Design and Testing

Specifications will be used to select both the internal parameters of the designand their allowable tolerances. For example, specifications on the frequencyresponse of an analog filter might be expressed in terms of its maximum andminimum gain within a specified passband and its maximum gain within aspecified stopband. This leads to the selection of a filter order and inductance,capacitance and resistance values for the circuit. This may be the simplestpart of the design. A more complex analysis is required to determine tolerancesfor the component values, such that the filter can be guaranteed to satisfy thedesign specifications.As already mentioned, specifications should be testable. In the above exam-

ple, this allows us to test each filter’s characteristics at the point of manufacture,if necessary; indeed this approach may be the only way to actually guaranteethat the specifications are satisfied, if component tolerances cannot be reliablydeduced during the design phase.More generally, complex systems are normally best partitioned into simpler

sub-systems, translating the overall product specifications into specifications foreach sub-system. This facilitates both the design and testing processes. Thepotential drawback of modular design is that it can obscure interactions betweenthe sub-systems which could potentially be exploited to make the overall designmore efficient, less power hungry, and so forth. In most cases, the small lossesin overall system efficiency which might be attributed to modular design areheavily outweighed by the benefits of design simplicity, module re-usability,reliability, testability and so forth.

5 Design ConstraintsIn this section, we take the opportunity to elaborate on hard constraints whichmight be imposed on the product design process. These may fall into the fallingcategories:

Safety Regulations: The sale of products which contravene safety standardsis usually illegal. Standards Australia is the body responsible for creat-ing and maintaining standards of this type, which may be referenced by


legislation. Of course, Standards Australia does not create the legislationitself. Standards are created by working groups of experts from industryand academia who are qualified to participate.

Other Regulatory Standards: Standards regulating allowable levels of elec-tromagnetic interference, use of the communication spectrum and copyprotection enforcement all belong to this category.

Inter-operability Standards

In-house Design Guidelines:

Patent Infringement: The rapidly growing number of broad patents placesincreasing constraints on new product design, especially where the prod-uct developer does not control its own patents in a similar area or havepatent treaties with other organizations. In law, patents are equivalentto property. As a result, in certain areas, creating new products can belike trying to build a new trainline through a densely populated suburb —almost all the land is already owned.

Legal Liability: A corporation is not exempt from liability just because itfollows relevant safety standards. Companies may (and should) be hessi-tant to create products which have unknown potential to cause personalharm or damage property. The development of medical products can beparticularly constrained by considerations of potential liability.

Time to Market: In a rapidly changing technological marketplace, manyproducts are not worth designing unless they can be brought to marketwithin a reasonable period of time (e.g., 1 to 2 years).

6 Design Phases and NarrowingA good design process typically involves the following phases:

1. Needs assessment — determine what types of products customers need

2. Requirements analysis — determine what features a product requires

3. Problem statement — a concise & useful statement of the design problem

4. Concept generation — lateral thinking, creativity stimulation, ...

5. System design — high level design

6. Specifications analysis — refined from requirements

7. Detail design — detailed schematics, component selection, mechanical de-signs, ...

8. Prototyping


9. Testing

We shall consider these design phases more carefully throughout the course.In practice, smooth flow from one design phase to the next is rarely achieveddue to missing or incomplete information. For example, it may happen thatnone of the design concepts which you explore during the system design phaseseem likely to satisfy all of the requirements. Indeed requirements often placecompeting pressures on the design. In this event, you would need to revisit therequirements to determine whether or not some of them can be softened. Thismight be done by engaging or re-engaging consumer focus groups, this timepresenting them with less choice regarding what can and cannot be achieved.Even if the requirements can all be achieved, it is a good idea to return to the

requirements analysis phase once a high level design concept has been selected.At this point, it may be possible to specify the requirements in more detail.Potential consumers may be given a more concrete idea of how the product willwork, and this in turn will inspire them to consider things that had would nothave crossed their minds earlier.Evidently, it is frequently necessary to revisit earlier design phases in an

iterative fashion. To say that design is an iterative process, however, is tooobvious to be all that helpful. The central effect is that of narrowing: narrowingof the requirements; narrowing of the feature set; narrowing of design choices;narrowing of the remaining time; narrowing of the remaining budget; etc. It isimportant to start broad, but it is equally important to progressively commit tochoices until a single solution is finally reached. The design phases mentionedabove certainly follow a narrowing trend, but narrowing also happens as we areforced to revisit them.

7 Documenting the Design ProcessDocumentation plays an important role in the design process. On one hand,the discipline of documentation forces you to think through each of the designphases in a methodical manner. On the other hand, documents record theinformation you will need for testing, continuously improving, communicating,marketing and manufacturing your design. Here are some of the documentsthat would typically be produced as part of a good design process:

1. Statement of the problem being solved

2. Operational description of the product (e.g., a draft users manual)

3. Requirements analysis

4. Technical specifications

5. System specification, including block diagram and block interface docu-mentation.


6. Detailed design documents, including schematics, PCB design, mechanicaldrawings, etc.

7. System test plan

8. Service and maintenance plans, if required

9. User manual

10. Manufacturing plans

11. Marketing/advertising brochures

8 Why do it?This is probably a good point to reflect on why you are emarking on the de-sign process in the first place. In most cases, the potential for commercialreturn is the main driving factor, but this is not the only one. I have beenreliably informed that engineers at Sony developed the “Aibo” robot, becausethey thought it was a cool thing to do and they thought that other engineerslike themselves would like to have one. In other words, it was not the productof a sound marketing strategy at all. It turned out, however, to be much moresuccessful than anyone had imagined.Whatever the motivation for designing a new product, it is important to

remember that some ideas are better than others. Limited design and manu-facturing resources, competition and the budget limitations of consumers meanthat many ideas will not make it to prototypes and many prototypes will notmake it to marketable products. As a result, it is important to evaluate themarket potential of product concepts at multiple points in the design cycle soas to eliminate unpromising candidates as early as possible. This is broadlyknown as the “go/no go decision.”Even if a product could be a success, the development and manufacture of

that product may stand in the way of developing another, even more successfulproduct. As Jack Knight (of the consulting firm Sinclaire Knight Mertz) is fondof saying,

Sometimes, the most important decision you can make is the decisionnot to pursue an opportunity.

In this course, we will explore a number of methodologies to help you evaluateand re-evaluate the go/no go decisions of product design.

9 Reality CheckSeems like a lot to digest! Are you up to it? Can you succeed in the ELEC3017design project without a team of experts guiding you through the requirementsanalysis, concept development, detailed design and testing phases? Don’t stress!Remember:


• The big picture only emerges slowly, as you emerse yourself in the process.• You can’t know it all from the beginning, but you have to start somewhere.Each completed design expands your ability to identify similar blocks inthe design of later products.

• The next chapter of your notes provides you with a useful framework onwhich to hang all the material covered in this course (and others). Afterreading that chapter, try to see where the material covered in these notesfits in. Much of this material will be expanded as we go on.

References[1] Salt, J. E. and Rothery, R., Design For Electrical and Computer Engineers:

John Wiley & Sons, 2002.

[2] Ulrich, K. T. and Eppinger, S. D., Product Design and Development 2 ed ,McGraw Hill, 2000.

chapter1 introduction-to-design

Documents