Get documents about "TECHNICAL SPECIFICATIONS - Get Now PDF
Document Sample
EUMETNET CONTRACT
for
Technical Specification of Automatic Weather Stations
TECHNICAL SPECIFICATIONS
OUTPUT OF PHASE 2
Final Version – 10 April 2000
prepared by:
ITALIAN AIR FORCE METEOROLOGICAL SERVICE
- Ufficio Generale per la Meteorologia -
Authors:
T.Col L. De Leonibus, Dott. U. Vecchi
revised in accordance to the
Steering Committee
Approved by
AWS project manager L. De Leonibus
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
TECHNICAL SPECIFICATIONS
SUBJECT: EUMETNET AWS (Automatic Weather Station) CONTRACT-
TECHNICAL SPECIFICATIONS.
REFERENCES.
A EUMETNET AWS REPORT OF SURVEY- FIRST OUTPUT OF PHASE 1,
July 1999.
B WMO INSTRUMENT AND OBSERVING METHODS REPORT N° 65:
GUIDANCE ON AUTOMATIC WEATHER SYSTEMS AND THEIR
IMPLEMENTATION, WMO/TD N° 862; 1997.
C WMO MANUAL N° 8, Sixth edition 1996: Guide to Meteorological
Instruments and Methods of Observation.
D ICAO ANNEX 3, Twelfth edition – July 1995: Meteorological service
for international air navigation.
E WMO – N° 306, 1995 edition: Manual on Codes.
F ICAO DOC. 7488/3; Third edition 1993: Manual of the ICAO standard
atmosphere.
G ICAO DOC. 9328-AN/908; First edition 1981 (in course of updating);
Manual of Runway Visual Range Observing and Reporting Practices.
INDEX
1 ROLES OF THE AWS.
2 GENERAL REQUIREMENTS.
a AUTOMATIC OPERATIONS.
b HARDWARE/FIRMWARE MODULARITY AND EXPANDABILITY.
c HARDWARE/FIRMWARE SCALABILITY AND EXPANDABILITY.
d SOFTWARE CONFIGURATION AND FLEXIBILITY.
e COMMUNICATIONS.
f LOGISTIC MANAGEMENT AND MAINTENANCE OF THE AWS
NETWORK.
g ON-LINE DATA ARCHIVE.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
1/72
3 SENSORS CONFIGURATIONS.
a SYNOPTIC AWS.
b AIRPORT AWS.
4 CONSIDERATIONS ABOUT THE SYSTEM ARCHITECTURE OF THE
AWS.
a THE PROPOSED FUNDAMENTAL SYSTEM ARCHITECTURE OF
THE AWS.
b VARIOUS TYPES OF EXISTING AWS SYSTEM ARCHITECTURES.
(1) “FIRST TYPE” AWS.
(2) “SECOND TYPE” AWS.
5 THE AWS SYSTEM ARCHITECTURE.
6 EXPANDABILITY AND REDUNDANCY.
7 METEO VARIABLES ACCURACY.
8 METEO VARIABLES CLASSIFICATION.
9 SENSORS CLASSIFICATION.
10 SENSORS DTE OUTPUT RATE CRITERIA.
11 SENSORS DTE OUTPUT RATE.
12 SENSORS STATUS CODE.
13 VALIDITY CHECKS.
14 AWS ELABORATION OF INSTANTANEOUS DATA.
15 AWS ELABORATION OF THE DERIVED METEO VARIABLES.
16 SENSORS UNITS DATA THROUGHPUTS.
17 THE CONCENTRATOR.
18 DATA ACQUISITION TASKS.
19 TRUSTED BASE TASKS.
20 ENVIRONMENTAL CONDITIONS.
21 POWER SUPPLY.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
2/72
22 REMOTE COMMUNICATIONS.
LIST OF FIGURES:
1 GENERAL BLOCK DIAGRAM OF THE PROPOSED FUNDAMENTAL
AWS SYSTEM ARCHITECTURE.
2 GENERAL BLOCK DIAGRAM OF THE EXISTING “1° TYPE” AWS
SYSTEM ARCHITECTURE.
3 GENERAL BLOCK DIAGRAM OF THE EXISTING “2° TYPE” AWS
SYSTEM ARCHITECTURE.
4 BLOCK DIAGRAM OF THE AWS SYSTEM ARCHITECTURE.
5 BLOCK DIAGRAM OF THE AWS SYSTEM ARCHITECTURE. THE USE
OF THE BUS AS CONCENTRATOR.
6 BLOCK DIAGRAM OF THE AWS SYSTEM ARCHITECTURE.
EXPANDABILITY AND REDUNDANCY.
LIST OF ANNEXES:
A SENSORS DTE OUTPUT RATES.
B SENSORS STATUS CODES.
C SENSORS OUTPUT AVERAGING TIME (COPY OF PAGES FROM THE
WMO N° 8 MANUAL).
D ELABORATION OF WIND INSTANTANEOUS DATA (COPY OF A PAGE
FROM THE WMO N° 8 MANUAL).
E HUMIDITY ALGORITHMS (COPY OF A PAGE FROM THE WMO N° 8
MANUAL).
F ALGORITHMS OF DEW POINT AND VIRTUAL TEMPERATURE.
G ALGORITHMS OF ATMOSPHERIC PRESSURE REDUCTIONS.
H ALGORITHMS FOR THE DETERMINATION OF THE RVR DATUM.
I TABLES OF CODES AND FORMATS.
J MARKED DISCONTINUITY.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
3/72
1 ROLES OF THE AWS.
According to Ref. A considerations, the following two main roles are
indicated for the AWS:
- REAL-TIME SYNOPTIC; where:
. real-time means the capability of transmitting the synoptic
meteo messages, remotely, to the central NMSs (National
Meteo Services) with a typical frequency update of one
message every ten minutes;
. a real-time synoptic role fully includes the other classes of
AWSs like the:
* limited capability and agricultural ones,
* climatological one
but not the airport one;
- REAL-TIME AIRPORT; where:
. real-time means the capability of transmitting:
* the routine airport meteo messages, remotely, to the
central NMSs with a typical frequency update of one
message every half an hour;
* the special airport meteo messages, remotely, to the
central NMSs anytime pre-defined alarm criteria are met;
* the airport meteo information, locally, to the ATC (Air
Traffic control) offices with a typical frequency update of
one information every one minute.
. a real-time airport AWS is usually expanded to include also the
capabilities of a real-time synoptic AWS.
2 GENERAL REQUIREMENTS.
According to Ref. A considerations, the following general requirements
are indicated.
a AUTOMATIC OPERATIONS.
The AWS should be able to perform the maximum of possible
automatic operations to reduce the need (and corresponding high
cost) for 24 hours manned stations.
b HARDWARE/FIRMWARE MODULARITY AND EXPANDABILITY.
The AWS should be composed by elementary hardware/firmware
modules so that it would be expandable with modularity just adding
new such hardware/firmware components, for example:
- if additional sensors are needed, new input hardware/firmware
modules would simply have to be added without changing the
pre-existing hardware/firmware architecture;
- if new outputs to NMS or DATA presentations are needed, new
output hardware/firmware modules would simply have to be
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
4/72
added without changing the pre-existing hardware/firmware
architecture; etc.
c HARDWARE/FIRMWARE SCALABILITY AND EXPANDABILITY.
Any AWS hardware/firmware module should be scalable to fit,
properly, the expandability of the system, for example:
- if the AWS CPU (Control Processing Unit) would have to be
substituted by another one more powerful because the general
system architecture has expanded to the maximum of the
processing capabilities of the old CPU;
- then the new CPU should substitute the old one without the
need of changing anything in the rest of the system
architecture.
d SOFTWARE CONFIGURATION AND FLEXIBILITY.
It should be possible to classify and report all the AWS software
possible performances in a basic general configuration table.
Therefore, the AWS behaviour should vary with flexibility according
to the variations of this general configuration table setting, for
example:
- the AWS should activate new sensors or deactivate old ones in
function of the specific configuration table setting;
- the AWS should activate new kind of input data
filtering/averaging or deactivate old ones in function of the
specific general configuration table setting; etc.
e COMMUNICATIONS.
The meteo messages should be collected by the central NMS via
transmission:
- at scheduled times
- and/or on alert
- and/or on request.
f LOGISTIC MANAGEMENT AND MAINTENANCE OF THE AWS
NETWORK.
As regards the logistic management and maintenance of the AWS
network, it is considered necessary that:
- the activities of analysis and diagnostic of the behaviour of the
AWS network would be centralised;
- the monitoring central officer would be the one responsible of
requesting the eventual intervention of a field engineer.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
5/72
g ON-LINE DATA ARCHIVE.
The minimum period of time to keep the representative data ON-
LINE within the AWS mass memory should be:
- 5 days for the one minute data;
- 1 month for the messages/ten minutes data.
This ON-LINE data archive is considered necessary because:
- it would facilitate later collection of data in the event that
communications links are temporarily disrupted;
- it would allow for ON-LINE local simple information retrieval
without the need of interrogating the central database.
3 SENSORS CONFIGURATIONS.
The following sub-paragraphs report examples of possible minimum and
maximum AWS sensors configurations (as they were discussed in Ref. A)
to evidence how it would be important that the above said AWS
expandability and flexibility capabilities be truly effective.
At this point, i.e. while considering sensors configurations, however, it is
just worthwhile to remember that:
- a proper sensors siting is necessary to ensure the validity of the
measurements performed by the AWS;
- sensors siting criteria are not part of these specifications but Ref. B
and C. are quite exhaustive about them.
a SYNOPTIC AWS.
According to Ref. A, some of the NMS members require that, in a
synoptic AWS, sensors measuring the same meteo variable could be
present:
- twice because the redundancy of the same measurement was
needed;
- several times because various measurements, of the same type
but representative of different points around the AWS, were
needed.
Therefore the following maximum amount number of sensors (n° x)
has been retained for the definition of a synoptic AWS configuration:
- ESSENTIAL:
. Air temperature, n° 3;
. Relative humidity or in alternative dew point
temperature, n° 3;
. Atmospheric pressure, n° 3;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
6/72
. Wind speed/direction or in alternative Wind
components, n° 3;
. Precipitation amount, n° 2;
- HIGHLY DESIRABLE:
. Cloud base height, n° 1;
. Cloud amount, n° 1;
. MOR (forward scatter), n° 1;
. Present weather, n° 1;
- DESIRABLE:
. Ground temperature (=0 level), n° 1;
. Soil temperature (<0 level), n° 5;
. Depth of snow, n° 1;
. Global solar radiation, n° 1;
. Sunshine duration, n° 1;
- OPTIONAL:
. Air temperature at precipitation gauge, n° 1;
. Wet bulb temperature, n° 1;
. Diffuse solar radiation, n° 1;
. Longwave radiation, n° 1;
. Total radiation, n° 1;
. Net total radiation, n° 1;
. Soil heat flux, n° 1;
. Background luminance, n° 1;
. Lightning (counter), n° 1;
. State of the ground, n° 1;
. Soil moisture, n° 1.
It can be, then, concluded that the sensors synoptic AWS
configuration could vary from a minimum of 2 sensors (in the case of
limited capability and/or climatological AWS) to a maximum of 41
sensors.
b AIRPORT AWS.
The airport AWS, because of its specific nature, has to manage
several measurements of the same type but representative of
different points around the airport.
The ICAO annex 3 (see ref. D) is quite specific in this question and
gives the following representative points for an airport with one
runway:
- Airport area;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
7/72
- Landing area;
- Take off area;
- Touch Down Zone (TDZ);
- Middle runway (MID);
- End runway (END).
Therefore the following maximum amount number of sensors (n° x)
has been retained for the definition of a one runway airport AWS
configuration:
- ESSENTIAL:
. Air temperature, n° 2;
. Relative humidity or in alternative dew point
temperature, n° 2;
. Atmospheric pressure, n° 2;
. Wind speed/direction or in alternative Wind
components, n° 2;
. MOR (Transmissometer), n° 3;
. Background luminance, n° 2;
. Cloud base height, n° 2;
- HIGHLY DESIRABLE:
. Cloud amount, n° 1;
. MOR (forward scatter), n° 1;
. Present weather, n° 1;
- DESIRABLE:
. Precipitation amount, n° 1;
. Ground temperature (=0 level), n° 1;
. Soil temperature (<0 level), n° 5;
. Depth of snow, n° 1;
. Sunshine duration, n° 1;
. Global solar radiation, n° 1;
- OPTIONAL:
. Air temperature at precipitation gauge, n° 1;
. Runway surface temperature, n° 1;
. Winds components height profile, n° 1;
. Longwave radiation, n° 1.
It can be, then, concluded that the sensors airport AWS
configuration could vary:
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
8/72
- from a minimum of 17 sensors (just the essential ones) for one
runway;
- to a maximum of 20 sensors (essential ones plus highly
desirable ones) for one runway;
- to a maximum of 34 sensors (essential ones plus highly
desirable, desirable and optional ones) for one runway;
- to a maximum of 102 sensors (five times the essential ones
plus one time the highly desirable, desirable and optional ones)
for 5 runways.
4 CONSIDERATIONS ABOUT THE SYSTEM ARCHITECTURE OF THE
AWS.
a THE PROPOSED FUNDAMENTAL SYSTEM ARCHITECTURE OF
THE AWS.
As work-base for the Ref. A survey, an “AWS FUNDAMENTAL
SYSTEM ARCHITECTURE” was proposed.
The general block diagram of this fundamental AWS system
architecture is reported in the annexed figure 1.
Such architecture identifies two main objects: the Sensor Unit and
the CPU; the first one is responsible of transducing the external
physical entity in a digital basic message (the instantaneous
DATUM); the second one accepts the DATUM and inserts it (after
processing) into an information/message which is sent to the
Meteorological Centre.
There were, indeed, no new technical concepts in the proposed
architecture as it follows the guidance provided by Ref. B and C.
Once agreed however, it provided a basis for further conclusions:
- the AWS CPU is the logical centre of a star network of point-
to-point connections to the peripheral source sensors units and
the remote destination computers;
- the AWS CPU should be a COTS (Commercial Off The Shelf)
standard computer with, no special internal configuration but
the including various standard DTE (Data Terminal Equipment)
ports for serial digital data transmission;
- the pair of DCE (Data Circuit-terminating Equipment) between
the AWS CPU DTE port and the sensor unit DTE port should
be no special equipment but COTS standard data transmission
support components ( only necessary if, for installation
problems, the distance between the two DTE ports would be
longer then the one accepted by the driving capability of the
DTE ports themselves);
- the pair of DCE between the AWS CPU DTE port and the
remote destination computer DTE port should be no special
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
9/72
equipment but COTS standard components to support the data
transmission on the available remote communication link;
- in the case of a complex manned AWS (for example an airport
one), peripheral equipment (“Terminals”), have to be provided
either for input of visual observation or for presentation of the
information to operational users, therefore:
. the AWS CPU would still be the logical centre of the star
shaped network of point-to-point connections including
those to the Terminals
. these Terminals should be COTS standard configured
computers;
. if these Terminals had to be installed at a distance, there
would be DTE/DCE point-to-point connections between
the central AWS CPU and each Terminal;
. if these Terminals had to be installed locally, then a
standard LAN (Local Area Network) should be used to
connect the central AWS CPU with the Terminals;
- the sensor unit is composed by two elements:
. the sensor itself responsible for transducing, with a
certain time constant and accuracy, the meteo entity into
an electric signal;
. the DTE interface responsible for reading, with a certain
frequency, this electric signal and converting the reading
in a standard digital information to be transmitted, via the
DTE port, to the CPU;
any single DTE output value is defined and considered as the
instantaneous DATUM for that meteo variable.
The fundamental architecture described above could be synthesised
in the following general two statements which should always be
considered when assessing an AWS:
- any meteorological sensor would end, logically, only at a DTE
standard digital output (i.e. the instantaneous data stream)
where its characteristics can be, defined by three parameters:
accuracy; time constant; DTE output rate;
- behind the DTE standard digital output point, the AWS block
diagram would consist only of standard COTS computer
equipment (as the basic function of a standard computer is to
manage data streams).
b VARIOUS TYPES OF EXISTING AWS SYSTEM ARCHITECTURES.
As indicated in Ref. A, the survey gave the possibility of classifying
the various existing AWS system architectures in two types.
The following text describes these two types and reports examples
and discussions about how the functional concepts, introduced in the
precedent paragraph, are applied to real AWS system architectures.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
10/72
(1) “FIRST TYPE” AWS.
The general block diagram of the “1° type” AWS is shown in
the annexed figure 2.
This architecture could be defined as the “traditional” one.
In particular the figure 2 shows that:
- the logical point to point data flows (from the peripheral
sensors to the central AWS CPU) coincide with physical
point to point lines;
- the so-called intelligent sensors are connected to the
AWS CPU via a standard RS232 (DTE) channel, the
modems (DCE) being needed only if the distance between
the sensor and the AWS CPU would be more than about
20m;
- the analogue outputs of the remaining sensors are
connected to Analogue/Digital interfaces internal to the
AWS CPU.
This “1° type AWS” block diagram looks quite equivalent to the
proposed fundamental one except for the block related to the
management of the analogue sensors where the A/D interfaces
are internal to the AWS CPU instead of internal to the Sensor
Unit.
In spite of this difference, the fundamental system check point
of the DTE standard digital output (where the sensor
characteristics have to be assessed) is present not physically
but as a logical entity within the AWS CPU.
(2) “SECOND TYPE” AWS.
The general block diagram of the “2° type” AWS is shown in
the annexed figure 3.
In particular the figure 3 shows that:
- all the sensors are intelligent, in particular:
. the ones, already outputting the data via a RS232
DTE, are connected via a RS232/BUS standard
interface to a DCE BUS standard (which could be
RS485 or CAN standard);
. the ones, with analogue output, are expanded with a
DTE interface:
* performing the A/D conversion and the data
transmission;
* connected via a DTE/BUS standard interface to
the DCE BUS standard;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
11/72
- the logical point to point data flows (from the peripheral
sensors to the central AWS CPU):
. do not coincide with physical point to point lines, like
in the case of figure 2, because the common DCE
BUS is used;
. but, from a logical point of view, are still there, and
the sum of their data throughputs results in the
communication workload:
* for the common BUS itself
* and the BUFFER of the only receiving port of
the AWS CPU.
With reference to the above said architecture, it has, also, to be
said that:
- the DTE interfaces for sensors like Wind direction, speed
(where a high throughput of data is coming from) were
intelligent enough to elaborate the various mean values,
extremes, etc. so that the data throughput toward the
common BUS could be reduced;
- it was important that the algorithms (to elaborate the said
mean values, extremes, etc.) were quite standard and
defined/controlled by the meteorologist as if they had to
be performed by the AWS CPU.
Comparing this architecture versus the proposed fundamental
one, it can be concluded that, this time, the “fundamental” one
is included from a logical point of view in the “2° type AWS”
architecture, which can be said to go even further in the sense
that:
- like in the case of the “fundamental” one, the A/D
conversions, DTE standard digital output were included in
the sensor unit;
- unlike the case of the “fundamental” one:
. not only the minimum of intelligence was given to the
sensors units to output instantaneous values as DTE
information sources
. but also intelligence was given to elaborate mean
values, extreme, etc.
5 THE AWS SYSTEM ARCHITECTURE.
According to the considerations reported in the precedent paragraph 4,
the proposed fundamental architecture of figure 1 is still kept as the
logical reference of AWS SYSTEM ARCHITECTURE for this document
because:
- it evidences the effective logical point to point star connections (from
the sensors to the AWS CPU) which, from a physical point of view:
. could become BUS/LAN connections;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
12/72
. or could remain STAR connections as well;
- it considers the DTE interface as a very simple one outputting just
instantaneous data (and not averaged data, extremes, etc.) so that
the meteo variable information are followed from the very elementary
point of view.
The figure 4 shows further details of functional AWS components to be,
logically, included within the fundamental AWS system architecture of
figure 1.
Considerations about figure 4 are listed below:
- the necessary logical function of concentration of the input sensors
data is evidenced;
this function has been represented with a module called
CONCENTRATOR and situated, in the block diagram, out of the
CPU block;
it is stressed that:
. while, from a logical point of view, the CONCENTRATOR
module must always be present in any AWS;
. from a technical point of view, this module could consist:
* either in a dedicated typical DATA CHANNELS
CONCENTRATOR equipment
* or in the standard BUS equipment (RS485/CAN/etc. as
introduced in figure 3);
figure 5 evidences the peculiar concentration components for
which the use of the BUS equipment would be an alternative;
- the AWS CPU should consist in a COTS STANDARD COMPUTER
supporting the following principal software modules:
. the central FILE SERVER which would be the hearth of the
system providing:
* the METEO DATA TABLES, archive of the continuously
updated meteo data;
* the CONFIGURATION DATA TABLES, archive of the
AWS configuration data;
* the SECURITY DATA TABLES, archive of the information
about the “NEED TO KNOW” USERS profiles;
. the DATA ACQUISITION TASKS which would be responsible
for acquiring the data from the sensors and archiving them in
the central METEO DATA TABLES;
. the TRUSTED BASE TASKS which would control, on a need to
know basis, the access (reading or updating) of the users to the
data in the central FILE SERVER.
It is evidenced that the AWS reference time has to be the AWS CPU FILE
SERVER time.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
13/72
The presentations in figures 4 and 5 allow for a complete definition of the
following hardware/firmware and software basic modules by which the
AWS system configuration could be expanded.
- HARDWARE/FIRMWARE MODULES:
. SENSOR UNIT;
. DCE;
. BUS;
. CONCENTRATOR;
. STANDARD COMPUTER;
. LAN;
- SOFTWARE MODULES:
. FILE SERVER;
. DATA ACQUISITION TASKS;
. TRUSTED BASE TASKS.
6 EXPANDABILITY AND REDUNDANCY.
The scenario of how to expand with modularity and scalability the AWS
SYSTEM ARCHITECTURE is indicated in the annexed figure 6.
With reference to this figure and considering:
- the case of the SYNOPTIC AWS with 41 SENSORS UNITS,
discussed in the precedent paragraph 3, the following guidelines of
design could be applied:
. the 41 sensors units could be divided into groups and every
group could be clustered to one CONCENTRATOR,
. every CONCENTRATOR would transmit the data to a
STANDARD COMPUTER configured only with the DATA
ACQUISITION TASKS software module which, via the LAN,
would archive the data on the common central FILE SERVER
software module;
. the FILE SERVER software module would be resident only on
one STANDARD COMPUTER of the LAN therefore:
* it would be common to all the DATA ACQUISITION
TASKS software modules;
* there would be no need of archives duplicated in cascade
and, consequently, no related problems with the
coherence of the data;
- the case of the AIRPORT AWS with 102 SENSORS UNITS, also
discussed in the precedent paragraph 3, the following guidelines of
design could be applied:
. at any representative point of the airport (Landing area, TDZ,
MID, etc.) the appropriate group of SENSORS UNITS and a
CONCENTRATOR clustering them would be installed;
. every peripheral CONCENTRATOR would transmit, remotely
via DCEs, the data to a central (in the METEO OFFICE
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
14/72
equipment room) STANDARD COMPUTER configured only
with the DATA ACQUISITION TASKS software module which,
via the LAN, would archive the data on the common central
FILE SERVER (always in the METEO OFFICE equipment
room);
. again, the FILE SERVER software module would be resident
only on one STANDARD COMPUTER (always in the METEO
OFFICE equipment room) of the LAN therefore:
* it would be common to all the DATA ACQUISITION
TASKS software modules;
* there would be no need of archives duplicated in cascade
and, consequently, no related problems with the
coherence of the data.
Also in figure 6, it is shown that the STANDARD COMPUTER with the
central FILE SERVER, which would represent, the heart of the AWS
architecture, could be duplicated for redundancy.
With reference to the above statements, It is underlined that:
- regarding LAN standards, the “state of the art” COTS market offers
various solutions of HOT STAND BY CLUSTERED COMPUTERS
for ON LINE REDUNDANCY;
- furthermore, just because of the fact that STANDARD COMPUTERS
and STANDARD DTE/DCE INTERFACES would be used, the
maximum of scalability capabilities would be achievable thanks to
the COTS market basic tendency of offering a full line of
interoperable products going from the less powerful ones (entry
level) to the most powerful ones (top level).
7 METEO VARIABLES ACCURACY.
According to the conclusions of Ref. A, the following characteristics of
METEO VARIABLES ACCURACY are indicated.
Meteo_variable Accuracy
Air temperature 0.2K
Ground temperature (=0 level) 0.3K
Soil temperature (<0 level) 0.3K
Relative humidity 5%(<=50%), 3%(>50%)
Dew point temperature 0.5K
Wet bulb temperature 0.2K
Atmospheric pressure 0.3hPa
Cloud base (Cloud amount) 2octa
Cloud base (Height) 10m(<=100m), 10%(>100m)
Wind speed 0.5m/s(<=5m/s), 10%(>5m/s)
Wind direction 5°
Precipitation amount 5%
Depth of snow 2.5cm
Sunshine duration 3%
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
15/72
Global solar radiation 5%
Diffuse solar radiation 7%
Longwave radiation 5%
Total radiation 0.4MJ/m2/day(<=8MJ/m2/day), 5%(>8MJ/m2/day)
Net total radiation 0.4MJ/m2/day(<=8MJ/m2/day), 5%(>8MJ/m2/day)
Soil heat flux 10%
MOR (General visibility) 20%
MOR (Transmittance) 1%
Background luminance 5cd/m2(<=50cd/m2), 10%(>50cd/m2)
Present weather 30%
Lightning (Counter) N.A. (state of the art)
State of the ground N.A. (state of the art)
Soil moisture 10%
The above indicated accuracy characteristics are the recommended ones:
- to be checked, at the DTE OUTPUT SENSOR UNIT test point;
- concerning only instrumental uncertainty i.e. the one verifiable in the
tests laboratory, not necessarily in the field.
In the table above, as defined by ref. C “any stated value of required
accuracy represents the uncertainty of the reported value with respect to
the true value and indicates the interval in which the true value lies with a
probability of 95 per cent”.
It is the responsibility of the NMSs to establish and certify the field
performance level of the sensors through proper field testing campaigns.
8 METEO VARIABLES CLASSIFICATION.
According to the conclusions of Ref. A, which are synthesised in annex A,
the following classification of meteo variables is indicated:
Variable
Dynamic
Two states dynamic
Coded dynamic
Always growing
Static
Where:
- a dynamic variable is a variable containing small scale frequencies
which have to be filtered;
- a two states dynamic variable is a dynamic variable, as already
defined, which is then transformed in only two states: the low one
when the variable is lower than a condition value; the high one when
the variable is higher than a condition value;
- a coded dynamic variable is a dynamic variable, as already
defined, the values of which are not numeric but codes from a
standard defined table;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
16/72
- an always growing variable is a variable always growing within a
range from zero to a maximum which becomes a discontinuity point
because of the successive immediate passage of the variable value
from the maximum to zero again;
- a static variable is a variable presenting a low dynamical range with
no small scale frequencies which have to be filtered.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
17/72
9 SENSORS CLASSIFICATION.
According to the conclusions of Ref. A, which are synthesised in annex A,
the following classification of sensors is indicated:
Sensor
Linear Transducer & A/D converter
Linear Transducer & Threshold trigger
Fast measuring computer based device
Pulse generator & Counter
Slow measurements computer based device
Where:
- a Linear Transducer & A/D converter is a sensor:
. performing as a linear transducer, i.e. the sensor converts,
linearly, introducing a certain Time constant, the meteo
quantity to an electrical signal;
. providing a DTE interface data acquisition based on a A/D
converter;
- a Linear Transducer & Threshold trigger is a sensor:
. performing as a linear transducer, i.e. the sensor converts,
linearly, introducing a certain Time constant, the meteo entity
to an electrical signal;
. providing a DTE interface data acquisition based on a Digital
threshold trigger;
- a Fast measuring computer based device is a sensor performing
computer based fast measurements, i.e.:
. the time needed by the sensor to elaborate a representative
measurement of the dynamic variable is of the same order than
the period of the small scale frequencies which have to be
filtered;
. therefore, there is a need for the sensor to perform a further
measurements average;
with a certain Time of average;
- a Pulse generator & Counter is a sensor:
. performing a pulse generation, i.e. generating a pulse every
defined amount;
. providing a DTE interface data acquisition based on a
counter;
- a Slow measurements computer based device is a sensor
performing computer based slow measurements, i.e.:
. the time, needed by the sensor to elaborate a representative
measurement of the dynamic variable, is greater than the
period of the small scale frequencies which have to be filtered;
. therefore, there is no need for the sensor to perform a further
measurements average;
with a certain Time of measurement.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
18/72
10 SENSORS DTE OUTPUT RATE CRITERIA.
According to the conclusions of Ref. A, which are synthesised in annex A,
the following criteria for defining DTE OUTPUT RATES are indicated:
Variable Sensor DTE_output_rate
Dynamic Linear Transducer & A/D converter 1 output every Time constant
Dynamic Fast measuring computer based device 1 output every Time of average
Dynamic Slow measurements computer based device 1 output every Time of measurement
Two states dynamic Linear Transducer & Threshold trigger 1 output every Time constant
Coded dynamic Slow measurements computer based device 1 output every Time of measurement
Always growing Linear Transducer & A/D converter 1 output every 60s
Always growing Pulse generator & Counter 1 output every 60s
Static Linear Transducer & A/D converter 1 output every 60s
Static Slow measurements computer based device 1 output every 60s
11 SENSORS DTE OUTPUT RATE.
In consideration of the definitions introduced in the precedent paragraphs
and according to the conclusions of Ref. A, the SENSORS DTE OUTPUT
RATES are reported in the annex A table.
12 SENSORS STATUS CODE.
In consideration of the definitions introduced in the precedent paragraphs
and according to the conclusions of Ref. A, the annex B table reports the
capabilities of information which the SENSORS STATUS CODES should
insure (i.e. the sensor unit should be the source of this information).
13 VALIDITY CHECKS.
In consideration of the definitions introduced in the precedent paragraphs
and according to the conclusions of Ref. A, the following table defines
the AWS VALIDITY CHECKS which should be performed for the various
variables (i.e. the AWS CPU should perform these checks).
Variable 1 2 3 4
Dynamic Data domain Max data variation Vs time Min data variation Vs time
Two states dynamic Data domain
Coded dynamic Data domain
Always growing Data domain Max data variation Vs time Discontinuity point
Static Data domain Max data variation Vs time Min data variation Vs time
According to the general requirements of SOFTWARE CONFIGURATION
AND FLEXIBILITY, the End User should be able to vary, in the
CONFIGURATION DATA TABLES, parameters like the following:
- Extremes of data domain;
- Max data variation Vs time;
- Min data variation Vs time;
- Discontinuity point.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
19/72
14 AWS ELABORATION OF INSTANTANEOUS DATA.
After the STATUS and VALIDITY CHECKS, the AWS should perform the
elaboration of the INSTANTANEOUS METEO DATA for obtaining the
proper REPRESENTATIVE METEO DATA to be inserted in the
messages.
This elaboration should consist in the:
- typical averaging of the instantaneous data performed as indicated
by the Ref. C standard recommendations reported in the annex C
table;
- detection of meteo variables marked discontinuities (i.e. WIND and
RVR, for aviation purposes) as requested by Ref. D and E
recommendations.
Considering the Ref. A requirements indicating that:
- “locally at the AWS sites, systems with as little as possible
intelligence should be placed”;
- “in future projects, AWS software must reduce to the minimum
required for performing the basic tasks to be locally performed”
the above defined:
“elaboration of the INSTANTANEOUS METEO DATA for obtaining the
REPRESENTATIVE METEO DATA to be inserted in the messages”
looks like the optimum level of performance, to be asked locally to the
AWS, offering the following cost/performance advantages:
- the AWS would serve, immediately and independently from the NMS
centre, End Users who need international standard messages like
SYNOP and/or METAR/SPECI for their operational duty;
- the NMS centre would be able to perform any sort of further data
elaboration just asking the AWS for more frequent representative
meteo data transmissions (i.e., typically, one message every ten
minutes).
According to the general requirements of SOFTWARE CONFIGURATION
AND FLEXIBILITY, the End User should be able to vary, in the
CONFIGURATION DATA TABLES, parameters like:
- time periods of averaging;
- criteria for the detection of the marked discontinuity.
The minimum number of valid instantaneous data (i.e. data which passed
the status and validity checks), necessary to elaborate a representative
data average, should be the one covering the 50% of the related period of
averaging.
Also this “percent” parameter should be, anyway, considered in the
CONFIGURATION DATA TABLES and be variable by the End User.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
20/72
The WIND should be considered as a vector . The WIND DIRECTION
and SPEED (or WIND VELOCITY NORTH/EAST COMPONENTS)
instantaneous values, which are specific in comparison to other meteo
variables because of their heavy data throughput (i.e. one datum every
second), should be elaborated according to the realistic way suggested by
Ref. C page I.5-6 and evidenced in annex D.
15 AWS ELABORATION OF THE DERIVED METEO VARIABLES.
Bearing in mind the same Ref. A requirements already introduced in the
precedent paragraph 14, i.e. those indicating that:
- “locally at the AWS sites, systems with as little as possible
intelligence should be placed”;
- “in future projects, AWS software must reduce to the minimum
required for performing the basic tasks to be locally performed”
only the following, generally used, derived meteo variables (all necessary
to produce SYNOP and/or METAR/SPECI messages) should be
elaborated at AWS level (whenever possible other derived meteo variable
should be elaborated at NMS forecast centre level):
- dew point temperature (if derived from air temperature and relative
humidity or from wet/dry bulb);
Annex E (copy of the Ref. C page I.4-25) provides the related
international standard algorithms;
Annex F gives further details about the dew point temperature (if
derived from air temperature and relative humidity) algorithms for
correct automatic computation;
- virtual temperature;
according to the basic theory (and to Ref. C definition) the virtual
temperature of damp air is the temperature at which dry air of the
same pressure would have the same density as the damp air;
therefore the virtual temperature formula is:
Tv = [1+ (Rv/Ra-1)*q]*T
where:
. Tv is the virtual temperature (°K);
. Rv/Ra is the ratio between the water vapour gas constant and
the dry air gas constant;
. q is the specific humidity;
. T is the damp air temperature (°K);
as known, the virtual temperature will not have to be reported in
meteo messages but will be needed for pressure corrections to
altitudes different from that of the barometer;
Annex F gives further details about the virtual temperature
algorithms;
- QFE; QFF
the QFE and QFF are pressure corrections to a reference level
which differs by less than 500m from that of the barometer of the
station;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
21/72
these derived variables should be computed, in a standard way,
using the virtual temperature and the algorithms of the ref. F
international standard model of atmosphere;
Annex G gives proper details about the QFE and QFF algorithms;
- QNH,
the QNH should be computed using the QFE as defined above and
the algorithms of the ref. F international standard model of
atmosphere;
Annex G gives proper details about the QNH algorithms;
- geopotential height of a pressure level;
in SYNOP messages, the geopotential height of a pressure level has
to be indicated instead of the local pressure correction to sea level
when the station elevation is >=500m,
this derived variable should also be computed, in a standard way,
using the virtual temperature and the algorithms of the ref. F
international standard model of atmosphere;
Annex G gives proper details about the geopotential height
algorithms;
- RVR;
the RVR algorithms should be strictly in line with the Ref. G
recommended standards;
Annex H gives proper details about the RVR algorithms;
- wind components (with respect to runway direction);
there is no need of international standard algorithms for these
derived variables because their computing is straightforward in
principle;
according to the general requirements of SOFTWARE CONFIGURATION
AND FLEXIBILITY, it would be possible that also the following derived
meteo variables, as indicated by the NMS members, should be elaborated
at AWS level:
- wind turbulence information (i.e. various statistical information of
wind components all over 10 minutes; Austria);
- past weather code (Finland);
- sunshine duration (derived from global radiation measurements;
France);
- saturation vapour pressure (France);
- sunshine duration (derived from global radiation measurements;
Netherlands);
- correction of Present Weather using wet bulb temperature (derived
from air temperature and relative humidity; Sweden);
- correction of Precipitation amount using data from Present Weather
sensor (Sweden).
- wind values reductions to heights different from the observations
(Sweden).
Of course, also for these peculiar derived meteo variable it would be
essential that when “detailed technical specifications” would be
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
22/72
presented, the interested NMS members should annex related algorithms
(reported in a logical sequence of formulas to be clearly understood by
the manufacturers analysts) which could represent international standard
requirements for the possible use by other NMS members.
16 SENSORS UNITS DATA THROUGHPUTS.
According to the conclusions of Ref. A, it has been, agreed by the NMS
members that the SENSOR UNIT DTE output serial data transmission
protocol should be: ASYNCHRONOUS TTY, ASCII ALPHABET, CRC
CHECK.
The following logical structure for the SENSOR UNIT message could,
then be defined:
- Start of text (STX): 1 ASCII character;
- Space: 1 ASCII character;
- Sensor unit identification (an identification code for the unit)
8 ASCII characters;
- Space: 1 ASCII character;
- Variable identification (an identification code for the variable, for
example: Ta for air temperature, P for atmospheric pressure; etc.):
8 ASCII characters;
- Space: 1 ASCII character;
- Variable value (the value of the variable in predefined measurement
units): 8 ASCII characters;
- Space: 1 ASCII character;
- Status code: 8 ASCII characters;
- Space: 1 ASCII character;
- CRC: 2 ASCII characters;
- Space: 1 ASCII character;
- End of text (ETX): 1 ASCII character.
So far a minimal information capacity for the SENSOR UNIT message
results in 42 ASCII characters i.e. 42 bytes, but because of the fact that
the internal meteo information (Variable identification + Variable value)
could be repeated several times (4 times for example, is the case of the
ceilometer which reports 3 levels of cloud height and a maximum range of
detection) a maximum information capacity results in 96 ASCII
characters i.e. 96 bytes.
A middle information capacity, significant for communication channels
dimensioning, could be fixed to 80 bytes which, when transmitted via
asynchronous protocol communication channels, result in 800 bits.
For very sophisticated sensor units like the WIND PROFILER a typical
message information capacity, significant for communication channels
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
23/72
dimensioning, could be fixed to 2,000 bytes which, when transmitted via
asynchronous protocol communication channels, result in 20,000 bits.
From the general SENSORS DTE OUTPUT RATES table in annex A, the
following SENSOR UNITS DATA THROUGHPUTS in bps (bits per
second) could, then, be computed to indicate typical values of channel
capacities which the AWS would have to manage internally.
Sensor unit Data throughput
(bps)
Air temperature 40
Ground temperature (=0 level) 40
Soil temperature (<0 level) 40
Relative humidity 20
Dew point temperature 40
Wet bulb temperature 40
Atmospheric pressure 40
Cloud base (Cloud amount) 27
Cloud base (Height) 54
Wind speed 800
Wind direction 800
Wind components 800
Wind components height profile 167
Precipitation amount (Tipping bucket) 14
Precipitation amount (Weighing system) 14
Depth of snow 14
Sunshine duration 40
Global solar radiation 40
Diffuse solar radiation 40
Longwave radiation 40
Total radiation 40
Net total radiation 40
Soil heat flux 14
MOR (General visibility) 80
MOR (Transmittance) 80
Background luminance 80
Present weather 80
Lightning (Counter) 14
State of the ground 14
Soil moisture 14
In particular the above table evidences that:
- a WIND SENSOR UNIT would need a relevant channel capacity i.e.
800 bps
- while any other SENSOR UNIT needs a channel capacity of one
order inferior.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
24/72
17 THE CONCENTRATOR.
Referring to the concentrator, as it has been, defined from a logical point
of view in the preceding paragraphs 5, 6 and shown in the figures 4, 5, the
following input channel capacities values are indicated as examples of
data throughputs which would have to be managed for data concentration:
- for a SYNOPTIC AWS configured just with ESSENTIAL SENSOR
UNITS, i.e.:
. n° 1 Air temperature 40 bps;
. n° 1 Relative humidity 20 bps;
. n° 1 Atmospheric pressure 40 bps;
. n° 1 Wind speed 800 bps;
. n° 1 Wind direction 800 bps;
. n° 1 Precipitation amount 14 bps;
the sum of the input channels capacities would be 1,714 bps;
- for a SYNOPTIC AWS configured with ESSENTIAL and HIGHLY
DESIRABLE SENSOR UNITS, i.e.:
. n° 1 Air temperature 40 bps;
. n° 1 Relative humidity 20 bps;
. n° 1 Atmospheric pressure 40 bps;
. n° 1 Wind speed 800 bps;
. n° 1 Wind direction 800 bps;
. n° 1 Precipitation amount 14 bps;
. n° 1 Cloud base height 54 bps;
. n° 1 Cloud amount 27 bps;
. n° 1 MOR 80 bps;
. n° 1 Present weather 80 bps;
the sum of the input channels capacities would be 1,955 bps;
- for a SYNOPTIC AWS configured with ESSENTIAL, HIGHLY
DESIRABLE, DESIRABLE and OPTIONAL SENSOR UNITS, i.e.:
. n° 1 Air temperature 40 bps;
. n° 1 Relative humidity 20 bps;
. n° 1 Atmospheric pressure 40 bps;
. n° 1 Wind speed 800 bps;
. n° 1 Wind direction 800 bps;
. n° 1 Precipitation amount 14 bps;
. n° 1 Cloud base height 54 bps;
. n° 1 Cloud amount 27 bps;
. n° 1 MOR 80 bps;
. n° 1 Present weather 80 bps;
. n° 1 Global solar radiation 40 bps;
. n° 1 Sunshine duration 40 bps;
. n° 1 Ground temperature 40 bps;
. n° 5 Soil temperature 200 bps;
. n° 1 Depth of snow 14 bps;
. n° 1 Air temperature (prec. gauge) 40 bps;
. n° 1 Wet bulb temperature 40 bps;
. n° 1 Diffuse solar radiation 40 bps;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
25/72
. n° 1 Longwave radiation 40 bps;
. n° 1 Total radiation 40 bps;
. n° 1 Net total radiation 40 bps;
. n° 1 Soil heat flux 14 bps;
. n° 1 Background luminance 80 bps;
. n° 1 Lightning (counter) 14 bps;
. n° 1 State of the ground 14 bps;
. n° 1 Soil moisture 14 bps;
the sum of the input channels capacities would be 2,665 bps;
in particular it is evidenced that if the WIND channels are taken
away from the total, the remaining would be 1,065 bps i.e.
equivalent to the preceding case of the SYNOPTIC AWS configured
just with ESSENTIAL SENSOR UNITS;
- for an AIRPORT AWS CLUSTER of ESSENTIAL SENSOR UNITS
configured with:
. n° 1 Air temperature 40 bps;
. n° 1 Relative humidity 20 bps;
. n° 1 Atmospheric pressure 40 bps;
. n° 1 Wind speed 800 bps;
. n° 1 Wind direction 800 bps;
. n° 1 Cloud base height 54 bps;
. n° 3 MOR (Transmissometer) 240 bps;
. n° 1 Background luminance 80 bps;
the sum of the input channels capacities shall be 2,074 bps.
In relation to the above examples of input channels capacities the
following specifications are indicated:
- the functions of the CONCENTRATOR should be very simple
consisting in:
. buffering the input channels which could work at different
speeds (for example 1200 bps, 2400 bps, etc.);
. queuing the various input messages, properly one after the
other, insuring error free operations;
- it is evidenced that the CONCENTRATOR:
. should not need to respect a strict synchronisation between the
input message with the related output one (for example, it
would not be needed that the every second WIND DIRECTION
inputted message would be outputted every second)
. but, thanks to the buffer resources, should insure that all the
data incoming should be leaving without saturation points and
loss of information;
- there should be only one level of CONCENTRATION; i.e. there
should be no need of CONCENTRATORS connected in cascade.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
26/72
According these conclusions and to the logic structure defined for the
SENSOR UNIT message, the logic message structure, at the
CONCENTRATOR OUTPUT PORT, would be:
- Start of header (SOH): 1 ASCII character;
- DTE identification (the identification number of the specific
CONCENTRATOR input DTE receiver of the following message
text): 2 ASCII characters;
- Start of text (STX): 1 ASCII character;
- Space: 1 ASCII character;
- Sensor unit identification 8 ASCII characters;
- Space: 1 ASCII character;
- Variable identification: 8 ASCII characters;
- Space: 1 ASCII character;
- Variable value: 8 ASCII characters;
- Space: 1 ASCII character;
- Status code: 8 ASCII characters;
- Space: 1 ASCII character;
- CRC: 2 ASCII characters;
- Space: 1 ASCII character;
- End of text (ETX): 1 ASCII character.
- End of transmission (EOT): 1 ASCII character.
18 DATA ACQUISITION TASKS.
As soon as the DATA ACQUISITION TASKS would be activated, they
would be able to receive, continuously, the SENSOR
UNITS/CONCENTRATOR messages containing the instantaneous meteo
values and produce the following table of ACTUAL DATA on the central
FILE SERVER.
- ACTUAL DATA:
. Date and time group;
. AWS DTE identification;
. Concentrator DTE identification;
. Actual variable identification;
. Actual variable value;
. Status code;
the Date and time group would be included in the logical primary key
of this table because these ACTUAL DATA:
. would not, consist in the ensemble of very last instantaneous
value for each variable;
. but would contain the entire number of the last instantaneous
values for each variable, necessary for the AWS elaboration of
averaging as indicated in the precedent paragraph 14;
Table 1, of Annex I, reports examples of codes and value formats for
the fields of Actual variable identification and Actual variable
value.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
27/72
The logical existence of the mentioned ACTUAL DATA TABLE would
insure, without the need of any other external information, that the AWS is
able of perceiving and controlling the entire configuration of sensor units.
To complete the information about the configuration of sensor units, the
authorised End User would be able to record the following tables of
SENSOR UNITS CONFIGURATION DATA and LOCATION POINTS
CONFIGURATION DATA on the central FILE SERVER.
- SENSOR UNITS CONFIGURATION DATA:
. Date and time group;
. User identification;
. AWS DTE identification;
. Concentrator DTE identification;
. Actual variable identification;
. Location point identification;
especially useful for ATC (Air Traffic Control) aviation purposes
(TDZ, LANDING, RUNWAY, etc.);
. Validity checks parameters;
. Averaging time parameters;
. Frequency of presentation updating;
especially useful for ATC aviation purposes;
. enabled/disabled;
the Date and time group would be included in the table primary key
because the sensor units configuration changes have to be
registered carefully at the time they occur;
of course the operational configuration would be the one related to
the most recent times.
- LOCATION POINTS CONFIGURATION DATA:
. User identification;
. Location point identification;
. Configuration variable identification;
. Configuration variable value;
Table 2, of Annex I, reports examples of codes for the field of
Location point identification;
Table 3, of Annex I, reports examples of codes and value formats for
the fields of Configuration variable identification and
Configuration variable value.
Based on the above SENSOR UNITS CONFIGURATION DATA, the
DATA ACQUISITION TASKS;
- would perform:
. the averaging of the above ACTUAL DATA according to the
related Averaging time/validity checks parameters
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
28/72
. with a frequency as indicated by the related Frequency of
presentation updating;
- would produce, with the same Frequency of presentation
updating, a record in the following table of REPRESENTATIVE
DATA on the central FILE SERVER.
- REPRESENTATIVE DATA:
. Date and time group;
. AWS DTE identification;
. Concentrator DTE identification;
. Representative variable identification;
. Representative variable value;
. Count;
the number of valid actual data used to elaborate the
Representative variable value;
. Status code (First)
the Status code related to the First actual data to be
considered in the elaboration of the Representative variable
value;
. Status code (Last);
the Status code related to the Last actual data to be considered
in the elaboration of the Representative variable value;
according to the general requirements, as introduced at the
precedent point 2.g, the capacity of this archive should be of the
order of five days data;
of course the operational representative data would be the ones
related to the most recent times;
Table 4, of Annex I, reports examples of codes and value formats for
the said fields of Representative variable identification and
Representative variable value.
The logical existence of the mentioned ACTUAL DATA, SENSOR UNITS
CONFIGURATION DATA, REPRESENTATIVE DATA TABLES would
insure that the AWS is able to control the complete sensor units
configuration and manage all the information about the directly measured
meteo variables.
Because the AWS has to elaborate derived meteo variables from the
directly measured meteo ones, the authorised End User would be able to
record the following table of DERIVED VARIABLES CONFIGURATION
DATA on the central FILE SERVER.
- DERIVED VARIABLES CONFIGURATION DATA:
. Date and time group;
. User identification;
. Location point identification;
. Derived variable identification;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
29/72
. Algorithms;
the Date and time group would be included in the table primary key
because the derived variables configuration changes have to be
registered carefully also if varying slowly with the time;
of course the operational configuration would be the one related to
the most recent times;
Table 5, of Annex I, reports examples of codes for the field of
Derived variable identification.
In function of the above DERIVED VARIABLES CONFIGURATION DATA,
the DATA ACQUISITION TASKS;
- would apply the indicated algorithms to the related
REPRESENTATIVE DATA and/or ACTUAL DATA;
- would produce the following table of REPRESENTATIVE DERIVED
DATA on the central FILE SERVER.
- REPRESENTATIVE DERIVED DATA:
. Date and time group;
. Location point identification;
. Representative derived variable identification;
. Representative derived variable value;
. Count;
the number of valid actual data used to elaborate the
Representative derived variable value;
according to the general requirements, as introduced at the
precedent point 2.g, the capacity of this archive should be of the
order of five days data;
of course the operational representative data would be the ones
related to the most recent times;
Table 6, of Annex I, reports examples of codes and value formats for
the fields of Representative derived variable identification and
Representative derived variable value.
The logical existence of the mentioned ACTUAL DATA, SENSOR UNITS
CONFIGURATION DATA, REPRESENTATIVE DATA, DERIVED
VARIABLES CONFIGURATION DATA, REPRESENTATIVE DERIVED
DATA TABLES would insure that the AWS is able to control the complete
sensor units configuration, manage, automatically, the information about
the directly measured meteo variables and the related derived ones.
Because the AWS has to manage visual data, the authorised End User
would be able to record the following messages of visual data on the
central FILE SERVER.
- VISUAL DATA:
. Date and time group;
. User identification;
. Location point identification;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
30/72
. Visual variable identification;
. Visual variable value;
the variable value or the METAR or SYNOP code which would
be checked by the DATA ACQUISITION TASKS against the
standard METAR/SYNOP tables;
according to the general requirements, as introduced at the
precedent point 2.g, the capacity of this archive should be of the
order of one month data;
of course the operational representative data would be the ones
related to the most recent times;
Table 7, of Annex I, reports examples of codes and value formats for
the said fields of Visual variable identification and Visual variable
value.
Annex J reports further details about the meteo variable marked
discontinuity concept which has been introduced in the precedent text and
included in the codes of Annex I.
The logical existence of the mentioned ACTUAL DATA, SENSOR UNITS
CONFIGURATION DATA, REPRESENTATIVE DATA, DERIVED
VARIABLES CONFIGURATION DATA, REPRESENTATIVE DERIVED
DATA, VISUAL DATA TABLES would insure that the AWS is able to
manage, automatically, the full meteo information so that it could compile
and transmit messages reporting part or all of its capacity of information.
The following logic structure of a flexible multipurpose message, able to
report the full AWS capacity of information, is defined and proposed as a
possible standard.
- START OF AWS MESSAGE:
. Date and time group;
. AWS identification;
(-) LOOP OF REPRESENTATIVE DATA:
(.) AWS DTE identification;
(.) Concentrator DTE identification;
(.) Representative variable identification;
(.) Representative variable value;
(.) Count;
(.) SENSOR UNIT Status code (First)
(.) SENSOR UNIT Status code (Last);
(-) LOOP OF REPRESENTATIVE DERIVED DATA:
(.) Location point identification;
(.) Representative derived variable identification;
(.) Representative derived variable value;
(.) Count;
(-) LOOP OF VISUAL DATA:
(.) Location point identification;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
31/72
(.) Visual variable identification;
(.) Visual variable value;
. AWS Status code;
- END OF AWS MESSAGE.
The AWS should be able, as well, of compiling and transmitting the meteo
messages in the standard formats: SYNOP and METAR/SPECI.
The scheduling information, the alarm criteria and the coding definitions
for these common use messages are fully covered in the Ref. D and E
documents.
According to the general requirements, as introduced at the precedent
point 2.g., the minimum period of time to keep these messages within the
AWS mass memory should one month.
According to the indication of Ref. A, also the AWS messages destined
(externally to the AWS) to the remote NMS centres, like the ones
(internally to the AWS) outputted by the sensors units, should be
transmitted via an asynchronous protocol, in ASCII alphabet and with a
CRC check.
However, for these external messages, in addition, a binary standard
protocol could be designed and generally used.
19 TRUSTED BASE TASKS.
As soon as an End User would begin a transaction with the AWS, the
TRUSTED BASE TASKS would be activated and would perform the
IDENTIFICATION-AUTHENTICATION of the End User, i.e. the TRUSTED
BASE TASKS:
- would ask for the insertion of the User identification and Password;
- would check if the inserted relation: User identification and
Password exists in the following AUTHENTICATION DATA table
resident on the central FILE SERVER;
- would continue the transaction just if the said relation exists in the
AUTHENTICATION DATA table.
- AUTHENTICATION DATA:
. User identification;
. Password.
After the IDENTIFICATION-AUTHENTICATION phase, the TRUSTED
BASE TASKS would present to the End User its menu of possibilities on a
“need to know” basis according to the information contained in the
following NEED TO KNOW DATA table resident on the central FILE
SERVER.
- NEED TO KNOW DATA:
. User identification;
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
32/72
. Table identification:
i.e. any DATA TABLE (SENSOR UNITS CONFIGURATION
DATA, REPRESENTATIVE DATA, etc.) within the FILE
SERVER;
. Read/Write:
if the End User is enabled just in information retrieval or also in
inserting data.
The TRUSTED BASE TASKS should be able to log the various steps of a
transaction producing the following TRANSACTION LOG DATA table on
the central FILE SERVER.
- TRANSACTION LOG DATA:
. Date and time group;
. User identification;
. Table identification;
. Read/Write.
20 ENVIRONMENTAL CONDITIONS.
Ref. A indicates that, about, the 30% of the next EUMETNET AWSs will
be, certainly, working “automatic only” so that their entire configuration,
will have to be installed externally on the field.
The remaining 70% of AWSs will be working in manned or partially
manned premises so that, in this case, the AWS CPU could be installed,
internally, in equipment rooms.
The following environmental conditions refer to the equipment operating
externally on the field.
Temperature ranges.
The Ref. A indications about the temperature ranges are reported in the
following table:
T_min(°C)\T_max(°C) 20 25 30 35 40 45 50 60 70
-10 0,70% 2,25%
-20 0,37% 0,45%
-25 0,84%
-30 7,12% 32,25 0,23%
-35 0,20% 0,28% 0,45% 1,97% %
-40 0,84% 1,41% 1,13% 23,75 0,87% 1,41%
-50 0,28% 0,11% 1,44% 8,64% % 0,48%
-55 3,94%
-60 8,58%
According to these indications the following temperature ranges are
proposed:
- –40°C…50°C which will include, about, the 75% of cases
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
33/72
- –60°C…60°C which will include a further 24.8% of the remaining i.e.
the 99.8% of cases;
- –30°C…70°C which will include the last 0.2% of cases.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
34/72
Atmospheric pressure range.
According to Ref. A indications the following atmospheric pressure range
is proposed:
- 500hPa…1100hPa.
Relative humidity range.
According to Ref. A indications the following relative humidity range is
proposed:
- 0%…100%.
Wind speed max.
According to Ref. A indications the following wind speed max are
proposed:
- 60m/s which will include the 90% of cases;
- 80m/s which will include the remaining 10% of cases.
21 POWER SUPPLY.
Ref. A indicates that in, about, the 70% of cases there will be no problems
of external power supply lines.
Therefore:
- the AWS should be mainly designed to be powered by a typical
220V/50Hz electrical source;
- it should be taken in account that in, about, 30% of cases the AWS
should be powered by dedicated electrical sources based on SOLAR
PANEL or WIND energy.
It is evidenced that the AWS should be equipped with a UPS
(Uninterrupted Power Supply) feature being able of powering, for one day
minimum, the AWS CPU and the essential sensors configuration set (see
point 3.a. and point 3.b.)
22 REMOTE COMMUNICATIONS.
Ref. A indicates that in, about, the 90% of cases there will be no problems
of remote communications supports, for the majority of cases supplied by
PSTN and/or Cellular networks.
Therefore:
- the AWS should be mainly designed to transmit/receive through the
PSTN and/or Cellular networks;
- it should be taken in account that in, about, 10% of cases the AWS
should interface satellite switched network DCEs.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
35/72
Ref. A indicates also a few cases of availability of X25 or leased lines
which should be considered just as special advantageous cases of PSTN
communication support.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
36/72
FIGURE 1
GENERAL BLOCK DIAGRAM OF
THE PROPOSED FUNDAMENTAL AWS SYSTEM ARCHITECTURE
AWS
SENSOR UNIT
DCE DCE DTE SENSOR
REMOTE DTE
DESTINATION COMPUTER DCE DTE SENSOR UNIT
OPERATIONAL CENTRE DTE DCE DCE DTE SENSOR
CPU
REMOTE DTE
DESTINATION COMPUTER DCE DTE DTE
MAINTENANCE CENTRE DTE DTE DTE OTHER SENSOR UNITS
SENSOR UNIT
DCE DCE DTE SENSOR
TERMINAL
TERMINAL
TO INPUT
FOR OPERATIONAL
NON AUTOMATIC
PRESENTATIONS
OBSERVED DATA
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
37/72
FIGURE 2
GENERAL BLOCK DIAGRAM OF
THE EXISTING "1° TYPE" AWS SYSTEM ARCHITECTURE
AWS
SENSOR UNIT
MODEM MODEM DTE SENSOR
RS232
RS232
DTE
REMOTE ANALOGUE
INTERFACES
SENSOR
DESTINATION COMPUTER MODEM DTE CPU
A/D
RS232
OPERATIONAL CENTRE ANALOGUE
ANALOGUE
OTHER ANALOGUE SENSORS
DTE
RS232
SENSOR UNIT
RS232
MODEM MODEM DTE SENSOR
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
38/72
FIGURE 3
GENERAL BLOCK DIAGRAM OF
THE EXISTING "2° TYPE" AWS SYSTEM ARCHITECTURE
AWS
RS485 or CAN SENSOR UNIT
DCE DTE SENSOR
BUS
PSTN or GSM
REMOTE MODEM
SENSOR UNIT
DESTINATION COMPUTER RS485 or CAN
OPERATIONAL CENTRE
DCE
RS232
DTE CPU DTE
RS232
DCE
BUS
DCE DTE SENSOR
OTHER SENSOR UNITS
RS485 or CAN
BUS SENSOR UNIT
DCE DTE SENSOR
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
39/72
FIGURE 4
BLOCK DIAGRAM OF THE AWS SYSTEM ARCHITECTURE
AWS
CPU
SENSOR UNIT
STANDARD DCE DCE DTE SENSOR
COMPUTER
DTE
DATA ACQUISITION
REMOTE
CONCENTRATOR
TRUSTED BASE
DESTINATION COMPUTER DCE DTE
SENSOR UNIT
OPERATIONAL CENTRE DTE DCE DCE DTE SENSOR
FILE DTE DTE
REMOTE SERVER
DTE DTE DTE
DESTINATION COMPUTER DCE DTE
DTE
MAINTENANCE CENTRE DTE
DTE
DTE OTHER SENSOR UNITS
SENSOR UNIT
DCE DCE DTE SENSOR
LAN
TERMINAL TERMINAL
TO INPUT FOR OPERATIONAL
NON AUTOMATIC PRESENTATIONS
OBSERVED DATA
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
40/72
FIGURE 5
BLOCK DIAGRAM OF THE AWS SYSTEM ARCHITECTURE.
THE USE OF THE BUS AS CONCENTRATOR
AWS
CPU BUS
SENSOR UNIT
STANDARD DCE DCE DTE SENSOR
COMPUTER
DTE
DATA ACQUISITION
REMOTE
CONCENTRATOR
TRUSTED BASE
DESTINATION COMPUTER DCE DTE
SENSOR UNIT
OPERATIONAL CENTRE DTE DCE DCE DTE SENSOR
FILE DTE DTE
REMOTE SERVER
DTE DTE DTE
DESTINATION COMPUTER DCE DTE
DTE
MAINTENANCE CENTRE DTE
DTE
DTE OTHER SENSOR UNITS
SENSOR UNIT
DCE DCE DTE SENSOR
LAN
TERMINAL TERMINAL
TO INPUT FOR OPERATIONAL
NON AUTOMATIC PRESENTATIONS
OBSERVED DATA
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
41/72
FIGURE 6
BLOCK DIAGRAM OF THE AWS SYSTEM ARCHITECTURE
EXPANDIBILITY AND REDUNDANCY
CPU AWS
STANDARD
REMOTE COMPUTER
or
DESTINATION COMPUTER DCE DTE
CLUSTERED
TRUSTED BASE
OPERATIONAL CENTRE COMPUTERS
FOR REDUNDANCY
REMOTE DCE DTE
DESTINATION COMPUTER DTE
FILE
SERVER
MAINTENANCE CENTRE
SENSOR UNIT
DCE DCE DTE SENSOR
STANDARD
COMPUTER DTE
DATA ACQUISITION
CONCENTRATOR
SENSOR UNIT
DTE DCE DCE DTE SENSOR
DTE
DTE DCE DCE
DTE DTE
DTE DCE DCE DTE
DTE
DTE OTHER SENSOR UNITS
DTE
SENSOR UNIT
DCE DCE DTE SENSOR
SENSOR UNIT
STANDARD DCE DCE DTE SENSOR
COMPUTER
DATA ACQUISITION
DTE
CONCENTRATOR
SENSOR UNIT
DTE DCE DCE DTE SENSOR
DTE DCE DCE DTE
DTE DCE DCE DTE DTE
DTE
DTE
DTE OTHER SENSOR UNITS
DTE
SENSOR UNIT
DCE DCE DTE SENSOR
LAN
TERMINAL TERMINAL TERMINAL TERMINAL
TO INPUT TO INPUT FOR OPERATIONAL FOR OPERATIONAL
NON AUTOMATIC NON AUTOMATIC PRESENTATIONS PRESENTATIONS
OBSERVED DATA OBSERVED DATA
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
42/72
ANNEXE A
SENSORS DTE OUTPUT RATES
Meteo_variable Variable Sensor DTE_output_rate Time_constant Time_of_average Time_of_measurement
Air temperature Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Ground temperature (=0 level) Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Soil temperature (<0 level) Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Relative humidity Dynamic Linear Transducer & A/D converter 1 output every Time constant 40s
Dew point temperature Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Wet bulb temperature Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Atmospheric pressure Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Cloud base (Cloud amount) Dynamic Slow measurements computer based device 1 output every Time of measurement 30s
Cloud base (Height) Dynamic Slow measurements computer based device 1 output every Time of measurement 15s-30s
Wind speed Dynamic Linear Transducer & A/D converter 1 output every Time constant 1s
Wind direction Dynamic Linear Transducer & A/D converter 1 output every Time constant 1s
Wind components Dynamic Fast measuring computer based device 1 output every Time of average 1s
Wind components height profile Dynamic Slow measurements computer based device 1 output every Time of measurement 120s
Precipitation amount (Tipping bucket) Always growing Pulse generator & Counter 1 output every 60s
Precipitation amount (Weighing system) Always growing Linear Transducer & A/D converter 1 output every 60s
Depth of snow Static Slow measurements computer based device 1 output every 60s
Sunshine duration Two states dynamic Linear Transducer & Treshold trigger 1 output every Time constant 20s
Global solar radiation Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Diffuse solar radiation Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Longwave radiation Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Total radiation Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Net total radiation Dynamic Linear Transducer & A/D converter 1 output every Time constant 20s
Soil heat flux Dynamic Linear Transducer & A/D converter 1 output every Time constant 60s
MOR (General visibility) Dynamic Slow measurements computer based device 1 output every Time of measurement 10s-60s
MOR (Transmittance) Dynamic Slow measurements computer based device 1 output every Time of measurement 10s-15s
Background luminance Dynamic Linear Transducer & A/D converter 1 output every Time constant 10-15s
Present weather Coded dynamic Slow measurements computer based device 1 output every Time of measurement 10s-60s
Lightning (Counter) Always growing Pulse generator & Counter 1 output every 60s
State of the ground Static Linear Transducer & A/D converter 1 output every 60s
Soil moisture Static Linear Transducer & A/D converter 1 output every 60s
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
43/72
ANNEXE B
SENSORS STATUS CODES
Dynamic Linear Transducer & A/D converter Power supply (OK or not OK) A/D converter (OK or not OK)
Dynamic Fast measuring computer based device Self diagnostic results Heater (ON or OFF)
Dynamic Slow measurements computer based device Self diagnostic results Heater (ON or OFF)
Two states dynamic Linear Transducer & Treshold trigger Power supply (OK or not OK)
Coded dynamic Slow measurements computer based device Self diagnostic results Heater (ON or OFF)
Always growing Linear Transducer & A/D converter Power supply (OK or not OK) A/D converter (OK or not OK) Heater (ON or OFF)
Always growing Pulse generator & Counter Power supply (OK or not OK) Heater (ON or OFF)
Static Linear Transducer & A/D converter Power supply (OK or not OK) A/D converter (OK or not OK)
Static Slow measurements computer based device Self diagnostic results Heater (ON or OFF)
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
44/72
ANNEX C
SENSORS OUTPUT AVERAGING TIME
(COPY OF PAGES FROM THE WMO N° 8 MANUAL)
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
45/72
ANNEX C
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
46/72
ANNEX C
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
47/72
ANNEX D
ELABORATION OF WIND INSTANTANEOUS DATA
(COPY OF A PAGE FROM THE WMO N° 8 MANUAL)
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
48/72
ANNEX E
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
49/72
ANNEX F
SPECIFICATIONS
ALGORITHMS OF DEW POINT AND VIRTUAL TEMPERATURE
1 SUBJECT.
The subject of these specifications is the definitions of algorithms for
computing:
- the dew point temperature as a function of the observed relative
humidity and air temperature;
- the virtual temperature as a function of the observed relative
humidity, air temperature and atmospheric pressure.
2 DEW POINT TEMPERATURE.
Ref. C (i.e. the WMO No. 8, annex 4.b) indicates the
following system of formulas related to the dew point
temperature:
td= 243.12*ln[e’/(6.112*f(p))]
17.62-ln[e’/(6.112*f(p))]
(Dew point temperature
with respect to water (-45 to 60°C))
e’=U*e’w(p,t)/100
(Vapour pressure)
e’w(p,t)=f(p)*ew(t)
(Saturation vapour pressure of moist air)
ew(t)=6.112*exp[17.62*t/(243.12+t)]
(Saturation vapour pressure in the pure phase
with respect to water (-45 to 60°C))
which, resolved, is reduced to the following two formulas:
ew(t)=6.112*exp[17.62*t/(243.12+t)]
td= 243.12*ln[(U/100)*ew(t)/6.112]
17.62-ln[(U/100)*ew(t)/6.112]
where:
- t is the observed air temperature measured in °C;
- U is the relative humidity measured in %;
- td is obtained in °C.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
50/72
ANNEX F
3 VIRTUAL TEMPERATURE.
According to the basic theory (and to Ref. C definition) the
virtual temperature of damp air is the temperature at which dry air of
the same pressure would have the same density as the damp air;
therefore the virtual temperature formula would be:
Tv=[1+(Rv/Ra-1)*q]*T
where:
- Rv/Ra is the ratio between the water vapour gas constant and the dry
air gas constant;
- q is the specific humidity;
- T is the observed (damp air) temperature (K);
Further on, Ref. C indicates the following system of
equations related to the specific humidity:
q=r/(r+1)
(Specific humidity as function of the mixing ratio)
e’=p*r/(r+Mv/Ma)
(Vapour pressure as function of the mixing ratio)
e’=U*e’w(p,t)/100
(Vapour pressure)
e’w(p,t)=f(p)*ew(t)
(Saturation vapour pressure)
which, when resolved, drives to the following formulas to be computed in
sequence (knowing the initial values: relative humidity; air temperature,
atmospheric pressure):
ew(t)=6.112*exp[17.62*t/(243.12+t)]
f(p)=1.0016+3.15*10-6*p-0.0074*p-1
e’w(p,t)=f(p)*ew(t)
e’=U*e’w(p,t)/100
r=(e’/p)*(Mv/Ma)/(1-e’/p)
q=r/(r+1)
Tv=[1+(Rv/Ra-1)*q]*T
where Mv/Ma=Ra/Rv=0.62198 is the ratio between the water vapour mole
mass and the air mole mass.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
51/72
ANNEX G
SPECIFICATIONS
ALGORITHMS OF ATMOSPHERIC PRESSURE REDUCTIONS
1 SUBJECT.
The subject of these specifications is the definitions of algorithms for
computing:
- atmospheric pressure reductions to levels different from the one of
observation;
- geopotential heights of atmospheric pressure levels different from
the one of observation.
The following alghorithms are aimed to automate the elaboration of the
derived meteo variables refferring to atmospheric pressure observations
within the messages SYNOP, METAR, METREPORT and generally
known as QFE, QFF, QNH, geopotential heights.
2 INTRODUCTION.
Ref. F, i.e. the ICAO DOC. 7488/3; Third edition 1993:
Manual of the ICAO standard atmosphere:
- exposes the following system of differential equations:
-dp=s*g*dh
(Hydrostatic equation)
p=s*R*T
(Perfect gas Law)
H=r*h/(r+h)
(Geopotential height H versus geometrical height h)
g=g0.(r/(r+h))2
(Acceleration due to gravity)
T=Tb+k*(H-Hb)
(Absolute temperature profile)
- integrates the above system presenting the following equation
(solution of the problem) as a mathematical model of a standard
atmosphere recommended for various uses, among which the
“processing of data from geophysical and meteorological
observations”:
p=pb*[1+k*(H-Hb)/Tb] -g0/(k*R)
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
52/72
ANNEX G
where, according to Ref. F:
- k=-6.5K/km for the layer of subject interest, i.e. from 0 to
11km;
- the subscript “b” refers to values of pertinent characteristics to
the lower limit of the layer concerned, i.e. Hb=0,
Tb=T0=288.15K, pb=P0=1013.25hPa for the layer of subject
interest;
- g0=9.80665m/s2;
- R=287.05287m2/(K*s2).
3 DRY AND DAMP AIR.
The above formula of standard atmosphere refers to dry air
(free from moisture) but it could be, also, applied for
modelling damp air when, in lieu of the observed
temperature, the related virtual temperature Tv (K) is
used.
The algorithms for computing the virtual temperature as a function of the
observed relative humidity, air temperature and atmospheric pressure are
reported in annex F.
4 QFE, QFF CALCULATIONS.
Considering the arguments in the precedent paragraphs, the following
QFE calculations would be concluded.
QFE=pz*[1+k*(Ha-Hz)/Tv]-g0/(k*R)
where:
- Ha is the datum elevation to which the barometric pressure has to be
reduced and reported as QFE;
- Hz is the elevation of the zero point of the barometer;
- pz is the observed barometric pressure;
- Tv is the virtual temperature at the elevation Hz.
the QFF would be a special case of the above calculation where Ha=0,
i.e.:
QFF=pz*[1-k*Hz/Tv]-g0/(k*R)
5 QNH CALCULATIONS.
Considering the arguments in the precedent paragraphs, the following
system of equations would be proposed for the QNH calculations.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
53/72
ANNEX G
QFE=P0*[1+k*H/T0]-g0/(k*R)
QNH=P0*[1+k*(H-Ha)/T0]-g0/(k*R)
which, when resolved, gives the following solution:
QNH=P0*[(QFE/P0)-k*R/g0-k*Ha/T0]-g0/(k*R)
where all the terms are defined in the precedent paragraphs.
6 GEOPOTENTIAL HEIGHT CALCULATIONS.
Considering the arguments in the precedent paragraphs, from the above
general formula for the damp atmosphere, i.e.:
p=pz*[1+k*(H-Hz)/Tv]-g0/(k*R)
the following GEOPOTENTIAL HEIGHT calculation would be concluded.
H=((p/pz)-k*R/g0-1)*Tv/k+Hz
where p is the standard level pressure of which the related geopotential
height H has to be reported.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
54/72
ANNEX H
SPECIFICATIONS
ALGORITHMS FOR THE DETERMINATION OF THE RVR DATUM
INDEX
1 SUBJECT.
2 DEFINITION OF RVR.
3 RUNWAY LIGHTS TO BE USED FOR THE DETERMINATION OF THE
RVR.
4 RVR BASED ON MARKERS OR OTHER BLACK OBJECTS.
5 RVR BASED ON RUNWAY LIGHTS.
APPENDICES:
1 RUNWAY LIGHTS AS SEEN BY A PILOT AT AN HEIGHT OF 5M AND
10M.
2 RELATIONSHIP BETWEEN ILLUMINATION THRESHOLD AND
BACKGROUND LUMINANCE.
3 I(R) FUNCTION, LIGHT INTENSITY VERSUS RVR.
4 ISOCANDELA DIAGRAM OF THE EDGE LINE LIGHT.
5 ISOCANDELA DIAGRAM OF THE CENTRE LINE LIGHT.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
55/72
ANNEX H
1 SUBJECT.
The subject of these specifications is the definitions of algorithms for the
determination of the RVR (Runway Visual Range) datum according to the
recommendations reported in the documentation of Ref. D and G.
2 DEFINITION OF RVR.
Ref. D (i.e. the ICAO annex 3) gives the following definition of RVR:
“a runway visual range observation should be the best possible
assessment of the range over which the pilot of an aircraft on the centre
line of a runway can see the runway surface marking or the lights
delineating the runway or identifying its centre line. For this assessment a
height of approximately 5m should be regarded as corresponding to the
average eye level of a pilot in an aircraft”.
3 RUNWAY LIGHTS TO BE USED FOR THE DETERMINATION OF THE
RVR.
Ref. G (ICAO Doc 9328) evidences that the runway lights, to be used for
the determination of the RVR, are the edge and centre lines ones.
In particular the figure 5-1 of Ref. G, reported in appendix 1, presents the
perspectives of the above lights as seen by a pilot at an height of 5m and
10m.
4 RVR BASED ON MARKERS OR OTHER BLACK OBJECTS.
Ref. G recommends that the RVR value, based on markers or other black
objects, be computed according to the Koschmieder law:
Tx=0,05
where:
- x is the value of the MOR (Meteorological Optical Range), i.e. the
solution of the problem;
- T is the air transmissivity, computed according to the following
formula:
Tb=tb
where:
. tb is the transmittance, read on the transmissometer;
. b is the base length of the transmissometer.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
56/72
ANNEX H
In practice, the above system is resolved with the following formula:
x=b*ln(0.05)/ln(tb)
In particular Ref. G recommends that, with day light, if the above MOR
would result greater than the RVR value based on runway lights then it
would have to be considered as the effective RVR value.
5 RVR BASED ON RUNWAY LIGHTS.
Ref. G recommends that the RVR value, based on the runway lights, be
computed according to the Allard law:
ET(bgl)=I(R)*TR/R2
where:
- R is the value of the RVR, i.e. the solution of the problem;
- T is the air transmissivity, defined in the precedent paragraph;
- ET is the visual threshold of illumination which is function of the
background luminance (bgl) according to the relationship shown in
appendix 2;
in particular it is evidenced that, according to Ref. G
recommendations, in obtaining ET from bgl, the continuous function
of appendix 2 would be taken in account instead of the stepped one;
- I(R) is a curve equivalent to the one shown in the example of Ref. G,
reported in appendix 3, in which the directionality of the runway
lights irradiation is taken in account;
in particular this curve is obtained considering:
. an edge light irradiation diagram like the typical one shown in
appendix 4;
. a centre light irradiation diagram like the typical one shown in
appendix 5;
and applying the following recommendations of Ref. G:
. the nominal intensity values, read on the edge line light
irradiation diagram (as given by the runway lights system
manufacturer), would be decreased of 20% to consider the
inevitable lamp degradation with the time;
. the nominal intensity values, read on the centre line light
irradiation diagram (as given by the runway lights system
manufacturer), would be decreased of 50% to consider the
inevitable lamp degradation with the time;
. when the visibility is low (RVR<350m), the RVR would be
computed considering the centre line light;
. when the visibility is high (RVR>600m), the RVR would be
computed considering the edge line light;
. when the RVR is in the transition zone (350m<=RVR<=600m),
the RVR would be computed making a mean value between
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
57/72
ANNEX H
the one assessed considering the edge line light and the other
one assessed considering the centre line light;
. the RVR value would be calculated for a 100% intensity of the
runway lights (edge and centre) which would be considered as
“the appropriate intensity of runway lights related to prevailing
conditions of operational use”;
. the RVR value would be calculated also for the following
remaining steps of runway light intensity (edge and centre):
30%, 10%, 3%, 1%, 0% and the RVR value related to the
runway lights intensity actually in use would be evidenced
thanks to an automatic data transmission link with the runway
light system (air traffic control panel).
In practice there are no symbolic solutions to be suggested for the above
Allard equation because its elements ET(bgl) and I(R) are given in
empirical form and not in a symbolic one.
Therefore the said equation would be resolved via numerical methods.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
58/72
ANNEX H
APPENDIX 1
COPY OF A PAGE FROM THE ICAO DOC 9328-AN/908
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
59/72
ANNEX H
APPENDIX 2
COPY OF A PAGE FROM THE ICAO DOC 9328-AN/908
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
60/72
ANNEX H
APPENDIX 3
COPY OF A PAGE FROM THE ICAO DOC 9328-AN/908
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
61/72
ANNEX H
APPENDIX 4
COPY OF A PAGE FROM THE ICAO DOC 9328-AN/908
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
62/72
ANNEX H
APPENDIX 5
COPY OF A PAGE FROM THE ICAO DOC 9328-AN/908
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
63/72
ANNEX I
TABLES OF CODES AND FORMATS
TABLE 1
ACTUAL VARIABLE IDENTIFICATION CODE AND VALUE FORMAT
Actual_variable Variable Unit Format Description
WD Wind_direction ° XXX Surface wind direction value
WS Wind_speed m/s XX.X Surface wind speed value
WU Wind_components m/s XX.X Surface wind component U value
WV Wind_components m/s XX.X Surface wind component V value
VIS MOR_visibility m XXXXX Value of the general visibility
TRS MOR_Transmittance % XXX.X Transmittance value read on the transmissometer
BGL Background_luminance Cd/m^2 XXXXXX Background luminance value
PW Present_weather Code XXXXXXXX Present weather code
CL Cloud_base_height m XXXXX Value of the height of the first detected level of clouds
CM Cloud_base_height m XXXXX Value of the height of the second detected level of clouds
CH Cloud_base_height m XXXXX Value of the height of the third detected level of clouds
CA Cloud_base_amount octa X Value of the amount of clouds
T Air_temperature °C XXX.X Air temperature value
RH Relative_humidity % XXX Relative humidity value
DP Dew_point_temperature °C XXX.X Value of the dew point temperature
P Atmospheric_pressure hPa XXXX.X Atmospheric pressure value
PREC Precipitation_amount_tipping_bucket Count XXXX Aumount value of precipitation read on the counter
PREW Precipitation_amount_weighing_system g XXXX Aumount value of precipitation read on the counter
DSN Depth_of_snow cm XXXX Value of depth of snow
WV(Z) Wind_components_height_profile m/s XX.X Wind component V value at height Z measured in m
WU(Z) Wind_components_height_profile m/s XX.X Wind component U value at height Z measured in m
TG Ground_temperature °C XXX.X Ground temperature value
TS(Z) Soil_temperature °C XXX.X Value of the soil temperature at depth Z measured in cm
SUNDUR Sunshine_duration h XX.X State of presence/absence of sunshine duration
SOLRA Global_solar_radiation W/m^2 XXXXX Value of the global solar radiation
DIFRA Diffuse_solar_radiation W/m^2 XXXXX Value of the diffuse solar radiation
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
64/72
ANNEX I
Actual_variable Variable Unit Format Description
LONRA Longwave_radiation W/m^2 XXXXX Value of the longwave radiation
TOTRA Total_radiation W/m^2 XXXXX Value of the total radiation
NETRA Net_total_radiation W/m^2 XXXXX Value of the net total radiation
SHF Soil_heat_flux W/m^2 XXXXX Value of the soil heat flux
TPRE Air_temperature_at_precipitation_gauge °C XXX.X Value of the air temperature at precipitation gauge
TW Wet_bulb_temperature °C XXX.X Value of the wet bulb temperature
TR Runway_surface_temperature °C XXX.X Value of the runway surface temperature
TSN(Z) Snow_cover_temperature_profile °C XXX.X Value of the snow cover temperature at height Z measured in cm
LIGHTC Lightning_counter Count XXXXXX Aumount value of lightning read on the counter
SOG State_of_the_ground N.A. N.A. Value of the state of the ground
SM Soil_moisture N.A. N.A. Value of the soil moisture
I% Runway_lights_intensity % XXX Value of the percent of the runway lights intensity
TABLE 2
LOCATION POINT IDENTIFICATION CODE
Point Description
MET1 Identification of the location point of the METEO GARDEN 1
MET2 Identification of the location point of the METEO GARDEN 2
16APP Identification of the location point of the APPROACH AREA of the runway 1 (DIRECTION 160°)
16TDZ Identification of the location point of the TOUCH DOWN zone of the runway 1 (DIRECTION 160°)
16MID Identification of the location point of the MIDDLE SECTION of the runway 1 (DIRECTION 160°)
16END Identification of the location point of the END SECTION of the runway 1 (DIRECTION 160°)
34APP Identification of the location point of the APPROACH AREA of the runway 2 (DIRECTION 340°)
34TDZ Identification of the location point of the TOUCH DOWN zone of the runway 2 (DIRECTION 340°)
34MID Identification of the location point of the MIDDLE SECTION of the runway 2 (DIRECTION 340°)
34END Identification of the location point of the END SECTION of the runway 2 (DIRECTION 340°)
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
65/72
ANNEX I
TABLE 3
CONFIGURATION VARIABLE IDENTIFICATION CODE AND VALUE FORMAT
Configuration_variable Variable Unit Format Description
WMO Station_WMO_code Code XXXXXXXX Station WMO code
ICAO Airport_ICAO_code Code XXXXXXXX Airport ICAO code
LAT Latitude ° XXXXXX Latitude
LONG Longitude ° XXXXXX Longitude
DIR Runway_direction ° XXX Runway direction
MAG Magnetic_declination ° XX.X Magnetic declination
HZ Elevation m XXXX Elevation of the zero point of the barometer
HA Elevation m XXXX Datum level to wich barometric pressure reports
IRVR Runway_lights_intensity_table Code XXXXXXXX Number of the reference table of runway lights intensity against RVR values
TABLE 4
REPRESENTATIVE VARIABLE IDENTIFICATION CODE AND VALUE FORMAT
Representative_variable Variable Unit Format Description
WD2A Wind_direction ° XXX Mean value of the wind direction considering the last two minutes respect to the true north
WD10A Wind_direction ° XXX Mean value of the wind direction considering the last ten minutes respect to the true north
WD3A10M Wind_direction ° XXX Three seconds average value extreme of the wind direction considering the last ten minutes
respect to the true north
WD3A10X Wind_direction ° XXX Three seconds average value other extreme of the wind direction considering the last ten minutes
respect to the true north
WS2A Wind_speed m/s XX.X Mean value of the wind speed considering the last two minutes
WS10A Wind_speed m/s XX.X Mean value of the wind speed considering the last ten minutes
WS3A10M Wind_speed m/s XX.X Three seconds average minimum value of the wind speed considering the last ten minutes
WS3A10X Wind_speed m/s XX.X Three seconds average maximum three seconds average value of the wind speed considering the
last ten minutes
W3A10K Wind_marked_discontinuity % XXX Marked discontinuity of wind: "percent" of the 3 seconds average values effectively used for
elaboration of mean and extremes within the last ten minutes
VIS3A MOR_visibility m XXXXX Mean value of the general visibility considering the last three minutes
TRS1A MOR_Transmittance % XXX.X Mean value of the trasmittance considering the last minute
BGL1A Background_luminance Cd/m^2 XXXXXX Mean value of the background luminance considering the last minute
PWL Present_weather Code XXXXXXXX Last present weather code
CL1A Cloud_base_height m XXXXX Mean value of the height of the first detected level of clouds considering the last minute
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
66/72
ANNEX I
Representative_variable Variable Unit Format Description
CM1A Cloud_base_height m XXXXX Mean value of the height of the second detected level of clouds considering the last minute
CH1A Cloud_base_height m XXXXX Mean value of the height of the third detected level of clouds considering the last minute
CA1A Cloud_base_amount octa X Mean value of the amount of clouds considering the last minute
T1A Air_temperature °C XXX.X Mean value of the air temperature considering the last minute
RH1A Relative_humidity % XXX Mean value of the relative humidity considering the last minute
P1A Atmospheric_pressure hPa XXXX.X Mean value of the atmospheric pressure considering the last minute
PRE1T Precipitation_aumount mm XXXX Total amount of precipitation considering the last minute
DSNL Depth_of_snow cm XXXX Last value of depth of snow
WU(Z)L Wind_components_height_profile m/s XX.X Last wind component U value at height Z measured in m
WV(Z)L Wind_components_height_profile m/s XX.X Last wind component V value at height Z measured in m
TG1A Ground_temperature °C XXX.X Mean value of the ground temperature value considering the last minute
TS(Z)1A Soil_temperature °C XXX.X Mean value of the value of the soil temperature at depth Z measured in cm, considering the last
minute
SUNDUR1T Sunshine_duration h XX.X Total amount of sunshine duration considering the last minute
SOLRA1T Global_solar_radiation W/m^2 XXXXX Total amount of the global solar radiation considering the last minute
DIFRA1T Diffuse_solar_radiation W/m^2 XXXXX Total amount of the diffuse solar radiation considering the last minute
LONRA1T Longwave_radiation W/m^2 XXXXX Total amount of the longwave radiation considering the last minute
TOTRA1T Total_radiation W/m^2 XXXXX Total amount of the total radiation considering the last minute
NETRA1T Net_total_radiation W/m^2 XXXXX Total amount of the net radiation considering the last minute
SHF1T Soil_heat_flux W/m^2 XXXXX Total amount of the soil heat flux considering the last minute
TPRE1A Air_temperature_at_precipitation_gaug °C XXX.X Mean value of the air temperature at precipitation gauge considering the last minute
e
TW1A Wet_bulb_temperature °C XXX.X Mean value of the wet bulb temperature considering the last minute
TR1A Runway_surface_temperature °C XXX.X Mean value of the runway surface temperature considering the last minute
TSN(Z)L Snow_cover_temperature_profile °C XXX.X Last value of the snow cover temperature at height Z measured in cm
LIGHTC1T Lightning_counter Count XXXXXX Total amount of lightning considering the last minute
SOGL State_of_the_ground N.A. N.A. Last value of the state of the ground
SML Soil_moisture N.A. N.A. Last value of the soil moisture
I%L Runway_lights_intensity % XXX Last value of the percent of the runway lights intensity
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
67/72
ANNEX J
TABLE 5
DERIVED VARIABLE IDENTIFICATION CODE
Derived_variable Variable Unit Description
WDN Wind_direction_magnetic_north ° Value of the wind direction corrected respect to the magnetic north
WSC Wind_speed_across m/s Value of the component of the wind speed across the runway
WSL Wind_speed_along m/s Value of the component of the wind speed along the runway
R Runway_visual_range m Value of the RVR computed considering the 100% of runway light intensity
RI Runway_visual_range m Value of the RVR computed considering the actual I% of runway light intensity
DP Dew_point_temperature °C Value of the dew point temperature computed as function of (T, RH)
QFE Atmospheric_pressure hPa Value of the QFE computed as function of (P, T, RH, HZ, HA)
QFF Atmospheric_pressure hPa Value of the QFF computed as function of (P, T, RH, HZ)
QNH Atmospheric_pressure hPa Value of the QNH computed as function of (QFE, HA)
TABLE 6
REPRESENTATIVE DERIVED VARIABLE IDENTIFICATION CODE AND VALUE FORMAT
Representative_derived_variable Variable Unit Format Description
WD2AN Wind_direction ° XXX Value of WD2A corrected respect to the magnetic north
WD3A10MN Wind_direction ° XXX Value of WD3A10M corrected respect to the magnetic north
WD3A10XN Wind_direction ° XXX Value of WD3A10X corrected respect to the magnetic north
WS2AC Wind_speed_across m/s XX.X Value of the component of WS2A across the runway
WS2AL Wind_speed_along m/s XX.X Value of the component of WS2A across the runway
R1A Runway_visual_range m XXXX Mean value of the RVR (100%) considering the last minute
R5A Runway_visual_range m XXXX Mean value of the RVR (100%) considering the last five minutes
R5AP Runway_visual_range m XXXX Mean value of the RVR (100%) considering the first five minutes within the last ten minutes
R10T Runway_visual_range m XXXX Tendency code of RVR (100%): U, D, N, space
R10A Runway_visual_range m XXXX Mean value of the RVR (100%) considering the last ten minutes
R1A10M Runway_visual_range m XXXX Minimum of the RVR1A (100%) values considering the last ten minutes
R1A10X Runway_visual_range m XXXX Maximum of the RVR1A (100%) values considering the last ten minutes
RI1A Runway_visual_range m XXXX Mean value of the RVR (I%) considering the last minute
RI5A Runway_visual_range m XXXX Mean value of the RVR (I%) considering the last five minutes
RI5AP Runway_visual_range m XXXX Mean value of the RVR (I%) considering the first five minutes within the last ten minutes
RI10T Runway_visual_range m XXXX Tendency code of RVR (I%): U, D, N, space
RI10A Runway_visual_range m XXXX Mean value of the RVR (I%) considering the last ten minutes
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
68/72
ANNEX J
Representative_derived_variable Variable Unit Format Description
RI1A10M Runway_visual_range m XXXX Minimum of the RVR1A (I%) values considering the last ten minutes
RI1A10X Runway_visual_range m XXXX Maximum of the RVR1A (I%) values considering the last ten minutes
R30A10K RVR_marked_discontinuity % XXX Marked discontinuity of RVR (100%): "percent" of the 30 seconds average values effectively
used for elaboration of mean and extremes within the last ten minutes
RI30A10K RVR_marked_discontinuity % XXX Marked discontinuity of RVR (I%): "percent" of the 30 seconds average values effectively
used for elaboration of mean and extremes within the last ten minutes
DP1A Dew_point_temperature °C XXX.X Value of the dew point temperature computed as function of (T1A, RH1A)
QFE1A Atmospheric_pressure hPa XXXX.X Value of the QFE computed as function of (P1A, T1A, RH1A, HZ, HA)
QFF1A Atmospheric_pressure hPa XXXX.X Value of the QFF computed as function of (P1A, T1A, RH1A, HZ)
QNH1A Atmospheric_pressure hPa XXXX.X Value of the QNH computed as function of (QFE1A, HA)
TABLE 7
VISUAL VARIABLE IDENTIFICATION CODE AND VALUE FORMAT
Visual_variable Variable Unit Format Description
VIS MOR_visibility m XXXXX Value of the general visibility
PW Present_weather Code XXXXXXXX Present weather code
CL Cloud_base_height m XXXXX Value of the base height of the low level of clouds
CM Cloud_base_height m XXXXX Value of the base height of the medium level of clouds
CH Cloud_base_height m XXXXX Value of the base height of the high level of clouds
CA Cloud_base_amount octa X Value of the amount of clouds
CLG Cloud_genus Code XXXXXXXX Genus code of the low level of clouds
CMG Cloud_genus Code XXXXXXXX Genus code of the medium level of clouds
CHG Cloud_genus Code XXXXXXXX Genus code of the high level of clouds
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
69/72
ANNEX J
SPECIFICATIONS
MARKED DISCONTINUITY
1 ICAO RECOMMENDATIONS.
Ref. D (i.e. the ICAO annex 3) evidences that, in elaborating the
instantaneous data of meteo variables like the WIND and the RVR,
MARKED DISCONTINUITIES should be taken in account.
In particular Ref. D recommends that the ten minutes representative data
(mean, extremes, etc.), of the said meteo variables, should be computed
only using the instantaneous data after the beginning of the last MARKED
DISCONTINUITY.
Ref. D gives the following general definition of a marked discontinuity: “an
abrupt change of the meteo variable (WIND or RVR) lasting, at least, two
minutes”.
A pictorial expression of the above said definition could be the one shown
in the following figure:
Tafter
where Tafter is equal to two minutes.
Indeed, Ref. D does not give any peculiar specification about the other
secondary parameters which characterise, in practice, a meteo variable
abrupt change and are evidenced in the following paragraph.
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
70/72
ANNEX J
2 MARKED DISCONTINUITY PARAMETERS.
The parameters which characterise, in practice, a meteo variable abrupt
change are presented in the following figure:
Taverage
Tafter
Trise
Tbefore
where:
Taverage is the time to average the instantaneous data (i.e. the data
which the sensor unit sends to the AWS at the DTE output rate)
in order to have further filtered values representative and valid
for the detection of the MARKED DISCONTINUITY
phenomenon;
Tbefore is the time which should be considered before the MARKED
DISCONTINUITY abrupt change;
Trise is the rising time of the abrupt change itself;
Tafter is the lasting time of the MARKED DISCONTINUITY after the
abrupt change.
3 AWS ELABORATION.
The AWS processes, for the detection of the MARKED DISCONTINUITY
phenomenon, would be able to elaborate all the said four parameters
which should be fully configurable by the End User in order to achieve the
best of flexibility.
The following table proposes default values for such parameters.
Variable DTE output rate Taverage t Tbefore Trise Tafter
Wind 1 every second 3 seconds >=30 seconds <=6 seconds >=2 minutes
RVR 1 every 10 seconds 10 seconds >=30 seconds <=30 seconds >=2 minutes
or in alternative or in alternative
1 every 15 second 15 seconds
(i.e. no further
averaging)
EUMETNET AWS CONTRACT-TECHNICAL SPECIFICATIONS
71/72
Related docs
