The purpose of the CDx is to detect potential collisions of aircrafts located by a radar device. This is a modified version of the original CDx, providing a concurrent execution of computation of detection and also exploiting the features of SCJ Level 1. Our aim with the concurrent CDx is, most of all, to provide a genuine and more representative Level 1 application. Due to the novelty of the SCJ paradigm and technology, such applications are still diffcult to come by in the public domain.

This SCJ program uses a simple cyclic executive, and embeds the assumption that the radar device collects a frame of aircraft positions that becomes available for input to the program periodically. In each iteration, the CDx : 1) reads a frame; (2) carries out a voxel hashing step that maps aircrafts to voxels; (3) checks for collisions of aircrafts in each voxel; (4) records and reports the number of detected collisions.

A voxel is a volumetric element; all voxels together subdivide the entire space. The voxels in the CDx superimpose a coarse 2-dimensional grid on the x-y plane with the height of a voxel extending along the entire z-axis. Thus, the altitude of aircrafts is abstracted away during voxel hashing in step (2). This reduces the number of necessary collision tests between aircrafts. After mapping aircrafts to the voxels that are intersected by their interpolated trajectories, it is sufficient to test for possible collisions of aircrafts within each voxel.

The concurrent CDx consists of a single mission that instantiates seven handlers. Figure 1 and Figure 2 present two UML diagrams that illustrate the design.

The concurrent CDx consists of a single mission that instantiates seven handlers. Figure 1 presents a UML class diagram that illustrates the design. The classes shaded are part of the SCJ API. The classes CDxSafelet, CDxMissionSequencer and CDxMission implement the safelet, the mission sequencer, and the mission. The behaviour of the setUp() and tearDown() methods of CDxSafelet is void, and getSequencer() simply returns an instance of CDxMissionSequencer. Likewise, getNextMission() returns an instance of CDxMission when called for the rst time. (Since the mission here does not terminate, getNextMission() is not called again.)

In the mission execution, rst the initialize() method of CDxMission is called. It creates the handler objects and shared data in mission memory. The handler classes are InputFrameHandler, OutputCollisionsHandler, ReducerHandler, and DetectorHandler. We choose to create four instances of DetectorHandler, possibly corresponding to a scenario in which we have four processors. A more general design for the CDx could allow the configuration of the number of instances; our program, however, is enough to illustrate the main aspects of our technique.

The shared data is held by public fields of CDxMission. The currentFrame and state elds record the current and previous frame of aircraft positions; recording previous positions is important for calculating their predicted motions. As we divide and distribute the computational work, work holds the partitions of voxels to be checked by each of the detection handlers, and collisions is used to accumulate the result of the detection. A further shared object control plays a crucial part in orchestrating the execution of handlers.

Figure 2 summarises the control mechanism of the SCJ application. The three software events, reduce, detect and output, are used to control execution of the handlers. The program design ensures that the handlers effectively execute sequentially in each cycle, apart from the four instances of DetectorHandler, which carry out their work concurrently. The InputFrameHandler is the only periodic handler. It is released at the beginning of each cycle to interact with the hardware to read the frame into currentFrame and update state accordingly. Afterwards, it releases the ReducerHandler, via the reduce software event, to carry out the voxel-based reduction step. This handler also partitions and distributes the work among the detector handlers by populating work. Once this is done, it concurrently releases all DetectorHandler instances by ring the detect event. These handlers carry out the actual detection work and store their result in collisions. The mechanism for releasing OutputCollisionsHandler, which outputs the resulting number of collisions to an external device, uses the shared object control. DetectorControl provides a method notify(), which is called by the detector handlers at the end of each release. It res the event output when all detection work is done. This illustrates that sharing may occur not only to exchange data between handlers, but also in the design of execution control.

Finally, the overview of all classes in the CDx package is shown in Figure 3.