CITT

COALITION BATTLE MANAGEMENT LANGUAGE INDUSTRY TASK TEAM

MEETING RECORD SHEET MINUTES
Date: / 20-Jun-2012
21-Jun-2012 / Start Time: / 9:30 EDT / End Time: / 17:00 EDT / Date Distributed: / 03-July-2012
Title of Meeting: / June 20-21th CITT Paris Workshop
Location: / MBDA
Le Plessis Robinson, France / Meeting Chair(s):
Kevin Heffner, Pegasus Research & Technologies
Present: / Workshop (21-June-2012):
Christophe BOUGERET (Thales)
Kevin HEFFNER (Pegasus)
Kevin GUPTON (University of Texas)
Thomas ROUILLARD (MBDA)
Laurent PRIGNAC (MBDA)
Régis MAUGET (CapGemini)
Elena BRAVO (ISDEFE)
Meeting (22-June-2012):
Gyslain HERVIEUX (ONERA)
Hervé ROCHARD (Thales)
Christophe BOUGERET (Thales)
Dan GREGORY (Thales)
Benoit ROLLAND (Presagis)
Jose-Maria LOPEZ-RODRIGUEZ (NADS)
Kevin HEFFNER (Pegasus)
Kevin GUPTON (University of Texas)
Thomas ROUILLARD (MBDA)
Laurent PRIGNAC (MBDA)
Bernard LANGLAIS (Antycip Simulation)
David KAMP (Antycip Simulation)
Régis MAUGET (CapGemini)
Elena BRAVO (ISDEFE)
Patricio JIMENEZ (ISDEFE)
Next Meeting: / TBD / Prepared by:ElenaBravo (ISDEFE) July 1st 2012
Revised by: Kevin Heffner (PEGASUS) July 3rd 2012
Revised by: Laurent Prignac (MBDA) July 4th 2012
Item / Description / Resp.
EVE-01 / 21-June-2012
Welcome and Introduction
Kevin H. explains that C-BML is not a standard yet due in part to debates between various academic stakeholders and lack of industry involvement. The university community has provided a solid foundation for C-BML by producing the Phase 1 specification. The purpose of the CITT is to get industry involved in the development and to increase industry awareness about C-BML for Phase 2.
Kevin H. informs that during the recent June 2012 MSG-085 a proposal was made to merge phases 2 and 3 of C-BML standard development within the SISO C-BML PDG. Kevin G noted that this proposal has yet to be made officially to the PDG.
Review of the agenda for the presentation to ADIS Group on 22-June (See Annex 1)
Kevin H., Kevin G. and Laurent P. review the proposed agenda for the presentation to ADIS Group on June 22th, which is set as follows:
09:20 Introduction to CITT (Kevin H.)
09:30 Introduction to C-BML Standard (Kevin G.)
  • MSDL/CBML Alignment (Kevin H.)
10:00 CBML Standard Roadmap (Kevin H.)
11:15 Phase 2 Approach
  • Standard Development Framework (Kevin H.)
  • Ontology (Kevin G.)
  • Transport (Laurent P.)
11:45 Prototype Demonstration (Laurent P.)
EVE-02 / Presentation of C-BML Standard Development Framework (see attached Annex 2)
Kevin H. and Kevin G. make a presentation of the C-BML Standard Development Framework from NATO MSG-085 where the following information is highlighted:
  • Requirements: are not part of the Standard but likely will be provided as an Annex; they would not be normative, but informative.
  • Over the coming months 5 use cases from various domaines are expected to be developed as inputs into the requirements.
  • Reference Architecture:
  • Interaction Protocols: the intention for the standard is not to produce a set of standardized protocols (e.g. Call For Fire) but rather to produce a template and standard means to specify Interaction Protocols that will allow each Organization to define their own protocols in an standard way.
  • Service Components: the initial 6 services defined in this slide are the outcome of brainstorming by Kevin H. and Kevin G. Comments are accepted to incorporate new services to this set or eliminate services that may not be necessary. These services could be able to be implemented using any language/protocol: HLA, Java, WSDL, RESTful Style services …
  • Normative Specifications: Kevin H. explains that current protypical BML expressions (e.g. orders) that have been used in early experimentation up to now have primarily low-level, simple orders and reports. However, future BML information exchange will be require more complete higher-level information that is consistent with more detailled information sets and also with automatic processing by intelligent software agents. This drives the need for a “grammar” and “message structure”.Although it is possible that many simulators may not require these types of requirements for some time to come,other existing COTS simulators already possess such agent-based capabilities.

