AU2012101435A4 - Live combat simulation monitoring system, method and apparatus - Google Patents

Abstract

C:\NRPorb\DCC\EXT4622207 I DOC-19/)9/2)12 A method of monitoring performance in a live combat simulation, including the steps of: generating, on respective simulated firearm units associated with respective participants in the live combat simulation, event data relating to combat events in which the participants are involved during the simulation; and 5 transferring, by communication means of the respective simulated firearm units, the event data to a data capture module. BattlefieldSIM After Action Review System in Context Phase setup Mission ExEtrcise setup Force/unit Review Training Rules Training Rules Forcr/ rii statistics Tralinig Objectives Training Objectives Location Location DS Assignment and Plan Force and unit allocation Weapon Assignment Saldier/u nit/farce /Ileader review, Force Review Soldier/unit/lorcu Unit Review statistics Leader Review iDetailed Phase Lag Soldier Review- Support EvidencLe wr lrce/itnit/persona 160 statistics/ phuse log r - - AA Systern/ - - > Database or, Configuratr.n data Statistics Phaser Log 115 Q r c170 Top 5 weapons y 8 Recent Ph-osu Lug :Command IR NoIntiitr sse Figure 1

Description

Regulation 3.2 AUSTRALIA Patents Act 1990 INNOVATION PATENT SPECIFICATION (ORIGINAL) Name of Applicant: Pathfinder Events Pty Ltd of Suite 1, 6 Graham Street Brisbane QLD 4119 Australia Actual Inventor: Peter Lander Address for Service: DAVIES COLLISON CAVE, Patent Attorneys, 1 Nicholson Street, Melbourne 3000, Victoria, Australia Innovation Patent specification for the invention entitled: "LIVE COMBAT SIMULATION MONITORING SYSTEM, METHOD AND APPARATUS" The following statement is a full description of this invention, including the best method of performing it known to us: C:\NRPonbl\DCC\EXT\4622113_ .DOC - 20/9/12 C:\NRPonbDCC\EXT4622207_ DOC. 19/09/2012 LIVE COMBAT SIMULATION MONITORING SYSTEM, METHOD AND APPARATUS Background 5 Live combat simulation games using firearm-like devices emulating or simulating real-life firearms, such as laser tag or combat games, allow participants or players to participate in realistic combat simulations in a range of different indoor and outdoor environments without substantially endangering their own, and others', personal safety. Such games can 10 be used for entertainment, sport, team building and morale building. In some forms, they may also be suitable for training of military personnel, police, or other persons who may be required to use firearms in the course of performing their duties. In a typical live combat simulation, players are divided into at least two teams. Each player 15 is equipped with a firearm-like device arranged to generally simulate a firearm, such as a rifle or a machine-gun, for example. The devices when fired, such as by squeezing a trigger or pressing a button, emit a focused infra-red beam or pulse directed in the assumed trajectory of a projectile fired from the device. Each player also carries one or more sensors coupled to the device, which may be arranged about the head or on the body of the 20 player, for example, for sensing "hits" (i.e. emitted infra-red beams) from another player. Each player's device may be configured to fire a predetermined maximum number of times and also accept a predetermined number of hits, after either of which the device may enter a "dead" state in which the device is effectively inactive and unable to fire. The player, or a 25 referee supervising the game, may then be able to reactivate ("re-spawn") the "dead" player's device so that the device is again able to be fired and the player can re-enter the game or participate in a further game. One known live combat simulation system is disclosed in our PCT publication 30 WO 2008/074082, the contents of which are hereby incorporated in their entirety by reference. In this known system, real-time feedback relating to whether a first player CANRPo,,bl\DCC\EX-r4622207_LDOC-19/19/2012 -2 bearing a first electric game apparatus has "hit" or "killed" a second player bearing a second game apparatus is provided by a signal, preferably a radio-frequency signal, transmitted from the second player's apparatus and received by a receiver of the first player's apparatus. Players are able to gain an indication of their own performance by 5 viewing statistics displayed on an LCD of their game apparatus, during and immediately after a simulated combat. However, there is no provision in this known system for accurate performance monitoring of the combatants as a whole throughout the course of the simulated combat, or of individuals or teams of individuals after the simulation is complete. For military applications it is very desirable to be able to conduct a review, post 10 simulation, of individual incidents during the simulation, including the time of an incident, the identity of individuals involved (shooter, target, medic etc.) and the outcome of the incident. It would be desirable to overcome or alleviate one or more of the above difficulties, or at 15 least to provide a useful alternative. Summary of the invention In a first aspect, the present invention provides a method of monitoring performance in a 20 live combat simulation, including the steps of: generating, on respective simulated firearm units associated with respective participants in the live combat simulation, event data relating to combat events in which the participants are involved during the simulation; and transferring, by communication means of the respective simulated firearm units, the 25 event data to a data capture module. The method may include processing the event data, on a computer system associated with the data capture module, to generate a summary of the live combat simulation. The summary may be generated in a hierarchical manner. For example, in military applications, 30 the hierarchy may correspond to a military hierarchy and summaries may be generated at various levels of the hierarchy, such as battalion, company, platoon, section/squad, fireteam C \NRPonbf\DCC\EX1\6222u7_ I DOC-]9/09/20 12 -3 or individual. The method, in these embodiments, thus enables detailed performance analysis to be conducted at multiple different levels. In a second aspect of the present invention, there is provided a live combat simulation 5 performance monitoring system, including: a plurality of simulated firearm units, respective simulated firearm units being associated with respective participants in the live combat simulation and being configured to generate event data relating to combat events in which the participants are involved during the simulation; and 10 a data capture module for receiving, from the respective units, the event data. The system may include a computer system coupled to the data capture module. The computer system may include a reporter module for processing the event data to generate a summary of the live combat simulation. 15 In a third aspect of the present invention, there is provided an apparatus for monitoring performance in a live combat simulation, including: a data capture module for receiving, from respective simulated firearm units associated with respective participants in the live combat simulation, event data relating to 20 combat events in which the participants are involved during the simulation. The apparatus may include means for transferring the event data to a reporter module, the reporter module being configured to generate a summary of the live combat simulation. 25 Brief description of the drawings Certain embodiments of the invention will now be described, by way of non-limiting example only, with reference to the accompanying drawings in which: Figure 1 is a schematic block diagram of a combat simulation performance monitoring 30 system according to certain embodiments; Figure 2 is a schematic block diagram of a computer system used with the combat C:\NRPonblDCC\EXT\4622207_ .DOC-19/)9/2012 -4 simulation performance monitoring system of Figure 1; Figure 3 is a schematic block diagram of an interface module coupled to the computer system of Figure 2 as part of the system of Figure 1; Figure 4 is an example display produced by a scoreboard used with the system; and 5 Figures 5 to 8 are flow diagrams showing steps implemented as part of methods of certain embodiments of the invention. Detailed description 10 Embodiments of the present invention employ a computer system 115, in conjunction with various other components, as a "base station" to capture and analyse data generated by units in a live combat simulation system 100, as shown for example in Figure 1. Embodiments of the invention provide a portable "After Action Review" (AAR) system for the military market and for businesses offering advanced combat simulation. 15 In presently preferred embodiments, the AAR system allows a person supervising the combat simulation (the Trainer) to enter and record information on the performance of teams and individuals into a computer system 115, preferably a laptop computer system or other portable computing device. 20 Referring to Figure 1, there is shown a live combat simulation system 100 including a computer system 115 coupled to an interface module 300. The computer system 115 and interface module 300. together form a base station which is in communication with units 500 (only one of which is shown for clarity) operated by participants in the simulation, 25 referred to as Trainees or Gainers depending on the type of simulation. For example, in a military version of the simulation known as Battlefield SIM, the participants are known as Trainees while in "civilian" versions conducted for entertainment, known as Battlefield LIVE or Laser Tag, the participants are known as Gainers. The base station 115, 300 receives and analyses combat data from units 500, and transmits configuration and other 30 data to units 500 in a manner which will be described later. The units 500 are also referred to herein as SATR units.

