The most fundamental part of a systems engineering model is the representation that it uses to convey information to the systems engineering team members. A good representation allows the system model to be conveniently stored, accessed, and manipulated. For the team-based development of complex engineering systems, good representations tend be similar to the "mental model" in the end-user's head, and therefore, need to be tailored to produce the best response to the user.

With these observations in mind, the purpose of this tutorial is to describe representations for model-based systems engineering development. The contents are as follows:

1. Basic System Concepts
2. System Engineering View of Modeling
3. Synthesis of Models for System Behavior and System Structure
4. Representations for System Structure
5. Representations for System Behavior
6. Representations for System Processes
7. Representations for System Interfaces and Systems Integration
8. Object-Oriented Formulations and Development
9. Visual Modeling for Functional/Object-Oriented Development
10. Formal Models
11. Pathway from Models to Tools

The first part of this handout contains a general discussion of representation properties that should be found in any system.

Definition of a System

Although there are no hard-and-fast rules for determining exactly what a system is, we are nonetheless motivated to study systems as a means of understanding and dealing with the complex world within which we live.

For our purposes, a system is a collection of components (some of which can be modules and sub-systems) that are interconnected so that the system can perform a function which cannot be performed by the components alone. Systems may consist of products, people and processes.

Elements of a System. To understand and deal with complex systems as a whole, we must impose some structure on it.

Figure 1. A System and its Boundaries

Figure 1 is a schematic of a system, its boundaries, inner components and subsystems, and mechanisms for communication with the surrounding environment (via inputs and outputs). Points to note are as follows:

1. A boundary separates the system from its external environment (e.g., walls in a building; starting and finishing times for a numerical analysis).

2. Inputs are elements that enter the system (e.g., raw materials entering a manufacturing plant).

3. Outputs are the finished products and consequences of being in the system. New cars leaving a car assembly plant is an example of finished products. An example of ``consequence of being'' is the ability of a highway bridge system to carry traffic.

4. System threats are those things that can potentially affect acceptability of the system configuration -- for example, a lack of knowledge, insufficient time to build, lack of finance etc...

System Perspectives

Systems are typically defined (and viewed) from two perspectives:

1. Structural Definition (System Structure)

   An assemblage or combination or elements or parts forming a complex or unitary whole. Systems are defined by their components, attributes, and relationships (Blanchard, 1990):

   • Components

     Components are the operating parts of a system consisting of input, process, and output. Each system component may assume a variety of values to describe a system state.

   • Attributes

     Attributes are the properties of the components in the system. Most often the attributes characterize the system.

   • Relationships

     Relationships are the links between the components and attributes.

   Most systems are assembled from a combination of components and subsystems. An important characteristic of a system is that its purpose is met by the properties of the system as "a whole," and not just by the union of the components.

   We assume that the properties and behavior of each component and subsystem will: (1) Have an effect on the properties and system as a whole, and (2) Depend on the properties and behavior of at least one other component in the set. This definition is recursive and so each possible subset of the system should also have these properties.

   The system structure viewpoint focuses on the internal subsystems and how they are connected. This viewpoint helps us to understand how the system will accomplish its purpose?

   Example 1

   In the early phases of systems engineering development, system structures are characterised by: (1) the components contained within system boundary; (2) the connectivity of components; and (3) the component interfaces.

   Indeed, a wide variety of engineering systems (e.g., plumbing, meteorology) are defined primarily through the notion of connectivity among components. In VLSI design, for example, all electronic components have wires coming out of them to connect to other components through some path. The collection of paths through the system define its topology. Notice that this use of connectivity is not always present in mechanical artifacts such as buildings, which have optional and adaptable connectivity and often contain unrelated components (e.g., furniture).

2. Transformational Definition (System Processes and System Behavior)

   A system is a process that receives one or more system inputs I from an external environment, transforms them with process T , and then releases them as system outputs O to an external environment. This input-output (I/O) relationship can be expressed symbolically as

   T(I) = O or T : I -----> O.

   See Figure 2.

   

   Figure 2. A Transformational System

   Examples of processes include procedures, programs, software tools, machine tools, activities, and decisions. Understanding the behavior of a system as a whole requires a knowledge of the individual parts and their behavior, the interfaces between the parts, the traffic that passes along the interfaces, and the system environment (Kronloff, 1993).

   Engineering systems that have one external input and one output are termed single-input/single-output (SISO). Engineering systems that have multiple external inputs and multiple outputs are termed multi-input/multiple-output (MIMO).

   The system behavior viewpoint focuses on the transformation inputs to outputs. This viewpoint helps us to understand what the system will do? We need to know "what happens and in what order?" What are the corresponding inputs and outputs?

   Example

   The key elements of an organization are its people, the way they relate to one another, and the infrastructure that supports the transformation of inputs to outputs. An organization exists when people interact to perform a function, thereby moving the organization towards a desired goal.

   

   Figure 3. Elements of an Organizational Process

   Figure 3 shows how organizations consume and harness resources, and tranform them into products and services. Internal organizational processes exist for technical management, production, maintenance, and adaption.

Note. Clearly, the structural and behavioral viewpoints of a system are coupled. The details of how a system is assembled from subsystems affects what it can do, and vice versa.

In developing models of system behavior and system structure, key questions to be answered include: (1) How with the system achieve its desired behavior? (2) What physical and logical objects/parts are needed? And what is their purpose? (3) How should the system components be connected?

Strategies for Studying a System

Generally speaking, we study systems in the hope of understanding cause-and-effect relationships appropriate to a desirable type of reasoning. Appropriate concerns include: (1) How should we look at the system? (2) What does this system do? and (3) How does the system work?

Figure 4. Strategies for Studying a System

Figure 4 shows that systems can be studied in a wide variety of ways. One possibility is to simply play with the real system. In most cases, however, this is impractical -- how, for example, does an astronomer play with the planets? -- and we are forced to experiment with models of the real system.

The basic ingredients of a model and its development are as follows (Binder, pg. 112):

As a key element of engineering systems development, modeling helps to close the gap between "what is needed" and "how the system will work." This purpose is achieved through capture, improved understanding, and communication of data and information for the system functionality, measures of effectiveness for business and engineering objectives, and the balancing of multiple concerns via optimization and tradeoff analysis.

Procedure for Creating a Model

Generally speaking, a model is an abstraction of the real world.

Figure 5. Procedure for Creating a Model

Models are created in two steps:

1. Abstraction

   Abstraction means that we concentrate on the essential features of one part/module of the engineering problem, and abstract from details of the engineering system that are not immediately relevant to the current module.

   Abstraction replaces the real world system with a similar but simpler-to-understand model. The model may employ one or more of the following representations -- textual description; visual/graphical description; analytical/mathematical description; discrete numerical approximation. Moreover, to facilitate communication among team members, models often follow conventions defined by standards (e.g., UML).

   It is important to note that the so-called "simpler-to-understand model" need not be perfect in order for it to be useful. For example, Newton's laws are not a perfect representation of our physical universe. Yet, they allow for the formulation of models that can be analyzed and studied during the development of an engineering product.

2. Validation

   A fundamental consideration is validating (or ensuring) that the model represents the real system to a certain degree of accuracy. The closed loop of one-way arrows indicates that several iterations of abstraction and validation may be required. Without validation, results of the modeling may amount to little more than educated guesswork!

Models represent systems through a variety of viewpoints, abstractions, and analytical and visual formalisms (e.g., technical drawings; sequence and collaboration diagrams), and enable accurate and concise communication of ideas and behavior.

Benefits of Modeling

Consider the following comment adapted from Thome's book on principles and practices of computer-based systems engineering (Thome, 1993).

Of course, there is a little more truth to this statement than many engineers would like to admit! Engineers like to create models of engineering systems and procedures for creating engineering systems because, potentially, models offer the following benefits (Turban, 1998):

1. Assistance in Communication

   For systems that are in the process of development, models are the primary enabler of communication among project participants (e.g., stakeholders, developers, customers). For example, a developer might use a model to explain to a stakeholder what the system will do, its form, and expected performance, and then verify that this viewpoint is consistent with the client's objectives.

2. Assistance in Coordination of Activities

   In part, project team members use models of system development to coordinate development activities -- project milestones define what is due, and when? During the maintenance and ``system upgrade'' phases of the project life cycle, the same models can provide perspective through a documented history of development.

3. Ease of Manipulation

   The manipulation of decision variables in a model is much easier that changing the same variables in the real world. Exploration and observation of phenomena that may not be fully understood can lead to improvements in system performance, elimination of redundant steps in manufacturing processes, and assessment of system performance and reliability (also see item 7);

4. Support for Trial-and-Error Experiments

   The cost of making mistakes during trial-and-error experiments is considerably less with models than for the real system;

5. Compression of Development Time

   Years of experience can be simulated in a small fraction of the time;

6. Economics

   Frequently, the cost analyzing a model to derive information is much cheaper than analysis of the real world system. Models can describe the economic feasibility of creating and maintaining systems.

7. Management of Uncertainty and Risk

   Models can be constructed to represent uncertainty and risk in engineering systems, thereby providing a framework for balancing these effects against system performance and economics.

For problem domains that are sufficiently simple, insight into the behavior and structure of a system can be obtained through the use of analytic procedures. Otherwise, modeling can involve experiments (e.g., construction and testing of scaled-experimental models in the laboratory).

Model Ingredients

For the visual modeling of engineering systems, models are needed for the system structure, system behavior, and for the system development process (i.e., life-cycle and process models that divide up the development time-scale into milestones, phases and activities).

Keeping the Complexity of System Models in Check

Whereas an engineer in the recent past could be a ``jack of all trades,'' many engineering systems are now so large and complex that teams of multidisciplinary specialist engineers are need to develop these systems. The standard approach for reducing problem complexity is to partition the system it into smaller more manageable modules, and to define milestones for project deliverables. Where appropriate, concepts of abstraction, modularity, and information hiding should be employed.

1. Modularity

   Modularity means division of a complex task or problem into ensembles of of weakly coupled (independent) modules. Each module should be viewed as an independently managed resource, with access highly restrained. Modularity is motivated by the need for simplicity in design, production without error, and ease of implementation.

2. Decomposition

   System hierarchies view a system as being composed of sub-systems, which in turn are composed of smaller sub-systems. System hierarchies enable a designer to view an entire related aspect of some object without having to deal with the (potentially overwhelming) detail of sub-parts and the generality of super-parts.

   Decomposition is the process of breaking the design into subsystems and components described at a given level of the hierarchy.

   

   Figure 6. Decomposition of System Functionality

   As new layers are added to the decomposition, the modeling detail and data increases (almost) exponentially. Moving downwards in the decomposition hierarchy increases the focus on implementation -- indeed, the main goal of decomposition is to obtain components that can be designed and verified almost independently. Conversely, moving higher in the decomposition hierarchy increases the focus on the satisfaction of design goals. As detail is eliminated from the system description, care needs to be taken that the abstracted system representation has properties and behavior close to the lower-level representations.

   So when should a decomposition cease?

   As a rule of thumb, the bottom of a product hierarchy is reached when all of the objects are physical modules, components, or resources.

   Guidelines for the decomposition of system processes are less clear. It seems sensible that decomposition of processes should occur until a level of detail is reached where processes can be controled in a repeatable manner. It seems equally important not to over decompose processes -- for example, a process hierarchy might be decomposed to the point of where "contractors are required to paint a room." At this point you have to assume that the contractors know what they are doing -- so decomposing the process further, for example, to specify the type of paint and brush is likely to be a bad idea.

3. Information Hiding

   The principle of "information hiding" states that information which is likely to change (e.g., over the life-time of a software package) should be hidden inside a module. The information to be hidden could be: (a) details on the internal products used by the module, (b) strategies for manipulating the information, and (c) algorithms that change because of efficiency, optimization, or accuracy considerations.

   From a user viewpoint, information hiding reduces the likelihood of over-defining processes. Instead, user attention focuses on the system interfaces and how different system components can be connected. A great example is stereo components, and how easily they fit together.

Support for Multiple Viewpoints

For the design and development of reasonably complex systems (e.g., a large three-dimensional system whose behavior evolves over time), support for multiple viewpoints and representations occurs because:

1. Multiple perspectives of a complex system are needed simply to understand it completely.

2. Large systems have stakeholders with multi-disciplinary interests (e.g., engineers; architects; builders; customers).

3. The development process for engineering systems is simplified if discipline-specific views/models of the system can be established (e.g., data models; component models; architectural models; process models).

Each viewpoint contains an abstraction of the system which is important to understanding (or making a decision relevant) a particular aspect of design. Other details are pushed into the background.

Figure 7. Support for Multiple Viewpoints

All of these views should be able to link together to create a single object. In this course we will use visual modeling techniques (i.e., the Unified Modeling Language) to describe the architecture and preliminary performance of system designs, and to enable communication among different viewpoints.

Although different views can sometimes be derived from each other in straightforward ways, they are useful to consider separately because they each cater to a different way of thinking and thus provide a "double check" for the designer.

Note. A fundamental limitation of physical viewpoints is the need to project summaries of the system information/data onto two- and three-dimensional space. Graphical represntations of a system are inherently two-dimensional. Experimental prototypes tend to be three-dimensional. The beauty of computational models is their ability to store and manipulation higher dimensional representations of a system -- for example, the time-dependent behavior of a three-dimensional spatial system.

Example 1. Viewpoints for a VLSI Circuit.

A very large scale integrated (VLSI) circuit can be viewed physically as a collection of polygons on different layers of a chip, structurally as a collection of logic gates, or behaviorally as a set of operational restrictions in a hardware-description language.

For exaple, the adjacent diagram is from Computer Aids in VLSI Design (Rubin, 1994) and shows four views for a transistor: (a) Schematic; (b) MOS circuit, (c) bipolar circuit, and (d) behavior.

Example 2. Technical Viewpoints for House.

The architectural drawings for a building focus on the geometry of rooms, corridors, access ways, and architectural features such as doorways, windows, toilet and washroom facilities. At least three perspectives (plan view; two elevation views) will be needed simply to define the geometry.

In contrast, a planner may be interested in functionality of the building for its occupants. In this viewpoint, topological representations are needed to highlight room adjacenty relationships.

At the trade level, different views include the plumbing plan, perspective sketches showing solar exposure, and even parts lists that describe the house as comprising various quantities of wood, metal, and glass.

Databases: Integration and Linking of Viewpoints

The next aspect systems engineering development that must be represented is views and their relationships. A good view-correspondence system allows these view links to be established uniformly and thoroughly in the database.

Unfortunately, there are no truly good view-correspondence systems today, so their representational needs are ill-defined. What is known is that arbitrary information must be available to do proper correspondence maintenance. In particular, the database must be able to link two designs done in different views and to describe their relationship fully.

Figure 8 is a schematic of specialist and central models. A specialist model allows a project participant to assess an engineering object from his/her point of view. A central model is one that contains the attributes of multiple specialist models.

Figure 8. Central and Specialist of Models

Central model. File storage; object-relational databases.

Specialist model. Drawings; geometric models; finite element models.

This pointer information links the database across hierarchies, showing the same design in different layout styles. If the views are so different as to be unable to associate common cells, then further pointer information must be represented. For example, the link between an algorithm and a layout will have to identify textual equations and their equivalent components. Thus the capability demanded by views is the ability for attributes to contain pointers to any other object in the database.

The aspect of design that makes view correspondence hard to maintain is the fact that designers are constantly rearranging the objects that are linked between views. When this is done, some of the links are temporarily broken. The attributes must be able to track this information so that the design can be checked and reconstructed.

Generation of Domain-Specific Models

Central models should employ a representation that allows specialized models to be automatically assembled by extracting the appropriate attribute information based on a theory.

Figure 9. Automatic Synthesis of Specialist Models

Synthesis procedures should be guided by relevant theory (when it's available). For example, concepts from algebraic geometry might be employed in the extraction of a geometric model from a central model.

Note. By having a central model we can avoid the problem of having to provide n(n-1)/2 transformation programs among n models, and to maintain consistency among them.

Example

We will also describe the system level automation tool for engineers (SLATE). SLATE provides engineers with the capability to construct system models for a variety of viewpoints, and then link the viewpoints via translational mappings. By linking the viewpoints, engineers can conduct trade-off studies and see how a change in one viewpoint might impact other viewpoints/team members.

Meta Models

A meta-model is a precise definition of the constructs and rules needed for creating semantic models. Models are the first level of abstraction from "systems of interest" to the modeler. Meta-models are the second level of abstraction -- the items of interest at this level are the "elements," "rules" and "meaning" of the modeling constructs themselves.

Notions of meta-models, meta-data and meta-meta-models can be found in the Semantic Web (what we hope the web might become in five to ten years from now) and STEP, the standard for the exchange of product data.

Meta-models are important to systems engineers because of their role in systems integration of various disciplines (i.e., so-called integrated meta-models). When meta-models are combined with concepts of abstraction, the result can be a set of guidelines on how modules should be developed for reuse and integration with other modules.

Purposes

Common purposes for meta-models are (see www.meta-model.com):

1. As a schema for data that needs to be exchanged (e.g., exchange ofthis is where much of CASE tool data; the exchange of mechanical design data via STEP etc.) or that needs to be stored (in a repository, for example)

2. As a language that supports a particular methodology or process. For example, the meta-model for UML makes the following diagram types available for describing system structure and system behavior:

   Major Area	View	Diagram
   System Structure	Static View	Class Diagram
   	Use Case View	Use Case Diagram
   	Implementation View	Component Diagram
   	Deployment View	Deployment Diagram
   System Behavior	State Machine View	Statechart Diagram
   	Activity View	Activity Diagram
   	Interaction View	Sequence Diagram
   		Collaboration Diagram
   Model Management	Model Management View	Class Diagram

   Table 2. Classification of UML Diagrams for each Major Area

   UML provides coverage for nearly all aspects of engineering system development, including, representation of system requirements, system structure, and system behavior.

3. As a language to make information on the web (inside and outside of companies) more semantic.

In the traditional engineering disciplines, engineers build models of the products they are making, and less often, the processes that are followed to create these products. The systems engineering view of modeling is considerably broader than its engineering counterpart. In addition to modeling the functional capabilities of a product, the systems engineering view of modeling needs to include project requirements, requirements traceability, and sometimes, a model of the organization and its work practices. Models of the interfaces among these elements are a necessary prerequisite for efficient communication among systems engineering entities.

At a high level of abstraction, we can view the main entities of model-based systems engineering as sketched in Figure 10:

Figure 10. Types of Models in Systems Engineering

Engineering, requirements, and organizational models are abstractions of their real-world counterparts. To be useful, they must be simple enough for tractable calculations, and yet, complicated enough to capture real-world cause-and-effect relationships. The latter are needed for problems in system optimization and trade-off.

Key points to note are as follows:

1. Modeling the Engineering System: Product and Processes

   Engineering models are useful for assessing the performance and technical feasibility of a system, representing interfaces between subsystems, planning the assembly procedures, anticipated maintenance schedules, and so forth.

2. Modeling the Requirements: Product and Processes

   The requirements model helps developers capture, store, and manage project requirements, and trace requirements to/from the design. The requirements model provides a basis for understanding the interaction among design objects/entities, links to automated analysis and generation of documents. It can help developers answer questions like:

   • Is the product being developed what the customer wants?
   • Does the product meet all of the requirements?
   • Is the product under or over designed?

   If the project requirements change (e.g., due to a change in a customer's needs), then the requirements model can help the developers understand how the change in needs propagates to details of the product development. By tracing requirements to a design, a requirements model can help a designer decide how to rationally adjust a design in response to a customers budget/performance needs.

3. Modeling the Organization: Structure and Processes

   Organizations solve problems for their customers over an extended period of time (i.e., several projects).

   Organizational structures can work well in a variety of ways (e.g., military, start-up company, university, commune, factory). An organizational model can help management understand its resources, staff availability, and business processes, thereby creating a pathway to exploring and understanding alternative high-level business strategies. The organization may decide, for example, that rather than search for extroadinary people to do a job, maybe it is better to adjust the organizational structure so that ordinary people can do it.

   Advances in technology, which allow people to me much more mobile that was possible only one or two decades ago, are having a major impact on the types of organizational structure that are possible. For example, as part of organizational restructuring and corporate downsizing, numerous companies are now utilizing so-called "virtual offices" in an effort to increase overall efficiency. These offices are staffed by employees who telecompute, use Internet communications and resources, and share office space for brief periods of time when working at corporate facilities outside the home ~\cite{snizek95}.

Our long-term goal for model-based systems engineering is methodologies that allow for a full description (or model) of system behavior and system structure, which can be executed, observed, and evaluated against prescribed requirements.

Qualitative versus Quantitative Assessment

Figure 11 is a refinement of figure 9, and shows the issues important to the organization, requirement, and engineering sectors.

Figure 11. Models of Organization, Requirements, and Product

The modeling space is presented as a stack of cards, meaning that models of each sector are expected to evolve throughout the project life cycle. Points to note are as follows:

1. Engineering

   Creating models that can respond the complete range of inquiry along lower half of Figure 11 is far from a trivial. Among these sectors, engineers are in the best shape because engineering models tend to assess either the technical performance and economic assessment of the system, or, the logical feasibility of transforming the system in some way (e.g., questions of design and assembly). Later in the system life cycle, procedures for maintenance and retirement are important.

2. Requirements

   Requirements are a little more difficult to model because they come from a variety of sources (e.g., legal issues; technical issues; regulations; physics), are presented in a variety of formats (e.g, textual; graphical; mathematical), and despite all efforts, are sometimes imprecise. Tracing of the project requirements onto the engineering design is represented by the horizontally drawn dashed-arrows connecting the requirements and engineering models.

   Later in this course we will see that requirements traceability is an important part of systems project validation, and that a number of systems engineering tools now support this feature.

3. Organization

   Compared to engineering systems and requirements, the modeling of organizational issues is difficult because a large section of what managers deal with is qualitative in nature. For example, the problem of modeling human resources and how people work does not lend itself to a clean-cut logic formulation. At the same, however, there is little doubt that the nature and efficiency of these resources of great importance to determining the overall quality, reliability and efficiency of system development.

   So what to do? The key observation is to note that there is clearly more than one good way to run an organization. Rather than mandate how an organization should be structured (and hence modeled if one wished to do so), authorities that oversee systems engineering activities simply prescribe what processes an organization should have in place. They then leave the details of implementation up to the organization -- but, of course, the organization must be able to show the required processes are in place.

While all three of these sectors must deal with information that is part qualitative and part quantitative, on balance, engineers from the traditional domains enjoy the benefit of working with problems that lend themselves to quantitative analysis. At various levels of abstraction, the components of an engineering system will fit together or they won't. This mix of heterogeneous information types is important because it has a direct bearing on the best types of model for each sector.

Process, Method and Tool Integration for Design Product Lines

Modern manufacturing organizations (e.g., BMW, Boeing, NASA) are meeting market demands to develop customized products for global consumption, in ever-shortening development times by creating families of products that can be easily tailored to a customer's specific needs.

We define platform-based design as:

• The creation of a stable architecture that can be rapidly extended, customized for a range of applications (instead of a single product), and delivered to customers for quick deployment. Often, these systems will operate with many other systems.

The goal of platform-based design is to facilitate development of future product generations that are extensions of original hardware and software investments, thereby allowing for dramatically reduced time to market, while decreasing development and production costs.

• From a product perspective, product family success is achieved through a set of well-defined design modules and interfaces that can be easily customized to a variety of customer requirements. Reuse is a must.

• From a process perspective, multi-project integration is achieved via a stable basis of processes and tools that support networks of cooperation with project partners and suppliers.

As systems become more complex, the relative cost of verifying and testing behavior will steadily increase unless new approaches are developed. In the electronics arena (the leader of many trends), this trend is prejuiding manufacturers towards components/subsystems that have guaranteed high-volume production (where the test and verification process can be amoritized more economically). Therefore, we would like to identify a common "hardware and software" denominator (which we will refer to as the "platform") that can be shared across multiple applications. Ideally, future evolutions of these applications will occur with only minimal extensions to functionality.

Both reuse and early error detection imply that the design activity must be defined rigourously so that all phases are clearly defined and appropriate checks are made. To be effective, a design methodology that addresses complex systems must start at high levels of abstraction. This requirement is at odds with current design practice where designers are familiar with working at levels of abstraction that are too close to the final implementation (e.g., requirements written in a way that ties the implementation to a particular technology). As a result, sharing design components (i.e., reuse) and early verification of designs before prototypes are built is nearly impossible.

Case Study. Process, Method and Tool Integration at BMW

The systems engineering environment at BMW is moving towards increased use of process modeling and management of development processes (Browning, Fricke and Negele, 2002).

Problem and Challenge

There is a lot of administrative overhead associated with process redundancy. Without process modeling, there is a slim likelihood of process improvement and learning.

To develop a first-class product line, BMW needs first-class processes that are stable and repeatable. Process models and associated measures of effectiveness are important because they enable understanding and learning (i.e., transparency), documentation and reusability, what-if analyses, and process managements, planning and improvement.

Figure 12. Multi-Project Development Processes at BMW (Browning et al, 2002)

Figure 12. shows the interaction of multi-project development processes at BMW (Browning et al, 2002). The goal is to create models of development processes (..not organizations or people), to show how the processes can be integrated, and to understand the process activities at an appropriate level of abstractions.

The goal is to eliminate process redundancy and coordinate related process activities. The complexity of product development processes is at least equal to the complexity of the product itself!

One of the most difficult problems that systems engineers face is synthesis of models for system behavior and system structure. Models for system behavior and system structure define the way in which designer will think about the system -- as we will soon see, models of system behavior lend themselves to a "process model" implementation. Typically, system structures are combinations of hierarchy, network and layers.

A clean organization makes all phases of design easier. For example, when each level of the system structure is assigned well-defined functionality and aggregates only those components that pertain to that hierarchical level, then the system will be easier to understand. Moreover, a good structure will simplify demands on simulation, since simulation activities can be assigned to various levels of detail.

For the high-level synthesis of complex heterogeneous systems, the richness of implementation choices makes the use of a unified model for "a system" almost impossible today. A tractable solution for "system level abstraction" is to view design and its environment as a set of communicating entities/nodes that may or may not be be based on the same model of computation (e.g., mixtures static and dynamic, discrete event, and continuous systems).

The synthesis of models for system behavior and system structure begins with the identification of things, occurences/events, and relationships.

1. Things and Occurrences/Events

   As engineers, we are interested in developing system requirements and creating models of engineering systems that will eventually be built and used. The elements and behavior of these engineering systems are the "things" or objects we care about. They are described (or specified) through the following aspects:

   1. Name of the object;
   2. All the properties of the object that are important for the problem of current interest;
   3. All the tasks, actions, or functions that are to be performed by the object for the problem of current interest;
   4. All the inputs that the object accepts and outputs it generates;
   5. How to connect the object (i.e., its interfaces);

2. Occurrences/Events

   The important characteristics system behavior are identification of system usage, events, and time sequencing of events. An event is an occurrence at a specific time and place. Systems engineers need to plan for and react to the following types of events:

   • External Events

     These are events that occur outside the system boundary. For most systems, external events trigger a set of actions the system must response to.

   • Temporal Events

     These are events that occur as the result of reaching some point in time.

   • State Events

     A state event occurs when something happens inside the system that triggers the need for processing.

   A key challenge for systems engineers is identifying and tracing sequences of events caused by entities external to the system. Indeed, a useful catalyst for establishing system requirements is to ask the question "...what events occur that will affact the system being studied (or developed)?" Later in the design process, additional events are introduced with the creation of logical design alternatives and selection of technologies. Tables of events can be constructed for various aspects of expected system behavior.

3. Relationships

   A relationship is a naturally occuring association among specific things. Because things (or objects) are built from things, we need a way to express (e.g., counting and enumerating) how things relate to each other and how things within the system are connected to the surrounding environment. The notion of interconnection provides a way of showing which parts are connected to each other, and which parts are not. Relevant concepts include:

   Interconnection Description	Appropriate Formulation
   Context description	How objects are connected to the external environment?
   Assembly description	How objects are connected within the system boundary?

   Table 3. Types of Interconnection Relationships in Systems

   Aggregation allows use to consider an object as a unit, ignoring its parts, thereby simplifying our viewpoint of the system.

Figure 13 shows pathway of development from things, events and relationships to the synthesis of models for system behavior and system structure.

Definition

By definition, structure is an arrangement of parts, or constituent particles, in a substance or body (Merriam Webster, 1981). When an engineer describes the structure of a system, the description must contain a list of the parts and how the components are connected.

Viewpoints for Describing System Structure

The structure of nearly all systems can be described using one or more of the following three models: hierarchy structure; network structure; layered structure.

1. Hierarchy Structure

   The components of a system may themselves be systems, and every system may be part of a larger system hierarchy. If two hierarchical levels are involved in a given system, the lower is conveniently called a subsystem}. The bottom of the structural hierarchy is reached when all the parts are basic physical components such as wheels, engine and so forth.

   The definition of a system is not complete without consideration for its position in the hierarchy of systems. The term modularity means decomposition of a system into smaller units. The lowest level of decomposition is known as as "granularity," and it defines the size of the smallest basic unit (or chunk) in the system (Kim, 1990).

   Hierarchical organization is the most important characteristic in the design of any moderately complex object. The major reason for using hierarchical description is to hide the vast amount of detail in a design. By reducing the distracting detail to a single object that is lower in the hierarchy, one can greatly simplify many system development operations.

   The hierarchy viewpoint enables a designer to visualize an entire related aspect of the system without the confusing detail of subparts and without the unrelated and distracted generality of superparts. By reducing the distracting detail to a single object that is lower in the hierarchy, one can greatly simplify many system development operations. For example, simulation, verification, design-rule checking, and layout constraints can all benefit from hierarchical representation, which makes them much more computationally tractable.

   Example 1. Hierarchy for an Automobile

   Consider, for example, an automobile system -- the engine, wheels, axles, and car-frame, are all subsystems of main automobile system.

   

   Figure 14. Examples of System Hierarchies

   For each wheel system, the tire is a subsystem that has its own internal components. Clearly, the designations of system, subsystem, and component are relative, since the system at one level in the hierarchy is the component at another.

   Example 2. Embedded Systems

   By definition, embedded systems are applications that are part of a larger system, and therefore fall into the hierarchy classification. For example, a missile guidance system works in conjunction with sensors, explosives, and other equipment. Embedded systems also include controllers for stand-alone systems, process control, and to run machinery, and to control thermostats, microwaves, refrigerators, TVs, and VCRs to name a few.

2. Network Structure

   A network is a set of modules (or nodes or devices) that are connected by a set of interfaces (or communication channels) that communicate on a peer-to-peer protocol. The modules may be computers, mechanical machines, etc... The interfaces may use a variety of communications media, including copper wires, coaxial cable, optical fiber and satellite links.

   

   Figure 15. Interacting Subsystems in an Aircraft

   Figure 15 shows, for example, the subsystem components (i.e., radar, navigation, external communications, instrument display panel, and engine control system) in a modern aircraft. The subsystem components are connected together so that the functioning engineering system will satisfy the overall system requirements.

3. Layered Structure

   A layered system is one where the hierarchy of system components is clustered into horizontal strata. The granules (or smallest components) of the system communicate through standard interfaces/protocols to levels above and below it own level. The layered architecture eliminates the need to define one-on-one relations among modules in separate strata.

   

   Figure 16. Open Systems Interconnection Model for Computer Communications

   A well known example of a layered system is the International Standards Organization (ISO) Open Systems Interconnection (OSI) Model. See Figure 16. Another example is a computer program that interacts with window development toolkits, a basic window system, the operating system, and other libraries (e.g., math libraries) as needed.

Models of real engineering systems are likely to be a combination of the hierarchy, network, and layered models (e.g., a hierarchy of networks). Moreover, because the various participants in a project will have differing interests, system hierarchies may have multiple tops and variable resolutions of modeling for different views. See Figure ~\ref{figure-models-multiple-views}.

Behavior

By definition, behavior is the way in which a organism, organ, or substance acts, especially in response to a stimulus (Merriam Webster, 1981). Models of system behavior include abstractions of the system to be developed, as well as the environment in which the system will operate .

Abstractions for System Behavior

Abstractions for system behavior are developed through functional decomposition.

The basic abstractions used with behavior are function, ordering of functions, and function inputs and outputs. (System processes are concerned with the the definition and ordering of "activities" rather than functions.)

• Functions

  A function describes an action or activity that take places.

• Inputs and Outputs.

  Formal description of functions are expressed in terms for transformations -- that is, transforming an input into an output. subject to appropriate external mechanisms and controls (see figure below).

  

  Behavior models coordinate a set of what we will call steps. Such a specification requires that at least two questions be answered for each step: When should each step be taken? and When are the inputs to each step determined?

• Ordering of Functions

  By themselves, functions are incapable of describing behavior. Rather, real-world behavior emanates from an ordering of functions, which in turn affects how inputs are transformed into outputs. Abstractions that allow for the ordering of functions include:

  • Sequence -- which functions must precede or succeed others;
  • Concurrency -- which functions can occur simultaneously;
  • Selection -- capturing choices between functions, and;
  • Iteration -- which functions can be repeated as a block.

  These abstractions are captured in a number models. including flowcharts, IDEF0 (roots in Systems Engineering), and design structure matrices.

The implementation of system behavior (engineering process) models occurs together with:

• Data model.

  The purpose of the data model is to analyze the data structures and their relationships independently of the processing that takes place (already accounted for in the process model).

• Rule model.

  Contains a set of assertions that describe what is to be done when a set of conditions evaluates to true (e.g., decision trees and decision tables).

For example, associated with the IDEF0 model (Marca and McGowan, 1987) is a data dictionary, which includes definitions of the activities, listing and description of the inputs, controls, and outputs, and if entered, a set of activator rules of the form "preconditions postconditions" These are the rules that indicate the conditions under which the associated function can be carried out.

Viewpoints for Describing System Behavior

The behavior of nearly all systems can be described using one or more of the following three viewpoints:

1. Control Flow

   Control flow takes each step when another step (or steps) is complete, perhaps taking into account other conditions, but without regard to the availability of inputs. Inputs are determined during the transitions between steps, but are not required to start a step. No restrictions are placed on how inputs are determined.

   When to use Control Flow

   Control flow emphasizes the sequencing of steps by requiring one step to finish before another starts. It de-emphasizes the calculation of inputs by using whatever information happens to be available when a step starts, according to some unrestricted algorithm. This makes control flow more suitable for applications in which the exact sequence of steps is most important, as in business applications.

   Example

   The postal delivery person starts rounds after getting to work, regardless of whether mail needs delivery, because there may be mail to pick up. Control flow is the oldest and most popular form of behavior model, as expressed in the imperative languages (C, Java, and so forth), and was once diagrammed in flow charts.

2. Data Flow

   Data flow takes each step when other steps provide its inputs. Inputs are determined by being passed directly from outputs of other steps.

   When to use Data Flow

   Data flow emphasizes the calculation of inputs by requiring the outputs of one step to be explicitly linked to inputs of another step or steps. It de-emphasizes the sequencing of steps, because the time at which all the inputs to a step arrive is determined by however long the various input steps take to complete. This means some steps may get all their inputs earlier than others in a less restrictive order than control flow. These characteristics make data flow more suitable for applications in which the proper determination of inputs is most important, as in manufacturing applications.

   Example

   In "just-in-time" manufacturing, each assembly step is carried out when the parts arrive from other assemblies. Data flow is the basis of functional languages, such as Lisp when it is used without side effects, and is related to Petri Nets, a behavior model that incorporates queuing features. Data flow is also common in manufacturing, as in the example above [6, 7].

3. State Machines

   Suppose that with the passage of time, a system switches between states as shown in Figure 17.

   

   Figure 17. System State versus Time

   A state machine is an abstraction composed of events (inputs), states, transitions, and actions (outputs):

   • State. An abstraction that summarizes that information concerning past inputs that is needed to determine the behavior of the system on subsequent inputs (Hopcroft 79, pg. 13);

   • Transition. A transition takes a system from one state to another (i.e., this is an allowable two-state sequence). A transition is caused by an event. It may result in an output action. It must specify an acceptable state and a resultant state;

   • Event. An input (or an iterval of time);

   • Action. The result (or output) that follows an event.

   State machine mechanisms have several steps:

   1. The machine begins at an initial state;
   2. The machine waits for an event for an indefinite interval;
   3. The event presents itself to the machine;
   4. If the event is not accepted in the current state, it is ignored;
   5. If the event is accepted in the current state, the designated transition is said to fire. The associated action (if any) is produced and the state designated as the resultant state becomes the current state. The current and resultant states may be identical.
   6. The cycle is repeated from step 2, unless the resultant state is the final state.

   State machines emphasize response to external stimuli by requiring that each step start only when certain events happen in the environment of the system. The process by which events are generated and sequenced for consideration is not part of the state machine model. Events are recognized singly. Transitions fire one at a time. The state machine will only recognize those events defined in the model. The machine can only be in one state at a time. The current state cannot change except by a defined transition.

   State machines are static -- that is, events and permissible states cannot be removed by execution of the machine. Finally, the model is time invariant. For example, the firing of a transition (in the precense of an event) does not cosume any specific amount of time;

   State machines de-emphasize the sequencing of steps by allowing this to be controlled by external events. Similarly, they downplay the calculation of inputs to each step by doing it as part of the steps themselves.

   Mealy and Moore

   The two most prominant versions of state models, Mealy machines and Moore machines, differ in how they deal with model outputs. Briefly, the differences are as follows:

   • Mealy Machine. In a Mealy machine, a transition may have an output action and any output action may be used in more than one transition. No output action may be associated with a state (i.e., state are passive).

   • Moore Machine. In a Moore machine, transitions do not have an output action. Instead, an output action is associated with each state (i.e., states are active). Every output action has at least one corresponding state.

   Mealy and Moore machines are mathematically equivalent (and algorithms have been developed to transform one machine form to the other).

   When to use State Machines

   State machines are ideally suited to applications that operate in response to their environment, as in real-time or embedded applications. The challenge for the designer is to devise a model that correctly represents the behavior of the system under study.

   Example

   In a vending machine, for example, depositing money causes the amount to be displayed to the buyer.

State Transition Diagrams

A state transition diagram is a graphic representation of the real-time (or on-line) behavior of a system. Nodes represent states. Arrows (directed edges) represent transitions. Annotations along the edges represent events and actions. The states of a system are assumed to have the following characteristics:

1. Each state represents the system's potential response to its input over a predefined period of time. A system may remain in the same state for an infinite period, during which the way it responds to inputs will remain the same.

2. Each state represents a unique combination of behaviors within the system. Whenever the system is within a given state, its behavior will always be the same. The state acts as a ``label'' for that set of behaviors.

3. At any given time, a system can only be in one state.

For the description of a system to be complete (i.e. when it is turned on), there must be a state to define its behavior at all points in time. Ensuing changes in the state of a system must be logically instantaneous (when a system is built in practice, this change in states will take a small finite length of time -- these details will be technology dependent).

State transition diagrams date back to the early days of digital logic systems, where the state of a system is determined by the setting of switches such as relays or binary registers within the digital circuit. Each binary switch has two states, an on-state and an off-state, so a circuit of n switches can have 2^n states, each corresponding to a different setting of the switches. The evolution of the digital system is determined by specifying logic that takes as input the value of the state, and the value of the external binary signals that are inputs to the circuit, and produces as output the next values that the switches should take. Think of the way that an automatic traffic light works: here the states are determined by the relays that control the lights and timers, and the external binary inputs are the signals from the sensors under the road, and the signal from the timer that controls the length of the amber light.

This mechanistic view of a state machine is abstracted to the systems setting by substituting the settings of switches with values of object attributes. To be a little more precise, the state of the system at a moment in time is a function of the values of the attributes of the objects that comprise the system. For the state to change, the values of some of the attributes of the systems objects have to change.

Example 1. Hydroelectric Dam

A simple example where a state transition diagram provides a useful model of behavior is the following model for a hydroelectric dam.

Figure 18. State Transition Diagram for a Simple Hydroelectric Dam Model

The dam is in one of three states (which depend on the level of water in the lake):

1. When the water level is low the dam is in the state Drought when no electricity is produced.

2. When the lake level is high the dam is in the state Flood when flood gates are opened to fix the lake level.

3. The third state Normal corresponds to normal operation of the dam, water flows out of the dam to power the turbines, and flows into the dam as rain falls in the catchment watershed.

The operation of the dam is modeled by two functions:

1. Level Rise. Means that water in the lake is being replenished faster than it is used for power generation.

2. Level Fall. Means the opposite.

The evolution of the system is described by the directed graph shown in Figure 18 this directed graph is called a state transition diagram. The nodes on the graph represent the possible states of the system, and the directed paths are the possible transitions from one state to the next. The function that triggers the transition is written beside the path of the one-way arrows.

Notice that for the simplistic model described, the behavior is non-deterministic. When the dam is in the normal state a Level Rise will only trigger a transition to the flood state if the level of the lake is just below flood. However, since this model doesn't capture the level of the lake, or the amount that the lake rises, all we can say is that the transition occurs some of the time.

Example 2. Spacecraft Computer System

Figure 19 is taken from Larson (Larson, 1996), and shows a typical state transition diagram for a spacecraft computer system.

Figure 19. State Transition Diagram for Spacecraft Computer

The boxes in the state diagram show the valid states of the system, and the conditions needed to achieve each state. Off and On are minimal choices for states -- and even if the system is required to be On at all times, an Off should be provided for graceful shutdown in emergency situations. The remaining states relate to what the system needs to do under normal and contingency operating conditions.

The computer system states must be consistent with the design requirements, and space crafts concept of correct operation.

Note. State transition diagrams are in fact basic to the discrete event modeling and simulation techniques taught in ENSE 622, and will be covered from a number of different points of view (e.g., intuition, finite state automata).

Processes

A process is simply a sequence of activities executed by a human or machine, often with the goal of transforming a set of inputs into useful outputs. A complete description of a process includes naming of the steps within the process, and use of models of the system in various textual/graphic abstractions.

Systems engineering processes are concerned with the step-by-step development of complex engineering systems, from identification of user needs through to specification of the detailed step-by-step procedure for creating and integrating the system components and subsystems. Every organizations has processes, but often they are poorly organized (i.e., neither planned nor designed).

Taxonomy of Diagrams for Displaying Information on Processes

1. Activity Diagrams and Flow Charts

   Activity and flow chart diagrams are an intuitive way of representing activities/tasks and their relationships. Activity/flow chart diagrams are most useful when their are only a few relationships between activities -- however, for activities containing many steps and relationships, activity/flowchart diagrams soon become too crowded. The diagram structure can be mapped onto swim lanes, one for each participants involved in the diagram execution.

2. Gantt Charts (Milestone Charts)

   Gantt charts (and milestone charts) are an excellent tool for showing planned schedules, project status and overlapping activities. They downplay the significance of information/data dependencies, especially when these dependencies are more complicated than a simple chain of activities.

3. Design Structure Matrices (DSMs)

   Design structure matrices provide a concise way of describing the relationship of each activity to every other activity. DSMs show the flows of information and feedback among subsystems and modules.

Sequencing of Activities with a Milestone Chart

Schedules are a manafestation of processes. They highlight the activities and milestones necessary to complete the systems engineering objectives. The flow of information and details of the system interfaces are pushed into the background.

Figure 20 is a schematic of a basic milestone chart. It provides top-down guidance on "tasks versus time period," and the major milestones for the project.

Figure 20. Schematic of Milestone Chart

A weakness of milestone charts is their inability to capture the integration of tasks that must occur for the system requirements to be satisfied. This deficiency can be overcome with scheduling techniques that identify

• The input-output of individual tasks,

• The relationships among tasks.

The scheduling technique should be flexible enough to handle tasks in the early stages of project development, where precise times may not be available.

One such approach is PERT-CPM networking, and acronym for Program Evaluation and Review Technique, Critical Path Method.

• PERT

  PERT shows the relationships among combined activities and introduces notions of probability, which together, enables better management decisions.

  The dependent events and activities should be related to the project's milestones.

• CPM

  CPM is analogous to PERT except that emphasis is placed on critical activities which may require the greatest time for completion.

PERT-COST is an extension of PERT and CPM, and deals with not only the issue of task time, but of cost. If a cost network is superimposed on top the activity network, then managers are provided with a tool for constructing trade-off curves of cost versus time of development, for fixed resources.

Work Breakdown Structure

Figure 21 summarizes the project events and activities organized into work packages.

Figure 21. Schematic of Work Packages

Individual work packages can be evaluated from the standpoint of task type, complexity, required completion schedule, and cost. Finally, the work packages are integrated with the project's objectives, and the available resources of an organization.

Design Structure Matrices

A design structure matrix (DSM) is a compact, matrix representation of a system or project. The matrix contains a list of all constituent subsystems/activities and the corresponding information exchange and dependency patterns (i.e., what information pieces (parameters) are required to start a certain activity and where does the information generated by the activity feed into).

1. Systems Analysis

   As a systems analysis tool, DSMs provide a compact and clear representation of a complex system and a capture method for the interactions, interdependencies, interfaces between system elements (i.e. sub-systems and modules).

2. Project Management

   As a project management tools, DSMs provide a project representation that allows for feedback and cyclic task dependencies. This is extremely important since most engineering applications exhibit such a cyclic property. This DSM project representation results in an improved and more realistic execution schedule for the corresponding design activities.

Benefits of Design Structure Matrices

Briefly, binary matrices are a useful tool for systems modeling because they can represent the presence or absence of a relationship between pairs of elements of a system.

1. If the system is a project represented by a set of tasks to be performed, then off-diagonal marks in a single row of the DSM represent all of the tasks whose output is required to perform the task corresponding to that row.

2. Similarly, reading down a specific column reveals which task receives information from the task corresponding to that column.

Marks below the diagonal represent forward information transfer to later (i.e. downstream) tasks. This kind of mark is called forward mark or forward information link. Marks above the diagonal depict information fed back to earlier listed tasks (i.e. feedback mark) and indicate that an upstream task is dependent on a downstream task.

Example

The left-hand side of the adjacent figure is a directed graph showing the interactions of information among seven design tasks. A task could be a decision. The nodes, labeled A through G, represent individual tasks in the design realization. We use arcs with one-way arrows to indicate a one-way flow of information, and arcs with two-way arrows for bi-directional flows of information between tasks. So, for example, task A requires information from tasks C and D. Task D does not require information from A, however.

Because the geometric layout of node locations in the digraph is somewhat arbitrary, determining sequences of information flow can be difficult, especially when problems that contain more than a handful of tasks.

We would like to know:

• What decisions provide information to other decisions in the product realization?
• How can the sequence of design activities be rearranged so that decisions can be made sequentially, and without iteration?

One solution to this problem is shown on the right-hand side of the figure. A design structure matrix is a two-dimensional representation of task sequencing, and information flows among design tasks. The time sequence of tasks is represented by increasing column and row numbers -- in this case, task A is first, followed by task B, then C, D, E, F and finally G. The X's in each column show the nodes/task to which information is sent, and the X's in each row, the information from which nodes will be received.

For the sequence of design activities is to proceed in an efficient manner, we require that flows of information only be sent to tasks that are downstream in the task sequence -- for the design structure matrix, this situation corresponds to X's in the lower left-hand side of the matrix. When sequential flows of information are not possible (i.e. X's in the upper right-hand section of the structure matrix), time consuming loops of design iteration must be computed. In Figure 22, for example, task A requires input from task D, even though the latter is yet to be completed.

