Strategies of Systems Engineering Development

Emerging strategies of systems development are driven by the need to design systems that have ever-increasing complexity and performance, yet, are economical and adaptable to a wide range of changing external conditions. This tutorial is divided into three sections:

  1. Established Strategies of System Development
  2. Limitations of Present-Day Approaches to System Developent
  3. Emerging Strategies of System Development


ESTABLISHED STRATEGIES OF SYSTEM DEVELOPMENT

Systems Analysis and Systems Design

Systems engineering development is part systems analysis and part systems design.

[System Modeling]

Figure 5. Schematic of Systems Analysis and Design

For situations where the transformation from system inputs to system outputs is of importance (i.e., the system is a process), analysis can be viewed as the act of improving our understanding of the system inputs, outputs, and transformations. Design can be viewed as the search for a suitable function that will transform the inputs to suitable outputs.

Design Synthesis

Synthesis of engineering systems is a process whereby provisional and plausible concepts are developed to the point where traditional engineering and design can begin. Synthesis is particularly important for systems that are quite unlike their predecessors. Instead of extrapolating established designs and technologies, engineers need to return to first principles, rethink established ideas, and identify potential problems (e.g., incompatible interfaces) downstream in the development. The required skills are creativity, common sense, and an ability to apply heuristics to new situations.

System synthesis is inherently a multi-step process, with each step contributing an additional level of information needed for the next level of synthesis (i.e., requirements flowdown). Of course, synthesis of the refined engineering system must satisfy the current level of behavior as well as behavioral descriptions generated by previous steps of synthesis.

Systems Design: A Stepwise Refinement of Models Connected by Mappings

During the past 20 years, design research has focused on finding ways of transforming design of engineering systems from ``an art'' into a pragmatic discipline of ``art and science,'' with well established representations and procedures for modeling, generating design alternatives, analysis, explaining behavior, and evaluating performance of a design.

[ System Design Process1]

Figure 1. Stepwise Refinement of Models Connected by Mappings

With the combination of ``art and science'' in mind, Figure 1 is a high-level simplified view of the design process as a stepwise refinement of models connected by mappings. The sequence begins with a model of initial design requirements and evolves through a series of re-designs into a detailed design, which satisfies the system constraints and maximizes the system effectiveness measures (e.g., behavior; cost; quality; time-to-market). The pathway of potential solutions and partially complete designs is guided by goal-directed searching strategies, and is shown in Figure 7.

Role of Simulation and Optimization

The large circles in Figure 1 show that simulation and optimization can be applied to each model space. While simulation is the process of predicting the performance of a potential design, optimization identifies the potential designs for a specified set of requirements. Optimization can take many forms, including selection of alternatives from a components catalog, and adjusting dimensions of an established form.

Mappings

The output from each cycle of simulation and optimization is mapped onto a new less abstract modeling schema, with the design iterates continuing until the utility of making another iteration is less than the utility of mapping to another level of abstraction -- this is where the design has converged to a fixed point in design space.

Good and Bad Design

A good design leaves sufficient options available in the final stages so that corrections and improvements can be made at that point. A poor design can leave the designer "painted into a corner" such that the final stages become more and more difficult, even impossible to accomplish.

Hierarchical Organization: Top-down/Breadth First and Bottom-up Development

The most difficult problem that systems designers face is that of selecting a hierarchical organization for their system. This organization defines the way in which the various team members think about the system.

A clean hierarchical organization makes all phases of design easier. If each level of the hierarchy has obvious functionality and aggregates only those components that apply to that hierarchical level, then the engineering system is easier to understand. For example, with a good hierarchy, simulation can be done effectively by completely testing each level of the hierarchy starting at the bottom.

Unfortunately, there is no way to describe precisely how to choose a good hierarchical organization. The proper planning of an engineering system is as much an art as the design of the actual components. For this reason, the techniques described here are only guidelines; they should be followed not blindly, but rather with an understanding of the particular design task at hand.

Goal-Directed Search Strategies

Goal-directed search strategies can take several forms. Sometimes a designer will start with a goal and work towards the specification of details for a design object, and in other situations, a designer will begin with a set of well understood objects, and look for ways to connect the objects into a systems that meets the design goals.

