NATO C3 Technical ArchitectureTable of Contents1. Introduction1.1. Background1.1.1. Role of the NC3TA within the NATO Interoperability Framework1.1.1.1. NATO Interoperability Framework.1.1.1.2. Technical Architecture in the NIE.1.1.1.3. Responsibilities1.1.2. NATO Approach to CCIS Standardisation1.1.3. National NC3TA related Initiatives1.1.4. Major NATO Programmes1.1.5. NATO Information Systems Requirements1.2. Purpose and Context1.2.1. Purpose of the NC3TA1.2.2. Context of the NC3TA1.2.3. NC3TA Evolution Strategy1.3. Intended Audience1.4. Point of Contact for the NC3TA1.5. Reference Documents2. NC3TA Management Processes2.1. NC3TA Overall Description2.2. NC3TA Internal Management Processes2.2.1. NC3TA Update Process2.2.1.1. NC3TA Update Review, Management and Dependencies2.2.1.2. Requests For Change Proposal (RFCP)2.2.1.3. Co-ordination with NC3B Sub-structure2.2.1.4. NC3TA Update Process within the NATO Standardisation Programme2.2.1.5. Co-ordination with the NATO PMOs in NC3TA Update Process2.2.1.6. National Systems Interoperability Co-ordination in NC3TA Update Process2.2.1.7. Dissemination of NC3TA Documents2.2.2. Configuration Management of the NC3TA2.2.2.1. CM Organisation2.2.2.2. Resources2.2.2.3. Baselines2.2.2.4. Configuration Control Procedures.3. NC3TA Facilities and Services3.1. Introduction3.2. NC3TA Development and Maintenance Support3.3. Project Support3.4. Testing EnvironmentA. Request for Change Proposal (RFCP)B. References to National COE InitiativesB.1. NetherlandsB.2. United KingdomB.3. United StatesC. Summary of Major NATO ProjectsC.1. BI-Strategic Commands AISC.1.1. BackgroundC.1.2. ObjectivesC.1.3. IncrementsC.1.4. System ViewC.1.5. Functional RequirementsC.1.6. Bi-SC and National C2IS InteroperabilityC.2. ACCS ProgrammeC.2.1. Air Command and Control System First Level of Operational Capability (ACCS LOC1)C.2.2. NATO Air Command and Control System (ACCS LOC1 Capability)C.2.3. ACCS ArchitectureD. WHAT'S NEW IN VOLUME 1E. ABBREVIATIONSF. HARMONIZATION OF NATO AND CCEB TECHNICAL ARCHITECTURESF.1. LIST OF UNDERSTANDINGS BETWEEN NATO AND THE CCEBADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlAllied Data Publication 34(ADatP-34)
NATO C3 Technical Architecture
Volume 1Management
Version 4.0
Date: 16 December 2002ISSC NATO Open Systems Working GroupADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -Table of Contents1. Introduction 1.1. Background 1.1.1. Role of the NC3TA within the NATO Interoperability Framework 1.1.2. NATO Approach to CCIS Standardisation 1.1.3. National NC3TA related Initiatives 1.1.4. Major NATO Programmes 1.1.5. NATO Information Systems Requirements 1.2. Purpose and Context 1.2.1. Purpose of the NC3TA 1.2.2. Context of the NC3TA 1.2.3. NC3TA Evolution Strategy 1.3. Intended Audience 1.4. Point of Contact for the NC3TA 1.5. Reference Documents 2. NC3TA Management Processes 2.1. NC3TA Overall Description 2.2. NC3TA Internal Management Processes 2.2.1. NC3TA Update Process 2.2.2. Configuration Management of the NC3TA 3. NC3TA Facilities and Services 3.1. Introduction 3.2. NC3TA Development and Maintenance Support 3.3. Project Support 3.4. Testing Environment A. Request for Change Proposal (RFCP) B. References to National COE Initiatives B.1. Netherlands B.2. United Kingdom B.3. United States C. Summary of Major NATO Projects C.1. BI-Strategic Commands AIS C.1.1. Background C.1.2. Objectives C.1.3. Increments C.1.4. System View C.1.5. Functional Requirements C.1.6. Bi-SC and National C2IS Interoperability C.2. ACCS Programme C.2.1. Air Command and Control System First Level
of Operational Capability (ACCS LOC1) C.2.2. NATO Air Command and Control System
(ACCS LOC1 Capability) C.2.3. ACCS Architecture D. WHAT'S NEW IN VOLUME 1 E. ABBREVIATIONS F. HARMONIZATION OF NATO AND CCEB TECHNICAL ARCHITECTURES F.1. LIST OF UNDERSTANDINGS BETWEEN NATO AND THE CCEB ADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -1. INTRODUCTION1.1. BACKGROUND1.1. BACKGROUND1.1.1. Role of the NC3TA within the NATO Interoperability Framework1.1.1. Role of the NC3TA within the NATO Interoperability Framework1.1.1.1. NATO Interoperability Framework.1.1.1.1. NATO Interoperability Framework.The NATO Interoperability Framework (NIF) is a 3 layer hierarchical
structure comprising Policy, Execution and Product elements. The Product
layer, known as the NATO Interoperability Environment (NIE), provides
the basis for the technical development and evolution of C3 systems, and is
itself partitioned into two domains: design and implementation. Within the
design domain the NC3TA supports the Technical View by providing
architectural design concepts and templates through Volume 2
(Architectural Descriptions and Models). Within the implementation
domain, the NIE addresses the appropriate standards and products that are
inclusive components of the NC3TA at Volume 4 NATO Common Standards
Profile (NCSP) and Volume 5 NATO Common Operating Environment (NCOE).Figure 1.1. NATO C3 Interoperability Environment Framework (NIF) Schematic1.1.1.2. Technical Architecture in the NIE.1.1.1.2. Technical Architecture in the NIE.From the perspective of achieving specified interoperability requirements,
C3 system development is considered on the basis of three architectural
views; Operational, System and Technical, as described in the Architectural
Framework for NC3S. The NC3TA provides the
principal source of procedures, architectural concepts, data (standards and
products), and their relationships, from which the Technical View may be
constructed. It could be considered as the minimal set of rules required to
ensure that the selected system elements collectively conform to meet the
requirements established by the Operational View. In its totality, the
NC3TA contains and describes the capabilities and attributes of all
procedures, standards and products necessary to develop the technical view
in order to meet operational needs. Closely associated with the NIE and
NC3TA is the concept of a Testing Infrastructure (NIETI), which is
necessary to ensure that all selected standards and products are verified
against appropriate criteria (technical, integration, interoperability) before
they are implemented in the system architecture to meet operational
scenarios.1.1.1.3. Responsibilities1.1.1.3. ResponsibilitiesThe NC3Board conducts responsibility for the overall NATO C3
Interoperability Policy (which forms the upper level of the NIF). The
Interoperability Sub-Committee (AC/322-SC/2) is its custodian on behalf
of the Board. The Policy is executed through the NATO Interoperability
Management Plan (NIMP) volumes 1 (Directives) and 2 (Execution
Guidance), which support the second layer of the NIF. The Interoperability
Sub-Committee assumes responsibility for the NIMP. Within this structure,
the NC3TA comes under the responsibility of the Information Systems
Sub-Committee (AC/322-SC/5) for design, development and maintenance;
for functional purposes it supports the design and implementation layers of
the NIE as described above.1.1.2. NATO Approach to CCIS Standardisation1.1.2. NATO Approach to CCIS StandardisationPast NATO policy of standardisation applying to the C2IS field was
primarily supported by STANAGS, NATO OSE and NOSIP
documentation. It is clear that STANAGs will still remain the main vehicle
to achieve interoperability objectives between national systems and
between national and NATO systems. The NATO OSE and NOSIP, essentially
provided the fundamental
technical guidance on the selection of open systems standards, thus
conformance of NATO CIS to these standards, this work has now been migrated into the
NC3TA and will decisively contribute to the achievement of NATO
interoperability objectives.This past experience of an interoperability strategy based only on
adherence to standards, whilst in large part ignoring other design and
implementation considerations, has lead to a number of unresolved
problems such as:•Strict adherence to standards can inhibit the effective
exploitation of Information Technology, whilst in the meantime
overlooking potential advantages offered by commercial
products which may effectively meet user requirements and
reduce complexity, thus costs, of CIS realisation;•Commercial aspects have become the key IT market driver
and de facto standards, often based on proprietary solutions (e.g.
Microsoft), and have taken the lead over de jure standards;•Open standards by definition, address a wide range of
potential use, depending on customisable options, a growing part of
which are often declared "implementation defined";•Products frequently tend to pre-exist any standards,
because of commercial diversity, and there is often no other option than to
select a particular product. Such a decision potentially has a
large impact on the system architecture, the system&s ability to
evolve, and, ultimately on the interoperability achieved.The work undertaken in the NC3TA development takes these experiences
into account and aims to improve, complement and complete the approach
based solely on standards in order to address the existing gap between
system design and implementation stages (the NIE approach). It also
will produce a list of products that have been shown to implement the
selected standards1.1.3. National NC3TA related Initiatives1.1.3. National NC3TA related InitiativesThere are a number of national Technical Architecture programmes that
relate to the development and future evolution of the NC3TA. Collectively
they underpin the NC3TA, and are of specific interest in order to ensure
that the maintenance of NATO/National and nNation to Nation interoperability is preserved. A
short summary and references to a few of these National programmes can
be found in Appendix B. It should be noted that Combined Communications
Electronics Board (CCEB) ACP140A (Combined Interoperability
Technical Architecture (CITA) as ratified by the CCEB Nations (AS, CA,
NZ, UK, US) in March 2001 has been incorporated into Volume 4 of the NC3TA and
CCEB CITA development has now been discontinued.1.1.4. Major NATO Programmes1.1.4. Major NATO ProgrammesThe major NATO Programmes that are currently being influenced by the
NC3TA are ACE ACCIS, MCCIS and ACCS. Collectively they form the
projects that can benefit most from the NC3TA. The convergence of ACE
ACCIS and MCCIS into the Bi-SC AIS is influenced by the NC3TA and
the implementation of its common core will be based on the NATO C3
Common Operating Environment (NCOE).1.1.5. NATO Information Systems Requirements1.1.5. NATO Information Systems RequirementsCurrent Information System initiatives within both SCs are directed
towards a convergence of their individual CIS and MIS capabilities into a
future single Bi-SC AIS. This process can be envisioned as parallel evolutions
of existing programmes (ACE ACCIS and
MCCIS) with the incremental transition of core functions implemented
initially under a single management structure.The NC3B has agreed the Bi-SC AIS Implementation Strategy in which
the two current systems will be increasingly merged towards a single
consistent functional core capability to be based upon the NCOE and
subsequent evolutionary to accommodate functional area services (see
Figure 1.2 below).
This transition will take into account both the independent
evolution of each existing system (ACE ACCIS and MCCIS), and their
individual convergent paths. In parallel, each SC has harmonised their
management transition plan within the agreed strategy, with emphasis on
ensuring that redundant practice and procedures are eliminated as early as
possible and common structures are established in support of emerging
common system elements.Figure 1.2. NC3TA Role in Bi-SC AIS Implementation Strategy1.2. PURPOSE AND CONTEXT1.2. PURPOSE AND CONTEXT1.2.1. Purpose of the NC3TA1.2.1. Purpose of the NC3TAThe NC3TA will provide the necessary guidance and technical
components to support NATO CIS developments with the purpose to:•Serve as the principal
source of technical guidance for the management of NATO CIS
project implementations (project staff and NATO
Committees/Working Groups);•Track technology developments in order to
optimise application development;•Compile all applicable CIS standards as
baseline for optimising programmes and project selection and
adherence;•Assess applicable CIS products for system
application;•Support architecture-based CIS programme
development and evolution;•Provision of technical reference and
rationale to promote and optimise NATO CIS systems
interoperability;•Promote NATO internal, Nation to NATO and Nation to Nation
interoperability.1.2.2. Context of the NC3TA1.2.2. Context of the NC3TAThe NC3TA is constructed in the context of the new Overarching Goals and
Objectives requirement statements issued by the NC3B (AC/322-WP/0221, dated 2 May 2002) and
further detailed by the ISSC in AC/322(SC/5)N/253-REV2, dated 5 Nov 2002Volume 1 of the NC3TA addresses the management procedures necessary
for the successful implementation of the NC3TA into NATO systems.
These procedures cover both internal configuration management of all
volumes of the NC3TA (maintenance, updating, handling of standards and
products, etc) and the external relationships of Volumes 2, 4 and 5 as they
apply to the management of NATO projects.A number of support services and associated resources are necessary in
order to implement the NC3TA. This volume outlines how these services
are to be established, and addresses resources.
The NC3TA is centrally managed, and resource
estimates are based on this premise. Management authorities and
their responsibilities will also be outlined. The NC3TA internal
management relates to a strict configuration management of the 5 volumes
to keep standards information up-to-date and reflect changes in
technology.Since the NC3TA is one of the principal technical elements that will
support the formulation of an overall NATO CIS Architecture, its
implementation and management will evolve with time. In the short term,
the NC3TA will primarily support the enforcement of standards from the
NCSP in the project environment, over the longer term all appropriate
components of the NC3TA will be fully addressed.
Figure 1.3 below gives an overview of the typical
life-cycle of a NATO project and its relationship with external bodies.
Such a project will have to conform to the technical
prerequisites as laid down in the NC3TA.Successive evolutions of the NC3TA should extend the capability to
control into and across the full implementation and maintenance process.
Its role would be to help identify possible interoperability problem areas,
either by direct involvement or by advising the appropriate committees.Figure 1.3. NATO Project External Management Relationship1.2.3. NC3TA Evolution Strategy1.2.3. NC3TA Evolution StrategyThe NC3TA is a living document and is being updated on an
annual basis. New technologies, standards and products will be included
when they are considered applicable for NATO System use and in support
of interoperability with National Systems. 1.3. INTENDED AUDIENCE1.3. INTENDED AUDIENCEThe NATO user community of the NC3TA comprises technical project
managers, procurement staff, architects and IT specialists. The NC3TA
provides guidance to NATO Technical working groups within the
substructure of the NC3Board, Infrastructure and Military Budget
Committees. Although these documents are primarily developed for
NATO, they should also provide equal benefit to national project and
procurement staffs and their contractors, in order to promote the widest
possible opportunities for interoperability.Users of this volume will gain an understanding of the technical
architecture management process for the purpose of submitting change proposals
that are intended for any or all NC3TA volumes.1.4. POINT OF CONTACT FOR THE NC3TA1.4. POINT OF CONTACT FOR THE NC3TAThe NC3TA has been developed by the NATO Open Systems Working
Group (NOSWG) of the ISSC (SC/5), together with specialist sub-groups
as required. In addition to the formal Sub Committee approval process,
comments from other bodies on any of the 5 volumes are welcome, and
should be addressed to:
Secretary, ISSC
Information Systems and Technology Branch
NATO Headquarters C3 Staff
B-1140 Brussels, Belgium
Email: iss@hq.nato.int
The full NC3TA documentation is available on the NATO Website at: http://194.7.79.15/ or
http://www.nato.int/docu/standard.htm1.5. REFERENCE DOCUMENTS1.5. REFERENCE DOCUMENTSNC3B Overarching Goals and Objectives Statement AC/322-WP/0221, dated 2 May 2002NATO Policy for C3 Interoperability (ref PO(2000)39ISSC-CCEB List of Understandings (LoU) AC322(SC/5)/DS18, dated 7th May 2002 included at
Appendix FADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -2. NC3TA MANAGEMENT PROCESSES2.1. NC3TA OVERALL DESCRIPTION2.1. NC3TA OVERALL DESCRIPTIONThe NC3TA is composed of the five following volumes addressing
the various stages of the development of NATO Communication and Information Systems
from the design to the implementation:Volume 1: Management: This
volume provides the management framework for the development and
configuration control of the NC3TA and includes the general management
procedures for the application of the NC3TA in NATO C3 systems
development.Volume 2: Architectural Descriptions and
Models: This volume principally supports a
NATO CCIS technical framework to provide a common basis for the
establishment of the architectures of NATO Communications and Information Systems
projects. It will also offer a vision on the use of emerging OTS
technologies.Volume 3: Base Standards and
Profiles: This document is a repository of information
system and communication standards applicable to NATO Communication and Information
Systems as well as guidance for their use through the selection of profiles.Volume 4: NATO C3 Common Standards Profile
(NCSP): This document contains those standards that have either
a mandatory status or an emerging status. Emerging standards are standards that are expected
to be elevated to a mandatory status within a few years. It contains the subset of
mandatory and emerging standards critical to interoperability. It also contains
standards related to portability, and overall life-cycle process aspects of NATO
Common Funded (NCF) Systems. It should be noted that a STANAG that is
in scope for CCEB Nations within the NCSP, must be
releasable to Australia and New Zealand (see Appendix F LoU para 6(h)Volume 5: NATO C3 Common Operating
Environment (NCOE): The NCOE is the NCSP standards-based
computing and communication infrastructure, comprised of an
architectural component model that can host selected OTS products and
supporting services, providing the structural foundation necessary to
build NATO open systems interoperable with national systems, and the
OTS software product selection process and criteria. The NCOE also
contains the initial Basket of Products (BoP) from which Projects can
select.Rationale DocumentTo capture the process and selection of the NCSP standards, a seperate
NCSP Rationale Document (RD) has been produced
(AC/322(SC/5)N/215-REV1).Implementation HandbookTo assist the implementation of projects an NC3TA
Implementation Handbook has been developed (AC/322(SC/5)N/268).2.2. NC3TA INTERNAL MANAGEMENT PROCESSES2.2. NC3TA INTERNAL MANAGEMENT PROCESSES2.2.1. NC3TA Update Process2.2.1. NC3TA Update Process2.2.1.1. NC3TA Update Review, Management and Dependencies2.2.1.1. NC3TA Update Review, Management and DependenciesUpdating of the NC3TA will be conducted by a managed, rolling
review process which will take into account information on standards
and products available from a wide variety of sources. The NOSWG
acts as the hub for this maintenance activity, supported by the
NHQC3Staff and NC3A personnel as required. The information updating
process is based on Requests For Change Proposal (RFCP's). RFCP's
will be reviewed by the NOSWG, in accordance with figure Figure 2.1, and forward recommendations on acceptance to the SC/5.
The SC/5 will review the recommendations and determine acceptance and will forward
a reply to the originator. The NC3TA update cycle will stretch over one year ending the 15th
of December each year. The NC3TA will be issued each March following endorsement
by SC/5. This update cycle is depicted in the following figure (see Figure 2.1):Figure 2.1. NC3TA Update CycleConfiguration management of this process is described in section
Section 2.2.22.2.1.2. Requests For Change Proposal (RFCP)2.2.1.2. Requests For Change Proposal (RFCP)Requests for Changes Proposal (RFCP) to the NC3TA will be
processed by the NOSWG following the process outlined at
Figure 2.2. The key dates for the RFCP Process are:
End of March issue request for
changes to the new version, end of June closing date for RFCPs for
guaranteed processing and review for the next version, in the role of Configuration Control Board,
against an agreed schedule in order to meet Baseline delivery.
The primary point of contact for RFCP
submission is the Secretary NOSWG. RFCP's may be submitted to
the NOSWG through a number of channels, including:•NOSWG National representatives and
Observers (see SC/5-CCEB LoU at Appendix F);•SC representatives;•NATO Agency representatives;•Other Sub Committees of the NC3Board, and their
substructures;•NC3Board Staff representatives;•NATO working groups / committees responsible for a
specific standards domain.Approval of RFCP's will be co-ordinated with the responsible
sub-committees where appropriate. Appendix A contains
the form for RFCP's.Figure 2.2. Outline RFCP handling process2.2.1.3. Co-ordination with NC3B Sub-structure2.2.1.3. Co-ordination with NC3B Sub-structureThe NC3B sub-committees will contribute to the development of
the NC3TA in their respective C3 areas of responsibility by responding
to the RFCP as indicated in Section 2.2.1.1. The
co-ordination of NC3TA development effort throughout the NC3B
sub-structure should be based on the following guidance:•The secretaries of the SCs will constitute the
primary point of co-ordination with the NOSWG, to help the
ISSC/NOSWG to obtain the adequate support from each SCs working
structure;•In special cases, specific requests for
information or even questionnaires will be sent to the relevant
Committees/WGs, in order to receive expert views on specific issues,
technologies etc.•The NOSWG Chairman (or suitably delegated NOSWG
representatives) will be available to participate in any SCs or
SC/WGs meeting when necessary or required.2.2.1.4. NC3TA Update Process within the NATO Standardisation Programme2.2.1.4. NC3TA Update Process within the NATO Standardisation ProgrammeThe principal linkage between the NC3TA and the wider NATO
Standardisation Programme is provided through the NATO Policy for C3
Interoperability (ref PO(2000)39). In particular, under paragraph 1-10
(Applicability) of the Policy, the statement is made that
"this Policy is applicable to C3 systems,
whether NATO or nationally owned, used by the forces of NATO. The use
of the standards and products in the NIE, at a minimum by the NCSP and
NCOE, is mandatory for all new or substantially modified NATO common
or partially common-funded C3 systems." Within this
Policy, the NATO Interoperability Management Plan (NIMP) describes the
management processes associated with NC3TA application. There is a close
relationship between the NIMP and the NC3TA, which will be
evolved over time and assessed within the update process.2.2.1.5. Co-ordination with the NATO PMOs in NC3TA Update Process2.2.1.5. Co-ordination with the NATO PMOs in NC3TA Update ProcessThe co-ordination with the NATO Programme Management Offices
(PMOs) is primarily realised through the Strategic Commands
representatives to the NOSWG.In addition, the NOSWG POW development takes into account the
requirements of NATO programmes, which is derived from the programme
increment currently under design.2.2.1.6. National Systems Interoperability Co-ordination in NC3TA Update Process2.2.1.6. National Systems Interoperability Co-ordination in NC3TA Update ProcessEach of the national NOSWG representatives is responsible
for:•Providing the NOSWG with the appropriate and timely
inputs with respect to interoperability with national
systems;•Co-ordination of the national position, including
co-ordination with national representatives of other
sub-committees;•Providing the NOSWG with the appropriate technical
information based on the national IT market assessment.2.2.1.7. Dissemination of NC3TA Documents2.2.1.7. Dissemination of NC3TA DocumentsAll NC3TA Volumes will be available both in printed
and electronic from. All volumes are accessible through the NC3A Web
site (http://194.7.79.15/). All NC3TA volumes may also
be requested through the national ISSC/NOSWG representatives.2.2.2. Configuration Management of the NC3TA2.2.2. Configuration Management of the NC3TAConfiguration Management (CM) of the NC3TA is an essential component
of the overall management task, and has been instituted from the time
the NC3B has endorsed version 2 of NC3TA. In this
context, CM will address the maintenance of agreed baselines for each
of the NC3TA volumes and the change control
is invoked through Request For Change Proposal (RFCP) procedure.The CM process requires identification and maintenance of an
appropriate hierarchy of Configuration Items (CIs). Each volume of the
NC3TA is a high level CI, the specific decomposition of which into
subordinate CIs is dependent upon the volume in question (principally
service areas and standards in Volumes 3 and 4, products and segments
in Volume 5). CM of Volumes 1 and 2 does not similarly decompose into
subordinate CIs.2.2.2.1. CM Organisation2.2.2.1. CM OrganisationFor the NC3TA, authority to act as the Configuration Management
Board (CMB) lies with the ISSC on behalf of the NC3Board, since this
is the lowest level at which national endorsement can be given to any
proposed changes to the Technical Architecture contents. The NOSWG
acts as the Configuration Control Board (CCB), to which all
RFCP's must be submitted for evaluation, approval and
inclusion. In conducting this task, the NOSWG will be supported by the
NC3A (in technical and procedural considerations) and in particular
instances by working groups where specific technical advice and
reference may be required. Thus the CM organisation for the NC3TA may
be represented as follows:ISSCCMB for the NC3TA.Responsible for:•National Endorsement of the NC3TA•Reporting to the NC3B•Promulation of the NC3TA throughout NATO•Monitoring and highlighting project elements which are
not in conformance with the NC3TA•Replying to originators as to the
acceptance/modification/rejection of their RFCPsNOSWGCCB for the NC3TA.Responsible for:•Processing Change Requests•Updating and Maintaining the NC3TA
documents•Assessing related technical developments for
inclusion•Co-ordination with NC3Staff, Sub-committees and Working Groups
•Co-ordination with NATO Interoperability
Management Plan (NIMP) WG•Review and evaluate projects compliance
with NC3TA•Technical advice and support•COE implementation/maintenance as
directed•Reporting/recommending new versions to the ISSC
2.2.2.2. Resources2.2.2.2. ResourcesAs described above, the CM organisation is dependent on resource
contributions from NATO and the NATO nations through their participation in the
various committees and working groups involved in the CM process.
This support will typically take the form of reviews and submitting
RFCPs and to exercise the responsibilities of the CMB and
CCB.As NC3TA Custodian, the ISSC will assign responsibility to the
NOSWG to determine, on an annual basis, the overall task requirement
and associated resources necessary for its completion. Tasks that will
be undertaken by national sources will be initially consolidated under
the NOSWG. Those that can be more effectively undertaken by the NC3A
(e.g. specialist technical or procedural support), will be endorsed by
the NOSWG (as Agent for the ISSC) as part of the NC3A Programme of
Work, and funded from NC3B resources.2.2.2.3. Baselines2.2.2.3. BaselinesThe rationale for establishing a formal NC3TA Baseline derives
from the interdependency of all volumes, and the need to maintain
coherence throughout their individual and collective content (this
applies in particular across Volumes 3/4/5, IHB and RD).When a version of the NC3TA is considered updated, i.e., all
applicable RFCP submitted have been actioned, it will be baselined by the NOSWG for
release to the ISSC and recommended for promulgation to NATO. This
Baseline applies to the NC3TA in its entirety (regardless of whether
any particular volume has been subject to RFCP procedure or not since
the previous Baseline was issued) and replaces the previous Baseline
in totality. It signifies a specific point in the update cycle of the
NC3TA (previously described).Appendix D contains a 'What's New in
Volume 1' overview2.2.2.4. Configuration Control Procedures.2.2.2.4. Configuration Control Procedures.The conduct of Configuration Control by the NOSWG will be based
on a meeting schedule as shown in Figure 2.1
at which a list of RFCPs submitted will be reviewed and their
status assessed. On receipt of an RFCP, an acknowledgement in a timely manner
from the NOSWG Secretary, will be sent
to the originator indicating the meeting at which it will be reviewed;
a final decision will be communicated when the matter has been
considered by the appropriate committee. For each RFCP, this status
will be:•Submitted for consideration;•Undergoing review and evaluation;•Returned to originator for additional information/justification•Accepted for inclusion in next Baseline;•Modified•Rejected.The review process may in some cases require submission of
supplementary material. Throughout this process, the Secretary NOSWG
will maintain a formal RFCP status accounting record, which will be
eventually archived for traceability and audit purposes. Generally a
consensus of NOSWG members will be required to effect a change,
although in some circumstances a majority vote will be invoked (which
will be recorded). Chairman NOSWG will be responsible for promulgation
of majority/minority views as appropriate.It is recognised that the release of a new NC3TA Baseline does
not signify completion of all currently submitted RFCP's, but
that, as a result of those that have been included, the NC3TA has been
revised and remains coherent overall. A certification to
this effect will be given by the NOSWG to the ISSC in order that
programme management has sufficient confidence to follow the guidance
contained and utilise all appropriate components.ADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -3. NC3TA FACILITIES AND SERVICES3.1. INTRODUCTION3.1. INTRODUCTIONThe effectiveness of any defined process mainly depends on the
availability of supporting tools to enable their effective
implementation. The NC3TA supports and promotes this
principle.The environment required to support NC3TA management processes,
internal or external, can be broadly broken down into three
components:•Support development and maintenance of
NC3TA;•Support PMs, NATO or national, to help them
develop C3 Systems compliant with the NC3TA;•Testing Control Authority in conjunction with the testing
environment to ensure, in a practical and
demonstrable way, the conformance of designed and implemented C3
Systems to the NC3TA.The NC3TA support environment will make intensive use of
available Information Technology, including Web technology, to improve
effectiveness of the sharing or the exchange of up-to-date information
and allow timely interaction between relevant players.3.2. NC3TA DEVELOPMENT AND MAINTENANCE SUPPORT3.2. NC3TA DEVELOPMENT AND MAINTENANCE SUPPORTDetailed information drawn from the NC3TA project compliance
forms (see NC3TA Volume 2 and the Implementation Handbook)) will need to be properly
stored and configuration managed in order to progressively develop and maintain a
NATO wide technical view.The tasks associated with this compliance information management activity will need to be scoped
for a POW and submitted for contractor support3.3. PROJECT SUPPORT3.3. PROJECT SUPPORTProject support is a continuous centralised function of the
NC3TA external management process that is the basis for ensuring that
project plans optimise both their own target system functionality and
wider NATO interoperability objectives.In addition a Project Manager's Handbook,
outlining appropriate procedural issues to achieve NC3TA compliance
and suggesting mechanisms for standards or product choice, has been
developed and is part of the NC3TA distribution.3.4. TESTING ENVIRONMENT3.4. TESTING ENVIRONMENTAs referenced in the introductory section of this document, the
concept of a NATO Interoperability Environment Testing Infrastructure (NIETI)
is closely associated with
the NIE and NC3TA. NIETI is being developed to ensure the correct
implementation of the NC3TA elements (i.e. NCSP and NCOE) in NATO
owned and national C3 systems as well as to ensure, when required and
possible, the quality of NIE elements, NCSP and NCOE elements in
particular, to meet operational scenarios. Thus NIETI will offer its
contribution to support both internal and external NC3TA management
processes as previously described. It should be noted that
Interoperability is not obtained through a testing process alone, but
more through a strict adherence to the process of development,
configuration management and implementation of interoperability
standards and products. Testing confirms the success of this process
and should be an integral part of all phases of the process and not
limited to a final assessment.ADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -A. REQUEST FOR CHANGE PROPOSAL (RFCP)Guidance NotesIn order to process any RFCP it is important to provide as much
information as possible.Changes to Volume 2 should outline the key
elements of the proposed change(s), references to associated
documentation and description of perceived technology trend (if
appropriate). Changes should only be proposed in areas where a
technology is gaining a broad market acceptance and mature product
base.For Volume 3 requests for new standards will address details
such as a full specification title, description of applicability, and
reference to a Web address or other source. Changes to, or deletion,
of existing component standards will require appropriate support
justification.Under normal circumstances, changes to Volume 4 will
have already been reflected in Volume 3 (e.g. a standard possibly
proposed as maturing from 'emerging' to
'mandatory').Rationale for changes must be adequately
supported with implementation evidence in order to allow the review
process to proceed.Changes to Volume 5 or requests for inclusion of
new products will require ample justification based on technical,
performance, compatibility (e.g. interoperability), and security
criteria.REQUEST FOR CHANGE PROPOSAL for the NC3 TECHNICAL ARCHITECTURENumber: ................Date: .................Requesting Organisation................................................................................................ Point of Contact................................................................................................ Full Address................................................................................................ Tel, fax, email................................................................................................Type of Change:................................................................................................(e.g. update existing standard,................................................................................................add new standard,................................................................................................include product)................................................................................................Request for Change to Vol 1 .. 2
.. 3 .. 4 .. 5 .. Rationale Doc .. Implementation Handbook
..Classification level of the
information in this change request: No Class .. NATO Unclassified
.. NATO Restricted .. NATO
Confidential .. NATO Secret .. (Default will be No Classification)Releaseabilty of the information to: All .. Internet .. Nominated Nations
on request .. Partners .. NATO Nations only ..Version and date:................................................................................................Reason for change Request:................................................................................................(attach supporting text................................................................................................as appropriate)................................................................................................Additional Comments:................................................................................................To be filled in only by updating authoritiesStatus/Date of Approval:................................................................................................Reason Acceptance/Refusal:................................................................................................Change to Vol:1...2...3...4...5...Rationale Doc...Implementation Handbook...Change Reflected in Version:................................................................................................Nature of Change:................................................................................................(attach supporting text as appropriate)................................................................................................Date Returned to Requestor:................................................................................................SEND THIS FORM TO:Secretary NOSWGEmail: iss@hq.nato.int InfoSys SectionTel : 322.707.4271 NATO HQBrussels, BelgiumADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -B. REFERENCES TO NATIONAL COE INITIATIVESTEMPLATE FOR NATIONAL
ANNEX TO NC3TA VOLUME 1Nations are invited to submit information for inclusion in this Appendix.
The format of the Annex will be a brief introductory paragraph explaining the
National Architectural effort followed by more specific information in line with
the guidance template below:Candidates are national projects/systems that have a relationship with
the NC3TA either as a similar Technical Architecture with national mandatory
standards, or as systems that interoperate in a National to NATO context.•Project Title and Point of Contact.•Brief description (1/2-1 page) addressing the project's
relation with the NC3TA or equivalent national standard. Include if appropriate
size of the project in terms of computers and networks and the date of becoming
operational.•Adherence to NC3TA. Standards adopted and possible conflict areas.
Mention products that are compatible or incompatible with the NC3TA Basket of
Products.•Interoperability with NATO C3 Systems. Description of profiles and
testing results.•Lessons learned. Have interoperability problems been encountered and
have they been solved? Are there issues of importance that should be addressed
within the NC3TA?B.1. NETHERLANDSB.1. NETHERLANDSLAN2000 is the Architecture for the Netherlands Defence COE.
LAN2000 is intended to be implemented on roughly 40000 workstations
(partly laptops) and 1400 servers within the Defence community. It
defines standards in many areas, e.g. domain naming, user account
naming, NT account groups. These standards ensure that the several
LAN's can technically and logically interoperate in the Defence
WAN environment. LAN 2000 is currently implemented for almost all
Services in the Netherlands Defence organisation.LAN2000 provides amongst others an implementation of a common
set of agreed software products that are being used Defence wide,
called the "LAN2000 Basis bundle". A mechanism is available
to convert software into "packages", in a way distribution
and installation of both common support applications and mission
applications can be done in a highly controlled and automated
way.The current implementation of LAN2000 is based upon Windows
NT 4.0. Activities have started to develop a new version of the underlying
Operating System. These activies will be handled by a project called MULAN
(Major Update LAN2000). Apart from providing a technical update, MULAN intends to widen
the scope of LAN2000 to the full Defence community.The first implementation of MULAN is expected to be available the second half
of 2003.Both for LAN2000 and MULAN, the intention is to make use of existing concepts,
architectures and design documents already developed for use within NATO.Further information can be found on: http://www.dto.mindef.nl/lan2000.htm.B.2. UNITED KINGDOMB.2. UNITED KINGDOMThe UK has enhanced it's Defence Technical Architecture
with a series of publications designed to allow the development of
coherent interoperable CIS systems, these publications are contained
in the UK Joint Services Publication (JSP) 600 series (available on
the Internet at http://www.dtais.mod.uk/jsp600/default.htm). The UK
Defence Technical Architecture (DTA), JSP 450, contains the MOD
Communication and Information Systems (CIS) policies, standards and
guidelines, which had to be used for all Defence CIS. As the
DTA predated the NC3TA, the NCOE has adopted many concepts from
the DTA. The DTA is no longer being developed and it is the intention
of the UK to use the NC3TA by use of the UK JSP600 series.B.3. UNITED STATESB.3. UNITED STATESUS DOD Joint Technical Architecture (JTA). The DOD JTA mandates
the minimum set of standards and guidelines for the acquisition of all
DOD systems that produce, use, or exchange information. The JTA is
required for use by anyone involved in the management, development, or
acquisition of new or improved systems within DOD. System developers
are required to use the JTA to facilitate the achievement of
interoperability for new and upgraded systems (and the interfaces to
such systems). System integrators are required to use it to foster the
integration of existing and new systems. The standards and guidelines
in the JTA are stable, technically mature, and publicly available. The
JTA is a living document that will continue to evolve with the
technologies, marketplace, and associated standards upon which it is
based. More information on the JTA can be found at: http://www-jta.itsi.disa.mil.DOD Technical Reference Model (TRM). The purpose of the TRM is
to provide a common conceptual framework and define a common
vocabulary so that the diverse Components within DoD can better
co-ordinate acquisition, development, interoperability, and support of
DoD information systems. The TRM is intended to be used by developers,
system architects, and individuals involved in developing systems that
must exchange information or interoperate with other systems. More
information on the TRM can be found at: http://www-trm.itsi.disa.mil.Defense Information Infrastructure Common Operating Environment
(DII COE). The DII COE is the US DoD equivalent to the NATO NCOE. As
the DII COE existed before, the NCOE has been based on the concepts of
the DII COE. The US DII COE is implemented within a larger number of
US Systems. More info on the DII COE can be found at: http://diicoe.disa.mil/coe/.ADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -C. SUMMARY OF MAJOR NATO PROJECTSC.1. BI-STRATEGIC COMMANDS AISC.1. BI-STRATEGIC COMMANDS AISC.1.1. BackgroundC.1.1. BackgroundOver recent years the Strategic Commands' (SC)
operational Command and Control (C2) Information Systems (C2IS)
services have developed along independent paths and to their own
schedules. This has resulted in two main systems: the Automated
Command and Control Information System of Allied Command Europe
(ACE ACCIS) and the Maritime Command and Control Information System
(MCCIS) of Allied Command Atlantic (ACLANT). In addition, a plethora
of operational C2IS services have been fielded throughout NATO,
generally without reference to the achievement of wider systems
coherence or interoperability; many of these now fall in the category
of legacy systems requiring replacement.In order to promote interoperabilty, portability, scalability and cost
effectiveness across the
whole life cycle of AIS and to comply with the relevant Defence Capabilities
Initiative (DCI) action items and the NATO Consultation, Command and Control
Organisation (NC3O) Goals and Objectives, the two SC's have agreed to
achieve architectural convergence and management harmonisation with
respect to all AIS services.C.1.2. ObjectivesC.1.2. ObjectivesThe objectives of the programme are identified below:•To integrate and improve the capabilities currently provided by the
AIS services within ACE and ACLANT and to NATO HQ, in order to achieve effective
and interoperable consultation, command and control, and general administrative
functions suitable for flexible direction and execution of day-to-day operations
within and beyond NATO's Area of Responsibility (AOR).•To merge MIS and C2IS to progressively attain an integrated
Bi-SC AIS.•To facilitate the design and subsequent operation of systems that provide
improved information flow across hierarchical boundaries, including operational
forces, e.g. CJTF-requirements, and that maximise interoperability with national
systems.•To achieve incremental evolution of the Bi-SC AIS functionality in order
to facilitate economies of scale and effectiveness, but with allowances for
specific local system functionality where needed. This is to be achieved, whenever
possible, by promoting solutions/capabilities currently available in only one SC's
AIS as the common solution for the target Bi-SC AIS.C.1.3. IncrementsC.1.3. IncrementsBecause of the size and complexity of this task, the decision was made to
divide the implementation into three increments. ACE Automated Command & Control
Information System (ACE ACCIS) Increment 1 is the current major ACE CIS Programme,
which will provide ACE ACCIS Baseline 1 to be adopted as the Bi-SC AIS Baseline 0.
Increment 1 provides the major Headquarters sites in ACE with a common hardware and
software baseline. Its goal is to provide an ACE-wide, stable foundation of core
capabilities for the other increments to build on.Other parallel projects helping to form the initial Bi-SC AIS Core Capability
are:•The MCCIS AIS Convergence Initiative (MACI) project in SACLANT.
This project is separating out Core Services from the existing Maritime applications
and is implementing those services in the ACE ACCIS architecture and in the ACE
ACCIS Increment 1 timeframe.•The Military Message Handling System (MMHS) or NATO Messaging System
Handling Project (NMS) is a currently authorised project which will provide military
message handing capability to a few commands initially, including SHAPE.
The follow-on NMS project will provide the same service to the remaining commands.Increment 2 will be built on the work done in Increment 1. Through a
combination of projects it will expand the geographic scope of CCIS and provide
for information exchange with a number of national sites concerned with NATO
planning and consultation. Increment 2 will be realised as a Bi-SC effort in
order to facilitate the convergence of ACE ACCIS and MCCIS to a Bi-SC AIS Core
Capability by year 2004 and is embodied in CP 5A0050/9B0020.Increment 3 has been planned to integrate the Functional Area Services (FAS)
across the homogeneous application platform built by the Bi-SC Automated Information
System (AIS.) These FASs, supported by common core products, provide specific
applications to one or more mission areas (e.g., OPS, LOG, and Personnel.) These
are normally provided by a database server and software applications, which run on
either the end-user desktop, or on a separate application server, and render the
requisite data to the end-users and facilitate data transactions such as display
and modification. This increment will be enabled by a specific set of FAS CPs,
which are currently being developed.Figure C.1. Bi-SC AIS Convergence PathC.1.4. System ViewC.1.4. System ViewFigure-2 provides a high-level system view that depicts the Bi-SC AIS
Services Paradigm adopted for the Bi-SC AIS Architectural Framework. It comprises:•the WAN;•a Core Capability containing common services (e.g. core services
and system management services);•specific C2 (e.g. Land C2) and Administrative (e.g. Financial)
services, which are accessed by users via the enabling functionality provided by
the Core Capability.Figure C.2. Bi-SC AIS High Level System ViewThe Wide Area Network is the data
network infrastructure that interconnects the Bi-SC AIS nodes. Its boundary
lies within the WAN gateway facilities (currently access routers). The WAN is in the
network domain, along with other communications services such as video
tele-conferencing and telephony. It is therefore not part of the Core Capability
although it is essential to interconnecting AIS nodes.The Bi-SC AIS Core Capability is the
foundation on which the Bi-SC AIS will be built. As such it will provide the
common services to support the SCs end users' core business. The achievement of
the Bi-SC AIS Core Capability will be the first Bi-SC AIS convergence milestone
and will be the result of the harmonisation and standardisation of the Core
Capability services of the two SCs: i.e. ACE-ACCIS Increment 2 core components and
the ACLANT MCCIS Architectural Convergence Initiative (MACI) core components.
This will include the common implementation of other essential capabilities (e.g.
message handling, document management, etc.).The Functional Area Services, supported
by common core products, provide specific applications to specialist end-users.
These are normally provided by a database server and software applications, which
run on either the end-user desktop, or on a separate application server, and render
the requisite data to the end-users and facilitate data transactions such as
display and modification.C.1.5. Functional RequirementsC.1.5. Functional RequirementsThe Bi-SC AIS configuration is required to provide the AIS services, through
a combination of hardware and software components, which will be fully compatible
with the NCOE element of the evolving NC3TA.Core Services will be installed at every Bi-SC AIS node and will be required
to support all mission areas/organisational elements with general-purpose services.
They will provide common applications for all users and the enabling technologies
such as web-browsing, collaborative tools etc.Interoperability Services will provide information exchange capabilities,
facilitate the co-operative efforts of the different command nodes and enhance the
ability of the SCs to interoperate with nations and external organisations.Security Services will provide confidentiality, integrity, availability,
authentication, access-control, non-repudiation and accountability services across
the entire system.Management Services will provide for integrated system management and support
for both node and Local Area Network (LAN) assets and relevant WAN assets.Functional Area Services (FAS) will provide business-dedicated applications,
databases, and in some cases special interfaces to external systems through secure
gateways. These Services will be required to support a specific mission
area/organisational element and collaborative processes between different mission
areas/organisational elements.Network Services will provide the
variety of communication services required by Static and Deployable HQs and
Augmentation Forces. These will be provided by one integrated WAN plus LANs.C.1.6. Bi-SC and National C2IS InteroperabilityC.1.6. Bi-SC and National C2IS InteroperabilityInteroperability between NATO and national C2IS is of major importance to the
Alliance in order to reach full military effectiveness in the various potential
scenarios to be faced in the future. Although, in the broadest sense it is a diverse
and multi-faceted subject, its two primary aims in the Bi-SC AIS context relate to
ensuring that operational requirements of the two SCs are fully met (principally
through comprehensive data exchange) in static and deployable/mobile HQ
configurations, and that the resultant system is able to interoperate successfully
with national C2IS. The problem is complex when considered across NATO as a
whole, particularly when taking into account NATO common funded and nationally
funded systems. No attempt is made within this Strategy to cover the whole range
of interoperability issues. The focus is on the key issues, which are of a more
immediate nature to the achievement of adequate operational levels of service.C.2. ACCS PROGRAMMEC.2. ACCS PROGRAMMEC.2.1. Air Command and Control System First Level
of Operational Capability (ACCS LOC1)C.2.1. Air Command and Control System First Level
of Operational Capability (ACCS LOC1)With an effective date of contract of Nov 1999, this project comprises under
NACMA's lead the development of the ACCS core software and the system test and
validation facility (STVF) and is complemented by four separate validation
contracts (Belgium, France, Germany and Italy). Contract options include
CLS[1][1]CLS - Contractor Logistic Support,
support to the STVF and replication. In 2002 the project is in the Preliminary
Design Phase in 2002 and is likely to enter service in 2006. When approved,
replication to the European NATO Nations is likely to take place over the period
2007 - 2010.C.2.2. NATO Air Command and Control System
(ACCS LOC1 Capability)C.2.2. NATO Air Command and Control System
(ACCS LOC1 Capability)The ACCS LOC1 project implements automated functions to support the following
air C2 functions:•Force Management (FM) - Activities required to plan, task and manage
the employment of manned and unmanned air vehicles and Surface-to-Air weapons;•Air Mission Control (AMC) - Monitor mission progress, guidance to
aircraft and support to aircraft in distress; SAM control including allocation of
potential targets to subordinate units;•Airspace Management (ASM) - Develop and maintain airspace
structure; in wartime ASM maximises the use of airspace whilst reducing the
risk of fratricide;•Air Traffic Control (ATC) - Coordination with AMC, area
radar control, recovery/departure services, coordinate Civ/Mil traffic
(when authorised); alerting service for SAR;•Surveillance (S) - Management, production and dissemination
of the Recognised Air Picture (RAP); receipt and dissemination of land,
maritime and sub-surface tracks;•C2 Resource Management (C2RM) - Management of sensors,
ACCS entities and communications air operations and includes Allocation,
Deployment, Configuration, Tasking and Monitoring.The ACCS LOC1 project implements also non functional requirements:•an Open System environment;•architectural constraints for portability, expandability,
maintainability and security;•the use of Commercial Off the Shelf (COTS) products and
reuse of fielded software components is preferred over new development.This contract provides in the First Level of Operational Capability, the
development and validation of software for CAOC[2][2]
CAOC - Combined Air Operations Centre, CARS[3][3]
CARS - CAOC Air Control Centre, Recognised Air Picture Production Centre, Sensor
Fusion Post and ARS[4][4]ARS - Air Control Centre
Recognised Air Picture Production Centre, Sensor Fusion Post
that can be reused for developing WOC[5][5]WOC - Wing Operations Centre, SQOC[6][6]SQOC - Squadron Operations Centre
, AOCC[7][7]AOCC - Air Operations Coordination Centre
and SAMOC[8][8]SAMOC - Surface to Air Missile Opeerations Centre
later.ACCS LOC1 is implemented by a joint venture headquartered at Paris, France
and six sub-contractors developing software in a geographically distributed
environment (France, UK, Germany, Denmark, Italy and USA).C.2.3. ACCS ArchitectureC.2.3. ACCS ArchitectureFrom the outset an evolutionary approach was adopted towards the design of
the LOC1 project. Thus entities will be implemented in phases based upon a
common approach and modular design. Static and deployable entities will use the
same core software. The 'Product Line Concept' allows ACCS Entities to be
built from only those components that are required to deliver the required
functionality.The project implements an architecture centric multi-layered
'system-of-systems' design that embraces proven modern commercial
technology (e.g. Java 2 Enterprise Edition, CORBA), fully transparent common
services and allows for integrating multiple frameworks and technologies of reused
software components. An integrated Human Machine Interface (HMI) bringing tasking
and execution application software together is also required. A critical requirement
is that this architecture shall be robust such that future requirements/extensions
(e.g. EAD, COTS technology evolution) can be introduced without major redesign of
the core software product.ADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -D. WHAT'S NEW IN VOLUME 1•New Introduction•Revised consistency process•Architectural templates moved to Volume 2•Revised annex on National Architectural work•Strategic Command and Agency input updated•Abbreviations added•What's New Annex addedADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -E. ABBREVIATIONSABBREVIATION[a]MEANINGC2Command and ControlCISCommunication and Information SystemsCPCapability PackageDCIDefence Capability InitiativeG&OGoals and ObjectivesIOInteroperabilityIORInteroperability requirementJWIDJoint Warrior Interoperability DemonstrationMNCMajor NATO CommandMORMilitary Operational RequirementNC3ONATO C3 OrganisationPCNCEPPolitical Consultation and NATO Civil Emergency PlanningTBCEType "B" Cost EstimateTable E.1. ABBREVIATIONS[a]Abbreviations are in accordance with AAP-15ADatP-34NC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlNC3TA-Vol1-v4.xmlADatP-34NC3TA-Vol1-v4.xmlADatP-34- -- -- -- -F. HARMONIZATION OF NATO AND CCEB TECHNICAL ARCHITECTURESF.1. LIST OF UNDERSTANDINGS BETWEEN NATO AND THE CCEBF.1. LIST OF UNDERSTANDINGS BETWEEN NATO AND THE CCEBReferences:A. NATO Letter AC/322(SC/5)L/144 of 18 October 2000B. CCEB Letter D/CCEB/WS/1/16 of 9 November 2000C. NATO Letter AC/322(SC/5)L/157 of 13 February 2001PurposeThe purpose of this document is to provide an enduring record of the
understandings that have been reached between NATO and the Combined Communications
Electronics Board (CCEB) in regard to the harmonization of the NATO and CCEB
technical architecturesBackgroundAt reference A, NATO (through the ISSC) noted the parallel activities in NATO
and the CCEB to develop a multi-national technical architecture. As this
represented an opportunity to converge on a single technical architecture NATO
extended an invitation to Australia and New Zealand, as non-NATO members of the
CCEB, to participate as non-voting observers in the NATO Open Systems Working Group
(NOSWG) meetings and on-line discussions. NATO (via the ISSC) assured Australia
and New Zealand that their technical contributions would be accorded the same
consideration as all other participants in NOSWG meetings.The CCEB, at reference B, accepted these invitations and confirmed that it
was a CCEB priority to develop a single technical architecture to enhance
interoperability between NATO and CCEB nations. Collaborative work with NATO and
CCEB subject matter experts in early 2001 demonstrated that harmonization of the
relevant sections of the CCEB and NATO technical architectures was achievable.
Further collaborative effort throughout 2001 resulted in a harmonized technical
architecture consisting relevant portions of NCSP Ver 2, ACP140A and CCEB Pub
1007.To ensure that a single technical architecture would recognize the needs of
all CCEB nations, the CCEB sought clarification on Australia and New Zealand
participation in technical architecture development and maintenance. Of
particular note were the equity arrangements and opportunities for Australia and
New Zealand to contribute to and influence future technical architecture
development, and access to all relevant standards and documents referenced in the
NATO technical architecture. The ISSC has assured the CCEB that technical
contributions from Australia and New Zealand will be accorded the same
consideration as those submitted by all other participants at NOSWG meetings at
reference C and that the ISSC will support the release of relevant NATO documents
to Australia and New Zealand, subject to NATO Policy regarding the release of NATO
documents to non-NATO nations and NATO Security Policy. Subsequently the CCEB
confirmed its intention, subject to acceptance of the NATO NCSP Vol 4 version 3 by
all CCEB nations, to adopt it as its technical architecture.The September 2001 NOSWG meeting drafted a List of Understandings to document
agreements and processes that would provide an enduring record for future NOSWG
participants of the background of the technical architecture harmonization
initiative, and the continuing role of Australia and New Zealand (as non-NATO
nations) in this activity.List of UnderstandingsThe following understandings and undertakings have been agreed between NATO
and the CCEB in regard to the harmonization of current and future versions the NATO
and CCEB technical architectures:a.NATO desires that the NC3TA be acceptable to all the CCEB
nations.b.The CCEB intends to adopt NC3TA Volume 4 (NCSP) as the CCEB
technical architecture following its acceptance by the all CCEB member
nations.c.The CCEB desires that the scope of NC3TA Volume 4 (NCSP) be
comparable to ACP140A and the rationale for NCSP standards selection be
detailed in a NATO document able to be referenced in CCEB policy.d.Australia and New Zealand, as non-NATO members of the CCEB, are
invited to participate as observers and their technical contributions will be
accorded the same consideration as those submitted from all other participants in
NOSWG meetings. Being non-NATO nations, Australia and New Zealand acknowledge
that they are not able to vote in NOSWG matters.e.The CCEB will note any variances in CCEB interoperability
standards in the remarks column of the NCSP standards tables with the remark
'For CCEB interoperability the standard is ...'f.If necessary, Australia and New Zealand will develop and
publish national supplements to document national variances or exceptions to
NC3TA NCSP standards. These instances are expected to be rare. Any
nationally approved Australian and New Zealand national supplements to the
NC3TA NCSP will be forwarded to the NOSWG Secretary for formal distribution
to all NATO nations.g.Any Request For Change Proposals (RFCPs) or amendments
proposed to the NC3TA NCSP (Volume 4) by NATO nations will be distributed in
accordance with NATO policy for the release of NATO documents to non-NATO
nations (via email to the maximum extent possible in accordance with NATO
Policy on the use of the Internet) by the NOSWG Secretary to the Australian
and New Zealand representatives to the NOSWG for staffing nationally within
Australia and New Zealand.h.Australia and New Zealand will be provided access (in a
readable electronic format wherever possible) to all standards and documents
listed in the NC3TA NCSP to the maximum extent possible in accordance with
NATO policy for the release of NATO documents to non-NATO nations and NATO
Security Policy. The United Kingdom will sponsor release of the relevant
NATO documents to Australia and New Zealand.i.As necessary, the United Kingdom Mission in NATO will act as
the Point of Contact for distribution of all NC3TA NCSP documents between
NATO and Australia and New Zealand.