Дипломная (вкр): Диспетчерское управление автоматизированным производством на базе SCADA системы

Диспетчерское управление автоматизированным производством на базе SCADA системы

ВВЕДЕНИЕ

Ранние управляющие решения, предварившие наступление эры SCADA (Supervisory Control and Data Acquisition), назывались «телеметрическими» системами и представляли собой попытки организовать дистанционный мониторинг небольшого числа параметров (обычно одного-двух). В те времена никому и в голову не могло прийти, что уже к концу столетия оператор управляющей системы будет видеть буквально всё происходящее на удалённой станции. Тем не менее, все основные требования, которым должны удовлетворять современные решения типа SCADA, равно как и большинство обеспечиваемых такими решениями преимуществ, присутствовали уже в телеметрических системах начала 70 годов прошлого века хотя бы в зачаточном виде. Для отображения текущего состояния системы тогда использовались «имитационные стены» (mimic wall). Оперативность вывода информации на такие стены можно охарактеризовать как «приближающуюся к реальному времени»: показания индикаторов и лампочек изменялись вручную по мере того, как перемещающиеся по удалённым локациям операторы получали новые данные.

Аббревиатура SCADA расшифровывается как Supervisory Control and Data Acquisition - диспетчерский контроль и сбор данных. Почему контроль здесь назван «супервизорским»? В ранних SCADA-подобных системах вроде тех, что применялись в задачах водоснабжения и водоочистки в 60-70 годах XX века, связь между диспетчерской (головной станцией SCADA) и удалёнными станциями была столь призрачной, что организовать полноценный оперативный контроль не представлялось возможным [1].

В ранних SCADA системах, использовавшихся на предприятиях водоснабжения и сбора сточных вод, применялись арендованные телефонные пары, по одной паре на один сигнал/аларм. Однако это было слишком дорого и ненадежно. Это подвигало SCADA-операторов на поиск других решений. В 1970 годах многие попытались перейти на радиосвязь и немедленно столкнулись с целым рядом проблем: полосы частот тогда были значительно уже, чем в начале XXI столетия, а правила лицензирования частот в городах по всему миру были таковы, что зачастую превращали SCADA системы на базе радио в несбыточную мечту [2].

Ситуация упростилась после того, как в 70 годах прошлого века начался переход с аналоговой телеметрии, функционирующей по принципу частотной модуляции (Frequency Shift Keying/FSK), к цифровой телеметрии. Первые цифровые решения были частнофирменными, затем появились системы на базе COTS-продуктов (Commercial Off The Shelf/готовые коммерческие продукты с полки). Микропроцессоры вкупе с разработанными в НАСА технологиями сжатия и кодирования (метод Боуза-Чоудхури и др.) позволили организовывать передачу на одной радиочастоте (или по одной арендованной линии в тех случаях, когда использовать радио было нельзя) сразу несколько алармов и аналоговых величин [2].

В современных управляющих системах типа SCADA связь с полевыми устройствами и корпоративным уровнем реализуется поверх Ethernet или беспроводных сетей на базе технологий OPC (OLE for Process Control) и TCP/IP (Transmission Control Protocol/Internet Protocol), не привязанных жёстко к конкретным коммуникационным протоколам и средам. В самых новых системах применяются сервисы Microsoft .NET и стандарт XML (eXtensible Markup Language), которые расширяют возможности технологии OPC и традиционных сетевых коммуникаций [2].

Стоит задача обеспечить обучение специалистов использованию SCADA систем для работы на производстве, конструкторских бюро и научных учреждениях. В рамках дипломного проекта разработаны вопросы методического обеспечения использования SCADA систем для разработки объектов автоматизации для студентов 4-5 курсов и обобщены наработанные на кафедре РТС материалы по данному вопросу, в разработке которых активное участие принимали студенты в рамках НИРС.

Методические рекомендации разработаны на основе SCADA Citect.

1. ОСНОВЫ SCADA СИСТЕМ

Создание системы управления предусматривает выполнение следующих задач:

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

организация канала связи с устройством. Если в момент создания проекта все параметры канала связи будут неизвестны, вместо него можно воспользоваться «эмулятором», создаваемым в памяти компьютера;

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

