AN AGENT BASED ENVIRONMENT FOR DISCOVERY AND COMPOSITION OF
SIMULATION COMPONENTS
By
IMRAN MAHMOOD
SCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY (ICT) ROYAL INSTITUTE OF TECHNOLOGY (KTH)
Master of Science Thesis
Stockholm, Sweden. 2007
KTH/ICT/ECS-2007-141
i
A B S T R A C T
Modelling and Simulation (M&S) plays an important role in supporting development of concepts,
making business decisions, conducting safe and low-cost trainings, studies and analysis. Simulations
can help us understand the dynamics of the systems and give us a tool to study them before they are
even being developed. Moreover it provides a very suitable virtual environment for training, research
and experiments that are delicate in nature. Nonetheless the development of simulation models is a
multi-disciplinary and time/resource consuming process. Scientists have investigated different
approaches of reusing already existing components in order to reduce the cost. But this involves
various challenges one of which is called �Composability�.
Some previous work has already done at FOI, to investigate improved methods of composability of
BOM by introducing semantic attachments using OWL. This thesis is an effort to develop an agent
based environment that performs both syntactic and semantic composability matching on a given set
of components which are discovered from the repository according to the criteria given by a
simulation modeller in a simulation scenario. The outcome of this thesis will help in automating the
discovery and composition operations of model components.
ii
A C K N O W L E D G M E N T S
I wish to dedicate this manuscript to the soils of the great land of Sweden, which welcomed me to
come and allowed me to harvest the crop of knowledge. Now that it reaped, I will it take back to my
country, half for feeding and half for seeding.
I express sincere appreciation to Professor Rassul Ayani and Mr. Forshad Moradi for giving me a
chance to work on this topic and for their kind support in the preparation of this work.
i
Table of Contents Abstract .................................................................................................................................. i Acknowledgments .............................................................................................................. ii List of figures ...................................................................................................................... iii Glossary ............................................................................................................................... iv 1. Introduction ........................................................................................................... 1
1.1. Introduction: ................................................................................................... 1 1.1.1. Modeling and Simulation .............................................................................................. 1 1.1.2. Reusability: ....................................................................................................................... 3 1.1.3. Composability .................................................................................................................. 4
1.2. Motivation: ...................................................................................................... 4 1.3. Aim of the project ......................................................................................... 5 1.4. Statement of the problem: ........................................................................... 5 1.5. Purpose of the study: .................................................................................... 8
2. Background ............................................................................................................ 9 2.1. Description of Terms: ................................................................................... 9
2.1.1. BOM-Base Object Model: ............................................................................................ 9 2.1.2. SRML .............................................................................................................................. 12 2.1.3. SDR: ................................................................................................................................ 12 2.1.4. Onthologies: .................................................................................................................. 13 2.1.5. OWL: .............................................................................................................................. 13 2.1.6. Intelligent Agents: ......................................................................................................... 14 2.1.7. Multi-agent System (MAS): ......................................................................................... 14 2.1.8. Discovery and Composition process work flow: ................................................... 15
3. Agent based framework ..................................................................................... 17 3.1. Overview: ...................................................................................................... 17 3.2. Agent Oriented Software Engineering .................................................... 17 3.3. What is an Agent? ........................................................................................ 18 3.4. What is an Agent Framework? .................................................................. 18 3.5. JACK Agent Framework: ........................................................................... 19 3.6. Jack Agents: ................................................................................................... 19 3.7. Components of Jack Framework: ............................................................. 21
3.7.1. The JACK Agent Language ........................................................................................ 21 3.7.2. The JACK Agent Compiler ........................................................................................ 21 3.7.3. The JACK Agent Kernel ............................................................................................. 21 3.7.4. Jack Code Entities: ....................................................................................................... 22
3.8. JACK Development Environment (JDE) .............................................. 25 3.9. JACK Framework Workflow: ................................................................... 26
4. Implementation prototype ................................................................................ 29 4.1. Software development approach .............................................................. 29 4.2. System class diagram: .................................................................................. 31
4.2.1. Query Manager: ............................................................................................................. 31
ii
4.2.2. Combination Manager ................................................................................................. 31 4.2.3. Composition Manager ................................................................................................. 31 4.2.4. Comparison Manager ................................................................................................... 31 4.2.5. Presentation Manager .................................................................................................. 31
4.3. Sequence Diagram: ...................................................................................... 34 4.4. Jack Agent framework: ............................................................................... 38
4.4.1. Initialization: .................................................................................................................. 38 4.4.2. Parsing: ........................................................................................................................... 39 4.4.3. Discovery: ...................................................................................................................... 39 4.4.4. Virtual SDR: .................................................................................................................. 39 4.4.5. Combinations: ............................................................................................................... 42 4.4.6. Composition: ................................................................................................................. 42 4.4.7. Comparison: .................................................................................................................. 44
4.5. Future Improvements ................................................................................. 46 5. Test case study ..................................................................................................... 47
5.1. A Restaurant Scenario: ................................................................................ 47 5.2. Output of the test: ....................................................................................... 49
5.2.1. Step 1:.............................................................................................................................. 49 5.2.2. Step 2:.............................................................................................................................. 50 5.2.3. Step 3:.............................................................................................................................. 51 5.2.4. Step 4:.............................................................................................................................. 51 5.2.5. Step 5:.............................................................................................................................. 52
6. Conclusion & Future work ............................................................................... 53 6.1. Conclusion: ................................................................................................... 53 6.2. Future Work: ................................................................................................ 54
References .......................................................................................................................... 55 Index .................................................................................................................................... 57 Appendixes ......................................................................................................................... 58
1. Restaurant SRML ......................................................................................... 58
iii
L I S T O F F I G U R E S
Figure 1: System, Model and Simulation ............................................................................................................................. 2 Figure 2 BOM Conceptual Model, as described in (8) ................................................................................................... 12 Figure 3 Discovery and Composition process work flow [6] ...................................................................................... 17 Figure 4 JACK Process (a. Jack Language b. Jack Compiler c. Jack Runtime) ....................................................... 22 Figure 5 Jack Agent entities ................................................................................................................................................ 23 Figure 6 Jack Development Environment [12] ............................................................................................................... 26 Figure 7 Jack Agent Workflow ........................................................................................................................................... 27 Figure 8 System Architecture .............................................................................................................................................. 29 Figure 9 Class Diagram ........................................................................................................................................................ 32 Figure 10 Use case Model .................................................................................................................................................... 34 Figure 11 Sequence Diagram............................................................................................................................................... 35 Figure 12 Owl Description .................................................................................................................................................. 40 Figure 13 Discovery Rules [6] ............................................................................................................................................ 41 Figure 14 Composition Rules [6] ...................................................................................................................................... 42 Figure 15 Composition Logic ............................................................................................................................................. 43 Figure 16 Entire Process ...................................................................................................................................................... 45 Figure 17 Restaurant Sequence Diagram [6] ................................................................................................................... 48 Figure 18 Output Step 1: Parsing ....................................................................................................................................... 49 Figure 19 Output Step 2: Discovery .................................................................................................................................. 50 Figure 20 Output Step 3: Combinations ........................................................................................................................... 51 Figure 21 Output Step 4: Matching ................................................................................................................................... 51
iv
G L O S S A R Y
BOM Base Object Model
DoD - Department of Defense
FOI- Totalförsvarets Forskningsinstitut (Swedish Defence Research Agency)
HLA High Level Architecture
HTML - Hyper-Text Markup Language
HTTP - Hyper-Text Transfer Protocol
IDE - Integrated Development Environment
JDE Jack Development Environment
OWL - Web Ontology
PoC - Point of Contact
SISO - Simulation Interoperability Standards Organization
SRML Simulation Reference Markup Language
UML - Unified Modeling Language
XML - eXtensive Markup Language
C h a p t e r 1
1 . I N T R O D U C T I O N
1.1. Introduction:
1.1.1. Modeling and Simulation
A computer simulation is a program that attempts to simulate an abstract model of a
particular system. Computer simulations have become a useful tool in modeling of many natural
systems in physics (Computational Physics), chemistry and biology, human systems in
economics, psychology, and social science and in the process of engineering new technology, to
gain insight into the operation of those systems. Computer simulations vary from computer
programs that run a few minutes, to network-based groups of computers running for hours, to
simulations that run for days. The scale of systems being studied by computer simulations has
far exceeded anything possible (or perhaps even imaginable). Beside the fact that it involves a
high performance computational environment, the construction of such complex system is also
costly and time consuming. Even some times the cost of developing simulation is very high
however still computer simulation is worthy as in some cases running simulations is better than
the original system (e.g., nuclear tests, air combat, accident investigation or experimental
surgery), where lives are at risk so it becomes unavoidable to utilize the equivalent simulation
systems in order to better analyze the results of experiments and take precautionary measures
[1]. To summarize simulation plays an important role the scientific research and problem
solving. For more details please see [2].
Modeling and Simulation is a well know method of scientific problem solving used in scientific
community and other businesses to investigate solutions to a great range of problems. Simulations
are performed to study in depth the behavior of a system, formally represented mathematically or as
a computer program. They are performed on various scenarios to test the reaction of the system,
2
analyze various data-sets and their effect of the behaviors of the system. Simulations can be done on
existing systems or on conceptual systems, which saves a great deal of effort and money by making
it possible to find out how systems work before they are developed and built. A similar work can be
seen at [3].
A simulation is an implementation of a model of the existing system that is intended to be studied.
Each entity or object in the existing system represents a component in the simulation and each
component has a set of states. Moreover each interaction between the entities is represented by
events and actions and the states are changed according to their interactions. The following diagram
shows the relation of a system, model and a simulation:
A system exists and operates in time and space.
A model is a simplified representation of a system at some particular point n time or space intended to preview the understanding of the real system.
A simulation is the manipulation of a model in such a way that it operates on �compressed� time or space, thus enabling one to perceive the interactions that would not otherwise be apparent because of their separation in time or space.
Figure 1: System, Model and Simulation
SIMULATION
MODEL
SYSTEM
3
We have so far established that simulation plays an important role in the business decision making
and scientific problem solving however when it comes to development/construction a simulation
system is not only a time consuming effort but also it implies greater cost. And due to this factor the
decision makers might find it discouraging to invest in the development of simulation models. A
simulation development process includes many steps including, requirement specification, conceptual
modelling, design, development, test, verification and validation. So in order to ensure the validity and
suitability of the simulation model a large amount of effort is required [3].
This has led the scientist and IT researchers to come to a conclusion that instead of constructing
new simulation components each time they are needed, they should go for the existing components
and reuse them. This approach to reuse pre-developed and already validated simulation components
has been inspired from different paradigms. One of which is component-based development, which
has already been successfully applied in manufacturing hardware and software industry, so it is easily
accepted and is favoured by the simulation researchers to adapt it.
1.1.2. Reusability:
The ability of a component or subprogram to be used again with or without modification as a building
block in a different program is called Reusability [4].
Component Reusability is about building a library of frequently used components, thus allowing new
programs to be assembled quickly from existing components. Component Reusability has been
known to be a very suitable approach in terms of time and cost saving. This concept has been
applied not only to the code, but also to the design, data, documentation, test materials,
specifications, and plan.
We have a repository named �Semantic Distributed Repository� to store the BOM components
that are identified as commonly used components. This repository not only contains model
components for simulations but also their semantic descriptions. So an important operation in the
reusability has been identified as �semantic discovery� of a suitable component.
4
1.1.3. Composability
According to Petty [5] composability:
1. �Is the capability to select and assemble simulation components in various combinations
into simulation systems to satisfy specific user requirements�
The assembled simulation components could be purpose-built or are reusable component.
There are two major aspects of composability, namely syntactic composability and semantic
composability. Syntactic composability is how to actually compose implementation of
components into a working simulation, while semantic composability is a more theoretic view
on composability that considers how models of simulations can be composed and remain valid,
via for example SCT � the Semantic Composability Theory. One view on composability that
relates highly to this thesis can be found in [4] where the author explains it as follows:
�Given a set of components, structured descriptions or specifications of the components,
sometimes called meta-data or meta-models, can be used to guide the process of selecting
components for a specific purpose and determining if a set of components can be effectively
composed�. [4: Page-13 ,Sec-2.2]
1.2. Motivation:
The initiative for this work has been inspired from some previous (Master thesis) research done
at FOI. Few of the important topics are as follows:
1. Composability and Reuse for Simulation Development using BOMs [4]
2. Syntactic and Semantic Model Composability based on BOMs [6]
5
In (6), an approach has been proposed to model composition using Semantic attachment of
BOMs and SRML. A three layered model was suggested for composing BOM based
components along with a set of discovery and matching rules.
Based on the work done so far, it was an intuitive effort to setup an intelligent automated
environment to support simulation modelers for performing composability operations: DMC
(Discovery, Matching and Composition) of the component available in the SDR: Semantic
Distributed Repository [8] thus making it a step ahead in the domain of
reusability/interoperability of simulation components. This will not only bring modernization in
the simulation research community but also be a threshold for the development of next
generation simulation systems. For details about the benefits of composition of simulation
models please refer to [4], [5], [6], [7]
1.3. Aim of the project
The aim of the thesis project is to define an agent-based environment for discovery of BOMs
based on predefined search criteria and presentation of different combination of components
that match the description. On each combination, the composition rules are applied (as proposed
by [6]) to calculate their syntactic and semantic composability degree so that they are validated by
a simulation modeler for later use. The work has been exemplified with a simple implementation
and using a real world Test Scenario: �The Restaurant Scenario�.
1.4. Statement of the problem:
The problem statement can be divided into three parts:
Part1:
6
Component-based Reusability: Utilization of pre-existing components when developing
complex software systems is increasingly applied within the software industry. Component-based
model development has been a long-term goal within the M&S community to increase reuse and
availability of simulation models. An initial work has already been done to investigate the
possibilities of component reusability, and it has been established that different components can
be composed together and by uniting them we can reuse them in different simulation scenarios.
Part2:
Composability: However, composing sub-models in order to build new models raise the non-
trivial issue of composability. There are two types of composability, syntactic and semantic.
Syntactic composability is concerned with the compatibility of implementation details, such as
parameter passing mechanisms, external data accesses, and timing mechanisms. It is the question
of whether a set of components can be combined. Semantic composability, on the other hand, is
concerned with whether the models that make up the composed simulation system can be
composed and remain valid. Some research has already been in progress to find out the
composability degree of two candidate BOMs and based on certain rules we can evaluate whether
they are composable or not.
Part3:
Agent-based environment: Now that we have a set of rules to find out a match between the
two or more BOMs so we can setup a multi agent-based environment in order to perform
automated discovery of related BOMs specified in a given simulation scenario (SRML), and an
intelligent way of performing the composition rules of different combinations of the candidate
BOMs (that have been discovered so far from the repository).
The process can even be improved by involving agents to be able to lookup the semantic aspects
of different BOMs in their attached ontology descriptions, and thus can perform semantic
matching on the fly. Furthermore a multi.-agent system can be designed to perform the
operations by introducing parallelism to increase the performance of the system.
7
To summarize the problem statement:
1. Can an agent-based system be used to traversing through the 7 step process which was
developed at FOI for discovery and composition of simulation components, [6] and
automatically determine if a set of BOMs are syntactically and semantically compatible according
to a given simulation model scenario?
2. How can agents be used to perform semantic matching given a set of OWL description of
BOMs?
8
1.5. Purpose of the study:
The purpose of this study is to contribute to the development of a run-time environment for
distributed multi-agent framework that is capable of the following:
1. Capable to co-ordination among various internal agents for co-operative distributed problem
solving.
2. Communication with various existing systems such as SDR [8]
3. Capable of integrating with various domain onthologies to perform semantic matching
4. Providing simulation modeler a graphical interface to input investigation data.
5. Capable of publishing the test results
This framework is desired to be used in ongoing research activities being held at FOI. So its
structure should be easily configurable and adaptable to changes.
9
C h a p t e r 2
2 . B A C K G R O U N D
2.1. Description of Terms:
Before we move on to the description of system design and implementation it is necessary to
define some technical terms that are commonly used/comprehended by the people of this
domain.
2.1.1. BOM-Base Object Model:
It is highly recommend to studying BOM specification [9] for anyone who is more interested in
this work. A brief overview of BOM concept is however given as below:
Concept of BOM is proposed by SISO [10] and it provides �a component framework for
facilitating interoperability, reuse, and composability�. BOM is an XML document containing the
�essential elements for specifying aspects of the conceptual model and documenting an interface
of a simulation component that can be used and reused in the design, development, and
extension of interoperable simulations�. The authors of BOM were intended to introduce the
BOM as a building block in the development and extension of a simulation and/or a federation
of simulations [9].
BOM is organized into four major parts:
1. Model Identification
2. Conceptual Model
3. Model Mapping
4. HLA Object.
10
They are briefly described in detail below. More details can be found at [6] and [9].
Model Identification
Metadata about the component is stored in this part. It includes Point of Contact (POC)
information, as well as general information about the component itself � what it simulates, how it
can and has been used as well as descriptions aimed towards helping developers find and reuse it.
Other information such as intended application domain, the purpose of component, Use History
and Use Limitation, which includes a list of all successful and unsuccessful inclusion of this BOM
in other simulations, would be part of the meta-data. It also provides the possibility to include
references to other documents (e.g. an OWL document) or BOMs used in the creation of this
component.
Conceptual Model
�Conceptual Model Definition provides a mechanism to identify up to the following four
different template components for representing the needs of a simulation:
Pattern Of Interplay
State Machine
Event Type
Entity Type
2.1.1.1 . Pattern of Interplay
�A pattern of interplay is represented by one or more pattern actions needed to accomplish a
specific purpose or capability� [9]. The Pattern Action is described by Pattern Description. The
pattern Description provides a table of all actions taken by the component, and describes what
conceptual entities and events take part in the action as well as lists a number of variations and
exceptions to the action that could happen. Each pattern action has one or more senders and
11
receivers providing a means for understanding the behavioral relationship among conceptual
entities, which are defined by entity types. The activity required for fulfilling each pattern action
can be associated with either an event type, or another BOM.
2.1.1.2 . State Machine
�The state machine template component provides a mechanism for identifying the behavior
states expected to be exhibited by one or more conceptual entities [9]. It lists all states in which
entities can be in, and state transitions (what conditions must be satisfied in order to exit the state
� via a specified action � into a next state). It provides a clear overview to the BOM composer of
how a federate that is implemented from a BOM will behave. Also state-machine can be used to
validate the BOM component by comparing it with reality.
2.1.1.3 . Entity Type
�A conceptual entity is an abstract representation of a real world entity, phenomenon, process, or
system. These conceptual entities are needed to understand the relationships within a pattern of
interplay, the roles with respect to state machines across one or more patterns of interplay, and
the responsibilities as sender and/or receiver in regards to the events that can occur to fulfill a
pattern of interplay�. Attributes of the conceptual entity types are presented in the BOM entity
type structure.
2.1.1.4 . Event Type
Each pattern action is supported by either an event or another BOM. Event Type contains a
listing of the Events present in the BOM. There are two different types of Events: BOM Trigger
and BOM Message. A BOM Trigger is an undirected event that is triggered by some entity
without a specific receiver. In other words, the entity sending out a Trigger does not care about
who receives a notification of the event. This might for example be a bomb exploding triggering
a blast wave. BOM Event, the next type, is an event sent from one conceptual entity directed to
12
another specified entity. Unlike BOM Trigger, this type of event is precisely directed to another
entity. The entire structure of a typical BOM can be seen in the following figure:
Figure 2 BOM Conceptual Model, as described in [9]
2.1.2. SRML
The Simulation Reference Mark-up Language (SRML) is based on XML that was developed by
the World Wide Web Consortium with support from the Boeing Company. It is an XML
application that can describe the behaviour of distributed simulation models, and its runtime
environment is software that is capable of executing those models [10]
SRML was developed with a number of goals, among them being a flexible reference standard
for representing simulations with enough expressive power to model almost anything for the
purpose of simulation.
2.1.3. SDR:
Semantic Distributed Repository was designed and developed for secure sharing of simulation models,
components and related resources such as computer resources. It consists of an overlay
architecture based on the technologies like Semantic Web, Peer-to-Peer and Grid techniques.
This project at the Swedish Defense Research Agency (FOI) has served the need for a repository
of simulation related resources. [8]
BOM Type
Pattern of Interplay
State Machine Entity Type
Event Type
Conceptual Model Definition
0..10..1
1..n1..n1..n1..n 1..n1..n
1..n1..n
13
2.1.4. Onthologies:
Ontology is a study of conceptions of reality and the nature of being. In philosophy, ontology
is the study of being or existence and forms the basic subject matter of metaphysics. It seeks to
describe or posit the basic categories and relationships of being or existence to define entities
and types of entities within its framework.
Ontology mainly deals with the precise utilization of words as descriptors of entities or realities
and ontology must give an account of which words refer to entities, which do not, why, and
what categories result. When one applies this process to nouns such as electrons, energy,
contract, happiness, time, truth, causality, and God, ontology becomes fundamental to many
branches of philosophy [11]
A commonly accepted definition of ontology as given by [12]:
�Specification of a representational vocabulary for a shared domain of discourse� definitions of
classes, relations, functions and other objects.�
Onthologies are used to share knowledge between people, business enterprises and information
systems. Onthologies are also a vehicle for establishing a consensus between diverse groups of
people, management or heterogeneous and distributed information systems.
2.1.5. OWL:
The Web Ontology Language (OWL) is a language for defining and instantiating Web
onthologies. OWL ontology may include descriptions of classes, along with their related
properties and instances. OWL is designed for use by applications that need to process the
content of information instead of just presenting information to humans. It facilitates greater
machine interpretability of Web content than that supported by XML, RDF, and RDF Schema
14
(RDF-S) by providing additional vocabulary along with a formal semantics. OWL is based on
earlier languages OIL and DAML+OIL, and is now a W3C recommendation.
OWL is seen as a major technology for the future implementation of a Semantic. It is playing
an important role in an increasing number and range of applications, and is the focus of
research into tools, reasoning techniques, formal foundations and language extensions. OWL
was designed to provide a common way to process the semantic content of web information. It
was developed to augment the facilities for expressing semantics (meaning) provided by XML,
RDF, and RDF-S. Consequently, it may be considered an evolution of these web languages in
terms of its ability to represent machine-interpretable semantic content on the web. Since
OWL is based on XML, OWL information can be easily exchanged between different types of
computers using different operating systems, and application languages. Because the language
is intended to be read by computer applications, it is sometimes not considered to be human-
readable, although readability can be enhanced by the use of certain viewers. OWL is being
used to create standards that provide a framework for asset management, enterprise
integration, and data sharing on the Web. [11]
2.1.6. Intelligent Agents:
According to Wooldridge [13]:
�An agent is a computer system that is situated in some environment and that is capable of
autonomous action in this environment in order to meet its design objectives�.
2.1.7. Multi-agent System (MAS):
A multi-agent system contains a number of agents which interact with one another through
communication. The agents are able to act in an environment; where each agent will act upon
or influence different parts of the environment. They interact with each other to solve large
problems, to allow interconnection and interoperation of multiple entities of a system, to
15
provide a solution to inherently distributed problems, to provide solutions which draw from
distributed information sources and to provide solutions where expertise is distributed [13].
2.1.8. Discovery and Composition process work flow:
The basic steps in the process of the discovery and composition are proposed by the previous
researchers [4], [6]. The approach comprises of four phases:
SRML Parsing
BOM Discovery
BOM Matching and Composition
BOM Assembly Building
Each phase starts whenever the previous phase finishes. These four phases altogether make
seven steps:
1. The simulation scenario is parsed and then the candidate components identifications are
extracted from simulation scenario. The simulation scenario is written in SRML Light standard,
so its validity according to SRML scheme also might be checked. The �Item Class �tag is used as
a heuristic to identify and extract the type of candidate BOMs. The output of this step would be a
collection of syntaxes (identification/name of component + events sent/received by the
component) for possible BOM candidate .We call this collection SRML Object Model. (SRML
parsing phase)
2. A query is built based on the SRML Object Model and then it is applied to BOM repository. The
repository returns a collection of potential candidates according to the query. (Discovery phase)
3. The syntax (number of parameters and event name) and semantic (parameter data type and entity
type) of candidate components is filtered by comparison with those in SRML object model.
(Discovery phase)
16
4. Since there might be more than one candidate for each BOM, the composer makes a
permutation set of candidates. The composer adjusts the permutations based on received
feedbacks form syntactic and semantic BOM matching. The steps 5, 6 and 7 are done for each
permutation set. (Matching and Composition phase)
5. For each interaction, stated in simulation scenario, the syntax of message and action between
involving BOMs in the interaction is verified. If the BOMs have consensus on syntactic
composition, the semantic of BOMs is compared against each other based on the interaction.
(Matching and Composition phase).
6. If the syntax and semantic of all BOMs in the set are correct, the state machine composition
starts. The state machines of all candidates in that permutation set are run according to
simulation scenario interactions. In a successful run, all interactions mentioned in the scenario
appear in some order. It means that events passed between components will result in successful
state transition. So the order of action executions can be obtained.(Matching and Composition
phase)
7. By having in hand a right set of candidates, their interactions and the order of interactions, a
BOM assembly can be created from the current set of BOMs.
17
Figure 3 Discovery and Composition process work flow [6]
C h a p t e r 3
3 . A G E N T B A S E D F R A M E W O R K
3.1. Overview:
In the following chapter we will mainly discuss the details of Agent-Based system, their
architectures and environments. This chapter does not focus on theoretical details of an agent
system but some technical terms will be briefly described. However more interested readers will
find the citations and reference quite useful to study the topic in depth.
3.2. Agent Oriented Software Engineering
Agent-oriented software engineering is a next generation software modeling paradigm that
arose from research in distributed artificial intelligence and co-operative distributed problem
Simulation Idea
High Level SRML Document
SRML Parsing
BOM Discovery
BOM Semantic and Syntactic Matching
BOM Repository
Semantic of BOM Assembly
BOM Composition
18
solving. It addresses the need for software systems to exhibit rational, human-like behavior in
their domains of expertise. Traditional software development approaches are difficult to use for
building complex intelligent systems that posses multiple behaviors when operated in real-time
environments.
Agent oriented programming is highly suited to many application areas, including IT business
systems, military command and control, intelligent manufacturing, robotics, modeling and
simulation. Although still young and under development, this programming paradigm has
already demonstrated particular promise in a variety of distributed problem solving tasks such
as fleet organization, air traffic management and air combat simulation. Because of its ability to
handle complex programming challenges such as coordinated reactive processing, agent-
oriented programming is ideally suited to these environments [14].
3.3. What is an Agent?
Before we continue our discussion about the framework, I will take this opportunity to define
and agent and an agent framework in a more formal way.
The term agent is normally used to describe a range of software components that are used to
automate computational tasks such as information search, discovery or retrieval based on a
particular plan and finally capable of reasoning their moves in a well-defined way [14].
3.4. What is an Agent Framework?
An agent framework is a development & runtime environment inspired by specific agent
architecture that is used to develop a variety of simple and complex agents and also is used to
19
populate different instances of those agents. These agents live in that environment, they age
(get mature), act and react to their environment and die. The framework can conceptually be
taken as an API or programming library but it is more than just that. It is a runtime
environment for complex behavioral software entities that are artificially intelligent [14].
3.5. JACK Agent Framework:
During my research at FOI I have evaluated various agent frameworks (including Jade and
JadeX), but I considered JACK Agent Framework by Agent Oriented Software Pty. Ltd [14] to
be the best fit for the implementation of the problem under study. Out of many other reasons
that can be found in the technical manual following is the most important and worth
mentioning:
JACK framework was mainly design to serve in the area of Defense Modeling and
Simulation and its application in this domain include:
Plan based decision support
Modeling Complex Human Behavior in Defense simulations
Command and control information system resource coordination
3.6. Jack Agents:
The agents used in JACK are intelligent-agents; we will refer them as JACK agents. They model
reasoning behavior according to the theoretical Belief Desire Intention (BDI) architecture of
distributed artificial intelligence (DAI). They are autonomous software components that have
explicit goals to achieve or events to handle (desires). To describe how they should achieve
these desires, BDI agents are programmed with a set of plans. Each plan describes how to
achieve a goal under varying circumstances. When executed, the agent pursues its given goals
(desires), adopting the appropriate plans (intentions) according to its current set of data
20
(beliefs) about the state of the world. This combination of desires and beliefs initiating
context-sensitive intended behavior is part of what characterizes a BDI agent. [15].
A JACK agent is a software component that can exhibit reasoning behavior under both
proactive (goal directed) and reactive (event driven) stimuli. Each agent has:
1. A set of beliefs about the world
2. A set of events that it will respond to
3. A set of goals that it may desire to achieve (either at the request of an external agent, as a
consequence of an event, or when one or more of its beliefs change)
4. A set of plans that describe how it can handle the goals or events that may arise.
When an agent is instantiated in a system, it will wait until it is given a goal to achieve or
experiences an event that it must respond to. When such a goal or event arises, it determines
what course of action it will take. If the agent already believes that the goal or event has been
handled (as may happen when it is asked to do something that it believes has already been
achieved), it does nothing. Otherwise, it looks through its plans to find those that are relevant
to the request and applicable to the situation. If it has any problems executing this plan, it looks
for others that might apply and keeps cycling through its alternatives until it succeeds or all
alternatives are exhausted.
21
3.7. Components of Jack Framework:
3.7.1. The JACK Agent Language
The JACK Agent Language is the actual programming language used to describe an agent
oriented software system. The JACK Agent Language is a super-set of Java � encompassing
the Java syntax while extending it with constructs to represent agent-oriented features. [14]
3.7.2. The JACK Agent Compiler
The JACK Agent Compiler pre-processes JACK Agent Language source files and converts
them into pure Java. This Java source code can then be compiled into Java virtual machine
code to run on the target system. [14]
3.7.3. The JACK Agent Kernel
The JACK Agent Kernel is the runtime engine for programs written in the JACK Agent
Language. It provides a set of classes that give JACK Agent Language programs their agent
oriented functionality. Most of these classes run behind the scenes and implement the
underlying infrastructure and functionality that agents require, while others are used explicitly
in JACK Agent Language programs, inherited from and supplemented with callbacks as
required to provide agents with their own unique functionality [14].
The following figure illustrates the overall process of Jack agent development. Agent code is
written in the Jack Agent Language (JAL) which is compiled by Jack Complier and is
executed in a run time environment called Jack Run time.
22
Figure 4 JACK Process (a. Jack Language b. Jack Compiler c. Jack Runtime)
3.7.4. Jack Code Entities:
Following are the type of Jack code entities or classes that are required to form a Jack Agent.
To re-phrase, a typical Jack Agent needs the following resources (code snippets), to be able to
run in a Jack environment:
a. JACK event (.event)
b. JACK plan (.plan)
c. JACK agent (.agent)
d. JACK capability (.cap)
e. JACK view (view)
f. JACK belief set (.bel)
g. Other Java code (.java)
This can be seen in the following diagram:
Jack AgentLanguage (JAL)
Code
Jack
Compiler
JVM
Jack Kernel
Jack Agent container
We will only describe them briefly. Again details can be seen from the
[14].
3.7.4.1. Agent Class
The Agent class embodies all the functionality associated with a JACK intelligent agent.
agent should fully describe the functionality it implements via JACK Agent Language
definitions. In general, this definition needs to include the following conceptual statements:
� Belief Sets and Views which the agent can use and refer to.
� Events (both internal and external) that the agent is prepared to handle.
� Plans that the agent can execute.
� Events the agent can post internally
� Events the agent can send externally
23
Figure 5 Jack Agent entities
We will only describe them briefly. Again details can be seen from the Jack reference manual
The Agent class embodies all the functionality associated with a JACK intelligent agent.
agent should fully describe the functionality it implements via JACK Agent Language
In general, this definition needs to include the following conceptual statements:
which the agent can use and refer to.
(both internal and external) that the agent is prepared to handle.
that the agent can execute.
internally (to be handled by other plans).
externally to other agents.
reference manual
The Agent class embodies all the functionality associated with a JACK intelligent agent. An
agent should fully describe the functionality it implements via JACK Agent Language
In general, this definition needs to include the following conceptual statements:
24
3.7.4.2. Capability Class
Capabilities represent functional aspects of an agent that can be plugged in as required. This
capability as component approach allows an agent system architect to build up a library of
capabilities over time. These components can then be used to add selected functionality to an
agent.
3.7.4.3. Event Class
Events motivate an agent to take action. There are a number of event types in JACK, each with
different uses:
Internal stimuli � events that an agent sends to itself, usually as a result of executing reasoning
methods in plans that an agent has. These internal events are integral to the ongoing execution
of an agent and the reasoning that it undertakes.
External stimuli � such as messages from other agents, or percepts that an agent receives from
its environment
Motivations � which the agent may have, such as goals that the agent is committed to achieving.
Events are the origin of all activities within an agent-oriented system. In the absence of events
an agent sits idle. Whenever an event occurs, an agent initiates a task to handle it. This task can
be thought of as a thread of an activity within the agent. The task causes the agent to choose
between the plans it has available, executing a selected plan or plan set (depending on the event
processing model chosen) until it succeeds or fails.
3.7.4.4. Plan Class
The Plan class describes a sequence of actions that an agent can take when an event occurs.
Whenever an event is posted and an agent adopts a task to handle it, the first thing the agent
does is try to find a plan to handle the event. Plans can be thought of as pages from a
procedures manual. They describe, in explicit detail, exactly what an agent should do when a
given event occurs. Equipped with a set of plans, an agent has a set of skills and procedural
25
knowledge that it can draw upon as required. When the event that a plan addresses occurs, the
agent can execute this plan to handle it.
3.7.4.5. Belief set Relations
Belief sets are used in JACK to maintain an agent's beliefs about the world. An agent's belief
set can be stored as either an �Open World� or a �Closed World� class. �Open world� can be
defined as an environment where an agent can come across agents which he might or might
not know before and in closed world an agent can always encounter agents he always know or
can recognize.
The belief set represents these beliefs in a first order, tuple-based relational model.
3.8. JACK Development Environment (JDE)
The JACK Development Environment (JDE) is a cross-platform graphical editor suite written
entirely in Java for developing JACK agent and team based applications. The JDE allows the
definition of projects, aggregate agents and teams, and their component parts under these
projects [16].
A screen shot of JDE environment is shown in the following figure:
26
Figure 6 Jack Development Environment [16]
3.9. JACK Framework Workflow:
A typical JACK project workflow can be described in the following steps:
1. An agent is created, given an agent name and a Plan and an Event. The agent can either Posts
that event, or it handles it. Agent uses the Plan and that Event Handles the Plan. This
triangular relationship can be view as follows:
27
Figure 7 Jack Agent Workflow
2. Once this is ready, we can compile all the above as a capability component and add it in a
capability library e.g., in the above example and agent is posting as well as handling a parse
event and it has a parse plan to execute. So we can this parsing capability and it can be
compiled in a component �Parser�.
3. In a multi-agent system, we usually do not post and handle events by the same agent at a
time. So one agent will post an event and other (has a capability) to handle it. Once the event
is handled we can let the agent send/receive more events (message events) to the requestor
or to some other agent. This is how a process of co-operative co-ordination can be executed.
This message handling can be done within the same machine or across the network. JACK
kernel is completely capable of handling network communication. In a typical multi-agent
system we normally program a manager agent that is instantiated from a main java program
and it can delegate different tasks to different agents according to their expertise. This can be
stored in the Plain of Manager agent. The other agents can take tasks from the manager and
report the results to the same. We can allow them to negotiate among each other for the task
distribution (a famous Distributed Agent Programming problem) or have them in
28
communication/co-ordination to solve complex problems. Furthermore agents can increase
performance while solving a computation task by applying techniques of parallelism.
29
C h a p t e r 4
4 . I M P L E M E N T A T I O N P R O T O T Y P E
4.1. Software development approach
The software development approach that was mainly kept in focus for the implementation of the
agent-based framework was �Modular approach�. Since it is already a study of component
reusability, so it was favorable to design the system in the same fashion in order to inherit the
working environment of the facility
There are two perspectives of seeing the system architecture:
A. Horizontal Perspective (This will indicate the modules system contains)
B. Vertical Perspective ( This will indicate the layers system is comprised of)
The following diagram indicates the overall system architecture based on the above two
perspectives. Here the rows can be seen as system layers: Presentation layer, Business logic Layer
and data layer where as the columns depict the different modules that are programmed to make
the entire process functional. Following are the modules (which will be explained later):
Presentation Module Query Module Combination Module Composition Module Comparison Module Virtual SDR
Each element in the figure has its place i.e., if in middle row and left column, it means it�s a business object related to presentation module. There are different icons to represent the type of object.
Figure 8 System Architecture
31
4.2. System class diagram:
The following system class diagram in Figure 9 explains the basic modules of the core system.
(The core system refers to that part of the system which actually deals with the business logic)
4.2.1. Query Manager:
This module performs SRML parsing and constructs appropriate query, which is then sent to
the SDR for BOM discovery. In our case of implementation we have devised a virtual file
based SDR that emulates the functions of the real SDR present at the facility. This module is
also responsible to filter the discovered BOMs based on the discovery matching rules
4.2.2. Combination Manager
After the discovery the combination module forms all possible statistical combinations of the
selected BOMs. We will refer each combination as a compound from here onwards.
4.2.3. Composition Manager
In this module each compound will pass through a set of rules and will be given a
composability score based on its syntactic and semantic properties.
4.2.4. Comparison Manager
All the scores will be collected by the comparison manager and will be compared and sorted
to form a result sheet.
4.2.5. Presentation Manager
The result sheet formulated by the comparison module will be published by this module.
33
Since each of the above modules is constructed in an agent based environment, following are the
different use cases (Figure 10) assigned to each agent. An important thing to note is, though
agents are programmed routines, but we are referring them as Actors because technically agents
are considered to be actors in the system. They have an autonomous decision making for
action/reaction based on some events. For details please refer to [13].
34
Figure 10 Use case Model
4.3. Sequence Diagram:
The sequence of actions can be viewed from the following diagram:
36
In order to understand the sequence diagram, we need to know the different data types that were
defined to exchange data objects between different agents. They have been defined inform of
java beans. Following is the hierarchy that shows the Bean and sub-beans with in the bean:
SRMLInfo: o List [ItemInfo Items]
String ItemName List [ScriptInfo scripts]
o String name o String type o String[] parametes
List [SinkInfo sinks] String name String events
37
BOMInfo:
o String name o String version o String securityClassification o String description o String glyph o List [EntityInfo entities]
String Name List [String characteristics]
o List [EventInfo events] String Name String source String target List [String characteristics]
o List [PatternOfInterplayInfo poi]
String name List [ActionInfo actions]
String sequence String name String event String sender String receiver
o List [StateMachineInfo SM]
String name List [EventInfo events] List [StateInfo States]
String name String exitcondiction
They are used to carry all the data parsed from a BOM XML and later from OWL. From the
above sequence diagram (figure 11) it is clear that the server initiates a Parse request which is
severed by Parser Agent who instantiate an SRMLInfo bean and it forwards it to the discovery
38
agent which in turn reads the bean, and for each entity in the bean sends a query request to the
SDR, which returns a list of BOMInfo beans. These are further filtered by the discovery agent
and then are handed over to the Combination Agent. It creates all possible combinations that are
sent to the composition agent for matching. Each matching operation returns a score that is
collected by the comparison agent. Finally a list of scores is sorted and published to the presenter
4.4. Jack Agent framework:
The following section will describe the implementation of the Jack Agent Framework on top of
the core system. As it has already been explained in the previous chapter the Jack agent system is
a shell that is running on top of a Jack Kernel
The entire working of Jack agent framework is explained as follows:
4.4.1. Initialization:
The entry point of execution of this shell is a Main.java program that initiates the call to the
Manger agent. This agent is further responsible to govern all the tasks.
Please note that this �Manager Agent� term should not be confused with the system design of
Query Manager, Composition Manager etc. These are the modules and are formed based on the
convention used in Model Driven Component development where as the Manager Agent is the
Agent programmed to govern all the tasks.
The rationale to use a centralized approach in handling all the tasks is to accommodate
parallelism. This part contains all the initialization code. Normally in a typical multi-agent system
environment, it is important to populate agents in the agent container with their default metadata.
In our case we have agent names.
39
4.4.2. Parsing:
Once the agent manager is instantiated, it calls the presentation module to display input GUI for
locating an SRML file. When the user specify an appropriate SRML file, the Manager agent posts
a parse event to the Parser Agent, who has the capability to handle this event based on a parse
plan. When this event is posted the parser agent is actually running an XML file parser routine
specified by the basic parse plan and the entire SRML file is parsed and extracted in the memory
in form of SRML bean. This bean is designed to carry the entire SRML elements & attributes.
Thus it can be used to carry the SRML data which can be exchanged by various agents.
Once an SRML file is parsed the �posting method� , the method which is called when a post
event is handled, will return the SRML object to the Manager agent.
4.4.3. Discovery:
The manager agent can then send a request message to discovery agent to perform discovery on
all the entities identified so far from the parsing of the SRML file. This agent can further query
our virtual SDR and retrieve a list of BOM.
4.4.4. Virtual SDR:
In order to complete the implementation of the agent framework it was desired to emulate the
SDR locally in the system [instead of connecting directly to the real SDR due to confidentially
reason] thus we have devised a file-based SDR that contains XML and OWL files for each BOM.
When the Virtual SDR is initialized, it reads all the XML files stored in the disk and collects the
BOMS in a data structure, that is capable of performing search operations (similar to real SDR).
I have also contributed in the design of the OWL description schema for each BOM. The
following OWL classes were proposed that can be used as a schema for the OWL description:
40
Figure 12 Owl Description
This OWL description is a replica of BOM structure but in form of OWL class hierarchy. We
needed this to write the OWL description of BOMs. Based on the above class hierarchy we
developed instances (also known as individuals) for each BOM discussed in the Test case study.
This ontology attachment proved to be very successful in applying composition rules. In order to
connect to the ontology attachment document, Jena API was used. The following basic code
explains how to connect to a specific BOM OWL description:
public OntModel loadOWL(String pathToFile){ OntModel model = ModelFactory.createOntologyModel(OntModelSpec.OWL_MEM ); InputStream in = FileManager.get().open(file); if (in == null) { throw new IllegalArgumentException( "File: " + file + " not found"); } model.read(in, ""); return model; }
41
Since it is a file based ontology model, so we input an OWL file source and the above method
returns an Ontology Model which can further be used by Jena iterater to traverse and lookup or
compare for two different objects/entities or instances of the BOM.
So the query is constructed and handed over to the Discovery agent. This agent process the
discovery in two passes.
a. Simple discovery:
In the first pass, the BOMs are fetched only on the basis of criteria given by the manger
agent. It is quite possible to get a large number of BOMs in this step.
b. Filtration:
In the second pass, a filtration is performed based on the following discovery rule set:
Discovery Layer
Feature to be checked What is checked Rule
Syntactic
Action Event Name Rule-1
Message Number of parameters Rule-2
Semantic Entity Entity Type Rule-3
Message Data Type Rule-4
Figure 13 Discovery Rules [6]
After the filtration, the BOMs are collected in a list of Array and are sent back to the Manger
Agent. Manager agent is then responsible to put them into appropriate groups based on the
BOM classes (as identified from the Ontology of a given scenario and then SRML document).
When this re-grouping is done it will post a request to combination agent to perform the
combinations
42
4.4.5. Combinations:
The manager agent then employs a combination agent to perform all the possible statistical
combinations on the BOMs, which will run a routine and create all possible combinations. The
compounds are returned to the manager in form of an array list.
4.4.6. Composition:
Now finally the manager agent is ready to evaluate each compound for the composability degree,
so it sends request to the composition agent one by one for each compound and waits for the
score. The composition agent picks up the compound and start applying all the rules to evaluate
the composability degree. Following is the list of rules that are applied:
Composition Layer
Feature to be checked What is checked Rule Weight
Syntactic
Action
Event Name Rule-1
Mode In/Out
Binding Horizontal Message Number of parameters Rule-2 W2
Static Semantic
Action
Entity Type(Source & Target of Event
Rule-3 W3
Event Type N.A
Message Unit Rule-4 W4
Data Type Rule-5 W5
Business Role Rule-6 W6
Dynamic Semantic
State Machine of Composition ( State machines + Pre/Post
conditions on events)
Plug-in Pre matching is checked
Rule-7 W7
Figure 14 Composition Rules [6]
It is recommended for the readers to take a look at Syntactic and Semantics Model
Composability based on BOMs [6] for further information of the composition technique.
Jena OWL API is used inside the code body of Composition Agent in order to traverse in the
OWL description of BOMs and be able to perform semantic matching. These rules are applied
43
in the recursive order, i.e., when there is a match it continues to the second rule and then next
and then so on until it finally declares the two candidates to be composable. See the following
diagram for the process of composition.
Match A,B
Rule 1
Rule 2
pass
Rule 3
Rule 4
pass
Reason
fail
pass
Reason
Reason
fail
fail
Rule 5
passReason
fail
Score Calculation
Score
Figure 15 Composition Logic
Once the composition score is calculated it is returned to the manager agent. Since this
composition operation is done for each compound so both the agents are involved in a loop
until all compounds are scored.
44
4.4.7. Comparison:
The manager agent sends all the scores to the comparison agent who can sort the list according
to the logic defined by the simulation modeler and then publish the result accordingly
The following diagram illustrates the entire process in detail.
From the figure, it is clear that the Manager Agent first posts a parse request to the Parser Agent.
This is posted in form of a �Parse Event�, because either the Parser Agent might be idle at that
time or is busy in some existing task to finish. So when the Parse Event is posted Parser Agent
will be updated about the request and it will serve it by invoking its posting event , which in our
case is doParse(). This method will return a SRMLInfo bean back to the Manger Agent. Manager
Agent then updates its global variable for the SRMLInfo.
Then the Manager Agent posts a discovery request to the discovery agent which in turn performs
the discovery for each entity in the SRML bean and fetches the results from the SDR. It then
filters the irrelevant BOMS from its collection based on the events specified in the SRML and
returns an array of filleted BOMs back to the Manager Agent.
Then Manager Agent re-groups all the BOMs according to their classes� and calls the
Combination Agent to perform combinations on each class, who returns a list of all possible
combinations. For each combination in the list, Manager Agent then employs a composition
agent to perform the composition and return the score, which is collected in a list. Once all the
compounds have their composition result the comparison agent prints the score list.
46
4.5. Future Improvements
We can also improve the design of the system by dividing events into two categories: Post-
Request Event and Post-Response Event, this will help in achieving parallelism in the entire
pipeline of the project and after posting the request events, the manager agent does not have to
wait for the response and can continue some other jobs. When the response event is posted by
the task performer, the manager agent can easily handle it by spawning a new thread. This can be
referred as future improvement of the system.
47
C h a p t e r 5
5 . T E S T C A S E S T U D Y
5.1. A Restaurant Scenario:
In order to test the system, we have worked on the restaurant scenario previously proposed in
the previous thesis [6]. This case study is basically a simulation model of a restaurant, which has
the following simulation components:
1. Customer
2. Waiter
3. Table
4. Queue
5. Kitchen (Chef)
The overview of the simulation scenario is as follows:
A customer walks in a restaurant and wants to take a seat. For that he has to join a waiting
queue. When his turn comes he is allocated a table. When he occupies a table, a waiter goes to
attend him and gives him a menu. The customer orders food from the menu. The Waiter places
the order to the kitchen. When food is ready he serves the food. When customer finishes eating
he asks for the bill. Waiter gets the payment (either by cash or by credit card). Then customer
leaves the restaurant. Waiter cleans the table. The table is ready for another customer.
Starting with the test, we have a Restaurant SRML document that contains the actual simulation
scenario a modeler wants to test. [A copy of the Restaurant SRML is attached in the appendix C]
We also have a collection of BOMs related to restaurant scenario in our Virtual SDR along with
their OWL description. Based on the scenario mentioned in SRML we can draw the following
48
sequence diagram to preview the actions/events being sent and receive between the simulation
components:
Figure 17 Restaurant Sequence Diagram [6]
A : Customer
: Waiter : Queue : Table : Chef
Occupy(CustomerID)
RequestMenu(CustomerID)
GiveMenu(CustomerID, Menu)
Join(CustomerID)
TakeSit(TableID, CustomerID)
OrderFood (SelectedFood, CustomerID)
ServeFood(SelectedFood)
FoodReady(SelectedFood)GiveFood(SelectedFood)
AskBill(CustomerID)
GiveBill(Bill)
PayBillByCreditCard(CreditCard, Bill)
AskForSignature(Receipt)
Release(CustomerID)
CleanTable(TableID)
TableIsClean()
TableIsFree(TableID)
JoinAck(PlaceNo)
SignReceipt(Receipt)
49
5.2. Output of the test:
Now by running the Restaurant SRML scenario in the agent based system, we can see the
following outputs:
5.2.1. Step 1:
As a first step of the program execution, it asked for the SRML file. When importing the
appropriate file, it started parsing it and finally displayed the following tree graph of figure 18,
showing the entities, events, actions and parameters found in the SRML as follows:
Figure 18 Output Step 1: Parsing
(The folder means it has a child element. Page means it is a leaf)
50
5.2.2. Step 2:
In the next step, it sent a query for the following BOMs to the Virtual SDR:
Searching for: Customer
Searching for: Table
Searching for: Waiter
Searching for: Queue
Searching for: Kitchen
Following result was displayed after the discovery agent has finished searching Virtual SDR: 8 BOMs found for the entity: Customer
10 BOMs found for the entity: Table
9 BOMs found for the entity: Waiter
7 BOMs found for the entity: Queue
4 BOMs found for the entity: Kitchen
After applying the discovery rules, following BOMs were filtered: Apply discovery rules for filtration:
4 BOMS filtered for the entity: Customer
2 BOMS filtered for the entity: Table
3 BOMS filtered for the entity: Waiter
2 BOMS filtered for the entity: Queue
1 BOMS filtered for the entity: Kitchen
Figure 19 Output Step 2: Discovery
51
5.2.3. Step 3:
After the discovery the next step is creating combinations. Some of the combinations that were generated by the Combination Agent can be seen as below::
1. Customer1Table1Waiter1Queue1Kitchen1 2. Customer1Table1Waiter1Queue2Kitchen1 3. Customer1Table1Waiter2Queue1Kitchen1 4. Customer1Table1Waiter2Queue2Kitchen1 5. Customer1Table1Waiter3Queue1Kitchen1 6. Customer1Table1Waiter3Queue2Kitchen1 7. Customer1Table2Waiter1Queue1Kitchen1 8. Customer1Table2Waiter1Queue2Kitchen1 9. Customer1Table2Waiter2Queue1Kitchen1 10. Customer1Table2Waiter2Queue2Kitchen1 11. Customer1Table2Waiter3Queue1Kitchen1
Figure 20 Output Step 3: Combinations
5.2.4. Step 4:
After applying the composition rules, following output has been seen: TESTING BOM Customer1 WITH Table1
APPLYING RULE 1 : ********************************************************************************************** Release has a name match [EventNameA: Release <-> EventNameB :Release] Release has matched IN/OUT [Release_Action hasType Out <-> Release_Action hasType In] ********************************************************************************************** RULE 1 IS PASSED... ********************************************************************************************** APPLYING RULE 2 : ********************************************************************************************** EventA :Release has number of Parameters = 0 EventB :Release has number of Parameters = 0 ********************************************************************************************** RULE 2 IS PASSED... ********************************************************************************************** APPLYING RULE 3 : ********************************************************************************************** EntityType <-> EntityType EntityType <-> EntityType ********************************************************************************************** RULE 3 IS PASSED... ********************************************************************************************** APPLYING RULE 4 : ********************************************************************************************** Noparamater <-> Noparamater ********************************************************************************************** RULE 4 IS PASSED... **********************************************************************************************
Figure 21 Output Step 4: Matching
52
5.2.5. Step 5:
The final score for the BOM composability degree was calculated in the following steps:
1. All the events in each compound has an individual composability score which is calculated as
follows:
Syntactic Layer Score = If Rule 1 & 2 are true then 1 else 0
Semantic Layer score = [Rule-3 Score * w3 ]+ [Rule-4 Score * w4] + [Rule-5 Score *w5]
{w3, w4 , w5 = 1, 0.75, 0.25, 0} (6)
Total score for each event = Syntactic Layer Score + Semantic Layer score
2. Total score for each pair = Sum of All event score / N [Where N = no. of events]
3. Total semantic score of the whole compound = [total score of all the pairs / No. of pairs ]
4. Dynamic score of the whole compound = Score calculated by Jess Engine
5. Compsobility degree = Total semnatic score *0.5 + Dynamic Score*0.5
53
C h a p t e r 6
6 . C O N C L U S I O N & F U T U R E W O R K
6.1. Conclusion:
This research can be concluded with the following deductions:
6.1.1. With the help of Agent technology, we can not only match the components based on their
syntax, but also can evaluate their semantic context so that we can be assured of their
accurate functionality after they are composed.
6.1.2. As we have used a modular approach in designing and developing the agent environment,
we can always introduce new Agent Plans, beliefs and capabilities in order to deal with
more complex situations. Due to the modular approach used in the development of our
Agent system, it is an advantage that an agent (with multiple plans, beliefs and capabilities)
can decide, which plan he should proceed with to handle a particular situation. This can be
more useful when we are targeting complex simulation scenarios, with more rules and
constraints.
6.1.3. Ontology description associated with a particular simulation component, as proposed by
other researchers, proved to be a very useful tool to utilize by the agent system for being
able to perform semantic based discovery and matching.
6.1.4. Finally, the environment design is capable to be deployed on various platforms and on
various technologies. It can be executed in a single desktop machine or can be deployed
over a distributed network environment and can be executed across different machines. It
can also be hosted as a web service. But in that case an additional security layer (Agent-
Security) needs to be implemented.
54
6.2. Future Work:
This research initiative was just an effort to implement a basic agent-based framework that can
perform an automated discovery and composition of simulation components. There are a lot of
suggested improvements and future research. Some of them are stated as below:
6.2.1. The agent based system can be improved to keep the history of existing successful BOM
composition reports and reuse them to speed up the matching process. Already validated
combination can be retrieved from the history and could be considered for using with new
scenarios of similar nature.
6.2.2. Agent system can be redesigned to achieve parallelism in the matching pipeline. This
involves a great deal of negotiation, co-ordination and communication (which are already
known sophisticated features of Agent technology), to serve parallel tasks. This can help in
increasing performance up to a greater extent.
6.2.3. An automated SRML modeling GUI tool can be designed and incorporated with this
system in order to support the modelers. This can include a graphical library interface or
palette (actually connected to the SDR at the backend), that has components to choose
from and can be added in a graphical modeling canvas by drag & drop, and test their
interaction in various ways. Importing new onthologies and new BOM description in the
scenario can increase the number of possibilities for modeling complex simulation
scenarios.
55
R E F E R E N C E S
1. Fabian C Hadipriono Implementation of a virtual environment for traffic accident simulation. [thesis] 2003 .
2. Francis Neelamkavil Computer Simulation and Modelling . [Book : Wiley], 1990.
3. Farshad Moradi �Component-based Simulation Model using web services�, proceedings of the first Asia
International Conference on Modeling & Simulation, [Paper] 2007.
4. Peder Nordvaller �Composability and Reuse for Simulation Development using BOMs� [Thesis], IMIT-KTH, 2006
5. Mikel. D Petty, E. W. Weisel and R. R. Mielke �Overview of a Theory of Composability�, Virginia Modeling Analysis.. [Paper] 2004.
6. Shahab Mokherzadeh, Hossein Akbari �Syntatic and Semnatic Model Composibilty based on BOMs�.ICT-KTH, [thesis] 2007.
7. Farshad Moradi, Rassul Ayani, Peder Nordvaller, "Simulation Model Composition using
BOMs", in Proceedings of The 10-th International Symposium on Distributed Simulation and Real Time Applications, DS-RT '06, October 2006, Malaga, Spain.
8. Marianela Garcia Lozano, Rassul Ayani, Farshad Moradi, SDR - A Semantic
based Distributed Repository, in Proceedings of the first Asia Modelling symposium, AMS 2007, March 2007, Thailand.
9. BOM Guide version [Manual] 2006. http://www.boms.info/ 10. Group, SISO Product Development. Guide for Simulation Interoperability Standards Organization
(SISO). [Manual] http://www.sisostds.org/ 2006.
11. Edward N. Zalta Stanford Encyclopedia of Philosophy. [Book] 2003. 12. T. R. Gruber Toward principles for the design of ontologies used for knowledge sharing. [Report] 1993. 13. Michael Wooldridge. An Introduction to Multi-agent Systems. [Book], 2002. 14. AOS. Jack Agent Framework Manual. [Manual] http://www.agent-software.com 2006.
56
15. Nick Howden, Ralph Rönnquist, Andrew Hodgson, Andrew Lucas. JACK Intelligent Agents � Summary of an Agent Infrastructure. http://www.agent-software.com [Paper] 2001. 16. AOS. JACK� Intelligent Agents JDE Manual. http://www.agent-software.com 2006. 17. T.Berners-Lee, J.Handler and O.Lassila. The Semantic Web. Scientific American. 2001. 18. BOMworks. [Online] http://www.simventions.com/bomworks/.
57
I N D E X
A
agent based environment, i, iii, 32
API, 17, 38
B
BDI, 18 BOM, i, iii, i, iii, 5, 10, 11,
12, 13, 30, 36, 37, 46, 47, 48, 49, 52
C
Combination, i, 30, 45 Communication, i, 9 Comparison, ii, 30, 39 component, 2, 4, 5, 6, 7, 10,
11, 12, 18, 22, 24, 25, 28, 47, 48
Composability, i, iii, 5, 7, 38, 49
Composition Logic, i, 38 computer simulation, 1 co-operative, 9, 16, 26
D
Discovery, i, ii, i, 6, 27, 36, 44
distributed, 9, 13, 15, 16, 18, 47
E
Entity Type, 11, 12, 36, 37 Event Type, 11, 12, 37
F
FOI, iii, ii, iii, 6, 9, 18
H
HLA, iii, 10
I
Intelligent, i, 15, 49
J
Jack, i, ii, i, 18, 20, 21, 22, 24, 25, 35, 49
JACK Agent Compiler, i, 20 JACK Agent Kernel, i, 20 JACK Agent Language, i, 20,
22 JDE, i, 24, 49
M
Modelling, iii
O
Ontology, iii, 14, 37, 47 OWL), 14
P
Parsing, ii, i, 35, 43 Pattern Of Interplay, 11
R
Restaurant, ii, i, 6, 41, 42, 43, 52
Reusability, i, 4, 7 Rules, i, 36, 37
S
Semantic, 5, 6, 7, 14, 36, 37, 49
Simulation, i, iii, i, iii, 1, 3, 13, 18, 49, 52, 54
SRML, i, ii, iii, 8, 13, 30, 35, 36, 37, 41, 43, 48, 52
State Machine, 11, 12, 37
V
Virtual SDR, ii, 36, 41, 44
58
A P P E N D I X E S
1. Restaurant SRML
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!-- This is a Restaurant Model --> <Simulations> <Simulation Name="Restaurant"> <Script Name="SimulationScript" type="text/javascript"/> <!-- Defining The BOM Objects --> <ItemClasses Name="AllItemClasses" > <ItemClass Name="Customer" Source="the place of CustomerBOM"/> <ItemClass Name="Table" Source="the place of TableBOM"/> <ItemClass Name="Waiter" Source="the place of WaiterBOM"/> <ItemClass Name="Queue" Source="the place of QueueBOM"/> <ItemClass Name="Kitchen" Source="the place of KitchenBOM"/> </ItemClasses> <Items Name="AllItems" > <Item ItemClass="Customer" ID="c00" Source="the place of CustomerBOM"> <Script Name="CustomerScript1" type="text/javascript">PostEvent(Queue,Join,CustomerID);</Script> <EventSink Name="CustomerNeedsAcknowledge" EventClasses="JoinAck"></EventSink> <EventSink Name="CustomerNeedsTable" EventClasses="TakeSit"></EventSink> <Script Name="CustomerScript2" type="text/javascript">PostEvent(Table,Occupy,CustomerID);</Script> <Script Name="CustomerScript3" type="text/javascript">PostEvent(Waiter,RequestMenu,CustomerID);</Script> <Script Name="CustomerScript4" type="text/javascript">PostEvent(Waiter,OrderFood,Food,CustomerID);</Script> <EventSink Name="CustomerNeedsFood" EventClasses="GiveFood"></EventSink> <EventSink Name="CustomerNeedsMenu"
59
EventClasses="GiveMenu"/> <Script Name="CustomerScript5" type="text/javascript">PostEvent(Waiter,AskBill,Order); <!-- PostEvent(Waiter, Waiter_PayBillByCash, Cash, Bill); --> </Script> <Script Name="CustomerScript6" type="text/javascript">PostEvent(Waiter,PayBillByCreditCard,CreditCard,Bill);</Script> <EventSink Name="CustomerNeedsReceipt" EventClasses="AskForSignature"></EventSink> <EventSink Name="CustomerNeedsBill" EventClasses="GiveBill"/> <Script Name="CustomerScript7" type="text/javascript">PostEvent(Table,Release,CustomerID);</Script> </Item> <Item ItemClass="Table" ID="t00" Source="the place of TableBOM"> <EventSink Name="TableNeedsCustomerToOccupy" EventClasses="Occupy"></EventSink> <EventSink Name="TableNeedsCustomerToRelease" EventClasses="Release"></EventSink> <Script Name="TableScript1" type="text/javascript">PostEvent(Waiter,CleanTable,TableID);</Script> <EventSink Name="TableNeedsWaiterToClean" EventClasses="TableIsClean"></EventSink> <Script Name="TableScript2" type="text/javascript">PostEvent(Queue,TableIsFree,TableID);</Script> </Item> <Item ItemClass="Waiter" ID="w00" Source="the place of WaiterBOM"> <EventSink Name="WaiterNeedsCustomerToAskForMenu" EventClasses="RequestMenu"></EventSink> <EventSink Name="WaiterNeedsCustomerToOrderFood" EventClasses="OrderFood"></EventSink> <Script Name="WaiterScript1" type="text/javascript">PostEvent(Customer,GiveFood,Food,Order);</Script> <EventSink Name="WaiterNeedsCustomerToAskForBill" EventClasses="AskBill"></EventSink> <EventSink Name="WaiterNeedsCustomerToPayByCreditCard"
60
EventClasses="PayBillByCreditCard"></EventSink> <Script Name="WaiterScript2" type="text/javascript">PostEvent(Customer,AskForSignature,Receipt);</Script> <EventSink Name="WaiterNeedsTableToAskForClean" EventClasses="CleanTable"></EventSink> <EventSink Name="WaiterNeedsFoodFromKitchen" EventClasses="FoodReady"/> <Script Name="WaiterScript3" type="text/javascript">PostEvent(Table,TableIsClean);</Script> <Script Name="WaiterScript6" type="text/javascript">PostEvent(Customer,GiveBill,Bill);</Script> <Script Name="WaiterScript4" type="text/javascript">PostEvent(Customer,GiveMenu,CustomerID,Menu);</Script> <Script Name="WaiterScript5" type="text/javascript">PostEvent(Kitchen,ServeFood,Food);</Script> </Item> <Item ItemClass="Queue" ID="q00" Source="the place of QueuBOM"> <EventSink Name="QueueNeedsCustomerToJoin" EventClasses="Join"></EventSink> <Script Name="QueueScript1" type="text/javascript">PostEvent(Customer,TakeSit,CustomerID,TableID);</Script> <Script Name="QueueScript2" type="text/javascript">PostEvent(Customer,JoinAck,CustomerID,QueueID);</Script> <EventSink Name="QueueNeedsTableToFree" EventClasses="TableIsFree"></EventSink> </Item> <Item ItemClass="Kitchen" ID="k00" Source="the place of KitchenBOM"> <Script Name="KitchenScript" type="text/javascript">PostEvent(Waiter,FoodReady,Food);</Script> <EventSink Name="KitchenNeedsWaiterToAskForPreparingFood" EventClasses="ServeFood"></EventSink> </Item> </Items> </Simulation> </Simulations>
Top Related