NATO STANDARD AMSP-04 NATO Education and Training …€¦ · Version 1 NATO EDUCATION AND TRAINING NETWORK FEDERATION ARCHITECTURE AND FEDERATION OBJECT MODEL DESIGN, which has been

NATO STANDARD

AMSP-04

NATO Education and Training Network Federation Architecture and FOM

Design (NETN FAFD)

Edition (A) Version 1.0 (Draft 3)

October 2017

NORTH ATLANTIC TREATY ORGANIZATION

ALLIED MODELLING AND SIMULATION PUBLICATION

Published by the NATO STANDARDIZATION OFFICE (NSO)

© NATO/OTAN

INTENTIONALLY BLANK

III Edition (A) Version 1.0 (Draft 3)

NORTH ATLANTIC TREATY ORGANIZATION (NATO)

NATO STANDARDIZATION OFFICE (NSO)

NATO LETTER OF PROMULGATION

Oct 2017 1. The enclosed Allied Modelling and Simulation Publication AMSP-04, Edition A, Version 1 NATO EDUCATION AND TRAINING NETWORK FEDERATION ARCHITECTURE AND FEDERATION OBJECT MODEL DESIGN, which has been approved by the nations in the NATO MODELLING AND SIMULATION GROUP, is promulgated herewith. The recommendation of nations to use this publication is recorded in STANREC 4800.

2. AMSP-04, Edition A, Version 1 is effective upon receipt.

3. No part of this publication may be reproduced, stored in a retrieval system, used commercially, adapted, or transmitted in any form or by any means, electronic, mechanical, photo-copying, recording or otherwise, without the prior permission of the publisher. With the exception of commercial sales, this does not apply to member or partner nations, or NATO commands and bodies.

4. This publication shall be handled in accordance with C-M(2002)60.

Director, NATO Standardization Office

Edvardas MAŽEIKIS Major General, LTUAF

IV Edition (A) Version 1.0 (Draft 3)

INTENTIONALLY BLANK

V Edition (A) Version 1.0 (Draft 3)

ACKNOWLEDGEMENTS

The following individuals participated in the NATO Modelling and Simulation (NMSG) Task Group MSG-068 FAFD subgroup and contributed to the development of the NETN FAFD v1.0:

Amy Grom, André Geiger, Andy Bowers, Angel San Jose, Anthony Jones, Bharat Patel, Birol Güvenç, Björn Löfstrand, Brian Gregg, Cem Kumsal, Christian Mårtensson, Clive Wood, Darren McFarlane, Dieter Steinkamp, Duncan E Rogers, Elena Bravo, Ercan Atalay, Erdal Cayirci, Erich Schmid, Farshad Moradi, Frank Bertling, Franz Schubert, Fredrik Jonsson, Gareth M. Pugh, Gokay Sursal, Gunnar Öhlund, Gustav Schulz, Göran Bergström, Hans Jense, Heliodoro Ruiperez, Herbert Tietje, Ionel Vlasie, Jacek Sumislawski, James Boulet, Jan van Geest, Jean-Pierre Faye, Jochen Siebeneicher, John Loughhead, Jose Mimbrero, Jose Ruiz, Juan José Ruiz Pérez, Karl-Heinz Neumann, Klaus Greiwe, Konradin Keller, Lars Lindberg, Laurent Lesage, Leif Almgren, Lennart Olsson, Lesley Jacobs, Manuel Dogaru, Mark Shelford, Martin Eklöf, Miles Patterson, Mimi Nguyen, Ola Wall, Oliver Henne, Orlin Nikolov, Patricio Jimenez, Per-Philip Sollin, Petar Savkov Petrov, Peter Meyer zu Drewer, Pontus Svenson, Rachid El Abdouni Khayari, Robert B. Kean, Robert Paledau, Roger Jansen, Ron Caprio, Sergio Galán, Stephane Devaud, Steven Blackstone, Søren Larsen, Thomas Orichel, Tom van den Berg, Torbjörn Hultén, Ulf Björkman, Ulf Jinnestrand, Vladimir Manda, Wim Huiskamp, Xavier Coste.

The following individuals participated in the NATO Modelling and Simulation (NMSG) Task Group MSG-106 TEK subgroup and contributed NETN FAFD v2.0:

Adam Brook, Amy Grom, Andrew Poulter, Andy Bowers, Antony Hubervic, Bharat Patel, Björn Löfstrand, Brian Horn, Ceri Pritchard, Christopher Struselis ,David Desert, Erik Solum, Patrice Guillou, Jack Bramhill, Jeppe Nyløkke, Jerome Martinet, Johannes Mulder, José Ruiz, Kay Roos, Kjell Magne Fauske, Lennart Olsson, Lubomir Chylik, Malcolm Pigott, Martin Jones, Michael Jobson, Michael Mifsud, Morten Ottesen, Nathan Newton, Neil Morris, Neil Smith, Nico de Reus, Nicolas Pitrat, Nils Smedberg, Orlin Nikolov, Per-Philip Sollin, Peter Jackson, Reinhard Herzog, Robert Wittman, Roger Jansen, Rolf Engsvang, Russell Mills, Simon Morris, Stefan Vrieler, Stephen Ballard, Stuart Robin, Tom van den Berg, Xavier Cuneo.

VI Edition (A) Version 1.0 (Draft 3)

INTENTIONALLY BLANK

VII Edition (A) Version 1.0 (Draft 3)

EXECUTIVE SUMMARY

The NATO Education and Training Network (NETN) Federation Architecture and FOM (Federation Object Model) Design (FAFD) document is a reference document intended to provide architecture and design guidance for developing distributed simulation and training systems in the context of Computer Assisted Exercises (CAX). The guidance provided by the FAFD has been developed to support the NETN vision and is applicable to NATO CAX, national CAX and to some extent to distributed modelling and simulation in general.

The FAFD focuses mainly on technical interoperability issues in distributed simulation. It is not a complete guide on how to design a distributed simulation to support CAX but will provide key architecture and design patterns and proposed solutions. The FAFD provides architecture and design guidelines on network infrastructure, simulation infrastructure, simulation data exchange models (SDEM) and how to design a robust, scalable, interoperable and high performing federation of distributed simulation to support CAX. The document also addresses domain specific requirements of modelling aspects of units, platforms, activities and other events. Areas specifically included in this version of the NETN FAFD are CBRN, Logistics, and NETN compatibility with RPR-FOM and German Maritime FOM (GMF).

Key recommendations include:

a. Use of NATO STANAG 4603 (High Level Architecture);

b. Use of NATO NETN FOM and associated standard and NATO NETN developed FOM Modules;

c. Use of RPR-FOM v2.0 (Modularized) and German Maritime FOM (GMF);

d. Use of Transfer of Modelling Responsibilities Design Pattern;

e. Use of MSDL to support Initialization;

f. Use of C-BML to support Simulation-to-C2 interoperability; and

g. Use of Multi-Resolution Modelling.

VIII Edition (A) Version 1.0 (Draft 3)

INTENTIONALLY BLANK

IX Edition (A) Version 1.0 (Draft 3)

TABLE OF CONTENTS

Chapter 1 INTRODUCTION .................................................................................... 1-1 1.1. PURPOSE ................................................................................................. 1-1 1.2. BACKGROUND ......................................................................................... 1-1 1.3. SUMMARY OF CHANGES ....................................................................... 1-2 1.4. REFERENCES .......................................................................................... 1-2 1.5. OUTLINE ................................................................................................... 1-4 Chapter 2 NETN FEDERATION ARCHITECTURE AND DESIGN .......................... 2-1 2.1. CONCEPTS .............................................................................................. 2-1 2.2. NETWORK INFRASTRUCTURE .............................................................. 2-2 2.2.1. Network Virtualization ........................................................................ 2-2 2.2.2. Site Identification ................................................................................ 2-2 2.3. SIMULATION INFRASTRUCTURE ........................................................... 2-3 2.3.1. Mixed Infrastructure ........................................................................... 2-3 2.3.2. Federate Compliance Verification and Certification ........................... 2-4 2.4. NETN FOM................................................................................................ 2-5 2.5. NETN FEDERATION DESIGN .................................................................. 2-6 2.5.1. Initialization ........................................................................................ 2-6 2.5.2. Transfer of Modelling Responsibility .................................................. 2-7 2.5.3. Representation of Aggregate and Physical Entities ........................... 2-7 2.5.4. Multi-Resolution Modelling ................................................................. 2-8 2.5.5. Simulation-C2 System Interoperability ............................................... 2-8 2.5.6. Service Oriented Modelling and Simulation ....................................... 2-9 2.5.7. Logistics ........................................................................................... 2-10 2.5.8. CBRN ............................................................................................... 2-11 2.5.9. Maritime Task ................................................................................... 2-11 Chapter 3 Aggregate and Physical Entity Representation ....................................... 3-1 3.1. OVERVIEW ............................................................................................... 3-1 3.2. NETN ATTRIBUTES ................................................................................. 3-3 3.2.1. Instance Identification ........................................................................ 3-3 3.2.1.1. Instance Identification in the RTI ................................................. 3-3 3.2.1.2. Instance Identification in the RPR FOM ...................................... 3-3 3.2.1.3. Instance Identification in the NETN FOM .................................... 3-3 3.2.2. Entity Name........................................................................................ 3-4 3.2.3. Status ................................................................................................. 3-4 3.2.4. Activity ................................................................................................ 3-4 3.2.5. On-Board Entities ............................................................................... 3-5 3.2.6. NETN Aggregate Attributes ................................................................ 3-5 Chapter 4 Initialization ............................................................................................. 4-1 4.1. NETN ORBAT AND SCENARIO SETTINGS FORMAT ............................ 4-1 4.2. INITIAL ALLOCATION OF MODELLING RESPONSIBILITIES ................. 4-3 4.3. UNIT AND EQUIPMENT TYPE IDENTIFICATION ................................... 4-4 4.4. ORGANIZATION DESCRIPTION .............................................................. 4-6 4.5. DESCRIPTION OF HUMANS ................................................................... 4-8 4.6. EMBARKED UNITS ................................................................................ 4-10

X Edition (A) Version 1.0 (Draft 3)

Chapter 5 Transfer of Modelling Responsibilities .................................................... 5-1 5.1. TMR PATTERN CONCEPT ...................................................................... 5-1 5.1.1. Introduction ........................................................................................ 5-1 5.1.2. TMR Interactions and HLA Services .................................................. 5-1 5.2. TMR PATTERN USAGE ........................................................................... 5-2 5.2.1. TMR Pattern Rules ............................................................................. 5-2 5.2.2. Transfer Type ..................................................................................... 5-3 5.2.3. TMR Interactions ................................................................................ 5-3 5.2.3.1. Interaction: TMR ......................................................................... 5-3 5.2.3.2. Interaction: TMR_RequestTransferModellingResponsibility........ 5-3 5.2.3.3. Interaction: TMR_OfferTransferModellingResponsibility ............. 5-5 5.2.3.4. Interaction: TMR_InitiateTransferModellingResponsibility .......... 5-6 5.2.3.5. Interaction: TMR_CancelRequest ............................................... 5-7 5.2.3.6. Interaction: TMR_TransferResult ................................................ 5-7 5.2.4. Use Cases.......................................................................................... 5-7 5.2.4.1. Acquire Request and a Positive Offer ......................................... 5-8 5.2.4.2. Transfer Request and a Negative Offer ...................................... 5-8 5.2.4.3. Request and Cancel Request ..................................................... 5-9 5.2.4.4. Request, Positive Offer and Cancel Request .............................. 5-9 5.2.4.5. Divest Request and Positive Offer .............................................. 5-9 5.2.4.6. Divest Request and Positive Offer, Race Condition .................. 5-10 5.2.4.7. Divest Request, Positive Offer, Cancel Request After HLA Ownership Negotiation Started ................................................. 5-11 5.2.4.8. Initiate from External Source, Acquire Request, Positive Offer . 5-12 5.2.4.9. Initiate from External Source, Divest Request, Positive Offer ... 5-13 5.2.4.10. Initiate from External Source, Acquire Request, Positive Offer and Cancel Request ................................................................. 5-13 5.2.4.11. Initiate from External Source, AcquireWithoutNegotiating Request..................................................................................... 5-14 Chapter 6 MULTI-RESOLUTION MODELLING ....................................................... 6-1 6.1. MRM PATTERN CONCEPT...................................................................... 6-1 6.1.1. Modelling Responsibility ..................................................................... 6-1 6.1.2. High Resolution Units ......................................................................... 6-1 6.1.3. MRM Service Provider ....................................................................... 6-1 6.1.4. Aggregate Dynamic Attribute Update Responsibility .......................... 6-2 6.1.5. High Resolution Dynamic Attribute Update Responsibility ................. 6-3 6.1.6. Aggregate Federate ........................................................................... 6-3 6.1.7. Higher Resolution Federate ............................................................... 6-3 6.1.8. Trigger Federate ................................................................................ 6-3 6.1.9. Identification ....................................................................................... 6-3 6.1.10. MRM Interactions ............................................................................... 6-4 6.2. DISAGGREGATION .................................................................................. 6-4 6.3. AGGREGATION ........................................................................................ 6-6 6.4. MRM TRIGGER ........................................................................................ 6-7 6.5. UNABLE TO COMPLY .............................................................................. 6-8 Chapter 7 SIMULATION-C2 INTEROPERABILITY ................................................. 7-1

XI Edition (A) Version 1.0 (Draft 3)

7.1. INTRODUCTION ....................................................................................... 7-1 7.2. C-BML FOM MODULE .............................................................................. 7-3 7.2.1. Module Objects .................................................................................. 7-3 7.2.2. Module Interactions ............................................................................ 7-4 7.3. LOW LEVEL BML FOM MODULE ............................................................ 7-4 7.3.1. Module Objects .................................................................................. 7-5 7.3.2. Module Interactions ............................................................................ 7-5 Chapter 8 SERVICE CONSUMER-PROVIDER PATTERN ..................................... 8-1 8.1. GENERAL APPROACH ............................................................................ 8-1 8.2. SERVICE CONSUMER ............................................................................. 8-3 8.3. SERVICE PROVIDER ............................................................................... 8-5 Chapter 9 LOGISTICS SIMULATION ...................................................................... 9-1 9.1. SCOPE ...................................................................................................... 9-1 9.2. DEFINITIONS ............................................................................................ 9-2 9.2.1. Facilities ............................................................................................. 9-2 9.2.2. Materials ............................................................................................ 9-2 9.2.3. Appointment Data .............................................................................. 9-3 9.3. NETN LOGISTICS FOM ........................................................................... 9-3 9.4. SUPPLY PATTERN .................................................................................. 9-5 9.4.1. Supply Service ................................................................................... 9-6 9.4.2. Storage Service ................................................................................ 9-10 9.5. MAINTENANCE PATTERN..................................................................... 9-14 9.5.1. Repair Service .................................................................................. 9-14 9.5.2. Repair Types .................................................................................... 9-17 9.6. TRANSPORT PATTERN ........................................................................ 9-17 9.6.1. Disaggregation of Units for Transportation ....................................... 9-23 9.6.2. Warfare Interactions Against Transporter ........................................ 9-23 9.6.3. Embarkment Service ........................................................................ 9-24 9.6.4. Disembarkment Service ................................................................... 9-25 9.6.5. Transport Services and Attrition ....................................................... 9-26 9.6.6. Scenario Initialization Phase ............................................................ 9-27 Chapter 10 CHEMICAL, BIOLOGICAL, RADIOLOGICAL AND NUCLEAR (CBRN) SIMULATION ........................................................................................... 10-1 10.1. INTRODUCTION ..................................................................................... 10-1 10.2. DESIGN OVERVIEW .............................................................................. 10-1 10.3. CBRN SOURCE RELEASE MODELLING .............................................. 10-1 10.3.1. CBRN_Release ................................................................................ 10-1 10.3.2. CBRN Warheads on Conventional Munitions................................... 10-2 10.4. DETECTOR MODELLING ...................................................................... 10-2 10.4.1. CBRN_Detector ............................................................................... 10-3 10.4.2. CBRN_Sensor .................................................................................. 10-3 10.5. CBRN EFFECTS MODELLING ............................................................... 10-3 10.5.1. Lifeform CBRN Effects Modelling ..................................................... 10-4 10.5.1.1. CBRN_Human .......................................................................... 10-4 10.5.1.2. CBRN_Casualty ........................................................................ 10-4 10.5.1.3. CBRNDamageEnum8 ............................................................... 10-4

XII Edition (A) Version 1.0 (Draft 3)

10.5.2. Platform CBRN Effects Modelling .................................................... 10-5 10.5.2.1. CBRN Platforms ........................................................................ 10-5 10.5.2.2. CBRN_PlatformUpdate ............................................................. 10-5 10.6. PROTECTIVE MEASURES MODELLING .............................................. 10-5 10.6.1. COLPRO .......................................................................................... 10-6 10.6.2. DecontaminationStation ................................................................... 10-6 10.6.3. CBRN_FacilityUpdate ...................................................................... 10-6 10.6.4. COLPROUpdate .............................................................................. 10-6 10.6.5. DecontaminationStationUpdate ........................................................ 10-6 10.6.6. IPECommand ................................................................................... 10-7 10.6.7. CBRN_TreatmentCommand ............................................................ 10-7 10.7. HAZARD AREA MODELLING ................................................................. 10-7 10.7.1. ATP45HazardArea ........................................................................... 10-7 10.7.2. ProbabilityHazardContourGroup ...................................................... 10-7 10.7.3. RawDataHazardContourGroup ........................................................ 10-8 Chapter 11 NETN AND GMF COMPATIBILITY .................................................... 10-1 11.1. INTRODUCTION ..................................................................................... 11-1 11.2. BASE MODULE (GMF_INTERCHANGE) ............................................... 11-1 11.3. UNDERWATER ACOUSTICS EMISSIONS (GMF_ACOUSTICS) .......... 11-2 11.4. COMMUNICATION (GMF_COMM) ......................................................... 11-2 11.5. EMITTER SIGNALS AND EMITTER PARAMETRIC DATA (GMF_EMITTER) .................................................................................... 11-2 11.6. SONOBUOY INTEROPERABILITY (GMF_SONOBUOY) ...................... 11-2 11.7. TRANSPONDER (GMF_TRANSPONDER) ............................................ 11-3 Chapter 12 REFERENCES ................................................................................... 12-1 Annex A NETN FAFD FOM MODULES ............................................................. A-1 A.1. MODULE NETN-BASE_v1.0.2 .................................................................. A-1 A.1.1. Datatypes ........................................................................................... A-3 A.1.1.1. Simple Datatypes ........................................................................ A-3 A.1.1.2. Enumerated Datatypes ............................................................... A-4 A.1.1.3. Array Datatypes ........................................................................ A-19 A.1.1.4. Fixed Record Datatypes ........................................................... A-21 A.2. MODULE NETN-AGGREGATE_v1.0.4 ................................................... A-23 A.2.1. Object Classes ................................................................................. A-24 A.2.1.1. NETN_Aggregate ...................................................................... A-24 A.2.2. Datatypes ......................................................................................... A-35 A.2.2.1. Simple Datatypes ...................................................................... A-35 A.2.2.2. Enumerated Datatypes ............................................................. A-37 A.2.2.3. Array Datatypes ........................................................................ A-42 A.2.2.4. Fixed Record Datatypes ........................................................... A-42 A.3. MODULE NETN-PHYSICAL_v1.1.2 ........................................................ A-48 A.3.1. Object Classes ................................................................................. A-50 A.3.1.1. NETN_Aircraft ........................................................................... A-51 A.3.1.2. NETN_AmphibiousVehicle ........................................................ A-64 A.3.1.3. NETN_GroundVehicle .............................................................. A-77 A.3.1.4. NETN_MultiDomainPlatform ..................................................... A-90

XIII Edition (A) Version 1.0 (Draft 3)

A.3.1.5. NETN_Spacecraft ................................................................... A-104 A.3.1.6. NETN_SubmersibleVehicle..................................................... A-117 A.3.1.7. NETN_SurfaceVessel ............................................................. A-130 A.3.1.8. NETN_NonHuman .................................................................. A-143 A.3.1.9. NETN_Human ......................................................................... A-154 A.3.1.10. NETN_CulturalFeature ........................................................... A-164 A.4. MODULE CBRN_v1.1.9 ........................................................................ A-175 A.4.1. Object Classes ............................................................................... A-178 A.4.1.1. ATP45HazardArea .................................................................. A-179 A.4.1.2. COLPRO ................................................................................. A-181 A.4.1.3. DecontaminationStation .......................................................... A-191 A.4.1.4. CBRN_Human ........................................................................ A-202 A.4.1.5. CBRN_Aircraft ........................................................................ A-213 A.4.1.6. CBRN_AmphibiousVehicle ..................................................... A-227 A.4.1.7. CBRN_GroundVehicle ............................................................ A-240 A.4.1.8. CBRN_MultiDomainPlatform ................................................... A-254 A.4.1.9. CBRN_Spacecraft ................................................................... A-267 A.4.1.10. CBRN_SubmersibleVehicle .................................................... A-281 A.4.1.11. CBRN_SurfaceVessel ............................................................. A-294 A.4.1.12. CBRN_Detector ...................................................................... A-308 A.4.1.13. CBRN_Sensor ........................................................................ A-318 A.4.1.14. ProbabilityHazardContourGroup ............................................. A-329 A.4.1.15. RawDataHazardContourGroup ............................................... A-330 A.4.2. Interaction Classes ......................................................................... A-333 A.4.2.1. HLAinteractionRoot ................................................................. A-334 A.4.2.2. CBRN_Casualty ...................................................................... A-334 A.4.2.3. CBRN_DetectorAlarm ............................................................. A-335 A.4.2.4. CBRN_PlatformUpdate ........................................................... A-335 A.4.2.5. CBRN_Release ....................................................................... A-336 A.4.2.6. CBRN_SensorUpdate ............................................................. A-336 A.4.2.7. CBRN_FacilityUpdate ............................................................. A-337 A.4.2.8. COLPROUpdate ..................................................................... A-338 A.4.2.9. DecontaminationStationUpdate .............................................. A-338 A.4.2.10. IPECommand .......................................................................... A-339 A.4.2.11. CBRN_TreatmentCommand ................................................... A-339 A.4.3. Datatypes ....................................................................................... A-340 A.4.3.1. SimpleDatatypes ..................................................................... A-340 A.4.3.2. Enumerated Datatypes ........................................................... A-342 A.4.3.3. Array Datatypes ...................................................................... A-346 A.4.3.4. Fixed Record Datatypes ......................................................... A-348 A.5. MODULE NETN-SCP-BASE_v1.1.3 ..................................................... A-353 A.5.1. Object Classes ............................................................................... A-355 A.5.1.1. SCP_Facility ........................................................................... A-355 A.5.2. Interaction Classes ......................................................................... A-359 A.5.2.1. HLAinteractionRoot ................................................................. A-360 A.5.2.2. SCP_Service ........................................................................... A-360

XIV Edition (A) Version 1.0 (Draft 3)

A.5.2.3. SCP_RequestService ............................................................. A-361 A.5.2.4. SCP_OfferService ................................................................... A-362 A.5.2.5. SCP_AcceptOffer .................................................................... A-363 A.5.2.6. SCP_ServiceStarted ............................................................... A-364 A.5.2.7. SCP_ServiceComplete ........................................................... A-365 A.5.2.8. SCP_ServiceReceived ............................................................ A-366 A.5.2.9. SCP_RejectOffer .................................................................... A-367 A.5.2.10. SCP_CancelService ............................................................... A-368 A.5.2.11. SCP_ReadyToReceiveService ............................................... A-369 A.5.3. Datatypes ....................................................................................... A-370 A.5.3.1. Enumerated Datatypes ........................................................... A-370 A.5.3.2. Array Datatypes ...................................................................... A-371 A.5.3.3. Fixed Record Datatypes ......................................................... A-371 A.5.4. Notes .............................................................................................. A-372 A.6. MODULE NETN-REPAIR_v1.2.1 .......................................................... A-373 A.6.1. Interaction Classes ......................................................................... A-375 A.6.1.1. HLAinteractionRoot ................................................................. A-375 A.6.1.2. SCP_Service ........................................................................... A-376 A.6.1.3. SCP_RequestService ............................................................. A-376 A.6.1.4. RequestRepair ........................................................................ A-377 A.6.1.5. SCP_OfferService ................................................................... A-378 A.6.1.6. OfferRepair ............................................................................. A-379 A.6.1.7. SCP_ServiceComplete ........................................................... A-381 A.6.1.8. RepairComplete ...................................................................... A-381 A.6.1.9. SCP_ReadyToReceiveService ............................................... A-382 A.6.1.10. ReadyToReceiveRepair .......................................................... A-383 A.6.2. Datatypes ....................................................................................... A-384 A.6.2.1. Enumerated Datatypes ........................................................... A-384 A.6.2.2. Array Datatypes ...................................................................... A-388 A.6.2.3. Fixed Record Datatypes ......................................................... A-389 A.7. MODULE NETN-STORAGE_v1.2.2 ...................................................... A-390 A.7.1. Interaction Classes ......................................................................... A-392 A.7.1.1. HLAinteractionRoot ................................................................. A-392 A.7.1.2. SCP_Service ........................................................................... A-392 A.7.1.3. SCP_RequestService ............................................................. A-393 A.7.1.4. RequestStorage ...................................................................... A-394 A.7.1.5. SCP_OfferService ................................................................... A-395 A.7.1.6. OfferStorage ........................................................................... A-396 A.7.1.7. SCP_ServiceComplete ........................................................... A-397 A.7.1.8. StorageComplete .................................................................... A-398 A.7.1.9. SCP_ReadyToReceiveService ............................................... A-399 A.7.1.10. ReadyToReceiveStorage ........................................................ A-400 A.8. MODULE NETN-SUPPLY_v1.1.2 ......................................................... A-402 A.8.1. Interaction Classes ......................................................................... A-404 A.8.1.1. HLAinteractionRoot ................................................................. A-404 A.8.1.2. SCP_Service ........................................................................... A-405

XV Edition (A) Version 1.0 (Draft 3)

A.8.1.3. SCP_RequestService ............................................................. A-405 A.8.1.4. RequestSupply ........................................................................ A-406 A.8.1.5. SCP_OfferService ................................................................... A-407 A.8.1.6. OfferSupply ............................................................................. A-408 A.8.1.7. SCP_ServiceComplete ........................................................... A-410 A.8.1.8. SupplyComplete ...................................................................... A-410 A.8.1.9. SCP_ReadyToReceiveService ............................................... A-411 A.8.1.10. ReadyToReceiveSupply ......................................................... A-412 A.9. MODULE NETN-TRANSPORT_v1.1.2 ................................................. A-414 A.9.1. Interaction Classes ......................................................................... A-415 A.9.1.1. HLAinteractionRoot ................................................................. A-416 A.9.1.2. SCP_Service ........................................................................... A-416 A.9.1.3. SCP_RequestService ............................................................. A-417 A.9.1.4. RequestTransport ................................................................... A-418 A.9.1.5. SCP_OfferService ................................................................... A-419 A.9.1.6. OfferTransport ......................................................................... A-420 A.9.1.7. TransportEmbarkmentStatus .................................................. A-421 A.9.1.8. TransportDisembarkmentStatus ............................................. A-422 A.9.1.9. TransportDestroyedEntities..................................................... A-423 A.9.2. Datatypes ....................................................................................... A-424 A.9.2.1. Enumerated Datatypes ........................................................... A-424 A.9.2.2. Fixed Record Datatypes ......................................................... A-424 A.9.2.3. Variant Record Datatypes ....................................................... A-425 A.10. MODULE TMR_v1.1.3 .......................................................................... A-426 A.10.1. Interaction Classes ......................................................................... A-428 A.10.1.1. HLAinteractionRoot ................................................................. A-429 A.10.1.2. TMR ........................................................................................ A-429 A.10.1.3. TMR_OfferTransferModellingResponsibility............................ A-430 A.10.1.4. TMR_InitiateTransferModellingResponsibility ......................... A-430 A.10.1.5. TMR_RequestTransferModellingResponsibility ...................... A-431 A.10.1.6. TMR_CancelRequest .............................................................. A-432 A.10.1.7. TMR_TransferResult ............................................................... A-433 A.10.2. Datatypes ....................................................................................... A-434 A.10.2.1. Simple Datatypes .................................................................... A-434 A.10.2.2. Enumerated Datatypes ........................................................... A-434 A.10.2.3. Array Datatypes ...................................................................... A-436 A.10.2.4. Fixed Record Datatypes ......................................................... A-437 A.10.3. User Supplied Tags ........................................................................ A-438 A.11. MODULE MRM_v1.1.1 .......................................................................... A-440 A.11.1. Interaction Classes ......................................................................... A-443 A.11.1.1. HLAinteractionRoot ................................................................. A-444 A.11.1.2. MRM_Object ........................................................................... A-444 A.11.1.3. MRM_DisaggregationRequest ................................................ A-445 A.11.1.4. MRM_DisaggregationResponse ............................................. A-446 A.11.1.5. MRM_AggregationRequest ..................................................... A-447 A.11.1.6. MRM_AggregationResponse .................................................. A-448

XVI Edition (A) Version 1.0 (Draft 3)

A.11.1.7. MRM_CancelRequest ............................................................. A-448 A.11.1.8. MRM_ActionComplete ............................................................ A-449 A.11.1.9. MRM_Trigger .......................................................................... A-450 A.11.1.10. MRM_TriggerResponse .......................................................... A-451 A.11.2. Datatypes ....................................................................................... A-452 A.11.2.1. Enumerated Datatypes .................................................................. A-452 A.12. MODULE NETN-HCBML_v1.1.1 ........................................................... A-454 A.12.1. Object Classes ............................................................................... A-455 A.12.1.1. MessageBML .......................................................................... A-455 A.12.1.2. OrderBML ............................................................................... A-456 A.12.1.3. RequestBML ........................................................................... A-458 A.12.2. Interaction Classes ......................................................................... A-459 A.12.2.1. HLAinteractionRoot ................................................................. A-459 A.12.2.2. Ack .......................................................................................... A-460 A.12.2.3. Report ..................................................................................... A-460 A.12.2.4. TaskReport ............................................................................. A-461 A.12.2.5. StatusReport ........................................................................... A-461 A.12.2.6. SituationReport ....................................................................... A-462 A.12.2.7. LogReport ............................................................................... A-463 A.12.3. Datatypes ....................................................................................... A-464 A.12.3.1. Enumerated Datatypes ........................................................... A-464 A.12.3.2. Array Datatypes ...................................................................... A-468 A.12.3.3. Fixed Record Datatypes ......................................................... A-470 A.12.4. Switches ......................................................................................... A-473 A.13. MODULE NETN-LBML_v1.1.0 .............................................................. A-475 A.13.1. Interaction Classes ......................................................................... A-477 A.13.1.1. HLAinteractionRoot ................................................................. A-478 A.13.1.2. LBMLMessage ........................................................................ A-478 A.13.1.3. LBMLTask ............................................................................... A-478 A.13.1.4. Move ....................................................................................... A-479 A.13.1.5. MoveToLocation ..................................................................... A-480 A.13.1.6. MoveToUnit ............................................................................. A-481 A.13.1.7. MoveIntoFormation ................................................................. A-482 A.13.1.8. FollowRoute ............................................................................ A-483 A.13.1.9. FollowUnit ............................................................................... A-484 A.13.1.10. TurnToHeading ....................................................................... A-485 A.13.1.11. TurnToOrientation ................................................................... A-486 A.13.1.12. VehicleMount .......................................................................... A-487 A.13.1.13. VehicleDismount ..................................................................... A-488 A.13.1.14. FireAtLocation ......................................................................... A-489 A.13.1.15. FireIndirectWM ........................................................................ A-490 A.13.1.16. FireAtUnit ................................................................................ A-491 A.13.1.17. FireDirectWM .......................................................................... A-492 A.13.1.18. Wait ......................................................................................... A-493 A.13.1.19. ChangeOrderedSpeed ............................................................ A-494 A.13.1.20. ChangeOrderedAltitude .......................................................... A-495

XVII Edition (A) Version 1.0 (Draft 3)

A.13.1.21. SetRulesOfEngagement ......................................................... A-496 A.13.1.22. LBMLTaskManagement .......................................................... A-497 A.13.1.23. CancelAllTasks ....................................................................... A-498 A.13.1.24. CancelSpecifiedTasks ............................................................ A-498 A.13.1.25. LBMLReport ............................................................................ A-499 A.13.1.26. StatusReport ........................................................................... A-500 A.13.1.27. TaskStatusReport ................................................................... A-500 A.13.1.28. PositionStatusReport .............................................................. A-501 A.13.1.29. DamageStatusReport ............................................................. A-502 A.13.1.30. FuelStatusReport .................................................................... A-502 A.13.1.31. AmmunitionStatusReport ........................................................ A-503 A.13.1.32. UnderAttackStatusReport ....................................................... A-504 A.13.1.33. ActivityStatusReport ................................................................ A-505 A.13.1.34. CurrentActivityStatusReport .................................................... A-505 A.13.1.35. NextActivityStatusReport ........................................................ A-507 A.13.1.36. SpotReport .............................................................................. A-508 A.13.1.37. ActivitiySpotReport .................................................................. A-509 A.13.1.38. CurrentActivitySpotReport....................................................... A-510 A.13.1.39. NextActivitySpotReport ........................................................... A-512 A.13.1.40. InSensorReport ....................................................................... A-513 A.13.1.41. InWeaponRangeReport .......................................................... A-514 A.13.2. Datatypes ....................................................................................... A-516 A.13.2.1. Simple Datatypes .................................................................... A-516 A.13.2.2. Enumerated Datatypes ........................................................... A-516 A.13.2.3. Array Datatypes ...................................................................... A-520 A.13.2.4. Fixed Record Datatypes ......................................................... A-521 Annex B NETN MSDL EXTENSIONS ................................................................ B-1 Annex C LIST OF ACRONYMS .......................................................................... C-1

XVIII Edition (A) Version 1.0 (Draft 3)

INTENTIONALLY BLANK

AMSP-04

1-1 Edition (A) Version 1.0 (Draft 3)

CHAPTER 1 INTRODUCTION 1.1. PURPOSE

1. The NATO Education and Training Network (NETN) Federation Architecture and FOM Design (FAFD) document is a reference document intended to provide architecture and design guidance for developing distributed simulation and training systems in the context of Computer Assisted Exercises (CAX). The guidance provided by the FAFD has been developed to support the NETN vision and is applicable to NATO CAX, national CAX and to distributed modelling and simulation in general.

“To deliver to NATO and Partners a persistent, distributed combined joint training capability able to support training from the operational to the tactical level across the full spectrum of operations, through leveraging existing national expertise and capabilities.” - NATO ACT NETN Vision

2. The FAFD focuses mainly on technical interoperability issues in distributed simulation. It is not a complete guide on how to design a distributed simulation to support CAX but will provide key architecture and design patterns and proposed solutions.

3. As a reference document, the FAFD is not intended to replace design and agreements documents authored to support each particular instance of federation development and use.

1.2. BACKGROUND

1. The first version of the FAFD was developed by NATO Modelling and Simulation Group MSG-068. This task group was created to support the ACT Snow Leopard Program, establishing a NATO-wide network for education and training (NETN).

2. A technical subgroup of MSG-068, Federation Architecture and FOM Design (FAFD), was created with representatives from the participating NATO and partner nations. This group represented a broad community of practice with respect to federation architecture and design. Major systems, federations and training networks were represented in the FAFD group. The input provided and the harmonization of federation architecture and design agreements formed the first version of this document.

3. The second version of these federation agreements were developed by a second NMSG task group, namely the MSG-106 "Enhanced CAX architecture, design and methodology - SPHINX" technical (TEK) subgroup. This group modified the original agreements based on practical experiences in using the NETN recommendations in major exercises and experiments and included clarifications,

AMSP-04


recommendations and agreements resulting from work accomplished during the tenure of MSG-106.

1.3. SUMMARY OF CHANGES a. Modularization of RPR-FOM.

b. New NETN Base FOM Module.

c. New NETN Physical FOM Module.

d. New NETN Aggregate FOM Module.

e. New NETN Logistics FOM Modules.

f. New MRM FOM Module.

g. New C-BML FOM Module.

h. New CBRN FOM Module.

i. New TMR FOM Module.

1.4. REFERENCES

While this document is intended to be sufficiently complete to be read stand-alone, it cannot fully explain all the concepts and foundational work accomplished by the many individuals and organizations whose efforts preceded ours. Please refer to the documents referenced below for more details. This document refers especially to the RPR-FOM v2.0 documentation. In the case of differences between this document and the references, this document is primary as changes were made with intent to support evolving NETN requirements.

a. Distributed Interactive Simulation (DIS):

(1) IEEE 1278.1-1995 Application Protocols.

(2) IEEE 1278.1a-1998 Supplement to Application Protocols - Enumeration and Bit-encoded Values.

(3) IEEE 1278.2 - Communication Services and Profiles.

(4) IEEE 1278.3 - Exercise Management & Feedback (EMF) - Recommended Practice.

(5) SISO-REF-010-2006 DIS Enumerations.

AMSP-04


b. High Level Architecture (HLA):

(1) IEEE 1516-2000 Framework and Rules.

(2) IEEE 1516.1-2000 Federate Interface Specification.

(3) IEEE 1516.2-2000 Object Model Template (OMT) Specification.

(4) IEEE 1516.3-2003 Federation Development and Execution Process (FEDEP).

(5) IEEE 1516.4-2007 Verification, Validation, and Accreditation of a Federation.

(6) IEEE 1516-2010 HLA "Evolved" Framework and Rules.

(7) IEEE 1516.1-2010 HLA "Evolved" Federate Interface Specification.

(8) IEEE 1516.2-2010 HLA "Evolved" Object Model Template (OMT) Specification.

c. Real-time Platform Reference Federation Object Model (RPR-FOM):

(1) SISO-STD-001-2015: Standard for Guidance, Rationale, and Interoperability Modalities (GRIM) for the Real-time Platform Reference Federation Object Model (RPR FOM), Version 2.0 (10 Aug 2015).

(2) SISO-STD-001.1-2015: Standard for Real-time Platform Reference Federation Object Model (RPR FOM), Version 2.0 (10 Aug 2015).

d. SISO-STD-004-2004: Dynamic Link Compatible HLA API Standard for the HLA Interface Specification Version 1.3.

e. SISO-STD-004.1-2004: Dynamic Link Compatible HLA API Standard for the HLA Interface Specification (IEEE 1516.1 Version).

f. NATO STANAG 4603.

g. IEEE 1730 Distributed Simulation Engineering and Execution Process (DSEEP).

h. IEEE 1730.1 Distributed Simulation Engineering and Execution Process Multi-Architecture Overlay (DMAO).

i. SISO-STD-002-2006: Standard for: Link16 Simulations.

AMSP-04


j. SISO-STD-003-2006; Base Object Model (BOM) Template Specification (approved 8 May 06).

