NORTH ATLANTIC TREATY SCIENCE AND TECHNOLOGY

ORGANIZATION ORGANIZATION

AC/323(MSG-086)TP/562 www.sto.nato.int

STO TECHNICAL REPORT TR-MSG-086-Part-II

Guideline on Scenario Development for
(Distributed) Simulation Environments
(Guide en vue du développement de scénario
dans le cadre de simulation distribuée)

Part of the Final Report of MSG-086.

Published January 2015

Distribution and Availability on Back Cover

NORTH ATLANTIC TREATY SCIENCE AND TECHNOLOGY
ORGANIZATION ORGANIZATION

AC/323(MSG-086)TP/562 www.sto.nato.int

STO TECHNICAL REPORT TR-MSG-086-Part-II

Guideline on Scenario Development for
(Distributed) Simulation Environments
(Guide en vue du développement de scénario
dans le cadre de simulation distribuée)

Part of the Final Report of MSG-086.

The NATO Science and Technology Organization
Science & Technology (S&T) in the NATO context is defined as the selective and rigorous generation and application of
state-of-the-art, validated knowledge for defence and security purposes. S&T activities embrace scientific research,
technology development, transition, application and field-testing, experimentation and a range of related scientific
activities that include systems engineering, operational research and analysis, synthesis, integration and validation of
knowledge derived through the scientific method.
In NATO, S&T is addressed using different business models, namely a collaborative business model where NATO
provides a forum where NATO Nations and partner Nations elect to use their national resources to define, conduct and
promote cooperative research and information exchange, and secondly an in-house delivery business model where S&T
activities are conducted in a NATO dedicated executive body, having its own personnel, capabilities and infrastructure.
The mission of the NATO Science & Technology Organization (STO) is to help position the Nations’ and NATO’s S&T
investments as a strategic enabler of the knowledge and technology advantage for the defence and security posture of
NATO Nations and partner Nations, by conducting and promoting S&T activities that augment and leverage the
capabilities and programmes of the Alliance, of the NATO Nations and the partner Nations, in support of NATO’s
objectives, and contributing to NATO’s ability to enable and influence security and defence related capability
development and threat mitigation in NATO Nations and partner Nations, in accordance with NATO policies.
The total spectrum of this collaborative effort is addressed by six Technical Panels who manage a wide range of
scientific research activities, a Group specialising in modelling and simulation, plus a Committee dedicated to
supporting the information management needs of the organization.
• 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 Panels and Group are the power-house of the collaborative model and are made up of national representatives as
well as recognised world-class scientists, engineers and information specialists. In addition to providing critical
technical oversight, they also provide a communication link to military users and other NATO bodies.
The scientific and technological work is carried out by Technical Teams, created under one or more of these eight
bodies, for specific research activities which have a defined duration. These research activities can take a variety of
forms, including Task Groups, Workshops, Symposia, Specialists’ Meetings, Lecture Series and Technical Courses.

The content of this publication has been reproduced directly from material supplied by STO or the authors.

Published January 2015

Copyright © STO/NATO 2015
All Rights Reserved

ISBN 978-92-837-0201-2

Single copies of this publication or of a part of it may be made for individual use only by those organisations or
individuals in NATO Nations defined by the limitation notice printed on the front cover. The approval of the STO
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 STO-TR-MSG-086-Part-II

3 MEL/MIL 2-10 Chapter 3 – Content of a Scenario 3-1 3.3 Auxiliary Terms 2-10 2.1 Vignettes 2-10 2.2.2 Scenario Variants 2-10 2.6 Rules of Engagement 3-4 STO-TR-MSG-086-Part-II iii .4 Intended Audience 1-2 1.2.2 Purpose 1-1 1.3.2. Table of Contents Page List of Figures vii List of Tables viii List of Acronyms ix MSG-086 Membership List x Executive Summary and Synthèse ES-1 Chapter 1 – Introduction 1-1 1.2.2 Relation of Conceptual Scenario and Conceptual Model 2-6 2.5 Surrounding Conditions 3-4 3.2.1 Preliminary Remarks 3-1 3.3 Scope 1-1 1.2 Scenario Development Process 2-1 2.1 Relation of Conceptual Scenario and Operational Scenario 2-6 2.1 Definition “Scenario” 2-1 2.5 Document Outline 1-2 Chapter 2 – Scenarios in Distributed Simulation Environments 2-1 2.2.3.1 Motivation 1-1 1.1 Objects and Units 3-2 3.2.3 Executable Scenario 2-7 2.2.3.2 Conceptual Scenario 2-5 2.2 Forces and Force Structure 3-3 3.2 Initial State 3-2 3.2.3 Geography 3-3 3.4 Date/Time 3-4 3.1 Operational Scenario 2-3 2.2.2.2.2.

3.1 Rationale A-1 A.5 Allied Data Publication 3 (ADatP-3) 5-3 5.6 Joint Exercise Management Module (JEMM) 5-4 5.2 Components Regarding Course of Events of a Scenario 3-6 3.6 Coalition-Battle Management Language (C-BML) 5-3 5.1.3 General Purpose Software 5-2 5.1.5.2 Standards and Tools for Conceptual Scenarios 5-3 5.1 Standards and Tools for Operational Scenarios 5-2 5.2.2.4 Joint C3 Information Exchange Data Model (JC3IEDM) 5-2 5.2 NATO Comprehensive Operations Planning Directive 5-2 5.4 Environmental Events 3-5 3.3 NAF Templates for Conceptual Scenarios A-2 iv STO-TR-MSG-086-Part-II .3.5 VEVA Process Model 5-4 5.2.5.2 Architectures in the Scenario Development Process A-2 A.2 Interaction Events 3-5 3.3 Level 2 – Standardized Scenario Specification 4-2 4.3.1.2.1 Military Scenario Definition Language (MSDL) 5-5 5.4 Base Object Models (BOMs) 5-4 5.3.3.5 Relation of Maturity Levels to Scenario Types 4-3 Chapter 5 – Standards and Tools for Scenario Specification 5-1 5.2 Level 1 – Non-Standardized Scenario Specification 4-2 4.3 Standards and Tools for Executable Scenarios 5-5 5.1.3.2.5.4 Termination Conditions 3-5 3.1 Communication Events 3-5 3.3 Course of Events 3-4 3.1.1 Level 0 – No Written Scenario Specification 4-1 4.3 State Change Events 3-5 3.2 Order of Battle Service (OBS) 5-5 Chapter 6 – References 6-1 Annex A – Scenario Specification Using the NATO Architecture Framework A-1 A.3 Systems Modelling Language (SysML) 5-4 5.2.1 DSEEP 5-2 5.3 Components Regarding Termination Conditions of a Scenario 3-8 Chapter 4 – Maturity Levels of Scenario Specification 4-1 4.1 Components Regarding Initial State of a Scenario 3-6 3.2 Unified Modeling Language (UML) 5-3 5.1 NATO Architecture Framework (NAF) 5-3 5.3.4 Level 3 – Formal Scenario Specification 4-3 4.5 Reuse in the Scenario Development Process 3-5 3.1.

1 NOV Operational View A-3 A.1 Overview of the BOM Standard B-1 B.3 Geography C-3 C.2.3 Using BOMS for Scenario Specification C-4 C.3.1.3.3.1.3 Object Model Definition B-2 B.3 Ideas for Improving the BOM Standard B-3 Annex C – Example Scenario “Air Defence” C-1 C.2.1.5 Rules of Engagement C-3 C.1.2 Textual Description of the Conceptual Scenario C-2 C.2.2 Pattern of Interplay C-6 C. A.2.1 Communication Events C-3 C.2.4 Model Mapping B-2 B.1.2 Conceptual Scenario D-1 D.2.2.3.1 Description of the Operational Scenario C-1 C.2 Conceptual Model Definition B-1 B.1 Operational Scenario D-1 D.2 FAC Team D-2 D.1.2.1 Model Identification C-4 C.1.2 Evaluation B-3 B.1.1 F-16 Flight D-1 D.2 Conceptual Model Definition C-5 C.1 Model Identification B-1 B.1.2.3 Termination Conditions C-4 C.2.1.2.2.1 Initial State C-2 C.2.3 Infantry Unit D-3 STO-TR-MSG-086-Part-II v .3.2 Forces and Force Structure C-2 C.2.1 Initial State D-1 D.2.3 Other Views and Templates A-6 Annex B – Scenario Specification Using Base Object Models B-1 B.2.2.3 Object Model Definition and Model Mapping C-11 Annex D – Example Scenario “Close Air Support” D-1 D.2.2.1 Entity Types C-5 C.1.1 Units C-2 C.4 Surrounding Conditions C-3 C.2 Negative Experiences B-3 B.2 Course of Events C-3 C.1.1 Positive Experiences B-3 B.3.3.1.2.2 Interaction Events C-3 C.3 State Machines C-8 C.3.3.5 Documentation of BOMs B-2 B.2.2.2 NSV System View A-4 A.

2.3 Environmental Events D-4 D.1.1.1. Date/Time D-3 D.1 Communication Events D-3 D.2.2.3 Discussion D-5 vi STO-TR-MSG-086-Part-II .7 Rules of Engagement D-3 D.2 Course of Action D-3 D.2.6 Surrounding Conditions D-3 D.4 Insurgents D-3 D.1.2.2.5 Geography.2.3 Termination Criteria D-5 D.2. D.2.2.2 Interaction Events D-3 D.2.2.

List of Figures Figure Page Figure 2-1 Types of Scenarios in the Simulation Environment Engineering Process 2-2 Figure 2-2 Role of Operational Scenarios in the Early Steps of a Simulation Environment 2-3 Engineering Process Figure 2-3 Relation of Conceptual Scenario and Conceptual Model Regarding Entity Classes 2-7 and Entities and Example Figure 2-4 Allocation of Entities to Federates of a Simulation Environment for Different 2-8 Executions of the Simulation Environment Figure 2-5 Allocation of Values to Attributes of Entities to be Represented by the Different 2-9 Federates for Different Simulation Environment Executions Figure 3-1 Refinement and Extension of the Content of a Scenario Along the Scenario 3-1 Development Process Figure 3-2 Relationship between Vignettes and Vignette Configurations for Composing a 3-7 Scenario Figure A-1 NOV-5 Operational Activity Tree for Scenario Example from Annex C A-4 Figure A-2 NOV-2 Operational Nodes for Scenario Example from Annex C A-4 Figure A-3 NSV-2 System Communication Template for Scenario Example from Annex C A-6 Figure B-1 Example Specification of State Machine as a Table and as a Diagram B-2 Figure C-1 Area of Interest C-1 Figure C-2 Overview of Pattern of Interplay in Example Scenario “Air Defence” C-7 Figure C-3 State Machine of ManPAD Commander C-8 Figure C-4 State Machine of ManPAD Observer C-9 Figure C-5 State Machine of ManPAD Gunner C-9 Figure C-6 State Machine of Target C-10 Figure C-7 State Machine of Missile C-11 Figure D-1 Actors D-2 Figure D-2 Two Roles in the FAC Team D-2 Figure D-3 Scenario Interactions Between Different Actors D-4 STO-TR-MSG-086-Part-II vii .

List of Tables Table Page Table 2-1 Types of Scenarios and Their Relation to DSEEP Activities 2-2 Table 2-2 Example of Scenario Variants 2-10 Table 3-1 Example Information Set for Describing Units and Objects 3-3 Table 4-1 Maturity Levels of Scenario Specification 4-1 Table 4-2 Relation of Maturity Levels to the Different Types of Scenarios 4-4 Table 5-1 Standards and Tools for Scenario Specification 5-1 Table A-1 Usability of NAF Operational View Templates for the Description of Scenarios A-3 Table A-2 Usability of NAF System View Templates for the Description of Scenarios A-5 Table A-3 NSV-5 Operational Activities to System Function Traceability Matrix for A-5 Scenario Example from Annex C viii STO-TR-MSG-086-Part-II .

List of Acronyms BOM Base Object Model CAS Close Air Support CAX Computer-Assisted Exercise C-BML Coalition Battle Management Language CMMI Capability Maturity Model Integration DIF Data Interchange Format DIS Distributed Interactive Simulation DSEEP Distributed Simulation Engineering and Execution Process EU European Union FAC Forward Air Controller FEDEP Federation Development and Execution Process FOM Federation Object Model HLA High Level Architecture IEEE Institute of Electrical and Electronics Engineers IFF Identification Friend or Foe ISO International Organization for Standardization JEMM Joint Exercise Management Module JLVC Joint Live Virtual Constructive JTDS Joint Training Data Services LCIM Levels of Conceptual Interoperability Model ManPAD Man Portable Air Defence MEL Main Events List MIL Main Incidents List M&S Modelling and Simulation MSDL Military Scenario Definition Language MSG Modelling and Simulation Group NAF NATO Architecture Framework NATO North Atlantic Treaty Organization PMESII Political. Social. Military. Information. Infrastructure OBS Order of Battle Service OMT Object Model Template SISO Simulation Interoperability Standards Organization SME Subject-Matter Expert UML Unified Modelling Language V&V Verification and Validation STO-TR-MSG-086-Part-II ix . Economic.

siegfried@aditerna.at DEU Michael BERTSCHIK WTD 91 / GF 510 NO Am Schießplatz 49176 Meppen GERMANY Phone: +49 5931 43 1590 Email: MichaelBertschik@bundeswehr.de x STO-TR-MSG-086-Part-II .de DEU Martin ROTHER IABG mbH YES Einsteinstrasse 20 85521 Ottobrunn GERMANY Phone: +49 89 6088 3974 Email: rother@iabg.de DEU Robert SIEGFRIED aditerna GmbH YES Co-Chair Otto-Hahn-Str.ac.neugebauer@kabelmail. MSG-086 Membership List Nation Full Name Contact Information Appointed by Nation AUS Johannes LÜTHI FH Kufstein Tirol Bildungs GmbH NO Andreas Hofer-Strasse 7 6330 Kufstein AUSTRIA Phone: +43 5372 71819 303 Email: Johannes. 26 56073 Koblenz GERMANY Phone: +49 261 94729-71 Email: dieter-steinkamp@gmx. 13 B 85521 Riemerling GERMANY Phone: +49 89 608 755 825 Email: robert.org DEU Matthias HAHN Planungsamt der Bundeswehr YES Chair Oberspreestrasse 61L 12439 Berlin GERMANY Phone: +49 30 6794 .org DEU Eckehard NEUGEBAUER IABG mbH YES Postfach 1764/Schiessplatz 49707 Meppen GERMANY Phone: +49 59 327 343 42 Email: eckehard.Luethi@fh-kufstein.de DEU Dieter STEINKAMP IABG mbH NO Ferdinand-Sauerbruch-Str.1977 Email: matthias3hahn@bundeswehr.

com GBR Neil MORRIS Dstl Portsdown West YES PCS/AES Portsdown Hill Road Fareham.gov. Hampshire PO17 6AD UNITED KINGDOM Phone: +44 02392 532 936 Email: nmorris@dstl.gerretsen@nlr.org GBR Steve FRANK MBDA UK Ltd YES 5200 Building Six Hills Way Stevenage. Nation Full Name Contact Information Appointed by Nation DEU Stefan VRIELER WTD 91 / GF 510 YES Am Schießplatz 49176 Meppen GERMANY Phone: +49 5931 43 2226 Email: StefanVrieler@bundeswehr.O.nl STO-TR-MSG-086-Part-II xi . Box 90502 Anthony Fokkerweg 2 1059 CM Amsterdam NETHERLANDS Phone: +31 88 511 3155 Email: keuning@nlr. Herts SG1 2DA UNITED KINGDOM Phone: +44 1438 754 271 Email: steve.O. Box 90502 Anthony Fokkerweg 2 1059 CM Amsterdam NETHERLANDS Phone: +31 88 511 3231 Email: arno.nl NLD Michel KEUNING National Aerospace Laboratory NLR YES Training.fontana@selex-es. Simulation and Operator Performance Dept P.frank@mbda-systems. Simulation and Operator Performance Dept P.uk ITA Valeria FONTANA SELEX ES SpA YES Via Tiburtina 1231 00131 Rome ITALY Phone: +39 6 4150 5731 Email: valeria.com NLD Arno GERRETSEN National Aerospace Laboratory NLR YES Training.

Banérgatan 62 SE-115 88 Stockholm SWEDEN Phone: +46 878 255 34 Email: fredrik.se TUR Mahmut Nedim ALPDEMIR TÜBITAK BILGEM ILTAREN YES Sehit Yzb Ilhan. Ankara TURKEY Phone: +90 312 291 6084 Email: nedim. 2489 Sok Umitkoy 06800.gov.alpdemir@tubitak.tsk. Nation Full Name Contact Information Appointed by Nation ROU Catalin CIUL Military Equipment and Technologies YES Research Agency Aeroportului Street.tr TUR Kurtulus BEKTAS Turkish Navy YES Denis K. K. No 16 CP 19 OP BRAGADIRU 077025 Ilfov ROMANIA Phone: +40 21 423 30 58 Email: cciul@acttm.se SWE Björn LÖFSTRAND Pitch Technologies AB YES Repslagaregatan 25 58222 Linköping SWEDEN Phone: +46 13 470 5500 Email: bjorn. TAN Kislasi.ro SWE Fredrik JONSSON Swedish Defense Materiel Administration YES FMV.tr xii STO-TR-MSG-086-Part-II .lofstrand@pitch.karlsson@pitch.ligi APGE ve BILKARDES Bsk.olsson@pitch.se SWE Peter KARLSSON Pitch Technologies AB YES Repslagaregatan 254 SE-58222 Linköping SWEDEN Phone: +46 13 470 5517 Email: peter.k5781@dzkk.ligi 06650 Bakanliklar/Ankara TURKEY Phone: +90 312 403 3649 Email: bektas. Umit Mah 2432 Cad.se SWE Lennart OLSSON Pitch Technologies AB YES Repslagaregatan 25 58222 Linköping SWEDEN Phone: +46 13 470 5500 Email: lennart.jonsson@smart-lab.

Nation Full Name Contact Information Appointed by Nation TUR Mesut GUNEY Turkish General Staff YES Genelkurmay BILKARDEM Bsk. 2489 Sok.tr TUR Ahmet KARA TÜBITAK BILGEM ILTAREN NO Ümit Mah.tr TUR Halit OGUZTÜZÜN Middle East Technical University YES Department of Computer Engineering Inonu Bulvari 06531 Ankara TURKEY Phone: +90 312 210 5587 Email: oguztuzun@metu. Ümitköy 06800 Ankara TURKEY Phone: +90 312 291 6061 Email: ahmet.gov. 2432.kara@tubitak.edu. Cad.tr STO-TR-MSG-086-Part-II xiii .ligi 06650 Bakanliklar. Ankara TURKEY Phone: +90 312 402 3842 Email: mguney@tsk.

xiv STO-TR-MSG-086-Part-II .

but that simulation interoperability needs to be addressed in a holistic way along the whole simulation environment engineering process.e.. MSG-086 delivers the following secondary outcomes and deliverables: • Recommendations for updating AMSP-01 [AMSP-01] with respect to simulation interoperability and scenario development. on the pragmatic.. STO-TR-MSG-086-Part-II ES . ET-027 identified 63 issues which severely limit simulation interoperability. MSG-086 “Simulation Interoperability” was initiated in 2010 and tasked to analyse the ET-027 interoperability issues. integration. and semantic issues). Based on the identified interoperability issues and their impact on the simulation environment engineering process. Guideline on Scenario Development for (Distributed) Simulation Environments (STO-TR-MSG-086-Part-II) Executive Summary As simulation interoperability was the highest priority capability gap of the NMSG MORS M&S Gap Analysis Questionnaire an Exploratory Team (ET-027) of the NMSG was formed in 2009 to investigate simulation interoperability. the syntactic and (to a limited extent) on the semantic interoperability level. the syntactic. This guideline augments the DSEEP with regards to scenario development and proposes content and structure of an information product for scenario specification. especially with regards to scenario development.. All issues are documented according to the same schema and relations to relevant M&S standards are identified. and SCM). Achieving simulation interoperability requires efforts and standardization on the technical. MSG-086 focused its further efforts on the issue group “Scenario”.g. syntactic. In total.e. 46 interoperability issues are identified and described by MSG-086 and categorized into 9 interoperability issue groups. on technical. MSG-086 developed a “Guideline on Scenario Development for (Distributed) Simulation Environments”. To improve simulation interoperability in context of the DSEEP. Present standards for distributed simulation environments mostly focus on the technical. dynamic.1 . To meet future demands – especially in terms of quality and reduced time and costs – simulation interoperability at higher levels (i. the semantic. A major finding of MSG-086 (besides the detailed documentation of simulation interoperability issues) is that simulation interoperability is not primarily a technical issue.g. DSEEP. the DSEEP. following e. Such standardized information products must address higher levels of interoperability than present simulation interoperability standards which focus on lower interoperability levels (i. FEAT.. This requires standardization of information products created in the process of developing a simulation environment. and execution of distributed simulation environments. Based on the findings of ET-027. • Recommendations for SISO working groups (e. and conceptual interoperability level) is required as well as substantial automation of development. Additionally. • A proposal for updating the NMSG Military Operational Requirements Sub-group (MORS) M&S Gap Analysis Questionnaire. This analysis should be used to recommend and prototype information products augmenting the Distributed Simulation Engineering and Execution Process (DSEEP) [DSEEP] to mitigate or obviate identified interoperability issues.

and the pragmatic level. Regarding cooperative action with SISO the recommendation is to transform the “Guideline on Scenario Development for (Distributed) Simulation Environments” into an official SISO standard. commonly referred to as “M&S as a Service”. It is recommended to continue initial work done by MSG-131 (“Modelling and Simulation as a Service: New Concepts and Service-Oriented Architectures”) and to investigate the potential of M&S as a Service by a dedicated Task Group. One of the most promising approaches towards improving simulation interoperability is a service-oriented approach. MSG-086 worked out proposals for future activities within the NMSG and for cooperative actions with SISO.2 STO-TR-MSG-086-Part-II . Based on these conclusions. ES . Focusing only on standards for distributed systems or reuse of components will not lead to simulation interoperability on higher levels.

L’ET-027 a identifié 63 problèmes qui limitent fortement l’interopérabilité de la simulation. dynamique et conceptuel) de même que l’automatisation relative du développement. Tous les problèmes sont documentés selon le même schéma ainsi que leur lien avec les normes de M&S associées. qui se concentrent sur des niveaux inférieurs (autrement dit. notamment en termes de qualité et de réduction des délais et des coûts. à la suite. syntaxique et (dans une certaine mesure) sémantique de l’interopérabilité. Le MSG-086 « Interopérabilité de la simulation » a été créé en 2010 sur la base des conclusions de l’ET-027 . une équipe exploratoire (ET-027) a été constituée au sein du NMSG pour étudier l’interopérabilité de la simulation. Guide en vue du développement de scénario dans le cadre de simulation distribuée (STO-TR-MSG-086-Part-II) Synthèse Puisque le questionnaire d’analyse des lacunes de M&S du MORS du NMSG a déterminé que le manque d’interopérabilité de la simulation constituait la lacune prioritaire à combler en matière de capacité. Cette analyse devait servir à recommander et créer des prototypes d’applicatifs qui améliorent les processus de création et réalisation de simulation distribuée (DSEEP. le MSG-086 identifie et décrit 46 problèmes d’interopérabilité et les classe en neuf groupes. Distributed Simulation Engineering and Execution Process) [DSEEP] afin d’atténuer ou éviter les problèmes d’interopérabilité identifiés. du DSEEP. En outre. FEAT et SCM). STO-TR-MSG-086-Part-II ES . Pour répondre aux besoins futurs. le MSG-086 a concentré ses efforts sur la problématique liée au « scénario ». Ces produits normalisés doivent répondre à des niveaux d’interopérabilité supérieurs aux normes actuelles d’interopérabilité de la simulation. de l’intégration et de la mise en œuvre des environnements de simulation distribuée. aux niveaux pratique. Afin d’améliorer l’interopérabilité de la simulation dans le contexte du DSEEP. les questions techniques. le MSG-086 délivre les résultats secondaires et documents suivants : • Recommandations de mise à jour de l’AMSP-01 [AMSP-01] relativement à l’interopérabilité de la simulation et au développement des scénarios. • Recommandations aux groupes de travail de la SISO (par exemple. par exemple. • Proposition de mise à jour du questionnaire d’analyse des lacunes du Sous-groupe des besoins opérationnels militaires (MORS) du NMSG. Au total.3 . Les normes actuelles relatives aux environnements de simulation distribuée se concentrent principalement sur les niveaux technique. DSEEP. Cela exige une normalisation des applicatifs créés pendant le développement d’un environnement de simulation. l’interopérabilité de la simulation doit avoir lieu à des niveaux plus élevés (autrement dit. en particulier au sujet du développement des scénarios. Ce guide augmente le DSEEP relativement à l’élaboration des scénarios et propose un contenu et une structure d’applicatif pour la spécification des scénarios. syntaxiques et sémantiques). le MSG-086 a rédigé un « Guide au développement des scénarios dans les environnements de simulation (distribuée) ». sa mission est d’analyser les problèmes d’interopérabilité mis au jour par l’ET-027. En partant des problèmes d’interopérabilité identifiés et de leur impact sur le processus d’ingénierie de l’environnement de simulation.

ES . L’une des approches les plus prometteuses pour améliorer l’interopérabilité de la simulation est une approche axée sur le service fourni. de nouveaux concepts et de nouvelles architectures axées sur le service ») et de confier à un groupe de travail spécial l’étude du potentiel de la M&S en tant que service. il est recommandé de transformer le « Guide au développement des scénarios dans les environnements de simulation (distribués) » en une norme officielle de la SISO. sémantique et pragmatique. le MSG-086 propose des activités futures au sein du NMSG et des actions en coopération avec la SISO. L’interopérabilité de la simulation exige du travail et une normalisation aux niveaux technique.L’une des grandes conclusions du MSG-086 (en plus de la documentation détaillée sur les problèmes d’interopérabilité de la simulation) est que l’interopérabilité de la simulation n’est pas fondamentalement une question technique. mais qu’elle doit être abordée de manière holistique tout au long du processus d’ingénierie de l’environnement de simulation. Il ne suffit pas de se focaliser sur les normes des systèmes distribués ou sur la réutilisation de composants pour améliorer l’interopérabilité de la simulation.4 STO-TR-MSG-086-Part-II . couramment appelée « M&S en tant que service ». Il est recommandé de poursuivre le travail initial accompli par le MSG-131 (« Modélisation et simulation en tant que service. A partir de ces conclusions. syntaxique. En ce qui concerne les actions en coopération avec la SISO.

As such.. Chapter 1 – INTRODUCTION 1.g. Therefore. This guideline is based on the Distributed Simulation Engineering and Execution Process (DSEEP) [DSEEP] and augments the DSEEP with additional information specific to scenario development.. Although similar in nature. 1. In other words. This guideline gives an overview of existing standards and tools that may be used for scenario development. STO-TR-MSG-086-Part-II 1-1 . many considerations laid out in this guideline are also applicable to these application domains. well-specified scenarios are of utmost importance. Nevertheless. Therefore. Consistency refers to the internal correctness of a scenario specification (e. no unit belongs to more than one party. scenarios defined by the user of a simulation environment are paramount sources of requirements for the engineers faced with planning and setting up a simulation environment. the conceptual model (and the subsequently developed simulation environment) may not reflect what the user originally wanted. this guideline does not explicitly address scenarios used in live exercises or Computer-Assisted eXercises (CAX). Completeness means that a scenario specification has to contain sufficient information to enable persons in the subsequent process (especially during development of the conceptual model) to use the scenario in a meaningful way and to extract all information required for their activities. 1.g. and • Understandable. training. Ideally. this may lead to various problems due to misunderstandings when talking about the objectives and scope of a simulation environment. missing or incompletely specified scenarios will lead to simulation results that do not reflect what the user was expecting.2 PURPOSE The purpose of this guideline is to provide detailed information regarding the development of scenarios for (distributed) simulation environments and the relationship of the scenario development process with the overarching simulation environment engineering process. However. due to missing experiences and large differences between simulation environments this guideline does not recommend specific standards. If such scenarios are missing. about the initial situation and about pre-planned courses of action and major events happening during the simulation execution.1 MOTIVATION Regardless of the application domain – e. initial positions of all units are within the specified geographic area).3 SCOPE The primary scope of this guideline is the development of scenarios in context of (distributed) simulation environments. the simulation environment does not fulfil the original requirements or does not answer the questions originally posed. • Consistent. As a result. involved entities. a scenario specification should be: • Complete. Understandability requires that a scenario specification has to be written and structured in a way that it is easily accessible by future users. Typically a scenario specification contains information about the geographic location. analysis or decision support – scenarios are used to specify situations and conditions to be represented in a simulation environment for the intended purpose of a simulation application.

.4 INTENDED AUDIENCE The intended audience of this guideline includes (but is not limited to): • Primarily. using MSDL). • Users and subject-matter experts which define and specify requirements for a simulation environment. project managers and simulation engineers which need to set up a simulation environment. • Chapter 5 provides an overview of currently available standards and tools for scenario specification. • Chapter 4 discusses maturity levels for scenario specifications and highlights the importance of formal scenario specifications (e. Based on both practical experiences as well as literature research.g. Afterwards. This guideline is not restricted to a specific application domain (e. and • Operator personnel that operates simulation systems and other member applications of a simulation environment. • Chapter 3 presents necessary scenario documentation. Chapter 2 defines the term “scenario” and provides related terminology.5 DOCUMENT OUTLINE • As many problems arise out of different interpretations of the term “scenario”.INTRODUCTION 1. a set of documentation items for specifying scenarios is presented. military scenarios)... • Annex C and D present two example scenario specifications. but may be applied in various different application domains (e.g. Features currently missing in available standards are identified. crisis management scenarios). different types of scenarios within different steps of the DSEEP are identified and described in detail. 1.g. • Annex A and B describe how the NATO Architecture Framework and Base Object Models are related to scenario specifications. 1-2 STO-TR-MSG-086-Part-II .

CAX).” [MSG-053. 13] 2) Use of the term “scenario” in context with later steps of the development and execution process of simulation environments (“Develop Simulation Environment” (Step 4 of the DSEEP) and “Plan. even if there is agreement about the above definition: 1) Use of the term “scenario” in context with the first steps of the development and execution process of simulation environments (“Define Simulation Environment Objectives” (Step 1 of the DSEEP) and “Perform Conceptual Analysis” (Step 2 of the DSEEP).g. An exhaustive overview of definitions for the term “scenario” is given in [MSG-053] and [12S-SIW-014].” [DSEEP. Activity 2.. each consisting of one or more temporally ordered sets of events and behaviours (i.” [DSEEP. the term “scenario” is used in an ambiguous way. p. the scenario may actually include multiple scenarios. in particular with Step 2. and events during a specified time frame related to events of interest. As shown in Figure 2-1 three types of scenarios are distinguished: • Operational scenarios. the following sections describe the scenario development process and the three different types of scenarios that are developed during this process. as experience shows again and again. the scenario specification is continuously refined and augmented with additional information. the actual data stores are used to transition the functional description of the scenario (developed in Step 2.2 (“Establish Simulation Environment Agreements”) of the DSEEP): “Once all authoritative data sources that will be used in support of the simulation environment have been identified. Unfortunately. environment.. Chapter 2 – SCENARIOS IN DISTRIBUTED SIMULATION ENVIRONMENTS 2. pp. In order to establish a clear understanding of scenarios and their role within distributed simulation environments. see Figure 4) to an executable scenario instance (or set of instances). p. STO-TR-MSG-086-Part-II 2-1 . 2-3] This definition was proposed by the NATO Modelling and Simulation Group MSG-053 “Rapid Scenario Generation for Simulation Applications” and a similar definition can be found in [NATO_COBP]. Activity 4. in particular with Step 4. As the term “scenario” may have a different meaning in another context (e.e.1 DEFINITION “SCENARIO” The term “scenario” has many definitions. it is stressed that this document is primarily concerned with scenarios in the context of (distributed) simulation environments.1 (“Develop Scenario”) of the DSEEP): “The purpose of this activity is to develop a functional specification of the scenario. objectives.2 SCENARIO DEVELOPMENT PROCESS During the planning and design process of a simulation environment. 2. Integrate and Test Simulation Environment” (Step 5 of the DSEEP). Depending on the needs of the simulation environment. The definition recommended by this guideline in context with the development and execution of simulation environments is the following: “A scenario is a description of the hypothetical or real area. a three-step scenario development process is proposed. means. 26] To clarify the scenario terminology. vignettes).

.

.

economic. In this case. As operational scenarios are authoritative sources of requirements for the subsequent development of the simulation environment they provide: • A description of a real or fictitious piece of the world of interest.e. • In defence analysis/planning. i. personnel. • PMESII (political. • The required capabilities to enable these tasks. objectives of the scenario. associated sustainment]) that must be represented within the simulation environment. road to war/operations. specifying the application domain forces the user to answer the question “For which purpose is a simulation environment supposed to be used?” Based on the specification of the application domain. • The required tasks to accomplish these effects. equipment. including the initial state and desired end state. For multi-level simulation environments a consistent hierarchy of operational scenarios is mandatory. suitable operational scenarios have to be selected (if available) or developed. Often a combination of a graphical and a textual description is chosen. tactical). • The effects considered to be necessary for a transition from the initial state to the desired end state. Ideally – to capture all aspects of relevance – the descriptions of such operational scenarios should follow an operational planning process or scenario development process as described in [NMSG-024]. For each selected or developed operational scenario it has to be described how it is related to the application domain and how it supports the original objectives and needs of this application domain. the user often specifies an operational scenario before defining all objectives and questions. infrastructure. Each scenario description could (depending on the application domain) embrace all or parts of the following information: • Reason for the creation and use of the scenario. • Historical context. and • The required force packages to assure these capabilities. operational. information). Operational scenarios are described in terms the user is familiar with and may be documented in any format... relation to the application domain. humanitarian. military. based on a given operation scenario the application domain and the questions to be answered are specified. these questions may then be used to refine the operational scenarios. political. • In context with a peace support operation (Non-Article 5). [NATO_COPD]. social [cultural. Thus. • Relation to higher and/or lower level scenarios (hierarchy of scenarios!). The alignment process may be iterative. logistics.SCENARIOS IN DISTRIBUTED SIMULATION ENVIRONMENTS A single instance of the simulation application space is denoted as “Application domain”. In practice. resources [facilities. An example for an instance of the application space (thus for an application domain) could be: • For training. it is important that the application domain is aligned with the given operational scenarios. strategic. legal]. 2-4 STO-TR-MSG-086-Part-II . It has to be kept in mind that descriptions of operational scenarios differ depending on the level of the scenario (e.g. • On the operational level. • Types and numbers of major entities (units. and • For the CJ4 (Logistics).

• Constraints (doctrines. atmosphere/weather. game plan (plans. TOEL (Time-Ordered Event List [-> events can change the environment dynamically]). For development of a conceptual model as fundamental pre-condition for the development of a simulation environment the operational scenarios need to be refined and augmented with additional information. associated behaviours).) that impact or are impacted by entities in the simulation environment. • They are described by SMEs using domain-specific terminology and guidelines. The resulting “conceptual scenarios” provide a detailed specification of the piece of the world to be simulated and should provide all necessary information for persons which are involved in later steps of the simulation environment engineering process.1 (“Develop Scenario”) which will most often be carried out by M&S experts (lead) which are assisted by the user and further subject-matter experts. forms the cornerstones for the derivation of the requirements for the development of the conceptual model for a simulation environment. • Missions (initial state and desired end state). geographical locations of objects of interest). Thus. The problem space defines which (or which parts) of the operational scenarios (possibly simplified. space. but usually do not contain enough information for deriving a conceptual model and designing a simulation environment. As far as possible these information should be based on authoritative sources and documents. • Sequence of actions or occurrences relevant to the objectives. and relationships between these major entities over time. operations. and • Specific geographic regions (areas of operations. ocean. While the operational scenarios are defined by the user. or extended) have to be represented in the simulation environment.2. together with additional requirements derived from the objectives and needs of the intended application domain.2 Conceptual Scenario The operational scenarios provide a coarse description of the intended situation and its dynamics. type of terrain. • They are related to a certain application domain (= instance of the application space). areas of interest. The problem space. orders. rules of engagement.1). thus for the development of the conceptual model of a simulation environment (DSEEP Activity 2. A sub-step between the “Operational Scenarios” and the “Simulation Environment Requirements” is the “Problem Space” (see Figure 2-2). etc. behaviour. 2. • A specification of relevant environmental conditions (terrain [urban terrain versus natural area. the problem space is defined by M&S experts (in collaboration and interaction with SMEs). SCENARIOS IN DISTRIBUTED SIMULATION ENVIRONMENTS • A description of the characteristics. MEL/MIL (Main Event List / Main Incident List). positions for physical objects]. control measures). orders. operational scenarios are characterized by the following aspects: • They answer the question “What has to be represented in a simulation environment?”. STO-TR-MSG-086-Part-II 2-5 . and • They are a basic pre-requisite and authoritative source for the definition of the problem space. capabilities. adapted. • Playbook. tasks. day/night. climate. and associated effects of these entities over time. This is the focus of DSEEP Activity 2. • They are human readable.

Also the use of specialized tools or methodologies for scenario specification should be considered.2. the conceptual model may define entity classes and their attributes (much like classes are defined in any object-oriented programming language). 2. 2-6 STO-TR-MSG-086-Part-II . It is important to note that other “views” (e. Yet.1 “Develop Scenario”. This may be supported by enforcing a more precise use of simulation-related terms. the conceptual scenarios are derived (as abstractions of the underlying operational scenarios). Based on the operational scenarios (or the “mission space”).1 Relation of Conceptual Scenario and Operational Scenario The totality of operational scenarios to be represented in a simulation environment determines what is also known as the “mission space”. This activity is intimately connected to Activity 2.2. ammunition in rounds Following an object-oriented view. For this purpose.2 “Develop Conceptual Model”. as the development of the conceptual scenarios is led and coordinated by M&S experts this transfer of responsibility is also reflected in the scenario specification. The object-oriented view is chosen here only as an example. The conceptual model describes the entities and their static and dynamic relationships. Mojtahed2008]. for example: Entity class “Helicopter H-1” Attributes: remainingFuel in litres. ontology-related approaches [Mojtahed2005. 2. Like the operational scenarios also the conceptual scenarios are specified in terms the user is familiar with.. The conceptual scenarios provide a specification of that piece of the real world which is reflected by the mission space (respectively the operational scenarios).2 Relation of Conceptual Scenario and Conceptual Model The DSEEP treats the development of conceptual scenarios in Activity 2. and as described by the DSEEP the conceptual scenario and the conceptual model may be developed in parallel. a tight integration of the original user and subject-matter experts is usually necessary. This helps to reduce misunderstandings and ensures that the right conceptual scenarios are derived from the given operational scenarios.2. Especially.SCENARIOS IN DISTRIBUTED SIMULATION ENVIRONMENTS Although the conceptual scenarios are primarily developed by M&S experts. architecture approaches using NAF) exist and may be more appropriate for specifying certain conceptual models. conceptual scenarios may reference and instantiate these entity classes (see Figure 2-3).2.g. the M&S experts should aim for a more structured specification of conceptual scenarios and should ensure that all information required for setting up a simulation environment is specified.

.

.

.

p.10 STO-TR-MSG-086-Part-II .2 Scenario Variants For purposes of experimental design a scenario is often analysed and executed in different variants. ideally self-contained parts of a scenario. This leaves much space for interpretation and. We propose the following definition in this context: A scenario variant is a scenario which is derived from another scenario by variation of isolated parameters for purposes of experimental design (e.3 AUXILIARY TERMS 2.g. vignettes may be thought of as small. from experience.3. More or less. Scenario variants may be specified for all three types of scenarios. Currently many definitions exist of which most definitions are to some degree circular [EU CTF. which are actions or situations that provide greater clarity to an event [Cayirci2010].] [DoD M&S Glossary.. 158]. As described in the EU Core Technical Framework study [EU CTF. 2. p. events are major occurrences or a sequence of related incidents.SCENARIOS IN DISTRIBUTED SIMULATION ENVIRONMENTS 2.]. In this terminology. missing clarity and understandability is a key factor for missing user adoption.3. 89] [DSEEP.3. 103ff. a practical drawback of these definitions is that they do not distinguish clearly between a scenario and a vignette. Within this guideline a vignette is defined as follows: A vignette is a reusable temporally ordered set of events and behaviours for a specific set of entities. Table 2-2: Example of Scenario Variants.3 MEL/MIL A further term commonly used in context of executable scenarios used for training and exercise purposes is “Main Events List” or “Main Incidents List” (MEL/MIL). Table 2-2 illustrates an example for usage of scenario variants during the scenario development process. although they are most common in context of executable scenarios. different units but otherwise no changes). the term “vignette” is regularly used. vignettes are considered to be small scenarios or to be smaller than a regular scenario. p. p. Conceptual Scenario Executable Scenarios “Air Defence” Unit Base Variant Variant 1: Low Variant 2: High “Enemy Helicopter” Altitude Approach Altitude Approach Attribute Height = 500 Height = 50 Height = 2300 “Height : Metres” Attribute Remaining Fuel = 1000 Remaining Fuel = 1000 Remaining Fuel = 1000 “Remaining Fuel : Litres” Attribute Ammunition = 200 Ammunition = 200 Ammunition = 200 “Ammunition : Rounds” 2. Furthermore. 13f.1 Vignettes In order to structure scenario specifications and to allow more flexible reuse of dedicated parts of a scenario. The only publicly available definition is the following: 2 .

p. facsimile. STO-TR-MSG-086-Part-II 2 . tasks. 121] Such event lists define courses of action within a surrounding situation.e.11 . SCENARIOS IN DISTRIBUTED SIMULATION ENVIRONMENTS “Master scenario events list: A chronological list that supplements the exercise scenario with event synopses. capabilities. Therefore. radio call. It also records the methods that will be used to provide the injects (i. e-mail). and procedures that require testing during the exercise. expected participant responses. and responsible personnel. they may be used similarly as vignettes to specify dedicated parts of a scenario in a reusable way.> phone call.. policies.” [DoD M&S Glossary. as identified in the capabilities-based planning process. and objectives to be addressed. It includes specific scenario events (or injects) that prompt players to implement the plans.

SCENARIOS IN DISTRIBUTED SIMULATION ENVIRONMENTS 2 .12 STO-TR-MSG-086-Part-II .

.

Therefore. specific scenarios may require more or other information items. and 6) Rules of engagement. In turn.1 Objects and Units Enumeration and description of all objects and units of this scenario. During the process of transforming operational scenarios into conceptual scenarios. The mentioned set of information items for describing the initial state of a scenario is suitable for a wide range of (military) scenarios. attributes and capabilities.2 INITIAL STATE The initial state of a scenario defines the situation at the beginning of the scenario timeline. It is necessary here to see the issue in connection with the requirements and justify the participation of the units and objects. the question should also be answered: What would be the consequence if a specific unit or object was not part of the scenario? Every unit and object should be described by a common pattern (see Table 3-1 for an example).CONTENT OF A SCENARIO scenarios may contain other or much more information than proposed in the following sections. 2) Forces and force structure. Therefore. the JC3IEDM may be taken as a starting point for deriving such a common documentation pattern. 3-2 STO-TR-MSG-086-Part-II . It is. The JC3IEDM [JC3IEDM] describes in great detail which information is necessary (at least from an operational point of view) to describe an object. Yet. it is a major task of the M&S experts to structure the existing operational scenario description. the initial state typically contains information regarding the following aspects: 1) Objects and units. 4) Date/time. 3. and to strip off too detailed information. All information items are described in more detail in the following sub-sections. Especially the presented set of information items is suited for scenarios which are directly involving forces and units. the following proposed content items for a scenario description may also serve well for describing operational scenarios. It is particularly important to describe for each unit and each object why its participation in the scenario is necessary. 5) Surrounding conditions. a unit. The purpose of this information item is to describe which units and objects take part in the scenario. 3) Geography. to add missing information. for example. less suited for describing scenarios in context of cyberwar.2. Nevertheless. 3. their states.

CONTENT OF A SCENARIO

Table 3-1: Example Information Set for Describing Units and Objects.

Information Description
Identifier Every unit and object should have an unambiguous identifier.
Description The unit or object has to be described. If possible (or necessary) suitable sources or
references should be given.
Number The numbers in which the units and objects are present in the scenarios have to be
determined.
Capabilities All capabilities of the units and objects that are relevant for the scenario have to be
described. It has to be justified with a view to the objectives of the simulation
environment and the target values and requirements why a specific capability is
important.
Behaviour In what way(s) do the units act? Do alternative behaviours exist?
States Which states (e.g., mobile, partly mobile, degree of damage) have to be distinguished
concerning the units and objects?
Attributes For each object and unit all attributes have to be identified that are required in context
of the current scenario. If possible, valid value ranges for all attributes should be
specified.

An important remark is that all relevant units and objects of a scenario have to be described. In turn,
a scenario must not contain units or objects that are not described here.

3.2.2 Forces and Force Structure
Definition of forces and force structures, as well as definition of relationships of objects and assignment of
units to forces. Also, command and control hierarchies may need to be specified.

This information is also known as Order of Battle (ORBAT):
“The identification, strength, command structure, and disposition of the personnel, units, and
equipment of any military force.” [AAP-06]

3.2.3 Geography
The purpose of this information item is to describe the geographic requirements for a scenario:
1) Area of Interest: Specification of the area of interest of this scenario (e.g., as rectangular bounding
box);
2) Special Requirements: Requirements regarding buildings (e.g., real buildings or geotypical
buildings), vegetation, roads, ditches; and
3) Environmental Conditions: Specification of all environmental conditions which are of interest
within this scenario (e.g., day/night/dawn, rain/fog/snow/dust).

Again, the question has to be answered: Why are certain requirements necessary? All requirements must be
derived from the objectives of the simulation environment.

STO-TR-MSG-086-Part-II 3-3

CONTENT OF A SCENARIO

3.2.4 Date/Time
Specification of date and time of the beginning of the scenario.

3.2.5 Surrounding Conditions
The surrounding conditions provide an overview of all scenario-related information and are described
according to the PMESII approach:
1) Political situation;
2) Military situation;
3) Economic situation;
4) Social situation / Cultural aspects;
5) Information; and
6) Infrastructure.

This information item is especially important if real operators are integrated into the simulation environment
(operating either virtual or live systems). Unless the behaviour of the real operators is completely determined
a priori, the surrounding conditions may affect the actions of a real operator (e.g., whether a crowd is
considered to be harmful or not, how to respond to enemy behaviour).

Especially if real operators are involved, it is important to stress that executable scenarios are not only
specific files for initializing constructive simulations but may also be explanations, MEL/MIL, or story
boards to “initialize” humans (e.g., personnel operating virtual systems).

3.2.6 Rules of Engagement
A clear definition of rules of engagement is necessary to ensure the correct (i.e., intended) behaviour of all
participating personnel operating live and virtual systems as well as participating constructive systems.

3.3 COURSE OF EVENTS
Besides a specification of the initial state a typical scenario specification includes pre-planned events
happening at a specific time. Such events are usually triggering some kind of reaction, either of a
participating simulation system or a trainee within the simulation environment.

We propose to distinguish the following types of events:
1) Communication events;
2) Interaction events;
3) State change events; and
4) Environmental events.

Each event (whether triggered at a pre-planned point in time relative to the starting time of the scenario
or triggered by some condition) injects a specific influence into the scenario. Typically, events
(e.g., communication events like orders or interaction events like direct fire) are used to generate a specific
situation onto which the participating member applications (live, virtual or constructive) have to react in a
certain way. Intended reactions of the systems may be very different and depend heavily on the purpose
of the simulation environment.

3-4 STO-TR-MSG-086-Part-II

CONTENT OF A SCENARIO

In general, the course of events of a scenario is defined by a set of events and corresponds to the Main
Events List (MEL) used for training and exercise purposes.

The following sub-sections describe the four event types in more detail.

3.3.1 Communication Events
Communication events include all type of scenario-related communication (e.g., reconnaissance reports,
orders). The sender of a communication may either be a participant of the simulation environment itself
(e.g., another simulation system) or communication may be injected by exercise control (e.g., provision of
fictitious news reports to operator personnel of a virtual or live system).

3.3.2 Interaction Events
Interaction events define explicitly interactions regarding objects and units of the scenario (e.g., one unit
attacking another one or explosion of an improvised explosive device).

3.3.3 State Change Events
State change events are similar to interaction events but concern only a single object or unit (e.g., collapse of
a bridge or breakdown of an armoured vehicle due to some technical malfunction).

3.3.4 Environmental Events
Sub-types of state change events are environmental events which specify state changes within the
environment (e.g., beginning of rain).

3.4 TERMINATION CONDITIONS
Within (distributed) simulation environments conditions should be defined for each scenario determining the
achievement of a final state and thus leading to a termination of the simulation run. Although FEDEP and
DSEEP do not include termination conditions within their respective scenario definition, they mention
termination conditions as one result of Activity 2.1 (“Develop Scenario”) [FEDEP, p. 10] [DSEEP, p. 14].

Two typical termination conditions for a scenario can be distinguished:
1) A specific condition is achieved (e.g., destruction of all enemy units); and
2) A pre-defined time is elapsed (e.g., two hours of simulation time).

Explicitly defining termination conditions is especially important for simulation environments which are
executed in a fully automated fashion. Typical examples for this are constructive simulation systems used
within data farming setups.

3.5 REUSE IN THE SCENARIO DEVELOPMENT PROCESS
As mentioned, operational scenarios are specified by the user. Therefore, the way to define and describe
operational scenarios is usually dominated by domain-specific regulations (e.g., operational planning
processes in the military domain). To avoid interference with these planning processes, considerations
regarding reuse in the scenario development process are focussed on conceptual scenarios and executable
scenarios. Nevertheless, operational scenarios may also be subject to reuse and specific operational scenarios
should be derived from authoritative sources (e.g., major scenarios defined in defence policies).

STO-TR-MSG-086-Part-II 3-5

CONTENT OF A SCENARIO

Focusing on conceptual scenarios and executable scenarios, two general options for exploiting reuse in the
scenario development process may be distinguished:
1) Reuse of a scenario as a whole; and
2) Reuse of specific parts of a scenario.

The first option requires putting in place sufficient storage mechanisms as well as augmenting scenarios with
specific metadata (e.g., MSC-DMS [MSC-DMS]) for efficient retrieval. As the scenarios are reused as a
whole, this option does not place any specific requirements on the scenario development process and does
not impose any constraints on the scenario specification. All organizations involved in planning and
developing (distributed) simulation environments should aim for at least this level of scenario reuse. Within
this guideline, this option is not discussed any further.

Compared to the first option, the second option promises improved reuse possibilities and added flexibility.
At the same time, option two requires decomposing a scenario into smaller parts (building blocks) which
may then be assembled according to some rules to form a scenario. The remainder of this section is
concerned with exactly this option and will discuss how the different parts of a scenario (initial state, course
of events, termination conditions) may be split into components.

An obvious requirement for reuse of all kinds is that the applicability of existing components in a new
context has to be thoroughly evaluated each time. This is also true for scenario components and has always
to be kept in mind.

3.5.1 Components Regarding Initial State of a Scenario
Almost all parts of the initial state can be considered as components which may be reused separately in
multiple scenarios. This is especially true for lists of objects and units as well as for information about forces
and force structures. Similarly, the rules of engagement are a candidate for reuse as certain areas of operation
are often associated with the same rules of engagement. Depending on the level of detail PMESII-related
information (e.g., storybooks, country books) is also a candidate for reuse.

3.5.2 Components Regarding Course of Events of a Scenario
Although the term “vignette” is often not clearly distinguished from the term “scenario”, the basic idea
behind it is highly valuable. The basic idea is to decompose a scenario into smaller components and to
assemble new scenarios from existing components (cp. Section 2.3.1).

For the possibility to assemble new scenarios from existing building blocks (i.e., vignettes) and to achieve
maximum reuse it is necessary to specify vignettes independently of scenarios. Therefore, a vignette should
not contain specific geographic locations or similar information (cp. [EU CTF]).

For example, a simple vignette “air refuelling operation” might specify the rendezvous of a jet fighter and a
tanker aircraft in detail without referring to actual coordinates. Instead, the vignette would describe positions
relative to an imaginative starting point. Integrating this vignette into a specific scenario would only require
specification of the coordinates of the starting point. This integration of a vignette into a specific scenario is
done by introducing “vignette configurations” [EU CTF]:
A vignette configuration places a vignette or set of vignettes in a context of a specific scenario.

As vignettes describe a set of activities in a generic way they may roughly be associated with classes in
object-oriented programming languages. Assigning actual values by defining a vignette configuration may
then be associated with creating instances of a class (usually called an “object”).

3-6 STO-TR-MSG-086-Part-II

.

and 2) Camp Patrol Task: Possible parameters may be the units executing the patrol task and their initial positions. about the camp) and effectively prohibit reuse (e. Therefore. i. waypoint_list waypoints) // assume that unit u is at the camp’s main gate While (scenario is running) For each waypoint in waypoints do Move to waypoint endfor Endwhile The respective benefits of using parameters or hard-coding certain parts are the same as in programming languages. 3.5.g. Examples: 1) Air Refuelling Operation: Possible parameters may be the starting points of the tanker and the jet fighter to be refuelled. the use of parameters is highly encouraged..CONTENT OF A SCENARIO It follows immediately that certain verification activities are required to ensure that selected vignettes and the remainder of the scenario are compatible with each other..e. In general.3 Components Regarding Termination Conditions of a Scenario The reuse of termination conditions is not detailed any further as the potential benefit of reuse seems to be too small compared to the effort for specifying the termination conditions.g. they require detailed knowledge (e. Each parameter will be associated with an actual value during the process of integrating the vignette into a scenario. the parameters used in vignettes give scenario developers the same degree of freedom as in common programming languages when writing methods.. The following two snippets of pseudo code show an example of a camp patrol task. 3-8 STO-TR-MSG-086-Part-II . While hard-coded vignettes are quick and easy to create. vignettes might be specified in a way that “everything is parameterized” or vignettes may be defined in a way that “many to all aspects are hard- coded”. simple_campPatrolTask(unit u) // assume that unit u is at the camp’s main gate While (scenario is running) Move south 500 metres Move east 300 metres … Endwhile advanced_campPatrolTask(unit u. because the patrol task is intimately connected to a specific camp). This includes the scenario developers decision on the degree of parameter usage for specific vignettes. An important aspect is that vignettes should make use of parameters.

arbitrarily fuzzy and effectively prevents all types of scenario reuse.e. 4. Also. Table 4-1: Maturity Levels of Scenario Specification. specification 2 – Standardized scenario Documentation which is structured according to a standard or agreed specification guideline or template. Chapter 4 – MATURITY LEVELS OF SCENARIO SPECIFICATION In order to assess the quality of a scenario specification. Very seldom exceptions may be very small and focused simulation environments which are planned and set up by a single person (or very few persons).. • Level 2 – Standardized scenario specification. a maturity level indicates that all goals defined for this level are achieved. STO-TR-MSG-086-Part-II 4-1 . Maturity levels are well known from CMMI (Capability Maturity Model Integration) which provides the following definition: “Maturity level: Degree of process improvement across a predefined set of process areas in which all goals in the set are attained.” [CMMI.1 LEVEL 0 – NO WRITTEN SCENARIO SPECIFICATION Maturity Level 0 refers to the situation where no written scenario specification is available at all. traceability and understandability are reduced to a minimum. this kind of (unavailable) documentation is error-prone. achieving only maturity Level 0 is in almost all conceivable cases not sufficient. 1 – Non-standardized scenario Free text documentation. Table 4-1 provides an overview of the maturity levels of scenario specifications and typical ways to represent scenario specifications on each maturity level. Maturity Level of Scenario Representation of the Scenario Specification Specification 0 – No written scenario Thoughts and ideas within the mind of the military user/SME. oral specification explanation. and • Level 3 – Formal scenario specification. Detailed descriptions are provided in the following sub-sections. Similarly. In this case the scenario is only available within the minds of the participating persons and explained and communicated orally. p. i. maturity levels may be used to indicate the quality of a scenario specification. For these reasons. 3 – Formal scenario specification Formal specification of a scenario. A 4-level maturity model for scenario specifications is proposed: • Level 0 – No written scenario specification. 445] With regards to CMMI. • Level 1 – Non-standardized scenario specification. this guideline introduces maturity levels. Obviously. the core idea is to use maturity levels as an indicator for process improvement.

e. the main benefit of a non-standardized scenario specification is the availability of a scenario specification at all.3 LEVEL 2 – STANDARDIZED SCENARIO SPECIFICATION Maturity Level 2 requires the creation of a standardized scenario specification and is a great step forward compared to maturity Levels 0 and 1. However. A key characteristic of open standards is their public availability that allows broad usage of such a standard. 3) Comparability of scenario specifications is low as each scenario is specified differently. IEEE. Local standards reflect the fact that standards are used by different communities at different levels. Examples for standards organizations are SISO.MATURITY LEVELS OF SCENARIO SPECIFICATION 4. etc. 2) Ensuring completeness of the scenario specification is complicated (due to missing checklists). custom structure for the scenario documentation.) is quite high. and 4) Reuse is hampered due to low comparability of scenario specifications and thus limited possibilities for efficiently searching and finding suitable existing scenarios. the familiarization effort for involved parties (user. Therefore. Open standards are defined by AMSP-01 [AMSP-01] as “Specifications that are developed by a standards organization or a consortium to which membership is open. AMSP-01 uses the term “Local standards” to denote specifications and standards that are organization- specific and usually not publicly available. publicly available) standard for scenario specifications. In this context “non-standardized” means that the scenario specification is not created according to a generally accepted standard but structured according to the likings of the persons participating in planning and designing the simulation environment. and ISO. 4. Maturity Level 1 requires only the existence of a written scenario specification but does not require that this specification is structured according to any specific standard. system operators. this broad use of the term “standardized” includes open standards and local standards (as defined by [AMSP-01]). but is insufficient for achieving higher maturity levels of scenario specification.2 LEVEL 1 – NON-STANDARDIZED SCENARIO SPECIFICATION Maturity Level 1 indicates the existence of a scenario specification at least in a non-standardized way. Only by using a standardized and ideally open (i. potential benefits may be realized. The main benefits of a standardized scenario specification are: 4-2 STO-TR-MSG-086-Part-II . The existence of documentation at all allows basic traceability of requirements and improves understandability of the simulation environment for directly involved persons as well as third parties. Therefore. everybody who is specifying a scenario may use a different. and are available to the public for developing compliant products (with or without some license fee)”.. a non-standardized scenario specification still comes along with many problems: 1) Due to a missing standardized documentation template. Compared to maturity Level 0. We deliberately interpret “standardized” rather broad and consider any scenario specification to be standardized if the standard is agreed upon beforehand jointly by all participants in the engineering process and if the standard is used across multiple simulation environments. The scenario documentation may follow available standards like the DSEEP which give a few hints about the necessary content of a scenario specification. As the DSEEP does not provide detailed templates for scenario specification. M&S experts. it is sufficient to achieve maturity Levels 0 and 1.

computer-generated forces) which are part of the simulation environment. Transfer and sharing of scenario specifications is easily possible. the V&V experts responsible for the quality management as well as all readers of the scenario specification in general. the provision of at least a standardized (and complete) scenario specification is required for achieving interoperability of simulation systems on the pragmatic. dynamic and conceptual level as defined by the Levels of Conceptual Interoperability Model [Wang2009].g. whether the Federation Object Model (FOM) provides interaction classes for all communication events defined in the scenario). One of the most prominent choices. no units are positioned outside the specified geographic boundaries). 2) Secondly and maybe even more important. no units have overlapping positions. The benefits of a rigorous formal scenario specification are manifold: 1) Ideally ambiguities are eliminated or at least reduced to a minimum. b) Automated initialization of all simulation systems and other member applications (like. 2) Following an analogue reasoning. Other options include RELAX NG [RelaxNG]. Several possibilities exist for defining such a formal specification.. 4.. in practice only certain combinations are possible or likely. initial familiarization efforts are minimized. is XML Schema [XMLSchema]. a clearly defined scenario specification structure (ideally accompanied by explanatory texts) simplifies the development of a “good” scenario specification. MATURITY LEVELS OF SCENARIO SPECIFICATION 1) As all persons involved in the scenario specification process are familiar with the standard and the scenario structure defined by this standard. As scenarios are decisive sources of requirements for the intended simulation environment.5 RELATION OF MATURITY LEVELS TO SCENARIO TYPES While in principle each maturity level may be assigned to any of the three types of scenarios. 4. automated processing of scenario specifications and extensive utilization of tools is made possible. Table 4-2 indicates: STO-TR-MSG-086-Part-II 4-3 .g. 4) Similarly. a standardized structure allows easier access to scenario documentation for all persons working on these scenarios. 3) A precisely defined scenario specification structure simplifies quality management activities (like evaluation of completeness of a scenario specification). 3) Reuse is simplified. This opens up a wide range of possible applications: a) Automated consistency checks (e. 5) A precisely defined scenario specification structure is the necessary prerequisite for the formal specification of a scenario.4 LEVEL 3 – FORMAL SCENARIO SPECIFICATION Maturity Level 3 requires the formal specification of a scenario. e. Scenario specifications may be archived and retrieved for later reuse. This availability of such a scenario specification structure is especially important if scenario specifications have to be created by persons with few or zero experience in this area. UML [UML] and OWL [OWL]. Benefits are a reduced risk of errors due to manual misconfiguration or human errors as well as an improved reproducibility.g. This includes the M&S experts which set up the simulation environment. c) Semi-automated or fully automated cross-checks with other information products developed during the engineering process (e.. especially in the software engineering domain.

.. and which provide a customized presentation and output of the conceptual scenario for discussion with the user and sponsor on the other hand. MSDL).g. Specifications of conceptual scenarios are regularly achieving maturity Levels 1 and partially also Level 2. • Which maturity levels are currently achieved (C) or at least partially achieved (/C/). Currently. and • Which maturity levels should be aimed for specifying the different types of scenarios (A).e. i.MATURITY LEVELS OF SCENARIO SPECIFICATION • Which maturity levels are generally applicable to which type of scenario (non-empty cells). Although most users follow some kind of schema for describing operational scenarios. 4-4 STO-TR-MSG-086-Part-II . A critical factor for achieving this target will be the availability of specialized tools which allow a formal specification of conceptual scenarios by M&S experts on the one hand. For specifying operational scenarios. formally specified conceptual scenarios. A necessary prerequisite for achieving this is the development and adoption of a common standard for specifying operational scenarios. executable scenarios are most often specified on maturity Levels 1 and 2. Table 4-2: Relation of Maturity Levels to the Different Types of Scenarios. we are not aware of any commonly used standard or even template. The short-term goal should be to consistently achieve maturity Level 2 across a large number of simulation environment engineering process applications. in our experience currently non-standardized scenario specifications prevail. A reason for this may be that currently available standards are missing important features or are not providing enough benefits compared to currently used “legacy” standards. Type of Scenario Maturity Level of Scenario Specification Operational Conceptual Executable Scenario Scenario Scenario 0 – No Written Scenario Specification C C 1 – Non-Standardized Scenario Specification C C C 2 – Standardized Scenario Specification /C/ /C/ /C/ 3 – Formal Scenario Specification A A /C/ A Regarding operational scenarios. the mid-term target should be to achieve maturity Level 2. but are not as regularly used as they could be. Approaches for formally specifying scenarios are available (e. The target must be to achieve maturity Level 3 for the specification of executable scenarios in order to realize the potential benefits. The mid-term to long-term target should be maturity Level 3.

Maturity Type of Scenario Level of Operational Scenario Conceptual Scenario Executable Scenario Scenario Specification Standards Tools Standards Tools Standards Tools 0 – No Written Scenario Specification 1 – Non. “Everybody General Unified General Individual General Standardized uses his own purpose Modelling purpose documentation purpose Scenario standard.g. Systems story books) UML editors Modelling Language (SysML) 2 – Stand.” software Language software (e. This compilation is not exhaustive but tries to give an overview. Table 5-1: Standards and Tools for Scenario Specification. The assignment of standards and tools to the different types of scenarios indicates for which type of scenario a standard or tool is most likely to be used. software Specification DSEEP (UML) Wiki engines MEL/MIL. This assignment does not exclude the use of a standard or tool for a different type of scenario. NATO General NATO General Proprietary ardized Comprehensive purpose Architecture purpose (vendor- Scenario Operations software Framework software specific) data Specification Planning (NAF) Wiki engines exchange Directive VEVA formats (formerly: UML editors documentation “NATO guidelines Guidelines for (in Germany) Operational Planning”) 3 – Formal C-BML Base Object JEMM MSDL XML Scenario JC3IEDM Models (BOM) JTDS Order of editors Specification Battle Service MSDE. More detailed explanations on the standards and tools are given in the following subsections and may also be found in AMSP-01 [AMSP-01].. ADatP-3 C-BML WebMSDE C2IEDM/JC3I Saab EDM Scemanta C2LG GUI Exonaut Tool Suite STO-TR-MSG-086-Part-II 5-1 . Chapter 5 – STANDARDS AND TOOLS FOR SCENARIO SPECIFICATION Table 5-1 lists available standards and tools for scenario specification.

1 DSEEP Type of Standard: Open standard. Any general-purpose software may be used to document scenarios. publicly available. Following [JC3IEDM] the scope of this data model is directed at producing a corporate view of the data that reflects the multi-national military information exchange requirements for multiple echelons in joint/ combined wartime and Crisis Response Operations (CRO). OpenOffice Writer). • Operational planning.g. the DSEEP provides basic guidance on the content of a scenario specification [DSEEP.1. 5-2 STO-TR-MSG-086-Part-II . The Distributed Simulation Engineering and Execution Process (DSEEP) [DSEEP] describes a generic 7-step process for developing and executing a simulation environment. Command.. As the DSEEP is considered as a generalized. Typically used software includes: • Word processors (e. • Graphics editors (e.g. Nevertheless. 13ff. It is assumed that each organization that uses the DSEEP provides this detailed guidance as part of the individual adaptation.STANDARDS AND TOOLS FOR SCENARIO SPECIFICATION 5. The Joint Consultation. and Control Information Exchange Data Model (JC3IEDM) [JC3IEDM] is a data exchange model that aims to improve interoperability between systems that exchange Command and Control (C2) information. The JC3IEDM development is managed by the Multi-lateral Interoperability Programme (MIP). OpenOffice Impress). publicly available from SISO and IEEE. publicly available from Multi-lateral Interoperability Programme (MIP).. the DSEEP does not provide very detailed guidance or even documentation templates for activity outcomes.2 NATO Comprehensive Operations Planning Directive Type of Standard: Open standard. high-level framework which has to be adapted to individual needs. • Presentation programs (e. MS Word.4 Joint C3 Information Exchange Data Model (JC3IEDM) Type of Standard: Open standard. and for each activity inputs and outputs are specified by the DSEEP. Adobe Photoshop. p. Each step of the DSEEP is further sub-divided into more specific activities. gimp). publicly available. 5.3 General Purpose Software Type of Tool: Open tool.g.1 STANDARDS AND TOOLS FOR OPERATIONAL SCENARIOS 5.1. Although these planning procedures are not dedicated solely to scenario development they are agreed guidelines and can thus be seen as standards. The NATO Comprehensive Operations Planning Directive (COPD) [NATO_COPD] (formerly: “NATO Guidelines for Operational Planning”) and its national counterparts define operational planning procedures.. MS PowerPoint. The data model is focused on information that supports: • Situational awareness. 5.].1.1. 5.

These message formats are to be used for all formatted character-oriented messages within the NATO Command. and • Reporting.2.1 NATO Architecture Framework (NAF) Type of Standard: Open standard.e. publicly available from SISO. As the JC3IEDM is used to describe operational situations it is obvious that it may also be used to describe operational scenarios. 5.6 Coalition-Battle Management Language (C-BML) Type of Standard: Open standard. Although NAF does not directly address scenario documentation it may be used for this purpose (see Annex A for an example).2 STANDARDS AND TOOLS FOR CONCEPTUAL SCENARIOS 5. 5. the NAF is originally intended for developing and describing complex (hardware and software) systems and not specifically for documenting scenarios.2 Unified Modeling Language (UML) Type of Standard: Open standard. Control and Information System (NCCIS) unless specifically excluded by multi-national agreement. which methodologies or modelling languages should be used).. publicly available from OMG and ISO/IEC. publicly available. STANDARDS AND TOOLS FOR SCENARIO SPECIFICATION • Execution. but not how these views should be filled (i. The Coalition-Battle Management Language (C-BML) currently under development by SISO provides an effort for a publicly available standard which may be used for specifying the course of events within a scenario.2. 5. Furthermore. As ADatP-3 is used to describe operational situations (like JC3IEDM) it is obvious that it may also be used to describe operational scenarios. The NATO Architecture Framework (NAF) [NAF] defines several views which may be used for documenting a simulation environment engineering process (as described in [EU CTF] and [10S-SIW-027]). 5. STO-TR-MSG-086-Part-II 5-3 .1. As explained by [ADatP-3] the standard provides the rules. constructions and vocabulary for standardised character-oriented message text formats that can be used in both manual and computer-assisted operational environments.5 Allied Data Publication 3 (ADatP-3) Type of Standard: NATO STANAG. The NAF defines only the content of the various views. It is concerned solely with the part of a message that contains the thought or idea the originator wishes to communicate. The transmission of formatted messages remains in accordance with the instructions given in relevant Allied Communications Publications. The scope includes data from various functional areas according to the requirements levied by MIP and NATO.1.

In addition. those aspects of a simulation conceptual model found in a BOM contain information on how such items relate or interact with each other in the real world in terms of patterns of interplay and state machines. SysML could be beneficial for the development of a distributed simulation environment. “BOMs serve to provide an end-state of a simulation conceptual model and can be used as a foundation for the design of executable software code and integration of interoperable simulations. The first can be used for requirements analysis and the latter for engineering analysis of critical system parameters.2.2.3). Obviously. publicly available from OMG. the VEVA documentation guidelines provide specialized documentation templates for scenarios. Also. p. the VEVA is not an official.4 Base Object Models (BOMs) Type of Standard: Open standard. Specifically for specifying scenarios there is probably not too much difference between using UML or SysML. The documentation templates defined by VEVA are most applicable for documentation of operational scenarios and conceptual scenarios. 5. A standard which directly addresses defining and reusing components of models. Large parts of UML and SysML overlap. 7] A detailed analysis regarding usability and practicability of using BOMs for scenario documentation is presented in [13S-SIW-019]. 5-4 STO-TR-MSG-086-Part-II . 5. but as the VEVA is used regularly within the German Armed Forces it is considered as a standard (in the sense of the definition given in Section 4. the Unified Modeling Language (UML) [UML] defines several diagram types which may be used to document specific parts of a scenario. public standard. 5. The system engineering world has derived the Systems Modelling Language (SysML) from UML.3 Systems Modelling Language (SysML) Type of Standard: Open standard. class diagrams may be used to define unit hierarchies and deployment diagrams may be used to document which units are simulated by which simulation system. As the UML is a generic modelling language it is not specifically designed for documenting scenarios. Especially. simulations and federations is the Base Object Model (BOM) Template Specification [BOM]. For example.6 Joint Exercise Management Module (JEMM) Type of Tool: Local tool.2.” [BOM. publicly available from SISO. available from NCIA.STANDARDS AND TOOLS FOR SCENARIO SPECIFICATION Also. The UML language comes from the software engineering world. Representatives of a different approach are the VEVA documentation guidelines. The VEVA process model is a German approach for operationalizing the DSEEP and provides detailed documentation guidelines covering the whole simulation environment engineering process [11S-SIW-044] [11F-SIW-023] [Siegfried2010].” Regarding scenario documentation: “The aspects of a simulation conceptual model found in a BOM contain static descriptions of items resident in the real world described in terms of conceptual entities and conceptual events. partially publicly available. 5. used by German Armed Forces. As described therein. but SysML adds two additional diagram types: requirements diagrams and parametric diagrams. Annexes B and C provide examples for the usage of BOMs for scenario specification. Given that a distributed simulation environment is more than software only.2.5 VEVA Process Model Type of Standard: Local standard.

STANDARDS AND TOOLS FOR SCENARIO SPECIFICATION JEMM (NC3A Joint Exercise Management Module) [Cayirci2010] is a so-called “Exercise and Scenario Management Tool”.2 Order of Battle Service (OBS) Type of Standard: Local standard used by JTDS. The most widely known and publicly available standard for specifying executable scenarios is the Military Scenario Definition Language (MSDL) [MSDL] which is developed and maintained by SISO. They can help in preparation and management of scenarios as well as the Main Event and Master Incident Lists (MEL/MIL). The JTDS OBS XML Schema defines the XML interchange format used to exchange initialization data between JTDS and the JLVC federation.1 Military Scenario Definition Language (MSDL) Type of Standard: Open standard. publicly available from SISO. etc. Due to various reasons. A MEL/MIL tool can also be very useful in synchronizing and managing the flow of an exercise according to the exercise objectives. as well as. units. 5. Similar to MSDL.e. information management and information exchange throughout an exercise process. The Order of Battle Service (OBS) which is part of the US Joint Training Data Services (JTDS) provides pre-populated Order of Battle data sets for use within the Joint Live. Virtual. Constructive (JLVC) Federation [11F-SIW-034]. MSDL allows especially the specification of the initial state of a scenario.. In its current version. STO-TR-MSG-086-Part-II 5-5 .3. Exercise and Scenario Management tools can be used for the automation of processes. the OBS XML Schema allows representation of force sides.3. planning.3 STANDARDS AND TOOLS FOR EXECUTABLE SCENARIOS 5. collecting and analyzing the observations. facilities. course of events) are currently not part of the MSDL. 5. relationships. Dynamic properties of a scenario (i. the OBS XML Schema was developed in parallel with MSDL [MSDL]. MSG-068 used JEMM for this purpose [NMSG-068].

STANDARDS AND TOOLS FOR SCENARIO SPECIFICATION 5-6 STO-TR-MSG-086-Part-II .

Mojtahed2008 V. 2007. JC3IEDM Multilateral Interoperability Programme (MIP). 11F-SIW-034. SISO 2011 Fall SIW. November 2008. October 2002. NATO_COPD NATO. RTO Technical Report RTO-TR-MSG-068 AC/323(MSG-068)TP/407.3-2003. May 2010.H. “Joint Consultation. November 2005. “Effective Realism”. (JC3IEDM). 5th NATO CAX Forum 2010. 17 December 2010. RTO-TR-MSG-024 AC/323(MSG-024)TP/27. Keuning2008 M. NAF NATO Consultation. Keuning and A. P. 2003. Budde. B. FEDEP IEEE: IEEE Recommended Practice for High Level Architecture (HLA) – Federation Development and Execution Process (FEDEP). RTO Technical Report TR-MSG-053 AC/323(MSG-053)TP/302. “The Knowledge Use in DCMF”. January 2008. Kabilan. DoD M&S Glossary Department of Defense: Modeling and Simulation (M&S) Glossary. Anderson and V.4.4. Paper 8187. ISSN 1650-1942. Mojtahed2005 V. B. 24 December 2010. Germany. JP3-09. NATO_COBP NATO: Code of Best Practice for C2 Assessment. Command and Control Information Exchange Data Model”. Mojtahed. AC/322-D(2007)0048-AS1. “NATO Comprehensive Operations Planning Directive”.1. E.L.pdf. Zdravkovic and A. M. I/ITSEC 2008. FL. Gerretsen. Khan. Tjörnhammer. Gregg and D. 14 February 2012. J. Mojtahed. Cayirci. Published by Modeling and Simulation Coordination Office.fas. Bowers.G. USA. August 2010. Tutorial on “Joint Exercise Management Module (JEMM)”. Version 3. “JLVC Data Initialization”. Command and Control Board (NC3B): NATO Architecture Framework. Orlando. IEEE Std 1730-2010.3 Joint Publication 3-09. MSC-DMS Department of Defense Modeling and Simulation Coordination Office: Modeling and Simulation (M&S) Community of Interest (CoI) Discovery Metadata Specification (MSC-DMS). DSEEP IEEE: IEEE Recommended Practice for Distributed Simulation Engineering and Execution Process (DSEEP). “DCMF-Defence Conceptual Modelling Framework”. C. Winkowski. 1 October 2011. MSG-068 NATO: Final Report of MSG-068 “NATO Education and Training Network”. MSG-024 NATO: Final Report of MSG-024 “M&S Support to Non-Article 5 Operations”. Version 3. STO-TR-MSG-086-Part-II 6-1 . ISSN 1650-1942. http://www. FOI-R–1754–SE. February 2012. Cayirci2010 E. Svan. 2011. Chapter 6 – REFERENCES Reference / Key Full Bibliographical Information 11F-SIW-034 A.3 Close Air Support.org/irp/doddir/dod/jp3_09_3. Version 1. IEEE Std 1516. 8 July 2009. MSG-053 NATO: Final Report of MSG-053 “Rapid Scenario Generation for Simulation Applications”. Lozano. Ottobrunn. FOI-R–2606–SE.C.

Utrecht. http://relaxng. Brussels: NATO Headquarters. G. Committee Specification. Siegfried. Hahn. “Components and Reuse in Scenario Development Processes for Distributed Simulation Environments”. Paper 12F-SIW-046. Steinkamp. G. J. Orlando. D. A. H. Hahn.1/. Steinkamp. Paper 12S-SIW-014. AMSP-01. 14 October 2008 – SISO-STD-007-2008.org/spec-20011203. Herrmann.REFERENCES Reference / Key Full Bibliographical Information AAP-06 NATO Standardization Agency (NSA): NATO Glossary of Terms and Definitions. “RELAX NG Specification”. Part of EU Core Technical Framework Study. (See also “ISO/IEC 19757-2:2003 Document Schema Definition Language (DSDL) – Part 2: Regular-Grammar-Based Validation – RELAX NG” for an ISO version of RELAX NG Specification. USA. Laux. Siegfried. Herrmann. July 2009.1. Siegfried. Orlando. Version 1. U. Laux. Herrmann. Netherlands. 6-2 STO-TR-MSG-086-Part-II . G. Hahn. NATO Message Text Formatting System (FORMETS) – System Concept Description and Management (October 1987). J. ADatP-3 ADatP-3. 3 December 2001.org/spec/UML/2. CA. G. Lüthi. Hahn. J. Edition (B).omg. G. A. Boston. Edition 2013. SISO 2011 Fall SIW. Paper 010. USA. A. BOM SISO: Base Object Model (BOM) Template Specification.) UML Object Management Group (OMG). USA. AMSP-01 NATO: NATO Modelling and Simulation Standards Profile. Herrmann and J. August 2011. “VEVA as German Approach Towards Operationalizing the DSEEP: Overview and First Experiences”. Part 1. San Diego. Lüthi and M. FL. Version 2. Hahn. Lüthi and M. A. Siegfried. Siegfried. MSDL SISO: Military Scenario Definition Language (MSDL). http://www. Lüthi and M. Paper 13S-SIW-019. SISO 2012 Spring SIW. 11S-SIW-044 R. M. Laux.4. FL. D. 13S-SIW-019 R. Lüthi and M. Rother. Relax NG The Organization for the Advancement of Structured Information Standards (OASIS). J. Paper 11S-SIW-044. G. Hatip. Herrmann. 31 March 2006 – SISO-STD-003-2006. “Scenarios in Military (Distributed) Simulation Environments”. EU CTF Saab Systems and Combitech: Core Technical Framework for Distributed Simulation. Rother. NATO MSG Symposium 2010. SISO 2011 Spring SIW. Oguztüzün. Siegfried. USA. P. Herrmann. Paper 11F-SIW-023. SISO 2012 Fall SIW.html. “Specification and Documentation of Conceptual Scenarios Using Base Object Models (BOMs)”. “Unified Modeling Language”. Gustavson and M. Durak. 12S-SIW-014 R. MA. EDA reference number 08-R&T-004. June 2011. Siegfried2010 R. “A Comparison of DSEEP with the German Approach VEVA”.4. 2013 SISO Spring SIW. 11F-SIW-023 R. “VEVA – A Procedure Model for Distributed Simulation Experiments”. 12F-SIW-046 R. M.

Paper 9198.3. CA. SCS Spring Simulation Multiconference. http://www. W3C Recommendation. Voogd2009 J. w3. 10S-SIW-027 J. Version 1. USA. A. 23-27 March 2009. “XML Schema”. Tolk and W. A. Suzic. 28 October 2004. 10S-SIW-027. W3C Recommendation. FL. STO-TR-MSG-086-Part-II 6-3 . Orlando. Wang. 27 October 2009. Lemmers. “Core Technical Framework Stud: DSEEP Adaption and MODAF Mapping”. OWL W3C. November 2010.w3. I/ITSEC 2009. SISO 2010 Spring SIW. REFERENCES Reference / Key Full Bibliographical Information CMMI Software Engineering Institute: CMMI for Development. USA. San Diego. “The Levels of Conceptual Interoperability Model: Applying Systems Engineering Principles to M&S”. Voogd. Karelse: “Effective Use of Simulation Means in Collective Mission Simulation”. Tegner and R. “OWL 2 Web Ontology Language”. Technical Report CMU/SEI-2010-TR-033. Gerretsen. A. Wang.org/XML/ Schema. http://www.org/TR/owl2-overview/. M. XMLSchema W3C. Wang2009 W. Roza and R.

REFERENCES 6-4 STO-TR-MSG-086-Part-II .

Due to the similarity of the real-world military domain and the design of simulation environments and simulations for the military domain. [. Development and Portfolio. relations and ideas expressed therein. their abstract roles and relationships and the integration of these parts into different views (plans) according to certain templates.. • Systems Engineering. • Develop Scenario (Operations Planning). their relationships to each other and to the environment and the principles guiding its design and evolution. the architect normally uses a specific type of formal description for their work. Depending on the specific domain many formal notions of architectures have evolved. it is very likely that at least some parts of the NAF will also be helpful to support the design and execution of distributed simulation. and • Develop and Integrate Simulation Environment (Systems Engineering).. floor plans in the construction domain or UML diagrams in the software domain.1 RATIONALE The following citation from [NAF] roughly describes what is commonly understood by the term “architecture”: An architecture is the fundamental organisation of a system embodied in its components. According to [DSEEP] for example the following tasks will occur: • Develop Objectives. A. Extensive work has been carried out in [10S-SIW-027] to analyse and demonstrate the usability of architecture frameworks in this context (using the Ministry of Defence Architecture Framework MoDAF instead of NAF). Documenting the architecture in a formalized way ensures that every expert capable in understanding the formal notion can also read and understand the architecture. Following these ideas and convinced STO-TR-MSG-086-Part-II A-1 . its elements. It typically comprises some kind of symbology.g.] An architecture is little more than a plan put together in accordance with certain rules. When creating an architecture. This fosters coherent design and reuse. Initial Planning (Capabilities. Programming and Execution. Portfolio). • Acquisition. • Planning. e. elements of the domain. In this sense the NATO Architecture Framework (NAF) provides many different views and related templates to describe system architectures to be used in the NATO military domain for different purposes like for example: • Capabilities Integration. Annex A – SCENARIO SPECIFICATION USING THE NATO ARCHITECTURE FRAMEWORK This annex describes how the development of a scenario may be supported and documented using the NATO Architecture Framework (NAF). The formalized notion for an architecture within a single application domain may be called “architecture framework”. Several of these activities will also have to be carried out on the design and execution of distributed simulation. and • Operations Planning..

NSV System View and NTV Technical View sections. Operational scenarios have to be provided by the user and form the starting point of the scenario development process. Although the latter describes federates.ANNEX A – SCENARIO SPECIFICATION USING THE NATO ARCHITECTURE FRAMEWORK of the general usability of NAF in the context of distributed simulation in the military domain in the following sections concentrates on the question on how the development of a scenario may be supported using the NAF. that the derivation of conceptual scenarios from operational scenarios will benefit most from the use of NAF. However. However. The use of NAF templates to describe these detailed scenarios probably won’t be feasible.3 NAF TEMPLATES FOR CONCEPTUAL SCENARIOS The analysis in the previous section shows. A. nor will all templates featured by the framework have to be created for the description of a particular architecture. actions. A-2 STO-TR-MSG-086-Part-II . NOV Operational View. It is obvious. concepts of operations. The user normally will not be aware that by creating these graphical and textual descriptions they may actually be creating a NAF NOV-1 High Level Operational Concept Description. tasks and events. From the NAF point of view such information is captured in templates from the NAV All View.2 explains the differences between operational. Executable scenarios finally contain all information necessary for preparation. and procedures. environmental conditions. it concentrates on the construction of distributed simulation systems only and lacks the templates necessary to describe scenarios. They are created by M&S experts by analysing the operational scenario and extracting the conceptual information necessary to construct a simulation environment matching the operational scenario. it should be noted here that an M&S expert is not necessarily a NAF-aware system architect. that this work will benefit from the application of NAF because the main goal of NAF is the support of the analysis and design of complex systems and finally creating an architecture of the system to be constructed. because the information to be captured in most cases will be too specific to be described by NAF templates. They are described in terms the user is familiar with and often are a combination of graphical and textual descriptions of involved entities. conceptual and executable scenarios within the scenario development process. Also their description may contain information on doctrine. A. In addition there is no standardized machine-readable format for NAF. Although the use of NAF templates even in this early phase of scenario development would be feasible and desirable. that this use of architectures and the corresponding frameworks must not be confused with simulation architectures like the High Level Architecture (HLA). a system architect familiar with the NAF should be involved in the development of the conceptual scenario. and technical standards to be used and so on. preferably in machine readable form. They contain the most detailed specification of the scenario and are derived from the corresponding conceptual scenarios by M&S experts and system operators. initialization and execution of the simulation environment. at least as long as the M&S experts are not familiar with the NAF themselves. It should be pointed out. the user normally is not familiar with the NAF and will have no support by an architecture expert during the creation of the operational scenario.2 ARCHITECTURES IN THE SCENARIO DEVELOPMENT PROCESS Section 2. normally operational scenarios are being developed without any relations to the NAF. This will be detailed in the next section. tactics. Conceptual scenarios refine the operational scenarios. object models and federation rules and therefore forms some kind of architecture framework. The typical architecture creation process does not follow any specific sequence of templates. To gain optimal results.

. ANNEX A – SCENARIO SPECIFICATION USING THE NATO ARCHITECTURE FRAMEWORK Instead the decision on the templates to be created and the sequence of template creation has to be made on a case by case basis to gain optimal results. For a description of conceptual scenarios using templates of the NAF a good starting point would be the creation of the NAF operational view. A. NAF Template Usage NOV-1 Describe the context.g. We explicitly note here that this proposed structuring of operational information in NAF templates has nothing to do with simulation. Following and augmenting the recommendations from [10S-SIW-027]. the NOV templates from the NAF may be used in this way.g. Operational Information Requirements NOV-4 Describe organizational relationships if relevant for the operation. Given the operational scenario from Annex C for example the NOV-5 activity tree may look as depicted in Figure A-1.1 NOV Operational View The creation of the operational view mainly consists of a capturing and structuring of information already present in the operational scenario in an unstructured form.. Organizational Relationships NOV-5 Describe activities that are relevant for the operational scenario. operational nodes are logical collections of operational activities. It is the same task as designing. Operational nodes produce or consume information and may represent an operational realization of capabilities. NOV-3 Describe operational information to be exchanged among the nodes. The transformation to a simulation environment occurs at a later stage by replacing the real systems by simulation models with the appropriate capabilities. Table A-1: Usability of NAF Operational View Templates for the Description of Scenarios. STO-TR-MSG-086-Part-II A-3 . NOV-2 Describe operational nodes and their roles and collaboration patterns from Operational Node an operational point of view. Operational Activities NOV-6 Describe the sequencing of activities and events. Connectivity Describe activities to be performed by nodes. e.3. Therefore the following sequence of steps is proposed as a guideline. a defence architecture using real weapon systems on the basis of a real-world operational scenario. High-Level Operational May already be available in the operational scenario description. on environmental conditions may be stated here. because the operational scenario is already present and will provide a good starting point. major entities and actions involved in the operation. e. Concept Additional constraints or preferences. Operational Activities Sequence and Timing According to NAF.

No operational information is exchanges between the nodes. According to [10S-SIW-027] Table A-2 below.ANNEX A – SCENARIO SPECIFICATION USING THE NATO ARCHITECTURE FRAMEWORK Figure A-1: NOV-5 Operational Activity Tree for Scenario Example from Annex C. To express the opponent role of the helicopter. but will be simulation systems or individual simulation models and therefore their specific requirements will have to be taken into account. A. and assign operational activities to the nodes. so (in NAF terminology) a “need line” between the nodes is missing. the following NSV templates from the NAF are useful. Figure A-2: NOV-2 Operational Nodes for Scenario Example from Annex C. Additionally the nodes may be attributed with the activities performed at the nodes. A-4 STO-TR-MSG-086-Part-II . different colours for the operational nodes are used. In this phase special M&S knowledge will be necessary because the systems will not be real-world weapon systems.2 NSV System View In a next step some templates of the NAF System View may be deduced from the operational view.3. The NOV-2 operational node connectivity diagram then might look as shown in Figure A-2. the AH-1 helicopter and the infantry troop. For the example operational scenario (see Annex C) two operational nodes may be identified.

NAF Template Usage NSV-1 Describe the interfaces (simulated operational interfaces and simulation System Interfaces specific interfaces) of the systems. STO-TR-MSG-086-Part-II A-5 . Similar to the assignment of operational activities to operational nodes in the operational view. Sequence and Timing NSV-11 Describe data to be represented in the simulation environment. these system functions may be assigned to individual systems. Rules. Continuing the example from above. Table A-3: NSV-5 Operational Activities to System Function Traceability Matrix for Scenario Example from Annex C. state transitions and event traces. model capabilities) necessary to System Functions to perform the required operational activities. System Data Model may be focused on exchanged data (FOM. These system functions therefore may be identified with individual functions or capabilities of simulation models. ANNEX A – SCENARIO SPECIFICATION USING THE NATO ARCHITECTURE FRAMEWORK Table A-2: Usability of NAF System View Templates for the Description of Scenarios. the list of system functions (1st column) and their mapping to operational activities (1st row. see table above) as NSV-5 matrix may appear as presented in Table A-3 below. Move Detect Engage Dispense Flares Radar Detection X Visual Detection X IR Detection X Flight Helicopter X Flight Missile X Flight Flare X X IR Emission X X Radar Reflection X Each of the operational activities thereby requires one or several system functions to be implemented in the system. NSV-5 Describe system functions (e.g. message exchanges and System Communication (simulation) communication quality requirements. NSV-2 Describe system or model communication. NSV-10 Describe system rules.. From the assignment of system functions to system nodes and from the necessary data flows between the system functions then follows the NSV-2 System Communication template. in HLA terminology). Operational Activity Tracing NSV-4 Describe systems or models to be present and their functionality to be System Functionality represented.

ANNEX A – SCENARIO SPECIFICATION USING THE NATO ARCHITECTURE FRAMEWORK Figure A-3: NSV-2 System Communication Template for Scenario Example from Annex C. e. For example.. It is obvious. A. and • NAV-2 Integrated Dictionary. that these information exchanges form a starting point for the definition of the data (exchange) model NSV-11 (the FOM in HLA terminology) or a description of event sequence and timing NSV-10. the infantry troop model needs information on position and movement of the helicopter to implement the visual detection system function. Examples are: • NTV-1 Technical Standards Profile: Describes the (simulation and operational) technical standards to be followed. • NTV-3 Standard Configuration: Describes the standard system configurations that are known to work.g. the missile model may be composed of a movement model (implementing the “flight missile” system function) and an IR seeker model (implementing the “IR detection” system function). guidance and distortion of detection/guidance by IR emissions from the flare. Each of the models may contain sub-models not shown in this figure. In contrast to the NOV-2 operational node connectivity diagram there is intensive data exchange between the individual systems/models. This is depicted by the connection lines in the figure above. the transmitted information and direction of data flow indicated by the arrows and their labels. Here the green boxes denote the individual simulation models. A-6 STO-TR-MSG-086-Part-II .3 Other Views and Templates In addition to the templates listed above several other templates from the NAF may be used to further detail the conceptual scenario description. The missile will need position information from the helicopter and the flare to implement target detection. On detection it will launch the missile (model).3. which implement the system functions listed in the table. The helicopter model will need the position information from the missile model to implement radar detection of the missile and to launch the flare.

variations. information about the base object model itself) with the model. B. • Conceptual Model Definition. and exceptions) which are required to represent the activities and interactions within the conceptual model.1 OVERVIEW OF THE BOM STANDARD As stated in [BOM]. undirected) which are required for representing the pattern action of a pattern of interplay. and composability”.1. “Base Object Models (BOMs) provide a component framework for facilitating interoperability. • Object Model Definition. All four components are described in more detail in the following sub-sections. and • Model Mapping.e. The entity types define the types of conceptual entities required for representing all aspects of the conceptual model. A Base Object Model is composed of four major components: • Model Identification (Metadata). STO-TR-MSG-086-Part-II B-1 . • Pattern of Interplay. The pattern of interplay defines a set of patterns of interplay (including pattern actions. The state machine identifies the conceptual entities and their respective states as well as the state transitions which are required within this conceptual model.1 Model Identification The “Model Identification” component of a BOM associates important metadata (i. • State Machine. For defining the conceptual model the BOM Template Specification defines four template components as sub-components of the “Conceptual Model Definition”: • Entity Type. For this purpose the “Base Object Model (BOM) Template Specification” defines the format and syntax for describing the elements of a template for representing BOMs. This information is necessary for purposes of search and retrieval of BOMs as well as for maintaining traceability and facilitating reuse of BOMs. reuse. and • Event Type.2 Conceptual Model Definition The “Conceptual Model Definition” component of a BOM is used for specifying the conceptual model represented by this BOM. The event types define types of conceptual events (directed. B. Annex B – SCENARIO SPECIFICATION USING BASE OBJECT MODELS B.1..

state diagrams for state machines). tabular.1. B. B..ANNEX B – SCENARIO SPECIFICATION USING BASE OBJECT MODELS B. Figure B-1 shows an example. graphical). p.3 Object Model Definition “The Object Model Definition defines the structure of object and interaction classes. However. Basically.5 Documentation of BOMs Each of the four main components of a BOM may be documented and represented in many ways (e. In its current version. almost all tables may be transformed into respective UML diagrams (e.g. textual.. using the classes “HLA Object Class” and “HLA Interaction Class” as respective root classes for objects and interactions).1.1.. The BOM DIF is specified as XML Schema and provides the possibility to represent a BOM as XML. and their associated attributed and parameters” [BOM. 48]. the BOM Template Specification uses table-based approach for specifying data.g.4 Model Mapping The “Model Mapping” component of a BOM template provides the link between the entities and events of the Conceptual Model Definition and the classes specified by the Object Model Definition. Figure B-1: Example Specification of State Machine as a Table (Top) and as a Diagram (Bottom) [BOM]. sequence diagrams for patterns of interplay. the BOM Template Specification describes the BOM Data Interchange Format (DIF). Additionally. the BOM Template Specification refers to the HLA OMT for defining object and interaction classes (e. B-2 STO-TR-MSG-086-Part-II .g.

In our opinion. we believe that the usage of UML as formal notation (which requires precision) simplifies this process and requires a certain scrutiny of scenario developers. the BOM Data Interchange Format (DIF) itself is a great advantage of the BOM standard. graphical.2. the focus on HLA (especially of the Object Model Definition and Model Mapping components) seems to be a drawback. Secondly. Especially the development of the patterns of interplay and the development of the state machines revealed many shortfalls which were not identified when developing the textual documentation of the conceptual scenario. This simplifies both understanding and comparing conceptual scenarios as the reader (e. B. model developer.. BOM DIF for tools).g.2 Negative Experiences Although the BOM Template Specification was very useful. This would open up the opportunity to create a direct link between the specification of conceptual scenarios and elements of corresponding executable scenarios.g. it would be of great value if mappings between entities and events of the Conceptual Model Definition and arbitrary elements defined in other specifications (e. a textual documentation of the conceptual scenario is shown and secondly it is shown how the conceptual scenario may be documented using the BOM Template Specification.3 Ideas for Improving the BOM Standard Besides relaxing terminology. which is refined into a conceptual scenario. it would be beneficial if the current mapping mechanism of the BOM standard (which maps entities and events of a Conceptual Model Definition onto classes defined by an Object Model Definition) would be generalized.2. user.. Although these shortfalls might generally also be identified when developing a textual documentation..2 EVALUATION In Annex C an operational scenario is presented. Shortcuts which are easily taken even by experienced developers (e. STO-TR-MSG-086-Part-II B-3 . First. B. ANNEX B – SCENARIO SPECIFICATION USING BASE OBJECT MODELS B. the well-structured templates of the BOM standard lead to a well-structured documentation of conceptual scenarios. sequence diagrams for user. The possibility to document (and present!) the same information in different ways is further supported by the BOM standard which defines at least three different representations: tabular. Finally. This allows presenting the same information differently for different users (e. due to missing information or time) are a lot easier to identify during quality management processes. or V&V agent) is familiar with the way a conceptual scenario is documented. Such links would also allow augmenting the specification of conceptual scenarios with more detailed specifications where necessary and would improve traceability between conceptual and executable scenarios a lot. BOM DIF.2. in MSDL or C-BML files) could be defined. the formal notation imposed by the BOM Template Specification requires a scenario developer to be much more precise when specifying conceptual scenarios (compared to a free-text documentation of conceptual scenarios). the BOM standard would benefit if terminology would be relaxed to be non-HLA-specific and aligned with DSEEP (which is architecture-neutral). B.g. The BOM DIF is the prerequisite for enabling any kind of tool support and automated processing of conceptual scenarios. Especially in the context of scenario specifications.g.1 Positive Experiences The BOM standard proved to be very useful for documenting conceptual scenarios for various reasons.. First.

ANNEX B – SCENARIO SPECIFICATION USING BASE OBJECT MODELS B-4 STO-TR-MSG-086-Part-II .

The ManPAD gunner launches the missile from 80% of range ring. The ManPAD team is deployed around 400 metres behind the manoeuvring unit on high ground. is supporting a manoeuvring unit. At the instant when the ManPAD commander receives an early warning with the assumed target location. and the missile approaches the target from the front.1 DESCRIPTION OF THE OPERATIONAL SCENARIO A ManPAD team consisting of a commander. The ManPAD observer starts searching the sector from which the aircraft is approaching. the ManPAD Commander orders a Fire Command. Figure C-1: Area of Interest. At the instant of fire. the ManPAD gunner starts an interrogation procedure. As soon as the helicopter detects the engagement. he triggers an IFF (identification friend or foe) operation. Since the ManPAD team is in Weapons Free status. As the target is identified as hostile. C. an observer and a gunner. Annex C – EXAMPLE SCENARIO “AIR DEFENCE” The example scenario “Air defence” is concerned with the study of the operational effectiveness of Man Portable Air Defence (ManPAD) systems for defending a manoeuvring unit against airborne attacks. As soon as the target is in range ring. the manoeuvring unit is heading north and the ManPAD team is behind the unit. The ManPAD observer catches a glimpse of a blade flash from rotating helicopter blades approaching from North. STO-TR-MSG-086-Part-II C-1 . the enemy helicopter is at 500 metres altitude and has a speed of 45 metres per second with straight flight. it throws a dozen flares to protect against the missile when it is within the last kilometre.

Below is the initial state of the example Air Defence scenario.1. • Spatial position: All three units at the same location. 0) Manoeuvre Straight flight Position 0.1 Units Unit Attribute Value Manoeuvring Unit Initial position 0. C. 0 in Local NED ManPAD Team Initial Position 0. • C2: Receives voice messages/commands over radio.2. C. The textual description of the conceptual scenario follows the scenario documentation template outlined in Chapter 3. 0. geography.2 TEXTUAL DESCRIPTION OF THE CONCEPTUAL SCENARIO This section presents a typical textual description of a conceptual scenario. C. 5500.2 Forces and Force Structure ManPAD Team • Composed of: ManPAD commander. -500 in Local NED Engagement Ring 2500 m C. ManPAD Observer. C-2 STO-TR-MSG-086-Part-II . ManPAD gunner. ManPAD Gunner Equipment and Weapons IFF and ManPAD-X Status Weapons Free Target Type AH-1 similar helicopter Altitude 500 metres Speed 45 m\s to South (-45. forces and the force structure.2. ManPAD observer. 0 (Local NED origin) Sub Units ManPAD Commander. The textual description provided in this section is introduced for comparison with the specification of the conceptual scenario using Base Object Models which will be presented in the following section. 0. 400.ANNEX C – EXAMPLE SCENARIO “AIR DEFENCE” The ManPAD observer then evaluates the first missile and reports the result to the ManPAD commander for consecutive action. • Command structure: ManPAD observer and ManPAD gunner are under the command of ManPAD Commander.2. surrounding conditions and the rules of engagement.1 Initial State The initial state specifies the situation at the beginning of the scenario time line which includes participating units.1.

ANNEX C – EXAMPLE SCENARIO “AIR DEFENCE” C. interaction.) as soon as a missile attack is detected. state change or environmental events.1.1. C.1 Communication Events Time Event 00:00 ManPAD commander receives a voice message with early warning information for a target at a specific position.5 Rules of Engagement ManPAD Team: 1) If any approaching object is identified and the status is Weapons Free then IFF operation will be triggered as soon as object heads into the range ring.2. weapon is fired.2. the conceptual scenario shall also specify pre-planned events that are triggered at a specific time or due to a specific condition. C. These events may include communication.1.2.2 Interaction Events Event Type Attribute(s) Trigger/Condition Target Identification Target Position Within 5 km of ManPAD team IFF Operation Target Position In the range ring of ManPAD missile Missile Fire IFF Status Foe Target Position In 80% of range ring Missile Detection Missile Position Within 1. and 2) If object is identified as hostile and the object is in 80% of range ring.2. and 2) Attack any manoeuvring target within engagement ring.2.3 Geography Attribute Value Area Hypothetical area Terrain Flat earth Atmosphere ICAO Standard Wind 5 m/s from East C. C.2. Helicopter: 1) Apply any means of soft kill (flares.2 Course of Events Besides specifying the initial conditions. etc.2.4 Surrounding Conditions Not applicable. manoeuvre. C. The course of events in the example air defence scenario is provided below.2.5 km of helicopter STO-TR-MSG-086-Part-II C-3 .

0 Modification Date 2012-12-10 Security Classification Unclassified Release Restriction Publicly releasable Purpose Analysis of the operational effectiveness of Man Portable Air Defence (ManPAD) systems for defending a manoeuvring unit against airborne attacks Application Domain Analysis Description This BOM specifies interactions between infantry using ManPADs against helicopters Use Limitation This BOM is not applicable for airborne attacks carried out by jet fighters or bomber units C-4 STO-TR-MSG-086-Part-II .3. Although it might be argued that it provides little additional value in the context of this example. C.ANNEX C – EXAMPLE SCENARIO “AIR DEFENCE” Event Type Attribute(s) Trigger/Condition Flare Dispense Missile Slant Range 1400 m Dispense Number 12 Initial Dispense Time 0. Below is the termination condition of the example air defence scenario.3 Termination Conditions Each conceptual scenario shall specify termination conditions which define the end of a scenario. Typical termination conditions can be that a predefined time has elapsed or that a specific condition is achieved.2.1 s C.6 s Dispense Interval Time 0. Termination Condition: The missile either hits the target or misses and self-destructs. Category Information Name Air defence of a manoeuvring unit using ManPADs Type BOM Version 1.3 USING BOMS FOR SCENARIO SPECIFICATION This section describes how the BOM Template is used for specifying the conceptual scenario (in contrast to the textual description of the conceptual scenario outlined in the previous section). we deliberately do not omit the “Model Identification” component of the BOM Template Specification. C.1 Model Identification We are convinced that the “Model Identification” component is a very important component which should always be specified in “real world” scenario development efforts.

a conceptual scenario will usually reference parts of a conceptual model (e. the definition of entities (and their properties) is part of the conceptual model and not part of a conceptual scenario.2. entities). a reference to this documentation of the conceptual model may be included in the “Reference” sub-component of the “Model Identification” component. conceptual scenarios are tightly connected to the conceptual model of a simulation environment. Strictly speaking. Aylin Hatip POC Organization … POC Telephone … POC Email … Reference None Type Identification Other None Glyph No glyph provided Type Alt Height Width C..1 Entity Types The BOM is made of several key elements.g. STO-TR-MSG-086-Part-II C-5 . the BOM Template provides the possibility to include information about entity types.3. ANNEX C – EXAMPLE SCENARIO “AIR DEFENCE” Category Information Use History Keyword Taxonomy Keyword Value POC POC Type Primary author POC Name Halit Oguztüzün POC Organization … POC Telephone … POC Email … POC POC Type Technical POC POC Name Umut Durak. etc.. However. one of them is the conceptual model.3. C. • Observer Entity. If a separate documentation of a conceptual model is available for a simulation environment. directly into the BOM.2 Conceptual Model Definition As described in Section 2.2. • Gunner Entity. Our conceptual model includes • Commander Entity.2. Otherwise.

C-6 STO-TR-MSG-086-Part-II .2.ANNEX C – EXAMPLE SCENARIO “AIR DEFENCE” • Hostile Object Entity. and • Target Entity.2 Pattern of Interplay The major pattern of interplay within this air defence scenario is the sequence from observing the airspace until detection. Entity Type Name Description Characteristics Description Commander Thing that is the ID Unique ID for entity Entity commander information _identifier Location Physical position of the entity Observer Thing that is the observer ID Unique ID for entity Entity information _identifier Location Physical position of the entity Gunner Thing that is the gunner ID Unique ID for entity Entity information _identifier Location Physical position of the entity Hostile Thing that is the hostile ID Unique ID for entity ObjectEntity object information _identifier Location Physical position of the entity Velocity Velocity for the entity Firing Thing that fires a weapon ID Unique ID for entity Entity at a target _identifier Location Physical position of the entity Target Thing that is the target ID Unique ID for entity Entity_identifer information Location Physical position of the entity Velocity Velocity for the entity MissileEntity_ Thing that is the missile ID Unique ID for entity identifier information Location Physical position of the entity Velocity Velocity for the entity C. identification and engagement of the target.3. • Firing Entity.

.

.

.

.

.

ANNEX C – EXAMPLE SCENARIO “AIR DEFENCE” C .12 STO-TR-MSG-086-Part-II .

If needed. D. A flight of two F-16 aircraft is on a close air support mission and is flying above the mission area. another attack is made. and • Wingman.2 CONCEPTUAL SCENARIO D. They will only release their weapon after the FAC team announced CLEARED HOT.1 Initial State D. • Initial position: • In a holding pattern somewhere above the battlefield. STO-TR-MSG-086-Part-II D-1 . This operational scenario is given as free text.1 F-16 Flight • Structure: • Flight lead. and • Targeting pod.2. The Forward Air Controller (FAC) team of the infantry unit requests air support from the F-16 flight. The attacking pilot contacts the FAC team on the ground. the pilot identifies the target. The aircraft are equipped with laser guided bombs. • Laser guided bomb. The pilot will announce when the weapon is 10 seconds before impact and at the moment the FAC team will start to illuminate the target with their laser. Annex D – EXAMPLE SCENARIO “CLOSE AIR SUPPORT” In this annex.1 OPERATIONAL SCENARIO Below is the operational scenario. where a Forward Air Controller (FAC) team on the ground and a flight of fighter aircraft work together to deliver a laser-guided weapon on a target (see [JP3-09. as it could be given by an operational person. The FAC team requests a Type 1 CAS attack and delivers the information about the target using the standard 9 liner procedure. and while communicating with the FAC team.1. an example is given how the information products related to scenario can be applied to a real world scenario. In the next sections. • Equipment: • Radio. A Close Air Support scenario is described. the operational scenario and conceptual scenario for this case are given. so it is using an unstructured scenario specification.3] for more details about Close Air Support procedures). After weapon impact the damage is assessed by the pilot and the FAC team. A friendly infantry unit is being attacked by insurgents from a building. Using their Targeting Pod (TGP). This example is based on work also described in [Keuning2008] and [Voogd2009].2. D. The flight lead determines which of the two aircraft will deliver the close air support. After successful identification the pilot starts their attack run.

Figure D-1: Actors. and • Within visual range of the insurgents. Figure D-2: Two Roles in the FAC Team. and • Laser operator.1. The flight lead will determine which aircraft is in the best position to deliver the support once the request is made.2. The UML diagram below shows the two roles in the FAC team graphically.2 FAC Team • Structure: • Team leader. • Initial position: • Near the infantry unit. D.ANNEX D – EXAMPLE SCENARIO “CLOSE AIR SUPPORT” The UML use case diagram below shows the actors within this scenario and indicates that both the flight lead and the wingman can become the attacking aircraft when close air support is requested. • Equipment: • Radio. and • Laser designator. D-2 STO-TR-MSG-086-Part-II .

1.7 Rules of Engagement • F-16: • Must have identified the target. D. • FAC team leader provides basic target information to F-16 flight lead.1 Communication Events • FAC team leader requests CAS from F-16 flight lead.6 Surrounding Conditions • Clear weather.2. D.2. ANNEX D – EXAMPLE SCENARIO “CLOSE AIR SUPPORT” D.1.1.2. • Must have identified the location of friendly forces around the target.2.5 Geography.2. D. D. D. • F-16 flight lead reports to F-16 wingman who is going to be the attacking aircraft.2 Course of Action D. • Attacking F-16 reports ready for attach run once target has been identified. Date/Time • Rural environment.1. • Attacking F-16 reports to FAC team leader 10 seconds before expected weapon impact.2 Interaction Events • Insurgents fire at infantry unit. STO-TR-MSG-086-Part-II D-3 .1.2. • No wind. • FAC team leader provides detailed target information to the attacking F-16. and • Must have received CLEARED HOT instruction from FAC team.3 Infantry Unit • Initial position: • Near insurgents. • FAC team leader reports CLEARED HOT when allowed to employ weapon.2. • Attacking F-16 identifies target (building with insurgents).2. • Day time.2.2. D. • F-16 flight lead acknowledges CAS request.4 Insurgents • Initial position: • Inside a building.

• Laser-guided bomb impacts on target or ground. The UML activity diagram below shows the basic interactions between the different actors in the scenario.2.3 Environmental Events • N/A.2.ANNEX D – EXAMPLE SCENARIO “CLOSE AIR SUPPORT” • Attacking F-16 releases laser-guided bomb. D-4 STO-TR-MSG-086-Part-II . • Laser-guided bomb acquires laser signal. Figure D-3: Scenario Interactions Between Different Actors. • FAC team laser operator illuminates target with the laser designator. D.

When describing the course of events. Any detail that is not included in the conceptual scenario will have to be determined by the developer producing the executable scenario. since that eases the task to transform a conceptual scenario into an executable scenario. The required amount of detail should be balanced for each specific scenario. On the other hand. Specifying them in more detail helped with the development of the conceptual model. STO-TR-MSG-086-Part-II D-5 . One variant situated the close air support mission in a training context.3 Termination Criteria • Weapon has detonated and damage has been assessed. if different variants of the same scenario are used. ANNEX D – EXAMPLE SCENARIO “CLOSE AIR SUPPORT” D. while the other variant put it in a mission rehearsal context. as much detail as possible should be provided.3 DISCUSSION Compared to the other example scenario. it might be useful to make the conceptual scenario more generic. the conceptual scenario does not provide very detailed initial position and related information of the different units. As a result of this. D. since that allows usage of the same conceptual scenario for deriving multiple executable scenarios.2. the different interactions have been described slightly more detailed than the other example scenario. two variants of the same scenario were used in a real-world project. This has been done because the different interactions going on between the entities in the scenario were an important aspect in the project the scenario comes from. This section discusses why this decision has been made. On one hand. this example has chosen a different level of detail to describe certain elements of the conceptual scenario. In the specific case of this example scenario.

ANNEX D – EXAMPLE SCENARIO “CLOSE AIR SUPPORT” D-6 STO-TR-MSG-086-Part-II .

g. STO-TR-MSG-086-Part-II . reliably achieving high- quality distributed simulations requires to also consider more abstract questions regarding pragmatic. Further Reference 4. 8. Abstract Simulation interoperability is most often considered to be a technical problem (e. France 6. Pages Multiple 88 12. MSG-086 analyzed 46 interoperability issues in total and categorized these issues into nine issue groups. “How is aggregation and disaggregation treated by different simulation systems?”. the Exploratory Team ET-027 identified 63 major issues which limit “true” simulation interoperability. REPORT DOCUMENTATION PAGE 1. its influence on simulation interoperability as well as possible solution approaches and already existing work in the specific problem area. In 2010. Author(s)/Editor(s) 9. Distribution Statement There are no restrictions on the distribution of this document.. MSG-086 “Simulation Interoperability” was tasked to analyze the ET-027 interoperability issues in order to recommend and prototype information products augmenting the DSEEP to mitigate or obviate the identified issues.g. Presented at/Sponsored by Part of the Final Report of MSG-086. dynamic and conceptual issues (e. Information about the availability of this and other STO unclassified publications is given on the back cover. F-92201 Neuilly-sur-Seine Cedex. Recipient’s Reference 2. Title Guideline on Scenario Development for (Distributed) Simulation Environments 7. Detailed descriptions of all interoperability issues have been developed specifying the original problem. Originator’s References 3. “Does every system support the same HLA standard and which RTI should we use?”) or semantic problem (e. 13. Based on the identified interoperability issues.g.. Yet. Security Classification of Document STO-TR-MSG-086-Part-II ISBN AC/323(MSG-086)TP/562 978-92-837-0201-2 PUBLIC RELEASE 5. “How do we map different object models onto each other?”). MSG-086 developed a “Guideline on Scenario Development for (Military) Simulation Environments” to overcome scenario-related interoperability issues.. Date Multiple January 2015 10. Author’s/Editor’s Address 11. In 2009. “Do different simulation systems interpret Rules of Engagement in the same way?”). Originator Science and Technology Organization North Atlantic Treaty Organization BP 25. Keywords/Descriptors DSEEP Levels of conceptual interoperability model Simulation Interoperability 14.

STO-TR-MSG-086-Part-II .

R. RTO ou AGARD doivent comporter la dénomination « STO ». Drumul Taberei Street CANADA ITALIE Sector 6 DSIGST 2 – Gérant des publications (S et T) Centro Gestione Conoscenza 061353 Bucharest Recherche et développement pour la défense Canada Secretariat General of Defence Ministère de la Défense nationale National Armaments Directorate ROYAUME-UNI 101 Colonel By Drive. sur la liste d’envoi. 2750 Ballerup Norwegian Defence Research M. « RTO » ou « AGARD » selon le cas.int STO NON CLASSIFIEES Les publications de l’AGARD. Ontario K1A 0K2 00187 Roma Services Building 247 DANEMARK LUXEMBOURG Porton Down. Wetherby National Research Council Acquisitions West Yorkshire LS23 7BQ Montreal Road.99 • E-mail mailbox@cso. 1000 Bruxelles Holargos. vous pouvez consulter notre site Web (http://www. suivi du numéro de série. RTO ou AGARD doivent comporter la dénomination « STO ».B. telles que le titre et la date de publication sont souhaitables.R. Les demandes de documents STO. Des références bibliographiques complètes ainsi que des résumés des publications STO. Les publications de la STO. ou simplement celles qui concernent certains Panels.002 1000 Ljubljana Sakala 1 4800 PA Breda Tallinn 15094 TURQUIE POLOGNE Milli Savunma Bakanlığı (MSB) ETATS-UNIS Centralna Biblioteka Wojskowa ARGE ve Teknoloji Dairesi Defense Technical Information Center ul. Des informations analogues. Building M-55 ROYAUME-UNI Ottawa. Distribučné a Establishment informačné stredisko STO ESPAGNE Attn: Biblioteket Demänová 393 SDGTECIN (DGAM) P. Kingman Road 04-041 Warszawa 06650 Bakanliklar – Ankara Fort Belvoir. Ontario K1A 0S2 CANADA Les demandes de documents STO. National STO Coordinator Directorate. Box 25 031 06 Liptovský Mikuláš 6 C/ Arturo Soria 289 NO-2007 Kjeller Madrid 28033 SLOVENIE PAYS-BAS Ministry of Defence ESTONIE Royal Netherlands Military Central Registry for EU & NATO Estonian Ministry of Defence Academy Library Vojkova 55 Estonian National Coordinator for NATO STO P.O. Des informations analogues.61. « RTO » ou « AGARD » selon le cas. Box 90.O. telles que le titre est la date de publication sont souhaitables. RTO et AGARD figurent dans le « NTIS Publications Database » (http://www. Ostrobramska 109 Başkanlığı 8725 John J. Štefánika.int/) et vous abonner à ce service.ntis. Si vous souhaitez recevoir une notification électronique de la disponibilité des rapports de la STO au fur et à mesure de leur publication.A. Research Directorate CZ Distribution Information Centre Royal Military Academy – Campus Renaissance Fakinos Base Camp. de la RTO et de la STO peuvent parfois être obtenues auprès des centres nationaux de distribution indiqués ci-dessous.22. NORTH ATLANTIC TREATY ORGANIZATION SC ENCE AND TECHNOLOGY ORGANIZATION BP 25 DIFFUSION DES PUBLICATIONS F-92201 NEUILLY-SUR-SEINE CEDEX • FRANCE Télécopie 0(1)55. Si vous souhaitez recevoir toutes les publications de la STO. 25 Centre 1606 Sofia H-1885 Budapest Armaments Department 9-11. 6 CBS – F002 Via XX Settembre 123/A Dstl Knowledge and Information Ottawa. Salisbury SP4 0JQ Danish Acquisition and Logistics Organization Voir Belgique (DALO) SLOVAQUIE Lautrupbjerg 1-5 NORVEGE Akadémia ozbrojených síl gen. D-53229 Bonn BP 72 Alfragide 92322 Châtillon Cedex P-2720 Amadora BELGIQUE Royal High Institute for Defence – KHID/IRSD/RHID GRECE (Correspondant) REPUBLIQUE TCHEQUE Management of Scientific & Technological Research Defence Industry & Research General Vojenský technický ústav s.gov).G.N. 1020 Mladoboleslavská 944 Renaissancelaan 30. VA 22060-6218 AGENCES DE VENTE The British Library Document Canada Institute for Scientific and Supply Centre Technical Information (CISTI) Boston Spa. S. soit au nom de votre organisation. vous pouvez demander d’être inclus soit à titre personnel.T. suivie du numéro de série (par exemple AGARD-AG-315).p.nato. (ISP) Estado Maior da Força Aérea Fachinformationszentrum der Bundeswehr (FIZBw) 29. Avenue de la Division Leclerc SDFA – Centro de Documentação Gorch-Fock-Straße 7. de la RTO et de l’AGARD sont également en vente auprès des agences de vente indiquées ci-dessous. for Defence.sto.O. CENTRES DE DIFFUSION NATIONAUX ALLEMAGNE FRANCE PORTUGAL Streitkräfteamt / Abteilung III O. Zvetan Lazarov” Development and Logistics Agency Romanian National Distribution Blvd “Totleben” 34 P.E.nato. . Athens PO Box 18 197 06 Praha 9 BULGARIE HONGRIE Ministry of Defence Hungarian Ministry of Defence ROUMANIE Defence Institute “Prof.

RTO or AGARD documents should include the word ‘STO’. Štefánika. Box 90.99 • E-mail mailbox@cso. Wetherby National Research Council Acquisitions West Yorkshire LS23 7BQ Montreal Road. they may be willing to include you (or your Organisation) in their distribution. Kingman Road 92322 Châtillon Cedex 04-041 Warszawa Fort Belvoir. Salisbury SP4 0JQ FRANCE POLAND UNITED STATES O.22.nato. as appropriate.O. or just those relating to one or more specific STO Panels. Avenue de la Division Leclerc – BP 72 ul. followed by the serial number (for example AGARD-AG-315). RTO or AGARD documents should include the word ‘STO’. 25 informačné stredisko STO Defence Research and Development Canada H-1885 Budapest Demänová 393 Department of National Defence 031 06 Liptovský Mikuláš 6 101 Colonel By Drive.002 Milli Savunma Bakanlığı (MSB) 2750 Ballerup 4800 PA Breda ARGE ve Teknoloji Dairesi Başkanlığı 06650 Bakanliklar – Ankara ESTONIA NORWAY Estonian Ministry of Defence Norwegian Defence Research UNITED KINGDOM Estonian National Coordinator for NATO STO Establishment. ‘RTO’ or ‘AGARD’.nato. (ISP) Centralna Biblioteka Wojskowa Defense Technical Information Center 29. RTO and AGARD reports may also be purchased from the Sales Agencies listed below.int STO PUBLICATIONS AGARD.A. STO. Research Directorate 9-11.O. 1020 Sector 6 Defence Institute “Prof.B.O. as appropriate. 6 CBS – F002 ITALY Ottawa. Collateral information such as title and publication date is desirable. Box 25 Building 247 Tallinn 15094 NO-2007 Kjeller Porton Down.gov). Ontario K1A 0K2 Centro Gestione Conoscenza SLOVENIA Secretariat General of Defence Ministry of Defence CZECH REPUBLIC National Armaments Directorate Central Registry for EU & NATO Vojenský technický ústav s.p. National STO Coordinator Gorch-Fock-Straße 7 P-2720 Amadora Royal Military Academy – Campus Renaissance D-53229 Bonn Renaissancelaan 30 ROMANIA 1000 Brussels GREECE (Point of Contact) Romanian National Distribution Centre Defence Industry & Research General Armaments Department BULGARIA Directorate. If you wish to receive electronic notification of STO reports as they are published. Building M-55 UNITED KINGDOM Ottawa.R. S. please visit our website (http://www. Full bibliographical references and abstracts of STO.E.T. followed by the serial number. ‘RTO’ or ‘AGARD’. Athens 061353 Bucharest Blvd “Totleben” 34 1606 Sofia HUNGARY SLOVAKIA Hungarian Ministry of Defence Akadémia ozbrojených síl gen CANADA Development and Logistics Agency M.61. NORTH ATLANTIC TREATY ORGANIZATION SCIENCE AND TECHNOLOGY ORGANIZATION BP 25 DISTRIBUTION OF UNCLASSIFIED F-92201 NEUILLY-SUR-SEINE CEDEX • FRANCE Télécopie 0(1)55. RTO & STO publications are sometimes available from the National Distribution Centres listed below. Ontario K1A 0S2 CANADA Requests for STO. Zvetan Lazarov” Holargos. NATIONAL DISTRIBUTION CENTRES BELGIUM GERMANY PORTUGAL Royal High Institute for Defence – KHID/IRSD/ Streitkräfteamt / Abteilung III Estado Maior da Força Aérea RHID Fachinformationszentrum der SDFA – Centro de Documentação Management of Scientific & Technological Bundeswehr (FIZBw) Alfragide Research for Defence.G. ISBN 978-92-837-0201-2 . If you wish to receive all STO reports. RTO and AGARD publications are given in “NTIS Publications Database” (http://www.R. Requests for STO.ntis.sto. Ostrobramska 109 8725 John J. Drumul Taberei Street Ministry of Defence Fakinos Base Camp.int/) from where you can register for this service. Attn: Biblioteket Dstl Knowledge and Information Services Sakala 1 P. VA 22060-6218 SALES AGENCIES The British Library Document Canada Institute for Scientific and Supply Centre Technical Information (CISTI) Boston Spa. Distribučné a DSTKIM 2 – S&T Publications Manager P. Collateral information such as title and publication date is desirable. Via XX Settembre 123/A Vojkova 55 CZ Distribution Information Centre 00187 Roma 1000 Ljubljana Mladoboleslavská 944 PO Box 18 LUXEMBOURG SPAIN 197 06 Praha 9 See Belgium SDGTECIN (DGAM) C/ Arturo Soria 289 DENMARK NETHERLANDS Madrid 28033 Danish Acquisition and Logistics Organization Royal Netherlands Military (DALO) Academy Library TURKEY Lautrupbjerg 1-5 P.N.