CisBML: A Formal Language for Describing Military Doctrine

(1)

Master Thesis Software Engineering

CisBML: A Formal Language for Describing

Military Doctrine

Liam Blythe

10389210

(2)

Host Organization

TNO - Modeling, Simulation and Gaming Oude Waalsdorperweg 63 2597 AK Den Haag Netherlands

Supervisors

Paul Klint paul.klint@cwi.nl University of Amsterdam Nico de Reus nico.dereus@tno.nl TNO

(3)

7.4.2 Other Tools . . . 67 7.5 CisBML Agents . . . 68 7.5.1 Agents Engine . . . 68 7.5.2 Context . . . 68 7.5.3 Tasks . . . 69 7.5.4 Task Reports . . . 69 7.6 Capabilities . . . 69 7.6.1 Events . . . 71 7.6.2 Task Evaluators . . . 71 7.6.3 Context Evaluators . . . 71 7.6.4 Executable Tasks . . . 71 7.7 Interpreter . . . 71 7.8 Decision Modules . . . 72 7.9 Visualizer . . . 72 8 Results 74 8.1 CisBML Language Specification . . . 74

8.1.1 Requirement: Generic . . . 74

8.1.2 Requirement: Extensiblity . . . 74

(6)

8.3 CisBML Agent . . . 76 8.3.1 Requirement: Maintainability . . . 76 8.3.2 Requirement: Extensibility . . . 78 8.4 Functional Demonstration . . . 83 8.4.1 WorldSate Simulator . . . 83 8.4.2 Full Setup . . . 83 9 Conclusion 89 9.1 Contributions . . . 89 9.2 Discussion . . . 89 9.3 Future Work . . . 90 A Metrics 95 A.1 Maintainability . . . 95

(7)

Glossary

• BDI Belief-Desire-Intention

• BML Battle Management Language • C-BML Coalition BML

• C2 Command and Control

• C2LG-GUI C2 Lexical Grammer Graphic User Interface • CC Cyclomatic Complexity

• CGF Computer Generated Forces • CIS Combat Instruction Set

• CisBML Combat Instruction Sets BML

• FFI Norwegian Defence Research Establishment. Norwegian Research Institute.

• FOM Federation Object Model • HLA High Level Architecture • IBML Integrated BML

• ISIS The Integrated Staff Information System • JBML Joint BML

• JMS Java Messaging Service • LLBML Low Level BML • LOC Lines Of Code

• M&S Modelling & Simulation • MAS Multi Agent System

(8)

• NATO North Atlantic Treaties Organisation

• NLDA Callsign for A-Company of the 42nd Armoured Tank Battalion, used in our demo scenario.

• NMSG NATO RTO Modeling and Simulation Group • ORBAT Order Of Battle

• RNLA Royal Netherlands Army

• RPR-FOM Real-time Platform Reference FOM

• SISO Simulation Interoperability Standards Organisation

• TNO Toegepast Natuurwetenschappelijk Onderzoek. Dutch Research In-titute.

• VR-Forces CGF Tool used during this project • XML Extensible Markup Language

(9)

Chapter 1

Introduction

1.1 Problem domain

In Military organisations, Modelling & Simulation (M&S) systems are used dur-ing traindur-ing exercises and operations to simulate the execution of orders issued by military commanders. During such training exercises, operators receive or-ders issued by military commanor-ders through a Command and Control (C2) system, and input these into the M&S system. However M&S systems typically operate only on lower echelons of the military hierarchy (e.g. on individual platform level or platoon level). Orders issued by higher echelon commanders (e.g. battalion commanders) cannot be directly input into the M&S system.

Furthermore, the use of human operators is expensive. To this end, recent efforts have been devoted toward the development of a means to eliminate the need for operators, thus moving toward an automated approach for interopera-tion of C2 and M&S systems. The result of these efforts has been the concept for a Battle Management Language (BML) [18].

Conceptually, BML is a language which attempts to capture, unambiguously, all information required by both a C2 system and M&S system such that it allows for interoperation.

However, whilst traditional BML forms provide the means for interoper-ation between C2 and M& S systems, they do not address the issue of how orders are translated from higher echelons to lower echelons. To this end, both TNO (Netherlands) and FFI (Norway) have recently devoted effort toward de-velopment of Multi-Agent Systems, which act as commanders in the military hierarchy capable of receiving orders and translating them into sets of orders which are issued to subordinates. TNO’s Multi Agent System translates orders based on embedded Combat Instruction Sets (CIS). A CIS is a type of military doctrine which describes how a particular type of action is to be performed. One such example of a CIS is the formation in which a platoon must move during a combat patrol, or the coordinated sequence of actions to be performed during an attack maneuver.

(10)

Unfortunately, TNO’s Multi Agent System only implements CIS for a limited number of actions and the CIS it implements are embedded in the source code. Furthermore, the system is riddled with design shortcuts and trade-offs which lead to functionalities that do not perform according to their requirements. Finally, the difficult code structure and poor coding practices make it difficult to maintain and extend.

Despite these problems, TNO’s Multi Agent System has recently drawn in-ternational interest. However, as the embedded CIS are based on doctrine provided by the Royal Netherlands Army (RNLA), other countries would likely wish to implement their own doctrine. Given the maintainability and extensi-bility issues, as well as the numerours malfunctions, the Multi Agent System in its current form is not ready for international distribution and development.

1.2 Research Question

Given the need for a system that is capable of supporting a wide array of CIS, the primary question put forth in this thesis is how one can develop a standard for describing military CIS, such that it is flexible, extensible and implementable by (agent) systems. Here, flexible means that different CIS can be defined for the same type of action. Extensible means that the developed standard is open for extension to support new types of actions, as well as extending the capabilities of the language beyond that of its original design specification, preferably with no modification of the existing language components.

1.3 Proposed Solution

This thesis proposes a new type of system that allows for flexible description of CIS using a purpose built Domain Specific Language. Furthermore, keeping in mind the intention for international distribution and development, this new system is purpose built with maintainability and extensibility at the forefront of its architecture. Implementation of this new system will be realized in the form of a new Multi Agent System, however this thesis will focus primarily on the development of CisBML, a domain specific language developed for describing CIS, inspired by BML.

1.4 Contributions

The primary contribution of this work is the development of CisBML. A fo-mal language used to describe how higher echelon orders are delegated to lower echelons in the military hierarchy. CisBML has been accompanied by the devel-opment of a new Multi Agent system which is capable of interpreting CisBML, such that it can receive higher echelon orders issued by C2 Systems as input, and output lower echelon orders to M & S systems. Furthermore, this new Multi Agent System places maintainability and extensiblity at the forefront of

(11)

its architecture with the primary goal of providing a platform which can form the basis for international distribution and future development of CisBML.

1.5 Thesis Outline

Chapter 2 describes background and related work. Chapter 3 describes the over-all system architecture currently employed by TNO for interoperation between C2 system, Agents and M&S system. Chapter 4 describes the architecture of TNO’s current MAS. Chapter 5 describes the CIS used for the development of CisBML. Chapter 6 describes the design of CisBML itself and chapter 7 pro-vides and overview of the architecture and implementation of the new MAS that implements CisBML. Chapter 8 evaluates performance and quality of the proposed solution compared to the current MAS. Finally, chapter 9 discusses the conclusion and provides recommendations for future development.

(12)

Chapter 2

Background and Related

Work

2.1 Military Hierarchy

Military organisations have a command hierarchy. Figure 2.1 displays the army command hierarchy of military organisations. Previous work by TNO regarding the development of Multi Agent Systems for interoperation of C2 Systems and M&S systems has focussed on the platoon and company levels. Simulations were done using Armoured platoons, rather than infantry platoons. As such, platoons were modelled as units consisting of 4 tanks, rather than 3-4 squads.

2.2 Command & Control (C2) Systems

“

The exercise of authority and direction by a properly designated comman-der over assigned and attached forces in the accomplishment of the mission. Command and control functions are performed through an arrangement of per-sonnel, equipment, communications, facilities, and procedures employed by a commander in planning, directing, coordinating, and controlling forces and op-erations in the accomplishment of the mission. Also called C2.

”

Dictionary of Military Terms and Acronyms, US Department of Defense, 2011

Military Command and Control systems are used for planning and coordi-nation of operations by military commanders. In this section we will discuss briefly the C2 systems used by the RNLA, as well as a surrogate C2 system used for C2-M&S interoperation by TNO.

(13)

(14)

Figure 2.2: Military staff working with ISIS

2.2.1 ISIS

The Integrated Staff Information System (ISIS) [14] is the C2 System used by the RNLA. The Dutch Ministry of Defence states that ISIS consists of three subsystems: Geographic Information System (GIS), which is used by the army to determine and exchange data about units and objects. It displays a digital map with information and allows vehicle crews linked with the GIS to follow the common operation picture, providing near-real time information about the situation in the area of operations. The Order Of Battle (ORBAT) subsystem which commanders can use to simulate a military combat operation or order of battle. Finally the Operational Order Template subsystem is a tool for produc-tion and coordinaproduc-tion of Standard Operaproduc-tion Orders. Commanders can draw up and distribute operational orders quickly and in a uniform way using Opera-tional Order templates that work on Microsoft Word. Unfortunately, BML has not been integrated in ISIS to allow interoperation with M&S systems. However in the updated version of ISIS, named ELIAS, this has been foreseen.

2.2.2 C2 Lexical Grammar GUI

C2 Lexical Grammer (C2LG) is a context free language for specifying orders and reports in C2 systems, developed by the German research institute FGAN-FKIE. This institute has developed a graphical user interface to ”allow and to facilitate the formulation of orders (and reports) according to the C2LG’s rules” [39]. Essentially, the C2LG-GUI is a C2 Surrogate. The C2LG-GUI also includes a plug-in that allows import and export of orders and reports in C-BML format, allowing interoperation with other C2 and M&S systems. During this thesis project, the C2LG-GUI was the C2 system used to issue BML orders. The setup for interoperation with M&S systems is discussed in chapter 3.

2.3 Military Modelling & Simulation Systems

According to Sandercock et Al. [44], military simulation is a term that en-capsulates several definitions. In this paper, military simulation refers to the

(15)

simulation of military environments with the purpose of research and training within the defense domain. To this end, numerous different military simula-tion systems exist, including VR-Forces [13], Virtual Battlespace (VBS) [12] and SWORD [9]. At first glance, several of these simulators have the outward appearance of a computer game (indeed VBS 1.0 was developed based on the game Operation Flashpoint), however the distinction between these simulators and computer games lies in their primary goals: computer games are developed for entertainment, simulators are developed for realism. To this end, games can sacrifice realism for entertainment, where simulators need to model real-world behaviour.

2.3.1 Computer Generated Forces

”Computer Generated Forces (CGF) is a term used to describe all actors in a [military] simulation that are not controlled by a human” [44]. The term CGF tool can also be used to describe certain military simulators, such as VR-Forces. CGF are developed to exhibit realistic human behaviour. Within the problem domain of C2-M&S interoperation, we want CGF to be capable of receiving higher echelon orders, and executing these following a given military doctrine or tactic. Unfortunately, CGF tools generally do not support standards such as C-BML, because these standards are still under development. Furthermore, few CGF tools include any such modelling of military doctrine for higher level echelons, because military doctrine is often military organisation specific [15].

2.3.2 VR-Forces

VR-Forces was developed by VT Mk [13] as a tool to support CGF simulation. At TNO, previous work regarding C2-simulation interoperation has seen exten-sive use of this tool. To this end, VR-Forces has seen continued use in this thesis project as well. Figure 2.3 shows a screenshot of the Vr-Forces.

2.4 Interoperability Standards

In this section, we discuss the various interoperation standards used during this thesis project.

2.4.1 Battle Management Language

“

BML is the unambiguous language used to command and control forces and equipment conducting military operations and to provide for situational awareness and a shared, common operational picture.

”

(16)

Figure 2.3: A screenshot of VR-Forces.

BML is an open standard under development, used for unambiguous expres-sion and communication of orders, reports and requests [42]. It is intended to facilitate interoperation between C2 systems, M&S systems and real units by providing a common format for the exchange of such information [38]. Several dialects of BML have been developed (including IBML [3], C-BML [20], LLBML [15] and JBML [2]).

Coalition BML (C-BML)

During the development of various BML specifications (including XBML and Joint BML), the NATO RTO Modeling and Simulation Group (NMSG) found that Coalition operations have an even greater need for interoperability than national or joint operations. To this end, NMSG chartered the MSG-048 activity (2006-2009) group to explore the concept of a Coalition BML (C-BML) [2].

In 2010, NMSG has chartered the follow-up activity MSG-085, which is chartered ”to demonstrate and facilitate the operational utility of MSDL and C-BML in military coalitions”[40]. The first draft of C-BML was released by the Simulation Interoperability Standards Organisation (SISO) in April 2012 [20], this C-BML standard is defined utilizing an XML schema.

However, several other XML schema based varieties of C-BML have also been developed. In 2011, the George Mason University C4I Center developed an experimental C-BML schema that utilizes Integrated BML (IBML, see section 2.4.1). This version of C-BML was used in George Mason University’s own experimental C2 system BMLC2GUI up until version 1.3.1, which was released in 2011.

The French company Cassidian also developed a similar schema named Cas-sidian C-BML. This schema also implements IBML. The CasCas-sidian C-BML schema is used by the FGAN-FKIE C2LG-GUI as the schema for exporting BML orders. At the time of writing this thesis, the latest version of the

(17)

C2LG-GUI is 2.66. Note that because we use the C2LG-C2LG-GUI as our C2 System, the C-BML schema used during this project is the Cassidian C-BML variant.

Integrated BML (IBML)

One of the currently most prominent BML versions is Integrated BML ( IBML), which was successfully tested in the MSG-048 experiments [43]. It has found use in several other BML schemas, including George Mason University’s exper-imental C-BML and Cassidian C-BML.

2.4.2 Military Scenario Definition Language (MSDL)

