|
||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Class Summary | |
---|---|
Aircraft | The object of Aircraft where callsign is the only attribute |
ArrayListFactory | This class is used to pre-allocate ArrayLists in mission memory. |
ASCIIConverter | The purpose of this class is to permit printing of debug messages with callsigns (byte arrays) and floating point data from a no-heap thread. |
CallSign | The class CallSign encodes callsigns. |
CDxMission | The single mission of the parallel CDx. |
CDxMissionSequencer | The mission sequencer of the parallel CDx application. |
CDxSafelet | Safelet of the parallel CDx. |
CHashMap | We note that the key and value of a map entry must not be null. |
Constants | All of relevant global constants for the parallel CDx. |
DetectorControl | This class is used to control the execution of OutputCollisionsHandler. |
DetectorHandler | DetectorHandler instances carry out the actual collisions detection. |
Error | This class is used to generate program errors. |
InputFrameHandler | InputFrameHandler is a periodic handler that reads and stores radar frames as they arrive. |
Motion | Objects of the Motion class provide all a-priori known information about what the Aircraft was doing between two frames. |
MotionFactory | This class is used to pre-allocate Motion objects in mission memory. |
OutputCollisionsHandler | OutputCollisionsHandler outputs the number of detected collisions to an external device. |
Partition | This class evenly distributes lists of motions which may be collided to each element of the shared variable `parts', so that each DetectorHandler can retrieve the related list regarding to its ID. |
PersistentData | This class acts as a contained for all factories needed to pre-allocate shared objects in mission memory. |
RawFrame | A raw radar frame where callsigns and positions are recorded sequentially and seperately. |
Reducer | Reduces the set of collisions to be tested using a voxel hashing algorithm. |
ReducerHandler | ReducerHandler performs two preparational tasks prior to the parallel detection phase. |
StateTable | The class StateTable records the state of the previous frame. |
Vector2d | The Vector2d class implements a 2-dimensional vector that
can represent the position or velocity of an object within a 2D space. |
Vector3d | The Vector3d class implements a 3-dimensional vector that
can represent the position or velocity of an object within a 3D space. |
VectorConstants | The VectorConstants class implements some simple utility
methods for obtaining vectors that are commonly used, such as zero vectors
unit direction vectors, and orthogonal vectors. |
VectorMath | The VectorMath class implements the mathematical functions
for manipulating vectors of two and three dimensions. |
Exception Summary | |
---|---|
ZeroVectorException | The ZeroVectorException exception is thrown by utilities that
perform calculations on vectors. |
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.
|
||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |