ИНФОРМАЦИОННЫЕ СИСТЕМЫ РЕАЛЬНОГО ВРЕМЕНИ
ДЛЯ ЦЕНТРОВ УПРАВЛЕНИЯ

Оперативно-информационные комплексы и системы технологических задач

Авторы: Нестеренко В.Л., генеральный директор ЗАО "Монитор электрик", Карасев Ю.Д., канд. техн. наук, первый заместитель генерального директора ЗАО "Монитор электрик".

Опубликовано: Информационно-аналитический журнал "Энергоэксперт" № 2 (37). - 2013. - С. 24-27.

Оперативно-информационные комплексы (ОИК), пока еще работающие в большинстве диспетчерских центров электроэнергетики России, удивительным образом совмещают функции подсистемы SCADA (Supervisory Control And Data Acquisition, диспетчерское управление и сбор данных — программный пакет, предназначенный для разработки и обеспечения работы в реальном времени систем сбора данных, их обработки, дистанционного управления и представления информации оператора или диспетчерам), а также подсистемы технологических приложений, укомплектованных в зависимости от уровня объекта управления и решаемых задач, называемые подсистемами EMS (Energy Management System, программный пакет системы управления производством и передачей электроэнергии) и DMS (Distribution Management System, программный пакет систем управления распределением электроэнергии). ОИК – это информационные системы, которые были созданы под заказчика и при тесном взаимодействии с заказчиком. Их быстрое и легкое внедрение, долгую и уже не современную жизнь можно объяснить хорошей интеграцией в прежнюю систему управления на сравнительно современной технической базе. Цель статьи – показать иной подход к формированию состава пользовательских приложений для программно-аппаратных комплексов (ПТК) центров диспетчерского управления электроэнергетическими системами, отличающийся от складывающегося в последние годы направления.

Сегодня заказчикам предлагаются готовые SCADA/EMS/DMS системы зарубежного производства, которые разработаны на концепциях конца прошлого века. Отметим, что принципы построения ОИК сформировались еще раньше. Если функции подсистемы SCADA определены достаточно четко и не вызывают больших дискуссий, то опыт внедрения EMS/DMS заставляет вернуться к анализу состава приложений, их взаимосвязей, участия в работе технологических подсистем персонала диспетчерских центров.

Производителями SCADA/EMS/ DMS систем стандартом де-факто был признан некоторый состав приложений, считающийся необходимым для установки в центрах управления электроэнергетическими системами. Этот перечень приведен во многих технических и рекламных материалах известных компаний с небольшими отличиями. Так, для подсистем DMS он может выглядеть следующим образом:

формирование моделей электрической сети;
оценка состояния;
анализатор топологии сети;
расчет потокораспределения;
регулирование напряжения/реактивной мощности;
управление последовательностью переключений;
мониторинг временных элементов сети;
обеспечение проведения работ по переключениям;
управление восстановлением сети после аварии;
расчет потерь в электрической сети;
оценка надежности (n-1);
расчет токов коротких замыканий;
определение места повреждения участка сети;
расчет отключающей способности коммутационных аппаратов;
краткосрочный прогноз нагрузки;
расчет показателей эффективности энергоснабжения;
тренажер диспетчера.

Казалось бы, нужно брать этот список, добиваться включения перечисленных программ в автоматизированные систему управления электрическим сетями, и задача будет решена. Именно в таком объеме и производят в России поставку комплексов SCADA\EMS\DMS интеграторы и зарубежные вендоры.

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

Причины разные, остановимся на некоторых, имеющих системный характер. Напомним эволюцию развития средств автоматизации в диспетчерских центрах энергосистем.

В конце 60-х гг. прошлого века начали разрабатываться компьютерные программы, позволяющие решать задачи, которые прежде выполнялись только методами аналогового моделирования. Это программы расчетов установившихся режимов, статической и динамической устойчивости, токов коротких замыканий, оптимизации по активной и реактивной мощности. Это важнейшие фундаментальные задачи электроэнергетики, переведенные на современную платформу и находящиеся в эксплуатации до сей поры. Программы имели свои локальные базы данных, работали в режиме off-line, информационно не были связаны между собой.

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

Однако стратегически важная задача следующего этапа – внедрение автоматизированных подсистем диспетчерского управления (EMS, DMS), использующих реальные данные режимов энергосистем, режим on-line, до сих пор не реализована. Новые задачи, которые можно было бы решать на основе реальных данных, не находят должного применения. Проблемы проявляются в недостоверности, нестабильности результатов, трудоемкости настроек приложений и управления данными, и, что самое важное, в неприменимости большинства результатов в существующей российской системе диспетчерского управления. И, что не менее важно, обнаруживается несоответствие масштаба получаемых результатов сделанным на начальном этапе и постоянно производимым в последующем затратам. Добавление числа приложений к вышеприведенному списку, возможно, только ухудшит ситуацию. Причины трудностей на этапе перехода в режим реального времени для многих специалистов очевидны, но...

В режиме off-line процесс решения задач организационно значительно проще, потому что имеет одного конкретного «хозяина», отвечающего за правильность и своевременность представленного результата. Ситуация благоприятна еще тем, что время на выполнение работы отводится относительно большое, и есть возможность выполнить перерасчет с немного измененными владельцем процесса исходными данными.

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

Решение задачи в темпе процесса или за относительно короткое время, например, в течение нескольких минут наталкивается на проблему адекватной оценки результата субъектом, в нашем случае технологом, отражающей его уверенность или неуверенность в правильности появившегося сигнала, числа, потока данных, поведения графика. Интересно, что абстрактное понятие «технолог» разделяется, как минимум на два субъекта: диспетчер (получатель результата) и настройщик приложения, обязанный постоянно следить за получаемым результатом, изменениями в энергосистеме и корректировать исходные данные, даже при безупречном алгоритме работы программы.

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

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

И это лишь часть проблемы высокой стоимости владения информационными системами (TCO – Total Cost of Ownership), иными словами, значительных эксплуатационных затрат на обеспечение ее функционирования.

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

Сегодня персонал, перегруженный «своей» работой и постоянно- периодически привлекаемый к настройкам вновь внедряемых техно

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

В новом проекте компании Microsoft – SERA собраны многие рекомендации для систем управления энергетическими компаниями, которые, как то могли бы способствовать выходу из создавшегося положения. Это свободный, но защищенный обмен информацией внутри корпорации. Объединение всех располагаемых информационных ресурсов в мегабазу данных с возможностью доступа из любых приложений различных производителей через интеграционные платформы с использованием стандартов МЭК, в частности, CIM для операционной деятельности, и других международных и промышленных стандартов для интеграции и обмена. Создаваемые условия для интеграции разнородных приложений позволяют их достаточно просто резервировать и даже конкурентно дублировать. Появляется возможность управления изменениями без остановки информационной системы. Все в целом, должно привести к существенному снижению ТСО. Идеи проекта позволяют надеяться, что SERA (RA – Reference Architecture) станет в будущем системой эталонной архитектуры, но при этом выбор состава приложений по-прежнему полностью возлагается на заказчика, так как с точки зрения системных, архитектурных вопросов отходит на второй план.

Подведем предварительные итоги.

При внедрении и эксплуатации технологических подсистем в режиме on-line создается цепочка проблем: значительное усложнение организации процессов настройки и поддержки, сложности оценки результатов решений, представляемых системой, значительные трудозатраты и эффект отторжения, ввиду необходимости поддерживать прежнюю систему принятия решений, контроля, отчетности и пр.

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

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

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

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

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

При таком подходе будет обозначен «хозяин» функции/бизнес-процесса, что сформирует условия подобные задачам off-line. Чем-то это может напоминать популярные в прошлом «автоматизированные рабочие места» (АРМ). Произойдет снижение затрат на ручные операции, сокращение времени решения задачи, повышение достоверности результата.

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

Чтобы задача была обозримой, целесообразно перед началом работы представить проект укрупненно – по подсистемам организации, после чего отдать на экспертизу потенциальному заказчику.

Для примера, рассмотрим одну из ветвей задачи – «Планирование развития энергосистемы». Автоматизировано формируется поузловой баланс; накладывается на реальный режим (SCADA) или прогнозный режим сети (Forecast Mode); вводятся запросы на подключение потребителей путем использования данных о выданных техусловиях (technical specifications); выбираются автоматически из базы данные об ограничениях по линиям и трансформаторам