Design Partitioning and Tearing. Once a design has been mapped to a design structure matrix, analysis can proceed in two directions (Gebala, 1991):

1. Partitioning

   The goal of partitioning is to re-sequence the design tasks so that availability of information is maximized at each stage of the design process.

2. Tearing.

   The goal of tearing is to re-sequence within the groups (or blocks) of coupled tasks to find an initial ordering to start the iteration.

Example

The left- and right-hand sides of the next figure show the design structure matrix before and after task re-sequencing.

In moving from the initial to final ordering of design tasks, we note:

1. Task F provides information to other nodes, and doesn't depend on information from any other nodes. Hence, it can be moved to the beginning of the task sequence.

2. Task E does not provide information to any other tasks -- hence, it can be moved to the end of the task sequence.

3. Task A depends on information of task C, and vice-versa. Since A and C, together, are not part of any other loop, and C feeds information to E, tasks A and C are moved to position second-last in the task sequence.

4. Notice that tasks B, D, and G form a loop -- task B depends on task G, which depends on task D, which depends on task B. This loop includes all of the unscheduled tasks.

The rescheduled sequence of tasks is shown on the right-hand side of the figure.

Tearing

Now that the identification of loops is complete, tearing algorithms can be used to identify an initial condition for beginning each loop. The two most common approaches are shunt diagrams, and heuristics that attempt to identify the nodes within a loop that have a minimal number of inputs from external sources -- for more details, see the paper of Gebala and Eppinger (Gebela et al., 1991).

Remarks

1. The scheduling scenario described in these figures is simplified in several respects. First, we have assumed that the time-to-completion for tasks A through G is known (or deterministic). In the development of many real world projects, the time needed to complete a task may be subject to considerable uncertainty.

2. Second, our rescheduling strategy is based on sequential sequencing of tasks. You should note that if it were somehow possible to remove links B --> C, D --> A, and G --> C (perhaps with the use of a new technology), then iterations within the blocks B --> D --> G and C --> A could be computed in parallel.

For a much more detailed discussion, see the notes on Design Structure Matrices .

In the development of engineering systems, systems integration is concerned with the management of interfaces. Interfaces may be operational, logical, or both. They appear as the system is decomposed into functional areas, and are usually characterized by mechanical, electrical, and software data parameters.

There are two general classes of problems associated with management of interfaces. In the development of a new product, many potential problems can be avoided with the precise definition of interfaces early in the project lifecycle.

A growing class of problems involves integration of legacy systems with new technology. For example, the advent of the Internet has provided organizations with the opportunity to develop application-specific software systems that fulfill their purpose, and communicate information to all of the other relevant software systems in a company. For those organizations that have made large investments in software, there is, naturally, great reluctance to simply discard the investment. What management would like instead is the benefits of improved communications without having to reinvest in the basic application-specific software. Within this context, the objectives of systems integration are to try to bring the situation under control, to ensure that the pathway forward maximizes return for the organization, and protect a companies past investments in software and hardware ~\cite{east94}. Systems integration is not a technical discipline in itself, but rather an approach to the management of organizations which recognizes the different ways its parts interact.

Vertical and Horizontal Integration

Figure 24 shows the relationship between vertical and horizontal integration of business partners.

Figure 24. Vertical Integration of Business Partners

Vertical Integration

Vertical integration is the process whereby different aspects of a business, "upstream" and "downstream" -- ranging from souring raw materials and production to marketing -- are brought together. To operate efficiently, each of the participants must make the effort to understand and recognize the purpose of each player.

Vertical integration encourages co-operation among participants, thereby lifting there overall welfare. In bargaining relations emphasis is placed on ``win-win'' results. To remain viable, however, vertical systems must maintain a balance between the dynamic dimensions of coordination and adaptation. Coordination involves synchronization and cooperation -- two factors that contribute to a stable organization. Adaptation involves reorganization, conflict and instability. While coordination is needed for short- and medium- term survival of a business, long-term survival requires an ability to adapt.

A manufacturing company might decide, for example, to engage in vertical integration by acquiring downstream distribution networks. A company strong in its downstream operations may try to engage in vertical integration by investing more in manufacturing. Vertical integration may also occur when complementary companies make long term contracts with one another or joint ventures, or if they decide to merge.

Horizontal Integration

Horizontal integration, in contrast to vertical integration, is movement towards a monopoly within an industry. Market differentiators include products provided in a certain form, quality and uniformity. Horizontal integration also encourages niche markets. Vertical and horizontal integration are not completely UN-coupled. For example, vertical integration may encourage tendencies toward monopoly by offering the integrated companies a competitive edge against their less integrated rivals.

Guidelines for the Design of System Interfaces

Guidelines for the design of system interfaces are as follows:

• Details of the system implementation should be hidden behind its interface.

• An interface should provide as much functionality as needed, and no more. (i.e., keep it simple).

• Interface functions should not overlap (i.e., orthogonality condition).

• A system module should only communicate with a customer via its interface.

• Interfaces should be consistent and regular (i.e, relative things should be achieved via relative means).

For more information, see Kernighan and Pike, "The Practice of Programming", Prentice-Hall, 1999.

System Interoperability

Interoperability means the ability of two or more programs to communicate or work together despite having been written/created in different languages or language dialects.

Figure 25. Use of Abstract Interfaces to enable System Interoperability

Sources of incompatibility include (Arpa, 1994):

• Mismatch of protocol structures.

• Non-conformance of vendor equipment.

• Inappropriate specificity of standards.

• Lack of appropriate cross platform software.

• Mismatch between performance requirements and the system capabilities.

Interoperability means the ability of two or more Frequently interoperability also implies communication between two or more support systems within a single processor to physically distinct processors within a distributed system. In the database world, interoperability refers to the ability to build applications that can simultaneously access data in different databases provided by different vendors. Transportability is the ability to move an application from one network (or hardware) combination to another while using the same database ~\cite{dowgiallo93}.

Abstract Interface Modules

Systems usually have access to external devices that transmit data to the system in either:

1. A standard format -- perhaps the system will use the data internally in a different format, or

2. A non-standard format -- the data has to be converted to some internal format.

An abstract interface module hides the interface of the system to some {\tt device} from: (a) changes in the characteristics of the device, and (b) replacement of one device by another device.

Remark. For more information on quality metrics for systems engineering design, see IEEE Transactions on Software Engineering}, March 1986 .

Middleware Solutions

Realizing this vision requires the design of engineering/computer systems that can operate across disparate hardware platforms, software languages, component/module interfaces, and networking protocols. These systems should balance the attributes of abstraction and simplicity. That is, we want to design apparently simple solutions to complex problems), interoperability and extensibility (i.e., the need for a system to handle a wide variety of information types/protocols must be balanced against the ability of a system to handle new information formats and unforeseen circumstances) and are symmetric (i.e., in a symmetric architecture, clients are coded to a common framework, and not another client). Consider, for example, a system of n components shown in Figure 26.

Figure 26. Custom and Framework-based Interfaces

In the traditional approach to systems development, components and modules are connected by point-to-point custom-built interfaces. The complexity of interface development is O(n^2) . A framework-based interface reduces the interface complexity from O(n^2) to O(n) .

The use of framework-based interfaces, otherwise known as middleware, simplifies the development of systems. For example, software programmers need only learn a small number of functions -- middleware takes care of communication details. See Figure 27.

Figure 27. Role of Middleware

Engineering/Business Applications of Middleware

At this point, 40% of Fortune 100 companies already use middleware. Engineering/business applications of middleware include:

• Presentations Management

  Management of forms, graphics and printing.

• Computation.

  Mathematics and engineering services. Internationalization services (e.g., manipulation of characters and strings).

• Information Management.

  Directory services, log and file manager. Management of repository data and information -- relational and object-oriented database systems.

• Communications.

  Peer-to-peer messaging. Management of messaging services, including e-mail and electronic data exchange.

• Control.

  Thread manager. Transaction manager. Resource broker. Course-grained job scheduler.

• System Management.

  Event notification service. Accounting services. Software installation management. Authentication services. Auditing services.

Example. Agile Manufacturing

The term "manufacturing" includes in its broadest sense, the entire life cycle of a product from product conception and design through production, maintenance, and disposal. Manufacturing is a multidisciplinary endeavor that requires an ability to combine the technical aspects of product development with human, management, cultural, and business practices.

Role of Standards

Standards play an important role in the development of large and complex engineering systems because they provide legitimacy to emerging technologies.

There are many types of standards. Some carry the authority of government regulation, and may be international in scope (e.g., building design codes). Other standards, such as companies proprietary specifications, may not share the same level of accreditation (Baudoin, 1996). Sometimes standards evolve from products that are so successful others want to use it, interface to it, and emulate it (e.g., Microsoft Word; Java).

Benefits of Standards

The benefits of standards are as follows:

• Portability

  Standards enhance portability of software between hardware platforms, operating systems, graphical user interfaces, and networking services.

• Interoperability

  Standards define common formats for the exchange of information between software/hardware systems.

• Risk Control

  The use of standards frees software/hardware from implementation-specific dependencies, thereby reducing risks in system developments, maintenance, and future upgrades.

• Enhanced Product Interchangeability

  Standards promotes so-called product and subsystem interchangeability. Interchangeability can mean availability of a wider choice of components, the selection of which may optimize cost, performance, and re-use.

• Cost Reduction

  Through the use of standards and mass product-production, most users will see a reduction in costs. Reductions in cost can also occur through competition between alternative vendors conforming to the same standard.

• Extended life-cycle

  Because many standards represent the most stable technologies, which in many cases evolve into upwardly compatible products, developing a new product that conforms to a standard reduces the likelihood of early system obsolescence.

Standards encourage creativity by providing a framework upon which new developments can be conceived and built. For example, without a dictionary and rules of grammar to provide standards for words and their use, a complex language cannot evolve.

Example. Standard for the Exchange of Product Model Data (STEP)

STEP is an acronym for Standard for the Exchange of Product Model Data (10303). STEP allows companies to effectively exchange information with their worldwide partners, customers and suppliers, as well as internally. In order to remain competitive in the global marketplace, companies will have to ensure this exchange is consistent, accurate and timely. See Figure 28.

Figure 28. Levels of Data Transfer between Models

Unlike other data transfer standards, STEP is computer sensible. It supports design reuse, data retention, and provides access to data across a product's entire life cycle. Product development strategies, such as concurrent engineering, enterprise integration, electronic commerce and quality function deployment, will significantly benefit from the use of of STEP -- allowing them to have a broad impact within enterprises.

Transactions of Data Packaged in Standards

Figure 29. Transactions of Data Packages in Standards

The design and manufacture of new products often requires the talents of many specialists, who may be geographically dispersed. A virtual enterprise must be able to form quickly in response to new opportunities, and dissolve just as quickly when the need ceases.

Figure 30. Electronic Network for Accelerated Manufacturing

Electronic networks enable creation of virtual enterprises, and interchange of design and manufacturing data. There are many challenges to communicating information among companies in virtual enterprises, including:

• Security Controls.

  Companies participating in a virtual enterprise are independent businesses, and often compete against one another.

• Control over Project Development.

  Techniques of project control that work well within one organization may not work well for projects involving multiple parties.

• Inability of Systems to Interoperate.

  Manufacturers will have difficulty collaborating if the data/information generated by one company cannot be read by another company. Sources of interoperability include:

  • Code Interoperability. Two applications cannot make use of each other's functionality because they cannot invoke one another's resources.

  • Unfamiliar Technology. Often a company's technology is complex, and requires substantial training to be used correctly.

Standards are being developed to overcome problems of interoperability (e.g., CORBA supports message calls between objects in a network; STEP for the exchange of product data).

Using the WWW for Manufacturing Activities

The World Wide Web can provide the following manufacturing support services:

• Dissemination of software for design purposes.

• On-line simulation services for product performance (e.g., finite element analyses) and assessment of manufacturability (i.e., manufacturing processes).

• Parts fabrication -- submit CAD model to parts server, and receive part in mail.

• Testing -- submit part by regular mail. Receive test results via e-mail.

Additional Reading. See "Communications of the ACM", February 1996. Special Issue on Computer Science in Manufacturing.

Benefits and Limitations of Functional Analysis and Design

Historically, architecture framework product definitions have been based on structured analysis -- that is, a methodology where the system mission is decomposed into a hierarchy of functions. The benefits of functional analysis and design are touted as follows:

1. The functional approach to development coincides with the way developers naturally look at systems;
2. Top-down functional designs can be tailored to the specific needs of an application.

The limitations of functional analysis and design are touted as follows:

1. Real-world systems are constantly being upgraded -- those systems designed along the lines of a top-down functional approach may not be readily amenable to upgrade and maintenance (object-oriented systems provide for better management of system complexity).

Key Ideas in Object-Oriented Development

Ideas in object-oriented development have been around since the late 1960s. The object-oriented paradigm (i.e., way of doing things) is motivated by a need to:

• Simplify the way we view the real world, and
• Provide engineers with mechanisms for handling complex problems that are subject to change (Henderson, 1990; Nerson, 1992).

Object-oriented analysis is analysis but also contains an element of synthesis. Generally speaking, these methods share the following basic steps, although the details and ordering of the steps vary a lot:

• Find ways that the system interacts with its environment (use cases);
• Identify objects and their attributes and functions;
• Establish relationships among the objects;
• Establish the interfaces for each object;
• Implement and test the individual objects;
• Assemble and test the system.

Abstracting user requirements and identifying key domain objects are followed by the assembly of these objects into structures of a form that will support the physical design at some later stage. The synthetic aspect comes about because we are analyzing "a system" that imposes structure on a problem solving domain. To support the ensuing design activities, analysis should emphasize the clear and concise definition of system interfaces, and as mentioned above, high the internal details of module implementations.

By using object-oriented analysis procedures, engineers are assisted in understanding the complexity of a project in three ways (Graham, 2001):

• Required changes are localized (i.e., object-oriented systems and architectures are decentralized.) Likelihood of unexpected interactions with other sub-systems/modules is minimized.
• For software, inheritance and polymorph-ism make object-oriented systems more extensible, thereby contributing to rapid development.
• Object-based design is suitable for distributed, parallel or sequential implementation.
• Objects correspond closely to entities in the real world of the developer an user, leading to enhanced seamlessness and traceability.
• Classification is part of the system structure. Shared data areas are encapsulated, reducing the possibility of unexpected modifications or other update anomalies.

The object oriented approach to design attempts to achieve these goals by deemphasizing procedures (or what the components will do), and emphasizing instead, the encapsulation of data and procedural features, together with a concise specification for the module interface.

Elements of Object-Oriented Development

Object formulations achieve their purpose with systems assembled from modules having having well defined functionality and well defined interfaces for connectivity to other modules. Typically descriptions of systems contain four elements:

• An identity;
• Data, objects, concepts and their structure;
• Architecture and atemporal processes;
• Dynamics or system behavior;

Object oriented development combines the second and third elements by encapsulating local behavior with data, and sometimes, also control. Problems with the early methods included:

• Lack of support for modeling of system dynamics;
• Little help in expressing business rules and constraints;

Modern approaches to object oriented analysis dispense with data flow diagrams (DFDs), and construct state models for individual objects instead. At the system level, models of interactions between a system and its users and external devices are usually expressed in terms of use cases.

As shown in the adjacent figure, functional flow is replaced by message passing among objects, which in turn, cause changes to the internal state of an object. This approach to problem solving requires developers to adapt the functional flow of control (used in functional development) to a control flow model that is influenced from moment to moment by events (Graham, 2001).

Visual modeling formalisms map real-world products and processes to a graphical representation or blueprint. These formalisms use symbols to represent real-world entities.

Visual models are particularly suited to the capture and representation of business and engineering processes, and the preliminary representation of system architectures.

