MULTILATERAL INTEROPERABILITY PROGRAMME Document Library/99...1.3 History The Multilateral Interoperability Programme was established by the Project Managers of the Army Command and

MIP GLOS – ITA – CCWG Edition 2.4

MULTILATERAL INTEROPERABILITY PROGRAMME

MIP GLOSSARY (MIP GLOS)

26 May 2006, Greding Germany

This Multilateral Interoperability Programme (MIP) Glossary has been reviewed and is

hereby “Approved” by the Heads of Delegation of participating nations. Release of this

document to nations or agencies, who are not participants in the Multilateral Interoperability

Programme including the media and general public, requires approval of the MIP Steering

Group (MSG) in accordance with the policy stated in the MIP Communications and Liaison

Plan (MCLiP). This document is the property of the MIP Participants and the information

contained in this document shall not be communicated, either directly or indirectly, to any

person or agency not authorised to receive it.

MIP GLOS – ITA – CCWG 26 MAY 2006

Edition 2.4

i

RECORD OF CHANGES PAGE

___________________________________________________________________________

CP NUMBER DATE ENTERED ENTERED BY REMARKS

___________________________________________________________________________

001 30 September 2005 CCWG New Edition 2.2

002 9 December 2005 CCWG New Edition 2.3

003 23 May 2005 CCWG New Edition 2.4




Edition 2.4

ii

TABLE OF CONTENTS

___________________________________________________________________________

SECTION TITLE PAGE

___________________________________________________________________________

1 INTRODUCTION .................................................................................................................................. 1

1.1 Multilateral Interoperability Programme (MIP) .............................................................................. 1

1.2 The MIP Concept ............................................................................................................................ 2

1.3 History............................................................................................................................................. 4

1.4 MIP Organisation ............................................................................................................................ 4

1.5 Implementation, Adoption and Stability ......................................................................................... 5

1.6 Purpose............................................................................................................................................ 6

1.7 Scope............................................................................................................................................... 6

ANNEX A GLOSSARY ................................................................................................................................. A-1

ANNEX B DEFINITIONS............................................................................................................................. B-1

ANNEX C REFERENCES ............................................................................................................................ C-1


Edition 2.4

1

MIP GLOSSARY

1 INTRODUCTION

The application of military force in the early 21st century is demanding. It covers a wide

spectrum of threats and deployment scenarios that range from conventional general war

through limited operations, crises response operations, asymmetric conflict, and terrorism.

Unilateral capability is important to nations but most planning is made on the assumption of

alliance and coalition operations in scenarios that are difficult to predict and which often arise

at short notice. Thus the nature and composition of a force structure to meet military

requirements will be specific to requirement and based upon a general and flexible military

capability.

To achieve this, an assured capability for interoperability of information is essential. The

successful execution of fast moving operations needs an accelerated decision-action cycle,

increased tempo of operations, and the ability to conduct operations within

combined/multinational formations. Commanders require timely and accurate information.

Also, supporting command and control (C2) systems need to pass information within and

across national and language boundaries. Moreover, tactical C2 information must be provided

to the operational and strategic levels of command including other governmental departments.

Additionally, forces must interact with non-governmental organisations, including

international aid organisations.

The Multilateral Interoperability Programme (MIP) aims to deliver an assured capability for

interoperability of information to support land focused joint operations.

1.1 Multilateral Interoperability Programme (MIP)

The aim of the Multilateral Interoperability Programme (MIP) is to achieve international

interoperability of Command and Control Information Systems (C2IS) at all levels from corps

to battalion or the lowest appropriate level, in order to support combined and joint operations;

and pursue the advancement of digitization in the international arena, including NATO.


Edition 2.4

2

The means to achieve this will be known as the MIP solution. This will take into account

issues regarding the establishment of communication and information systems connectivity,

and the establishment of a C2IS interface that fulfils common information exchange

requirements.

The Programme has gone through the stages of: operational analysis, concept, feasibility,

definition, development and demonstration. The present focus is on implementation and the

programme has adopted a controlled iterative cycle to support incremental development.

The information exchange requirements, upon which MIP is founded, encompass the

spectrum of Joint and Combined Land Operations. Thus MIP meets the requirements of the

Land Component Commander of Allied Joint and Combined Operations (including Article 5

and Crisis Response Operations). Systems may be wholly different from each other and need

not necessarily conform to any hardware or software standard. Typically systems will be

acquired through national or NATO acquisition programmes and their architecture will

conform to the national or NATO policy prevailing at the time.

In a community of MIP-enabled C2 systems nations, command levels and organisations can

share:

• Situational awareness (including, inter-alia, capabilities and status of friendly and enemy

forces).

• Plans and Orders.

• NBC alerts and critical messages.

1.2 The MIP Concept

The MIP specification consists of common interface and exchange mechanisms (two at

present) to exchange information between co-operating but diverse C2 systems.

The common interface is the Land C2 Information Exchange Data Model, LC2IEDM. It is a

product of the analysis of a wide spectrum of allied information exchange requirements. It

models the information that allied land component commanders need to exchange (both

vertically and horizontally). It serves as the common interface specification for the exchange


Edition 2.4

3

of essential battle-space information. The function, implementation and the display of the host

C2 application is not the concern of MIP.

System developers incorporate the MIP specification and include a single interface to it. The

specification enables C2IS to C2IS information exchange and allows users to decide what

information is exchanged, to whom it flows, when and over what communications medium.

Thereafter no further interfaces are required to interoperate with any other MIP enabled

system.

The Message Exchange Mechanism (MEM) consists of a suite of formatted messages derived

from the LC2IEDM that conform to AdatP-3 Part 1, plus guidelines for their use.

The Data Exchange Mechanism (DEM) is an automatic data push mechanism that co-exists

with the MEM. When a C2 application changes the state of information that it holds, and

which is recognised by the DEM, this information is automatically replicated to all other co-

operating systems that have agreed to exchange this information.

With both exchange mechanisms the meaning and context of the information is preserved and

requires no additional processing on receipt to make it useful. The MIP specifications enable

interoperability at Degree 4.a1 (DEM) and 2.h2 (MEM) and functions at NATO Level 5 of

System Interconnection3.

The programme is tightly focused on delivering capability in an incremental manner based

upon a rolling 2-year delivery cycle, while in parallel the previous baselines are sustained,

new operational requirements are analysed, new capabilities are agreed, and emerging

technologies are explored. Nations are encouraged to align their acquisition cycles. The MEM

1 The NATO Policy for C3 Interoperability [NC3B Sub-Committee AC/322 SC/2-WP/72 (Revised) Version 4.3]:

“Seamless Sharing of Information: Common Information Exchange.”

2 The NATO Policy for C3 Interoperability [NC3B Sub-Committee AC/322 SC/2-WP/72 (Revised) Version 4.3]: “Structured Data Exchange: Data Object Exchange”

3 STANAG 5048 - The Minimum Scale of Connectivity for Communications and Information Systems for NATO Land Forces (Edition 5. Promulgated 16 February 2000 by NC3B Sub-Committee AC/322 SC/1). “Two systems which are open to each other, and which conform to minimum standards for information definition and transfer such that there are no fixed constraints on the extent of access by users of one system to the other, but dynamic constraints are applied to each system, in accordance with the current operational situation, such that only a user-defined subset of the total information base of one system is available to the other.”


Edition 2.4

4

and the DEM will be in-service during the period 2003 – 2005 and followed thereafter with

biennial capability enhancements.

1.3 History

The Multilateral Interoperability Programme was established by the Project Managers of the

Army Command and Control Information Systems (C2IS) of Canada, France, Germany, Italy,

the United Kingdom and the United States of America in April 1998 in Calgary, Canada. MIP

replaced and enhanced two previous programmes: BIP (Battlefield Interoperability

Programme) and QIP (Quadrilateral Interoperability Programme). The aim of these

programmes was similar to the present MIP but each was active at a different level of

command.

In 2002 the Army Tactical Command and Control System (ATCCIS) programme merged

with MIP. ATCCIS was founded in 1980 to see if interoperability could be obtained at

reduced cost and developed according to technical standards agreed by Nations and

prescribed by NATO. The programme sought to identify the minimum set of specifications, to

be included within national C2 systems that would allow interoperability between them. With

the publication of ATCCIS Baseline 2 the programme’s mandate was complete. By 2002 the

activities of ATCCIS and MIP were very close, expertise was shared, and specifications and

technology was almost common. The merger of ATCCIS and MIP was a natural and positive

step and this was recognised by the almost immediate publication of a NATO policy that

endorses MIP4.

1.4 MIP Organisation

The MIP programme is not a formal NATO programme. Rather it is a voluntary and

independent activity by the participating nations and organizations. The nations and HQs that

are active in the MIP programme are: Australia, Austria, Belgium, Canada, Czech Republic,

Denmark, France, Germany, Greece, Hungary, Italy, Lithuania, Netherlands, Norway, Poland,

Portugal, Spain, Sweden, Turkey, United Kingdom, United States, Regional Headquarters

4 NATO Policy on the Multilateral Interoperability Programme [NC3B AC/322-WP/0238]


Edition 2.4

5

Allied Forces North Europe (RHQ AFNORTH) and Supreme Headquarters Allied Powers

Europe (SHAPE).

MIP is organised into 6 working groups with an executive management body and a high level

steering group for resources, policy and targets. Rigour is maintained by the adoption of

recognised system engineering practices. In addition to the interface specification and the

exchange mechanisms, MIP also produces supporting products covering programme

management, security policy, test schedules, configuration management, representative data

fills, and international liaison.

1.5 Implementation, Adoption and Stability

The MIP is involved in the following activities and standards:

• The LC2IEDM, is the core of the NATO Reference Model and is also a view model of

NATO Corporate Data Model (STANAG 5523 / AdatP-32).

• Implementation of the MIP specification is a NATO Force Goal (FG2802).

• NATO Policy on MIP calls for close co-ordination and re-use of the MIP specification

within NATO.

• Bi-SC Automated Information System will use the MIP solution in its Land Functional

Services (LandFS) to interface to national CCIS, either in HRF/LRF, CJTF or other crisis

response operation or exercise5.

• NATO Standardisation Agreement SO 01-11 calls for the implementation of MIP

specifications.

5 Bi-SC transition Management Board Report to Bi-SC CIS Board, on 25th September, 2002

OperationalWorking Group

(OWG)

Systems Engineering& ArchitectureWorking Group

(SEAWG)

Data and ProceduralWorking Group

(DPWG)

TechnicalWorking Group

(TWG)

ExerciseDemonstrationWorking Group

(EDWG)

ConfigurationControl

Working Group(CCWG)

ProgrammeManagement Group

(PMG)

MIP SteeringGroup(MSG)


Edition 2.4

6

• The MIP specification is well regarded in the NC3A. It is the core capability of the NC3A

Integrated Data Environment prototype, a capability to integrate legacy systems.

• The MIP specification is included in the NATO C3 Technical Architecture.

• The NATO Military Criteria for High Readiness Forces (Land) Headquarters requires the

use of an ATCCIS6 compliant land information system.

• Many national C2 information systems implement MIP specifications.

1.6 Purpose

This document shall explain all the abbreviations and define important terms used within the

MIP documents.

1.7 Scope

The glossaries of the following baseline and supporting documents are consolidated in this

MIP Glossary.

MIP Programme Management Plan MPMP-NLD-PMG

MIP Configuration Management Plan MCMP-ITA-CCWG

MIP Communications and Liaison Plan MCLiP-ACT-PMG

MIP Tactical C2IS Interoperability

Requirement

MTIR-FRA-OWG

6 MIP is the custodian of the ATCCIS specifications.


Edition 2.4

7

MIP Operating Procedures MOP-GBR-SEAWG

MIP Technical Interface Design Plan MTIDP-DNK-SEAWG

MIP System Interconnection Security Policy MSISP-USA-SEAWG

MIP Test and Evaluation Master Plan MTEMP-USA-TEWG

MIP Block 2 Plan MBP-USA-SEAWG

MIP Integrated Framework MIF-CAN-SEAWG

MIP Operational Level Test Specification MOLT-FRA-OWG

MIP System Requirements Specification MSRS-NLD-SEAWG

MIP System Level Test Plan MSLTP-USA-TEWG

MIP End of Block 2 Report MEB2R-NLD-MSG

C2 Information Exchange Data Model C2IEDM-USA-DMWG


Edition 2.4

8

MIP Document Register MIP Doc Reg-ITA-CCWG

MIP Operational Handbook MOH-CAN-OWG

MIP Glossary MIP Gloss-ITA-CCWG

MIP Point of Contact List MIP PoC-NLD-CCWG

Configuration Management Status Report CMSR-ITA-CCWG

MIP Integrated Programme Schedule MIPS-ACT-PMG

MIP Boiler Plate Text MBPT-ACT-CCWG

MIP Statement of Intent MSOI-GBR-PMG

MIP Vision and Scope MVS-GBR-PMG


Edition 2.4

A-1

ANNEX A GLOSSARY

AAP Allied Administrative Publication

AAP–6 Allied Administrative Publication N° 6 — NATO Glossary of

Terms and Definitions

ABCA America Britain Canada Australia

ACE Allied Command Europe

ACK Acknowledgement

ACO Allied Command Operations

ACP Allied Communications Publication

ACS Automated Channel Selection

ACSE Association Control Service Element

ACT Allied Command Transformation

ADatP–3 Allied Data Publication N° 3 — NATO Message Text Formatting

System (FORMETS)

ADM ATCCIS Data Model

ADMD Administration Management Domain

AFS ADatP-3 Formatting Staff

AI Air Interdiction

AintP-3 Allied Intelligence Publication 3

AN Access Node

ANSI American National Standards Institute

AOI Area of Interest

AOR Area of Responsibility


Edition 2.4

A-2

APDU Application Protocol Data Unit

API Application Programming Interface

APP Allied Procedural Publication

APP-6A Allied Procedural Publication N° 6A - Military symbols for Land

Based Systems


Edition 2.4

A-3

APP-9 Allied Procedural Publication N° 9 (Compendium of Allied Forces

Messages)

APP-10 Allied Procedural Publication N° 10 (NATO Interoperability

Document)

ARM ATCCIS Replication Mechanism

ARP Address Resolution Protocol

ARRC ACE Rapid Reaction Corps

ASAP Application service access point

ASCA Artillery Systems Cooperation Activities

ASCII American Standard Code for Information Interchange

ASN.1 Abstract Syntax Notation 1

ASSOCMAN Association Manager

ATacCS Army Tactical Computer System

ATCCS Army Tactical Command and Control System (US)

ATCCIS Army Tactical Command and Control Information System

ATP-35(B) Allied Tactical Publication 35(B) (Land Forces Tactical Doctrine)

AUS Australia

AUT Austria

AUTOKO Automatisiertes Kommunikationsnetz

Bde Brigade

BEL Belgium

BG Battle Group (Equivalent to a US Battalion)

BGR Bulgaria

BICES Battlefield Intelligence Collection and Exploitation System


Edition 2.4

A-4

BIGSTAF Breitbandiges Integriertes Gefechtsstandfernmeldenetz

BIP Battlefield Interoperability Programme

BiSC Bi Strategic Commands (NATO)

BMHS BIP Message Handling System

BMS Battlefield Management System

Bn Battalion

BOA Basic Object Adaptor

BPD Boundary Protection Device

C2 Command & Control

C2IEDM Command and Control Information Exchange Data Model

C2IS Command, Control and Information System

C2S Command and Control System

C3 Command Control & Consultation

C4I DTF Object Management Group (OMG) C4I Domain Task Force

CAN Canada or Canadian

CAS Close Air Support

CCIR Commander's Critical Information Requirements

CCIS Command, Control and Information System

CCWG Configuration Control Working Group

CE Combined Endeavour

CEE Common Engineering Environment

CEOI Communication and Electronic Operating Instruction

CFCS Command and Fire Control System


Edition 2.4

A-5

CFE Conventional Forces Europe

CIS Communication Information Systems

CJTF Combined & Joint Task Force

CM Configuration Management

CMSR Configuration Management Status Report

CN Change Notice

CNR Combat Net Radio

COMMS Communications

COMSEC Communication Security

COP Common Operational Picture

CORBA Common Object Request Broker Architecture

CoStEx Command and Staff Exercise

COTS Commercial Off The Shelf

Coy Company

CP Change Proposal

CP Command Post

CPX Command Post Exercise

CRC Cyclic Redundancy Check

CRO Crisis Response Operations

CRLF Carriage Return Line Feed

CSMA/CD Carrier Sense Multiple Access / Collision Detection

CWID Coalition Warrior Interoperability Demonstration

CZE Czech Republic


Edition 2.4

A-6

DB Database

DBA ADatP-3 Data Base Administrator

DDL Database Definition Language

DEM Data Exchange Mechanism

DEU Germany or German

Div Division

DMWG Data Modelling Working Group

DNK Denmark

DP Data Provider

DR Data Receiver

DSN Delivery Status Notification

DSP Digital signal processor

DTG Day Time Group

ECCM Electronic Counter – Counter Measures

ECM Electronic Counter Measures

ED50 European Datum 50

E.G. Exempli Gratia – As Example

E-IARRCIS Enhanced Interim ARRC Information System

EID Experimental Interoperability Database

E-mail Electronic-mail

EMC Electro-Magnetic Compatibility

ENVID Envelope ID

EoS Element of Service


Edition 2.4

A-7

ER Entity Relationship

ERWIN CaseTool ER=entity-relationship WIN=Windows-based

ESMTP Extended Simple Mail Transfer Protocol

ESP Spain

EUROFOR European Force

EW Electronic Warfare

EXCON Exercise Control

FAFCISO Federal Armed Forces CIS Organization

FD Field Demonstration

FFIRN Field Format Index Reference Number

FH Frequency Hopping

FIN Finland

FORMETS NATO Message Text Formatting System

FRA France or French

FTP File Transfer Protocol

FUD Field Use Designator

FUDN Field Use Designator Number

FUI Field Use Identifier

GBR United Kingdom of Great Britain and Northern Ireland

GeFüSys Gefechtsfeldführungssystem

GEL Generic Event List

GH ATCCIS Generic Hub (Data Model)

GIE Global Information Environment


Edition 2.4

A-8

GOIDG General Officers International Digitization Group

GPOC Gateway Point of Contact

GRC Greece

GW Gateway

HCDR High Capacity Data Radio

HDRS Headers

HEROS Heeresführungsinformationssystem für rechnergestützte

Operationsführung in Stäben

HF High Frequency

HICON Higher Controller

HoD Head of Delegation

HQ Headquarters

HQ AFCENT Headquarters Allied Forces Central Europe

HQ AFSOUTH Headquarters Allied Forces Southern Europe

HQ ARRC Headquarters ACE Rapid Reaction Corps

HQ EUROCORPS Headquarters European Corps

HRF/LRF High Readiness Forces / Low Readiness Forces

HTML Hyper Text Markup Language

HTTP Hyper Text Transfer Protocol

HUN Hungary

HW Hardware

I/O input / output

IAD Interface Adapter Device

IAW In Accordance With


Edition 2.4

A-9

ICAM Integrated Computer-Aided Manufacturing

ID Identifier

IDEF1X ICAM Definition Language 1. Extension

IDL Interface Definition Language

I.E. Id Est-Such As

IEEE Institute of Electrical and Electronic Engineers

IER Information Exchange Requirement

IMC Information Management Cell

IMS International Military Staff

INFOSEC Information Security

IOB Inter-Operability Branch

IOF Input/Output Facility

IOT&E Initial Operational Test & Evaluation

IP Internet Protocol, ISO/OSI level 3

IPM Interpersonal Messaging

IPMS Interpersonal Messaging System

IR Incident Report

IRD Information Resource Dictionary

IRDS Information Resource Dictionary Standard

IRRB IR Review Board

ISDN Integrated Services Digital Network

ISO International Organisation of Standardisation

ISO/OSI International Standardisation Organisation/ Open Systems

Interconnection


Edition 2.4

A-10

ISSC Information System Sub-Committee

ITA Italy or Italian

ITR Initial Technical Review (CP at AFS or DBA)

ITU International Telecommunication Union

JC3IEDM Joint C3 Information Exchange Data Model

JC3RCSC Joint C3 Requirements and Concepts Sub-Committee

JSB Joint Service Board

JWID Joint Warrior Interoperability Demonstration (renamed to CWID in

2005)

LAN Local Area Network

LC2IEDM Land Command and Control Information Exchange Data Model

LC2IS Land Command and Control Information System

LCIS Land Common Interoperability System

LFCS Land Forces Command System

LFC2IS Land Forces Command and Control System

LG.1 Land Group 1 (of the NATO Army Armaments Group - NAAG)

LLAPI Low Level Air Picture Interface

LLC Logical Link Control

LO Liaison Officer

LOCON Lower Controller

LOWG Land Operational Working Group

LTU Lithuania

MAS NATO Military Agency for Standardisation

MBN MIP Briefing Notes


Edition 2.4

A-11

MBP MIP Block Plan

MBPT MIP Boiler Plate Text

MBxTP MIP Block x Test Plan (x is for the Block it’s written for)

MCDM MIP Common Data Model

MCI MIP Common Interface or MIP Gateway

MCLiP MIP Communications and Liaison Plan

MCMP MIP Configuration Management Plan

MCS Maneuver Control System

MDP MIP Development Plan

MDWP Multi-Disciplinary Working Party

MEBxR MIP End Of Block x Report (x is for the Block it’s written for)

MEDP MIP Exercise and Demonstration Plan

MEI Message Exchange Interface

MEL Main Events List

MEM Message Exchange Mechanism

MFI Mandatory For Implementation

MG Multinational agreement

MGA CP MG agreed

MGS CP in MG Staffing process MTFWG

MHS Message Handling System

MIC Multinational Interoperability Council

MIE Military Information Environment

MIF MIP Integrated Framework


Edition 2.4

A-12

MIL-STD-2525B US Mil Standard, Common Warfighting Symbology, version B dd

30 Jan 1999

MIME Multipurpose Internet Mail Extensions

MIP Multilateral Interoperability Programme

MIP Baseline List MIP Baseline Documents Status List

MIP CONOPS MIP Concept of Operations.

MIP Doc Reg MIP Document Register

MIP Glos MIP Glossary

MIP POC MIP Point of Contact List

MIPS MIP Integrated Programme Schedule

MIR MIP Implementation Rules

MMHSWG Military Message Handling Services Working Group

MNC Multinational Corps

MND Multinational Division

MNMB MIP – NDAG Management Board

MOA Memorandum of Agreement

MOD Ministry of Defence

MOH MIP Operational Handbook

MOL MIP Official Library

MOLT MIP Operational Level Test Specification

MOOTW Military Operations Other Than War

MOP MIP Operating Procedures

MOU Memorandum of Understanding

MPMP MIP Programme Management Plan


Edition 2.4

A-13

MPRL MIP Program Risk List

MPR MIP Problem Report

MPRRB MPR Review Board

MPRT MIP Problem Report Tool (aka MIPzilla, Bugzilla)

MRMP MIP Risk Management Plan

MRS MIP Reference System

MS MIP Solution

MS Message Store

MSB MIP Standard Briefing

MSG MIP Steering Group

MSG Message

MSISP MIP System Interconnections Security Policy

MSLT MIP System Level Test Specification

MSRS MIP System Requirement Specification

MTA Message Transfer Agent

MTBF Mean Time Between Failure

MTC MIP Test Controller

MTEMP MIP Test and Evaluation Master Plan

MTF Message Text Format

MTFWG Message Text Format Working Group

MTFWG CM Plan Message Text Format Working Group Configuration Management

Plan

MTIDP MIP Technical Interface Design Plan

MTIR MIP Tactical C2IS Interoperability Requirement


Edition 2.4

A-14

MTM Message Transfer Mechanism

MTP MIP Test Plan

MTS Message Transfer System

MTTP MIP Technical Test Plan

MTTR Mean Time To Repair

MTWP MIP Testing Working Party

MVS MIP Vision and Scope

MWAOP MIP WEB Site Administration and Operating Procedures.

NAAG NATO Army Armaments Group

NAD Network Architecture Diagram

NARR Narrative

NATO North Atlantic Treaty Organisation

NBC Nuclear, Biological, Chemical

NC3A NATO Command Control & Consultation Agency

NC3B NATO Command Control & Consultation Board

NC3O NATO Command Control & Consultation Organization

ND National Division

NDAG NATO Data Administration Group

NEGACK Negative Acknowledgement

NEO Non-combatant Evacuation Operations

NHQC3S NATO Headquarters Consultation, Command and Control Staff

NHQC3S/IOB NATO Headquarters Consultation, Command and Control Staff /

Interoperability Branch

NI Not Implemented


Edition 2.4

A-15

NIETWG NATO Interoperability Testing Working Group

NIMP NATO Interoperability Management Plan

NIPD NATO Interoperability Planning Document

NLD The Netherlands

NOR Norway

NOSWG NATO Opens Systems Working Group

NPIS NATO Procedural Interoperability Standards

NRT Nearly Real Time

O/R Originator/Recipient

OBJ Objective

OCL Object Constraint Language

OIG Operational Information Groups

OLT Operational Level Test

OMG Object Management Group

OMT Object Modelling Technique

OO Object Oriented.

OOTW Operations Other Than War

Op Eval Operational Evaluation

OPCOM Operational Command

OPCON Operational Control

OPLAN Operations Plan

OPORDER Operations Order

ORB Object Request Broker


Edition 2.4

A-16

ORBAT Order of Battle

ORG Organization

OSI Open Systems Interconnection

OT Object Technology

OWG Operational Working Group

P1 A special X.400 protocol

PDAU Physical Delivery Access Unit

PDU Protocol Data Unit

PL Phase Line

PM Project Manager

PMG Programme Management Group

POL Poland

POSACK Positive Acknowledgement

PPP Point-to-Point-Protocol

PRMD Private Management Domain

PRT Portugal

QACISG Quadrilateral Army CIS Interoperability Group

QACISIG Quadrilateral Army Communications and Information systems

Interoperability Group

QIOP Quadrilateral Interface Operational Procedures (QIP Program)

QIP Quadrilateral Interoperability Programme

QMHS QIP Message Handling System

QTIDP QIP Technical Interface Design Plan

RCPT Receipt to


Edition 2.4

A-17

RDBMS Relational Data Base Management System.

RDC Replication Domain Composite

RDT Replication Domain Type

REPMAN Replication Manager

RET Return

RFC Request for Comments

RFC 822 Part of SMTP Message Text Format

RFD Request For Deviation

RFW Request For Waiver

RIP Routing Information Protocol

RITA Réseau Intégré de Transmissions Automatiques

RMKS Remarks

ROU Romania

RPC Remote Procedure Call

RTSE Reliable Transfer Service Element

S&F Store and Forward

SA Situational Awareness

SAN Secondary Access Node

SAP Service Access Point

SATCOM Satellite Communications

SCRA(T) Single Channel Radio Access (Terminal)

SEAWG Systems Engineering & Architecture Working Group

SEI Software Engineering Institute from Carnegie Mellon University


Edition 2.4

A-18

SC/n Subcommittee/number

SHA Supreme Headquarters Allied Powers Europe

SHAPE Supreme Headquarters Allied Powers Europe

SIACCON Sistema Automatizzato di Comando e Controllo

SICF Système d’Information pour le Commandement des Forces

SIMACET SIstema de Mando y Control para el Ejército de Tierra

SINCE Simulation and C2 Information System Connectivity Experiment

SIR Système d’Information Régimentaire

SLIERP Senior Land Information Exchange Requirements Panel

SLT System Level Test

SME Subject Matter Expert

SMTP Simple Mail Transfer Protocol

SNR (A) Senior National Representatives (Army)

SNR (C3) Senior National Representatives C3

SOI Statement of Intent

SOP Standard Operating Procedures

SOTRIN Sottosistema di Trasmissioni Integrate

SPN Self-Protecting Node

SQL Structured Query Language

SRS [Software or System] Requirements Specifications

SSP System Security Policy

STANAG STANdardisation AGreement

STGP Shared Tactical Ground Picture


Edition 2.4

A-19

SUT System Under Test

SVN Slovenia

SW Software

SWE Sweden

SYS ACK System Acknowledgement

SYS NAK System Negative Acknowledgement

TAA Tactical Assembly Areas

TACCIS Tactical Area Command and Control Information System

TASK ORG Task Organisation

TBD To be Done / To be Decided / To be Determined

TCP Transmission Control Protocol

TEWG Test and Evaluation Working Group

