Reception window forecast

Technical solution proposal H2017-029
Corporate entity: Diehl Metering Systems GmbH

Description:

Method for precalculating the expected reception window of a bidirectional meter on the data concentrator.

In the receiver, a precalculation of the expected radio reception window of bidirectional meters is made and stored without a previous command. This makes it possible to react as quickly as possible to the receipt of a command for a counter. A time-optimised transmission of the command to the meter is made possible.

This is to specify a 2-way communication between data concentrator and meter, in which the data concentrator knows the radio reception window of the meter and can thus make a temporally accurate transmission of commands to the meter.

Up to now, it was usual for the data concentrator to calculate the radio reception window of the bidirectional meter only if a command for it was received from the control centre beforehand. This makes it possible that the first reception window at the meter is missed and the command can only be delivered after a further calculation of the reception window.

In order for the receiver / data concentrator to be able to send commands to a bidirectional radio meter, it must know its reception window. This allows a command to be sent to the meter at the correct time. The receiver can only determine after receiving a telegram from the meter whether it will open a reception window and when this will be. In order for the receiver to know the In order for the receiver to determine the next reception time of the meter, it must be given a corresponding order. If this is only started with the receipt of a command for this counter, then the reception window can only be determined after the next received telegram, i.e. at least one counter telegram must be received.

If a counter transmits telegrams at long intervals or if a command is to be executed as quickly as possible, it is not advisable to wait for the reception of a counter telegram. The described procedure speeds up the delivery of commands to the counter. Furthermore, a method is described in which the processing of commands is made possible on devices with limited memory.

This makes it possible to use the first reception window after the receipt of a command at the data concentrator for the delivery of the command to the counter.

With the method, a pre-calculation of the expected reception window is carried out without a previous command at the data concentrator. In this way, the execution of the command can be optimised in terms of time. Furthermore, a method is described in which the processing of commands is made possible in devices with limited storage space.

1. system overview

The basic components of the communication between a bidirectional meter and the data concentrator are shown in figure 1. The data concentrator can send commands to the meter via radio. For the execution of commands and command sequences, the meter and the data concentrator use different components.

For bidirectional radio communication, both the meter and the data concentrator use the "Radio Manager" FM component.

The data concentrator has the component "Data Storage" DS. In this component there is a counter list. For each counter in the counter list ZL, a list with commands or command sequences can be stored and managed there. It is possible to store parameters per counter in the counter list, which provide information about its radio, e.g. the provision of the receiver receiver.

To process commands or command sequences, the meter and the data concentrator each use the "Command Manager" KM component.

For a command to be executed, it must be known to the command manager. For this purpose, the DS component in the data concentrator must provide the KM with information about commands to be executed.

The component "Receive Window Monitor" EM on the data concentrator calculates when a meter from the meter list is expected to provide a window for receiving a command via radio. For this calculation, the "Receive Window Monitor" component keeps and manages data that enable this precalculation.

2. Principle of communication

The principle of communication between the meter and the data concentrator can be seen in Figure 2. The meter automatically sends out repeated messages with its data.

On the side of the counter:

In order to reduce the energy consumption of the meter, the meter is not able to receive data permanently by radio, but it provides reception windows for this purpose. Information about the start of a reception window can be signalled by the meter in repeatedly transmitted messages. However, this can also be defined by system defaults. In this case it is not necessary that information about the reception window is sent in the message. Opening the receive window, sending and receiving data by radio is part of the radio manager FM on the meter.

On the side of the data concentrator:

The data concentrator receives and transmits a large number of meter messages via its radio manager FM. On reception, however, it only evaluates the messages from the meters that are contained in the meter list ZL of the data memory DS. Regardless of whether there are one or more commands for the meter in the data memory DS, the reception window monitor EM uses the stored parameters of the meter and the data from the received messages to calculate the expected reception window at the meter. If the command manager KM has to execute a command or a command sequence, it uses this calculated counter reception window to deliver a message to the counter at the exact time.

3. Method for the precalculation of the reception window in the reception window monitor

Method 1:

The counter signals in its messages when the next reception window is opened and how long it is. It is also possible that the counter signals when or how fast the data concentrator must send a message. The receive window monitor EM uses the time of reception of the telegram and the signalled data to calculate the receive window (time and duration) in advance and stores this in the counter - receive window table ZE-Ta- belle.

Example: In the w- bus frame, there is a bit in the transport layer that indicates the slow- or fast-response-delay mode of the counter. This indicates the time with which the data concentrator should respond and thus determines the counter receive window.

Method 2:

Parameters with information about the reception window are stored in the data memory DS. The reception window monitor EM uses the time of reception of the telegram and the stored data to calculate the reception window (time and duration) in advance and stores this in the counter reception window table ZE table.

Example: For a proprietary radio (such as RS in DM system), the response times and the duration of the window are fixed.

Method 3:

The meter transmits its messages with a fixed transmission scheme (e.g. periodic transmissions) and opens a reception window for each, so that the data concentrator can calculate this reception window with method 1 or method 2. The data concentrator knows the transmission scheme so that it can calculate the reception scheme in advance. This is stored in the counter reception window table ZE table.

The reception window monitor EM keeps data for each received meter in the meter reception window table ZE-Table. If the table receives outdated data (i.e. the next reception window is in the past), these are deleted or overwritten by new entries.

4. procedure for hitting the reception window on the meter

To execute a command in the data concentrator, the command must be available in the command manager (KM). Commands that are stored in the data memory (DS) must first be transferred to the command manager. KM uses the counter -receiving window table that the receiving window monitor (EM) creates.

Figure 3 shows that KM does not calculate the receive window after receiving a message if there is no command for the counter. Only when a command for the counter is stored in KM, then the reception window is calculated. This is the procedure used at the moment. This means that a possible reception window on the counter can be missed. The command is not delivered at the earliest possible time, but with a delay. This can be seen in Figure 3, where a reception window is missed.

Figure 4 shows that KM always calculates the reception window after receiving a message, even if there is no command for the counter. This allows the next possible receive window on the counter to be used. The command is delivered at the earliest possible time.

Figure 5 shows that KM performs a calculation of the reception scheme of the counter after receiving a message, even if there is no command for the counter. This allows the next possible reception window on the counter to be used, even if messages sent by the counter have been lost. The command is thus delivered at the earliest possible time.

5. optimisation of command processing

The data memory (DS) can load optimised commands into the com- mando manager (KM) with the help of the counter-receiving window table ZE table of the receiving window monitor (EM). Figure 6 shows various optimisations..

Optimisation procedure:

• A command is given by the DS to the EM only shortly before the arrival of the time of the reception window from the DS in order to save resources on the EM. In this way, devices with a limited memory capacity in the EM can still process a large command list (i.e. commands for many counters) in the DS, since only a small number of commands are being processed in the EM.
• In general, the counters of their chronological sequences are loaded from the DS into the EM (see column "Transfer sequence to KM").
• The DS immediately loads a command with high priority into the KM if no reception window time is stored in the EM (see counter 2). If the command does not have high priority, it can also be executed at a later time.
• If the same reception window time is stored in the EM for 2 counters, then the respective command is not loaded into the KM at the same time (see counters 4 and 5).