Synthesis of Radar System Architectures from Reusable Component-Specifications

Research and Development in Systems Engineering at UMCP

Synthesis of Radar System Architectures from Reusable Component-Specifications
By: Mark Austin, Natasha Kositsyna, Vimal Mayank (...with help from Jeff Coriale)

Table of Contents Contact Information and Project Participants

Bottom-Up Synthesis of Engineering Systems, enhanced with Component Reuse
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

Formulation of Reusable Component-Specification Pairs

Writing Requirements and Specifications
Attaching Specifications to Objects and Components

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.

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

Figure 1 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. We envision a library (XML database) of object-specification descriptions.

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

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.

Requirements	Specifications
Initial requirements tend to be "qualitative" statements. Unfortunately, often they are informal, incomplete, and ambiguous.	Specifications tend to be "quantitative" statements that are based upon a detailed knowledge of a product and its (required or established) capabilities...
The system should .... The system must ....	The system (input) requirements are .... The system (output) capabilities are .... You'll need to make sure .....
Natural language sentences.	Pseudo-code. Technical sentences (e.g., written in BNF). UML-like class diagrams for system structure. UML-like FSM/statechart and activity diagrams for system behavior. Equations, charts, tables ..... Design rules .....
Validation of requirements supported by traceability to specifications and design subsystems/objects.	Verification of specifications supported by formal testing procedures, numerical simulations of system behavior, experiments in the lab ... etc.

Table 1. Comparison of Requirements and Specifications

Our Strategy for Requirements Engineering Research

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

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

[Systems of systems of Requirements]
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

Compare the needs of a requirements engineering system to the
Internet and look for solutions along parallel lines of thought.

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 2. The Semantic Web Layer Cake (Berners-Lee, 2002).

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.
XML files and web resources capture objects and classes. XML separates structure from presentation.
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.
Ontologies provide a formal conceptualization (semantic representation) of a particular domain shared by a group of people.
Ontology-based applications will be built on top of the Semantic Web infrastructure (i.e., XML, RDF and ontologies)

Case Study: Architecture-Level Development of a Pulse-Doppler Radar System

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 3. Flowdown of Requirements to System Architecture for Pulse-Doppler Radar. Reuse of System Components.

Bottom-Up System Synthesis Enabled by Reusable Component-Specifications

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

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

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

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?

Formulation of Reusable Component-Specification Pairs

Attaching Specifications to Objects and Components

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

Figure 5. Elements of an Object-Specification Pair

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

Long Term 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?
Engineering constraints -- convervation of flow, energy, force?
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.
Information Model
An abstract definition of any information or state that is retained between client requests by an object supporting the interfaces and any constraints on that information. (persistence).

Plan of Work

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 6. Formulation of Sensor-Specification Pairs

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

XML Database and Graphical Frontend

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

Figure 7. 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?

References

Selberg S., "Requirements Engineering and the Semantic Web," M.S. Thesis, Institute for Systems Research, University of Maryland, College Park, MD 20742, April 2002.
Stimson G.W., Introduction to Airbourne Radar , Second Edition, SciTech Publishers Inc, 1998.

Synthesis of Radar System Architectures from Reusable Component-Specifications By: Mark Austin, Natasha Kositsyna, Vimal Mayank (...with help from Jeff Coriale)
Table of Contents	Contact Information and Project Participants

Bottom-Up Synthesis of Engineering Systems, enhanced with Component Reuse 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 Formulation of Reusable Component-Specification Pairs Writing Requirements and Specifications Attaching Specifications to Objects and Components 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.