TFMAN Transfer Facility Manager

TFTP Trivial File Transfer Protocol

TIDP Technical Interface Design Plan

TMHS Tactical Message Handling System

TOA Transfer Of Authority

TOC Tactical Operations Centre

TOP WG Land Forces Tactical Doctrine and Operational Procedures Working

Group

ToR Terms of Reference

TP2K TACOM Post-2000

TTP Tactics, Techniques and Procedures

TTSpec Technical Test Specification


Edition 2.4

A-20

TUR Turkey

TWG Technical Working Group

UA User Agent

UDP User Datagram Protocol

USA United States of America

UTC Coordinated Universal Time

UTM Universal Transverse Mercator

UTP Unshielded Twisted Pair

VHF Very High Frequency

WAN Wide Area Network

WG(s) Working Group(s)

WGS World Geodetic System

WP(s) Working party(s)

WTD 81 Wehrtechnische Dienststelle 81

(Federal Armed Forces Technical Centre for Communications and

Electronics 81)

WWW World Wide Web

X.400 CCITT/ITU Recommendation for Message Handling Systems

XDR External Data Representation

XML Extensible Markup Language

Y2K Year 2000


Edition 2.4

B-1

B-1

ANNEX B DEFINITIONS

Actor Someone or something, outside the system that interacts with the

system.

Analysis The part of the development process whose primary purpose is to

formulate a model of the problem domain. Analysis focuses on what

to do.

Architectural

Description

A collection of products to document an architecture.

Architecture The fundamental organization of a system embodied in its

components, their relationships to each other, and to the

environment, and the principles guiding its design and evolution.

Artefact Artefacts are either final or intermediate work products that are

produced and used during a project. Artefacts are used to capture

and convey project information. An artefact can be any of the

following:

• A document, such as Business Case or Software Architecture Document;

• A model, such as the Use-Case Model or the Design Model; • A model element; that is, an element within a model, such

as a class, or a subsystem; and • Plans, code, test cases, manuals.

Baseline A reviewed and approved release of artefacts that constitutes an

agreed basis for an in-service period or further evolution or

development and that can be changed only through a formal

procedure, such as change management and configuration control.

Block A block is a fixed period of time that goes through a complete (3

year) development and (2 year) in-service cycle. At the end of a

block development cycle, a new generation of the product is

baselined. In MIP, a block has a fixed duration of five years.


Edition 2.4

B-2

B-2

Class A description of a set of objects that share the same attributes,

operations, methods, relationships, and semantics. A class may use a

set of interfaces to specify collections of operations it provides to its

environment.

Class Diagram A diagram that shows a collection of declarative (static) model

elements, such as classes, types, and their contents and relationships.

CM Configuration Management (CM) is a supporting process whose

purpose is to identify, define, and baseline items; control

modifications and releases of these items; report and record status of

the items and modification requests; ensure completeness,

consistency and correctness of the items; and control storage,

handling and delivery of the items.

Construction Construction is one of the phases in development life cycle. The

purpose of the construction phase is to clarify the remaining

requirements, complete the development of the national

implementation of the product based upon the baselined architecture

and decide if the implementation is ready for integration with other

national implementations of the product.

Contracts From an operational context a contract is the description of

information that a Data-Provider [DP] and Data-Receiver [DR] will

exchange. A contract in replication terms consists of a DP, DR, a

description of a subset of tables, referred to as a RDC, from the

C2IEDM and an optional description of the associated horizontal

filters.

A contract defines, to the replication mechanism, a set of the data in

the database to be replicated. It associates a contract type, with

appropriate parameter values, to a source (data provider) and a

destination (data receiver). Contracts are instantiated by the

replication managers when data needs to be replicated between


Edition 2.4

B-3

B-3

nodes on the network based on the operation needs of the users

within the national system and/or display on any C2 systems.

Contract-Types A contract template that specifies the subset of data in the database

to be replicated by combining an RDC with parameterised

horizontal filter statements for each table in the RDC. The pertinent

records within the MCDM Data Base are specified in a given

contract type.

Examples:

‘UNIT-ACTIVITY-and-LOCATION’ -- a description of the attitude

of the unit within a given area of interest

‘CONTROL-FEATURES’ -- the description of limits of units, area or

zone or axis of action

‘ORBAT and STATUS’ -- the description of the status of the reported

units.

Cycle One complete pass through the four phases: inception, elaboration,

construction and transition. The span of time between the beginning

of the inception phase and the end of the transition phase.

Database Index Data access structures used to speed access along specified paths.

Data base rules These are the logical rules found in the C2IEDM. These rules are

used to ensure that automated data exchange is logically complete,

and therefore machine processable information.

Database Trigger Event-activated behaviour associated with tables.

Data fill National data fill: data needed to support an operation (e.g. national

ORBAT/task organisation)

MIP common data fill: MIP provided data that every MIP Gateway

has to load (for Block 2 this is TYPE fill).

Data Provider A Tactical addressee which is transmitting information to one or


Edition 2.4

B-4

B-4

many receiver.

Data Receiver A Tactical addressee which is acquiring information from one or

many providers.

Denormalization Denormalization aids the process of systematically adding

redundancy to the database to improve performance.

Denormalization can improve certain types of data access

dramatically, but there is no success guaranteed and there is always

a cost.

Design The part of the development process whose primary purpose is to

decide how the system will be implemented.

Design Model

An object model describing the realization of use cases; serves as an

abstraction of the implementation model and its source code.

<Development> Cycle One complete pass through the four <development> phases:

inception, elaboration, construction and transition. The span of time

between the beginning of the inception phase and the end of the

transition phase.

<Development> Phase The time between two major project milestones, during which a

well-defined set of objectives is met, artifacts are completed, and

decisions are made to move or not move into the next phase.

Discipline A discipline is a collection of related activities that are related to a

major 'area of concern'.

