Command Modelling Languages and the Reduction of Display Fixation

An historical perspective

In historical terms, the first advanced technology to be employed for command and control (C2) was the electric telegraph. This technology saw exponential expansion during the 1860s and 1870s, and was used by the High Command in Berlin during the Franco-Prussian War. The round-trip message time of about 24 hours was far better than could be obtained using teams of “gallopers”, and was considered preferable to moving the High Command forward to a position of potential danger. Of course, High Command was not concerned with the transmission cost of each message.

In commercial terms, the telegraph facilitated C2 by Head Office. A Company Board in London could receive news from (say) India or Singapore on one day, consider their response, issue an instruction to their local manager that was received the next day. The Board of Directors was very much concerned with the transmission cost of each message.

The electric telegraph transmitted letters and a string of letters made up a word. The telegraph company charged by the word—and charged a rate that the telecommunication companies of today must envy! The rate-per-word was frequently equal to the weekly pay of a skilled workman in the home country. The response of those concerns engaged in multi-national commerce was to use codes. These codes were either dedicated or were standard commercial codes, and, in either case, one single word sent represented a longer string of words (a sentence). The success of this type of commercial C2 rested on the fact that both ends of the message transmission system used the same code, and thus the full message as initiated was the same message received.

The advent of radio sets that were man-portable (in practical terms) during and after WWII saw a similar use of codes—usually referred to as Voice Procedure or WT Procedure. There was of course a security component to these procedures, but a transmission that went:

“Sunray here. sunray to set”

represented a substantial compression factor over the true content of the message:

“This is the Commanding Officer. I want to talk to your Officer Commanding, now!”

or something very similar (and which would have been highly context-dependent).

The current digital C2 system is usually considered as one having a “secure fax facility” that will enable the rapid transmission of written orders down the command hierarchy, and initial trials in the UK have indicated that a side effect has been to reduce the number of pages transmitted. We argue later that the old principles for the use of the telegraph can also be applied to further reduce the transmission volume.

Message brevity and battle management languages

A Battle Management Language (BML) is any notation that can be used to express commands for military operations. Such languages range from ordinary language extended with a set of special terms, as have been traditionally used for command and control in real battles, to highly formalised notations for expressing commands in a form that can be interpreted by machine.

The expense of running simulation exercises in which operators are required to translate orders expressed in ordinary language into a set of directions or updates to the simulator has led to considerable interest in the possibility of developing a battle management language (see, for example, the work by Carey et al, [1,2]) satisfying the following two criteria:

• sufficiently detailed, structured and unambiguous that it could be directly interpreted by simulation software; and
• sufficiently expressive and “natural” that it could be used to express commands in real operations.

Were such a language to be developed, it would provide the benefit of bridging the current mismatch between real operations and training exercises. This would allow simulations to be used seamlessly in operation rehearsal and in training exercises.

Although such languages would undoubtedly have enormous potential for enabling interoperability of simulation and C2 systems they have another potential application in battlefield communication. This possibility arises from having a small, encoded, message interpreted in terms of a standard common procedure or command sequence. Provided both sender and receiver share the same stock procedure that is given a common name, then there is no reason why the sender cannot trigger a complex sequence of operational behaviour on the part of the message receiver. Furthermore, some parts of invoked procedure can rely on parameters passed in the message.

This idea can be illustrated using the Pilot Conceptual Language [3], a modelling language which was developed to allow both structural information (normally modelled by data models) and behavioural information or procedures to be represented. This language was not strictly speaking a battle management language in that its primary concern was to allow for the modelling of the battlespace in general (that is the entities in the battlespace and the activities they carry out) rather than orders alone. However, it can still be used to illustrate the facility for message compression.

The following is an example behaviour definition using the Pilot Conceptual Language. This represents the way in which a gun battery might respond to a set of fire instructions received from a fire co-ordination cell which has allocated it to a particular target:

behaviour

(Battery b) fire at (real x) (real y) (real z)

(string ammo) (string targTyp)

is

{

set gs = b.guns;

set fp = new FirePattern(gs, x, y, z, ammo, targTyp);

set gunBearings = fp.bearings;

while (gunBearings != [ ] )

do

set gunDetails = head gunBearings;

set gun = gunDetails.gun;

set bearing = gunDetails.bearing;

set elevation = gunDetails.elevation;

independent gun fire with bearing elevation ammo;

gunBearings = tail gunBearings;

end;

}

The details of this specification are not important for this discussion. In broad terms, what this definition says is that an appropriate firing pattern and set of bearings (which will take account of individual gun characteristics, weather conditions and so on) are worked out for the guns in the battery. Once this pattern has been calculated then the behaviour loops through a list of gun bearings, each specifying a gun and its corresponding settings, and starts each gun firing as an independent process or activity.

A behaviour such as the one above might be invoked, in the pilot conceptual language, by a statement like the following:

battery5 fire at 345 897 130 “HE” “armoured”;

which has a particular battery fire at an armoured target with high-explosive ammunition.

The important point about a behaviour specification such as the one above is that it can be invoked using a very succinct command phrase. Furthermore, since any behaviour definition can invoke other behaviours as it executes it is possible for complex behaviours to be built up as a hierarchy of definitions but then invoked by short command phrases.

Such packaging of commands and their invocation using short parameterised phrases has a number of potential benefits in the context of real operations:

• Command messages can be made very short and so are more easily transmitted and less vulnerable to interception.
• There is no reason why a group of fighting units cannot be sent all the commands for each entity in the group. An individual or a unit will only pick out and respond to those messages (orders) for which it is the intended destination.
• Using succinct parameterised messages may allow a degree of interoperability between coalition forces. Provided they use a common set of message formats to invoke command procedures, there is no barrier to the underlying procedures being differently expressed or even differently formulated provided they have the same effect. This is rather like being able to order some well-known dish, such as spaghetti carbonara, from chefs who speak different languages. They will each follow a version of the recipe expressed in their own language and perhaps slightly adapted in some way. Nevertheless they will all produce a basically similar result.

