Размещено на http://www.allbest.ru/

Анотация

Пояснительная записка по дипломному проекту "Разработка информационной системы нижнего уровня по автоматизированному учёту энергоресурсов".

В ходе выполнения дипломной работы:

- Сделан выбор программного обеспечения для сбора и передачи данных с энергоконтроллеров в базу данных Oracle и локальную базу Accesss

- Разработана информационная сеть

- Разработана локальная база данных

- Разработана аварийная сигнализация

- Разработан порядок взаимодействия всех компонентов в целом

- Разработана эксплуатационная документация

- Выполнены экономические расчеты целесообразности разрабатываемого проекта, а также рассмотрены вопросы безопасности жизнедеятельности операторов ЭВМ

Содержание

• Введение
• 1. Разработка и анализ технического задания
• 1.1 Наименование и область применения
• 1.2 Цель и назначение разработки
• 1.3 Требования к системе
• 1.3.1 Требования к структуре и функционированию системы
• 1.3.2 Показатели назначения
• 1.3.3 Требования надежности
• 1.3.4 Требования к безопасности
• 1.3.5 Требования к защите информации
• 1.3.6 Требования по сохранности информации
• 1.3.7 Требования к стандартизации и унификации
• 1.3.8 Требования к техническому обеспечению
• 1.3.9 Требования к эргономике и технической эстетике
• 1.4 Требования к видам обеспечения
• 1.4.1 Требования к информационному обеспечению
• 1.4.2 Требования к программному обеспечению
• 1.5 Требования к документрированию
• 2. Анализ требований заказчика. Технико-экономическое обоснование
• 2.1 Выбор программного обеспечения для автоматического сбора и передачи данных с энергоконтроллеров
• 2.2 Технико-экономическое обоснование
• 3. Разработка информационной сети и программного обеспечения системы
• 3.1 Разработка информационной сети подключения энероконгроллеров
• 3.2 Используемые технологии
• 3.2.1 ODBC
• 3.2.2 OPC
• 3.2.3 ORACLE NET
• 3.3 Разработка локальной базы данных
• 3.4 Обеспечение аварийной сигнализации
• 3.5 Защита информации
• 4. Расчёты и оценки
• 4.1 Оценка свободного места на диске
• 4.2 Оценка объёма оперативной памяти
• 4.3 Оценка сетевого трафика
• 4.4 Расчёт надёжности программы
• 4.5 Оценка надёжности программы
• 5. Разработка эксплуатационной документации
• 5.1 Руководство пользователя "АРМ оператора технологических процессов"
• 5.1.1 Описание операций
• 5.1.2 Система аварийной сигнализации
• 5.2 Руководство администратора
• 5.2.1 Руководство по установке системы
• 5.2.2 Руководство по настройке системы
• 6. Организационно-экономическая часть
• 6.1 Оперативно-календарный план разработки
• 6.2 Определение эксплуатационных затрат
• 6.3 Срок окупаемости системы
• 6.4 Технико-экономические показатели
• 7. Безопасность и экологичность
• 7.1 Описание помещения
• 7.2 Оценка безопасности и экологичности проекта
• 7.3 Защита от вредных производственных факторов
• 7.3.1 Защита воздушной среды
• 7.3.2 Производственное освещение
• 7.3.3 Защита от шума
• 7.3.4 Защита от электромагнитных излучений
• 7.4 Безопасность технологического процесса и оборудования
• 7.5 Электробезопасность
• 7.6 Пожарная безопасность
• 7.7 Организация рабочего места
• 7.8 Расчёт искусственного освещения
• Список используемых сокращений
• Список используемых источников
• Заключение
• Приложение А
• Приложение Б
• Приложение В
• Приложение Г
• Приложение Д
• Приложение Е

Введение

В связи с тем что в 1998 году Бельгийская фирма "Glaverbel" приобрела контрольный пакет акций ОАО "БСЗ", стали иметь место изменения в структуре завода. Все вспомогательные цеха постепенно выделялись из состава завода. В этом году очередь дошла и до цехов, вырабатывающих энергоресурсы, необходимые как для основных производственных процессов, так и для обеспечения жизнедеятельности. Поэтому одной из первоочередных задач на данном этапе является учёт энергоресурсов, поскольку он отвечает экономическим интересам поставщиков и потребителей. Основным направлением данной задачи является контроль, рациональное использование энергоресурсов, простота и удобство расчётов.

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

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

Более того, необходимость создания автоматизированной системы учёта энергоресурсов обусловлена тем, что старая система основывалась на ручной сбор диаграмм, ручную обработку на планиметре, расчёт приведённого расхода при помощи специального программного обеспечения на локальном ПК. В настоящее время эта система не актуальна. Во первых самописцы чаще и чаще стали выходить из строя, так как оборудование работает с 1980 г. Во вторых при обработке на планиметре не возможно уловить всевозможные всплески на диаграмме, в результате погрешность при расчётах получается очень высокой.

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

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

информационный сеть энергоконтроллер база

1. Разработка и анализ технического задания

1.1 Наименование и область применения

"Система нижнего уровня автоматизированного учета энергоресурсов" АСКУЭ НУ предназначена для получения архивных данных энергоконтроллеров и передачи их на верхний уровень ВУ АСКУЭ, а также локального сохранения и отображения архивной информации и мгновенных значений.

1.2 Цель и назначение разработки

- увеличение объема информации, используемой на ВУ АСКУЭ, за счет предоставления возможности 100% передачи архивов энергоконтроллеров;

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

- сокращение времени сбора информации на ВУ АСКУЭ за счет предоставления возможности автоматической передачи данных архивов энергоконтроллеров с частотой формирования архивов;

- сокращение времени обнаружения неисправности, сбоя в работе энергоконтроллеров, за счет формирования аварийной сигнализации в смежной системе - АРМ оператора технологического процесса.

1.3 Требования к системе

1.3.1 Требования к структуре и функционированию системы

АСКУЭ НУ включает в себя программу "сервер опроса" один или несколько, ПК, информационную сеть подключения энергоконтроллеров и предназначена для передачи данных архивов энергоконтроллеров в БД АСКУЭ ВУ, разработанную в СУБД Oracle и локальной БД, а также для ведения протоколов и формирования рапортов на ПК для проведения испытаний и периодической проверки работы системы.

Связь между АСКУЭ НУ и энергоконтроллерамми осуществляется по ЛВС на основе RS232, RS485, либо Ethernet.

Связь между АСКУЭ ВУ и АСКУЭ НУ осуществляется по ЛВС ОАО "БСЗ" на основе Ethernet.

В качестве программ просмотра и печати рапорта по архиву локальной БД, протоколу работы НУ используются программы MS Office2000: соответственно MS Access и MS Word.

Смежной системой для АСКУЭ НУ может являться АРМ оператора технологического процесса. АСКУЭ НУ должна обеспечивать обмен данными со SCADA пакетом АРМа оператора (RSView 32) посредством OPC сервера, публикующего последние считанные реальные данные или DDE сервера.

АСКУЭ НУ должна обладать достаточной степенью надежности и иметь встроенные средства диагностики, позволяющие определять отказ опроса энергоконтроллеров, записи в базы данных, осуществлять контроль места на диске.

Модульная и открытая структура построения программных средств АСКУЭ НУ должна обеспечивать возможность наращивания модулями ввода\вывода к новым типам энергоконтроллеров без повторной отладки всей АСКУЭ НУ, подключение дополнительных энергоконтроллеров одного типа к программе "сервер опроса", путем настройки сервера опроса.

1.3.2 Показатели назначения

АСКУЭ НУ должна быть открытой для дальнейшей модернизации. Это должно достигаться путем использования новых технологий проектирования, что дает возможность поддерживать программное обеспечение и документацию проекта на протяжении всей их жизни.

Разрабатываемая ИС не должна иметь ограничений по модернизации КТС в части замены ПЭВМ и коммуникационного оборудования на более надежные варианты их развития, при условии сохранения общего программного обеспечения (ОПО).

1.3.3 Требования надежности

К показателям надежности системы следует отнести время восстановления работоспособности системы после сбоев в работе.

Во всех аварийных ситуациях основным требованием является отсутствие потери информации и минимально-возможное время автоматического восстановления данных от энергоконтроллеров, в том числе условие, что время восстановления АСКУЭ НУ после сбоя не превышает времени хранения архива в любом из подключенных к АСКУЭ НУ энергоконтроллеров.

Время восстановления АСКУЭ НУ должно быть меньше времени хранения архивов по каждому виду энергоконтроллеров, чаще всего оно заложено в самом энергоконтроллере или настраивается с помощью доплнительного ПО.

Для обеспечения своевременного формирования рапортов в отчетный период должно быть обеспечено время восстановления работы АСКУЭ НУ - не более 24 часа.

1.3.4 Требования к безопасности

Работа с АСКУЭ НУ не должна приводить к опасным ситуациям, сбои в программном обеспечение не повлекут серьезных последствий.

1.3.5 Требования к защите информации

В системе должна быть предусмотрена защита от несанкционированного доступа к программному обеспечению АСКУЭ НУ.

Вход, настройка и закрытие программы сбора данных должны выполнятся по паролю, который задается администратором ОС.

Попытки несанкционированного доступа или взлома системы должны фиксироваться в протоколе работы АСКУЭ НУ.

1.3.6 Требования по сохранности информации

Со всех энергоконтроллеров в АСКУЭ ВУ и локальную базу данных должны передаваться следующие параметры:

- Давление

- Температура

- Расход

- Тепловая мощность

Сохранность информации в АСКУЭ НУ локальных архивов не является критичным параметром, в связи с их использованием только для контроля опроса архивов энергоконтроллеров.

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

1.3.7 Требования к стандартизации и унификации

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

- Windows NT/2000;

- ODBC совместимых драйверов баз данных;

- MS Office2000.

Программное обеспечение АСКУЭ НУ должно обеспечивать сбор данных с полевого уровня на платформе Windows NT4.0/2000 .

Протоколы обмена данными приборов учета должны быть совместимы между собой по формату информационных посылок и удовлетворять следующим требованиям:

- возможность передачи данных передача по сети RS485, RS232 или по сети Ethernet;

- возможность опроса до 34 Com -портов, на каждом из которых до 3 энергоконтроллеров, поддерживающих такой тип адресации и совместимых по формату информационных посылок;

- формат информационных посылок при передаче данных по сети RS232 и RS485 должен состоять из 8 бит данных;

- минимальная скорость передачи данных 300 бод;

- максимальная скорость передачи данных 115200 бод.

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

1.3.8 Требования к техническому обеспечению

Сервер сбора данных АСКУЭ НУ и рабочие станции должны выполнять все функции АСКУЭ НУ в соответствии с требованиями, изложенными в ТЗ.

АРМы, где установлено специальное программное обеспечение, должны соответствовать следующим требованиям:

- Минимальный размер оперативной памяти, должен составлять 128Мб.;

- Минимальный объем жесткого диска должен составлять 4,3 Гб.

1.3.9 Требования к эргономике и технической эстетике

Разрабатываемая АСКУЭ НУ должна отвечать современным требованиям к эргономике и технической эстетике для обеспечения надежной и эффективной работы системы "человек-машина" в целом.

Поток информации, поступающий к оперативному персоналу, должен соответствовать возможностям человека по ее переработке.

В АСКУЭ НУ используются современные технологии организации удобного интерфейса на платформе Windows. В программном обеспечении применяются удобные и привычные пользователям элементы управления.

1.4 Требования к видам обеспечения

1.4.1 Требования к информационному обеспечению

Информационное обеспечение АСКУЭ НУ должно быть достаточным для выполнения всех автоматизированных функций.

Данные архивов энергоконтроллера должны автоматически передаваться в локальную базу данных MS Access2000 и БД АСКУЭ ВУ с использованием ODBC, BDE, Oracle Net или других технологий, сообщения о работе НУ должны протоколироваться. Процесс передачи данных в локальную базу данных и БД АСКУЭ ВУ осуществляется сразу после последнего опроса энергоконтроллера. Информация в локальной базе данных должна автоматически удаляться при превышении заданного времени хранения. Программа "сервер опроса" должена обеспечивать автоматическое пополнение архивных данных в локальную базу данных и БД АСКУЭ ВУ с заданной периодичностью или при запуске после сбоя, при условии, что время восстановления после сбоя или отказа не превышает времени хранения архива в любом из подключенных к АСКУЭ НУ энергоконтроллеров. Сообщения о работе АСКУЭ НУ должны включать в себя сообщения о сбоях и о активности, вызванной чтением и записью данных;

Должна быть обеспечена информационная совместимость по стандартным или согласованным форматам данных.

1.4.2 Требования к программному обеспечению

Программное обеспечение должно быть достаточным для выполнения всех функций АСКУЭ НУ, реализуемых с применением средств вычислительной техники.

Программное обеспечение должно состоять из общего (ОПО) и специального (СПО).

ОПО системы должно включать в себя:

- операционную систему Windows NT\2000;

- MS Office2000;

- ODBC драйверы для БД Oracle RDBMS 8.1.7.1 и MS Access2000 .

СПО системы должно включать в себя:

- Программа "сервер опроса" одна или более в зависимости от типов энергоконтроллеров и имеющихся к ним драйверов;

- OPC или DDE сервера для обмена данными со SCADA пакетом RSView32 АРМа оператора технологического процесса;

- Драйвера или ПО для связи с базами данных;

- Драйвера или ПО для конфигурации Com-портов;

Допускается использование прикладных пакетов независимых фирм для решения функциональных задач АСКУЭ НУ.

Разрабатываемое программное обеспечение не должно мешать работе других пакетов программного обеспечения, установленного на АРМах.

1.5 Требования к документрированию

Программная документация должна включать:

1) Руководство пользователя.

2) Руководство администратора системы.

2. Анализ требований заказчика. Технико-экономическое обоснование

В настоящее время на ОАО "БСЗ" используется три вида энергоконтроллеров.

ЭКОМ 3000, СТД и ЭХО-Р. Основные технические характеристики энергоконтроллеров приведены в приложении В.

2.1 Выбор программного обеспечения для автоматического сбора и передачи данных с энергоконтроллеров

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

Энергоконтроллер ЭКОМ 3000 разработан Екатеринбургской фирмой ПРОСОФТ-Е. Фирма также разработала программу "сервер опроса" для считывания данных с ЭКОМ 3000 и записи в СУБД (SQL, Oracle и др.). Но такой выбор, полностью не решает поставленной задачи, так как сервер опроса не работает с приборами СТД и ЭХО-Р. Тем не менее, такой вариант использования возможен, приняв во внимание, что для снятия данных с приборов СТД и ЭХО-Р необходимо дополнительное программное обеспечение. Что касается OPC, то этот сервер опроса поддерживает данный стандарт, но для передачи данных по OPC необходим дополнительный OPC-сервер. Таким может быть Fastwel Uni OPC сервер, разработанный фирмой Fastwel.

Выполняемые задачи:

- сбор данных с устройств ЭКОМ-3000

- сбор данных с ModbusRTU-совместимых контроллеров

- сбор данных c электросчетчиков типа СЭТ-4ТМ.01(02)

- сбор данных с SoftBasic-контроллеров

- сбор данных с электросчетчиков типа EAxxxxx (ЕвроАльфа)

- сбор данных с теплосчетчиков типа ТСР фирмы Взлет

- сбор данных с расходомеров-счетчиков типа УРСВ-010М

- запись собираемых данных в БД

- коррекция времени УСПД по локальному времени

- коррекция локального времени по времени УСПД или SQL-сервера

- выдача по требованию команд управления в устройства ЭКОМ-3000, ModbusRTU-совместимые контроллеры и SoftBasic-контроллеры

- протоколирование событий

- хронометраж отдельных стадий и процесса в целом

Что касается энергоконтроллеров СТД и ЭХО-Р у фирм разработчиков не разработано своё собственное программное обеспечение обеспечивающее чтение данных с энергоконтроллеров и передачу в какую либо базу данных. На сегодняшний день у них имеется ПО для считывания архивов энергоконтроллера и запись их в текстовый файл, работающие под операционной системой DOS. Поэтому использовать такое ПО не следует.

Программа "сервер опроса" для энергоконтроллеров СТД разработана фирмой "Кливер". Фирма разработала программу "сервер опроса" для энергоконтроллеров СТД. Запись может производиться в любую СУБД, используя ODBC. В сервере опроса заложена поддержка OPC.

Выполняемые задачи:

- сбор данных с устройств СТД

- сбор данных с теплосчетчиков типа ТСР фирмы Взлет

- сбор данных с расходомеров-счетчиков типа УРСВ-010М

- запись собираемых данных в БД

- функции OPC сервера.

- протоколирование событий

Программа "сервер опроса" для энергоконтроллеров ЭХО-Р разработанная фирмой "Элеком". Фирма разработала программу "сервер опроса" для энергоконтроллеров ЭХО-Р. Запись производиться в базу данных Oracle, используя Oracle Net. В сервере опроса заложена поддержка DDE.

- сбор данных с устройств ЭХО-Р

- сбор данных с теплосчетчиков типа ТСР фирмы Взлет

- запись собираемых данных в БД

- функции DDE сервера.

- протоколирование событий

Состав и функциональные возможности программы "сервер опроса", разработанного фирмой "VECON"

Универсальный сервер опроса представляет собой специальное программное обеспечение (СПО) предназначенное для:

- опроса энергоконтроллеров ЭКОМ, СТД, ЭХО-Р и т.д.;

- управления служебными параметрами энергоконтроллеров;

- передачи архивов энергоконтроллеров в локальную базу данных (БД);

- передачи архивов энергоконтроллеров в БД верхнего уровня;

- публикации текущих показаний энергоконтроллеров через OPC.

Разработанная программа производит сбор данных с энергоконтроллеров и передачу их в БД верхнего уровня, что позволяет пользователям верхнего уровня АСКУЭ получать всю необходимую информацию. [5]

Теперь можем рассмотреть две возможные системы АСКУЭ НУ.

Первая система, в состав которой входят:

- Сервер опроса фирмы ПРОСОФТ-Е + Fastwel Uni OPC сервер.

- Сервер опроса фирмы "Кливер"

- Сервер опроса фирмы "Элеком"

Вторая система, включающая один сервер опроса, разработанный фирмой "VECON".

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

С функциональной точки зрения первый вариант системы по отношению ко второму имеет ряд недостатков:

- Необходим больший размер ОП ПК, так как одновременно загружены четыре задачи, а не две (включая RSView 32).

- Более сложная настройка системы АСКУЭ НУ

- Сложнее обеспечить взаимодействие с АСКУЭ ВУ

- Низкий контроль, за работой трёх независимых систем

- Более трудоёмкий анализ протоколов

Из достоинств можно выделить только одно, при остановке одного из серверов опроса, данные с других будут поступать в базу данных ВУ

Проанализировав все достоинства и недостатки, мы сделали выбор в пользу второго варианта - программы "сервер опроса" фирмы "VECON". В состав сервера опроса фирмы "VECON" входят следующие блоки:

- ядро сервера опроса;

- модуль сбора и передачи данных "ЭКОМ 3000"

- модуль сбора и передачи данных "СТД-3";

- модуль сбора и передачи данных "ЭХО-Р";

- модуль передачи данных "ODBC";

- модуль передачи данных " БД ВУ ";

- модуль передачи данных "ОРС";

- модуль запроса данных из БД ВУ;

- модуль запроса данных из локальной БД ;

- модуль протоколирования сообщений.

2.2 Технико-экономическое обоснование

Смысл создания и использования АСКУЭ заключается в постоянной экономии энергоресурсов. Величина экономического эффекта от использования АСКУЭ достигает по предприятиям в среднем 5-30% от годового потребления энергоресурсов. На сегодняшний день АСКУЭ предприятия является тем необходимым механизмом, без которого невозможно решать проблемы цивилизованных расчётов за энергоресурсы с их поставщиками, непрерывной экономии энергоносителей и снижении доли энергозатрат в себестоимости продукции предприятия.

По мере автоматизации технологических процессов предприятия, снижения степени человеческого участия в производстве и повышения уровня его организации, благодаря АСКУЭ можно использовать аварийную сигнализацию. До тех пор, пока в технологии производства преобладает человек со своими случайными волевыми решениями, АСКУЭ сохранится как автоматизированная система, позволяющая в первую очередь выявлять все потери энергоресурсов. Уровень потребления энергоресурсов предприятия складывается из двух составляющих: базовой и организационной. Базовая составляющая определяется степенью эффективности вырабатываемых энергоресурсов вспомогательными цехами. Организационная составляющая определяется режимами потребления энергоресурсов, которые задаются персоналом предприятия исходя из производственных и личных интересов и потребностей. Организационная составляющая предприятия в свою очередь имеет пять основных частей:

- Договорная, фиктивная составляющая связана с расчётами за энергоресурсы с поставщиками не по фактическим значениям, а по договорным и как правило существенно завышенным, что приводит потребителя к финансовым потерям. Эта составляющая сводится к минимуму и даже к нулю при организации АСКУЭ коммерческого учёта

- Тарифная составляющая, связанная с расчётами за энергоресурсы с поставщиком по фактическим значениям энергопотребления, но не по самому выгодному тарифу для потребителя из-за отсутствия учёта, способной отслеживать любые действующие и перспективные тарифы

- Режимно-тарифная составляющая, связанная с возможностью изменения режимов потребления по времени и величине энергопотребления в заданных зонах суток с целью минимизации тарифных платежей в рамках одного и того же тарифа. Эта составляющая сводится к минимуму при организации АСКУЭ коммерческого учёта

- Личностная составляющая, связанная с использованием персоналом энергоресурсов в личных целях. Эта составляющая потерь сводится к минимуму при организации АСКУЭ.

- Бесхозная составляющая, связанная с не заинтересованностью, безразличием персонала на рабочих местах к энергопотерям разного вида. Эта составляющая сводится к минимуму при организации АСКУЭ коммерческого учёта с введением внутреннего расчёта по энергоресурсам между подразделениями предприятия или норм потребления энергоресурсов подразделениями.

