21 (2021-06-09 07:52:53 отредактировано dev_ekra_ru)

Re: Быстродействие передачи GOOSE

ПАУтина писал(а):
2021-06-09 02:20:24

Коллеги!

Есть ли натурные осциллограммы передачи сигналов по goose и/или MMS?
Особенно интересуют осциллограммы передачи аналоговой передачи по ММS?

наверное не MMS, а SV?

Также не совсем понятно что нужно. Осциллограмма процесса на энергообъекте, записанная устройством с цифровым приемом измерений и дискретных сигналов или осциллограмма канала Ethernet в процессе передачи пакетов Goose/SV (но какой тут может быть Comtrade?)

Сайт: dev.ekra.ru | Почта: dev@ekra.ru | Тел.: 8 (8352) 220-130 (доб. 1057, 1099, 1267) | Часы работы: 08:00 - 17:00 по Москве

22

Re: Быстродействие передачи GOOSE

dev_ekra_ru писал(а):
2021-06-09 07:49:45

Также не совсем понятно что нужно. Осциллограмма процесса на энергообъекте, записанная устройством с цифровым приемом измерений и дискретных сигналов или осциллограмма канала Ethernet в процессе передачи пакетов Goose/SV (но какой тут может быть Comtrade?)

Вот, если бы я сам знал!!!
Запросил не корректно, действительно Goose/SV.
Вопрос может быть и не к релейщика, но это не мой "каприз", что в датчиках для телемеханики начали применять протоколы IEC61850 и заявляют, что они полностью отвечают их требованиям, а т.к. он начал применяться вначале в РЗ, значит есть уже какой-то опыт, потому и обращаюсь за помощью.
По поводу дискретных сигналов проблем нет, надёжность их передачи согласно требованиям 10 мс подтверждается (есть осциллограмма снятая в лабораторных условиях для 3 сигналов - максимум 4 мс). Да к тому же меня ТС пока и не интересуют.
А вот по поводу передачи аналоговых сигналов есть большое сомнение. Суть в том, что установлен источник, формирует действующее значение, передаёт его по сети Ethernet, а приёмник его воспринимает и отравляет на решающий орган (РО), который срабатывает и выдаёт команду. Так вот весь этот цикл должен укладываться в определённые временные рамки и, по моему, не долее чем это назначено для МП РЗА - 20 мс если применяется протокол Goose/SV. Проблема усугубляется ещё и тем, что таких сигналов одновременно от этого источника 9...10 штук! Вот хотелось бы увидеть осциллограмму с исходными и принятыми аналоговыми сигналами, что бы оценить задержки.
Задал аналогичный вопрос в фирму производителей этих датчиков, пока что-то мнутся, но хотелось бы иметь информацию по проблеме от разных источников.

23

Re: Быстродействие передачи GOOSE

Странно это. SV это про отсчеты мгновенных значений, а не про действующие. Видимо надо таки разбираться с производителем.

Сайт: dev.ekra.ru | Почта: dev@ekra.ru | Тел.: 8 (8352) 220-130 (доб. 1057, 1099, 1267) | Часы работы: 08:00 - 17:00 по Москве

24

Re: Быстродействие передачи GOOSE

ПАУтина писал(а):
2021-06-10 01:35:08

установлен источник, формирует действующее значение, передаёт его по сети Ethernet,

Извините, я думал что по сети , например от цифровых ТТ и ТН , передаются именно аналоговые сигналы. Информация по величине с определенной нормативной дискретностью. И эту информацию каждое устройство в своих алгоритмах использует как требуется: действующие значения, дифференцирование ,интегрирование, интерполяция функции на участках. Просьба уточнить, про какой источник действующих значений по сети Ethernet речь? Может я что то неправильно понимаю.

25

Re: Быстродействие передачи GOOSE

EvgenL писал(а):
2021-06-10 05:06:33

Просьба уточнить, про какой источник действующих значений по сети Ethernet речь? Может я что то неправильно понимаю.

да ведь действительно, какая-то ерунда  получается, есть датчики ЕНИП-2, регламентируется, что:   
"- обмен данными с внешними системами по протоколам Modbus RTU, Modbus TCP, ГОСТ Р МЭК 60870-5-104-2004, ГОСТ Р МЭК 60870-5-101-2006, SNTP, SNMP, МЭК 61850-8.1 (для передачи измеренных и вычисленных параметров МК обновляет регистры этих параметров каждые 20 мс)."

