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

да ведь действительно, какая-то ерунда  получается, есть датчики ЕНИП-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 могут передавать только и только дискреты, так называемые, ТС.
Вот этот вопрос меня и мучает...

Давайте разбираться.
Раздел 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). В первом случае данные передаются с высокой задержкой, во втором - только мгновенные значения и быстро, но с огромной нагрузкой на сеть.

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

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

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

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

И из источников: первая ссылка в гугле с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 МБит\с при больших пакетах и минимальных настройках задержки.

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

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

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

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

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

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

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

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