k. SISO-STD-003.1-2006; Guide for BOM Use and Implementation (approved 8 May 06).

l. SISO-STD-007-2008: Military Scenario Definition Language (MSDL).

m. SISO-STD-011-2014: Coalition Battle Management Language (C-BML) Phase 1, Version 1.0.

n. RTO Technical Report TR-MSG-048 Coalition Battle Management Language (C-BML).

o. RTO Technical Report TR-MSG-052 Knowledge Network for Federation Architecture and Design.

p. RTO Technical Report TR-MSG-058 Conceptual Modelling (CM) for Military Modelling and Simulation (M&S).

q. RTO Technical Report TR-MSG-068 NATO Education and Training Network.

r. GMF: German Maritime Federation Object Model (GMF) Guidance, Rationale, and Interoperability Manual (GRIM) GMF Baseline v1.1 27 June 2012.

s. 13S-SIW-032. Low-level Battle Management Language. A. Alstad, O.M. Mevassvik, M.N. Nielsen, R.A. Løvlid, H.C. Henderson, R.E.J. Jansen, N.M. de Reus. 2013 Spring Simulation Interoperability Workshop. Simulation Interoperability Standards Organization.

1.5. OUTLINE

1. The NETN FAFD chapters are structured as follows:

a. Chapter 2 on NETN Federation Architecture and Design contains the overall requirements on NETN Federates and NETN Federations.

b. Chapter 3 on Aggregate and Physical Entity Representation describes extensions to the RPR-FOM representation of Platforms and Aggregates.

c. Chapter 4 on Initialization (Init) contains more detailed specification on preparation of a NETN Federation.

d. Chapters 5 & 6 on Transfer of Modelling Responsibility and Multi Resolution Modelling (MRM) describe fundamental design patterns for simulation interoperability in NETN federations.

AMSP-04


e. Chapter 7 on Simulation-C2 Interoperability describes how to transfer and inject C-BML messages in NETN federations and how to break these messages down into lower level BML messages to interact with CGFs.

f. Chapter 8 on Service Consumer-Provider Pattern describes a pattern for modelling and simulation of service requests, negotiation and delivery.

g. Chapter 9 on Logistics Simulation describes a service consumer-provider based pattern for simulation of logistics operations in a distributed NETN federation.

h. Chapter 10 on Chemical, Biological, Radiological and Nuclear (CBRN) describes interactions and agreements associated with modelling and distributed simulation of CBRN related events.

i. Chapter 11 on NETN and GMF Compatibility specifies compatibility concerns when integrating German Maritime FOM (GMF) within NETN federations.

j. Chapter 12 on References.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 2 NETN FEDERATION ARCHITECTURE AND DESIGN 2.1. CONCEPTS

1. In the context of distributed simulation, a Federation is a union of essentially independent applications (Federate) interoperating using common infrastructure services accessed through well-defined standard interfaces and governed by common agreements on modelling responsibilities and information exchange. A High-Level Architecture (HLA) Evolved Federation is a federation using the HLA standard (IEEE 1516-2010) to specify available infrastructure services and APIs for accessing them. The HLA standard also specifies how to document information exchange using a Federation Object Model (FOM). Different domains may have different FOMs but can use the same underlying simulation infrastructure standard. A NETN Federation is a HLA Evolved Federation that follows the NETN Federation Architecture and Design described in this chapter.

2. Federation Architecture is the style of design and method of integration using Simulation Components and common Simulation Infrastructure to create coherent distributed Simulation Systems. A specific Federation Design is developed to meet the requirements of Simulation Solutions to support Simulation Based Events such as Computer Assisted eXercises (CAX).

Figure 2-1: Federation Architecture.

AMSP-04


3. The purpose of having a common Federation Architecture is to harmonize design by providing design rules, design guidelines and best practices. Use of common design patterns and standards for interoperability and reuse lower the cost of development and integration.

4. The NETN FAFD specifies the architecture for NETN Federations and FOM modules specifically identified to support the design of NETN Federations.

2.2. NETWORK INFRASTRUCTURE

A NETN Federation relies on the existence of a network infrastructure providing local and wide-area connectivity based on standard Internet Protocols (IP). Implementation of the network infrastructure may differ for different NETN federations based on performance and security requirements, network availability, and cost considerations. Network infrastructure services providers, such as the Combined Federated Battle-Lab Network (CFBLNet), manage the network and can provide guarantees with respect to quality of service (QoS) and network security. Conversely, an internet connection combined with technologies for encryption may provide an appropriate level of connectivity and security for some cases. 2.2.1. Network Virtualization

1. A Virtual Private Network (VPN) is a common technology used for connecting distributed sites and systems with a peer-to-peer encrypted connection between different local area networks (LAN). The result is a virtual network where all systems share the same IP address space and can connect as if the systems were on the same LAN.

2. Another technology exists to create a virtual overlay network which acts on a protocol and application level. The overlay network connects only some of the systems on the LANs, e.g. the simulation infrastructure, and allows only these systems to interoperate as if they were on a LAN. An overlay network for simulation can hide the complexity of the physical networking infrastructure, simplifying the federation setup and optimizing simulation performance over WAN by providing a simulation-aware software router. In a NETN federation the types of virtual network technology used and in what combinations depends on the requirements of the federation. In a multi-site federation the use of an overlay network technology is recommended for creating persistent Virtual Simulation Networks.

2.2.2. Site Identification

1. In NETN federations the unique identification of sites is a vital part of agreements related to the representation of simulated entities and units. A list of site identifiers (IDs) is therefore required to be completed as part of any federation agreement. The unique site identifier is also used as part of the unique identifier for simulated entities in the federation as defined in the RPR-FOM datatype "EntityIdentifier".

AMSP-04


2. Site IDs should be in the range 1 – 65534.

2.3. SIMULATION INFRASTRUCTURE

NATO STANAG 4603 mandates the use of IEEE 1516-2010 standards on High-Level Architecture (HLA Evolved) for new M&S systems. The use of HLA Evolved in NETN federations is a fundamental design rule which impacts most parts of the NETN FAFD. Any NETN federation will be supported by a Run-Time Infrastructure (RTI) implementing the HLA services. On the network the RTI acts as a distributed operating system (OS) providing a standard interface (API) to the federated systems. Internally the RTI uses distributed algorithms and network protocols to implement all HLA services. The NETN FAFD will not make any recommendations with respect to specific RTI implementations but will assume a complete and certified HLA RTI implementation will be part of any NETN federation design.

2.3.1. Mixed Infrastructure

1. In many NETN federations there will be a need to mix different simulation infrastructure implementations and to support other distributed simulation standards, a.k.a. multi-architecture simulation environment. The NETN FAFD allows non-HLA (e.g. DIS) or legacy HLA (e.g. HLA 1.3) federates to participate in federations using appropriate bridging and/or adaptor technologies. Any bridging required in order to integrate federates to HLA Evolved or the selected RTI shall be the responsibility of the integrating federate. In some cases multiple NETN based federations may exist and information between them exchanged using bridges.

Figure 2-2: A Federation with Applications Using Different Standards and APIs.

AMSP-04


2. An adaptor is used to modify the way an individual system interacts with the simulation infrastructure. The adaptor can be implemented as:

a. An integrated and configurable part of a system (e.g. a plugin "HLA" module of a simulation system).

b. A separate component but tightly coupled through interfaces with the system (e.g. an HLA Wrapper).

c. A part of the simulation infrastructure providing an alternate API for system integration (e.g. HLA 1.3 and HLA 1516-2000 APIs provided by an HLA Evolved RTI implementation).

3. A bridge (also commonly referred to as gateway) is used to integrate multiple federations or federations running different versions of HLA, DIS or other simulation architectures. The difference between an adaptor and a bridge is that the latter allows multiple systems to use the same integration component.

4. NETN federations use HLA Evolved as the core simulation architecture. However, in the design of a federation, requirements may motivate the use of hierarchical federations, and integration of other simulation architectures. Some of these reasons are listed below:

a. Possibility of making code change, relinking, etc. (e.g. availability of source code to make adjustments).

b. Use of different RTI implementations or versions (e.g. no/minimal change of already verified federations).

c. Need to filter data (e.g. reduce load on a set of systems).

5. Need to translate data (e.g. using different FOMs).

6. Most adaptor and bridging solutions modify/reduce the services provided by HLA Evolved. This may have little or no impact on the overall interoperability of the system, but the fundamental design guideline of the NETN FAFD is to allow systems to integrate using as many of the HLA Evolved services and FAFD design patterns as possible. Designs with bridges and adaptors that limit the use of HLA Evolved services and FAFD design patterns should be avoided.

2.3.2. Federate Compliance Verification and Certification

Tests to verify compliance with HLA and NETN Federation design should be performed by each federate before integration. NATO nations provide HLA certification and some tools exist to test compliance with NETN design patterns. NATO MSG-134 "NATO Distributed Simulation Architecture & Design, Compliance Testing and Certification" is tasked with developing tool support for compliance testing and certification.

AMSP-04


2.4. NETN FOM

1. The NETN FOM is an identified set of HLA Evolved FOM Modules. To support NETN federation design, the NETN FOM modules are recommended for use when implementing NETN FAFD agreements in a distributed simulation. These modules include both references to standard FOMs and FOM modules as well as NETN modules developed and refined in MSG-068, MSG-085 [8] and MSG-106. The Low-Level BML FOM module was originally developed in ANNC CP-27 (Anglo Netherlands Norwegian Cooperation Programme 27) by TNO (NLD) and FFI (NOR), and is reused in MSG-106.

2. The modules have inter-dependencies and have been designed to maximize re-use and interoperability with legacy systems using existing standards, and those having requirements for new patterns of simulation interoperability. The NETN FOM is the complete set of NETN modules and all other modules they depend on (e.g. RPR-FOM modules). A NETN Federation defines the modules that are relevant and each simulation system only loads those modules it requires.

Figure 2-3: The NETN FOM Modules.

3. All FOM modules are provided as HLA IEEE-1516-2010 OMT Data Interchange Format files. Textual representations of the modules are provided in Annex A – NETN FAFD FOM Modules.

4. The modular concept allows federates to load only those modules necessary for the federation instance. In addition, the modules can be extended with more detailed representation by creating new modules and sub-classing or using information from other modules.

5. NETN Federations may extend the reference FOM with additional FOM Modules when appropriate. These FOM modules can be used in combination and extended to support NETN federation design. A specific federation may choose to

AMSP-04


include additional FOM modules, extend the NETN modules and/or select to use only a subset of the provided modules depending on the needs and requirements of the federation. The basic FOM Module rules as defined in HLA Evolved shall be applied. When extending the FOM with additional modules, the naming of classes, datatypes and other identifiers must be de-conflicted.

6. Registered objects and interactions are always discovered/received at the most specific subscribed class level. Extending a FOM Module with additional subclasses provides the possibility to add extra attributes/parameters at the more specific class level. Exchange of information using this more specific level can take place between federates publishing and subscribing to this level. However, to become compatible with and receive information from federates only publishing on the more general level, the receiving federate must subscribe to both class levels. Subscribers of the more general class will receive information from publishers of the more specific class level.

7. Example: A national extension to the NETN FOM Modules subclasses existing NETN object classes and defines additional attributes. National models aware of this extension can publish and subscribe to the more specific level defined in the national FOM module extensions. Other existing federates not aware of the extension can still discover the object and receive updates but only on the level they subscribe to. In order for the national federates to discover and receive information from other federates they need to subscribe to the NETN class level as well as the national extension level. Note that the discovered object and attribute updates will be on the NETN level.

2.5. NETN FEDERATION DESIGN

2.5.1. Initialization

1. In a NETN federation the responsibility of modelling and simulation is allocated to participating federates. Optimally, each federate is selected to participate in the federation because it has intrinsic capabilities to represent certain aspects of entities, events and other phenomena in the simulated environment necessary to accomplish the purpose for which the federation exists. The federation design and development process allocates, describes, and documents the roles and responsibilities of all federates. The responsibility of modelling certain aspects can only be assigned to a federate with a capability that meets specified requirements. Agreements on how to define the initial and dynamic transfer of modelling responsibilities are important for all NETN federation design.

2. NETN federations are advised to use Military Scenario Definition Language (MSDL) [SISO-STD-007-2008] and NETN extensions of MSDL to provide federates with initial scenario settings including ORBAT. Shared folders and/or web services can be used for distribution of MSDL and/or other common data. However, a single common distribution mechanism is currently not included in the recommendations. Chapter Initialization details the NETN proposed extensions to MSDL and proposed updates of the MSDL Schema is provided in Annex B.

AMSP-04


2.5.2. Transfer of Modelling Responsibility

1. In advanced distributed simulation the modelling and simulation responsibilities may change during the execution of the federation. The NETN FAFD provides a recommended design pattern for dynamic transfer of modelling responsibilities (TMR), which is described in detail in chapter Transfer of Modelling Responsibility. The TMR pattern is a general purpose pattern that supports multiple federation designs to handle situations where dynamic change of modelling responsibility is required or requested. TMR works at the attribute level and can include all or a subset of attributes for a simulated entity.

2. TMR is recommended, amongst other things, to support the following situations:

a. Transfer of modelling responsibility from a high fidelity federate to a low fidelity federate or vice versa.

b. Transfer of modelling responsibility from a Live simulation to a Constructive or Virtual simulation.

c. Transfer of modelling responsibility from a Constructive to a Virtual simulation.

d. Transfer of modelling responsibility from a Virtual to a Constructive simulation.

e. Transfer of modelling responsibility to a fail-over federate in case of federate loss.

f. Load balancing by transferring modelling responsibility to a less loaded federate.

g. Transfer of modelling responsibility to a federate located geographically closer to another federate to reduce latency between them.

h. Aggregation/Disaggregation using the NETN FAFD MRM pattern.

2.5.3. Representation of Aggregate and Physical Entities

1. The NETN FAFD representation of aggregate entities such as military units and physical entities such as platforms is based on the RPR-FOM v2.0 standard. The NETN FOM Module extends the RPR-FOM with NETN-Aggregate and NETN-Physical which include additional attributes for unique identification of simulated entities. The unique identification has been included to provide better support for initialization, TMR and other advanced design patterns requiring unique pre-defined identifiers for simulated entities. NETN federations still allow pure RPR-FOM based federates in the federation but with limited ability to interoperate in some NETN design aspects. Chapter Aggregate and Physical Entity Representation describes the extensions to RPR-FOM BaseEntity object class.

AMSP-04


2. It is recommended that NETN federates support NETN extensions of Aggregate and Physical Entities. For compatibility reasons NETN federates that implement NETN extensions of Aggregate and/or Physical Entities are also required to support RPR-FOM v2.0.

2.5.4. Multi-Resolution Modelling

1. The NETN FAFD supports multi-resolution modelling (MRM) by providing an MRM pattern for aggregation and disaggregation of simulated aggregate units and physical entities. The MRM pattern as described in chapter Multi Resolution Modelling (MRM) requires the use of NETN FAFD Transfer of Modelling Responsibilities pattern.

2. It is recommended that NETN federations that require models of varying levels of resolution apply the NETN FAFD MRM design pattern.

2.5.5. Simulation-C2 System Interoperability

1. The purpose of SIM-C2 interoperability is to automate the process of interaction between C2 systems and simulations. The NETN SIM-C2 concept as described in Chapter Simulation-C2 Interoperability is based on the Coalition Battle Management Language (C-BML) standard. A common design pattern is the use of a C-BML server to connect and exchange C-BML information between C2 systems and simulations. To interact with a NETN federation, a C-BML-HLA Gateway is used to transfer C-BML data between C-BML Server and the NETN federation. The NETN federation uses a C-BML FOM module as data exchange model within the federation. For a further break-down of the C-BML information, the NETN FAFD provides a Low-Level BML (LBML) FOM module. The LBML FOM module was originally developed in ANNC CP-27 (Anglo Netherlands Norwegian Cooperation Programme 27) by FFI and TNO, and is further refined in MSG-106.

Figure 2-4: SIM-C2 Architecture as Proposed in 13S-SIW-032.

AMSP-04


2. NETN Federations in Simulation Solutions that include C2 systems are recommended to make use of the NETN FAFD SIM-C2 design to automate Simulation-C2 interaction for orders and reports. A C-BML-HLA Gateway should be procured/implemented.

3. NETN Federations with CGFs that require low level BML instructions are recommended to procure/implement C2 Agent Federates using the NETN LBML FOM Module and/or extensions to support specific CGF interoperability.

2.5.6. Service Oriented Modelling and Simulation

1. The NETN FAFD includes a design pattern for allowing a federate to provide or request modelling and simulation services to or from other federates. This is not a transfer of responsibility between federates but rather a service provided by one federate and consumed by another. The NETN Service-Consumer FOM Module is a base module that allows federates to request, provide and consume services. This design pattern is also used in the NETN Logistics FOM module for logistics related services. Chapter Service Consumer-Provider Pattern describes this pattern in detail.

2. NETN Federation designs requiring inter-federate service negotiation before the simulation of the delivery of a service are advised to use the NETN FAFD Service Consumer-Provider Pattern.

Figure 2-5: NETN Service Consumer-Provider Pattern Interaction Sequence Diagram.

AMSP-04


2.5.7. Logistics

1. The NETN Logistics services are based on the NETN Service Consumer-Provider Pattern. The pattern is described in Chapter Logistics and implemented as extensions to the base FOM module (NETN-SCP-Base). The NETN Logistics covers the following services:

a. Supply service is provided by a facility, a unit or entity with consumable materials supply capability. Resources are transferred from the providing unit to the consuming unit.

b. Storage service is provided by a facility, a unit or entity with consumable materials storage capability. Resources are transferred from the consuming unit to the providing unit.

c. Repair service can be performed on equipment (i.e. non-consumables items such as platforms) by facilities or units capable of performing requested repairs. Modelling responsibility is by default not transferred for the consuming unit (e.g. a damaged platform) to the application with modelling responsibility for the providing unit (i.e. repairing facility). Modelling responsibility can be transferred by introducing the Transfer of Modelling Responsibility (TMR) pattern.

d. Transport service is provided by a facility, a unit or entity with transportation capability of non-consumable materials (units). Transported units are embarked, transported and disembarked. Modelling responsibility is by default not transferred for the consuming unit (transported unit) to the application with modelling responsible for the providing unit (transporter). Modelling responsibility can be transferred by introducing the Transfer of Modelling Responsibility pattern.

2. NETN Logistics is recommended to replace RPR-FOM v2.0 logistics modules and can be used, amongst others, in the following situations:

a. Supply of fixed wing aircraft in airports or during aerial refuelling.

b. Supply of helicopters in assembly areas.

c. Repair of damaged platforms by a maintenance unit without changing the platform's location.

d. Maintenance of damaged platforms previously deposited in a facility.

e. Transport of units, platforms, and humans by train, ship, or aircraft.

f. Embarkment and disembarkment of units.

AMSP-04


2.5.8. CBRN

The NETN FAFD includes a FOM Module designed to add specific support for CBRN modelling and simulation. The module is described in detail in Chapter Chemical, Biological, Radiological and Nuclear (CBRN). NETN Federations modelling CBRN events and effects are recommended to make use of the NETN FAFD CBRN design.

2.5.9. Maritime Task

The German Maritime FOM (GMF) provides enhanced/extended support for modelling and simulation of Maritime Tasks. Although the NETN FAFD does not include specific design recommendations or FOM modules for modelling and simulation of maritime tasks, the Chapter NETN and GMF Compatibility provides key information regarding the use of GMF in NETN Federations.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 3 AGGREGATE AND PHYSICAL ENTITY REPRESENTATION

3.1. OVERVIEW

The NETN object classes for entities are specializations of the leaf classes of the RPR object class BaseEntity. The NETN object classes have additional attributes to address the issue with instance identification in RPR; the issue with entity name and the lack of ability to set entities as inactive. One new attribute specifies the on-board entities and one attribute specifies the entity's activity. The NETN Aggregate object class has a number of attributes beyond these.

AMSP-04


Figure 3-1: NETN Object Classes.

AMSP-04


3.2. NETN ATTRIBUTES

3.2.1. Instance Identification

3.2.1.1. Instance Identification in the RTI

The RTI uses a handle of the data type ObjectInstanceHandle to identify instances in RTIambassador and FederateAmbassador services. Every instance in a federation execution gets a handle when it is registered and a name, either specified by the registering federate or generated by the RTI. The instance handle is unique in a federation execution but the instance handle will change between subsequent federation executions. The instance name is unique in a federation execution but will change in subsequent federation executions if generated by the RTI. Instances whose instance handle and name are automatically generated by the RTI, will be given new values if their owning federate leaves and subsequently re-joins a federation.

3.2.1.2. Instance Identification in the RPR FOM

1. The value of the attribute BaseEntity.EntityIdentifier is used for instance identification by many interactions in the RPR FOM, also is the instance name that the instance (unit/entity) gets when it is registered used by RPR FOM interactions. The attributes PhysicalEntity.Marking and AggregateEntity.AggregateMarking are used by some applications to identify instances in a federation execution with units/entities specified in an ORBAT. The attribute PhysicalEntity.Marking is restricted to 11 characters and the attribute AggregateEntity.AggregateMarking is restricted to 31 characters.

2. When a federate resigns and re-enters a federation execution the value on the attribute BaseEntity.EntityIdentifier may change on the unit/entity depending on the method that the federate uses for initialization of units/entities. Units/entities will not get the same value on the attribute BaseEntity.EntityIdentifier in subsequent federation executions if the responsible federate for a unit/entity changes between federation executions. Specifying the value for the attribute BaseEntity.EntityIdentifier on units/entities in an ORBAT is possible, but not recommended.

3.2.1.3. Instance Identification in the NETN FOM

1. The identification property defined in MSDL (Military Scenario Definition Language) is used in the NETN FOM to identify units/entities. It uses the definition of UUID from ISO/IEC 11578:1996 (and ISO/IEC 9834-8:2005). The UUID consists of an array with 16 bytes and has a standardized printable format that consists of 32 ASCII characters (0-9, a-f) and four hyphens on predetermined places, e.g. 550e8400-e29b-41d4-a716-446655440000.

2. The value of the attribute UniqueId for unit/entity identification is specified in a MSDL file defining an ORBAT where each unit/entity gets a unique UUID.

AMSP-04


3. If unit/entity UUIDs are specified in a federation ORBAT MSDL file, those UUIDs shall be maintained whichever federate has the modelling responsibility for the units/entities. If a modelling federate resigns and re-enters a federation, the units/entities will get the same identities that they previously had. This enables a good traceability in and between federation executions.

4. Units/entities specified in a MSDL file that are not (yet) registered in a federation execution will be possible to address with the UUID from other federates and the responsible federate may register it or make internal computation without registering it in the federation execution and then publish the consequences of these actions.

5. NETN object class units/entities outside the ORBAT shall be assigned a randomly generated UUID by the responsible federate when they are initialized in a federation execution.

3.2.2. Entity Name

The attribute Callsign on NETN aggregate and physical object classes is added to manage the problem with different data types for marking on RPR object classes (PhysicalEntity.Marking and AggregateEntity.AggregateMarking). There is no restriction for the length of Callsign.

3.2.3. Status

1. The attribute Status specifies if an entity is active or inactive and should be taken into account by federates, e.g. entities mounted in a vehicle may be set to inactive and not shown in a visualizer. For an aggregate entity in a disaggregated state the sub aggregates shall be activated, when in an aggregate state the sub aggregates should be inactive.

2. An inactive instance may have its instance attributes updated by the federates with the modelling responsibility for these instance attributes but received updates at that instance shall be ignored by receiving federates.

3. An inactive instance shall not be the source for any interactions, e.g. it cannot be the firing object in a WeaponFire interaction.

4. When an inactive instance becomes active shall the federate who own the Status attribute update the attributes that is owned by that federate and request an update on all other attributes that is not owned by that federate.

3.2.4. Activity

The activity of entities/units is specified with the Activity attribute, which is an enumerated value from the JC3IEDM action-event-category-code. Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM) is a fully documented standard [NATO STANAG 5525] for an information exchange data model for the sharing of C2 information.

AMSP-04


3.2.5. On-Board Entities

1. On-board entities are specified in a list with UUIDs in the attribute EmbeddedUnitList. Specified entities are instances of the NETN Aggregate class or a NETN-Physical leaf class. E.g. when soldiers are transported in a NETN_GroundVehicle instance shall a reference (UUID) to these soldier instances (NETN_Human) be added to the EmbeddedUnitList at the transporter, in this case the NETN_GroundVehicle. When a soldier disembarks from the transporter shall the reference (UUID) to that soldier in the EmbeddedUnitList be removed from the list.

2. This shall not be used for components such as sensor and emitting systems associated with their parent entity object.

3.2.6. NETN Aggregate Attributes

The attributes described above are also defined for the NETN Aggregate object class, which also contains a number of additional attributes, e.g. Symbol specifying the App6A code for the unit, CombatValue, HigherHeadquarters specifying the aggregate's superior unit or headquarters, Echelon specifying the level of command of the aggregate, etc.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 4 INITIALIZATION

1. Preparation of a distributed CAX environment includes the distribution and initialization of common data including but not limited to the following:

a. Order of Battle (ORBAT);

b. Common static map and terrain data; and

c. Initial scenario settings.

2. The NETN FAFD defines a common ORBAT format for initialization based on Military Scenario Definition Language (MSDL) [SISO-STD-007-2008] with NETN extensions.

In a NETN Federation, the MSDL with NETN extensions should be used for representing ORBAT and initial scenario settings.

3. The MSDL file is a common data / shared resource for the different shareholders and systems. Its distribution is typically done through a push/pull mechanism and a use of web services or shared folders. Federated systems are configured to access common data from the network during initialization.

In a NETN federation, common data should be made available using web services or shared folders.

4.1. NETN ORBAT AND SCENARIO SETTINGS FORMAT

1. The format for ORBAT and initial scenario settings is usually based on MSDL (SISO-STD-007-2008).

2. NETN extensions to the MSDL XML schema are used to better support initialization of distributed simulation systems. The following MSDL extensions are defined in the NETN ORBAT and scenario settings format:

a. Initial allocation of modelling responsibilities;

b. Unit and equipment type identification for simulation;

c. Representation of holdings;

d. Extended description of humans; and

e. Embarkment status.

AMSP-04


Figure 4-1: MSDL Description.

3. In MSDL, an ORBAT is described as a list of units and equipment. These items are further described by detailed objects linked together by relations.

AMSP-04


Figure 4-2: Description of MSDL ORBAT Section.

4.2. INITIAL ALLOCATION OF MODELLING RESPONSIBILITIES

1. The initial responsibilities of modelling units and equipment in the ORBAT shall be allocated to the participating systems during the federation configuration. This deployment or allocation of ORBAT information is captured in a NETN extension.

Figure 4-3: Description of New MSDL Deployment Section.

2. The MSDL XML schema is extended with one "Deployment" element including multiple (one or more) "Federate" sub-elements. A "Federate" element shall contain

AMSP-04


information regarding which ORBAT elements that have been allocated to the federate.

3. Example of MSDL Deployment section: … <Deployment> <Federate> <ObjectHandle>federate1</ObjectHandle> <Units> <Unit> <ObjectHandle>467088d7-6e7b-4e42-bdc5-b35a908acb39</ObjectHandle> </Unit> <Unit> <ObjectHandle>c283ef19-bd8e-4056-ab39-ccb227142e16</ObjectHandle> </Unit> <Unit> <ObjectHandle>c406b592-9011-4866-928d-bdd299cedfeb</ObjectHandle> </Unit> <Unit> <ObjectHandle>2451c755-5a02-49e4-a404-f0b8abb9414b</ObjectHandle> </Unit> </Units> </Federate> <Federate> <ObjectHandle>federate2</ObjectHandle> <Units> … </Units> </Federate> </Deployment> …

4.3. UNIT AND EQUIPMENT TYPE IDENTIFICATION

The MSDL format uses the JC3IEDM object type values to identify the unit type and NATO Stock Number (NSN) codes to identify the equipment type. NETN extensions to the MSDL XML schema provide additional fields for the type identification of units and equipment based on SISO-REF-010. "EntityType" values are introduced in the existing "Model" attribute (from "UnitType" and "EquipmentItemType" sections) which already contains data for simulation.

AMSP-04


Figure 4-4: Entity Type in the MSDL Unit Type.

AMSP-04


Figure 4-5: Entity Type in the MSDL Equipment Type.

4.4. ORGANIZATION DESCRIPTION

1. In an MSDL file, sub units can be described either in the ORBAT element or in the holdings element depending on the modelling capabilities / level of the CGFs. A federation may use platoons as leaf elements of the ORBAT, whereas another may be designed for a more detailed ORBAT by using equipment as leaf elements.

2. In order to enable the exercise planner to design the federation with the appropriate modelling granularity (aggregated simulations, platform-level simulations or a mix of both modelling granularities), the description of the organization shall be detailed enough for all federated simulations.

3. The "Holding" concept is used to describe human, platform, equipment and resources that do not need to be individually defined in a simulation (extension of logistics concept). The holdings are sub elements of "UnitType" and "EquipmentItemType" sections.

AMSP-04


Figure 4-6: Use of Holding in the MSDL UnitType Section.

Figure 4-7: Use of Holding in the MSDL EquipmentType Section.

AMSP-04


4.5. DESCRIPTION OF HUMANS

1. The description of humans in the ORBAT requires more details such as ranks and functions. For example: officer/non-officer, sniper/driver, etc.

2. This kind of information is already present in the JC3IEDM standard through the MILITARY-POST-TYPE concept (MilitaryPostTypeCategoryCode and MilitaryPostTypeRankCode elements) which defines a rank code and a category code. These codes are used as new attributes in the "UnitTypeType", "EquimentItemType" and "HoldingType".

3. In addition, when a human is described as Equipment or as a Holding, the following NSN code should be used: 0500. This enables human description without providing the full description of military post type in the simulation.

Figure 4-8: Use of MilitaryPostType in the MSDL UnitTypeType Section.

AMSP-04


Figure 4-9: Use of MilitaryPostType in the MSDL EquipmentItemType Section.

Figure 4-10: Use of MilitaryPostType in the MSDL HoldingType Section.

AMSP-04


4. JC3IEDM currently has a limited set of defined military post types. Therefore, to meet the needs of some simulation systems, it may be required to extend this set. Such limitation hasn't been experienced yet.

4.6. EMBARKED UNITS

1. Another NETN extension indicates if a unit or equipment is embarked on a hosting unit. This is modelled similar to a support relation in MSDL.

2. The "SupportRoleType" element, in which an enumerated value describes the kind of provided support, is extended with a new enumerated value ("EMBARKMENT") to indicate that a unit or equipment is embarked on another unit.

Figure 4-11: SupportRoleType in the MSDL UnitRelationType Section.

AMSP-04


Figure 4-12: SupportRoleType in the MSDL EquipmentRelationType Section.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 5 TRANSFER OF MODELLING RESPONSIBILITIES

5.1. TMR PATTERN CONCEPT 5.1.1. Introduction

1. The type of control of entities in a federation can be of two kinds, entity control and attribute modelling responsibility. A federate with entity control, controls the actions and behaviour of simulated entities. A federate with attribute modelling responsibility, updates a set of attributes at simulated entities. The TMR pattern is used to transfer modelling responsibility between federates. The reason for transfer of modelling responsibility can be to get the most suitable model do the updating of the attributes that covers the capability and characteristic of simulated entities. The TMR pattern can also be used for fault management, load balancing and multi resolutions models; such as aggregation and disaggregation, movement behaviour models, and damage assessment.

2. The transfer of ownership can be triggered either from an external source or by the requesting federate. The pattern has methods both for acquiring and divesting of instance attribute ownership. There is a correlation between TMR interactions and HLA Ownership services to ensure that the expected federates are involved in the transfer.

5.1.2. TMR Interactions and HLA Services

1. The TMR pattern defines five TMR interactions:

a. Initiate;

b. Request;

c. Offer;

d. Cancel Request; and

e. Transfer Result.

2. The TMR pattern incorporates four RTIambassador HLA Ownership Management services:

a. Attribute Ownership Acquisition (when negotiation);

b. Attribute Ownership Acquisition If Available (without negotiation);

c. Attribute Ownership Divesture If Wanted; and

d. Cancel Attribute Ownership Acquisition.

AMSP-04


3. The TMR pattern incorporates four FederateAmbassador (callbacks) HLA Ownership Management services:

a. Request Attribute Ownership Release † ;

b. Attribute Ownership Acquisition Notification †;

c. Confirm Attribute Ownership Acquisition Cancellation †; and

d. Attribute OwnershipUnavailable †.

Figure 5-1: The Interaction Classes in TMR FOM Module.

5.2. TMR PATTERN USAGE 5.2.1. TMR Pattern Rules

1. Before divesting instance attributes, the attributes shall be updated (HLA service Update Attribute Values). † = Callback service.

AMSP-04


2. After acquisition of instance attributes, the attributes shall be updated (HLA service Update Attribute Values).

5.2.2. Transfer Type

The type of the transfer can be Acquire, Divest or AcquireWithoutNegotiating. The requesting federate specifies the transfer type or if the transfer process is triggered from outside, the initiating interaction specifies the transfer type.

5.2.3. TMR Interactions 5.2.3.1. Interaction: TMR

1. The super interaction, containing parameters for use in its specializations.

Parameter: TMR.TransactionID

2. A structure with two fields, Counter and Federate Handle. The Transaction ID should, where possible, be encoded and used as the User Supplied Tag in the HLA Ownership services to get a correlation between the TMR interactions and HLA Ownership services.

3. When the transfer is initiated from an external source, the external source shall specify the Transaction ID and this shall then be used through the process. When the transfer is initiated by the requesting federate, the requesting federate shall specify the Transaction ID and this shall then be used through the process.

Parameter: TMR.RequestFederate

4. The Federate Name shall specify the federate that makes the request for the transfer.

Parameter: TMR.ResponseFederate

5. The Federate Name shall specify the federate that is the responding federate.

5.2.3.2. Interaction: TMR_RequestTransferModellingResponsibility

1. Request Transfer Modelling Responsibility shall be sent from the requesting federate to the responding federate, these federates are specified in the inherited parameters from the super interaction. If the request is the result of a TMR_Initiate TransferModellingResponsibility interaction, the parameters from that interaction shall be copied and used in the request.

Parameter: RequestTransferModellingResponsibility.TransferType

2. An enumerated value that shall indicate the direction of the transfer on the ownership and whether there shall be any negotiation:

AMSP-04


Acquire

a. Requesting Federate acquires instance attribute ownership from the Responding Federate (current owner).

Divest

a. Requesting Federate (current owner) releases instance attribute ownership to Responding Federate.

AcquireWithoutNegotiating

a. Requesting Federate acquires unowned instance attributes.

Parameter: RequestTransferModellingResponsibility.Instances

3. The Instances parameter shall specify the instances in the transfer collected in an array. The UniqueId attribute (UUID) is used for entity reference. The UniqueId attribute is defined in NETN object classes.

Parameter: RequestTransferModellingResponsibility.Attributes

4. The Attributes parameter shall specify the common set of attributes for all instances that shall be involved in the transfer. The set is collected in an array. An attribute shall be specified by the attribute name.

Parameter: RequestTransferModellingResponsibility.CapabilityType

5. The CapabilityType is an enumerated value and shall specify the capability type that the transfer is about. The usage of this is optional with a default value of Other. Some federates may be dependent on a value other than Other. There shall be a correspondence between the capability type and the set of attributes.

6. Enumerated values:

Total

a. Intersection of published attributes of the object class at the acquiring and divesting federate.

Movement

a. E.g. Spatial, PowerPlantOn, etc.

Damage

a. E.g. DamageState, Immobilized, etc.

Resource Consumption

AMSP-04


Other

Parameter: RequestTransferModellingResponsibility.InstanceAttributeValues

7. Optional parameter, default value is an empty array. Shall be used when acquiring federate is unaware of current instance attribute values, e.g. re-entering federates.

5.2.3.3. Interaction: TMR_OfferTransferModellingResponsibility

1. Offer Transfer Modelling Responsibility shall be sent from the responding federate to the requesting federate; these federates are specified in the inherited parameters from the super interaction. If the transfer is initiated from an external source, with the interaction TMR_InitateTransferModellingResponsibility, the requesting federate shall respond with TMR_OfferTransferModellingResponsibility to inform the originator of the intention of the initiate.

Special Case:

2. When the transfer type is Divesting, the delivery order of the interaction TMR_OfferTransferModellingResponsibility and the HLA ownership callback service requestAttributeOwnershipRelease at the receiving federate is not determined. Due to this, receiving a requestAttributeOwnershipRelease callback should be treated in the same way as receiving a TMR_OfferTransferModellingResponsibility with a positive offer.

3. The user supplied tag in the callback service contains the transaction identification which identifies a specific transfer process.

Parameter: OfferTransferModellingResponsibility.isOffering

4. Definition of the parameter values:

True

a. If and only if for all instances all attributes in the request are offered.

False

a. If for any instance any attribute in the request is not offered.

Parameter: OfferTransferModellingResponsibility.Respondent

5. Shall specify the sender of the offer interaction using the Federate Name.

Parameter: OfferTransferModellingResponsibility.Reason

6. An enumerated value that shall specify the reason for a negative offer:

AMSP-04


a. Other.

b. CapabilityDoesNotMatch.

c. AttributeSetTooRestricted.

d. AttributeSetTooExtensive.

e. FederateTooBusy.

f. AttributeSetNotCompatibleWithPublication.

g. OwnershipStateNotApplicableWithRequest.

h. EntityNotKnown.

7. The usage is optional with a default value of Other.

5.2.3.4. Interaction: TMR_InitiateTransferModellingResponsibility

1. This interaction shall trigger the requesting federate to do the request for modelling responsibility transfer.

Parameter: TMR_InitiateTransferModellingResponsibility.Initiating

2. The Initiating parameter shall specify the originator of the interaction, e.g. the value may be the federate name or the Callsign for the role possessor.

3. Other parameters shall be used by the Requesting Federate in the request interaction.

Parameter: TMR_InitiateTransferModellingResponsibility.TransferType

4. See Parameter: RequestTransferModellingResponsibility.TransferType.

Parameter: TMR_InitiateTransferModellingResponsibility.Instances

5. See Parameter: RequestTransferModellingResponsibility.Instances.

Parameter: TMR_InitiateTransferModellingResponsibility.Attributes

6. See Parameter: RequestTransferModellingResponsibility.Attributes.

Parameter: TMR_InitiateTransferModellingResponsibility.CapabilityType

7. See Parameter: RequestTransferModellingResponsibility.CapabilityType.

Parameter: TMR_InitiateTransferModellingResponsibility.InstanceAttributeValues

8. See Parameter: RequestTransferModellingResponsibility.InstanceAttributeValues.

AMSP-04


5.2.3.5. Interaction: TMR_CancelRequest

1. Sent by the Requesting Federate to cancel a request.

Parameter: TMR_CancelRequest:Reason

2. An enumerated value that describes the reason for the cancellation:

Other

a. When a Requesting Federate for some reason except time out decides not to complete a transfer, a cancel request shall be sent from the Request Federate to the Response Federate.

TimeOut

a. When a model's time limit for receiving a TMR Offer has passed, a cancel of the request shall be sent from the Request Federate to the Response Federate.

5.2.3.6. Interaction: TMR_TransferResult

1. Sent by the Requesting Federate, receiver is the initiating federate.

Parameter: TMR_TransferResult.TransferOk

2. A Boolean value indicating the result of the transfer.

5.2.4. Use Cases

A number of different cases are described with sequence diagrams in this chapter.

Figure 5-2: The TMR interactions and HLA services are colour coded.

AMSP-04


5.2.4.1. Acquire Request and a Positive Offer

Figure 5-3: TMR Acquire – OK. The requesting federate initiates the transfer to acquire instance attributes, transfer successful.

5.2.4.2. Transfer Request and a Negative Offer

The transfer type can be either Acquire or Divest in this case.

Figure 5-4: The Requesting Federate Initiates the Transfer to Acquire or Divest Instance Attributes, No Transfer Done.

AMSP-04


5.2.4.3. Request and Cancel Request

The requesting federate initiates the transfer but for some reason decides to cancel the request, e.g. a time out due to no offer from the response federate.

Figure 5-5: TMR CancelRequest – 1. The requesting federate initiates the transfer to acquire instance attributes, thereafter cancelled by the requesting federate.

5.2.4.4. Request, Positive Offer and Cancel Request

The requesting federate initiates the transfer but for some reason decides to cancel the request after a positive offer from the response federate.

Figure 5-6: TMR CancelRequest – 2. The requesting federate initiates the transfer to acquire instance attributes, a positive offer from the response federate,

thereafter cancelled by the requesting federate.

5.2.4.5. Divest Request and Positive Offer

The requesting federate initiates the transfer for divesting instance attributes.

AMSP-04


Figure 5-7: TMR Divest – OK. The requesting federate initiates the transfer to divest instance attributes, transfer successful.

5.2.4.6. Divest Request and Positive Offer, Race Condition

The requesting federate initiates the transfer for divesting instance attributes, the callback service is delivered before the positive offer interaction, and the callback is treated as a positive offer. The requesting federate does not need to wait for the TMR_OfferTransferResponsibility interaction to send the HLA service attributeOwnershipDivestureIfWanted. The UserSuppliedTag contains the transaction id and is bound to the original request.

AMSP-04


Figure 5-8: TMR Divest – OK – Race. The callback service is treated as an implicit positive offer.

5.2.4.7. Divest Request, Positive Offer, Cancel Request After HLA Ownership Negotiation Started

The requesting federate initiates the transfer for divesting instance attributes, the offer is positive but requesting federate cancels the request after the response federate has called attributeOwnershipAcquisition. The response federate has to cancel the acquisition with HLA service cancelAttributeOwnershipAcquisition.

AMSP-04


Figure 5-9: TMR CancelRequest – 3. The requesting federate initiates the transfer to divest instance attributes, a positive offer from the response federate,

thereafter cancelled by the requesting federate.

5.2.4.8. Initiate from External Source, Acquire Request, Positive Offer

The requesting federate starts the acquiring transfer after an initiate from an external source. The requesting federate sends a positive offer to the initiating federate and a report that the transfer was OK after it is completed.

Figure 5-10: The Trigger Federate Initiates the Transfer to Acquire Instance Attributes, Transfer Successful.

AMSP-04


5.2.4.9. Initiate from External Source, Divest Request, Positive Offer

The requesting federate starts the divesting transfer after an initiate from an external source. The requesting federate sends a positive offer to the initiating federate and a report that the transfer was OK after it is completed.

Figure 5-11: The Trigger Federate initiates the Transfer to Divest Instance Attributes, Transfer Successful.

5.2.4.10. Initiate from External Source, Acquire Request, Positive Offer and Cancel Request

The requesting federate starts the acquiring transfer after an initiate from an external source. The requesting federate sends a positive offer to the initiating federate. A report that the transfer failed is sent after the cancellation.

AMSP-04


Figure 5-12: The Trigger Federate Initiates the Transfer to Acquire or Divest Instance Attributes, a Positive Offer from the Requesting

Federate, Thereafter Cancelled by the Requesting Federate.

5.2.4.11. Initiate from External Source, AcquireWithoutNegotiating Request

The requesting federate starts the acquiring transfer after an initiate from an external source. The requesting federate sends a positive offer to the initiating federate and a report that the transfer was OK after it is completed.

Figure 5-13: The Trigger Federate Initiates the Transfer to Acquire Instance Attributes Without Negotiation.

AMSP-04


CHAPTER 6 MULTI-RESOLUTION MODELLING

1. The purpose of MRM is to enable interoperability sufficient for the intended purpose of the federation among HLA federates employing different levels of resolution.

2. Resolution is defined as "The degree of detail used to represent aspects of the real world or a specified standard or referent by a model or simulation" [1] as it supports development of guidance and/or standards representing different "dimensions" of resolution [2]. Davis and Bigelow decompose an object's resolution into process, spatial, and temporal dimensions with the object-related dimension further decomposed into three components: entity level, attributes, and logical dependencies among attributes.

6.1. MRM PATTERN CONCEPT 6.1.1. Modelling Responsibility

The MRM Pattern uses the Transfer of Modelling Responsibility Pattern to transfer ownership of instance attributes during the disaggregation and aggregation events. This is only sparsely described in this chapter; for detailed information about the TMR Pattern; see the Transfer of Modelling Responsibility (TMR) chapter.

6.1.2. High Resolution Units

The High Resolution Units are the disaggregated elements of the original aggregate, and can themselves be smaller aggregates. A high resolution unit is an instance of the NETN Aggregate class or a NETN-Physical leaf class.

6.1.3. MRM Service Provider

1. The MRM pattern describes a functionality implemented in a federate, either a federate whose main purpose is to act as a MRM Service Provider (MRM SP) or it may be implemented in a federate with another main purpose, e.g. a CGF federate.

2. The MRM SP requirements are:

a. The MRM SP shall have knowledge about the hierarchy in the ORBAT, which can be found in the MSDL file that defines the scenario units.

b. The MRM SP shall publish and subscribe to the NETN-Aggregate class.

c. The MRM SP is responsible for actions associated with the multi-resolution modelling. For example, the MRM SP is responsible for registering the entity instances (NETN-Physical leaf classes) according to the hierarchy defined in the ORBAT.

AMSP-04


d. The MRM SP may be able to manage the high resolution units, for example, moving the units and assigning damage to them. The attributes associated with these capabilities shall be published and subscribed to.

e. If the MRM SP does not have the capability to manage the high resolution units and is not responsible for modelling these, it shall have knowledge of which federates are capable, and transfer the modelling responsibility (TMR) appropriately.

f. Only one MRM SP shall respond to a Trigger request. If more than one MRM SPs exist in a federation execution then the responsibility for aggregate units shall be divided between the MRM SPs.

6.1.4. Aggregate Dynamic Attribute Update Responsibility

1. When an aggregate unit is disaggregated, modelling responsibility for the aggregate unit's dynamic values shall be transferred to the MRM SP. Attributes with a static value shall not be transferred. The MRM SP is then responsible for updating the dynamic attributes. According to the DIS standard a fully disaggregated unit shall not be updated. The MRM pattern modifies this, the MRM SP shall update the dynamic attributes and the Status attribute (NETN) shall be set to Inactive.

2. The federate responsible for the aggregate unit in Aggregate State gets information about the status of the subunits when the MRM SP updates the dynamic attributes of the aggregate unit according to the changes to the physical entities (the aggregate federate may not subscribe to physical object classes).

Table 6-1: Responsibility for Updating the Dynamic Attributes at NETN Aggregate Instances in Different Aggregate States.

AMSP-04


6.1.5. High Resolution Dynamic Attribute Update Responsibility

The MRM SP registers the high resolution entities. Attributes with static values shall not be transferred and shall be initialised (and updated on a request) by the MRM SP with data from the ORBAT, e.g. UniqueID, Callsign, EntityType. Dynamic attributes shall be updated by a federate with the required capability.

6.1.6. Aggregate Federate

The Aggregate Federate (Aggregate Sim) publishes and subscribes to the NETN-Aggregate class.

6.1.7. Higher Resolution Federate

The Higher Resolution Federate (HRF or Disaggregate Sim) shall publish and subscribe to the NETN-Physical leaf classes. It shall have the capability to manage physical entity attributes, such as movement and damage assessment. The Higher Resolution Federate can also publish and subscribe to the NETN-Aggregate class, e.g. when the result of a disaggregation of a battalion is units at platoon level.

6.1.8. Trigger Federate

A federate that triggers a MRM event shall have the capability to recognize events that require a higher resolution than the Aggregate Federate can provide to the simulation. This capability can be included in any federate e.g. the MRM SP or an Aggregate Federate. The functionality that the Trigger Federate represents can be replaced if the MRM SP is manually operated and the Trigger Federate is omitted.

6.1.9. Identification

To identify units (aggregates and physical units) each unit shall have a specified unique id represented in an attribute. This attribute is defined in the NETN FOM modules and the value is specified in the MSDL specification of the ORBAT (or equivalent).

AMSP-04


6.1.10. MRM Interactions

Figure 6-1: The Interaction Classes in the MRM FOM Module.

For a description of the MRM interactions and the interaction parameters see the MRM FOM module.

6.2. DISAGGREGATION

1. The MRM SP sends an MRM_DisaggregationRequest to both the Aggregate Sim and the Disaggregate Sim (Higher Resolution Federate).

2. The MRM SP waits for the MRM_DisaggregationResponse from the Aggregate Sim. When the MRM SP receives the response it makes a TMR request (acquire) for instance attributes at the aggregate object instance.

3. The HLA Ownership callback attributeOwnershipNotification to the MRM SP indicates that the TMR action between the MRM SP and the Aggregate Sim is complete.

4. The MRM SP registers entities if they do not already exist, and updates static and dynamic attributes of the entities.

5. When the Disaggregate Sim has discovered all entities specified in the UuidList of the associated MRM_DisaggregationRequest, and is ready to manage the entities, it sends the MRM_DisaggregationResponse.

AMSP-04


6. The MRM SP waits for the MRM_DisaggregationResponse from the Disaggregate Sim. When the MRM SP receives the response, it starts the transfer of modelling responsibility. The MRM SP uses the TMR pattern to divest the ownership of instance attributes with dynamic attribute values to the Disaggregate Sim.

7. The MRM SP will need to divest ownership of attributes of multiple object instances during an MRM disaggregation process. For each (entity) object instance: The HLA Ownership service attributeOwnershipDivestureIfWanted is a synchronized service and returns a set of instance attributes that have been divested. This is an indication for the MRM SP that the TMR action for an object instance (entity) with the Disaggregate Sim is complete.

8. When the TMR-actions are completed for all entities, the MRM SP sends the interaction MRM_ActionComplete to inform the Aggregate Sim and the Disaggregate Sim that the disaggregation is completed successfully (or failed).

9. The Disaggregate Sim updates the entity attribute values according to the events in the federation execution.

10. The MRM SP listens to the entity updates and then updates the corresponding attributes of the aggregate unit.

11. The Aggregate Sim listens to the updated attributes of the aggregate instance.

AMSP-04


Figure 6-2: MRM Disaggregate. MRM Disaggregation Sequence Diagram.

6.3. AGGREGATION

1. The MRM SP sends an MRM_AggregationRequest to both the Aggregate Sim and the Disaggregate Sim (Higher Resolution Federate).

2. The MRM SP waits for the MRM_AggregationResponse from the Aggregate Sim and the Disaggregate Sim. If both federates are able to comply with the aggregation request, the MRM SP starts the transfer of modelling responsibility (TMR) pattern to acquire the ownership of instance attributes with dynamic attribute values from the Disaggregate Sim.

3. The MRM SP will need to acquire ownership of attributes of multiple object instances during a MRM aggregation process. For each (entity) object instance: The HLA Ownership callback attributeOwnershipNotification indicates that the TMR action between the MRM SP and the Disaggregate Sim has completed for the entity.

4. The entities are either deleted or deactivated by the MRM SP.

AMSP-04


5. The MRM SP makes a TMR request (divest) to the Aggregate Sim for instance attributes of the aggregate object instance.

6. The HLA Ownership service attributeOwnershipDivestureIfWanted is a synchronized service and returns a set of instance attributes that have been divested. This is an indication for the MRM SP that the TMR action for the aggregate object instance with the Aggregate Sim is complete.

7. The MRM SP sends MRM_ActionComplete to inform the Aggregate Sim, and Disaggregate Sim that the aggregation is complete or cancelled.

Figure 6-3: MRM Aggregate. MRM Aggregation Sequence Diagram.

6.4. MRM TRIGGER

1. The MRM_Trigger interaction is sent from a federate that in some sense can detect the need for a disaggregation. It is not mandated that the MRM_Trigger interaction must be sent to the MRM Service Provider (MRM SP). The disaggregation process can start without a trigger interaction, e.g. a manually operation.

2. The MRM SP sends an MRM_TriggerResponse to the Trigger Federate, which contains the TransactionId which is used in subsequent interactions related to this MRM_Trigger.

3. The Disaggregation or the Aggregation sequence is executed depending on the AggregateState in the MRM_Trigger interaction.

AMSP-04


4. The MRM SP sends MRM_ActionComplete to inform the Trigger Federate that the aggregation is complete.

Figure 6-4: A Trigger Activates a Disaggregation or an Aggregation Event.

6.5. UNABLE TO COMPLY

If the service for some reason is not doable by the MRM SP it shall first respond with an MRM_TriggerResponse and then send an MRM_ActionComplete with the parameter CompletionResult (Boolean) indicating that the requested action in the MRM_Trigger will not be executed. One reason for a negative response can for example be that an aggregate unit already has the requested aggregate state or a TMR action was not performed.

AMSP-04


Figure 6-5: The MRM Request from the Trigger is Not Performed.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 7 SIMULATION-C2 INTEROPERABILITY

7.1. INTRODUCTION

1. The purpose of SIM-C2 interoperability is to automate the process of interaction between C2 systems and simulations.

2. The NETN SIM-C2 concept is based on Coalition Battle Management Language (C-BML) standard and a common design pattern is the use of a C-BML server to connect and exchange C-BML information between C2 systems and simulations.

3. Simulation could use a C-BML interface to interact with the C-BML server. In case of a NETN federation, an alternative solution is provided by using a common C-BML-HLA gateway to map C-BML data between the C-BML server and the NETN C-BML FOM module.

Figure 7-1: Example of C-BML Implementation Between C2 Systems and Simulations.

4. The C-BML language is a high level language and the use of associated information (orders, reports, etc.) depends on the modelling granularity of the simulation. High Level simulations (aggregated units) can process global orders, i.e. real C-BML orders. Low level simulation (platforms or small aggregated units like platoons) can only process elementary military tasks. With the HLA technology, the

AMSP-04


C-BML language is mirrored into an NETN FOM module called the C-BML FOM module. For the low level simulations, the C-BML orders should be transformed into lower level BML tasks using C2 Agent Federates and a Low-Level BML FOM Module. The C2 agent is a separate federate in the NETN federation, not integrated in a simulation or in a C2 system.

Figure 7-2: C2 Agent Federate Data Flow.

5. To avoid potential mistake, the C-BML FOM module has been named NETN-HCBML FOM module and the other module has been named NETN-LBML FOM module. The following diagram indicates the two approaches selected to manage the SIM-C2 interoperability.

Figure 7-3: Simulation-C2 Architecture Proposal.

AMSP-04


7.2. C-BML FOM MODULE

The NETN-HCBML FOM module is SIM-C2 oriented and focuses on transportation of C-BML messages:

a. The objective is to have a maximum process of C-BML ORDER message by simulations which are able to understand directly the C-BML message by using the existing schema defined by MSG-085.

b. This FOM module contains objects which transfer the whole information of ORDER and REQUEST without any change. The BML message is stored entirely in the BML object content in its XML format without modification (encapsulation that ensures an optimized compatibility), some information from the message header are extracted for the routing of the message.

c. For the reports, there is no encapsulation of the BML messages. BML reports and acknowledgements are supported by interactions with a design inspired from genuine C-BML reports and acknowledgements to aid use by the two C-BML modules.

7.2.1. Module Objects

Figure 7-4: Objects from the HCBML FOM Module.

This module contains three HLA objects:

a. MessageBML: global object which describes a BML element:

(1) OrderBML: object which describes a "BML Order"; and

(2) RequestBML: object which describes a "BML Request".

AMSP-04


7.2.2. Module Interactions

Figure 7-5: Interactions from the HCBML FOM Module.

This module contains six HLA interactions:

a. Ack: acknowledge the reception of the message and the capacity to execute a task in the Order.

b. Report: global interaction:

(1) TaskReport: progress of the Task.

(2) StatusReport: global interaction:

(a) SituationReport: perceived view or BFT (Blue Force Tracking) information, depend; and

(b) LogReport: logistics report.

7.3. LOW LEVEL BML FOM MODULE

The NETN-LBML FOM module is simulation oriented and focuses on tasks with a fine granularity:

a. It helps the simulation in understanding the C-BML message and it also introduces some concepts about "Command & Control" that simulations could use between themselves (for example during the disaggregation process).

b. It contains compact low level tasks and commands that can easily be interpreted and executed by CGF tools.

c. It reflects the capabilities commonly found in COTS CGF tools, but it is independent of one specific COTS CGF tool and one specific agent framework or agent modelling paradigm.

d. It is independent of any specific doctrine or tactics.

e. It defines status reports needed for the agent decision making and for producing C-BML reports.

AMSP-04


7.3.1. Module Objects

This module contains no HLA object classes.

7.3.2. Module Interactions

Figure 7-6: Interactions from the LBML FOM Module.

This module contains the following HLA interactions:

a. LBMLMessage: abstract root class of low level BML interactions.

b. LBMLTask: root class of low level BML tasks.

AMSP-04


c. ChangeOrderedAltitude: Change the ordered altitude. Usually sent with TaskType InterruptCurrentTask to adjust the current move task.

d. ChangeOrderedSpeed: Change the ordered speed. Usually sent with TaskType InterruptCurrentTask to adjust the current move task.

e. FireAtLocation: tasks a unit to fire at a location:

(1) FireIndirectWM: Tasks a unit to fire at a location with the specified weapon and munition.

f. FireAtUnit: tasks a unit to fire at a specified unit:

(1) FireDirectWM: The weapon type and the munition type to use.

g. FollowRoute: Tasks a unit to follow the specified route.

h. FollowUnit: tasks a unit to follow another unit.

i. Move: Tasks a unit to move in the specified direction. The unit will keep on moving until the specified end time or when ordered otherwise.

j. MoveIntoFormation: tasks an aggregate unit to move into the given formation with the given heading.

k. MoveToLocation: tasks a unit to move to the specified destination.

l. MoveToUnit: Tasks a unit to move to another unit.

m. SetRulesOfEngagement: tasks a unit to change the rules of engagement.

n. TurnToHeading: Tasks a unit to turn to the specified heading:

(1) TurnToOrientation: Pitch and roll parameters.

o. VehicleDismount: Tasks a unit to dismount.

p. VehicleMount: Tasks a unit to mount the specified vehicle.

q. Wait: tasks a unit to wait until the specified end time. Wait indefinitely if no end time is specified.

r. LBMLTaskManagement: Task management interactions. For now only used to cancel tasks. Can be extended to reschedule tasks:

(1) CancelAllTasks: Cancel all tasks. Tasks already started have to be aborted immediately.

AMSP-04


(2) CancelSpecifiedTasks: Cancel all specified tasks. Tasks already started have to be aborted immediately.

s. LBMLReport: root class of low level BML reports:

t. StatusReport: root class of reports from blue units about their status:

u. ActivityStatusReport: Base class for an activity report (absolute truth):

(1) CurrentActivityStatusReport: Time and status of the current task.

(2) NextActivityStatusReport: Time and start condition of the next activity.

v. AmmunitionStatusReport: a report about the amount of ammunition the unit still has.

w. DamageStatusReport: a report from a unit that has been damaged or destroyed.

x. FuelStatusReport: a report about the amount of fuel the unit still has.

y. PositionStatusReport: Report about the position, speed, and heading of the unit.

z. TaskStatusReport: A report about the status of a task the unit was ordered to execute.

aa. UnderAttackStatusReport: a report that the unit is under attack.

bb. SpotReport: a report from a blue unit about a spotted enemy, neutral, or unknown unit:

(1) ActivitySpotReport: The information here is based on perception information which is determined from situation awareness, intel or potentially instinct:

(a) CurrentActivitySpotReport: Elapsed time and status of the current task.

(b) NextActivitySpotReport: Time and start condition of the next activity.

(2) InSensorReport: Sensor type and sensed entities identifiers.

(3) InWeaponRangeReport: Weapon type and entity identifiers of entities in weapon range.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 8 SERVICE CONSUMER-PROVIDER PATTERN

1. The NETN Service Consumer-Provider is a basic pattern for modelling request, negotiation and delivery of services. The interaction patterns required for different types of services may vary but the basic principles and interaction class definitions are outlined in this chapter.

2. In the RPR-FOM and DIS, patterns exist to model logistics services. The intention is to allow these specific patterns to map onto the more general Service Consumer-Provider Pattern. This is described in more detailed in the Logistics FOM Module chapter.

3. The NETN Service Consumer-Provider Pattern defines two types of entities:

a. Service Consumer Entities: entities requesting and consuming specific services offered and provided by other entities.

b. Service Provider Entities: entities able to offer and provide a specific service.

4. A provider/consumer entity can be of various kinds, e.g.:

a. An object instance in a federation execution.

b. A federate.

c. A controller of a function implemented in a federate application.

5. The interactions between entities in this pattern will be published and sent using HLA services.

8.1. GENERAL APPROACH

1. The pattern is divided into three phases:

a. Service Negotiation: the service is requested, offers received and offers are either accepted or rejected.

b. Service Delivery: the consumer indicates that the deliver process can start, and the selected provider starts to deliver, continuing until all the services has been delivered.

c. Service Acceptance: the provider or consumer indicates the completion of the service delivery and waits for acknowledgement/acceptance from the other part.

AMSP-04


Figure 8-1: The Interaction Sequence for the Service Consumer-Provider Pattern.

2. The above interaction diagram shows the normal patterns for requesting services and receiving notification that the service transaction has completed.

3. Variations include:

a. Service completion is determined by the consuming entity and sent as a ServiceReceived interaction before the corresponding ServiceCompleted interaction is sent.

b. The service offer (OfferService) is NOT proceeded by a service request. This accommodates cases in which a service provider determines that a service is needed by one or more consumers and offers that service before being asked.

4. Exceptions include:

a. Early termination of the service by either the consumer or provider using the CancelService interaction.

b. Rejection of a service offer by the service consumer entity using the RejectOffer interaction.

AMSP-04


5. Federation agreements:

a. The condition for offering a service based on information in the request is an agreement for a specific federation. This agreement shall be documented in the federation specific agreements using the following reference template:

Scope/type of request Condition for Offering All types of requests exactly Ability to provide the type of service must match <scope> <condition>

6. Extending the RequestSupply and adding parameters with a description of the conditions for offering may be a future extension, e.g. in a RequestSupply the requested supplies (amount, type) needs to be available by a producer in order to make an offer. On the other hand one might also consider providers making promises they know or don't know they cannot keep (like in real life).

8.2. SERVICE CONSUMER

1. It is usually the service consumer that initiates a request for a specific service. A service consumer can be engaged in several concurrent service requests and deliveries. For each requested service the state of the service consumer can be described using a state-transition diagram (STD).

2. The Service Consumer entity may be in one of five states with respect to a requested service:

a. Requesting State. A service consumer entity is in the Requesting State when it has requested a specific service from another entity.

b. Offered State. A service consumer entity is in the Offered State when an offer of the service delivery has been made by a service provider.

c. Contracted State. A service consumer entity is in the Contracted State when an offer has been accepted.

d. Waiting State. A service consumer is ready to receive the service and waiting for service delivery start.

e. Receiving State. A service consumer entity is in the Receiving State during service delivery.

AMSP-04


Figure 8-2: The Consumer State Diagram.

Transition Condition and Actions Request Service

When conditions for requesting a service are met, the consuming entity shall issue a RequestService interaction. The entity shall proceed from the Initial state to the Requesting state.

Cancel Request

When conditions for requesting the services are no longer met a CancelService interaction is sent and the entity proceeds from the Requesting state to the End state.

Receive a no Offer

When an OfferService with a NoOffer indication is received, the entity shall proceed from the Requesting state to the End state.

AMSP-04


Transition Condition and Actions Receive Offer When an OfferService with an Offer indication is received, the entity shall

proceed from the Requesting state or Initial state to the Offered state. Reject Offer When conditions for accepting a service offer are not met the service

consuming entity shall issue a RejectOffer interaction and proceed to the End state.

Accept Offer When conditions for accepting a service offer exist the service consuming entity shall issue an AcceptOffer interaction and proceed to the Contracted State.

Ready to Receive Offer

When conditions for delivery of the service are met the service consuming entity shall issue a ReadyToReceiveService interaction and proceed to the Waiting State.

Cancel Service

When conditions for receiving the services are no longer met a CancelService interaction is sent and the entity proceeds to the End State.

Service Cancelled

When a CancelService interaction is received the service consuming entity shall proceed to the End State.

Start Service Delivery

When a ServiceStarted interaction is received the service consuming entity shall proceed to the Receiving State.

Service Completed

When a ServiceCompleted interaction is received or when the consuming entity determines that the conditions for service completion are met the ServiceReceived interaction shall be sent and the entity shall proceed to the End State.

8.3. SERVICE PROVIDER

The Service Provider entity may be in one of five states with respect to a requested service:

a. Requested State. A service provider entity is in the Requested State when it has received a request for a service from a service consumer entity.

b. Offering State. A service provider entity is in the Offering State when an offer in response to a requested service has been delivered to a service consumer.

c. Contracted State. A service provider entity is in the Contracted State when its offer has been accepted.

d. Preparing State. A service consumer has indicated it is ready to receive the service, a service provider prepares the service delivery.

e. Servicing State. A service provider entity is in the Servicing state when a service is being delivered to a service consuming entity.

AMSP-04


Figure 8-3: The Provider State Diagram.

Transition Condition and Actions Service Requested

When a RequestService is received the service providing entity shall proceed from the Initial State to the Requested State.

Cancel Request

When a CancelService interaction is received from a service consuming entity, the entity shall proceed from the Requested State to the End State.

No Offer When the conditions for delivering a requested service are not met, an OfferService with a NoOffer indication shall be sent and the service providing entity shall proceed to the End State.

AMSP-04


Transition Condition and Actions Offer When the conditions for delivering a requested service are met, an

OfferService including the offer shall be sent and the service providing entity shall proceed to the Offering State.

Offer Rejected When a RejectOffer is received the service providing entity shall proceed to the End State.

Offer Accepted

When an AcceptOffer is received the service providing entity shall proceed to the Contracted State.

Service Ready to Receive

When a ReadyToReceiveService is received the service providing entity shall proceed to the Preparing State.

Cancel Service When conditions for receiving the services are no longer met a CancelService interaction is sent and the entity shall proceed to the End State.

Service Cancelled

When conditions for providing the services are no longer met a CancelService interaction is sent and the entity proceeds to the End State.

Start Service Delivery

When the conditions for starting the service delivery are met, a ServiceStarted interaction is sent and the service providing entity proceeds to the Servicing State.

Service Completed

When a ServiceReceived interaction is received or when the conditions for completed service delivery are met, a ServiceCompleted interaction is sent and the service providing entity proceeds to the End State.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 9 LOGISTICS SIMULATION

9.1. SCOPE

1. The NETN Logistics services are based on the NETN Service Consumer-Provider Pattern. The pattern is described below and implemented in a base FOM module (NETN-SCP-Base) with extensions in additional FOM modules to support specific logistics services as defined below. Detailed description of how these services map to the NETN Logistics FOM modules are included in this document. The NETN Logistics FOM modules are dependent on the RPR v2.0 FOM modules due to the fact that a few data types defined in these modules are reused in the definition of parameters for NETN Logistics interactions. In addition, a Transfer of Modelling Responsibility pattern is introduced as an option for some logistics services. Extensions to RPR v2.0 object classes are introduced. The NETN Logistics covers the following services:



c. Repair service can be performed on equipment (i.e. non-consumables items such as platforms) by facilities or units capable of performing the requested repairs. Modelling responsibility is by default not transferred from the consuming unit (e.g. a damaged platform) to the application with modelling responsibility for the providing unit (i.e. repairing facility). Modelling responsibility can be transferred with the inclusion of the Transfer of Modelling Responsibility (TMR) pattern.

d. Transport service is provided by a facility, a unit or entity with transportation capability of non-consumable materials (units). Transported units are embarked, transported and disembarked. Modelling responsibility is by default not transferred from the consuming unit (transported unit) to the application with modelling responsibility for the providing unit (transporter). Modelling responsibility can be transferred with the introduction of the Transfer of Modelling Responsibility pattern.

2. Examples of uses:

a. Supply of fixed wing aircraft in airports or during aerial refuelling.

b. Supply of helicopters in assembly areas.

AMSP-04


c. Repair of damaged platforms by a maintenance unit without changing platform's location.

d. Maintenance of damaged platforms previously deposited in a facility.

e. Transport of units, platforms, and humans by train, ship, or aircraft.

f. Embarkment and disembarkment of units.

9.2. DEFINITIONS

The term unit will be used for individual physical entities as well as for aggregate entities.

9.2.1. Facilities

Facilities are the central element through which services are provided, e.g. material can be transferred to a consuming unit. Facilities may be created during a simulation or may be a part of the infrastructure (railway station, storage tanks depot, port, etc.). A facility may be part of a unit (e.g. ship).

9.2.2. Materials

1. Materials are differentiated between:

a. Consumable materials:

(1) Ammunition.

(2) Mines.

(3) NBC Materials.

(4) Fuel (Diesel, Gas, Aviation fuel, etc.).

(5) Water.

(6) Food.

(7) Medical materials.

(8) Spare parts.

b. Non-consumable materials:

(1) Platforms.

(2) Humans.

AMSP-04


(3) Aggregates.

(4) Reconnaissance and Artillery systems (Radar).

(5) Missile.

2. Consumable materials, hereafter also referred to as supplies, differ from non-consumables in that the former can be transferred to a unit, thereby "resupplying" that unit with the appropriate consumable material. Consumable materials are further differentiated between piece goods and bulk goods (e.g. fuel, water, decontamination means). Material may therefore be requested as individual pieces (each), or in cubic meters for liquid bulk goods and kilograms for solid bulk goods. The type of packaging (fuel in canisters, water in bottles, etc.) is not taken into account.

3. The definition of the type of the supply is based on the description in the Bit Encoded Values (SISO-REF-010) for Use with Protocols for Distributed Interactive Simulation Applications. Additional supply types shall be defined and specified in the Federation Agreement Document.

9.2.3. Appointment Data

Services delivery may require an agreement between the consumer and provider of when and where the service delivery shall take place; these requirements are specified in the appointment data.

9.3. NETN LOGISTICS FOM

1. The NETN Logistics FOM is composed of five FOM modules, one base module and one module each for the four different service types. The four FOM modules for the different service types contain specializations of the interaction classes in the base module.

AMSP-04


Figure 9-1: The NETN-SCP-Base FOM Module Interaction Classes.

2. The base module contains one object class, SCP_Facility which inherits from the RPR v2.0 object class BaseEntity. The attribute StorageList specifies the materials that are located at a facility and the attribute PlatformList specifies the units that are located at a facility. Since the SCP_Facility object class inherits from RPR v2.0 object class BaseEntity, it has the attributes IsPartOf and RelativeSpatial, it can be given a spatial relation to a RPR 2.0 instance, e.g. a facility can be placed on a surface vessel and act as a provider of supply and repair services.

AMSP-04


Figure 9-2: The NETN-SCP-Base FOM Module Object Class SCP_Facility.

9.4. SUPPLY PATTERN

1. Services for resupply of consumable materials include:



2. These two services are different in terms of flow of materials between service consumer and provider. Both services follow the basic NETN Service Consumer-Provider pattern to establish a service contract and a service delivery. In both services the Consumer and Provider are specified with parameters from the base module (NETN-SCP-Base). Both services have an optional Appointment parameter that describes where and when the transfer of the consumable materials shall take place. The Provider can change the appointment data from the request, e.g. the Consumer does not specify the appointment data in the request interaction, thereafter the Provider specifies appointment data in the offer interaction, the Consumer than has to accept or reject the offer.

3. If the time specified in the RequestTimeOut parameter of the request passes without the Provider sending a positive offer, the Consumer shall cancel the service. The Consumer may then again initiate a request interaction.

AMSP-04


4. The LoadingDoneByProvider parameter is used by the Consumer to propose whether the loading is controlled by the Provider or by the Consumer. This is an agreement between the parties and is specified in the offer from the Provider, which is accepted by the Consumer; the Provider can agree or disagree with the Consumer's proposal. By default the service delivery is controlled by the Provider. If the service delivery is controlled by the Provider:

a. The consuming entity shall issue a SCP_ServiceReceived in response to the SupplyComplete/StorageComplete interaction. Transfer of supplies is considered as complete once the SCP_ServiceReceived is issued. The SupplyComplete/StorageComplete interaction informs of the amount, by type, of supplies transferred.

5. If the service delivery is controlled by the Consumer:

a. The providing entity shall issue a SupplyComplete/StorageComplete in response to the SCP_ServiceReceived interaction. Transfer of supplies is considered as complete once the SupplyComplete/ StorageComplete is issued. The SupplyComplete/StorageComplete interaction informs of the amount, by type, of supplies transferred.

6. Early termination of the service request or delivery (as defined in the Service Consumer-Provider Pattern) is possible by either the Consumer or Provider by a cancellation of the service. On early termination, no materials will be transferred. Rejection of a service offer is allowed. In this case, no material will be transferred.

9.4.1. Supply Service

1. Materials will be transferred after the offer is accepted and the service is started. This service allows partial transfers. This implies that only some of the materials described in the service contract are transferred. The final requested amount of supplies, by type, is specified in the ReadyToReceiveSupply interaction and shall not exceed the amount of supplies, by type, specified in the OfferSupply interaction.

AMSP-04


Figure 9-3: Supply FOM Interaction Classes.

2. RequestSupply is used by a Consumer to initiate a request for supply from a supply service provider. Amount and type of materials are included in the request. In this request, the Consumer specifies a preference for whether the service delivery is controlled by the Provider (default) or by the Consumer.

3. OfferSupply is used by a Provider to indicate which of the requested materials (amount and type) can be offered. In this offer the provider can agree with the Consumer's choice of service delivery control or make a counter-offer.

4. ReadyToReceiveSupply is used by a Consumer to indicate that supply delivery can start.

5. If the transfer is controlled by the Provider then SupplyComplete is used by the Provider to inform the Consumer that the transfer is complete. The consuming entity shall send a SCP_ServiceReceived in response to the SupplyComplete interaction. Transfer of supplies is considered complete once the SCP_ServiceReceived is issued.

AMSP-04


6. If the transfer is controlled by the Consumer then SCP_ServiceReceived is used by the Consumer to inform the Provider that the transfer is complete. The providing entity shall send a StorageComplete in response to the SCP_ServiceReceived interaction. Transfer of supplies is considered complete once the StorageComplete is issued.

7. The transfer may only be a part of the offered materials (partial transfer); the actual transferred supplies are specified in SuppliesData parameter of the SupplyComplete interaction. If requested materials are only partially transferred, the consumer may start another RequestSupply in order to obtain all desired supplies.

8. If the SCP_CancelService occurs between SCP_ServiceStarted and SupplyComplete, the Provider shall inform the Consumer of the amount of supplies transferred using SupplyComplete parameter SuppliesData. This allows for supply pattern interruptions due to operational necessity, death/destruction of either the consumer or provider during resupply, etc. Note that the updated supply amount(s) are subject to the constraint that the amount(s), by type, must be less than or equal to the amount(s), by type, of offered supplies.

Figure 9-4: OK Transfer of Resources, Provider Controls the Service Delivery.

9. The service can be cancelled by both the provider and the consumer with the SCP_CancelService interaction. If the service is cancelled before service delivery has started, the service transaction is terminated.

AMSP-04


Figure 9-5: Early Cancellation, here by the Provider. Service is terminated.

10. If the service is cancelled during service delivery, the provider must inform the consumer of the amount and type of material transferred.

Figure 9-6: Cancellation by the Provider After the Service has Started, Provider Controls the Service Delivery.

11. The consumer can reject an offer from the provider and no more negotiations shall be done in the rejected service.

Figure 9-7: Consumer Rejects the Offer from the Provider.

AMSP-04


12. The provider can inform the Consumer that it is not able to fulfil the required supply data.

Figure 9-8: Provider Sends a Negative Offer to the Consumer.

9.4.2. Storage Service

1. Materials will be transferred after the offer is accepted and the service is started. This service allows partial transfers. This implies that only some of the materials described in the service contract are transferred. The final requested amount of stored supplies, by type, is specified in the ReadyToReceiveStorage interaction and shall not exceed the amount of supplies, by type, specified in the OfferStorage interaction.

Figure 9-9: Storage FOM Interaction Classes.

AMSP-04


2. RequestStorage is used by a Consumer to initiate a request for storage of supplies. Amount and type of materials are included in the request.

3. OfferStorage is used by a Provider to indicate which (amount and type) of the requested materials can be stored.

4. ReadyToReceiveStorage is used by a Consumer to indicate that supply delivery can start.

5. SCP_ServiceStarted is used by a Provider to indicate that the storage of requested materials has started.

6. If the transfer is controlled by the Provider then StorageComplete is used by the Provider to inform the Consumer that the transfer is complete. The consuming entity shall send a SCP_ServiceReceived in response to the StorageComplete interaction. Transfer of supplies is considered complete once the SCP_ServiceReceived is issued.

7. If the transfer is controlled by the Consumer then SCP_ServiceReceived is used by the Consumer to inform the Provider that the transfer is complete. The providing entity shall send a StorageComplete as response to the SCP_ServiceReceived interaction. Transfer of supplies is considered complete once the StorageComplete is issued.

8. The transfer may only be part of the offered materials (partial transfer); the actual transferred supplies are specified in SuppliesData parameter of the StorageComplete interaction. If requested materials are only partially transferred, the consumer may start another RequestStorage in order to transfer all desired supplies.

9. If the SCP_CancelService occurs between SCP_ServiceStarted and StorageComplete, the Provider shall inform the Consumer of the amount of supplies transferred using StorageComplete parameter SuppliesData. This allows for supply pattern interruptions due to operational necessity, death/destruction of either the consumer or provider during storage actions, etc. Note that the updated supply amount(s) are subject to the constraint that the amount(s), by type, must be less than or equal to the amount(s), by type, of offered supplies.