Document A document is a collection of information that is intended to be

represented on paper, or in a medium using a paper metaphor. The

paper metaphor includes the concept of pages, and it has either an

implicit or explicit sequence of contents. The information is in text

or two-dimensional pictures. Examples of paper metaphors are word

processor documents, spreadsheets, schedules, Gantt charts, web

pages, or overhead slide presentations.


Edition 2.4

B-5

B-5

Domain An area of knowledge or activity characterized by a set of concepts

and terminology understood by practitioners in that area.

Domain Model A domain model captures the most important types of objects in the

context of the domain. The domain objects represent the entities that

exist or events that transpire in the environment in which the system

works. The domain model is a subset of the business object model.

Elaboration Elaboration is one of the phases in development life cycle. The

purpose of the elaboration phase is to baseline the architecture of the

product in order to provide a stable basis for the bulk of the design

and implementation effort in the construction phase and to decide to

commit to the remainder of the development cycle.

Enabling System A system that complements a system-of-interest during its life cycle

stages but does not necessarily contribute directly to its function

during operation.

Entity An entity is any distinguishable object or concept that is to be

represented in the database.

Environment (1) A discipline in the software-engineering process, whose purpose

is to define and manage the environment in which the system is

being developed. Includes process descriptions, configuration

management, and development tools.

(2) A specific instance of a configuration of hardware and software,

established for the purpose of software development, software

testing, or in which the final product is deployed.

Feature An externally observable service provided by the system, which

directly fulfills a stakeholder need.

Framework A micro-architecture that provides an extensible template for

applications within a specific domain.


Edition 2.4

B-6

B-6

Generation Final release at the end of a <development> cycle.

Host Nation A nation which receives the forces and/or supplies of allied nations

and/or NATO organizations to be located on, or to operate in, or to

transit through its territory. (AAP-6, NATO Glossary of Terms and

Definitions, Aug 95).

IDEF1X IDEF1X is a method for designing relational databases with a syntax

designed to support the semantic constructs necessary in developing

a conceptual schema. A conceptual schema is a single integrated

definition of the enterprise data that is unbiased toward any single

application and independent of its access and physical storage.

IEEE The Institute of Electrical and Electronics Engineers (Eye-triple-E)

is a non-profit, technical professional association of more than

380,000 individual members in 150 countries.

Inception Inception is one of the phases in development life cycle. The

purpose of the inception phase is to achieve concurrence among all

stakeholders on the objectives for the development cycle, determine

if it is feasible, and decide if it is worth pursuing.

Incremental Qualifies an iterative development strategy in which the system is

built by adding more and more functionality at each iteration.

Initialisation The process that leads to two organisations having the same

common awareness of the military situation. This means the MOP -

Technical Setup and Operational Setup and Management Procedures

have to be executed.

Integration Integration is one of the phases in development life cycle. The

purpose of the integration phase is to integrate all readied national

implementations of the product and to perform its verification and

initial validation

Interoperability The ability of systems to provide services to and accept services


Edition 2.4

B-7

B-7

from other systems and to use the services so exchanged to enable

them to operate effectively together. It can be achieved:

by exchanging of formatted messages (level 4);

by pushing selected data towards other systems (level 5 – push).

Iteration A distinct sequence of activities with a base-lined plan and valuation

criteria resulting in a release (internal or external).

Life Cycle Model A framework of processes and activities concerned with the life

cycle, which also acts as a common reference for communication

and understanding.

MACCIS Model based Architecture for Command and Control Information

System (Minimum Architecture for Command and Control

Information System).

MIP Common Data

Dictionary

It contains all the dictionaries attached both to the MIP Message

Text Formats and MIP Common Data Model.

MIP Common Data

Model

Data Model developed from the LC2IEDM (current C2IEDM), used

as starting point and mapped with AdatP-3 12.2 and APP-6A, for

satisfying MIP Requirements

MIP Common Interface

(MCI)

or

MIP Gateway

A logical description of the configuration of two or more

implementations (in Soft and/or Hardware) of the MIP

specifications that enables information exchange between two or

more C2IS of different nations.

MIP Interface The national implementation of the MIP Specifications.

MIP Solution A set of items delivered by the MIP programme at the end of each

block. It includes the MIP specifications, Standard Operation

Procedures and other documentation that is required for

implementation of the specifications and for use of the MCI.

MIP Specification What is required to implement a MIP Interface.


Edition 2.4

B-8

B-8

Model An abstraction of a physical system with a certain purpose. A model

captures a view of a physical system. Hence, it is an abstraction of

the physical system with a certain purpose; for example, to describe

behavioral aspects of the physical system to a certain category of

stakeholders. A model contains the entire model elements needed to

represent a physical system completely according to the purpose of

this particular model.

Object Model An abstraction of a system's implementation..

Operational Information

Groups (OIG)

Operational Information Groups are sets of information passed

across the MIP Gateway.

Operational procedures These are the human business rules that ensure that operational

meaning and intent is exchanged during operations.

Order of battle The identification, strength, command structure, and disposition of

the personnel, units, and equipment of any military force.

ORBAT concerns nations. ORBAT is a list of military forces/units

at any levelORBAT TOA (TRANSFER OF AUTHORITY)

concerns coalition forces.

ORBAT TOA is the list of forces provided to the force commander

from the nations.

Product The <system> that is the result of development, and some of the

associated artefacts.

Query A result of a structured information request in a formal notation used

to extract information from a database.

Receiving Nation The nation to which the Donor Nation deploys its gateway. The

Receiving Nation normally assumes Operational Control of the

Donor Nation's gateway.

Release A subset of the end-product that is the object of evaluation at a


Edition 2.4

B-9

B-9

major milestone. A release is a stable, executable version of product,

together with any artifacts necessary to use this release, such as

release notes or installation instructions. A release can be internal or

external. An internal release is used only by the development

organization, as part of a milestone, or for a demonstration to users

or customers. An external release (or delivery) is delivered to end-

users. A release is not necessarily a complete product, but can just

be one step along the way, with its usefulness measured only from

an engineering perspective.

Replication Domain

Composite (RDC)

A Replication Domain Composite is the union of selected RDTs

(often combined to support a specific contract), and the entity RDC-

ELEMENT specifies the RDTs from which the RDC is composed.

An RDC may be used to define one set of data to be exchanged

between a DP and a DR. Because an RDC is a union of RDTs and

some RDTs may be subsets of other RDTs, there is no need to

include, in an RDC specification, an RDT that is a subset of another

RDT in the that specification. An RDC is a referentially complete

set of the tables.

Replication Domain

Type (RDT)

A minimum set of entities of a data model that is originated from a

specific “leaf” ENTITY and that is referentially complete including

all non-identifying relationships. “Complete” means that none of the

entities has a parent entity that is not part of the same RDT. An

RDT can be considered as an independent sub-model within the data

model. An RDT can be viewed as the smallest subset of the

database that can be agreed as referentially integral for information

exchange.

Repository A storage place for object models, interfaces, and implementations.

Requirement A requirement describes a condition or capability to which a system

must conform; either derived directly from user needs, or stated in a


Edition 2.4

B-10

B-10

contract, standard, specification, or other formally imposed

document.

RUP Rational Unified Process®, or RUP®, is configurable software

development process platform that delivers practices and a

configurable architecture that enable you to select and deploy only

the process components you need for each stage of your project.

Semantic Artefacts /

Composites

By recognising that data is only the building block of information

and knowledge. Common data as in the C2IEDM is a necessary but

not sufficient condition to the achievement of level 5

interconnection. The other necessary condition is semantic

completeness. One could submit that information is indeed made up

of data plus semantic completeness (business rules). The operational

requirement is about the exchange of information and not only the

exchange of data. However in order for information to be processed

by automated command and control system, it has to be broken

down into data. This data elements are either created or combined

into logical and semantic artefacts in order to confirm the

operational value of the intended exchange. The actual

implementation of one of these artefacts is information composite.

Semantic rules These are the Rules used to create semantic composites, which

maintain operational meaning of the information during creation,

exchange and display of operational activities. These rules can be

implemented through human procedures, application level business

rules or replication semantic validation, (In the case of the MIP

phase 2 prototype demo the replication semantic rules validation

will be limited to agreed C2IEDM business rules. Operation

business rules associated with agreed generic operational events will

be implemented in the national C2IS application or managed

through operational procedures).


Edition 2.4

B-11

B-11

Sequence Diagrams A diagram that shows object interactions arranged in time sequence.

In particular, it shows the objects participating in the interaction and

the sequence of messages exchanged.

Specification A declarative description of what something is or does.

SRS Is a set of requirements, which completely defines the external

behaviour of the system to be built—sometimes called a functional

specification.

Stage A period within the life cycle of a system that relates to the state of

the system description or the system itself.

Stakeholder A party having a right, share or claim in a system or in its possession

of characteristics that meet that party’s needs and expectations.

Stakeholder An individual who is who is materially affected by the outcome of

the system.

System A set or arrangement of elements [people, products (hardware and

software) and processes (facilities, equipment, material, and

procedures)] that are related and whose behaviour satisfies customer

/ operational needs, and provides for the life cycle sustainment of

the products.

System Element A member of a set of elements that constitutes a system.

System Life Cycle The evolution with time of a system-of-interest from conception

through to retirement.

System-of-Interest The system whose life cycle is under consideration in the context of

this document.

Task Organization A temporary grouping of forces designed to accomplish a particular

mission. Task organization involves the distribution of available

assets to subordinate control headquarters by attachment or by

placing assets in direct support or under the operational control of


Edition 2.4

B-12

B-12

the subordinate.

The force commanders reorganize his forces to solve the mission

given in a plan. He decides the best way to accomplish the mission,

is to create a specific task organization based on the ORBAT TOA

linked to this specific plan.

Test Case The definition of a specific set of test inputs, execution conditions,

and expected results, identified for the purpose of making an

evaluation of some particular aspect of a target test item.

Timeboxing The approach to the management of an iteration's schedule

recommended in the RUP: having initially established the scope and

schedule for an iteration, the project manager is encouraged to

actively manage that scope (and the resources committed to the

iteration) so as to meet the planned iteration end date, rather than

slipping the end date to accommodate the originally planned scope,

if development takes longer than planned. In the RUP, reduction of

scope is preferred to addition of resources to manage a slipping

schedule. The motivations for this approach are to make the results

of an iteration visible to the stakeholders and to assess the iteration,

so that the lessons learned may be applied to subsequent iterations.

Transition Transition is one of the phases in development life cycle. The

purpose of the transition phase is to deliver the product to the

operational environment in each nation and to assess the completion

of development cycle.

UML Unified Modelling Language (UML) is a standard language for

specifying, visualizing, constructing, and documenting the artefacts

of software systems. It simplifies the complex process of software

design, making a "blueprint" for construction.

Use Case A use case defines the user's view of interactions with (and within)

the system. Use Cases show how entities interact, and are usually


Edition 2.4

B-13

B-13

presented as structured text or diagrammatically.

Use-Case Model A model that describes a system’s functional requirements in terms

of use cases.

Use-Case Package A use-case package is a collection of use cases, actors, relationships,

diagrams, and other packages; it is used to structure the use-case

model by dividing it into smaller parts.

View A projection of a model, which is seen from a given perspective or

vantage point and omits entities that are not relevant to this

perspective.

Viewpoint A viewpoint is one or more stakeholder concerns.

Workflow The sequence of activities performed in a business that produces a

result of observable value to an individual actor of the business.


Edition 2.4

C-1

C-1

ANNEX C REFERENCES