Embedded Systems Design and Development Chapter 12
Transcript Of Embedded Systems Design and Development Chapter 12
Embedded Systems Design and Development
Chapter 12
Embedded Systems - Design and Development ............................................................................. 3 Things to Look For… ................................................................................................................... 3 12.0 Introduction .......................................................................................................................... 4 12.1 System Design and Development ....................................................................................... 6 12.1.1 Getting Ready – Start Thinking .................................................................................... 7 12.1.2 Getting Started ............................................................................................................. 8 12.2 Life Cycle Models ................................................................................................................ 9 12.2.1 The Waterfall Model ................................................................................................... 10 12.2.2 The V Cycle Model ..................................................................................................... 11 12.2.3 The Spiral Model ........................................................................................................ 13 12.2.4 Rapid Prototyping - Incremental................................................................................. 14 12.3 Problem Solving................................................................................................................. 15 12.3.1 Five Steps to Design .................................................................................................. 15 12.4 The Design Process .......................................................................................................... 16 12.5 Identifying the Requirements............................................................................................. 18 12.6 Formulating the Requirements Specification..................................................................... 21 12.6.1 The Environment ........................................................................................................ 22 12.6.2 The System ................................................................................................................ 23 12.7 The System Design Specification...................................................................................... 35 12.7.1 The System ................................................................................................................ 35 12.8 System Specifications versus System Requirements ....................................................... 50 12.8 System Specifications versus System Requirements ....................................................... 51 12.9 Partitioning and Decomposing a System........................................................................... 52 12.9.1 Initial Thoughts ........................................................................................................... 52 12.9.2 Coupling ..................................................................................................................... 55 12.9.3 Cohesion .................................................................................................................... 57 12.9.4 More Considerations .................................................................................................. 59 12.10 Functional Design ............................................................................................................ 59 12.11 Architectural Design......................................................................................................... 66 12.11.1 Hardware and Software Specification and Design................................................... 67 12.12 Functional Model versus Architectural Model.................................................................. 71 12.12.1 The Functional Model............................................................................................... 72 12.12.2 The Architectural Model ........................................................................................... 72 12.12.3 The Need for Both Models ....................................................................................... 72 12.13 Prototyping....................................................................................................................... 73
Embedded Systems- A Contemporary Design Tool
- 1 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
12.13.1 Implementation......................................................................................................... 73 12.13.2 Analyzing the System Design................................................................................... 74 12.14 Other Considerations....................................................................................................... 77 12.14.1 Capitalization and Reuse ......................................................................................... 77 12.14.2 Requirements Traceability and Management .......................................................... 78 12.15 Archiving the Project........................................................................................................ 79 12.16 Summary ......................................................................................................................... 81
Embedded Systems- A Contemporary Design Tool
- 2 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
Chapter 12
Embedded Systems - Design and Development
Things to Look For…
• Things to consider in a design. • The product life cycle. • The five steps to design. • The need to understand the environment and the system being
designed. • The difference between requirements definition and specification. • Motivation for and objective when partitioning a system. • Coupling and cohesion and why they are important. • The differences between functional and architectural models of a
system. • Motivation for and timing of static and dynamic analysis of a design • Capitalization and reuse of designs. • Requirements traceability.
Embedded Systems- A Contemporary Design Tool
- 3 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
12.0 Introduction
In this chapter, we will study the major phases of the development process for embedded systems. The more detailed aspects of that process will be explored in conjunction with the design and test of the specific hardware and software elements of the system.
In this chapter, we will learn that design is the process of translating customer requirements into a working system and that the complexity of contemporary systems demands a formal approach and formal methods. Working from a formal specification of a problem, we will look at ways of partitioning the system as a prelude to developing a functional design. We will then examine the process of mapping functional model on to an architectural structure and ultimately to a working prototype. To help to ensure the robustness of the ultimate product, we will illustrate how to critically analyze the design both during and after development.
We will also look at several other important considerations in the design lifecycle. These will include intellectual property, component/module reuse, and requirements management and the archival process.
As we begin to think about a new product or adding new features to an existing one, we must look at things from many different points of view. The most important of these is the customer’s since he or she finances the development of the product either directly through an agreed upon contract or indirectly through a purchase. The best design of little value if no one is willing to buy. So, we pose the question: What kinds of things should be considered?
If we look at products, we must know how to measure costs and features. We must be
able to identify and distinguish between real and perceived needs. Too
often when we talk with customers about new products, the essential
“requirement” in the next generation product is that which was missing when a problem arose this morning.
It’s important to learn to make market and technology trade-offs. Several years ago the following very simple table was proposed.
Old Market
New
Taking old technology into and old markets is a reasonable and safe
Technology
Old
New
Embedded Systems- A Contemporary Design Tool
- 4 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
strategy. These are the niche markets and often provide support and evolutionary growth for products that are no longer in a vendor’s mainstream offering. Taking new technology into new markets is difficult and risky. At the same time, the rewards can be very high. The personal computer is a very good example. Xerox and Apple both had limited success with their early offerings. The people and the full technology were simply not ready. Taking new technology in to an existing area or existing technology in to a new area is easier. At least one portion of the problem - the market or the technology - is well understood and well developed.
We must understand the importance of deadlines and costs. Product development is based upon a (directly or indirectly) negotiated contract between us and the customer(s). Failure to respect development and delivery costs or schedules leads to loss of sales, market share, and credibility.
We also must always consider reliability, safety, and quality in the products we design. We will study these in great detail shortly. Beyond obvious need to work properly, the product must be robust. That is, simply, ‘Does it do what it’s supposed to?’ and ‘How does it behave with unexpected inputs?’ Robust means much more than this, however. Robust also implies that the system performs even if it is partially damaged, or under extreme temperature conditions, or if it’s dropped. If a product does what it’s supposed to do but is fragile and buggy, the product is not robust.
The documentation we produce to accompany the product must be clear and understandable. The product must be easy to use - intuitive rather than counter-intuitive. Post sales support, including the correction of bugs, is very important. Lack of quality has two costs. The first cost is obvious and immediate, the cost to repair, which is often small. The second a hidden cost, the loss of customer confidence and sales, can be very large. Once confidence lost very difficult to regain.
Embedded Systems- A Contemporary Design Tool
- 5 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
A Simple Example:
Years ago, when developing some of the early microprocessor based embedded systems, we would encounter problems as we debugged the hardware and software. At that time, tools were few and far between. This was a new field.
One very powerful tool for helping to track down such problems is called a logic analyzer. It allows one to follow which instructions the processor is executing (in real-time) and learn why stuff goes in and never comes out. We had to have one, so, our company purchased two of them from two different vendors.
The analyzer from vendor A arrived was out of the box, on the bench, connected to the system, and making useful measurements within 10-15 minutes. Only several days later did anyone think to take a look at the manual. The analyzer from vendor B had a user interface that rivaled a 1040 tax form. Its one-inch thick manual was equally cryptic and demanded several hours of study before even the simplest measurements could be made.
Guess which instrument always has a queue of people waiting to use it and guess which vendor sold us many more instruments.
12.1 System Design and Development
System design and development is a challenging problem. What makes it fun and exciting is that there is a very large creative component to it. There are no rules, no steps to follow to make one creative. There is, however, a large collection of rules to ensure the opposite. Consider a new child. Each comes into this world, eyes wide open with a million questions. Why is the sky blue? Why is the sun yellow? Why can’t we see the air? Where does air come from anyway? What do we do? We put them in school. We teach them the rules. Walk into any group of little ones and ask, how many of you can sing? How many of you can draw? Almost every tiny hand leaps up. Go into any similar group of adults and ask the same questions. Everyone is suddenly fascinated with their shoes. One hand may come slowly up. Why? We place too many restrictions on our thinking. Sure, we may need 10 million dollars worth of electronic equipment to give our voice perfect pitch, but, so what. We need to remove artificial restrictions that we impose on our thinking.
Embedded Systems- A Contemporary Design Tool
- 6 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
Look at the little ones drawing or coloring. What do we tell them? No, people aren’t purple. Cows can’t fly. Fish don’t have legs - anymore. Oh, and by the way, always color in the lines….and let’s also learn how to be creative.
12.1.1 Getting Ready – Start Thinking
Ok, let’s start. Driving is always a good place to begin. The rules are easy. Keep the yellow line on your left and the white on your right – except in Britain and several other places. Now the chance to be creative. In the autumn in the northern parts of the world, the days are warm, but, the nights start getting colder. Often there is a bit of fog that makes an appearance as well. By the morning, the fog and chill have combined to give a very fine glaze of ice on the road. We call this black ice; it gives us the opportunity to be creative. Hop in the car and race out onto the road. What’s this nonsense about staying in the lines?
Now perhaps we’ve decided that maybe we can be just a little creative, let’s begin to explore. As we begin thinking about a new design, we’ll discover that there are a lot of things to be considered. The problem may not always be what it seems at first blush. Roger van Oech in A Whack on the Side of the Head, Warner Brooks, says "Always look for the second right answer.” He’s right. As we begin, it’s important to understand the problem to make sure that we are solving the right problem. Consider the adjacent figure. Which one is the correct image? Is it the old lady or the young one?
When we begin trying to solve a problem, it’s important to talk with everyone involved; to listen to different opinions; to see how the design might affect the people who have to work with it. We have to take the time to look at different views of the problem; to look
at it from both the inside and the outside. Based upon our view, we can have a couple of different interpretations of the following problem. Are we building a goblet or are we building two statues?
Embedded Systems- A Contemporary Design Tool
- 7 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
There will always be occasions in which we have too much information, too many opinions, or too many details. Remember the old expression of not being able to see the forest for the trees. The same holds true as we begin trying to understand a problem during the early stages of a design. Look at this next drawing. What do you see? An interesting design; it looks perhaps like a snowflake. This is a case in which we have too much information.
Let’s remove some of the information – if we take a more abstract view of the problem, the solution is easier to see.
Now that we have a start, let’s look at the design problem. Let’s look at each design as a chance to explore.
12.1.2 Getting Started
Designing and developing embedded systems does raise some interesting challenges and does require a large number of decisions. Some of those decisions require knowledge about the problem, others about the tools and techniques that may be available, and still others choose methods for approaching the solution. There will often be still more things to think about that are not related to the technical part of the problem at all. The collection of these things that we do as we move from requirement to application is often called the product life cycle.
Like so many other things in life, there are probably as many different product life cycle models as there are people designing these systems. Who said there isn’t any creativity? Each of these models has its supporters and each also has it group of detractors. The goal in the next few pages is to introduce some of the more important things that one should think about when executing a design, present several of the more common life cycle models, and to present some guidelines for things that have worked on successful projects. Despite what they tell you, there are no hard and fast rules. Oops, I lied. There are three: learn a lot with each project, have fun, and do the job right…to the best of your ability. Let’s get started.
Embedded Systems- A Contemporary Design Tool
- 8 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
12.2 Life Cycle Models
The product life cycle of an embedded application is purely a descriptive representation. It breaks the development process into a series of interrelated activities. Each activity plays a role of transforming its input (specification) into an output (a selected solution). The organization of the steps is done according to a design process model – the life cycle model. Formality in design provides the structure for a development that lets one creatively explore the design while using the tools to manage some of the more mechanical issues. We use the structure as an aid rather than something that encumbers design.
As we’ve commented already, in the related literature, one can find that a variety of different approaches and models have been suggested. At the end of the day, all have the same basic goal; they all have similar phases. Perhaps, we could more accurately say that they all have similar needs or goals or objectives. These needs are very simple,
• Find out what the customer wants • Think of a way to give them what they want • Prove what you’ve done by building and testing it • Build a lot of them to prove that it wasn’t an accident • Use the product to solve the customer’s problem
Several of the historically more common models or approaches include,
• Waterfall • V Cycle • Spiral • Rapid Prototype
Today, we are continually developing new ones. Which ever model one chooses, the most important point is to understand the meaning and intent or objective of each of the phases or steps in the process. Understand the deliverables for each step as well as the necessary outputs and inputs that are required to move, conclude, or to enter each phase
Embedded Systems- A Contemporary Design Tool
- 9 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
in the selected model. Then follow those – don’t take shortcuts. We’ll look briefly at each of these four models momentarily. Before we do so, let’s look at another model that fits just about any phase of engineering; it looks something like that in the accompanying figure.
This is called the hockey stick model or curve; its shape is strongly suggestive of where the name came from. We’ve talked about how important it is to address reliability and safety early in the requirements specification and design phases of the life cycle. The hockey stick curve provides an intuitive feel as to why. If we label the horizontal axis as time and the vertical one as cost, and apply it here, we see that the longer we delay in addressing those issues, the greater the cost will be. Cost is not constrqained to be money alone.
Let’s begin with the Waterfall model. Use your artistic creativity here. Its name evokes its sound which evokes the philosophy and approach engendered in the model.
12.2.1 The Waterfall Model The Waterfall model represents a cycle; a series of steps appearing much like a waterfall, sequentially, one below the next as we see in the following figure.
Specification
Review and Revise Preliminary Design Review and Revise Detailed Design
Review and Revise Implementation
Review and Revise
Embedded Systems- A Contemporary Design Tool
- 10 -
Copyright 2004 Oxford Consulting, Ltd.
Chapter 12
Embedded Systems - Design and Development ............................................................................. 3 Things to Look For… ................................................................................................................... 3 12.0 Introduction .......................................................................................................................... 4 12.1 System Design and Development ....................................................................................... 6 12.1.1 Getting Ready – Start Thinking .................................................................................... 7 12.1.2 Getting Started ............................................................................................................. 8 12.2 Life Cycle Models ................................................................................................................ 9 12.2.1 The Waterfall Model ................................................................................................... 10 12.2.2 The V Cycle Model ..................................................................................................... 11 12.2.3 The Spiral Model ........................................................................................................ 13 12.2.4 Rapid Prototyping - Incremental................................................................................. 14 12.3 Problem Solving................................................................................................................. 15 12.3.1 Five Steps to Design .................................................................................................. 15 12.4 The Design Process .......................................................................................................... 16 12.5 Identifying the Requirements............................................................................................. 18 12.6 Formulating the Requirements Specification..................................................................... 21 12.6.1 The Environment ........................................................................................................ 22 12.6.2 The System ................................................................................................................ 23 12.7 The System Design Specification...................................................................................... 35 12.7.1 The System ................................................................................................................ 35 12.8 System Specifications versus System Requirements ....................................................... 50 12.8 System Specifications versus System Requirements ....................................................... 51 12.9 Partitioning and Decomposing a System........................................................................... 52 12.9.1 Initial Thoughts ........................................................................................................... 52 12.9.2 Coupling ..................................................................................................................... 55 12.9.3 Cohesion .................................................................................................................... 57 12.9.4 More Considerations .................................................................................................. 59 12.10 Functional Design ............................................................................................................ 59 12.11 Architectural Design......................................................................................................... 66 12.11.1 Hardware and Software Specification and Design................................................... 67 12.12 Functional Model versus Architectural Model.................................................................. 71 12.12.1 The Functional Model............................................................................................... 72 12.12.2 The Architectural Model ........................................................................................... 72 12.12.3 The Need for Both Models ....................................................................................... 72 12.13 Prototyping....................................................................................................................... 73
Embedded Systems- A Contemporary Design Tool
- 1 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
12.13.1 Implementation......................................................................................................... 73 12.13.2 Analyzing the System Design................................................................................... 74 12.14 Other Considerations....................................................................................................... 77 12.14.1 Capitalization and Reuse ......................................................................................... 77 12.14.2 Requirements Traceability and Management .......................................................... 78 12.15 Archiving the Project........................................................................................................ 79 12.16 Summary ......................................................................................................................... 81
Embedded Systems- A Contemporary Design Tool
- 2 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
Chapter 12
Embedded Systems - Design and Development
Things to Look For…
• Things to consider in a design. • The product life cycle. • The five steps to design. • The need to understand the environment and the system being
designed. • The difference between requirements definition and specification. • Motivation for and objective when partitioning a system. • Coupling and cohesion and why they are important. • The differences between functional and architectural models of a
system. • Motivation for and timing of static and dynamic analysis of a design • Capitalization and reuse of designs. • Requirements traceability.
Embedded Systems- A Contemporary Design Tool
- 3 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
12.0 Introduction
In this chapter, we will study the major phases of the development process for embedded systems. The more detailed aspects of that process will be explored in conjunction with the design and test of the specific hardware and software elements of the system.
In this chapter, we will learn that design is the process of translating customer requirements into a working system and that the complexity of contemporary systems demands a formal approach and formal methods. Working from a formal specification of a problem, we will look at ways of partitioning the system as a prelude to developing a functional design. We will then examine the process of mapping functional model on to an architectural structure and ultimately to a working prototype. To help to ensure the robustness of the ultimate product, we will illustrate how to critically analyze the design both during and after development.
We will also look at several other important considerations in the design lifecycle. These will include intellectual property, component/module reuse, and requirements management and the archival process.
As we begin to think about a new product or adding new features to an existing one, we must look at things from many different points of view. The most important of these is the customer’s since he or she finances the development of the product either directly through an agreed upon contract or indirectly through a purchase. The best design of little value if no one is willing to buy. So, we pose the question: What kinds of things should be considered?
If we look at products, we must know how to measure costs and features. We must be
able to identify and distinguish between real and perceived needs. Too
often when we talk with customers about new products, the essential
“requirement” in the next generation product is that which was missing when a problem arose this morning.
It’s important to learn to make market and technology trade-offs. Several years ago the following very simple table was proposed.
Old Market
New
Taking old technology into and old markets is a reasonable and safe
Technology
Old
New
Embedded Systems- A Contemporary Design Tool
- 4 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
strategy. These are the niche markets and often provide support and evolutionary growth for products that are no longer in a vendor’s mainstream offering. Taking new technology into new markets is difficult and risky. At the same time, the rewards can be very high. The personal computer is a very good example. Xerox and Apple both had limited success with their early offerings. The people and the full technology were simply not ready. Taking new technology in to an existing area or existing technology in to a new area is easier. At least one portion of the problem - the market or the technology - is well understood and well developed.
We must understand the importance of deadlines and costs. Product development is based upon a (directly or indirectly) negotiated contract between us and the customer(s). Failure to respect development and delivery costs or schedules leads to loss of sales, market share, and credibility.
We also must always consider reliability, safety, and quality in the products we design. We will study these in great detail shortly. Beyond obvious need to work properly, the product must be robust. That is, simply, ‘Does it do what it’s supposed to?’ and ‘How does it behave with unexpected inputs?’ Robust means much more than this, however. Robust also implies that the system performs even if it is partially damaged, or under extreme temperature conditions, or if it’s dropped. If a product does what it’s supposed to do but is fragile and buggy, the product is not robust.
The documentation we produce to accompany the product must be clear and understandable. The product must be easy to use - intuitive rather than counter-intuitive. Post sales support, including the correction of bugs, is very important. Lack of quality has two costs. The first cost is obvious and immediate, the cost to repair, which is often small. The second a hidden cost, the loss of customer confidence and sales, can be very large. Once confidence lost very difficult to regain.
Embedded Systems- A Contemporary Design Tool
- 5 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
A Simple Example:
Years ago, when developing some of the early microprocessor based embedded systems, we would encounter problems as we debugged the hardware and software. At that time, tools were few and far between. This was a new field.
One very powerful tool for helping to track down such problems is called a logic analyzer. It allows one to follow which instructions the processor is executing (in real-time) and learn why stuff goes in and never comes out. We had to have one, so, our company purchased two of them from two different vendors.
The analyzer from vendor A arrived was out of the box, on the bench, connected to the system, and making useful measurements within 10-15 minutes. Only several days later did anyone think to take a look at the manual. The analyzer from vendor B had a user interface that rivaled a 1040 tax form. Its one-inch thick manual was equally cryptic and demanded several hours of study before even the simplest measurements could be made.
Guess which instrument always has a queue of people waiting to use it and guess which vendor sold us many more instruments.
12.1 System Design and Development
System design and development is a challenging problem. What makes it fun and exciting is that there is a very large creative component to it. There are no rules, no steps to follow to make one creative. There is, however, a large collection of rules to ensure the opposite. Consider a new child. Each comes into this world, eyes wide open with a million questions. Why is the sky blue? Why is the sun yellow? Why can’t we see the air? Where does air come from anyway? What do we do? We put them in school. We teach them the rules. Walk into any group of little ones and ask, how many of you can sing? How many of you can draw? Almost every tiny hand leaps up. Go into any similar group of adults and ask the same questions. Everyone is suddenly fascinated with their shoes. One hand may come slowly up. Why? We place too many restrictions on our thinking. Sure, we may need 10 million dollars worth of electronic equipment to give our voice perfect pitch, but, so what. We need to remove artificial restrictions that we impose on our thinking.
Embedded Systems- A Contemporary Design Tool
- 6 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
Look at the little ones drawing or coloring. What do we tell them? No, people aren’t purple. Cows can’t fly. Fish don’t have legs - anymore. Oh, and by the way, always color in the lines….and let’s also learn how to be creative.
12.1.1 Getting Ready – Start Thinking
Ok, let’s start. Driving is always a good place to begin. The rules are easy. Keep the yellow line on your left and the white on your right – except in Britain and several other places. Now the chance to be creative. In the autumn in the northern parts of the world, the days are warm, but, the nights start getting colder. Often there is a bit of fog that makes an appearance as well. By the morning, the fog and chill have combined to give a very fine glaze of ice on the road. We call this black ice; it gives us the opportunity to be creative. Hop in the car and race out onto the road. What’s this nonsense about staying in the lines?
Now perhaps we’ve decided that maybe we can be just a little creative, let’s begin to explore. As we begin thinking about a new design, we’ll discover that there are a lot of things to be considered. The problem may not always be what it seems at first blush. Roger van Oech in A Whack on the Side of the Head, Warner Brooks, says "Always look for the second right answer.” He’s right. As we begin, it’s important to understand the problem to make sure that we are solving the right problem. Consider the adjacent figure. Which one is the correct image? Is it the old lady or the young one?
When we begin trying to solve a problem, it’s important to talk with everyone involved; to listen to different opinions; to see how the design might affect the people who have to work with it. We have to take the time to look at different views of the problem; to look
at it from both the inside and the outside. Based upon our view, we can have a couple of different interpretations of the following problem. Are we building a goblet or are we building two statues?
Embedded Systems- A Contemporary Design Tool
- 7 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
There will always be occasions in which we have too much information, too many opinions, or too many details. Remember the old expression of not being able to see the forest for the trees. The same holds true as we begin trying to understand a problem during the early stages of a design. Look at this next drawing. What do you see? An interesting design; it looks perhaps like a snowflake. This is a case in which we have too much information.
Let’s remove some of the information – if we take a more abstract view of the problem, the solution is easier to see.
Now that we have a start, let’s look at the design problem. Let’s look at each design as a chance to explore.
12.1.2 Getting Started
Designing and developing embedded systems does raise some interesting challenges and does require a large number of decisions. Some of those decisions require knowledge about the problem, others about the tools and techniques that may be available, and still others choose methods for approaching the solution. There will often be still more things to think about that are not related to the technical part of the problem at all. The collection of these things that we do as we move from requirement to application is often called the product life cycle.
Like so many other things in life, there are probably as many different product life cycle models as there are people designing these systems. Who said there isn’t any creativity? Each of these models has its supporters and each also has it group of detractors. The goal in the next few pages is to introduce some of the more important things that one should think about when executing a design, present several of the more common life cycle models, and to present some guidelines for things that have worked on successful projects. Despite what they tell you, there are no hard and fast rules. Oops, I lied. There are three: learn a lot with each project, have fun, and do the job right…to the best of your ability. Let’s get started.
Embedded Systems- A Contemporary Design Tool
- 8 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
12.2 Life Cycle Models
The product life cycle of an embedded application is purely a descriptive representation. It breaks the development process into a series of interrelated activities. Each activity plays a role of transforming its input (specification) into an output (a selected solution). The organization of the steps is done according to a design process model – the life cycle model. Formality in design provides the structure for a development that lets one creatively explore the design while using the tools to manage some of the more mechanical issues. We use the structure as an aid rather than something that encumbers design.
As we’ve commented already, in the related literature, one can find that a variety of different approaches and models have been suggested. At the end of the day, all have the same basic goal; they all have similar phases. Perhaps, we could more accurately say that they all have similar needs or goals or objectives. These needs are very simple,
• Find out what the customer wants • Think of a way to give them what they want • Prove what you’ve done by building and testing it • Build a lot of them to prove that it wasn’t an accident • Use the product to solve the customer’s problem
Several of the historically more common models or approaches include,
• Waterfall • V Cycle • Spiral • Rapid Prototype
Today, we are continually developing new ones. Which ever model one chooses, the most important point is to understand the meaning and intent or objective of each of the phases or steps in the process. Understand the deliverables for each step as well as the necessary outputs and inputs that are required to move, conclude, or to enter each phase
Embedded Systems- A Contemporary Design Tool
- 9 -
Copyright 2004 Oxford Consulting, Ltd.
Embedded Systems Design and Development
Chapter 12
in the selected model. Then follow those – don’t take shortcuts. We’ll look briefly at each of these four models momentarily. Before we do so, let’s look at another model that fits just about any phase of engineering; it looks something like that in the accompanying figure.
This is called the hockey stick model or curve; its shape is strongly suggestive of where the name came from. We’ve talked about how important it is to address reliability and safety early in the requirements specification and design phases of the life cycle. The hockey stick curve provides an intuitive feel as to why. If we label the horizontal axis as time and the vertical one as cost, and apply it here, we see that the longer we delay in addressing those issues, the greater the cost will be. Cost is not constrqained to be money alone.
Let’s begin with the Waterfall model. Use your artistic creativity here. Its name evokes its sound which evokes the philosophy and approach engendered in the model.
12.2.1 The Waterfall Model The Waterfall model represents a cycle; a series of steps appearing much like a waterfall, sequentially, one below the next as we see in the following figure.
Specification
Review and Revise Preliminary Design Review and Revise Detailed Design
Review and Revise Implementation
Review and Revise
Embedded Systems- A Contemporary Design Tool
- 10 -
Copyright 2004 Oxford Consulting, Ltd.