development, representation and validation of conceptual...

Defence R&D Canada

DEFENCE DÉFENSE&

DEVELOPMENT, REPRESENTATION AND

VALIDATION OF CONCEPTUAL MODELS

IN DISTRIBUTED SIMULATION

Okan Topçu

Technical Memorandum

DRDC Atlantic TM 2003-142

February 2004

Copy No.________

Defence Research andDevelopment Canada

Recherche et développementpour la défense Canada

This page intentionally left blank.

Copy No:

DEVELOPMENT, REPRESENTATION AND VALIDATION OF CONCEPTUAL MODELS IN DISTRIBUTED SIMULATION

Okan Topçu

Defence R&D Canada – Atlantic Technical Memorandum DRDC Atlantic TM 2003-142 February 2004

Abstract This study proposes a new approach to conceptual model representation and validation. Conceptual models are widely used in Modelling and Simulation (M&S) and are becoming one of the main building blocks of the distributed simulation development. It is also vital to state the development environment in which the conceptual model representation and validation techniques will be applied. Therefore, this study first proposes a vision for a distributed simulation environment, then prepares the technical ground for the conceptual model representation and validation techniques, and finally presents a conceptual model representation and validation technique.

Résumé Cette étude propose une nouvelle approche pour la représentation et la validation des modèles conceptuels. Les modèles conceptuels sont fort utilisés en modélisation et simulation (M&S) et ils sont en train de devenir l’un des principaux blocs fonctionnels du développement de la simulation répartie. Il est également essentiel de définir l’environnement de développement dans lequel les techniques de représentation et de validation des modèles conceptuels seront appliquées. Par conséquent, cette étude propose tout d’abord une vision de l’environnement de simulation réparti, elle prépare ensuite le terrain technique pour les techniques de représentation et de validation des modèles conceptuels et elle présente finalement une technique de représentation et de validation des modèles conceptuels.

DRDC Atlantic TM 2003-142 i


ii DRDC Atlantic TM 2003-142

Executive summary Introduction Either documented or not, all simulations simulate an abstract world that may be called a conceptual world or conceptual model. The creation of a conceptual model (CM) is one of the main steps in simulation development, and eases the transition between simulation requirements and simulation high-level design by strictly formatting the requirements. CMs are also used as a communication means between simulation users/sponsors and developers. From a user’s perspective, the conceptual model is the most important document about the simulation capabilities because it includes assumptions, limitations, algorithms, objects, and relations among these objects related to the real world. From a developer’s perspective, the conceptual model prepares the basis for simulation development and is a vital element in simulation validation. In software engineering, one of the general rules states that “the earlier you make a mistake in the software development lifecycle, the more you pay, and the more time you spend to fix it”. A corollary is that a mistake in the conceptual model will result in bigger bugs in the simulation software and it will take more time and money to fix it. Therefore, the validation of a conceptual model should be carried out in the beginning and then the simulation can be developed based on the validated conceptual model. Results This study prepares the technical ground for conceptual model representation and validation. Using this preparation, it proposes:

• A technical framework for developing High Level Architecture (HLA)-based military simulations with verification and validation support. This technical framework includes a methodological view, tool-support view, and a lifecycle view and states the technical ground.

• Extensions to the scientific paper-based approach for the representation of the informal conceptual model. The use of domain entity tables are proposed as a tool to explicitly state the domain entities, attributes, relations, and operations and to ease the development of a formal conceptual model

• A representation technique for the formalization of conceptual models using ontologies. This representation technique may be classified as a design accommodation approach and it overcomes the problems introduced by previous design accommodation approaches by providing a method for capturing assumptions and limitations inherent in the conceptual model. It also eliminates the necessity for the problem domain expert to understand the software formats by providing automation support for validation. This technique also eliminates the weak point of conceptual model-based methods in the use of different notations for the problem space system view and the solution system view by using a well-known and widely accepted notation, Unified Modelling Language.

This technical document also presents a simple real-life case study, which shows how to apply the proposed techniques. Significance

DRDC Atlantic TM 2003-142 iii

The Canadian Forces (CF) are increasingly using Modelling and Simulation and moving toward the use of distributed simulation for training and concept development. Validation is crucial to the success of these efforts. The conceptual model representation is the heart of the simulation validation. This study provides the theoretical work to introduce new techniques for conceptual model representation and validation in order to obtain a more formalized simulation validation. These techniques should also increase the validation quality and the reliability in resulting software. Future plans Work is continuing on refining the conceptual model representation and validation techniques, on the specification of a federation design model, and on developing a federation design verification technique. The next step will be connecting the conceptual model to federation design model.

Topçu, O., 2003. Development, Representation, and Validation of Conceptual Models in Distributed Simulation. DRDC Atlantic TM 2003-142 Defence R&D Canada – Atlantic.

iv DRDC Atlantic TM 2003-142

Sommaire Introduction Qu’elles soient documentées ou non, toutes les simulations simulent un monde abstrait que l’on peut appeler monde conceptuel ou modèle conceptuel. La création d’un modèle conceptuel (MC) est l’une des principales étapes du développement des simulations et elle facilite la transition entre les exigences de simulation et la conception de haut niveau des simulations grâce à une mise en forme stricte des exigences. Les modèles conceptuels servent également de moyen de communication entre les utilisateurs/les responsables et les développeurs des simulations. Du point de vue de l’utilisateur, le modèle conceptuel est le document le plus important au sujet des capacités de simulation car il englobe les hypothèses, les limitations, les algorithmes, les objets et les relations entre ces objets qui ont trait au monde réel. Du point de vue du développeur, le modèle conceptuel prépare la base de développement des simulations et c’est un élément vital dans la validation des simulations. Dans le domaine de l’ingénierie logicielle, l’une des règles générales établit que: «plus tôt vous faites une erreur dans le cycle de développement des logiciels, plus vous payez et plus de temps il vous faudra pour corriger cette erreur». Cette règle a pour corollaire qu’une erreur dans le modèle conceptuel aura pour résultat des bogues plus importants dans le logiciel de simulation et qu’il faudra plus de temps et d’argent pour les corriger. Par conséquent, la validation d’un modèle conceptuel devra être exécutée au début du travail et la simulation pourra être ensuite développée selon un modèle conceptuel validé. Résultats Cette étude prépare le terrain technique pour la représentation et la validation des modèles conceptuels. À l’aide de cette préparation, on propose ce qui suit:

• Un cadre technique de développement de simulations militaires basé sur l’architecture de haut niveau (HLA ou High Level Architecture) avec le support de la vérification et de la validation. Ce cadre technique englobe une vision ou «vue» méthodologique ainsi qu’une vue du support des outils et du cycle de vie et il définit le terrain technique.

• Des extensions à l’approche fondée sur des documents scientifiques pour la représentation du modèle conceptuel informel. On propose d’utiliser les tables des entités de domaines comme outil pour définir explicitement les entités de domaines, les attributs, les relations et les opérations et pour faciliter le développement d’un modèle conceptuel formel.

• Une technique de représentation qui permet de formaliser des modèles conceptuels au moyen d’ontologies. Cette technique de représentation peut être classifiée comme une approche de prise en charge de la conception et elle surmonte les problèmes introduits par les approches antérieures en fournissant une méthode qui permet de saisir les hypothèses et les limitations inhérentes dans le modèle conceptuel. Cette technique de représentation élimine également la nécessité, pour l’expert dans le domaine des problèmes, de comprendre les formats des logiciels en lui assurant le support automatique de la validation. Elle élimine également le point faible des méthodes fondées sur les modèles conceptuels quant à l’utilisation de différentes notations pour la vue système de

DRDC Atlantic TM 2003-142 v

l’espace de problème et la vue système des solutions grâce à une notation bien connue et couramment acceptée que l’on appelle le langage de modélisation unifié (UML ou Unified Modeling Language).

Ce document technique présente également une simple étude de cas qui montre comment appliquer les techniques proposées. Portée Les Forces canadiennes (FC) ont de plus en plus recours à la modélisation et à la simulation et elles sont en train d’adopter la simulation répartie pour le développement des concepts et de la formation. La validation est essentielle au succès de ces efforts. La représentation des modèles conceptuels est au cœur de la validation des simulations. Cette étude constitue la base théorique qui permet d’introduire de nouvelles techniques pour la représentation et la validation des modèles conceptuels afin d’obtenir une validation plus formalisée des simulations. Ces techniques devraient également améliorer la qualité et la fiabilité de la validation dans les logiciels résultants. Recherches futures Le travail se poursuit pour ce qui est raffiner les techniques de représentation et de validation des modèles conceptuels, d’établir les spécifications des modèles de conception de fédération FDM (Federation Design Model) et de développer une technique de vérification de la conception de fédération. L’étape suivante portera sur la connexion du modèle conceptuel avec le modèle de conception de fédération.

Topçu, O., 2003. Development, Representation, and Validation of Conceptual Models in Distributed Simulation. DRDC Atlantic TM 2003-142 Defence R&D Canada – Atlantic.

vi DRDC Atlantic TM 2003-142

Table of contents

Abstract........................................................................................................................................ i

Executive summary ................................................................................................................... iii

Sommaire.................................................................................................................................... v

Table of contents ...................................................................................................................... vii

List of figures ............................................................................................................................. x

Acknowledgements .................................................................................................................. xii

1. Introduction ................................................................................................................... 1 1.1 Theory of Modelling and Simulation ............................................................... 1 1.2 What is a Conceptual Model (CM)?................................................................. 2 1.3 Present CM Development and Representation Techniques.............................. 5

1.3.1 Scientific Paper Approach................................................................... 5 1.3.2 Design Accommodation ...................................................................... 6 1.3.3 Extreme Conceptual Modelling (XCM).............................................. 6 1.3.4 Conceptual Model of Mission Space (CMMS) Paradigm................... 8 1.3.5 Ad Hoc Method ................................................................................... 8

1.4 Present CM Validation Techniques.................................................................. 8 1.4.1 Using a Subject Matter Expert (SME)................................................. 8 1.4.2 Model Validation with Simulation Graph Models .............................. 9

1.5 Summary ........................................................................................................ 10 1.6 Document Outline .......................................................................................... 10

2. A Framework for V&V Supported Development Environment for HLA-Based Distributed Simulations ............................................................................................................ 11

2.1 Methodology .................................................................................................. 11 2.1.1 Conceptual Model (CM) ................................................................... 13 2.1.2 CM Validation Using Scenarios........................................................ 13 2.1.3 Federation Design Model (FDM)...................................................... 14 2.1.4 Federation Design Verification ......................................................... 14

DRDC Atlantic TM 2003-142 vii

2.1.5 Detailed Design (DD):....................................................................... 14 2.2 Tools............................................................................................................... 16 2.3 Lifecycle......................................................................................................... 18

3. Conceptual Model Representation............................................................................... 22 3.1 User Profiles ................................................................................................... 22 3.2 Conceptual Model Content and Limits........................................................... 22 3.3 Informal Conceptual Model (Informal CM)................................................... 23 3.4 Formal Conceptual Model (Formal CM)........................................................ 24

3.4.1 What is Ontology?............................................................................. 24 3.4.2 What does an Ontology include?....................................................... 25 3.4.3 Ontology Representation ................................................................... 26

3.4.3.1 Why UML? ........................................................................ 26 3.4.3.2 Can UML represent an Ontology? ..................................... 27 3.4.3.3 UML in Ontology............................................................... 28 3.4.3.4 UML Profile for DAML+OIL............................................ 29

3.4.4 Using OCL in the Formalism of Constraints..................................... 29 3.4.5 Using Tools in the Development of the Formal CM ......................... 29 3.4.6 Research Issues.................................................................................. 30

4. Scenario-Based Conceptual Model Validation............................................................ 31 4.1 Introduction .................................................................................................... 31 4.2 Technique ....................................................................................................... 31

4.2.1 Scenarios ........................................................................................... 31 4.2.1.1 Use Case Scenarios ............................................................ 31 4.2.1.2 Simulation Scenarios.......................................................... 32

4.2.2 A Simple Example............................................................................. 33 4.2.3 Comparison and Automation............................................................. 35

4.3 Supporting Tools ............................................................................................ 35 4.4 Discussions ..................................................................................................... 35

5. Results and Conclusions.............................................................................................. 36 5.1 Contributions of This Work............................................................................ 36 5.2 Advantages ..................................................................................................... 37

viii DRDC Atlantic TM 2003-142

5.3 Disadvantages................................................................................................. 37 5.4 Future Work ................................................................................................... 37

6. References ................................................................................................................... 38

Appendix-A Case Study: Canadian Virtual Battle Experiment (VBE CA) ............................. 42

Appendix-B Ontology Review ................................................................................................. 72

List of symbols/abbreviations/acronyms/initialisms ................................................................ 75

Distribution list ......................................................................................................................... 77

DRDC Atlantic TM 2003-142 ix

List of figures

Figure 1. The Basic Elements and Relations of Modelling and Simulation Enterprise [1]........ 1

Figure 2. Relationships Between Models, Simulations, and Reality.......................................... 4

Figure 3. Revised Simulation Model .......................................................................................... 5

Figure 4. V&V Oriented Development Methodology for HLA-Based Distributed Simulations12

Figure 5. Layered Software Architecture for Federate Design................................................. 15

Figure 6. Development Lifecycle ............................................................................................. 19

Figure 7. Analysis and Conceptual Model Development Phase Activities .............................. 20

Figure 8. Domain Entities Table............................................................................................... 24

Figure 9. Ontology Representation Paradigms (reproduced from [48]) ................................... 26

Figure 10. Example: Left Diagram: An Ontology as a UML Class Diagram, Right Diagram: Family Knowledge as a UML Object Diagram (reproduced from [25])........................... 27

Figure 11. The Ontology Language Stack (reproduced from [48]) .......................................... 29

Figure 12. Example of a UML Use Case Diagram................................................................... 33

Figure 13. A Simplified Sequence Diagram for “Making-Association” Use Case .................. 34

Figure 14. Vessel Group........................................................................................................... 45

Figure 15. Environment Group................................................................................................. 47

Figure 16. Sonar Group ............................................................................................................ 49

Figure 17. Display Group ......................................................................................................... 51

Figure 18. Ontology Connections............................................................................................. 57

Figure 19. Protégé Ontology Editor Screen Shot ..................................................................... 58

Figure 20. ArgoUML CASE Tool Screen Shot........................................................................ 60

Figure 21. Architectural Overview of Federation..................................................................... 61

Figure 22 Instantiation of own ship and coalition ship vessels ................................................ 62

x DRDC Atlantic TM 2003-142

Figure 23. Sonar Federate Object Class P/S Diagram.............................................................. 63

Figure 24. Sonar Federate Interaction Class P/S Diagram ....................................................... 64

Figure 25. Data Logger Federate Class P/S Diagram............................................................... 65

Figure 26. Motion Federate Class P/S Diagram ....................................................................... 66