The Military Scenario Definition Language (MSDL) is a developed SISO stan-dard [21] that allows automatic initialization of C2 systems and M&S systems. It is intended as a mechanism for representing military scenarios, independent of any specific application. MSDL is essentially a snapshot of an instant in time, which provides information about ”the order of battle (ORBAT), already defined control features, and general relevant information, e.g. about the weather”.[43]. The ORBAT conveys information such as strength, command structure and hierarchical organisation of units, equipment and personnel. Control features define routes, areas, points of interest, etc. MSDL is defined utilizing an XML schema. As such it can be exchanged between C2 systems, M&S systems and Scenario development applications. As XML, MSDL files can be readily checked for conformity against the standard’s defined schemas. The MSDL Product de-velopment group has worked in close collaboration with the C-BML Product Development Group to ensure that the two standards are compatible and plans exists for integrating MSDL and C-BML in the future [38].

2.4.3 High Level Architecture (HLA)

The High Level Architecture (HLA) was developed by Dahmann Et Al. [19]. It for allows interoperability between various types of simulation, using a common basis of understanding. Simulators connected by HLA are known as federates, although other types of federates are also possible (e.g. C2 systems). Federates share a common model, the Federation Object Model (FOM), to specify what information can be exchanged between them. FOMs are recorded in XML files. When all connected simulators adhere to the FOM model, data transmitted over the HLA bus can be interpreted by each federate. Should additional information be required from a simulator, the FOM will need to be adjusted so that other federates can receive this information. A standardized FOM named the real-time platform reference FOM (RPR FOM) was released by SISO in 1999.

Furthermore, recent developments have seen the release of HLA Evolved. This is an updated version of HLA which allows modular FOMs. By using Modular FOMs, federates no longer need to share the exact same infromation. Federates that do not require certain information, do not need to use the FOMs of federates that do; they can use only the FOMs that contain the information

(18)

they do need. To illustrate its usefulness: TNO’s agents communicate with VR-Forces using the RPR FOM, extended with an LLBML FOM. However, use of modular FOMs still allows communication with other coalition federates that only use the RPR FOM.

2.4.4 Low Level BML (LLBML)

LLBML was developed as part of the work by TNO and FFI to develop agents capable of decomposing C-BML orders (issued by C2 systems) into lowlevel commands and tasks understandable by a CGF tool. Furthermore, LLBML is also used to communicate events and reports from the CGF tool to the agent systems. LLBML is specified in a FOM module which is shared between the CGF and agent system [15]. LLBML was developed to be independent of any specific COTS CGF tool, military doctrine or tactics, with the intent of pro-viding compact lowlevel tasks that can easily be interpreted and executed by CGF tools. Furthermore, it is meant to reflect capabilities commonly present in CGF tools. LLBML is implemented as a HLA FOM as this is one of the most standardized ways of communication between simulaton systems.

2.5 Bridging C2 Systems and CGF with

Mili-tary doctrine

Potts et Al. [37], Real Time Visuals [8] and Antycip[1] have developed commer-cial products for capturing and representation of military tactics and doctrine. These systems extend CGF to realize higher level reasoning and decision mak-ing. However, they do not understand C-BML and do not appear to create reusable languages for communication with CGF [15]. Pullen et al.[38] describe a bridging application between systems using MSDL/C-BML and VR-Forces. This application is capable of converting simple MSDL and C-BML documents into calls to the C++ Remote Control Interface that is provided by VR-Forces. However, [15] concluded that this ”solution is not capable of planning and exe-cuting tasks for higher echelon units”. To this end, Collaborative efforts between TNO and FFI have focused on the development of MAS that are capable of de-composing high level C-BML orders into lowlevel BML (LLBML) commands according to military doctrine.

2.5.1 Multi Agent Systems (MAS)

TNO and FFI each developed their own MAS, investigating different agent paradigms: TNO decided on the Belief-Desire-Intention (BDI) paradigm and FFI decided on the Context Based Reasoning paradigm. While both agents exhibit similar functionality, implementation of these agents using different paradigms will allow for future comparison [15]. The architecture of TNO’s MAS will be discussed in chapter 4.

(19)

2.5.2 Combat Instruction Set (CIS)

The RNLA provided documents that describe military doctrine on company and platoon levels, which can be turned into intelligent agent behaviour. These documents are known as Combat Instruction Sets (CIS). TNO’s MAS was ex-tended by Luik [23] to implement a number of CIS. CIS will be further discussed in chapter 5.

(20)

Chapter 3

C2-Sim Architecture using

the Multi Agent System

3.1 Outline

In this chapter we will discuss the architecture used by TNO for establishing C2-simulation interoperation. Figure 3.1 depicts the complete architecture. In the following sections of this chapter we will discuss each of the components and their interaction with one another.

3.2 C2 System

The FGAN-FKIE developed C2 surrogate C2LG-GUI serves as our C2 sys-tem.The C2LG-GUI can be used to send C-BML orders to the Scripted BML server and receive reports from it. The commander interacts directly with this C2 system. C2LG-GUI is also capable of producing MSDL files. These could also be sent to the SBML server. However neither VR-Forces nor LLBML cur-rently implement any mechanism to handle MSDL dynamically. As such, MSDL files produced by our C2 system must be manually input to our M&S system and MAS.

3.3 Scripted BML Server

The FGAN-FKIE SBML server serves as a repository for BML orders and re-ports. Connected systems can send orders and reports to the Scripted BML server via a webservice (publishing). Systems can also request to be informed by the Scripted BML server of a submitted order or report (subscribing). Sub-scribing is done using Java Message Service (JMS) [6]. When an order or report is published to the Scripted BML Server, subscribers are informed. The pub-lish/subscribe dynamic of Scripted BML servers is discussed by Nicklas [24].

(21)

Figure 3.1: The current architecture for C2-simulation interoperation using TNO’s Command Agents MAS. Note that SBML is used to abbreviate Scripted BML. Graphic elements used in this diagram were obtained from [4].

(22)

3.4 Scripted BML Gateway

The Scripted BML gateway is an application developed to interface the Scripted BML Server with HLA. It subscribes to C-BML orders from the Scripted BML server using JMS. C-BML orders transmitted over the HLA bus. Finally, the Scripted BML Gateway also subscribes to C-BML reports transmitted over the HLA bus, and sends these to the Scripted BML server using the provided webservice.

3.5 Command Agents

The TNO Command Agents is the MAS developed by TNO. This system will be further discussed in chapter 4. The Command Agents receive C-BML orders transmitted over the HLA bus and decompose these into LLBML tasks. They also receive LLBML events and reports are received over the HLA bus, and act on them appropriately. Finally, the Command Agents generate and transmit C-BML reports.

3.6 Plugin

LLBML was developed during collaborative efforts between TNO and FFI. As such, VR-Forces does not natively understand LLBML. To this end, they de-veloped a plugin to VR-Forces which is used to interface it with LLBML.

3.7 MSDL Converter

The MSDL converter is used by VR-Forces to interpret MSDL data such that it can initialize a military scenario from it.

(23)

Chapter 4

Current TNO Command