EVE-03 / “Call For Fire” use-case review
Kevin H. explains that he would like to develop a use-case in detail so that it can be used as a model/example/template for each Organization to develop their own use-cases based on a common reference (actors, assumptions/design considerations, pre-conditions, normal sequence for the mission execution, …). The use case of Call For Fire (CFF) has been selected for this purpose.
As a starting point, the proposal of information flow for CFF developed in a previous meeting is used.
Kevin G. collects the requirement needs.
Christophe B. asks about use-case validation: has legal framework being used by the CITT (NCOIC and SISO) does not allow for any software development. However, individual companies are encouraged to co-develop and share preliminary Phase 2 software with each other and other members of the CITT to support early validation of phase 2 products.
  • Laurent P. tells that it will be very difficult to share to the CITT group any software developed by MBDA as they do not have authorization neither from MBDA nor from the Government.
  • Kevin H. explains that software development is outside the CITT. The CITT is using NCOIC and SISO legal frameworks which do not allow for software development. Therefore, Kevin H. suggests that –under this framework- it may be able to make some sort of common development by CITT-member companies aside from CITT.
  • MBDA proposes that each company implements their own developments to validate use-cases and expose to CITT the results of these validations: individual validation. Sharing results and not developments arise less legal issues. All attendees accept this option.
  • Kevin H. suggests that companies may be able to participate in the experimentation of MSG-085 if invited to do so by their national representatives to the MSG-085 Technical Activity and this could be another opportunity to share implementations between companies.
  • Christopher B. asks whether use-cases developed in CITT will be validated by Operational Military Personnel. Kevin H. answers they will be.
  • Kevin H. explains that Military Personnel are involved in the definition of the “Operational Activity” of the Requirements of the C-BML SDF, as defined by the Technical Sub Group of MSG-085. They are not involved in the definition of the Information Exchange Requirements and Information Requirements, as they are technical issues.
  • Laurent P. asks about the confidentiality of the contents of the use-case developed by CITT.Since the CFF use-case developed represents a real doctrine classified by a specific country, that information can not go to SISO. Kevin H notes that the level of detail required to create a useful generic CFF example use-case does not require the use of classified documents, but will require some work.
  • Kevin G. suggests using the public documents as sources for CFF description, as available in the USA to develop a sufficiently detailed CFF use-case that can be used as a detailed template so that other members can develop their own classified use-cases.
  • APP11C specifies the following CFF-related Messages: Fire Mission CFF (FMCFF), Fire Mission Command, Fire Mission Subsequent Adjustment, Fire Mission to Missions Observer.