Figure 27. Typical VMSA Federation Lifecycle [55] .............................................................. 67

Figure 28. Creation of Composite and Component Entities..................................................... 68

Figure 29. VMSEM P/S Diagram............................................................................................. 68

Figure 30. Entity Instantiation Diagram ................................................................................... 69

Figure 31. VBE General Data Flow Diagram .......................................................................... 69

Figure 32. Composite and Component Entity Class Diagram.................................................. 70

Figure 33. Sequence Diagram of Target Detection via Passive Sonar ..................................... 70

List of tables

Table 1. CM Development/Representation/Validation ............................................................ 10

Table 2. Categorization of Tools .............................................................................................. 17

Table 3. Ontology-OO Modelling Analogy.............................................................................. 25

Table 4. Simulation Developers - Points of Contact ................................................................ 45

Table 5. Notation Used in Informal Conceptual Model ........................................................... 44

Table 6. Shared Data Between Ship Instances ......................................................................... 62

Table 7. Ontology Languages................................................................................................... 72

Table 8. Ontology Languages and UML Mapping................................................................... 72

Table 9. Knowledge Representation Languages ...................................................................... 73

Table 10. Ontology Tools......................................................................................................... 73

Table 11. Some Top Level (a.k.a. Core) Ontologies ................................................................ 74

DRDC Atlantic TM 2003-142 xi

Acknowledgements I express sincere appreciation to the Group Leader of Virtual Combat Systems Mr. Mark Hazen and my PhD Supervisor Asst. Prof. Dr. Halit Oğuztüzün for their support, guidance and insight throughout the research. Thanks go to Tania Wentzell, Garfield Mellema and Jason Murphy for their help and support in the case study. Finally, I would like to thank my wife Tuğçe Oğuz Topçu. Without her support, things would be impossible. This work has been supported by DRDC Atlantic under the terms of NATO Fellowship Program.

xii DRDC Atlantic TM 2003-142


DRDC Atlantic TM 2003-142 xiii

1. Introduction Either documented or not, all simulations simulate an abstract world that may be called a conceptual world or conceptual model. The creation of a conceptual model (CM) is one of the main steps in simulation development, and eases the transition between simulation requirements and simulation high-level design by strictly formatting the requirements. CMs are also used as a communication means between simulation users/sponsors and developers. From a user’s perspective, the conceptual model is the most important document about the simulation capabilities because it includes assumptions, limitations, algorithms, objects, and relations among these objects related to the real world. From a developer’s perspective, the conceptual model prepares the basis for simulation development and is a vital element in simulation validation. In software engineering, one of the general rules states that “the earlier you make a mistake in the software development lifecycle, the more you pay, and the more time you spend to fix it”. A corollary is that a mistake in the conceptual model will result in bigger bugs in the simulation software and it will take more time and money to fix it. Therefore, the validation of a conceptual model should be carried out in the beginning and then the simulation can be developed based on the validated conceptual model. In this work, examples of the distributed simulation are taken from the High Level Architecture (HLA) paradigm and involve: federations (overall simulation), federates (component simulators), and run-time-infrastructure (RTI) (communication infrastructure).

1.1 Theory of Modelling and Simulation The idea of Conceptual Model may be based on Zeigler’s modelling and simulation (M&S) theory [1]. Before discussing the conceptual model, it is helpful to review some M&S theory basics. Modelling and simulation theory provides three major elements (i.e., real system, model, and computer) and two relations (i.e., simulation and modelling) among these elements. Figure 1 depicts the basic elements and relations of the modelling and simulation enterprise.

Real System Computer

ModelSimulationModeling

Figure 1. The Basic Elements and Relations of Modelling and Simulation Enterprise [1]

The following definitions are taken from [1]. A Real system is some part of the real world, which is of interest, and it is a source of behavioural data, consisting in primary form of plots of X against T, where X can be any variable of interest and T is time. A Model is basically a set of instructions for generating behavioural data (of the form of plots of X against T). A Computer is any computational process capable of generating behavioural data when supplied with suitably encoded model instructions. A Modelling relation concerns the validity of the model, that is, how well the model represents the real system. The examination of this relation is called model validation. The simulation relation concerns the faithfulness with which the computer carries out the instructions intended by the model. The faithfulness with which a

DRDC Atlantic TM 2003-142 1

program realizes a model is often referred to as the correctness of the program. Many of the definitions and concepts related to M&S and verification and validation (V&V) are presented and discussed in [2]. Another important part of M&S theory is the communication aspect, which emphasizes the representation of a model. Zeigler described several communication aspects, the first three (which are of interest to this paper) are as follows:

• Informal (natural language) description of the model and the assumptions,

• Formal (mathematical or other exact) description of the model structure,

• Presentation of the program with which the simulation was carried out.

Zeigler stated that “the informal model should help both users and colleagues to grasp the basic outlines of the model and to visualize it within the framework of their prior conceptions about how things work”. This is (one of) the fundamental purpose(s) of a conceptual model.

1.2 What is a Conceptual Model (CM)? Although “conceptual model” is a frequently used term in Modelling and Simulation, it is used in many different ways. Concept is defined as “(1) something conceived in mind, (2) an abstract or generic idea generalized from particular ideas” in Merriam-Webster (online) dictionary [3]. Conceptual is defined as “of, relating to, or consisting of concepts” [3]. Model has several definitions, but in our context, it is described as “a pattern of something to be made” [3]. Modelling is the process of producing a model. Therefore, a conceptual model can be defined as “an abstract representation of something generalized from particular instances” [4]. From a developer’s perspective, a conceptual model is the developer’s way of translating the requirements into a detailed software design from which the simulation software will be built [5]. In High Level Architecture (HLA)-based distributed simulations, the Federation Execution and Development Process (FEDEP) [6] describes a conceptual model such that “The federation conceptual model provides an implementation-independent representation that serves as a vehicle for transforming objectives into functional and behavioural capabilities; the model also provides a crucial traceability link between the federation objectives and the design implementation. This model can be used as the structural basis for many federation design and development activities (including scenario development) and can highlight correctable problems early in the federation development process when properly validated.” Sometimes the term conceptual model is used interchangeably with terms: Meta model or logical model or logical view or domain model or high-level design. As stated before, conceptual models are defined in many differing perspectives. CM is the result of an effort to understand, to reason, and to obtain consensus about the real world domain. Therefore, it is important to express the objective, purpose, and use of conceptual models. The objective of the descriptive format for the conceptual model (system representation) is to provide a coherent set of information that fully, and correctly, describes the system representation so that its capabilities, limitations, and characteristics can be readily understood by Subject Matter Experts (SMEs) and simulation development personnel [5]. The following excerpt from [7] states the use of conceptual modelling:

2 DRDC Atlantic TM 2003-142

“System developers must have a clear understanding of the domain, for which the system is developed, to produce the system which is valid and sufficient for the intended use. Since development of an information system starts with the definition of informal requirements specification (usually in natural language) defined by the users, these informal specifications are formalized into the conceptual models so that the system design has a more structured and clarified base. The main motivation behind this activity is that the structure of natural language statements may cause different interpretations, while the formal representation of these statements have inherently one valid interpretation.”

Conceptual models serve several purposes:

• A conceptual model helps the developers to understand the problem domain.

• A conceptual model provides more structured and clear documentation.

• A conceptual model provides the means for the verification and validation.

• A conceptual model provides a precise tool for the communication between system developers and application domain specialists.

When we bring together the conceptual model with other M&S concepts, the general modelling and simulation approach will follow the diagram in Figure 2, which represents the relationships between models, simulations, and reality. Conceptual Model Validation is the evaluation of a conceptual model with respect to the system or real life, where the objective is primarily to evaluate the realism of the conceptual model with respect to the objectives of the study [8]. Results Validation (also called Behavioural Validation) is the evaluation of the simulation behaviour. Our concern in this study is conceptual model validation. Other related terms, such as credibility, software verification etc., are defined and explained in [2].


Simulation

ConceptualModel

RealWorldSystem

Programming

Credibility

ResultsValidation

Analysis &

Modeling

ConceptualValidation

SWVerification

Simulation

ConceptualModel

RealWorldSystem

Programming

Credibility

ResultsValidation

Analysis &

Modeling


SWVerification

Figure 2. Relationships Between Models, Simulations, and Reality

Conceptual models have gained more importance due to the rapid growth of distributed simulations1. In distributed simulations, generally, the components are developed independently or reused from another simulation. Therefore, it is important to define the intersections of intended domains of each component (also called a federate), which is a part a of distributed simulation (federation), in order to determine the total domain of interest. HLA [9-11] slightly changes the general simulation theory presented in Figure 2, by introducing a new step: Federation design. In HLA terms, a federation is a group of distributed simulation components. Federation design defines the data flow and interactions between distributed components. The revised picture is depicted in the Figure 3. In proper software engineering, design always comes before coding.

1 A short overview of distributed simulation architectures/protocols is presented in [32].


ConceptualModel

FederationDesign

ConceptualModel

FederationDesign

Simulation

RealWorldSystem

ResultsValidation

ResultsValidation


SWVerification

SWVerification

Program

SoftwareDesign

ProgramProgram

SoftwareDesign

Figure 3. Revised Simulation Model

The proposed approach for distributed simulation development with verification and validation support is generally based on this model and is explained in section 2.

1.3 Present CM Development and Representation Techniques A successful representation of CM must be in a form that fully and correctly describes the system and it is understandable by Subject Matter Experts (SMEs) and simulation development personnel. This section identifies several descriptive formats.

1.3.1 Scientific Paper Approach

The scientific paper method is the descriptive format recommended by US Department of Defense (DoD) for system representations.

This technique employs the standard construct of a scientific paper or report to be more complete in its identification of assumptions, more explicit in its statement of algorithms in accord with standard mathematical and technical conventions, and more rigorous in its specifications of limitations arising from the conceptual model. The suggested descriptive format [12] includes (note that a slightly different format can be found [13]):

• Conceptual Model Part Identification


• Point(s) of Contact for the Conceptual Model

• Conceptual Model Part Requirements/Purpose

• Conceptual Model Part Overview

• General Assumptions

• Basic Elements of the Entities and Processes

• Identification of Algorithms

• Simulation Development Plans

• Summary and Synopsis

Although, the items above are self-explanatory, a detailed explanation can be found in [5, 12, 13].

The main advantage of this approach is that the user community can easily inspect the model since it is constructed using natural language sentences. This approach also provides documentation for the simulation.

1.3.2 Design Accommodation

In software engineering and knowledge engineering, there are many representation formats to document any kind of information according to its abstraction level. The design accommodation method includes these software formats. For example, Unified Modelling Language (UML) can be used to describe the whole or part of the conceptual model. Although, this approach facilitates the transition from conceptual model format to simulation design format, it includes some problems [13]:

• There may be no standard method for capturing assumptions and limitations inherent in the conceptual model.

• It may be very difficult for a problem domain SME to understand the software format and therefore to validate the CM.

1.3.3 Extreme Conceptual Modelling (XCM)

This approach can be seen as an application/realization of the design accommodation technique. It was developed for automatic software production [14] and it attempts to provide an approach to “how to go from the problem space to the solution space with sound methodological guidance”.

The weak point of conceptual modelling-based methods is the use of different notations for the problem space system view (what the system is) and the solution


system view (how it is to be represented). To overcome this problem, a conceptual schema should be a precise representation of the user requirements and should be executable. This means that the programming tasks are really done at a higher level of abstraction, using conceptual modelling constructs.

This approach includes the process of capturing user requirements (by using the Use Case-based approach [15] that is widely accepted in requirements engineering practice) and model-based code generation techniques (by using design patterns to automatically implement the conceptual concepts).

A conceptual schema constitutes the problem space representation of the system being developed. It consists of static, dynamic, and functional system views based on UML diagrams.

The XCM approach has four main steps:

• Requirements model

Mission state

Function refinement tree

Use case model (based on UML)

• Requirements Analysis Process

Sequence diagrams (Each use case is represented by at least one sequence diagram)

Function decomposition table (It is based on the structured analysis technique and it is used to clearly document which classes are involved in each use case)

• Conceptual Modelling

Object Model-based on UML Class Diagrams

Dynamic Model-based on State Transition Diagrams and Interaction Diagrams

Functional Model

• Execution Model

Software architecture for the system by means of architectural patterns (e.g., multi-tiered architecture)

Code generation strategy (it is made up of a set of conceptual patterns based on the formal specification language OASIS [16])


Although this approach provides a full conceptual modelling framework including a transition phase from the CM to software development, it does not propose an obvious CM validation technique.

1.3.4 Conceptual Model of Mission Space (CMMS) Paradigm

CMMS, developed by the US Department of Defense (DoD), is a simulation implementation-independent functional description of the real world processes, entities, and environment associated with a particular set of military missions [17] so that conceptual analysis and conceptual model development is performed on the same basis for different simulations. The CMMS is a first abstraction of the real world and serves as an authoritative knowledge source for simulation development [18, 19]. CMMS is now known as the Functional Description of the Mission Space (FDMS).

1.3.5 Ad Hoc Method

This method is used on a case-by-case basis without consideration of wider applications. The representation of the CM has no standard description format and depends on the specific perspectives of the application in consideration. No formal approach is followed and it is generally based on the coding documentation. Many existing legacy simulations may have conceptual models based on this method.

1.4 Present CM Validation Techniques The objective of conceptual model validation is confirming that the capabilities indicated in the conceptual model embody all the capabilities necessary to meet the requirements.

1.4.1 Using a Subject Matter Expert (SME)

Validation of a conceptual model is generally based on informal validation techniques: Subject Matter Expert (SME) Review [12, 20], SME Inspection [21], and SME Walkthroughs [22]. The review technique is a more detailed technique than inspection and walkthrough since it also includes management. Other informal techniques (i.e., audit, self inspection, face validation) [2] can also be employed in conceptual model validation. The basic strength of SME validation is that the validation is based on the subjective assessment of an expert such that the validation activity is affected by the experience, training, education, involvement to the project and available time of the expert(s).

A Subject Matter Expert (SME) is an individual who, by virtue of position, education, training, or experience, is expected to have greater than normal expertise or insight relative to a particular technical or operational discipline, system, or process, and who has been selected or appointed to participate in development, verification, and validation (V&V), or use of a model or simulation [20]. SMEs are generally categorized in two groups: V&V SMEs (i.e., requirement validation SME, verification SME, and validation SME) and non-V&V SMEs (i.e., domain expertise SME, simulation development SME, and application SME).


1.4.2 Model Validation with Simulation Graph Models

The Simulation Graph Models (SGM) are mathematical representations of the state variables of a model, events that change the state, and the logical and temporal relationships between events. SGMs were produced with the intent of determining when one discrete event model could be replaced by another. The process involves graphing and analyzing the structure of the two models (e.g., the problem entity vs. conceptual model) being compared. An SGM is used to augment model validation [23].

Model validation is a three-step procedure:

• SGM is the combination of event and simulation graphs. The first step is to generate event graphs and simulation graphs (which involves producing mathematically explicit definitions of the event graphs) for each model (problem, conceptual, and computer implementation).

• SGMs must be contracted to Elementary SGMs (ESGMs), which is an SGM that has all of the compound edge conditions and vertices reduced to simple edge conditions and vertices.

• Validation is based on the structural equivalence test [24]. If an isomorphism between model structures can be shown, the models are declared structurally equivalent. If two models are considered structurally equivalent, then they are valid.

To perform a validity assessment using simulation graph models requires the problem entity, conceptual model, and implemented computer model to all be developed using this technique. This approach is applicable to discrete event simulations where simulation graph models were produced with the intent of determining when one discrete event model could be replaced by another [23].


1.5 Summary

Table 1. CM Development/Representation/Validation

APPROACH REPRESENTATION/FORMALIZATION

TECHNIQUE

DEVELOPMENT PARADIGM

VALIDATION TECHNIQUE

Scientific Paper Approach

Formatted paper Some guidelines proposed in DMSO RPG [12]

SME Review

XCM (Extreme Conceptual Modelling)

Object Oriented (OO) Model

Object Oriented (OO) Method

No proposal

CMMS (Conceptual Model of Mission Space)

Database Structures CMMS Toolset

Modelling and Simulation Resource Repository (MSRR)

SME Review

Simulation Graph Models (Design Accommodation)

Event and Simulation Graphs

Elementary Simulation Graphs

- Structural Equivalence Test

1.6 Document Outline The preceding sections of this chapter presented an overview of the theory of modelling and simulation, the definition of conceptual model, and the current representation and validation methods for conceptual models. The remaining chapters are broken down as follows: Chapter 2 outlines a vision for verification and validation supported development environment for HLA-based distributed simulations. Chapter 3 describes the proposed representation technique for conceptual model. Chapter 4 presents the proposed validation technique for conceptual model. Chapter 5 outlines conclusions reached as a result of this research as well as recommendations for future research in this area. Appendix A presents a case study called Canadian Virtual Battle Experiment. Appendix B gives a short ontology review.


2. A Framework for Verification and Validation (V&V) Supported Development Environment for HLA-Based Distributed Simulations

The proposed approach is especially designed for distributed interactive simulations, specifically for High Level Architecture (HLA) simulations, and it is very applicable in the military domain. The development vision is explained by forming a methodological view, tool-support view, and a lifecycle view. The methodological side of the vision emphasizes the models and the products to be developed, the tool-support view explains the support for automation and the tools that can be used to develop these models, and the lifecycle view presents the necessary activities and work-flow for development.

2.1 Methodology A development methodology can be seen as a transformation of models. Then, we can claim that HLA-based distributed interactive simulations are comprised basically of conceptual, federation design, detailed design, and execution models. Figure 4 depicts the basic models incorporated with V&V. Each layer of models has a different level of abstraction, for example, while the conceptual model layer deals with domain entities, the detailed design model layer deals with software objects. In this approach, Unified Modelling Language (UML) is used as the glue between models. This is possible due to the flexible nature of UML, which has the capability to represent both high abstraction and detailed levels of software applications. In software engineering, UML is commonly used to represent detailed software design and execution models, and many Computer Assisted Software Engineering (CASE) tools (e.g., Rational Rose, argoUML) support UML for the automatic generation of customizable code skeletons. UML is also suggested as a representation language for both conceptual models and domain modelling [25, 26, 27].


Representation:Formal:UML Based OntologyInformal:Paper-based Approach

CONCEPTUALMODEL

SIMULATION ENTITY PROCESSES

FEDERATIONDESIGN

DETAILEDDESIGN

MEKOFdMEKOFdMEKOFdMEKOFdMEKOFdOTCFd

MEKOFdMEKOFdKNOXFd

FEDERATION MANAGEMENT PROCESSES

OSEFd FEDMONFd

RUNTIME INFRASTRUCTURE

0..1 0..1

SCENARIODB CPD DB

ENV

IRO

NM

ENT

GEN

ER

ATIO

N F

EDE

RAT

ES

Env

iFd

ENVIRONMENTDB

RTI PR

OV

IDE

D PR

OC

ESSES

RTIExec

FedExec

Representation:UML Profile for HLA

Representation:UML

Cfrigate

Cmeko

CcommCen Chelm Ceot Cgps Chydrodynamics

CUIcommCen CUIgpsCUIshipConCen

CmsgDispatcher

CUIcontroller

1

*

11

11

11

11

1 *aggregation

inheritance

Cofficer -OOW

*

-navigates

1 *

*

Cradar

CUIradar

11One-way association

C3DmainVP C3DcVP C3DradarVP C3DctiVP

C3D

VariousSystemViews

Real Life Problem

Design Verification

Results Validation

InformalCM

SME Review

Informal CMFormal CM

Scenario-based ValidationScenario DB

ImplementationTesting

OBJECT ORIENTEDIMPLEMENTATION

Figure 4. Verification and Validation (V&V) Oriented Development Methodology for HLA-Based

Distributed Simulations


2.1.1 Conceptual Model (CM)

Simulation Conceptual Models serve some different purposes. From the users perspective, the conceptual model provides the documentation necessary to understand the simulation capabilities and limitations. From the developer’s perspective, the conceptual model serves as an agreement about what is to be developed. It represents how developers understand the problem domain. From a communication perspective, the conceptual model serves as a communications link between users and developers.

The proposed methodology suggests two representations of a conceptual model; namely, informal conceptual model and formal conceptual model.

An informal CM will be used especially by the sponsor and the user group, which we can call CM users. Informal CMs help CM users to assess the capabilities and the intended focus of the simulation without any technical background. An informal CM can easily be validated by a domain expert (called Subject Matter Expert (SME)), who generally has no technical background of the simulations and the software. We can accept this as the main technique for conceptual model validation. Meanwhile, being informal does not imply being unformatted. The scientific paper-based approach [12, 13], promoted by DMSO, can be used for representation of the informal CM.

On the other hand, a formal CM representation will be directly used by the CM developers, who may modify or redevelop the conceptual model. At the same time, formal CMs can be applied to solve disputes when there is uncertainty or disagreement in the informal CM (e.g., two people can infer different things by reading the same sentence in informal CM). Another of the main objectives of a formal CM is to transform a conceptual model into machine-understandable form. In this respect, it will be possible to provide the conceptual model to all kinds of software tools (e.g., V&V tools, HLA federates) and software agents (e.g., web robots). Note that it may not always be practical to formalize all of the conceptual model (e.g., a CM may include some photos, charts, etc.). An UML-based ontology is suggested for the formalization of the conceptual model. This will also ease the transformation between models and layers due to the use of the same notation.

2.1.2 CM Validation Using Scenarios

Scenarios can be used as a supporting validation technique for formal CM validation. Simulation requirements are captured as use cases by using use case requirements analysis techniques [15]. These use cases (a.k.a. use case scenarios) provide the main part of the simulation scenarios. Then, CM will be meaningful according to its level of support for scenarios. The meaning of support should be defined operationally within the overall problem domain. Simply, entities, actions, relationships, states, and parameters implied by scenarios should exist in CM representation. The other important point is to formalize scenarios by using ontology languages. The ontology-based scenarios should then be saved in a database to assist reusability.


2.1.3 Federation Design Model (FDM)

As simulations have become more distributed, it has become more important to design the information flow and interactions between components (specifically federates in HLA federation) in a simulation.

In HLA-based distributed simulations, the design model includes, but is not limited to:

• Forming federation and simulation object models (e.g., designing static object interests of federates (or designing declaration management interface)),

• Designing dynamic object flows (e.g., designing dynamic data distribution properties (data distribution management interface)),

• Designing dynamic object interests of federates (e.g., designing object management interface),

• Designing execution environment (e.g., host configurations, network configurations).

A set of metamodel extensions to UML, called a UML profile for HLA federation design, is prepared to support a more formalized and standardized description of the federation design and documentation. The proposed UML profile is presented in [28, 29]. In most cases, we encourage using a combination of UML profile for HLA and predefined standard UML model elements in the representation of the federation design model. The FDM will serve as a transformation form between the validated ontology-based conceptual model and the detailed software design. A case study is presented in section 4 of Appendix A showing how to use the proposed UML profile in federation design.

2.1.4 Federation Design Verification

Once the FDM has been developed it must be verified that it provides a reliable transformation from formal CM to FDM. The FDM includes more detailed information than a conceptual model (while the focus of CM is in the mission/problem space, the focus of FDM is in simulation/application space).

2.1.5 Detailed Design (DD):

Detailed design briefly depicts the internal structure of the components in detail and it is the most important design effort before the implementation, and can be seen as the skeleton of the components.

At the end of the federation design activity, if the components, which compose the distributed simulation, are ready at hand, then there is no need for detailed design.


However, if the federation design model implies a requirement to develop a new component or to modify an existing component, then a detailed analysis and design that is focused on the component must be conducted.

Case 1 (a detailed design required): Since UML is recommended for the overall federation, it will be a complementary choice to use object oriented analysis and design techniques and UML in designing each federate’s internal structure. The detailed federate design, with the federation design, will enable CASE tools to generate software code automatically to some degree.

It is suggested that federate internal design conform to the layered structure presented in Figure 5.

BEHAVIORAL MODULESREPOSITORY

USER INTERFACE MODULESREPOSITORY SIMULATION/FEDERATE

ORIENTED MODULES

RTI AMBASSADOR FEDERATE AMBASSADOR RTIORIENTED MODULES

FEDERATION ORIENTED(e.g., Tracking Sub-System, Message Dispatcher) FEDERATION

ORIENTED MODULES

RUN TIME INFRASTRUCTURE (RTI)

Figure 5. Layered Software Architecture for Federate Design

This layered architecture provides some advantages:

• By separating the modules, reusability is enhanced both in design and implementation phases.

• Encapsulation is achieved in the architectural level. Each layer could be thought of as a black box. The designer of one layer does not need to know the internal modular design of the other layers.

Simulation or federate oriented modules are related to the simulation capabilities of a federate. These modules have nothing to do with HLA or network concepts; they merely model and simulate some real life entities. Federation Oriented Modules satisfy the federation-wide needs of the federate. For example, these modules may track other entities and filter the messages in the federation. RTI-oriented modules are dedicated to communication related jobs. They are responsible for communicating with the RTI (run time


infrastructure) and receiving callbacks. This internal architecture has been applied successfully in the development of some naval federations [30,31]. Case 2 (federates at hand can be reused for a new federation): The following rules-of-thumb can be followed to select/determine federates in a complex project:

• Check that the Simulation Object Model (SOM) of the candidate federate satisfies the published classes and interactions from the FDM.

• Check that the needs (in terms of objects and interactions) of the candidate federate are satisfied by other federates.

2.2 Tools Despite that the proposed methodology is independent from the presented tools in Table 1, the support for each phase of this methodology by a tool is important. The existence of tools helps to automate many activities and eases the development activities for M&S developers. The following table summarizes the categorization of tools that may be employed in the vision. Although the presented tools below are examples only, they increase the applicability of the proposed methodology.


Table 2. Categorization of Tools1

PHASE SUB-PHASE EXPLANATION TOOLS

Scenario Development Tools

Scenario development tools are used to automate the activities of the development, editing, and classification of the simulation scenarios

No Available Tool Exists

UML-based Ontology Modelling and Development Tools

They are used in developing and in modelling the ontologies, which composes the formal conceptual model. They are also employed in the formalization of the simulation scenarios.

DUET plug-in for argoUML and Rational Rose [32] Medius Visual Ontology Modeller2 plug-in for Rational Rose

Ontology Consistency Checkers and Verification Tools

They are employed to check structural consistency of ontologies

Presented in chapter 4

Conceptual Model

Conceptual Model Validation Tools

They are used to validate the formal conceptual model by using scenarios.


Federation Design Modeller

It is a plug-in to general UML CASE tools to support UML profile for HLA

No Available Tool Exists Federation Design

Design Verification Tool

They are used to check structural consistency of the UML models.


UML Modeller General UML CASE tool. Rational Rose [33] argoUML [34]

Detailed Design

Design Verification Tool

They are used to check structural consistency of the UML models.


Languages Selection is dependent RTI API or RTI Binding Support

OO Languages

Development Environment

No support for UML Profile for HLA Simplicity3 Simbuilder4

Execution Model

Results Validation Validation of simulation execution results vs. real life results

Statistical Analysis Tools can be employed according to the application, data, and analysis required.

1 The variety of tools can be simplified when plug-ins are available, for example, argoUML with “ontology modelling plug-in” and “UML-Profile-for-HLA plug-in” can be used in CM, FDM, and DD. 2 http://www.sandsoft.com/ 3 http://www.calytrix.com 4 http://www.eugenuity.ca


http://www.sandsoft.com/

http://www.calytrix.com/

http://www.eugenuity.ca/

2.3 Lifecycle The development lifecycle clarifies and presents the activities necessary to develop the models specified in the methodology section. Even if it is not required to develop new components or modify the existing ones, the Federation Design and Execution Process (FEDEP) [6] can be used as a lifecycle model, which also will support the vision and the development methodology. If the development of some new components is required, then the presented development lifecycle can be used in conjunction with FEDEP. The development lifecycle is composed of FEDEP and object oriented analysis and design (OOAD) methodology based on an iterative and incremental paradigm. In the lifecycle, mainly the following items are considered:

• It is required to develop some federates in parallel to the federation development and execution process, because each of the federates is not always ready at hand.

• It is required to modify some federates at hand for re-use.

• It is required to provide support for the development methodology presented in section 2.1.

The development lifecycle is successfully applied to a case study explained in [30,31]. Figure 6 shows a single iteration of the lifecycle where the number-of-runs (iterations) are project dependent. The first run takes much more time than other runs and has the least functionality since it is populated with stub methods and processes. Each run enriches an existing program by adding functionality. At the end of the last iteration, the new or modified classes and federation and simulation object models (FOM/SOM) may be added to a code library (called a module repository) for code re-use and to an object model library for model re-use respectively.


RequirementAnalysis

Conceptual ModelDevelopment

FederationExecution Evaluation

START

ITERATION

NEXT

ITERATION

OOAof

Federates

OODof

Federates

FEDERATION DESIGNAND

DEVELOPMENT

FederationIntegration

Implementationof

Federates

OBJECT MODEL LIBRARY

Library of FOMs Library of SOMs

[public]

MODULES REPOSITORY for Code Re-use

Library of BehavioralModules

(e.g., in C++ API)

Library of User InterfaceModules

(e.g., in C++ API)

[public]

SOMs FOM

FED

RID

FEDERATE DESIGN

Classes

Implemented/ModifiedFederates

FEPW

{at last iteration}

{at last iteration}

Classes

FOMSOMs

FOM SOMs

Figure 6. Development Lifecycle


Following thorough the flow of Figure 6, the first step is the requirements analysis phase. This phase includes:

• Defining the interest domain

• Defining the problem statement

• Defining federation objectives and goals

• Defining requirements (simulation requirements, graphical user interface requirements, and hardware requirements)

• Defining simulation specifications

The Conceptual Model Development phase includes:

• Developing federation scenarios

• Developing Federation Conceptual Model (FCM) (first informal CM, then formal CM)

Figure 7 summarizes the analysis and conceptual model development activities. Goals

ObjectivesRequirements

use-cases

Conceptual Model(formal andinformal)

SimulationScenarios

Specifications

Use-Case Analysis

FDM Figure 7. Analysis and Conceptual Model Development Phase Activities

Federation design and development phase, and analysis and design of federates are parallel activities. The Federation design phase includes:

• Defining system components

• Defining initialization and termination scenarios of the system

• Defining system wide principles

• Defining federation components

• Developing FDM


• Constructing FOM

Federation Integration and Testing phase includes:

• Federate Testing

• Integration Testing

• Federation Testing

In summary, the typical activity steps in the federation development lifecycle shown in Figure 6 are:

• Capture and standardize requirements using use case analysis techniques

• Develop ontology-based scenarios

• Develop an informal conceptual model and validate the informal CM using a SME review technique

• Develop a formal conceptual model and validate the formal CM using scenarios

• Design the federation using UML profile for HLA

• Verify the federation design using CASE tool syntax and consistency checking capabilities

• If new components are needed, design software using object oriented design techniques

• Implementation

• Validate the results with real life data if available


3. Conceptual Model Representation It is proposed that two forms of conceptual model (CM) representation be used: informal and formal. Before presenting the details of conceptual model representation, we will briefly overview the potential users and the potential content of the conceptual model.

3.1 User Profiles In general, we can categorize the users of a conceptual model into three groups. These groups are:

• CM Users/Sponsors: The sponsor and user group who need and who use the simulation respectively. This group is generally experienced in the problem domain and does not have software/simulation development experience or technical background.

• CM Developers: This group consists of the people who will develop, change, and re-use the CM, and the simulation developers (i.e., software designers and programmers).

• Non-Human Users: All kind of software tools and software agents. For example, V&V tools, HLA federates, and other simulation elements (e.g., computer generated red forces).

3.2 Conceptual Model Content and Limits

• Mission Space/Problem domain Elements:

o Entities (e.g., a surface vessel)

o Entity Attributes/Descriptive Variables (e.g., the course of the vessel)

o Functions/Actions (e.g., changing the course)

o Relationships/Interactions (e.g., frigate is a surface vessel)

• Assumptions (e.g., signal attenuation in underwater acoustics is due to spherical spreading only) and problem domain pre- and post-conditions (input, output)

• Constraints1/Bounds/Limitations2 (e.g., operational area is 50x50 km)

• Domain Specific Algorithms (e.g., target motion analysis (TMA) algorithms in target localization)

1 Constraint=Restraint 2 Limitation=Restriction


The following documents can be considered as part of the conceptual model. They are generally used to capture the items presented above by use of verbal sentence analysis and use case methodology techniques [15].

• Scenarios

• The aim of the simulation: Objectives, Requirements, Research Questions

• Experimentation or Usage Plan for the Simulation

• Any authoritative information explaining the intended problem domain (e.g., military operation concepts)

The extent of the content and limits of the conceptual model is an open research question. In the literature, some researchers also include simulation domain elements in which this makes the conceptual model more application specific.

3.3 Informal Conceptual Model (Informal CM) An Informal CM especially will be used by the sponsor group and the user group. CM users can easily understand the capabilities of the simulation without technical information by reviewing the informal CM. Note that being informal does not imply being unformatted. We can claim that one of the best-documented domains is the military domain. The art of war is generally documented as military operational concepts. In many cases (if a military concept coincides with the objectives of the simulation), we can accept a military operational concept as an informal conceptual model directly. If the content of the simulation limits the existent military concept or the objectives of the simulation do not coincide with the military concept, then military concepts may be used only as authoritative information sources. The informal CM may be a subset of a couple military concepts. The scientific paper-based approach [12,13] can be used for the representation of an informal CM. However, although this approach includes a section entitled “basic elements of the entities and processes”, it does not define a specific representation to identify the entities and processes. Therefore, the following techniques extend this approach by explicitly stating the domain concepts, entities, and their relations in a predefined form. Domain concepts can be captured by using a use case methodology used in object-oriented analysis and design [15] and noun-verb analysis in natural language. For example, a military concept may state that: “If a number of vessels are traversing a narrow strait…” The simulation developer can select and mark the nouns and verbs in these statements and then he/she can select the important domain concepts and entities by interviewing the domain experts (e.g., vessel). The table in Figure 8 has been developed to document the domain concepts and entities. Entity is the term for things in the problem domain; it is characterized by a description, its attributes, its functions, and its relationships with other entities in the problem space. Attributes are defined by a name, a type, and limit information if applicable. Operations (a.k.a. member functions) related to the entity are expressed in terms of a name, input variables, and output variables. Relationships or interactions between entities can be expressed as text descriptions. These tables will also ease the development of the formal conceptual model.


Entity Name Description

Name Type Limits Description Attributes

Name Input Variables Output Variables Description Operations

Relationships Interactions

Constraints

Examples of Instances

Figure 8. Domain Entities Table

An informal CM can be validated by domain expert (SME) reviews. It is important to use expert intuition, because the real world is not a formal presence. Therefore, the SME review technique is accepted as the main validation technique. Here, we use the term SME for domain expertise that is qualified to validate the conceptual model. A case study showing how to develop and document an informal conceptual model is presented in part 2 of Appendix A.

3.4 Formal Conceptual Model (Formal CM) A Formal Conceptual Model is directly used by the CM developers and non-human users. If there is a disagreement in the informal CM (e.g., due to the different interpretation of natural language by different people), then the formal CM will be used as a solution base. One of the main rationales for the formal CM is to transform the conceptual model (or domain knowledge) into a machine-readable and machine-understandable form. This makes it possible for all kinds of software tools and agents to read and understand the conceptual model. A UML-based ontology is suggested for the formalization of the conceptual model, while the Object Constraint Language (OCL) is used for the formalism of the constraints in the conceptual model. In knowledge representation techniques, ontologies are gaining importance due to their high applicability and support to providing machine-understandable capabilities. Ontologies provide characteristics such as reusability due to their formal representations. Why ontology and UML are chosen is discussed in the following sections.

3.4.1 What is Ontology?

Ontologies were developed in artificial intelligence to facilitate knowledge sharing and reuse and to provide machine understandable semantics for information sources that can be communicated between software and humans [35]. Although there are many definitions, the following ones characterize the essence of an ontology:

1. Ontology is a formal representation of objects and relations between them in a specific domain. Formal representation refers to the fact that ontology should be machine understandable.


2. Ontology is a vocabulary of terms and the precise relationships between them (www.daml.org). Precise refers to the fact that the terms and the constraints on them should be explicitly defined.

The use of ontologies provides an effective way to describe objects and their relationships to other objects. A good introduction to ontology and the importance of ontologies in knowledge management is presented in [35]. A short review about ontology languages, tools, and some basic ontologies are presented in Appendix B.

Note that this study does not attempt to present an ontology development methodology or ontology development activities. There are some studies that present ontology development methodologies such as ontoClean [36] and formal ontological analysis (e.g., mereology).

3.4.2 What does an Ontology include?

An Ontology includes concepts, properties, axioms, values, and nominals. A frame in artificial intelligence (AI) and a class in object oriented (OO) modelling are seen as equivalent to a concept. Properties are equivalent to attributes in OO modelling. Nominals are concepts that cannot have instances, which are equivalent to abstract class notions in OO modelling. Axioms are constraints on properties and concepts (e.g., type constraints, cardinality constraints).

Instantiating a defined ontology by adding specific instances and inference rules gives a Knowledgebase (KB). A conceptual model includes both an ontology and an associated knowledgebase. The following table summarizes the terms and defines what ontology includes.

Table 3. Ontology-OO Modelling Analogy

ONTOLOGY TERMS OBJECT ORIENTED (OO)

METHODOLOGY TERMS

FRAME-BASED TERMS

EXAMPLE

Concept Class Frame Frigate

Property Attributes/Roles Slot Speed of the ship

Relationships Class Relationships (association, aggregation, generalization)

Slots/Facets Frigate is a sea vessel

“inheritance relationship”

Actions Operations/Member Functions

Facets Turning the ship

Axiom/Constraint Constraint - Speed < 40 knots


http://www.daml.org/

Values Defaults Defaults Economic speed = 18 knots

Individuals/Instances Object Instances HMCS Halifax, TCG Muavenet

Nominals Abstract Classes - Sea vessel

Ontology (KR language schema) = Concept + Property + Axiom + Values + Nominals

Knowledgebase = Instances (+ rule base)

Conceptual Model = Ontology + Knowledgebase

3.4.3 Ontology Representation

Figure 9 summarizes some well-known ontology representation techniques. Taxonomies

Ontologies

Thesauri TopicMaps

Semantic Nets

ExtendedER-Model

UMLDB Schema

RDF(S)Frames

Logics:Predicate Logics

F-LogicConceptual

GraphsDescription

Logics

Figure 9. Ontology Representation Paradigms (reproduced from [37])

Using UML in ontology representation is expected to ease the transformation of conceptual model to high-level software design.

3.4.3.1 Why UML?

The Unified Modelling Language (UML) is an industry standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system [38]. The UML notation is a fusion of the notations of Booch, Object Modelling technique (OMT), Object Oriented Software Engineering (OOSE) and others. UML for ontology development is promoted by [26, 39], and the main reasons are as follows:

• UML is generally accepted in software engineering community, widely adopted in industry, and taught in many university courses,

• UML is supported by many CASE tools. UML tools are more accessible to software practitioners than current ontology tools [39],


• UML has standard extension mechanisms for specific application domains,

• UML plays several roles simultaneously, supporting representation of the problem domain, the development artifacts, and the proposed software or simulation system, while fitting together as a tightly integrated, well-defined language [25].

3.4.3.2 Can UML represent an Ontology?

UML Class and Object diagrams are suggested to represent ontology and knowledge about the domains described in this ontology respectively [26]. UML class diagrams provide a rich notation for defining classes, their attributes, their functions, and relationships between other classes. They can be used to define ontologies in an object-oriented fashion. On the other hand, UML object diagrams express the instances of the classes in the class diagrams. Therefore, the knowledge about the domain described in the ontologies described using class diagrams can be expressed in the object diagrams.

The following example (Figure 10) presents an ontology describing family relationships (the UML class diagram in the left) and some knowledge about a particular family in the form of an object diagram (the UML object diagram in the right).

+name : string(idl)Person

Man Woman

+parent 2 +child*

{parent=Set{mother,father}son=child->select(oclIsTypeOf(man))daughter=child->select(oclIsTypeOf(woman))}

name : string(idl) = John Smith : Man

name : string(idl) = Mary Smith : Woman

name : string(idl) = Susan Smith : Woman

daughter daughter

father mother

{ordered}

{ordered}

{ordered}

+father

*

1

*

2

+son

+mother1

*

*

2

+daughter

parent

child child

parent

Figure 10. Example: Left Diagram: An Ontology as a UML Class Diagram, Right Diagram: Family Knowledge as a UML Object Diagram (reproduced from [26])

In this representation, Object Constraint Language (OCL) [40] is used to express the constraints in the domain. OCL can also be used to obtain problem solving information from the knowledge rules stated in the conceptual model.

Although the class and object diagrams can be used to represent an ontology, as seen in the example to some degree, they are not adequate to fully support


the ontology representations, because UML standard elements were originally designed for detailed software design (i.e., object oriented analysis and design) and then extended to cover the system requirements phase. Therefore, there are studies to extend UML in order to provide a full ontology representation support.

3.4.3.3 UML in Ontology

Presently, there are three options for using UML notation in the representation of ontologies.

UML Profile for OWL

OWL (Web Ontology Language) is designed for use by applications that need to process the content of information instead of just presenting information to humans [41]. OWL is a revision of the DARPA Agent Mark-up Language and Ontology Inference Layer (DAML+OIL) Web Ontology Language incorporating lessons learned from the design and application of DAML+OIL [42]. The purpose of the OWL, identical to Resource Description Framework (RDF) Schemas [43], is to provide an XML [44] vocabulary to define classes, properties, and their relationships. OWL provides much richer relationships than DAML+OIL and RDF. OWL is currently (April 2003) at the World Wide Web Consortium (W3C) Candidate Recommendation Stage.

The UML profile for OWL is still an ongoing work and it maps UML elements to OWL elements by extending UML stereotypes.

UML Profile for DAML+OIL

DAML+OIL, which is an extension of RDF, RDF Schema, and XML, provides a rich set of constructs with which to create ontologies and to markup information so that it is machine readable and understandable [42].

The UML Profile for DAML+OIL is used for translating DAML+OIL ontologies into UML models, and conversely, UML models into DAML+OIL ontologies.

UML 2.0

UML version 2.0 will be a major upgrade to UML Specification and in this version, built-in elements are planned to provide support for ontology representation. UML 2.0 will be ready in near future.

Figure 11 shows the ontology representation languages and the relations among them (refer to the list for acronyms).


Unicode URI

HTML XML + Name Space + XML Schema

RDF

RDF Shcema

DAML-Ont OIL

DAML + OIL

DAML-R

DAML-SOWL

SMILTopic MapsXOL

PICSDC

Figure 11. The Ontology Language Stack (reproduced from [48])

3.4.3.4 UML Profile for DAML+OIL

The mapping elements, mapping discussions, and detailed specification for UML Profile are explained in [32].

The DAML-UML Enhanced Tool (DUET) [32], which is a plug-in for the ArgoUML Computer Assisted Software Engineering (CASE) tool, provides a UML-based environment for the visualizing, developing, and manipulating DAML+OIL ontologies. This plug-in enables it to import and export DAML format files (i.e., .daml) into argoUML CASE tool.

A case study showing how to develop and document a formal conceptual model using the informal model is presented in part 3 of Appendix A.

3.4.4 Using OCL in the Formalism of Constraints

Object Constraint Language (OCL) is a formal language used to express constraints [40]. OCL is a pure expression language in which an OCL expression is guaranteed to be without side effect. OCL is used to express and formalise the rules associated to UML notations.

In a formal conceptual model, OCL is used as a formalism language for stating the assumptions in the problem domain.

3.4.5 Using Tools in the Development of the Formal CM

The following items present the activities and the tools in the development of the formal conceptual model.


• First, use Protégé Ontology Editor Tool1 to map an informal conceptual model to an ontology environment.

• Protégé can transform the ontology into many ontology formats. These are DAML+OIL, OWL, RDF, UML, XMI, XML Schema, and XML DTD. Save the ontology in DAML format.