Agents Architecture

4.1 Outline

Originally the TNO MAS, named Command Agents, was developed by Bronkers [16] and was later extended by Luik [23]. In the original implementation Bronkers implemented straightforward MOVE, ATTACK and DEFEND tasks. When is-sued with one of these tasks, tanks would move to a designated location. De-pending on the task, the tanks’ rules of engagement would be set to HOLD FIRE, FIRE AT WILL and RETURN FIRE respectively. The agents also im-plemented a SEIZE task, which was imim-plemented as ATTACK at location, then DEFEND that location.

Luik extended the Command Agents to support more complex sequences of tasks, using a set of CIS provided by the RNLA. This project builds on the CIS used by Luik which are discussed in chapter 5.

Since the original development of the Command Agents in 2011, TNO has used it in its continued research projects regarding C2-Simulation interopera-tion and has been demonstrated internainteropera-tionally serveral times. However, the Command Agents suffer from a number of issues and limitations that inhibit international progression within the C2-Simulation interoperability domain.

In this chapter we briefly discuss the agent paradigm used for the Command Agents, the framework on which the MAS was built and its architecture. Finally, we will discuss the issues and limitations from which the Command Agents suffer.

4.2 Belief-Desire-Intention (BDI) Paradigm

TNO implemented its MAS using the Belief-Desire-Intention (BDI) model from Rao and Georgeff (1995) [41]. BDI models agent behaviour in a way related

(24)

Figure 4.1: Belief-Desire-Intention model. Beliefs are created, based on observa-tions from the external world. Beliefs internally trigger goals (desires). A single goal is selected to be pursued by the reasoning engine. In order to fulfill that goal, the agent must select an appropriate plan to follow. The reasoning engine selects a plan, which initiates intention, either changing a belief or actuating some change on its environment.

(25)

to human thinking. Figure 4.1 provides an abstract representation of the BDI model.

Beliefs represent the perceived set of truths about an agent’s environment. As such, beliefs allow an agent to respond to its environment.

Desires represent a set of objectives which an agent wants to achieve. A goal is a desire which the agent has adopted to actively pursue.

Where a goal represents the motivational state of an agent, intention repre-sents the deliberative state. An intention is that which an agent has chosen to do. In other words, it represents a desire to which an agent has in some extent committed. Plans represent a sequence of actions which an agent can perform in order to achieve its intention. An agent does not fully commit to an inten-tion until it starts executing a plan. This is known as the Least-Commitment approach.

Bronkers selected the BDI paradigm as a basis for implementation, based on in-depth comparisons of several paradigms. Luik corroborated Bronkers’ decision. It is not the aim of our project to dispute this. As such, we have continued to use the BDI paradigm as a theoretical basis in our project.

4.3 Jadex BDI Platform

The Jadex BDI platform [5] is a framework in which BDI agents are modelled using Java and XML files. Plans are implemented as Java classes. XML files are used to record beliefs and goals, as well as define how plans are selected. Jadex allows multiple agents to be created based on a single XML file or can instantiate multiple agents, each from a different XML file. To this end, Jadex allows the creation of Platoon and Company agents.

4.4 Architecture

In this section we discuss the architecture of TNO’s Command Agents. The achitecture is shown in figure 4.2.

4.4.1 HLA Manager

The HLA manager is an agent which handles all communication over HLA. C-BML orders and LLC-BML reports and events are received, while LLC-BML tasks and C-BML reports are transmitted. LLBML reports and tasks are commu-nicated directly with the platoon agents. C-BML reports are received directly from the Battalion agents. Other information is sent to the Information Man-ager agent.

4.4.2 Information Manager

The Information Manager is an agent which maintains a full representation of information which is relevant to the agents. It handles initialization of the

(26)

Figure 4.2: The Command Agents architecture. Image obtained from [23].

commanding agents, based on the received MSDL file. The MSDL file con-tains the ORBAT, which lists information on units and equipment, as well as their command hierarchy. Received events are routed through the Information Manager, allowing it to update its representation of the simulation accordingly. When commanding agents want to reason about the state of the simulation, they request that information from the Information Manager.

4.4.3 Battalion Agent

The Battalion Agent receives C-BML orders and delegates tasks contained in that order to the Company Agents. It also implements limited capability for coordination of Company agents.

4.4.4 Company Agent

The Company agents receive C-BML tasks from their commanding Battalion agent. The company agents implement a number of CIS. These CIS are imple-mented as plans. The Company Agent translates C-BML tasks into Platoon behaviour. Furthmore, the Company Agent is capable of interrupting execution of a CIS when ordered to by its commander. It will also resume execution when ordered. Finally, the Company Agents choose formations to use and coordinates platoons into these formations.

4.4.5 Platoon Agent

The Platoon Agent translates tasks received from its commanding Company Agent into LLBML tasks, which are sent to HLA Manager.

(27)

4.5 Issues and limitations

In this section we discuss the issues from which the Command Agents suffer, maintainability and limitations.

4.5.1 Issues

This section discusses a number of problems in terms of functionality offered by the Command Agents.

BML Type

The Battalion agent did not support an established BML type, rather it used a BML schema developed internally. to this end, it was not capable of understand-ing orders sent by any connected C2 system. This agent was later ammended to support the C-BML type used by the C2LG-GUI. However, this support was only partially implemented.

Reports

Whenever a platoon, company or battalion agent completes a task, it sends a task report to its superior. In the case of the Battalion Agent task reports are sent to HLA Manager (in C-BML format), instead of a superior agent. Battal-ion and Company agents consider their task complete when they receive task reports from all their subordinates. Platoon agents consider their task complete when they receive LLBML task reports from the simulator. Unfortunately, this method for reporting does not work in practice. On a regular basis it occurs that tanks in the simulator get stuck or do not move to the exact location they are tasked with. Even when it appears they do, task reports are rarely sent by the simulator. As a result, company agents do not consider their tasks complete because they have not received confirmations from their subordinates. Thus of course battalion agents suffer the same fate as they do not receive confirmations from their company level subordinates.

ORBAT

Luik claims that the introduction of the MSDL allowed the MAS to intialize agents based on the ORBAT. This is partially true, as the command hierarchy was no longer hardcoded. However, the agents themselves are still hardcoded. As such, the Command Agents system is not fully capable of accepting a differ-ent ORBAT.

Trade-offs

Unexpected behaviour and bugs exhibited by VR-Forces have lead to a number of quick-fix trade-offs in the agent. One of the more notable of these is an attempt to fix issues with the reports. The inintial fix was a follows: Instead

(28)

of demanding reports from all subordinates, an agent waits to receive reports from all but one of its subordinates. It then waits a few seconds. If the time expires, the task is considered complete anyway.

However, this still did not fix the issue. As such, an extra condition was added to wait for all but two reports. In practice, this still has not fixed the issue and it should be clear by now that this is not the correct way to go about it.

Unimplemented Functionality

The agents implement only a small subset of functionality needed to fully sup-port the possiblities offered by C-BML and LLBML. This in itself is not a problem. However, combined with the maintainbility issues that we will dis-cuss in section 4.5.2, it is difficult to determine what changes are required to implement new functionality.

