Overview of the OneSAF Models Infrastructure

1. Overview of the OneSAF Models Infrastructure

2. Agenda • Define fundamental concepts • Define battlespace actors • Define components • Define composite behaviors (CBs) and primitive behaviors (PBs) • Define information transport mechanisms • Explain inferencing • Explain actor view of data • Explain the decision tree • Describe encoding behavior best practices.

3. The “Sacred Chart”You will understand it by the end of this discussion.

4. Composition is OneSAF’s central design principle: Composite behaviors: Represent tasks and missions Are composed of PBs and other CBs Are created with the Behavior Composer. Entities: Represent people and platforms such as tanks and trucks Are composed of both behavior and physical agents and their models Are created with the Entity Composer. Units: Represent the command and control of organizations, such as platoons, companies, and battalions Are composed of behavior agents and their behavior models Are created with the Unit Composer. Model Composition

5. PBs provide chunks of doctrinal functionality from which more complex behavior models are built. PBs interact with behavior agents. Agents: Behavior agents provide command and control capabilities, such as planning, plan execution, and situation assessment. Physical agents are the “middlemen” between behaviors, the physical world, and physical models. Models: Behavior models answer behavior agents’ questions and represent the reasoning of agents. Physical models provide physical capabilities, such as mobility, weapons, vulnerability, sensing, and communications. They represent the effectors and perceptors of simulated platforms and the physics of the simulated world. Behavior Components

6. Actor: An entity or unit A simulated thing that can be instantiated in a battlespace and has a location Entity: In OneSAF, an entity is the smallest discrete, stand-alone actor and is implemented as a composition of physical components and behavioral components. Unit: In OneSAF, a unit has two meanings: A unit is an organized collection of actors and their capabilities. Alternatively… “a collection of actors” A unit is a simulation object representing the combined command and control of a collection of subordinate actors (entities and sub-units). Alternatively… “a collection of components” Component: An agent, its models, and model data Agent: Discrete physical or behavioral capability (weapon, mobility, sensing) Modeling Infrastructure Definitions

7. Agent Composite Behavior Q? Component Model A! Primitive Behavior Events and Triggers Branch Order Sender Blackboard MI Icons Unit Entity World Model Data Blackboard

8. Simulation ObjectRuntime Database(SORD) Client (Wrapper) Objects ClientObject Modeling Infrastructure ClientObject Defines Client Model Battlespace Participant a.k.a. Actor ClientObject Composite Behaviors 1..* Actor Software Component 1 Object Database Managers (ODM) Posted to Blackboard on Initialization Blackboard C2 Manager Sides & Forces Manager Entity Manager Unit Manager Control Measures Manager Application Management Manager Physical Capability Unit Entity Triggers Primitive Behaviors RuntimeDataModel(RDM) TransportObject Use & are controlled by TransportObject Defines Transport Model TransportObject Trigger Object Database (ODB) use use use Behavior Agents (Controller) Physical Agents (Controller) Data Data Data Physical Models Behavior Models 1..* 1..* Graphical View of MI Discovered method invocation

9. Modeling Infrastructure Battlespace Participant a.k.a. Actor Composite Behaviors 1..* Actor Software Component 1 Posted to Blackboard on Initialization Blackboard Physical Capability Unit Entity Triggers Primitive Behaviors Use & are controlled by Trigger use use use Behavior Agents (Controller) Physical Agents (Controller) Data Data Data Physical Models Behavior Models 1..* 1..* Discovered method invocation OneSAF Battlespace Participants (Actors)

10. Side relationships: Hostile, Suspect, Neutral, and Friendly. “Unknown” is available, but meaningless – do not use it. Inherited from comprising side. Command relationships: Generally, each actor has a command relationship with another actor. At least one top-level actor per side. Independent entities can be created and controlled. Each command relationship establishes a command net. Support relationships: Fire Support, Combat Support, Combat Service Support, Intel, and Air Defense Artillery. Each support relationship establishes a support net. Relationships

11. Path to Actors • net.onesaf.core.services.odm.unit • net.onesaf.core.services.odm.entity

12. Modeling Infrastructure 1..* Battlespace Participant a.k.a. Actor Actor Software Component 1 Posted to Blackboard on Initialization Blackboard Triggers Physical Capability Unit Entity Use & are controlled by Trigger Behavior Agents (Controller) Physical Agents (Controller) Composite Behaviors 1..* 1..* Behavior Models Physical Models Primitive Behaviors use use use Data Data Data Discovered method invocation Components in MI

13. An agent is a software artifact exhibiting: Autonomy Reactivity Inferential capability Temporal persistence Cooperative behavior. Agent control within an actor is implemented as a subscription mechanism through the actor’s blackboard. Agents receive only the triggers they are interested in, may send any trigger, and are unaware of other agents. Agent Concepts

14. “Society of the Mind” Marvin Minsky The human mind is a society of agents. A OneSAF actor is a society of agents. Groups are societies of actors: Sides, Forces, and Units Sides are composed of: Forces, Units, and Entities. Forces are composed of: Sides, Units, and Entities. Units are composed of: Units and Entities. Entities are societies of agents (and their models). Organization of and association within societies: Groups: Relationships Entities: Contained with actor Actors as Societies

15. Our dissatisfaction with more direct modular software solutions is not that they do not solve their problems; in fact, they are often quite efficient solutions. It is that we desire software solutions that are more flexible, easier to adapt to new problem spaces, and handle various levels of fidelity and entity counts. We want software systems that take advantage of special knowledge when available and degrade gracefully (not catastrophically) under unusual conditions. We also want a set of software products that can easily evolve over time without the typical software arteriosclerosis that develops over time in large systems. Why use Agents?

16. Behavior Agents: Command Scheduler Intel Message Operations Driver Direct Fire Weapons Controller Fire Direction Center Caller For Fire ADA Target Handoff Physical Agents: Weapon Radio Sensor Mobility Transport Vulnerability Example Agents

17. Path to Agents • Behavior Agents: • net.onesaf.core.services.model.behavior • Physical Agents: • net.onesaf.core.services.model.physical

18. Modeling Infrastructure 1..* Battlespace Participant a.k.a. Actor Actor Software Component 1 Posted to Blackboard on Initialization Blackboard Triggers Physical Capability Unit Entity Use & are controlled by Trigger Behavior Agents (Controller) Physical Agents (Controller) Composite Behaviors 1..* 1..* Behavior Models Physical Models Primitive Behaviors use use use Data Data Data Discovered method invocation Behaviors

19. An important element of OneSAF composability is the ability to compose behaviors. OneSAF’s goal is to develop a language for non-programmers to develop executable representations of behavior: The set of behaviors is the language dictionary. Behavior inputs and outputs establish the language’s syntax (rules for arranging “words” to make valid sentences). CB execution plots are sentences. “Your mission, Jim, should you decide to accept it, is to use and extend the OneSAF behavior language.” Behavior Creation without Programming

20. Principles for a useful, robust dictionary: Because the dictionary must make sense to non-programmers, our PBs’ names and actions should make sense in the problem domain. We hide solution space decomposition through naming and software engineering (Object-oriented [OO] design, helper classes). PBs must be semantically rich (usable in many contexts). Our dictionary should be: Concise Support a large set of sentences. Behavior over-decomposition creates behaviors each usable only in the context of a few other behaviors. Such semantically weak PBs lead to a: Verbose dictionary Limited set of sentences. Guiding Principles

21. CBs: Represent tasks and missions Are composed of PBs and other CBs Are created with the Behavior Composer. Temporal organization: Sequential Parallel Conditional Branching Looping Composite Behaviors

22. Each phase (Plan, Prepare…) is optional. For example: Only the Perform phase is necessary for performing a task. Only the Plan phase is necessary for planning a task. Each phase consists of one or more CBs and PBs organized temporally. Within each phase: CBs and PBs are organized into sequential and parallel temporal relations. Branches and loops control the execution of behaviors. Sequential Execution Plan Prepare Perform Finish Monitor Parallel Execution Generic Composite Behavior

23. PBs provide chunks of doctrinal functionality from which more complex behavior models are built. PBs interact with behavior agents. Strategies for robust PBs: Support implicit modeling Include centralization Include semantic richness. Primitive Behaviors

24. Many behaviors may simply require a sequence of three PBs: DetermineTimesToPerform_PB(taskX, actor, location) Data lookup Algorithm TimeDelay_PB(timeToPerform) AssertFactOrState_PB(taskXDone(true)) With such an approach: An arbitrary number of specialized CBs can be developed and given doctrinally meaningful names. The assertion of facts will, in some cases, cause distributable state changes. Fact developers are responsible for making fact assertion cause state attribute distribution. Implicit Modeling

25. Centralization: Put conceptually similar things together. For example, we avoid building a PB to find each type of tactical position. Instead: DetermineGroundTacticalPosition_PB selects ground positions using algorithms suitable for terrain skin. DetermineUrbanTacticalPosition PB selects interior, exterior, and near building positions using algorithms in a 2½d world. DetermineAirTacticalPosition PB selects 3d positions. This approach does not reduce the amount of code to write but it: Does reduce the number of PBs May illuminate areas for software reuse. Centralization

26. Semantically rich PBs: Have an input set supporting multiple uses and internally select the appropriate algorithm. For example: MoveCrossCountry_PB selects the appropriate movement algorithm given a “movement technique” discriminator. New movement techniques require: Code to implement movement Additions to movement technique enumeration. Semantic Richness

27. Modeling Infrastructure 1..* Battlespace Participant a.k.a. Actor Actor Software Component 1 Posted to Blackboard on Initialization Blackboard Triggers Physical Capability Unit Entity Use & are controlled by Trigger Behavior Agents (Controller) Physical Agents (Controller) Composite Behaviors 1..* 1..* Behavior Models Physical Models Primitive Behaviors use use use Data Data Data Discovered method invocation Communication in MI

28. Event Information object that is sent from an actor to the external world over the network. Events are “sent” on the EventRouter. Also referred to as a “Simulation Event.” Trigger Information object sent internal to an actor. May be sent/received by agents and behaviors. Triggers are “posted” on the blackboard. Also referred to as a “Command.” Directive A special event that can also function as a trigger. The Directive may be “sent” or “posted.” When it is received as an event, it will automatically be posted as a trigger on the blackboard. Also referred to as an “Intervention” (on the MCT). Fact Information object that is stored in the blackboard. Facts may be simple “Information Facts” that store information or they may be “Fuzzy Facts” that can evaluate its stored information and modify it over time. Message A class of events used by the communication framework. Content Carriers

29. Events: Inter-actor communication Order: Initiates behavior execution Directive: Modifies executing behavior Message and Report: Doctrinal messages Element Coordination: Simulation specific, model coordination Triggers: Inter-agent communication Missions, phases, tasks, and overlays: Mission: Collection of tasks for an actor Phase: Collection of missions for a workstation (a unit) Task: CB Overlay: Used by CBs RDM has separate representations for each. Communicating Among Agents and Behaviors

30. Event Router: MI’s, models’, and PBs’ interface to the Simulation Infrastructure (EventManager, TimeManager, InterestManager). Send and receive (external) events Register ticks and timers Access to a RandomNumberGenerator Event Router

31. Agent control mechanism: Agents subscribe to triggers on the blackboard. When the blackboard receives a trigger, the blackboard notifies that trigger’s subscribers (and only those subscribers). Blackboard: “World Model” for an actor containing perceived truth. Send and receive (internal) triggers Contains facts Access physical capabilities One instance per actor; cannot be shared with other actors. Blackboard

32. OneSAF MI provides a fuzzy logic inference engine and supports fact sets. Facts are fuzzy facts. Do not worry, fuzzy facts support crisp logic. Facts can be created and placed on the blackboard. In this course, we will cover only facts governing reactive behavior. Inferencing

33. Composite behaviors may have reactive rules (e.g., MoveTactically_CB may enable “react to direct fire”). You will see how this is done in the section on CBs. Reactions (sometimes called “situational interrupts”) occur when a “reaction fact” is asserted. The reaction fact specifies the interrupting behavior (a CB with no mandatory inputs). If the executing behavior has reactions enabled, the executing behavior is suspended and the reactive behavior executed. When the reactive behavior ends, the interrupted behavior is NOT resumed. • Behavior resumption is but we do not know when. Reactive Facts

34. Types of data: Facts Data Distributed via ODM Parametric Data Intra-Actor Events (Triggers) Inter-Actor Events Actor View of Data

35. Facts (a.k.a. Predicates): Fuzzy facts: Truth value 0.0…1.0 Crisp facts: Truth value 0 or 1 (false or true) Types of facts: Externally Assignable Fact: Truth value is assigned by another party (e.g. a rule). Can appear on both sides of rules. Internally Evaluating Fact: Event Driven Evaluation Fact: Determine their truth values when stimulated by an event (e.g., taking fire). Can appear only on the LHS of rules. Evaluation On Query Fact: Determine their truth values when queried by interested party (e.g., a rule). Can appear only on the LHS of rules. Facts

36. Actors obtain distributed data from the Object Database Managers. For example: Control Measure Manager Entity Manager Unit Manager Component Manager Exceptions: Terrain from static Application Program Interfaces (APIs) Knowledge about self from reference to ODM instance Simulation events are ODM objects obtained from the Event Router. There is no SimEvent Manager. Data Distributed via ODM

37. Types of parametric data: Unit, entity, and component compositions: PAIR_dev_d\compositions\unit\ PAIR_dev_d\compositions\entity\ PAIR_dev_d\compositions\component\ CB compositions: PAIR_dev_d\compositions\behavior\ Model data: Physical PAIR_dev_d\models\phys\ Behavior PAIR_dev_d\models\beh\ Parametric Data

38. Within an actor, PBs and agents communicate via triggers posted on the blackboard with one exception: Using the blackboard: Decouples the behaviors and components Fosters composability. Behavior agents directing physical agents (the exception): Instead of using triggers: Each physical component posts its capabilities on the blackboard at initialization. Each behavior component retrieves the physical capabilities it needs from the blackboard at initialization. During execution, the behavior component directly uses the physical capabilities. Discovering and using physical capabilities still decouples the agents but is more efficient. This is the only allowed direct connection between agents. Do NOT use the discovery of capabilities elsewhere. Intra-Actor Events (Triggers)

39. Order: Initiates behavior execution Directives: Modifies executing behavior Messages and Reports: Doctrinal messages Element Coordination: Simulation specific, model coordination In general: Information from outside an actor reaches one or more (preferably one) components. The component: Processes the information Posts information to the blackboard via a trigger. The blackboard treats triggers originating outside the actor just like triggers originating inside an actor. Inter-Actor Events (Triggers)

40. There is not a one-to-one mapping from domain document type to simulation artifact. The domain documents (TDs, PKADs, PSDs, CDDs, BDDs) describe capabilities from a domainperspective but in a computationallyamenable form. Switching to the implementation we have nine ways of encoding behavior that group nicely into three sets: Behaviors: CBs PBs Data Behavior components: Behavior agents Behavior models Data Physical components: Physical agents Physical models Data. Since OneSAF is a heavily data-driven system, the data parts are extremely important. Decision Tree

41. During design, the implementers take a domain document and ask: Is this a physical or behavior capability? Physical leads to physical components. Does an agent already exist for this class of capability? If an agentexists:  Build a physical model.  Enhance the agent-model interface, if necessary. For example, the OneSAF vulnerability agent uses many vulnerability models (DF, IF). If noagentexits:  Build a new agent, ensuring the agent-model interface is generic  Build a physical model. If behavior capability: <next slide> Physical or Behavior Capability?

42. If behavior capability, does the capability persist? Persistent behavior capabilities lead to behavior components. Does an agent already exist for this class of capability? If an agent exists,  Build a behavior model.  Enhance the agent-model interface if necessary. For example, the OneSAF vulnerability agent uses many vulnerability models (DF, IF). If no agent exits, build:  A new agent ensuring the agent-model interface is generic and  A behavior model. For example, the ability to drive is persistent; an entity can move even if stationary. So we have a driver agent. Non-persistent behavior capabilities: <next slide> Persistent Capability?

43. If behavior, does the capability persist? Persistent: <previous slide> Non-persistent behavior capabilities lead to behaviors. Is the behavior something to be ordered? If orderable, build an orderable composite behavior with the behavior composer. If non-orderable, is the capability a new fundamental behavior capability? If not new, build a non-orderable composite behavior with the behavior composer. If new, is it a variation or enhancement of an existing primitive behavior?  If enhancement, add the capability to the existing primitive behavior.  If not an enhancement, build a new primitive behavior. Non-persistent Behavior?

44. In general: Descriptions of physical models (PKADs) lead to physical agents, models, and data. Descriptions of behavior (Domain Behavior Descriptions [DBDs]) lead to CBs, PBs, behavior agents, behavior models, and data. Decision Summary

45. Avoiding duplicate triggers: If multiple components express interest in a sim event, make sure the components post different triggers or check before creating duplicate triggers. Best Practices

46. OneSAF Objective System’s (OOS) entities, units, behaviors, agents, models, and data are officially verified. You cannot change them without voiding the verification. The solution is to extend, not modify directly, the OOS baseline. Use OOS concepts to create: Specialized classes Overloaded functions Polymorphic functions Refactor the OOS baseline to expose functionality for overloading or polymorphism. You must leave OOS functionality intact. Use the “Factory” pattern and leave exposed OOS functionality intact. Adding interfaces is preferred to changing existing interfaces. Add new component, entity, unit, and behavior compositions instead of changing the OOS versions. Add data “rows” to data files for your compositions. Ask for help and guidance. Modifications to the OOS baseline will be costly and time consuming to refactor for integration. We would rather help you do it correctly than fix it later. Extend OOS Baseline

47. Lesson Summary This lesson provided you the capability to: • Define fundamental concepts • Define battlespace actors • Define components • Define CBs and PBs • Define information transport mechanisms • Explain inferencing • Explain actor view of data • Explain the decision tree • Describe encoding behavior best practices.

48. Questions