Employing JFORCES to Determine Military Utility Effectiveness Based On Engineering-Level Specifications



JFORCES can reliably roll up engineering-level data to Theater level Measures of Effectiveness because the components of large scenarios are clearly broken down into limited player activities corresponding to the Orient->Look->Communicate->Plan->Decide->Direct->Engage model. Each of these models can be ( and often are ) defined at very detailed levels appropriate to engineering applications. Moreover, the interfaces between these actions is consistent with real world interfaces, permitting JFORCES to use the actual ICDs between military systems, as proven in JFORCES employment as a testbed to receive and process live sensor reports as well as its ability to drive actual operator workstations with data with the same content, format, and rate of presentation as expected in the field.



JFORCES provides a scenario driver that defines the architectural requirements on a current or envisioned system. The scenario is understood to each side only according to its perception. That is apparent enemies and unknowns detected and reported as well as knowledge of previous and ongoing missions. The assessment of the situation generates system requirements. These requirements are mapped to simulated (and, when available, live) assets and systems to determine possible methods to fulfill these requirements. Each of these assets has detailed deployment, employment, performance and subsystem specifications that together define their roles and capabilities . Based upon the completeness, accuracy, reliability and timeliness information actually made available to both the decision maker and the warfighter throughout combat decisions are made and missions are attempted. The success of these actions (and ability to respond to enemy actions) is then determined according to the validity of the mission and the ability of the allocated elements to perform the assigned job. This results in classical warfighting metrics including kills, losses and objectives taken. The results of missions attempted (and possibly achieved) rolls back into the situation understanding for additional assessment and action.




One reason that JFORCES has been successfully used in a wide range of applications is that the approach is built on a fundamentally simple and understandable basis. While applications sometimes require that esoteric descriptions and techniques are used, the system at its core defines scenario components in the proven who, what, where, when and how specifications and evaluates them in the context of a military operation.


The engineering-level data that defines specific elements, in this case a communications subsystem, define the who, what and how of specific communications. The scenario, by providing a context, provides information on why the message is being sent, who to, and why.



The kill chain mechanism then evaluates the effect of the receipt, or failure, of the communication to destroy an enemy. It does this continually throughout the scenario execution, thereby altering outcome based upon the time the information is received as well as realistically “aging” the report; that is reporting the data that was available at the time the report was generated instead of data available at the time of reception. The success of chosen operations, including enemy engagement and (if appropriate to the ROE) destruction are then discretely modeled according to platform capabilities and the ability to operate on available information.




The decisions of appropriate actions relies on the information available to the commander. In this diagram the JFORCES sensor module is highlighted as the primary source of enemy information. But Only information that has been passed through the communications module is actually made available to the commander, and then only after appropriate transmission and processing delays.




As with the communications module, the sensor module relies on engineering-level specifications. Here the performance-related information for the typical JFORCES sensors is shown. This is augmented by other supporting information, for example the specifications for marshaling appropriate data in real-world formats.




JFORCES pulls all of these simple approaches into an architecture that, while piece-wise simple and understandable, is complex because of the extent of representation. Three common implementation threads in this architecture keep the system from being overwhelming. These are: