Автоматизированная система управления очистки городских сточных вод

При необходимости передачи данных длиной более восьми байтов применяется механизм фрагментации. В зависимости от потребностей обмена и возможностей модулей возможны мастер ведомый (master slave), мультимастерный (multi master) или равноправный (peer to peer) способы взаимодействия устройств. Пересылки данных могут инициироваться путем опроса, циклически или при изменении их значения (change of state).

Максимальное число узлов в сети DeviceNet - 64.Такое ограничение связано с 6 разрядным двоичным форматом идентификатора модуля MAC ID (он является частью CAN ID, причем в DeviceNet используется только стандартный тип CAN фрейма с 11 разрядным ID). Однако общее число устройств ввода вывода может достигать 2048 (по 32 на узел).

Модули в сети могут быть как UCMM типа (UnConnected Message Manager), способные выставлять равноправные (peer to peer) соединения с другими модулями, так и Predefined Master/Slave типа, которые не могут произвольно выбирать путь соединения, и их объекты соединения конфигурируются при включении устройства. Реализация последнего типа модуля требует меньшей длины кода и производительности управляющего микроконтроллера, что снижает общую стоимость устройства.

В сети DeviceNet не всегда устройство с меньшим значением идентификатора модуля - MAC ID (он составляет лишь часть CAN идентификатора) выигрывает арбитраж. Это зависит и от того, к какой группе принадлежит сообщение. Всего таких групп четыре (в порядке убывания приоритета):

наиболее критичные ко времени доставки сообщения;

явные и сообщения ввода вывода для соединения типа Predefined Master/Slave;

несрочные сообщения, использующиеся для диагностики и мониторинга;

сообщения для off line подключения используются на этапе инсталляции модулей.

Для обеспечения стыкуемости устройств разных производителей и их взаимодействия в рамках единой сети стандарт DeviceNet, подобно некоторым другим HLP, определяет ряд профилей устройств. Формированием и стандартизацией библиотек профилей занимаются специальные группы (Special Interest Groups) ассоциации ODVA.

Более 285 производителей членов ассоциации ODVA занимаются разработкой и производством устройств, инструментальных средств и программного обеспечения для сетей DeviceNet.

3.2.5 SDS (Smart Distributed System)

SDS - продукт компании Honeywell Inc (Micro Switch Division). Наряду со стандартом DeviceNet, SDS представляет собой еще одно недорогое и законченное решение для сетевого управления интеллектуальными датчиками и актуаторами от центрального контроллера (PLC, компьютера) в системах промышленной автоматизации. По степени завершенности - от спецификаций физической среды до прикладного уровня - и по ориентировке на снижение стоимости системы SDS стандарт напоминает DeviceNet, а функционирование сети походит на работу сети DeviceNet в режиме Predefined Master/Slave.

Архитектура протокола SDS включает в себя три уровня модели OSI/ISO - физический, канальный и прикладной. Шинная топология представляет собой линейную шину (магистраль или транк) короткими отводами (рисунок 3.14).

Рисунок 3.14 - Пример сети SDS

Определены два базовых типа кабельной разводки:

Mini (применяемый при сборке транка сети) - 4-проводной кабель максимальной токовой нагрузкой 8 А;

5-и контактный разъем, и Micro (для подключения физических устройств к сети) - 4 проводной кабель,3 А, 4-х контактный разъем без отдельного контакта для экрана кабеля.

В сети SDS допускается и обычная проводная разводка с использованием открытых клеммных соединителей. Всеми типами кабельной разводки и соединителей, так же как и в сети DeviceNet, предусмотрено подведение питающего напряжения (диапазон 11 25 В на стороне устройства) к узлам. Предельные значения длин магистрали и отводов сети SDS в зависимости от скорости передачи приведены в таблице 2. Дробные представления длин в метрах вязаны с прямым пересчетом их величин, выраженных в футах

Таблица 3.2 - Соотношение длин магистрали и отводов сети SDS

Длина магистрали, м	Скорость передачи кбит/сек	Максимальная длина отводов, м	Максимальное количество узлов
22,8	1000	0,3	32
91,4	500	0,9	64
182,2	250	1,8	64
457,2	125	3,6	64

Сообщения, циркулирующие в сети SDS, носят название APDU (Application layer Protocol Data Unit) - блоки данных протокола прикладного уровня. APDU представляет собой CAN фрейм стандартного формата (расширенный формат фрейма в SDS сети не применяется), элементы которого имеют свое собственное назначение в SDS (рисунок 3.15).



Рисунок 3.15 - Заголовок APDU в сети SDS

