Software System Structure

21.1 General Structure for Attitude Software Systems

21.2 Communications Technology Satellite Attitude Support System

213 Star Sensor Attitude Determination Systems

Components of a Star Sensor Attitude Determination System, Construction of Batch and Sequential Attitude Systems

21.4 Attitude Data Simulators

This chapter describes the overall structure of attitude support systems as they have been used for mission support in the Attitude Determination and Control Section at NASA's Goddard Space Flight Center. Section 21.1 gives the general framework that has proved useful in mission support. Sections 21.2 and 21.3 illustrate how this was implemented in attitude software for particular mission types. Section 21.4 briefly describes the function and operation of attitude data simulators.

21.1 General Structure for Attitude Software Systems

Myron A. Shear'

The requirements for attitude support software systems vary considerably from mission to mission, depending on spacecraft and ground support hardware, data volume, telemetry format, and the mission timeline. However, certain features are common to most attitude support systems, and there is a general software structure which has proved useful for a variety of missions. This section describes that general structure and discusses the tradeoffs to be considered when modifying this general structure for special mission requirements.

The basic software requirement for most missions is to take spacecrafts telemetered data and perform ground processing to determine the attitude. These attitude results may then be used to compute control commands which are?-* transmitted to the spacecraft. The computation of control commands is typically, though not necessarily, done with a separate software system. As discussed in the introduction to Section 20.1, attitude determination requirements may be either real time, near-real time, or definitive, depending on the time constraints. For* tunately, the same software system can often be used to satisfy all three requirements if appropriate options are provided to handle each mode of operation.

Figure 21-1 shows the general structure for a typical attitude support system used in the Attitude Determination and Control Section at Goddard Space Flight Center. This system consists of several processing subsystems, operating under the control of a driver and utilizing a graphics package (see Section 20.2) to provide interactive graphics capabilities for all subsystems.

The telemetry processor subsystem reads the raw telemetry data set, constructs frames of data from the telemetry stream, and converts data from binary-coded

Fig. 21-1. General Structure for an Attitude Software System. Arrows indicate direction of data flow.

values to engineering units. (Chapter 8 contains a detailed discussion of data transmission and manipulation up to and including the telemetry processor.) The data preparation subsystem performs data selection, editing, smoothing, calibration, and adjustment, with or without operator interactive control (see Chapter 9). Here, the data can be displayed in tabular or graphical form so the operator may examine it for anomalies. By this point in the processing, absolute times should have been attached to data items so that ephemeris data can be obtained. The required ephemerides may include the spacecraft, the Sun, the Moon, planets, stars, and the E&rth's magnetic field, depending on the sensor hardware used.

The deterministic attitude subsystem is normally used next to obtain a rough attitude for control purposes or an initial attitude estimate for the state estimation subsystem. Deterministic methods, discussed in detail in Chapters II and 12, are advantageous because they can be used in the absence of an a priori attitude and in the presence of a substantial amount of spurious data. However, deterministic methods are generally limited to solving for not more than two or three parameters. Thus, sensor bias determination and calibration cannot be done in the deterministic subsystem, and the presence of these systematic errors will generally limit the accuracy of the deterministic solution. However, deterministic processing may still use a significant amount of computer time. For example, horizon sensor data may require iterative techniques to resolve attitude and central body ambiguities and to reject spurious data and terminator crossings. Similarly, star sensor data may require complex star identification procedures.

In contrast to the deterministic subsystem, the state estimation subsystem will generally assume that an accurate a priori attitude is available and that spurious data points have been rejected. Therefore, this subsystem can use least-squares state estimation techniques (described in Chapters 13 and 14), such as Kalman filtering, recursive estimation, or differential correction, to solve for a state vector with perhaps.a dozen or more parameters, including the attitude, sensor biases, and attitude dynamics. The sensor biases determined in this subsystem may subsequently be used by the deterministic subsystem to improve the accuracy of the deterministic results for subsequent data passes.

