TMCALGO V2R1: Algorithm Compiler

Over the years, a few time-tested strategies for organizing instrument algorithms have emerged. These are not the only approaches that will work, of course, but they can give you a good start.

To begin with, it is worth pointing out that TMCALGO is a programming language, and many design principles that apply to other languages apply to it as well:

• Keep your organization simple
• Separate control of unrelated subsystems into separate partitions.
• Avoid indiscriminate interference in other partitions' operations.
• Clearly identify and document how one partition can affect another.

One of the best resources for strategies is the source code of existing instruments. None of these represent a perfect solution, and some older code may employ conventions we have since moved away from, but they are a good place to start.

And of course one additional resource worth mentioning is the author, who is more than happy to talk about your algorithms until you can't stand it anymore.

4.1: First Partition

We have traditionally used the first partition of an algorithm to outline the full course of data taking for a run from initialization through shutdown. A minimal implementation of this would have three states, Initialize, Record, and Shutdown. Record might well loop through some standard procedures until conditions for advancing to Shutdown are recognized.

The record state can also be broken up into two or more states to perform particular types of operations. Doing so can allow certain procedures to be executed only under particular circumstances.

In this example, Record3 is only executed at high altitude:

Most instruments of any complexity require some additional elaboration. For flight instruments, the major transitions may be keyed off of changes in altitude and may require additional states to allow for the possibility of aborted landings or other false triggers. Lab instruments may run unattended from start to finish, or they may choose to use the software status techniques to provide keyboard control of the algorithm.

4.2: Keying off of Altitude

When the Anderson Group first ventured from balloons onto an airplane and lost ability to manually control the instrument during flight, we had to rely on the pilot to signal the instrument through a cockpit switch, indicating when the plane was taking off or preparing to land. We soon discovered that the pilots hate to have that level of responsibility for instrument operation. They are extremely busy during takeoff and landing and would much prefer to be flying the plane than punching buttons for instruments. Needless to say, this was one of the first motivations for giving algorithms a flexible way to access to the instrument data and take actions accordingly.

Since planes go up at the beginning of a flight and come down at the end, using altitude, or pressure, as an indication of where we are in a flight works pretty well. I have included an example of code we have used on the Chlorine Nitrate instrument (which is also nearly identical to the corresponding code on half a dozen other instruments.)

There are two goals inherent in this design:

1. Clearly and globally define three altitude regions, ON_GROUND, BELOW_CLOUDS, and ABOVE_CLOUDS that other partitions (notably partition 1) can use to make decisions.
2. Provide a method for emulating altitude changes in order to test other parts of the algorithm while on the ground.

The reason for having three altitude regions rather than two is to allow instruments to start warming up as early as possible without necessarily exposing the flows to dangerous water or ice particles in the clouds. Instruments generally start their initializations when they detect that the plane has left the ground, but don't advance to full data-taking until the plane is safely "above the clouds". On the downward leg, tripping into BELOW_CLOUDS indicates impending landing, allowing the instrument time for an orderly shutdown. The algorithm does not advance to a full shutdown and quit until it detects that the plane has gotten as low as ON_GROUND, allowing for a return to data-taking if the plane climbs again.

The altitude emulation is accomplished via the use of software status data which can be set from the keyboard interface. By issuing a keyboard command, this partition will advance to the next altitude state. Other partitions which key off of these altitude states (rather than looking directly at the pressure) will make decisions as if the plane were in the air.

It is worth noting that while this approach is useful for testing other partitions, it is in no way adequate for testing this partition. At least once before flying a new instrument, this portion of the algorithm should be tested by pumping on the pressure sensor to make sure that it properly detects changes in pressure and that the algorithm does in fact perform the appropriate transitions.

4.3: Using Software Status

Software status is telemetry data that does not represent physical properties that have been read via sensors but rather quantities that have been set manually via software. This is useful for manually adjusting setpoints for systems which are controlled by an algorithm, for identifying regions of interest to data analysis software, and for providing a means of communication between the operator and the algorithm.

The subject of how to get software data into the telemetry stream is outside the scope of this document. Many examples exist in the instrument source code, and a definitive example should be included in one of the guides.

The remainder of this section is concerned with using a purely arbitrary software status word which can be set to discrete values from the keyboard. A command such as "Set Software Status 7" can be used to assign a value to the variable, or more mnemonic commands can be provided which are associated with specific values.

We have tried tying individual bits of a software status word to particular functions, but have found this ultimately inadequate since the number of bits available is relatively small compared with the number of discrete values vailable. We have found it more effective to use specific values of a software status variable to signal state transitions which are recorded in the algorithm. For example, the value '7' might signal the algorithm to enable a particular option, and the value '8' could disable the option. The algorithm uses a local (non-TM) variable to hold that option's state, and once the transition has been recognized, the software status word need no longer be concerned with it.

In this approach, a software status value of zero represents "no operation", and every recognized operation is responsible for resetting the software status once the specified operation has been recorded. I have provided a minimal example, taken from the Total Water and Ozone instrument. Using this as a starting point, you can add all sorts of interactive controls to your experiment. You will need to:

• Add a new case for each value you wish to recognize, including the code necessary to record the command.
• Make sure to terminate each case with a 'break' command unless you intentionally want the procedure to fall through to the next case.
• If a particular case is going to be handled in another part of the algorithm, it is a good practice to list that case without any code above the 'case 0:' line. This helps to document the fact that that particular value is being used somewhere.

Return to Manuals Guide. Written by Norton T. Allen