Как стать автором
Обновить

Становление стандартов передачи телемеханических данных в электроэнергетике (МЭК 101/104) — особенности разработки

Время на прочтение 6 мин
Количество просмотров 28K
Здравствуйте! Меня зовут Юрий.

Преамбула

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


Для краткости я введу некоторые сокращения:
  • МЭК -протоколы по ГОСТ Р МЭК 60870-5-101/104
  • МЭК 101, 101-ый — протокол по ГОСТ Р МЭК 60870-5-101
  • МЭК 104, 104-ый — протокол по ГОСТ Р МЭК 60870-5-104


Как все начиналось


Повышение требований к информационным системам в современной Энергетике России привело к развитию средств и технологий передачи данных. В энергетики это направление называется телемеханика. В качестве основы передачи телемеханической информации был взят стек протоколов IEC 870-5-101 и в 2001 году появился его отечественный перевод ГОСТ Р МЭК 870-5-101.
Для его локализации было несколько причин:
  1. на тот момент «развелось» огромное количество разновидностей реализаций протоколов передачи данных и весь этот «зоопарк» все сложнее и сложнее было как-то упорядочивать;
  2. у всех существующих протоколов было большое количество ограничений, по емкости передаваемых данных, по типу передаваемых данных, отсутствовали средства диагностики качества передаваемых данных, не было возможности для расширения и пр.;
  3. на наш рынок постепенно начали приходить зарубежные поставщики решений и оборудования, где процесс стандартизации уже давно шел.


В 2004 году был переведен IEC 60870-5-104 получивший название ГОСТ Р МЭК 60870-5-104-2004. Параллельно этому в ОАО РАО «ЕЭС России» был выпущен знаменитый 603-й приказ, который бросились исполнять практически все производители оборудования для передачи телемеханической информации. К счастью, процесс «развития» «Российского МЭК» очень быстро был переведен к процессу стандартизации казалось бы и без того «стандартного» ГОСТ-а. Я не просто сформулировал про «счастье», т.к. некоторые производители к моменту выпуска дополнительных регламентирующих и уточняющих отраслевых документа все же успели «отличиться». Но об этом позже.
Начиная с 2004 года в ОАО «СО ЕЭС» была принята эталонная модель построения комплексов для диспетчерских центров филиалов этой структуры. В соответствии с данной моделью, которая действует до сих пор, в качестве системы верхнего уровня (SCADA) был принят ОИК СК-2000 (а позже 2003 и 2007) производства ЗАО «Монитор Электрик», а в качестве системы сбора данных использовался ЦППС «SMART-FEP» производства ЗАО «РТСофт», который являлся средством сбора данных телемеханики из различных протоколов и передавал всю собранную информацию в ОИК по протоколу МЭК 104.
После широкомасштабного развертывания данных комплексов и начала подключения к ним большого числа объектов с новыми или модернизированными устройствами телемеханики возникла проблема согласования технических решений, которые были основаны на принятом ГОСТ-е. Казалось бы, что ГОСТ должен однозначно определять как и что делать. Но в данном случае он предоставлял разработчикам набор возможностей, которые они могли реализоввывать по разному, в соответствии с их пониманием этого стандарта. При этом каждый говорил «У нас все в соответствии с МЭК!» и был по своему прав. В определенный момент, к 2007 году, центральному заказчику этих систем, СО ЕЭС, такая ситуация надоела, и было принято решение о необходимости приведения процедуры тестирования совместимости протоколов, выполнять которую должен был РТСофт, т.к. он являлся поставщиком ЦППС.
Фактически в этот период было только два основополагающих документа на русском языке — это МЭК 101 и МЭК 104. Позже, в 2006 году 101 протоколы был переиздан и получил более четкую и конкретную структуру с исключением части функций, которые в реальной жизни не пригодились. Многим разработчикам ПО этой информации не хватало и они старались найти ее зарубежных источниках. Одним из таких документов стало отлично проработанное «норвежское соглашение» — этот документ был принят в Норвегии еще в 2000 г. В нем подробно распысывались не только форматы кадров, но и были приведены диаграммы последовательностей выполнения процедур обмена, установки соединения и пр., с проработкой не только положительного выполнения операций но и описанием исключений. Де-факто этот документ стал основой в реализации МЭК 101 во всех системах, которые сейчас производятся в России.
В 2008 году СО ЕЭС был запущен проект (реализацией занималась ЗАО «ЭНИТА») подготовки методических рекомендаций для разработчиков систем телемеханики, создание проверку которых осуществлял Филиал ОАО «СО ЕЭС» — ОДУ «Урала», Филиал ОАО «СО ЕЭС» — ОДУ «Юга» и ВНИИЭ.
Результатом этир разработок стали два подробных фундаментальных документа, которые однозначно определили как необходимо строить свои решения разработчикам ПО и проектировщикам систем:

Как мне кажется — это один из немногих примеров эвалюционного подхода в развитии систем с положительным исходом.

Немного о 603-ем приказе


Полное название документа: О приведении систем телемеханики и связи на генерирующих предприятиях электроэнергетики, входящих в состав холдинга ОАО РАО «ЕЭС России», в соответствие с требованиями балансирующего рынка, Приказ № 603 от 09.09.2005 ОАО РАО «ЕЭС России».

Основными требованиями 603 приказа в части систем телемеханики стало:
  • определение требований к каналам связи (цифровые выделенные, минимум 64 кБит., резервирование);
  • установка лимитов времени на передачу оперативной ифнормации (ТС — 5 сек., ТИ — 1 сек.);
  • организация прямых каналов связи до объектов управления (РДУ, ОДУ, ЦДУ).

Сроки, как всегда в России, ставились не реальные — все реформу (3 этап) нужно было завершить к 01.09.2007, т.е. за 2 года требовалось переделать всю телеметрию по всей России.
Прим.: До сих пор на большей части России каналы связи работают на старых протоколах и низких скоростях, но для вновь создаваемых систем требования в обязательном порядке выполняются.

Спорные моменты протокола МЭК


Есть несколько нюансов, которые никак нельзя трактовать однозначно.

Метка времени в формате UTC

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

Отсутствие часовых поясов

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

Возможность расширения

Как показала практика применения данного протокола, из всего набора определенных в нем типов кадров реально применяется процентов 20, максимум. Но в самом начале его использования отечественные разработчики постарались использовать кадры, зарезервированные под дальнейшее расширение. Это к вопросу о процессе «развития» протокола.

Немного о продуктах того периода и их возможностях


В связи с тем, что энергетика — это достаточно денежная отрасль, к «кормушке» старались попасть большое количество фирм со своими продуктами или услугами. Соответственно, по распространенности того или иного продукта можно судить насколько близко договорились между собой представители власти и представители того или иного бизнеса.
К счастью, в случае если эти договоренности так или иначе сопровождал какой-то продукт на первом этапе не самого лучшего качества, постепенно он доводился до ума, модернизировался и сейчас уже можно сказать является надежным и не заменимым. Но про сложности этапа внедрения, связанные с «сыростью» и не согласованностью решений между различными участниками все-таки помнить следует.

О косяках особенностях в реализации


Прим.: В связи с тем, что на тот момент моя работа в компании была непосредственно связана с тестированием оборудования тех или иных производителей для выдачи разрешительных документов на внедрение этих систем на объектах сдаваемых ОАО «СО ЕЭС», разработчиков я видел достаточно много, с некоторыми из которых я до сих пор поддерживаю хорошие отношения.
Основные особенности в реализации протоколов были связаны с непониманием процедурной части реализации протоколов. Т.к. МЭК раздел 870-5 регламентирует только форматы передаваемых данных, часть производителей подразумевала, что можно тупо эти данные слать, не выполняя никаких процедур, связанных с установкой соединения на канальном уровне. За процедурную часть отвечал раздел МЭК 870-6, на который почему-то никто из «законодателей» не обращал внимания. Тем не менее, имея в запасе прекрасно сформулированное Норвежское соглашение, со всеми его диаграммами и вычеркнутыми частями, всем производителям удалось придти к какому-то единому пониманию того, как должен строится обмен.

Насколько я знаю, сейчас процедура проверки совместимости протоколов уже не проводится, т.к. все, кто был на этом рынке уже свои реализации протоколов МЭК за эти годы успели отладить, а те, кто не успел — просто покинули рынок (есть и такие компании).
Теги:
Хабы:
+2
Комментарии 14
Комментарии Комментарии 14

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн