Next: 7 Architecture Design Process Detailed Description Up: Appnotes Index Previous:5 RASSP Design Process Description
Next: 7 Architecture Design Process Detailed Description
Up: Appnotes Index
Previous:5 RASSP Design Process Description
The RASSP methodology provides several key improvements over traditional system processes. The output of the system definition process is a set of executable specifications for the signal processor design activity. The definition and functions encompassed by the executable specification is receiving focused attention on the RASSP program. 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. In RASSP, we emphasize considering LCC early in the design process and the reuse of library elements at the system and subsystem-levels.
The system design process is a front-end engineering task in which signal processing concepts are developed to meet customer requirements and top-level tradeoffs are performed to define the signal processing subsystem requirements. Depending upon one's perspective, a system could represent a platform, sensor system, signal processor or processing board. For RASSP, a system is defined at the signal processor level. For this document, a "system" represents a signal processing system and a "subsystem" represents a major component of the signal processor. The system design process for RASSP starts after the requirements have been established for the signal processing system. A multidiscipline Product Development Team (PDT) performs the functions specified by the system design process. The specific roles of the PDT team members are described in Section 6.4.3.
The inputs to the system design process include all the customer documentation detailing the processing system specification. The outputs of this process include the functional, performance, and physical requirements for each signal processing subsystem. Typical signal processing requirements include system mode functional descriptions (search, track, waveforms, algorithms), performance requirements (processing gain, timeline and precision requirements), physical constraints (size, weight, power, cost, reliability, maintainability, testability, etc.), and interface requirements. The system definition process is iterative, requiring constant interaction with the customer and the product development team members as the impact of system-level decisions on LCC are significant.
The system design process is shown in Figure 6 - 1. Top-level trade-offs are performed 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 output of the system design process is a set of functional, performance and physical requirements for each subsystem. As the subsystem designs progress, key subsystem parameters are back annotated, and system-level simulations are re-run to ensure that performance is maintained.
Subsystem requirements are constantly monitored to make sure the development risks are balanced among the subsystems. There is a feedback path back to the system-level from each subsystem design; this path is used whenever cost-effective subsystem designs cannot be obtained. System requirements are then reexamined and new analyses is performed to determine a refined partitioning of the requirements. By clicking on the system design process box in the IDEF figure the next level of system design can be explored. The IDEF process model of this second level will be presented and textual descriptions of each subprocess may be obtained by clicking on the text button or by clicking on the link below. This level consists of three main subprocesses:
The operational and procurement requirements are initially examined to ensure that all requirements are well understood. There is close interaction with the customer to clarify any confusion with the requirements. A traceable path must be established when requirements are allocated to functions and components. Both mission and threat analyses are performed to understand how the signal processing system should behave. The system is defined by describing the system modes, functions and interfaces. Measures of effectiveness (cost, performance, risk, testability, etc.) are established for the system to provide metrics to compare different system configurations. Operational scenarios are also develop to assist in determining system performance.
The system is decomposed into its functional elements while establishing the requirements. This functional analysis is performed by determining what functions are required to implement each system requirement. Functions are described by defining the inputs to the function, the algorithm performed by the function, and the outputs of the function. Constraints and timing requirements are identified for each function. The top-level system behavior is modeled to determine the functional performance of the system. Signal-to-noise ratios, detection ranges, probability of detection, and probability of false alarms are several examples of system-level behavior for a signal processing system. System test and maintenance concepts are developed. All functions within the system must be traced back to the system requirements.
The functions of the system are allocated to subsystems as the functional requirements are established. At this point, various system configurations are developed and characterized to determine the baseline system. Trade-off analyses are typically performed for the following areas: reliability, availability and maintainability; testability; LCC; schedule and technical risk; integrated logistics support; human factors; and system safety. All system requirements must be traceable to both functions and subsystems. The output of the system partitioning process is a set of executable specifications for each signal processing subsystem.
Other items that need to be considered during this phase of the process are considered below:
The system definition process steps of requirements analysis, functional analysis, and system partitioning are closely interrelated. The tasks shown in Figure 6 - 1 are performed concurrently, often as a series of iterations to trade-off alternative approaches and to successively provide greater detail. The system requirements are first examined before functional analysis can begin. However, the functional behavior of the system can be developed while the requirements are analyzed and refined with the customer and end-user of the system. A preliminary system functional baseline is required at the System Requirements Review. This corresponds to the first level of the spiral model. In addition, the system partitioning process begins after the initial functional baseline is identified. The limitations of various equipment configurations identified during system partitioning must be accounted for in the functional behavior simulations. The system definition process is an iterative process where requirements analysis, functional analysis, and system partitioning activities are performed concurrently to define the subsystem requirements. The system definition process is closely coupled with the architecture design activities. As the signal processor design matures, quantified processor parameters such as throughput rates and precision must be back annotated into the system-level functional simulations. In addition, the system activities continue throughout the signal processor design. The allocation of system requirements to subsystems is closely monitored to ensure that the development risks are balanced among the subsystems.
Risk management is an integral part of the system design process as sources of technical, schedule, and cost risk are identified. Risk analysis is part of all of the trade studies that are conducted. The probability of occurrence for each risk and the resulting impact on performance, development schedule, and LCC as well as their interrelationships are determined. Risk reduction plans for the risks likely to occur or those that have a critical impact on the program are generated. The key to risk management is to identify and quantify the individual risk elements so that the overall system risk can be set at an acceptable level. Another key is to track key design parameters as the system is developed to monitor the risks throughout the program. Risk management activities are formally examined during all design reviews.
Baselines are used to control the development process. The functional baseline is established following the system design phase, which prescribes:
By clicking on the system requirements analysis and refinement process box in the IDEF figure, the last level of the system design process can be explored. The IDEF process model of this third level will be presented and textual descriptions of each subprocess may be obtained by clicking on the text button or by clicking on the link below. The system requirements analysis process is composed of three primary subprocesses:
The functional analysis process describes the requirements as a set of verifiable (simulatable) statements that can be used as a basis for system design. The functions, constraints and performance statements are decomposed to a detailed level that can be allocated to specific candidate design configurations. The output of this process is a functional baseline that describes the system functionality and is the basis for eventual customer sell-off. The functional analysis process is shown in Figure 6 - 3. This process is composed of two steps, functional identification and functional decomposition, which are described in the following paragraphs.
By clicking on the functional analysis process box in the IDEF figure, the last level of the system design process can be explored. The IDEF process model of this third level will be presented and textual descriptions of each subprocess may be obtained by clicking on the text button or by clicking on the link below. The system functional analysis process is composed of three primary subprocesses:
The RASSP architecture selection process transforms the processing requirements for each processing subsystem into a candidate processing architecture of hardware and software elements. The architecture selection process overlaps with the system definition process during the later portions of the system partitioning activity. A set of executable specifications is used to transfer the signal processor requirements to the architecture selection process. 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 performance is maintained.
VHDL is applicable for conveying system function, timing, and performance information and is used to develop a test bench and model of the signal processing system. Many efforts, some of which are being funded under RASSP, are focusing on conventions for associating physical information with VHDL models. As they become available, the methodology will expand to include their use with VHDL.
The system model captures the specification for the timing, performance, and function of the DSP system and its interfaces. It also contains a structural specification of its interfaces.
The test bench provides system stimulus and checks that the applicable system requirements are satisfied. As in all cases, the VHDL test bench is developed before the model it is intended to test. This ensures a thorough analysis and understanding of the requirements before and during design. In essence, the test bench is an interpretation of the aspects of the system requirements that can be described in VHDL, while the system model is an expression of the design solution that satisfies the requirements.
The system model forms an executable specification at the system definition level. The executable specification supports design-for-test (DFT), since the system test concepts must be considered and developed for its verification. The performance model is periodically back annotated with timing and performance data from the more detailed design levels. To continually ensure that system requirements are being met, the performance model is executed within the test-bench to verify continued compliance with the system requirements.
The executable specification consists of a test bench and a system model described in the following paragraphs.
The presence of COTS may throttle attempts to reach a singular life cycle test strategy. One reason is that black box COTS elements are usually tested functionally (for defect detection and isolation), while most of the rest of the design that is not black box oriented is usually tested using a great deal of structural testing and some functional testing. An analysis of the degree of anticipated COTS usage and the extent to which current COTS incorporates test features, would tend to allow an early, preliminary assessment of what plateau of test architectures might be possible
The impact of using COTS components during system definition is to place practical limitations on the test requirements and subsequent test strategies. For example, it does not make sense today to specify a requirement that can only be achieved with 100% boundary-scan, if a large part of the system will use COTS boards that do not come in boundary-scan versions.
The development of the fault model in this step is also affected by the presence of COTS, particularly if the COTS element is a "black box" in terms of its structural composition. Several options exist for handling fault models for black box COTS elements:
System Requirements Review (SRR)
The objective of the SRR is to determine that the customer requirements have been properly analyzed and translated into system specific functional and performance requirements. Typically, the SSR is held after the requirements have been analyzed, a preliminary functional analysis performed, and the requirements initially allocated to subsystems. During the SRR, we identify and quantify risks, and address approaches to manage these risks. We identify key technologies essential to system success and candidate technologies not viable for the system. We present the progress of on-going technical verifications, the preliminary functional analysis of the system, and the draft allocation of requirements to subsystems. The draft system specification is reviewed. During the SSR, we establish understanding of the customer requirements by identifying a complete functional baseline.
System Design Review (SDR)
The objective of the SDR is to ensure that the process used to determine the functional and performance requirements for the system is complete. We accomplish this by addressing the primary product and processes, by demonstrating a balanced and integrated approach to the development of the functional and performance requirements, by reviewing the audit trail established from the customer requirements, and by substantiating any requirement changes made since the SRR. The SDR is held after all system-level trade-offs have been performed, which resulted in an optimum allocation of requirements and functions to each subsystem.
During the SDR, we verify the performance, availability, and design suitability for critical products and process technology. We assess the adequacy, completeness and achievability of proposed system functional and performance requirements and present evidence to confirm that the system requirements can be met by the proposed system. The functional baseline for the system is established. We identify the draft specification tree, work breakdown structure, and risk handling approach for the next phase of the program. Pre-planned product and process improvements and acquisition strategies are presented.
Next: 7 Architecture Design Process Detailed Description
Up: Appnotes Index
Previous:5 RASSP Design Process Description
Approved for Public Release; Distribution Unlimited Dennis Basara