Muliple C-BML Orders

The Command agents are currently only capable of receiving a single C-BML order for execution. It is not possible to schedule multiple orders.

4.5.2 Maintainability

When we first started working with the TNO Command Agents, we noticed that the application suffers from a number of issues with regards to code quality. Con-sistently throughout this project we encountered difficulties when consulting the code in attempts to understand the structure and exhibited functionality. How-ever, we were not alone in this struggle. Repeatedly, we heard TNO researchers utter complaints about the difficulty they experienced in understanding and maintaining the application.

As such, we wished to gain a quantifiable understanding of these issues, therefore we decided to analyze the application using an number of software maintainability metrics.

Metrics

The metrics we use are presented in Heitlager et Al [22]. For more information on these metrics, consult appendix A. In our analysis we consider code volume, complexity per unit, code duplication, comments and deactivated (commented out) code. Overall, maintainability is evaluated in terms analysability, change-ability and testchange-ability. More information regarding these metrics can be found in appendix A.

Volume We measure volume by the total lines of code (LOC) in our applica-tion. See table 4.1. The Command Agents application is still a relatively small Java application which faciliates maintainability.

(29)

LOC 7421 Overall Rating ++

Table 4.1: Total LOC in TNO Command Agents.

Complexity Per Unit Complexity per unit is measured by the Cyclomatic complexity of each unit. See table 4.2. Most compilation units do not have significant complexity, however this is not the case for all the code. As such, despite a number of disproportionately complex units, the Command Agents generally scores well in terms of complexity.

Complexity Rating Simple More Complex Complex Untestable

Units 665 32 8 2

Relative Percentage 94% 5% 1% 0%

Overall Rating +

Table 4.2: Cyclomatic Complexity per unit ratings. Relative Percentage denotes the percentage of units that account for the given complexity classification.

Code Duplication Code duplication is measured by the number of copies of the same code encountered. See table 4.3. The Command agents aplication does not score particularly well in this area either.

Lines of Duplicated Code 567 Relative Percentage 8% Overall Rating 0

Table 4.3: Code Duplication. Relative Percentage is measured as percentage of duplicated code lines with regards to total LOC.

Comments and Deactivated Code Comments are not explicitly discussed in [22]. However, when examining the Command Agents application we noticed significant amounts of deactivated code as well as a distinct lack of actual com-mentary in certain sections. To this end we decided to include an analysis on the use of comments. Table 4.4 lists our findings. Notably, deactivated code ac-counts for 73% as much of the total commentary as documentational comments do.

In order to ascertain the reliability of our deactivated code detection method, we performed a manual inspection of the comments marked as code by our algo-rithm. In this instance the algorithm proved surprisingly effective in detecting deactivated code, yielding only a few mathematical equations as false positives.

(30)

Figure 4.3: Distribution of comments and deactivated code in the TNO Com-mand Agents

Type Comments Deactivated Code Number of Lines 1668 1185 Relative Percentage 22% 16%

Table 4.4: Comments and deactivated code. Relative Percentage denotes the percentage of comment lines with regards to the total LOC in the application.

Furthermore, figure 4.3 visualizes the distribution of comments over all files in the application, If we examine this distribution, we notice that only 20% of the files account for 85% percent of the comments. One file in particular stands out, which contains over 300 lines of comments, this file is a utility file, which contains calculations for conversion of various types of coordinate systems.

When examining the distribution of deactivated code, we notice that the files with the largest of volume of deactivated code are files with very little commenting, in other words: determining why the code was deactivated will not be easy, as no motivation for deactivating it was added. Deactivated code is also widely distributed in the application: about 69% of files contain some amount of it.

Other Although purely qualitative, one issue we encountered when working with the Command Agents was that classes are not always what their names suggest they should be. One particular instance of this is the class ”Battalion”, which is a class wich contains only constants used in the application and appears to have no correlation to battalions whatsoever.

(31)

”Conversion”, GeoConvert” and ”MyMath” all contain various methods per-taining to the conversion of geographic coordinates between various formats. Several of these are functional duplicants. Worse, some of these methods do not work correctly.

Overall Evaluation

In this subsection we discuss our overall evaluation regarding the maintainabil-ity of the Command Agents. This evaluation is done in terms of analysabilmaintainabil-ity, changeability and testability, as described in appendix A. We base our evalu-ation on the metrics discussed in the previous subsections. Overall, the quan-titative metrics indicate that the Command Agents score moderately in terms of maintainability. However there are several qualitative aspects that argue the contrary.

Analysability In terms of LOC and code duplication, the Command Agents application does not scores moderately. Although the application is relatively small in terms of code, code duplications do impair maintainability. However, we experience the general disuse of comments as a particularly negative influ-ence, regularly finding ourselves scratching our heads wondering ”what does this code do?” (this is not helped by confusing class names or duplicated and distributed functionality). The widespread use of deactivated code causes even more confusion as it is often unclear why the code was deactivated in the first place and whether this code should be permanently removed or was only tem-porarily deactivated as ”quick fix”. Finally, the message driven architecture of the Jadex platform further complicates analysability, as the code itself provides little insight into the routing of messages or the origins of certain belief values.

Changeability In terms of code duplication and code complexity, the Com-mand Agents’ code scores moderately. With exception to a few disproportion-ately complex units, cyclomatic complexity is fairly low. Unfortundisproportion-ately code duplication is fairly prominent in the application and might lead to problems should any of these clones be changed (in fact, we have observed instances of this in the application).

Testability In terms of unit complexity, testability is slightly affected. How-ever, we have not invested enough effort into testing and correcting the applica-tion to provide any further insights. For the most part, we have not attempted to correct the Command Agents’ behaviour.

4.5.3 Limitations

(32)

Fixed Agent Echelons

The Command Agents only implement battalion, company and platoon agents. Furthermore, the agent echelons responsible for receiving C-BML orders and sending LLBML tasks is hardcoded. As such, expanding or contracting the agent chain is not an option (e.g. in the current implementation, C-BML orders cannot be received by Company agents, nor could LLBML be output by squad level agents).

Hardcoded CIS

CIS are implemented as Jadex plans. These plans are written in Java code.The agent currently implements only a single set of CIS, for a single military organ-isation. Expanding the agent with additional CIS to support a wider range of tasks for a wider selection of military organisations is possible, however doing so would incur a rapid increase in the code base and configuration files of the agents.

The agent currently defines no template or framework as a basis for future implementation of CIS as Jadex plans. Furthermore there is no structured theoretical basis for structured translation of real world CIS to any such format. As such, each new CIS could be implemented in a different way. Components would not be developed in a reusable fashion, leading to duplication of code and functionality. Software quality of the application would further degrade, causing maintainability to suffer more. This is particularly likely if one considers that the developer of the application changes with each rotation of TNO’s interns (which is every 6 months) and even more so if one considers what would happen if this application was distributed to various research groups internationally.

