chapter4 high-level-design

Elec3017:Electrical Engineering Design

Chapter 4: High Level Design

A/Prof D. S. Taubman

August 4, 2006

1 Purpose of this ChapterIn this chapter, we consider the three high level design phases of problem state-ment, concept generation and system design. As mentioned in Chapter 2, theproblem statement aims to capture the fundamental design challenges and con-straints; it serves to focus our attention during the concept generation phase,whose goal is to propose as many conceptual approaches to solving the problemas possible. The system design phase involves the selection of one of these de-sign concepts1 and the development of a corresponding system level design. Thesystem level design usually involves a block diagram, with a careful descriptionof the function of each block and the interactions between blocks.

2 Stating the ProblemHaving collected information on requirements and features from potential con-sumers of our product, and developed a set of carefully worded requirementstatements, it is tempting to try to work all of this information into a singleproblem statement. In fact, you might wonder why you need a problem state-ment at all, since the requirements seem to capture all the objectives of thedesign problem. The difficulty with working directly from requirements is thatsome will be more easy to achieve than others, so it is difficult to focus your ef-forts on the key design challenges. As discussed in the next section, the conceptgeneration phase does not aim to find solutions to all stated requirements ordesired features. Instead, it seeks for a range of possible solution approaches tothe central design challenges. The purpose of a problem statement is to removeclutter and focus our attention on the key objectives, challenges and constraints.Later, when we come to system design, the full range of requirements can betaken into account.

1 If we have sufficient resources to pursue multiple parallel design paths, we may selectseveral of the most promising design concepts.

1

c°Taubman, 2006 ELEC3017: High Level Design

Many possible strategies for formulating a good problem statement can befound in design textbooks. Some strategies seek to focus attention on what iswrong with existing solutions. Others focus attention on the product’s inputsand outputs. In the end, there may be no single method which will consistentlyproduce good results. I personally recommend the following structure:

Summary: Start your problem statement with a brief summary of the problem.Try to use words to describe the product which suggest function ratherthan form. In the example given below, we resist the temptation to de-scribe our problem as that of designing an “automated shopping trolley,”preferring to identify it as a “product to assist shoppers in accumulatingand transporting items selected from supermarket aisles.” Your summarywill draw upon information collected during requirements analysis, butyou should keep only those requirements which are critical to product ac-ceptance here. Even then, use words like “should” instead of “must,” soas not to overly constrain the concept generation phase later on.

Hard constraints: State any hard constraints, such as legislative constraints,ethical considerations and so forth. However, avoid elevating desirablefeatures to the level of hard constraints.

State the central challenges: The purpose of this is to focus attention dur-ing the concept development phase. This is the hardest part of the problemstatement process. You are trying to eliminate requirements which youexpect could be easily addressed if required. In the end, you should bethinking, “If only I could do X, the rest would fall into place,” where X isthe central challenge. There may be multiple central challenges, or con-ditional challenges, such as “If I could do X and Y, or W and Z, the restwould fall into place.”

The advice given above seems sensible and reasonable straightforward.When you try to apply it, however, you should find yourself asking the fol-lowing question repeatedly:

Am I reasonably sure that this statement (requirement, constraintor challenge) will be true of all useful solutions to the core designproblem?

Asking this question is perhaps the single most important thing you can doduring the problem statement phase. It will force you to reword your problemstatement, where appropriate, to be less prescriptive. It will encourage you toremove statements which unduly impose a form on the solution. At the sametime, with this question as the basis for writing and re-writing the problemstatement, you will probably be able to avoid the danger of over-generalizing.There is no point in having a problem statement which contains no details ofthe problem at all. It must leave you keenly aware of the problem to be solved.Since this question is difficult to answer, you may need to revisit the problemstatement process after an initial pass through the concept generation phase.


At this point, it is worth giving an example of a problem statement. Forthis purpose, we select one of the design problems for which requirements wereanalyzed in lectures (in 2006) — the “automated check-out trolley for super-markets.” During lectures, the class came up with a large number of desirablefeatures, unique selling points and requirements for such a product. Only themost critical of these is reflected in the initial summary portion of the problemstatement produced below. Note the focus on stating the central design chal-lenge for this product. We could easily augment this problem statement witha collection of auxiliary considerations. For example, it may be necessary toconsider what happens if children ride in the product or some of the shopper’sown possessions are transported in it. These could be included in a separatesection of the problem statement, or just omitted for the time being. They willbe considered more carefully during design concept selection (see Section 4).

Problem Statement: The problem is to design a product to as-sist shoppers in accumulating and transporting items selected fromsupermarket aisles. The product should be easy to use and providebenefits to both shoppers and store owners, by automating or par-tially automating the processes involved in purchasing items. Theproduct should allow items to be added or removed by the shopper atwill. While the product might offer a variety of additional featureswith various benefits, the central design challenge is to keep track ofthe total price of items which are currently being transported in theproduct.

3 Generating Design ConceptsWe use the term “concept” in a number of different ways in this course, whichcould potentially be confusing. For this reason, it is helpful here to distinguishbetween the following two usages:

Product concept: This is what emerges from the needs assessment phase.A product concept is basically just an idea for a product, presumablysomething which can meet real or perceived user needs. We probablyhave some idea how it might possibly be implemented, or else we wouldnot consider it further, but product concepts are about user benefit ratherthan technical implementation.

Design concept: Many of these emerge from the concept generation phase andone is selected at the start of the system design phase. Design concepts aremuch more technical in nature than the original product concept. Gener-ally what we mean by a design concept is the key principle around whicha solution to the design problem might be built. It might be a principlefor measuring some obscure quantity. It may be the novel deployment ofsome specific technology, possibly a newly invented technology.

The following definition is perhaps the most useful:


A design concept is one possible method, usually technical in na-ture, for solving a principle design challenge described in the problemstatement.

A design concept is not usually a complete solution to the design problem.Many less challenging aspects of the design problem might be ignored duringthe concept generation phase so that we can focus our attention on generatingas many novel concepts as possible. Later, during system design, we will have toconsider the whole system. If there are multiple non-trivial design challenges,we might separately come up with design concepts to address each of thesechallenges. Again, during system design we will need to decide which of thesecan work together to form a complete solution. During concept generation,however, we are should not discard a concept just because it happens to beincompatible with concepts we have found for other aspects of the system.Concept generation requires lateral thinking, as well as a general awareness of

available technology. The goal is to come up with as many different approachesas possible, so that we minimize the risk of missing a novel solution path. Forthis reason, you should consciously refrain from exploring the concepts you comeup with in detail at this stage. Some ideas might seem outlandish at first, butwrite them down. They may stimulate you to think of other more promisingdesign concepts. You might also find that aspects of two seemingly infeasibleconcepts can be combined to produce a meritorious approach.The following is a list of methods which have been found to help in stimu-

lating creative concept generation. This list has been drawn, with quite a bit ofadaptation, from [1, Chapter 7].

Brainstorming: This is perhaps the most well-known technique for creativitystimulation. A group of people, ideally with different backgrounds andstrengths, propose and build on each others ideas in an intense period ofdiscussion. It is important that people feel free to propose novel conceptswithout being dismissed out of hand for lack of feasibility or realism. Acompletely left-field concept might stimulate other members of the groupto think of approaches which turn out to be both plausible and highlycreative.

Brainwriting: This is similar to brainstorming, except that each person writestheir ideas down and then passes them on to the next person to build onthe ideas. This can, of course, be done by electronic means using theinternet. A Wiki would be an excellent tool to use for brainwriting.

Analogies: One important source of analogies, particularly for mechanical andcivil engineering disciplines, is nature. To come up with a concept for un-derwater position detection, you might gain inspiration from dolphins andother marine mammals, for example. There are many potential sourcesof analogy, though. For electronic products, some of the best sources ofideas come from other (possibly very different) products which have somecommon theme to what they are trying to achieve. Guttenburg’s printing


press was inspired by the wine press. Steel rolling mills used to produceplate armour were inspired by rolling pins used to prepare bread dough.As a more immediate example, suppose you were trying to design a prod-uct for sorting and counting fruit; you might be inspired by consideringthe analogy of a coin-operated vending machine.

Obtain a fresh perspective: A design team can easily get locked into a smallnumber of concepts that they consider most promising, after which furthercreativity tends to stall. One way to break out of this trap is to invite anoutsider to give their thoughts on the matter — sounds pretty obvious. Becareful not to describe your current concepts to the outsider, or they maybe similarly locked into your current pattern of thinking.

Idea diagrams: As design concepts start to emerge, you will find it helpfulto classify them into different broad approaches to the problem. Thiswill help you to find other related design concepts. Basically, classify-ing concepts and identifying their relationships to each other helps youto generalize. As an example, 1st year Electrical Engineering students in2006 were asked to design a system which would automatically orient aplatform to face into the wind. Various design concepts for sensing thewind direction emerged from this exercise. Some concepts involved hotwire anemometry to sense differential wind speed through changes in re-sistance in two or more wires. Some concepts involved wind-vanes withassociated sensors. Other concepts involved various arrangements of flapswhich moved around in the breeze, making and breaking electrical con-tacts. These were all interesting concepts, but arranging the concepts intorelated groupings can stimulate the generation of yet further ideas. Forexample, recognizing that one category of concepts involves the indirectsensing of wind direction through multiple wind speed measurements canlead to the proposal of additional speed measurement strategies. Thereare many other categories that can be built for this problem which stim-ulate the creativity of additional design concepts, but we will not dwellfurther on them in these notes.

4 Concept SelectionIn this section, we consider the selection of one or more concepts for later designphases. It is convenient to think of this as a first step in the system design phase,since we may need to carry out a partial system level design for several conceptsbefore we can make a sufficiently informed decision. Two broad categories ofconsiderations in the design selection step may be identified as “user require-ments” and “design requirements.” By “design requirements,” we mean thatthe design concept or concepts which are selected must lie within the technicalcapabilities of the design team, given time and other constraints. The followingtwo sub-sections consider these two categories in reverse order.


4.1 Design Requirements

An obvious design requirement is that you have or can acquire the expertiserequired to realize a selected design concept. Some early prototyping may berequired in order to determine how feasible a concept actually is. This will betrue also for your ELEC3017 design projects, so be prepared to start prototypingvery early.A slightly less obvious design requirement is that the selected concept or

concepts should lend themselves to available manufacturing technology. It isone thing to build a one-off prototype in the lab, but quite another to effi-ciently manufacture large quantities of the product. Of course, determining themanufacturability of a concept may not be straightforward. Familiarity withmanufacturing techniques is certainly helpful. It is highly advisable, however,to include representatives from the manufacturing side of your industry on theactual design team. This greatly facilitates what is known as Design For Man-ufacture (DFM).Tightly connected with manufacturing is the issue of cost. All other things

being equal, a less expensive approach will clearly be preferred.Related to both cost and expertise is the design complexity. All other things

being equal, a less complex concept is to be preferred. Of course, less complexconcepts are likely to be easier and quicker to design. Complexity also oftenmakes testing more difficult and decreases reliability.Finally, you should consider the risk associated with a selected design con-

cept. Does it rely upon unproven technology? Are the manufacturing processesuncertain? etc.

4.2 User Requirements

During concept selection, we should review the requirements which were estab-lished during the requirements analysis phase. Recall that the problem state-ment does not normally attempt to capture all of the identified requirements andfeatures. This is to focus our creativity on the most important design challengesduring concept generation. Now that we come to select one of these concepts,however, we should refer back to the full set of requirements.Issues such as usability, maintainability, reliability and performance are all

reflective of user needs, and may depend strongly on the selected concept orconcepts.

4.3 Constraints

Some of the generated concepts might not be compatible with known designconstraints. Specifically, we should consider whether any of the concepts haveadverse ethical, legal or environmental implications.


Light interruptionsensor 1


Entering/LeavingDetection Logic

Up/DownCounter

Display System

User Interface

interruptevent

interruptevent

entering

leaving

personcount

reset

mode select

Logging Systemstatistics



Entering/LeavingDetection Logic

Up/DownCounter

Display System

User Interface

interruptevent

interruptevent

entering

leaving

personcount

reset

mode select

Logging Systemstatistics

Figure 1: Initial block diagram for a “people counter” product.