NOTE: CITT is not able to share APP11C message, but is able to share the requirements derived from this messages.
EVE-04 / HLA C-BML Communication
  • Kevin H. asks Regis M. about CapGemini’s intention of linking C2 systems and simulation via HLA through a C-BML FOM. Regis M. explains their proposal (which is similar to the one under development in MSG-106).
  • Kevin H. indicates that he is not in favour of using HLA to link systems outside the federation. However, he suggests that maybe the Web Services exposed in HLA Evoled could be used to support HLA-based C-BML communication.
  • Regis M indicated that the services defined for HLA-Evolved were limited to a set of six services that probably would not support a customized web-service approach to C-BML communication using HLA.
  • Regis M mentioned that there are other approaches that could be evolved to develop an HLA-based C-BML communication and that would not necessarily involve the definition of a detailed FOM, but that could provide a FOM for the message structure, but not for the content. This could be supported by using an initial version of the set of C-BML core services.
  • ACTION 01: CapGemini to start the definition of the Core C-BML Services
  • ACTION 02: CapGemini to send to the CITT members a written explanation of their proposal HLA-C-BML.

  • Kevin H. gives a general overview of MIP Information Model (MIM). The MIM has a large potential for re-use in order to define whole branches of the C-BML content model (e.g. Location, TaskOrganisation, Material/Equipment, Features, etc…) as well as providing inputs into the definition of metadata to be used for defining the Message Structure.This model has been released in May 2012 and will replace the JC3IEDM.
  • Defining the Message Structure and metadata is a high priority task and a first draft needs to be done soon. Cassidian already has provided an initial draft C-BML message metadata schema and has made this available to SISO. This could be used as the basis but needs to be complemented with other data. MBDA has contributed an initial set of requirements for the C-BML Message Metadata.
  • In addition to the C-BML Message Metadata, the Reference Architecture specifies domain independent, transport-specific metadata refered to as “Transport-Message Metadata”. This metadata allows an implementer to vehicle a C-BML expressionusing one of many possible transport protocols or information exchange mechanisms.
  • Defining the Message-Metadata and the Transport-Message Metadata are high priorities for the CITT since they need to be done before any further applied work can be done (e.g. prototype messaging infrastructures).

  • Laurent P. expressed concern about the changes that there may be from C-BML phase 1 to phase 2 and their impact in the implementations made by companies under CBML phase 1.
  • Kevin G. indicates that C-BML phase 1 is open and not much defined and that C-BML phase 2 will specify more all aspects of the standard. Therefore, Kevin G. does not consider that there will be substantial changes from phase 1 to phase 2.
  • Kevin G. also suggests companies to participate actively in the definition of phase 2, so that their implementations can be part of what is standardized.
  • Kevin H. indicated that phase 1 compatibility and migration from phase 1 to phase 2 are part of the Phase 2 program of work and that the phase 1 model may be re-organized slightly in phase 2, but that it will remain essentially intact.

