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:
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.
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).
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.
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.
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.
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.
Development of the logical architecture:
Supports initial system partitioning trades -- that is, trade studies among objectives that are restricted by constraints introduced via spatial and temporal relationships, and control logic imposed at the logical-level of design.
Facilitates traceability between the system requirements and the physical/allocated design, and down the road, integration of hardware, software and data architectures;
Provides input to detailed lower-level engineering models.
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:
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.
A CD player design must be consistent with the physical and optical standards defining a CD!
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:
Scheduling assigns operations in the behavioral description into control steps. The number of functional units needed within any slice of time (or time step) directly corresponds to the number of operations scheduled into it.
Allocation is the process of assigning requirements/functionality to an answer. In practical terms, this often boils down to the selections of functional modules and components from a component library. The allocation pathway will be most straight forward when each major aspect of system behavior can be handled (independently) by a single module/component in the system architecture. That is:
Tree of functions mapping Architectural in the system behavior -----------------> solution domain. domain.
There may, of course, be several alternative combinations of modules and components that can potentially satisfy the functional requirements.
Binding assigns operations to functional units. Tasks may include:
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.
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 A | Component A | |
Task B | Component B | |
Task C | Component C |
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.
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
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 designs employ partitioning criteria that address critical requirements and promote sound design practices. Common criteria are as follows:
The phrase linguistic modular units refers to the need for a close matching (or correspondence) between the modules of a system and the primitive data types or syntactic units used by languages that describe the system (see pg's 52-53 of Graham).
The principle of information hiding is central to good system design. It states that modules should hide design decisions and internal workings in their construction, and that all communication with the module should be via well-defined specifications for use (see pg's 52-53 of Graham).
Each module should communicate with as few other modules as possible. This strategy simplifies the tracing of messages throughout the system.
The principle of small interfaces states that interfaces should pass as little data as possible (see pg's 52-53 of Graham).
The need for explicit interfaces arises from the need to use objects, modules and subsystems via their specification alone. The details of sub-system implementation should be completely decoupled from the interfaces and communication among interfaces.
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.
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.
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:
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.
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):
Generally speaking, for an improvement in performance to occur a cluster must be implemented in hardware.
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.
The choice of a good cluster has significant impact on the cost of implementation/manufacture in hardware and/or software.
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
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
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.
A use case/component interaction matrix provides:
Refer to flowchart diagram on system and sub-system development ....
System-level engineering analysis can provide insight into levels of performance, cost, and schedule that are likely to be encountered with the proposed system.
In turn, this information can lead to the generate additional requirements that need to be taken into account in lower-level system development. See the adjacent figure.
When you look at across a spectrum of engineering disciplines to see how engineering systems are described, a basic question to ask is:
This issue has been investigated by Whitney (Whitney, 1996) by critically comparing features of VLSI and Mechanical Design. See the following table:
|
|
|
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. |
Points to note are as follows:
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:
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):
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):
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 |
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
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.
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
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.
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.
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:
Example 2. Design patterns can be represented in a graphical format. See, for example, the Gang of Four : Design Patterns represented in UML.
The physical design shows how the system will be implemented, including tentative choices of hardware and software technology.
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.
Figure 15. Process for Design of Embedded Systems
Co-design methodologies divide the design process into the following subproblems:
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.
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).
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.
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:
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):
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.
Even if a technology is superior, it will be a market failure if it cannot operate in a robust manner.
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.
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:
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).
Developed in February 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin, University of Maryland