Блог компании phoenix contact

Несмотря на повсеместное распространение сетей Ethernet, технологии связи на основе DSL не теряют своей актуальности и по сей день. До сих пор DSL можно встретить в сетях последней мили для подключения абонентского оборудования к сетям Интернет-провайдера, а в последнее время технология все чаще используется при построении локальных сетей, например, в промышленных приложениях, где DSL выступает в качестве дополнения к Ethernet или к полевым сетям на основе RS-232/422/485. Подобные промышленные решения активно применяются в развитых европейских и азиатских странах.

DSL представляет из себя семейство стандартов, которые изначально задумывались для передачи цифровых данных по телефонным линиям связи. Исторически это стало первой технологией широкополосного доступа в Интернет, придя на смену DIAL UP и ISDN. Большое разнообразие существующих в настоящий момент стандартов DSL связано с тем, что многие компании, начиная с 80-х годов, старались разработать и продвинуть на рынок собственную технологию.

Все эти разработки можно разделить на две большие категории асимметричные (ADSL) и симметричные (SDSL) технологии. Под асимметричными понимаются те, в которых скорость входящего соединения отличается от скорости исходящего трафика. Под симметричными понимается, что скорости на прием и передачу равны.

Наиболее известными и распространенными асимметричными стандартами являются, собственно, ADSL (в последней редакции ADSL2+) и VDSL (VDSL2), симметричными HDSL (устаревший профиль) и SHDSL. Друг от друга все они отличаются тем, что работают на разных частотах, используют разные способы кодирования и модуляции на физической линии связи. Также отличаются способы коррекции ошибок, благодаря чему обеспечивается разный уровень помехоустойчивости. Как итог, каждая технология имеет свои пределы в скорости и дистанции передачи данных, в том числе в зависимости от типа и качества проводника.


Предельные параметры различных стандартов DSL

В любой DSL-технологии скорость передачи данных падает с увеличением длины проводника. На предельных дистанциях возможно получить скорость в несколько сот килобит, но при передаче данных на 200-300 м доступна максимально возможная скорость.

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

Для SHDSL подходит любая пара изолированных друг от друга проводников медных, алюминиевых, стальных и пр. В качестве среды передачи может выступать старая электропроводка, старые телефонные линии, колючая проволока заборов и пр.


Зависимость скорости передачи данных SHDSL от дистанции и типа проводника

Из графика зависимости скорости передачи данных от дистанции и типа проводника, приведенного для SHDSL, можно увидеть, что проводники с большим сечением позволяют передавать информацию на большую дистанцию. Благодаря технологии возможно организовать связь на дистанцию до 20 км при максимально возможной скорости 15.3 Мб/с для 2-проводного кабеля или 30 Мб для 4-проводного. В реальных приложениях скорость передачи может быть выставлена вручную, что необходимо в условиях сильных электромагнитных помех или плохого качества линии. В этом случае для увеличения дистанции передачи необходимо снизить скорость работы SHDSL-устройств. Для точного расчета скорости в зависимости от дистанции и типа проводника можно использовать бесплатные программные средства, такие как SHDSL-калькулятор от Phoenix Contact.

За счет чего SHDSL обладает высокой помехоустойчивостью?

Принцип работы приемопередатчика SHDSL можно представить в виде блок-диаграммы, в которой выделяют специфическую и независимую (инвариантную) с точки зрения приложения часть. Независимая часть состоит из функциональных блоков PMD (Physical Medium Dependent) и PMS-TC (Physical Medium-Specific TC Layer), в то время как специфическая часть включает уровень TPS-TC (Transmission Protocol-Specific TC Layer) и интерфейсы пользовательских данных.

Физическая линия связи между приемопередатчиками (STU) может существовать в виде однопарного или нескольких однопарных кабелей. В случае нескольких пар кабелей STU содержит несколько независимых блоков PMD, связанных с единственным PMS-TC.


Функциональная модель SHDSL-приемопередатчика (STU)

Модуль TPS-TC зависит от приложения, в котором используется устройство (Ethernet, RS-232/422/485 и пр.). В его задачу входит преобразование пользовательских данных в формат SHDSL, выполняется мультиплексирование/демультиплексирование и корректировка по времени нескольких каналов пользовательских данных.

На уровне PMS-TC производится формирование кадров SHDSL и их синхронизация, а также скремблирование и дескремблирование.

Модуль PMD выполняет функции кодирования/декодирования информации, модуляции/демодуляции, эхоподавления, согласования параметров на линии связи и установления соединения между приемопередатчиками. Именно на уровне PMD выполняются основные операции, обеспечивающая высокую помехоустойчивость SHDSL, включая TCPAM кодирование (Треллис кодирование с аналого-импульсной модуляцией), механизм совместного кодирования и модуляции, при котором улучшается спектральная эффективность сигнала по сравнению с раздельным способом. Принцип работы модуля PMD также можно представить в виде функциональной диаграммы.


Блок-диаграмма модуля PMD

В основе TC-PAM лежит использование сверточного кодера, формирующего избыточную последовательность битов на стороне SHDSL-передатчика. На каждом такте работы каждому биту, поступающему на вход кодера, ставится в соответствие двойной бит (дибит) на выходе. Таким образом, ценой сравнительно небольшой избыточности повышается помехоустойчивость передачи. Использование Треллис-модуляции позволяет уменьшить используемую полосу частоту передачи данных и упростить аппаратную часть при неизменном отношении сигнал/шум.


Принцип работы Треллис-кодера (TC-PAM 16)

