Battle Management Language: A Grammar for Specifying Reports

Battle Management Language (BML) is being developed as an open standard that unambiguously specifies Command and Control (C2) transactions. BM L is both a methodology and a language specificatio n, based on doctrine and consistent with Coalition C2 standards . We argue that the communication of future C2 tra nsactions needs to be based on a formal grammar to support Net-Cent ric Operations. Such a grammar provides the lexicon for a BML as well as a set of production rules defining how t he lexicon elements can be concatenated to BML expr essions. The grammar applies both to orders (C2 transactions com municating tasking) and reports (C2 transactions co mmunicating situations). This grammar is intended to contribut e to the Coalition Battle Management Language Speci fication being developed within the Simulation Interoperability St andards Organization. In this paper, we take an existing BML grammar for Orders and develop a related, but distinct grammar for reports. There are many differences between orders and repor ts. First, we differentiate between status reports, event reports, and task reports. Status reports include reports gi vin actual positions, the current status of a unit and its material. Event reports are about incidents that are not orch estrated, e.g., sandstorms. Task reports describe o perations. A second difference is that with task reports in cont rast to orders the sender of the report does not always know the unit or person executing the task being reported. Theref ore grammar rules must exist to allow the descripti on of the executer by more general terms, e.g., by unit type or person type (“two snipers”). A third difference is that r eports, especially those about the enemy, must allow the expression of u certainty (“Enemy may be preparing an ambush”). This paper describes an initial set of the grammar’ s rules for reports, taking into account the differ ences between orders and reports. It illustrates the use of BML i n general and especially the use of the report rule s by giving an example of BML communication in a scenario of asymm etric warfare. In this scenario, a patrol is ambush ed by snipers. The communication is between lower echelon units. I n particular, it involves the patrol, its battalion headquarters, a relief force, an Unmanned Aerial Vehicle (UAV) for reconnaissance, engineers for recovery, and medical support. This example illustrates how shared word semantics provi ded by the Joint Consultation, Command and Control Inf rmation Exchange Data Model (JC3IEDM) and the grammar give meaning and illocutionary force to the BML transact ions. 1. Need for a Generalized Language for Command and Control Coalition Interoperability has typically been addre ss d though message exchanges between Command and Control (C2) systems. There is a transition underw ay to a more structured communication based on exchanging d ata elements of common data models. One of these model s is the Joint Consultation Command and Control Informat ion Data Exchange Model (JC3IEDM) provided by the Multinational Interoperability Programme (MIP) [20] . While the data elements exchanged are semantically we specified by the model, the communication of inform ation is still in ad hoc messages. The syntax and grammar of these communications is lacking. It is needed, howe ver, to construct the meaning of messages exchanged from th e semantics of these messages’ data elements. In this paper, we present a grammar for Command and Control. We have previously presented this grammar for Orders [25]. Here we present a grammar for Reports. These grammars are designed to be computationally tractable so that statements can be both expressive and able to be parsed. Also, these grammars will be of great benefit to both Simulations and Robotics, which cur rently suffer from little to no commonality in how they pr ocess and understand C2 messages. 1.1 Communication C2 Information In a network-centric environment, information empow ers the participants (both human and automated decision systems). The exchange of information has to run smoothly such that fleeting opportunities can be no ticed and exploited by the participants in time. In order to optimize the information exchange and to deal in a timely fashion with the huge amount of information exchang ed, forces have to be equipped with smart C2 systems wh ich automatically pre-process the incoming information. It is not only necessary that the right information is av ailable at the right time, it is also necessary that the in formation is understood correctly at the right time (cf. [2], chapter 12). To achieve these goals is difficult, and it is even more difficult if the forces in question are coalit ion forces. Coalition forces often rely on nation-specific C2-s ystems developed with nation-specific doctrines in mind. Therefore, even if information is exchanged in time on the information level, the “understanding” of the excha nged information by the C2-systems normally will be diff erent and thus a force that receives information often re acts to it a different way than the sender had intended. The effective empowerment of Coalition C2 is predic ated on the satisfaction of two key conditions. First, as Alberts and Hayes [2, chapter 7] described, the most direct way to ensure a desired degree of interoperability is to e xchange i formation by communicating in a common language . With respect to forces, this idea has guided the development of a specific (military) variety of Eng lish and the standardization of military messages, e.g., the standard form of an Operations Order is determined by STANAG 2014. Military doctrines have leveraged thes e standards, such that for example professional NATO soldiers know by heart how an Operations Order has to be structured and how such an order is to be read and interpreted. However, many military messages formul ated according to military doctrine are “free text” and as such hard to process automatically. Second, as Devlin p resents [10], the effectiveness of any interaction is depen dent on degree and quality of a shared context among the participants. 1.2 Need for Formal Grammars A grammar, the essential part of a language, provid es rules constituting how the lexical elements of the language in question can be connected and how the meaning of the catenation can be derived from the meaning of the parts if the parts are connected acc ording to the grammar’s rules. For example, grammar determ ines that in the sentence “ The US general ordered the German general to attack ” it is the German unit that will attack whereas in the sentence “ The US general promised the German general to attack ” it is the US unit. In contrast, the JC3IEDM lists terms, e.g. mission terms, merely as words. E.g., “advance” is a value provided by the t able “action-task-activity-code.” The semantics of the t erms is given by a textual description. E.g., “advance” is “ to move toward an objective in some form of tactical format ion [...] .” This description shows the human reader what is meant by “advance”. Neither the meaning of terms li ke “advance”, nor appropriate rules for what can be combined with such terms, can be used by automated processes with the current design of the JC3IEDM. T here is nothing but the human interpreter’s goodwill tha t ensures that a destination (the objective the execu ting nit has to move towards) should be associated with an a ction called “advance” in the JC3IEDM. A grammar as part of a language, however, enforces the existence of a destination and connects “advance” and its destinat io in the intended way. And this is exactly what is neede d to convey understanding to other C2 systems, to simula tion systems and to robotic forces such that the actions are carried into execution as intended. 1.3 A Grammar for Reports In comparison to orders and requests, reports are different, especially with respect to certainty and definiteness. If a military commander orders an att ack, the units that are ordered to execute it are definitely determined. To refer to these units and to give the m the attack order, the commander can use their names. Th i is not true with respect to reports. The sender of a r eport may notice an attack. But, normally, he does not kn w by name which units execute it, especially if the atta ck is carried out by enemy forces. Usually, the sender on ly observes the behavior of troops; he sees that vehic les move and fire. From this, he may infer the type of the involved units, under the best of circumstances. In other cases, especially during operations other than war (e.g., if a convoy runs into sniper fire) the amount of objec tiv information may even be smaller. Nevertheless, a re port has to be formulated and sent, but the BML expressi on that are sufficient for orders and requests are not sufficient for such reports. They, as given above, lack the power to express types of units, types of equipment , vagueness and other required concepts. We therefore have to add rules and non-terminal symbols to cope with reports. 1.4 Roadmap to Rest of Paper The remainder of this paper is organized as follows : Section 2 gives a background on the BML and our previous grammar work for Orders. Section 3 reviews in detail the Lexical Function Grammar, the basis for ou grammar work. Section 4 presents a grammar for Repo rts. Section 5 gives an example of using the grammar and Section 6 concludes with recommendations for future research. Throughout the text, we will also make recommendations for modification to the JC3IEDM to make it more consistent and improve it’s ability to correctly represent military reports. 2. Background – A Grammar for Orders Our grammar work supports a current simulation initiative called Battle Management Language (BML). Within this section we describe BML, and also prese nt the previous grammar work that has been performed for Orders. 2.1 BML Concept and Current Initiatives The definition of BML [6] is