Источник: Заболотный И.П. Внеязыковая технология программирования в информационно-управляющей системе локальными объектами ЭЭС // Вісник Кременчуцького державного політехнічного інституту. – 2004(26). – №3. – С. 171-174.
Введение.Структурная перестройка энергетики, введение энергетического рынка, которые происходят в ряде стран, в том числе и в энергетике Украины, сопровождаются децентрализацией управления как локальными объектами, так и всей ЭЭС. Анализ существующих информационно – управляющих систем (ИУС) локальными объектами ЭЭС показывает, что программное обеспечение, учитывающее особенности технологических задач управления практически отсутствует. Таким образом, обеспечение надежности в новых условиях связано с повышением эффективности ИУС за счет использования современных информационных технологий.
Цель работы. Основной целью проведенных в работе исследований является разработка технологии программирования с позиций инженера–технолога, а не инженера–исследователя, обеспечивающей устранение в ИУС локальными объектами ЭЭС несоответствия между возможностями современных информационных технологий и техническими средствами управления с одной стороны, существующим инструментарием программных средств с другой стороны.
Результаты исследований. В развитии технологий программирования выделяют этапы, которые связаны, в первую очередь, с автоматизацией программирования: ассемблеры, алгоритмические языки, объектно – ориентирование программирование (ОПП). Каждый этап включает в себя ряд конкретных направлений. Например, широко известны такие как, CASE – технологии, предназначенные для проектирования на высоком уровне без отвлечения на детали на основании набора инструментальных средств; COM – технологии для компонентного программирования, позволяющего автоматизировать программирование и обмен данными между программными продуктами; CAD – технологии ориентированные на использование графических изображений; ГИС технологии, позволяющие привязать информацию к географическим картам (в общем к поверхности) и др. Кроме того, пакеты прикладных программ могут быть классифицированы по таким признакам, как ориентация на математические методы (пример MathCad), ориентация на структуры (пример Matlab) и др. Рабочие программы пользователей и программный инструментарий АСУТП в целом также делятся на проблемно–ориентированные; структурные методы и структурированные макромодели; системы искусственного интеллекта. Использование существующих технологий программирования обуславливает появление следующих характеристик программного обеспечения:
Анализ показывает, что дальнейшее развитие изложенного в [1] метода требует другого подхода к описанию объектов по сравнению с ООП. Несмотря на разницу в строении объектов их нужно не только разделить, что уже сделано в [1-2], на группы: по общности функционального назначения (что делают объекты) и (или) по сходству функциональных наборов (как они что-то делают), но и использовать такое деление для образования объектов другого вида. Под функциональным набором понимается перечень действий, выполняемых объектом как самостоятельно, так и по инициативе других программных объектов и событий. Все действия могут быть разбиты на последовательности.
Таким образом, мы имеем несколько совокупностей объектов, причем в каждой совокупности объекты функционируют сходным образом. При этом внутреннее и внешнее устройство объектов не принимается во внимание. Кроме стандартного функционального набора, каждый экземпляр из группы может иметь дополнительные функции, т.е. не накладываются никакие ограничения на объем и выполняемые действия. Поскольку объект управления представлен совокупностью параметров с заданным отношением принадлежности и взаимосвязи, то образующие деятельности могут быть представлены лишь как различные формы преобразования, анализа и синтеза информационного потока. Причем упор делается на общность, универсальность приемов, используемых персоналом энергетических объектов. Стремление к общности находит отражение и в форме представления декларативной информации, и в технической реализации системы управления. Тот же подход применяется и к моделям образующих деятельности, а любые логические построения должны быть в случае необходимости полностью объяснены в терминах, не выходящих за пределы профессиональных знаний оператора.
Данная работа является развитием [3]. Основой системы технологического программирования являются: объектный подход (рис. 1); компонентная структура; технология «промежуточного слоя» (рис. 2); внеязыковое программирование. Логически вся совокупность параметров разбита на две группы: собственно параметры объекта, управляющие параметры, среди которых и относящиеся к командам.
Технологическая программа на непроцедурном языке представляет собой совокупность объектов и форм заданной структуры: множества таблиц по направлениям: параметры элементов (параметры модели); исполнители команд; перечислимые типы модели; состояния модели; реакции модели; запреты на команды подчиненным; зоны действия и уставки защит, объекты, на которые действуют устройства регулирования и защиты; меню с различными опциями и т.д.
Технология взаимодействия объектов по сути является универсальным протоколом обмена данными, представляющим собой способ реализации данной абстракции в табличной и графической формах и обеспечения взаимодействия между ними и другими объектами. Протокол назван универсальным потому, что задается только один единственный способ обмена данными между объектами. Таким образом, технология взаимодействия объектов представляет собой синтез нескольких технологий вокруг одной идеи: универсального представления объекта и универсального взаимодействия.
Универсальное взаимодействиереализуется посредством следующих основных компонент:
1. Механизма имен.
2. Механизма регистрации объектов (рис. 3).
3. Универсального интерпретатора логических выражений (рис. 4), хранящихся в базе знаний и используемых для оценки реакций объекта на управляющие и возмущающие воздействия, для учета работы устройств релейной защиты и автоматики, диагностирования состояния элементов и режимов объекта, анализа работы устройств РЗиА. Модификация структуры записей правил, коррекция содержимого базы знаний не требует изменения программного кода интерпретатора.
Условия, образующие правила, представляют собой строковые переменные. Метод интерпретации преобразует строковые переменные в логические выражения. Значениями эти выражений являются логическими константами, которые принимают значения True или False в зависимости от выполнения логического выражения. В выражения входят переменные, отражающие номинальные параметры, нормативные параметры и текущие параметры от устройств регистрации. Цикл работы интерпретатора схематически показан на рис. 4.
В каждом цикле просматриваются все правила, чтобы выявить те, посылки которых совпадают с известными на данный момент фактами из рабочей памяти.
Интерпретатор выполняет такие функции:
1. Для каждого условия правила
1.1. Извлечение условия БЗ – символьные строки.
1.2. Преобразование строковой переменной в логическое выражение
1.3. Подстановка значений переменных, входящих в логическое выражение.
1.4. Выполнение логического выражения
2. Формирование вектора текущего состояния элемента, режима работы, команды, персонала, работы устройства и т.д.
3. Сопоставление текущего вектора с эталонными (БЗ).
4. Формирование заключения/заключений, рекомендаций, воздействий.
Совокупность отобранных правил составляет так называемое конфликтное множество. Для разрешения конфликта интерпретатор имеет критерий, с помощью которого он определяет сработавшее правило.
4. Построителя логических выражений, опирающегося на идентификаторы переменных базы данных, имена внешних и внутренних функций, арифметические и операции отношения, логические функции.
5. Посредников, которые представляют собой контейнеры для хранения и передачи параметров и обеспечивают доставку параметров до нужного объекта/объектов.
Взаимодействие объектов основывается на использовании таблиц обмена данными. Требования образования пространства имен и соглашений, полей, наборов хранимых процедур и т.д. частично описаны в [1-3].
Согласно [1, 3] объект графического изображения имеет множество портов для соединения силовых элементов электрической схемы, подключения средств регулирования, измерения, подключения информационных окон. Параметры объектов позволяют определить тип; состояние; математическую модель; таблицы БД, описывающие свойства объекта; таблицы баз знаний; логические модели и т.д.
Так, таблицы БЗ анализа действия устройств релейной защиты и автоматики описывают зоны действия команд защит с учетом режима работы объекта, содержат информацию о назначении команды (отключить, запретить, формировать, и т.д.), признак объекта, на который воздействует команда.
Таблица параметров модели полностью описывают информацию, обрабатываемую моделью и ее информационное взаимодействие с другими моделями. Алгоритмы модели могут использовать только те параметры, которые описаны в таблице. Таблица имеет простую структуру - для каждого параметра указываются идентификатор параметра, его полное название и тип.
Как и для параметров, использование в алгоритмах внутритиповых имен обеспечивает независимость программ не только от размещения, но и от названия элементов в конкретной технологической схеме, что обеспечивает «библиотечный» характер алгоритмов и простоту их переноса на аналогичные объекты.
Источником запуска входной команды может быть меню, срабатывания устройств регулирования, защиты при выполнении критериев в процессе имитационного моделирования.
Таблица состояний в максимально наглядной форме описывает алгоритм идентификации состояния модели, соответствующего одному из основных режимов ее функционирования. Таблица также имеет простую структуру: столбец соответствует критерию состояния модели, строки - комбинации значений критериев, именованная группа строк, объединённых по технологической сущности - состоянием модели. Как и другие параметры, критерии состояния должны быть описаны в таблицах базы знаний. Состояние модели идентифицируется в соответствии с таблицей состояний по совокупности значений критериев состояния в текущий момент времени.
Неисправные состояния вычисляются по таблице реакций. Таблица реакций описывает все существенные для модели события, кроме поступления команд, и ответные реакции модели на эти события. Таблица реакций в наиболее простой форме описывает все нештатные ситуации, диагностирует неисправное состояние модели. Для каждой реакции указываются: условие срабатывания, действия, автоматически выполняемые АСУТП при срабатывании реакции, и сообщение о событии, передаваемое оператору.
Таблица запретов не разрешает выполнение технологически недопустимых или нежелательных операций.
Для запрета указывается: на кого он действует (один из исполнителей, перечисленных в таблице исполнителей), исполнение какой команды запрещает, приоритет запрета, условие действие запрета. Условие действия представляет собой логическое выражение.
Если приоритет команды оказывается меньше или равен приоритету запрета, то команда отбрасывается, иначе она «пробивает» запрет (например, команда защиты преодолеет запрет уровня диспетчерского управления).
Предлагается несколько способов работы с объектами, среди которых простейшим является метод прямого вызова.
Как указывалось выше, каждый элемент локального объекта ЭЭС обслуживается механизмом регистрации таблиц, в том числе и универсальной таблицы, содержащей разделы:
- сообщений, в котором отражается ход выполнения операции и приводится информация о сработавших правилах БЗ;
- настройки активного объекта на контроль состояния при выполнения команд путем агрегирования информации из БД и БЗ;
- предупреждений, являющейся диагностированием объекта до выполнения операции;
- описание датчиков, имеющихся на объекте и отражающих параметры объекта при его эксплуатации.
На рис. 5, в качестве примера, приведена форма экрана при работе с таблицами БЗ в прикладной экспертной системе диагностирования турбогенератора. Автоматизированы режимы с базой знаний. Прямоугольники на схеме это датчики контроля состояния генератора.
Реализация обобщенного механизма (независимого от объекта) автоматизации управления базой знаний диагностирования состояния связана с использованием дополнительных таблиц.
Первая описывает связи датчиков с таблицами БД, вторая имена переменных с источниками данных. Вершины деревьев ситуаций связаны с датчиками контроля реального состояния объекта, табло, реле-указателями или результатами обработки специальных испытаний, что отражено в таблице.
Обеспечивается работа с датчиками путем указания их на мнемосхеме и выбором из меню необходимых действий: использование информации от датчика в правиле БЗ, вывод данных на экран, задание уставок и т.д.
Если значение (значения) от датчика (датчиков) превысило уставку (уставки), то с помощью информации таблицы интерпретатор начинает обрабатывать соответствующую таблицу решений, описывающую текущую ситуацию.
Выводы. Разработана внеязыковая технология моделирования для ИУС, отличающаяся тем, что с позиций инженера-электрика решаются задачи управления при автоматическом формировании моделей на основе принципиальных схем электрических соединений, формировании управляющих признаков для адаптации модели, оценки допустимости команд управления на основе информации от систем сбора и оперативно вводимой оператором.