RASSP Integrated System Tools Appnote

The system definition process is shown in Figure 3-2. The inputs to the system definition process include all the customer documentation detailing the processing system specification. Typical signal processing requirements include system mode functional descriptions (search, track, waveforms and algorithms), performance requirements (processing gain, timeline and precision requirements), physical constraints (size, weight, power, cost, reliability, maintainability, testability, etc.), and interface requirements. Top-level tradeoffs are performed by the multidiscipline product development team to determine how the system will operate and what set of subsystems are required. System level functional and timeline simulations are developed to characterize system behavior. The system definition process is iterative, requiring constant interaction with the customer and product development team. The outputs of the system definition process include the functional, performance and physical requirements for each signal processing subsystem.

As the subsystem designs progress, key system-level simulations are re-run to ensure that performance is maintained. The subsystem requirements are periodically monitored to make sure that the development risks are appropriately balanced among the subsystems. There is a feedback path back to the system-level from each subsystem design which is used whenever cost-effective subsystem designs cannot be obtained. When subsystem requirements can not be met, analyses are performed to determine a refined partitioning of the system requirements.

The tasks performed during requirements analysis are summarized in Table 3-1. A complete set of customer documents must be used to determine the requirements since the contractor must understand how users intend to use the system. The system is defined in terms of its modes and states, functions and interfaces. Trade-offs establish alternative performance and functional requirements to meet customer needs. Any potential conflicts between the trade-off analysis results and the system requirements are resolved. A work-off plan for all TBD/TBR items that identify the responsible individual, schedule for resolution, risk analysis and key trade-offs to be performed is developed. Traceability of system requirements and decisions ensures that the trade-off decisions made in generating requirements can be tracked and that these requirements are completely and accurately reflected in the final design. Traceability is also used to assess the impact of changes at any level of the system. System requirements are examined to ensure completeness and consistency.

The output of the requirements analysis task is the system specification. This specification includes the technical requirements for the system, allocates the requirements to functional areas, documents the design constraints and defines interfaces between functional areas. This specification also contains the necessary performance requirements. Essential physical constraints and requirements for application of any known specific equipment which must be included in the system are included in the specification. The specification can be in either a written format, an executable format or a combination of both formats.

The tasks performed during functional analysis are summarized in Table 3-2. The functional identification task translates system requirements, customer heritage and customer rationale into functional block diagrams that are used by subsequent processes to create and evaluate system configurations. This task refines and decomposes the functions identified from the requirements analysis task. Design constraints for each functions are defined. Functional elements within the RASSP reuse library are examined to determine whether existing functional library elements can be used.

Lower level functions, constraints and performance are generated during functional decomposition. This decomposition continues until the functionality can be allocated to a specific subsystem. This more detailed information is used in the subsequent partitioning and architectural trade processes. This functional analysis is performed iteratively to eliminate poor allocation decisions as soon as possible. Functional elements within the RASSP reuse library are examined to determine whether existing library elements can be used at this lower level decomposition. If any of the system functions can not be represented by existing library elements, new primitives are identified for development.

Traceability is established between each functional block and the system requirements.

The tasks performed during system partitioning are summarized in Table 3-3. Functions and constraints are allocated to entities in a specific candidate design during the functional allocation task. This task is completed when all functions are allocated to subsystems and all requirements and constraints are mapped through functions to subsystems. Trade-off analyses assess the risk and life cycle cost for each alternative system configuration. Design decisions and rationale must be documented as the functions are allocated. This task iterates until an allocated baseline is established. Many iterations may be needed to refine the system configuration.

The performance verification task supports system partitioning by providing evaluation criteria to determine which candidate configuration provides the most effective performance. This effort must consider all factors of interest to the product development team: technical performance, risk, life cycle cost, producability, supportability, testability, etc. The performance evaluation must reflect objective, demonstrable evaluation metrics and must assure the customer that sufficient candidates were considered. The behavior of candidate configurations is determined through simulation to ensure all performance requirements are met at the system level. The system partitioning process iterates with the functional allocation process until the performance of a candidate configuration meets the completion criteria established during the requirements analysis process.

The output of the system partitioning process includes the set of functional, performance and physical requirements for each subsystem. This requirements are in the form of an executable requirement and represent the first virtual prototype for the subsystem.

The RASSP architecture selection process transforms the processing requirements for each processing subsystem into a candidate architecture of hardware and software elements. The architecture selection process overlaps with the system definition process during the system partitioning activity. A hierarchical set of simulations is performed at each design level, and the results of these simulations are back annotated in the higher-level simulations to verify that overall performance is maintained.

