Info

r Table 11-29

Fire Sat Example

Uncertain <200

Computer or stored commands, not both

<200 Low

150 Mbps No

Yes No

Uncertain

LightSat bus 0.98 5 years

Must be SEU hard 2-year development Low

See Table 11-28

Mission time clock to be included in telemetry component of C&DH (critical to correlate data with time of day)

See Table 11-29

Issues or Data Needed

Command Processing

Is command processing required? If Yes,

- What is the command rate?

- How many channels?

- Is there a computer?

- Are stored commands needed? Telemetry Processing

Is telemetry processing required? If Yes,

- How many channels?

- What Is the housekeeping data rate?

- What is the payload data rate?

- Is a computer interface needed? Other

Mission time clock needed? Computer watchdog needed? ACS functions needed?

Bus constraints

Reliability

Satellite Lifetime

Radiation Environment

Schedule

Budget

Evaluate each function separately

Are other functions such as the mission time clock combined into command or telemetry (typically telemetry)?

Combined systems (share housing, reduce Interface cabling, may share power supply)

| Procedure

Determine or estimate what on the spacecraft must be controlled and what must be monitored to accomplish or support the mission. Determine what tasks are to be performed on board.

Determine the parameters, driven by aspects of the overall spacecraft design, which impact the C&DH system (the C&DH drivers).

Use Table 11 -28 to estimate the complexity of each function identified In step 1, applying constraints established in step 2.

Collect functions into command and telemetry components and determine composite complexity of eaoh

Apply results of step 4 to Table 11-29 for command and telemetry components

Step

1. Identify which functions are to be performed by the C&DH system

2. Identify requirements and constraints

3. Determine complexity of C&DH functions

4. Determine overall C&DH level of complexity

5. Estimate size, weight, and power for each component

We must include the capability to store commands if we require spacecraft control when its not in view of its ground stations, or as a means of recovery if the communication link is lost These commands may be controlled by matching a time-tag or by a simple delay counter from a controlled timing event Stored commands of this type may be easily implemented without a general-purpose processor.

We must add an onboard computer if we require a decision-making element on the spacecraft Once we establish the need for a computer, we can plan to use it to perform many functions including the stored command capability, attitude control algorithms, and data processing and storage. Integrating attitude control with the command system will typically add some special interface requirements for driving control elements.

Telemetry Processing

The data handling system provides the ability to acquire data for:

• Spacecraft housekeeping data (health and status)

• Feedback for onboard control of spacecraft functions

• Routing of payload or subsystem data to and from receivers and transmitters, storage or affected system controllers

The quantity of telemetry input channels required for monitoring spacecraft health is typically directly proportional to the size, complexity, and quantity of payloads and subsystems involved in meeting the primary and secondary missions. The majority of these channels are standard interfaces to temperature, pressure, and voltage transducers. Some subsystems provide the ability to monitor their own health and integrate the information into a data stream. For new subsystems, the awareness of what ihe data handling system can do for them may prevent an unusual design or duplication of a large amount of circuitry.

The data handling system may acquire payload or subsystem data also. Of critical importance to the system design is the quantity of data and its transfer rate. The telemetry acquired for spacecraft health is limited in speed due to the time necessary to accurately convert analog signals to digital information. If a subsystem or payload data stream exceeds 200 kbps or is greater than a few thousand bits in size, it is usually necessary to provide data buffers or to process the data in a separate section of the data handling system. Often, an interleaver may be provided to integrate and synchronize the health and payload data into a single stream.

If an onboard computer is available, it may require additional signals to perform its tasks. These signals may not be needed in the downlink telemetry format Therefore, it is usually preferable for the computer to have the capability to request data independently of the preprogrammed downlink format The computer may also be used to preprocess subsystem and health data to reduce the downlink bandwidth requirement. (See Chap. 16 for a discussion of onboard processing.)

Other Functions

Time. Most spacecraft designs require the availability of a time word (universal time, mission elapsed time, or delay) for support of attitude control, stored commanding, or data time-tagging. Several systems can provide this time, including GPS receivers, computer-maintained counters, and hardware timers. The most critical parameters for the definition of this function are:

