Command and Control Demo

Command and Control Demo Click here to open the demonstration in a new window


The Command and Control Demonstration shows the use of three separate KEEL engines in a command and control (C2) application. While the three separate KEEL engines are integrated into a single application, they could be integrated into separate applications that communicate among themselves over a network (wired or wireless). The transport of information between KEEL engines in any application is independent of the KEEL engines themselves.

This demo includes Mission Control and two individual UAVs (Unmanned Aerial Vehicles).

You can see this design with several enhancements in the Unmanned Aerial Vehicle (UAV) Demo where you can watch the UAVs in action. Other demos that fit within the same C2 domain are the Surveillance Demo, the Swarm Leadership Demo and the Adaptive Targeting Demo. These describe other policies that might be included in unmanned vehicles while still allowing humans to impact how they autonomously solve problems.

Using KEEL Technology, policy makers can create complex policies that address dynamic situations with relative ease. This will greatly reduce costs and increase the capabilities of advanced unmanned vehicles (Air, Ground, and Sea).
  • Devices / Systems that can interpret information better and faster and can react better and faster will win
  • Organizations that control those devices / systems will win.
  • Organizations that can accumulate these devices / systems faster will win.

The concept being demonstrated suggests that it is possible to create a UAV that operates autonomously (without a remote pilot) and still receives some direction from a higher level command.

In this demonstration, each UAV has been designed as a fully autonomous vehicle. Each knows how to evaluate its options and choose what it should do. Mission Control has two management functions:

  1. To provide intelligence input to the UAV that has the potential of modifying how decisions are made, and
  2. To confirm attack requests and perhaps choose which of the UAVs will perform the attack and potentially to block any attacks from either UAV.

In this demonstration, Mission Control evaluates the status of both UAVs and selects the UAV with the most likely chance of success to attack the target. This same reasoning model could be deployed to each UAV in a "swarming" model, where each UAV published its own status so all of the UAVs would know which UAV was the most capable. All UAVs would react accordingly without the need for a Mission Control decision maker.

In this demonstration, Mission Control will have the capability of escalating the importance of the mission. Each UAV has built in sensors that determine the value of the target. Each UAV also can evaluate the risk of attacking that target. It is assumed that Mission Control can have access to additional intelligence that could be used to change how the UAVs evaluate the target. In this case, the importance of a tank as a target could be enhanced if it was known that a certain individual might be inside or if the tank might be carrying weapons of mass destruction.

In light of this capability, Mission Control can escalate the value of the target and it can increase the risk tolerance of the UAV in attacking the target. In the highest priority case, the UAV will be told to ignore all risk in evaluating whether to attack.

The UAV will not have a pilot and will therefore have no need for a "user interface". The demonstration will allow the user (simulator operator) to simulate sensor data observed by the UAVs.

The objective of each UAV is to determine whether it should:

  1. search for targets,
  2. hide from threats that are encountered while searching,
  3. evade threats if that is more appropriate
  4. retreat (for various reasons), or
  5. attack a target that has been identified.

The objective of the UAVs is to attack targets. But they won't just attack anything. First the target must have sufficient target value.

Before considering an attack, however, there must be sufficient weapons available. If weapons / ammunition have been depleted, the UAV will retreat (i.e. go home for re-supply).

This demonstration includes Mission Control in the attack scenario. Now, when either or both UAVs want to attack the target, they request permission from Mission Control. Mission Control will determine which UAV is in better position to perform the attack (or which one should attack first). This command is sent back to the two UAVs authorizing one or the other to perform the attack. When the weapons of the first are depleted, then a command to the second "may" be given based on the overall evaluation.

Mission Control has also been given the ability to block all attacks, should they be requested. (For example, the war is over or some other intelligence is obtained.)

Also, each of the UAVs will be monitoring itself for damage. This will also contribute to its personal assessment of its ability to attack the target or whether it should retreat home.

While searching for targets, the UAV may be threatened by the enemy. If the threat is very low, it will be ignored. However, as the threat increases, the UAV will look for a place to hide. It will balance its ability to evade the threat or hide from it. It will remain in hide mode, until the threat goes away. Also, if the threat gets close enough and the threat is not something worth attacking, the UAV will run away (hoping that the threat will not blow it away).

Any time that the UAV is not hiding, retreating, evading or attacking will be spent searching for new targets.

This demonstration is not intended to be a complete solution. Additional items could be added like the ability to evaluate multiple targets and choose the best one while including fuel supply in the evaluation and the distance to each of the targets. We could also include the ability to redirect the focus of the UAVs to protect friendly forces if they came under fire.

Another enhancement could be to package the UAVs' KEEL Engines within state machines. Each UAV could then transition from state to state where a KEEL Engine would handle each mode of the UAV.

  1. at home mode where diagnostics and prognostics would be performed,
  2. load mode where munitions would be loaded
  3. refueling mode,
  4. in-route mode where it was migrating to the battlefield
  5. battlefield mode
  6. going home mode
  7. landing mode…..

Demonstration Overview

This is a very simple application of KEEL technology and is intended only to demonstrate some concepts of this type of a control system. It is not a real product and has not been validated as an appropriate design for such a system. A productized version of this concept could take into account any number of sensors and could react in a variety of ways. This multiple KEEL engine simulation has separate engines for each UAV and another one for Mission Control.

The demonstration running on Compsim's web site is a Macromedia Flash application. The graphical front end in this demonstration (scroll bars, option buttons and state indicators, images...) is created with standard Macromedia Flash tools by the programmer. The remainder of the code (Actionscript - not shown) is created using the KEEL toolkit. It is in the KEEL toolkit, where the relationships between target value, target risk, threat magnitude, hiding places, damage assessment and available weapons are defined. The KEEL toolkit has a menu option to document the design in , Standard C, C++, C#, Adobe/Macromedia Flash ActionScript 2/3, Java, Python, Visual Basic, and PLC Structured Text. The resulting solution is a very small footprint engine. If the KEEL engines were deployed in devices, then it is likely that C or another low level language would be used. Flash is good for web deployment. Other languages may be more appropriate for desktop / mainframe deployment.

This system is based on Compsim's patented / patent-pending KEEL technology that covers the toolkit user interface, Compsim's decision-making algorithms, the resulting KEEL engine architecture, and a method of implementing the cognitive model as an analog circuit.

KEEL Development:

The following images show the portions of the design of the system from within the KEEL toolkit.

In the screen shots below, decisions or decisions to perform actions are shown as the vertical bars in the upper half of the screen. The supporting and objecting reasons for each of those decisions or decisions to perform actions are shown as scroll bars below their respective decisions with green (supporting) or red (blocking) indicators.

The wires forming the web of inter-relationships indicate how one decision may interact with other decisions. The height of the upper bars is an indication of the importance of that specific data item at one point in time.

The Mission Control Engine is shown in one single screen shot. The Unmanned Aerial Vehicle Engine is shown by capturing several views. Both UAVs operate the same.

Mission Control

KEEL Source Code for Mission Control

The "Mission Importance" input to Mission Control is used to amplify the perceived Target Value and increase the Risk Tolerance of the UAVs. These values are sent to the two UAVs and are used to adjust their respective reasoning models.

Unmanned Aerial Vehicles (UAV1 and UAV2)

The KEEL Toolkit allows the user to select just a few items at a time for viewing. This is helpful in more complex designs are being developed. By viewing and working with subsets of data at a time, the related items can be more easily managed. Even though only portions of the data may be visible, the entire system is in operation. So when the user manually adjusts inputs, the entire system will react; not just the visible items.

Code Segment for Option Selection

The UAV design is based on a group selection process. This KEEL process is used for selecting the most appropriate course of action by accumulating a number of lower level reasons that support or block a particular activity. In this design, the KEEL engine will select between Attack, Retreat, Evasive Maneuver, Hide, or Scout. This is a "view" of selected items. The blue indicator at the left of the window reminds the designer that there are Hidden Groups. While it may be difficult to interpret the design in this report, the blue bar under the Attack label indicates that "Attack" is the chosen option for this UAV. The indicator highlights the desired option, while the indicator highlights the unselected options. Changing inputs to the system will cause other options to be chosen.

Attack Segment

KEEL Source Code for UAV1 Attack Segment

The screen shot above shows all of the associated information that is evaluated by the UAV in a determination to request and proceed with an attack function. In this design, two things are necessary for an attack to take place: First, the UAV must decide that an attack is appropriate. Second, the attack must be approved by Mission Control. In "this" overall system design, both of the UAVs may request an attack of the same target. It is Mission Control's responsibility to determine which UAV will handle the task. Mission Control has one other interaction with this UAVs decision regarding the attack. The UAV is balancing a number of items in making its decision. One of those items is its assessment of risk associated with the attack. If the risk is excessive, relative to the value of the target, then the UAV will not attack and risk its own destruction. Mission Control has the ability to override this concern over risk and, at the same time, escalate the perceived value of the target. In certain circumstances (perhaps where weapons of mass destruction might be identified), Mission Control may ask the UAV to risk all and attack (completely ignoring risk), even if the risk is high.

The decision to attack also takes into consideration the value of the target, other threats in the area, its own weapon supply and any internal damage. All of these impact its ability to attack the target successfully. Also, because the UAV is balancing the decision to attack with other decisions about its own health, even if the accumulated attack reasoning is above the threshold, it may choose to hide, make an evasive maneuver, or retreat if the justification for those actions outweighs the reasoning for the attack.

The UAV will only request attack permission if the balance of supporting and blocking conditions are raised above a threshold point and Attack is the preferred action. When the UAV wants to attack, it sends a request to Mission Control. Should the request be acknowledged, then the UAV will switch to Attack mode.