[System Reuse]

Figure 2. Elements of Top-down/Breadth First and Bottom-up Development

Generally speaking, the architecture specification process should follow a top-down breadth-first scheme.

  1. Top-Down

    Top-down means the process begins with the entire architecture contained within a black box with connections to external entities (e.g., other systems; the environment). Then, within that context the architecture is divided successively (or decomposed) into its major sub-systems. Individual sub-systems are then decomposed into components.

    In the top-down style of design, each iteration of development generates more detail. Volumes of data/information increase geometrically with each new layer of decomposition.

  2. Breadth-First

    Breadth-first means that the decomposition should be performed uniformly across the architecture as the depth increases -- there should not be tunnels of significantly deeper decomposition in any particular area of the architecture.

  3. Bottom-Up

    Bottom-up design involves synthesis of previously developed product and process modules. The benefits of product modularity include: economy of scale, increased feasibility of product/component change, increased product variety, reduced time to market (i.e., product lead time), decoupling of risks, and easier product diagnosis, maintenance, repair and disposal. Potential costs of modularity include redundant physical architecture and systems containing features not needed.

Top-Down versus Bottom-Up

In top-down development a system is designed with successively more detail. Conversely, in bottom-up development, a system is viewed with successively less detail. The choice of direction depends on the nature of the task, and in real design, the two techniques are almost always mixed. Moreover, as shown above, the distinction is further clouded by the fact that the hierarchical organization may be created with one method (top-down) and then actually implemented in the opposite direction.

Incremental Nature of System Development

The purpose of Figure 3 is to show that the systems lifecycle is often cyclical in nature.

[ System Cycle ]

Figure 3. High-Level View of the Systems Life Cycle

The stages of systems design and implementation are often followed by periods of maintenance (expensive!) and planning for technical upgrades and/or repair (e.g., Window95, Windows 98, Windows 2000).

Routine Development versus New Development

Systems development is said to be routine when the underlying procedures and technology are well tested and familiar. Since few surprises are likely to occur (and perhaps little new will be learned), problem solving procedures can include best practices, expert opinion, rules of thumb and formal problem solving procedures. It may even be possible to work through steps 1 through 6 without iteration. In contrast, the development of a new system tends to be a much more challenging problem because less information is known about the system during the early stages of development. Challenges include the need for synthesis, learning, assessment, and integration of new technologies and heterogeneous information sources (i.e., hardware and software elements, human factors, system requirements, and design specifications).

[Routine/Innovative Development]

Figure 4. Pathway of Development for Innovative and Routine Design

The adjacent figure shows that innovative designs are often prototyped and then implemented in one or two full-scale systems before becoming routine. Routine design involves the solution of similar problems that are familiar. We would like to capture, organize, and store the knowledge for routine design, and share this information throughout the engineering community. The key features of each problem type are:

Nature of Design Problem
Key Features
Innovative
  • Tend to involve the conceptualization of a new product.
  • The main focus of designers is to push technology, thereby making a quantum increase in performance, or perhaps, a totally new function ...
  • Lack of models of phenomena is sometimes a key impediment to progress ....
Routine
  • Tend to be the detailed design, or reconfiguration, of an existing product.
  • Work has goal of incremental increases in performance.
  • Impediments to progress include lack of approximate models, knowledge in peoples heads (i.e., and not in a computer), and lack of computer integration.

Table 1. Characteristics of Innovative and Routine Design

