Как управлять потоками в ЛВС Цифровой Подстанции?
Цифровая Подстанция – это тренд в энергетике. Если Вы близки к теме, то наверняка слышали, что большой объем данных передается в виде multicast-потоков. Но знаете ли Вы, как этими multicast-потоками управлять? Какие инструменты управления потоками применяются? Что советует нормативная документация?
Всем, кому интересно разобраться в этой теме, – welcome под кат!
Как данные передаются в сети и зачем управлять multicast-потоками?
Прежде чем переходить непосредственно к Цифровой Подстанции и нюансам построения ЛВС, предлагаю краткий ликбез по типам передачи данных и протоколам передачи данных для работы с multicast-потоками. Ликбез мы спрятали под спойлер.
Типы траффика в ЛВС
Существует четыре типа передачи данных:
- Broadcast – широковещательная рассылка.
- Unicast – обмен сообщениями между двумя устройствами.
- Multicast – рассылка сообщений на определенную группу устройств.
- Unknown Unicast – широковещательная рассылка с целью найти одно устройство.
Прежде всего, давайте вспомним, что внутри ЛВС адресация между устройствами выполняется на основе MAC-адресов. В любом передаваемом сообщении есть поля SRC MAC и DST MAC.
SRC MAC – source MAC – MAC-адрес отправителя.
DST MAC – destination MAC – MAC-адрес получателя.
Коммутатор на основании этих полей передает сообщения. Он смотрит DST MAC, находит его в своей таблице MAC-адресов и отправляет сообщение на тот порт, который указан в таблице. Также он смотрит и SRC MAC. Если такого MAC-адреса в таблице нет, то добавляется новая пара «MAC-адрес – порт».
Теперь давайте поговорим подробнее про типы передачи данных.
Unicast
Unicast – это адресная передача сообщений между двумя устройствами. По сути, это передача данных точка-точка. Другими словами, два устройства для общения друг с другом всегда используют Unicast.
Передача Unicast-трафика
Broadcast
Broadcast – это широковещательная рассылка. Т.е. рассылка, когда одно устройство отправляет сообщение всем остальным устройствам в сети.
Чтобы отправить широковещательное сообщение, отправитель в качестве DST MAC указывает адрес FF:FF:FF:FF:FF:FF.
Передача Broadcast-трафика
Unknown Unicast
Unknown Unicast, на первый взгляд, очень похож на Broadcast. Но разница между ними есть — сообщение рассылается всем участникам сети, но предназначено только одному устройству. Это как сообщение в торговом центре с просьбой перепарковать авто. Услышат это сообщение все, но откликнется только один.
Когда коммутатор принимает фрейм и не может найти Destination MAC из него в таблице MAC-адресов, то он просто рассылает это сообщение во все порты, кроме того, с которого принял его. На подобную рассылку ответит только одно устройство.
Передача Unknown Unicast-трафика
Multicast
Multicast – это рассылка сообщения на группу устройств, которые «хотят» получать эти данные. Это очень похоже на вебинар. Он транслируется на весь Интернет, но подключаются к нему только те люди, которым данная тематика интересна.
Такая модель передачи данных называется «Издатель — Подписчик». Есть один Издатель, который отправляет данные и Подписчики, которые эти данные хотят получать – подписываются на них.
При multicast-рассылке сообщение отправляется с реального устройства. В качестве Source MAC в фрейме указывается MAC отправителя. А вот в качестве Destination MAC — виртуальный адрес.
Устройство должно подключиться к группе, чтобы получать данные из нее. Коммутатор перенаправляет информационные потоки между устройствами – он запоминает, с каких портов данные передаются, и знает, на какие порты эти данные нужно отправлять.
Передача Multicast-трафика
Важный момент, что в качестве виртуальных групп чаще используются IP-адреса, но т.к. в разрезе данной статьи речь идет об энергетике, то мы будем говорить про MAC-адреса. В протоколах семейства МЭК 61850, которые используются для Цифровой Подстанции, разделение на группы производится на основе MAC-адресов
Краткий ликбез про MAC-адрес
MAC-адрес – это 48-битное значение, которое уникально идентифицирует устройство. Он разбит на 6 октет. Первые три октета содержат информацию о производителе. 4, 5 и 6 октеты назначаются производителем и являются номером устройства.
Структура MAC-адреса
В первом октете восьмой бит отвечает за то, является ли данное сообщение unicast или multicast. Если восьмой бит равен 0, то данный MAC-адрес – это адрес реального физического устройства.
А если восьмой бит равен 1, то этот MAC-адрес виртуальный. То есть, этот MAC-адрес принадлежит не реальному физическому устройству, а виртуальной группе.
Виртуальную группу можно сравнить с вышкой радиовещания. Радиокомпания транслирует на эту вышку какую-то музыку, а те, кому хочется ее послушать, – настраивают приемники на нужную частоту.
Также, например, IP-видеокамера отправляет данные в виртуальную группу, а те устройства, которые хотят эти данные получать, подключаются к этой группе.
Восьмой бит первого октета MAC-адреса
Если на коммутаторе не включена поддержка multicast, то он будет multicast-поток воспринимать как широковещательную рассылку. Соответственно, если таких потоков будет много, то мы очень быстро забьем сеть «мусорным» трафиком.
В чем суть multicast?
Основная идея multicast — с устройства отправляется только одна копия трафика. Коммутатор определяет, на каких портах находятся подписчики, и передает на них данные от отправителя. Тем самым, multicast позволяет значительно сократить данные, передаваемые через сеть.
Как это работает в реальной ЛВС?
Понятно, что недостаточно просто отправлять одну копию трафика на какой-то MAC-адрес, восьмой бит первого октета которого равен 1. Подписчики должны уметь подключаться к этой группе. А коммутаторы должны понимать, с каких портов данные приходят, и на какие порты их необходимо передавать. Только тогда multicast позволит оптимизировать сети и управлять потоками.
Для реализации этого функционала существуют multicast-протоколы. Наиболее распространенные:
- IGMP.
- PIM.
Коммутатор с поддержкой IGMP запоминает, на какой порт приходит multicast-поток. Подписчики должны отправить IMGP Join сообщение для подключения к группе. Коммутатор добавляет порт, с которого пришел IGMP Join, в список нисходящих интерфейсов и начинает передавать multicast-поток туда. Коммутатор постоянно посылает IGMP Query сообщения на нисходящие порты, чтобы проверить, нужно ли продолжать передавать данные. Если с порта пришло сообщение IGMP Leave или не было ответа на сообщение IGMP Query, то вещание на него прекращается.
У протокола PIM есть две реализации:
- PIM DM.
- PIM SM.
PIM SM по принципу работы близко к IGMP.
Если очень грубо обобщить общий принцип работы multicast – Издатель отправляет multicast-поток на определенную MAC-группу, подписчики отправляют запросы на подключение к этой группе, коммутаторы управляют данными потоками.
Почему мы настолько поверхностно прошлись по multicast? Давайте поговорим про специфику ЛВС Цифровой Подстанции, чтобы понять это.
UPD: Протоколы IGMP и PIM — это протоколы сетевого уровня и они работают с IP-адресами. При передаче данных IP-группа транслируется в MAC-адрес. Подробнее про это можно посмотреть, например, здесь. Есть протоколы, которые используют только MAC-адреса для рассылки (подробнее).
Что такое Цифровая Подстанция и зачем там нужен multicast?
Прежде, чем заговорить про ЛВС Цифровой Подстанции, нужно разобраться, что такое Цифровая Подстанция. Потом ответить на вопросы:
- Кто участвует в передаче данных?
- Какие данные передаются в ЛВС?
- Какая типовая архитектура ЛВС?
Что такое Цифровая Подстанция?
Цифровая Подстанция – это подстанция, все системы которой имеют очень высокий уровень автоматизации. Все вторичное и первичное оборудование такой подстанции ориентировано на цифровую передачу данных. Обмен данными выстраивается в соответствии с протоколами передачи, описанными в стандарте МЭК 61850.
Соответственно, в цифровом виде здесь передаются все данные:
- Измерения.
- Диагностическая информация.
- Команды управления.
Определение:
Цифровая подстанция — автоматизированная подстанция, оснащенная взаимодействующими в режиме единого времени цифровыми информационными и управляющими системами и функционирующая без присутствия постоянного дежурного персонала.
- дистанционная наблюдаемость параметров и режимов работы оборудования и систем, необходимых для нормального функционирования без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
- обеспечение телеуправления оборудованием и системами для эксплуатации ПС без постоянного присутствия дежурного и обслуживающего эксплуатационного персонала;
- высокий уровень автоматизации управления оборудованием и системами с применением интеллектуальных систем управления режимами работы оборудования и систем;
- дистанционная управляемость всеми технологическими процессами в режиме единого времени;
- цифровой обмен данными между всеми технологическими системами в едином формате;
- интегрированность в систему управления электрической сетью и предприятием, а также обеспечение цифрового взаимодействия с соответствующими инфраструктурными организациями (со смежными объектами);
- функциональная и информационная безопасность при цифровизации технологических процессов;
- непрерывный мониторинг состояния основного технологического оборудования и систем в режиме онлайн с передачей необходимого объема цифровых данных, контролируемых параметров и сигналов.
Кто участвует в передаче данных?
В составе Цифровой Подстанции есть следующие системы:
- Системы релейной защиты. Релейная защита – это практически «сердце» Цифровой Подстанции. Терминалы релейной защиты из систем измерения берут значения тока и напряжения. На основе этих данных терминалы отрабатывают внутреннюю логику защит. Терминалы общаются между собой, чтобы передавать информацию о сработанных защитах, о положениях коммутационных аппаратов и т.д. Также терминалы отправляют информацию о произошедших событиях на сервер АСУ ТП. Итого, можно выделить несколько типов связи:
▸Горизонтальная связь – общение терминалов между собой.
▸Вертикальная связь – общение с сервером АСУ ТП.
▸Измерения – общение с измерительными устройствами.
- Системы коммерческого учета электроэнергии.Системы коммерческого учета общаются только с измерительными устройствами.
- Системы диспетчерского управления.С сервера АСУ ТП и с сервера коммерческого учета данные частично должны отправляться в диспетчерский пункт.
Какие данные передаются в ЛВС?
Чтобы объединить описанные системы между собой и организовать горизонтальную и вертикальную связь, а также передачу измерений организуются шины. Пока давайте договоримся, что каждая шина – это просто отдельная ЛВС на промышленных Ethernet-коммутаторах.
Структурная схема электроэнергетического объекта в соответствии с МЭК 61850
На структурной схеме изображены шины:
- Мониторинг/Управления.
- Передача сигналов РЗА.
- Передача мгновенных значений напряжений и токов.
Через шину «Передача сигналов РЗА» терминалы передают информацию между собой. Т.е. здесь реализована горизонтальная связь.
Через шину «Передача мгновенных значений напряжений и токов» реализована передача измерений. К этой шине подключаются устройства измерения – трансформаторы тока и напряжения, а также терминалы релейной защиты.
Также к шине «Передача мгновенных значений напряжений и токов» подключается сервер АСКУЭ, который также забирает к себе измерения для учета.
А шина «Мониторинг/Управление» служит для вертикальной связи. Т.е. через нее терминалы отправляют на сервер АСУ ТП различные события, а также сервер посылает управляющие команды на терминалы.
С сервера АСУ ТП данные отправляются в диспетчерский пункт.
Какая типовая архитектура ЛВС?
Перейдем от абстрактной и достаточно условной структурной схемы к более приземленным и реальным вещам.
На схеме ниже изображена достаточно стандартная архитектура ЛВС для Цифровой Подстанции.
Архитектура Цифровой Подстанции
На подстанциях 6 кВ или 35 кВ сеть будет попроще, но если мы говорим про подстанции 110 кВ, 220 кВ и выше, а также про ЛВС электрических станций, то архитектура будет соответствовать изображенной.
Архитектура разбита на три уровня:
- Уровень станции/подстанции.
- Уровень присоединения.
- Уровень процесса.
Уровень присоединения включает в себя все технологическое оборудование.
Уровень процесса включает в себя измерительное оборудование.
Также есть две шины для объединения уровней:
- Шина станции/подстанции.
- Шина процесса.
Особенности передачи Multicast в Цифровой Подстанции
Какие данные передаются с помощью multicast?
Горизонтальная связь и передача измерений в рамках Цифровой Подстанции выполняется с помощью архитектуры «Издатель-Подписчик». Т.е. терминалы релейной защиты используют multicast-потоки для обмена сообщениями между собой, а также измерения передаются с помощью multicast.
До цифровой подстанции в энергетике горизонтальная связь реализовывалась при помощи связи точка-точка между терминалами. В качестве интерфейса использовался либо медный, либо оптический кабель. Данные передавались по проприетарным протоколам.
К этой связи предъявлялись очень высокие требования, т.к. по этим каналам передавали сигналы срабатывания защит, положения коммутационных аппаратов и т.д. От этой информации зависел алгоритм оперативной блокировки терминалов.
В случае если данные будут передавать медленно или негарантированно, велика вероятность, что какой-то из терминалов не получит актуальной информации по текущей ситуации и может подать сигнал на отключение или включение коммутационного аппарата, когда на нем, например, будут проводиться какие-то работы. Или УРОВ не отработает вовремя и КЗ распространится на остальные части электрической схемы. Все это чревато большими денежными потерями и угрозой человеческой жизни.
Поэтому данные должны были передаваться:
- Надежно.
- Гарантированно.
- Быстро.
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-01-FF.
Для GOOSE-сообщений: от 01-0C-CD-01-00-00 до 01-0C-CD-01-01-FF.
Нюанс 2. Терминалы не используют протоколы multicast
Второй нюанс гораздо значительнее — терминалы релейной защиты не поддерживают ни IGMP, ни PIM, ни какие-либо еще multicast-протоколы. Тогда как они работаю с 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.
На этом все про 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 регламентировано нормативной документацией, которая предлагает достаточно проработанные рекомендации.
Шина процесса и шина станции что это
Релейная защита • МЭК 61850
Продолжаем цикл публикаций «Релейная защита. МЭК 61850», в рамках которого будут рассмотрены все части стандарта и описываемых им протоколов (начало цикла – см. «Новости ЭлектроТехники» № 3(75) 2012, № 4(76) 2012, № 5(77) 2012, № 6(78) 2012, № 1(79) 2013).
Члены рабочей группы 10 Технического комитета 57 «Управление электроэнергетическими системами и сопутствующие технологии обмена информацией» МЭК, занимающейся разработкой стандарта, Алексей Олегович Аношин и Александр Валерьевич Головин рассматривают сегодня протокол передачи мгновенных значений тока и напряжения, применение которого пока ограничивается пилотными проектами.
 |  |
