| IAW Annex A to ATCCIS WORKING GROUP (AWG) IV-1 Minutes | ||||||||||
| WORKING PAPERS ETC PRODUCED BY AWG FOR THE ATCCIS DEMONSTRATION(S) AND EVALUATION PERIODS | ||||||||||
| No. | Class | Title | Edition | Date | Status hardcopy | Status softcopy | Intended Audience | Remarks | Purpose | Overview/Scope |
| WP 3-1 | NU | Data Naming Procedures for ATCCIS Data Model | 2.0 | Jul-97 | In FC Phase IV in Edition 3.0 dated in Mar-00 | In Edition 2.2 | -Data managers -Data Modellers |
The purpose of this paper is to propose the naming convention that will be adopted to support the ATCCIS Phase III Data Modelling work. Strict rules will be imposed initially, which will be continually reviewed throughout the Phase III programme, and revised if necessary in the light of experience gained during the data modelling exercise. This paper is intended to be utilised by those involved in the ATCCIS Data Modelling exercise and assumes that the reader is familiar with the concepts of ATCCIS, data modelling, and IDEF1X in particular. | The naming convention proposed within this paper is aimed purely at supporting the requirements of the ATCCIS Phase III programme. It is based on the proposal formulated in ATCCIS Phase II and documented in Working Paper 7L. In this paper, the fundamental principles of the Working Paper 7L proposal have been revised to take account of the particular requirements of the Phase III programme, and experience gained within the nations of applying a structured naming convention since the publication of Working Paper 7L. It is not the function or intention of ATCCIS to review and rationalise the various naming proposals currently being proposed by various external agencies throughout the nations. | |
| WP 3-6 | NU | ATCCIS Key Management | 0.6 | Nov-96 | In FC Phase IV in Edition 1.0 dated in Mar-00 | OK | -Data
managers -Data Modellers -Implement. |
Draft | This paper describes a set of rules, which are to lead to unambiguous world-wide usage of keys for all ATCCIS operational and meta data. Whenever a record is created, the key of that record, which consists of ‘id’ and ‘index’ attributes, must be globally unique. The value that the key of a new record gets must not have yet been used elsewhere already. The rules will ensure this. | By the present draft version of this paper, there is a common agreement about the initial strategy for key management in ATCCIS. It is therefore released as an official ATCCIS Working Paper. In addition, a summary of this paper is to be incorporated in ATCCIS Working Paper 3-5 [Ref. 2], which describes ATCCIS Data Management (procedures and organisation). |
| WP 4-1 | NU | ATCCIS Information Resource Dictionary (AIRD). Definition of Structure and Contents | 2.0 | Jun-95 | FC | OK | -Data managers -Data Modellers |
The purpose of this working paper is to define the structure of the ATCCIS Information Resource Dictionary (AIRD). The AIRD structure is specified in this paper through a logical data model known as a "metadata model" (also called "metamodel") for the information to be retained in the AIRD. The AIRD will serve as the data repository referenced in the ATCCIS Phase III Work Plan. | The ATCCIS
Information Resource Dictionary should contain the essential and pertinent
information from the ATCCIS information modelling efforts plus such
additional information that is deemed to be important to ATCCIS conformancy. As such, the AIRD itself will be a database
with its own conceptual schema defining the structure and the content of the
Information Resource Dictionary. The AIRD described in this paper is specified to the level necessary to support the forthcoming ATCCIS Phase III Demonstration |
|
| WP 4-2 | NU | AIRD Management Procedures | 2.0 | Jun-95 | FC | OK | -Data managers -Data Modellers |
This Working Paper describes the procedures that should be followed when managing the AIRD. It describes how to populate and maintain the AIRD. This first chapter provides a global introduction to the AIRD. It concludes with an overview of the remaining document. | The ATCCIS Information Resource Dictionary (AIRD) is a repository of information about the data requirements and recommendations for common meanings and relationships that are deemed essential by the ATCCIS PWG for achieving NIPD Level 5 of System Interconnection among the future command and control information systems of the nations. As a minimum, such interconnection must ensure the exchange of information (with user-imposed constraints) that preserves meanings and relationships (a concept characterised in the ATCCIS Architecture as “basic interoperability”). | |
| WP 4-3 | NU | Data Repository User Manual | 1.0 | Sep-96 | FC | In Final Draft jun-96 | -Data managers -Data Modellers |
The purpose of this working paper is to provide guidance to all possible users of the ATCCIS Information Resource Dictionary (AIRD). It is to explain how the AIRD meta database can be utilised by means of the tool ADEF (Automated Data Element Finder), which provides the functionality necessary for viewing and, in special cases, input of meta data about the ATCCIS information analysis results. | The ATCCIS Information Resource Dictionary (AIRD) contains the essential information from the ATCCIS information modelling efforts plus such additional information that is deemed to be important to ATCCIS conformancy. The AIRD itself is a database with its own conceptual schema. | |
| WP 5-2 | NU | Battlefield Generic Hub Data Model Level 1 + SFAs | 1.0 | Apr-93 | FC Includes Fire support, Communication electronics, Barriers and personnel |
OK Includes Fire support and Communication electronics |
-Data Modellers -Implement. |
The purpose of this working paper is to provide guidance to all possible users of the ATCCIS Information Resource Dictionary (AIRD). It is to explain how the AIRD meta database can be utilised by means of the tool ADEF (Automated Data Element Finder), which provides the functionality necessary for viewing and, in special cases, input of meta data about the ATCCIS information analysis results. | The scope of the analysis carried out in the production of the ATCCIS Data Model, is specifically directed at producing a corporate view of the data, together with a relational database schema, for use in the ATCCIS demonstration. To that end it is based on the information requirements of a multinational division headquarters. | |
| WP 5-3 | NU | Generic Hub Level 2 for 1995 Demonstration | 1.0 | Aug-94 | FC | OK | -Data Modellers -Implement. |
WP 5-3 aims
to document the Generic Hub Level 2 in order to provide the following: a. A description of the data that all subfunctional areas have in common. The overall ATCCIS data model contains all ATCCIS relevant data elements, abstracted in a well-structured and normalised way, unambiguously reflecting their semantic meaning. b. A base document against which amendments to the model can be referenced and around which discussions can be based. The 5-3 working paper is the initial configuration management tool for the ATCCIS Data Model. c. Implementation of the naming conventions laid out and detailed in WP 3-1, Data Naming Procedures for the ATCCIS Data Model. d. A core upon which nations can base their own modelling efforts of chosen subfunctional areas and onto which specific subfunctional area models can be attached or “hung.” e. A basic document that nations can use to present and validate subfunctional ATCCIS data model views with their own specialist organisations. |
The scope of the analysis carried out in the development of the Generic Hub Level 2 Data Model is specifically directed at producing a corporate view of the data that can serve as the basis for the development of the integrated ATCCIS Data Model as well as the ATCCIS Demonstration Data Model. To that end, it is based on the information requirements of a multinational headquarters at brigade, division, or corps echelon level. Furthermore, the data model tends to limit its scope primarily by adopting the viewpoint of the operations planning and execution elements of a tactical headquarters. | |
| WP 5-4 | NU | Guidance for the Physical Implementation of the Demo DB | 0.4 | jun-95 | UKN | OK | -Data Modellers -Implement. |
Draft | WP 5-4 aims
to document the demonstration database physical schema in order to provide
the following: a. Configuration control of all data specifications supporting the demonstration b. The data model for the demonstration database specified in accordance with the Integrated Computer-Aided Manufacturing (ICAM) Definition (IDEF) language and methodology c. Metadata for the physical schemata d. Domain values for all coded (enumerated) domains e. Configuration management of the values of identifiers and indexes, to include allocation of blocks of identifiers to nations and, where appropriate, to nodes identified by the nations for participation in the demonstration (the values of these attributes must be unique world wide, so configuration management is needed to ensure that no value is introduced twice for two different instances) f. Rules and guidance for physical schemata to support consistent meaning of data g. Traceability of the physical schemata to the baseline data model (WP 5-3) h. Traceability to and interaction of data requirements underlying the evolving functional specifications for the demonstration scenarios and scripts i. Reference to the AIRD for definitions and other metadata underlying the demonstration physical schemata. |
This
document is one of several specifications required to define the ATCCIS
demonstration database structures (schemata).
It is therefore specifically aimed at supporting the
demonstration. The basis for the demonstration physical schemata is the ATCCIS Battlefield Generic Hub Level 2 Data Model (WP 5-3). This document includes modifications to WP 5-3 that are required to support the demonstration. Most of the modifications are those required to technically align the AIRD with the demonstration physical schema (e.g., adoption of abbreviated entity names for which the names provided in the data model exceed the maximum name length agreed for use in the AIRD). Substantive changes will only be included when the implementing nations agree the changes and needed and can be accommodated in time for the demonstration. |
| WP 5-6 | NU | Implementation Guidance for Physical Databases based on GH3 | 1.0 | Sep-97 | In FC Phase IV in Edition 2.0 dated in Nov-98 | OK in Ed.1.0 dated in Nov-97 | -Data Modellers -Implement. |
Draft | WP 5-6 aims
to document the physical schemata for ATCCIS-conformant databases in order to
provide the following: a. Configuration control of the data specifications. b. The physical data model specified in accordance with the Integrated Definition (IDEF) for Information Modelling [Ref. 11]. c. Meta data for the physical schemata, which include for each attribute: (1) Generic data types: integer or real numeric (NUMBER), fixed-length alphanumeric (CHAR), and variable-length alphanumeric (VARCHAR) (2) Number of positions (i.e., length of each valid domain value) and, in the case of a real numeric data type, the number of decimal places (3) Whether a null value is permitted (NULL) or not (NOT NULL). d. Domain values (including physical abbreviations) for all coded (enumerated) domains. e. Rules and guidance for physical schemata to support consistent meaning of data. f. Traceability of the physical schemata to the baseline data model (WP 5-5). g. Reference to the AIRD for definitions and other meta data underlying the physical schemata |
This document is one of several specifications required to define the ATCCIS database structures (schemata). It is specifically aimed at supporting the implementation of ATCCIS-conformant systems. |
| WP 5-7 | NU | ATCCIS Generic Hub Overview | 1.0 | Sep-97 | FC | OK | -Data Modellers -Implement. -General |
WP 5-7 provides a broad overview of the model structure and functionality while omitting a significant part of the technical detail that is inherent in explicit data models and is needed for further evolution of the model and its application in systems development. | The scope of the development of the Generic Hub 3 Data Model is the multinational information exchange requirements of a multinational or national army headquarters at brigade, division, or corps levels for operations planning and execution. | |
| WP 5-8 | NU | ATCCIS Sub Functional Area Data Models | ? | ? | UKN | UKN | Mentioned in the minutes but without edition and date. | |||
| WP 5-9 | NU | ATCCIS GH3 Interaction Analysis | 0.8 | Apr-98 | UKN | OK | -Data Modellers -Procedur. -Implement. |
Draft | The purpose
of this WP is to provide implementors of the applications developed for the
evaluation period with examples for introducing information into the database
structure according to GH3, specified in WP 5-5 Draft 1-1. The interaction analysis is based on the Review Events detailed in WP 15-4 and on GH3 draft version 1.0. The model will be further improved hence this paper should not be used for any version of the model other than that specified above. |
Rather than specifying the full details of which area of the model is to used for the information in each event, WP 5-9 concentrates on providing examples that are applicable over multiple events. For example, there is a need to specify Control Features (FLOT, FLET, FEBA etc.) in a number of events but there will only be one example in this paper. |
| WP 5-10 | NU | ADatP-3 Mapping | 0.75 | Apr-98 | In FC Phase IV in Draft 1.1 dated in Jan-99 | OK | -Data Modellers -Procedur. -Implement. |
Draft | The purpose
of this document is to describe general and specific rules that will have to
be taken into consideration when mapping ATCCIS operational (battlefield)
information to ADatP-3 messages and vice versa. The proposed Mapping Rules are based on the comparison of the ATCCIS GH3 (Draft 1.1) [Ref. ATCCIS WP 5-5 1997] and ADatP-3, Baseline 8.1 [Ref. ADatP-3 1992]. |
Considering
the volume of ADatP-3, the spectrum of the mapping efforts has been reduced
to some significant messages. The
present document covers the following three ADatP-3 Message Text Formats
(MTFs): 1. Enemy Situation Report (ENEMY SITREP) 2. Own Land Forces Situation and Presence Report (OWN SITREP) 3. Commanders Logistic Report (CDRLOGREP) |
| WP 12-1B | NU | ATCCIS
Demostration team objectives, organization and terms of reference |
0.7 | Mar-95 | UKN | In
draft but with different title 'ATCCIS Demonstration Team Objectives, Organization and Terms of Reference' |
-Test -Implement. |
Mentioned in the minutes as ATCCIS Demonstration Replication Mechanism Test Plan but without edition and date. | The ADT planning will cover all the activities and products that are the responsibility of the ADT. In addition it will include the products needed for the ATCCIS Study or for the demonstrations that are the responsibility of other ATCCIS Organisations. | The team structure, organisation and terms of reference specified in this plan will change to take account of changes in the current manning and skills of the team, and the requirements of the ATCCIS Study. The day -to -day team structure and responsibilities will be specified by the Demonstration Director and documented in the ATCCIS Support Office - Office Procedures [Ref 0]. This document will include the day -to -day procedures of the ADT, define the ADT filing system and contain background information such as ATCCIS acronyms. |
| WP 12-2 | NU | ATCCIS Demonstration Architecture Specification | 1.0 | Sep-94 | FC | OK | -Engineer -Test -Implement. |
Edition 1 is dated in sep 94 instead of dec 94 as stated in the minutes. | This paper describes an architecture to support the system concept of an Army tactical C2 information system as it has been agreed for the ATCCIS Demonstration. The primary purpose is to ensure that the required information exchange requirements are fulfilled by the participating systems and that NATO Level 5 System Interconnection is achieved. The architecture should also support the second ATCCIS theme of demonstrating the ability to implement such systems at lower cost than hitherto | In this paper the architecture will be described in functional terms only, and standards and profiles will be described with no reference to their actual implementation, which remains a national responsibility. The ATCCIS architecture as it is defined in this document does not provide a complete justification of architectural choices derived from an exhaustive analysis of all aspects of possible operational system requirements. Such criteria as survivability, configurability, performance and requirement traceability have not been taken into account, and will not be supported in the demonstration. In that sense, this paper is not a design level document. In a real system, it is expected that they would be achieved by a combination of the implementation of each system and the configuration of the systems, in particular the duplication by replication of data to additional sites to provide a survivability function. |
| WP 12-2.2 | NU | Demonstration Architecture Replication Mechanism Specification | 1.0 | Sep-94 | FC in the same folder than the WP12.2 |
OK | -Technical -Implement. |
This document is the specification for the ATCCIS Replication Mechanism (ARM) for the 1995 ATCCIS Demonstration. It is intended to be used as a stand-alone document, and therefore contains some tutorial material about ATCCIS and the positioning of the ARM in the overall ATCCIS architecture in order to provide a sufficient background for potential users of the document not to need further working papers from the ATCCIS PWG in order to enable an adequate appreciation of the subject matter to be attained. | From an operational point of view, military personnel operating a tactical headquarters carry out activities in the context of a task within their functional area. For example, G3, G2, Arty, Engr etc. To be able to perform that task, they need information from a variety of sources. The information that is created as a result of the work will in its turn serve as an input to the work of others. It is the function of the ARM to replicate data that is created or changed as a result of work performed in headquarters to those who have expressed an interest in that data, and have been authorised to receive it. It is not the function of the ARM to manage or map the Information Exchange Requirements, the user addresses or the network. | |
| WP 12-3A | NU | X.400 Interoperability & Integration Test Specification | 1.9 | Aug-94 | UKN | OK in Draft 2.2.1 | -Technical -Implement. |
Draft | This document specifies a set of tests to help ensure that the X.400 Message Handling System (MHS) of the Army Tactical Command and Control Information System (ATCCIS) Demonstrator testbed will interoperate and function as required to meet overall demonstration objectives. This includes establishing a representative specification of the Demonstrator target configuration in terms of X.400 names, addresses, routes, and a conducting a series of specific, formal interoperability and stress tests to ensure that an agreed common set of functionality exists and that the implementations are robust. The ATCCIS Demonstrator will contain multiple instances of national ATCCIS systems placed in different headquarters, modelled after national contributions to the ACE Rapid Reaction Corps (ARRC) and its Divisions and Brigades. The envisioned number of X.400 sub-systems and corresponding databases in the ATCCIS Demonstrator is approximately 15. This represents a medium-sized X.400 network. Validation of the required routing and relaying capabilities of each type of system, and validation of the tables and structures collectively defining the Demonstrator target configuration, are critical steps in establishing an interoperable ATCCIS Demonstrator information exchange infrastructure. | Testing OSI products is a well established discipline. It consists of three typical stages: conformance testing, interoperability testing and performance/stress testing. The scope of the tests defined here is mainly interoperability tests, with some performance/stress tests added. The interoperability tests defined are not exhaustive tests of any of the profile implementations. Rather they are practically oriented tests to ensure that the X.400 backbone chosen is capable of supporting X.400 dependent ATCCIS Demonstrator applications (i.e. database replication) and planned operationally oriented e-mail demonstrations. This includes final tests on the full target configuration |
| WP 12-4 | NU | Operational Scenario for ATCCIS Phase III Demonstration | 1.0 | Jan-95 | OK | OK | -Technical -Implement. |
Draft | This
document specifies a set of tests to help ensure that the X.400 Message
Handling System (MHS) of the Army Tactical Command and Control Information
System (ATCCIS) Demonstrator testbed will interoperate and function as
required to meet overall demonstration objectives. This includes establishing a representative
specification of the Demonstrator target configuration in terms of X.400
names, addresses, routes, and a conducting a series of specific, formal
interoperability and stress tests to ensure that an agreed common set of
functionality exists and that the implementations are robust. The ATCCIS Demonstrator will contain
multiple instances of national ATCCIS systems placed in different
headquarters, modelled after national contributions to the ACE Rapid Reaction
Corps (ARRC) and its Divisions and Brigades.
The envisioned number of X.400 sub-systems and corresponding databases
in the ATCCIS Demonstrator is approximately 15. This represents a medium-sized X.400
network. Validation of the required
routing and relaying capabilities of each type of system, and validation of the tables and structures collectively defining the Demonstrator target configuration, are critical steps in establishing an interoperable ATCCIS Demonstrator information exchange infrastructure. |
Testing OSI products is a well established discipline. It consists of three typical stages: conformance testing, interoperability testing and performance/stress testing. The scope of the tests defined here is mainly interoperability tests, with some performance/stress tests added. The interoperability tests defined are not exhaustive tests of any of the profile implementations. Rather they are practically oriented tests to ensure that the X.400 backbone chosen is capable of supporting X.400 dependent ATCCIS Demonstrator applications (i.e. database replication) and planned operationally oriented e-mail demonstrations. This includes final tests on the full target configuration |
| WP 12-6 | NU | Prototype Replication Mechanism FR & US Report | 1.0 | Mar-96 | UKN | OK | -Technical -Engineer. |
The purpose of this document is to share information of direct interest to future ARM development efforts and to the evolution of the ATCCIS architecture specification. | Both the French and US prototype ARM implementations were developed in accordance with an agreed-upon draft standard, described in ATCCIS WP12-2.2. However, the referenced working paper contains several deficiencies that would preclude its use in operational Command and Control Information Systems (CCISs). The WP 14 series of ATCCIS architecture documents (forthcoming) are expected to supersede WP12-2.2 and promise a number of improvements. | |
| WP 12-9 | NU | Command and Staff Information Exchange Requirements | 0.1 | May-96 | UKN | OK | -Operat. -Engineer |
This Working Paper supports the development of the 1997 ATCCIS Demonstration Plan. It is designed to specify a range of information exchange requirements (IERs) from the perspective of the commander as well as the user/operator. Further, it provides the operational basis for the development of specific technically-oriented Information Exchange Contracts that will be implemented in the ATCCIS Replication Mechanism | This working paper specifies a series of combat-related types of information that focus on the IERs of a NATO commander (e.g., corps, division, brigade) and the detailed information needs of the supporting staff. Each type is identified by means of a short title together with a verbal description of the information type. Information exchanges pertinent to the commander as well as data exchanges pertinent to the staff are identified herein. It is assumed that the NATO Corps and its subordinate formations (to brigade level) are supported by ATCCIS-conformant systems, thus permitting event-oriented updates to the commonly-shared database to be accomplished seamlessly and in near-real time. | |
| WP 12-10 | NU | Functional Requirements: The 1997 Demonstration | 0.5 | May-96 | FC | OK | -Operat. -Engineer -Test |
The aim of this paper is to describe, in user terms, the minimum set of C2 functions that will be required. These are based on the technical objectives that have been agreed and are suitable for all likely scenarios | One of the principle concepts of ATCCIS is that interoperability should be achieved with the minimum of constraints on system designers ability to meet national procurement, procedural and policy requirements. Any ATCCIS demonstration will need, therefore, to show that the participating systems are indeed different. It might appear that much of this paper, by requiring a degree of uniformity in the displays, runs counter to this requirement. It is argued, however, that any applications, whatever their internal design, carrying out similar functions will tend to have similar displays. Freedom in design is, therefore, better demonstrated by diversity in architecture, components and range of applications rather than a forced divergence in the on screen displays of applications performing the same tasks. | |
| WP 13-1 | NU | Demonstration Test Report | ? | ? | UKN | UKN | -All | Mentioned in the minutes but without edition and date. | ||
| WP 13-1A | NU | Demonstration X.400 Test Report | ? | ? | UKN | UKN | -All | Mentioned in the minutes but without edition and date. | ||
| WP 14-1 | NU | ARM Requirements (operational and high-level functional) | 1.0 | Sep-95 | FC | OK | -Operat -Engineer |
The purpose of this paper is to specify the agreed operational requirements for the method (not the contents) of information exchange in an ATCCIS environment and to specify the high-level ARM requirements that relate directly to system interconnection. | The requirements in WP 14-1 and the forthcoming specification of WP 14-3 will, therefore, not cover all of the requirements of operational systems (e.g., robustness, availability, survivability, and security). They are aimed at supporting automatic database-to-database replication for the ATCCIS proof-of-concept demonstration in a laboratory environment, while taking into account some of the constraints that apply in an operational environment. | |
| WP 14-2 | NU | ARM Concepts and Models | 2.0 | Sep-97 | In FC Phase IV in Draft 2.1 dated in Mar-98 | OK | -Engineer -Technical |
Draft | The purpose of this paper is to define the concepts of the ARM and their relationships, and to discuss the models that will form the context for stating the specification. | This document contains material on both concepts and models that will ultimately be national implementation issues. This apparent redundancy is necessary to put the ARM in perspective, to define the relations, and to decide the exact boundaries and interfaces between national and international issues. When required, national functionality will be explicitly identified. |
| WP 14-3 | NU | ARM Specification (Initial Spec for Experimentation and Evaluation) | 2.0 | Jul-97 | In FC Phase IV in Ed. 3.0.a dated in Jun-00 | OK | -Technical -Implement. |
Draft | The purpose of this paper is to define the specification of the ARM, with as background WP 14-1 and WP 14-2, and guidance for implementation teams in WP 14-4. | This document contains the specification of the ARM for ATCCIS proof-of-principle evaluation. The specification is a description of the agreement of the ATCCIS Permanent Working Group on what is required to be implemented when designing an ARM to guarantee interoperability on automatic data exchange within the ATCCIS concept. |
| WP 14-3A | NU | ARM Specification Change Control | 1.0 | Nov-96 | UKN | OK | -Technical -Implement. |
The purpose of this paper is to identify each change made to the baseline specification issued as Edition 0.5 of WP 14-3 during its development and promulgation as Edition 1.0 of WP 14-3. Originally, separate tables were kept for the changes agreed at each meeting of the Permanent Working Group’s (PWG’s) Architecture Subgroup. These have now all been integrated into a single table to made identification of the changes as convenient as possible. | Chapter 2 provides the complete list of changes made to Edition 0.5 of WP 14-3 in developing Edition 1.0 of that document. | |
| WP 14-4 | NU | ARM Implementation Guidance | 0.6 | Jul-97 | FC in draft 0.52 date in Apr-97 | OK | -Technical -Implement. |
Draft | The purpose of this paper is to define common interpretations to the specification of the ARM in WP 14-3, with as background WP 14-1 and WP 14-2. | This document contains the implementation agreements associated with the concepts and specification of the ARM for ATCCIS proof-of-principle evaluation. The specification is a description of the agreements of the ATCCIS Permanent Working Group on what is required to be implemented when designing an ARM to guarantee interoperability on automatic data exchange within the ATCCIS concept. |
| WP 14-5 | NU | ARM Pre-Evaluation Test Specification | 1.0 | Oct-96 | In FC Phase IV in Draft 1.4 dated in Nov-98 | In Edition 1.0 but dated in Jan-97 | -Technical -Test -Implement. |
The purpose
of this paper is to define the technical tests that will be run for the ARM
in order to prepare for the 1996-1997 period of experimentation and
evaluation for Phase III. It is
planned to address the following points: a. Standard test installation b. Association Manager tests (1) Full protocol implementation tests (2) Point-to-point ARM connection tests (3) Full ARM network connection test (4) Stress tests c. Replication Manager tests d. Application tests. |
This document contains the implementation agreements associated with testing the features of the ARM. | |
| WP 14-5A | NU | ARM Conformance Test Specification - Protocol Handler | 0.6 | Nov-96 | FC in draft 0.5 dated in Oct-96 | OK | -Technical -Test -Implement. |
Draft | The purpose
of this paper is to define the technical test that will be run for the ARM in
order to prepare for the 1996-1997 period of experimentation and evaluation
for Phase III. It is planned to
address the following points: a. Standard test installation. b. Association Manager tests (1) Full protocol implementation tests. (2) Point to point ARM connection tests. (3) Full ARM network connection test. (4) Stress tests. c. Replication Manager tests d. Application tests |
This paper covers chapter 2 and 3 of the WP 14-5. |
| WP 15-1 | NU | ATCCIS Phase III Evaluation Overview | 1.0 | Jul-96 | FC | OK | -Test | Draft | The purpose of this document is to provide an overview of the objectives, organisation and controls of the ATCCIS Phase 3 Evaluation Phase | This document contains the objectives of the evaluation phase together with the evaluation documentation structure and the additional procedures. |
| WP 15-2 | NU | ATCCIS Phase III - Evaluation Specification | 0.75 | Apr-97 | FC in draft 0.7 | OK | -Engineer -Test |
Draft | The purpose of this document is to specify what the evaluation period should achieve | This paper
contains the requirements of the evaluation phase of the Phase III of the
ATCCIS Study. It covers: a. the information to be gathered b. the questions to be answered c. any conditions or additional information required to specify the evaluation period. |
| WP 15-3 | NU | ATCCIS Phase III - Evaluation Reports | ? | ? | In FC Phase IV in Edition 1.0 dated in Feb-98 | In Edition 1.0 dated in Feb-98 | -All | The purpose of this document is to provide the results of the three Evaluation Cycles that took place during ATCCIS Phase III. | This paper
contains the results of the Evaluation Program in an analysed fashion. The results of each of the three evaluation
cycles will not be individually addressed.
Only the analysed, consolidated results of each of the subsets of the
programme, i.e., the ATCCIS Replication Mechanism (ARM), the Generic Hub 3
data model, and data management rules) will be incorporated herein. a. Each of the three major subsets (ARM, data model and data management rules) will be covered in a separate chapter. b. Network load and bandwidth conservation techniques will be discussed in Chapter 6. c. The Nations were invited to document their lessons learned and recommendations in Chapter 9, if not accommodated elsewhere in the document. d. Forms used during the execution of Evaluation Program are contained in the annexes as a record of tools used. e. A matrix correlating evaluation requirements from WP 15-2 to those items actually evaluated in the program is contained in Annex E. |
|
| WP 15-4 | NU | ATCCIS Phase III Evaluation Programme | 0.97 | Apr-97 | FC in Draft 0.98 dated in Jul-97 | In Draft 0.98 dated in Jul-97 | -Test | Draft | The purpose of this document is to describe the evaluation events that will be run, identify the data required to support the evaluation, specify the minimum set of metrics to be recorded and specify the responsibilities for its production. | This document covers the execution of the evaluation activities associated with the ATCCIS Phase III Programme Review. |
| ATCCIS PHASE III PRODUCTS | ||||||||||
| No. | Class | Title | Edition | Date | Status hardcopy | Status softcopy | Remarks | Purpose | Overview/Scope | |
| WP 3-5 | NU | ATCCIS Data Management | 1.0 | Sep-97 | In FC Phase IV in Edition 1.0 dated in Nov-97 | In Edition 1.0 dated in Nov-97 | -Data managers -Data modellers |
Draft | The purpose
of this working paper is to describe the data management issues that must be
addressed if the ATCCIS concepts for Level 5 interconnection are to live
beyond the end of the ATCCIS study programme. The paper provides a high-level view of ATCCIS Data Management as part of the final ATCCIS Conformance Specification. |
There are
two distinct data management aspects which must be considered in terms of the
successful implementation of a data management policy in support of any
organisation or group of organisations. These are: a. the organisational framework to support data management in a multi-national context; b. the supporting technical procedures and capabilities. For the effective establishment and operation of a data management policy the technical aspects must be defined in terms of the Organisational Framework in which they will be operated. The Phase III data management work has defined a baseline of understanding in terms of: a. a structured naming convention for the attributes of the generic data model; b. the definition of a dictionary structure and supporting functionality to meet the shorter term requirements of the demonstration; c. the population and maintenance of the dictionary in support of the demonstration; d. management and allocation of Data Identification Keys; e. guidance for Physical Implementation of ATCCIS conformant databases. |
| WP 5-5 | NU | ATCCIS Generic Hub 3 Data Model Specification | 2.0 | Sep-97 | FC | OK | -Data Modellers -Implemen. |
WP 5-5 aims
to document the Generic Hub 3 in order to provide the following: a. A description of the data that all subfunctional areas have in common. The overall ATCCIS data model contains all ATCCIS relevant data elements, abstracted in a well-structured and normalised way, unambiguously reflecting their semantic meaning. b. A base document against which amendments to the model can be referenced and around which discussions can be based. Working Paper 5-5 is the configuration management tool for the ATCCIS Data Model. c. Implementation of the naming conventions laid out and detailed in WP 3-1, Data Naming Procedures for the ATCCIS Data Model [Ref. ATCCIS WP 3-1 1995]. d. A core upon which nations can base their own modelling efforts of chosen subfunctional areas and onto which specific subfunctional area models can be attached or “hung.” e. A basic document that nations can use to present and validate subfunctional ATCCIS data model views with their own specialist organisations. |
The scope of the analysis carried out in the development of the Generic Hub 3 Data Model is principally directed at producing a corporate view of the data that reflects the multinational information exchange requirements of a multinational or national army headquarters at brigade, division, or corps levels. Furthermore, the data model tends to focus its scope primarily on the information requirements that support the operations planning and execution activities of a military headquarters. | |
| WP 8-4 | NU | The ATCCIS Standards & Conformance Specification | 0.05 | ? | UKN | In Draft 0.3 dated in Sep-97, title Preliminary ATCCIS Engineering Specification for NIPD Level 5 of System Interconnection | -Generic | Draft | This
document should be the first document of the ATCCIS set to be read. It introduces the methodology used during the ATCCIS study, and presents all necessary information for the specification of ATCCIS conformant systems. It introduces the more detailed documents. It represents, with its related documents, the preliminary engineering specification for conformant ATCCIS systems. |
This
document will evolve throughout the study. It supersedes some earlier documents and refers to others. The status of all ATCCIS various documents is recorded in this document. |
| BASELINE DOCUMENTATION | ||||||||||
| No. | Class | Title | Edition | Date | Status hardcopy | Status softcopy | Remarks | Purpose | Overview/Scope | |
| WP 8-1 | NU | Technical Standards for CCISs (Phase II WP25) | 4.0 | Feb-94 | In FC as WP25 | Title "TECHNICAL STANDARDS FOR COMMAND AND CONTROL INFORMATION SYSTEMS (CCISs) AND INFORMATION TECHNOLOGY" WP25 | -Engineer | Draft | The purpose
of this paper is to identify the technical standards that are applicable to
automated information systems (AISs), including CCISs. These systems are defined to be a
combination of information, computers, and telecommunications resources and
other information technology, together with personnel resources, that
collect, record, process, store, communicate, retrieve, and display
information [Ref. DoD 7920.2 1990] This paper identifies standards that can be used to define implementations of information systems. In this paper, existing and planned standards appropriate to the 11 service areas common to most AISs are surveyed to the level of detail necessary to confirm a reasonable basis for the future support of the CCIS requirements. Relevant standards are identified, but no recommendations for selecting standards are considered. Gaps in current and planned standards coverage, which may require some developmental effort, are identified and are being passed to the appropriate standards defining bodies, including those within NATO. This document also offers guidance in ensuring adequate coverage by the set of standards employed at the time of implementation. |
This
working paper presents information and analyses that are intended to support
defense AISs, with particular emphasis on the exchange of data that preserves
the meaning and relationships of the data exchanged (termed “basic
interoperability”). This paper contains information on existing and planned international, voluntary, government, and de facto standards that promote interoperability and portability, ensure flexibility and growth potential, and allow for technology insertion through use of commercial off-the-shelf (COTS) products and nondevelopmental items (NDIs). The paper identifies relevant standards and gaps in current and planned standards coverage that may require development effort. It does not, however, provide a detailed evaluation of the standards, but instead focuses on standards activities leading to future standards as well as the current issues surrounding these activities. This paper provides a broad overview of the existing and developing technical standards applicable to AISs, to include automated CCISs. Very little of the work is specific to tactical CCISs. |
| - | NU | Phase III Work Plan | 1.0 | Dec-93 | UKN | OK | In Ed. 2.0 | |||
| - | NU | Phase III Project Brief | 1.0 | Dec-93 | UKN | UKN | ||||
| - | NU | Phase III Final Report | 1.0 | Mar-98 | OK | OK | ||||