Linking Legacy

Gerry Tyra September 2015

Abstract:

Across the other writings in this set, there has been an assumption that the messaging system described is used universally. Then I was confronted by the question: What happens if you have to interface with a legacy system? Does relative structural simplicity and evolutionary consistency of the system breakdown in a flurry of custom coding? After an examination, the answer is: No.

Introduction:

No matter how technically advantageous a system is, if it is used in an existing vehicle, there are bound to be a couple legacy systems that can't be displaced. For a messaging system to be truly robust, it must be able to interface with these legacy systems in as seamless a manner as possible.

Two examples in my personal experience are Link-16 (Mil-Std-6016 or NATO STANAG 5516) and 1553 (Mil-Std-1553). Link-16 is used as a secure operational communications network by NATO forces and 1553 is used for on board data transfers. Both are massively bit packed and frequently use an interesting mix of unit types.

So, the issue at hand is how to interface with these systems.

Problem Space:

First, there is a fundamental difference between Link-16 and 1553, the former is a fully specified international standard (message structure, timing and RF), while the latter is only a timing and electrical specification, with very few constraints on the message contents.

What they have in common is that they result in tightly packed data structures, which makes interfacing to the corresponding data sources and sinks tedious at best, and frequently painful.

1553 uses a maximum of 512 bits in a message, usually represented at 32 words of 16 bits each, or 16 words of 32 bits. The messages are routed to a terminal address and a sub-address within that terminal, thereby defining the base message. Additional message type data can be included in the message body to further differentiate message types, but this is implementation dependent. Effectively, every system using 1553 uses its own specific message set. Any commonality is more by coincidence and reuse of a specific subsystem than by long term planning. This implies that any message definitions implemented to carry the 1553 message data will be aircraft specific. As will be shown there is a lot of hope for simplifying that implementation, but it will still have to be done on a case by case basis.

Since the Link-16 standard is export controlled, I won't be going into any detail of its implementation. But I will point out some of the characteristics of the message structure that usually make it difficult to interface with. I will then discuss how to actually do it under the messaging system presented here, using a loose approximation of the Link-16 message format. This approximation should provide a working example that can be extended to handle the actual standard by anyone with access to the standard. Once the mechanics for interfacing with Link-16 are explained, a similar methodology can be used to interface to any 1553 message set.

TDL-J:

The Tactical Data Link series J (TDL-J, with the legacy name TADIL-J) messages are defined in Mil-Std-6016E. This standard goes on for thousands of pages. The only parts that have significance here are:

1. The messages are organized by groups labeled as Jx.y.

2. The messages are made up of 70 bit words.

3. The message has an Initial word, an optional set of Extension words and an optional set of Continuation words.

4. Depending on the size of the transmit time slot, only the Initial word, the Initial word and all of the Extension words, or the Initial word, the Extension words, and the Continuation words are transmitted.

For the purpose at hand, consider the J2.y message set. These are the Precision Participant Location and Identification (PPLI) messages. Their purpose is to declare who, where, and doing what that a participant in the network is. There are different messages for air vehicles, surface vessels, mobile and fixed land units.

Data In, Data Out:

“Ownship” (i.e., the host vehicle) transmits some version of the PPLI periodically. This provides identification and position data to other friendly forces and reduces the chances that they will try to shoot you down. Since it is unlikely that any one activity in the aircraft has all of the data needed to build this message, it is reasonable to assume that a client associated with the Link-16 hardware would accumulate this data and prepare the actual message structure, then serialize it before making it available to the transmit queue.

Similarly, all of the other forces on the network are sending their PPLI data, which are received and consolidated into actionable data for crew awareness, sensor fusion, et.al.

Given that this latter function(s) (e.g., the Pilot Interface Display) is probably not immediately associated with the Link-16 hardware, there needs to be a server capable of taking in the Link-16 messages, translating them into a more useful format, then providing the reformatted messages to the clients that had requested the data. Logically, the distribution of this data does not have to be uniform. For example, an Anti-Submarine Warfare (ASW) function would probably have little use of ground or air PPLIs.

Implications for Message Structure:

We start, as before, with the generic message base class. This is a requirement in order for message pointers to be passed around easily. In the context of the TDL-J messages, we define a group “TDL”, equating it to some group index, say 42. Aside from the group lending a sense of hierarchy, it doesn't actually serve a purpose. Rather, the group ID and the message ID define the actual message.

