FY04-FY05
1
Overview
The
advanced system specified in this document must be able to perform all
of the
functions of the current AWIPS system deployed in the field. In addition there are three major areas of
enhancements identified for this system to significantly improve
flexibility of
the system.
Some
features of the new system, such as the Linux integration, must be
transferable
to the NWS AWIPS system, before the entire prototype has been
completed. The
remaining enhancements are to be integrated into future releases of
AWIPS.
2
Linux
Integration
The ALPS system, which includes code from FSL and other organizations, must run entirely on Linux hardware. The hardware architecture must approximate but need not be identical to the proposed Linux hardware proposed by NGIT. Computer and network technology evolve rapidly, and costs for the specified equipment are likely to be lower by the time the ALPS functionality is deployed. ALPS must therefore use the latest technology available at the time of development.
2.1
Hardware
Capabilities
2.1.1
NAS
Data Storage – The system must have a reliable storage device for
storing
real-time meteorological data.
2.1.2
Gigabit
Ethernet – A high speed network (minimum 1Gb/s) must be provided to
interconnects the servers and workstations.
2.1.3
RH Enterprise WS Linux –
The operating system must be the Open Source Linux and provided by a
vendor who can provide security patches and other basic support.
2.1.4
Postgress
– The relational database must be Open Source and replace the existing
data
base without major rewrite of application software.
2.1.5
Flat
File Text Storage – The D2D WarnGen application must be able to work
with a
flat file and relational data base. The flat file storage must allow
independent testing of new WarnGen features without storage in the
operational
data base.
2.1.6
Fail-Over
– The system must be able to tolerate loss of a single server without
failure
or degraded service. The fail-over must be automatic and accomplished
in less
than two minutes.
2.2
Software
Features
2.2.1
AWIPS
OB5/OB6 – The prototype system must be
based on current AWIPS software. The ALPS may diverge temporarily in
order to
allow prototyping of new capabilities. The software must be managed
such that
all modifications to the baselines can be merged back into the baseline
tree.
2.2.2
FFMP –
The system must integrate the flash flood applications developed
outside
of FSL.
2.2.3
SCAN
– The system must integrate radar applications developed outside of FSL.
2.2.4
OHD
Applications – (TBD)
2.2.5
GFE
– The Graphical Forecast Editor must run on the ALPS hardware, but it
does not
have to be fully integrated with the AWIPS D2D display software.
2.2.6
MHS
– Software provided by non-Government groups, such as the Message
Handling
System, must be integrated into the system.
2.2.7
Other
. . .
3
Distributed
Data
3.1
Data
Access
3.1.1
Local
Images – Certain image data must reside on the local storage device to
provide
rapid response to user requests.
3.1.1.1
Radar
Images – Radar data for all frequently used radars (at a minimum, the
local and
associated radars) must be stored locally and displayable in the same
or less
time than currently.
3.1.1.2
Satellite
Images – All satellite data received from the SBN that is pertinent to
the
local office must be stored locally. Key data sets are the various GOES
channels.
3.1.2
Model
Grids (local) – Commonly used forecast models must reside locally and
be
accessible in the same or less time than currently.
3.1.3
Observations
(local) – Various surface and upper air observations may be stored on
the local
storage device.
3.1.4
Model
Grids (remote) – The system must be able to access selected model grids
that
are stored at remote locations (e.g. NCEP).
3.1.5
GFE
Grids (remote) – The prototype system must be able to access remote GFE
grids
for the purpose of inter site coordination. Local offices may register
for
these grids in order to have them automatically transferred when they
are
available.
3.1.6
Remote
ISC Graphics Annotation (SVG, DGM) – Manual graphics produced at one
office
must be stored in a standard format and accessible to remote offices.
3.2
Data
Management
3.2.1
Local
Catalog – A catalog containing the
location of current available meteorological data within and external
to the
office must be provided.
3.2.1.1
Catalog
Update – The local catalog must be updated when new data is received
locally or
remotely.
3.2.1.2
Metadata
– The catalog must include sufficient metadata to allow display of
external
data on the workstation.
3.2.2
Remote
Catalog – The system must interact with remote data catalogs in order
to
determine available data at remote locations.
3.2.3
Data
Cache – Certain data is to be cached at
local and intermediate sites in order to reduce network traffic and
improve
access time to the data.
3.2.4
Inventory
Server – An inventory server must be
provided that converts basic data notifications to display notification
to meet
the requirement for auto update of display and menu update.
3.2.5
Data
Transfer Mechanism – Data
must be transferred between the remote
server and local system using an existing protocol (e.g. OPeNDAP, LDM,
ftp).
Accuracy of the data must be verified if a compression technique is
employed as
part of the transfer.
3.2.6
Data
Access – A common software API should
be provided to access local or remote data.
3.2.7
Graphics
Refresh – To support inter site coordination, notification of
completion or
update of a manual graphics must be provided. The notification may
server to
automatically update user displays at remote sites.
3.2.8
Intelligent
Purger – Data at the local site must be purged based on system load and
user
needs.
3.2.9
Data
Discovery – A mechanism must be
provided to allow users to see new data sets at remote data locations
without
intervention by a developer or system administrator.
4
Advanced
API
4.1
Interface
Features
4.1.1 External Interface Support - The system will have a high level software interface for external applications (e.g. load display/graphic, export raw/graphic data). The interface must allow the application to be written in any one of the authorized programming languages.
4.1.1.1 Raw Data Load Function - It must be possible from an external application to load raw data from a file and create one of the many data views supported by AWIPS D2D. These include image displays, meteograms, grid contour, and data plots.
4.1.1.2 Object Load Function - Applications must be able to display graphic objects created externally to the AWIPS D2D software (in XML, SCG, or similar format).
4.1.1.3 Raw Data Export Function - Once data is displayed on the screen, it must be possible to export the raw data used to generate the display. The raw data must be the derived parameter, if applicable, and not the base parameters.
4.1.1.4 Object Export Function - The system must be able to export the graphic object (in XML, SVG, or similar format) in order for an application to determine geographic location, area extent, and other attributes of a graphic object.
4.1.1.5 Control Function - Applications must be able to register with the drawing interface to determine when a drawing object has been created. The interface must include other functions that allow basic control of the drawing program.
4.1.2 Internal Interface Support - An internal interface, in the form of a hierarchical library, must be available to developers to allow low level graphic control and generation. This interface may restrict software development to the same language as used by AWIPS D2D.
4.1.2.1 Software Impact - The interface must be developed to minimize expansion of the existing display software code.
4.1.2.2 Extensibility - The library must be designed to allow easy addition of new features.
4.1.3 Drawing Application - A generic drawing application must be developed to create basic graphics for inter site coordination.
4.1.3.1 Line Drawing - The system must be able to draw and edit a variety of lines (e.g. fronts, ridge, freehand, polyline).
4.1.3.2 Weather Symbols - The capability to draw basic weather symbols (e.g. thunderstorm, hail) must be included.
4.1.3.3 Drawing Manipulation - The application must support such basic functions as line editing, smoothing, grouping.
4.1.3.4 GUI configuration - The GUI layout for the application (i.e. tool bar) must be specifiable by an external data structure.
4.2 Display Capabilities
4.2.1 Multi-color graphic - The workstation must be able to display multi color graphics, for such objects as stationary fronts or highlighting certain objects.
4.2.2 Hydroview Application - The system must meet the interactive drawing needs for manual
product annotation.
ALPS 1 Requirements
1. Overview
The first version of the prototype will implement a basic AWIPS D2D system on an all Linux architecture. The architecture will consist of a NAS device for meteorological data storage, two workstations, three servers, and a 1GB ethernet switch. The operating system will be Linux Red Hat Enterprise 3.0 Workstation and the AWIPS code will be Operational Build 5 (OB5). The system will acquire real-time data through an SBN communications processor obtained from one of the other systems. The system will demonstrate the basic AWIPS functions without external applications, and the system monitoring and support functions. The text workstation is also not part of this initial capability.
The following requirements will be addressed:
2.1 Hardware Capabilities
2.1.1 NAS Data Storage - The system must have a reliable storage device for storing real-time meteorological data.
2.1.2 Gigabit Ethernet - A high speed network (minimum1Gb/s) must be provided to interconnects the servers and workstations.
2.1.3 Fedora Linux - The operating system must be the Open Source Linux and provided by a vendor who can provide security patches and other basic support.
2.2 Software Features
2.2.1 AWIPS OB5/OB6 - The prototype system must be based on current AWIPS software. The ALPS may diverge temporarily in order to allow prototyping of new capabilities. The software must be managed such that all modifications to the baselines can be merged back into the baseline tree.
3.1 Data Access
3.1.4 Model Grids (remote) - The system must be able to access selected model grids that are stored at remote locations (e.g. NCEP).
The test data used for this prototype will be located on one of FSL's Central Facility Server. A catalog and an existing data transfer protocol will be used to transfer the data to the ALPS database on the NAS.
3.2 Data Management
3.2.1 Local Catalog - A catalog containing the location of current available meteorological data within and external to the office must be provided.