Dear all, 


I'm in favor of separating the concerns (and messages), within different extensions. 

The extension mechanism is meant for that :) 

My preference would be to create a new extension. 

I agree with you Mark that it would lead to additional work for the balloting process, and that's not good. 

But on the other hand, I'm wondering if we need to standardize this extension now (with maybe some elements that can be specific to a C2SIM server)

Maybe not. 

My opinion is that we could keep in the core only a minimal set of "initialization" messages, and take the time to : 

- think about the other initialization messages, 

- and maybe also think to other use-cases, such as simulation for planning / decision support, autonomous vehicle (what does a Start_Scenario meant for it?), etc. 

For the core, I think that the main message that is relevant is C2SIMInitializationBody. 

But maybe it's too restrictive... 

Please let me know what you think 

Kind regards 


De : SAC-PDG-PSG-C2SIM <[log in to unmask]> de la part de Douglas Reece <[log in to unmask]>
Envoyé : mercredi 9 octobre 2019 22:10
À : [log in to unmask]
Objet : Re: C2SIM pre-balloting issue:system commands in a separate C2SIM extension
Some additional information.
The Standard document says this about synchronization:

C. Coalition System-of-Systems Synchronization
The following messages, with formats defined in the C2SIM Core Ontology, are used to synchronize
simulation across the C2SIM coalition. Some of these can only be sent by a designated coalition controller:
a. Submit_Inititalization: Sent by a C2SIM controller. When C2SIM systems receive this
C2SIM_Message, they should submit Object_Initialization messages for object definitions they are
configured to simulate. This message contains no data; it serves as a command and is not required if
a preconfigured master initialization file is used.
b. Object_Initialization: Sent by each C2 and simulation to a marshalling server on receipt of a
Submit_Inititalization C2SIM_Message. This message is not required if a preconfigured master
initialization file is used.
c. Share_Scenario: Set by a C2SIM controller to a marshalling server. When this C2SIM_Message is
received, the marshalling server sends to all subscribed systems the C2SIM_Initialization message.
d. C2SIM_Initialization: This C2SIM message aggregates initialization data for all systems, as described
in section 7.1. The source of this information could either be an preconfigured C2SIM_Initialization or
a composite, produced by the marshalling server, of the initialization data in all received
Object_Initialization messages.
e. Initialization_Complete: This C2SIM_Message is sent by each participating C2 and simulation system
in response the the C2SIM_Initialization message, after that system has completed its initialization
f. Start_Scenario: This C2SIM_Message is sent to all subscribed systems indicating that the simulation
scenario is to begin.
g. Query_Unit/Query_Init: Sent by a later joiner to get current status (Query_Unit) or initial status
(Query_Init) – this C2SIM_Message is optional for server implementation.

The current ontology supports all of these commands except for the optional g, as shown below (note the MessageBody classes and the SystemCommandTypeCodes for the SystemCommandBody):

The additional commands Marks mentions are PauseScenario, ResetScenario, and EditScenario (probably OBE). In addition there could be the QueryUnit and QueryInit messages and a SimulationNotification message. Also possibly a new property in the C2SIM header hasExtensionName that could be used for filtering messages by extension. 
And anything else that is specific to a particular server or coalition implementation.

Doug Reece

On Tue, Oct 8, 2019 at 11:26 PM Mark Pullen <[log in to unmask]> wrote:
A C2SIM Coalition (system of C2 and simulation systems) requires synchronization. In existing prototype coalitions, this has been accomplished by system command messages, for example INITIALIZE and START. It has been proposed to include the most basic commands in the C2SIM Core Ontology but also to create a new, small C2SIM extension for those system commands that might not be needed in all Coalitions.  An alternate viewpoint is that these commands should be included in the Standard Military Extension (SMX) rather than going to the trouble of creating a new extension that will need to be shepherded through the balloting process. If you have a comment in favor of one side of this or the other, please respond to this email with your viewpoint.



To unsubscribe from the SAC-PDG-PSG-C2SIM list, click the following link:


Dr. Douglas Reece |  Principal Engineer
VT MÄK  | 150 Cambridge Park Drive, Third Floor, Cambridge, MA 02140
T: +1.857.209.3483  | 
[log in to unmask]  |


To unsubscribe from the SAC-PDG-PSG-C2SIM list, click the following link:

The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.

To unsubscribe from the SAC-PDG-PSG-C2SIM list, click the following link: