The System design process encompasses the following steps:

• Extract customer requirements from source documents using either RDD-100 or RTM as the requirements tool.
• Perform requirements engineering management/clarification/traceability using the selected requirements tool. Define keywords, rules and relationships. Expand/focus requirements for testability and verification while maintaining an audit trail.
• Export data (requirements, relationships, etc.) to RDD-100 if RTM is used as the requirements tool. One-to-one mapping of elements between RDD-100 and RTM is required. This initial baseline for requirements analysis can be maintained in RTM for tracking purposes.
• Use RDD-100 in conjunction with BONeS, SPW, and MATLAB to perform System Definition, Functional Analysis, Functional Allocation, Interface Design, scenario development, thread analysis, etc. Derived requirements will be identified.
• Derived requirements along with functional allocations will be exported back to RTM to maintain traceability throughout the program lifecycle if RTM is used as the requirements tool.
• RDD-100 will export data which requires detailed simulation, performance verification, and architectural tradeoffs to BONeS. Traceability is maintained in RTM if RTM is used as the requirements tool.
• RDD-100 will generate system and subsystem specifications, SSDD, ICD's, etc. in Interleaf.

The RASSP Baseline 2 Systems design toolset includes:

• RTM (Requirements and Traceability Management) from Marconi Systems is used as the requirements traceability tool throughout a program's engineering life cycle.
• RDD-100 (Requirements Driven Development) from Ascent Logic is used to capture system requirements, perform functional decomposition, model system behavior, allocate requirements to components, and generate systems engineering documentation.
• BONeS (Block Oriented Network Simulator) from Alta Group is used to perform token-based high-level system simulation, such as modeling network traffic, and is used to obtain detailed performance metrics early in the system design.
• PRICE S/M/H/HL from Lockheed Martin PRICE Systems is used for computer-aided parametric cost estimating and enables life-cycle cost analysis throughout the design process.
• RAM/ILS from MSI enables feedback on reliability, availability, maintainability, and integrated logistics to support early tradeoff analyses.
• GEDAE™ from Lockheed Martin ATL is a graphical programming and autocoding environment.
• MATLAB from Mathworks for algorithm development and numerical analysis.
• SPW from Alta Group for algorithm development.
• The Component and Library Management System (Explore (CLMS)) from Aspect is an object-oriented extension to the existing commercially-available Component Information System (CIS) product that forms the basis of the design reuse library.

The RASSP Baseline 2 Systems engineering tools are depicted in Figure 2.2-1.

Requirements and Traceability Management (RTM) provides the tools necessary to manipulate original customer system requirements specifications into a clear and unambiguous set of requirements to control design, implementation and testing. See Figure 2.2-2. Whenever a requirement is altered, a record is kept so that it is always possible to trace the evolution of a requirement back to its source. At this point in the requirement engineering process it is possible to rebuild the source (customer) document exchanging the original requirements with their successors. Ultimately this allows an updated requirements document to be published to the customer in a format compatible with his original source document, thus facilitating review and authorization of requirement statements towards an approved requirement baseline.

RTM allows requirements to use indexed by keywords (e.g., performance, weight, power consumption, etc.) thereby allowing the user to obtain lists of related requirements. When requirements are extracted from a customer source document (multiple source documents are allowed), the RTM system associates various pieces of information with it. Some of this information is supplied by the system, some by the user. On extraction, the system always associates a unique number (called the key) with a requirement together with the date of extraction, the name of the source document and the name of the user performing the extraction. The system also associates a life cycle status with the requirement. This reflects how a requirement has been altered, if at all. A date and user name are stored for the most recent alteration to a requirement. As mentioned previously, links are maintained between requirements and their successors. These are all updated automatically by the system. The user is able to state attributes for the requirements. An attribute describes a characteristic of a requirement, e.g., its type, its level of acceptance, etc. Additional features of RTM are given below.

• Requirements Stripper Tool - This tool is used to extract requirements from the source document. The remnant of the source document is stored for use later when rebuilding the document. As each requirement is extracted, the user optionally enters a paragraph identifier (paragraph ID) and attribute values as appropriate. The paragraph ID is a type of index to indicate the original position in the document of the requirement.
• Requirement Focus Tool - This tool is used to combine requirements with similar meaning, so that a single consistent version can be maintained. When there are several source documents, there may be several duplicated requirements, possibly with similar wording. The tool may also be used to alter or enter clarification and query text, e.g., to justify the focusing of these requirements together.
• Requirement Expansion Tool - The Requirement Expansion tool is the opposite of the Focus tool. It allows extracted requirements to be split into several expansion (substitute) requirements. It is used when a requirement from a source (spec., RFP, etc.) encompasses a number of individual requirements. Splitting the compound requirement allows each of the constituents to have its own set of attributes, and to be mapped to the most appropriate part of the design process. Clarification and query text may be entered and altered for the requirements.
• Requirement Editor Tool - The Requirement Editor tool provides the remaining functions essential for requirement alteration. The editor makes it possible to mark a requirement as deleted (i.e., that it is redundant, no longer required). A requirement may be changed and replaced. To correct errors, derived requirements (i.e., not directly extracted from the source document) may be deleted from the Project Database. Clarification and Query text may be entered and altered for the requirements.
• Keyword Editor Tool - This tool performs the task of "grouping" requirements. Keywords may be entered as a form of classification and requirements may be linked to them in various ways. It is possible to view a list of requirements classified by a particular keyword. Keywords can themselves be grouped into hierarchies.

RDD-100 is a front-end tool that supports the requirements and functional analysis steps of the RASSP EPI Baseline Systems Engineering process. It enables the systems engineer to take RTM-captured requirements for top-level system design, analyze and model behavior that satisfies those requirements, design components that implement that behavior, examine architecture tradeoffs, and handle exceptions. See Figure 2.2-3.

Throughout this process, RDD-100 performs hundreds of static consistency checks to verify the completeness and traceability of the system under design. The Dynamic Verification Facility (DVF) is used observe the dynamic behavior of the system for potential timing or resource utilization problems.

RDD-100 uses predefined templates to create a variety of customer documents (for example, DOD-STD-2167A System/Segment Specifications, Interface Requirements Specifications, and several versions of the Software Requirements Specification). This customer documentation is extracted directly from the data generated during the verification of the design and system model analysis. Project documentation is therefore a byproduct of the systems engineering process, and it is always congruent with the system model.

RDD-100 contains a collection of utilities for creating, accessing, manipulating, extending, viewing, analyzing, and interfacing to/from elements in the System Descriptor Database (SDD). The system design is described in an Entity/Relationship/Attribute (ERA) Model. With this notation, a user specifies instances of elements (e.g., System Requirements) and describes their specific attributes and relationships to other elements (e.g., functions that fulfill those requirements).

There are four items that define an RDD-100 Facility (collection of similar elements):

• Schema - the definition of elements, attributes and relationships among the elements for a specific area (i.e., the core systems engineering schema).
• Views - the definition of the user interfaces for viewing the schema elements in a facility. RDD-100 is delivered with a standard set of views for displaying data (i.e., Behavior Diagrams).
• Consistency Checks - the definition of the consistency rules among the schema elements for maintaining design integrity (i.e., fundamental checks).
• Reports - report templates are stored and used to organize and format contractually required documents (i.e., DID compliant 2167A and 490A reports).

The information in the SDD can be viewed in either Behavior Diagram (BD) form or other kinds of function graphs which include: IDEF0 Diagrams, N-Squared Charts, Function Flow Block Diagrams (FFBD), or Data Flow Diagrams (DFD). Behavior diagrams display the most information and you must create a Behavior Diagram before the information can be displayed in any other function graph type.

Another system view is provided by the Hierarchy Chart. These charts start with a top level element and trace through one or more relationships down a hierarchy to any number of levels.

This output can be an Interleaf "book", a postscript file, arbitrary ASCII output, Encapsulated PostScript files, or Context Document compatible. The user can generate report specifications from scratch, or modify the supplied templates.

A Behavior Diagram is a graphic view which represents both input/output data flow and a time order sequence of events. Behavior Diagrams can be decomposed hierarchically, show order of functional activation (precedence/relationship), define control data flow, and exit (completion) conditions. Related text shows performance traceability and other data (such as text descriptions). The sequence of behavior flow is generally top down and left to right. Behavior diagrams are comprised of Functions and Items. Functions and Items can be either Time or Discrete. A Function is a part of the system that carries out an action (i.e., convert an input to an output). An Item is something that a function accepts (input) or produces (output).

Behavior Diagrams have many constructs that control time flow. Refer to Figure 2.2-4. They include; Sequence, Concurrence, Select, Iterate and Replicate. A sequence is the simplest and most common structure. It consists of a single, vertical time-flow line with a series of functions in order from top to bottom.

A concurrence or parallel represents multiple paths of a process that can occur at the same time based on certain conditions, inputs, etc. Functions below the concurrence cannot start until all branches of the concurrence have completed. For example if there are two branches in a concurrence and one branch takes 5 minutes to complete and the other branch takes 5 hours and if both were started at the same time, functions after the concurrence could not be executed until the 5 hour branch is complete.

The Block Oriented Network Simulator (BONeS) provides a Motif graphical environment for capturing the design of communication networks and simulating the performance of the captured design. The network design is created graphically by hierarchical, data flow block diagram generation.

The Data Structure Editor (DSE) is used to create data structures which are defined hierarchically and have an arbitrary number of fields. Fields can contain simple entities such as packet lengths and time stamps, or other data structures.

The Block Diagram Editor (BDE) is used to create network models. Primitives and other blocks are placed and connected to perform functions.

When the network model is completed, error and consistency checking is done. An event driven simulation of the network is executed using the Simulation Manager with user specified values for model parameters. An interactive simulation can be run to watch the flow of data on the diagram. Simulation continues until there are no more data structures in the block diagram or until the simulation clock reaches a user specified stop time.

During simulation BONeS collects data in the network using a variety of probes at user specified locations. The data collected during simulation is analyzed and displayed graphically using the Post Processor (PP). A variety of statistical analysis routines are available.

The Signal Processing Worksystem (SPW) provides tools needed to interactively capture, simulate, and test a wide range of digital signal processing (DSP) designs. SPW is used to evaluate various architectural approaches to a design and to develop, simulate and fine tune DSP algorithms.

The Block Diagram Editor (BDE) is used to create network models. Primitives and other blocks are placed and connected to perform functions.

The Signal Display Editor (SDE) is used to create, display, edit, process and analyze signal waveforms.

The Simulation Program Builder converts the signal flow block diagram from the BDE database into an executable program that simulates the behavior of the signal processing system. It takes the simulation inputs from the SDE database and places the simulations outputs into the SDE database

MATLAB is a high-performance, interactive numeric computation and visualization environment. It combines the advantages of hundreds of prepackaged advanced math and graphics functions, with the flexibility and extensibility of a high-level language to customize and add new functions as needed. MATLAB combines numeric analysis, matrix computation, sparse matrix computation, signal processing, 2-D and 3-D graphics, and other functions with a user interface where problems and solutions are expressed mathematically without the need for traditional programming.

MATLAB application toolboxes extend the functionality of MATLAB by providing algorithms and functions developed by renowned experts in digital signal processing, control system design, neural networks, system identification, dynamic simulation, optimization, and other application areas.

The MATLAB Signal Processing Toolbox works with MATLAB numeric computation software for 1-D and 2-D digital signal processing and time-series analysis. The Toolbox includes 1-D and 2-D FFTs and inverses, FIR and IIR filter design, filter response and simulation, and power spectrum estimation.

Revisions to correct reliability and quality issues are a costly and time-consuming process. The MSI Design Assurance toolset will identify issues as the design progresses. The RASSP RAM-ILS tools will provide auditable 'second opinions' for the reliability, safety, producibility, life-cycle costs, and related quality viewpoints.

The RASSP Design Assurance Manager toolset provides feedback to designers from concept through completion. The MSI RAM allocation tool uses the mission requirements in a deployment simulator to allocate functional safety, reliability, diagnosability, maintainability, supportability, life-cycle costs, and quality requirements. The allocations are used as the benchmark for comparisons all phases of the design. The allocations will be used in trade-off studies to determine return on investment in terms of economic and performance issues. The MSI Primary Predicted Costs of Ownership model provides a consistent basis for trade-off studies.

The classic methods of reliability prediction Mil-HDBK-217 are based in device statistics. Much of the RASSP design process will use new, advanced technology with little statistical history. MSI's RAM-ILS toolset is based on reliability physics. Parametric variation caused by heat, oxidation, humidity, and other factors of aging are integral to the RASSP RAM-ILS methods. Worst case analysis methods evaluate the robustness of a design to withstand the effects of radiation, aging, electrical, mechanical, and thermal conditions. Digital and analog design tools are integral to the RAM-ILS evaluation.

GEDAE™ is a highly interactive graphical programming and autocoding environment which facilitates application development, debugging, and optimization on workstations or embedded systems. Its graphical editor supports building data flow graphs which are very readable. Explicit inputs and outputs are identified and user notes can be inserted directly on the graph canvas. The same user interface which supports the graphical editor is used for controlling all activity within GEDAE™. Capability is provided for the designer to readily partition graphs and map the partitions to multiple workstations or multiple processors in an embedded system. Autocoding generates appropriate schedules and code for each processing element which is efficient in terms of execution time and memory usage.

A GEDAE™ Run-Time Kernel provides all of the interprocessor communication required by the particular software mapping. Although the designer has flexibility in selecting the type of communication used (e.g., socket, DMA, or shared memory), implementation of the communication is automatic. Therefore, the application developer never needs to write any interprocessor communication software.

Algorithms are captured in GEDAE™ by placing processing functions extracted from a library on a canvas and interconnecting them using the extensive facilities of the graphical editor. Using a top down design approach, the basic building blocks and data passing requirements can be put on the canvas. In this way, the application designer can build, test, and analyze algorithms with point and click simplicity. Designers can select from functions contained in the extensible library. Library functions are provided for most of the commonly used signal processing functions. Understanding that a function library will never be complete, templates are provided for creating new functions. In addition to providing all of the typical data types, GEDAE™ has the important capability to define new arbitrary data types (e.g., complex C structures) for use with custom primitives. This ability is of great importance to users who want to capture heritage software which is generated in modules whose I/O is maintained as complex data structures.

Hierarchy is supported in a flow graph which simplifies complex application understanding. GEDAE™ supports extensive and efficient parallel processing.

Execution of GEDAE™ graphs is controlled through the same interface used to construct the graph. Users can modify parameters in the graph on the fly and observe the impact of those changes. The ease of making modifications to a graph and its operating parameters increases productivity by making it easy for designers to fine tune applications quickly. Execution results are presented to the designer in the form of detailed timelines and execution schedules along with memory maps to support the designers analysis of system solutions.

GEDAE™ provides an efficient autocoding capability driven by partitioning and mapping defined by the user. Because GEDAE™ handles all interprocessor communication, the designer never has to write any communication software. GEDAE™ launches the compilation, linking, loading, and execution of the application on the embedded hardware. An embedded run-time kernel on each processor supports execution. GEDAE™ generates the execution schedule for each processor and provides the user the ability to divide schedules into subschedules which may all operate at different firing granularity to optimize performance. Execution schedules and memory maps are presented for analysis.

A new architecture is defined as a specific vendor's COTS product in conjunction with the operating system (or board support software) and optimized function library used by the vendor. There are three steps required to port GEDAE™ to new architectures. First, the communication software is modified to use the specific operating system and/or board support package provided by the vendor. Second, all communication mechanisms that are supported by the specific hardware must also be supported by the autocoding for that hardware. For example, some SHARC hardware utilizes only SHARC links for all communication while other hardware also provides switching networks or local buses. In addition, various communication protocols are used including, shared memory, message passing, and DMA. Third, a version of the GEDAE™ primitive library which utilizes the optimized math library supplied by the vendor must be provided.

GEDAE™ is relatively easy to port to new architectures (even those not using an operating system) because the communication layer has been optimized and reduced to approximately 600 lines of code. ATL has ported GEDAE™ to various hardware including three different vendor's hardware architectures with different communication mechanisms, both on a board and between boards. The currently supported architectures utilize SHARC, Power PC, and i860 processors.

GEDAE™ supports the optimization of partitioning and mapping, memory usage, communication mechanism selection, schedule firing granularity, queue capacities, and scheduling parameters. GEDAE™ provides the ability to interactively manipulate these items which greatly improves the designers ability to optimize processing after retargeting an application to a new architecture.

Under the RASSP program, the synthetic aperture radar (SAR) application was implemented using the GEDAE™ tool. The application software that was hand-generated for a Mercury RaceWay architecture was re-implemented using the GEDAE™ tool on a similar Mercury architecture. The resulting autocoded application achieved the same execution and memory efficiency as the hand coded version-with approximately a 10X reduction in implementation time. The same application has been remapped to three other architectures by simply repartitioning, remapping, and reoptimizing the application on the new architecture using the optimization support within the GEDAE™ tool. The time utilized for retargeting was 2-3 days for each subsequent architecture.

The PRICE suite of Computer-Aided Parametric Estimating (CAPE) tools are used to estimate the development, production, maintenance cost, and schedules of Hardware, Software, and Micro-circuits. Parametric cost modeling is based on cost estimating relationships (CERs) that make use of product characteristics (such as hardware weight and software language) to estimate costs and schedules. The family of PRICE parametric tools include four models which are described below. Hardware cost model (PRICE H) - The hardware cost model is used to estimate the cost and schedule for electronic, electro-mechanical, and structural assemblies. This model incorporates input data concerning yield, performance, quantity, process and design sensitivity, and complexity parameters. The hardware model provides cost and schedule output for the development and production phases of a program.

Hardware life-cycle cost model (PRICE HL) - The hardware life-cycle cost model is used to estimate the cost of operating and maintaining hardware systems throughout their deployment. Inputs to the life-cycle model include deployment parameters, maintenance concepts, cost, and escalation factors. The life-cycle model is a supplement to and operates in conjunction with the hardware model.

Microcircuit/module cost model (PRICE M) - The microcircuit cost model is used to estimate the cost and schedule for custom microcircuit, printed circuit boards, and electronic modules. The model uses functional relationships based upon parameters such as the number of transistors, percentage of new circuit cells, number of pins, board type and size.

Software/software life-cycle cost model (PRICE S) - The software cost model is used to estimate the cost and schedule for the design, development, integration, testing, and support of software. This model uses functional relationships based upon parameters such as function, lines of code, complexity, platform, application, and design reuse to estimate costs.

The PRICE cost models will be integrated with the RASSP system engineering, life-cycle support, and architecture selection tools. These integrations will allow engineers the capability to perform cost/performance trade-offs throughout the design process.

The Component and Library Management System (Explore (CLMS)) is an object-oriented extension to the existing commercially-available Component Information System (CIS) product. This extension supports the implementation of the RASSP Reuse Data Manager (RRDM) subsystem and consists of the following:

• Data manager extensions
• Object viewer development
• Object editor development
• Meta-model editor development

The data manager is an existing capability which will be extended to manage default objects, template objects, and temporary objects. A default object is a model for the design objects in a given class. The attributes (properties and values) for a default object may be used as a basis for creating a new object. Template objects enforce rules about required fields and values. Template objects may be mapped to individual design objects. Temporary objects are added to the database, but marked to be deleted or moved at a later time. Temporary design objects are useful for creating test cases for converting existing data.

The object viewer will allow users to search for reusable design objects using a powerful parametric search. It will use two windows; one for entering parametric search data and another for displaying results. The results of performing a search will be a list of all reusable design objects that match the specified parameters. The user can then pick individual reusable design objects on the list and view all of the parameters and cross-references associated with each reusable design object.

The object editor will allow users to enter design objects into the RRDM, or to update existing design objects. Updates typically involve adding, deleting, or editing object parameters and test items associated with a given object, changing permissions for a given object, and copying an object to a different class. The object editor will also allow users to add mappings between objects.