Not all missions require both a deterministic and a state estimation subsystem; if an accurate a priori attitude is available, for example, from an onboard control system, then it may be possible to eliminate the deterministic subsystem. However, some form of attitude initialization may still be required to determine an a priori attitude immediately after launch. Conversely, if the attitude accuracy requirements do not necessitate bias determination (or if the spacecraft dynamics or mission timeline do not permit bias determination), the state estimation subsystem may be eliminated.

The "other capabilities" of Fig. 21-1 will depend on mission characteristics and may include routines to monitor maneuvers in real time, predict the availability of future data passes, compute control commands, or perform solution logging and data archiving functions. These capabilities may be provided in separate software systems or designed as subsystems invoked from the driver. The tradeoff here involves speed and ease of operation versus programming complexity and ease of maintenance. Separate utility programs are generally easier to develop and maintain because interfaces are minimized. If a separate graphics device and other computer resources are available, then the utility program can be executed concurrently with the main attitude system. However, if the main attitude system must be terminated to provide resources for the utility, then the extra time involved in terminating and reinitializing the attitude system must be considered, especially for near-real-time applications.

The general structure described above has been used successfully on many missions including CTS, GOES, SIRIO, RAE, IMP, SMS, ISEE, and IUE. The success of this structure is due primarily to its modularity and flexibility. A modular structure implies that each subsystem has a minimum number of interfaces with each other subsystem. This results in ease of development and maintenance, because subsystems can be developed concurrently and almost independently. When modifying the system for future missions, it may be possible to replace only the telemetry processor subsystem and support a spacecraft with a totally différent telemetry format but similar sensor hardware. System flexibility results from the fact that subsystems can be invoked in almost any sequence, under operator control. For example, attitude processing can be repeated on the same data using different processing options without repeating telemetry processing, data preparation, and ephemeris accessing. Similarly, state estimation can be (and usually is) repeated, many .times, solving for a different set of parameters or changing the filtering options, without repeating the deterministic attitude processing. Thus, the system minimizes execution time for the most frequently repeated functions.

The modular system also lends itself to a simple overlay structure, allowing each subsystem to share the same core storage. The system provides interactive graphics control at each step in the processing; we have found this to be essential 1

in attitude support systems to handle the unpredictable problems that occur in real data, requiring operator intervention to select and edit the data and ensure the quality of the attitude results.

There are several ways in which this general structure can be modified to handle special requirements. The structure in Fig. 21-1 assumes that all the subsystems are part of the same program and that core storage interfaces are used for communication between subsystems. This arrangement is used for CTS, as described in Section 21.2. However, one or more of the subsystems could be implemented as Separate programs and one or more of the subsystem interfaces could be implemented via data sets. The tradeoffs here are among program complexity, computer resources, and operational timeline requirements. For example, the telemetry processor could be split off as a separate program which could then operate on a minicomputer. This would have the advantage of freeing resources on the primary computer; however, it would have the disadvantage of reducing the flexibility and ease of operation of the attitude system. If the telemetry processor incorrectly constructed frames from the telemetry stream, there is no way the attitude system could correct this error in the processed telemetry, and it would be necessary to reexecute the telemetry processor with different processing options. This could require a human interface between the primary computer and the minicomputer, which, for real-time operation, might prove impractical. Similarly, a hardware failure on the minicomputer would be just as serious as a failure of the primary computer, increasing the risk of computer failure for real-time and near-real-time requirements.

As another example, the state estimation subsystem could be a separate program, interfacing with the remainder of the attitude system via a data set containing preprocessed telemetry. This arrangement is anticipated for MAGSAT processing. In this case, the state estimation system could be run on another computer to distribute the computing load and allow the real-time requirements of the deterministic attitude system to proceed concurrently. The major advantages of a separate program are ease of maintenance and simplification of the interfaces; the major disadvantages are the increased operational difficulty involved in creating and maintaining the interface data set, the time delay involved in an extra processing step, and the reduced flexibility which results from not being able to reaccess the original telemetry data from the state estimation system.