AMSP-04


Figure 9-10: OK Transfer of Resources, Provider Controls the Service Delivery.

10. The service can be cancelled by both the provider and the consumer with the SCP_CancelService interaction. If the service is cancelled before the service delivery has started, the service transaction is terminated.

Figure 9-11: Early Cancellation, here by the Consumer. The service is terminated.

11. If the service is cancelled during service delivery, the provider must inform the consumer of the amount and type of material transferred.

AMSP-04


Figure 9-12: Cancellation by the Consumer After the Service has Started, Provider Controls the Service Delivery.

12. The consumer can reject an offer from the provider and no more negotiations shall be done in the rejected service.

Figure 9-13: Consumer Rejects the Offer from the Provider.

13. The provider can inform the Consumer that it is not able to fulfil the required supply data.


AMSP-04


9.5. MAINTENANCE PATTERN 9.5.1. Repair Service

1. Repair service can be performed on equipment (i.e. non-consumables items such as platforms). Damaged platforms can be delivered to maintenance location or maintenance equipment can be moved to the requesting equipment. Providers of this service are facilities capable of performing requested repairs. The required effort for the repair of damaged material is determined by the providing model. It is calculated, based on the degree of damage to the material. If the consuming entity is an aggregate entity, its damaged equipment has to be listed in a platform list to get repaired.

Figure 9-15: Repair FOM Interaction Classes.

2. The service is initiated with a RequestRepair interaction, sent by a federate with modelling responsibility of damaged equipment (for example damaged platforms). The service provider offers the repair service by sending the OfferRepair interaction. The NETN Service Consumer-Provider interactions are used to complete the service.

3. The RepairData parameter in the request interaction is a list of equipment and type of repairs. The list of offered repairs may be different from the list of requested

AMSP-04


repairs. If the HLA object (equipment to be repaired) has a damaged state, the list of requested repairs could be empty. The providing federate models the efforts to repair a damaged platform.

4. The consuming entity shall send a SCP_ServiceReceived as a response to the RepairComplete interaction. The repair is considered as complete once the SCP_ServiceReceived is sent.

5. If the SCP_CancelService is sent either by the Consumer or Provider, before the service has started, no repair of equipment is done.

6. If the SCP_CancelService occurs between SCP_ServiceStarted and RepairComplete, the Provider shall inform the Consumer of the amount of repair done using RepairComplete parameter RepairData. This allows for interruptions due to operational necessity, e.g. death/destruction of either the consumer or provider during repair actions.

7. By default the Maintenance Pattern does not include a transfer of modelling responsibility of the damaged platform to the application with modelling responsibility for the repairing facility, but could be included in the service delivery if applications are aware of the Transfer of Modelling Responsibility (TMR) pattern.

Figure 9-16: OK Repair.

8. The service can be cancelled by both the provider and the consumer with the SCP_CancelService interaction. If the service is cancelled before service delivery has started, the service transaction is terminated.

AMSP-04


Figure 9-17: Early Cancellation by the Provider.

Figure 9-18: Service Cancelled by the Consumer After Service Started.

Figure 9-19: Service Offer Rejected.


AMSP-04


9.5.2. Repair Types

1. The NETN_RepairTypeEnum16 enumerated data type is defined in the NETN-Repair FOM and identifies a large set of repair types. These enumerations are also defined in the RPR-Enumerations FOM module. DIS does not define the enumerated values as part of the core specification.

2. In the RPR FOM modules values are defined as a fixed part of some enumerated data types. In order not to violate the modular FOM merging rules, the NETN Logistics FOM modules does not define any extensions to these data types as part of the FOM module. A separate table for adding values to the existing range of enumerations defined in the RPR FOM modules is allowed instead. This table shall be part of any federation specific agreements where extensions to an enumerated data type are required. It is also recommended but not required that any additional enumerated values added to this data type shall be submitted as Change Requests to the SISO RPR-FOM Product Development Group. All existing enumerators in RPR FOM modules and their values are reserved. Additional repair types are documented in the federation specific agreements.

9.6. TRANSPORT PATTERN

1. Transport services are used when there are needs to transport non-consumable materials such as platforms, units or battlefield entities. The providing federate models the transport. The Transport pattern follows the basic NETN Service Consumer-Provider pattern for establishing a service contract and a service delivery. Services for Transport include:

a. Transport service provided by a facility, a unit or entity with transportation capability of storing and delivering non-consumable materials.

b. Embarkment service provided by a facility, a unit or entity with transportation capability of storing non-consumable materials.

c. Disembarkment service provided by a facility, a unit or entity with transportation capability of delivering non-consumable materials.

2. Transport services differ in terms of the flow of units between service consumer and service provider:

a. In Disembarkment service, units are transferred from a service provider to a service consumer.

b. In Embarkment service, units are transferred from a service consumer to a service provider.

c. The Transport service consists of both Embarkment and Disembarkment service.

AMSP-04


3. The Embarkment and Disembarkment services could also be extended to management of facilities; with the capability of delivering and storing non-consumable materials to/from other facilities, units or battlefield entities. The Transport pattern includes an optional Transfer of Modelling Responsibility mechanism between a service consumer and a service provider (see Transfer of Modelling Responsibility).

Figure 9-21: Transport FOM Module.

4. The following interaction classes are extensions of the NETN Service Consumer-Provider base interactions:

a. RequestTransport interaction is used by the consumer to initiate a request of transport to a transport service provider. Units and appointment data are included in the request. The appointment data specifies when and where embarkment and disembarkment shall take place.

b. OfferTransport interaction is used by the transport service provider to indicate which of the requested units can be transported. In the offer, the provider can also change the appointment data specified in the request.

AMSP-04


5. During execution of transport services, the service provider shall inform the service consumer about the service progress using the following interactions:

a. TransportEmbarkmentStatus interaction is used by the service provider to indicate precisely when units are embarked.

b. TransportDisembarkmentStatus interaction is used by a service provider to indicate precisely when units are disembarked.

c. TransportDestroyedEntities interaction is used by a service provider to indicate the damage state of units during the transport.

6. The following NETN Service Consumer-Provider base interactions are also used in the Transport Pattern:

a. SCP_AcceptOffer.

b. SCP_ReadyToReceiveService.

c. SCP_ServiceStarted.

d. SCP_ServiceComplete.

e. SCP_ServiceReceived.

f. SCP_CancelService.

Figure 9-22: Transport Service Requested and Delivered.

AMSP-04


7. A Consumer makes a request for transport with the following data in a RequestTransport interaction:

a. List with units to transport; and

b. Time and location for embarkment and disembarkment.

8. A Provider offers a response to the consumer request with an OfferTransport interaction with the following parameters which may be modified from the originating request:

a. List with units that the provider can transport;

b. Time and location for embarkment and disembarkment; and

c. List of units that will execute the transport.

9. An offer is accepted with the interaction SCP_AcceptOffer or rejected with the interaction SCP_RejectOffer by the Consumer. The offer is accepted when both service Consumer and Provider have agreed about the conditions for delivery of the service. To achieve the transport service, the units listed for transport must be present on time at the embarkment location in order to embark and declare it with the SCP_ReadyToReceiveService interaction.

10. During the execution of the transport service, each transporting unit enters a loop where:

a. It publishes a list of embarked units.

b. It publishes a list of disembarked entities. If modelling responsibility has been transferred to the Provider; the responsibility of entities specified in this list is restored to the Consumer when disembarked (see Transfer of Modelling Responsibility).

11. Both TransportEmbarkmentStatus and TransportDisembarkmentStatus interactions can be repeated as much as needed, if transportation needs to be realized in several iterations. Unit management during delivery of services:

a. When Embarkment: Federate with modelling responsibility for the embarked units shall set these units as inactive. The unit is no more taken into account in simulation execution.

b. During Transport: The modelling responsibility of spatial attributes for the units specified in this list can be transferred to the Provider until disembarkment (see Transfer of Modelling Responsibility) or the consumer shall update the Spatial attribute or IsPartOf and RelativeSpatial attributes.

AMSP-04


c. When Disembarkment: Federate with modelling responsibility for the disembarked units shall set these units as active and assign their location to the disembarkment location.

12. A Transport service is considered as closed:

a. When the Consumer receives a SCP_ServiceCompleted interaction and sends a SCP_ServiceReceived interaction.

b. When a SCP_RejectOffer is issued by the service Consumer.

c. When a SCP_CancelService is issued by either the service Provider or service Consumer.

Figure 9-23: Early Cancellation of the Service, here by the Provider. The service transaction is terminated.

13. If a Transport service is cancelled:

a. During negotiation phase (before service delivery start):

(1) The transaction between service Consumer and Provider is considered as closed without delivery of service.

b. During delivery phase (after service start and before disembarkment has started):

(1) All units already embarked or partially embarked are kept by the service Provider. The service Provider needs a new Request to continue, either to embark remaining units or to disembark the already embarked units.

AMSP-04


c. During delivery phase (after disembarkment has started and before complete):

(1) All units already disembarked or partially disembarked are kept by the service Consumer. The service Provider needs a Cancellation of the transport service after it is started, and transported units will remain on the transporter.

Figure 9-24: Cancellation of the Transport Service after Disembarkment is Started, Units not yet Disembarked will Remain on the Transporter.

Figure 9-25: The Consumer Requests a New Transport Service, Disembarkment of Transported Units after a Cancellation of a Previous Transport Service.

AMSP-04


9.6.1. Disaggregation of Units for Transportation

1. In the case when a unit is too large for transportation on one transporter, e.g. echelon size does not permit a unit to be transported in a single transportation, the consumer of the service shall disaggregate the large unit in to a number of subunits, which shall be indivisible. The originating unit is set as inactive if it is fully disaggregated according to the definitions in 1278.1a-1998 document, otherwise it shall remain active. All subunits are then included in a transport request, and any offer may then be accepted or rejected.

2. When a unit is disaggregated for transport these subunits are embarked on more than one transporter or one transporter used repeatedly. At disembarkment, a temporary Bridgehead unit is activated at the disembarkment location, together with disembarked subunits. The bridgehead unit shall be assigned the callsign from the originating aggregate unit with an additional "-bh" to indicate that the unit represents a bridgehead. When all subunits are disembarked the originating unit is aggregated and set as active at the disembarkment location and subunits are then either deleted or set as inactive. The bridgehead is either deleted or set as inactive.

9.6.2. Warfare Interactions Against Transporter

1. Whenever a transport service provider receives warfare interactions (e.g. MunitionDetonation), damage on the transporter is calculated. If the transporter is destroyed then units on board the transporter shall also be destroyed.

2. If the transporter is not destroyed then damage is assessed against embarked units.

3. The transport service provider sends a list of destroyed units to the service consumer. The transport service consumer can use this list to update its situation or to cancel a transaction in progress. A transport service provider shall use the TransportDestroyedEntities interaction to define destroyed transported units during the service delivery.

4. If a transport service consists of one embarkment and one disembarkment event:

a. If the transporter is destroyed, the consumer service is cancelled and the transported unit(s) is never reactivated.

else:

b. If a transporter is destroyed with transported units on board, transport service continues with remaining transporters until service is completed. Units on destroyed transporter are deleted or set as inactive for the remainder of the federation execution.

AMSP-04


9.6.3. Embarkment Service

1. A Consumer makes a request for embarkment with the following data:

a. List with units to embark.

b. Time and location for embarkment.

2. A Provider offers a response to the consumer request with the following parameters which may be modified from the originating request:

a. List with units that the provider can embark.

b. Time and location for embarkment.

c. List of units that will execute the embarkment.

3. An offer is accepted or rejected by the Consumer. The offer is accepted when both service Consumer and Provider are agreeing about the conditions for delivery of the service. To achieve the embarkment service, the units listed for embarkment must be present on time at the embarkment location in order to embark and declare it with the SCP_ReadyToReceiveService interaction.

4. The TransportEmbarkmentStatus interaction can be repeated as much as needed, if embarkment needs to be realized in several iterations. During an Embarkment service execution, each transporter enters a loop publishing a list of embarked units. If the modelling responsibility is transferred to the application that provides the service then it shall remain there in this protocol. An Embarkment service is considered as closed:

a. When the service Consumer receives a SCP_ServiceCompleted interaction and sends a SCP_ServiceReceived interaction.

b. When a SCP_RejectOffer is used by the service Consumer.

c. When a SCP_CancelService is used by the service Provider or Consumer.

5. If an Embarkment service is cancelled:


(1) The transaction between the service Consumer and Provider is considered as closed without delivery of service.

b. During delivery phase (after service start and before service completed):

(1) All units already embarked are kept by the service Provider. The service Provider needs a new Request to continue, either to

AMSP-04


embark remaining units or to disembark the already embarked units.

9.6.4. Disembarkment Service

1. A Consumer makes a request for disembarkment with the following data:

a. List with units to disembark.

b. Time and location for disembarkment.

2. A Provider offers a response to the consumer request with the following parameters which may be modified from the originating request:

a. List with units that the provider can disembark.

b. Time and location for disembarkment.

c. List of units that will execute the disembarkment.

3. An offer is accepted or rejected by the Consumer. The offer is accepted when both service Consumer and Provider are agreeing about the conditions for delivery of the service. To achieve a Disembarkment service, Consumer shall publish the SCP_ReadyToReceiveService interaction.

4. A TransportDisembarkmentStatus interaction can be repeated as much as needed, if disembarkment needs to be realized in several iterations. During a Disembarkment service execution, each transporter enters a loop where it publishes a list of disembarked units. If the modelling responsibility is transferred to the application that provides the service then it shall be returned back to the application that consumed the service.

5. A Disembarkment service is considered as closed:

a. When the service Consumer receives a SCP_ServiceCompleted interaction and issues a SCP_ServiceReceived interaction.

b. When a SCP_RejectOffer is issued by the service Consumer.

c. When a SCP_CancelService is issued by the service Provider or Consumer.

6. If a Disembarkment service is cancelled:


(1) The transaction between the service Consumer and Provider is considered as closed without delivery of service.

AMSP-04


b. During delivery phase (after service start and before service completed):

(1) All embarked units are kept by the service Provider. The service Provider needs a new Request to continue, either to disembark remaining units or to embark the already disembarked units.

7. Variations:

a. Disembarkment protocol can start with a Consumer interaction instead of a Provider one. If a Provider initiates a Disembarkment (planned operation), the protocol execution starts directly at the second step (SCP_OfferService), without processing the query phase (RequestTansport).

9.6.5. Transport Services and Attrition

1. The TransportDestroyedEntities interaction can take place at any time between the start of the service (SCP_ServiceStarted interaction) and the end of the service (SCP_ServiceComplete interaction). Impact on the transport service pattern could be the following example.

2. Vessel « 1 » and « 2 » are transporters. Some units need to be transported in two rotations on each Vessel. We study the case where Vessel « 1 » is destroyed during its first rotation and Vessel « 2 » is destroyed during its second rotation: Event Interaction Negotiation phase and start of the service

…

First rotation: Vessel 1 and Vessel 2 embark units

Provider send: TransportEmbarkmentStatus (list1, Vessel1) TransportEmbarkmentStatus (list2, Vessel2)

During transport, service Provider receives MunitionDetonation; Vessel 1 is destroyed

Provider send: TransportDestroyedEntities (list1)

Vessel 2 disembark his units Provider send: TransportDisembarkmentStatus (list2, Vessel2)

Second rotation: Vessel 2 embark units Provider send: TransportEmbarkmentStatus (list3, Vessel2)

During transport, service Provider receives MunitionDetonation; Vessel 2 is destroyed

Provider send: TransportDestroyedEntities (list3)

End of service or Cancel

AMSP-04


9.6.6. Scenario Initialization Phase

1. Units can start as embarked units and have a planned disembarkment location. The transporters attribute EmbeddedUnitList shall identify these units with their UniqueId (UUID) which is specified in the scenario (MSDL) file for the initialization of the federation execution. Embarked units shall be published by the consumer during the scenario preparation/initialization phase.

2. The embarkment phase is assumed to have taken place during the scenario preparation phase, so applications do not need to interact for embarkment. The interaction sequence for the disembarkment service is:

a. The Consumer sends a request for disembarkment with units, time and location.

b. The Provider offers the service.

c. If the offer conditions are OK, it is accepted by the Consumer.

d. Consumer directly sends a ReadyToReceive interaction.

e. Provider directly sends a SCP_ServiceStarted.

f. Provider sends TransportDisembarkStatus when it arrives at the location.

g. Provider sends a SCP_ServiceCompleted when all units have disembarked.

h. Consumer sends a SCP_ServiceReceived.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 10 CHEMICAL, BIOLOGICAL, RADIOLOGICAL AND NUCLEAR (CBRN) SIMULATION

10.1. INTRODUCTION

1. This section provides the data definitions for CBRN FOM module within the NETN FOM. These data types will represent those needed to perform CBRN dispersion calculations (with the notable exception of meteorological information) and the dissemination of information about the dispersion effects on entities and the environment.

2. Note that meteorological information and CBRN material properties are not considered in this document. Meteorology is a wide and complex field that has requirements in many different modelling fields, not just CBRN. For that reason it is recommended that it has its own FOM module. Different dispersion models require different material properties; therefore it is better left to the dispersion model to handle these material properties.

10.2. DESIGN OVERVIEW

1. The CBRN FOM module consists of five sections:

a. CBRN Source release modelling;

b. Detector modelling;

c. CBRN effects modelling;

d. Protective measures modelling; and

e. Hazard area information.

2. Whilst designing this CBRN FOM module considerations have been taken as to how the CBRN FOM module can be used by legacy systems that cannot be updated to implement the CBRN FOM module. These considerations have resulted in the CBRN FOM module including interactions that mirror the changes that can be made to objects. These interactions allow for a translation federate to sit between the CBRN and simulation federate to translate the CBRN data into data that the simulation federate can understand.

10.3. CBRN SOURCE RELEASE MODELLING 10.3.1. CBRN_Release

The CBRN_Release interaction defines all of the CBRN source release information required for a CBRN federate to model a CBRN source release.

AMSP-04


Figure 10-1: CBRN_Release Interaction.

10.3.2. CBRN Warheads on Conventional Munitions

Ideally the CBRN_Release interaction would be sent from a simulation federate to the CBRN federate to inform it that a release had occurred, allowing the CBRN federate to model the release. However if a legacy simulation federate that can’t be updated to use the CBRN FOM module is being used, then the MunitionDetonation from the RPR FOM can be used instead. In this situation an additional federate will be created that can subscribe to the MunitionDetonation interactions and use the WarheadType parameter to check that the MunitionDetonation is a CBRN release. If it is a CBRN release then the additional federate will create a CBRN_Release using the WarheadType parameter, and publish the CBRN_Release interaction allowing the CBRN federate to start its CBRN modelling.

10.4. DETECTOR MODELLING

1. There are two use cases for a detector in a HLA simulation:

a. The first is for detector properties to be created and published by a simulation federate. A detector model within a CBRN federate would calculate the detector readings and publish the alarm status. This process would use the CBRN_Detector object and CBRN_DetectorAlarm interaction.

b. The second would have a complete detector model in a federate; this would request concentration readings from a CBRN federate and calculate its own alarm status. This would use the CBRN_Sensor object and CBRN_SensorUpdate interaction.

2. Both the CBRN_Detector and CBRN_Sensor objects extend the BaseEntity.PhysicalEntity.Sensor object in the RPR Physical FOM module.

AMSP-04


10.4.1. CBRN_Detector

The CBRN_Detector object is used when a CGF creates a detector with a CBRN federate performing the modelling of the detector. When the federate controlling the detector calculates a concentration above a threshold, it will issue a CBRN_DetectorAlarm interaction.

10.4.2. CBRN_Sensor

The CBRN_Sensor object is used when there is a detector federate performing the modelling of the detector. The CBRN_Sensor registers the agents that it is interested in and receives readings in the form of a CBRN_SensorUpdate interaction.

Figure 10-2: CBRN Detector Objects.

Figure 10-3: CBRN Detector Interactions.

10.5. CBRN EFFECTS MODELLING

1. Previous systems utilising HLA as the interoperability mechanism have used representations of damage from existing object models for representing kinetic weapons in order to represent CBRN exposure. The representation of damage from kinetic models does not necessarily map well to represent CBRN exposure.

AMSP-04


2. This section presents the use cases and data types for CBRN casualty modelling.

10.5.1. Lifeform CBRN Effects Modelling 10.5.1.1. CBRN_Human

The CBRN_Human object is an extension of the NETN_Human object from the NETN Physical FOM module. The CBRN federate will update the appropriate attributes as the casualty state of the entity changes. The TriageLevel uses the NATO representation of triage category scores [1]. The IPEType attribute denotes the level of Individual Protective Equipment (IPE) that the unit is wearing. These levels are those defined by the Nuclear, Biological and Chemical (NBC) dress states [2].

Figure 10-4: CBRN_Human Object.

10.5.1.2. CBRN_Casualty

The CBRN_Casualty interaction is provided to give support to legacy systems that do not use the CBRN FOM module. A translation federate can then map the CBRN_Casualty interaction into a data type that the legacy system can use.

10.5.1.3. CBRNDamageEnum8

The triage levels used in the CBRNDamageEnum8 enumeration uses the ‘T system’ to denote the priority of treatment for casualties where the levels are defined as:

a. T3 – Delayed priority.

b. T2 – Urgent priority.

c. T1 – Immediate priority.

d. T4 – Expectant priority (treatment would be ineffective).

Figure 10-5: CBRN_Casualty Interaction.

AMSP-04


10.5.2. Platform CBRN Effects Modelling 10.5.2.1. CBRN Platforms

In order to calculate further contamination and exposure for a platform, extensions are made to seven NETN leaf nodes in the NETN Physical FOM module. These are all extensions of the Platform object from the RPR Physical FOM module. Each extension contains an array of the mass of all materials that are contaminating the vehicle.

Figure 10-6: CBRN Platform Objects.

10.5.2.2. CBRN_PlatformUpdate

Using the same pattern as that used for the CBRN_Human object, the contaminating mass inside a platform due to embedded units can be updated by an external federate using the CBRN_PlatformUpdate interaction.

Figure 10-7: CBRN_PlatformUpdate Interaction.

10.6. PROTECTIVE MEASURES MODELLING

The use case for protective measures covers both the modelling of CBRN treatment and the modelling of CBRN protective equipment. This includes both individual (i.e. a respirator) and collective protection (i.e. Collective Protection (COLPRO)).

AMSP-04


10.6.1. COLPRO

The COLPRO object extends the BaseEntity.PhysicalEntity.CulturalFeature.NETN_CulturalFeature and provides information on how many entities it can contain as well as what agents it provides protection against.

10.6.2. DecontaminationStation

The DecontaminationStation object also extends the BaseEntity.PhysicalEntity.CulturalFeature.NETN_CulturalFeature and provides information on how many entities it can contain as well as what agents it can provide decontamination for.

Figure 10-8: CBRN Protective Measures Objects.

10.6.3. CBRN_FacilityUpdate

The CBRN_FacilityUpdate interaction is a base interaction that allows entities to be instructed to enter or leave a CBRN facility, it is not possible to publish or subscribe to this interaction.

10.6.4. COLPROUpdate

The COLPROUpdate interaction extends the CBRN_FacilityUpdate and allows entities to be instructed to enter or leave a COLPRO object.

10.6.5. DecontaminationStationUpdate

The DecontaminationStationUpdate interaction extends the CBRNFacilityUpdate and allows entities to be instructed to enter or leave a DecontaminationStation object.

AMSP-04


10.6.6. IPECommand

The IPECommand interaction allows entities to be instructed to don IPE by an external federate.

10.6.7. CBRN_TreatmentCommand

The CBRN_TreatmentCommand can be used for both pre-mission countermeasures and for treatment to be applied post-exposure. The CBRN_Human object has an attribute which denotes the treatments that have been applied to the unit.

Figure 10-9: CBRN Protective Measures Interactions.

10.7. HAZARD AREA MODELLING

The modelling of hazard areas allows the representation of a contamination area to be sent to a simulation federate in the simplest possible form. This could be in the form of:

a. The output from a hazard prediction algorithm (a warning area defined in Allied Tactical Publication (ATP)-45) [3] in response to a detector alarm or observation.

b. Raw output from a dispersion model (contours) during a simulation run.

10.7.1. ATP45HazardArea

The ATP45HazardArea object represents the hazard region as calculated by a warning and reporting model. Currently only a subset of the ATP-45 definition is used.

10.7.2. ProbabilityHazardContourGroup

The ProbabilityHazardContourGroup object provides a representation of the hazard area of the casualty effects of this CBRN hazard, calculated from the properties of the particular material.

AMSP-04


10.7.3. RawDataHazardContourGroup

The RawDataHazardContourGroup object provides a representation of the raw dispersion output which is purely the quantity of the material calculated by a dispersion model.

Figure 10-10: CBRN Hazard Area Objects.

AMSP-04


CHAPTER 11 NETN AND GMF COMPATIBILITY

11.1. INTRODUCTION

1. This section describes how to make the NETN FOM compatible and interoperable with the German Maritime FOM (GMF) version 1.1 modules.

2. The GMF FOM modules have been analysed with respect to:

a. Impacts arisen from changes from RPR2.0D17 to RPR 2.0.

b. Identification of possible conflicts in integration with NETN, especially inheritance, aggregation and transfer of responsibility.

3. The figure below shows the GMF modules and the relations between the GMF and the NETN and RPR FOMs.

Figure 11-1: Relations between GMF, NETN and RPR.

4. Note: The Simulation and Testing Environment of the Bundeswehr (SuTBw) module is also part of the GMF FOM. But it has not been possible to get sufficient information about the semantics of this module to relate it meaningfully to the NETN FOM.

11.2. BASE MODULE (GMF_INTERCHANGE)

This module serves as the base module for all other modules in the GMF FOM and has no standalone purpose.

AMSP-04


11.3. UNDERWATER ACOUSTICS EMISSIONS (GMF_ACOUSTICS)

The following steps are required in order for NETN federates participate in a federation using the GMF_Acoustics FOM module:

a. The NETN federates need to model AcousticPing events using the RPR-UA AcousticTransient class, encoding the ping mode using the ActivityCode index attribute, and modelling the ping mode parameters with the ActivityParameter attribute.

b. Create a bridge that maps the RPR-UA AcousticTransient events to GMF_Acoustics AcousticPing events, and back.

11.4. COMMUNICATION (GMF_COMM)

No conflicts exist between NETN and the GMF_Comm module.

11.5. EMITTER SIGNALS AND EMITTER PARAMETRIC DATA (GMF_EMITTER)

No conflicts exist between NETN and the GMF_Emitter module.

11.6. SONOBUOY INTEROPERABILITY (GMF_SONOBUOY)

1. The following steps are required in order for NETN federates to participate in a federation using the GMF_Sonobuoy FOM module:

a. Create a NETN Sonobuoy class inheriting from the RPR-Physical Sensor object class with the following attributes in order to support bridging Sonarbuoys between NETN and GMF:

(1) Payload, integer.

(2) OperationalMode, enumeration.

(3) AcousticGainControl, enumeration.

(4) EmbeddedSonar, RTIobjectId.

(5) EmbeddedRadioTransmitter, RTIobjectId.

(6) EmbeddedRadioReceiver, RTIobjectId.

b. NETN federates model the Sonobuoy as a collection of objects that together provide the complete model:

(1) NETN Sonobuoy.

(2) RPR_UA ActiveSonar.

AMSP-04


(3) RPR_UA ActiveSonarBeam.

(4) RPR_Communication RadioTransmitter.

(5) RPR_Communication RadioReceiver.

c. NETN federates use the RPR-Communication ApplicationSpecificRadioSignal interaction class to model sonarbuoy commands, where the commands are encoded into the object's SignalData attribute.

d. A NETN/GMF bridge is created that:

(1) Maps the proposed NETN model of the sonobuoy, with its sonar and radio properties, to the GMF model.

(2) Maps the NETN Sonobuoy commands modelled as ApplicationSpecificRadioSignal interaction classes to GMF SonobuoyCommand interaction classes.

11.7. TRANSPONDER (GMF_TRANSPONDER)

The GMF_Transponder FOM does not conflict with NETN.

AMSP-04


INTENTIONALLY BLANK

AMSP-04


CHAPTER 12 REFERENCES

[1] Gross, David C. (1999). Report from the Fidelity Implementation Study Group. In Proceedings of the Spring 1999 Simulation Interoperability Workshop, Orlando FL, March 14-19. http://www.sisostds.org.

[2] Davis PK and Bigelow JH (1998). Experiments in Multiresolution Modeling. RAND National Defense Research Institute, Sana Monica, CA.

http://www.sisostds.org/

AMSP-04


INTENTIONALLY BLANK

ANNEX A to AMSP-04 NETN FAFD FOM MODULES

A-1 Edition (A) Version 1.0 (Draft 3)

ANNEX A NETN FAFD FOM MODULES

A.1. MODULE NETN-BASE_v1.0.2

Information

Name: NETN-Base Type: FOM Version: 1.0 Modification Date: 2013-10-24 Security Classification: Unclassified Purpose: Application Domain: Training



Description: Base module for NETN FOM v2 modules. Mainly datatypes for use in other NETN FOM modules Use Limitation: Other:

Primary Author Point of Contact

Name: Lennart Olsson Organization: Pitch Technologies Telephone: +46 13 4705506 Email: [email protected]

References

Dependency RPR-Base_v2.0

Use History

Datatypes is collected from FOM modules in NETN FOM v1. NETN_AggDeagg_v1.07_2010. NETN_Service_Consumer_Provider_v1.0.3_2010. NETN_Logistics_v1.1.2_2010. v1.0.0 - First version in NETN FOM v2. v1.0.1 - Added array data type: ArrayOfWorldLocation3 (moved from NETN_Aggregate FOM module). v1.0.2 - Renamed data type, new name: ArrayOfWorldLocationStruct3. Updated References, Dependency.

mailto:[email protected]



Dependencies

RPR-Base_v2.0_draft19.10 RPR-Enumerations_v2.0_draft19.10 RPR-Foundation_v2.0_draft19.10

A.1.1. Datatypes

A.1.1.1. Simple Datatypes

TimeSecInt64 Representation: HLAinteger64BE Units: Second Resolution: 1 Accuracy: NA Semantics: Number of seconds since 1 January 1970.

CounterInt32 Representation: HLAinteger32BE Units: NA Resolution: 1 Accuracy: NA Semantics: A counter.

QuantityFloat32 Representation: HLAfloat32BE Units: NA



Resolution: NA Accuracy: NA Semantics: The number of units.

A.1.1.2. Enumerated Datatypes

ActiveStatusEnum8 Representation: HLAoctet. Semantics: An inactive object should not be shown on C4I systems and can not move or interact with other objects.

Enumerator Value

Other 0

Active 1

Inactive 2

AggregateMissionEnum16 Representation: HLAinteger16BE Semantics: The specific value that represents the general class or nature of activity (from JC3IEDM action-event-category- code).

Enumerator Value

Abdication 1 Accident 2 AccidentAircraftGround 3 Accident_Mine 4 Accident_Traffic 5



Enumerator Value

Accident_Weapon 6 Accident_Workplace 7 Advancing 8 AerialEngagement 9 AerialShootDown 10 AirAssault 11 AirborneAssault 12 AircraftCrash 13 AircraftLanding 14 AircraftLaunchActivity 15 AircraftLoss 16 AirspaceViolation 17 AlertCancellation 18 Ambush 19 AmphibiousOperation 20 ArmsProduction 21 ArmsTrade 22 Arresting_Legal 23 ArrestingOrObstructing 24 Arson 25 ArtilleryFire 26 Assassination 27 Assembling 28 AssistingACriminal 29



Enumerator Value

AtmosphericPollution 30 Attack_Deliberate 31 Attack_Diversion 32 Attack_Electronic 33 Attack_Hasty 34 Attack_Main 35 Attack_NotOtherwiseSpecified 36 Attack_Supporting 37 AttemptedMurder 38 AttemptedRape 39 AttemptedRobbery 40 AttemptedSuicide 41 Avoiding 42 BellyLanding 43 Blocking 44 Bombing 45 Bombing_Accidental 46 Bombing_Deliberate 47 BoobyTrapDiscovery 48 BorderCrossing_Escorted 49 BorderCrossing_Forced 50 BorderCrossing_Illegal 51 BorderCrossing_Not-Planned 52 BorderCrossing_Planned 53



Enumerator Value

BorderCrossing_Surveilled 54 BorderIncursion 55 BorderRaid 56 Breaching 57 Build-Up 58 BurnedOutObject 59 Bypass 60 Canalise 61 Capture 62 CarrierLaunch 63 CarrierRecovery 64 CBRN-EVENT 65 CeremonyOrParade 66 CivilDemonstration_Illegal 67 CivilDemonstration_Legal 68 CivilDisobedience 69 CivilUnrest 70 CivilWar 71 Clearing_Air 72 Clearing_LandCombat 73 Clearing_Obstacle 74 Clearing_RadioNet 75 CodewordExecution 76 Collision_Mid-Air 77



Enumerator Value

Collision_Obstacle 78 CommunicationsActivation 79 CommunicationsDeactivation 80 CommunicationsDisruption 81 CommunicationsInterception 82 CommunicationsOutage 83 CommunicationsRestoration 84 ConductingConference 85 ConductingForwardPassageOfLines 86 ConductingMediaInterview 87 ConductingPreparatoryFire 88 ConductingRearwardPassageOfLines 89 ConductingRecreationalActivities 90 ConductingRoadService 91 ConductingSocialEvents 92 ConductingSportingEvents 93 Confiscation 94 ConsolidatingOfAPosition 95 Constructing 96 Containing 97 Cooperating 98 CounterAttack 99 CounterAttackByFire 100 Counter-BatteryFire 101



Enumerator Value

CoupDetat 102 Covering 103 CrimeAgainstHumanity 104 CriminalIncident 105 Crossing 106 Dazzle 107 Death_NaturalCauses 108 DeathOfChiefOfState 109 DeathOfSpiritualLeader 110 Deception 111 Deception_Electronic 112 Defeat 113 Defending 114 Deflecting 115 Delaying 116 Demolition 117 Demonstration 118 Denying 119 Deploying 120 Destroying 121 Disease 122 Disengaging 123 Disrupting 124 Distributing 125



Enumerator Value

Diversion 126 Drive-ByShooting 127 Drought 128 DrugConsumption_Illegal 129 DrugDistribution_Illegal 130 DrugManufacturing_Illegal 131 DrugOperation 132 DrugStorage 133 DrugTransportation 134 EarlyWarningAlert 135 Earthquake 136 ElectionAssociatedViolence 137 ElectronicEmission 138 ElectronicWarfare 139 EnemyContact 140 Engaging 141 Enveloping 142 Epidemic 143 EquipmentFailure 144 Escaping 145 Escorting 146 Evacuating 147 Execution 148 Exploitation 149



Enumerator Value

Explosion 150 Famine 151 Fire 152 Firefighting 153 Fix 154 Fix_Acoustic 155 Fix_Electromagnetic 156 Fix_Electro-Optical 157 Flood 158 FollowingAndAssuming 159 FollowingAndSupporting 160 ForcedLanding 161 FriendlyFire 162 GeneratingChemicalSmoke 163 Genocide 164 GovernmentalCollapse 165 Guarding 166 Gunnery_Air-To-Air 167 Harassing 168 Hiding 169 Hijacking_Boat 170 Hijacking_LandVehicle 171 Hijacking_NotOtherwiseSpecified 172 Hijacking_Plane 173



Enumerator Value

Hold_Defensive 174 Hold_Offensive 175 HostageTaking 176 HumanRightsViolation 177 Hunting 178 Identifying 179 Illumination 180 IndirectFire 181 IndiscriminateShooting 182 IndustrialEspionageIncident 183 Infiltration 184 Interception 185 Interdiction 186 Intimidation 187 Invasion 188 Isolation 189 IssuingMediaArticle 190 IssuingMediaDocumentary 191 IssuingPressRelease 192 Jamming 193 Kidnapping 194 LabourStrike 195 Leaguer 196 LetterBombExplosion 197



Enumerator Value

LetterBombIncident 198 LocalElection 199 Locating 200 Looting 201 Maintaining 202 Marking 203 MartialLawImplementation 204 MassingOfForces 205 MassiveDeportationOrBanishment 206 MedicalEvacuation 207 MilitaryMobilisation 208 Mine-Laying 209 MissingIndividual 210 MissionStaging 211 MortarFire 212 Moving 213 Murder 214 MutualAssistancePactAgreement 215 NationalElection 216 NationalHoliday 217 NationalStateOfEmergency 218 NaturalDisaster 219 NavalGunFire 220 NavalPlatformFlightOperations 221



Enumerator Value

NetworkSeizure 222 Neutralize_Chemical 223 Neutralize_Combat 224 Neutralize_Explosive 225 Obscure 226 Observing 227 Occupying 228 Oceans_SeasOrWaterPollution 229 OffensiveOrCounteroffensive 230 OrganisedCrime 231 OutbreakOfRacialOrTribalOrEthnicWarfare 232 Patrolling 233 PeaceConference 234 PeaceTreatyAgreement 235 Penetrating 236 Pestilence 237 PetroleumProductSpills 238 Picketing 239 Poisoning 240 PoliticalDemonstration 241 PoliticalExecution 242 POWReturn 243 PrisonerExchange 244 Procuring 245



Enumerator Value

Protection_Electronic 246 ProvidingAccommodation 247 ProvidingAgriculturalSupport 248 ProvidingBedding 249 ProvidingCamps 250 ProvidingConstructionServices 251 ProvidingDecontaminationServices 252 ProvidingEducationServices 253 ProvidingHealthcareServices 254 ProvidingHostNationSupport 255 ProvidingInfrastructure 256 ProvidingLaundryServices 257 ProvidingRepairServices 258 ProvidingSecurityServices 259 ProvidingShelter 260 ProvidingStorageServices 261 ProvidingTranshipmentServices 262 Proxy-Bombing 263 PsychologicalOperation 264 PublishingMediaArticle 265 PublishingMediaDocumentary 266 PublishingPressRelease 267 Pursuing 268 Rape 269



Enumerator Value

Reconnaissance 270 ReconnaissanceInForce 271 Reconstituting 272 Recovering 273 Recuperating 274 Redeployment 275 RefugeeMovement 276 Reinforcing 277 ReliefInPlace 278 ReligiousDemonstration 279 ReligiousViolence 280 ReligiousWarfare 281 Rendezvous 282 Reorganising 283 Repairing 284 Resting 285 Resupplying 286 Retain 287 Retire 288 Revolution 289 Riot 290 Robbery 291 RocketFire 292 Sabotage 293



Enumerator Value

Screening 294 SecessionOfPortionOfCountry 295 Securing 296 SecurityCompromise 297 SecurityViolation 298 Seizing 299 ServingAsABreakoutForce 300 ServingAsABridgeheadForce 301 ServingAsAFlankGuard 302 ServingAsAMainBody 303 ServingAsAnAdvanceGuard 304 ServingAsAnIn-PlaceForce 305 ServingAsARearGuard 306 ServingAsAReserve 307 SettingUp 308 Shooting 309 SniperAttack 310 SpaceAccident 311 Spying 312 StateOfWar 313 Strafing_Aerial 314 Strike 315 Suicide 316 Supporting 317



Enumerator Value

Suppressing 318 Surrender 319 Surveillance_Electronic 320 SuspensionOfHostilities 321 Terrorism 322 Threaten 323 Torture 324 Transporting 325 Traversing 326 TreatyViolation 327 Troublemaking_Agitating 328 Troublemaking_Bullying 329 Troublemaking_Harassing 330 Troublemaking_Hooliganism 331 Troublemaking_Inciting 332 Troublemaking_Intimidating 333 Turning 334 UnexplodedOrdnanceDiscovery 335 VandalismOrRapeOrLootOrRansackOrPlunderOrSack 336 Verifying 337 VesselSinking 338 VolcanicEruption 339 WarOrCrisisAlert 340 WarOrMilitaryConference 341 WarCrime 342



Enumerator Value

WeaponFiring 343 Withdrawal 344 WithdrawalUnderPressure 345 Witnessing 346 NotOtherwiseSpecified 347

DamageStatusEnhancedEnum32 Representation: HLAinteger32BE Semantics: The damage status of an object.

Enumerator Value

NoDamage 0

SlightDamage 1

ModerateDamage 2

SignificantDamage 3

Destroyed 4

A.1.1.3. Array Datatypes

Callsign Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Unique identifier for an entity. A more user friendly identifier than UUID, used in Logistics protocol for Consumer

and Provider.



NETN_ArrayOfEntityTypeStruct Element Type: EntityTypeStruct Cardinality: [1..2147483647] Encoding: HLAvariableArray Semantics: One or more entity types.

UuidArrayOfHLAbyte16 Element Type: HLAbyte Cardinality: 16 Encoding: HLAfixedArray Semantics: 16 bytes in the UUID

A universally unique identifier (UUID), standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). A UUID is a 16-byte (128-bit) number. In its canonical form, a UUID is represented by 32 hexadecimal digits, displayed in five groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 digits and four hyphens). For example: 550e8400-e29b-41d4-a716-446655440000.

ArrayOfUuid Element Type: UuidArrayOfHLAbyte16 Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array with UUIDs.

NETN_ArrayOfSupplyStruct Element Type: NETN_SupplyStruct Cardinality: Dynamic



Encoding: HLAvariableArray Semantics: Array with NETN SupplyStructs.

ArrayOfWorldLocationStruct3 Element Type: WorldLocationStruct Cardinality: [3..2147483647] Encoding: HLAvariableArray Semantics: 3 or more locations, specifying a region (area).

A.1.1.4. Fixed Record Datatypes

NETN_EventIdentifier Encoding: HLAfixedRecord Semantics: Uniquely identifies an event from an entity.

Name Type Semantic

EventCount CounterInt32

EventCount shall be set to one for each exercise and incremented by one for NETN event. In the case where all possible values are exhausted, the numbers may be reused beginning again at one.

IssuingObjectIdentifier Callsign Callsign for the entity which issued the event.



NETN_SupplyStruct Encoding: HLAfixedRecord Semantics: Same definition as RPR2 SupplyStruct.

Name Type Semantic

SupplyType EntityTypeStruct The type of supply (as described in the Bit Encoded Values for Use with Protocols for Distributed Interactive Simulation Applications).

Quantity QuantityFloat32 The number of units of the supply type. The unit measure depends on the supply type and shall use the SI units of measurement used for such supplies.



A.2. MODULE NETN-AGGREGATE_v1.0.4

Information

Name: NETN-Aggregate Type: FOM Version: 1.0 Modification Date: 2014-10-16 Security Classification: Unclassified Purpose: Application Domain: Training Description: Object class from NETN FOM v1, module: AggDeagg Use Limitation: Other:



References

Dependency NETN-Base_v1.0 Dependency RPR-Aggregate_v2.0




Use History

v1.0.0 - Initial, object class and datatypes from NETN_AggDeagg_v1.0.7_2010 FOM module in NETN FOM v1. v1.0.1 - Changed name on basic data types from RPR2 Base. v1.0.2 - Moved array data type ArrayOfWorldLocation3 to NETN-Base FOM module. v1.0.3 - Updated References, Dependency. v1.0.4 - Fixed misspellings in sematics.

Dependencies

NETN-Base_v1.0.2 RPR-Aggregate_v2.0_draft19.10 RPR-Base_v2.0_draft19.10 RPR-Enumerations_v2.0_draft19.10 RPR-Foundation_v2.0_draft19.10

A.2.1. Object Classes

A.2.1.1. NETN_Aggregate

Full Name: HLAobjectRoot.BaseEntity.AggregateEntity.NETN_Aggregate Sharing: Publish/Subscribe Semantics: Aggregate extensions for NETN.



Attributes:

UnitPersonnel

Datatype Sharing Ownership Order Transportation Dimensions

ArrayOfResourceStatus PS DA RO HLAbestEffort Update type Update Condition

Conditional On change Semantics

This summarizes the health status of personnel comprising the aggregate.

Callsign


HLAunicodeString PS DA RO HLAbestEffort Update type Update Condition

Static N/A Semantics

The name of the object.

VisualSignature


VisualSignatureStruct PS DA RO HLAbestEffort Update type Update Condition


Describes the unit's susceptibility to electro-optical detection.

SourceUnit




Aggregate from which this aggregate was spawned.



Mission


MissionStruct PS DA RO HLAbestEffort Update type Update Condition


The operational task the aggregate has been ordered to perform.

Mounted


QuantityFloat64 PS DA RO HLAbestEffort Update type Update Condition


The percentage of aggregate personnel travelling on or in their organic transport.

UnitSupplies


NETN_ArrayOfSupplyStruct PS DA RO HLAbestEffort Update type Update Condition


The type and quantities of supplies available (on hand) to the unit.

HigherHeadquarters


UuidArrayOfHLAbyte16 PS DA RO HLAbestEffort Update type Update Condition


A pointer to the aggregate's superior unit or headquarters. The highest level unit or headquarters on each side will publish its own UniqueID as its HigherHeadquarters value.



CombatValue


CombatValueFloat64 PS DA RO HLAbestEffort Update type Update Condition


A summary value (in percent) of unit effectiveness based on level of training, leadership, moral, personnel and equipment operational status, etc.

WeaponsControlOrder


WeaponControlOrderEnum8 PS DA RO HLAbestEffort Update type Update Condition


Describes current Weapon Control Order Free, Tight, or Hold.

SupportUnit


SupportRelationshipStruct PS DA RO HLAbestEffort Update type Update Condition


Identifies unit(s) which support the aggregate logistically, or with a specified combat or combat support relationship, e.g. a Direct Support or General Support Artillery unit.

Activity


AggregateMissionEnum16 PS DA RO HLAbestEffort Update type Update Condition


The current activity of the aggregate. This may differ from the mission due to casualties, readiness, etc.



Symbol




The APP6A code for the aggregate.

CaptureStatus


CaptureStatusEnum8 PS DA RO HLAbestEffort Update type Update Condition


The status of an aggregate with respect to its control or influence over its own activities.

UnitEquipment


ArrayOfResourceStatus PS DA RO HLAbestEffort Update type Update Condition


This summarizes the health status of the equipment comprising the aggregate.

Echelon


EchelonEnum8 PS DA RO HLAbestEffort Update type Update Condition


The level of command of the aggregate.



HUMINTSignature


HUMINTSignatureStruct PS DA RO HLAbestEffort Update type Update Condition


Describes the unit's susceptibility to human intelligence (HUMINT), i.e. information collected and provided by human sources.

ElectronicSignature


ElectronicSignatureStruct PS DA RO HLAbestEffort Update type Update Condition


Describes the aggregate's susceptibility to electronic detection both as a summary value and by identifying aggregate sensors together with their operational status.

Footprint


ArrayOfWorldLocationStruct3 PS DA RO HLAbestEffort Update type Update Condition


The region occupied by the aggregate. the region is defined as that bounded by line segments connecting the listed world locations.

CoverStatus


CoverStatusStruct PS DA RO HLAbestEffort Update type Update Condition


Describes the unit's protection from the effects of weapons fire.



EntityList


EntityListVariableLengthStruct PS DA RO HLAbestEffort Update type Update Condition


Provides data on entities comprising the aggregate.

Status


ActiveStatusEnum8 PS DA RO HLAbestEffort Update type Update Condition


If an instance shall be taken into account by federates.

UniqueID



Static NA Semantics

The unique identifier of the object.

EmbeddedUnitList


ArrayOfUuid PS DA RO HLAbestEffort Update type Update Condition


The list of objects carried by this aggregate.



AggregateMarking Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


AggregateMarkingStruct PS DA RO HLAbestEffort Update type Update Condition

Static NA Semantics

A unique marking or combination of characters used to distinguish the aggregate from other aggregates.

AggregateState Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


AggregateStateEnum8 PS DA RO HLAbestEffort Update type Update Condition


An indicator of the extent of association of objects form an operating group.

Dimensions Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


DimensionStruct PS DA RO HLAbestEffort Update type Update Condition

Conditional AggSizeChange Semantics

The size of the area covered by the units in the aggregate.

EntityIdentifiers Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


RTIobjectIdArray PS DA RO HLAbestEffort Update type Update Condition


The identification of entities that are contained within the aggregate.



ForceIdentifier Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


ForceIdentifierEnum8 PS DA RO HLAbestEffort Update type Update Condition


The identification of the force that the aggregate belongs to.

Formation Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


FormationEnum32 PS DA RO HLAbestEffort Update type Update Condition


The category of positional arrangement of the entities within the aggregate.

NumberOfSilentEntities Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


Integer16 PS DA RO HLAbestEffort Update type Update Condition


The number of elements in the SilentEntities list.

NumberOfVariableDatums Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


UnsignedInteger32 PS DA RO HLAbestEffort Update type Update Condition


The number of records in the VariableDatums structure.



SilentAggregates Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


SilentAggregateStructLengthlessArray PS DA RO HLAbestEffort Update type Update Condition


The numbers and types, of silent aggregates contained in the aggregate. Silent aggregates are sub-aggregates that are in the aggregate, but that are not separately represented in the virtual world.

SilentEntities Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


SilentEntityStructLengthlessArray PS DA RO HLAbestEffort Update type Update Condition


The numbers and types, of silent entities in the aggregate. Silent entities are entities that are in the aggregate, but that are not separately represented in the virtual world.

SubAggregateIdentifiers Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


RTIobjectIdArray PS DA RO HLAbestEffort Update type Update Condition


The identifications of aggregates represented in the virtual world that are contained in the aggregate.

VariableDatums Inherited from AggregateEntity in RPR-Aggregate_v2.0_draft19.10


VariableDatumStructLengthlessArray PS DA RO HLAbestEffort Update type Update Condition


Extra data that describes the aggregate.



EntityType Inherited from BaseEntity in RPR-Base_v2.0_draft19.10


EntityTypeStruct PS DA RO HLAbestEffort Update type Update Condition

Static NA Semantics

The category of the entity.

EntityIdentifier Inherited from BaseEntity in RPR-Base_v2.0_draft19.10


EntityIdentifierStruct PS DA RO HLAbestEffort Update type Update Condition

Static NA Semantics

The unique identifier for the entity instance.

IsPartOf Inherited from BaseEntity in RPR-Base_v2.0_draft19.10


IsPartOfStruct PS DA RO HLAbestEffort Update type Update Condition


Defines if the entity if a constituent part of another entity (denoted the host entity). If the entity is a constituent part of another entity then the HostEntityIdentifier shall be set to the EntityIdentifier of the host entity and the HostRTIObjectIdentifier shall be set to the RTI object instance ID of the host entity. If the entity is not a constituent part of another entity then the HostEntityIdentifier shall be set to 0.0.0 and the HostRTIObjectIdentifier shall be set to the empty string.

Spatial Inherited from BaseEntity in RPR-Base_v2.0_draft19.10


SpatialVariantStruct PS DA RO HLAbestEffort Update type Update Condition


Spatial state stored in one variant record attribute.



RelativeSpatial Inherited from BaseEntity in RPR-Base_v2.0_draft19.10




Relative spatial state stored in one variant record attribute.

HLAprivilegeToDeleteObject Inherited from HLAobjectRoot in MIM


HLAtoken PS DA TS HLAreliable Update type Update Condition

Static NA Semantics

A.2.2. Datatypes


FacingDegreesFloat32 Representation: HLAfloat32BE Units: Degrees Resolution: NA Accuracy: Perfect Semantics:



RangeFloat32 Representation: HLAfloat32BE Units: Meters Resolution: NA Accuracy: Perfect Semantics: Range of sensor.

CombatValueFloat64 Representation: HLAfloat64BE Units: Percent Resolution: NA Accuracy: NA Semantics: Percent of unit effectiveness.

QuantityFloat64 Representation: HLAfloat64BE Units: NA Resolution: NA Accuracy: NA Semantics: The number of units.

PercentageUint32 Representation: RPRunsignedInteger32BE Units: Percent Resolution: 1 Accuracy: Perfect Semantics: A simple datatype using units of percent.




WeaponControlOrderEnum8 Representation: HLAoctet Semantics: The enumerations for weapon control.

Enumerator Value

WeaponsFree 1

WeaponsHold 3

Other 0

WeaponsTight 2

CaptureStatusEnum8 Representation: HLAoctet Semantics: The status of a person or unit with respect to their control or influence over their own activities.

Enumerator Value

Not-Captured 1

Captured 2

AttemptingSurrender 3

Other 0

EchelonEnum8 Representation: HLAoctet Semantics: The specific value that represents the relative size of the commonly accepted configuration of military formations (from JC3IEDM echelon-size-code).



Enumerator Value

Army 1 ArmyGroup 2 Battalion 3 BattalionGroup 4 BattleGroup 5 Brigade 6 BrigadeGroup 7 Company 8 CompanyGroup 9 Corps 10 Division 11 Fleet 12 Flight 13 Platoon 14 Regiment 15 Region 16 Section 17 Squad 18 SquadronAir 19 SquadronMaritime 20 TaskElementNavy 21 TaskForceNavy 22 TaskGroupNavy 23 TaskUnitNavy 24



Enumerator Value

TeamFireteamCrew 25 Wing 26 NotKnown 27 NotOtherwiseSpecified 28

SupportRelationshipEnum8 Representation: HLAoctet Semantics: Enumeration of different support relationships.

Enumerator Value

Engineering 5 GeneralSupportArtillery 4 Logistics 1 Other 0 DirectSupportArtillery 2 DirectSupportReinforcingArtillery 3

CoverEnum8 Representation: HLAoctet Semantics: The type of cover utilized by an aggregate.

Enumerator Value

StrongPoints 5 FightingPositionsWithOverheadCover 4 CrewServedWeaponsPositions 3



Enumerator Value

Other 0 HastyFightingPositions 1 IndividualFightingPositions 2

EntityCategoryEnum32 Representation: RPRunsignedInteger32BE Semantics: Category of entity.

Enumerator Value

Invalid 0 EquipmentEntity 1 PersonnelEntity 2 EmitterEntity 3 RadioEntity 4

ConcealmentEnum32 Representation: RPRunsignedInteger32BE Semantics: The reason for the objects concealment.

Enumerator Value

Invalid 0 InOpen 1 MountedInternally 2 MountedExternally 3 UnderNet 4



Enumerator Value

UnderGround 5 InsideStructure 6 FightingPositionCovered 7 FightingPositionUncovered 8

UpdateTypeEnum32 Representation: RPRunsignedInteger32BE Semantics: Used to create, change, or delete an EntityList.

Enumerator Value

Invalid 0 Create 1 Update 2 Addition 3 Delete 4

SensorStateEnum32 Representation: RPRunsignedInteger32BE Semantics: The emission states of aggregate sensors.

Enumerator Value

OnButNotEmitting 2 Off 1 Other 0 OnAndEmitting 3




ArrayOfResourceStatus Element Type: ResourceStatusNumberStruct Cardinality: [1..2147483647] Encoding: HLAvariableArray Semantics: The array of health states for a named resource.

ArrayOfEntityStruct Element Type: EntityStruct Cardinality: [1..2147483647] Encoding: HLAvariableArray Semantics: Data for one or more entities that comprise an entity list.

ArrayOfSensorStruct Element Type: SensorStruct Cardinality: [1..2147483647] Encoding: HLAvariableArray Semantics: Array with definitio0ns of sensors, 1+ cardinality.


VisualSignatureStruct Encoding: HLAfixedRecord Semantics:



Name Type Semantic

DVOSignaturePercent PercentageUint32

A summary percentage of an aggregates susceptibility to detection by direct view optics, i.e. the human eye, binoculars, or telescopes. A unit with zero percent signature would be concealed from DVO detection.

I2SignaturePercent PercentageUint32 A summary percentage of an aggregates susceptibility to detection by Image Intensifying sensors. A unit with zero percent signature would be invisible to image intensifiers (I2).

ThermalSignaturePercent PercentageUint32 A summary percentage of an aggregates susceptibility to detection by thermal sensors. A unit with zero percent signature would be invisible to thermal sensors.

MissionStruct Encoding: HLAfixedRecord Semantics: The operational task the aggregate has been ordered to perform, the time the mission was assigned, and the estimated completion time.

Name Type Semantic

StartTime TimeSecInt64 An optional field providing the mission start time.

EndTime TimeSecInt64 An optional field providing the mission estimated end time.

MissionEnum AggregateMissionEnum16 The mission assigned to the aggregate.

SupportRelationshipStruct Encoding: HLAfixedRecord Semantics: Identifies unit(s) which support the aggregate logistically, or with a specified combat or combat support relationship, e.g. a Direct Support or General Support Artillery unit.



Name Type Semantic

SupportConsumer UuidArrayOfHLAbyte16 The unique ID of the consumer of the support.

SupportProvider UuidArrayOfHLAbyte16 The unique ID of the provider of the support.

SupportType SupportRelationshipEnum8 The type of support provided by the supporting unit.

HUMINTSignatureStruct Encoding: HLAfixedRecord Semantics: Describes the unit's susceptibility to human intelligence (HUMINT), i.e. information collected and provided by human sources.

Name Type Semantic

HUMINTSignaturePercent PercentageUint32 A summary percentage of an aggregates susceptibility to detection by human intelligence collectors. Zero percent signature means an aggregate is impervious to HUMINT.

ElectronicSignatureStruct Encoding: HLAfixedRecord Semantics: A summary percentage of an aggregates susceptibility to detection of its electronic emissions. Zero percent means that the aggregate has no electronic emissions.

Name Type Semantic

ElectronicSignaturePercent PercentageUint32 A summary percentage of an aggregates susceptibility to detection of its electronic emissions. Zero percent means that the aggregate has no electronic emissions.

SensorArray ArrayOfSensorStruct A list of sensors owned by the aggregate together with their respective operational status and range.



CoverStatusStruct Encoding: HLAfixedRecord Semantics:

Name Type Semantic

CoverStatusPercent PercentageUint32 The percentage of protection enjoyed by an aggregate. A unit with 100 percent cover would be impervious to the effects of weapons fire.

CoverTypeEnum CoverEnum8 An optional field describing the type of cover employed by the aggregate.

EntityListVariableLengthStruct Encoding: HLAfixedRecord Semantics: Provides data on one or more entities comprising the aggregate. This includes the initial list of all entities and subsequent updates as entities on the list experience change.

Name Type Semantic

UpdateType UpdateTypeEnum32 Indicates whether this update creates the list or modifies its' values.

EntityList ArrayOfEntityStruct Data about one or more entities comprising the list.

ResourceStatusNumberStruct Encoding: HLAfixedRecord Semantics: The name of a resource and the number of instances of that resource by health status.

Name Type Semantic

NumberHealthyOrIntact QuantityFloat64 The number of healthy or intact resources. NumberSlightlyDamaged QuantityFloat64 The number of slightly damaged resources.



Name Type Semantic

NumberModeratelyDamaged QuantityFloat64 The number of moderately damaged resources. NumberSignificantlyDamaged QuantityFloat64 The number of significantly damaged resources. NumberDestroyed QuantityFloat64 The number of destroyed or consumed resources. ResourceName HLAunicodeString The name of the resource.

EntityStruct Encoding: HLAfixedRecord Semantics: An entity represented to the federation as part of the aggregate object which owns it.

Name Type Semantic

Callsign HLAunicodeString The unique identifier of the object.

EntityCategory EntityCategoryEnum32 Indicates whether the entity is equipment, person, emitter, etc.

EntityStatus DamageStatusEnhancedEnum32 The damage state of the entity.

IsDistinctObject RPRboolean OPTIONAL. A BaseEntity object has been created to represent this entity (true) or not (false). Default is false.

IsUnavailable RPRboolean OPTIONAL. This entity is in use by another object (true) or not (false). Default is false.

Facing FacingDegreesFloat32 OPTIONAL. Direction is measured in degrees clockwise from orientation of unit. Default is 0.

Concealment ConcealmentEnum32 OPTIONAL. Indicates whether the entity is concealed and, if so, how.

OffsetLocation RelativePositionStruct The entity location given as an offset from the location of the aggregate unit in meters.



SensorStruct Encoding: HLAfixedRecord Semantics: Defines a sensor,operational status, damage status, coverage and ID.

Name Type Semantic

SensorStateEnum SensorStateEnum32 The operational status of the sensor. SensorDamageState DamageStatusEnum32 The damage status of the sensor. SensorCoverage RangeFloat32 The maximum range of the sensor. SensorID HLAunicodeString A sensor owned by the aggregate.



A.3. MODULE NETN-PHYSICAL_v1.1.2

Information

Name: NETN-Physical Type: FOM Version: v1.1.2 Modification Date: 2014-09-25 Security Classification: Unclassified Purpose: Application Domain: Training

Description: Object class inherit from RPR Physical. Object classes and datatypes from NETN FOM v1, module: AggDeagg.

Use Limitation: Other:






References

Dependency NETN-Base_v1.0 Dependency RPR-Aggregate_v2.0

Use History

v1.0.0 - Initial, object classes and datatypes from FOM modules in NETN FOM v1. v1.1.0 - Added object class NETN_CulturalFeature. v1.1.1 - Updated References, Dependency. v1.1.2 - Update of semantics, spell corrections.

Dependencies

NETN-Base_v1.0.2 RPR-Physical_v2.0_draft19.10 RPR-Base_v2.0_draft19.10 RPR-Enumerations_v2.0_draft19.10 RPR-Foundation_v2.0_draft19.10






A.3.1.1. NETN_Aircraft

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.Aircraft.NETN_Aircraft Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

Callsign


HLAunicodeString PS RO HLAbestEffort Update type Update Condition



Status





Activity




The activity of the object.



EmbeddedUnitList




List of unique IDs of on-board elements.

UniqueID


UuidArrayOfHLAbyte16 PS RO HLAbestEffort Update type Update Condition

Static NA Semantics

The unique dentifier of the object. Required value. If not assigned by the ORBAT specification or similar, shall a value be assigned, either randomized or generated from the Marking or EntityIdentifier attribute value.

AfterburnerOn Inherited from Platform in RPR-Physical_v2.0_draft19.10


RPRboolean PS DA RO HLAbestEffort Update type Update Condition


Whether the entity's afterburner is on or not.

AntiCollisionLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's anti-collision lights are on or not.



BlackOutBrakeLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's black out brake lights are on or not.

BlackOutLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's black out lights are on or not.

BrakeLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's brake lights are on or not.

FormationLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's formation lights are on or not.



HatchState Inherited from Platform in RPR-Physical_v2.0_draft19.10


HatchStateEnum32 PS DA RO HLAbestEffort Update type Update Condition


The state of the entity's (main) hatch.

HeadLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's headlights are on or not.

InteriorLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's internal lights are on or not.

LandingLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's landing lights are on or not.



LauncherRaised Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's weapon launcher is in the raised position.

NavigationLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's navigation lights are on or not.

RampDeployed Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity has deployed a ramp or not.

RunningLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's running lights are on or not.



SpotLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's spotlights are on or not.

TailLightsOn Inherited from Platform in RPR-Physical_v2.0_draft19.10




Whether the entity's tail lights are on or not.

AcousticSignatureIndex Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Index used to obtain the acoustics (sound through air) signature state of the entity.

AlternateEntityType Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10



Static NA Semantics

The category of entity to be used when viewed by entities on the 'opposite' side.



ArticulatedParametersArray Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


ArticulatedParameterStructLengthlessArray PS DA RO HLAbestEffort Update type Update Condition


Identification of the visible parts, and their states, of the entity which are capable of independent motion.

CamouflageType Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


CamouflageEnum32 PS DA RO HLAbestEffort Update type Update Condition


The type of camouflage in use (if any).

DamageState Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


DamageStatusEnum32 PS DA RO HLAbestEffort Update type Update Condition


The state of damage of the entity.

EngineSmokeOn Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity's engine is generating smoke or not.



FirePowerDisabled Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity's main weapon system has been disabled or not.

FlamesPresent Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity is on fire (with visible flames) or not.

ForceIdentifier Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




The identification of the force that the entity belongs to.

HasAmmunitionSupplyCap Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10



Static NA Semantics

Whether the entity has the capability to supply other entities with ammunition.



HasFuelSupplyCap Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10



Static NA Semantics

Whether the entity has the capability to supply other entities with fuel or not.

HasRecoveryCap Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10



Static NA Semantics

Whether the entity has the capability to recover other entities or not.

HasRepairCap Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10



Static NA Semantics

Whether the entity has the capability to repair other entities or not.

Immobilized Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity is immobilized or not.



InfraredSignatureIndex Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Index used to obtain the infra-red signature state of the entity.

IsConcealed Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity is concealed or not.

LiveEntityMeasuredSpeed Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


VelocityDecimeterPerSecondInteger16 PS DA RO HLAbestEffort Update type Update Condition


The entity's own measurement of speed (e.g. air speed for aircraft).

Marking Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


MarkingStruct PS DA RO HLAbestEffort Update type Update Condition


A unique marking or combination of characters used to distinguish the entity from other entities.



PowerPlantOn Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity's power plant is on or not.

PropulsionSystemsData Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


PropulsionSystemDataStructLengthlessArray PS DA RO HLAbestEffort Update type Update Condition


The basic operating data of the propulsion systems aboard the entity.

RadarCrossSectionSignatureIndex Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Index used to obtain the radar cross section signature state of the entity.

SmokePlumePresent Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity is generating smoke or not (intentional or unintentional).



TentDeployed Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10




Whether the entity has deployed tent or not.

TrailingEffectsCode Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


TrailingEffectsCodeEnum32 PS DA RO HLAbestEffort Update type Update Condition


The type and size of any trail that the entity is making.

VectoringNozzleSystemData Inherited from PhysicalEntity in RPR-Physical_v2.0_draft19.10


VectoringNozzleSystemDataStructLengthlessArray PS DA RO HLAbestEffort Update type Update Condition


The basic operational data for the vectoring nozzle systems aboard the entity.




Static NA Semantics







Static NA Semantics






















Static NA Semantics

A.3.1.2. NETN_AmphibiousVehicle

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.AmphibiousVehicle.NETN_AmphibiousVehicle Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

Callsign





Status







Activity





EmbeddedUnitList





UniqueID



Static NA Semantics

The unique identifier of the object. Required value. If not assigned by the ORBAT specification or similar, shall a value be assigned, either randomized or generated from the Marking or EntityIdentifier attribute value.



































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics





















VelocityDecimeterPerSecondInteger16

PS DA RO HLAbestEffort Update type Update Condition




















































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.3.1.3. NETN_GroundVehicle

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.GroundVehicle.NETN_GroundVehicle Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

Callsign



Static NA Semantics




Status





Activity





EmbeddedUnitList





UniqueID



Static NA Semantics




































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics







Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.3.1.4. NETN_MultiDomainPlatform

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.MultiDomainPlatform.NETN_MultiDomainPlatform Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:



Callsign



Static NA Semantics


Status





Activity





EmbeddedUnitList







UniqueID



Static NA Semantics


































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics







Static NA Semantics





Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.3.1.5. NETN_Spacecraft

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.Spacecraft.NETN_Spacecraft Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

Callsign



Static NA Semantics


Status





Activity







EmbeddedUnitList





UniqueID



Static NA Semantics


































































































Static NA Semantics












































Static NA Semantics







Static NA Semantics





Static NA Semantics





Static NA Semantics







































































Static NA Semantics







Static NA Semantics






















Static NA Semantics

A.3.1.6. NETN_SubmersibleVehicle

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.SubmersibleVessel.NETN_SubmersibleVehicle Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

Callsign



Static NA Semantics


Status







Activity





EmbeddedUnitList





UniqueID



Static NA Semantics




































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.3.1.7. NETN_SurfaceVessel

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform. SurfaceVessel.NETN_SurfaceVessel Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

Callsign



Static NA Semantics




Status





Activity





EmbeddedUnitList





UniqueID



Static NA Semantics




































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics







Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.3.1.8. NETN_NonHuman

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Lifeform.NonHuman.NETN_NonHuman Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:



Callsign



Static NA Semantics


Status





Activity





UniqueID



Static NA Semantics




FlashLightsOn Inherited from Lifeform in RPR-Physical_v2.0_draft19.10




Whether the lifeform's flash lights are on or not.

StanceCode Inherited from Lifeform in RPR-Physical_v2.0_draft19.10


StanceCodeEnum32 PS DA RO HLAbestEffort Update type Update Condition


The stance of the lifeform.

PrimaryWeaponState Inherited from Lifeform in RPR-Physical_v2.0_draft19.10


WeaponStateEnum32 PS DA RO HLAbestEffort Update type Update Condition


The state of the soldier's primary weapon system.

SecondaryWeaponState Inherited from Lifeform in RPR-Physical_v2.0_draft19.10




The state of the soldier's secondary weapon system.



ComplianceState Inherited from Lifeform in RPR-Physical_v2.0_draft19.10


ComplianceStateEnum32 PS DA RO HLAbestEffort Update type Update Condition


The compliance of the lifeform.









Static NA Semantics












































Static NA Semantics





Static NA Semantics







Static NA Semantics





Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.3.1.9. NETN_Human

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Lifeform.Human.NETN_Human Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

Callsign



Static NA Semantics


Status


ActiveStatusEnum8 PS RO HLAbestEffort Update type Update Condition



Activity


AggregateMissionEnum16 PS RO HLAbestEffort Update type Update Condition





UniqueID



Static NA Semantics





































Static NA Semantics












































Static NA Semantics







Static NA Semantics





Static NA Semantics





Static NA Semantics







































































Static NA Semantics







Static NA Semantics






















Static NA Semantics

A.3.1.10. NETN_CulturalFeature

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.CulturalFeature.NETN_CulturalFeature Sharing: Publish/Subscribe Semantics: Extensions for NETN. Attributes:

UniqueID



Static NA Semantics




Callsign



Static NA Semantics

Name of the object.

Status





Activity





EmbeddedUnitList







ExternalLightsOn Inherited from CulturalFeature in RPR-Physical_v2.0_draft19.10




Whether the cultural feature's external lights are on or not.

InternalHeatSourceOn Inherited from CulturalFeature in RPR-Physical_v2.0_draft19.10




Whether the cultural feature's internal heat source is on or not.

InternalLightsOn Inherited from CulturalFeature in RPR-Physical_v2.0_draft19.10




Whether the cultural feature's internal lights are on or not.











Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.4. MODULE CBRN_v1.1.9

Information

Name: CBRN Type: FOM Version: v1.1.9 Modification Date: 2014-12-17 Security Classification: Unclassified Purpose: Application Domain: Training Description: The CBRN FOM module specifies objects and interactions necessary to enable CBRN modelling. Use Limitation: Other:


Name: Hazard Assessment Simulation and Prediction (HASP) Group Organization: Defence Science and Technology Laboratory (Dstl) Telephone: +44 (0) 1980 613121 Email: [email protected]




References

Dependency NETN-Base_v1.0 Dependency NETN-Physical_v1.1 Dependency RPR-Base_v2.0 Dependency RPR-Physical_v2.0

Use History

v1.0.0 - Initial; object, interaction classes and datatypes. v1.0.1 - Added semantics. v1.0.2 - Added missing QuantityUInt32 simple data type, fixed IPEEnum values. v1.1.0 - Added new attributes to ATP45HazardArea, CBRN_Sensor and CBRN_Detector. Added parent interaction type to COLPROUpdate and DecontaminationStationUpdate. Re-used existing RPR and NETN simple data types. Renamed several data types and attribute names. v1.1.1 - Added references to dependencies. v1.1.2 - Added ValidityTime attribute to ATP45HazardArea. v1.1.3 - Updated the description. v1.1.4 - Added CBRN_PlatformUpdate interaction. v1.1.5 - Updated semantics. v1.1.6 - Standardised on Agent for agent name. Used correct naming convention for CBRN_FacilityUpdate. v1.1.7 - Changed update conditions for certain attributes. Added UniqueID attributes to hazard contours. v1.1.8 - Added TIC agents to AgentTypeEnum16. v1.1.9 - Added POC information.



Dependencies

NETN-Base_v1.0.2 NETN-Physical_v1.1.2 RPR-Base_v2.0_draft19.10 RPR-Physical_v2.0_draft19.10 RPR-Enumerations_v2.0_draft19.10 RPR-Foundation_v2.0_draft19.10






A.4.1.1. ATP45HazardArea

Full Name: HLAobjectRoot.ATP45HazardArea Sharing: Publish/Subscribe Semantics: Represents the footprint generated by a CBRN warning and reporting simulation. This follows the NATO ATP-45 doctrine to generate a hazard area. Attributes:

Time


TimeSecInt64 PS DA RO HLAbestEffort Update type Update Condition


Simulation time at which this hazard area was generated.

ValidityTime


TimeSecondInteger32 PS DA RO HLAbestEffort Update type Update Condition


Duration (in seconds) from the Time attribute that this hazard area prediction is valid.

Locations


ArrayOfWorldLocationStruct3 PS DA RO HLAbestEffort Update type Update Condition


Array of locations that define the hazard area.



ATP45HazardAreaType


ATP45HazardAreaTypeEnum8 PS DA RO HLAbestEffort Update type Update Condition


This hazard area's type.

AgentClass


AgentClassEnum8 PS DA RO HLAbestEffort Update type Update Condition


The agent class.

UniqueID




Unique representation of the area’s ID.




Static NA Semantics



A.4.1.2. COLPRO

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.CulturalFeature.NETN_CulturalFeature.COLPRO Sharing: Publish/Subscribe Semantics: Represents a feature that provides Collective Protection (COLPRO) against a CBRN threat. Attributes:

NumberEntities


QuantityUInt32 PS DA RO HLAbestEffort Update type Update Condition


The number of entities that this COLPRO can handle.

Protection


ArrayOfProtectionEffectivenessStruct PS DA RO HLAbestEffort Update type Update Condition


The effectiveness that this COLPRO offers for each agent.

UniqueID Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2



Static NA Semantics




Callsign Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2



Static NA Semantics

Name of the object.

Status Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2





Activity Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2
































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.4.1.3. DecontaminationStation

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.CulturalFeature.NETN_CulturalFeature.DecontaminationStation Sharing: Publish/Subscribe Semantics: Represents a feature that provides treatment for CBRN exposure. Attributes:

NumberEntities


QuantityUInt32 PS DA RO HLAbestEffort Update type Update Condition


The number of entities that this decontamination station can handle.



DecontaminationPeriod




Duration in seconds it takes to decontaminate an entity.

Treatments


ArrayOfTreatmentStruct PS DA RO HLAbestEffort Update type Update Condition


The types of treatment that this decontamination station currently offers.

UniqueID Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2



Static NA Semantics


Callsign Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2



Static NA Semantics

Name of the object.



Status Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2





Activity Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_CulturalFeature in NETN-Physical_v1.1.2






























Static NA Semantics












































Static NA Semantics







Static NA Semantics





Static NA Semantics





Static NA Semantics







































































Static NA Semantics







Static NA Semantics






















Static NA Semantics

A.4.1.4. CBRN_Human

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Lifeform.Human.NETN_Human.CBRN_Human Sharing: Publish/Subscribe Semantics: Extension of NETN_Human to provide CBRN modelling. Attributes:

Exposures


ArrayOfCBRNExposureStruct PS DA RO HLAbestEffort Update type Update Condition


Array of agents to which this entity has been exposed to. Defaults to an empty array.

Treatments


ArrayOfTreatmentStruct PS DA RO HLAbestEffort Update type Update Condition


The types of treatment that this entity has used. Defaults to an empty array.



TriageLevel


CBRNDamageEnum8 PS DA RO HLAbestEffort Update type Update Condition


Triage level of this entity. Defaults to Uninjured.

IPEType


IPETypeEnum8 PS DA RO HLAbestEffort Update type Update Condition


Type of IPE that the entity has donned. Defaults to None.

Callsign Inherited from NETN_Human in NETN-Physical_v1.1.2



Static NA Semantics


Status Inherited from NETN_Human in NETN-Physical_v1.1.2


ActiveStatusEnum8 PS RO HLAbestEffort Update type Update Condition





Activity Inherited from NETN_Human in NETN-Physical_v1.1.2


AggregateMissionEnum16 PS RO HLAbestEffort Update type Update Condition



UniqueID Inherited from NETN_Human in NETN-Physical_v1.1.2



Static NA Semantics







































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.4.1.5. CBRN_Aircraft

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.Aircraft.NETN_Aircraft.CBRN_Aircraft Sharing: Publish/Subscribe Semantics: Extension of NETN_Aircraft to provide CBRN modelling. Attributes:

Contamination


ArrayOfAgentMassStruct PS DA RO HLAbestEffort Update type Update Condition


CBRN hazardous agent inside vehicle due to embedded units.



Callsign Inherited from NETN_Aircraft in NETN-Physical_v1.1.2





Status Inherited from NETN_Aircraft in NETN-Physical_v1.1.2





Activity Inherited from NETN_Aircraft in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_Aircraft in NETN-Physical_v1.1.2







UniqueID Inherited from NETN_Aircraft in NETN-Physical_v1.1.2



Static NA Semantics


































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics







Static NA Semantics





Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.4.1.6. CBRN_AmphibiousVehicle

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.AmphibiousVehicle.NETN_AmphibiousVehicle.CBRN_ AmphibiousVehicle Sharing: Publish/Subscribe Semantics: Extension of NETN_AmphibiousVehicle to provide CBRN modelling. Attributes:

Contamination





Callsign Inherited from NETN_AmphibiousVehicle in NETN-Physical_v1.1.2





Status Inherited from NETN_AmphibiousVehicle in NETN-Physical_v1.1.2







Activity Inherited from NETN_AmphibiousVehicle in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_AmphibiousVehicle in NETN-Physical_v1.1.2





UniqueID Inherited from NETN_AmphibiousVehicle in NETN-Physical_v1.1.2