Постоянное удорожание энергоресурсов требует от промышленных предприятий разработки и внедрения комплекса мероприятий по энергосбережению, включающий жёсткий контроль поставки / потребления всех видов энергоресурсов, ограничение и снижение их доли в себестоимости продукции. Современная АСКУЭ является измерительным инструментом, позволяющим экономически обоснованно разрабатывать, осуществлять комплекс мероприятий по энергосбережению, своевременно его корректировать, обеспечивая динамическую оптимизацию затрат на энергоресурсы в условиях изменяющейся экономической среды, таким образом АСКУЭ является основой системы энергосбережения промышленных предприятий. Первый и самый необходимый шаг в этом направлении, который надо сделать уже сегодня - это внедрить автоматизированный учёт энергоресурсов, позволяющий учитывать и контролировать параметры всех энергоносителей по всей структурной иерархии предприятия. Благодаря этому будут сведены к минимуму производственные и не производственные затраты на энергоресурсы, что позволит решать спорные вопросы между поставщиком и потребителем не волевыми директивными мерами, а объективно на основании автоматизированного учёта.

Определение экономического эффекта основывается на сопоставлении затрат по существующему и предлагаемому варианту.

Рассмотрим эти два варианта.

Первый вариант предполагает учёт энергоресурсов на предприятии используя систему пересчёта диаграмм.

Этот вариант предполагает следующие недостатки:

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

- Длительный анализ получаемых данных, существование ошибок в расчётах.

- Отсутствие контроля, за экономией энергоресурсов.

- Отсутствие объективного анализа получаемых данных.

Второй вариант предполагает учёт энергоресурсов на предприятии при помощи системы АСКУЭ.

Теплотехники смогут сидя у себя в кабинете получать всю необходимую информацию с энергоконтроллеров на компьютер, которую ИС АСКУЭ ВУ будет выдавать в требуемой форме. Оперативному персоналу теплотехнической службы предприятия не придётся ежедневно по истечении суток заменять листы для обкрутки диаграмм на самописцах, а инженерно-техническому персоналу пересчитывать снятые диаграммы. Появится возможность точно подсчитать и доказать какую экономию будут приносить те или иные мероприятия.

Далее приведён расчёт сравнительного экономического эффекта от внедрения системы АСКУЭ. Экономический эффект основывается не только на экономии рабочего времени целого ряда работников предприятия осуществляющих сбор данных, расчётов, анализа, планирования потребления энергоресурсов, а в появлении многих дополнительных возможностей позволяющих более эффективно использовать энергоресурсы предприятия.

Проведём анализ по количеству рабочего времени, затрачиваемое отделом главного теплотехника на сбор данных по потреблению для первого и второго вариантов. Данные по количеству рабочего времени приведены в таблице 2.1 и таблице 2.2.

Таблица 2.1 Рабочее время, затрачиваемое на учёт энергоресурсов без использования системы АСКУЭ НУ

Действие	Количество исполнителей	Длительность
Снятие диаграмм со всех самописцев и установка чистых листов	3 чел.	4 часа
Итого		12 часов

Итого общее затраченное время при пересчёте на одного человека, равно 12 часов.

Таблица 2.2 Рабочее время, затрачиваемое на учёт энергоресурсов с использованием системы АСКУЭ НУ

Действие	Количество исполнителей	Длительность
Снятие последних архивных данных со всех энергоконтроллеров и запись в базу данных ВУ	1	4 мин
Итого		4 мин (0,066 час)

Экономия времени службы главного теплотехника предприятия при каждом сборе информации по потреблению с использованием системы АСКУЭ НУ составляет:

Э = 12 - 0,066, = 11,933 часов

Экономия рабочего времени за месяц рассчитывается по формуле 2.1

Эм = Э х М (2.1)

Где М - количество расчётов в месяц (М = 30)

Получаем:

Эм = 11,933 х 30 = 358 часов

Таким образом экономический эффект от разработки системы АСКУЭ очевиден.

3. Разработка информационной сети и программного обеспечения системы

Функциональная схема АСКУЭ НУ представлена в приложении Е.

3.1 Разработка информационной сети подключения энероконгроллеров

Основным требованием при выборе места расположения ПК для сбора и передачи информации с энергоконтроллеров является необходимость использования аварийной сигнализации. Аварийная сигнализация должна быть обеспечена в парокотельном цехе и на газораспределительной подстанции N1 (ГРП 1). ПК на этих местах имеются по проекту "Автоматизация технологических процессов". Отображение текущих данных с энергоконтроллеров, для обеспечения аварийной сигнализации будет осуществляться, используя технологию OPC.

Нумерация энергоконтроллеров в соответствии с приложением А.

Самое большое количество энергоконтроллеров находится в парокотельном цехе ОАО "БСЗ" В нём установлены два эергоконтроллера ЭКОМ 3000 и три энергоконтроллера СТД.

Два энергоконгроллера ЭКОМ-3000 имеют встроенный информационный выход RS 485, поэтому их можно объединить в одну ЛВС

Три энергоконтроллера СТД имеют информационный выход RS 232. Для того чтобы объединить их в единую ЛВС, необходимо использовать преобразователи RS 232 в RS 485, такими могут быть преобразователи интерфейса А-52 фирмы Moxa или любые другие.[2]

Для физического соединения этих энергоконтроллеров с ПК, на ПК необходимо иметь два выхода RS 485. Для обеспечения двух выходов RS 485 можно использовать встроенную плату фирмы Advantec PCI-1602B, или любую другую, имеющую два или более выхода RS 485.[2]

Выбор сети RS 485 обоснован тем, что длина кабеля для связи с энергоконтроллерами превышает 18 м. При такой длине кабеля, использовать сеть RS 232 не следует.

Схема информационной сети парокотельного цеха представлена на рисунке 3.1

Рисунок 3.1 - Схема информационной сети парокотельного цеха

К ПК оператора газораспределительной подстанции N1, подключаем энергоконтроллер СТД N5, находящийся на ГРП 1 и другие энергоконтроллеры СТД и ЭХО-Р, находящиеся на значительном расстоянии от ГРП 1.

Для подключения энергоконтроллера СТД N5 можем использовать сеть RS232, так как расстояние до ПК менее 6 м, для этого не требуется дополнительных преобразователей.

Подключение удалённых энергоконтроллеров можно осуществить двумя способами, проложив к ним сеть RS485, либо использовав существующую сеть Ethernet

В первом случае, при использовании сети RS485, необходимо:

- проложить кабель ко всем удалённым энергоконтроллерам

- установить к каждому энергоконтроллеру преобразователи интерфейса RS232 в RS485

- установить к ПК преобразователь интерфейса RS232 в RS485

Во втором случае, при использовании существующей сети Ethernet, необходимо:

- установить к каждому энергоконтроллеру преобразователи интерфейса RS232 в Ethernet, такими могут быть преобразователи DE 311 фирмы MOXA. [2]

Учитывая большую протяжённость ОАО "БСЗ", удалённость и разброс энергоконтроллеров от ПК более чем на 1км, имеющуюся рядом с энергоконтроллерами ЛВС Ethernet. наиболее приемлемым является второй вариант.

Схема информационной сети газораспределительной подстанции (ГРП) N1 представлена на рисунке 3.2

Передача данных в БД ВУ осуществляется по существующей сети Ethernet.

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



Рисунок 3.2 - Схема информационной сети ГРП

Когда говорят Ethernet, то под этим обычно понимают любой из вариантов этой технологии. В более узком смысле, Ethernet - это сетевой стандарт, основанный на технологиях экспериментальной сети Ethernet Network, которую фирма Xerox разработала и реализовала в 1975 году (еще до появления персонального компьютера). Метод доступа был опробован еще раньше: во второй половине 60-х годов в радиосети Гавайского университета использовались различные варианты случайного доступа к общей радиосреде, получившие общее название Aloha. В 1980 году фирмы DEC, Intel и Xerox совместно разработали и опубликовали стандарт Ethernet версии II для сети, построенной на основе коаксиального кабеля. Поэтому стандарт Ethernet иногда называют стандартом DIX по заглавным буквам названий фирм.

На основе стандарта Ethernet DIX был разработан стандарт IEEE 802.3, который во многом совпадает со своим предшественником, но некоторые различия все же имеются. В то время, как в стандарте IEEE 802.3 различаются уровни MAC и LLC, в оригинальном Ethernet оба эти уровня объединены в единый канальный уровень. В Ethernet определяется протокол тестирования конфигурации (Ethernet Configuration Test Protocol), который отсутствует в IEEE 802.3. Несколько отличается и формат кадра, хотя минимальные и максимальные размеры кадров в этих стандартах совпадают.

В зависимости от типа физической среды стандарт IEEE 802.3 имеет различные модификации - 10Base-5, 10Base-2, 10Base-T, 10Base-F.

Для передачи двоичной информации по кабелю для всех вариантов физического уровня технологии Ethernet используется манчестерский код.

Все виды стандартов Ethernet используют один и тот же метод разделения среды передачи данных - метод CSMA/CD

Сегментация сети на основе протокола TCP/IP

Локально-вычислительная сеть (ЛВС) на ОАО БСЗ, основана на использовании топологии "звезда". При использовании данной топологии, каждый компьютер подключается к специальному концентратору (хабу). Преимуществом является ее устойчивость к повреждениям кабеля - при обрыве перестает работать только один из узлов сети и поиск повреждения значительно упрощается.

В разрабатываемой сети назначаются IP-адреса класса В. Класс В, является сетью средних размеров с числом узлов 28 - 216. В сетях класса В, под адрес сети и под адрес узла отводится по 16 битов, то есть по 2 байта. Адрес всей сети 172.17.16.0

Назначение IP-адресов персональным компьютерам и серверам осуществляется при помощи DHCP-сервера. Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов. При автоматическом статическом способе DHCP-сервер присваивает IP-адрес (и, возможно, другие параметры конфигурации клиента) из пула наличных IP-адресов без вмешательства оператора. Границы пула назначаемых адресов задает администратор при конфигурировании DHCP-сервера. Между идентификатором клиента и его IP-адресом по-прежнему, как и при ручном назначении, существует постоянное соответствие. Оно устанавливается в момент первичного назначения сервером DHCP IP-адреса клиенту. При всех последующих запросах сервер возвращает тот же самый IP-адрес.

Назначение IP-адресов преобразователям DE 311 происходит ручным способом, с помощью специального ПО, входящего в комплект поставки DE 311.

Таблица 3.1 Маршрутизация преобразователей DE 311:

Сетевой адрес	Маска	Адрес шлюза
172.17.19.121	255.255.240.0	172.17.19.249
172.17.19.122	255.255.240.0	172.17.19.249
172.17.19.123	255.255.240.0	172.17.19.249
172.17.19.124	255.255.240.0	172.17.19.249
172.17.19.125	255.255.240.0	172.17.19.249
172.17.19.128	255.255.240.0	172.17.19.249

Таблица 3.2 Таблица маршрутизации для котельной станции:

Сетевой адрес	Маска	Адрес шлюза	Интерфейс	Метрика
127.0.0.0	255.0.0.0	127.0.0.1	127.0.0.1	0
172.17.n.m	255.255.255.255	127.0.0.1	127.0.0.1	0
224.0.0.0	255.0.0.0	172.17.n.m	172.17.n.m	0
255.255.255.255	255.255.255.255	172.17.n.m	172.17.n.m	0
172.17.26.128	255.255.240.0	172.17.n.m	172.17.n.m	0
172.17.255.0	255.255.255.255	172.17.n.m	172.17.n.m	0
0.0.0.0	0.0.0.0	172.17.19.249	172.17.n.m	0

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

Схема ЛВС на основе Ethernet представлена на рисунке 3.3

Рисунок 3.3 - Схема ЛВС на основе Ethernet

Третья запись (224.0.0.0) предназначена для передачи пакетов многоадресным группам.

Четвертая запись (255.255.255.255) - стандартный адрес для широковещания.

Пятая запись (172.17.26.128) - для передачи пакетов узлам в локальной сети.

Шестая запись (172.17.255.0) относится к широковещательным сообщениям локальной сети.

Седьмая запись (0.0.0.0) указывает на шлюз по умолчанию, служащий для пересылки трафика, адресованного другой сети.

Таблица 3.3 Таблица маршрутизации для ГРП 1.

172.17.26.153	255.255.240.0	172.17.n.m	172.17.n.m	0
0.0.0.0	0.0.0.0	172.17.19.249	172.17.n.m	0

Таблица 3.4 Таблица маршрутизации для Oracle сервера.

172.17.18.6	255.255.240.0	172.17.n.m	172.17.n.m	0
0.0.0.0	0.0.0.0	172.17.19.249	172.17.n.m	0

Маршрутизатор Cisco74XX, выполняет роль шлюза для отправки сообщений другой подсети.

3.2 Используемые технологии

3.2.1 ODBC

Аббревиатура ODBC является сокращением для Open DataBase Connectivity, что можно перевести как „открытый интерфейс доступа к базам данных". Этот интерфейс представляет собой набор функций, которые можно использовать для доступа к любой реляционной СУБД, поддерживающей SQL. На уровне операционной системы ODBC реализуется в виде группы DLL-библиотек, состоящей из драйверов отдельных баз данных (ODBC-драйверов) и так называемого менеджера драйверов, выполняющего роль прослойки между приложением-клиентом и ODBC-драйвером; именно наличие такой прослойки и обеспечивает независимость приложения от конкретного сервера БД.

Последняя версия ODBC, выпущенная в 1997 году, имеет номер 3.51; как показывает практика, для решения большинства типичных задач бывает достаточно версий 2.x, выходивших в период с 1993 по 1995 год. Заметим, что Microsoft официально прекратила развитие ODBC, предлагая в качестве замены технологию ADO (Active Data Objects), которая представляет собой ни что иное, как COM-оболочку ядра ODBC.

3.2.2 OPC

Стандарт OPC предназначен для поставки оперативных данных от оборудования и/или к оборудованию. Для стандарта OPC реализованы спецификации как Custom-интерфейса, так и интерфейса автоматизации. С точки зрения функциональных интерфейсов, последний ничем не отличается от Custom, кроме того, что не позволяет одновременно работать с несколькими OPC-серверами и добавлен упоминавшийся выше COM-интерфейс IDispatch, обязательный в OLE Automation. Это позволило OPC Foundation издать обёртку (wrapper) в виде dll, преобразующую один интерфейс в другой. Стандарт OPC имеет две версии интерфейсов: 1.0 и 2.0. Как мы уже знаем, с точки зрения COM, это самостоятельные спецификации. OPC-клиент предварительно запрашивает, может ли он работать с нужным ему COM-интерфейсом в используемом OPC-сервере. С точки зрения функциональности, в версии 2.0 механизм уведомления клиента приведён к стандартному механизму COM/DCOM, что упрощает программирование. Технология OPC регламентирует только интерфейс между OPC-клиентами и OPC-серверами (как и положено в технологии клиент-сервер, допускается множественные подсоединения).

3.2.3 ORACLE NET

Сетевой продукт Net 8 для Oracle 8 обеспечивает работу Oracle в компьютерных сетях, предполагая "прозрачную" связь приложений в средах клиент-сервер. Этот продукт содержит богатый набор сетевых услуг, включая транспорт данных, службу имён сети, защиту и текущий контроль транзакций. Он создаёт "абстрактный" уровень, изолируя пользователей и прикладные программы пользователя от физической сети, допуская гетерогенную, распределённую работу приложений, обеспечивая независимость от поставщиков компьютеров, операционных систем, аппаратной архитектуры или сетевой топологии. Прикладная программа работает стабильно на AS-400 с сетевым протоколом LU6.2, в сетях Token-Ring, на HP-9000 с сетевым протоколом TCP/IP, в локальных сетях на основе протокола Ethernet. Сетевой продукт Oracle Net 8 доступен фактически для любой платформы поддерживаемой Oracle, - от ПК до мейнфреймов - и поддерживает почти все сетевые транспортные протоколы, включая TCP/IP, Novell SPX/IPX, IBM LU6.2, NetBIOS, DECNet и AppleTalk.

Сетевая структура Oracle очень эффективна. Продукт Oracle Net 8 поддерживает балансировку сетевой загрузки и отказоустойчивость. Если существует несколько путей к серверу базы данных, Net 8 определяет наиболее эффективный маршрут и устанавливает соответствующее подключение. Кроме того, во время установки подключений Net 8 обнаруживает любые отказы компонентов на первичном пути и автоматически переключает на альтернативный маршрут, используя вторичные сетевые интерфейсы или сетевые программные стеки протокола. Net 8 также обнаруживает прерванное подключение и освобождает ресурсы сервера, сбрасывая неудачные подключения.

Oracle Net 8 превосходит своего предшественника SQL*Net для Oracle 7 в эффективности и масштабируемости благодаря наличию двух новых возможностей - объединению подключений и мультиплексирования сеанса. Благодаря этим технологиям уменьшается количество ресурсов сервера, необходимых для поддержки сетевых подключений, поскольку один сервер базы данных может поддерживать большое число пользователей.[6]

3.3 Разработка локальной базы данных

При разработке локальной базы данных необходимо учесть следующие требования

- Структурированное отображение данных

- Рапорт для печати отображаемых данных

При разработке локальной базы данных используем офисное приложение MS Access.[3]

Часовые и суточные архивные данные поступают в одну таблицу с названием ACS_DATAS. Запись данных обеспечивается настройкой в программе "сервер опроса"

- параметров соединения через ODBC

- созданием задачи пополнения часовых и суточных данных по каждому из потребителей

- настройкой SQL запросов (см. приложение Г)

В форме должны отображаться следующие параметры:

- Адрес прибора

- Com-порт

- Описание прибора

- Уникальный идентификатор

- Тип данных

- Дата/время

- Номер потребителя

- Давление

- Температура

- Тепловая мощность

- Расход

Структура полей таблицы ACS_DATAS представлена на рисунке 3.4

Рисунок 3.4 - Структура полей таблицы ACS_DATAS

Отображение необходимых данных осуществляется при помощи форм: главной - F_MAIN и подчинённой - F_ACS_DATAS

Для устранения избыточности информации необходимо задать следующие поля для выборки:

- выбор периода просмотра данных

- выбор описания прибора

- типы данных

- номер потребителя

Главная форма F_MAIN содержит поля для выборки и кнопки для обновления и вывода рапорта. Подчинённая форма находится в главной форме и содержит поля для вывода выбранных архивных данных

Выборка для отображения необходимых данных осуществляется при помощи SQL запросов Q_DATAS

SELECT ACS_DATAS.D_DATE, ACS_DATAS.P, ACS_DATAS.T, ACS_DATAS.N, ACS_DATAS.W, ACS_DATAS.DEVICE_PATH, ACS_DATAS.DATA_TYPE, ACS_DATAS.NP

FROM ACS_DATAS

WHERE (((ACS_DATAS.D_DATE)>=[Forms]![F_MAIN]![Datefrom] And (ACS_DATAS.D_DATE)<=[Forms]![F_MAIN]![DateTo]) AND ((ACS_DATAS.DEVICE_PATH)=[Forms]![F_MAIN]![DEVICENAME]) AND ((ACS_DATAS.DATA_TYPE)=[Forms]![F_MAIN]![DataType]) AND ((ACS_DATAS.NP) Like [Forms]![F_MAIN]![NumP]))

ORDER BY ACS_DATAS.D_DATE, ACS_DATAS.NP;

Вид форм для вывода представлен на рисунке 3.5

Рисунок 3.5 - Форма для вывода данных F_MAIN

Кнопка "Обновить" предназначена для обновления данных, в случае изменения в каком либо из вводных полей.Рапорт вызывается при нажатии кнопки "Рапорт". Процедура обработки событий следующая.

Private Sub btnReport_Click()

On Error GoTo Err_btnReport_Click

Dim stDocName As String

stDocName = "R_DATAS"

DoCmd.OpenReport stDocName, acPreview

Exit_btnReport_Click:

Exit Sub

Err_btnReport_Click:

MsgBox Err.Description

Resume Exit_btnReport_Click

End Sub

Вид рапорта представлен на рисунке 3.6

Рисунок 3.6 - Рапорт

3.4 Обеспечение аварийной сигнализации

Обеспечение аварийной сигнализации возможно на операторских местах благодаря использованию SCADA системы RSView 32, по проекту "Автоматизация технологических процессов".[7] Связь между двумя системами осуществляется по OPC интерфейсу. OPC сервером является сервер опроса, а OPC клиентом - RSView 32. Эта связь возможна при создании в программе "сервер опроса" задачи "Чтение текущих показаний" и указании модуля публикации OPC по каждому из настроенных приборов. А также при создании узла OPC в проекте RSView 32. Пример создания узла OPC представлен на рисунке 3.7

Рисунок 3.7 - Создание OPC узла

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

Tag

- Type - тип тега (аналоговый, дискретный, стринговый)

- Security - уровень защиты тега

- Discription - описание тега

- Minimum - максимальное значение

- Maximum - минимальное значение

- Scale - шкала

- Offset - смещение

- Units - единицы измерения

- Data Type - тип данных

Data Source

- Type - выбор источника данных

- Node Name - имя созданного узла

- Address - адрес публикуемого тега

Пример сконфигурированного тега представлен на рисунке 3.8

Рисунок 3.8 - Создание тега

Следующим шагом производим настройку аварийности созданного тега. В данной настройке для аналоговых тегов задаётся уровень серьёзности аварии и порог на её срабатывание. Пример настройки представлен на рисунке 3.9



Рисунок 3.9 - Аварийные пороги

При срабатывании какой либо аварии она отображается в нижней строке любого из загруженных на данный момент кадров и автоматически попадает в сводку аварий. Аварии первого уровня серьёзности сопровождаются звуковым сигналом. Вид настройки сводки аварий представлен на рисунке 3.10