Home
NATO CALS Handbook Home
NCH Section 1
NCH Section 2
NCH Section 3
NCH Section 4
NCH Section 5
NCH Section 6
NCH Section 7
NCH Section 8
NCH Section 9
NCH Section 10

 
CITIS DEVELOPMENT


CITIS Strategy

CITIS Program-Specific Working Data Repositories

CITIS and Suppliers/Subcontractors

Data Availability Factors

Acceptance of Data Delivered via CITIS

Hardware, Software, and Networks

Operating System Considerations

File Format Considerations

Neutral Data File Options

Hardware and Telecommunications Options

Infrastructure Changes


The primary requirement for creating a successful CITIS is preliminary planning. The contractor and the NATO/NATO nations must discuss and agree upon a large number of issues before the CITIS development is begun. Both sides must understand exactly which functions are required and how the NATO/NATO nations intends to utilize them.

They must discuss the hardware, software, and networks that will be used, how the CITIS should handle data in different formats, and how the contractor should handle major changes in the NATO/NATO nations's computer infrastructure. The contractor also needs to decide, with the help of the NATO/NATO nations, how and to what extent to include supplier/subcontractor data and what type of data repository method makes the most sense for the program.

Creation of a successful CITIS requires continuous communication between the CITIS developers and the CITIS users. Otherwise, the developers may create a system that satisfies the requirements, butdoesn't meet the user's actual needs. This is especially a problem if the requirements are not well defined in the contract.

CITIS Strategy

During the planning phase of the CITIS development process, contractors must determine their strategy in terms of the location/distribution of the program-specific data repository, the extent to which their suppliers/subcontractors will be included in the CITIS, and CITIS data availability.

CITIS Program-Specific Working Data Repositories

A major decision that must be made early in the planning process is where the data will reside. This decision does not have to be made prior to solicitation release. If the NATO/NATO nations has already decided on the form of its program-specific data repository, it should be specified in the SOW, but if not, the contractor should propose a solution after contract award in the CALSIP and/or the System Design Document. The main options for program-specific data repository strategies include:

  • Option 1: database repository resides with the prime contractor as a single physical integrated database.

    It's the simplest option to implement, with all data residing in a single database at a single location. However, this option could result in extensive duplication of data, since data is copied from wherever it originated and loaded into the database. Another potential drawback to this method is reduced accuracy-timeliness of data, since physical copies of updated information must be sent to and loaded into the main database.

  • Option 2: database repository resides with the prime in the form of distributed multiple databases with a navigator.

    It allows for distributed databases within the prime contractor that are accessed via a navigation system. With this option, each functional area (e.g., logistics, engineering, technical publications, etc.) maintains its own database and data, which is accessible by the CITIS users through the central navigator. There is no single physical database with option 2. This option is an improvement over the first option because it significantly reduces theamount of redundant data within the databases. It also improves data accuracy through the timeliness of incorporation of data updates into the database. The navigator system will simply be a pointer to the location where each particular piece of data is stored. Supplier/subcontractor data, if desired, is provided by the supplier and loaded into the CITIS (no direct access to supplier databases).

  • Option 3: database repository resides with the prime; existing information systems are interfaced to extract CITIS data in a central repository.

    It involves a program-specific data repository that resides with the prime contractor and is made up of multiple databases. This option differs from option 2 in that even though the databases are distributed, they contain duplicate information that allows data to be easily linked together (i.e., a relational database management system). The central data repository typically contains basic information about each functional area, program, or type of data that is used to interface with more extensive databases containing related information. This method can also be easily used to identify, for example, parts/equipment used on more than one system. Another benefit to data linking is that when information is changed in one location, the CITIS system can be designed to reflect that change in any other databases containing that same data. Supplier/subcontractor data, if desired, is provided by the supplier and loaded into the CITIS (no direct access to supplier databases).

  • Option 4: database repository resides with the prime and suppliers (many), with a navigator (gateway processor) to pass requests/access to supplier databases.

    Option 4 is the most extensive of all four options, because it allows direct access not only to contractor databases, but to supplier and subcontractor databases as well. This option is typically the most difficult to implement, since CITIS could be required to interface with a potentially large number of different systems. This option would require suppliers to be responsible for their own data, thus improving the accuracy of the data available to the CITIS users. One of the drawbacks to the all-encompassing CITIS is the problem of proprietary data rights and privileges. Another potentially major drawback to this type of CITIS network is the possibility of suppliers/subcontractors utilizing their own data management/storage systems that are not compatible with anyone else's. Using current technology, the cost and effort to set up a CITIS system that can interface with all the different data management systems could be prohibitive. Before making a decision on whether to provide CITIS access to supplier/subcontractor databases directly, the contractor should identify the hardware and software used by each candidate system to determine the complexity, and thus feasibility, of incorporating it into the CITIS network.

CITIS and Suppliers/Subcontractors

If supplier/subcontractor data is included in the CITIS, the contractor must develop a supplier data input strategy. This input method should be based on the extent and complexity of the CITIS. The four methods for incorporation of subcontractor data into the CITIS include:

  • Method 1: subcontractor delivers data on paper - prime scans it in and adds it to CITIS in raster format.
  • Method 2: subcontractor delivers data via physical media in digital format - prime loads it into CITIS.
  • Method 3: subcontractor downloads its data directly into CITIS databases.
  • Method 4: subcontractor becomes member of CITIS network and users have access to all of its data.

Method 1 is almost never recommended because of the cost and effort required to scan in the data. Also, the resultant raster data is in a non-processable format, which will significantly reduce the usefulness of the subcontractor-supplied data.

Methods 2 and 3 are both reasonable options when a relatively basic (lower cost) CITIS is desired, because they allow for reasonably simple incorporation of data into the CITIS databases. Digital delivery of subcontractor data to the prime contractor for download into CITIS would eliminate the need to interface with a potentially large number of different subcontractors' information management systems. If, however, a robust CITIS is planned, suppliers/subcontractors should be a part of the CITIS network, and their data should reside in-house.

Method 4 should provide the greatest subcontractor data accuracy and timeliness, but these benefits may be outweighed by the typically higher cost and effort to implement the robust CITIS. In general, methods 2 and 3 should be the simplest, least costly methods to implement for incorporation of subcontractor data into the CITIS.

Data Availability Factors

For most defence programs, a large volume of technical data will be created by the contractor in support of the program. Before this data can be released for access through the CITIS, it must meet the programmatic requirements and pass the contractual restrictions. Only that data that meets all the requirements and restrictions should be made available through the CITIS.

Acceptance of Data Delivered via CITIS

The contract must address the questions of what constitutes data delivery, and who in the NATO/NATO nations will receive, inspect, and accept the data. The NATO/NATO nations will specify in the contract the delivery methods for each CDRL item, and if delivery includes CITIS, this delivery may be in the form of either in-place delivery, in which the data item is considered delivered once it becomes available on the CITIS, or it may be in the form of a physical data download by the NATO/NATO nations from the CITIS.

The NATO/NATO nations contracting officer should decide, and the decision should be specified in the contract, whether the data inspection and acceptance can be performed electronically (e.g., some form of electronic signature or other means of indicating approval or disapproval), or whether it should be done in a traditional method. If an organization will serve as the approving official responsible for taking receipt of the data and then coordinating the inspection and acceptance, that organization should be identified in the SOW.

Hardware, Software, and Networks

The selection of hardware and software used to create the CITIS is critical and must be thoroughly analysed before any attempt to develop CITIS is begun. The CITIS configuration should be determined only after analysis and comparison of the NATO/NATO nations', contractor's, and subcontractor's (if included in CITIS) infrastructures. Some important considerations include compatibility of operating systems, file formats, and hardware and telecommunications options. The CITIS designer should also consider future impacts to the CITIS system should NATO/NATO nations users upgrade their hardware or software.

Operating System Considerations

One of the basic problems between different operating systems (e.g., DOS vs. UNIX) is the allowable length of file names. DOS is restricted to the 8.3 (8 character name plus 3 characters for the file extension) file naming convention, while UNIX allows much larger file names. Because of this problem, close attention should be paid to indexing and file management schemes.

File Format Considerations

Before any CITIS development is performed, the contractor must determine how CITIS will handle data in different formats. A matrix should be developed during the CITIS planning stage showing which software tools will be used and how the NATO/NATO nations and contractor data will be stored and displayed. An ideal CITIS would be able to display and process data in any format, regardless of the software tool used to develop it. However, this ideal CITIS may be economically prohibitive and technologically challenging. In practice, the two primary options for data handling are:

  • All CITIS data is translated from native formats into a single agreed-upon format;
  • CITIS is used to launch multiple applications to display the data in various native formats.

The primary drawback to the first option is that the system operators may be required to reprocess data that has already been created. This translation process introduces the potential to lose data and/or format information. If the data has been created with a wide variety of applications, conversion to a single format is a serious weakness that may have a significant economic impact. Composite documents (which may include text, graphics, databases, and/or spreadsheets) are especially difficult to convert into a single format because some software packages may not reproduce the information accurately, and in some cases, not at all.

The drawbacks to the second option include greater complexity of the CITIS system and the necessity for CITIS users to be trained on and become familiar with a variety of viewing/editing tools. The greater the number of formats the CITIS data viewer/editor must handle, the more complex and difficult to develop the system will be. Depending on the number of applications launched, software licensing costs could also become a major consideration.

The solution to the data format problem may be the use of a neutral file format that allows data created with a variety of different software applications to be saved in a format that can be read by anyone possessing the associated file reader software. Some of the formats currently available are discussed in paragraph 5.5.2.3 below.

Neutral Data File Options

Depending on the expected CITIS data usage (view, process, comment, etc.), the contractor may choose to translate appropriate data into a neutral format rather than attempting to retain information in its original file formats. These neutral formats, in general, can be created for files developed with a variety of different applications and can then be read by anyone possessing the associated reader software.