• Using ArgoUML (DUET plug-in must be installed), import “.daml” file to UML diagrams.

3.4.6 Research Issues

• One of the research issues is how much of the conceptual model must be formalized. It may not always be practical to formalize all parts of the conceptual model (e.g., some charts, maps). Therefore, it may be adequate to formalize the basic elements of the informal conceptual model. The important point in determining where to stop the formalization activity is in answering the question “can software agents understand it or not? If they can understand it then continue, if not then stop.

• The second issue is the simulation resolution and the simulation fidelity requirements. It is the hypothesis of this paper that if two federates (or simulations) share the same conceptual model or if their conceptual models are subsets of each other, then we can claim that they can be integrated without encountering a resolution or fidelity problem.

Hypothesis 1 (Argument 1) 2:

If two federates (or simulations) share the same conceptual model or if their conceptual models are subsets of each other, then they can be integrated without encountering a resolution or a fidelity problem.

• In a formal representation of a conceptual model, domain elements are represented in UML and domain assumptions and constraints are represented in OCL.

1 http://logic.stanford.edu/projects/protege 2 Argument-1: p: Federates share the same conceptual model. q: Their conceptual models are subset of each other. r: They can be integrated w/o a resolution or fidelity problem. Hypothesis (or premise) 1.1: if (p V q) then r; Hypothesis (or premise) 1.2: p V q; Conclusion 1.1: ∴ r.


http://logic.stanford.edu/projects/protege

4. Scenario-Based Conceptual Model Validation Generally, conceptual models are validated using domain Subject Matter Experts (SMEs). The quality of this validation process, although it is accepted as a main validation technique, depends on the subjective assessment of an expert. This process can be lengthy and very dependent on the individual SMEs involved. There is a need to automate, to support, and to formalize the conceptual model validation process. This chapter lays the ideas and some technical approaches for the conceptual model validation using scenarios.

4.1 Introduction In the military arena, scenarios are used as a validation method to test newly developed tactics and concepts by carrying out the scenarios in live exercises. This process validates the tactics only for those particular scenarios and circumstances, not in general or if any conditions change unless the process is accompanied by a sensitivity analysis. The use of scenarios for validation has been applied and used in the following areas: Software Engineering (e.g., for software testing), Telecommunications, Business-Process Reengineering, User Interface Design, and Conceptual Specifications [45]. Deriving a formal specification from informal requirements is an error-prone task unless a methodical approach is used. In the initial analysis phase of simulation development, if use-case requirements analysis is used, then each requirement will be captured as a use case (or use case scenario). These will help in the development of an informal conceptual model and simulation scenarios. Simulation scenarios are those that will be executed in run-time by simulation. The scenarios1 are the representation of simulation requirements. Therefore, if entities, relationships, states, parameters, limitations, and constraints implied by scenarios take place in the simulation conceptual model, then we can claim that conceptual model is valid.

4.2 Technique This technique is called Scenario-Based Conceptual Model Validation.

4.2.1 Scenarios

Scenarios generally include the traces of internal or external events, message exchange between components, interaction sequences between a system and its user.

4.2.1.1 Use Case Scenarios

Use case analysis is a technique for deriving system requirements by examining the behaviour of a system from the user’s perspective [15].

A use case specifies a sequence of actions that an actor performs within a system to achieve a particular goal [38]. A use case can be described in plain text, using

1 In this document, “the scenario” word itself refers to both use case and simulation scenario.


operations and methods together with attributes, in activity graphs and use case diagrams, by a state machine, or by other behaviour description techniques, such as pre-conditions and post-conditions. These descriptions are usually called use case scenarios.

The purpose of a use case is to define a piece of behaviour of an entity without revealing the internal structure of the entity. The level of detail is not high in order to help focusing on the real issues. Use cases complement the object-oriented approach and form the basis of the analysis and design process. Use cases are also used in software testing.

Use case scenarios are expressed by using UML use case diagrams and then Interaction diagrams are used to describe how use cases are realized as interactions among societies of entities. They represent the system requirements.

4.2.1.2 Simulation Scenarios

Simulation scenarios are real-life situations, which will be represented in the simulation at run time. The format of simulation scenarios can be text files as well as application specific.

Simulation scenarios generally include:

• Instantiation of domain objects (i.e., particular objects) for example, a specific frigate – HMCS Halifax.

• The initial position, posture, and conditions of domain objects (e.g., position, speed, course, and depth of a sea vessel)

• The injections during execution (e.g., man overboard in HMCS Halifax at x time and date)

• Deletion of domain objects

Simulation scenarios generally use a natural language description to explain the situation; for example:

A number of vessels are traversing a narrow strait. The ownship is following a zigzag path along one side of the strait, as appropriate for TMA using a towed array. Additional sonar information is …

Then they are refined to an application specific format (e.g., XML) in order to be executed and used in the simulation runs. For example:

-<gc:Scenario StartTime="00:00:00" StopTime="02:00:00" xmlns:gc="http://www.drdc-rddc.gc.ca/Namespace/drdca/vmsa/gc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.drdc-rddc.gc.ca/Namespace/drdca/vmsa/gc .\..\Gameboard.xsd">

-<gc:AddVessel Affiliation="Blue" Name="CA_Vessel" Time="00:00:00"


Type="SeaSurface.Military.Warship.Frigate.Canada...CA_Vessel">

<gc:Position Latitude="2.47788739869363" Longitude="101.716636321791" />

<gc:Speed Value="12" Units="KNOTS" />

<gc:Course Value="94.87399" />

<gc:Depth Value="0" Units="METRES" />

…

The two formats complement each other by providing different views of the same information.

4.2.2 A Simple Example

Requirement:

A sonar operator will make associations and disassociations of sonar tracks using software, which displays passive sonar tracks in a bearings-over-time chart.

This requirement includes a couple of use-cases. They are:

• Sonar operator use of a software tool interface

• Sonar operator makes associations and disassociations

• Software tool displays passive sonar tracks in a chart

Here, the sonar operator is a principal actor who uses the main system functions. Figure 12 shows the UML use-case diagram.

Sonar Operator

Making a decision

Making Association

MakingDisassociation

«uses»

«uses»

Software

triggers

Figure 12. Example of a UML Use-Case Diagram

In the following figure, “making-association” use-case is represented as a UML sequence diagram.


Sonar Operator Software Tool

Select first track or track segment using mouse

Mark track as selected

Select second track or track segment using mouse

Mark track as selected

Repeat above process as needed

Click associate button

Delete old tracks from the display

Display new master track

Log assocition time, track numbers, and association generator

Figure 13. A Simplified Sequence Diagram for “Making-Association” Use Case

This use-case scenario reveals some key domain elements and event sequence, such as operator, track, track segment, master track, association, track display, some data logging requirements (i.e., association time, track number). This allows us to check whether the key elements are included in the conceptual model or if they can be mapped onto an element in the conceptual model. If they are not included in the simulation conceptual model, then the conceptual model must be modified and corrected.

These types of scenarios are used both in preparing the conceptual model and in checking that the conceptual model includes the scenario entities. Also, note that they can be used as test cases for software verification.

Examples can be given for simulation scenarios. If the simulation scenario mentions that “While HMCS Halifax is transiting from point A at time X, she detects a sonar track bearing 180 via her passive broadband towed array sonar, which is assumed to be located in the ship …”, then this scenario indicates an assumption that the positions of the towed array and the ship are the same. Therefore, we can check whether or not this assumption is included in the simulation conceptual model.


4.2.3 Comparison and Automation

Validation is based on the ability of the comparison of the scenario information with the formal conceptual model. In order to achieve this, scenarios must be represented by using ontologies1. Then, both forms (formal CM and scenarios) will be ontology-based and the comparison problem will be reduced to the comparison of two ontologies. If suitable ontology languages are used automatic comparison may be possible.

The automation for comparison will be possible due to the increased precision in the description of scenarios and the conceptual models.

In the literature, there are some studies that deal with the comparison of ontologies with the intervention of human experts [46-48]. In addition, in [46, 49], a relatively simple model, called MD3, is presented to compare ontologies in a completely automated manner. This approach is based on connecting two ontologies using a common imaginary root and then using a comparison algorithm, which uses breadth-first traversals of the ontology trees [46].

4.3 Supporting Tools In the literature, there are also some tools for the validation of ontology itself. They generally check for syntax problems, provide you with a listing of errors and pointers to the error in the ontology file. Some of these are OWL Validator2, OWL Ontology Validator3, and DAML Validator4.

4.4 Discussions The scenario-based conceptual model validation technique is based on the following hypothesis.

Hypothesis 2 (Argument 2):

If entities, relationships, states, parameters, limitations, and constraints implied by scenarios take place in the simulation conceptual model, then conceptual model is valid.

1 The same proposals mentioned in chapter 3 (i.e., OWL and DAML+OIL can be used as ontology format) 2 http://owl.bbn.com/validator 3 http://phoebus.cs.man.ac.uk:9999/OWL/validator 4 http://www.daml.org/validator


http://owl.bbn.com/validator

http://phoebus.cs.man.ac.uk:9999/OWL/validator

http://www.daml.org/validator

5. Results and Conclusions This study prepares the technical ground for conceptual model representation and validation. As well it presents a framework for the distributed simulation development. Using this preparation, it presents techniques for conceptual model representation and conceptual model validation based on the proposed framework. This study also presents a simple real-life case study, in Appendix A in order to show how to apply the proposed techniques. One of the main aims of this technical document is to open a discussion for the proposed techniques.

5.1 Contributions of This Work This study proposes:

• A technical framework for developing HLA-based military simulations with verification and validation support. This technical framework includes a methodological view, tool-support view, and a lifecycle view and states the technical ground.

• Extensions to the paper-based approach proposed by US DMSO [12] for the representation of the informal conceptual model. The use of domain entities table are proposed as a tool

o To explicitly state the domain entities, attributes, relations, and operations

o To ease the development of a formal conceptual model

o It is also shown how we can connect the requirements to informal conceptual model and how to develop the informal conceptual model from the requirements

• A representation technique for the formalization of a conceptual model using ontologies. This representation technique may be classified as a design accommodation approach, however it overcomes the problems introduced by the design accommodation approach by providing a method for capturing assumptions and limitations inherent in the conceptual model. It also eliminates the necessity for the problem domain SME to understand the software formats by providing automation support for validation. This technique also eliminates the weak point of conceptual model-based methods in the use of different notations for the problem space system view and the solution system view by using a well-known and widely accepted notation, UML.


5.2 Advantages

• A conceptual model and a scenario repository may be created during the simulation development activities due to the reusability of ontologies and UML models.

5.3 Disadvantages

• UML currently lacks a complete formal definition but the study for UML formalization continues under the Precise UML Study Group.

• It may seem expensive to develop a conceptual model first, especially for large-scale simulations. However, due to the reusability characteristics of ontologies, after the first effort, the others will be developed more quickly.

• Formalization generally introduces a complexity to the development efforts. To develop a formal conceptual model, experts who have the knowledge about software engineering (UML, OCL), knowledge engineering (knowledge representation), and ontology engineering (OWL, DAML+OIL) are necessary to guide the process.

5.4 Future Work Work is continuing on:

• Refining the conceptual model representation and validation techniques after applying the proposed techniques on a real life case study. The results that will be obtained from this process will yield more realistic approaches to distributed simulation development and validation.

• The specification of a federation design model and then connecting the federation design and conceptual model layers.

• Developing a federation design verification technique.

• UML 2.0 (a major upgrade to UML) will provide support for ontology representation, and then this study should be revised to include UML 2.0 standard elements instead of using a UML profile for OWL and DAML+OIL.


6. References

1. Zeigler, P. B., “Theory of Modelling and Simulation”, A Wiley-Interscience Publication, 1976.

2. Topçu, O., “Review of Verification and Validation Methods in Simulation: Literature Survey, Concepts, and Definitions”, Defence R&D Canada – Atlantic (DRDC Atlantic) Technical Memorandum (TM 2003-055), Halifax, NS, Canada, April 2003.

3. Merriam-Webster Online Dictionary, http://www.m-w.com, Meriam-Webster Online the Language Center, accessed Apr 03, 2003.

4. Borah, J., “Conceptual Modelling – The Missing Link of Simulation Development”, Simulation Interoperability Workshop Spring (02S-SIW-074), 2002.

5. Pace, D. K., “Simulation Conceptual Model Development”, in Simulation Interoperability Workshop (SIW) Spring (S00-SIW-033), 2000.

6. Defense Modelling and Simulation Office (DMSO), “HLA Federation Development and Execution Process (FEDEP) Model, version 1.5”, December 8, 1999.

7. Cuneyd, F., “Conceptual Modelling and Conceptual Analysis in HLA”, Fall Simulation Interoperability Workshop Paper Proceedings, 2000.

8. Birta, G.L. and Ozmizrak F. Nur, “A Knowledge-Based Approach for the Validation of Simulation Models: The Foundation”, ACM Transactions on Modelling and Computer Simulation, Vol. 6, No.1, pp. 76-98, January 1996.

9. IEEE 1516 Standard for Modelling and Simulation (M&S) High Level Architecture (HLA) – Framework and Rules, 21 September 2000.

10. IEEE 1516.1 Standard for Modelling and Simulation (M&S) High Level Architecture (HLA) – Federate Interface Specification, 21 September 2000.

11. IEEE 1516.2 Standard for Modelling and Simulation (M&S) High Level Architecture (HLA) – Object Model Template Specification, 21 September 2000.

12. DoD VV&A Recommended Practices Guide (DOD VVA RPG Build 2) in http://vva.dmso.mil, accessed May 30, 2003.

13. Pace, D. K., “Conceptual Model Descriptions”, Simulation Interoperability Workshop (SIW) Spring (99S-SIW-025), 1999.


http://www.m-w.com/

http://vva.dmso.mil/

14. Insfran E., Pelechano V., and Pastor O., “Conceptual Modelling in eXtreme”, Elsevier Information and Software Technology Journal, Volume 44, pp.659-669, Aug 2002.

15. Jacobson I., Christerson M., Jonsson M., and Overgaard G., “Object-Oriented Software Engineering: A Use Case Driven Approach”, Addison-Wesley, ACM Press, 1993.

16. Pastor O. and Ramos I., “OASIS Version 2(2.2): A Class-Definition Language to Model Information Systems”, Servicio de Publicaciones Universidad Politecnica de Valencia, (SPUPV-95.788), Valencia, 1995.

17. Sheehan J., et. al., “CMMS: Basic Concepts, Advanced Techniques, and Pragmatic Examples”, Simulation Interoperability Workshop Spring (98S-SIW-127), spring 1998.

18. Johnson, T. H., “Mission Space Model Development, Reuse and the Conceptual Models of the Mission Space Toolset,” 98 Spring Simulation Interoperability Workshop Papers, Volume 2, pp. 893-900, March 1998.