For both innovative and routine designs, the development objective is a system that is easy to maintain, testable (does it do what it's supposed to), contains reusable components, and above-all, improves the productivity of its users. Like the concepts of software reuse, the reuse of design knowledge can take many forms (e.g., previous architectures, published processes, scientific theories, empirical observations, design standards, and so forth). In some cases the sharing of information will be company-wide, and in other cases, engineering community wide.


LIMITATIONS OF PRESENT-DAY APPROACHES TO SYSTEM DEVELOPMENT

Established approaches to system development are limited in the following ways:

  1. Inability to Explore and Evaluate the Complete Design Space

    The space of design solutions may be "very large" in the sense that many potential solutions are likely to exist, and "complex" in the sense that there may be many cause-and-effect relations among components of the design space. Together the attributes of "large and complex" will make a complete exploration of the design space intractable, thereby leaving potentially good design concepts unexplored.

    [ System Design Process2]

    Figure 5. Generation and Evaluation of Design Alternatives

    At the lowest level of abstraction in Figure 5 a leaf may be pruned for a failed design. At higher levels of abstraction, entire sub-trees may be pruned because a design concept is deemed unsuitable. In either case, decision making narrows the domain of acceptable design solutions. Backtracking is required because design information is often incomplete, and incorrect decisions are all too probable.

  2. Premature Commitment to Technologies

    Present-day strategies for systems 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. For design problems that are innovative, making a commitment to a technology may eliminate good design options from further consideration. Moreover, longevity of the final design may also be limited because it is too strongly tied to a specific technology.

    We believe that the effects of these shortcomings can be mitigated by following the principles of "maximum-entropy and minimum commitment."

    Principles of Maximum Entropy and Minimum Commitment

    Given that we choose to view systems enginseering and the evolution of data and information punctuated by decision making, then we also need to acknowledge that this process will evolve under conditions of incomplete information and uncertainty. How should decision making under these circumstances be handled?

    A general framework for decision making in the presence of uncertainties eminates from concepts of "entropy" and probability distributions that occur when we maximise entropy. More specifically, according to the maximum-entropy principle (see, Kapur, 1989), given some partial information about a random variable, scalar, or vector, we should choose that probability distribution for it which is consistent with the given information, but otherwise has maximum uncertainty associated with it. Put another way, first we find the family of probability distributions that are consistent with the given information, and then, from this family we select the distribution whose uncertainty (or entropy) has the maximum value.

    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. Limited Flexibility in Design

    By developing procedures and tools that will allow systems engineers to synthesize and assess the viability of design alternatives at a high-level of abstraction, the hope is an extension in sections of the product lifecycle during which designs can be "easily changed."

    [Benefits in Ease of Change]

    Figure 6. Desired Goal for Improved Design Flexibility

    If this can be accomplished, engineers will be able to work with problem solutions at a high-level of abstraction, and search the space of potential design solutions in a way that is very difficult to accomplish today.

  4. Unified Model of "System Representation and Computation" unavailable

    Wouldn't it be great if we could use a single general-purpose information representation to describe all aspects of system behavior and structure? Unfortunately, such a model does not exist (well, not today, anyway). Hence, complete descriptions of engineering systems will employ multiple information abstractions. For example:

    Abstractions will also be discipline specific. This approach to system development is good in the sense that it supports multi-disciplinary team efforts. At the same time, it presents challenges -- how, for example, do we maintain consistency of system viewpoints among disciplines? This problem can be solved in part through the use of databases, and system versioning techniques.

  5. "Design for Reuse" not explicitly built into the Design Process

    In the early stages of system development, most concepts are represented in an abstract way. Reuse of design knowledge, technologies and libraries of preferred subsystems and parts in new projects not only helps to minimize the use of non-standard content in new designs, but it also decreases project complexity and improves project economy.

    From a technical perspective, "design for reuse" is promoted through two features of design -- modularity and configuability. A module is a physical element which has well-defined functionality/behavior, and clear and explicitly defined interfaces. Modularity in system design relates to the use of system modules in structuring a system. Configuability in system design relates to the ability of system modules/components to be easily configured to satisfy requirements. Together, implementations of modularity and configuability provide a practical means for managing complexity in system design.

    Design resuse is most effective in reducing development time and and cost when the components and subsystems to be shared are close to the final implementation. There is, of course, a cost to pay for this benefit since it is not alway desirable to share designs at this level. As the design specification becomes progressively more detailed, nominal variations in specification can result in different (albeit almost the same) implementations. If moving to a higher level of design abstraction eliminates these design differences, then the higher level of abstraction can be shared, with perhaps only a minimal amount of work needed to customize the design for the final implementation.

    With this framework of development in mind, our long-term research and development goal is to create libraries of hardware and software components and subsystems that can be easily shared and used in new designs. Since the reuse of design abstractions varies with the fidelity of design description, it is important to have multiple levels of functionality supported in such a library. For example:

    It is important to start the design process at a high level of abstraction that can be implemented in a wide variety of ways. In this framework, the design and implementation process corresponds to a sequence of steps that remove choice from the formal model (i.e., the abstract representation of the design should contain all of the correct implementations in the sense that behavior of the implementation should be consistent with the abstract model behavior).


EMERGING STRATEGIES OF DEVELOPMENT

In order for the complexity of system-level designs to remain manageable, by necessity, approaches to system development need to be very strategic and disciplined in the way problems are setup and solved. Emerging strategies of development include:

  1. Orthogonalization of Design Concerns
  2. Function-Architecture Co-Design
  3. Provision for Design Formalization and Early Checking of Design Errors
  4. Provision for Multidisciplinary Design Rule Checking
  5. Reuse at All levels of Abstraction

Strategy 1: Orthoganalization of Design Concerns

Modern-day system designs are undergoing a series of radical transformations to meet performance, quality, safety, cost and time-to-market constraints. An essential component of the new system design paradigm is the orthogonalization of concerns, i.e., the separation of the various aspects of design to allow more effective exploration of alternative solutions . For fast paced industries (e.g., electronics) to remain economically and technically competitive in the face of rapid increasing technical complexity, new methods are needed for the for selecting families of software and hardware architectures that allow a substantial design re-use. These paradigms for system designs are likely to become the pillars of future tools and flows (A. Sangiovanni-Vincentelli). (see, for example, the working notes on platform-based design ).

Strategy 2: Function-Architecture Co-Design

Function-Architecture Co-Design is a system level methodology that promotes the description of systems in two orthogonal ways.

  1. The function that the system is intended to provide.
  2. Candidate architectures which have the potential of realizing the system functionality. Architectural descriptions include choices of the main subsystem blocks.

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 7. Mapping Models of System Behavior onto System Structure Alternatives

At this point, all of the required hardware-software, hardware-hardware and software-software partitioning is carried out. Both functional processing and communications interfaces are explicitly mapped to the system's architectural resources.

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.)

