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 ChartYou will understand it by the
end of this discussion.
4
Model Composition

• Composition is OneSAFs 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.

5
Behavior Components

• 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.

6
Modeling Infrastructure Definitions

• 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)

7
MI Icons
Unit
Entity
World Model
Data
Blackboard
8
Graphical View of MI
Discovered method invocation
9
OneSAF Battlespace Participants (Actors)
10
Relationships

• 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.

11
Path to Actors

• net.onesaf.core.services.odm.unit
• net.onesaf.core.services.odm.entity

12
Components in MI
13
Agent Concepts

• 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 actors
  blackboard. Agents receive only the triggers
  they are interested in, may send any trigger, and
  are unaware of other agents.

14
Actors as Societies

• 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

15
Why use Agents?

• 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.

16
Example Agents

• 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

17
Path to Agents

• Behavior Agents
• net.onesaf.core.services.model.behavior
• Physical Agents
• net.onesaf.core.services.model.physical

18
Behaviors
19
Behavior Creation without Programming

• An important element of OneSAF composability is
  the ability to compose behaviors.
• OneSAFs 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
  languages 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.

20
Guiding Principles

• 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.

21
Composite Behaviors

• 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

22
Generic Composite Behavior

• 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.

23
Primitive Behaviors

• 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.

24
Implicit Modeling

• 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.

25
Centralization

• 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.

26
Semantic Richness

• 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.

27
Communication in MI
28
Content Carriers

• 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.

29
Communicating Among Agents and Behaviors

• 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.

30
Event Router

• Event Router
• MIs, models, and PBs interface to the
  Simulation Infrastructure (EventManager,
  TimeManager, InterestManager).
• Send and receive (external) events
• Register ticks and timers
• Access to a RandomNumberGenerator

31
Blackboard

• Agent control mechanism
• Agents subscribe to triggers on the blackboard.
• When the blackboard receives a trigger, the
  blackboard notifies that triggers 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.

32
Inferencing

• 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.

33
Reactive Facts

• 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.

34
Actor View of Data

• Types of data
• Facts
• Data Distributed via ODM
• Parametric Data
• Intra-Actor Events (Triggers)
• Inter-Actor Events

35
Facts

• Facts (a.k.a. Predicates)
• Fuzzy facts Truth value 0.01.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.

36
Data Distributed via ODM

• 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.

37
Parametric Data

• 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\

38
Intra-Actor Events (Triggers)

• 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.

39
Inter-Actor Events (Triggers)

• 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.

40
Decision Tree

• 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 domain perspective but in a
  computationally amenable 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.

41
Physical or Behavior Capability?

• 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 agent exists
• ? Build a physical 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
• ? Build a physical model.
• If behavior capability ltnext slidegt

42
Persistent Capability?

• 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 ltnext
  slidegt

43
Non-persistent Behavior?

• If behavior, does the capability persist?
• Persistent ltprevious slidegt
• 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.

44
Decision Summary

• 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.

45
Best Practices

• 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.

46
Extend OOS Baseline

• OneSAF Objective Systems (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.

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