Phase 1 of the OCAP project was completed at the end of April. Since then, we have started working on the software design and creating the reference implementation.
In order to make integration into existing software as easy as possible, we have decided to implement the reference implementation of OCAP as a program library in the “C” programming language. The library is divided into the following main components:
The component for calculating possible imminent collisions and generating warnings (gray box on the right) is central. This component takes as input information about the own (A) and from nearby (Bi) flight objects. In a first draft, this information includes the current position, speed and acceleration of the flight objects. The program logic in the component periodically extrapolates the flight paths and checks whether a possible collision is imminent between our own and nearby flight objects. It generates warning messages as output, which the application software should provide to the pilot.
In a first draft, we use three levels of alarm messages (level 1 = low to level 3 = high). The selected level depends on the time until the collision on the one hand and on the distance of the flight objects at the time of collision on the other hand. This criterion roughly takes into account that the uncertainty of the position prediction increases with increasing extrapolation time. It will be reviewed and refined in the course of the project.
For the calculation of the input data for the collision prediction, we distinguish between two cases. The “Preparation <own> vectors” component is responsible for calculating the vectors for our own flight object. It uses the available sensor data, in particular the information from the GPS module. The “Preparation <other> vectors” component calculates the vectors of the nearby flight objects. It uses data from received radio packets, if these are available, and extrapolates existing data if no new data has been received.
The reference implementation will in any case contain an interpretation of the ADS-L packets. In addition, we are planning to investigate our own optimized packet format. If possible, FLARM and FANET packets will also be taken into account.
Comments