See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/317239986

A Process for Human-aided Multi-Entity Bayesian Networks Learning in Predictive

Situation Awareness

Conference Paper · May 2016

CITATIONS READS

4 41

4 authors:

Cheol Young Park Kathryn Blackmond Laskey

George Mason University George Mason University
19 PUBLICATIONS   69 CITATIONS    238 PUBLICATIONS   5,950 CITATIONS   

SEE PROFILE SEE PROFILE

Paulo Costa Shou Matsumoto

George Mason University George Mason University
136 PUBLICATIONS   1,325 CITATIONS    17 PUBLICATIONS   143 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

ADS-B Security View project

ITA/GMU Distributed Simulation Project View project

All content following this page was uploaded by Kathryn Blackmond Laskey on 07 September 2017.

The user has requested enhancement of the downloaded file.

 A Process for Human-aided Multi-Entity Bayesian
Networks Learning in Predictive Situation Awareness
Cheol Young Park, Kathryn Blackmond Laskey, Paulo C. G. Costa, Shou Matsumoto
The Sensor Fusion Lab & Center of Excellence in C4I
George Mason University, MS 4B5
Fairfax, VA 22030-4444 U.S.A.
cparkf@masonlive.gmu.edu, [klaskey, pcosta]@gmu.edu, smatsum2@masonlive.gmu.edu
Abstract— Predictive Situation Awareness (PSAW) is the
ability to estimate and predict aspects of a temporally evolving
situation. PSAW systems reason about complex and uncertain
situations involving multiple targets observed by multiple sensors
at different times. Multi-Entity Bayesian Networks (MEBN) are
rich enough to represent and reason about uncertainty in
complex, knowledge-rich domains, and have been applied to
representation and reasoning for PSAW. To overcome a labor-
intensive and insufficiently agile process for manual MEBN
modeling by a domain expert, MEBN machine learning was
developed. Although technologies for machine learning have
improved dramatically, the necessary capabilities to build a
MEBN model efficiently do not yet exist. The search space for
components of an MEBN model is too large and complex to
investigate all possible structures, variables, and parameters. For
this reason, this paper proposes a method which relies partially
on expert knowledge and insight to reduce the search space. The
proposed method, a process for Human-aided MEBN learning in
PSAW, is a framework to develop a MEBN model from the
domain expert's knowledge combined with relational data. This
paper presents the process for Human-aided MEBN learning in
PSAW and a case study to evaluate the process on development
of a defense system in PSAW.
Keywords—Data Fusion; Situation Awareness; Predictive
Situation Awareness; Bayesian Networks; Multi-Entity Bayesian
Networks; Modeling Process; Human-aided Machine Learning
I. INTRODUCTION
Predictive Situation Awareness (PSAW) requires
combining information from multiple sensors to reason about
multiple targets over a range of times. Furthermore, the number
of entities and the relationships between them may be uncertain.
For this reason, PSAW requires an expressive language for
representing and reasoning about situations. Multi-Entity
Bayesian Networks (MEBN) [1] is such an expressive
language and has been applied to PSAW systems
[2][3][4][5][6][7]. MEBN combines First-Order Logic with
Bayesian Networks to represent and reason under uncertainty
in complex, knowledge-rich domains. The increased expressive
and reasoning power over ordinary Bayesian Networks (BNs)
[8] is an advantage for PSAW.
MEBN has been applied to several PSAW systems.
TSGUDA fused data from different sensors, identified the type
and activity of groups of targets, and generated alerts [3].
PROGNOS represented domain knowledge using probabilistic
ontologies, fused the knowledge dynamically into complex
situation models, and inferred aspects of the current situation
from the models [6]. Laskey [9] described a MEBN application
for using a model of user behavior to detect insider threats
from document retrieval patterns. Suzic [5] introduced a
generic framework for plan recognition using MEBN. The
framework focused on estimating plans of multi-agent
organizations through time using an ontology that supports
MEBN and contained four main template random variables
(i.e., utility, plan, state, and observation).
For efficiently designing a MEBN model, a reference
architecture [32] and a structured process [25] for constructing
semantically rich models for reasoning under uncertainty in
complex environments were suggested. Recently, a reference
MEBN model for PSAW, which offers referential elements of
MEBN for PSAW, was proposed [15].
Manual MEBN modeling by a domain expert is a labor-
intensive and insufficiently agile process. Therefore, greater
automation through machine learning method may enhance
agility. For this reason, a basic MEBN learning method was
suggested [18][19]. Although technologies for machine
learning have improved dramatically, the methods to learn a
MEBN model from data have not yet been reported. The
search space for building the model is too large and complex to
investigate all possible structures, variables, and parameters.
For this reason, the proposed method relies partially on expert
knowledge and insight to reduce the search space. A process
for Human-aided MEBN learning in PSAW is a framework to
develop an MEBN model from the domain expert's knowledge
as well as data.
This paper (1) provides background information for the
proposed process, (2) introduces the process for Human-aided
MEBN learning in PSAW, and (3) presents a case study on
developing a defense system in PSAW.
II. BACKGROUND
In this section, a definition of PSAW is presented and
MEBN is introduced as a representation formalism for PSAW.
Human-aided MEBN learning uses a relational model (RM) as
a data schema for a dataset. We choose RM because it is the
most popular database model and has the necessary expressive
power to represent entities and their relationships. It is
necessary to define how to convert elements of RM to elements
of MEBN, so a mapping rule between MEBN and RM, called
MEBN-RM, is introduced. Also, we introduce a reference
MEBN model for PSAW which enables us to easily develop a
MEBN model for PSAW by supporting the design of a MEBN
model for PSAW. The process for Human-aided MEBN
learning in PSAW, which this paper proposes, is a modification
of a probabilistic ontology modeling process, called
Uncertainty Modeling Process for Semantic Technology
(UMP-ST), so UMP-ST is introduced in this section.
A. Predictive Situation Awareness
According to the most commonly cited definition, situation
awareness (SAW) is composed of three processes: perception
of elements in the environment, comprehension of the current
situation, and projection of the future status [10][11]. Breton
and Rousseau [12] classified 26 SAW definitions and
identified a set of common elements of SAW. They identified
two distinct varieties, which they termed State- and Process-
oriented SAW. In their definition, Process-oriented SAW
focuses on the link between the situation and the cognitive
processes generating SAW, while State-oriented SAW focuses
on the link between the situation and an internal representation
of elements present in the situation.
Predictive Situation Awareness (PSAW) emphasizes the
ability to make predictions about aspects of a temporally
evolving situation. Traditionally, humans have been
responsible for higher-level fusion of low-level fusion outputs
to estimate and predict the evolving situation. A PSAW system
must aggregate state estimates provided by lower level
information fusion (LLIF) systems to help users understand
key aspects of the situation and project its likely evolution. In
order to more effectively support humans in understanding and
predicting a complex situation, a PSAW system needs a
semantically rich representation to capture attributes of,
relationships among, and processes associated with various
kinds of entities in a situation. It also needs to reason under
uncertainty about the situation. We use the following, taken
from [15] as our definition of PSAW.
Definition (Predictive Situation Awareness). Predictive
Situation Awareness (PSAW) is the ability to estimate and
predict a possible situation involving multiple actors (Atr)
and/or objects (Obj) in different locations (Loc), in which
actors may trigger events (Evt) or activities (Act) occurring
over time (T), and where the meaning of the situation (MS) is
revealed by integrating previous knowledge with evidence
from multiple sources.
Actors (Atr) are entities which can generate events (Evt) or
activities (Act), whereas objects (Obj) can be involved in
events or activities but cannot actively initiate them. For
example, vehicles V1 and V2 can be modeled as actors, and
they may be able to perform Move, Defend, or Attack activities.
(In a richer representation, we might model the vehicles as
objects and their drivers as actors.) On the other hand, a region
or stone is an object and cannot perform an activity. Events and
activities happen at a given time or during a time interval (T).
For example, two vehicles V1 and V2 may perform certain
activities at time T1. The meaning of the situation (MS) means
a set of the activities stimulated by the actors. For example, if
the two vehicles’ activities are attacking, the meaning of the
situation (MS) may be an attack situation.
B. Multi-Entity Bayesian Networks
MEBN allows compact representation of repeated structure
in a joint distribution on a set of random variables. MEBN
represents domain knowledge using an MTheory, a collection
of MFrags. An MFrag is a fragment of a graphical model that
is a template for probabilistic relationships among instances of
its random variables (RVs). RVs in an MFrag can contain
ordinary variables, which can be instantiated for different
domain entities to create multiple instances of the RVs. We can
think of an MFrag as a class that can generate instances of BN
fragments. These can be assembled into a Bayesian network,
called a situation-specific Bayesian Network (SSBN). A given
MTheory can represent many different SSBNs, depending on
the specific entity instances present in the situation. The
following definition is taken from [1].
Definition (MFrag). An MFrag F consists of: (i) a set 𝑪 of
context nodes, which represent conditions under which the
distribution defined in the MFrag is valid; (ii) a set 𝑰 of input
nodes, which have their distributions defined elsewhere and
condition the distributions defined in the MFrag; (iii) a set 𝑹 of
resident nodes, whose distributions are defined in the MFrag1;
(iv) an acyclic directed graph G, whose nodes are associated
with resident and input nodes; and (iv) a set 𝑳 of local
distributions, in which an element of 𝑳 is associated with each
resident node. Each input node must be a root node of G and
may have only resident nodes as children. The RVs in an
MFrag may have ordinary variables as arguments. We can
substitute different domain entities for the ordinary variables to
make instances of the RVs in the MFrag.
An MTheory M is a collection of MFrags that satisfies
conditions given in [1] ensuring the existence of a unique joint
distribution over its random variables. Like other expressive
probabilistic languages such as Object-oriented Bayesian
networks [13] or probabilistic relational models [14], MEBN
allows random variables to be defined as templates than can be
repeatedly instantiated to construct probabilistic models with
repeated structure.
C. Relational Model (RM)
In 1969, Codd proposed the Relational Model (RM) as a
database model based on first-order predicate logic [23][24].
RM is the most popular database model. A relational database
(RDB) is a database that uses RM to describe and organize
data. In RM, data are organized as a collection of relations. A
relation is an abstract definition of a class of entities or a
relationship that can hold between classes of entities. An
instance of a relation is depicted as a table in which each
column is an attribute of the relation and each row, also called
a tuple, contains the value of each attribute for an individual
entity of the class represented by the relation. An entry in the
table, called a cell, is the value of the attribute associated with
the column for the entity associated with the row. A key for a
1
Bold italic letters are used to denote sets.
relation is one or more attributes that uniquely identify a
particular domain entity or row. A primary key uniquely
identifies the individual entities in the relation. A foreign key
points to the primary key in another relation. The cardinality of
a relation is the number of rows in the table, i.e., the number of
unique entities of the type represented by the relation. The
degree of the relation is the number of columns in the table,
i.e., the number of attributes of entities of the type represented
by the relation.
Fig. 1. Example of Relations
Fig. 1 shows an example of a relational model. There are three
relations: Vehicle, Report, and Communication. Columns of
each relation represent attributes of the relation. For example,
the Vehicle relation has two attributes: Key, which uniquely
identifies each individual vehicle, and VehicleType, which
indicates whether the vehicle is tracked or wheeled.
D. MEBN-RM Mapping Model
MEBN-RM is a framework that maps elements of RM to
elements of MEBN [19]. MEBN-RM contains an entity
mapping between a relation in RM and an entity in MEBN, a
resident node mapping between an attribute in RM and a
resident node in MEBN, and a context node mapping between
an attribute in RM and a context node in MEBN.
In MEBN, an entity is a unique thing with independent
existence. We can distinguish between entity types and entity
instances. For example, individual people (e.g., John, Mathew)
are instances of the person entity type. In MEBN-RM, an
entity relation from RM is mapped to an entity type in MEBN.
For example, the Vehicle relation (Fig. 1) can be mapped to a
VEHICLE entity type in MEBN.
A resident node in MEBN can be described as a Function, a
Predicate, or a Formula of First-order logic (FOL). MEBN
allows a modeler to specify a probability distribution for the
truth-value of a predicate or the value of a function. In FOL, a
predicate represents a true/false statement about entities in the
domain. For example, Communication(x, y) is a predicate that
expresses whether the entities indicated by the arguments x and
y are communicating. In RM, we can express a predicate as a
relation in which the attributes are arguments of the predicate
(e.g., the Communication relation in Fig. 1). In FOL, a function
is a mapping from domain entities to a value. For example, the
function VehicleType(x) is a function that maps its argument x
to wheeled if it is a wheeled vehicle and tracked if it is a
tracked vehicle. In RM, we can express a function as an
attribute of a relation. A primary key in the relation is used for
argument (s) of the function and a cell of the attribute is used
for an output value of the function, so the function maps from
the primary key to the cell. For example, in Fig. 1, the
argument of the function VehicleType is the primary key of the
Vehicle relation, and the output is the cell (either Tracked or
Wheeled) of the VehicleType attribute.
In MEBN, context nodes are used to specify constraints
under which the local distributions apply. In RM, the context
nodes are used for limiting a relation instance in a relation. For
MEBN-RM, we identify four types of the context node (Isa,
Value-Constraint, Slot-filler, and Entity-Constraint type) [19].
E. A Reference MEBN Model for PSAW
A reference MEBN model for PSAW specifies reference
MFrags, RVs, and entities which support the design of a
MEBN model for PSAW. Such a MEBN model is called a
PSAW-MTheory. The PSAW-MTheory is designed to reason
about PSAW questions and can be supported by the reference
model, called a reference PSAW-MEBM model.
To perform PSAW, we may want to answer various
questions, e.g., "Will the weather be cloudy?", "How many
military vehicles are we going to encounter?", "How high will
the level of danger for an enterprise be?", "Where will the
target be located?", "Where will the event occur?", "What is
the type of the target?", "What type of activity will the target
perform?", and "What will the enemy do and why?"
[20][4][21]. Also, Roy [22] proposed a broad spectrum of
questions to be answered in situation analysis (e.g., situation
element contextual analysis).
An entity in the reference model can be classified into five
categories; (1) the time entity T, (2) the observer entity OR, (3)
the sensor entity SR, (4) the target entity TR, and (5) the
interpreted target entity IT. These categories can be used to
describe a situation in which an observer observes a target and
interprets it as an interpreted target using a sensor at a certain
time. For example, an omnidirectional radar (as SR) controlled
by a commander (as OR) detects a vehicle object (as TR) and
produces a vehicle object report (as IT) at time T1 (as T).
In the reference model, random variables containing
ordinary variables of type T, OR, SR, TR, or IT are called
PSAW-RVs. For example, a situation in which two vehicles
communicate with each other and are detected by a COMINT
(communications intelligence) sensor at time T1 can be
described by a PSAW-RV, specified by Communicated(v1, v2,
cmt, t), where v1, v2, cmt, and t are ordinary variables that can
be filled in by a first vehicle, a second vehicle, a COMINT
sensor, and a time, respectively.
In MEBN, an MFrag is a fragment of a probabilistic graph-
ical model in which the nodes contain variables that are
placeholders for domain entities. MFrags can be instantiated
with domain entities and combined into complex models with
repeated structure. MFrags for PSAW, called PSAW-MFrags,
contains PSAW-RV. The reference MEBN model for PSAW
suggests four groups: (1) Relation of Observed Target, (2)
Sensing Conditions, (3) Relation of Interpreted Target, and (4)
Situation. These four groups can be constructed as four MFrags:
(1) a Relation of Observed Target MFrag, (2) a Sensing Condi-
tions MFrag, (3) a Relation of Interpreted Target MFrag, and
(4) a Situation MFrag, respectively. The Relation of Observed
Target MFrag defines distributions for PSAW-RVs related to
relations of an observed target. For example, it can include the
PSAW-RVs mission, size, type, and activity of a target. The training dataset. This paper improves the previous proces by
Relation of Sensing Conditions MFrag represents probabilistic using expert knowledge to limit the search space over
knowledge about conditions of sensors. For example, it can parameters, variables, and structures. The process is a
include the PSAW-RVs performance, range, and weather modification of UMP-ST to be applied to Human-aided MEBN
condition of a sensor. The Relation of Interpreted Target learning in PSAW, called HMLP. As UMP-ST containing the
MFrag represents probabilistic knowledge about relations for four main disciplines, the presenting process contains the four
interpreted targets. For example, it can include the PSAW-RVs steps (Fig. 2): (1) Analyze Requirements, (2) Design World
reported mission, reported size, reported type, and reported Model and Rules, (3) Construct Reasoning Model, and (4) Test
activity of a target. The Situation MFrag defines distributions Reasoning Model.
for situations of targets. For example, it can include the
PSAW-RVs danger level situation, collaborating situation,
and communicating situation.
F. Uncertainty Modeling Process for Semantic Technology
UMP-ST is a process for constructing a probabilistic
ontology. A probabilistic ontology represents domain
knowledge, including uncertainty about entity attributes and Fig. 2. Process for Human-Aided MEBN Learning
relationships [4]. PR-OWL [25] extends the OWL language to
represent probabilistic ontologies. UMP-ST supports the Inputs of the process can be needs and/or missions from
construction of PR-OWL probabilistic ontologies. The UMP- stakeholders. Outputs of the process are a reasoning model (in
ST process consists of four main disciplines: (1) Requirements, our case, a PSAW MTheory). The following sub-sections
(2) Analysis & Design, (3) Implementation, and (4) Test. describe these four steps.
The Requirements discipline defines goals, queries, and A. Analyze Requirements
evidence for a probabilistic ontology. The goals are objectives
This step is to identify requirements for development of a
to be achieved by reasoning with the probabilistic ontology
reasoning model. As with requirements in UMP-ST,
(e.g., identify a ground target). The queries are specific
requirements in the HMLP define goals to be achieved, queries
questions for which the answers help to achieve the objectives.
to answer, and evidence to be used in answering queries. Also,
For example, what is the type of the target? The evidence is
the requirements should include performance criteria for
information used to answer the query (e.g., history of the speed
verification of the reasoning model. These performance criteria
of the target). The Analysis & Design discipline designs
are used in the Test Reasoning Model step. Before the Analyze
entities, attributes for the entities, relationships between the
Requirements step begins, stakeholders provide their initial
entities, and rules for attributes and relationships to represent
requirements containing needs, wants, missions, and objectives.
uncertainty. These are associated with the goals, queries, and
These initial requirements may not be defined formally.
evidence in the Requirement discipline. For example, suppose
Therefore, to clarify the initial requirements, operational
that a vehicle entity has two attributes, type, and speed. Then
scenarios are developed. In other words, the operational
an example of a rule might be that if the speed is low, the type
scenarios enable to identify the goals, queries, and evidence in
is likely to be a tracked vehicle. The Implementation discipline
the requirements.
is a step to develop a probabilistic ontology from outputs
developed in the Analysis & Design discipline. Entities, This step contains two sub-steps (Fig. 3): (1) an Identify
attributes, relationships, and rules are mapped to elements of Goals step and (1) an Identify Queries/Evidences step.
the probabilistic ontology. For example, the attributes type and
speed are mapped to random variables type and speed,
respectively. The rule for the speed and type is converted to the
joint probability for the random variables type and speed. In
the Test discipline, the probabilistic ontology developed in the
previous step is evaluated to assess its correctness. The
correctness can be measured by three approaches: (1)
Elicitation Review, in which completeness of the probabilistic
ontology addressing requirements are reviewed, (2) Importance Fig. 3. Analyze Requirements
Analysis, which is a form of sensitivity analysis that examines
the strength of influence of each random variable on other The goals represent missions of the reasoning model we are
random variables, and (3) Case-based Evaluation, in which developing. The queries are specific questions for which the
various scenarios are defined and used to examine the reasoning model is used to estimate and/or predict answers.
reasoning implications of the probabilistic ontology [16]. The evidence consists of inputs used for reasoning. From these
sub-steps, a set of goals, a set of queries for each goal, and a set
III. PROCESS FOR HUMAN-AIDED MEBN LEARNING IN of evidence for each query are defined. The following shows
PSAW an illustrative example of requirement.
A basic MEBN learning method for relational databses was Goal 1: Identify characteristics of a target.
suggested [18][19]. MEBN learning finds parameters, variables,
and structure for an MTheory that provides a good fit to a
 Query 1.1: What is the speed of the target at a given
time?
Evidence 1.1.1: Position report for the target.
The performance criteria in the requirements can be
specified in terms of some measure of accuracy (e.g., the Brier
score [17], the Kullback-Leibler (KL) divergence [26], and the
area under the receiver operating characteristic curve (AUC)).
For example, we might require that the sum of KL divergence
values between ground truth and estimated results from a
reasoning model shall be less than a given threshold. The
performance criteria are determined by stakeholder agreement.
B. Design World Model and Rules
The Design World Model and Rules step develops a world
model and rules. The world model and the rules provide a clear
idea by which the reasoning model can be formed. This step
decomposes into two sub-steps (Fig. 4): (1) a Design World
Model step and (2) a Design Rules step. The Design World
Model step defines the world model from the requirements,
domain knowledge and/or existing data schemas. The world
model is used to identify rules. The Design Rules step defines a
rule or an influencing relationship between attributes (e.g., A
and B) of relations in the world model. The rules are used to
identify a reasoning model. The influencing relationship is a
relationship between attributes in which there is an unknown
causality between the attributes (e.g., influencing(A, B)). If we
know the causality, the influencing relationship becomes a
causal relationship (e.g., causal(A, B)).
Fig. 4. Design World Model and Rules
The Design World Model step uses requirements, domain
knowledge and/or existing data schemas to develop a world
model. The world can be represented in a modeling language
(e.g., Entity–Relationship (ER) model, Enhanced Entity–
Relationship (EER), RM, or Unified Modeling Language
(UML)). A requirement specifies a query and evidence for the
query. The elements of the requirement are used to define
corresponding elements in the world model. For example,
suppose that the requirements specify speed (Query 1.1) and
position attributes (Evidence 1.1.1) for a target g at a time t.
Based on these requirements, these two attributes are included
in the world model. We can then identify additional attributes
related to these attributes. For example, a type attribute for the
target g most likely influences the speed attribute. The speed
attribute at the previous time probably influences the current
speed attribute. These new attributes and relationships are also
included in the world model. In this step, the reference MEBN
model for PSAW can be used to identify more attributes for the
world model. For example, from the five entities (i.e., T, OR,
SR, TR, and IT), we can realize that the world model should
contain a sensor entity SR for the position attribute, so we add
both a sensor entity of ground moving target indicator (GMTI)
and its performance attribute into the world model.
In this step, we determine whether data can be obtained for
the attribute, and if so, either collect data or identify an existing
dataset. We usually divide the data into a training dataset and a
test dataset. The training dataset is used for machine learning in
the Construct Reasoning Model step. The test dataset is used
for verification in the Test Reasoning Model step. If no data
can be obtained, we use the judgment of domain experts to
specify the necessary probability distributions. For example, a
belief for the target type attribute can be P(Wheeled) = 0.8 and
P(Tracked) = 0.2. If neither data nor expert judgment is
available, we consider whether the attribute is really necessary.
For this, we can return the Analyze Requirements step to
modify the requirements.
The Design Rules step defines rules for the identified
attributes (i.e., type, speed, previous speed, GMTI performance,
and position) by expert knowledge. For example, we noted
earlier that the type attribute most likely influences the speed
attribute and the previous speed attribute also likely influences
the current speed attribute. These beliefs from expert
knowledge become a causal relationship rule as shown the
following.
Rule 1: causal(type, speed)
Rule 2: causal(previous speed, speed)
In this step, a (conditional) local distribution for an attribute
(e.g., the speed attribute) can be defined by expert knowledge.
In some cases, there is no dataset for a rule and all we have is
expert knowledge. For example, a conditional local distribution
for the speed attribute given the type attribute can be identified
by a domain expert (e.g., if a vehicle type is wheeled, then the
speed of the vehicle on a road is normally distributed with a
mean of 50MPH and a standard deviation of 20MPH).
C. Construct Reasoning Model
The Construct Reasoning Model step develops a reasoning
model from a training dataset a world model, and rules.
Fig. 5. Construct Reasoning Model
This step decomposes into two sub-steps (Fig. 5): (1) a Map
to Reasoning Model step and (2) a Learn Reasoning Model
step. The Map to Reasoning converts the world model and
rules to a candidate reasoning model. The Learn Reasoning
Model uses a machine learning method to learn the model from
a training dataset.
In the Map to Reasoning Model step, MEBN-RM is used
for a reference of mapping rule (i.e., how to convert RM to
MEBN). The five attributes (i.e., type, speed, previous speed,
GMTI performance, and position) in the previous section,
become five resident nodes in a candidate MTheory using
MEBN-RM. For example, the type attribute for the target g
becomes a resident node Type(g). The speed attribute for the
target g and at the time t becomes a resident node Speed(g, t).
The two rules enable the candidate MTheory to have
conditional dependencies between the resident nodes. For
example, from Rule 1, a conditional probability of the resident
node Speed(g, t) given the resident node Type(g) can be
derived.
The Learn Reasoning Model step contains MTheory
learning from relational data. MTheory learning is to learn an
MTheory M* given a training dataset D in RM and an initial
MTheory M. MTheory learning can be written as follows:
𝑀𝐸𝐵𝑁!"!!"#$_!"#$%&%' ( 𝑀 ∗ ∶ 𝑫, 𝑀 ) (1)
MTheory learning can use a score based learning method in
which candidate parameters and structures for the MTheory are
searched and a score function [18] is used to evaluate the
theories given the dataset. If we use score based MEBN
learning, the score function must be defined [28][29][30][31].
Search algorithms for structures and parameters of the model
are chosen. The results of the search are scored according to
the score function. A high scoring reasoning model is selected
as an output in this step.
D. Test Reasoning Model
In the Test Reasoning Model step, a learned reasoning
model is evaluated to determine whether to accept it. The
accepted reasoning model is output as a final result in this step.
This step is decomposed into two sub-steps (Fig. 6): (1) an
Experiment Reasoning Model step and (2) an Evaluate
Experimental Results step.
Fig. 6. Test Reasoning Model
The Experiment Reasoning Model step tests the learned
reasoning model using a test dataset. The test dataset can be
generated from simulations, existing data and/or actual
experiments. This experiment can consist of the following five
steps. (1) The learned reasoning model is exercised on a test
case from the test dataset. (2) The test dataset provides ground
truth data for a certain metric (e.g., KL divergence) in the
requirements defined in the Analyze Requirement step. (3) The
metric is used to measure performance between results from
the learned reasoning model and the ground truth data. (4)
Steps 1-3 are repeated for all testing cases. (5) This step results
in a result value integrating all measured values. Any attribute
for which we have no ground truth data are ignored in this
process.
In the Evaluate Experimental Results step, the performance
of estimation and prediction for the learned reasoning model is
assessed by the performance criteria in the requirements
defined in the Analyze Requirement step (e.g., a sum of KL
divergence values < 0.001). If the measured value satisfies the
criteria, the learned reasoning model is accepted and this step
results in the learned reasoning model. If the requirement is not
satisfied, we can return to the previous steps to improve the
performance of the learned reasoning model.
IV. CASE STUDY
In this section, we introduce a case study for the HMLP
process. In the case study, we aimed to develop a PSAW
MTheory for a prototype software PSAW system, called
HERALD, which wards off attacks against critical
infrastructure by means of early detection of threatening targets,
identification of the targets, estimation of the target’s activities,
and prediction of virtual short-term future situations. A
decision maker in charge of critical infrastructure (CI)
protection must examine situations, analyze the situations to
determine crucial aspects, choose courses of action to address
the mission, and execute the decisions. The goal of HERALD
was to support some of these activities for the decision maker
by fusing sensor system reports. The sensor systems producing
the reports were of various types such as a Moving Target
Indicator (MTI), an Imagery Intelligence (IMINT) system, and
a Geospatial Intelligence (GEOINT) system. A PSAW
MTheory developer in charge of the development of a
HERALD MTheory cooperated with the decision maker to
develop the HERALD MTheory by using the HMLP process.
The following shows how the development operates.
A. Analyze Requirements
HERALD focused on threats from terrorists and UAVs
approaching the critical infrastructure element. Operational
scenarios for attacker (Red Team) and defender (Blue Team)
are given below.
(1) Red Team Scenarios
HERALD considered two Red Team scenarios attacking a
nuclear power plant in South Korea: (1) terrorist attack and (2)
UAV attack. Both scenarios are performed in the same
environmental conditions in which the weather is clear, it is
evening, and the season is the end of the spring. (1) In the
terrorist attack scenario, a UH-60 helicopter carrying three
armed terrorists heads toward the nuclear power plant. At 800
m from the region, the helicopter airdrops the terrorists. The
terrorists break through a surveillance system and infiltrate the
plant. The terrorists occupy a critical infrastructure element at
the plant, set up explosives at a vulnerable point of the critical
infrastructure element, and evacuate from the area. (2) In the
UAV attack scenario, three UAVs flying in formation at speed
74MPH head toward a nuclear power plant. Each UAV
contains a bomb. The UAVs move to 12 miles from the plant
and scatter to distract the Blue Team from surveillance. At 6
miles from the plant, each UAV flies into the plant and
detonates its bomb.
(2) Blue Team Scenarios
For the two Red Team scenarios, the Blue Team responds to
the Red Team. A Blue Team command center uses sensors
around the plant for PSAW. If targets are identified, the
command center reacts to the targets (e.g., double-check using
a mobile sensor). If the targets are identified more precisely,
the command center defends the operations from the targets.
The Blue Team scenarios vary according to discrimination for a
target. The target is differently identified by its location. For
example, if a target is located far from a sensor, the sensor may
judge whether the target is detected or not. This case means
that the target is in a detection layer. Target discrimination is a
process in which the target is assigned to an object type from a
set of object types. Target discrimination can be broken into
four categories: (1) Detection, (2) Classification, (3)
Recognition, and (4) Identification, or DCRI [27]. In the
detection layer, an unconfirmed object has been acquired (e.g.,
object of interest). In the classification layer, the unconfirmed
object is determined by class (e.g., vehicle or animal). In the
recognition layer, threatening targets are determined (e.g., tank
or armored car). In the identification layer, the specific model
of the threatening target is determined (e.g., M1A2 or AH-
64D). The scenario of the Blue Team is as follows. (1) If a
target enters the detection layer, the commander of the Blue
Team observes the target’s activity closely. The target can
either enter the classification layer or leave the detection layer.
(2) If the target enters the classification layer, the commander
of the Blue Team tries to identify whether the target is armed or
not. The target can either enter the recognition layer or leave
the classification layer. (3) If the target enters in the
recognition layer and is determined as a threatening target, the
commander of the Blue Team prepares against an attack from
the target. The target can move to some places, stay at a place,
prepare for an attack, or attack the critical infrastructure. (4) If
the target enters the identification layer, the commander of the
Blue Team orders attack against the target. The target engages
with the Blue team.
(3) Requirements
From the operational scenarios for the Red Team and the
Blue Team, we developed goals, queries and evidence for the
PSAW questions Of Section 3. Two examples are given:
Goal 1: Recognize emergency situation for a critical
infrastructure
Query 1.1: How high is the level of danger to the
critical infrastructure?
Evidence 1.1.1: All reports for targets
Goal 2: Identify threatening target
Query 2.1: What is the type of the target?
Evidence 2.1.1: All reports for targets
For our case study, we used the Brier score for a multi-
category forecast, where perfect prediction yields a score of
zero, and a sure prediction on the wrong hypothesis yields a
score of two [17], as a metric for a performance criterion. The
performance criterion was that the Brier score for reasoning
results (e.g., results for Query 2.1) from the HERALD
MTheory should be less than 0.5.
B. Design World Model and Rules
This step contains two sub-steps (Design World Model and
Design Rules). The first sub-step is to define a world model for
HERALD from the requirements, domain knowledge and/or
existing data schemas (e.g., RM). The reference MEBN model
for PSAW can be used in this step to identify possible entities
and variables (or attributes in RM). The reference model
provides information about possible entities (i.e., T, OR, SR,
TR, and IT). Entities derived from these categories can have
various attributes and be related to other entities. Fig. 7 shows
an EER model for HERALD as the HERALD world model.
Fig. 7. Part of EER Model for HERALD
The EER model for HERALD contained 15 relations (i.e.,
sensor, target, time, ci_situation, reportedtarget_mtirpt,
sensorof, reportedtarget_imintsrpt, reportedtarget_geointsrpt,
sensortemporalproperty, targettemporalproperty, predecessor,
criticalinfrastructure, mti_report, and imints_report,
geoints_report). For example, the target relation possesses a
primary key TargetID and three attributes TargetType,
TargetSize, and TargetImage. We grouped relations and
attributes in the EER model for HERALD using the reference
MEBN model for PSAW. The reference model suggested four
groups: (1) Relation of Observed Target, (2) Sensing
Conditions, (3) Relation of Interpreted Target, and (4)
Situation. The Relation of Observed Target group contained
the relations target and targettemporalproperty. The Sensing
Conditions group contained the relation
sensortemporalproperty. The Relation of Interpreted Target
group contained the relaions mti_report, and imints_report,
geoints_report. The reference MEBN model provided some
rule information between these groups. The Sensing Conditions
group and the Relation of Observed Target group influenced
the Relation of Interpreted Target group. For example, the
attribute DistanceToSensor in the relation sensortempora-
lproperty influenced the report attributes in the report relations
mti_report, and imints_report, geoints_report. The arrows in
Fig. 7 indicate these relationships. From the relationships and
domain knowledge, we derive the following rules.
 Rule 1: causal({TargetType, Mission}, DangerLevel}
Rule 2: causal(TargetType, {TargetSize, TargetImage ,
Temperature})
Rule 3: causal(Temperature, TemperatureReport)
C. Construct Reasoning Model
This step consists of two sub-steps (Map to Reasoning
Model and Learn Reasoning Model) to construct a reasoning
model from a training dataset. According to MEBN-RM, an
entity relation which contains only one attribute for the primary
key of the relation (e.g., sensor and target) can be defined as an
entity type in MEBN. Thus, there were 7 entity types (sensor,
target, time, criticalinfrastructure, reportedtarget_mtirpt,
reportedtarget_imintsrpt, and reportedtarget_geointsrpt). Also,
each of the attributes in the relations could be mapped to a
resident node in MEBN using MEBN-RM. For example, the
attribute Activity of the relation targettemporalproperty
became the resident node Activity(tr, t). The attribute
DangerLevel of the relation ci_situation became the resident
node DangerLevel(ci, t).
Rules which are defined in the previous step are used to
develop conditional dependence and independence between
resident nodes. From Rule 1, we had a conditional dependence
P(DangerLevel | TargetType, Mission). This relationship could
be represented in a candidate MTheory for HERALD.
Fig. 8. CI Situation MFrag in the HERALD MTheory
Fig. 8 shows an MFrag, called a CI Situation MFrag in the
candidate HERALD MTheory. Note that this MFrag is a part
of the HERALD MTheory, which contains several MFrags
(e.g., MTI_Report, IMINTS_Report, and GEOINTS_Report) for
higher level information fusion. The MFrag represents
probabilistic knowledge of critical infrastructure situations
involving a group of targets. It contains three isA context nodes
for entities Target, CriticalInfrastructure, and Time, two input
nodes TargetType (with states Others and ThreateningTarget)
and Mission (with states Others and Attacking), and one
resident node DangerLevel (with states Dangerous and Safe).
The resident node DangerLevel(ci, t) has a critical
infrastructure ordinary variable ci and a time ordinary variable
t as arguments. It indicates whether the situation of the group
of targets in the times t is dangerous or safe. The resident node
DangerLevel(ci, t) is influenced by the input node
TargetType(tr) with a target ordinary variable tr and Mission(tr,
t) with the target ordinary variable tr and the time ordinary
variable t.
In the Learn Reasoning Model step, the candidate
HERALD MTheory is refined using a MEBN learning
algorithm from a training dataset. In our simple learning test,
we used parameter learning given the candidate HERALD
MTheory. The training dataset was generated by the HERALD
simulator. The HERALD simulator simulated ground truth
information about a situation in which blue and red teams
operated against each other. The Red Team could be a group of
terrorists or UAVs (unmanned aerial vehicles). The Red Team
aimed to destroy a critical infrastructure element defended by
the Blue Team. The Blue Team had several types of sensors
that could detect threatening targets of interest, and a command
center, charged with using data from the sensors to identify the
situation and make decisions about future actions. The
simulator simulated the operational scenarios in Section 4. To
learn the HERALD MTheory, the training dataset was
generated from the HERALD simulator. A test dataset was also
generated from the HERALD simulator to be used for
evaluation. These datasets were separately stored in a relational
database.
D. Test Reasoning Model
This step consists of two sub-steps (Experiment Reasoning
Model and Evaluate Experimental Results) to evaluate a
reasoning model from the test dataset. In the Experiment
Reasoning Model step, the performance of estimation and
prediction for the learned HERALD MTheory was assessed
using some measures (e.g., accuracy, sensitivity, specificity,
AUC, and Brier score). This experiment consisted of the
following five steps. (1) The test dataset provided entity
information (e.g., target1, sensor1, and time1) and simulated
ground truth information (e.g., ImageReport = Unknown,
TemperatureReport = High, SizeReport = Small) to the learned
HEARLD MTheory. (2) Given these, a marginal probability of
a query (e.g., Query 2.1: P(TargetType | ImageReport =
Unknown, TemperatureReport = Mid, SizeReport = Small) was
calculated using the learned HEARLD MTheory. (3) The test
dataset provided a ground truth data (e.g., TargetType =
ThreateningTarget). (4) The steps 1-3 were repeated for all
testing cases. (5) Finally, for results for all cases, the measures
were calculated.
Accuracy Sensitivity Specificity AUC Brier
Average 0.5893 0.9664 0.5884 0.6384 0.0294
Standard
0.0049 0.0434 0.0049 0.0078 0.0008
Deviation
Table 1. Evaluation results for target type estimation
In the Evaluate Experimental Results step, we evaluated the
Brier score. Table 1 shows the accuracy, sensitivity, specificity,
AUC, and Brier score for the target type estimation, in which
the four test datasets were used to evaluate the learned
MTheory. Each test dataset contained 10000 cases. For the
target type estimation, the average and the standard deviation
of the Brier score were 0.0294 and 0.0008, respectively. This
result satisfied the requirement defined in the Analyze
Requirements step.
V. CONCLUSION
We have developed MEBN models in PSAW.
Developments for PSAW-MEBN models were labor-intensive
and insufficiently agile processes. To overcome these problems,
MEBN machine learning for the PSAW-MEBN models was
developed. In the real world, limitations on available data may
necessitate using expert judgment. For this reason, a process [16] Laskey, K. B., & Mahoney, S. M. (2000). Network engineering for agile
for Human-aided MEBN learning in PSAW was presented in belief network models. Knowledge and Data Engineering, IEEE
Transactions on, 12(4), 487-498.
this paper. The process relied partially on expert's knowledge
[17] Brier, G. W. (1950). Verification of forecasts expressed in terms of
and insight. One case study was conducted for the process. A probability. Monthly weather review, 78(1), 1-3.
full effectiveness analysis to evaluate improvement in the [18] Park, C. Y., Laskey, K. B., Costa, P. C. G., & Matsumoto, S. (2013).
quality of the reasoning and reduction in time cost and time for Multi-Entity Bayesian Networks Learning For Hybrid Variables In
development was beyond the scope of this paper, and is left for Situation Awareness. Proceedings of the 16th International Conference
future research. Our future plans are to elaborate the process on Information Fusion (Fusion 2013).
and to apply the process to more realistic scenarios. [19] Park, C. Y., Laskey, K. B., Costa, P. C. G., & Matsumoto, S. (2013).
Multi-Entity Bayesian Networks Learning In Predictive Situation
Awareness. Proceedings of the 18th International Command and Control
Technology and Research Symposium (ICCRTS 2013).
ACKNOWLEDGMENTS [20] Waltz, E. L., & Buede, D. M. (1986). Data fusion and decision support
The research was partially supported by the Office of Naval for command and control. IEEE Transactions on Systems, Man, and
Cybernetics, 6(16), 865-879.
Research (ONR), under Contract#: N00173-09-C-4008.
[21] Dorion, É., Gareau, M., & Roy, J. (2008). Situation Analysis for the
Tactical Army Commander (SATAC).
REFERENCES
[22] Roy, J. (2001, August). From data fusion to situation analysis. In
Proceedings of Fourth International Conference on Information Fusion
[1] Laskey, K. B. (2008). MEBN: A Language for First-Order Bayesian (Vol. 2).
Knowledge Bases. Artificial Intelligence, 172(2-3).
[23] Codd, E. F. (1970). A Relational Model of Data for Large Shared Data
[2] Laskey, K. B., D’Ambrosio, B., Levitt, T. S., & Mahoney, S. M. (2000). Banks. Communications of the ACM.
Limited Rationality in Action: Decision Support for Military Situation
[24] Codd, E. F. (1969). Derivability, Redundancy, and Consistency of
Assessment. Minds and Machines, 10(1), 53-77.
Relations Stored in Large Data Banks. IBM Research Report.
[3] Wright, E., Mahoney, S. M., Laskey, K. B., Takikawa, M. & Levitt, T.
[25] Carvalho, R. N. (2011). Probabilistic Ontology: Representation and
(2002). Multi-Entity Bayesian NetworksforSituation Assessment.
Modeling Methodology. PhD Dissertation. George Mason University.
Proceedings of the Fifth International Conference on Information Fusion.
[26] Kullback, S., & Leibler, R. A. (1951). On information and sufficiency.
[4] Costa, P. C. G., Laskey, K. B., Takikawa, M., Pool, M., Fung, F., &
The annals of mathematical statistics, 79-86.
Wright, E. J. (2005). MEBN Logic: A Key Enabler for Network Centric
Warfare. Proceedings of the 10th ICCRTS. [27] Self, M., Miller, B., & Dixon, D. (2005). Acquisition Level Definitions
and Observables for Human Targets Urban Operations and the Global
[5] Suzic, R. (2005). A generic model of tactical plan recognition for threat
War on Terrorism. Army communications-electronics command fort
assessment. In Defense and Security (pp. 105-116). International Society
belvoir va night vision and electronics sensors directorate.
for Optics and Photonics.
[28] Cooper, G. F. & Herskovits, E. (1992). A Bayesian method for the
[6] Costa, P. C. G., Laskey, K. B., & Chang, K. C. (2009). PROGNOS:
induction of probabilistic networks from data. Machine Learning 9(4),
Applying Probabilistic Ontologies To Distributed Predictive Situation
309–347.
Assessment In Naval Operations. Proceedings of the 14th ICCRTS.
[29] Bouckaert, R. R. (1993). Probabilistic network construction using the
[7] Carvalho, R. N., Costa, P. C. G., Laskey, K. B., & Chang, K. C. (2010).
minimum description length principle. In Symbolic and Quantitative
PROGNOS: predictive situational awareness with probabilistic
Approaches to Reasoning and Uncertainty: European Conference
ontologies. In Proceedings of the 13th International Conference on
ECSQARU ’93, Lecture Notes in Computer Science 747, 41–48,
Information Fusion.
Springer.
[8] Pearl, J. (1988). Probabilistic Reasoning in Intelligent Systems:
[30] Heckerman, D., Geiger, D., & Chickering, D. M. (1995). Learning
Networks of Plausible Inference. San Mateo, CA, USA: Morgan
Bayesian networks: The combination of knowledge and statistical data.
Kaufmann Publishers.
Machine Learning, 20:197–243.
[9] Laskey, K., Alghamdi, G., Wang, X., Barbara, D., Shackelford, T.,
[31] Chickering, D. M., Geiger, D. & Heckerman, D. (1996). Learning
Wright, E., & Fitzgerald, J. (2004). In Proceedings of the Conference on
Bayesian networks: search methods and experimental results. In
Behavioral Representation in Modeling and Simulation.
Learning from Data: Artificial Intelligence and Statistics V, Fisher, D. &
[10] Endsley, M. R. (1988). Design and evaluation for situation awareness Lenz, H.-J. (eds). Lecture Notes in Statistics 112, 112–128. Springer.
enhancement. Paper presented at the Human Factors Society 32nd
[32] Haberlin Jr, R. J., da Costa, P. C., & Laskey, K. B. (2013). A Reference
Annual Meeting, Santa Monica, CA.
Architecture for Probabilistic Ontology Development. STIDS 2013.
[11] Endsley, M. R., Bolte, B., & Jones, D. G. (2003). Designing for
situation awareness: An approach to human-centered design. New York,
NY: Talyor & Francis.
[12] Breton, R., & Reousseau, R. (2001). Situation Awareness: A Review of
the Concept and its Measurement.Technical Report No. 2001-220,
Defense Research and Development Canada, Valcartier.
[13] Koller, D., & Pfeffer, A. (1997). Object-Oriented Bayesian Networks.
Paper presented at the Thirteenth Conference on Uncertainty in
Artificial Intelligence (UAI-97). SanFrancisco, CA, USA.
[14] Friedman, N., Getoor, L., Koller, D., & Pfeffer, A. (1999). Learning
Probabilistic Relational Models. In Proceedings of the Sixteenth
International Joint Conference on Artificial Intelligence (IJCAI-99).
[15] Park, C. Y., Laskey, K. B., Costa, P. C. G., & Matsumoto, S. (2014).
Predictive Situation Awareness Reference Model using Multi-Entity
Bayesian Networks. Proceedings of the 17th International Conference on
Information Fusion.

View publication stats