This paper describes the development of an ontology for use in a military simulation system. Within the military, aircraft represent a signi cant investment and these valuable assets need to be protected against various threats. An example of such a threat is shoulder-launched missiles. Such missiles are portable, easy to use and unfortunately, relatively easy to acquire. In order to counter missile attacks, countermeasures are deployed on the aircraft. Such countermeasures are developed, evaluated and deployed with the assistance of modelling and simulation systems. One such system is the Optronic Scene Simulator, an engineering tool that is able to model and evaluate countermeasures in such a way that the results could be used to make recommendations for successful deployment and use. The use of formal ontologies is no longer a foreign concept in the support of information systems. To assist with the simulations performed in the Optronic Scene Simulator, an ontology, Simtology, was developed. Simtology supports the system in various ways such as providing a shared vocabulary, improving the understanding of the concepts in the environment and adding value by providing functionality that improves integration between system components.
Military forces consider aircraft as important and expensive assets often
representing huge investments. The protection of these assets is considered to be a
priority by most countries. Protection is needed from various threats and one of
these threats are attacks through enemy missiles such as surface-to-air missiles,
which are relatively cheap and easy to operate, and in addition, widely
available in current and old war-zone areas [
Simulation systems model real-world objects and simulate them in an
articial world [
At present, various problems are experienced when constructing the input models for CmSim simulations. Because models are used as input into CmSim simulations, it is necessary to ensure that these models are adequate and accurate for useful simulations. The input model is adequate when it captures su cient input variables and context, and a model is accurate when it correctly captures the input variables and relations. It is for example possible to create input models that are syntactically correct, but the interaction between the models are not correctly set up in the simulation and therefore the results have no correlation with the real world. In addition, di erent users with various roles work with the system and it is necessary to acquire a common understanding and vocabulary for the constructs of the models and their characteristics. Furthermore, the creation of reference models for reuse across the user base would ensure better use of resources and time.
When investigating possible technologies that support modelling within
information systems, ontologies and ontology technologies feature extensively. One
of the original de nitions for the term ontology is that by Gruber who de ned an
ontology as a formalisation of a shared conceptualisation [
The remainder of this paper is structured as follow: Section 2 provides some background of the simulation environment and why it was necessary to build an ontology, as well as some background on ontologies. Section 3 discusses the development and nature of Simtology. Sections 4 and 5 discuss the contribution and conclude the paper in addition to discussing future work, as well as possible extensions to the ontology. 2
One of the largest investments in the military of a country is aircraft. Aircraft is the target of unfriendly forces in order to weaken the military forces of a country. These attacks include attacks executed by shoulder-launched missiles, which are portable, easy to use and relatively easy to acquire. In order to counter these missile attacks, the military deploy various kinds of countermeasures on aircraft, and these countermeasures are developed, evaluated and deployed with the assistance of modelling and simulation systems such as the Optronic Scene Simulator (OSSIM). 2.1
CmSim is a software application that is part of the broader Optronic System
Simulation (OSSIM) system [
CmSim is speci cally designed to do countermeasure evaluation for the
protection of military aircraft. Models of the aircraft, the missile, the
countermeasure and the environment are used to construct a scenario that simulates what
will happen in the real world [
In order to construct better input models, it is necessary to improve the understanding of the simulation and the meaning of concepts in the simulation environment. Users of models often does not know what models exist already, to what level the models were constructed, and the scenarios that might be possible in the simulation, and knowledge is not shared between di erent role-players. The simulation practitioner setting up the simulation scenario might not have specialist knowledge of how the models interact, and can set up scenarios that are syntactically correct but do not correlate with the real world scenario. There is therefore a need to capture the specialised knowledge in reference models that could be used before the scenario is fed to the simulation. Figure 2 depicts the di erent role-players that could be involved in the simulation environment.
In order to address the above mentioned needs, we initiated a project based
following the guidelines of design science research (DSR) [
The origins of the term ontology could be traced to the philosophers of the
ancient world who analysed objects in the world and study their existence [
From the characteristics listed above it is possible to argue that an ontology
may be a solution to the problems experienced in OSSIM simulations. Formal
ontologies are represented in a speci c formal knowledge representation language
[
Within computing, modelling and simulation are used to build a representation
of the real world and simulate the behaviour of objects presented in the models
[
Military systems and the knowledge captured therein are complex and
often consist of layered information from di erent sources. To support this view,
Clausewitz, in his book, On War, wrote about military information as follow
[
Furthermore, Mandrick discussed the use of ontologies to model information
in the military environment. According to Mandrick, ontologies in the military
must adhere to the same requirements as ontologies in other domains, as
described in Section 2.2. Important aspects to highlight is the ability of the ontology
to provide a common vocabulary between planners, operators and commanders
in the di erent military communities [
At present the adoption of ontologies in the military domain is primarily for
support of command and control in the battle eld, as well as the management of
assets and the sharing of knowledge[
The development of Simtology was in response to the identi ed needs when
using the Optronic Scene Simulator (OSSIM) [
The research design adopted for the development of Simtology, was Design
Research (DSR). DSR is a research methodology for the design and construction
of computing artefacts through the use of rigour (the use of fundamental
knowledge) and relevance (basing the development of the artefact on real needs) [
The rst steps in the design research process is awareness of the problem and proposing possible suggestions for a solution. The following list summaries the issues and needs in the simulation system as discussed in Section 2.1 that created awareness of the problem: { Di erent role-players: There are developers, model builders and users involved in the system. Inconsistencies in the terminology used between different users often led to frustration and wrong use of concepts. There is lack of a common vocabulary that is shared by everyone involved in building and using the system. { Model complexity: One of the main characteristics is the ability of the system to execute models at di erent levels of detail. This poses a problem to users, when to know at which level of detail a model is implemented at. { Reference models: Speci c users that only interact with the system at a certain level, need more technical insight into model detail to know what is available in the system. This means that reference models are required that can de ne domain-speci c concepts to these users. { Model Interaction: A simulation consists of a scenario that is built up from interacting models. The models interact using a set of rules but there is currently no rules that verify model behaviour when a scenario are constructed.
Previous research e orts in the simulation environment attempted to address
the the need for a standard notation for documentation of the simulation models.
This proved to be problematic and one of the suggestions for further research was
to investigate the use ontologies in the simulation environment. The suggestion
according to the DSR process is therefore that a formal ontology is created to
address the above mentioned needs for the simulation environment.
The ontology was build using the approach followed by the researchers who
develop the Adaptive Methodology [
The prototype is a proof-of-concept and in this project it played an important role to demonstrate the feasibility of the suggested solution. The prototype ontology supported the role of an ontology in the simulation system environment, and supported an ontology as a solution to a shared, common vocabulary. The tools also provided graphical views of the concepts de ned in the ontology. { Development of the Working Ontology: During this phase the prototype ontology was expanded by adding concepts from the domain not previously included in the ontology, as well as developing new functionality. The working ontology contains a full set of domain concepts that describe the simulation models and model properties and is called Simtology. The next section describes Simtology in more detail, as well as how Simtology is used in CmSim. 3.4
To do a simulation in CmSim, a scenario must be set up to act as input to the simulation. The scenario consists of various con guration les but the main le is the scenario le itself, which contains links to all other les necessary to describe a scenario and the components in it. Although the prototype already contained enough information to set up basic scenarios, Simtology contains all the concepts in the domain of CmSim.
The rst task was thus to expand the prototype to present not only the basic objects, but all the possible objects in the CmSim domain. The classes and properties were expanded. The following list describes the concepts and properties de ned in Simtology.
{ Concepts: In Simtology, an example of a concept representing all the individual aircrafts modelled in the simulation environment, is Aircraft. Figure 4 depicts an extract of the top-level concepts de ned in Simtology, where the concepts were selected to present those in a simulation scenario. The main concepts in Simtology are the Moving, Observer and Scenario concepts. The choice of concepts relied heavily on the structure of the simulation con guration les. Therefore objects of type Moving have speci c behaviour in the simulation and belong together in a concept. { Individuals: Individuals are asserted to be instances of speci c concepts.
Speci c scenarios can be build by choosing individuals from the ontology and thus creating an individual scenario.
ScenarioC130 is an individual of the Scenario concept that uses a speci c type of aircraft. { Object Properties: Object properties are used to link individuals to each other. In Simtology, a scenario must have a clock object, so having a clock object is an object property of the scenario concept. The name of the property is \hasClock\ and links an individual of class Clock to an individual from class Scenario.
In Simtology the main object properties belong to a scenario. The following properties are su cient to denote a valid scenario that can run in a simulation: ScenarioC130 hasClock Clock10ms ScenarioC130 hasTerrain TerrainBeachFynbos ScenarioC130 hasMoving C130Flying120knots ScenarioC130 hasObserver SAMTypeA
ScenarioC130 hasAtmosphere MidLatitudeSummer { Data Properties: Data properties were added to Simtology to add data to individuals. Examples of data properties are geometric locations of moving objects, or data belonging to the class Clock, as depicted below: Clock10ms hasInterval 10ms and Clock10ms hasStopTime 10sec Functionality: A scenario can be complex and rules were built in to ensure that a valid scenario is constructed, for instance only certain types of ares can be used as a valid countermeasure on a speci c aircraft. After building the scenario in the ontology, the scenario can be processed by a reasoner. The reasoners are used to compute the inferred ontology class hierarchy and to do consistency checking after a scenario is created.
Additional functionalities were developed for use with Simtology such as the integration of the ontology with the graphical user interface (GUI) used to set up the simulation. The ontology is used to populate the elements in the interface, resulting in several advantages such as that only one source of simulation information has to be maintained, as well as that the ontology can be used to change the language displayed in the GUI .
Functionalities were also developed to write out scenarios created in the ontology to les that can act as input to the simulation. This made it possible that a scenario can rst be checked for logical correctness before it is run in the simulation. Modelling errors not handled by the simulation software are handled early in the simulation process by using the reasoning technology in the ontology. By having a scenario de ned in the ontology, it is possible to export a high-level description of a scenario and its components to be used for reporting and documentation of simulation studies.
Testing of Simtology Testing the ontology was an important step towards creating a useful Simtology. When an ontology is small with a few concepts, it is easier to identify modelling problems but when there are large numbers of concepts with complex relationships, it is important to test the ontology regularly in order to avoid inconsistencies immediately and eliminate rework. During ontology veri cation the focus was mainly to ensure that the ontology was built correctly and that the ontology concepts match the domain it represents. The test phase of the ontology is part of the adaptive methodology process and this phase complements the evaluation phase of the design research process. 4
In Section 3.2, the simulation system environment was discussed. In order to evaluate the use of Simtology in the simulation system and the contribution it has for the improvement of the environment, the issues mentioned in Section 3.2 are used as evaluation criteria. The identi ed issues are 1) di erent users; 2) model complexity; 3) reference models; and 4) model interaction. When evaluated against the identi ed issues, Simtology provided the necessary solutions. { Di erent users: Simtology provided a common, shared 'language' to assist with eliminating ambiguities and the inconsistent use of terminology by the di erent users of the system. The feedback by all concerned users was positive. An example of how Simtology assisted with regards to a common understanding is in the use of ambiguous terms. Some terms in the simulation had di erent meanings depending on the user using it and the application it was used for. An example of such a term is countermeasure, which was vague and previously many di erent types of countermeasures existed. In Simtology the concept Countermeasure was de ned in such a way that it can be used as an explanatory tool to illustrate the di erent countermeasures available in the simulation as well as the use of each countermeasure. The Protege editor allows for several ways to communicate the ontology, for example a graphical display of the concepts and the relations in the ontology A visual display of the di erent components in the simulation leads to better communication between all the people involved. { Model complexity: Simtology formally de ned the concepts, properties and individuals necessary for the construction of input models. When a user uses Simtology to construct her input model, the appropriate level of detail and complexity of the input models are speci ed. { Reference models: Simtology provides a reference model for all the different users of the system to create their speci c input models from. After introducing Simtology, very few problems were experienced by users when constructing simulation models because Simtology acted as a reference model informed their speci c model design. { Model Interaction: A simulation consists of a scenario that is build up from interacting models. Simtology provides a common shared language to be used in the simulation environment for both users and when interacting with other applications. The de nitions of concepts in the system are kept in Simtology and made available to applications in the environment such as the Graphical User Interface.
As a nal evaluation, the guidelines proposed by Hevner et al. [
The outcome of the research project was Simtology, a domain ontology for the simulation environment that contains the model information for simulation scenarios. An added bene t was that the process to analyse the contents of the simulation environment to construct the ontology clari ed the knowledge in the domain.
During the construction of Simtology, the following observations were made: { With regards to modelling, it is important to distinguish part-of from subclassof. An aircraft body is part of an aircraft, not part of a speci c type of aircraft. { It is important to correctly model roles. Modelling a missile as an observer in the simulation means that it can never be used in the simulation as an object of type moving. In Simtology, a missile can therefore never be used in a di erent role. { Another important modelling decision has to do with the modelling of individuals vs. concepts. This decision has an impact on how the ontology could ultimately be used. The choice between concept and individual is often contextual and application-dependent but it needs to be evaluated in one of the development cycles. { The development and use of the ontology should be an iterative process. As new functionality is added, it must be tested, used and evaluated. Existing functionality is maintained by making changes where necessary. Proper version control is therefore also necessary when constructing ontologies.
Several advantages of having an ontology in the simulation environment emerged after the ontology was created. The ontology can, for instance, be used in training exercises to show aircraft personnel the technical detail of the countermeasures deployed on the aircraft. Furthermore, the simulation environment is always expanding and improving through the addition of new models, the addition of new properties to existing entities in the system or through the addition of new functionality to entities. Future versions of the ontology need to incorporate these changes and there should therefore always be future expansions to the Simtology ontology. Furthermore, Simtology should ideally be expanded to not only include concepts in CmSim, but also in the Optronic Scene Simulator. One of the planned functions to be developed is to reverse engineer previously run simulations and add the scenario descriptions of those simulations to the ontology.