URCB: формирование отчетов по dchg|qchg с integrity

У меня возник вопрос по пониманию стандарта.

В соответствии с п.17.2.3.2.3.3  стандарта 61850-7-2 ed.2 перед посылкой отчета по integrity сервер должен отправить все буферизованные события. По п.17.2.2.12 когда в BRCB включена передача отчетов по integrity, параметр BufTm не действует. То есть получается, что отчеты по dchg|qchg должны формироваться и передаваться в следующих случаях:

1) если было повторное изменение сигнала (п.17.2.2.9).
2) если истек интервал времени BufTm (п.17.2.2.9) и не должны формироваться периодические отчеты (integrity, п.17.2.2.12).
3) перед посылкой отчета по integrity (п.17.2.3.2.3.3).
4) перед посылкой отчета по команде GI (п.17.2.3.2.3.4).

То есть, если в блоке управления отчета включены оба типа передачи отчета (периодическая  (integrity) и по изменению сигналов (dchg и/или qchg)),  отчеты по изменению сигналов должны буферизоваться за время IntgPd и выдаваться перед периодическими отчетами.

Правильно ли понят стандарт? Относится ли все написанное к URCB?  Если событий нет, нужно ли передавать   “пустой” отчет (Inclusion-bitstring ==0)?  Это допустимо или этого категорически нельзя делать? Или п.17.2.3.2.3.3 относится только к буферизованным отчетам и к событиям, буферизуемым по п.17.2.3.2.3.6 за время отсутствия соединения или разрешения на передачу? Если п.17.2.3.2.3.3 и 17.2.3.2.3.4 относятся ко всем событиям и к URCB, почему соответствующие тесты (sBr11 и sBr12) в 61850-10 описаны только для BRCB?

elena
Автор: elena
1
голос
1
ответ
1 ответ

Постараемся разобраться по пунктам.

По п.17.2.2.12 когда в BRCB включена передача отчетов по integrity, параметр BufTm не действует.
 
Видимо, этот вывод сделан на основании “An integrity report shall report the values of all members of the related data-set. BufTm shall have no effect when this change issues a report.” Если это так, ты вы понимаете не совсем верно. Речь здесь идёт о том, что в отчётах, работающих по Integrity не делается буферизация событий перед отправкой, в этом просто нет никакого смысла, так как по Integrity в любом случае передаются все элементы набора данных.
 
То есть получается, что отчеты по dchg|qchg должны формироваться и передаваться в следующих случаях:

1) если было повторное изменение сигнала (п.17.2.2.9).
2) если истек интервал времени BufTm (п.17.2.2.9) и не должны формироваться периодические отчеты (integrity, п.17.2.2.12).
3) перед посылкой отчета по integrity (п.17.2.3.2.3.3).
4) перед посылкой отчета по команде GI (п.17.2.3.2.3.4).
 

Я бы всё-таки поменял местами пункты, хотя в общем вроде бы всё правильно. Но, во-первых, должно быть некоторое первое событие (которое, я так понимаю, подразумевается по умолчанию). После чего запускается счётчик BufTm. Дальше 3 варианта:

1. BufTm истёк. Тогда отправляется отчёт с теми данными, что изменились.
2. Сигнал изменился повторно. Тогда следует принимать во внимание FC для данного атрибута (см. 17.2.2.9), в частности, для FC=MX величина может быть просто заменена и отчёт продолжит ждать отправки до истечения BufTm.
3. По GI или Integrity.

То есть, если в блоке управления отчета включены оба типа передачи отчета (периодическая  (integrity) и по изменению сигналов (dchg и/или qchg)),  отчеты по изменению сигналов должны буферизоваться за время IntgPd и выдаваться перед периодическими отчетами
Тут то ли опечатка, то ли ошибка. Очтёты по изменению буферизируются на время BufTm, а не IntgPd. Если BufTm истёк до того, как прошёл IntgPd, то отчёт всё равно будет отправлен.

Относится ли все написанное к URCB?
Отличия регулируется п. 17.2.5.2. В части BufTm и IntgPd никаких отличий у них нет, так что, да, всё указанное в равной степени касается и URCB, и BRCB.

Если событий нет, нужно ли передавать   “пустой” отчет (Inclusion-bitstring ==0)?
Нет, зачем? Это же не GOOSE… А если по GI или Integrity отчёт передаётся целиком со всеми данными.

Это допустимо или этого категорически нельзя делать? Или п.17.2.3.2.3.3 относится только к буферизованным отчетам и к событиям, буферизуемым по п.17.2.3.2.3.6 за время отсутствия соединения или разрешения на передачу?

Не могу себе представить случая, когда возникнет необходимость отправить пустой отчёт. Пустых отчётов просто не может быть по GI или Integrity.

Если п.17.2.3.2.3.3 и 17.2.3.2.3.4 относятся ко всем событиям и к URCB, почему соответствующие тесты (sBr11 и sBr12) в 61850-10 описаны только для BRCB?
Потому что для URCB описаны sRp11 и sRp12 – те же самые тесты.

 

Alexey Anoshin
Alexey Anoshin
Вопросов:  0 Ответов:  23

Вам нужно авторизоваться, чтобы оставить ответ .


Цифровая подстанция

(close)

 

Цифровая подстанция

(close)

Имя пользователя должно состоять по меньшей мере из 4 символов

Внимательно проверьте адрес электронной почты

Пароль должен состоять по меньшей мере из 6 символов

 

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: