EUMETSAT response on ET SAT Action 5.1

Transcription

1 EUMETSAT response on ET SAT Action 5.1 Contents 1 Background Requirements for hosting the RRR database and related DOORS capabilities Tentative data model for the GOS Dossier GOS Volume 1: Programmes GOS Volume 2: Instruments GOS Volume 3: GAP Analysis GOS Volume 4: Performance GOS Volume 5: Compliance Overview Summary Background Action 5.1 of the 5 th ET SAT meeting held from 26 th to 29 th April 2010 in Geneva reads Action ETSAT 5.1: EUMETSAT (A. Rodriguez) to perform an initial evaluation of the use of DOORS or other tools to support the migration of the information contained in the Dossier to a suitable requirements management system, and facilitate its further handling and updating. (End September 2010) The Space based Global Observing System in 2010 (GOS2010) is currently contained in 6 Word documents, inter related through bookmarked hyperlinks. ET SAT at its 5 th meeting underlined that the information therein is very valuable, but in its current format is difficult to maintain and impossible to link to the existing WMO database of requirements and observing capabilities. In addition, the sustainability of the latter is currently not guaranteed. ET SAT recommended that WMO, with the support of its Members, should maintain a common database, initially comprised of the current content of the GOS dossier and the requirements and observing capabilities database. This database, maintained by WMO and its Members in a coordinated manner, would then be expected to supersede the GOS dossier and the current requirements and observing capabilities database. EUMETSAT already has provided a short analysis of the possibilities for implementing and maintaining the WMO Rolling Review of Requirements (RRR) database at EUMETSAT. The analysis is contained in Appendix II of the report from the 6 th session of the Page 1 of 9

2 Implementation / Coordination Team on the Integrated Observing System (IOS). The report is available here, and is further extended in this document. 2 Requirements for hosting the RRR database and related DOORS capabilities DOORS is a server / client software for requirements management widely used in space industry. At EUMETSAT, DOORS is used for the formulation and maintenance of user, system, and sub system requirements for Meteosat Third Generation, and for establishing and maintaining traceability between the requirements. The implementation also covers product requirements from the Satellite Application Facility (SAF) network, and is currently extended to EPS SG and GMES Sentinel 3. The technical characteristics of DOORS already allow an analysis of some of its capabilities w.r.t. the requirements for hosting the database as documented in the IOS report, irrespective of an actual implementation of the RRR Requirement Developing the database possibly based on software and tools already existing at the host... Making the database available online via the web and permitting to query information from... Providing tools for easily managing content of the database, i.e. (i) online password... and (ii) import tools to make substantial changes. Making sure the database is available operationally 24h every a day... Maintenance of the database application, including correction of bugs, software/hardware upgrades as needed. DOORS capabilities Compliant: DOORS is available and widely and proficiently used at EUMETSAT for future programmes. Non compliant: On line access to DOORS is currently not possible at all and in the future, if available at all, will be limited to few and experienced users. A partial work around would be the routine creation and publication of static HTML pages making the database content available on line, but not offering the possibility to query the information. Partially compliant: On line modifications of the database content are currently not possible and will stay significantly restricted. Off line modifications using e.g. Excel sheets and dedicated import tools are possible and subject to development. Compliant: Availability of DOORS is secured during normal EUMETSAT working hours, which is considered compliant in light of the restrictions above, as the availability of DOORS itself would only affect (off line) update processes which will take place during normal working hours anyhow. The availability of eventual static HTML pages would be independent of the availability of the database itself and would only depend on the availability of the standard EUMETSAT webserver. Compliant: Maintenance of DOORS is part of the core EUMETSAT activities Database documentation available Compliant: Database documentation could be made available Page 2 of 9

3 on line. on line independently of the actual implementation in DOORS. The above analysis shows that from the technical, maintenance point of view DOORS would be well suited to be the underlying technology for the WMO RRR database. However, its availability to other users is greatly restricted due to the technical characteristics of DOORS and its expensive software license scheme, making dynamic on line access impossible for a wider user group. However, DOORS on the one hand is well capable to import Word files, and on the other hand is very flexible in the definition of data models and the export capabilities, opening the possibility for a two step approach: In a first step, the GOS Dossier would be imported to DOORS whereby the information content would be transferred from plain text and text tables into a database format. In DOORS, the underlying data model could then be developed and tested locally. In a second step, the database content could e.g. be exported to XML or a different suitable format from which it would then be imported into a final database with better on line functionalities. After this step, the database would be maintained fully in this other database. 3 Tentative data model for the GOS Dossier In the framework of this report the 5 Volumes of the GOS Dossier (GOS 2010) have been imported into DOORS for a first analysis. A tentative data model would be based on the relationships within and in between the 5 Volumes as specified in the GOS Introduction cited hereafter. The first two volumes ( Programmes and Instruments ) collect the information on the status of the space based Global Observing System (both meteorological and R&D satellites). The third volume analyzes the long term evolution of the plans to discover possible gaps of service, and indicates needs for continuity or new developments. The last two volumes ( Products and Compliance ) estimate the potential performances of future systems and compare them with the user requirements. Page 3 of 9