Двойной бит формируется в результате логической операции сложения по модулю 2 (исключающее или) на основе входного бита x₁(t_n) и битов x₁(t_n-1), x₁(t_n-2) и т.д. (всего их может быть до 20), которые поступали на вход кодера до этого и остались храниться в регистрах памяти. На следующем такте работы кодера t_n+1 произойдет смещение битов в ячейках памяти для выполнения логической операции: бит x₁(t_n) переместится в память, сдвинув всю хранящуюся там последовательность битов.


Таблицы истинности операции сложения по модулю 2

Для наглядности удобно использовать диаграмму состояния сверточного кодера, по которой можно увидеть, в каком состоянии находится кодер в моменты времени t_n, t_n+1 и т.д. в зависимости от входных данных. Под состоянием кодера в этом случае подразумевают пару значений входного бита x₁(t_n) и бита в первой ячейки памяти x₁(t_n-1). Для построения диаграммы можно использовать граф, в вершинах которого находятся возможные состояния кодера, а переходы из одного состояния в другое обозначены соответствующими входными битами x₁(t_n) и выходными дибитами $inline$y y (t )$inline$.


Диаграмма состояний и граф переходов сверточного кодера передатчика

В передатчике на основе полученных четырех битов (двух выходных битов кодера и двух битов данных) формируется символ, каждому из которых соответствует своя амплитуда модулирующего сигнала аналого-импульсного модулятора.


Состояние 16-разрядного АИМ в зависимости от значения четырехбитового символа

На стороне приемника сигнала происходит обратный процесс демодуляция и выделение из избыточного кода (двойных битов y₀y₁(t_n)) нужной последовательности входных битов кодера x₁(t_n). Эту операцию выполняет декодер Витерби.

Алгоритм декодера основан на расчете метрики ошибок для всех возможных предполагаемых состояний кодера. Под метрикой ошибок понимают разницу между принимаемыми битами и предполагаемыми битами для каждого возможного пути. Если ошибок на приеме нет, то метрика ошибок истинного пути будет 0, потому что нет расхождения по битам. Для ложных путей метрика будет отличаться от нуля, постоянно нарастать и через какое-то время декодер перестанет рассчитывать ошибочный путь, оставив только истинный.


Диаграмма состояний кодера, вычисляемая декодером Витерби приемника

Но как этот алгоритм обеспечивает помехоустойчивость? Если предположить, что приемник принял данные с ошибкой, декодер продолжит рассчитывать два пути с метрикой ошибок 1. Пути с метрикой 0 уже не будет существовать. Но вывод о том, какой путь истинный, алгоритм сделает позже на основе следующих принимаемых двойных битов.

При появлении второй ошибки, будет несколько путей с метрикой 2, но правильный путь выявится позже на основе метода наибольшего правдоподобия (то есть минимальной метрики).


Диаграмма состояний кодера, вычисляемая декодером Витерби, при приеме данных с ошибками

В описанном выше случае для примера был рассмотрен алгоритм 16-разрядной системы (TC-PAM16), обеспечивающей передачу в одном символе трех бит полезной информации и дополнительного бита для защиты от ошибок. В TC-PAM16 достижима скорость передачи данных от 192 до 3840 кбит/с. При увеличении разрядности до 128 (современные системы работают с TC-PAM128) в каждом символе передается шесть бит полезной информации, а максимально достижимая скорость составляет от 5696 кбит/с до 15,3 Мб/с.

Использование аналого-импульсной модуляции (PAM) роднит SHDSL с рядом популярных стандартов Ethernet, таких как гигабитный 1000BASE-T (PAM-5), 10-гигабитный 10GBASE-T (PAM-16) или перспективный на 2020 год промышленный однопарный Ethernet 10BASE-T1L (PAM-3).

SHDSL в сетях Ethernet

Различают управляемые и неуправляемые SHDSL-модемы, но в подобной классификации мало общего с привычным разделением на управляемые и неуправляемые устройства, которое существует, например, для Ethernet-коммутаторов. Разница заключается в средствах конфигурирования и мониторинга. Управляемые модемы настраиваются через веб-интерфейс и могут диагностироваться по SNMP, а неуправляемые при помощи дополнительного ПО через консольный порт (для Phoenix Contact это бесплатная программа PSI-CONF и mini-USB интерфейс). В отличии от коммутаторов неуправляемые модемы могут работать в сети с кольцевой топологией.

В остальном управляемые и неуправляемые модемы являются абсолютно идентичными, включая функционал и возможность работать по принципу Plug&Play, то есть без всякого предварительного конфигурирования.

Дополнительно на модемы могут возлагаться функции защиты от импульсных перенапряжений c возможностью ее диагностики. Сети SHDSL могут образовывать очень протяженные сегменты, и проводники могут проходить в местах, где возможно образование импульсных перенапряжений (наведенной разности потенциалов, вызванной грозовыми разрядами либо короткими замыканиями в близлежащих кабельных линиях). Наведенное напряжение может вызвать протекание разрядных токов величиной в килоамперы. Поэтому для защиты оборудования от подобных явлений в модемы встраиваются УЗИП в виде съемной платы, которая в случае необходимости может быть заменена. Именно к клеммнику этой платы подключается линия SHDSL.

Топологии

С помощью SHDSL в Ethernet возможно строить сети с любой топологией: точка-точка, линия, звезда и кольцо. При этом, в зависимости от типа модема для подключения можно использовать как 2-проводные, так и 4-проводные линии связи.


Топологии сети Ethernet на основе SHDSL

Также можно строить распределенные системы с комбинированной топологией. Каждый сегмент SHDSL-сети может насчитывать до 50 модемов и, учитывая физические возможности технологии (расстояние между модемами в 20 км), длина сегмента может достигать 1000 км.

Если в голове каждого такого сегмента установить управляемый модем, то целостность сегмента можно диагностировать по SNMP. Помимо этого, управляемые и неуправляемые модемы поддерживают технологию VLAN, то есть позволяют разбивать сеть на логические подсети. Также устройства способны работать с протоколами передачи данных, применяемыми в современных системах автоматизации (Profinet, Ethernet/IP, Modbus TCP и пр.).


Резервирование каналов связи с помощью SHDSL

SHDSL используют для создания резервных каналов связи в сети Ethernet, чаще всего оптического.

SHDSL и последовательный интерфейс

SHDSL-модемы с последовательным интерфейсом позволяют преодолеть ограничения по дистанции, топологии и качеству проводника, которые существуют для традиционных проводных систем на основе асинхронных приемопередатчиков (UART): RS-232 15 м, RS-422 и RS-485 1200 м.

Существуют модемы с последовательными интерфейсами (RS-232/422/485) как для универсальных приложений, так и для специализированных (например, для Profibus). Все подобные устройства относятся к категории неуправляемых, поэтому настраиваются и диагностируются при помощи специального ПО.

Топологии

В сетях с последовательным интерфейсом при помощи SHDSL возможно строить сети с топологией точка-точка, линия и звезда. В рамках линейной топологии возможно объединить в одну сеть до 255 узлов (для Profibus 30).

В системах, построенных с использованием только устройств на интерфейсе RS-485, отсутствуют какие-либо ограничения по применяемому протоколу передачи данных, но топологии типа линия и звезда являются нетипичными для RS-232 и RS-422, поэтому работа конечных устройств в SHDSL-сети с подобными топологиями возможна только в полудуплексном режиме. Одновременно в системах с RS-232 и RS-422 на уровне протокола должна обеспечиваться адресация приборов, что нехарактерно для интерфейсов, чаще всего применяемых в сетях точка-точка.

При объединении через SHDSL устройств с разными типами интерфейсов необходимо учитывать факт отсутствия единого механизма для установления соединения (рукопожатия) между устройствами. Однако организовать обмен в этом случае все равно возможно для этого необходимо выполнение следующих условий:

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

Наиболее часто встречающийся для асинхронных интерфейсов протокол Modbus RTU позволяет избежать всех описанных ограничений и строить единую систему с различными типами интерфейсов.


Топологии сети с последовательным интерфейсом на основе SHDSL

При использовании двухпроводного RS-485 на оборудовании Phoenix Contact можно строить более сложные структуры, объединяя модемы через одну шину на DIN-рейке. На этой же шине может быть установлен источник питания (в таком случае питание всех устройств осуществляется через шину) и оптические преобразователи серии PSI-MOS для создания комбинированной сети. Важным условием работы такой системы является одинаковая скорость всех приемопередатчиков.


Дополнительные возможности SHDSL в сети RS-485

Примеры применения

SHDSL-технология активно применяется в городском коммунальном хозяйстве в Германии. Более 50 компаний, обслуживающих городские коммунальные системы, используют старые медные провода, чтоб связать одной сетью распределенные по городу объекты. На SHDSL строятся в первую очередь системы управления и учета в водо-, газо- и энергоснабжении. Среди таких городов Ульм, Магдебург, Ингольштадт, Билефельд, Франкфурт-на-Одере и многие другие.

Самая масштабная система на основе SHDSL была создана в городе Любеке. Система имеет комбинированную структуру на основе оптического Ethernet и SHDSL, объединяет 120 удаленных друг от друга объектов и использует более 50 модемов Phoenix Contact. Вся сеть диагностируется по SNMP. Самый протяженный сегмент от коммуны Калькхорст до аэропорта Любека имеет длину 39 км. Причина, по которой компания-заказчик выбрала SHDSL, заключалась в том, что реализация проекта целиком на оптике была экономический невыгодна с учетом наличия старых медных кабелей.


Передача данных через контактное кольцо

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

Сравнение с другими технологиями

SHDSL vs GSM
Если сравнивать SHDSL с системами передачи данных на основе GSM (3G/4G), то в пользу DSL говорит отсутствие эксплуатационных расходов, связанных с регулярной платой оператору за доступ к мобильной сети. При SHDSL мы не зависим от зоны покрытия, качества и надежности мобильной связи на промышленном объекте, включая устойчивость к электромагнитным помехам. В SHDSL отсутствует необходимость в конфигурировании оборудования, что ускоряет ввод объекта в эксплуатацию. Для беспроводных сетей характерны большие задержки в передаче данных и сложность с передачей данных, использующих мультикастовый трафик (Profinet, Ethernet IP).

В пользу SHDSL говорит информационная безопасность в силу отсутствия необходимости передачи данных через Интернет и необходимости конфигурирования для этого VPN-соединений.

SHDSL vs Wi-Fi
Многое из сказанного для GSM можно отнести и к промышленному Wi-Fi. Против Wi-Fi говорит низкая помехоустойчивость, ограниченная дистанция передачи данных, зависимость от топологии местности, задержки при передаче данных. Самый главный недостаток информационная безопасность сетей Wi-Fi, потому как любой человек имеет доступ к среде передачи данных. При помощи Wi-Fi уже возможно передавать данные Profinet или Ethernet IP, что было бы затруднительно для GSM.

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

Введение

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

Всем, кому интересно разобраться в этой теме, welcome под кат!

Как данные передаются в сети и зачем управлять multicast-потоками?

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


Что такое Цифровая Подстанция и зачем там нужен multicast?

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

• Кто участвует в передаче данных?
• Какие данные передаются в ЛВС?
• Какая типовая архитектура ЛВС?

И уже после этого обсуждать multicast

Что такое Цифровая Подстанция?

Цифровая Подстанция это подстанция, все системы которой имеют очень высокий уровень автоматизации. Все вторичное и первичное оборудование такой подстанции ориентировано на цифровую передачу данных. Обмен данными выстраивается в соответствии с протоколами передачи, описанными в стандарте МЭК 61850.

Соответственно, в цифровом виде здесь передаются все данные:

• Измерения.
• Диагностическая информация.
• Команды управления.

Этот тренд получил очень большое развитие в российской энергетике и сейчас повсеместно внедряется. В 2019 и 2020 году появилось очень много нормативных документов, регулирующих создание Цифровой Подстанции на всех этапах разработки. Например, СТО 34.01-21-004-2019 ПАО Россети определяет следующее определение и критерии ЦПС:

Определение:
Цифровая подстанция автоматизированная подстанция, оснащенная взаимодействующими в режиме единого времени цифровыми информационными и управляющими системами и функционирующая без присутствия постоянного дежурного персонала.

Критерии:

• дистанционная наблюдаемость параметров и режимов работы оборудования и систем, необходимых для нормального функционирования без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
• обеспечение телеуправления оборудованием и системами для эксплуатации ПС без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
• высокий уровень автоматизации управления оборудованием и системами с применением интеллектуальных систем управления режимами работы оборудования и систем;
• дистанционная управляемость всеми технологическими процессами в режиме единого времени;
• цифровой обмен данными между всеми технологическими системами в едином формате;
• интегрированность в систему управления электрической сетью и предприятием, а также обеспечение цифрового взаимодействия с соответствующими инфраструктурными организациями (со смежными объектами);
• функциональная и информационная безопасность при цифровизации технологических процессов;
• непрерывный мониторинг состояния основного технологического оборудования и систем в режиме онлайн с передачей необходимого объема цифровых данных, контролируемых параметров и сигналов.

Кто участвует в передаче данных?

В составе Цифровой Подстанции есть следующие системы:

• Системы релейной защиты. Релейная защита это практически сердце Цифровой Подстанции. Терминалы релейной защиты из систем измерения берут значения тока и напряжения. На основе этих данных терминалы отрабатывают внутреннюю логику защит. Терминалы общаются между собой, чтобы передавать информацию о сработанных защитах, о положениях коммутационных аппаратов и т.д. Также терминалы отправляют информацию о произошедших событиях на сервер АСУ ТП. Итого, можно выделить несколько типов связи:
  Горизонтальная связь общение терминалов между собой.
  Вертикальная связь общение с сервером АСУ ТП.
  Измерения общение с измерительными устройствами.

• Системы коммерческого учета электроэнергии.Системы коммерческого учета общаются только с измерительными устройствами.

• Системы диспетчерского управления.С сервера АСУ ТП и с сервера коммерческого учета данные частично должны отправляться в диспетчерский пункт.

Это очень упрощенный перечень систем, которые обмениваются данными в составе Цифровой Подстанции. Если Вам интересно углубиться в эту тему глубже пишите в комментарии. Расскажем про это отдельно ;-)

Какие данные передаются в ЛВС?

Чтобы объединить описанные системы между собой и организовать горизонтальную и вертикальную связь, а также передачу измерений организуются шины. Пока давайте договоримся, что каждая шина это просто отдельная ЛВС на промышленных Ethernet-коммутаторах.


Структурная схема электроэнергетического объекта в соответствии с МЭК 61850

На структурной схеме изображены шины:

• Мониторинг/Управления.
• Передача сигналов РЗА.
• Передача мгновенных значений напряжений и токов.

Терминалы релейной защиты участвуют и в горизонтальной и в вертикальной связи, а также используют измерения, поэтому они подключаются ко всем шинам.

Через шину Передача сигналов РЗА терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.

Через шину Передача мгновенных значений напряжений и токов реализована передача измерений. К этой шине подключаются устройства измерения трансформаторы тока и напряжения, а также терминалы релейной защиты.

Также к шине Передача мгновенных значений напряжений и токов подключается сервер АСКУЭ, который также забирает к себе измерения для учета.

А шина Мониторинг/Управление служит для вертикальной связи. Т.е. через нее терминалы отправляют на сервер АСУ ТП различные события, а также сервер посылает управляющие команды на терминалы.

С сервера АСУ ТП данные отправляются в диспетчерский пункт.

Какая типовая архитектура ЛВС?

Перейдем от абстрактной и достаточно условной структурной схемы к более приземленным и реальным вещам.

На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.

Архитектура Цифровой Подстанции

На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.

Архитектура разбита на три уровня:

• Уровень станции/подстанции.
• Уровень присоединения.
• Уровень процесса.

Уровень станции/подстанции включает в себя АРМы и сервера.

Уровень присоединения включает в себя все технологическое оборудование.

Уровень процесса включает в себя измерительное оборудование.

Также есть две шины для объединения уровней:

• Шина станции/подстанции.
• Шина процесса.

Шина станции/подстанции объединяет в себе функции шины Мониторинг/Управление и шины Передача сигналов РЗА. А шина процесса выполняет функции шины Передача мгновенных значений напряжения и тока.

Особенности передачи Multicast в Цифровой Подстанции

Какие данные передаются с помощью multicast?
Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры Издатель-Подписчик. Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.

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

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

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

Поэтому данные должны были передаваться:

• Надежно.
• Гарантированно.
• Быстро.

Теперь вместо связи точка-точка используется шина станции/подстанции, т.е. ЛВС. А данные передаются с помощью протокола GOOSE, который описан стандартом МЭК 61850 (в МЭК 61850-8-1, если быть точнее).

GOOSE расшифровывается как General Object Oriented Substation Event, но эта расшифровка уже не очень актуальна и смысловой нагрузки не несет.

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

Переход от связи точка-точка к ЛВС подхода не изменил. Данные по-прежнему необходимо передавать надежно, гарантированно и быстро. Поэтому для GOOSE-сообщений используется несколько непривычный механизм передачи данных. Про него чуть позже.

Измерения, как мы уже обсудили, также передаются с помощью multicast-потоков. В терминологии ЦПС эти потоки называются SV-потоками (Sampled Value).

SV-потоки это сообщения, содержащие определенный набор данных и передаваемые непрерывно с определенным периодом. Каждое сообщение содержит измерение в определенный момент времени. Измерения берутся с определенной частотой частотой дискретизации.

Частота дискретизации частота взятия отсчетов непрерывного по времени сигнала при его дискретизации.


Частота дискретизации 80 выборок в секунду

Состав SV-потоков описан в МЭК61850-9-2 LE.

SV-потоки передаются через шину процесса.

Шина процесса коммуникационная сеть, обеспечивающая обмен данными между измерительными устройствами и устройствами уровня присоединения. Правила обмена данными (мгновенными значениями тока и напряжения) описаны в стандарте МЭК 61850-9-2 (на данный момент используется профиль МЭК 61850-9-2 LE).

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

Зачем необходим multicast?
Как упоминалось выше, для закрытия требований по передаче данных для горизонтальной связи, GOOSE передаются несколько непривычно.

Во-первых, они передаются на канальном уровне и имеют свой Ethertype 0x88b8. Это обеспечивает высокую скорость передачи данных.

Теперь необходимо закрыть требования гарантированности и надежности.

Очевидно, что для гарантированности необходимо понимать доставлено ли сообщение, но мы не можем организовать отправки подтверждений получения, как, например, это делается в TCP. Это значительно снизит скорость передачи данных.

Поэтому для передачи GOOSE используется архитектура Издатель-Подписчик.

Архитектура Издатель Подписчик

Устройство отправляет GOOSE-сообщение на шину, и подписчики получают это сообщение. Причем сообщение отправляется с постоянным временем T0. Если случается какое-то событие, то генерируется новое сообщение, в независимости от того, закончился предыдущий период Т0 или нет. Следующее сообщение с новыми данными генерируется через очень короткий промежуток времени, потом через чуть больший и так далее. В итоге время увеличивается до Т0.

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

Подписчик знает, от кого он получает сообщения, и если от кого-то не получил сообщение через время T0, то он генерирует сообщение об ошибке.

SV-потоки также передаются на канальном уровне, имеют свой Ethertype 0x88BA и передаются по модели Издатель Подписчик.

Нюансы multicast-передачи в Цифровой подстанции
Но в энергетическом multicastе есть свои нюансы.

Нюанс 1. Для GOOSE и SV определены свои multicast-группы
Для энергетического multicast используются свои группы для рассылки.

В телекоме для multicast-рассылки используется диапазон 224.0.0.0/4 (за редкими исключениями есть зарезервированные адреса). Но сам стандарт МЭК 61850 и корпоративный профиль МЭК 61850 от ПАО ФСК определяет собственные диапазоны multicast-рассылки.

Для SV-потоков: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Для GOOSE-сообщений: от 01-0C-CD-04-00-00 до 01-0C-CD-04-FF-FF.

Нюанс 2. Терминалы не используют протоколы multicast
Второй нюанс гораздо значительнее терминалы релейной защиты не поддерживают IGMP или PIM. Тогда как они работаю с multicast? Они просто ждут, когда на порт будет прислана нужная информация. Т.е. если они знают, что подписаны на определенный MAC-адрес, то принимают все приходящие фреймы, но обрабатывают только необходимые. Остальные просто отбрасывают.

Другими словами вся надежда возлагается на коммутаторы. Но как будет работать IGMP или PIM, если терминалы не будут посылать Join-сообщения? Ответ простой никак.

А SV-потоки это достаточно тяжелые данные. Один поток весит около 5 Мбит/с. И если все оставить как есть, то получится, что каждый поток будет передаваться широковещательно. Другими словами, мы потянем всего 20 потоков на одну 100 Мбит/с ЛВС. А количество SV-потоков на крупной подстанции измеряется сотнями.

Какой тогда выход?

Простой использовать старые проверенные VLAN.

Более того, IGMP в ЛВС Цифровой Подстанции может сыграть злую шутку, и наоборот ничего не будет работать. Ведь коммутаторы без запроса не начнут передавать потоки.

Поэтому можно выделить простое правило пусконаладки Сеть не работает? Disable IGMP!

Нормативная база

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

• СТО 34.01-21-004-2019 ЦИФРОВОЙ ПИТАЮЩИЙ ЦЕНТР. ТРЕБОВАНИЯ К ТЕХНОЛОГИЧЕСКОМУ ПРОЕКТИРОВАНИЮ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 110-220 кВ И УЗЛОВХ ЦИФРОВХ ПОДСТАНЦИЙ НАПРЯЖЕНИЕМ 35 кВ.
• СТО 34.01-6-005-2019 КОММУТАТОР ЭНЕРГООБЪЕКТОВ. Общие технические требования.
• СТО 56947007-29.240.10.302-2020 Типовые технические требования к организации и производительности технологических ЛВС в АСУ ТП ПС ЕНЭС.

Давайте сначала посмотрим, что можно найти в этих СТО про multicast? Упоминание есть только в свежем СТО от ПАО ФСК ЕЭС. СТО просит при приемо-сдаточных испытаниях ЛВС проверить, корректно ли настроены VLAN, и проверить отсутствие multicast-трафика в непрописанных в рабочей документации портах коммутаторов.

Ну и еще СТО прописывает, что обслуживающий персонал должен знать, что такое multicast.

На этом все про multicast

Теперь давайте посмотрим, что можно найти в этих СТО про VLAN.

Здесь уже все три СТО сходятся в том, что коммутаторы должны поддерживать VLAN на основе IEEE 802.1Q.

СТО 34.01-21-004-2019 говорит о том, что VLANы должны использоваться для управления потоками, и при помощи VLAN трафик должен разделяться на РЗА, АСУТП, АИИС КУЭ, видеонаблюдение, связь и др.

СТО 56947007-29.240.10.302-2020, помимо этого, еще требует при проектирование подготовить карту распределения по VLAN. При этом СТО предлагает свои диапазоны IP-адресов и VLAN для оборудования ЦПС.

Также СТО приводит таблицу рекомендуемых приоритетов для разных VLAN.

Таблица рекомендуемых приоритетов VLAN из СТО 56947007-29.240.10.302-2020



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

А сейчас давайте подведем итог по управлению потоками в ЛВС Цифровой Подстанции.

Заключение

В Цифровой Подстанции, несмотря на тот факт, что передается очень много multicast-потоков, по факту не применяются стандартные механизмы управления multicast-трафиком (IGMP, PIM). Это обусловлено тем, что конечные устройства не поддерживают какие-либо multicast-протоколы.

Для управления потоками используются старые добрые VLANы. При этом использование VLAN регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.

Полезные ссылки:
Обучающий курс Цифровая подстанция от Phoenix Contact.
Решения для ЦПС от Phoenix Contact.

В наше время не каждый специалист может отнести сервер точного времени к категории технически сложных устройств. На просторах Интернета существует большое количество статей о том, как сделать собственный аппаратный NTP-сервер. Тем не менее, решения, применяемые в промышленных приложениях и предлагаемые мировыми производителями, сложно назвать бюджетными. Существует ли возможность оптимизировать эти затраты, не снижая качества и надежности подсистемы точного времени на предприятии?


Для чего нужно точное время?

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

В системах видеонаблюдения таймсервер обеспечивает привязку отснятых видеозаписей к астрономическому времени. Также устройство позволяет безошибочно сопоставлять информацию от разных информационных систем на предприятии. Например, это могут быть системы видеонаблюдения и системы безопасности, такие как СКУД, системы РЗА и независимые системы телемеханики и пр.

Ряд протоколов информационного обмена используют метки времени напрямую в составе пакетов передаваемых данных. К таким протоколам можно отнести МЭК-101/104, применяемые в современных системах телемеханики.

Одним из важных требований, предъявляемых в ряде промышленных приложений, являются требования информационной безопасности, исключающие выход в Интернет для выполнения функции синхронизации времени.

В силу своей простоты и ряда исторических причин для решения задачи синхронизации времени наибольшее распространение получил протокол NTP. В качестве NTP-клиентов на предприятии, помимо серверов, архивных и операторских станций систем управления, могут выступать контроллеры и HMI-панели, сетевое оборудование систем связи (управляемые коммутаторы, маршрутизаторы и пр).

Протокол NTP

Network time protocol (NTP) это сетевой протокол для синхронизации часов в компьютерных системах по сетям передачи данных с коммутацией пакетов и переменной задержкой (латентностью). Высокая популярность протокола объясняется активным развитием систем на основе Ethernet. Одним из ключевых преимуществ протокола является возможность передачи меток времени непосредственно по сети передачи данных, что позволяет отказаться от отдельной шины точного времени, как например в системах 1PPS или IRIGB. Протокол был разработан в 1985 году и является одним из старейших Интернет-протоколов, используемых в настоящее время.

NTP обеспечивает приемлемую точность синхронизации для большинства приложений. Протокол может поддерживать время с точностью до десятков миллисекунд в сети Интернет и до 0,2 мс в локальных сетях при идеальных условиях. Асимметричные маршруты передачи данных и перегрузка сети могут привести к ошибкам в 100 мс и более.

NTP синхронизирует устройства относительно всемирного координированного времени (UTC). При этом протокол учитывает появление високосной секунды в результате неравномерности вращения Земли, но никакой информации о местных часовых поясах или переходе на летнее время не передает.

Структура системы

NTP использует иерархическую систему источников точного времени. Каждый уровень иерархии называется Stratum (стратой, слоем) и ему присваивается номер, начинающийся с 0 для эталонных часов на вершине иерархии. Сервер времени на слое N синхронизируется от серверов на уровне N-1. Число N представляет собой расстояние от эталонных часов и используется для предотвращения цикличности в процессе синхронизации. Stratum не всегда является показателем качества или надежности. Например, можно найти источники времени на слое 3, которые имеют более высокое качество, чем источники времени на слое 2.

Stratum 0

