Объектная модель – важная составляющая МЭК 61850
Я не хочу в очередной раз проводить сравнение таких протоколов как DNP3, МЭК 60870-5-101/-104 с МЭК 61850. Мы все знаем о потенциальных преимуществах, которые могут быть получены при применении протоколов GOOSE и Sampled Values – тех механизмов, которые не описываются другими существующими коммуникационными стандартами. Кроме этого, стандарт МЭК 61850 описывает процедуру ижиниринга систем автоматизации и унифицированный язык конфигурирования устройств, чего также не было в других стандартах.
Однако одной из важных особенностей стандарта МЭК 61850, о которой часто забывают и которую недооценивают, является объектная модель, которая определена в главе 7-4 стандарта путем описания так называемых логических узлов и объектов данных, которые, в совокупности, позволяют выполнять моделирование различных функций релейной защиты и автоматики, оборудования энергообъектов и формируемых ими сигналов. Если при работе со SCADA-системой, опирающейся на использование давно существующих коммуникационных протоколов, специалист должен знать номер точки данных, которой соответствует, к примеру, положение силового выключателя #921, то в случае использования МЭК 61850 эта информация всегда представляется объектом данных Pos логического узла XCBR. И среди нескольких экземпляров логического узла XCBR, каждый из которых соответствует реальному силовому выключателю на энергообъекте, благодаря использованию языка описания конфигурации системы (SCL – System Configuration Language), пользователь может определить какой экземпляр соответствует именно выключателю с номером 921. Все это не только упрощает процедуру наладки системы АСУ ТП, но и ее дальнейшее обслуживание.
К сожалению, практическая реализация объектной модели в устройствах не всегда подчиняется требованиям и рекомендациям стандарта и может быть именно по этой причине многие не осознают ее истинной ценности. Почему это происходит?
В первую очередь, следует отметить, что существует логический узел GGIO, исходное предназначение которого согласно стандарту МЭК 61850 – моделирование общей, не входящей в состав ни одного из других описанных стандартом логических узлов, информации. Например, контакта положения двери или выходного сигнала системы пожарной сигнализации. В объектных моделях многих существующих устройств имеет место отступление от этой идеологии и логические узлы GGIO используются для моделирования описанной другими стандартными логическими узлами информации.
Во-вторых, стандарт дает достаточно большую свободу действий при моделировании, когда пользователь может смоделировать одну и ту же функцию (информацию) различными способами. Пример – трехступенчатая функция дистанционной защиты. Данная функция может быть представлена тремя экземплярами логического узла PDIS – по одному на каждую ступень защиты. Или при помощи 6 экземпляров логического узла PDIS, когда для каждой ступени один экземпляр PDIS описывает виртуальное реле дистанционной защиты от междуфазных КЗ, а другой – от однофазных КЗ на землю. Или же при помощи 12 логических узлов PDIS, когда моделируется реле защиты по каждой фазе и отдельно реле защиты от однофазных КЗ на землю. В такой ситуации достаточно сложно определить какой логический узел какую информацию предоставляет. Префиксы, которые могут быть добавлены к наименованию логического узла, – не стандартизованы. Поэтому Вам повезет, если Вы догадаетесь, что из себя представляет логический узел PhsPDIS1 или GndPDIS6. А если не повезет – то в объектной модели Вы обнаружите логические узлы PDIS1 – PDIS6. В части разграничения того, для моделирования чего конкретно используется тот или иной логический узел ситуация должна улучшиться в ближайшем будущем. В семантике языка SCL рабочая группа определила новые возможности для идентификации функций и под функций (отдельных ступеней защит, отдельных фаз первичного оборудования и др.).
Вернемся к проблеме с применением логического узла GGIO. Эта проблема обсуждается достаточно часто. Можно отметить две причины применения логических узлов GGIO не в соответствии с их назначением:
- Специалисты фирм-разработчиков не знают как или не хотят моделировать информацию в соответствии со стандартом. Например, они моделируют сигнал положения силового выключателя двумя разными сигналами (52a/52b) (single point) вместо того, чтобы использовать сигнал типа double point.
- Вторая причина заключается в том, что большая часть существующих сегодня на рынке устройств – это свободно-программируемые устройства. При поставке устройства, базовым программным обеспечением уже предусмотрено выполнение определенного набора функций (например, управления коммутационным оборудованием, автоматическое повторное включение и др.). Каждой функции, имеющейся по умолчанию, соответствует стандартный логический узел в соответствии с МЭК 61850 (учтите, что это может быть и не так, если фирма-разработчик работает не добросовестно). Как было указано выше, устройства наиболее часто являются свободно-программируемыми, что означает, что на их входы может быть назначен любой сигнал контролируемого первичного процесса и также могут быть созданы пользовательские логические схемы, имеющие на выходе пользовательские сигналы. В этих условиях есть единственно возможный и правильный способ, позволяющий в объектной модели отразить набор таких пользовательских сигналов, – использовать логические узлы GGIO. Ведь производитель еще не знает, какую смысловую нагрузку будут нести эти сигналы. Однако при проектировании и наладке микропроцессорного устройства специалист должен иметь возможность заменить данный общий логический узел на подходящий из стандартизованных (если смысловое соответствие может быть установлено). К примеру, если специалист заводит на дискретный вход устройства выходной контакт реле сигнализации снижения давления, в дальнейшем он должен иметь возможность представить эту информацию не при помощи логического узла GGIO (GGIO.Alm), а при помощи логического узла SIMG (Ins.Alm). Возможность внести подобные изменения может предоставляться на этапе формирования файла ICD устройства для ПО системного инжиниринга, если пользователь уже знает какие сигналы устройство будет принимать или формировать в соответствии с проектом, либо на этапе загрузки файла SCD в настроечное ПО устройства. В последнем случае потребуется загрузка файла формата IID в ПО для системного инжиниринга для обновления файла SCD в части устройств, которых коснулись изменения. Таким образом, необходимые механизмы для выполнения таких изменений предусмотрены стандартом МЭК 61950, – но сегодня большинство производителей не обеспечивают такой возможности.
Сегодня, когда фирмы-производители приступили к реализации своих устройств в соответствии с главами второй редакции стандарта, мы можем ожидать изменений в лучшую сторону в части представления объектной модели.
Вскоре, я уверен, мы будем получать еще больше преимуществ от использования стандарта МЭК 61850.