JC3IEDM

JC3IEDM, or Joint Consultation, Command and Control Information Exchange Data Model is a model that, when implemented, aims to enable the interoperability of systems and projects required to share Command and Control (C2) information. JC3IEDM is an evolution of the C2IEDM standard that includes joint operational concepts, just as the Land Command and Control Information Exchange Data Model (LC2IEDM) was extended to become C2IEDM. The program is managed by the Multilateral Interoperability Programme (MIP).

The Joint C3 Information Exchange Data Model

JC3IEDM is produced by the MIP-NATO Management Board (MNMB) and ratified under NATO STANAG 5525. JC3IEDM a fully documented standard for an information exchange data model for the sharing of C2 information.

The overall aim of JC3IEDM is to enable "international interoperability of C2 information systems at all levels from corps to battalion (or lowest appropriate level) in order to support multinational (including NATO), combined and joint operations and the advancement of digitisation in the international arena."

According to JC3IEDM's documentation, this aim is attempted to be achieved by "specifying the minimum set of data that needs to be exchanged in coalition or multinational operations. Each nation, agency or community of interest is free to expand its own data dictionary to accommodate its additional information exchange requirements with the understanding that the added specifications will be valid only for the participating nation, agency or community of interest. Any addition that is deemed to be of general interest may be submitted as a change proposal within the configuration control process to be considered for inclusion in the next version of the specification."

"JC3IEDM is intended to represent the core of the data identified for exchange across multiple functional areas and multiple views of the requirements. Toward that end, it lays down a common approach to describing the information to be exchanged in a command and control (C2) environment.

1. The structure should be sufficiently generic to accommodate joint, land, sea, and air environmental concerns.
2. The data model describes all objects of interest in the sphere of operations, e.g., organizations, persons, equipment, facilities, geographic features, weather phenomena, and military control measures such as boundaries.
3. Objects of interest may be generic in terms of a class or a type and specific in terms of an individually identified item. All object items must be classified as being of some type (e.g. a specific tank that is identified by serial number WS62105B is an item of type "Challenger" that is a heavy UK main battle tank).
4. An object must have the capability to perform a function or to achieve an end. Thus, a description of capability is needed to give meaning to the value of objects in the sphere of operations.
5. It should be possible to assign a location to any item in the sphere of operations. In addition, various geometric shapes need to be represented in order to allow commanders to plan, direct, and monitor operations. Examples include boundaries, corridors, restricted areas, minefields, and any other control measures needed by commanders and their staffs.
6. Several aspects of status of items need to be maintained.
7. The model must permit a description of the composition of a type object in terms of other type objects. Such concepts include tables of organizations, equipment, or personnel.
8. The model must reflect information about what is held, owned or possessed in terms of types by a specific object item.
9. There is a need to record relationships between pairs of items. Key among these is the specification of unit task organizations and orders of battle.
10. The model must support the specification of current, past, and future role of objects as part of plans, orders, and events.
11. The same data structure should be used to record information for all objects, regardless of their hostility status.
12. Provision must be made for the identification of sources of information, the effective and reporting times, and an indication of the validity of the data."

JC3IEDM development history and current maturity

JC3IEDM has been developed from the initial Generic Hub (GH) Data Model, which changed its name to Land C2 Information Exchange Data Model (LC2IEDM) in 1999. Development of the model continued in a Joint context and in November 2003 the C2 Information Exchange Data Model (C2IEDM) Edition 6.1 was released. Additional development to this model, incorporating the NATO Corporate Reference model, resulted in the model changing its name again to JC3IEDM with JC3IEDM Ed 0.5 being issued in December 2004.

Subsequent releases have seen areas of the model developed in greater depth than others and there is variation in the number of sub-types and attributes for each type in the current version. An example is HARBOUR within the FACILITY type which has 43 attributes compared to a VESSEL-TYPE with 12 attributes or a WEAPON-TYPE with 4 attributes. The associated attributes of a certain type also lack support for exploiting with those of other types. For example, VESSEL-TYPE does not support the length or width of a vessel in its attributes but HARBOUR has both maximum vessel length and width attributes.

National policies related to JC3IEDM

The UK Ministry of Defence has mandated JC3IEDM as the C2 Information Exchange Model, in Joint Service Publication (JSP) 602:1007, for use on all systems and/or projects exchanging C2 information within and interoperating with the Land Environment at a Strategic and Operational Level. It is strongly recommended for other environments and mandated for all environments at the Tactical level. JSP 602:1005 for Collaborative Services has also mandated JC3IEDM in the tactical domain for all systems/projects providing data sharing collaborative services.

References

Note: Link for Ref 3 is broken. Link for Ref 5 is wrong. As of 05.05.2017 all MIP links are broken and point to different directions.

External links

• MIP site
• Files comprising the JC3IEDM specification