Textual data (e.g., technical manuals and reports, graphics, spreadsheets, etc.) is particularly well suited for conversion to neutral file formats; databases and some engineering drawing formats should be retained in their original format or converted to a standardized format (e.g., convert from specific CAD format to IGES). Some examples of neutral file formats include platform-independent files and Standard Generalized Markup Language (SGML) files.

Several industry-developed software products for creating platform-independent files have recently become available that allow users to save information created in a variety of software applications and formats, including text, graphics, and spreadsheets, into a platform-independent file format, which can then be viewed and printed by anyone possessing the associated reader software.

Many applications also allow reader-software users to annotate data and copy information that can then be pasted into other word processing programs. Because of their flexibility in handling a wide range of software packages, contractors may want to explore these platform-independent file applications when determining standard CITIS file formats.

SGML is the CALS standard for the exchange of text material for technical documents. It is a non-proprietary format that is not bound to any system software or platform. SGML can handle both text and graphics. A number of SGML authoring software packages are currently available as COTS software. As with the platform-independent files, SGML reader software is required to utilize data in an SGML format.

Most SGML readers allow the user to, as a minimum, view, annotate, and print data. One of the current considerations when selecting SGML formats is that it is not yet widely used because of the present lack of Document Type Definitions (DTD) and Formatting Output Specification Instances (FOSI), which are needed to create or translate data into SGML formats.

The neutral format reader software discussed above is especially appropriate for data that will be viewed and printed only. Some SGML readers, and the authoring versions of platform-independent file and SGML applications should allow users to perform most of the other data functions such as processing and updating the data.

Hardware and Telecommunications Options

When determining the infrastructure for CITIS, the program manager must decide whether the contractor or the NATO/NATO nations or both will provide the hardware and telecommunications for the NATO/NATO nations to interface with CITIS. Typically, the NATO/NATO nations will use its own computer hardware, including modems, and software to access the CITIS data, with the contractor providing only the software necessary to access CITIS. However, the program manager may choose to have the contractor provide computer hardware (e.g., complete PCS, terminals, etc.) and/or software to be located at NATO/NATO nations facilities and used exclusively for CITIS access. This option may be especially attractive for locations that could otherwise require infrastructure upgrades to access CITIS.

Telecommunications involves the physical connection to CITIS via telephone or other type of lines. The CITIS access can be via regular phone lines, dedicated modem lines, high-speed optical lines, or networks, and will typically be a combination of these methods.

If any new lines or networks will be required, the program manager must decide whether the NATO/NATO nations or the contractor will be responsible for line installation and maintenance. The NATO/NATO nations will typically pay for its own connection time charges (e.g., phone line usage) for use of its own telecommunications lines. The NATO/NATO nations may, however, require the contractor to establish an 800-number hotline that can be used by the specified number of concurrent CITIS users.

Infrastructure Changes

Because of the rapidly changing computer hardware and software technology, it is reasonable to assume that at some point during the life of the CITIS, the NATO/NATO nations users will upgrade either their hardware or software or both. This upgrade can cause major problems for the CITIS developers if the existing CITIS has been created to be compatible only with NATO/NATO nations systems as they were at the beginning of the development effort. The NATO/NATO nations and the contractor should agree up-front as to what technology refreshments the NATO/NATO nations can expect the contractor to incorporate after the CITIS has been implemented. The NATO/NATO nations may also want to state explicitly that CITIS shall be upgraded to be compatible with any major changes in hardware and/or network configuration.

Problems can occur when a CITIS user facility reconfigures its networks and then finds that it can no longer communicate properly with the CITIS. Obviously, there needs to be some control over and planning for the number of anticipated changes the contractor is required to incorporate/handle. Ideally, the CITIS will be developed to operate independently of users' operating systems and specific hardware and software. In reality, however, the hardware and software compatibility problems described above can and will occur. CITIS user group meetings can serve as an excellent forum for discussion of compatibility problems, technology advancements, and the advantages and disadvantages to upgrades to the CITIS.

It is highly recommended that the NATO/NATO nations designate at least one person who is knowledgeable in computer hardware, software, and networks to be its CITIS administrator. This person will be trained in the specifics of how the CITIS system works and how it is set up at their facility. Ideally, a CITIS administrator would be selected for each of the NATO/NATO nations' CITIS locations. The CITIS administrator(s) should filter NATO/NATO nations complaints and issues before bringing them to the contractor, and should be responsible for making upgrades to local hardware and software work with CITIS. When a hardware or network incompatibility problem arises, it is often due to a change in the user's PC or network configuration. The local CITIS administrator should attempt to solve compatibility problems before contacting the CITIS developers, who may simply direct the problem back to the NATO/NATO nations as an internal facility problem.



Content last modified
10/4/2000 10:16:28 AM
by TK
Copyright© 1999-2009 LAMP / IDE Virtual Enterprise