Static NA Semantics




































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.4.1.7. CBRN_GroundVehicle

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.GroundVehicle.NETN_GroundVehicle.CBRN_GroundVehicle Sharing: Publish/Subscribe Semantics: Extension of NETN_GroundVehicle to provide CBRN modelling. Attributes:

Contamination







Callsign Inherited from NETN_GroundVehicle in NETN-Physical_v1.1.2



Static NA Semantics


Status Inherited from NETN_GroundVehicle in NETN-Physical_v1.1.2





Activity Inherited from NETN_GroundVehicle in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_GroundVehicle in NETN-Physical_v1.1.2







UniqueID Inherited from NETN_GroundVehicle in NETN-Physical_v1.1.2



Static NA Semantics


































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics







Static NA Semantics





Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.4.1.8. CBRN_MultiDomainPlatform

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.MultiDomainPlatform.NETN_MultiDomainPlatform.CBRN _MultiDomainPlatform Sharing: Publish/Subscribe Semantics: Extension of NETN_MultiDomainPlatform to provide CBRN modelling. Attributes:

Contamination





Callsign Inherited from NETN_MultiDomainPlatform in NETN-Physical_v1.1.2



Static NA Semantics


Status Inherited from NETN_MultiDomainPlatform in NETN-Physical_v1.1.2







Activity Inherited from NETN_MultiDomainPlatform in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_MultiDomainPlatform in NETN-Physical_v1.1.2





UniqueID Inherited from NETN_MultiDomainPlatform in NETN-Physical_v1.1.2



Static NA Semantics




































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.4.1.9. CBRN_Spacecraft

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.Spacecraft.NETN_Spacecraft.CBRN_Spacecraft Sharing: Publish/Subscribe Semantics: Extension of NETN_Spacecraft to provide CBRN modelling. Attributes:

Contamination







Callsign Inherited from NETN_Spacecraft in NETN-Physical_v1.1.2



Static NA Semantics


Status Inherited from NETN_Spacecraft in NETN-Physical_v1.1.2





Activity Inherited from NETN_Spacecraft in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_Spacecraft in NETN-Physical_v1.1.2







UniqueID Inherited from NETN_Spacecraft in NETN-Physical_v1.1.2



Static NA Semantics


































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics







Static NA Semantics





Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.4.1.10. CBRN_SubmersibleVehicle

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.SubmersibleVessel.NETN_SubmersibleVehicle.CBRN_ SubmersibleVehicle Sharing: Publish/Subscribe Semantics: Extension of NETN_SubmersibleVehicle to provide CBRN modelling. Attributes:

Contamination





Callsign Inherited from NETN_SubmersibleVehicle in NETN-Physical_v1.1.2



Static NA Semantics


Status Inherited from NETN_SubmersibleVehicle in NETN-Physical_v1.1.2







Activity Inherited from NETN_SubmersibleVehicle in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_SubmersibleVehicle in NETN-Physical_v1.1.2





UniqueID Inherited from NETN_SubmersibleVehicle in NETN-Physical_v1.1.2



Static NA Semantics




































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.4.1.11. CBRN_SurfaceVessel

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Platform.SurfaceVessel.NETN_SurfaceVessel.CBRN_SurfaceVessel Sharing: Publish/Subscribe Semantics: Extension of NETN_SurfaceVessel to provide CBRN modelling. Attributes:

Contamination







Callsign Inherited from NETN_SurfaceVessel in NETN-Physical_v1.1.2



Static NA Semantics


Status Inherited from NETN_SurfaceVessel in NETN-Physical_v1.1.2





Activity Inherited from NETN_SurfaceVessel in NETN-Physical_v1.1.2





EmbeddedUnitList Inherited from NETN_SurfaceVessel in NETN-Physical_v1.1.2







UniqueID Inherited from NETN_SurfaceVessel in NETN-Physical_v1.1.2



Static NA Semantics


































































































Static NA Semantics












































Static NA Semantics





Static NA Semantics







Static NA Semantics





Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.4.1.12. CBRN_Detector

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Sensor.CBRN_Detector Sharing: Publish/Subscribe Semantics: Represents a CBRN detector. This object is used to pass information to a CBRN federate, which will model the detector internally and publish a CBRN_DetectorAlarm. Attributes:

UniqueID




Unique representation of the detector’s ID.

ProcessingTime




Duration (in seconds) between the detector being exposed to a concentration of agent above its threshold and the detector raising an alarm.

AveragingTime




Duration (in seconds) over which the detector will collect samples.



DetectableAgents


ArrayOfAgentConcentrationStruct PS DA RO HLAbestEffort Update type Update Condition


Array of detectable agents and their thresholds.

Alarm


CBRNAlarmStruct PS DA RO HLAbestEffort Update type Update Condition


Data representing the alarm of this detector. Defaults to no alarm if the attribute is not set.

AntennaRaised Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's antenna is raised or not.

BlackoutLightsOn Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's blackout lights are on or not.



LightsOn Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's lights are on or not.

InteriorLightsOn Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's interior lights are on or not.

MissionKill Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter has sustained damage that will prevent it carrying out its mission or not (e.g. damaged antenna).











Static NA Semantics












































Static NA Semantics





Static NA Semantics





Static NA Semantics





Static NA Semantics









































































Static NA Semantics





Static NA Semantics






















Static NA Semantics

A.4.1.13. CBRN_Sensor

Full Name: HLAobjectRoot.BaseEntity.PhysicalEntity.Sensor.CBRN_Sensor Sharing: Publish/Subscribe Semantics: Represents a CBRN sensor. This object is used to pass information to a CBRN federate, which will return sensor readings by publishing CBRN_SensorUpdate interactions. Attributes:

UniqueID




Unique representation of the sensor’s ID.



UpdateFrequency




Duration (in seconds) that this sensor would like between updated readings.

AveragingTime




Duration (in seconds) over which the sensor will collect samples.

DetectableAgents


ArrayOfAgentTypeEnum PS DA RO HLAbestEffort Update type Update Condition


Array of agents that this sensor wishes to detect.

SensorReadings


ArrayOfCBRNSensorReadingStruct PS DA RO HLAbestEffort Update type Update Condition


Latest sensor readings. Defaults to no readings if this attribute is not set.



AntennaRaised Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's antenna is raised or not.

BlackoutLightsOn Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's blackout lights are on or not.

LightsOn Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's lights are on or not.

InteriorLightsOn Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter's interior lights are on or not.



MissionKill Inherited from Sensor in RPR-Physical_v2.0_draft19.10




Whether the sensor/emitter has sustained damage that will prevent it carrying out its mission or not (e.g. damaged antenna).









Static NA Semantics












































Static NA Semantics





Static NA Semantics







Static NA Semantics





Static NA Semantics







































































Static NA Semantics





Static NA Semantics






















Static NA Semantics



A.4.1.14. ProbabilityHazardContourGroup

Full Name: HLAobjectRoot.ProbabilityHazardContourGroup Sharing: Publish/Subscribe Semantics: Represents the footprint covered by a CBRN hazard. This object covers the agent-specific effects which would be the output from a casualty model. Attributes:

Time




Simulation time at which this contour group was generated.

Agent


AgentTypeEnum16 PS DA RO HLAbestEffort Update type Update Condition

Static NA Semantics

Agent reflected in this contour.

ExposureType


ExposureTypeEnum8 PS DA RO HLAbestEffort Update type Update Condition

Static NA Semantics

Type of exposure.



Contours


ArrayOfProbabilityHazardContourStruct PS DA RO HLAbestEffort Update type Update Condition


Array of contours. These should be ordered in a sequence of ascending PercentProbabilityLevel.

UniqueID




Unique representation of the contour’s ID.




Static NA Semantics

A.4.1.15. RawDataHazardContourGroup

Full Name: HLAobjectRoot.RawDataHazardContourGroup Sharing: Publish/Subscribe Semantics: Represents the footprint covered by a CBRN hazard. This object covers the raw data which would be the output from a dispersion model. Attributes:



Time




Simulation time at which this contour group was generated.

Agent


AgentTypeEnum16 PS DA RO HLAbestEffort Update type Update Condition

Static NA Semantics

Agent reflected in this contour.

HazardType


HazardTypeEnum8 PS DA RO HLAbestEffort Update type Update Condition

Static NA Semantics

Type of hazard.

Contours


ArrayOfRawDataHazardContourStruct PS DA RO HLAbestEffort Update type Update Condition


Array of contours. These should be ordered in a sequence of ascending ExposureLevel.



UniqueID




Unique representation of the contour’s ID.




Static NA Semantics



A.4.2. Interaction Classes



A.4.2.1. HLAinteractionRoot

Full Name: HLAinteractionRoot Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:

A.4.2.2. CBRN_Casualty

Full Name: HLAinteractionRoot.CBRN_Casualty Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents a CBRN casualty caused by exposure. This is for use with federates that cannot support the TriageLevel attribute in CBRN_Human. Parameters:

Name Datatype Semantics

UniqueID UuidArrayOfHLAbyte16 Unique representation of the entity’s ID. TriageLevel CBRNDamageEnum8 Triage level of this entity. Exposures ArrayOfCBRNExposureStruct Array of agents to which this unit has been exposed.



A.4.2.3. CBRN_DetectorAlarm

Full Name: HLAinteractionRoot.CBRN_DetectorAlarm Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents the alarm trigger of a previously registered CBRN detector. Parameters:


DetectorID UuidArrayOfHLAbyte16 Unique representation of the detector’s ID.

Alarm CBRNAlarmStruct Details of the alarm.

A.4.2.4. CBRN_PlatformUpdate

Full Name: HLAinteractionRoot.CBRN_PlatformUpdate Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents an update to the contaminating mass inside a vehicle due to embedded entities. Parameters:


PlatformID UuidArrayOfHLAbyte16 The unique ID of the platform.

Contamination ArrayOfAgentMassStruct New state of CBRN hazardous agent inside vehicle due to embedded units.



A.4.2.5. CBRN_Release

Full Name: HLAinteractionRoot.CBRN_Release Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Communicates information associated with the release of hazardous agent. Parameters:


UniqueID UuidArrayOfHLAbyte16 Unique representation of the release’s ID. Agent AgentTypeEnum16 The released agent. Location WorldLocationStruct Initial location of the release in the geocentric location system. Mass MassKilogramFloat32 Total released mass in kg. Duration TimeSecondInteger32 Duration in seconds over which the release takes place.

ReleaseSize ReleaseSizeStruct Includes SourceSize (sigmas), mean and variance of released particulates.

ReleaseDynamics ReleaseDynamicsStruct Temperature and buoyancy of released mass. ReleaseVelocity VelocityVectorStruct Velocity of the source term.

A.4.2.6. CBRN_SensorUpdate

Full Name: HLAinteractionRoot.CBRN_SensorUpdate Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions:



Semantics: Sends information about the current state of a previously registered CBRN sensor. Parameters:


Time TimeSecInt64 Time of this sensor update. SensorID UuidArrayOfHLAbyte16 Unique representation of the sensor’s ID. Readings ArrayOfAgentConcentrationStruct Readings for this sensor.

A.4.2.7. CBRN_FacilityUpdate

Full Name: HLAinteractionRoot.CBRN_FacilityUpdate Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents an order for the specified entities to enter or leave the CBRN facility. Parameters:


FacilityID UuidArrayOfHLAbyte16 The unique ID of the CBRN facility.

EmbeddedUnitList ArrayOfUuid List of unique IDs of the entities who will enter or exit the CBRN facility.

IsEntry HLAboolean Determines whether the entities are entering (IsEntry = true) or exiting (IsEntry = false) the CBRN facility.



A.4.2.8. COLPROUpdate

Full Name: HLAinteractionRoot.CBRN_FacilityUpdate.COLPROUpdate Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents an order for the specified entities to enter or leave the COLPRO. Parameters:


FacilityID Inherited from CBRN_FacilityUpdate in CBRN_v1.1.9

UuidArrayOfHLAbyte16 The unique ID of the CBRN facility.

EmbeddedUnitList Inherited from CBRN_FacilityUpdate in CBRN_v1.1.9

ArrayOfUuid List of unique IDs of the entities who will enter or exit the CBRN facility.

IsEntry Inherited from CBRN_FacilityUpdate in CBRN_v1.1.9

HLAboolean Determines whether the entities are entering (IsEntry = true) or exiting (IsEntry = false) the CBRN facility.

A.4.2.9. DecontaminationStationUpdate

Full Name: HLAinteractionRoot.CBRN_FacilityUpdate.DecontaminationStationUpdate Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents an order for the specified entities to enter or leave the decontamination station. Parameters:




FacilityID Inherited from CBRN_FacilityUpdate in CBRN_v1.1.9

UuidArrayOfHLAbyte16 The unique ID of the CBRN facility.

EmbeddedUnitList Inherited from CBRN_FacilityUpdate in CBRN_v1.1.9

ArrayOfUuid List of unique IDs of the entities who will enter or exit the CBRN facility.

IsEntry Inherited from CBRN_FacilityUpdate in CBRN_v1.1.9

HLAboolean Determines whether the entities are entering (IsEntry = true) or exiting (IsEntry = false) the CBRN facility.

A.4.2.10. IPECommand

Full Name: HLAinteractionRoot.IPECommand Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents an order for the specified entities to don protective equipment. Parameters:


UnitList ArrayOfUuid List of unique IDs of the entities who will don IPE. IPEType IPETypeEnum8 Type of IPE that the entities will don.

A.4.2.11. CBRN_TreatmentCommand

Full Name: HLAinteractionRoot.CBRN_TreatmentCommand Sharing: Publish/Subscribe



Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents an order for the specified entities to receive the list of treatments. Parameters:


UnitList ArrayOfUuid List of unique IDs of the entities who will receive the treatment. Treatments TreatmentStruct Type of treatment to be applied to the entities.

A.4.3. Datatypes

A.4.3.1. SimpleDatatypes

ConcentrationKgPerMeterCubedFloat32 Representation: HLAfloat32BE Units: Kg Per Meter Cubed Resolution: NA Accuracy: Perfect Semantics: Concentration in SI units.

DensityRatioFloat32 Representation: HLAfloat32BE Units: NA Resolution: NA Accuracy: Perfect Semantics: Ratio of density of two materials in range [0, 1].



DosageKgSecondPerMeterCubedFloat32 Representation: HLAfloat32BE Units: Kg Second Per Meter Cubed Resolution: NA Accuracy: Perfect Semantics: Dosage in SI units.

ExposureFloat32 Representation: HLAfloat32BE Units: NA Resolution: NA Accuracy: Perfect Semantics: Data type for exposure.

MeanMetersFloat32 Representation: HLAfloat32BE Units: Meters Resolution: NA Accuracy: Perfect Semantics: Mean of a Gaussian distribution, based on SI unit meter, unit symbol m.

QuantityUInt32 Representation: RPRunsignedInteger32BE Units: NA Resolution: NA Accuracy: Perfect Semantics: Quantity in range [0, 2^32-1].



VarianceMetersSquaredFloat32 Representation: HLAfloat32BE Units: Meters squared Resolution: NA Accuracy: Perfect Semantics: Variance of a Gaussian distribution, based on SI unit meter squared, unit symbol m2.


AgentClassEnum8 Representation: HLAoctet Semantics: Class of Agent for an ATP-45 Hazard Area.

Enumerator Value

Chemical 0 Biological 1 Radiological 2 Nuclear 3

AgentTypeEnum16 Representation: HLAinteger16BE Semantics: Type of CBRN hazardous agent.

Enumerator Value

Chemical 1000 Choking 1100



Enumerator Value

CG 1102 Persistent_Nerve 1200 GA 1201 GB 1202 GD 1203 GF 1204 VX 1205 Non_Persistent_Nerve 1300 Vesicant 1400 HD 1401 Blood_Agent 1500 AC 1501 CK 1502 Riot_Control 1700 Toxic_Industrial_Chemical 1800 TIC1 1801 TIC2 1802 Biological 2000 Bacterial 2100 Anthrax 2101 Plague 2102 Toxin 2200 Virus 2300 Radiological 3000



Enumerator Value

Alpha 3100 Beta 3200 Gamma 3300 Delta 3400 Nuclear 4000

ATP45HazardAreaTypeEnum8 Representation: HLAoctet Semantics: Type of ATP-45 Hazard Area (simple or detailed).

Enumerator Value

Simple 0 Detailed 1

CBRNDamageEnum8 Representation: HLAoctet Semantics: Level of damage due to CBRN exposure.

Enumerator Value

Uninjured 0 T3 1 T2 2 T1 3 T4 4 Dead 5



ExposureTypeEnum8 Representation: HLAoctet Semantics: Type of exposure represented in a contour group.

Enumerator Value

Exposure 0 Incapacitation 1 Lethal 2

HazardTypeEnum8 Representation: HLAoctet Semantics: Type of dispersion output represented in a contour group.

Enumerator Value

Concentration 0 Deposition 1 Dosage 2 RadiologicalDose 3 RadiologicalDoseRate 4

IPETypeEnum8 Representation: HLAoctet Semantics: Types of Individual Protective Equipment.

Enumerator Value

None 0 One 1



OneR 2 Two 3 TwoR 4 Three 5 ThreeR 6 Four 7 FourR 8


ArrayOfAgentConcentrationStruct Element Type: AgentConcentrationStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of agents and their concentrations.

ArrayOfAgentMassStruct Element Type: AgentMassStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of agents and their masses.

ArrayOfAgentTypeEnum Element Type: AgentTypeEnum16 Cardinality: Dynamic



Encoding: HLAvariableArray Semantics: Array of agents.

ArrayOfCBRNExposureStruct Element Type: CBRNExposureStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of agents and their dosages.

ArrayOfCBRNSensorReadingStruct Element Type: CBRNSensorReadingStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of sensor readings.

ArrayOfProbabilityHazardContourStruct Element Type: ProbabilityHazardContourStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of Probability Hazard Contours.

ArrayOfProtectionEffectivenessStruct Element Type: ProtectionEffectivenessStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of the protection’s effectiveness.



ArrayOfRawDataHazardContourStruct Element Type: RawDataHazardContourStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of Raw Data Hazard Contours.

ArrayOfSigmas6 Element Type: LengthMeterFloat32 Cardinality: 6 Encoding: HLAfixedArray Semantics: Size of the initial Gaussian puff sigma values.

ArrayOfTreatmentStruct Element Type: TreatmentStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of TreatmentStruct types.


AgentConcentrationStruct Encoding: HLAfixedRecord Semantics: Concentration value associated with a specific agent.

Name Type Semantic

MeanConcentration ConcentrationKgPerMeterCubedFloat32 Concentration in kg m-3. Agent AgentTypeEnum16 Enumeration representation of the agent.



AgentMassStruct Encoding: HLAfixedRecord Semantics: Mass of contaminant inside a vehicle brought in by an embedded unit.

Name Type Semantic

ContaminatedMass MassKilogramFloat32 Mass in kg of contaminant. Agent AgentTypeEnum16 Enumeration representation of the agent.

CBRNAlarmStruct Encoding: HLAfixedRecord Semantics: Properties of a CBRN alarm.

Name Type Semantic

Time TimeSecInt64 Simulation time of this detector alarm. Location WorldLocationStruct Location of the detector alarm.

Agent AgentTypeEnum16 Agent that the detector believes to have triggered this alarm.

CBRNExposureStruct Encoding: HLAfixedRecord Semantics: Dosage exposure value associated with a specific agent.

Name Type Semantic

Exposure DosageKgSecondPerMeterCubedFloat32 Dosage value (in kg.s.m-3) which has caused this casualty. Defaults to 0.0.

Agent AgentTypeEnum16 Enumeration representation of the agent.



CBRNSensorReadingStruct Encoding: HLAfixedRecord Semantics: Timed CBRN sensor reading.

Name Type Semantic

Time TimeSecInt64 Simulation time of this sensor reading. Reading AgentConcentrationStruct Agent and concentration value in this reading.

ProbabilityHazardContourStruct Encoding: HLAfixedRecord Semantics: Represents the footprint covered by a CBRN hazard. This object covers the agent-specific effects which would be the output from a casualty model.

Name Type Semantic

PercentProbabilityLevel PercentFloat32 Percentage of entities within this contour being affected to the define exposure level.

Locations ArrayOfWorldLocationStruct3 Array of locations that define the probability contour.

ProtectionEffectivenessStruct Encoding: HLAfixedRecord Semantics: Protection effectiveness associated with a specific agent.

Name Type Semantic

Effectiveness PercentFloat32 Percentage by which this protection reduces effects.

Agent AgentTypeEnum16 Enumeration representation of the agent.



RawDataHazardContourStruct Encoding: HLAfixedRecord Semantics: Contour locations bounding a given exposure value.

Name Type Semantic

ExposureLevel ExposureFloat32 Quantity of exposure, measured in SI units. Locations ArrayOfWorldLocationStruct3 Array of locations that define the hazard contour.

ReleaseDistributionStruct Encoding: HLAfixedRecord Semantics: Mean and variance of the distribution of the particles or droplets in a release.

Name Type Semantic

Mean MeanMetersFloat32 Mean size of the released material in meters.

Variance VarianceMetersSquaredFloat32 Variance of the distribution of released particulates/droplets.

ReleaseDynamicsStruct Encoding: HLAfixedRecord Semantics: Defines the dynamic properties of a release.

Name Type Semantic

DensityRatio DensityRatioFloat32 Ratio of material density relative to the atmosphere.

TemperatureDifference TemperatureDegreeCelsiusFloat32 Difference in temperature between the released material and the atmosphere in Celsius.



ReleaseSizeStruct Encoding: HLAfixedRecord Semantics: Defines the properties of the initial size of a release.

Name Type Semantic

SigmaArray ArrayOfSigmas6 Initial Gaussian sigmas of the released puff.

ReleaseDistribution ReleaseDistributionStruct Details regarding the size of the released particles/droplets for non-gaseous materials.

TreatmentStruct Encoding: HLAfixedRecord Semantics: Defines the properties for a CBRN treatment.

Name Type Semantic

UniqueID UuidArrayOfHLAbyte16 The ID of this treatment.

Effectiveness PercentFloat32 Percentage by which this treatment reduces effects.

Duration TimeSecondInteger32 Duration in seconds for which this treatment will remain effective.

TreatmentWindow TimeSecondInteger32 The time window in seconds between exposure and treatment for which this treatment is effective.

TreatableAgents ArrayOfAgentTypeEnum Array of agents that can be treated using this treatment.



A.5. MODULE NETN-SCP-BASE_v1.1.3

Information

Name: New Module Type: FOM Version: 1.1 Modification Date: 2014-05-26 Security Classification: Unclassified Purpose: Application Domain: Training Description: Base for NETN Logistics FOM modules: Supply, Storage, Repair and Transport Use Limitation: Other:


Name: Lennart Olsson Organization: Pitch Technologies Telephone: +46 13705506 Email: [email protected]




References

Dependency NETN-Base_v1.0

Use History

v1.0.0 - Initial, interaction and object classes and datatypes from FOM modules in NETN FOM v1. v1.1.0 - Interaction class RejectOffer: Added parameter Reason. Interaction class CancelService: added parameter Reason. Moved fixed record AppointmentStruct from Transport module to this module. v1.1.1 - Updated semantics. v1.1.2 - Updated References, Dependency. v1.1.3 - Replaced the datatype in parameter ServiceID to NETN_ServiceIdentifier. The format is the equal to the previous but names on fields is changed (buffer compatible).

Dependencies

NETN-Base_v1.0.2 RPR-Base_v2.0_draft19.10 RPR-Enumerations_v2.0_draft19.10 RPR-Foundation_v2.0_draft19.10




A.5.1.1. SCP_Facility COPY-rpr2base_7

Full Name: HLAobjectRoot.BaseEntity.SCP_Facility Sharing: Publish/Subscribe Semantics: Logistics Facility dedicated for supplying, storaging, reparing, and other services. Attributes:

DamageState




Damage State of Facility.

Callsign




Name of the Facility.



IsOperational


HLAboolean PS DA RO HLAbestEffort Update type Update Condition


The operational status of the facility (true = is operational).

ForceIdentifier




Force identifier of owner.

StorageList


NETN_ArrayOfSupplyStruct PS DA RO HLAbestEffort Update type Update Condition


List of the material contained in the facility.

PlatformList




Descripltion of platforms located within the facility.



UniqueID




The unique identifier for the facility.




Static NA Semantics





Static NA Semantics






















Static NA Semantics








A.5.2.2. SCP_Service

Full Name: HLAinteractionRoot.SCP_Service Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_Service interaction class is the base class for all NETN Service Consumer-Provider Pattern interactions. It contains the basic required parameters (not optional) that are always sent. Parameters:


ServiceID NETN_ServiceIdentifier Unique identifier for a service. Consumer Callsign Entity that has requested the service.

Provider Callsign Providing or intended provider entity. If no provider is specified and the request is a common request shall en empty string be used as the Callsign.

ServiceType SCP_ServiceTypeEnum8 Enumerated value describing the type of service.



A.5.2.3. SCP_RequestService

Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The request for a service is always initiated by a SCP_RequestService. Subclasses of this interaction for specific types of services may include parameters for detailing the requirements of this request. This may include information when, where and how the service is to be delivered. Parameters:


RequestTimeOut TimeSecInt64 Wallclock time. The timeout time in seconds after 1 January 1970. ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3

NETN_ServiceIdentifier Unique identifier for a service.

Consumer Inherited from SCP_Service in NETN-SCP-Base_v1.1.3

Callsign Entity that has requested the service.

Provider Inherited from SCP_Service in NETN-SCP-Base_v1.1.3

Callsign Providing or intended provider entity. If no provider is specified and the request is a common request shall en empty string be used as the Callsign.

ServiceType Inherited from SCP_Service in NETN-SCP-Base_v1.1.3

SCP_ServiceTypeEnum8 Enumerated value describing the type of service.



A.5.2.4. SCP_OfferService

Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_OfferService is usually a response to a SCP_RequestService and contains information with respect to the providing entities ability to deliver the requested service. This ability is expressed as either an offer to provide the service or no offer. Subclasses of this interaction for specific types of offers should contain more detailed description of the offer. This may include information about when, where, how the service can be delivered. Parameters:


IsOffering HLAboolean Defines if the requested service is offered (=true) or not (=false). (Not Optional).

RequestTimeOut TimeSecInt64 Wallclock time. The timeout time in seconds after 1 January 1970. ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3










A.5.2.5. SCP_AcceptOffer

Full Name: HLAinteractionRoot.SCP_Service.SCP_AcceptOffer Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_AcceptOffer is used to accept an offer made by a service providing entity as indicated in a SCP_OfferService interaction. By issuing a SCP_AcceptOffer interaction the service consuming entity enters a contract for service delivery with the service producing entity. The SCP_AcceptOffer interaction does not define any additional parameters but subclasses may include parameters with additional information. Parameters:


ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3










A.5.2.6. SCP_ServiceStarted

Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceStarted Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_ServiceStarted interaction is issued by a service providing entity to inform about the start of service delivery. The time of service delivery start may be significantly later then receiving a indication from the consumer that the service delivery can start. The SCP_ServiceStarted interaction does not define any additional parameters. Parameters:












A.5.2.7. SCP_ServiceComplete

Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceComplete Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_ServiceCompleted interaction is used by a service providing entity to inform the service consuming entity that the service has been delivered. The SCP_ServiceCompleted interaction does not define any additional parameters. Parameters:












A.5.2.8. SCP_ServiceReceived

Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceReceived Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The NETN_ServiceReceived interaction is used by a service consuming entity to inform the service providing entity that the service has been delivered. The NETN_ ServiceReceived interaction does not define any additional parameters. Parameters:












A.5.2.9. SCP_RejectOffer

Full Name: HLAinteractionRoot.SCP_Service.SCP_RejectOffer Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_RejectOffer is used to reject an offer made by a service providing entity as indicated in a SCP_OfferService interaction. By issuing a SCP_RejectOffer interaction the service consuming entity informs the providing entity that the offer has been rejected. Parameters:


Reason HLAASCIIstring Allows to inform about the reason of the cancel (free text). ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3










A.5.2.10. SCP_CancelService

Full Name: HLAinteractionRoot.SCP_Service.SCP_CancelService Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_CancelService interaction is used by either a service consuming entity or a service providing entity to inform about early termination of the service delivery or in some cases termination of the service request before delivery has begun. Parameters:


Reason HLAASCIIstring Allows to inform about the reason of the cancel (free text). ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3










A.5.2.11. SCP_ReadyToReceiveService

Full Name: HLAinteractionRoot.SCP_Service.SCP_ReadyToReceiveService Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The SCP_ReadyToReceiveService interaction is issued by a service consuming entity to indicate that the start of service delivery can start. The time of service delivery start may be significantly later then indicating ready for service delivery. The SCP_ReadyToReceiveService interaction does not define any additional parameters. Parameters:












A.5.3. Datatypes


SCP_ServiceTypeEnum8 Representation: HLAoctet Semantics: Description of NETN services, extension of RPR2 ServiceTypeEnum8.

Enumerator Value

Other 0 Resupply 1 Repair 2 Storage 3 Transport 4 CombatAdjudication 5

OfferTypeEnum32 Representation: HLAinteger32BE Semantics: Type of the offer (With restriction, positive, negative).

Enumerator Value

RequestAcknowledgeWithRestriction 0 RequestAcknowledgePositive 1 RequestAcknowledgeNegative 2




ServiceDescription Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: A name associated with the service, e.g. name of the service, the issiuing federate or entity (Callsign).


AppointmentStruct Encoding: HLAfixedRecord Semantics: Date; Time and Location of an appointment. When date and time is set to zero (0), implies no date-time specification.

Name Type Semantic

DateTime TimeSecInt64 Date time in second since 1 junuary 1970 for the appointment.

Location WorldLocationStruct Location of the appointment.

NETN_ServiceIdentifier Encoding: HLAfixedRecord Semantics: An ID associated with the service, shall be unique in the federation execution. E.g. generate the federate id as a string and use this in the ServiceDescription.



Name Type Semantic

EventCount CounterInt32

EventCount shall start at one (1) and then incremented by one (1) for a new NETN Service Provider event and service specified in field Service. In the case where all possible values are exhausted, the numbers may be reused beginning again at one.

Service ServiceDescription A name associated with the service, e.g. name of the service, the issiuing federate or entity (Callsign).

A.5.4. Notes

COPY-rpr2base_7 Semantics: Federates shall send the time at which the data is valid in the user defined tag with every attribute values update and interaction. The time shall be in the first 8 bytes (octets) of the user defined tag, using the DIS timestamp field format (see section 5.2.31 of IEEE 1278.1-1995) converted into hexadecimal ASCII character representation (0-9 and A-F). The ordering of the characters shall be in accordance with section 5.1.1 of IEEE 1278.1-1995, that is most significant octet first, with the most significant bits first (i.e. the character for bits 4-7 precedes the character for bits 0-3). All federates shall transmit this field, even if they do not use it themselves, so that other federates can use its value to compensate for network transport delays.



A.6. MODULE NETN-REPAIR_v1.2.1

Information

Name: NETN-Repair

Type: FOM

Version: 1.2

Modification Date: 2014-05-26

Security Classification: Unclassified

Purpose:

Application Domain: Training

Description: NETN Logistics, Maintenance Pattern, Repair Service

Use Limitation:

Other:






References

Dependency NETN-SCP-Base_v1.1

Use History

v1.0.0 - Initial, interaction classes and datatypes from FOM modules in NETN FOM v1. v1.1.0 - Interaction class RequestRepair: Added parameter Appointment as an optional parameter. Interaction class OfferRepair: Added parameter Appointment as an optional parameter. v1.1.1 - Semantics updates. v1.2.1 - Added new interactions, ReadyToReceiveRepair and RepairComplete.

Dependencies

NETN-SCP-Base_v1.1.3 NETN-Base_v1.0.2 RPR-Base_v2.0_draft19.10 RPR-Enumerations_v2.0_draft19.10 RPR-Foundation_v2.0_draft19.10





Full Name: HLAinteractionRoot Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Attributes: Parameters:




Full Name: HLAinteractionRoot.SCP_Service Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Attributes: Parameters:











Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService Sharing: Transportation type: HLAreliable



Order: Receive Dimensions: Semantics: Attributes: Parameters:


RequestTimeOut Inherited from SCP_RequestService in NETN-SCP- Base_v1.1.3

TimeSecInt64 Wallclock time. The timeout time in seconds after 1 January 1970.









A.6.1.4. RequestRepair

Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService.RequestRepair Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions:



Semantics: Sent by the consumer when a repair for needed. Specifies entity and type of repair. Attributes: Parameters:


RepairData ArrayOfRepairStruct List of all requested repairs. Appointment AppointmentStruct Time and location for the exchenge of the service. Optional. RequestTimeOut Inherited from SCP_RequestService in NETN-SCP- Base_v1.1.3











Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService Sharing: Transportation type: HLAreliable Order: Receive Dimensions:



Semantics: Attributes: Parameters:


IsOffering Inherited from SCP_OfferService in NETN-SCP- Base_v1.1.3

HLAboolean Defines if the requested service is offered (=true) or not (=false). (Not Optional).

RequestTimeOut Inherited from SCP_OfferService in NETN-SCP- Base_v1.1.3










A.6.1.6. OfferRepair

Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService.OfferRepair Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions:



Semantics: The OfferRepair interaction class shall be sent by a federate simulating the service providing entity in response to a RequestRepair interaction. Attributes: Parameters:


RepairData ArrayOfRepairStruct List of the type of repairs offered. May be different from the list of requested repairs. List of all offered repairs if isOffering = true otherwise Undefined

Appointment AppointmentStruct Time and location for the exchenge of the service. Optional.
















Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceComplete Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Attributes: Parameters:










A.6.1.8. RepairComplete

Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceComplete.RepairComplete Sharing: Publish/Subscribe Transportation type: HLAreliable



Order: Receive Dimensions: Semantics: This interaction is sent by the provider when the repair service is delivered to the consumer. Attributes: Parameters:


RepairData ArrayOfRepairStruct List of the type of repairs done. May be different from the list of requested repairs.










Full Name: HLAinteractionRoot.SCP_Service.SCP_ReadyToReceiveService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics:



Attributes: Parameters:










A.6.1.10. ReadyToReceiveRepair

Full Name: HLAinteractionRoot.SCP_Service.SCP_ReadyToReceiveService.ReadyToReceiveRepair Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: This interaction is sent when the consumer is ready to receive the repair service. (At same location as the provider). Attributes: Parameters:




RepairData ArrayOfRepairStruct The repairs, by type, that the consumer is able to accept at the time it declares ReadyToReceive.









A.6.2. Datatypes


NETN_RepairTypeEnum16 Representation: HLAinteger16BE Semantics: Same enumeration as RPR2 RepairTypeEnum16.

Enumerator Value

NoRepairsPerformed 0 AllRequestedRepairsPerformed 1 MotorOrEngine 10 Starter 20



Enumerator Value

Alternator 30 Generator 40 Battery 50 EngineCoolantLeak 60 FuelFilter 70 TransmissionOilLeak 80 EngineOilLeak 90 Pumps 100 Filters 110 Transmission 120 Brakes 130 SuspensionSystem 140 OilFilter 150 Hull 1000 Airframe 1010 TruckBody 1020 TankBody 1030 TrailerBody 1040 Turret 1050 Propeller 1500 EnvironmentalFilters 1520 Wheels 1540 Tire 1550 Track 1560



Enumerator Value

GunElevationDrive 2000 GunStabilizationSystem 2010 GunnersPrimarySight_lt_GPS_gt_ 2020 CommandersExtensionToTheGPS 2030 LoadingMechanism 2040 GunnersAuxiliarySight 2050 GunnersControlPanel 2060 GunnersControlAssemblyHandle_slsh_Handles 2070 CommandersControlHandles_slsh_Assembly 2090 CommandersWeaponStation 2100 CommandersIndependentThermalViewer_lt_CITV_gt_ 2110 GeneralWeapons 2120 FuelTransferPump 4000 FuelLines 4010 Gauges 4020 GeneralFuelSystem 4030 ElectronicWarfareSystems 4500 DetectionSystems 4600 ElectronicWarfareRadioFrequency 4610 ElectronicWarfareMicrowave 4620 ElectronicWarfareInfrared 4630 ElectronicWarfareLaser 4640 RangeFinders 4700 Range-OnlyRadar 4710



Enumerator Value

LaserRangeFinder 4720 ElectronicSystems 4800 ElectronicSystemsRadioFrequency 4810 ElectronicSystemsMicrowave 4820 ElectronicSystemsInfrared 4830 ElectronicSystemsLaser 4840 Radios 5000 CommunicationSystems 5010 Intercoms 5100 Encoders 5200 EncryptionDevices 5250 Decoders 5300 DecryptionDevices 5350 Computers 5500 NavigationAndControlSystems 6000 FireControlSystems 6500 AirSupply 8000 LifeSupportFilters 8010 LifeSupportWaterSupply 8020 RefrigerationSystem 8030 ChemicalBiologicalAndRadiologicalProtection 8040 WaterWashDownSystems 8050 DecontaminationSystems 8060 HydraulicSystemWaterSupply 9000



Enumerator Value

CoolingSystem 9010 Winches 9020 Catapults 9030 Cranes 9040 Launchers 9050 LifeBoats 10000 LandingCraft 10010 EjectionSeats 10020 OtherAuxiliaryCraftToBeDefined 10030


ArrayOfRepairStruct Element Type: RepairStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: List of repair descriptions (equipment and type of repairs).

ArrayOfRepairTypeEnum Element Type: NETN_RepairTypeEnum16 Cardinality: Dynamic Encoding: HLAvariableArray Semantics: List of repair types.




RepairStruct Encoding: HLAfixedRecord Semantics: Repairs associated with a specific material.

Name Type Semantic

MaterialID UuidArrayOfHLAbyte16 UUID for the material.

Repairs ArrayOfRepairTypeEnum List of the types of repair associated with the material.



A.7. MODULE NETN-STORAGE_v1.2.2

Information

Name: NETN-Storage Type: FOM Version: 1.2 Modification Date: 2013-10-24 Security Classification: Unclassified Purpose: Application Domain: Training Description: NETN Logistics, Supply Pattern, Storage Service Use Limitation: Other:



References





Use History

v1.0.0 - Initial, Interaction classes from NETN FOM v1, NETN_Logistics_v1.1.2. v1.1.0 - Removed interaction StorageStarted. Interaction class RequestStorage: Added parameter Appointment as an optional parameter. Interaction class OfferStorage: Added parameter Appointment as an optional parameter. v1.2.0 - Added two intaractions, StorageComplete and ReadyToReceiveStorage. v1.2.1 - Updated semantics. v1.2.2 - Updated References, Dependency.

Dependencies








Full Name: HLAinteractionRoot.SCP_Service Sharing:



Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:











Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:












A.7.1.4. RequestStorage

Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService.RequestStorage Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: RequestStorage is used by a consumer to initiate a request for storage of supplies. The amount and type of material is included in the request. Parameters:


SuppliesData NETN_ArrayOfSupplyStruct Specifies the supply (type and quantity).

