Какие функции сетевого оборудования нужны для цифровой подстанции?

Цифровая подстанция (ЦПС) — это сложная система, состоящая из множества элементов, которые связаны в единую локальную вычислительную сеть (ЛВС). Через ЛВС обмениваются данными и терминалы релейной защиты, и передаются все измерения тока и напряжения, а также все данные на верхний уровень. И за счёт того, что все участники сети очень активно обмениваются информацией, ЛВС оказывается высоконагруженной. Если посмотреть на текущие спецификации проектов АСУ ТП электроэнергетических объектов, то мы увидим там большое количество коммутаторов, причём достаточно сложных, которые имеют много различных IT-функций, особенно важными из которых являются:

• приоритетная передача;
• GOOSE-сообщений;
• поддержка протокола PRP;
• Multicast и VLAN.

Но зачем все эти функции? И нужны ли они для ЦПС? Именно эти вопросы освещены в данной статье.

Поддержка приоритетной передачи GOOSE-сообщений

В первую очередь коммутаторам необходимо поддерживать приоритетную передачу GOOSE-сообщений. Для понимания необходимости данной функции нужно рассмотреть принцип работы GOOSE-сообщений. Они задумывались как замена горизонтальной связи между терминалами релейной защиты, которая раньше реализовывалась чаще всего на основе дискретных сигналов. Из этого факта вытекают следующие требования для передачи GOOSE-сообщений:

• малый объём информации;
• высокая скорость передачи информации;
• высокая вероятность доставки сообщения;
• возможность передачи сообщений сразу нескольким адресатам;
• необходимость контроля целостности канала передачи данных.

Чтобы обеспечить требование по скорости, GOOSE-сообщения передаются на канальном уровне. GOOSE-сообщения передаются multicast-трафиком, что даёт возможность отправки сообщений сразу нескольким адресатам, и при этом каждый адресат сам решает, будет он получать это GOOSE-сообщение или нет (слушать ему данную multicast-группу или нет). Чтобы обеспечить высокую вероятность доставки сообщения и контроль целостности канала, используется модель передачи данных, отличная от привычной модели для TCP/IP: GOOSE-сообщение, в случае, когда все параметры неизменны, передаётся с постоянным временем передачи — T0; а когда какой-либо из параметров меняется, то GOOSE-сообщение незамедлительно передаётся, вне зависимости от времени T0 (рисунок 1). Затем следующее сообщение передаётся через короткий промежуток времени, следующее — через чуть больший промежуток, и так продолжается до увеличения времени T0. Таким образом, в случае какого-то происшествия генерируется «пачка» сообщений.

Когда происходит какое-то глобальное событие, то можно наблюдать, как «GOOSE-лавина» (когда генерируется большое количество GOOSE-сообщений с разных терминалов, а другие терминалы подхватывают эти события и начинают генерировать один за другим) даёт большую нагрузку на сеть, и поэтому коммутаторам необходимо обрабатывать GOOSE-сообщения с отдельным приоритетом, чтобы они были переданы в первую очередь. Иначе существует возможность «остановки» передачи данных по сети, когда буферы обмена коммутаторов будут переполнены GOOSE-сообщениями, и никакого другого трафика коммутаторы передавать не смогут. UCAIug в своих программах и методиках испытаний (ПМИ) устанавливает максимально допустимое время передачи GOOSE-сообщения 3 мс для класса производительности P1 согласно МЭК 61850–5. Для обеспечения приоритетной быстрой передачи GOOSE-сообщений коммутатору необходимо понимать QoS-приоритет пакета и его VLAN ID, а также «узнавать» Ethertype GOOSE-пакета.

Поддержка протокола PRP

Во-вторых, коммутаторы должны поддерживать протокол резервирования PRP. На самом деле несколько ошибочно говорить про поддержку PRP на коммутаторе. Коммутатор для этого резервирования никаких особенно сложных функций не выполняет. Ему достаточно просто не отбрасывать пакеты с PRP-трейлером. Что такое PRP-трейлер, и почему его нужно поддерживать?

Протокол PRP подразумевает параллельное резервирование. То есть пакет дублируется и передаётся по двум разным сетям, и конечное устройство получает на вход два пакета, если один из них битый, то устройство использует второй. В терминологии PRP параллельные сети называются сеть А и сеть Б. Соответственно, к дублированным пакетам добавляется дополнительное поле, содержащее информацию о PRP — PRP-трейлер. Если не погружаться глубоко в технологию, то в нём содержатся данные, к какой сети относится пакет —сеть А или сеть Б. Коммутатор без «поддержки» PRP может посчитать, что пакет с PRP-трейлером является битым. Именно поэтому важно использовать проверенные коммутаторы, которые не блокируют пакеты в резервированной сети (рисунок 2).

Поддержка Multicast и VLAN

Также достаточно востребованными являются функции VLAN и Multicast. VLAN позволяет сегментировать сеть, разделяя её на виртуальные подсети, а поддержка Multicast позволяет работать с потоками данных. Под поддержкой Multicast подразумевается поддержка протокола IGMP. Данные функции позволяют управлять потоками данных и ограничивать пути распространения широковещательных пакетов. Наиболее актуально это для управления SV-потоками. Для примера рассмотрим следующую схему, представленную на рисунке 3.

Имеется 4 коммутатора Phoenix Contact FL SWITCH 4824E-4GC — 2891072. Коммутаторы объединены в кольцо. К каждому коммутатору подключено по шесть Merging Unit и по 2 терминала релейной защиты (все устройства подключаются к 100 Мбит/с портам, а кольцо создано на основе 1 Гбит/с портов). Предположим, что с каждого MU передаётся один SV-поток. Тогда, если не использовать VLAN или Multicast, мы можем получить ситуацию, когда через один коммутатор будет передаваться 24 SV-потока. Один SV-поток весит в среднем около 4–5 Мбит/с, т. е. через один коммутатор с пропускной способностью портов 100 Мбит/с может проходить около 20 потоков. Учитывая, что помимо SV-потоков через коммутаторы проходит еще как минимум служебный трафик, то без потери данных может быть передано около 18 потоков. Другими словами, 24 потока коммутатор передать не сможет. Подобная нагрузка в лучшем случае станет причиной потери пакетов, а в худшем — остановки передачи данных в сети.

Здесь-то и возникает необходимость в управлении потоками и ограничении распространения широковещательных пакетов, которыми, по большому счёту, и является multicast-трафик. Управлять ими можно при помощи протокола управления multicast-потоками IGMP. Каждый SV-поток передаётся как multicast-трафик и, соответственно, при помощи IGMP можно ограничить распространение данного трафика только теми узлами, которым эти пакеты необходимы. Или же, потоки можно разделить по разным VLAN-функциям, что даёт возможность определить, куда  потоки могут быть переданы. Обе технологии помогают значительно разгрузить сеть.

Что может предложить Phoenix Contact под данные требования?

Коммутаторы серии FL SWITCH 48XXE с поддержкой стандарта IEC 61850 позволяют реализовывать все вышеописанные функции. В конце 2018 г. были пройдены испытания в АО «НТЦ ФСК ЕЭС», которые подтвердили, что коммутаторы Phoenix Contact имеют необходимый уровень ЭМС, а также выдерживают необходимый для электроэнергетических объектов уровень механических воздействий и обладают всеми необходимыми IT-функциями для создания АСУ ТП на электростанциях и подстанциях. Сейчас коммутаторы Phoenix Contact имеют аттестат соответствия от АО «НТЦ ФСК ЕЭС», который подтверждает, что данное сетевое оборудование может быть использовано в проектах ПАО «Россети» и занесено в реестр оборудования, допущенного к применению на объектах ПАО «Россети» (рисунок 4).

Но, принимая во внимание все современные тренды создания ЛВС ЦПС, описанных выше функций уже недостаточно. Дополнительно к тем требования, которые были обсуждены, в ближайшем будущем для реализации новых проектов на борту коммутаторов потребуются:

• поддержка протокола PTPv2;
• передача данных со скоростью передачи данных 10 Гбит/с;
• работа на третьем уровне модели OSI;
• поддержка HSR.

Поддержка протокола PTPv2

Поддержка протокола синхронизации времени PTP, который позволяет добиться точности синхронизации 1 мкс. Казалось бы, зачем такая точность? Ведь 1 мс, которую обеспечивает NTP, было всегда достаточно! Да, это так, но NTP не подходит для организации шины процесса. К шине процесса подключаются измерительные преобразователи либо MU, с которых передаются значения тока и напряжения в шину, а также подключаются терминалы РЗ, которые используют эти данные для реализации логики защиты. Если использовать для синхронизации NTP, то мы можем получить ложные срабатывания, например, дифференциально-фазной защиты (ДФЗ) линий. Это получится из-за того, что из-за недостаточной точности синхронизации времени на один терминал может прийти одно измерение тока, а на второй — измерение тока за другой промежуток времени, что может дать разницу фаз этих токов большую, чем в уставке, и это вызовет ложное срабатывание терминала релейной защиты. Поэтому для шины процесса и важна высокая точность синхронизации времени. В свою очередь нельзя ставить любые коммутаторы в сеть, где используется синхронизация времени по PTP, т. к. каждый коммутатор, через который проходит пакет синхронизации, должен добавить в этот пакет ту задержку времени, которую он дал при передаче. Коммутатор без поддержки PTP этого сделать не может, что скажется на точности синхронизации времени, и добиться 1 мкс будет невозможно.

Передача данных со скоростью передачи данных 10 Гбит/с

Как было изложено выше, SV-потоки достаточно требовательны к пропускной способности сети, и передача даже 20 потоков через коммутатор, скорость портов которого 100 Мбит/с, является проблемой. На крупном энергетическом объекте таких потоков может быть достаточно много. И если использование технологий VLAN и IGMP и замена 100-мбитных коммутаторов на гигабитные для шкафов присоединения еще может быть решением, то для организации магистралей потребуются большие скорости, нежели 1 Гбит/с. Именно поэтому сейчас становятся актуальными коммутаторы с наличием каналов передачи данных со скоростью 10 Гбит/с.

Работа  на 3 уровне модели OSI

Сложность АСУ ТП продолжает расти и количество систем в рамках одного объекта становится все больше. И очень часто для работы системы автоматизации требуются данные из смежных систем, и использовать кучу маршрутизаторов несколько избыточно. Гораздо удобнее бы было иметь поддержку L3 на коммутаторах.

Поддержка HSR

И последнее, но одно из самых важных — PRP сейчас все чаще заменяется на более надежный и быстрый протокол HSR. Он очень похож на PRP в том, что пакет также дублируется и, если один оказывается битым, то конечное устройство использует второй. Но HSR уже не требует использовать две параллельные сети, а работает внутри одного кольца. Просто одна копия пакета уходит в кольце по часовой стрелке, а другая — против часовой. В случае, если речь идет о unicast-трафике, то копии уничтожаются на конечном устройстве, который принимает трафик, или на RedBox. Если передаёт широковещательный трафик, то обе копии пакетов проходят полное кольцо и уничтожаются на устройстве, с которого выполнялась передача данных.

Есть ли оборудование у Phoenix Contact под эти требования?

Поддержка PTPv2, каналы со скоростями передачи данных 100 Мбит/с, 1 Гбит/с, 10 Гбит/с, L2/L3 на выбор, HSR — весь этот функционал есть в новой серии коммутаторов для электроэнергетики от Phoenix Contact. Более того, коммутаторы этой серии поддерживают диагностику по MMS и являются модульными! Новая серия коммутаторов от Phoenix Contact позволяет удовлетворить все текущие требования отрасли к сетевому оборудованию и оставить серьезный задел на будущее.

ЗАКЛЮЧЕНИЕ

1. К коммутаторам, которые используются для создания ЛВС ЦПС, предъявляются повышенные требования и необходимо, чтобы данные коммутаторы поддерживали специфичные IT-функции. Сформулированные требования являются необходимыми и, более того, объём требований возрастает для более сложных коммутаторов, применяемых в полнофункциональной ЦПС.

2. Phoenix Contact предлагает широкий выбор сетевого оборудования, которое может быть использовано при реальном проектировании, и обеспечит полностью весь необходимый функционал для ЦПС при эксплуатации.

Подробнее: https://dam-mdc.phoenixcontact.com/asset/156443151564/a9bc285c15cb20b710b898c4730a74ea/FunkciiSetevogoOborudovaniya.pdf