Synthesis of Radar System Architectures from Reusable Component-Specifications By: Mark Austin (...with help from Natasha Kositsyna, Vimal Mayank, and Jeff Coriale)
Table of Contents	Contact Information and Project Participants
Top-Down and Bottom-Up Approaches to Architecture-Level Development Top-Down Decomposition: Pathway from Requirements to System Architectures Bottom-Up Synthesis of Engineering Systems, enhanced with Component Reuse Capability of Present-Day Requirements Management Tools Our Strategy for Requirements Engineering Research Systems of Systems Requirements Management Systems are Systems of Systems Research Approach Second Generation Semantic Web Architecture-Level Development of a Pulse-Doppler Radar System Top-Down System-Level Development Bottom-Up System Synthesis Enabled by Reusable Component-Specifications Reusable Component-Specification Pairs Attaching Specifications to Objects and Components Writing Requirements and Specifications Research and Development Issues Plan of Work Formulation of Sensor-Specification Descriptions XML Database and Graphical Frontend	Institute for Systems Research, University of Maryland, College Park, MD 20742. Mark's e-mail: austin@isr.umd.edu Natasha's e-mail: kosnat@isr.umd.edu Vimal's e-mail: vmayank@isr.umd.edu Jeff's e-mail: coriale@isr.umd.edu Current Industry Participants: Lockheed Martin, NASA Goddard Space Flight Center, Battelle.

Top-Down Decomposition: Pathway from Requirements to System Architectures

We promote "Systems Engineering Development Procedures" that employ formal design/requirements representations connected by mappings and traceability. A simplified view of systems-level development is as follows:

Figure 1. Traceability Mappings for the Development Pathway, Goals/Scenarios through System Evaluation.

Points to note:

• Traceability begins with the connnection of goals and scenarios to use cases. Traceability links the requirements and specifications with performance attributes/functions characterising system behavior, objects and attributes in the system structure, and procedures for system evaluation.

  Requirements also flowdown (and are traceable) to the subsystem levels.

• Models of system behavior specify the system functionality (i.e., what it will actually do ...). Usually, behavior can be represented networks and hierachies of tasks, functions and processes. Behavior is evaluated via attributes of performance.

• The system structure corresponds to collections of interconnected objects and subsystems, constrained by the environment within which the system must exist. The nature of each object/subsystem will be captured by its "attributes."

• In our design methodology, descriptions of system behavior are independent of their implemenation in the system structure.

  We expect, however, that selection of a suitable system structure/architecture will be guided by the details of required behavior. Suppose, for example, when large chunks of behavior can occur concurrently, a system structure that will support parallel execution of tasks is appropriate.

• We create the system-level design by mapping fragments of system behavior onto specific subsystems/objects in the system structure. Thus, the behavior-to-structure mapping defines the functional responsiblity of each subsystem/component.

• Cost, reliablilty, performance, and time-to-market are all factors that can infludence the system evaluation.

  We verify that the system structure connecitivity is consistent with the flows of data/information defined in the models of system behavior. We also check that system-level timing requirements can be met by the proposed sequences of tasks and mappings to objects/subsystems.

• The "system-level specification" is a detailed description of the system's capabilties.

Bottom-Up Synthesis of Engineering Systems, enhanced with Component Reuse

Bottom-up synthesis of engineering systems from reusable components is a key enabler of enhanced business productivity (i.e., shorter time-to-market with fewer errors) and return on investment (ROI).

Figure 2 shows elements of a top-down/breadth first development (decomposition) followed by a bottom-up implemenation procedure (composition). In the latter half, a key design decision is: should we custom build new components or buy/reuse them.

Figure 2. Elements of Top-down and Bottom-Up Development coupled with Component Reuse

Points to note:

• Reusable components reduce development costs and shorten the time-to-market.

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

• The key research question is: "how do we describe the reusable component and its capabilities?"

We envision a library (XML database) of object-specification descriptions.

Present-Day Requirements Management Tools

Present-day requirements management tools (e.g., SLATE, DOORS) claim to be process independent. But!!!

• They provide the best support for top-down development where the focus is on requirements representation, requirements traceability, and allocation of requirements to system abstraction blocks.

• Computational support for the bottom-up synthesis of systems from components is poor. This problem is more difficult.
  

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

  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.

  A minimal implementation would check groups of requirements for logical consistency and compatibility.

Systems of Systems

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

Chaotic Systems of Systems

Chaotic (or virtual) systems of systems do not have a centralised 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.

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 eminate from external sources (e.g., the EPA may manadate that a system must satisfy certain environmental regulations).

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

Points to note:

• High-level project requirements are partitioned into groups of requiremnts 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.

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.

Our Research Approach

Second Generation 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.

Modeling

The Semantic Web Layer Cake

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

The Semantic Web is an extension of the current web.

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

2. XML files and web resources capture objects and classes. XML separates structure from presentation.

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

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

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

System-level design of a pulse-doppler radar system requires top-down decompositions of goals into layers of requirements, followed by a bottom-up implementation of the system from theatre components.

Design Goal
I need a pulse-doppler radar system.

Operations Concept
The pulse-doppler radar system will detect small aircraft at long ranges, even when their echoes are buried in strong ground clutter (Stimson, 1998).

Our long-term development objective is to create an interactive design environment where the specifications for system components are found online. Component specifications will basically say "...if you supply a required set of inputs, then the component will gurantee a minimum level of performance (output).

