Dryden Flight Research Center has developed a computer program that performs signal management for analysis in real time (SMART). This program, called "SMART," has been effectively used since 1991 in F-18, X-31, LASRE, and X-33 programs.

Figure 1 depicts the architecture of SMART. Signals are processed by executing rules (represented by Boolean expressions) that generate messages on a UNIX X-Window. Inputs to SMART can come from any or all of several sources, as discussed below:

Figure 1. SMART can receive input from any of four sources, one of which is part of SMART itself.
One of the sources can be a computational simulation. SMART is very effective for use in a simulation environment, because the simulation scripts can be used in conjunction with the rules to automate pass/fail criteria for software testing. Such raw words as signals on a 1553-standard bus are very easily decoded by SMART into meaningful textual character strings. As scripts are run, test words can be controlled to indicate to SMART that a particular test is being run. SMART generates the appropriate messages for the autotesting of the simulation software. All tests are exactly repeatable, very fast, and self-analyzing.

Another source of input to SMART can be a control room for an aircraft or spacecraft mission. The use of SMART during flight testing in such programs as the X-31 and LASRE has proven to be very valuable. For flight testing, safety of flight is the primary concern, and SMART works very well because health and status words are constantly being monitored. Status is not missed because when any fault is detected, a new colored (red) message is added to the top of a real-time UNIX X-Window message stack. An additional benefit is that each such message is time-tagged. Data can be analyzed easily because SMART gives event times. All faults are immediately made known to enable quick action by a flight-test team.

Figure 2. A Dynamic Message Stack contains the primary output of SMART.
A third source of input is a "GetData" batch file. The capability to receive data from this source is a recent addition to SMART. SMART reads the batch file, frame by frame, at whatever rate the data come in, and generates messages according to the rules. This capability is very effective in automating the analysis of batch data. Certain events can easily be tested by the rules and messages generated. It is also very helpful in developing the rules by use of known events representative of those that it is very important to be able to detect.

A fourth source of input is a spreadsheet subprogram that is part of SMART. This subprogram is used by a rules developer to test the rules. There is an option to automatically load all the signals from an input rule source onto a spreadsheet. The tester can click a cell and type the desired data value to test the rules. The message(s) appear on the stack when the rule has been satisfied.

The primary output of SMART consists of messages put into a dynamic stack. New messages are always added to the top of the stack and as old messages are rescinded, the stack is compressed to fill in the gaps. Messages can also be color-coded to enhance the visibility of designated information. The current messages in the stack can be sent to a printer at any time by use of a print command on the SMART window.

The SMART window provides an option to save the messages in a log file on a hard disk. This option is very useful for saving time-tagged event information for testing. Certain information can be scanned out from this file by use of standard UNIX commands; this feature was found to be very useful in the LASRE program.

Another option, which was recently added to SMART, provides for triggering by a rule to generate a message and the current time and record the message and its time tag in a file. Information is continuously written into this file as long as the rule is satisfied. The message is defined by the developer. The message could be, for example, a parameter to be recorded whenever a fault flag is set. This option is meant to be used as a tool for analyzing anomalies as quickly as possible.

This work was done by Richard Larson of Dryden Flight Research Center. For further information, access the Technical Support Package (TSP) free on-line at www.nasatech.com/tsp  under the Information Sciences category. DRC-99-28


NASA Tech Briefs Magazine

This article first appeared in the June, 2000 issue of NASA Tech Briefs Magazine.

Read more articles from the archives here.