- In this paper we present a new approach for using semantic web technologies in modeling and simulation. In recent years ontologies have been used popularly in many fields to represent and structure their concepts. This work is an attempt to create a specific ontology for the process oriented discrete event simulation domain. The ontology instances represent the model instances. This instance described in XML format and then transformed to another form that is used to generate the simulation code via XSLT rules. The code is generated according to the open source library Japrosim. The objective of this work is to enhance interoperability and automation of the transition from the ontology to the code execution.
INTRODUCTION
The web of today is basically syntactic and the
interpretation of the resources content is available only to
humans, the machine addresses only document structure.
Generally there is no rigid method for classifying semantic
content of Web documents. This is one of the reasons of the
development of semantic web. The Semantic Web is an
extension of the syntactic web, we add semantics layer, its
objectives to make the semantic content of Web resources
accessible by the software agents through a set of languages,
meta-data and formal knowledge representation tools. One of
the rich knowledge representation tools is the ontology, which
is a set of concepts based on the meaning of an information
field [
The use of ontologies is now become widespread because
many fields have used this technology like medicine,
architecture, geography and computing [
XML (eXtensible Markup Language) is a computer
language that allows structuring of information and promotes
the exchange of information on the Internet. It ensures high
interoperability in the exchange of models [
Today, technology developing and ambitions of researchers are increasing. One of these ambitions is the automatic code generation from a conceptual model, which is not something easy. It allows avoiding several error sources, save the time, and verifying the transition from conceptual model to the executable model with formal methods. With the definition of transformation rules, the passage from an XPISM instance to executable simulation code (especially Java) became possible, these rules are written using XSLT (extensible Stylesheet Language Transformation), which is a declarative language.
By carefully examining the course of our work, we build the domain ontology, the construction of the scheme XPISM and finally defining the XSLT rules to build the conceptual model and executable code generation, it will be obvious to see the interest of this work, which aims to enhance interoperability, define a standard vocabulary to represent concepts of simulation model, and full automate of the process of modeling and simulation.
In the next section, we present the motivation and use of ontologies in modeling and simulation. Section 3 presents the related work on the use of ontologies in process-oriented discrete event simulation. Section 4 is devoted to develop PIDESO ontology. Section 5 deals with devolved XML schema XPISM. In Section 6, we present the whole passage from domain ontology to exactable model and in section 7 a conclusion is given which focus on the path from the domain ontology to simulation executable.
II.
Simulation knowledge representation approaches require
the handling of highly structured knowledge, including
ontologies. Ontologies are useful in the process of modeling,
simulation and analysis cycle, particularly in the problem
analysis and in the conceptual model development [
The simulation model is often designed to achieve a set of
modeling objectives or respond to a set of questions. The
ambiguity of natural language is always a problem but
ontologies can help to facilitate the different tasks as described
below [
The process of constructing the conceptual model includes the
following activities: acquisition and analysis system
description, identification and classification of goals in
modeling, determining the roles of system objects, boundaries
and level of abstraction and the determining the model
structure and logic of it, [
Ontologies can facilitate the identification of inconsistency and incompleteness in a description of a system. For example, ontologies can be used to interpret the descriptive information on system objects.
An important step in developing the conceptual model is to determine the specific goals of the simulation study based on "the application of decision data" provided by the domain expert. This process of reasoning uses knowledge of the report and stresses in the system description (these are interpreted using domain ontologies).
The following tasks are performed once the specific aims of the analysis were established.
Establish the boundaries of the model: the first activity in the development of the conceptual model is to choose the part of the system under study. Establish the level of abstraction: A simple rule for determining the appropriate level of abstraction is to "include only those elements of a system that is able to meet the objectives and content and the level of abstraction as up ". Identify the roles of objects in the model: this step is to determine the model objects (resource, entity …), and the role of each object, for example queue 'x' is the activity therein '. 4)
The model structure and logic refer to the characterization of the relationship between activities in the model. An activity represents the dynamic behavior that occurs when objects interact one over the other. Ontologies play a key role in eliminating the ambiguity of interpretation of information contained in the description of the system to correctly understand the logical flow of objects and the decision logic in real-world process.
III.
The Process Interaction Modeling Ontology for Discrete
Event Simulation (PIMODES) [
PIMODES proposes a set of classes for models
representation, each model must be identified with a single
identifier and a clear description (annotation), the structure of
the model represented by a set of processes, a set of activities
and a graph of traffic control of entities [
Flowchart Nodes and Arcs Node #N1 Node #N2
Arc #C1 Arc #C2
Node #N3
Arc #C3
Node #N4 control flow rerperleastieonntsehdipby Activity #A1 takes place at
control flow rerperleastieonntsehdipby Activity #A2 takes place at
control flow rerperleastieonntsehdipby Activity #A3 takes place at control flow rerperleastieonntsehdipby Activity #A4 takes place at
The Demo (The Discrete Event Modeling Ontology) [
Automated code generation is a difficult task that falls
within the agile development movement. The generation of the
code is done automatically from a set of information (model,
meta-data ...). In the simulation, the model can be
programmed directly from the encoded conceptual model
using translation rules (type: IF THEN) with high-level
language or languages of the simulation. These rules are
written in software which does not facilitate their maintenance
in the event of changes in the target language. At this level
there is a lack of interoperability is a low reuse [
IV.
Process Interaction Discrete Event Simulation
Ontology (PIDESO)
Process interaction discrete event simulation ontology
(PIDESO), it’s an ontology specific to represents the concepts
of process-oriented discrete event simulation domain. It
consists of a set of classes organized in different levels in a
hierarchy very clear to help designers to build their models
without ambiguity and in a formal framework provided by
OWL. A model is a set of processes where each is a set of
activities and controlled by a control graph [
A.
This step allows reaching an informal model, semantically ambiguous and therefore usually expressed in natural language. This step is done to identify concepts and relationships between these concepts from raw data, these concepts to describe informally cognitive entities of simulation domain. The ontology in this research is divided into two levels. The first one is to identify the major elements of the system: model, processes, activities (general view) and the graphs of control. The second level is to represent the elements of characterization of first-level classes such as the types of each activity, the components of graph control, additional information on the model ... etc.
Second level: Project Description
This step leads to a semi-formal. This partial formalization
facilitates its subsequent representation in a formal language
and fully operational. Here is a diagram used to specify each
class of the ontology. Figure 1 shows the classes in the
ontology PIDESO and semantic links between different
concepts [
Defined by Variable Resource
Entity Attributes
Arc Transition
Node
Model contain *
Project description
Process Contains
* Controlled
by Contain *
Activity
Activity Type Manage resource
Queue Exit
Contains
Activity graph
Operationalization aims to have a formal structure of
concepts and relations between them, represented as a web
language OWL classes using an ontology editor Protégé-2000
[
An XML document is well formed if it adheres to XML syntax rules that are explicitly designed to make documents easily interpreted by a computer, and an XML document is valid if it adheres to the rules described in a document as an Associate DTD or schema.
We have defined an XML dialect to describe process-oriented
discrete event simulation models, named XPISM (extensible
process interaction simulation model). It describes the
simulation models in a hierarchy. The model consists of a
project description (sets the name of analyst / designer /
author, title of project, etc ....) And the whole model process
components such as activities, resources associated with each
activity, variables, attributes associated with such entities and
the graph of activities [
Automatic generation of Java code from the ontology instance
Process-oriented discrete event simulation models can be described as instances of OWL (Ontology instance). The idea is to change the shape of the model (OWL instances) to another more appropriate form (XPISM instance). This new description of the model (XPISM pending) is an intermediate representation for the executable model. An XSLT stylesheet containing the transformation rules allows instances of classes in ontology elements XPISM by an XSLT processor. XSLT rules are based on a locator called XPath to identify nodes in the source document (OWL instance) and build a result document (instance XPISM). This transformation is independent of all simulation languages or programming that ensures and strengthens interoperability and facilitates reuse.
Generating java code contains a main class containing a main () method that initializes the variables of the simulation model reflects its original state (number of replications, the simulation time ... etc.). It also launches the first arrivals in the simulation, then it call the start method (start ()) that initializes the coordinator and the simulation begins. After initialization of the first arrivals of each process, must be defined for each body that represents its life cycle in the system. Each process contains its own resources, variables, queues… etc
Models of discrete event simulation can be described as an instance of the schema XPISM well organized according to the process approach (a model contains several processes each process has several activities etc ....). An XSLT stylesheet contains the transformation rules allow instances XPISM (conceptual model) to a java code. These rules are executed via an XSLT processor.
JAPROSIM, (JAva PRocess Oriented SIMulation) [
VII.
CONCLUSIONS
PIDESO is a complete and comprehensive ontology for the process interaction discrete event simulation domain. It allows analysts and designers to improve their models with a semantic dimension. Models can be represented with an instance PIDESO and this instance will be transformed into another form more appropriate XPISM noted. Also, it is easy to obtain a conceptual model based on domain ontology. A set of rules defined XSLT transforms this model into an executable Java code based on the framework JAPROSIM.
The interest of our approach is summarized in three main points. First, the introduction of semantics in the simulation models, automatic generation of executable model, and the automation of the first steps of a simulation project. The result is certainly a gain in productivity, security development, enhanced interoperability and ease of maintenance and updating. To this is added clarity of approach and is now more rigorous.
We envision in the future work, to use the results to extend the code generation part to other simulation languages, given that the approach is independent of any simulation languages and simulation tools. And it is possible to provide new ontologies for other approaches to discrete event simulation, especially for events.