Systems Colloquium Presentation, U.C. Berkeley, April 10, 2003 By: Mark Austin (....with help from Natasha Kositsyna, Vimal Mayank, Scott Selberg)
Table of Contents	Contact Information and Project Participants
Our Definition of Systems Engineering Case Study: NASA's Global Precipitation Measurement (GPM) System. Major Challenges facing the Practising Systems Engineer Guiding Principles. We promote: Function-Architecture Co-Design and Orthogonalization of Design Concerns Use of Technology-Independent System-Level Design Representations Automation for Multidisciplinary Information-Based Design Reuse at all levels of Abstraction/ Object-Relational Database Storage. Systems Engineering Research and Education at ISR Requirements Engineering Definition. Requirements Engineering Work Breakdown Structure Low-End Models of Product and Process Traceability State-of-the-Art Capability for Requirements Management Tools Requirements Engineering and the Semantic Web Systems of Systems The Second-Generation (Semantic) Web/ Semantic Web Layer Cake Mapping the Requirements Engineering Work Breakdown Structure to layers of technology in the Semantic Web Research Agenda (2000-2003) Project 1. Java-Enabled Diagram Technology. Project 2. An XML/RDF Traceability Viewer. Project 3. Formal Methods for the Synthesis of Modular Systems with Real-Time Rule Checking. Conclusions and Future Work. Project 4. Formal Methods for the Synthesis of Sensor Networks in Buildings.	Institute for Systems Research, University of Maryland, College Park, MD 20742. E-mail : austin@isr.umd.edu Univ. of MD Project Participants: Mark Austin, John Baras, Bernie Frankpitt, Jim Hendler, Vimal Mayank, Natasha Kositsyna, Deep Saraf, Scott Selberg. Industry Participants: James Adams (Manager, Global Precipitation Measurement Group, NASA Goddard). David Everett (Systems Engineer, NASA Goddard). Michael Krok (GE Research and Development). Paul Robitaille (Corporate Fellow, Lockheed Martin). Sponsors: National Science Foundation, GE Research and Development, Lockheed Martin, Northrop Grumman, NASA Goddard Space Flight Center. In the pipeline: Lockheed Martin Aerospace, Ft. Worth, TX.

Our Definition of Systems Engineering

