Medspiration â System Requirements Document - Data User Element

More documents

Recommendations

Info

Medspiration MED-SOC-RS-001_1 System Requirements Document Issue F The fourth module uses an appropriate DV model to estimate the SSTskin associated with each SSTfnd in the analysed field, evaluated every two hours through the 24 h period represented by the final L4 product. While the overall structure of the L4 processor is well defined, the detailed criteria and models used in each of the four models are not yet optimized by the user (GHRSST-PP). Indeed it is expected that experience with operating the processor is needed before the OI and DV models can be finally chosen. For this reason the L4 processor must be designed in a highly modular way, with the specifications of the internal functions of each module contained in configuration files. Match-up data records production at IFREMER The functions within the MDR production are shown in Figure 3-7. In situ measurements of SST are obtained form the CORIOLIS system in IFREMER. This provides a convenient single point access to data from a number of different networks of buos and other measurement platforms. In situ data can be expected to be up to several days old when they are finally made available by CORIOLIS. Therefore the MDR production cycle is operated periodically to find matches for all the in situ data that have come available since the previous run, irrespective of their actual age. The in situ data are matched with any available satellite data within prescribed spacetime overlap windows. A number of conditions are attached to the complexity of matching discrete point samples to spatially distributed satellite data, and these are contained in several system requirements. The MDR are then sent to the GHRSST-PP MDB. Dissemination of data from IFREMER IFREMER provides access to the archive of L2P and L4 products through the dissemination module. This provides three different services, an ftp push-pull server, a DODS server and a live access server (LAS). Control of Medspiration Processing at IFREMER Management of the various different Medspiration processing functions being carried out at IFREMER requires a controller to ensure that they operate smoothly. This gives rise to the requirements presented in 3.3.5. While many of these are not directly traceable to the user requirements documents, they are inherently implied by the need for an autonomously operating system. This system controller also acts as a central log for all © 2004 SOC Page 24 of 193
Medspiration MED-SOC-RS-001_1 System Requirements Document Issue F relevant error and operation messages provided by the various Medspiration systems wherever they are located. A selection of these log messages is then redirected to the GHRSST-PP central error log system. 2.3.3 Processing at SOC Figure 3-10 shows the part of the Medspiration processing system located at SOC. There are two main tasks to be performed, handling the ingest of the AATSR L2 global data, and extracting the diagnostic data set (DDS) granules of data from the main Medspiration archive at IFREMER. AATSR Ingestion Medspiration has a responsibility to extract the DDS granules from the AATSR for the whole world. This is in contrast with all the other data in Medspiration which cover European and Atlantic waters only. For this reason, and also to expedite AATSR data exchange between Medspiration and the ESRIN server, SOC will operate a mirroring function for AATSR data. From the AATSR data downloaded from ESRIN in Envisat format, the global DDS sites will be extracted and converted to netCDF format. Also the full data coverage of the EURDAC area will be extracted to provide the L2 input to the ingestion module at CMS. To avoid duplication of effort, the pixel location, viewing angle and sun angle information that is provided at a few tie points will be interpolated and attached to each pixel before transmission to CMS. Diagnostic data set generation at SOC The DDS granule generation for all sensors other than AATSR extends only to the European area DDS sites. As soon as data are entered into the IFREMER server the DDS granules will be extracted and MMR records sent to GHRSST-PP. Since the GHRSST-PP DDS is a distributed dataset, relying on the RDACs to house the data, it is implicit in the provision of DDS granules to GHRSST-PP that Medspiration should establish a DDS archive for the European DDS sites. This will be located at SOC. Associated with the DDS archive is an obligation of dissemination, leading to a requirement to serve the DDS data freely to external users. © 2004 SOC Page 25 of 193
Page 1 and 2: Medspiration System Requirements Do
Page 5 and 6: Medspiration MED-SOC-RS-001_1 Syste
Page 23: Medspiration MED-SOC-RS-001_1 Syste
Page 75 and 76:
Medspiration MED-SOC-RS-001_1 Syste
Page 77 and 78:
Page 79 and 80:
Medspiration System Requirements Do
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Page 191 and 192:
Page 193:
show all

Medspiration â System Requirements Document - Data User Element

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?

Medspiration â System Requirements Document - Data User Element