LoadingDoneByProvider HLAboolean Proposes whether the service provider (LoadingDoneByProvider = true) or the service consumer (LoadingDoneByProvider = false) takes care of the (un)loading of the material. Default value is true.




Appointment AppointmentStruct The time and location for the exchange of the service. Optional. RequestTimeOut Inherited from SCP_RequestService in NETN-SCP- Base_v1.1.3











Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:
















A.7.1.6. OfferStorage

Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService.OfferStorage Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: OfferStorage is used by a storage service provider to indicate which (amount and type) of the requested material can be stored. Parameters:




SuppliesData NETN_ArrayOfSupplyStruct Specifies the supply (type and quantity).

LoadingDoneByProvider HLAboolean Determines whether the service provider (LoadingDoneByProvider = true) or the service consumer (LoadingDoneByProvider = false) takes care of the (un)loading of the material. Default value is true.

Appointment AppointmentStruct The time and location for the exchange of the service. Optional. IsOffering Inherited from SCP_OfferService in NETN-SCP- Base_v1.1.3













Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceComplete Sharing: Transportation type: HLAreliable



Order: Receive Dimensions: Semantics: Parameters:










A.7.1.8. StorageComplete

Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceComplete.StorageComplete Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: This interaction is sent by the provider when the supply is delivered to the provider. Parameters:




SuppliesData NETN_ArrayOfSupplyStruct This interaction is sent by the provider when all supply is received by the provider.










Full Name: HLAinteractionRoot.SCP_Service.SCP_ReadyToReceiveService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:













A.7.1.10. ReadyToReceiveStorage

Full Name: HLAinteractionRoot.SCP_Service.SCP_ReadyToReceiveService.ReadyToReceiveStorage Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: This interaction is sent when the consumer is ready to deliver the supply (receive storage). (At same location as the provider.) Parameters:


SuppliesData NETN_ArrayOfSupplyStruct This interaction is sent when the consumer is ready to transfer the supply. (At same location as the provider).














A.8. MODULE NETN-SUPPLY_v1.1.2

Information

Name: NETN-Supply Type: FOM Version: 1.1 Modification Date: 2013-10-24 Security Classification: Unclassified Purpose: Application Domain: Training Description: NETN Logistics, Supply Pattern, Supply Service. Replaces RPR Supply logistics Use Limitation: Other:



References





Use History

v1.0.0 - Initial, interaction classes and datatypes from FOM modules in NETN FOM v1. v1.1.0 - Interaction class RequestSupply: Added parameter Appointment as an optional parameter. Interaction class OfferSupply: Added parameter Appointment as an optional parameter. v1.1.1 - Update of semantics. v1.1.2 - Updated References, Dependency.

Dependencies










Full Name: HLAinteractionRoot.SCP_Service Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:











Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService Sharing: Transportation type: HLAreliable Order: Receive



Dimensions: Semantics: Parameters:












A.8.1.4. RequestSupply

Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService.RequestSupply Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: RequestSupply is used by a consumer to initiate a request for supply from a supply service provider. The amount and type of material is included in the request. In this request the consumer propose whether the loading is done by the provider or by the consumer.



Parameters:


SuppliesData NETN_ArrayOfSupplyStruct List of type and quantity of supplies requested.

LoadingDoneByProvider HLAboolean Proposes whether the service provider (LoadingDoneByProvider = true) or the service consumer (LoadingDoneByProvider = false) takes care of the (un)loading of the material. Default value is true.

Appointment AppointmentStruct Time and location for the exchange of the service. Optional. RequestTimeOut Inherited from SCP_RequestService in NETN-SCP- Base_v1.1.3











Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService Sharing: Transportation type: HLAreliable Order: Receive



Dimensions: Semantics: Parameters:














A.8.1.6. OfferSupply

Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService.OfferSupply Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions:



Semantics: OfferSupply is used by a supply service provider to indicate which of the requested materials (amount and type) can be offered. In this request the consumer decides whether the loading is done by the provider or by the consumer. Parameters:


SuppliesData NETN_ArrayOfSupplyStruct List of type and quantity of supplies offered. May be different from the list of requested supplies. All offered supplies if isOffering = true otherwise Undefined.

LoadingDoneByProvider HLAboolean Determines whether the service provider (LoadingDoneByProvider = true) or the service consumer (LoadingDoneByProvider = false) takes care of the (un)loading of the material. Default value is true.

Appointment AppointmentStruct Time and location for the exchange of the service. Optional. IsOffering Inherited from SCP_OfferService in NETN-SCP- Base_v1.1.3















Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceComplete Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:










A.8.1.8. SupplyComplete

Full Name: HLAinteractionRoot.SCP_Service.SCP_ServiceComplete.SupplyComplete Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive



Dimensions: Semantics: This interaction is sent by the provider when the supply is delivered to the consumer. Parameters:


SuppliesData NETN_ArrayOfSupplyStruct The amount of supplies, by type, that were transferred from provider to consumer.










Full Name: HLAinteractionRoot.SCP_Service.SCP_ReadyToReceiveService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:












A.8.1.10. ReadyToReceiveSupply

Full Name: HLAinteractionRoot.SCP_Service.SCP_ReadyToReceiveService.ReadyToReceiveSupply Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: This interaction is sent when the consumer is ready to receive the supply. (At same location as the provider). Parameters:


SuppliesData NETN_ArrayOfSupplyStruct The amount of supplies, by type, that the consumer is able to accept at the time it declares ReadyToReceive.














A.9. MODULE NETN-TRANSPORT_v1.1.2

Information

Name: NETN-Transport Type: FOM Version: 1.1 Modification Date: 2013-10-24 Security Classification: Unclassified Purpose: Application Domain: Training Description: NETN Logistics, Transport Pattern Use Limitation: Other:

References


Use History

v1.0.0 - Initial, interaction classes and datatypes from FOM modules in NETN FOM v1. v1.0.1 - Updated datatypes DataEDStruct and DataTStruct, switch order on fields. v1.1.0 - Removed Interaction Classes: RejectOfferTransport and CancelTransport. Moved fixed record AppointmentStruct to module NETN-SCP-Base.



v1.1.1 - Update of semantics. v1.1.2 - Updated References, Dependency.

Dependencies








Full Name: HLAinteractionRoot.SCP_Service Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:














Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:














A.9.1.4. RequestTransport

Full Name: HLAinteractionRoot.SCP_Service.SCP_RequestService.RequestTransport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: A request for a Transport support. The request to transport, embark or disembark a platform is initiated by a RequestTransport interaction. Parameters:


TransportData TransportStruct Data for the transport. Transported units and appointment data. RequestTimeOut Inherited from SCP_RequestService in NETN-SCP- Base_v1.1.3













Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:
















A.9.1.6. OfferTransport

Full Name: HLAinteractionRoot.SCP_Service.SCP_OfferService.OfferTransport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: An Offer for a Transport support. The OfferTransport interaction shall be sent by the service providing federate in response to a RequestTransport interaction. Parameters:


TransportData TransportStruct Data for the transport.

OfferType OfferTypeEnum32 Provide high level information about the acceptance of the request (Partial, Full).

Transporters ArrayOfUuid Platform list with transporters. IsOffering Inherited from SCP_OfferService in NETN-SCP- Base_v1.1.3















A.9.1.7. TransportEmbarkmentStatus

Full Name: HLAinteractionRoot.SCP_Service.TransportEmbarkmentStatus Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The TransportEmbarkmentStatus interaction shall be sent by the service provider federate, to inform the service consumer of the embarkment state, after the SCP_ServiceStarted interaction. Parameters:


EmbarkedObjects ArrayOfUuid Allows to follow the elements managed by the provider. TransportUnitIdentifier UuidArrayOfHLAbyte16 Callsign of transporter. ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3











A.9.1.8. TransportDisembarkmentStatus

Full Name: HLAinteractionRoot.SCP_Service.TransportDisembarkmentStatus Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The TransportDisembarkmentStatus interaction shall be sent by the service provider federate, to inform the service consumer of the disembarkment state, after the SCP_ServiceStarted interaction. Parameters:


DisembarkedObjects ArrayOfUuid Allows to follow the elements managed by the provider. TransportUnitIdentifier UuidArrayOfHLAbyte16 Callsign of transporter. ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3











A.9.1.9. TransportDestroyedEntities

Full Name: HLAinteractionRoot.SCP_Service.TransportDestroyedEntities Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The TransportDestroyedEntities interaction is used by the service provider federate to give information on managed element to the consumer. This interaction is used only if the provider simulate the destruction of elements managed. Parameters:


DestroyedObjects ArrayOfUuid Allows to follow the elements managed by the provider. ServiceID Inherited from SCP_Service in NETN-SCP-Base_v1.1.3











A.9.2. Datatypes


TransportTypeEnum32 Representation: HLAinteger32BE Semantics: Type of action, transport, embark or disembark.

Enumerator Value

Transport 0 Embarkment 1 Disembarkment 2


DataEDStruct Representation: HLAfixedRecord Semantics: Defines the entities to transport, where and when for embarkment or disembarment.

Name Type Semantic

ObjectsToManage ArrayOfUuid List with the units to be landing or boarding. Appointment AppointmentStruct Expected location for the landing or boarding.



DataTStruct Representation: HLAfixedRecord Semantics: Defines the entities to transport, where and when for pickup and dropoff.

Name Type Semantic

ObjectsToManage ArrayOfUuid List with the units to be Transport. Appointment AppointmentStruct Expected location for the boarding. FinalAppointment AppointmentStruct Expected location for the landing.

A.9.2.3. Variant Record Datatypes

TransportStruct Encoding: HLAvariantRecord Discriminant name: TransportType Discriminant type: TransportTypeEnum32 Semantics: Transport data.

Name Enumerator Type Semantics

DataTransport Transport DataTStruct Data for transport. DataEmbarkment Embarkment DataEDStruct Data for embarkment. DataDisembarkment Disembarkment DataEDStruct Data for Disembarkment.



A.10. MODULE TMR_v1.1.3

Information

Name: Transfer of Modelling Responsibility FOM Module Type: FOM Version: 1.1 Modification Date: 2014-09-26 Security Classification: Unclassified Purpose: Protocol for Transfer of Modelling Responsilbility Application Domain: Training Description: Transfer of Modelling Responsibility FOM Module Use Limitation: NA Other: NA






Secondary Author Point of Contact

Name: Bjorn Lofstrand Organization: Pitch Technologies Telephone: +46 13 470 55 07 Email: [email protected]

References

Dependency NETN-Base

Use History

v1.0.1 - XML Schema Reference Changed. v1.0.2 - Spelling correction at enumerations. v1.0.3 - Adding AttributeValues. v1.0.3r3 - Adding reason. v1.0.3r4 - Added parameter Respondent at interaction TMR_OfferTransferModellingResponsibility and enumeration value NoofferReasonEnum32.OwnershipStateNotApplicableWithRequest. v1.0.3r5 - Added enumeration value NoofferReasonEnum32.EntityNotKnown. v1.0.3r6 - Change definition of data type TransactionId, a counter and the federate handle. v1.1.0r1 - Added interactions TMR_CancelRequest and TMR_Status. v1.1.0 - Removed "r1" from module name. v1.1.1 - Update of Dependecy table.




v1.1.2 - Rename of enumeration values (AttributeSetTooRestricted, AttributeSetTooExtensive). v1.1.3 - Rename of enumeration value (FederateTooBusy).

Dependencies







A.10.1.2. TMR

Full Name: HLAinteractionRoot.TMR Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Base class for Transfer of Modelling Responsibility interactions. Parameters:


TransactionID TransactionId Identifier for this transaction. Required. RequestFederate FederateName Federate name, Required.

ResponseFederate FederateName Federate name. Not necessary if TransferType is AquireWithoutNegotiation.



A.10.1.3. TMR_OfferTransferModellingResponsibility

Full Name: HLAinteractionRoot.TMR.TMR_OfferTransferModellingResponsibility Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Offer Transfer of Modelling Responsibility. Parameters:


isOffering HLAboolean Is offering (=true) Transfer of Modelling Responsibility or not (=false). Required.

Respondent FederateName

The name of the sending federate of the TMR_OfferTransferModellingResponsibility. The requesting or responding federate. Required.

Reason NoofferReasonEnum32 Describes the reason why the offer is negative. Optional. TransactionID Inherited from TMR in TMR_v1.1.3

TransactionId Identifier for this transaction. Required.

RequestFederate Inherited from TMR in TMR_v1.1.3

FederateName Federate name, Required.

ResponseFederate Inherited from TMR in TMR_v1.1.3

FederateName Federate name. Not necessary if TransferType is AquireWithoutNegotiation.

A.10.1.4. TMR_InitiateTransferModellingResponsibility

Full Name: HLAinteractionRoot.TMR.TMR_InitiateTransferModellingResponsibility Sharing: Publish/Subscribe



Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Interaction for initiating Transfer of Modelling Responsibility between federates. Parameters:


Initiating HLAunicodeString Id of the initiating federate/role. Required. TransferType TransferTypeEnum32 Required. Instances ArrayOfUuid Array of Unique Instance IDs. Required. Attributes ArrayOfAttributes Array with Attribute names. Required.

CapabilityType CapabilityTypeEnum32 Specify the type of capability that shall be transfered between federates. A guidance for the acquiring federate. Optional.

InstanceAttributeValues ArrayOfInstanceAttributeValues The value that the new owner of the attributes may use. Optional. TransactionID Inherited from TMR in TMR_v1.1.3






A.10.1.5. TMR_RequestTransferModellingResponsibility

Full Name: HLAinteractionRoot.TMR.TMR_RequestTransferModellingResponsibility Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions:



Semantics: Request Transfer of Modelling Responsibility. Parameters:


TransferType TransferTypeEnum32 Required. Instances ArrayOfUuid Array of unique instance ids. Required. Attributes ArrayOfAttributes Array of attributes. Required.

CapabilityType CapabilityTypeEnum32 Specifies the capability type that the transfer of the modelling responsibility is about. A guidance for the acquiring federate. Optional.

InstanceAttributeValues ArrayOfInstanceAttributeValues Attribute values that the new owner of the instance attribute may use. Optional.

TransactionID Inherited from TMR in TMR_v1.1.3






A.10.1.6. TMR_CancelRequest

Full Name: HLAinteractionRoot.TMR.TMR_CancelRequest Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Shall be sent by the requesting federate to inform the respons fedrate that the transfer is canceled. Parameters:




Reason CancellationReasonEnum32 The reason for the cancellation. TransactionID Inherited from TMR in TMR_v1.1.3






A.10.1.7. TMR_TransferResult

Full Name: HLAinteractionRoot.TMR.TMR_TransferResult Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Sent by the requesting federate to inform the status of a terminated transfer, completed or not completed. Parameters:


TransferOk HLAboolean True if the transfer is completed, else false. TransactionID Inherited from TMR in TMR_v1.1.3








A.10.2. Datatypes


Counter Representation: HLAinteger32BE Units: NA Resolution: 1 Accuracy: Perfect Semantics: Counter.


TransferTypeEnum32 Representation: HLAinteger32BE Semantics: Transfer type.

Enumerator Value

Other 0 Acquire 1 Divest 2 AcquireWithoutNegotiating 3

CapabilityTypeEnum32 Representation: HLAinteger32BE Semantics: TotalTransfer indicates that all instance attributes shall be involved in the ownership transfer.



Enumerator Value

Other 0 TotalTransfer 1 Movement 2 Damage 3 ResourceConsumption 4

NoofferReasonEnum32 Representation: HLAinteger32BE Semantics: Describes the reason why not accepting a TMR request.

Enumerator Value

Other 0 CapabilityDoesNotMatch 1 AttributeSetTooRestricted 2 AttributeSetTooExtensive 3 FederateTooBusy 4 AttributeSetNotCompatibleWithPublication 5 OwnershipStateNotApplicableWithRequest 6 EntityNotKnown 7

CancellationReasonEnum32 Representation: HLAinteger32BE Semantics: Describes the reason for the cancellation.



Enumerator Value

Other 0 TimeOut 1


ArrayOfAttributes Element Type: HLAunicodeString Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of attribute names.

FederateName Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: HLA Federate Name.

ArrayOfBytes Element Type: Octet Cardinality: Dynamic Encoding: HLAvariableArray Semantics: An array of bytes, used as the raw value of attributes and parameters.

ArrayOfAttributeValues Element Type: AttributeValueStruct Cardinality: Dynamic



Encoding: HLAvariableArray Semantics: An array with name-value pairs.

ArrayOfInstanceAttributeValues Element Type: InstanceAttributeValuesStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array with instances and its attribute values as an array with name-value pairs.


TransactionId Representation: HLAfixedRecord Semantics: Unique identifier for this transaction.

Name Type Semantic

TransactionCounter Counter This value shall be incremented by 1 for each sent transaction. Required.

FederateHandle HLAhandle The handle that the federate get when joining the federation. Required.

AttributeValueStruct Representation: HLAfixedRecord Semantics: The name-value pair for attributes.

Name Type Semantic

AttributeName HLAunicodeString Name of the attribute. Value ArrayOfBytes The value as a byte array.



InstanceAttributeValuesStruct Representation: HLAfixedRecord Semantics: Instance and name-value pairs for instance attributes.

Name Type Semantic

Instance UuidArrayOfHLAbyte16 The UUID for the instance.

AttributeValues ArrayOfAttributeValues Array with attribute name-value pairs.

A.10.3. User Supplied Tags

Update/Reflect Update: NA Semantics: NA.

Send/Receive Update: NA Semantics: NA.

Delete/Remove Update: NA Semantics: NA.

Divestiture Request Update: TransactionId Semantics: NA.



Divestiture Completion Update: NA Semantics: NA.

Acquisition Request Update: TransactionId Semantics: NA.

Request Update Update: NA Semantics: NA.



A.11. MODULE MRM_v1.1.1

Information

Name: NETN Multi-Resolution Management FOM Module Type: FOM Version: 1.1.1 Modification Date: 2014-05-15 Security Classification: Unclassified Purpose: Specify classes necessary to enable federation multi-resolution modeling Application Domain: Training and Education. Platform and aggregate level simulations Description: The MRM FOM module specifies classes necessary to enable federation multi-resolution modeling Use Limitation: Depends on TMR and NETN-Base FOM modules Other:


Name: Andy Bowers Organization: MITRE Telephone: 757.673.5718 Email: [email protected]




Contributor Point of Contact

Name: Lennart Olsson Organization: Pitch Technologies Telephone: +46 13 470 55 06 Email: [email protected]

Contributor Point of Contact

Name: Bjorn Lofstrand Organization: Pitch Technologies Telephone: +46 13 470 55 07 Email: [email protected]

Sponsor Point of Contact

Name: JS J7 Organization: Telephone: Email:

References

HLA Evolved Conversion Tool Pitch Visual OMT 1516 v1.6.0

Dependency NETN Service Consumer-Provider FOM Module





Dependency RPR2 Aggregate FOM Module Dependency RPR2 Physical FOM Module Dependency TMR FOM Module Dependency NETN-Base FOM Module Dependency RPR2 Foundation FOM Module Dependency RPR2 Enumerations FOM Module

Use History

v1.1.0d1 - NETN2 First version. v1.1.0d2 - Updated Identification, modified parameters at MRM_CancelRequest and MRM_ActionComplete. v1.1.0d3 - Added CompletionResult parameter to MRM_ActionComplete, added semantics for parameter reason. v1.1.0d4 - Added NonComplianceReason and associated enumerated datatype to both MRM_DisaggregationResponse and MRM_AggregationResponse. v1.1.0d5 - Added UuidList to MRM_DisaggregationRequest. Changed MRM_DisaggregationRequest.Instance name to AggregateUuid. v1.1.0d6 - Add Aggregate to AggregateStateEnum, Changed semantics for AggregateFederate and HigherResolutionFederate in MRM_Object. v1.1.0d7 - Changed AggregateStateEnum to AggregateStateEnum32 and revised enumerated values. v1.1.0d8 - Added MRM_TriggerResponse interaction. Updated References tab. v1.1.0 - Removed draft number (d8) from name. v1.1.1 - Semantics update.



Dependencies

NETN-Base_v1.0.2 TMR_v1.1.3 RPR-Base_v2.0_draft19.10 RPR-Enumerations_v2.0_draft19.10 RPR-Foundation_v2.0_draft19.10






A.11.1.2. MRM_Object

Full Name: HLAinteractionRoot.MRM_Object Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Base class for Multi-Resolution Modelling (MRM) interactions. Parameters:


TransactionID TransactionId Identifier for this transaction. Required.

AggregateFederate FederateName

Federate name; Required in MRM_DisaggregationRequest or MRM_AggregationRequest from MRM SP, and in MRM_DisaggregationResponse or MRM_AggregationResponse from AggregateFederate, else Optional.

HigherResolutionFederate FederateName

Federate name; Required in MRM_DisaggregationRequest or MRM_AggregationRequest from MRM SP, and in MRM_DisaggregationResponse or MRM_AggregationResponse from HigherResolutionFederate, else Optional.



A.11.1.3. MRM_DisaggregationRequest

Full Name: HLAinteractionRoot.MRM_Object.MRM_DisaggregationRequest Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: A request to disaggregate an object instance specified by a UUID. Parameters:


AggregateUuid UuidArrayOfHLAbyte16 The UUID of the object instance intended for disaggregation.

AggregationState AggregateStateEnum32

Informs Aggregate Federate of intended Aggregation State: If Fully Disaggregate, the aggregate unit does not send updates and all Entities and/or (sub)units of the aggregate unit are updated. If Disaggregate, the aggregate unit sends updates and entities and/or (sub)units of the aggregate unit are updated. If Pseudo-Disaggregate, the aggregate unit sends updates and all Entities and/or (sub)units of the aggregate unit are updated but these “are not capable of full interaction with other entities”. If Partially Disaggregate, the aggregate unit send updates and some entities and/or (sub)units of the aggregate unit are updated, but others are not (and are accounted for using the “silent” attribute).

UuidList ArrayOfUuid

Optional for: Disaggregated and FullyDisaggregated. Required for: PartllyDisaggregated (and PseudoDisaggregated). The list of UUIDs which will be instantiated as a result of the disaggregation.

TransactionID Inherited from MRM_Object in MRM_v1.1.1





AggregateFederate Inherited from MRM_Object in MRM_v1.1.1

FederateName


HigherResolutionFederate Inherited from MRM_Object in MRM_v1.1.1

FederateName


A.11.1.4. MRM_DisaggregationResponse

Full Name: HLAinteractionRoot.MRM_Object.MRM_DisaggregationResponse Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: A response from the receiving federate indicating ability to comply with request. Parameters:


Acknowledge ResponseFlagEnum16 The receiver federates response to the disaggregation request.

NonComplianceReason NonComplianceReasonEnum An optional parameter sent only if the ResponseFlagEnum16 value equals 2, UnableToComply, to specify the reason for non-compliance.




FederateName






FederateName


A.11.1.5. MRM_AggregationRequest

Full Name: HLAinteractionRoot.MRM_Object.MRM_AggregationRequest Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: A request to aggregate a set of UUIDs. Parameters:


AggregateUuid UuidArrayOfHLAbyte16 The UUID of the Aggregate object which will result from the aggregation.

UuidList ArrayOfUuid Optional. The list of UUIDs which should be aggregated. TransactionID Inherited from MRM_Object in MRM_v1.1.1



FederateName



FederateName




A.11.1.6. MRM_AggregationResponse

Full Name: HLAinteractionRoot.MRM_Object.MRM_AggregationResponse Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: A response from the receiving federate indicating ability to comply with request. Parameters:


Acknowledge ResponseFlagEnum16 The receiver federate's response to the request for aggregation.

NonComplianceReason NonComplianceReasonEnum An optional parameter sent only if the ResponseFlagEnum16 value equals 2, UnableToComply, to specify the reason for non-compliance.




FederateName



FederateName


A.11.1.7. MRM_CancelRequest

Full Name: HLAinteractionRoot.MRM_Object.MRM_CancelRequest Sharing: Publish/Subscribe



Transportation type: HLAreliable Order: Receive Dimensions: Semantics: An interaction sent to cancel either a MRM_DisaggregationRequest or a MRM_AggregationRequest. Parameters:


Reason CancellationReasonEnum32 Reason given for cancelling the request. TransactionID Inherited from MRM_Object in MRM_v1.1.1



FederateName



FederateName


A.11.1.8. MRM_ActionComplete

Full Name: HLAinteractionRoot.MRM_Object.MRM_ActionComplete Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: An interaction sent at the completion of either a DisaggregationRequest or AggregationRequest. Parameters:




CompletionResult HLAboolean True if the MRM_Action is successfully completed, else false. TransactionID Inherited from MRM_Object in MRM_v1.1.1



FederateName



FederateName


A.11.1.9. MRM_Trigger

Full Name: HLAinteractionRoot.MRM_Trigger Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: A trigger to inform the MRM SP to disaggregate or to aggregate an object instance specified by a UUID. Parameters:


Instance UuidArrayOfHLAbyte16 Required. This is the UUID of the object instance intended for disaggregation when triggering a DisaggregationRequest and it is the AggregateUuid when triggering an AggregationRequest.

AggregationState AggregateStateEnum32 Informs Aggregate Federate of intended Aggregation State: If Aggregate, the aggregate unit send updates.




AggregationState (cont’d) AggregateStateEnum32

If Fully Disaggregate, the aggregate unit does not send updates and all Entities and/or (sub)units of the aggregate unit send updates. If Disaggregate, the aggregate unit sends updates and entities and/or (sub)units of the aggregate unit send updates. If Pseudo-Disaggregate, the aggregate unit sends updates and all Entities and/or (sub)units of the aggregate unit send updates but these “are not capable of full interaction with other entities”. If Partially Disaggregate, the aggregate unit send updates and some entities and/or (sub)units of the aggregate unit send updates, but others do not (and are accounted for using the “silent” attribute).

UuidList ArrayOfUuid

Optional when in triggering an AggregationRequest or DisaggregationRequest, state: Disaggregate and Fully Disaggregate. Required when in triggering an DisaggregationRequest, state: Partially Disaggregate and Pseudo Disaggregate.

A.11.1.10. MRM_TriggerResponse

Full Name: HLAinteractionRoot.MRM_TriggerResponse Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: An interaction sent in response to MRM_Trigger in order to inform the initiator of the MRM_Trigger interaction 1. that the MRM SP has received the interaction and will act on it and 2. of the TransactionID which will be used for the subsequent interactions associated with the particular trigger (to include the MRM_ActionComplete interaction). Parameters:




Instance UuidArrayOfHLAbyte16 Required. This is the UUID of the object instance specified in the MRM_Trigger interaction.

TransactionID TransactionId Required. The TransactionID which will be used for all interactions (to include the MRM_ActionComplete interaction) associated with the particular MRM_Trigger interaction.

A.11.2. Datatypes


NonComplianceReasonEnum Representation: RPRunsignedInteger32BE Semantics: An enumerated list of reasons why a federate may not be able to comply with a MRM_DisaggregationRequest interaction.

Enumerator Value

Other 0 UnitUnknown 1 UnitAlreadyDisgaggregated 2 UnitNotOwned 4 UnitAlreadyAggregated 3

AggregateStateEnum32 Representation: RPRunsignedInteger32BE Semantics: Aggregate state.



Enumerator Value

Other 0 Aggregated 1 Disaggregated 2 FullyDisaggregated 3 PseudoDisaggregated 4 PartiallyDisaggregated 5



A.12. MODULE NETN-HCBML_v1.1.1

Information

Name: HCBML Type: FOM Version: 1.1.1 Modification Date: 2014-07-22 Security Classification: Unclassified Purpose: C-BML module Application Domain: Training

Description: C-BML standard implementation This module allows exchange between C2 system and Simulation system HCBML : High level CBML

Use Limitation: Other:


Name: Jose RUIZ Organization: DGA/DS/CATOD/DSF/CMI Telephone: +33 1 79 86 41 12 Email: [email protected]




References

HLA Evolved Editor Tool Pitch Visual OMT 1516 v2.2.0 Dependency Base module for NETN FOM v2 modules : NETN-Base_v1.0.2

Dependencies



A.12.1.1. MessageBML

Full Name: HLAobjectRoot.MessageBML Sharing: Subscribe Semantics: Global object which describes a BML element.



Attributes:

OpsHeader


OperationalHeaderStruct PS DA RO HLAbestEffort Update type Update Condition


Military header information about BML distribution.

BMLContent


BMLContentDescription PS RO HLAbestEffort Update type Update Condition


Contains the entire CBML message. CBML message is describe in XML format compliante with CBML 2.2.C shema.




Static NA Semantics

A.12.1.2. OrderBML

Full Name: HLAobjectRoot.MessageBML.OrderBML Sharing: Publish/Subscribe Semantics: Object which describe a BML Order.



Attributes:

MetaData


ArrayOfMetaDataOrder PS DA RO HLAbestEffort Update type Update Condition


Meta data which describe information contains in the Order.

OpsHeader Inherited from MessageBML in NETN- HCBML_v1.1.1





BMLContent Inherited from MessageBML in NETN- HCBML_v1.1.1








Static NA Semantics



A.12.1.3. RequestBML

Full Name: HLAobjectRoot.MessageBML.RequestBML Sharing: Publish/Subscribe Semantics: Object which describe a BML Request. Attributes:

MetaData


ArrayOfMetaDataRequest PS DA RO HLAbestEffort Update type Update Condition


Meta data which describe information contains in the Request.

OpsHeader Inherited from MessageBML in NETN- HCBML_v1.1.1





BMLContent Inherited from MessageBML in NETN- HCBML_v1.1.1










Static NA Semantics






A.12.2.2. Ack

Full Name: HLAinteractionRoot.Ack Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Acknowledgment for CBML message. Confirm reception and ability to process a BML message. Parameters:


Id BmlId Identifier of the acknowledgment.

IdRef BmlId Reference Element identifier for this acknowledgment. Could be reference a task of an Order or a Request.

Who Callsign Sender of the acknowledgment. Type AcknowledgmentStatusEnum Type of acknowledgment.

Reason CommentDescription Inform about the reason which not allows to process or execute a mission.

A.12.2.3. Report

Full Name: HLAinteractionRoot.Report Sharing: Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Global interaction which describe a BML Report. Parameters:




Id BmlId Identifier of the report. When Datetime18 Time of the report.

A.12.2.4. TaskReport

Full Name: HLAinteractionRoot.Report.TaskReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Report about progress of a BML Task Order. Parameters:


IdTask BmlId Identifier of the Task associated to the Report. IdOrder BmlId Identifier of the Order (optional). Status StatusReportEnum32BE Progress status of the Task. Comments CommentDescription Additionnal information about Task progress. Id Inherited from Report in NETN-HCBML_v1.1.1

BmlId Identifier of the report.

When Inherited from Report in NETN-HCBML_v1.1.1

Datetime18 Time of the report.

A.12.2.5. StatusReport

Full Name: HLAinteractionRoot.Report.StatusReport Sharing: Subscribe



Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Global interaction which describe a BML Status Report. Parameters:


IdTask BmlId Identifier of the Task associated to the report (optional). IdOrder BmlId Identifier of the Order (optional). Who Callsign Sender of the Report. Id Inherited from Report in NETN-HCBML_v1.1.1




A.12.2.6. SituationReport

Full Name: HLAinteractionRoot.Report.StatusReport.SituationReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Status Report about perceived view (BFT & Red Situation). Parameters:


Observer UuidArrayOfHLAbyte16 Entity who observe the situation Could be the same of the sender. Hostility HostilityStatusEnum32BE Hostility for the target.




Status OperationalStatusEnum32BE Operational status of the target. TargetDesignation TargetDescription Target track name. TargetRealIdentity UuidArrayOfHLAbyte16 Target real identity (optional). ObservePosition WorldLocationStruct Target position. ObserveTime Datetime18 Time of observation. IdTask Inherited from StatusReport in NETN-HCBML_v1.1.1

BmlId Identifier of the Task associated to the report (optional).

IdOrder Inherited from StatusReport in NETN-HCBML_v1.1.1

BmlId Identifier of the Order (optional).

Who Inherited from StatusReport in NETN-HCBML_v1.1.1

Callsign Sender of the Report.

Id Inherited from Report in NETN-HCBML_v1.1.1




A.12.2.7. LogReport

Full Name: HLAinteractionRoot.Report.StatusReport.LogReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Logistic Report. Parameters:




Consumable ConsumableTypeStruct A set of Consumable-Material-Type-Category-Name. Quantity QuantityFloat32 Available quantity (metric system shall be used). IdTask Inherited from StatusReport in NETN-HCBML_v1.1.1

BmlId Identifier of the Task associated to the report (optional).

IdOrder Inherited from StatusReport in NETN-HCBML_v1.1.1

BmlId Identifier of the Order (optional).

Who Inherited from StatusReport in NETN-HCBML_v1.1.1

Callsign Sender of the Report.

Id Inherited from Report in NETN-HCBML_v1.1.1




A.12.3. Datatypes


SendActionEnum32BE Representation: HLAinteger32BE Semantics: Represent the type of action for a BML message receiver.

Enumerator Value

ForAction 0 ForInfo 1



StatusReportEnum32BE Representation: HLAinteger32BE Semantics: The specific value that represents the perceived appraisal of the progress of a specific ACTION-TASK. JC3IEDM_ActionTaskStatusProgressCodeXmlType.

Enumerator Value

ABO 0 AIRBRN 1 CANCLD 2 COM 3 DELAY 4 DPLMMW 5 DWNTMW 6 IPR 7 NOOPER 8 NKN 9 NOS 10 NST 11 OFFTSK 12 PAU 13 PLAN 14 RECMMW 15 RETASK 16 SCRMBL 17 TASKED 18 TRNMMW 19



OperationalStatusEnum32BE Representation: HLAinteger32BE Semantics: The specific value that represents the operational status of a specific ORGANISATION. JC3IEDM_OrganisationStatusOperationalStatusCodeXmlType.

Enumerator Value

MOPS 0 NKN 1 NOP 2 OPR 3 SOPS 4 TNOPS 5

HostilityStatusEnum32BE Representation: HLAinteger32BE Semantics: The specific value that represents the perceived hostility status of a specific OBJECT-ITEM. JC3IEDM_ObjectItemHostilityStatusCodeXmlType.

Enumerator Value

AFR 0 AHO 1 AIV 2 ANT 3 FAKER 4 FR 5 HO 6



Enumerator Value

IV 7 JOKER 8 NEUTRL 9 PENDNG 10 SUSPCT 11 UNK 12

PriorityEnum32BE Representation: HLAinteger32BE Semantics: Represent the associate priority of a BML message.

Enumerator Value

Z 0 O 1 P 2 R 4

AcknowledgmentStatusEnum Representation: HLAoctet Semantics: Represente the different status of an acknowledgment.

Enumerator Value

Received 0 Acknowledged_Ok 1 Acknowledged_Nok 2



ConsumableTypeEnum Representation: HLAoctet Semantics: Represent the different type of logistic consumable.

Enumerator Value

Fuel 0 Ammo 1 Food 2


ArrayOfMetaDataOrder Element Type: MetaDataOrderStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Order Meta data list.

ArrayOfMetaDataRequest Element Type: MetaDataOrderStruct Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Request Meta data list.

ArrayofReceiver Element Type: ReceiverStruct Cardinality: Dynamic



Encoding: HLAvariableArray Semantics: Receiver list for a BML message.

Datetime18 Element Type: HLAunicodeChar Cardinality: 18 Encoding: HLAfixedArray Semantics: A designation of a specified chronological point measured using Coordinated Universal Time (UTC) ISO 8601:2000 as a standard of reference, constrained to "zero meridian" i.e. Zulu time zone only. This is expressed as a composite field using a compacted ISO notation YYYYMMDDHHMMSS.SSS where YYYY represents a year, MM represents a month in values from 00 to 12, and DD represents a day in values from 00 to 31, HH represents an hour, MM represents a minute, and SS.SSS represents the number of seconds and milliseconds.

MessageDescription Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Represents the identification of a BML message.

BMLContentDescription Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Contains the entire CBML message. CBML message is described in XML format compliante with CBML 2.2.C shema.



CommentDescription Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Comment for a BML message.

TargetDescription Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Represents the Track name of an observed Entity.

BmlData Element Type: HLAunicodeChar Cardinality: Dynamic Encoding: HLAvariableArray Semantics: BML message data.


MetaDataOrderStruct Encoding: HLAfixedRecord Semantics: Meta data for an Order.

Name Type Semantic

Id BmlData BML message order id. Information extract from Xml data message.



Name Type Semantic

IdTask BmlData BML message task id. Information extract from Xml data message.

Who BmlData BML message taskee. Information extract from Xml data message.

What BmlData BML message mission. Information extract from Xml data message.

GeographicInterest WGS84Location BML message mission zone (Baricentre). Information extract from Xml data message.

Status StatusReportEnum32BE Actual state of the BML Task. State is update with the progress of the Order.

OperationalHeaderStruct Encoding: HLAfixedRecord Semantics: Meta data for distributed BML message.

Name Type Semantic

Sender BmlData BML message sender. Information extract from Xml data message.

Receivers ArrayofReceiver List of Receivers for the BML message. Information extract from Xml data message.

SendTime Datetime18 Sending date of the BML message.

Priority PriorityEnum32BE BML message priority. Information extract from Xml data message.



ReceiverStruct Encoding: HLAfixedRecord Semantics: Receiver decription.

Name Type Semantic

Name BmlData BML message receiver. Information extract from Xml data message.

SendAction SendActionEnum32BE BML message action for the receiver. Information extract from Xml data message.

BmlId Encoding: HLAfixedRecord Semantics: Represent Identifier of a BML message.

Name Type Semantic

Counter CounterInt32

EventCount shall start at one (1) and then incremented by one (1) for a new BML message. In the case where all possible values are exhausted, the numbers may be reused beginning again at one.

MessageId MessageDescription Identifier of BML message. This identifier corresponds to xml id information of Request and Order.



WGS84Location Encoding: HLAfixedRecord Semantics: Represents a location in WGS84.

Name Type Semantic

latitude Float32 Latitude representation in degree. longitude Float32 Longitude representation in degree. altitude MeterFloat32 Altitude representation in meter.

ConsumableTypeStruct Encoding: HLAfixedRecord Semantics: Consumable Description.

Name Type Semantic

ConsumableType ConsumableTypeEnum Consumable type. SubCategory EntityTypeStruct Consumable Enumere. SubCategoryDesription HLAunicodeString OPTIONAL- Consumable name.

A.12.4. Switches Auto Provide Disabled Convey Region Designator Sets Disabled Convey Producing Federate Disabled Attribute Scope Advisory Disabled Attribute Relevance Advisory Disabled



Object Class Relevance Advisory Disabled Interaction Relevance Advisory Disabled Service Reporting Disabled Exception Reporting Disabled Delay Subscription Evaluation Disabled Automatic Resign Action CancelThenDeleteThenDivest



A.13. MODULE NETN-LBML_v1.1.0

Information

Name: LBML Type: FOM Version: 1.0 Modification Date: 2014-09-24 Security Classification: Unclassified Purpose: Low level BML Application Domain: Description: Low level BML orders/tasks and reports Use Limitation: Other:


Name: Roger Jansen Organization: Telephone: Email:



References

HLA Evolved Conversion Tool Pitch Visual OMT v2.2.3

Release Restrictions

Use History

v.1.1.0 - Renamed (from 1.0.0d6)

Dependencies









A.13.1.2. LBMLMessage

Full Name: HLAinteractionRoot.LBMLMessage Sharing: Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Root class of low level BML interactions. Parameters:

A.13.1.3. LBMLTask

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask Sharing: Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: An interaction for ordering a unit to execute a task. Parameters:




Task TaskId Identifies the task. Taskee UuidArrayOfHLAbyte16 The unit that has to execute the task. Tasker Callsign Identifies the commander of the task. StartWhen Datetime18 Time when the task execution has to start.

EndWhen Datetime18 Time when the task execution has to end. 00000000000000.000 means no end time.

Why HLAunicodeString For what reason has this task to be executed. TaskType TaskTypeEnum8 Determines how this new task is related to the current task.

A.13.1.4. Move

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.Move Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to move in the specified direction. The unit will keep on moving until the specified end time or when ordered otherwise. Parameters:


Direction AngleRadianFloat32 Determines the azimuth direction, in radians. Task Inherited from LBMLTask in NETN-LBML_v1.1.0

TaskId Identifies the task.

Taskee Inherited from LBMLTask in NETN-LBML_v1.1.0

UuidArrayOfHLAbyte16 The unit that has to execute the task.




Tasker Inherited from LBMLTask in NETN-LBML_v1.1.0

Callsign Identifies the commander of the task.

StartWhen Inherited from LBMLTask in NETN-LBML_v1.1.0

Datetime18 Time when the task execution has to start.

EndWhen Inherited from LBMLTask in NETN-LBML_v1.1.0

Datetime18 Time when the task execution has to end. 00000000000000.000 means no end time.

Why Inherited from LBMLTask in NETN-LBML_v1.1.0

HLAunicodeString For what reason has this task to be executed.

TaskType Inherited from LBMLTask in NETN-LBML_v1.1.0

TaskTypeEnum8 Determines how this new task is related to the current task.

A.13.1.5. MoveToLocation

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.MoveToLocation Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to move to the specified destination. Parameters:


Destination WorldLocationStruct The location to move to. MoveType MoveTypeEnum32 Indicates if roads have to be followed. Waypoints WorldLocationStructLengthlessArray Optional route to the destination. Task Inherited from LBMLTask in NETN-LBML_v1.1.0

















A.13.1.6. MoveToUnit

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.MoveToUnit Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to move to another unit. Parameters:


Unit UuidArrayOfHLAbyte16 The unit to move to. MoveType MoveTypeEnum32 Indicates if roads have to be followed. Waypoints WorldLocationStructLengthlessArray Optional route to the destination.




Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.7. MoveIntoFormation

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.MoveIntoFormation Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks an aggregate unit to move into the given formation with the given heading. Parameters:


Formation FormationEnum32 The category of positional arrangement of the entities within the aggregate.




Distance MeterFloat32 Distance between the individual vehicles in the formation. Location WorldLocationStruct The location (x, y and z) to move to. Heading AngleRadianFloat32 The heading of the formation in radians. Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.8. FollowRoute

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.FollowRoute Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to follow the specified route. Parameters:




MoveType MoveTypeEnum32

ControlMeasure EntityIdentifierStruct Follow a control measure referenced by an entity identifier struct. This would typically be an envionmental object which contains one (waypoint) or many points (route), but could also be another entity.















A.13.1.9. FollowUnit

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.FollowUnit Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to follow another unit.



Parameters:


Unit UuidArrayOfHLAbyte16 The unit to follow. Behind MeterFloat32 The distance in meters behind the unit to follow. Right MeterFloat32 The distance in meters to the right of the unit to follow. Above MeterFloat32 The distance in meters above the unit to follow. Task Inherited from LBMLTask in NETN-LBML_v1.1.0 TaskId Identifies the task.

Taskee Inherited from LBMLTask in NETN-LBML_v1.1.0 UuidArrayOfHLAbyte16 The unit that has to execute the task.

Tasker Inherited from LBMLTask in NETN-LBML_v1.1.0 Callsign Identifies the commander of the task.

StartWhen Inherited from LBMLTask in NETN-LBML_v1.1.0 Datetime18 Time when the task execution has to start.

EndWhen Inherited from LBMLTask in NETN-LBML_v1.1.0 Datetime18 Time when the task execution has to end. 00000000000000.000

means no end time. Why Inherited from LBMLTask in NETN-LBML_v1.1.0 HLAunicodeString For what reason has this task to be executed.

TaskType Inherited from LBMLTask in NETN-LBML_v1.1.0 TaskTypeEnum8 Determines how this new task is related to the current task.

A.13.1.10. TurnToHeading

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.TurnToHeading Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive



Dimensions: Semantics: Tasks a unit to turn to the specified heading. Parameters:


Heading AngleRadianFloat32 Determines the heading, in radians, a unit has to turn to. Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.11. TurnToOrientation

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.TurnToHeading.TurnToOrientation Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics:



Parameters:


Pitch AngleRadianFloat32 Roll AngleRadianFloat32 Heading Inherited from TurnToHeading in NETN-LBML_v1.1.0

AngleRadianFloat32 Determines the heading, in radians, a unit has to turn to.















A.13.1.12. VehicleMount

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.VehicleMount Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive



Dimensions: Semantics: Tasks a unit to mount the specified vehicle. Parameters:


VehicleToMount UuidArrayOfHLAbyte16 The vehicle to mount. Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.13. VehicleDismount

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.VehicleDismount Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to dismount.



Parameters:
















A.13.1.14. FireAtLocation

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.FireAtLocation Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to fire at a location. Parameters:




TargetLocation WorldLocationStruct The location to fire at. Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.15. FireIndirectWM

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.FireAtLocation.FireIndirectWM Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to fire at a location with the specified weapon and munition. Parameters:




WeaponTypeToUse EntityTypeStruct MunitionTypeToUse EntityTypeStruct TargetLocation Inherited from FireAtLocation in NETN-LBML_v1.1.0

WorldLocationStruct The location to fire at.















A.13.1.16. FireAtUnit

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.FireAtUnit Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to fire at another specified unit.



Parameters:


Target UuidArrayOfHLAbyte16 The unit to fire at. Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.17. FireDirectWM

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.FireAtUnit.FireDirectWM Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:




WeaponTypeToUse EntityTypeStruct The weapon type to use. MunitionTypeToUse EntityTypeStruct The munition type that should be used by the select weapon type. Target Inherited from FireAtUnit in NETN-LBML_v1.1.0

UuidArrayOfHLAbyte16 The unit to fire at.















A.13.1.18. Wait

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.Wait Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Tasks a unit to wait until the specified end time. Wait indefinitely if no end time is specified.



Parameters:








StartWhen Inherited from LBMLTask in NETN-LBML_v1.1.0 Datetime18 Time when the task execution has to start.

EndWhen Inherited from LBMLTask in NETN-LBML_v1.1.0 Datetime18 Time when the task execution has to end. 00000000000000.000

means no end time. Why Inherited from LBMLTask in NETN-LBML_v1.1.0 HLAunicodeString For what reason has this task to be executed.

TaskType Inherited from LBMLTask in NETN-LBML_v1.1.0 TaskTypeEnum8 Determines how this new task is related to the current task.

A.13.1.19. ChangeOrderedSpeed

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.ChangeOrderedSpeed Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Change the ordered speed. Usually sent with TaskType InterruptCurrentTask to adjust the current move task. Parameters:




Speed VelocityMeterPerSecondFloat32 Determines the ordered speed to set for a unit, in m/s. Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.20. ChangeOrderedAltitude

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.ChangeOrderedAltitude Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Change the ordered altitude. Usually sent with TaskType InterruptCurrentTask to adjust the current move task. Parameters:




Altitude Float64 AltitudeType AltitudeTypeEnum8 Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.21. SetRulesOfEngagement

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTask.SetRulesOfEngagement Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Change the rules of engagment for a unit. Parameters:




RulesOfEngagement RulesOfEngagementEnum8 Determines the rules of engagment for a unit. Task Inherited from LBMLTask in NETN-LBML_v1.1.0














A.13.1.22. LBMLTaskManagement

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTaskManagement Sharing: Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Task management interactions. For now only used to cancel tasks. Can be extended to reschedule tasks, etc. Parameters:




Taskee UuidArrayOfHLAbyte16 The unit that has to execute the task. Tasker Callsign Identifies the commander of the task.

A.13.1.23. CancelAllTasks

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTaskManagement.CancelAllTasks Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Cancel all tasks. Tasks already started have to be aborted immediately. Parameters:


Taskee Inherited from LBMLTaskManagement in NETN- LBML_v1.1.0


Tasker Inherited from LBMLTaskManagement in NETN- LBML_v1.1.0


A.13.1.24. CancelSpecifiedTasks

Full Name: HLAinteractionRoot.LBMLMessage.LBMLTaskManagement.CancelSpecifiedTasks Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions:



Semantics: Cancel all specified tasks. Tasks already started have to be aborted immediately. Parameters:


Tasks ArrayOfTaskIds Tasks that have to be cancelled. Taskee Inherited from LBMLTaskManagement in NETN- LBML_v1.1.0


Tasker Inherited from LBMLTaskManagement in NETN- LBML_v1.1.0


A.13.1.25. LBMLReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport Sharing: Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: An interaction for sending reports from a simulation framework (e.g. VR-Forces) to a BML agent framework. Parameters:


When Datetime18 Date and time when the reported status was valid. Comments HLAunicodeString Any additional comments.



A.13.1.26. StatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport Sharing: Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Status report from a friendly unit about its own (perceived) state. The C2 agent shall base its low level BML tasks on this perceived truth data of blue units instead of RPR ground truth data, although for blue units perceived and ground truth data might be the same (but not necessarily). Parameters:


Unit UuidArrayOfHLAbyte16 The unit that is reported about. When Inherited from LBMLReport in NETN-LBML_v1.1.0

Datetime18 Date and time when the reported status was valid.

Comments Inherited from LBMLReport in NETN-LBML_v1.1.0

HLAunicodeString Any additional comments.

A.13.1.27. TaskStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.TaskStatusReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: A report about the status of a task the unit was ordered to execute. Parameters:




Task TaskId Identifies the task associated with the task report. TaskStatus TaskStatusEnum32 Indicates the evaluation status of the task. Unit Inherited from StatusReport in NETN-LBML_v1.1.0

UuidArrayOfHLAbyte16 The unit that is reported about.

When Inherited from LBMLReport in NETN-LBML_v1.1.0




A.13.1.28. PositionStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.PositionStatusReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Report about the position, speed, and heading of the unit. Parameters:


Position WorldLocationStruct Position of the unit at the specified time. Heading AngleRadianFloat32 Heading of the unit. Speed VelocityMeterPerSecondFloat32 Speed of the unit. Unit Inherited from StatusReport in NETN-LBML_v1.1.0









A.13.1.29. DamageStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.DamageStatusReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Represents a report from a unit that has been damaged or destroyed. Parameters:


DamageType DamageStatusEnhancedEnum32 Damage state of the reported unit. Unit Inherited from StatusReport in NETN-LBML_v1.1.0






A.13.1.30. FuelStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.FuelStatusReport Sharing: Publish/Subscribe Transportation type: HLAreliable



Order: Receive Dimensions: Semantics: Report about the amount of fuel the unit has left. FuelType is a string since it is still experimental. Parameters:


FuelType HLAunicodeString The type of fuel. FuelPercentage PercentFloat32 The amount of fuel the unit has not yet used, in percentages. Unit Inherited from StatusReport in NETN-LBML_v1.1.0






A.13.1.31. AmmunitionStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.AmmunitionStatusReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Report about the amount of ammunition the unit has left. Parameters:


AmmunitionType EntityTypeStruct The type of ammunition. AmmunitionPercentage PercentFloat32 The amount of ammunition the entity has not yet used in percentages.




Unit Inherited from StatusReport in NETN-LBML_v1.1.0






A.13.1.32. UnderAttackStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.UnderAttackStatusReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Report that the unit is under attack. Parameters:


FromDirection AngleRadianFloat32 Direction from which the unit is attacked. Severeness AttackTypeEnum32 Severeness of the attack upon the reporting unit. Unit Inherited from StatusReport in NETN-LBML_v1.1.0








A.13.1.33. ActivityStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.ActivityStatusReport Sharing: Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Base class for an activity report (absolute truth). Parameters:


EntitiesInvolved ArrayOfUuid Reference to entities involved in a particular activity. TimeLeftToCompletion Float64 Amount of time (if known) to completion of activity. 0 if unknown.

Activity HLAunicodeString A application specific description of the task since different CGF's / simulators are capable of executing different task types which may not fall neatly into those defined in the AggregateMissionEnum16.

ActivityType AggregateMissionEnum16 Provide a universally understood summary of the activity using the aggregate mission enum (for compatability).







A.13.1.34. CurrentActivityStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.ActivityStatusReport.CurrentActivitySta tusReport Sharing: Publish/Subscribe





ElapsedTaskTime Float64 Time entity has been performing task.

TaskExecutionStatus HLAunicodeString Includes more specific information about the current task state (application specific) or sub- states within the task.

EntitiesInvolved Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

ArrayOfUuid Reference to entities involved in a particular activity.

TimeLeftToCompletion Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

Float64 Amount of time (if known) to completion of activity. 0 if unknown.

Activity Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

HLAunicodeString A application specific description of the task since different CGF's / simulators are capable of executing different task types which may not fall neatly into those defined in the AggregateMissionEnum16.

ActivityType Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

AggregateMissionEnum16 Provide a universally understood summary of the activity using the aggregate mission enum (for compatability).









A.13.1.35. NextActivityStatusReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.StatusReport.ActivityStatusReport.NextActivityStatusReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:


StartCondition TaskStartConditionEnum8 TimeToStart Float64 EntitiesInvolved Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

ArrayOfUuid Reference to entities involved in a particular activity.

TimeLeftToCompletion Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

Float64 Amount of time (if known) to completion of activity. 0 if unknown.

Activity Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

HLAunicodeString A application specific description of the task since different CGF's / simulators are capable of executing different task types which may not fall neatly into those defined in the AggregateMissionEnum16.

ActivityType Inherited from ActivityStatusReport in NETN- LBML_v1.1.0

AggregateMissionEnum16 Provide a universally understood summary of the activity using the aggregate mission enum (for compatability).









A.13.1.36. SpotReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.SpotReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Spot reports are one-time reports used by all units to transmit intelligence or information about a spotted enemy, neutral, or unknown unit. The C2 agent shall base its low level BML tasks on this perceived truth data on non friendly / unknown units instead of RPR ground truth data. UnitType, EquipmentType, and Activity are strings since they are still experimental. Parameters:


Observer UuidArrayOfHLAbyte16 Unit that observed the enemy (or neutral/unknown unit) and sends the spot report.

IdentificationLevel IdentificationLevelEnum8 The identification level of the unit(s) spotted. ForceIdentifier PerceivedForceIdentifierEnum32 Force Id of the spotted unit(s) as assumed by the observer. Position WorldLocationStruct Position of the spotted unit at the specified time. NumberOfUnits Integer32 Number of spotted units.

UnitType EntityTypeStruct Description of the units spotted. Subfields can be 0 if unknown, depending on the identification level.

NumberOfEquipments Integer32 Number of spotted enemy equipments.

EquipmentType EntityTypeStruct Description of the equipments spotted. Subfields can be 0 if unknown, depending on the identification level.







A.13.1.37. ActivitiySpotReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.SpotReport.ActivitySpotReport Sharing: Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: The information here is based on perception information which is determined from situation awareness, intel or potentially instinct. Parameters:


EntitiesInvolved ArrayOfUuid Entities involved in the perceived activity.

TimeLeftToCompletion Float64 Activity HLAunicodeString Description of the activity of the enemy spotted. ActivityType AggregateMissionEnum16 Perceived activities are engaged in. Observer Inherited from SpotReport in NETN-LBML_v1.1.0

UuidArrayOfHLAbyte16 Unit that observed the enemy (or neutral/unknown unit) and sends the spot report.

IdentificationLevel Inherited from SpotReport in NETN-LBML_v1.1.0

IdentificationLevelEnum8 The identification level of the unit(s) spotted.

ForceIdentifier Inherited from SpotReport in NETN-LBML_v1.1.0

PerceivedForceIdentifierEnum32 Force Id of the spotted unit(s) as assumed by the observer.

Position Inherited from SpotReport in NETN-LBML_v1.1.0

WorldLocationStruct Position of the spotted unit at the specified time.

NumberOfUnits Inherited from SpotReport in NETN-LBML_v1.1.0

Integer32 Number of spotted units.

UnitType Inherited from SpotReport in NETN-LBML_v1.1.0

EntityTypeStruct Description of the units spotted. Subfields can be 0 if unknown, depending on the identification level.




NumberOfEquipments Inherited from SpotReport in NETN-LBML_v1.1.0

Integer32 Number of spotted enemy equipments.

EquipmentType Inherited from SpotReport in NETN-LBML_v1.1.0

EntityTypeStruct Description of the equipments spotted. Subfields can be 0 if unknown, depending on the identification level.





A.13.1.38. CurrentActivitySpotReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.SpotReport.ActivitySpotReport.CurrentActivitySpotReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:


ElapsedTaskTime Float64 Perceived time the task started if known. 0 if unknown. TaskExecutionStatus HLAunicodeString Perceived exeuction status. EntitiesInvolved Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

ArrayOfUuid Entities involved in the perceived activity.

TimeLeftToCompletion Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

Float64




Activity Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

HLAunicodeString Description of the activity of the enemy spotted.

ActivityType Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

AggregateMissionEnum16 Perceived activities are engaged in.

Observer Inherited from SpotReport in NETN-LBML_v1.1.0






















A.13.1.39. NextActivitySpotReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.SpotReport.ActivitySpotReport.NextActivitySpotReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:


StartCondition TaskStartConditionEnum8 TimeToStart Float64 EntitiesInvolved Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

ArrayOfUuid Entities involved in the perceived activity.

TimeLeftToCompletion Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

Float64

Activity Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

HLAunicodeString Description of the activity of the enemy spotted.

ActivityType Inherited from ActivitySpotReport in NETN-LBML_v1.1.0

AggregateMissionEnum16 Perceived activities are engaged in.

Observer Inherited from SpotReport in NETN-LBML_v1.1.0























A.13.1.40. InSensorReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.SpotReport.InSensorReport Sharing: Publish/Subscribe Transportation type: HLAreliable Order: Receive Dimensions: Semantics: Parameters:




SensorType EntityTypeStruct SensedEntities ArrayOfUuid Observer Inherited from SpotReport in NETN-LBML_v1.1.0




















A.13.1.41. InWeaponRangeReport

Full Name: HLAinteractionRoot.LBMLMessage.LBMLReport.SpotReport.InWeaponRangeReport Sharing: Publish/Subscribe





WeaponType EntityTypeStruct EntitiesInWeaponRange ArrayOfUuid Observer Inherited from SpotReport in NETN-LBML_v1.1.0






















A.13.2. Datatypes


Counter Representation: HLAinteger32BE Units: NA Resolution: 1 Accuracy: Perfect Semantics: Counter.


RulesOfEngagementEnum8 Representation: HLAoctet Semantics: Rules of engagment for a simulated unit.

Enumerator Value

HoldFire 0 FireAtWill 1 FireWhenFiredUpon 2

TaskStatusEnum32 Representation: HLAinteger32BE Semantics: The status of a task.



Enumerator Value

Accepted 0 Refused 1 Aborted 2 Completed 3

IdentificationLevelEnum8 Representation: HLAoctet Semantics: The identification level of an object.

Enumerator Value

Lost 0 Detected 1 Classified 2 Identified 3 FullKnowledge 4

MoveTypeEnum32 Representation: HLAinteger32BE Semantics: CrossCountry: move directly to the destination without taking into account the roads. OnlyRoads: stay on the roads to get to the closest point to the destination that is still on a road; if there is no road very near to the start (within around 10 meters) there will be no movement at all. RoadsAndCrossCountry: move to the destination by taking into account the roads; it is allowed to go off the road.

Enumerator Value

CrossCountry 0



Enumerator Value

OnlyRoads 1 RoadsAndCrossCountry 2

AttackTypeEnum32 Representation: HLAinteger32BE Semantics: The kind of attack by the enemy.

Enumerator Value

None 0 Artillery 1 HeavyArtillery 2 Other 3

AltitudeTypeEnum8 Representation: HLAoctet Semantics: AMSL = Above Mean Sea Level; AGL = Abve Ground Level.

Enumerator Value

AMSL 1 AGL 2



TaskStartConditionEnum8 Representation: HLAoctet Semantics:

Enumerator Value

OnCompletionOfPrevious 1 AtTime 2

TaskTypeEnum8 Representation: HLAoctet Semantics: CancelAllOtherTasks: this new task replaces all other tasks. The current task has to be aborted as soon as possible and the new task can be executed at the start time. AddToTaskList: this new task will be executed after all other tasks with a smaller start time have been completed. InterruptCurrentTask: this new task interrupts the current task or is an adjustment of the current task.

Enumerator Value

CancelAllOtherTasks 0 AddToTaskList 1 InterruptCurrentTask 2

PerceivedForceIdentifierEnum32 Representation: HLAinteger32BE Semantics:

Enumerator Value

Unknown 0 AssumedFriend 1



Enumerator Value

Friend 2 Neutral 3 Suspect 4 Hostile 5


Datetime18 Representation: HLAunicodeChar Cardinality: 18 Encoding: HLAfixedArray Semantics: A designation of a specified chronological point measured using Coordinated Universal Time (UTC) ISO 8601:2000 as a standard of reference, constrained to "zero meridian" i.e. Zulu time zone only. This is expressed as a composite field using a compacted ISO notation YYYYMMDDHHMMSS.SSS where YYYY represents a year, MM represents a month in values from 00 to 12, and DD represents a day in values from 00 to 31, HH represents an hour, MM represents a minute, and SS.SSS represents the number of seconds and milliseconds.

ArrayOfTaskIds Representation: TaskId Cardinality: Dynamic Encoding: HLAvariableArray Semantics: Array of Task Ids.




TaskId Encoding: HLAfixedRecord Semantics: Unique identifier for this order.

Name Type Semantic

TaskCounter Counter This value shall be incremented by 1 for each sent task.

FederateHandle HLAhandle The handle that the federate get when joining the federation.



INTENTIONALLY BLANK

ANNEX B to AMSP-04 NETN MSDL EXTENSIONS

B-1 Edition (A) Version 1.0 (Draft 3)

ANNEX B NETN MSDL EXTENSIONS

This annex specifies extensions made to SISO-STD-007-2008 Military Scenario Definition Language (MSDL) XML Schema definitions (https://www.sisostds.org/ Schemas.aspx) to support NETN FAFD based distributed simulations.

The extended XML Schemas are also available for download from NATO CSO at https://www.sto.nato.int/pages/natostandards.aspx.

================================================================= File: MsdlCodes_v1.0.0.xsd

New enumeration:

<xs:simpleType name="enumSupportRoleType"> <xs:enumeration value="EMBARKMENT"> <xs:annotation> <xs:documentation>Support is to embark another unit</xs:documentation> </xs:annotation> </xs:enumeration>

================================================================= File MsdlSimpleTypes_v1.0.0.xsd

New SimpleTypes:

<xs:simpleType name="patternForceSymbolAPP6B"> <xs:annotation> <xs:documentation>The 15 character Symbol identifier with fields that shall not be interpreted restricted using dashes. These fields would be redundant to other explicit elements in the standard. Affiliation, Status, and Country Code are restricted in this manner. Affiliation and Country Code values are provided in the ForceSide structure data. Status is to be interpreted as 'Present' until such time as a separate element is created to distinguish truth values from perceived values.The coding scheme, position 1, shall be 'S' for unit and equipment symbol identification. The elements in the force symbol are defined in NATO APP6(B).</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:length value="15"/>

https://www.sisostds.org/Schemas.aspx

https://www.sisostds.org/Schemas.aspx

https://www.sto.nato.int/pages/natostandards.aspx



<xs:pattern value="[S]{1}[\-]{1}[PAGSUFX\-]{1}[\-]{1}[A-Z\-]{6}[A-Z\-\*]{1}[A-Z\-\*]{1}[\-]{2}[AECGNSX\-\*]{1}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="patternInstallationSymbolAPP6B"> <xs:annotation> <xs:documentation>The 15 character Symbol identifier with fields that shall not be interpreted restricted using dashes. These fields would be redundant to other explicit elements in the standard. Affiliation, Status, and Country Code are restricted in this manner. Affiliation and Country Code values are provided in the ForceSide structure data. Status is to be interpreted as 'Present' until such time as a separate element is created to distinguish truth values from perceived values. The coding scheme, position 1, shall be 'S' for Installation symbol identification. The elements in the installation symbol are defined in NATO APP6(B).</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:length value="15"/> <xs:pattern value="[S]{1}[\-]{1}[G]{1}[AP\-]{1}[I]{1}[A-Z\-]{5}[A-Z\-\*]{1}[A-Z\-\*]{1}[\-]{2}[AECGNSX\-\*]{1}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="patternMETOCSymbolAPP6B"> <xs:annotation> <xs:documentation>The 15 character Symbol identifier with fields that shall not be interpreted restricted using dashes. These fields would be redundant to other explicit elements in the standard. Affiliation, Status, and Country Code are restricted in this manner. Affiliation and Country Code values are provided in the ForceSide structure data. Status is to be interpreted as 'Present' until such time as a separate element is created to distinguish truth values from perceived values. The coding scheme, position 1, shall be 'W' for the METOC symbol identification. The elements in the METOC symbol are defined in NATO APP6(B).</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:length value="15"/> <xs:pattern value="[W]{1}[\-]{1}[A]{1}\-[PTIWFCRSO\-]{1}[B-X\-]{3}[\-]{2}\-\-\-\-\-"/> </xs:restriction>



</xs:simpleType> <xs:simpleType name="patternMOOTWSymbolAPP6B"> <xs:annotation> <xs:documentation>The 15 character Symbol identifier with fields that shall not be interpreted restricted using dashes. These fields would be redundant to other explicit elements in the standard. Affiliation, Status, and Country Code are restricted in this manner. Affiliation and Country Code values are provided in the ForceSide structure data. Status is to be interpreted as 'Present' until such time as a separate element is created to distinguish truth values from perceived values. The coding scheme, position 1, shall be 'O' for the MOOTW symbol identification. The elements in the MOOTW symbol are defined in NATO APP6B.</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:length value="15"/> <xs:pattern value="[G]{1}[\-]{1}[O\-]{1}[AP\-]{1}[A-Z\-]{6}[A-Z\-\*]{1}[A-Z\-\*]{1}[\-]{2}[AECGNSX\-\*]{1}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="patternNSN"> <xs:annotation> <xs:documentation>The 13 character NATO STOCK NUMBER. See http://www.nato.int/structur/ac/135/ncs_guide/english/e_1-6-5.htm </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:length value="13"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="patternEntityType"> <xs:annotation> <xs:documentation>For HLA</xs:documentation> </xs:annotation> <xs:restriction base="xs:string" /> </xs:simpleType> <xs:simpleType name="patternTacticalGraphicSymbolAPP6B"> <xs:annotation> <xs:documentation>The 15 character Symbol identifier with fields that shall not be interpreted restricted using dashes. These fields would be redundant to other explicit elements in the standard. Affiliation, Status, and Country Code



are restricted in this manner. Affiliation and Country Code values are provided in the ForceSide structure data. Status is to be interpreted as 'Present' until such time as a separate element is created to distinguish truth values from perceived values.The coding scheme, position 1, shall be 'G' for the Tactical Graphic symbol identification. The elements in the tactical graphic symbol are defined in NATO APP6(B).</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:length value="15"/> <xs:pattern value="[G]{1}[\-]{1}[TCOX\-]{1}[AP\-]{1}[A-Z\-]{6}[A-Z\-\*]{1}[A-Z\-\*]{1}[\-]{2}[AECGNSX\-\*]{1}"/> </xs:restriction> </xs:simpleType>

================================================================= File: MsdlComplexTypes_v1.0.0.xsd

New Element in <xs:complexType name="MilitaryScenarioType">:

<xs:element name="Deployment" minOccurs="0"> <xs:complexType> <xs:sequence maxOccurs="unbounded"> <xs:element name="Federate"> <xs:complexType> <xs:all> <xs:element name="ObjectHandle"/> <xs:element name="Name" minOccurs="0"/> <xs:element name="Units"> <xs:complexType> <xs:sequence> <xs:element name="Unit"> <xs:complexType> <xs:sequence> <xs:element name="ObjectHandle"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:all> </xs:complexType> </xs:element>



</xs:sequence> </xs:complexType> </xs:element> ---------------------------------------------------------------

New Elements in <xs:complexType name="UnitType">:

<xs:element name="Type" type="msdl:UnitTypeType" minOccurs="0"> <xs:annotation> <xs:documentation>The type of the unit.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Holdings" type="msdl:HoldingsType" minOccurs="0"> <xs:annotation> <xs:documentation>The quantity of all specific Equipment/Consumable that is held by, installed in, or included with the unit</xs:documentation> </xs:annotation> </xs:element> ---------------------------------------------------------------

New Elements in <xs:complexType name="EquipmentItemType">:

<xs:element name="NSN_Code" type="msdl:patternNSN"> <xs:annotation> <xs:documentation>The 13 character of NATO Stock Number.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="NSN_Name" type="msdl:textName255" minOccurs="0"> <xs:annotation> <xs:documentation>The human readable name of the NNS code.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Post_Type_Category" type="jc3iedm:MilitaryPostTypeCategoryCode" minOccurs="0"> <xs:annotation> <xs:documentation>The military category post type.</xs:documentation>



</xs:annotation> </xs:element> <xs:element name="Post_Type_Rank" type="jc3iedm:MilitaryPostTypeRankCode" minOccurs="0"> <xs:annotation> <xs:documentation>The military rank post type.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Holdings" type="msdl:HoldingsType" minOccurs="0"> <xs:annotation> <xs:documentation>The quantity of all specific Equipment/Consumable that is held by, installed in, or included with the unit</xs:documentation> </xs:annotation> </xs:element> ---------------------------------------------------------------

New Element in <xs:complexType name="EquipmentModelType">:

<xs:element name="EntityType" type="msdl:patternEntityType"/> ---------------------------------------------------------------

New complexTypes:

<xs:complexType name="HoldingsType"> <xs:annotation> <xs:documentation>The quantity of all specific Equipment/Consumable defined by a Nato Stock Number that is held by, installed in, or included with a unit.</xs:documentation> </xs:annotation> <xs:sequence maxOccurs="unbounded"> <xs:element name="Holding" type="msdl:HoldingType"/> </xs:sequence> </xs:complexType> <xs:complexType name="HoldingType"> <xs:annotation> <xs:documentation xml:lang="en">The quantity of each specific Equipment/Consumable defined by a Nato Stock Number that is held by, installed in, or included with a unit.</xs:documentation> </xs:annotation>



<xs:sequence> <xs:element name="NSN_Code" type="xs:string"> <xs:annotation> <xs:documentation xml:lang="en">The 13 digits of NATO Stock Number of the equipment or consumable that the report deals with.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="NSN_Name" type="xs:string" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">The human readable name of the NSN code.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="IsEquipment" type="xs:boolean" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">Optionnaly define the category of the item (equipment or consumbale). Maybe redundant with the first 4 digit of the NSN_Code, but this attribute is easier to interprate.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="OperationalCount" type="xs:double" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">The integer value representing the number of specific OBJECT-TYPEs a specific OBJECT-ITEM has available for operations. For simulation purpose, it's mapped to the quantity of available and operational Equipment/Consumable (without reserve) at the instant of the report in the unit.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="TotalQuantity" type="xs:double" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">The numeric value representing the total quantity, to include reserves, of specific OBJECT-TYPEs physically held by a specific OBJECT-ITEM. The unit of measure is derived from the OBJECT-TYPE specification.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Post_Type_Category" type="jc3iedm:MilitaryPostTypeCategoryCode" minOccurs="0"> <xs:annotation>



<xs:documentation>The military category post type.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="Post_Type_Rank" type="jc3iedm:MilitaryPostTypeRankCode" minOccurs="0"> <xs:annotation> <xs:documentation>The military rank post type.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="OnHandQuantity" type="xs:double" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">The numeric value representing the quantity of specific OBJECT-TYPEs physically held on-hand, not including reserves, by a specific OBJECT-ITEM. For simulation purpose, it's mapped to the quantity of available and [operational + damaged] Equipment (without reserve) at the instant of the report in the unit. If simulation doesn't provide this attribute, it means that it doesn't manage damaged equipments. It’s not used for consumables.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="RequiredTotalQuantity" type="xs:double" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">The numeric value representing the total quantity of specific OBJECT-TYPEs required to be held on-hand and in reserve by a specific OBJECT-ITEM to meet the NATO assigned task in accordance with Force Standards or established mission requirements.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="RequiredOnHandQuantity" type="xs:double" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">The numeric value representing the quantity of specific OBJECT-TYPEs, not including reserves, required to be held on-hand by a specific OBJECT-ITEM in accordance with Force Standards or established mission requirements. For simulation purpose, it's mapped to the theorical quantity of Equipment/Consumable (without reserve) in the unit.</xs:documentation> </xs:annotation> </xs:element>



<xs:element name="RequiredCalculationMethodCode" type="xs:double" minOccurs="0"> <xs:annotation> <xs:documentation xml:lang="en">The specific value that represents the required stocks calculation method used for the count of OBJECT-TYPEs in a specific HOLDING.</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="UnitTypeType"> <xs:annotation> <xs:documentation>The description of a Unit Type of a Military Scenario.</xs:documentation> </xs:annotation> <xs:all> <xs:element name="cmd_function_ind_code" type="jc3iedm:OrganisationTypeCommandFunctionIndicatorCode"/> <xs:element name="service_code" type="jc3iedm:MilitaryOrganisationTypeServiceCode"/> <xs:element name="unit_type_cat_code" type="jc3iedm:UnitTypeCategoryCode"/> <xs:element name="arm_cat_code" type="jc3iedm:UnitTypeArmCategoryCode"/> <xs:element name="size_code" type="jc3iedm:UnitTypeSizeCode"/> <xs:element name="unit_type_arm_spclsn_code" type="jc3iedm:UnitTypeArmSpecialisationCode" minOccurs="0"/> <xs:element name="unit_type_suppl_spclsn_code" type="jc3iedm:UnitTypeSupplementarySpecialisationCode" minOccurs="0"/> <xs:element name="unit_type_gen_mob_code" type="jc3iedm:UnitTypeGeneralMobilityCode" minOccurs="0"/> <xs:element name="unit_type_qual_code" type="jc3iedm:UnitTypeQualifierCode" minOccurs="0"/> <xs:element name="mil_type_cat_code" type="jc3iedm:MilitaryPostTypeCategoryCode" minOccurs="0"/> <xs:element name="mil_type_rank_code" type="jc3iedm:MilitaryPostTypeRankCode" minOccurs="0"/> </xs:all> </xs:complexType>



INTENTIONALLY BLANK

ANNEX C to AMSP-04 LIST OF ACRONYMS

C-1 Edition (A) Version 1.0 (Draft 3)

ANNEX C LIST OF ACRONYMS a.k.a. also known as ACT Allied Command Transformation AGL Above Ground Level AMSL Above Mean Sea Level AMSP Allied Modelling and Simulation Publication ANNC CP Anglo Netherlands Norwegian Cooperation Programme 27 API Application Programming Interface ASCII American Standard Code for Information Interchange ATP Allied Tactical Publication BML Battle Management Language BOM Base Object Model C2 Command and Control CAX Computer Assisted eXercises C-BML Coalition Battle Management Language CBRN Chemical, Biological, Radiological and Nuclear CFBLNet Combined Federated Battle-Lab Network CGF Computer Generated Forces CM Conceptual Modelling COLPRO Collective Protection COTS Commercial Off The Shelf DCE Distributed Computing Environment DD Date DIS Distributed Interactive Simulation DMAO Distributed Simulation Engineering and Execution Process Multi-Architecture Overlay DSEEP Distributed Simulation Engineering and Execution Process Dstl Defence Science and Technology Laboratory EMF Exercise Management & Feedback FAFD Federation Architecture and FOM Design FEDEP Federation Development and Execution Process FFI Forsvarets forskningsinstitutt (Norwegian Defence Research Establishment) FOM Federation Object Model GMF German Maritime FOM GRIM Guidance, Rationale, & Interoperability Modalities HASP Hazard Assessment Simulation and Prediction HCBML High level C-BML HH Hour HLA High-Level Architecture HRF Higher Resolution Federate HUMINT Human Intelligence I2 Image Intensifier ID Site Identifier



IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers Init Initialization IP Internet Protocol IPE Individual Protective Equipment ISO International Organization for Standardization JC3IEDM Joint Consultation, Command and Control Information Exchange Data Model LAN Local Area Network LBML Low-level BML LTUAF Lithuanian Air Force M&S Modelling and Simulation MIM (ANNEX) MM Minute MM Month MRM Multi Resolution Modelling MSDL Military Scenario Definition Language MSG Modelling and Simulation Group NA Not Applicable NATO North Atlantic Treaty Organization NBC Nuclear, Biological and Chemical NED NATO Effective Date NETN NATO Education and Training Network NLD Netherlands NMSG NATO Modelling and Simulation Group NOR Norway NSN NATO Stock Number NSO NATO Standardization Office OMT Object Model Template ORBAT Order of Battle OS Operating System OSF Open Software Foundation QoS Quality of Service REF Reference RPR Real-time Platform Reference RPR2 Real-Time Platform Reference FOM v2.0 RTI Run-Time Infrastructure RTO Research and Technology Organisation SCP Service Consumer-Provider SDEM Simulation Data Exchange Models SIM/Sim Simulation SISO Simulation Interoperability Standards Organization SIW Simulation Innovation Workshop SP Service Provider SS.SSS Seconds and milliseconds STANAG Standardisation Agreement



STANREC Standardization Recommendation STD Standard STD State-Transition Diagram SuTBw Simulation and Testing Environment of the Bundeswehr TEK Technical Subgroup TMR Transfer of Modelling Responsibility TNO Nederlandse Organisatie voor Toegepast Natuurwetenschappelijk Onderzoek (Netherlands Organisation for Applied Scientific Research) TR Technical Report UA Underwater Acoustics UTC Coordinated Universal Time UUID Universally Unique Identifier VPN Virtual Private Network WAN Wide Area Network XML eXtensible Markup Language YYYY Year



INTENTIONALLY BLANK

Documents

NATO STANDARD AMSP-04 NATO Education and Training …€¦ · Version 1 NATO EDUCATION AND TRAINING NETWORK FEDERATION ARCHITECTURE AND FEDERATION OBJECT MODEL DESIGN, which has been