Strategy 3: 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.

Present-day system development processes pass through four stages: (1) planning and analysis, (2) system architecting, (3) system design, and (4) build and test. See the left-hand side of the adjacent figure.

[Reuse Maturity's]

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

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. In addition to appropriate use of simulation and optimization procedures, this will require use of specialized conceptual devices for dealing with correctness in the face of complexity, including:

Formal models with precise and unambiguous semantics are an essential part of formal verification -- indeed, without it, the very meaning of verification becomes fuzzy and problematic (Sangiovanni-Vicentelli et al., 1996).

Strategy 4: Provision for Multidisciplinary Design-Rule Checking

Example. The adjacent diagram shown multidisciplinary standards processing that might occur in the system-level design of a surface transportation system that incorporates a geographical information system (GIS).

[System Testing]

Figure 9. Pathways of Development with Multidisciplinary Standards Processing

Traditional approaches to design code checking embed the relevant regulations inside the design environment or encode technologies into files that are read and executed by rule-checking programs (e.g., the Magic incremental design-rule checker).

For engineering systems of the size and complexity envisioned in the near future, designs will need to satisfy standards and regulations from multiple disciplines. Since it is unlikely that designers will be intimately familiar with the details and potential interactions of regulations from all three domains, there is a strong need for future design environments to provide sophisticated support for the representation, execution and interpretation of codes, regulations and standards throughout the system development lifecycle These concepts are illustrated in the stack of standards shown along the right-hand side of the adjacent figure.

The principles that we believe will drive this development are as follows.

  1. As shown in the adjacent figure, there needs to be a clean separation of the design environment from the suite of programs that checks the conformance of a design to multiple design standards.

  2. Because design standards evolve over time, the standard processing program that models, executes and interprets multiple standards should be decoupled from the standards themselves.

Before this can happen, considerable research is needed to develop formal languages that encompass the wide variety of representations techniques and knowledge found in standards. Ontologies that will enable application interoperability by resolving semantic clashes between application domains and standards/design codes are currently in development.

Strategy 5: Ruse at All Levels of Abstraction

State-of-the-art systems engineering development processes keep the complexity of system developments in check, and reliable, by following a layered approach to problem solving (i.e., high-level system design is followed by lower-level subsystem design, followed by sub-system build and test procedures, and finally, system-level build and test).

Future design processes and methodologies will need to allow for system development and decision making at a high level of abstraction (where there design decisions are easy to change and space of potential design solutions is easy to explore), and exploit reuse of work (i.e., products and processes) across multiple levels of abstraction.

[System Abstraction]

Figure 10. Layers of Abstraction in Reuse

Reuse at the lowest level of problem abstraction is easiest to achieve since of the data and information details have been prescribed. Reuse becomes progressively more difficult to achieve as one moves toward the front of the development lifecycle -- but, its worth the effort because lifecycle benefits of reuse become significantly more important.

[Reuse Maturity]

Figure 11. Benefits of Reuse Maturity

Points to note are as follows:

  1. In the software world, informal and code reuse leads to reductions in code development effort.
  2. Reuse of complete modules can allow for a compressed development schedule, which in turn, leads to economic benefits through a faster time-to-market.
  3. Reuse of system architectures leads to improved flexibility in exploring the space of potential design solutions.

Remark. Researchers have found that less than half of the typical system can be built from reusable software components, and that the only way to obtain more significant gains in productivity is to raise the level of abstraction in the problem solving process (Biggerstaff, 1989). Generally speaking, systems analysis products (e.g., preliminary architecture alternatives) are more abstract than system designs, which in turn are more abstract that detailed designs (having all of the technology details filled in),

Since abstract artifacts have less detail and less reliance on technology and other implementation constraints, the benefits of reuse can be obtained earlier in a project, where they are likely to have the greatest impact. The challenge in realizing the benefits of abstract artifacts is that they also contain less detail, a trend that acts against opportunity for reuse.


COLLECTIVE BENEFITS

Collectively, these aspects of system design and development will enable:

  1. Design Automation for High-level Synthesis of Systems

    As the complexity of system development increases, so will the need for design automation on higher levels of abstraction where functionality is easier to understand and trade-off is more influential (Lin, 1997).

    To facilitate real advances in design verification and productivity, designs should be entered into a formal framework (possibly supported by tools) as early as possible in the design process. Formalization of designs at the system level (with corresponding higher levels of abstraction) assures shorter design cycles, and allows for more exploration of different design alternatives because alternatives can be generated and evaluated more quickly.

  2. Reuse of Designs, Architectures and Business Processes through Object-Relational Database Storage.

    The economic benefits of increased reuse include reduced development time, improved product quality (because components are well used and well tested) and extended working lifetime. Maintenance costs are reduced because an improvement in one piece of design work will enhance all the projects in which it is used.

    The major objectives of a reuse system are to classify the reusable components, to retrieve them from an existing library, and to modify the retrieved components to satisfy the query.

    [XML Business Model]

    Figure 12. Reuse-Centric Development Method for Systems Engineering

    The adjacent figure shows the role of reuse-centric components in an ongoing business. Points to note are as follows:

    A shared repository of artifacts produced by the busines and systems modeling serves as a reference architecture. The repository will contain standard representations of use cases. Use cases not only provide a compact way of capturing (and organizing) requirements, they also trigger later development steps in analysis, design, implementation and testing.

A medium-term development goal is "design platforms" which can support the synthesis and design of product lines. A key challenge that we face is in identifying "design elements" that are common across the entire product line, and other "modular design elements" which can be easily


References and Web Resources

  1. Dym C., "Engineering Design: A Synthesis of Views," Cambridge University Press, 1984.
  2. Goldstein and Pappart, 1977.
  3. Kapur J.N., "Maximum-Entropy Models in Science and Engineering," John-Wiley and Sons, 1989.
  4. Kim S.H., Designing Intelligence: A Framework for Smart Systems, Oxford University Press, New York, 1990.
  5. Lin, Y.L., "Survey Paper: Recent Development in High-Level Synthesis," ACM Transactions on Design Automation of Electronic Systems, Vol. 2, No. 1., January 1997, pp. 2-21.
  6. O'Sullivan B., "Constraint-Aided Conceptual Design," Professional Engineering Publishing, London, 2002.

Developed in February 2001 by Mark Austin
Copyright © 2001-2002, Mark Austin. All rights reserved. These notes may not be reproduced without expressed written permission of Mark Austin.