|
|
In the Polish troops example the critical mistake they made was to use an "area weapon" to attack EC in a civilian environment - something they were most likely prohibited from doing. Had they followed the EC into the village and engaged them with their rifles/machine guns they would not have violated any rules. However, international law states that you need to take into consideration the value of the military unit vs. the potential for civilian casualties in the selection of the weapon to use. The mortar is not a very accurate weapon - it is very useful against concentrations of purely enemy forces, but if used in a civilian environment it will almost certainly cause more civilian casualties than enemy casualties. Thus, the Polish troops were guilty of using indiscriminate force in their attempts to make the enemy forces "pay" for killing their comrades.
If an AxS (Autonomous System) was available for use in this situation we would want to ensure it would not make the decision to use indiscriminate force (i.e. a mortar) - and we would most probably not want it to use the mortar even if fired upon (unless they had a very accurate location of the EC and the AxS was very accurate with the mortar). Thus, we would want the AxS NOT to fire into the civilian environment with the mortar based on the local commander's desires - we would want the AxS to refuse to use that weapon unless it was given permission from a higher authority.
This is a demonstration of an executable policy described with the KEEL Dynamic Graphical Language and implemented in Flash ActionScript for demonstration purposes.
The hypothetical High-Level Policy describes how an Autonomous System (AxS) will make an "Engagement Decision" (to engage with an enemy combatant). The high level policy identifies a number of characteristics that must be considered when making that decision:
Lower level policies will describe how the AxS interprets sensor data, weapon characteristics, and other intelligence that will pass through the High Level Policy filter to control the actions of the AxS during the missions.
In this demonstration, the red circle will act as the Enemy Combatant (EC). One can drag and drop the red circle representing the movement of the EC in battle space.
The white rectangular box on right segment of the screen is the field of view of the AxS. When the EC is over a white area of the battle space, it can be engaged if the AxS has the appropriate weapon. An Engage with message is displayed if the appropriate weapon is available that matches the characteristics of the EC in the unprotected environment.
The green rectangular box indicates a vehicle where the EC might take refuge. It takes a more powerful weapon to engage an EC in a vehicle.
A Legend checkbox is provided to get a better understanding of the abstract representations used in this demonstration. The simulation does not run while the images representing the objects are displayed.
An Engage with message is displayed when the AxS matches the EC's environment with the weapons at its disposal.
The black rectangular box indicates an out-of-bounds building. It takes an even more powerful weapon to engage an EC in the OOB facility. When the AxS detects the mouse (EC) is in the OOB facility a Don't Engage message is displayed and a message is sent to the Command Authority (CA) advising the CA that the EC has entered the OOB facility. This is displayed in this demonstration as a checkbox titled Override OOB, where the user can signify overriding the OOB policy by typing an "x" on the keyboard.
If the non-combatant is in the OOB location and it fires from the OOB location, the AxS can engage the enemy combatant without requiring authorization by the Command Authority. You can simulate the EC firing by hitting an "f" key when the mouse is over the OOB location.
The blue blobs indicate non-combatants or entities that are Collateral Risk to an engagement if the EC is within range. The intensity of the blue indicates relative collateral risk. Moving the mouse (EC) over / near a blue blob will signify that engaging the EC in this location will have associated Collateral Risk. This value is shown on the upper left of the demonstration screen.
During normal operation of this demonstration, the blue blobs are moving over the screen. A Pause Collateral / Resume Collateral button in the upper left allows the user to pause and resume their movement for more focused testing.
When the blue blobs (collateral risk) items have been paused on the screen, then can be dragged around for specific situational testing. In the snapshot below, one of the blue blobs has been dragged over the OOB location indicating there is collateral risk for an engagement if the enemy combatant enters the same OOB location. The policy states that one "must" consider collateral risk that cannot be overridden, even by command authority.
The AxS has three weapons available, each with configuration profiles that are assumed in this demonstration to be pre-loaded for the mission. The profiles define the viability of each weapon for a balanced response to an enemy combatant. The 3 check boxes in the upper left corner of the screen signify the availability of those weapons. Unchecking one or all of these checkboxes will force the AxS to consider its options with our without those weapons. The images below show the profiles of the 3 weapons where the bottom of the "V" indicates the optimal target. The green slope up shows the under-powered characteristics and the red slope up show the over-powered characteristics. The shape of these curves is encoded in the KEEL-based policy.
|
|
|
Two sliders are also provided in the demonstration. These sliders: OOB Hardness and Vehicle Hardness allow you to change the AxS's perception of the OOB location and the Vehicle location. By changing these sliders, this simulates the AxS sensors viewing the EC in those locations as requiring different weapon characteristics for engagement. The AxS will either choose a different "balanced" weapon, or decide not to engage because it didn't have the appropriate weapon (per policy). There is no slider to indicate the hardness of the EC in "white space" in this demonstration, but it is part of the policy.
Policies processed by the KEEL cognitive engine interpret "numeric values" of information from sensors or command signals. A status view is provided in this demonstration to show the values changing in real-time. This is the information being processed by the KEEL Engine that was auto-generated from the KEEL "dynamic graphical language" that was used to create the policy.
A configuration control is provided in this demonstration to allow the user (field commander) to adjust the threshold that the AxS uses to determine whether it is ok to engage the Enemy Combatant. The KEEL-based policy accumulates the "target value" of the Enemy Combatant with information that effectively reduces that target value. The accumulation is compared to the threshold when making the engagement decision.
An interactive rendering of the KEEL-based policy driving this demonstration can be viewed by clicking on the image below.
Also:
Video explaining the demonstration is available at:
Another associated demonstration (Language Animation Demonstration) showing how one uses the KEEL "dynamic graphical language" to audit a policy. In this case, this same demonstration is tied diectly to the language allowing you to "see the policy in action" and "trace the Engage decision back to its source". This demonstration can be found at:
Video explaining the Language Animation Demonstration and how one uses Language Animation to audit a KEEL-based policy.