Declic: Linux 2.6 on the International Space Station

In past experiments on the Russian Mir station, all experiment timelines had to be stored on a computer. Experiment control existed by switching on the system and executing a series of commands. The experiment command list had few possibilities to act on specific occurring phenomena or experiment phases. In an early stage of the Declic development, the French company EREMS, responsible for the PDHS development, came up with the idea to use Tcl for the interface. Scientists now are given a complete programming language to formulate the experiment. They can execute commands, store values from read commands in variables and make decisions using the Tcl language for configuring the next executed command. The science script is located on one of the PDHS hard disks and started from the ground. For example, a Tcl science script can contain Tcl statements to bring the experiment to a specific temperature, start the video if the insert has reached a stable temperature and start the acquisition of some interesting sensors.

When writing a science Tcl script, the scientist doesn't need to know much about the hardware; a simple list of items with their numbers is enough. Reading a certain temperature sensor can be done in this way by executing the Tcl command cre_get_values -item 34. The science script executes on the PDHS, and a CRE command results in passing the Tcl command to the CRE computer. The CRE knows that sensor 34 is actually the third sensor on a Platinum sensor controller board. It sends a binary equivalent command to this board, cre_get_values -item 3. The controller makes a data acquisition of the sensor and responds with the value. This response once again is sent back to the PDHS and the running Tcl script.

Now, suppose you want to add an item to the Insert Definition File—how do you keep this XML file consistent with the microcontroller software? It's easy for a Linux system to interpret XML files, but small 8-bit controllers certainly cannot do such things. Adding one item to the Insert Definition File, however, can change all item numbers by one, making the local item numbers no longer consistent with the software implementation. The solution is found in generating C code and header files automatically from the XML file. Putting both files into the Makefile keeps everything consistent. Listing 2 gives a small example of such a generated C file.

....
char item_names[]={
    "BOARDVERSION",
    "BOARDID",
    "DAL_ALI_POWER_BOARD1",
    "PWM_OTSF",
    ....
    "U_FPE"};

void init_items(void){ t_item *items;

    item = g_items[ITEM_NR_BOARDID];
    item-> item_type=pseudo_sensor;
    item-> itemnr=0;
    item-> device_data_type=11;
    MALLOC(item-> device_value, void, 32);
    item-> SI_data_type=0;
    item-> SI_value=NULL;
    item-> in= NULL;
    item-> out= NULL;
    ...

In Listing 2, the last two entries are pointers to functions that perform the actual acquisition for this item when it's a sensor; it also performs the action for an actuator.

We saw that a single Tcl command results in a multistage command transmission between different Declic subsystems. It's possible to acquire multiple sensors with a single Tcl command, even if they are distributed over several microcontrollers. This results in the arrival of several packets on the CRE computer that need to be collected and sent as one TCP packet to the PDHS. In such cases, a responsive Linux kernel is crucial.

The central CPU of the CRE uses the new 2.6 kernel. It is compiled into a Net-bootable image: the CPU boots using the bootp and TFTP protocols for LAN booting. The image is located on the hard disk of the PDHS, which is booted in a normal way from hard disk. All the microcontrollers boot in the same way. When data transfers take place between microcontrollers and the CPU, a responsive operating system is necessary: we don't want to have the system interrupting the transfers for more than 20ms as sometimes happens in kernel 2.4.

The requirements are soft real time here, and 2.6 fulfills these requirements. All we need is a kernel that immediately triggers a C thread in the main CRE application when data arrives from a microcontroller. The microcontrollers have hard real-time requirements, because they need to be responsive to such hardware events as hardware counters and interrupting devices. Our major application running on the CRE central processor has no such demands. When we started to run the application, using Linux with a 2.4 kernel with several microcontrollers sending data, we encountered timeout problems for packets that were not received in time; although the contents of these packets showed they were sent with correct timestamps. The major improvement with the 2.6 kernel is the low latency of system interrupts.