tor Detail Design

Progression of QFD Process. Illustrated Is the derivation of successive "What" aspects from previous levels' responsive "Hows."

Thus the QFD is a structured means for a design team to address customer needs and to develop the consequent design characteristics to satisfy them. It also serves to sustain the trail of requirements derivation and provides a means for analyzing the impact of changes to requirements at any level. And since we can link the technical attributes responsive to needs, to functions of the system, there is a logical translation to functional analysis via functional flow diagrams and thence architecture and interface definitions.

As an added note regarding understanding the customer, I know of several satellite projects that have had little success as commercial ventures because the contractor's designers established requirements based on their own interpretation of potential customer needs. This was also the cause of a major military satellite contract loss to the competition due to inaccurately presumed knowledge of customer's desires. The voice of the customer must be heard before fixing a design.

4.2 Requirements Analysis and Performance Budgeting

We must decompose every system requirement into progressively lower levels of design by defining die lower-level functions which determine how each function must be performed. Allocation assigns the function and its associated performance requirement to a lower level design element Decomposing and allocating starts at the system level, where requirements derive directly from mission needs, and proceeds through segment, subsystem, and component design levels. This process must also ensure closure at the next higher level. Closure means that satisfying lower-level requirements ensures performance at the next higher level, and that we can trace all requirements back to satisfying mission needs. This emphasizes the iterative character of the requirements development process.

Figure 4-4 shows how a single mission need—the FireSat geopositioning error— flows through many levels of design. Errors in the final mission data depend on many sources of error in the processing segments for space, mission control, and mission data.

Fig. 4-4. Allocation from Mission Requirements through Component Design. Understanding the sources contributing to top-level requirements is essential.

Two important observations are necessary. First, the system encompasses more than the spacecraft, and errors come from numerous segments. The accuracy of the geolocated object in a FireS at image is driven by much more than the spacecraft's pointing capability. Second, while the,number of error sources is large, they are not all equal. Many are predictable and relatively constant—star catalogs and Earth ellipsoid estimates. Others are more variable, but small and not significant drivers for cost or technology. The remaining errors are those which are most amenable to cost-performance-risk trade-offs and need the greatest level of attention during requirements flowdown and validation.

4.2.1 Functional Analysis

The simplest way to represent functions—or actions by or within each element of a system—is through a functional-flow block diagram. As Fig. 4-5 shows, we define the topmost or first level functions of a system in the sequence in which they occur. Successive decomposition permits identifying how a system works at each level before proceeding to lower levels. For example, to address sensor misalignment three levels down in the functional flow (Function 4.4.4 in Fig. 4-5), it is necessary to consider the production (1.0) and integration (2.0) phases, which require manufacture and validation within reasonable tolerances.

Fig. 4-5. Functional Hows Generating Geo positioning Information for Fire Sat Mission.

The functional flow defines what Is to be done hi a hierarchical framework. Additional features can be added to the representation (e.g., data Interfaces, control sequences) using different diagramming techniques.

Fig. 4-5. Functional Hows Generating Geo positioning Information for Fire Sat Mission.

The functional flow defines what Is to be done hi a hierarchical framework. Additional features can be added to the representation (e.g., data Interfaces, control sequences) using different diagramming techniques.

Once we establish the top-level functions and sequences, we can decompose and analyze each function throughout the remaining layers of the flow. For example, determining geopositioning data (Function 4.4 in Fig. 4-5) for FireSat requires a sequence of actions, from estimating key spacecraft and payload parameters to deriving local Earth coordinates. Functional decomposition, regardless of how formalized, is necessary in allocating design characteristics at each level of system architecture (the organization of system elements into a structured hierarchy). This organization permits us to allocate performance budgets together with other budgets affecting cost and risk.

We can also use functional flow diagrams to depict information or data flow, as well as control gates governing function sequencing. Information may include interface data flowing between functions, control relationships showing what must happen before another function can begin, or data sources and destinations.

In applying these techniques, we may use manual methods, particularly for ample systems, for top-level mission descriptions, but CASE (computer-aided system engineering) tools facilitate diagramming decompositions and maintaining traceability. But as with other computer applications, the software for developing diagrams and maintaining support databases does not drive the analysis. In fact, the functional framework which evolves is often a compromise among estimates of performance, cost, schedule, and the risk associated with each decision. (McClure [1988] and INCOSE Sixth Annual Proceedings [1996] provides an interesting discussion of support tools and techniques.)

422 Initial Performance Budgets

Analyzing requirements leads eventually to hierarchically organized performance metrics and budgets for the interactive development segments. The iterative process starts with budgets derived using analysis, simulation, known design or test data, and a large measure of experience. We should note that in the development of requirements and derived functions, mission drivers must be the primary drivers.

Experience or related reference missions are especially important in developing the initial performance budgets to meet system performance requirements. In the example of Fig. 4-5, the geopositioning accuracy reflects this. The major trade-offs and focus for validating performance therefore reside in how accurately the system can estimate and control position and attitude, and we must evaluate the options considered against not only performance requirements but also cost and schedule.

Figure 4-6 illustrates the combined effect of spacecraft attitude and position errors on the geopositioning estimate's accuracy in locating fires. In this simple example, three broad options are possible. The first option gives a very loose spacecraft position budget, which permits only limited support from the GPS and/or remote tracking stations. However, it requires a tight attitude budget, which is likely to create problems for both the space and mission control segments. Though payload sensitivity and resolution drive the selection of the FireSat oibit envelope, using a low-Earth oibit could severely affect attitude accuracy because of atmospheric drag. A higher altitude would reduce drag, but produce even tighter pointing tolerances. Thus, two main costs make this a poor budget option: the satellite's subsystem for controlling attitude and the potentially taxing calibration which the mission control segment must perform on the attitude sensors.

At the other extreme, leaving the attitude budget loose and tightly estimating spacecraft position can have risks if a full GPS constellation is not in operation. Using GPS

Geopositlonlng Error

0 0

Post a comment