В поле арбитража (ID3 ID9) расположен 7 разрядный адрес устройства (максимально допустимое количество устройств в сети SDS - 126). Тип APDU (3 разрядное поле)определяет тип сервиса (0 …7) прикладного уровня, которому соответствует данный APDU. Нулевое значение бита ID10 (DIR)поля арбитража указывает, что адрес устройства (device adrress) является адресом назначения, а единичное - адресом источника. Чем ниже значения логического адреса, тем выше приоритет сообщения. Бит RTR в SDS CAN фреймах всегда имеет нулевое значение (удаленный CAN фреймв SDS спецификации не применяется). Блок APDU имеет две формы - укороченную и длинную. Укороченная форма APDU содержит в поле DLC все нули и для передачи данных не используется. В поле данных длинной формы APDU содержится код длины (2 …8) поля данных CAN фрейма (2), два первых байта которого содержат спецификатор сервиса (Service Specifier), идентификатор встроенного объекта (EOID)и дополнительные параметры сервиса, а оставшиеся шесть предназначены для передачи собственно данных. При необходимости передачи последовательностей данных более шести байтов используется фрагментированный формат (до 64 фрагментов по 4 байта) длинной формы APDU.

Укороченная форма APDU используется в следующих сервисах прикладного уровня:

Change of State (Off, On, Off ACK, OnACK) - обнаружение изменения состояния логического устройства;

Write (On State, Off State, On StateACK, Off State ACK) - управление состояниями логического устройства.

К сервисам, использующим длинную форму APDU, относятся следующие:

Channel - обеспечение как широковещательного (multicast), так и равноправного (peer to peer) каналов соединения;

Connection - открытие/закрытие индивидуальных типов соединения;

Write - чтение атрибутов объектов устройства;

Read - изменение атрибутов объектов устройства;

Action - команда объекту устройства выполнить действие;

Event - сигнализация объектов устройства о событии.

При инициализации взаимодействия модулей сети SDS используются 4- е сервисные функции примитива:

Запрос (Request) - генерация APDU устройством инициатором соединения;

Ответ (Response) - ответный APDU устройства ответчика;

Индикация (Indication) - фиксация факта приема APDU устройством ответчиком;

Подтверждение (Confirm) - подтверждение приема APDU устройством инициатором.

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

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

Модули с внешним питанием (не от SDS шины) должны иметь механизм обнаружения пропадания питания шины для блокировки своей активности и выполнения автонастройки скорости после повторного включения сети. В сети SDS возможны четыре скорости передачи данных: 1 Мбит/с, 500,250 и 125 кбит/с.

3.2.6 Сравнение протоколов CAN. Прочие HLP

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

Далеко не последнюю роль играет и поддержка того или иного HLP со стороны производителей CAN оборудования и инструментальных средств. Самым простым и компактным вариантом объединения несложных промышленных устройств под управлением одного мастера является стандарт SDS. Несколько более развитые сервисы предоставляет спецификация DeviceNet. Наибольшей гибкостью и возможностью максимально эффективной реализации режима реального времени обладает протокол CAN Kingdom. В отличие от трех других рассмотренных протоколов, CANKingdom не касается каких либо аспектов физического уровня (среда, соединители и т.п.), выходящих за рамки стандарта ISO 11898, и представляет собой высокоуровневую надстройку над канальным уровнем CAN. В таблицу 3.3 сведены некоторые характеристики четырех рассмотренных в статье HLP.

Таблица 3.3 - Сравнительные характеристики 4-х CAN HLP

	CANopen	Can Kingdom	DeviceNet	SDS
Допустимые скорости передачи данных, кбит/с	10,20(обязательная), 50,125,250, 500,800,1000	Любые до 1000, инициализация на 125	125, 250, 500	125,250, 500, 1000
Защита от некорректной установки скорости передачи модулей	Нет	Да	Нет	Нет
Автонастройка скорости передачи	Нет	Возможна, но не определена	Возможна, но не определена	Нет
Допустимые номера узлов	0 - 27	0-255	0-63	0-127
Поддержка расширенного CAN фрейма	Нет	Да	Нет	Нет
Наличие профилей устройств	Да (CiA SIG)	Нет	Да (ODVA SIG)	Да (Honeywell Inc.)
Поддержка протокола	CiA (CAN in Automation)	KVASER AB	ODVA (Open DeviceNet )	Honeywell Inc.
Спецификация соединителей	Да	Нет	Да	Да

Среди других прикладных CAN протоколов, получивших признание в последнее время, можно выделить стандарт SAE J1939 (SAE - Society of Automotive Engineers), пришедший на смену более старому J1708/J1587 и предназначенный для управления в режиме реального времени узлами транспортных средств (грузовики, автобусы), реализующий plug&play режим для модулей и использующий расширенный формат (29 битовый идентификатор) CAN фрейма. Ряд специализированных групп (например, HUG - Hydraulic Users Group) в области промышленной автоматизации работают над собственными дополнениями уже существующих CAN HLP в целях адаптации их параметров к своим областям применения.

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

В последние годы во всем мире наблюдается стремительный рост числа разработок CAN сетей и расширение спектра областей применения CAN-технологий.

По информации ассоциации CiA, если в 1996 году в мире было установлено 11 млн. CAN узлов, в 1997 - 25 млн., то в 1998 - уже более 59 миллионов. Прогнозируемое число на 1999 год - около 83 млн., а на 2000 год - более 125 млн. узлов. Эти прогнозы не учитывают все возрастающий интерес к сетям CAN со стороны североамериканских производителей, а также крупнейших юго-восточных корпораций. Непрерывно расширяется и предложение готовых модулей, а также инструментальных программных и аппаратных средств для тех или иных стандартов прикладных протоколов.

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

4 Выбор программного обеспечения верхнего уровня

4.1 Общие сведения

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

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

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

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

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

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

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

Концепция SCАDA (Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных) предопределена всем ходом развития систем управления и результатами научно-технического прогресса. Применение SCADA-технологий позволяет достичь высокого уровня автоматизации в решении задач разработки систем управления, сбора, обработки, передачи, хранения и отображения информации.

Дружественность человеко-машинного интерфейса (HMI/MMI), предоставляемого SCADA - системами, полнота и наглядность представляемой на экране информации, доступность "рычагов" управления, удобство пользования подсказками и справочной системой и т. д. - повышает эффективность взаимодействия диспетчера с системой и сводит к нулю его критические ошибки при управлении.

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

В настоящее время SCADA является основным и наиболее перспективным методом автоматизированного управления сложными динамическими системами (процессами).

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

В России диспетчерское управление технологическими процессами опиралось, главным образом, на опыт оперативно-диспетчерского персонала. Поэтому переход к управлению на основе SCADA-систем стал осуществляться несколько позднее. К трудностям освоения в России новой информационной технологии, какой являются SCADA-системы, относится как отсутствие эксплуатационного опыта, так и недостаток информации о различных SCADA-системах. В мире насчитывается не один десяток компаний, активно занимающихся разработкой и внедрением SCADA-систем. Хорошо известными на нашем рынке являются следующие: InTouch (Wonderware), LookOut (National Instruments), Fix (Intellution), BridgeView, Genesis 32 (Iconics), WinCC (Siemens), RSView (Rockwell Automation) и другие.

4.2 Системы контроля и управлени

4.2.1 Компоненты систем контроля и управления и их назначение

Рисунок 4.1 - Обобщенная схема системы контроля и управления.

Многие проекты современных автоматизированных систем управления (АСУТП) технологическими процессами позволяют выделить обобщенную схему их реализации, представленную на рисунке 4.1

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

Нижний уровень - уровень объекта - включает различные датчики для сбора информации о ходе технологического процесса, электроприводы и исполнительные механизмы для реализации регулирующих и управляющих воздействий. Датчики поставляют информацию локальным программируемым логическим контроллерам (PLC - Programming Logical Controller), которые могут выполнять следующие функции:

сбор и обработка информации о параметрах технологического процесса;

управление электроприводами и другими исполнительными механизмами;

решение задач автоматического логического управления и др.

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

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

Информация с локальных контроллеров может направляться в сеть диспетчерского пункта непосредственно, а также через контроллеры верхнего уровня (рисунок 4.1). В зависимости от поставленной задачи контроллеры верхнего уровня (концентраторы, интеллектуальные или коммуникационные контроллеры) реализуют различные функции. Некоторые из них перечислены ниже:

сбор данных с локальных контроллеров;

обработка данных, включая масштабирование;

поддержание единого времени в системе;

синхронизация работы подсистем;

организация архивов по выбранным параметрам;

обмен информацией между локальными контроллерами и верхним уровнем;

работа в автономном режиме при нарушениях связи с верхним уровнем;

резервирование каналов передачи данных и др.

Верхний уровень - диспетчерский пункт (ДП) - включает, прежде всего, одну или несколько станций управления, представляющих собой автоматизированное рабочее место (АРМ) диспетчера/оператора. Здесь же может быть размещен сервер базы данных, рабочие места (компьютеры) для специалистов и т. д. Часто в качестве рабочих станций используются ПЭВМ типа IBM PC различных конфигураций.

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

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

автоматизированная разработка, дающая возможность создания ПО системы автоматизации без реального программирования;

средства исполнения прикладных программ;

сбор первичной информации от устройств нижнего уровня;

обработка первичной информации;

регистрация аварийных событий и исторических данных;

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

визуализация информации в виде мнемосхем, графиков и т.п.;

возможность работы прикладной системы с наборами параметров, рассматриваемых как "единое целое" ("recipe" или "установки").

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

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

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

4.2.2 Прикладное программное обеспечение.

При разработке специализированного прикладного программного обеспечения (ППО) для создания системы контроля и управления, выбирается один из следующих путей:

программирование с использованием "традиционных" средств (традиционные языки программирования, стандартные средства отладки и пр.);

использование существующих, готовых - COTS (Commercial Of The Shelf) - инструментальных проблемно-ориентированных средств.

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

Программные продукты класса SCADA широко представлены на мировом рынке. Это несколько десятков SCADA - систем, многие из которых нашли свое применение и в России.

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

Среди критериев оценки SCADA - систем по которым осуществлялся выбор, можно выделить следующие:

технические характеристики;

открытость;

стоимостные характеристики;

эксплуатационные характеристики.

Анализ представленных на Российском рынке программных продуктов класса SCADA показал, что наибольший интерес представляет специализированное прикладное программное обеспечение для создания систем контроля и управления LookOut (National Instruments).

LookOut - это высокоэффективное программное обеспечение для промышленной автоматизации на базе PC и Windows NT/95/3.1. LookOut обеспечивает графическое представление процессов и интерфейс оператора (HMI) и выступает в качестве системы АСУТП (SCADA).

LookOut представляет собой масштабируемую, объектно-ориентированную архитектуру для промышленных приложений, имеющую следующие достоинства:

создание объектов и связей без программирования и компиляции;

оn-line конфигурация - создание, модификация и удаление объектов осуществляется интерактивно, без перерыва в процессе управления или мониторинга.

Система LookOut является открытой, что допускает организацию различных механизмов обмена, используя OLE Automation, OPC, ODBC, DDE. Поддерживается встраивание ActiveX-объектов. Для нее определены и описаны используемые форматы данных и процедурный интерфейс, что позволяет подключить к ней "внешние", независимо разработанные компоненты. Фактически открытость системы означает доступность спецификаций системных (в смысле SCADA) вызовов, реализующих тот или иной системный сервис. Это может быть и доступ к графическим функциям, функциям работы с базами данных и т.д.

Открытая архитектура LookOut предлагает пользователю и проектировщику ряд новых возможностей: интеграция SCADA-системы с управленческими системами, системами управления ресурсами предприятия и производством продукции.

LookOut предоставляет большой набор драйверов под большинство широко известных программируемых логических контроллеров, распределенных систем сбора, измерительных станций и другой аппаратуры ведущих компаний, а так же имеет хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Драйверы разрабатываются с использованием стандартных языков программирования. Кроме того, LookOut поддерживает технологии OPC, DDE, ActiveX, обеспечивает сетевые решения TCP/IP и UDP и содержит SQL сервер баз данных.

Поскольку система LookOut выполнена по объектной технологии управления событиями (так называемое событийное управление (event-driven) - объекты работают только в случае возникновения соответствующего события), она широко используется в сложных комплексных системах, требующих высокой производительности и содержащих большое количество контролируемых узлов.

LookOut обладает уникальной производительностью и позволяет:

увеличить количество точек ввода/вывода;

повысить скорость опроса;

улучшить анимационные возможности.

4.3 Краткое описание работы программы Lookout

4.3.1 Состояние тревоги и события.

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

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

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

Наряду с состоянием тревоги в LookOut существует понятие событий. События представляют собой обычные сообщения о состоянии системы и не требуют реакции оператора. Обычно событие генерируется при возникновении в системе определенных условий (типа регистрации оператора в системе).

В LookOut функционирование подсистемы состояний тревоги реализуется с помощью компонента Alarm. При его создании (рисунок 4.2) задается условие генерирования события, приводящее к состоянию тревоги.

Рисунок 4.2 - Диалоговое окно создания объекта Alarm.

Так же указывается некоторая величина, называемая приоритетом события. Этот приоритет характеризует важность данного события и принимает значения от 1 до 10 (наиболее серьезные события имеют приоритет 10). Определив приоритет для каждого события, можно достаточно легко отфильтровать критические события от некритических.

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

LookOut поддерживает возможность отображения и регистрации информации как об состояниях тревоги, так и о системных событиях. Для отображения информации об аварийных ситуациях или событиях в LookOut предусмотрено окно аварийных ситуациях - Alarm Window (рисунок 4.3).

Рисунок 4.3 - Окно вывода событий и аварийных ситуаций.

В дополнение к выводу информации об аварийных ситуациях на экран дисплея и в регистрационный файл на диск возможен вывод ее и на печать. Содержание выводимой информации определяется пользователем на закладке Alarm ->Print (рисунок 4.4).

Рисунок 4.4 - Окно настройки параметров печати событий

4.3.2 Аппаратная реализация связи с устройствами ввода/вывода

Для организации взаимодействия с контроллерами используются COM - порты. Контроллер или объединенные сетью контроллеры подключаются по протоколам RS-232, RS-422, RS-485.

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

Кроме того, существует возможность разработки собственного обменного протокола связи с устройствами первого уровня. Для этого в LookOut существует компонент Ascii (рисунок 4.5).

Рисунок 4.5 - Окно выбора компонентов

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



Рисунок 4.6 - Окно свойств компонента Ascii

Для отображения хода технологического процесса и оперативного управления в LookOut имеются средства визуализации, включающие в себя библиотеку визуальных компонентов (различные индикаторы, кнопки, переключатели и т.д., которыми можно управлять через их свойства, методы и события), библиотеку и редактор графических элементов, шаблонов (template) (рисунок 4.7), компоненты ActiveX и средства анимации объектов.

Рисунок 4.7 Окно выбора графического объекта

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



Рисунок 4.8 -Пример LookOut-приложения, реализующего управление технологическим процессом

4.3.3 Поддерживаемые коммуникационные протоколы

Спектр поддерживаемых протоколов LookOut для обеспечения связи с технологическим уровнем включает широко распространенные промышленные протоколы. Их использование позволяет организовать взаимодействие с контроллерами, устройствами, объединенными промышленными и обычными сетями. Предлагаемая схема решения позволяет конечному пользователю, системному интегратору единообразным способом организовать взаимодействие между программным обеспечением (ПО) верхнего уровня и платами, специфическими для каждого типа промышленных сетей.

DDE (Dynamic Data Exchange - динамический обмен данными) представляет собой коммуникационный протокол, разработанный компанией Microsoft для обмена данными между различными Windows - приложениями. Этот протокол реализует взаимосвязи типа клиент - сервер между двумя одновременно исполняющимися программами.

С целью расширения возможностей стандартного протокола DDE на локальную сеть используется протокол NetDDE. Он позволяет приложениям, запущенным на объединенных в локальную сеть компьютерах, вести DDE - обмен. NetDDE допускает обмен информацией между приложениями на IBM PC и приложениями на машинах другого типа с операционной системой VMS или UNIX. Поддержка обмена данными между приложениями происходит независимо от того, исполняются ли эти приложения на одном узле сети или на разных.

Приложения LookOut могут взаимодействовать не только между собой, но и с другими Windows - приложениями. Одним из примеров такого приложения является Microsoft Excel. LookOut - приложение может считывать и записывать какие - либо значения в любую клетку открытой в Excel электронной таблицы. Аналогично и программа Excel может читать и записывать информацию в базу данных LookOut - приложения. Данный механизм обеспечивает одновременное обновление данных в одном приложении при изменении их значений в другом.

В LookOut поддерживается обмен по OPC-протоколу. OPC (Object Linking and Embedding for Process Control). Это новый открытый промышленный стандарт для организации программный связи с программируемыми и сетевыми контроллерами в режиме Plug and Play . Компания National Instruments предлагает инструментальные средства для разработки OPC-компонентов (Toolkits) под Windows 95/98 и NT, которые позволяют реализовать как интерфейс OLE Automation для приложений Visual Basic, так и интерфейс COM Custom для приложений, разрабатываемых на С/C++.

При помощи LookOut возможно создание систем и на сетях Internet/Intranet. Компоненты, позволяющие организовать передачу информации через Internet, реализованы в архитектуре Client/Server. Web Server поставляет графическую информацию о технологическом процессе. Web-клиенты, реализованные в виде стандартных Internet-просмотрщиков позволяют просматривать информацию о технологическом процессе в реальном времени (рисунок 4.9).

Рисунок 4.9 - Наблюдение за процессом в режиме реального времени по сети Internet

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

5.1 Обобщенная структурная схема системы управления

Разрабатываемая в рамках данного дипломного проекта распределенная микропроцессорная система (МПС) предназначена для решения задачи оперативного контроля состояния технологического процесса аэрации (схема приведена на плакате 2004.Д02.207.00.00Э1 и рисунке 5.1)

Разрабатываемая система построена по трехуровневой децентрализованной системе. Она строится на базе малоканальных систем измерения расхода воздуха и системы управления его подаче, со встроенным индикатором и клавиатурой, устанавливаемых непосредственно на контролируемых объектах и через среду связи подключаются к главной ЭВМ предприятия. Такая МПС обеспечивает в реальном масштабе времени доступ к информации о состоянии технологического процесса всем заинтересованным лицам. Децентрализованная МПС дает возможность персоналу оперативно и эффективно решать на местах задачи управления.

Как выше было сказано, МПСК строится по трехуровневой схеме:

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

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

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

5.2 Описание структурной схемы микропроцессорного модуля управления процессом аэрации

Модуль ММУПА самостоятельно реализует алгоритмы сбора и обработки информации на объекте. Такая относительная независимость от диспетчерской ЭВМ достигнута установлением на эти модули программируемых однокристальных микроконтроллеров (ОМК) с широкими периферийными возможностями и обладающие высоким быстродействием. От диспетчерской ЭВМ этот контроллер получает только инициализирующую информацию в начале работы всей системы, а также переинициализирующую информацию, когда это необходимо для изменения режима контроля отдельным или несколькими объектами. По сравнению со скоростью функционирования этих модулей, такая переинициализация происходит очень редко, поэтому модули подавляющее большинство времени работает автономно. Такое разделение задач между отдельными модулями обеспечивает параллельное выполнение всех операций сбора и обработки данных, что значительно увеличивает скорость функционирования системы в целом, а также высвобождает ресурсы диспетчерской ЭВМ.

Задача оператора диспетчерской ЭВМ сводится к слежению за предоставляемой ему информации.

В состав ММУПА входит ОМК, энергонезависимое запоминающее устройство (ОЗУ), коммутатор напряжений, нормирующий усилитель (НУ), фильтр низкой частоты (ФНЧ), аналого-цифровой преобразователь (АЦП), гальваническая развязка, блок клавиатуры, блок индикации, модуль связи построенный на CAN-контроллере и CAN-приемопередатчике.

На контролируемом объекте, которым является воздухопровод, установлены первичные измерительные преобразователи (ПИП). Все контролируемые объекты имеют по три ПИП давления и одному ПИП температуры. Они вырабатывают ток, пропорционально измеряемой величине. Токи с выхода каждого ПИП поступают на входы ММУПА, где входные нагрузочные сопротивления ММУПА создают соответствующие падения напряжений. Напряжения с нагрузочных сопротивлений поступают на коммутатор напряжения, где осуществляется выбор того ПИП, который определен алгоритмом опроса. На выходе нагрузочных резисторов напряжение недостаточно для нормальной работы АЦП, поэтому перед АЦП установлен НУ, который усиливает напряжение до заданного уровня.

В задачу АЦП входит преобразование поступившего непрерывного аналогового сигнала в эквивалентный цифровой код, который будет обработан ОМК.

ФНЧ подавляет наводимые помехи в линии связи между ПИП и ММУПА, что уменьшает погрешность измерения.

Гальваническая развязка обеспечивает защиту ММУПА от внешних помех, которые не способен подавить ФНЧ, и перенапряжений возникающих в линии связи.

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

После обработки информация об измеряемых входных сигналов записываются в (ОЗУ).

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

Модуль связи обеспечивает передачу данных по CAN-шине от ММУПА к концентратору.

В состав концентратора входит высокопроизводительный ОМК, энергонезависимая ОЗУ большого объема, два модуля связи.

ОМК выполняет опрос всех ММУПА, накопление полученных данных в ОЗУ и передачу их диспетчерской ЭВМ.

5.3 Описание структурной схемы микропроцессорного модуля управления двигателями воздуходувок

Сточные воды поступают из первичных отстойников по водопроводу в аротенки. Аэротенки состоят из трех коридоров, в теле каждого установлены измерительные преобразователи растворенного кислорода О2, еН, NO3, NH4. По показаниям этих ИП оператор принимает решение о увеличении или уменьшении подачи воздуха.

Посредством измерительных преобразователей производится контроль состояния процесса.

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

Управление частотными преобразователями осуществляется посредством интерфейса RS-232. В силу относительно высокой территориальной распределенности МПС, интерфейс RS-232 не подходит для передачи данных от ЭВМ диспетчера к объекту управления. В этой связи разработан микропроцессорный модуль управления работой частотными преобразователями. Структурная схема модуля показана на плакате 2004.Д02.207.01.00 Э1 и рисунке 5.3

В состав ММУДВ входит ОМК, энергонезависимое запоминающее устройство (ОЗУ), коммутатор напряжений, контроллер RS-232, блок клавиатуры, блок индикации, модуль связи построенный на CAN-контроллере и CAN-приемопередатчике.

Контролируемый объект, которым является частотный преобразователь, управляется посредством интерфейса RS-232. ММУДВ общается с диспетчерской ЭВМ посредством CAN-сети. ММУДВ преобразует сигналы CAN-сети в уровни напряжения стандарта RS-232.

ОМК предназначен для обработки информации о состоянии частотного преобразователя и управляет его работой в соответствии с заданным алгоритмом. Кроме того, ОМК управляет работой блоком клавиатуры, блоком индикации, модулем связи и выбором измеряемого сигнала.

После обработки информация об измеряемых входных сигналов записываются в (ОЗУ).

Блок клавиатуры и индикации предназначен для постоянного отображения текущего состояния одного из частотных преобразователей. Модуль связи обеспечивает передачу данных по CAN-шине от ММУДВ к концентратору.

В состав концентратора входит высокопроизводительный ОМК, энергонезависимая ОЗУ большого объема, два модуля связи.

ОМК выполняет опрос всех частотных преобразователей, накопление полученных данных в ОЗУ и передачу их диспетчерской ЭВМ.

5.4 Техническое задание на проектирование МПС

5.4.1 Общее положение

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

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

непрерывный диспетчерский контроль технических процессов подачи воздуха;

предоставление технологической информации в реальном масштабе времени;

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

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

Необходимо обеспечить надежную работу системы в интервале температур от минус 10 до плюс 40 С.

5.4.2 Состав системы

Система контроля должна состоять из трех уровней:

верхний уровень должен быть представлен диспетчерской ЭВМ (IBM АТ-совместимый компьютер);

средний уровень должен быть построен на высокопроизводительном ОМК с внешним энергонезависимым ОЗУ большого объема, а также иметь средства связи с ММУПА и диспетчерской ЭВМ;

нижним уровнем системы является устройства сбора, обработки и передачи данных представленные ММУПА МПСК расположенные в контролируемых точках, а также микропроцессорный модуль сопряжения CAN-сети с интерфейсом RS-323. Основным элементом в составе каждого модуля должен являться однокристальный микроконтроллер, оснащенный модулем связи с концентратором;

Диспетчерская ЭВМ должна связываться с концентратор посредством интерфейса RS-485, по инициативе диспетчерской ЭВМ, а концентратор с ММУПА и ММУДВ по CAN-шине.

5.4.3 Требования к диспетчерской ЭВМ

Диспетчерская ЭВМ должна представлять собой IBM AT-совместимый компьютер, который необходимо сконфигурировать таким образом, чтобы его аппаратных мощностей хватало для бесперебойной реализации возложенных на него функций с соответствующим быстродействием (в режиме реального времени). Поэтому аппаратные средства, входящие в состав диспетчерской ЭВМ, должны соответствовать или быть мощнее выше перечисленных:

ЭВМ должна быть построена на базе процессора Intel Pentium с тактовой частотой 100..200 МГц;

оперативная память SDRAM объемом не менее 32 Мбайт;

накопитель на жестком магнитном диске (HDD) объемом 10 Гбайт или выше для хранения сводок технологической информации от территориально разнесенных объектов;

привод накопителей на гибких магнитных дисках (FDD) 3,5”;

монитор с диагональю кинескопа не менее 17” со стандартом ТСО-99;

принтер струйный или лазерный, использующий бумагу формата А4 для вывода на печать при необходимости информации, полученной с территориально разнесенных объектов и других объектов.

Диспетчерская ЭВМ должна иметь операционную систему Microsoft Windows 95..2000. программное обеспечение, готовое (предлагаемое на рынке ПО) и специально разработанное для данной системы управления, должно работать в среде используемой операционной системы. Диспетчерская ЭВМ должна обеспечивать выполнение следующих функций:

связь с удаленным концентратором через интерфейс RS-485;

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

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

при получении в автономном режиме неудовлетворительной информации привлекать внимание диспетчера.

Высокого быстродействия от диспетчерской ЭВМ не требуется, так как в технологических процессах она не участвует, а скорость выполнения ее основной функции (сбор технологической информации от территориально разнесенных объектов) ограничивается лишь скоростью передачи данных через интерфейс RS-485.

5.4.4Требования к концентратору

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

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

интерфейс обмена с диспетчерской ЭВМ - RS-485;

CAN-шина для обмена данными с ММУПА и ММУДВ, скорость передачи 1 Мбод;

количество подключаемых ММУПА должно быть не меньше 8;

режим обмена данными по шине без - задержек;

энергонезависимую память объёмом не менее 16 Мбайт;

высокопроизводительный 16-разрядный ОМК;

модуль должен быть интеллектуальным - иметь внутрению реализацию алгоритмов ввода/вывода.

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

циклический опрос ММУПА;

работа в реальном масштабе времени;

накопление полученной технологической информации от ММУПА;

передачу накопленной технологической информации диспетчерской ЭВМ по запросу.

5.4.5 Требования к микропроцессорному модулю измерения расхода воздуха

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

К аппаратным средствам модуля предъявляются следующие требования:

измеряемые входные сигналы от датчиков:

вид - аналоговый (0…+5) мА;

количество сигналов - 8;

относительная погрешность преобразования не должна превышать 0,025%;

8-разрядный ОМК с тактовой частотой 8МГц;

вывод обработанной информации на жидкокристаллический индикатор имеющий 2 строки и 16 столбцов;

