STATUS GISC/DCPC DEVELOPMENT IN RUSSIAN FEDERATION (Submitted by Leonid Bezruk (Russian))

1. STATUS GISC/DCPC DEVELOPMENT IN RUSSIAN FEDERATION (Submitted by Leonid Bezruk (Russian)) Summary and Purpose of Document This document describes the development of GISC in Moscow and DCPC in Obninsk ACTION PROPOSED The meeting is invited to note the report. ________________________________________________________________

2. Federal Hydrometereology and Environmental Monitoring Service planned to finish creation of prototypes GISC/DCPC in 2009. By this time also should the telecommunication infrastructure of the centres of telecommunications in WMC Moscow, WDC Obninsk and RTH Khabarovsk, Novosibirsk is modernised. However world financial crisis has introduced corrective amendments in our plans. Modernisation of a telecommunication infrastructure will come to the end in March, 2010. The tender for creation of prototypes GISC/DCPC is declared also we hope to place in operation GISC/DCPC in the first quarter 2011. INTRODUCTION

3. Links of RMDCN OBS/Equant (Exeter, Prague, Sofia, Norrkoping, Beijing, New-Delhi, Bucharest) were migrated from F/R to IPVPN MPLS network in June 2007 with success. Bandwidth of some links were extended during 2007-2009: - RTH Novosibirsk up to 512Kbps - RTH Khabarovsk up to 256 Kbps - NMC Minsk up to 128 Kbps Current status of RTH Moscow

4. In all centres of telecommunications the new network equipment (routers, switchboards, firewall and other equipment) is established. Control and managements of network resources are established also. We have fiber-optical cables on various directions to various providers. It has given the chance to increase essentially throughput of communication channels and to reserve them. It concerns also connections to the Internet which speed in Moscow makes 2х100Mbit/second and in the near future will be upgraded up to 1Gbit/second Its server part, and terminal continued to develop Satellite based data distribution system, both. Tests of technology of transfer of urgent messages (type of a tsunami, etc.) have been conducted successfully Modernisation of a telecommunication infrastructure.

5. MSS network software is based on TCP/IP procedures. Message Switching System in RTH Moscow was replaced in 2009. It consists of two sub-systems: operational and standby. In addition, there are a limited number of asynchronous connections. Russian broadcast system “Meteoinform” is also integrated to the system. TCP/IP Socket (Special) and FTP/WMO: are the basic data exchange protocol used. E-Mail: Messages can be received or transmitted via e-mail. WWW: A/N messages and FAX charts can be received via web-interface. . Modernisation of a telecommunication infrastructure.

6. It is recieved and transmited more than 50 types of the various information; The total of recieved messages exceeds 300 thousand; The total amount of recieved messages with observation data makes nearby 1,3Gb, and taking into account the processed information and the Internet more 50Gb; The average length of messages makes more 4Кb and fluctuates depending on a type of information from 100b to 130Кb. We expect, that the volume of the observation data (without satellite) within 4-5 years will increase not less, than at 8-10 time (at the expense of increase in frequency of observation, quantity of the observant platforms, new types of observation). In this period the increase in volume of the processed information to 1,5-3Тb (at the expense of the further increase in resolution of models, ensemble models and other kinds of production) is expected. Technical requirements to prototypes GISC/DCPC.The preliminary analysis of the recieved and transmited information

7. Technical requirements to prototypes GISC/DCPC.

8. The software of the GISC prototype shall support interaction with data sources and the DCPC prototype via uniform protocols, and be closely integrated with other GISC for synchronisation of metadata sets and cache data entry. The interaction between system nodes shall be at the level of data and be initiated on the portal side. When setting up the prototypes, the following shall be supported: performance of the main technological functions and operations of user authorization, selection of data sources, selection of resources for data search and support of access to data source for receiving request results. The prototype shall meet the following requirements: Have an own base of metadata, isolated from working bases; Automatically formed metadata shall be entered into the database; The base of metadata of the prototype shall be synchronised with databases of other sources and other GISC nodes; The prototype shall limit access to user data and templates by other subsystem users; The user interface shall be as simple and user-friendly as possible; it is required to support a work possibility of an untrained user in the subsystem; The prototype portal shall be documented and have a function of context-sensitive help; The prototype portal shall have a user interface for work via Internet; The prototype portal shall support work in the Linux environment; the client part of the subsystem shall work with most common browsers, such as Microsoft Internet Explorer, Opera, Avant, Gecko (Firefox, Mozilla, Netscape); Requirements for the Subsystem as a Whole

9. The GISC prototype shall be physically separated from DCPC data sources at the hardware level for the purpose of preventing unauthorized access to DCPC data. At the same time, information interaction between the portal and DCPC shall be implemented. When setting up the prototypes, it is required to carry out all the tests of automatic metadata formation and entry into the system. The database of the GISC prototype shall include, at least, operational data and products for international exchange over the latest 24 hours. Requirements for Subsystem Structure and Functioning

10. The user shall have access to the following functions: Get information about available data sources of DCPC; Select a required data source; Form a request for data retrieval; Receive a reference to the formed data block in the DCPC data source; Subscribe for regular data receipt; View the subscription status or change its parametres. There shall be no limitations on the number of users who work with the system in the operational mode at the same time. The administrator of the GISC prototype shall have access to the following functions: View accounting records of registered users; Manage accounting records of users; Perform operations to create backup copies of the database and to recover data after failures; Manage procedures of metadata synchronisation with sources of DCPC and other GISC. Requirements for Subsystem Structure and Functionign

11. The GISC/DCPC prototypes shall be mobile and portable and flexible enough to changes. The prototype software shall be flexible enough to used metadata formats and interaction protocols with DCPC data sources and other GISC portals. Prototype setup shall be performed, as much as possible, by means of changing setting parametres, without additional changes in the application software. The prototype software shall enable extending the list of used interaction protocols with DCPC data sources and other GISC portals, without a need to change the software. The prototypes shall support acceptable performance of the key technological operations, subject to compliance with the requirements for the subsystem hardware and staff. Targeted Characteristics

12. Information security at the level of data access shall be implemented by means of the following tools in the portal software list, ensuring data protection against unauthorized access: • User identification by personal data; • Distribution of access preferences to data and functions using the role mechanism; • Protection of DCPC data against unauthorized access via the portal. Requirements for Information Protection against Unauthorized Access

13. The subsystem software shall automatically recover its functioning in case of a correct restart of the hardware. A possibility of backup copying shall be designed using standard tools included into the software. Data integrity shall be ensured in case of data destruction under mechanical and electronic failures and malfunctions in server operations on the following basis: • Information recovery procedures using stored copies of databases; • Change logs in databases; • Software copies. Requirements for Data Integrity under Failures

14. SW DBMS shall be a central component of the architecture of the system to be built, to implement mechanisms of storing spatial and attributive data, indexation and access delimitation SW Application Server shall be compatible with SW DBMS. As Application Server, software of the application level shall be used, to resolve the following tasks: Support client systems operating on different hardware and software platforms; Ensure connection with SW DBMS and other services of the third level; Provide infrastructure services, such as transaction management, authentication, access delimitation, workload balancing, etc.; Provide application functionality, with an obligatory possibility of expanding it. Software

15. The Application Server shall include the following elements: Web server; Object request broker; Specialized modules or applications: To execute stored procedures written in the PL/SQL language in SW DBMS and tools to organise calls of stored procedures by means of HTTP and HTML; To execute Java applications (virtual Java machine) for applications to the database by means of the JDBC interface or with the help of Java classes; To execute applications written in the C language for programming service functions called by the Application Server; To interpret include files on the server side enabling inclusion of dynamic data into HTML documents; SW– Application Software of DCPC SW – Application Software of GISC Software

16. The work scope shall include the following activities: Supply required hardware and software; Provide an order of fulfilling the technical requirements as described in paragraph 1.3.1 (WIS-TechSpecs, See Annex A) and develop a plan for confirming them; Install the GISC/DCPC prototypes (hardware and software), adjust the software according to the Consignee’s requirements; Develop a Program and Methodology to confirm the requirements of WIS-TechSpecs Develop recommendations about further modernisation of the GISC/DCPC prototypes (if necessary); Scope of Works

17. Questions?

18. Thanks for attention!