System-Level Design

Scope and Objectives of System-Level Design

At the system level, designs are viewed as collections of large, arbitrarily complex, functional units. The units typically form the major components of a system. Connections among units in system-level designs may also be arbitrarily complex, carrying unspecified data and information. A system-level description of a design may exist only to show design topology without providing excessive detail -- all that matters is whether or not a particular function block connects to another. A precise method of communication is not important.

Present-day strategies for the system-level development of complex systems are limited in several respects:

  1. Design Concerns are Poorly Organized

    Designers are typically concerned with things like system behavior, system structure, generation of system alternatives, mechanisms for communication and computation, and metrics for performance assesment and trade-off. In systems engineering, the system-level design is further complicated by the need to partition development activities for team design. The specification of interfaces provides an opportunity to define system-level constraints that must be satisfied by the sub-system designs.

    When these concerns are poorly organized, opportunities for reuse and procedures for exploring options in the design space may become clouded and inefficient.

  2. Premature Commitment to Technology

    Present-day strategies for system development tend to make commitments to a specific technology too early in the development lifecycle. This strategy of development works well for design activities that are mature and in a steady state. However, for design areas where the underlying technologies may be changing fast (i.e., every couple of years), technology-specific system specifications are likely to burden the designer with unnecessary references to implementations, and eliminate good design options from further consideration resulting in an over-determined representation with respect to designer intent. Moreover, longevity of the final design may also be limited because it is too strongly tied to a specific technology.

    Fortunately, there is a well-defined pathway from information gathering, to constraints, to entropy associated with the design options that are possible. Generally, gathering information about a design allows for new constraints to be added to the design specification. A more tightly constrained design specification reduces the entropy (or uncertainty) associated with the design options that are possible. The "minimum commitment princple" states that no decision should be made beyond what is necessary to ensure the quality of the current solution (Dym, 2002). This strategy of development ensures that the designer has maximum scope later in the design process to made decisions about the specifics of a particular design (O'Sullivan, 2002).

  3. Poor Support for Early Detection of Design Errors

    The complexity of engineering systems is rapidly approaching where it will be impossible to verify correctness of the design without also introducing a verification-aware discipline in the design process.

Refinements to present-day strategies for system-level development involve trade-offs, of course. While commitments to a specific technology may reduce the design options that are available, the pathway to an immediate design that is acceptable may be streamlined.

We will attack these inefficiencies on three fronts: (1) function-architecture co-design, (2) logical design followed by physical design, and (3) provision for design formalization and early detection of errors.

Function-Architecture Co-Design

Function-architecture co-design is a system level methodology that promotes the description of systems in two orthogonal ways.

System structure and system behavior are essential views of any system description. Simply put, behavior is "what a system does" to fulfill its purpose. Structure is "how the systems is built." With these two views in hand, the system description (or system design) alternatives can be obtained by mapping the system behavior viewpoint onto the system structure alternatives, as shown in the adjacent figure.

[System Pathway2]

Figure 1. Mapping Models of System Behavior onto System Structure Alternatives

When models of the "system behavior" are mapped onto the "system structure" alternatives, both the functional processing and communications interfaces are explicitly mapped to the system's architectural resources. This determines their performance and cost, and creates a framework for evaluation, ranking and trade-off among alternatives.

So why go to all this additional effort? Lessons learned in industry indicates that a clean separation of system functionality and system architecture enables much easier modifications of the design at the system level, and reuse of major components. These advantages have allowed for a rapid escalation in the complexity of systems that can be designed. (Martin and Salefski, 2001). (Later on a trade-off analysis can be performed to pick the best solution.)

Logical Design followed by Physical Design

Present-day system development processes pass through four stages: (1) planning and analysis, (2) system architecting, (3) system design, and (4) build and test.

We will attempt to modify this process by creating design methodologies that first create a (technology independent) "logical design" followed by a "physical design" having the technology filled in. During the physical design, all of the required hardware-software, hardware-hardware and software-software partitioning is carried out.

Provision for Design Formalization and Early Detection of Errors

Formal models of designs are needed to facilitate correctness of design decisions. Communication among entities is characterized by well-defined flows of data and information (in response to occurrences), and enabled by well-defined entity interfaces.

[Reuse Maturity's]

Figure 2. Pathways of Development, Now and in 2010-2020

Future systems design procedures will partition verification procedures into three phases (see the right-hand side of the adjacent figure). and will use formal methods and precise language semantics for design specification and verification. By moving parts of the verification process up to the logical design phase, design corrections will be easier and cheaper to make.


Logical System Design

The logical system design provides:

Spatial constraints are defined by relationships among the system elements. Temporal constraints are defined by relationships among events in scenarios of system behavior (e.g., required sequencing of activities for proper behavior to occur).

Development Procedure

We create the logical design by: (1) decomposing the system into a network of logically connected components; and (2) mapping models of system behavior onto system structure alternatives.

[System Design]
Figure 3. Pathway of System Desgin Development -- Mapping System Behavior onto System Structure

Development of the logical architecture:

Step 1. Logical Decomposition and Relationships

Logical decomposition represents a systematic method for identifying the system objects. Tasks are as follows:

Relationships

At this stage of development, the design will be typically viewed as a collection of key subsystems (or large functional units) which may be arbitrarily complex. Connections among the subsystems may also be arbitrarily complex. To keep the complexity of development in check, all that matters is whether or not a particular subsystem connects to another subsystem.

The precise purpose of the connectivity is not eminently important -- in an electrical system the connection might carry a current; in a computer system it might carry data or information; in a mechanical system tha connection may act as a pathway for transferring a force to a supporting foundation. With the topological details of the connectivity established, details on the actual form of the communication and its effect on system performance and cost can be filled-in later in design.

Role of Technology and Physical Constraints

The logical system-level design shows what the system will do, without committing to any one technology. This does not mean, however, that "technology" plays no role at the logical design stage. To the contrary. When a system is developed to work within a well-defined environment, the nature of that environment usually places constraints on the space of design alternatives that are possible. Some examples are as follows:

  1. Design of a Seismically Resistant Building

    The dynamical behavior of a building designed to stand up in a severe earthquake (i.e., this is the external environment) is constrained to follow the laws of physics (F = m.a). This behavior will also be affected by the choice of building materials -- but that is a decision that should be dealt with at the physical design.

  2. Design of a CD Player

    A CD player design must be consistent with the physical and optical standards defining a CD!

  3. Design of a Traffic Intersection

    For cars to pass safely through traffic intersection, drivers should obey "rules of the road." Also, because the notion of a car is already fixed, geometry of the roadway and appropriate traffic controls must be adequate to: (1) carry the cars and (2) allow for control the traffic. The first item places a minimum width on the roadway. The latter constraint -- clearly this option will not be economically competitive -- places an upper practical bound on the roadway width.

Also, even though a commitment to a "specific technology" may not be made at the logical stage of design, the features (e.g., performance; cost) of a range of available technologies may be well known. This range of capabilities may be represented by design intervals, and used to eliminate design alternatives from further consideration.

Step 2. Mapping Behavior onto Structure

The mapping procedure involves three elements:

After scheduling is complete, the allocation and binding tasks define flows of data and information through the system architecture in response to external events.

Example 1

Here we consider a very simple model of behavior mapped onto a very simple model of system structure.

[Traceability: Fig 3]

Figure 4. Task/Component Interaction Matrix for System Behavior Mapped onto Structure.

System behavior is captured by the sequence of tasks: Task A, Task B and Task C. We assign Task A to Component A, Task B to Component B, and Task C to Component C. This simple task-to-component mapping can be expressed:

Task
(is mapped to)
Component
Task A   Component A
Task B   Component B
Task C   Component C

Table 1. Mapping Tasks (System Behavior) onto Components (System Structure)

Notice that while components A and B are connected, component C is connected to neither A nor B. Hence, although the tasks are cleanly mapped from "function" to "component implementation" a pathway of connectivity from component B to component C does not exist. Hence, the system cannot work as required.

Step 3. Execution of Logical Scenarios

Logical scenarios are elaborated by tracing the pathway of data/information through the logical system design in response to external inputs. We hope to answer:

Some of these questions are very very difficult to answer (so don't feel bad if you doesn't know how to approach these problems), and there is a strong need for new methodologies that will simplify and streamline their solution. In the long term, we envision visual tools for evaluation and debug of logical designs.

Step 4. Validation of System Behavior

We need to make sure that the desired model of system behavior matches the implemented model of system behavior. As shown in the adjacent figure, reaching a suitable match may require several iterations.

[OO Behavior]

Figure 5. Validation of System Behavior

Each iteration begins with a description of desired behavior, possibly expressed as a series of messages between objects in a sequence diagram, and ends with an equivalent description of the "as modeled" system. At the end of each interaction, the "desired" and "as modeled" behaviors are compared.

This example shows "desired" behavior expressed in terms of sequence diagrams, however, it may also be represented using state diagrams,

Step 5. Trade Studies

Here we explore variations in "logical design" objectives throughout the design space bounded by constraints eminating from spatial and temporal relationships.

This stage of development is challenging because we need to coming up with quantitative measures for assessment (e.g., system cost, performance, reliabilty ... etc) without making a commitment to a specific technology.

So how to move forward? The key observation is to note that while a commitment to a particular technology need not be made, in many cases we will know ahead of time, the range of technologies that are possible, their costs, performance capabilities, and so forth. So instead of conducting a trade-off analysis with specific numbers for each design attribute, we can work with [min, max] intervals bounding the range of possibilities. Based on this information alone, and the relationships defined among the system components, it may be possible to eleminate (and further constrain the design space) some options from further consideration.

Example 2

The adjacent diagram

[System trade-off]

Figure 6. Pathway from system constraints to a constrained design space and tradeoff

shows how the presence of relationships in the system structure leads to constraints in the design space, which in turn defines a set of design alternatives for preliminary evaluation and trade-off of design attributes.


SYSTEM-LEVEL DESIGN CRITERIA

System-level designs employ partitioning criteria that address critical requirements and promote sound design practices. Common criteria are as follows:

System level designs with a minimal number of small and explicit interfaces combine to keep interfaces as simple as possible. A quantitative assessment of these factors is possible by organizing activities via a design structure matrix and then superimposing the system structure onto the design structure matrix. The overlap of structure border and behavior will provide a rough estimate of interface complexity among system components.

Evaluation Criteria for Design Decompositions

Decomposition is the process of breaking the design at a given level of the hierarchy into components that can be designed and verified almost independently. Guidelines for the design of modules are as follows:

The motivation for following these guidelines is modules that will be functional, easy to understand, testable, and reusable.

Functional Decomposition.

Functions in the behavior model are reorganized so that:

Coupling

Coupling is a measure of the interface complexity (or degree of interdependence) between modules.

[System Design Criteria 1]

Figure 7. Highly-coupled and loosely-coupled system architectures.

In design, we should:

Cohesion

Cohesion is a measure of how well the components of a module are related to one another (put another way, cohesion is a measure of the functional association of the element within an element). In design, we should:

The criteria of coupling and cohesion work together. Generally speaking, modules with components that are well related will have the capability of plugging into loosely coupled systems.

Module Complexity

Modules should be kept as simple as possible, and hide the details of implementation from the outside environment.

[System Design Criteria 2]

Figure 8. Factors contributing to module complexity.

Three factors that contribute to module complexity are: (a) its size, (b) the number of internal functions and connections within the modules, and (c) the number of interfaces to the modules.

Guidelines for Mapping Behavior onto Structure

Points to note are as follows:

  1. Try to design components that will serve a single function (high cohesion).
  2. Try to map individual elements of system behavior/functionality onto individual elements of system structure.
  3. Promote component isolation (i.e., through encapsulation and information hiding);
  4. Promote common functions, inputs and outputs;
  5. Promote commercial off-the-shelf (COTS) reuse.

Items 1 and 2 lead to simplified maintenance strategies. Item 3 helps to keep the complexity of development in check. Item 4 simplifies communication among subsystems and, thereby, enhances the opportunity for system expansion. Item 5 improves the economics of system development through reuse.


DESIGN CONCEPT ENHANCEMENT/TRADE-OFF ANALYSIS

In this section we look at analytical tools that can represent and potentially enhance design concepts (e.g., properties of a system architecture) and design processes (e.g., sequencing of activities).

The degree of coupling between tasks is an important metric for final design implementations because the higher its value, the higher the cost of communication among modules. Finding the right balance in criteria is an art:

The mapping consists of choosing the best allocation of the clusters according to a number of factors (Carchiolo et al., 2000):

  1. Performance

    Generally speaking, for an improvement in performance to occur a cluster must be implemented in hardware.

  2. Ease of Modification

    This parameter is difficulty to quantify. However, because software is much easier to modify and update than hardware, it needs to be traded off against performance.

  3. Implementation Cost

    The choice of a good cluster has significant impact on the cost of implementation/manufacture in hardware and/or software.

  4. Cost of Communications

    Sometimes the additional cost of communications among modules can be significant.

This framework means that we can now decide whether a component should be implemented in hardware or software according to a cost function that takes these factors into account (most likely in an empirical way).

Example 1

[Traceability: Fig 4]

Figure 9. Coarse Mapping of System Behavior onto System Structure

Configuration 1: This simple architecture is partitioned into two subsystems, and thus has few interfaces. As a result, there is limited downstream opportunity for trade-off in selection of hardware and software.

Example 2

[Traceability: Fig 5]

Figure 10. Fine Mapping of System Behavior onto System Structure

Configuration 2: More complicated architecture; more interfaces; better downstream opportunity for trade-off in selection of hardware and software. Also notice the use of a "facade" interface to simplify connectivity between the two main subsystems.

Use Case/Component Interaction Matrices

A single system component may support the operation of multiple use cases. Conversely, a single use case may be supported by multiple system components. A convenient way of visualizing the role of components in the execution of use cases is through a use-case/component matrix. See the adjacent figure.

[UML Usecase Matrix]

Figure 11. Use Case/Component Interaction Diagram

A use case/component interaction matrix provides:


DESIGN AT THE SUB-SYSTEM LEVEL


CASE STUDY: VLSI DESIGN VERSUS MECHANICAL DESIGN

When you look at across a spectrum of engineering disciplines to see how engineering systems are described, a basic question to ask is:

"Are some types of engineering system more easily decomposed into hierarchies,
and amenable to orthogonalization of design concerns ... and so forth ... than others?"

This issue has been investigated by Whitney (Whitney, 1996) by critically comparing features of VLSI and Mechanical Design. See the following table:

Issue
VLSI Design
Mechanical Design
Component design and verification. Model-driven single function design based on single function components; Design is based on rules; Relatively, only a small number of component types needed. Multi-function design (single-function design plays a minor role). Components verified individually, repeatedly and exhaustively. Many component types are needed.
Component behavior. Is the same in systems and in component isolation. Behavior is dominated by logic; described by mathematics; small design errors do not destroy the system. System and component behavior is different. Behavior dominated by power/energy, approximated by mathematics.
System design and verification. Rules of logic in subsystem can be propagated up to system level. Logical implementation of main functions can be proved correct. System design is separable from component design. Main system functions are accomplished by standard elements. Building block approach can be followed. Logic captures a tiny fraction of behavior. System design is inseparable from component design. Main function design cannot be proven correct (well, not yet anyway). Large design effort devoted to side effects. Systems tend to be strongly coupled -- component behavior changes when they are connected into systems`.
System behavior. Described by a logical "union" of component behaviors, dominated by a main function. No top-level description of behavior exists. Union of component behaviors largely irrelevant.

Table 2. VLSI Design versus Mechanical Design

Points to note are as follows:

  1. The multi-function nature of mechanical components means that designers spend significant attending to side effects. This, coupled with the lack of a main function, is one reason why mechanical systems require so much design effort for apparently so little complexity of output.


USING DESIGN PATTERNS FOR SYSTEM-LEVEL DEVELOPMENT

Definition of Design Patterns and Patterns Languages?

Experienced designers know that instead of always returning to first principles, ``routine design problems'' are best solved by adapting solutions to designs that have worked well for them in the past. In the software engineering community, for example, it is now possible to synthesize solutions to software problems by stitching together patterns, or architectural templates, of problem solving that are known to work well (Schmidt 1994, Gamma 1995). This approach to problem solving is popular because it encodes many years of professional experience, and is time efficient.

Families of good designs tend to share ``patterns'' in their development. A design pattern is simply:

  1. A description of a problem that occurs over and over again, and
  2. A description of a generalized (or core) solution to that problem stated in such a way that it can be reused many times, but without doing it in the same way twice.

In other words, a design pattern prescribes a:

      [ problem, solution ]

pair. Design patterns crop up in many avenues of day-to-day life and in nature. For example, that layout of streets in planned communities follows familiar patterns, as does the growth of snowflakes. Each snowflake may have the same pattern, and yet, be quite unique. To become a chess master not only must you know the rules and principles of the game, but most study the games of other masters -- these games contain patterns that need to be understood, memorized and applied repeatedly.

From an engineering point of view, patterns are important because they provide a solution to a problem in a context. The four essential components of a pattern are (Gamma, 1995):

  1. Pattern Name. This is a short label we can use to describe a design problem, its solutions, and consequences.
  2. Problem. This component describes the problem and its context, and when the patterns apply.
  3. Solution. The solution describes the elements that make up the design, their relationships and responsibilities, and collaborations. The solution does not describe a particular design or implementation -- instead the solution is a template (or abstract description) that can be applied to the solution of many different specific problems.
  4. Consequences. The consequences are the result and trade-offs in applying the pattern, and are critical for evaluating design alternatives, and for understanding the costs and benefits of applying the pattern.

Gamma and co-workers (Gamma et al., 1995) point out that patterns facilitate reuse -- one persons pattern can be another persons fundamental building block. The design pattern identifies the participating subsystems and parts, their roles and collaborations, and distribution of responsibilities.

When to use Design Patterns

Design patterns are a useful when (Schmidt, 1994):

  1. Solutions to problems recur with variations.
  2. Solutions to problems require several steps. A design pattern may be overkill for problems that only require one step.
  3. The problem solver is more interested in the existence of the solution than its derivation.

Patterns leave out much of the information needed to fully understand a solution procedure. However, when an engineer is looking to fill a gap in a problem solving procedure, a pattern can be just what is required to fill in the missing piece.

What design patterns will and will not do for you.

Design patterns capture the essence of proven solutions to recurring design problems. Patterns are not the best way to explain or present all types of problems. When the conditions expressed in the "problem context" hold, the solution strategy is a very good approach to solving the problem.

Patterns are not a good vehicle for the following purposes (see Binder, pg. 329):

Systems Engineering Design Patterns

Type of System/Type of Pattern Behavioral Patterns Structural Patterns Creational Patterns
Software Dominated
Systems
Chain of Responsibility Pattern
Command Pattern
Interpreter Pattern
Iterator Pattern
Mediator Pattern
Observer Pattern
State Pattern
Template Pattern
Visitor Pattern
Adapter Pattern
Bridge Pattern
Composite Pattern
Decorator Pattern
Facade Pattern
Flyweight Pattern
Proxy Pattern
Abstract Factory Pattern
Builder Pattern
Factory Method Pattern
Prototype Pattern
Singleton Pattern
Hardware-Software
Systems
To be determined To be determined To be determined
Hardware Dominated
Systems
To be determined To be determined To be determined
Systems Engineering
Management
To be determined To be determined To be determined

Table 3. Framework for Systems Engineering Design Patterns

The popularity of software design patterns mushroomed in the mid 1980s. Counterpart patterns for systems engineering domains have yet to be worked out.

Classification (and Examples) of Patterns

  1. Behavioral Design Patterns. Patterns that capture and enable improvements to system behavior.

    Mediator Pattern

    The mediator pattern defines an object that encapsulates how a set of objects interact. The mediator pattern promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interactions independently.

    Observer Pattern

    Define a one-to-many dependency between objects so that when one object changes state, all its dependents will be notified and updated automatically.

  2. Structural Design Patterns. Patterns that capture and simplify system structures.

    Composite Pattern

    The composite pattern composes objects into tree structures to represent part-whole hierarchies. The composite pattern lets clients treat individual objects and compositions of objects uniformly.

    [ Facade Pattern ] Facade Pattern

    The facade pattern provides a unified set of interfaces in a subsystem. By providing a higher-level interface, the facade makes the subsystem easier to use.

  3. Creational Design Patterns Patterns that enable product creation and evolution.

    Abstract Factory Pattern.

    The abstract factory pattern provides an interface for creating families of related or dependent objects without specifying concrete classes. (Used a lot in Java!).

    Builder Pattern.

    The builder pattern separates the construction of a complex object from its representation so that the same construction project can create a variety of representations.

  4. System Design Test Patterns Patterns for testing the logical and physical system design.

    Example Test Patterns. See details below.

For more information, see the Gang of Four : Design Patterns , and the references at the bottom of this tutorial.

Describing Design Patterns

For an engineering design to be reusable, we need to record the decisions, expert knowledge, design alternatives and trade-offs that lead to the final form. Together, these components of information can help explain how and why a particular solution procedure is suitable for a certain task. These requirements also suggest the need for a format (or template) that allows design patterns to be described in a consistent way.

The key to maximizing reuse in engineering lies in anticipating new requirements and changes to requirements, and designing a system that can evolve accordingly. A design that doesn't take change into account is likely to encounter expensive overhauls at one point or another in its functional lifetime. Design patterns mitigate this problem by ensuring that a system can change in specific ways. Each design pattern will be able to vary independently of other patterns (i.e., they will be weakly coupled).

Example 1. Design patterns can be represented in a textual format. Consider the following class dictionary for describing various types of bicycles:

     Bicycle =  Color ";"  List( Part ) .
     PartList ~ { Part "," } .
     Part : Piece1 | Piece2 | Piece3 | Piece4 | Piece5 | Piece6 .
     Piece1 = "tire"
     Piece2 = "handle-bars"
     Piece3 = "single-frame"
     Piece4 = "double-frame"
     Piece5 = "horn"
     Piece6 = "seat"
     Color : GreenColor | BlueColor .
     GreenColor = "green" .
     BlueColor  = "blue" .

Any combination of these part names can now be input to this class dictionary to create a Bicycle Object. For example, the input sentence:

     blue; seat, frame, horn, tire, tire, handle-bars

describes a blue single seat bike. A green 2 seater bike can also be created:

     green; seat, seat, frame, horn, horn, tire, tire, tire,
     handle-bars, handle-bars

In software implementations of design patterns, the class dictionary is independent of the mechanism that creates the object. The class dictionary can change over time without affecting the process by which Bicycle objects are created. The method for the design pattern builder satisfies the requirements:

  1. The algorithm for creating a complex object must be independent of the parts that make up the object and how they are assembled
  2. The construction process must allow different representations for the object that is constructed \end{description}

Example 2. Design patterns can be represented in a graphical format. See, for example, the Gang of Four : Design Patterns represented in UML.


Creating the Physical Design

The physical design shows how the system will be implemented, including tentative choices of hardware and software technology.

[System Test]

Figure 14. Procedure for Creating and Evaluating the Physical Design

Procedure. Allocate logical components to architecture framework. Tasks are as follows:

Note. Insert material from Schultz et al.....

Hardware/Software Co-Design

Hardware/software co-design attempts to integrate hardware and software design techniques into a single framework. Its purpose is to give a homogeneous approach to the design of embedded systems, aiming to reduce the development time and optimize the software/hardware trade-off.

To be useful, co-design environments must support the entire development process. That is, from the specification of requirements through to the implementation of modules that define the system and corresponding communication interfaces. A key challenge is providing developers with the tools to work at a high level of abstraction -- this allows them to concentrate on "what is to be done" without having to simultaneously worry about details of implementation.

[System HW/SW Co-Design]

Figure 15. Process for Design of Embedded Systems

Co-design methodologies divide the design process into the following subproblems:

  1. Specification

    Our goal here is to use formal specification languages that can represent interactions of a system with its surrounding environment, and can support "what is to be done" without having to worry about if the final implementation will be in hardware or software.

  2. Verification/Validation and/or Simulation

    Validation means that we verify the "as described" behavior corresponds to what we want to specify. Verification through simulation can be carried out by using so-called test patterns (i.e., a test suite) as inputs to the system, and verifying that the outputs are as required. The shortcoming of this approach is that it allows only partial verification of the system behavior. Indeed correctness is only assured for the test cases covered.

    For systems that are dominated by logic and communications, the mathematical basis of formal languages permits verification that the system has some key safety properties (e.g., freedom from deadlock).

  3. Clustering/Mapping of Tasks onto Target Architectures

    Here we are concerned with decomposition of system architecture into subsystems/tasks, and assignment and partitioning of tasks to either hardware or software.

Partitioning is composed of two steps: clustering and mapping.

[System Mappings]

Figure 16. Role of Mappings in System-Level Design

In order to keep the overall system complexity in check, clustering reduces the number of tasks below a fixed threshold. This, in turn, minimizes coupling between tasks.

Scheduling

A scheduler is the component of the system that manages activation and synchronization of various modules, whether they are hardware or software. The presence of software and hardware components imposes the necessity for a scheduler responsible for:

  1. It must synchronize all the modules of the system.
  2. It must serialize software modules that have to share a single microprocessor.

The scheduler must be simple, reliable and use minimal resources (processor, memory, etc). Typically, the scheduler consists of hardware and software ports.

Technology Selection and Trade-Off Analysis

The problem of technology selection is multi-faceted (Schultz, 2000):

  1. Superiority

    This metric captures the ability of a technology to provide significant improvements in terms of performance or cost. Over time, each technology will reach a plateau in terms of satisfaction (i.e., fulfillment of market- and technology-based requirements) and satisfaction-to-cost ratio, and will eventually be replaced by a new technology.

  2. Robustness

    Even if a technology is superior, it will be a market failure if it cannot operate in a robust manner.

  3. Maturity

    The metrics of "maturity" and "robustness" are closely aligned. However, the former takes into account any technical factors that might threaten the schedule of the product development.

  4. Flexibility

    This metric is a direct outcome of robust technologies. Once a technology is robust and has proven its applicability in its initial product program and application, its scope of application can be extended to a variety of product programs.

Design alternatives can be ranked by simply constructing a matrix of design concepts and technology selection criteria. Since some of these criteria are subjective, several iterations of elimination may be needed to reach consensus in a team design.

Technologies that do not fair well with respect to these metrics will be eventually removed from consideration in technology selection procedures. For a more complete discussion, see pg's 204-205 of Shultz et al., 2000.

Systems Integration and Test

Engineering systems are built with components that must inter-operate. Several kinds of tests are needed to establish minimal interoperability: (1) tests of individual components; (2) tests of subsystems assembled from small numbers of components; (3) tests of subsystem and component interactions. Working through these three layers of evaluation requires careful planning:

  1. What components need to be tested?
  2. What sequence should the component interfaces be exercised?
  3. What techniques should be used to exercise each interface?

Binder (see Chapter 13 of Binder, 2000) points out that integration testing is needed because most interoperability faults are not revealed by testing a component in isolation. For tests to be planned, we need information on the scope of each component (i.e., how far do the effect of a component's state reach throughout the system) and dependencies among components. Dependencies are necessary to implement testing collaborations and achieve separation of concerns (which, of course, simplifies the testing of a system).


References and Web Resources

  1. Binder R.V., Testing Object-Oriented Systems: Models, Patterns and Tools , Addison-Wesley, 2000.
  2. Dym C., "Engineering Design: A Synthesis of Views," Cambridge University Press, 1984.
  3. O'Sullivan B., "Constraint-Aided Conceptual Design," Professional Engineering Publishing, London, 2002.
  4. Schultz A.P., Clausing D.P., Fricke E., Negele H., "Development and Integration of Winning Technologies as a key to Competitive Advantage," Systems Engineering, Vol. 3, No. 4., 2000.
  5. Whitney D.E., "Why Mechanical Design Cannot be like VLSI Design," Research in Engineering Design, Vol. 8, 1996, pp. 125-138.

Developed in February 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin, University of Maryland