создание графических страниц с помощью Графического редактора. После создания базовых страниц их можно будет заполнять требуемыми графическими объектами в соответствии с прикладным назначением;

определение с помощью Редактора проектов всех параметров, не связанных с графическими страницами (например, алармов, отчётов, событий, параметров регистрации данных и т.д.) [3].

1.1 Обмен информацией с внешними устройствами

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

Современные SCADA системы не ограничивают выбора аппаратуры нижнего уровня (контроллеров), так как предоставляют большой набор драйверов или серверов ввода/вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Для подсоединения драйверов ввода/вывода к SCADA системе в настоящее время используются следующие механизмы:

а) ставший стандартом динамический обмен данными DDE (Dynamic Data Exchange);

б) собственные протоколы фирм-производителей SCADA систем, реально обеспечивающие самый скоростной обмен данными;

в) ОРС-протокол, который, с одной стороны, является стандартным и поддерживается большинством SCADA систем, а с другой стороны, лишен недостатков протоколов DDE [1].

Изначально протокол DDE применялся в первых человеко-машинных системах в качестве механизма разделения данных между прикладными системами и устройствами типа ПЛК (программируемые логические контроллеры). Для преодоления недостатков DDE, прежде всего для повышения надежности и скорости обмена, разработчики предложили свои собственные решения (протоколы), такие, как AdvancedDDE-или FastDDE-протоколы, связанные с пакетированием информации при обмене с ПЛК и сетевыми контроллерами. Но такие частные решения приводят к ряду проблем:

для каждой SCADA системы пишется свой драйвер для поставляемого на рынок оборудования;

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

Основная цель ОРС-стандарта (OLE for Process Control) заключается в определении механизма доступа к данным с любого устройства системы управления. ОРС позволяет производителям оборудования поставлять программные компоненты, которые стандартным способом обеспечат клиентов данными с ПЛК. При широком распространении ОРС-стандарта появятся следующие преимущества:

- ОРС позволят определять на уровне объектов различные системы контроля и управления, работающие в распределенной неоднородной среде;

-   ОРС устранят необходимость использования различного нестандартного оборудования и соответствующих коммуникационных программных драйверов;

-   у потребителя появится больший выбор при разработке приложений.

1.2 Взаимодействие SCADA системы Citect с устройствами ввода/вывода

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

В зависимости от способа подключения к системе Citect все устройства можно условно разделить на две категории: локальные (Local) и удалённые (Remote) [1].

а) Локальные устройства в/в подключаются к серверам в/в Citect непосредственно.

б) Удалённые устройства подключаются к системе Citect через промежуточные средства связи (радиоканалы, модемные и телефонные линии и т.д.) [1].

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

Типы каналов связи

Система Citect поддерживает четыре следующих типа связи:

- последовательная,

-   связь с интерфейсными модулями ПЛК,

-   связь с модулями накопления данных,

-   связь с DDE-серверами.

Независимо от того, является ли устройство ввода вывода локальным или удалённым, наиболее часто его подключение к системе выполняется последовательными линиями связи. Как правило, используется один из трёх общепринятых стандартов: RS-232. RS-422 и RS-485 [1].

Система Citect поддерживает множество способов подключения устройств ввода/вывода: к коммуникационным СОМ-портам компьютера, к модулям высокоскоростной последовательной связи либо к специальным связным адаптерам, поставляемым производителем устройства ввода вывода. В любом случае настройка параметров взаимодействия будет простой благодаря использованию мастера настройки связи с устройствами ввода вывода [1].

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

какие-либо управляющие команды типа команды запуска электродвигателя, изменения скорости вращения вала, открытия вентиля, включения индикаторной лампы и т.д. В некоторых устройствах ввода вывода (типа ПЛК) выдача выходных сигналов осуществляется под контролем программы [1].

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

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

Обычно читать данные из всех регистров устройства (или записывать в них новые данные) нет необходимости, и в состав системы Citect входит редактор проектов, с помощью которого пользователь определяет, какие входные и выходные сигналы требуется контролировать. После указания адресов соответствующих регистров можно использовать их в программах управления системой, вывода информации на операторский экран, построения трендов, регистрации данных и генерации алармов [1].

Устройства ввода/вывода типа ПЛК. как правило, уже имеют в своём составе программы, обеспечивающие низкоуровневое регулирование производственных процессов. Программа ПЛК непрерывно считывает (сканирует) входные регистры контроллера и устанавливает значение выходных регистров в соответствии с внутренней логикой управления. Хотя система Citect в состоянии заменить собой программу ПЛК, делать этого не рекомендуется. ПЛК отличаются очень малым временем реакции (как правило, от 1 до 100 мс). Замена их системой Citect может привести к значительному снижению общей производительности системы управления. Назначение системы Citect - дополнять программы ПЛК (т.е. обеспечивать управление и мониторинг на высоком уровне) [1].

Компьютер, с которым непосредственно соединено устройство ввода вывода, называется сервером ввода/вывода. Сервер ввода вывода хранит в своей кэш-памяти актуальные данные, получаемые в результате периодического обращения ко всем подключенным к нему устройствам. Когда бы клиент Citect (дисплейный клиент, сервер трендов, сервер отчётов и т.д.) ни обратился к серверу, последний всегда выдаст самую последнюю информацию из своего кэша [1].

Система Citect обращается к компьютеру, к которому непосредственно подключено устройство ввода вывода, как к серверу ввода/вывода. С одним и тем же сервером может быть соединено несколько устройств. Чтобы получить информацию о состоянии устройства ввода вывода, клиент Citect (дисплейный клиент, серверы трендов, отчётов и т.д.) обращается не к самому устройству, а к соответствующему серверу, который осуществляет непосредственный обмен данными с устройством [1].

1.2.1 Переменные тэги

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

Преимущество использования переменных тэгов заключается в том, что:

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

б) адрес в устройстве ввода/вывода определяется только один раз. При изменении адреса достаточно изменить определение переменного тэга - а не каждую ссылку на этот адрес в программе:

в) в определении переменного тэга исходные данные можно масштабировать [3].

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

В системе Citect также поддерживаются такие типы, как вещественный (Real), символьный (String), байтовый (Byte), двоично-десятичный (BCD), расширенный целый (Long) и расширенный двоично-десятичный (LongBCD).

После определения переменных тэгов их можно использовать:

- при отображении объектов на графической странице.

-   для хранения данных, используемых для построения трендов и анализа.

-   для мониторинга алармов.

-   для управления оборудованием и технологическими процессами.

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

Рисунок 1.1 - Параметры переменных тэгов

Переменные тэги обладают следующими параметрами (смотри рисунок 1.1):

а) Название тэга. Оно должно быть не длиннее 32 символов. Рекомендуется использовать стандартизованный способ назначения имен, чтобы облегчить последующую работу с ними, их поиск и сортировку (название должно быть уникально в пределах кластера).

б) Тип данных - 16 символов.

BCD - двоично-десятичный. Занимает 2 байта памяти, допустимые значение 0-9999.

BYTE - байтовый, занимает 1 байт памяти, допустимые значении 0-255

DIGITAL - логический , занимает 1 бит или байт, допустимые значения 0 или 1

INT - целые со знаком, занимает 2 байта, допустимые значения - 32768-32767

UINT - Целые без знака, занимает 2 байта допустимые значения 0-65535.

LONG - расширенный - 4 байта, допустимые значения -2147487648-2147484647

LONGBCD - расширенные двоично-десятичные, 4 байта, 0-999999999

REAL - вещественный с плавающей запятой 4 байта , допустимые значения - 3,4е38-3,4e38

STRING - символьный, до 256 байтов, ASCII (c нулевым завершающим байтом.)

Тип определяемого переменного тэга должен соответствовать типу данных устройства ввода-вывода. Каждый тип данных отличается своим форматом адреса, который необходимо соблюдать при определении адреса переменной. Система Citect допускает конкатенацию регистров устройств ввода-вывода. Например, два подряд идущих регистра устройства ввода-вывода можно определить в системе Citect как один тэг вещественного типа. Система будет считывать оба регистра и возвращать результат как вещественное число. При конкатенации регистров результирующие адреса должны быть либо все четные, либо все нечетные. Этой возможностью нужно пользоваться осторожно, устройство ввода-вывода должно обеспечивать целостность второго регистра [3].