Содержание к диссертации
Введение
Глава 1. Концепция построения и функциональные модули автоматизированной системы оперативного управления режимами работы электростанции 17
1.1. Структура автоматизированной системы оперативного управления режимами работы электростанции 17
1.2. Расположение автоматизированной системы оперативного управления режимами работы в структуре локально-вычислительной сети электростанции 20
1.3. Основные функции автоматизированной системы оперативного управления режимами работы электростанции 22
1.4. Обоснование функций автоматизированной системы оперативного управления режимами работы электростанции 23
1.5. Разбиение функций автоматизированной системы оперативного управления режимами работы электростанции на модули 25
Глава 2. Межмодульное взаимодействие и система хранения данных автоматизированной системы оперативного управления режимами работы электростанции 27
2.1. Выбор интерфейсов взаимодействия с АСУТП и АСУП автоматизированной системы оперативного управления режимами работы электростанции 27
2.2. Описание интерфейсов межмодульного и межсистемного взаимодействия 28
2.2.1. Получение плана балансирующего рынка 28
2.2.2. Получение задания теплосети 29
2.2.3. Получение задания промышленной нагрузки 31
2.2.4. Получение данных о режиме работы оборудования 32
2.2.5. Получение поправок в режим работы оборудования 37
2.2.6. Получение ограничений на режим работы оборудования 40
2.2.7. Получение дополнительных параметров 42
2.2.8. Получение данных пользовательского ввода 44
2.2.9. Методы ведения архива 52
2.2.10. Интеграция с АСУТП 53
2.3. Методы хранения данных 66
2.3.1. Сервер ввода-вывода 66
2.3.2. Сервер хранения настроек программы 67
2.3.3. Архивный сервер 68
2.3.4. Сервер вычислений 69
2.3.5. Локальный сервер ввода-вывода 70
Глава 3. Реализация основных функций 72
3.1. Расчет распределения нагрузки 72
3.1.1. Разбиение оборудования на группы 72
3.1.2. Построение энергетической характеристики группы оборудования 73
3.1.3. Составление уравнений расчета 76
3.1.4. Методика решения уравнений 77
3.1.5. Методика поиска энергетических характеристик 78
3.2. Раздача задания на АРМ машинистов турбоагрегатов 83
3.3. Монитор состояния оборудования 84
3.4. Расчет удельных расходов топлива 84
3.4.1. Выбор методики расчета 86
3.4.2. Ввод формул и корректировка шаблонов 88
3.4.3. Использование интерпретатора формул при расчете 88
Глава 4. Внедрение системы и оценка экономической эффективности 118
4.1. Внедрение системы 118
4.1.1. Установка модуля распределения нагрузки на ТЭЦ-23 ОАО «Мосэнерго» 118
4.1.2. Установка модуля мониторинга параметров на ТЭЦ-21 ОАО «Мосэнерго» 122
4.1.3. Тестирование интерфейсов доступа к ПТК «Квинт» в ОАО «НИИТеплоприбор» 124
4.2. Экономическая эффективность 125
4.2.1. Уменьшение расхода топлива 125
4.2.2. Повышение мотивации персонала 126
4.2.3. Ввод контроля действий 126
Выводы 128
Список литературы 130
- Структура автоматизированной системы оперативного управления режимами работы электростанции
- Получение данных пользовательского ввода
- Использование интерпретатора формул при расчете
- Установка модуля распределения нагрузки на ТЭЦ-23 ОАО «Мосэнерго»
Введение к работе
Актуальность работы. Необходимость оптимального управления режимами работы электростанции и энергосистем всегда остается важным вопросом в энергетике.
В настоящее время, в связи с вводом новых правил функционирования рынка электроэнергии, особенно важной стала задача управления ТЭЦ со сложным составом оборудования (при наличии на ТЭЦ блочных, неблочных агрегатов и пиковых водогрейных котлов) в условиях НОРЭМ.
В данных условиях, при оптимальном управлении режимами работы ТЭЦ, одной из главных задач является получение максимальной суммарной прибыли станции (ТГК) от ее участия в продаже электроэнергии по регулируемым договорах (РД), на рынке "на сутки вперед" (РСВ), и на балансирующем рынке (БР), а также от продажи тепловой энергии. Для обеспечения данного условия основное внимание необходимо уделять минимизации топливных затрат, как главного показателя экономичности работы ТЭЦ.
Оптимальное управление режимами работы электростанций -традиционно одна из сложных научных и практических задач, обусловленная неопределенностью исходной информации, многовариантностью решения, трудностью учета реального технического состояния оборудования, а также другими факторами. Тем не менее, в настоящее время разработаны различные методики и программные комплексы на их основе для внутристанционной оптимизации режимов работы оборудования.
Причиной сложности использования программных комплексов оптимального управления режимами работы электростанции является значительная доля ручного ввода исходных данных для выбора оптимального режима при каждом изменении задания. Это обусловлено отсутствием интерфейсов взаимодействия между программными комплексами и системами автоматизации, установленными на электростанциях.
Актуальность создания программных комплексов управления режимами работы электростанции обусловлена также появлением новых АСУТП и АСУП, реализующих алгоритмы управления основным оборудованием, включая алгоритмы перехода с одного режима на другой. Разработка автоматизированной системы оперативного управления режимами работы электростанции позволяет в автоматическом или полуавтоматическом режиме формировать задание для блочных и локальных АСУТП, выводя управление электростанцией на новый уровень.
Целью работы является усовершенствование методического, технического и информационного обеспечения АСУТП на базе современных программно-технических комплексов для практической реализации в автоматизированном режиме задачи оперативного управления режимами работы оборудования электростанции. В рамках поставленной цели решаются следующие конкретные задачи:
- формирование концепции построения автоматизированной системы оперативного управления режимами работы электростанции;
- разработка методов и алгоритмов обеспечения совместимости и интеграции АСУП и АСУТП для автоматизированной системы оперативного управления режимами работы электростанции;
- разработка интерпретатора формул для расчета фактического удельного расхода топлива с возможностью подключения алгебраических функций сторонних разработчиков;
- создание модуля связи с информационным обеспечением АСУТП для автоматизированной системы оперативного управления режимами работы электростанции и его тестирование на примере ПТК «Квинт»;
- создание программного комплекса для оперативного управления режимами работы электростанции, состоящего из нескольких модулей: модуля распределения тепловой и электрической нагрузки между генерирующим оборудованием, модуля расчета фактического удельного расхода топлива для
оценки эффективности распределения, модуля мониторинга состояния оборудования;
6 - апробация разработанной автоматизированной системы на электростанции с целью проверки работы созданных интерфейсов взаимодействия с другими программными комплексами. Научная новизна работы состоит в следующем.
Предложена концепция создания автоматизированной системы оперативного управления режимами работы электростанции.
Разработаны методы и алгоритмы обеспечения совместимости и интеграции АСУП и АСУТП для автоматизированной системы оперативного управления режимами работы электростанции.
Разработан интерпретатор формул для расчета фактического удельного расхода топлива с возможностью подключения алгебраических функций сторонних разработчиков.
Практическая значимость работы. Разработан программный комплекс, выполняющий функции:
распределения суммарной тепловой и электрической нагрузки между генерирующим оборудованием электростанции;
оценки экономического эффекта от оптимального распределения нагрузки посредством анализа значений фактического удельного расхода топлива до и после оптимизации;
объединения наиболее важных показателей работы электростанции для поставленной задачи с разных АСУТП или АСУП в одной системе;
повышения информативности и адекватности выбора режима работы оборудования, снижение количества отклонений от утвержденного диспетчерского графика;
ретроспективной оценки режимов работы оборудования с целью выявления нарушений, оценки качества выбора режимов работы и принятия мер по устранению неисправностей.
повышения конкурентоспособности электростанции при работе на рынке электроэнергии и мощности.
Достоверность и обоснованность результатов подтверждается:
- применением современных методов математического моделирования объекта;
- использованием современных информационно-технических средств при решении поставленной задачи;
- положительным эффектом от внедрения разработанной автоматизированной системы.
Реализация результатов: Результаты работы по созданию автоматизированной системы оперативного управления режимами работы электростанции прошли апробацию и внедрены в промышленную эксплуатацию на ТЭЦ-23 ОАО «Мосэнерго», в том числе интерфейс ввода-вывода данных из ПТК «Квинт». Алгоритм построения базы данных оборудования для оперативного управления применяется в ИВЦ филиал ОАО «Мосэнерго». Мониторинг состояния оборудования внедрен на ТЭЦ-21 ОАО «Мосэнерго».
Личный вклад автора:
- разработана концепция построения автоматизированной системы оперативного управления режимами работы электростанции;
- разработаны алгоритмы взаимодействия между АСУТП и АСУП при решении задач оперативного управления режимами работы электростанции;
- создан программный комплекс для оперативного управления режимами работы электростанции;
- разработаны модули ввода-вывода данных АСУТП и эргономичный интерфейс пользователя;
- даны рекомендации по внедрению автоматизированной системы оперативного управления режимами работы электростанции;
6 - определено расположение разработанного программного комплекса в системе управления электростанцией.
Апробация работы. Разделы и положения диссертации докладывались и обсуждались на 5 научно-технических конференциях и отраслевых совещаниях, в том числе на всероссийской научно-практической конференции «Повышение эффективности энергетического оборудования» (Иваново, 2010), на всероссийской научно-практической конференции «Энерго - 2010» (Москва, 2010), на 22-й Международной научной конференции «Математические методы в технике и технологиях» (ММТТ-22) (Иваново, 2009), на международном семинаре «Networked embedded and control system technologies: European and Russian R&D cooperation» (Милан, 2009) и на конференции «International Universities' Power Engineering Conference» (Кардифф, 2010), и получили положительную оценку.
Публикации. Результаты диссертационной работы опубликованы в 7 научных работах, в том числе в 5 докладах на конференциях, в 2 статьях в журналах и сборниках, рекомендуемых ВАК. Результаты работы демонстрировались на выставках и получали призовые места. Модули разработанного программного комплекса побеждали в конкурсах инновационных разработок и получили рекомендательное письмо о внедрениях на предприятия от депутата Государственной думы РФ.
Структура и объем диссертации. Диссертация состоит из введения, четырех глав, заключения, библиографического списка, включающего 133 наименований. Содержит 142 страницы машинописного текста, 9 рисунков и 3 таблицы.
Структура автоматизированной системы оперативного управления режимами работы электростанции
Модель автоматизированной системы оперативного управления режимами работы электростанции построена исходя из декомпозиции функций системы [10; 11]. Такой подход обеспечивает возможность встраивания системы в существующую пирамиду управления электростанции. Он же позволяет избежать лишних расходов на внедрение автоматизированной системы оперативного управления за счет использования уже существующих компонентов. Общий принцип построения показан на рис. 1.
Автоматизированная система оперативного управления режимами работы электростанции встраивается в два уровня управления, один из них - уровень SCAD А систем, второй — MES уровень. Между уровнями расположен Fire Wall [12], шлюз, препятствующий проникновению несанкционированных данных на нижний уровень. Он обеспечивает безопасность данных, необходимых для технологического управления, их сохранность и возможности ввода-вывода для зарегистрированных программ. В большинстве случаев существует несколько однотипных шлюзов для обеспечения надежности, их функции могут быть дублированными.
Автоматизированная система оперативного управления режимами работы электростанции состоит из нескольких основных модулей. Обязательными модулями системы являются: база данных расчетов, сервер расчетов, сервер сбора данных. Все этим модули могут быть локальными, т.е. реализованными на одном компьютере. Такая реализация повысит надежность и скорость работы комплекса, но снизит его масштабируемость и значительно увеличит вычислительную нагрузку на отдельный физический модуль.
База данных расчетов - SQL-сервер [13 - 15], служащий для хранения данных, содержащий встроенные функции базы данных. Этот модуль является также интерфейсом для вывода данных на верхний уровень управления и в другие системы. Для защиты информации предусмотрена возможность создания пользователя с правами на доступ только к встроенным функциям, что обеспечит проверку запроса перед предоставлением информации. В базе данных расчетов хранятся все результаты и исходные данные расчетов, а также статистика пользователей и их настройки. Высокая загрузка сети в связи с использованием единой базы данных требует ввода алгоритмов оптимизации запросов.
Сервер расчетов служит для периодического или сигнального запуска задач. Сигнальный запуск подразумевает запуск задачи по внешней команде. Для взаимодействия с сервером расчетов и посылки сигналов используются функции SQL-сервера и .NET Remoting. Самой комплексной задачей оперативного управления является распределение нагрузки между генерирующим оборудованием [16]. Реализация сигнального вызова позволяет добавить и другие задачи на сервер расчетов.
Сервер сбора данных осуществляет функции сбора данных с АСУТП и других систем и загружает полученную информацию в базу данных расчетов. Для этого модуля предусмотрено множество протоколов сетевого обмена для доступа к другим системам. Интерфейсный принцип построения сервера сбора данных позволяет добавить отсутствующие интерфейсы, не нарушая его работу. Ручной ввод осуществляется с помощью разработанных клиентов сервера сбора данных.
Сервер передачи информации не является обязательным модулем программного комплекса. При этом его установка позволяет значительным образом повысить надежность системы. Он служит для передачи оперативной информации между начальником смены станции, машинистами энергоблоков и другим оперативным персоналом.
Архив служит для резервного копирования данных. Он не является обязательным модулем. В случае обрыва линий связи он может служить резервным хранилищем и поставщиком данных для других модулей. Такая связь предполагает прокладку резервных линий связи. В случае отказа сервера базы данных все модули переключатся на архив. При восстановлении связи архив начнет синхронизацию данных с базой данных расчетов.
Основным пользователем системы является начальник смены станции. Он рассчитывает распределение нагрузки между генерирующим оборудованием электростанции и пересылает задание по нагрузке машинистам энергоблоков. Специалисты АСУТП являются наладчиками системы. Инженеры ПТО имеют возможность просматривать информацию по распределению нагрузки, состоянию работы оборудования и удельному расходу топлива. Директор ТЭЦ, главный инженер могут просматривать обобщенные данные, такие как суточ ные удельные расходы топлива, выработка тепловой или электрической энергии.
Развязка данных между различными модулями позволяет говорить о расширяемости и взаимозаменяемости частей системы. При этом сосредоточение данных в единой базе предотвращает их дублирование и рассинхронизацию. Таким образом, все модули, как логические, так и физические могут быть заменены, добавлены или удалены из системы. База данных расчетов тоже является заменяемой, но для ее замены требуется написание дополнительного программного обеспечения способного изменить формат данных при их восстановлении из архива.
Получение данных пользовательского ввода
Под пользовательским вводом будем понимать обслуживание системы, временную подмену параметров, удаление ошибочно введенных значений, ведение переменных, хранящих настройки каждого пользователя. Для этого метода предусмотрены отдельные приложения, не зависящие от программно-технического комплекса, работающие непосредственно на сервере базы данных. Возможна работа этих приложений и на любых других компьютерах, подключенных к сети. Запуск таких программ необходим достаточно редко, поэтому ими пользуются в основном операторы, настраивающие программный комплекс. В дальнейшем эти программы запускаются в фоновом режиме для автоматической отправки необходимых данных. В частности, таким образом, реализовано хранение настроек пользователя.
Для взаимодействия с сервером баз данных может использоваться любой драйвер, поддерживающий базу данных MS SQL. Администраторы могут частично использовать Microsoft SQL Server Management Studio. Целиком использование этого программного продукта не представляется возможным в связи с методами хранения данных. Можно использовать встроенные средства для редактирования данных, изменения архива, подмены значений и т.д. Нельзя изменять бинарные поля базы данных. Для их изменения предусматривается несколько приложений, способных представить эти данные в удобном виде, т.е. декодировать их, и потом отправить их обратно на сервер, т.е. кодировать.
Сервер базы данных поддерживает три протокола взаимодействия: ODBC - это программный интерфейс доступа к базам данных. Он разработан фирмой Microsoft, в сотрудничестве с Simba Technologies на основе спецификаций Call Level Interface (CLI). Впоследствии CLI был стандартизован ISO. Стандарт CLI призван унифицировать программное взаимодействие с СУБД, сделать его независимым от поставщика СУБД и программно-аппаратной платформы [34 - 38].
В начале 1990 года существовало несколько поставщиков баз данных, каждый из которых имел собственный интерфейс. Если приложению было необходимо общаться с несколькими источниками данных, для взаимодействия с каждой из баз данных было необходимо написать свой код. Для решения возникшей проблемы Microsoft и ряд других компаний создали стандартный интерфейс для получения и отправки источникам данных различных типов. Этот интерфейс был назван Open Database Connectivity или открытая связь с базами данных.
С помощью ODBC прикладные программисты могли разрабатывать приложения для использования одного интерфейса доступа к данным, не беспокоясь о тонкостях взаимодействия с несколькими источниками.
Это достигается благодаря тому, что поставщики различных баз данных создают драйверы, реализующие конкретное наполнение стандартных функций из ODBC API с учётом особенностей их продукта. Приложения используют эти функции, реализованные в соответствующем конкретному источнику данных драйвере, для унифицированного доступа к различным источникам данных.
MFC усовершенствовала ODBC для разработчиков приложений. Истинный интерфейс ODBC является обычным процедурным API. Вместо создания простой оболочки процедурного API, разработчики MFC создали набор абстрактных классов, представляющих логические сущности в базе данных.
При применении ODBC требуется помнить, что данная технология доступа к данным не рассчитана на работу с большим числом клиентов. В том случае, если необходимо, чтобы с БД одновременно работало много активных клиентов, требуется использовать SQL API или специальный интерфейс для взаимодействия с конкретной БД. JDBC — платформенно-независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД, реализованный в виде пакета ja-va.sql, входящего в состав Java SE.
JDBC основана на концепции так называемых драйверов, позволяющих получать соединение с базой данных по специально описанному URL. Драйверы могут загружаться динамически во время работы программы. Загрузившись, драйвер сам регистрирует себя и вызывается автоматически, когда программа требует URL, содержащий протокол, за который отвечает драйвер.
SOAP - протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. SOAP является расширением протокола XML-RPC.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и другие. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.
SOAP является одним из стандартов, на которых базируются технологии веб-служб.
Под настройками пользователя будем понимать параметры внешнего вида программы пользователя, графического отображения, хранимых данных. Настройки пользователя могут содержать такие параметры как, ширина и высота окна для пользовательской программы, расположение вкладок программ, скрытие и открытие информации на вкладках, язык пользовательского ввода для приложений. Параметрами графического отображения можно считать настройки осей отображения графиков, маркеры, их количество, масштаб.
Хранимые данные — наиболее емкие настройки. К ним относятся пароли пользователей, уровни доступа к приложениям, их автозапуск, строки подклю чения к серверам, выборки баз данных, автоматически проводимые при запуске программы и ее использовании. К этим настройкам также относятся подписки на события, происходящие в базе данных и других приложения, а таюке пути для поиска подключаемых плагинов и дополнительных модулей.
Все настройки пользователя хранится в базе данных программного комплекса. В большинстве случаев поля для настроек определяются интерфейсом их записи. В базе данных они хранятся в поле типа varbinary, т.е. бинарном поле.
Двоичные данные переменной длины п могут иметь значение от 1 до 8000; max означает максимальную длину хранения, которая составляет 2 -1 байт. Размер хранения — это фактическая длина введенных данных плюс 2 байта. Введенные данные могут иметь размер 0 символов.
Интерфейс разбирает данные настройки, и превращает их в массивы данных, понятные конкретной программе. Соответственно, в самой программе или ее конфигурационном файле, требуется хранить только строку подключения к базе данных, логин, пароль и набор данных, который необходимо получить. Эти параметры передаются в интерфейс.
Возможно хранение этих настроек в реестре Windows. Такой метод не является оптимальным, т.к. создает несколько путей хранения и делает невозможным процесс переноса приложения из одной системы в другую без потери настроек.
В случае со встроенной авторизацией в базе данных, т.е. нахождении компьютера под управлением домена, логин и пароль хранить не требуется, строка подключения также упрощается, т.к. контроллер домена берет на себя часть функций, реализующих подключение к серверу.
Еще одним методом создания строки подключения к серверу для начального запроса настроек пользователя является создание файла. Он создается стандартными средствами Windows. Далее необходимо изменить его расширение на UDL. Сведения о соединении можно указать в UDL-файле, однако этого следует избегать. UDL-файлы не подвергаются шифрованию, и строки соединения хранятся в них в виде простого текста. Так как UDL-файл представляет собой внешний файловый ресурс для приложения, его нельзя защитить средствами .NET Framework.
Наряду с недостатками этого метода, у него есть и свои преимущества. Универсальность, возможность работы сразу с несколькими драйверами доступа к данным и поддержка контроля правильности ввода на уровне операционной системы в большинстве случаев избавляют администратора базы данных от необходимости написания модуля доступа в ущерб безопасности. При этом, безопасность строки подключения не всегда необходима, и может обеспечиваться средствами контроля доступа к файлу на уровне пользователя. Такой метод устраняет недостатки применения UDL файлов подключения, но добавляет необходимость ввода прав пользователей на уровне операционной системы.
Использование интерпретатора формул при расчете
Первым требованием к разработанному методу решения расчетных задач, является его универсальность. Под универсальностью будем понимать возможность изменения расчетных формул пользователем, не участвующим в разработке расчетной задачи, и возможность добавления новых функций (например, Abs — модуль числа) сторонними разработчиками.
По другому критерию расчетные задачи можно разбить на задачи, работающие в режиме реального времени, и задачи, не требовательные к скорости выполнения вычислений. В первую группу в основном входят задачи АСУТП, а во вторую — АСУП. Рассматриваемая задача относится к первому классу, хотя и может быть применена ко второму в случае необходимости.
Вторым требованием к создаваемому методу является скорость решения расчетной задачи. Самыми медленными функциями можно считать функции, описанные сторонними разработчиками, именно на них можно тестировать скорость работы задачи.
Третьим критерием создания метода решения расчетных задач является встраиваемость его в другие задачи АСУ и возможность получения из него данных, необходимых для решения других задач. Наилучшим решением, удовлетворяющим этому критерию, является создание динамической библиотеки (all).
К рассматриваемым расчетным задачам, в частности, относятся задачи автоматизации расчетов ТЭП, расчета распределения нагрузки между генерирующим оборудованием, расчетов с использованием аппроксимирующих зависимостей, расчетов с использованием пользовательского ввода. Проблема вычисления пользовательских функций может быть решена путем создания кнопок с арифметическими действиями и форм для ввода значений переменных, а также с использованием интерпретаторов формул других программ посредством их вызова и дальнейшего закрытия. Такими программами могут быть Microsoft Excel, РТС MathCAD. Одним из современных методов является использование JScript.NET в своей программе. JScript.NET имеет встроенные классы для вычисления формул. Все перечисленные методы обладают рядом достоинств и недостатков.
Создание кнопок с арифметическими операциями неудобно и ограничивает возможности пользователя. Так, например, для включения в программу новых функций необходимо переписывать часть кода и создавать новую кнопку. Достоинством этого метода является его скорость и простота программирования. Основным недостатком использования интерпретаторов формул внешних программ является необходимость их установки и многократного запуска [60] при выполнении расчетной задачи автоматизации. Каждый раз при вычислении формулы будет вызываться программа, интерпретатор которой использовал разработчик для своего приложения. Такие методы приводят к излишнему расходу памяти и существенному замедлению процесса вычислений.
Использование JScript.NET в приложениях [61] не позволяет пользователю добавлять новые функции. Достоинствами этого метода являются его простота и сравнительно высокая скорость.
Все перечисленные выше методы не дают пользователю возможность добавлять собственные функции в интерпретатор формул без участия программиста. Такой подход ограничивает использование программы и приводит к необходимости ее постоянного обслуживания со стороны разработчика.
С учетом рассмотренных достоинств и недостатков других методов, для решения задачи математического ввода и анализа формул необходимо создать универсальную расчетную библиотеку пользовательского ввода с возможностью подключения функций, написанных сторонними разработчиками - интерпретатор формул.
Общий принцип работы интерпретатора формул показан на рис. 2. Квадратом обозначен класс, реализующий вычисление формул. В данном классе всего один открытый полиморфический метод. Он принимает на вход строковое значение выражения (String), которое необходимо вычислить. Вторая реализация метода принимает на вход дополнительно таблицу пар «переменная -значение», записанную в Hashtable. Использование класса Hashtable обосновано содержащимися в нем методами поиска значения по ключу и ключа по значению, что упрощает процесс программирования. При замене объекта этого класса на двумерный массив String и создании быстрой функции поиска скорость работы программы должна вырасти. Такой эксперимент не проводился, так как скорость не являлась основным критерием.
Интерпретатор формул поддерживает два интерфейса [62] для обмена данными с другими приложениями, в том числе с приложениями, написанными сторонними разработчиками. Вверху рисунка изображен полиморфический интерфейс, повторяющий единственный открытый метод класса, описанный выше. Этот интерфейс создан для взаимодействия с подключаемыми функциями-модулями, написанными сторонними разработчиками, которые не могут использовать открытый метод класса. Использование метода предпочтительнее, так как он работает намного быстрее. Примером использования данного интерфейса может служить выражение «sin([x+2] 3)»5 где sin() - подключаемая функция, написанная сторонним разработчиком. Таким образом, вычисление выражения [х+2] 3» происходит посредством вызова рассматриваемого интерфейса из подключаемой функции. Внизу рисунка показан интерфейс для подключения функций, написанных сторонними разработчиками. Функция должна возвращать число типа Double, а принимать строку String или строку String и таблицу с переменными Hashtable. Также функция возвращает строку String, что показано самой левой стрелкой, содержащую название функции. Эта строка используется при идентификации. В данном интерпретаторе формул использовался метод разбора выражения на узлы и дальнейшего вычисления полученных узлов [63]. Узлом выражения является математическая операция (+, %) или функция (sqrt(), sin()). После определения всех узлов строится их древовидная структура. Последовательно вычисляются значения каждого узла. Ответ содержится в корне древовидной структуры, т.е. в верхнем узле. Разберем данный метод на простейшем примере.
Установка модуля распределения нагрузки на ТЭЦ-23 ОАО «Мосэнерго»
Программно-технический комплекс реализован применительно к одной из ТЭЦ ОАО «Мосэнерго» - ТЭЦ-23, в состав которой входят два турбоагрегата Т-100-130, два турбоагрегата Т-110/120-130 (ст. № 1-4), четыре котла ТГМ-96 - часть станции с общим паропроводом; и четыре энергоблока (ст. № 5-8) с котлами ТГМП-314 и турбоагрегатами Т-250/300-240. Станция имеет два вывода по электроэнергии, по телу схему станции можно представить как станцию с двумя выводами. По электрической схеме станции генераторы турбоагрегатов ст. № 4 и 5 подключены к ГТП-110 кВ, а остальные к ГТП-220 кВ. По теплу турбоагрегаты ст. № 1 и 2 работают на первый вывод, а остальные агрегаты работают на второй вывод.
Программно-технический комплекс «Оперативное управление ТЭС» предназначен для поиска при заданных суммарных нагрузках ТЭЦ оптимальных электрических и тепловых нагрузок котлов, турбин, энергоблоков; раздачи задания машинистам турбин, отображения исходных данных, архивирования результатов. Основной технологической функцией является минимизация суммарного расхода условного топлива на ТЭЦ для заданных диспетчерских графиков.
Исходными и задаваемыми данными оптимизации являются:
состав работающего оборудования;
энергетические характеристики котлов, турбин и энергоблоков;
суммарная электрическая нагрузка ТЭЦ, заданная суточным графиком нагрузки по ГТП;
текущая тепловая нагрузка ТЭЦ по каждому выводу;
допустимые электрические и тепловые нагрузки агрегатов ТЭЦ;
вид сжигаемого топлива на каждом котле;
режим работы системы подогрева сетевой воды на каждом турбоагрегате;
текущее отклонение ряда технологических параметров от номинальных значений.
Выходной информацией оптимизации являются:
данные по оптимальному распределению электрической и тепловой нагрузки между агрегатами ТЭЦ;
расход топлива по агрегатам;
суммарные затраты на топливо.
Для оптимизации распределения тепловой и электрической нагрузки оборудование станции разбивается на три группы:
1 группа - турбоагрегаты ст. № 1 и 2, работающие на ГПТ-220 кВ и первый вывод по теплу;
2 группа — турбоагрегат ст. № 4 (часть станции с общим паропроводом) и энергоблок ст. № 5, работающие на ГПТ-110 кВ и второй вывод по теплу;
3 группа - остальное оборудование части станции с общим паропроводом и энергоблоки, работающие на ГПТ-220 кВ и второй вывод по теплу.
Таким образом, станция эквивалентируется станцией из трех элементов, связанных перекрестно заданными нагрузками по теплу и электроэнергии.
В качестве исходных данных для энергоблоков были взяты энергетические характеристики оборудования из нормативно-технической документации использования топлива ТЭЦ и режимные карты котлов.
На базе указанных данных были получены полиноминальные аналитические зависимости:
удельного расхода тепла на турбоустановку при различных способах подогрева сетевой воды и различных давлениях в отборах;
расхода пара в голову турбины;
мощность приводной турбины питательного насоса;
максимальная и минимальная электрическая мощность турбины в зависимости от тепловой нагрузки;
максимальная и минимальная тепловая мощность турбины в зависимости от электрической нагрузки;
В вышеприведенных выражениях: N3 — электрическая мощность энергоблока, QT - тепловая нагрузка, п — число ступеней подогрева сетевой воды, рот — давление в теплофикационном отборе (при двухступенчатом подогреве сетевой воды в верхнем отборе), qT — удельный расхода тепла на турбоустановку, D0 - расхода пара в голову турбины, NnT — мощность приводной турбины, jymax и jqmin _ максимальНая и минимальная электрическая мощность, Qax и Qin — максимальная и минимальная тепловая мощность, rjK - КПД котла.
Характеристика расхода топлива на энергоблок в зависимости от электрической и тепловой нагрузок, для заданных способа подогрева сетевой воды и давления в отборе, имеет вид:
Для части ТЭЦ с общим паропроводом аналитические характеристики получаются отдельно для турбин в виде:
Соответствующая этим характеристикам паровая нагрузка выводится в виде:
Характеристика котлов выражается следующей зависимостью:
Для оценки экономической эффективности от внедрения модуля оптимального распределения нагрузки между генерирующим оборудованием ТЭЦ в программный комплекс был добавлен блок сопоставления рекомендуемого программой распределения от альтернативного распределения.
Как показали проведенные расчеты, в зависимости от величин заданных тепловой и электрической нагрузок ТЭЦ, состава и режимов работы оборудования экономия топлива за счет оптимального распределения нагрузок между оборудованием по сравнению с альтернативными вариантами может достигать 2 % при условии неизменности состава и режимов работы оборудования в сопоставляемых вариантах.