The CIS in their current implementation depend entirely on Java and the Jadex platform. Belief sets, plans and agents depend entirely on the implemen-tation of classes in the Command Agents. As such, implemenimplemen-tation of CIS is inexorably bound to the implementation of the Command Agents itself. This does not allow for CIS implementations to be developed in a portable manner, such that it can serve as the basis for the construction of an internationally collective CIS data set of different military organisations. At least, not unless the Command Agents itself becomes the international development platform for CIS implementations.

Implementation of CIS in the Command Agents currently requires that the developer have knowledge of both Java and the Jadex platform. Implementation of CIS is obfuscated by Jadex framework structures, such as retrievals of beliefs and messaging of subordinate agents. Consider also that not all researchers within the NATO MSG groups are programmers, nor that all the programmers use Java (let alone Jadex).

Summarized, expansion of the Command Agents with new CIS is not a viable option without the development of a structured theoretical basis for im-plementing real world CIS. Even with such a basis, implementation of these CIS in the Command Agents requires specific knowledge which is not owned by all

(33)

involved researchers, nor is the format itself portable.

4.6 Summary

Given the various issues and maintainability problems of the Command Agents, it is clear that it is not ready for international distribution. Furthermore the current implementation of Java and Jadex does not facilitate international col-laborative development and there is a need for a structured theoretical basis for translating real world CIS. Therefore, coupled with the fact that the Command Agents is a relatively small application it is worth considering if it would be better to do away with the current implementation and start from scratch.

(34)

Chapter 5

Combat Instruction Sets

5.1 Outline

This chapter discusses the CIS currently implemented in TNO’s Command Agents. This chapter is based entirely on Luik [23]. The CIS presented in this chapter were provided by the Royal Netherlands Army (RNLA) for use by TNO. These CIS were designed for use with the Tactical Indoor Simula-tor (TACTIS) [10], developed by Thales. Note that, building on the previous works by [23] and [16], the CIS discussed in this section will be constrained to tank platoons and companies. For brevity, we will focus mainly on the CIS Assault An Enemy Position. It is also important to note that all CIS discussed in this chapter are platoon level CIS. In other words, these CIS were designed for execution by tank platoons. In the same manner as Luik [23] assumed linear transformation of CIS to company level, we will do the same.

5.2 Scenario Description

Before discussing the CIS, this section presents a demo scenario description for which the CIS were selected. This scenario is formulated according to the Format for Operations Orders, as described in NATO Stanag-2014 (page 28) [45]

5.2.1 Situation

The town of Marnehuizen, Groningen, Netherlands (Population: 0), has been seized by opposing forces (Expected strength: 1 platoon). This town must be retaken. A-Company of the 42nd Armoured Tank Battalion, codename NLDA, has been assigned this task. Arial surveillance indicates enemy activity is fo-cussed in the centre, and south-west perimeter of the town. Intel suggests that the nearest enemy reinforcements are located at a forward operating base, 10km

(35)

to the north-west of Marnehuizen. Enemy presence to the south and/or west of Marnehuizen is not expected.

5.2.2 Mission

NLDA will assault and recapture the town of Marnehuizen from the south-west, taking the enemy by surprise. After recapture, enemy retaliation is expected from the north-east.

5.2.3 Execution

To maintain the element of surprise, NLDA must move into the mission area as quickly as possible. Once in the mission area, NLD will execute the assault. After retaking the town, NLDA must establish a perimeter on the north-east side to block any enemy counter offensive.

5.3 CIS: Assault On An Enemy Position

The primary CIS employed in the execution of the presented scenario is the Assault An Enemy Position CIS.

5.3.1 General Description

(36)

“

The assault is the actual overrunning and seizing of an enemy position. The platoon is operating in an assault as part of a company team and will hardly operate independently because of its limited combat power. To be successful the combat ratio of an assault has to be 3 : 1, so a company team can assault a (reinforced) enemy platoon. Basically the assault will take place by fire and movement of the company team, supported by indirect fire and/or air support. After crossing or on the start line (± 1500 m from objective) at H-hours, the platoons will disperse (line formation) and move forward (traveling) in the di-rection of the objective. When enemy is firing, the company team will move forward by fire and movement (platoon bounds and/or section bounds). When the final phase of the assault begins (± 600 m from objective), all vehicles move with maximum speed in the enemy direction while firing on enemy positions. Tanks will cross the objective and take in positions 300 - 500 m beyond it, to secure the seized objective from counter attacks. Aifvs [Armored Infantry Fight-ing Vehicles] will dismount aggressively at the edge of the objective and vehicles and firing teams will move forward by fire and movement. After cleansing the objective the armored infantry platoon(s) will also take in positions 300 - 500 m beyond the objective and, with the tank platoon(s) consolidate and reorganize.

”

Assault an enemy position - Mechanized Infantry Platoon

“

An assault is the culmination of an attack that closes with and destroys the enemy; it is the actual overrunning and seizing of an occupied enemy position. Normally the assault force is composed of tanks and infantry elements under the control of company (team) commander. The assault force moves by fire and movement (See CIS ”Platoon fire and movement”) along covered and concealed routes to the enemy position until it reaches the assault position (the last covered and concealed position before the objective). Typically, tanks lead, with Aifvs following to protect against dismounted infantry and provide suppression to the tanks. The assault elements move rapidly in a line formation, under cover of direct and indirect fires to the objective, moving through it to the far side and consolidate and reorganize. Infantry dismounts to mop up resistance and clear objective.

”

(37)

5.3.2 Summarized

Using on the CIS given above, [23] surmised the following interpretation. • Preconditions

– Combat ratio of 3:1

– Start line at ± 1500m from objective. • Phase 1: Preparation

– Company moves to the assault start line,± 1500m from the objective. – At the start line, company and its platoons move into Line

forma-tions.

• Phase 2: Fire & Movement

– Company moves to 600m from the objective.

– Movement is carried out using CIS: Line Formation Traveling – However, if company comes under fire it executes CIS: Fire &

Move-ment instead

• Phase 3: Attack Objective

– Company moves to objective, executing CIS: Final Phase of Attack • Phase 4: Consolidate & Reorganize

– Company crosses objective and takes in positions 300 - 500m beyond it.

– Platoons execute CIS: Consolidate & Reorganize.

The CIS Assault An Enemy Position incorporates a number of other CIS. These CIS are discussed in the following sections.

5.4 CIS: Fire & Movement

During the assault on an enemy position, fire and movement is simultaneously moving and firing at the enemy position. During this maneuver, one element provides overwatch or provides fire to suppress or destroy the enemy, while the other element bounds to the next concealed position along the route of attack. In the example CIS provided by the RNLA [34], fire & movement is carried out using one of two movement techniques:

• Line Formation Bounds (both company & platoon CIS were provided) • Line Formation Successive Bounds (both company & platoon CIS were

(38)

5.5 CIS: Final Phase of Attack

This CIS is described as a latter part of the CIS: Assault An Enemy Position [33]. During execution, elements of the company

• move using CIS: Line Formation Successive Bounds, thus providing max-imum fire power in front.

• fire at will on enemy positions.

5.6 CIS: Consolidate & Reorganize

Consolidate and reorganize is defined as the process of preparing for continued fighting. Including the evacuation of casualties, conducting essential mainte-nance, and redistributing supplies, equipment, and personnel. During this phase of the assault, platoons are tasked to execute the CIS: Hasty Occupation of a Battle Position [32].

5.7 CIS: Line Formation

Formations are described as a means to establish vehicle positions and sectors of responsibility during operations. [28]. Line formations are used when a platoon/company [26, 28, 30]

• is on the move while assaulting an enemy position.

• is required to engage the enemy while moving forward or backward. • has to cross an open terrain or dangerous areas as quickly as possible,

whilst providing maximum firepower to the front.

This section describes three types of line formations used in the CIS Assault An Enemy Position (section 5.3).

5.7.1 Traveling

In [30], execution of the Line Formation Traveling is described as follows: ”The line formation traveling is formed with all vehicles continuously moving in a line, vehicles 2 and 3 are moving abreast and slightly behind vehicles 1 and 4.” [30]. See figure 5.1.

5.7.2 Bounds

The Line Formation bounds [26] is performed by all vehicles moving simulta-neously, in a line, from one covered position to the next. The length of the bounds is not fixed as it depends on the possiblities for cover and concealment, but should not be more than 500 meters. See figure 5.2.

(39)

Figure 5.1: Line Formation Traveling. Tanks move together in a line, where tanks 2 and 3 are moving abreast and slightly behind tanks 1 and 4.

Figure 5.2: Line Formation Platoon Bounds. The entire platoon moves simul-taneously from one cover position to the next.

(40)

Figure 5.3: Line Formation Successive Bounds. Tanks 1 and 2 make a bound for the next cover position. Then tanks 3 and 4 close up on the other two.

5.7.3 Successive Bounds

Execution of the Line Formation Successive Bounds [28] is performed with two vehicles moving simultaneously to the next concealed postion, while the other two vehicles provide overwatch. The other two vehicles then close up on the first two vehicles by bounding to a concealed position slightly to the left side, abreast of the first two vehicles. See figure 5.3.

5.8 CIS: Hasty Occupation of a Battle Position

According to [35], hasty occupation of a battle position is used when conducting offensive or defensive operations and insufficient time is available to go through the stages of deliberate occupation. Vehicles of a platoon move from a dispersion point to a firing position, orienting themselves in the expected direction/avenue of an enemy attack and/or assigned area of engagement.

5.9 Current Implementation Notes

In TNO’s Command Agents system, the preconditions listed for the CIS Assault An Enemy Piosition5.3 are not explicitly checked. Rather, the NLD battalion is intialized at a location that is greater than 1500m away from the enemy position.

(41)

Furthermore, no explicit check is made regarding the required friendly to hostile (3:1) ratio, this precondition is also satisfied by the demo scenario.

During the execution of ”Phase 2: Fire & Movement”, companies and pla-toons only move in line formations. Bounding movements have not been imple-mented.

(42)

Chapter 6

CisBML

6.1 Motivation

Contrary to TNO’s Command Agents, which embeds the implementation of a single set of CIS within its code. The driving motivation behind CisBML is the development of a language capable of describing CIS, such that an agent system can perform the same actions in different ways, analogous to how differ-ent military organizations have their own doctrine. In other words, where an order or task specifies what has to be done, CisBML describes how it is to be carried out. CisBML is developed for use in Multi Agent systems which act as substitutes for military commanders, therefore it focuses entirely on specifying how issued tasks are to be delegated to subordinates.

6.2 Requirements

1. Generic CisBML shall be capable of describing CIS in a manner that is independent of any specific military organisation or scenario, nor shall it implement any pretences pertaining to specific elements or group sizes. 2. Extensible: CisBML shall be extensible. That is to say, CisBML should

be augmentable with new language structures. Augmentation should not incur changes to the existing language structure of CisBML (other than addition of the new language structure to the existing elements).

3. Unbounded CisBML’s capabilities to express CIS shall not be bound by any particular type or range. It must be capable of expressing any given CIS.

(43)

6.3 Abstract Design

In the previous chapter we have seen instances where a choice must be made between several possible courses of action. For instance, during the second phase of the assault, the company initially moves using the CIS: Line Formation Traveling, but will switch to a different CIS if the company takes enemy fire. In this instance, the CIS prescribes when to opt for a particular course of action.

However, there are also instances where it may fall entirely on the comman-der to assess the situation and determine how a goal can best be achieved. For example, the company commander in our scenario (see chapter 5) executes the given assault task using the CIS Assault An Enemy Position. Now consider that the company commander could choose from a range of possible CIS to perform the task. Why would he settle for that choice? At this point we take into consid-eration the preconditions of that CIS. In our scenario, the situation fulfilled all the precondition for using the CIS Assault An Enemy Position. However if this had not been the case we would want to find a CIS that best fit the situation.

To this end, we have already identified all the elements of the BDI paradigm: the task we receive is our goal. The conditions that make up the situation form out belief set. Our CIS are the plans from which we can choose and, finally, we require some decision model which we can use to determine the CIS tmost suited to achieve our goal. However, we break with the BDI paradigm slightly: In the BDI paradigm, goals are formulated based on beliefs, however in our military context goals are enforced upon us by commanding officer.

6.4 Language Design: Deriving from CIS

In designing the CisBML, we turn to the set of CIS already at our disposal. These CIS were discussed in chapter 5. From these we attempt to derive in-formation pertinent to the expressive capabilities of CisBML. In order to do so, we will examine the interpretations of the CIS that were made by Luik [23] and further destill these such that we can extract the necessary structures and elements. As such, the process has been divided into a number of steps: (1) Reformulation of given CIS interpretations, (2) concept identification.

6.4.1 Step 1: Reformulation of CIS Interpretations

Unfortunately the CIS (and their interpretations) discussed in chapter 5 are not yet formulated in a uniform manner, such that we can clearly identify the structures and concepts we will need in our language. The CIS first need to be reformulated. As seen in the examples provided, CIS act as manuals that describe a sequence of steps to be carried out. To this end, we model the CIS as a set of procedures, not unlike pseudo code. Statements made in each procedure are modeled such that they attempt to convey in a logical, structured manner that which is described in the CIS sample set.

(44)

During the modeling process it became apparent that some CIS depend on certain parameters, such as intermediate destinations to which elements should move during a CIS execution. In the following models, parameters are written in uppercase letters.

For clarity regarding use of certain notations, we will first discuss all the Line Formation CIS, before discussing the other CIS.

CIS: Line Formation Traveling

We assume this CIS is only executed when elements are already in line formation. Line Formation Traveling is executed by all elements in a group simultaneously.

Name: Line Formation Traveling Parameters: DESTINATION Preconditions: Formation: Line Description: Simultaneously: Move to DESTINATION

CIS: Line Formation Bounds

Again, we assume this CIS is only executed when elements are already in line formation. Line Formation Bounds is executed by all elements in the group simultaneously. Elements move at maximum speed from cover position to cover position (but no more than 500m at a time) until they reach the specified desti-nation. It is important to note here that chosen cover positions must be located on the route to the given destination.

Name: Line Formation Bounds Parameters: DESTINATION Preconditions:

Formation: Line Description:

Change Movement Speed to Maximum While (not reached DESTINATION) do

Simultaneously:

Move to next cover position towards DESTINATION, but no further than 500m

(45)

CIS: Line Formation Successive Bounds

Same as Line Formation Bounds, except that during this CIS some elements bound together, while others stay behind to provide overwatch. Once the bound-ing elements have reached the next cover position, the remainbound-ing elements do the same.

Name: Line Formation Successive Bounds Parameters: DESTINATION

Preconditions:

Formation: Line Description:

Change Movement Speed to Maximum While (not reached DESTINATION) do

Alternating:

Move to next cover position towards DESTINATION, but no further than 500m

CIS: Assault An Enemy Position

There are two aspects here which are important to note. First is the use of the word ”simultaneously”. In the same way all Line Formation CIS specify how a unit’s subordinate elements should perform a movement maneuver, we use the same construction here to denote that the entire company should move simultaneously.

The second important note is that ”objective” is not considered a parameter. The reasons behind this will be discussed in the next section.

(46)

Name: Assault An Enemy Position Parameters: (none) Preconditions: Combat Ratio 3:1 Distance to objective > 1500m Description: Phase 1 Simultaneously:

Move to 1500m before objective Change Formation to Line

Phase 2

If (not under fire) then

Execute CIS: Line Formation Traveling (600m before objective)

Else

Execute CIS: Fire & Movement (600m before objective) Phase 3

Execute CIS: Final Phase of Attack (objective) Phase 4

Simultaneously:

Move to 300m behind objective Execute CIS: Consolidate & Reorganize

CIS: Fire & Movement

This CIS appears ambiguous, as the provided description states that execu-tion of this CIS involves some elements moving, while other elements provide overwatch. Yet that same description also states that both the CIS Line For-mation Bounds, as well as Line ForFor-mation Successive Bounds are valid choices, when the former does not involve alternation between overwatch and movement. The specification also does not provide clear guidelines on using one over the other. For simplicity, we assume the use of only the CIS Line Formation Suc-cessive Bounds, as sucSuc-cessive bounding involves elements providing overwatch while other elements move, consistent with the textual description of the Fire & Movement CIS. In doing so, Fire & Movement becomes purely transitive

(47)

and could be eliminated. However, to maintain consistency with the original interpretation, we will not do so.

Name: Fire & Movement Parameters: DESTINATION Preconditions:

(none) Description:

Execute CIS: Line Formation Successive Bounds (DESTINATION)

CIS: Final Phase of Attack

Name: Final Phase of Attack Parameters: DESTINATION Preconditions:

(none) Description:

Change Rules Of Engagement to Fire At Will

Execute CIS: Line Formation Successive Bounds (DESTINATION)

CIS: Consolidate & Reorganize

According to the provided description of this CIS [32], Consolidate & Reorganize generally encompasses a broad number of different activities. However, for the tank platoon this CIS only specifies the hasty occupation of battle positions. This effectvely makes this CIS redundant, however we do not eliminate it for the same reason we do not eliminate the Fire & Movement CIS.

Name: Consolidate & Reorganize Parameters: (none)

Preconditions: (none) Description:

(48)

CIS: Hasty Occupation of a Battle Position

Name: Hasty Occupation of a Battle Position Parameters: (none)

Preconditions: (none) Description:

Change Formation to Line

6.4.2 Step 2: Concept Identification

Parameters As discussed in the previous section, CIS may contain parame-ters. In our examples we see that only locations are used as parameparame-ters. Given the limited size of our sample set, we should not conclude that only locations should be used as parameters.

Phases Some of the CIS are divided into phases. However, not all CIS are.

Constraints Constraints refer to particular changes in the way elements oper-ate (behavioural change). Constraints include Rules of Engagement and Move-ment Speed. However, we also consider Formation to be a constraint, as we consider changing a formation to be a change in the behavioural parameters of an element.

Conditions In the models, we have noted several instances where conditions are used . First, some CIS have preconditions. Second, we have observed branches (if-then-else) within a CIS, where choice of one branch over the other depends on a particular condition. Furthermore, all three Line Formation CIS also stated the assumption that elements are already in Line formation prior to executing that CIS, indicating that constraints may also serve as conditions.

However, there is a distinction between various types of conditions. Con-straints relate to behavioural aspects of an element. Where as combat state of an element (under fire or not) relates to the environment in which the element is operating. To this end we divide conditions into classes: behavioural and situational.

Yet there is also a third, implicit class of conditions we can identify from the sample set: conditions that relate to an element’s own state of being. Consider the following: operating procedures differ depending on an element’s governing military organisation, echelon, service type (army, airforce), etc. The CIS that are applicable to that element depend on such factors, therefore we have a third class of conditions: sentient.

(49)

Repetition The CIS that describe bounding also contain the notion of re-peating an action until a specific goal has been met.

Iteration The CIS that describe bounding also introduce the notion of itera-tion, where units in a group may not necessarily all perform the same action at once, but may do so in a particular order (e.g. one by one, or in an alternating fashion).

Task Execution Aside from execution of included CIS, CIS also state the ex-ecution of specific actions such as ”move”. Recall from section 6.1 that CisBML is developed for use in Multi Agent systems that simulate military commanders. Therefore actions are not carried out by the element itself. To illustrate: during the assault, a move action could be physically carried out by the commander himself, but he would undoubtedly benefit from bringing his platoons with him. To this end, actions are achieved by translating them into tasks, which are delegated to subordinates. Tasks will be disucussed in a later section of this chapter.

Included CIS Execution Execution of a CIS may include the execution of another CIS.

Delegation At this point it is important to note the distinction between ex-ecution of tasks and exex-ecution of CIS. To illustrate, let us use a programming analogy: Consider NLDA as an object with NLDA’s subordinates as its at-tributes, where each of these attributes is a similar object in itself. When NLDA receives the task to assault the town of Marnehuizen, it triggers the execution of the appropriate subroutine ”Assault An Enemy Position” (CIS execution). This subroutine includes calls to number of other subroutines (e.g. ”Fire & Movement”, ”Final Phase of Attack”, etc).

Now let us consider tasks encountered in these subroutines as assignment operations for NLDA’s subordinates. Execution of a task means assignment of that task to its subordinates. Such an assignment then triggers the appropriate subroutines within that subordinate to deal with that task (Task Execution).

Furthermore, by wrapping the tasks in Iteration and Repetition construc-tions, we can control not only what tasks are executed, but also how often and in what order. This allows for constructions such as those used in the Line Formation Successive Bounds CIS.

Locations Locations described in the CIS are not fixed coordinates. Aside from locations provided in the CIS parameters (e.g. destination), abstract lo-cations such as ”objective” and ”next cover” are also used. Such lolo-cations have no predetermined coordinates as the actual location of such a point depends en-tirely on other factors such as governing task (in our case, the order to assault the town), element position, terrain, etc.

CisBML: A Formal Language for Describing Military Doctrine

Master Thesis Software Engineering