| Алексей Аношин, исполнительный директор | Александр Головин, технический директор |
| ООО «ТЕКВЕЛ», г. Москва | |
СТАНДАРТ МЭК 61850
Протокол передачи мгновенных значений тока и напряжения
Шина процесса и протокол МЭК 61850-9-2
Использование протокола МЭК 61850-9-2 неразрывно связано с термином «шина процесса» (от англ. Process Bus). Шиной процесса по МЭК 61850-1 называется коммуникационная шина данных, к которой подключены устройства полевого уровня подстанции (коммутационные аппараты, измерительные трансформаторы). В данном случае слово «шина» не следует понимать буквально, речь идет о целой системе передачи данных между устройствами. Таким образом, в общем случае к шине процесса могут быть подключены не только измерительные преобразователи, но также выключатели, разъединители и другое оборудование. Однако именно передача мгновенных значений от измерительных трансформаторов производит наибольшую нагрузку на информационную сеть шины процесса.
В традиционной схеме подключения устройств РЗА цепи от измерительных трансформаторов тока (ТТ) и напряжения (ТН), находящихся на ОРУ или в КРУЭ, прокладываются до терминалов РЗА, размещенных в ОПУ (рис. 1).
Рис. 1. Традиционная схема подключения устройств РЗА:
a) к ТТ и ТН, б) к цепям напряжения
Использование концепции шины процесса предполагает, что все сигналы, включая мгновенные значения токов и напряжений, оцифровываются непосредственно в аппарате и передаются устройствам защиты и автоматики в виде цифрового потока данных по информационной сети, называемой шиной процесса (рис. 2).
Рис. 2. Использование шины процесса для передачи данных
Как и в случае с остальными протоколами, основные концептуальные положения сервиса передачи мгновенных значений описаны главой МЭК 61850-7-2.
Характеристики
Охарактеризуем передачу мгновенных значений тока и напряжения с точки зрения требований, предъявляемых при передаче данных:
- требуется передача данных с высокой частотой, что ведет к появлению больших объемов информации, передаваемых по сети. Причем должна быть обеспечена возможность выбора различных частот, например, меньшая частота в случае использования для целей релейной защиты и большая частота для целей контроля качества электрической энергии;
- необходимо обеспечить минимальную задержку при передаче данных по сети шины станции, так как эта задержка в конечном счете будет влиять на быстродействие устройств РЗА;
- измерения, получаемые из различных источников одним приемником (например, значения тока и напряжения от разных устройств сопряжения), должны быть синхронизированы. В противном случае возможна некорректная работа устройств РЗА;
- требуется обеспечить возможность выявления потерь и искажений данных при передаче данных с целью исключения возможных излишних и ложных срабатываний РЗА, а также сигнализации в случае отказа канала связи или устройства сопряжения;
- один поток данных может быть востребован различными устройствами (например, данные о напряжении на шинах от устройства сопряжения ТН), поэтому должна быть обеспечена возможность многоадресной передачи данных;
- требуется гибкость при формировании кадров данных, поскольку измерения могут поступать как от группы трехфазных ТТ или ТН, так и от комбинированных измерительных преобразователей.
Рассмотрим механизмы, с помощью которых решались поставленные задачи.
ПЕРЕДАЧА ДАННЫХ С ВЫСОКОЙ ЧАСТОТОЙ И СКОРОСТЬ ПЕРЕДАЧИ ДАННЫХ
Обеспечение высокой частоты передаваемых данных на сегодняшний день является обычным требованием к сетям передачи данных, например, при решении задач телефонии или передачи потокового видео. Поэтому, хотя прикладная задача передачи мгновенных значений тока и напряжения и накладывает достаточно высокие требования в части производительности сетевого оборудования, существующее сетевое оборудование в промышленном исполнении вполне способно решать эти задачи.
Отдельно следует рассмотреть требование о возможности изменения частоты передачи данных. Так, при решении задач релейной защиты может потребоваться передавать мгновенные значения с частотой 20 выборок/период, однако для целей контроля качества электрической энергии потребуется существенно более высокая частота. С другой стороны, в указанных случаях предъявляются различные требования к быстродействию. Например, в случае передачи данных устройству релейной защиты требуется передать значения тока и напряжения в темпе реального времени с минимальной задержкой, тогда как для целей коммерческого учета и анализа качества допустимо введение задержек при условии точной привязки данных к единому времени.
Исходя из этих условий, в стандарте предусмотрено два параметра, которые будут влиять на частоту формирования кадров с выборками мгновенных значений (Sample Rate – SmpRate) и на количество измерений, размещаемых в одном кадре (Number of ASDU – noASDU). Фактическая частота формирования кадра в сеть при этом будет составлять f = SmpRate / noASDU. Так, при частоте SmpRate = 80 выборок за период и количестве мгновенных значений в одном кадре noASDU = 1, фактическая частота формирования кадров составит 80 пакетов за период, или 4 кГц. В случае частоты взятия выборок SmpRate = 256 выборок за период и количестве выборок в кадре noASDU = 8, фактическая частота формирования кадров в сеть составит лишь 1,6 кГц.
Конечно, кадр с 8 выборками будет иметь больший размер, чем с одной выборкой, однако в силу специфики сетей на базе технологии Ethernet оптимальная пропускная способность канала передачи данных достигается при максимальной длине кадров. Кроме того, при передаче нескольких выборок в одном кадре используется одна и та же общая часть кадра, что в конечном счете позволяет повысить эффективность передачи данных в случаях, когда не требуется высокое быстродействие, то есть скорость передачи каждой отдельной выборки.
ОБЕСПЕЧЕНИЕ МИНИМАЛЬНЫХ ЗАДЕРЖЕК ПРИ ПЕРЕДАЧЕ ДАННЫХ
Вопрос обеспечения минимальных задержек при передаче данных по протоколу GOOSE был достаточно подробно рассмотрен в [1]. Протокол МЭК 61850-9-2, так же как и GOOSE, маппируется непосредственно на протокол второго уровня. Это в сочетании с использованием меток приоритета VLAN-Priority и качества обслуживания QoS позволяет значительно повысить приоритет данных, передаваемых по протоколу МЭК 61850-9-2, по сравнению с остальными данными, передаваемыми по той же сети с использованием других протоколов, тем самым сводя к минимуму задержки как при обработке данных внутри устройств источников и приемников данных, так и при обработке их сетевыми коммутаторами.
СИНХРОНИЗАЦИЯ ДАННЫХ И ОБНАРУЖЕНИЕ ПОТЕРЬ
Устройство релейной защиты может получать измерения от разных устройств шины процесса. Например, на защищаемом присоединении может быть установлен только трансформатор тока, тогда как данные о напряжении поступают от ТН, установленного на шинах и подключенного через отдельное устройство сопряжения (УСШ). Очевидно, что в такой ситуации отсутствие синхронизации между выборками с двух УСШ может привести к ложным и излишним срабатываниям защиты в случае возникновения различных задержек по сети и неодновременного прихода пакетов.
Отметим, что фактически присвоение метки абсолютного времени каждой выборке не требуется. Необходимо лишь, чтобы выборки, сформированные различными устройствами в один и тот же момент времени, имели один и тот же идентификатор. Таким идентификатором является поле smpCnt – счетчик выборок. Счетчик за одну секунду пробегает значения от 0 до (SmpRate · 50 – 1). Номера присваиваются формируемым выборкам одновременно, так что устройство-приемник данных по МЭК 61850-9-2 может легко установить соответствие между получаемыми значениями и производить вычисления на их основе. Для того, чтобы все устройства сопряжения формировали данные с одними и теми же номерами, используется внешний синхронизирующий импульс. При использовании секундного импульса счетчик smpCnt принимает значение 0 каждый раз при приходе синхроимпульса. Причем выборке с номером 0 соответствует выборка, взятая в момент прихода импульса.
Таким образом достигается синхронизация всех выборок, и принимающее устройство может обрабатывать значения токов и напряжений, принятые от разных устройств, компонуя их по номерам выборок (рис. 3), причем синхронизация самого принимающего устройства не требуется. С помощью счетчика выборок устройство также может осуществлять контроль целостности принимаемых данных, то есть обнаруживать факты пропажи выборок. Различные устройства по-разному реагируют на пропажу выборок. Как правило, это определяется алгоритмами, заложенными в устройство-приемник, и описано в сопроводительной документации.
Рис. 3. Синхронизация и присвоение номеров выборкам
СИГНАЛИЗАЦИЯ ОБ ИСКАЖЕНИЯХ ДАННЫХ
Важной особенностью передачи данных в цифровом формате является возможность передачи сервисной информации – так называемых мета-данных. Сервисная информация передается с использованием меток качества в одном кадре с самими выборками. Такая опция позволяет устройству-издателю снабжать передаваемые значения токов и напряжений метками, отражающими достоверность этих данных, включая информацию о том, что измерения производятся в заданном классе точности, измеряемое значение не выходит за границы допустимого диапазона, значение измерено прямым путем либо получено на основе косвенных вычислений и т.п.
Эти данные могут в дальнейшем использоваться алгоритмами принимающего устройства с целью блокировки тех или иных функций в автоматическом режиме и выдачи сигнализации оперативному персоналу.
ГИБКОСТЬ ПРИ ФОРМИРОВАНИИ ПОТОКОВ ДАННЫХ
По аналогии с GOOSE-сообщениями, данные в которых передаются на основе составленного набора данных (DataSet), потоки по протоколу МЭК 61850-9-2 также формируются на основе набора данных, в который включаются атрибуты мгновенных значений тока и напряжения.
В общем случае в набор данных, передаваемых по протоколу МЭК 61850-9-2, могут включаться не только эти атрибуты, но и любые атрибуты сигналов, включая дискретные сигналы, при условии что эти данные необходимо передавать с высокой частотой дискретизации.
СПЕЦИФИКАЦИЯ Light Edition
Глава МЭК 61850-9-2 описывает коммуникационный профиль протокола передачи мгновенных значений и структуру соответствующих сообщений, однако не описывает ни структуру информационной модели устройств, ни структуру набора передаваемых данных, ни частоты дискретизации измеряемых сигналов, ни способы синхронизации устройств.
За несколько лет существования первой редакции МЭК 61850-9-2 массово не были представлены устройства с его поддержкой, в первую очередь, ввиду большой гибкости, которую он давал, хотя принципиально все изложенные в нем положения всем были понятны. Каждый производитель мог определить свой набор данных, свои частоты дискретизации и реализовать устройства с соответствующими характеристиками, но его решения не были бы совместимы с решениями других производителей, либо для их совместимости потребовался бы охват большого диапазона значений изменяющихся параметров, что сразу реализовать крайне сложно.
Появилась необходимость в некой договоренности между производителями, заказчиками и другими заинтересованными сторонами. Такой договоренностью стали технические требования Implementation Guidelines for Digital Interface to Instrument Transformers using IEC 61850-9-2, получившие сокращенное наименование МЭК 61850-9-2LE. Эти технические требования не противоречат положениям стандарта МЭК 61850-9-2, а лишь зафиксировали ряд моментов:
- структуру информационной модели устройства;
- набор передаваемых данных (4 тока и 4 напряжения);
- частоты дискретизации измеряемых сигналов (4000 Гц для целей релейной защиты и коммерческого учета, 12800 Гц для целей контроля качества электроэнергии);
- способы синхронизации устройств (секундный импульс 1PPS).
Это дало толчок к массовому появлению на рынке как устройств-источников информационных потоков МЭК 61850-9-2LE, так и приемников этих потоков.
Моменты, зафиксированные техническими требованиями МЭК 61850-9-2LE, могут меняться с течением времени (так, может измениться способ синхронизации устройств, структура набора данных и т.д.). И примеры этого уже есть: тенденция к использованию протокола PTP для синхронизации устройств [3] вместо описанного в МЭК 61850-9-2LE синхроимпульса 1PPS, изменение/добавление частот дискретизации измеряемых сигналов [4] и др.
Таким образом, можно отметить, что все устройства, которые сейчас появляются на рынке, поддерживают МЭК 61850-9-2, а благодаря техническим требованиям МЭК 61850-9-2LE все производители приняли одинаковые решения в тех аспектах, где МЭК 61850-9-2 допускает гибкость.
РАЗВИТИЕ ПРОТОКОЛА В ЧАСТИ СИНХРОНИЗАЦИИ ВРЕМЕНИ И РЕЗЕРВИРОВАНИЯ
Первая редакция МЭК 61850-9-2 не предполагала использования протоколов резервирования, в связи с чем формат Ethernet-кадра, описанный первой редакцией, не включал соответствующих полей. Впоследствии вопрос применения протоколов резервирования на уровне шины процесса встал достаточно остро, в связи с чем во второй редакции стандарта в описание формата кадра 9-2 были добавлены поля для протоколов резервирования PRP и HSR.
Протокол синхронизации не описан самим стандартом МЭК 61850-9-2. Глава МЭК 61850-5 содержит лишь требования к точности синхронизации, однако также не оговаривает, каким образом должна достигаться эта точность. Единственным документом, прямо указывающим на использование синхроимпульса 1PPS, являются технические требования МЭК 61850-9-2LE. Следует отметить, что данная спецификация не предполагала использование протокола синхронизации PTPv2 согласно стандарту IEEE 1588 (МЭК 61588), профиль которого для электроэнергетики появился уже после принятия МЭК 61850-9-2LE. Однако уже сегодня появляются устройства, поддерживающие новый протокол синхронизации вместе с возможностью синхронизации по сигналу 1PPS.
Рассмотренные изменения ведут к необходимости закрепления новых технических требований или общих договоренностей взамен действующей редакции 9-2LE, и у многих возникает вопрос: когда будет издана вторая редакция 9-2LE? Однако вторая редакция 9-2LE издана не будет. На смену этому документу придет стандарт, описывающий требования к цифровому интерфейсу измерительных трансформаторов – МЭК 61869-9.
МЭК 61869-9
На сегодняшний день стандарт МЭК 61869-9 «Измерительные трансформаторы — Часть 9. Цифровой интерфейс» находится в финальной стадии разработки: он опубликован для голосования и сбора замечаний. Этот документ заменит и расширит технические требования МЭК 61850-9-2LE, которые определили первый профиль (или спецификацию) МЭК 61850 для измерительных трансформаторов тока и напряжения и устройств сопряжения. Новый стандарт учитывает опыт, накопленный в работе с техническими требованиями, изложенными в 9-2LE.
Отличительными особенностями документа являются:
- обратная совместимость с МЭК 61850-9-2LE;
- использование синхронизации согласно стандарту МЭК 61588 (2-я редакция) с сохранением возможности использования 1PPS;
- обеспечение возможности измерения электрических величин в сетях как переменного, так и постоянного тока;
- предусмотрено использование Ethernet 100 Мбит/с или 1 Гбит/с;
- определено использование следующих частот дискретизации измеряемых сигналов вне зависимости от номинальной частоты сети:
- для целей учета электроэнергии и РЗА: 4800 Гц;
- для целей контроля качества электроэнергии: 14400 Гц;
- для целей учета электроэнергии и РЗА в сетях постоянного тока: 96000 Гц.
ЛИТЕРАТУРА
- Аношин А.О., Головин А.В. Стандарт МЭК 61850. Протокол GOOSE // Новости ЭлектроТехники. 2012. № 6(78).
- Аношин А.О., Головин А.В. Стандарт МЭК 61850. Протокол MMS // Новости ЭлектроТехники. 2013. № 1(79).
- Временная синхронизация согласно стандарту IEEE 1588 // www.digitalsubstation.ru.
- МЭК 61869-9 опубликован для голосования // www.digitalsubstation.ru.
© ЗАО «Новости Электротехники»
Использование материалов сайта возможно только с письменного разрешения редакции
При цитировании материалов гиперссылка на сайт с указанием автора обязательнаШина процесса
Оффтоп.
Статьи не читал, просто просмотрел рисунки. Обратил внимание на http://www.news.elteh.ru/pics/80/Anoshin_80_pict-02.jpg
Основная и резервная защита линии на одной шине процесса? Т.е. шина неисправна и ни та ни друга защиты работать не будут? Или предлагается резервирование данной шины?2 Ответ от Andrey_13 2014-03-07 17:53:33
- Andrey_13
- Проектировщик
- Неактивен
- Зарегистрирован: 2012-04-18
- Сообщений: 1,434
- Репутация : [ 0 | 0 ]
Re: Шина процесса
А устройство управления выключателем?
3 Ответ от Golemlego 2014-03-07 19:23:28 (2014-03-08 00:31:29 отредактировано Golemlego)
- Golemlego
- Пользователь
- Неактивен
- Зарегистрирован: 2011-01-12
- Сообщений: 241
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Внесу свою лепту, а сервер времени? Вырубится сервер, произойдет рассинхронизация всех устройств, чревато.
4 Ответ от dominator 2014-03-07 22:20:21
- dominator
- Пользователь
- Неактивен
- Зарегистрирован: 2011-01-07
- Сообщений: 711
- Репутация : [ 1 | 0 ]
Re: Шина процесса
А устройство управления выключателем?
Как минимум, особо ответственные сигналы можно продублировать с помощью УУВа соседнего выкючателя.
СОЕВ, да, резервируется.5 Ответ от fajm 2014-03-14 10:22:44
- fajm
- Пользователь
- Неактивен
- Зарегистрирован: 2012-05-17
- Сообщений: 22
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Шина процесса дублируется, все современные устройства рза и асу тп имеют дублированный сетевой интерфейс
6 Ответ от Yuriy82 2014-03-14 10:33:57
- Yuriy82
- Пользователь
- Неактивен
- Зарегистрирован: 2011-02-01
- Сообщений: 158
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Шина процесса дублируется, все современные устройства рза и асу тп имеют дублированный сетевой интерфейс
Одно совершенно не следует из другого. имея дублированный сетевой интерфейс вы всего лишь резервируете подключение устройства к одной шине процесса. Причем способы резервирования этих двух интерфейсов также различаются.
Приведенная иллюстрация слишком упрощенная, чтобы делать на ее основе какие-либо выводы.
7 Ответ от fajm 2014-03-14 11:45:22
- fajm
- Пользователь
- Неактивен
- Зарегистрирован: 2012-05-17
- Сообщений: 22
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Приведенная иллюстрация слишком упрощенная, чтобы делать на ее основе какие-либо выводы.
Совершенно верно!
А про дублированный интерфейс я имел ввиду протокол PRP, каждый интерфейс устройства работает на отдельную информационную сеть.8 Ответ от sonoki 2014-06-12 14:02:39
- sonoki
- Пользователь
- Неактивен
- Зарегистрирован: 2011-07-05
- Сообщений: 28
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Внесу свою лепту, а сервер времени? Вырубится сервер, произойдет рассинхронизация всех устройств, чревато.
Medvedb,спасибо.
Если есть поддержка IEEE1588 и устройства защиты его поддерживают, то если пропадает сгинла от основного источника — одно реле должно стать мастером для других устройств, так что все ок.
Что касается резервирования, как правильно отметил коллега выше, при использовании протокола PRP — это две независимые сети, при нормальной работе, сигнал передается по двум сетим, при этом дублирующиеся сигналы отбырасываются. При сбое в отдной из сетей, сигналы продолжают идти по исправной. За счет этого не требуется время на реконфигурацию дерева, в отличии от RSTP. В протоколе HSR время реконфигурации так же равно 0, но он менее надежен, т.к. используется кольцевая схема связи между устройствами. По той же причине построение сети по такой топологии дешевле, чем PRP.
9 Ответ от rocker890 2014-06-13 07:33:02
- rocker890
- ГИПроектировщик
- Неактивен
- Откуда: Челябинск
- Зарегистрирован: 2011-05-30
- Сообщений: 1,732
- Репутация : [ 0 | 0 ]
Re: Шина процесса
А посоветуйте литературу по данному вопросу, чтобы понять азы и начать разбираться?
10 Ответ от Andrey_13 2014-06-19 08:56:58
- Andrey_13
- Проектировщик
- Неактивен
- Зарегистрирован: 2012-04-18
- Сообщений: 1,434
- Репутация : [ 0 | 0 ]
Re: Шина процесса
А посоветуйте литературу по данному вопросу, чтобы понять азы и начать разбираться?
11 Ответ от tenzorx 2014-07-23 09:41:15
- tenzorx
- Пользователь
- Неактивен
- Зарегистрирован: 2011-10-10
- Сообщений: 17
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Если имеете ввиду литературу по протоколам резервирования и построению ЛВС, то тут можно обратиться к:
— Разделу 90-4 стандарта МЭК 61850 — этот раздел выполнен в форме guidelines — по-русски руководящие указания и как это принято для подобных док-ов не содержат подробных объяснений многих вещей;
— Самому стандарту МЭК 62439 раздел 3, именно он посвящен PRP и HSR;
— Книге Alstom NPAG — её можно получить бесплатно в электронном виде, сделав запрос, она практически вся посвящена РЗ,но в конце есть информация по цифровому направлению.
Все это англоязычные источники, с литературой на русском сложно.12 Ответ от rocker890 2014-07-23 10:16:38
- rocker890
- ГИПроектировщик
- Неактивен
- Откуда: Челябинск
- Зарегистрирован: 2011-05-30
- Сообщений: 1,732
- Репутация : [ 0 | 0 ]
Re: Шина процесса
я на досуге как-то начал читать в переводе стандарты. ничего не понятно. Надо азы. По связи, автоматике, асу тп.
13 Ответ от tenzorx 2014-07-23 10:50:14
- tenzorx
- Пользователь
- Неактивен
- Зарегистрирован: 2011-10-10
- Сообщений: 17
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Если из азов по связи, то помогут книги по ЛВС от Олифера и Таненбаума, они на русском есть.
14 Ответ от Antusov 2018-01-31 14:45:53
- Antusov
- Пользователь
- Неактивен
- Зарегистрирован: 2015-11-04
- Сообщений: 68
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Шина процесса, должна быть ограничена присоединением, но бывает исключение, например защита шин и диф.защита трансформатора, она охватывает несколько присоединений.
Шина процесса должна обеспечивать жесткое качество обслуживания в режиме реального времени.
При построении шины процесса должны рассматриваться топологии сети:
— две отдельные сети со схемой "звезда" ( схема без единой точки отказа) и/или "дублированная звезда" с технологией разервирования PRP;
— кольцо с технологией резервирования HSR.15 Ответ от Golemlego 2018-01-31 17:06:38
- Golemlego
- Пользователь
- Неактивен
- Зарегистрирован: 2011-01-12
- Сообщений: 241
- Репутация : [ 0 | 0 ]
Re: Шина процесса
Шина процесса, должна быть ограничена присоединением, но бывает исключение, например защита шин и диф.защита трансформатора, она охватывает несколько присоединений.
Шина процесса должна обеспечивать жесткое качество обслуживания в режиме реального времени.
При построении шины процесса должны рассматриваться топологии сети:
— две отдельные сети со схемой "звезда" ( схема без единой точки отказа) и/или "дублированная звезда" с технологией разервирования PRP;
— кольцо с технологией резервирования HSR.Шина процесса и шина станции что это
Среди лучших практик интеграции сложных информационных систем — построение логических витрин данных, а также создание централизованных инфраструктур обмена данными при помощи MDM-систем и корпоративных сервисных шин (ESB, Enterprise Service Bus). Наши решения, в том числе система АрхиГраф.MDM, пригодны для использования в составе операционной системы специального назначения Astra Linux Special Edition, а также Alt Linux.
Зачем нужна интеграционная шина?
Любая компания, использующая больше двух программных продуктов, работающих с пересекающимися наборами информации, знает, какова цена отсутствия связи между ними. Не синхронизированные списки клиентов или номенклатуры товаров и другой информации между ERP, CRM иными корпоративными приложениями, несут постоянные потери времени, ресурсов, репутации компании. Единственным правильным решением подобной проблемы является внедрение корпоративной сервисной шины (ESB), в связке с системой управления мастер-данными (MDM).
Решения, основанные на регулярных выгрузках и преобразовании информации (ETL), сервисно-ориентированной архитектуре (SOA), дают лишь временное решение подобных проблем, имеют множество недостатков, ограничивают возможности роста ИТ-инфраструктуры.
Внедрение интеграционной шины
При внедрении интеграционной шины возникает задача мэппинга (сопоставления) структуры сведений об одних и тех же объектах, присутствующих в разных информационных системах. Решать эту задачу необходимо путем создания общей, нейтральной по отношению к каждому приложению, информационной модели. Такая модель может быть наиболее эффективно реализована при помощи семантических технологий. Для достижения оптимальных результатов внедрения требуется, чтобы разработкой модели занимался профессиональный архитектор данных.
Важной частью проекта по внедрению является реализация коннекторов (программных интерфейсов) для всех приложений, участвующих в обмене данными. Наши специалисты имеют опыт разработки и подключения коннекторов для широкого круга ПО на различных платформах.
Проекты по интеграции мы выполняем совместно с партнерами на основе решений IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse, а также шины «Бизнес Семантика».
Часто проект по внедрению интеграционной шины выполняется в рамках общего реинжиниринга информационной архитектуры предприятия.
Корпоративная сервисная шина — «бюджетный» подход к решению задач интеграции
Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft LabПродолжая знакомить читателя с различными подходами к интеграции, мы решили остановиться на относительно новой и весьма привлекательной технологии — корпоративной сервисной шине (Enterprise Service Bus, сокр. ESB).
Что же такое корпоративная сервисная шина и как она соотносится с рассмотренной в предыдущих номерах Журнала Клуба знатоков DWH, OLAP и XML интеграцией корпоративных приложений (EAI)? По сложившейся традиции сначала предоставим слово экспертам в данной области.
Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня (middleware), который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция). Многие корпоративные сервисные шины также поддерживают другие стили обмена информацией, включая гарантированную доставку и «публикацию и подписку» (publish and subscribe). Сервисы, предоставляемые этими шинами, обладают «добавленной стоимостью», которой не располагают межплатформенное обеспечение, предназначенное для упрощенного обмена сообщениями, — они обеспечивают проверку сообщений, трансформацию, маршрутизацию на основе содержания, безопасность, обнаружение сервисов для сервис-ориентированной архитектуры, балансирование нагрузки и регистрацию. Некоторые сервисы встроены в основание шины, другие — исполняются в модулях расширения (plug-in). Кроме того, шины поддерживают язык XML и другие форматы сообщений.
Чем же так привлекательна корпоративная сервисная шина? Прежде всего, своей относительной дешевизной. Продукты ESB, как правило позиционируются как доступные по цене, или, как говорят, «бюджетные», решения.
Действительно, сегодня наблюдается усиления спроса на интеграционные технологии. И если раньше развертывание продуктов EAI было связано с достижением стратегических целей и, следовательно, окупалось в долгосрочной перспективе, задачи, с которыми в настоящий момент приходится сталкиваться компаниям, носят тактический характер и требуют новых подходов. «Современные бизнес-реалии» привлекли внимание к областям, где поставщики EAI традиционно слабы — к трансформации, программной обработке, ориентированной на разработчиков (например, на Java) и интеграции к внешним технологиям. Все это и «подготовило благоприятную почву» для появления новой категории продуктов — ESB.
Говоря о достоинствах корпоративной сервисной шины, стоит привести слова вице-президента и члена исследовательского отдела компании Gartner Ройя Шульте (Roy Schulte): «Обычное программное обеспечение промежуточного уровня уже не может поддерживать новые приложения, которые используют сервис-ориентированную (Service Oriented Architecture, сокр. SOA) и управляемую событиями архитектуры (Event Driven Architecture, сокр. EDA), Web-сервисы и управление бизнес-процессами. Это и является основной причиной, почему архитекторы и менеджеры информационных систем должны усилить свои корпоративные информационные инфраструктуры с помощью ESB».
Ведущий аналитик Gartner выделяет группы поставщиков ESB. К первой группе он относит продукты ESB, которые позиционируются как «бюджетные» интеграционные решения, оптимально подходящие для поддержки композитных приложений и SOA. Вторая группа — это продукты, предназначенные для рынка Web-сервисов, наконец последние — это программные средства, обеспечивающие поддержку EDA. По оценке Ройя Шульте, на протяжении следующих лет произойдет уплотнение рынка ESB, что объясняется усиливающимся спросом на Web-сервисы и многопротокольные и управляемые событиями решения.
Интересно, что в ряде компаний ESB трактуют не как категорию продуктов, а как архитектуру. Например, в IBM корпоративную сервисную шину считают «архитектурной моделью» (architectural pattern).
Таким образом, можно констатировать, что до сих отсутствует четкое определение, что такое же ESB. Фактически, дискуссия разворачивается вокруг двух вопросов:
- Является ли ESB архитектурой (причем такой, которую не нужно даже стандартизировать), «односторонним подходом» или же самостоятельным продуктом.
На данный момент на обозначенные вопросы нет окончательных ответов.
Вместе с тем стоит подчеркнуть, что несмотря на отсутствие ясности в отношении корпоративной сервисной шины, совершенно очевидно, что благодаря тому, что ESB опирается на открытые стандарты, она позволяет существенно сократить затраты на покупку и реализацию.
Заметим, что слово «сервисная» в термине «корпоративная сервисная шина» является центральным. Так, аналитики Forrester Research рассматривают ESB как «слой промежуточного программного обеспечения, с помощью которого можно получить доступ к набору основных (многократно используемым) бизнес-сервисам». SOA позволяет представить большую часть функциональности как «сервис» в корпоративной сервисной шине, которая переправляет, преобразовывает и проверяет входные и выходные данные в формате XML, получаемые из этих сервисов.
ESB и XML
Было бы несправедливо, если бы мы не подчеркнули особую роль XML — XML является основанием для интеграции. Если принять тот факт, что XML скорее «алфавит», чем просто язык, становится понятным, что для полной реализации интеграции требуется «дирижировать» бизнес-процессами, управлять преобразованием XML, а также проверять и пересылать сообщения XML по организации. Все эти функциональные возможности составляют основу корпоративной сервисной шины.
XML может обеспечить исчерпывающее представление набора данных. Популярность этого языка можно объяснить его высокой гибкостью и расширяемостью. Действительно, синтаксис XML позволяет модернизировать и разрабатывать специализированные XML-схемы для обработки различных данных.
Вместе с тем стремительный рост объемов данных, подлежащих передаче, создает серьезные сложности для функционирования корпоративной информационной структуры. Так, первые интеграционные проекты, в которых использовались возможности XML, явились «живым» доказательством перспективности этого языка, однако сейчас наблюдается определенные проблемы при увеличения количества, размера и сложности XML-документов. Ниже перечислены основные причины существующих сложностей (недостаточной масштабируемости):
- Синтаксический разбор всего документа: как правило, требуется разбирать документы целиком, даже если для маршрутизации и фильтрования необходимо извлечь только его фрагмент. Если документы становятся большими, время ожидания увеличивается.
- Повторное сканирование. Документы часто разбираются повторно — на каждом этапе бизнес-процесса, другими словами, одни и те же документы могут сканироваться несколько раз. Поскольку такая практика чрезвычайно ресурсозатратна, ухудшается производительность и пропускная способность.
Для решения проблемы недостаточной масштабируемости рекомендуется использовать архитектуру обработки, которая поддерживает следующие функции:
- Потоковая передача документов — гарантирует, что XML-документы обрабатываются по мере поступления каждого элемента, т.е. обеспечивается низкое время ожидания. Этот подход позволяет обрабатывать большие сообщения также продуктивно, как и небольшие.
- Выборочная обработка, при которой достигается очень значительное повышение производительности благодаря тому, что обрабатывается только релевантные фрагменты, а не весь XML-документ.
- Многонитевая обработка, при которой процессор управляет выстраиванием последовательных шагов по каналу, параллельным исполнением отдельных шагов и выравниванием нагрузки от идентичных шагов при обработке нескольких фрагментов XML.
- Единственное сканирование, при котором вместо нескольких повторяющихся прочтений структуры одного и того же документа с самого начала за одну передачу извлекаются все необходимые фрагменты.
Приведенные выше функции могут быть реализованы с помощью корпоративной сервисной шины — причем без специального кодирования и конфигурирования.
В чем отличие сервисной шины предприятия(ESB) от брокеров сообщений (например RabbitMQ)?
В результате, можно разрешить проблему неудовлетворительной производительности.
Заключение
Судя по публикациям в зарубежных Интернет-изданиях и оценкам аналитиков ведущих исследовательских компаний, корпоративная сервисная шина уже больше не является просто новой технологией с большим потенциалом. Действительно, по прогнозу Gartner, в 2005 году большинство крупных компаний будут использовать ESB. В IDC же полагают, что корпоративная сервисная шина должна «революционизировать» информационные технологии и сделать возможным гибкую и масштабируемую распределенную обработку данных.
Действительно, поддержка открытых стандартов (и особенно XML) позволяет получить недорогое, но эффективное решение и гарантирует быструю окупаемость инвестиций, т.е высокий показатель ROI. Как отмечает вице-президент Консорциума по интеграции Стив Крэггс (Steve Craggs), «ESB является базисом для интеграции, обеспечивает гибкую и настраиваемую среду, которая позволяет плодотворно, успешно и планомерно реализовывать интеграционные проекты».
И все же неопределенность с многозначностью термина «корпоративная сервисная шина» пока сохраняется. Сегодня ESB означает любую технологию, необходимую для реализации SOA. Именно такой точки зрения придерживаются в компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированная архитектуры. В этой связи аналитики ZapThink предупреждают, что если в 2005 году не будет выработано реального и конкретного определения корпоративной сервисной шины, термин ESB «навсегда уйдет из лексикона SOA». Что касается же самой SOA, то о ней речь пойдет в следующей статье.
Публикации
- Бесс Голд-Бернштейн (Beth Gold-Bernstein) «Нужна ли вам корпоративная сервисная шина» (Is an ESB Critical To Your Future?).
- Найджел Томас (Nigel Thomas) и Уоррен Бакли (Warren Buckley) «Появление корпоративной сервисной шины» (Rise of the ESB).
- Материалы, опубликованные на сайте Консорциума по интеграции (Integration Consortium).
Что такое ESB и SOA¶
An excellent description of system-of-systems thinking
Nick Coghlan, Core Python DeveloperAlso available in Català, Deutsch, English, Français, italiano, Nederlands, Português, Türkçe and 中文.
Аббревиатура ESB и связанная с ней SOA — могут стать причиной путаницы. ESB расшифровывается как Enterprise Service Bus. SOA — Service Oriented Architecture.
Эти названия мало о чем говорят, поэтому далее приведена более полная информация простым языком, без излишней корпоративной лексики.
Вся правда¶
Давайте представим, что происходит, когда Вы входите в фронтенд-приложение Вашего банка:
- Показывается Ваше имя
- Отображается баланс Вашего счета
- Показываются Ваши кредитные и дебетовые карты
- Там может быть список Ваших паевых инвестиционных фондов
- Вы также получаете список предварительно рассчитанных ссуд, в которых Вы можете быть заинтересованы
С большой долей вероятности можно сказать, что все эти кусочки информации принадлежат к разным системам и приложениям, каждое из которых предоставляет данные через какой-то интерфейс (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV или любой другой):
- из CRM, работающей под управлением Linux и Oracle
- из COBOL системы, работающей на z/OS мейнфрейме
- говорят, эта информация поступила из системы на мейнфрейме, но эти ребята слишком молчаливы, чтобы сказать что-то кроме того, что они предпочитают CSV всему остальному
- из смеси PHP и Ruby, работающих на Windows
- из PostgreSQL, Python и Java, работающих на Linux и Solaris
Вопрос состоит в том, как Вы можете заставить фронтенд-приложение общаться с системами 1-5? Ну, никак.
Это фундаментальная основа для уверенности в том, что такие окружения могут масштабироваться за пределы нескольких систем. Вы не заставляете их общаться напрямую друг с другом.
В схеме, представленной ниже, каждое обращение к сервису, который предоставлен другой системой, показано линией с разной толщиной и стилем:
Заметьте, мы даже не показали ни одного высокоуровневого процесса (App1 вызывает App2 и либо App3, либо App5, в зависимости от того, был ли предыдущий ответ от App6 успешным, для того, чтобы App4 могло позже взять данные, которые были сгенерированы App2, но только если App1 не запрещает этого и т. д.).
Также, заметьте, мы не говорим о серверах — каждая из систем может работать на 10 физических серверах, так что как минимум 60 физических компонентов будут обмениваться информацией друг с другом.
Тем не менее, некоторые вопросы становятся очевидными.
Как разделить интерфейсы? Как планировать выгрузку? Как скоординировать обновления или запланированный простой, если каждое приложение управляется разными командами разработчиков, вендоров или отделов и половина исходных разработчиков уже покинула компанию?
Если Вы думаете, что можете управлять 6-ю приложениями, как на счет 30?
А сможете справиться с 400? А с 2000? Каждое приложение может быть своей уникальной экосистемой, требующей десятка серверов или других устройств для работы, так что это — 20 000 движущихся частей, распределенных по континентам с всяческими техническими и культурными границами. И все эти части постоянно и без остановки хотят обмениваться сообщениями все время без каких бы то ни было простоев, вообще. (Мы избавим Вас от схемы.)
Есть отличное название для такой ситуации — беспорядок.
Как Вы можете исправить ситуацию?¶
Первым делом стоит признать, что ситуация вышла из-под контроля. Это позволяет искать решение без ощущения сильного чувства вины. Хорошо, это произошло, Вы не знали, как сделать лучше, но есть шанс, что все это можно исправить.
Это может принести за собой организационные изменения в подходе к IT, но иной шаг — это вспомнить, что системы и приложения созданы не просто для обмена данными. Они созданы для поддержки бизнес-процессов, вне зависимости от самого бизнеса, будь это банковская сфера, аудио записи, радиолокационные устройства, что угодно.
Когда Вы четко определите для себя эти два пункта, Вы сможете начать проектирование или редизайн Ваших систем вокруг сервисов.
Сервис — это что-то интересное, многократно используемое и атомарное, что предоставляется одной системой другим приложениям, которые хотят использовать его, но, при этом, сервис никогда не выставлен напрямую в режиме один к одному. Это самое короткое и осмысленное описание из всех возможных.
Если данная функциональность системы удовлетворяет этим трем требованиям:
- I nteresting (интересная)
- R eusable (многократного использования)
- A tomic (атомарная)
тогда велик шанс, что система может и должна быть представлена другим системам как сервис, но никогда не соединяться напрямую.
Давайте обсудим подход IRA на нескольких примерах.
- Заставить получать произвольные даты начала и конца периода, вместо указания только квартала.
- Заставить получать произвольные приложения, не только портал. Дать возможность указывать приложение для получения информации в качестве входного параметра.
- Разделить на несколько меньших частей. Подумайте, что описывает покупателя — у них есть адреса, телефоны, любимые продукты, предпочтительные методы связи с ними и так далее. Каждый из этих пунктов должен быть превращен в независимый сервис.
- Используйте ESB для создания составных сервисов из атомарных.
Если Вы хотя бы немного программировали за последние 50 лет, Вам станет очевиднo, что предоставление сервиса аналогично предоставлению API в одной части кода для другой. Единственная разница в том, что Вы имеете дело не с подмодулями одной системы, Вы работаете на уровне целого окружения отдельных систем.
Доступность сервисов в ESB и SOA¶
Сейчас, когда Вы знаете, что системы не обмениваются информацией напрямую и Вы понимаете, что такое сервис, Вы можете начать эффективно использовать ESB.
Теперь это работа ESB — предоставлять и вызывать сервисы интегрированных систем. Таким образом в большинстве случаев только один метод доступа, один интерфейс должен быть определен между каждой системой и ESB.
Так что, если, как в схеме вверху, у Вас 8 систем — тогда у Вас 16 интерфейсов (по одному в каждое направление) для создания, обслуживания, управления и обеспечения.
Без ESB у Вас было бы 56 интерфейсов для создания и управления (допуская, что каждая система общается с любой другой).
Отсутствие дополнительных 40 интерфейсов означает меньше потерь времени и больше сэкономленных денег. Это одна из причин, по которой Ваши пятницы будут менее напряженными.
Один этот факт должен побудить Вас рассмотреть внедрение ESB.
Если одна из систем будет переписана, передана другому владельцу, разделена между отделами или вендорами, то это будет задача ESB-ребят произвести соответствующие изменения. Ни одна из других систем даже не заметит этого, так как их интерфейс с ESB будет не тронут.
Когда Вы станете “дышать” IRA-сервисами на регулярной основе, Вы сможете начать думать о составных сервисах.
Помните сервис “дайте-мне-все-что-можете-про-этого-клиента”, представленный выше?
Создавать его не было хорошей идеей, но Вам иногда придется сталкиваться с клиентскими приложениями, которые должны будут агрегировать информацию. Ответственными за это будут ESB-ребята, задачей которых будет выбор лучших атомарных сервисов для построения составного сервиса для этой конкретной клиентской системы, требующей конкретно этот набор составных данных.
Со временем вся организация начнет понимать, что речь уже больше не о таблицах баз данных, файлах, пакетах, функциях, подпрограммах или записях. Теперь речь об архитектуре, сконцентрированной вокруг интересных, многократно используемых и атомарных сервисах, предоставляемых приложениями для ESB.
Люди больше не будут думать, что приложения и системы посылают сообщения друг другу. Они будут видеть ESB как универсальный шлюз доступа к интересным сервисам, которые их же системы могут использовать. И они даже не будут проверять кто и что предоставляет, их системы будут иметь дело только с ESB.
Это потребует времени, терпения и скоординированных усилий, но это вполне выполнимо.
Но берегитесь…¶
Самый лучший способ уничтожить всю концепцию SOA — развернуть ESB и ожидать, что проблемы самоустранятся. Будучи великолепной идеей, просто развернуть ESB будет мало, к сожалению.
В лучшем случае попытка спрятать что-то под ковер, как в схеме внизу, не приведет ни к чему:
Ваши IT-ребята будут ненавидеть систему и, хоть поначалу менеджеры будут терпеть ESB в качестве нового решения, впоследствии оно станет посмешищем. “Что, это та самая новая серебряная пуля? Хахаха.”
Такие последствия неизбежны, если ESB не является частью большего плана по развитию.
Так, получается, ESB только для банков и подобных им?¶
Совсем нет. Это хорошее решение в любой ситуации, которая требует слаженной работы нескольких источников данных и нескольких методов доступа для достижения интересного результата.
К примеру, задача сбора последних показаний с термодатчика и публикация их в нескольких каналах, таких как имейл-оповещения и IPhone-приложения, хорошо подходит для интеграционной платформы.
Периодическая проверка и мониторинг работы всех экземпляров критического приложения и, если не все из них работают, запуск сконфигурированного скрипта и отправка текстового сообщения администраторам, так же отлично подходит.
Все, что требует интеграции в понятном, четко определенном окружении, вполне вероятно хорошо подходит для ESB сервиса. Но, как всегда, решение о том, действительно ли что-то подходит для интеграции приходит с опытом.
корпоративная сервисная шина
Само собой, команда Zato может помочь.
Но я слышал, что SOA это XML, SOAP и веб сервисы¶
Да, некоторые люди хотели бы, чтобы вы верили именно в это.
Если люди или вендоры, с которыми Вы работали, отправляли закодированный в BASE64 CSV-файл в защищенном посредством SAML2 SOAP-сообщении, тогда вполне понятно, откуда у Вас сложилось такое впечатление.
XML, SOAP и веб сервисы — имеют свои сценарии использования, но как и все — они могут быть неправильно использованы.
SOA — о понятной и управляемой архитектуре. То, что какой-то сервис может использовать или не использовать SOAP практически не важно. SOA, как подход к архитектуре, будет все еще верным, даже если никакой SOAP сервис не будет использован вовсе.
Если архитектор проектирует прекрасное здание, он не может слишком сильно повлиять на цвет интерьера.
Так что нет, SOA — это не XML, SOAP и веб сервисы. Они могут быть использованы, но они лишь часть, а не основа.
Вы можете отсылать заблудившихся коллег к этой статье, чтобы они разобрались, что же такое SOA.
Дальше — больше¶
Эта глава покрывает только самые основы, но тем не менее должна дать четкое понимание как должны выглядеть ESB и SOA и что требуется для достижения успеха.
Другие темы, не затронутые здесь, включают (но не ограничены):
- Как получить поддержку от менеджеров для введения ESB
- Как собрать SOA-архитекторов и аналитические команды
- Представление канонической модели данных (Canonical Data Model — CDM) в организации
- Ключевые показатели эффективности (Key Performance Indicators — KPI) — теперь, когда у Вас есть общий и унифицированный метод предоставления сервисов между системами, Вы должны начать наблюдать и анализировать, что на самом деле Вам предоставляется
- Управление бизнес-процессами (Business Process Management — BPM) — как и когда выбрать BPM-платформу для управления сервисами (ответ — не слишком скоро, сначала познакомьтесь с тем, как строить приятные и полезные сервисы)
- Что делать с системами без API? К примеру, должна ли ESB получить прямой доступ к их базам данных (ответ — по разному, золотого правила нет)
Так что же такое Zato?¶
Zato — ESB и сервер приложений, написанный с использованием Python и может быть использован для построения промежуточных и бэкенд-систем. Это программное обеспечение с открытым исходным кодом с коммерческой поддержкой и поддержкой сообщества. И Python — язык программирования, известный своей простотой и эффективностью.
Использование Python и Zato позволяет увеличить производительность и тратить меньше времени впустую.
Zato был написан прагматиками для прагматиков. Это не еще одна наспех сооруженная вендором система на волне ESB/SOA шумихи.
На самом деле, Zato был построен исходя из практического опыта “тушения пожаров”, вызванных такими системами. В самом деле, авторы Zato провели настолько много времени в борьбе с такими окружениями, что они стали практически невосприимчивыми к любым пожарам.
Это кузница, из которой Zato вышел в мир и поэтому он может предложить производительность и простоту использования, которых нет в других похожих решениях.
Увидимся в здесь!
Корпоративная сервисная шина данных DATAREON ESB (Enterprise Service Bus) предназначена для построения распределённого информационного ландшафта предприятия. Программный продукт обеспечивает взаимодействие всех интегрируемых приложений в одном центре, объединяя существующие источники информации и предоставляя централизованный обмен данными между разными информационными системами.
Корпоративная сервисная шина данных DATAREON ESB является эффективным средством обеспечения стабильности и полноты информационного обмена, повышения общей производительности информационной системы и сокращения трудозатрат на ее администрирование.
Сервисная шина предприятия
Программный продукт DATAREON ESB официально включен в единый реестр российских программ для электронных вычислительных машин и баз данных, которые могут закупаться государственными и муниципальными учреждениями ( https://reestr.minsvyaz.ru/).
Для интеграции 2-3 информационных систем в небольших компаниях DATAREON предлагает программный продукт, созданный на базе DATAREON ESB — DATAREON MQ.
Функциональные возможности DATAREON ESB
Задачи, решаемые с помощью корпоративной сервисной шины данных
- Передача данных между различными информационными системами (с маршрутизацией или «точка-точка»)
- Формирование единого информационного пространства в гетерогенных средах
- Построение распределённой системы на основании событийной модели в следующих вариантах:
- построение приложений со сквозными бизнес-процессами на основании событийной модели;
- создание системы с синхронизацией бизнес-приложений в различных информационных системах
Преимущества корпоративной сервисной шины данных DATAREON ESB
- Быстрая интеграция
- Высокая надежность
- Возможность многократного использования ресурсов
Функциональные возможности
Цены и лицензионная политика
Техническая поддержка и сопровождение
Сравнительный пример интеграцииМенеджеры DATAREON будут рады ответить на все вопросы по тел. +7(495)280-08-01. Также вы можете написать нам через форму обратной связи.
Корпоративная сервисная шина DATAREON ESB.
Зачем разработчикам нужна Enterprise Service Bus?
Назначение классов и маршрутов передачи данных. Урок 4
DATAREON · 43 Просмотры
Интеграционная шина данных DATAREON ESB — программный продукт, разработанный компанией DATAREON.
Решение предназначено для построения распределенного информационного ландшафта предприятия и обеспечивает взаимодействие всех интегрируемых приложений в одном центре.Урок 4 посвящен работе с объектами "Класс информационных пакетов" и "Маршруты передачи данных", настройке интеграции номенклатуры и сегментации потоков данных.
Сервисная шина данных DATAREON ESB построена на компонентной архитектуре со слабыми связями, где интегрируемые системы работают независимо друг от друга, а для обработки сообщений не требуется сведения об источниках или получателях сообщений.
Для обеспечения такого алгоритма работы все передаваемые данные должны отвечать общим требованиям и правилам, вне зависимости от системы-источника или приемника.
Для типизации и описания структуры сообщений вводятся классы информационных пакетов.
Маршруты используются для определения получателей сообщения, а также для сегментации потоков данных.