Life Cycle Considerations

Carnegie Mellon University
18-849b Dependable Embedded Systems
Spring 1999

Author: Philip Koopman


The life cycle of an embedded system varies dramatically, from processors embedded in disposable consumer goods to applications requiring maintenance and support for decades. Designing an embedded system often requires taking into account the complete product life cycle, from initial product concept, through its operational period, and into replacement with newer equipment. While the design phase is covered by other topics, areas of specific concern to a life cycle perspective are: an accurate life cycle economic model to guide engineering tradeoffs, taking into account requirements for logistics and support over the product operational period, and issues specific to refurbishing/retiring/discarding the system at end-of-life. While the term "life cycle" has different meanings to different technical communities, the central idea is to expand the traditional engineering emphasis on the "design cycle" to encompass optimizing utility, profits, and tradeoffs across the entire lifetime of the embedded system being designed.



The idea of a product life cycle acknowledges the fact that designing and selling a product is only part of the story. In fact, every product goes through a series of steps between the time it is first conceived and the time the manufactured product is retired or discarded. Figure 1 shows one view of the various phases of a produce lifecycle [ref to edrc material].

{life cycle circle}

Figure 1. The phases of a product life cycle. (click for larger version)

The product starts with a need or opportunity in the marketplace. In embedded applications, this need has historically been a goal of reducing cost or increasing the functionality of an existing electromechanically controlled system by inserting computer technology. An example is digital engine controllers for automobiles, which were virtually required to meet tougher emission controls that could not be handled by mechanical engine controllers. At other times, completely new opportunities exist because of the progress of technology. As a somewhat frivolous example, greeting cards that play music or recorded messages require fairly sophisticated, inexpensive electronics for operation.

Once a need or opportunity is defined, a concept for a product is created. As an example, a product concept might be something like a digital cell phone instead of an analog one, in order to reduce audio noise heard by the user. With a life-cycle approach this stage involves not only defining the product, but also addressing the business model of how the company will make money from the product, how users will employ the product, how the manufacturer and/or user will benefit from any potential upgrades, and how the product will be retired, disposed of, or refurbished.

After concept development, both the product and manufacturing process are designed. In some cases an existing manufacturing process is taken as a fixed parameter, but often it is more efficient to permit changes to the product to accommodate manufacturing needs as well as changes in the manufacturing process to accommodate product needs. In many embedded systems the manufacturing volumes are quite high, making it worthwhile to modify or even create new manufacturing processes. Additionally, in smaller companies that create embedded products, much of the manufacturing process may actually be created via contract manufacturing, meaning that creating the manufacturing process consists largely of selecting vendors for various process steps and then arranging them in the appropriate order rather than arranging manufacturing equipment at the company's own plant.

Within product design, it is common enough to take the approach of designing something that functions correctly and can be manufactured for a profit. However, with a life cycle approach it is often better to maximize profit across the entire lifecycle, even if that means reaping less product on the initial equipment sale. For example, a system that is to be upgraded might be designed with higher-priced component sockets or connectors that support multiple installations and removals, rather than less expensive sockets that can only be used a single time. (There is, obviously, a tie-in to the business model at this point, and there may be structural impediments within a company that prevent such global optimization.)

Once the design process is completed, the equipment is produced and deployed. Considering for these life cycle phases in product design can reap significant profits. For example, automatic component placement machines can only handle a fixed number of different components, so designing to stay within that limit either speeds up production throughput or avoids the cost of buying a second placement machine. Similarly, considering deployment requirements during the design phase can be quite beneficial. For example, a user interface on a new piece of equipment might be made to mimic the user interface on an older, non-computerized piece of equipment to reduce the need for customer training even though a radically new interface might be slightly more efficient or cheaper to manufacture.

After the product is deployed, it must be supported and maintained. Support and maintenance for desktop software is dominated by technical support phone calls with problems of installation, bug reports, and difficulty using advanced features. Desktop hardware maintenance far less frequent, and involves situations such as disk crashes, dirt, and power supply failures. Embedded systems seem to have a somewhat different focus for support and maintenance. Since the embedded software is often more focussed on controlling some other system, the amount of software functionality exposed may be significantly less than in a software product such as a spreadsheet or database. However, user interfaces are often minimal, making it difficult for the user to access the available functionality (the classical example is setting the time on a VCR). Thus, technical support is more likely to be help due to user interface obstacles or mismatches between the consumer's mental model of operation and the actual software design. From a maintenance point of view, interactions with other products are less likely to be an issue since the embedded system comes with its own dedicated computer. However, embedded maintenance is complicated by the fact that problems may be due not only to a computer failure, but in fact are more likely to be due to failures in sensors, actuators, or mechanical components. Thus, in support and maintenance it is important to provide extensive diagnostic and monitoring in complex embedded systems to facilitate repair.

The need for upgrades varies dramatically depending on the life expectancy and usage of the embedded system. At the low end, some embedded systems are completely disposable, such as the electronic greeting card mentioned above, many toys, and consumer products in which repair labor is more expensive than the product, or in which products are evolving so quickly that products are obsolete before they have a chance to break (this is probably the case with digital cameras at the moment). On a larger time scale, however, enduring embedded systems must be upgraded once or more during their product life. For example, elevators can remain operation for up to a hundred years or more, but are upgraded every decade or so. The same is true of many expensive pieces of equipment such as military weapon systems or aircraft, which must be operated for many years to amortize purchase costs. With equipment that is likely to be upgraded, it is important to design the system in such a way that upgrades can be done cost-effectively, and that system downtime is minimized during upgrade. Perhaps the most extreme example of design-for-upgrade is in telephone switches, which are required to operate continuously through a system upgrade.

Finally, all embedded systems are eventually retired, discarded, or replaced. Designing the system to be retired gracefully can significantly reduce costs to the manufacturer, the user, or society as a whole, as is discussed in a later section.

Key Concepts

While the notion of a life cycle encompasses a very broad range of topics, there are three particular life cycle areas that are not covered in other topic discussions: life cycle costing, logistics, and design-for-disposal (also known as life cycle assessment, or "green design").

Life Cycle Cost

The life cycle cost of a product includes not simply the cost of materials and labor to manufacture it, but in fact all costs associated with the product from inception to retirement. The idea of a life cycle approach to cost is not specific to embedded systems, but rather is more generally applied to very expensive capital purchases such as buildings, factory machinery, and military systems (ships, planes, tanks, etc.). However, since embedded system designers are often embedding computers in such expensive systems, it behooves them to understand the financial model for life cycle costing so that they can take this into account in their work.

Kirk & Dell'Isola's book [Kirk95] provides a comprehensive look at life cycle costing from the perspective of operating a commercial building, such as an office building (the following discussion is based on material from that book with some augmentation). However, the concepts they discuss apply to many embedded systems in general. (As an aside, an office building is in fact an embedded system. There are computers controlling the climate, operating the elevator system, and in many cases controlling the lighting. In some buildings these three systems are beginning to be coordinated for efficient operation as well as lower cost maintenance.) In general, the factors included in the life cycle are those discussed in the previous section with respect to design and retirement of the product. In general, the idea is to minimize total cost for owning and operating an embedded system over the complete life of that system. This means that in addition to technical design factors, specific economic factors must be considered.

The life of a product is the shortest of three different aspects of system life:

Although it may not be possible to completely predict the lifetime of a system in advance, it is estimated taking these three factors into account. Then, the direct costs of ownership are considered, including:

Additionally, there are many indirect costs that must be taken into account in a complete financial model. These indirect costs of ownership include:

The above life cycle costing approach works well for many large-scale embedded systems, where consumers are very sophisticated and equipped to invest for the long term. However, with consumer products it may be much more difficult to create a design that is optimized both to achieve profitable sales as well as maximum utility for the purchaser.

Antonides [Antonides90] discusses a combination of economics and psychology for durable goods purchases. While they come to the conclusion that frequency of use is generally related to reliability, and the cost of the good is generally related to its lifetime (when comparing different similar goods of different prices). While this is probably no surprise, the finding that makes life difficult for embedded system designers is that the decision of when to scrap a product is made on a potentially distorted view of life cycle economics. It should be noted that this is a European study and thus not necessarily representative of North American consumers. However, the specific points mentioned seem to ring true in general (the following is an interpretation and amplification, not a quotation):

When taken as a whole, the point of life cycle costing is to take into account all the direct and indirect costs of a product, and optimize for the lowest total cost given the constraints of customer preferences/behaviors.


Logistics is the process of managing acquisition, movement, and storage of parts, materials, and products [Christopher92]. It has been a specialized discipline for a very long time in the military, which is of course vitally connected with keeping troops properly supplied. In the embedded systems life cycle, logistics affects the life cycle phases from production through retirement.

Logistics can be viewed along two axes: by type of item, and by activity. In either case the objective is to assure that materials are available where and when needed at minimum cost. This often involves tradeoffs of risks that demand or supplies will fluctuate vs. the cost of maintaining inventory (these costs include not only the cost to make space and staffing available, but also the debt burden of the money tied up in inventory as well). The particular types of items affecting logistics are:

The types of activities that most affect logistics are below. They are to a large degree a different view on the same issues as the types of items, with the exception of disposal concerns:

The main concern about logistics for embedded system designers is to ensure that design decisions are made on a more global scope than simply minimizing per-unit component costs. In particular, it is important to take into account the cost of sinking a large amount of money into spares that must be stored over many years for long-lived systems.

Life Cycle Assessment ("Green Design")

A third general area of life cycle considerations is specifically that of designing products for ecologically friendly retirement and disposal. This is a relatively new, but fairly active area of academic research, with roots back to the ecology movement of the 1960s. The basic idea is that products should be designed with disposal, operational consumption of resources, and operating pollution specifically in mind, just as manufacturing efficiency is considered in many designs. This area has now matured to the point that there are international standards for approaching the problem, including the ISO 14000 series, and in particular ISO 14040 "Life Cycle Assessment".

As an idea of the magnitude of the impact a system designer can have on recycling effectiveness, [Goldberg98] states that there is an IBM estimate that discarded computers will occupy 2 million tons of US landfill space by the year 2000. Although embedded systems are more prevalent, it is in some cases more difficult to understand their impact on landfill space because they are so often hidden inside other equipment. However, even so, there are many techniques that embedded system designers can employ to reduce the environmental impact and societal costs of their designs, including:

In general, the Green Design approach to the life cycle is to consider the end of the product life when doing the design. A tricky way in which this ties in to the life cycle costing model is that society as a whole (and our descendents) pay a hidden price for pollution and resource exhaustion that are difficult to take into account in a single-product life cycle model. The only proven wide-scale techniques for accounting for these costs is government taxation/rationing (such as with Freon to discourage manufacture and consumption) and recent European initiatives to make manufacturers accountable for disposal of waste streams their products generate.

Available tools, techniques, and metrics

The state of the art in tools, techniques, and metrics varies widely depending on the particular area in life cycle concerns. Life cycle costing is generally an accounting approach that is not encountered by every-day design engineers, and measures results in dollars. Logisticians have a variety of mathematical optimization tools available, and in fact are intimately tied to the field of Operations Research (e.g., the Simplex method), and measures results in terms of achieving maximum efficiency for a given flow rate objective. Green design currently employs tools of a sort of "spreadsheet" nature that link raw materials and components with the waste streams they generate at end-of-life, and typically measures results in terms of tons of landfill space consumed.

Relationship to other topics

Life cycle concerns are not a particular technical expertise area the way that many of the other topics are. Instead, it is an overlay concept that suggests that each technical area consider the impact of decisions on the rest of the areas.

Related Topics:


The following are the key ideas for this topic:

Annotated References

Further Reading

Index of other topics

Home page