C:\NRPortb1\DCC\EXi4622207..DOC-I9/9/20I2 -5 The computer system 115 is in communication with a data store 160 which may be located on a storage medium of computer system 115, or alternatively may be located on a remote computer system (not shown) with which computer system 115 is in communication, such 5 that computer system 115 can connect to, read data from and write data to data store 160. In presently preferred embodiments, the data store 160 is a relational database, for example implemented using Microsoft Access, although it will be appreciated that other implementations using MySQL, PostgreSQL, Microsoft SQL Server or Oracle are possible. 10 Data store 160 associates Trainees with one or more SATR units 500, each of which has a unique identifier, and also stores information relating to the relationship between Trainees and their teams, and to the performance of individuals and teams, in a manner which will later be described. 15 SYSTEM COMPONENTS The components of the system 100 illustrated in Figure 1 will now be described in more detail. 20 Computer system 115 In the described embodiment, the system 100 includes a standard computer system 115. The computer system 115 may be a commercially available personal computer or server 25 computer system based on a 32-bit or 64-bit Intel architecture. However, in presently preferred embodiments, the computer system 115 comprises a portable computing device such as a laptop or notebook computer, which may be easily transported by the Trainer or other persons accessing the system 115 during the live combat simulation. 30 The processes and/or methods executed or performed by the system 100 are implemented in the form of programming instructions of one or more software components or modules C:\NRPonbl\DCCEX1\46222071 DOC. 19/09/2112 -6 240 stored on non-volatile (e.g., hard disk) computer-readable storage 202 associated with the computer system 115, as shown in Figure 2. At least parts of the software modules 240 could alternatively be implemented as one or more dedicated hardware components, such as application-specific integrated circuits (ASICs) and/or field programmable gate arrays 5 (FPGAs). The computer system 115 includes at least one or more of the following standard, commercially available, computer components, all interconnected by a bus 214: random access memory (RAM) 204, at least one computer processor 206, and external computer 10 interfaces. The external computer interfaces include: universal serial bus (USB) interfaces 208 (at least one of which may be connected to one or more user-interface devices, such as an external keyboard 216, a pointing device (e.g., a mouse 218 or touchpad)), a network interface connector (NIC) 210 which connects the computer system 115 to a data communications network such as the Internet 112, and a display adapter 214, which may 15 be used to drive an integrated display (not shown) of the laptop 115 and/or be connected to an external display device 220 such as a liquid-crystal display (LCD) panel device. The computer system 115 includes a plurality of standard software modules, including: an operating system (OS) 224 (e.g., Linux or Microsoft Windows) and structured query 20 language (SQL) modules 230 (e.g., MySQL, available from http://www.mysql.com, or Microsoft SQL Server, available from http://www.microsoft.com/sqlserver), which allow data to be stored in and retrieved/accessed from database 160 with which computer system 115 is in communication. 25 The boundaries between the modules and components in the software modules 240 are exemplary, and alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine 30 multiple instances of a particular module or submodule. Furthermore, the operations may be combined or the functionality of the operations may be distributed in additional C \NRPortb\DCC\EXT4622207_1 DOC-19/09/2012 -7 operations in accordance with the invention. Alternatively, such actions may be embodied in the structure of circuitry that implements such functionality, such as the micro-code of a complex instruction set computer (CISC), firmware programmed into programmable or erasable/programmable devices, the configuration of a field- programmable gate array 5 (FPGA), the design of a gate array or full-custom application-specific integrated circuit (ASIC), or the like. Each of the blocks of the flow diagrams of the processes 800, 1000 of the computer system 115 may be executed by a module (of software modules 240) or a portion of a module. The 10 processes may be embodied in a machine-readable and/or computer-readable medium for configuring a computer system to execute the method. The software modules may be stored within and/or transmitted to a computer system memory to configure the computer system to perform the functions of the module. 15 The computer system 115 normally processes information according to a program (a list of internally stored instructions such as a particular application program and/or an operating system) and produces resultant output information via input/output (I/O) devices. A computer process typically includes an executing (running) program or portion of a program, current program values and state information, and the resources used by the 20 operating system to manage the execution of the process. A parent process may spawn other, child processes to help perform the overall functionality of the parent process. Because the parent process specifically spawns the child processes to perform a portion of the overall functionality of the parent process, the functions performed by child processes (and grandchild processes, etc. ) may sometimes be described as being performed by the 25 parent process. Interface module 300 The interface module 300, illustrated in Figure 3, provides a communication layer between 30 computer system 115 and units 500.

CANRPortbl\DCCEXT\462220_I DOC-I9/)9/2012 -8 Interface module 300 includes circuitry components on an interface board 360 which is in communication with an infrared (IR) emitter 340 and a radio frequency (RF) receiver 350. The IR emitter 340 may be any suitable device for emitting IR signals, for example a TSAL6100 high power infrared emitting GaAlAs/GaAs diode of Vishay Electronic GmbH 5 (Selb, Germany). The RF receiver 350 may be coupled to a separate antenna for extending the effective range of the interface module 300. The interface board 360 is also in communication with a serial adapter module 330 which interfaces to a USB port 335 to enable the interface module 300 to be connected to a USB 10 interface 208 of computer system 115. The serial adapter module 330 may be any device capable of converting serial transmissions (e.g. TTL or RS-232) to USB signals, such as a PL-2303 module of Prolific Technology Inc (Taiwan), or a USB-RS232 module manufactured by Future Technology Devices International Ltd (UK), for example. It will be appreciated that the interface board 360 need not include a serial interface, and could 15 instead, for example, employ a USB interface such that it can be directly coupled to USB port 335 for connection to laptop 115. Functions performed by the interface module 300 are implemented in one or more control and processing modules 370. For example, the control and processing modules 370 may include instructions for driving the IR emitter to transmit configuration data or other data 20 to simulated firearm units 500, and instructions for receiving and processing signals/data received via RF receiver 350. The configuration or other data may be received from computer system 115 via USB port 335 and serial interface 330. The interface module 300 may also include a RF transmitter (not shown) capable of transmitting RF signals, for exampleto units 500, acknowledging receipt of data. The RF transmitter may employ a 25 smaller standard antenna and will therefore allow the interface module 300 to use a very large antenna for better range for receiving signals transmitted by units 500 without compliance issues. The control and processing modules 370 may include modules for pre-processing data 30 received from firearm units 500, prior to sending the data to computer system 115 for further processing. However, it is in general preferred that interface module 300 act C :NRPotbI\DCC\EXP4622207_1 DOC.19R)9/2012 -9 primarily as a conduit between computer system 115 and units 500 with the majority (if not all) of the data processing being performed by software modules 240 of computer system 115. 5 Unit 500 A particular example of a unit 500 used in the system 100 will now be describedunit 50OThe functionality of the unit 500 is preferably embodied in a purpose-built firearm-like device for use by a game player or trainee in a live combat simulation. 10 The SATR unit 500 unit 500includes a transmitter for transmitting at a least first, or firing, signal and preferably a second, or feedback, signal. The first signal may be in the form of an infra-red beam or pulse in response to a player in a live combat simulation game firing the firearm, such as applying pulling a trigger of the firearm, that is able to be transmitted 15 towards a target receiver on another game player. The second signal may be in the form of a radio signal, for example, that is transmitted in response to a target receiver on a first game player being hit by the first signal from a like device of another game player, whereby the second signal indicates the hit to that other player, and, in the preferred embodiment, whether the hit has resulted in a kill, hit (wound) or the device of that other 20 player is already in a dead state. Accordingly, when used in the play of a live combat simulation game, an opposing player also equipped with a unit 500 may carry one or more sensors for sensing the transmitted infra-red beam or pulse, which when sensed by the sensor(s) constitutes a hit on the 25 opposition player. Hits on a player may be used to determine functioning of the player's unit 500 and, in consequence, the player's continued participation in the game. The unit 500 integrates a directional infra-red emitter, infra-red sensors system, and a radio control systemunit 500. Each unit 500 includesunit 500unit 500 30 - Circuitry (not shown), in the form of a circuit board, for example, functioning as a central processing unit (CPU) for the unit 500. This circuit board is advantageously also C:\NRPob\DCCEXI\622207_1 DOC-19/09/2012 - 10 configured to generate sound effects associated with the use of the unit 500. - Software associated with the circuit board for operating the unit 500. Advantageously, the software can be configured to determine and establish settings associated with the operation of the unit on boot-up. Preferably, one of the settings 5 includes a selection of whether the unit 500 is operating in outdoor mode (the default operating mode) or indoor mode; in indoor mode, significantly less power may be provided to the infra-red emitter (discussed below) to reduce the range of the infra-red emitter so as to reduce problems associated with infra-red bounce. - Power source, preferably in the form of a re-chargeable battery. The battery is 10 preferably sufficient to operate the unit 500 for at least 24 hours without requiring re charging. The battery may be a 6 cell 7.2 volt rechargeable nickel metal hydride battery (NiMH) battery with a Tamiya connection, for example. - Infrared emitter, such as the TSAL6100, which transmits an infra-red signal in the form of a directed infra-red beam or pulse when the unit 500 is "fired" to trigger hits 15 preferably to at least an 80-metre range in direct sunshine on a sensor (described below) of another player. - Lens assembly, including a 50mm glass lens having a focal length of 100m, for example, although it will be understood the properties of the lens may be varied as desired. The lens assembly focuses the infra-red beam when the unit 500 is fired so as to transmit 20 infra-red light in a relatively narrow beam in a generally forward direction, such that players are able to obtain hits at a range of up to about 100 metres and players have to aim to achieve hits. The lens assembly may be about 30mm longer than the focal length and about 4mm wider than the diameter of the lens, for example, although again it will be understood that the dimensions of the lens assembly may be varied as required. 25 - Muzzle LEDs (not shown), preferably at least one blue, one white and one red, for example, located on a forward external part of the unit 500, preferably surrounding the infrared emitter. One of the LEDs will flash, under the control of the SATR unit software, each time the unit 500 is fired, preferably as determined by a firmware setting. The muzzle flash may also be deactivated for simulating weapons having flash suppressors. The 30 different colours may be used to indicate players on opposed teams, which may be advantageous for identifying players on opposing teams at night, for example.

C-\NRPonbl\DCC\E.T4622207_ .DOC- Iw119/2012 - 11 - Liquid crystal display (LCD), for a player using the unit 500 to view. The LCD may have a black background and green text and be able to display four lines each having 16 characters, for example. A panel holding the LCD may be about 40mm wide x 8mm depth x 32mm height, for example, although it will again be understood that these 5 dimensions may be varied as required. The LCD may be used to display information including real-time hit feedback for indicating to a first player if another player has been hit and/or or the hit another player's device switches to an inactive state in response to the first player firing action their device. The LCD may also be arranged to display details of operating characteristics of one or more firearms the device may be arranged to simulate 10 such as ammunition in current magazine, number of ammunition reloads available, type of weapon simulated, current weapon status (Firing, Reloading, Ready) and fire mode. Also may be shown is the current health measured in hit points. The number of hits made, kills made, accuracy percentage and number of times "re-spawned" during a game may also be displayed on the LCD in real time. The estimated expected effective range that the unit 15 will make hits may be displayed. The LCD may also display, during a live simulation, details of which simulation (of a number of concurrent simulations, each corresponding to a separate RF channel) the unit 500 is assigned to, and where applicable, which team the unit 500 is assigned to. At the end of the simulation, the LCD may display key performance statistics for the individual associated with the unit 500, including Kill to 20 Death ratio and Assist to Wound ratio. - One or more sensors associates with a target receiver on the player form sensing hits (transmitted infra-red beams or pulses) from other units 500. Each sensor includes an infra-red receiving circuit and preferably two coloured LEDs, such as red and blue LEDs, for example. The LEDs may be activated to indicate to other players when a sensor has 25 been hit or when the unit 500, and therefore player, is in a dead or inactive state. The sensors may be housed in hard plastic domes, for example, and preferably include a filtering system to minimise the impact of sunlight on the performance of the sensors. The difference in ranges between a sensor in direct sunlight compared to a sensor in darkness is preferably less than about 20%. 30 In one preferred arrangement, a sensor is mounted on an upper, generally forward part of the unit 500. Alternatively, and/or additionally, one or more sensors in the form of C:\NRPonb\DCC\EX-T622207_1 DOC-19/09/2(112 - 12 front and rear head sensors that may be mounted to a hat, headband or other apparel (such as a body harness) of the player may be associated with the target receiver. A short electrical wire may be used to couple the front and rear sensors and a longer heavy duty cable may be used to couple preferably the rear sensor to the circuit board. 5 - Re-load button mounted on the unit 500 and able to be pressed to re-load further ammunition or rounds that can be subsequently fired from the unit 500. - On/off switch mounted to the unit 500, by which it may be turned off and on. Actuation of the switch may be controlled by a key lock, for example. - On/off LED mounted on the unit 500, preferably near the switch, for indicating 10 whether the unit 500 is on. - Two position slide for controlling the fire mode; one position for fully automatic (FA) fire mode and the other position for semi-automatic (SA) fire mode. It will be understood the slide may have more than two positions and could be used to indicate other fire modes, for example. Moreover, the fire mode may be further limited by the selected 15 firearm being simulated or emulated by the unit 500. Alternatively, a single button could be used to toggle fire mode. - Charging port by which the rechargeable battery is able to be recharged while still inside the case. unit 500unit 500unit 500 - Red-dot sight, such as a 30mm red-dot sight, or a telescopic 20 scope, for example, mounted to the unit 500. The sight or scope (not shown) may be zeroed during manufacture of the unit 500 and, in the instance of a 30mm red-dot sight, wired so that it is powered by the main re-chargeable battery and turns off when the unit 500 is turned off. In the case of powered sights/scopes, such as red dots and particular powered telescopic scopes, the red light will flash each time the unit makes a hit or kill on 25 another unit. This is an additional way of providing hit feedback to the firer (the other way being a sound effect), especially when the sound hit feedback system has been disabled by the user (for the purposes of stealth). - Waterproof speaker for making or playing sound effects associated with the operation of the unit 500. The speaker unit 500is advantageously used to play sounds 30 in response to the operation of the unit 500. For example, the speaker may be used to play a commentary on the weapons the unit 500 is arranged to emulate, such as a commentary C NRPortbiDCC\EXT4622207_J DOC-19A9/2012 - 13 detailing characteristics of each weapon and its history. Further, the speaker may be used to play sound effects corresponding to the simulated reloading of the weapon, the firing of the weapon and/or changes to the fire mode. Advantageously, the speaker may also be used, when there is appropriate hit-feedback signal from another player's unit 500, to play 5 a sound effect corresponding to the hit on the another unit 500, which preferably will be different for a hit that kills the another unit 500 (i.e. sends the another unit 500 into a dead or inactive state) and a hit that does not. Advantageously, the player may selectively turn audible feedback associated with the hit feedback-signal on and off during boot-up of the unit 500. 10 - Radio module (not shown) that attaches to, or is integrated into, the main circuit board to provide radio receiving and transmitting capability so that the unit 500 can receive and process radio feedback signals from other SATR units, or control signals from central radio control systems (discussed below), or from any SATR unit configured to function as a master controller (discussed below) on boot of the unit 500, for example. 15 Advantageously the radio module is arranged to receive radio signals from up to up to at least 80 metres away, for example. Further, advantageously the preferably digital, radio module is selectively operable on several different channels, whereby different firearm-like devices may effectively listen on different channels so as to facilitate the operation of two or more separate live simulations in relatively close proximity to one another, such as on 20 adjacent or adjoining "battlefields" in an outdoor environment, for example. In practice one channel may be used, but using a digital code, individual battles can be separated. Also note that each infra-red signal when a SATR unit is firing will also include a code that isolates this SATR unit to a single battle and therefore will not trigger hits on SATR units assigned to another battle. 25 The hit-feedback signals advantageously may provide real-time hit-feedback to a first player's unit 500 of a hit on another player by the first player. The real-time hit feedback may be in the form of a display on the first player's LCD and an audible sound effect played on the speaker of the first player's unit in response to a hit-feedback signal, for example. 30 In practice, the control signals may be used by a referee, or other supervisor, supervising a live combat simulation to efficiently and remotely control a live combat C \NRPonblDCC\EXT\46222I7_ I.DOC-19/A9/21I 2 - 14 simulation game, and more particularly units 500 being used in the simulation, without the need to manually key each device off and on each time to reset settings of the units 500. - Radio antenna (not shown) associated with the radio module, which comprises a wire in the sensor cable, such that the antenna is effectively externally mounted to the case. 5 Advantageously, the antenna or aerial is an omnidirectional antenna or aerial whereby the radio signal is omnidirectional (or at least multidirectional), so that the device need not be aimed at another device to transmit the radio signal to it. 10 AAR modules 240 The modules 240 of computer system 115 include at least the following: " a configuration module for configuring parameters of the simulation, including terminology and difficulty level, for assigning Trainees/Gamers to teams, and for 15 configuring parameters of SATR units 500 operated by the Trainees/Gamers; * a statistics module for processing data received from SATR units 500 and storing it in database 160, and for generating summaries of the data; * a manual input module for receiving data related to the simulation and entered by a Trainer or other person interacting with computer system 115; and 20 e a reporter module for generating reports for participants to review after the simulation. In presently preferred embodiments, the modules 240 are implemented in Object Pascal, and may interact with or include components of Delphi of Embarcadero Technologies, Inc. 25 However, it will be understood that the modules 240 may be implemented in any number of other ways using any one of a number of known programming languages and libraries. Scoreboard 170 30 The scoreboard 170 is a large display screen, used to display in real time (or close to real time) the performance of teams and/or individual participants in the simulation.

C:\NRPonbl\DCC\EXT46222071 DOC-19/09/2012 - 15 Scoreboard 170 is preferably coupled to a computer system, which is preferably (but which need not be) a standard computer system (the scoreboard system) similar to computer system 115. The scoreboard system need not include the AAR modules 240, but preferably 5 includes one or more scoreboard control modules which allow the scoreboard system to connect to, and retrieve data from, database 160, to use the data to prepare information relating to the simulation, and to display the information on scoreboard 170. The scoreboard control modules may allow user configuration to restrict the displayed 10 information as follows: " Objectives Only (for totally oriented missions without statistics) " Team Statistics Only (objectives not included just show all the team summary stats) e Objectives (page 1) and Team Statistics (page 2), automatically switch pages on display every 30 seconds. 15 e Battle Log only (shows the most recent incidents first) " Team statistics (page 1) and Battle Log (page 2), automatically switch between the pages every 30 seconds. " Objectives/team statistics/battle log. 20 If the scoreboard system is configured for "Objectives Only", the following information may be displayed on scoreboard 170: " Mission Name " Date and Time (Last refresh) * Team Names (split screen) 25 * Total Score " Objective Score . Kill Score (victory points for making kills on enemy gamers) . Survival Score (victory points for having gamers alive or respawns unused) * For each objective: 30 o Objective Title o Victory Points for achievement CANRPortbIDCC\EXTN4622207 I DOC- I 9/)9/2012 -16 o Tick or other "success" indicator before objective description if achieved If the scoreboard system is configured to show team statistics, the particular statistics to be 5 shown can be selected. By default all the following will be displayed: * Total Score (Victory Points, VP) * Objective Score (VP for achieving objectives) * Kill Score (VP for making kills on enemy gamers) e Survival Score (VP for having gamers alive or respawns unused) 10 e Kills * Kill Assists * Wounds (hits on this gamer that did not cause a kill) * Deaths * K/D Ratio 15 e A/W Ratio * Accuracy% * Shots Fired e Top Weapons - list of emulations in use with total kills with most kills first (normally 3 weapons). 20 . First Blood -Alias of the gamer that made the first kill in the last or current game * Final Kill -Alias of the gamer that made the last kill. * Most Kills - The alias of the gamer with the most number of kills e Most Shots - The alias of the gamer that fired the most shots. * Most accurate - the alias of the Trainee with the highest accuracy percentage, must 25 have fired at least 1 shot to qualify. If battle log data are captured in database 160 (in a manner described below), these can be displayed on the scoreboard 170. For example, a single page containing the most recent incidents can be displayed on scoreboard 170, in the format shown in Figure 4. In Figure 4, 30 a scoreboard display 400 includes the following columns: C.\NRPortb\DCCEX-R4622207_l DOC-19/09/2012 -17 WHEN represents the time when the incident occurred; WHO is the shooter; FROM is the alias name of the shooter's team; 5 EFFECT is what happened; TARGET is the alias name of the participant affected; TARGET TEAM is the name of the team of the participant affected; SURVIVORS is how many participants are still alive, followed by the total number of participants assigned to that team. 10 Master controller 180 Master controller 180 is a device, configured similarly to units 500, which communicates with units 500 by infrared or RF signals. Typically, RF commands are issued when it is 15 desired to configure multiple units 500 at the same time, while infrared commands are issued for controlling a single unit 500. Master controller 180 includes one or more control modules which configure signals to be transmitted by an IR or RF emitter of master controller 180 to units 500 which cause them to do one or more of the following: . Infrared commands (issued by direct line of fire, i.e. target a single unit): 20 o Re-spawn o Re-load ammunition o Pause o Resume o Kill 25 o New Mission o Change battle (i.e., change simulation that unit is assigned to) o Test IR sensor (also issues a command to test the RF transmitter of unit 500) o Allocate unit to a particular team 30 o Set a "Gun Timer" so this unit will operate for a specified period of time before entering a "game over" state C:\NRPonbl\DCCEX\4622207_I DOC.19/09/2012 - 18 o Shoot (deducts 1 hit point from unit 500) * Radio commands (issued as an omnidirectional signal, i.e. affects all units 500 forming part of the simulation): o Pause 5 o Resume o End mission (disables all units 500 in the simulation) o Start mission (enables all units 500 in the simulation) o Simulation timer (tells all units 500 indicating how much time is left in the simulation) 10 PROCESS OVERVIEW An exemplary live combat simulation monitoring process will now be described. 15 With reference to Figure 5, a live combat simulation process 700 begins with a configuration step 800, in which parameters of the simulation are defined and individual firearm units 500 are configured, in a manner which will later be described. The process 700 then enters the simulation phase 710. Depending on the type of simulation being conducted, the simulation phase 710 may end at a predetermined time, or when a 20 predetermined event occurs. The process 700 then enters an "After-action review" phase 720. Configuration step 800 25 At configuration step 800, illustrated in more detail in Figure 8, the configuration module of computer system 115 loads default parameters from database 160 (step 810). The default parameters may be selected from one of a number of predefined sets of parameters. The configuration module may provide for user selection of a simulation type, which will then determine which predefined set of parameters is used. Typically, the majority of the 30 parameters will relate to configuration parameters for the SATR units 500, such as the type of weapon to be emulated by, and the number of hit points of, units 500. The parameters C:NRPonbl\DCC\EX"4622207- IDOC-19/09/20)2 -19 may also include type of terminology used in the simulation (such as standard military terms, or terms typically used by gamers), the type of graphical theme used for displaying results of the simulation on display 220 or scoreboard 170, or what information is to be included in reports generated by the reporter module, for example. 5 At step 812, the configuration module accepts user input as to any changes which are desired to the default parameters loaded from database 160. Step 812 may also include assigning Trainees to one of two or more teams taking part in the simulation, by associating Trainee IDs with team IDs in database 160. More complicated assignment of Trainees is also possible. For example, in a military style simulation, the teams may have a 10 hierarchical structure, such that teams are divided into "units" each of which are assigned a leader together with several other Trainees. This allows performance to be monitored for the team as a whole, for individual units (and also for the respective leaders of those units), and for individual Trainees within units. Further levels in the hierarchy may also be implemented as desired (for example battalion - company - platoon - section/squad 15 fireteam - individual). Different sets of parameters may be applied to different Trainees, individually and/or on the basis of the unit or team to which they are assigned, at step 812. For example, a subset of parameters can be set at a "unit" level in configuration step 812, such that each Trainee 20 in a unit is assigned the same values for that subset of parameters. At step 814, the configuration module generates, on the basis of the configuration parameters retrieved from database 160 (and incorporating any modifications at step 812), a configuration packet to be transmitted from the interface module 300 to a unit 500 by the 25 IR emitter 340 of the interface module 300. In one embodiment, the configuration packet has a structure including the fields shown in Table 1. In Table 1, in cases where a zero value is assigned to a field, no change will be made to the corresponding parameter when the configuration packet is received by a SATR unit 500. 30 C:\NRPotbhDCC\EX~n4622207_I DOC.19/09/2012 - 20 Table I FIELD NOTES SATRUNITUD This is the ID associated with a unit 500. The configuration module checks which IDs are already assigned in database 160 and generates a unique ID. The number range will be 0 to 1023 (i.e., this is a 10 bit field) ALIAS Up to 8 characters, for example a short version of the Trainee's name or nickname. HITPOINTS 100 = Invulnerable 0 =No change DIFFICULTYCODE Values from 0 to 2 (2 bits) where 00 (Null) - no change, 0 1 is easy, 10 is standard and I I is hard. If hit points loaded is 0 being no change, then the difficulty level will determine the hit point value. Hard being 3 hit points while standard and easy will be 5 hit points GUNCLASSCODE 3 bit value 000 No Change 001 HandGun 010 Submachinegun 011 Rifle 100 Machinegun WEAPONEMULATIONCODE 7 Bit code for the weapon emulations, 0000000 no change LANGUAGECODE 00000 NO CHANGE 00001 English, British 00010 English, US, Male 000 11 Laser Tag 00100 Vietnamese 00101 Spanish 00111 Russian 01000 Portuguese 01001 Japanese 01010 Italian 01011 French 0 1100 German 01101 Mandarin 01110 Arabic 01111 Custom 10000 English, US, Female C\NRPonbl\DCC\EXT\46222"7_ I DOC. Iw'Aw2012 -21 FIELD NOTES DEVICEROLECODE 0000 No Change 000 1 Master Controller 0010 Medic Box 0011 Ammunition Box 0100 Dirty Mine 0101 Normal Mine 0110 Claymore Mine 0111 Radio Repeater 1000 Combination Box 1001 Weapon FIREMODECODE 00 No Change 01 Shooting 10 Killing BLANKSCODE 00 - No Change 0 1 -Disabled 01- Enabled STOPPAGESCODE 00 - No Change 0 1 - Stoppages OFF 10- Stoppages ON DAMAGECODE 00 - NO CHANGE 01 - Damage Disabled 10 - Damage Enabled MUZZLEFLASHCODE 000 No Change 001 White (Default) 010 Red 011 Blue 100 No Muzzle Flash TEAMCODE 000 X (FRIENDLY FIRE ON) 001 A 010 B 01l C 100 D 101 E HOF III G HITLIGHT_CODE 00 - No Change 01 - Red Hit Light (Default Civilian) 10 - Blue Hit Light II - No Hit Light (Default Military) For the head sensor light RANGECODE 000 NO CHANGE 001- Default 010 - Short 0 11 - Medium 100 - Long Range ignored if indoor mode enabled. VOICEFEEDBACKCODE 00 NO CHANGE 01 - Voice Feedback ON (Default Civilian) 10 - Voice Feedback OFF (Default military) C-\NRPortbNDCC\EX'14622207_ I DOC. 9Aw9w2012 -22 FIELD NOTES VOLUMECODE 00 - NO CHANGE 01 High Volume (Default) 10 - Medium 1l -Low BATTLE_CODE Battle or Game Number for IR and RF isolation purposes 000 No Change 001 Battle I 010 Battle 2 0 11 Battle 3 100 Battle 4. HIREMODECODE 00 No Change 01 - Hire Mode DISABLED 10 - Hire Mode ENABLED ENABLESTATSCODE For the military version it may be desired to disable statistics and voice feedback as well. So if Enable Stats is OFF then on the LCD of unit 500 the Kill Assists, Kills, Accuracy and Respawns will not appear on the display. A value of OFF also disables Phase Stats (Game Stats) and Exercise stats (Session Stats) and Phase Log (so no hit who data will appear on the LCD after the game). The value of this field does not affect the collection and upload of statistics to interface module 300. 00 - No Change 01 - Enable Stats 10- Disable Stats INDOOROUTDOORCODE 00 No Change 01 Outdoor 10 Indoor MANUAL_DOWNLOADONLY If FALSE, downloads will occur every 30 seconds or so (at DOWNLOADREFRESHRATE) and continue automatically after the battle ends for the period specified by DOWNLOADPERIODAFTERPHASE (default 10 minutes). If TRUE, no automatic downloads occur. However the Master Controller 180 can trigger by JR a request to download to the SATR units 500 and they will then queue their downloads. 00 - No Change 01 - False, do automatically download 10 - True, only manual download DOWNLOADPERIODAFTERPHASE Time in minutes after a game has ended, that the system should continue to download data from the SATR devices 400 to the Laptop 115. This is a 5 bit field representing a value in minutes from 0 to 31 minutes C:\NRPorbl\DCC\EX~I4622207_1 DOC-19/0912W2 - 23 FIELD NOTES DOWNLOADREFRESH_RATE Frequency in seconds of the refresh of data during and immediately after a live game or exercise. Allowable intervals are: 000 - No Change 001 - Every 10 Seconds 010 - Every 30 Seconds 0 11 - Every 60 Seconds 100 - Every 120 Seconds 10 1 - Every 300 Seconds I 1I - Every 600 Seconds TIMESYNC The current time with a maximum value of 24 hours in minutes. 7 bits. 000000 No Change 000001 Midnight plus I Minute 000002 Midnight plus 2 Minutes... On the LCD Phase Log of unit 500 and user interface shown on display 220 it will be displayed in HH:MM 24 hour time format. LCDBATTLELOGENABLED Known as Phase Log when military version is in use. This enables on the SATR target unit 500 the collection and possibly display of who and when information on the LCD post game/phase 00 - No Change 01 -Enabled 10 - Disabled DOWNLOAD_BATTLELOG If enabled the SATR unit 500 will need to store who hit this unit for upload to the Laptop 115 by RF. 00 No Change 01 Enabled 10 Disabled (Default) Only needs to store on the SATR unit 500 who this unit hit if LCD BATTLE LOG ENABLED. DAMAGE The amount of hit points deducted from the target's hits per successful shot. Default is I point of damage. 00 No Change 001 1 Point of damage 010 2 points of damage 0 11 3 points of damage 100 4 points of damage 10 1 5 points of damage 110 6 points of damage I 11 7 points of damage C:\NRPonbl\DCC\EXIM622207_i DOC-19AW2012 - 24 FIELD NOTES MINEOPTIONCODE 000 - No Change 001 - "Shoot to fire" 010 - "Shoot to disable" 0 11 -"Always live" 100 - "One fire only" - Default military 101 "2.5 min reload" -Default Civilian Preferably, an error detection code is added to the configuration packet. This can be done by the configuration module prior to forwarding the configuration packet to the interface module 300. Alternatively, the interface device 300 may add an error detection code after it 5 receives (step 822) the configuration packet. At the start of step 800, interface module 300 is in listening mode 820. When it receives a configuration packet from laptop 115, at step 822, it transmits the configuration packet for receipt at a SATR unit 500 (step 824). The SATR unit 500, which starts in listening mode 10 830, receives the packet at step 832, and then checks (step 834) whether it is valid by analysing the error detection code incorporated into the configuration packet. If the packet is valid, head sensors of the unit 500 flash to indicate it has received the packet in an error free state. Preferably, the RF transmitter of unit 500 also sends a signal to the interface module 360 to confirm error free receipt to system 115. The unit 500 then processes the 15 configuration packet (step 836) to determine which configuration parameters should be updated (step 838). It will also be appreciated that alternative methods of configuring the units 500 are possible. For example, if the interface module 300 is equipped with an RF transmitter, the 20 information in the configuration packet may be used to generate an RF packet for broadcast to all units 500 in range, to thereby configure those units prior to the simulation. Simulation phase 710 25 Once configuration 800 is complete, the simulation phase 710 of process 700 commences. Typically, the simulation phase 710 is initiated by master controller 180 issuing, by its RF transmitter, a "Start mission" command to all units 500 assigned to a particular simulation C :\RPonbF\DCC\EX'4622207_1 DOC-19A9/I212 - 25 (channel), such that the units 500 are enabled. During simulation phase 710, SATR units 500 borne by participants (Trainees), configured according to the process described above, can perform various functions, for example 5 substantially as described in PCT publication WO 2008/074802. The functions performed by a unit 500 borne by a Trainee may include taking hits from other units 500 borne by other Trainees (i.e., sensing on sensors 440 signals transmitted by the other units 500), firing shots (i.e., emitting beams or pulses of infra-red radiation), and receiving radio frequency data (as discussed above) relating to hits recorded against other players. The 10 LCD display of a unit 500 may be updated to reflect events occurring during the live combat simulation, with varying degrees of detail included in the displayed information depending on the configuration of the unit 500. The unit 500 records, in a storage means, data relating to the simulated combat events. Some or all of the event data may be uploaded to interface module 300 in a manner which will now be described in more detail. 15 By default, each unit 500 is configured to upload event data (which may be statistical data summarising events since the last upload, or battle log data which comprises more detailed information about each specific event) by RF broadcast, to interface module 300, at predetermined intervals determined by the value of DOWNLOADREFRESH_RATE. 20 Since a large number of units 500 may be involved in any given simulation, it is desirable to avoid flooding the channel(s) employed by RF receiver 350 of interface module 300. Accordingly, the time at which any given unit 500 uploads data may be offset, for example by introducing random "jitter" into the upload time, or by offsetting the upload time by an amount calculated on the basis of the unique ID of the unit 500, for example. As a fallback, 25 unit 500 may include means for detecting whether the upload channel is busy at the time of an attempted upload, and attempting to re-upload a few seconds later, for example. Each unit 500 continues to upload event data at intervals of (or based on) DOWNLOADREFRESH_RATE throughout the simulation, and may continue to do so for up until a predetermined time (DOWNLOADPERIODAFTERPHASE) after the 30 nominated end time of the simulation.

C:WRPonbrDCCEXTN4622207 1 DOC-19/119/21 12 - 26 If storage of battle log data on unit 500 is enabled, data for each event (incident) may be stored, for example according to the format shown in Table 2. Table 2 INCIDENTTIME 000001 Midnight plus I Minute 000002 Midnight plus 2 Minutes... SATRUNITID In the case of a Wound or Death (on this unit) then the SATRUNITID of shooter. In the case of a Hit or Kill on another soldier/player it is the SATR_UN ITID of the target INCIDENTTYPE Wound (a hit on this unit not a death) Death Kill Assist (this unit has hit another one) Kill (this unit has killed another one) Respawned Reloaded (by ammunition box) ALIAS NAME The 8 character Alias of the other SATR unit involved in the incident. 5 Typical statistical (summary) data may include the values listed in Table 3. Table 3 SATR UNIT ID The identifier of the SATR unit downloading data to the Laptop DOWNLOADTYPE 0 means standard download of states (this one) I means a battle log download (Table 3). KILLS The number of kills/deactivations made by this gaming gun 400 during the current phase or if a new phase has not commenced yet the last phase KILL ASSIST Number of hits made that did not cause a kill in current or last phase. DEATHS Number of times this gaming gun 400 died in current or last phase WOUNDS Number of hits received during the last or current game that did not cause this unit 500 to die RESPAWNS Number of respawns taken in last or current game. SHOTS FIRED Number of shots fired in the last or current game. CURRENT HP The current hit points of the SATR unit 500. CURRENT RELOADS The number of spare magazines available ACCURACY The percentage of shots fired that caused a kill or kill assist. If DOWNLOAD_BATTLE_LOG is enabled, then the unit 500 may also, at times determined by DOWNLOADREFRESH_RATE (offset as above, if desired), upload 10 battle log data to interface module 300. Battle log data uploaded to interface module 300 CNRPorblDCC\EXT4622207_ I DOC-19l9/2012 -27 may include the values listed in Table 4. Table 4 SATRUNITID The identifier of the SATR unit 500 downloading data to the Laptop 115 DOWNLOAD_TYPE 0 means standard download of states (Table 2) I means a battle log download (this one) LASTPACKET 0 Not the last packet, more battle log to download I Last Packet from this SATR unit 500. INCIDENTTIME Time of incident in hours, minutes, seconds. SHOOTERSATRUNITID Gun ID of the shooter that hit this SATR unit 500 (NULL if respawn or reload incident) INCIDENTTYPE 00 -Wound (hit by someone shooting at this unit that did not cause death) 01 - Death 10 - Respawn I I - Reload (meaning reloaded all spent magazines by the battle box) SHOTNUMBER From the start of the phase each shot is counted, which shot number caused the incident is uploaded in the battle log. NULL if respawns If respawns log injury code if damage enabled in SATR. WHERESHOTGENERAL Values can be 000 Null 001 Head 010 Left Leg 011 Right Leg 100 Left Arm 101 Right Arm I I I Torso SPECIFIC SHOT LOCATION Within each region such as head, this is a one digit code showing exactly where. Allowable range is 0 to 9 so we will need 4 bits for this. SEVERITY 00 - Serious 01 - Shock 10 - Superficial Software associated with the circuit board of unit 500 may provide for displaying battle log 5 data on the LCD of unit 500, if unit 500 is configured to enable this by means of the LCDBATTLELOGENABLED setting. Battle log data may be displayed during or after C:\NRPonbDCC\EXn4622207_I DOC-10909/212 - 28 the simulation. An example of battle log data displayed on the LCD is as follows: 00:30 A DAVE 01:30A PLAN 5 02:45 K PLAN 03:00 W DAVE 12:15 D PLAN 12:30 A GJN95 12:32 D MINE183 10 As will be appreciated from the above, each line of battle log data displayed on the LCD represents a single event or incident during the simulation. The software of unit 500 may provide for a Trainee to scroll through the displayed battle log data, for example using buttons located on the casing 422. 15 The display format can be summarised as "HH:MM x ALIAS", where x is the incident type: A: Hit on another unit that did not cause it to die - Kill Assist 20 K: Killed another unit with this shot W: Wounded from another hit (received a hit, but did not kill this SATR unit) D: Death (this unit was killed by another SATR unit) ALIAS is the alias name of the owner of the other unit associated with the incident. 25 Uploaded statistical data or battle log data are received by interface module 300 and processed in a data capture process 900 shown schematically in Figure 9. Interface module 300 continually listens for RF packets (step 910). If a packet is received (step 920), the process 900 checks whether the packet is a statistics packet or a battle log packet (step 930). If the packet satisfies neither of these criteria, the interface module returns to 30 listening mode at 910. If the packet meets either criterion, it is forwarded to laptop 115 via USB interface 335 and the interface module 300 returns to listening mode.