For this example, it is assumed that all of the PPLI messages have the same structure for the Initial word. This allows the use of a single base class to represent it. Please note that the base class referred to here is the base for the PPLI message set. This message is, in turn, derived from the global message base type. The various permutations of Extended word(s) and Continuation word(s) can then be represented as derived message types. For the sake of simplicity, only one Extended and one Continuation word will be considered.

How It Works:

Ownship's client will gather the data required for the appropriate outgoing message type, including both the Extended and Continuation words. At the appropriate interval, the message structure is serialized into a three word TDL-J message and passed to the transmit queue. As the designated time slot occurs, one, two, or all three words are transmitted. Assuming that a one deep queue is used, only the most recently available data is ever pending transmission.

The Link-16 receive server will have been requested to forward some or all of the incoming PPLI messages to various client functions. When a PPLI is received, the type and word count are used to determine which message type is appropriate. Once a message instance is allocated to the message, the deserializer populates the message instance from the TDL-J words. The message is then prepared for transfer to the requesting clients. As has been stated in the other papers, the extent of compression in the re-serialization is a function of the transfer media between the server and the client.

The message handler at a client will examine the message header in the incoming buffer, allocate a message instance from the pool (it is assumed here that all message instances are passed through a pool, and not allocated from from the heap and then freed) and populate it. A reference to the message instance can then be provided to the specified callback function, which is responsible for acting on the data.

Huh?:

If parts of what you just read was confusing because it appeared that I just made several major jumps without adequate description or amplification, I did. The details of the message handlers has been discussed in detail and other white papers at planet-tyra.com/Software. As such I didn't want to bore the reader with too much repetition.

Serializer Details:

The other serializers associated with the messaging system do some level of packing, and only in the low bandwidth case does it do any scaling. That is not the case when dealing with Link-16 or 1553. In these cases, the data is always assumed to be scaled or translated, frequently with a change of units.

To cover the various data transforms, we must provide a consistent, flexible set of mechanisms. As with the other serializers, each data element is converted in turn, depth first. However, in this case, the translation arguments get a little more complex. The first argument is a pointer to a static 'getInstance' function for the applicable transform class. Each class type has both a serialize and a deserialize function. A value of zero implies that the associated data element is not included in the legacy message structure (not likely in the current example, but probable in a standard message interfaced to 1553). Any additional arguments are passed into the function, along with the data element.

As an added consideration, there are cases where, rather than redefining the message to have more resolution by extending a field over more bits, the original resolution was left as it was and the additional bits were added in a continuation word. This implies that the parameters being passed to the function must be managed as a list. That is, take the first set of parameters and populate part of the message, then repeat, laying the new answer elsewhere in the message. The deserializer would reverse the process, summing the parts into the final value represented in the structure.

The scaling parameters list required depends on the implementation, but I present the set that I'll be using:

1. Double precision scale, only once.

2. Right shift count of scaled result.

3. Bits to copy.

4. Word to insert into.

5. Left shift into word.

The range of items 2 – 5 can be represented by 1 byte, hence the set is one 32 bit word per iteration. Another option is to map some number of 64 bit integers through a union to provide greater typing flexibility. Your mileage may vary for different target applications.

Another side of the translation is the use of enumerated types. Link-16 has various data elements represented by enumerated values. Some of these enumerations go on for pages. And, just because a certain aircraft type is represented by specific value in Mil-Std-6016, does not automatically make it a reasonable representation in this messaging format. For example, why maintain enumerations for aircraft that are no longer flying? Or how do you represent aircraft that have entered service since the last standard update? The point of the messaging system presented here is its ability to gracefully evolve.

The final translation is text. Link-16 can, and does, push a fair amount of text around, but it isn't ASCII, let alone UTF-8 or UTF-16. Rather, it is a reduced set, all capital letters and numbers, minimum punctuation, and no letter 'i' (an upper case i can be confused with '1'). As a result, it can pack a character into 6 bits rather than 8. This requires another translator.

Generalization of Translators:

It should be pointed out that a translator in this context does not have to be only bound to the immediate operation. Consider a translation of aircraft type designation, using an F-15E as an example. There may be one enumerated type internally, the Link-16 designation, another designation used by a legacy 1553 interface, as well as a ASCII representation. This could make it advantageous to have a single translator class, with an array of structures, each of which contains all of the representations of a given entity. Then maps (key/data pairs) could provide quick access from one representation to another. This type of implementation lends itself to a central library function, providing uniform results over a number of applications, along with simplified maintenance.

Summary:

While the proof remains to be seen in an actual implementation, there is no reason to doubt that a messaging system as discussed in these paper can be made to work cleanly with legacy messaging system.