Each tool passes data to another tool through an ASCI file with the appropriate format. The types of data which are passed from one tool to another consist of the data that typically resides in that tool and can be used by the other tool. For example, system engineering data is passed from RDD-100 to the PRICE cost estimating tool. This approach eliminated the need for implementing a GUI interface for PRICE and RAM-ILS in the RDD-100 tool. 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 calculated within the PRICE tool and these costs are back annotated into the RDD-100 data base. On the other side of the interface, the equipment configuration, allocated reliability and maintainability budgets, and cost data are passed from RDD-100 to the RAM-ILS toolset. The reliability and maintainability assessment is performed within the MSI toolset and the results of these analyses are back annotated into the RDD-100 data base. In addition, optimizations can be performed within the RAM-ILS toolset when the reliability requirements are not met and the tool can make a recommendation on how redundancy can be added in the system in the most cost effective way to meet the requirements.

Now that you have a basic understanding of the integrated toolset, you may read Sections 3.2.2 and 3.2.3 for more detailed information on the individual tools and their integration. For a shortened version you can skip directly to Section 3.3 to read about the benefits of using these tools in a cooperative manner.

3.2.2.1 RDD-100

RDD-100 is based upon an entity, relationship and attribute (ERA) database. Entities within the database are the nouns or objects within the system such as requirements, functions and components. The interrelationship between different entity types are defined by an extendible schema within RDD-100. It is through these relationships that traceability is maintained within RDD-100. The base RDD-100 schema has been extended for RASSP to support the integrated costing and reliability analysis and these extensions are described in Section 3.2.3.1.

The typical use of RDD-100 is illustrated in Figure 3-4. Requirements are initially captured, examined and decomposed into lower level requirements during the requirements analysis step. The functionality of the system is then defined using behavior diagrams within RDD-100 during the functional analysis step. Both control and data flow are shown within the same behavior diagram. Every function within the behavior diagram must be traceable to a requirement. The physical architecture consisting of hardware and software components is established during the system partitioning step. Each function in the behavior diagram must be allocated to one component in the system architecture. A traceable path between each function and the component that function is allocated to is maintained within RDD-100.

The PRICE cost estimating tools consist of the hardware, microcircuit, hardware life cycle and software models and each of these models are described below.

PRICE H - Hardware Cost Model : The hardware model is used to estimate the cost and schedule for electronic, electro-mechanical, and structural assemblies. This model incorporates input data concerning weight, size, quantity, process and design sensitivity, and complexity parameters. The hardware model provides cost and schedule outputs for the development and production phases of a program.

PRICE M - Microcircuit/Module Cost Model : The microcircuit model is used to estimate the cost and schedule for custom microcircuits, 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 types and size.

PRICE HL - Hardware Life Cycle Model : The hardware life-cycle 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 works in conjunction with the hardware model.

PRICE S - Software/Software Life Cycle Model : This software 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.

PRICE Systems refine and update their cost estimating models based upon actual costs being incurred on current products of their users. While the cost models are designed to provide estimates for a typical organization, the models provide the flexibility for the user to tailor and calibrate the models for their specific organization. As a result of calibration, the costs and schedule outputs of the models reflect how a particular organization develops their product.

The PRICE model requires that the system be described as a set of hardware and software components in an equipment breakdown structure (EBS) which is shown in Figure 3-5. Parameters which characterize each component are entered into the model. Global parameters which define labor rates, financial factors and deployment concepts are also required. The PRICE models determines the development, production and support costs for each component in the EBS and these costs are accumulated up the equipment tree to determine the overall system costs.

The RAM-ILS toolset can be used for reliability predictions, maintenance analysis, failure modes and effects criticality analysis (FMECA), and success tree analysis. Each of these capabilities are described below.

Reliability Predictions - Reliability predictions are made within the RAM-ILS tool using reliability block diagrams. Failure models for each component in the system can be based upon relevant historical data, specialty computational methods, probability distributions and "similar to" designs. These predictions facilitate trade-off studies when allocating failure rate budgets to system components.

Maintainability Predictions - The RAM-ILS tool can be used to determine the impact of various maintenance concepts on life cycle cost. The tool models various maintenance strategies such as level of repair and fault isolation characteristics. Maintenance diagrams are constructed within the toolset.

Failure Modes and Effects Criticality Analysis (FMECA) - The FMECA portion of the RAM-ILS toolset provides the user with an understanding how the system will perform when it is operating in either a degraded or failed state.

Success Trees - Success trees are modeled within the RAM-ILS toolset to illustrate how a system successfully operates with respect to the interaction of system functions and components. Inverted success trees identify unacceptable critical combinational failures. Success trees can be used to confirm redundancy decisions and identify false redundancy conditions.

The RAM-ILS toolset is integrated with Mentor Graphics Falcon Framework and is illustrated in Figure 3-6. This integration provides a consistent, well-defined, known user interface. As a result, the user does not need to learn another specialized interface to use the RAM-ILS tool. In addition, the Mentor interface provides convenient access to detailed design data.

3.2.3.1 RASSP Schema Extension Overview

• Attributes have been added to the component entity, which describe the physical nature of the component.
• A cost entity has been added to the schema, which contains the development, production and support costs for each component in the system.
• An RMA entity has been added to the schema, which contains both input parameters needed for specialty engineering analyses and output results from these analyses.
• A life cycle parameter entity has been added which contains parameters that describe how the system is deployed during its life cycle.
• A duplicate component entity has been added to the schema, which identifies multiple instances of the same component within a system.
• An external tool file entity has been added to the schema, which contains file information that the PRICE and RAM-ILS tools need.

The attributes for the duplicate component entity are essentially identical to the additional attributes added to the component entity in the RASSP extended schema. The major difference between the attributes is that the various quantity attributes in the component entity have been replaced by the total system quantity attribute in the duplicate component entity. The total system quantity attribute contains the total number of identical components used within one system and this number is calculated and back annotated into the RDD-100 database by running the "Calculate Total System Quantity Report" within RDD-100.

3.2.3.2.1 Overview

An automated Integrated Design To Cost (IDTC) environment has been developed which enables engineers and cost estimators to work efficiently together using their native tools so many design alternatives can be examined during system concept trade-off studies. As shown in Figure 3-8, the engineer works within his system engineering tool (RDD-100) to enter a physical description of a potential design. This information is then exported out of the system engineering tool and read into the cost estimating tool(PRICE). The data is then translated into cost estimating parameters and merged with information from the cost analyst to produce a complete set of data for the parametric estimating engine. The parametric engine produces a cost and schedule estimate and exports this data back to the system engineering tool. The engineer can then access this cost data within the system engineering tool.

This IDTC estimating process is an improvement to the traditional method in many ways. It is faster, enabling more alternatives to be explored. It is more accurate and repeatable because the estimating relationships are controlled by the estimator, codified into a language script and executed by a computer. Since the relationships are codified, the engineer does not need to meet with the estimator every time a cost estimate is needed. This IDTC process allows the engineer and estimator to work effectively together. A cost estimate can be turned around in minutes instead of days or weeks with this IDTC environment.

The organization of this section is as follows. The physical elements of the IDTC environment are initially described. Then the process to use the IDTC environment is explained.

The RASSP IDTC environment consists of the RDD-100 and PRICE extensions as shown in Figure 3-9. The schema, consistency checks and output reports have been developed for RDD-100 which support the IDTC environment. A cost analyst file, synchronization file, PRICE Rule Language (PRL) import template, and PRL export template have been developed within the PRICE Enterprise toolset to support the automated IDTC environment. The use of each of these elements within the IDTC environment is described below. Note that the parameters calculated by the RAM-ILS tool which are used within PRICE to support cost estimating are not explicitly shown in Figure 3-9, since these parameters are back annotated into the RDD-100 database prior to using them in PRICE.

The schema within RDD-100 has been extended on the RASSP program to support both cost estimating and reliability analysis as previously described in section 3.2.3.1. The engineer populates the RDD-100 data base with the system engineering parameters that define the physical configuration of the hardware and software. A consistency report is then executed within RDD-100 to make sure that the database has been sufficiently populated to obtain a cost estimate. An export report is then run within RDD-100 which outputs the system configuration with all the required attributes in the appropriate format (format needed by the PRICE tool is defined in the interface specification) to import into the PRICE cost estimating tools. The cost for each system component is then estimated within the PRICE tool based upon the system engineering parameters and data provided by the cost analyst. The PRICE tool generates an output file in the standard RDD-100 rdt format which contains the development, production and support costs for each system component. This cost data is populated within the RDD-100 data base using the standard RDD-100 import facility.

Cost Analysis File - The cost analyst file is used in conjunction with the RDD-100 output file, PRL import template and the synchronization file to establish all of the parameters the PRICE tool needs to perform a cost estimate. The cost analyst file contains default parameters for each component in the system which are missing from translation of the RDD-100 file. The parameters typically defined within the cost analyst file are prototype and production schedule, labor rates, escalation rates and other financial factors that the PRICE tool needs. The information is entered within the cost analyst file on an element type basis. Each component within the PRICE estimating breakdown structure has a particular element type such as electro-mechanical, software and design integration. All components of the same mode type receive the same default parameters contained within the cost analyst file if the parameter is missing from the RDD-100 file and synchronization file.

Synchronization File - The synchronization file is used in conjunction with the RDD-100 output file, PRL import template and the cost analyst file to establish all of the parameters the PRICE tool needs to perform a cost estimate. The synchronization file contains parameters for each component which override any parameter from either the translation of the RDD-100 file or cost analyst file. It is through the use of the synchronization file that the cost analyst can control the cost estimate since any parameter within this file will supersede the same parameter from any other source. The information is entered within the synchronization file on a component name basis which enables each component to have its own parameters within the synchronization file. Since the PRICE interface has been designed to interface with multiple tools, a lock file name is used within the PRICE tool to identify which parameters are active for overriding parameters for each tool interface. It is through the use of the lock file name that the same synchronization file can be used for interfacing PRICE to multiple tools.

PRL Import Template - System engineering parameters within RDD-100 are used to populate attributes within the PRICE toolset. However, there is not a direct one-to-one mapping of the system engineering parameters within RDD-100 to PRICE attributes. A simple illustration of this is that the length, depth and width of a component are entered in RDD-100 for a hardware component, while the PRICE tool only uses volume. As a result, the system engineering parameters must be translated into attributes understood by the PRICE tool. A proprietary interpreted language called PRICE Rule Language (PRL) was developed to translate parameters from other tools into PRICE attributes. As a part of the RASSP program, a PRL import template was written which translates approximately 65 system engineering parameters for each component into about the same number of PRICE attributes. This import template was developed for the signal processing domain, although it may be applicable to digital hardware and software systems. To support other domains, additional translations are required that are unique to that particular domain.

1. Create the parametric estimating relationships;
2. Analyze the programmatic requirements of the project;
3. Create the cost analysis file;
4. Develop and verify system architectures which meet the requirements;
5. Obtain the cost estimate; and
6. Create and maintain the synchronization file.

Each of these process steps is described below. Note that this process is iterative in nature and is repeated as the system design matures, resulting in more accurate cost estimates.

Create Parametric Estimating Relationships - The parametric estimating relationships (PER) which are used to convert system engineering data into PRICE cost estimating attributes are established and codified into the PRICE Rule Language (PRL) during this process step. This process step is performed once and should address all product lines and application domains which IDTC is intended to be used. The generation of the PRL import template should be done once for a company and is not typically part of a specific project. The PER's and PRL import template are updated to reflect changes in a company's product line. The cost estimating department is responsible for developing the PER's. The process used to generate these relationships are contained within a company's work instructions. These relationships are developed from legacy data from previous projects. The output of this process step is the PRL import template which codifies the rules to translate RDD-100 system engineering parameters into PRICE attributes. The RDD-100 schema, consistency checks and export reports may need to be modified if additional system engineering parameters are needed to characterize a company's product.

Analyze Project's Programmatic Requirements - The customer requirements are analyzed in this process step to determine whether a company is going to proceed in bidding the program. The program management and proposal response teams perform this process step using the company's legacy data and conceptual baseline architecture for the project. The outputs of this process step include the job instructions for conducting the project and the set of allocated budgets for the program.

Create the Cost Analyst File - The cost analyst file used to supply default parameters while importing system engineering parameters into the PRICE tool is created during this process step. The cost estimating department is responsible for the generation of this file using the PRICE tool. This file contains default parameters which are used to supplement the attributes obtained from the translation of the RDD-100 parameters. This file typically contains prototype and production schedules, labor rates, escalation rates and other financial factors.

Develop and Verify System Architectures - Architecture tradeoffs are performed during this process step to determine the hardware and software elements of the system. This process step is performed by the IPDT team which must consider all aspects of the system life cycle. The IPDT performs this process step using the allocated budgets, project technical information and cost data in determining the composition of the system. The requirements are analyzed, the system functions are decomposed and system architectures are analyzed using RDD-100. This process step is iterative in nature and is repeated for each candidate system design. The output of this process is the system configuration with costing data. The fidelity of the cost data can either be comparative in nature, rough order of magnitude or basis of estimate depending upon the rigor used in developing the parametric estimating relationships.