Top-Down System-Level Development

The flowdown of requirements to the system architecture might be as follows:

Figure 6. Flowdown of Requirements to System Architecture for Pulse-Doppler Radar. Reuse of System Components.

Points to note:

• System cost is proportional to power requirements, antenna gain, signal processors ...

• Design driven by "radar range" equations and trade-off among terms (e.g., transmitter power vs. antenna gain).

• High-level requirements on performance (i.e., ability to sense unambiguous range and velocity) and cost (i.e., max allowable cost) flow down to major subsystems.

Bottom-Up System Synthesis Enabled by Reusable Component-Specifications

Now we can implement the system economically via reusable component specifications.

Figure 7. System Synthesis Enabled by Reusable System-Component Specifications.

Points to note:

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

• Now suppose that a component is "almost" compatible with a partially assembled system. We need formal procedures for studying trade-offs among component selections. (This is outside our immediate scope!!!).

Generation and Evaluation of Design Alternatives

Clearly, design alternative 1 is inferior to design alternative 4. Design alternative 6 is infeasible because it exceeds the cost constraint.

Research Questions to be Answered

• We need a formal language to describe system assemblies. We will start with a system-port model for the architecture-level description of modules.
• We need templates for structuring/writing requiremnts and specifications in a way enables parsing and interpretation of their content. What role can UML and XML and RDF play?

Attaching Specifications to Objects and Components

An object-specification pair defines a set of behaviors can be offered by a component/object. Object/component descriptions must be at least multi-input multi-output (MIMO). Otherwise they aren't useful.

Figure 8. Elements of an Object-Specification Pair

Interface Specification

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.

Figure 9. Role of Pre- and Post-Conditions in Contract for Object Usage
(Source: Newton A.R., "Notes on Interface-Based Design," EECS, UC Berkeley).

Networks of interacting/communicating objects having a larger purpose/functionality can be synthesized by stitching together objects that have compatibly I/O requirements and pre- and post-conditions.

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.

Sample Requirements Document -- Implemented in XML

We are designing an XML/RDF tagset for a family of "requirements templates." For the pulse-doppler radar system, implementation of the tagset might look something like:

     <?xml version="1.0" encoding="UTF-8" ?> 
     <!--  Requirement for a Pulse-Doppler Radar System --> 

     <Project file="radarsystem.xml"> 

     <ToBeChecked Value="false"> 
     <Requirement ID="SYS.REQ.1"> 
        <Name>         System Description        </Name>
        <Rationale>    Overall System Objective  </Rationale>
        <Verification> User Input                </Verification>
        <Comment> No comments </Comment>
        <Revision Month="4" Date="8" Year="2003" />
        <Mappedto> Signal Processing Unit </Mappedto>
        <Template No="-1" />
        <Description> I need a Pulse-Doppler Radar System. </Description>
     </Requirement> 

     <Requirement ID="SYS.REQ.2"> 
        <Name>         Total System Cost                     </Name>
        <Rationale>    Overall Cost Objective of the system  </Rationale>
        <Verification> Add the sum of the components of the system.  </Verification>
        <Comment> No comments </Comment>
        <Revision Month="4" Date="8" Year="2003" />
        <Mappedto> null </Mappedto>
        <Template No="-1" />
        <Description> The total cost must be less than or equal to USD $8,000,000 </Description>
     </Requirement> 

     ..... etc ..... 

An Open Question

System-level design methods for embedded systems assemble system structures from IP (Intellectual Property) blocks. The IP block manufacturer needs to describe functionality of the block in sufficient detail to:

• Enable its use.
• Not reveal the IP elements of the block.

At the same time, the embedded system designer needs to check that the system will actually work and that no unintended subsystem interactions occur.

At this time, a precise methodology for resolving these conflicting criteria does not exist.

Research and Development Issues

Object/component-specification pairs are the basic building block in an interconnect design methodology (Newton, 2002). We need to understand:

• 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?
  How to model engineering and physical constraints -- convervation of flow, energy, force?

• Pre- and Post-Conditions
  How to use 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.

• Design of "Component Blocks" and Glue Logic
  How much functionality of the "component blocks" needs to be known in order for: (1) the glue logic to work, and (2) system-level verification procedures to work?

As a starting point, we envision an XML database containing collections of object-specification pairs and a graphical frontend for querying the database and graphically displaying the relevant contents.

Formulation of Sensor-Specification Pairs

We will work with NG to develop a framework for describing sensor-specification pairs.

Figure 10. Formulation of Sensor-Specification Pairs

We anticipate that sensor-specification pairs (see Figure 8) will be written in XML and RDF.

XML Database and Graphical Frontend

We will develop an XML database of sensor-specification pairs.

Figure 11. Architecture of XML database and graphical frontend.

Research questions to be answered:

• How to search/browse the database and graphically display object-specifications?
• Is it possible to completely separate the object-specification description (XML, RDF, SVG) from functionality of the graphical frontend?

1. 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.
2. Selberg S., "Requirements Engineering and the Semantic Web," M.S. Thesis, Institute for Systems Research, University of Maryland, College Park, MD 20742, April 2002.
3. Stimson G.W., Introduction to Airbourne Radar , Second Edition, SciTech Publishers Inc, 1998.

Copyright © 2003, Mark Austin, All rights reserved. The contents of this talk may not be reproduced without expressed written permission of Mark Austin.