Despite 30 years of history, systems engineering still means many things to many people (but, actually, the same is true of Civil Engineerin and it's been around for centuries). A few of the most commonly used texts contain at least 20-30 definitions of systems engineering. I happen to like:

At first this leads you to believe that "systems engineering is all things to all people," which of course runs the danger of delivering almost nothing to most.

To avoid falling into that trap, we are very explicit about what systems engineering means to us:

For this "working definition and vision" to be realized, we need methodologies for the synthesis of systems from modular components, support for team developments, ways to handles large volumes of heterogeneous data and, of cource, procedures for quantitative decision making.

The "front-end" part of our definition and focus is key because this is where decisions have the largest impact on commitment of funds in a project and, also, greatest opportunity for improvements.

Discipline Maturity

From a research and software development perspective, I think systems engineering is in exactly that same spot as finite elements, late 1960s. The problems aren't simple, but there are lots of opportunities for contributions.

Why Systems Engineering is Important?

Over the past fifteen years there have been several important reasons and developments that have rendered systems engineering methodologies, tools, and educational programs critical. They are:

1. Rapid changes in technology;

2. Fast time-to-market most critical;

3. Increasing pressure to lower costs;

4. Increasing higher performance requirements;

5. Increasing complexity of systems/products;

6. Increased presence of embedded information and automation systems; and

7. Failures due to lack of systems engineering.

70% of product and system failures are due to bad or no Systems Engineering effort, as our industry advisors (General Electric, Lockheed Martin, Northrop Grumman) and collaborators have frequently stated.

Science Mission

Provide satellite coverage and sampling strategy to (Adams, 2001):

• Improve probability of detection of extreme rain events. Coverage region: 90 N to 90 S latitude. Goal: 3 hour maximum revisit interval.
• Better understand the horizontal and vertical structure of rainfall and its microphysical elements.
• Provide enough sampling to reduce the uncertainty in predictions for short-term accumulations.
• Extend scientific and societal applications (e.g., improved water resources and infrastructure planning --> better policies for sustainable development).

Systems Architecture

Form rain measuring constellation using co-op satellites from other programs suitable passive microwave radiometers dedicated to GPM mission:

• Core Satellites
  Provide instruments for cloud physics research and calibration of radiometers on constellation satellites.
  • Dual frequency radar and multi-frequecy radiometer.
  • TRMM-like spacecraft at 400-500 km altitude.
• Constellation Satellites
  • Multiple satellites with microwave radiometers.
  • Aggregate revisit time -- 3 hour goal.
  • Approximate altitude 600 km.
• Precipitation Validation Sites
  • Global ground based rain measurement.
• Global Precipitation Processing Center
  • Produces Global precipitation data products as defined by the GPM partners.

Program Budget, Participants, and Schedule

• Need a minimum of 7 satellites for the system to work.
• Budget. NASA only has enough money to pay for 2 of them.

GPM performance depends on sucessful partnerships -- space segment; ground segment; validation segment; research segment.

• Current project partners: S. Korea, Japan.
• Potential partners for constellation satellites: Canada, Australia, France, Italy, United Kingdom, China, India....
• Partner satellites (e.g., EuroGPM-1, Euro-GPM-2) are scheduled for launch 2008-2010.
• Duration. At least through 2018.

GPM Trade Space

The GPM trade space includes:

• Science requirements and partnership development.
• Systems engineering and measures of systems effectiveness.
• Mission architecture.
• Measurement approach -- radar and radiometers.
• Ground and data systems.
• Progrommatic considerations.

The NASA GPM project contains elements of the major challenges facing the practising systems engineer:

Support for Team Development

Today's industry requires that teams of experts from multiple disciplines/domains work together on the solution of complex problems (e.g., integrated product teams (IPTs)). These teams may be geographically dispersed and mobile.

We need to maintain a shared view of the project objectives, and at the same time focus on specific tasks. See Figure 2.

Figure 1. Elements of Team-Based Development

A key challenge is avoiding communication and interpretation problems -- everyone needs to know what they are supposed to be working on, and when it's due!

Extended Project Duraation

In most large systems engineering projects, the team working on a project at its inception has probably retired before the project is completed.

• NASA's Global Precipitation Measurement (GPM) Project: 20-25 year duration.
• Lockheed Martin's Joint Strike Fighter: 30 year duration.

Methodologies and tools are needed for the capture of knowledge (i.e., understanding of a problem domain; pathway of decision making) so that all is not lost when an employee leaves.

Synthesis from Modular Components

The prevalence of synthesis from modular components is no longer true just for aerospace, defense and large government contracts (systems engineering started with Aerospace Engineering). Instead it is required in all commercial designs and operations.

Figure 2. Top-down decomposition and bottom-up synthesis coupled to reuse of objects/sub-systems.

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

Growing Importance of Information-Driven Systems

In the Past Systems have been seen from an operations point of view, where information and communications have been regarded as the supply of services necessary for the system to operate in pre-defined ways. Nowadays There is a rapidly evolving trend towards the development of large-scale information-dominated systems, which exploit COTS and communications technologies, have superior performance and reliability, and are derived in response to various types of information drawn from a wide array of sources. Simply put -- these systems have functionality that would not be possible without an ability to gather and work with data/information.

Example In a modern automobile, the electronics and communication systems account for 30% of the overall cost. Figure 3. Electronics and Communications in a Modern Car. (Source: A.S. Sangiovanni-Vincentelli, EE 249, UC Berkeley, Fall 2002.)

Large Volumes of Heterogeneous Data

Current and future data are in large volumes (not all relevant), numerically intensive (often requiring parallel algorithms for processing), multidimensional, heterogeneous, distributed, typically worked on specialized search engines, and represent multiple views (to the various users from engineering team members, to marketing, to sales people, to management, and to customers).

Example 1. Sensor Networks for NASA's GPM Project

Estimates of rainfall made in space need to be callibrated against Ground Station Measurements.

From Space
Dual frequency radar and multi-frequecy radiometer.

From Ground-Level
Rain Gauges

Example 2. Sensor Networks for Security of Buildings

Multiple sensor modalities must be used for the detection and classification of intruder and chemical/biological threats to a busy building. All sensors should be connected via a wireless network.

Information processing must be able to work with a variety of data formats:

• Motion detectors.
• Acoustic sensors (microphones).
• Image sensors (cameras).
• Temperature, chemical, and biological sensors.
• Magnetic sensors.

Key research challenges include:

• Sensor fusion among heterogeneous sensors, and
• Techniques for rubust performance and security -- no false alarms!

Systems engineering activities complement (and support) those of the traditional engineering disciplines.

Figure 4. What's Systems Engineering?

Our goals for Systems Engineering Research and Education at ISR are to formulate and provide formal (model-based) methodologies for "liason among disciplines" and "systems analysis and trade-off."

Economic Considerations

Figure 5. So-called "Knowledge Gap" in Systems Development

Importance of Frontend Development

Figure 6. Desired Goal for Improved Design Flexibility

Research Challenges

1. Identify and address key research challenges facing "synthesis of engineering systems."
2. How to codify this knowledge into systematic methodologies and tools for the "synthesis of engineering systems?"
3. How to find a practical way of using web technology to enhance: (a) classroom instruction, and (b) self-guided "post-training" instruction.

We promote:

Use of Technology-Independent System-Level Design Representations

• We want to enhance the longevity of our work by creating system-level design representation that are not tied to an underlying implementation technology. This can be achieved, in part, through separate representations for the logical and physical design.
  
  Figure 7. Provision for Fomalization and Early Detection of Errors

• Goal.
  Hardware and software implementations and specific technology selections are ``pushed'' near the very end (i.e., delayed as long as possible), but are performed once and must work flawlessly.

Enhanced Systems Engineering Management through Design/Requirements Representations Connected by Mappings and Traceability

• Figure 8 shows the primary tracks of traceability for the development of a system-level product.
  

  Figure 8. Traceability Mappings for the Development Pathway, Goals/Scenarios through Eystem Evaluation.

  For system-level design, traceability begins with the connnection of goals and scenarios with use cases. It links the requirements and specifications with models of system behavior, system structure, and procedures for system evaluation.

Management of Complexity through Orthogonalization of Design Concerns

• Emphasize function-architecture co-design. System design alternatives are created by mapping models of system behavior onto tentative system structures. System evaluation and ranking/optimization procedures eliminate the inferior solutions.
  

  Figure 9. Evaluation, Ranking, Optimization and Trade-Off Analysis for System Design Alternatives

• In the design of complex engineering systems, "orthogonalization of concerns" simplifies the difficulty in exploring the space of design alternatives.

Quantitative Procedures for System Evaluation, Optimization and Trade-Off

• Develop sophisticated algorithmic, mathematical and quantitative methods implementable in modern software environments for system evaluation, ranking, optimization and trade-off analysis.

Automation for Multidisciplinary Information-Based Design

• We need to find ways to automate the capture and processing of data/information relevant to engineering system development.
  

  Figure 10. Requirements Engineering Processes supported by Semantic Web Technology

• Systems engineering development processes (e.g., requirements engineering) and the Semamtic Web are both "chaotic systems-of-systems." Systems engineering methodologies and tools for automation can benefit from advances in Semamtic Web Technology!

Reuse at All Levels of Abstraction

• Abstract multiple disciplines to properly annotated information representations. This is the only way to allow communication among disciplines and multiple contextual views.
  
  Figure 11. Layers of Abstraction in Reuse

  A "general-purpose" information representation that can describe all aspects of system behavior and structure is currently unavailable. Hence, systems must work with multiple information abstractions. For example:

Use of Object-Relational Database Storage

• Enable reuse of designs, architectures and business processes through object-relational database storage.

  

  Figure 12. Business Processes supported by Technology

• Object-relational database storage can be the foundation for "platform-based design" of engineering systems.

Elements of Requirements Engineering

Requirements engineering bridges the gap between organizational-level and project-level concerns.

Figure 13. Requirements Bridge the Gap between Organization- and Project-Level Development.

Requirements engineering addresses the development and validation of methods for eliciting, representing, analyzing, and confirming system requirements and with methods for transforming requirements into specifications for design and implementation.

Figure 14. Components of the Requirements Engineering Process

How do we capture and represent knowledge through requirements engineering activities?

Problem Size and Complexity

There are a plethora of examples:

• Projects that have dealings with the Environmental Protection Agency (EPA) must be aware of 200,000+ evolving requirements (Sampson, 1998).
• Space Station Freedom has over 1.5 million requirements.

The only economically feasible approach to managing this complexity is by automating parts of the reasoning process with inference services.

Writing Requirements and Specifications

Requirements and specifications need to be written in a manner that balances two key aspects: (1) they should be readable, and (2) they should lend themselves to various forms of automated processing.

Table 1 summarizes the key features of requirements and specifications.

Low-End Models of Product and Process Traceability

Product Traceability
Product traceability mechanisms connect requirements to elements of the design.

Figure 15. Components of the Requirements Engineering Process

Two key questions need to be answered:

1. From the requirements side ... how is each requirement taken into account in thd design?
2. From the design side ... why is this design element needed?

Requirements-to-design traceability ensures that the design takes all of the requirements into account. Design-to-requirements traceability ensures that design elements are actually needed.

Process Traceability
Traceability can also be applied to the sequence of decisions defining the underlying development process, e.g., traceablity of rationale to specific decisions, decisions to actions items ...etc.

State-of-the-Art Capability for Requirements Management Tools (e.g., DOORS and SLATE).

Organizing requirements into the right structure can help:

• Minimize the number of requirements (i.e.. eliminate redundant requiremnts).
• Find sets of requirements relating to a particular topic.
• Detect omissions, duplications and inconsistencies.
• Eliminate conflicts among requirements.

Telelogic DOORS (...used across GE businesses; LM Aerospace)

Telelogic DOORS is an Enterprise requirements managment system.

Figure 16. Representation of Requirements in DOORS

DOORS does not explicitly support system viewpoints.

Case Study Application: Lockheed Martin Aerospace, Ft. Worth, TX

Joint Strike Fighter Project. 30 year duration. Budget $200 Billion.
Lockheed is unveiling a new, four-pronged architecture:

• A development configuration management tool (from Merant);
• DOORS requirements management tool (from Telelogic);
• A homegrown interface management tool; and
• Microsoft Office for documentation.

SLATE (System Level Tool for Enterprises) (...used by NASA Goddard; Northrop Grumman)

An application is modeled as a network of connected requirements and design abstraction hierarchies.

Traceablity Links and Translational Mappings (TRAMs)

Relationships define connectivity between requirements and abstraction blocks in the design hierarchy.

Translational Mappings (TRAMs) define relationships between different system abstraction block hierarchies. TRAMs allow for cause-and-effect relationships among "design disciplines" to be modeled.

Sample Screendumps

Example 1. A screen of requirements ....

Figure 17. Representation of Requirements in SLATE.

Example 1. An abstraction block hierarchy with translational mappings among (TRAMs) viewpoints.

Figure 18. Representation of Abstraction Block Hierarchy and Translational Mappings (TRAMs) in SLATE.

Critical Assessment of Present-Day Systems Engineering Tools (e.g., DOORS and SLATE).

Lessons Learned from Industry

1. Support for Team Development
   DOORS and SLATE both support a top-down approach to systems development. Tools for integrating the work of separate teams is missing.
2. Visualization
   DOORS and SLATE do not support domain-specific visualization of engineering systems. Now that Javascript and XSLT are here, this limitation can be mitigated.
3. Process
   DOORS and SLATE are designed to be process-independent tools -- that is, a company supposedly use the tool to enhance any high-level systems engineering process.
   Company training procedures focus on step-by-step procedures for low-level tasks. In practice, many employees have great difficulty in scheduling these low-level tasks to match organizational processes.

Specific Limitations of Present-Day Tools (Selberg, 2002)

Figure 19. Requirements Engineering WBS and Industry Toolset Weakensses. (For details, see Ramesh and Jarke, 2001)

1. Thick Descriptions.
   Current tools lack the ability to store informal representations (i.e., so-called thick descriptions) of systems conveying information along subtle or implied lines.
2. Model Driven Trace Capture and Usage.
   Current tools lack mechansms for "easy linking" of models into the design environment (e.g., SLATE).
3. Abstraction Mechanisms.
   Current tools lack the ability to search and explore requirements at various levels of abstraction.
4. Inference Services.
   The lack of "inference services" in the work breakdown structure impacts the systems engineering process in several ways. Current tools are incapable of analyzing requirements for completeness or consistency. Search mechanisms are limited to keywords, which can be limiting for custom jargon in multidisciplinary and multilingual projects.

System of Systems

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

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

Management and Communication Styles for System-of-Systems

There are three management styles which influence the communication style: coerced (directed), collaborative, and chaotic (virtual) (Maier, 1999; Maier, 2000).

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

2. Collaborative Systems of Systems

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

   Example -- Transportation Services at an Airport

   

   Here the "taxi" and "airplane" systems work together to provide a chain of services neither could provide by themselves. Airports provide the appropriate interfaces to these systems.

3. Chaotic Systems of Systems

   Chaotic (or virtual) systems of systems have no management structure.

   Examples -- The Internet and Open Source Software Development

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

   

   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.

Requirements Engineering

Monolithic Model of Requirements Engineering

A requirements management system, one which is concerned with the creation and use of the requirements for a given project, can be implemented as a monolithic system.

Chaotic System of Systems Model of Requirements Engineering

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.

The chaotic system of systems is a more appropriate model because every project, company, and industry 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.

Research Approach

These are very similar tasks faced by the Internet. It is therefore a reasonable approach to compare the needs of a requirements engineering system to the Internet and look for solutions along parallel lines of thought.

Objectives of the Semantic Web

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

The Semantic Web is an extension of the current web. It aims to:

• Give information a well-defined meaning, thereby creating a pathway for machine-to-machine communication and automated serives based on descriptions of semantics.

Modeling

The Semantic Web Layer Cake

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

The Semantic Web is an extension of the current web. URIs are just links in today's web. Unicode is 16-bit representation of (multilingual) characters. XML files and web resources capture objects and classes. XML separates structure from presentation. XML assumes data/information can be represented in hierarchies. 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. RDF represents data/information in graphs. Ontologies provide a formal conceptualization (semantic representation) of a particular domain shared by a group of people. Languages include: Darpa Agent Markup Language (DAML) and Web Ontology Language (OWL). The logic layer allows for reasoning. Languages include: RuleML. Reasoning tools include Jess and MANDARAX. Ontology-based applications will be built on top of the Semantic Web infrastructure (i.e., XML, RDF and ontologies)

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

Today's search engines rely on "keywords."

Suppose that we could represent facts on the web.

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

And suppose that the (ontology) conceptualization of this domain 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."

With these facts and concepts 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).

