Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Technical Considerations NOAA has recognized the need, and embarked on a course, to bring the nautical chart production processes into a digital environment. Several broad themes and requirements bear on the technical choices NOAA must make to ac- complish these objectives. These themes and requirements are discussed below. PAPER AND RASTER CHARTS NOAA is currently committed to producing paper and raster chart images. In a digital production system, raster images are a byproduct of paper chart produc- tion; thus, paper and raster charts are, from a high-level production point of view, virtually the same product. Neither chart requires maintenance of an underlying vector database of nautical features, although it may be more efficient in the long run to produce and maintain them from such a database. Even in the absence of a full-vector database, a digital maintenance system for raster and paper products can use vector source data to improve the efficiency of producing updates and new editions. NOAA is able to provide the raster product to a growing number of users as an inexpensive byproduct of the paper chart production process. POPULATING THE VECTOR DATABASE To provide and support digital vector data products, nautical chart features will need to be captured and stored in a vector database rather than in raster chart images. While currently there is no legal requirement for NOAA to produce a complete vector digital data product, a demand exists for new products with some data themes captured in vector form. It is possible to build and populate such a 18
TECHNICAL CONSIDERATIONS 19 database of partial themes over time by collecting a limited number of critical themes (such as channel limits, navigation aids, bridge clearances, etc.~. These themes could comprise the initial vector database and products. The incorpora- tion of additional themes could then populate a more complete database. These selected themes can also support the raster and paper chart maintenance process identified above. The process of loading a vector database with all data currently contained in the paper chart suite is costly, but technically possible; contractors are currently doing similar work for the Defense Mapping Agency (DMA) and the U.S. Geo- logical Survey. NOAA could explore the possibility of partial loading of vector data from DMA's Digital Nautical ChartlVector Product Format (DNC/VPF) data. DMA's data is digitized from NOAA paper charts and therefore is not new source data. NOAA has estimated a cost of $20 million for the complete vectorization of the chart suite and the loading of all ANCS II databases. The DMA data presents a valuable, potential source of data for the initial loading of the nautical informa- tion database. Moreover, analysis suggests that it may be possible to vectorize the remainder of NOAA's chart suite (those charts not converted in DMA's DNC project) for about $4 million (see appendix E). NOAA may benefit from examin- ing the experience of other countries that are involved in efforts to load and qual- ity control vector data (e.g., Norway, Canada, and Japan). It may be possible to refine the time and cost estimates for loading and quality control of vector data. A major goal in the current modernization plan of the Office of Coast Survey at NOAA is to populate the vector database with an accuracy that is commensu- rate with the accuracy available in global positioning systems (GPS),~ at least where that level of accuracy will be tested (e.g., data for docking and navigating narrow channels). Data that is digitized from existing charts does not support this requirement. Inaccuracies of 50 meters are common in digitized charts, and greater inaccuracies can occur. Accidents can result from mariners not under- standing the limitations of their data. However, while the ideal situation is for all U.S. waters to be resurveyed to higher accuracy, this is quite impractical in the near term, and the accuracy of the paper chart is adequate to support most naviga- tion. With more accurate data for specific areas, electronic charts can become valuable aids for nearly all navigation. Accuracy requirements should obviously be a major factor in determining a database loading strategy. Whatever course of action NOAA chooses to take, several factors need to be considered to ensure that the cost of population, as well as the total operating costs, are minimized. The following observations are based on lessons learned from experience with populating similar production systems: iDevelopment of the GPS provides Me mariner with realtime position accuracy to within 5 to 10 meters in some cases (Alsip et al., 1992-1993).
20 NAUTICAL CHART PROGRAM The format and content of data to be used in the database must first be established. NOAA's data formats need to be interchangeable with those of other national and international agencies in the mapping, charting, and geodesy community. · The most appropriate and most efficient mechanisms for establishing con- trol of data (metadata) must be identified early in the process. · All existing data do not need to be converted into digital format unless there is demand for data. All new data should be collected in digital form. · Data management requires a database-loading strategy that allows maxi- mum use of resources. If database loading is prioritized, the most critical databases will be loaded first. Loading of additional databases and con- version of analog data to digital format could then proceed on a demand basis. Resources to support the database-loading strategy are a substantial part of the life-cycle cost of any system. DATA PERISHABILITY Data that reflect the geographic character of the environment are, by defini- tion, subject to the ever-changing forces of nature a factor often called data perishability. The volatility of that information will affect the ability to maintain accurate chart products. Accuracy maintenance of the latest edition of a chart is critical to chart users because it may ultimately affect the life, safety, health, or livelihood of chart users and others. Moreover, a reduction in the time required to produce and disseminate new (updated or corrected) editions of chart products and the timely management and maintenance of large amounts of source data are among the main reasons for moving to a digital production system. DATA STANDARDS The two primary data formats used in international nautical applications are S-57 and VPF (see detailed discussion in appendix D). S-57 is the vector data format approved by the International Hydrographic Organization (IHO) for trans- fer of data among hydrographic offices and for use in the Electronic Chart Dis- play and Information System (ECDIS). VPF is a vector data format developed by DMA and incorporated into the international Digital Geographic Information Exchange Standard (DIGEST). Under the auspices of the Digital Geographic In- formation Working Group, several North Atlantic Treaty Organization nations helped to develop the DIGEST standard. DMA is the U.S. representative on that working group and is also the custodian of the standard. The DNC is a product- specif~c implementation of the VPF format with nautical data content. Efficient operations in a digital environment depend on a clear definition of data standards and the commitment to use standard data formats for delivery of
TECHNICAL CONSIDERATIONS 21 data products. Developments such as S-57 and DNC/VPF motivate and enable the mapping, charting, and geodesy community as a whole to move toward true interoperability among disparate users through the use of fully digitized data- bases, digital map production, and direct electronic distribution of products and data. The nautical chart product is no longer primarily in a paper format, but the underlying source data have become a product in themselves. In response to a growing customer base, systems developers are building ECDIS, electronic chart systems (ECSs) and geographic information systems (GISs) that rely on the availability of data for effective implementation and, ulti- mately, for safe navigation. In the past year, the international hydrographic com- munity has made much progress to advance the data exchange standard (S-57~. Early NOAA efforts to produce this data used a version that lacked the "profile" or "product specification" needed to ensure its uniform implementation by users. The latest version of S-57, approved by the IHO in November 1995, includes these product specifications and resolves many of the problems encountered in earlier data production efforts. NOAA, along with hydrographic offices world- wide, has adopted the S-57 specifications as the standard for nautical data. Par- ticipation on the international technical committees that develop these specifica- tions helps NOAA ensure that the standards evolve within an overall plan of change, thereby causing minimum impact on systems. NOAA could promote con- sistency by publicizing this position, alerting data users to be prepared for data within standard formats, and allowing software systems developers to be pre- pared to create and use this data. The Canadian Hydrographic Service has been producing S-57 data successfully (Casey and Goodyear, 1994~. COMMERCIAL OFF-THE-SHELF AND OPEN SYSTEMS In consideration of the investment that NOAA has already made in its cur- rent digital data management and production systems, the evolution toward newer hardware and software should take into account the anticipated total life-cycle costs. For example, choices about hardware and software should take into ac- count the cost savings generally associated with commercial off-the-shelf (COTS) solutions. Custom software coder is usually more expensive to acquire and main- tain than COTS software. Consequently, if COTS software can provide the nec- essary functions, it is likely to be a preferable solution to custom code. Similarly, more open (less proprietary) and more widely used hardware platforms and oper- ating systems are likely to incur lower life-cycle costs. The renewal of existing information systems and the transformation of obso- lete (usually proprietary, special-purpose) systems into modernized, lower-cost, open-architecture systems generally requires the re-engineering of the hardware 2Custom codes are instructions to run computer programs that are designed for a specific (usually a single) customer.
22 NAUTICAL CHART PROGRAM and software into more flexible components. In addition, the total production environment, including data, interfaces, and operational procedures, may need to undergo a redesign to provide greater flexibility. A term often used today to cap- ture the mechanics of this process is migration planning. Migration Planning A basic requirement necessary to plan the migration of any system is to un- derstand the long-range plans of the implementing agency on future roles and missions, budgets, and staffing. The development of a specific migration plan for NOAA's nautical charting program requires an understanding of technology trends and of specific developments in the mapping, charting, and geodesy com- munity. Documentation of requirements is a prerequisite to the development of a migration plan. The development of a migration plan is an iterative process. The starting point is the delineation of agency goals and objectives, together with other exter- nal factors such as the availability of budget and the relevant future roles and missions of the implementing agency. The migration plan is then revised and modified until management is convinced that the plan will support agency objec- tives. Any migration plan should be updated at least once a year and correlated with agency objectives by senior management. Migration plans of large organizations (and particularly government agen- cies) tend to adopt layers of inflexible standards as a solution to most problems. In a marketplace where a high percentage of COTS solutions are applied, the federal government no longer will be able to dictate the use of specific standards, and commercial practice will frequently bypass federal standards. Consequently, although standards can be used effectively and are necessary to define data for- mats and content, a migration plan that attempts to plan data systems over more than a five-year period, or to foresee every contingency, is probably not realistic. The migration plan is best viewed as a general guideline rather than as an abso- lute guide on every subject. Hardware Hardware capabilities are evoloving rapidly. Because of this rapid evolution, to specify the use of a particular or unique hardware platform in a plan will likely lead to system obsolescence. The adoption of open-system protocols and stan- dards, open-operating systems, and an open-systems hardware and software ar- chitecture will allow more flexibility in creating a long-term plan. Software Many of the functions performed by specialized software developed during the 1980s and earlier can be replaced with COTS solutions. Furthermore, many
TECHNICAL CONSIDERATIONS 23 COTS packages can be customized with software that will connect various COTS pieces together to perform a new task. The need to develop custom code can be minimized using this approach and also results in a more efficient operating system. Because of the significant investment that other agencies of the federal map- ping, charting, and geodesy community have made, it is possible for NOAA to reduce its overall system development costs by taking advantage of code that has already been developed and tested to perform similar tasks. Another key element in controlling software costs is to use as many standard COTS modules as pos- sible and to modify requirements to avoid custom coding whenever possible. Other agencies have found that the replacement of aging proprietary systems with COTS incurs economies; however, when safety is an issue, care must be taken to ensure quality and to anticipate and cope with unexpected software or hardware failures (NRC, 1995; see also appendix C). Other System Elements Other elements, in addition to hardware and software, are important factors in designing and implementing a cost-effective system. Networking, interactivity, distributed systems or multimedia capabilities and requirements can all impact system design and cost. The establishment of requirements for and the estimate of costs of these infrastructure and applications elements is necessary, just as it is for the system hardware and software elements. Standards in these areas are rapidly evolving. These developments will ultimately benefit NOAA. Open-System Design Philosophy Open systems are more receptive to insertion of new technology, especially lower-cost COTS hardware and software components. An open-systems environ- ment allows users to transparently access the data they need, regardless of data source and location, and to use data on a variety of production applications even though these applications may have come from several COTS vendors. Adoption of an open-systems emphasis for development and procurement will allow NOAA to rapidly and flexibly accommodate new production scenarios and revise others. The following are some characteristics of architectures built on an open- systems philosophy: · Open-system architectures generally operate on a wide variety of com- mon hardware platforms and associated operating systems. · Open-system architectures generally support a variety of data exchange standards (through means of translators available with the software), as well as general information processing standards. · Open-system designs allow for standardization in the access of data from a host application program, thereby supporting multiple vendor products.
24 NAUTICAL CHART PROGRAM . Open-systems standardize the way a user interacts with an application through a graphical user interface. This helps the application code remain independent of the user interface code. Often this is achieved by the use of an open, documented application programming interface that integrates the application code with the graphical user interface. Development of an agencywide plan for systems evolution and replacement with the approach above would allow NOAA management and internal and ex- ternal hardware and software developers, and other agencies, to cooperate in an on-going phased systems evolution approach. SYSTEM DEVELOPMENT AND ENGINEERING AND MANAGEMENT CAPABILITIES An acquisition strategy for future development of nautical charting informa- tion systems would benefit from incorporating the following considerations: the ability to manage complex information system projects the available budget for these activities and the stability of those budgets over the time frame necessary to implement the system the overall roles and missions of NOAA a determination of where NOAA's nautical information systems need to be to fulfill mission and user requirements in the future These considerations will contribute to the long-term stability of the production environment and low total life-cycle costs. Other factors, such as facilities and instrumentation, may be relevant to the specific implementation details of any acquisition strategy. Like many other large information systems developed by federal agencies and industry over the past decade, the process of developing ANCS II ran into difficulty due to the stresses and demands of costs, schedules, technologies, and development practices. These difficulties make it clear to the committee that in undertaking the development of future systems, it is worthwhile for NOAA man- agement to pay critical attention to methods and management practices docu- mented in the literature of systems engineering science, management science, technology development, and organizational change, and to benefit from the les- sons learned by other federal government agencies that have undertaken similar modernization programs (DOD, 19954. The basic building blocks for improving the management of complex tech- nological and engineering projects are qualified staff to manage the project, high- level reporting and access of the project manager to senior management, stable assignment of the project manager and supporting staff, a team approach to imple- mentation, timely decision making, and the enforcement of a systems engineer- ing methodology. Appendix C discusses these widely accepted elements of man- aging a successful systems engineering project in greater detail.
