Time Segment 2

time Segment 1 Requirements

(Payload Scan Options & Sensitivity

Time Segment 2 Requirements


Time from Detection to Data Delivery

Initial Validation (PD/PFA, No. of Hits, ' Processing Time Given Detection)

, Downlink (Link Avail., Unk Acquisition/ Closure)

, Orbit and Attitude Determination

- Ground Look Point Determination

Completion of Ground Processing (Front End Pro-" cessfng Arch., No. of Channels, Process. Rate)

1 mln

3 mln 6 mln

2 mln

3 mln

3 mln 2 mln

. Confirmation of Fire (Auto vs. Manual, Number of Exploiters and Workstations)

i Data Preparation (Sorting, Formatting, Internal Routing)

v Queuing lor User Distribution (Sorting, Distribution, 3 mln Queue Processing)

k Distribution to End User (Network MgmL, Channel 2 mbi


5 mln 30 mln

Fig. 4-7. Mission Data Timeline and Requirements Budget The actual time from the detection of a fire to distribution of the time-urgent data Is related both to coverage and' specific timing requirements.

to meet this timeline is a significant cost driver, potentially replacing a "store and dump" approach appropriate for purely scientific missions.

Once the ground system receives the data it must process the data to format it, perform orbit, altitude, and ground-look-point determination, and then extract the relevant fire-detection data. A short time requirement here will likely demand real-time processing and a substantial capacity to support real-time operation. Identification and subsequent confirmation of a fire prior to broader dissemination may drive either a high performance pattern-matching process or manual processing in a time-critical fashion. Once the system confirms a fire, the data must be registered and prepared for distribution to appropriate end users. This preparation may involve merging it with standard data sets to support evaluating the fire at a later time. The data processing system must also queue die data for distribution over a network. Priorities and protocols may drive the management of input queues and network routing. Figure 4-7 shows the initial allocations for the components of Time Segment 2.

This example punctuates two critical activities: First, the components of a timeline must follow die step-by-step functional flow described in 4.2.1. The functions themselves may be strictly sequential or capable of being processed in parallel to shorten timelines. Functional representation diagrams and support tools (e.g., built-in simulation) can ease this evaluation. Second, there are numerous performance-cost trade-offs at each decision point which dictate the time-budget allocations. The objective is to meet the highest level requirement while equally sharing the potential performance risk and cost associated with meeting each derived requirement

4.2.3 Refining and Negotiating the Performance Budgets

System engineers must thoroughly understand how to develop and define requirements, then allocate and negotiate budgets associated with them. Failure to meet key budgets can lead to major system problems. Early definition permits the iterative process of adjusting allocations, margins and even operations well before major cost or schedule penalties occur.

Performance budgeting and validating key system requirements is the iterative process, as shown in Fig. 4-8. Before the process can actually start, however, the specific performance parameter and associated requirement statement must be clear and traceable to the mission need. The Quality Function Deployment methodology and several tools make this possible by maintaining the link between the need and the technical requirement in traceable documentation. Vague, inconsistent, or unquantifi-able requirements too often lead to inaccurate understanding, misinterpretation and/or exploitation. This applies especially to critical areas of system performance which without early and thorough interaction and/or prototype testing can become expensive and program-threatening later. We should also note that the iterative process includes negotiation and re-negotiation of budgets based upon evidence from the design process and the discovery of errors and "injustices" in the initial allocation.

We know of several programs in which major difficulties have resulted from conflict among requirements. One case involved the difference between operational availability of ground stations with that of the satellites in a system. Another involved the selection of the launch vehicle before a design concept was established, the requirements for the latter driving the mass far beyond the booster's lift capability. And in a third case, the changes in a customer's program management introduced new requirements for a payload which invalidated the flowdown of the original project requirements. The response to this required both data and persuasiveness, the latter being unfortunately insufficient until serious problems arose in the systems design.

An aside is worthwhile at this point on the issue of requirements-level vs. design-level budgeting. The system-level design is a logical integration or synthesis of segment designs. Defining functions and their performance requirements and those interfaces requiring support lays the framework for deciding "how" to design each segment For FireS at, this relates to the accuracy of the geolocation and the allocation to segments of ephemeris, attitude, and other contributions. The "how" relates to space segment hardware decisions such as whether to use star sensor or gyro performance to achieve the required attitude accuracy. But such decisions affect mission operations which must then schedule star sensor calibration and gyro alignment so the spacecraft

System Concept

System Performance

Parameter & — Requirement Language

System Concept

System Performance

Parameter & — Requirement Language

System4evel Validation Testing

0 0

Post a comment