This demonstration is a supplement to the Unmanned Aerial Vehicle Demo. The KEEL Source Code for the UAV has been rendered here showing the KEEL dynamic graphical language.
While this may at first appear complicated, it is a relatively simple application when created with the KEEL Toolkit and the KEEL "Dynamic Graphical Language". Wires defining functionality (dependencies and contributing factors) are created with simple drag and drop techniques. As soon as they are placed on the display, they are active; allowing the user to stimulate inputs and see how the system reacts. This way, the policy maker can create complex models without resorting to predicate calculus. When the policy / design is complete, it can be deployed in almost any conventional computer language. The autogenerated code also greatly simplifies the code validation process.
This rendering of the KEEL Engine has been deployed in JavaScript and is based on the same design implemented with the KEEL Toolkit. The rendering is "very" similar to that within the KEEL Toolkit where the design was created. This is one example of using the KEEL dynamic graphical language and deploying it in multiple environments.
The window above shows the KEEL dynamic graphical language for describing the policy for the UAV as it searches for the target and avoids collisions with other aircraft.
The user can interact with the design using the vertical scroll bars that control the INPUT Target Value (0), INPUT Distance (1), INPUT Target Risk (2), Threat INPUT (3), INPUT Fuel (4), INPUT Weapon Available(5), INPUT Hiding Place (6), INPUT Sustained Damage (7), INPUT Frustration (8), INPUT UAV1 Attack Authorization Blocker (9), Obstacle INPUT Risk Modifier (10), INPUT Distance Ahead (11), INPUT Full Left=0 Full Right=100. NOTE: You may have to scroll horizontally to bring the adjustable controls to the screen. When you use the "real" KEEL Toolkit there are several ways to organize the inputs for easy manipulation.
The user can interact with the Risk Modifier(10) to see how the Mission Control Adjustment can be used to "change how the UAV thinks" and provide ground control command authority to the UAV.
When developing the design with the KEEL Toolkit, the user has access to many more features, including the ability to isolate portions of the design. For example, if the user was just interested in the decision to attack, a view of the design showing just the relevant sections of the design associated with the attack would be displayed. The system remains fully operational, so the user still "sees the system think".
When implemented in a UAV, the KEEL Engine exists as a function that is accessed repeatedly as information changes. The graphical language is translated into conventional source code suitable for execution in any microprocessor. (There is no graphical manipulation in the KEEL Engine, just as there is no "text" manipulation.) The simple API (Application Interface) allows easy integration with existing systems. In this case the cognitive model exists as a single function. Other designs may be implemented as multiple KEEL Engines. Compsim's KEEL Tools support the integration of multiple KEEL Engines for use on a single microprocessor.
KEEL Technology includes a set of "tools"; one of which is KEEL Influence. KEEL Influence provides a way to automatically generate "Influence Diagrams", which provide a high level view of the factors contributing to decisions or actions. The following images were generated from the KEEL policy shown above.
KEEL-based policies are commonly used to direct complex information fusion types of behaviors with many inter-related factors. Explaining the resulting behaviors is often a significant factor when these capabilities are deployed in machines.
KEEL Influence is an interactive tool, that allows the user to investigate all or selected parts of the policy. The bubbles can be dragged around to generate the most effective view for group discussions. Labels for bubbles can be selectively and collectively turned on and off. Large green bubbles identify the Primary Inputs to the policy. Smaller green bubbles identify inputs designated as configuration or tuning parameters for the policy (There are no configuration inputs in this policy). Large Red bubbles designate the outputs of the policy. Gray bubbles are infusion fusion points.
