SISO-STD-XXX Standard for Command and Control Systems - Simulation Systems Interoperation. Version 1.0. DD Month 2018

Transcription

1 SISO-STD-XXX-2018 Standard for Command and Control Systems - Simulation Systems Interoperation Version 1.0 DD Month 2018 Prepared by Command and Control Systems - Simulation Systems Interoperation Product Development Group

2 Copyright 2018 by the Simulation Interoperability Standards Organization, Inc. P.O. Box Orlando, FL , USA All rights reserved. Permission is hereby granted for SISO developing committee participants to reproduce this document for purposes of SISO product development activities only. Prior to submitting this document to another standards development organization for standardization activities, permission must first be obtained from the SISO Standards Activity Committee (SAC). Other entities seeking permission to reproduce this document, in whole or in part, must obtain permission from the SISO Inc. Board of Directors. Copyright 2018 SISO. All rights reserved Page 2 of 50

3 Revision History SISO-STD-XXX-YYYY Version Section Date Description (MM/DD/YYYY) v3 All updates from consolidated draft v2 DRAFT Changes HISTORY (from LDMConsolidated v3): Updated Section 7 Synchronized Section 5 with v0.8 of the OWL file Removed Classes Unit, AreaGraphic, LineGraphic, PointGraphic, MapGraphic, TaskForce Added caveat for Appendix C Removed Appendix G Fixed spelling and formatting issues To be done: Review consistency of formatting (headings/number of levels in ToC etc) Add Figure 9.4 Synchronize mapping table in Appendix C Review acronyms table to synchronize with content Copyright 2018 SISO. All rights reserved Page 3 of 50

4 Participants At the time this product was submitted to the Standards Activity Committee (SAC) for approval, the Product Development Group had the following membership and was assigned the following SAC Technical Area Director: Product Development Group Dr. Mark Pullen (Co-Chair) Kevin Galvin (Co-Chair) Kevin Gupton (Vice-Chair) Dr. Thomas Remmersmann (Vice-Chair) Dr. Rob Wittman (Vice-Chair) SAC Representative Name (SAC Technical Area Director) The Product Development Group would like to especially acknowledge those individuals that significantly contributed to the preparation of this product as follows: PDG Drafting Group Dr. Samuel Singapogu (Lead Editor) Thomas DeCarlo (Secretary) Curtis Blais Douglas Corner Dr. Saikou Diallo Kevin Galvin Dr. Douglas Reece Kevin Gupton Dr. Thomas Remmersmann Dr. Mark Pullen Dr. Rob Wittman Magdalena Wolski (Others to be added) The following individuals comprised the ballot group for this product. Ballot Group Member Name Member Name Member Name..<continue with all the other Ballot Group member names and place all in alphabetical order> When the Standards Activity Committee approved this product on DD Month YYYY, it had the following membership: Standards Activity Committee Copyright 2018 SISO. All rights reserved Page 4 of 50

5 Member Name (Chair) Member Name (Vice Chair) Member Name (Secretary) Member Name Member Name Member Name..<continue with all the other SAC member names and place all in alphabetical order> When the Executive Committee approved this product on DD Month YYYY, it had the following membership: Executive Committee Member Name (Chair) Member Name (Vice Chair) Member Name (Secretary) Member Name Member Name Member Name..<continue with all the other EXXOM member names and place all in alphabetical order> Copyright 2018 SISO. All rights reserved Page 5 of 50

6 Copyright 2018 SISO. All rights reserved Page 6 of 50

7 TABLE OF CONTENTS Introduction 1. Overview Scope Purpose Objectives Intended Audience References (Normative) SISO References Other References Bibliography: Definitions, Acronyms, and Abbreviations Definitions Acronyms and abbreviations Compliance Strategy for the C2SIM Standards Set Logical Data Model Element Compliance Physical Data Model Element Compliance C2SIM Family of Standards Compliance Description of the Core LDM (Informative) Extending the LDM Initialization Procedures Tasking/Reporting Procedures Message Exchange Header Information Sender Receiver ReplyTo Message ID Conversation ID Performative ReplyWith inreplyto ReplyBy Copyright 2018 SISO. All rights reserved Page 7 of 50

8 Protocol and Version Message Processing Order Message Flow Appendix A Generating XML schema using Sparx Enterprise Architect (Informative) Appendix B Brief Overview of OWL (Informative) APPENDIX C Mappings between C2SIM and other standards...44 APPENDIX D Top-Level Architecture 46 APPENDIX E Generating XML schema using Sparx Enterprise Architect..47 Appendix F Tools to Work with C2SIM Web Ontology Language (OWL) Model (Informative)...50 Copyright 2018 SISO. All rights reserved Page 8 of 50

9 LIST OF FIGURES Figure 5.1 LDM Core Ontology Heirarchy Figure 9.1. Top-Level Message Processing Strategy Figure 9.2. Message flow that is triggered by a received order Figure 9.3 Message flow that is triggered by a request Figure D.1. C2SIM Top-Level Architecture Figure E. 1. Generating XML schemata from C2SIM LDM-1 (Screenshot from Sparx Enterprise Architect v 12.1) Figure E. 2. Generating XML schemata from C2SIM LDM-2 (Screenshot from Sparx Enterprise Architect v 12.1) Figure E. 3. Generating XML schemata from C2SIM LDM-3 (Screenshot from Sparx Enterprise Architect v 12.1) Copyright 2018 SISO. All rights reserved Page 9 of 50

10 LIST OF TABLES Table 1. Definitions Table 2. Communicative acts and possible responses Copyright 2018 SISO. All rights reserved Page 10 of 50

11 Standard for Introduction Command and Control Systems to Simulation Systems Interoperation (C2SIM) is a family of standards for expressing and exchanging Command and Control (C2) information between C2 systems, simulation systems, and robotic and autonomous (RAS) systems in a coalition context. Military operations in today s world are increasingly driven towards coalition participation and as such are dependent on effective interoperation between participating coalition systems. The growth of digitized C2 systems and the need for coalition interoperation has created a need for standards to represent and exchange digitized C2 information and for these systems to interoperate. The Simulation Interoperability Standards Organization (SISO) supports the identification and creation of standards to help in the interoperability of simulation and operational communities. In the past few years SISO has supported the standardization of Coalition Battle Management Language (C-BML, SISO-STD ) and Military Scenario Definition Language (MSDL, SISO-STD ). The C2SIM Product Development Group has consolidated both C-BML and MSDL with the goal to create a unified standard that provides seamless integration between C2 initialization, tasking, and reporting with simulation systems and robotic systems. The C2SIM PDG has four sub-groups that focus on individual aspects of C2SIM development. The sub-groups are: 1. C2SIM-Logical Data Model will provide, at a logical level (i.e., independent of how the data will be communicated), a core set of data elements common to most C2 and Simulation systems, combined with a standard way of adding to that core a collection of additional elements specific to a particular domain and/or context. 2. C2SIM-Initialize will supersede the MSDL v1 standard and is an XML message format developed with the purpose of initializing the operational environment (OE) in a wide variety of simulations and connected systems. Applications of the initialization messages include description of partial or complete start conditions for simulation execution (e.g., events and exercises) and contextual information defining the truth or belief conditions of actors in simulations. Other applications include defining simulation checkpoint (snapshots of past simulation conditions for reset or rollback operation), describing multiple courses of action (CoA), or contexts in the past, present, or future (e.g. planned, preset, anticipated, and objective states). 3. C2SIM-TaskingReporting will supersede the C-BML v1 standard and is an XML message format developed with the purpose of describing task and report messages in operational or simulation environments. The new product expands the range of tasking and situational awareness information relative to the C-BML v1 standard. Task and report messages may be utilized during execution of simulations as runtime messages between real or simulated entities and as a common format for conveying information to and from tactical message formats based on the C2SIM LDM. 4. C2SIM-ManeuverWarfareExtension will serve as an exemplar for other C2SIM extensions. It also will provide for continuity with maneuver warfare aspects of MSDL and C-BML that are not included in the LDM Core but are in use in the international community. Copyright 2018 SISO. All rights reserved Page 11 of 50

12 1. Overview Command and Control Systems to Simulation Systems Interoperation is being developed as a standard to support interoperation between C2 systems, simulation systems, and robotics and autonomous systems (RAS) in a coalition context. The C2SIM PDG replaced the C-BML and MSDL PDGs and Product Support Groups (PSGs) Scope C2SIM covers the initialization, tasking, and reporting of forces. Initialization contains all information necessary for creating and describing forces, situation (weather, etc.), and control measures across interoperating C2 and simulation systems. Tasking and Reporting covers all information necessary to create tasks, provide situational reports, and manage forces between interoperating C2 system, simulation systems, and RAS Purpose This document describes the C2SIM LDM standard and provides a normative description of the scope and use of C2SIM. C2SIM uses a model driven framework that formalizes a Logical Data Model and a mechanism to extend the data model for specialized use. The design enables participating systems to interoperate Objectives The primary objective of this standard is to provide C2 systems, simulation systems, and RAS the ability to use the C2SIM LDM to generate an XML schema suitable to their needs to represent and exchange digitized C2 information. Using the LDM, systems can generate data needed for scenario initialization, tasking, and reporting Intended Audience The primary audience is the C2 community, the modeling and simulation community, and the RAS community. Other communities of interest can leverage the C2SIM LDM to create customized extensions for their domains. Copyright 2018 SISO. All rights reserved Page 12 of 50

13 2. References (Normative) 2.1. SISO References SISO-STD-XXX-YYYY # Document Number Title Date 1. SISO-PN C2SIM Product Nomination TBD revision SISO-STD Version 1.0 Standard for Coalition Battle Management Language 14 Apr SISO-STD Standard for Military Scenario Definition Language reaffirmed 11 May Other References # Document Number Title Date 4. MIL-STD-2525B, 30 Defense Information Systems Agency, Department of 1 July 2005 January 1999, w/change 1, 1 July 2005 Defense. MIL-STD-2525B, Common Warfighting Symbology. 5. NATO APP-6 NATO Symbology reference 6. MIP JC3IEDM web site JC3IEDM, Annexes, and.xsd Domain Values 7. NIMA TM , 20 September Datums, Ellipsoids, Grids, and Grid Reference Systems. Edition 1. US National Imagery and Mapping Agency (NIMA) 8. NIEM National Information Exchange Model 20 September Bibliography: Document Number Title 1 APP-6 MILITARY SYMBOLS FOR LAND BASED SYSTEMS. NATO. July SISO-ADM SISO-ADM SISO-ADM SISO-PDG-PN-MSDL SISO Policies and Procedures (P&P) SISO Balloted Products Development Process (BPDP) Policy for: The Style and Format of SISO documents MSDL Product Nomination 6 XML World Wide Web Consortium (W3C) web site XML Schema UN/CEFACT XML Naming United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) XML Naming and Design Rules Copyright 2018 SISO. All rights reserved Page 13 of 50

14 and Design Rules Version 2.0 of 17 February 2006 Copyright 2018 SISO. All rights reserved Page 14 of 50

15 3. Definitions, Acronyms, and Abbreviations English words are used in accordance with their definitions in the latest edition of Webster's New Collegiate Dictionary [ref#] except when special SISO Product-related technical terms are required Definitions Table 1. Definitions Term Core Domain Extension Attribute COA Complex Element Compliant Definition A set of formally defined information elements and associated definitions that are commonly used as part of C2SIM Data, applicable to all or most domains (military, medical, etc.) and/or communities (international, national, services, functional areas, etc.) A formally defined information element and associated definition that is commonly used only within a specific domain (military, medical, etc.) and/or community (international, national, services, functional areas, etc.) A characteristic of an object or entity. (ref Organisation for Economic Co-operation and Development OECD Glossary of statistical terms [As proposed and accepted by the C2SIM PDG 1 March 2016] Course of Action: A sequence of activities that an individual or unit may follow. (Army Planning and Orders Production, FM 5-0, Department of the Army, USA) A unit of information (object) for which the definition, identification, representation, and permissible values are specified by means of a set of existing Simple Elements and/or Complex Elements. [As proposed and accepted 1 March 2016] Agreeing with a set of rules, standards, or requirements. ( [As proposed and accepted 1 March 2016] Conceptual Data Model A conceptual data model is a high-level description of a business s informational needs. It typically includes only the main concepts and the main relationships among them. Typically, this is a first-cut model, with insufficient detail to build an actual database. This level describes the structure of the whole database for a group of users. The conceptual data model is also known as the data model as the data model can be used to describe the conceptual schema when a Copyright 2018 SISO. All rights reserved Page 15 of 50

