Software System Development

20.1 Safeguards Appropriate for Mission Support Software

20.2 Use of Graphic Support Systems

203 Utility Subroutines

Vector and Matrix Algebra Routines, Time-Conversion Routines, Ephemeris Routines, Plotting Routines

In practice, much of the time devoted to preparation for mission support is spent in the development of computer software systems. Although some progress has been made in the standardization of software, the variations in attitude determination and control hardware, mission requirements, and processing sophistication have meant that most spacecraft series have required largely new attitude determination and control software systems. Therefore, questions of software structure and performance are central to the practical problems of mission support. This chapter describes the general principles for the development of attitude software and the use of executive support systems and utility subroutines.

20.1 Safeguards Appropriate for Mission Support Software

Myron A. Shear

Attitude determination requirements may be divided into three categories: real time, near real time, and definitive. A real-time requirement implies that attitude must be determined within seconds of the receipt of data and is usually associated with monitoring an attitude maneuver or attitude acquisition sequence. A near-real-time requirement implies that attitude must be determined within minutes or hours of the receipt of data, usually to compute control commands to achieve or maintain a desired attitude. A definitive requirement implies that an accurate attitude history is to be generated, perhaps weeks or months after the fact, generally for use in analysis of experimental results. The most critical demands on mission support software generally arise in real-time or near-real-time support, when results must be obtained shortly after the receipt of data. Failure to obtain accurate results within the prescribed time may jeopardize the success of the mission. Therefore, software intended for use in real-time or near-real-time mission support must be designed to meet particularly high standards of reliability, flexibility, and ease of operation. In some missions, even a minor software error could lead to total mission failure; furthermore, software must be capable of handling contingencies as well as nominal mission conditions. For example, if one attitude sensor fails, the software should still be capable of supporting the mission to the extent that the remaining attitude sensors permit. In real-time and near-real-time support, there is no time to make software modifications either to correct errors or to add new capabilities. Even a minor modification to a large software system may require hours or days to implement and the system reliability would be in doubt until extensive testing had been performed. For these reasons, specific safeguards should be considered in the design, implementation, and testing of mission support software. This section describes some of the safeguards used in mission software developed for the Attitude Determination and Control Section of NASA's God-dard Space Flight Center.

The software environment for mission support programs at Goddard Space Flight Center is typically a multiprogrammed, large-scale computer with interactive graphics terminals, card readers, printers, and other peripheral devices. Mission support programs are assigned relatively high priority, and nonmission support programs are run only as resources permit. Most mission support software is designed for interactive graphics operation, primarily because of the greater flexibility provided by allowing an analyst to examine the input data and program results and change the processing options accordingly. Graphics operation, described further in Section 20.2, also allows rapid correction of user input errors. Nongraphic systems utilizing card input and printed output are normally limited to utility programs which do not directly process telemetry data and, therefore, require fewer processing options. The safeguards discussed in this section can be applied to either nongraphic or graphic systems.

Error Checking. If a program terminates unexpectedly and must be restarted, a period of 15 minutes or more may be required to resubmit the job, schedule the required resources, and initialize the program. A delay of this magnitude is unacceptable in real-time support, and very inconvenient in near-real-time support. For this reason, mission support software must be fully protected against failures due to user errors or unexpected telemetry data. An interactive graphics program must not be allowed to terminate abnormally except for the most severe error conditions; most common errors can be corrected by the user if the program provides appropriate error messages. Thus, mission support software must check for all foreseeable error conditions, provide standard corrective actions whenever possible, or provide an error message which is clear enough to allow the user to diagnose and correct the problem promptly. If further diagnosis is required, the user must be able to request intermediate displays to obtain additional information.

User input errors are almost inevitable; these may be simple typographical errors, or logical errors resulting from specifying an inconsistent set of input parameters. The program should check user input parameters for validity, especially in cases in which a user input error could lead to abnormal program termination. For example, ^ user error which leads to overfilling an array or infinite looping may result in a program termination which is difficult to diagnose and relate to the original error.

Potential mathematical singularities should also be checked to avoid errors such as division by zero, square root of a negative argument, or inverse trigonometric functions of invalid arguments. These singularities may result from user input errors, invalid telemetry data, or spacecraft hardware noise. Most operating systems provide features to intercept such errors, apply standard fixups, print warning messages, and /or terminate the program. However, these operating system features (such as the FORTRAN monitor) are generally inadequate for an interac tive graphics system. Occurrences of mathematical singularities may require a standard corrective action; a count of the errors for later display, or an execution halt to inform the user of the error with an appropriate message. If standard corrective actions are applied indiscriminately, the program may generate meaningless results with no indication of the cause of the problem.

In addition to user input, ^mission support software generally obtains input from telemetry data files, ephemeris files, attitude history files, and other sources. Because these files are computer generated, they are not normally as susceptible to errors as user input. However, the data in these files must still be checked for validity, especially for errors which might result in program termination. The most common errors are an ephemeris file which does not cover the time span of the data being processed; a file generated in the wrong format or out of time order due to human error or software errors in the generating program; the header record of a file which disagrees with the data on the file; I/O errors which lead to random bit changes on the file; and files containing no data records.

If, in spite of error checks, a program abnormally terminates, or abends, then as a last resort the graphics executive should intercept the abend and allow a rapid recovery or restart of the program. Intercepting an abend is not as satisfactory as detecting an error within the program, because diagnosis of the abend may be more difficult; however, it does permit recovery from errors detected within operating system routines in cases in which prior error detection by the user would be inconvenient or the potential for error was unforeseen.

Flexibility. Mission support software should provide enough flexibility to handle contingencies such as spacecraft hardware malfunction, telemetry errors, or mission timeline changes. It is generally not possible to foresee all contingencies, nor is it feasible to provide special capabilities for every contingency which can be foreseen. However, if the software is sufficiently flexible, it is often possible to improvise a technique for handling a contingency simply by altering the available program options. For this reason, all program parameters should be variables which can be changed via interactive graphics; parameters such as tolerances and calibration constants should not be hard-coded within the program. Data set specifications should be flexible to permit processing multiple data sets or switching between data sets without terminating the program to change job control language. Processing flow within the program should be flexible and should be controlled by user input parameters. The program should optionally provide displays of all input, output, and intermediate results in a variety of formats (plots, tables, summaries); these formats should be designed to allow for the display of nonnominal as well as nominal data. A variety of options should be provided for editing telemetry data based on criteria such as maximum and minimum tolerances, residual tests, and consistency checks. As a last resort, the program should allow the operator to manually flag individual data items or override or modify any or all of the telemetry data items.

Ease of Operation. Ease of operation is more than just a convenience in mission support software; a system with the degree of flexibility described above will normally have hundreds of user input parameters and can easily become so complex as to tax the skill of any user. Operator interaction must be minimized, both to reduce the chance of human error and to minimize delays in near-real-time operation. To minimize the need for user input, typical default values should be provided for all input parameters, for example, via FORTRAN BLOCK DATA subprograms. Those parameters which must be changed from their default values and which are known a few hours or days in advance (such as orbit parameters or calibration constants) can be specified on input cards which are read when the program is initialized (e.g., NAMEL1ST card input). The user then will change only those parameters which differ from their expected values. Once the user changes a parameter, the new value should be used by the program until the user changes it again.

All displays should be clear and self-explanatory to a trained user; there should be no need for the experienced user to consult a user's guide for definitions of input parameters or error codes. The most frequently altered input options should be grouped together at the beginning of displays, so that the user can skip rarely used options. All input and output should be in the units and format which are most convenient for the user; for example, if times are to be expressed in calendar format for purposes of communicating with the control center, then the program should make the necessary conversions. There should be no need for the operator to do hand calculations or consult tables because the error rate for such operations is unacceptably high. Output displays should be designed to communicate information as rapidly as possible. A plot display can often be interpreted by the user many times faster than a tabular display, but only if proper attention is given to automatic scaling and exclusion of spurious points.

Reliability. A software system is said to be reliable if it meets its specifications (i.e.. obtains correct results) for all possible sets of input data. The error-checking features discussed above are considered part of the specifications; thus, a reliable program must generate appropriate error messages for invalid input data.

Reliability begins with program design. The design should be simple, straightforward, and modular. If, after a detailed study, it appears that there does not exist any simple design which can meet the specifications (including execution time and core requirements), then it is advisable to consider relaxing the specifications rather than proceeding with the development of a system which may never achieve the required reliability.

Following detailed design, the program should be coded in a higher level language with features designed to minimize or eliminate bookkeeping-type errors,1 thereby allowing the programmer to concentrate on program logic. Some useful language features include the ability to define COMMON blocks in a single library, the ability to check calling sequences in the called routine against those in the calling routine, structured programming constructs to eliminate GO TO statements, tests for variables which are never initialized, simplified vector and matrix operations, and automatic enforcement of programming standards. Most versions of FORTRAN lack these features; however, precompilers can be used to add these features to FORTRAN or other programming languages. A structured FORTRAN. precompiler providing many of these features is described by Chu [1977].

Enforcement of good programming standards can eliminate many common errors. The standards used will necessarily depend on the application, programming language, and computing environment. One such set of FORTRAN program-ming standards has been described by Berg and Shear [1976].

Table 20-1. Methods for Avoiding Common Software Errors
0 0

Post a comment