В качестве эталонных часов на Stratum 0 выступают системы спутниковой навигации (ГЛОНАСС, GPS и пр.), атомные часы или радиопередатчики. Раз в секунду они генерируют импульсный сигнал (1PPS), который вызывает прерывание и генерирует метку времени на подключенных устройствах. Устройства слоя 0 также известны как опорные часы. Серверы NTP не могут позиционировать себя в системе как Stratum 0. Если в пакете передачи данных в поле Stratum установлен 0, это указывает на неопределенный слой.

Логическая структура системы синхронизации на основе NTP

Stratum 1

На этом слое находятся устройства, системное время которых синхронизировано с точностью до нескольких микросекунд от эталонных часов. Серверы времени на этом уровне могут работать в одноранговом режиме с другими серверами Stratum 1 для резервирования и проверки точности. Их также называют первичными серверами времени.

Stratum 2

Это устройства, которые синхронизируются по сети от серверов уровня 1. Часто устройства уровня 2 опрашивают несколько серверов уровня 1. Компьютеры Stratum 2 также могут быть одноранговыми с другими компьютерами Stratum 2, чтобы обеспечить более стабильное и надежное время для всех устройств в группе одноранговых узлов.

Максимальное теоретическое число слоев равно 15; Stratum 16 используется для указания того, что устройство не синхронизировано. Механизмы протокола NTP на каждом устройстве системы взаимодействуют таким образом, чтобы построить кратчайший путь к серверам Stratum 1 для всех клиентов. Это позволяет минимизировать накопленную задержку в передаче данных и повысить точность синхронизации. В основе алгоритма построения связующего дерева с минимальной длиной пути лежит алгоритм Беллмана-Форда.

Метки времени

Изначально NTP использовал 64-битные метки времени, состоявшие из 32-битной части для секунд и 32-битной части для долей секунды, что давало временную шкалу, которая прокручивалась бы каждые 232 секунды (136 лет) и давало теоретическое разрешение 2-32 секунды (233 пикосекунды). Отсчет времени начинался с 1 января 1900 года, поэтому первая эпоха закончилась бы 7 февраля 2036 года.

Последняя версия протокола NTPv4 вводит 128-битный формат представления времени: 64 бита для секунд и 64 бита для долей секунды, что дает временную шкалу более 584 млрд лет и разрешение в 0,05 аттосекунд. Дополнительно было введено 32-битное поле номера эры, которое устранило даже ставшей теоретической проблему окончания каждой эпохи.

Алгоритм синхронизации часов

Клиент NTP регулярно опрашивает один или несколько серверов. При этом он вычисляет смещение времени и круговую задержку. Смещение времени представляет собой разницу в абсолютном времени между часами сервера и клиента и определяется по формуле:


Круговая задержка определяется как время передачи сигнала по линиям связи от клиента к серверу и обратно. Это время, затраченное на отправку сигнала, плюс время, которое требуется для подтверждения, что сигнал был получен:


где t0 метка времени клиента для передачи пакета запроса,
t1 метка времени сервера приема пакета запроса,
t2 метка времени сервера для передачи ответного пакета,
t3 метка времени клиента приема ответного пакета.

Алгоритм расчета смещения времени и круговой задержки

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

Точная синхронизация достигается, когда входящие и исходящие маршруты между клиентом и сервером симметричны, то есть имеют одинаковую задержку. Если маршруты несимметричны, то существует систематическое смещение в половину разницы между временем передачи пакета от клиента к серверу и обратно.

Механизмы передачи

В большинстве случаев протокол NTP использует классическую клиент-серверную модель работы, в которой клиент отправляет запрос и через некоторое время получает ответ от сервера. Однако протокол допускает работу и в одноранговых системах, где два одноранговых узла (peer) рассматривают друг друга как потенциальный источник времени. Этот режим работы также называют симметричным. Для сетевого взаимодействия NTP использует протокол UDP, по умолчанию работая на порту 123. Для передачи данных могут быть использованы различные механизмы unicast, broadcast, multicast и manycast.

Режим Unicast

Протокол NTP для передачи данных чаще всего использует режим Unicast. В этом режиме данные передаются от одного устройства сети к другому индивидуально. В Unicast пакетах в качестве IP-адреса назначения используется конкретный адрес устройства, для которого этот пакет предназначен.

Режим Broadcast

Этот режим удобен в тех случаях, когда малое количество NTP-серверов обслуживает большое количество клиентов. В этом режиме сервер периодически рассылает пакеты, используя широковещательный адрес подсети. Клиент, настроенный на синхронизацию таким способом, получает широковещательный пакет сервера и производит синхронизацию с ним.

Этот режим имеет ряд особенностей. Во-первых, режим Broadcast обеспечивает меньшую точность синхронизации по сравнению с Unicast. Во-вторых, широковещательные пакеты могут передаваться только в рамках одной подсети. Кроме того, для защиты от злоумышленников желательно использовать методы аутентификации.

Режим Multicast

Режим Multicast работает аналогично Broadcast. Разница заключается в том, что для доставки пакетов используется не широковещательный адрес подсети, а адрес Multicast-группы. Для клиентов и серверов задается групповой IP-адрес, который они используют для синхронизации времени. Это делает возможным синхронизацию групп машин, расположенных в различных подсетях, при условии, что соединяющие их маршрутизаторы поддерживают протокол IGMP и настроены на передачу группового трафика.

Режим Manycast

Этот режим является нововведением последней версии (v4) протокола NTP. Режим Manycast функционирует как режим Multicast только с неизвестными IP-адресами серверов NTP. Путем рассылки Multicast-сообщений клиент ищет в сети Manycast-сервера, получает от каждого из них образцы времени и производит выбор трех лучших, с которыми будет производить синхронизацию. В случае выхода из строя одного из серверов клиент автоматически обновляет свой список.

Для передачи образцов времени клиенты и серверы, работающие в Manycast-режиме, также используют адреса Multicast-групп. Клиенты и серверы, использующие один и тот же адрес, формируют одну ассоциацию. Количество ассоциаций определяется количеством используемых Multicast-адресов.

Версии протокола

С момента своего появления в 1985 года протокол начал активно развиваться и уже к 1992 году сменил четыре версии (от NTPv0 до NTPv3). Каждая новая версия добавляла функционал и оптимизировала его работу, но оставляла неизменным формат данных и сохраняла совместимость различных версий между собой. Последняя четвертая версия протокола датирована 2010 годом. NTP продолжает развитие и в наши дни, ведутся работы по созданию решения, технически схожего с более точным протоколом PTP (Precision Time Protocol).

SNTP

Одновременно с NTPv3 в 1992 году была представлена более простая версия протокола SNTP (Simple NTP). В протоколе SNTP используется одинаковый с протоколом NTP формат передачи и представления данных. При этом SNTP не касается алгоритмов работы сервера, а упрощает алгоритмы работы клиентов. Именно поэтому протокол чаще всего используется во встраиваемых системах и устройствах, не требующих высокой точности.

Разница между NTP и SNTP заключается в методах определения оптимальных серверов для синхронизации и методе коррекции времени. Так NTP позволяет клиенту использовать математический алгоритм пересечений (переработанную версию алгоритма Марзулло) для выбора нескольких лучших серверов в сети и плавно корректировать свое время. В SNTP для синхронизации используется один предопределенный NTP сервер, в то время как другие могут являться лишь резервными на случай потери связи с основным устройством. При этом клиент, использующий SNTP, способен корректировать время только скачком по факту получения ответа от сервера.

Типовая схема системы синхронизации и ее недостатки

Традиционно система точного времени на промышленных объектах строится на основе NTP-сервера, состоящего из головного устройства, монтируемого в одном шкафу с сетевым оборудованием, и выносной антенны, которая устанавливается на улице и подключается к серверу при помощи коаксиального кабеля. При этом на головном устройстве имеется несколько сетевых интерфейсов (Ethernet или RS-232/485) для подключения клиентов в одной или нескольких сетях.

Типовая схема системы точного времени

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

Вторым недостатком можно назвать необходимость установки сервера времени в шкафу. Для больших проектов это не является минусом, но для небольших локальных систем управления это может стать серьезной проблемой.

Также к недостаткам можно отнести необходимость применения выносной антенны и коаксиального кабеля. Почему? Прежде всего, стоимость качественной GPS/ГЛОНАСС антенны с длинным кабелем и защитой от грызунов легко может перевалить за 10 000 руб. в ценах 2020 года. При этом коаксиальные кабели имеют ограниченную длину для передачи сигналов спутниковых систем. При длине более 50 м сигнал будет значительно затухать, что является серьезным ограничивающим фактором в больших зданиях.

Главным же недостатком традиционного подхода в создании систем синхронизации является его высокая стоимость (часто более 150 000 рублей), что существенно сказывается на смете не только небольших проектов, но и вполне крупных.

Как сделать систему дешевле и надежнее

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

Всё решение, связанное с системой синхронизации, включая GPS/ГЛОНАСС антенну, может уместиться в небольшую коробочку, как это сделано в
FL TIMESERVER от Phoenix Contact. Устройство выполнено по принципу smart-антенны, то есть совмещает в себе непосредственно функционал сервера времени и антенну GPS/ГЛОНАСС приемника. Конструктивное исполнение это единственное, что отличает его от привычных решений.


Сервер времени FL TIMESERVER NTP

Как показывает практика, устройство способно обеспечивать связь со спутниковыми системами даже внутри зданий, но для более надежного приема сигналов может эксплуатироваться в уличных условиях, потому что выполнено в корпусе с уровнем пылевлагозащиты IP68 и способно работать в широком температурном диапазоне от -40 до +70 С. При этом сервер времени монтируется как обычная антенна, имеет резервированное питание от цепи 24 В постоянного тока и/или через Ethernet кабель (РоЕ) и диагностируется по SNMP. При монтаже на открытом воздухе используется герметизирующий кабельный ввод, чтоб сохранить высокий уровень пылевлагозащиты.

В плане функционала никаких отличий нет: устройство способно принимать метки времени и данные геолокации от спутниковых систем навигации (ГЛОНАСС, GPS) и транслировать эту информацию для клиентов в сети Ethernet.

Система точного времени на основе решения Phoenix Contact

При использовании подобного решения система синхронизации значительно упрощается и позволяет избавиться от недостатков традиционного подхода. FL TIMESERVER имеет только один порт Ethernet, но при необходимости использовать несколько интерфейсов достаточно подключить его в коммутатор или же использовать несколько smart-антенн. В этом случае мы получим полноценное резервирование серверов времени, а не только его сетевого интерфейса. При этом конечное решение все равно окажется дешевле многих существующих аналогов. FL TIMESERVER можно вынести за пределы сетевого шкафа или шкафа автоматизации, сэкономив место внутри. В этом решении не требуется отдельная антенна, здесь она уже встроена и к сети предприятия мы можем подключаться обычным Ethernet кабелем. В свою очередь это позволяет вынести сервер времени на расстояние до 100 м от основного оборудования без опасения, что сигнал затухнет. Самым главным преимуществом подобного решения является совсем другой порядок цен. Стоимость одного сервера времени менее 300 евро, что делает его удобным в применении как в небольших, так и в крупных проектах.