Data set interfaces between subsystems can be used even if the subsystems are combined in a single program. A data set interface requires .additional I/O processing time; there is not necessarily any reduction in core storage because generally at some point a block of data for processing must still be held in core. However, a data set interface reduces the possible interaction between subsystems and thus reduces interface problems. If the observations can be processed singly in the attitude determination subsystems, a data set interface can reduce core requirements. In this case, a data set interface is probably more convenient than the alternative of cycling between the telemetry processor and the attitude system for each observation. Data set interfaces can also provide for a more rapid restart and reduce the need for reprocessing in the event of machine failure.

The use of separate programs does not necessarily imply data set interfaces. Core storage interfaces can be used between separate programs, even operating on separate machines; however, the use of a core interface tends to increase the interdependency of the programs, thus reducing the advantages normally associated with separate programs. For this reason, and because additional system software is required to interface^the programs via core storage, separate programs are normally interfaced via data sets.

For real-time maneuver monitoring, special capabilities must be provided to minimize or eliminate the need for operator interaction. In real-time operation, the telemetry processor normally reads one or a small number of data samples, and the driver automatically invokes the data preparation and deterministic attitude subsystems to process this small set of data. Then a special maneuver monitoring subsystem is invoked to generate displays showing the actual maneuver trajectory versus the expected or desired trajectory. Computed results are also displayed to indicate whether the maneuver is within expected tolerances and to warn of any potential problems, such as violating Sun angle constraints or maneuvering outside antenna coverage. While these displays remain on the screen, program flow returns to the telemetry processor to read all the data which have been received since the previous call to this subsystem. Typically, a complete cycle through these subsystems will take 10 sec or less, which is well within the real-time requirements for a system which operates with a manual interface to the control center. If the real-time control requirements were much more severe than this, the manual interface would have to be eliminated and the control loop would have to be closed within the support computer (see Section 19.5.1). This would require much more sophisticated control monitoring software to make reliable' control decisions without operator assistance. Fortunately, most missions are designed to make this type of ground-based, closed-loop control unnecessary.

21.2 Communications Technology Satellite Attitude Support System

Gyanendra K. Tandon

As an example of the general structure discussed in Section 21.1, we describe how that structure was implemented for the Communications Technology Satellite (CTS) Attitude Support System. This system provided adequate computational support throughout the CTS mission, even when a balky latch valve in the control system caused substantial changes in the nominal timeline. During this emergency situation, the system provided all the information needed to define an alternate timeline in real time.

The CTS Attitude Support System consists of two major programs: the CTS Attitude Determination System, CTSADS, and the CTS Maneuver Control Program, CTSMAN. In addition, the following utility programs were available for use: the CSMP/AMF Dyanmics Program (Section 17.4); simulators CTSSIM and ODAP (Section 21.4); the orbit geometry program OSAG (Shear. 1972]; and a set of standard programs for checking, archiving, and purging the data from the attitude data link, ADL, file (Section 8.1) and for checking the archived data.

The basic system structure and data flow of the CTSADS system [Nelson, et al., 1975], are shown in Fig. 21-2. Graphic displays of control parameters and data are available throughout the system for controlling and monitoring program operation. Input to the system includes control parameters via NAMELIST data sets or cards for each subsystem, although these are not shown in Fig. 21-2.

CTSADS uses the Graphic Executive Support System, GESS, described in Section 20.2 for operation on an IBM 2250, or a Data Disc 6600 graphics display device. GESS provides execution sequence control, data management, error recovery, and graphic services. The driver is the main control module of CTSADS, providing the interface between the GESS executive and each subsystem in CTSADS. It permits the operator to select any desired subsystem or to terminate the job. CTSADS can also be executed in a nongraphic mode for analytical purposes.

The CTSADS program consists of seven major subsystems and an attitude status file subsystem (not shown in Fig. 21-2) used for writing the current spacecraft attitude to a direct-access disk file. The seven major subsystems are as follows:

1. Telemetry Processor. This subsystem reads the raw telemetry data provided by the control center (see Section 8.1) on disk or tape and provides the attitude determination system with the spin rate and Sun and Earth sensor data. During attitude maneuvers it also provides the engine firing pulse counts to the control monitor subsystem. In addition, it can perform three levels of telemetry time checks (Section 8.3) and three types of data smoothing (Section 9.2).

2. Data Adjuster. The data adjuster selects a working set of the telemetry data and obtains the corresponding ephemeris information. In addition, it provides the operator with options for selecting a subset of the data, smoothing or adjusting data, overriding individual values, rejecting invalid data points, and selecting the ephemeris sources. The operator can examine the data both before and after adjustment, using a variety of character and plot displays.

3. Deterministic Attitude. The deterministic attitude subsystem computes the attitude using any combination of seven deterministic methods; each method uses a closed-form analytical technique to compute one or more attitudes from a pair of observables (see Section 11.1). These single-frame attitude solutions are then averaged to resolve the ambiguous solutions and yield a best estimate of the average attitude over a block of data. During the attitude maneuvers, the best estimate of the average attitude for each single frame of data is determined and is passed to the control monitor for maneuver monitoring.

4. Bias Determination. The bias determination subsystem is used to determine attitude and sensor biases using either a least-squares differential correction or recursive estimation procedure. The program uses up to five observation models to solve for any subset of up to 20 state vector elements. Details of observation models and filtering techniques are described in Chapter 13. This subsystem and the differential correction subsystem provide two alternative programs for bias and attitude determination.

5. Differential Correction. The differential correction subsystem provides an alternative approach to attitude and bias determination and serves as a backup to the bias determination subsystem. It first converts the raw data (Sun angles, spin rates, and Earth times) into arc lengths and/or rotation angles. Based on these angles, the subsystem uses a least-squares state estimation algorithm (see Sections 13.4 and 13.5) to solve for a state vector which includes separate biases in each type of arc-length or rotation angle measurement or to solve for polynomial coefficients for right ascension and declination as functions of time, up to first order. The biases here are numerically convenient parameters in contrast to the physically motivated parameters of the bias determination subsystem.

6. Predicted-Versus-Observed Plots. This subsystem provides the operator with a visual display of the observed Earth sensor data compared with the Earth sensor data predicted using any specified set of attitude and bias parameters. These plots are used to evaluate the attitude and bias solutions obtained by the various subsystems. The plots can also be used as a backup method of attitude and bias determination, by varying the state parameters manually to obtain the best fit to the data. In addition, the predictions can be generated for arbitrary times to determine data coverage for future data passes. For examples of these plots, see Section 9.4.

7. Control Monitor. This subsystem monitors attitude reorientation maneuvers in real time, to determine whether they are proceeding in the right direction at the proper rate. In the monitor mode, the system automatically cycles through the telemetry processor, data adjuster, deterministic attitude, and control monitor subsystems. Ordinarily on each cycle, a single telemetry record (10 sec of data) is retrieved from the raw telemetry data file and processed through each applicable subsystem. The control monitor accumulates the results from processing each record and updates displays which show the observed attitude motion versus the predicted attitude motion as obtained from the predicted maneuver file. The predicted maneuver file is generated by the CTSMAN program described below. The control monitor can also compute new command parameters necessary to correct a maneuver if it is not proceeding as predicted.

Figure 21-3 shows the normal operating procedure for attitude determination. In CTSADS, the subsystems may be invoked in any desired order. However, the data adjuster -must be executed immediately after the telemetry processor to select data'for processing and to choose ephemeris options before any other subsystem can be executed. The routine steps followed for determining an attitude solution from a batch of data are delineated in Fig. 21-3.

Figure 21-4 shows the data flow during maneuver monitoring. The control monitor first reads the predicted maneuver file to obtain the predicted attitudes

ma r repeat BMS de termination usino different subset of state vector elements

Fig. 21-3. Normal Operating Procedure for Attitude Determination Using CTSADS

ma r repeat BMS de termination usino different subset of state vector elements

Fig. 21-3. Normal Operating Procedure for Attitude Determination Using CTSADS

Was this article helpful?

0 0

Post a comment