Содержание к диссертации
Введение
Глава I. Технология проработки ремонтных заявок в энергообъединениях 11
1.1.Работа с ремонтными заявками. Основные понятия и категории 11
1.2.Проблемы автоматизации работы с заявками. Состояние вопроса 15
1.3 Информационные системы для автоматизированной проработки ремонтных заявок . 18
1.4.Существующие реализации в области автоматизации проработки заявок 22
1.5.Выводы по главе 1 25
Глава II. Метод интеллектуальных систем для проработки ремонтных заявок .26
2.1.Обоснование применения интеллектуальных систем для решения задач проработки заявок в энергообъединениях 26
2.2.Общая структура экспертных систем 28
2.3. Структура интеллектуальной системы со специализированным логическим выводом (метод МИМИР) 30
2.4.Построение прикладных систем на базе инструментальной системы МИМИР 42
2.5.Выводы по главе 2 45
Глава III. Инструментальная система МИМИР-3 46
3.1Преимущества и недостатки инструментальной системы МИМИР...46
3.2Новая архитектура системы 48
3.3 Структура данных Базы знаний МИМИР-3 51
3.4. Трансляция ОЕЯ-запросов в SQL-запросы 54
3.5Выбор Оптимального плана выполнения запроса 64
3.6Выводы по главе 3 74
Глава IV. Интеллектуальная система для режимной проработки заявок 75
4.1.Общая структура системы режимной проработки заявок. 75
4.2.Структура знаний системы 77
4.3.Сервисные функции ЭСОРЗ 87
4.3.1. Сервис топологии сети 87
4.3.2. Сервис для автоматики 91
4.4.Проработка ремонтных заявок 92
4.5.Мониторинг заявок 94
4.6. Выводы по главе 4 100
5.1. Работа с заявками в оперативном диспетчерском управлении 101
5.2.Мониторинг коммутационных состояний электросети 102
5.2.1.Мониторинг «прошедших»режимов 103
5.2.2.Мониторинг «предстоящих» состояний сети 104
5.2.3.Мониторинг текущего состояния сети 105
5.2.4.Контроль режимных параметров 106
5.3.Фиксация нештатных изменений состояния оборудования 109
5.4.Диспетчерское закрытие заявок 111
5.5.Диспетчерское открытие заявок 115
5.6. Выводы по главе V. 116
Литература
- Информационные системы для автоматизированной проработки ремонтных заявок
- Структура интеллектуальной системы со специализированным логическим выводом (метод МИМИР)
- Структура данных Базы знаний МИМИР-3
- Работа с заявками в оперативном диспетчерском управлении
Введение к работе
достаточно сложных логических выводов специалистов технологов с привлечением большого объема данных (топология сети, режимные инструкции, данные по противоаварийной автоматике и др.). Для поддержки и автоматизации работы служб энергообъединений целесообразна разработка методов, алгоритмов и программного обеспечения, на сколько возможно, облегчающей проработку ремонтных заявок и использования информации полученной в результате.
Наиболее полно данный класс задач решается в экспертной системе оперативного рассмотрения ремонтных заявок (ЭСОРЗ). Хотя на данный момент времени ряд структурных и технологических недостатков не позволяют, использовать его возможности в полном объеме, они связанны с изменением технической оснащенности энергообъединений и расширением круга решаемых задач.
Из технологических недостатков можно выделить отсутствие диспетчерских функций у системы-советчика таких как:
Онлайновая проработка заявок на случай изменения условий (получение аварийной заявки, смещение даты вывода или ввода оборудования) после предварительной проработки заявок, которая может повлиять на устойчивость и надежность работы энергообъединения.
Мониторинг состояния сети. Сравнивая информацию, полученную из оперативного управляющего информационно комплекса (ОУИК) с
информацией находящейся в базе данных системы-советчика можно выявлять на не соответствие установившегося режима.
Существует также ряд технических недостатков, таких как отсутствие:
Автоматического или полуавтоматического ввода информации из системы хранения информации по заявкам в систему проработки заявок.
Многопользовательской работы в системе-советчике.
Возможности взаимодействия других программных комплексов с системой-советчиком. Современные информационные системы имеют открытую архитектуру, позволяющую осуществлять обмен информацией.
Цели и задачи работы. Целью работы является дальнейшее развитие теории и практики использования систем-советчиков для автоматизации проработки заявок в диспетчерских службах энергообъединений. Конкретно в работе решаются следующие основные задачи.
Разработка концепции автоматизации проработки заявок дежурными диспетчерами энергообъединений.
Развитие возможностей систем-советчиков и разработка метода интеграции в информационную среду энергообъединений.
Эти проблемы взаимосвязаны: интеграция систем хранения данных и знаний позволит использовать результаты работы систем-советчиков в других подсистемах АСДУ, а также привлечь к проработке ремонтных заявок оперативную информацию, необходимую, в частности, для «диспетчерской» проработки заявок.
Основные методы исследований. Для решения поставленных задач использовались: практический опыт диспетчеров энергообъединений, практика внедрения интеллектуальных систем в энергообъединения, теория построения компиляторов, теория систем управления базами данных, практические исследования производительности систем управления базами данных (СУБД), объектно-ориентированное программирование, принципы построения оптимизаторов СУБД.
При решении ряда задач автором учтены результаты ранее проводимых экспериментальных исследований в области разработки и применения методов оптимизации запросов, также учтен опыт построения инструментальной системы малой информационной модели интеллектуальных решений (МИМИР1).
Научная новизна. Разработана концепция «диспетчерской» проработки ремонтных заявок, учитывающую проверку условий открытия (закрытия) заявок в схемно-режимной ситуации, отличающейся от ситуации,
МИМИР-2 текущая версия инструментальной оболочки, МИМИР-3 - разработанная автором ее новая версия
предполагаемой при предварительной проработке заявок в службе режимов, реализованы следующие функции:
Мониторинг текущего состояния сети.
Контроль режимных параметров энергообъединения
Фиксация нештатных изменений состояния оборудования
Диспетчерское закрытие заявок
Диспетчерское открытие заявок
Разработана инструментальная система, имеющая следующий ряд особенностей:
хранение базы знаний интеллектуальной системы в СУБД поддерживающих стандартный язык запросов SQL2
преобразование ограниченных естественно-языковых вопросов в SQL-запросы (разработаны методы оптимизации обработки SQL-запросов для локальных и корпоративных СУБД для обеспечения необходимой производительности систем-советчиков);
поддержка он-лайн взаимодействия экспертной системы с информационной средой энергообъединения.
2 SQL (Structured Query Language) - стандартизованный язык запросов к реляционным базам данных
Практическая значимость работы и ее реализация.
Новая версия ЭСОРЗ, содержащая элементы диспетчерской проработки, внедряется в использование в службе электрических режимов СО-ЦДУЕЭСРФ;
ОДУ Урала внедряет новую систему анализа топологии сети построенную на базе новой инструментальной системы.
Апробация результатов работы. Результаты работы были доложены и обсуждены на:
втором специализированном научно-техническом семинаре «Современные методы и программные средства анализа и планирования электропотребления, балансов мощности и электроэнергии» (г. Москва, 2004 г);
второй научно-технической конференции молодых специалистов электроэнергетики (г. Москва, 2003 г.);
конференции «Управление электроэнергетическими системами - новые технологии и рынок» (Сыктывкар 2004г).
конференции «Инновации в энергетических технологиях». (Москва 2001 г).
Информационные системы для автоматизированной проработки ремонтных заявок
Автоматизированные рабочие места оперативного персонала по проработке ремонтных заявок (АРМПЗ) должны сочетать диалоговые функции системы АСПРЗ (мониторинг информации по заявкам, редактирование информации по заявкам с контролем правил доступа к информации и функциям систем) и функции систем-советчиков типа ЭСОПЗ.
При этом если функции АСПРЗ практически идентичны для АРМПЗ в различных службах, то функции ЭСОПЗ для разных служб существенно отличаются, что обусловлено использованием в разных службах различных систем поддержки принятия решения при проработке заявок.
В систему АСПРЗ обычно входят только Данные по заявкам; Данные по оборудованию пока не включены в АСПРЗ, но в перспективе это предполагается; в ЭСОПЗ входят ДЗ, ДО, ДПА, ДТ, ДИ. Для интегрирования систем-советчиков ЭСОПЗ в сеть АРМПЗ необходимо ввести процедуру импорта данных из базы данных (БД) АСПРЗ в БД ЭСОПЗ.
При работе с системой-советчиком по заявкам (то есть при вызове функций экспертной системы) осуществляется сеанс работы экспертной системы, начинающийся с импорта данных БДОаспрз - БДОэсопз (1-1) и последующей проработкой ремонтных заявок системой советчиком. Результатами работы экспертной системы-советчика являются: рекомендации решения по заявке (разрешить, отказать) РР, условия разрешения заявки УР (соответствующие режимным указаниям для АРМПЗ СОЭлР или релейным указаниям для АРМПЗ СРЗиА), протокол экспертизы ПЭ (документ, содержащий обоснования или объяснения рекомендаций экспертной системы, выработанных ею при проработке заявки).
Чтобы полученная информация была доступна различным пользователям локальной сети, в базе данных АСПРЗ предусматривается соответствующий интерфейс и в конце сеанса работы экспертной системы осуществляется экспорт данных:
Наличие в составе Базы данных АСПРЗ информации типа РР, УР, ПЭ позволит существенно развить функции мониторинга заявок, и, тем самым, повысить качество компьютерной поддержки оперативного персонала при работе с ремонтными заявками.
При организации процедур импорта-экспорта данных в сеансе работы экспертной системы имеется существенная особенность, связанная с необходимостью определения оборудования по его текстовому обозначению, а также определения исходной схемы для рассмотрения каждой заявки. Информация об оборудовании в тексте заявок находится не в стандартизированной форме, для ее приведения к виду БДэсопз разрабатывается специальный модуль.
В Базе данных по заявкам БДЗаспрз необходимо ввести раздел о коммутациях по заявке и осуществлять (по каждой заявке из БДЗаспрз) экспорт данных (МКі)зсопз - (МКі)аспрз расширяются возможности обеих интегрированных систем. В АСПРЗ, благодаря интеграции с ЭСОПЗ, появляются следующие новые функции: автоматизация редактирования (принятия решения) заявок: в ЭСОПЗ вырабатываются рекомендации по решению (разрешить или отказать); при согласии пользователя АРМ с этими рекомендацию в атрибуты заявки автоматически записываются условия разрешения (например, режимные или релейные указания по заявкам), расширение функций просмотра информации по заявкам: пользователю могут отображаться не только карты заявок, но и осуществляться выборка заявок по атрибутам и предъявляться условия разрешения, а также протоколы экспертизы проработки заявок. В ЭСОПЗ, благодаря интеграции с АСПРЗ, появляются следующие новые функции: предъявление в процессе проработки заявок карт заявок из БДЗаспрз, а именно карт рассматриваемых заявок и тех заявок, на которые ссылается протокол экспертизы, формируемый в процессе автоматизированной проработки заявок, предъявление в процессе рассмотрения заявок (по инициативе пользователя АРМ) изображений электрических схем энергообъектов и электросети (при этом элементы изображения схем связаны с информацией по заявкам), функции ЭСОПЗ (проработка, мониторинг) для различных АРМ могут быть регламентированы системой прав доступа, задействованных в АСПРЗ (как правило, функции автоматизированной проработки заявок устанавливаются для одного из АРМ каждой оперативной службы, а остальные АРМ имеют только функции мониторинга). На основе изложенных выше требований автором разработано программное обеспечение «Мост» между системой типа «Заявки» и экспертной системой ЭСОРЗ для АРМ службы оптимизации электрических режимов в СО-ЦДУ ЮС РФ (см. Приложение 3)
В настоящее время разработан ряд систем типа АСПРЗ (разработки некоторых энергообъединений, Мосэнерго, ЦДУ ЮС и ВНИИЭ). Наиболее совершенные системы такого типа используют операционную платформу Windows и Базу Данных типа Oracle (например, система «ЗАЯВКИ-2» разработки ЦДУ и ВНИИЭ).
Системы типа ЭСОПЗ разрабатывались ВНИИЭ; при этом наибольшее развитие (и применение) получила экспертная система для «режимной» проработки ремонтных заявок ЭСОРЗ (разработка ВНИИЭ с участием ЦДУ, использование в службах СОЭлР ЦДУ и ОДУ Центра). Эти системы разрабатывались на основе инструментальной системы МИМИР (Малая информационная модель интеллектуальных решений). Прототип системы типа ЭСОПС для службы СРЗиА использовалась в одной из энергосистем (система СЭЗАР, разработка ВНИИЭ).
Зарубежные аналоги отечественных разработок в основном концентрируют внимание на долгосрочном планировании проведения ремонтов [27-32], а так же на контроле выработки ресурсов электротехнического оборудования. В зарубежной энергетике проработка ремонтных заявок не является проблемной областью в связи с достаточной близостью потребителя к электростанциями; развитыми межсистемными линиями электропередач; во многих случаях наличием дублирующего оборудования для вывода основного электрооборудования в ремонт. Хотя после аварии в энергосистеме восточного побережья США 14 августа 2003 года возможна большая заинтересованность зарубежных стран к данной проблеме, что возможно приведет к более интенсивному развитию данной области автоматизированного диспетчерского управления.
Структура интеллектуальной системы со специализированным логическим выводом (метод МИМИР)
Существующие информационные системы типа «Заявка» обеспечивают поддержку оперативного персонала энергообъединений при просмотре заявок, редактировании заявок, пересылке информации по заявкам. Уровень такой поддержки явно недостаточен, так как наиболее трудоемкие операции, связанные с принятием решений по заявкам (разрешить или отказать) и с определением условий разрешения заявок, выполняются «вручную».
Другим «традиционным» средством поддержки проработки заявок оперативным персоналом является использование расчетных технологических задач. При режимной проработке заявок используются программные комплексы для расчета установившегося режима УР в энергообъединениях. Это обусловлено тем, что режимные ограничения, накладываемые при разрешении заявок на вывод оборудования в ремонт, как правило, являются условиями существования УР.
Существует целый ряд комплексов для расчета УР, разработанных рядом организаций. Разумеется, использование этих программных комплексов целесообразно, но лишь в отдельных сложных ситуациях. «Массовое» использование этих программ для проработки всех заявок связано со значительными трудозатратами персонала. Это происходит по следующим причинам: -значительное количество данных, необходимых для работы расчетных комплексов, персонал должен вводить вручную; -определение «границ» существования УР в расчетных комплексах является, в определенном смысле, исследовательской работой, связанной с реализацией так называемых «траекторий утяжеления» режима; -для режимной проработки заявок недостаточно определить условия существования УР при отключении по заявкам ряда элементов оборудования (то есть ограничения «на время заявки»), но рассмотреть «потери» оборудования при возможных коротких замыканиях из-за коммутаций при вводе и выводе оборудования по заявке (ограничения «на время переключения» и «на время операций с ВЛ»); расчетные комплексы способны рассматривать режимы при коротких замыканиях, но точки этих замыканий нужно вводить вручную, предварительно определив «в уме», в каких именно узлах нужно задавать замыкания.
Вместе с тем, в оперативных службах энергообъединений (конкретно - в службе электрических режимов) работа с заявками основана на достаточно определенных правилах. Количество этих правил весьма велико, многие из них имеют эвристический характер. «Ручная» работа персонала по этим правилам требует привлечения очень большого объема информации (множество заявок с их приоритетами, характеристиками и состояниями, топология электросети, режимные инструкции, противоаварийная автоматика и др.). Работа с множеством заявок часто носит комбинаторный характер («конфликты» между заявками, пересмотр ранее принятых решений и пр.). Количество одновременно прорабатываемых заявок в службе энергообъединения может быть весьма велико (от нескольких десятков до сотен). Трудоемкость «ручной» проработки заявок может приводить к «человеческим» ошибкам, а эти ошибки, в свою очередь, приводить к тяжелым последствиям при реализации ошибочных решений по заявкам.
Анализ правил логического вывода, используемых в практической работе технологами-энергетиками, показывает, что эти правила применяются не изолированно, а «упакованы» в функциональные блоки, которые можно назвать «рассуждениями»[2]. Отсюда следует структура ИДС, основанная на специализированном логическом выводе, реализованном с помощью «программ-рассуждений» («сценариев») [3]. Такая система разработана ВНИИЭ и получила наименование МИМИР. Структура ИЭС МИМИР показана нарис. 2-3.
Особенностью МИМИР является сильный лингвистический аспект построения системы. Ограниченный естественный язык (ОЕЯ) является не только языком «внешнего» диалога, но и языком логического вывода. Основной лингвистической компонентой является вопрос на ОЕЯ. Входящий в структуру МИМИР лингвистический процессор осуществляет грамматический и семантический анализ ОЕЯ-вопроса и на основе информации в базе знаний осуществляет вывод ответа. Операция «вопрос» является основной для организации логического вывода в МИМИР и, тем самым, является основным оператором языка построения программ-рассуждений. Поэтому этот язык назван «языком вопросного программирования» (ЯВП) [3]. В данной работе для ЯВП используется также синтаксическое наименование «язык МИМИР». В ЯВП оператор «вопрос» дополнен рядом других операторов, предназначенных, в основном, для анализа ответов на вопросы и для взаимодействия с пользователями.
Текст вопроса заключен в кавычки, завершается знаком вопроса. В тексте вопроса могут быть ссылки на линейки ранее полученных ответов (обозначается знаком $) и на отдельные числовые значения, содержащиеся в ячейках - «слотах» (обозначается знаком ). В данном вопросе логический номер заявки ранее помещен в слот 1.
Вопрос в последнем примере запрашивает множество энергообъектов, связанных с оборудованием, входящим во множество сечений, в которые входит оборудование по заявке 1.
Анализ СВ начинается «с конца», т.е. с конечной вложенной конструкции. Эта конструкция выделяется как отдельный вопрос, а ответ на этот «вложенный вопрос» подставляется (в виде линейки) как дополнительное условие в предыдущее «вложение» или (если вложений больше нет) - в основной ПВ.
Для представления в МИМИР знаний о предметной области используется формализм структурированных семантических сетей. Принцип этого структурирования следующий: среди множества понятий предметной области выделяются семантические группы (СГ) - подмножества однородных понятий, таких, что для описания предметной области не требуется задавать непосредственные связи между элементами одной и той же группы - эти элементы могут связываться через другие СГ.
Структура данных Базы знаний МИМИР-3
При эмуляции МИМИР-системы посредством реляционной БД особого внимания требует обеспечение приемлемой скорости выполнения ОЕЯ-запросов. Основные затраты времени при логическом выводе в МИМИР-системах приходятся на обработку ОЕЯ-вопросов. В системе-советчике для проработки ремонтных заявок процедура, связанная с рассмотрением одной заявки, требует выполнения порядка 1000 ОЕЯ-вопросов. Рассмотрение одной заявки должно занимать не более 1-2 минут. Отсюда вытекают требования к времени выполнения одного ОЕЯ-вопроса.
Эксперт-технолог, создающий систему правил МИМИР-системы, в общем случае не имеет представления о механизме интерпретации ОЕЯ-вопросов в реляционной БД. Он не может целенаправленно влиять на скорость их выполнения посредством изменения их структуры. С другой стороны, непосредственная трансляция ОЕЯ-вопроса в последовательность SQL-операторов может приводить к существенным задержкам реакции системы по сравнению с минимально возможным временем. Поэтому механизм интерпретации ОЕЯ-вопросов должен быть "интеллектуальным", т.е. обладать средствами анализа и выбора оптимального метода интерпретации в зависимости от характера запроса.
Современные серверные модули реляционных БД содержат в качестве компонента оптимизатор, основной функцией которого является сокращение времени выполнения SQL-запросов. По аналогии с этим целесообразно встроить оптимизатор как компонент в экспертную систему. Если интеллектуальная система использует локальную БД, такой компонент будет служить одновременно SQL-оптимизатором и логическим оптимизатором обработки ОЕЯ-вопросов. При использовании сервера интегральной реляционной БД этот компонент должен выдавать указания оптимизатору сервера БД для наилучшего выполнения запросов.
Оптимизатор использует статистическую информацию о состоянии данных в Базе Данных, какие семантические группы связаны между собой большим количеством связей, а какие один к одному размерность семантических групп указывает о возможном количестве данных получаемых после выполнения.
На первом этапе ОЕЯ-вопрос подвергается лексическому и синтаксическому анализу, результатом чего является его внутреннее представление. Оно отражает структуру ОЕЯ-вопроса и содержит упоминаемые в нем объекты модели данных экспертной МИМИР-системы: имена семантических групп и их элементов, номера элементов СГ, идентификаторы временных множеств ("линеек"). Выше описано внутреннее представление ОЕЯ-вопроса как конструкции из элементарных ОЕЯ-вопросов.
На втором этапе внутреннее представление запроса приводится к канонической форме в SQL. Далее запрос подвергается оптимизации. Преобразования могут быть семантическими, в которых получаемое представление не является семантически эквивалентным начальному представлению, но гарантирует, что результат выполнения преобразованного запроса совпадает с результатом обработки запроса в начальной форме при соблюдении ограничений, существующих в хранилище данных системы. Ограничения могут быть следующим - элементы СП не могут быть связаны с элементами СГ2 , а подзапрос содержит вычисления некоторых связей между этими группами, следовательно результат запроса пустое множество которое подставляется в каноническую форму и изменяет логику выполнения.
Также могут применяться различные преобразования, "улучшающие" начальное представление запроса. Например, изменение последовательности применения ограничений с более быстрых к более долгим, что на следующем этапе процедурного выполнения, позволит при получении в одном из условий пустого множества вообще не выполнять более долгие ограничения.
После выполнения второго этапа обработки запроса его внутреннее представление остается непроцедурным (то есть физически как выбирать данные и в какое последовательности выполнять реляционные операции еще не определено), хотя и является более эффективным (в отношении времени обработки запроса), чем начальное.
Третий этап состоит в анализе возможных альтернативных процедурных планов (алгоритмов) выполнения запроса, построенных в соответствии с внутренним представлением запроса, полученным на втором этапе. Для каждого плана оценивается время обработки запроса. В этой оценке используется статистическая информация о состоянии базы данных, доступная оптимизатору. Из набора возможных планов выбирается тот, который обеспечивает наименьшее время выполнения. Внутреннее представление запроса преобразуется так, чтобы оно соответствовало выбранному процедурному плану.
Для уменьшения времени выполнения операции ограничения в реляционных системах управления базами данных используются индексы по полям, на которых задано условие этой операции. Индекс поля реляционной таблицы - это отсортированный список обратных ссылок значений поля на номер записи в таблице.
Из данной формулы вытекает, что наиболее часто используемые запросы вида а) следовательно в первую очередь максимально увеличить скорость таких запросов для этого мы введем индекс по полям №СГ1, №СГ2 ,№ элемента СГ2 как стандартный ход по увеличению скорости обработки запросов в реляционных БД.
Рассмотрим для примера времена обработки ОЕЯ-запросов: 1) без индексов, 2) с индексами без оптимизатора, 3) с индексами и оптимизатором. В скобках даны коэффициенты ускорения, обеспечиваемого второй и третьей стратегиями по отношению к первой. Статистика получена на компьютере с процессором Intel Pentimn III при тактовой частоте 1 Ггц в режиме избытка оперативной памяти относительно объема хранилища данных. С ростом производительности компьютера выполнение запросов при любой стратегии ускоряется.
При выборе из альтернативных процедурных планов нет смысла оптимизировать запрос, если время, затраченное на выбор нужного процедурного плана, сопоставимо со временем выполнения запроса. Например, запрос с уровнем вложенности N может иметь около (N-1)! различных вариантов процедурного выполнения. Время на решение этой задачи близко к времени выполнения запроса, поэтому можно приступить к выполнению запрос немедленно без рассмотрения альтернативных планов.
Работа с заявками в оперативном диспетчерском управлении
В настоящее время не существует систем-советчиков дежурного диспетчера по проработке заявок. Специфика онлайнового диспетчерского управления не позволяет использовать для этих целей системы ЭСОРЗ без изменений. Вместе с тем, использование имеющейся в ЭСОРЗ информации при дополнении ЭСОРЗ рядом новых функций позволяет создать «диспетчерскую» версию ЭСОРЗ. Для этого необходимо определить те функции оперативного диспетчерского управления, которые связаны с использованием информации по ремонтным заявкам. К таким функциям диспетчерского управления можно отнести: -контроль коммутационного состояния электрической сети (для текущего или для определенного заданного времени); -выявление нештатных (не определенных заявками) изменений положений коммутационных аппаратов и изменений состояния элементов оборудования; автоматизация ввода и проработки аварийных (внеплановых) заявок для нештатных изменений; -определение режимных условий открытия заявок; -определение режимных условий закрытия заявок.
Ниже для этих функций будут рассмотрены следующие вопросы: -использование имеющихся в системе ЭСОРЗ данных для выполнения соответствующих диспетчерских функций; -необходимость разработки новых (отличных от задач ЭСОРЗ) задач диспетчерской версии экспертной системы; алгоритмические требования к этим задачам.
Определение коммутационного состояния электросети необходимо дежурному диспетчеру, по крайней мере, для следующих целей: -для ретроспективного анализа «прошедших» режимов сети (в частности, при определении причин возникновения аварийных ситуаций); -для анализа предстоящих коммутационных состояний сети (например, при планировании операций по реконфигурации сети); -для контроля текущего коммутационного состояния электросети (определение «нештатных» отключений в коммутационной схеме, контроль пределов режимных параметров).
В ОИК существует функция архивирования телесигнализаций (ТС) положений коммутационных аппаратов. Казалось бы, этого достаточно для определения коммутационного состояния электросети для заданного «прошедшего» момента времени - необходимо лишь считать соответствующий срез ТС из архива. Во многих отечественных энергообъединениях, нет достаточной полноты телесигнализаций для определения состояния элементов оборудования. Таким образом, запомненной в архиве информации по ТС, обычно, недостаточно для ретроспективного анализа режима. Дополнение «среза» ТС «срезом» информации о заявках, которые были открыты в заданное время, позволит полностью определить сети для этого времени. Задача «восстановления» положений коммутационных аппаратов на основе информации о заявках рассмотрена в [18] здесь эта задача не рассматривается. В этой задаче нет возможности использовать ТС - информацию о положении выключателей, поэтому единственным источником информации является информация: -об открытых (на заданный момент времени) заявках; -о разрешенных (на заданный момент времени) заявках. Множество Мез заявок, отвечающих указанным выше условиям, должно быть «проработано» в системе ЭСОРЗ, и для каждой заявки 3j, принадлежащей этому множеству, при проработке определено (и заполнено в БД ЭСОРЗ) множество коммутаций Kjo, соответствующих отключениям коммутационных аппаратов (выключателей). Таким образом, может быть найдено общее множество отключений при выводе оборудования «с восстановлением поля» на подстанции, определенной заявкой 3j. Поэтому из множества Kjo необходимо конъюнктивно исключить множество KJB - тогда получим необходимое множество отключений. «Наложив» найденные по (5-1) отключения на «нормальное» коммутационное состояние сети, можно получить коммутационное состояние для заданного «предстоящего» момента времени. Например, диспетчер может запросить коммутационные состояния сети на начало следующего интервала заданного диспетчерского графика или на момент начала следующей смены.
Множество «продолжительных» ограничений Оп, соответствующее множеству Мз проработанных заявок, не зависит от порядка проработки заявок (при изменении этого порядка может измениться только «привязка» ограничебний к заявкам). Это множество ограничений целесообразно использовать для контроля параметров текущего режима. Для этого необходимо провести операцию упорядочивание множества ограничений Уог. Эта операция заключается в следующем: -для заданного момента времени t выделяется множество открытых «синхронных» заявок Мосз; -определяется множество «продолжительных» ограничений Оп (Мосз); -производится минимизация ограничений из Оп путем определения «одноименных» ограничений (ограничения на одинаковые параметры в одинаковых направлениях); из «одноименных» ограничений для контроля режима выбирается ограничение с наименьшим значением (это наиболее «сильное» ограничение) - в результате формируется множество ограничений Оп. Описанная выше операция должна производиться периодически (в темпе контроля текущего режима).
Найденное множество ограничений Оп используется для контроля соответствующих режимных параметров. Для этого выполняется: -формирование текстового списка для Оп для отображения пользователям ЭСОРЗ; -передача значений ограничений Оп в подсистему обработки оперативной информации ОИК для автоматического сравнения телеизмеряемых (и «дорасчитываемых») значений режимных параметров с пределами, определяемыми ограничениями. Для последней из указанных выше операций следует сделать уточнение. Некоторые из ограничений Оп имеют не скалярный, а функциональный характер (в соответствующие функциональные выражения входят измеряемые параметры ОИК). Поэтому перед контролем в ОИК должна производиться «скаляризация» этих функционалов. Следует сказать, что предлагаемый метод контроля текущего режима связан с некоторой методической неточностью. Это определяется тем обстоятельством, что «продолжительные» ограничения в ЭСОРЗ считаются неизменными в течение всего времени выполнения работ по заявке. Это приводит к «ужесточению» контроля режима. Более «точный» контроль режима можно осуществить, используя результаты «анализа топологии» электросети. Но при этом следует отметить, что проверка правильности анализа топологии опять-таки используется информация по ремонтным заявкам.
