Sunteți pe pagina 1din 16
Optimising Polling Strategies on Courier-Based Devices COURIER - R6540A

Optimising Polling Strategies on Courier-Based Devices

COURIER - R6540A

Optimising Polling Strategies on Courier-Based Devices COURIER - R6540A

R6540A

Page 2 of 24

CONTENTS

R6540A

Page 3 of 24

1.

APPLICATION, AND BASIC OPERATING SEQUENCE

5

1.1

Operating sequence

5

1.2

Operation modes

6

2.

MAIN OPERATING FEATURES

7

2.1

Instantaneous trips selector

7

2.2

Maintenance alarm

7

2.3

Maintenance lockout

8

2.4

Auto reclose initiation inhibit for a pre-selected time TMR Mancl AR Inh, following manual CB closing, or following energisation of a previously dead line.

8

2.5

Cold load pick-up logic

8

2.6

Excessive fault frequency lockout

8

2.7

Delayed manual close

8

2.8

Reset from lockout

9

2.9

Omit first shot of programmed cycle if selected protection operates

9

2.10

Successful auto-reclose indication (Logic output RLY A/R Success, and control output CTL A/R Success)

9

2.11

CB failed to close alarm

9

2.12

Input mode selection

9

2.13

Auto reclose without protection operation

10

2.14

Auto reclose initiation with CB initially open

10

2.15

Dead time starty without protection reset

10

2.16

First reclosure without system check

10

2.17

Maintained close pulse

10

2.18

Setting changes in or out of service

10

2.19

Fault not cleared alarm

10

2.20

Sensitive earth fault

11

2.21

Test trip and autoreclose

11

2.22

Circuit breaker control

11

2.23

Co-ordination with other devices

12

2.24

Remote auto/non auto operation modes

12

2.25

Default display

13

3

SCHEME INPUTS

13

4

USER INPUTS

14

5

SCHEME OUTPUTS

14

6

CONTROL OUTPUTS

16

7

PLANT STATUS OUTPUTS

16

8

SOFTWARE LOGIC FUNCTIONS

17

8.1

Menu cell 0A01 - Scheme Fn Links 1

17

8.2

Menu cell 0A02 - Scheme Fn Links 2

18

9

TIMER SETTING RANGES

18

R6540A

Page 4 of 24

10

PROTECTION SETTING RANGES

19

11

COUNTERS

19

11.1

Counter registers (coils/resets)

19

11.2

Counter settings (targets)

20

11.3

Counter values (messages)

20

12

SCHEME ALARMS

20

12.1

Status 1 alarms - red LED continuous

20

12.2

Compound alarms - red LED flashing

20

13

EVENT RECORDS

21

Figure 1

KCGG/KVTR integrated autoreclose and protection relay scheme connection diagram using interposing relays from SCADA

23

SECTION 1.

INTRODUCTION

R6540A

Page 5 of 24

The Courier Communication Language is designed for a master-slave polled environment, consisting of a master device connected to one or more slave devices, usually in a multi-drop configuration. To avoid message collisions on the communication bus, slaves can only transmit within 5ms of receiving a request for data from the master. As this is a relatively short amount of time, the slave device will not normally be able to process the request and return the appropriate response. A busy message is therefore returned, indicating that the slave device will continue processing the message and that the master device should return some time later to request the result using a poll buffer command. Repeated busy messages will be returned to each poll buffer request until the slave has completed its processing, at which point the originally requested data will be returned.

SECTION 2.

ACCESSING SLAVE DEVICE DATA

The Courier Communication Language has been designed to be generic, such that each slave device could contain different information, or the same information but in different formats. This allows for the flexibility of developing new slave devices in the future which will be completely compatible with any existing Courier installation. Data in each slave device is arranged into a database where each item of data is given a menu location. Each item of data is accessed using a single command called the Get_Value command. It has only one parameter which is the menu location of the data to be accessed. Information from a slave device is therefore accessed by sending a Get_Value command for each item of data required. Each request can be sent individually, or they can be grouped into a single message sent only once.

Slave devices may also need to send unsolicited information to the master device from time to time. This usually includes data which rarely changes, but when it does, the master device needs to know about it as soon as possible. Regularly polling the slave device for this information would be an inefficient use of the communication system, and polling at a slower rate would not provide the required response time.

An event mechanism is therefore included for sending information such as changes to the circuit breaker status. Whenever such an event occurs, the slave device raises a flag which is sent to the master in each slave response. Detection of this flag being set causes the master device to request the events that have been stored in the slave device, thus maintaining the efficiency and response time required.

SECTION 3.

DEVELOPING A POLLING STRATEGY

R6540A

Page 6 of 24

The first step in deciding on a polling strategy is to determine the following information:

· how many slave devices are to be polled

· what communication speed is to be used

· what information is needed from each slave device

· how often it is required to be updated

· relative priorities of the data.

From this information, the polling strategy can be determined:

· if data should be asked for individually or as a whole

· whether events should be used, or digital status polled for

· how often data should be requested

However, in order to optimise the polling strategy to get the best out of the communication system, some details of the internal operation of the slave devices needs to be understood.

SECTION 4.

THE FUNCTION OF THE BUSY MESSAGE

In a protective relay slave device, the communication is considered to be a low priority task compared to the device’s protection functions. It is likely, therefore, that the processing of an incoming request will not be completed within the 5ms response time allowed, and thus a busy response will be returned. Further busy responses will be returned if subsequent Poll_Buffer commands are sent too early, ie. before the data is available. This will be particularly true in the case where many Get_Value requests have been sent in a single message as the total response time will be the sum of the response times of each individual Get_Value request, and thus longer.

What is the effect of repeatedly sending Poll_Buffer commands until the data is available?

In actual fact, this slows down the response time of the slave device. The slave device may only have one microprocessor which is shared between all the tasks that must be executed. The communication task has a relatively low priority so it does not execute for very long periods of time. By repeatedly sending Poll_Buffer commands to a slave device which is busy, the communication task is using most of its available time slot to processing the Poll_Buffer request and replying busy, instead of being able to devote all of its time to processing the previous request. Thus it takes longer to obtain the required result.

So why not eliminate the Busy response altogether?

To do so would compromise the efficiency of the communication bus by reducing the bandwidth. By increasing the allowable response time from 5ms to a time greater than any slave devices maximum response time, say 500ms, would mean the bus could be idle for periods of up 500ms. This time could be utilised more effectively to communicate to other devices on the same multi-drop bus. At 64kBaud, 4000 bytes (characters) could have been transferred during this period.

R6540A

Page 7 of 24

It would also take in excess of 500ms to detect that a slave device is not communicating and that a potential error exists, whereas using a 5ms response time, this potential error could have been detected and rectified in a much shorter time.

SECTION 5.

EXAMPLE OF AN OPTIMISED POLLING STRATEGY

The key to optimising the polling strategy is to use the busy response to advantage and to eliminate as much redundant message transferral as possible. This worked example of a polling strategy has been devised for the following specific requirements:

· 4 slave devices are to be polled on one communication bus

· 64kBaud on K-Bus

· 23 menu cells to be polled from each device

· All data from all relays to be refreshed within 1 second of an occurrence

· Analog and digital data to be updated within 1 second, therefore, same priority.

The first thing to recognise is that any data sent over a communication system contains a certain amount of overhead. In the case of K-Bus messages, this amounts to 11 bytes for a request and at least 19 bytes for its response. It is therefore advantageous to minimise the number of messages by increasing their length as a result of requesting as much information in one go as possible.

Secondly, the event mechanism requires at least two transmissions and two receptions per event and is therefore less efficient in terms of data transfer than simply using a Get_Value command. Its use should be reserved to systems where very little data is being polled on a regular basis, or when the polling interval is particularly long. In both of these cases, the bus bandwidth is not fully utilised, so the available time can be devoted to polling for events.

In the above specification, the digital and analog data have the same priority, so using the event mechanism to give the digital events higher priority has no real advantage. The number of menu cells to be requested (including the digital information) can all fit into one request message, as can their respective responses, so the additional overhead of requesting the digital information on each poll is negligible.

Due to the large amount of data that is to be requested in one message, the relay would ordinarily respond with a Busy message. Continuous polling of the relay thereafter would lengthen the response time, however, tests have shown that the response time is around 300ms for 23 menu cells if no poll buffers are involved. This response time should be used to advantage by requesting the same data from other relays on the bus during this period.

The master device should be prevented from issuing a Poll_Buffer command to any Slave device until the maximum response time has elapsed from sending it its original request. After the maximum response time has elapsed, the next poll buffer command will yield the requested data straight away. The same relay should immediately be requested for the same data again to fully utilise the available time. In this way, all non-essential Poll_Buffer requests and Busy responses are eliminated. The total communication time for requesting and receiving the required

R6540A

Page 8 of 24

data from each relay is now constant and can be determined. Dividing the poll cycle period by this communication time will determine the number of relays that can be serviced on a given bus for a given communication speed.

5.1 Strategy analysis

This analysis of the example polling strategy assumes the following details:

· The request (Ta) consists purely of Get_Value commands, each of 4 byte packets

· The response (Tg) consists of 6 byte data packets (typical for Courier Numeric types).

· The message format is as on K-BUS (the difference in length from IEC870 is ignored).

The timing diagram below is to illustrate the relationship between the communication messages between a master device and each of 4 slave relay devices. All the message transmissions occur over the same communication bus, but are separated out on the diagram depending on the relay which is receiving or transmitting the message. Transmissions from the master device are shown shaded, each one is accompanied by a slave response shown in white. The diagram assumes communication has been in progress for some time (the first poll cycle period would look slightly different due to the startup conditions). The polling cycle begins by the master device requesting all the data from relay 1 (Ta). The relay responds with a busy message. (Tc) A poll buffer message is sent to relay 2 which responds with its previously requested data. The relay is then immediately asked for the same data which results in a busy message. This is repeated for relays 3 & 4. By this time, the maximum relay response time for relay 1 (Td) will have expired, so a Poll_Buffer message is sent to it (Te). Relay 1 responds with its data (Tg) and the next polling cycle period starts.

Rly 1

Rly 2

Rly 3

Rly 4

TeTf Tg Th Ta Tb Tc Td Te Tf Tg Th Ta Tb Tc Poll
TeTf
Tg Th
Ta Tb Tc
Td
Te Tf
Tg
Th
Ta Tb Tc
Poll Cycle Period

R6540A

Page 9 of 24

The following times are defined:

Ta = Communication time of Tx message (length / effective baud rate)

Tb = Relay turnaround time (5ms) + 2 x delay through KITZ (=2.5ms) = 7.5 ms

Tc = Communication time of Busy response (length / effective baud rate)

Td = Maximum response time of relay

Te

= Communication time of Poll Buffer message (length / effective baud rate)

Tf

= Tb

Tg = Communication time of Rx message (length / effective baud rate)

Th = turnaround time of Master device (assume zero).

Tt = total time = Ta+Tb+Tc+Td+Te+Tf+Tg+Th

Tu = utilised communication time for one relay = Tt - Td

In this analysis, the calculations are to be generalised so that the equations can be

used for different system configurations. The following variables are therefore

defined:

P

= Poll cycle period = 500ms

R

= Number of relays on K-BUS spur

C

= Number of cells extracted from each relay

B

= Effective baud rate (bytes/s)

D

= Maximum allowable relay response time

(Note that in order to guarantee a 1s update cycle maximum, P must be 0.5s - from Nyquists sampling theorem).

Equation 1

ie. The relay response time plus the total communication time must be less than the poll cycle period.

Equation 2

ie. The number of relays on a spur must be less than the total time to extract the data from one relay divided by the utilised communication time for one relay.

For this polling strategy to work, the following conditions need to be met:

The effective baud rate is the combination of the K-BUS speed (Sk) and the IEC870 speed (Si) on each side of the KITZ and gives an overall communication time from master device to relay given the length of the message. (This assumes the same byte length on either side, which is not strictly true, but negligible for long messages).

B = (Sk x Si) / (Sk+Si)

Note that even with 64kBaud speed on either side of the KITZ, the effective baud rate reduces to only 32kBaud. Also, the lowest baud rate predominates, so for Si = 9600 and Sk = 64000, B = 8347 baud! Elimination of the KITZ should be aimed for as this is a major bottleneck.

Td + Tu < P

R < Tt/Tu

The K-Bus message format is as follows:

R6540A

Page 10 of 24

Tx:

0

0

S

A

0

L

61

08 data crc1

crc2

E

Rx:

0

0

S

A

0

L

61

08 3C

04

t1

t2

t3

t4

5D

0 data crc1 crc2

E

 

For Tx: the message overhead is 11 bytes.

 

For Rx: the message overhead is 19 bytes.

5.1.1

Determining Tu

 

A

complete polling cycle for one relay involves one request message, one busy

 

response, one poll buffer and one valid response. The total number of bytes (L) transferred is given by:

L

= (11 + 4C) + (19+0) + (11+2) + (19+6C)

 

L

= 62 + 10C

 

This is transferred in a time (t) of

 

t

= L/B

which is equivalent to the following times from the above diagram:

 

Ta+Tc+Te+Tf = L/B

 

From previous equations we have a formula to determine Tu as follows:

 

Tu = Tt - Td (assuming Tt = P, worst case)

 

Tu = Ta+Tb+Tc+Td+Te+Tf+Tg+Th - Td

 

Tu = (Ta+Tc+Te+Tf) +Tb+Tg+Th

 

Tu = L/B + 2Tb

 

So substituting known values gives:

 

Tu = 15ms + (62+10C)/B

 

5.1.2

Determining Td

 

Now from equation 1 we can derive an expression for the maximum relay response time Td:

 

P-Td = Tu

 

P-Td = 15ms + (62+10C)/B

 

so

Td = P - (15ms +(62ms+10C)/B)

 

5.1.3

Determining expressions for B & C

 

From equation 2 we can also derive expressions for B & C, assuming that P = Tt (worst case):

Tt/R = Tu

P/R

P/R = 15ms + (62ms+10C)/B

Rearranging this yields the required expressions for B & C.

= Tu

R6540A

Page 11 of 24

and

B = (62 + 10*C) / (P/R-15ms)

Using the above equations, it is possible to show the relationship between the number of relays, the effective baud rate, the required relay response time and the number of cells that can be extracted from each relay.

Note that in this analysis, no account has been made for extracting additional data such as fault records and disturbance records, or to action any commands. As these usually occur infrequently, it is assumed that these would take precedence over any polling activity which would be suspended for the duration of the operation. Alternatively, spare bandwidth capacity could be made available on the communication network (for example, by increasing the baud rate or reducing the number of relays on a bus) for such operations so that they do not impinge on the normal polling sequence.

SECTION 6.

EXAMPLES OF USING THE EQUATIONS

Using the equations from the above strategy analysis, the following tables and graphs have been produced to show a clearer indication of the relationship between the effective baud rate, the number of relays, the cycle time, relay response time and amount of requested information. These can be used to determine whether specific system requirements are achievable and how they might best be realised.

All of these tables assume a polling cycle period of 500ms.

6.1 Maximum allowable response time

This table shows the maximum response time that can be allowed from any Courier device given the baud rate of the KITZ and the number of cells to be polled per relay.

KITZ baud rate

9600

19200

38400

57600

No KITZ

Effective Baud Rate

8347

14769

24000

30315

64000

 

8

349

408

438

448

467

cells/relay

16

272

365

411

426

457

24

196

321

384

405

447

32

119

278

358

384

437

R6540A

Page 12 of 24

Maximum response time

500 450 400 350 300 Time (ms) 250 200 150 100 50 0 0 10000
500
450
400
350
300
Time (ms)
250
200
150
100
50
0
0
10000
20000
30000
40000
50000
60000
70000

Effective Baud rate

8 16 24 32
8
16
24
32

6.2 Number of relays on one KITZ

Assuming the above response times can be met, the following table shows the maximum number of relays that can be satisfied on one KITZ.

KITZ baud rate

9600

19200

38400

57600

No KITZ

Effective Baud Rate

8347.826

14769.23

24000

30315.79

64000

 

8

3

5

8

10

15

cells/relay

16

2

4

6

7

12

24

2

3

4

5

9

32

1

2

4

4

8

6.3 Number of cells readable per relay

From another perspective, given the baud rate and the number of relays on a spur, the number of cells that could be read from each relay can be determined (note however, that this assumes both the request and response are single messages, which practically limits the number of cells to about 30):

R6540A

Page 13 of 24

KITZ baud rate

9600

19200

38400

57600

No KITZ

Effective Baud Rate

8347.826

14769.23

24000

30315.79

64000

 

1

44

83

139

178

382

2

18

37

64

83

182

3

10

22

39

51

115

No. relays

4

5

14

27

35

82

5

3

9

19

26

62

6

1

6

14

20

48

7

0

4

11

15

39

8

0

3

8

12

32

20

0

0

0

0

2

Required

Response Time

(ms)

400

350

300

250

200

150

100

50

0

-50

Cells per relay 0 20000 40000 60000 80000
Cells per relay
0
20000
40000
60000
80000

Effective Baud Rate

12 3 4 5 6 7 8

21 3 4 5 6 7 8

31 2 4 5 6 7 8

41 2 3 5 6 7 8

51 2 3 4 6 7 8

61 2 3 4 5 7 8

71 2 3 4 5 6 8

81 2 3 4 5 6 7

6.4 Effective baud rate required

R6540A

Page 14 of 24

If the number of relays on one KITZ and the number of cells to be read from each relay is known, the minimum effective baud rate can be determined:

No. of Relays

12345678

 

8 2342

4834

7490

10327

13365

16624

20132

23916

Cells/relay

16 3662

7557

11710

16145

20894

25990

31473

37389

24 4981

10281

15930

21964

28424

35356

42815

50863

32 6301

13004

20149

27782

35953

44722

54157

64337

Effective Baud Rate Required

Effective Baud

Rate

70000 60000 1 2 50000 3 40000 4 5 30000 6 20000 7 10000 8
70000
60000
1
2
50000
3
40000
4
5
30000
6
20000
7
10000
8
0
8
16
24
32

Cells

For the specific cases of the number of relays and number of cells given, the effect of varying the polling cycle period on the effective baud rate can be shown:

R6540A

Page 15 of 24

 

Relays

45678

cells

23

23

23

23

23

Cycle

500

21236

27482

34185

41397

49179

period

600

17304

22248

27482

33034

38933

(ms)

700

14600

18688

22977

27482

32221

800

12627

16110

19741

23528

27482

900

11124

14158

17304

20569

23959

1000

9940

12627

15402

18270

21236

2000

4816

6068

7338

8629

9940

3000

3178

3993

4816

5648

6489

4000

2372

2976

3585

4198

4816

5000

1891

2372

2855

3341

3830

6000

1573

1971

2372

2774

3178

7000

1346

1687

2028

2372

2716

8000

1177

1474

1772

2071

2372

9000

1045

1309

1573

1838

2105

10000

940

1177

1414

1653

1891

6.5 Spare communication time

By reducing the number of relays or the number of cells extracted per relay, it is possible to gain some spare communication time. This is shown in ms in the following table for a baud rate of 64kBaud (ie. with no KITZ). The amount of this spare communication time which is available for sending commands or extracting additional information is largely dependent on the response times of the relay, since although there is spare bandwidth on the communication bus, all the relays may be busy processing their poll messages and unable to accept additional commands.

effective

baud:

64000

relays:

88884444

cells:

23

20

14

10

23

20

14

10

Cycle

500

88

118

178

218

294

309

339

359

Period

600

188

218

278

318

394

409

439

459

(ms)

700

288

318

378

418

494

509

539

559

800

388

418

478

518

594

609

639

659

900

488

518

578

618

694

709

739

759

1000

588

618

678

718

794

809

839

859

SECTION 7.

CONCLUSION

This document illustrates how adopting the correct polling strategy for a particular situation can affect the throughput and efficiency of the system as a whole. It also shows how the baud rate on the RS232 side of the KITZ is a limiting factor, why the highest baud rate possible should be used, and ideally why the KITZ should be eliminated altogether.

Equations have been developed which can be used to determine how best to configure the communication network for such a polling strategy. All that remains is to determine the response time of the relays for the particular information required.

Publication: COURIER - R6540A

TRANSMISSION & DISTRIBUTION

Publication: COURIER - R6540A TRANSMISSION & DISTRIBUTION Energy Automation & Information

Energy Automation & Information

energy-automation.information@tde.alstom.com

www.tde.alstom.com

Contact Centre on line 24 hours a day : +44 (0) 1785 25 00 70