4 Most of the core information in the GOS Dossier is stored in Word tables. For a future usage in a database, this information will have to be translated into different tables with different attributes. Starting from the different GOS Volumes, the following tables and attributes are proposed: 3.1 GOS Volume 1: Programmes Different to the other Volumes, the information in this Volume is not to the vast majority kept in tables, but is a mixture of plain text and tables. It is structured by programme, satellite and payload. The information contained herein would be used to populate the following database table: 01 Satellites Attributes: Linked to: Agencies, Programme, Satellite name, Orbit type, Launch date, End of service, Height, Position / LST, Status, Comments 02 Instruments Note that the Information on Data transmission as well as Annex 1: Frequency Plans, and Annex 2: Definitions and Acronyms, are not yet covered in this analysis. 3.2 GOS Volume 2: Instruments Volume 2 begins with two tables listing all satellites and all instruments. They do not provide additional information, but rather serve as starting points for the hyperlink navigation. The main information is contained in the Instrument Descriptive Tables thereafter. The content of Volume 2 would be used to populate the following tables, and to establish the links between 01 Satellites and 02 Instruments. Page 4 of 9

5 The main table would be 02 Instruments, containing the overall instrument characteristics. However, in addition, Volume 2 also provides information on the individual channels of each instrument. As the number of channels and their characteristics is different from instrument to instrument, but the type of characteristics is identical throughout the different instruments, it is suggested to create an individual table 03 Channels, which contains all channels from all instruments, and which is linked to the actual instrument entries in 02 Instruments. 02 Instruments Attributes: Linked to: Acronym, Full name, Status, Mission, Instrument type, Scanning technique, Swath, Coverage / cycle, Resolution at SSP, Mass, Power, Data rate, Start of service, End of service 01 Satellites, 03 Channels, 04 Missions 03 Channels Attributes: Central wavelength / frequency, Spectral interval start, Spectral interval end, Spectral resolution, Bandwidth, Radiometric accuracy, Polarisations, IFOV size, Pixel size Linked to: 02 Instruments Note: Not all attributes would be used for the different types of instruments 3.3 GOS Volume 3: GAP Analysis While the first two Volumes of the GOS are built from an extensive objective analysis of the current situations and future plans, the Gap Analysis in this volume adds a subjective element to the analysis and more than the other two volumes represent the outcome of intellectual work. This will have an impact on the processes which have to be implemented to secure the sustained update of the database. While the first two volumes (or the respective tables) can be maintained more mechanically, any update of the Gap analysis requires consensus among the involved parties. The GAP analysis itself does not add a lot of additional information to the database, but is the result of the analysis of its inter relationships. Consequently, the content would not necessarily result in the creation of many new database tables, but would be the basis for the creation of these relationships in the database, and for the creation of tailored reports. (In DOORS words, it would be the basis for the creation of links and views). The main structuring element of this volume is the grouping of all instruments into 30 Missions, or model instruments. The grouping itself is already achieved in Volume 2, where each Instrument is assigned to a Mission, which is reflected in the respective attribute in 02 Instruments. The new element in Volume 3 is that a) each mission is assigned to representative characteristics, and that b) for each mission the list of those geophysical parameters is given which is mainly addressed by the given mission. The fist element drives the creation of another table (04 Missions), while the second is the basis for the links between 05 Products and 04 Missions. Page 5 of 9

6 04 Missions Attributes: Spectral range, Bandwidths, No. of channels, Typical radiometric accuracy, resolution, Swath, Scanning, Position / LST Gap analysis Situation, Gap analysis Indications Linked to: 02 Instruments, 05 Products Link attributes: Instrument compliance, Instrument compliance comment Note: For e.g. the LEO missions, different entries in the table would be created for different LSTs. While the links from the Missions to the Instruments would not indicate whether a given instrument is / will be available in a given orbit, this information would be available by following the link further from the instrument to the satellite. The above table and the links to instruments and further to satellites would enable the management of the tables listing the evolution of current and planned missions. The tables Comparative characteristics of... for each mission contain summary information for each instrument, which could be built from the links to each instrument and further down to the individual channels. The additional information in Volume 3, the analysis of the instruments characteristics with the mission s representative characteristics, can only be supported by the database, but not be done automatically. The result, however, can be stored in the database. In DOORS, this information could be stored as a Link attribute in the links from the instruments to the missions. 3.4 GOS Volume 4: Performance Volume 4 does not provide information on actual or planned instruments, but rather on the 30 generic model instruments or missions described in detail in the previous volume. The core intellectual part of Volume 4 is a conceptual performance model, which is used to derive expected product characteristics (resolution, quality, etc., for profiles even provided in different vertical levels) from the generic instrument characteristics of the model instruments. It must be stressed here that although the database model is capable of documenting the outcome of the application of the performance model, it will not serve the purpose of documenting and retaining the performance model itself and the respective knowledge and experience of the Dossier s author, B. Bizzarri. Other means will have to be identified for the latter. Regardless of this limitation, the performance model s results can be captured in a database table with the following characteristics: 05 Products Attributes: Product name, Volume, Principle, Accuracy, Horizontal resolution, Vertical resolution, Temporal resolution, Number of satellites, Coverage, Conditions Linked to: 04 Missions, 06 Requirements Page 6 of 9

7 Note: The attribute Volume denotes the volume of air for which the respective values are valid. In the Dossier, possible values for Volume are Lower troposphere, Higher troposphere, Surface, etc GOS Volume 5: Compliance The final Volume of the GOS Dossier contains a comparison of Product level user requirements with the generic instrument capabilities presented in the previous volume. The intellectual work in this Volume comprises the collection, editing and harmonisation of the end user requirements available from different sources. In order to allow for the automatic comparison with the expected instrument performances presented in the previous volume, all requirements had to be harmonized e.g. in terms of units, and w.r.t. the vertical layer to which they apply. In the Volume, edited user requirements are presented for each Product in 05 Products. In a database, the corresponding table would have the following attributes: 06 Requirements Attributes: Product name, Volume, Application, Source, Accuracy unit, Accuracy threshold, Accuracy breakthrough, Accuracy objective, Horizontal resolution threshold, Horizontal resolution breakthrough, Horizontal resolution objective, Vertical resolution threshold, Vertical resolution breakthrough, Vertical resolution objective, Temporal resolution threshold, Temporal resolution breakthrough, Temporal resolution objective Linked to: 05 Products. 3.6 Overview The following figure provides an exemplary overview about how the different tables outlined above would be linked through relationships. Page 7 of 9

8 01 Satellites Meteosat 9 02 Instruments SEVIRI GERB 03 Channels 0.635µm 0.81µm Short wave Total radiance 04 Missions GEO VIS/IR imagery GEO Earth radiation budget 06 Requirements Cloud imagery Wind profile (horizontal component) 05 Products Cloud imagery Wind profile (horizontal component) Outgoing LW irradiance (TOA) Outgoing LW irradiance (TOA) Figure 1: Overview over the proposed database model 4 Summary This report gives an initial evaluation of the use of DOORS and some other related tools to support the migration of the information contained in the GOS Dossier to a suitable and sustainable requirements management system. The report is divided into an analysis of the DOORS capabilities w.r.t. to the general requirements upon a WMO database for the management of user requirements and observing system capabilities, and into an (almost) DOORS independent proposal for a data model used for the transformation of the GOS Dossier into a database. The first part clearly shows that although DOORS is well suited to implement the GOS Dossier in a database locally, it lacks the fundamental techniques to make the results dynamically available on line. Although as a work around the results could be made available in the form of static web pages, this will not fulfil the user requirements for dynamic database queries. In addition, the off line implementation complicates the conjoint maintenance of the database through the WMO members. The second part, although only scratching at the surface of the task, already shows that the resulting database will be of considerably complexity. Although its value for the user community, once the transformation into a database is achieved, is undoubted, it is questionable whether on the long term enough commitment and resources will be made Page 8 of 9

9 available by the WMO members to keep the database up to date. If this cannot be ensured, then the effort possibly put into the initial transformation would be wasted. As a summary it can be stated that DOORS could well be used a test bed for an initial, local implementation of a database version of the GOS Dossier, but that this is not expected to be the final solution. If the local results are promising and showing a general usefulness of the database implementation, then the transition from DOORS to a more on line oriented database architecture would be much easier than the initial transition from Word to DOORS. A last word of caution must be expressed w.r.t. Volume 4 of the Dossier which contains the result of the application of a conceptual performance model to a list of 30 generic instruments. Although the proposed database model is well suited to capture the final results, other means will have to be identified for the knowledge conservation w.r.t. the performance model and its application as well. If this cannot be achieved, then this part of the Dossier, or its representation in a database, will become a static element impossible to be updated in the future. Page 9 of 9