Введениевскадасистемы
 Скачать 3.5 Mb.
|
|
- Appearance (General) Опция - Text Закладка - Input (Touch) Поле - Command СТАРТ ? Digital 1?=1 СТОП ? Digital 1?=0 АВТО ? Digital 2?=1 РУЧ ? Digital 2?=0 ВЫХОД WinFree( ); В режиме исполнения нажатие кнопки джина PUMP1 активизирует команду AssPopUp("SGenie", "%PUMP%", "%STATUS%"). При этом произойдет подстановка первой переменной PUMP в заменяемое имя ?digital 1?, а второй переменной STATUS - в заменяемое имя ?digital 2? суперджина, что вызовет появление выпадающей страницы с пультом управления насосом PUMP1 (рис.1.2.10в). После выполнения действий по управлению насосом выпадающая страница может быть закрыта щелчком по кнопке ВЫХОД (функция WinFree( ) закрывает страницу). В результате применения суперджинов выигрывает оператор, который взаимодействует с управляемым процессом через интерфейс, имея всю необходимую информацию и средства управления. 1.3. Сравнениеграфическихсредств Безусловно, графический интерфейс рассматриваемых систем достаточно многообразен. Но следует отметить, что подход к инструментарию различен. • CiT - компания имеет большой опыт в разработке проектов. Взгляд CiT- это взгляд разработчика, который из опыта "ощущает", какие готовые решения следует предложить для ускорения и упрощения разработки мнемосхем технологического процесса. • Wonderware - компания с большим опытом разработки инструментальных прикладных систем. Многим знакомый Windows - подобный интерфейс (по предлагаемым панелям, по способу создания окон) позволяет интуитивно использовать навыки работы в Windows. Библиотеки сложных графических объектов позволяют пользователю решать как вопросы дизайна (не все же художники !), так и сокращения времени разработки. • Библиотеки Wizards в InTouch включают тысячи мастер-объектов. Воспользоваться Wizard - объектом просто хотя бы потому, что любое неправильное действие по его конфигурированию проверяется при закрытии каждого диалога. Если какое - то поле заполнено неправильно, то об этом предлагается информация с целью модификации неправильных параметров. • Citect предлагает библиотеки символов, джинов и суперджинов. Использование всего арсенала названных средств предполагает: o концептуальное понимание; o заполнение диалоговых панелей свойств с целью анимирования сопровождается диагностикой лишь серьезных ошибок, а весь список ошибок появляется лишь на этапе компиляции проекта. • Наконец, InTouch ориентирован на более широкий круг разработчиков операторских интерфейсов, так как он не предъявляет высоких требований к пользователю с точки зрения программирования. С этой работой после небольшой подготовки справится специалист-технолог или инженер по автоматизации технологических процессов. • Citect предлагает более гибкий инструментарий, оставляя возможность пользоваться простыми средствами. Но соблазн велик! Для более полного использования возможностей Citect желательна более квалифицированная подготовка разработчиков приложений ГЛАВА 2. ОРГАНИЗАЦИЯВЗАИМОДЕЙСТВИЯСКОНТРОЛЛЕРАМИ Современные SCADA - системы не ограничивают выбора аппаратуры нижнего уровня (контроллеров), так как предоставляют большой набор драйверов или серверов ввода/вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Для подсоединения драйверов ввода/вывода к SCADA - системе в настоящее время используются следующие механизмы: • ставший стандартом de facto динамический обмен данными (DDE); • собственные протоколы фирм-производителей SCADA - систем, реально обеспечивающие самый скоростной обмен данными; • новый OPC - протокол, который, с одной стороны, является стандартным и поддерживается большинством SCADA - систем, а с другой стороны, лишен недостатков протоколов DDE. Изначально протокол DDE применялся в первых человеко - машинных интерфейсах в качестве механизма разделения данных между прикладными системами и устройствами типа ПЛК (программируемые логические контроллеры). Для преодоления недостатков DDE, прежде всего для повышения надежности и скорости обмена, разработчики предложили свои собственные решения (протоколы), такие как AdvancedDDE или FastDDE - протоколы, связанные с пакетированием информации при обмене с ПЛК и сетевыми контроллерами. Но такие частные решения приводят к ряду проблем: • для каждой SCADA - системы пишется свой драйвер для поставляемого на рынок оборудования; • в общем случае, два пакета не могут иметь доступ к одному драйверу в одно и то же время, поскольку каждый из них поддерживает обмен именно со своим драйвером. Основная цель OPC стандарта (OLE for Process Control) заключается в определении механизма доступа к данным с любого устройства из приложений. OPC позволяет производителям оборудования поставлять программные компоненты, которые стандартным способом обеспечат клиентов данными с ПЛК. При широком распространении OPC - стандарта появятся следующие преимущества: • OPC позволят определять на уровне объектов различные системы управления и контроля, работающие в распределенной гетерогенной среде; • OPC - устранят необходимость использования различного нестандартного оборудования и соответствующих коммуникационных программных драйверов; • у потребителя появится больший выбор при разработке приложений. С OPC - решениями интеграция в гетерогенные (неоднородные) системы становится достаточно простой. Применительно к SCADA-системам OPC серверы, расположенные на всех компьютерах системы управления производственного предприятия, стандартным способом могут поставлять данные в программу визуализации, базы данных и т. п., уничтожая, в некотором смысле, само понятие неоднородной системы. 2.1. Аппаратнаяреализациясвязисустройствамиввода/вывода Для организации взаимодействия с контроллерами могут быть использованы следующие аппаратные средства: • COM - порты. В этом случае контроллер или объединенные сетью контроллеры подключаются по протоколам RS-232, RS-422, RS-485. • Сетевые платы. Использование такой аппаратной поддержки возможно, если соответствующие контроллеры снабжены интерфейсным выходом на Ethernet. • Вставные платы. В этом случае протокол взаимодействия определяется платой и может быть уникальным. В настоящее время предлагаются реализации в стандартах ISA, PCI, CompactPCI. Прикладные протоколы, используемые для организации взаимодействия с контроллерами, оставлены за границей этой книги. 2.2. Особенностипостроениякоммуникационногопрограммногообеспечения Перед рассмотрением реализации связи с устройствами ввода/вывода в SCADA - системах InTouch и Citect читателю предлагается общий взгляд на организацию коммуникационного ПО в системах управления (рис.2.2.1). Рис. 2.2.1. Типовая архитектура системы управления. Коммуникационное программное обеспечение является многоуровневым. Количество уровней зависит от используемой операционной системы. Так, Applicom предлагает поддержку для следующих ОС: MS-DOS, UNIX SCO, HP-UX V10, OS/2, MS Windows 3.x, Windows 95/98, Windows NT4 на Intel и Alpha-платформах. Для Windows-платформ ПО включает следующие типы: • статическая библиотека, используемая с традиционными языками программирования, такими как C, C++, Pascal; • DLL (динамическая библиотека), применяемая со всеми Windows языками программирования (Visual Basic, Visual C/C++, Borland C/C++, Delphi, LabWindows CVI, LabView); • DDE-сервер (имеет 16 и 32 битные реализации); • пакетные реализации DDE протокола - FastDDE для продуктов линии Wonderware и AdvancedDDE для Rockwell линии; • SuiteLink сервер, реализующий механизм обмена по SuiteLink протоколу, используемому компонентами пакета FactorySuite (Wonderware); • OPC-сервер, поддерживающий интерфейс, определенный OPC- спецификацией. На рис.2.2.2 показаны программные интерфейсы для Windows-приложений (в том числе и SCADA-систем) и спектр широко распространенных промышленных протоколов. Использование этих протоколов позволяет организовать взаимодействие с контроллерами, устройствами, объединенными промышленными (fieldbuses) и обычными сетями. Предлагаемая схема решения позволяет конечному пользователю, системному интегратору, единообразным способом организовать взаимодействие между ПО верхнего уровня и платами, специфичными для каждого типа промышленных сетей. Рис. 2.2.2. Набор интерфейсов для SCADA - систем и спектр поддерживаемых протоколов. DDE, OPC - компоненты являются серверами по отношению к SCADA - системам. По отношению к ПО нижнего уровня (fieldbus) возможна организация Master/Slave и Client/Server. Внешние устройства способны посылать и принимать данные через плату. Когда вставная в персональный компьютер плата является Master/Client, то именно плата с поддерживаемым ПО является инициатором опроса промышленных устройств. В случае применения плат типа Slave/Server они реагируют на запросы внешних устройств. На некоторых вставных платах имеется разделяемая область памяти. Эта память доступна как приложению в ПК, так и встраиваемому ПО. На рис.2.2.3 показана обобщенная схема организации коммуникационного ПО для Windows NT. На предлагаемой схеме отражены как традиционные решения на базе стандартных Windows NT - драйверов, так и с использованием библиотек, реализованных в расширении реального времени RTX от VenturCom. Рис.2.2.3. Схема организации коммуникационного ПО для Windows NT. После рассмотрения общей схемы организации коммуникационного ПО представляется логичным остановиться на особенностях подключения к нему рассматриваемых в данной книге SCADA-приложений. 2.3. Серверыввода/выводав InTouch При функционировании InTouch - приложения в реальном времени информация обо всех его переменных хранится в базе данных. К такой информации относятся имя переменной, ее тип, минимальное и максимальное значения, уставки, способ отображения (дисплей, журнал) и т. д., а также информация о коммуникационных каналах, по которым происходит обмен данными между технологическим процессом и приложением. InTouch - приложение поддерживает взаимодействие с DDE и OPC-серверами. Именно на организации взаимодействия с ними и остановимся ниже. 2.3.1. Поддерживаемыекоммуникационныепротоколы DDE (Dynamic Data Exchange - динамический обмен данными) представляет собой коммуникационный протокол, разработанный компанией Microsoft для обмена данными между различными Windows - приложениями. Этот протокол реализует взаимосвязи типа клиент - сервер между двумя одновременно исполняющимися программами. В InTouch поддерживается также пакетированный DDE - обмен - FastDDE. Применение последнего заметно повышает эффективность и производительность обмена данными благодаря уменьшению общего количества DDE - пакетов, которыми клиент и сервер обмениваются между собой. Но принципиальные недостатки, связанные с надежностью и зависимостью от количества загруженных в текущий момент приложений Windows, остались. Необходимость в появлении более совершенного технологичного протокола созрела! Но следует отметить, что отказ от DDE-механизма происходит не мгновенно хотя бы потому, что в мире наработано большое количество DDE - серверов. С целью расширения возможностей стандартного протокола DDE на локальную сеть компания Wonderware предложила NetDDE. Он позволяет приложениям, запущенным на объединенных в локальную сеть компьютерах, вести DDE - обмен. Позднее NetDDE лицензируется компанией Microsoft и поставляется в дистрибутивном пакете Windows. Следует отметить и то, что NetDDE допускает обмен информацией между приложениями на IBM PC и приложениями на машинах другого типа с операционной системой VMS или UNIX. Компания Wonderware предлагает и инструментальные средства для разработки DDE- серверов, в том числе и для не-Windows-платформ. Протокол SuiteLink был специально разработан фирмой Wonderware для того, чтобы удовлетворить таким требованиям, как целостность данных, высокая производительность и простота диагностики. В основе протокола SuiteLink лежит протокол TCP/IP. SuiteLink не является заменой протоколам DDE, FastDDE и NetDDE. Новый протокол разработан для поддержания быстродействующих промышленных систем и обладает следующими характеристиками: • Передача данных осуществляется в формате VTQ (Value, Time, Quality - значение, время, качество), в соответствии с которым каждая пересылаемая клиенту единица информации сопровождается метками времени и качества данных. • Благодаря системному монитору операционной системы Windows NT (Performance Monitor) стал возможным расширенный анализ производительности по передаче данных, степени загрузки сервера, степени потребления ресурсов компьютера и сети, что особенно важно для проектирования и сопровождения больших распределенных промышленных сетей. • Поддержка обмена данными между приложениями происходит независимо от того, исполняются ли эти приложения на одном узле сети или на разных. Для реализации функций OPC - клиента Wonderware предлагает OPCLink - сервер, преобразующий OPC в SuitLink - протокол. В материалах, предложенных компанией Wonderware, отмечается, что большинство реализованных OPC-серверов создают для каждого подключаемого к серверу клиента новый канал связи или нить. Для текущей обработки каждого клиента сервер должен переключаться между нитями. Каждая нить использует DCOM (Distributed Component Object Model) для организации обмена данными, и DCOM также управляет переключением нитей. В итоге возможна достаточно низкая производительность в сети. Тесты, проведенные фирмой Wonderware, показали, что при обслуживании OPC- сервером 7 клиентов (при передаче 4 целых чисел в режиме обновления) сервер на 95% занимал ресурсы CPU. Это означает, что ресурсы компьютера практически целиком были заняты переключением нитей и DCOM- процедурами. Поэтому на текущем этапе параметры производительности протокола SuiteLink превосходят параметры DCOM. Поставляемый в комплекте FactorySuite (Wonderware) OPCLink Server обеспечивает прием информации с OPC- сервера и передачу ее по протоколу SuiteLink в SCADA - систему InTouch и наоборот. Именно OPCLink Server рекомендуется устанавливать на одном узле с OPC- сервером, чтобы для сетевых передач использовался SuiteLink- протокол, а не DCOM (рис.2.3.1). 2.3.1. Использование SuiteLink - протокола в SCADA - системах. Все описанные ниже особенности адресации распространяются и на OPC-серверы с одним лишь ограничением. При разработке InTouch - приложения создается канал связи с OPCLink - сервером (как с любым другим SuiteLink - сервером). Но рекомендуется использовать встроенный в InTouch OPC Browser для упрощения выбора параметров конфигурации подключаемого OPC - сервера. 2.3.2. Особенностиадресациив InTouch В InTouch вышеуказанные механизмы положены в основу обмена данными между приложениями InTouch и DDE и SuiteLink - серверами, которые, в свою очередь, связаны коммуникационными каналами с устройствами нижнего уровня (контроллерами). Так как InTouch предназначен для разработки и поддержания интерфейса сбора данных и диспетчерского управления (рис.2.3.2), среда исполнения WindowViewer при взаимодействии с контроллерным уровнем выступает, как правило, в роли приложения - клиента (узел View), запрашивающего данные у приложения - сервера (I/O Server). Рис.2.3.2. Обмен данными между InTouch - приложением и технологическим процессом. Через сервер ввода/вывода InTouch - приложение имеет возможность читать данные из контроллера или писать данные в него. Процесс обмена информацией InTouch - приложения с контроллером можно представить следующей схемой (рис. 2.3.3). Рис. 2.3.3. Схема обмена информацией InTouch - приложения с ПЛК. Здесь и встает один из главных вопросов организации обмена с серверами ввода/вывода: каким образом обеспечить клиенту доступ к запрашиваемой им информации? Для организации обмена с приложением определяются каналы обмена или каналы доступа, характеризующиеся следующими параметрами: • имя узла (Node Name); • имя приложения ( Application Name ); • имя группы данных или топик (Topic Name ); • имя элемента ( Item Name ). Имя приложения - это имя программы Windows, которая выполняет функции DDE, FastDDE, SuiteLink - серверов. Имя группы данных (топика) определяется при конфигурировании сервера на прием или передачу группы данных, которыми сервер будет обмениваться с контроллером или объединенными в сеть контроллерами. Определенные параметры группы (топика) зависят от конкретного сервера (поэтому рекомендуется изучать документацию и справочную систему выбранного сервера). Например, при использовании Modbus - сервера, позволяющего обеспечить взаимодействие с контроллером Modicon Micro 984 PLC, в качестве имени приложения (Application Name) должен быть Modbus, в качестве имени группы или топика (Topic Name) вводится любое имя (текстовая строка), но среди необходимых параметров группы из списка выбирается имя контроллера Modicon 984 PLC. А в качестве имени элемента (Item Name) следует выбирать название конкретного регистра контроллера (например, 40001 для контроллера Modicon Micro 984). Чтобы узнать правильный синтаксис имени элемента, необходимый для конкретных PLC, нужно обратиться к руководству по соответствующему серверу. Определены все компоненты коммуникационного канала. С учетом введенных понятий схема обмена информацией для рассмотренного выше примера будет выглядеть следующим образом (рис.2.3.4). Рис. 2.3.4. Обмен информацией на примере Modbus - сервера. Фирма Wonderware предлагает DDE и SuiteLink - серверы, которые поддерживают более 800 типов контроллеров основных производителей и различные протоколы. Если нужного драйвера все-таки нет, можно воспользоваться пакетом разработки драйверов FactorySuite Toolkit. Схемы, приведенные на рис. 2.3.3, 2.3.4, интерпретируют стандартный обмен информацией между узлом (приложением) View и контроллером (ПЛК) в режиме сбора данных и управления. В этом режиме, как уже было сказано выше, приложение View - клиент по определению. |