19. Sheehan J., Prosser T., Conley H., Stone G., Yentz K., Morrow J., “Conceptual Models of the Mission Space (CMMS): Basic Concepts, Advanced Techniques, and Pragmatic Example”, 98 Spring Simulation Interoperability Workshop (SIW), vol. 2, pp. 744-751, March 1998.

20. Pace D.K., “M&S Correctness and Credibility”, I/ITSEC 2002 Tutorial Presentation, Orlando USA, December 2002.

21. Schach, S.R., “Software engineering (3rd ed.), Irwin, Homewood, IL, 1996.

22. Yourdon, E., Structured Walkthroughs (3rd ed.), Yourdon Press, NY, 1985.

23. Milks W.A. and Proctor D. M., “Augmenting Model Validation with Simulation Graph Models”, in proceedings of I/ITSEC 02, December 2002.

24. Yucesan E. and Schruben L., “Structural and Behavioural Equivalence of Simulation Models”, ACM Transactions on Modelling and Computer Simulation, Vol.2 2, No. 1, pp. 82-103, January 1992.

25. Opdahl L. A. and Henderson-Sellers B., “Ontological Evaluation of the UML Using the Bunge-Wand-Weber Model”, Springer International Journal on Software and Systems Modelling, 1:43-67, 2002.

26. Cranefield S., “Networked Knowledge Representation and Exchange Using UML and RDF”, Journal of Digital Information, volume 1 issue 8, 2001-02-15, February, 2001.

27. Baclawski K., et al., “Extending UML to Support Ontology Engineering for the Semantic Web”, UML Conference, Toronto, Canada, October 2001.


28. Topçu O and Oguztuzun H., “Towards a UML Extension for HLA Federation Design”, in the Proceedings of 2nd Conference on Simulation Methods and Applications (CSMA-2000), pp 204-213, Orlando, FL, USA, Oct. 29-31, 2000.

29. Topçu O, Oguztuzun H., and Hazen M.G., “Towards a UML Profile for HLA Federation Design, Part II”, in the Proceedings of Summer Computer Simulation Conference (SCSC-2003), pp. 874-879, Montreal, Canada, July 19-24, 2003.

30. Topçu O and Oguztuzun H., “Design of a Naval Surface Tactical Maneuvering Simulation System”, in the Proceedings of 31st Summer Computer and Simulation Conference (SCSC-1999), pp 319-324, Chicago, Illinois, USA, July 11-15, 1999.

31. Topçu O, “Naval Surface Tactical Maneuvering Simulation System”, Middle East Technical University Computer Engineering Department Master of Science Thesis, Ankara, Turkiye, 1999.

32. AT&T Government Solutions Inc., “DUET User Guide”, http://codip.grci.com, accessed Aug 06, 2003.

33. Rational Software, “IBM Rational Rose”, http://www.rational.com, accessed Jun 03, 2003.

34. Tigris.org Open Source Software Engineering, “argoUML”, http://argouml.tigris.org, accessed Jun 03, 2003.

35. Fensel D, “Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce”, Springer-Verlag Berlin Heidelberg, 2001.

36. Guarino N, “Ontology Driven Conceptual Modelling”, ER 2002 Tutorial, 21st International Conference on Conceptual Modelling, Tampere, Finland, Oct. 7-11, 2002.

37. Goble C. and Shadbolt N., “Ontologies and the Grid Tutorial: Part-2 Representation”, Ontology and the Grid Tutorial Presentation from the Semantic Grid, July 2002.

38. Object Management Group (OMG), “Unified Modelling Language (UML) Specification v1.5”, March 2003.

39. Kogut P. et al., “UML for Ontology Development”, KE Review Journal Special Issue on Ontologies in Agent System (online), 2002.

40. Object Management Group (OMG), “Object Constraint Language (OCL) Specification v1.5”, March 2003.

41. McGuinness D.L. and Harmelen V.F., “OWL Web Ontology Language Overview”, W3C Working Draft, March 31, 2003. http://www.w3.org/TR/owl-features/, accessed Aug 03, 2003.


http://codip.grci.com/

http://www.rational.com/

http://argouml.tigris.org/

http://www.w3.org/TR/owl-features/

http://www.w3.org/TR/owl-features/

42. DARPA, “DAML: DARPA Agent Mark-up Language”, http://www.daml.org, accessed Aug 06, 2003.

43. World Wide Web Consortium (W3C), “Resource Description Framework (RDF) Model and Syntax Specification”, http://www.w3.org/TR/rec-rdf-syntax, accessed Aug 06, 2003.

44. World Wide Web Consortium (W3C), “Extensible Markup Language (XML)”, http://www.w3.org/XML/, accessed Aug 06, 2003.

45. Lalioti V. and Theodoulidis B., “Use of Scenarios for Validation of Conceptual Specifications”, in the Proceedings of the 6th Workshop of the Next Generationat CASE Tools (CaiSE95), Jyvaskyla, Finland, 12-13 June 1995.

46. Gustavo A.G., Amandi A., Sichman J.S., and Godoy D., “Enriching Information Agents’ Knowledge by Ontology Comparison: a Case Study”, in the Proceedings of 8th Ibero-American Conference on Artificial Intelligence (IBERAMIA’02), Sevilha, Spain, 2002.

47. Fridman N. and Musen M., “An Algorithm for Merging and Aligning Ontologies: Automation and Tool Support”, in AAAI Workshop on Ontology Management, 1999.

48. McGuinness D., Fikes R., Rice J., and Wilder S., “An Environment for Merging and Testing Large Ontologies”, in the Proceedings of KR2000 International Conference, 2000.

49. Rodriguez M. A., “Assessing Semantic Similarities among Spatial Entity Classes”, PhD Thesis, University of Maine, USA, May 2000.

50. Mellema G. and Wentzell T.E., “Experimental Plan for VBE CA-1”, Defence R&D Canada – Atlantic (DRDC Atlantic) Technical Memorandum (TM 2003-158), Halifax, NS, Canada, April 2004.

51. Sowa J., “Knowledge Representation: Logical, Philosophical, and Computational Foundations”, PWS Publishing, 2000.

52. Canney S.A., “Virtual Maritime System Architecture Description Document Issue 2.00”, Defence Science and Technology Organisation Australia Document Number 00034, July 10, 2002.

53. Kendall E.F. and Dutra M.E., “An Introduction and UML Profile for the Web Ontology Language (OWL)”, presented at OMG’s 3rd Workshop on UML for Enterprise Applications: Model Driven Solutions for Enterprise, 2002.

54. Brachman R.J. and Schmolze J.G., “An Overview of the KL-ONE knowledge Representation Systems”, Cognitive Science, pp.: 9(2):171-216, 1985.



http://www.w3.org/TR/rec-rdf-syntax

http://www.w3.org/XML/

A. Appendix-A Case Study: Canadian Virtual Battle Experiment (VBE CA) This case study presents how to apply the scientific paper-based conceptual model representation as an informal conceptual model in part 2, how to formalize this conceptual model using ontologies in part 3, and then how to design the federation in part 4.

PART-1 Introduction and Research Objectives Virtual Battle Experiments (VBE), originally performed by the Australian Defence Science and Technology Organisation (DSTO), are aimed at, among other things, studying the data sharing and fusion problems in underwater tactical picture development. This experiment focuses on the broadband sonar track associations. The objective of the experiment is to understand how sonar operator situational awareness is affected, when one or two sets of track segments are available to the operator. The primary experimental mechanism will be the observation of the manual track association process [50].

PART-2 VBE CA Informal Conceptual Model This is a complementary work for:

• VBE objectives,

• VBE requirements,

• VBE scenarios, and

• VBE experimentation plan [50]

All of these documents constitute the VBE Informal Conceptual Model (CM).

Conceptual Model Identification Canadian VBE Conceptual Model dated 08 August 2003.


Points of Contact (POCs) For the Conceptual Model

Table 4. Simulation Developers - Points of Contact

Name Phone Fax E-Mail Specific Area Of Responsibility

Garfield Mellema (902) 426-3100 x-252

(902) 426-9654 [email protected]

Chief Scientist

Tania Wentzell (902) 426-3100 x-283


Experimental Design

Jason Murphy (902) 426-3100 x-256


Implementation

Okan Topçu (902) 426-3100 x-179

(902) 426-9654 oTopç[email protected]

Okan.Topç[email protected]

Verification and Validation

Conceptual Model Purpose The primary purpose of the conceptual model in this case is to provide a communications method between the experiment scientific authority and the experimental environment developers. The conceptual model must express the synthetic environment and environmental effects that the scientific authority requires in order to observe the phenomena required for the experiment, and express it in a manner that the developers can understand and implement. The initial representation of this model is contained in [50] and summarized in Part 1 of this appendix.

Conceptual Model Overview The experiment calls for a maritime synthetic environment driving a set of track management displays with which operators can interact. The synthetic environment needed to provide a number of broadband acoustic targets, at least two acoustic receivers, and model the effects of transmission loss and noise interferers on received signals. The environmental modelling was required to be sufficient that a tracking algorithm would produce the following track characteristics: Track initiation (initiated when there was detection in N of M last time steps) Track fading Track loss due to interference (lost when no detection for n of m last time steps) Track loss due to similar bearings The track management tools were required to provide a bearing-time display in which an operator could designate and associate track segments. Further, associated track segments were required to be dis-associatable. In addition, the operator had to be provided with a plan position display of blue force vessels, but not targets. A number of experimental tools were also required, such as data capture tools for the simulated environment, and tools to probe operator reasoning. Since this is a human in the


mailto:[email protected]










loop experiment to look at operator performance, it was required that the synthetic environment operate at close to real-time.

Basic Elements of the Entities and Processes While defining entities, instead of broadening the entity structure scope, we focused only on the entity groups directly related to VBE application domain. In this regard, VBE entities are mainly grouped in five categories:

• Vessel – Coalition Vessel • Environment – Acoustics, Terrain, Sea, Strait • Sonar – Broadband, Passive, Towed Array • Display – Track, Chart • Operator

The graphs used in the interactions/relationships representation can be seen as conceptual maps, but the notation is not the same with Sowa’s Conceptual Graph Language [51]. Table 5 summarizes and explains the notation used in this section.

Table 5. Notation Used in Informal Conceptual Model

GRAPHICAL NOTATION

EXPLANATION

Name

Indicates an entity or a concept in the problem domain

Name Indicates a bi-directional association between concepts

Indicates a constraint or a note related to concept or association

Indicates “include” relation between concepts

Indicates “is-a” relation between concepts

0..1, * Numbers indicate cardinality. “*” indicates multiple

The following tables first present the top-level interaction between entities and then focuses on details over entities.


VESSEL:

Vessel

Sea Vessel

Sea Surface Sub surface

Frigate SubmarineMerchantFish BoatRed Ship

Figure 14. Vessel Group

Sea Vessel

Description The word “vessel” includes every description of watercraft, used or capable of being used as a means of transportation on water. “Sea vessel” and “vessel” is used interchangeably. Name Type Limits Description Course Degrees 0-359 Speed Knots 0-No Limit Position (Lat, Long)

True in Degrees Lat: 0-90 Long:0-180

Depth Meters 0-N/A Class String N/A

Attributes

Source Level (SL)

dB -30 – N/A

Name Input Variables Output Variables Description

Change Speed Speed New Speed Change Course

Course New Course Operations

Change Source Level

Source Level New Source Level


Sea vessel moves in and injects acoustic energy into the environment.

SeaVessel

AcousticEnvironment

Inject (acoustic energy)

SeaVessel

TerrainEnvironmentmove in

{vessel.draft < terrain.depth}


Constraints Vessels cannot move in terrain that is shallower than its own draft.


Submarine, fish boat, merchant ship, and red ship entities are all inherited from the sea vessel.

Frigate

Description These vessels employ broadband passive towed array sonar and share their sonar track data with other class members. Name Type Limits Description

Attributes


Operations


Frigate employs a broadband passive towed array sonar and shares its sonar data (track and track segments) with other class members.

share (sonar data)Sea

Vessel Frigate

Operator Sonar

1

10..1

Constraints Frigate depth is always equal to zero (sea level).


Ownship and coalition ship are inherited from the frigate entity.


ENVIRONMENT:

Environment

Acoustics Terrain

Strait Sea

Figure 15. Environment Group

Acoustics

Description The medium through which acoustic signals travel from the sea vessels to the broadband passive towed array sonar. Name Type Limits Description Attenuation (α) dB/m 0-N/A Spreading Rate (SR)

- (1.0, 1.5, 2.0) User Specified

Attributes

Noise Level (NL) dBA User Specified


Operations


1. The environment attenuates the transmitted acoustic signals (causes transmission loss (TL) and otherwise modifies the transmitted acoustic signals).

2. It couples acoustic energy produced by the vessels, the ownship and the allied ship to the broadband passive towed array sonars.

Acoustics Sonar

Attenuate (source level,acoustic energy)

Constraints Spreading rate is equal to 1.5, because signal attenuation is due to a mix of cylindrical and spherical spreading.



Terrain

Description Bathymetry and elevation. The geographical constraints on the physical movement and position of the vessels. Name Type Limits Description

Attributes <position, elevation>


Operations


Sea Level 0

+

-

Above Water

Under Water Bathymetry

Elevation

Strait is inherited from terrain and strait has length and width attributes.

Constraints Sea vessel cannot be positioned above 0 elevation.



SONAR:

TowedArray

Sonar

Passive Active

Broadband

Figure 16. Sonar Group

Broadband Passive Towed Array Sonar

Description This device computes time series of bearings and signal-to-noise ratios representing acoustic emissions from locally observable sea vessels as propagated through the acoustic environment and received by sonar. Name Type Limits Description Track Enumeration 0-N/A Host Vessel Index 1-N/A Detection Threshold (DT)

dB N/A

Received Level (RL)

dB

Signal-Noise-Ratio (SNR)

dB

Directivity Index (DI)

dB Constant

Attributes

Position. Course, Speed

As for sea vessel

-


Calculate Range Ownship vessel position, target position

Range (R) in meters

Operations

Generate Track Range, SL, SR, α

Track Segment (bearing, time)



1. It’s carried by a frigate.

CoalitionVessel TA

2. It provides track segments that the operator can see on the track

display.

TA TrackDisplay

Send (track segments)

Constraints



DISPLAY:

Display

TrackDisplay

ChartDisplay

Figure 17. Display Group

Display

Description Displays the information for the operator to see and possibly interact with.

Name Type Limits Description Attributes


Operations


It displays the information for the operator to see and possibly interact with.

Display OperatorShow (track segment)

Constraints



Track Display

Description Displays recent track segments for the operator to see. It allows the operator to associate track segments into master tracks and disassociate master tracks into track segments. Name Type Limits Description Master Track Index 0-N/A Attributes Component Track

Index 1-N/A


Associate Track Segments Master Track Operations

Disassociate Master Track Track Segments


1. It receives track segments from the sonar.

TrackDisplay Sonarreceive (target track

segment)

2. The operator can associate track segments into master tracks. 3. The operator can disassociate master tracks into track segments.

Constraints



Chart Display

Description It displays the local terrain and the known positions of the ownship and coalition vessel for the operator to see. Name Type Limits Description

Attributes Map Binary


Operations


1. It receives terrain data from the terrain environment.

ChartDisplay Terrain

receive (<position,elevation>)

2. It receives position information from the ownship and coalition

vessel.

ChartDisplay

CoalitionVessel

receive (position)

Constraints



OPERATOR: Operator

Description A key interest in this experiment is the situational awareness of the human operator. The operator can view navigation information on the chart display and sonar information on the track display as well as associate and disassociate tracks. Name Type Limits Description Education - - Training - (High, Medium,

Low) Attributes

Expertise Years -


Operations Interact


1. The operator interacts with both chart display and track display. 2. The operator can associate and disassociate tracks on the chart

display.

Constraints



General Assumptions This section identifies the general assumptions and their implications. Assumptions define the constraints and boundary conditions of the intended simulation system. Environment:

• Signal attenuation is due to a combination of cylindrical and spherical spreading (because of the shallow environment).

• There is background noise, but no clutter or other environmental effects.

Track:

• Tracks are automatically initiated.

• Tracks are considered reliable.

• Support for manual track association is available.

Sonar:

• Sonar information is available in track format only.

• No other sensor information is available. Initially, a situation report will be provided to the operator.

• Position, course, speed of sonar are the same as the parent ship (host vessel).

Data:

• This simulation uses track-level bearings-only data.

• While the platforms (ownship and coalition ship) are co-operating, we assume that communication is being maintained continuously.

Identification of Algorithms • TMA algorithm

• Dead Reckoning (DR) Algorithms

• Track Generation Algorithm:

Transmission Loss (TL) due to Spreading Rate (SR):

SRSR RTL log10= {where R-Range}


Transmission Loss due to Attenuation (A):

RTLAα10=

Total Transmission Loss:

ASR TLTLTL +=

Received Level (RL):

TLSLRL −=

Signal-Noise-Ratio (SNR):

)( DINLRLSNR −−= {where NL-Noise Level, DI-Directivity

Index)

Comparison:

If SNR>DT then create_track() else do_nothing();

{DT-Detection Level}

Simulation Development Plans See VBE Experimentation Plan [50].

PART-3 VBE CA-1 Formal Conceptual Model Although this study can be seen as a stand-alone application-specific ontology, in fact it must also be connected to other upper level ontologies for consistency, integrity, and reusability. Figure 18 depicts the possible connections with other ontologies. An upper ontology defines the base concepts upon which lower ontologies are created. The domain ontology defines the terminology and concepts relevant to a particular topic. The task ontology defines the inputs, outputs, and sequencing information relevant to a particular business process.

UpperLevel

Ontology

DomainOntology

TasksOntology

ApplicationSpecificOntology


Figure 18. Ontology Connections

The following code snippets give some examples of how we can formalize a class, an instance, and how we can define an equivalent to other class by using OWL.

Defining Classes in OWL:

<OWL:Class rdf:ID=”Coalition Vessel”>

<rdfs:subClassOfrdf:resource=”Sea Vessel”>

</OWL:Class>

Defining Instances in OWL:

<?xml version=”1.0”?>

<Coalition Vessel rdf:ID=”Own Vessel” xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”>

</Coalition Vessel>

Defining a Class Equivalent to Other Class (in informal CM we indicate that sea vessel and vessel is used interchangeably):

<?xml version=”1.0”?>

<rdf:RDF xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#”

xmlns:rdfs=”http://www.w3.org/2000/01/rdf-schema#”

xmlns:owl=http://www.w3.org/2002/07/owl#>

<owl:Class rdf:ID=”Sea Vessel”>

<owl:equivalentClass rdf:resource=”vessel”>

</owl:Class>

</rdf:RDF>

There are two ways to formalize the conceptual model: in the first way, an ontology editor, which has a user-friendly interface, is used to create the ontology, which is then saved in a well-known ontology format (e.g., owl, rdf, daml). Finally, we can load it via a UML software engineering tool. The second way: If designer is experienced in UML, then he/she can directly use UML software engineering tools to create the ontology. The following figure shows a screen shot of the conceptual model transformed into an ontology editor format.


http://www.w3.org/1999/02/22-rdf-syntax-ns

http://www.w3.org/1999/02/22-rdf-syntax-ns

http://www.w3.org/2000/01/rdf-schema

http://www.w3.org/2002/07/owl

Figure 19. Protégé Ontology Editor Screen Shot

Once created, we can convert the ontology into some well-known ontology formats such as DAML and RDFS. The following excerpt shows a generated XML Metadata Interchange (XMI) file from the VBE conceptual model. Note that XMI files can be used to exchange UML models in transformation between conceptual model and federation design model. <?xml version = '1.0' encoding = 'ISO-8859-1' ?>

<XMI xmi.version = '1.2' xmlns:UML = 'org.omg.xmi.namespace.UML' timestamp = 'Mon Aug 11 14:09:36 ADT 2003'>

<XMI.header>

<XMI.documentation>

<XMI.exporter>Netbeans XMI Writer</XMI.exporter>

<XMI.exporterVersion>1.0</XMI.exporterVersion>

</XMI.documentation>

</XMI.header>

…


<UML:Comment xmi.id = 'a51' isSpecification = 'false' body = 'Displays recent track segment for the operator to see. It allows the operator to associate track segments into master tracks and disassociate master tracks into track segments.'>

<UML:Comment.annotatedElement>

<UML:Class xmi.idref = 'a2'/>

</UML:Comment.annotatedElement>

</UML:Comment>

<UML:Comment xmi.id = 'a52' isSpecification = 'false' body = 'Instances: submarine'>

…

<UML:Comment xmi.id = 'a63' isSpecification = 'false' body = 'The medium through which acoustic signals travel from the sea vessels to the broadband passive towed array sonar.'>

<UML:Comment.annotatedElement>

<UML:Class xmi.idref = 'a64'/>

</UML:Comment.annotatedElement>

</UML:Comment>

<UML:TagDefinition xmi.id = 'a65' isSpecification = 'false' tagType = 'element.uuid'>

<UML:TagDefinition.multiplicity>

<UML:Multiplicity xmi.id = 'a66'>

<UML:Multiplicity.range>

<UML:MultiplicityRange xmi.id = 'a67' lower = '1' upper = '1'/>

…

<UML:Class xmi.id = 'a5' name = 'Towed Array' isSpecification = 'false'

isRoot = 'false' isLeaf = 'false' isAbstract = 'false' isActive = 'false'>

<UML:GeneralizableElement.generalization>

<UML:Generalization xmi.idref = 'a4'/>

</UML:GeneralizableElement.generalization>

</UML:Class>

</UML:Model>

</XMI.content>

</XMI>


Finally, the screen shot of ArgoUML CASE tool in Figure 20 shows the VBE conceptual model in UML diagrams. ArgoUML supports ontology development activities by the help of a DUET plug-in, which is a tool for mapping DAML ontologies into UML models.

Figure 20. ArgoUML CASE Tool Screen Shot


PART-4 VBE CA-1 Federation Design In a distributed interactive simulation system, the analysis and design of simulation entities (federates) is not the only issue. The design of the virtual environment (federation), which is being constructed by these federates, should be considered seriously. Today, it is recognized that designing a distributed software system starts at the architectural level; in High Level Architecture (HLA) domain, this is called federation design. The purpose at this stage is to define a set of software components, the way they interact, and the way they are mapped to an execution platform (OS, middleware, etc.). Decisions taken at the architectural level have an important and long lasting impact on the system. Federation design tries to cover various views of the simulation system. Views are namely: data view (flow of data), functional view (hierarchy and static relations), and behavioral view (states, transitions, and interactions associated with simulation elements). These views are presented by using the Unified Modelling Language (UML) [38] and the UML extensions for HLA notation [28,29].

Architectural Design The following diagram graphically depicts the software components and their processes in a Virtual Battle Experiment (VBE). A federate is represented as an oval-like shape; the name of the federate being printed inside. Multiplicity information attached to each federate state the number of federates participating in the federation. Processes that are not in the federation, but are being used in its construction (i.e., RtiExec, FedExec), are presented by a component figure, printed with its name. Federates are also logically grouped together to show the runtime instance which they represent.

Runtime Infrastructure (RTI)

Motion

Logger

GameboardVSSDVMSEM

HorizonTMASonar

rtiexec

fedexec

Coalition ship

DB

Own ship

Computer GeneratedEntitiesExecution

ScriptFile

0..11

1 1 1

1

1..*

1

Figure 21. Architectural Overview of Federation


Typical object instantiation in VBE is depicted in Figure 22. The dotted line between helm, navigation, and motion objects indicates that these objects are not planned to be used in the current VBE, but they can be added easily in the future use.

OwnShip:Motion

:Helm TA:Sonar :TMA

GPS:Navigation

CoalitionShip:Motion

:Sonar :TMA

Data Sharing

Figure 22 Instantiation of own ship and coalition ship vessels

The minimum data to be shared between own ship and coalition ship to form the tactical picture is shown in Table 6.

Table 6. Shared Data Between Ship Instances

DATA STRUCTURE NAME ATTRIBUTES

Target Association Data Time (when?)

Association Generator Object Instance Name (who?)

Source Tracks (Parts?)

Relative Fused Track Data Track #

Description

Course

Speed

Time

Statistical Object Interests Of Federates

1. Sonar Federate Publish/Subscribe (P/S) Diagrams The sonar federate (SonarFd) mainly subscribes to composite entity and navigation report object classes. Figure 23 shows the subscribe/publish relationships for the sonar federate. Composite entity data is generated by the motion federate in order to inform the status of the instance created (e.g., position, course, speed of the instance). One of the uses of composite


entity data is to figure out the location of the sensor; derived from the location of the parent entity. However, in the current VBE, it is assumed that sensor position, sensor course, and sensor speed is the same as the parent ship’s. Navigation report data is only used if a navigation federate exists, otherwise it is ignored.

SonarFd

CompositeEntity

<<objectClass>>

NavigationReport

<<objectClass>>

KinematicReport

<<objectClass>>

S(*)

S(*)

SonarSystem<<objectClass>>

SensorSystem<<objectClass>>

ComponentEntity

<<objectClass>>

RelativeSonarTrack

<<objectClass>>

RelativeTrack<<objectClass>>

Track<<objectClass>>

Passive SonarTask

<<objectClass>>

AcousticTask<<objectClass>>

SignalTask<<objectClass>>

P(*)

P(*)

P(*)

Not Used

SeaSurfaceSubSurface

<<objectClass>>

Figure 23. Sonar Federate Object Class P/S Diagram

The sonar federate produces three types of data namely: sonar system (which is a component entity data), relative sonar track data, and passive sonar task data. The operation of a system in a particular mode is typically described as a task. For example, a radar may perform a search task, as opposed to a tracking task, which is a signal task. Task data is not used in the current VBE. The relative sonar track class keeps the track data generated by the sonar federate and it is used by the Horizon1 software to display tracks. Sonar system class is used to inform other federates (e.g., Data logger federate) about the sonar component properties. Composite entity class and component entity class attributes are presented in Figure 32 (near at the end of section 4). Figure 24 expresses the interaction interests of the sonar federate. The sonar federate subscribes to both execution management and track management interactions. Execution management messages are used to create composite entity instances (such as ship and submarine) and to set the seed for a random number generator within the sonar federate. Execution management messages are initiated by the Virtual Maritime System Execution Manager (VMSEM) federate.

1 http://www.iscience.com.au


http://www.iscience.com.au/

Not Used

SonarFd

ExecutionManagement

<<interactionClass>>

S(*)

S(*)

P(*)

P(*)

TrackManagement


SonarDetection<<interactionClass>>

SensorDetection<<interactionClass>>

ExecutionManagementError


ExecutionManagement

<<interactionClass>>CreateComponentEntitySetScenarioDescription

SetRandomNumberSeed<<InteractionClass>>

InteractionClassGroup

InitiateTrackConrrectTrackDeleteTrack

<<InteractionClass>>

Figure 24. Sonar Federate Interaction Class P/S Diagram

The sonar federate can be controlled by track management messages. Track management messages are used to manually initiate a track, to correct a track, and to delete a track. In VBE, track management interactions are not used. Instead, the sonar federate randomly generates track management messages (e.g., to lose a track). Sensor detection interactions are not used either in the current VBE. Execution management error messages are generated by the sonar federate when there is something wrong with execution management issues.


2. Data Logger Federate Publish/Subscribe (P/S) Diagrams The main objective of the data logger federate (LoggerFd) is to collect and to log data related to scientific research questions. This data will help in addressing the research questions, which is the objective of this distributed interactive simulation.

LoggerFdS(Name, Position, Velocity,orientation)

Composite Entity<<objectClass>>


<<objectClass>>

SonarSystem<<objectClass>>

SensorSystem<<objectClass>>

ComponentEntity

<<objectClass>>

RelativeSonarTrack

<<objectClass>>

RelativeTrack<<objectClass>>

Track<<objectClass>>

S(Track number, Description, Valid/lost, Time, Range,Elevation, Bearing, SNR, Frequency)

S(Name, Relative position, Relative orientation)

Figure 25. Data Logger Federate Class P/S Diagram

As seen in Figure 25, the data logger federate is a stealth federate, which only listens to the federation data traffic and logs the intended data. The data requirements and corresponding federation data structure for the present VBE are presented in [50]. The data logger federate mainly collects three groups of data: vessel information, track information, and data fusion information.


3. Motion Federate Publish/Subscribe (P/S) Diagrams The motion federate (MotionFd) creates composite entity instances (e.g., vessels) and keeps track each vessel kinematically. It is used to control the motion of composite entities.


<<objectClass>>

MotionFd

S(*)

S(*)

CompositeEntity<<objectClass>>

?<<objectClass>>

ComponentEntity<<objectClass>>

P(*)

P(*)

P(*)

ExecutionManagement


PropulsionSystemControl


CreateCompositeEntitySetScenarioDescription


SetPropulsionSystemAttrAckSetPropolSysAttr<<InteractionClass>>

SystemControl<<interactionClass>>

ExecutionManagementError


ExecutionManagement<<interactionClass>>

Figure 26. Motion Federate Class P/S Diagram

The motion of vessel instances can be controlled manually (e.g., by the help of helm federate) or automatically (e.g., by the help of gameboard software). The creation of vessel entities is explained in federation execution management section.


4. Federation Execution Management Federate (VMSEM) VMSEM controls the federation execution by the help of a script file, which is in XML format and is used to define which components and composite entities will participate in the federation. The only difference in VMSA federation execution lifecycle from a typical HLA federation lifecycle is the composite/component entity creation phase. Figure 27 depicts a typical VMSA federation execution lifecycle [52].

Federation Cration

Joining of Federates

Composite/Component Creation

Simulation Tick

Shut down

Figure 27. Typical VMSA Federation Lifecycle [55]

After the VMSEM federate has scanned the Execution Script File, it waits for federates to join the federation. When all federates are joined, federation initialization begins by creating instances of composite and component entities. Initialization of federation is depicted in Figure 28.


VMSEM TMA

Motion

VMSEM Script File (in XML):

Composite (ship1)…Component (TMA1)

createComposite(ship1)

createComponent (TMA1)

create instance of ship

create instance of TMA

getParent(TMA1)

Composite= a platformComponent= something on a composite entity

Figure 28. Creation of Composite and Component Entities

The VMSEM federate uses an “Execution Management” interaction class data structure to organize component/composite entity management. The Federate-Based Publication/Subscription Class Diagram is depicted in the Figure 29.

VMSEM

Execution Management<<InteractionClass>>

ExecutionManagementErrorTerminateIterative

TerminateFederation<<InteractionClass>>

CreateCompositeEntityCreateComponentEntitySetScenarioDescription


P(*)

S(*)

Federate Manager

S(*)

MOM

InteractionClassGroup

Figure 29. VMSEM P/S Diagram

After a federate receives a “create <composite/component> entity” interaction, it first checks that the interaction is meant for it, and then creates the instantiation of entity. The state chart diagram in Figure 30 explains the entity creation by a typical VMSA federate:


create entityreceive create entity interaction

{If (Federate Name=This Federate)}

T

F

Figure 30. Entity Instantiation Diagram

Data Flow The following diagram expresses general data flow in VBE focusing on the motion and sonar federates.

VMSEMFederate

MotionFederate

NavigationReport System

FederateSonar

Federate

Script File in XML

Execution Mngmt Messages

(CompositeEntity)Composite Entity

State Data(sea surface)

NavigationReport Data

Component SystemState Data

Sonar DetectionMessages (N/U)

RelativeSonarTrack

SignalTask

Data (N/U)

Component SystemState Data

(If motion federate models aspectsof the propulsion system)

Execution Mngmt Messages(ComponentEntity)

Execution ManagementError

GameBoard

System Control Messages(request to change course/speed)

Helm

OR

TrackManagementData (N/U)

Horizon

RelativeFusedTrack

RelativeFusedTrackN/U (Not used)

TrackAssociation

TrackAssociation

Figure 31. VBE General Data Flow Diagram

Signal task data, track management data, and sonar detection messages are not used in the current VBE. The main data structures, composite entity state and component entity state, are depicted in the Figure 32.


CompositeEntity<<objectClass>>

NameDescriptionAffiliationRolePositionVelocityAccelerationOrientationOrientation RateDR Algorithm

ComponentEntity<<objectClass>>

ComponentNameStatusRelative PositionRel. OrientationParent CompositeEntity Obj. InstanceName

Figure 32. Composite and Component Entity Class Diagram

Target Detection Via Passive Sonar Target detection via passive sonar in the current VMSA is depicted in the Figure 33.

OurSensor Emitter Target

Composite Entity Data

Component Entity Data

Signal Task Data

Compute the current position of target

Look up the emitting properties of the emitter

Compute the current orientation of beam pattern

Compute the signal emitted from emitter to receiver

Compute propogation of the signal emitted from emitter to receiver

Figure 33. Sequence Diagram of Target Detection via Passive Sonar


General Assumptions Architecture related assumptions are as follows:

• All interactions and data transfer are reliable,

• All federates are time regulating and time constrained.

Deployment Design From a user point of view, two or three hosts seem sufficient for the current VBE. One of the hosts should be configured as the simulation management node, which can host rtiexec, fedexec, VMSEM, data logger federate, gameboard executables. The other one (or two) can be configured as an operator console node, which will host horizon, sonar, and TMA federates. A fast Ethernet local area network (100 Mbps) will be used as communication media.


Appendix-B Ontology Review A selection of the well-known ontology languages (Table 7), some knowledge representation (KR) languages (Table 9), ontology tools (Table 10), and some basic ontologies (Table 11) are presented in the following tables:

Table 7. Ontology Languages

LANGUAGE EXPLANATION REFERENCE

RDF (Resource Description Framework) and RDF Schema - [43]

DAML (DARPA Agent Markup Language)

An extension to RDF. Variants: DAML+OIL (Ontology Inference Layer) (basic rep. language for ontologies, 2001) and DAML-L (Logic)(for rule representation) and DAML-S (web service ontology)

[42]

OWL (Web Ontology Language) Based on DAML+OIL supported by DAML group and W3C [41]

BWW (Bunge-Wand-Weber) BWW is an ontological model of information systems [25]

KIF (Knowledge Interchange Format) - http://logic.stanford.edu/kif/

kif.html

Others:

XOL (XML-based Ontology Exchange Language),

SHOE (Simple HTML Ontology Extension) (1996)

OCML (Operational Conceptual Modelling Language)

-

Table 8. Ontology Languages and UML Mapping

MAPPING EXPLANATION REFERENCE

UML Profile for OWL As known as UML Profile for KR, 2002 [53]

UML Profile for DAML+OIL Supported by DARPA [27]

BWW-UML - [25]

RDF-UML Mapping - [26]


http://logic.stanford.edu/kif/kif.html


Table 9. Knowledge Representation Languages

CATEGORY EXAMPLE(S) REFERENCE

Logical Languages KIF http://logic.stanford.edu/kif/kif.html

Frame-Based KL-ONE [54]

Graph-based Semantic Networks, Sowa’s Conceptual Graph Language

http://www.jfsowa.com/cg/index.htm (for the latter)

Table 10. Ontology Tools

TOOLS EXPLANATION REFERENCE

DAML Tools - http://www.daml.org

Stanford Ontology Environment

Protégé (RDF, XMI, JDBC Database, Text file, XML, OIL, CLIPS), 2000

Ontolingua (KIF), 1996

OKBC API (Open Knowledgebase Connectivity), an application programming interface for accessing knowledge bases stored in KR systems, 1998

Chimaera, 2000

Respectively;

http://smi.stanford.edu/projects/protege

http://www.ksl.stanford.edu/sns.shtml

http://www.ai.sri.com/~okbc

UBOT (UML-based Ontology Toolset)

AeroDAML, ConsVISor, DAML VisuaLinks (DAML)

http://ubot.lockheedmartin.com

By Lockheed-Martin inc.

Consistency Checkers and Verifiers for DAML -

http://vis.home.mindspring.com

By VIS inc.

CODIP Project (the Components for ontology driven information push)

An implementation of DAML:

DUET (DAML-UML Enhanced Tool) Rational Rose [37] and argoUML [38] Add-in based on UML profile for DAML

[32]

Medius Visual Ontology Modeller

Uses UML profile for frame-based KR/UML profile for OWL.

Rational Rose add-in (includes consistency-checking and has OKBC-based interface)

http://www.sandsoft.com

By Sandpiper Inc.



http://www.jfsowa.com/cg/index.htm

http://www.jfsowa.com/cg/index.htm






http://www.ai.sri.com/~okbc

http://ubot.lockheedmartin.com/

http://vis.home.mindspring.com/

http://www.sandsoft.com/

Table 11. Some Top Level (a.k.a. Core) Ontologies1

ONTOLOGY EXPLANATION REFERENCE

IEEE SUO (Standard Upper Ontology) - http://suo.ieee.org

GUM (Generalized Upper Model) General task and domain independent ontology

http://www.fb10.uni-bremen.de/anglistik/langpro/webspace/jb/gum/index.htm

Sowa Top Level KR Ontology http://users.bestweb.net/~sowa/ontology/

WordNet A lexical database for the English language by Princeton University

http://www.cogsci.princeton.edu/~wn/

1 Top level ontologies include high level concepts (e.g., time, structure, thing) and they are useful for ontology re-use


http://suo.ieee.org/




http://users.bestweb.net/~sowa/ontology/

http://users.bestweb.net/~sowa/ontology/



List of symbols/abbreviations/acronyms/initialisms

BWW Bunge-Wand-Weber CASE Computer Assisted Software Engineering CM Conceptual Model CMMS Conceptual Model of Mission Space DARPA US Defense Advanced Research Projects Agency DAML DARPA Agent Mark-up Language DAML-L DAML Logic for Rule Representation DAML-Ont DAML Ontology Library DAML-S Web Service Ontology DB Database DD Detailed Design DND Canada Department of National Defence DoD US Department of Defense DUET DAML-UML Enhanced Tool ESGM Elementary SGM FCM Federation Conceptual Model FDM Federation Design Model FDMS Functional Description of Mission Space FED Federation Execution Data FEDEP Federation Execution and Development Process FEPW Federation Execution Planner’s Workbook FOM Federation Object Model HLA High Level Architecture HTML Hypertext Mark-up Language KIF Knowledge Interchange Format KR Knowledge Representation M&S Modelling and Simulation OCL Object Constrained Language OCML Operational Conceptual Modelling Language OIL Ontology Inference Layer OKBC Open Knowledgebase Connectivity OMT Object Modelling Technique OO Object Oriented OOA Object Oriented Analysis OOAD Object Oriented Analysis and Design OOD Object Oriented Design OOSE Object Oriented Software Engineering OWL Web Ontology Language POC Point of Contact R&D Research and Development RDF Resource Description Framework RID RTI Initialization Data RTI Run-Time Infrastructure


SGM Simulation Graph Model SHOE Simple HTML Ontology Extension SME Subject Matter Expert SOM Simulation Object Model TMA Target Motion Analysis UML Unified Modelling Language URI Uniform Resource Identifier VBE CA Canadian Virtual Battle Experiment V&V Verification and Validation VV&A Verification, Validation, and Accreditation XCM Extreme Conceptual Modelling XMI XML Metadata Interchange language XML Extensible Mark-up Language XOL XML-based Ontology Exchange Language


Distribution list DRDC ATLANTIC DOCUMENT DISTRIBUTION LIST Document No.: DRDC Atlantic TM 2003-142 LIST PART 1: CONTROLLED BY DRDC ATLANTIC LIBRARY3 DRDC ATLANTIC LIBRARY FILE COPIES 3 DRDC ATLANTIC LIBRARY (SPARES) 1 J.S. Kennedy 1 M.G. Hazen 1 G.R. Mellema 9 TOTAL LIST PART 1 LIST PART 2: DISTRIBUTED BY DRDKIM 3 2 DRDKIM 2 Okan Topçu, Genelkurmay MEBS Bsk.ligi Bil.Sis.D. Isl. Ynt. S. Bakanliklar, 06000 Ankara, Turkey 1 B. Cinar (Turkish Military Attaché, 197 Wurtemburg Street, Ottawa, ON K1N 8L9) 1 CF Synthetic Env. Coordination Office, CFEC, Shirley’s Bay Campus, Ottawa, ON 1 M-SECO, CFMWC, FMO Halifax, NS 7 TOTAL LIST PART 2 16 TOTAL COPIES REQUIRED

Original document held by DRDC Atlantic Drafting Office. Any requests by DRDC Atlantic staff for extra copies of this document should be directed to the DRDC ATLANTIC LIBRARY.


DRDC Atlantic mod. May 02

DOCUMENT CONTROL DATA(Security classification of title, body of abstract and indexing annotation must be entered when the overall document is classified)

1. ORIGINATOR (the name and address of the organization preparing the document.Organizations for whom the document was prepared, e.g. Centre sponsoring acontractor's report, or tasking agency, are entered in section 8.)

DRDC Atlantic

2. SECURITY CLASSIFICATION !!(overall security classification of the document including special warning terms if applicable).

UNCLASSIFIED

3. TITLE (the complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S,C,R or U) in parentheses after the title).

Development, Representation, and Validation of Conceptual Models in Distributed Simulation

4. AUTHORS (Last name, first name, middle initial. If military, show rank, e.g. Doe, Maj. John E.)

Lt. (TUN) Okan TOPCU

5. DATE OF PUBLICATION (month and year of publication ofdocument)

February 2004

6a. NO. OF PAGES (totalcontaining information IncludeAnnexes, Appendices, etc). 93

6b. NO. OF REFS (total citedin document)

55

7. DESCRIPTIVE NOTES (the category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter thetype of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered).

Technical Memorandum 8. SPONSORING ACTIVITY (the name of the department project office or laboratory sponsoring the research and development. Include address).

VCS Group, Defence R&D Canada – AtlanticPO Box 1012Dartmouth, NS, Canada B2Y 3Z7

9a. PROJECT OR GRANT NO. (if appropriate, the applicable researchand development project or grant number under which the documentwas written. Please specify whether project or grant).

NATO Fellowship Programme - 11BK01

9b. CONTRACT NO. (if appropriate, the applicable number underwhich the document was written).

10a ORIGINATOR'S DOCUMENT NUMBER (the official documentnumber by which the document is identified by the originatingactivity. This number must be unique to this document.)

DRDC Atlantic TM 2003-142

10b OTHER DOCUMENT NOs. (Any other numbers which may beassigned this document either by the originator or by thesponsor.)

11. DOCUMENT AVAILABILITY (any limitations on further dissemination of the document, other than those imposedby security classification)( X) Unlimited distribution( ) Defence departments and defence contractors; further distribution only as approved( ) Defence departments and Canadian defence contractors; further distribution only as approved( ) Government departments and agencies; further distribution only as approved( ) Defence departments; further distribution only as approved( ) Other (please specify):

12. DOCUMENT ANNOUNCEMENT (any limitation to the bibliographic announcement of this document. This will normally correspond to theDocument Availability (11). However, where further distribution (beyond the audience specified in (11) is possible, a wider announcementaudience may be selected).

DRDC Atlantic mod. May 02

13. ABSTRACT (a brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. Itis highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with anindication of the security classification of the information in the paragraph (unless the document itself is unclassified) representedas (S), (C), (R), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual).

This study proposes a new approach to conceptual model representation andvalidation. Conceptual models are widely used in Modelling and Simulation(M&S) and are becoming one of the main building blocks of the distributedsimulation development.

It is also vital to state the development environment in which the conceptualmodel representation and validation techniques will be applied. Therefore,this study first proposes a vision for a distributed simulation environment,then prepares the technical ground for the conceptual model representationand validation techniques, and finally presents a conceptual modelrepresentation and validation technique.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (technically meaningful terms or short phrases that characterize adocument and could be helpful in cataloguing the document. They should be selected so that no security classification isrequired. Identifiers, such as equipment model designation, trade name, military project code name, geographic location mayalso be included. If possible keywords should be selected from a published thesaurus. e.g. Thesaurus of Engineering andScientific Terms (TEST) and that thesaurus-identified. If it not possible to select indexing terms which are Unclassified, theclassification of each should be indicated as with the title).

Distributed Simulation, Validation, Conceptual Model, High Level Architecture

development, representation and validation of conceptual...

Documents