Weather Forecasting: Systems Architecture Needed for National Weather
Service Modernization (Chapter Report, 03/11/94, GAO/AIMD-94-28).
The National Oceanic and Atmospheric Administration (NOAA) lacks a
systems architecture, or overall blueprint, to guide the design,
development, and evolution of the many subsystems comprising its $4
billion modernization of the National Weather Service's weather
observing, information processing, and communications systems. This
situation arose because NOAA officials have not managed the multiple
subsystems as interrelated parts of a single system. As a result,
incompatibilities have arisen among the subsystems, including different
communication protocols and application languages. The modernization has
never had a central manager or chief architect. Consequently, the
subsystems continue to be developed and managed in largely the same
manner as they were started--as individual systems that must be
interconnected after development to meet National Weather Service
requirements. Unless a single manager is appointed and an architecture
is developed and enforced, the integration of these and potentially
other new weather forecasting subsystems will continue to require more
time, effort, and money than is necessary.
--------------------------- Indexing Terms -----------------------------
REPORTNUM: AIMD-94-28
TITLE: Weather Forecasting: Systems Architecture Needed for
National Weather Service Modernization
DATE: 03/11/94
SUBJECT: Systems architecture
Earth resources satellites
Information analysis operations
Systems compatibility
Programming languages
Strategic information systems planning
Weather forecasting
Computerized information systems
Computer software
Information resources management
IDENTIFIER: Hurricane Andrew
NOAA/NASA GOES-Next Satellite Program
NWS Advanced Weather Interactive Processing System
NWS Next Generation Weather Radar
NWS Automated Surface Observing System
Geostationary Operational Environmental Satellite
NWS Telecommunications Gateway
NOAA Wind Profiler System
NWS Automatic Hydrologic Observing System
NWS AWIPS Forecast Preparation System
**************************************************************************
* This file contains an ASCII representation of the text of a GAO *
* report. Delineations within the text indicating chapter titles, *
* headings, and bullets are preserved. Major divisions and subdivisions *
* of the text, such as Chapters, Sections, and Appendixes, are *
* identified by double and single lines. The numbers on the right end *
* of these lines indicate the position of each of the subsections in the *
* document outline. These numbers do NOT correspond with the page *
* numbers of the printed product. *
* *
* No attempt has been made to display graphic images, although figure *
* captions are reproduced. Tables are included, but may not resemble *
* those in the printed version. *
* *
* A printed copy of this report may be obtained from the GAO Document *
* Distribution Facility by calling (202) 512-6000, by faxing your *
* request to (301) 258-4066, or by writing to P.O. Box 6015, *
* Gaithersburg, MD 20884-6015. We are unable to accept electronic orders *
* for printed documents at this time. *
**************************************************************************
Cover
================================================================ COVER
Report to Congressional Requesters
March 1994
WEATHER FORECASTING - SYSTEMS
ARCHITECTURE NEEDED FOR NATIONAL
WEATHER SERVICE MODERNIZATION
GAO/AIMD-94-28
National Weather Service Modernization
Abbreviations
=============================================================== ABBREV
ASOS - Automated Surface Observing System
AWIPS - Advanced Weather Interactive Processing System
DOD - Department of Defense
FAA - Federal Aviation Administration
GAO - General Accounting Office
GOES-Next - Next Generation Geostationary Operational Environmental
Satellite
ISO - International Standards Organization
NESDIS - National Environmental Satellite, Data, and Information
Service
NEXRAD - Next Generation Weather Radar
NMC - National Meterological Center
NOAA - National Oceanic and Atmospheric Administration
NWS - National Weather Service
NWSTG - National Weather Service Telecommunications Gateway
OSI - Open Systems Interconnection
Letter
=============================================================== LETTER
B-255498
March 11, 1994
The Honorable Ernest F. Hollings
Chairman, Committee on Commerce,
Science, and Transportation
United States Senate
The Honorable George E. Brown, Jr.
Chairman
The Honorable Robert S. Walker
Ranking Minority Member
Committee on Science, Space,
and Technology
House of Representatives
This report responds to your request that we review the National
Weather Service's (NWS) modernization program. As agreed, we focused
on whether NWS is using a systems architecture and has clearly
assigned responsibility for development and management of the
modernization.
We will provide copies of this report to the Secretary of Commerce;
the Director, Office of Management and Budget; and interested
congressional committees. Copies will also be made available to
others upon request.
Please call me at (202) 512-6253 if you or your staff have any
questions concerning the report. Other contributors to this report
are listed in appendix IV.
Joel C. Willemssen
Director, Information Resources
Management/Resources, Community,
and Economic Development
EXECUTIVE SUMMARY
============================================================ Chapter 0
PURPOSE
---------------------------------------------------------- Chapter 0:1
The National Weather Service's (NWS) ability to forecast the weather
impacts not only the lives and property of every American but also
our nation's commercial interests. Catastrophic disasters such as
hurricane Andrew and the "great flood of 1993" demonstrate the
importance of providing timely weather forecasts and warnings. To
improve the accuracy, timeliness, and efficiency of its weather
forecasts and warnings, the National Oceanic and Atmospheric
Administration (NOAA), of which NWS is a part, is spending over $4
billion to modernize NWS weather observing, information processing,
and communication systems.
Given the risks inherent in such a large and complex undertaking, the
Chairman of the Senate Commerce, Science, and Transportation and the
Chairman and Ranking Minority Member of the House Science, Space, and
Technology Committees requested that GAO review the NWS modernization
effort to determine (1) whether NOAA has a systems architecture to
guide the development and evolution of the many interrelated
subsystems under the modernization, (2) whether there are
architectural differences among these subsystems and the impact of
any such differences, and (3) whether responsibility for managing the
modernization has been clearly assigned.
BACKGROUND
---------------------------------------------------------- Chapter 0:2
The modernization program includes four new major subsystem
developments, subsystem hardware and software upgrades at three NOAA
organizations, and the development of a number of other smaller
subsystems. Collectively, these subsystems will comprise a single
weather forecasting and warning system that must work together as an
integrated set to meet NWS requirements.
These subsystems will evolve as forecasting methods improve and
operational requirements change. Improvements are already being
developed for subsystems still under development, and other changes
are likely to occur as research results are incorporated.
RESULTS IN BRIEF
---------------------------------------------------------- Chapter 0:3
NOAA lacks a systems architecture, or overall blueprint, to guide the
design, development, and evolution of the many subsystems comprising
the modernization because NOAA officials have not managed the
multiple subsystem initiatives as interrelated parts of a single
system. This lack of a systems architecture has led to
incompatibilities among the subsystems, such as different
communication protocols (sets of rules that govern communications
among computer systems) and application languages. To address the
protocol differences, special interfaces have to be developed and
maintained to interconnect the subsystems. Furthermore, multiple
application languages are problematic because software written in
different languages is more difficult and expensive to maintain and
share among subsystems. Sharing application software is especially
important because NWS is considering reallocating forecasting
functions among the subsystems to provide better support to each
weather office, and subsystem incompatibilities make such functional
transfers difficult.
The modernization has also never had a central manager or chief
architect. As a result, the subsystems continue to be developed and
managed in largely the same manner as they were started--as
individual systems that must be interconnected after development to
meet NWS mission requirements. Unless a single management entity is
designated and an architecture is developed and enforced, the
integration of these and potentially other new weather forecasting
subsystems in the future will continue to require more time, effort,
and money than is necessary.
PRINCIPAL FINDINGS
---------------------------------------------------------- Chapter 0:4
NWS DOES NOT HAVE A SYSTEMS
ARCHITECTURE
-------------------------------------------------------- Chapter 0:4.1
A systems architecture is widely recognized as an essential element
in guiding system development, operation, and maintenance because it
promotes commonality among subsystem components, thereby increasing
efficiency and minimizing maintenance. NWS does not have a systems
architecture for the modernization. The subsystems were started at
different times, some as early as 1980, when the state of technology
for interconnecting systems was not as mature as it is today. Thus,
it is somewhat understandable why the subsystems' genesis and early
development were not guided by an overall systems architecture.
However, the subsystems continue to be developed today independent of
one another. NOAA's Systems Program Office, in realizing the
importance of a systems architecture to assist in managing and
guiding future systems development and evolution, recently initiated
an effort to define an architecture for the four subsystems under its
purview. However, this effort does not encompass all subsystems
comprising the entire modernization.
LACK OF SYSTEMS ARCHITECTURE
IMPACTS MODERNIZATION'S COST
AND PERFORMANCE
-------------------------------------------------------- Chapter 0:4.2
Developing the modernization subsystems independently, without an
architecture, has resulted in incompatibilities that require
additional resources to acquire, interconnect, and maintain hardware
and software. For example, the modernization subsystems use a number
of differing protocols. This can best be seen in the Advanced
Weather Interactive Processing System (AWIPS), which, as the
integrating component of the many subsystems, requires extra hardware
and software to accept data from other subsystems that use their own
communication protocols. Not only do these multiple protocols
require the purchase and maintenance of additional hardware and
software, but they also complicate interconnection of the subsystems.
NWS is considering reallocating functions among subsystems to use
weather data more efficiently, as well as migrating certain
subsystems to vendor-independent environments.\1 However, because of
existing and potential incompatibilities among the subsystems, this
will be more difficult than necessary. A systems architecture would
facilitate the transfer of functions among subsystems and the
migration to compatible, vendor-independent operating environments.
--------------------
\1 A vendor-independent environment uses hardware and software with
characteristics that conform to specifications in the public domain
(that is, that are not unique to a particular vendor or group of
vendors).
NO ONE IN NWS IS RESPONSIBLE
FOR THE MODERNIZATION
-------------------------------------------------------- Chapter 0:4.3
In order for the modernized subsystems to be designed, built,
operated, and evolved as a system of interconnected subsystems,
someone within NOAA must have the responsibility and authority to do
so. However, other than the head of NOAA, there is no such
designated individual. Instead, the management of the modernization
is diffused. For example, the NOAA Systems Program Office is
managing four new major subsystems, while existing subsystems are
managed independently by various NOAA and NWS organizations. As a
result, systemwide architectural standards have not been formulated.
RECOMMENDATIONS
---------------------------------------------------------- Chapter 0:5
To help ensure the success of the NWS modernization, GAO recommends
that the Secretary of Commerce direct the Deputy Under Secretary for
Oceans and Atmosphere to designate a single manager or chief
architect for the modernization with the responsibility and authority
to define and enforce adherence to an overall systems architecture.
GAO further recommends that the Deputy Under Secretary direct this
individual to develop a systems architecture and that the
architecture include all weather forecasting and warning subsystems
and be used as a guide in current and future subsystems development.
AGENCY COMMENTS
---------------------------------------------------------- Chapter 0:6
In its written comments on a draft of this report, the Department of
Commerce stated that the report's focus is appropriate and timely and
that the report thoughtfully addressed important technical and
organizational considerations facing NOAA from a modern systems point
of view. In addition, the Department agreed that NOAA lacks a
single, complete, and unified systems architecture that encompasses
all the various subsystems used to create and disseminate weather
information and services. The Department added that NOAA accepts and
shares the goal of establishing a comprehensive and unifying
architecture that will serve as a guide for current and future
development. Accordingly, the Department generally concurred with
GAO's findings, conclusions, and recommendations, and it stated that
NOAA is currently taking steps to implement the recommendations. The
Department also noted several considerations associated with the
modernization that it believed GAO's report did not address. GAO
agrees with the Department's points, as discussed in chapter 5, and
believes that they further strengthen GAO's argument for a
comprehensive systems architecture.
INTRODUCTION
============================================================ Chapter 1
The National Weather Service's (NWS) basic mission is to provide
weather and flood warnings, public forecasts, and advisories
primarily for the protection of life and property. NWS' operations
also support other agencies' missions and the nation's commercial
interests. For example, NWS provides specialized forecasts to
support aviation safety and the agricultural and marine industries.
To fulfill its mission, NWS uses a variety of systems and manual
processes to collect, process, and disseminate weather data to and
among its network of field offices and national centers. Many of
these systems are outdated. For example, the current radar equipment
dates to 1957, and the one remaining U.S. geostationary weather
satellite has exceeded its planned life and will run out of fuel
prior to the planned April 1994 deployment of its replacement.\1
Since the early 1980s, NWS has been modernizing its observing and
processing systems so it can more accurately and quickly predict the
weather. The goals of the modernization are to achieve more uniform
weather services across the nation, improve forecasts, provide more
reliable detection and prediction of severe weather and flooding,
permit more cost-effective operations, and achieve higher
productivity. The modernization involves new orbiting and
ground-based technology for collecting data on weather phenomena and
powerful new information and forecast systems. According to NWS, new
technological systems are essential to improve warning and forecast
services and to replace obsolete and increasingly unreliable systems.
Because of the productivity and efficiency gained from these new
systems, NWS expects to reduce the number of weather field offices
from 249 to 116 and overall staffing levels by over 17 percent by
around the year 2000.
--------------------
\1 Geostationary satellites maintain a constant view of a single
location on the earth from about 22,300 miles in space.
DESCRIPTION OF MODERNIZATION
SUBSYSTEMS
---------------------------------------------------------- Chapter 1:1
As defined by NWS, the modernization program consists of four
acquisitions--the Advanced Weather Interactive Processing System
(AWIPS), the Next Generation Geostationary Operational Environmental
Satellite (GOES-Next), the Next Generation Weather Radar (NEXRAD),
and the Automated Surface Observing System (ASOS)--and an upgrade to
the National Meteorological Center (NMC) computer system. However,
accomplishing the goals of the modernization also requires other new
and existing subsystems. These complementary subsystems, with a
combined estimated cost of over $4 billion, must work together as an
integrated unit to provide the forecaster with all the information
needed to prepare forecasts and weather warnings. The major
subsystems that encompass NWS' modernization are described below.
AWIPS, the centerpiece of the modernization, is an information
processing system that acquires, integrates, analyzes, displays,
and disseminates weather data from various sources. AWIPS will
be deployed to each of the 116 weather forecast offices
beginning in April 1996 with full deployment estimated for March
1998. NOAA estimates the cost to develop and deploy AWIPS to be
about $475 million.
GOES-Next measures temperature and moisture levels of the
atmosphere, provides visible and infrared images of clouds and
the earth's surface, and collects data from remote locations.
The GOES-Next program, which includes five satellites and the
ground systems to command, control, and communicate with the
satellites, is estimated to cost about $2 billion. The
satellites are to be launched between 1994 and 2004.
NEXRAD is a Doppler radar system that measures wind velocity in
severe weather, such as thunderstorms, tracks storm movement and
intensity, and generates images for use by forecasters and other
users.\2 This joint acquisition with NWS, the Federal Aviation
Administration (FAA), and the Department of Defense (DOD) will
consist of 175 units. As of August 1993, 44 radar units had
been delivered to the three agencies. NWS estimates NEXRAD's
cost to be about $1.3 billion, with full deployment to occur in
January 1996.\3
ASOS is a system of sensors that automatically collects and
processes data on weather conditions, including temperature,
barometric pressure, wind, visibility, clouds, and
precipitation. As of August 1993, NWS had deployed
approximately 321 of the 868 planned ASOS units at NWS, FAA, and
DOD sites. NWS estimates its share of the ASOS program to be
about $340 million, with full deployment to occur by May 1996.\4
NMC processes weather data through computer models to generate
numerous weather products, such as extended and medium-range
forecasts and advisories of hazardous weather for aviation
interests. NMC plans to upgrade its systems by acquiring a
supercomputer at an estimated cost of about $47.5 million.
Completion of the upgrade is expected to occur by 1994.
The National Weather Service Telecommunications Gateway (NWSTG)
receives data from NMC for dissemination to AWIPS, other
government agencies, other nations, and private users. NWSTG
also collects and disseminates weather observations received
from such sources as aircraft and ships. To process the much
larger traffic volumes that will be required by the
modernization, NWSTG plans to upgrade its current computer
system at a cost of about $9.5 million. The upgrade is to occur
between 1995 and 1996.
The National Environmental Satellite, Data, and Information Service
(NESDIS) collects and processes data from GOES satellites for
use by AWIPS and NWS national centers. In October 1992, to
accommodate GOES-Next data, NESDIS began upgrading its system at
a cost of about $400,000. NWS will continue this effort through
June 1994.
In addition to these major acquisitions and upgrades, the
modernization also includes other, smaller acquisitions and existing
subsystems. For example, NOAA's Office of Oceanic and Atmospheric
Research developed a Wind Profiler system that uses Doppler radar to
automatically measure upper-atmospheric winds. As of May 1992,
NOAA's Office of Oceanic and Atmospheric Research fielded a
demonstration network of 32 profilers. NWS plans to acquire a
national, operational network consisting of 150 to 250 profiler
units. The estimated acquisition cost of this national network is
about $250 million. In addition, the Automatic Hydrologic Observing
System is an existing network of remote sensors (satellite and
ground-based) that automatically collects river and rainfall data.
These smaller subsystems are also to be integral components of the
modernized weather forecasting and warning system.
--------------------
\2 Doppler radar, named for Christian Johann Doppler, is used to
determine the speed and direction of rain or snow particles, cloud
droplets, or dust moving toward or away from the radar. The radar
accomplishes this by sending out a pulse using a stable soundwave
frequency and then measuring the changing frequencies as the
distances between the radar and the object change.
\3 FAA and DOD are reimbursing NWS $306 million and $281 million,
respectively, for NEXRAD units.
\4 FAA and DOD are reimbursing NWS $191 million and $18 million,
respectively, for ASOS units.
THE MODERNIZATION IS A SYSTEM
OF SUBSYSTEMS
---------------------------------------------------------- Chapter 1:2
The multiple subsystems that comprise the NWS modernization must work
together to form one integrated system. Collectively, these
subsystems comprise a single weather forecasting and warning system,
with each component being expected to fulfill its part of the total
weather forecasting and warning process. For example, satellite
image data from GOES-Next is collected and processed by NESDIS, which
then distributes these processed data to NMC. The Center uses these
data in computer models to generate products, which are sent through
NWS' telecommunications gateway to AWIPS. AWIPS integrates these
products with weather information from other sources, including
NEXRAD and ASOS, to generate local forecasts and warnings. AWIPS
then distributes these forecasts and
warnings through various means to the local media and government
agencies, which in turn provide this information to the general
public. Figure 1.1 depicts the relationships and flow of data among
the different subsystems.
Figure 1.1: Future NWS Weather
Forecast System
(See figure in printed
edition.)
\a Includes data from other observing satellites (for example, Polar
Orbiting Environmental Satellites).
\b Includes data from remote sensors (for example, ground-based
Automated Hydrological Observing System), local flood warning system,
spotter network, cooperative observers, and government agencies.
\c The National Meteorological Center, the National Hurricane Center,
and the National Severe Storms Forecast Center will also have AWIPS
workstations.
\d Includes Ocean Products Center, private meteorologists and
corporations, aircraft and ship reports, lightning network, and Wind
Profiler system.
THE MODERNIZATION SUBSYSTEMS
WILL CONTINUE TO EVOLVE
---------------------------------------------------------- Chapter 1:3
The systems that comprise the NWS modernization must be flexible
enough to meet dynamic operational requirements. Current forecasting
methods will be constantly improved, and the subsystems must evolve
to accommodate these changes. According to the scientific operations
officers at the weather forecast offices we visited, NWS has only
begun to think about how to use the wealth of data that their
modernized systems will provide.
The evolutionary nature of the modernization system is evidenced by
the many changes currently taking place. In addition to the NMC,
NESDIS, and NWSTG upgrades, enhancements are also being planned for
the subsystems that are under development. For example, NOAA's
Forecast Systems Laboratory and NWS' Techniques Development
Laboratory are currently developing the AWIPS Forecast Preparation
System to be incorporated into AWIPS. The AWIPS Forecast Preparation
System will further automate forecast and warning generation and
enhance the forecaster's ability to edit graphics on the AWIPS
workstation screen. The Forecast Systems Laboratory estimates that
this system will consist of at least 250,000 lines of code and will
be incorporated into AWIPS in 1999.
The subsystems will also evolve as they are used to conduct
meteorological research. This research will then be used to
establish new requirements that must be incorporated into each
subsystem. For example, forecasters will use AWIPS to develop new
forecasting techniques and strategies, from which new applications
will be developed to provide weather forecasts and warnings.
OBJECTIVES, SCOPE, AND
METHODOLOGY
---------------------------------------------------------- Chapter 1:4
The objectives of our review were to determine (1) whether NOAA has a
systems architecture to guide the development and evolution of the
many interrelated subsystems under the modernization, (2) whether
there are architectural differences among these subsystems and the
impact of any such differences, and (3) whether responsibility for
managing the modernization has been clearly assigned. To determine
whether a systems architecture was used to guide subsystem
development and evolution, we met with NOAA and NWS officials
responsible for each component of the modernization to determine
whether a modernization architecture exists. In addition, we
reviewed NWS' data flow diagrams, Office of the Federal Coordinator
for Meteorological Services and Supporting Research guidance, and the
AWIPS specification to determine if these documents constitute a
systems architecture. We also met with NOAA Systems Program Office
officials to discuss their efforts to develop a systems architecture
for the four subsystems they currently manage (AWIPS, NEXRAD,
GOES-Next, and ASOS).
To determine whether architectural differences existed among the
subsystems and the impacts of any differences, we (1) acquired
information on each subsystem's hardware, operating system,
application languages, database management, communications, and
security characteristics, (2) reviewed key technical documents,
including the AWIPS contractor's best and final offer and the AWIPS
specification that described subsystem interfaces and communication
protocols, (3) analyzed the impacts of these differences, (4)
interviewed NOAA and NWS officials and well-recognized experts in the
field of computer technology at the National Institute of Standards
and Technology, Massachusetts Institute of Technology's Lincoln
Laboratory, and Carnegie Mellon University's Software Engineering
Institute, and (5) interviewed National Research Council officials
involved in the modernization.
To determine whether responsibility for managing the modernization
has been clearly assigned, we reviewed the modernization strategic
plan and asked NOAA and NWS officials responsible for each respective
component of the modernization who is responsible for the
modernization. In addition, we reviewed the subsystems configuration
management plans to assess how changes in subsystems are analyzed and
ascertain the cross-representation of configuration control board
members among subsystems.
We performed our work at the Department of Commerce in Washington,
D.C.; NOAA and NWS headquarters in Silver Spring, Maryland; NOAA's
Forecast Systems Laboratory in Boulder, Colorado; National Institute
of Standards and Technology in Gaithersburg, Maryland; Lincoln
Laboratory in Lexington, Massachusetts; and the Software Engineering
Institute in Pittsburgh, Pennsylvania. The Department of Commerce
provided written comments on a draft of this report. These comments
are presented in appendix I and are addressed in chapter 5. Our work
was performed between January 1993 and September 1993, in accordance
with generally accepted government auditing standards.
NOAA HAS NOT DEVELOPED A
SYSTEMWIDE ARCHITECTURE TO GUIDE
THE DEVELOPMENT OF THE
MODERNIZATION
============================================================ Chapter 2
A complete systems architecture is vital in effectively and
efficiently guiding the development, operation, and maintenance of
any complex system. It promotes compatibility among subsystem
interfaces, protocols, hardware, operating systems, application
languages, and data formats, thereby increasing system performance
and minimizing system development and maintenance costs. NOAA has
never had an architecture for its modernization subsystems because
each subsystem was historically viewed and managed as a disparate
piece.
AN ARCHITECTURE IS A
FUNDAMENTAL COMPONENT OF SOUND
SYSTEMS DEVELOPMENT, OPERATION,
AND MAINTENANCE
---------------------------------------------------------- Chapter 2:1
A systems architecture describes the functions, elements, and
performance requirements of the system, and defines the most
effective approach to meet current and future mission needs.\1
Effective architectures are derived from a strategic information
systems planning process, which analyzes the system's functional,
informational, data, and application requirements. The architecture
describes all functional activities to be performed by the system,
the elements needed to perform these functions, and the performance
requirements for these elements. An architecture further defines the
hardware, software, communications, data management, and security
subarchitectures of the system; and defines the system's required
operational effectiveness, maintainability, and flexibility to adapt
to changing missions. Failure to specify an architecture may result
in additional development and maintenance costs, additional
development time, and systems that do not function as required.
NOAA and NWS officials, as well as officials at Lincoln Laboratory,
the Software Engineering Institute, the National Institute for
Standards and Technology, and the National Research Council,
acknowledge that a systems architecture is valuable in guiding system
development and optimizing system operations and maintenance. Also,
9 of the 11 NOAA and NWS officials we spoke with who are directly
involved in and responsible for different aspects of the
modernization agreed that a systemwide architecture to guide the
development and evolution of the subsystems would be valuable. For
example, a NOAA program official stated that without an architecture,
there are no limitations or constraints on future development, which
results in programs being developed using different standards. Also,
the mission statement for the System Program Office, the NOAA
organization that is responsible for managing AWIPS, NEXRAD,
GOES-Next, and ASOS, specifically recognizes the need for a systems
architecture to promote interoperability\2 and plan future systems.
--------------------
\1 Strategic Information Planning: Framework for Designing and
Developing System Architectures (GAO/IMTEC-92-51, June 1992).
\2 Interoperability is the ability to have computers from different
vendors work together in a cooperative way over a network.
NWS DOES NOT HAVE A SYSTEMS
ARCHITECTURE FOR THE
MODERNIZATION
---------------------------------------------------------- Chapter 2:2
We interviewed 16 NOAA and NWS officials responsible for each
component of the modernization, and all but 3 stated that no systems
architecture exists for guiding development or integration of the
subsystems under and related to the modernization. The principal
reasons cited by several of these officials for no architecture were
that the subsystems were largely begun and have since been managed
separate from one another and that no one has taken a more global
view of the modernization. NWS and NOAA officials also emphasized
that certain subsystems were begun many years ago and at different
times to replace systems that were basically stand-alone. Moreover,
the state of technology for interconnecting systems was not as a
mature as it is today.
The three officials who said that an architecture existed referred to
several documents, including data flow diagrams, interface control
documents, program specifications, and Office of the Federal
Coordinator for Meteorological Services and Supporting Research
documentation. While these different documents represent parts of an
architecture, they do not constitute a complete systems architecture.
For example, the NWS data flow diagram, although displaying logical
data exchange between subsystems, does not provide any specifics
concerning how data exchange is to be accomplished, including data
formats, data definitions, interfaces, hardware, software, or
security features. Further, the Office of the Federal Coordinator
for Meteorological Services and Supporting Research documentation
regarding automated weather information system programs expressly
states that it does not apply to weather data acquisition systems,
weather information dissemination systems, operational processing
centers, and their associated communications links.
The beginnings of a systems architecture can be found in the NOAA
Systems Program Office. This office recently began defining a
systems architecture to (1) assist in managing subsystems'
interfaces, and (2) guide future systems development, management, and
evolution. However, this effort covers only the four subsystems
managed by the Systems Program Office--AWIPS, GOES-Next, NEXRAD, and
ASOS--and therefore will not result in a complete NWS systems
architecture.
At the conclusion of our audit work in September 1993, NOAA's Deputy
Under Secretary for Oceans and Atmosphere agreed that it would be
beneficial to develop an architecture for the modernization. The
Deputy Under Secretary stated that she planned to place this matter
high on the agenda of a council she recently formed to advise her on
a wide range of issues facing NOAA.
INCOMPATIBILITIES AMONG SUBSYSTEMS
INCREASE INTEGRATION AND
MAINTENANCE COSTS AND LIMIT SYSTEM
FLEXIBILITY
============================================================ Chapter 3
The lack of a global view of the modernization and a systemwide
architecture has caused incompatibilities among the subsystems (for
example, differences in communication protocols\1 and application
languages) that require additional resources to overcome, and makes
transferring functions among subsystems and migrating to
vendor-independent operating environments\2 more difficult and
expensive.
--------------------
\1 Sets of rules that govern communications among computer systems.
\2 A vendor-independent environment uses hardware and software with
characteristics that conform to specifications in the public domain
(that is, that are not unique to a particular vendor or group of
vendors).
SUBSYSTEM ARCHITECTURAL
CHARACTERISTICS DIFFER
---------------------------------------------------------- Chapter 3:1
The modernization's subsystems are very dissimilar. These
differences can be noted by examining the specific architectural
characteristics of each subsystem in five areas--hardware, operating
systems, application languages, database management systems, and
communications. (The specific architectural characteristics for the
seven major subsystems are shown in table 3.1, and described in
detail in appendix II). The differences among the subsystems are
apparent in any one of the five areas. For instance, each subsystem
uses a different operating system (for example, AWIPS uses
Hewlett-Packard's version of the UNIX operating system, called HP-UX,
while NEXRAD uses Concurrent's OS/32 operating system). This means
that each subsystem relies on a completely different set of tools and
techniques (for example, interfaces between applications and the
operating systems, interfaces between the operating systems and
peripheral devices, interfaces between the operating systems and
communication software, etc.) to control and manage the interaction
of its software and hardware.
Table 3.1
Architectural Characteristics of NWS
Subsystems
Subs Database
yste Operating Application Management
m Hardware System Languages System Communications
---- -------------- -------------- ------------ ------------ --------------
AWIP Hewlett- HP-UX, C, Informix X.25,
S Packard HP-RT FORTRAN, IEEE 802.2 &
Pascal, 3,
HP Assembly ISO 8802/5,
SNA, ASOS,
NEXRAD,
Asynchronous,
Async.
satellite
TCP/IP,
HP Network
File System
GOES VAX, DEC VMS, FORTRAN, custom X.25,
- Micro-VAX ENCORE MPX, MACRO DECnet
Next Data General Assembly
AOS/AOSVS
NEXR Concurrent Concurrent OS/ FORTRAN none custom X.25
AD Microfive 32
ASOS custom i486- custom real- C, none, all custom
based time HP Assembly data reside
processor in RAM
NMC CRAY Y-MP8, CRAY UNICOS, FORTRAN, none TCP/IP
Hitachi MVS/SP, IBM
mainframes MVS/XA Assembly,
Hitachi
Assembly,
Cray
Assembly,
C
NWST Amdahl and IBM MVS, IBM custom IBM X.25,
G Hitachi IBM VM/SP, Assembly, IBM TCP/IP,
mainframes IBM VSE/SP, Amdahl IBM FTP,
NCP Assembly, Baudot
Hitachi
Assembly,
FORTRAN,
C
NESD Force-based Microware OS- C none Defense
IS processor, 9 protocol suite
Pentek (TCP/IP, FTP,
SMTP, TELNET)
--------------------------------------------------------------------------------
MULTIPLE COMMUNICATION
PROTOCOLS COMPLICATE THE
INTERCONNECTION OF SUBSYSTEMS
---------------------------------------------------------- Chapter 3:2
Differing subsystem protocols make exchanging data among the
subsystems more difficult and expensive. This can best be seen in
AWIPS, which integrates information provided by many subsystems and
thus must be able to accommodate the differences among subsystem
interfaces. Specifically, AWIPS is required to support 24
communication interfaces.\3 As a result, AWIPS requires extra
communication hardware and software to translate among differing sets
of protocols. This additional hardware and software for AWIPS not
only involves the added cost of buying it, but also the cost of
upgrading and maintaining it. Moreover, 5 of the 24 interfaces are
proprietary, meaning that NWS must deal with these vendors on a sole
source basis and cannot acquire, upgrade, and maintain these
interfaces competitively. Without a systems architecture, subsystem
incompatibilities will persist, and NWS will continue having to
compensate for them.
--------------------
\3 These interfaces include five different transport layer protocols,
five different network layer protocols, nine different data link
layer protocols, and eight different physical layer protocols. See
appendix III for a detailed description of the different layers of
the Open System Interconnection Reference Model.
DIFFERING APPLICATION LANGUAGES
COMPLICATE MAINTENANCE
---------------------------------------------------------- Chapter 3:3
Systems written in multiple application programming languages are
more difficult to modify and maintain than systems written in fewer
languages. Limiting the number of programming languages results in
lower maintenance costs because programming staff require less
training and less support software (for example, compilers,
debuggers, program libraries)\4 must be maintained.
Software for the modernization's subsystems is written in a variety
of programming languages; the choice of which language to use was
based solely on what NWS used in the past, rather than on the type of
analysis and deliberate decision-making that is needed to define a
complete and effective software subarchitecture.
Currently, the seven major subsystems' applications are written in
nine programming languages,\5 and no restrictions have been placed on
the use of additional languages. For instance, in the absence of any
restrictions, NOAA's Forecast Systems Laboratory and NWS' Techniques
Development Laboratory have chosen to develop the AWIPS Forecast
Preparation System (the new AWIPS user interface) in an additional
language (C++) not used previously. According to the concepts
document for this system, C++ is being used because it is object
oriented\6 and believed to be more flexible, easier to maintain, and
needing fewer lines of code to write a given application than the C
programming language. However, none of the NWS subsystems provide
compilers for this language. Therefore, NWS will either have to
convert the code or purchase additional compilers and translators to
incorporate the code into AWIPS. A software subarchitecture, based
on careful and systematic analysis of the needs of current and
planned operating environments, would define the languages to be used
and thus help to avoid the unnecessary costs and difficulties
associated with language proliferation.
--------------------
\4 A compiler is a program that translates the source code written by
the programmer into object code that can be executed. A debugger is
a program that aids in identifying and correcting program errors. A
program library is a collection of routines that a programmer can
use, as needed, without having to write them anew.
\5 Includes six assembly languages.
\6 Object orientation is a new paradigm for software construction.
Historically, writing programs involved defining procedures that act
on a separate set of data. Object oriented languages, like C++,
permit the creation of programs using collections of self-sufficient
objects (modules that contain data and the procedures that act on the
data) that act upon, request, and interact with each other by passing
messages back and forth.
HETEROGENOUS SUBSYSTEMS HINDER
REALLOCATION OF SUBSYSTEM
FUNCTIONS
---------------------------------------------------------- Chapter 3:4
The interdependence between and among the modernization's many
subsystems demands that architectural incompatibilities be minimized.
Such incompatibilities lead not only to increased costs, as discussed
earlier, but they can also restrict flexibility in deciding which
systems will perform which weather forecasting and warning functions.
A systems architecture that defines critical standards (for example,
communication protocol standards, application language standards)
promotes architectural compatibility and thus facilitates
reallocation of functions between and among subsystems.
NWS is currently planning to transfer some subsystem functions to
better meet user needs, and more transfers are being considered. For
example, NMC will transfer its graphics generation function to the
AWIPS workstation to allow forecasters to better manipulate graphics
to their specific geographical area. Also, certain NEXRAD functions,
such as generating storm tracks or tornado position information, may
be transferred to the AWIPS workstation, according to a senior NOAA
Forecast Systems Laboratory official. In addition, the AWIPS program
manager stated that some functions now performed by the Wind Profiler
subsystem may also transfer to the AWIPS workstation. How difficult
these and other transfers prove to be will depend on the extent of
inherent architectural differences among the subsystems.
LACK OF GUIDANCE FOR MIGRATING
SUBSYSTEMS TO AN OPEN
ENVIRONMENT MAY PERPETUATE
ARCHITECTURAL INCOMPATIBILITIES
---------------------------------------------------------- Chapter 3:5
NWS is also considering migrating subsystem applications to open
operating environments. An open environment is one that is based on
vendor-independent, publicly available standards. Implementation of
these standards allows applications to (1) run on any vendor's
hardware, (2) use any vendor's operating system, (3) access any
vendor's database, and (4) communicate and interoperate over any
vendor's networks. An open system environment supports portable and
interoperable applications through standard services, interfaces,
data formats, and protocols. Such an open system environment would
facilitate NWS' efforts to transfer functionality between subsystems
by eliminating reliance on vendor-specific products. Moreover, an
open environment would allow NOAA to competitively acquire, upgrade,
and maintain equipment.
The NOAA System Program Office is considering migrating from NEXRAD's
proprietary hardware and operating system environment to an open
environment. In addition, NWSTG is converting existing software from
nonstandard assembly languages to the C programming language, which
Lincoln Laboratory officials described as the language of choice for
open systems development.\7
There are still choices to be made, however, in moving to an open
environment because different open system options may be selected.
If each subsystem moves to open systems independently, different open
system options may be selected, perpetuating architectural
incompatibilities and continuing to incur additional expenses to
interconnect the subsystems and reallocate functions among them.
Moreover, ensuring that the appropriate standards for the subsystems
as a whole are selected requires careful and thorough analysis of
systemwide requirements. The rigor associated with developing a
systems architecture can ensure such analysis.
--------------------
\7 The C programming language is the preferred language for open
systems because it is (1) considered to be a machine-independent
language, (2) closely associated with the UNIX operating system, (3)
widely used, and (4) standardized by the American National Standards
Institute.
OVERALL RESPONSIBILITY NOT
ASSIGNED FOR THE MODERNIZATION
EFFORT
============================================================ Chapter 4
NOAA's management structure for the modernization is a reflection of
it viewing the modernization as a collection of autonomous
subsystems. Specifically, responsibility and authority for the
modernization are shared by several NOAA organizations, leaving no
one entity in charge. Without a designated chief architect or
engineer for the modernization, no one other than the head of NOAA
has the authority to develop a systemwide architecture. To NOAA's
credit, it is managing individual subsystem changes through change
control groups that bring together representatives for the multiple
subsystems. However, this process, which focuses on individual
subsystem changes, is not an effective alternative to having a
systems architecture and a chief engineer or single manager because
it does not focus on the design, development, management, and
evolution of the total weather forecasting and warning system.
LACK OF A SINGLE MANAGER LIMITS
ABILITY TO ENFORCE ARCHITECTURE
---------------------------------------------------------- Chapter 4:1
The management of the modernization is diffused--no single manager or
entity has the responsibility and authority to manage all aspects of
the modernization or the evolution of the various subsystems
comprising or associated with it. Instead, autonomous organizations
are managing the subsystems. For example, the Systems Program Office
is responsible for AWIPS, GOES-Next, NEXRAD, and ASOS. NOAA created
this office in 1991 to manage these four subsystems' acquisitions to
control cost overruns and schedule delays on each. In addition, NMC,
NWSTG, and other subsystems (for example, the Automated Hydrological
Observing System) are each independently managed within NWS. NESDIS
is managed independently within NOAA.
The use of a guiding architecture and the designation of a single
manager are concepts that go hand-in-hand. Because accountability
and responsibility for the entire modernization have not been
assigned to a single manager, key officials directly associated with
the modernization stated that they do not have the organizational
authority to develop a total systems architecture. In the absence of
someone having been assigned such authority, the only individual
currently having purview over the entire modernization is the Deputy
Under Secretary for Oceans and Atmosphere. Consequently, subsystems
have been, and without appropriate changes will continue to be,
developed and modified independent of one another, with
incompatibilities that will require additional time, effort, and
money to overcome.
At the conclusion of our audit work, the Deputy Under Secretary for
Oceans and Atmosphere agreed that central leadership of the
modernization would be beneficial. The Deputy Under Secretary stated
that clearly fixing responsibility and authority for the entire
modernization with a chief architect or single manager would be high
on the agenda of a council she recently formed to advise her on a
variety of issues facing NOAA.
CHANGE CONTROL PROCESS IS NO
SUBSTITUTE FOR SYSTEMS
ARCHITECTURE AND SINGLE MANAGER
---------------------------------------------------------- Chapter 4:2
To NOAA's credit, it is managing individual subsystem changes in a
manner that considers the systemwide impact of such changes.
Specifically, all subsystems have their own configuration control
board to (1) review requests for change and engineering change
proposals, (2) determine if the change is needed, (3) evaluate the
total effect of the change, and (4) issue changes to the subsystems'
individual configuration baselines. These boards consist of multiple
subsystems representatives. According to the AWIPS program manager,
board members use technical documentation (for example, software
specifications, interface control documents, etc.) and their
knowledge about the subsystems as the means of (1) determining what
impact hardware, software, and communication changes made to a
subsystem may have on their's or others' subsystems, and (2) deciding
whether the benefits of the change justify its cost. The program
manager for AWIPS, which is the integrating component of the
modernization and thus the subsystem most affected by changes, stated
that a systems architecture would facilitate the change control
process by limiting the scope of subsystem change and providing a
systematic basis for determining the systemwide impact of individual
changes.
Relying on a change control board process to guide and control
systemwide evolution is not an effective alternative to a systems
architecture for two primary reasons. First, it provides no single
point of reference that members can turn to for clarification and
guidance in objectively evaluating the effects of changes on the
system as a whole. A systems architecture, particularly one that has
been modeled in an automated form, can be this point of reference and
thus establish criteria for optimizing the entire system rather than
merely its parts. Second, the change control board process manages
specific subsystem changes on a change-by-change basis. It is not a
mechanism for planning or implementing the collection of changes
needed to evolve the system as a whole to effectively meet future
weather forecasting and warning mission needs. That is, it does not
provide an effective means for directing and limiting change in the
sense that a globally-oriented, systemwide blueprint can.
CONCLUSIONS, RECOMMENDATIONS, AND
AGENCY COMMENTS AND OUR EVALUATION
============================================================ Chapter 5
CONCLUSIONS
---------------------------------------------------------- Chapter 5:1
The benefits of developing an architecture and fixing accountability
and responsibility for the entire modernization are numerous. The
lack of a guiding systems architecture and a single manager or chief
architect has resulted in the largely independent development and
upgrade of subsystems that will need to be adapted later to permit
subsystem integration and interoperability. Such an approach has
proven to be unnecessarily costly because subsystem incompatibilities
that result must be overcome through additional hardware, software,
and the associated maintenance. Moreover, these incompatibilities
limit NWS' flexibility in moving functions to the subsystems where
their execution makes the most sense.
It is somewhat understandable that NOAA and NWS have not had a
systems architecture from the modernization's inception, since (1)
some of the subsystems were developed to replace systems that relied
on outdated technology and were largely stand-alone and (2) the
technology and standards now available to permit system integration
and interoperability did not exist or were only emerging at the time.
However, continuing to evolve the subsystems without the benefit of
an architecture and the designation of chief architect or single
manager who is below the Deputy Under Secretary level is unwise. In
particular, the absence of an architecture will likely continue to
result in incompatibilities among subsystems, and the breadth and
technological complexity of the modernization calls for a chief
architect or manager whose full attention is devoted to the
modernization and all its subsystems.
NWS' observational and information processing systems will not remain
inert; they will evolve, incorporating new computer technology and
emerging science. Without an architecture and a single system
manager, existing incompatibilities will continue and new ones will
occur, limiting NWS' ability to migrate the subsystems to open
environments and reducing the effectiveness and efficiency of the
overall weather forecasting and warning systems. Moreover,
overcoming these incompatibilities will require NOAA and NWS to
expend more time, effort, and money than is necessary.
RECOMMENDATIONS
---------------------------------------------------------- Chapter 5:2
We recommend that the Secretary of Commerce direct the Deputy Under
Secretary for Oceans and Atmosphere to designate a single manager or
chief architect for the modernization with the responsibility and
authority to define and enforce adherence to an overall systems
architecture. We further recommend that the Deputy Under Secretary
direct this individual to develop a systems architecture and that the
architecture include all weather forecasting and warning subsystems
and be used as a guide in current and future subsystems development.
AGENCY COMMENTS AND OUR
EVALUATION
---------------------------------------------------------- Chapter 5:3
In its written comments on a draft of this report, the Department of
Commerce generally agreed with our findings, conclusions, and
recommendations. The Department stated that the report thoughtfully
addresses important technical and organizational considerations
facing NOAA from a modern systems point of view and that the report's
focus is appropriate and timely. In addition, the Department
acknowledged that there is currently no single, complete, and unified
systems architecture that encompasses all the various systems used by
NOAA in exchanging and disseminating weather information and
services.
Accordingly, the Department stated that the Deputy Under Secretary
for Oceans and Atmosphere is directing the Assistant Administrator
for Weather Services to prepare by September 30, 1994, the plans and
schedules for the development, documentation, and promulgation of an
overall systems architecture to guide current and future developments
for modernized NWS operations. According to the Department, the
Assistant Administrator for Weather Services will have both the
responsibility and authority to define and direct an overall systems
architecture for NOAA systems that are part of the modernization
effort. In addition, the Assistant Administrator has established a
new position of NWS Modernization Systems Manager responsible for all
systems modernization matters.
The Department's comments also noted several considerations
associated with the modernization that it believed our report did not
address. The Department stated that NWS' infrastructure is complex
and involves diverse system interfaces and protocols to permit data
exchange with various federal, state, and local agencies, as well as
private sector organizations and individuals. It noted that some of
the major subsystems serve other missions besides NWS' and that this
creates an environment of diverse requirements and formidable
integration challenges. Further, the Department commented that
fundamental differences among the various weather forecasting
subsystems' functions, technologies, life cycles, external
interfaces, and operational impact dictate that an overall systems
architecture be able to accommodate a range of standards reflecting
the various vintages of the subsystems. Finally, the Department
stated that the overriding need for continuity of operations and
services necessitate that "old" systems must generally overlap with
"new" systems to permit successful transition of internal operations
and to allow external weather users and collaborators to adapt to the
new technologies and products.
We fully agree with each of the Department's points. In fact, we
believe that they make our argument for a comprehensive systems
architecture even stronger. Given the complexity, diversity, and
interdependence of the many weather forecasting subsystems, which
both we and the Department have pointed out, the absence of such an
architecture increases the risk of subsystem incompatibilities and
thus the unnecessary expenditure of time, effort, and money to
overcome them.
(See figure in printed edition.)Appendix I
COMMENTS FROM THE DEPARTMENT OF
COMMERCE
============================================================ Chapter 5
(See figure in printed edition.)
(See figure in printed edition.)
(See figure in printed edition.)
ARCHITECTURAL CHARACTERISTICS OF
THE MAJOR NWS SUBSYSTEMS
========================================================== Appendix II
This appendix provides more detail on the subsystem architectural
characteristics presented in table 3.1.
Amdahl: A computer manufacturer.
ANSI: American National Standards Institute, an organization of
American industry and business groups dedicated to the development of
trade and communication standards.
AOS/AOSVS: Operating systems developed by the Data General
Corporation.
Assembly: A type of low-level programming language in which each
statement corresponds directly to a single machine instruction.
Assembly languages are thus specific to a given processor.
ASOS: The Automated Surface Observing System-specific interface.
Asynchronous: A way of transmitting data over a circuit in which time
intervals between characters are unequal and thus each character or
byte must be controlled by a start and stop bit. In contrast,
synchronous transmissions send characters and bits at a fixed rate
that both the sending and receiving devices have predetermined and
know (i.e., the two devices are in sync with one another).
BAUDOT: Five-bit code, also called five-level code, is named "Baudot
code" after Emil Baudot, who invented the first constant length
teleprinter code in 1874.
C: A compiled programming language that contains a small set of
built-in functions that are machine dependent. The rest of the C
functions are machine independent and are contained in libraries that
can be accessed from C programs.
CCITT: Comite Consultatif Internationale de Telegraphie et
Telephonie, an organinzation based in Geneva, Switzerland, and
established as part of the United Nations International
Telecommunications Union. The CCITT recommends the use of
communications standards that are recognized throughout the world.
Concurrent Microfive: Computer platform that will replace the
Concurrent 3200 series platforms that are currently being used by
NEXRAD.
Concurrent OS/32: The current operating system for NEXRAD.
CRAY Y-MP8: A specific supercomputer model developed by Cray.
DECnet: Network architecture from Digital Equipment Corporation.
ENCORE: The company that developed the MPX operating system.
Force-based Processor: Processor developed by the Force company.
FORTRAN-77: FORmula TRANslation language, the first high-level,
structured and compiled computer language and the progenitor of many
high-level concepts, such as variables, expressions, statements,
iterative and conditional statements, separately compiled
subroutines, and formatted input/output.
FTP: File Transfer Protocol, one of the Department of Defense suite
of protocols for transferring files between different makes and
models of computers.
Hewlett-Packard: A computer manufacturer.
Hitachi: A computer manufacturer.
HP-RT: Hewlett-Packard's real-time operating system.
HP-UX: Hewlett-Packard version of the UNIX operating system.
i486: An Intel microprocessor introduced in 1989 (also called the
80486 or the 486). Like its 80386 predecessor, the i486 is a
processor with 32-bit registers, 32-bit data bus, and 32-bit
addressing.
IEEE: Institute of Electrical and Electronics Engineers, an
organization of engineering and electronics professionals who
developed the IEEE 802 standards for the physical and data-link
layers of the local area networks following the ISO Open Systems
Interconnection model.
IEEE 802.2: Describes the functions, features, and services of the
Logical Link Control sublayer in the ISO 8802 Local Area Network
Protocol, including the peer-to-peer protocol procedures that are
defined for the transfer of information and control between any pair
of Data Link Layer service access points on a local area network.
IEEE 802.3: Describes the Carrier Sense Multiple Access with
Collision Detection media access method--the means by which two or
more stations share a common bus transmission medium.
INFORMIX: A company that develops software tools that support
client/server database management.
ISO: International Organization for Standardization, an international
association of member countries, each of which is represented by its
leading standard-setting organization (e.g., American National
Standards Institute for the United States).
ISO 8802/5: This standard specifies the formats and protocols used by
the Token-Passing Ring Medium Access Control Sublayer, the Physical
Layer, and the means of attachment to the Token-Passing Ring physical
medium.
MACRO: VAX assembly language.
MPX: Mapped Programming Executive operating system from ENCORE.
MVS/SP: Multiple Virtual System/System Product operating system from
International Business Machines Corporation.
MVS/XA: Multiple Virtual System/Extended Architecture operating
system from Internation Business Machines Corporation.
NCP: Operating system from International Business Machines
Corporation.
Network File System: Allows HP 9000 computer systems to share file
systems in a multi-vendor network of machines and operating systems.
NEXRAD: The Next Generation Weather Radar-specific interface.
OS-9: UNIX-derivative operating system from Microware Corporation.
Pascal: A compiled, structured language, built upon the Algorithmic
Language. It simplifies syntax while adding data types and
structures, such as subranges, enumerated data types, files, records,
and sets.
Pentek: A digital signal processor manufacturer.
RAM: Random access memory, the semiconductor-based memory that can be
read and written by the microprocessor or other hardware devices.
SMTP: Simple Mail Transfer Protocol, one of Defense's suite of
protocols for message transfer in electronic mail form between
different makes and models of computers.
SNA: Systems Network Architecture from International Business
Machines Corporation, a widely used communications framework to
define network functions and establish standards for enabling
different models of its computers to exchange and process data.
TCP/IP: Transmission Control Protocol/Internet Protocol, two of
Defense's suite of protocols that define message handling at layers 3
and 4 of the ISO model.
TELNET: One of Defense's suite of protocols for interfacing terminal
devices and terminal-oriented processes to each other.
UNICOS: The UNIX-derivative operating system from Cray.
VAX/MicroVAX: Virtual Address Extension computer architecture from
Digital Equipment Corporation.
VMS: Virtual Memory System operating system from Digital Equipment
Corporation.
VM/SP: Virtual Machine/System Product operating system from
International Business Machines Corporation.
VSE/SP: Virtual Storage Extended/System Product operating system from
International Business Machines Corporation.
X.25: A CCITT recommendation for packet switching over a wide area
network.
THE OSI REFERENCE MODEL
========================================================= Appendix III
The Open System Interconnection (OSI) Reference Model is a
seven-layer model based on a proposal developed by the International
Standards Organization (ISO) as a first step toward international
standardization of the various protocols. The model deals with
connecting open systems--systems that communicate using standard
protocols in the public domain.
The OSI model describes seven layers of functionality--physical,
data, network, transport, session, presentation, and application. It
is a hierarchial and peer-to-peer model for
communications--hierarchical because each layer above the physical
layer is built on top of the services provided by the lower layers
and peer-to-peer in that one layer in a system has a protocol by
which it communicates with the equivalent or peer layer in another
system. ISO has produced standards for each layer. However, the
standards are not part of the model and each one has been published
as a separate international standard. A description of each of the
seven layers follows.
Layer 1: The Physical Layer - This layer handles the mechanical and
electrical details of the actual physical transmission of bit
sequences over communication lines.
Layer 2: The Data Link Layer - This layer defines station-to-station
connections, generates message frames, and detects and possibly
corrects errors in the physical layer.
Layer 3: The Network Layer - This layer controls the switching and
routing of messages between stations in the network.
Layer 4: The Transport Layer - This layer provides for transfer of
messages between end users. The users need not be concerned with the
manner in which data transfers are achieved.
Layer 5: The Session Layer - This layer provides the means for
cooperating presentation-entities to organize and synchronize their
dialogue and manage their data exchange.
Layer 6: The Presentation Layer - This layer resolves differences in
formats among the various computers, terminals, databases, and
languages used in the network.
Layer 7: The Application Layer - This is the highest layer and
provides services directly to users. It deals with data exactly as
it is generated by and delivered to user processes.
MAJOR CONTRIBUTORS TO THIS REPORT
========================================================== Appendix IV
ACCOUNTING AND INFORMATION
MANAGEMENT DIVISION, WASHINGTON
D.C.
-------------------------------------------------------- Appendix IV:1
Dr. Rona B. Stillman, Chief Scientist
Randolph C. Hite, Assistant Director
Matthew D. Ryan, Staff Evaluator
DENVER REGIONAL OFFICE
-------------------------------------------------------- Appendix IV:2
Keith A. Rhodes, Senior Technical Adviser
David A. Powner, Evaluator-in-Charge
Joseph P. Sikich, Staff Evaluator
|
NEWSLETTER
|
|
Join the GlobalSecurity.org mailing list
|
|
|
