СУХТП лекции. Курс лекций Разработчик Афонин Ю. Д. Екатеринбург, 2007 2 Содержание
 Скачать 2.79 Mb.
|
|
Редактор Задач. Редактор задач GENIE представляет из себя пиктограмно - основанную среду проектирования, которая обеспечивает, с помощью инструментальных средств (Toolbox), формирование схемы из блоков устройств и дисплеев, благодаря которым разрабатывается, управляется, и просматривается процесс. При использовании мыши и клавиатуры пиктограммы блоков соединяются вместе и используются для работы с аппаратными средствами I/O через драйвера Advantech DLL, что в конечном итоге позволяет управлять и контролировать ваш процесс. Пиктограммы Дисплея соединены со схемой задач для отображения и управления событиями во время их исполнения программой GENIE Runtime. 115 Типичная процедура для разработки задач состоит из следующих шагов: С помощью мыши выбрать и расположить в рабочей области необходимые пиктограммы инструментальных средств Редактора Задач (рис. 6.2, 6.3). Рисунок 6.2 – Подключение входного канала к блоку аналогового ввода. 2. Для конфигурирования параметров блоков произвести двойное нажатие на каждую пиктограмму и в связанном диалоговом окне произвести настройку. 3. Для установки элементов дисплея запустите Редактор дисплея. Редактор Дисплея используется для разработки панелей операционного дисплея (Operator Display Panel) т.е. установления динамических связей между задачей и процессом отображением данных. Используя растровый фон, Вы можете создать панель, подобную дисплеям промышленных процессов. Из элементов инструментальных средств дисплея Вы создадите любой операционный дисплей. 116 Типичная процедура разработки Операционного дисплея в Редакторе Дисплея состоит из следующих шагов: Рисунок 6.3 – Конфигурирование блока аналогового ввода Типичная процедура разработки Операционного дисплея в Редакторе Дисплея состоит из следующих шагов: 1. Вызовите Редактор Дисплея (рис.6.4). 2. Из комплекта инструментальных средств возьмите мышью нужные элементы и переместите их в желательное место рабочей области. 3. Измените размер элемента, используя один из окаймляющих черных квадратов. 4. Сконфигурируйте каждый элемент, вызывая диалоговое окно двойным нажатием на его поверхность. Для динамического отображения (или управления. если оно предусмотрено) Вы можете выбирать любой блок Редактора Задач. 117 5. Добавьте на панелях дисплея текстовые поля и строки для логической связи информации дисплея. 6. Добавьте на дисплей фоновое изображение (если необходимо). 7. Сохраните Дисплей. Рисунок 6.4 – Редактор дисплея и конфигурирование стрелочного индикатора. 6.3 Технология OPC OPC (OLE for Process Control) – промышленный стандарт, созданный консорциумом всемирно известных производителей оборудования и программного обеспечения при участии Microsoft. Этот стандарт описывает интерфейс обмена данными между устройствами управления технологическими процессами. Главной целью было предоставить разработчикам систем диспетчеризации некоторую независимость от конкретного типа контроллеров. OPC основывается на технологии OLE/COM/DCOM компании Microsoft, Inc. Рассмотрим основные причины создания OPC. Довольно много 118 программ-клиентов может получать данные из различных источников и делать их доступными для драйверов независимых разработчиков. Но при этом возникают следующие проблемы: ▪ Каждая программа диспетчеризации должна иметь драйвер для конкретного устройства АСУ (Рис. 6.5а). ▪ Возникают конфликты между драйверами различных разработчиков, что приводит к тому, что какие-то режимы или параметры работы оборудования не поддерживаются всеми разработчиками ПО. ▪ Модификации оборудования могут привести к потере функциональности драйвера. ▪ Конфликты при обращении к устройству – различные программы диспетчеризации не могут получить доступ к одному устройству одновременно из-за использования различных драйверов. Рисунок 6.5a - Пример схемы работы "множества различных драйверов" Производители оборудования стараются решить эту проблему с помощью разработки дополнительных драйверов. Однако эти попытки встречают сильное сопротивление разработчиков систем диспетчеризации, которые должны, в этом случае, усложнять свои клиентские протоколы. OPC проводит четкую разграничительную линию между производителями оборудования и разработчиками драйверов. 119 Рисунок 6.5б - Решения на базе OPC Данная технология предоставляет механизм сбора данных из различных источников и передачу этих данных любой клиентской программе вне зависимости от типа используемого оборудования (рис. 6.5б). Это позволяет разработчикам сосредоточиться на производительности и оптимизации работы серверной части, которая отвечает за сбор данных. Преимущества технологии OPC. OPC был разработан для обеспечения доступа клиентской программы к нижнему уровню технологического процесса в наиболее удобной форме. Широкое распространение технологии OPC в промышленности имеет следующие преимущества: ▪ Независимость в применении систем диспетчеризации от используемого в конкретном проекте оборудования. ▪ Разработчики программного обеспечения не должны постоянно модифицировать свои продукты из-за модификации оборудования или выпуска новых изделий. ▪ Заказчик получает свободу выбора между поставщиками оборудования, а также имеет возможность интегрировать это оборудование в информационную систему предприятия, которая может охватывать всю систему производства, управления и логистики. 120 Разработку стандартов OPC, их описание, поддержку и пропаганду взяло на себя OPC Foundation, добровольная международная организация, расположенная в Boca Raton, Флорида, США. Сейчас организация насчитывает более 250 членов, в число которых входят компании, занимающие лидирующие позиции в разработке программ для мониторинга, визуализации и диспетчеризации, а также других приложений для управления технологическими процессами. В спецификации OPC для обмена данными определены два компонента - OPC-клиент и OPC-сервер. ОРС-сервер - программа, получающая данные во внутреннем формате устройства или системы и преобразующая эти данные в формат ОРС. ОРС- сервер является источником данных для ОРС-клиентов. ОРС-клиент - программа, принимающая от ОРС-серверов данные в формате ОРС и преобразующая их во внутренний формат устройства или системы. ОРС-клиент общается с ОРС-сервером посредством строго определенных в спецификации интерфейсов, что позволяет любому ОРС- клиенту общаться с любым ОРС-сервером. Однажды созданный OPC-сервер позволяет подключать устройство к широкому кругу программного обеспечения (SCADA системам, HMI и др.) поддерживающего спецификацию OPC. В настоящее время наибольшее распространение получили следующие спецификации: OPC Data Access 1.0 и 2.0 – самая распространенная спецификация OPC, обеспечивающая обмен текущими данными. OPC Alarms and Events – спецификация определяющая как регистрировать аварии процесса, действия оператора, информационные сообщения. 121 OPC Historical Data Access - предоставляет доступ к историческим данным. Использование этой спецификации позволяет представить архивные данные в универсальном формате, как в простых системах визуализации, так и в сложных SCADA системах. OPC основана на модели распределенных компонентных объектов Microsoft DCOM и устанавливает требования к классам объектов доступа к данным и их специализированным (custom) интерфейсам для использования разработчиками клиентских и серверных приложений. Опираясь на объектную технологию COM/DCOM, стандарт OPC фиксирует определенную модель взаимодействия между клиентом и сервером. Давайте поговорим о Data Access, наиболее популярной спецификации OPC, а также о структуре типового OPC-сервера и о том, как он связывается с OPC-клиентом. Спецификации OPC Data Access 1.0 и 2.0 являются основными и наиболее популярными спецификациями среди используемых в OPC- серверах и клиентах. Они применяются для получения следующих типов данных: • Данные, полученные от датчиков в реальном времени (температура, давление, проток и т.п.); • Управляющие воздействия (открыть, закрыть, старт, стоп и т.п.); • Информация о текущем состоянии оборудования и исполнительных программ систем и подсистем Базовым понятием этой спецификации является элемент данных (Item). Каждый элемент данных имеет значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа - булево, целое, плавающее с точкой и т.п. - или строкой (так называемый OLEVARIANT). Время представляется со 100-наносекундной точностью (FILETIME Win32 API). Реальная точность измерения времени обычно бывает хуже и, в общем случае, зависит от реализации сервера и аппаратуры. Качество - это код содержащий в себе грубую оценку - UNCERTAIN, GOOD и BAD (не 122 определено, хорошее и плохое), а на случай плохой - еще и расшифровку, например QUAL_SENSOR_FAILURE - неисправность датчика. Следующим вверх по иерархии является понятие группы элементов (OPC Group). Группа создается OPC-сервером по требованию клиента, который затем может добавлять в группу элементы (Item). Для группы клиентом задается частота обновления данных, и все данные в группе сервер старается обновлять и передавать клиенту с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Для каждого клиента всегда создается своя группа (кроме так называемых публичных групп), даже если состав элементов и частота обновления совпадают. Отсоединение клиента приводит к уничтожению группы. Элементы в группе, таким образом, - это своего рода клиентские ссылки на некие реальные переменные (тэги), находящиеся на сервере или в физическом устройстве. Понятие тэга спецификацией OPC не определяется, но подразумевается неявно. Элементы в группу клиент добавляет по имени, и эти имена являются именами соответствующих тэгов. Клиент может либо знать нужные имена заранее, либо запросить список имен тэгов у сервера. Для запроса имен тэгов служит интерфейс IOPCBrowseServerAddressSpace, с помощью которого сервер описывает клиенту свое "пространство имен", организованное в общем случае иерархически. Пример полного имени тэга: Устройство1.Модуль5.АналоговыйВход3. При добавлении элемента в группу клиент всегда указывает это полное имя. Заметим, что группы, создаваемые клиентом, не обязаны совпадать (и, как правило, не совпадают) с подразделами пространства имен сервера, элементы в группу добавляются в "разнобой". Единственное, что их объединяет - это общая частота обновления и синхронность отправки клиенту. Наконец, на верхней ступеньке иерархии понятий находится сам OPC- сервер. Из всех перечисленных (OPC-группа, OPC-элемент) он единственный 123 является COM-объектом, все остальные объекты доступны через его интерфейсы, которые он предоставляет клиенту (рис 6.6). Рисунок 6.6 - Объектная модель OPC-сервера Data Access. Установление соединения между клиентом и сервером на одном компьютере. Установочная программа автоматически производит регистрацию сервера (запись соответствующей информации в системные реестр). Программы-клиенты, как правило, имеют соответствующий пользовательский интерфейс, позволяющий выбрать из списка зарегистрированных серверов нужный (при этом, если сервер не активен, он автоматически запустится), пролистать его адресное пространство и подписаться на необходимые тэги. Таким образом, для обеспечения соединения на одной машине каких-либо специальных настроек (кроме установки сервера и клиентского программного обеспечения, например SCADA-системы) производить не нужно. Для работы в сети (клиент и сервер на разных компьютерах) необходимо присутствие в сети хотя бы одной станции с установленной Windows NT (Server или Workstation). Станция с Windows NT используется в качестве сервера авторизации и аутентификации, при этом сам OPC-сервер может располагаться как на ней, так и на другой сетевой станции. Перед установлением соединения между приложением-клиентом и удаленным сервером следует произвести настройку системных компонентов DCOM. 124 Литература 1. Беспалов А.В. Системы управления химико-технологическими процессами : учеб. для вузов / А. В. Беспалов, Н. И. Харитонов. - М. : Академкнига, 2007. 2. Бородин И.Ф., Андреев С.А. Автоматизация технологических процессов и системы автоматического управления: учебник. – М.: "КолосС", 2005. 3. Щербина Ю.В. Технические средства автоматизации и управления: Учеб. пособие /МГУП. - М.: МГУП, 2002. 4. Михаил Гук. Интерфейсы ПК. – М., 2000 г. 5. Задков В.Н., Пономарев Ю.В. Компьютер в эксперименте. Архитектура и программные средства систем автоматизации. – М.: Наука, 1988. 6. 5025А, руководство пользователя. Корпорация Octagon SYSTEMS. 7. 5710, руководство пользователя. Корпорация Octagon SYSTEMS. 8. ГОСТ 26.003-80 "Система интерфейса для измерительных устройств с байт-последовательным, бит-параллельным обменом информацией." 9. Система GENIE. Руководство пользователя. – Екатеринбург: М- АРТ, 1996 г. |