The meta-model editor will allow the database administrator or librarian to modify the hierarchical class structure by adding and deleting classes. The meta-model editor will be available either in interactive or batch modes.

Interleaf TPS is the common tool for document production used to create and manage technical documentation, work instructions, specifications, proposals, reports, data sheets, catalogs, forms, and correspondence.

TPS offers complete word processing, advanced graphics, automatic layout, conditional document assembly, multi-page tables to support traceability data and technical equations, data-driven charts, image editing, interactive equations, and centralized control over document content and format.

Additional Interleaf features are:

• Full WYSIWYG word processing, including spell checking, text undo, automatic numbering and wildcard search and replace.
• Automatic layout including document zooming with full editing capabilities, turn pages, facing pages, kerning, and leading.
• Multi-page, multi-column tables that can include graphics.
• A palette-based equations editor.
• Sophisticated graphics, including creation, editing, and importing of line art, graphics, and charts.
• Rotated text and graphics - at any angle.
• An extensive clip art library.
• Online context-sensitive help.
• Book management facility for multi-sectioned document assembly.
• Book catalogs for central control of format and content.
• Revision management to track changes and maintain version history.
• Linked online documents for workgroup access to most recent document versions.
• Extensive filter support including ASCII, CGM, FrameMaker, IGES, HP-GL, PICT, TIFF, Microsoft Word RTF, etc.

To support the RASSP System Definition Process, Ascent Logic's RDD-100, Lockheed Martin's PRICE cost estimating tools and Management Sciences' RAM-ILS toolset have been integrated together to provide a concurrent engineering design environment over multiple domains. This interface is shown in Figure 2.3-1. RDD-100 is used to capture and analyze the requirements, to define the functional behavior of the signal processor, to allocate the requirements and functions to each signal processing subsystem and to provide requirements traceability. PRICE cost estimating tools are used to estimate the development, production and support costs for the signal processor. The RAM-ILS tool is used to perform reliability and maintainability analyses.

The types of data which are passed from one tool to another consist of the data that typically resides in that tool which can be used by the other tool. For example, system engineering data is passed from RDD-100 to the PRICE cost estimating tool. A GUI interface for the PRICE tool in RDD-100 was not developed. The types of parameters which are passed from RDD-100 to PRICE include the equipment configuration, size, weight, power, technology and complexity factors. The development, production and support costs are passed back to RDD-100 from the PRICE tool. On the other side of the interface, the equipment configuration and allocated reliability and maintainability budgets are passed from RDD-100 to the RAM-ILS toolset. The reliability and maintainability assessments are passed back to RDD-100 from the RAM-ILS tool. In addition, optimizations can be performed within the RAM-ILS toolset when the budget is not met and the tool can make recommendation on how redundancy can be added in the system in the most cost effective way to meet the requirements.

In addition, the RAM-ILS toolset is tightly integrated within Mentor Graphic's FALCON Framework. With this integration the RAM-ILS tools have access to detail design information such as thermal and stress profiles as the design progresses. This detailed design information can be used in more accurate reliability and maintainability analyses.

RTM/RDM integration supports the following process steps. An overview of the RTM/RDD-100 tool integration is diagrammed in Figure 2.3-2.

• Prepare the RTM database and populate it with customer requirements.
• Use RTM to clarify and organize requirements.
• Export requirements to RDD-100.
• Perform system definition and requirement/functional/mission analysis with RDD-100.
• Export derived requirements, critical issues, and allocations back to RTM to maintain traceability and to support impact assessment.
• Export from RDD-100 critical issues along with relevant data (requirements, functions, components, etc.) to BONeS.
• In BONeS, define models which map to imported RDD-100 elements. Capture assumptions, rationale, and derived requirements in BONeS.
• Pass back results (Pass/Fail), assumptions, rationale, derived requirements, plots, recommendations, etc. to RDD-100.

RDD-100/BONeS integration supports the following process steps:

• Perform preliminary system definition in RDD-100.
• System engineer evaluates results and makes final determination (accept, rerun, reallocate etc.).

Figure 2.3-3 depicts the integration of RDD-100 and BONeS.

RASSP CDRL A007 - 6/98 2-23 cad system description Baseline 2.0