C \NRPortbDCC\EX'462220 LDOC-19/09/2fi12 -29 As shown in Figure 10, laptop 115 is, during the simulation, continually listening for data from interface module 300 (at 1010). When it receives a statistics packet or battle log packet from data capture process 900 (step 1020), the statistics module (of modules 240) 5 processes the packet (step 1030) to determine its content, and updates database 160 accordingly (step 1060). Process 1000 executed by laptop 115 may also, directly after processing packet 1030 or at regular predetermined intervals, refresh the display of laptop 115 to show updated statistical or battle log data. For example, the process 1000 may refresh the display at 30-second or 1 minute intervals with summarised data (calculated by 10 the statistics module) regarding performance of individuals and teams partaking in the simulation, updated to take into account new information received since the last refresh. The display may also refresh to show newly received battle log data, thereby showing details of individual incidents in real time (or close to real time), for example in a scrolling display. 15 If a scoreboard 170 is used as part of the system 100, then the summarised data and/or the battle log data may also be displayed on scoreboard 170. The scoreboard 170 may merely mirror the information shown on the display of computer system 115, or may display a subset or superset of that information. The manner in which information is displayed on 20 scoreboard 170 may be configured, for example using one or more software modules 240 executed by computer system 115 or by a separate computer system coupled to scoreboard 170, the separate computer system being in communication with computer system 115 and/or with database 160 in order to retrieve the information to be displayed. 25 The summarised data may include at least the following, for a Trainee and/or team: * Total kills / deactivations / casualties * Total hits made " Total shots fired 30 e Total deaths / deactivations / wounds suffered by the Trainee * Total hits received C \NRPortblDCC\EXT06222107_ LDOC-19A9/2012 - 30 * Total damage received * Accuracy percentage [(Total Kills + Total Hits Made)* 100/(Total Shots Fired)] * KID (Kills to Deaths) ratio e A/W (Assist to Wound) ratio, i.e. hits made to hits received ratio. 5 In addition to receiving and processing data from interface module 300, the process 1000 may also cause computer system 115 to display a user interface (step 1040) which provides one or more menus to allow a user to enter, into database 160, information relating to the simulation (step 1050). For example, in a civilian or game-type simulation the user may 10 enter information relating to objective achievements (if any objectives are set during configuration step 812), or to enter who has won the match. In a military-type simulation, facility may be provided for the entry of additional data, including detailed exercise notes such as summary of recent events (what happened), 15 discussion of key issues (why it happened and how to improve), sustain points, improve and fix points, discussion of force protection issues and closing comments. In addition, the user interface may allow input of video and photo data into the exercise database 160, optionally associated with date/time stamp and location. The video and photo data are preferably "tagged" or associated with a particular unit and/or soldier, typically by manual 20 data entry. Some of the additional data may be entered prior to the simulation, or between simulations in a sequence of simulations (e.g. a linked set of simulations which form an "exercise" in the military sense). For example, the additional data for a given simulation (battle) may 25 include "Commander's mission and intent', "OPFOR Commander's mission and intent", Notes and Maps. The system 115 may generate, on the basis of the additional data, training aids and information for any participants who are to take on the role of official "Observer and Controller" (O/C). 30 C \NRPonbl\DCC\EXTh462221U7 .DOC- lw9A)/20 12 -31 After-action review phase 720 As will be apparent from the above discussion, the system 100 provides for continuous monitoring, on a real time or close to real time basis, the performance of participants and 5 teams of participants in a live combat simulation. Advantageously, the performance can also be summarised at various levels in a process referred to as "after-action review". In one example, a reporter module (of modules 240) generates, from data in database 160, one or more reports. The type of report to be generated, and the type of information 10 contained therein, may be user-selectable. The reporter module may generate reports in various formats, preferably HTML and/or PDF, and may print reports to a printer (not shown) connected to computer system 115. Typical examples of information included in reports generatable by the reporter module are shown in Table 5. The particular examples shown relate to a military-type simulation. However, it will be appreciated that the content 15 and formatting of the reports can be readily modified to suit other types of simulation. Table 5 Report Name Criteria Contents Soldier Statistics All soldiers in a unit in HEADING Alias order OR [Exercise/s]/[Phase/'s] an individual Soldier Start/end datetime Filtered further by: DETAIL All Exercises OR Order by Alias/Last Name/First Name An Exercise OR Soldier ID A Phase OR Last Name+ ' ' + Middle Name ' '+ First Name Datetime Range Rank K/D Each soldier/gamer will A/W start a new page (page Accuracy Percentage break) Kills Wounds Deaths Hit Points (Current) Current Reloads (spare magazines) Shots Fired Fratricides C:\NRPorb1\DCC'EX'l46222I07.DOC-19/09/12(112 - 32 Report Name Criteria Contents Soldier Phase Log Same as Soldier HEADING Statistics criteria. [Exercise/s]/[Phase/s] Start/end datetime Order by Alias/Last Name/First Name SUB HEADING BAND Soldier ID Last Name+' ' + Middle Name ' '+ First Name DETAIL BAND HH:MM:SS x Last Name Last Name+' + Middle Name ' '+ First Name Shot Number OR HH:MM:SS Treated Inj ury code (ai per SA'T R display i f damage enabled) OR HH:MM:SS Reloaded Where x is the incident type: A: Hit on another soldier/gamer that did not cause it to die K: Killed an enemy soldier/gamer W: Wounded, hit by another hit without dying D: Died (this soldier was killed in action) Soldier Combined Same as Soldier Combine output of Soldier Statistics and Soldier Statistics criteria. Exercise Log. The statistics for a particular soldier are shown first and then the exercise log followed by the next soldier.