Key Observation

• Systems engineering development processes (e.g., requirements engineering) and the Semamtic Web are both "chaotic systems-of-systems."
• Maybe systems engineering methodologies and tools can benefit from advances in Semamtic Web Technology!

Transfer of Semantic Web Technologies to Tools for Requirements Engineering

What is the minimum level of Semantic Web Technology that can mitigate (and hopefully overcome) limitations in present-day tools?

Figure 21. Requirements Engineering WBS (Create Branch) to Semantic Layer Cake (Selberg, 2002).

Figure 22. Requirements Engineering WBS (Use Branch) to Semantic Layer Cake (Selberg, 2002).

Anticipated Challenges and Trade-Offs in Design

In figuring out how "requirements engineering" methodologies and tools can benefit from Semantic Web technologies, it is likely that we have to deal to some interesting trade-offs in the capabilities of technologies:

• Present-day search engines are capable of finding answers to searches that cover a huge part of the web (excluding the content of databases). There is no notion of correctness in the answers.

• Present-day logic engines have the capability of restricting their output to information that is known to be correct, but are currently incapable of wandering through masses of interwined data to construct valid answers. The process of dealing with the combinatorial explosion of possibilities that need to be traced is quite intractable.

A key question is: can we get the best of both worlds and apply these techniques to a new generation of "requirements engineering" tools?

Figure 23. Advancing Requirements Engineering with Semantic Web Technologies.

Participants: Natasha Kositsyna, Mark Austin.
Support: NSF, Northrop Grumman, GE Research and Development.

Motivation -- Lessons Learned from Training Classes at Company XYZ (in 1999-2000)

Ideally, systems engineering training activities should mirror those of the practising systems engineer. This is hard!!!

• Systems engineering is a team activity -- training needs to support multiple viewpoints, levels of experience, and backgrounds.

• Systems engineering processes make use of many different entity types (e.g., primary and derived requirements; traceability links; various models of system behavior and system structure), sometimes connected in complicated ways.

• Training materials are linear -- but systems concepts are best organized into a variety of architectures. See the adjacent figure.
  

  Figure 24. Architecture of Training Material Contents

• Too many pages! Too many links! Readers feel overwhelmed. They jump around material and gloss over content rather than learning it.

• Students need to see how new systems engineering concepts can be applied to applications they are familiar with. (i.e., if you're at a company that makes trains, you need a case study on trains).

  Challenge
  We need to find ways of using web technology to enhance quality of learning. Otherwise, whole exercise is a waste of time.

XML Document to Application Pathway

The eXtended markup language (XML) is a metalanguage -- that is, a language for describing other languages -- that allows people and computers to search for and exchange scientific, engineering and business data/information.

Phase 1. Explore feasibility of XML to Java Applet Pathway (Sep't 1999 - August 2000)

Design XML vocabulary, tag set structure for markup of diagrams and diagram pathways, and XML-to-Java source code compiler.

Figure 25. XML to Java Applet Pathway

The step-by-step development procedures is as follows:

1. Design XML tagset and allowable hierarchy for combination of tags.
2. Design a data type definition (DTD) file (or XML schema file).
3. Create parser to transform XML document into (internal) tree structure.
4. Develop application code to travserse tree structure and generate application-specific output (in our case, this will be Java source code).

JaDia Markup Language The JaDia Markup Language has 12 elements: <chart> <graph> <edge> <node> <frame> <framenode> <path> <pathedge> <link> <hint> <image> <text>

Figure 26. Components of the JaDia Markup Language

Phase 2 : Develop Platform-Independent Diagram Editor (June, 2001 -- present)

Create a click-and-drop editor for development of "Collections of Java-Enabled Diagrams." knowledge capture for systems engineering is enabled through:

• Diagram annotation features,
• Links to heterogenous data and information sources on the web, and
• File and database storage.

We are currently working on the right-hand side of this diagram. Future versions of the editor will import of XML representations of diagrams, requirements, and systems stored in commerical databases (e.g., Oracle).

Screendumps from Drag-and-Drop Editor

Figure 28. Drag-and-Drop Editor and Property Window

Participants: Scott Selberg, Mark Austin.

Problem Statement

State-of-the-Art Systems Engineering tools have graphical user interfaces that are very poorly designed and nonintuitive. Systems engineers should be able to look at trees of requiremnts and engineering schematics and indenify mapping and traceability relations among them.

The purpose of this project is to explore the extent to which XML and RDF technologies (i.e., SVG, Javascript, cascading stylesheets) can improve the human-computer interface.

XML Separates Content from Presentation

The eXtended markup language (XML) is a metalanguage -- that is, a language for describing other languages -- that allows people and computers to search for and exchange scientific, engineering and business data/information.

Web page content is separated from presentation -- applications decide how the data will be displayed.

Figure 29. XML Portability Model

XML allows for custom interpretation of data sets (write once, publish anywhere).

Traceability Viewer Model

Figure 30. Traceability Viewer Model

XML/RDF Datafile for Requirements

As an example, the top level requirement, Time Reference, is shown below.

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="requirement.xsl"?>

<requirement id="TimeReference.req.xml"
        xmlns:="http://www.isr.umd.edu/~selberg"
        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

    <description>
        A physical device which displays a signal at regular frequency.      
    </description>

    <need>
        For a performing musician it can often be difficult to sustain a constant
        beat.  This is especially true when the music is complex, or very slow
        and sustained.  A physical time reference allows the musician to train
        his or her internal clock to a higher degree of precision.
    </need>

    <rdf:RDF>
    <rdf:Description about="TimeReference.req.xml">
        <refined_by>
            <rdf:Description about="AuditorySignal.req.xml"/>
            <rdf:Description about="AdjustableFrequency.req.xml"/>
        </refined_by>
        <satisfied_by>
            <rdf:Description about="Metronome.com.xml"/>
        </satisfied_by> 
    </rdf:Description>
    </rdf:RDF>

    <history>
       <entry timestamp="12:38:03 PM 3/2/02">
              Created Requirement
       </entry>
    </history>
</requirement>

Notice that each of the basic categories (i.e., not the RDF links) simply contain text. The RDF section is the core of the linking. The rdf:Description block identifies the subject of the RDF statement. Beneath it are two property arcs: refined_by and satisfied_by. These arcs then point to the subject objects.

Requirements Traceability for Design of a Metronome

Figure 31. Requirements Traceability for Design of a Metronome

Participants: Vimal Mayank, Mark Austin, Natasha Kositsyna, Dave Everett (NASA Goddard)
Support: NSF, NASA Goddard Space Flight Center.

Project Objectives

Methodologies for the team development of system-level architectures need to support the following activities:

• Partitioning of the design problem into several levels of abstraction and viewpoints suitable for concurrent development by design teams;
• Synthesis of good design alternatives from modular components;
• Integration of the design team efforts into a working system; and
• Evaluation mechanisms that provide a designer with critical feedback on the feasibility of a system architecture, and make suggestions for design concept enhancement.

The purpose of this project is to develop methodologies and tools for the synthesis, management, and visualization of system-level architectures likely to be found in the NASA Global Precipitation Measurement (GPM) project. The research and development will leverage advances in the Semantic Web.

Two Simple Examples

We view system architectures as collections of modules, connectors, and rules for system assembly.

Figure 32. Synthesis of System Architectures Supported by Product Descriptions on Web

More complicated subsystems will be modeled graphs.

Figure 33. Simplified Assembly of System Architectures via Merging of Graphs.

We need to be able to merge graph models and remove inconsistencies among viewpoints.

Study Problem -- Architecture-Level Synthesis and Analysis of a Home Theatre System

We would like to create and interactive design environment where the specifications for components are found on the web.

Figure 34. Synthesis of System Architectures Supported by Product Descriptions on Web

Figure 34 shows a simple scenario:

• We are assembling a home theatre system using descriptions of the components and their capabilities located at the vendor web sites. Component specifications will basically say "...if you supply a required set of inputs, then the component will gurantee a minimum level of performance (output).

A system design tool should:

• Contain mechanisms for controlled visualization of complex system structures.
• Provide for automatic processing of "appropriate" requirements. Evaluation mechanisms should provide the designer with critical feedback on the feasibility and correctness of the system architecture.
• Support management and integration of design team efforts from different domains into an integrated system description.

Top-Down System-Level Development Coupled with Component Reuse

Design Goal
I need a home theatre system.

Operations Concept
Our wishes are very modest -- we will simply watch movies on a large size theatre screen and high fidelity audio system.

Figure 35. Flowdown of Requirements to a Detailed System Architecture Description.

Pathway from High-Level Requirements to Component-Level Requirements

Research questions to be answered:

• We need templates for structuring/writing requiremnts in a way enables precise parsing and interpretation of their content. How to do this?

Representation of System Architecture

The system architecture is the structure of the pieces that make up a system, including the resposibilities of the pieces and their interconnection.

Research questions to be answered:

• What is an appropriate symbolic representation for the system architecture?
• Can we use (or easily adapt) an architecture description language (ADL) that has already been developed?

System Structure
Here is a first-cut implementation of entities making up the system structure.

Figure 36. UML Model of the System Architecture.

Port capability -- services required and services provided -- is described by an interface specification.

Port Model
And here is a preliminary port model.

Figure 37. UML Model of Ports, Port Connectors, and Port Geometry.

Bottom-up Implementation of the System (without trade-off among subsystem attributes).

To start with, let's assume that trade-off of attributes (e.g., cost) among the system components does not occur. The step-by-step implementation might proceed as follows:

Step 1. Selection of the Amplifier.

Figure 38. Assembly of the System Architecture. Choosing the Amplifier.

Step 2. Selection of the Speakers.

Figure 39. Assembly of the System Architecture. Choosing the Speakers.

Bottom-up Implementation of the System (with trade-off)

Step 1. Selection of the Amplifier.

Figure 40. Assembly of the System Architecture. Choosing the Speakers.

Step 2. Selection of the Speakers.

Figure 41. Assembly of the System Architecture. Choosing the Speakers.

Semi-Formal Representation for Requirements

We assume that "some requirements" can be expressed in a template format. For example:

    The
        <subject> 
    of the
        <object> 
    shall be
        <constraintt>. 

The requirement:

    The "price" of the "amplifier system" shall be < US $400.00

The corresponding markup in XML might look like:

    <requirement>
        <template>    1 </template>
        <subject> price </subject>
        <object> amplifier system </object>
        <constraint>
            <mathML>
                less than 400
            </mathML>
        </constraint>
    </requirement>

Attaching Specifications to Objects/Components

An object-specification pair defines a set of behaviors can be offered by a component/object.

Figure 42. Elements of an Object-Specification Pair.

Object/component descriptions must be at least multi-input multi-output (MIMO). Otherwise they aren't useful.

Research
Research questions to be answered:

• Input and output.
  How to use XML/RDF to model ports, port attributes, and flows (e.g., signals, energy) to varying levels of complexity?
  How to design a hierarchy of port classes?
  
• Pre- and post-conditions.
  How to XML/RDF to model pre- and post-conditions for object/module use? We'd like to write these rules in a manner that enables tools like Jess and MANDARAX to evaluate compatibility of pre- and post-conditions.
• Interface specification.
  An interface specification precisely defines what a component that offers an interface must do, and what a client of that interface can expect (i.e., the list of allowwable operations is defined by an underlying information model). The specification consists of the following parts:
  • The interface type itself.
  • The information model -- that is, the attributes and association roles of the interface, and their types.
  • The operation specifications -- pre- and post-consitions.

Logical Checking of Requirements

Issue:

• Difficulty in identifying two requirements that are many pages apart and are in conflict.
• Low productivity due to manual checking of requirements against interfacing components in the system structure.

Proposed Solution:

• Design a formal language framework to describe system requirements and specifications. An implementation in XML and RDF would work.
• Identifying and eliminating conflicting requirements through automated processing.
• Evaluating and reusing components across different projects by importing them from a component repository.

Simple Example: Connecting a Digital Camera to a Computer

Figure 43. Synthesis of System Assemblies Accompanied by Logical Checking of Requirements.

Requirements:

• On the computer cbject
  • Camera connects through a USB port ....
• On the camera object
  • Computer should have a vacant USM slot.
  • Driver has to be installed on the computer for the camera to function.
• Overall requirements of this small subsystem:
  • Camera resolution needs to be > 2.1 MP.
  • Camera price should be < US $1,500.
  • Computer clock speed > 100 MHz.

Complexity and System Levels

Issue:

• Due to the large number of components in many engineering systems, viewing and comprehending the entire system is impossible.

Proposed Solution:

• Decomposition of complex systems into hierarchies enables subsystems to be isolated and studied independently.
• Customized visualization of the subsystem structure facilitates this decomposition.

Ensuring Consistency Across Different System Viewpoints

Issue:

• Lack of formalization and associated automation forces manual update of subsystem views when there is a change in the system structure.

Proposed Solution:

• Tracking modifications in the system structure by extracting the connectivity information from its XML/RDF representation.

Figure 44. Viewpoints of a Home Theatre System.

Expected Benefits

• Better abstraction, encapsulation and definition of the system and its components.
• Ability to make informal decisions to "buy or build" component by configuration management.
• Improved productivity in assembling the system from components with well defined specifications.
• Seamless synchronization at various levels of abstraction due to consistent multi-disipline views of the system.

Conclusion

• We have a created a framework for next-generation systems engineering methodology and web-based tool capability.

Further Issues .....

But we still need to:

• Formulate a framework for writing a broad range of requirements that can be parsed into components.
• Develop a processing pathway from "requirements components" to "web-based reasoning" (e.g., via Jess or Mandarax).
• Build a graph-based model for requirements representation and management, coupled with appropriate models for requirements-design traceability.
• Better understand how synthesis with "early real-time rule checking" should work for problems having a strong spatial component.

Important Applications ...

• Layout of facilities and networks in buildings. Applications include: furniture layout; sensor networks for security, environmental control, ... etc.
  

  Figure 45. Version 0.0001 of our Sensor Network Layout Editor. (April, 2003)
  (Source: Vijay Krishnamuthy, MSSE Student)

• Layout of network facilities in geographical domains. Applications include power grids; water facilities; communications ... etc.

1. NASA's Global Precipitation Measurement (GPM) Project Home Page.
2. Adams J., "GPM Global Precipitation Measurement -- Planning for Global Precipitation Measurement," IGARSS2001 -- International Geoscience and Remote Sensing Symposium, Paper 357, Sydney, Australia, July, 2001.
3. Everett D., "GPM Global Precipitation Measurement -- Satellites, Orbits, Coverage," NASA Goddard Space Flight Center, May 2001.
4. Karpinski R., Managing Code on a Massive Scale , INTERNET WEEK, May 14, 2002.
5. Maier M.W., "Architecting Principles for Systems of Systems," Systems Engineering, 1999.
6. Maier M.W., Rechtin E., The Art of Systems Architecting, 2nd Edition, CRC Press, London, 2000.
7. Ramesh B., and Jarke M., "Toward Reference Models for Requirements Traceability," IEEE Transactions on Software Engineering, Vol. 27., No. 1., January 2001, pp. 58-93.
8. Sampson M.E., "Web-based Requirement Management and Regulatory Tracking. People, Teams, and Systems", Proceedings of the Eighth Annual International Symposium of the International Council on Systems Engineering (INCOSE), 1998.
9. Selberg S., "Systems of Systems," Term Project for ENSE 621: Systems Engineering Principles, University of Maryland, College Park, MD, November 30, 2000
10. Selberg S., "Requirements Engineering and the Semantic Web," M.S. Thesis, Institute for Systems Research, University of Maryland, College Park, MD 20742, April 2002.
11. Telelogic Telelogic DOORS (DOORS), Telelogic Corporation.
12. System Level Tool for Enterprises (SLATE), Electronic Data Systems, Plano, TX.

Copyright © 2003, Mark Austin, University of Maryland.