11.1 How to Make an International Meteorological Workstation Project Successful
Total Page:16
File Type:pdf, Size:1020Kb
11.1 HOW TO MAKE AN INTERNATIONAL METEOROLOGICAL WORKSTATION PROJECT SUCCESSFUL Hans-Joachim Koppert 1 Deutscher Wetterdienst, Offenbach, Germany Torben Strunge Pedersen Danish Meteorological Institute, Copenhagen, Denmark Bruno Zürcher MeteoSwiss, Zürich, Switzerland Paul Joe Meteorological Service of Canada, Toronto, Canada 1. INTRODUCTION partners. In the course of the project, they are refined when the respective sub-project work- The Deutsche Wetterdienst (DWD) together packages are initiated. with the German Military Geophysical Service (GMGO) started a new Meteorological Workstation project (NinJo) in 2000. Soon thereafter Meteo- Swiss and the Danish Meteorological Institute (DMI) joined the project. Just recently, the Meteorological Service of Canada (MSC) decided to become a member of the NinJo consortium. The aim of the project is to replace aging workstation systems (Kusch 1994, Koppert 1997) and to provide an unified environment to support forecasting and warning operations. Besides the development of new, or the integration of recently developed applications, it is necessary to provide most of the capabilities of the existing systems. Forecasters are conservative and often would like to stay with their old tools. So we are facing an enormous pressure to implement a system that does (nearly) everything better. Since NinJo is a multi-national project with 5 Figure 1: A NinJo window with 3 scenes: gridded partners, diverse hardware and software infra- data (left), surface observations ( top right), satellite structures, distributed development sites, and local image (bottom right) meteorological needs, a strong requirement is to built the software with a sound software architecture The following list shows NinJo’s main features : that could easily be adapted to the needs of the partners. But it’s not only the software architecture that assures the success of an international S Integrated 2D and 3D visualization of point workstation project, it is also the management of the data including: surface observations, project. The management has to make sure that all soundings, lightning data; gridded data; requirements are incorporated, that resources are satellite and radar imagery; geographical effectively used and the communication among the data; and bulletins sub-projects is functioning effectively. S Batch chart production S Data decoding and management 2. THE NINJO WORKSTATION S Graphical editor S Data modification - both point and gridded User requirements were collected and data structured at the very beginning of the project. S Monitoring and alerting for observations These high level requirement and specifications are and NWP data the basis of the agreement between the NinJo 1 Corresponding author address: Hans-Joachim Koppert, Deutscher Wetterdienst, Kaiserleistr. 42, 63067 Offenbach, Germany; email: [email protected] S Support for multiple windows with data existing hardware and software environment would layering, multiple screens, and animation likewise be difficult to achieve. However, the participation in the NinJo project provided Expected areas of operation: Guidance, MeteoSwiss with a long needed, integrated warning/consulting, research, climatology, meteorological workstation. reports, commercial and private customers Similarly, the MSC has tried to build/buy/develop an integrated workstation for 3. RATIONALE FOR WORKING TOGETHER many years to replace aging, inadequate systems while including new science and technology. It is a The NinJo partners have a very long history of big investment, a high risk venture, a difficult project developing meteorological applications. Based on to manage and very difficult to clearly state the this history, there are different rationales for working requirements and specifications A new driving together on a large and complex project like NinJo. impetus for the MSC was the restructuring to fewer At DWD and GMGO, several Meteorological offices which assumed that the new and maturing Workstation Systems were developed from the science and computer technology - models, early nineties. These Systems became difficult to algorithms, visualization, software, processing, maintain and upgrade. Furthermore, they lack telecommunications, data storage – could be required features such as GIS support, advanced leveraged (GEM refer; Scribe ref; Joe et al, 2002; analysis functionality, data modification modules, FPA). seamless integration with 3D visualization and The advent of affordable high power graphical interactive chart modification into one single workstations in the late eighties led to the application. In 1999, a strategic decision was made development of many independent but very to replace these aging systems and to move away effective forecast applications. The code was from dedicated hard and software environments. In difficult to maintain or upgrade because they were order to broaden the project’s pool of expertise and designed for specific applications and situations and to strengthen the resources, DWD and GMGO lacked a software or data architecture or an overall happily welcomed DMI, MeteoSwiss and MSC as concept that would enable it to evolve. Even newly new partners developed radar software, such as CARDS The DMI started its first meteorological (Lapczak et al, 2001; Joe et al, 2002), soon hit data workstation project in 1990. Based on a cost / access roadblocks. So, a well designed software performance evaluation and the money available architecture and data infrastructure is needed. DMI selected SUN Sparc workstations and started Regardless of which system was the starting to develop applications. With very limited man point for development, it would require substantial power, an approach was chosen where one modification and development to meet the MSC application was developed for each data type vision. So, the driving , requirement was to develop facilitating fast operational deployment to from a solid IT and data foundation. Unique in forecasters who at the time had no such tools at all. MSC’s IT assessment of software was the NinJo During the 90’s, DMI moved from Sparc to Intel system - it was being designed based on sound based Solaris OS workstations and then started to software principles -. functional components were move towards Java. After a decade with isolated from each other and there was an workstations, DMI saw a large part of the encompassing architecture development resources going into maintenance, an uncertain OS and hardware future, a requirement 4. IT SUCCESS FACTORS for data integration in the applications. With the resources available, the options were The philosophy of NinJo is to provide a building to port existing applications (most still in Motif) to kit in order to assemble tailored applications from Linux or acquire a “new” system that could provide NinJo components. A flexible programming model is the data integration (e.g. Horace). Developing a needed to allow NinJo partners to develop their own new DMI system from scratch was out of the application without hampering each other. With this question. With the option of participating in NinJo, it concept, it is possible that each partner can easily was easy to reach the conclusion for the DMI to adapt NinJo to their own needs. make a final Solaris Intel software release, join Before we discuss the key design principles of NinJo and be part of a real meteorological portability, client layer patterns, generic frameworks, workstation project. and easily manageable data sources, we have to The meteorological software currently used at explain our NinJo concept of a generic MeteoSwiss consists of many, rather small and Meteorological Workstation. This concept is one of isolated applications which were increasingly the keys to success! difficult to maintain. In the past decade, there have been efforts to develop an in-house integrated 4.1 A Generic Meteorological Workstation solution, but there were too few resources available to accomplish this task in a reasonable time. A generic Meteorological Workstation should Embedding commercially available systems into the be able to run easily at any meteorological institute of the world. It doesn’t assume or prescribe any is a hierarchy of co-operating agents following the hardware or data infrastructure. It relies solely on Model View Controller (MVC) design pattern. This standards for input and output of data and/or agent hierarchy is configurable through the above products. WMO codes like Synop, Temp, Metar, mentioned configuration framework. There is a strict BUFR or GRIB (to name a few) should be able to decoupling of the agents, allowing the layers to be be ingested as well as any vector or image format. independently developed. Each layer manages it’s It is not possible to interface with all back-end own data. The view of the layer provides GUI- systems immediately, but, the architecture of the components to be integrated by a top-level agent, workstation should be capable of implementing the the “master of the scene”. This top level agent connection with reasonable effort. (called the Layer Container) is also responsible for A multi-national Meteorological Workstation global event handling like the changing of the can be successful only if the technical pre-requisites geographic or the time context. of a generic workstation are addressed early in it’s development. Visualization Library (Vislib) 4.2 Portability Layer The NinJo partners run their current systems Layer Specific Visualization on a variety of hardware with different