5 System Design and Block DiagramsDetailed design will take time. Suppose you spend 2 months developing a greatsystem for weighing packages, only to discover that your design cannot workwith another, mechanical part of the product due to excessive vibration. Thepurpose of system design is to identify sub-systems of the complete productand their inter-dependencies before embarking on costly detailed design. In thesystem design phase, it is possible to explore multiple design concepts and theirinteractions without expending an unreasonable amount of time. System designaims to decompose the design into sub-systems, allowing you to estimate therequirements, risks and possibly the cost of each such sub-system early on. Thisgives you a better understanding of the detailed design challenges and the risksto your overall product development plans. At the end of the system designphase, you should evaluate the costs, benefits and risks associated with theproposed product to determine whether their are sufficient economic or othergrounds to continue the design effort.Given the emphasis on decomposing the design into smaller sub-systems,

block diagrams are central to system design. These help you to visualize themain functional elements of the product and their interaction. The block dia-gram also provides a framework for the design team to work with, as individualmembers begin to focus on detailed design of specific sub-systems. An exampleblock diagram for a “people counter” product is provided in Figure 1. Noticethat some of the blocks correspond to physically separated components of thesystem, while others do not. For example, the light interruption sensors aremost likely separate physical components, mounted in convenient locations todetect people. On the other hand, the logic has been broken up into three blocks(entering/leaving, up/down counter and logging system), which might not allbe physically implemented on a single chip.For a block diagram to be useful, we should be careful in selecting the right

level of abstraction — i.e., what the blocks should be. We could think of individ-


ual components (silicon chips, transistors, etc.) as blocks. For some purposesthat might be appropriate, but for most design problems individual componentsare the subject of detailed design. At the other extreme, we could think of theentire product as one block, but that would clearly be useless. Here is a list ofcriteria which can be used to help you decompose the design into blocks.

One technology: Different technologies are best kept in separate blocks. Ex-amples include analog vs. digital electronics, various sensing technologies,and electronic vs. mechanical aspects of the product. One reason fordoing this is that blocks with different technologies may call for quite dif-ferent methods and personnel for the later detailed design phase. Anotherreason is that separating technology types into different blocks allows usto explore alternative technologies for some aspect of the system, withminimal impact on other aspects.

Physical separation: If the product contains physically separate sub-systems(e.g., the receiver and transmitter in a communication system), it is nat-ural and helpful to separate them into different blocks.

Known solutions: If known solutions or known solution methods exist forsome aspect of the design problem, it is helpful to assign it a separateblock. For example, you might create a “filter” block in your system,noting that filtering is a problem for which good self-contained designmethods exist.

Simple interfaces: If two blocks in your block diagram have a complicatedinteraction, it might be better to put them into a single block. This willmake it easier to provide input/output specifications for each block.

Not too many blocks: In the system design phase, you should try to avoidhaving a massive number of blocks. Large numbers of blocks will slow thesystem design process down, in the same way that detailed design does.

Once you have a block diagram, you should try to identify the critical blocks.These are the ones you expect to present the greatest design challenges or havethe greatest impact on cost. Critical blocks might also represent aspects of theproduct which are subject to regulatory compliance. You should spend someeffort exploring the critical blocks further. You might not initially be sure thatyou can implement it. If not, you need to know this sooner rather than later, sosome early prototyping might be required. You should also ask yourself whetherthe critical blocks in your system are critical to the actual design. It is possiblethat they are challenging and risk, yet not required to meet essential customerdemands.As mentioned in previous chapters, design is a narrowing process. This

means that your initial block diagrams should involve relatively few genericblocks. If you encounter a problem, you may need to go back to concept genera-tion and selection, or even re-examine the requirements and problem statement.


If you are satisfied, however, you might proceed to a more detailed block di-agram, expanding broad sub-systems into their respective elements. At somepoint, of course, this starts looking like detailed design. You only need to con-tinue the system design phase until you reach the point where you are satisfiedthat you will be able to come up with specifications and proceed with detaileddesign of every aspect of the sub-system.

References[1] Voland, G, Engineering By Design (2nd edition), Pearson/Prentice Hall,

2004.

chapter4 high-level-design

Documents