In particular, Battle Management Languages offer the possibility (through their succinct format) of transmitting orders in both text and speech form, and with minimum cognitive overhead.

Workload and fixation

Other domains that are introducing a combination of written and aural media to communicate commands may inform the arguments regarding the wider use of BML. An example is the aviation domain, where ‘data link’ systems are being introduced in both Europe and the USA as an adjunct to radio (voice) communications. A ‘data link’ is a system for digital messaging, most often as text, from the ground controller to the cockpit crew [4]. Although developed for different reasons in aviation—to alleviate radio frequency congestion—the aviation example can be used to highlight some of the advantages and disadvantages of a multi-media approach to command communication.

One concern for the introduction of a data link is the possibility that it will increase crew ‘heads-down’ time, so that the increased time and attention the crew spends looking at their instrument panels will be at the expense of their focus on flying. Attention-narrowing manifests itself as “display fixation” when using a battle management display (BMD). It has been reported by the USMC that commanders (even down to squad level) are concentrating on their display to the exclusion of observing the world around them [5]. Student research at the UK Defence Academy has seen field grade officers looking at ways to simplify the display [6], and to indicate degrees of uncertainty in data depicted on such a display [7].

While visual displays may be compelling, text communication may be less disruptive to ongoing visual tasks than is currently presumed. Latorella [8] studied communication interruptions to ongoing civil aviation tasks using different media for communication. Generally, she found that:

“… a dedicated data link system may afford the pilot more flexible task management and thereby increase efficiency of performance…” ([8] p. 90).

Essentially, because voice communications are discrete and temporal, crews have to execute the commands they contain soon after a transmission, which may not be the most convenient time for the crew given the other tasks they are undertaking. This situation may not be directly relevant to ground combat situations. Under some doctrines, a degree of flexibility is accorded to lower-level commanders

Data link transmissions remain on the Flight Management Computer (FMC) and so can be referred to at any time. The message record, or ‘log’, has the added advantage that the crew can re-read a message to clarify its details. In civil aviation studies, the advantages of the log have been reflected in less frequent requests for clarification (see [4]) and thus an overall decrease in communications. In this way, a data link leads to fewer failures in information transfer [4]. A second advantage attributed to data link permanence, is a reduction in execution errors due to the omission of mishears, and, if a direct transfer of the command to the FMC is available, a reduction in keystroke (data entry) errors. It is possible that such logging technology could be applied to BMDs as well.

In theory, civil aviation already uses a standard language, albeit without compression: the internationally agreed protocol is that English is the language of aviation [9], although even this may be disregarded if all pilots in an airspace have another primary language. However, the abbreviated voice message phraseology can still be subject to ambiguity in use. An advantage of a data link is that it overcomes the problems of the style of message delivery. Anecdotally, international pilots comment more on the way messages are delivered, citing added comprehension challenges due to the regional accent of the controller and the speed of delivery, rather than what is said per se. This has relevance in multi-national operations where the combination of a different language and a regional accent, plus a different command phraseology, offers the potential for serious misunderstanding.

Several organisations have accepted the concept of a standard message format (see [10], for a discussion of Message Text Formats or MTFs in the military domain), and the proposals herein can be seen as both a logical extension to military MTFs usage, and also a simplification of them.

In most civil applications, data link communication replaces selected voice communications. This ‘complementary’ configuration has the advantage that different media can be reserved for specific types of messages, for example using data link for clearances, and voice for route assignments. The crew then know what general type of message they are going to receive as the transmission begins. However, one medium can also be used as a pre-notification for messages that will arrive through another medium. Used like this, a BML message could be transmitted digitally to prime commanders for following radio messages, which maybe would contain detailed values for the order parameters. Advantages of pre-notification include that the repetition and written record may both reduce commanders’ memory load, and enhance information transfer. Disadvantages include a possible increase in workload. Although there are few studies testing pre-notification, Cox [11] did not find an increase in air traffic controller workload, but in another study [12] pilots expressed concern that pre-notification could be distracting.

A criticism levelled at a data link is that it could increase crew workload. This may be because critics equate the time to complete a task with workload. In general, studies have found that data link messages take civil aviation crews about twice as long to complete as voice messages (see for example, Dunbar, et al, [13]). However, in her reviews, Kerns [4,14] concluded that workload did not increase when the data link was used, rather it was re-distributed: visual and manual workload increased slightly with data link use, but this was compensated for by auditory and speech workload, which decreased (see for example, [15]). For a battle commander who is attending to two radio streams, a tool that potentially reduces auditory workload, even at the expense of increased visual workload, may be a good trade-off.

In conclusion

We suggest that the use of text messages can be usefully incorporated on a BMD. Commanders—particularly at company/squadron level down—are required to attend to multiple radio networks, since these link to higher and lower formations. The combination of single words or phrases from a standard BM or C2 language can supplement RT messages, and do so in a particularly secure manner. The RT message can call attention to the visual message, and vice versa, thus minimising the concentration on either medium. Integrating voice, text, and “secure fax” messaging can therefore be used to pass a substantial volume of C2 traffic—facilitating a rapid response—but which is context dependent. The parallel here is with the telegraph messages, which could use a mix of commercial and dedicated codes, and enable almost instant compliance with an instruction; yet which would be faster than the opposition who—even if they had obtained a copy of the telegraph messages—would still have to interpret them. The concept of “getting inside the opposition OODA-Loop” was as valid to the 19^th Century entrepreneur (even though the expression would have meant nothing to him) as it is to today’s network-enabled commander.

References

Authors

.