что такое спорадическая передача данных
Форум АСУТП
Клуб специалистов в области промышленной автоматизации
МЭК 104 и исходящее TCP-соединение
МЭК 104 и исходящее TCP-соединение
Сообщение svtnp » 15 фев 2018, 12:28
МЭК 104 и исходящее TCP-соединение
Сообщение hell_boy » 15 фев 2018, 21:32
МЭК 104 и исходящее TCP-соединение
Сообщение svtnp » 16 фев 2018, 08:43
МЭК 104 и исходящее TCP-соединение
Сообщение hell_boy » 16 фев 2018, 10:06
МЭК 104 и исходящее TCP-соединение
Сообщение checker » 16 фев 2018, 10:12
Это неверно. Как правило, МСЭ защищает от попыток _установить_ соединение, но разрешает передавать данные в _уже_ установленном соединении. Пример: домашний интернет через роутер. Роутер разрешает браузеру с домашнего компьютера установить соединение с сайтом и пропускает ответ от сайта. Но с сайта подсоединиться к компьютеру уже никто может.
Отправлено спустя 1 час 7 минут 54 секунды:
Не вводите людей в заблуждение.
По определению, спорадическая передача – передача данных, инициируемая процессом пользователя при возникновении событий или изменений данных. В контексте МЭК 101/104 это означает только то, что сервер посылает клиенту свои данные не постоянно, а по мере изменения. Используется для экономии трафика.
Балансный обмен сложнее в реализации. Используется в основном для 101 протокола, от безисходности, когда есть всего одна RTU линия, а данные гонять надо в обе стороны.
Что такое спорадическая передача данных
Релейная защита • МЭК 61850Стандарт МЭК 61850 принят большинством производителей устройств РЗА и систем учета и за рубежом, и в России. Сегодня важно, чтобы принципы, заложенные в стандарт, одинаково понимались как разработчиками, производителями устройств РЗА, так и специалистами проектных, монтажных, наладочных и эксплуатационных организаций.
ПРОТОКОЛЫ СВЯЗИ В ЭЛЕКТРОЭНЕРГЕТИКЕ |
Параметр | Протокол | ||
Modbus | МЭК-101/103/104 | DNP3 | |
Линии связи | RS-232/485/422 TCP/IP (Modbus TCP) | RS-232/485/422 TCP/IP (104) | RS-232/485/422 TCP/IP |
Архитектура | Клиент – сервер | Клиент – сервер | Клиент – сервер |
Принцип передачи данных | Обмен индексированными точками данных | ||
Спорадическая передача данных | Нет | Да | Да |
Семантическая модель данных | Нет | Нет Базовая (103) | Да |
Передача данных в режиме реального времени | Нет | Нет | Нет |
ВЫВОДЫ ПО ПРОТОКОЛАМ
Из представленного краткого анализа видно, что существующие протоколы связи достаточно успешно позволяют реализовывать задачи диспетчерского управления / интеграции данных в системы управления, однако не позволяют реализовывать функции реального времени (такие как передача дискретных сигналов между устройствами РЗА, передача мгновенных значений токов и напряжений).
Большое количество проприетарных протоколов приводит к усложнению процесса интеграции устройств в единую систему:
При передаче данных по-прежнему применяется большое количество последовательных интерфейсов, что накладывает ограничения на скорость передачи данных, объем передаваемых данных и количество устройств, одновременно включенных в информационную сеть.
Передача ответственных команд управления (команды отключения выключателей от РЗА, оперативные блокировки и т.п.) и оцифрованных мгновенных значений токов и напряжений невозможна в цифровом формате в силу непригодности существующих протоколов связи для передачи подобного рода информации.
Следует отметить, что существующие протоколы связи не предъявляют требований к формальному описанию конфигураций протоколов и передаваемых сигналов, в связи с чем проектная документация на системы АСТУ содержит лишь описание сигналов на твердых носителях.
ОСНОВНЫЕ ПОЛОЖЕНИЯ ПРИ СОЗДАНИИ МЭК 61850
Работа над стандартом МЭК 61850 началась в 1995 году, причем изначально велась двумя независимыми, параллельно работающими группами [5]: одна из них, образованная UCA*, занималась разработкой общих объектных моделей подстанционного оборудования (GOMFSE); вторая, образованная в рамках технического комитета 57 МЭК, занималась созданием стандарта на протокол передачи данных для подстанций.
Позднее, в 1997 году, работы обеих групп были объединены под эгидой рабочей группы 10 ТК 57 МЭК и вошли в основу стандарта МЭК 61850.
В основе стандарта лежат три положения:
Разработка первой редакции стандарта заняла порядка 10 лет. Отвечая поставленным требованиям, стандарт позволяет соответствовать изменяющимся потребностям электроэнергетики и использовать последние достижения в области компьютерных, коммуникационных и измерительных технологий.
На сегодняшний день МЭК 61850 состоит из 25 различных документов (в том числе разрабатываемых), которые охватывают широкий круг вопросов и делают его гораздо больше, чем просто спецификацией ряда коммуникационных протоколов. Отметим основные особенности стандарта [6]:
Работая с МЭК 61850, необходимо понимать, что стандарт:
Безусловно, такая масштабная работа не может быть идеальной. В качестве примеров неточностей и недоработок стандарта, в частности, называется отсутствие методик формальной проверки соответствия требованиям стандарта, ряд технических неточностей в описании параметров и подходов к их обработке и так далее. Более подробно эти вопросы будут рассмотрены в дальнейших публикациях.
К недостаткам стандарта часто относят неконкретность описания требований и слишком большую свободу при реализации, что, по мнению разработчиков, как раз является одним из его главных достоинств.
UCA – некоммерческая организация, основной деятельностью которой является поддержка пользователей во внедрении стандартов передачи данных реального времени. В настоящее время UCA не занимается разработкой стандартов, однако активно взаимодействует с органами по стандартизации.
ЛИТЕРАТУРА
© ЗАО «Новости Электротехники»
Использование материалов сайта возможно только с письменного разрешения редакции
При цитировании материалов гиперссылка на сайт с указанием автора обязательна
Становление стандартов передачи телемеханических данных в электроэнергетике (МЭК 101/104) — особенности разработки
Здравствуйте! Меня зовут Юрий.
Преамбула
Проработав несколько лет в энергетической отрасли в теме организации передачи данных, хочу поделиться с сообществом полученными знаниями, в том числе тем, «как это было».
Сразу оговорюсь, что в тексте будут даны названия компаний и продуктов, которые на рынке уже давно, так что рассматривать это как рекламу я бы не стал. Также хочу отметить, что все сроки, связанные с «неразглашением конфиденциальной информации» давно уже прошли, что позволяет мне делиться полученной в процессе работы информацией. Какие-то конкретные фамилии «ответственных за» называться не будут, т.к. все они в той или иной степени развивали это направление.
Ссылки в статье даны для тех, кто желает погрузиться в тему немного глубже.
Как все начиналось
Немного о 603-ем приказе
Полное название документа: О приведении систем телемеханики и связи на генерирующих предприятиях электроэнергетики, входящих в состав холдинга ОАО РАО «ЕЭС России», в соответствие с требованиями балансирующего рынка, Приказ № 603 от 09.09.2005 ОАО РАО «ЕЭС России».
Спорные моменты протокола МЭК
Есть несколько нюансов, которые никак нельзя трактовать однозначно.
Метка времени в формате UTC
В зарубежной реализации протокола сказано, что рекомендуется использовать метку времени в формате UTC. Парадоксально, но для Российской редакции этого документа для нашей много-часовопоясной страны эта сточка отсутствует, хотя она могла бы решить огромное количество проблем, связанных с передачей данных из одного часового пояса в другой!
Отсутствие часовых поясов
В 7-ми байтной метке времени есть большое количество свободного пространства, которое позволяет задать текущий часовой пояс, если уж возникла такая необходимость.
Возможность расширения
Как показала практика применения данного протокола, из всего набора определенных в нем типов кадров реально применяется процентов 20, максимум. Но в самом начале его использования отечественные разработчики постарались использовать кадры, зарезервированные под дальнейшее расширение. Это к вопросу о процессе «развития» протокола.
Немного о продуктах того периода и их возможностях
В связи с тем, что энергетика — это достаточно денежная отрасль, к «кормушке» старались попасть большое количество фирм со своими продуктами или услугами. Соответственно, по распространенности того или иного продукта можно судить насколько близко договорились между собой представители власти и представители того или иного бизнеса.
К счастью, в случае если эти договоренности так или иначе сопровождал какой-то продукт на первом этапе не самого лучшего качества, постепенно он доводился до ума, модернизировался и сейчас уже можно сказать является надежным и не заменимым. Но про сложности этапа внедрения, связанные с «сыростью» и не согласованностью решений между различными участниками все-таки помнить следует.
О косяках особенностях в реализации
Прим.: В связи с тем, что на тот момент моя работа в компании была непосредственно связана с тестированием оборудования тех или иных производителей для выдачи разрешительных документов на внедрение этих систем на объектах сдаваемых ОАО «СО ЕЭС», разработчиков я видел достаточно много, с некоторыми из которых я до сих пор поддерживаю хорошие отношения.
Основные особенности в реализации протоколов были связаны с непониманием процедурной части реализации протоколов. Т.к. МЭК раздел 870-5 регламентирует только форматы передаваемых данных, часть производителей подразумевала, что можно тупо эти данные слать, не выполняя никаких процедур, связанных с установкой соединения на канальном уровне. За процедурную часть отвечал раздел МЭК 870-6, на который почему-то никто из «законодателей» не обращал внимания. Тем не менее, имея в запасе прекрасно сформулированное Норвежское соглашение, со всеми его диаграммами и вычеркнутыми частями, всем производителям удалось придти к какому-то единому пониманию того, как должен строится обмен.
Насколько я знаю, сейчас процедура проверки совместимости протоколов уже не проводится, т.к. все, кто был на этом рынке уже свои реализации протоколов МЭК за эти годы успели отладить, а те, кто не успел — просто покинули рынок (есть и такие компании).
Особенности и преимущества протокола МЭК 101
По сравнению с протоколом Modbus RTU протокол МЭК 101 имеет следующие преимущества и особенности:
– разными структурами блоков данных;
– разными форматами данных;
Спорадическая передача – передавать данные только когда это необходимо
Возможность установки апертур для каждого параметра позволяет управлять объемом передаваемых данных для формирования оптимального трафика передачи.
Спорадический метод передачи может быть реализован одним из следующих способов:
1. Передача только последних значений измеренных параметра на момент формирования кадра. В этом случае происходит потеря измеренных значений при быстром их изменении.
2. Использование очереди изменившихся значений измеренных параметров. Может привести к увеличению динамической ошибки за счёт необходимости передачи всех изменений параметров. Метод также трудно реализуем программно.
В ПИМ ЕТ реализован спорадический метод передачи путем передачи последнего значения измеренного параметра на момент формирования кадра (способ 1). При этом значение измеренного параметра будет передаваться только в случае, если оно превысило значение ранее переданного на величину, превышающую значение апертуры для данного параметра.
Таким образом, при незначительном изменении измеряемых параметров, их значения не передаются. Правильный выбор апертур позволяет минимум в 6 раз уменьшить объём передаваемых с ПИМ ЕТ телеизмерений.
Это делает протокол МЭК 101 в разы «легче», чем Modbus.
То есть за 1 сек можно передать (считать) информацию с большего количества ЕТ по протоколу МЭК 101, чем по Modbus.
Широкий выбор блоков данных прикладного уровня (ASDU)
В базовой комплектации ПИМ ЕТ имеет протокол МЭК 870-5-101 и программные часы реального времени (RTC).
Это дало возможность реализации в приборе различных блоков данных прикладного уровня (ASDU).
RTC позволяют присваивать измеренным параметрам метки времени с дискретностью 1 мсек на уровне преобразователя.
1. Структуры блоков данных
В структуре-2 все измеренные параметры представляют собой один объект, который имеет единый адрес (2 байта) независимо от количества измеренных параметров, и единую метку времени на все параметры.
ПИМ поддерживает передачу как стандартных (в рамках стандарта МЭК), так и новых (нестандартизованных) типов ASDU, рекомендованных отраслевым стандартом СО 34.48.160-2004 «Унифицированные протоколы информационного обмена. Общие технические требования».
Стандартные ASDU: 9, 10, 11, 12, 13, 14, 21, 34, 35, 36.
Новые ASDU: 143, 144, 145.
Основное отличие новых ASDU от стандартизованных в том, что есть возможность использовать структуру-2 с меткой времени. В то время как в стандартизованных ASDU предусматривалась метка времени только для структуры-1.
Реализованные в ПИМ ЕТ ASDU 143, 144, 145 очень существенно укорачивают длину передаваемого пакета. Например, при 10 передаваемых параметрах с 7-байтной меткой времени длина пакета будет короче на 63 байта за счёт единой метки времени и на 19 байтов за счёт единого адреса по сравнению с ASDU 34, 35, 36.
2. Описатель качества
Описатель качества – это специальный байт, содержащий набор атрибутов, которые несут следующую информацию:
– для Ua, Ub, Uc, Ia, Ib, Ic, Uab, Ubc, Uca рабочий диапазон – 0…1,2*Uном (0…6000 ед.);
– для ПИМ с питанием от измерительной сети рабочий диапазон Uab, Ubc, Uca — от 0,8*Uном до +1,2*Uном (от 4000 до 6000 ед.);
– для F — это диапазон от 45 до 55 Гц (4500…5500 ед).
О режиме «замещения» подробнее можно прочитать в статье>>
Все указанные биты можно сделать не активными (устанавливаются равными 0) с помощью программы конфигурации «EMaster Net».
3. Форматы передаваемых данных
Формат масштабированных значений ( 2 байта) – самый универсальный. Применяется для передачи всех электрических параметров – тока, напряжения, мощности, частоты. Рекомендуется для всех способов передачи – спорадической, циклической, периодической, по запросу. Диапазон представления значений измеренных параметров в ПИМ ЕТ ±6000 единиц. Для частоты от 45 000 до 55 000.
Достоинства формата – длина всего 2 байта. Недостаток – требует введения дополнительных коэффициентов для представления измеренных значений в их физических единицах.
Рекомендуется применять при спорадическом методе передачи (причина передачи — 3), при выполнении функции «Общий опрос» (причина передачи — 20, 21, 22) и при выполнении функции «Запрос данных» (причина передачи — 5).
Достоинство формата – возможность представления измеренных величин в их физических единицах в самом преобразователе ЕТ, который учитывает коэффициенты трансформации по току и напряжению.
Недостаток – длина 4 байта.
4. Метки времени
В ПИМ ЕТ в протоколе МЭК 101 реализованы разнообразные типы ASDU по признаку наличия или отсутствия в них метки времени.
Метка времени может отсутствовать, а может иметь короткий формат СР24Время2А (3 байта) или длинный формат СР56Время 2а (7 байт).
Формат метки времени 3-х байтный содержит информацию о миллисекундах, секундах и минутах измеренного параметра.
Метка времени в 7-и байтном формате содержит полную информацию, включая дополнительно к 3-х байтной метке времени информацию о часах, днях недели, днях месяца и годе.
Достоинство 3-х байтной метки времени в том, что для её передачи в УСД или КП ТМ требуется меньше времени.
А при ограниченности времени опроса (1 сек) и длине кадра (255 байт) при использовании 3-х байтной метки времени можно:
– опросить больше ЕТ за 1 сек;
– передать больше измеренных параметров в кадре;
– больше ЕТ подключить на один шлейф.
Недостаток 3-х байтной метки времени в необходимости восстановления полного времени измеренного параметра в УСД или КП ТМ.
Достоинство 7-и байтной метки времени в том, что она содержит полную информацию о времени измерения.
Недостаток 7-и байтной метки времени – требует больше времени на опрос ЕТ и уменьшает:
– допустимое количество передаваемых в кадре измеренных измеренных параметров в кадре;
– количество ПИМ ЕТ, подключаемых на один шлейф.
Все характеристики ASDU, реализованныых в ПИМ ЕТ, приведены в таблице.