16 database system is implemented. It hides the internal details of physical storage and targets on describing entities, datatypes, relationships, and constraints. (update 11/13/2016) Core Domain Extension Ground Truth Information Element or Simple Element Intelligence: A set of formally defined information elements and associated definitions that are commonly used as part of Scenario Start and Context Data, applicable to all or most domains (military, medical, etc.) and/or communities (international, national, military services, functional areas, etc.) [As proposed and accepted by the C2SIM PDG 1 March 2016] A formally defined information element and associated definition that is commonly used only within a specific domain (i.e. military, military-maneuver, medical, etc.) and/or community (international, national, military service, functional areas, etc.) [As proposed and accepted by the C2SIM PDG 1 March 2016] A scenario describes a battlespace containing elements 1 that interact with each other. In support of these interactions, each element may have certain knowledge of the other elements in the scenario. The actual description of the elements is referred to as the ground truth aspect of the item being described because what it describes is the truth in the context of the scenario. These descriptions are exact and not the result of interpretation by the scenario elements. An atomic and inseparable unit of information (object) for which the definition, identification, representation, and permissible values are specified by means of a set of attributes. (ref Organisation for Economic Cooperation and Development OECD Glossary of statistical terms [As proposed and accepted by the C2SIM PDG 1 March 2016] 1. The product resulting from the collection, processing, integration, analysis, evaluation, and interpretation of available information. 2. Information and knowledge obtained through observation, investigation, analysis, or understanding. 1 The term element in this section describes battlespace and scenario things and does not equate to the XML element definition as in the rest of the specification. Copyright 2018 SISO. All rights reserved Page 16 of 50

17 (Dictionary of Military and Associated Terms, Joint Publication 1-02, Department of Defense, USA) 2 Logical Data Model Mandatory METT-TC MOOTW Graphics: Military scenario: Object Optional A logical data model or logical schema is a data model of a specific problem domain expressed independently of a particular database management product or storage technology (physical data model) but in terms of data structures such as relational tables and columns, object oriented classes, or XML tags. This is as opposed to a conceptual data model, which describes the semantics of organization without reference to technology. (update 11/13/2016) Required by a law or rule. ( [As proposed and accepted by the C2SIM PDG 1 March 2016] Mission, enemy, terrain and weather, troops and support available, time available and civil considerations. The information that is gathered as part of the Intelligence Preparation of the Battlefield (IPB) process (Army Planning and Orders Production, FM 5-0, Department of the Army, USA). Military operations other than war graphics information captures and describes violent activities, locations, operations, and items. (MIL-STD-2525B) A specific description of the situation and course of action at a moment in time for each element in the scenario. The description of the scenario conveys reality (what is true about the situation, such as the forces identified as participants in the situation) and perceived reality (what is considered to be true based on intelligence information). Anything that is perceivable or conceivable. (ref Organisation for Economic Co-operation and Development OECD Glossary of statistical terms [As proposed and accepted by the C2SIM PDG 1 March 2016] Available as a choice but not required. 2 The definitions for intelligence have been modified to allow information and knowledge concerning friendly forces and the environment. The kind of information and knowledge is unspecified in the definition and as such could include COA-relevant data. Copyright 2018 SISO. All rights reserved Page 17 of 50

18 ( [As proposed and accepted by the C2SIM PDG 1 March 2016] Perception Physical Data Model Redundant Core Redundant Domain Extension Each scenario element s knowledge of the battlespace. Multiple perception descriptions of a single element will exist in the context of the scenario since multiple elements may have specific knowledge of other elements. These descriptions represent the result of perceptions gathering process and stored within the initialization data set. A physical data model is a representation of a data design as implemented, or intended to be implemented, in a database management system. In the lifecycle of a project it typically derives from a logical data model, though it may be reverseengineered from a given database implementation. A complete physical data model will include all the database artifacts required to create relationships between tables or to achieve performance goals, such as indexes, constraint definitions, linking tables, partitioned tables, or clusters. Analysts can usually use a physical data model to calculate storage estimates; it may include specific storage allocation details for a given database system. A set of formally defined information elements and associated definitions that are commonly used as part of C2SIM Data, applicable to all or most domains (military, medical, etc.) and/or communities (international, national, services, functional areas, etc.) A formally defined information element and associated definition that is commonly used only within a specific domain (military, medical, etc.) and/or community (international, national, services, functional areas, etc.) 3.2. Acronyms and abbreviations Acronym or Abbreviation BMNT BSO COA COP Meaning Begin Morning Nautical Twilight Battle Space Object Course of Action Common Operational Picture Copyright 2018 SISO. All rights reserved Page 18 of 50

19 DIS EENT EXCOM GCC GDC IFF JC3IEDM RAS Distributed Interactive Simulation End Evening Nautical Twilight Executive Committee Geocentric Coordinate Geodetic Coordinate Identification, Friend of Foe Joint Consultation, Command, and Control Information Exchange Data Model Robotic and Autonomous System Copyright 2018 SISO. All rights reserved Page 19 of 50

20 4. Compliance Strategy for the C2SIM Standards Set This section defines the compliance strategy for the C2SIM family of standards. The overall compliance strategy of the C2SIM family of standards is based on adherence to the selected elemental definitions within the data model and the use of these commonly defined elements when transmitting data between interested participants. Because the C2SIM standard set includes both a Logical Data Model (LDM) and the instantiation of the Physical Data Model (PDM) from the contents of the LDM the compliance strategy benefits from supporting both the LDM and the PDM constructs under the same conceptual foundation. The underlying principle to support interoperability is to establish C2SIM compliance at the data-model element level. The following subsections describe element level compliance in terms of the LDM, PDM, and the overall compliance with the C2SIM family of standards Logical Data Model Element Compliance Logical Data Model Elements (includes both Simple and Complex Elements) shall not be duplicative. (There shall be only one Element per concept within the core Logical Data Model) Logical Data Model Attributes shall not be duplicative. (There shall be one definition per Attribute that will be used within the appropriate Element definitions.) The Logical Data Model shall be described using the C2SIM LDM specification Physical Data Model Element Compliance Physical Data Model Elements (includes both Simple and Complex Elements) shall not be duplicative. (There shall be only one Element per concept within the core Physical Data Model) Physical Data Model Attributes shall not be duplicative. (There shall be one definition per Attribute that will be used within the appropriate Element definitions.) The Physical Data Model shall be described using the C2SIM PDM specification C2SIM Family of Standards Compliance The use of Core Elements (both Simple and Complex) is optional (they do not have to be used in every application all of the time); however, if an Element is needed and the Element is represented within the set of Core Elements then the existing Core Element shall be used. The use of Domain Elements are optional when creating a domain specific data set; however if an Element is needed and the Element is represented within the set of Core or Domain Elements then the existing Core or Domain Element shall be used. If an Element is needed that is not in the Core or Domain Element set it can be added and compliant such that it abides by the Logical Data Model and Physical Data Model compliance constraints. When creating an interoperable federation or system of systems using C2SIM compliant systems engineers must agree on the common C2SIM Element set (Simple and Complex Elements) to use and share amongst the systems. This may result in two C2SIM compliant systems that have nothing in common to a situation where all of their LDM and/or PDM C2SIM Elements can be shared in a consistent manner. Copyright 2018 SISO. All rights reserved Page 20 of 50

21 5. Description of the Core LDM (Informative) Note: The C2SIM Core Ontology (current version: 0.6.8) is the proposed normative C2SIM LDM standard. This section is included in order to make the C2SIM standard understandable to those without understanding of ontology. Figure 5.1 LDM Core Ontology Heirarchy 1. Class Name: AbstractObject Description: An AbstractObject is an object in the system that does not have the full characteristics of an entity. 2. Class Name: AbstractState Description: This type of state represents anything that is not a physical property, e.g. morale 3. Class Name: AcknowledgeBody Description: Describes concepts in the body of a C2SIM acknowledgement message. 4. Class Name: Acknowledgement Description: Describes information to be included in a C2SIM acknowledgement message. Copyright 2018 SISO. All rights reserved Page 21 of 50

22 5. Class Name: Action Description: An action that an ActorEntity can perform to change the state of the world. 6. Class Name: ActorEntity Description: An ActorEntity is an entity that can send/receive orders and reports and/or perform tasks. 7. Class Name: Animal Description: A biological lifeform (non-human) represented in the scenario. 8. Class Name: Attitude Description: Orientation of an entity in 3D space. 9. Class Name: BoundingBox Description: A rectangle in 2D space containing the two-dimensional extent of an entity. 10. Class Name: BoundingVolume Description: A rectangular volume of 3D space containing the physical extend of an entity. 11. Class Name: C2SIMConcept Description: Top-level class for C2SIM concepts for information content and messaging. 12. Class Name: C2SIMContent Description: Class of all concepts in the core C2SIM model. 13. Class Name: CartesianOffset Description: A spatial offset expressed in Cartesian coordinates. 14. Class Name: CollectiveEntity Description: This is an Entity that is normally thought of as having consituent entities. CollectiveEntities may or may not hve their subordinates explicitly represented in the exercise (i.e., it may always be aggregated, or it may have subordinates that are themselves entities). If they are represented, then the hassubordinate property will have at least one instance. The CollectivEntity may be an abstract actor, or it may have physical properties; if the latter, then the hascurrentstate property is present with a PhysicalState. 15. Class Name: CommunicationNetwork Description: An specific network over which an entity communicates. 16. Class Name: CommunicativeAct Description: FIPA enabling class that categorizes a message based on the type of communicative act. DO WE NEED THIS? Copyright 2018 SISO. All rights reserved Page 22 of 50

23 17. Class Name: ConcreteEntity Description: An Entity that has physical/kinematic properties. 18. Class Name: CulturalFeature Description: Any man-made feature in the environment 19. Class Name: DateTime Description: A time in seconds along with a date. 20. Class Name: Duration Description: A time duration in seconds. 21. Class Name: Entity Description: An individually identified object. 22. Class Name: EntityDefinedLocation Description: A location defined by the location of a ConcreteEntity. 23. Class Name: EntityDescriptor Description: The Descriptor defines static attributes of an entity, i.e. that do not change during the course of the simulation. This information is provided at initialization time. 24. Class Name: EntityHealthStatus Description: This is a class instead of a data property because it can be represented in several different formats. 25. Class Name: EntityState Description: Dynamic state information in the exercise. 26. Class Name: EnvironmentalObject Description: A specified region in which the environment (e.g. weather, ocean state) is defined by a particular Environmental State. 27. Class Name: EnvironmentalState Description: Defines the state of weather, ocean, NBC contamination, smoke, ocean state etc. 28. Class Name: EulerAngles Description: Representation of the orientation of an entity in 3D space expressed as Euler angles. 29. Class Name: ExtentVertices Description: The locations of multiple vertices defining the space occupied by an entity. For example, points on a multipoint line or a convex hull. Copyright 2018 SISO. All rights reserved Page 23 of 50

24 30. Class Name: GeocentricCoordinateValue Description: Location of an entity in 3D space expressed in geocentric coordinates. 31. Class Name: GeodeticCoordinateValue2D Description: Latitude - longitude 32. Class Name: GeographicExerciseArea Description: Describes the terrain database or other geographic reference in which the exercise is conducted, and any bounding area of interest within the terrain. 33. Class Name: GeographicFeature Description: A geographic feature generally used for location reference. For example a hill, river, etc. 34. Class Name: Handles Description: The locations of the special locations that define the shape of a physical object, e.g. a tactical graphic. 35. Class Name: Heading Description: Angular measure of the orientation (moving or stationary) of an entity with respect to true north. 36. Class Name: IntervalTime Description: An interval defined by a start and end datetime. 37. Class Name: Location2D Description: This class specifies only location without reference to altitude or depth. The altitude is assumed to be unimportant, or otherwise constrained, e.g. by clamping to the surface of the earth. 38. Class Name: Location2DWithAltitude Description: Location of an entity in 3D space expressed as a location in 2D space and an altitude above the surface of the scenario area. 39. Class Name: Location3D Description: Location of an entity in 3D space. 40. Class Name: LocationModelingConcept Description: A representation of location in space. The location of a CollectiveEntity may represent the center of mass or headquarters location in the case of an organization. This is a class instead of a data property because it can be represented in several different formats. 41. Class Name: MapGraphic Description: Graphics on a map that define locations, lines, areas, actions, etc. The location of the graphic is the location in the real world represented on the map. The extent is the set of handle points or vertices that define its shape and size. This class includes task graphics, METOC graphics, and MOOTW graphics. Copyright 2018 SISO. All rights reserved Page 24 of 50

25 42. Class Name: Material Description: Physical assets that are significant to the exercise but that are inanimate by themselves, such as ammunition or immobilized vehicles. 43. Class Name: Message Description: Assembled data to transmit C2SIM transactions. 44. Class Name: MessageBody Description: Describes concepts in the body of a C2SIM message. 45. Class Name: MessageConcept Description: The subclasses of this class define the concepts needed to form message envelopes for C2SIM. 46. Class Name: MessageHeader Description: Describes concepts in the header of a C2SIM message. 47. Class Name: MilitaryOrganization Description: An organization operating under the military authority of a nation. 48. Class Name: NonMilitaryOrganization Description: An organization operating external to military authority (e.g., law enforcement, non-governmental organizations). 49. Class Name: OperationalStatus Description: An enumeration indicating degree of partial capability. 50. Class Name: Order Description: Describes information to be included in a C2SIM order message. 51. Class Name: Orientation Description: Orientation is a 2- or 3- degree of freedom specification in one of a number of formats. This is a class instead of a data property because it can be represented in several different formats. 52. Class Name: Overlay Description: A logical grouping of Entities for purposes of conveniently referring to them. 53. Class Name: Perception Description: This is a perception of the state of the world, including any type of EntityState or EntityDescriptor. ActorEntities may have one or more perception. 54. Class Name: Person Description: A human being represented in the scenario. Copyright 2018 SISO. All rights reserved Page 25 of 50

26 55. Class Name: PhysicalConcept Description: Concepts relating to the physical characteristics of an entity (e.g., location, health, orientation, size, etc.). The subclasses of this class have complex or alternative representations, and so are classes. Other physical properties such as mass that are simple scalars can be data type properties of (ConcreteEntity) objects. 56. Class Name: PhysicalExtent Description: A description of the space occupied by a physical object. This is a class instead of a data property because it can be represented in several different formats. 57. Class Name: PhysicalState Description: Description of the physical state of an entity, including location, orientation, health, speed, etc. 58. Class Name: Platform Description: A physical platform that is represented as a single entity in the exercise. Although it is represented as a single entity, it may at times have component parts or entities that are also represented in the exercise (for example, an aircraft with missiles, a truck with passengers, or an aircraft carrier with aircraft). 59. Class Name: PolarOffset Description: A spatial offset expressed in polar coordinates. 60. Class Name: Query Description: Describes information to be included in a C2SIM query message. 61. Class Name: RelativeLocation Description: A location defined by an offset to some reference location. 62. Class Name: RelativeTime Description: Specifies the start time of an action (task or event) in relative time. (from C-BML) 63. Class Name: Report Description: Information transmission intended to provide the sender's best understanding of status to the receiver 64. Class Name: ResourceCount Description: A level of personnel, equipment, ammunition, fuel, etc. The user must compare this to the full strength of the unit. 65. Class Name: RotationMatrix Description: Representation of the rotation of an entity in 3D space expressed as a matrix of rotations around x, y, z axes (traditionally, roll, pitch, and yaw). 66. Class Name: ScenarioState Description: Information describing the state of a scenario, to include force structures, dispositions, planned state, start time, weather, terrain, etc. Copyright 2018 SISO. All rights reserved Page 26 of 50

27 67. Class Name: ScenarioTime Description: The current date and time as defined by the scenario. That is, the date-time defined for the start of the scenario plus the elapsed simulation time since the start. 68. Class Name: ScenarioWeather Description: An example of an environmental state; could define air temperature, humidity, wind speed and direction, profiles of these over altitude or on a grid. 69. Class Name: Side Description: Side is an abstract notion of the set of entities that all have friendly Allegiance to one another. As an alternative to specifying all of the Allegiances of an Entity in its EntityDescriptor, the Side can be specified. 70. Class Name: SimulationTIme Description: A time measured in seconds since the beginning of the scenario start. 71. Class Name: SpatialOffset Description: Used in a relative location specification. This is a class instead of a data property because it can be represented in several different formats. 72. Class Name: StrengthPercentage Description: Representation of the strength of an entity expressed as a percentage of some starting value. 73. Class Name: Task Description: Discrete unit of activity that has a clear purpose, starting time, and ending time. Can include a definition of who and what (inherited from Action), when, where (Location and MapGraphics), and why (DesiredEffectCode). 74. Class Name: TemporalConcept Description: Time concepts include instants in time, durations of time, and intervals between two times. 75. Class Name: TimeInstant Description: A specific time expressed in seconds, i.e. with no date. The generator and user of this time must understand a common reference point, for example the start of the scenario. 76. Class Name: UTMCoordinateValue Description: Location of an entity in 2D space expressed in universal transverse mercator (UTM) coordinates. Copyright 2018 SISO. All rights reserved Page 27 of 50

28 6. Extending the LDM While the C2SIM LDM captures core data elements, it is expected that C2SIM implementations will need elements that are not available in the LDM. This standardized methodology will enable C2SIM implementations to interoperate after extensions. The extension methodology is designed to preserve continuity and consistency with C-BML and MSDL while allowing implementations to create new classes and attributes in the data model. The extension methodology contains two design constructs: a) Clear identification of standard data elements: The core contains a unique identifier with value Standard to identify all data elements that are in the standard core data model. All C2SIM implementations are expected to support these data elements in order to be compliant with C2SIM. b) Reference to extensions: Each data element has an attribute called referencename that points to a data file with the extension definition and any supporting documentation. C2SIM implementations will be required to consider elements defined in the core before creating duplicate extensions. TBA: Guidelines on naming convention, creation of enumerations and taxonomy definitions. Also, guidelines on submitting the extension to a C2SIM repository so that other implementations and discover and use the extension. Copyright 2018 SISO. All rights reserved Page 28 of 50

29 7. Initialization Procedures SISO-STD-XXX-YYYY The Core Initialization Interaction Model and Terms A C2SIM Initialization Data Set is composed as an instance of the LDM. This section describes how a client of the Core Initialization model requests service from the initialization data provider. The terms and interaction sequence of the interaction model are provided here. The underlying protocol for sending initialization set data is the same as for sending order and report data as defined within the LDM. The initialization interaction model and terms support the following initialization concepts: Create New Data Set This command instructs the C2SIM service to create and store a new initialization data instance with the information that provided in the payload and is consistent with section There are minimally two concepts that must be supported here: Edit Create from blank This command is used to create a new scenario instance. Create new data set Y from Data Set X This command is to create a new scenario from an existing initialization data set x. This command instructs the C2SIM service to open an existing scenario for editing. Save Open Data Set x for editing or viewing This command instructs the C2SIM service to save the data set to the name scenario or components of the scenario. Save As Save Open Data Set to same named file(s) This command instructs the C2SIM service to save the data set as a new scenario or component of a scenario. Save Open Data Set to new x named file(s) Share (Activate Scenario) This command instructs the C2SIM service to mark the scenario as complete and ready to executive as an active scenario. Import Share Open Data Set with x users/groups Mark Data Set as Complete and ready for start ex This command instructs the C2SIM service to import an MSDL file into the new C2SIM structure and open for editing. Import MSDL Data Set x to New Data Set Copyright 2018 SISO. All rights reserved Page 29 of 50

30 Export This commend instructs the C2SIM service to export a C2SIM file into support external formats. Merge a. Export Data Set using format x This command instructs the C2SIM service to merge two or more C2SIM components into a single integrated C2SIM data set. Search Merge Open Data Set with Data Set y This command instructs the C2SIM service to search the data sets and return the data sets with the identified data sets Search repository for x Delete This command instructs the C2SIM service to delete the identified data set. Delete data set x Join This command instructs the C2SIM service to send the identified data set to the client for initialization. Join data set x Print Report Print Report x (error, validation, parts complete, IA levels, description, locks, etc.) with Open, x, all Data Set 8. Tasking/Reporting Procedures 8.1 Message Exchange All Information for Tasking and Reporting are exchanged via messages (see 5.6 LDM) and communication concept is similar to FIPA ACL Message Structure Specification. Each Message contains a header, which contains most of the attributes from FIPA ACL Message Structure Specification. The overall message structure is: Copyright 2018 SISO. All rights reserved Page 30 of 50

31 The message will be an XML document encompassed in and independent of whatever network protocol is used for the actual implementation. Copyright 2018 SISO. All rights reserved Page 31 of 50

32 The header is constructed as: SISO-STD-XXX-YYYY Table 2. Communicative acts and possible responses FIPA Communicative Act Responses according to FIPA Communicative Act Library Specification Order Order Accept or Reject Acknowledge Order Response - Accept - Refuse Order Response - Reject - Request Request Accept or Reject Acknowledge Request Response - Accept - Refuse Request Response - Reject - Report Report None Copyright 2018 SISO. All rights reserved Page 32 of 50

33 8.2 Header Information SISO-STD-XXX-YYYY Sender Unique identifier of the unit or the system that sent the message Receiver Non empty list of unique identifiers of the receivers of the message ReplyTo Unique identifier of the unit or the system that should be contacted for anything concerning this message Message ID Unique identifier for the message. Other messages refer to the message using this ID Conversation ID Unique identifier for the conversation. Should be kept identical for all replies Performative Communicative act; one of the values from Table 3. Table 3. Communicative Acts Communicative Act Order Response Request Report ReplyWith Defines the expected response communicative act, or empty if no response is intended inreplyto References the message id that this message is a reply to. Element is missing if no message is referenced ReplyBy Defines the timestamp by which the sender expects the receiver to have responded to the message. Copyright 2018 SISO. All rights reserved Page 33 of 50

34 Protocol and Version SISO-STD-XXX-YYYY Should be SISO-STD-C2SIM for this version. Version Number will change with standard updates. Copyright 2018 SISO. All rights reserved Page 34 of 50

35 9. Message Processing This processing approach is expected to be used by all C2SIM clients. Note that it imposes no ordering on the messages so that initialization messages could be received at any point in the operation. In cases where a client is unable to handle particular messages in arbitrary order, the client is free to reject messages it is unable to process. Figure 9.1. Top-Level Message Processing Strategy 9.1 Order Message Flow If a system receives an order for a unit that it is responsible for it should react according to the flow diagram shown in Figure 9.2. The system might be a simulation system that simulates the unit that is named in the receiver field or a C2 system of the unit named as a receiver. C2SIM Tasking-Reporting message flow is shown in Figure 9.2. C2SIM Tasking-Reporting messages contain a Header (see LDM 5.6) and an AcknowlegeBody (see LDM 5.6) and TaskReportBody (see LDM 5.6). Copyright 2018 SISO. All rights reserved Page 35 of 50

36 Figure 9.2. Message flow that is triggered by a received order Copyright 2018 SISO. All rights reserved Page 36 of 50

37 9.2 Request Message Flow If a system receives a request for a unit that it is responsible for it should react according to the flow diagram shown in Figure 9.3. Figure 9.3 Message flow that is triggered by a request Copyright 2018 SISO. All rights reserved Page 37 of 50

38 9.3 Report Message Flow SISO-STD-XXX-YYYY If a system receives a report for a unit that it is responsible for it should react according to the flow diagram shown in Figure 9.4 (To be Added). Copyright 2018 SISO. All rights reserved Page 38 of 50

39 Appendix A Data Format Definitions JC3IEDM enumerations URL: (search for JC3IEDM in Public Document Library ) MIM enumerations URL: MSDL enumerations URL: (Development Groups > Archived PDGs > MSDL PDG) Classes in C2SIM use the data types below. Data type name datetimetypefix18 patternuuid32 affiliationgeopoliticalcode floatcompassdegrees3_3 textiff5 militaryorganisationtypeserviceco de texttypevar100 enumorientationtype enumsymbolclasstype actioneffectdescriptioncode enumoverlaytype enumcommunicationnettype Data type definition 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. The Universal Unique Identifier (UUID) of an object as defined in ISO/IEC 11578:1996 Information technology - Open Systems Interconnection - Remote Procedure Call (RPC). The specific value that represents the identification of the independent first-level geographic-political area and its dependencies, areas of quasi-independence, and areas with special unrecognized sovereignty, including outlying and disputed areas. Codes are defined in ISO Compass Degrees (Type: XSD float). Text modifier for identification friend or foe (IFF) (Type: XSD with minlength:0, maxlength:5 and pattern: ([ -z]{1})* ) The specific value that represents the type of military, paramilitary, irregular force, force or group, capable of functioning as an offensive or defensive combat or support organization (JC3IEDM Enumeration). A character string (i.e. a finite set of characters) generally in the form of words of a language. This embraces notions such as description, name, comment etc. The max length of the text is 100 characters. Orientation of the graphic to the right or left as defined in the symbology standard. (MSDL enumeration) Enumerated choice for the class of symbology modifiers. (MSDL enumeration) The specific value that represents the type of outcome of a specific ACTION that is being estimated or recorded. (JC3IEDM enumeration) A specific overlay used in the scenario that is then referenced by the control measures that are to be included on the overlay. (MSDL enumeration) List of Communications Net Types for Army Units. (MSDL enumeration) Copyright 2018 SISO. All rights reserved Page 39 of 50

40 enumcommunicationservicetype floatspeed6_2 enumechelon enumcombateffectivenesstype enumdemolitionstatuscode enumemissioncontrolcode enumoperationalstatuscode enumoperationalstatusqualifierco de enumprimaryconstructionmaterialc ode enumsecuritystatuscode latitudecoordinatetyperangelatitu de9_6 longitudecoordinatetyperangelon gitude10_6 enumangleprecisioncode dimensiontype12_3 enumdistanceprecisioncode enumverticaldistancereferenceco de enumbottomhardnesscode enumliquidsurfaceseastatecode enumliquidsurfaceconditioncode enumdirectioncode enumsolidsurfacedamagecode The list of network communications service types for Army Units. (MSDL enumeration) The field for unit or equipment speed (for display only) expressed in meter per second. (XSD float between 0 and ) Graphic modifier that identifies Command level. (MSDL enumeration) The text modifier for units and installations that indicates unit effectiveness or installation capability. (MSDL enumeration) The status of an Object destined for demolition. (MIM enumeration) The emission control status of the Facility. (MIM enumeration) The operational status of a Facility, Materiel or Organisation. (MIM enumeration) The qualification of the operational status of a Facility. The major material used in building a Facility. The protection status of the site corresponding to an Object (being either a Facility or the site encompassed by a ControlFeature). The geodetic latitude of the location of a line or plane, expressed in degrees, with positive values measured northward and negative values southward from the equator. (XSD decimal 6 digits between -90 and 90) The geodetic longitude of the location of a line or plane, expressed in degrees, with positive values measured eastward and negative values westward from the zero meridian. (XSD decimal 10 digits between -180 and 180) The specific value that represents the maximum resolution used for the expression of a value of an angle. (JC3IEDM enumeration) A one-dimensional linear distance measure expressed in meters. (XSD decimal between 3 and 12 digits, value between and ) The specific value that represents the maximum resolution used for the expression of a linear measure. (JC3IEDM enumeration) The specific value that represents the reference system for a specific VERTICAL-DISTANCE. (JC3IEDM enumeration) The subjective indication obtained by a diver of the hardness of the liquid/solid surface interface. It is the result of a single arm thrust. The range of wave heights on a liquid surface. (MIM enumeration) The physical status of a liquid surface area. (MIM enumeration) The direction of waves in a liquid surface (MIM enumeration) The damage status of a solid surface. (MIM enumeration) Copyright 2018 SISO. All rights reserved Page 40 of 50

41 enumsolidsurfaceconditioncode enumsolidsurfacefirmnesscode enumsolidsurfacecompositioncod e enumsurfacecategorycode enumgeorgraphicfeatureterrainco de enumimagetypecode enumreinforcedreducedtype enumframeshapemodifiertype enumbodycolorcode enummarkingcode enummarkingcolourcode enummaterielsupplyclasscode enumechelonsizecode enumvisibilitycategorycode enumvisibilitydirectioncode enumcommunicativeactcategoryc ode enumactiontaskactivitycode enumtemporalassociationcategory Code enumatmosphereinversionlayerco de enumatmospherepressuresystemc ategorycode enumatmospheretemperaturegrad ientcode enumcloudcovercategorycode The physical status of a solid surface area. (MIM enumeration) The firmness of a surface area, in terms of its ability to support land vehicles or helicopters (MIM enumeration) The composition of the surface of the GeographicFeature. The type of surface of the GeographicFeature. The tract of land. (MIM enumeration) The media used to record the photographic product. (MIM enumeration) The graphic modifier in a unit symbol that displays (+) for reinforced, (-) for reduced, (±) for reinforced and reduced. (MSDL enumeration) The modifier of the frame shape to support affiliations (hostile, friend, unknown, and neutral). (MSDL enumeration) The colour scheme of the Materiel (MIM enumeration) The type of marking of the Materiel (MIM enumeration) The colour of the markings of the Materiel. (MIM enumeration) The NATO supply class of the Materiel. (MIM enumeration) The specific value that represents the relative size of the commonly accepted configuration of military formations. The specific value that represents the class of obscurant that governs a particular VISIBILITY. The specific value that represents the direction for which a specific VISIBILITY is valid. FIPA categorization of a message (options are: Inform, Confirm, Refuse, Request, Agree, Accept). The specific value that represents the type of activity prescribed by the ACTION-TASK. (JC3IEDM enumeration) The specific value that represents the class of chronological relationship of a subject ACTION to an object ACTION for a specific ACTION-TEMPORAL-ASSOCIATION. (JC3IEDM enumeration) The specific value that represents the height of the inversion layer in the atmosphere. The stability class describes the degree of mixing of released material in the atmosphere. (JC3IEDM enumeration) The specific value that represents the class of a pressure system in a particular Atmosphere. (JC3IEDM enumeration) The specific value that represents heat change with respect to the ground and 100 m in elevation in a certain area. Acts as an indication of vertical air movement between the ground and higher elevations. The specific value that represents the prevailing class of a specific CLOUD-COVER. (JC3IEDM enumeration) Copyright 2018 SISO. All rights reserved Page 41 of 50

42 enumcloudcoveraveragecoverage Code enumicingcategorycode enumicingseverityqualifiercode enumlightcategorycode enummoonphasecode enumprecipitationcategorycode enumdirectioncode enumwindcategorycode enumwindairstabilitycategorycode enumwindaltitudelayercode enumcontrolfeaturetypecategory Code enumactionfunctionalassociationc ategorycode enumplanorderdistributionacknowl egementcode enumactiontaskstatusprogressco de The specific value that represents the average density of a specific CLOUD-COVER as fractional coverage. The specific value that represents the class of a particular ICING. (JC3IEDM enumeration) The specific value that represents the severity of a particular ICING. (JC3IEDM enumeration) The specific value that represents the class of LIGHT. (JC3IEDM enumeration) The specific value that represents the phase of the moon for a specific LIGHT. The specific value that represents the prevailing class of a specific PRECIPITATION. The specific value that represents the direction for which a specific VISIBILITY is valid. The specific value that represents the class of WIND. The specific value used to indicate the class of air stability. The specific value used to indicate the class of the altitude for a specific set of reported wind data. The specific value that represents the class of CONTROL- FEATURE-TYPE. The specific value that represents the class of relationship of subject ACTION to object ACTION. The specific value that represents the type of acknowledgement of the distribution for a specific PLAN- ORDER and a specific recipient. (JC3IEDM enumeration) JC3IEDM Values are Acknowledged, Read and Received. The additional value Not Understood is allowed and should be used if the receiver cannot understand the message and cannot respond more specifically. The specific value that represents the perceived appraisal of the progress of a specific ACTION-TASK. (JC3IEDM enumeration) Copyright 2018 SISO. All rights reserved Page 42 of 50

43 Appendix B Brief overview of OWL (Informative) To Be Added Copyright 2018 SISO. All rights reserved Page 43 of 50

44 APPENDIX C Mappings between C2SIM and other standards Caveat: Table below is deprecated; will be synchronized to the LDM (Section 5) shortly. Note: NF= Not Found, TBA= To Be Added (Needs Further research) Class Name Mappings C-BML Full C-BML Light MSDL MIM NIEM Echelon NF NF Echelon NF cbrn:militar yunitsizet ext MilitaryService NF NF MilitaryService NF jc3iedm:mi litaryorgan izationcat egoryservi cecode Entity ObjectItem ObjectItem Unit NF nc:entity CommunicationN NF NF Communicatio NF TBA etinstances nnetinstances Materiel AbstractMateriel NF NF Materiel NF DesiredEffectCod e ActivityCode Type ActionEffectDes criptioncode enumactiontask ActivityCode ActionEffectDesc riptioncode ActionTaskActivit ycode NF ActionTaskAct ivitycode ActionEffect Description Code ActionTask ActivityCod e nc:activity. ActivityRe asontext Affiliation NF NF Affiliation Affiliation nc:person Organizati onaffiliatio nassociati on Allegiance NF NF AllegianceHan dle CommunicativeA cts DateTime RelativeDateTim e DirectionOfMove ment NF NF NF NF NF NF intel:perso naffiliation Associatio n StartWhenAbsol utetimetype StartWhenAbsolu tetimetype DateTimeGrou p NF xs:datetim e StartWhenRelati StartWhenRelativ NF NF TBA vetimetype etimetype DirectionCode DiectionCode DirectionOfMo NF mo:course vement AngleMea sure Orientation NF NF Disposition NF NF AreaOfInterest NF NF AreaOfInterest NF nc:areage ographic GeoCoordinateV alue AbstractLocation PointLightType Location Location nc:locatio n3dgeosp atialcoordi nate (of complex type Copyright 2018 SISO. All rights reserved Page 44 of 50

45 Geographicfeatur e SISO-STD-XXX-YYYY GeographicFeat uretype AtWhereLightTyp e+routewhereli ghttype NF Geographicf eature nc:locatio n3dgeosp atialcoordi natetype) geo:featur e RelativeLocation LocationRef LocationRef NF NF cbrn:relati velocation (of complex type cbrn:relati velocation Type) Version NF NF NF NF cbrn:versi onid Name NameText NameText NF Name nc:organiz ationname UniqueDesignatio NF NF UniqueDesign NF NF n ation ObjectHandle patternuuid32 patternuuid32 ObjectHandle NF mo:identifi cationuui D IFF NF NF IFF NF NF Copyright 2018 SISO. All rights reserved Page 45 of 50

46 APPENDIX D Top-Level Architecture From stove piped mediation and translation to brokered interactions and canonical data models (TBA) This architecture applies to all parts of C2SIM and shows how C2SIM interoperation has been achieved up to the time this standard was drafted. The C2SIM system-of-systems may be referred to as a "coalition". Its major components are: a) C2 System(s) - networked software/hardware systems capable of composing orders, submitting those orders, accepting situational awareness reports, and conveying the contents of those reports externally b) Server System(s) - networked platforms, multiple of which may cooperate in a distributed configuration, capable of receiving subscriptions from participating C2 and simulation systems, accepting orders and reports from those systems, storing the latest state of simulated objects, forwarding reports to subscribing systems, and responding to queries with latest state of the objects. c) Simulation System(s) - networked software/hardware systems, capable of using physics and organizational principles to project likely outcome when objects in real or virtual worlds interact in response to direction from orders and emit report messages. d) Transaction Log - automated, time-stamped record of all reports and orders accepted/transmitted by a server. Available for after-action inspection. e) Replay - capability associated with a server that can read a transaction log and inject its contents, on a time-synchronized basis, back into a server. The result is expected to be that the participating C2 and simulation systems experience the original message flow associated with the log and therefore can output the original results. Figure D.1. C2SIM Top-Level Architecture Copyright 2018 SISO. All rights reserved Page 46 of 50

47 APPENDIX E Generating XML schema using Sparx Enterprise Architect (Informative) The following steps can be followed in Sparx Enterprise Architect (v 12.1) to generate XML schemata from the C2SIM Logical Data Model. Step 1: Right click the C2SIM LDM in the Package Explorer window. Select Code Engineering and then click Generate XML schema as shown in the Figure E.1. Figure E. 1. Generating XML schemata from C2SIM LDM-1 (Screenshot from Sparx Enterprise Architect v 12.1) Copyright 2018 SISO. All rights reserved Page 47 of 50

48 Step 2: Provide a filename for the XML schema and click OK as shown in Figure E.2 Figure E. 2. Generating XML schemata from C2SIM LDM-2 (Screenshot from Sparx Enterprise Architect v 12.1) Copyright 2018 SISO. All rights reserved Page 48 of 50