At the highest level of abstraction, the imagery production process is similar for all types of imagery. Imagery data is collected (e.g., by satellite or airplane) and sent to an initial processor; from this processor the data is sent through a dissemination system to a library or database. The imagery files are copied from the database to an exploitation system where intelligence products are generated; the resulting imagery products are returned to the database. Authorized users can access the images they need from this database. This entire process takes place within SCI enclaves for most types of imagery, even though most imagery is at the Secret Collateral level.
A3I Libraries are composed of three types: Product, Command, and National. The three types are differentiated by content, storage size, performance, and responsibility for operations and management. They are alike in that each type may contain digital imagery or digital imagery products from all sources including tactical, theater, national, civil, and commercial collection systems. All libraries share common digital imagery standards.
Image Product Libraries (IPLs) contain shared, restricted, or both types of imagery and imagery products required to support individual organizations. Each organization will determine the population of its IPLs and manage its IPLs. The imagery and imagery based products consist of tactical, theater, national, civil, and commercial imagery and imagery-based products. Most of the data stored on IPLs will be imagery products with the owner determining the mix between imagery and imagery products. The size of their IPLs, their interfacing organizations, and the products requiring storage. NIMA will provide the update IPL management software. IPLs are based upon the existing Demand Driven Direct Digital Dissemination (5D) and the Imagery Product Archive (IPA) capabilities, scaled for size and performance, and some are portable. IPLs support various levels of commands, Common Imagery Ground/Surface System (CIGSS) sites, and other organizations outside the command structure of the services, that require the use of libraries. When IPL is integrated IPL into the 17+ Common Imagery Ground/Surface System (CIGSS) ground station architectures processed tactical imagery (still or motion) is fed to an IPL, acting as an imagery buffer, at the ground station. Stored imagery is then pulled or pushed to the exploitation workstations, exploited, then sent to the "public access" IPL for dissemination.IPL will be capable of importing, storing, exporting and managing imagery, image-based products, and associated metadata. IPL has the capability to retain digital imagery data in on-line, near-line, and off-line storage media. Each IPL maintains a catalog populated with metadata of its imagery and imagery product holdings. The IPL supports up to 1300 image requests per day and up to 900GB for on-line imagery storage. The IPL should not take longer than eight minutes to transfer a full frame (930MB) national image to any requesting Client (assuming Fiber Distributed Data Interface, FDDI interface(s) and no LAN contention).
Because of the aggressive schedule, IPL 2.0 needed to use HTMLI (now Broadsword) as the client to meet early needs. IPL 2.0 uses Rome Lab's Broadsword as a client, since NIMA’s Geospatial and Imagery Access Services (GIAS) Common Client was not expected to be available in time. When Harris and GDE Systems looked at functionality in 1997, they found that IAS would not provide required functions to the sites in time for IPL 2.0 release. HTLMI 3.2 was used as a risk mitigation effort. This was considered a low risk decision, since Broadsword is based on HTMLI 3.2. Broadsword was available, easy to use and integrate, and interoperable with IPA, IPL 1.0, IESS, MIDB, 5D, etc. It provides simultaneous access to multiple sources (IPA, IESS, etc.) through a single client interface. The Broadsword web browser client can be accessed from multiple workstations via Netscape.
Most imagery is currently transmitted, processed, transferred and exploited within SCI enclaves; most imagery is, however, classified Secret Collateral. The Secret Collateral user community would like access to these files in a Secret Collateral environment. Currently the transfer of Secret Collateral files from a TS SCI system to a Secret Collateral system requires the services of a human reviewer to ensure SCI information is not compromised; a guard and a firewall provide added security for intrusion protection.
NIMA’s goal is to provide this transfer through an automated guard system, enabling users to access all Secret Collateral imagery products on Secret Collateral systems. To provide this service, an automated Guard System must be able to determine the classification of each file, and to verify that the file has been neither modified nor corrupted since its classification was determined, i.e. that the file’s integrity is intact.
The NIMA Imagery Security Guard (NISG) provides the ability to efficiently transfer imagery, intelligence, and geospatial information products between producers and consumers, often operating at different security levels through the use of accredited, trusted mechanisms. These mechanisms are envisioned to be Security Guards. Although the imagery guard issue faces two primary levels of classification, actually there are three, as the releasability issue comes into play. Multi-Level Security [MLS] is a long way off, and in the interim attention is focused on Secret and Below Interoperability (SABI), and later Top Secret/SCI and Below Interoperability (TABI) and their applicability to MLS.
In 1995 CIO fielded the first major system element under the pilot Accelerated Architecture Acquisition Initiative (A3I), installing the Image Product Library (IPL) at U.S. Atlantic Command Headquarters in Norfolk, Virginia. Additional IPLs also came online in the Washington, DC, area, and at U.S. Central Command. By the end of l996, the IPL was fielded worldwide at NPIC, DIA, SOUTHCOM, STRATCOM, SPACECOM, ITAC, CENTCOM, ACOM, NMJIC, 480IG, ONI, and 26 BC2A sites.
By early 1998 there was an acknowledgment that 5D will be required for several more years than originally planned. In early 1998 NIMA proposed $115M to field IPL to JTF and below. Three actions are combined: CIG/SS fielding (JTF and below); 5D to IPL transition; and 5D sustainment through transition. NIMA will fund the current 5D support program beginning in April 1998 to FY2001. IPLs out at sites need to work with 5D more gracefully. The transition plan establishes a team with members from NIMA, IPL developers, SPAWAR, and 5D developers to identify activities to support 5Ds in the theater. Based on benchmark test results, the team should be able to provide better data to the community to facilitate planning. As of late 1999 IPL problems remained at all levels. NIMA continued to work the issue of imagery and geospatial information storage and retrieval and was confident that a solution will be found. In the mean time browsers (e.g., 5D) will be utilized.5D did not need hardware upgrades to go to Level 6 NITF. All 5D servers out in the field could be upgraded to level 6 with about 6 man-months worth of software developement. It is said that the reason NIMA didn't want this to happen was that 5D would then out perform IPL in function and performance and that would make NIMA look bad because of all of the tens of millions spent on IPA/IPL and only a couple of million spent on 5D.
The NIMA managers that were in charge of IPL and 5D wanted to kill 5D ASAP, with the 5D servers to be stood down after all of the products were migrated to IPL servers. There was no plan ever made to run the systems concurrently until IPL proved itself.The resistance in the field to IPL is a combination of comfort factor and IPL not working well. 5D is a mature product that has had most if not all bugs removed and has had many user suggested features added to it over the years. This makes life easier for the end user. IPL, on the other hand, has had trouble just performing it's basic functions. As of late 1999, GDE/Marconi/BAE had cleaned up IPL to the point that it functed acceptably. Unfortunately, it was still about ten times slower than 5D in serving up imagery.
The present IPL client is a web based client whose code is largely taken from 5D's web client code. The IPL development team was given all of the 5D source code. One of the things that would have made the transition to IPL smoother would have been to have the 5D developers work directly with the IPL developers from the start so they could pass on the knowledge gained over the years of the 5D project. NIMA never requested this until late in 1999 when IPL was in serious trouble of being killed because of being way past it's delivery date and way way over budget. At that point, the 5D developers would have rather quit than help IPL because of the bad reputation IPL had with the commands and also because of all of the mudslinging that the 5D team received over the previous couple of years.
As for product replication and auto-ingesting, as of late 1999 5D had all of the function necessary to do both. The 5D-to-IPL Migration Tool is a NITF file parser, checker , duplicator, and mover. It can be used with any application that uses NITF files. This tool, coupled with several scripts and executables that are already part of 5D, can do almost all of the functions that IPL's replicator and auto-ingest do. There are some limitation but these are few and far between.The "distributed archive" remains something of a pipe dream. Reportedly IPA 1.0 has not demonstrated this functionality, and as of late 1999 the IPL 2.X build could not do it. Supposedly this functionality was going to be introduced in version 2.5. The 5D client has an update [version 4.01], though NIMA will not allow it to be release to the field [IPL was never supposed to have a client -- Broadsword was supposed to be the client]. The new 5D client can query IPA 1.0 servers. It also contains a minor Y2K fix that was missed in the Y2k version 3.41. It also contains enhancements (some mission critical) and fixes that the end users had requested beginning in 1998, and most (90+%) of the coding was actually paid by OASD before the program was transitioned to NIMA. These commands have requested that the update be release but NIMA refuses to field the new 5D client. Many command have loaded 5D on machines that originally had IPA loaded on them. The numbers NIMA reports for IPA servers is said to be inflated, and reportedly most IPA servers are either powered down, not serving up any imagery at all, or have been converted to 5D servers. Only sites that require level 6 NITF support use them at all and there are very few sites that do. IPA 1.0 was updated for Y2K by people at the JITF at Rome Labs. The update IPA (1.1), actually performed very well under testing. When NIMA gave the commands a choice for Y2K updates (since IPL 2.x was nowhere near ready for fielding), most requested 5D. This included new servers they had been waiting for and conversions of IPA 1.0 to 5D where level 6 wasn't required. Two days after the overwhelming response for 5D, NIMA managers decided not to honor the requests and NIMA then told the commands that no new 5D servers would be fielded and all IPA's would be update with 1.1.