NOAA Forecast Systems Laboratory
Boulder, Colorado
Software technology, like its hardware counterpart, continues to evolve and provide better and more powerful products for solving system design problems. Development techniques and tools such as structured design and procedural languages, e.g. Fortran and Pascal, are slowly being superseded by object oriented design and object-oriented languages such as C++ and Java. Many of the proven concepts used by procedural languages, such as data abstraction and information hiding, have become an integral part of object-oriented technology. FSL has followed the industry trend and developed the WFO-Advanced weather forecast support system using object oriented design and development.
A software architecture is defined by the type and number of software components, their interfaces, and their interrelationships with each other. The WFO-Advanced architecture comprises a large number of software classes and interfaces. Since it is impossible to discuss all of these here only the most significant classes for the WFO-Advanced will be identified in this paper.
In addition to changing to a new design paradigm using object-oriented technology, FSL also made some major changes to its designs of real-time meteorological workstations. All of FSL's previous workstations used routine product generation to pregenerate and store almost all of the workstation graphic and image displays on disk. The purpose of this was to provide faster response to product requests by the forecasters. Because of the tremendous improvements in processor speed over the years, the WFO-Advanced now generates all of its displays from raw data upon request. This has significantly improved flexibility in displaying products to the screen. Progressive disclosure of additional information when zooming in on a smaller area is now fully implemented for both images and graphics.
Performance - is the predominant driver in the design of a real-time meteorological workstation. The time it takes to display a product, measured from the moment the forecaster intends to display a product until it is available, must be measured in seconds or fractions thereof (MacDonald, 1985). Different facets of the system architecture are factors in achieving the desired performance. These include the user interface (Grote and Bullock, 1997), database layout, software modularity, and interprocess communications. In pursuing maximum performance, frequently the first implementation is not the best or the final.
Flexibility - is critical to the evolution of the software to meet new or changing requirements. The life of the system is determined by the degree of flexibility in the software architecture.
Maintainability - is of particular importance to the WFO-Advanced development since maintenance responsibility for the software will be transferred to another government organization. The National Weather Service is using FSL's WFO-Advanced software as the core of AWIPS (Advanced Weather Information Processing System). One of the keys to making the software maintainable is defining the appropriate number and kinds of software classes during the design phase.
Software design patterns - identify practical solutions to common software design problems. Each design pattern describes specific classes, their roles, and collaboration to solve a general design problem (Gamma etal. 1995). They are designs and not code, like application frameworks that can be extended to satisfy a particular application. By using design patterns, a developer takes advantage of the experience of many programmers in solving specific object oriented design problems and issues. Three design patterns, Singleton, Parameterized Factory Method, and Template Method, were found to be particularly useful.
(a) Of the three, the Singleton is probably the most widely used pattern in the WFO-Advanced software. A class that follows the Singleton pattern ensures that there is only one instance (i.e. object) of the class and that there is a global point of access to the instance. An example of a Singleton is the IGC_Impl (Interactive Graphic Capability) which receives requests from the user interface and passes them on to other objects for processing.
(b) The Factory Method (also known as virtual constructor) provides the class interface for creating objects without specifying their "concrete" classes. An illustration of an interface is "draw_box()" where the concrete implementation of "draw_box()" is in a concrete subclass. The Factory Method is used in the WFO-Advanced to initialize extensions such as text warning generation and the display of baselines for cross sections. The extension factory is a Singleton object that constructs and destroys all extensions.
(c) A Template Method provides the steps of an algorithm using abstract operations. The Template Method defines the order in which the steps are executed, but the implementation of those steps can be redefined by a particular subclass. An example of the Template Method is the TextFileDictServer class, which defines the steps of an algorithm to read various text configuration files. Because each file has a slightly different format, a subclass implements the method to parse each line. Different subclasses implement different line parsers.
Legacy software - in the WFO-Advanced include specialized utilities such as decoders and thermodynamic libraries, which were developed either for previous workstations or obtained from outside sources. The main benefit of using legacy software is reduced development time.
Foundation classes - provide abstractions for fundamental and commonly used data structures. Because these classes are widely used, they are highly reliable and optimized for performance, as appropriate. Examples of these data structures are absolute time, time range, text string, and points in two-dimensional Cartesian coordinates. The foundation classes are categorized into container classes, common data classes, and logging.
Code reusability - applies to both reuse of the code internal to the system, and use of the code by external users. The WFO-Advanced uses the C++ foundation classes developed for another project within FSL. Although not as extensively as hoped, reuse of code has reduced the number of different classes and the overall development time.
Commercial off-the-shelf versus custom software - There are many well-known benefits and some downsides to incorporating commercial off-the-shelf (COTS) software. Since this type of software is a "black box" it can obstruct performance tuning of the system. Also, any software change, including modifications to stay current with new operating system releases, must be performed by the vendor. Poor support may prevent the entire system from upgrading to a new operating system release. One also needs to be aware of the recurrent software license costs.
The WFO-Advanced uses Informix, a commercial relational database product; Tcl/Tk (Tool Command Language/Tool Kit) a freely-available scripting language and a user interface tool kit; and netCDF, a freely available data storage and retrieval interface. Two other products: DMQ (DEC Message Queue) and OI (Object Interface) were removed from the system because of some of the stated difficulties with COTS software.
Generic vs. hardware specific - Best performance can usually be obtained by taking advantage of special hardware features provided by the vendor. The WFO-Advanced uses the HCRX-24, a powerful graphics board for Hewlett Packard workstations, to implement the display functions. Although special features are employed, they have been fairly well isolated in the software.
Flexibility vs. performance - Flexibility usually is achieved with a reduction in performance. Additional software, such as abstract classes, is typically added to achieve flexibility. However, the flexibility gained may offset the reduction in performance. For example, in the WFO-Advanced an abstract interface to the interprocess communications made it relatively easy to replace the underlying interprocess communications mechanism.
Figure 1 provides a high level overview of the system components to illustrate the fundamental interrelationship between components.
Figure 1. WFO-Advanced System Components
These components are decomposed into many smaller classes for actual implementation. Front End Communications establishes and maintains communications with the remote data sensor but usually does not interpret the data. Data Acquisition is responsible for acquiring the data, converting it into the appropriate internal format, and storing it on disk. The implementation separates the high bandwidth data sources, such as SBN (Satellite Broadcast Network) and radar to achieve maximum performance. An ancillary component, Local Data Exchange, is being developed to handle unique local data sources and distribution of local data and products. Local Data Exchange will also be responsible for distribution of data and products to outside users. The Data Management component provides all services for storage, retrieval, deletion and update of data, and maintains a data inventory. The software conceals the implementation details, such as data formats, organization, and location, from users of the data.
Depictables are among the primary users of the data and contain both the rendering algorithm to create a display-ready product and the product itself. A depictable is invoked by the Interactive Graphics Capability any time a product is to be displayed on the screen. All of the display capabilities, such as pan, zoom, and animate are part of the Interactive Graphics Capability. User Interface Selection provides the services that permit the user to select a product and control the display of that product and also the workstation.
To better understand the software architecture we now split some of the high-level system components into their software counterparts.
Front End Communications - The wfoAPI process is responsible for establishing a link with the radar product generator (RPG) and transferring data between the RPG and the rest of the data ingest system. The architecture requires that each radar have its own wfoAPI process. The wfoAPI stores the data on disk and notifies the radarServer when new data have arrived. The radarServer is responsible for routing messages from wfoAPI to the rest of the system and vice versa.
The front end communications for the AWIPS SBN, known as the acqserver process, was provided by the AWIPS contractor (PRC Inc.) and was slightly modified to integrate with WFO-Advanced software. Unlike the radar front-end communications, information from the SBN flows in only one direction. The acqservers (one for each SBN channel) store most of the received data directly to disk and notify the commsRouter of its arrival.
Data Acquisition - Data are either stored on disk or transmitted by the front-end communications to the data controllers (i.e. grid, satellite, text, or radar). The controllers initiate the proper action to either decode or reformat the data for storage.
Data Management - Radar data are run-length encoded in flat files, satellite and gridded data are stored in netCDF, and text is stored in the Informix database. Once these data are stored, decoders notify the notification-Server, which then sends the appropriate notifications to the various workstation processes, such as the IGC. The system provides two separate inventories: one for data, a second for depictables. A separate inventory is needed for depictables since there is not a one-to-one relationship between data and depictables. Data accessors are used to retrieve data from the database: each data source has its own unique accessor. Figure 2 illustrates the use of the GridAccessor and GridSliceAccessor to retrieve a derived grid for a Depictable.
Figure 2. Use of Grid Accessors
Local Data Exchange - The local data exchange receives data from a number of different local sources over low speed phone lines and stores them in the WFO-Advanced database. After performing quality control checks this and other data are made available to emergency managers in the field and the general public.
Interactive Graphics Capability - The IGC process (Biere, 1998) provides the means to generate and manipulate graphic and image displays. An IGC_Impl object is created when the IGC process is started. It receives requests from the user interface and passes them on to such C++ objects as FrameSeq and DisplayMgr for processing. The FrameSeq object is also a Singleton that is responsible for loading, unloading, and printing of products. It performs such operations as time matching of graphic overlays in the various frames of an animation loop. FrameSeq relies on such objects as Frame, DepictSeq, and DepictTuple to perform these operations. A Frame object exists for each frame in a loop and contains information (in a depictTuple ) on where to locate the depictables for the frame. A DepictSeq is used by each image or graphic overlay to determine whether it is toggled on or off and what color is assigned to it.
Depictables - Depictables convert raw data into a form suitable for display by the IGC. They employ two subclasses, ImageDepictable and GraphicDepictable, to create approximately 50 different concrete depictables. The requirement for on-the-fly product generation necessitates that depictables are optimized for performance. Some depictables use legacy code from DARE (Denver AWIPS Risk Reduction and Requirements Evaluation) written in Fortran.
User Interface - The user interface, which provides a means for the user to initiate actions, is written in the scripting language Tcl/Tk that supports rapid prototyping and allows easy modification of scripts to incorporate new capabilities. A C++ interface was developed to allow Tcl/Tk scripts to communicate with the IGC process.
Support software is used throughout the system and is not considered to be a separate component. In addition to the foundation classes, discussed under legacy code, there are two additional significant sets of software: interprocess communications and process management and monitoring.
Interprocess communications - The IPC (Interprocess Communications) has been rewritten and refined to meet the demanding reliability and performance requirements of the WFO-Advanced workstations. The IPC uses TCP/IP sockets to establish communications between processes on the same host or other machine.
Process Management and Monitoring - Process management and monitoring can be thought of as consisting of two parts: internal and external. Several of the WFO-Advanced processes (such as the IGC) are monitored within the system and restarted if they fail. In addition, there is an elaborate data and process monitor implemented in Perl using the Netscape browser.
The front-end communications and data acquisition components reside on two data servers and two application servers. A commercial software package (MC Service Guard) performs fail-over of functions to another server, in case of hardware failure. The User Interface and IGC components execute on each of the workstations. Workstations equipped with two graphic monitors require two copies of these components.
The WFO-Advanced database resides on redundant data servers. All access to the database by the workstations and application servers, except for text data, is performed using Network File Service disk mounts. Except for small amounts of internal caching of raw data by depictables and caching by the UNIX operating system, there is no local caching of data on the workstations.
The WFO-Advanced architecture is the result of 16 years of development and testing of real-time meteorological workstations. It represens FSL's first application of object-oriented design to a meteorological workstation and has proven to be very successful in providing a reliable and flexible design. Extending the capability (Kelly, 1997) of the WFO-Advanced is more easily accomplished than in previous FSL workstation. Also, the use of on-demand product generation has added considerable flexibility in displaying meteorological data. FSL is in the process of transferring the WFO-Advanced software to the AWIPS contractor for system integration and deployment to operational field offices.
Biere, M., 1998: WFO-Advanced Two-Dimensional Display Software Design. Fourteenth International Conference on Interactive Information and Processing Systems for Meteorology, Hydrology and Oceanography, Phoenix, AZ, Amer. Meteor. Soc.
Gamma E., Helm R., Johnson R., Vlissides J., 1995: Design Patterns, Addison Wesley Publishing Company.
Grote U. and C. Bullock , 1997: Design of the WFO-Advanced User Interface. Thirteenth International Conference on Interactive Information and Processing Systems for Meteorology, Hydrology and Oceanography, Long Beach, CA, Amer. Meteor. Soc., 320-323.
Kelly, S., 1997: An Object-oriented Framework for Local Extensions to the WFO-Advanced. Thirteenth International Conference on Interactive Information and Processing Systems for Meteorology, Hydrology and Oceanography, Long Beach, CA, Amer. Meteor. Soc., 324-327.
MacDonald, A. E., 1985: Design Considerations of Operational Meteorological Systems: A perspective based upon PROFS Experience. First International Conference on Interactive Information and Processing Systems for Meteorology, Hydrology and Oceanography, Los Angeles, CA, Amer. Meteor. Soc., 16-23.