Из заявленного Энергосервисом всё понятно!
Да, мы применяли и применяем ГОСТ Р МЭК 60870-5-104-2004 и всё нормально, только время доставки не гарантировано, однако всё работает -  связка ТМ-ПА, а теперь появился МЭК 61850-8.1 - goose/sv как более надёжный и быстрый, ан нет, выходит и все предыдущие перестали тоже передавать аналоговые сигналы!!! а передают только какие-то дискреты,
просил пришлите осциллограмму в протоколах 60870-5-104 и 61850-8.1, а на присланной осциллограмме только дискреты.

Например, УПАЭ - АПНУ с ТМ работает по протоколу ГОСТ Р МЭК 60870-5-104-2004: собирает значения перетоков по сечениям/линиям, но т.к. доставка медленная, то можно выполнить только функцию КПР, на протоколе же МЭК 61850-8.1 время доставки регламентировано, значит можно построить решающие органы или точнее автоматики.
Или они действительно в протоколе МЭК 61850-8.1 могут передавать только и только дискреты, так называемые, ТС.
Вот этот вопрос меня и мучает...

Присоединяйтесь!!! Мы в социальных сетях и на Ютуб.

26 (2021-06-10 14:08:01 отредактировано dev_ekra_ru)

Re: Быстродействие передачи GOOSE

ПАУтина писал(а):
2021-06-10 13:35:39

да ведь действительно, какая-то ерунда  получается...

Судя по тому что вы пишите, ЕНИП-2 передает измерения и вычисленные параметры (в том числе и действующее значение) по 61850-8.1. Это законно. В 8-1 помимо Goose входит и MMS. Вот по MMS они это и отдают. Но надо понимать, что MMS это вовсе не протокол шины процесса (как Goose/Sv), а протокол общения с AСУ (или иным верхним уровнем). С концептуальной точки зрения это то же Modbus-TCP или  60870-5-104 или любой другой протокол общения устройств с верхним уровнем, коих тьма. Поэтому тут все ровно так же, как было у вас с 60870-5-104, понятия гарантированного времени доставки по сути нет.

Т.е. у вас было 15 разных стандартов для получения информации с устройств, но ОНИ (создатели 61850) придумали новый, самый лучший, который заменит все что было. Теперь у вас 16 разных стандартов.

Сайт: dev.ekra.ru | Почта: dev@ekra.ru | Тел.: 8 (8352) 220-130 (доб. 1057, 1099, 1267) | Часы работы: 08:00 - 17:00 по Москве

27 (2021-06-10 13:56:54 отредактировано n00buK)

Re: Быстродействие передачи GOOSE

ПАУтина писал(а):
2021-06-10 13:35:39

просил пришлите осциллограмму в протоколах 60870-5-104 и 61850-8.1, а на присланной осциллограмме только дискреты.

Давайте разбираться.
Раздел 8.1 стандарта определяет 2 абстрактных протокола: MMS и Goose.
MMS предназначен в основном для передачи данных между ИЭУ и верхним уровнем. Для передачи аварийных сигналов и команд он неприменим, т.к. гарантированное время передачи достаточно большое (корпоративный профиль ФСК определяет максимальное время передачи ОТ 500 мс, https://www.fsk-ees.ru/upload/docs/STO_ … 9-2020.pdf).
Goose протокол предназначен как раз для передачи аварийных сигналов. Преимущественно дискретных (в теории можно засунуть и аналоговые, но это нецелесообразно по всем параметрам). Этот протокол гарантирует надежную доставку аварийных сигналов (с максимальным временем передачи 3 либо 10 мс в зависимости от типа) ценой нагрузки на сеть (в начальный момент запуска одно goose сообщение создает траффика порядка на 5-6 МБит).
Касательно аналоговых сигналов: они могут передаваться либо по MMS (раздел 8.1), либо по SV (профиль 9.2LE). В первом случае данные передаются с высокой задержкой, во втором - только мгновенные значения и быстро, но с огромной нагрузкой на сеть.

28

Re: Быстродействие передачи GOOSE

n00buK писал(а):
2021-06-10 13:53:23

(в начальный момент запуска одно goose сообщение создает траффика порядка на 5-6 МБит).

Добрый вечер! А откуда такие сведения по загрузке, на мой взгляд это слишком много? Кстати, GOOSE сообщение это вовсе не дискретная информация может быть, а объект данных (содержащий в первую очередь обязательные атрибуты), так же стоит заметить, что и сама полезная информация может представлять собой число (Н-р, положение выключателя). Автор вопроса упомянул ЭНИП-2, а он на сколько я знаю умеет выдавать синхронизированные векторные измерения в определенных модификациях, и частота передачи (20 мс) это как раз к этому и имеет судя по всему отношение.

29 (2021-06-10 18:45:19 отредактировано n00buK)

Re: Быстродействие передачи GOOSE

Дмитрий1995 писал(а):
2021-06-10 16:45:12

А откуда такие сведения по загрузке, на мой взгляд это слишком много

Зависит от объема пакета.  В среднем 1 МБит, 5 для больших пакетов.

Дмитрий1995 писал(а):
2021-06-10 16:45:12

Кстати, GOOSE сообщение это вовсе не дискретная информация может быть,

Если вы внимательно прочитаете мое сообщение, то увидете, что я говорил о передачи дискретных сигналов, а не дискретной информации.

Дмитрий1995 писал(а):
2021-06-10 16:45:12

что и сама полезная информация может представлять собой число (Н-р, положение выключателя)

Если вы говорите о двухпозционном положении (on-off-intermidate-bad), то это как бы тоже дискретный сигнал. Даже положение РПН - тоже дискретный сигнал.

Дмитрий1995 писал(а):
2021-06-10 16:45:12

Автор вопроса упомянул ЭНИП-2, а он на сколько я знаю умеет выдавать синхронизированные векторные измерения в определенных модификациях, и частота передачи (20 мс) это как раз к этому и имеет судя по всему отношение.

Имеет отношение к чему? К Goose? Серьезно? И причем здесь синхронизированные измерения?
И да, вспомнил. Разве синхронизированные измерения от УСВИ не передаются по протоколу С37.118?

30

Re: Быстродействие передачи GOOSE

Конечно не имеет никакого отношения это к GOOSE. Это было больше адресовано автору вопроса, и сказано к тому, что возможно в его случае речь вообще не идет о 61850, а относится к СВИ. На счет дискретного сигнала да согласен. И все же по загрузке сети откуда у Вас такая информация, из источников или на практике наблюдали?

31 (2021-06-11 13:14:10 отредактировано n00buK)

Re: Быстродействие передачи GOOSE

Дмитрий1995 писал(а):
2021-06-11 08:02:11

И все же по загрузке сети откуда у Вас такая информация, из источников или на практике наблюдали?

И из источников: первая ссылка в гугле сhttps://www.researchgate.net/publicatio … 8/download

GOOSE traffic impacts more the station bus. GOOSE transmits messages cyclically and retransmits spontaneous messages, usually two times to overcome possible frame losses. This results in increase in traffic which becomes more than what is actually required. Since links have a very low loss rate, the recovery mechanism of GOOSE actually increases the probability of losing frames at switches due to congestion. A short GOOSE message handling just one digital status information in the dataset has an approximate size of 124 bytes. The actual size depends on various configured parameters in GOOSE control block such as GoID, name of dataset and reference object of GOOSE control block. Typical size of GOOSE message is between 92 bytes to 250 bytes. One GOOSE application in an IED generates about 1 Kbit/s in steady state and 1 Mbit/s during bursts

.
Хотя соглашусь, что 5 МБит много. До 1 МБит\с при больших пакетах и минимальных настройках задержки.

32

Re: Быстродействие передачи GOOSE

n00buK писал(а):
2021-06-10 13:53:23

Касательно аналоговых сигналов: они могут передаваться либо по MMS (раздел 8.1), либо по SV (профиль 9.2LE). В первом случае данные передаются с высокой задержкой, во втором - только мгновенные значения и быстро, но с огромной нагрузкой на сеть.

Ага!!! Значит всё же могут!!!
Ну тогда, Христа ради, если есть, ёлы-палы, пришлите, пожалуйста!

То, что ЕНИП-2 передаёт по 104 уже есть и сама скорость доставки  отличная - 3 сигнала менее 10 мс, там проблема в другом во времени формирования вычислении самих действующих значений - порядка 50...60 мс. Поэтому, как бы в принципе не понимаю  на какой корнеплод на букву Х, нужен тогда протокол goose/sv как бы быстрее показывать какие-то промежуточные значения: если сигнал постоянно меняется, то выходит как только он не успел показать предыдущее, так тут же не успевает показать текущее...
Суть вопроса, действительно посмотреть на пакет из 30...40 сигналов, они как относительно друг-друга синхронны?
В чем прикол. Пусть возникает трёхфазное КЗ и если все фазы напряжения и фазы тока синхронны, то симметричных составляющих не появится, а если они разсихронизорованы, то на достаточно долгое время (скажем долее времени срабатывания ИО) могут возникнуть большие значения симметричные составляющие, т.е. как бы наоборот не симметричное КЗ, или наоборот - ОКЗ или ДКЗ а будет как ТКЗ.

По поводу "забитого" трафика. решение проблемы как бы "в лоб":
взял первую попавшуюся осциллограмму ёмкостью 3 955 472 б (это файл *.sg, комтрейд (1991года) *.dat  итого меньше 1 495 957 б длительностью 17 с и пересчитал число сигналов:
20 - мгновенных (32 разряда, Тд = 0,000125)
28 - действующих (32 разряда, Тд = 0,008)
и дискреты не стал считать, но там их больше 80 (Тд = 0,008 с)
посчитайте сами,  не забыть умножить на 8 + служебка (CRC и пр.) и разделить на 17.

33

Re: Быстродействие передачи GOOSE

Не надо путать работу в «реальном» времени (goose/sv) с общением с верхним уровнем в отложенном времени (104, MMS....)

Очень грубо на пальцах, sv, передающий информацию об аналоговых измерениях, это такой удаленный АЦП и информация, приходящая по нему ровно та же, что приходила бы с вашего локального АЦП, отсчеты мгновенных значений. И используете вы их точно также как использовали бы данные со своего АЦП. Как и в случае локального АЦП вы точно знаете какому тику АЦП какой отсчет соответствует (все это есть в принимаемых пакетах). Даже если  информация приходит с нескольких измерительных источников, в разных sv пакетах, точно известно что чему соответствует во времени. Разумеется с астрономической точки зрения устройство будет в своих решениях немного запаздывать по отношению к классическому, локальному АЦП, ведь ему надо получить весь необходимый срез отсчетов одного всеобщего тика, чтобы выполнить цикл обработки, но в стандарте установлены строгие требования к времени доставки и некоторым другим параметрам (что напрямую влияет на архитектуру сети) вписываясь в которые, такая распределённая система может функционировать корректно. Естественно все устройства должны быть точно синхронизированы между собой по PTP или чему-то сопоставимого уровня точности. Гуси тоже снабжены информацией, по которой можно точно сказать в какой момент произошло событие и даже приняв его с задержкой, зная ее можно принять некое осознанное решение по своему поведению. Это работа в темпе процесса, поэтому goose/sv часто называют шиной процесса.

Можно провести параллель с сотовой связью. Goose/sv это разговор с собеседником в реальном времени, а MMS, 104 и прочие, это СМСки, которые могут прийти, а могут не прийти, или задержаться га неопределенное время. Поэтому и применения у них совершенно разные.

Сайт: dev.ekra.ru | Почта: dev@ekra.ru | Тел.: 8 (8352) 220-130 (доб. 1057, 1099, 1267) | Часы работы: 08:00 - 17:00 по Москве

34

Re: Быстродействие передачи GOOSE

Важное дополнение. 104 это протокол общения устройств с верхним уровнем АСУ. А SV/GOOSE это уже уровень полевой. И задачи у них принципиально разные. Как было сказано выше, 104 протокол допускает передавать информацию на ДП с задержкой времени, ибо сигнализация срабатывания защит пришедшая диспетчеру не через 0,1 секунду, а через 3-4 кардинально ни на что не повлияет. А вот SV поток в цепи ДЗШ с такой задержкой уже вызывает серьезные проблемы.

Только спалив 3 мультиметра начинаешь понимать, что читать схемы все же нужно.

35 (2021-06-16 02:24:33 отредактировано ПАУтина)

Re: Быстродействие передачи GOOSE

dev_ekra_ru писал(а):
2021-06-11 20:33:07

Как и в случае локального АЦП вы точно знаете какому тику АЦП какой отсчет соответствует (все это есть в принимаемых пакетах).

Согласен и понятно, что такое такт и что такое тик, но как у Вас не упомянуто, так и структурной схеме ЕНИП-а - устройства выборки и хранения сигналов. До формировании пакета, ЦП выдаёт сигнал на УВХ для фиксации синхронного среза текущих значений аналоговых сигналов, потом они последовательно обрабатываются АЦП и запоминаются в регистрах, после обработки всех, формируется пакет для передачи в сеть, в который вставляется фиксированная метка времени, но перед отправкой ЦП выдаёт новый импульс на УВХ. Наверно как-то так, может я и на сочинял, но если нет, то тогда не понятно зачем вообще ставить метку времени. Получается при такой процедуре АЦП должен иметь большое быстродействие, т.к. цикл обработки всех сигналов должен помещаться во требуемое время дискретизации одного сигнала, например если требуется для ДЗ 3-х обмоточного Тр 64 отсчёта в период, то получим тик 20/64 > 0,3 мс. а для одного тока (20/64)/9 < 0,035 с. Если не заворачиваться с УВХ, то АЦП может быть тихоходным.

Добавлено: 2021-06-16 11:18:33

mrsalikov писал(а):
2021-06-15 14:47:31

Важное дополнение. 104 это протокол общения устройств с верхним уровнем АСУ. А SV/GOOSE это уже уровень полевой. И задачи у них принципиально разные. Как было сказано выше, 104 протокол допускает передавать информацию на ДП с задержкой времени, ибо сигнализация срабатывания защит пришедшая диспетчеру не через 0,1 секунду, а через 3-4 кардинально ни на что не повлияет. А вот SV поток в цепи ДЗШ с такой задержкой уже вызывает серьезные проблемы.

Да понимаете, то о чём Вы говорите правильно (тоже на много по разбирался), но дело в том, что не понятно с какого перепугу производитель ЕНИП заявляет, что используется протокол IEC 61850?! Для дискретных сигналов у них действительно goose. А вот  неторопливое или тихоходное формирование и, как следствие, передача действующих значений аналоговых сигналов ну ни как не может относится к упомянутому стандарту. Такое впечатление, что всё было выполнено для протокола 104 для которого можно и не синхронизировать сигналы и передавать действующие значения, а под влиянием моды они как бы выполнили современные требования времени. Вот такие пироги.


Всем спасибо!
и n00buK отдельно тоже!
но если что шлите (осциллограммы)!!!

36 (2021-06-16 17:58:14 отредактировано n00buK)

Re: Быстродействие передачи GOOSE

ПАУтина писал(а):
2021-06-16 02:18:33

До формировании пакета, ЦП выдаёт сигнал на УВХ для фиксации синхронного среза текущих значений аналоговых сигналов, потом они последовательно обрабатываются АЦП и запоминаются в регистрах, после обработки всех, формируется пакет для передачи в сеть, в который вставляется фиксированная метка времени, но перед отправкой ЦП выдаёт новый импульс на УВХ. Наверно как-то так, может я и на сочинял, но если нет,

Я это понимаю примерно также. Если глянуть в профиль ФСК (я приводил его выше), то для SV потоков для РЗ (для ККЭ и СМПР другие значения) сейчас приняты следующие характеристики:
1) Максимальное время доставки кадра- не более 3 мс.
2) Частота выборок на период - 96
3) Число сигналов в кадре - 1 или 3.
4) Число выборок в одном кадре (пакете) - 2.
5) Точность синхронизации источника SV (преобразователя аналоговых сигналов) и приемника - не хуже +-1 мкс.
Таким образом, кадры будут формироваться каждые 20мс/(96/2), т.е. примерно каждые 0,42 мс. И через не более 3 мс они достигнут получателя. С точки зрения идеологов 61850 этого достаточно.
Касательно РАС и осциллограмм - насколько мне известно на данных момент общего подхода пока нет. Варианты можно почитать тут: http://digitalsubstation.com/blog/2016/ … dstantsij/

37

Re: Быстродействие передачи GOOSE

n00buK писал(а):
2021-06-16 15:46:58

5) Точность синхронизации источника SV (преобразователя аналоговых сигналов) и приемника - не хуже +-1 мкс.

Укажите пожалуйста в каком стандарте ФСК сказано, что точность синхронизации ПРИЕМНИКА SV не хуже +-1мкс.

38

Re: Быстродействие передачи GOOSE

Илья Иванов писал(а):
2021-06-16 17:17:40

Укажите пожалуйста в каком стандарте ФСК сказано, что точность синхронизации ПРИЕМНИКА SV не хуже +-1мкс.

Поторопился, в профиле идет речь только о синхронизации ПАС. Сообщение поправил, спасибо.

39 (2021-06-17 01:58:21 отредактировано ПАУтина)

Re: Быстродействие передачи GOOSE

n00buK писал(а):
2021-06-16 15:46:58

С точки зрения идеологов 61850 этого достаточно.

по поводу идеологии.
понятно, что если гарантированно обеспечивается время формирования (подготовки) и доставки сигнала или пакета синхронизированных сигналов, т.е. конечно не совсем уж жёсткий режим реального времени,  а просто реального времени, то достаточным будет в пакте иметь "упрощенную" меточку времени, а вот если нет ни какой гарантии во времени доставки сигнала, то наверно метка должна быть достаточно сложной и длинной может даже с указанием века  ICQ/ag:D ...