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

Здравствуйте! Меня зовут Юрий.

Преамбула

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


Для краткости я введу некоторые сокращения:
  • МЭК -протоколы по ГОСТ Р МЭК 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, на который почему-то никто из «законодателей» не обращал внимания. Тем не менее, имея в запасе прекрасно сформулированное Норвежское соглашение, со всеми его диаграммами и вычеркнутыми частями, всем производителям удалось придти к какому-то единому пониманию того, как должен строится обмен.

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

Комментарии 14

    0
    Ждал больше конкретики.
    Надеюсь на продолжение.
      0
      По конкретике — скажите, пожалуйта, что больше интересует, т.к. тема достаточно обширная.
        0
        Конкретный опыт применения на больших гетерогенных системах, нюансы. Передача в систему АСУП верхнего уровня.
        Так-то понятно, что 101 / 104 — это протокол, который может все на свете в области энергетики, но мало кто ее разрабатывал сам и уже еще меньше тех, кто использовал его хотя бы на упоминаемые вами 20%.

        Еще интересует стандарт IEC 61850. Насколько он реально применим в наших энергосистемах, насколько он востребован.
          0
          Ок! Про конкретику и нюансы я понял. Попробую смастерить на эту тему отдельный пост. В нем, кстати, постараюсь просто расказать и про внутреннее устройство протокола.

          Касательно 61850 — в данный момент я практически ничего про него не знаю. Если встретится какая-нибудь хорошая статейка — дам ссылку.
            0
            Ну да, было бы неплохо. Рассмотрение четырех групп команд (информация процессов / системная информация в направлениях контроля, управления). Наиболее часто используемые команды.
            Общая схема обмена сообщениями: запрос, подтверждение, сами данные и т.д.
            Пример общение на этом проколе какой-нибудь станции контроля заряда аккумуляторных батарей (для примера).
              0
              Хорошо, уже начну делать наброски. :-)

              P.S.
              Я не искал, может быть сразу есть ответ на этот вопрос:
              У меня Андроид, планшеты/телефоны. Может есть какой-нибудь софт для работы с хабром? Специально заточенный, типа Вордпрессовского клиента для андроид?
      0
      В 104 протоколе крайне печалит размер фрейма с ограничением в 256 байта, доставшееся в наследство от 101, работающего на RS 232 / RS 485. Хотя в 104 могли бы увеличить, ну хотя бы до значений близких к MTU Ethernet.
      Ну и да, хотелось бы продолжения с подробностями
        0
        Про нюансы и 256 — вообще, во всех (насколько я видел) реализациях 104-ого несколько APDU фреймов могут быть переданы в рамках одного TCP пакета. Так что в этом смысле я не вижу серьезных ограничений. Наоборот, при реализации на основе UDP это позволяет оперативней отслеживать потери пакетов. Хотя, опять же, если честно на UDP видел 104-ый только 1 раз.
          0
          Наоборот, при реализации на основе UDP это позволяет оперативней отслеживать потери пакетов.

          Как это? Если я верно понимаю, в этом случае, при пропадании одного юдипишного пакета мы потеряем сразу несколько APDU фреймов.
          И, да.
          Конкретный опыт применения на больших гетерогенных системах, нюансы. Передача в систему АСУП верхнего уровня.

          Вот это очень интересует.
            0
            Как это?

            Верно. Но внутри APDU в 104 протоколе есть механизм проверки доставки последовательности, который позволяет при определенной настройке протокола параметрами k и w и таймаутами t0, t1 и t2 добиваться обязательного моментального подтверждения получения последнего фрейма. Насколько я знаю у стека UDP/IP задержки могут быть меньше засчет моментальной отправки появившейся в нем информации. Но давайте я этот момент получше уточню и раскрою в новой статье.
            … опыт применения на больших гетерогенных системах, нюансы… Передача в систему АСУП верхнего уровня.

            Понял.
        0
        Хотелось бы увидеть комментарии по поводу сравнения новых протоколов МЭК-101/104 с устаревшими RPT80, GRANIT, UTM7, TM512 и по использованию их наравне с ними.
          0
          :-) Приятно видеть знакомые названия на несколько отстранненом от этой тематики сайте.

          Постараюсь, если вспомню особенности и возможности старых протоколов.

          P.S.
          Кстати, документация (РП) к ЦППС «SMART-FEP» является одним из хороших источников информации о возможностях данных протоколов. Если что — пишите, попробую достать доку.
          0
          Отличная статья! А занимались ли Вы сами реализацией обмена по данному протоколу?
          Хотелось бы обратится за консультацией.
            +1
            Здравствуйте!
            Что в Вашем понятии «занимался реализацией обмена»? Софт, к сожалению, не писал. Знаю хороших «писателей». :-) Могу свести.
            Настройкой — раньше — постоянно, до тошноты. :-)

            P.S.
            Прошу прощения, на хабре бываю редко. Можно на почту личную shembel гав гмыл.

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

          Самое читаемое