Курс лекций для студентов высших учебных заведений Чебоксары 2012 scadaсистема каскад. Курс лекций для студентов вузов. Ооо Каскадасу, г. Чебоксары, 2012 г. Страница 2 Оглавление
Скачать 1.21 Mb.
|
2. События. Подсистема регистрации событий является обязательным компонентом SCADA-системы «КАСКАД». Её основная функция — это регистрация всех событий, происходящих в системе. Под событиями понимаются действия пользователей, изменение настроек, управление технологическим процессом, аварийная сигнализация и реакция оператора на неё, сработка защит, служебные логи серверных модулей системы и т.д. Используемая СУБД для баз данных событий – Firebird. Подсистема регистрации событий состоит из следующих частей: 1) модуль настройки баз данных событий; 2) модуль регистрации событий; 3) модуль просмотра событий. 2.1. Модуль настройки баз данных событий. 2.1.1. Базы данных событий. Для любого проекта обязательно должна быть настроена хотя бы одна база данных событий, иначе система не будет работать. Создавать новые проекты следует из Конфигуратора, с помощью «Мастера создания проектов», который позаботится о наличии в новом проекте как БД пользователей, так и БД событий. Созданная БД событий будет являться БД по умолчанию – базой данных, которая используется всеми станциями проекта (в том числе незарегистрированными) и которую нельзя удалить. В простейшем случае для проекта достаточно настроить только одну базу данных событий. Если необходимо, существует возможность создавать и вести свои БД событий для каждой станции или для группы станций проекта. При этом каждая станция будет производить запись событий в соответствующую ей базу данных. Если станция не зарегистрирована в проекте (с помощью программы «Настройка сетевого взаимодействия»), то для неё будет использоваться БД по умолчанию. Любая (но только одна) БД событий проекта может быть назначена в качестве БД по умолчанию. В списке БД событий БД по умолчанию выделена жирным шрифтом: SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 11 Рис. 2.1. Список БД событий Для каждой БД событий обязательно необходимо настроить параметры подключения к файлу БД и создать собственно файл БД. Кроме этого, имеется возможность задать ограниченный срок хранения данных, настроить резервирование и создание архивных копий, посмотреть статистику по выбранной БД, создать backup-копию и т.д. 2.1.2. Группы событий. Для того, чтобы визуально отличить события различного происхождения и важности друг от друга, каждое событие системы записывается в свою группу. Группы событий могут объединяться в категории. Количество групп и категорий в проекте не ограничено. SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 12 Рис. 2.2. Категории и группы событий На рис. 2.2 корневыми элементами списка являются категории, дочерними – группы. «Мастер создания проектов» автоматически добавляет в проект список групп событий по умолчанию. При необходимости этот список можно изменить, добавив туда новые категории и группы. Кроме того, новые группы событий могут автоматически создаваться модулями SCADA-системы в процессе её работы. Такие группы по умолчанию будут относиться к категории, помеченной «для новых групп». При необходимости их можно переместить в любую другую категорию. Для визуального выделения событий, относящихся к той или иной группе, в свойствах группы можно настроить цвет шрифта и фона, а также выбрать подходящую пиктограмму. Таким образом события «особо важных групп» можно выделить в общем списке ярким цветом или фоном. Как правило, группы событий невозможно удалить из проекта, т.к. большинство групп создаётся модулями SCADA-системы автоматически. Из проекта возможно удалить только группы, добавленные пользователем. Тем не менее, любую группу или даже целую категорию событий при необходимости можно отметить как «незаписываемую». События, относящиеся к подобным группам, будут игнорироваться модулем регистрации событий и, соответственно, не будут записываться в БД. 2.2. Модуль регистрации событий Как следует из названия, данный модуль производит регистрацию всех событий системы в базы данных событий – это его основная функция. Кроме этого, он осуществляет очистку БД от устаревших данных и резервирование, если это настроено. 2.3. Модуль просмотра событий Этот модуль служит для просмотра событий SCADA-системы «КАСКАД» в виде списка. SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 13 Рис. 2.3. Список событий Модуль просмотра событий имеет следующие возможности: • фильтрация событий по выбранным базам данных, группам событий, зонам производства, станциям, типам событий; • выборка событий за конкретную дату или период; • выделение событий по группе, зоне производства или даже по параметру; • следящий режим; • поиск и сортировка событий; • предварительный просмотр и печать; • экспорт событий в файл Microsoft Excel, в текстовый файл или в отдельный файл БД. Дополнительно к модулю просмотра событий, в SCADA-системе «КАСКАД» существуют панель расширения и объект для модуля визуализации, предназначенные для вывода событий на мнемосхемы. Кроме этого, в модуле формирования рапортов имеется специальный алгоритм, позволяющий генерировать отчёты, содержащие данные из БД событий. 3. Сервер Доступа к Данным. Сервер Доступа к Данным, или СДД,- это одно из основных приложений SCADA-системы «Каскад». Задачей его является сбор и обработка данных с устройств, архивирование данных в соответствии с заданными алгоритмами, контроль данных и генерация событий сигнализации (алармов) в случае выхода параметров за допустимые пределы. За выполнение каждой из задач отвечает свой модуль в составе СДД. По сути, сам СДД – это некая оболочка, объединяющая различные модули и обеспечивающая их взаимодействие между собой в рамках заданной роли. Благодаря такой модульной организации можно легко дополнить функционал СДД без необходимости его перекомпиляции. Любой сторонний пользователь может написать свой драйвер или модуль обработки данных, который автоматически будет подключен к Серверу Доступа к SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 14 Данным. Разумеется, при этом необходимо обеспечить наличие необходимых программных интерфейсов в модуле, но рассматривать их в рамках данной лекции мы не будем. Рис. 3.1 Структура Сервера Доступа к Данным. Настройка модулей доступа к данным (МДД) и некоторым модулям обработки данных (МОД) производится в Конфигураторе Сервера Доступа к Данным. Рис.3.2. Конфигуратор СДД. Для каждого задействованного в обработке данных МДД создается и настраивается своя конфигурация. Список настроенных конфигураций доступен на вкладке Конфигурации. Полный список доступных МДД отображается на вкладке Список МДД. Модули доступа к данным Массив параметров технологического процесса Клиент OPC KLogic ModBus RTU/TCP/ ASCII Счетчики, расходом еры … Контрол- леры Модуль предоставления доступа к СДД Модуль обработки паспортов Интерфейс для клиентских приложений SCADA-системы «КАСКАД» Сервер доступа к данным Обмен данными с внутренними модулями Обмен данными с внешними модулями (TCP/IP) Модуль прямого доступа к устройствам под управлением KLogic Модуль ведения баз данных ТП Модуль сигнализации Модули обработки данных SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 15 Наличие галочки около названия конфигурации говорит о том, что при загрузке СДД указанная конфигурация загрузится и начнет работать. Отсутствие галочки, соответственно, укажет на то, что данная конфигурация в работу СДД включена не будет. При двойном щелчке на конфигурации или нажатии на кнопку Настроить откроется окно настройки конфигурации. Список задействованных МОДов доступен на вкладке Модули расширения. Модули расширения могут быть обязательными и необязательными. Обязательные – это модуль обработки паспортов, модуль регистрации технологических параметров, модуль аварийно-предупредительной сигнализации. Настройка этих МОДов производится соответствующими внешними приложениями отключить их нельзя, поэтому в списке модулей расширения они отсутствуют. Остальные МОДы настраиваются подобно МДД: наличие галочки говорит о задействовании МОДа в работе сервера, а двойной щелчок вызовет окно конфигурирования. Вернемся к настройке МДД. Рис.3.2. Настройка конфигурации МДД. По сути, Модуль доступа к данным – это драйвер, который, с одной стороны, реализует протокол обмена данными с заданным типом устройств, а с другой стороны, представляет эти данные в универсальном виде, пригодном для использования SCADА-системой. Проще говоря, с одной стороны МДД обращается непосредственно к сигналам и каналам устройства, а с другой стороны представляет их в виде неких универсальных единиц – тегов. Теги могут быть двух типов, обусловленных двумя возможными типами сигналов: аналоговыми и дискретными. Каждый тег однозначно соответствует определенному сигналу устройства. При изменении сигнала меняется и значение тега. Запись данных тег означает подачу команды устройству на установку определенного уровня конкретного сигнала. Для удобства восприятия теги группируются по определенным критериям, образуя группы. Один МДД, как правило, позволяет обмениваться данными не с одним устройством, а сразу с несколькими, объединенными в сеть. Для того, чтобы выделить каждое устройство внутри конфигурации и дать возможность задать специфичные настройки (например, номер устройства в сети или его IP-адрес), внутри конфигурации для каждого устройства создается более крупная, чем группа, единица, которая так и называется: Устройство. Соответственно, единые для всех устройств настройки (номер COM-порта, скорость обмена, тип сети устройств и т.п.) настраиваются в свойствах Конфигурации Таким образом, иерархия представления данных в конфигурациях Модулей доступа к данным выглядит следующим образом: • Конфигурация • Устройство • Группа • Тег SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 16 После того, как МДД сконфигурирован, для него созданы устройства, группы и теги, настроены параметры связи с устройством, можно проверить обмен данными с устройствами, запустив опрос устройств. Если данные поступают, обмен происходит корректно, значит, МДД настроен правильно. Сохраняем конфигурацию, закрываем конфигуратор Сервера доступа к данным и переходим к настройке паспортов. 4. Паспорта. Задача тегов – предоставить данные СДД в универсальном формате. Благодаря такому представлению при работе с тегами уже нет необходимости задумываться, по какому протоколу, с каких типов устройств и каким образом получены данные. Всю работу по связи с железом взял на себя МДД, это и есть его прямая задача. Однако тег – это, как правило, сырое значение, и не обязательно он несет в себе числовое значение измеряемой величины. Это может быть код АЦП, либо величина силы тока, либо величина, выдаваемая датчиком с квадратичной шкалой измерения. В этих случаях сигнал необходимо пересчитать в реальное значение измеряемой величины. Для такого преобразования предназначены Паспорта сигналов. Они на входе получают значения тегов, а на выходе выдают реальные значения величин. Помимо этого паспорта хранят в себе массу дополнительной информации: шифры, наименования сигналов, единицы измерения, способы преобразования данных и т.д. Настройка паспортов производится в Модуле настройки паспортов. Рис.4.1. Модуль настройки паспортов. Паспорта, как и теги, подразделяются на 2 типа сигналов: аналоговые и дискретные. Кроме того, паспорта делятся еще и на первичные и вторичные. Первичные паспорта непосредственно привязаны к тегам, и значение первичного паспорта напрямую зависит от значения соответствующего ему тега. Это типы паспортов Аналоговый и Дискретный . Задачей первичных паспортов является получение значений тегов и базовое преобразование этих значений: пересчет из квадратичной шкалы, масштабирование, смещение сигналов, удаление паразитных шумов и фильтрация для аналоговых сигналов, и инверсия для дискретных. SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 17 Рис.4.2. Настройка паспорта аналогового параметра Вторичные паспорта к тегам не привязаны, источниками данных для них являются другие паспорта. Задачей вторичных паспортов является более сложная обработка данных. К вторичным относятся следующие типы паспортов: Корректируемые, Сумматоры, Умножители, Формулы, Условия, Мультиплексоры, Дискретное управление, Функции и Скрипты. Самым мощным и самым универсальным типом паспорта, а поэтому и самым медленным в исполнении является паспорт-скрипт. Он позволяет производить обработку данных по алгоритмам любой сложности и ветвления, писать скрипты на C++ и Object Pascal, использовать процедуры и функции, но выполняется он относительно медленно – около 50 мс на один скрипт. Поэтому рекомендуется при использовании скриптов не создавать 2 десятка мелких скриптов, а организовать один скрипт, реализующий эти 2 десятка алгоритмов обработки. Общий принцип настройки паспортов следующий. Создаются первичные паспорта, каждый первичный паспорт привязывается к соответствующему тегу. Для того, чтобы паспорт мог сгенерировать шифр и/или наименование из имени тега, необходимо в Настройках указать необходимые маски преобразования. Для того, чтобы быстро создать большое количество первичных паспортов, необходимо воспользоваться пунктом Создать группу паспортов. В этом случае нам необходимо выбрать лишь теги, на основе которых будут создаваться паспорта и нажать ОК. После этого для каждого тега будет создан свой паспорт, привязанный к нему. Созданные паспорта будут сгруппированы так же, как были сгруппированы соответствующие им теги. Точно так же, как и при настройке тегов, при настройке паспортов можно запустить опрос – тогда мы сможем наблюдать получение данных от Сервера Доступа к Данным. Очевидно, что если при опросе тегов МДД сам реализовывал связь с устройством, и при этом СДД должен был быть выгружен, то в случае с паспортами СДД наоборот, должен быть запущен. Модуль настройки паспортов в этом случае, по сути, представляет собой клиентское приложение, и запрашивает данные так же, как это делает Визуализация. И если данные модуль настройки паспортов получает корректно, то так же корректно их получит и модуль Визуализации. Останавливаться на настройках каждого из типов паспортов не будем. Особенности настройки каждого типа достаточно подробно разъяснены в системе справки и поддержки и в руководстве пользователя. SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 18 Лекция 3. Система программирования микропроцессорных контроллеров с открытой архитектурой KLogic. Система программирования контроллеров (СПК) KLogic является инструментом технологического программирования контроллеров в составе автоматизированных систем управления технологическими процессами, оперативно-диспетчерского управления, систем коммерческого и технического учета ресурсов. СПК KLogic полностью интегрирована в SCADA-систему КАСКАД, но она также может использоваться отдельно от нее, с другим программным комплексом (или вообще без верхнего уровня). 1. Понятие технологической программы. Технологическая программа содержит в себе описание окружения контроллера (дискретные и аналоговые модули ввода-вывода, устройства связи с объектами и прочая периферия), настройки связи и периодичности их опроса, описание алгоритмов работы, заданных пользователем. Цикл выполнения технологической программы для любого контроллера выглядит следующим образом (рис. 1.1). Рис. 1.1. Цикл выполнения технологической программы. Чтение данных с каналов ввода подразумевает под собой получение текущего состояния объекта: значения необходимых технологических параметров (температура, давление, скорость) или их состояния (состояние кнопки, двигателя, выключателя). Далее происходит анализ полученного состояния объекта с использованием тех или иных инструментов, обычно под ними подразумеваются языки программирования контроллеров МЭК 61131-3 , либо их модификации. Вслед за проведением анализа, в контроллере происходит формирование ответной реакции на текущее состояние и его запись в каналы вывода. 2. Структура KLogic СПК KLogic состоит из двух программных частей: Инструментальная система , при помощи которой происходит конфигурирование и настройка контроллера. Инструментальная система (KLogic IDE) работает на платформе Win32 и предоставляет пользователю графический интерфейс, при помощи которого можно создать, загрузить и отладить технологическую программу для контроллера. Кроме набора предопределенных алгоритмов имеется возможность реализовывать собственные алгоритмы на двух языках программирования, максимально приближенных по синтаксису к языкам Pascal, C. Помимо этого, при помощи инструментальной системы, можно изменить коммуникационные настройки и время контроллера, выполнить сервисные функции (удаление конфигурации, перезагрузка контроллера и прочее) Исполнительная система , выполняющаяся на контроллере с открытой архитектурой (то есть имеющей опубликованную спецификацию работы с ним). Исполнительная система тесно работает с программными и аппаратными ресурсами контроллера, в число которых входит оперативная и SCADA-система КАСКАД. Курс лекций для студентов ВУЗов. © ООО «Каскад-АСУ», г. Чебоксары, 2012 г. Страница 19 постоянная память, коммуникационные порты, встроенные каналы ввода-вывода, светодиоды. Основная задача исполнительной системы - выполнение технологической программы, и дополнительные сервисные функции, в том числе коммуникации с инструментальной системой, изменение времени контроллера, конфигурации Ethernet-портов и прочее. Исполнительная система KLogic максимально абстрагирована от конкретного оборудования и портирована на следующие целевые платформы и операционные системы: • I7188, I8000 – MiniOS7 • МФК, ТКМ-52 – MS DOS • Ломиконт – MS DOS • Платформы Win32, WinCE • Контролер ТКМ410, операционная система eCos • Контроллер Теконик P06, операционная система Linux • Контроллер Деконт А9, операционная система Linux • Контроллеры Moxa UC-7112LX Plus, IA-240, операционная система Linux • Контроллер UCDK, операционная система Linux Взаимодействие инструментальной и исполнительной системы KLogic осуществляется по специализированному набору функций, основанных на коммуникационном протоколе Modbus, по каналам последовательной связи (COM-порт) и Ethernet. Возможность интеграции контроллеров KLogic в другие системы верхнего уровня обеспечивает поставляющийся в комплекте OPC-сервер. Рис. 1.2. Организация связи с контроллером. Независимо от типа используемого контроллера и его операционной системы, все взаимодействие между компьютером и контроллером осуществляется через инструментальную систему KLogic. Исполнительная система KLogic поддерживает сбор данных по более чем 40 протоколам. При помощи контроллера под управлением KLogic можно интегрировать различные линейки модулей ввода-вывода, счетчики различных видов ресурсов (электроэнергия, вода, тепло), терминалы релейной защиты аппаратуры и прочее оборудование |