As shown in the adjacent figure, both the functional and object-oriented approaches to system development begin with the identification events and things needed to generate system requirements and preliminary models of system behavior and system structure.

Figure 31. Functional and Object-Oriented Approaches to Visual Development

Event tables are a convenient way of organizing the information associated with the relevant events (Satzinger), and can contain for example:

• Event. What is the event that causes the system to do something?
• Trigger. How does the system know that the event has occurred? For external events, this is data entering the system.
• Source. What or who is the source of the event?
• Activity. What does the system do (i.e. sequence of activities) when the event occurs?
• Response. What output (if any) is produced by the system?
• Destination. After the system has finished responding to the event, what or who are the external entities that receive the system output.

Beyond the identification of events (and possible use of an event table), visual representations of systems in functional and object-oriented development are quite distinct:

Remark

In practical terms, the goals of object-oriented development have lead to both good and bad benefits. The good news is that once the intellectual process of object-oriented development is properly understood and mastered (much easier said than done), it can be used for multiple stages of project development. The bad news is that whenever inappropriate types of objects are selected, or whenever awkward structuring choices are made, the final architecture or system, reflects these poor decisions.

Near-Term Advances in Object-Oriented Development

Ideas and implementation procedures for object-oriented development have now been around for more than 30 years. During that time, object-oriented methods have matured from a focus on discrete event simulation and languages such as Simula and Smalltalk, to safer languages (like Java) and an interest in solving and implemented real-world design and analysis problems in distributed environments (Graham, 2001, pg's 8-9).

Anticipated near-term advances and focus areas for object-oriented development include (Graham, 2001, pg 9):

• Focus on architecture and patterns;
• Design and implementation for distributed systems everywhere;
• Migration to component-based systems and wrapped legacy systems;
• Real reuse via component-based systems;
• Increased attention to business modeling and requirements engineering;
• Shifted emphasis to safe object-oriented languages (e.g., Java).

Present-day design specifications and systems documentation tend to be textual -- they generate too much paper. More important, a fundamental problem with textual formats is the difficulty in obtaining zero ambiguity, zero inconsistencies, and full design-completeness. For the development of life-critical systems, oversights of these types cannot be tolerated. Hence it is critically important that we find ways of describing systems in ways that minimize error.

We believe that in the near future, electronic databases and Internet technology will become an integral part of project development, and will support online, electronic, representation of design specifications, design requirements, and the design itself. As a result, a fundamental question that we need to think about is:

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

Components of a Formal Model

Figure 32 shows how meta-models and ontologies are employed by formal models to produce a variety of representations for a system description.

Figure 32. What is a Formal Model?

Ontologies

An ontology is an explicit and precise description of concepts and relations that exists in a particular domain such as a given organization, a study field, an application area, etc. Ontologies usually three types of information (Bezivin, 2002):

1. Terminological. This is the basic set of concepts and relations constituting the ontology. It is sometimes called the definition layer of the ontology.

2. Assertional. This part is sometimes called the axioms layer of an ontology. It is a set of assertions applying to the basic concepts and relations, e.g.:

         ~[on(x,y) ^ on(y,x)]
         bachelor (x) º man (x) ^ ~married (x)
   

3. Pragmatic. This is the so-called toolbox layer. It contains a lot of pragmatical information that could not fit in a) or b). If, for example, there is a concept of "class" defined in the terminology, then this part could contain the functions and processes to create and manipulate the class.

From a systems engineering viewpoint, using ontologies to represent the knowledge about a system is important because it opens the door for partial automation of interpretation of information. Ontologies also facilitate the development of complex systems through "separation of concerns" and support for team development. When dealing with a given system, you can observe and work with different models of the same system, each one partially defined by a given ontology. See Figure 33.

When several ontology-specific models have been extracted from the same system, these extracted systems remain related and to some extent the reverse operation may apply (i.e., combination and integration of system concerns). For these two steps to work smoothly, we need a clean organization of system development duties (together with a notion of context and knowledge), composite models, and their corresponding meta-models.

Of course a model is always built for a given purpose, usually of understanding some aspects of the source system. This purpose should be clearly defined and associated to the ontology. The main properties of an ontology are sharing and filtering.

1. Sharing (i.e., Support for Team Development)

   Sharing means that an agreement may exist between different agents, based on the acceptance of common ontologies, that they have the same understanding of a given concept. When two systems engineers are talking about a requirement, they are talking about the same concept.

   

   Figure 34. Role of Ontologies in Systems Integration

   Figure 34 shows the role of ontologies in enabling (loose coupling) communication among two or more application domains modeled in XML (eXtended Markup Language) and RDF (the Resource Description Framework).

2. Filtering (i.e., Support for Synthesis of Models)

   Filtering is linked to abstraction of real world situations and the synthesis of models. Because models take into account only a part of the reality, their usefulness is based on their ability to filter out a lot of undesirable characteristics. An ontology can help define what should be extracted from a system in order to build a given model of this system.

   Filtering can also be used to hide information. For example, a keyword search on Google filters out web pages that do not match the listed keywords (i.e., all of the web pages that are not relevant to the keywords are not rendered). Beyond "listed keywords," human readers are needed to figure out if the knowledge contained within the web page is relevant. This can only occur if the human has an understanding of the content (e.g., can read the language).

   By representing the semantics of applications in ontologies, the hope is the next-generation web tools (e.g., search engines; systems engineering tools) will assist the user by automatically performing some of the semantic interpretation.

Sharing and filtering mechanisms are important to businesses that make money by keeping part of the information about their products proprietary. Other aspects of their products (e.g., the system interfaces) need to be open so that they can work with other products. Ontologies can help define what should be open and what should remain proprietary.

Representations

As a starting point, consider the following three cases (Bubenko, 1995):

1. Informal Representations

   These include arbitrary graphics (i.e., back of the envelope drawing), natural language (i.e., conversational), and (i.e., textual requirements). Generally speaking, informal representations are imprecise, bulky and often unorganized. The only technique for evaluating an informal requirement is human inspection.

2. Semiformal Representations

   These include structured graphical representations of the system, like data flow and functional flow block diagrams, object-oriented analysis diagrams, and so forth. Unlike informal representations, semi-formal representations come with semantics in the form of a semi-formal language.

3. Formal Representations

   These representations have a richer semantic structure than their semi-formal counterparts. and include specification languages, such as ERAE (Hagelstein, 1988). Formal requirements are needed in multiple formats: logical, numerical, inequalities, logical and relational expressions, hybrid logical and numerical.

   These mathematically based approaches to software and hardware development are important because of their potential for helping to ensure correct specification, design, and implementation of complex systems. Arguments that support the use of formal methods include (Atlee, 1996):

   • The process of formalizing system specifications forces the project participants to state all assumptions, thereby avoiding omissions and exposing inconsistencies.

   • Mathematical techniques can be used to analyze properties of a formal specification. For example, logic theory can be used to determine whether a specification comprised of a set of logic formulas is satisfied and consistent.

   • Mathematical techniques can be used to prove the consistency of different specifications. For example, one can verify that a formal design specification to a refinement of the formal requirements specification.

   • Communication among entities is characterized by well-defined flows of data and information (in response to occurrences), and enabled by well-defined entity interfaces.

It is important to observe that because each of these representations looks at the design information in its own way, the final output will be affected by choice of analysis method.

Remark. A standard criticism of formal methods is that customers find them hard to understand. Perhaps this is because the methods notations and mathematical techniques are difficult to understand. Software tools are needed that will overcome these barriers.

Points to note (Austin, Frankpitt, Baras 2002):

• Some guidelines for designing model spaces are as follows: (1) Keep the rules simple; (2) Use many model spaces adapted to specific domains; (3) Use translation tools to move between domains.

• The "English Language" representation of OO models provides descriptive semantics. This mimics the way that we think about systems, but makes for long-winded descriptions of system structure.

• Diagraming notation provides a visual syntax that retains the formalism of the language. This makes models easier to capture and understand.

• Standards such as UML provide a formal specification, called a meta-language, that secifies what constitutes a valid model description in a particular application domain. The standard also links the diagraming notation with the language representation. (In the case of UML the domain is software engineering)

The specification of the formal modeling languages and ontologies for particular problem domains provides support for:

• Efficient storage and communication of all valid systems models
• Tools (such as requirements tracing tools) that can draw inferences about a model based rules that are founded in the model structure.
• Tools that can use mappings of ontologies to translate models from one domain to another, e.g. a mechanical system model to a thermal system model.

Example. In the example presented in the next slide, the language supports three entities: classes, objects and relations. The language defines special relations between classes: generalization and aggregation, and a relationship between objects and classes, instantiation. It also specifies that interactions between objects are restricted to the relations that are defined for the classes that the objects represent.

Some Cartoon Examples

The problem domain is Bedrock Department of Transportation, Accident Reconstruction Office.

Part 1. The meta-model elements and meta-model rules.

Meta model elements classes objects relations attributes special relationships Generalization Aggregation Instantiation Meta model rules Each object instantiates a single class Let A, B and C be classes, and let r be a relation. If A generalizes B, and if r connects B to C, then r connects A to C

Notation for Meta Model Elements

Part 2. The meta-model and ontology

The Ontology The class person has a name attribute The class vehicle has a license plate attribute The class vehicle is an aggregate of a drive-train, a body, an electrical system, etc. The class vehicle is a generalization of the classes truck, car, and motorcycle A person can relate to a vehicle as a driver, a passanger. A vehicle can collide with a person

The meta model

Part 3. A specific model

English language representation: The person with name Fred is the driver of the car with license plate AAA 111 The person with name Wilmer is the passenger of the car with license plate AAA 111 The person with name Barney is the victim of a collision with the car with license plate AAA 111

Diagram representation:

Notes:

• The meta language elements are quite general. The generalization and aggregation relationships support scalable models.
• The part of the language that is domain specific is the ontology.
• To develop this material for a short course we need to find an example that is realistic and meaningful to the target audience e.g. mechanical engineers working on systems at Lockheed Martin. Do you have an example that we can slot in place?

Executable Models

Executable models automate:

• Step-by-step execution of system behavior and design process implementation.
• Generation of customized views of system behavior and structure from central models/databases.
• Verification of system behavior and structure by the computer.

Executable models are needed to ensure:

• Each object class has at least one connection to other parts of the system.
• Low-level interconnections are consistent with those at higher levels of abstraction.
• Provide automated (or semi-automated) layout of components (e.g., like in circuits; building design).

Execution can be a manual process or by computer.

Consider the following comments:

• "The single most important factor shaping our industry has been, and will continue to be, the computer." A comment by Mark Burgess, principal engineer, defense and space group, Boeing Advanced Systems (Burgess, 1991).