Mission Control has the ability to block attack requests. This could be done if the other UAV is considered to have a better chance of success or because there are some overriding reasons that no attacks should take place (i.e. the war over, or friendly forces are in the area…).

Hide Segment

KEEL Source Code for UAV1 for Hide Segment

Hiding is a defensive tactic. The UAV will only hide if there is a hiding place available. This is not a binary situation. The quality of the hiding place is taken into consideration. Mission Control participates in the decision to hide by potentially telling the UAV to devalue any threats. Also if the UAV is damaged, it may downplay the importance of Hiding and pursue a retreat. So, in this design, Hiding is a temporary activity that might be pursued while hunting. It may hide from threats temporarily, until it can resume its hunt.

Evade Segment

KEEL Source Code for UAV1 for Evade Segment

Evasive maneuvers are another defensive mechanism available to the UAV. The decision to take an evasive maneuver is driven by a threat that could be offset by Mission Control. In the overall design, the UAV may make an evasive maneuver when there is no place to hide (or the quality of the hiding place is determined to be insufficient).

Retreat Segment

Retreat is another defensive maneuver. In its most basic state, the UAV will retreat when it has utilized all of its weapons. This is an absolute position that will override all other options. Self assessment of internal damage can also contribute to a UAV's decision to retreat. Again, Retreat, like the other decisions, is a balancing act. Retreat is the least desirable action for the UAV to take and it will take it only if the conditions demand it.

In this design the impact of damage is non-linear as shown in the graph below. The design also includes a "Weapons of Mass Destruction" override. Should this directive by Mission Control be given, Damage assessment will be removed from the decision making model. In this case, the UAV will be directed to ignore any damage it has incurred when making its decision on whether to attack or not. The WMD override will also downplay the importance of available weapons. Only if the UAV is totally without weapons will the UAV decide to retreat.

Graph of Damage Impact

While these screen shots are probably not fully readable in this document, the design is easy to create and visualize in the KEEL toolkit. While in the design mode the user can "see" the design in action and graph the activity.


When the demonstration is started, the windows shown below are opened.

Screen Shot of Demonstration

Once loaded, the KEEL engines are constantly reading the sensors and reacting.

Adjust any of the scroll bars and view the state change.

Mission Control is depicted at the top of the window and the two UAVs are shown below. The values for Perceived Target Value and Perceived Target Risk are at the bottom.

The uppermost window represents Mission Control. It has a horizontal scroll bar that can be used to adjust mission importance. To the right of the vertical scroll bar are two horizontal bars indicating two pieces of information that are sent to the UAVs to impact Target Value and Risk Tolerance. By raising Mission Importance (right), the impact on Target Value and Risk Tolerance will be modified. The Risk Tolerance adjustment is non-linear and the "Weapons of Mass Destruction" modifier will kick in at 90%.

Mission Control "Reasoning" Modifier

The other control available to Mission Control is the check box that can be used to block any attack requests by the UAVs. Without this check box, Mission Control will evaluate which UAV should make the attack (assuming that both want to attack at the same time).

The two windows entitled "UAV1" and "UAV2" (below the Mission Control window) represent the options chosen by each of the UAVs and a few sensors available to each of them. When the system is loaded, the UAVs are shown with a full weapons supply. This causes them to Scout for the target. By lowering the Weapons horizontal scroll bar, the UAV will move to Retreat mode. The first horizontal scroll bar indicates sustained damage for that UAV and the third horizontal scroll bar indicates the availability of a hiding place. The fourth horizontal scroll bar allows the simulation operator to simulate a threat on the UAV. In normal real-time operation, these might be constantly changing observations.

The window entitled "Target" provides some external inputs to the system. The top horizontal scroll bar defines the target value. The lower horizontal scroll bar defines the risk assigned to the target. These are the values that are recognized by both UAVs. The Modified Target Value and Modified Target Risk indicators show the integration of Mission Control adjustments with the target value and target risk values. The Combined Target Value shows the result of determining an intermediate Target Value that combines the perceived value and risk together. Each UAV then combines this value with its own status information to determine what it will do.

One of the benefits of KEEL technology over competing technologies like neural nets and fuzzy logic is the ability to explain the decisions made. While not apparent in this demonstration, each UAV can record the sensor data it uses to make its operational decisions. If a user wants to get an understanding of why the UAV performed the way it did, it can import this recorded data into the KEEL Toolkit. The dynamic nature of the language will interpret the real world data the same way that the UAV did. By tracing the wires and observing the reasoning model, it is easy to understand how the information was interpreted.

KEEL Demonstrations:

The demonstration applications on Compsim's web site are not intended to be tutorials on the use of the KEEL toolkit. If you are interested in learning more about Knowledge Enhanced Electronic Logic and KEEL® technology, please contact Compsim at the phone number listed below.