C.\NRPorbl\DlCCMXTA6222o7_ I DOC. 19/)9/21)12 - 33 Report Name Criteria Contents Soldier Review Select a soldier by HEADING searching by name or list [Exercise/s]/[Exercise Phase/s] of names from a unit. Start/end datetime This report only show Soldier ID review information about Last Name+ ' ' + Middle Name ' '+ First Name an individual soldier but could be over multiple SUSTAIN POINTS DETAIL (Heading in Green) exercises. SUB DETAIL - EXERCISE Exercise Name Filtered further by: Exercise start datetime All Exercises OR Exercise end datetime Training Exercise OR Training Stage OR SUB SUB DETAIL - EXERCISE STAGE Date Range Exercise Stage Name Exercise Stage start datetime EACH Exercise Stage end datetime GAMER/SOLDIER GETS A NEW PAGE. SUB SUB SUB DETAIL Sustain Point IMPROVE POINTS DETAIL (Heading in amber) SUB DETAIL - EXERCISE Exercise Name Exercise start datetime Exercise end datetime SUB SUB DETAIL - EXERCISE STAGE Exercise Stage Name Exercise Stage start datetime Exercise Stage end datetime SUB SUB SUB DETAIL Improve Point FIX POINTS DETAIL (Heading in Red) SUB DETAIL- EXERCISE Exercise Name Exercise start datetime Exercise end datetime SUB SUB DETAIL - EXERCISE STAGE Exercise Stage Name Exercise Stage start datetime Exercise Stage end datetime SUB SUB SUB DETAIL FIX POINT Point C:NRPoinb\DCCEX-\462221J7_1 DOC-19A19/2012 -34 Report Name Criteria Contents Force Statistics Select first the exercise, Force Name then the phase and the a Exercise Stage Name particular force (team) Exercise Stage Start datetime Exercise Stage End datetime K/D A/W Accuracy Kills Kill Assists Wounds Deaths Shots Fired Fratricides Force Review Same as Force statistics FORCE REVIEW HEADING Force Name Exercise Stage Name Exercise Stage Start datetime Exercise Stage End datetime SUSTAIN POINTS DETAIL (Heading in Green) Sustain Point IMPROVE POINTS DETAIL (Heading in amber) Improve Point FIX POINTS DETAIL (Heading in Red) Fix Point Units Statistics Select a unit from list of Unit Name units should be able to Start datetime work through unit End datetime hierarchy from senior to junior. K/D A/W Filter by start to end date Accuracy range. Kills Kill Assists Deaths Wounds Shots Fired Fratricides Unit Exercise Log Same as Unit statistics C-\NRPortbhDCC\IXl4622207_1.DOC-19/)9/20)12 - 35 Report Name Criteria Contents Leaders Review Select Exercise then HEADING Phase, then force, then Force Name unit assignment to find Exercise Stage Name the leader for that unit Leaders Name and Rank for the specified Exercise Stage Start datetime exercise. Exercise Stage End datetime SUSTAIN POINTS DETAIL (Heading in Green) Sustain Point IMPROVE POINTS DETAIL (Heading in amber) Improve Point FIX POINTS DETAIL (Heading in Red) Fix Point Embodiments of the system and method described herein therefore advantageously provide a training aid that permits the capture, entry, storage and reporting on data associated with a simulated combat. The detailed analysis enabled by the system and method permits those 5 involved with training of military personnel to readily identify strengths and weaknesses of individuals in a manner not previously possible. The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or 10 admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

Claims (8)

1. A method of monitoring performance in a live combat simulation, including the steps of: 5 generating, on respective simulated firearm units associated with respective participants in the live combat simulation, event data relating to combat events in which the participants are involved during the simulation; and transferring, by communication means of the respective simulated firearm units, the event data to a data capture module. 10

2. A method according to claim 1, including processing the event data, on a computer system associated with the data capture module, to generate a summary of the live combat simulation. 15

3. A method according to claim I or claim 2, including transferring the event data at regular intervals during the simulation.

4. A live combat simulation performance monitoring system, including: a plurality of simulated firearm units, respective simulated firearm units being 20 associated with respective participants in the live combat simulation and being configured to generate event data relating to combat events in which the participants are involved during the simulation; and a data capture module for receiving, from the respective units, the event data. 25

5. A system according to claim 4, including a computer system communicatively coupled to the data capture module.

6. A system according to claim 5, wherein the computer system includes a reporter module for processing the event data to generate a summary of the live combat 30 simulation. C:\NRPonbl\DCC\EX'I622207_1.DOC-19/09/2012 - 37

7. An apparatus for monitoring performance in a live combat simulation, including: a data capture module for receiving, from respective simulated firearm units associated with respective participants in the live combat simulation, event data relating to combat events in which the participants are involved during the simulation. 5

8. An apparatus according to claim 7, including means for transferring the event data to a reporter module, the reporter module being configured to generate a summary of the live combat simulation.