NORTH ATLANTIC TREATY RESEARCH AND TECHNOLOGY

ORGANISATION ORGANISATION

AC/323(MSG-058)TP/404 www.rto.nato.int

RTO TECHNICAL REPORT TR-MSG-058

Conceptual Modeling (CM) for Military

Modeling and Simulation (M&S)
(Modélisation conceptuelle (MC) pour la
modélisation et la simulation
(M&S) militaires)

Final Report of MSG-058.

Published July 2012

Distribution and Availability on Back Cover

NORTH ATLANTIC TREATY RESEARCH AND TECHNOLOGY
ORGANISATION ORGANISATION

AC/323(MSG-058)TP/404 www.rto.nato.int

RTO TECHNICAL REPORT TR-MSG-058

Conceptual Modeling (CM) for Military

Modeling and Simulation (M&S)
(Modélisation conceptuelle (MC) pour la
modélisation et la simulation
(M&S) militaires)

Final Report of MSG-058.

 The Research and Technology
Organisation (RTO) of NATO
RTO is the single focus in NATO for Defence Research and Technology activities. Its mission is to conduct and promote
co-operative research and information exchange. The objective is to support the development and effective use of
national defence research and technology and to meet the military needs of the Alliance, to maintain a technological
lead, and to provide advice to NATO and national decision makers. The RTO performs its mission with the support of an
extensive network of national experts. It also ensures effective co-ordination with other NATO bodies involved in R&T
activities.
RTO reports both to the Military Committee of NATO and to the Conference of National Armament Directors.
It comprises a Research and Technology Board (RTB) as the highest level of national representation and the Research
and Technology Agency (RTA), a dedicated staff with its headquarters in Neuilly, near Paris, France. In order to
facilitate contacts with the military users and other NATO activities, a small part of the RTA staff is located in NATO
Headquarters in Brussels. The Brussels staff also co-ordinates RTO’s co-operation with nations in Middle and Eastern
Europe, to which RTO attaches particular importance especially as working together in the field of research is one of the
more promising areas of co-operation.
The total spectrum of R&T activities is covered by the following 7 bodies:
• AVT Applied Vehicle Technology Panel
• HFM Human Factors and Medicine Panel
• IST Information Systems Technology Panel
• NMSG NATO Modelling and Simulation Group
• SAS System Analysis and Studies Panel
• SCI Systems Concepts and Integration Panel
• SET Sensors and Electronics Technology Panel
These bodies are made up of national representatives as well as generally recognised ‘world class’ scientists. They also
provide a communication link to military users and other NATO bodies. RTO’s scientific and technological work is
carried out by Technical Teams, created for specific activities and with a specific duration. Such Technical Teams can
organise workshops, symposia, field trials, lecture series and training courses. An important function of these Technical
Teams is to ensure the continuity of the expert networks.
RTO builds upon earlier co-operation in defence research and technology as set-up under the Advisory Group for
Aerospace Research and Development (AGARD) and the Defence Research Group (DRG). AGARD and the DRG share
common roots in that they were both established at the initiative of Dr Theodore von Kármán, a leading aerospace
scientist, who early on recognised the importance of scientific support for the Allied Armed Forces. RTO is capitalising
on these common roots in order to provide the Alliance and the NATO nations with a strong scientific and technological
basis that will guarantee a solid base for the future.

The content of this publication has been reproduced

directly from material supplied by RTO or the authors.

Published July 2012

Copyright © RTO/NATO 2012

All Rights Reserved

ISBN 978-92-837-0150-7

Single copies of this publication or of a part of it may be made for individual use only. The approval of the RTA
Information Management Systems Branch is required for more than one copy to be made or an extract included in
another publication. Requests to do so should be sent to the address on the back cover.

ii RTO-TR-MSG-058
 Table of Contents

Page

List of Figures viii

List of Tables x
List of Acronyms xiii
MSG-058 Participating Members xvi
MSG-058 Task Group Members xviii

Executive Summary and Synthèse ES-1

Overview O-1
O.1 Purpose O-1
O.2 Scope and Limitations O-1
O.3 Special Issues (Procedures) O-1
O.4 Significant Considerations, Analysis/Results O-2
O.5 Decisions and Recommendations, Military/NATO Significance of the Study O-2

Chapter 1 – Background of MSG-058 Effort 1-1

Chapter 2 – Objective of MSG-058 Effort 2-1

Chapter 3 – MSG-058 Program of Work 3-1

3.1 Introduction 3-1
3.2 General Discussion of Effort Elements 3-1
3.2.1 National Conceptual Modeling Practice Expository Briefings 3-5
3.2.2 Issue Identification and Analysis 3-5
3.2.3 Stakeholders and Study Scope and Objective 3-6
3.2.4 Terminology and Concepts 3-7
3.2.5 Analytical Framework and Ontological Perspective 3-8
3.2.6 Standards Review and Evaluation 3-9
3.2.7 Process, Product and their Relationships 3-9
3.2.8 Process Specification Expression 3-10
3.2.9 Conceptual Model Process Elements 3-11
3.2.10 Conceptual Model Documentation 3-11
3.2.11 Task Group Work-Product Generation 3-12
3.2.12 Coordination with SISO for Generation of Subsequent SISO/IEEE International 3-13
Best-Practice Standard
3.3 Conclusion 3-14

RTO-TR-MSG-058 iii
Chapter 4 – Introduction to Conceptual Modeling: Best-Practice Guidance 4-1
4.1 Conceptual Modeling Operational Scope 4-1
4.2 Enterprise Context 4-3
4.2.1 Evolution of Operational Context 4-4
4.2.2 Enterprise Definition 4-4
4.2.3 Implications of Enterprise Context for Conceptual Modeling Practice 4-5
4.2.4 Consequences of Conceptual Modeling for Enterprise Mission 4-6
4.3 Conceptual Modeling Enterprise Stakeholders 4-7
4.3.1 The Importance of Identifying Stakeholders 4-7
4.3.2 Main Categories of Stakeholders 4-7
4.3.3 Use Case Description of a Conceptual Model Development Process 4-7
4.3.4 Stakeholders Responsibilities 4-8
4.4 Conceptual Model Attributes and Definitions 4-10
4.4.1 Scoping Definitions 4-10
4.4.2 Conceptual Model Characteristics 4-11
4.4.3 Conceptual Model 4-13
4.5 Conceptual Model Perspectives and Composition 4-14
4.6 Best-Practice Specification Notation 4-15
4.7 Conceptual Model Quality (Verification and Validation) 4-17
4.7.1 Context of Conceptual Model V&V Effort 4-18
4.7.2 Quality Attributes Relevant to Conceptual Model V&V 4-18
4.7.3 Sufficiency Criteria for Conceptual Model V&V 4-18
4.7.4 V&V Compliance Framework 4-19
4.8 References 4-20

Chapter 5 – Conceptual Modeling Process Guidance 5-1

5.1 Process Guidance Introduction 5-1
5.2 Conceptual Model Process Description 5-4
5.2.1 Process Phase 1 Guidance – Initiate Conceptual Model Development 5-5
5.2.1.1 PA1.1 – Identify and Map Stakeholder Responsibilities 5-7
5.2.1.2 PA1.2 – Define Purpose and Intended Use of M&S Effort 5-7
5.2.1.3 PA1.3 – Identify Constraints on the M&S Effort 5-8
5.2.1.4 PA1.4 – Impose Mandatory Enterprise Policies 5-8
5.2.2 Process Phase 2 Guidance – Define Conceptual Model Requirements and Knowledge 5-8
Needs
5.2.2.1 PA2.1 – Identify, Analyze and Record Conceptual Model, Mission and 5-9
Simulation Space Requirements
5.2.2.2 PA2.2 – Verify Requirements with Respect to Needs, Constraints and 5-10
Policies
5.2.2.3 PA2.3 – Synergize Conceptual Model, Mission and Simulation Space 5-11
Requirements
5.2.2.4 PA2.4 – Derive Mission and Simulation Space Knowledge Needs 5-11
5.2.3 Process Phase 3 Guidance – Acquire Conceptual Model Knowledge 5-12
5.2.3.1 PA3.1 – Identify Authoritative Knowledge Sources 5-13
5.2.3.2 PA3.2 – Search for the Reusable Knowledge in the Conceptual Model 5-14
Repository

iv RTO-TR-MSG-058
 5.2.3.3 PA3.3 – Identify Knowledge Gaps and Bounds 5-14
5.2.3.4 PA3.4 – Gather, Structure and Document Knowledge 5-14
5.2.3.5 PA3.5 – Generate/Extend a Domain Ontology 5-14
5.2.3.6 PA3.6 – Review Validity of Knowledge with Respect to the Authoritative 5-14
Knowledge Sources
5.2.4 Process Phase 4 Guidance – Design Conceptual Model 5-15
5.2.4.1 PA4.1 – Search for Existing Conceptual Models that May be Partially or 5-18
Fully Re-Used to Support the Current Conceptual Modeling Development
5.2.4.2 PA4.2 – Identify and Select Conceptual Primitives and Model Kinds to 5-18
Represent Acquired Knowledge
5.2.4.3 PA4.3 – Select Formalism(s) for Conceptual Model Specification 5-19
5.2.4.4 PA4.4 – Select Views to Support Stakeholders 5-19
5.2.4.5 PA4.5 – Select a Notation Suitable to Express the Chosen Formalism 5-20
5.2.4.6 PA4.6 – Evaluate Design for Adequacy/Relevance with Respect to 5-20
Requirements
5.2.5 Process Phase 5 Guidance – Build Conceptual Model 5-21
5.2.5.1 PA5.1 – Populate the Conceptual Model Using the Chosen Primitives, 5-23
Model Kinds, Formalism, and Notation
5.2.5.2 PA5.2 – Create the Specified Views 5-24
5.2.5.3 PA5.3 – Verify Conceptual Model Consistency with Respect to 5-24
Conceptual Model Design
5.2.5.4 PA5.4 – Validate Conceptual Model with Respect to Mission Space and 5-24
Simulation Space Knowledge
5.2.5.5 PA5.5 – Ensure Acceptance of Conceptual Model by Authorized Stakeholder 5-25
5.3 Conceptual Modeling Process Conclusion 5-25

Chapter 6 – Conceptual Model Product Guidance 6-1

6.1 Product Guidance Introduction 6-1
6.2 Conceptual Model Product Description 6-3
6.2.1 Product 1.1 Guidance – Stakeholder Description 6-3
6.2.2 Product 1.2 Guidance – Need Statement 6-5
6.2.3 Product 1.3 Guidance – Constraints and Policies 6-6
6.2.4 Product 1.4 Guidance – Conceptual Model Meta Data 6-7
6.2.5 Product 2.1 Guidance – Conceptual Model Requirements 6-11
6.2.6 Product 2.2 Guidance – Conceptual Model Knowledge Acquisition Needs 6-12
6.2.7 Product 3.1 Guidance – Validated Knowledge 6-13
6.2.7.1 Overall 6-13
6.2.7.2 The Generation Process 6-13
6.2.7.3 The Validation Process 6-14
6.2.7.4 Significant Inputs, Tools, Methods and Roles 6-15
6.2.8 Product 4.1 Guidance – Conceptual Model Design 6-15
6.2.9 Product 5.1 Guidance – Conceptual Model 6-16

Chapter 7 – Conclusions and Recommendations 7-1

7.1 Observations and Inferences 7-1
7.2 Recommendations 7-1

RTO-TR-MSG-058 v
Annex A – TAP A-1

Annex B – Terms of Reference B-1

Annex C – TAP/TOR Requirements C-1

Annex D – Issues D-1

Annex E – Explanation of Fundamental Concepts for Conceptual Model Frame-of- E-1

Reference
E.1 Overview E-1
E.2 Analysis E-2
E.2.1 Method: BOM E-2
E.2.2 Method: BOM++ E-3
E.2.3 Method: BPMN E-3
E.2.4 Method: CML (OneSAF) E-6
E.2.5 Method: CommonKADS E-6
E.2.6 Method: DCMF (KM3) E-7
E.2.7 Method: DCMF (M2CM) E-8
E.2.8 Method: DRDC E-10
E.2.9 Method: Entity Relationship E-11
E.2.10 Method: KAMA E-12
E.2.11 Method: Mind Maps E-12
E.2.12 Method: Topic Maps E-13
E.2.13 Method: Operational Conceptual Modeling Language (OCML) E-14
E.2.14 Method: Object Process Methodology (OPM) E-15
E.2.15 Method: Object-Role Modeling (ORM) E-16
E.2.16 Method: UML E-17
E.3 References E-19

Annex F – Standards F-1

F.1 Introduction F-1
F.2 Relevant Standards Characterization F-4

Annex G – Conceptual Modeling Process Activity Description G-1

Annex H – Conceptual Model Product Description H-1

Annex I – Conceptual Model Examples I-1

I.1 Defining Conceptual Model Requirements and Deriving Knowledge Needs I-1
I.1.1 Process Activity 2.1 − Identify, Analyze and Record Conceptual Model, Mission and I-1
Simulation Space Requirements
I.1.2 Process Activity 2.4 − Derive Mission Space and Simulation Space Knowledge Needs I-2

vi RTO-TR-MSG-058
I.2 From Knowledge Acquisition to Knowledge Use in a Conceptual Model I-3
I.2.1 Process Activity 3.4 − Gather, Structure and Document Knowledge I-3
I.2.2 Process Activity 3.5 − Generate/Extend a Domain Ontology I-5
I.2.3 Process Phase 4 − Design Conceptual Model I-8
I.2.4 Process Phase 5 − Build Conceptual Model I-10
I.3 Relation Between Knowledge Representation and a Conceptual Model I-13
I.3.1 Process Activity 3.4 − Gather, Structure and Document Knowledge I-14
I.3.2 Process Phase 4 − Design Conceptual Model I-15
I.3.3 Process Phase 5 − Build Conceptual Model I-16
I.4 Community-Specific Conceptual Model Design and Artefacts I-17
I.4.1 Process Phase 4 − Design Conceptual Model I-17
I.4.2 Process Phase 5 − Build Conceptual Model I-18
I.5 Iterative Evolution of Conceptual Model Requirements, Design and Artefacts I-21
I.6 Conclusion I-27
I.7 References I-27

Annex J – Lexicon/Glossary J-1

Annex K – Bibliography K-1

RTO-TR-MSG-058 vii
 List of Figures

Figure Page

Figure 3-1 Calendar Relationship of Meeting Activities Across Which Effort was Distributed 3-2
Figure 3-2 Logical and Activity Flow Relationships Among Principal Efforts Comprising the 3-3
MSG-058 Effort
Figure 3-3 Mind-Map Style Illustration of the Scope-of-Effort and Domain-of-Interest of the 3-4
MSG-058 Task Group
Figure 3-4 Relationships Among Agents, Processes, and Products Associated with Subject 3-10
MSG-058 Effort and its Consequential Conceptual Modeling Practice

Figure 4-1 Conceptual Model Depicted as Intermediate Artefact Between Real-World or 4-2
Mission Space Knowledge and Simulation Artefact and as Element in Progressive
Simulation Life-Cycle Development Process
Figure 4-2 The Scope of Best-Practice Guidance in the Conceptual Model Life Cycle 4-3
Figure 4-3 High Level Use Case Diagram Illustrating the Main Actors and Interactions During 4-8
a Conceptual Model Development Process
Figure 4-4 Conceptual Model Characteristics 4-12
Figure 4-5 Conceptual Model Composition 4-13
Figure 4-6 Mission Space and Simulation Implementation Spaces Indicated as Disjoint, but 4-14
Highly Integrated ‘Worlds’ Whose Natures are to be Included in the Entire M&S
Conceptual Model
Figure 4-7 Simple Indication of Composition of the Simulation Conceptual Model from 4-15
Mission Space and Simulation Implementation Space Components
Figure 4-8 Simplified Process Graphical Notation Used in Expressing Conceptual Modeling 4-16
Best-Practice Process
Figure 4-9 Notional Illustration of Relationship of Simplified Process Specification Graphical 4-17
Notation in Context of Other Canonical and More Powerful Notations
Figure 4-10 The V&V Argumentation Framework (AF) Consists of the Goal Network, 4-19
Evidence and the Claim Network

Figure 5-1 Conceptual Model Development Phases 5-2

Figure 5-2 Conceptual Model Development Process Exhibiting Devolution of Process Phases 5-3
to Process Activities
Figure 5-3 Example Conceptual Model Development Workflow 5-4
Figure 5-4 Process Phase 1 (PP1) Activity Diagram 5-6
Figure 5-5 Process Phase 2: Define Conceptual Model Requirements and Knowledge Needs 5-9
Figure 5-6 Process Phase 3 Activity Diagram: Acquire Conceptual Model Knowledge 5-13
Figure 5-7 Conceptual Model Components 5-16
Figure 5-8 Process Phase 4 (PP4) Activity Diagram 5-17
Figure 5-9 PP5 Activity Diagram: Build Conceptual Model Indicating Process Activities, 5-22
Process Flow, and Artefact Generation

viii RTO-TR-MSG-058
Figure 6-1 Conceptual Model Process and Product Relationships 6-2
Figure 6-2 Components of a Role Specification and Relationships to Role Functions 6-4
Figure 6-3 Suggested Role Specification and Stakeholder Role Assignment Information 6-4
Taxonomy
Figure 6-4 Conceptual Model Meta Data Must Always be Attached to the Conceptual Model 6-7
Figure 6-5 Conceptual Model Meta Data 6-8

Figure D-1 Outline of Scope and Influence Among Topic Issues Identified by the Task Group D-2
in Anticipation of Initiation of Detailed Programme of Work
Figure D-2 Schematic of Specification of Topical Issue, Resolution Action and Influence D-3

Figure I-1 Sample Scenario Knowledge (Patrol Mission Object) in the Protégé Ontology Editor I-8
Figure I-2 Sample View of the Conceptual Model of the Scenario Allowing to Visualize the I-11
Simplest Human Understandable High-Level Description of the Scenario
Figure I-3 Sample View of the Conceptual Model of the Scenario Allowing Visualizing the I-12
Collaboration Between Organizations
Figure I-4 Sample View of the Conceptual Model of the Scenario Allowing to Compare I-13
Procedures
Figure I-5 Sample Mission-Space Knowledge Documentation I-14
Figure I-6 Sample Simulation-Space Knowledge Documentation I-15
Figure I-7 Sample View from the Conceptual Model of a Simulation I-16
Figure I-8 The CML Formalism, Notation and Conceptual Primitives I-17
Figure I-9 Sample View from the OneSAF Conceptual Model Representing Entity I-19
Composition
Figure I-10 Sample View from the OneSAF Conceptual Model Representing Unit Movement I-20
Control
Figure I-11 Sample View from the OneSAF Conceptual Model Representing Tactical Fire I-21
Direction Center
Figure I-12 Sample View of the KARMA Conceptual Model Representing the Engagement I-22
Mission Space
Figure I-13 Sample View of the KARMA Conceptual Model Representing the Engagement I-23
Key Concepts
Figure I-14 Sample View of the KARMA Conceptual Model Representing an Engagement I-24
Sequence
Figure I-15 Sample View of the KARMA Conceptual Model Representing an Engagement I-24
States
Figure I-16 Sample View of the KARMA Conceptual Model Representing an Engagement I-26
in the Object-Oriented Formalism
Figure I-17 Sample View of the KARMA Conceptual Model Including Simulation Space I-26
Concepts and Implementation-Related Conceptual Primitives

RTO-TR-MSG-058 ix
 List of Tables

Table Page

Table 4-1 Stakeholders’ Concerns 4-9

Table 4-2 Relationships Between Defined Terms 4-11

Table 6-1 Array of Maturity Stages versus Conceptual Model Suite Component Product 6-6
Addressed in Detail in the Subject Best-Practice Explication
Table 6-2 V&V Data Elements in the Conceptual Model Meta Data 6-9

Table D-1 Total List of Candidate Topic Issues, With Team Vote Compilation of Significance D-4
of Each

Table F-1 Standards with Applicability in NATO Modeling and Simulation Domain F-1
Table F-2 Based Object Model (BOM) F-5
Table F-3 Conceptual Modeling Language (CML) F-7
Table F-4 Capability Maturity Model Integration (CMMI) F-8
Table F-5 Defence Conceptual Modeling Framework (DCMF) F-10
Table F-6 Discrete Event Systems (DEVS) F-11
Table F-7 Department of Defense Architecture Framework (DoDAF) F-12
Table F-8 Generic Methodology for Verification and Validation (GM-V&V) F-14
Table F-9 Integration Definition for Function Modeling (IDEFØ) F-16
Table F-10 Integration Definition for Function Modeling (IDEF5) F-17
Table F-11 Joint Command Control Communication Information Exchange Data Model F-18
(JC3IDEM)
Table F-12 Kernel Meta Meta Model (KM3) F-21
Table F-13 Model Driven Architecture (MDA) F-22
Table F-14 NATO Architecture Framework (NAF) F-24
Table F-15 Open Knowledge Base Connectivity (OKBC) F-25
Table F-16 Web Ontology Language (OWL) F-27
Table F-17 Resource Description Framework (RDF) F-28
Table F-18 Rational Unified Process (RUP) F-29
Table F-19 Systems Modeling Language (SysML) F-30
Table F-20 Unified Modeling Language (UML) F-31

Table G-1 Generic Template for Specification of Process Activity G-1

Table G-2 Conceptual Model Process Activity 1.1 Description G-3
Table G-3 Conceptual Model Process Activity 1.2 Description G-4
Table G-4 Conceptual Model Process Activity 1.3 Description G-5
Table G-5 Conceptual Model Process Activity 1.4 Description G-7

x RTO-TR-MSG-058
Table G-6 Conceptual Model Process Activity 2.1 Description G-8
Table G-7 Conceptual Model Process Activity 2.2 Description G-10
Table G-8 Conceptual Model Process Activity 2.3 Description G-11
Table G-9 Conceptual Model Process Activity 2.4 Description G-12
Table G-10 Conceptual Model Process Activity 3.1 Description G-13
Table G-11 Conceptual Model Process Activity 3.2 Description G-15
Table G-12 Conceptual Model Process Activity 3.3 Description G-16
Table G-13 Conceptual Model Process Activity 3.4 Description G-18
Table G-14 Conceptual Model Process Activity 3.5 Description G-20
Table G-15 Conceptual Model Process Activity 3.6 Description G-22
Table G-16 Conceptual Model Process Activity 4.1 Description G-24
Table G-17 Conceptual Model Process Activity 4.2 Description G-25
Table G-18 Conceptual Model Process Activity 4.3 Description G-27
Table G-19 Conceptual Model Process Activity 4.4 Description G-29
Table G-20 Conceptual Model Process Activity 4.5 Description G-31
Table G-21 Conceptual Model Process Activity 4.6 Description G-32
Table G-22 Conceptual Model Process Activity 5.1 Description G-34
Table G-23 Conceptual Model Process Activity 5.2 Description G-40
Table G-24 Conceptual Model Process Activity 5.3 Description G-45
Table G-25 Conceptual Model Process Activity 5.4 Description G-48
Table G-26 Conceptual Model Process Activity 5.5 Description G-49

Table H-1 Generic Template for Specification of Product H-1

Table H-2 Conceptual Model Product 1.1 Description H-3
Table H-3 Conceptual Model Product 1.2 Description H-4
Table H-4 Conceptual Model Product 1.3 Description H-5
Table H-5 Conceptual Model Product 1.4 Description H-7
Table H-6 Conceptual Model Product 2.1 Description H-9
Table H-7 Conceptual Model Product 2.2 Description H-11
Table H-8 Conceptual Model Product 3.1 Description H-12
Table H-9 Conceptual Model Product 4.1 Description H-14
Table H-10 Conceptual Model Product 5.1 Description H-16

Table I-1 Examples of Conceptual Model Requirements Categorized in Terms of Conceptual I-2
Model Space, Mission Space and Simulation Space
Table I-2 Examples of Conceptual Model Knowledge Needs Derived from Some of the I-2
Sample Conceptual Model Requirements of Table I-1
Table I-3 Sample Scenario Description in Natural Language (Paragraph 1) I-3
Table I-4 Sample Implicit Knowledge Inferred from the Scenario Description I-4
Table I-5 Sample Explicit Knowledge Extracted from the Scenario Description Using the Five I-4
Ws Method

RTO-TR-MSG-058 xi
Table I-6 Sample Explicit Knowledge Extracted from the Scenario Description Using the KM3 I-5
Method
Table I-7 Sample Ontology Classes Instantiated to Document the Scenario I-6
Table I-8 Sample OWL Code for the Patrol Mission Instance of the Action-Required-Capability I-7
Class Capturing the Scenario Knowledge
Table I-9 Conceptual Model Design for the Scenario Description Example I-9
Table I-10 Sample Conceptual Model Design for IMAGE I-16
Table I-11 Conceptual Model Design for OneSAF I-18
Table I-12 Conceptual Model Design for KARMA Engagement Mission Space I-22
Table I-13 Conceptual Model Design for KARMA Engagement Key Concepts I-25

xii RTO-TR-MSG-058
 List of Acronyms

ACIMS Arizona Center for Integrative Modeling and Simulation

AF Argumentation Framework
AMRDEC Aviation and Missile Research, Development and Engineering Center
AV All View

BCI BOM Component Implementations

BOM Base Object Models
BPGS Best-Practice Guidance Specification
BPMN Business Process Modeling Notation

C2IEDM Command and Control Information Exchange Data Model

C-BML Coalition Battle Management Language
CBML Cell Behavior Markup Language
CIM Computation Independent Model
CM Conceptual Model, Conceptual Modeling
CML Conceptual Modeling Language
CMMI Capability Maturity Model Integration
CMMS Conceptual Model of the Mission Space
COI Critical Operational Issues
CONOPS Concept of Operation
COTS Commercial-Off-The-Shelf
CSDP Conceptual Schema Design Procedure
CWM Part of SWAP – Semantic Web Application Program

DAML DARPA Agent Markup Language

DCMF Defence Conceptual Model Framework
DEVS Discrete-Event Systems
DMWG Data Modeling Working Group
DoD Department of Defense
DoDAF DoD Architecture Framework
DSEEP Distributed Simulation Engineering and Execution Process

EA Enterprise Architecture
ER Entity Relationship
ERM Entity Relationship Modeling

FEDEP Federation Development and Execution Process

FEDEX Federation Execution
FFI Norwegian Defence Research Establishment
FOI Swedish Defence Research Agency
FORML Formal Object-Role Modeling Language

GM Generic Methodology
GM-V&V Generic Methodology for Verification, Validation

HLA High Level Architecture

HPKB High Performance Knowledge Base Program

IDEF Integration Definition for Function Modeling

IEC Infomentum Classification Engine

RTO-TR-MSG-058 xiii
IEEE Institute of Electrical and Electronics Engineers
INCOSE International Council on Systems Engineering
IR Information Retrieval
ISDEFE Ingenería de Sistemas para la DEFensa de España
ISO International Organization for Standardization
IST Information System Theoretic

JC3IEDM Joint Command Control Communications Information Exchange Data Model

KA Knowledge Acquisition
KE Knowledge Elicitation
KIF Knowledge Interchange Format
KM3 Kernel Meta Meta Model
KRS Knowledge Representation System

M&S Modeling and Simulation

MDA Model-Driven Architecture
MOF Meta Object Facility
MSCO Modeling and Simulation Coordination Office
MSG Modeling and Simulation Group
MSM Mission Space Model
MSMP Modeling and Simulation Master Plan

NAF NATO Architecture Framework

NATO North Atlantic Treaty Organisation
NDAG NATO Data Administration Group
NLIAM Natural Language Information Analysis Method
NIST National Institute of Standards and Technology
NMM NAF Meta-Model
NMSG NATO Modeling and Simulation Group

OCL Object Constraint Language

OIL Ontology Interface Layer
OKBC Open Knowledge Base Connectivity
OMG Object Management Group
ORM Object-Role Modeling
OV Operational View
OWL Web Ontology Language
OXL Ontology Exchange Language

PA Process Activity
PfP Partners for Peace
PIM Platform Independent Model
POC Point Of Contact
PP Process Phase
PSM Platform Specific Model

RDECOM Research, Development, and Engineering Command

RDF Resource Description Framework
RPR Real Platform Reference
RTG Research Technology Group
RTO Research and Technology Organisation
RUP Rational Unified Process

xiv RTO-TR-MSG-058
SCAMPI Standard CMMI Appraisal Method for Process Improvement
SEI Software Engineering Institute
SES Senior Executive Service
SISO Simulation Interoperability Standards Organization
SME Subject Matter Expert
SSDD System Simulation and Development Directorate
SV System View
SysML Systems Modeling Language

TAP Technical Advisory Panel

TG Task Group
TOR Terms of Reference
TS Technical Standards

UML Unified Modeling Language

V&V Verification and Validation

VEA Microsoft® Visio® for Enterprise Architects
VV&A Verification, Validation and Accreditation

W3C World Wide Web Consortium

XMI XML Metadata Interchange

XML Extensible Markup Language

RTO-TR-MSG-058 xv
 MSG-058 Participating Members

Jan-Jelle Boomgaardt is a senior scientist concerned with Modeling & Simulation at TNO Defence, Security
and Safety. He has some 9 years of experience in the field of applied research. The main focus of his research
has been on distributed simulation architectures, such as the High Level Architecture (HLA). The M&S field of
expertise is supported by his previous 7 years of experience in computer architectures and software engineering.

Mircea Cernat was born in Romania, in 1957. He finished the PhD studies in 1996 with the thesis entitled
“Study of the solid propellant burning chambers under dynamic loading”. He is the Deputy Director for
Science at Military Equipment and Technologies Agency, Bucharest (http://www.acttm.ro/en/index.html).
Since 1987 he worked in positions linked to education and research, being entitled professor at Military
Technical Academy in Bucharest since 2001. In 2006, he graduated the National Defence College and has been
involved in several projects linked to defence and security since then. Since 2009 he is also a senior researcher
succeeding to manage or to contribute as member in research Groups to several projects regarding weapon
systems technology and aerospace engineering. His research topics are focused on applied mathematics to
weapon systems and structural mechanics. Since 2005 he has been mandated to represent Romania as voting
member in NATO Modeling and Simulation Group (NMSG).

Nathalie Harrison is a defence scientist at Defence R&D Canada – Valcartier since 2000. She works in the
Electro-Optical Warfare Section where she develops and uses Modeling and Simulation (M&S) processes and
tools to study engagements between military platforms, guided weapons and countermeasures. She received a
Bachelor’s degree in Engineering Physics from Laval University (Quebec, Canada) in 1998. She also received
a Master’s degree in Electrical Engineering from the same university for her research on virtual reality
cryosurgery simulation and modeling of heat transfer in human tissues. Her research interests include: physics-
based modeling; verification and validation process and techniques; model exchange; software engineering
applied to M&S; Conceptual Modeling and Model-Driven Architecture applied to M&S; and simulation
frameworks and synthetic environments.

Vahid Mojtahed is a senior scientist and deputy research director at the Swedish Defence Research Agency
(FOI). He received a Master of Science in Computer Science and Engineering from Chalmers University of
Technology in 1994. He has been working on modeling and simulation for the past 15 years and has led
the Swedish conceptual modeling research at FOI since 2001 as well as the FOI research on Semantic
Interoperability since 2006. He is also the Swedish representative in NATO’s research group on conceptual
modeling as well as in NATO’s research group on Semantic Interoperability. His research interests are in the
area of Conceptual Modeling, Simulation Framework, Semantic Interoperability and Information Operations
and Warfare.

Arne C. Jenssen is a senior scientist with the Norwegian Defence Research Establishment (FFI). He has received
BEng, MSc and PhD degrees in electrical engineering. He has been working with test and evaluation in a naval
context for the last decade. These activities comprise substantial efforts in modeling and simulation for evaluation
of torpedo and missile defence capabilities.

Bernardo Martinez Reif is working for ISDEFE, a company that provides technical engineering support and
consulting services to the Spanish Ministry of Defence. He has been involved in several Command and Control
and Modeling and Simulation projects since 2003, specially focused in the Data Modeling and Interoperability
issues. He has participated also in the NATO Modeling and Simulation Group Technical Activity Program
MSG-042 “Framework for Simulation Resources Reusability (FSRR)” and in the Information System Technologies
IST-075 “Semantic Interoperability”. He received his Bachelor’s degree in Computer Science from the Polytechnic
University in Madrid, Spain.

Oscar Jimenez Pascual is Major of the Spanish Army, specialized in telecommunications, computer science
and operational research. He has been working in these fields and, nowadays, he works in the Operational

xvi RTO-TR-MSG-058
Research Department of the Spanish Army, which participates in M&S projects. He also has a degree in Computer
Science from the University of Valladolid, a Master of Operational Research from Complutense University
(Madrid), and an Executive MBA from Financial Studies Centre (Madrid).

Gregory Tackett is a member of the US Army Senior Executive Service (SES) and is the Director of the System
Simulation and Development Directorate (SSDD) in the Research, Development, and Engineering Command
(RDECOM) Aviation and Missile Research, Development, and Engineering Center (AMRDEC). Mr. Tackett
has worked for the Department of Defense since 1982 in the field of Modeling and Simulation (M&S) and is a
leader in academic and professional initiatives to establish M&S as a recognized profession with a defined
body of knowledge and standardized curricula. He has most recently been appointed as the RDECOM M&S
Executive Agent. He has a B.S. degree in Physics from Mississippi College, and an Executive MBA from the
University of Tennessee.

Jeroen Voogd is a member of the scientific staff at the Modeling & Simulation and Gaming Department of
TNO Defence, Security and Safety Division. He holds a Ph.D. in Computational Physics from the University of
Amsterdam in the field of modeling and simulating (M&S) of biophysical systems on parallel and distributed
computing platforms. A recurring theme in his work of the last years is the quality of simulations. This includes
verification and validation of M&S assets, as well as quality assurance within TNO.

William F. Waite is co-founder and Chairman of The AEgis Technologies Group, Inc., where he directs a staff
involved in a wide variety of modeling and simulation (M&S) activities including simulation technologies
evolution; simulation systems development; simulation verification, validation, and accreditation; simulation-
based studies and analyses; and the development of hardware and software products supporting modern M&S
practice. He has more than 30 years of professional involvement in all phases of the M&S life cycle and its
application to systems engineering lifecycle. Mr. Waite is currently active in the evolution of the M&S
profession, industry, and market. He is also engaged in the further discovery and invention of M&S business
practice, emphasizing M&S employment in business enterprise operations.

RTO-TR-MSG-058 xvii
 MSG-058 Task Group Members

CANADA SPAIN
Nathalie Harrison Bernardo Martinez Reif
Defence R&D Canada – Valcartier System Engineer, ISDEFE
2459, boul. Pie-XI Nord Beatriz de Bobadilla, 3
Val-Belair, Quebec G3J 1X5 28040 Madrid
Email: Nathalie.Harrison@drdc-rddc.gc.ca Email: bmreif@isdefe.es
Tel: +1 418-844-4000, ext. 4604 Tel: +34 91 411 50 11
Fax: +34 91 411 47 03
NETHERLANDS
Jan-Jelle Boomgaardt Oscar Jimenez Pascual
TNO Defence, Security and Safety Major, Spanish Army
Postbus 96864 Operations Research Unit of the Spanish Army
2509 JG The Hague Prim 6
Email: jan_jelle.boomgaardt@tno.nl 28004 Madrid
Tel: +31 7037 40266 Email: oscarjim@et.mde.es
Tel: +34 91 780 24 91
Jeroen Voogd Fax: +34 91 780 25 96
TNO Defence, Security and Safety
Oude Waalsdorperweb 63 SWEDEN
2509 JG The Hague Vahid Mojtahed
Email: jeroen.voogd@tno.nl Deputy Research Director
Tel: +31 7037 40280 Swedish Defence Research Agency
Division of Information Systems
NORWAY Competence Unit Informatics
Arne Jenssen Email: vahid.mojtahed@foi.se
Forsvarets forskningsinstitutt Tel: +46 8 5550 3705
Postboks 25 Fax: +46 8 5550 3700
2027 Kjeller GSM: +46 73 444 7705
Email: Arne-Cato.Jenssen@ffi.no
Tel: +47 6380 7434 UNITED STATES
William Waite (Chair)
ROMANIA The AEgis Technologies Group, Inc.
Mircea Cernat (Chair) 410 Jan Davis Drive
Deputy Director of Science Huntsville, AL 35806
Military Equipment and Technologies Research Email: BWaite@aegistg.com
Agency Tel: +1 256-922-0802
Aeroportului Street, No. 16
CP 19 OP Bragadiru Gregory Tackett
077025 Lifov Director, System Simulation Development
Email: mcernat@acttm.ro Directorate
Tel: +0040214233058 US Army Research, Development, and
Engineering Command (RDECOM)
Eugen Popescu Aviation and Missile Research, Development,
Romanian Defence Establishment and Engineering Center (AMRDEC)
Email: epopescu@acttm.ro Redstone Arsenal, AL 35898
Tel: +40-21-423.14.83 Email: Gregory.Tackett@us.army.mil
Tel: +1 256-876-4271

xviii RTO-TR-MSG-058
 Conceptual Modeling (CM) for Military
Modeling and Simulation (M&S)
(RTO-TR-MSG-058)

Executive Summary

Purpose
The aim of this document is to clarify the “Conceptual Model” (CM) concepts; investigate methodologies,
simulation and software engineering processes; draft a guidance document on CMs that can be used by
different stakeholders; foster the establishment of the guidance document as a SISO standard; identification
of the relevant stakeholders of CMs; address the needs of M&S community and provide guidance to
implementation; and, provide guidelines for standards in conceptual modeling for M&S.

Scope and Limitations

The scope of this guidance is nominally for NATO military M&S. However, the approach taken herein is to
provide comprehensive guidance that can easily be adapted and tailored to individual enterprises. It can be
generalized to apply to alternative domains. NATO and national defense establishment M&S communities-
of-practice are de facto enterprises in this spirit when the investment, development, maintenance, and use of
M&S assets are concerned. While the application of this guidance is intended to be broad, its scope is
targeted to the CM development process, and only provides limited best-practices pertaining to the rest of the
CM life cycle.

Special Issues (Procedures)

Five topics have been identified as critical. They required special work efforts to propose an appropriate
solution: Stakeholder Analysis and Context; Scope and Definition; Relationship to Standards; Specification
of CM Management Process; Specification of CM Artefacts.

Significant Considerations, Analysis/Results

As in Heisenberg Uncertainty, where a phenomenon is disturbed as soon as one tries to measure it, the
referent in a CM is distorted as soon as one tries to represent it. This is one reason so many simulation
frameworks have turned out to be unusable or un-reusable while they were modeled as point solutions
such as “red against blue”, instead of more composable structures, such as “entities and interactions”.
The conceptual modeling enterprise does not get rid of these biases, as much as it makes the choosing of
biases deliberate and well documented.

The CM of a simulation is not simulation space implementation independent. It may appear to be so,
without any specific references to the simulation space, but the decisions that were made during the CM
design inevitably were informed by the underlying need for a simulation capability or an enterprise
interest. The value of this guidance to enterprises is the provision of a broad and flexible process with
defined products which can be mapped against current approaches and future plans. Common terminology
can also be derived from this guidance to enable better communication of concepts between enterprises.

RTO-TR-MSG-058 ES - 1
Decisions and Recommendations, Military/NATO Significance of the Study
• NATO Nations should adopt this guidance as best-practice for their national and international M&S
efforts to enable interoperability and reuse.

• The M&S community should incorporate CM development into their M&S development processes,
based on the best-practice provided in this guidance.

• Each enterprise should specify its own conceptual modeling process and CM products, using this
guidance as a point of reference.

• VV&A of CMs should be integral to the development process. Use of the ISO/IEC 9126 standard
on software quality is a starting point for the derivation of CM quality criteria, and use of the (draft)
GM-V&V standard is applicable to V&V of CMs.

• Every customization of the guidance should be published to contribute to the body of knowledge of
conceptual modeling, to build a valuable experience base for standardization initiatives.

• The M&S community and the Simulation Interoperability Standards Organization, should use this
best-practice guidance as a basis to initiate an international standard for CM development.

ES - 2 RTO-TR-MSG-058
 Modélisation conceptuelle (MC) pour la modélisation
et la simulation (M&S) militaires
(RTO-TR-MSG-058)

Synthèse

Objectif
Le but du présent document est de : clarifier les notions de « modèle conceptuel » (MC) ; étudier les
méthodologies, les procédés de génie logiciel et de simulation ; rédiger une directive traitant des MC
pouvant être utilisée par différentes parties prenantes ; agir en sorte que la directive devienne une norme
SISO (Organisation de normalisation en vue de l’interopérabilité en matière de simulation) ; identifier les
bonnes parties prenantes aux MC ; répondre aux besoins du monde de la modélisation et de la simulation
et lui fournir des directives de mise en œuvre ; et fournir des lignes directrices en matière de normes dans
le domaine de la modélisation conceptuelle destinée à la M&S.

Portée et limitations
La présente directive porte, en principe, sur la M&S militaire de l’OTAN. Toutefois, le parti retenu ici est
de fournir une directive complète pouvant être facilement adaptée à différentes entreprises. Elle peut être
généralisée pour s’appliquer à d’autres domaines. Les collectivités qui assurent la mise en œuvre de la
M&S, qu’elles se situent au niveau OTAN ou des établissements nationaux de défense, sont de facto des
entreprises en ce sens lorsqu’il s’agit de financer, développer, entretenir et utiliser les ressources en
matière de M&S. Bien que le domaine d’application de la présente directive soit intentionnellement vaste,
sa portée est restreinte à la procédure de développement de modèle conceptuel et elle n’indique que de
façon limitée les meilleures pratiques se rapportant au reste du cycle de vie dudit modèle conceptuel.

Questions spéciales (Procédures)

Cinq domaines critiques ont été identifiés. Ils ont nécessité une réflexion spéciale débouchant sur une
solution adaptée : environnement et analyse de partie prenante ; portée et définition ; rapports avec les
normes ; spécification de procédure de gestion de la MC ; spécification d’artefact de MC.

Considérations importantes, analyse/résultats

De même que, selon le principe d’incertitude de Heisenberg, on perturbe un phénomène dès lors que l’on
essaie de le mesurer, le référent dans une MC est altéré dès que l’on essaie de le représenter. C’est l’une des
raisons pour lesquelles tant de cadres de simulation se sont révélés être inutilisables ou non réutilisables alors
qu’ils étaient modélisés en tant que solutions ponctuelles telles que « rouges contre bleus », en lieu et place
de structures plus accommodantes telles qu’« entités et interactions ». L’entreprise de modélisation
conceptuelle n’élimine pas tant ces biais qu’elle rend leur choix délibéré et bien documenté.

La MC d’une simulation n’est pas indépendante de la mise en œuvre de l’espace de simulation. Cela peut
paraître être le cas, sans aucune référence spécifique à l’espace de simulation, mais les décisions prises
lors de la conception de la MC ont été inévitablement influencées par le besoin sous-jacent d’une capacité
de simulation ou d’un intérêt d’entreprise. La valeur de la présente directive pour les entreprises consiste

RTO-TR-MSG-058 ES - 3
en la mise à disposition d’une procédure large et souple comprenant des produits définis qui peuvent être
organisés en fonction des méthodologies actuelles et des plans futurs. Une terminologie commune peut
également être tirée de la présente directive afin de favoriser l’échange de concepts entre entreprises.

Décisions et recommandations, importance militaire/pour l’OTAN de l’étude

• Les pays de l’OTAN doivent adopter la présente directive en tant que meilleure pratique applicable à
leurs efforts nationaux et internationaux en matière de modélisation et simulation (M&S), et ce, en vue
de permettre l’interopérabilité et la réutilisation.

• Le monde de la M&S doit intégrer le développement de la modélisation conceptuelle (MC) dans ses
processus de développement de M&S en se fondant sur les meilleures pratiques indiquées dans la
présente directive.

• Chaque entreprise doit indiquer ses propres procédures de modélisation conceptuelle et produits de
MC en utilisant la présente directive comme référence.

• Les VV&A (vérification, validation et acceptation) des MC doivent faire partie intégrante du processus
de développement. L’utilisation de la norme ISO/IEC 9126 sur la qualité des logiciels constitue le point
de départ d’où vont découler les critères de qualité de la MC, et (le projet de norme ou) la norme
GM-V&V (méthodologie générique de vérification et validation) est applicable aux V&V (vérification
et validation) des MC.

• Toute personnalisation de la directive doit être publiée afin de contribuer au corpus de connaissances
relatives à la modélisation conceptuelle, et ce, pour constituer un précieux socle d’expérience utile aux
initiatives en matière de normalisation.

• Le monde de la M&S ainsi que l’Organisation de normalisation en vue de l’interopérabilité en matière

de simulation (SISO) doivent utiliser la directive relative aux meilleures pratiques comme point de
départ d’une norme internationale en matière de développement de MC.

ES - 4 RTO-TR-MSG-058
 OVERVIEW

O.1 PURPOSE
This document is intended to have the following consequential effects:
• Clarify “Conceptual Model” (CM) concepts, discuss the terminology, and emphasize the utility to better
formalize conceptual models, understand the relationship between conceptual modeling and related
concepts (scenario definition, etc.);
• Investigate methodologies, simulation and software engineering processes, initiatives and technologies
useful for the establishment and content of conceptual models;
• Draft a guidance document on conceptual models that can be used by different stakeholders (sponsor/
user, project manager, subject-matter experts, V&V agents, developers, etc.);
• Foster the establishment of the guidance document as a SISO standard;
• Provide identification of the relevant stakeholders of conceptual models and considering whether a
prioritization is needed;
• Address the needs of M&S community, identifying the way conceptual models may contribute to M&S
development, and providing guidance to implementation; and
• Provide guidelines for standards in conceptual modeling for M&S; thereby specifying a conceptual
model to be (re)usable by users with similar knowledge and to be accepted by the computer science
community.

O.2 SCOPE AND LIMITATIONS

The scope of this guidance is nominally for NATO military M&S. However, the approach taken herein is to
provide comprehensive guidance that can easily be adapted and tailored to individual enterprises. It can be
generalized to apply to alternative domains. NATO and national defence establishment M&S communities-of-
practice are de facto enterprises in this spirit when the investment, development, maintenance, and use of M&S
assets are concerned. While the application of this guidance is intended to be broad, its scope is targeted to the
CM development process, and only provides limited best-practices pertaining to the rest of the CM life cycle.

O.3 SPECIAL ISSUES (PROCEDURES)

Five topics were identified as critical to the TR-MSG-058 Task Group’s efforts that required special attention
to achieve an appropriate outcome to the Groups work-product. Those issues included:
1) Sensitivity to stakeholder analysis and context;
2) Precise specification of study scope and definition of terms;
3) Explication of relationships of conceptual modeling practice and products to existing standards;
4) Specification of conceptual model management process; and
5) Specification of resulting conceptual model documentary artifacts.

RTO-TR-MSG-058 O-1
OVERVIEW

O.4 SIGNIFICANT CONSIDERATIONS, ANALYSIS/RESULTS

Two particular considerations assumed special prominence during the effort of the Group’s deliberations.
In each case the Group made every effort to appreciate the underlying nature and logical entailments of these
considerations and to produce analyses and work-product results that were reasonably commensurate both the
implications of these considerations and the need for practitioners to deal with those implications in straight-
forward pragmatic ways.

The first consideration is the fact of ‘ontological relativism’ whereby every abstraction of a referent domain
by way of conceptualization has inherent systematic biases that depend strongly on the perceptual frame of the
modeler and that may so particularize a consequent conceptual model that alternative models, while drawn
from the same reality, are not in fact ‘complementary’ or semantically consistent. Conceptual modeling
process and conceptual model product artifacts recommended by the Study Group were particularly conceived
and phrased so as to make this risk to re-use and interoperability of conceptual models and consequent
simulations apparent and to provide such guidance as could be made prescriptive whereby this risk might be
ameliorated.

The second consideration of import addressed by the Group was the question of whether simulation conceptual
models should be in some significant way simulation-implementation independent. By designating fully
simulation independent abstractions of the referent world as ‘conceptual system-reference-models’ rather than
conceptual simulation-models, the Group proceeded to include both the objective system-space and the
simulation-space in its scope. Consequently, the decisions that are recommended to be made during the
conceptual model design inevitably will be informed by the underlying need for a simulation capability or an
enterprise interest. The value of this guidance to enterprises is the provision of a broad and flexible process with
defined products which can be mapped against current approaches and future plans. Common terminology can
also be derived from this guidance to enable better communication of concepts between enterprises.

O.5 DECISIONS AND RECOMMENDATIONS, MILITARY/NATO

SIGNIFICANCE OF THE STUDY
• NATO Nations should adopt this guidance as best-practice for their national and international M&S
efforts to enable interoperability and reuse.

• The M&S community should incorporate CM development into their M&S development processes, based
on the best-practice provided in this guidance.

• Each enterprise should specify its own conceptual modeling process and CM products, using this guidance as
a point of reference.

• VV&A of CMs should be integral to the development process. Use of the ISO/IEC 9126 standard on
software quality is a starting point for the derivation of CM quality criteria, and use of the (draft) GM-V&V
standard is applicable to V&V of CMs.

• Every customization of the guidance should be published to contribute to the body of knowledge of
conceptual modeling, to build a valuable experience base for standardization initiatives.

• The M&S community and the Simulation Interoperability Standards Organization, should use this best-
practice guidance as a basis to initiate an international standard for CM development.

O-2 RTO-TR-MSG-058
 Chapter 1 – BACKGROUND OF MSG-058 EFFORT

Conceptual models are key to the transformation of user needs and requirements to modeling and simulation
(M&S) design, implementation and use. Conceptual models form the bridges of understanding between the
users of M&S, the military domain experts that have the necessary knowledge that must be represented in
M&S, and the software and simulation engineers that implement simulations. Neither a standard practice for
conceptual model development nor consensus definition of conceptual model content currently exists. Where
conceptual modeling is practiced, it is typically defined on a project-to-project basis. A recommended best-
practice including specification of the content of conceptual models for M&S will increase user understanding
of the capabilities of those M&S, thus increasing their reusability and interoperability.

The North Atlantic Treaty Organisation (NATO) Modeling and Simulation Group (NMSG) was established
within the Research and Technology Organisation (RTO) in 1999, with an objective to favour re-use and
interoperability of M&S within the Alliance, and NATO/PfP Nations. So far, within NATO, as within the
international M&S community, the interoperability objective has been mainly addressed at the “technical level”
using open standards developed by the Simulation Interoperability Standards Organization (SISO), Institute of
Electrical and Electronics Engineers (IEEE) or International Organization for Standards (ISO), such as the High
Level Architecture (HLA) that was adopted by NATO as early as 1998. Those standards have provided a first
step to interoperability and a state-of-the-art way to interconnect simulations and tools to build distributed
systems of simulations; but it is recognized that existing standards are neither intended nor sufficient for
specification and controlled exchange of semantics and concepts.

Since the beginning of the NMSG activity, it was recognized that HLA was only a preliminary step to satisfy
the M&S technical interoperability concern and that the final objective was still to achieve a more ambitious
M&S “interoperability level”. This final objective should be to achieve a common understanding and use of
information exchanged between simulations for better satisfying military requirements for education, training
and operational support. Without conceptual models, history has shown that simulation developers often do
not sufficiently understand the military domain to be modelled, implement M&S that do not reflect the
intended reality, and thus do not satisfy the user’s needs. Further, conceptual models form the basis of an
important step in Verification and Validation – determining that the application domain has been described
sufficiently to meet users’ needs while accurately incorporating Subject-Matter Expert (SME) knowledge.

SISO recognized the importance of better defining and advising the M&S community on the importance of
conceptual models not only for the interoperability issue but also to form a basis for simulation development,
foster re-use, and to support Verification and Validation (V&V) activities. A SISO Task Group was created in
2003 to address the topic of conceptual models with the potential objective of developing a new standard,
or more precisely a “guide”, to help practitioners building conceptual models. While this SISO Task Group
did not proceed to the publication of such a guide, it nevertheless produced interesting and valuable output
that can be exploited to produce a recommended practice guide for the elaboration of conceptual models.

RTO-TR-MSG-058 1-1
BACKGROUND OF MSG-058 EFFORT

1-2 RTO-TR-MSG-058
 Chapter 2 – OBJECTIVE OF MSG-058 EFFORT

In April 2008, then, the NMSG originated a Task Group (MSG-058) to develop a guidance document on
conceptual models, which can be used in the future by NATO to support its M&S requirements. The major
objectives of this Task Group, according to its Technical Advisory Panel (TAP) Terms Of Reference (TOR)
charter of June 2007, enclosed as Annex A and B respectively are:
1) Clarify the “Conceptual Model” concepts, discuss the terminology, and emphasize the utility to better
formalize conceptual models, understand the relationship between conceptual modeling and related
concepts (scenario definition, etc.);
2) Investigate methodologies, simulation and software engineering processes, initiatives and technologies
useful for the establishment and content of conceptual models;
3) Draft a guidance document on conceptual models that can be used by different stakeholders (sponsor/
user, project manager, subject-matter experts, V&V agents, developers, etc.);
4) Foster the establishment of the guidance document as a SISO standard;
5) Identify the relevant stakeholders of conceptual models and considering whether a prioritization is
needed;
6) Address the needs of M&S community, identifying the way conceptual models may contribute to
M&S development, and providing guidance to implementation; and
7) Provide guidelines for standards in conceptual modeling for M&S; thereby specifying a conceptual
model to be (re)usable by users with similar knowledge and to be accepted by the computer science
community.

The Task Group’s first objective was to clarify what a conceptual model for M&S is and what it represents.
A common understanding from the outset of the effort was that a conceptual model should serve as a frame of
reference for simulation development by documenting important entities/concepts, their properties, and their
key actions and interactions. That is, a conceptual model should bridge between the requirements and simulation
design. The use of simulation in military applications such as training and decision support requires that the
simulations are fit for use. V&V can be applied to evaluate if this fitness for use is achieved. The quality of the
end-product (i.e., the simulator) is, however, largely dependent on the quality of the intermediate products.
To be more specific, a large portion of the problems with the end-product come from a poor understanding of
the customer’s situation which leads to a low quality of the requirements. Explicitly building a conceptual
model is one of the ways to improve the quality of the end-product by allowing for a good starting point for its
development. In order for the conceptual model to be able to really improve the quality of the consequent
simulation, the quality of the conceptual model itself must be sufficiently high. Building the conceptual model
is the step in simulation development in which the actual modeling takes place. Therefore validation (determining
whether the abstractions taken during the modeling are allowed) of the conceptual model against the
stakeholders’ purpose is important for the simulation’s fitness for purpose. From a project management point
of view, the conceptual model is the last step in simulation development where correcting errors, such as
having erroneously left out important parts that should be represented in the end-product, is still relatively
easy, quick and cheap. If design and implementation starts, correcting mistakes quickly becomes much more
costly. Therefore V&V of the conceptual model is an important form of risk mitigation.

Therefore, the Task Group endeavoured to clarify and rigorously define the core terminology associated with
conceptual models and conceptual modeling, and the relationship among those terms. Among the issues the Task

RTO-TR-MSG-058 2-1
OBJECTIVE OF MSG-058 EFFORT

Group addressed was clarification of key concepts in respect to which are framed the needs each of these
stakeholders in a conceptual model and the level of abstraction at which conceptual models should be expressed
to meet various stakeholders’ needs. Conceptual Models are one of the key concepts in the development and
employment lifecycle of M&S. As such it is related to other concepts such as scenario development,
simulation software requirements development, and test plan development. As part of the first objective,
the Task Group defined the relationships among conceptual models and these other activities.

The second objective of this Task Group was to investigate methodologies, simulation engineering and
software engineering processes, initiatives and technologies useful for the establishment and content of
conceptual models. While the objective of this Task Group was not to develop or identify a single standard for
the representation of conceptual model content, this Task Group did identify a range of such solutions that can
be employed in conceptual models. In order to take advantage of the work covered by others regarding to this
issue, it was very important to collect and analyze as much as possible of the documentation available on
conceptual models – especially those related to the M&S field. Lesson learnt by them helped to avoid some
recurrent problems, to reduce the risk of developing simulation not adapted to the requirements and to get the
greatest benefit from the effort of this Task Group. The Task Group explored the potential of a variety of
processes and knowledge representation approaches to examine their potential for conceptual modeling.
Through this objective, the Task Group synthesized existing practices to identify the state-of-the-art of
conceptual modeling. By doing this, the Task Group maximized the reuse of previous effort in the development
of a recommended practice.

The third objective of the effort was to provide a tailorable set of guidance to the M&S community on
conceptual modeling processes and products. This will guide users through the conceptual modeling effort by
explaining how to apply it in practice. The process will be tailorable in that it is intended to be extended and
modified by individual programs that apply it. Rather than being a one-size-fits-all rigid, single approach to
conceptual modeling, the guidance will provide a starting point that individual programs can apply given their
specific needs and resources. The guidance on the conceptual model content will state what should be in the
conceptual model, and not mandate a specific format but suggestions for the selection and use of format,
methodology, techniques and tools will be provided. The guidance will encompass the conceptual model
process, conceptual model content and describe appropriate views on a conceptual model for different
stakeholders. For example, the conceptual model process will describe the transformation from the users view,
concerned with the problem domain, to the developers view, focused on the M&S domain.

The Task Group’s fourth objective was to foster the establishment of the guidance document as a SISO
standard. The current policy of NATO for standardization is to use civil standards where appropriate ones
exist and to develop its own standards only when no civil standard exists. In the case of conceptual models for
M&S or conceptual models in general, no civil standard exists. The requirement for M&S conceptual model is
not specific to NATO or to the military domain. Thus it should be helpful to extend this work to a larger M&S
community. With respect to this proposal, the Task Group broadened its guidance document to comprehend in
its work-product the scope of an M&S standard product, developed through an open consensus-based
standards body. The SISO is the best-suited organization for this standardization, since it has a strong
background and current focus on military M&S, but also includes M&S practitioners from outside the military
domain. Finally, the Task Group collaborated with SISO’s Standing Task Group on Conceptual Modeling
throughout the period of performance of the effort in order to facilitate to the greatest extent possible the
acceptance of the Task Group’s work-product as the basis of a successor SISO/IEEE standard.

In addressing the fifth objective, the Task Group identified the key stakeholders in conceptual modeling and
their requirements with respect to conceptual models. Stakeholders will include those that are involved in the
production of conceptual models and those that rely on conceptual models to perform their jobs.

2-2 RTO-TR-MSG-058
 OBJECTIVE OF MSG-058 EFFORT

In response to the sixth objective, the Task Group realized that the value of its eventual work product would
be dependent upon the degree to which it provided value to practicing modeling and simulation professionals
and to the stakeholders involved in the M&S enterprise wherein it is employed; the Group was anxious to
appreciate and to make evident in, auditably traceable form, its perception of the wants and needs of the
conceptual modeling stakeholder community, and the specific attributes desired of its effort and of the
resulting work-product pursuant to that effort. To this effect, desiderata were compiled from a variety of
sources relating to each of the following categories:
• Compliance – Degree of conformance of work-process and work-product to explicit and implicit
guidance.
• Completeness – Degree of exhaustion of effort and resulting product with respect to the fundamental
need to support enterprise conceptual modeling of military models and simulations.
• Correctness – Degree of appropriateness of operational process and conceptual modeling guidance
documentation in subject enterprise environment … roughly the degree to which employment of the
published best-practice specification is likely to result in satisfactory conceptual modeling practices
and conceptual model artefacts, given requisite completeness.
• Consistency – Degree to which the efforts of the Task Group and its resulting work-product are
mutually coherent and based on common precepts and assumptions.
• Utility – Degree to which the employment of the Task Group work-product is useful to stakeholders
in generating, using and maintaining conceptual models in the NATO enterprise environment.

In response to the seventh objective, the Task Groups have to ensure that specific requirements (e.g., attributes
of the Task Groups operating process and/or resulting product) were derived from task guidance, self-generated
concept of operations of the Task Group, and the consensus of product structure, and content agreed upon by the
Task Group during its deliberations. These requirements are documented in Annex C. The requirements serve
both to:
• Indicate the sensitivities of the Task Group in executing its responsibilities and to provide persistent
strategic and tactical guidance for execution of the Task Group effort; and
• Serve both the Task Group itself and the recipients of the Task Group’s work-product, by providing
the means for evaluation of the work-product as against necessary and sufficient criteria.

RTO-TR-MSG-058 2-3
OBJECTIVE OF MSG-058 EFFORT

2-4 RTO-TR-MSG-058
 Chapter 3 – MSG-058 PROGRAM OF WORK

The effort described in this chapter constitutes the program of work executed by the Task Group MSG-058,
which resulted in the generation of the Study work-product, i.e., recommended best-practice guidance for
conceptual modeling for military models and simulations and for the structure and content of the resulting
conceptual model documentary artefact.

3.1 INTRODUCTION
Significant diverse and intensive technical effort was required to meet the Task Group objective. Understanding
conceptual models for military simulations requires employment of a variety of precepts, technical concepts,
and existing circumstances. Generating best-practice guidance for executing conceptual modeling requires
appreciation of a wide variety of academic and practical techniques for ontology creation and conceptual model
specification. Finally, the creation of useful best-practice guidance requires appreciation of existing M&S
management practice, and the standards and techniques associated with specification of both process and product
in expected enterprise operational environments.

Elucidation of the effort conducted by the group in executing the subject study illustrates clearly the diverse
technical basis for the resulting study conclusions and recommendations. Description of the activities of the Task
Group, indication of their necessity or motivational rationale, and description of their intended consequences in
accomplishment of the study objective, is intended to provide detailed context for interpretation and appreciation
of the study results and recommendations. The effort actually executed by MSG-058 is described explicitly
herein for two purposes. First, such a description is intended to demonstrate the practical means whereby the
Group met the conditions set forth in the Study TAP and TOR introduced above. Comparison of the account that
follows and the prescriptive guidance from reference guidance document illustrates that the ‘way of work’ is in
fact compliant with guidance, complete with respect to scope of the guidance, and consistent both internally and
with the intentions of the guidance itself. Secondly, the following description of the programme of work actually
executed by the Group should provide implicit evidence to the reader of this report and the agent striving to
follow the best-practices guidance recommended herein regarding both the quality of the effort and consequent
work-product, and the significance and relevance of the subject best-practice guidance proffered below to the
reader/user’s needs and interests.

The approach adopted by the Group in addressing all these foundational matters was to first identify particular
topics that seemed to entail issues of significance or particular difficulty; to address each of these topics
specifically; and to derive there-from concrete elements of the solution of the study problem to be manifest in
study conclusions and recommendations. In all cases, the Task Group was careful to consider:
• The diversity in the existing practices and technical postures;
• Commonality in practice or in dealing with potential issues; or
• Innovative approaches considered to be auspicious but not in fact part of the experience of any of the
organizations and enterprises of the respective Group members.

3.2 GENERAL DISCUSSION OF EFFORT ELEMENTS

By way of context, comments relating to scope of activity and Concept of Operations (CONOPS) of the
Group’s effort, and associated transaction protocols as well as to relationships among components of the
Group’s effort are introduced first.

RTO-TR-MSG-058 3-1
MSG-058 PROGRAM OF WORK

The effort of the MSG-058 consisted of a series of working meetings augmented with the execution of actions
identified therein in the intervals between formal working meetings. The effort of each meeting was decided
in advance and published as a meeting agenda. Naturally, the differential interests of the Group members and
national participation suggested that one or another Group member might lead deliberation for topic areas of
special interest or competency; nevertheless, all deliberations were conducted by the committee-of-the-whole,
operating as a peer-group, wherein all significant decisions were made as matters of consensus across the
entire Group. Group efforts were coordinated by means of collaboration workspace information technology
resources, wherein, all records of meetings, decisions, actions, and collateral information, were conscientiously
recorded and will be made available for inspection by interested parties in future or related efforts. The use of the
collaboration environment was particularly valuable in supporting the compilation of the Group’s work-product
– whose components’ authorship responsibilities were allocated to Group members based on interest and
familiarity.

The schedule of Group meetings is indicated in the following figure. That illustration indicates the tactic adopted
by the Group to have meetings as frequently as possible, particularly early in the program when disparate
practices and complex concepts requiring face-to-face interaction for adequate resolution were at issue.

Figure 3-1: Calendar Relationship of Meeting Activities Across Which Effort was Distributed.

A rough indication of the logical and activity-flow relationships among the Group’s activities regarding topics
of special import is provided in the figure following. These logical relationships and the nature of particular
activities are discussed in considerable detail below.

3-2 RTO-TR-MSG-058
 MSG-058 PROGRAM OF WORK

Figure 3-2: Logical and Activity Flow Relationships Among

Principal Efforts Comprising the MSG-058 Effort.

Finally, the effort of the Group and its respective domains of interest and resulting meta-products is to be
understood in context of the diagram of Figure 3-3 below. There, the Group executes the MSG-058 program
by way of Business Process Invention. The Group product document specifies conceptual model process to be
conducted by practitioner during Business Process Practice, yielding the conceptual model artefact for the
specific mission space and model-simulation intended.

RTO-TR-MSG-058 3-3
MSG-058 PROGRAM OF WORK

Figure 3-3: Mind-Map Style Illustration of the Scope-of-Effort

and Domain-of-Interest of the MSG-058 Task Group.

Specific topic areas of effort undertaken by the Task Group included the following:
• National Conceptual Modeling Practice Expository Briefings.
• Issue Identification and Analysis.
• Stakeholders and Study Scope and Objective.
• Terminology and Concepts.
• Analytical Framework and Ontological Perspective.
• Standards Review and Evaluation.
• Process, Product and their Relationships.
• Process Specification Expression.
• Conceptual Model Process Elements.
• Conceptual Model Documentation.
• Task Group Work-Product Generation.
• Coordination with SISO for Generation of Subsequent SISO/IEEE International Best-Practice Standard.

3-4 RTO-TR-MSG-058
 MSG-058 PROGRAM OF WORK

For each topic area identified above, we will address briefly:

• Introduction and background;
• Current circumstance;
• Approach;
• Risks and risk-amelioratives;
• Relationships;
• Findings; and
• Conclusions and recommendations.

3.2.1 National Conceptual Modeling Practice Expository Briefings

Naturally, members of the Group convened to execute MSG-058 effort brought with them both their personal
and their national Institutional preconceptions and practices relevant to conceptual modeling. Therefore, in order
to assay the range of interests, competencies, and richness of perception and experience, the systematic review of
existing conceptual models practice was considered prudent. Therefore, Task Group member’s national
representatives briefed in turn their respective practices for conceptual modeling, and those sample practices
were compiled into the Group’s collaborative environment for future reference.

As expected, the range of preconceptions and styles of operations in conceptual modeling practice proved to
be exceptionally diverse. Differentials exist among presumptive academic underpinnings, scope assumed to be
included in conceptual modeling, techniques for educing and documenting conceptual models and for their
use within the various enterprise environments represented. This diversity, while challenging, was considered
by the Group as opportunistic by virtue of its providing a constructively broad scope to the Group’s deliberations
and establishing a suitably broad basis of implicit requirements for any best-practice work-product developed
and recommended by the Group. Consequently, potential risk in task scoping and ecumenical consideration of
established preferred practices were considered to be assuaged.

Review of existing practices familiar to the Group proved a profitable initial transaction. It did in fact serve as
a suitable basis for framing the work process for the remainder of the program, and particularly reinforced the
sense that a consensus-based effort was prudent.

3.2.2 Issue Identification and Analysis

Pursuant the revelation of Task Group members’ respective conceptual modeling practices; it was observed
that a variety of topics might reasonably be specially designated ‘issues’ – that is, topics whose deep appreciation
and consensus resolution by the Group members would likely be necessary to the successful completing of the
MSG-058 effort.

The Group’s approach to issue-identification and resolution is described in detail in Annex D. Significantly,
however, a deliberate effort was made to identify issues related to each of four perspectives:
1) General and administrative conduct of the Task Group tasking;
2) Constraints associated with the program of work defined in the tasking guidance;
3) Technological considerations arising out of the subject matter entailed in conceptual modelling; and

RTO-TR-MSG-058 3-5
MSG-058 PROGRAM OF WORK

4) Considerations related to the generation of work-products necessary and sufficient to accomplish the
mission of MSG-058.

In each case, actions necessary to resolve such issues, and the identification of the entailments of such
resolution to technology, product, program, and meta-process for the Task Group’s effort, were identified.

This approach revealed what proved to be nineteen (19) issues deemed worthy of attention in four (4) categories:
1) Circumstance and Analytical Context;
2) Intention;
3) Product Development and Deployment; and
4) Technical Considerations.

Of the total set of issues explicitly identified, five (5) topics were accorded such criticality that special work
efforts were conceived and executed for their resolution and the remediation of such risks as were considered
to be related thereto. In priority order, these issues were:
• Stakeholder Analysis and Context;
• Scope and Definition;
• Relationship to Standards;
• Specification of Conceptual Model Management Process; and
• Specification of Conceptual Model Artefact.

Each is addressed in the text of this report at a level of indenture no higher than two (i.e., n.m.).

Naturally, early issue identification had profound implications for the establishment of a detailed program of
effort by the Group. The Task Group’s approach to concern for identification and resolution of critical issues
had far-reaching implications for the subsequent effort, and the work-product of which this report and its
enclosed best-practice recommendations consist.

3.2.3 Stakeholders and Study Scope and Objective

In the course of the Task Group’s deliberations, it became apparent that conceptual modeling must be
practiced in context of modeling a simulation enterprise–scope activity. Further, it was clear that the nature of
conceptual modeling shared many of the practices related to ‘user-needs’, and ‘requirements’ management
practices typical of systems engineering disciplines. For both these reasons, the need to be explicit regarding
the identification of stakeholder roles, their associated processes, and responsibilities was evident. At the least,
the Group’s expression of conceptual models best-practice would need to ‘speak to’ significant stakeholder
communities – for which purpose, the Group needed to be appropriately sensitive to those roles.

Consequently, the MSG-058 Task Group devoted considerate attention to identifying and characterizing
stakeholder roles, and to including in our analysis such use-cases as seemed prudent both to understand the
implications of necessary diversity of stakeholder populations in M&S enterprise environments and to
communicate successfully to all parties those entailments.

The results of this analysis are addressed more fully in Section 4.3 Conceptual Modeling Enterprise
Stakeholders, below; and further explication is therefore deferred, except to emphasize the degree to which

3-6 RTO-TR-MSG-058
 MSG-058 PROGRAM OF WORK

stakeholder analysis and respect for stakeholder diversity and peculiarity are necessary conditions for
understanding, let alone employing the best-practice guidance contained herein.

Regarding the study scope and objective, analysis effort addressed primarily the class of conceptual model
being considered, and the analytical disciplines considered necessary and sufficient for subject models to be
managed over their life cycle.

Conceptual models for simulations relating to military mission space domains were, according to the tasking
guidance, the relevant scope. In fact, however, considering the breadth of the adjective ‘military’ in its own
referential scope (covering most of the mission space elements considered typical of non-military mission-
spaces and certainly passing well beyond simple war-fighting operations to encompass logistics, materiel
management, personnel health and safety, operational security, communications, etc.), and considering how
generic most of the ideas associated with conceptual models in general and the pragmatic conceptual models
guidance eventually derived; the scope of applicability of the Group’s work-product is scarcely proscribed by
its ‘military’ appellation.

Likewise, given the interest of conceptual model management (development, documentation, storage, retrieval,
re-use, sharing, etc.), during the conceptual modeling life-cycle, together with the not incidental relationships of
systems engineering (applied here to simulation systems) and enterprise-context operations across considerable
institutional scope (e.g., national and NATO international); very little constraint accrued to the processes
recommended, particularly with respect to requirements management and stakeholder sensitivity.

3.2.4 Terminology and Concepts

In many scientific domains, terminology is critical, see Annex I. Practitioners’ shared appreciation of the state of
evolution of the field of endeavour, and their fundamental capacity to communicate, collaborate and cooperate
depend upon the existence of a well-established vernacular that is shared by the community-of-practice.

Often, such terminology is available through the efforts of past researchers – especially when the discipline is
mature (or simple), taught systematically, and appreciated widely across the community. Conceptual modeling
is not such a discipline. While its roots in the ‘first-philosophies’ of epistemology and ontology are deep,
its explicit practice in modeling and simulation is relatively new. Conceptual modeling terminology is further
confounded by the overloading or multiple meanings of such keywords such as: ‘entity’, ‘model’, ‘concept’,
‘relationship’, ‘attribute’, ‘predicate’, etc. Further, the presumption of one or another conceptual technique,
schema or notation leads promptly to terminological ambiguity. Finally, in an international working group
doing business in English, some challenges to terminological consistency are to be expected.

The approach of the MSG-058 was, from the start, to be scrupulously precise in vocabulary usage, and to
record such determinations as seem best in a lexicon that has evolved over the course of the program and that
is published as Annex J to the present volume. The structure of that annex is, in fact rather a glossary than a
formal definitional lexicon, in which alternative definitions, interpretation, commentary and usages are cited
in hopes of communicating not only the sense of terms as used in the report text, but also to communicate to
the reader the range of nuance which lexical vocabulary may, under one circumstance or another assume.
In doing so, the Task Group hopes both to communicate precisely its own effort, determinations and findings,
but also to share with the reader the degree to which nuance and potential ambiguity persist in a subject only
lately approaching the maturity which modeling and simulation practitioners desire and deserve.

This explicit convergence on vocabulary usage, combined with the consensus-based protocols characteristic of
all the collaborative effort of the Group has resulted in acceptable vocabulary consistency at least within the

RTO-TR-MSG-058 3-7
MSG-058 PROGRAM OF WORK

context of the study. Given that the intention of NATO is to have the present work continued in context of
international standards-development bodies, however, concern for lexical precision cannot be ignored.
The reader is particularly referred to the Glossary, Annex J, for citations and explication of vocabulary used in
the body of this report.

Continued aggressive pursuit of vocabulary and subject-matter semantic consistency in conceptual models
best-practice guidance is strongly recommended.

3.2.5 Analytical Framework and Ontological Perspective

Conceptual modeling entails the abstraction of some ‘referent’ domain’ resulting in a description of that
domain suitable for managing its ‘representation’ by artificial means such as by a model or simulation.
Pursuing the MSG-058 TAP TOR entails assuming one or another ‘analytical frame’ from which to address
consideration of this process and generation of prescriptive guidance to practitioners. This analytical frame is
in effect one or another way of looking at the world. Alternatives of such frames include for instance:
ontology, systems engineering, software engineering, and knowledge management; together with a wide
variety of tools and techniques for pursuing explication of each frame, such as model driven architecture,
Knowledge Acquisition / Knowledge Engineering (KA/KE) assets, systems engineering tools, etc.

The Task Group debated the question of an appropriate analytical frame or prospective from which to proceed,
investigating closely a wide variety of options such as was manifest in the knowledge and practices of the
member national participants and active individual members. Finally, the Task Group elected an ontology-based
perspective, and proceeded to create a systematic process that reflected this foundational perspective, while
drawing from multi-disciplinary perspectives to make the best-practice guidance familiar and pragmatically
practical to the target practitioner and associated stakeholders.

In short, ‘ontology’ asks the rhetorical question: What is there? In the present context, more specific formulations
might be: What do we care about, or alternatively:
• What is it necessary to represent in a model or simulation in order for the resulting product to serve its
intended use; and
• What is necessary to prescribe about the simulation artefact itself for it to be likewise useful? Given
this knowledge, the next question that must be addressed is: How can one select, and document the
contents of such representations?

Two complimentary risks are associated with the Group’s addressing selection of analytical frame. On the one
hand, failing to establish an intellectually secure frame leaves the establishment of a conceptual model a
proverbial foundation of sand. On the other hand, making the proceedings and consequent product of the
Group too explicitly bound to potentially abstruse academic precepts, constructs, and inferences risks
alienating potential practitioners. The risk management tactic adopted by the Group was to dig deep and build
on firm foundations, and to report those deliberations; but to efface such considerations from the pragmatic
process guidance provided in the ‘best-practice’ prescriptive guidance in the document’s Annexes G and H.

To this effect, the subject is explicitly treated separately in Annex E – Explanation of Fundamental Concepts
for Conceptual Model Frame-of-Reference. In addition, copious references are provided in Annex K –
Bibliography, that document the fundamental ontological perspective upon which many of the Task Group’s
deliberations were fundamentally based. Nevertheless, this analysis and exposition and the academic-
intellectual underpinnings it deploys can be skipped for the sake of convenience or for lack of explicit interest

3-8 RTO-TR-MSG-058
 MSG-058 PROGRAM OF WORK

by the reader without detracting from either the comprehensibility or the utility of the concrete best-practice
guidance contained herein.

3.2.6 Standards Review and Evaluation

The present document – particularly its operationally concrete and procedurally prescriptive guidance contained
in Annex G – Conceptual Modeling Process Activity Description and Annex H – Conceptual Model Product
Description – is itself a ‘soft’ standard, of type usually denoted ‘best-practice’. On the other hand, the analysis
entailed in deriving such practice and the expression of the practice itself entails consideration of standards of a
wide variety of types.

A significant effort by the MSG-058 Task Group was to review standards perceived as potentially relevant to
the subject analysis and prescriptive guidance; to analyze the special significance of such candidate standards;
and to invoke such standards (individually, by reference, or more often by class) in either the analysis reported
herein or the procedural guidance appended.

The strategic approach of the Group was to leverage existing standards instances and standards types to the
greatest extent possible in order to reduce redundancy and invoke guidance re-use wherever possible.
At the same time, however, we have been scrupulous to avoid recommending specific standards when a class
of standards could be cited and the choice of a particular standard left to the discretion of the practitioner.

The subject of standards is detailed in Annex F – Standards, but should be interpreted throughout as an exercise
in coaching of the practitioner toward more systematic professional and productive practice commensurate
with the mores of his own enterprise environment.

3.2.7 Process, Product and their Relationships

Within this document, there are two primary processes described, to be executed by one or another of two
agencies, and resulting in one or another of two significant work-products. In this section, we identify briefly
these processes, agents, and work-products and indicate their relationships before proceeding with more
detailed descriptions in following text sections. In order to establish a perceptual frame of the set of agents,
activities, and products that comprise the development of this document and its included best-practice
guidance as well as the execution of that guidance and the generation of consequent conceptual models,
the reader is referred to the following Figure 3-4.

RTO-TR-MSG-058 3-9
MSG-058 PROGRAM OF WORK

Figure 3-4: Relationships Among Agents, Processes, and Products Associated with
Subject MSG-058 Effort and its Consequential Conceptual Modeling Practice.

As indicated in the diagram, the MSG-058 Task Group itself performed the activity of analyzing conceptual
modeling and formulating requisite best-practice guidance. The persistent information product resulting from
that activity is the best-practice guidance specification contained within this document in Chapters 5 and 6 and
in the Annexes G and H. The causal relationship between this activity and its consequent resulting work-
product is indicated by the blue arrow numbered 1. Subsequently, the M&S conceptual modeling development
practitioner is expected to execute the prescriptive best-practice to produce the conceptual model itself.
This productive result is indicated by the blue arrow number 2. Finally, the activity conducted by conceptual
modeling practitioners and the work-product produced thereby are shown to be affected by the best-practice
guidance specification through influence designated by red arrows 3 and 4 respectively. With this activity and
influence relationships in mind, comments follow relating to process and product specification generated by
the Task Group.

3.2.8 Process Specification Expression

The MSG-058 Task Group explicitly addressed consideration of the most appropriate form of specification of its
guidance to conceptual model stakeholders. Process specification itself admits to a wide variety of schemas,
notations, and seminal notions. Since the Group could not provide multiple alternative specifications, and chose
not to endorse a single specific notational or conceptual frame for process specification, we resorted to what was
held to be a generic or vanilla specification schema – without, however, falling prey to least-common-
denominator information content. The meta-process specification schema employed (employed as partial graphic
illustrations in the text of Chapters 5 and 6 and defined in detail in association with the Annex G wherein it is
employed to communicate the recommended conceptual modeling processes) is considered to be sufficient,
complete, consistent, and formally equivalent to most commonly employed process specification schemas and
notations, and implementing Commercial-Off-The-Shelf (COTS) tools.

Naturally, the practitioner is encouraged to use schemas, tools, and techniques to specify the objective system
processes such as constitute the content of the actual conceptual model as are deemed appropriate to the

3 - 10 RTO-TR-MSG-058
 MSG-058 PROGRAM OF WORK

enterprise context in which execution of conceptual modeling is to be conducted. In that way, considerations
such as machine readability, COTS tools availability, and compliance with enterprise process specification
standards are well within the discretion of the practitioner-agent for the benefits intended thereby.

3.2.9 Conceptual Model Process Elements

Moving from consideration of meta-process specification practiced in formulating the best-practice
instructions proffered below, to the actual prescription of elements of process models considered necessary
and sufficient to contain and communicate model and simulation object and process semantic content;
the Task Group again, resorted to the use of nominative or generic conceptual primitives that were considered
equivalently powerful as specific conventional notations and styles of object and process specification.
Supporting on the one hand, object qualia such as: class membership, generalization and specialization,
inheritance of attributes, membership and client server associations, etc., and on the other hand, process constructs
as sequence and concurrency, causal effect, temporal synchronization, process composition and encapsulation,
etc.; the notation used in the subject best-practice specification is considered likewise sufficiently general to
serve all needs, and sufficiently suggestive and non-binding to be able to be implemented by the use of such
specific process primitives as are to be found in typical practices and tools.

Once again, the practitioner’s discretion to use such constructs and notations as are commensurate with
technical, programmatic, and enterprise constraints is protected, while the sufficiency of actual conceptual
models to contain necessary and sufficient information is guaranteed.

3.2.10 Conceptual Model Documentation

Consideration of the conceptual model documentation, as discriminated from both the conceptual model
generation and its specific information content generated for one or another application, was a matter of
particular concern to the Group. That documentation activity is yet another meta-process – that is, one of the
operations by the conceptual model management practitioner whereby the conceptual model, having been
abstracted from appreciation of the subject mission- and simulation-space, is made manifest in persistent,
communicable, achievable, and recoverable form, that can serve as well as a reference information artefact
from which model or simulation implementation may proceed and subsequently be verified. Documentation
artefacts resulting from practitioners’ efforts were considered to be appropriately subject to best-practice
guidance; and providing instruction to practitioners on recommended structural form and general semantic
content of such artefacts was felt to be a significant component of best-practice guidance.

In order to influence conceptual model artefacts generated pursuant to election and execution of best-practice
guidance by conceptual modeling stakeholders, the Task Group elected to provide to the conceptual modeling
practitioner dual forms of guidance (i.e., process and product) whereby one perspective addressed conceptual
model development process and the other addressed the resulting conceptual model product document
artefact. Having addressed conceptual modeling process elements, as described above, and having resolved to
provide guidance to practitioners, the Group determined to address the characteristics recommended for the
consequent conceptual model ‘Product’ itself, namely the document (or other form of persistent capture of the
conceptual model’s semantic content) expected to be generated by the practitioner in accomplishing his
objective conceptual modeling effort.

Since a necessary criterion for completion of conceptual model development and use is the generation of a
persistent capture of information relevant to the conceptual model development, contents, life-cycle management,

RTO-TR-MSG-058 3 - 11
MSG-058 PROGRAM OF WORK

and uses, the Task Group resolved to provide necessary and sufficient guidance for the generation of such
documentation. Guidance related to conceptual model product artefacts is ‘dual’ to process guidance
addressed above; and the result of the pursuit of this approach is Chapter 5 and Annex G of this report.
In effect, the Task Group determined that if the conceptual modeling practitioner executed the Process
Guidance of Chapter 5 in this report; then there would result a documentary product whose desired
characteristics are described in Chapter 6 and Annex H of this report. Product Guidance, therefore, contains
specification of expected information-content and expositional-structure of the resulting conceptual model
documentation itself.

Throughout the Task Group’s deliberations and everywhere in its derived prescriptive guidance, emphasis of
data contents over expository structure was assumed. Attention to capture of information necessary and
sufficient to support the conceptual modeling facet of M&S enterprise operations of the specific M&S
community of practice for which the conceptual model is intended was kept clearly in mind and made manifest
to the greatest degree possible in recommended practice guidance processes prescribed below. This commitment
was modulated with considerable sensitivity to avoiding too restrictive prescription of documentary practice that
local or national standards could not conveniently be employed.

The Task Group concluded that by providing complimentary process and product prescriptive guidance,
the prospect of successful completion of conceptual modeling practitioners’ efforts and the result of appropriate
conceptual model documentation might be assured.

3.2.11 Task Group Work-Product Generation

The Task Group was well aware that the results of the effort were expected to be a documentary report serving
the following functions:
• Establishing the context of the subject effort by reciting background circumstances and Task Group
objectives;
• Providing a recitation of the effort of the Group sufficient to illustrate how their determinations and
findings were arrived at, and establishing the credibility of the group process and consequently the
relevance of its effort; and
• Capturing prescriptive guidance for M&S conceptual modeling practitioners regarding the generation
and documentation of subject conceptual models commensurate with NATO M&S enterprise wants
and needs on the one hand and the need for explicit guidance to practitioners occupied in conceptual
model management on the other.

According to the “TERMS OF REFERENCE RTG on Conceptual Modeling for M&S MSG-058, RTG-038:”,
the Task Group was to “Draft a guidance document on conceptual modeling that can be used by different
stakeholders (sponsor/user, project manager, subject-matter experts, V&V agents, developers, etc.)”, with the
admonition that: “The final work will be to provide a tailorable set of guidance to the M&S community on
conceptual modeling” … provided as a “Technical Report”… which final report should be a “guidance
document freely available to the international community”.

The Group’s approach to the generation of this work-product was to execute the following process:
• Establish subject matter suitable for inclusion in the product;
• Agree on the expository outline deemed most clearly to accomplish the functions cited above;

3 - 12 RTO-TR-MSG-058
 MSG-058 PROGRAM OF WORK

• Negotiate voluntary adoption of writing assignments among the Group members according to
personal familiarity with the subject matter in respective documentary outline sections, and equitable
distribution of workload among the Group participants;
• Complete storyboard specifications of subject-matter exposition, including attention to elements
indicated in the NATO Conceptual Model Storyboard template;
• Review in plenary the storyboards and establish consistent plan of explication;
• Draft respective sections;
• Compile and integrate full documentary report; and
• Conduct review of document by all members of the Task Group and determination of consensus
support of final work-product.

While small risk was expected relating to consistency, correctness, and lucidity of explanations of the
individual sections (due to conscientious record-keeping by the Task Group via its collaborative environment
during effort execution and the personal and professional qualifications and competencies of the authority team),
the formal composition process implemented served to ensure consistency and economic documentation of the
Group effort and its consequent determinations and findings.

One significant decision was to produce one report work-product; within which the subject-recommended
best-practice standard was contained. Consequently, Chapter 4 “Conceptual Modeling Best-Practice Guidance
Introduction”, Chapter 5 “Conceptual Modeling Process Guidance”, Chapter 6 “Conceptual Model Product
Guidance” and their accompanying Annexes G – “Conceptual Modeling Process Activity Descriptions” and H
– “Conceptual Model Product Descriptions” are considered appropriate to serve as stand-alone as prescriptive
best-practice guidance and to be proffered to the NATO and SISO communities for excision and publication
for the reference of conceptual model management practitioners and related stakeholders.

3.2.12 Coordination with SISO for Generation of Subsequent SISO/IEEE International

Best-Practice Standard
At the inception of Task Group activity, collaboration with other international standards organizations was
anticipated and made explicit in the TOR tasking. In particular, the intention was to: “Foster the establishment
of the [Task Group work-product] guidance document as a SISO standard.”

The desired scope of prospective collaboration was specified as “Liaison” in the Terms of Reference and should
be established with the following organizations:
• MSG-054 Task Group on “An Overlay Standard for Verification, Validation, and Accreditation
(VV&A) of Federations”.
• MSG-052 Task Group on “Establishment of a Knowledge Network for Federation Architecture and
Design”.
• The coming Task Group IST-075/RTG-034 on “Semantic Interoperability” (Continuation of the IST
group ET-040 on “Ontology fusion”).
• Simulation Interoperability Standards Organization (SISO).
• Other RTO Task Groups as required.

RTO-TR-MSG-058 3 - 13
MSG-058 PROGRAM OF WORK

Means for implementing such collaboration process were left to the discretion of the Task Group and were,
in fact pursued to the greatest extent allowed by circumstances, resources, and perceived probability of
success of the Task Group’s subject tasking. Interface was implemented by means of exchange of briefings
publications of papers, and meetings at which information was exchanged on current state of effort and
expectations for immanent progress.

As a consequence of this collaboration, it is expected that, as desired: “The final report should be a ‘guidance
document’ freely available to the international community.”

3.3 CONCLUSION
Based on the process model and activity of the Task Group described in the preceding sections, the contents of
Chapters 4, 5, and 6 were generated, which together with their accompanying annexes, constitute the
recommended best-practice guidance for conceptual modeling for Military Models and Simulations.

3 - 14 RTO-TR-MSG-058
 Chapter 4 – INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

In the previous chapter, we addressed the conduct of MSG-058 and identified significant issues and strategies
associated with the accomplishment of the Task Group’s effort. In following chapters, we present exposition
of best-practice guidance process and product finally developed and recommended to the conceptual modeling
practitioner and stakeholder community for employment. In this Chapter 4, we establish the conditional
determinations and findings upon which that operational best-practice is predicated. The discussion following
addresses contextual issues of scope and enterprise context, and the appreciation of the stakeholder community
whose wants, needs and collaborative participation are necessary for successful conceptual modeling.
Foundational and pragmatic ideas related to specialized vocabulary, the complementary dyadic conceptions of
representation spaces, and best-practice notational conventions are introduced in anticipation of the use of this
terminology and these concepts in the formal prescriptive guidance to follow in Chapters 5 and 6. Finally,
we comment on quality attributes of conceptual models in order to emphasize the necessity to verify and validate
simulation conceptual models in much the same way as simulation artefacts themselves are verified and
validated as a fundamental component of conceptual model quality management.

4.1 CONCEPTUAL MODELING OPERATIONAL SCOPE

While the scope of this guidance is nominally for NATO military modeling and simulation, the approach
taken herein is to provide comprehensive guidance that can easily be adapted and tailored to individual
enterprises and can be generalized to apply to alternative domains. Likewise, this guidance is intended to be
general enough to serve as a foundation for subsequent establishment of industry standards for conceptual
model development and life-cycle management activities.

Throughout MSG-058 deliberations, the Task Group found it convenient to keep in mind two contextual
perspectives of conceptual modeling and conceptual models – both simple – each suggestive of the place of
conceptual models and modeling in simulation life-cycle development paradigms. Such pictorial paradigms
served to remind the Group at once of the intended scope of deliberation and of consequent best-practice
guidance as well as the context of its analysis and work-products.

Consequently, it may be useful to consider a general case of conceptual modeling as shown in Figure 4-1,
to illustrate that any conceptual model of interest may be of a particularly simple or complex domain or
problem space, which can also benefit from these best-practices.

RTO-TR-MSG-058 4-1
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

Figure 4-1: Conceptual Model Depicted as Intermediate Artefact Between Real-World

or Mission Space Knowledge and Simulation Artefact and as Element in
Progressive Simulation Life-Cycle Development Process.

While the application of this guidance is intended to be broad, the scope of this guidance is targeted to the
conceptual model development process, and only provides limited best-practices pertaining to the rest of the
conceptual model life cycle. And while the development of quality conceptual models enables other life-cycle
characteristics such as interoperability and transformation, guidance to execute the additional stages is beyond
the scope of this document. Figure 4-2 provides a context for the guidance provided here, as related to the
larger conceptual model life cycle.

4-2 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

Figure 4-2: The Scope of Best-Practice Guidance in the Conceptual Model Life Cycle.

The approach for explication of this guidance is to discuss the role a conceptual model should have in the
M&S development process, propose scope and terms of reference, expand and illustrate new and novel
concepts, propose an analytical framework, define a thorough but tailorable process and associated products,
and provide Process Activity and product descriptions for reference.

4.2 ENTERPRISE CONTEXT

One particularly significant component of the context of conceptual modeling is the institutional or business
practice environment within which the modeling is performed and within which its value is expected to be
realized. In the text that follows, we introduce the idea of enterprise context by discussing how modeling and
simulation has evolved within the last decades. Next we define ‘enterprise’ and distinguish between ‘local’
operational contexts and enterprise contexts. Several implications that are entailed by enterprise-based
conceptual modeling operations, including both:

RTO-TR-MSG-058 4-3
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

• The influence of enterprise concepts-of-operations upon conceptual modeling process and the nature
of conceptual models themselves; and
• The entailments of conceptual modeling and the use of conceptual model artefacts for the success of
the enterprise environment, in which they are contained, will be described.

The very significant perspective of the control of quality of conceptual models over their life-cycle evolution
– usually designated verification and validation of the conceptual model – are addressed in a following section
in order to address in appropriate detail the specific place of conceptual model quality management in enterprise
contexts.

4.2.1 Evolution of Operational Context

Modeling and simulation in general, and conceptual modeling in particular, are being conducted in different
environments in recent decades than previously.

Heretofore, M&S (and conceptual modeling) were technical specialties that were conducted by individual
staff, largely below the level of visibility of the organization-level management. Conceptual modeling was
itself mostly a craft competency; and its conduct was private to the simulation developer or to the small Group
of which he was a member. Conceptualization was a personal skill, seldom conducted at even Group level of
visibility, and less often documented at all but instead manifest only implicitly in the simulation products
produced by individuals or development Groups. Simulation development efforts were modest in size and scope
or were organic within one or another user community. Simulations were seldom shared, re-used or operated in
combination with other models or simulations; and there was little appetite or motivation for explicit, deliberate,
public conceptual modeling practice and products.

More recently, M&S has become a significant component of operations within organizations. Consequently,
M&S and their attendant conceptual modeling efforts have become both more expensive, and more critically
valuable to the organizations within which they are conducted. Expectation of M&S re-use and interoperability,
sensitivity to demonstrated M&S credibility through systematic verification and validation, and the persistence
and pervasiveness of use of simulations within and beyond organizational boundaries have made deliberate,
public, and accountable M&S practice in enterprise context the norm.

4.2.2 Enterprise Definition

For purposes of this discussion, the following definition is provided:
Enterprise n. – One or more organizations under common control. Generally refers to the broadest
scope of organization and operational process relevant to the subject discussion rather than to
individual components thereof.

NATO and national defence establishment M&S communities-of-practice are de facto enterprises in this spirit
when the investment, development, maintenance, and use of M&S assets are concerned. Naturally, the scope
of any particular enterprise environment depends upon the circumstances and particularities of the M&S
operation in question; but in most cases, questions of strategic investment in M&S policy, practice and
implementation has as its scope the entire NATO community. The fundamental need for successful investment
in modeling and simulation within NATO is well documented and broadly recognized. In addition, more than
a few efforts have been conducted to assess the then-current state, prevalent need, and recognized gaps of

4-4 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

business practices for M&S, and the deliberate management of M&S investment to achieve necessary and
sufficient state of mission capability. Such efforts have included: NATO M&S Conference [1] and Study
Group [2] activity; initiatives by other national defence establishments [3]; efforts by professional societies to
analyze the mechanisms of M&S cost-effectiveness [4][5][6][7][8]; and academic research efforts [9][10].

Enterprise-level M&S investment requires structure, persistence and common valuation for consistent
execution. To paraphrase a quote [11] from the commercial environment:
Stand-alone M&S strategies don’t work when DoD’s enterprise-wide success depends on the collective
value created across the organizations that influence the creation and delivery of value derived from
investment in M&S. Knowing what to do requires understanding DoD’s ecosystem and leadership’s role
in it.

This admonition advances the fundamental premise that commercial businesses exist and thrive (or not)
within the context of a business environment much larger than exists within the boundaries of an individual
firm; and that to succeed, individual firms must learn to recognize and create value within ‘the ecosystem’ in
which they exist. The article defined a ‘business ecosystem’ as that set of external organizations to which the
success of your organization is closely tied, those for which critical dependencies exist. The key to maximizing
value on an enterprise level is, as is implied by an ‘ecosystem’ viewpoint, understanding who shoulders the
costs, and who potentially derives value from the allocation of resources to M&S.

4.2.3 Implications of Enterprise Context for Conceptual Modeling Practice

Enterprise level processes and products are required for all components of the M&S life cycle within the
organization, but nowhere more than in the area of conceptual modeling.

From the perspective of enterprise operations, several implications follow for conceptual modeling practice.
These influences must be reflected in recommended conceptual modeling best-practice, and constitute,
in fact, a substantial set of the requirements for such practice. Among the several requirements driven by the
expectation that conceptual models will inhabit an enterprise environment are the following:
• Stakeholder Community – Conceptual modeling will be conducted and its value recovered in a
community or practice commensurate with the scope and diversity of the enterprise participants.
Concepts invoked to develop, understand, share, and reuse conceptual model artefacts with confidence,
and with reasonable expectation of accruing the benefits of shared investment require that all
stakeholder roles be carefully defined and be appreciated as pertaining across the enterprise scope.
• Process Consistency, Commonality and Tailorability – Processes comprising the conceptual model
best-practice must be appropriate for execution in a NATO-diverse constituency. Best-practice process
elements must be sufficiently consistent that participation in conceptual modeling can be extended across
any sub-set of the NATO M&S community. Practice commonality must have a similar domain in order
that suitable common ground exist from which NATO M&S constituents may fully appreciate both how
conceptual models were achieved and what their contents are, once produced. Conceptual modeling
processes and products must, nevertheless, be sufficiently tailorable so that they can be socialized by any
particular sub-set of the enterprise to which they will particularly pertain – and they must be sufficiently
tailorable as to admit the specific referent subject matter, conceptual constructs, and representational
schemas as may be elected by one or another sub-set of the stakeholder community.

• Product Consistency – Conceptual model product consistency must be sufficient that the library
of conceptual models deployed and used within the NATO M&S enterprise are at least evidently

RTO-TR-MSG-058 4-5
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

interpretable among stakeholders, and preferably interoperable (to within similarity of mission- and
simulation-space referents) across the enterprise. While complete interoperability and exhaustive
re-usability are not likely to occur even under the most auspicious circumstances, and while it is
certain that no degree of product ‘best-practice’ results could guarantee such consistency; any element
of the prescribed practice that can be established with a view to improving product consistency should
be adopted.
• Product Quality – Conceptual model product quality across the enterprise is relevant from two
complimentary perspectives. On the one hand, consistent quality resulting from the subject guidance
is directly correlated to the value of the return on investment in conceptual modeling itself. On the
other hand, sufficient and auditably documented product quality across conceptual models will
influence greatly both the likelihood of use of the conceptual modeling best-practice guidance and the
re-use, sharing, and recovery of utility of the pursuant models themselves.

4.2.4 Consequences of Conceptual Modeling for Enterprise Mission

The use of simulation in military applications such as analysis, acquisition, training and decision support
requires that the simulations are fit for use. V&V can be applied to evaluate if this fitness for use is achieved.
The quality of the end-product (i.e., the simulation) is, however, largely dependent on the quality of the
intermediate products. To be more specific, a large portion of the problems with the end-product come from a
poor understanding of the customer’s situation which leads to a low quality of the requirements. Explicitly
building a conceptual model is one of the ways to improve the quality of the end-product by allowing for a
good starting point for its development. In order for the conceptual model to be able to really improve the
overall quality, the quality of the conceptual model itself must be sufficiently high. Building the conceptual
model is the step in simulation development in which the actual modeling takes place. Therefore validation
(determining whether the abstractions taken during the modeling are allowed) of the conceptual model against
the stakeholders’ purpose is important for the simulation’s fitness for purpose.

From a project management point of view, the conceptual model is the last step in simulation development
where correcting errors, such as having erroneously left out important parts that should be represented in the
end-product, is still relatively easy, quick and cheap. If simulation design and implementation starts, correcting
mistakes quickly becomes much more costly. Therefore V&V of the conceptual model is an important form of
risk mitigation.

The amount of resources put into the V&V effort must be related to the risk (financial risk, loss of lives, etc.)
of using a faulty end-product because a faulty conceptual model was used for its development. If almost no
consequences exist of using a faulty conceptual model then the V&V effort may be low. If, however,
a substantial risk is present, and using M&S results for military application usually has, the V&V effort must
be accordingly.

For an enterprise it is advantageous to re-use as much of previous efforts as possible. This means that
conceptual models from previous projects should be available for re-use, but it also means that V&V results
should be available. One important way of achieving this is to use a set of enterprise-mandated processes and
product formats. Then a common approach across projects can be achieved. On enterprise level, a V&V
methodology must be chosen that supports this reuse in the sense that the V&V data of previous efforts should
be (partially) re-usable.

4-6 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

4.3 CONCEPTUAL MODELING ENTERPRISE STAKEHOLDERS

Stakeholders can be defined as people being affected by a process or product. In this sense conceptual modeling
and conceptual models have a number of stakeholders – each with different responsibilities, concerns and
interests. They will typically also have different backgrounds and consequentially different perspectives,
and therefore often use different “languages” or terminology.

4.3.1 The Importance of Identifying Stakeholders

Explicit identification of stakeholders of the conceptual modeling endeavor will help each stakeholder
understand his role in a larger context. It will make him aware of the roles of other stakeholders and thus
facilitating necessary communication between stakeholders.

4.3.2 Main Categories of Stakeholders

The primary stakeholder targeted by this guidance is the developer of conceptual models. There are however
several other types of stakeholders. These can be referred to by many names. For our purpose we will use the
following main categories:
• Sponsor: This is a person or organization that sees a need for modeling and simulation in the solving
of a problem such as specifying an operational requirement or analyzing a capability. The sponsor
will typically initiate and fund a modeling and simulation activity.
• Producer: This is a person or organization that will endeavor to satisfy the sponsor’s need.
The supplier will undertake activities such as project management and development of the conceptual
model. This will typically include subject-matter experts providing mission space knowledge and
knowledge engineers eliciting, structuring and documenting knowledge.
• Consumer: This is a person or organization that will put the conceptual model to use in order to
implement an executable model to satisfy the sponsor’s needs. The users of the simulation model may
also be conceptual model consumers, as they will profit from understanding mission domain concepts
and their relationships.

In an organization where conceptual model development is a recurring activity, it will, in the long run,
pay to employ a repository containing results from past development efforts. In this approach is chosen, there
will be need for a:
• Custodian: This is the person or organization that ensures that the repository is maintained and policies
adhered to.

In order to ensure the quality of the conceptual model, it is recommended to implement a verification and
validation process. This will be carried out by an:
• Evaluator: The person/organization that validates the conceptual models.

4.3.3 Use Case Description of a Conceptual Model Development Process

Figure 4-3 shows a high level view of the activities and stakeholders typically involved during a conceptual
model development process.

RTO-TR-MSG-058 4-7
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

u c C M D e v e lo p m e n t U s e C a s e s

P ro d u c t i o n , m a n a g e m e n t a n d u se o f C o n c e p tu a l M o d e l s (C M ) 1 . S e t st ra t e g i c o b j e c t i v e s a n d c a p a b i l i t y n e e d s
2 . D e f i n e m i ssi o n /sc e n a ri o t o b e a n a l y se d

D e fi n e th e p u r p o s e o f
M o d & S i m a c ti v i ty
1 . C re a t e o r re v i e w re l e v a n t sc e n a ri o s
2 . R e a c h c o n se n su s o n p ro b l e m f o rm u l a t i o n ,
o b j e c ti v e s o f t h e si m u l a t i o n st u d y
S ponsor
3 . P ro d u c e a N e e d S t a te m e n t
4 . S p e c i f y a v a i l a b l e re so u rc e s, e . g . m a n -y e a rs,
C l a r i fy o b j e c ti v e s a n d
b u d g e t, ti m e
s p e c i fy a v a i l a b l e
re s o u rc e s
P ro d u c e r
1 . I d e n t i f y t h e st a ke h o l d e rs
2 . D e f i n e th e i r i n t e re st s/ c o n c e rn s
3 . D e sc ri b e t h e i r i n v o l v e m e n t i n t h e p ro j e c t
4 . I n f o rm t h e st a ke h o l d e rs o f t h e i r ro l e s a n d
I d e n ti fy s ta k e h o l d e r s
a u t h o ri t i e s
a n d a s s i g n m a n d a te s
M & S P ro j e c t M a n a g e r

1 . S e c u re n e c e ssa ry re so u rc e s
D e ve lo p e r
2 . A ssi g n p ro j e c t te a m ro l e s
3 . E st a b l i sh a n M & S p ro j e c t p l a n (W B S , re so u rc e
E s ta b l i s h a n M & S
a l l o c a t i o n , sc h e d u l e )
d e v e lo p m e n t p la n a n d
4 . E st a b l i sh C M a n d o t h e r p o l i c i e s
a p r o j e c t te a m

M i l i ta r y S M E 1. E l i c i t e re q u i re m e n ts
S p e c ify 2. A n a l y z e re q u i re m e n t s
R e q u ir e m e n ts a n d 3. D o c u m e n t re q u i re m e n t s
M o d e lin g S M E
d e riv e K n o w le d g e 4. D e ri v e kn o w l e d g e n e e d s
I d e n ti fy a u th o r i ta ti v e Ne e ds
k n o w le d g e s o u rc e s a n d
e lic it n e s s e c a ry
K n o w le d g e E n g in e e r 1 . I d e n t i f y a u t h o ri t a t i v e so u rc e s o f m i l i t a ry
k n o w le d g e
kn o w l e d g e
2 . G a th e r K n o w l e d g e
3 . S tru c tu re kn o w l e d g e
4 . Do cu m e n t K n o wle d g e

R e u s e e x i s ti n g C M D e s i g n th e C M
c o m p o n e n ts 1 . D e c i d e o n t h e c o n c e p t u a l p ri m i t i v e s a n d
m o d e l ki n d s th a t c a n re p re se n t t h e kn o w l e d g e
g a t h e re d
2 . S e l e c t F o rm a l i sm (s), v i e w s a n d n o t a t i o n to
C u s to d i a n
su p p o rt t h e C M d o c u m e n t a t i o n

B u i l d th e C M
1 . S e a rc h fo r e x i st i n g C M c o m p o n e n t s w i t h
M a na ge CM d o m a i n o v e rl a p
r e p o s i to r y 2 . I n te g ra t e C M -c o m p o n e n ts i n t o a c o h e re n t
E v a l u a to r o v e ra l l C M

C o n su m e r
1 . P o p u l a t e C M d e si g n w i t h g a th e re d kn o w l e d g e
2 . Do cu m e n t CM
3 . S u b m i t n e w C M t o C M re p o si t o ry
A p p r o v e C M fo r u s e
b y c on s u m e rs
V e r i fy, v a li d a te a n d
M o d e l I m p l e m e n to r A c c re d it C M
1 . P ro v i d e re p o si t o ry se rv i c e s (se a rc h , re t ri e v e ,
st o re , p u rg e , u p d a t e )
A n a l ys t 2 . M a i n ta i n re p o si t o ry c o n t e n t (c a t a l o g u e ,
U s e C M fo r g u i d a n c e c o n f i g u re )
3 . In t e g ra t e n e w kn o w l e d g e i n t o m i l i ta ry d o m a i n
o n to l o g y
Tr a i n i n g S ys te m
D e s ig n e r
1 . E st a b l i sh v a l i d a t i o n p ro c e d u re s a n d c ri t e ri a
2 . R e v i e w a n d e v a l u a te C M s
1 . U se C M f o r u n d e rst a n d i n g t h e 3 . A p p ro v e a d d i t i o n s t o C M re p o si t o ry
m i ssi o n / sc e n a ri o t o b e a n a l y z e d
2 . U se C M f o r sp e c i f y i n g d e t a i l e d re q u i re m e n t s
fo r e xe c u ta b l e m o d e l s
3 . U se C M f o r g u i d a n c e i n d e v e l o p i n g 1 . O f f i c i a l i z e th e C M a s sa t i sf y i n g t h e n e e d
e x e c u t a b l e m o d e l s o r t ra i n i n g sy st e m s st a t e m e n t

Figure 4-3: High Level Use Case Diagram Illustrating the Main Actors
and Interactions During a Conceptual Model Development Process.

4.3.4 Stakeholders Responsibilities

Some of the main concerns of the different stakeholders in the process of conceptual model development and
use are summarized in Table 4-1.

4-8 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

Table 4-1: Stakeholders’ Concerns.

Stakeholder Responsibility
Sponsor • Analysis of combat outcome, system performance, system alternative
trade-offs, etc.
• Cost-effective training.
• Credibility of analysis results.
• Making sure the conceptual model represents necessary and sufficient
relevant information about operational issues and mission context of
interest (correct scope).
• Decision-making based on analysis products (introducing a new
tactic, procuring a new system, etc.).
• Cost of modeling and simulation.
Producer • Effective use of allocated resources (e.g., ensuring reuse when
(M&S Project Manager) appropriate).
• Unambiguous communication with customer.
Producer • Understanding of operational issues and mission context.
(Knowledge Engineer)
• Translation of operational issues and mission context into a
conceptual model.
• Unambiguous communication with SMEs and implementers.
Producer • Understanding operational issues and mission context.
(M&S Subject-Matter Expert,
• Provide technical and military know-how at appropriate level
Military Subject-Matter
of detail.
Expert)
Consumer • Understanding operational issues and mission context.
(Model Implementer)
• Implementation of simulation model.
• Verification of simulation model compliance with
conceptual model.
Consumer • Understanding operational issues and mission context.
(Analyst)
• Producing relevant analysis products.
Consumer • Understanding operational issues and mission context.
(Training System Developer)
• Producing adequate training environment.
Custodian • Provide services for effective reuse of available knowledge and
conceptual model components.
Evaluator • Ensuring validity of conceptual model and compliance with
requirements.

RTO-TR-MSG-058 4-9
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

4.4 CONCEPTUAL MODEL ATTRIBUTES AND DEFINITIONS

Conceptual modeling has often been practiced as an art form or implied activity in M&S development processes.
There was has been little formal structure or definition, and no consistent approach to applying various standards
or formalism in previous practice. Conceptual modeling has been defined in several ways in literature, of which
copious evidence is provided in Annex K – Bibliography. Most of these definitions are compatible, overlapping,
or complimentary, but taken as a whole; they produce considerable ambiguity in regards to the scope of the
conceptual modeling process and products. Further, consideration of conceptual modeling in the Military M&S
context puts additional constraints and implications on the set of applicable definitions.

4.4.1 Scoping Definitions

Since it is difficult to write a definition of conceptual modeling that is not self-referential, and while Annex J
– Lexicon provided a glossary of relevant terms; the following definitions will be used for the purposes of this
guidance document:
• A referent is a set of fictive or existing systems, entities, phenomena, or processes subjected to modeling
and simulation, which a user may want to consider in the context of their own objectives or interest.
• A model is a simplified/abstracted representation of a part of reality or a potential reality. It is a physical,
mathematical, or otherwise logical representation of a referent of interest.
• A simulation is the implementation of a model over time.
• A concept is an abstract idea or a mental symbol, typically associated with a corresponding representation
in language or symbology, that denotes all of the objects in a given category or class of entities,
interactions, phenomena, or relationships between them.
• A conceptual model is a model that abstractly represents a referent.
• An M&S conceptual model is a conceptual model intended for realizing a simulation capability.
• A military M&S conceptual model is an M&S conceptual model within the military domain.

The relationship between these terms is further illustrated in Table 4-2.

4 - 10 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

Table 4-2: Relationships Between Defined Terms.

Term Definition

Subject Attribute Relationship Object

Concept Abstraction Generalized Characterizes Referent

Model Description Simplified Represents Referent

Explicit

Conceptual Model Model Abstract Represents Referent

Military Conceptual Conceptual Represents Military

Model Model Referent

Simulation Conceptual Represents Simulation

Conceptual Model Model Referent in

Military-simulation Conceptual Represents Simulation

Conceptual Model Model Military
Referent in

These basic terms define the content of the conceptual model, which is the set of information that is the
collection of abstractions of the represented referents. But it is also necessary to consider the nature of the
conceptual model in terms of the characteristics, the composition, and the context of the conceptual model in
the relationship of the Conceptual Model Space to the Mission Space and Simulation Space must be defined.

4.4.2 Conceptual Model Characteristics

Any conceptual model will have characteristics of the following categories: Quality Characteristics, Utility
Characteristics, Formality Characteristics, and Abstractness Characteristics. Figure 4-4 provides an illustrative
list of characteristics in these categories, but is not intended to be exhaustive in its illustration.

RTO-TR-MSG-058 4 - 11
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

Figure 4-4: Conceptual Model Characteristics.

A practical set of definitions for these illustrative characteristics may be found in the Lexicon to this document.
Definitions of the four categories are as follows:
• Quality is a totality of features and characteristics of a conceptual model that bear on its ability to
satisfy stated or implied needs. It measures how “good” a conceptual model might be for various
purposes.
• Utility is the property of the relative satisfaction gained by the use of a system expressed in terms of a
value and cost. It measures the kinds of purposes for which the conceptual model might provide
value.
• Formality is compliance with formal or conventional rules.
• Abstractness relates to the way the conceptual model abstracts or symbolizes the referent.

These characteristics are inherent to the conceptual model, and are not necessarily explicitly defined, measured,
or in some cases even known. But it is this set of characteristics that will determine the use of the conceptual
model by the Stakeholders, the re-use of the conceptual model by future Stakeholders, and the V&V Status
throughout the conceptual model development and life cycle.

4 - 12 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

4.4.3 Conceptual Model

Most importantly, the conceptual model has content. And this content is composed, structured, and viewed as
shown in Figure 4-5. This figure shows that a conceptual model is composed of Model Kinds, which are
similarly composed of Conceptual Primitives. Model kinds use Formalism, and Conceptual Primitives are
specified by that Formalism. Notation supports the Formalism and realizes Views, and the Views allow the
conceptual model to be presented in appropriate manners to respective Stakeholders.

Figure 4-5: Conceptual Model Composition.

These composition terms have standard definitions, per Webster:

• Primitive – “an elemental component from which higher-order composites may be composed.
Commonly applied to conceptual model constructs”.
• Model Kind – “a type or alternative classes of models”.
• Formalism – “the practice or the doctrine of strict adherence to prescribed or external forms”.
• Notation – “a system of characters, symbols, or abbreviated expressions used in an art or science or in
mathematics or logic to express technical facts or quantities”.
• View – Explication of a subject model-kind instance created using one or another selected notation.

The following are illustrative lists of these composition elements. These lists are not intended to be exhaustive
in their illustration.
• Example Primitives: Entity, object, signal, time, event, attribute, message, state, etc.
• Example Model Kinds: Dynamic, static, state machine, structural, behavioral, agent, object-based,
process-based, Meta data, entity relation, activity, composition, generalization, collaboration, event
trace, sequence, etc.
• Example Formalisms and Suitable Notations: Unified Modeling Language (UML), Conceptual Modeling
Language (CML), System Modeling Language (SysML), Integration Definition for Function Modeling
(IDEF0), Base Object Models (BOM), BOM++, Conceptual Graphs, Mind Maps, and Business Process
Modeling Notation (BPMN).
• Example Views: Class diagram, activity diagram, swim lanes, state diagram, operational view, etc.

RTO-TR-MSG-058 4 - 13
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

A more detailed discussion of the composition of the conceptual model, in terms of the design process, will be
given in Chapter 6.

4.5 CONCEPTUAL MODEL PERSPECTIVES AND COMPOSITION

Conceptual Model of a Simulation is predicated for the purposes of this effort as the conceptual model of the
Mission Space (i.e., that which is represented within the simulation during its execution) integrated with the
conceptual model of Simulation Space (i.e., encompassing the design and implementation of the simulation
artefact itself). Consequently, it is important to differentiate between aspects of the conceptual model space,
the Mission Space of the referent world, and the Simulation Space where the simulation itself resides. Each of
these Spaces will impact the design of the conceptual model in its own fashion.
Figure 4-6 shows the nature of these three spaces, and how they interact through the requirements and design
of the conceptual model. Following are examples of requirements which might be applied to the conceptual
model components relevant to the two spaces and the composite conceptual model itself.
• Example from conceptual model composite space: The conceptual model shall be machine-readable.
• Example from Mission Space: The conceptual model shall represent World War II trench warfare.
• Example from Simulation (Implementation) Space: The conceptual model shall be at a level of
abstraction allowing real-time execution at 1000 Hz on a commercial desktop platform.

Figure 4-6: Mission Space and Simulation Implementation Spaces Indicated as Disjoint, but Highly
Integrated ‘Worlds’ Whose Natures are to be Included in the Entire M&S Conceptual Model.

4 - 14 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

Also see Annex I – Conceptual Model Examples.

The diagrams of Figure 4-6 and Figure 4-7 illustrate the notions of the disjoint representation and simulation
implementation spaces and their composition into the fully articulated conceptual model artefact.

Figure 4-7: Simple Indication of Composition of the Simulation Conceptual Model

from Mission Space and Simulation Implementation Space Components.

Typically, the conceptual model is thought to only represent the Mission Space. Although it is often said that
the ideal conceptual model is “implementation independent”, thus “Simulation Space independent”, such is
rarely ever the case. Even if the conceptual model does not explicitly mention an implementation, and may be
highly portable from one Simulation Space to the next, the original Simulation Space to which the conceptual
model was designed will have influenced the structure and content of the conceptual model, sometimes in
significant ways. This is also true of the Conceptual Model Space influences, such as Conceptual Model
Stakeholders and Policies.

It is, in fact, the frequency of conflation of mission and simulation implementation spaces, and the occurrence
of unanticipated pejorative consequences that has motivated the Task Group to adopt this particular partition
convention. By making the partition explicit, the degree of machine independence and the artificial
implementation of mission space representations by means of undesirably static implementation techniques
are believed to be better appreciated and controlled.

4.6 BEST-PRACTICE SPECIFICATION NOTATION

One of the practical determinations and findings of the Task Group related to representational notations
whereby specifications of best-practice and resulting conceptual models could be mad manifest; and, whereby
the conceptual model itself may be captured, published, archived, retrieved, understood, modified,
and maintained in a systematic and deliberate manner without corrupting the semantic content of the model
itself. It was abundantly clear from the Team’s investigations of current practice and available standards that
myriad notational schema were available. It was further determined by the Group that the use of any of any
one notational form in expressing best-practice or the requirement for use of any such single form by
conceptual model practitioners in executing the recommended best-practice would be found to be technically
and socially impractical, however desirable and fit-for-purpose it might seem.

RTO-TR-MSG-058 4 - 15
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

Notwithstanding this determination, it was clear that the Team needed a provisional or ‘nominal’ notation for
expressing its guidance; and that the conceptual modeling practitioner would be obliged to select some one
specific documentary notational schema in executing the recommended best-practice. In the later case,
the Group resolved that practitioners should (could) elect any formulation consistent with the representational
capacity required to express their particular conceptual model and commensurate with the norms and
requirements of the enterprise environment in which they worked. Naturally, selection from among common
standard notations and specification languages is strongly recommended in any case. In the former case,
the Group was particularly sensitive to its own use of notational artifice for two reasons. On the one hand, any
notation employed herein to specify conceptual modeling process or conceptual model structure and semantic
content must be sufficiently expressive and ecumenical so that the best-practice guidance communicated
thereby might be clearly intelligible. On the other hand, the Group was anxious not to imply by its own
selection and use of notational schema, that our particular choice of schema was particularly preferred for use
by practitioners – let alone a required element of the recommended best-practice.

Therefore, the group strove to use the most simple and self-evident notation within the document, and to
reserve the best-practice guidance itself to vernacular English in Chapters 5 and 6 and in tabular prescription
in annexes tabular prescriptive guidance in Annexes G and H for process and product respectively.
The fundamental activity-on-node with control-on-arrow notation with which this guidance is modestly
introduced in Chapter 6 for process particularly together with an expression of the degree to which this
notational convention is practically a ‘least common denominator’ of several common representational forms,
is indicated in the figures following.

Figure 4-8 illustrates the simplified baseline graphical representation for indication of activities and their
relationships with other entities in the conceptual modeling practice process Used by the Task Group in
following explication.

Data Store 1 Data Store 2

Tool Tool
LEGEND :
Tool 1 Tool 2

Tool
Activity 1 Activity 2
Data Store

Actor-Agent 1 Actor-Agent 2
Product
Activity
Control
Flow
Actor-Agent Data
Flow Product 1 Product 2

Figure 4-8: Simplified Process Graphical Notation Used in

Expressing Conceptual Modeling Best-Practice Process.

Figure 4-9 indicates alternative canonical views with information-preserving transform operations are
possible, facilitating use of CASE-supported native representations and guaranteed information sharing.

4 - 16 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

DIF

Data Store 1 Data Store 2

Tool Tool
Programmatic Tool 1 Tool 2
Representation Object-Oriented (UML)
Activity 1 Activity 2 Representation
Actor-Agent 1 Actor-Agent 2

Baseline
Representation

Product 1 Product 2

DIF DIF

Process-Oriented (IDEF0)
Representation

Figure 4-9: Notional Illustration of Relationship of Simplified Process Specification

Graphical Notation in Context of Other Canonical and More Powerful Notations.

4.7 CONCEPTUAL MODEL QUALITY (VERIFICATION AND VALIDATION)

In this section some aspects that are relevant for understanding the role of V&V of a conceptual model in the
project context are described. Although the complete product life cycle is not described in this report, some
aspects of this larger setting may still be useful for a complete understanding. An enterprise that decides to
explicitly make a conceptual model clearly has the desire to deliver quality products. Just making a conceptual
model, however, is not sufficient for achieving quality. The quality of the conceptual model (and other
intermediate products) must be sufficient to allow the development of a quality end-product. V&V helps in
determining the quality of the final product and must be applied throughout the whole of the development,
and thus also to the conceptual model. V&V of the whole development can be a large undertaking. Here we
describe the V&V work with the focus on conceptual model and as if the rest of the V&V work is non-
existent. It is important, however, to understand that the result of V&V of a conceptual model is only a part of
the overall V&V effort.

RTO-TR-MSG-058 4 - 17
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

4.7.1 Context of Conceptual Model V&V Effort

The V&V work consists of a number of activities that are described in the activities in this guidance. These
V&V activities do not all need to be completely finished before a next activity can be started: they may partly
be executed in parallel. Process Activities can also be executed iteratively.

The V&V work starts with agreement on a number of elements such as: who performs the V&V work, what
resources (time, money, etc.) are available for V&V, and how the results of the V&V work are used. See also
the V&V elements in the “Meta data” product in the V&V elements in the “Information Pool” of Annex H,
Table H-5. The amount of available resources for V&V must be related to the risk (financial, loss of lives,
etc.) of using a faulty end-product because a faulty conceptual model was used for its development. If almost
no consequences exist of using a faulty conceptual model, then the V&V effort may be low. If, however, a
substantial risk is present, and using M&S results for military application usually has, the V&V effort must be
accordingly. The applied V&V methodology should be tailorable such that it delivers the best possible V&V
given the risk and available resources.

4.7.2 Quality Attributes Relevant to Conceptual Model V&V

Three properties must be shown during the V&V work: utility, validity and correctness:
• Utility
• Assesses the effectiveness and efficiency of the conceptual model in solving the problem statement.
Evaluation metrics for utility comprises three areas: value or benefits (measures of effectiveness,
measures of performance, etc.), costs (money, time, etc.) and use risks (impact, probability, etc.).
• Validity
• Assesses the level of agreement of the conceptual model behavioral representation with that of the
simuland. Validity metrics are also used to assess the consequences any behavioral discrepancies
on the utility of the M&S system.
• Correctness
• Assesses whether the conceptual model implementation is free of error and of sufficient precision.
Correctness metrics are also used to assess the consequences of implementation discrepancies on
both the validity and utility of the conceptual model.

4.7.3 Sufficiency Criteria for Conceptual Model V&V

In order for the conceptual model to have utility it must help improve the quality of the end-product within
with resources that are in balance with the risk. Building the conceptual model is the step in simulation
development in which the actual Modeling takes place. Therefore validation (determining whether the
abstractions taken during the Modeling are allowed) of the conceptual model against the stakeholders’ purpose
is important for the simulation’s fitness for purpose. In order to serve its purpose the constructed conceptual
model must also be correctly implemented such that its representation is useful and leads to a correct
transformation of purpose, via requirements to design and implementation.

A conceptual model that has been V&V-ed with positive results increases the chances of a high quality end-
product and can serve as part of a referent for the V&V of that final product. For conceptual models no formal
acceptance process (accreditation) is available, it must however be acceptable for the stakeholders (users,
developers, etc.) that use the conceptual model in the development process. This must be achieved in two

4 - 18 RTO-TR-MSG-058
 INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

ways. First, the acceptance criteria must be derived from the stakeholders’ purpose, and, second, the format in
which the results of the V&V effort are delivered must be suited for their purpose.

4.7.4 V&V Compliance Framework

It is important that the V&V effort results in a compliance network linking stakeholders’ goals via a set of
evidences to justifiable claims.

Figure 4-10: The V&V Argumentation Framework (AF) Consists

of the Goal Network, Evidence and the Claim Network.

The goal network is used in a top down fashion for reasoning about the decomposition of a top-level objective
into smaller goals and, finally, into a set of definitions of tests to generate evidence. Therefore goal networks
can be used for planning purposes. V&V goal networks are closely related to and overlap with goal-oriented
requirements engineering.

Claim network structures work in the opposite way. A claim network structure aggregates evidence collected
in a certain context into sub-claims, and these sub-claims into a single justified top-level claim on the subject
of interested. This aggregation is done by means of logical arguments.

The rationale for using both a goal network and a claim network stems from the fact that in practice
decomposition and re-composition do not mirror each other for various practical reasons like time, cost and
availability of equipment to gather the appropriate evidence.

After completion of the claim network, and thus also the goal network and evidence collection, the results
must be communicated to the stakeholders. The results are an acceptance recommendation in the format best
suited for the stakeholders’ purpose with the V&V results. Since there is no formal acceptance process for
conceptual models, the result is not an accredited conceptual model but a recommendation on acceptance.

If all is well the top claim shows that the top goal is justified. For all M&S related products, and indeed
possibly all products, the top goal is of the same form: the system must provide utility for the given purpose.
Therefore the top goal of the Goal Network is a utility goal. In case of conceptual models the following top
goal is proposed:
The Conceptual Model provides utility for the improvement of the quality of the end-product.

This top goal must be decomposed into smaller goals. At first these are likely to be more specific utility goals.
At some point the utility goals can be expressed either into criteria for which tests can be devised or into
smaller goals that deal with validity and correctness. The validity goals express criteria on the abstractions
from reality that are made in the conceptual model since the phase in which the conceptual model is build is

RTO-TR-MSG-058 4 - 19
INTRODUCTION TO CONCEPTUAL
MODELING: BEST-PRACTICE GUIDANCE

the modeling phase. Only those abstractions are allowed that will result in a model that – given its purpose
and the way it is used in the final product – result in a behaviour that is indistinguishable from the equivalent
behaviour in the real world. The correctness goals state criteria on how the conceptual model is build,
expressed in formalism and used in the rest of the development process. The conceptual model must for
example be understandable for all relevant stakeholders and be specified without errors in formalisms that are
appropriate.

Some of these criteria will be independent of the specific topic and formalisms, but many criteria,
and especially those in the validity goals, will be highly dependent on the stakeholder’s purpose with the final
product. Inspiration for criteria can be found in standards on software quality, namely [ISO/IEC 9126], papers
on conceptual model quality such as [Lindland] [Pace] [Teeuw], SMEs and domain specific knowledge that
may be available from previous quality evaluation efforts. A good overview of quality frameworks specific
for conceptual models is given by [Moody].

4.8 REFERENCES
[1] Gordon, S., Waite, W., Öhlund, G. and Björk, Å., Review and Update of Findings from Economics of
Simulation Study Groups, Paper 21, NATO Modeling and Simulation Group Symposium, Warsaw,
Poland, October 2005 (Paper presented at the RTO NMSG Symposium on “The Effectiveness of
Modeling and Simulation – From Anecdotal to Substantive Evidence”, held in Warsaw, Poland, 13-14
October 2005).

[2] The Cost Effectiveness of Modeling and Simulation (M&S) MSG-031 Final Report – Draft. NATO
MSWG, 2008.

[3] Department of National Defence, Canada, The Joint Simulation and Modeling for Analysis,
Requirements, Training, and Support (SMARTS) Initiative: A Vision for enabling Strategy 2020.

[4] Waite, W.F., Proposal for Establishment of a Technical CHAPTER within the Society for Computer
Simulation (SCS) on “The Economics of Modeling and Simulation”, 2000.

[5] Waite, W.F., Terms of Reference (TOR) Revised for the SISO Task Group on The Economics of
Simulation, 2001.

[6] Waite, W.F., Tutorial: Economics of M&S: Change-Agents or Martyrs for Innovation. I/ITSEC 05,
Sponsored by NTSA, 2005.

[7] Erlandson, M. and Gordon, S., Economics of Simulation Data Compilation Work Group, 1995.

[8] Gordon, D.S., Review and Update of Findings From Economics of Simulation Study Groups, Waite, B.,
Editor, NMSG-035/RSY-005, 2005.

[9] Nesselrode, M.C., Developing a Repeatable and Reliable Methodology to Determine Return-on-Investment,
Old Dominion University, 2008.

[10] Ostwalt, Ivar, et al., Calculating Return on Investment for U.S. Department of Defense Modeling and
Simulation, in Defense Acquisition Research Journal, Vol. 18, No. 2, April 2011.

[11] Iansiti, M. and Levin, R., Strategy as Ecology, in Harvard Business Review, March 2004.

4 - 20 RTO-TR-MSG-058
 Chapter 5 – CONCEPTUAL MODELING PROCESS GUIDANCE

Establishment and implementation of best-practices are critical to ensure that a sound and structured process is
followed to produce conceptual models of sufficient quality, and to ensure that conceptual model products are
robust and complete. It is particularly important to establish a homogeneous and common process for conceptual
model development to enable a structured approach and to build a common vocabulary across the M&S
community for the sake of collaboration and reuse.

Based on the research effort described above, and in order to meet the stated objectives of advancing the
development of conceptual models beyond current practice, Chapters 5 and 6 (along with corresponding
annexes) constitutes NATO Best-Practice Guidance, provided to enable the development of quality and
re-useable conceptual models of military models and simulations.

5.1 PROCESS GUIDANCE INTRODUCTION

This chapter provides the MSG-058 Task Group’s “Best-Practice Guidance Specification (BPGS)” for the
“Conceptual Model Best-Practice Development Process” as indicated in Figure 3-4. This guidance includes
descriptions of the Process Phases, Activities, and Activity-Flows required to ensure a quality conceptual model,
and quality ancillary products. The products themselves will be described further in Chapter 6.

The desired process guideline is based on these desirable characteristics, which best-practices conceptual
modeling process should contain, exhibit, or facilitate:

COMPLIANCE:
• Comply with policies.
• Conform to enterprise precepts and practices.
• Include identification of stakeholders’ roles and responsibilities.
• Leverage available standards.
• Leverage systems engineering and information management best-practices.

SUFFICIENCY:
• Provide necessary activities to the conceptual model lifecycle.
• Contemplate multiple formalisms and views.
• Distinguish between Mission Space and Simulation (implementation) Space requirements and needs.
• Exhibit sufficient completeness for subsequent intended use.

‘-ITILITIES’ – this represents words that end in itilities, such as utilities, capabilities, etc.:
• Give developers flexibility to apply and tailor the process.
• Provide utility and efficiency.
• Allow sufficient expressiveness and flexibility.
• Foster reusability.
• Foster understanding.

RTO-TR-MSG-058 5-1
CONCEPTUAL MODELING PROCESS GUIDANCE

QUALITY:
• Exhibit sufficient correctness for intended use.
• Produce quality documentation.
• Enable VV&A.

A five-phase development process is provided commensurate with these required characteristics. That process
is shown in Figure 5-1, and its process elements are designated as follows:
• PP1 – Initiate Conceptual Model Development.
• PP2 – Define Conceptual Model Requirements and Knowledge Needs.
• PP3 – Acquire Conceptual Model Knowledge.
• PP4 – Design the Conceptual Model.
• PP5 – Build the Conceptual Model.

Figure 5-1: Conceptual Model Development Phases.

Each development phase is composed of a corresponding set of Process Activities. The complete collection of
activities for the entire process is shown in Figure 5-2. Further guidance on the specific phases and activities is
provided in the sections below, and technical descriptions of each Process Activity are provided in the text
that follows and, systematically in Annex G.

5-2 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

Figure 5-2: Conceptual Model Development Process Exhibiting

Devolution of Process Phases to Process Activities.

It is important to note that these Process Phases and Activities need not be executed in the serial order implied
by their enumerated listing; although, the ordinality of Process Activities associated with each Process Phase
is considered to be logically suggestive. Pragmatically, many of the activities may be executed concurrently,
in multiple iterations or out of numerical sequence, contingent such exigencies a team structure and availability
of expertise, availability of information, election of spiral or other recursive implementation techniques,
or, in fact, any of the circumstances that are the inevitable consequence of enterprise operational style or
business practice. The only limitations to task activity sequencing is the necessity to satisfy entry conditions
and exit conditions for each activity, as defined in the respective sections of Annex G.

Figure 5-3 illustrates such one such non-linear execution of the global process through the use of a state-
transition diagram. In the example in the figure, S1…S13 indicate each state, and it can be seen that the
sequence includes execution of multiple phases in parallel, and iterative passes through the process. These
states may also involve execution of individual phased Process Activities in different or parallel order.

RTO-TR-MSG-058 5-3
CONCEPTUAL MODELING PROCESS GUIDANCE

class Business Workflow Instance

PP1 PP2 PP3 PP4 PP5

Start

S3
S5

S1 S2
S4

S8

S6 S7

S13

S10
S9 S12
S11

Stop

Figure 5-3: Example Conceptual Model Development Workflow.

It is significant to note that the process specification is organized and presented in order to provide the greatest
possible discretion to the conceptual modeling execution agent, while encouraging elements that have been
determined to comprise best-practice. In that spirit:
• These defined Process Phases and Activities are provided as best-practices in conceptual model
development.
• This process may be tailored as needed by the developer.
• The Process Activities may be executed in any sequence allowed by the entry and exit criteria.

5.2 CONCEPTUAL MODEL PROCESS DESCRIPTION

In the sections that follow, discussion of conceptual modeling Process Phases and their component Process
Activities are provided. The intention of the text is to provide a plausible explanation and rationale of the
entire effort expected to be necessary and sufficient for the creation and management of military simulation
conceptual models. Information is provided that is deemed:
• Useful to the practitioner in understanding motivation for particular process components;
• Constructively prescriptive in conducting conceptual modeling;
• Effective in elaborating on special circumstances likely to apply to such execution;

5-4 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

• Liberating to the practitioner in specializing the subject guidance contingent particular circumstances
following from enterprise and task peculiarities; and
• Prescriptive of intentions for resulting work-products.

This account is provided as a complimentary and consistent form of guidance which, when taken together
with the systematically tabular guidance specification contained in Annex G, is considered necessary and
sufficient to inform best-practices.

5.2.1 Process Phase 1 Guidance – Initiate Conceptual Model Development

The conceptual model development activity in this phase is to identify, collect, and document initial needs,
constraints, and policies that are most often described in terms of the underlying simulation, and to identify
stakeholders and map them to their roles and responsibilities. This phase is critical to the translation of
simulation needs, mandates, and constraints into those for the conceptual model itself.

Since it is highly unusual for conceptual models to be developed for their own sakes, rather than in the context
of one or more M&S initiatives, the initiation process is often seen as external to the conceptual model
process. Yet most senior stakeholders in the enterprise make their greatest conceptual model development
contributions at this time. Historically these contributions rarely have been documented within the conceptual
model itself, which has often resulted in limited conceptual model reusability or sub-optimum representation
due to assumed constraints and mandates that dictate the form and content of the conceptual model.

For example:

A Joint Forces Commander recognizes the need to provide transportable helicopter simulators in the
field to reduce the number of flight hours required for mission training. He develops an M&S need
statement to address the problem, and an Acquisition Executive decides to fund the development of the
simulators to meet the need. Due to the urgency of the problem, the Acquisition Executive allocates
twenty million dollars to do the development in the nine remaining months of the current year,
and tasks an Army Program Office to execute the mission. The Army Program Manager knows that to
execute within time and budget, he will not be able to develop a validated flight model, and will have
to use a surrogate, which will limit the value of the training in the near-term. He decides to direct the
development of a composable architecture so that he can drop in a validated flight model at a later
date. He also is constrained to develop the simulators using existing tools and using mandated software
development practices. He articulates this to his Group, who are now prepared to develop the
conceptual model for the simulation effort.

In this example, conceptual model development began long before the development Group received their
direction, in terms of the constraints, policies, and mandates limiting the simulation development effort.
As mentioned above, an ideal conceptual model is said to be implementation independent. And a conceptual
model can certainly be developed to support the example above, without specifying application constraints.
But even if the conceptual model does not explicitly reference these constraints, those constraints will still
bind and shape it, and as will be shown in the next process steps, the conceptual model requirements
definition and knowledge acquisition will be highly impacted by the decisions made by the senior
stakeholders.

Therefore, in order to translate and document the impacts of the M&S development effort to the conceptual
model, the following Process Activities must take place:

RTO-TR-MSG-058 5-5
CONCEPTUAL MODELING PROCESS GUIDANCE

• PA1.1 – Identify and Map Stakeholder Responsibilities.

• PA1.2 – Define Purpose and Intended Use of M&S effort.
• PA1.3 – Identify Constraints on the M&S effort.
• PA1.4 – Impose Mandatory Enterprise Policies.

The relationships among these Process Activities and with their products are shown in Figure 5-4.

act PP1 Activ ity Diagram: Initiate CM Dev elopment

Start PP1

PA1.2 Define Purpose and P1.2 Need

Intended Use of M&S Effort Statement

PA1.1 Identify and Map

Stakeholder P1.1 Stakeholder
Responsibilities Description

PA1.3 Identify Constraints

on the M&S Effort

PA1.4 Impose Mandatory P1.3 Constraints

Enterprise Policies and Policies

End PP1

Figure 5-4: Process Phase 1 (PP1) Activity Diagram.

5-6 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

Each Process Activity is described below, and is further specified in Annex G.

5.2.1.1 PA1.1 – Identify and Map Stakeholder Responsibilities

A conceptual model primarily exists for the benefit of its stakeholders. Stakeholders must be identified to
support the conceptual model development process: to support requirements development and knowledge
acquisition, and to impact the design and build of the conceptual model. Stakeholders and their roles must be
known before views can be determined. Stakeholder perspectives will drive terminology and will impact the
selection of models and relationships.

This Process Activity involves three kinds of things: Lists of actual points of contact, by name or office;
identification of relevant stakeholder roles as described in Section 4.3; and a mapping of the points of contact
to the roles.

Points of contact may be generated from lists, employee roles, organizational charts, personnel databases,
referrals, resumes, biographies, contract labor categories, or any other programmatic or administrative means.

Roles must be defined by analysis of the PA1.2 defined purpose and intended use of the M&S effort to the
stakeholder classes described above, tailored to the particular application.

Mapping of the two will most likely involve M to N mapping, given that many individuals or offices can often
have multiple roles in a particular conceptual model development, and many roles include multiple people for
any realistically sized effort.

In the example above, the points of contact “Joint Forces Commander” and “Acquisition Executive” might
map to “Sponsor”, and “Army Program Manager” would likely map to the stakeholder role of “Producer”.

This activity produces the P1.1 – Stakeholder Descriptions, which are used to derive conceptual model
requirements and conceptual model knowledge needs.

5.2.1.2 PA1.2 – Define Purpose and Intended Use of M&S Effort

This Process Activity may begin upon stated or implied intent to develop a model, simulation, or conceptual
model. This intent may come in the form of task orders, mission needs statements, user requirement
documents, requests for proposal, statements of work, formal or informal directives, test agreements, oral or
written orders, or any combination of like manners of communication.

The purpose of this activity is to compile all these M&S source documents and implied intents into a single
set, to deconflict the elements of the set, and to provide this reconciled, definitive description of intent to the
conceptual model developers, written in terms of descriptions of needs for the conceptual model.

It may be possible that multiple references to intent cannot be reconciled, as in the example above, where the
Joint Forces Commander wants to train pilots but the Army Program Manager is not providing a validated
flight model. In that case, even these potentially conflicting or mutually exclusive intents must be documented
and highlighted, as they will likely drive complexity into the conceptual model, as the Army Program
Manager’s decision to develop a composable architecture surely would have done.

This activity produces the P1.2 – Intended Use Statement, which is used to derive conceptual model
requirements and conceptual model knowledge needs.

RTO-TR-MSG-058 5-7
CONCEPTUAL MODELING PROCESS GUIDANCE

5.2.1.3 PA1.3 – Identify Constraints on the M&S Effort

As in the example, time and resources can constrain the conceptual model design, as can the intended use
itself. These M&S constraints in turn constrain the conceptual model development, and impact the reusability
and implementation independence.

And as in PA1.2, information pools such as documented resource constraints, senior stakeholder preferences
and requirements, planning/budgeting management limitations, legacy M&S preferences and availability, data
availability, enterprise preferences, and such, must be collected, integrated, and de-conflicted into a self-
consistent set of descriptions of M&S constraints.

This activity, combined with PA1.4, is necessary to produce P1.3 – Constraints and Policies, which is used to
derive conceptual model requirements and conceptual model knowledge needs.

5.2.1.4 PA1.4 – Impose Mandatory Enterprise Policies

In this Process Activity, developers collect information from enterprise standard operating procedures,
industry and government standards, enterprise executive mandates, law, agency regulations, agency directives,
written policy, implied enterprise mandates, and other references relating to Enterprise Policy Mandates.
This data must be collected, integrated, and de-conflicted into a self-consistent set of descriptions of policies.

Examples of enterprise mandates include the US Department of Defense mandate to use High Level
Architecture (HLA), some industries standardizing on UML, or even a small business’s decision to use a
proprietary software tool for competitive advantage. This activity is where the enterprise has tailored the
intended use and constraints to its own interests, and that tailoring gets reflected in the initial state of the
conceptual model.

This activity, combined with PA1.3, is necessary to produce P1.3 – Constraints and Policies, which is used to
derive conceptual model requirements and conceptual model knowledge needs.

Listed below are the points of emphasis:

• The INITIATE phase of conceptual model development is a critical and often overlooked set of
activities that must be understood and documented.
• These activities are necessary to document stakeholder roles, conceptual model requirements,
policies, and mandates.
• This phase sets the initial state of the conceptual model.
• In mature enterprises, much of this initial state is quite repeatable from one conceptual model activity
to the next, and might generate documents that are highly reusable in subsequent efforts.

5.2.2 Process Phase 2 Guidance – Define Conceptual Model Requirements and Knowledge
Needs
Overview of Process Activities and Products – The second Process Phase in the conceptual model development
process consists of four Process Activities in a simple sequence as shown in Figure 5-5. This Process Phase takes
two input products (P1.2 – Need Statement and P1.3 – Constraints and Policies) and produces two output
products (P2.1 – Conceptual Model Requirement Specification and P2.2 – Conceptual Model Knowledge

5-8 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

Acquisition Needs). A preliminary product is used to record requirements during the Process Phase execution
before they have been synergized and verified.

act PP2 Activ ity Diagram: Define CM Requirements and Know ledge Needs

Start PP2

PA2.1 Identify, analyse Preliminary

P1.2 Need and record CM, Mission
Requirement
Statement and Simulation Space
Specification
Requirements

PA2.2 Verify requirements

P1.3 Constraints w rt needs, constraints and
and Policies policies

PA2.3 Synergize CM,

Mission and Simulation
Space Requirements

PA2.4 Deriv e Mission and

Simulation Space
Know ledge Needs

End PP2
P2.2 CM P2.1 CM
Know ledge Requirement
Acquisition Needs Specification

Figure 5-5: Process Phase 2: Define Conceptual Model Requirements and Knowledge Needs.

5.2.2.1 PA2.1 – Identify, Analyze and Record Conceptual Model, Mission and Simulation
Space Requirements
Process Activity 2.1 refers to requirements grouped into three “Spaces”: Conceptual Model Space, Mission
Space and Simulation Space. The concepts of these “Spaces” are explained in Chapter 4, Section 4.1 Scope and
Definitions and an example are presented in Annex I.

This Process Activity refines the need statement by detailing the implications of the needs in a more explicit
set of requirements. It can be described as a kind of translation process from qualitative and informal
statements in the “language” of the client (needs) to more quantified and precise statements of content and
attributes of the required conceptual model (requirements).

RTO-TR-MSG-058 5-9
CONCEPTUAL MODELING PROCESS GUIDANCE

Analyzing the requirements is a process of reviewing and evaluating the requirements to ensure that they are
complete, consistent and correct.

Typical requirements originating from the conceptual model space may include:
• The views needed of the conceptual model by different stakeholders.
• The level of formality needed by stakeholders.
• Mandatory tools, documentation formats, notations, etc.
• Mandated conceptual model characteristics.
• What policy to follow to validate the conceptual model.
• What acceptance criteria to apply in validation.

In order to prepare the acceptance of the results of the V&V effort by the stakeholders used in PA5.5 (Ensure
Acceptance of Conceptual Model by Authorized Stakeholder), it must be determined what information the
stakeholders require for their acceptance decision-making process.

Typical requirements originating from the mission space may include:

• Definition of what parts of the mission space to be included in the conceptual model (Scope).
• Questions to be answered by the modeling and simulation effort (Critical Operational Issues (COIs)).
• Level of realism and detail needed in order to address the COIs (Abstractness characteristics).
• How the degree of satisfaction of operational issues are to be measured (Measures of effectiveness).

Typical requirements originating from the simulation space may include:

• Intended use of the model (e.g., training, feasibility study, trade-off studies, performance analysis).
• Implementation strategy and choice of fundamental technology.
• Explicit performance constraints (e.g., real-time requirements, Monte Carlo simulation requirements).
• Requirement to interface with existing software, hardware equipment or human operators.

5.2.2.2 PA2.2 – Verify Requirements with Respect to Needs, Constraints and Policies
Process Activity 2.2 shall ensure that the requirement specification satisfies important quality criteria.
As `described in Section 4.7 V&V, an AF is built during the V&V work. For the first part of the AF a goal-
oriented approach is taken. Starting with the top goal, criteria are derived in a hierarchical fashion. A part of
those criteria deal with the requirements of the conceptual model space, the mission space and the simulation
space. The requirements are to be verified against the criteria in that part of the AF.

Typical quality criteria are:

• Completeness: All needs, constraints and policies are covered by one or more requirements.
• Traceability: Every requirement statement can be referred to a corresponding need, constraint or
policy statement.
• Correctness: All needs, constraints and policies have been interpreted as the sponsor intended.
• Un-ambiguity: The requirement is given a form that avoids misinterpretation.

5 - 10 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

Other possible criteria are consistency, adequacy, measurability, pertinence, feasibility, comprehensibility and
good structuring.

Completeness ensures that all requirements implicit in the need statement and applicable constraints and
policies are accounted for. Traceability ensures that no requirement that is not implied by these inputs has
found its way into the requirement specification product. That is, there should be no element of invention at
this stage. The requirement specification shall simply be an accurate reflection of preceding products.

The process of verifying the requirements may however reveal inconsistencies, inaccuracies or omissions in
the input products. It is therefore a good opportunity to clarify and adjust Phase 1 products before weaknesses
are propagated to downstream Process Phases.

5.2.2.3 PA2.3 – Synergize Conceptual Model, Mission and Simulation Space Requirements
Conceptual model space, mission space and simulation space requirements may in some cases be incompatible.
There may therefore be a need for harmonizing any conflicting requirements. This is taken care of in Process
Activity 2.3.

5.2.2.4 PA2.4 – Derive Mission and Simulation Space Knowledge Needs

Process Activity 2.4 shall produce a description of the knowledge needed by the developers of the conceptual
model. These needs must be based on the conceptual model requirement specification and should identify
relevant knowledge:
• Used by military personnel in the execution of their profession (tactics, techniques and procedures).
• About the scientific basis for military technology.
• About construction and performance of military technology.
• About simulation methods and technologies.

Note that only the knowledge needs are described at this stage, not the knowledge itself (which is the task of
Process Phase 3). It is important to be careful in limiting the knowledge needs to what is strictly necessary for
the conceptual model to be constructed. It is easy to be carried away by the wealth of information available
and making the knowledge acquisition task more onerous than necessary.

Some aspects that should be considered when deriving knowledge needs are:
• The entities and behaviours that must be described by the model.
• The granularity or level of detailed needed in describing the phenomena to be modelled.
• Which simplifying assumptions can be allowed and what causal relationships must be included in the
model.

When assessing these aspects the knowledge needed must finally be dictated by what questions the model is
supposed to answer, that is the purpose of the model.

For example:
A simulation model shall be used to evaluate the effectiveness of flare countermeasures against infrared
homing anti-ship missiles. In such a setting we may need the following type of knowledge:

RTO-TR-MSG-058 5 - 11
CONCEPTUAL MODELING PROCESS GUIDANCE

• Missile flight trajectory, agility and speed.

• Missile seeker sensitivity, field of view and tracking ability.
• Missile seeker countermeasure discrimination ability.
• Countermeasure blooming profile, intensity and duration.
• Countermeasure alternative tactics for deployment.
• Ship IR signature.
• Ship maneuverability.
• Ship alternative maneuvering tactics.
• Environmental conditions influencing background IR radiation.
• Environmental conditions influencing IR radiation propagation.
• Environmental conditions influencing flare movement.

Listed below are the points of emphasis:

• Bring any hidden assumptions into the open by spelling them out explicitly in the form of requirements
and so reduce room for alternative interpretations.
• The knowledge acquisition needs should be limited to what is strictly needed.
• Leverage earlier requirements and knowledge specifications.

5.2.3 Process Phase 3 Guidance – Acquire Conceptual Model Knowledge

The Phase 3 in the NATO conceptual modeling process, called “Acquire Conceptual Model Knowledge”, will
begin by taking the two products generated in Phase 2, which are P2.1 – Conceptual Model Requirement
Specification and P2.2 – Conceptual Model Knowledge Acquisition Needs, as input. These inputs will be used
to identify the authoritative knowledge sources for a particular piece of knowledge. Thus Phase 3 is where the
knowledge required for description of a certain mission space will be acquired. This phase will, after
gathering, structuring and documenting and review the validity of that acquired knowledge with respect to the
authoritative knowledge sources, produce a product called P3.1 – Validated Knowledge. This product will
serve as the foundation for designing and building the final conceptual model.

Given that a conceptual model repository already exists, this phase will begin by looking for reusable
knowledge that may already be in the conceptual model repository and can be completely or partially usable
for this new need. If not, the lack of knowledge is identified, along with the gaps that must be filled.
But before that knowledge can be acquired the authoritative knowledge sources should be identified. After
that, the required knowledge will be gathered, structured, and documented, and finally analyzed for necessity
and sufficiency. After that, enough knowledge should exist to either generate a Domain Ontology for this
particular mission space or to extend the existing Domain Ontology. The last activity in this phase will be to
review the validity of the acquired knowledge with respect to the authoritative knowledge sources.

The third phase in the conceptual model development process consists of six Process Activities as shown in
Figure 5-6.

5 - 12 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

act PP3 Activ ity Diagram: Acquire CM Know ledge

Start PP3

P2.2 CM Know ledge PA3.1 Identify List of Authoritativ e

Acquisition Needs Authoritativ e Know ledge Know ledge Sources
Sources

PA3.2 Search for

Re-usable Know ledge

Know ledge
Components

PA3.3 Identify Know ledge

Gaps and Bounds

Structured Know ledge PA3.4 Gather, Structure Yes

Corpus and Document Still significant knowledge gaps?
Know ledge
No

PA3.5 Generate/Extend a
Domain Ontology
Domain Ontology

PA3.6 Rev iew Validity of

Know ledge w rt
Authoritativ e Know ledge
Sources

P3.1 Validated
End PP3
Know ledge

Figure 5-6: Process Phase 3 Activity Diagram: Acquire Conceptual Model Knowledge.

5.2.3.1 PA3.1 – Identify Authoritative Knowledge Sources

This activity is about identifying authoritative knowledge sources to fetch correct and authoritative
information that describes a certain domain. Knowledge Acquisition (KA) belongs to the initial phases of
almost any kind of system development process. There is no specific methodology for identifying appropriate
sources for KA but the important issue here is to rely only on authoritative knowledge sources, those
authorised by some organisation/authority beforehand (who this person or agency should be is beyond the
scope of this report). These sources can be anything from books, web information, papers, regulations
documents, pictures, maps, and case studies, but perhaps most important of all interviews with SMEs. Having
a deeper understanding of the problem domain and (preferably) having experience of the particular area are
necessary qualities for success.

RTO-TR-MSG-058 5 - 13
CONCEPTUAL MODELING PROCESS GUIDANCE

5.2.3.2 PA3.2 – Search for the Reusable Knowledge in the Conceptual Model Repository
A successful result of this activity requires that good work is done in previous phases to identify the purpose,
need, and requirements that are posed on the acquired information. This list of needs and requirements will be
the foundation for building the necessary queries to the conceptual model repository. Keep in mind that
several qualitative properties are critically important to search and find either the reusable knowledge
component (part of a conceptual model) or a complete conceptual model fulfilling a specific need. One is to
try to model knowledge in smaller components that makes reusability easier. The other property is to have a
degree of formalisation and semantic description that makes it possible to compose smaller components for
building the needed conceptual model. The third is to have good Meta data addressing artefacts in the
Conceptual Model Repository; this makes it possible to easily find the knowledge which corresponds to the
need.

5.2.3.3 PA3.3 – Identify Knowledge Gaps and Bounds

This activity concerns whether the knowledge retrieved from an existing conceptual model repository is in
accordance with the requirements; here the reusability of already gathered conceptual models or components
will be examined to see if they can be used for the new purpose. The outcome aids in identifying what is
missing. This activity will be considered only if the result of the previous activity (search for the reusable
knowledge in the conceptual model repository) has been that the knowledge components have been found that
only partly fulfils the need. These are then compared with the requirements to make certain that either the set
of requirements are fulfilled or alternately, if knowledge corresponding to a specific requirement is missing,
further knowledge acquisition will be taken care of in the next activity.

5.2.3.4 PA3.4 – Gather, Structure and Document Knowledge

Information sources for military activities can be anything from instructions, books, military doctrines, military
scenarios, and case studies to military experts, Subject-Matter Experts, etc. However, the information that is
needed for a certain purpose is often not documented anywhere and is only available through SMEs. Since there
is no easy way to access this knowledge and it is often expensive to gather, recount, and store. This activity is
about gathering, structuring and documenting this important knowledge. Certain military knowledge is often not
documented anywhere and is only available through SMEs. The art of gathering this information from SMEs is
usually called Knowledge Elicitation (KE) and is considered to be one of the greatest challenges of KA. Another
challenge is to capture and obtain tacit knowledge – things that the expert does routinely, without much thought
and considered obvious by the expert. The more knowledge an expert possesses, more is often considered
obvious and it is usually more difficult for him to recount what they know.

5.2.3.5 PA3.5 – Generate/Extend a Domain Ontology

The previous activity has captured and documented new knowledge about a certain military activity that did
not already exist in the conceptual model repository. It means new knowledge most likely will introduce new
military concepts, properties, relations, and constraints which should be stored in some kind of knowledge
base for future use and reuse. This activity covers structuring, tagging, and storing the gathered information
either as new domain ontology or as an extension to an existing one.

5.2.3.6 PA3.6 – Review Validity of Knowledge with Respect to the Authoritative Knowledge Sources
This activity is about evaluation of the validity of acquired knowledge with respect to authoritative knowledge
sources. This occurs by examining whether the result of the knowledge acquisition phase is acceptable to the
owner of the mission space (the SME). It is about checking with the experts, whose realities have been

5 - 14 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

captured and documented, to see if the documented knowledge is correct and completely represents the
activity. This is preferably performed by a VV&A agent.

A challenge of knowledge acquisition is that it often begins with the gathering of information from
descriptions about a certain domain, through books, papers, tutorials, etc. All stored information is static while
reality is dynamic and in constant change, which, if nothing is done, results in information that has been
correctly gathered, but over time, becomes out-dated. Another challenge may appear when several experts
have to be involved, where each expert might use different terminology or emphasize different things.
A method for solving this can be to have one expert write something and then use a system of peer-review to
iteratively refine the data. However a good methodology for keeping the generated conceptual models updated
over time is required.

5.2.4 Process Phase 4 Guidance – Design Conceptual Model

The objective of this phase is to translate the conceptual model requirements into a conceptual model design
preparing to build the actual conceptual model.

The conceptual model design explicitly trades off and balances conflicting requirements, such as the
stakeholders understanding and involvement in the simulation development process and enterprise mandated
policies.

It may seem artificial to explicitly separate the design and the building. However, a conscious conceptual
model design makes the producers aware of their own bias relative to the stakeholders’ bias.

The conceptual model design is basically a top-down selection of conceptual primitives, model kinds, views,
formalisms and notations. The selection can be influenced by the bottom-up choice of reusing existing
conceptual model artefacts. The design must be submitted to an evaluation against the conceptual model
requirements for typical quality criteria like completeness and fitness for purpose.

The conceptual model design is divided in six activities:

• PA4.1 – Search for Existing Conceptual Models that May be Partially or Fully Re-Used to Support
the Current Conceptual Model Development.
• PA4.2 – Identify and Select Conceptual Primitives and Model Kinds to Represent Acquired Knowledge.
• PA4.3 – Select Formalism(s) for Conceptual Model Specification.
• PA4.4 – Select Views to Support Stakeholders.
• PA4.5 – Select a Notation Suitable to Express the Chosen Formalism.
• PA4.6 – Evaluate Design for Adequacy/Relevance with Respect to Requirements.

As shown in Figure 5-7, conceptual primitives, model kinds, formalisms, views and notations are implicitly
entangled, but they are artificially separated to make the producers aware of the interrelation of design choices
and their consequences on meeting the stakeholders’ expectations and the conceptual model characteristics
requirements. This separation is necessary to be intentionally selective on the conceptual model design
options. It is an investment against the risk of uninformed use of conceptual model components.

RTO-TR-MSG-058 5 - 15
CONCEPTUAL MODELING PROCESS GUIDANCE

Figure 5-7: Conceptual Model Components.

The activity diagram in Figure 5-8 shows how the activities are interrelated.

5 - 16 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

act PP4 Activ ity Diagram: Design CM

Start PP4

Preliminary CM
PA4.1 Search for existing Design
P2.1 CM
CMs that may be partially or
Requirement
fully re-used to support the
Specification current CM dev elopment

Formalism Mandated?

PA4.4 Select View s to

support Stakeholders

PA4.2 Identify and Select

Conceptual Primitiv es and
Model Kinds to Represent
Acquired Know ledge

PA4.3 Select Formalism(s)

for CM Specification

No Done?

Yes

PA4.5 Select a Notation

suitable to express the
chosen Formalism

PA4.6 Ev aluate the Design

for Adeqacy/Relev ance w rt
Requirements

No Adequate?

P4.1 Conceptual
End PP4
Model Design

Figure 5-8: Process Phase 4 (PP4) Activity Diagram.

RTO-TR-MSG-058 5 - 17
CONCEPTUAL MODELING PROCESS GUIDANCE

There is no mandatory order in PA4.1 to PA4.5. They all input to the preliminary design for evaluation in
PA4.6 and for acceptance by the stakeholders as the Product 4.1 – Conceptual Model Design. Several preliminary
design and evaluation cycles are usually required to finally pass the evaluation. Experience will allow passing
the evaluation with fewer cycles.

Annex I presents several examples of different conceptual model designs. The example in Annex I, Section I.5
specifically emphasizes on the iterative conceptual model design process.

5.2.4.1 PA4.1 – Search for Existing Conceptual Models that May be Partially or Fully Re-Used
to Support the Current Conceptual Modeling Development
In this Process Activity, the producer of the conceptual model is searching for existing partial conceptual
models with the intention of reusing it for the conceptual model design. Typical search criteria are driven by
mandated enterprise policies, the obligation for stakeholder’s involvement and relevant common practice.
Even if the producer cannot find an appropriate conceptual model design that suits all of these criteria,
a conceptual model design that has been used successfully might be a good starting point. Future iterations are
likely to refine search criteria and hint of other existing designs.

Motivations for reusing conceptual model designs are to avoid discussions that have been settled in the past
and endorse common practice within a relevant community.

5.2.4.2 PA4.2 – Identify and Select Conceptual Primitives and Model Kinds to Represent Acquired
Knowledge
In this Process Activity, the producers select suitable conceptual primitives that will capture the knowledge
elements and the model kinds that will organize the conceptual primitives.

The producers do not need to know the exact knowledge content to be modelled, but need to have a rough idea
of the domain area and the type of knowledge. For example, decision support knowledge may require action-
related conceptual primitives while system knowledge may require function-related ones.

The producers need to analyze the conceptual model characteristic requirements from P2.1 – Conceptual
Model Requirement Specification to derive the implications on conceptual primitives and model kinds.

The producers need to know about the conceptual primitive and model kind options either from the literature
or from experience. There is a critical need to further develop the body of knowledge necessary to categorize
the conceptual primitives and model kinds in terms their implications on conceptual model characteristics on
the other conceptual model components. For example, it would be useful to understand how characteristics
such as expressiveness, computability or level of detail influence the choice of conceptual primitives and
model kinds.

Each time the conceptual primitives and model kinds are updated; they influence other conceptual model
components, the existing conceptual model artefact and its Meta data, including its characteristics and its
validation status. Conversely each time other conceptual model components and requirements change,
the conceptual primitives and model kinds will be influenced.

5 - 18 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

5.2.4.3 PA4.3 – Select Formalism(s) for Conceptual Model Specification

In this Process Activity, one or more formalisms are selected to be enforced in the build phase. A formalism is
the constraint of form over content. A formalism can be more or less formal. The formality is the amount of
constraints imposed on the form. Informal representations such as loose or structured natural language would
not be considered as a conceptual model (e.g., glossaries, dictionaries, thesaurus, and hierarchies). A formal
representation imposes an artificially defined formalism. A more formal formalism clearly defines concepts
with semantics, theorems and proofs that enable inferences. A higher level of formality fosters some
conceptual model characteristics such as consistency, interoperability, reusability, computability and
executability.

Several formalisms may be required to bridge the gap between different stakeholders. For example, decision-
makers, simulation end-users, simulation developers and machines may feel more comfortable to retrieve
meaningful and valuable input from a particular paradigm or a particular level of formality. The conceptual
model design is meant to cope with contradictory requirements such as expressiveness for human
understandability (e.g., Mind Map or UML) and computability or executability for machine readability (e.g., Web
Ontology Language (OWL)).

The formalisms are carefully chosen according to the policies, the characteristics and the stakeholders’
requirements from P2.1 – Conceptual Model Requirement Specification. In an iterative and incremental
design process, the choice of formalism is driven by and influences the other conceptual model components,
the existing conceptual model artefact and its Meta data, including its characteristics and its validation status.

The producers need to know about the formalism options either from the literature or from experience. There
is a critical need to further develop the body of knowledge necessary to categorize the formalisms in terms
their implications on conceptual model characteristics and on the other conceptual model components.

5.2.4.4 PA4.4 – Select Views to Support Stakeholders

In this Process Activity, views are selected to fit the purpose of the different stakeholders. Views are the
graphical user interfaces of the conceptual model. When selecting views, the producers are always biased by
their own way of “seeing” the problem. It is of utmost importance to make an elective choice of views that
support the stakeholders’ requirements.

A complete conceptual model design generally includes multiple views. For example, Department of Defense
Architecture Framework (DoDAF)/NATO Architecture Framework (NAF) includes an Operational, System
and Technical views. UML offers Design, Process, Component, Deployment, Use Case views.

A view can be represented by several model kinds. For example, the UML Process view represents dynamic
aspects using State, Activity, Sequence and Collaboration diagrams.

Although views are prescribed by P2.1 – Conceptual Model Requirement Specification, many other latent
views can emerge from available conceptual primitives and model kinds if a stakeholder requires it. In an
iterative and incremental design process, the stakeholders’ representation requirements and the views can
evolve as the conceptual model is being built.

The producers need to know about the view options either from the literature or from experience. There is a
critical need to further develop the body of knowledge necessary to determine which views are appropriate fit
which stakeholders’ representation requirements and which conceptual primitives and model kinds make
meaningful views.

RTO-TR-MSG-058 5 - 19
CONCEPTUAL MODELING PROCESS GUIDANCE

If formalisms have been selected in the preliminary conceptual model design, they may impact on the
discretionary specification of views. There may be more than one way of presenting a view and a specific
formalism may impose specifications on the view.

5.2.4.5 PA4.5 – Select a Notation Suitable to Express the Chosen Formalism

In this Process Activity, suitable notations are elected to express the formalisms, the conceptual primitives,
the model kinds and the views selected in the preliminary conceptual model design. The choice is driven by
P2.1 – Conceptual Model Requirement Specification. For example, in Annex I, Section I.2, the Use Case view
was expressed using a custom pictogram notation instead of the UML notation to meet an expressiveness
requirement. Introducing the UML notation to non-initiated decision-makers could have added an overhead if
not a misunderstanding.

The producers need to know about the notation options either from the literature or from experience. There is
a critical need to develop the body of knowledge necessary to explicitly categorize the notations in terms of
supported formalisms, conceptual primitives, model kinds, and views.

In an iterative and incremental design process, the selected notations need to be adapted when the requirements
and the conceptual model design change.

5.2.4.6 PA4.6 – Evaluate Design for Adequacy/Relevance with Respect to Requirements

In this Process Activity, the stakeholders verify whether the conceptual model design meets the criteria that
are manifest in the conceptual model requirements. Their criteria are also part of the V&V argumentation
framework. Typical topics that must be specified and transformed into criteria are whether all views needed
by the stakeholders are available and for each view whether the chosen formalism is capable of expressing the
conceptual model. For example, there must be one or more model kinds that present and completely cover the
user’s view. There must also be one or more views that present and completely cover the designer’s view.

Listed below are the points of emphasis:

• It is not necessary to wait until the requirements are perfect before starting to design the conceptual
model and it is not forbidden to start building the actual conceptual model to express the intent as the
effort progresses in order to help progressing through the requirements. This conceptual modeling
guidance supports the creative process of evolving a conceptual model. Trying to express in building
a preliminary conceptual model is part of the iterative design.
• The conceptual model design always starts with an informal mean to express ideas. It evolves each
time the mean induces ambiguity or constrains what needs to be expressed. The evolution is from less
formal to more formal. The process of evolving a conceptual model design is essential to the
stakeholders self and mutual understanding. The conceptual model design process is a learning
process; the process of becoming aware of self and others’ understanding, bias and expectations.
There is more to it than just what is recorded in the actual conceptual model artefact. The journey
serves as much as the end destination.
• It is important to be intentionally selective on the conceptual model components (conceptual
primitives, model kinds, views, formalisms, and notations) to reduce the risk of uninformed use of
components.
• The producers have the discretionary choice of conceptual model components, but they also have the
responsibility to justify their choice.

5 - 20 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

• Because the conceptual model components are tightly entangled, this five-unknown system of
equations can only be solved iteratively until the requirements are all satisfied and the design is
reconciled in a coherent conceptual model component combination. It is advised to select conceptual
model components and try building a preliminary conceptual model. If the design becomes too
constraining, it is time to redesign toward another level of conceptual model characteristics.
• Specific modeling tools are helpful to design coherent conceptual model component combinations.
It is not rare that the tool influences the design choices, which may affect the conceptual model
characteristics.
• It is important to remind that although the coherence of the conceptual model component combination
is a necessary condition, the conceptual model design must be driven by the requirements, mostly
stakeholders’ representation requirements and conceptual model characteristics requirements.
• It is important to document which requirements cannot be met within the constraints of the design
and to update the effective conceptual model characteristics accordingly in the conceptual model
Meta data.
• It is not rare to feel the need to invent new conceptual model components when encountering
expressiveness limitations. This is why general modeling languages allow creating profiles
(e.g., UML, SysML) and common standards emerge from specific communities. It is useful to look at
related community conceptual models, as a reference since they are likely to suit similar needs.
It is not wrong to invent new conceptual model components when nothing satisfying already exists.
It would be useful to develop the body of knowledge to determine the common design patterns
(appropriate conceptual model component combinations) typically used by the M&S community.

5.2.5 Process Phase 5 Guidance – Build Conceptual Model

The Conceptual model development Process Phase described here is the final stage of the five-step process
and entails the completion of the subject conceptual model by means of its compilation and qualification for
its intended use.

The components of Phase 5 (PP5) Process Activities, their inputs, and resulting products are indicated in
diagram of Figure 5-9 below.

RTO-TR-MSG-058 5 - 21
CONCEPTUAL MODELING PROCESS GUIDANCE

a c t P P 5 Ac tiv ity D ia g ra m : B uild CM

S ta rt P P 5

P 3 .1 V a lid a te d
P re lim in a ry C M
K no w le d g e
P A 5 .1 P op u la te th e C M
u s in g th e c h o s e n
P rim itiv e s , M od e l Kin d s ,
Fo rm a lis m a n d N o ta tio n
P 4 .1 C o nc e p tua l
M od e l De s ign

P A5 .2 C re a te the
s pe c ifie d V ie w s

P A 5 .3 V e rify C M
C o ns is te n c y w rt C M
De s ign

A d e q u a te ?

P A 5 .4 V a lid a te C M w rt
M is s ion S pa c e a n d
S im u la tio n S pa c e
K no w le d g e

A d e q u a te ?

P A 5 .6 E ns u re
A c c e p ta n c e o f C M b y
A u tho rize d S ta k e ho ld e r

End PP5 P 5 .1 C on c e ptu a l

M o d e l (C M )

Figure 5-9: PP5 Activity Diagram: Build Conceptual Model Indicating

Process Activities, Process Flow, and Artefact Generation.

Depending primarily on the results of proceeding activities including work-products (i.e., P3.1 – Validated
Knowledge and P4.1 – Conceptual Model Design), and resulting in a single work-product result (i.e., P5.1 –
Conceptual Model); Phase 5 consists of five (5) Process Activities (PA5.1 through PA5.5) whose contextual
circumstances, execution, and consequent results together with inter process flows will be elaborated in the
commentary that follows and in detailed formal specification in Annex G, Tables G-23 through G-28.

Some guidance relevant to the entire PP5 – Conceptual Model development phase includes the following
elements considered prudent for any such product build effort:
• Confirm entrance criteria are satisfied and that all necessary resources are likely to be available in time.
• Establish Group composition, roles and responsibilities.

5 - 22 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

• Establish expectations for the execution of all Process Activity elements. Plan effort and manage to
resources, schedule, and product deliverables.
• Confirm exit criteria with conceptual model product customer/user.

5.2.5.1 PA5.1 – Populate the Conceptual Model Using the Chosen Primitives, Model Kinds,
Formalism, and Notation
Several considerations relevant to the execution of PA5.1 relate to: input assets, preparation for effort
execution, conduct of the activity itself, and the nature of resulting effort.

Overall program management agent for conceptual model effort is presumed to provide:
• A full specification of characteristics of an acceptable conceptual model product; and
• A complete set of validated knowledge of both the mission space and the simulation space.

Nevertheless, conceptual model build Task Group should be prepared to communicate liberally with Process
Phase 3 and 4 execution agents to request clarification of information provided in work-products P3.1 and
P4.1 and to request additional information determined necessary to complete the model specification as build
population proceeds.

In preparation for formal task activity, anticipation of circumstances likely to arise during the effort is prudent.
Building of a conceptual model entails a variety of determinations that may not be fully prescribed by design
guidance but which are likely to affect the efficiency and quality of conceptual model product. In each of
these cases, provisional determinations by the conceptual model build Group are recommended.

Build strategy refers to the election of style of operation by the Group, election of alternative design options
not otherwise bound by requirements, and establishing such stylistic conventions as may facilitate cooperation
and efficiency of the Group. Build versions may be spiral so that a succession of products is generated
progressively converging on the desired result. Alternatively, parallelization techniques such as partitioning
the mission space, allocating model constructs (i.e., primitives or model kinds) to Group members of the
group may be convenient.

Election of alternative options for Primitives, Model kinds, Formalisms and Notation which may persist,
consistent with P4.1 – Conceptual Model Design specified constraints may be necessary. These determinations
and such style conventions to be shared across the Group should be established by consensus before
significant build composition effort is begun. Checking the implications of such determinations during first
spiral reviews will reassure the Group of the wisdom of its choices.

Prefatory interpretation of sufficiency criteria for the expected product, cast in terms of easily observable and
confirmable product characteristics and evidently correlated to requirements specification elements will
provide insurance against shortfalls in product quality in areas such as detail and completeness (scope,
entities, entity-attribute and entity-relationships) as specified.

Selection and prompt access to sufficient tools is prerequisite to start of work. Selection of such tools should
be made carefully with consideration for:
• Familiarity and competence of Task Group;
• Power to meet conceptual design capture and specification; and
• Facility to generate views and published data products acceptable to customer user stakeholders.

RTO-TR-MSG-058 5 - 23
CONCEPTUAL MODELING PROCESS GUIDANCE

Finally, establishment of Product Document management process and information storage and retrieval
sufficient to contain the evolving conceptual model work-product, control of its authoritative configuration
and containing commentary on tactical decisions – just as is prudent for requirements or code management
under other circumstances.

During execution, conduct of Group reviews of work progress, product convergence according to build
strategies, and product quality should compliment normal program reviews and control mechanisms.
Cultivation of consistency of vision across the conceptual model build Group is a powerful mechanism to
maintain consistency of product, and collaboration among Group members.

Work-product capture in tool consistent with Model Design guidance in form suitable for use as publication or
transmission of database as Product P5.1. For this purpose, preliminary coordination with Stakeholder
recipient is prudent.

5.2.5.2 PA5.2 – Create the Specified Views

Assuming the requirements for conceptual model design are satisfied, and tools that sufficiently articulate and
powerful, the generation, capture, and publication into document or database archive under configurable
control should be straightforward. In order not to be disappointed in this expectation, view generation should
be included in product reviews during PA5.1.

5.2.5.3 PA5.3 – Verify Conceptual Model Consistency with Respect to Conceptual Model Design
The practice of system, software, or simulation verification is of course too extensive in its scope and detail
and too myriad in its alternative strategies, tactics and techniques to be specified here. With respect to the
range of options available for verification of the preliminary conceptual model, the most important
considerations are consistency, and sufficiency – otherwise wide discretion is allowed to the conceptual model
build group commensurate with ‘good practice’ contingent that such process as is elected is declared and
documented together with the results of its execution.

Sufficiency of verification consists in a complete, documented, persistent, and traceable confirmation that all
the attributes required by the conceptual model design of P4.1 are present in the subject conceptual model.
Naturally deliberate and professional requirements management beginning with conceptual model design and
proceeding through the process of model build is desired in avoiding (or, alternatively in detecting) such
errors of omission.

Consistency in verification entails that attributes of the Conceptual Model are in fact self-consistent
(presumably in accordance with Conceptual Model Design) and that, in particular, no pathological attributes
of the Conceptual Model not addressed in the Design are present that will interfere with the acceptability of
the conceptual model in supporting its intended use and in meeting the need for which it was conceived and
created. Such errors of commission are more difficult to identify without a consistent representational schema
in the design, conscientious attention to build discipline, and thorough testing and customer use. Execution or
inspection of the conceptual model in representation of use cases that may have been used in its design as well
as with such cases that were not used in its design will likely be helpful.

5.2.5.4 PA5.4 – Validate Conceptual Model with Respect to Mission Space and Simulation
Space Knowledge
See above, recognizing the distinction between verification and validation, and interpreting the above in
relation to the appropriate referent – that is, Validated Knowledge of Product P3.1.

5 - 24 RTO-TR-MSG-058
 CONCEPTUAL MODELING PROCESS GUIDANCE

5.2.5.5 PA5.5 – Ensure Acceptance of Conceptual Model by Authorized Stakeholder

Whereas verification and validation are technical determinations of goodness of fit or similarity between
artefact (here a conceptual model) and one or another referent (here design requirements, and Validated
Knowledge respectively); accreditation is an administrative decision regarding the degree to which an asset
(here the conceptual model) is acceptable for its intended use. On this account, accreditation processes entail
articulate collaboration between the accreditation agent stakeholder and the proponent of the asset in question.
Several considerations pertain to this circumstance.

First of all, unambiguous identification and acquiescence of the identity of the accreditation agent is
necessary. If the authoritative accreditation agent (or agents) is not clearly identified, due, for instance, to the
relatively large number of agents with a significant ‘stake’ in the conceptual model, an inefficient decision
process is to be expected at best. Note that multiple accreditation agents for alternative intended uses are not
uncommon for either simulations or conceptual models.

Clarity of agreement on intended uses and re-confirmation of accreditation exit criteria in advance of the
accreditation application is prudent if only to remove inconsistency between acceptability of the conceptual
model asset due to migration or evolution of the use or changes in staff appointees.

It is incumbent upon the conceptual model build agent to have designed and execute factory acceptance tests
and if desired user delivery tests whose results have been suitably documented, interpreted and reported in
anticipation of the preparation of submission of accreditation request. Coordination of accreditation reviews;
support of the accreditation decision process itself; documentation of the consequences and its delivery with
the completed Product P5.1 prepared in compliance with associated guidance completes PA5.5, PP5 and
conceptual model development.

5.3 CONCEPTUAL MODELING PROCESS CONCLUSION

In preceding text, a linearized account of recommended best-practice guidance for conceptual model
development and management process is provided. That account is intended to be interpreted together with
the more terse but systematic specification provided in Annex G as constituting recommended best-practice
conceptual modeling process. Every effort was made by the Task Group to produce necessary and sufficient
guidance; in forms that are comprehensible, consistent, and sufficient for guidance of practice throughout the
conceptual modeling process and practically; while leveraging the minimal sufficient binding on the
conceptual modeling practitioner in favor of allowing liberal elective of style, an convention commensurate
with the challenge of the effort and the cultural, technical and business practice constraints of the enterprise
environment in which effort is effected.

RTO-TR-MSG-058 5 - 25
CONCEPTUAL MODELING PROCESS GUIDANCE

5 - 26 RTO-TR-MSG-058
 Chapter 6 – CONCEPTUAL MODEL PRODUCT GUIDANCE

Having addressed in Chapter 5 and its associated Annex G the process intended by the MSG-058 Task Group
to be executed by the “M&S Conceptual Model Development Practitioner” agent. We proceed to discuss the
expected results of completion of the “Conceptual Modeling Best-Practice Development Process”, namely the
Conceptual Model itself.

6.1 PRODUCT GUIDANCE INTRODUCTION

This chapter provides the MSG-058 Task Group’s “Best-Practice Guidance Specification (BPGS)” for the
“Conceptual Model” Product as indicated in Figure 3-4. These products include the conceptual model itself, as
well as intermediate documents produced in the course of following the conceptual model development process.
The intermediate products are critical to document and transfer information from one Process Phase to the
next, and are also very valuable references for later simulation development, and for conceptual model
management throughout the life cycle, including VV&A.

This guidance details the intents and ideas behind these products and how they relate to different phases of the
conceptual model development process. It defines the main products the process should generate, what ideas,
views and information should be contained in each of them, their structure and their format.

The complete set of products associated with conceptual model development is as follows. They are numbered
with respect to the Process Phase within which each one is developed:
• P1.1 – Stakeholder Description.
• P1.2 – Need Statement.
• P1.3 – Constraints and Policies.
• P1.4 – Conceptual Model Meta Data.
• P2.1 – Conceptual Model Requirements Specification.
• P2.2 – Conceptual Model Knowledge Acquisition Needs.
• P3.1 – Validated Knowledge.
• P4.1 – Conceptual Model Design.
• P5.1 – Conceptual Model.

Each of these products will be discussed in more detail in subsequent text, and technical descriptions of each
are provided in Annex H.

This product set has been designed such that all information transfer between conceptual model development
phases is contained within the set of documents. Further, these documents are the input and output of specific
phases. This relationship is shown in the context of the development process in Figure 6-1.

RTO-TR-MSG-058 6-1
CONCEPTUAL MODEL PRODUCT GUIDANCE

PP 2
PP 1 PP 3 PP 4 PP 5
DEFINE
INITIATE ACQUIRE DESIGN BUILD
CM Requirements and
CM Development CM Knowledge CM CM
Knowledge Needs

PA4.1
PA 2. 1 PA 5.1
PA 1. 1 PA3.1 Search for Existing CMs that may
Identify , Analyse and Record CM , Populate the CM Using the
Identify and Map Stakeholders Identify Authoritative be Partially or Fully Re -used to
Mission and Simulation Space Chosen Primitives , Model Kinds ,
Responsibilities Knowledge Sources Support the Current CM
Requirements Formalism and Notation
Development

PA 2. 2 PA4.2
PA 1. 2 PA3.2
Verify Requirements with respect Identify and Select Conceptual PA 5.2
Define Purpose and Intended Search for Re -usable
to Needs , Constraints and Primitives and Model Kinds to Create the Specified Views
Use of M &S Effort Knowledge
Policies Represent Acquired Knowledge

PA 1. 3 PA 2. 3 PA3.3 PA4.3 PA 5.3

Identify Constraints on the M &S Synergize CM , Mission and Identify Knowledge Gaps and Select Formalism (s ) for CM Verify CM Consistency with
Effort Simulation Space Requirements Bounds Specification respect to CM Design

PA 5.4
PA 1. 4 PA 2. 4 PA3.4 PA4.4
Validate CM Consistency with
Impose Mandatory Enterprise Derive Mission and Simulation Gather , Structure and Select Views to Support
respect to Mission Space and
Policies Space Knowledge Needs Document Knowledge Stakeholders
Simulation Space Knowledge

PA3.5 PA4.5 PA 5.5

Generate /Extend a Domain Select a Notation Suitable to Ensure Acceptance of CM by
Ontology Express the Chosen Formalism Authorized Stakeholder

PA3.6 PA4.6
Review Validity of Knowledge Evaluate Design for Adequacy /
with respect to Authoritative Relevance with respect to
Knowledge Sources Requirements

P 1.1 P2. 1
Stakeholder CM Requirements
Description Specification
P3.1
Validated Knowledge
P2. 2 P4.1 P5.1
P1. 2 CM Knowledge Conceptual Model Conceptual Model
Need Statement .5
Acquisition Needs Design (CM)
P

P 1.3
Constraints and
Policies

P1. 4
CM Meta Data

Figure 6-1: Conceptual Model Process and Product Relationships.

From this figure, it can be seen that Stakeholder Descriptions, Needs Statement, and Constraints and Policies
are generated in the 1st phase and provide input to the 2nd phase, but do not continue to influence subsequent
phases. This means that all relevant content of these products must be translated into the Conceptual Model
Requirements Specification and Conceptual Model Knowledge Acquisition Needs documents during the
2nd phase. Likewise, the Conceptual Model Requirement Specification must be translated into the Conceptual
Model Design in the 4th phase to provide input to the fifth and final phase, whereas the Conceptual Model
Knowledge Acquisition Needs are translated into Validated Knowledge in the 3rd phase and made available
directly to the 5th phase. Conceptual Model Meta Data is modified and used throughout every phase.

Listed below are the points of emphasis:

• The provided products are provided as best-practice in conceptual model development.
• These products may be tailored as needed by the developer.
• Product development will be as allowed by the previously described process.
• Intermediary products should be preserved as valuable artefacts for the conceptual model life cycle.

6-2 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

6.2 CONCEPTUAL MODEL PRODUCT DESCRIPTION

In the sections that follow, discussion of the desired conceptual modeling product and its component elements
are provided. The intention of the text is to provide a plausible explanation and rationale of the entire work-
product expected to be necessary and sufficient to constitute a military simulation conceptual model.

In particular, information is provided that is intended to address:

• Motivation for conceptual model component artefacts.
• Considerations relevant generation of specific conceptual model components not wholly addressed in
the preceding process specification.
• Data-item description of conceptual model components, including explication of:
• Information content recommended for the subject data component;
• Data format suggestions for syntactic specification of information;
• Manifestation in forms that are suitably consistent, manageable, persistent, accessible, and re-usable;
and
• Relationships among conceptual model information artefacts.
• Fundamental utility, special value with respect to quality, cost effectiveness, ‘ilities’, etc.
• Special sensitivities associated with generation, administration and use of conceptual model component
elements.

This account is provided as a complimentary and consistent form of guidance which, when taken together with
the systematically tabular guidance specification contained in Annex H, is considered necessary and sufficient
to inform best-practice results.

6.2.1 Product 1.1 Guidance – Stakeholder Description

The Stakeholder Description product component is a document-mapping stakeholder to roles and responsibilities
in the conceptual modeling effort throughout the entire enterprise life cycle. The purpose of this product is to
identify the stakeholders of a particular conceptual modeling development effort and their respective roles and
responsibilities to enable staffing/tasking of the conceptual modeling development effort, derivation of
stakeholder-related requirements and stakeholder-related knowledge needs, and identification of subject-
matter expertise for knowledge acquisition, capture, administration, and use.

At a minimum, the product includes relevant conceptual model development responsibilities identified and
grouped into roles, and stakeholders identified organizationally, mapped to responsibilities and roles.
It is desirable to also include stakeholder identities by name, and point of contact information, when known.
Stakeholder candidate classes are thoroughly described in Section 4.3.3 of this document, and the Process
Activity to generate this product is described in Section 5.2.1.1.

Stakeholder role specification within the enterprise is indicated in the Figure 6-2, wherein composition of role
specifications and types of role functions are generally indicated. (see Lexicon/Glossary, Annex J for terminology
definitions) Naturally, alternative concepts of role specification are admissible, but should be prescriptively
defined in relevant documentation along with accompanying role descriptions.

RTO-TR-MSG-058 6-3
CONCEPTUAL MODEL PRODUCT GUIDANCE

R ole
id
mMem bership
leadership
M

M
Planning
R ole Spec if ic ation

M Organization

R ole N am e Operat ional Authority

C oor dinati on
(Ro lehol
M
dder) May Ex ec u te
M
R ole As s ignm ent
M
Commens urability F u nct io ns D ec is ion
M

M
Cont ingenc y
(Roleholder)
M
M us t Ex ec ut e D irec tion
Eligibility Qualif ic at ions F unc tional R es pons ibility

Commens urability Ex ecut i on

Ev aluation

Figure 6-2: Components of a Role Specification and Relationships to Role Functions.

Information content suggested as minimally sufficient for documentation of conceptual modeling roles
actually employed within the enterprise is suggested in Figure 6-3. Note the obvious distinction between role
specification and role-holder agent or individual. This segregation particularly facilitates the establishment of
organizational postures for the conceptual modeling agents with the enterprise in anticipation of or
commensurate with appointment of, or changes-to particular role-holder assignments.

Figure 6-3: Suggested Role Specification and Stakeholder Role Assignment Information Taxonomy.

6-4 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

As indicated in Section 4.3.3, the fact of the usual diversity and particular nature of stakeholder postures
relative to conceptual modeling within the enterprise is a matter of considerable sensitivity. Difficulties arising
from failure to appreciate the existence, necessity and inter-relationships among these roles commonly afflict
conceptual modeling efforts and denigrate the consequent value of conceptual model products. Systematic
investment in stakeholder role specification as a formal part of the conceptual model product is considered
well worth its relatively modest cost.

6.2.2 Product 1.2 Guidance – Need Statement

The Need Statement product is a document that defines the intended use of the conceptual model, derived
from the purpose and intended use of the M&S within the expected enterprise environment. This product
serves as the source from which to generate the derived set of conceptual model requirements and knowledge.
The Process Activity to generate this product is described in Section 5.2.2.4.

Publication of conceptual model needs statement is motivated by the criticality of preservation of audit
traceability from intended use of prospective simulation implementations through expected uses of the
conceptual model itself throughout the simulation enterprise life cycle. In tracing these related needs and
intended uses, it is important to consider the conceptual model and the consequent simulation generated there-
from as distinct product entities. Sequentially, the need for the simulation typically arises first; then, the need
for the conceptual model to support the life cycle of that simulation is made manifest. Thereafter, conceptual
model requirements may be generated based both on simulation needs and other potential utility of the
conceptual model in the enterprise environment. Conceptual model requirements emerge and the conceptual
model is itself developed and published. Thereafter, simulation requirements may be finalized, manifesting
components of the conceptual model – from which the simulation itself is developed. While this sequence of
events is not always adhered to, and while spiral or concurrent simulation development within an enterprise
environment often admits to contemporaneous conceptual model and simulation product evolution; the value
of audit traceability of the respective process and build threads by means of maintenance of conceptual model
needs statements for successive block-builds is difficult to overestimate.

For purposes of reference for each of the components of the conceptual model product suite, the canonical
causal sequence of ‘needs’, ‘requirements’, ‘design’ and ‘implementation’ may be considered applicable.
The Task Group, while aware of this taxonomy, has not considered it necessary to address each stage of
maturity evolution for each component product, but have, instead, selected the elements of such a matrix that
most need explication, and for which best value may be attained for their explicit inclusion in the subject best-
practice. In future guidance, consideration to completion of this best-practice-to-product-component may be
found to deserve exhaustive coverage. Meanwhile, for reference to the entire matrix of possibilities as well as
indication of matrix loci actually treated in detail in the best-practice guidance, the following table is offered.

RTO-TR-MSG-058 6-5
CONCEPTUAL MODEL PRODUCT GUIDANCE

Table 6-1: Array of Maturity Stages versus Conceptual Model Suite Component
Product Addressed in Detail in the Subject Best-Practice Explication.

DESCRIPTION NEED REQUIREMENTS DESIGN IMPLEMENTATION

Section 6.2.1 Section 6.2.2
Stakeholders
Product 1.1 Product 1.2
Section 6.2.3
Policy
Product 1.3
Section 6.2.4 Section 6.2.4 Section 6.2.4
Meta Data
Product 1.4 Product 1.4 Product 1.4
Section 6.2.6 Section 6.2.7
Knowledge
Product 2.2 Product 3.1
Section 6.2.5 Section 6.2.8 Section 6.2.9
Model
Product 2.1 Product 4.1 Product 5.1

Conceptual model data-item specification is may be liberally adjusted in order to conform to enterprise
conventions. In fact, many forms of needs statements are available; from which tailored adaptations can serve
for conceptual models. As usual, what is imperative is that for any given conceptual model development
within any given enterprise environment, the conceptual model needs statement specification formulary
should be prescriptively agreed-upon among the stakeholder community and preserved longitudinally across
successive conceptual model and simulation block-build cycles. Practically, sensitivity to the simulation –
user’s vernacular and preconceptions are recommended.

6.2.3 Product 1.3 Guidance – Constraints and Policies

The creation and use throughout the conceptual modeling process of an information-product documenting the
strategic business-practice rules-of-the-road, manifest as operational constraints, policies and practices,
is motivated by the need for conceptual modeling to exist as a component of the overall M&S enterprise
environment in which it is conducted. Such operational guidance may exist pursuant to: organizational
regulations; technical standards; enterprise conventions; stakeholder preferences; or contingency conditions
relating to availability of information, staff or materiel resources, While such constraints and policies are
present in every management context, their being made explicit and their being acknowledged by the entire
conceptual modeling stakeholder community is particularly valuable in conduct of conceptual modeling
programs. This special sensitivity results from the facts that:
• Conceptual modeling is poised as it is among stakeholder communities (particularly between
simulation users and simulation developers);
• That the success of enterprise wide initiatives such as re-use and interoperability depend so strongly
upon the deliberate and successful completion of conceptual modeling efforts; and
• That conceptual modeling is typically not administered with sufficient rigor to forestall the
misapprehensions the can so easily arise in early phases of simulation development life cycle.

Naturally, documentation of such strategic guidance admits to any of a variety of forms of capture; and, since
there is little precedent for such practice, some liberty is expected on the part of conceptual modeling agents in

6-6 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

creating useful product of this type. In general, an explicit ‘living document’ kept under configuration control
in the enterprise collaboration environment and available to all stakeholders for reference should suffice.

The Process Activity to generate this product is described in Sections 5.2.1.3 and 5.2.1.4. A more detailed
technical description of this product is provided in Annex H, Table H-4.

6.2.4 Product 1.4 Guidance – Conceptual Model Meta Data

Meta data is generally used to describe the data it is referring to, and provides information about a certain
item’s content, such as: means of creation, purpose of the data, time and date of creation, creator of data, what
standards used, etc. The Conceptual Model Meta Data will address a conceptual model, acting as its identifier.
Conceptual models are stored in a conceptual model repository for future use together with Meta data
specifying how they have been produced, i.e., when, where, by whom, from what, using what tool, and so on.
This Meta data is necessary to ensure traceability and reusability of the Conceptual Model. As shown in
Figure 6-4, the Conceptual Model Meta Data is not part of Conceptual Model, but it is delivered as an end-
product along with the conceptual model itself.

Figure 6-4: Conceptual Model Meta Data Must Always be Attached to the Conceptual Model.

The main role of a Meta data template is to facilitate reusability. Meta data provides information enabling
inferences to be drawn regarding their reuse potential for supporting the extension and creation of models and
simulations. Thus, it is important to include a minimum but sufficient degree of descriptive information about
the conceptual model in its Meta data. An abstract view of the Meta data part of the conceptual model
template is presented in Figure 6-5.

RTO-TR-MSG-058 6-7
CONCEPTUAL MODEL PRODUCT GUIDANCE

class CM Metadata

Meta Data

CM Meta Data

Model Use history

identification

Point of Contact Keyw ord

Reference Glyph

Implementation V&V Data

dependence Elements

CM
characteristics

Figure 6-5: Conceptual Model Meta Data.

The Meta data template can accommodate a number of meta features of the conceptual model, for example:
Name, Type, Version, Modification Date, Security Classification, Release Restriction, Purpose, Application
Domain, Description, Use Limitation, Use History, V&V Data Elements, Keyword, Implementation
Dependencies, Point Of Contact (POC), Reference and Glyph.
• POC: Holds information about an organization or a person having a particular role with respect to the
conceptual model.
• Model Identification: Can accommodate information related to the identification of a conceptual
model such as: Name, Type, Version, Modification Date, Security Classification, Release Restriction,
Purpose, Application Domain, Description, and Use Limitation.
• Use History: Provides a description of where this conceptual model has been used.

6-8 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

• Reference: Specifies a pointer to additional sources of information such as locations in XML documents
and references to ontologies (both domain and middle level) which are used by the conceptual model.
• Implementation Dependencies: Maintains a log of all dependencies determined during the development
of this conceptual model, such as domain ontologies or any other new concept introduced by the
process during the implementation of this conceptual model.
• Key Word: Holds information about the key words of this conceptual model for future use. It helps
users in searching for this conceptual model.
• Glyph: Is responsible for holding the image of conceptual model, which can be used to visually
represent a conceptual model in a tool palette or a web repository.
• V&V Data Elements: The V&V process can produce an enormous amount of data. These data are
collected under a label called V&V Data Elements and placed in the product “Conceptual Model
Meta data”. In the table below a list of data items is presented together with the Process Activities
where that data is produced.

Table 6-2: V&V Data Elements in the Conceptual Model Meta Data.

Meta Data V&V Data Elements PA That Produces V&V Meta Data

V&V Requirements Specification (VV&A Intended use, 1.1, 1.4

VV&A Requirement, VV&A Constraint)

V&V Precondition Specification (Conceptual Model 1.3

Intended Use, Conceptual Model Use Risk, Conceptual
Model Requirement, Conceptual Model Constraint,
Conceptual Model itself if available)

Conceptual Model System of Interest 1.2, 3.4

V&V Experimental Frame 1.3, 1.4

V&V Goal Network 1.2, 2.1, 3.4, 4.3, 4.4, 4.5

V&V Results 2.2, 3.6, 4.6, 5.3, 5.4

V&V Claim Network 5.5

Acceptance Recommendation 5.5

Table 6-2 shows the Meta data elements and the Process Activity that produces the Meta data. A short description
of each element in the V&V Data Elements is given below:
• V&V Requirements Specification
All requirements that are placed upon the V&V products or effort to be delivered and restrictions
placed upon their realisation. It is sub-divided into:
• V&V intended use
An account of how the Stakeholders intend to utilise a V&V product(s) or effort.

RTO-TR-MSG-058 6-9
CONCEPTUAL MODEL PRODUCT GUIDANCE

• V&V requirements
A statement of necessary attributes, capabilities, characteristics, or qualities a V&V product or
effort shall possess in order to have value to the Stakeholders. This could for instance be a
requirement on the usage of specific formats or templates for V&V products.
• V&V constraint
The constraints placed on the execution of the V&V effort.

• V&V Precondition Specification

The prerequisite information for the execution of a V&V project. Many of the items in this specification
can be in the form of references to other products produced in this conceptual modeling guidance.
The following V&V preconditions are required to properly execute a V&V project:
• Conceptual model intended use
An account of how the conceptual model stakeholders intend to utilise the conceptual model.
• Conceptual model use risk
An account of a risk associated to the (intended) utilisation of a conceptual model.
• Conceptual model requirement
A statement of necessary attributes, capabilities, characteristics, or qualities a conceptual model
shall possess in order to have value to the stakeholders.
• Conceptual model constraint
A restriction placed upon the realisation of a conceptual model.
• Conceptual model itself if (parts of it) are already available.

• Conceptual Model System of Interest

The Conceptual Model System of Interest specifies the referent system, which is usually a part of the
real world. This information can be in the form of references to product P3.1 – Validated Knowledge.

• V&V Experimental Frame

The V&V Experimental Frame indicates how the conceptual model is to be evaluated in order to
obtain results that can be used as evidence for criteria.

• V&V Goal Network

The V&V Goal Network structure provides the technical vehicle to systematically develop a set of
precise and well-argued criteria and how evidence for their support can be obtained. Criteria specify
from the Stakeholders perspective a set of requirements that, when proven properly, result into a
positive acceptance recommendation for the conceptual model and its deployment.

• V&V Results
The collection of obtained V&V data that are used as foundation to build evidence for the criteria.

• V&V Claim Network

The V&V Claim Network structure provides the technical vehicle to systematically develop a well-
argued set of items of evidence and acceptance claims. These acceptance claims are a declaration of
an assertion for the conceptual model and its deployment on whether or to what extent its results can
effectively be utilized (i.e., value) with acceptable consequences (i.e., cost and use risk).

6 - 10 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

• Acceptance Recommendation
The Acceptance Recommendation is a Stakeholders oriented presentation of the V&V claim network
and other relevant V&V project information, which together comprise all the pieces of information
needed for an adequate acceptance decision-making on the conceptual model and its deployment.

6.2.5 Product 2.1 Guidance – Conceptual Model Requirements

For purposes of the present document, a specific and very significant distinction is made between ‘wants’ and
‘needs’ on the one hand and ‘requirements’ on the other. The rationale for that distinction illustrates the
motivation for specification of Conceptual Model Requirements as a necessary component of a conceptual
model product suite. Whereas formal definitions for these terms are provided in the glossary, the fundamental
distinction has to do with the relationship of these terms to stakeholders in the first place and the conceptual
model design and implementation on the other. So, for instance, a ‘want’ or ‘need’ is related to the state of
expectation or intention of one or another of the stakeholders. Individually or collectively, stakeholders may
have anticipatory preferences for that which is produced as the conceptual model proper based on their
intended use for it in context of their role within the enterprise. Thus, wants and needs as discussed in Section
6.2.2 (Product 1.2 Guidance – Need Statement) above are proximate to stakeholders’ preferences and may,
or may not, be wholly self-consistent, complete, or informative as a basis for creating or judging the
sufficiency of the conceptual model artifact per se. Wants and needs in this view are desiderata. In the same
vein, a ‘requirement’ is related to the necessary and sufficient attributes of the conceptual model as determined
appropriate for the enterprise at large. Requirements both prescribe and proscribe the characteristics of the
conceptual model which, if present, guarantee the model to be adequate for its several intended uses. As such,
requirements must be monolithic within the enterprise and must manifest the potentially disparate
stakeholders’ wants and needs in positive-definite, observable form. As in any systems engineering or product
development life cycle, stakeholders’ wants and needs are transposed into product attribute requirements in
accordance with the product life-cycle management strategies (such as waterfall, spiral, etc.). Discriminating
between needs and requirements is considered best-practice in conceptual model development; and
documenting each separately, while preserving audit traceability between the two guarantees the appropriate
causal influence of stakeholders needs upon requirements and consequently (and subsequently) upon
conceptual model artifact qualities.

Specification of requirements, therefore, is useful in guiding the conceptual model design and implementation
agents. Published requirements serve as a basis for evaluation of the quality of the resulting conceptual model
quality as built. Preservation of requirements as a formal component product of the conceptual modeling
process guarantees that causal dependencies of design upon stakeholders needs may be understood in the
event of conceptual model product evolution, re-use, or expected interoperability with other such models.

Expression of requirements is, in context of these best-practice recommendations, left materially to the
discretion of the requirements development and documentation agent within the enterprise. Observations
relevant to alternative expressional modes together with the identification of some determinative factors for
choosing particular forms of expression from within those modes are intended to be suggestive rather than
prescriptive.

Conceptual model requirements are certainly an information product whose function is to provide a necessary
if not positively sufficient binding upon the characteristics of the desired conceptual model proper. As such,
the scope of requirements is expected to extend at least across the static and dynamic set of observable
attributes of conceptual models proper (see Section 4.4.2 Conceptual Model Characteristics). Requirements
‘Characteristics’ – (see Figure 4-4 Conceptual Model Characteristics); such as scope, quality, utility, formality,

RTO-TR-MSG-058 6 - 11
CONCEPTUAL MODEL PRODUCT GUIDANCE

abstractness, consistency and special value with respect to quality, cost effectiveness, ‘-ilities’, etc.;
are expected to be included in the requirements regime. Note that the ‘observability’ of required
characteristics documented is significant insofar as the confirmation by observation of the values of those
characteristics as manifest in the conceptual model product with the values proscribed in requirements
specifications will constitute much of the verification of that conceptual model product. There are a few
special sensitivities in requirements documentation that associated with generation, administration and use of
conceptual model component elements. In particular, the conceptual model stakeholder team should be aware
of completeness challenges associated with the relevant generation of specific conceptual model components
not wholly addressed in the preceding process specification.

As an information product, requirements specifications should be systematic with respect to representational

schema elected for use within the enterprise. Such elective, but necessary conventional determinations may
include data-item description of conceptual model components, including explication of:
• Information content;
• Form of requirements specification – Manifestation in forms that are suitably consistent, manageable,
persistent, accessible, and re-usable;
• Relationships among conceptual model information artefacts; and
• Data format.

In the same way that information schemas may be left to the discretion of the conceptual model requirements
management agent and contingent upon enterprise stylistics or conventional standard the choice of information
management artefacts, e.g., classical textual, database, or related forms of expressions, and the choice of
CASE/COTS tools whereby to facilitate the generation, publication, reconciliation, valuation storage, retrieval,
and re-use are considered discretionary just in case such determinations are explicit, documented as intended
practice within the enterprise environment, and complied with by enterprise stakeholders.

Finally, requirements are intended to have the logical standing of imperatives or ‘shalls’ within the enterprise.
Compliance to requirements specifications is expected to be explicit, complete and auditably traceable,
contingent, of course, that mechanisms exist within the enterprise for prompt, systematic, and convergent
identification, documentation resolution, and identification of exceptions to published requirements.

6.2.6 Product 2.2 Guidance – Conceptual Model Knowledge Acquisition Needs

The purpose of this product component is to document and to communicate to the conceptual Model producer
what knowledge must be acquired in order to design and build a conceptual model that will serve its intended
purpose. Conceptual model knowledge acquisition needs describe the scope and level of detail of knowledge
needed by the Conceptual Model developer to produce a conceptual model satisfying the client’s need
statement. Conceptual model knowledge acquisition needs guide the conceptual model developer in collecting
the necessary knowledge and limit knowledge acquisition to the minimum sufficient knowledge set.

Given that the establishment of the context within which the bulk of direct conceptual model population will
occur, the following effort will generate information to be contained in the subject data product:
• Analyze the requirement specification in order to derive knowledge needs.
• Document knowledge needs. Information content of this product describe:

6 - 12 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

• The entities and activities in the mission space the modeler must understand in order to represent
them correctly and with appropriate detail; and
• The simulation technique, tools and legacy assets the modeler must understand in order to
represent implementation requirements and constraints correctly.

Contingent review the conceptual model requirement specification in order to identify knowledge needed for
developing a conceptual model with sufficient fidelity to satisfy its purpose; information covering the following
domains for which specific needs exist will be specified:
• Technologies applied in mission space entities and their capabilities and limitations.
• Physical theories underpinning these technologies.
• Military tactics, techniques and procedures.
• Candidate simulation technologies.
• Legacy simulation models and their capabilities and limitations.

Criteria for sufficiency of the subject product include an exhaustive list of knowledge elements needed to
design and build the desired conceptual model as has been documented in P2.2.

6.2.7 Product 3.1 Guidance – Validated Knowledge

Validated knowledge constitutes the authoritative information that is available, necessary, and sufficient for
the conceptual model development agent to understand the mission space and simulation space and from
which to construct the subject simulation conceptual model.

6.2.7.1 Overall
Validated Knowledge is a product of the NATO conceptual modeling Process Phase 3, known as Acquire
Conceptual Model Knowledge. This product is a validated piece of knowledge, developed in response to an
identified need and/or requirement from the previous phases. It will be acquired from authoritative knowledge
sources, and will then be structured, documented, and validated with respect to that authoritative knowledge
source. This product will be the sole and most important product produced during Phase 3. The next phase,
Design the Conceptual Model, will use this to design the conceptual model, i.e., this product will serve as the
foundation for designing and building the final conceptual model.

6.2.7.2 The Generation Process

The conceptual modeling process is iterative, in which some parts and steps are sometimes conducted in
parallel. By the end of every phase, one or more products are generated which may be used as input for the
next or another coming phase. Moreover, within one phase some activities may also generate one or more
intermediate products which may be used as input for the following activities in the same phase. That is the
case for Process Phase 3, where the end result will be P3.1 – Validated Knowledge.

In the previous phases, the needs and requirements for the knowledge were completed and the authoritative
knowledge sources for the particular knowledge which is requested were identified. But of course before
putting any effort into acquiring the required knowledge, one should search in some existing conceptual
model repository to look for knowledge which may already be available for reuse. So the next activity in the
process will start looking for the corresponding reusable knowledge for that particular conceptual model

RTO-TR-MSG-058 6 - 13
CONCEPTUAL MODEL PRODUCT GUIDANCE

which may already exist in an existing conceptual models repository, knowledge that can be either partly or
completely usable for this new need. If not, the lack of knowledge and the gaps which must be filled are
identified.

As previously mentioned, the conceptual modeling Process Phase 3 is about acquiring sufficient and necessary
knowledge about a particular conceptual model by applying knowledge acquisition methodologies. These
methodologies and the corresponding techniques help to ensure that the correct and necessary data is gathered
from the correct sources. When data is obtained (and is presumed to be in raw text format, all other formats of
data, such as voice, video, etc., can also be converted to raw text) it is assumed to be unstructured and the first
step is to analyze and structure it for further use. The data is therefore processed by knowledge analysis and
formalization methodologies employing the appropriate tools. By using these tools, the data is structured and
focused according to some world view (e.g., ontology). Smaller sections of this structured data can now be
called knowledge instances. The knowledge instances are useful for some purposes, but they are not reusable
since they are specific to the used data (e.g., scenario data, or the result of interviewing one specific SME for
a particular case). To get reusable components, modeling tools and methodologies must be applied to the
knowledge instances in order to get more abstract and reusable components. To make certain that no
information is misinterpreted the ontologies (as a knowledge base) are necessary. These components can now
be called knowledge components and can, with the aid of more methodologies and tools, be composed to form
one or more conceptual models. All of these products (Scenario Data, Interview Results, Knowledge
Instances, Knowledge Components, Conceptual Models, etc.) should be stored in a conceptual model repository
for future use, together with Meta data specifying how, when, where, by whom, from what, using what tool,
etc., they have been produced. This Meta data is necessary to ensure traceability. Now, there should be
enough information to either generate a domain ontology for this particular mission space or extend/update an
existing one. Finally the validity of the acquired knowledge, with respect to the authoritative knowledge
sources, will be reviewed before this product can be produced.

6.2.7.3 The Validation Process

The last activity in this phase of the conceptual modeling Process, PA3.6 – Review Validity of Acquired
Knowledge with respect to the Authoritative Knowledge Sources, discusses and examines the validity of
recently created knowledge with respect to authoritative knowledge sources, and is through that guarantee that
the end-product can be said to live up to the requirements. This activity may be initiated as soon as the activity
PA3.5 – Generate/Extend a Domain Ontology, is done and the acquired knowledge is ready for review.

For the validation of the conceptual model, it is necessary to determine whether all the abstractions used in
modeling are suitable/sufficient for the given purpose and end-product usage. All quality requirements must
be specified in the V&V goal model of the AF, and a precise description must be available of what evidence is
needed. Part of that description is what data must be “measured” in the conceptual model and a description of
the reference data to which it is to be compared. Also the quality of the “measurement” and the quality of the
reference data are specified. For each piece of required evidence, it must be considered if the available
reference data is of sufficient quality. The reference data may measure real-world data, theories,
SME opinions, etc. But for each of those types of reference data, the quality must be considered.

If SME is used as reference data the conceptual model will be reviewed and examined (preferably performed
with assistance of a VV&A agent) by that SME, whose reality has been captured and documented, to see if the
documented knowledge is correct and completely represents the activity. That is to say, examining whether
the result of the knowledge acquisition phase is acceptable to the owner of the mission space. An ontology
expert may also examine if the generation or integration of the ontology is done correctly.

6 - 14 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

When the acquired knowledge or the ontology is validated, Phase 3 is completed and the Product 3.1 is
considered being ready for use, i.e., the artefact is qualified to go to the next phase of conceptual modeling
process.

6.2.7.4 Significant Inputs, Tools, Methods and Roles

To produce P3.1 – Validated Knowledge, some inputs are required:
• The Knowledge Needs and the Requirements List from the previous phases.
• A list of the authoritative knowledge sources for the required knowledge is also advantageous.
• An existing conceptual model repository with reusable knowledge. Also domain ontologies in a
knowledge base are very much appreciated but not mandatory.

This product is a result of a knowledge development process and thus support of appropriate tools, methods,
and techniques from the knowledge development area is very much appreciated. Such things could include:
• Methodologies for acquisition of data, information, and knowledge.
• Methodologies for documentation, representation, and formatting the acquired knowledge.
• Tools for knowledge acquisition, representation, formalization, etc.
• Tools for managing and maintaining ontologies as well as ontology reviewing tools.
• V&V methodologies, e.g., GM-VV as well as V&V tools.

Some of the roles and their areas of responsibility used when generating this important product have been
identified as:
• Knowledge engineer, to provide experience in acquiring, gathering and compiling information;
• SME, to provide the domain and task knowledge;
• Analysis and formatting expert; experienced in the appropriate formatting analysis method and
technique;
• Ontology expert; experienced in mapping and interpreting information held in the ontology, as well as
being skilled in how to further develop and extend ontologies; and
• VV&A-agent for validating the result.

6.2.8 Product 4.1 Guidance – Conceptual Model Design

Just as in text Section 6.2.5 above, the Task Group felt the necessity to distinguish with particular precision the
distinction between ‘needs’ and ‘requirements’; at this point in the exposition, we feel the incumbent
responsibility to distinguish between ‘requirement’ and ‘design’. Both requirements and designed presage the
artefact (namely the conceptual model per se) itself. They are, however, individuated in several ways that make
the creation and persistent management of requirements and design(s) separately valuable to the conceptual
modeling enterprise. Definitions such as are provided in the Glossary appended are suggestive of these salient
distinctions; but, for purposes of this document the following discriminates are cited as particularly relevant:
• Requirements generally address specific attributes of the subject system; while designs address
collective/composite/holistic characteristics.

RTO-TR-MSG-058 6 - 15
CONCEPTUAL MODEL PRODUCT GUIDANCE

• Requirements are derived (devolved) from user/stakeholder needs; while design strategies, tactics and
features are generated to be compliant with existing requirements – in this phase of system evolution,
design discretions permitted insofar as requirements compliance is assured.
• Requirements consist primarily in attribute specification; while designs, while respecting required
attributes must be implementation specific.
• Requirements entail necessary conditions; while designs entail sufficient conditions.
• Requirements address structure and functional necessary attributes; while designs address in addition
compositional relationships among both structure and functions.
• Requirements are insofar as possible implementation indifferent; while designs are of necessity
implementation specific.
• Requirements must proscribe prospective systems to the degree that they are sufficient to support
some prospective design; while designs must be sufficient to support all necessary requirements.
• Requirements serve as a basis for user verification; while Design specifications must serve as a basis
for construction verification.
• Finally, requirements are similar to the Aristotelian final cause or telos, e.g., ‘that for the sake of
which’; while design is more nearly related to Aristotelian material cause (e.g., ‘that out of which’),
and formal cause (e.g., ‘the form … the account of what is to be’).

Motivation for conceptual model design – as for any system design artefact – is to establish constraints upon
the subject product that, when observed, improve the fundamental utility, quality, cost effectiveness, ‘ilities’,
etc., of the work-product. The design should in effect bind the conceptual model product in such a way as to
guarantee accomplishment of requirements. Product design should be sufficient to guide and control
implementation agents possessing a clear appreciation of the enterprise context of the intended product to
complete a satisfactory product. Design should contain explicitly or by inferential implication from requirements,
etc., everything short of conceptual model instance semantic content. That information is, of course, contained
in mission space and simulation space Meta data. Conceptual model product design should constitute a plan or
scheme conceived in the mind and intended for subsequent execution; addressing: architecture, notational
schemas, data formats, and documentary tools. Finally, conceptual model design may contain any information
considerations relevant to the generation of specific conceptual model components not wholly addressed in
the preceding process specification.

Naturally, documentation of conceptual model design admits to any of a variety of forms of capture; and,
since there is little precedent for such practice, some liberty is expected on the part of conceptual modeling
agents in creating useful product of this type. In general, an explicit ‘living document’ kept under configuration
control in the enterprise collaboration environment and available to all stakeholders for reference should suffice.

The Process Activity to generate this product is described in Section 5.2.4 as Process PP4. A more detailed
technical description of this product is provided in Annex H, Table H-9.

6.2.9 Product 5.1 Guidance – Conceptual Model

The conceptual model per se is, in this exposition, the final component of the conceptual model development
process. Having proceeded through the conceptual model development process described in Chapter 5 and
detailed in the process specification of Annex G, and having generated product artefacts above described in

6 - 16 RTO-TR-MSG-058
 CONCEPTUAL MODEL PRODUCT GUIDANCE

this chapter, in accordance with the product specification of Annex H there remains only to comment upon the
populated resulting simulation conceptual model.

The conceptual model product itself is clearly the conceptual model design, populated with mission space and
simulation space data generated, compiled and validated in preceding tasks. Seen as such it is merely the
practical compilation of information previously gathered consistent with the wants and needs of simulation
stakeholders, in context of the subject simulation enterprise environment. It is, therefore one – if the last –
information product of the suite of artefacts resulting from the conceptual modeling effort. Nevertheless,
as the culmination of that effort it is distinctive and particularly noteworthy.

Just as the conceptual model design above constitutes the descriptive and prescriptive specification of the
conceptual model; the simulation conceptual model itself, constitutes the de facto design of the resulting
simulation’s representation capabilities and implementation characteristics. Insofar as the conceptual model
has been generated by a suitably systematic devolution beginning with simulation user needs and proceeding
through collection and qualification of Meta data, specification schema, and information product design
stages, it manifests the fundamental information necessary and sufficient for the creation of a satisfactory
simulation. Insofar as the conceptual model development process has been conducted with due regard to the
enterprise context in which such simulations are to be developed and used, it establishes a sound basis for
collaborative business practice throughout the enterprise and over its practical duration.

The Process Activity to generate this product is described in Section 5.2.5 as Process PP5. A more detailed
technical description of this product is provided in Annex H, Table H-10.

RTO-TR-MSG-058 6 - 17
CONCEPTUAL MODEL PRODUCT GUIDANCE

6 - 18 RTO-TR-MSG-058
 Chapter 7 – CONCLUSIONS AND RECOMMENDATIONS

This best-practice guidance is intended to lay the foundation for practical and effective conceptual model
development, to serve as a baseline for individual enterprise tailored implementations, and to set the vector for
future standardization and conceptual model life-cycle management.

7.1 OBSERVATIONS AND INFERENCES

Conceptual modeling begins, most often unconsciously, at the very beginning of the first idea; long before the
official conceptual modeling effort starts. Notes and drawings scrawled in the corner of a napkin already begin
the abstraction process, and in doing so, provide the first bias. As in Heisenberg Uncertainty, where a
phenomenon is disturbed as soon as one tries to measure it, the referent in a conceptual model is distorted as
soon as one tries to represent it. This is one reason so many simulation frameworks have turned out to be
unusable or un-reusable while they were modeled as point solutions such as “red against blue”, instead of
more composable structures, such as “entities and interactions”. The conceptual modeling enterprise does not
get rid of these biases, as much as it makes the choosing of biases deliberate and well documented.

The conceptual model of a simulation is not simulation space implementation independent. It may appear to
be so, without any specific references to the simulation space, but the decisions that were made during the
conceptual model design inevitably were informed by the underlying need for a simulation capability or an
enterprise interest.

Current practice in simulation development rarely includes an explicit conceptual modeling effort. This fact
was the primary motivation for the development of this guidance. But study of ongoing enterprises has
revealed a few shining examples of deliberate conceptual modeling practices that are encouraging in the
commonality of their underlying principles, even as they took varied approaches in the conduct and
description of their efforts. The value of this guidance to these and future enterprises is the provision of a
broad and flexible process with defined products which can be mapped against current approaches and future
plans. Common terminology can also be derived from this guidance to enable better communication of
concepts between enterprises.

Once the community is able to produce a critical mass of conceptual model products from a diverse set of
enterprises, refining best-practices through a variety of experiences, the methods of standardization and reuse,
along with evolution towards automation and machine readability, can bring about substantial efficiencies in
the conceptual model and M&S development and their respective life-cycle management efforts.

7.2 RECOMMENDATIONS
The following comprise the recommendations distilled from the experience of the MSG-058 Task Group and
which are proffered for consideration in conducting NATO M&S conceptual modeling activity in expected
collaborative enterprise environments:
• NATO Nations should adopt this guidance as best-practice for their national and international M&S
efforts to enable interoperability and reuse.
• The modeling and simulation community should take this opportunity to deliberately incorporate
conceptual model development into their respective M&S development processes, based on the best-
practice provided in this guidance.

RTO-TR-MSG-058 7-1
CONCLUSIONS AND RECOMMENDATIONS

• Each enterprise should specify its own conceptual modeling process and conceptual model products,
using this guidance as a point of reference.
• VV&A of conceptual models should be integral to the development process. Use of the ISO/IEC 9126
standard on software quality is a starting point for the derivation of conceptual model quality criteria,
and use of the (draft) GM-V&V standard is directly applicable to V&V of conceptual models.
• Every customization of the guidance should be published to contribute to the body of knowledge of
conceptual modeling, to build a valuable experience base for standardization initiatives. Especially
important is the documentation of decisions on the mapping of formalisms/views/model-kinds/
primitives, and identification of formalisms that are well suited to particular applications or domains.
It would also be useful to develop the body of knowledge to determine the common design patterns
and appropriate conceptual model component combinations typically used by the M&S community.
Improving the conceptual modeling body of knowledge also involves the development of metrics to
evaluate fitness for purpose of a conceptual model design.
• The M&S community and the Simulation Interoperability Standards Organization (SISO) in particular,
should use this best-practice guidance as a basis to initiate an international standard for conceptual
model development.
• As this guidance was limited in focus to conceptual model development, further work should be
initiated to develop best-practice guidance for the entire conceptual modeling life cycle, including
design for reuse, collection of conceptual models for repositories, configuration management,
verification and validation of conceptual models, and advancing state-of-the-art in development of
automated tools.

7-2 RTO-TR-MSG-058
 Annex A – TAP

Activity MSG-058 2007

Conceptual Modelling for M&S
Activity REF. June 2007
RTG-038
Number IS
Principal Military Requirements 2 UU May 2010

Military Functions 4

Panel and Coordination MSG IST

Location and Dates Multiple P-I

Publication Data TR 2010 50 UU

Keywords M&S Interoperability M&S Re-use VV&A

I. BACKGROUND AND JUSTIFICATION

Current M&S standards have provided a first step to interoperability and a state-of-the-art way to interconnect
simulations and tools to build distributed systems of simulation but it is recognized that existing standards are
not meant for exchange of semantics and concepts. The final objective of the TG is to achieve a common
understanding and use of information exchanged between simulations for better satisfying military
requirements for education, training and operational support. Conceptual models are key to the transformation
of user needs and requirements to M&S design, and eventually implementation. The purpose of this NMSG
TG is to develop a guidance document on Conceptual Models, which can be used in the future by NATO to
support M&S requirements.

II. OBJECTIVE(S)
Major objectives of this Task Group are to:
• Clarify the “Conceptual Model” concepts, discuss the terminology, and emphasize the utility to better
formalize Conceptual Models, etc.;
• Investigate methodologies, simulation and software engineering processes, initiatives and technologies;
• Draft a guidance document on conceptual modelling that can be used by different stakeholders; and
• Foster the establishment of the guidance document as a SISO standard.

III. TOPIC TO BE COVERED

The first step will be to clarify what a conceptual model for Military M&S is and what it represents.
A common understanding is that conceptual models should serve as frames of reference for simulation
development by documenting important entities/concepts, their properties, and their key actions and

RTO-TR-MSG-058 A-1
ANNEX A – TAP

interactions: a conceptual model should bridge between the requirements and simulation design. The second
step will consist to investigate methodologies, simulation and software engineering processes, initiatives and
technologies useful for the establishment and content of conceptual models. The final work will be to provide
a tailorable set of guidance to the M&S community on conceptual modeling. This will guide users through the
conceptual modeling effort by explaining how to apply it in practice. If possible a future guidance will be
proposed to the international community for standardization via the SISO (Simulation Interoperability
Standards Organization).

Deliverables and/or end product:

The final report should be a “guidance document” freely available to the international community.

IV. DELIVERABLE
Technical Report.

V. TECHNICAL TEAM LEADER AND LEAD NATION

Co-Chair: Mr. William F. Waite, United States.

Lead Nation: United States.

VI. NATIONS WILLING/INVITED TO PARTICIPATE

Canada, France, Netherlands, Norway, Romania, Spain, Sweden, Turkey, United Kingdom, United States.

VII. NATIONAL AND/OR NATO RESOURCES NEEDED

Nations should provide funding for their own participation (manpower and traveling resources).

VIII. RTA RESOURCES NEEDED

RTA will publish the final report and electronic support through its RTO Wise.

IX. ADDITIONAL INFORMATION

Limited Participation Technical Team: No.

Comments: This activity will be co-chaired by the USA and Romania.

A-2 RTO-TR-MSG-058
 Annex B – TERMS OF REFERENCE
RTG on
Conceptual Modelling for M&S
MSG-058, RTG-038

I. ORIGIN

A. Background
The NMSG was established within the Research and Technology Organisation (RTO) in 1999, with an
objective to favour re-use and interoperability of M&S within the Alliance, and NATO/PfP Nations. So far,
within NATO, like in the international M&S community, the interoperability objective was mainly addressed
at the “technical level” using open standards developed by SISO (Simulation Interoperability Standards
Organization), IEEE (Institute of Electrical and Electronics Engineers) or ISO (International Organisation for
Standardisation) such as the HLA that was adopted by NATO as early as 1998. Those standards have
provided a first step to interoperability and a state-of-the-art way to interconnect simulations and tools to build
distributed systems of simulation but it is recognized that existing standards are not meant for exchange of
semantics and concepts.

Since the beginning of the NMSG activity it was recognized that HLA was only a preliminary step to satisfy
the M&S technical interoperability concern and that the final objective was still to achieve a more ambitious
M&S “interoperability level”. This final objective should be to achieve a common understanding and use of
information exchanged between simulations for better satisfying military requirements for education, training
and operational support.

In the mean time SISO recognized the importance of better defining and advising the M&S community on the
importance of Conceptual Models not only for the interoperability issue but also to form a basis for simulation
development, foster re-use, and to support V&V activities. A SISO Task Group was created in 2003 to
address the topic of Conceptual Models with the potential objective of developing a new standard, or more
precisely a “guide”, to help practitioners building Conceptual Models. For various reasons this SISO Task
Group did not fully achieve its goals. Nevertheless it produced some interesting and valuable output that can
be exploited to produce a recommended practice guide for the elaboration of Conceptual Models.

The purpose of this NMSG Task Group is to develop a guidance document on Conceptual Models, which can
be used in the future by NATO to support its M&S requirements.

B. Military Benefit
Conceptual models are key to the transformation of user needs and requirements to M&S design,
and eventually implementation. Conceptual models form the bridge of understanding between the users of
M&S, the military domain experts that have the necessary knowledge that must be represented in M&S,
and the software and simulation engineers that implement simulations. Without Conceptual Models, history
has shown that simulation developers often do not sufficiently understand the military domain to be modelled
and implement M&S that do not reflect the intended reality, and thus do not satisfy the user’s needs. Further,
Conceptual Models form the basis of an important step in Verification and Validation – determining that the

RTO-TR-MSG-058 B-1
ANNEX B – TERMS OF REFERENCE

application domain has been described sufficiently to meet users’ needs while accurately incorporating subject-
matter expert knowledge.

In addition to playing a key role in the development of individual simulations, Conceptual Models are also a
key to facilitating the valid and effective composition of M&S into federations. While technical
interoperability of simulations has been thoroughly researched and solutions have been implemented
(for example, the High Level Architecture for M&S), these do not address higher levels of interoperability
(semantic, pragmatic, and conceptual).

Neither a standard practice for Conceptual Model development nor consensus definition of Conceptual Model
content currently exists. Where conceptual modelling is practiced, it is typically defined on a project-to-
project basis. A NATO Task Group (TG), working in conjunction with SISO, is in the unique position to
develop a standard that will be used by multiple Nations, thus meeting the reusability and interoperability
goals. A recommended practice including specification of the content of Conceptual Models for M&S will
further increase user understanding of the capabilities of those M&S, thus increasing their reusability.

II. OBJECTIVE
Major objectives of this Task Group are:
• Clarify the “Conceptual Model” concepts, discuss the terminology, and emphasize the utility to better
formalize Conceptual Models, understand the relationship between conceptual modelling and related
concepts (scenario definition, etc.);
• Investigate methodologies, simulation and software engineering processes, initiatives and
technologies useful for the establishment and content of Conceptual Models;
• Draft a guidance document on conceptual modelling that can be used by different stakeholders
(sponsor/user, project manager, subject-matter experts, V&V agents, developers, etc.); and
• Foster the establishment of the guidance document as a SISO standard.

The TG’s first objective will be to clarify what a Conceptual Model for Military M&S is and what it
represents. A common understanding at this starting moment is that the Conceptual Model should serve as a
frame of reference for simulation development by documenting important entities/concepts, their properties,
and their key actions and interactions. That is a Conceptual Model should bridge between the requirements
and simulation design.

The TG will clarify and rigorously define the core terminology associated with conceptual models and
conceptual modelling, and the relationship among those terms. The TG will identify the key stakeholders in
conceptual modelling and their requirements with respect to conceptual modelling. Stakeholders will include
those that are involved in the production of conceptual models and those that rely on conceptual models to
perform their jobs. Among the issues the TG will address what key concepts each of these stakeholders needs
in a conceptual model and the level of abstraction at which conceptual models should be expressed to meet
various stakeholders’ needs.

Conceptual modelling is one of key concepts in the development and employment lifecycle of M&S. As such
it is related to other concepts such as scenario development, simulation software requirements development,
and test plan development. As part of the first objective, the TG will define the relationships among
conceptual modelling and these other activities. The second objective of this Task Group is to investigate

B-2 RTO-TR-MSG-058
 ANNEX B – TERMS OF REFERENCE

methodologies, simulation and software engineering processes, initiatives and technologies useful for the
establishment and content of Conceptual Models. While the objective of this TG is not to develop or identify a
single standard for the representation of conceptual model content, this TG will identify a range of such
solutions that can be employed in conceptual modelling.

In order to take advantage of the work covered by others regarding to this issue, it will be very important to
collect and analyze as much as possible of the documentation available on conceptual modelling, specially
those related to the M&S field. Lesson learnt by them can help to avoid some recurrent problems, to reduce
the risk of developing simulation not adapted to the requirements and to get a better profit of this TG.

The TG will explore the potential of a variety of processes and knowledge representation approaches to
examine their potential for conceptual modelling. Among these will be simulation-specific methodologies as
the HLA FEDEP general software engineering processes; prior conceptual modelling initiatives as the CMMS
– Conceptual Models of the Mission Space, and emerging technologies such as ontology languages. Through
this objective, the TG will synthesize existing practices to identify the state of the art of conceptual modelling.
By doing this, the TG will maximize the reuse of previous effort in the development of a recommended
practice.

The third objective is to provide a tailorable set of guidance to the M&S community on conceptual modelling.
This will guide users through the conceptual modelling effort by explaining how to apply it in practice.
The process will be tailorable in that it is intended to be extended and modified by individual programs that
apply it. Rather than being a one-size-fits-all rigid, single approach to conceptual modelling, the guidance will
provide a starting point that individual programs can apply given their specific needs and resources.
The guidance on the Conceptual Model content will state what should be in the Conceptual Model, and not
mandate a specific format but suggestions for the selection and use of format, methodology, techniques and
tools will be provided.

The guidance will encompass the conceptual modelling process, Conceptual Model content and describe
appropriate views on a Conceptual Model for different stakeholders. For example, the conceptual modelling
process will describe the transformation from the users view, concerned with the problem domain, to the
developers view, focused on the M&S domain.

The TG’s fourth objective is to foster the establishment of the guidance document as a SISO standard.
The current policy of NATO for standardization is to use civil standards where appropriate ones exist and to
develop its own standards only when no civil standard exists. In the case of conceptual modelling for M&S or
conceptual modelling in general, no civil standard exists. The requirement for M&S Conceptual Modelling is not
specific to NATO or to the military domain. Thus it should be helpful to extend this work to a larger M&S
community. With respect to this proposal, the TG will open its guidance document to an M&S standard product,
developed through an open consensus-based standards body. The SISO is the best suited organization for this
standardization, since it has a strong background and current focus on military M&S, but also includes M&S
practitioners from outside the military domain. Thus, the TG will propose to SISO the creation of a standard
development group (a PDG, Product Development Group) in charge of developing a balloted standard.

Two models of interaction between this NMSG TG and the SISO PDG are possible:
1) The TG guidance document can provide the first draft of the future SISO product which can benefit
from the input of a larger M&S community; or
2) The TG will work along with a SISO PDG to develop the product.

RTO-TR-MSG-058 B-3
ANNEX B – TERMS OF REFERENCE

The decision rests with the SISO membership and the SISO Standards Activity Committee on whether they
wish to apply the resources immediately to exercise the second option. In either case, the TG will be involved
in the SISO PDG activity and could provide a part of the leadership of the group thus protecting its own
interests. This working mode between NATO Task Groups and SISO Product Development Groups has
already been employed in the VV&A (Verification, Validation and Accreditation) and Coalition Battle
Management Language (C-BML) activities. Even if the first cooperative approach is used, and SISO does not
choose to take the product forward as a SISO product, NATO will be provided with a guidance document as
proposed in the third objective at the end of the TG activity.

Main deliverables of the Task Group will be:

• A draft guidance document;
• Interim publications at some conferences (when required); and
• A final report.

III. RESOURCES

A. Membership
Co-Chair: Mr. William F. Waite, United States.

B. Nations Willing/Invited to Participate

Canada, France, Netherlands, Norway, Romania, Spain, Sweden, Turkey, United Kingdom, United States.

Task Group members must have a working knowledge of the simulation design and development. An initial list
of Nations, which have expressed a willingness to participate, is given above.

Other Nations can express willingness to participate in this activity. It is recommended that USA and Romania
co-chair this activity.

National and/or NATO resources needed:

• Member Nations will supply manpower (including travelling expenses) resources. It is important that
the group be supported by the NATO Modelling and Simulation Coordination Office (MSCO).

RTA resources needed:

• Technical report publication services.
• RTO Web Space via the RTO Wise.

IV. SECURITY LEVEL

The security level will be Unclassified/Unlimited.

V. PARTICIPATION BY PARTNER NATIONS AND OTHER NATIONS

This activity is open to PfP.

B-4 RTO-TR-MSG-058
 ANNEX B – TERMS OF REFERENCE

VI. LIAISON
Liaison should be established with the following organisations:
• MSG-054 Task Group on “An Overlay Standard for Verification, Validation, and Accreditation
(VV&A) of Federations”;
• MSG-052 Task Group on “Establishment of a Knowledge Network for Federation Architecture and
Design”;
• The coming Task Group IST-075/RTG-034 on “Semantic Interoperability” (Continuation of the IST
group ET-040 on “Ontology fusion”);
• Simulation Interoperability Standards Organisation (SISO); and
• Other RTO Task Groups as required.

VII. REFERENCE
The deliverables should be “Unclassified – Approved for Public Release (unlimited distribution)”.

RTO-TR-MSG-058 B-5
ANNEX B – TERMS OF REFERENCE

B-6 RTO-TR-MSG-058
 Annex C – TAP/TOR REQUIREMENTS

REQUIREMENT COMPLIANT
Comply with TAP-TOR guidance language … as interpreted X
Sufficiently serve all relevant stakeholders X
Be demonstrably and fully relevant to (but not strictly limited to) best-practice… X
Modeling and simulation life-cycle X
Defence industry enterprise X
Facilitate broad-based M&S standards evolution X
Conceptual Model has to be something useful to the M&S community to understand clearly X
those aspects of the reality that must be implemented in a simulator
Conceptual model has to be enough open to get that it will be reusable by anyone that face X
similar problems in the same domain of knowledge
The guidelines have to become in a standard for conceptual model in M&S X
Guidance to address the conceptual model needs of NATO military M&S (4) Stakeholders, X
while keeping in mind that the related processes and technology solutions may be applicable
to a larger audience (non-military, non M&S). We must be enough specific (military /
M&S) to produce a useful and applied guidance document but nothing more specific than
that. If the specification does not bring clarity, useful / applicability of the guidance, we
must admit it.
Priorities in topic discussion be addressed X
[Address needs of 4] stakeholders X
Final product should be as… general as possible X
Relevant to military M&S but not proscribe practices that would preclude uses within other X
areas (as for instance, Enterprise modeling)
Consider adoption/tailoring of the 4-actor view of stakeholders X
Primary emphasis on the needs of the [simulation] developer X
Ensure stakeholders, use cases, definitions and applications are applicable to the military X
and M&S areas
If we discover during the process that we must give specific guidance that limits the scope X
to military or M&S, we will constrain ourselves only to the minimum degree necessary to
address the specific case
Other than military and M&S areas we have no other scope constraints X
Convey M&S as prime concern versus information systems in general X
Cover military as primary concern versus other domains X

RTO-TR-MSG-058 C-1
ANNEX C – TAP/TOR REQUIREMENTS

REQUIREMENT COMPLIANT
Identify specific stakeholders in the [military and M&S ] domains to capture their X
requirements on conceptual models but try not to limit the conceptual model for only those
domains
Scope driven from stakeholder’s needs X
Focus on defence establishment X
Focus on M&S development X
Stakeholder roles to be advanced somewhere between 4 of NMSG -042 and Colonel Smith X
Use of generally accepted practice in the computer science establishment X
[address] Definition of conceptual model X
[address] How conceptual model can address military simulation shortcomings X
[include] General evaluation of conceptual model use cases versus actual technology use X
cases
[provide] Guidance to implementation of conceptual models X
[provide] Guidance to possible standards X
Conceptual model [practice and artefact] has to be something useful to the M&S community X
to understand clearly those aspects of the reality that must be implemented in a simulation
Conceptual model [practice and artefact] has to be open enough that it will be accessible by X
anyone who face[s] similar problems in the same domain of knowledge
Guidance [has] to become a standard for conceptual modeling in M&S X

C-2 RTO-TR-MSG-058
 Annex D – ISSUES

In order to identify and subsequently resolve issues (i.e., topics whose deep appreciation and consensus resolution
by the Group members would likely be necessary to the successful completing of the MSG-058 effort) the Task
Group resolved to systematically review the prospective study and establish, by consensus, topic areas
considered deserving attention. The first step in this process was to discuss potential difficulties in areas of:
• General and Administrative conduct of the effort;
• Elements of the Programme of Work; and
• Matters of Technology that were likely to challenge the Group in successfully completing its assignment,
and considerations related to the intended Work-Product.

In doing so, as completely and systematically as possible, our intention was as follows:
• Ensure that each national participant nominated at least one issue topic of particular concern;
• Ensure that at least one topic was nominated for consideration by each individual participating in the
study;
• Arrange that each topic was ‘adopted’ by some one individual, who would be depended upon to pursue
resolution throughout the study process; and
• Arrange that each adoption allowed individuals with special intensity of concern for a topic to influence
the Group’s treatment of that topic issue to their particular satisfaction.

This intention for issue management activity is indicated in the following figure, where abbreviated topic titles
associated with General and Administrative, Programme of Work, Technology and Work-Product specification,
generation, and publication respectively.

RTO-TR-MSG-058 D-1
ANNEX D – ISSUES

Figure D-1: Outline of Scope and Influence Among Topic Issues Identified by the
Task Group in Anticipation of Initiation of Detailed Programme of Work.

It was further resolved by the Task Group that for each issue topic, the designated agent, would provide a
definition, indicate stakeholder needs, specify the scope of concern of the topic, and establish other such attributes
of the identification and specification of the issue, together with recommendations of actions whereby the
effect of each issue in areas of Technology, Work-Product, Programme of Work, and meta-process would be
made a matter of record and so duly respected by the team during the consequent effort. This intention is
indicated diagrammatically in the following figure.

D-2 RTO-TR-MSG-058
 ANNEX D – ISSUES

Figure D-2: Schematic of Specification of Topical Issue, Resolution Action and Influence.

Finally, the suite of issues so identified were reviewed by the Team in order to establish a priority list and to
identify the highest priority issue topics in order that the sensitivity of the study Task Group might continue to
be focused on a consensus basis throughout the duration of the effort. The list that follows indicates the 5 most
important topical issues identified by consensus of the group.
1) Stakeholder Analysis and Context;
2) Scope and definition;
3) Relationship to standards;
4) Specification of Conceptual Model Management Process; and
5) Specification of Conceptual Model Artefact.

The following table provides the details of the priority vote-ordering of the total list of topical issues considered.

RTO-TR-MSG-058 D-3
ANNEX D – ISSUES

Table D-1: Total List of Candidate Topic Issues, With Team Vote Compilation of Significance of Each.

Circumstances and Analytical Context: Score 1-5

Stakeholder Analysis and Context (20) 1,1,1,2,1,1,1,1,2Æ11

Effort Analytical Frame (e.g. ‘Conceptual model’ versus ‘Ontology’ … DODAF, 2,3,2,3,3,2,2,2,1,Æ20
MDA versus ontology …system eng, software eng, ? engineering… OWL / Rules …
‘ontology’ pragmatic selection of operating locus within the manifold of knowledge
management Æ capture as ‘operational strategy’)

Intention:
Product influence-utility scope … “Scope” – M&S? Military? Versus SE? Executable 1,2,1,1,1,2,1,1,1,Æ11
versus Representation? Order (CM / Mil / M&S vs. CM / M&S / Mil)
Guidance rigor (22) 3,1,3,3,2,1,2,2,3,Æ20
Style of influence (e.g. CMMI?)
Authoritative standing
Enforcement strategy

Product Development and Deployment:

Product needs/requirements discrimination (18) 4,3,3,4,1,2,3,4,3,Æ27
Work- Product content structure/architecture (19) 1,5,3,3,1,3,1,2,4Æ23
Exposition
Lexical analysis and documentation (10)
Reference analysis and documentation
Specification of Conceptual Model Management Process 1,1,1,1,2,2,1,1,2,Æ12
Process content
Expository schema
Subjective bias/influence/effects (ontological relativism) mitigation (17)
Specification of Conceptual Model Artefact (14) 1,1,1,1,1,1,1,1,2,Æ10
Specification requirements
Expository Schema
Conceptual Model contingency with respect to detail of conceptual model, its
relationship to simulation lifecycle evolution, it multiplicity of views, its
computability and its creditability.
Prototyping with Guidance-Product 3,4,3,1,3,4,4,3,3,Æ28

D-4 RTO-TR-MSG-058
 ANNEX D – ISSUES

Circumstances and Analytical Context: Score 1-5

Product Development and Deployment (cont’d):
Identify/enlist trial-horse sample problems
Establish preliminary guidance
Execute prototype
Abstract lessons learned
Document effort
Deployment/employment of guidance 5,3,3,1,4,2,2,3,4,Æ27
Recommendations
Initiate practice (23)
Deployment Campaign
Institutional Coordination

Technical Considerations:
Ontology (11) 2,2,1,1,4,1,1,2,3,Æ17
Function versus Object (13) 4,4,2,5,1,2,4,5,2,Æ29
Emphasis man vs. machine (21) 5,2,1,2,4,1,2,4,2,Æ23
Interface (only) vs. Context (15) 2,3,2,5,3,3,4,3,1,Æ26
Patterns/meta-model/stereotype (16) 2,3,2,5,4,3,2,2,4Æ27
Relationship to Standards … DODAF, etc. others 2,1,2,1,3,1,1,1,1,Æ13
Relationship to VV&A (12) 1,2,2,2,2,3,3,3,2,Æ20
Relationship to BOM, CBML, CML, other (24) 2,2,2,2,3,3,2,2,1,Æ19
Intellectual Property management 3,5,4,3,4,5,3,4,5Æ36

RTO-TR-MSG-058 D-5
ANNEX D – ISSUES

D-6 RTO-TR-MSG-058
 Annex E – EXPLANATION OF FUNDAMENTAL CONCEPTS
FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

In order to better understand and incorporate into the best-practice guidance specified in detail in following
annexes, the Task Group undertook an analysis of fundamental concepts for conceptual model composition and
specification. This analysis addressed particularly the differences and similarities between a variety of commonly
used conceptual models, formalisms and ontologies. This analysis had as its objective the following:
• Give appropriate and necessary definitions. Discuss the differences and the benefits of natural languages,
artificial languages, and machine languages.
• Discuss the possibility to verify the models by rules and constraints – if they have formal representations.
• Explain how to transform an informal conceptual model into a formal or semi-formal model.
• Discuss Machine Readability – e.g., to make an ontology ‘machine-readable’ we need to select a formal,
machine-processable implementation language.
• Show the steps towards making the human-readable information also machine-readable. (One of the
accepted ways of expressing such machine readable conceptual models is UML (Unified Modeling
Language). UML is being used for far more than simply conceptual modeling. Additionally, UML class
diagrams (conceptual models) can be categorized as semi-formal ontologies themselves. (Semi-formal
because they are not directly machine-readable.) However, tools are being developed that enable
automatic transformation from UML class diagrams to ontology formalisms like DARPA Agent Markup
Language (DAML), OWL, etc.).

E.1 OVERVIEW
To determine what can be a good conceptual frame for a set of elements for capturing the semantic contents
necessary and sufficient for a conceptual model, we have reviewed a number of methods known to the Task
Group to be relevant and representative for use for conceptual modeling. We identified and studied sixteen
(16) different methods/templates and have noted their properties, their most important information elements,
parameters, etc. The results of this analysis revealed, as expected, the common factors among them from
which we could select attributes of the consequent conceptual model specification prescriptive guidance to
follow.

Given this analysis, a synthesis step followed. Having found the denotative name for information elements, their
information content, and justification of their necessity; we allocated those elements to our nascent conceptual
modeling process and product. Taken together with the options are their representation/specification, and the
degree their quality should be certified; we proceeded to successfully generate a table of semantic contents
necessary and sufficient for a conceptual model, along with their qualifying attributes and other necessary
information.

For the purpose of this analysis/synthesis, the following terminology is relevant:

• A ‘Behavior’ is the means an Actor uses to actuate Events.
• An ‘Actor’ is the subject of action.
• An ‘Event’ is an action composed of Activities.

RTO-TR-MSG-058 E-1
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

• A ‘Control’ defines what can occur within an Activity.

• ‘Information’ details the capabilities of a Behavior, Actor, Event, or Control.

Using this vernacular, a process is specified (in the present context), thus:
Using <Behaviors>, an <Actor> actuates <Events> composed of <Activities> that are directed by
<Controls> and richly described by <Information>.
… where the text indicated within carets as reserved words are used below in tabulating the model schema
characteristics in tabular form for each model schema analyzed.

E.2 ANALYSIS
Analysis of conceptual schema alternative styles follows, given the primitives established above. In each case,
we identify the schema, and characterize it systematically in order both to:
• Appreciate its intrinsic nature and the systematic relationships among alternative typical relevant
schema; and
• Provide evidence to the effect that the use of the normative precept above is sufficient for any
conceptual model specification.

E.2.1 Method: BOM [1]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Patterns of interplay:
A. Identifies a sequence of actions.
II. State machines:
A. Identifies the behavior states expected to be exhibited by one or more conceptual entities.
III. Event type (Conceptual events):
A. Describes the types of events that are the result of, or triggered from, actions relevant in a pattern
of interplay.
B. Two types:
1. Triggers.
2. Messages.
IV. Entity type (Conceptual entities):
A. Types of conceptual entities that represent senders and receivers of information in a pattern of
interplay.
B. Object classes.
C. Interaction classes.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

E-2 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
State machines Entity type Event type Patterns of
interplay
(Object class) (Triggers)
(Interaction (Messages)
class)

E.2.2 Method: BOM++ [2]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Patterns of interplay:
A. Identifies a sequence of actions.
B. Identifies the behavior states expected to be exhibited by one or more conceptual entities.
II. Event type (Conceptual events):
A. Describes the types of events that are the result of, or triggered from, actions relevant in a pattern
of interplay.
B. Two types:
1. Triggers.
2. Messages.
III. Entity type (Conceptual entities):
A. Types of conceptual entities that represent senders and receivers of information in a pattern of
interplay.
B. Extended through use of Namespace Qualified Extensions.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
State machines Entity type Event type Patterns of
interplay
(Object class) (Triggers)
(Interaction (Messages)
class)

E.2.3 Method: BPMN [3]

BPMN is particularly conceived to meet the following criteria:
• Designed to be usable to business community; and
• Must generate executable processes through a BPMN model, coupled with some additional information.

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:

RTO-TR-MSG-058 E-3
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

I. Activities:
A. Work that is performed within a business process.
B. Can be atomic or non-atomic (compound).
C. Activities that are a part of a Process Model are:
1. Sub-Processes:
a) A compound activity included within a Process:
(1) Can be broken down into a finer level of detail (a Process) through a set of sub-
activities.
(2) Enables hierarchical process development.
(3) Two types:
(a) Embedded.
(b) Independent (reusable).
II. Task:
A. An atomic activity that is included within a Process.
B. Used when the work in the Process is not broken down to finer level of Process Model detail.
C. Can be looped.
III. Events:
A. Something that “happens” during the course of a business process.
B. Affect the flow of the Process.
C. Usually have a trigger or a result.
D. Can start, interrupt, or end the flow:
1. Start:
a) Indicates where a Process will begin.
2. Intermediate:
a) Occur after a process has been started and before a process is ended.
3. End:
a) Indicates where a process will end.
IV. Gateways:
A. Modeling elements that are used to control how Sequence Flows interact as they converge and
diverge within a Process:
1. Exclusive Gateways (decisions):
a) Locations within a business process where the Sequence Flow can take two or more
alternative paths.
b) Only one of the possible outgoing paths can be taken when the Process is performed:
(1) Two types decision mechanism:
(a) Data.
(b) Events.
(c) A branching point in the process where the alternatives are based on events that
occurs at that point in the Process, rather than conditions.
2. Inclusive Gateways:
a) Where there is more than one possible outcome.
3. Complex Gateways:
a) Where there more advanced definitions of behavior can be defined.
4. Parallel Gateways:
a) Places in the Process where multiple parallel paths are defined.
V. Connectors:
A. Sequence Flow:
1. Used to show the order that activities will be performed in a Process.

E-4 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

2. Source and target must be Events, Activities, and Gateways.

B. Conditional.
C. Default:
1. Exits an Exclusive or Inclusive Gateway may be defined as being the default path.
D. Message Flow:
1. Used to show the flow of messages between two entities that are prepared to send and receive
them.
E. Association:
1. Used to associate data, information and artefacts with flow objects.
VI. Swim-lanes:
A. Used to partition and organize activities.
B. Pool:
1. Represents Participants in an interactive (B2B) Business Process Diagram.
C. Lane:
1. Represents sub-partitions for the objects within a Pool.
VII. Artefacts:
A. Provide the capability to show information beyond the basic flow-chart structure of the Process:
1. Data Objects:
a) Used to show how data and documents are used within a Process.
2. Groups:
a) Used to highlight certain sections of a Diagram without adding additional constraints for
performance, as a Sub-Process would.
3. Annotations:
a) Provide additional information about a Process.
b) A modeler or tool can extend BPMN by defining new Artefacts.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Event Process Gateways
– Activity Connector
– Sub-process – Sequence flow
(embedded) – Conditional
(reusable) – Default
– Task – Message flow
– Association
Swim-lanes
– Pool
– Lane
Artefacts
– Data objects
– Groups
– Annotations

RTO-TR-MSG-058 E-5
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

E.2.4 Method: CML (OneSAF) [4]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Elements:
A. Real/abstract things making up and acting in the battle-space.
B. Belong to a Category.
C. Have Characteristics.
D. Issue Events.
E. Stimulate Behaviors.
F. Behaviors change state of Elements.
G. Two sub-classes of Elements:
1. Piece.
2. Players.
3. Those things explicitly represented:
a) Tanks, infantry, etc.
b) Markers.
4. Things implicitly represented:
a) Tactical positions, Psyops, etc.
5. Game-space:
a) Environment.
b) Establish physical battle-space whereas Elements have a location.
6. Zone:
a) Abstract spaces where inhabitants do not have a location:
1) Satellites providing intelligence.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Behaviors Elements Events Game-space Category
– Piece Zone Characteristics
– Player

E.2.5 Method: CommonKADS [5]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Communication Model:
A. Needs and desires with regards to other agents (e.g., a user interface or interfaces with other
systems).
II. Knowledge Model:
A. Knowledge and reasoning requirements.

E-6 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

B. Specifies data and knowledge structures for an application:

1. Domain knowledge.
2. Task/Inference Knowledge:
a) The objectives of an app, together with how to achieve these.
b) Tasks>Sub-tasks>Elementary inferences.
c) Therefore, a task is composed of a number of combined inferences, documented in an
inference diagram.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Communication Agent Task Sub-task Communication
model model
Elementary Knowledge
inferences model
– Domain
– Task/
inference

E.2.6 Method: DCMF (KM3) [6]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Model element:
A. Primary active object, as well as objects that are part of actions.
B. Can be:
1. EntityType.
2. RoleinAction.
3. RoleInOrganizationType.
4. Action Type.
II. Attribute:
A. Describes an optional, measurable characteristic of a model element.
III. State:
A. Set of attributes with values associated with a model element.
B. Specifies conditions under which an activity starts and ends.
IV. Rules:
A. Description of changes to model elements.
B. Rules are pairs:
1. Activity role.
2. Atomic formula:
a) Statement about the state or attributes of a role.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

RTO-TR-MSG-058 E-7
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Element Activity State Attribute
Rules

E.2.7 Method: DCMF (M2CM) [7]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Meta data:
A. Provides information regarding their potential for reuse in extending and creating conceptual
models:
1. POC (Point Of Contact):
a) Holds information about an organization or a person having a particular role with respect
to Conceptual Modeling.
2. Model Identification:
a) Accommodates information related to the identification of Conceptual Modeling:
(1) Name.
(2) Type.
(3) Version.
(4) Modification Date.
(5) Security Classification.
(6) Release Restriction.
(7) Purpose.
(8) Application Domain.
(9) Description.
(10) Use Limitation.
3. Use History:
a) Describes how Conceptual Modeling was used.
4. Reference:
a) Pointer to additional sources of info:
(1) T. ex., Locations in XML documents.
(2) References to ontologies.
5. Implementation Dependencies:
a) A log of all dependencies determined during Conceptual Modeling development:
(1) T. ex., Domain ontologies.
6. Key Word:
a) Contains information about keywords (used for searching).
7. Glyph:
a) Contains an image of Conceptual Model.
b) Sub-parts:
(1) Notation.
(2) Views.
(3) Dynamic.
(4) Static.
II. Static:
A. Role could possibly be filled using DCMF-O, in particular JC3EIDM:
1. Action:

E-8 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

a) Describes military actions on the lowest granular level or higher level aggregation.
2. Context:
a) Context in which action occurs.
3. Reporting:
a) Contains all data and information.
4. Rule of Engagement:
a) Associated with actions.
5. Candidate-Target List:
a) Associated with actions.
6. Objects:
a) Type:
(1) Static and persistent.
b) Item:
(1) Dynamic and likely to change over time.
7. Action Capability:
a) Capability of an object to perform a function or achieve an end.
8. Location:
a) Specific place for any item in the sphere of operations.
b) Geometric shapes needed to plan, direct, and monitor operations:
(1) Related to object-item concept.
(2) T. ex, Boundaries.
(3) Corridors.
(4) Restricted Area.
(5) Minefields.
9. Affiliation:
a) All objects possess an affiliation:
(1) T. ex Political Nation.
(2) Ethnic group.
III. Dynamic:
A. Role could possibly be filled using DCMF-O, in particular BOM++:
1. Captures activities, actions, and decisions performed by the atomic knowledge components of
the Conceptual Model.
B. Pattern of Interplay:
1. Represented by one or more pattern actions needed to accomplish a specific purpose or
capability.
C. State Machine:
1. Describes the possible states of the conceptual entities as well as the transitions between
them.
D. Entity Type:
1. Provides a mechanism for describing the types of conceptual entities used to represent senders
and receivers identified within a Pattern of Interplay and to carry out the role of conceptual
entities identified within the state machine.
E. Event Type:
1. Provides a mechanism for describing the types of conceptual events used to represent and
carry out:
a) Pattern actions.
b) Variations.
c) Exceptions.

RTO-TR-MSG-058 E-9
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
State machine Entity type Event type Pattern of Ontology stack Meta data
interplay
(Action) (POC)
(Context) (Use history)
(Reporting) Reference
(Rules of (Implementation
Engagement) Dependencies)
(Candidate- (Key word)
Target List) (Glyph)
(Objects) (Model ID)
(Action – Name
Capability) – Type
(Location) – Version
(Affiliation) – Modification date
– Security
Classification
– Release restriction
– Purpose
– Application
domain
– Description
– Use limitation

E.2.8 Method: DRDC [8]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Elements:
A. Entities.
B. Entity Attributes.
C. Functions/Actions.
D. Relationships/Interactions.
II. Assumptions.
III. Functions/Actions.
IV. Constraints (restraints) / Bounds / Limitations (restrictions).
V. Domain Specific Algorithms.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

E - 10 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Functions/ Elements Entity attributes Attributes
actions
Relationships/ Assumptions
interactions
Constraints/ Domain specific
bounds/ algorithm
limitations

E.2.9 Method: Entity Relationship [9]

Entity Relationship perspectives are characterized by the following:
• Role of an entity in a relationship is the function that it performs in the relationship.
• The information about an entity or a relationship is obtained by observation or measurement, and is
expressed by a set of attribute-value pairs.
• An attribute can be formally defined as a function which maps from an entity set or a relationship set
into a value set or a Cartesian product of value sets.
• Another conceptual approach is provided by Entity-Relationship (ER) Modeling (ERM) Although
ER models can be useful once the design process is finished, they are less suitable for formulating,
transforming or evolving a design. ER diagrams are further removed from natural language, cannot be
populated with fact instances, require complex design choices about attributes, lack the expressability
and simplicity of a role-based notation for constraints, hide information about the semantic domains
which glue the model together, and lack adequate support for formal transformations. Many different
ER notations exist that differ in the concepts they can express and the symbols used to express these
concepts. For such reasons we prefer ORM for conceptual modeling. In addition to ORM, VEA supports
IDEF1X (a hybrid of ER and relational modeling) as a view of ORM.

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Entity:
A. A “thing” which can be distinctly identified.
II. Relationship:
A. An association among entities.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Entity Attribute/ Attribute/value pairs
value pairs
Relationships

RTO-TR-MSG-058 E - 11
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

E.2.10 Method: KAMA [10]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Core meta-model (KAMA Foundation):
A. KAMA Behavior:
1. Missions.
2. Tasks.
3. Activities.
4. Events.
5. States.
6. Data Items.
7. Command/Control Units.
B. KAMA Relationships.
C. KAMA State Machine:
1. Expresses the behavior of a conceptual model entity.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
KAMA state KAMA KAMA Attribute/value pairs
machine behavior behavior
KAMA KAMA relationships
relationships

E.2.11 Method: Mind Maps [11]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Central focus of an image or graphic representation of the problem or information being mapped is
placed in the center of a page (BOI’s or Basic Ordering Ideas):
A. Associate and connect ideas with lines, arrows, and symbols:
1. Ideas are allowed to flow freely without judgment.
2. Key words are used to represent ideas.
3. One key word is printed per line.
4. Key word ideas are connected to the central focus with lines.
5. Color is used to highlight and emphasize ideas.
6. Images and symbols are used to highlight ideas and stimulate the mind to make other
connections.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

E - 12 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
N/A N/A N/A N/A N/A N/A

E.2.12 Method: Topic Maps [12]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Topics:
A. Are related to each other by associations, which are typed n-ary combinations of topics:
1. Associations are the general form for the representation of relationships between topics in a
topic map. An association can be thought of as an n-ary aggregate of topics. That is, an
association is a grouping of topics with no implied direction or order, and there is no
restriction on the number of topics that can be grouped together.
B. May also be related to any number of resources by its occurrences.
C. Represents information using:
1. Associations (representing relationships between topics):
a) Each topic involved in an association has a role type.
2. Occurrences (representing information resources relevant to a particular topic):
a) Used to represent or refer to information about a concept represented by a topic.
b) Can be used either to store string data within the topic map, or to reference any kind of
Web-addressable resource external to the topic map.
II. Topics (representing any concept):
A. A topic is a machine-processable representation of a concept:
1. Topics have:
a) Four principal forms of identity.
b) Can have zero or more of each of these forms of identity, and thus can be identified
within a topic map system by a number of different ways:
(1) Identity as a topic resource in a serialized topic map:
(a) When a topic map is represented in a serialized form for interchange, each topic
is assigned a URI identifier that is unique across that topic map.
(b) These URIs are used principally for deserializing references between topics.
(c) Such identifiers are referred to as source locators.
(2) Identity as a human-readable label:
(a) Names act as labels for human consumption:
(i) Can be either text or a reference to some non-textual representation
(for example, an icon, a sound clip, an animation clip, and so on.).
(a) Can have any number of topic names.
(ii) The scope mechanism allows for the case of homonyms (where a single word
is used to refer to two or more different concepts).
(3) Identity by reference:
(a) When a topic is used to represent a resource that already has its own unique URI,
that URI can be used as part of the identity of the topic.
(b) Known as a subject locator in the topic map standard.
(4) Identity by description:
(a) Topics can be used to represent a concept that does not have its own unique URI:

RTO-TR-MSG-058 E - 13
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

(i) Many of the things that a topic can represent could never have a unique URI
because they are not things that a computer can resolve a reference to:
(a) For example, a person may have any number of database records about
himself or online biographies or pictures, but none of those addressable
resources are the person – they are merely some form of descriptor for
the person.
(ii) The resource that the subject identifier resolves to is known as a subject
indicator.
(b) Subject identifiers (URIs) identify the subject the topic is about:
(i) The key difference between a subject identifier and subject locator is that a
subject identifier requires human interpretation of a resource to determine the
concept that a topic represents, whereas a subject locator simply points to the
concept that the topic represents.
III. Scope:
A. Used in the topic map standard to refer to a constraint or a context in which something is said
about a topic. The way in which such statements about topics are made is by adding a name to the
topic; specifying an occurrence for a topic; or creating an association between topics (in which
case the statement applies to all of the topics in the association):
1. Can be attached to any name, occurrence, or association in a topic map to qualify a statement,
but still express it.
2. Is defined by a collection of topics that can be assigned to a name, an occurrence, or an
association. The default scope (where no set is assigned) is known as the unconstrained scope
and simply means that the name, occurrence, or association is always valid.
IV. Topic Merging:
A. In any given topic map, each subject described by the topic map must be represented by one and
only one topic in the topic map. This means that it is the responsibility of the topic map processor
to attempt to identify the situation in which two topics represent the same subject and to process
them so that only one topic remains. This is the process of merging.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
N/A N/A N/A N/A N/A N/A

E.2.13 Method: Operational Conceptual Modeling Language (OCML) [13]

Operational Conceptual Modeling Language has the following attributes:
• Description at: http://technologies.kmi.open.ac.uk/ocml/;
• Allows the specification and operationalization of functions, relations, classes, instances and rules; and
• Includes mechanisms for defining ontologies and problem solving methods, the main technologies
developed in the knowledge modeling area.

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:

E - 14 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

I. Relations:
A. Allow the OCML user to define labeled n-ary relationships between OCML entities.
II. Functions:
A. Defines a mapping between a list of input arguments and its output argument.
III. Classes.
IV. Instances.
V. Rules:
A. Forward: forward rule comprises zero or more antecedents and one or more consequents.
B. Backward.
VI. Procedures:
A. Define actions or sequences of actions which cannot be characterized as functions between input
and output arguments.
VII. Constructs:
A. Functional:
1. Specifies an object in the current domain of investigation:
a) Can be:
(1) Constant.
(2) Variable.
(3) String.
(4) Function application.
(5) Can also be constructed by means of a special term constructor.
B. Control terms:
1. Specify actions.
2. Describe the order in which actions are executed.
3. Can be expressed as:
a) Sequential.
b) Iterative.
c) Conditional control structures.
C. Logical expressions.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Classes Procedures Relations
Instances Functions
Functional Rules
construct
Control terms

E.2.14 Method: Object Process Methodology (OPM) [14]

See for reference: http://www.opcat.com/products_opm.htm.

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:

RTO-TR-MSG-058 E - 15
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

I. Object Process Diagrams (OPD):

A. Formal graphic model.
II. Object Process Language (OPL):
A. Natural language (English sub-set/controlled vocabulary) generated in RT in response to
human input in OPD.
B. OPD are developed and then OPL is generated from it.
III. Three building blocks:
A. Objects:
1. Things that exist.
2. Physical or informational things:
a) What are the states of the object?
b) Which processes create, destroy, and modify the object?
c) Which processes does it instrument?
B. Processes:
1. Things that transform objects by changing their states or creating or consuming objects.
2. Processes are peers of Objects.
3. Objects may contain processes and processes may contain objects:
a) Which objects instrument and initiate the process?
b) Which of the three functionalities does it fulfill: create, destroy, or modify the states
of an object?
C. States:
1. Lower level entities since states are expressed inside of objects:
a) What object does it belong to?
b) Which process triggered the change of the state?
c) What are the source and destination states?
IV. Two parts of OPM ontology:
A. Entities.
B. Links, which can be:
1. Structural – express static, time-independent relations between pairs of entities.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Object Processes Processes States

E.2.15 Method: Object-Role Modeling (ORM) [15]

Object Role Modeling may be characterized as follows:
• Early versions of object role modeling were developed in Europe in the mid-1970s (for example, binary
relationship modeling and Natural Language Information Analysis Method (NLIAM)). The version
discussed here is based on the author’s formalization of the method, and incorporates extensions and
refinements arising from research conducted in Australia and the United States. The associated language
Formal Object-Role Modeling Language (FORML) is supported in Microsoft® Visio® for Enterprise
Architects (VEA), part of Visual Studio® .NET Enterprise Architect.

E - 16 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

• The information system’s life-cycle typically involves several stages: feasibility study; requirements
analysis; conceptual design of data and operations; logical design; external design; prototyping; internal
design and implementation; testing and validation; and maintenance. ORM’s Conceptual Schema Design
Procedure (CSDP) focuses on the analysis and design of data. The conceptual schema specifies the
information structure of the application: the types of fact that are of interest; constraints on these
facts; and perhaps the derivation rules for deriving some facts from others.

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
Conceptual schema

E.2.16 Method: UML [16]

Properties educed from examination of the standard in accordance with the strategy outlined in Section E.1
above include the following:
I. Structure Diagrams:
A. Class Diagram:
1. Shows how the different entities (people, things, and data) relate to each other.
B. Object Diagram.
C. Component Diagram:
1. A physical view of the system, meant to show the dependencies that the software has on the
other software components.
D. Composite Structure Diagram.
E. Package Diagram.
F. Deployment Diagram:
1. Shows how a system will be physically deployed in the hardware environment.
II. Behavior Diagrams:
A. Use Case Diagram:
1. Illustrates a unit of functionality provided by the system.
B. Activity Diagram:
1. Show the procedural flow of control between two or more class objects while processing an
activity.
C. State Machine Diagram:
1. Models the different states that a class can be in and how that class transitions from state to
state.
III. Interaction Diagrams:
A. Sequence Diagram:
1. Shows a detailed flow for a specific use case or even just part of a specific use case.
B. Communication Diagram.
C. Timing Diagram.
D. Interaction Overview Diagram.
IV. Other important concepts:
A. A UML profile is a specification that does one or more of the following:
1. Identifies a sub-set of the UML meta-model.

RTO-TR-MSG-058 E - 17
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

2. Specifies “well-formedness rules” beyond those specified by the identified sub-set of the
UML meta-model.
3. “Well-formedness rule” is a term used in the normative UML meta-model specification to
describe a set of constraints written in UML’s Object Constraint Language (OCL) that
contributes to the definition of a meta-model element.
4. Specifies “standard elements” beyond those specified by the identified sub-set of the UML
met-model.
5. “Standard element” is a term used in the UML meta-model specification to describe a
standard instance of a UML stereotype, tagged value or constraint.
6. Specifies semantics, expressed in natural language, beyond those specified by the identified
sub-set of the UML meta-model.
7. Specifies common model elements, expressed in terms of the profile.
B. Stereotype:
1. A stereotype defines how an existing meta-class may be extended, and enables the use of
platform or domain specific terminology or notation in place of, or in addition to, the ones
used for the extended meta-class.
2. A stereotype denotes a variation on an existing modeling element with the same form but with
a modified intent. Stereotypes are effectively used to extend the UML in a consistent manner.

Language Unit Purpose

Actions (Foundation) modeling of fine-grained actions
Activities Data and control flow behavior modeling
Classes (Foundation) modeling of basic structures
Components Complex structure modeling for component technologies
Deployments Deployment modeling
General Behaviors (Foundation) common behavioral semantic base and time modeling
Information Flows Abstract data flow modeling
Interactions Inter-object behavior modeling
Models Model organization
Profiles Language customization
State Machines Event-driven behavior modeling
Structures Complex structure modeling
Templates Pattern modeling
Use Cases Informal behavioral requirements modeling

A table compiling the canonical allocation of conceptual components evident in the standard to the vernacular
conceptual model characteristics reserved words, therefore, is:

E - 18 RTO-TR-MSG-058
 ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

Using An Actor Actuates Composed of Directed by Richly Described

Behaviors Events Activities Controls by Information
General Classes Actions Behavior diagrams Structure diagram
behaviors – Use case – Class diagram
diagram
Activity diagram
State machine
diagram
Interactions Activities Interaction
diagrams
– Sequence
diagrams
– Communications
diagrams
– Timing diagram
– Interaction
overview diagram
State machines Profiles
Stereotypes
Use cases

E.3 REFERENCES
[1] Simulation Interoperability Standards Organization, Guide for Base Object Model (BOM) Use and
Implementation, SISO-STD-003.1-2006, 31 March 2006. http://www.boms.info/standards.htm, Retrieved
18 September 2009.

[2] Mojtahed, V., Andersson, B., Kabilan, V. and Zdravkovic, J., “BOM++, a Semantically Enriched BOM”,
Spring Simulation Interoperability Workshop, 2008.

[3] White, S., “Introduction to BPMN”, IBM Corporation, 2006.

[4] Karr, D., “Conceptual Modeling in OneSAF Objective System (OOS)”, http://tinyurl.com/natrw6, 2005.

[5] Schreiber, G., Akkermans, H., Anjewierden, A.A., de Hoog, R., Shadbolt, N.R., Van de Velde, W. and
Wielinga, B.J., “Knowledge engineering and management: The Common KADS methodology”, Cambridge
Massachusetts, MIT Press, 2000.

[6] Mojtahed, V., Garcia Lozano, M., Swan, P., Andersson, B. and Kabilan, V., “DCMF – Defence
Conceptual Modeling Framework”, Technical Report FOI-R–1754-SE, Swedish Defence Research
Agency, ISSN 1650-1942. 2005.

[7] Mojtahed, V., Tjörnhammar, E., Zdravkovic, J. and Khan, A., “The Knowledge Use in DCMF”, Technical
Report FOI-R–2606-SE, Swedish Defence Research Agency, ISSN 1650-1942. 2008.

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

RTO-TR-MSG-058 E - 19
ANNEX E – EXPLANATION OF FUNDAMENTAL
CONCEPTS FOR CONCEPTUAL MODEL FRAME-OF-REFERENCE

[9] Chen, P., “The Entity-Relationship Model – Toward a Unified View of Data”, ACM Transactions on
Database Systems, Vol. 1, No. 1, March, pp. 9-36, 1976.

[10] Karagöz, A., “A Framework for Developing Conceptual Models of the Mission Space for Simulation
Systems”, Unpublished doctoral dissertation, Middle East Technical University, Ankara, 2008.

[11] http://mindmappingsoftwareblog.com/basic-ordering-ideas/, Retrieved 24 September 2009.

[12] Ahmed, K. and Moore, G. (2005): An Introduction to Topic Maps, Microsoft Corp., http://www.topic
maps.org/, Retrieved 24 September 2009.

[13] Domingue, J., Motta, E. and Garcis, O., “Knowledge Modelling in WebOnto and OCML: A User Guide”,
v. 2.4, Open University and Knowledge Media Institute, 1999.

[14] Liu, H. and Gluch, D., “Conceptual Modeling with the Object-Process Methodology in Software
Architecture”, JCSC No. 19 V. 3, 2003.

[15] Halpin, T., “Object-Role Modeling (ORM/NIAM)”, found in Handbook on Architectures of Information
Systems, Eds. P. Bernus, K. Mertins and G. Schmidt, Springer-Verlag, Berlin, Germany, 1998.

[16] http://www.uml.org/, Retrieved 2 October, 2009.

E - 20 RTO-TR-MSG-058
 Annex F – STANDARDS

F.1 INTRODUCTION
As indicated in Section 3.2.6 “Standards Review and Evaluation” of the accompanying text, the Team invested
significant effort reviewing standards potentially relevant to conceptual modeling in hopes of leveraging existing
standards and standards types to the greatest extent possible in developing the best-practice guidance contained
herein.

An indication of the scope and evaluative interest in such standards is provided in Table F-1 following. Based
on an initial review of the standards indicated therein, the Team selected nineteen (19) standards of particular
interest to conceptual modeling and for further analysis and commentary.

Table F-1: Standards with Applicability in NATO Modeling and Simulation Domain.
Standard Development

Execute Application
and Prepare Outputs
Perform Conceptual

Develop Simulation

Develop Federation
Define Application

Plan, Integrate and

Design Simulation
Design Federation

Analyze Data and

Evaluate Results
Test Application
Functional Area
STANDARD

Organization

Objectives

Analysis
Status

Carnagie Business
CMMI Mellon Published Process X X
University Management
Conceptual
BOMs SISO Published X X X X
Modeling
OneSAF Conceptual
CML Published X X X X X X
PMO Modeling
Conceptual
IDEF0 IEEE Published X
Modeling

Conceptual
IDEF5 KBS Published X X X X X
Modeling

OWL-Web
Conceptual
Ontology W3C Published X
Modeling
Language
Simulation
Conceptual
Conceptual SISO Concept X X X
Modeling
Modeling RP
Conceptual
UML OMG Published X X X X
Modeling
Open Data
DCMF Published X X X
Source Engineering
Data
IDEF1X NIST Published X X X
Engineering

RTO-TR-MSG-058 F-1
ANNEX F – STANDARDS

Standard Development

Execute Application
and Prepare Outputs
Perform Conceptual

Develop Simulation

Develop Federation
Define Application

Plan, Integrate and

Design Simulation
Design Federation

Analyze Data and

Evaluate Results
Test Application
Functional Area
STANDARD

Organization

Objectives

Analysis
Status
Data
OKBC DARPA Published X X X
Engineering
World-
Wide-Web Data
RDF Published X X X X
Consortium Engineering
(W3C)
Data
XML W3C Published X X X
Engineering
Data
C-BML SISO Draft X X X X X
Mediation
Data
CMSD SISO Draft X X X X
Mediation
Data
JC3IEDM MIP Published X X X X
Mediation
MultiGen- Data
OpenFlight Published X X X
Paradigm Mediation
Data
SEDRIS ISO Published X X X X X
Mediation
Data
DFAD U.S. DoD Published Production X X X X X
Format

Data
DTED U.S. DoD Published Production X X X X X
Format

M&S-
DEVS SISO Concept X X
Miscellaneous

M&S-
SCORM Sim SISO Concept X X X X X X
Miscellaneous

M&S-
SRML SISO Draft X X
Miscellaneous

HLA FEDEP SISO/IEEE Published M&S-Process X X X X X X X X X

SEDEP EUCLID Published M&S-Process X X X X X X X X X

F-2 RTO-TR-MSG-058
 ANNEX F – STANDARDS

Standard Development

Execute Application
and Prepare Outputs
Perform Conceptual

Develop Simulation

Develop Federation
Define Application

Plan, Integrate and

Design Simulation
Design Federation

Analyze Data and

Evaluate Results
Test Application
Functional Area
STANDARD

Organization

Objectives

Analysis
Status
Link 11 M&S-
SISO Draft X X X
Simulations Representation

Link 16 M&S-
SISO Published X X X
Simulations Representation

M&S-
MOD-5/S IFF SISO Concept X X X
Representation

M&S-
RPR FOM SISO Published X X X X
Representation

M&S-
MSDL SISO Draft X X X X X
Scenarios

M&S-
Simulation
CSPI SISO Draft X
Inter-
Operability

M&S-
Simulation
DIS SISO/IEEE Published X X X X X
Inter-
Operability

M&S-
Simulation X X
HLA SISO/IEEE Published X X X X
Inter- (OMT) (OMT)
Operability

M&S-
Simulation
TENA US DoD Published X X X X X X
Inter-
Operability

Software
CORBA OMG Published X X X X
Engineering
Software
MDA OMG Published X X X X
Engineering
Software
RUP IBM Published X X X X
Engineering
Software QA Software
IEEE Published X X
Plans (1220) Engineering

RTO-TR-MSG-058 F-3
ANNEX F – STANDARDS

Standard Development

Execute Application
and Prepare Outputs
Perform Conceptual

Develop Simulation

Develop Federation
Define Application

Plan, Integrate and

Design Simulation
Design Federation

Analyze Data and

Evaluate Results
Test Application
Functional Area
STANDARD

Organization

Objectives

Analysis
Status
Software Reuse
Software
Data Model IEEE Published X X X
Engineering
(1420)
Software
UML OMG Published X X X X
Engineering
DoD
Systems
Architecture US DoD Published X X X
Engineering
Framework
MOD
Systems
Architecture UK MOD Published X X X
Engineering
Framework
OMG/INC Systems
SysML Published X X X X
OSE Engineering
GM-V&V SISO Concept V&V X X X X X X X
REVVA1 EUCLID Published V&V X X X X X X X X X
V&V
Information ITOP Published V&V ? X X
Exchange
VV&A
Overlay to SISO/IEEE Draft V&V X X X X X X X
FEDEP
VV&A RPG US DoD Published V&V X X X X X X X X X

F.2 RELEVANT STANDARDS CHARACTERIZATION

In the tables that follow, selected standards identified in Table F-1 above are described in considerable detail.
The intention of the Task Group in providing this description is to provide users of the best-practice guidance
contained formally in Annexes G and H below to leverage to best advantage – contingent enterprise and
technical constraints and motivations – some of the several standards that are known by the Group to be relevant
to both the specification of conceptual models themselves and to the expression of best-practice within enterprise
contexts.

Standards described in detail in the tables following include:

• Based Object Model (BOM).
• Conceptual Modeling Language (CML).
• Capability Maturity Model Integration (CMMI).
• Defence Conceptual Modeling Framework (DCMF).
• Discrete Event Systems (DEVS).

F-4 RTO-TR-MSG-058
 ANNEX F – STANDARDS

• Department of Defense Architecture Framework (DoDAF).

• Generic Methodology for Verification, Validation (GM-VV).
• Integrated Definition Methods (IDEF0).
• Integrated Definition Methods (IDEF5).
• Joint Command Control Communications Information Exchange Data Model (JC3IEDM).
• Kernel Meta Meta Model (KM3).
• Model Driven Architecture (MDA).
• NATO Architecture Framework (NAF).
• Open Knowledge Base Connectivity (OKBC).
• Web Ontology Language (OWL).
• Resource Description Framework (RDF).
• Rational Unified Process (RUP).
• Systems Modeling Language (SysML).
• Unified Modeling Language (UML).

Table F-2: Based Object Model (BOM).

ATTRIBUTE COMMENTS

Organization: Simulation Interoperability Standards Organization (SISO)

The BOM is a component-based standard for describing a reusable piece part of
a federation or an individual federate. Specifically, the BOM specification offers
ontology for characterizing elements of a simulation and relationships among
conceptual entities within a simulation environment as a language neutral
interface. BOMs can be used to document the interface for one or more of the
Definition:
following piece part elements: 1) Object classes; 2) Interaction classes; 3) Patterns
of interplay; 4) State machines; and 5) Events. BOMs provide developers and users
a modular approach for defining and adding new capabilities to a federate or
federation, and in quickly composing object models such as HLA FOMs and
SOMs through BOM Assemblies.
Base Object Models (BOMs) provide a key mechanism in facilitating
interoperability, reuse, and composability. BOMs are specifically identified in the
IEEE 1516.3 HLA Federation Development and Execution Process (FEDEP) as
a potential facilitator for providing reusable model components used for the rapid
Intended Use: construction and modification of federates and federations. The open
standardization of BOM representations is considered essential for encouraging
their development, distribution and use. The BOM concept is based on the
assumption that piece-parts of simulations and federations can be extracted and
reused as modeling building-blocks or components.

RTO-TR-MSG-058 F-5
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS
The interplay within a simulation or federation can be captured and characterized
Intended Use in the form of reusable patterns. These patterns of simulation interplay are
(cont’d): sequences of events between simulation elements. The implementation of the
pattern using HLA object model constructs is also captured in the BOM.
Community Primary in Military Modeling and Simulation domain but even across government
of Usage: and non-government applications worldwide.
The BOM framework as documented in the BOM specification and the BOM
guidance document is intended to influence the following six capabilities within
the M&S community: Interoperability – The application of Extensible Markup
Language (XML) and XML Schemas prescribed for BOMs provides a mechanism
for defining and validating context, and facilitates understanding of the data being
exchanged. Furthermore, the flexibility offered by BOMs allows for greater
application of simulation interoperability within other domains. Reusability –
The Meta data cataloged within a BOM such as intent-of-use, integration history,
behavioral information, and potential visual information will facilitate greater
reuse of components. Composability – BOMs will facilitate the ability to rapidly
compose simulations and simulation environments both statically (design time)
Significant and dynamically (at run-time). Adaptability – Mega-BOMs produced by BOM
Attributes: compositions can be used to represent the standard data exchange interface for
systems and simulations. Aggregation – The application of BOMs can be used for
supporting two types of aggregation: Pattern Aggregation and Entity Aggregation.
Pattern Aggregations reflect the coupling of interface groupings that can be
identified prior to an exercise. Entity Aggregations reflect the coupling of multiple
entities into a single inclusive group, which can be accomplished during a
Federation Execution (FEDEX). Multi-resolution Models – At the Federate
Capability Level, BOMs can be used to represent the behavior states needed for
modeling a conceptual entity of one or more patterns of interplay. Federates can
choose from an assortment of BOM Component Implementations (BCIs) of
varying resolutions which can be swapped out dynamically during an exercise,
assuming the proper precautions are taken to ensure validity and consistency.
Relevance to See FOI-R—2363—SE (BOM and DCMF), BOM++, a Semantically Enriched
Our Work: BOM.
High:
ΠIts Meta data port (Model Identification) can be re-used.
Relevance of Form
for Our Product ΠBOM fulfils some of basic requirements on a Conceptual model such as; reusability
Specification: composability and syntactic interoperability.
ΠBOM structure and mechanism (like pattern of interplay and state Machine)
as well as BOM Assembly can be source of inspiration.
http://www.boms.info/. “Simulation Interoperability Standards Organization
(SISO) Base Object Model (BOM) Template Specification SISO-STD-003-2006”,
References:
31 March 2006 Copyright © 2004 – 2006 by the Simulation Interoperability
Standards Organization, Inc., P.O. Box 781238, Orlando, FL 32878-1238, USA.

F-6 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS
Simulation Interoperability Standards Organization (SISO) Guide for Base Object
Model (BOM) Use and Implementation SISO-STD-003.0 DRAFT-V0.12,
26 October 2005, Prepared by: SISO Base Object Model Product Development
References
Group Keywords: Automation, Behavior, BOM, Components, Composability,
(cont’d):
Conceptual Model, FEDEP, Interoperability, Meta data, Patterns, Requirements,
Reuse Copyright © 2004 – 2005 by the Simulation Interoperability Standards
Organization, Inc., P.O. Box 781238, Orlando, FL 32878-1238, USA.

Table F-3: Conceptual Modeling Language (CML).

ATTRIBUTE COMMENTS

Organization: U.S. Army, OneSAF Program

Definition: CML is the OneSAF conceptual modeling language.
CML is used within the OneSAF development enterprise as an implementation
Community independent and computationally amenable tool to increase efficiency and security
of Usage: of transformation of information about the real world into simulation
computational structures.
CML consists of meta-class components and inter class relationships which, when
instantiated, constitute a pictorial and text specification of the military mission
space conceptual model. The existence of well-defined component class types,
and intended interclass relationships provides a meta model, whereby the
conceptual model practitioner may instantiate conceptual model artefacts that will
be reduced to computational implementation in accordance with the pre-existing
Significant correlations between conceptual model components and computational component
Attributes: artefacts. CML class and relationships were expressly selected to facilitate
representation of military mission-space scenarios. The use of CML has been
observed to yield the following benefits: “1) improves KAKE and developer
productivity; 2) provides a common frame of reference for all shareholders;
3) minimizes requirements creep by limiting KAKE to relevant issues; and
4) provides a sufficiently detailed description of the modeling solution to minimize
misinterpretations and reinterpretations of the requirements.”
CML and its associated employment process are ostensibly highly relevant to the
subject effort, having been specifically designed to serve for conceptual model
specification for military models and simulations. The language further has been
used and tailored/optimized to this purpose in context of the OneSAF simulation
development environment. Specializations within CML related to capturing
Relevance to
military mission space representation are specifically relevant to the current work.
Our Work:
On the other hand, language features and associated process specializations that
are peculiar to OneSAF simulation representation and/or implementation paradigm
(such as simulation time advance mechanization, data modularization protocols,
object class declarations and visibility, etc.) are likely not suitable for the present
effort.

RTO-TR-MSG-058 F-7
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS
(NOTE that notwithstanding the assertion that CMS is “implementation
Relevance to Our
independent”, several features – many implicit in the CML itself – seem to entail
Work (cont’d):
implementation-specific presumption.)
Notational form for within CML is suggestive and relevant in many ways for
military mission space representation. On the other hand, the notation is not either
an industry standard nor does it evidently support translation to alternative
notations. It is, in fact particularly specific to time management, data flow,
Relevance of Form
and control flow specifically elected from a wider range of options for use in
for Our Product
OneSAF simulation implementation. The notation as -is is not suitable for use in
Specification:
the documents resulting from this task. It may be appropriate and sufficient as a
notation for implementation of the best-practice guidance being developed,
if-and-only-if its intended application environment is sufficiently similar to that
of OneSAF.
“Conceptual Modeling in OneSAF Software Development”, briefing provided by
References:
Greg Tackett in cooperation with the U. S. Army OneSAF Program Office.

Table F-4: Capability Maturity Model Integration (CMMI).

ATTRIBUTE COMMENTS

Organization: Carnegie Mellon, Software Engineering Institute (SEI)

CMMI is not a process (M1 level). It is a process improvement approach
Definition: (M2 level) that provides organizations with the essential elements of effective
processes.
It can be used to guide process improvement across a project, a division, or an
entire organization. CMMI helps integrate traditionally separate organizational
functions, set process improvement goals and priorities, provide guidance for
quality processes, and provide a point of reference for appraising current
processes. Two models exist. The CMMI for Development is a reference model
that covers the development and maintenance activities applied to both products
Intended Use: and services. Organizations from many industries, including aerospace, banking,
computer hardware, software, defence, automobile manufacturing, and
telecommunications, use CMMI for Development. This document is a reference
model that covers the acquisition of needed capabilities. Capabilities are acquired
in many industries, including aerospace, banking, computer hardware, software,
defence, automobile manufacturing, and telecommunications. All these industries
can use CMMI-ACQ.
It is difficult to quantify how many organizations have adopted CMMI because
Community
any organization can use CMMI for process improvement without having to
of Usage:
register with the SEI or otherwise identify themselves to the public.

F-8 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

However, there have been over 55,000 people who have attended Introduction to
Community of CMMI training, and CMMI has been adopted in many industries (e.g., software,
Usage (cont’d): finance, and manufacturing) in countries around the world (e.g., United States,
Australia, Japan, Brazil, and Russia).
The CMMI model is composed of these main components: process areas, goals
and practices. It also includes other components such as notes, examples,
amplifications (domain specific notes and examples) and references. Some
components are required, other are expected or informative. A process area is a
cluster of related practices in an area that, when implemented collectively, satisfy
a set of goals considered important for making improvement in that area.
A specific goal describes the unique characteristics that must be present to satisfy
the process area. Generic goals are called “generic” because the same goal
statement applies to multiple process areas. A generic goal describes the
characteristics that must be present to institutionalize the processes that implement
a process area A specific practice is the description of an activity that is considered
important in achieving the associated specific goal. The specific practices describe
the activities that are expected to result in achievement of the specific goals of a
process area. Generic practices are called “generic” because the same practice
Significant applies to multiple process areas. A generic practice is the description of an
Attributes: activity that is considered important in achieving the associated generic goal.
A generic practice elaboration appears after a generic practice in a process area to
provide guidance on how the generic practice should be applied uniquely to the
process area. A sub-practice is a detailed description that provides guidance for
interpreting and implementing a specific or generic practice The typical work-
products are sample output from a specific practice. Levels are used in CMMI to
describe an evolutionary path recommended for an organization that wants to
improve the processes it uses to develop and maintain its products and services.
CMMI supports two representations. The staged representation (maturity levels)
offers a systematic way to approach process areas one stage at a time. Achieving
each stage ensures that an adequate process infrastructure has been laid as a
foundation for the next stage. In the continuous representation (capability levels),
an organization can choose to improve different processes at different rates.
A CMMI level can be officially certified following a rating activity of appraisals.
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI)
provides benchmark quality ratings relative to CMMI models.
Since the CMMI models have been designed in a generic manner to improve
processes, some of its components (process areas, goals, practices, etc.) are
Relevance to
directly applicable to our conceptual modeling process guidelines. The CMMI for
Our Work:
Development is privileged because M&S is a developmental activity within the
targeted organizations.

RTO-TR-MSG-058 F-9
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

The notion of maturity levels is also very useful to scale the Conceptual Model
Relevance to Our process specification to various organizational needs and to guide them toward our
Work (cont’d): strategic vision (Level 5). This representation is privileged because it is easier to
understand.
Relevance of Form The M2 level of language of the CMMI makes it appropriate to serve as an
for Our Product example for our Conceptual Model Process Spec.
Specification:
http://www.sei.CMu.edu/CMmi/, CMMI for Development, Version 1.2, CMMI
References:
Product Group, Technical Report, CMU/SEI-2006-TR-008, August 2006, 573 pp.

Table F-5: Defence Conceptual Modeling Framework (DCMF).

ATTRIBUTE COMMENTS

Organization: FOI – Swedish Defence Research Agency

DCMF is a framework developed to understand and describe activities and
processes in military operations. These descriptions will then be the foundation for
developing conceptual models in a formal way. Those models are primarily used
for simulation model development.
Definition:
The framework consists of a number of components which together support
developers in the task of creating high quality conceptual models out of
unstructured data. Examples of Framework’s components are a specified modeling
process, ontologies and specifications of the format of the models.
The overall objectives for DCMF is to capture authorized knowledge of military
operations; to manage, model and structure the obtained knowledge in an
unambiguous way; and to preserve and maintain the structured knowledge for
future use and reuse. The premier aim of doing so is to enable semantic and
substantive interoperability of the future simulation models built on these
Intended Use: descriptions.
Another long-term goal with DCMF is reusability which will reduce costs and
enhance the quality in the development of conceptual models. Our vision is that
DCMF will evolve enough to become a standard for the development of simulation
models within the Swedish Armed Forces.
Community FOI and Swedish Armed Forces.
of Usage:
MSMs – Mission Space Models – which are the final result of the DCMF process,
Significant and the kernel of both DCMF and CMMS they are defined as simulation and
Attributes: implementation independent functional descriptions of the real-world processes,
entities, and environmental factors associated with a particular set of missions.

F - 10 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

These descriptions would be able to serve as a frame of reference for simulation

development by capturing the basic information about the important entities
involved in any mission, and their key actions and interactions. It is to say these
are for all stakeholders in the M&S process a common description of what is to be
simulated and serve as a bridge between the military experts and the developers.
The military experts own the mission process and are an authoritative source when
validating the content of the conceptual models. MSMs also serve as a platform for
communication among stakeholders working with these simulation models.
Already within the Modeling and Simulation Master Plan (MSMP) developed by
Significant the US DoD the CMMS concept was presented as an essential requirement for
Attributes interoperability and reusability of knowledge in the military domain. On top of
(cont’d): that the DCMF initiative has tried to put some more concrete requirements.
To summarize, the DCMF requirements for how the final conceptual models
should be are as follows:
• Well documented;
• Readable and usable for a person as well as a machine;
• Composable;
• Traceable the whole way back to the original sources; and finally
• Useable as a basis for simulation models.
The framework provides:
• A definition for a Conceptual Model;
• A process for delivering high quality Conceptual Models;
Relevance to
• A structure/template for the procedure Conceptual Models;
Our Work:
• A formalism over Conceptual Models;
• A list of potential stakeholder; and
• A list of different roles and their interactions.
Relevance of Form At least a source of inspiration and an example of the way we can develop the
for Our Product Defence Conceptual Modeling Framework.
Specification:
FOI-R—1754--SE.
References: FOI-R—2362--SE.
05F-SIW-038.

Table F-6: Discrete Event Systems (DEVS).

ATTRIBUTE COMMENTS

Organization: Arizona Center for Integrative Modeling and Simulation (ACIMS)

RTO-TR-MSG-058 F - 11
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

Discrete Event Systems (DEVS) formalism specification is a notation language

Definition:
(M1 level) specific to discrete event models.
Intended Use: EVS is to be used as a standard notation for discrete event system Modeling.
Community Discrete event system modellers.
of Usage:
Significant The DEVS model components are: inputs, outputs, states and events.
Attributes:
DEVS is not directly applicable to MSG-058 work because it specifies a Modeling
language (M1 level) instead of providing guidance on how to specify a language.
Relevance to Furthermore, it is specific to the discrete event formalism, which makes it a
Our Work: Modeling language of a lower level of abstraction that is already well defined and
outside the scope of the Task Group. However, DEVS could be stated as an
example of well-known low-level conceptual modeling language.
Relevance of Form Due to its scoped target, the DEVS specification can be very formal. Its form is not
for Our Product appropriate to the MSG-058 product specification.
Specification:
ACIMS – www.acims.arizona.edu.
References:
DEVS Standardization Group – http://www.sce.carleton.ca/faculty/wainer/standard/.

Table F-7: Department of Defense Architecture Framework (DoDAF).

ATTRIBUTE COMMENTS

Organization: DoD U.S.

Definition: Department of Defense Architecture Framework.
The DoDAF defines a standard way to organize an Enterprise Architecture (EA)
or systems architecture into complementary and consistent views. All major U.S.
Government Department of Defense (DoD) weapons and information technology
system procurements are required to develop and document an EA using the views
prescribed in the DoDAF. While it is clearly aimed at military systems, DoDAF
Intended Use: has broad applicability across the private, public and voluntary sectors around the
world, and represents only one of a large number of systems architecture
frameworks. It is especially suited to large systems with complex integration and
interoperability challenges, and is apparently unique in its use of “operational
views” detailing the external customer’s operating domain in which the developing
system will operate.
Community All major U.S. Government Department of Defense (DoD) procurements.
of Usage:

F - 12 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

DoDAF views are organized into four basic view sets:

• Overarching All View (AV);
• Operational View (OV);
• Systems View (SV); and
Significant
Attributes: • Technical Standards View (TV).
It does not prescribe a modeling language (e.g., UML).
April 23, 2007: Version 1.5 was released, ‘Volume I: Definitions and Guidelines’
(46 pages), ‘Volume II: Product Descriptions’ (284 pages), and ‘Volume III:
Architecture Data Description’ (223 pages).
Framework provides a potential definition for a conceptual model. It contains:
• An overall, high-level scenario (OV-1) – includes scope, purpose;
• Connectivity between and within systems (OV-2);
Relevance to • Information exchanged during system connectivity (OV-3);
Our Work: • Systems used by the organizations to perform the activities (OV-3);
• Organizations performing the activities (OV-4);
• Activities performed in the scenario (V-6); and
• Data elements contained in information exchanges (OV-7).
The Task Group did not employ DoDAF schemas explicitly in its product
specification on the grounds that while the DoDAF views, usage, and associated
tools may well support practitioner’s needs, the approach is inherently specific
Relevance of Form
with respect to representational schemas required, and peculiar in its endorsement
for Our Product
by one Member Nation represented on the Task Group. The degree to which
Specification
practitioners following the best-practice guidance herein use DoDAF conventions
is considered elective particularly with respect to the consequences of their efforts
and the nature of military (or other) simulations’ conceptual models.
DoDAF Promulgation Memo Feb 9, 2004 – DODAF Policy Directive mandates
use, all Architectures approved after 12/01/03 must be DODAF compliant.
http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_I.pdf, DoDAF 1.5
Volume 1] – Provides definitions, guidelines, background material.
http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_II.pdf, DoDAF 1.5
References: Volume 2] – Describes each architecture product.
http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_III.pdf, DoDAF 1.5
Volume 3] – Provides the architecture data description. DoDAF 1.0 Deskbook –
Provides supplementary “how to” information relating to architectures. The
DODAF architecture documents were updated on April 23, 2007 to version 1.5.
Currently the Deskbook, which is from February 9, 2004, has not been updated.

RTO-TR-MSG-058 F - 13
ANNEX F – STANDARDS

Table F-8: Generic Methodology for Verification and Validation (GM-V&V).

ATTRIBUTE COMMENTS

Organization: NMSG-073
Definition: Standards: GM-VV to support acceptance of Models, Simulations, and Data.
The GM-V&V aims to provide a common generic framework for making formal
and well-balanced acceptance decisions on a specific usage of models, simulations
(both legacy and new development) and data. Moreover, the GM-V&V comprises
of methods, practices and techniques that capture the interplay between the
allocation of V&V resources (costs, etc.), stakeholders’ needs, and M&S usage
risks in decision-making. The GM-V&V is based on a three pillar-view; product,
process and organization. The objective of a GM-V&V based project is to make
well-informed acceptance decisions on a specific usage of a model, simulations
or data based upon a precise and formal argumentation. GM-V&V adopts a goal-
driven approach to derive acceptance criteria from the stakeholders’ purpose,
and subsequently derives evidence criteria and associated tests from those
acceptance criteria. This goal-driven approach is considered in a context of the
M&S system intended use, development, use-risk, V&V cost-benefits and project
constraints. The goal-based hierarchical derivation of criteria is on the one hand
well suited for use in compliance with (an adapted) ISO/IEC 9126, and on the
other hand clearly focuses on the special elements needed for measuring the
quality of the Modeling part. The hierarchical derivation starts with the goal to
show that the Conceptual Model provides utility for its use in the development of
Intended Use:
an end-product. From that goal other utility type of goals can be derived, which
can also be further broken down into validity goals, related to the Modeling
abstractions, and correctness goals, related to the implementation of needed
Conceptual Model views. Some of the utility and correctness criteria are covered
by ISO/IEC 9126, others must be found elsewhere such as in [Lindland], [Pace] or
[Teeuw] The validity criteria will be highly domain and application dependent and
must thus be derived for each Conceptual Model anew until domain/application
specific referents are constructed. After the criteria have been defined test must be
defined and comparison material made available in order to produce evidence.
The tests are for conceptual models often executed in the form of literature
comparisons, comparisons with existing data on the same domain or problem and
often it will be the collection of expert opinion. After collection of evidence it is
“summed up” as a V&V Claim Network to the level of the top goal. If the top
claim is equal to the top goal, fitness for purpose of the Conceptual Model is
shown. If this is not the case the culprit(s) can be found by tracing back from the
top claim via the claim hierarchy to evidence that indicate failed criteria and up the
goal hierarchy to find for which purposes the Conceptual Model can not be proven
to be good.
Community Modeling & Simulation.
of Usage:
Significant Systematic guidance for V&V.
Attributes:

F - 14 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

Below mappings are provide between the GM-V&V and the guidance in this
report.
Mapping of Conceptual Model processes/products/roles to GM-V&V is shown in
the tables below.
Mapping of Roles Defined in this Report to the Roles Defined in GM-V&V.
NMSG-058 GM-V&V
Initiator/Sponsor/Client VV&A Sponsor
M&S Project Manager
Custodian/Administrator
Controller/VV&A Agent VV&A Project Manager, Acceptance
Leader, V&V Leader, V&V Implementers
Consumers / Conceptual Model VV&A Problem Owner
Users
Mapping between GM-V&V Processes Steps and the Process Activities Described
in this Report.
NMSG-058 GM-V&V
PP1 – Initiate Conceptual Model VV&A Requirements Definition Process
Relevance to Development VV&A Requirements Analysis Process
Our Work: PP2 – Define Requirements and Partial:
Analyze Knowledge Needs for the V&V Design Process
Conceptual Model
V&V Implementation Process
V&V Integration Process
PP3 – Acquire Mission Space and Partial:
Simulation Space Knowledge V&V Design Process
V&V Implementation Process
V&V Integration Process
PP4 – Design the Conceptual Partial:
Model V&V Design Process
V&V Implementation Process
V&V Integration Process
PP5 – Build the Conceptual Model Final:
V&V Design Process
V&V Implementation Process
V&V Integration Process
Acceptance Assessment Process
VV&A Transition Process

RTO-TR-MSG-058 F - 15
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

Mapping of GM-V&V “Worlds” to NMSG-058 “Spaces”.

NMSG-058 GM-V&V
Relevance to Our Mission space Real world
Work (cont’d): Mission space Problem world
Simulation space M&S world
User space Product world
Relevance of Form N/A pending completion of SISO product standard.
for Our Product
Specification
http://www.sisostds.org/StandardsActivities/DevelopmentGroups/GMVVPDGGen
References:
ericMethodologyforVVAintheM.aspx.

Table F-9: Integration Definition for Function Modeling (IDEFØ).

ATTRIBUTE COMMENTS

NIST – National Institute of Standards and Technology. In December 1993,

the Computer Systems Laboratory of the National Institute of Standards and
Organization:
Technology (NIST) released IDEFØ as a standard for Function Modeling in FIPS
Publication 183.
Process oriented function in cell (node), controls/inputs/outputs and mechanisms-
Definition:
on-arrow notation.
IDEFØ models are often created as one of the first tasks of a system development
effort. IDEFØ is useful in establishing the scope of an analysis, especially for a
functional analysis. As a communication tool, IDEFØ enhances domain expert
Intended Use: involvement and consensus decision-making through simplified graphical devices.
As an analysis tool, IDEFØ assists the modeler in identifying what functions are
performed, what is needed to perform those functions, what the current system
does right, and what the current system does wrong.
Community Systems engineers needing function or process-oriented representational notation.
of Usage:
IDEFØ is a method designed to model the decisions, actions, and activities of an
organization or system. Effective IDEFØ models help to organize the analysis of
Significant a system and to promote good communication between the analyst and the
Attributes: customer. Thus, The “box and arrow” graphics of an IDEFØ diagram show the
function as a box and the interfaces to or from the function as arrows entering or
leaving the box.

F - 16 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

To express functions, boxes operate simultaneously with other boxes, with the
interface arrows “constraining” when and how operations are triggered and
controlled. The basic syntax for an IDEFØ model is shown in the figure below.

Significant
Attributes
(cont’d):

Figure F-1: IDEFØ Box and Arrow Graphics.

The fundamentals of function-on-node and control-on-arrow notation were widely
Relevance to
and conveniently used by the Group in establishing and explaining the conceptual
Our Work:
modeling process.
While the semantics conveniently captured in the IDEFØ notation schema were
Relevance of Form carefully considered in establishing the resulting formal specification of best-
for Our Product practice process contained in Annex G; nevertheless, neither IDEFØ notation nor
Specification: tools were used to produce that guidance in order not to intimate to practitioners
that the notation per se was either required or preferentially recommended.
References: http://www.idef.com/IDEF0.htm; http://www.idef.com/pdf/idef0.pdf.

Table F-10: Integration Definition for Function Modeling (IDEF5).

ATTRIBUTE COMMENTS

Organization: Armstrong Laboratory, AL/HRGA, Wright-Patterson Air Force Base, Ohio 45433
Definition: Ontology Description Capture Method.
The IDEF5 method provides a theoretically and empirically well-grounded method
specifically designed to assist in creating, modifying, and maintaining ontologies.
Intended Use: Standardized procedures, the ability to represent ontology information in an
intuitive and natural form, and higher quality results enabled through IDEF5
application also serve to reduce the cost of these activities.

RTO-TR-MSG-058 F - 17
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

Community Systems engineers / Ontology analysts.

of Usage:
Supporting the ontology development process are IDEF5’s ontology languages.
There are two such languages: the IDEF5 schematic language and the IDEF5
elaboration language. The schematic language is a graphical language, specifically
Significant
tailored to enable domain experts to express the most common forms of
Attributes:
ontological information. The other language is the IDEF5 elaboration language,
a structured textual language that allows detailed characterization of the elements
in the ontology.
IDEF5 focuses particularly on Ontology languages. On that account it is neither as
intuitive nor as powerful as UML or other such notations in addressing the
generation of ontological descriptions per se, nor in documenting them for
persistent reference as is necessary in simulation conceptual modeling. This bias
Relevance to
and relative dislocation from the purpose of the Task Group’s scope of interest is
Our Work:
reflected in both the IDEF concepts and in its diagrammatic –notational
vocabulary. The standard was not strongly or formally employed in the Task
Group’s effort, though it might have served well enough for the subject
deliberations if its familiarity were more prevalent among team members.
The standard was not invoked explicitly in formulation of an expression of the
Relevance of Form best-practice guidance despite its ontological intentions. Whether its use in
for Our Product execution of the best-practice proffered, is left as with all other standards to the
Specification: discretion of the practitioner in context of the prevailing conceptual modeling
enterprise environment.
References: http://www.idef.com/IDEF5.htm; http://www.idef.com/pdf/Idef5.pdf.

Table F-11: Joint Command Control Communication Information Exchange Data Model (JC3IDEM).

ATTRIBUTE COMMENTS

The NATO Data Administration Group (NDAG) cooperates with the (Multi-
Organization: national Interoperability Programme) MIP’s Data Modeling Working Group
(DMWG) in building of JC3IEDM.
JC3IEDM, or Joint Command, Control and Consultation Information Exchange
Data Model is an evolution of the Command and Control Information Exchange
Definition: Data Model (C2IEDM) standard that includes joint operational concepts, just as
the Land Command and Control Information Exchange Data Model (LC2IEDM)
was extended to become C2IEDM.
The overall goal is to specify the minimum set of data that needs to be exchanged
Intended Use:
in coalition or multi-national operations.

F - 18 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS
Each NATO Nation, agency or community of interest is free to expand its own
data dictionary to accommodate its additional information exchange requirements
with the understanding that the added specifications will be valid only for the
participating NATO Nation, agency or community of interest. Any addition that is
deemed to be of general interest may be submitted as a change proposal within the
Intended Use configuration control process to be considered for inclusion in the next version of
(cont’d): the specification. The main source of information and the basis for the ontology
design and development is the MIP (Multi-lateral Interoperability Programme)
proposed standard JC3IEDM. The MIP aims to provide an assured capability for
interoperability of information to support joint military operations. Interoperability
is not envisioned merely at a data level but also at strategic, operational and
tactical level to allow proper planning and functioning of joint operations.
Community NATO North Atlantic Treaty Organisation.
of Usage:
JC3IEDM is intended to represent the core of the data identified for exchange
across multiple functional areas and multiple views of the requirements. Toward
that end, it lays down a common approach to describing the information to be
exchanged in a Command and Control (C2) environment.
• The structure should be sufficiently generic to accommodate joint, land, sea,
and air environmental concerns.
• The data model describes all objects of interest in the sphere of operations,
e.g., organizations, persons, equipment, facilities, geographic features, weather
phenomena, and military control measures such as boundaries.
• Objects of interest may be generic in terms of a class or a type and specific
in terms of an individually identified item. All object items must be classified
as being of some type (e.g., a specific tank that is identified by serial number
WS62105B is an item of type “Challenger” that is a heavy UK main battle
tank).
Significant
Attributes: • An object must have the capability to perform a function or to achieve an end.
Thus, a description of capability is needed to give meaning to the value of
objects in the sphere of operations.
• It should be possible to assign a location to any item in the sphere of
operations. In addition, various geometric shapes need to be represented in
order to allow commanders to plan, direct, and monitor operations. Examples
include boundaries, corridors, restricted areas, minefields, and any other
control measures needed by commanders and their staffs.
• Several aspects of status of items need to be maintained.
• The model must permit a description of the composition of a type object in
terms of other type objects. Such concepts include tables of organizations,
equipment, or personnel.
• The model must reflect information about what is held, owned or possessed in
terms of types by a specific object item.

RTO-TR-MSG-058 F - 19
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS
• There is a need to record relationships between pairs of items. Key among
these is the specification of unit task organizations and orders of battle.
• The model must support the specification of current, past, and future role of
objects as part of plans, orders, and events.
• The same data structure should be used to record information for all objects,
regardless of their hostility status.
• Provision must be made for the identification of sources of information,
the effective and reporting times, and an indication of the validity of the data.
The JC3IEDM is described from three different perspectives:
• Conceptual Data Model: A top, high level, Conceptual Data Model of
generalized concepts such as Actions, Organizations, Materiel, Personnel,
Features, Facilities, Locations, intended for top officers, senior commanders,
etc., who do not need to know the specific technical details of the model, but is
Significant sufficient to be aware of the different concepts and their relationships.
Attributes • Logical Data Model: Middle, Logical Data Model which is more detailed,
(cont’d): is based upon breaking down the high level concepts into specific information
that is regularly used. For example, a tank is an armored fighting vehicle that is
a piece of equipment that is a piece of materiel. It also makes implicit
knowledge explicit, like following the human reasoning patterns that a tank is a
piece of armored fighting equipment and allows command and control systems
to generalize by recognizing, for instance, that tanks are equipment. A logical
data model specifies the way data is structured with an entity-attribute-
relationship diagram and supporting documentation. At this level, technical
implementation specific details are still obscured from view. This level is
useful for middle level system analysts and domain experts.
• Physical Data Model: The third and lower most, Physical Data Model provides
the detailed specifications that are necessary to generate a physical schema that
defines the structure of a database. Mainly intended for the information system
developer. The physical data model can be seen as a traditional database
schema model, which illustrates the different logical concepts (tables), their
attributes (fields) and the relationships.
• To describe a Conceptual Model, one needs the same concepts of Objects or
Entities of interests around which the operation is focused.
• Each entity has both static characteristics as well as dynamic properties, as is
Relevance to represented by the situation concepts in the JC3IEDM.
Our Work: • Relevant if the main focus in our conceptual models is that of activities, or
Actions as proposed in the JC3IEDM as well.
• And to co relate pieces of information, to provide the context and other vital
information, a group of information packages is required as well.
Relevance of Form It depends on our chosen Conceptual models structure, content or process will
for Our Product make use of.
Specification:

F - 20 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS
http://www.mip-site.org.
http://encyclopedia.thefreedictionary.com/JC3IEDM.
References:
http://en.wikipedia.org/wiki/JC3IEDM.
FOI-R—175--SE.

Table F-12: Kernel Meta Meta Model (KM3).

ATTRIBUTE COMMENTS

Organization: FOI – Swedish Defence Research Agency

The Knowledge Meta Model (KM3), developed by the Swedish Defence Research
Institute (FOI), has its place as a tool and a language to construct well-formed
Definition:
conceptual models that are to be used successfully in simulation model and
Development.
The intention when producing the KM3 was not to construct a grand “unified
model description language”. It rather represents one possibility to capture system
structures and behavior in an object-oriented and rule-based way. The KM3 is all
of the following (in no particular order):
• The KM3 is a specification. It is a specification consisting of object-oriented
concepts, primarily aimed at capturing different dependencies in and between
activities. In this setting this means that the KM3 is a specification for the
creation of generic and reusable conceptual models of objects and processes
of (military) interest.
• The KM3 is a tool. It is a tool for structuring knowledge about objects and
Intended Use:
processes as conceptual models. The main objective of KM3 is to produce
generic templates of knowledge (MSMs, in the above list).
• The KM3 is a language. It is a common language to for different stakeholders
involved in the modeling process, to enable them to construct conceptual
models.
The KM3 is mainly used as a specification for construction of generic models,
which in turn are used to model knowledge at an instance level. KM3 is, in this
respect, a model for how to make models. A model produced using the KM3 is a
well-formed, well-understood conceptual model which in turn can be instantiated
to be used as a simulation model.
Community FOI and Swedish Armed Forces.
of Usage:
• Is an activity centric structure.
Significant • Covers static and dynamic aspects of objects in the same model.
Attributes: • Covers relations between objects.
• Captures rules of behaviour.

RTO-TR-MSG-058 F - 21
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

• A general and flexible structure and a potential candidate for Conceptual Model
Template.
• The interpreted information is subsequently transformed into a common format,
Relevance to generalized and stored as a reusable model. This common format is described by
Our Work: a Knowledge Meta Model (KM3).
• The reusable conceptual model, now called a Mission Space Model (MSM), can be
instantiated with real-world data and serve as a basic structure when performing
simulations.
Relevance of Form A source of inspiration and example of the way we can specify our Conceptual
for Our Product Models.
Specification:
FOI-R—1754--SE.
References:
05F-SIW-040.

Table F-13: Model Driven Architecture (MDA).

ATTRIBUTE COMMENTS

Organization: Object Management Group (OMG)

Model Driven Architecture (MDA) is a software development process (M1 level,
Definition: because it specifies the Modeling languages). It is the base architecture for OMG’s
software development standards, including MOF, UML, OWM and XMI.
MDA separates software business and application logic from underlying platform
technology. By leveraging OMG’s universally accepted MOF and UML standards,
the MDA allows creation of software applications that are portable across, and
interoperate naturally across, a broad spectrum of systems from embedded,
to desktop, to server, to mainframe, and across the Internet. In MDA, attention
focuses first on the application’s business functionality and behavior, allowing
stakeholders’ investment to concentrate on the aspects that critically affect core
Intended Usage:
business processes. Technical aspects, also critical but secondary to business
functions, are well handled by automated or semi-automated development tools.
MDA is always ready to deal with yesterday’s, today’s and tomorrow’s challenges
and makes it easier to integrate applications and facilities across middleware
boundaries. Domain facilities defined in the MDA by OMG’s Domain Task Forces
provide much wider interoperability by always being available on a domain’s
preferred platform, and on multiple platforms whenever there is a need.
OMG Task Forces organized around industries including Finance, Manufacturing,
Community
Biotechnology, Space technology, and others use the MDA to standardize facilities
of Usage:
in their domains.

F - 22 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

The MDA is structured around Computation Independent Model (CIM), Platform

Independent Model (PIM), Platform Specific Model (PSM) and implementations:
• The CIM represents the requirements of the system in the form of a
domain model. It is also a source of vocabulary for the other models.
The transformations from and to this model are mainly for requirements
traceability.
• The PIM describes a system without anchoring it to technology-specific
functional interfaces.
• The PSM implements in an abstract fashion the specification of the PIM using
technology-specific functionalities.
• The Implementation is the operational system.
Significant The different models are linked through automatic conversions. This improves
Attributes: traceability, consistency, uniformity and productivity. The MDA is implemented
using OMG’s software development standards. The MOF is OMG’s foundation
specification for modeling languages; MOF compliance allows UML structural
and behavioral models, and CWM data models, to be transmitted via XMI, stored
in MOF-compliant repositories, and transformed and manipulated by MOF-
compliant tools and code generators. Patterns play a critical role in most MDA-
based development projects. Successful transformation from PIM to PSM,
and from PSM to code, requires that the PIM contain enough detail to completely
guide the software tools through the process. By incorporating this detail through
the use of patterns, instead of inserting it by hand, we gain multiple benefits:
architects do less work, the resulting PIM reflects the collective wisdom of many
contributors, and the tools can work the pattern (parameterized as necessary in our
UML models) through the transformations, ultimately pulling implementation code
from a library written by experts and inserting it into the application.
The MDA process could be applied directly to M&S conceptual modeling,
i.e., that a new MOF-based conceptual model language adapted to military M&S
could be developed or an existing one could be reused (e.g., UML). However,
since the MSG-058 mandate is to provide a guidance (M2 level), proposing the
Relevance to MDA as-is would be too prescriptive. MDA could be stated as an example of a
Our Work: development process implementation leading to a high level of maturity: focus on
functionality and behavior while technical aspects are automated or semi-
automated, high maintainability and interoperability through shared domain
facilities. The notion of patterns is also desirable to apply in the MSG-058 work-
product.
The MDA philosophy (different abstraction levels linked with automatic
Relevance of Form
transformations) is applicable to the MSG-058 product specification. It has
for Our Product
influenced our strategic goal because it greatly improves the level of maturity of a
Specification:
process.
MDA – http://www.omg.org/mda/.
References:
MDA Guide Version 1.0.1, OMG, omg/2003-06-01, June 2003, 62 pp.

RTO-TR-MSG-058 F - 23
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

MOF – http://www.omg.org/mof/.
Meta Object Facility (MOF) Specification Version 1.4, OMG, April 2002, 358 pp.
UML – http://www.uml.org/.
References Unified Modeling Language Specification Version 1.4.2, OMG formal/05-04-01,
(cont’d): ISO/IEC 19501:2005(E), January 2005, 454 pp.
OMG Unified Modeling Language (UML), Infrastructure, V2.1.2, formal/2007-
11-04, November 2007, 224 pp.
OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2,
formal/2007-11-02, November 2007, 738 pp.

Table F-14: NATO Architecture Framework (NAF).

ATTRIBUTE COMMENTS

Organization: NATO, NC3A

Definition: NATO Architecture Framework is a derivative framework based on DoDAF.
• It provides guidance on describing communication and information systems
(or C3 systems) through architectures and provides the rules, guidance, and
templates for developing and presenting architecture descriptions to ensure a
common denominator for understanding, comparing, and integrating
architectures in NATO. The application of the NAF is designed to enable
architectures to contribute most effectively to acquiring and fielding cost-
effective and interoperable military capabilities.
• The ability to define views of architectural information in a more flexible way
and support Stakeholders so that extensive analysis can be made to provide
rationale for prioritization decision-making.
• A standardized way of documenting NATO-wide business processes and to
Intended Use: provide support to Capability-based planning.
• Critical support for the achievement of NNEC and NATO transformation by
facilitating the move from a system-oriented paradigm to a service-oriented
paradigm, and by identifying mechanisms to handle the complexity of the
relationships within the NATO federation of systems in a holistic manner.
• A NAF Meta-Model (NMM) and repository to enable stakeholders and users to
extract bespoke architecture information and make necessary analyses to support
development, interoperability, acquisition or technical considerations.
• A complementary tool to NATO and National programme management,
contributing to reduction in cost overruns, risk reduction, and more efficient use
of common funded budgets.

F - 24 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

Intended Use • A coherent mechanism to identify capability gaps and promote interoperability
(cont’d): across NATO, including for the critical deployed force and NRF scenarios.

Community NATO, PfP.

of Usage:

The NAF is still in development.

NAF introduces a number of new “Service Views” to support Service Orientated
Significant
Architecture.
Attributes:
It is likely that DoDAF and NAF may converge into a single or very closely
related architecture sometime in the near future.

Relevance to See DoDAF.

Our Work:

Relevance of Form See DoDAF.

for Our Product
Specification
http://194.7.80.153/website/book.asp?menuid=15&vs=0&page=volume1%2Fch03
References:
s02.html.

Table F-15: Open Knowledge Base Connectivity (OKBC).

ATTRIBUTE COMMENTS

The development of OKBC is being overseen by a working group. Richard Fikes

is the working group chair and the following six institutions are the voting
members:
• Cycorp;
• Information Sciences Institute;
Organization:
• Knowledge Systems Laboratory, Stanford;
• Science Applications International Corporation (SAIC);
• SRI International; and
• Teknowledge.
OKBC is an application programming interface for accessing knowledge bases
stored in Knowledge Representation Systems (KRSs). OKBC is being developed
Definition: under the sponsorship of DARPA’s High Performance Knowledge Base program
(HPKB), where it is being used as an initial protocol for the integration of various
technology components.

RTO-TR-MSG-058 F - 25
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

[OKBC] … provides a set of operations for a generic interface to underlying KRSs

... OKBC is complementary to language specifications developed to support
knowledge sharing. KIF, the Knowledge Interchange Format, provides a
declarative language for describing knowledge. As a pure specification language,
KIF does not include commands for knowledge base query or manipulation.
Intended Use:
Furthermore, KIF is far more expressive than most KRSs. OKBC focuses on
operations that are efficiently supported by most KRSs (e.g., operations on frames,
slots, facets — inheritance and slot constraint checking). OKBC is intended to be
well impedance-matched to the sorts of operations typically performed by
applications that view or manipulate object-oriented KRSs.
Community Knowledge management specialists.
of Usage:
OKBC specifies a knowledge model of KRSs (with KBs, classes, individuals,
slots, and facets). It also specifies a set of operations based on this model
Significant
(e.g., find a frame matching a name, enumerate the slots of a frame, delete a
Attributes:
frame). An application uses these operations to access and modify knowledge
stored in an OKBC-compliant KRS.
The current implementation of OKBC is object-oriented: methods in the
appropriate object-oriented programming language for an application are used to
implement OKBC operations. We refer to the set of methods that implement the
protocol for a particular KRS as a back end. Many OKBC operations have default
implementations written in terms of other OKBC operations; therefore, the
programmer need define only a core sub-set of all OKBC operations in order to
implement a compliant back end. These OKBC operations are called mandatory,
and they comprise the OKBC kernel. The default implementations can be
overridden within a given back end to improve efficiency. The design objectives
for OKBC are as follows. Simplicity: It is important to have a relatively simple
specification that can be implemented quickly, even if that means sacrificing
Significant
theoretical considerations or support for idiosyncrasies of a particular KRS.
Attributes:
Generality: The protocol should apply to many KRSs, and support all the most
common KRS features. For example, it should support all the knowledge access
and modification functionality that will be required by a graphical KB editor.
The protocol should not require numerous changes to a KRS for which the
protocol is implemented. That is, the protocol should not legislate the behavior of
an underlying KRS, but should serve as an interface between an existing KRS and
an application. Performance: Inserting the protocol between an application and a
KRS should not introduce a significant performance cost. Consistency:
The protocol should exhibit consistent behavior across different KRSs. That is,
a given sequence of operations within the protocol should yield semantically
equivalent results over a range of KRSs.
Relevance to OKBC is of potential use in executing any of the various knowledge collection and
Our Work: management activities cited within the best-practice process.

F - 26 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

Relevance of Form While OKBC was not used explicitly in the best-practice process specification, it is
for Our Product understood that utility may be found by the practitioner in executing the best-
Specification: practice process and in documenting the conceptual model product itself.
http://www.ai.sri.com/~okbc/.
References:
http://www.ai.sri.com/~okbc/spec.html.

Table F-16: Web Ontology Language (OWL).

ATTRIBUTE COMMENTS

Organization: W3C – Worldwide Web Consortium

“OWL is the W3C’s recommended ontology Language for representing
information on the Semantic Web. It is typically used to define an ontology for a
Definition:
particular domain. An OWL ontology is a set of axioms describing classes,
properties, and the relationships between them.” – Lacey 2005.
“The purpose of OWL is to provide a standard language for Semantic Web
information representation.” – Lacey. The W3C OWL 2 Web Ontology Language
(OWL) is a Semantic Web language designed to represent rich and complex
knowledge about things, groups of things, and relations between things.” OWL is
a computational logic-based language such that knowledge expressed in OWL can
Intended Use:
be reasoned with by computer programs either to verify the consistency of that
knowledge or to make implicit knowledge explicit. OWL documents, known as
ontologies, can be published in the World Wide Web and may refer to or be
referred from other OWL ontologies” – http://www.w3.org/TR/2009/REC-owl2-
primer-20091027/.
Data managers, web application developers, and database engineers who what to
Community leverage the power of the Semantic Web by representing their information using
of Usage: the Web Ontology Language – OWL in order to enable Semantic Web applications
and services to process and interpret content.
“OWL 2 is a language for expressing ontologies.” “OWL 2 is not a programming
language: OWL 2 is declarative, i.e., it describes a state of affairs in a logical way”
“OWL 2 is not a schema language for syntax conformance.” “OWL 2 is not a
database framework.” “OWL 2 is a knowledge representation language, designed
to formulate, exchange and reason with knowledge about a domain of interest”.
Significant
OWL assumes basic knowledge modeling practice and includes provision for
Attributes:
representation of information related to classes, properties, and individuals.
For survey of features see: http://www.w3.org/TR/2009/REC-owl2-primer-
20091027/#ref-owl-2-quick-reference. The currently most widely used OWL
editor is Protégé, a free open-source editing framework developed at Stanford
University.

RTO-TR-MSG-058 F - 27
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

By virtue of its open plug-in structure, it allows for the easy integration of special-
purpose ontology editing components. Other editors include TopQuadrant’s
commercial TopBraid Composer and the open-source systems SWOOP and NeOn-
Toolkit. There are several reasons for OWL DL which differs somewhat in terms
of coverage of the supported reasoning features. For some of these, OWL 2
conformance is currently planned and the corresponding implementations are in
progress. The Test Suite Status document lists to which extent some of the reasons
Significant
mentioned below comply with the test cases. For reasoning within OWL DL,
Attributes
the most prominent systems are Fact++ by the University of Manchester, Hermit
(cont’d):
by Oxford University Computing Laboratory, Pellet by Clark & Parsia, LLC,
and RacerPro by Racer Systems. In addition to those general-purpose reasons
aiming at supporting all of OWL DL, there are reasoning systems tailored to the
tractable profiles of OWL. CEL by Dresden University of Technology supports
OWL EL. QuOnto by Sapienza University di Roma supports OWL QL. ORACLE
11 g supports OWL RL. The open-source OWL API plays a rather prominent role
as the currently most important development tool around OWL.
The OWL standard and knowledge/concept specification schema is designed to
address the description of ontological domains. In the present work, such relevant
domains are the military mission space and simulation executive domains.
Therefore OWL is a language whose relevance to expressing the semantic content
Relevance to of military model and simulation conceptual models is direct and obvious. Further,
Our Work: toe prospect of using Semantic Web interface and communications infrastructure
in association with cloud computing techniques is highly suggestive for the present
effort. Relationship of OWL to XML is also prospectively significant for
consideration of machine readable military model and simulation conceptual
models.
Relevance of Form The notational schema manifest in OWL for ontology specification and semantic
for Our Product elaboration is effectively similar to that of UML and is manifestly suitable to the
Specification: needs for notational specification of military simulation conceptual models.
OWL: Representing Information Using the Web Ontology Language, Lee W.
References: Lacey, Trafford, Victoria, BC, Canada, 2005; and http://www.w3.org/TR/#tr_
OWL_Web_Ontology_Language.

Table F-17: Resource Description Framework (RDF).

ATTRIBUTE COMMENTS

Organization: World-Wide-Web Consortium (W3C)

“RDF is a standard model for data interchange on the Web. RDF has features that
facilitate data merging even if the underlying schemas differ, and it specifically
Definition:
supports the evolution of schemas over time without requiring all the data
consumers to be changed.”

F - 28 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS
Semantic description of data exchanged between independent users. It is not
Intended Use:
human readable.
Community Anyone who need to describe web content such that independent applications can
of Usage: discover and retrieve it.
“RDF extends the linking structure of the Web to use URIs to name the
relationship between things as well as the two ends of the link (this is usually
referred to as a “triple”). Using this simple model, it allows structured and semi-
structured data to be mixed, exposed, and shared across different applications.
Significant This linking structure forms a directed, labeled graph, where the edges represent
Attributes: the named link between two resources, represented by the graph nodes. This
graph view is the easiest possible mental model for RDF and is often used in
easy-to-understand visual explanations.” RDF is written in XML. It is designed to
be read by computers. Its basic building block is an object-attribute-value triple,
called a statement.
Relevance to May be used for representing Meta data about conceptual models.
Our Work:
The Task Group did not use RDF standard specifications or standards in framing
the best-practice guidance for military model conceptual modeling on the
Relevance of Form
assumption that our work-product would be a text document and that a practitioner
for Our Product
would leverage such relatively fundamental standards in accordance with their
Specification:
own enterprise practices in due course of developing and managing simulation
conceptual models.
http://www.w3.org/RDF/.
References: http://www.w3.org/standards/techs/rdf.
http://www.w3.org/2001/sw/.

Table F-18: Rational Unified Process (RUP).

ATTRIBUTE COMMENTS

Organization: IBM
“IBM Rational Unified Process® (RUP®) is a comprehensive process framework
Definition: that provides industry-tested practices for software and systems delivery and
implementation and for effective project management.”
“RUP promotes iterative development and organizes the development of software
Intended Use: and systems into four phases, each consisting of one or more executable iterations
of the software at that stage of development.”
Community Software developers in enterprise environments and project teams.
of Usage:
Significant Systematic, tailorable process for software development. Extensive support tools
Attributes: and training/coaching available.

RTO-TR-MSG-058 F - 29
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

Relevance to Significant software development bias but includes software system conceptual
Our Work: modeling within scope.
Relevance of Form N/A.
for Our Product
Specification
http://www-01.ibm.com/software/awdtools/rup/.
http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/12
References: 51 bestpractices_TP026B.pdf.
“Rational Unified Process, Best-Practices for Software Development Teams,
Rational Software – White Paper”, TP026B, Rev 11/01.

Table F-19: Systems Modeling Language (SysML).

ATTRIBUTE COMMENTS

The UML for Systems Engineering RFP was developed jointly by the OMG and
Organization: the International Council On Systems Engineering (INCOSE) and issued by the
OMG in March 2003
Definition: Systems Modeling Language.
The SysML is a Domain-Specific Modeling language for systems engineering.
It supports the specification, analysis, design, verification and validation of a broad
range of systems and systems-of-systems. SysML was originally developed by an
open source specification project, and includes an open source license for
distribution and use. SysML is defined as an extension of a sub-set of the Unified
Modeling Language (UML) using UML’s profile mechanism. SysML offers
system engineers several noteworthy improvements over UML, which tends to be
software-centric. These improvements include the following: SysML’s semantics
are more flexible and expressive. SysML reduces UML’s software-centric
restrictions and adds two new diagram types, requirement and parametric
diagrams. The former can be used for requirements management; the latter can be
Intended Use:
used for performance analysis and quantitative analysis. As a result of these
enhancements, SysML is able to model a wide range of systems, which may
include hardware, software, information, processes, personnel, and facilities.
SysML is a smaller language that is easier to learn and apply. Since SysML
removes many of UML’s software-centric constructs, the overall language is
smaller as measured both in diagram types and total constructs. SysML allocation
tables support common kinds of allocations. Whereas UML provides only limited
support for tabular notations, SysML furnishes flexible allocation tables that will
support requirements allocation, functional allocation, and structural allocation.
This capability facilitates automated Verification and Validation (V&V) and gap
analysis.

F - 30 RTO-TR-MSG-058
 ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

SysML model management constructs support models, views, and viewpoints.

These constructs extend UML’s capabilities and are architecturally aligned with
IEEE-Std-1471-2000 (IEEE Recommended Practice for Architectural Description
Intended Use
of Software Intensive Systems). SysML uses seven of UML 2.0’s thirteen
(cont’d):
diagrams, and adds two diagrams (requirements and parametric diagrams) for a
total of nine diagram types. SysML also supports allocation tables, a tabular format
that can be dynamically derived from SysML allocation relationships.
Community Systems Engineering.
of Usage:
The Object Management Group announced the adoption of the OMG SysML™
on July 6, 2006 and the availability of OMG SysML™ v1.0 in September 2007.
With SysML you can use Requirement diagrams to efficiently capture functional,
performance and interface requirements, whereas with UML you are subject to the
Significant limitations of Use Case diagrams to define high-level functional requirements.
Attributes: Likewise, with SysML you can use Parametric diagrams to precisely define
performance and mechanical constraints such as maximum acceleration, curb
weight, air conditioning capacity, and interior cabin noise management. UML
provides no straightforward mechanism to capture this essential performance and
mechanical information.
Relevance to SysML can be used as a conceptual model language format.
Our Work:
Relevance of Form Relatively little – See UML.
for Our Product
Specification
References: http://www.omgsysml.org/.

Table F-20: Unified Modeling Language (UML).

ATTRIBUTE COMMENTS

Organization: OMG – Object Modeling Group

Modeling notation and syntactic denotation specification created for software
Definition: development, but evolved into practical systematic, comprehensive and formal
notational method for specification of any system.
Intended Use: “... enabling object visual modeling tool interoperability.”
“The objective of UML is to provide system architects, software engineers,
Community and software systems as well as for modeling business and similar processes with
of Usage: tools for analysis, design, and implementation of software-based systems as well
as for modeling business and similar processes.”

RTO-TR-MSG-058 F - 31
ANNEX F – STANDARDS

ATTRIBUTE COMMENTS

“The modeling concepts of UML are grouped into language units. A language unit
consists of a collection of tightly coupled modeling concepts that provide users with
the power to represent aspects of the system under study according to a particular
paradigm or formalism. For example, the State Machines language unit enables
modelers to specify discrete event-driven behavior using a variant of the well-known
state charts formalism, while the Activities language unit provides for modeling
behavior based on a workflow-like paradigm. A model contains three major
categories of elements: Classifiers, events, and behaviors. Each major category
models individuals in an incarnation of the system being modeled. A classifier
describes a set of objects; an object is an individual thing with a state and
relationships to other objects. An event describes a set of possible occurrences; an
Significant
occurrence is something that happens that has some consequence within the system.
Attributes:
A behavior describes a set of possible executions; an execution is the performance of
an algorithm according to a set of rules. Models do not contain objects, occurrences,
and executions, because those things are the subject of models, not their content.
Classes, events, and behaviors model sets of objects, occurrences, and executions
with similar properties. Value specifications, occurrence specifications, and
execution specifications model individual objects, occurrences, and executions
within a particular context. The distinction between objects and models of objects,
for example, may appear subtle, but it is important. Objects (and occurrences and
executions) are the domain of a model and, as such, are always complete, precise,
and concrete. Models of objects (such as value specifications) can be incomplete,
imprecise, and abstract according to their purpose in the model.”
Highly relevant to the present work in multiple ways. First, UML is a suitable
notational schema in which to manifest, represent, and document a simulation
conceptual model itself. The notation is powerful and versatile, and it has
Relevance to extensive mechanisms for specialization to alternative representation domains.
Our Work: As far as is known, UML is sufficient (though not necessary) to specify any
simulation conceptual model envisioned by the present study. In addition, UML
might be used to document the best-practice process and intended conceptual
model work-product specification conceived by the MSG-058 Task Group.
While not used extensively within the formal simulation conceptual model process
and product specifications of Annexes G and H below or in the accompanying text
Relevance of Form of Chapters 4, 5 and 6 of the document, UML could have been used as the primary
for Our Product meta-language to provide such specifications. As a practical matter, the Task
Specification: Group felt is desirable not to adopt pre-emptively any single notational schema lest
the practitioner find himself constrained artificially to that choice. Nevertheless,
UML is a candidate for future (alternative) best-practice standards specifications.
OMG Unified Modeling Language TM (OMG UML), UML Superstructure
Specification, v2.3, May 2010.
OMG Unified Modeling Language TM (OMG UML), UML Infrastructure
References: Specification, v2.3, May 2010.
http://www.uml.org/.
http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML.

F - 32 RTO-TR-MSG-058
 Annex G – CONCEPTUAL MODELING
PROCESS ACTIVITY DESCRIPTION
Table G-1: Generic Template for Specification of Process Activity.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Step Name and Aliases <Denotative name of process step appears here.>
Process Activity Description
• Process Step Rationale / Need / <Here an account of the motivation of the subject Process Step
Motivation is provided, in order that the investment agent executing the
Process Step can have explicit record of his expected intention
in executing the subject Process Step.>
Process Activity Initiation
• Entrance Criteria <This field specifies component values of the state of the
decision problem in its entirety that are necessary and sufficient
for the subject Process Step to be begun with high probability of
successful completion.>
Process Activity Method
• Process Activity Procedure <In this field, the investment evaluation agent is provided
procedural guidance for the execution of the subject Process
Step. Note that relationships to other activities, needs for tools
or information, and expected work-products are specified in
other form records. Process Step procedure should be as nearly
as possible algorithmically prescriptive. Note however that any
procedure may entail almost arbitrary complexity and that the
procedure step in question may be replaced with defining
notation other than text.>
Inter Process Activity Relationships
• Process Activity Sequence and <Instruction cites relationships among activities. These may be
Control-Flow composition (is a part of) relationship in which one Process Step
is executed as one of several components of a composite Process
Step. Otherwise, Process Step precedence (comes-before-
relationship) and Process Step successor (comes-after-
relationship) may be designated. This latter relationship
specification may be contingent allowing programmatic
branching, loop recursion, or self repetition.>
• Process Activity Information Flow <Typically information from: a) inside the process
(endogenous) – perhaps having been developed by means of the
execution of one or another of the activities; or b) information
from outside the decision process (exogenous) may be identified
as necessary input to a Process Step.>

RTO-TR-MSG-058 G-1
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Information Flow <Alternatively information may flow out of the Process Step
(cont’d) having been generated by execution of the Process Step.
In either case it is prudent to indicate the information pool
involved as container, and the information type specification
needed or generated.>
Associated Entities
• Tools <Identify tools such as hardware or software necessary and
sufficient to complete the Process Step. In the case of M&S
investment Process Step, algorithms are likely tool-types.>
• Actor-Agents <Indicate the actor agent (individual member of one or another
stakeholder class) responsible for completion of the Process
Step. Clearly Groups or anonymous agents may be designated.
If the responsibility of members of the Group need to be
differentiated, it may be prudent to decompose the Process Step
into its component parts in order to reduce the cardinality of
agents to activities from N-to-1 to 1-to-1.>
• Information Pools <Data stores of any type containing information used as input
or generated as output from a particular Process Step. May
contain intermediate information re-used by successor activities,
or components of the process result compiled as residual
product documentation.>
• Product / Object / Artefacts <The principle intended output in any form consequent
execution of the subject Process Step. Ultimately an investment
decision, but meanwhile, information artefacts, qualifications to
be associated with the decision, or guidance as to how the
resulting decision should be pursued.>
Process Activity Completion
• Exit Criteria <This field specifies component values of the state of the
decision problem in its entirety that are necessary and sufficient
for the subject Process Step to be considered finished with high
probability of successful completion.>

G-2 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Table G-2: Conceptual Model Process Activity 1.1 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA1.1 – Identify and Map Stakeholder Responsibilities.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to produce PA1.1 – Stakeholder
Motivation Descriptions which are used to derive conceptual model
requirements and conceptual model Knowledge Needs.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:
• May begin once PA1.2 – Define Purpose and Intended Use
of M&S Effort initiates.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITIES
establish the context within which the bulk of direct conceptual
model population will occur:
• Identify relevant M&S responsibilities based upon purpose
and intended use, constraints, and policies.
• Map responsibilities into stakeholder roles by category.
• Identify stakeholders by organization or name based upon
M&S purpose and intended use, constraints, and policies.
• Map roles onto individual stakeholders.
• Document results in P1.1 – Stakeholder Description.
Inter Process Activity Relationships
• Process Activity Sequence and Once initiated, may be executed concurrently with other Phase 1
Control-Flow activities, or recursively in an iterative process with activities in
other phases.
• Process Activity Information Flow Information from external pools such as listed below flow into
this process step. Information from the other three activities in
the first phase flow into this activity. All information flow out
of this activity is to the P1.1 – Stakeholder Description.
Associated Entities
• Tools No custom tools.
• Actor-Agents Producer.
• Information Pools • Points of contact lists.
• Employee roles.
• Organizational charts.

RTO-TR-MSG-058 G-3
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Information Pools (cont’d) • Personnel databases.

• Referrals.
• Resumes.
• Biographies, etc.
• Product / Object / Artefacts This Process Activity produces the P1.1 – Stakeholder
Description.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity include the following:
• All stakeholders are identified and mapped to roles and
responsibilities.

Table G-3: Conceptual Model Process Activity 1.2 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA1.2 – Define Purpose and Intended Use of M&S Effort.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to produce P1.2 – Need Statement
Motivation which is used to derive conceptual model requirements and
conceptual model Knowledge Needs.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:
• May begin upon stated or implied intent to develop a model,
simulation, or conceptual model.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITIES
establish the context within which the bulk of direct conceptual
model population will occur:
• Collect information from Information Pools below, relating
to purpose and intended use of M&S effort.
• Integrate and deconflict collected information into a self-
consistent set of descriptions of M&S purpose and use.
• Provide information to other activities in this phase.
• Translate M&S purpose and intended use into descriptions
of needs for the conceptual model.
• Document descriptions of needs for the conceptual model
in P1.2 – Need Statement.

G-4 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Inter Process Activity Relationships

• Process Activity Sequence and Once initiated, may be executed concurrently with other Phase 1
Control-Flow activities, or recursively in an iterative process with activities in
other phases.
• Process Activity Information Flow Information from external pools such as listed below flow into
this process step. No information from the other three activities
in this phase flows into this activity. Information from this
activity may flow into the other three activities in the first phase.
Information flows out of this activity to the P1.2 – Need
Statement.
Associated Entities
• Tools No custom tools.
• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• Task orders.
• Mission needs statements.
• User requirement documents.
• Requests for proposal.
• Statements of work.
• Formal or informal directives.
• Test agreements, etc.
• Product / Object / Artefacts This Process Activity produces the P1.2 – Need Statement.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity include the following:
• Purpose and intended use of M&S effort is defined.

Table G-4: Conceptual Model Process Activity 1.3 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA1.3 – Identify Constraints on the M&S Effort.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to produce P1.3 – Constraints and
Motivation Policies which is used to derive conceptual model requirements
and conceptual modeling knowledge needs.

RTO-TR-MSG-058 G-5
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Process Activity Initiation

• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• May begin once PA1.2 – Define Purpose and Intended Use
of M&S Effort initiates.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITIES
establish the context within which the bulk of direct conceptual
model population will occur:
• Collect information from Information Pools below, relating
to constraints on the M&S effort.
• Integrate and deconflict collected information into a self-
consistent set of descriptions of M&S constraints.
• Provide information to the PA1.1 activity for constraints
that impact selection of stakeholders and respective
responsibilities.
• Document Constraints for the conceptual model in
P1.3 – Constraints and Policies.
Inter Process Activity Relationships
• Process Activity Sequence and Once initiated, may be executed concurrently with other Phase 1
Control-Flow activities, or recursively in an iterative process with activities in
other phases.
• Process Activity Information Flow Information from external pools such as listed below flow into
this process step. Information from PA1.2 may flow into this
activity. Information from this activity may flow into PA1.1.
Information flows out of this activity to P1.3 – Constraints and
Policies.
Associated Entities
• Tools No custom tools.
• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• Documented resource constraints.
• Senior stakeholder preferences and requirements.
• Planning/budgeting/management limitations.
• Legacy M&S preferences and availability.
• Data availability.
• Enterprise preferences, etc.
• Product / Object / Artefacts This Process Activity contributes to P1.3 – Constraints and
Policies.

G-6 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Process Activity Completion

• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Constraints of M&S effort are defined sufficiently to
constrain the scope and content of the conceptual model.
• Sufficient contributions are made for the development of
P1.3 – Constraints and Policies.

Table G-5: Conceptual Model Process Activity 1.4 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA1.4 – Identify Mandatory Enterprise Policies.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to produce P1.3 – Constraints and
Motivation Policies which is used to derive conceptual model requirements
and conceptual model Knowledge Needs.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• May begin once PA1.2 – Define Purpose and Intended Use
of M&S Effort initiates.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITIES
establish the context within which the bulk of direct conceptual
model population will occur:
• Collect information from Information Pools below, relating
to Enterprise Policy Mandates.
• Integrate and deconflict collected information into a self-
consistent set of mandates.
• Provide information to the PA1.1 activity for mandates that
impact selection of stakeholders and respective
responsibilities.
• Document Mandates for the conceptual model in
P1.3 – Constraints and Policies.
Inter Process Activity Relationships
• Process Activity Sequence and Once initiated, may be executed concurrently with other Phase 1
Control-Flow activities, or recursively in an iterative process with activities in
other phases.

RTO-TR-MSG-058 G-7
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Information Flow Information from external pools such as listed below flow into
this process step. Information from PA1.2 may flow into this
activity. Information from this activity may flow into PA1.1.
Information flows out of this activity to P1.3 – Constraints and
Policies.
Associated Entities
• Tools No custom tools.
• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• Enterprise standard operating procedures.
• Industry and government standards.
• Enterprise executive mandates law.
• Agency regulations.
• Agency directives.
• Written policy.
• Implied enterprise mandates, etc.
• Product / Object / Artefacts This Process Activity contributes to P1.3 – Constraints and
Policies.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Enterprise Mandates are defined sufficiently to align the
scope and content of the conceptual model to mandates.
• Sufficient contributions are made for the development of
P1.3 – Constraints and Policies.

Table G-6: Conceptual Model Process Activity 2.1 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA2.1 – Identify, Analyze and Record conceptual Model
Mission and Simulation Space Requirements.
Process Activity Description
• Process Activity Rationale / Need / This activity produces the requirements that will guide the
Motivation design of the conceptual model and indirectly also the
conceptual model itself.
• Process Activity Classification May be classified depending on sensitivity of the content.

G-8 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Process Activity Initiation

• Entrance Criteria May begin as soon as some of the needs for the simulation are
clarified or some constraints or policies applicable to the
development project are defined.
Process Activity Method
• Process Activity Procedure This Process Activity will typically consist of the following
sub-activities:
• Discussions with the initiator/client in order to ensure a
mutual understanding of the client’s needs.
• Conferring with domain and M&S experts in order to refine
the needs statement into more detailed requirements. This
activity may profitably be based on descriptions of scenarios
and/or use cases.
• Consulting documents describing the mission domain.
• Review of earlier requirement documents and legacy models
in order to leverage earlier development efforts.
• Documenting the elicited requirements using simple and
unambiguous language.
Inter Process Activity Relationships
• Process Activity Sequence and This Process Activity initiates the definition phase of the
Control-Flow conceptual model development process. It may be carried out
in several passes after PA2.2 – Requirement Verification has
revealed incompleteness, incorrectness or ambiguities.
• Process Activity Information Flow The activity takes as inputs P1.2 – Need Statement and
P1.3 – Constraints and Policies and produces a preliminary
requirement specification.
Associated Entities
• Tools Requirements management tool.
• Actor-Agents Conceptual model producer, domain SMEs, M&S SMEs.
• Information Pools Legacy requirements and conceptual models, descriptions of
military equipment and documentation of military tactics,
techniques, and procedures.
• Product / Object / Artefacts This Process Activity produces a preliminary requirement
specification to be verified in PA2.2.
Process Activity Completion
• Exit Criteria All relevant requirements for the conceptual model have been
identified and documented.

RTO-TR-MSG-058 G-9
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Table G-7: Conceptual Model Process Activity 2.2 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA2.2 – Verify Requirements with Respect to Needs,
Constraints and Policies.
Process Activity Description
• Process Activity Rationale / Need / This activity will ensure that all needs are accounted for and
Motivation constraints and policies are adequately described in the
requirement specification.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• At least some requirements must have been documented
prior to starting this activity.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITIES
establish the context within which the bulk of direct conceptual
model population will occur:
• Specify the quality attributes that the requirement
specification shall satisfy.
• Review and modify the conceptual model requirement
specification to ensure that the chosen quality attributes are
satisfied.
Inter Process Activity Relationships
• Process Activity Sequence and This activity follows the PA2.1 – Requirements Definition and
Control-Flow is followed PA2.3 – Synergize Requirements.
• Process Activity Information Flow The activity takes as inputs P1.2 – Need Statement and
P1.3 – Constraints and Policies and updates the preliminary
requirement specification. In addition, V&V evidence must be
added to Meta data of the conceptual model.
Associated Entities
• Tools Requirement management tool.
• Actor-Agents Producer (requirement engineer).
• Information Pools Information pools relevant to this activity include:
• Preliminary requirement specification.
• Meta data.
• Product / Object / Artefacts This Process Activity updates the preliminary requirement
specification.

G - 10 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Process Activity Completion

• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• All requirements have been evaluated with respect to chosen
quality attributes.
• Any identified discrepancies have been rectified.

Table G-8: Conceptual Model Process Activity 2.3 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA2.3 – Synergize Conceptual Model, Mission and Simulation
Space Requirements.
Process Activity Description
• Process Activity Rationale / Need / Reconciling any incompatibilities between conceptual model,
Motivation mission and simulation space requirements.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• At least some requirements of different categories must have
been defined.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Review and modify the conceptual model requirement
specification to ensure compatibility between conceptual
model, mission, and simulation space requirements.
Inter Process Activity Relationships
• Process Activity Sequence and This activity follows PA2.2 and is followed by PA2.4.
Control-Flow
• Process Activity Information Flow This Process Activity takes the preliminary requirement
specification produced by PA2.2 as input and produces
P2.1 – Conceptual Model Requirement Specification.
Associated Entities
• Tools Requirement management tool.
• Actor-Agents Producer (requirement engineer).

RTO-TR-MSG-058 G - 11
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Information Pools Information pools relevant to this activity include:

• Preliminary requirement specification.
• Product / Object / Artefacts P2.1 – Conceptual Model Requirement Specification.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• All requirements have been evaluated for compatibility with
respect to requirements of the other categories.
• P2.1 has been completed.

Table G-9: Conceptual Model Process Activity 2.4 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA2.4 – Derive Mission and Simulation Space Knowledge Needs.
Process Activity Description
• Process Activity Rationale / Need / The purpose of this Process Activity is to communicate to the
Motivation conceptual model producer what knowledge must be acquired
in order to design and build a conceptual model that will serve
its intended purpose.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• At least some conceptual model requirement must have been
identified and documented.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Analyze the requirement specification in order to derive
knowledge needs.
• Document knowledge needs.
Inter Process Activity Relationships
• Process Activity Sequence and This Process Activity follows the PA2.3 and is the final activity
Control-Flow in Process Phase 2.
• Process Activity Information Flow This Process Activity uses P2.1 – Conceptual Model
Requirement Specification as input and produces P2.2 –
Conceptual Model Knowledge Acquisition Needs as output.

G - 12 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Associated Entities
• Tools None.
• Actor-Agents Producer (knowledge engineer).
• Information Pools Information pools relevant to this activity include:
• Legacy knowledge.
• Need descriptions.
• Product / Object / Artefacts This Process Activity produces P2.2 – Conceptual Model
Knowledge Acquisition Needs.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• An exhaustive list of knowledge elements needed to design
and build the desired conceptual model has been
documented in P2.2.

Table G-10: Conceptual Model Process Activity 3.1 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA3.1 – Identify Authoritative Knowledge Sources.
Process Activity Description
• Process Activity Rationale / Need / This activity is about identifying authoritative knowledge
Motivation sources to fetch correct and authoritative information that
describes a certain domain, for example through books, papers,
tutorials, interviewing the SMEs, etc.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• May begin once P2.1 – Conceptual Model Requirement
Specification and P2.2 – Conceptual Model Knowledge
Acquisition Needs exist.
Process Activity Method
• Process Activity Procedure There is no specific methodology for identifying appropriate
sources for KA, but here is a couple of recommendations:
• Having a deeper understanding of the problem domain and
(preferably) having experience of the particular area are
necessary qualities for success.

RTO-TR-MSG-058 G - 13
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • Rely only on authoritative knowledge sources, those
authorised by some organisation/authority beforehand
(who this person or agency should be is beyond the scope
of this report).
• These sources can be anything from books, web information,
papers, regulations documents, pictures, maps, and case
studies, but perhaps most important of all interviews with
Subject-Matter Experts (SMEs).
Inter Process Activity Relationships
• Process Activity Sequence and This activity may be initiated as soon as the inputs
Control-Flow P2.1 – Requirement Specification and P2.2 – Conceptual Model
Knowledge Acquisition Needs are available. But it must be done
before activity PA3.4 – Gather, Structure and Document
Knowledge begins.
• Process Activity Information Flow This activity takes as inputs P2.1 – Conceptual Model
Requirement Specification and P2.2 – Conceptual Model
Knowledge Acquisition Needs and produces a list of
authoritative knowledge sources which corresponds to
requirements and needs identified in Phase 2.
Associated Entities
• Tools No custom tools.
• Actor-Agents No specific actors or agents has been identified, however
existence of some organisation or authority who can point out
authoritative knowledge sources is of great benefit.
• Information Pools Information pools relevant to this activity include:
• List of authoritative knowledge sources for different military
activities.
• Simulation expertise, etc.
• Points of contact lists.
• List of SMEs.
• Employee roles.
• Organizational charts.
• Biographies, etc.
• Product / Object / Artefacts The final product of this activity will be a list of authoritative
knowledge sources for a certain kind of knowledge.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• When at least one authoritative knowledge sources adequate
for the certain kind of knowledge has been identified.

G - 14 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Table G-11: Conceptual Model Process Activity 3.2 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA3.2 – Search for the Reusable Knowledge in the Conceptual
Model Repository.
Process Activity Description
• Process Activity Rationale / Need / Given that a conceptual model repository already exists, no
Motivation acquisition of new knowledge is justified before checking if the
required conceptual model already is either partly or completely
modelled and stored in the conceptual model repository.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• May begin once P2.1 – Conceptual Model Requirement
Specification and P2.2 – Conceptual Model Knowledge
Acquisition Needs exist.
Process Activity Method
• Process Activity Procedure There is no specific methodology for identifying appropriate
sources for KA, but here are a couple of recommendations.
The list of needs and requirements will be the foundation for
building the necessary queries to the repository:
• Analyze P2.1 – Conceptual Model Requirement
Specification and P2.2 – Conceptual Model Knowledge
Acquisition Needs to find syntactic and/or semantic key
words for the search.
• Do search in an already existing conceptual model
repository for the reusable knowledge.
Keep in mind that several qualitative properties are critically
important to search and find either the reusable knowledge
component (part of a conceptual model) or a complete
conceptual model fulfilling a specific need:
• One is to try to model knowledge in smaller components that
makes reusability easier.
• The other property is to have a degree of formalisation and
semantic description that makes it possible to compose
smaller components for building the needed conceptual
model.
• The third is to have good Meta data addressing artefacts in
the conceptual model Repository; this makes it possible to
easily find the knowledge which corresponds to the need.

RTO-TR-MSG-058 G - 15
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Inter Process Activity Relationships

• Process Activity Sequence and This activity may be initiated as soon as the inputs
Control-Flow P2.1 – Conceptual Model Requirement Specification and
P2.2 – Conceptual Model Knowledge Acquisition Needs are
available. But it must be done before activity PA3.4 – Gather,
Structure and Document Knowledge begins.
• Process Activity Information Flow This activity takes as inputs P2.1 – Conceptual Model
Requirement Specification and P2.2 – Conceptual Model
Knowledge Acquisition Needs and produces a list of
authoritative knowledge sources which corresponds to
requirements and needs identified in Phase 2.
Associated Entities
• Tools Query making and repository searching tools.
• Actor-Agents No specific actors or agents have been identified.
• Information Pools Information pools relevant to this activity include:
• Reusable knowledge components which partly or completely
fulfill the need may be found as an intermediate product.
• Product / Object / Artefacts The final product of this activity will be either:
• A positive answer that the required conceptual model is
found in the conceptual model repository;
• Reusable knowledge components which only partly fulfill
the need has been found; or
• A negative answer about nothing of value for the specific
need was found.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• When the search is done and adequate result has been
retrieved.

Table G-12: Conceptual Model Process Activity 3.3 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA3.3 – Identify Knowledge Gaps and Bounds.
Process Activity Description
• Process Activity Rationale / Need / This activity concerns whether the knowledge retrieved from an
Motivation existing conceptual model repository is in accordance with the
requirements and needs or not.

G - 16 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Rationale / Need / The reusability of already gathered knowledge will be examined
Motivation (cont’d) to see if they can be used for the new purpose.
This outcome aids in identifying what is missing.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• This activity will happen (will be considered) only if the
result of the previous activity PA3.2 – Search for the
Reusable Knowledge is case b), which is the knowledge
components found in the conceptual model repository partly
fulfill the need.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• If the result of PA3.2 is case a) “the required knowledge is
found in the conceptual model repository” end this activity
immediately and initiate PA3.5.
• If the result of PA3.2 is case c) “nothing of value for the
specific need was found” end this activity immediately and
initiate PA3.4.
• If the result of PA3.2 is case b) “reusable knowledge
components which only partly fulfil the need has been
found”; then the result has to be analyzed and compared
with the need to identify knowledge gaps, i.e., what
part/parts are missing.
Inter Process Activity Relationships
• Process Activity Sequence and This activity will be initiated after PA3.2 is done. Depending to
Control-Flow the result it will either be followed by PA3.4 or PA3.5.
• Process Activity Information Flow This activity takes as inputs P2.2 – Conceptual Model
Knowledge Acquisition Needs and the result of PA3.2 – Search
for the Reusable Knowledge, and if no knowledge gap is
identified it will initiate PA3.5, but if significant knowledge is
still missing will produce an intermediate document addressing
that gap which will be used of PA3.4 – Gather, Structure and
Document Knowledge.
Associated Entities
• Tools Knowledge comparison tools.
• Actor-Agents Knowledge engineer, SME.

RTO-TR-MSG-058 G - 17
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Information Pools Information pools relevant to this activity include:

• Intermediate result from PA3.2, P2.1 and P2.2.
• Product / Object / Artefacts The final product of this activity will either be:
• No knowledge gaps identified; or
• A notion of what kind of information is missing and a list
of authorized knowledge sources for KA.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• When knowledge comparison is done and the gaps are
addressed.

Table G-13: Conceptual Model Process Activity 3.4 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA3.4 – Gather, Structure and Document Knowledge.
Process Activity Description
• Process Activity Rationale / Need / This activity is about acquiring certain knowledge which often is
Motivation not documented anywhere but only available through Subject-
Matter Experts (SME). This acquired knowledge will then be
structured and documented for further use.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• When the result of PA3.2 – Search for the Reusable
Knowledge has been case c) “nothing of value for the
specific need was found”; or
• When PA3.3 – Identify Knowledge Gaps and Bounds has
ended.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• The first step in this activity is about gathering knowledge.
Information sources for military activities can be anything
from instructions, books, military doctrines, military
scenarios, case studies to military experts.

G - 18 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) However, the information that is needed for a certain
purpose is often not documented anywhere and is only
available through SMEs. Below we provide examples of
techniques that can be used for this kind of knowledge
elicitation (mainly through interviews):
• Unstructured: The SME has a general discussion of the
domain, designed to provide a list of topics and
concepts.
• Structured: The interviewer asks the SME or end user
questions relating to a specific topic.
• Problem-solving: The SME is provided with a real-life
problem, something that they deal with during their
working life and are then asked to solve it. As the expert
does so, they are required to describe each step, and the
reasons for doing it.
• Prototyping: The SME is asked to evaluate a prototype
of a system.
• Simulation: The SME is asked to use a simulator so that
the SME’s behaviors can be observed.
• Dialogue: The SME interacts with a client, in the way
that they would normally do during their normal work
routine.
• Sample lecture preparation: The SME prepares a lecture,
and the knowledge engineer analyses its content.
• Questionnaires: These are useful when the knowledge
is to be gathered from several different subject-matter
experts.
• When the knowledge is acquired a methodology must be
chosen to structure the knowledge.
• Finally the gathered and structured knowledge must be
documented for further use and reuse.
• Last but not least must conceptual model Meta data product
be update with new information.
Inter Process Activity Relationships
• Process Activity Sequence and This activity will be initiated either by PA3.2 – Search for the
Control-Flow Reusable Knowledge or after PA3.3 – Identify Knowledge Gaps
and Bounds is done. This activity must be done before PA3.5 –
Generate/Extend a Domain Ontology begins.
• Process Activity Information Flow This activity takes the intermediate product generated in
PA3.3 – Identify Knowledge Gaps and Bounds as input and
produces another intermediate product called structured
knowledge corpus.

RTO-TR-MSG-058 G - 19
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Associated Entities
• Tools • Knowledge Acquisition (KA) tools.
• Structuring tools.
• Actor-Agents • Knowledge Acquisition expert.
• Knowledge engineer.
• Information Pools Intermediate result from PA3.3, P2.1 and P2.2. Information
sources for military activities can be anything from instructions,
books, military doctrines, military scenarios, case studies to
military experts. However, the information that is needed for a
certain purpose is often not documented anywhere and is only
available through SMEs.
• Product / Object / Artefacts The final product of this step is some structured and documented
information gathered to fulfil a certain need of knowledge.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• When the needed knowledge is gathered, structured and
documented.

Table G-14: Conceptual Model Process Activity 3.5 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA3.5 – Generate/Extend a Domain Ontology.
Process Activity Description
• Process Activity Rationale / Need / This activity covers structuring, tagging, and storing the
Motivation gathered information either as new domain ontology or as an
extension to an existing one.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• May be initiated by PA3.3 – Identify Knowledge Gaps and
Bounds.
• When PA3.4 – Gather, Structure and Document Knowledge
has ended and the intermediate product Structured
Knowledge corpus is available.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:

G - 20 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • New knowledge most likely will introduce new military
concepts, properties, relations, and constraints which should
be stored in some kind of knowledge base for future use and
reuse.
• Check if ontology/ontologies for the current subject already
exist, and in that case update the/those ontology/ontologies
with the most recent acquired knowledge.
• If no ontology exists for the current subject/domain one may
be created.
• There are different methodologies for integrating these new
concepts into existing ontologies as well as for creating new
ones. The appropriate creation methodology will depend
upon, and be influenced by, the requirements and design
criteria that exist. Examples of these for such an ontological
knowledge base may be:
• Flexibility;
• Adaptability;
• Traceability;
• Machine readability;
• Interoperability; and
• Reusability for multiple applications; or might simply
be rapid and easy development.
Inter Process Activity Relationships
• Process Activity Sequence and • The previous activities captured and documented new
Control-Flow knowledge about a certain military activity that did not already
exist in the conceptual model repository. As soon
as this intermediate product (new documented knowledge)
is available this activity can begin.
• This activity may indicate that the acquiring and
documentation of knowledge is done and ready for review,
and thereby PA3.6 may be initiated.
• Process Activity Information Flow This activity takes the intermediate product generated in PA3.4
called structured knowledge corpus and either produces a new
ontology or update/extend an existing one.
Associated Entities
• Tools • Ontology engineering tools.
• Ontology creation tools.
• Ontology integration tool.
• Actor-Agents • Ontology experts.
• Conceptual modeler.

RTO-TR-MSG-058 G - 21
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Information Pools Information pools relevant to this activity include:

• Intermediate result from PA3.3.
• Structured knowledge corpus created in PA3.4.
• Existing ontology repository.
• Knowledge base.
• Product / Object / Artefacts The final product of this activity will either be:
• A new domain ontology; or
• An updated/extended version of an existing ontology,
covering the latest acquired knowledge.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• When domain ontology is build; or
• An existing one is updated/extended.

Table G-15: Conceptual Model Process Activity 3.6 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA3.6 – Review Validity of Knowledge with Respect to the
Authoritative Knowledge Sources.
Process Activity Description
• Process Activity Rationale / Need / This activity discusses and examines the validity of acquired
Motivation knowledge with respect to authoritative knowledge sources.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activity, availability of information and establishment of
operational capability:
• Will be initiated when PA3.5 – Generate/Extend a Domain
Ontology is done and the acquired knowledge is ready for
review.
Process Activity Method
• Process Activity Procedure The validity of acquired knowledge with respect to authoritative
knowledge sources can be done using different V&V
methodologies, e.g., GM-V&V. The following PRELIMINARY
or PREFATORY ACTIVITY establish the context within which
the bulk of direct conceptual model population will occur:

G - 22 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • It is about checking – preferably performed by a VV&A

agent – with the experts, whose realities have been captured
and documented, to see if the documented knowledge is
correct and completely represents the activity.
• Examine whether the result of the knowledge acquisition
phase is acceptable to the owner of the mission space
(the SME).
• An ontology expert may also examine if the generation or
integration of the ontology is done correctly.
Inter Process Activity Relationships
• Process Activity Sequence and This activity may be initiated as soon as the activity PA3.5 –
Control-Flow Generate/Extend a Domain Ontology is done and the acquired
knowledge or the ontology is ready for review. And when the
acquired knowledge or the ontology is validated this phase is
completed.
• Process Activity Information Flow This activity takes P2.2 – Conceptual Model Knowledge
Acquisition Needs and the intermediate product from PA3.5 the
ontology, and produce the P3.1 – Validated Knowledge.
Associated Entities
• Tools • V&V tools.
• Ontology reviewing tools.
• Actor-Agents • V&V agents.
• SMEs.
• Ontology experts.
• Information Pools Information pools relevant to this activity include:
• The ontology created, updated or extended as a result of
PA3.5.
• Existing ontology repository or knowledge base.
• P2.2 – Conceptual Model Knowledge Acquisition Needs.
• List of authoritative knowledge sources produced as an
intermediate product in PA3.1.
• Product / Object / Artefacts This is the last activity and the last check within Phase 3,
and artefacts which pass this check are qualified to go to the
next phase of the conceptual modeling process.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• When the acquired knowledge is validated.

RTO-TR-MSG-058 G - 23
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Table G-16: Conceptual Model Process Activity 4.1 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA4.1 – Search for Existing Conceptual Models that May be
Partially of Fully Re-Used to Support the Current Conceptual
Model Development.
Process Activity Description
• Process Activity Rationale / Need / This activity identifies the need to partially or fully reuse
Motivation existing conceptual models.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:
• May begin when PA2.3 has substantial progress and when
PA2.1 – Conceptual Model Requirement Specification has
substantial input to start identifying search criteria for reuse.
• A repository with conceptual models that have Meta data
descriptions that is relevant to designing conceptual models.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Parse P2.1 – Conceptual Model Requirement Specification
to become acquainted with what design characteristics are
required.
• Identify search criteria based upon these required design
characteristics and search for candidate conceptual model.
• If conceptual model compositions have already been
identified in the preliminary conceptual model design,
search for conceptual models with similar design
characteristics.
• Identify suitability for reuse based on criteria listed in the
conceptual model Requirements Specification.
• Record or update the found conceptual models to the
preliminary conceptual model design artefact.
Inter Process Activity Relationships
• Process Activity Sequence and This activity is executed at least once and may be executed
Control-Flow iteratively after new inputs to the preliminary conceptual model
design during PA4.2, PA4.3, PA4.4 or PA4.5 or after the failure
to meet the conceptual model requirements during PA4.6

G - 24 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Sequence and evaluation or after the addition of requirements in P2.1 from
Control-Flow (cont’d) either some build experience in PA5.1, the arrival of new
stakeholders, the evolution to different conceptual model
characteristics (quality, utility, formality, abstractness), etc.
• Process Activity Information Flow Information from P2.1 – Conceptual Model Requirement
Specification and from external information pools flows into
this activity. Information from this activity flows into the
preliminary conceptual model design and eventually into
P4.1 – Conceptual Model Design if selected.
Associated Entities
• Tools No custom tools.
• Actor-Agents • Producer.
• Conceptual model developer.
• Information Pools Information pools relevant to this activity include:
• P2.1 – Conceptual Model Requirement Specification,
preliminary conceptual model design, preliminary
conceptual model, existing conceptual models.
• Conceptual models that have relevance in the mission space.
• Expected views driven by Stakeholder roles.
• Product / Object / Artefacts This Process Activity contributes to a preliminary conceptual
model design.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Some (not necessarily all or definitely) conceptual models
have been found and recorded to the preliminary conceptual
model design.

Table G-17: Conceptual Model Process Activity 4.2 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA4.2 − Identify and Select Conceptual Primitives and Model
Kinds to Represent Acquired Knowledge.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to select suitable conceptual primitives
Motivation that will capture the knowledge elements and model kinds that
will organize the conceptual primitives. This activity is necessary
to be intentionally selective on the conceptual primitive and
model kind options. This activity is an investment against the risk
of uninformed use of conceptual primitives and model kinds.

RTO-TR-MSG-058 G - 25
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Process Activity Initiation

• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:
• May begin when PA2.3 has substantial progress and
P2.1 – Conceptual Model Requirement Specification has
valuable input.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Parse P2.1 – Conceptual Model Requirement Specification
to become acquainted with the type of knowledge to be
captured and organized.
• Analyze conceptual model characteristics requirements from
P2.1 – Conceptual Model Requirement Specification to derive
the implications on conceptual primitives and model kinds.
• Survey conceptual primitive and model kind options either
from the literature or from experience.
• Make an elective choice of conceptual primitives and model
kinds that suit the requirements and that make a coherent
conceptual model composite combination.
• If views have been selected in the preliminary conceptual
model design, select model kinds that represent these views.
• If model kinds have been selected in the preliminary
conceptual model design, select conceptual primitives that
compose these model kinds.
• If conceptual primitives have been selected in the
preliminary conceptual model design, select model kinds
that will use these conceptual primitives.
• Record or update the selected conceptual primitives and
model kinds in a preliminary conceptual model design
artefact.
Inter Process Activity Relationships
• Process Activity Sequence and Executed at least once and may be executed iteratively after new
Control-Flow inputs to the preliminary conceptual model design during PA4.1,
PA4.3, PA4.4 or PA4.5 or after the failure to meet the
conceptual model requirements during PA4.6 evaluation or after
the addition of requirements in P2.1 from either some build
experience in PA5.1, the arrival of new stakeholders, the
evolution to different conceptual model characteristics (quality,
utility, formality, abstractness), etc.

G - 26 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Information Flow Information from P2.1 – Conceptual Model Requirement
Specification and from external information pools flows into this
activity. Information from this activity flows into the
preliminary conceptual model design and eventually into
P4.1 – Conceptual Model Design.
Associated Entities
• Tools Specific modeling tools can help to select coherent conceptual
model composite combinations. Tool availability is likely to
influence the design choices.
• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• P2.1 – Conceptual Model Requirement Specification.
• Preliminary conceptual model design.
• Preliminary conceptual model.
• Existing conceptual models.
• Literature on conceptual primitives and model kinds.
• Product / Object / Artefacts This Process Activity contributes to a preliminary conceptual
model design.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Some (not necessarily all or definitely) conceptual primitives
and model kinds have been selected and recorded to the
preliminary conceptual model design.

Table G-18: Conceptual Model Process Activity 4.3 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA4.3 − Select Formalism(s) for Conceptual Model
Specification.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to select the formalism(s) that will be
Motivation followed in the build process. This activity is necessary to be
intentionally selective on the formalism options. This activity is
an investment against the risk of uninformed use of formalisms.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:

RTO-TR-MSG-058 G - 27
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Entrance Criteria (cont’d) • May begin when PA2.3 has substantial progress.
• P2.1 – Conceptual Model Requirement Specification has
valuable input.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Parse P2.1 – Conceptual Model Requirement Specification
to become acquainted with the type of knowledge to be
modeled.
• Analyze conceptual model characteristics requirements from
P2.1 – Conceptual Model Requirement Specification to
derive the implications on formalisms.
• If a formalism has been mandated by policies, record it to
the preliminary conceptual model design.
• Survey formalism options either from the literature or from
experience.
• Analyze the preliminary conceptual model design to derive
appropriate formalisms to fit the conceptual primitives,
model kinds and views.
• Make an elective choice of formalism(s) that suit the
requirements and that make a coherent conceptual model
composite combination.
• Record or update the selected formalism(s) in the
preliminary conceptual model design artefact.
Inter Process Activity Relationships
• Process Activity Sequence and Executed at least once and may be executed iteratively after new
Control-Flow inputs to the preliminary conceptual model design during PA4.1,
PA4.2, PA4.3 or PA4.5 or after the failure to meet the
conceptual model requirements during PA4.6 evaluation or after
the addition of requirements in P2.1 from either some build
experience in PA5.1, the arrival of new stakeholders, the
evolution to different conceptual model characteristics (quality,
utility, formality, abstractness), etc.
• Process Activity Information Flow Information from P2.1 – Conceptual Model Requirement
Specification and from external information pools flows into this
activity. Information from this activity flows into the
preliminary conceptual model design and eventually into
P4.1 – Conceptual Model Design.
Associated Entities
• Tools Specific modeling tools can help to select coherent conceptual
model composite combinations. Tool availability is likely to
influence the design choices.

G - 28 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• P2.1 – Conceptual Model Requirement Specification.
• Preliminary conceptual model design.
• Preliminary conceptual model.
• Existing conceptual models, literature on formalisms.
• Product / Object / Artefacts This Process Activity contributes to a preliminary conceptual
model design.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• At least one formalism has been selected and recorded to
the preliminary conceptual model design.

Table G-19: Conceptual Model Process Activity 4.4 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA4.4 − Select Views to Support Stakeholders.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to select the views that will fit the
Motivation purpose of the different stakeholders.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:
• May begin when PA2.3 has substantial progress and
P2.1 – Conceptual Model Requirement Specification has
valuable input.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Parse P2.1 – Conceptual Model Requirement Specification
to become acquainted with the type of knowledge to be
communicated.
• Analyze the stakeholders’ view requirements from
P2.1 – Conceptual Model Requirement Specification to
derive the implications on view selection.

RTO-TR-MSG-058 G - 29
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • Survey view options either from the literature or from
experience.
• If formalisms have been selected in the preliminary
conceptual model design, analyze the impact of the
formalisms on the discretionary specification of views.
• Make an elective choice of views that support the
stakeholders’ requirements.
• Record or update the selected views in the preliminary
conceptual model design artefact.
Inter Process Activity Relationships
• Process Activity Sequence and Executed at least once and may be executed iteratively after new
Control-Flow inputs to the preliminary conceptual model design during PA4.1,
PA4.3 or PA4.5 or after the failure to meet the conceptual model
requirements during PA4.6 evaluation or after the addition of
requirements in P2.1 from either some build experience in
PA5.1, the arrival of new stakeholders, the evolution to different
conceptual model characteristics (quality, utility, formality,
abstractness), etc.
• Process Activity Information Flow Information from P2.1 – Conceptual Model Requirement
Specification and from external information pools flows into
this activity. Information from this activity flows into the
preliminary conceptual model design and eventually into
P4.1 – Conceptual Model Design.
Associated Entities
• Tools Specific modeling tools can help to select coherent conceptual
model composite combinations. Tool availability is likely to
influence the design choices.
• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• P2.1 – Conceptual Model Requirement Specification.
• Preliminary conceptual model design.
• Preliminary conceptual model.
• Existing conceptual models.
• Literature on views.
• Product / Object / Artefacts This Process Activity contributes to the preliminary conceptual
model design.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• At least one view has been selected and recorded to the
preliminary conceptual model design.

G - 30 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Table G-20: Conceptual Model Process Activity 4.5 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA4.5 − Select a Notation Suitable to Express the Chosen
Formalism.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary to select a notation to express the
Motivation conceptual primitives, model kinds, views and formalisms.
This activity is necessary to be intentionally selective on the
notation options. This activity is an investment against the risk
of uninformed use of notations.
Process Activity Initiation
• Entrance Criteria Entrance criteria consist of the completion of the following
activities, availability of information and establishment of
operational capability: May begin when PA2.3 has substantial
progress; P2.1 – Conceptual Model Requirement Specification
has valuable input.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Analyze the preliminary conceptual model design to identify
which conceptual primitives, model kinds and formalisms
must be supported by the notation.
• Survey notations options either from the literature or from
experience.
• Make an elective choice of notations(s) in accordance with
the conceptual model characteristics from P2.1 – Conceptual
Model Requirement Specification.
• Record or update the selected notation(s) in the preliminary
conceptual model design artefact.
Inter Process Activity Relationships
• Process Activity Sequence and Executed at least once and may be executed iteratively after new
Control-Flow inputs to the preliminary conceptual model design during PA4.1,
PA4.2 or PA4.3 or after the failure to meet the conceptual model
requirements during PA4.6 evaluation or after the addition of
requirements in P2.1 from either some build experience in
PA5.1, the arrival of new stakeholders, the evolution to different
conceptual model characteristics (quality, utility, formality,
abstractness), etc.

RTO-TR-MSG-058 G - 31
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Information Flow Information from P2.1 – Conceptual Model Requirement
Specification and from external information pools flows into
this activity. Information from this activity flows into the
preliminary conceptual model design and eventually into
P4.1 – Conceptual Model Design.
Associated Entities
• Tools Specific modeling tools can help to select coherent conceptual
model composite combinations. Tool availability is likely to
influence the design choices.
• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• P2.1 – Conceptual Model Requirement Specification.
• Preliminary conceptual model design.
• Preliminary conceptual model.
• Existing conceptual models.
• Literature on views.
• Product / Object / Artefacts This Process Activity contributes to a preliminary conceptual
model design.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• At least one notation has been selected and recorded to the
preliminary conceptual model design.

Table G-21: Conceptual Model Process Activity 4.6 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA4.6 – Evaluate Design for Adequacy/Relevance with Respect
to Requirements.
Process Activity Description
• Process Activity Rationale / Need / This activity is necessary for verifying whether conceptual
Motivation model requirements have been met by the conceptual model
design.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:
• P2.1 – Conceptual Model Requirement Specification.

G - 32 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Entrance Criteria (cont’d) • The preliminary conceptual model design.

• The V&V argumentation framework.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY ACTIVITY
establish the context within which the bulk of direct conceptual
model population will occur:
• Parse P2.1 – Conceptual Model Requirement Specification
to become acquainted with what design characteristics are
required.
• Parse the Preliminary conceptual model Design and check
whether all conceptual model compositions have been
identified.
• Part of the V&V argumentation framework is concerned
with the quality of the design of the conceptual model. These
topics must be specified and transformed into design quality
criteria, such as whether all views needed by the
stakeholders are available or whether the chosen formalism
is capable of expressing the conceptual model.
• For each design quality criterion, evidence must be obtained.
• Finally, update the design characteristics in the conceptual
model data and publish the conceptual model design.
Inter Process Activity Relationships
• Process Activity Sequence and Perform after the PA4.1 – PA4.5 activities have finished.
Control-Flow
• Process Activity Information Flow Preliminary design whether the conceptual model Design meets
the conceptual model requirements and accepts the conceptual
model design.
Associated Entities
• Tools Book keeping aids like requirements tools.
• Actor-Agents Producer.
• Information Pools Information pools relevant to this activity include:
• P2.1 – Conceptual Model Requirement Specification.
• Preliminary conceptual model design.
• The preliminary conceptual model.
• Product / Object / Artefacts Verified conceptual model design and conceptual model Meta
data.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• When conceptual model design meets the conceptual model
requirements and when P4.1 is complete.

RTO-TR-MSG-058 G - 33
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Table G-22: Conceptual Model Process Activity 5.1 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA5.1 – Populate the Conceptual Model Using the Chosen
Primitives, Model Kinds, Formalism, and Notation.
Process Activity Description
• Process Activity Rationale / Need / Given information contained in P3.1 – Validated Knowledge
Motivation and P4.1 – Model Design; it is necessary to compile a
(DRAFT or FINAL) version of the preliminary conceptual
model. This process step is critical to the generation of the
Process Phase 5 final work-product P5.1 – Conceptual Model
insofar as it constitutes the accumulation, binding, and
permanent authoritative documentation of the desired
complete and consistent conceptual model itself, relevant to
the military mission space intending to be represented in the
pursuant model or simulation, in a preliminary form, pending
articulation and confirmation to yield the final conceptual
model artefact. The fundamental motivation of this process
step is to capture in concrete, persistent form the entire
STRUCTURE and PROCESS entailed in the mission space
in detail, scope, and fidelity appropriate to the intended use
of the conceptual model.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the completion of the following
activities, availability of information and establishment of
operational capability:
• Completion of previous activities (namely Process Phase
3 and Process Phase 4), and availability in DRAFT or
FINAL form of their work-products (i.e., P3.1 – Validated
Knowledge and P4.1 – Conceptual Model Design).
• Establishment of conceptual model drafting Group.
• Planning of effort entailed in PP5 Activity.
Process Activity Method
• Process Activity Procedure The following PRELIMINARY or PREFATORY
ACTIVITIES establish the context within which the bulk of
direct conceptual model population will occur:
• Build strategy – Establish the style of operation by the
Group, election of alternative design options not otherwise
bound by requirements, and establishing such stylistic
conventions as may facilitate cooperation and efficiency
of the Group. Build versions may be spiral so that a
succession of products is generated progressively
converging on the desired result. Alternatively,

G - 34 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) parallelization techniques such as partitioning the mission
space, allocating model constructs (i.e., primitives or
model kinds) to Group members of the group may be
convenient.
• Notation – Establish election of alternative options for
Primitives, Model kinds, Formalisms and Notation which
may persist, consistent with P4.1 – Conceptual Model
Design specified constraints may be necessary. These
determinations and such style conventions to be shared
across the Group should be established by consensus
before significant build composition effort is begun.
Checking the implications of such determinations during
first spiral reviews will reassure the Group of the wisdom
of its choices.
• Sufficiency Criteria – Establish agreement upon prefatory
interpretation of sufficiency criteria for the expected
product, cast in terms of easily observable and
confirmable product characteristics and evidently
correlated to requirements specification elements will
provide insurance against shortfalls in product quality in
areas such as detail and completeness (scope, entities,
entity-attribute and entity-relationships) as specified.
• Tools – Select and provide prompt access to sufficient
Tools to the conceptual model population Group.
Selection of such tools should be made carefully with
consideration for: a) familiarity and competence of Group,
b) power to meet conceptual design capture and
specification, and c) facility to generate views and
published data products acceptable to customer user
stakeholders.
• Documentation – Establish Product Document
management process and information storage and retrieval
sufficient to contain the evolving conceptual model work-
product, control of its authoritative configuration and
containing commentary on tactical decisions – just as is
prudent for requirements or code management under other
circumstances.
The following EXECUTION ACTIVITIES constitute the
bulk of the conceptual model composition effort – to be
executed with information contained in P3.1 – Validated
Knowledge, in accordance with the constraints manifest in
P4.1 – Conceptual Model Design, commensurate with the
build strategy and manifesting the notational conventions
previously agreed-upon:
• Designate object entities.

RTO-TR-MSG-058 G - 35
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • Designate entity class abstractions.

• Designate entity class or entity object attributes or
predicates.
• Designate entity class and entity object methods or
operational processes.
• Designate static relationships among object entities and
object classes including typically inheritance
(e.g., specialization-abstraction), logical (e.g., causal),
process subordination or composition and structural
composition relationships.
• Designate dynamic relationships associated with object
entities and classes, including typically state transition,
event trace, information flow and interface, and activity
control relationships.
Please NOTE that the enumeration of activity elements cited
above is not guaranteed to be complete or fully systematic,
notwithstanding its being characteristic of guidance provided
in respected literature and commonly observed in practice.
It should, in its entirety, however, provide procedurally
concrete guidance to the conceptual model population
practitioner In addition, the vernacular used in the operational
guidance, while somewhat particular, should not be
interpreted as limiting or constraining in any way the
determinations made a priori regarding “Primitives, Model
kinds, Formalisms and Notation “ Instead, they should be
considered a good faith attempt to indicate in unbiased form
the effort-elements recommended to capture a reasonable
preliminary conceptual model population.
Inter Process Activity Relationships
• Process Activity Sequence and Control- Process Build Strategy – <see above>.
Flow Process Step Iteration – <see above>.
Process Step Parallelization – <see above>.
• Process Activity Information Flow Contingent guidance on Process Activity sequence and
control flow above, the following guidance is provided:
• Collaboration – During execution, conduct of Group
reviews of work progress, product convergence according
to build strategies, and product quality should compliment
normal program reviews and control mechanisms.
Cultivation of consistency of vision across the conceptual
model build Group is a powerful mechanism to maintain
consistency of product, and collaboration among Group
members.
• Upstream – Knowledge/Design providers, Stakeholders –
essential to compliance.

G - 36 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Information Flow • Within activities – Population Group cohort … essential
(cont’d) to convergence and consistency of product.
• To product – Preliminary conceptual model as official
record of original entry… essential to closure.
Associated Entities
• Tools Notational Standards – Information and notational standards
assets likely to support the subject activity include, for:
• Process-Perspective:
• IDEF 0.
• Petri Net.
• …
• Object-Perspective:
• UML.
• SYSML.
• IDEF-4.
• Resource Description Frameworks (XML/RDF/RDFS).
• Meta Object Facility (MOF) Core Specification – OMG
adopted specification.
• …
• Data/Knowledge/Information-Perspective:
• IDEF- 1, 1xKnowledge Interchange Format (KIF).
• Open knowledge Base Connectivity Protocol.
• Knowledge Representation System (KRS).
• SQL.
• Entity Relationship Model (ERM)…
• …
• Ontology Perspective:
• ISO/IEC 1350 Topic Maps.
• OWL.
• IDEF 5.
• Ontology Interface Layer (OIL).
• Ontology Exchange Language (OXL).
• Ontolingua.
• …
COTS CASE Tools – Software assets likely to support the
subject activity are available from within the assets of four
coexisting communities of practice as follows:

RTO-TR-MSG-058 G - 37
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Tools (cont’d) • Systems Engineering/Architecture – Typical, but not

necessarily recommended tools in this category are:
• Systems Architect.
• Microsoft Visio.
• Cradle.
• CORE.
• …
• Software development – Typical, but not necessarily
recommended tools in this category are:
• IBM Rational Software Modeler (formerly Rational
Rose).
• Microsoft Visio.
• …
• Data Engineering – Typical, but not necessarily
recommended tools in this category are:
• Myriad DBMS assets.
• …
• Ontology and Knowledge Analysis – Typical, but not
necessarily recommended tools in this category are:
• Apollo.
• LinkFactory.
• OILdOntoEdit.
• Ontolingua Server.
• OpenKnoME.
• Protégé – 2000.
• SymOntoXWebODE.
• WebOntoChimera.
• FCA-Merge.
• PROMPT.
• ODEMerge.
• …
NOTE that suitability of tools is strongly contingent upon the
a priori selection of Primitives, Model kinds, Formalisms and
Notation cited above. In particular, tools are invariably
notation specific; but their having implicit capability or bias
toward one or another set of object- versus process- versus
data-orientation and choice of primitives is significant and
should not be overlooked.

G - 38 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Actor-Agents Agents populating the preliminary conceptual model are

typically individuals or a designated Group specifically familiar
with the required activities and expected consequential
products. Execution – implementation agents must be familiar
with a range of optional approaches, competent to execute the
designated procedures, and competent to collaborate with other
stakeholder role holders to ensure that the process executed and
product generated are acceptable for intended use of the
prospective conceptual model.
• Information Pools Information pools relevant to this activity include input data
artefacts and preliminary conceptual model product in whole
or in part pursuant to the completion of the subject activity.
In addition, it is likely that a variety of intermediate information
pools will be generated as Group member contributions are
generated or partial activity results components are generated
in anticipation of compilation of these elements in the
DRAFT preliminary conceptual model work-product.
• Product / Object / Artefacts The principle desired output of the subject activity is the
preliminary conceptual model. This product is described in
Annex F.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Execution all process steps indicated above.
• Generation of a preliminary conceptual model, including
intentional bindings of Primitives, Model kinds,
Formalisms and Notation; according to an unambiguously
specified notational formalism; with the following
attributes:
• Completeness:
• Preliminary conceptual model shall exhaust in scope
of its contents the description of mission-space and
simulation-space domains.
• The model shall contain all the expository features
entailed in the notational schema (as tailored) that
is used in the capture of the model documentation.
• Consistency:
• Preliminary conceptual model shall exhibit
commensurate detail among its respective conceptual
model components.
• Expression of the preliminary conceptual model shall
be expressed systematically in accord with
the notational schema of chosen tools and
representational notations.

RTO-TR-MSG-058 G - 39
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Exit Criteria (cont’d) • Correctness:

• Preliminary conceptual model contents shall be
plausibly correct in providing representations of
mission-space and simulation space domains,
contingent execution of VV&A and further credibility
determinations and findings to be achieved in
following activities.
• Sufficiency:
• Preliminary conceptual model shall be plausibly
sufficient for its intended use by each of several
stakeholders committed to the subject enterprise.
Criteria reference “values” for demonstration of satisfactory
completion of the subject activity – insofar as they shall be
needed in addition to the specific guidance above – shall be
established by the conceptual model development Group and
made a matter of explicit record in anticipation of the subject
completion evaluation.

Table G-23: Conceptual Model Process Activity 5.2 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA5.2 – Create the Specified Views.
Process Activity Description
• Process Activity Rationale / Need / Given information contained in the result of activity PA5.1,
Motivation e.g., the preliminary conceptual model; it is necessary to
elaborate that model by establishing the set of canonical
‘views’ or perspective of that preliminary conceptual model
so that that model’s contents may be precisely and thoroughly
appreciated by the stakeholder community and in particular
so the it may be systematically appreciated and understood
consistently by the members of the P5.1 – Conceptual Model
product development Group for purposes of execution of
activities PA5.2 – PA5.4. Consistent appreciation of the
content and significances of the syntax and semantics of the
Preliminary conceptual model by all members of the
conceptual model development Group is essential to the
convergence of the preliminary model to the final conceptual
model artefact.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:

G - 40 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Entrance Criteria (cont’d) • Completion of the Preliminary conceptual model to the

degree that its stability, scope and relevance are evident,
prime facie, to the conceptual model development Group.
• Documentation of the notational schema whereby the
Preliminary Conceptual model has been compiled, and
publication of tools and associated data interchange
schemas known readily to be available for operating upon
the contents of the preliminary conceptual model.
• Designation of the conceptual model views generation
and publication work cadre.
Process Activity Method
• Process Activity Procedure The following activities constitute the process whereby the
establishment of views reflecting the contents of the
Preliminary conceptual model shall be made manifest:
• Strategy – Establish systematic strategy and procedures
for educing and publishing views from the Preliminary
Conceptual Mode.
• View Inventory – Select views to be employed in
depicting the preliminary Conceptual model. Such views
should be assured to support the interests of enterprise
stakeholders, but particularly the following: a) VV&A
agents, b) Customers and users of the information
contained in the conceptual model, and particularly,
c) developers of the intended objective simulation system
These determinations and such style conventions to be
shared across the Group should be established by
consensus before significant build composition effort is
begun. Checking the implications of such determinations
during first spiral reviews will reassure the Group of the
wisdom of its choices.
• Sufficiency Criteria – Establish agreement upon prefatory
interpretation of sufficiency criteria for the expected
product, cast in terms of easily observable and
confirmable product characteristics and evidently
correlated to requirements specification elements will
provide insurance against shortfalls in product quality in
areas such as detail and completeness (scope, entities,
entity-attribute and entity-relationships) as specified.
• Tools – Select and provide prompt access to sufficient
Tools to the conceptual model view generation Group.
Selection of such tools should be made carefully with
consideration for: a) familiarity and competence of
Group, b) power to meet conceptual design capture and
specification, and c) facility to generate views and

RTO-TR-MSG-058 G - 41
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) published data products acceptable to customer user
stakeholders.
Documentation – establish Product Document management
process and information storage and retrieval sufficient to
contain the evolving conceptual model view-set work-product,
control of its authoritative configuration and containing
commentary on tactical decisions – just as is prudent for
requirements or code management under other circumstance.
The following EXECUTION ACTIVITIES constitute the
bulk of the conceptual model view generation effort – to be
executed consonant with information contained in the
preliminary conceptual model, commensurate with the build
strategy, and manifesting the notational conventions
previously agreed-upon:
• Elect one of the (possibly) several view types identified
for this activity.
• Using the preliminary conceptual model as a basis for
interpretation and representation, generate view
components consistent with the view type being
addressed, covering the entire scope of the Preliminary
Conceptual model and preserving detail contained in the
preliminary conceptual model in so far as the subject view
allows. Integrate view elements by means of composition,
or generalization relationships insofar as the subject view
schema allows.
• Select another of the intended representation views and
repeat as above. When one pass implementing all desired
views are completed proceed to next step following.
• Conduct systematic cross-reference of view consistency
by means suitable to ensure that all vies represent/reflect/
reveal the Preliminary conceptual model consistently and
comprehensively. Such cross-reference techniques as are
deemed suitable by the conceptual model views
generation Group are acceptable, but the following are
particularly endorsed: a) thorough reconciliation of
representative use case in mission space and simulation
space domains, b) reconciliation of views for any such
components of the Preliminary conceptual model as may
be perceived to have unusually close coupling in object
or process terms, c) reconciliation of views for parts of
preliminary conceptual model as may be considered
particularly significant; that is: those which were
unusually difficult to generate originally, those which are
perceived to be particularly difficult to understand,
and those that are perceived to be particularly relevant to
one or another stakeholder.

G - 42 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • Document all views generated with qualifying
commentary regarding their significance, their
relationships, and the use of notational conventions with
which they have been conceived and published.
Please NOTE that the enumeration of activity elements cited
above is not guaranteed to be complete or fully systematic,
notwithstanding its being characteristic of guidance provided
in respected literature and commonly observed in practice.
It should, in its entirety, however, provide procedurally concrete
guidance to the conceptual model population practitioner.
In addition, the vernacular used in the operational guidance,
while somewhat particular, should not be interpreted as
limiting or constraining in any way the determinations made
a priori regarding Conceptual model views. Instead, they
should be considered a good faith attempt to indicate in
unbiased form the effort-elements recommended to disclose
a reasonable preliminary conceptual model population.
Inter Process Activity Relationships
• Process Activity Sequence and Control- Process Build Strategy – <see above>.
Flow Process Step Iteration – <see above>.
Process Step Parallelization – <see above>.
• Process Activity Information Flow Contingent guidance on Process Activity sequence and control
flow above, the following guidance is provided:
• Collaboration – During execution, conduct of Group
reviews of work progress, product convergence according
to build strategies, and product quality should compliment
normal program reviews and control mechanisms.
Cultivation of consistency of vision across the conceptual
model build Group is a powerful mechanism to maintain
consistency of product, and collaboration among Group
members.
• Upstream – Knowledge/Design providers, Stakeholders –
essential to compliance.
• Within activities – Population Group cohort … essential
to convergence and consistency of product.
• To product – Preliminary conceptual model as official
record of original entry … essential to closure.
Associated Entities
• Tools See discussion of standards and COTS/CASE tools provided
in exposition of process step 5.1 above.
• Actor-Agents Agents producing views of the preliminary conceptual model
are typically individuals or a designated Group specifically
familiar with the required activities and expected

RTO-TR-MSG-058 G - 43
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Actor-Agents (cont’d) consequential products. Execution – implementation agents

must be familiar with a range of optional approaches,
competent to execute the designated procedures, and
competent to collaborate with other stakeholder role holders
to ensure that the process executed and product generated are
acceptable for intended use of the prospective conceptual
model.
Merit exists in choosing views generation agents from the
preliminary development Group and from among stakeholders
associated with prospective conceptual model verification,
validation and use, in order to assure that the most consistent,
intelligible and potentially useful suite of conceptual model
views is generated by consensus among disparate stakeholder
communities.
• Information Pools Information pools relevant to this activity include input data
artefacts and preliminary conceptual model product in whole
or in part pursuant to the completion of the subject activity.
In addition, it is likely that a variety of intermediate information
pools will be generated as Group member contributions are
generated or partial activity results components are generated
in anticipation of compilation of these elements in the DRAFT
preliminary conceptual model work-product.
• Product / Object / Artefacts The principle desired output of the subject activity is the suite
of expository views of the preliminary conceptual model.
This product is described in Annex F.
Process Activity Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Execution all process steps indicated above.
• Generation of an ensemble of views for the subject
preliminary conceptual model, according to an
unambiguously specified notational formalism; with the
following attributes:
• Completeness:
• Preliminary conceptual model views shall exhaust in
scope of its contents the description
of mission-space and simulation-space domains.
• The model views shall contain all the expository
features entailed in the notational schema
(as tailored) that is used in the capture of the model
documentation.

G - 44 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Exit Criteria (cont’d) • Consistency:

• Preliminary conceptual model views shall exhibit
commensurate detail among its respective conceptual
model components.
• Expression of the preliminary conceptual model views
shall be expressed systematically in accord with the
notational schema of chosen tools and representational
notations.
• Correctness:
• Preliminary conceptual model view contents shall be
plausibly correct in providing representations of
mission-space and simulation space domains,
contingent execution of VV&A and further credibility
determinations and findings to be achieved in
following activities.
• Sufficiency:
• Preliminary conceptual model views shall be plausibly
sufficient for its intended use by each of several
stakeholders committed to the subject enterprise.
Criteria reference “values” for demonstration of satisfactory
completion of the subject activity – insofar as they shall be
needed in addition to the specific guidance above – shall be
established by the Conceptual Model development Group and
made a matter of explicit record in anticipation of the subject
completion evaluation.

Table G-24: Conceptual Model Process Activity 5.3 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA5.3 – Verify Conceptual Model Consistency with Respect
to Conceptual Model Design.
Process Activity Description
• Process Activity Rationale / Need / Given information contained in the result of activity PA5.1,
Motivation e.g., the preliminary conceptual model; it is necessary to
establish the credibility and user confidence appropriate to be
held in the preliminary conceptual model. On this account, two
steps are warranted: verification of the preliminary model in
comparison to the conceptual model Design (Product P4.1)
and, subsequently, the validation of the preliminary model in
comparison to the validated knowledge manifest of the
simulation representation and simulation execution domains
as Product P3.1. This section addresses the former effort.

RTO-TR-MSG-058 G - 45
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Process Activity Initiation

• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• Completion of the Preliminary conceptual model and its
associated views heretofore incorporated, to the degree
that its credibility and commensurability to the Conceptual
Model Design are evident, prime facie, to the conceptual
model development group.
• Documentation of the verification plan whereby the
preliminary conceptual model is to be evaluated, this plan
should contain strategies, and procedures whereby the
congruity of the preliminary conceptual model and the
antecedent Conceptual Model Design is to be demonstrated.
• Designation of the Conceptual Model verification
evaluation and publication work cadre.
Process Activity Method
• Process Activity Procedure The fundamental nature of verification of a subject artefact
(here, the preliminary Conceptual Model) to a referent
information source (here, the content of the P4.1 – Conceptual
Model Design), entails corroboration of conformance of the
former in its structure, attributes and (functionality) to the
informational content of the latter.
Procedural guidance for verification execution is highly
contingent upon the nature of the subject, the referent, and the
intended use of the subject for which verification confirmation
is desired. On that count, no more than provisional guidance
can be provided here to guide verification execution toward
successful conclusion. In fact, however, there exists a copious
literature whereby such verification may be conducted.
In view of the specialization of VV&A necessary for any
particular conceptual model evaluation, and the myriad of
techniques for that purpose available in National, and
international ‘best-practice’ guidance (e.g., HLA, NATO);
Only precepts, strategic guidance and cautionary instructions
are provided in the procedural entries that follow:
• Publish and execute a conceptual model verification plan,
including specification of: a) verification needs, b)
requirements, c) activities, d) data products, e) necessary
and sufficient resources, f) management, and g) work-
product.
• Show rationale whereby planned verification effort
devolves and satisfies to a sufficient degree the intention
of verification, itself predicated upon appreciation of the
intended use of the conceptual model.

G - 46 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • Particularly link verification effort to the demonstration
of suitable compliance of the preliminary conceptual
model to the Conceptual Model Design manifest in the
work-product P4.1.
• Establish clearly defined verification evaluation
components and criteria for satisfaction of verification
evaluation component activities.
• Report results of verification effort in accordance with
description of the Accreditation Report element of
conceptual model work produce specified in Annex F.
• Coordinate verification plan and results with significant
stakeholders.
Inter Process Activity Relationships
• Process Activity Sequence and Control- Process Build Strategy – <see above>.
Flow Process Step Iteration – <see above>.
Process Step Parallelization – <see above>.
• Process Activity Information Flow Contingent guidance on Process Activity sequence and control
flow above, the following guidance is provided:
• Collaboration – During execution, conduct of Group
reviews of work progress, product convergence according
to build strategies, and product quality should compliment
normal program reviews and control mechanisms.
Cultivation of consistency of vision across the Conceptual
Model Build Group is a powerful mechanism to maintain
consistency of product, and collaboration among Group
members.
• Upstream – Input from Conceptual Model Design product
and product-providers, Stakeholders – essential to
compliance.
• Within activities – Population Group cohort … essential
to convergence and consistency of product.
• To product – Preliminary conceptual model or to
Conceptual Model Verification Report as official record
of original entry is essential to closure.
Associated Entities
• Tools See discussion of standards and COTS/CASE tools provided
in exposition of process step 5.1 above.
• Actor-Agents V&V Agents.
• Information Pools P4.1 – Conceptual Model Design documentation, together
with Preliminary conceptual model artefact are information
necessary and sufficient to support the completion of this
activity.

RTO-TR-MSG-058 G - 47
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Product / Object / Artefacts While no formal work-product is indicated in the process

model as consequent the execution of this activity, it is
recommended that a certificate of verification be produced and
made a part of the formal documentary conceptual model data
package for reference in subsequent VV&A efforts and for
reference within the enterprise environment.
Process Activity Completion
• Exit Criteria Determination of the adequacy of verification of the
conceptual model with regard to consistency with conceptual
model design and generation of an authoritative, permanent,
accessible record of such verification.

Table G-25: Conceptual Model Process Activity 5.4 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA5.4 – Validate Conceptual Model with Respect to Mission
Space and Simulation Space Knowledge.
Process Activity Description
• Process Activity Rationale / Need / Given information contained in the result of activity PA5.1,
Motivation e.g., the preliminary conceptual model; it is necessary to
establish the credibility and user confidence appropriate to be
held in the preliminary conceptual model. On this account, two
steps are warranted: verification of the preliminary model in
comparison to the conceptual model Design (Product P4.1),
and, subsequently, the validation of the preliminary model in
comparison to the validated knowledge manifest of the
simulation representation and simulation execution domains
as Product P3.1. This section addresses the latter effort.
Process Activity Initiation
• Entrance Criteria Entrance criteria consists of achievement of the following
state:
• Tasks PA5.1 – 5.3 are complete.
• Product P3.1 is available.
• Preliminary conceptual model DRAFT is available for
evaluation.
Process Activity Method
• Process Activity Procedure Execution agent conducts following activity:
• Establish rational for validation criteria.
• Specify validation criterion sufficiency levels based on
state of mission and simulation space knowledge.

G - 48 RTO-TR-MSG-058
 ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

• Process Activity Procedure (cont’d) • Evaluate preliminary conceptual model attributes.

• Compare attributes as evaluated to the criterion values
previously established.
• Document compliance or minimal sufficiency of attributes
of the preliminary conceptual model in relation to
reference values.
• Revise conceptual model (or reconsider mission space and
simulation space knowledge formulation and/or contents).
• Repeat evaluation step until sufficiency achieved.
Inter Process Activity Relationships
• Process Activity Sequence and Control- This activity follows Activity PA5.3 and subsequent
Flow determination of adequacy of the results of that activity.
It precedes Activity PA5.6.
• Process Activity Information Flow Activity uses information from Product P3.1 – Validated
Knowledge and provides information to the preliminary
conceptual model.
Associated Entities
• Tools VV&A tools chosen for use within the enterprise.
• Actor-Agents V&V agent.
• Information Pools Information pools relevant to this activity include the
preliminary conceptual model and P3.1 – Validated
Knowledge.
• Product / Object / Artefacts None.
Process Activity Completion
• Exit Criteria Complete demonstration of satisfaction of attributes of the
preliminary conceptual model to criteria derived from.

Table G-26: Conceptual Model Process Activity 5.5 Description.

PROCESS ACTIVITY CHARACTERISTIC

Process Activity Identity
• Process Activity Name and Aliases PA5.5 – Ensure Acceptance of Conceptual Model by
Authorized Stakeholders.
Process Activity Description
• Process Activity Rationale / Need / Satisfaction of stakeholders’ needs in creation and subsequent
Motivation utility of conceptual models is the fundamental objective of
conceptual model development activity. Confirmation of
suitability of the conceptual model work-product with
stakeholder(s) authorized to render that judgement is the
proximate objective of the effort.

RTO-TR-MSG-058 G - 49
ANNEX G – CONCEPTUAL MODELING PROCESS ACTIVITY DESCRIPTION

Process Activity Initiation

• Entrance Criteria Completion of development Process Activities through PA5.4
and a FINAL DRAFT of the conceptual model, together with
associated work-products are necessary pre-conditions for
completing this activity.
Process Activity Method
• Process Activity Procedure Particular activities considered necessary and sufficient to
complete this process step include:
• Check for completion of preceding efforts and entrance
criteria.
• Compile full documentation suite including FINAL
DRAFT preliminary conceptual model.
• Identify authoritative stakeholder(s) whose approval is
considered necessary.
• Prepare decision briefing.
• Prepare authorization documentation.
• Execute decision briefing.
• Obtain authorization documentation signature.
Inter Process Activity Relationships
• Process Activity Sequence and Control- This Process Activity follows Activity PA5.4 and the
Flow adequacy decision following. It is the last step in PP5.
• Process Activity Information Flow Information flow into this activity includes the FINAL
DRAFT preliminary conceptual model as well as any
necessary information from preceding information data
products generated during the conceptual modeling process
Output information includes a formally approved conceptual
model designated Product 5.1.
Associated Entities
• Tools No special tools required.
• Actor-Agents Principal actor agents contributing in this activity are the
conceptual model development effort program manager
(and associated administrative staff) and the designated
authoritative Stakeholder(s) whose approval is solicited.
• Information Pools Preliminary conceptual model and associated collateral
documentation.
• Product / Object / Artefacts P5.1 – Approved Conceptual Model.
Process Activity Completion
• Exit Criteria Approval of FINAL DRAFT conceptual model by
authoritative stakeholder(s).

G - 50 RTO-TR-MSG-058
 Annex H – CONCEPTUAL MODEL PRODUCT DESCRIPTION
Table H-1: Generic Template for Specification of Product.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases <Denotative names and identifiers of Product.>
Product Description
• Product Definition <A definition of the subject Product.>
• Product Purpose <Describes the purpose of the Product, both in the
development process and as an artefact for later reference.>
• Product Content <Describe the content of the product.>
• Product Structure/Format <Describe the structure of the product.>
Product Initiation
• Entrance Criteria <This field specifies component values that are necessary and
sufficient for the development of subject Product to be
effectively initiated.>
Product Development Guidance
• Product Development <In this field, the agent is provided procedural guidance for
the development of the subject Product. Note that relationships
to Process Activities and needs for tools or information are
specified in other form records.>
Product Relationships
• Product – Process Relationships <Instruction regarding the Process steps and sub-steps that
produce this Product, and the Process steps and sub-steps that
use this Product.>
• Inter-Product Relationships <Instruction regarding the relationships between this Product
and all other relevant Products. These instructions should
indicate which Products are predecessors to this Product,
which are successors, and which may be done in
concurrence.>
Associated Entities
• Tools <Identify tools such as hardware or software necessary and
sufficient, or useful, to complete the Product.>
• Actor-Agents <Indicate the actor agents responsible for development of the
Product, and their respective roles.>

RTO-TR-MSG-058 H-1
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

• Information Pools <Data stores of any type containing information used as input
or generated as key content of the Product. May contain
intermediate information re-used by this or successor
Products, or components of the Product compiled as residual
documentation.>
Product Completion
• Exit Criteria <This field specifies component values that are necessary and
sufficient for the subject Product to be considered finished.>

H-2 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

Table H-2: Conceptual Model Product 1.1 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P1.1 – Stakeholder Description.
Product Description
• Product Definition Document mapping stakeholders to roles and responsibilities
in the Conceptual Model effort.
• Product Purpose The purpose of this product is to identify the stakeholders of
this Conceptual Model development process and their
respective roles and responsibilities to enable staffing/tasking
of the Conceptual Model development effort, derivation of
stakeholder-related requirements and stakeholder-related
knowledge needs, and identification of subject-matter expertise
for knowledge acquisition.
• Product Content Conceptual model knowledge acquisition needs shall describe
at a minimum:
• Relevant Conceptual Model development responsibilities
identified and grouped into roles; and
• Stakeholders identified organizationally, mapped to
responsibilities and roles.
Desired:
• Stakeholder identities by name, along with contact
information.
• Product Structure/Format No mandated format.
Product Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• Product development may begin once PA1.1 begins.
Product Development Guidance
• Product Development See PA1.1.
Product Relationships
• Product – Process Relationships PA1.1 produces this product, which is used by PA2.1 and
PA2.4.
• Inter-Product Relationships This product may be developed concurrently with P1.2, P1.3,
and P1.4, but must be completed prior to the completion of
products from any later phases.
Associated Entities
• Tools None required.

RTO-TR-MSG-058 H-3
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

• Actor-Agents • Producer.
• Conceptual Model Developer.
• Information Pools Information pools relevant to this activity include:
• Points of contact lists.
• Employee roles.
• Organizational charts.
• Personnel databases, referrals, resumes, biographies.
• Any intermediate information generated during execution
of PA1.1.
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Product must contain comprehensive list of stakeholders
by organization as a minimum, mapped to all related
requirements and roles.

Table H-3: Conceptual Model Product 1.2 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P1.2 – Need Statement.
Product Description
• Product Definition Document that defines the intended use of the Conceptual
Model derived from the purpose and intended use of the M&S
effort.
• Product Purpose This product serves as the source from which to derive the set
of Conceptual Model requirements and knowledge needs
which are driven by M&S purpose and intended use.
• Product Content Description of Conceptual Model intended use driven by M&S
purpose and intended use.
• Product Structure/Format No mandated format.
Product Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• Product development may begin once PA1.2 begins.
Product Development Guidance
• Product Development See PA1.2.

H-4 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

Product Relationships
• Product – Process Relationships PA1.2 produces this product, which is used by PA2.1, PA2.2,
and PA2.4.
• Inter-Product Relationships This product may be developed concurrently with P1.1, P1.3,
and P1.4, but must be completed prior to the completion of
products from any later phases.
Associated Entities
• Tools Requirements Management tools optional.
• Actor-Agents • Producer.
• Conceptual Model Developer.
• Information Pools Information pools relevant to this activity include:
• Task orders.
• Mission needs statements.
• M&S needs statements.
• User requirement documents.
• Requests for proposal.
• Statements of work.
• Formal or informal directives.
• Test agreements.
• Any intermediate information generated during execution
of PA1.2.
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Product must contain comprehensive description of
Conceptual Model intended use sufficient to drive all
Conceptual Model requirements and knowledge needs
related to purpose and intended use of M&S.

Table H-4: Conceptual Model Product 1.3 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P1.3 – Constraints and Policies.
Product Description
• Product Definition Document that defines the constraints and policies to be
applied to the Conceptual Model effort based upon initial
direction and enterprise scope.

RTO-TR-MSG-058 H-5
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

• Product Purpose This product serves as a set of constraints upon the Conceptual
Model requirements and knowledge needs and impacts the
content of Conceptual Model requirements and knowledge
needs which are driven by constraints and policies.
• Product Content List of constraints and mandates affecting the Conceptual
Model development and design.
• Product Structure/Format No mandated format.
Product Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• Product development may begin once PA1.3 or PA1.4
begins.
Product Development Guidance
• Product Development Execute PA1.3 and PA1.4 concurrently or in any order.
Product Relationships
• Product – Process Relationships PA1.3 and PA1.4 produce this product, which is used by
PA2.1, PA2.2, and PA2.4.
• Inter-Product Relationships This product may be developed concurrently with P1.1, P1.2,
and P1.4, but must be completed prior to the completion of
products from any later phases.
Associated Entities
• Tools None.
• Actor-Agents • Producer.
• Conceptual Model Developer.
• Information Pools Information pools relevant to this activity include:
• Enterprise standard operating procedures.
• Industry and government standards.
• Enterprise executive mandates, law.
• Agency regulations.
• Agency directives.
• Written policy.
• Implied enterprise mandates.
• Documented resource constraints.
• Senior stakeholder preferences and requirements.
• Planning/budgeting/management limitations.
• Legacy M&S preferences and availability.
• Data availability.

H-6 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

• Information Pools (cont’d) • Enterprise preferences.

• Any intermediate information generated during execution of
PA1.3 and PA1.4.
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Product must contain comprehensive list of Conceptual
Model constraints and policies sufficient to constrain
Conceptual Model requirements and knowledge needs in
keeping with direction and enterprise mandates.

Table H-5: Conceptual Model Product 1.4 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P1.4 – Conceptual Model Meta Data.
Product Description
• Product Definition The conceptual model Meta data will address the conceptual
model, acting as its identifier. Conceptual models are stored
together with their Meta data specifying how they have been
produced, i.e., when, where, by whom, from what, using what
tool, and so on.
• Product Purpose This Meta data is necessary to ensure traceability and
reusability of the conceptual model.
• Product Content The Meta data template can accommodate a number of meta
features of the conceptual model, for example: Name, Type,
Version, Modification Date, Security Classification, Release
Restriction, Purpose, Application Domain, Description, Use
Limitation, Use History, V&V Data Elements, Keyword,
Implementation Dependencies, Point Of Contact (POC),
Reference and Glyph.
• Product Structure/Format A table with an entry for each data element in the Meta data.
Product Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• Product development may begin once PA1.1 begins.
Product Development Guidance
• Product Development The entire list of activities given in text of “Product 1.4
Guidance” should be completed.

RTO-TR-MSG-058 H-7
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

Product Relationships
• Product – Process Relationships Almost all the Process Activities in all the five Process Phases
will continuously fill the conceptual model Meta data table to
finally produce this product.
• Inter-Product Relationships This product will be developed concurrently with all other
products, and will be updated and completed till final
conceptual model is built.
Associated Entities
• Tools No specific tools or software to complete this product has been
identified.
• Actor-Agents No specific actor or agent has been identified to be alone
responsible for the development of this product, however all
actors and agents involved in the development of the
conceptual model are responsible for filling the conceptual
model Meta data with the relevant data from their activities.
• Information Pools Information pools relevant to this activity include:
• POC: Holds information about an organization or a person
having a particular role with respect to the conceptual
model.
• Model Identification: Can accommodate information
related to the identification of a conceptual model such as:
Name, Type, Version, Modification Date, Security
Classification, Release Restriction, Purpose, Application
Domain, Description, and Use Limitation.
• Use History: Provides a description of where this
conceptual model has been used.
• Reference: Specifies a pointer to additional sources of
information such as locations in XML documents and
references to ontologies (both domain and middle level)
which are used by the conceptual model.
• Implementation Dependencies: Maintains a log of all
dependencies determined during the development of this
conceptual model, such as domain ontologies or any other
new concept introduced by the process during the
implementation of this conceptual model.
• Key Word: Holds information about the key words of this
conceptual model for future use. It helps users in searching
for this conceptual model.
• Glyph: Is responsible for holding the image of conceptual
model, which can be used to visually represent a
conceptual model in a tool palette or a web repository.

H-8 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

• Information Pools (cont’d) • V&V Data Elements: The V&V process can produce an
enormous amount of data. These data are collected under a
label called V&V Data Elements and placed in the product
“conceptual model Meta data”. In the table below a list of
data items is presented together with the Process Activities
where that data is produced.
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Product development may end once the Meta data table is
completed.

Table H-6: Conceptual Model Product 2.1 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P2.1 – Conceptual Model Requirement Specification.
Product Description
• Product Definition The conceptual model requirement specification documents a
collection of verifiable properties, attributes and characteristics
of the Conceptual Model necessary for it to satisfy its intended
purpose.
• Product Purpose The conceptual model requirement specification shall
communicate to Conceptual Model designers and builders all
intended uses of the conceptual model, the aspects of the
mission space to be represented by it and the simulator features
to be supported.
• Product Content Requirement statements documenting the content of the
Conceptual Model and what criteria the Conceptual Model
must satisfy.
• Product Structure/Format Each requirement must be given a unique identifier. It may be
useful to categorizing the requirements as belonging to one of
the three “spaces” (Conceptual Model, mission, simulation).
Product Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• At least some of the content or the intended uses of the
simulation must have been documented.

RTO-TR-MSG-058 H-9
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

Product Development Guidance

• Product Development • Use the need statement and constraints and policies inputs to
identify requirements for the Conceptual Model.
• Analyze the requirements with respect to completeness,
consistency and correctness.
• Document the requirements in an appropriate format.
• Subject the requirement specification to review by competent
subject-matter experts and approval by the client.
Product Relationships
• Product – Process Relationships The conceptual model requirement specification is produced
by the process step P2.1 Identify, analyse and record User,
Mission and Simulation Space Requirements.
It serves as an input to the derivation of knowledge needs and
guides the development of the Conceptual Model design.
• Inter-Product Relationships The conceptual model requirement specification translates
P1.2 – Need Statement and P1.3 – Constraints and Policies into
verifiable requirements. It spells out in greater detail and more
precisely what is implied by these inputs. It influences the
P4.1 – Conceptual Model Design and indirectly the
P5.1 – Conceptual Model itself.
Associated Entities
• Tools A requirement management tool may prove useful to maintain
traceability from needs to requirements and Conceptual Model
content.
• Actor-Agents The conceptual model requirement specification is produced in
collaboration between mission space and Modeling SMEs and
subject to comment and approval by the client.
• Information Pools Information pools relevant to this activity include:
• Scenarios.
• Use cases.
• Repository of previously developed requirement
specifications.
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• The requirements for the Conceptual Model are sufficiently
detailed to allow unambiguous derivation of knowledge
needs and Conceptual Model design.

H - 10 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

Table H-7: Conceptual Model Product 2.2 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P2.2 – Conceptual Model Knowledge Acquisition Needs.
Product Description
• Product Definition Conceptual model knowledge acquisition needs describe the
scope and level of detail of knowledge needed by the
Conceptual Model developer to produce a Conceptual Model
satisfying the client’s need statement.
• Product Purpose Conceptual model knowledge acquisition needs shall guide the
Conceptual Model developer in collecting the necessary
knowledge and limit knowledge acquisition to the minimum
sufficient knowledge set.
• Product Content Conceptual model knowledge acquisition needs shall describe:
• The entities and activities in the mission space the modeler
must understand in order to represent them correctly and
with appropriate detail.
• The simulation technique, tools and legacy assets the
modeler must understand in order to represent
implementation requirements and constraints correctly.
• Product Structure/Format Textual description.
Product Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• At least some of the requirements for the Conceptual
Model must have been documented.
Product Development Guidance
• Product Development The developer must review the Conceptual Model requirement
specification in order to identify knowledge needed for
developing a Conceptual Model with sufficient fidelity to
satisfy its purpose. Such knowledge will typically include:
• Technologies applied in mission space entities and their
capabilities and limitations.
• Physical theories underpinning these technologies.
• Military tactics, techniques and procedures.
• Candidate simulation technologies.
• Legacy simulation models and their capabilities and
limitations.

RTO-TR-MSG-058 H - 11
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

PRODUCT CHARACTERISTIC
Product Relationships
• Product – Process Relationships Conceptual model knowledge acquisition needs are developed
in Process Activity PA2.4 – Derive Mission Space and
Simulation Space Knowledge Needs. Knowledge acquisition
needs form the input to Process Phase 3 – Acquire Conceptual
Model Knowledge.
• Inter-Product Relationships P2.2 – Conceptual Model Knowledge Acquisition Needs are
developed based on P2.1 – Conceptual Model Requirement
Specification. It is used in order to develop P3.1 – Validated
Knowledge.
Associated Entities
• Tools Not applicable.
• Actor-Agents The main agents participating in the development of
Conceptual Model knowledge needs are subject-matter experts
from the military mission domain, the military technology
domain and modeling and simulation domain.
• Information Pools Information pools relevant to this activity include:
• Previously developed knowledge needs descriptions.
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• A description of the knowledge needed for Conceptual
Model development has been developed that is sufficiently
comprehensive and specific to serve as guidance for the
knowledge acquisition phase.

Table H-8: Conceptual Model Product 3.1 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P3.1 – Validated Knowledge.
Product Description
• Product Definition The product Validated Knowledge is produced in the NATO
conceptual modeling Process Phase 3, called Acquire
Conceptual Model Knowledge. It is a validated piece of
knowledge, developed in response to an identified need and/or
requirement in the previous phase (2). It will be acquired from
authoritative knowledge sources, and then will be structured,
documented, and validated with respect to that authoritative
knowledge source.

H - 12 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

PRODUCT CHARACTERISTIC
• Product Purpose This will be the sole and very important product produced
during Phase 3. The next phase Design the Conceptual Model
will use this product to design a conceptual model. It is to say
that this product will serve as the foundation for designing and
building the final conceptual model.
• Product Content A structured and documented piece of knowledge which has
been validated with respect to the authoritative knowledge
sources.
• Product Structure/Format No mandated format.
Product Initiation
• Entrance Criteria Entrance criteria consists of the following activities,
availability of information and establishment of operational
capability:
• The knowledge needs and the requirements list from the
previous phase (2) are required.
• Access to an existing conceptual model repository with
reusable knowledge is beneficial and preferred.
• A list of the authoritative knowledge sources for the
required knowledge is also advantageous.
Product Development Guidance
• Product Development After identifying the needs and the requirements for the
knowledge which were done in the previous phase (2), the
authoritative knowledge sources for the particular knowledge
which is requested are identified. Next activity in the process
will start looking for the corresponding reusable knowledge
which may already exist in an existing conceptual model
repository, knowledge that can totally or partly be usable for
this new need. If not, the lack of knowledge and the gaps which
must be filled is identified. After that the knowledge will be
gathered, structured and documented. Next, there should be
enough information to either generate domain ontology for this
particular mission space or extend existing domain ontology.
Finally the validity of the acquired knowledge, with respect to
the authoritative knowledge sources, will be reviewed and this
product will be produced.
Product Relationships
• Product – Process Relationships This is the final product of Phase 3 in the NATO conceptual
model Process, and to produce it one should go through the
Process Activities PA3.1 to PA3.6.
• Inter-Product Relationships Products P2.1 – Conceptual Model Requirement Specification
and P2.2 – Conceptual Model Knowledge Acquisition Needs
are the predecessors and P4.1 – Conceptual Model Design is
the successor to this product.

RTO-TR-MSG-058 H - 13
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

PRODUCT CHARACTERISTIC
Associated Entities
• Tools This product is a result of a knowledge development process
and thus support of appropriate tools, methods, and techniques
from the knowledge development area is very much
appreciated, such as:
• Methodologies for acquisition of data, information, and
knowledge.
• Methodologies for documentation, representation, and
formatting the acquired knowledge.
• Tools for knowledge acquisition, representation,
formalization, etc.
• Tools for managing and maintaining ontologies.
• Actor-Agents • Knowledge engineer; to provide experience in acquiring,
gathering and compiling information.
• SME; to provide the domain and task knowledge.
• Analysis and formatting expert; experienced in the
appropriate formatting analysis method and technique.
• Ontology expert; experienced in mapping and interpreting
information held in the ontology, as well as being skilled
in how to further develop and extend ontologies.
• VV&A-agent; for validating the result.
• Information Pools Information pools relevant to this activity include:
• An existing conceptual model repository with reusable
knowledge.
• Domain ontologies in a knowledge base are very much
appreciated but not mandatory.
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• The Process Activity 3.6 – Review Validity of Acquired
Knowledge with Respect to the Authoritative Knowledge
Sources will guarantee that the product lives up to the
expectations.

Table H-9: Conceptual Model Product 4.1 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P4.1 − Conceptual Model Design.

H - 14 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

PRODUCT CHARACTERISTIC
Product Description
• Product Definition Document recording the conceptual model design decisions
with a justification of the elective choice.
• Product Purpose This product serves as a blue print to build the conceptual
model.
• Product Content Conceptual model design shall describe:
• A record of conceptual model composites: conceptual
primitives, model kinds, views, formalisms and notations.
• A justification of each design decision with traceability to
the driving requirement.
• Product Structure/Format No mandated format.
Product Initiation
• Entrance Criteria Product development may begin as soon as PP4 begins.
Product Development Guidance
• Product Development Iteratively:
• Make elective choices of conceptual model composites.
• Reconcile choices into a coherent conceptual model
composite combination.
• Evaluate the conceptual model design for adequacy/
relevance with the conceptual model requirements.
Product Relationships
• Product – Process Relationships The product exists in a preliminary form over PA4.1 to PA4.5
iterations. PA4.6 produces the final P4.1 product, which is used
by PA5.1. P4.6 also uses this product to evaluate the design
and update P1.4 – Conceptual Model Meta Data accordingly.
• Inter-Product Relationships This product completely relies on P2.1 – Conceptual Model
Requirement Specification and may be used to produce
P5.1 – Conceptual Model as soon as it has valuable input.
It may evolve iteratively with P5.1.
Associated Entities
• Tools No specific tool is required to document the selection of
conceptual model composites. A requirement management tool
could be useful to document traceability.
• Actor-Agents Producers.
• Information Pools Information pools relevant to this activity include:
• P2.1 – Conceptual Model Requirement Specification,
preliminary conceptual model design and literature surveys.

RTO-TR-MSG-058 H - 15
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

PRODUCT CHARACTERISTIC
Product Completion
• Exit Criteria Criteria-types for demonstration of satisfactory completion of
the subject activity, include the following:
• Product must pass PA4.6 evaluation against
P2.1 – Conceptual Model Requirement Specification.

Table H-10: Conceptual Model Product 5.1 Description.

PRODUCT CHARACTERISTIC
Product Identity
• Product Name and Aliases P5.1 – Conceptual Model.
Product Description
• Product Definition The authorized conceptual model work-product resulting from
the conceptual modeling activity and including collateral
materiel generated during the conceptual modeling effort as are
necessary and sufficient to qualify the conceptual model product
artefact per se and to support its evolution an use in context of
the simulation enterprise environment for which it was produced.
• Product Purpose The purpose of this work-product is to document in systematic,
persistent, authoritative and detailed form information
constituting the subject conceptual model in order to support
simulation development operations and maintenance as well as
model and simulation re-use throughout the duration of the
M&S enterprise.
• Product Content Product contains full and detailed articulation of the mission
space and simulation space ontology (entities, attributes,
behaviours, and relationships) that is necessary and sufficient
to support simulation development and life-cycle evolution.
• Product Structure/Format Product structure is elective in accordance with decisions made
during the conceptual modeling process; including particularly
election of conceptual model primitives, model kinds,
formalism, views, design features, mission- and simulation-
space information to be made manifest in the preliminary (and
final) conceptual model. Documentary conventions and media
are likewise left to the developer insofar as they are decided
explicitly, consistently, and in conformance with protocols and
strategic guidance associated with the M&S enterprise.
Product Initiation
• Entrance Criteria Product development proper (i.e., in addition to the
compilation of ancillary information products generated during
the conceptual modeling process), begins at completion of
Activity PP4.

H - 16 RTO-TR-MSG-058
 ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

PRODUCT CHARACTERISTIC
Product Development Guidance
• Product Development Activity PP5 and its sub-sections PA5.1 through PA5.5 specify
in detail product development activity.
Product Relationships
• Product – Process Relationships See PA5.1 – PA5.5.
• Inter-Product Relationships Products directly input to the generation of Product P5.1 are
P3.1 – Validated Knowledge and P4.1 – Conceptual Model
Design.
Associated Entities
• Tools CASE tools implied by the conceptual model design and
implementation process elements are relevant to the generation
of the subject product.
• Actor-Agents Conceptual product development team.
• Information Pools Information contained in P3.1 and P4.1 are required as input to
the subject work-product.
Product Completion
• Exit Criteria Approval of FINAL DRAFT conceptual model by authoritative
stakeholder(s).

RTO-TR-MSG-058 H - 17
ANNEX H – CONCEPTUAL MODEL PRODUCT DESCRIPTION

H - 18 RTO-TR-MSG-058
 Annex I – CONCEPTUAL MODEL EXAMPLES

This document deliberately presented guidance, as opposed to specification, to conceptual modeling to capture
the essential best-practices while remaining tailorable to a broad range of enterprise contexts. In this line,
this annex presents examples to illustrate the various Process Activities and Products.

The objective of this annex is to guide the reader in the implementation of a conceptual modeling process and
conceptual model products in its own enterprise context while avoiding restricting it to standard templates.
The examples are intended to clarify the most abstract parts of the guidance, to bring out the range of applicability
and to expose important issues.

For conciseness and time constraints, no thorough end-to-end example is included and trivial parts have been
omitted. The examples have been selected amongst a number of current enterprise practices. The domain
covered by the examples must not be taken as a limitation to the scope of applicability of the guidance.

Example I-1 differentiates between conceptual model space, mission space and simulation space requirements
and demonstrates how to derive knowledge needs from requirements. Example I-2 presents a method to:
gather, structure and document knowledge; generate domain ontology; and, use this knowledge to design and
build conceptual model artefacts. Example I-3 differentiates the representation of mission-space knowledge,
simulation-space knowledge and the conceptual model of a simulation. Example I-4 presents sample
conceptual model artefacts based on a community-specific conceptual model design. Finally, Example I-5
illustrates the iterative evolution of a conceptual model requirements, design and artefacts.

I.1 DEFINING CONCEPTUAL MODEL REQUIREMENTS AND DERIVING

KNOWLEDGE NEEDS

I.1.1 Process Activity 2.1 − Identify, Analyze and Record Conceptual Model, Mission and
Simulation Space Requirements
In Process Activity 2.1, the conceptual model requirements are identified, analyzed and recorded. It is suggested
to address the conceptual model requirement definition in terms of conceptual model space, mission space and
simulation space requirements. The objective of this example is to differentiate between conceptual model space,
mission space and simulation space requirements and to demonstrate what is inclusive in the conceptual
modeling process. This example was developed by the MSG-058 Task Group in testing several requirements
against the three-space classification. Although very partial, the artefact in Table I-1 is an example of
Product 2.1 – Conceptual Model Requirement Specification. The conceptual model requirement classification
may be arbitrary and is not error proof. The key point is to be all inclusive when capturing conceptual model
requirements.

RTO-TR-MSG-058 I-1
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-1: Examples of Conceptual Model Requirements Categorized in Terms

of Conceptual Model Space, Mission Space and Simulation Space.

Conceptual Model Space Mission Space Simulation Space

Conceptual Model requires… Conceptual Model requires… Conceptual Model requires…
To have views adapted to each To represent a battalion To represent a decision-maker
stakeholder training simulation
To be useful for interoperability To represent the command and To represent the live usage of a
within NATO control system decision support tool
To be readable by a computer To represent a peace keeping To represent fair fight
mission
To be readable in French To represent insurgents To represent an HLA simulation

I.1.2 Process Activity 2.4 − Derive Mission Space and Simulation Space Knowledge Needs
In Process Activity 2.4, the mission space and simulation space knowledge needs are derived. The objective of
this example is to demonstrate how to derive knowledge needs from requirements. Table I-2 presents knowledge
needs derived from a few requirements of Table I-1. Although very partial, the artefact in Table I-2 is an
example of Product 2.2 – Conceptual Model Knowledge Acquisition Needs. Deriving knowledge needs requires
experience and it is more easily done iteratively. The outcome can turn out to be arbitrary, thus a special effort
must be made to avoid preconceived ideas to produce an objective knowledge need statement.

Table I-2: Examples of Conceptual Model Knowledge Needs Derived from

Some of the Sample Conceptual Model Requirements of Table I-1.

Space Conceptual Model Requirements Conceptual Model Knowledge Needs

Simulation • To represent a battalion • Need knowledge on battalion
Space • To represent the live usage of a composition, humans, equipments, etc.,
+ decision support tool at the level of detail supported by the
Mission Space decision tool and at the level of fidelity
detectable by the tool
• Need knowledge from a tank driver,
from a physicist, etc.
Simulation • To represent the live usage of a • Need knowledge in the decision support
decision support tool tool inputs
• Need the minimum detectable
thresholds for each input
Simulation • To represent an HLA simulation • Need knowledge on the HLA concepts:
classes, interactions, time management,
data management, etc.
Simulation • To represent a decision-maker training • Need knowledge on the human interface
simulation • Need knowledge on the evaluation
metrics

I-2 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

I.2 FROM KNOWLEDGE ACQUISITION TO KNOWLEDGE USE IN A

CONCEPTUAL MODEL
This example is taken from the Swedish Defence Conceptual Modeling Framework (DCMF) Project [1].
The DCMF process could be an implementation of the proposed conceptual modeling guidance. It is divided
in four main phases: knowledge acquisition, knowledge representation, knowledge modeling and knowledge
use.

The example is written as straight forward steps to introduce sample product artefacts although, in reality,
the knowledge acquisition and the conceptual model construction have been done iteratively. The proposed
conceptual modelling guidance does not prevent to produce conceptual model artefacts to represent the
knowledge as it is acquired to help acquiring more knowledge. In fact, it is rather advised to do so. This is part
of the modeling art.

This example presents the conceptual model of a scenario, as opposed to the conceptual model of a system.
The sample scenario is taking place in Kosovo and its surroundings, in May 2002. NATO forces are conducting
a Peace Support Operation in order to regain stability and security in Kosovo. A Swedish patrol (KS05) from the
Swedish peace keeping force discovers a looted weapons depot and report this into the information system of the
Swedish Intelligence. An intelligence officer in Sweden receives the report and starts a further investigation.
Information from different sources leads to the estimate that the missing weapons might be smuggled to Sweden
by organized criminals. Cooperation between different military and civil organizations to acquire information
leads to the confiscation of the weapons in the harbor of Gothenburg in Sweden.

I.2.1 Process Activity 3.4 − Gather, Structure and Document Knowledge

Process Activity 3.4 consists in gathering, structuring and documenting knowledge to ultimately produce a
conceptual model. The objective of this example is to illustrate a method for performing Process Activity 3.4.

In this example, knowledge acquisition was performed using video clippings and in-depth interviews carried
out with subject-matter experts for further clarification and enrichment of the scenario description. It resulted
in a description of the scenario in natural language, for which an excerpt corresponding to paragraph 1 is
presented in Table I-3.

Table I-3: Sample Scenario Description in Natural Language (Paragraph 1).

A Swedish patrol from a battalion in Kosovo finds weapons in the forest near a village called Janjevo.
The finding is reported in the battalion’s intelligence report and this is transferred in code to
Stockholm. The information about the finding is received by the Intelligence Division at MUST and the
report is registered in the System. The information about the found weapons is made available for the
department of international intelligence (MUST IntUnd).

Then, implicit and explicit knowledge was represented from the natural language description. Table I-4
presents some implicit knowledge inferred from paragraph 1 of the scenario description in natural language.

RTO-TR-MSG-058 I-3
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-4: Sample Implicit Knowledge Inferred from the Scenario Description.

• There is a Peace Support Operation in Kosovo sometime in MAY 2002, of which the Swedish
contingent is a part of. (Inferred from background context material).
• Janjevo is a geographical location in Kosovo.
• There is a forest near Janjevo.
• Swedish troops go on regular patrol missions.
• There is a procedure (military) to be followed by any military PATROL if they are on a patrolling
mission. It also implies that there would be standard operating procedures and regulations
governing this process of patrolling.
• ‘Swedish’ implies that Sweden is a sovereign nation, and that it has military capability, and is part
of the UN Peace Support Operations.
• Weapons are hidden, that is, they are obscured from normal sight and they are not left for public
viewing.

Explicit knowledge can be extracted using different methods. Table I-5 presents the results of the Five Ws
method applied on paragraph 1 of the scenario description in natural language.

Table I-5: Sample Explicit Knowledge Extracted from the

Scenario Description Using the Five Ws Method.

Who Patrol from Swedish contingent Patrol: Military type Organization (under govt.
KS05 type object-type: Unit-Type: has Affiliation
object type relation to
Swedish Contingent: Object-Item-Group
Swedish: Affiliation
What Patrolling Patrolling: Action-task purpose: WHY AOI:
Location
When From 1st May to 31st May 2002
Why To secure AOI
Where AOI somewhere in Kosovo AOI: Specification detail AOI is both a
Location as well as a CONTROL FEATURE:
may even be a sub-type of control – feature
like ROUTE, etc.

Table I-6 presents the results of the Knowledge Meta Meta Model (KM3) methodology [1] applied on paragraph
1 of the scenario description in natural language.

I-4 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-6: Sample Explicit Knowledge Extracted from the

Scenario Description Using the KM3 Method.

Entity Type :: Swedish patrol

Entity Type :: Contingent in Kosovo
ElementComposition : <Swedish patrol , Contingent in Kosovo>
Entity Type :: Weapons
Entity Type :: Forest
Attribute : Close to ET:Janjevo, in kilometers
CompositionType : RangedAttribute
Domain : Distance
StartValue : 0
StopValue : 10
Entity Type :: Janjevo
Attribute : Village in Kosovo
CompositionType : RangedAttribute
Domain : Inhabitants
StartValue : 100
StopValue : 1000
Action Type :: Finds
Time : May 2002
RoleInAction : <finder, patrol>
RoleInOrganisationType : <patrol, ET: Swedish patrol>
Criterion :: SF: (prob 1, isStartCriterion t,
[Swedish patrol : onPatrol AND Forest AND Weapons])
State: found weapons
ActivityState : Finding weapons (has occurred) /* activity Finds has occurred */

Entity Type : Swedish patrol

State: alerted AND onPatrol
Entity Type :: Weapons
State: found

I.2.2 Process Activity 3.5 − Generate/Extend a Domain Ontology

In Process Activity 3.5, the knowledge captured in previous activities is formalized semantically as domain
ontology. The objective of this example is to illustrate how to generate domain ontology. This example uses
the knowledge of example I-2.1 to translate it in domain ontology.

The knowledge was modeled through a semantic mapping of the semi-structured information. The implicit
knowledge was merged with the explicit knowledge in a machine readable format, namely in the DCMF
ontology developed using the Web Ontology Language (OWL) [2]. Table I-7 lists some of the concept (class)
types that were instantiated to model the sample scenario paragraph.

RTO-TR-MSG-058 I-5
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-7: Sample Ontology Classes Instantiated to Document the Scenario.

• Action-Task
• Action-Task-Status
• Action-Objective-Type (securing area of interest)
• Action-Required-Capability (for patrol mission) related to
• Action-Event-Status: (through this it is associated to action-event. Finding weapons in a particular
action-task: patrolling.)
• Reporting-data
• Action-Event
• Object-Item-Group-Account: (the composition or relation of object types involved in the patrolling
action.)
• Capability: sub type: Mission-Capability: (specifies required parameters for carrying out a patrol.)
• Affiliation
• Context
• Location
• Control Feature
• Action-Temporal-Association: time events, sequences and info for placing the action tasks and events
in temporal sequence
• Object-Type:Equipment-Type:Non-Consummable-Equipment-Type:Weapons

Table I-8 presents an excerpt of the OWL code format for the Patrol Mission instance of the Action-Required-
Capability concept from the sample scenario paragraph. The artefact in Table I-8 is an example of Product 3.1
– Validated Knowledge.

I-6 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-8: Sample OWL Code for the Patrol Mission Instance of the
Action-Required-Capability Class Capturing the Scenario Knowledge.

<Action-Required-Capability rdf:ID="patrolreqdqty">
<quantifies>
<Mission-capability rdf:ID="patrolmission">
<capability-id rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>CMmscapability2</capability-id>
<capability-unit-of-measure-code rdf:datatype= "http://www.w3.org/2001/XMLSchema#string"
>square-metres-per-hour</capability-unit-of-measure-code>
<is-quantified-in rdf:resource="#patrolreqdqty"/>
<capability-subcategory-code rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>maximum-Range</capability-subcategory-code>
<capability-category-code rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>military-load-capability</capability-category-code>
<capability-day-night-code rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>day-and-night</capability-day-night-code>
</Mission-capability>
</quantifies>
<capability-id rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>CMmscapabilityid1</capability-id>
<is-minimum-required-for rdf:resource="#actioneventstatus1"/>
<action-required-capability-quantity rdf:datatype=

"http://www.w3.org/2001/XMLSchema#int">15</action-required-capability-quantity>
<action-id rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>patrol_reqd_qty</action-id>

</Action-Required-Capability>

Figure I-1 illustrates how the Patrol Mission instance is represented in the Protégé ontology editor [3]. In this
example, the capability categories have been imported from the Joint C3 Information Exchange Data Model
(JC3IEDM) [4], which is an illustration of knowledge reused following Process Activity 3.2.

RTO-TR-MSG-058 I-7
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-1: Sample Scenario Knowledge (Patrol Mission Object) in the Protégé Ontology Editor.

I.2.3 Process Phase 4 − Design Conceptual Model

A conceptual model is used to contain and represent the knowledge in a construct that will fit the type of
knowledge acquired during Process Phase 3 and that will allow to make use of that knowledge. In Process
Phase 4, the conceptual model design is driven by the intended purpose captured in Product 2.1 – Conceptual
Model Requirement Specification. The objective of this example is to illustrate a few design options to fit
different usages of the conceptual model. The artefact in Table I-9 is an example of Product 4.1 – Conceptual
Model Design.

I-8 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-9: Conceptual Model Design for the Scenario Description Example.

Component Design Build

Pool Swedish Contingent, MUST
Activity Patrol Mission, File Area Clear Report, etc.
Event Send Search, Interrogate Order/Request
Conceptual
Primitives Gateway Area Secure, Analyze Results
Actor Intel Officer, Depot Personnel
Use Case Report File to MUST, Check Information
System
Collaboration process diagram,
composed of 2 Abstract process
Model Kinds diagrams
Use Case
Simplest human understandable high- See Figure I-1
level description of the scenario
Views Collaboration between organizations See Figure I-3
Comparison of a scenario procedure to See Figure I-4
a recommended procedure
BPMN
Formalisms
Use Case
BPMN
Notations
Custom Pictogram

Process Activity 4.1 suggests that the conceptual model design may be influenced by the design of another
conceptual model being reused. In this example, no existing conceptual model was reused and no constraint of
that sort was imposed on the design.

In Process Activity 4.2, conceptual primitives fit for the type of knowledge are selected. The current example
involves the conceptual model of a military scenario. Therefore, appropriate conceptual primitives are actors,
activities, events, etc. Eligible model kinds that represent interactions between scenario elements include
collaboration, activity, sequence, and use case diagrams.

Different formalisms allow representing these combinations of conceptual primitives and model kinds: Petri
Nets, ontology, use case, BPMN, etc. In Process Activity 4.3, the formalism choice is influenced by the
conceptual model requirement specification. In this example, the conceptual model was intended for visualisation
purpose for communication with the subject-matter experts and for process optimization or conformance
checking by analysts. Graphical expressiveness was a key driver to present information to participants while
robust inference for system interoperability was not an intended use of the conceptual model. The use case
formalism was selected for its simplicity (only actors and use cases). BPMN [5] was privileged over Petri Nets
and ontology.

RTO-TR-MSG-058 I-9
ANNEX I – CONCEPTUAL MODEL EXAMPLES

The targeted stakeholders and intended purpose drive the selection of views during Process Activity 4.4.
Custom views can be created from the generic conceptual model content. For example, a simple high-level
description of the scenario is created for communication with the subject-matter experts. An organisational
collaboration view and a procedure comparison view are appropriate to the work of the process analysts.
In addition to these process views, others views could have useful to other usages, for example component or
deployment views to model the communications between information systems.

In Process Activity 4.5, a notation is selected to implement the chosen formalism. BPMN is a formalism that
comes with its own notation, a frequent practice in the modeling domain. The BPMN notation was chosen
over the UML notation because of its graphical expressiveness, a driving requirement in this example. BPMN
supports a few model kinds and their conceptual primitives (Pool, Activity, Event, Gateway). The same
Collaboration Process Diagram model kind is used to produce two different views. For the same reason,
a custom pictogram notation was selected over the UML notation to express the use case formalism.

Finally, as advised in Process Activity 4.6, the conceptual model conformance to the requirements should be
verified. Formal metrics could be derived to measure how fit is the conceptual model for the specific purposes.
In this example illustrated in Table I-9, only the overall stakeholders’ work efficiency proved the conceptual
model usefulness.

I.2.4 Process Phase 5 − Build Conceptual Model

In Process Phase 5, the validated knowledge produced (Product 3.1) is used to populate the content (conceptual
primitives) of the conceptual model. The objective of this example is to illustrate the different views generated
from the conceptual model based on the knowledge of example I-2.2 and the design choices (formalism,
notation, model kinds) summarized in Table I-9.

Figure I-2 presents the simplest human understandable high-level description of the scenario using a custom
pictogram notation to express the use case formalism. Figure I-3 shows the collaboration between organizations
and Figure I-4 compares the organizational procedures, both using collaboration process diagrams from
BPMN.

I - 10 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-2: Sample View of the Conceptual Model of the Scenario Allowing to Visualize
the Simplest Human Understandable High-Level Description of the Scenario.

RTO-TR-MSG-058 I - 11
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-3: Sample View of the Conceptual Model of the Scenario

Allowing Visualizing the Collaboration Between Organizations.

I - 12 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-4: Sample View of the Conceptual Model of

the Scenario Allowing to Compare Procedures.

The artefacts in Figure I-2 to Figure I-4, all together, are an example of Product 5.1 – Conceptual Model.

I.3 RELATION BETWEEN KNOWLEDGE REPRESENTATION AND A

CONCEPTUAL MODEL
The proposed conceptual modeling guidance does separate the knowledge documentation in Process Phase 3
from the conceptual model of a simulation in Process Phases 4 and 5. In reality, similar documentation
techniques may be used for both. The objective of this example is to differentiate the representation of mission-
space knowledge, simulation-space knowledge and the conceptual model of a simulation.

This example is taken from the Canadian IMAGE Project [6]. It presents the conceptual model of a military
mission to be simulated. The mission is a humanitarian operation to reconstruct a school in a rugged region
akin to Afghanistan. It involves convoys subjected to IEDs and evolving within a dynamical social terrain.
Blue friendly forces and red insurgents compete for recruiting the allegiance of the general population.
The convoys utilize different roads or tracks over time, some with limiting conditions related to the 3D
ruggedness of the terrain. Mine attacks occur with a probability that depends of the type of physical and social
grounds being travelled and type of carriers used.

RTO-TR-MSG-058 I - 13
ANNEX I – CONCEPTUAL MODEL EXAMPLES

I.3.1 Process Activity 3.4 − Gather, Structure and Document Knowledge

In Figure I-5, the mission-space knowledge is structured and document using conceptual graphs [7] in the
CoGUI tool [8]. In Figure I-6, the simulation-space knowledge is represented using a hierarchy of the simulation
framework concepts, in this case, a custom Canadian simulation framework.

Figure I-5: Sample Mission-Space Knowledge Documentation.

I - 14 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-6: Sample Simulation-Space Knowledge Documentation.

I.3.2 Process Phase 4 − Design Conceptual Model

In this example, the conceptual graph formalism was pre-selected as an arbitrary choice of the project Group.
The conceptual model design components were derived from the formalism. Table I-10 summarizes the
conceptual model design components for the conceptual model views of Figure I-5, Figure I-6 and Figure I-7.
The artefact in Table I-10 is an example of Product 4.1 – Conceptual Model Design.

RTO-TR-MSG-058 I - 15
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-10: Sample Conceptual Model Design for IMAGE.

Component Design Build

Concept Blue Convoy, Red, IED, etc.
Conceptual
Relation Agent, Object, Plan, etc.
Primitives
Context Attack, Concept Group
Model
Conceptual Graphs
Kinds
Mission Concepts Inter-Relation See Figure I-5
Views Simulation Concepts Hierarchy See Figure I-6
Simulation Specification for the Mission See Figure I-7
Formalisms Conceptual Graphs
Notations Conceptual Graphs

Figure I-7: Sample View from the Conceptual Model of a Simulation.

I.3.3 Process Phase 5 − Build Conceptual Model

Figure I-7 is a conceptual model view illustrating how the scenario concepts are mapped to simulation
concepts to describe the specification for the simulation. For example, the Blue and Red concepts become
simulation Agents; the Population, IED and School Project become simulation Patients; the Road Network
becomes a Decor; and, a simulation Scenario uses the defined Agents, Patients and Decor. Table I-10 includes
a mapping of the conceptual primitives and model kinds populated in the conceptual model.

The knowledge representations in Figure I-5 and Figure I-6 can be seen as other views of the conceptual model.
This example is representative of the reality where the conceptual model of a simulation often relies on
conceptual models of the mission space and the simulation space.

I - 16 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

I.4 COMMUNITY-SPECIFIC CONCEPTUAL MODEL DESIGN AND

ARTEFACTS
The conceptual modelers have access to a variety of design options. The conceptual model design components
being strongly interrelated, one design choice usually imposes constraints on the remaining component
options. This explains why different communities have created conceptual model design combinations tailored
to their specific domains. The objective of this example is to present sample conceptual model artefacts based
on a community-specific conceptual model design.

This example is taken from the United States OneSAF Project [10]. OneSAF Objective System (OOS) is a
composable Computer Generated Forces (CGF) simulation framework.

I.4.1 Process Phase 4 − Design Conceptual Model

The OneSAF Group has developed its own conceptual modeling formalism, called CML [11], adapted to
model simulations of the tactical military mission space. The CML formalism, notation and conceptual
primitives are illustrated in Figure I-8. CML uses a color-coded notation. Table I-11 presents the CML design
components.

Figure I-8: The CML Formalism, Notation and Conceptual Primitives.

RTO-TR-MSG-058 I - 17
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-11: Conceptual Model Design for OneSAF.

Component Design Build

Chassis, Articulation, Weapon, Sensor,
Element
Movement Adjudicator
Conceptual Event Activate Steering, Fire Command
Primitives Steering Behavior, Maintain SA, FDC Execute
Behavior
Fire Missions
Characteristic Movement Freedom, Rotational Freedom
Model
Conceptual Model Language
Kinds
Entity Entity Composition (see Figure I-9)
Views Common Unit Movement Control (see Figure I-10)
Battlefield Operating System Tactical Fire Direction Center (see Figure I-11)
Formalisms CML
Notations CML

I.4.2 Process Phase 5 − Build Conceptual Model

The OneSAF conceptual model was built according to the CML design. The column “Build” of Table I-11
above includes a few examples of how the components have been populated. Figure I-9 presents a sample
Entity view for the Entity Composition. Figure I-10 shows a sample Common view representing the Unit
Movement Control. Figure I-11 is an example of a Battlefield Operating System view for the Tactical Fire
Direction Center. These artefacts, all together, are part of Product 5.1 – Conceptual Model.

I - 18 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-9: Sample View from the OneSAF Conceptual Model Representing Entity Composition.

RTO-TR-MSG-058 I - 19
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-10: Sample View from the OneSAF Conceptual

Model Representing Unit Movement Control.

I - 20 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-11: Sample View from the OneSAF Conceptual

Model Representing Tactical Fire Direction Center.

I.5 ITERATIVE EVOLUTION OF CONCEPTUAL MODEL REQUIREMENTS,

DESIGN AND ARTEFACTS
Producing preliminary conceptual model artefacts contributes to the learning process and helps refining the
conceptual model requirements. The conceptual model design evolves accordingly over several iterations.
The objective of this example is to presents the iterative evolution of conceptual model requirements (Process
Activity 2.1), design (Process Phase 4) and artefacts (Process Phase 5). New requirements are challenging the
conceptual model design and new representation capabilities are incorporated to support the logical thinking
process.

RTO-TR-MSG-058 I - 21
ANNEX I – CONCEPTUAL MODEL EXAMPLES

This example is taken from the Canadian KARMA Project [11]. KARMA is a simulation framework for
guided-weapon engagement simulation intended to be used to develop countermeasures and to assess missile
performance. The project started from a blank page, without any legacy simulation system to integrate.

The first conceptual model requirement was to allow the project manager to represent the mission space
requirements. The informal view of Figure I-12 was developed using a MindMap design summarized in
Table I-12.

Figure I-12: Sample View of the KARMA Conceptual Model

Representing the Engagement Mission Space.

Table I-12: Conceptual Model Design for KARMA Engagement Mission Space.

Component Design Build

Entity Engagement, Platform, Missile, Autopilot
Conceptual
Relationship Has a
Primitives
Interaction Engages, Triggers, Senses
Model Kinds MindMap
Views Component Engagement Mission Space (see Figure I-12)
Formalisms MindMap
Notations Mind Manager® MindMap

I - 22 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

The second step involved the software architect and the subject-matter experts who needed a conceptual
model to support the simulation architecture design. The conceptual model was used to capture the subject-
matter experts’ knowledge, to engineer the knowledge in order to derive key concepts and to agree on a
common understanding to be used as the design reference. Figure I-13 shows the final key concepts diagram.
Several iterations of that diagram were produced during working sessions before to adopt a version satisfying
the reusability, interoperability and composability requirements. For example, an early version of that diagram
included threat/target and red/blue concepts, which was representative of the subject-matter experts’ bias.
The conceptual model proved to be useful to get rid of that bias. Other views, such as the sequence view in
Figure I-14 and the states view in Figure I-15, were used to complete the representation and proof the design.
Table I-13 summarizes the conceptual model design components based on the UML notation.

Figure I-13: Sample View of the KARMA Conceptual Model

Representing the Engagement Key Concepts.

RTO-TR-MSG-058 I - 23
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-14: Sample View of the KARMA Conceptual

Model Representing an Engagement Sequence.

Figure I-15: Sample View of the KARMA Conceptual

Model Representing an Engagement States.

I - 24 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

Table I-13: Conceptual Model Design for KARMA Engagement Key Concepts.

Component Design Build

Key Concept (Class) Physical Environment, Platform, Weapon,
Countermeasure
Property (Attribute) Signature, Dynamics, Equipments,
Atmosphere
Conceptual
Primitives Interaction Detect, Launch, Track, Deploy, Counter,
Exist In, Influence
Instance Launcher, Target
States Target Acquired, LockOn, Launched
Class Diagram
Model Kinds Sequence Diagram
State Diagram
Logicals Engagement Key Concepts (see Figure I-13)
Views Engagement Sequence (see Figure I-14)
Engagement States (see Figure I-15)
Formalisms UML
Notations UML

The conceptual model further evolved to allow the software developers to implement the simulation architecture.
The engagement concepts were expressed in the object-oriented formalism as shown in Figure I-16. Simulation
space concepts, such as the scheduler and logger mechanisms, were introduced as represented in Figure I-17.
Additional primitives (classes, attributes, methods, etc.) completed the model to allow the automatic generation
of a C++ implementation from the model.

RTO-TR-MSG-058 I - 25
ANNEX I – CONCEPTUAL MODEL EXAMPLES

Figure I-16: Sample View of the KARMA Conceptual Model Representing

an Engagement in the Object-Oriented Formalism.

Figure I-17: Sample View of the KARMA Conceptual Model Including Simulation
Space Concepts and Implementation-Related Conceptual Primitives.

I - 26 RTO-TR-MSG-058
 ANNEX I – CONCEPTUAL MODEL EXAMPLES

The complete conceptual allows for the complete traceability from needs to requirements to specification to
implementation. Each stakeholder is leveraging the conceptual model for his purpose.

I.6 CONCLUSION
This annex presented a limited number of examples complementing the best-practice guidance. In the interim
of a standard conceptual model specification, each enterprise has to specify its own conceptual modeling
process and conceptual model products, to a level down to actual templates if required. The proposed
guidance should serve as reference and the examples, as inspiration. Every customization of the guidance will
contribute to the science of conceptual modeling and will bring valuable experience to the standardization
table.

I.7 REFERENCES
[1] Mojtahed, V., Garcia Lozano, M., Svan, P., Andersson, B. and Kabilan, V., DCMF-Defence CM
Framework, Systems Technology Methodology Report Number FOI-R–1754–SE, ISSN 1650-1942,
FOI-Swedish Defence Research Agency, November 2005, UML: http://www2.foi.se/rapp/foir1754.pdf.

[2] Web Ontology Language (OWL), UML: http://www.w3.org/2004/OWL/.

[3] Protégé ontology editor, URL: http://protege.stanford.edu/.

[4] Joint C3 Information Exchange Data Model (JC3IEDM), URL: http://www.mip-site.org/publicsite/04-

Baseline_3.0/JC3IEDM-Joint_C3_Information_Exchange_Data_Model/.

[5] Business Process Modeling Notation (BPMN), URL: http://www.bpmn.org/.

[6] Lizotte, M., Poussart, D., Bernier, F., Mokhtari, M., Boivin, E. and DuCharme, M., IMAGE: Simulation
for Understanding Complex Situations and Increasing Future Force Agility, Proceedings of the Army
Science Conference 2008, Orlando, FL, USA, December 2008.

[7] Conceptual Graphs, URL: http://conceptualgraphs.org/.

[8] CoGui, URL: http://www.lirmm.fr/cogui/.

[9] OneSAF, URL: http://www.onesaf.net/.

[10] Karr, C.R., CM in OneSAF Objective System, Proceedings of the I/ITSEC 2005 Interservice/Industry
Training, Simulation and Education Conference, Paper 2005, Orlando, FL, USA, 28 November –
1 December 2005.

[11] Harrison, N., Gilbert, B., Jeffrey, A., Lestage, R., Lauzon, M. and Morin, A., KARMA: Materializing
the Soul of Technologies into Models, Proceedings of the I/ITSEC 2005 Interservice/Industry Training,
Simulation and Education Conference, Paper 2256, Orlando, FL, USA, 28 November-1 December 2005.

RTO-TR-MSG-058 I - 27
ANNEX I – CONCEPTUAL MODEL EXAMPLES

I - 28 RTO-TR-MSG-058
 Annex J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Abstract 4.a) Withdrawn or separated from matter, from material embodiment, OED
(Adjective) from practice, or from particular examples. Opposed to concrete.
Abstraction Denotes the essential characteristics of an object that distinguish it from M&S Glossary,
(Noun) all other kinds of objects and thus provide crisply defined conceptual DMSO Survey
boundaries, relative to the perspective of the user. of Semi-
Automated
Forces
Abstraction 1) The process of selecting the essential aspects of simuland to be Houghton
(Noun/Verb) represented in a model or simulation while ignoring those aspects that Mifflin Co.,
are not relevant to the purpose of the model or simulation. 2) The set of Webster’s II,
elements produced by this process. 3) The act or process of separating New College
the inherent qualities or properties of something from the actual physical Dictionary
object or concept to which they belong. 4) A product of this process, as a
general idea or word representing a physical concept.
Abstraction An intuitive technique transforming the essential features of a real Jake Borah
(Noun) system into a different form. Tutorial
Abstraction Denotes the essential characteristics of an object that distinguish it from OED
(Noun) all other kinds of objects and thus provide crisply defined conceptual
boundaries, relative to the perspective of the user.
Abstraction Generalization of a concept, idea, or symbol versus specialization.
(Verb)
Abstraction Process of generalization by reducing the information content of a M&S Glossary
(Verb) concept 3264 or an observable phenomenon typically in order to retain
only information 3265 which is relevant for a particular purpose.
Abstraction The act of process of separating in thought, of considering a thing OED
(Verb) independently of its associations; or a substance independently of its
attributes; or an attribute or quality independently of the substance to
which it belongs.
Abstractness Degree of abstraction.
Abstractness Relates to the degree to which the conceptual model abstracts or Text
symbolizes the referent.
Accessibility The ease of approaching, entering, obtaining, or using. DoD “Data
Quality
Assurance
Procedures”,
DoD 8320.
1-M-3

RTO-TR-MSG-058 J-1
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Accreditation Official acceptance or certification that a model, the data for a Report from
simulation or a simulation is suitable for a specific purpose or the Fidelity
application. Implementation
Study Group
Accuracy Correctly know in quantity.
Accuracy The degree to which a parameter or variable or set of parameters or Report from
variables within a model or simulation conform exactly to reality or to the Fidelity
some chosen standard or referent. See resolution, fidelity, and precision. Implementation
Study Group
Actions 1) The process or conditions of acting or doing (in the widest sense), the Houghton
exertion of energy or influence; working, agency, operation. a. Of Mifflin Co.,
persons. (Distinguished from passion, from thought or contemplation, Webster’s II,
from speaking or writing.) b. Of things. (Distinguished from inaction, New College
repose.) quantity of action, in Physics: The momentum of a body Dictionary
multiplied into the time. 3) a. A thing done, a deed, not always
distinguished from ACT, but usually viewed as occupying some time in
doing, and in pl. referred to habitual or ordinary deeds, the sum of which
constitutes conduct.
Actions Elementary components of behaviour of an entity, object or system.
Activity A task that consumes time and resources and whose performance is “IEEE Standard
necessary for a system to move from event to the next. Glossary of
Modeling and
Simulation
Technology”,
IEEE Std 610.
3-1989, nd
Activity Model A model of the processes that make up a functional activity showing DoD, “Data
inputs, outputs, controls, and mechanisms through which the processes Administration
of the functional activity are or will be conducted. Procedures”,
DoD 8320.1-M
Actor The subject (perpetrator, agent) of action. Text
Adaptability The quality of being adaptable; capacity of being adapted or of adapting
oneself; potential fitness for one or another intended purpose.
(See Tailorability)
Aggregation The ability to group items, whether entities or processes, while DoD M&S
preserving the effects of item behavior and interaction while grouped. Master Plan,
A relationship between objects in the data model where one object DoD 5000-59-P,
contains other objects. (See Disaggregation). SEDRIS
Glossary
Aggregation A whole composed of many particulars; a mass formed by the union of OED
(Noun) distinct particles; a gathering, assemblage, collection.
Also Aggregate

J-2 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Aggregation The action or process of collecting particles into a mass, or particulars OED
(Verb) into a whole; or of adding one particle to an amount; collection,
assemblage, union.
Analytical Frame In this context – one or another way of looking at the world. Alternatives Text
of such frames include for instance: ontology, systems engineering,
software engineering, and knowledge management; together with a wide
variety of tools and techniques for pursuing explication of each frame,
such as model driven architecture, Knowledge Acquisition / Knowledge
Engineering (KA/KE) assets, systems engineering tools, etc.
Architecture The structure of components in a program or system, their DoD, M&S
interrelationships, and the principles and guidelines governing their Master Plan,
design and evolution over time. DoD 5000-59-P
Artefact All or part of a work-product generated by the Task Group or by M&S
conceptual model practitioners in generating, and documenting a
simulation conceptual model.
Artefact A) n. Anything made by human art and workmanship; an artificial OED
product. In Archaol applied to the rude products or original work mans
hip as distinguished from natural remains. B) In technical and medical
use, a product or effect that is not present in the natural state (of an
organisms, etc.) but occurs during or as a result of investigation or is
brought about by some extraneous agency.
Attribute In object oriented analysis, (and simulation representation) the set of
characteristics of some class inherited by its specializations and
instances – which together with its behaviours and relationships,
completely describes the state of an object of system of object entities.
Attribute 1) A quality or character ascribed to any person or thing, one which is in OED
common estimation or usage assigned to him; hence, sometimes, an
epithet or appellation in which the quality is ascribed. 4) A quality or
character considered to belong to or be inherent in a person or thing; a
characteristic quality. c. in Logic, that which may be predicated of any
thing; a quality, mode of existence, affection; strictly an essential and
permanent quality.
Attribute 1) A property or characteristic of one or more entities or objects DoD, “Data
(e.g., COLOR, WEIGHT, SEX). 2) A property inherent to an entity or Administration
associated with that entity for database purposes. 3) A quantifiable Procedures”,
property of an object (e.g., the color of a building or the width of a DoD 8320.1-M,
road). SEDRIS
Glossary
Authoritative Data A data source whose products have undergone producer data The Fidelity
Source verification, validation, and certification activities. ISG Glossary
Authoritative Models, algorithms, and data that have been developed or approved by The Fidelity
Representation a source which has accurate technical knowledge of the entity or ISG Glossary
phenomenon to be modeled and its effects.

RTO-TR-MSG-058 J-3
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Behavior The means an actor performs or uses to actuate events. Text
Behavior 1) For a given object, how attribute value changes affect or are affected Report from
by the attribute value changes of the same or other objects. 2) The way the Fidelity
in which a system responds to stimuli over time. Implementation
Study Group
Best-Practice Guidance containing prescriptive instructions of such quality that is not
Standard exceeded elsewhere.
Business The environment including entities, processes, and active agents
Ecosystem constituting a universe of operations for one or another set of business
transactions or operations. (See Economic Ecosystem)
CASE Computer Aided Systems Engineering.
Class A description of a group of objects with similar properties, common The Fidelity
behavior, common relationships, or common semantics. ISG Glossary
Class Hierarchy A specification of a class, sub-class, or “is-a-kind-of” relationship The Fidelity
between object classes in a given domain. ISG Glossary
COTS A good that is available in the private sector market, normally at a price
established by supply and demand and distributed under proprietary
licensing.
Commonality Consistency between or among entities of processes facilitating the
capability to communicate, influence one another, and generally
cooperate to some intended constructive purpose.
Completeness Degree to which a work-product exhausts its requirements. All needs,
constraints and policies are covered by one or more requirements, or all
requirements are covered by the content of the consequent conceptual
model product.
Composability Capacity or suitability to be subject to composition.
Composition Act of combining elements or components into an intended aggregate
entity or system.
Computational A model consisting of well-defined procedures that can be executed on a “IEEE
Model computer (e.g., a model of the stock market, in the form of a set of Standard
equations and logic rules). Glossary of
M&S
Terminology”,
IEEE Std
610.3-1989, nd.
Computer Science Computer Science or Computing Science (abbreviated CS) is the study http://en.wikipe
of the theoretical foundations of information and computation and of dia.org/wiki/Co
practical techniques for their implementation and application in mputer_science
computer systems.

J-4 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Computer A dynamic representation of a model, often involving some combination The Fidelity
Simulation of executing code, control/display interface hardware, and interfaces to ISG Glossary
real-world equipment.
Computer A set of computer programs, procedures, and associated documentation The Fidelity
Software concerned with the operation of a data processing system (e.g., compilers, ISG Glossary
library routines, manuals, and circuit diagrams); software.
Concept Roughly equivalent to the “idea in the mind” resulting from a perception David Hume
or the mental processing of perceptions and existing ideas.
Concept In normal language, concept may mean “something out there in the Ray Jackendoff
world” or alternatively and inconsistently, “an entity within one’s head”
Formally, a concept may be defined as: “A mental representation that
can serve as the meaning of a linguistic expression.”
Concept Concepts are the Materials of reason and knowledge. John Locke
Concept “… concepts are [the] constituents of thought.” “Conceptions explain Jesse Prinz
epistemological facts (e.g., how we judge that something is a dog), while
concepts explain meta-physical facts (e.g., what makes something a
dog).” “… concepts just are perceptual detection mechanisms.”
“Concepts are prototypes, where prototypes are perceptually derived
representations that can be recruited by working memory to represent a
category.” Therefore, “[i]f concepts are prototypes, thinking is a
simulation process.”
Concept An abstract idea or a mental symbol, typically associated with a Text
corresponding representation in language or symbology that denotes all
of the objects in a given category or class of entities, interactions,
phenomena, or relationships between them.
Conceptual Atomic components from which conceptual model specifications are Text
(Model) Primitives composed. (See Primitives)
Conceptual One of “… a small set of major ontological categories (or conceptual Ray Jackendoff
Category ‘parts of speech’) such as Thing, Event, State, Place, Path, Property and
Amount.”
Conceptual The major units of conceptual structure, each of which belongs to a Ray Jackendoff
Constituent small set of conceptual categories.
Conceptual Model Model that abstractly represents a referent.
Conceptual Model A simulation developer’s method of translating modeling requirements Dale Pace
into a detailed design framework-[use].
Conceptual Model 1) A description of the content and internal representations that are the Report from
users’ and developer’s combined concept of the model including logic the Fidelity
and algorithms and explicitly recognizing assumptions and limitations. Implementation
2) An implementation-independent description of the content and Study Group
internal representations that represent the sponsor’s, user’s and
developer’s combined concept of the system or simulation under
development including logic, architecture, algorithms, available data and
explicitly recognising assumptions and limitations.

RTO-TR-MSG-058 J-5
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Conceptual Model Attributes or qualia of a conceptual model, such as Quality, utility,
Characteristic formality, abstractness, etc.
Conceptual Model Parts comprising a conceptual model, such as conceptual primitive,
Components model kind, view, formalism, notation, etc.
Conceptual Model See ‘Design’ and Section 6.2.8. Text
Design
Conceptual Model The conceptual model of the Mission Space integrated with the Text
of (a) Simulation conceptual model of Simulation Space.
Conceptual Model First abstraction of the real world that serves as a frame of reference for The Fidelity
of the Mission simulation development by capturing the basic information about ISG Glossary
Space (CMMS) important entities involved in any mission and their key actions and
interactions; simulation-neutral view of those entities, actions, and
interactions occurring in the real world.
Conceptual Model The totality of features and characteristics of a conceptual model that
Quality bear on its ability to satisfy stated or implied needs.
Conceptual Model See ‘Requirements’ and Section 6.2.5. Text
Requirements
Conceptual Model Domain to which conceptual model representation refers.
Space
Conceptual A descriptive representation of data and data requirements that supports DoD, “Data
Schema the “logical” view or data administrator’s view of the data requirement. Administration
This view is represented as a semantic model of the information that is Procedures”,
stored about objects of interest to the functional area. This view is an DoD 8320.1-M
integrated definition of the data that is unbiased toward any single
application of data and is independent of how the data is physically
stored or accessed.
Conceptual A self-consistent style of abstraction and associated conceptual W.V. Quine
Scheme/Schema categories and primitives or constituents employed in personal or
enterprise perception and descriptive communication.
Conceptualization “… an abstract simplified view of the world.” (See Concept) Dragan Gasevic
Consistency Degree to which components of a whole are congruent or are similarly
conceived, configured, and expressed. Lack of incongruity or logical
incompatibility among such components.
Consumer Role position designating person or organization that will put the
conceptual model to use in order to implement an executable model to
satisfy the sponsor’s needs.
Consumer 1) Understanding operational issues and mission context. 2) Producing Text
(Analyst) relevant analysis products.
Consumer (Model 1) Understanding operational issues and mission context.
Implementer) 2) Implementation of simulation model.

J-6 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Consumer (Model 3) Verification of simulation model compliance with conceptual model.
Implementer)
(cont’d)
Consumer 1) Understanding operational issues and mission context. 2) Producing Text
(Training System adequate training environment.
Developer)
Consumption Process of using products in order to satisfy needs and desires (self- Metrics for
generated or imposed; real or imagined) so that the products are used up, M&S
transformed, or deteriorated in such a manner as not to be either reusable Investments
or recognizable in their original form. In economics, the final using up
of goods and services. The term excludes the use of intermediate
products in the production of other goods (e.g., the purchase of
buildings, machinery, or software by an enterprise). Also, Consumption
can be viewed as a basically subjective phenomenon, with individual or
organizational utility, or satisfaction, having primary importance in the
valuation of the product(s) consumed.
Consumption The process of expending money by a/an organization/individual/ Metrics for
department/entity/project that does not result in an increase of assets. M&S
Investments
Control Defines what can occur within an activity. Constraint upon behaviour of Text
relevant entity.
Correctness The property of an artefact (e.g., a conceptual model) to comply with
formal rules and bodies of reference information for its representation
and for the transformation of its representation into another one.
Correctness All needs, constraints and policies have been interpreted as the sponsor
intended.
Correctness Degree to which the Conceptual Model implementation is free of error
and of sufficient precision.
Cost “The amount or equivalent paid or charged for something” or the “loss
or penalty incurred especially in gaining something” (http://www.mer
riam-webster.com/dictionary/cost). Normally, the value of a liquid asset
or cash that must be paid for a good or service. (See Value)
Cost Benefit A method of reaching economic decisions by comparing the costs of
doing something with its benefits. Especially useful when contributing
factors are inherently monetary – can be complex when the decision
being contemplated involves some cost or benefit for which there is no
market price or which, because of an externality, is not fully reflected in
the market price.
Credibility Quality of being credible, i.e., capable of being believed; believable. OED
Criteria The value of a variable or parameter against which some
commensurable measured or observed value relevant to an object or
process of interest can be compared for purposes of evaluation (singular,
criterion).

RTO-TR-MSG-058 J-7
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Custodian The person or organization that ensures that the repository is maintained
and policies adhered to.
Custodian Provide services for effective reuse of available knowledge and
Conceptual Model components.
Customer The buyer of a good or service, sometimes, but not necessarily the also
the consumer – user.
Customer Buyer of some good or service. Sometimes, in prospectus, having Metrics for
bought in the past or considered likely to buy in the future. Customers M&S
normally have discretionary choice whether to buy a good or service, Investments
but normally do not effect price in public sector markets. Customers in
government economic transactions normally negotiate with seller to
control price, rate, quality, and risk. Influence of customers in private
sector markets seldom persists beyond the sales event except insofar as
warranty or goodwill considerations pertain.
Data 1) A representation of facts, concepts, or instructions in a formalized DoD, “Data
manner suitable for communication, interpretation, or processing by Administration
humans or by automatic means. 2) Assumed, given, measured, or Procedures”,
otherwise determined facts or propositions used to draw a conclusion DoD 8320.1-M,
or make a decision. Houghton
Mifflin Co.,
Webster’s II,
New College
Dictionary,
1995
Data Architecture The framework for organizing and defining the interrelationships of data DoD, “Data
in support of an organization’s missions, functions, goals, objectives, Administration
and strategies. Data architectures provide the basis for the incremental, Procedures”,
ordered design and development of databases based on successively DoD 8320.1-M
more detailed levels of data modeling.
Data Dictionary A specialized type of database containing Meta data that is managed by The Fidelity
a data dictionary system; a repository of information describing the ISG Glossary
characteristics of data used to design, monitor, document, protect, and
control data in information systems and databases.
Data Model 1) The user’s logical view of the data in contrast to the physically stored DoD, “Data
data, or storage structure. 2) A description of the organization of data in Administration
a manner that reflects the information structure of an enterprise. Procedures”,
3) A description of the logical relationships between data elements DoD 8320.1-M,
where each major data element with important or explicit relationships is SEDRIS
captured to show its logical relationship to other data elements. Glossary
Data Repository A specialized database containing information about data such as
meaning, relationships to other data, origin, usage, and format, including
the information resources needed by an organization.

J-8 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Data 1) A format used to describe some type of data. 2) A variety of forms Report from
Representation used to describe a terrain surface, the features placed on the terrain, the the Fidelity
dynamic objects with special 3-D model attributes and characteristics, Implementation
the atmospheric and oceanographic features, and many other forms of Study Group,
data. SEDRIS
Glossary, 29
June 1998
Data Source 1) An organization or subject-matter expert who, because of either Report from
mission or expertise, serves as a data producer. 2) A publication that the Fidelity
serves as an authoritative source of data used in a model or simulation. Implementation
Study Group
Data Validation The documented assessment of data by subject area experts and its DoD, “M&S
comparison to known values. Master Plan”,
DoD 5000-59-P
Data Verification Data producer verification is the use of techniques and procedures to DoD, “M&S
ensure that data meets constraints defined by data standards and business Master Plan”,
rules derived from process and data modeling. Data user verification is DoD 5000-59-P
the use of techniques and procedures to ensure that data meets user
specified constraints defined by data standards and business rules
derived from process and data modeling, and that data are transformed
and formatted properly.
Deaggregation The ability to separate grouped items, whether entities or processes, The Fidelity
(Disaggregation) while preserving the effects of item behavior and interaction whether ISG Glossary
grouped or separated.
Design (noun) 1. a. A plan or scheme conceived in the mind and intended for subsequent OED
execution; the preliminary conception of an idea that is to be carried into
effect by action.
Design (noun) 2. The purposeful or inventive arrangement of parts or details. The free
Dictionary,
http://www.thef
reedictionary.co
m/design
Design (noun) The arrangement of elements or details in a product or work of art. http://www.mer
riam-webster.
com/dictionary/
design?show=1
&t=130340359
0
Design (noun) A plan or drawing produced to show the look and function or workings Wikipedia
of a building, garment, or other object before it is built or made.

RTO-TR-MSG-058 J-9
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Design (n.) The visual characteristics embodied in or applied to an article [in patent http://www.uspt
law]. o.gov/web/offic
es/pac/mpep/do
cuments/1500_
1502.htm
Detail 1.a. The dealing with matters item by item, detailed treatment; attention OED
to particulars … i.e., to deal or treat with a thing in its individual
particulars.
Detail Having to do with precision of identification or description.
Developers Agents responsible for development of conceptual models. Text
Disaggregate Activity that decomposes an aggregated entity into multiple entities Report from
representing its components. the Fidelity
Implementation
Study Group
Domain 3.a. fig. A sphere of thought or action; field province, scope of a OED
department of knowledge, etc.
Domain The physical or abstract space in which the [relevant] entities and The Fidelity
processes operate. ISG Glossary
Domain Analysis The process of identifying, acquiring and evaluating the information Report from
related to a problem domain to be used in specifying and constructing the Fidelity
a model or simulation. Implementation
Study Group
Domain of Knowledge related to a given domain.
Knowledge
Domain Ontology The ontology of a given domain.
Economic An economic community supported by a foundation of interacting
Ecosystems organizations and individuals--the organisms of the business world.
This economic community produces goods and services of value to
customers, who are themselves members of the ecosystem. The member
organizations also include suppliers, lead producers, competitors, and
other stakeholders. Over time, they co-evolve their capabilities and
roles, and tend to align themselves with the directions set by one or more
central companies. Those companies holding leadership roles may
change over time, but the function of ecosystem leader is valued by the
community because it enables members to move toward shared visions
to align their investments and to find mutually supportive roles.
(Source: Predators and Prey: A New Ecology of Competition, by
James F. Moore, Harvard Business Review, May/June 1993).

J - 10 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Emulate To represent a system by a model that accepts the same inputs and “IEEE
produces the same outputs as the system represented (e.g., to emulate Standard
an 8-bit computer with a 32-bit computer). Glossary of
M&S
Terminology”,
IEEE Std 610-
3-1989, nd
Encapsulation The process of hiding the details of an object that do not contribute to its The Fidelity
essential characteristics. ISG Glossary
Enterprise One or more organizations under common control. Generally refers to Text
the broadest scope of organizations and operational process relevant to
the subject discussion rather than to individual components thereof.
Enterprise The single, unified Concept of Operations (CONOPS) whereby the
Concepts-of- multiple organizations comprising an enterprise ensemble cooperate.
Operations Enterprise CONOPS often entail more formality, and systematic
consensus-based collaboration, as well as more explicitly coordinated
and documented modeling and simulation development and employment
than is common in more parochial contextual environments.
Enterprise Context The operational or environmental context at which enterprise
considerations agents, relationships, and transactions are relevant.
Enterprise Model An information model(s) that presents an integrated top-level DoD, “Data
representation of processes, information flows, and data. Administration
Procedures”,
DoD 8320.1-M
Enterprise-Based Operations, process, or work-products typically tailored-to or used-in or
generated-from enterprise-style circumstances.
Entity A distinguishable person, place, thing, event or concept about which The Fidelity
information is kept. Something that exists as a particular and discrete ISG Glossary
unit.
Entity/Entities A thing. Usually an element or component part of the mission space or
simulation space representation domain of a conceptual model of a
simulation. Note that entity is distinguished throughout the document
from ‘object’, whose specific connotations in object-oriented analysis,
and object-based software development have been intentionally avoided.
Entity Relationship A graphic representation of a data model. The Fidelity
Diagram (ERD) ISG Glossary
Epistemology The theory or science of the method or grounds of knowledge. OED
Evaluator Person or organization that validates the conceptual models, ensuring
validity of Conceptual Model and compliance with requirements.
Event Occurrence of the change of value of one or another of the ‘state
variables’ of the simulation representation information set.

RTO-TR-MSG-058 J - 11
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Event (cont’d) In ‘discrete-event simulation’ techniques, events occupy no duration but
have as attributes the value of the simulation time at which the related
represented state-change occurred.
Event An action composed of activities. Text
Event A change in an object attribute value, an interaction between objects, The Fidelity
an instantiation of a new object, or a deletion of an existing object that ISG Glossary
is associated with a particular point on the federation time axis. An
individual stimulus from one object to another at a particular point of
time.
Executability Ability of prescriptive guidance to be executed or accomplished.
Alternatively, the ability of a computer program, algorithm or simulation
to be made to operate according to program guidance and consistent
with expectation.
Expressiveness Efficiency of communication of information in an expression.
Information density combined with readability or correct interpretation.
Extensibility The ability of a data structure to accommodate additional values or DoD, “Data
iterations of data over time without impacting its initial design. Quality
Assurance
Procedures”,
DoD 8320.1-M-
3, DoD, “Data
Administration
Procedures”,
DoD 8320.1-M
External Schema A logical description of an enterprise that may differ from the DoD, “Data
conceptual schema upon which it is based in that some entities, Administration
attributes, or relationship may be omitted, renamed, or otherwise Procedures”,
transformed. DoD 8320.1-M
Federation Object An identification of the essential classes of objects, object attributes, The Fidelity
Model (FOM) and object interactions that are supported by a High Level Architecture ISG Glossary
federation. In addition, optional classes of additional information may
also be specified to achieve a more complete description of the
federation structure and/or behavior.
Fidelity Accuracy or correctness of representation – the degree to which the
representation conforms in resemblance to the referent.
Fidelity 1) The degree to which a model or simulation reproduces the state and Report from
behavior of a real-world object or the perception of a real-world object, the Fidelity
feature, condition, or chosen standard in a measurable or perceivable Implementation
manner; a measure of the realism of a model or simulation; faithfulness. Study Group
Fidelity should generally be described with respect to the measures,
standards or perceptions used in assessing or stating it. See accuracy,
sensitivity, precision, resolution, repeatability, model/simulation
validation.

J - 12 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Fidelity (cont’d) 2) The methods, metrics, and descriptions of models or simulations used Report from
to compare those models or simulations to their real-world referents or the Fidelity
to other simulations in such terms as accuracy, scope, resolution, level of Implementation
detail, level of abstraction and repeatability. Fidelity can characterize the Study Group
representations of a model, a simulation, the data used by a simulation
(e.g., input, characteristic or parametric), or an exercise. Each of these
fidelity types has different implications for the applications that employ
these representations.
Formal Conceptual A conceptual model with the following attributers or consequences of Jake Borah
Model formality: Tutorial
- Unambiguous description of model structure separated from software
implementation.
- Useful once users and colleagues understand informal model and want
more detail.
- Used as an aid to detect omissions and inconsistencies and resolve
ambiguities inherent in informal models.
Formal Language In logic, a set of symbols together with a set of formation rules that The Fidelity
designate certain sequences of symbols as well-formed formulas, and a ISG Glossary
set of rules of inference (transformation rules) that, given a certain
sequence of well-formed formulas, permits the construction of another
well-formed formula. The symbols chosen vary from language to
language, but typically they contain both logical constants and non-
logical vocabulary, e.g., in the language of the propositional calculus the
logical constants are truth-functional connectives and the non-logical
vocabulary consists solely of sentence letters, in the predicate calculus,
variable, predicates and quantifiers are needed. The formation rules will
naturally reflect the chosen vocabulary. The rules of inference are to be
thought of as governing only the manipulation of symbols,
independently of any interpretation they may have. Although formal
languages do not require at any state the notion of an interpretation, they
are nevertheless constructed with interpretations in mind, and rules of
inference that do not preserve truth, although not formally
unsatisfactory, are of no interest.
Formalism The practice or the doctrine of strict adherence to prescribed or external
forms.
Formalism Constraint of form over content.
Formalisms Examples are UML, CML, SysML, IDEF0, BOM, BOM++, Conceptual Text
Graphs, Mind Maps, and BPMN.
Formality Amount of constraints imposed on the form.
Formality Compliance with formal or conventional rules. Text
Formality Formality is compliance with formal or conventional rules. Text

RTO-TR-MSG-058 J - 13
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Generality Applicability to a wide class of instances.

Glyph Responsible for holding the image of conceptual model, which can be Text, OED
used to visually represent a conceptual model in a tool palette or a web
repository. From: 1. A structured mark or symbol. rare.
Implementation Constraints occurring at time of creation determined during the
Dependencies development of the conceptual model and manifest at the time of
implementation or execution of the conceptual model, such as may result
from peculiarities of domain ontologies, representational schema or any
other new concept introduced by the process during the implementation
of the conceptual model.
Incentive Incentive system: “A method of organizing production that uses a CFA Institute
market-like mechanism inside the firm.”
Incentive Any factor (financial or non-financial) that provides a motive for a Wikipedia
particular course of action, or counts as a reason for preferring one
choice to the alternatives.
Informal A conceptual model with the following attributers or consequences of Jake Borah
Conceptual Model informality: Tutorial
- Written using natural language and contains assumptions made during
its construction.
- Plays fundamental role during the period of activity when the modeler
conceives, programs, debugs, and test models.
- Helps users and colleagues comprehend basic outline of the model
from their perspective on how the real world operates.
Information Details the capabilities of a Behaviour, Actor, Event, or Control. Text
Inheritance The object-oriented concept where a child class also has the features SEDRIS
(attributes and methods) of its parent class; one of the types of Glossary
relationships between objects in the data model.
Instantiation To represent an abstraction by a concrete instance. The Fidelity
ISG Glossary
Interactions Transactions among entities wherein information exchange occurs or
causal influence is manifest.
Interoperability The capability of two or more simulation components to operate
together concurrently or in sequence guaranteed by the synchronized
exchange of syntactic and semantically consistent data signals/
messages.
Investment The process of adding to stocks of real productive assets. This may
mean acquiring fixed assets, such as buildings, plan, or equipment,
or adding to stocks and work in progress.
Investment Incurring costs in the present – for the right to receive future benefits /
with the expectation of achieving an increased benefit in the future.

J - 14 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Investment The process of expending money by a/an organization/individual/
department/entity/project that result in an increase of assets.
Investment Costs that result in the acquisition of, or addition to, end items. Such Glossary of
costs benefit future periods and generally are of a long-term character. Defense
Costs budgeted in the procurement and Military Construction Acquisition
appropriations are considered investment costs. Costs budgeted in the Acronyms &
Research, Development, Test and Evaluation appropriation can be Terms, Defense
considered investment costs or expenses, depending on the Acquisition
circumstances. University Press
Knowledge 1) The rules, environment, etc., that form the structure humans use to Houghton
process and relate to information, or the information a computer system Mifflin Co.,
must have to behave in an apparently intelligent manner. 2) The sum or Webster’s II,
range of what has been perceived discovered or learned. New College
Dictionary,
1995
Legacy Simulation/ Existing simulation asset whose initial costs are already incurred and
Simulator which may be in use and therefore may have stakeholder commitments
for continued investment and use.
M&S Asset An asset or assets used in the science, practice, development, or use of
M&S.
M&S Community The ensemble of practitioners comprising the population of individuals
(M&S Community- and organizations with significant interests and commitments to
of-Practice) modeling and simulation disciplines, practices, assets and uses.
M&S Conceptual Conceptual Model intended for realizing a simulation capability. Text
Model
M&S Investment The process of investing (as defined) in or for M&S (as defined) assets
(as defined) by a/an organization/individual/department/entity/project.
M&S Resources A source of relevant supply – in the case of M&S, resources normally
include: models, simulations, databases, scenarios, threat libraries, V&V
histories, accreditation pedigrees, environmental representations,
architectures, and interfaces; but they may also include: interfaces,
simulation federations, games, plans and policies, personnel, facilities
and equipment, information sources, behaviors, system information and
documentation, organizational knowledge, procedural knowledge,
operational knowledge, mappings and translations, conceptual models,
transaction protocols, software components, execution outputs, and
analysis results and reports.
Machine Ability of information to be perceived by a machine or automaton and
Readability subsequently be operated upon by that device.
Market “The means through which buyers and sellers are brought together to aid CFA Institute
in the transfer of goods and/or services.”

RTO-TR-MSG-058 J - 15
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Market “Any place where the sellers of a particular good or service can meet http://economic
with the buyers of that goods and service where there is a potential for s.about.com/cs/
a transaction to take place.” economicsgloss
ary/g/market.ht
m
Market “A market exists whenever potential sellers of a good or service are Graham
brought into contact with potential sellers and a means of exchange is Bannock
available.”
Market In general, a market is defined as the group of individuals/organizations/ Marketing
entities that has the need for, and can afford a product/service. definition
Mathematical 1) Any system of assumptions, definitions and equations that represents Report from
Model particular physical phenomena. See model, simulation, conceptual the Fidelity
model, software model. 2) A document describing the assumptions, Implementation
definitions and equations that represent particular physical phenomena Study Group
to be simulated for a specific application.
Measurement The dimensional or quantitative assignment of that which is being Practical
assessed (e.g., five inches long). A set of operations having the object Software
of determining a value of a measure. Measurement,
McGarry et all,
2002
Meta Data Data on a process, event, or system that is fundamentally abstract in
nature. A set of “data about data” that characterizes the referent in a
more theoretical manner than first order descriptors.
Meta Data Information describing the characteristics of data; data or information DoD, “Data
about meaning of the data; descriptive information about an Administration
organization’s data, data activities, systems, and holdings. Procedures”,
DoD 8320.1-M,
SEDRIS
Glossary 29 Jun
1998
Meta-Knowledge Knowledge about knowledge; knowledge about the use and control of The Fidelity
domain knowledge in an expert or knowledge-based system or ISG Glossary
knowledge about how the system operates or reasons; wisdom.
Meta-Model “… a specification model for a class of systems under study, where each Dragan Gasevic
system under study in the class is itself a valid model expressed in a
certain modeling language.” “… a meta-model is a model of a modeling
language.”
Meta-Model A model of a model. Meta-models are abstractions of the M&S being The Fidelity
developed which use functional decomposition to show relationships, ISG Glossary
paths of data and algorithms, ordering, and interactions between model
components and sub-components. Meta-models allow the software
engineers who are developing the model to abstract details to a level that
subject-matter experts can validate.

J - 16 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Metric(s) Describe a system of measurement that includes: the item or object The Metrics of
being measured; units to be measured, also referred to as “standard Science and
units”; and the value of a unit as compared to other units of reference. Technology,
(The Metrics of Science and Technology, Geisler, 2000). Geisler, 2000
Military Domain Domain or range of interest of entities and phenomenology of interest to
military organizations or personnel.
Military Domain Individuals having expert or specialized knowledge of one or another
Experts military domain.
Military M&S An M&S Conceptual Model within the military domain. Text
Conceptual Model
Military Mission Mission space relating to military entities or functions. (See Mission
Space Space)
Military Modeling Modeling conducted in support of military organizations or functions or
representing military behaviours.
Military Scenario Scenario of interest to Military operations or agents. (See Scenario)
Mission Space 1) The [world] in which a particular mission is performed. 2) The Report from
environment of entities, actions, and interactions comprising the set of the Fidelity
interrelated processes used by individuals and/or organizations to Implementation
accomplish assigned tasks. Study Group,
DoD, “M&S
Master Plan”,
DoD 5000-59-P
Mission Space A model based primarily upon knowledge of the real world. Such a Report from
Model model, if based entirely upon expert opinion of the real world, is a the Fidelity
preliminary to creating a mathematical or software model. A mission Implementation
space model of an object should describe what that object does, at some Study Group
level of fidelity, in the environment in which the mission is executed.
See model, mathematical model, software model, mission space.
Model 1) A physical, mathematical, or otherwise logical abstract representation DoD, “M&S
of a system, entity, phenomenon, or process with its own assumptions, Master Plan”,
limitations and approximations. See simulation, conceptual model, DoD 5000-59-P
software model, mathematical model. 2) A geometry or feature assembly
built in a relative coordinate system with the intent to multiply instances
of the assembly at one or more world coordinate positions. 3) A system
that stands for or represents another typically more comprehensive
system.
Model (Noun) A pattern of something to be made. Jake Borah
Tutorial
Model (Noun) “… a simplified view of reality.” “… A clear set of formal statements Dragan Gasevic
that describes something … for a specific purpose …”

RTO-TR-MSG-058 J - 17
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Model (Noun) I. Representation of structure. b. fig. Something that accurately OED
resembles something else; a person or thing that is the likeness or
‘image’ of another; esp. in little model, a thing that represents on a small
scale the structure or qualities of something greater. c. An archetypal
image or pattern. e. A simplified or idealized description or conception
of a particular system, situation, or process (often in mathematical terms:
so mathematical model) that is put forward as a basis for calculations,
predictions, or further investigation.
Model (Noun) A simplified/abstracted representation of a part of reality or a potential Text
reality.
Model (Noun) A physical, mathematical, or otherwise logical representation of a Text
referent of interest
Model (Verb) 1.a. trans. To present as in a model or outline; to portray or describe in OED
detail. b. [after MODEL n. 2e.] To devise a (usu. mathematical) model
of (a phenomenon, system, etc.).
Model (Verb) … to produce a representation of or simulation of [something]. Jake Borah
Tutorial
Model Data structure that can accommodate information related to the
Identification identification of a conceptual model such as: Name, Type, Version,
Modification Date, Security Classification, Release Restriction, Purpose,
Application Domain, Description, and Use Limitation.
Model Kinds Types or alternative classes of models. Examples are dynamic, static, Text
state machine, structural, behavioral, agent, object-based, process-based,
Meta data, entity relation, activity, composition, generalization,
collaboration, event trace and sequence.
Modeling … representation [v.] of a system for the purpose of studying the system. Banks, Carson,
and Nelson
Modeling … cost effective use of something in place of something else for some Ray Rothenburg
purpose.
Modeling Application of a standard, rigorous, structured methodology to create The Fidelity
and validate a physical, mathematical, or otherwise logical ISG Glossary
representation of a system, entity, phenomenon, or process.
Modeling and The use of models, including emulators, prototypes, simulators, and MSETT
Simulation (M&S) stimulators, either statically or over time, to develop data as a basis for NAWC-TSD
making managerial or technical decisions. The terms “modeling” and Glossary; DoD
“simulation” are often (though imprecisely) used interchangeably. M&S Glossary,
DoD 5000.59-M
Modeling and The use of models, including emulators, prototypes, simulators, and The Fidelity
Simulation (M&S) stimulators, either statically or over time, to develop data as a basis for ISG Glossary
making managerial or technical decisions. The terms “modeling” and
“simulation” are often used interchangeably.

J - 18 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Need 3.a. Necessity arising from the facts or circumstance of the case; 10.A A OED
condition marked by the lack or want of some necessary thing, or
requiring some extraneous aid or addition.
Need A ‘want’ or ‘need’ is related to the state of expectation or intention of Text
one or another of the stakeholders. Individually or collectively,
stakeholders may have anticipatory preferences for that which is
produced as the conceptual model proper based on their intended use for
it in context of their role within the enterprise. Wants and needs in this
view are desiderata.
Notation A system of characters, symbols, or abbreviated expressions used in an
art or science or in mathematics or logic to express technical facts or
quantities.
Notation Set of names, symbols, or other semiotic devices together with syntactic
rules for associated the elements of the notation into meaningful
statements.
Notational Schema Schema (see below) manifest as notational symbology.
Object A fundamental element of a conceptual representation for a federate that The Fidelity
reflects the “real world” at levels of abstraction and resolution appropriate ISG Glossary
for federate interoperability. For any given value of time the state of an
object is defined as the enumeration of all its attribute values.
Object Model A specification of the objects intrinsic to a given system, including a The Fidelity
description of the object characteristics, or attributes, and a description ISG Glossary
of the static and dynamic relationships that exist between objects.
Ontology Ontologies are formalized vocabularies of terms, often covering a Lee Lacey
specific domain and shared by a community of users. They specify the
definitions of terms by describing their relationships with other terms in
the ontology.
Ontology ‘An’ ontology is a specification of a conceptualization. Practically, OED; Dragan
“A representation vocabulary often specialized to some domain”. Gasevic
“... the body of knowledge describing the domain using the representation
vocabulary” “... an explicit representation of a shared understanding of
the important concepts in some domain of interest”.
Ontology Combination of objects and processes of interest. Text
Ontology An explicit formal conceptualisation of a shared understanding of the Text
domain of interest including the vocabulary of terms, semantics as well
as their pragmatics.
Ontology In short, ‘ontology’ asks the rhetorical question: What is there? In the Text
present context, more specific formulations might be: What do we care
about, or alternatively, what is it necessary to represent in a model or
simulation in order for the resulting product to serve its intended use?
Given this knowledge, the next question that must be addressed is: How
can one select, and document the contents of such a representation?

RTO-TR-MSG-058 J - 19
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Ontology (Formal) Ontologies may be classified depending upon both their formality and Asunción
complexity as a continuum as belong to the following major categories: Gómez Pérez
Highly Informal, Semi Formal, and Rigorously Formal. Formal
ontologies are considered to be: “… the systematic formal, axiomatic
development of the logic of all forms and modes of being. It studies the
formal properties and classification of the entities of the world (physical
objects, events, etc.), and of the categories that model the world
(concepts, property, etc.)”
Pattern(s) 1) a. The original proposed imitation; the archetype; that which is to be OED
copied; an exemplar’ (J.); an example or model deserving imitation; an
example or model of a particular excellence. 2) a. Anything fashioned,
shaped, or designed to serve as a model from which something is to be
made; a model, design, plan, or outline. [therefore a kind of a model]. 6)
An example, an instance; esp. a typical, model, or representative
instance, a signal example. c. fig. An arrangement or order of things or
activity in abstract senses; order or form discernible in things, actions,
ideas, situations, etc.
Policy A deliberate plan of action to guide decisions and achieve rational Wikipedia
outcomes.
Precision 1) The quality or state of being clearly depicted, definite, measured or Report from
calculated. 2) A quality associated with the spread of data obtained in the Fidelity
repetitions of an experiment as measured by variance; the lower the Implementation
variance, the higher the precision. 3) A measure of how meticulously or Study Group
rigorously computational processes are described or performed by a
model or simulation. See resolution, sensitivity.
Predicate 1) Logic. That which is predicated or said of the subject in a proposition. OED
2) Gram c. A quality, an attribute.
Primitives Elemental components from which higher-order composites may be Text
composed. Commonly applied to conceptual model constructs.
Examples are entity, object, signal, time, event, attribute, message, state.
Process 1) Something that affects entities (e.g., attrition, communications, and Houghton
movement). Processes have a level of detail by which they are described. Mifflin Co.,
2) A system of operations in producing something. 3) A series of Webster’s II,
actions, changes, or functions that achieve an end or result. New College
Dictionary,
1995
Process Processes comprising the conceptual model best-practice must be
Consistency, appropriate for execution in a NATO-diverse constituency. Best-practice
Commonality and process elements must be sufficiently consistent that participation in
Tailorability conceptual modeling can be extended across any sub-set of the NATO
M&S community.

J - 20 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Process Practice commonality must have a similar domain in order that suitable
Consistency, common ground exist from which NATO M&S constituents may fully
Commonality and appreciate both how conceptual models were achieved and what their
Tailorability contents are once produced. Conceptual modeling processes and
(cont’d) products must, nevertheless, be sufficiently tailorable so that they can
be socialized by any particular sub-set of the enterprise to which they
will particularly pertain – and they must be sufficiently tailorable as to
admit the specific referent subject matter, conceptual constructs, and
representational schemas as may be elected by one or another sub-set
of the stakeholder community.
Process Guidance Prescriptive guidance specifying the effort or activity necessary and
sufficient to create a desired work-product resulting from a
developmental activity.
Process Model A model of the processes performed by a system (e.g., a model that The Fidelity
represents the software development process as a sequence of phases). ISG Glossary
See structural model.
Producer This is a person or organization that will endeavour to satisfy the Text
sponsor’s need.
Producer 1) Understanding of operational issues and mission context. Text
(Knowledge 2) Translation of operational issues and mission context into a
Engineer) conceptual model. 3) Unambiguous communication with SMEs and
implementers.
Producer 1) Effective use of allocated resources (e.g., ensuring reuse when Text
(M&S PM) appropriate). 2) Unambiguous communication with customer.
Producer 1) Understanding of operational issues and mission context.
(M&S SME) 2) Translation of operational issues and mission context into a
Military SME conceptual model. 3) Unambiguous communication with SMEs and
implementers.
Producer 1) Understanding of operational issues and mission context. 2) Provide Text
(M&S SME) technical and military know-how at appropriate level of detail.
Product Conceptual model product consistency must be sufficient that the
Consistency library of conceptual models deployed and used within the NATO M&S
enterprise are at least evidently interpretable among stakeholders, and
preferably interoperable (to within similarity of mission space referents)
across the enterprise.. While complete interoperability and exhaustive
re-usability are not likely to occur even under the most auspicious
circumstances, and while it is certain that no degree of product ‘best-
practice’ results could guarantee such consistency, any element of the
prescribed practice that can be established with a view to improving
product consistency should be adopted.
Product Guidance Prescriptive guidance specifying the nature of the subject work-product
resulting from a developmental activity.

RTO-TR-MSG-058 J - 21
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Product Quality Conceptual model product quality across the enterprise is relevant from
two complimentary perspectives. On the one hand consistent quality in
fact resulting from the subject guidance is directly correlated to the
value of the return on investment in conceptual modeling itself. On the
other hand, sufficient and auditably documented product quality across
conceptual models will influence greatly both the likelihood of use of
the conceptual modeling best-practice guidance and the re-use sharing,
and recovery of utility of the pursuant models themselves.
Project Manager Role title relating to responsible agent leading a project or program of
activity.
Properties Attributes, characteristics of a thing or process.
Purpose(s) 1) a. That which one sets before oneself as a thing to be done or attained; OED
the object which one has in view. 2) a. Without a or pl. The action or
fact of intending or meaning to do something; intention, resolution,
determination. 3) The object for which anything is done or made, or for
which it exists; the result or effect intended or sought; end, aim.
Quality A totality of features and characteristics of a conceptual model that bear Text
on its ability to satisfy stated or implied needs. It measures how “good”
a conceptual model might be for various purposes.
Quality Measures how “good” a conceptual model might be for various Text
purposes.
Real-Time In modelling and simulation, simulated time advances at the same rate The Fidelity
as actual time (e.g., running the simulation for one second results in the ISG Glossary
model advancing time by one second). See fast time, slow time.
Real-World The set of real or hypothetical causes and effects that simulation Report from
technology attempts to replicate. See real battlefield. The real world the Fidelity
defines one standard against which fidelity is measured that includes Implementation
both imagined reality and material reality in order to accommodate Study Group
assessment of simulation fidelity when future concepts and systems are
involved. See fidelity, imagined reality, material reality, perceived truth.
Reference A pointer to additional sources of information such as locations in XML
documents and references to ontologies (both domain and middle level)
which are used by the conceptual model.
Referent That part of the mission-space being represented in the simulation –
also denoted the ‘simuland’.
Referent a. That to which something has reference; spec. that which is referred to OED
by a word or expression. Also in Comb. (appositively), as referent-
object.
Referent A set of fictive or existing systems, entities, phenomena, or processes Text
subjected to modeling and simulation which a user may want to consider
in the context of their own objects or interests.

J - 22 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Referent 1) A codified body of knowledge about a thing being simulated. Report from
2) Something referenced or singled out for attention, a designated object, the Fidelity
real or imaginary or any class of such objects. Implementation
Study Group,
Houghton
Mifflin Co.,
Webster’s II,
New College
Dictionary,
1995
Relation 3) a. That feature or attribute of things which is involved in considering OED
them in comparison or contrast with each other; the particular way in
which one thin is thought of in connection with another; any connection,
correspondence, or association, which can be conceived as naturally
existing between things.
Relationship The state of being related; a condition or character based upon this.
Repository A place where data or specimens are stored and maintained for future Wikipedia
retrieval.
Representation 2) a. n An image, likeness, or reproduction in some manner of a thing. OED
d. The fact of expressing or denoting by means of a figure or symbol;
symbolic action or exhibition. 6) a. v The action of presenting to the
mind or imagination; an image thus presented; a clearly-conceived idea
or concept.
Representation 1) Something that stands in place of or is chosen to substitute for Houghton
something else, e.g., representation of constituencies in government, Mifflin Co.,
linguistic representation of an event. 2) Something that describes as an Webster’s II,
embodiment of a specified quality. 3) The homomorphism of a group of New College
abstract symbols into a group of more familiar objects. 4) A model or Dictionary,
simulation. 1995, Report
from the
Fidelity
Implementation
Study Group
Representational Multiple representations of the same data to serve the needs of different SEDRIS
Polymorphism users. Glossary
Requirement 3) That which is required or needed; a want, need. b. that which is called OED
for or demanded; a condition which must be complied with.
Requirement A ‘requirement’ is related to the necessary and sufficient attributes of the Text
conceptual model as determined appropriate for the enterprise at large.
Requirements both prescribe and proscribe the characteristics of the
conceptual model which, if present, guarantee the model to be adequate
for its several intended uses.

RTO-TR-MSG-058 J - 23
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Requirement As such, requirements must be monolithic within the enterprise and Text
(cont’d) must manifest the potentially disparate stakeholders’ wants and needs in
positive-definite, observable form.
Resolution 1) The degree of detail used to represent aspects of the real world or a Houghton
specified standard or referent by a model or simulation. 2) Separation or Mifflin Co.,
reduction of something into its constituent parts; granularity. Webster’s II,
New College
Dictionary,
1995
Reusability Able to be used again; suitable for second or further usage.
Reuse For an asset to be used again subsequent to its initial intended use.
Risk Possibility that actual outcomes will vary from what is expected.
Risk A measure of the inability to achieve program objectives within defined Glossary of
cost and schedule constraints. It has two components: the probability of Defense
failing to achieve a particular outcome, and the consequences of failing Acquisition
to achieve that outcome. Acronyms &
Terms, Defense
Acquisition
University Press
Risk “The chance of things not turning out as expected. Risk taking lies at the http://www.eco
heart of capitalism and is responsible for a large part of the growth of an nomist.com/rese
economy. In general, economists assume that people are willing to be arch/economics
exposed to increased risks only if, on average, they can expect to earn
higher returns than if they had less exposure to risk.”
Role The named designation of a relationship that may be assigned-to or Webster...”a
assumed-by an individual or organization with respect to some function part or character
or organizational entity. Role is intended to imply requisite authority and assumed by
concomitant responsibility to execute the associated functions or to act anyone.”
successfully in relation to the designated organizational entity.
Role (Functional) Those functions (including decisions) that the individual person or
Authority organization assigned to a role class or instance may perform. … what
the role holder may do.
Role (Functional) Those functions that must be performed by the person or organization
Responsibility assigned to any particular role class or instance. Performance of
functional responsibilities is a necessary condition of satisfactory role-
position execution. … what the role holder must do.
Scale A specified, graduated reference used to measure the value of an item to
a decision-maker or user.
Scenario 2) A sketch, outline, or description of an imagined situation or sequence
of events; esp. (a) a synopsis of the development of a hypothetical future
world war, and hence an outline of any possible sequence of future
events; (b) an outline of an intended course of action; (c) a scientific
model or description intended to account for observable facts.

J - 24 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Scenario (cont’d) Hence, in weakened series (not easily distinguishable from sense 1a OED
transf. and fig.): a circumstance, situation, scene, sequence of events, etc.
Schema 1) a. Philos. In Kant: Any one of certain forms or rules of the OED
‘productive’ imagination’ through which the understanding is able to
apply its ‘ categories’ to the manifold of sense-perception in the process
of realizing knowledge or experience... (e.g., A rule that organizes
perceptions into a unitary whole.) b. Neurol. and Psychol. An automatic,
unconscious coding or organization of incoming physiological or
psychological stimuli, giving rise to a particular response or effect.
Scope The range, breadth, or degree of extension of the universe of discourse.
Semantic(s) 2) a. Relating to signification or meaning. OED
Semantics The components of a rule or lexical entry that define the meaning of a Steven Pinker
morpheme, word, phrase, or sentence.
Semantics 1) The implied meaning of data to define what entities mean with SEDRIS
respect to their roles in a system. 2) The study of relationships between Glossary, 29
signs and symbols and what they represent to their interpreters. Jun 1998,
Houghton
Mifflin Co.,
Webster’s II,
New College
Dictionary,
1995
Simplification Analytical technique in which unimportant details are removed in order Jake Borah
to define simpler relationships. Tutorial
Simuland The system being simulated by a simulation. See referent, model, and The Fidelity
simulation. ISG Glossary
Simulation The imitative representation of the functioning of one system or process
by means of the functioning of another”.
Simulation The implementation of a model over time. Text
Simulation 1) A method, software framework or system for implementing one or Report from
more models in the proper order to determine how key properties of the the Fidelity
original may change over time. See model, representation. 2) An Implementation
unobtrusive scientific method of inquiry involving experiments with a Study Group
model rather than with the portion of reality this model represents.
Simulation Conceptual model of or for a simulation.
Conceptual Model
Simulation Sub-discipline of engineering where models and simulations are the
Engineering systems of interest.
Simulation The model as it is actually implemented and exercised in the simulation.
Executable Model

RTO-TR-MSG-058 J - 25
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Simulation Process The imitative representation of the actions of platform(s), munition(s), The Fidelity
and life form(s) by computer program(s) in accordance with a ISG Glossary
mathematical model and the generation of associated battlefield entities
that may be fully automated or partially automated.
Simulation Space The simulation artefact wherein simulation mission space representation
is manifest.
Sponsor Person or organization that sees a need for modeling and simulation in Text
the solving of a problem such as specifying an operation requirement or
analyzing a capability.
Sponsor Responsibilities of a sponsor role agent include: 1) Analysis of combat
Responsibility outcome, system performance, system alternative trade-offs, etc.
2) Cost-effective training. 3) Credibility of analysis results. 4) Making
sure the Conceptual Model represents necessary and sufficient relevant
information about operational issues and mission context of interest
(correct scope). 5) Decision-making based on analysis products
(introducing a new tactic, procuring a new system, etc.). 6) Cost of
modeling and simulation.
Stakeholder Conceptual modeling will be conducted and its value recovered in a
Community community or practice commensurate with the scope and diversity of the
enterprise participants. Concepts invoked to develop, understand, share,
and reuse conceptual model artifacts with confidence, and with
reasonable expectation of accruing the benefits of shared investment
require that all stakeholder roles be carefully defined and be appreciated
as pertaining across the enterprise scope.
Stakeholder(s) People or organizational persons likely to be affected by a process or
product.
Standard 1) An accepted measure of comparison for quantitative or qualitative Houghton
value; a criterion. 2) Proposition of a norm or general pattern to be Mifflin Co.,
followed when constructing, operating or testing a (technical) device. Webster’s II,
A standard contains a set of reference criteria for functional, structural, New College
performance or quality aspects of a device or for any combination of Dictionary,
these. 1995
Standard(s) 10) a. (Originally fig from 9.) An authoritative or recognized exemplar OED
of correctness, perfection, or some definite degree of any quality.
b. A rule, principle, or means of judgement or estimation; a criterion,
measure. 12) a. A definite degree of any quality, viewed as a prescribed
object of endeavour or as the measure of what is adequate for some
purpose.
Stimulation The use of simulations to provide an external stimulus to a system or The Fidelity
sub-system (e.g., using a simulation representing the radar return from a ISG Glossary
target to drive (stimulate) the radar of a missile system within a hardware/
software-in-the-loop simulation).

J - 26 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Subject-Matter Individual particularly well-informed or adept in one or another subject
Expert matter domain.
Syntactic Facilitates enforcement of syntactic precision upon statements whose Text
Expression semantic-information content is left to the modeller agent.
Syntax The component of grammar that arranges words into phrases and Steven Pinker
sentences.
System of Interest Set of fictive or existing systems, entities, phenomena, or processes
subjected to modeling and simulation representation and which a user
of the system wants to consider in the context of their own needs,
objectives or interests.
Tailorable Attribute of an entity or process whereby it admits to being changed
specifically in order to make it more suitably relevant or purposefully fit
for some particular intended purpose or use.
Task A task is a description of a military activity, including the activity
performer and the activity object(s). It may be decomposed into sub-
tasks (recursively decomposable) or steps (atomic).
Traceability Every requirement statement can be referred to a corresponding need,
constraint or policy statement.
Traceability The quality of being traceable; to follow the course, development,
or history of. Also with the course, etc., as object. fit.
Traceability Left to conceptual model stakeholder practitioner with respect to Text
selection, modification and interpretation of notational schemas.
Unambiguity The requirement is given a form that avoids misinterpretation.
Universe of All of the participants with an abiding interest (types or individuals)
Stakeholders relevant to a specific use case or instance of investment management.
Use Cases A description of a system’s behavior as it responds to a request that http://en.wikipe
originates from outside of that system. The use case technique is used in dia.org/wiki/Us
software and systems engineering to capture the functional requirements e_case
of a system. Use cases describe the interaction between a primary Actor
(the initiator of the interaction) and the system itself, represented as a
sequence of simple steps. Actors are something or someone which exists
outside the system under study, and that take part in a sequence of
activities in a dialogue with the system to achieve some goal. They may
be end users, other systems, or hardware devices. Each use case is a
complete series of events, described from the point of view of the Actor.
In this case the system is the simulation conceptual model.
User Role specification denoting individual or organization who will employ
the subject (conceptual model) work-product for any of a variety of
purposes within scope of the M&S enterprise.
User-Needs See User and Needs.
Users’ View See User and View.

RTO-TR-MSG-058 J - 27
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Utility The “utility” of something is one factor that is taken into consideration
when determining things of “value.”
Utility Economist-speak for a good thing; a measure of satisfaction. Underlying
most economic theory is the assumption that people do things because
doing so gives them utility. Individuals strive to achieve as much utility
as possible. However, the more they have the less difference an
additional unit of utility will make – there is diminishing marginal
utility. Utility is not the same as utilitarianism, a political philosophy
based on achieving the greatest happiness of the greatest number.
Utility The (relative) importance of items in a class to an agent. Choices: An
Introduction
to Decision
Theory, Resnik,
1987
Utility The state or quality of being useful militarily or operationally. Designed Glossary of
for or possessing a number of useful or practical purposes rather than a Defense
single, specialized one. Acquisition
Acronyms &
Terms, Defense
Acquisition
University Press
Utility Utility is the property of the relative satisfaction gained by the use of a Text
system expressed in terms of a value and cost. It measures the kinds of
purposes for which the conceptual model might provide value.
Utility Assesses the effectiveness and efficiency of the conceptual model in Text
solving the problem statement.
Utility Function A representation of a consumer’s preferences that maps potential and
actual items and outcomes and the value preferences of a consumer or
decision-maker.
Utility Scales A specified, graduated reference used to measure the value of an item or
process to a decision-maker or user.
V&V Agents Role title for those responsible for managing verification and validation
within an M&S enterprise environment.
V&V Data The V&V process can produce an enormous amount of data. These data
Elements are collected under a label called V&V Data Elements and placed in the
product “conceptual model Meta data”. In the table below a list of data
items is presented together with the Process Activities where that data is
produced.
Validation The process of determining the degree to which a model or simulation is The Fidelity
an accurate representation of the real world, or some other meaningful ISG Glossary
referent, from the perspective of the intended uses of the model or
simulation.

J - 28 RTO-TR-MSG-058
 ANNEX J – LEXICON/GLOSSARY

Term DEFINITION or COMMENT REFERENCE

Validation The purpose of the Validation Process is to provide objective evidence
that the services provided by a system entity when in use comply with
stakeholders’ requirements.
Validation of Process of validation applied to subject conceptual model. See validation
Conceptual Model and conceptual model.
Validity The property of a simulation model to have, within a specific
experimental frame, a behavior which is indistinguishable under a set of
validation criteria from the behavior of the System of Interest.
Validity Assesses the level of agreement of the conceptual model behavioral Text
representation with that of the simuland.
Validity 1) The quality of being inferred, deduced or calculated correctly enough Report from
to suit a specific application. 2) The quality of maintained data that is the Fidelity
found on an adequate system of classification (e.g., data model) and is Implementation
rigorous enough to compel acceptance for a specific use. 3) The logical Study Group
truth of a derivation or statement, based on a given set of propositions.
Value I.1.a. That amount of some commodity, medium of exchange, etc., OED
which is considered to be an equivalent for something else. (See Cost)
Verification The purpose of the Verification Process is to confirm that the specified
design requirements are fulfilled by the system entity.
Verification The process of determining that a model or simulation implementation DoD, “M&S
accurately represents the developer’s conceptual description and Master Plan”,
specification. Verification also evaluates the extent to which the model DoD 5000-59-P
or simulation has been developed using sound and established software
engineering techniques.
View Instance of a model kind with selected information.
Views Examples are class diagram, activity diagrams, swim lanes, state
diagram, operational view, etc.
Want 2) a. Deficiency, shortage or lack (of something, desirable or necessary, OED
esp a quality or attribute). 5) a A condition marked by the lack of some
necessary thing, or requiring some extraneous aid or addition; need;
also, an instance of this, and so freq. pl (passing into the quasi- concr,
sense’ requirement’.
Want A ‘want’ or ‘need’ is related to the state of expectation or intention of Text
one or another of the stakeholders. Individually or collectively,
stakeholders may have anticipatory preferences for that which is
produced as the conceptual model proper based on their intended use for
it in context of their role within the enterprise. Wants and needs in this
view are desiderata.

RTO-TR-MSG-058 J - 29
ANNEX J – LEXICON/GLOSSARY

J - 30 RTO-TR-MSG-058
 Annex K – BIBLIOGRAPHY

The literature of conceptual modeling is hopelessly large and diffuse. This follows naturally from the diversity
of the significance of the key terms, ‘model’ and ‘concept’. Topical scope of references ranges from the entire
philosophical field of ontology through conceptualization used for software, and most recently simulation.
References address, primitive ideas, practices, and process, tools, and concrete results over a range of referent
domains that is as large as the world itself. While the Task Group did feel the need to anchor its deliberations
in firmly in the academic and practical literature of conceptual modeling and to provide relevant citations
allowing the reader to connect the ‘web of belief’ at which the Task Group finally arrived with their own
appreciation of the intellectual subject; we soon realized that a comprehensive bibliographic search and
analysis would itself consume the entire resources of the study effort. Caught between the Scylla of academic
grounding and the Chaybdis of finite resources; we have elected to cite those references that provided us
genuine insight, represented most evocatively the ‘world’ of modeling and simulating in which we are
embedded, or occasionally, provided background so influential and broadly relevant that it could be neglected
only at the risk of depriving the reader of one or another of those canonical hooks upon which he might
anchor his own evolving interpretation of the subject. The bibliographic references that follow, therefore,
include all citations invoked by footnotes in the text as well as those collateral citations that seemed most
likely to support the reader’s understanding and appreciation of the subject document. We regret egregious
omissions that will be apparent to any well-informed reader and plead necessity of economy as our only
defence.

[1] About.com Website; Definition of Market; http://economics.about.com/cs/economicsglossary/g/market.

htm.

[2] ACIMS; www.acims.arizona.edu.

[3] AEgis Technologies Group, Inc. 2008. Metrics for Modeling and Simulation (M&S) Investments –
Scientific and Technical Report.

[4] Agile Modeling Website; UML 2 Stereotype Style Guidelines; http://www.agilemodeling.com/style/

stereotype.htm.

[5] Ahmed, K. and Moore, G. (2005): An Introduction to Topic Maps, Microsoft Corp., http://www.topic
maps.org/, Retrieved 24 September 2009.

[6] Akst, G. Musings on Verification, Validation, and Accreditation (VV&A) of Analytical Combat
Simulations.

[7] Alembert, J.L.R.D., R.N. Schwab and W.E. Rex. 1995. Preliminary Discourse to the Encyclopedia of
Diderot. Chicago, IL, USA: University of Chicago Press.

[8] Allgood, B., A. Clough, G. Cunha, J. Van Buren and S. Godfrey. 1994. Process Technologies Method
and Tool Report (Volume I): Prepared by: Software Technology Support Center (STSC), Ogden ALC/
TISE, Hill AFB, UT, USA.

[9] Andersson, B., M. García Lozano and V. Mojtahed. The Use of a Knowledge Meta Meta Model (KM3)
when Building Conceptual Models of the Mission Space.

RTO-TR-MSG-058 K-1
ANNEX K – BIBLIOGRAPHY

[10] Armour, F., and G. Miller 2001. Advanced Use Case Modeling: Software Systems. Boston, MA, USA:
Addison-Wesley.

[11] Atherton, J. 2006. “Conceptual Modelling and Data Repositories: Tools to support SE Process” Paper
06F-SIW-038, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2006 Simulation Interoperability
Workshop.

[12] ATLAS Group, LINA & INRIA, and Nantes, KM3: Kernal MetaMetaModel Manual – Version 0.3, August
2005.

[13] Ayres, R. and M.R. Moulding. 2001. “A Pilot Language for Conceptual Modelling of the Battlespace”
Paper 01S-SIW-109, Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2001 Simulation
Interoperability Workshop.

[14] Bagui, S. and Earp, R. 2003. Database Design Using Entity-Relationship Diagrams. Boca Raton, FL, USA:
Auerbach.

[15] Balci, O. 1997. Verification, Validation and Accreditation of Simulation Models. In S. Andradottir,
K.J. Healy, D.H. Withers and B.L. Nelson (Eds.), Winter Simulation Conference.

[16] Banks, J., J. Carson, B. Nelson and D. Nicol. 2005. Discrete-Event System Simulation (4th Ed.). Upper
Saddle River, NJ, USA: Pearson Prentice Hall.

[17] Bannock, G., Baxter, R.E. and Davis, E. 1998. The Penguin Dictionary of Economics (6th Ed.). London;
New York, NY, USA: Penguin Books.

[18] Blake, D.D.W., J. Morse and C. Little. 2003. “The Navy’s Probability of Raid Annihilation Assessment
Process Standards and Architecture and Systems Engineering Concept Model” Paper 03F-SIW-057 Fall
SIW. Orlando, FL, USA: Proceedings of the Fall 2003 Simulation Interoperability Workshop.

[19] Booch, G. 1996. Object Solutions: Managing the Object-Oriented Project. Menlo Park, CA, USA:
Addison-Wesley Pub. Co.

[20] Boomgaardt, J.J., Mojtahed, V. and Waite, B. 2008. “NATO-MSG-058 Conceptual Modeling for M&S”
(08F-SIW-038), Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2008 Simulation Interoperability
Workshop.

[21] Borah, J. and J.-L. Igarza. Simulation Conceptual Modeling Study Group (SCM SG) Final Report.

[22] Borah, J. Conceptual Modeling Tutorial: Simulation Conceptual Modeling Study Group.

[23] Borah, J. 2002. “Conceptual Modeling – How do we move forward?” Paper 02F-SIW-054, Fall 2002.
Orlando, FL, USA: Proceedings of the Fall 2002 Simulation Interoperability Workshop.

[24] Borah, J. 2002. “Conceptual Modeling – The Missing Link of Simulation Development” Paper 02S-
SIW-074, Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2002 Simulation Interoperability
Workshop.

[25] Borah, J. 2002. Terms of Reference (TOR) for the SISO Study Group on: “Simulation Conceptual
Modeling”.

K-2 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[26] Borah, J. 2003. “Conceptual Modeling – How do we do it? – A practical example” Paper 03S-SIW-114,
Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2003 Simulation Interoperability Workshop.

[27] Borah, J. 2004. Simulation Conceptual Modeling Study Group – Spring 04 Simulation Interoperability
Workshop Meeting.

[28] Borah, J. 2006. Simulation Conceptual Modeling (SCM) – Study Group – Final Report: SISO.

[29] Borah, J. 2007. “Informal Simulation Conceptual Modeling – Insights from Ongoing Projects” (07F-
SIW-012), Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2007 Simulation Interoperability
Workshop.

[30] Borsodi, R. 1967. The Definition of Definition; A New Linguistic Approach to the Integration of
Knowledge. Boston, MA, USA: P. Sargent.

[31] Bowker, G.C. and S.L. Star. 1999. Sorting Things Out: Classification and its Consequences. Cambridge,
MA, USA: MIT Press.

[32] Bozlu, B. and O. Demirörs. 2008. A Conceptual Modeling Methodology: From Conceptual Model to
Design – Paper 08E-SIW-044, EURO-SIW. Edinburgh, Scotland: Proceedings of the 2008 Euro Simulation
Interoperability Workshop, June 16-19, 2008.

[33] Bozlu, B. and Karagoz, A. 2008. Synthetic Environment System (SES) Case Study Description for KAMA.

[34] Bozlu, B. and Karagoz, A. 2008. Report for Conceptual Modeling Approach developed in Turkey (KAMA)
Language Specification.

[35] BPMN Website; Business Process Modeling Notation (BPMN); http://www.bpmn.org/.

[36] Brade, D.A. 2003. “Conceptual Modeling Meets Formal Specification” Presentation 03S-SIW-138,
Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2003 Simulation Interoperability Workshop.

[37] Brade, D.A. 2004. Generalized Process for the Verification and Validation of Models and Simulation
Results: Dissertation, Fakultät für Informatik, Universität der Bundeswehr München. Neubiberg, 2004.

[38] Britt, D.W. 1997. A Conceptual Introduction to Modeling: Qualitative and Quantitative Perspectives.
Mahwah, NJ, USA: Lawrence Erlbaum Associates.

[39] Brooks, R.J. 2006. Some Thoughts on Conceptual Modelling: Performance, Complexity and Simplification.
In S. Robinson, S. Taylor, S. Brailsford and J. Garnett (Eds.), OR Society Simulation Workshop.

[40] Buhr, R.J.A. and Casselman, R.S.O. 1996. Use Case Maps for Object-Oriented Systems. Upper Saddle
River, NJ, USA: Prentice Hall.

[41] Carnegie Mellon Software Engineering Institute; CMMI Overview; http://www.sei.cmu.edu/cmmi/.

[42] Carnegie Mellon Software Engineering Institute. 2006. Appraisal Requirements for CMMI®, Version
1.2 (ARC, V1.2).

[43] Carnegie Mellon Software Engineering Institute. 2006. CMMI® for Development, Version 1.2.

RTO-TR-MSG-058 K-3
ANNEX K – BIBLIOGRAPHY

[44] Carnegie Mellon Software Engineering Institute. 2006. Standard CMMI® Appraisal Method for Process
Improvement (SCAMPISM) A, Version 1.2: Method Definition Document.

[45] Carnegie Mellon Software Engineering Institute. 2007. Understanding and Leveraging a Supplier’s
CMMI® Efforts: A Guidebook for Acquirers.

[46] Carnegie Mellon Software Engineering Institute. 2007. CMMI® for Acquisition, Version 1.2.

[47] Carrara, M. and N. Guarino. 1999. Formal Ontology and Conceptual Analysis: A Structured Bibliography –
www.pms.ifi.lmu.de/mitarbeiter/ohlbach/Ontology/Ontobiblio.doc.

[48] Casti, J.L. 1989. Alternate Realities: Mathematical Models of Nature and Man. New York, NY, USA:
Wiley.

[49] CFA Institute. https://www.cfainstitute.org/pages/index.aspx.

[50] Chadbourne, C., D. Clark, V.T. Dobe and S.K. Numrich. 2000. “Environment Concept Model: A Step
Toward Validation” Paper 039, Simulation Technology and Training Conference. Sydney, Australia:
Proceedings of the Simulation Technology and Training Conference.

[51] Chapman, R.M. 2000. “Conceptual Modeling Framework for Complex Synthetic Systems – an Example
from F-15C Distributed Mission Training” Paper 00S-SIW-088, Spring SIW. Orlando, FL, USA:
Proceedings of the Spring 2000 Simulation Interoperability Workshop.

[52] Chapman, R.M. 2000. “Mission-Oriented Conceptual Modeling Framework for Distributed Mission
Training” Paper 00F-SIW-104, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2000 Simulation
Interoperability Workshop.

[53] Chartrand, G. 1985. Introductory Graph Theory (Unabridged and Corr. Ed.). New York, NY, USA: Dover.

[54] Chen, P. 1976. The Entity-Relationship Model – Toward a Unified View of Data” ACM Transactions on
Database Systems, Vol. 1, No. 1, March, pp. 9-36, 1976.

[55] Chen, P.P.S. 1999. Conceptual Modeling: Current Issues and Future Directions. Berlin; New York, NY,
USA: Springer.

[56] Chisholm, R.M. 1996. A Realistic Theory of Categories: An Essay on Ontology. Cambridge; New York:
Cambridge University Press.

[57] CMMI Product Group, CMMI for Development, Version 1.2, Technical Report, CMU/SEI-20060TR-
008, August 2006, http://www.sei.CMu.edu/CMmi/.

[58] Cockburn, A. 2000. Writing Effective Use Cases: Addison-Wesley Professional.

[59] CoGui Website; CoGui; http://www.lirmm.fr/cogui/.

[60] Conceptual Graphs Website; Conceptual Graphs; http://conceptualgraphs.org/.

[61] Cotton, A.L., III. 1997. “Developing a Standard Unit-Level Object Model”. Master’s Thesis, Naval
Postgraduate School, September 1997, Monterey, CA, USA.

K-4 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[62] Cutts, D., P. Gustavson and J. Ashe. 2006. “LVC Interoperability via Application of the Base Object
Model (BOM)”, Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2006.
Orlando, FL, USA.

[63] Davis, R., H. Shrobe and P. Szolovits. 1993. What is a Knowledge Representation?

[64] Defence Modeling and Simulation Office. 1993. DMSO Survey of Semi-Automated Forces.

[65] Defense Acquisition University. 2005. Glossary of Defense Acquisition Acronyms & Terms. Fort Belvoir,
VA, USA.

[66] Defense Modeling and Simulation Office. 1997. Conceptual Models of the Mission Space (CMMS)
Technical Framework.

[67] Defense Modeling and Simulation Office (DMSO) VV&A Technical Support Team. DMSO VV&A
Recommended Practices Guide (RPG).

[68] Delphi Group. 2002. Taxonomy & Content Classification Market Milestone Report. Boston, MA, USA:
A Delphi Group White Paper.

[69] Department of National Defence, Canada, The Joint Simulation and Modeling for Analysis, Requirements,
Training, and Support (SMARTS) Initiative: A Vision for enabling Strategy 2020.

[70] Derrick, C. 2007. A View of Simulation Conceptual Modeling, Conceptual Modeling Workshop. UAH –
Huntsville, AL, USA.

[71] DEVS Standardization Group; http://ww.sce.carleton.ca/faculty/wainer/standard/.

[72] Dietz, J.L.G. 2006. Enterprise Ontology: Theory and Methodology. Berlin; New York, NY, USA: Springer.

[73] Dobey, V.T. 2003. “Representing the Natural Environment: An Integrated Development Process” Paper
03S-SIW-085, Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2003 Simulation Interoperability
Workshop.

[74] Dobey, V.T. 2003. “System Environmental Representation: Building for Success from the Very Beginning”
Paper 1378, I/IITSEC. Orlando, FL, USA: Interservice/Industry Simulation, Training, and Education
Conference, December 2003.

[75] Dobey, V.T. and P.G. Foley 2004. “System Contextual Development of Physical Environmental
Representations” Paper 04S-SIW-116, Spring SIW. Arlington, VA, USA: Proceedings of the Spring 2004
Simulation Interoperability Workshop.

[76] DoDAF Promulgation Memo; February 9, 2004.

[77] DoDAF 1.5 Volume 1; http://www.defenselink.mil/cio-nii/docs/DoDAF_VolumeI.pdf.

[78] DoDAF 1.5 Volume 2; http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume_II.pdf.

[79] DoDAF 1.5 Volume 3; http://www.defenselink.mil/cio-nii/docs/DoDAF_Volume _III.pdf.

RTO-TR-MSG-058 K-5
ANNEX K – BIBLIOGRAPHY

[80] Domingue, J., Motta, E. and Garcis, O. “Knowledge Modelling in WebOnto and OCML: A User Guide”,
V. 2.4, Open University and Knowledge Media Institute, 1999.

[81] Druid, L. 2006. “Methods and Tools for Simulation Conceptual Modeling” Paper 06E-SIW-029, EURO
SIW. Stockholm, Sweden: Proceedings of the 2006 European Simulation Interoperability Workshop.

[82] Duck, A.J., M.R. Auth, D.H. Timian, R.T. Dunbar and C.R. Karr. 2004. “Army Future Force Intelligence,
Surveillance, and Reconnaissance (ISR) System-of-System (SoS) Conceptual Modeling” Paper 04F-
SIW-003, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2004 Simulation Interoperability Workshop.

[83] Duncan, J. Fidelity Versus Cost and It’s Effect on Modeling & Simulation.

[84] Durso, F.T. and R.S. Nickerson. 2007. Handbook of Applied Cognition (2nd Ed.). Chichester, England;
Hoboken, NJ, USA: Wiley.

[85] Erlandson, M. and Gordon, S. Economics of Simulation Data Compilation Work Group, 1995.

[86] Eryilmaz, U. and N. Alpay Karagöz. 2009. “KAMA: A Tool for Developing Conceptual Models for C4ISR
Simulations” (09E-SIW-020), EURO SIW. Istanbul, Turkey: Proceedings of the Euro 2009 Simulation
Interoperability Workshop.

[87] Fauconnier, G. 1994. Mental Spaces: Aspects of Meaning Construction in Natural Language. Cambridge;
New York: Cambridge University Press.

[88] Fauconnier, G. 1997. Mappings in Thought and Language. Cambridge; New York: Cambridge University
Press.

[89] Federal Information Processing Standards Publication 183; Standard for Integration Definition for
Function Modeling (IDEF0); http://www.idef.com/pdf/idef0.pdf.

[90] Firat, C. 2000. “Conceptual Modeling and Conceptual Analysis in HLA” Paper 00F-SIW-151, Fall SIW.
Orlando, FL, USA: Proceedings of the Fall 2000 Simulation Interoperability Workshop, CD.

[91] Firat, C. 2001. “A Knowledge Based Look at Federation Conceptual Model Development”, Euro SIW.
Harrow, England: Proceedings of the 2001 European Simulation Interoperability Workshop.

[92] Fowler, M. 1997. Analysis Patterns: Reusable Object Models. Menlo Park, CA, USA: Addison Wesley.

[93] Gallier, N.P. 2002. “Standard Design Characteristics of Simulation Systems for Training – Part of the
Conceptual Model?” Paper 02F-SIW-003, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2002
Simulation Interoperability Workshop.

[94] Gansner, E.R. 2000. An Open Graph Visualization System and its Applications to Software Engineering.
Software: Practice and Experience, Volume 30(Issue 11): 1203-1233.

[95] Garshol, L.M. What are Topic Maps?; http://tinyurl.com/zj4d2; Retrieved 24 September 2009.

[96] Gasevic, D. 2006. Model Driven Architecture and Ontology Development (1st Ed.). New York, NY, USA:
Springer.

K-6 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[97] Geisler, E. 2000. The Metrics of Science and Technology. Westport, CT, USA: Quorum Books.

[98] Genesereth, M.R. and Fikes, R.E. 1992. Knowledge Interchange Format – Version 3.0 – Reference Manual:
Stanford University – Computer Science Department.

[99] Gomez-Perez, A., M. Fernandez-Lopez and O. Corcho. 2004. Ontological Engineering: With Examples
from the Areas of Knowledge Management, E-commerce and the Semantic Web London; New York,
NY, USA: Springer-Verlag.

[100] Gordon, S. and W. Waite, G. Öhlund and Å. Björk. Review and Update of Findings from Economics of
Simulation Study Groups, Paper 21, NATO Modeling and Simulation Group Symposium, Warsaw,
Poland, October 2005 (Paper presented at the RTO NMSG Symposium on “The Effectiveness of
Modeling and Simulation – From Anecdotal to Substantive Evidence”, held in Warsaw, Poland, 13-14
October 2005).

[101] Gordon, D.S., Review and Update of Findings from Economics of Simulation Study Groups, Waite, B.,
Editor, NMSG-035/RSY-005, 2005.

[102] Graphviz Website; Graphviz-Graph Visualization Software – http://www.graphviz.org/.

[103] Gross, D.C. System Representation – M&S Fundamentals and Applications, M&S Fidelity Briefing.

[104] Gross, D.C. 1999. Report from the Fidelity Implementation Study Group – 99S-SIW-167, Simulation
Interoperability Workshop. Orlando, FL, USA.

[105] Gruber, T.R. What is an Ontology; http://ksl-web.stanford.edu/people/gruber/.

[106] Gustavson, P., P. Zimmerman and C. Turrell, 2003. “Conceptual to Composable: Driving Towards
Rapid Development of Simulations and Simulation Spaces “I/ITSEC. Orlando, FL, USA: Proceedings
of the 2003 Intraservice/Industry Training, Simulation & Education Conference.

[107] Gustavson, P., P. Zimmerman, and C. Turrell. 2003. “Capturing Intent-Of-Use Meta-Data for the
Conceptual Model – A Key to Component Reuse”, Paper 03F-SIW-080, Fall SIW. Orlando, FL, USA:
Proceedings of the Fall 2003 Simulation Interoperability Workshop.

[108] Gustavson, P. 2007. “Using Base Object Models for Conceptual Modeling” (PowerPoint Presentation
for SCM SG Spring SIW 07), Spring SIW.

[109] Gustavson, P. and T. Chase. 2007. Building Composable Bridges Between the Conceptual Space and
the Implementation Space. In S.G. Henderson, B. Biller, M.-H. Hsieh, J. Shortle, J.D. Tew and
R.R. Barton (Eds.), Winter Simulation Conference.

[110] Haddix, F. 2001. “Conceptual Modeling Revisited: A Developmental Model Approach for Modeling &
Simulation” Paper 01F-SIW-098, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2001 Simulation
Interoperability Workshop.

[111] Haley, T. and S. Friedenthal. 2008. “Assessing the Application of SysML to Systems of Systems
Simulations” (08S-SIW-100), Spring SIW. Providence, RI, USA: Proceedings of the Spring 2008
Interoperability Workshop.

RTO-TR-MSG-058 K-7
ANNEX K – BIBLIOGRAPHY

[112] Halpin, T. 1998. Modeling Business Rules Using Fact-Orientation and Object-Orientation: Visio
Corporation.

[113] Halpin, T. and Bloesch, A. 1998. A Comparison of UML and ORM for Data Modeling – http://www.
orm.net/pdf/orm-emm98.pdf, EMMSAD ‘98 3rd IFIP WG8.I International Workshop on Evaluation of
Modeling Methods in Systems Analysis and Design. Pisa, Italy.

[114] http://mindmappingsoftwareblog.com/basic-ordering-ideas/, Retrieved 24 September 2009.

[115] http://www.uml.org/, Retrieved 2 October, 2009.

[116] Halpin, T.A. 2001. Information Modeling and Relational Databases: From Conceptual Analysis to
Logical Design. San Francisco, CA, USA: Morgan Kaufman Publishers.

[117] Halpin, T., “Object-Role Modeling (ORM/NIAM)”, found in Handbook on Architectures of Information
Systems, Eds. P. Bernus, K. Mertins and G. Schmidt, Springer-Verlag, Berlin, Germany, 1998.

[118] Hamilton, J.A., Jr. 2006. “A Conceptual Model for Interoperable Command and Control Acquisition”.
The Journal of Defense Modeling and Simulation: Applications, Methodology, Technology (JDMS),
Vol. 3(No. 2): pp. 125-138.

[119] Harrison, N., B. Gilbert, M. Lauzon, A. Jeffrey, C. Lalancette, R. Lestage and A. Morin. 2002.
“A M&S Process to Achieve Reusability and Interoperability” Paper 11, NATO M&S Conference.
Paris, France: Proceedings of the NATO M&S Conference 2002.

[120] Harrison, N., B. Gilbert, A. Jeffrey, M. Lauzon and R. Lestage. 2004. “Adaptive and Modular M&S
Configuration for Increased Reusability” Paper 1864, I/ITSEC. Orlando, FL, USA: Proceedings of the
2004 Intraservice/Industry Training, Simulation & Education Conference.

[121] Harrison, N., B. Gilbert, A. Jeffrey, R. Lestage, M. Lauzon and A. Morin. 2005. KARMA: Materializing
the Soul of Technologies into Models, I/ITSEC. Orlando, FL, USA.

[122] Hay, D.C. 2003. Requirements Analysis: From Business Views to Architecture. Upper Saddle River,
NJ, USA: Prentice Hall PTR.

[123] Hay, D.C. 2006. Data Model Patterns: A Metadata Map, Amsterdam; Boston: Elsevier Morgan
Kaufmann.

[124] Hillegas, A., J. Bachschies, M. Donley, R.C. Duncan and W. Edgar. 2001. The Use of Modeling and
Simulation (M&S) Tools in Acquisition Program Offices: Results of a Survey: Hicks & Associates.

[125] Horner, N.C., E.N. Jalbert and J.S. Topper. 2009. A Generic Conceptual Model for Mission Threads –
As an Example for the Airborne Networking Enterprise Framework (DRAFT): The Johns Hopkins
University Applied Physics Laboratory.

[126] Houghton Mifflin. 1995. Webster’s II New College Dictionary. Boston, MA, USA.

[127] Hümmer, W. A Decathlon in Multidimensional Modeling: Open Issues and Some Solutions. In W. Lehner
(Ed.).

K-8 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[128] Hume, D. 2004. An Enquiry Concerning Human Understanding (Dover Ed.). Mineola, NY, USA:
Dover Publications.

[129] Iansiti, M. and Levin, R. Strategy as Ecology, in Harvard Business Review, March, 2004.

[130] Ibarzabal, E. 2008. Enabling Semantic Discovery of Simulation Components. Unpublished Master’s
Thesis at FOI, KTH Royal Institute of Technology, Sweden.

[131] IDEF; IDEF5 – Ontology Description Capture Method; http://www.idef.com/IDEF5.htm.

[132] IEEE. 1989. IEEE Standard Glossary of Modeling and Simulation Terminology – 610.3-1989.

[133] IEEE. 1992. IEEE Standard 1074, “IEEE Standard for Software Quality Management Process and
Verification and Validation Process”.

[134] IEEE. 1993. IEEE Standard 1059, “Guide to Software Verification and Validation Plans”.

[135] IEEE. 1995. IEEE Standard 1278.1, “IEEE Standard for Distributed Interactive Simulation – Application
Protocols”.

[136] IEEE. 1997. IEEE Standard 1278.4, “IEEE Recommended Practice for Distributed Interactive Simulation
– Verification, Validation and Accreditation”.

[137] IEEE. 1998. Institute of Electrical and Electronics Engineers (IEEE) Standard 1012, “Standard for
Software Verification and Validation”.

[138] IEEE. 2000. IEEE Standard 1516, “IEEE Standard for Modeling and Simulation (M&S) High Level
Architecture (HLA) – Framework and Rules”.

[139] IEEE. 2000. IEEE Standard 1516.1, “IEEE Standard for Modeling and Simulation (M&S) High Level
Architecture (HLA) – Federate Interface Specification”.

[140] IEEE. 2008. IEEE P1730™/Dv3.0 Draft Recommended Practice for Distributed Simulation Engineering
and Execution Process (DSEEP). In D. P. D. G. o. SISO (Ed.): IEEE.

[141] IEEE. 2008. IEEE Standard 15288 – Systems & Software Engineering – System Life Cycle Processes.

[142] Integrated Definition Methods; IDEFO Function Modeling Method; http://www.idef.com/IDEF0.htm.

[143] International Organization for Standardization. 1994. International Standards Organization (ISO) 9001,
“Quality Systems – Model for Quality Assurance in Design, Development, Production, Installation,
and Servicing”. Geneva, Switzerland: ISO.

[144] International Organization for Standardization. 2000. ISO Standard 9000: 2000 – Quality Management
Systems – Fundamentals and Vocabulary – http://www.iso.org/iso/catalogue_detail?csnumber=29280.

[145] International Organization for Standardization. 2001. ISO/IEC Standard 9126 – Software Engineering
– Product Quality – Part 1: Quality Model.

RTO-TR-MSG-058 K-9
ANNEX K – BIBLIOGRAPHY

[146] International Organization for Standardization. 2007. ISO/IEC 24744 – Software Engineering –
Metamodel for Development Methodologies – http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail.htm?csnumber=38854.

[147] International Standards Organization. 1982. ISO 9000-3, “Quality Management and Quality Assurance
Standards – Part 3: Guidelines for the Application of ISO 9001 to the Development, Supply and
Maintenance of Software”. Geneva, Switzerland: ISO.

[148] ISO/IEC Joint Technical Committee 1 JTC1. 2002. ISO/IEC 13250 – Topic Maps, Information
Technology – Document Description and Processing Languages – http://www1.y12.doe.gov/
capabilities/sgml/sc34/document/0322_files/iso13250-2nd-ed-v2.pdf.

[149] Jackendoff, R. 1992. Languages of the Mind: Essays on Mental Representation. Cambridge, MA, USA:
MIT Press.

[150] Jacobson, I. 1992. Object-oriented Software Engineering: A Use Case Driven Approach. [New York]
Wokingham, England; Reading, MA, USA: ACM Press; Addison-Wesley Pub.

[151] Jensen, K. 2009. Coloured Petri Nets: Modeling and Validation of Concurrent Systems (1st Ed.). New
York, NY, USA: Springer.

[152] Johannisson, P. ISO 15288.

[153] Johansson, K., T. Nordqvist and P. Asplund. 2004. Report on Conceptual Models. Linköping, Sweden:
Front End AB.

[154] Johnson, T. 1998. “Mission Space Model Development, Reuse and the Conceptual Models of the
Mission Space Toolset”, Paper 98S-SIW-155, Spring SIW: 98 Spring Simulation Interoperability
Workshop Papers.

[155] Kabilan, V. 2006. Including DCMF-O: Ontology Suite for Defence Conceptual Modeling Paper 06E-
SIW-028, EURO SIW. Stockholm, Sweden: Proceedings of the 2006 European Simulation Interoperability
Workshop, CD.

[156] Kabilan, V. 2007. Ontology for Information Systems (O4IS) Design Methodology – Conceptualizing,
Designing and Representing Domain Ontologies. The Royal Institute of Technology.

[157] Karagöz, A. “A Framework for Developing Conceptual Models of the Mission Space for Simulation
Systems”, Unpublished doctoral dissertation, Middle East Technical University, Ankara, Turkey, 2008.

[158] Karagöz, N.A., H. Orkun Zorba, M. Atun and A. Can. 2008. “Developing Conceptual Models of the
Mission Space (CMMS) – An Experience Report” (08F-SIW-048), Fall SIW. Orlando, FL, USA:
Proceedings of the Fall 2008 Simulation Interoperability Workshop.

[159] Karagöz, N.A. and O. Demirörs. 2007. Developing Conceptual Models of the Mission Space (CMMS)
– A Metamodel Based Approach – (07S-SIW-056), SIW. Norfolk, VA, USA: Proceedings of the Spring
2007 SIW.

[160] Karr, C.R. 2005. Conceptual Modeling in OneSAF Objective System (OOS), I/ITSEC. Orlando, FL,
USA: Proceedings of the I/ITSEC 2005 Conference. http://tinyurl.com/natrw6, 2005.

K - 10 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[161] Kelly, L. 1995. The ASTD Technical and Skills Training Handbook. New York, NY, USA: McGraw-Hill.

[162] Kendal, S.L. and M. Creen. 2007. An Introduction to Knowledge Engineering. London, UK: Springer.

[163] Kèovecses, Z. 2002. Metaphor: A Practical Introduction. New York, NY, USA: Oxford University Press.

[164] Knowledge Based Systems Inc.; Information Integration for Concurrent Engineering (IICE) IDEF5
Method Report; http://www.idef.com/pdf/Idef5.pdf.

[165] Kotiadis, K. 2006. Extracting a Conceptual Model for a Complex Integrated System in Health Care.
In S. Robinson, S. Taylor, S. Brailsford and J. Garnett (Eds.), OR Society Simulation Workshop.

[166] Kulak, D. and E. Guiney. 2004. Use Cases: Requirements in Context (2nd Ed.). Boston, MA, USA:
Addison-Wesley.

[167] Lacey, L.W. 2005. OWL: Representing Information Using the Web Ontology Language, Victoria, BC,
Canada: Trafford Publishing.

[168] Lacy, L., S. Youngblood and R. Might. 2001. “Developing a Consensus Perspective on Conceptual
Models for Simulation Systems” Paper 01S-SIW-074, Spring SIW. Orlando, FL, USA: Proceedings of
the Spring 2001 Simulation Interoperability Workshop.

[169] Lakoff, G. 1987. Women, Fire, and Dangerous Things: What Categories Reveal About the Mind. Chicago,
IL, USA: University of Chicago Press.

[170] Lamsweerde, A.V. 2009. Requirements Engineering: From System Goals to UML Models to Software
Specifications. Chichester, England; Hoboken, NJ, USA: John Wiley.

[171] Law, A.M. and W.D. Kelton. 2000. Simulation Modeling and Analysis (3rd Ed.). Boston, MA, USA:
McGraw-Hill.

[172] Lehmann, A. 2006. “Verification, Validation and Accreditation of Simulation Models and Applications”,
NATO Advanced Research Workshop. Velingrad, Bulgaria.

[173] Lin, Y., S. Hakkarainen and D. Strasunskas. 2003. “Towards the Two World Modeling”: Information
System Group, Department of Computer and Information Science (IDI), Norwegian University of
Science and Technology (NTNU).

[174] Lindland, O.I., Sindre, G. and Sølvberg, A. 1994. Understanding Quality in Conceptual Modelling.
IEEE Software, 11(2): 42-49.

[175] Lindo, W. 2001. OneSAF Conceptual Model.

[176] Liu, H. and Gluch, D., “Conceptual Modeling with the Object-Process Methodology in Software
Architecture”, JCSC No. 19 V. 3, 2003.

[177] Lizotte, M., Poussart, D., Bernier, F., Mokhtari, M., Boivin, E. and DuCharme, M. 2008. IMAGE:
Simulation for Understanding Complex Situations and Increasing Future Force Agility, Army Science
Conference. Orlando, FL, USA: Proceedings of the Army Science Conference.

[178] Locke, J. 1995. An Essay Concerning Human Understanding. Amherst, NY, USA: Prometheus Books.

RTO-TR-MSG-058 K - 11
ANNEX K – BIBLIOGRAPHY

[179] Lozano, M.G., V. Mojtahed and B. Andersson. 2003. “Using a Knowledge Meta Meta Model (KM3)
Building Conceptual Models of the Mission Space (CMMS)” Paper 03F-SIW-040, Fall SIW. Orlando,
FL, USA: Proceedings of the Fall 2003 Simulation Interoperability Workshop.

[180] Lozano, M.G. and V. Mojtahed. 2005. “A Process for Developing Conceptual Models or the Mission
Space (CMMS) – From Knowledge Acquisition to Knowledge Use” Paper 05F-SIW-038, Fall SIW.
Orlando, FL, USA: Proceedings of the Fall 2005 Simulation Interoperability Workshop, CD.

[181] Lukose, D.D. 1996. Knowledge Engineering – PART A – Knowledge Representation – http://pages.
cpsc.ucalgary.ca/~kremer/courses/CG/CGlecture_notes.html: The University of New England.

[182] Lundgen, M., M. García Lozano and V. Mojtahed. 2004. “CMMS Under the Magnifying Glass –
An Approach to Deal with Substantive Interoperability” Paper 04F-SIW-010, Fall SIW. Orlando, FL,
USA: Proceedings of the Fall 2004 Simulation Interoperability Workshop, CD.

[183] Lundgen, M., M. García Lozano and V. Mojtahed. 2004. CMMS under the Magnifying Glass –
An Approach to Deal with Substantive Interoperability (Presentation), Fall SIW. Orlando, FL, USA.

[184] Lutz, B. and P. Gustavson and A. Bowers. 2009. Conceptual Modeling – Overview and Breakout.

[185] Malone, S., R. Reading and S. Trbovich. 2007. “Conceptual Modeling for the Probability of Raid
Annihilation Testbed” (07S-SIW-074), Spring SIW. Norfolk, VA, USA: Proceedings of the Spring
2007 Simulation Interoperability Workshop.

[186] Margolis, E. and S. Laurence. 1999. Concepts: Core Readings. Cambridge, MA, USA: MIT Press.

[187] McGarry, J. 2002. Practical Software Measurement: Objective Information for Decision Makers. Boston,
MA, USA: Addison-Wesley.

[188] Merriam-Webster; Design; http://www.merriam-webster.com/dictionary/design?show=1&t=1303403590.

[189] Metz, M.L. 2000. “Comparing the Joint Warfare System (JWARS) Conceptual Model to a Conceptual
Model Standard” Paper 00F-SIW-129, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2000
Simulation Interoperability Workshop.

[190] Miller, J.A., G.T. Baramidze, A.P. Sheth, G.A. Silver and P.A. Fishwick. Ontologies for Modeling and
Simulation: An Initial Framework. ACM Journal Name, Vol. V, No. N, M 20YY: 1-47.

[191] Milton, N.R. 2007. Knowledge Acquisition in Practice: A Step-by-Step Guide. London, UK: Springer.

[192] MIP-NATO Management Board (MNMB); Joint C3 Information Exchange Data Model (JC3IEDM)
http://www.mip-site.org/publicsite/04-Baseline_3.0/JC3IEDM-Joint_C3_Information_Exchange_Data
_Model/.

[193] Missile Defense Agency (MDA)/Systems Engineering. 2003. Ballistic Missile Defense System
(BMDS) Conceptual Model Version – DRAFT 0.2: Approved by COL Kevin J. Greaney.

[194] Mojtahed, V. and P. Svan – FOI Swedish Defence Research Agency & Binger Andersson, V.K.-K.-R.
I. o. T. DCMF – Survey of Related Research and Approaches.

K - 12 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[195] Mojtahed, V., García Lozano, M., Swan, P., Andersson, B. and Kabilan, V. “DCMF – Defence
Conceptual Modeling Framework”, Technical Report FOI-R–1754-SE, Swedish Defence Research
Agency, ISSN 1650-1942. 2005.

[196] Mojtahed, V., Tjörnhammar, E., Zdravkovic, J. and Khan, A. “The Knowledge Use in DCMF”, Technical
Report FOI-R–2606-SE, Swedish Defence Research Agency, ISSN 1650-1942. 2008.

[197] Mojtahed, V., B. Andersson and V. Kablan. 2008. BOM and DCMF, Methodology Report: FOI.

[198] Mojtahed, V., Andersson, B., Kabilan, V. and Zdravkovic, J. 2008. “BOM++, a Semantically Enriched
BOM” (08S-SIW-050), Spring SIW. Providence, RI, USA: Proceedings of the Spring 2008 Simulation
Interoperability Workshop.

[199] Mojtahed, V. 2009. Properties Within Various Methods for Conceptual Modeling.

[200] Moody, D.L. 2005. Theoretical and Practical Issues in Evaluating the Quality of Conceptual Models:
Current State and Future Directions. Data & Knowledge Engineering, 55(3): 243-276.

[201] Morgan, M.S. and Morrison, M. 1999. Models as Mediators: Perspectives on Natural and Social
Sciences. Cambridge; New York: Cambridge University Press.

[202] Morse, D.K.L. and D.W. Walter. 2000. “The FEDEP in Systems Engineering and Conceptual Modeling
for the WMDOA Federation” Paper 00F-SIW-053, Fall SIW. Orlando, FL, USA: Proceedings of the
Fall 2000 Simulation Interoperability Workshop.

[203] Morse, K., M. Petty, P. Reynolds, W. Waite and P. Zimmerman. 2004. Findings and Recommendations
from the 2003 Composable Mission Space Environments Workshop – 04S-SIW-050, Spring SIW.

[204] Mylopoulos, J. 2001. “Conceptual Modeling for Knowledge Management: A Tutorial”. Hong Kong,
China: City University of Hong Kong.

[205] Nagel, T. 1986. The View From Nowhere. New York, NY, USA: Oxford University Press.

[206] Nance, R.E. and Arthur, J.D. 2006. Software Requirements Engineering: Exploring the Role in
Simulation Model Development, 2006 Operational Research Society Simulation Workshop. Coventry,
England.

[207] National Bureau of Standards, C.S., and Technology. 1982. National Bureau of Standards (NBS)
Special Publication 500-93, “Software Validation, Verification, and Testing Technique and Tool
Reference Guide”. Washington, DC, USA.

[208] NATO Standardization Agency (NSA). 2011. AMSP-01 NATO Modelling and Simulation Standards
Profile Vol. Edition (B) Version 1.

[209] Naval Air Warfare Center Training Systems Division (NAWC-TSD). 1994. Modeling & Simulation
Educational Training Tool (MSETT) Glossary (MSETT NAWC-TSD Glossary).

[210] Nesselrode, M.C. Developing a Repeatable and Reliable Methodology to Determine Return-on-
Investment, Old Dominion University, 2008.

RTO-TR-MSG-058 K - 13
ANNEX K – BIBLIOGRAPHY

[211] North Atlantic Treaty Organisation. 2009. NATO Modelling and Simulation Standards Profile: NATO.

[212] North Atlantic Treaty Organisation Research & Technology Agency; The NATO Architecture
Framework (NAF); http://194.7.80.153/website/book.asp?menuid=15&vs=0&page=volume1%2Fch03
s02.html.

[213] North Atlantic Treaty Organisation Research & Technology Agency. 2006. Draft: Semantic
Interoperability. Follow on Activity of: ET-040 Ontology Fusion.

[214] North Atlantic Treaty Organisation Research & Technology Agency. 2007. RTB Endorsed NATO
Hardware TRL Definitions – http://ftp.rta.nato.int/public/PubFullText/RTO/TR/RTO-TR-AVT-128/
TR-AVT-128-Appendices.pdf.

[215] North Atlantic Treaty Organisation Research and Technology Agency. 2008. IST-075/RTG-034 Two
Day Workshop on “Semantic Interoperability”. TNO, The Hague, Netherlands.

[216] North Atlantic Treaty Organisation Research and Technology Agency. 2006. Draft – 1st Proposed
Technical Programme and Budget for 200X.

[217] North Atlantic Treaty Organisation Research and Technology Agency. 2006. Draft – Terms of Reference
(TOR) – Task Group on Semantic Interoperability – Follow on activity of: ET-040 Ontology Fusion.

[218] North Atlantic Treaty Organization Research and Technology Agency. 2007. 2007 Annual Report –
IST-075 – RTG-034 “Semantic Interoperability”: September 2006 – 2009.

[219] Noy, N.F. and McGuinness, D.L. Ontology Development 101: A Guide to Creating Your First Ontology –
www.ksl.stanford.edu/people/dlm/papers/ontology-tutorial-noy-mcguinness-abstract.html: 25 pages.

[220] Oberkampf, W.L. and T.G. Trucano. 2000. Validation Methodology in Computational Fluid Dynamics,
Fluids 2000 Conference & Exhibit, Vol. AIAA Paper 2000-2549. Denver, CO, USA: American Institute
of Aeronautics and Astronautics (AIAA).

[221] Object Management Group; OMG Systems Modeling Language, The Official OMG SysMl site;
www.omgsysml.org.

[222] Object Management Group; Meta Object Facility (MOF) Specification Version 1.4; http://www.omg.
org/mof/.

[223] Object Management Group; MDA Guide Version 1.0.1, OMG; http://www.omg.org/mda/.

[224] Object Management Group. 2005. Unified Modeling Language Specification Version 1.4.2.

[225] Object Management Group. 2007. OMG Unified Modeling Language (OMG UML), Superstructure,
V2.1.2.

[226] Object Management Group. 2007. UML Superstructure Specification, v2.1.2.

[227] Object Management Group; Introduction to OMG UML; http://tinyurl.com/y9xs2v9; Retrieved 2

October 2009.

K - 14 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[228] Object Management Group; OMG Unified Modeling Language (OMG UML)™ (OMG UML),
Infrastructure, Version 2.3 without change bars; http://www.omg.org/spec/UML/2.3/Infrastructure.

[229] O’Dell, C.S., Grayson, C.J. and Essaides, N. 1998. If Only We Knew What We Know: The Transfer of
Internal Knowledge and Best Practice. New York, NY, USA: Free Press.

[230] OneSAF Website; OneSAF; http://www.onesaf.net/.

[231] Ontology website; Ontology and Knowledge Representation Formalisms http://www.pms.ifi.lmu.de/

mitarbeiter/ohlbach/Ontology/.

[232] Ören, T. and Waite, B. 2010. Modeling and Simulation Body of Knowledge Index: An Invitation for
the Final Phases of its Preparation, SCS M&S Magazine, Vol. I.

[233] Ostwalt, I., et al. Calculating Return on Investment for U.S. Department of Defense Modeling and
Simulation, in Defense Acquisition research Journal, Vol. 18, No. 2, April 2011.

[234] OWL Website; Web Ontology Language (OWL); http://www.w3.org/2004/OWL/.

[235] Pace, D. 1999. Conceptual Model Descriptions, SCSC. Chicago, IL, USA: Proceedings of the 1999
Summer Computer Simulation Conference.

[236] Pace, D. 1999. Conceptual Model Descriptions – Paper 99S-SIW-025, Spring SIW: 133-144. Orlando,
FL, USA: Proceedings of the Spring 1999 Simulation Interoperability Workshop.

[237] Pace, D. 1999. Development and Documentation of a Simulation Conceptual Model – Paper 99F-SIW-
017, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 1999 Simulation Interoperability Workshop,
CD.

[238] Pace, D. 1999. Report from the M&S Conceptual Model Tiger Team (CMTT).

[239] Pace, D. 2000. Conceptual Model Development for C4ISR Simulations, 5th International Command and
Control Research and Technology Symposium. Canberra, Australia: Proceedings of the 5th International
Command and Control Research and Technology Symposium, Australia War Memorial, CD.

[240] Pace, D. 2000. Ideas About Simulation Conceptual Model Development, Johns Hopkins APL Technical
Digest, Vol. Volume 21: 327-336.

[241] Pace, D. 2000. Implications of Simulation Conceptual Model Development for Simulation Management
and Uncertainty Assessment, 1st Joint Army-Navy-NASA-Air Force (JANAF) Modeling and Simulation
SubCommittee Meeting: 1-13. Monterey, CA, USA: CPIA Publication 702, Chemical Propulsion
Information Agency (CPIA), Johns Hopkins University, Whiting School of Engineering.

[242] Pace, D. 2000. Simulation Conceptual Model Development Issues and Implications for Reuse of
Simulation Components – Paper 00F-SIW-019, Fall SIW. Orlando, FL, USA: Proceedings of the Fall
2000 Simulation Interoperability Workshop.

[243] Pace, D. 2000. Simulation Conceptual Model Development – Paper 00S-SIW-033, Spring SIW.
Orlando, FL, USA: Proceedings of the Spring 2000 Simulation Interoperability Workshop, CD.

RTO-TR-MSG-058 K - 15
ANNEX K – BIBLIOGRAPHY

[244] Pace, D. 2000. Simulation Conceptual Model Issues: Development Methods (Part 1), Interaction with
Simulation Requirements (Part 2), and Simulation Development Costs and V&V Costs (Part 3).
In William F. Waite (Ed.), SCSC: 488-499. Vancouver, British Columbia: Proceedings of the 2000
Summer Computer Simulation Conference.

[245] Pace, D. 2001. Conceptual Model Role in Simulation Validation, U.S. National Congress on
Computational Mechanics. Dearborn, MI, USA: Proceedings of the 6th U.S. National Congress on
Computational Mechanics, August 1-3, 2001.

[246] Pace, D. 2001. Impact of Federate Conceptual Model Quality and Documentation on Assessing HLA
Federation Validity – Paper 01S-SIW-024, EURO SIW. Harrow, England: Proceedings of the 2001
European Simulation Interoperability Workshop.

[247] Pace, D. 2001. Simulation Conceptual Model Role in Determining Compatibility of Candidate
Simulations for a HLA Federation, Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2001
Simulation Interoperability Workshop, CD.

[248] Pace, D. 2002. Capability of Explicit Conceptual Model on M&S Credibility and Reuse. Reno, NV,
USA: SURVIAC Workshop on Planning for Employment of Credible M&S in Defense Acquisition
Survivability, Lethality, and System Effectiveness, March 4-7, 2002, Reno, NV, USA.

[249] Pace, D. 2002. The Value of a Quality Simulation Conceptual Model, Modeling & Simulation, Vol. I:
9-10.

[250] Pace, D. 2003. Thoughts About The Simulation Conceptual Model – Paper 03S-SIW-009, Spring SIW.
Orlando, FL, USA: Proceedings of the Spring 2003 Simulation Interoperability Workshop, CD.

[251] Peacocke, C. 1992. A Study of Concepts. Cambridge, MA, USA: MIT Press.

[252] Pérez, A.G. 2002. Ontoweb – Ontology-Based Information Exchange for Knowledge Management
and Electronic Commerce IST-2000-29243: IST Programme of the Commission of the European
Communities.

[253] Pidcock, W.-B.C. What Are the Differences Between Vocabulary, a Taxonomy, a Thesaurus,
an Ontology, & a Meta-Model?; http://infogrid.org/wiki/Reference/PidcockArticle.

[254] Pinker, S. 1994. The Language Instinct (1st Ed.). New York, NY, USA: W. Morrow and Co.

[255] Popescu, E. 2008. Conceptual Modeling Role in the Defense Acquisition Process. Military Technique,
No. 1/2008: 12-19.

[256] Prinz, J.J. 2002. Furnishing the Mind: Concepts and Their Perceptual Basis. Cambridge, MA, USA:
MIT Press.

[257] Protégé Website; Protégé Ontology Editor; http://protege.stanford.edu/.

[258] Putnam, H. 1999. The Threefold Cord: Mind, Body, and World. New York, NY, USA: Columbia
University Press.

K - 16 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[259] Quine, W.V. 1969. Ontological Relativity, and Other Essays. New York, NY, USA: Columbia University
Press.

[260] Quine, W.V. 1980. From a Logical Point of View: 9 Logico-Philosophical Essays (2nd Ed.). Cambridge,
MA, USA: Harvard University Press.

[261] Râecanati, F. 2000. Oratio Obliqua, Oratio Recta: An Essay on Metarepresentation. Cambridge, MA,
USA: MIT Press.

[262] Rational Software. 2001. Rational Unified Process: Best Practices for Software Development Teams.

[263] Repgrid Website; Centre for Person-Computer Studies – www.repgrid.com.

[264] Resnik, M.D. 1987. Choices: An Introduction to Decision Theory. Minneapolis: University of Minnesota
Press.

[265] Ressler, R.L., M.R. Hieb and W. Sudnikovich. 1999. “M&S/C4ISR Conceptual Reference Model”
Paper 99F-SIW-060, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 1999 Simulation
Interoperability Workshop, CD.

[266] Robinson, S. 2006. Issues in Conceptual Modelling for Simulation: Setting a Research Agenda,
OR Society Simulation Workshop.

[267] Ross, R. 1997. Modeling for Data and Business Rules – An Interview with Terry Halpin. Data Base
Newsletter, Vol. 25(No. 5 (September/October 1997)).

[268] Rothenburg, J. 1991. “Knowledge-Based Simulation at the RAND Corporation”; Springer-Verlag.

[269] Roza, Z.C. 2004. Simulation Fidelity Theory and Practice: A Unified Approach to Defining, Specifying
and Measuring the Realism of Simulations: DUP Science.

[270] Rumbaugh, J. 1996. OMT Insights: Perspectives on Modeling from the Journal of Object-Oriented
Programming. New York, NY, USA: SIGS Books.

[271] Sagan, D.P., D.E. Kersey and P. May. 2000. “Conceptual Modeling Lessons Learned from WARSIM
2000” Paper 00S-SIW-52, Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2000 Simulation
Interoperability Workshop.

[272] Sarbo, J.J. 2004. Towards a new world-ontology – http://proceedings.eldoc.ub.rug.nl/HOME/bnaic/

2004/pt1/towards/: University of Nijmegen; Toernooiveld 1, 6525 ED Nijmegen.

[273] Schlenoff, C., A. Knutilla and S. Ray. 1996. Unified Process Specification Language: Requirements
for Modeling Process – http://www.mel.nist.gov/msidlibrary/doc/schlen96/req-paper.pdf: U.S. Dept. of
Commerce, Technology Administration, National Institute of Standards and Technology.

[274] Schneider, G. and Winters, J.P. 2001. Applying Use Cases: A Practical Guide (2nd Ed.). Boston, MA,
USA: Addison-Wesley.

RTO-TR-MSG-058 K - 17
ANNEX K – BIBLIOGRAPHY

[275] Schreiber, A., Th., Akkermans, J.M., Anjewierden, A.A., de Hoog, R., Shadbolt, N.R., Van de Velde, W.
and Wielinga, B.J. “Knowledge engineering and management: The Common KADS methodology”,
Cambridge Massachusetts, MIT Press, 2000.

[276] Scrudder, R.O. Modeling the Federation Development and Execution Process. In W.F. Waite (Ed.).

[277] SEDRIS. 1998. SEDRIS Glossary – http://www.sedris.org/glossary.htm.

[278] Selic, B. 2005. What’s New in UML 2.0?; IBM Corp.

[279] Shalloway, A. and Trott, J. 2004. Design Patterns Explained: A New Perspective on Object-Oriented
Design (2nd Ed.). Boston, MA, USA: Addison-Wesley.

[280] Shannon, R.E. 1975. Systems Simulation: The Art and Science. Englewood Cliffs, NJ, USA: Prentice-Hall.

[281] Sheehan J., T. Prosser., H. Conley, G. Stone, K. Yetz and J. Morrow. 1998. Conceptual Models of the
Mission Space (CMMS): Basic Concepts, Advanced Techniques, and Pragmatic Examples – Paper 98S-
SIW-127, Spring SIW, Vol. 2: pp. 744-751: 98 Spring Simulation Interoperability Workshop Papers.

[282] Simulation Interoperability Standard Organizations. 2006. Guide for Base Object Model (BOM) Use
and Implementation, SISO-STD-003.1-2006, 31 March 2006. http://www.boms.info/standards.htm,
Retrieved 18 September 2009.

[283] Simulation Interoperability Standards Organization. 2006. Guide for Base Object Model (BOM) Use
and Implementation, Vol. SISO-STD-003.1-2006.

[284] SimVentions, I. BOMS FAQ; http://www.boms.info/faq.htm.

[285] SISO Base Object Model Product Development Group. 2006. Simulation Interoperability Standards
Organization (SISO) Guide for Base Object Model (BOM) Use and Implementation.

[286] SISO Base Object Model Product Development Group. 2006. Simulation Interoperability Standards
Organization (SISO) Base Object Model (BOM) Template Specification: SISO.

[287] SISO Generic Methodology for Verification and Validation and Acceptance Product Development
Group (GM_VV PDG). Generic Methodology (GM) for Verification and Validation (VV) and Acceptance
of Models, Simulations, and Data – Reference Manual, Vol. SISO-GUIDE-00X.3-200X-DRAFT-
V1.0.1beta.

[288] SISO Generic Methodology for Verification and Validation and Acceptance Product Development
Group (GM_VV PDG). Guide for Generic Methodology (GM) for Verification and Validation (VV)
and Acceptance of Models, Simulations, and Data – Handbook, Vol. SISO-GUIDE-00X.2-200x-
DRAFT-V0.9.4: SISO GM-VV-PDG.

[289] Smith, B. 2003. Ontology. In L. Floridi (Ed.), Blackwell Guide to the Philosophy of Computing and
Information: 155-166: Oxford.

[290] Sonderegger, P. 2002. Grading Search Platform Hopefuls. In H. Manning (Ed.), The TechStrategy
Report: Forrester Research, Inc.

K - 18 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[291] Sowa, J.F. 1984. Conceptual Structures: Information Processing in Mind and Machine. Reading, MA,
USA: Addison-Wesley.

[292] Sowa, J.F. 2000. Knowledge Representation: Logical, Philosophical, and Computational Foundations.
Pacific Grove: Brooks/Cole.

[293] SPARTA, I. 1991. Working Notes on GBI Hardware and Functional Breakdowns – “In Support of
Survivability Assessment Study”.

[294] Staab, S. and Studer, R. 2004. Handbook on Ontologies. Berlin; New York, NY, USA: Springer.

[295] Strickland, J. 2007. Conceptual Modeling for an End-to-End C4ISR Systems Experiment Model,
Conceptual Modeling Workshop. UAH – Huntsville, AL, USA.

[296] Strickland, J. 2007. Conceptual Modeling for an End-to-End C4ISR Systems Experiment Model,
AMSC Workshop on Conceptual Modeling. University of Alabama, Huntsville, AL, USA.

[297] Tackett, G. 2007. Conceptual Modeling in OneSAF Software Development, AMSC Workshop on
Conceptual Modeling. University of Alabama, Huntsville, AL, USA.

[298] Tamucci, M.S., D. Timian and S.K. Burnett. 2000. “Conceptual Modeling of Foreign Command Decision
Processes” Paper 00S-SIW-019, Spring SIW. Orlando, FL, USA: Proceedings of the Spring 2000
Simulation Interoperability Workshop, CD.

[299] Tanrıöver, Ö. and Bilgen, S. 2007. An Inspection Approach for Conceptual Models in Notations Derived
from UML: A Case Study, ISCIS 2007 – 22nd International Symposium on Computer and Information
Sciences. Ankara, Turkey.

[300] Teeuw, W.B. and H. van den Berg. 2010. On the Quality of Conceptual Models – http://osm7.cs.byu.
edu/ER97/workshop4/tvdb.html.

[301] Teledyne Brown Engineering. 1988. Initial Requirements Study of USASDC ERIS Simulation (ESIM)
for KEW T&E Engineering Support Program (KEYTEST).

[302] The Cost Effectiveness of Modeling and Simulation (M&S) MSG-031 Final Report – Draft. 2008,
NATO MSWG.

[303] The Economist Website; Risk; http://www.economist.com/research/economics/alphabetic.cfm?letter=

R#risk.

[304] The Free Dictionary; Design; http://www.thefreedictionary.com/design.

[305] Timian, D.H., R.T. Dunbar and H.P. Stickley. 2003. “Army Objective Force Intelligence, Surveillance,
and Reconnaissance (ISR) Architecture Modeling Shortfalls”, Paper 03F-SIW-018 Fall SIW. Orlando,
FL, USA: Proceedings of the Fall 2003 Simulation Interoperability Workshop, 2003, CD.

[306] Tolk, A. and Muguira, J.A. 2003. “The Levels of Conceptual Interoperability Model”, Paper 03F-SIW-
007, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2003 Simulation Interoperability Workshop.

RTO-TR-MSG-058 K - 19
ANNEX K – BIBLIOGRAPHY

[307] Tolk, A. 2008. “Triangles of Interoperation” (08F-SIW-067), Fall SIW. Orlando, FL, USA: Proceedings
of the Fall 2008 Simulation Interoperability Workshop.

[308] Tolk, A. 2010. M&S Body of Knowledge: Progress Report and Look Ahead, SCS M&S Magazine,
Vol. I.

[309] Toolkit for Conceptual Modeling (TCM) Website; http://wwwhome.cs.utwente.nl/~tcm/.

[310] Topçu, O. “Development, Representation and Validation of Conceptual Models in Distributed

Simulation”, DRDC Atlantic TM 2003-142, Defence R&D Canada – Atlantic, 2003.

[311] Trbovich, S. and R. Reading. 2005. “Simulation and Software Development for Capabilities Based
Warfare: An Analysis of Harmonized Systems Engineering Processes” Paper 05S-SIW-106, Spring
SIW. San Diego, CA, USA: Proceedings of the Spring 2005 Simulation Interoperability Workshop, CD.

[312] Turrell, C. 2004. JSB Proto-Federation.

[313] UK Ministry of Defence. 2008. A Generic Process for the Verification & Validation of Modelling and
Simulation & Synthetic Environments Systems.

[314] US DoD. Air Force Policy Directive (AFPD) 16-10, “Modeling and Simulation Management”.
The Pentagon, Washington, DC, USA: Department of the Air Force.

[315] US DoD. Air Force (AF) Instruction 16-1001, “Verification, Validation, and Accreditation” (VV&A).
The Pentagon, Washington, DC, USA: Department of the Air Force.

[316] US DoD. Air Force Systems Command/AFLCP 800-5, “Software Independent Verification and
Validation”.

[317] US DoD. Army Regulation (AR) 5-11, “Army Model and Simulation Management Program”.
The Pentagon, Washington, DC, USA: Department of the Army.

[318] US DoD. Department of Defense Directive (DoDD) 5000.59, “Department of Defense (DoD) Modeling
and Simulation (M&S) Management”. The Pentagon, Washington, DC, USA: The Department of
Defense.

[319] US DoD. DoD Instruction (DODI) 5000.61, “DoD Modeling and Simulation (M&S) Verification,
Validation and Accreditation (VV&A)”. The Pentagon, Washington, DC, USA: The Department of
Defense.

[320] US DoD. DoD Guide to Integrated Product and Process Development (Version 1.0). Washington, DC,
USA 20301-3000: Office of the Under Secretary of Defense (Acquisition and Technology).

[321] US DoD. Department of the Army Pamphlet (DA PAM) 5-11, “Verification, Validation, and
Accreditation of Army Models and Simulations”. The Pentagon, Washington, DC, USA: Department
of the Army.

[322] US DoD. Department of the Navy Modeling and Simulation Verification, Validation, and Accreditation
Implementation Handbook. The Pentagon, Washington DC, USA: Department of the Navy.

K - 20 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[323] US DoD. Joint Chief of Staff Instruction (JSI) 8104.01 “Verification, Validation, and Accreditation of
Joint Models and Simulations. The Pentagon, Washington, DC, USA: The Department of Defense.

[324] US DoD. Joint Advanced Distributed Simulation Joint Test Force Report (JADS JT&E-TR-99-017)
“The Utility of Advanced Distributed Simulation for Electronic Warfare Systems Testing”. Kirtland
Air Force Base, NM, USA: Joint Advanced Distributed Simulation Joint Test Force.

[325] US DoD. JADS JT&E Report (JADS JT&E-TR-99-019) “Special Report on Programmatic Challenges
to Distributed Testing”. Kirtland Air Force Base, NM, USA: Joint Advanced Distributed Simulation
Joint Test Force.

[326] US DoD. Missile Defense Agency (MDA) Directive 5011, Missile Defense Agency Models and
Simulations Verification, Validation, and Accreditation (VV&A). The Pentagon, Washington, DC, USA:
MDA.

[327] US DoD. MIL-M-81203 – “Validation/Verification Plan”.

[328] US DoD. NASA-GB-002-95, “Formal Methods Specification and Verification Guidebook for Software
and Computer Systems”, Volume I: Planning and Technology Insertion, Release 1.0.

[329] US DoD. Secretary of the Navy Instruction (SECNAVINST) 5200.38, “Department of the Navy
Modeling and Simulation Program”. The Pentagon, Washington, DC, USA: Department of the Navy.

[330] US DoD. SECNAVINST 5200.40, “Verification, Validation and Accreditation of Models and
Simulations”. The Pentagon, Washington, DC, USA: Department of the Navy.

[331] US DoD. DI-M-2051A, “Technical Manual Quality Assurance Data: Navy.

[332] US DoD. 1994. Data Administration Procedures – DoD 8320.1-M.

[333] US DoD. 1994. Data Quality Assurance Procedures – DoD 8320.1-M-3.

[334] US DoD. 1995. Modeling and Simulation (M&S Master Plan – DoD 5000.59-P.

[335] US DoD. 1996. Department of Defense Verification, Validation & Accreditation (VV&A) Recommended
Practices Guide. The Pentagon, Washington, DC, USA: The Department of Defense.

[336] US DoD. 2005. Management of Army Models and Simulations, Army Regulation 5-11 – http://www.
army.mil/usapa/epubs/pdf/r5_11.pdf . Department of the Army.

[337] US DoD. 2005. Navy Modeling and Simulation Standard – Best Practices Guide for Verification,
Validation, and Accreditation of Legacy Modeling and Simulation: Navy Modeling and Simulation
Standards Project.

[338] US DoD. 2007. Modeling and Simulation (M&S), Verification, Validation, and Accreditation (VV&A),
Vol. MDA Directive 8315.01: Missile Defense Agency.

[339] US DoD; DoD Architecture Framework Version 1.5 – Volume I: Definitions and Guidelines;
http://cio-nii.defense.gov/docs/DoDAF_Volume_I.pdf.

RTO-TR-MSG-058 K - 21
ANNEX K – BIBLIOGRAPHY

[340] US DoD; DoD Architecture Framework Version 1.5 – Volume II: Product Descriptions; http://cio-
nii.defense.gov/docs/DoDAF_Volume_II.pdf.

[341] US DoD; DoD Architecture Framework Version 1.5 – Volume III: Architecture Data Description;
http://cio-nii.defense.gov/docs/DoDAF_Volume_III.pdf.

[342] US DoD. 2008. Department of Defense Standard Practice – Documentation of Verification, Validation,
and Accreditation (VV&A) for Models and Simulations: Modeling and Simulation Coordination
Office.

[343] US Federal Energy Regulatory Commission. 1998. Inquiry Concerning the Commission’s Policy on
the Use of Computer Models in Merger Analysis.

[344] US General Accounting Office. DOD Simulations: Improved Assessment Procedures Would Increase
the Credibility of Results”, Technical Report GAO/PEMD-88-3. Washington, DC, USA.

[345] US General Accounting Office. US GAO, “Guidelines for Model Evaluation”. Washington, DC, USA.

[346] US General Accounting Office. US GAO, “Report to the Congress: Ways to Improve Management of
Federally Funded Computerized Models”. Washington, DC, USA.

[347] US General Accounting Office. 1995. Military Training – Cost Effective Development of Simulations
Presents Significant Challenges. Report to Congressional Committees.

[348] US Patent and Trademark Office; 1502 Definition of a Design [R-2] – 1500 Design Patents;
http://www.uspto.gov/web/offices/pac/mpep/documents/1500_1502.htm.

[349] Valle, T. 2002. OneSAF CGF Advisory Board Conceptual Model Tutorial.

[350] van Bommel, P., S. Hoppenbrouwers, E. Proper and T. van der Weide. On the use of Object-Role
Modeling to Model Active Domains: Radboud University Nijmegen.

[351] van der Zee, D.-J. 2006. Building Communicative Models – A Job Oriented Approach to Manufacturing
Simulation. In S. Robinson, S. Taylor, S. Brailsford and J. Garnett (Eds.), OR Society Simulation
Workshop.

[352] Vander Schaaf, R. 2007. A System-of-Systems (SoS) Approach to Effective Organizational Decision-
Making for Infrastructure Project Selection, Conceptual Modeling Workshop. UAH – Huntsville, AL,
USA.

[353] Vander Schaaf, R. 2007. A System-of-Systems (SoS) Approach to Effective Organizational Decision-
Making For Infrastructure Project Selection, AMSC Workshop on Conceptual Modeling. University of
Alabama, Huntsville, AL, USA.

[354] Waite, B. 1995. Application of Object-Oriented-Analysis (OOA) concepts and practices to the
implementation of the DoD Modeling and Simulation Master Plan – A White Paper.

[355] Waite, W.F. 1997. HLA Federation Design / Development and Federation Implementation Process
Model - 97F-SIW-173, Fall SIW. Orlando, FL, USA.

K - 22 RTO-TR-MSG-058
 ANNEX K – BIBLIOGRAPHY

[356] Waite, W.F. 1997. Object-Oriented Representation Schemas for Conceptual Models of the Mission
Space (CMMS) – 97S-SIW-065, Spring SIW. Orlando, FL, USA.

[357] Waite, W.F. 1997. Leveraging HLA’s Object Orientation to Represent Human Decision Making,
Command, and Control-97S-SIW-066, Spring SIW. Orlando, FL, USA.

[358] Waite, W.F. Proposal for Establishment of a Technical CHAPTER within the Society for Computer
Simulation (SCS) on “The Economics of Modeling and Simulation”. 2000.

[359] Waite, W.F. Terms of Reference (TOR) Revised for the SISO Task Group on The Economics of
Simulation. 2001.

[360] Waite, W.F. Tutorial: Economics of M&S: Change-Agents or Martyrs for Innovation. I/ITSEC 05,
Sponsored by NTSA, 2005.

[361] Waite, B. 2007. Conceptual Modeling Practice, SummerSim. San Diego, CA, USA.

[362] Waite, B. 2010. Briefing from NATO RTO MSG-058 Task Group to SISO Conceptual Modeling Product
Development Group on “Best Practice Guidance in Conceptual Modeling for Military Simulations”.
Orlando, FL, USA.

[363] Wang, W. and Brooks, R.J. 2006. Improving the Understanding of Conceptual Modelling. In S. Robinson,
S. Taylor, S. Brailsford and J. Garnett (Eds.), OR Society Simulation Workshop.

[364] Weilkiens, T. 2007. Systems Engineering with SysML/UML: Modeling, Analysis, Design. Amsterdam;
Boston, MA, USA: Morgan Kaufmann OMG Press/Elsevier.

[365] Weiner, J. and P.D. Gutierrez. 2003. “Conceptual Modeling of a Legacy Constructive Simulation:
A Use Case” Paper 03F-SIW-064 Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2003 Simulation
Interoperability Workshop, CD.

[366] Wenger, E., McDermott, R.A. and Snyder, W. 2002. Cultivating Communities of Practice: A Guide to
Managing Knowledge. Boston, MA, USA: Harvard Business School Press.

[367] White, S. 2006. Introduction to BPMN: IBM Corporation.

[368] Widman, L.E., Loparo, K.A. and Nielsen, N.R. 1989. Artificial Intelligence, Simulation, and Modeling.
New York, NY, USA: Wiley.

[369] Wikipedia the free encyclopedia; Computer Science; http://en.wikipedia.org/wiki/Computer_science.

[370] Wikipedia the free encyclopedia; Use Case; http://en.wikipedia.org/wiki/Use_case.

[371] Wycoff, J. 1991. Mindmapping: Your Personal Guide to Exploring Creativity and Problem-Solving
(Berkley Trade Pbk. Ed.). New York, NY, USA: Berkley Books.

[372] Xue-hui, W., Z. Lei, and H. Ke-di. 2004. “Improving Simulation Conceptual Model” Paper 04F-SIW-
036, Fall SIW. Orlando, FL, USA: Proceedings of the Fall 2004 Simulation Interoperability Workshop.

RTO-TR-MSG-058 K - 23
ANNEX K – BIBLIOGRAPHY

[373] Yi, C.H., V. Mojtahed and M. García Lozano. 2006. REVVA and DCMF: A Link between VV&A and
Conceptual Modelling.

[374] Zeigler, B.P. 1976. Theory of Modelling and Simulation. New York, NY, USA: Wiley.

[375] Zeigler, B.P. 1999. “A Theory-based Conceptual Terminology for M&S VV&A” Paper 99S-SIW-064,
Spring SIW: pp. 133-144. Orlando, FL, USA: Proceedings of the Spring 1999 Simulation Interoperability
Workshop.

[376] Zeigler, B.P., Praehofer, H. and Kim, T.G. 2000. Theory of Modeling and Simulation: Integrating
Discrete Event and Continuous Complex Dynamic Systems (2nd Ed.). San Diego, CA, USA: Academic
Press.

[377] Zeigler, B.P. and Hammonds, P.E. 2007. Modeling & Simulation-Based Data Engineering: Introducing
Pragmatics into Ontologies for Net-Centric Information Exchange. Oxford, UK: Academic.

K - 24 RTO-TR-MSG-058
 REPORT DOCUMENTATION PAGE
1. Recipient’s Reference 2. Originator’s References 3. Further Reference 4. Security Classification
of Document
RTO-TR-MSG-058 ISBN UNCLASSIFIED/
AC/323(MSG-058)TP/404 978-92-837-0150-7 UNLIMITED
5. Originator
Research and Technology Organisation
North Atlantic Treaty Organisation
BP 25, F-92201 Neuilly-sur-Seine Cedex, France
6. Title
Conceptual Modeling (CM) for Military Modeling and Simulation (M&S)
7. Presented at/Sponsored by

Final Report of MSG-058.

8. Author(s)/Editor(s) 9. Date

Multiple July 2012

10. Author’s/Editor’s Address 11. Pages

Multiple 334
12. Distribution Statement
There are no restrictions on the distribution of this document.
Information about the availability of this and other RTO
unclassified publications is given on the back cover.
13. Keywords/Descriptors
Best-practice Interoperability Re-use
Collaboration Modeling Schema
Concepts Modeling and simulation enterprise Simulation
Conceptual modeling process-specification Ontology Stakeholders
Conceptual modeling product-specification Representation Standards
Conceptual-modeling
14. Abstract

The objectives of the Task Group (MSG-058) include: 1) Clarify the “Conceptual Model” concepts,
discuss the terminology, and emphasize the utility to better formalize conceptual models; 2) Investigate
methodologies, simulation and software engineering processes, initiatives and technologies useful
for the establishment of conceptual models; 3) Identify the relevant stakeholders of conceptual models;
4) Address the needs of M&S community, identifying the way conceptual models may contribute to
M&S development, and provide guidance to implementation; 5) Provide guidelines for standards in
conceptual modeling for M&S; thereby specifying a conceptual model to be (re)usable by users
with similar knowledge; 6) Draft a guidance document on conceptual models that can be used by
different stakeholders; and 7) Foster the establishment of the guidance document as a SISO standard.
This document is intended to serve as best-practice prescriptive guidance for the life cycle
management of conceptual modeling in support of modeling and simulation effort within the NATO
M&S enterprise. Subsequently, the contents of this document are expected to serve as a basis of
evolution of conceptual modeling throughout the international M&S community of practice by
virtue of its influence upon further international standards.

RTO-TR-MSG-058
RTO-TR-MSG-058
 NORTH ATLANTIC TREATY ORGANISATION RESEARCH AND TECHNOLOGY ORGANISATION

BP 25 DIFFUSION DES PUBLICATIONS

F-92201 NEUILLY-SUR-SEINE CEDEX • FRANCE
Télécopie 0(1)55.61.22.99 • E-mail mailbox@rta.nato.int RTO NON CLASSIFIEES
Les publications de l’AGARD et de la RTO peuvent parfois être obtenues auprès des centres nationaux de distribution indiqués ci-dessous. Si vous
souhaitez recevoir toutes les publications de la RTO, ou simplement celles qui concernent certains Panels, vous pouvez demander d’être inclus soit à
titre personnel, soit au nom de votre organisation, sur la liste d’envoi.
Les publications de la RTO et de l’AGARD sont également en vente auprès des agences de vente indiquées ci-dessous.
Les demandes de documents RTO ou AGARD doivent comporter la dénomination « RTO » ou « AGARD » selon le cas, suivi du numéro de série.
Des informations analogues, telles que le titre est la date de publication sont souhaitables.
Si vous souhaitez recevoir une notification électronique de la disponibilité des rapports de la RTO au fur et à mesure de leur publication, vous pouvez
consulter notre site Web (www.rto.nato.int) et vous abonner à ce service.

CENTRES DE DIFFUSION NATIONAUX

ALLEMAGNE GRECE (Correspondant) REPUBLIQUE TCHEQUE
Streitkräfteamt / Abteilung III Defence Industry & Research General LOM PRAHA s. p.
Fachinformationszentrum der Bundeswehr (FIZBw) Directorate, Research Directorate o. z. VTÚLaPVO
Gorch-Fock-Straße 7, D-53229 Bonn Fakinos Base Camp, S.T.G. 1020 Mladoboleslavská 944
Holargos, Athens PO Box 18
BELGIQUE 197 21 Praha 9
Royal High Institute for Defence – KHID/IRSD/RHID HONGRIE
Management of Scientific & Technological Research Hungarian Ministry of Defence ROUMANIE
for Defence, National RTO Coordinator Development and Logistics Agency Romanian National Distribution
Royal Military Academy – Campus Renaissance P.O.B. 25, H-1885 Budapest Centre
Renaissancelaan 30, 1000 Bruxelles Armaments Department
ITALIE 9-11, Drumul Taberei Street
CANADA General Secretariat of Defence and Sector 6
DSIGRD2 – Bibliothécaire des ressources du savoir National Armaments Directorate 061353, Bucharest
R et D pour la défense Canada 5th Department – Technological
Ministère de la Défense nationale Research ROYAUME-UNI
305, rue Rideau, 9e étage Via XX Settembre 123, 00187 Roma Dstl Knowledge and Information
Ottawa, Ontario K1A 0K2 Services
LUXEMBOURG Building 247
DANEMARK Voir Belgique Porton Down
Danish Acquisition and Logistics Organization (DALO) Salisbury SP4 0JQ
Lautrupbjerg 1-5, 2750 Ballerup NORVEGE
Norwegian Defence Research SLOVAQUIE
ESPAGNE Establishment, Attn: Biblioteket Akadémia ozbrojených síl gen.
SDG TECIN / DGAM P.O. Box 25 M.R. Štefánika, Distribučné a
C/ Arturo Soria 289 NO-2007 Kjeller informačné stredisko RTO
Madrid 28033 Demänová 393, Liptovský Mikuláš 6
PAYS-BAS 031 06
ESTONIE Royal Netherlands Military
Estonian Ministry of Defence Academy Library SLOVENIE
Estonian National Coordinator for NATO RTO P.O. Box 90.002 Ministry of Defence
Sakala 1, Tallinn 15094 4800 PA Breda Central Registry for EU and
NATO
ETATS-UNIS POLOGNE Vojkova 55
NASA Center for AeroSpace Information (CASI) Centralna Biblioteka Wojskowa 1000 Ljubljana
7115 Standard Drive ul. Ostrobramska 109
Hanover, MD 21076-1320 04-041 Warszawa TURQUIE
Milli Savunma Bakanlığı (MSB)
FRANCE PORTUGAL ARGE ve Teknoloji Dairesi
O.N.E.R.A. (ISP) Estado Maior da Força Aérea Başkanlığı
29, Avenue de la Division Leclerc SDFA – Centro de Documentação 06650 Bakanliklar
BP 72, 92322 Châtillon Cedex Alfragide, P-2720 Amadora Ankara

AGENCES DE VENTE
NASA Center for AeroSpace The British Library Document Canada Institute for Scientific and
Information (CASI) Supply Centre Technical Information (CISTI)
7115 Standard Drive Boston Spa, Wetherby National Research Council Acquisitions
Hanover, MD 21076-1320 West Yorkshire LS23 7BQ Montreal Road, Building M-55
ETATS-UNIS ROYAUME-UNI Ottawa K1A 0S2, CANADA
Les demandes de documents RTO ou AGARD doivent comporter la dénomination « RTO » ou « AGARD » selon le cas, suivie du numéro de série
(par exemple AGARD-AG-315). Des informations analogues, telles que le titre et la date de publication sont souhaitables. Des références bibliographiques
complètes ainsi que des résumés des publications RTO et AGARD figurent dans les journaux suivants :
Scientific and Technical Aerospace Reports (STAR) Government Reports Announcements & Index (GRA&I)
STAR peut être consulté en ligne au localisateur de ressources publié par le National Technical Information Service
uniformes (URL) suivant: http://ntrs.nasa.gov/search.jsp Springfield
STAR est édité par CASI dans le cadre du programme Virginia 2216
NASA d’information scientifique et technique (STI) ETATS-UNIS
NASA Langley Research Center, STI Program Office, MS 157A (accessible également en mode interactif dans la base de
Hampton, Virginia 23681-0001 données bibliographiques en ligne du NTIS, et sur CD-ROM)
ETATS-UNIS
 NORTH ATLANTIC TREATY ORGANISATION RESEARCH AND TECHNOLOGY ORGANISATION

BP 25 DISTRIBUTION OF UNCLASSIFIED
F-92201 NEUILLY-SUR-SEINE CEDEX • FRANCE RTO PUBLICATIONS
Télécopie 0(1)55.61.22.99 • E-mail mailbox@rta.nato.int
AGARD & RTO publications are sometimes available from the National Distribution Centres listed below. If you wish to receive all RTO reports,
or just those relating to one or more specific RTO Panels, they may be willing to include you (or your Organisation) in their distribution.
RTO and AGARD reports may also be purchased from the Sales Agencies listed below.
Requests for RTO or AGARD documents should include the word ‘RTO’ or ‘AGARD’, as appropriate, followed by the serial number. Collateral
information such as title and publication date is desirable.
If you wish to receive electronic notification of RTO reports as they are published, please visit our website (www.rto.nato.int) from where you can
register for this service.

NATIONAL DISTRIBUTION CENTRES

BELGIUM GREECE (Point of Contact) ROMANIA
Royal High Institute for Defence – KHID/IRSD/RHID Defence Industry & Research General Romanian National Distribution
Management of Scientific & Technological Research Directorate, Research Directorate Centre
for Defence, National RTO Coordinator Fakinos Base Camp, S.T.G. 1020 Armaments Department
Royal Military Academy – Campus Renaissance Holargos, Athens 9-11, Drumul Taberei Street
Renaissancelaan 30 Sector 6, 061353, Bucharest
1000 Brussels HUNGARY
Hungarian Ministry of Defence SLOVAKIA
CANADA Development and Logistics Agency Akadémia ozbrojených síl gen.
DRDKIM2 – Knowledge Resources Librarian P.O.B. 25, H-1885 Budapest M.R. Štefánika, Distribučné a
Defence R&D Canada informačné stredisko RTO
Department of National Defence ITALY Demänová 393, Liptovský Mikuláš 6
305 Rideau Street, 9th Floor General Secretariat of Defence and 031 06
Ottawa, Ontario K1A 0K2 National Armaments Directorate
5th Department – Technological SLOVENIA
CZECH REPUBLIC Research Ministry of Defence
LOM PRAHA s. p. Via XX Settembre 123, 00187 Roma Central Registry for EU & NATO
o. z. VTÚLaPVO Vojkova 55
Mladoboleslavská 944 LUXEMBOURG 1000 Ljubljana
PO Box 18 See Belgium
197 21 Praha 9 SPAIN
NETHERLANDS SDG TECIN / DGAM
DENMARK Royal Netherlands Military C/ Arturo Soria 289
Danish Acquisition and Logistics Organization Academy Library Madrid 28033
(DALO) P.O. Box 90.002
Lautrupbjerg 1-5 4800 PA Breda TURKEY
2750 Ballerup Milli Savunma Bakanlığı (MSB)
NORWAY ARGE ve Teknoloji Dairesi
ESTONIA Norwegian Defence Research Başkanlığı
Estonian Ministry of Defence Establishment, Attn: Biblioteket 06650 Bakanliklar – Ankara
Estonian National Coordinator for NATO RTO P.O. Box 25
Sakala 1, Tallinn 15094 NO-2007 Kjeller UNITED KINGDOM
Dstl Knowledge and Information
FRANCE POLAND Services
O.N.E.R.A. (ISP) Centralna Biblioteka Wojskowa Building 247
29, Avenue de la Division Leclerc ul. Ostrobramska 109 Porton Down
BP 72, 92322 Châtillon Cedex 04-041 Warszawa Salisbury SP4 0JQ

GERMANY PORTUGAL UNITED STATES

Streitkräfteamt / Abteilung III Estado Maior da Força Aérea NASA Center for AeroSpace
Fachinformationszentrum der Bundeswehr (FIZBw) SDFA – Centro de Documentação Information (CASI)
Gorch-Fock-Straße 7 Alfragide, P-2720 Amadora 7115 Standard Drive
D-53229 Bonn Hanover, MD 21076-1320

SALES AGENCIES
NASA Center for AeroSpace The British Library Document Canada Institute for Scientific and
Information (CASI) Supply Centre Technical Information (CISTI)
7115 Standard Drive Boston Spa, Wetherby National Research Council Acquisitions
Hanover, MD 21076-1320 West Yorkshire LS23 7BQ Montreal Road, Building M-55
UNITED STATES UNITED KINGDOM Ottawa K1A 0S2, CANADA

Requests for RTO or AGARD documents should include the word ‘RTO’ or ‘AGARD’, as appropriate, followed by the serial number (for example
AGARD-AG-315). Collateral information such as title and publication date is desirable. Full bibliographical references and abstracts of RTO and
AGARD publications are given in the following journals:
Scientific and Technical Aerospace Reports (STAR) Government Reports Announcements & Index (GRA&I)
STAR is available on-line at the following uniform resource published by the National Technical Information Service
locator: http://ntrs.nasa.gov/search.jsp Springfield
STAR is published by CASI for the NASA Scientific Virginia 2216
and Technical Information (STI) Program UNITED STATES
NASA Langley Research Center, STI Program Office, MS 157A (also available online in the NTIS Bibliographic Database
Hampton, Virginia 23681-0001 or on CD-ROM)
UNITED STATES
ISBN 978-92-837-0150-7