Obtain the Cost Estimate - The development, production and support costs for a system architecture are determined during this process step. This process step is performed by importing the RDD-100 generated file containing the system engineering parameters using the PRL import template, cost analyst file and synchronization file into the PRICE Enterprise toolset. The outputs of this process step are the cost reports from the PRICE tool and the ASCI file containing the development, production and support costs. This file is used to import the cost data into the RDD-100 database.

Create and Maintain the Synchronization File - The synchronization file used to supply overriding parameters while importing system engineering parameters into the PRICE tool is created during this process step. The cost estimating department is responsible for generating this file using the PRICE tool. This file contains overriding parameters which supersede the values obtained from either the translation of the system engineering data or cost analyst file. This file provides the mechanism that the cost analyst can use to control the cost estimate.

3.2.3.3.1 Overview

• RAM engineers expend significant effort obtaining numbers for logistics, such as MTBF and MTTR, without really being involved in the early design process.
• Large organizations expend time and effort trying to understand why systems fail, but rarely apply the lessons learned early in a repeatable design process.
• The designer performing the detailed design rarely has a documented list of reliability issues to influence the design.

Management Sciences, Inc. (MSI) RAM tools provide a new approach to applying traditional "ilities" design techniques early in the design process. The goal of using RAM tools early in the system engineering effort is to reduce the number of nasty surprises encountered later in the product life cycle. It is in this early design phase that the most reliability improvements can be recognized and incorporated cost effectively. Through the early use of the integrated systems tools, reliability requirements and issues are identified and documented cooperatively and concurrently with other design requirements and issues as shown in Figure 3-12. Thus, quality related issues can be applied to the architecture selection process, and issues and requirements can be documented, tracked, and monitored through the product design life cycle.

The remainder of this section provides a short discussion of the software integration with Ascent Logic's (ALC) RDD-100 tool. This discussion is followed with a description of how the MSI tools support the RASSP systems engineering process. The MSI tools that are discussed include: Quality Function Deployment (QFD), Failure Modes and Effects Analysis (FMEA), and Integrated RAM Analysis. Through reading this section, you will obtain an understanding of the benefits of using these capabilities early in the design process.

The systems engineer populates the RDD-100 data base with the equipment configurations, functional descriptions, interface items and allocated RAM budgets. An export report is run within RDD-100 which outputs the system configuration and its associated attributes in the appropriate format for the MSI RAM toolset. The specialty engineer uses this data within the MSI toolset with detailed CAD data from existing designs to support a variety of RAM analyses such as Quality Function Deployment (QFD), Failure Modes and Effects Analysis (FMEA) and RAM assessment. The predicted RAM attributes calculated by the MSI toolset are back populated within the RDD-100 data base.

Components, functions and interface items defined within the RDD-100 data base are used to initially populate a FMEA data base within the MSI toolset. The specialty engineer can then use this FMEA data base to perform the following tasks:

• Identify potential interface link failure modes and the effects of these failures on the immediate function and mission performance.
• Determine the anticipated method of detecting each failure mode.
• Identify the worst possible consequence of each failure mode.
• Enumerate redundancies or compensating provisions available for each failure mode.
• Identify changes to the RDD system configuration to eliminate or minimize failure modes.

• Calculate reliability and availability for designs incorporating redundancy.
• Identify candidate architectures that adversely affect system reliability or availability.
• Model maintenance strategies, such as level of repair and fault isolation characteristics.
• Form basis for more accurate cost estimates for warranty and life cycle cost.
• Identify designs that do not meet RAM requirements.
• Perform sensitivity analysis .
• Determine methods for solving reliability problems.
• Develop strategy to support the detailed design cycle.

3.3 Benefits of Using the RASSP Integrated System Tools

The integrated system tools provide an efficient process for the engineer to access cost data. Engineers can obtain complete life cycle costs using the system tools without becoming an expert cost analyst. The integrated system tools provide an environment which can be effectively used to implement either Design To Cost (DTC) or Cost as an Independent Variable (CAIV) programs which are being emphasized within DoD. The cost estimation process has been established so the cost analyst is able to control the estimate.

The integrated system tools provide a reliability and maintainability analysis capability throughout the design process. These tools provide the mechanism that allows specialty engineers to be involved early in the design process. The RAM-ILS tool provides capabilities to perform reliability, maintainability, success tree and FMECA analyses. In addition, the system architecture can be optimized to meet reliability requirements in a cost effective fashion with the integrated system tools.