Конспект

Программное обеспечение автоматизированной системы контроля и учета электроэнергии. Общие требования (вопрос 19)

Категория:

Конспект

Дисциплина:

Автоматизированная система контроля и учета электроэнергии (АСКУЭ)

Город:

Беларусь, Минск

Учебное заведение:

БНТУ, ФИТР

Стоимость работы:

бесплатный

Оценка: 10
Объем страниц: 5
Год сдачи: 2020
Дата публикации: 07.05.2021

Фрагменты для ознакомления

19. Программное обеспечение автоматизированной системы контроля и учета электроэнергии (АСКУЭ). Общие требования

Автоматизированное рабочее место (АРМ) – это программно-технический комплекс автоматизированной системы, предназначенный для автоматизации деятельности определенного вида. АРМ объединяет программно-аппаратные средства, обеспечивающие взаимодействие человека с компьютером, предоставляет возможность ввода информации (через клавиатуру, мышь, сканер и пр.) и её вывод на экран монитора, принтер, графопостроитель, звуковую карту — динамики или иные устройства вывода.

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

  1. Общие требования
  2. ПО АСКУЭ должно распределяться в общем случае по трем уровням: СИ (электронные счетчики) измерительного компонента АС (нижний уровень АСКУЭ), средства учета электроэнергии УСПД компонента АС сбора и обработки данных (средний уровень АСКУЭ), компьютеры и компьютерные сети компонента АС сбора и обработки данных (верхний уровень АСКУЭ).
  3. ПО АСКУЭ должно быть достаточным для реализации всех функций, а также иметь средства для организации всех требуемых процессов обработки данных, позволяющие выполнять в реальной шкале времени все автоматизированные функции во всех регламентированных режимах функционирования системы. ПО должно представлять собой совокупность программных средств, обеспечивающих совместно с техническими средствами решение всех задач АСКУЭ.
  4. ПО АСКУЭ должно строиться с применением принципов структурного и модульного про­граммирования. Каждая задача должна реализовываться в виде одного или нескольких модулей. Вносимые изменения в модуль не должны влиять на функции других модулей.
  5. Требования к программному обеспечению средств измерений

ПО электронных счетчиков и УКПКЭ должны обеспечивать выполнение ими всех предусмотренных функций.

  1. Требования к программному обеспечению устройства сбора и передачи данных

ПО УСПД должно обеспечивать выполнение всех предусмотренных функций и иметь свободно настраиваемую открытую модульную структуру и для обеспечения функционирования прикладного ПО должна быть использована стандартная сетевая операционная система (Windows, Solaris, Unixи др.).

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

1. ПО верхнего уровня АСКУЭ может устанавливаться на компьютер в локальной (доступ­ной только по месту установки) или сетевой версии.Выбор операционной системы и типа версии АСКУЭ для каждой конкретной системы учета должен производить ее заказчик или проектировщик по согласованию с заказчиком.

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

3. ПО верхнего уровня АСКУЭ должно реализовывать функции сбора ЧРИ с ее нижних уровней (уровней электронных счетчиков и УСПД), накопления, хранения, обработки, отображения, документирования и распространения ЧРИ, синхронизации часов средств измерения и учета, а также других функций, зависящих от требований к конкретной АСКУЭ со стороны заказчика.

4. ПО верхнего уровня АСКУЭ должно обеспечивать процедуры:

  • гибкой настройки как по виду запрашиваемых и сохраняемых ЧРИ, так и по периоду и объему запросов;
  • полного сбора ЧРИ по автоматическим и ручным запросам с использованием перезапросов, до- запросов и мажоритарного голосования для выбора правильных ЦРИ;
  • контроля целостности и достоверности ЧРИ;
  • автоматического архивирования ЧРИ в стандартных БД и т. д.

5. Допускается совместная работа программного комплекса верхнего уровня АСКУЭ как с уникальной (фирменной), так и стандартными БД под соответствующими СУБД. Выбор БД и СУБД для каждой конкретной системы учета определяет ее заказчик. Длительность хранения ЧРИ должна быть не менее 36 месяцев.

6. Программный комплекс должен использовать единые классификаторы объектов БД, по­зволять фиксировать замену электронных счетчиков в точках учета, задавать режимы их опроса, обеспечивать корректность ЧРИ и параметров, считываемых с электронных счетчиков и помещаемых в БД, а также непрерывность и полноту ЧРИ.

7. Должна быть обеспечена возможность просмотра БД по выбранным точкам учета, интер­валам времени и типам ЧРИ, а также возможность установки для каждой точки учета при автоматическом опросе допустимого значения времени задержки ЧРИ, после превышения которого должно генерироваться аварийное сообщение.

8. При невозможности дистанционного считывания ЧРИ с нижнего уровня АСКУЭ должна быть предусмотрена возможность альтернативного считывания и занесения данных в БД (например, с переносного средства учета). При плановых и аварийных заменах электронных счетчиков должна быть предусмотрена возможность санкционированной ручной коррекции БД с учетом времени отсутствия средства измерения в соответствующей точке учета.

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

10. Программный комплекс должен обеспечивать регистрацию прав пользователей по уровням доступа, идентификацию и аудит всех их действий. В зависимости от уровня доступа пользователю должно представляться ограниченное по уровню доступа количество ЧРИ (пунктов меню, электронных счетчиков и т. д.).

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

12. Сетевая операционная система должна обеспечивать выполнение функций по диспет­черизации процесса распределения и обработки ЧРИ в реальном времени, управлению вводом- выводом данных, обеспечению сетевой поддержки.

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

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

  • коммерческих задач - задач для расчетов за расчетный период за отпущенную/потребленную энергию между субъектами рынка энергии;
  • задач оперативного контроля энергии и мощности по точкам и объектам учета;
  • балансных задач - задач расчетов оперативных балансов энергии и мощности по каждому объекту и субъекту учета;
  • задач общих потерь - задач фактических балансных потерь электроэнергии и мощности по объектам и субъектам учета;
  • задач технических потерь - задач для расчетов по электроэнергии фактических потерь в сило­вых трансформаторах и линиях электропередачи (технические потери составляют часть общих, но в частном случае могут совпасть с общими потерями);
  • задач ограничения и регулирования - задач для системного ограничения потребления энергии и мощности и регулирования нагрузки потребителей-регуляторов;
  • задач технического контроля - задач для контроля технического состояния средств АСКУЭ;
  • прогнозных задач - задач для краткосрочного, среднесрочного и долгосрочного прогнозирования выработки и потребления энергии по каждому объекту (субъекту) учета.

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

16. Периодичность решения балансных задач должна определяться контрольным перио­дом, длительность которого выбирается индивидуально по каждому объекту и субъекту учета, исходя из возможностей используемых каналов связи и особенностей субъекта. Рекомендуется в штатном состоянии субъекта использовать контрольный период от 30 мин до 1 сут, а в особом состоянии субъекта (например, при системных ограничениях) - от 3 до 30 мин.При решении балансных задач основной исходной информацией ЧРИ служат БД суточных получасовых или трехминутных графиков нагрузки по каждой точке коммерческого и технического учета, входящих в круг баланса, по каждому направлению учета как для активной, так и реактивной электроэнергии.

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

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

19.Прогнозные задачи в составе АСКУЭ предназначены для определения краткосрочных (на период 30 - 60 мин), среднесрочных (на период 1 - 30 сут) и долгосрочных (на период до года) величин энергопотребления по группе или отдельным крупным потребителям энергии. Исходной информацией ЧРИ должны служить данные суточных (трехминутных и/или получасовых), месячных (по­суточных) или годовых (помесячных) графиков нагрузки по подлежащему прогнозу потребителю (сумме точек его коммерческого учета) и каждому направлению учета, по активной и реактивной электроэнергии.

20.Задачи технического контроля служат для выявления нарушения в работе программно- технических средств АСКУЭ на всех уровнях. Периодичность решения этих задач должна быть непрерывной при каждой операции сбора, обработки, отображения или документирования ЧРИ.

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

22.Другие детальные требования к программному комплексу верхнего уровня АСКУЭ оп­ределяются заказчиками конкретных АСКУЭ.

SCADA — программный пакет, предназначенный для разработки или обеспечения работы в реальном времени систем сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления. SCADA может являться частью АСУ ТПАСКУЭ, системы экологического мониторинга, научного эксперимента, автоматизации здания и т. д. SCADA-системы используются во всех отраслях хозяйства, где требуется обеспечивать операторский контроль за технологическими процессами в реальном времени. Данное программное обеспечение устанавливается на компьютеры и, для связи с объектом, использует драйверы ввода-вывода или OPC/DDE серверы. Программный код, может быть, как написан на одном из языков программирования, так и сгенерирован в среде проектирования.

Иногда SCADA-системы комплектуются дополнительным ПО для программирования промышленных контроллеров. Такие SCADA-системы называются интегрированными и к ним добавляют термин SoftLogic.

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

Значение термина SCADA претерпело изменения вместе с развитием технологий автоматизации и управления технологическими процессами. В 80-е годы под SCADA-системами чаще понимали программно-аппаратные комплексы сбора данных в реальном времени. С 90-х годов термин SCADA больше используется для обозначения только программной части человеко-машинного интерфейса АСУ ТП.

SCADA-системы решают следующие задачи:

  • Обмен данными с «устройствами связи с объектом» (то есть с промышленными контроллерами и платами ввода-вывода) в реальном времени через драйверы.
  • Обработка информации в реальном времени.
  • Логическое управление.
  • Отображение информации на экране монитора в удобной и понятной для человека форме.
  • Ведение базы данных реального времени с технологической информацией.
  • Аварийная сигнализация и управление тревожными сообщениями.
  • Подготовка и генерирование отчетов о ходе технологического процесса.
  • Осуществление сетевого взаимодействия между SCADA ПК.
  • Обеспечение связи с внешними приложениями (СУБДэлектронные таблицы, текстовые процессоры и т. д.).

В системе управления предприятием такими приложениями чаще всего являются приложения, относимые к уровню MES.

SCADA-системы позволяют разрабатывать АСУ ТП как автономные приложения, а также в клиент-серверной или в распределённой архитектуре.

SCADA-система обычно содержит следующие подсистемы:

  • Драйверы или серверы ввода-вывода — программы, обеспечивающие связь SCADA с промышленными контроллерамисчётчикамиАЦП и другими устройствами ввода-вывода информации.
  • Система реального времени — программа, обеспечивающая обработку данных в пределах заданного временного цикла с учетом приоритетов.
  • Человеко-машинный интерфейс (HMIангл. Human Machine Interface) — инструмент, который представляет данные о ходе процесса человеку оператору, что позволяет оператору контролировать процесс и управлять им.
  • Программа-редактор для разработки человеко-машинного интерфейса.
  • Система логического управления — программа, обеспечивающая исполнение пользовательских программ (скриптов) логического управления в SCADA-системе. Набор редакторов для их разработки.
  • База данных реального времени — программа, обеспечивающая сохранение истории процесса в режиме реального времени.
  • Система управления тревогами — программа, обеспечивающая автоматический контроль технологических событий, отнесение их к категории нормальных, предупреждающих или аварийных, а также обработку событий оператором или компьютером.
  • Генератор отчетов — программа, обеспечивающая создание пользовательских отчетов о технологических событиях. Набор редакторов для их разработки.
  • Внешние интерфейсы — стандартные интерфейсы обмена данными между SCADA и другими приложениями. Обычно OPCDDEODBCDLL и т. д.
169