• "Conventional CAD is just an electronic pencil. The potential for using the computer to integrate technical and business aspects of design has not been touched." A comment by Prof. Kim Clark, Harvard Business School; taken from Whitney (Whitney, 1990).

Many companies are finding that in order to remain competitive in a global marketplace, production times, costs, and schedules must be shorter, cheaper, and more flexible than in the recent past. The judicious use of computer-aided systems engineering (CASE) tools and group decision-making technologies is often seen as a means of mitigating these problems.

Figure 35. Systems Engineering Products, Processes and Models

The goal is to develop enterprise- and project-level systems tools that will support the team-based development of systems, automate design evaluation and trade-off analyses (where possible), and improve the product life cycle by taking advantages of concurrency whenever possible.

During the past decade two broad categories of systems tools have slowly emerged:

1. Technical Decision Support

   Technical decision support helps coordinate the consensus building process by helping designers sort through and evaluate design alternatives that have been recognized. From a technical decision standpoint, systems engineers need tools that will:

   • Assist them in the acquisition, definition, and tracking, of requirements,
   • Facilitate the execution of engineering analyses for system performance assessment.
   • Automate (or at least partially-automate) the execution of trade-off studies (e.g., cost versus quality, time-to-market versus quality) both at the system and sub-system levels.

   Each tool covers only part of the systems process -- some parts of the process may not be covered at all.

   The implementation of this capability requires models of interconnected components and design dependencies, and the processes describing interaction among components during the systems life-cycle process.

2. Infrastructure Support

   Infrastructure support includes management of communications and flow of work among team members. It is enabled by databases, graphics, and communication networks. The goal is to obtain high levels of information and knowledge integration, and efficient mechanisms of communication, management, and use of organizational resources (e.g., using corporate Intranets for access to online libraries of reusable software code, and commercial off-the-shelf products, materials, and services.).

A good toolset will detect design errors and inconsistencies, and help a contractor explain to the customer, for example, how a particular requirement fits into the overall process, or perhaps how it may/may not be related to other sets of requirements. It might also help a manager detect inefficiences in organizational practices, and suggest improvements to an organization's structure.

Integrated CASE Tools

Integrated Computer-Aided Systems Engineering (I-CASE) tools are the result of the merging of technical decision support and infrastructure support. By automating the execution of domain-specific tasks (e.g., requirements analysis; traceability; domain-specific engineering analyses) and the communications among them, I-CASE has great potential for improving productivity and reliability in the development of large-scale engineering systems. By using I-CASE to take care of the many routine details a systems engineer must deal with, the hope is he/she will have more time to focus on creative design tasks.

Recent (and not so recent) Advances in Computing Technology

In the 1970s most computer systems were stand-alone, and most software developers wrote computer programs dedicated to a specific task (e.g., finite element analysis; control systems package; an accounting or stock control system). Rarely were these packages developed as an integral part of a much larger picture, which included not only the package itself, but human, operational, and organizational considerations. Indeed, it was standard practice for organizations to develop software for applications in isolation of all other computer applications that could be running inside the same organization.

During the past two decades computers have been providing approximately 25% more power per dollar per year. An important component of these advances is central processing units, which for the past twenty years have been doubling in speed every 12-18 months.

Nowadays, high speed engineering workstations having bitmapped graphics, global network connectivity (e.g., cellular communications; fiber optic; the World-Wide Web), and multimedia (i.e., two or more of the following; graphics, voice, digital sound, video) are readily available in the marketplace (Halal, 1993; Press, 1993). Whereas computers in the 1960s and 1970s where viewed primarily as computational engines, importance is now placed on computation and communications, ease of use, and a wide-array of services being made available to the engineering profession as a whole.

The merging of computation and communications is making fundamental changes to the way an engineer conducts his/her day-to-day business activities. Consider, for example, an engineer who has access to a high speed personal computer with multimedia interfaces and global network connectivity, and who happens to be part of a geographically dispersed development team. The team members can use the Internet/E-mail for day-to-day communications, to conduct engineering analyses at remote sites, and to share design/analysis results among the team members. Clear communication of engineering information among the team members may be of paramount importance in determining the smooth development of a project.

Recent advances in technology seem to offer the potential for real-time computer-supported collaborative workspaces in which complex information (e.g., textual documents, maps, pictures, drawings, audio information, computer displays, simulations....) may be exchanged among geographically dispersed participants as they cooperate in day-to-day business/engineering activities. If this technology can be used to dramatically improve the usability, commonality, consistency, and responsiveness of the information shared by groups, then significant increases in productivity are likely to occur.

Despite remarkable advances in computer science (e.g., tools for storing, accessing, equipment; and for supporting remote collaboration via electronic mail and the World Wide Web), there are no ready-made off-the-shelf solutions to these problems at this time. Basic research problems include understanding how to use emerging information and hardware technologies in complex, distributed, computer-supported, cooperative work environments.

Changing Economics of Software Development

The economic challenges and difficulty in following-up on the abovementioned hardware advances with appropriate software developments is clearly reflected in in Figure 36.

Figure 36. Economics of Systems Development and Integration

In the early 1970s software consumed approximately 25% of total costs, and hardware 75% of total costs for development of data intensive systems. Nowadays, development and maintenance of software typically consumes more than 80% of the total project costs. This change in economics is the combined result of falling hardware costs, and increased software development budgets. Whereas one or two programmers might have written a complete program twenty years ago, teams of programmers are now needed to write todays programs. This gradual change in development strategies has bought with it, new challenges in the software development process -- for instance, when all of the details of a software/systems project cannot be understood within a group small enough to freely communicate, the cost of communications becomes high. Errors are easy to make and hard to find.

If we are to have any chance of keeping up in the future, attention will need to be paid to software design and reuse of functions, libraries, modules, program architectures, and programming experience. Each form of reuse will need to be annotated to an appropriate form of abstraction (e.g., UML; ontologies).

Pathway from Models to Tools

A closely aligned problem is the need to move from generalizations about systems thinking to specific processes and tools that help us understand system complexity and design better performing systems in compressed time.

This requires a well defined pathway from models to tools for each of the participating disciplines, followed by the integration of these pathways into processes and tools for generic systems engineering development. In each case, a convenient way of representing the pathway of development is as a stack of concepts, as shown in Figures 37 and 38.

Assembly of the stack is complicated by the need for development that proceeds in two directions.

1. From the bottom, one starts with models and system architectures, identifies processes, and finally, designs systems engineering tools that enhance the systems life cycle process.

2. From the top of the stack, one begins by observing the work practices of individuals and teams of workers within the domain. Fundamental questions are how do people work as individuals, and in teams? How do teams of workers interact? How does technology enhance the productivity of these workers?

With an understanding of these issues in hand, high-level processes can be partitioned into step-by-step procedures, and eventually models can be formulated for storing the basic types of information in the problem domain.

Research Note

A central theme of our research is that advances in information-centric systems engineering will occur together with those in ontology-based computing. With technologies for the latter in place, we envision development of web-centric, graphically-driven, computational platforms dedicated to system-level planning, analysis, design and verification of complex multidisciplinary engineering systems. These environments will employ semantic descriptions of application domains, and use ontologies to enable communication (or mappings) among multiple disciplines (e.g., to the engineering team members, to marketing, to management, and to customers).

They will have the ability to represent system behavior and structure at a high level of abstraction, to view systems from multiple contextual viewpoints, and to evaluate and improve upon system capability at the logical level (i.e., independent of underlying technology implementations). The latter will be achieved through coupling of the design environment to "rules for system synthesis" and high-level graphical representations of standards, thereby allowing designers to: (1) Learn about system requirements by browsing through the logical content of the standard, and (2) Learn why elements of a proposed design violate one or more provisions of a standard(s). Languages and appropriate low-level editing operations are needed for the assembly and transformation of these models. To keep the complexity, management, and cost of developments in check, abstraction of multiple disciplines to properly annotated information representations and re-use of previous work at all levels of development will be essential.

1. Austin M., Frankpitt B., Baras J., "Research and Curriculum Development for 3D Model-Based Systems Engineering," Presentation to Lockheed Martin, Bethesda, May 1, 2002.
2. Bezivin J., "Who's Afraid of Ontologies," See http://www.metamodel.com/oopsla98-cdif-workshop/bezivin1/ , Université de Nantes, Faculté des Sciences et Techniques, France, 2002.
3. Browning T.R., Fricke E., Negele H., "Process Modeling in a Systems Engineering Context," Tutorial 03, 12th Annual Symposium, International Council of Systems Engineering, Las Vegas, Nevada, July 28-August 1, 2002.
4. Bubenko J.A., Challenges in Requirements Engineering, In second IEEE International Symposium on Requirements Engineering, York, England, 1995.
5. Burgess M.A., The Future of Aircraft Design, Aerospace America, pp. 22-24, September, 1991.
6. Chateau J.M., Flexible Platform-Based Design, ISD: The Journal of Design Process, February, 2001. See http://www.eedesign.com/isd/OEG20010228S0084.
7. Gebala and Eppinger, "...", 1991.
8. Gonzalez-Zugasti J.P., Otto K.N., Baker J.D., "A Method for Architecting Product Platforms," Research in Engineering Design, Vol 12., 2000, pp. 61-72.
9. Hagelstein J., "Declarative Approach to Information System Requirements," Knowledge-Based Systems, Vol. 1, pp. 211-220, 1988.
10. Halal W.E., The Information Technology Generation, Engineering Horizons, pp. 10-13, September 1993.
11. Keutzer K., Malik S., Newton R.A., Rabaey J.M., Sangiovanni-Vincentelli A., System-Level Design : Orthogonalization of Concerns and Platform-Based Design, IEEE Transactions on Computer-Aided Design of Circuits and Systems, Vol. 19, No. 12, December 2000.
12. Press L, Personal Computing: Technetronic Education: Answers on the Cultural Horizon, Communications of the ACM, Vol. 36, No. 5, pp. 17-22, May 1993.
13. Sabbagh K., "Twenty-First Century Jet: The Making and Marketing of the Boeing 777," Scribner, New York, 1996.
14. Sangiovanni-Vincentelli A., McGeer R., Saidaaha A., "Verification of Integrated Circuits and Systems," Presented at the 1996 Design Automation Conference, Las Vegas, NV, 1996.
15. Simpson T.W., Jonathan R.A., Mistree F., "Product Platform Design:Method and Application," Research in Engineering Design, Vol. 13, 2001, pp. 2-22.
16. Whitney D.E., Designing the Design Process, Research in Engineering Design, Vol. 2, No. 3, pp 3-13, 1990.
17. Wilson J., Platform-based Design Ups Productivity, Business Development Manager, SoC Verification Business Unit This article first appeared in the November 20, 2000 issue of Electronic Engineering Times in the System Design section - Focus: Tools for Reprogrammability

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.