интерфейс обмена внутри модуля SPI;

энергонезависимая память объемом не менее 64 К;

клавиатуру, количество клавиш - 20;

напряжение питания цифровой части плюс 5В±10%;

напряжение питания аналоговой части плюс15В.

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

циклический опрос ПИП;

расчет расхода газа по заданному алгоритму в соответствии с «Правилами измерения расходов газов и жидкостей стандартными сужающими устройствами РД50-213-80 »;

работа в реальном масштабе времени;

обработку вводимых с клавиатуры команд.

По устойчивости к климатическим и механическим воздействиям в рабочих условиях применения ММУПА соответствует группе 4 по ГОСТ 22261-82:

температура окружающего воздуха от минус 10 до плюс 40 °С;

относительная влажность воздуха 90% (при 30°С);

атмосферное давление 84-106 кПа (630-800 мм.рт.ст.).

5.4.6 Требования к микропроцессорному модулю управления двигателями воздуходувок

Требуется разработать устройство, преобразующее сигнал интерфейса CAN в сигнал RS-232 хранением данных полученных по RS232 в энергонезависимой памяти в течении часа.

К аппаратным средствам модуля предъявляются следующие требования:

8-разрядный ОМК с тактовой частотой 8МГц;

вывод обработанной информации на жидкокристаллический индикатор имеющий 2 строки и 16 столбцов;

интерфейс обмена внутри модуля SPI;

энергонезависимая память объемом не менее 64 К;

клавиатуру, количество клавиш - 20;

напряжение питания цифровой части плюс 5В±10%.

По устойчивости к климатическим и механическим воздействиям в рабочих условиях применения ММУДВ соответствует группе 4 по ГОСТ 22261-82: температура окружающего воздуха от минус 10 до плюс 40 °С;

относительная влажность воздуха 90% (при 30°С);

атмосферное давление 84-106 кПа (630-800 мм.рт.ст.).

6. Разработка функциональной схемы ММУПА и ММУДВ

6.1 Разработка функциональной схемы ММУПА

6.1.1 Описание функциональной схемы ММУПА

Функциональная схема модуля представлена на чертеже 2004.Д02.188.01.00 Э2, а также на рисунке 6.2.

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

Кроме основной своей функции ММУПА должен обеспечивать:

вывод обработанной информации на индикатор;

отображение требуемых данных по требованию оператора;

хранение измеренных данных;

связь с концентратором.

Схема контролируемого объекта представлена на рисунке 6.1.

Рисунок 6.1 - Схема контролируемого объекта.

Как видно из рисунка 6.1, воздух двигаясь по трубопроводу проходит по ПИП1(Р), где происходит измерение абсолютного давления газа. Перед и после сужающего устройства установлены ПИП2(Р) и ПИП3(Р) соответственно, которые измеряют падение давления на сужающем устройстве, т.е.

, (6.1)

где, Р3 - давление на ПИП3(Р);

Р2 - давление на ПИП2(Р);

Р - разность давления между ПИП3(Р) и ПИП2(Р).

Последним измеряющим преобразователем на пути газа, является ПИП(Т) позволяющий измерить абсолютную температуру газа. Все показанные ПИПы и сужающее устройство расположены в соответствии со стандартом «Правилами измерения расходов газов и жидкостей стандартными сужающими устройствами РД50-213-80 ».

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

а) модуль памяти;

б) блок индикации, включающий:

контроллер ЖКИ;

матрица индикаторов;

в) блок клавиатуры;

г) НУ - нормирующий усилитель;

д) ГТИ - генератор тактовых импульсов;

е) БГР - блок гальванической развязки;

ж) ФНЧ - фильтр низкой частоты;

з) модуль связи, состоящий из:

CAN-контроллера;

CAN-приемопередатчика:

и) ОМК - однокристальный микроконтроллер;

к) АЦП - аналогово-цифровой преобразователь;

л) НР - нормирующие резисторы;

м) КН - коммутатор напряжения.

Входные сигналы IN1..IN16 с первично измерительных преобразователей (ПИП) поступают на входные нагрузочные резисторы, где преобразуются из унифицированного токового сигнала в пропорциональное напряжение. Так как АЦП имеет один вход, то необходимо последовательное считывание поступающих сигналов. Для выбора входных сигналов используются два коммутатора, по той причине, что сигнал является дифференциальным. К ним по шине адреса (К3..К1) от микроконтроллера поступает адрес выбираемого в данный момент входного сигнала.

Для подавления внешних помех возникающих в линии связи между ПИП и модулем измерения расхода газа, а также усиления поступающего входного сигнала до уровня нормальной работы АЦП используется нормирующий усилитель и фильтр низкой частоты (ФНЧ).

...