Figure 1
Carnegie Mellon University
18-849b Dependable Embedded Systems
Spring 1998
Authors: Kanaka Juvva
Software costs are often directly related to the complexity of designing, implementing, and testing a large software system. Hence design plays a very important role in embedded systems, as they constitute a very percentage of software business. Systems Design is an iterative process and broadly comprises five phases: 1) Architectural Design 2) Requirements Analysis 3) System Decomposition 4) Testing 5) Detailed Design and Implementation. The Architectural design is concerned with the structuring of the system to reduce the complexity and feasibility analysis studies. There are two options for structuring : horizontal (layering) versus vertical (partitioning). The feasibility analysis is used to make a "go ahead" decision at the end of architectural phase. The second phase, requirements analysis defines a concise view of system functions and identifies technical and economic constraints. In the third phase, the system is decomposed into subsystems, nodes and their communication network interfaces are identified. The fourth phase is concerned with the functional coherence, testability and dependability of the system components. In the final stage, the i/o interfaces, task development and task scheduling is done and final system is realized. The above mentioned five stages define a conventional design process and modern designs should address the issues such as scalability, dependability and composability. For example, there is a strong tendency in industry to use "COTS" (Commercial Off The Shelf) components to reduce the development time and the cost. On the other end of the design spectrum, there are CAD tools and Software Engineering tools which aid the design process and reduce the time to market.
Many embedded systems have substantially different design constraints than desktop computing applications. No single characterization applies to the diverse spectrum of embedded systems. However, some combination of cost pressure, long life-cycle, real-time requirements, reliability requirements and design culture dysfunction can make it difficult be successful in applying traditional computer design methodologies and tools to embedded applications. Embedded systems in many cases must be optimized for life-cycle and business-driven factors rather than for maximum computing throughput [PHIL96]. The paper discusses about the embedded systems design process and the issues involved in this.
Design is an iterative process. As more is learned about the problem domain, with different design alternatives being explored, there is the need to start all over again more often than once. There is a common core to design activities in many diverse fields: building design, product design, and computer system design are closely related. The designer must find a solution that accomodates a variety of seemingly conflicting goals to solve an often ill-specified problem. At the end, what differentiates a good design from a bad design is often liable to subjective judgement.
Figure 1 shows overview of a product life-cycle [PHIL98]
Figure 1
First a need or opportunity to deploy new technology is identified. Then a product concept is developed. This is followed by concurrent product and manufacturing process design, production, and deployment. But in many embedded systems, the designer must see past deployment and take into account support, maintenance, upgrades, and system retirement issues in order to actually create a profitable design. Some of the issues affecting this life-cycle profitability are discussed in later sections.
Dealing with complexity by layering design representations is prevalent throughout engineering. This layering appears in various disciplines in such concepts as: subsystem decomposition, functional decomposition, control hierarchy, and component subassemblies. In addition, most disciplines use simplifying assumptions in order to make analysis tractable.
Figure 2. Engineering design abstraction uses layers to move between Design
Goal setting and Customer Evaluation.
Figure 2 shows a simplified model of abstraction in the design process that, for the moment, defers the issue of representing structure and behavior.
At the top of Figure 2 is Design Goal Setting. This an activity that determines the envisioned utility of the artifact being designed. At the bottom of the figure is Customer Evaluation, in which the customer evaluates the usefulness of the artifact. It is worthy of note that sometimes the ultimate success of an artifact hinges on the customer finding utility that was not originally envisioned by the designer. Nonetheless, the design process is typically meant to accomplish transformations between Design Goal Setting and Customer Evaluation.
Between Design Goal Setting and Customer Evaluation is the design process. In Figure 2 we show the process as having refinement stages (the process in this figure has one refinement stage; real processes will often have multiple such refinement stages). The Initial Design stage is a high-level design formulation that takes into account design goals and is evaluated in terms of correctness, completeness, and various figures of merit (e.g., cost, weight, size, human factors, speed). The Refined Design stage is a more detailed design that is in turn fed by Initial Design goals and evaluated according to refined criteria. Iterations among levels are likely in any real design process as goals are modified in an attempt to improve evaluation scores.
Even though a process of abstraction allows using simplified artifact descriptions, these descriptions must nonetheless be complete. For engineering design, this means that not only must a behavior be specified, but also a structure in which to embed that behavior. For example, if a design includes the structure of a switch (or, more generically, a sensor of indeterminate type), then it is typically desirable to somehow describe the behavior of that switch when actuated. Similarly, specifying the behavior of a switch actuation makes no sense without the context that there is, in fact, the structure of a switch.
Figure 3. Design layers must each deal with both Structure and Behavior.
Figure 3 shows that inside each design stage (both Initial Design and Refined Design) are two components: Structure and Behavior. At the level of Initial Design, Structure is a proposed artifact organization in terms of both physical and logical sub-entities (e.g., subsystems, functions, assemblies). The Behavior consist of operational scenarios and sequences for these sub-entities. For example, if the input Goal is transportation, and the initial Structure is a car having an engine and transmission, then initial Behavior might include sequences of operation such as engine start, transmission shift into gear, and engine acceleration. It is possible to have tradeoffs within both structure and behavior as well as between them. For example, a simpler behavior (eliminate overt gear shifting operations) might come at the expense of a more complicated structure (a continuously variable transmission). Conversely, one could see the tradeoff as the transmission structure being simplified (discrete gears instead of continuous variability) at the expense of complicating the behavior (adding the concept of shifting gears).
At the next design layer down, the Refined Design is similarly composed of a Structure and Behavior. The refined Structure is the detailed organization of the artifact (e.g., components, modules) necessary to implement specifics of initial Behaviors. The refined Behavior has a greater level of detail to address the greater complexity of the refined Structure. To further the example, the refined Structure for the transmission might be an automatic or manual transmission. The refined Behavior for the manual transmission would include details of clutch pedal operation irrelevant to a refined Behavior for a manual transmission.
The process of design is not static. We hypothesize that there are two primary design activity loops between every pair of layers in the design abstraction hierarchy. Figure 4 shows two layers of design that could be embedded in a multi-layered design abstraction framework. There are two loops that represent separate but complimentary processes: structure synthesis (Figure 4a) and behavior refinement (Figure 4b). Structure synthesis involves refining and evaluating structure by way of an intermediate behavior. Behavior refinement involves refining and evaluating behavior by way of an intermediate structure.
Figure 4a. The structure synthesis loop generate the refined Structure.
Figure 4b. The behavior refinement loop generates the refined Behavior.
Market Forces
Embedded system design is often subjected to market forces as explained below.
Design costs, also called Non-Recurring Engineering costs (NRE), are of major importance when few of a particular embedded system are being built. Conversely, production costs are important in high-volume production. Embedded systems vary from single units to millions of units, and so span the range of tradeoffs between design versus production costs.
At the low-volume end of the spectrum, CAD tools can help designers complete their work with a minimum of effort. However, at the high-volume end of the spectrum the designs may be simple enough and engineering cost such a small fraction of total system cost that extensive hand-optimization is performed in order to reduce production costs.
CAD tools may be able to outperform an average engineer at all times, and a superior engineer on very large designs (because of the limits of human capacity to deal with complexity and repetition). However, in small designs some embedded computer designers believe that a superior human engineer can outperform CAD tools. In the Small system example a programmer squeezed software into a few hundred bytes of memory by hand when the compiler produced overly large output that needed more memory than was available. It can readily be debated whether CAD tools or humans are "better" designers, but CAD tools face skepticism in areas that require extraordinary optimization for size, performance, or cost.
The cycle time between identification of a product opportunity and product deployment (also called Time to Market) can be quite long for embedded systems. In many cases the electronics are not the driving force; instead, product schedules are driven by concerns such as tooling for mechanical components and manufacturing process design. Superficially, this would seem to imply that design time for the electronics is not an overriding concern, but this is only partially true.
Because the computer system may have the most malleable design, it may absorb the brunt of changes. For example, redesign of hardware was required on the Mission Critical example system when it was found that additional sensors and actuators were needed to meet system performance goals. On the Small example system, delays in making masked ROM changes in order to revise software dominate concerns about modifications (and programmable memory is too expensive). So, although the initial design is often not in the critical path to product deployment, redesign of the computer system may need to be done quickly to resolve problems.
In many cases embedded system designs are not unique, and there are a variety of systems of various prices and capabilities forming a product family. To the extent that system designers can reuse components, they lower the total cost of all systems in the product family.
However, there is a dynamic tension between overly general solutions that satisfy a large number of niche requirements, and specifically optimized designs for each point in a product family space. Also, there may be cases in which contradictory requirements between similar systems prevent the use of a single subsystem design. In the Mission Critical and Small examples different customers require different interfaces between the embedded system and their equipment. In the Distributed example regulatory agencies impose different safety-critical behavior requirements depending on the geographic area in which the system is deployed.
There are no general purpose tools for embedded system design. Use of CAD tools for embedded system design is being considered. Also there are some synthesis tools available for hardware/software co-design.
VERIFICATION/VALIDATION/CERTIFICATION
Embedded computers can affect the safety as well as the performance the system. Therefore, rigorous qualification procedures are necessary in some systems after any design change in order to assess and reduce the risk of malfunction or unanticipated system failure. This additional cost can negate any savings that might have otherwise been realized by a design improvement in the embedded computer or its software. This point in particular hinders use of new technology by resynthesizing hardware components -- the redesigned components cannot be used without incurring the cost of system recertification.
The business models under which embedded systems are developed can vary as widely as the applications themselves. Costs, cycle time, and the role of product families are all crucial business issues that affect design decisions.
Notes: Wide variety of info on real-time systems. There is a chapter on design.
Notes: This paper discusses about life-cycle issues and business issues in the design of embedded systems.
Notes: This paper deals with the limitations of CAD tools, when they are applied for embedded system design.
Notes: This paper is about the design patterns for real-time systems using real-time UML. It describes some design patterns for real-time systems.
Notes: It presents an augmented model of design that couples behavior and structure in a way that supports a variety of strategies for making the design process efficiently responsive to change.