Optimising Polling Strategies on Courier-Based Devices

COURIER - R6540A

R6540A Page 2 of 24

R6540A Page 3 of 24

CONTENTS 1. 1.1 1.2 2. 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24 2.25 3 4 5 6 7 8 8.1 8.2 9 APPLICATION, AND BASIC OPERATING SEQUENCE 5 Operating sequence 5 Operation modes 6 MAIN OPERATING FEATURES 7 Instantaneous trips selector 7 Maintenance alarm 7 Maintenance lockout 8 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 Cold load pick-up logic 8 Excessive fault frequency lockout 8 Delayed manual close 8 Reset from lockout 9 Omit first shot of programmed cycle if selected protection operates 9 Successful auto-reclose indication (Logic output RLY A/R Success, and control output CTL A/R Success) 9 CB failed to close alarm 9 Input mode selection 9 Auto reclose without protection operation 10 Auto reclose initiation with CB initially open 10 Dead time starty without protection reset 10 First reclosure without system check 10 Maintained close pulse 10 Setting changes in or out of service 10 Fault not cleared alarm 10 Sensitive earth fault 11 Test trip and autoreclose 11 Circuit breaker control 11 Co-ordination with other devices 12 Remote auto/non auto operation modes 12 Default display 13 SCHEME INPUTS 13 USER INPUTS SCHEME OUTPUTS CONTROL OUTPUTS PLANT STATUS OUTPUTS SOFTWARE LOGIC FUNCTIONS Menu cell 0A01 - Scheme Fn Links 1 Menu cell 0A02 - Scheme Fn Links 2 TIMER SETTING RANGES 14 14 16 16 17 17 18 18

R6540A Page 4 of 24

10 11 11.1 11.2 11.3 12 12.1 12.2 13 Figure 1

PROTECTION SETTING RANGES COUNTERS Counter registers (coils/resets) Counter settings (targets) Counter values (messages) SCHEME ALARMS Status 1 alarms - red LED continuous Compound alarms - red LED flashing EVENT RECORDS KCGG/KVTR integrated autoreclose and protection relay scheme connection diagram using interposing relays from SCADA

19 19 19 20 20 20 20 20 21

23

R6540A Page 5 of 24

SECTION 1.

INTRODUCTION

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.

R6540A Page 6 of 24

SECTION 3.

DEVELOPING A POLLING STRATEGY

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 devices 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.

TeTf Rly 1 Rly 2 Rly 3 Rly 4

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 Td + Tu < P ie. The relay response time plus the total communication time must be less than the poll cycle period. Equation 2 R < Tt/Tu 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.

R6540A Page 10 of 24

The K-Bus message format is as follows: Tx: Rx: 0 0 S 0 0 S A 0 L A 0 L 61 08 data crc1 crc2 E 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 5.1.3 Td = P - (15ms +(62ms+10C)/B)

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 = Tu P/R = 15ms + (62ms+10C)/B Rearranging this yields the required expressions for B & C. C = (B(P/R -15ms) - 62ms) / 10

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 Effective Baud Rate 8 cells/relay 16 24 32 9600 8347 349 272 196 119 19200 14769 408 365 321 278 38400 24000 438 411 384 358 57600 30315 448 426 405 384 No KITZ 64000 467 457 447 437

R6540A Page 12 of 24

Maximum response time

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

Effective Baud rate

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 Effective Baud Rate 8 cells/relay 16 24 32 9600 8347.826 3 2 2 1 19200 14769.23 5 4 3 2 38400 24000 8 6 4 4 57600 30315.79 10 7 5 4 No KITZ 64000 15 12 9 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 Effective Baud Rate 1 2 3 No. relays 4 5 6 7 8 20

9600 8347.826 44 18 10 5 3 1 0 0 0

19200 14769.23 83 37 22 14 9 6 4 3 0

38400 24000 139 64 39 27 19 14 11 8 0

57600 30315.79 178 83 51 35 26 20 15 12 0

No KITZ 64000 382 182 115 82 62 48 39 32 2

Cells per relay

400 350 300 250 Required 200 Response Time 150 (ms) 100 50 0 -50 0 20000 40000 60000 80000 1 2 3 4 5 6 7 8

Effective Baud Rate

R6540A Page 14 of 24

6.4

Effective baud rate required 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 1 8 2342 Cells/relay 16 3662 24 4981 32 6301 2 4834 7557 10281 13004 3 7490 11710 15930 20149 4 10327 16145 21964 27782 5 13365 20894 28424 35953 6 16624 25990 35356 44722 7 20132 31473 42815 54157 8 23916 37389 50863 64337

Effective Baud Rate Required

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

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

Cycle period (ms)

Relays cells 500 600 700 800 900 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000

4 23 21236 17304 14600 12627 11124 9940 4816 3178 2372 1891 1573 1346 1177 1045 940

5 23 27482 22248 18688 16110 14158 12627 6068 3993 2976 2372 1971 1687 1474 1309 1177

6 23 34185 27482 22977 19741 17304 15402 7338 4816 3585 2855 2372 2028 1772 1573 1414

7 23 41397 33034 27482 23528 20569 18270 8629 5648 4198 3341 2774 2372 2071 1838 1653

8 23 49179 38933 32221 27482 23959 21236 9940 6489 4816 3830 3178 2716 2372 2105 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: relays: cells: Cycle 500 Period 600 (ms) 700 800 900 1000

64000 8 23 88 188 288 388 488 588

8 20 118 218 318 418 518 618

8 14 178 278 378 478 578 678

8 10 218 318 418 518 618 718

4 23 294 394 494 594 694 794

4 20 309 409 509 609 709 809

4 14 339 439 539 639 739 839

4 10 359 459 559 659 759 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.

TRANSMISSION & DISTRIBUTION Energy Automation & Information energy-automation.information@tde.alstom.com Contact Centre on line 24 hours a day : +44 (0) 1785 25 00 70

Publication: COURIER - R6540A

www.tde.alstom.com