Human-Machine Interface в стандарте IEC 61850: интервью с Алексеем Аношиным

— В связи с чем возникла необходимость разработки этого раздела стандарта?

Начнем с того, что часть Human-Machine Interface (HMI) является своего рода продолжением 6-й главы стандарта. Она неспроста даже носит индекс 6.2. Необходимость связана со следующим: стандартный файл SСL, а точнее его секция Substation, то есть описание подстанции, содержит объектное описание однолинейной схемы объекта. Это означает, что в данном файле содержатся описание оборудования подстанции, описание соединения между различным оборудованием: силовыми трансформаторами, силовыми выключателями, измерителями, разъединителями и т. д. — то есть описывается вся однолинейная схема. Но описывается она непросто как, скажем, набор линий, кружочков и т. д. — каждый элемент описывается отдельным объектом. Дальше указывается, какие объекты и каким образом друг с другом соединены. Кроме того, описываются функции, которые должны быть реализованы на тех или иных элементах: функции защиты, автоматики и т. д. — функций, которые описываются с использованием логических узлов в стандарте IEC 61850.

Фактически мы получаем схему информационно-технологической системы (ИТС) — то, что релейщики и асушники знают как схему ИТС — только не в графической форме, а в форме объектного описания. Представить это в виде АРМ, в чистом виде взять секцию подстанции и показать ее в виде графического отображения на мониторе компьютера, или, скажем, на большом щите в диспетчерском центре, или на маленьком экране устройства — вот просто в лоб взять этот стандартизованный синтаксис и его отобразить крайне затруднительно. Не то чтобы невозможно, но затруднительно.

— А хочется, чтобы все содержалось в одном файле и быстро выгружалось в интерфейс?

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

— Наверное, этот тезис надо на две части разделить. Первая — то, что, конечно, хочется автоматизации. Вторая — хочется, чтобы стандартизированный файл конфигурации был средством передачи информации между различными этапами разработки проекта. Ведь основная цель, основное назначение этих файлов — передавать информацию между какими-то стадиями разработки проекта. Например, между стадией проектирования (П), стадией рабочей документации (РД) и в конечном счете стадией наладки.

— То есть это будет всегда один сквозной файл, который можно использовать на разных этапах проекта, от идеи до конфигурирования на построенном объекте?

На цифровой подстанции все, за исключением, скажем, цепей питания, мы можем описать с помощью файла SСL.

— Мы сейчас говорим про файлы SСL вообще или только про касающиеся HMI?

Начнем с глобальной идеи SСL. Конечно же, это не всегда один файл. Вообще, идея SСL-файла заключается в том, чтобы насквозь пронизать вот этим стандартным файлом разные этапы проектирования и наладки. То есть у нас на этапе проекта рождается файл спецификации системы, в котором мы можем описать — грубо — требования или схему ИТС. Дальше у нас этап РД, когда мы должны на основе файла спецификации создать конфигурацию целой подстанции, но мы не можем этого сделать сразу, нам нужны еще файлы описания устройств — то есть в специализированном софте мы подгружаем файлы устройств, задаем их конфигурации, в итоге получаем файл конфигурации подстанции. Не надо возлагать на этот файл задач больше, чем он решает: это просто средство хранения определенной информации в стандартном виде. Какой информации? Он позволяет хранить всю часть «вторички», которая не касается физических соединений, то есть в нем можно хранить уставки, можно хранить логические соединения функции между собой. Если мы переходим к полностью цифровой подстанции — термин неоднозначный, в данном контексте мы понимаем под ним то, что все устройства получают информацию и отдают ее только по «цифре», — в такой подстанции все, за исключением, скажем, цепей питания, мы можем описать с помощью файла SСL.

Теперь к HMI. Еще раз отмечу, что изначально SСL-файл не предполагал использование его для отображения информации — я имею в виду, на экране, АРМ или дисплее терминала.

— Как действуют сейчас, в отсутствии этого элемента?

— Вернемся назад. 6.2 — это глава, которая касается любых видов человеко-машинных интерфейсов, включая, во-первых, АРМ — с какой-то мнемосхемой, кнопками, органами управления, графиками и диаграммами, линиями тренда и всем остальным; во-вторых, дисплей на терминале, если он есть; в-третьих, большой диспетчерский щит. Все эти органы отображения охватывает глава 6.2. Она глобальна.

Как делается сейчас в этой сфере? По-разному. Для отображения на экране терминала есть два варианта. Первый — отображение вообще ничего общего с IEC 61850 не имеет, то есть идет отдельной историей: как производитель сам законфигурирует, так и есть, никто ничего не может там исправить в принципе — это область, которую жестко прошил производитель. Второй вариант — когда там что-то конфигурируемо, но только инструментами этого же производителя: можно вид отображения «однолинейки» поменять на терминалах с графическим дисплеем, можно добавить свои уведомления, перевести текст на русский язык — в рамках того, что позволяется производителем. Известны также устройства, которые пытаются у себя использовать синтаксис языка — это не синтаксис SСL, а скорее просто XML-файлы, которые используются для конфигурирования отображения на дисплеях терминалов и которые чем-то схожи с SСL-файлами.

Что касается АРМ как SCADA-системы, то тут все сильно зависит от конкретного поставщика этой SCADA, потому что есть системы, которые позволяют импортировать SСL-файл внутрь, они даже позволяют какие-то элементы из этого файла достать, расположить их на мнемосхеме — и, как бонус, мы получаем сразу привязку между отдельными элементами на однолинейной схеме и устройствами.

Весь IEC 61850, конечно, в первую очередь про объектное отображение, стандартизацию всяких элементов и атрибутов данных.

Тут, наверное, нужно углубиться в процесс наладки SCADA. У нее, условно говоря, есть две глобальные задачи. Первая — просто графически нарисовать квадратики, кружочки и еще что-нибудь, а вторая — связать их с конкретными точками данных внутри устройства. Вторая задача заключается в том, чтобы настроить коммуникации по стандарту IEC 61850, если мы говорим про этот стандарт. Бывают и так называемые объектные SCADA, где ты не кружочки рисэуешь, а знаешь, что вот в этот элемент уже зашита какая-то логика отображения — в замкнутом положении, в разомкнутом положении или когда данные не приходят. Весь IEC 61850, конечно, в первую очередь про объектное отображение, стандартизацию всяких элементов и атрибутов данных. И поэтому выключатель с точки зрения этого стандарта — это и конкретный элемент, который отвечает за положение этого выключателя на однолинейной схеме и соединение его с другими элементами по первичке, и функциональные логические узлы, относящиеся к этому выключателю, из которых можно получить данные о его текущем положении или передать команду на управление. Но часть, которая на сегодняшний день в IEC 61850 отсутствует, — это то, как конкретно представить этот выключатель на мнемосхеме: кружком или квадратиком, каким цветом, с какой анимацией для замкнутого или разомкнутого положение.

— То есть цель — это унификация, чтобы любой человек мог одинаково воспринимать один и тот же элемент схемы?

Стандарт в рамках 6.2 будет давать возможность создать это самое визуальное отображение объекта, описав его стандартными средствами, в том виде, в котором надо локальному рынку или даже локальному заказчику.

— Скорее даже наоборот. МЭК не стремится никогда предоставить людям универсальный стандарт, объясняющий, скажем, каким цветом красить выключатель. Возможно, такие стандарты где-то и есть, но это вне рамок именно IEC 61850. Наш стандарт в рамках 6.2 будет давать возможность создать это самое визуальное отображение объекта, описав его стандартными средствами, в том виде, в котором надо локальному рынку или даже локальному заказчику. Грубо говоря, речь идет о том, что вот у нас есть выключатель как элемент однолинейной схемы, как объект, у которого есть связи с другими объектами, и у нас есть выключатель как функция, мы можем получить его положение и управлять им, мониторить и т. д. И та часть, которая у нас отсутствовала, — это то, как он выглядит, буквально как его надо отобразить. И вот сейчас глава 6.2 как раз пытается восполнить этот пробел, то есть описать раздел синтаксиса, который бы позволил именно нарисовать этот выключатель и показать, как он должен выглядеть.

— Когда глава будет готова, у автора проекта будет выбор — нарисовать, например, выключатель квадратиком или полоской с крестиком?

— Именно так!

— Нет стремления унифицировать для всего мира отображение, есть цель автоматизировать процесс разработки проектов и сделать выводы конфигурирования элементов, отображения на мнемосхеме автоматическими?

— Я бы еще здесь добавил одну вещь. Ее можно рассмотреть на примере современного проектирования SCADA, при котором на этапе РД должны быть выданы мнемокадры для отдельных элементов системы: как будет выглядеть, скажем, экранная форма управления выключателем либо каким-то присоединением или как будет выглядеть экранная форма для объекта в целом. Это является предметом утверждения и заданием на параметрирование. Но очевидно, что то, что согласовывается, что рисуется, может иметь разные варианты: кто-то еще в рамках проекта делает всю наладку, «принтскринит»; другой вариант — экранные формы — это просто рисунки, которые потом наладчику надо все перерисовать. И МЭК как раз стремится к тому, чтобы сделать эти файлы визуализации частью единого процесса параметрирования, когда созданный файл визуализации потом связывается с объектной моделью устройств, и в конечном счете мы получаем уже готовую конфигурацию, которую загружаем непосредственно в устройство, в локальный АРМ или в АРМ диспетчера — чтобы получить отображение ровно в том виде, в котором изначально согласовали.

— Когда эта часть стандарта вступит в силу, производителям АСУ ТП и производителям релейной защиты нужно будет ее как-то принять и свои устройства, свое ПО разрабатывать с учетом всего этого, чтобы их устройства могли воспринять такой файл? Им придется что-то переделывать у себя?

— Надо сказать о том, что мы сейчас находимся на этапе так называемого первого CD, commission draft. Он только-только был сдан и опубликован. Соответственно, национальные комитеты его получили и могут проголосовать по нему либо «за», либо «против». Но надо понимать, что этот процесс еще будет длиться очень долго.

На одном из наших последних онлайн-заседаний обсуждался вопрос, что в целом внутри стандарта не планируется каким-то образом описывать то, как АРМ должен получать данные не по IEC 61850.

Заглядывая в будущее, я бы сказал следующее. Всех производителей хотя бы условно надо разделить на две категории: тех, кто делает «железки», и тех, кто делает софт. У тех, кто делает софт — имеется в виду SCADA, — уже есть какая-то «отображалка», и по большому счету они исходно могут этот вопрос решить малой кровью. Потому что сам по себе стандарт, в том драфте, который есть, не накладывает ограничений на технологии, которые использует у себя производитель. Речь не идет о том, что он у себя должен «отображалку» SVG-файлов сделать. SVG — это стандарт отображения векторной графики, наиболее популярный сейчас в интернете. И он открытый, что важно, так как открытость стандарта делает его доступным для большого количества разработчиков. Так вот, глава 6.2 не будет требовать от производителя SCADA-системы, чтобы у нее внутри обязательно отображался стандартный файл SVG. Речь идет о том, что система просто должна принять к себе файл в таком формате, а дальше может делать с ним, что хочет, — но при этом отобразить так, как было нарисовано. По большому счету точно так же дело обстоит со всем SСL вообще: производитель внутрь своего софта загружает SСL-файл в том виде, в котором он стандартизован, но внутрь устройства он отнюдь не всегда загружает именно XML-файл именно в этом виде, он его как-то преобразует — скармливает своему устройству то, что оно готово принять. Так и здесь: производитель конкретных SCADA должен будет научиться импортировать к себе этот файл, как-то его обработать и развернуть визуальное отображение из этого файла — причем не только развернуть визуальное отображение, но и сразу связать все с нужными серверами MMS, то есть с устройствами, передающими данные по стандарту IEC 61850.