• Time word granularity

• Acceptable uncertainty

Granularity defines the smallest increments of time maintained for use on the spacecraft or of interest on the ground. This value is usually driven by the accuracy of time needed for data time-tagging or the attitude control system. Typically this is one millisecond or one microsecond. Over specifying this value will increase the hardware required, increase the cost, and decrease the available bandwidth for data. IRIG-B time code generators transmit a 1-sec resolution time word and a 1-MHz oscillator to allow the user to create their own smaller granularity time.

The aging characteristics of the primary oscillator, which drives the timing system, determines the drift characteristics of the time word. Oscillators are typically specified by long-term and short-term stability in parts per million (ppm) over a given time. Selection of this stability determines the allowable error in the onboard time between time updates from the ground. The same stable oscillator may be used to provide other oscillator frequencies to other spacecraft subsystems. Occasionally, the stability needed by the other system may be the driving factor.

Maintaining time with the spacecraft computer is possible using internal registers and a periodic interrupt signal. However, additional uncertainty may be induced due to the nonsynchronous nature of a processor under interrupt control. Higher priority interrupts may delay the update of the time word. If other subsystems need a time base, the designer must include additional registered circuitry.

Computer Watchdog. When a spacecraft computer is used to provide decisionmaking capability on orbit, it is common to provide a method of determining a computer failure independent of the processor itself. This function may be integrated into the C&DH system and is usually referred to as the watchdog timer.

The watchdog timer ensures that the computer hardware and software functions as planned. A hardware or software anomaly could be catastrophic to the spacecraft mission if we don't provide a means of correcting the problem. Typically, this function uses one or more timers which must be reset by the onboard computer prior to timing out The computer resets the timer by writing a specific data word to a specific address. If this is not accomplished prior to die time-out, the watchdog will execute a predetermined recovery action. The recovery may be a computer reset, interrupt, or a disable which is maintained until cleared by a ground command.

Attitude Control System Functions. Integrating attitude control functions into the C&DH system may reduce the hardware required on the spacecraft by taking advantage of C&DH circuitry that is available in other subsystems. The integration of command, telemetry and onboard computer functions allows closed-loop monitoring and control with the addition of interface channels specific to the attitude control function. These channels may be high current, high accuracy, or other special requirement interfaces. In some cases, the attitude control section provides only controlling signals, with the high power and signal conditioning circuitry integrated into the attitude control component

Spam. As the baselining process continues, we develop an estimate of the I/O channel quantities, and use this estimate in step 3 to estimate system parameters. Unfortunately, I/O channel quantities tend to increase, as the spacecraft becomes more defined. Therefore, it is common practice to include 10% to 25% additional channels in the count for unforeseen growth requirements. We should use the channel count, including spares, to estimate system complexity in Table 11-28. This estimate must be documented carefully to prevent several increases as the concept proceeds through the various departments and levels of management involved in the spacecraft design. As always, more hardware increases the cost, size, weight, and power of the system.

Step 2—Identify Requirements and Constraints. Once the functions required by the command and data handling system have been determined, requirements and constraints imposed by external factors must be identified. We don't control these requirements and constraints and they may affect one or more aspects of the C&DH system design. Early identification and response to these issues may minimi7p the cost impact and design problems.

Spacecraft Bus Constraints. The physical size of a spacecraft and its design will often direct the ultimate configuration of the command and data handling system. In general, the C&DH system may be divided into three classes or architectures:

• Single-unit systems

• Multiple-unit, distributed systems

• Integrated systems

A single-unit C&DH system provides one unit for the command system and one unit for the telemetry system or a single unit which integrates both functions. Although the single-unit design may be simple and centralize functions, it can have a significant disadvantage on a medium to large spacecraft bus. As mentioned previously, a larger spacecraft will generally require a larger number of subsystems and associated interfaces and health monitors. A single-unit system requires every interface wire to be routed to a single physical location for monitoring and control. The result can be a wire harness that is larger than the unit itself and significantly impacts the weight budget

Multiple-unit C&DH systems provide a potential solution to this problem and others. A multiple-unit system provides "remote" command and data handling capabilities in locations physically removed from the "central" unit The number of remotes is driven by the spacecraft bus design or the quantity of 170 channels. One example is the design of a dual-spin satellite in which every signal must be transferred between the spinning and fixed sections of the satellite over a slip-ring interface. Slip rings limit the quantities of signals which may be practically routed and also complicate the design due to induced noise. One practical solution is to provide a remote unit on the spinning side which communicates with the central unit over a digital data bus. This allows the acquisition of hundreds of channels on the spinning side while requiring only 2 to 6 wires to pass through the slip rings.

Integrated C&DH systems typically combine command, telemetry, flight processing, and attitude control into one system. These systems tend to be small LightSat-type applications which use a single computer to monitor and control the satellite or a large high-performance system which uses multiple computers and subsystems coordinated by a central high-power processor. This type of system may provide a reduced hardware requirement and cost due to the increased capability provided by the processor. However, this system will most likely entail increased software costs associated with the increased programming requirements.

Reliability. The reliability required of the C&DH system will affect the system design in two areas: redundancy and parts quality. A low failure rate for the system provides a high confidence factor in the success of the mission. Reliability is dramatically increased by including a redundant system for all mission-critical components. Configuring a system in this manner will obviously increase the amount of hardware involved. More hardware means increasing the recurring cost, but not necessarily double the total procurement cost Many cost items involved in manufacturing the system are fixed whether a single-string or redundant system is built

Parts quality also affects the reliability of a system. Increasing the parts quality does not increase the amount of hardware; however, it does significantly increase cost Specifying a Class "S" parts program (or indirectly requiring it via the reliability requirement) typically multiplies the material cost by 400% to 500%.

Radiation. The areas affected most by the radiation requirement are cost and schedule. System size and weight may be affected if we require shielding of electronic components. A radiation environment limits the part types available to the designer and system performance is typically lower due to required derating. Predicting circuit behavior is accomplished by modeling, simulation, and analysis. Environment severity may double system development time and increase parts costs by a factor of 10.

Program Constraints. The foundation of any hardware development program lies in the constraints placed upon the program to carry out the mission. In some cases, program constraints initially restrict a design so the desired mission cannot be accomplished. The budget allocated for the program will typically be the most limiting constraint in the development of the spacecraft and, in ton, command and data handling. Allocating a budget for a LightSat will clearly preclude developing a spacecraft and support systems for a national-asset satellite.

If managers define a budget, it will become the primary driver in determining the other elements of the definition process. In the case of a preliminary study, the objective may be to define the budget needed to achieve the desired mission goals. In this case, the later steps become the determinant and the dollars needed become the output of the process.

The second significant program constraint is commonly schedule. Most space-qualified electronic systems are custom designs or semicustom implementations of existing hardware. The need dates for hardware may completely determine which approach we take to develop hardware. Typical lead times for command and data handling equipment are 12 to 18 months for systems using Class B parts and 24 to 30 months for systems using Class S parts. These schedule times are almost completely driven by the lead time involved in the procurement of electronic piece parts. Therefore, a fast delivery requirement to support an urgent mission will affect the parts and reliability level of the unit

Step 3—Determine the Complexity of C&DH Functions. Table 11-28 may be used to provide a first-order estimate of the complexity of each C&DH function. There are no absolutes in this stage of the process. The estimate is the result of the C&DH "feel" obtained by comparing known general requirements with those listed in the table. The result is a bounding of the system definition into one of three zones. We must define C&DH system drivers which may move the components between zones in the case of an unclear definition. Once a determination is made on the function complexities, steps 4 and 5 provide an estimate of the system size, weight, and power specifications. As can be seen in the FireSat example, all the requirements do not have to be defined to make a first-order estimate.

Step 4—Determine Overall C&DH Level of Complexity. Functions described as "other" are now collected into the command and telemetry components. Typically, the mission time clock is included in the telemetry component The computer watchdog is included in the command component because a computer failure often requires spacecraft reconfiguration via the command system. ACS functions are included in both.

"Eg il

0 0

Post a comment