A system of systems is a collection of independently useful/operational systems which have been glued together to achieve further emergent properties.

• An iPod connected to your automobile audio system is an example of a system of systems because, by themselves, both the iPod and automobile audio system have well defined, autonomous, functionality.
• The human heart is not a system of systems -- it does not have standalone functionality.

The primary design focus is on the interfaces, specifically the communication standards, as very little can be done to modify the monolithic systems.

Systems of systems can be classified into three types:

• Coerced,
• Collaborative, and
• Chaotic.

Coerced Systems of Systems

• In a coerced, or directed, system of systems there is a central entity which can dictate behavior.

Example -- Windows Operating System

• The Windows Operating System dictates certain behaviors of the software applications that run under it.

Example -- Smart House

• Network of smart appliances in a smart house.

Collaborative Systems of Systems

• A collaborative system of system is composed of several systems working together for synergistic effects.

Designers must consider why these systems will choose to collaborate, and then foster those reasons in the design. A working system will depend on the interfaces between individual systems.

Example -- Transportation Services at an Airport

• An airport acts as the interface between surface and air transportation services. Figure 1 shows the sequence of taxi and air transportation services that a traveler might employ in a home-to-destination trip.
  

  Figure 1. Cooperating transportation services for home-to-home travel

  The key challenge in creating an efficient system is synchronization timetables and capacities so that passengers can transition from one mode of transportation to another.

Example -- An Orchestra

• A good visual interface between the conductor and all members of the orchestra is essential!

Chaotic Systems of Systems

Chaotic (or virtual) systems of systems do not have a centralized management structure.

Examples -- The Internet and Open Source Software Development

• The Internet operates only on recommended standards which the various systems voluntarily adopt.
  

  The penguin is the icon for Linux, an open source operating system.

Chaotic systems of systems work because the various systems find the interface standards to be advantageous. Companies build web pages which adhere to the HTML standard not because they have to, but because it is economically advantageous to.

Our research approach:

Our research approach is motivated in the next two sub-sections.

Requirements Management Systems are Chaotic Systems of Systems

Requirements management systems need to deal with internal and external requirements. Internal requirements are generated from within a project. The latter emanate from external sources (e.g., the EPA may mandate that a system must satisfy certain environmental regulations).

Figure 2. Flow of requirements in team-based system development.

Points to note:

• High-level project requirements are partitioned into groups of requirements and specifications for individual team development. Requirements are a "qualitative" statement for what we want .... Specifications are a "quantitative" statement for what we want ... We can express the latter mathematically in terms of constraints.

Monolithic System

A requirements management systems can be implemented as a monolithic system. But as soon as the need to leverage or reuse the requirements across projects, companies, and industries is found, a monolithic system approach is no longer viable. (i.e., it is unrealistic to expect that all companies participating in a large project will conform to a standard set of requirements management tools, or any other tool for that mattera.)

Chaotic System of Systems

The chaotic system of systems is a more appropriate model because every project, company, and "regulations authority" will operate based on personal needs and desires.

Thus, an open standard is needed which will allow the various systems to share a common data structure and build customized tools to meet the personal needs.

In his original vision for the World Wide Web, Tim Berners-Lee described two key objectives:

• To make the Web a collaborative medium;
• To make the Web understandable and, thus, processable by machines.

During the 1990-2000 time frame, the first part of this vision has come to pass.

• Today's Web is designed for presentation of content to humans.
• Humans are expected to interpret and understand the meaning of the content.

The aims of the Semantic Web are to

Modeling

The Semantic Web Layer Cake

Figure 3. The Semantic Web Layer Cake (Berners-Lee, 2002).

The Semantic Web will be assembled from a layer cake of technologies:

1. XML files and web resources capture objects and classes. With XML you can:

   • Define data structures that are platform independent.
   • Process XML defined data.
   • Define your own tags.

   XML separates structure from presentation, thereby allowing for presentation to be customized to capabilities of the end device. e.g.,

   

   The adjacent figure shows the pathway of development and execution for an xml-based application.

   

   It is convenient to partition this pathway into two phases: (1) Definition of the XML Document, and (2) XML document processing.

   Phase 1: Definition of the XML Document.

   XML documents are defined in two parts: (1) a document type definition (DTD), and (2) the XML markup itself.

   1. Document Type Definitions (DTDs). A document type definition (DTD) provides applications with advance notice of what names and structures can be used in a particular document type (i.e., it is a formal description in XML declaration syntax of a particular type of document. A DTD sets out what names are to be used for the different types of element, where they may occur, and how they all fit together.

   2. XML Markup. The XML markup is composed to pairs of tags, elements and attributes. XML documents must be well-formed. Start and end tags must match. Element tags must be properly nested.

   Most often these parts will be defined in separte files (as shown in the figure above), but it is possible to embed the DTD in the same file as the XML markup. An example of the latter is shown below.

   Phase 2: Processing an XML Document Processing.

   XML documents are processed by a combination of: (1) parser and (2) application programming interface (API) software.

   1. A parser reads the XML document as plain text. The API offers programmers a set of functionality that they can call from a program to request information from the parser as it processes the document. The two most common APIs are the document object model (DOM) and the Simple API for XML (SAX).

      Some pasers are able to check (or validate) that an instance of an XML document against the data type definition (DTD) that is used to describe the vocabulary, and to check whether the actual markup conforms to the rules of the markup language.

2. RDF (resource description framework) describes relationships between objects and classes in a general but simple way.

   RDF separates content from structure, thereby allowing for the merging of multiple conceptual models.

   Click here an example of RDF.

3. Ontologies provide a formal conceptualization (semantic representation) of a particular domain shared by a group of people.

4. Ontology-based applications will be built on top of the Semantic Web infrastructure (i.e., XML, RDF and ontologies)

Note. XML technologies are an integral part of the AP233 interchange format for requirements.

Simple Example (... for how things will eventually work)

Today's search engines rely on "keywords."

Suppose that an ontology (i.e., conceptualization of a domain) of people relationships tells us:

     Concept 1.  If "a" is married to "b" then "a and b are friends"
     Concept 2.  If "a" and "b" are "best friends" then "a" then "b" are friends.
     Concept 3.  If "a" is a friend of "b" then "b" is a friend of "a."

And suppose that we could represent facts on the web.

     Fact 1.  John and Mary are married.
     Fact 2.  Jane's best friend is Mary.

With these concepts and facts in place, a semantic search engine should be able to accept queries of the type:

     Query 1.  Who are Mary's friends?

and answer with:

     Answer.  John and Jane.

Note. Concepts limit the "design space" by placing constraints around the set of (potentially) feasible solutions (c.f., differential equations in engineering).

We need a framework to support synthesis of system architectures enabled by product descriptions on the Web.

Figure 4. Simplified Architecture of a Home Theater System

Figure 4 shows elements of a top-down/breadth first development (decomposition) followed by a bottom-up implementation procedure (composition). Looking ahead, we envision database libraries of object-specification pairs from which components can be selected.

• As high-level requirements are decomposed into lower-level requirements, and models of system behavior and system structure, designers would like to "look down" into the "product library" to see what standards are available .... etc.

• When we select a component from the "library of products" for potential use in the system architecture, checks are needed to make sure the component I/O interfaces are compatible with the system architecture and constraints imposed by other components in the architecture.

This so-called "systems integration" problem has become key and perhaps the most profitable engineering practice.

Attaching Specifications to Objects and Components

We envision the development of object-specification pairs that define a set of behaviors offered by a component/object. Object/component descriptions must be at least multi-input multi-output (MIMO), otherwise they aren't useful.

Figure 5. Elements of an Object-Specification Pair

An interface specification precisely defines what a client of that interface/component can expect in terms of:

• Supplied operations (e.g., minimum and maximum levels of component functionality).
• Types of signal, data and information flows, and
• Operational pre- and post-conditions.

Together the pre- and post-conditions and satisfaction of the input requirements constitute a contract.

Selection of Sensors from a Database

Suppose that it were possible to create a family of sensor-specification pairs (probably expressed in XML and RDF).

Figure 6. Formulation of Sensor-Specification Pairs

Then, we could create and XML database graphical frontend for browsing the database and answering suitable queries:

Figure 7. Architecture of XML database and graphical frontend.

Developed in October 2006 by Mark Austin
Copyright © 2006, Mark Austin, University of Maryland.