(Limitations Data); создается структура балансов мощности и энергии, рассчитываются предельные режимы; возвращение к базе данных по ограничениям; проводится анализ нарушений (Violation Analysis); анализ серии полученных результатов; возврат на корректировку техусловий или подготовка набора отчетов по выбранному варианту (нескольким «лучшим» вариантам) развития энергосистемы. Даже при совершенно неглубоком анализе, очевидно, что в цепочке появляются места для разработки и включения новых приложений, не отраженных в типовом списке. Решение всей задачи происходит с меньшим вмешательством человека.

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

Одно и то же приложение нередко используется технологами разных служб, действующих на разных этапах планирования и управления, предъявляющих по роду своей деятельности различные требования по пользовательскому интерфейсу, по составу/объему данных, по форме представления результатов. В связи с этим, возможно применение программ одного функционала, но с различающимися алгоритмами. Приложения должны быть достаточно «гибкими» – настолько, чтобы позволять встраивание их в разные автоматизируемые процессы.

Кратко о декомпозиции функций диспетчерского центра.

По времени: планирование – оперативное управление – отчет, анализ. Оперативное управление распространяется на период диспетчерской смены, сутки. Планирование и соответствующая отчетность: год-квартал- месяц-неделя-сутки, нетипичные периоды (этап ввода значимого объекта, природные явления, незапланированные события и др.).

По предметам деятельности: оборудование подстанций, оборудование ЛЭП, оборудование РЗА, энергосистема в целом.

По состоянию: нормальный режим, ремонтный режим, аварийный режим, послеаварийный восстановительный.

По пространственному положению: если предприятие и предметы деятельности (объекты управления) имеют распределенный характер.

По элементам структуры: по предприятию в целом, по структурным подразделениям, по рабочим местам.

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

Пример формирования перечня функции персонала диспетчерского центра по работе с электросетевым оборудованием путем декомпозиции по оси времени:

разработка предложений к годовому плану ремонтов с помесячной разбивкой;
согласование плана годовых ремонтов;
контроль и корректировка выполнения годовых и месячных ремонтов;
утверждение скорректированного месячного плана ремонтов;
утверждение/согласование плана на неделю;
рассмотрение заявок и анализ допустимости вывода в ремонт оборудования;
организация выведение оборудования в ремонт/из ремонта;
координация аварийно-восстановительных работ;
отчет об отклонении хода ремонтов от запланированного за сутки, месяц, год;
анализ выполнения ремонтной компании в разрезе плановых периодов.

Еще одним направлением повышения эффективности внедрения новых технологий SCADA/EMS/DMS представляется снижение общего количества диспетчерских центров. На момент распада СССР в Российской Федерации было порядка 450 диспетчерских центров разного уровня. На сегодняшний момент при сохранении примерно того же уровня электропотребления, который был в 1990 году, число диспетчерских центров возросло примерно в два раза. Возникла острая проблема нехватки кадров, различные компании вольно или невольно конкурируют за квалифицированных специалистов для укомплектования «своих» центров. Все более сложным вопросом становится техническое обеспечение ДЦ, затраты на инфраструктуру растут. При большом количестве диспетчерских центров влияние эффекта отторжения новых технологий также возрастает: при каждом внедрении требуется переучивать большое количество персонала, привыкшего к другим технологиям и методам работы.

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

Выводы

Создание открытой информационной системы, представляющей площадку для приложений различных производителей, поддерживающих открытые протоколы интеграции, является перспективным направлением для диспетчерских центров управления электроэнергетическими системами и энергообъектами.
Для эффективного функционирования подобных комплексов необходимо выполнение специальных процедур системного характера и дополнительного усовершенствования программного обеспечения, позволяющих дополнить обычный пакет приложений и, тем самым, органично встроить программно-технические средства в организационную систему предприятия.
Значительное сокращение инфраструктурных затрат, кадровых ресурсов, можно было достичь за счет укрупнения диспетчерских центров и зон их операционной деятельности. Однако вопросы реорганизации системы оперативно-диспетчерской управления выходят за рамки настоящей статьи.