Tactical data links operate by exchanging messages between military units such as aircraft, ships, ground stations etc, which are synchronised in a radio network. Messages are transmitted in a digital form and consist of a stream of data bits formatted according to certain rules. These rules lay down that messages have a fixed format dependent on their message type. Different message types are intended to contain different information. For example, a track message will contain position and velocity information of (for example) an aircraft, whilst a status message will contain fuel data and weapons status of the aircraft. At present, approximately fifty different types of messages are defined for each link.
The message types and formats for each type are set down according to NATO rules and in theory a platform conforming to those rules should therefore be able to communicate with any other platform which also follows those rules. In other words, the platforms are fully interoperable and can communicate with each other satisfactorily. In practice, the rules are inevitably insufficiently comprehensive to cover every eventuality. There is therefore scope for variation between different platform implementations, and these variations typically lead to interoperability problems. For example, a receiving platform may require that an incoming message contains certain information whereas the transmitting platform for some reason does not include that information. This would result in the receiving platform discarding that message as it did not meet its processing rules.
Interoperability problems such as this can be discovered by comparing the different platform implementations with reference to their build specifications. However, the specifications themselves may be unclear and the procedure would in any case be lengthy and difficult. It is more usual for interoperability problems to be discovered during a trial when the messages are recorded and their contents matched against expected events in each platform.
The difficulty with this latter approach is that data is generated by tactical data links at a very high rate. It is normal to generate approximately 20 MB of data during a two hour flight by a single platform. This can be compressed for transmission, but for analysis will obviously need to be decompressed. A lengthy trial with a significant number of platforms will clearly generate a prima facie unmanageable volume of data.
It is however essential that interoperability problems are identified in order to allow their resolution. Such difficulties could significantly impair the effectiveness of armed forces in a conflict situation, the implications of which are clear.
At present, data is sorted chronologically and placed into a database. The sheer volume of data and the wide range of information that may be included within a specific message field due to the large number of message formats means that direct inspection of the data is not physically possible on any significant scale. However, databases allow a user to present queries, which are essentially filters to select those entries which meet certain criteria. Thus, a user can present the database with queries intended to illuminate interoperability conflicts.
The use of databases to analyse the data in this way has certain defects. It is immediately apparent to a user that the databases take a significant amount of time to analyse the data and respond to the query. Whilst this could in future be solved by applying ever greater processing power to the database, it would be useful to be able to accelerate the process. At present, the various stages necessary to convert the data into a form readable by the database, enter it into the database, select appropriate queries and obtain responses and analyse those responses means that, at best, results are available several days after the trial. It would be useful if those results were available at the post-trial debrief. As this is held a matter of hours after the trial end, whilst operators memories are still fresh, this is simply not practical at present.
Existing databases also suffer from a more fundamental flaw. It is up to the user to generate queries, and therefore this requires an a priori knowledge of the type of interoperability conflicts likely to arise. The user is not generally in a position to detect unexpected interoperability errors, as the raw data cannot feasibly be inspected and the processing time required rules out the use of a large number of speculative queries aimed at detecting unlikely or unsuspected conflicts. Speculative queries also require the user to have an intimate knowledge of the type of content in particular message fields, in order to detect unusual entries. This again cannot be guaranteed, and is clearly unlikely in the case of unsuspected conflicts.