EVE-05 /
  • Call for Fire:
  • Starting from the CFF use-case proposal the attendees note that it may be interesting not only to show the Forward Observer and the FDC in the diagram, but also a third participant: the Fire Unit.
  • The group starts discussions about how to improve the existing diagram. Kevin G. keeps a written copy of the revised diagram.
  • An example of Call for Fire Protocol is found in Wikipedia ( and may be used to redefine the use-case.
  • The group agrees that it will not be necessary to define a real CFF procedure (which would require the direct participation of and Operations Military) but to define an approximation to CFF.
  • NOTE FROM Kevin H.: Andy Bowers (MITRE) is part of the CITT and is a retire US Army officer. Andy has agreed to help develop and review the CFF use-case. Andy also is participating in MSG-106.

EVE-06 / Demonstration of a CBML Server Prototype by MBDA
EVE-07 / 22-June-2012CITT Industry Seminar (Morning)
(See presentations)
Welcome and Introduction
Introduction to C-BML
C-BML Standard RoadMap
Status of Phase 1
Phase 2 Approach
Prototype Demonstration
EVE-08 / 22-June-2012 CITT Workshop (Afternoon)
Kevin H recalled that it is important to move forward on the definitions for the C-BML Message Metadata and the Transport Message Metadata.
  • ACTION 03: Elena B. to evaluate whether the SP Army Simulation Office can work on the definition of the C-BML message metadata and report back (PENDING CONFIRMATION)
  • ACTION 04 (reviewed): CapGemini will define the transport metadata (PENDING CONFIRMATION)
  • Kevin H. indicates that Emiraje Systems has volunteered to work on the Services.
  • Laurent P. asks whether there are clear requirements for transport messages. Kevin H. references the following document to the group: “Common Messaging Strategy & Procedure”. Although this document is not intended specifically for C-BML, requirements can be extracted from it for the transport metadata and message metadata.Also, Kevin H indicates that some of the reference architecture was inspired by the Foundation for Intellighent Physical Agents (FIPA) standard that defines transport-message metadata.
  • Suggestion from Kevin H.: Ideally, all companies could work on a common messaging infrastructure, but as already pointed out, this may not be feasible for various reasons. However, if an individual or small group develops a solution, then resulting software may or may not be shared with the rest of the CITT group, as this may not be possible and also it may not be fair. However, the group may share some services over an available server on the internet without sharing all source-code and each company could access these services with their own proprietary implementations. The proposal is accepted.
  • Kevin H. says that, in general, he considers that it is difficult for some CITT members to get involved and commited to C-BML. All members agree that in order that companies get commited in C-BML, it would be interesting that somebody would develop an open-source server so that companies see something working and have the ability to experiment with it.
  • ACTION 05: Patricio J. volunteers to develop a small open-source server using available open-source technologies such as Amazon web-services. Kevin H. says this solution would be perfect. He notes however that he is reluctant to share the source code with all companies, as some of them are not interested in contributing actively but only in participating as observers.
  • Laurent P. says that, while he considers this open-source server very interesting, MBDA can not connect their developments to internet, and so they could not access this server.
  • Laurent P. also says that the legal framework for this collaboration must be defined, as French companies must have permission not only from their Management but from the Government to share defence source code to other companies/organisms.
  • ACTION 06: Laurent P. to talk to DGA (Lionel Khimeche) to study the possibility of sharing software though NATO.
  • In spite of all concerns, the group agrees that there's a need for an implementation so that we can communicate what C-BML Phase 2 standard so that people can try it out and test it. The best way to do it is to have an open source implementation.
  • ACTION 07: Laurent P is also to find out how can MBDA collaborate in this open source solution and will report back.
  • Patricio J. suggests to make the implementation under a European Framework (EDA, EUREKA, UE, …) in which Pegasus and the University of Texas may also participate through outsourcing.
  • ACTION 08: Patricio J. to look up for more information about European Frameworks.
  • José Mª suggest the DNBL initiative (Distributed Network Battle lab) of which MBDA is already a member. Laurent P. indicated that an experimentation to test CBML within DNBL can be proposed; all participants must be DNBL members, and all sites must be connected to the CFBLNet network.

EVE-09 / Implementation Candidate Technologies
  • Kevin G. points out that during the last MSG-085 meeting he has noticed that Lionel K. (DGA France) wants to know where the community is as far as the implementation architectures because there are so many different technologies: HLA, publish-subscribe, DIS, … , and they are all potentially valid.
  • ACTION 09: Kevin H. and Kevin G. to check whether the document MSG-085 “C-BML Services Specification” can be shared.
  • There are two questions that have arisen from this meeting and are pending answer:
  • What has the implementation to do in terms of functionality?
  • What has the implementation to provide in terms of services?
  • Laurent P. indicates that the aim of the implementation is to promote C-BML, not to investigate different implementation solutions.

EVE-10 / Meeting adjourned.

CITT Paris Workshop1/1020-21-June-2012

SISO COALITION BATTLE MANAGEMENT DRAFTING GROUP – PHASE 2

ANNEX A – OPENACTION ITEM TABLE (ordered by Action Item number)

ACTION ITEM TABLE
AI ID / Description / Assignee / Due date / Status
AI-M01-01 / Participants to look through slides and identify which specific parts they wish to be contribute. / ALL / 11-Jun-2012 / Open
AI-M01-02 / Participants from non-NCOIC member companies to contact K.Heffner and D.Gregory before next meeting so that they can be given one of the NCOIC-SISO reciprocal memberships. / ALL / 11-Jun-2012 / Open
AI-M03-01 / CapGemini to start the definition of the Core C-BML Services / RM
AI-M03-02 / CapGemini to send to the CITT members a written explanation of their proposal HLA-C-BML. / RM
AI-M03-03 / EB to elaborate a draft C-BML message metadata definition based on available documents. / EB
AI-M03-04 / Provide an initial definition of theC-BMLTransport MessageMetadata. / RM
AI-M03-05 / Patricio J. volunteers to develop a small open-source server using available open-source technologies such as Amazon web-services / PJ
AI-M03-06 / Laurent P. to confirm with DGA (Lionel Khimeche) the possibility of sharing software though NATO. / LP
AI-M03-07 / Laurent Pis also ground to try to find out how can MBDA collaborate in this open source solution and will report back. / LP
AI-M03-08 / Patricio J. to look up for more information about European Frameworks. / PJ
AI-M03-09 / Kevin H. and Kevin G. to check whether the document “C-BML Services Specification” can be shared. / KG, KH

ANNEX B – CLOSED ACTION ITEM TABLE (ordered by Action Item number)

ACTION ITEM TABLE
AI ID / Description / Assignee / Closed date / Status

*Items include: AI ## = records Action Items (Note: a unique number ## is assigned to each Action Item. Als are tracked to closure);

OBS = records OBServations; EVE = records EVEnts (Such as handovers of documents, products, tools, etc.)

Revision 0 / CITT20-21 June 2012 Paris Workshop Meeting Minutes / Page 1/10