Важный нюанс: на одном из наших последних онлайн-заседаний обсуждался вопрос, что в целом внутри стандарта не планируется каким-то образом описывать то, как АРМ должен получать данные не по IEC 61850. По крайней мере первая версия этого стандарта будет касаться только части IEC 61850. Например, весь 104-й и прочие протоколы останутся за скобками этой главы. Во всяком случае, текущий статус такой, но все еще может поменяться.

Что же касается производителей железа, то тут опять два варианта: либо у «железки» в принципе нет дисплея, отображать ей нечего, либо есть какой-то графический дисплей, который отображает мнемосхему. Замечу отдельно, что хотя мы немножко упрощенно говорим исключительно о мнемосхемах, внутри стандарта речь сейчас идет не только о них, но и о диаграммах, графиках, предупреждающих сигналах и т. д. Если какой-то экран есть, для него тоже надо будет предусмотреть то, что называется внутри стандарта «компилятор» — устройство, которое будет компилировать стандартный файл в формат, используемый у себя производителем, и отображать этот файл так, как он нарисован.

— Это касается подстанций. А как быть с сетями и элементами, которые расположены в сетях? Допустим, для сетей 6–35 кВ характерна установка секционирующих пунктов и реклоузеров, и АРМ диспетчера включает в себя эти элементы. Планируется развивать это направление? И как быть, если подстанции на IEC 61850, а все остальное на чем-то другом?

— Ответ очень простой — да, включает. На сегодняшний день IEC 61850 и SСL-файл в плане описания элемента Substation внутри SСL-файла, если говорить о первичной схеме соединений, могут описывать не одну подстанцию, а несколько подстанций и соединения между ними. Можно целиком сеть описать, если необходимо. Я не готов сейчас ответить, будет ли ГИС включен в HMI — ГИС как крайняя степень внедрения отображения именно в сети. Видимо, стандарт тут более сдержан и пойдет сначала в логике первой редакции IEC 61850, предполагая прежде всего отображение внутри подстанции, то есть локально, как объект.

— В рамках ОПУ-объекта, а не АРМ и РДУ?

— Да, в рамках какого-то локального объекта. Хотя очевидно, что те вещи, которые там будут разрабатываться, использоваться и стандартизироваться, очень быстро и легко смогут быть масштабированы на распредсеть и на диспетчерский центр с одним лишь, наверное, «но», которое будет заключаться именно в ГИС и т. д. Насколько я помню последние договоренности, ГИС в первой редакции стандарта не будет никак затрагиваться — это будет параллельная история. Следовательно, если ГИС нет, то речь идет больше о локальном объектовом АРМ, а не о системе для отображения сети.

— В какой стадии разработка?

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

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

Одна из наиболее существенных претензий, с которой нам приходилось встречаться и которая имеет под собой основания, — глава 6.2 на сегодняшний день не очень глубоко интегрирована с теми SСL-файлами, которые уже предусмотрены главой 6. Многие, кто смотрят предложенный драфт стандарта, говорят: «А почему вы исходно не используете SFD-файл, в нем уже есть все, что вы хотите описать, почему не ссылаетесь на него?» Вопрос, на мой взгляд, довольно резонный, и мы планируем делать шаги в этом направлении.

Есть еще несколько задач, которые решаются в рамках работы. Одна из них — описание бизнес-процесса создания HMI, то есть работа над интерфейсом, начиная с того, что отражается в ТЗ на АРМ, и заканчивая тем, как делается наладка. Потому что на сегодняшний день этот раздел отсутствует в стандарте. Хотя в целом процесс работы над конфигурацией HMI уже описан, однако такого важного, с моей точки зрения, пользовательского сценария пока нет.

Вторая задача, которая на сегодняшний день обсуждается, заключается в том, что вообще глава 6.2 порождает огромное количество видов файлов конфигураций. В главе 6 присутствует 4 вида файлов, которые знает большинство: SFD, — и есть еще менее известные IID и SED, введенные второй редакцией. А глава 6.2 порождает еще как минимум 4, а то и все 6 видов файлов, название и назначение которых до сих пор не все запомнили. Это определенного рода проблема, потому у многих все еще каша в голове по поводу того, чем SCD от CID отличается, а когда добавляются еще и HSD, HCD, HSI и т. д., явно будет очень много вопросов.

— Это файлы, которые по отдельности должны быть созданы?

IEC 61850 никогда не стандартизирует конкретный софт — он стандартизирует функционал.

— Да, их будет порождать, возможно, один инструмент. Напомню, что IEC 61850 никогда не стандартизирует конкретный софт — он стандартизирует функционал. Есть такая роль у инструмента, и эта роль должна породить вот такой файл, при этом конкретный софт может исполнять сразу много ролей, быть целым оркестром. Так и здесь. Будет много видов файлов, которые порождаются разными ролями. Наверное, основной момент, что есть в сегодняшней логике стандарта, заключается в том, что полностью разделены части, касающиеся функциональной спецификации HMI, и части, касающиеся визуально-графического отображения. Большой вопрос — правильно это или нет. Будем работать над этим, может быть, что-то со временем поменяется.

— Что бы ты посоветовал в данный момент производителям? Что им делать? Готовиться и искать первый драфт или ждать?

Чтобы реально повлиять на ход развития стандарта, надо участвовать в заседаниях, выражать свою позицию, спорить, аргументировать — тогда это находит отражение в стандарте.

— Все зависит от того, чего хотят производители. Наш опыт работы с этим стандартом показывает, что в целом инвестиции в работу с ним так или иначе оправдывают себя. Потому что когда ты используешь IEC 61850, ты становишься игроком глобального рынка; дальше все зависит от того, чем ты можешь на этом рынке людей привлечь.

Что можно посоветовать? Наверное, в первую очередь речь идет о разработчиках и производителях SCADA-систем. Им можно предложить поучаствовать во всем этом. Сейчас нельзя сказать, что этот стандарт разрабатывают реально действующие игроки рынка SCADA, хотя часть из них входит в task force [целевую группу — прим. ЦПС]. Однако есть две проблемы: первая — может быть, кто-то будет не готов, вторая — возникнут условные перекосы, например, у Schneider Electric появится более стандартная SCADA, чем у всех остальных. Немного возвращаясь назад во времени: многие производители выражали недовольство тем, что в профиле 9-2LE были закреплены частоты, в принципе некратные тем частотам, которые использовались в России. А так — рабочая группа открыта, в нее может войти любой, как вошли мы. Но одно вхождение в рабочую группу, по сути, не значит ничего, кроме того, что ты можешь похвастаться своей фамилией на сайте МЭК. Чтобы реально повлиять на ход развития стандарта, надо участвовать в заседаниях, выражать свою позицию, спорить, аргументировать — тогда это находит отражение в стандарте. Это, наверное, первое и единственное, что можно посоветовать производителям, если они реально хотят войти в эту историю.

Второй вариант: если чего-то нельзя отменить, то можно просто запастись аргументами против МЭК и сказать, что глобальные стандарты — это плохо, а внедрение их в России подрывает ее суверенитет.

— Либо, если нет возможности участвовать в создании стандарта и влиять на него, просто отслеживать появление драфтов и согласованных версий на странице стандарта IEC 61850?

— Конечно. Думаю, и «Цифровая подстанция» напишет, если глава 6.2 будет опубликована. Но надо понимать, что стандарт будет еще как минимум года три разрабатываться. Дальше он будет опубликован на сайте МЭК, но это не значит, что все сразу кинутся его требовать. Есть определенные сдерживающие факторы, которые явно приведут к тому, что после его публикации понимание того, что есть этот стандарт и как можно с ним работать, до заказчиков этих систем дойдет еще через некоторое время.

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