Figure 1. ALPS Application Programmers Interface
FSL's Advanced Linux Prototype System (ALPS) development will focus in three areas: full Linux integration, a distributed data paradigm (push/pull of data), and creation of a new API to support manual graphic generation. These are expounded upon herein.
1. Overview
The objective is to create a powerful API that can be used by a
large number of applications, and also by the D2D depictables and
extensions. The current IGC (interactive graphic capability) comprises
a large body of code that has three separate interfaces for
depictables, extensions, and applications. Depictables are responsible
for creating most of the meteorological displays on the AWIPS
workstation (there are over 65 unique depictables used by D2D).
Depictables draw information to the IGC window using the "painter"
object. Extensions are "half" objects in that reside partially in the
IGC process and partially in a separate process. They use a higher
level interface that is more limited in functionality. Communications
between the IGC and extension occurs through sockets. Finally, D2D
applications have a very simple, but extremely limited interface
using text strings transmitted via standard IO channels. They cannot
draw directly into an IGC window. In order to consolidate these
three interfaces requires a total restructuring and redesign of the IGC.
The current IGC process is partitioned into two or more processes
consisiting of a display manager and the depictables (and
applications). The display manager controls the display window and
draws into it using X11 drawing instructions. The depictable
process(es) use a new interface that is at a slightly higher level than
the X11 instructions used by the IGC. The exact partitioning of
responsibilities between the display Manager and depictables (and
applications) has not been finalized. For the most part, the
depictables will remain the same. But the current painter interface
will be replaced by the new API. Ideally, each depictable should have
its own process. However, since many depictables (particularly, those
controlled by the Volume Browser) are fairly tightly coupled to each
other it is envisioned that a depictable manager manage some or all
depictables. If desired, a future effort could subdivide the
depictables into individual processes.
The D2D extensions, of which WarnGen is the most complex, will be
modified to work with this new interface. The number of extensions is
small and most, such as the "Home Cursor" extension, are fairly simple
to rewrite.
Currently, all data displayed by the AWIPS workstation are read from the local database and processed by the IGC for display. This approach requires that all data be located on the local data server in order for the data to be accessible to the user. It also implies that all data must be transmitted routinely to the data server in order to be available when the user needs it. The concept of distributed data makes it possible for the AWIPS workstation to access data on its local database as well as on servers at remote sites.
To implement the concept of distributed data, a significant change is required to how data are managed within the AWIPS system. The concept of an inventory server is introduced and significant changes are made to the data purger and notification server (see Figure 3). A fallout of this architectural change is a significant reduction in the work performed by the notification server.
A description of the initial work in this area was presented at the 21st IIPS conference (Jan 05, San Diego) by Davis et al.
Figure 3. ALPS Inventory Server
The proposed AWIPS architecture consists entirely of computers that run the Red Hat Enterprise Linux operating system. The Network Attached Storage (NAS) device is the primary local database that serves data to all of the other system components over a high speed Gigabit ethernet connection. The system closely emulates the final configuration proposed to the NWS to implement an all-Linux AWIPS architecture.
Figure 4. Prototype System Architecture