6017

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

Конспект

Коммуникация, связь, радиоэлектроника и цифровые приборы

Интегрированные системы проектирования и управления Глава 1. Выбор программных средств АСУТП 1.1. Общие положения Современная АСУТП (автоматизированная система управления технологическим процессом) представляет собой многоуровневую человеко-машинную...

Русский

2012-12-27

610.5 KB

76 чел.

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

Глава 1. Выбор программных средств АСУТП

1.1. Общие положения

Современная АСУТП (автоматизированная система управления технологическим процессом) представляет собой многоуровневую человеко-машинную систему управления. Создание АСУ сложными технологическими процессами осуществляется с использованием автоматических систем сбора данных и вычислительных комплексов. Развитие АСУТП можно разделить на три этапа:

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

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

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

Технологические процессы в энергетике, нефтегазовой и ряде других отраслей промышленности являются потенциально опасными и при возникновении аварий приводят к человеческим жертвам, а также к значительному материальному и экологическому ущербу. По статистике за тридцать лет число учтенных аварий удваивается примерно каждые десять лет. В 60-х годах ошибка человека была первоначальной причиной аварий лишь в 20% случаев, тогда как к концу 80-х доля "человеческого фактора" стала приближаться к 80 %. Одна из причин этой тенденции - низкая эффективность HMI.

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

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

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

В России диспетчерское управление ТП опиралось, на опыт диспетчерского персонала. Поэтому переход к управлению на основе SCADA-систем стал осуществляться позднее. К трудностям освоения в России SCADA-систем, относится отсутствие эксплуатационного опыта и недостаток информации о различных SCADA-системах. В мире насчитывается не один десяток компаний, активно занимающихся разработкой и внедрением SCADA-систем. Каждая SCADA-система - это "know-how" компании и поэтому данные о той или иной системе не столь обширны.

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

1.2. Архитектура АСУ ТП

Обобщенная схема АСУТП, представлена на рис. Как правило, это двух или трех уровневые системы, так как именно на этих уровнях реализуется непосредственное управление технологическими процессами.

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

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

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

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

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

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

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

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

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

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

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

г) обмен информацией между нижним и верхним уровнем;

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

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

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

Функции SCADA-систем:

1) автоматизированная разработка ПО АСУ ТП;

2) сбор и обработка и хранение информации, полученной от устройств нижнего уровня;

3) автоматическое управление технологическим процессом

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

1.3. Разработка SCADA-системы

Существует 2 пути разработки специализированного ПО для создания SCADA-системы:

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

2) Использование коммерческих инструментальных проблемно-ориентированных средств. Целесообразен для сложных распределенных систем. Позволяет минимизировать затраты труда высококлассных программистов, по возможности привлекая к разработке специалистов-технологов в области автоматизируемых процессов.

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

SCADA

Фирма-разработчик

Страна

Сimplicity

GE Fanuc Automation

США

Citect

CI Technology

Австралия

Factory Link

United States DATA Co.

США

iFIX

Intellution

США

Genesis

Iconics

США

InTouch

Wonderware

США

MasterSCADA

InSAT

Россия

TraceMode

AdAstra

Россия

WinCC

Siemens

Германия

КРУГ2000

НПО "Круг"

Россия

Выбор SCADA осуществляется на основе технических, экономических и эксплуатационных характеристик.

После выбора SCADA - системы, начинается разработка АСУ ТП для конкретного объекта, которая включает следующие этапы:

1) Разработка архитектуры системы автоматизации в целом. На этом этапе определяется функциональное назначение каждого узла системы.

2) Решение вопросов, связанных с возможной поддержкой распределенной архитектуры.

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

4) Связь прикладной системы устройствами нижнего уровня (ПЛК, датчики, исполнительные устройства и др.)

5) Отладка созданной прикладной программы в режиме эмуляции.

1.4. Характеристики SCADA-систем

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

В различных SCADA-системах этот вопрос решен по разному. Так, FactoryLink имеет широкий список поддерживаемых платформ: DOS, MS Windows, OS/2, UNIX и др. В RealFlex и Sitex основу программной платформы принципиально составляет ОСРВ QNX. Подавляющее большинство SCADA-систем реализовано на MS Windows платформах. Учитывая позиции Microsoft на рынке ОС, следует отметить, что даже разработчики многоплатформных SCADA, приоритетным считают развитие своих систем на платформе Windows NT/2000.

2) Наличие средств сетевой поддержки. Для эффективного функционирования в разнородной среде SCADA должна иметь поддержку работы в стандартных сетевых средах (ARCNet, Ethernet и т.д.) с использованием стандартных протоколов (NetBIOS, TCP/IP и др.), а также обеспечивать поддержку промышленных интерфейсов (PROFIBUS, CAN, MODBUS и т.д.).

3) Встроенные командные языки. Большинство SCADA-систем имеют встроенные VisualBasic-подобные языки высокого уровня, позволяющие генерировать адекватную реакцию на события.

4) Поддерживаемые базы данных. Одной из основных задач SCADA является обработка информации: сбор, оперативный анализ, хранение, сжатие, пересылка и т. д. Таким образом, в рамках создаваемой системы должна функционировать база данных. Практически все SCADA-системы, используют ANSI SQL синтаксис, который является независимым от типа базы данных.

5) Графические возможности. Для специалиста-разработчика системы автоматизации, также как и для специалиста - "технолога", очень важен графический пользовательский интерфейс. Функционально графические интерфейсы SCADA-систем весьма похожи. В каждой из них существует графический объектно-ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом, а также быстро обновлять изображение на экране, используя средства анимации. Крайне важен также вопрос о поддержке в рассматриваемых системах стандартных функций GUI (Graphic Users Interface). Поскольку большинство рассматриваемых SCADA-систем работают под управлением Windows, это и определяет тип используемого GUI.

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

2. Экономические характеристики

При оценке стоимости SCADA-систем нужно учитывать следующие факторы:

1) Стоимость программно-аппаратной платформы

2) Стоимость системы

3) Стоимость освоения системы

4) Стоимость сопровождения

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

1) Удобство интерфейса среды разработки, полнота инструментария и функций системы

2) Качество документации (полнота, наличие русификации)

3) Поддержка создателей (количество инсталляций, дилерская сеть, обучение, условия обновления версий и т. д.)

ГЛАВА 2. ПОСТРОЕНИЕ ГРАФИЧЕСКОГО ИНТЕРФЕЙСА

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

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

SCADA-системы, разработанные под OC Windows, как правило, имеют интерфейс API Win32, и представляют собой набор окон с различными графическими и текстовыми объектами.

2.1. Графические средства InTouch

Компоненты среды разработки InTouch:

1) WindowMaker - инструментальная среда разработки приложений;

2) Application Explorer - представление приложения в иерархическом виде с доступом к любому компоненту приложения.

Проект, созданный в пакете InTouch, представляет собой набор окон (Window) с различными графическими и текстовыми объектами.

Создание нового окна производится в WindowMaker командой File/New Window. Свойства каждого окна (наличие заголовка, цвет фона, размеры и т. д.) определяются при его создании. Каждое окно должно иметь свое имя для его идентификации (Name). InTouch предлагает три типа окон (Window Туре):

  1.  Replace (заменяющее) - закрывает все существующие окна, перекрываемые им при появлении на экране.
  2.  Overlay (перекрывающее) - появляется поверх всех отображаемых в текущий момент окон. Когда окно типа Overlay закрывается, все скрываемые им окна восстанавливаются. Щелчок мыши по любому видимому участку лежащего ниже окна приводит к переходу его на передний план.
  3.  Popup (всплывающее) - похоже на окно типа Overlay, но всегда остается поверх других открытых окон. Окно закрывается после соответствующей команды пользователя.

В поле Frame Style (стиль обрамления) выбирается необходимый стиль обрамления окна:

  1.  Single - окно с рамкой, допускается заголовок;
  2.  Double - окно с рамкой без заголовка;
  3.  None - окно без рамки и заголовка.

В группе полей Dimentions определяются текущие размеры и положение окна на рабочем поле.


Интерфейс
WindowMaker.

Инструментарий InTouch

Инструментарий InTouch представлен пятью панелями инструментов, сгруппированными по функциональному принципу.

1) General содержит элементы, соответствующие часто используемым командам меню File и Edit. Эти элементы известны по среде Windows и не требуют пояснения.

2) Format включены средства, выполняющие большую часть команд форматирования текстовых объектов меню Text.

3) Arrange содержит инструменты, соответствующие командам выравнивания объектов.

4) Drawing включает инструменты для создания простых и сложных объектов интерфейса оператора. Простые объекты: геометрические фигуры, текстовый объект и трехмерная кнопка. Сложные объекты: контейнер для вставки растровых изображений, тренд реального времени и архивный тренд. На рис. на рабочем поле окна WindowMaker показаны примеры объектов, созданных инструментами панели Drawing.

5) В панели View (Вид) представлены команды отображения/закрытия окна.

Объекты и их свойства

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

  1.  Линия - это объект, представляющий собой один или несколько связанных отрезков. Статические свойства  - толщина линии и стиль, динамические - цвет.
  2.  Заполненный контур (прямоугольник, скругленный прямоугольник, круг, эллипс, многоугольник) представляет собой двухмерный объект. Динамические свойства - цвет контурной линии, цвет заполнения, размеры, расположение.
  3.  Текст представляет собой последовательность символов. Статические свойства - тип шрифта, его размер, выделение, курсив, подчеркивание, выравнивание. Динамические свойства - цвет, видимость и расположение.
  4.  Кнопка - часто используемый объект при создании операторских интерфейсов. С кнопками могут быть связаны функции различных типов.

 

Сложные объекты.

  1.  Символ - это комбинация простых объектов, которые обрабатываются как один объект. Любое изменение статических или динамических свойств символа влияет на все составляющие символа. Например, если создать символ "насос" из двух кругов и двух прямоугольников и присвоить ему динамическое свойство Fill Color (цвет заполнения), то это свойство будет распространяться на все четыре простых объекта.
  2.  Компонент - это совокупность двух или более объектов, символов или других компонентов, образующих единый элемент. Создается путем выбора двух и более объектов и последующего запуска команды Arrange/Make Cell. Каждая составляющая компонента может иметь собственные динамические свойства. Используются для таких виртуальных устройств, как панель управления контроллером, движковый регулятор и т. д. Компонент не может менять свой размер, ему нельзя присваивать динамические и статические свойства (внутри компонента есть объекты и символы со своими свойствами). Для изменения свойств компонента его надо разобрать на составные части командой Arrange/Break Cell.
  3.  Мастер-объект - это предварительно созданный компонент с определенными статическими и динамическими свойствами. В отличие от компонента, динамические свойства мастер-объекта быстро настраиваются с помощью специализированного диалога. Другими словами, фирма Wonderware провела большую работу и создала огромное количество мастер-объектов (несколько тысяч), определив для каждого из них механизм быстрой настройки статических и динамических свойств. Все эти мастер-объекты разделены на большое количество групп и размещены в соответствующей библиотеке.


Диалог Wizard Selection (выбор мастер-объекта).

2.2. Графические средства Citect

Компоненты среды разработки Citect:

1) Citect Explorer - представление списка проектов и их стандартных папок в иерархическом виде с доступом к любому компоненту проекта;

2) Project Editor (редактор проектов) - среда создания, конфигурирования и редактирования задач, не связанных с графическими страницами проекта;

3) Graphics Builder (построитель интерфейсов) - среда создания и редактирование графического интерфейса;

4) Cicode Editor (редактор Cicode) - полнофункциональная интегрированная среда для создания и отладки программ на языке Cicode.

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

Шаблоны страниц (Template)

Ниже приведено описание некоторых шаблонов Citect, хранящихся в библиотеке:

  1.  Blank - шаблон пустой страницы;
  2.  Normal - шаблон базовой страницы для создания мнемосхем технологических процессов;
  3.  PageMenu - шаблон для создания страницы меню, которая позволяет оператору быстро переходить к другим страницам или группам страниц проекта;
  4.  BookMenu - шаблоны для создания меню в формате книг;
  5.  TabMenu - шаблоны для создания меню в формате таблиц;
  6.  Single Trend - шаблон для создания страницы с одним окном трендов, в котором имеется до 8 перьев;
  7.  Double Trend - шаблон для создания страницы с двумя окнами трендов, в каждом из которых имеется до 8 перьев;
  8.  Compare Trend - шаблон для создания страницы c двумя трендами, наложенными один на другой в целях их сравнения;
  9.  Pop Trend - шаблон для создания маленькой страницы трендов, которая будет играть роль выпадающей страницы;
  10.  Alarm - шаблон для создания страницы текущих алармов;
  11.  Summary - шаблон для создания страницы сводки алармов;
  12.  Hardware - шаблон для создания страницы аппаратных алармов.

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

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


Шаблон страницы проекта.

Доступ к диалогу для выбора типа шаблона осуществляется из Citect Explorer (Project Editor) выбором соответствующей папки (команды).


Диалог выбора шаблона (
Normal)

Готовые шаблоны страниц являются достоинством SCADA-пакета, так как они позволяют разработчику экономить значительное время. Если несколько страниц проекта созданы на базе одного и того же шаблона, легко модифицировать сразу всю эту группу страниц, производя изменения только в шаблоне. При включенной опции Linked все страницы группы изменятся автоматически. Применение в проекте типовых шаблонов позволяет унифицировать внешний вид страниц проекта, что положительно скажется на работе оператора. Щелчок по клавише Ok диалога выбора шаблонов переносит читателя в построитель интерфейсов Graphics Builder.


Страница на базе шаблона Normal с примерами объектов.

На рабочем поле окна Graphics Builder (рис.) размещен шаблон Normal с инструментарием. Слева и справа от инструментария представлены примеры объектов, созданных с помощью различных инструментов.

Инструментарий включает 14 различных инструментов и селектор (стрелка) для выбора объектов в окне.

Библиотека статических объектов (Library Objects)

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

Для ускорения работы над проектом Citect предлагает разработчику библиотеку объектов (Library Objects), которая включает более 500 готовых графических компонентов. Если нужного объекта в библиотеке нет, его можно импортировать из графических форматов: .BMP, .DXF, .PCX, .WMF и др..

На рис. представлен набор объектов раздела Емкости.


Раздел Емкости библиотеки объектов.

Genies и Super Genies (джины и суперджины)

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

Для решения данных задач, Citect предлагает два типа сложных объектов:

1) Джины (genies) – группа из нескольких связанных задачей объектов, с настроенными  свойствами. Находятся в библиотеке джинов аналогично объектам (рис. 4). Размещаются на графической странице при проектировании системы, их количество на странице не ограничено. Джин может управляться как единый объект (его можно копировать, перемещать, масштабировать и т.д.), при этом обрабатываются все составляющие джина.

2) Суперджины (super genies), которые представляют собой динамические страницы, активизируемые в режиме исполнения для ввода/вывода данных.

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

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

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


Раздел Моторы библиотеки джинов.

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

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

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

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


К описанию механизма суперджина.

Сравнение графических средств

  •   InTouch ориентирован на более широкий круг разработчиков, так как он не предъявляет высоких требований к пользователю с точки зрения программирования. С этой работой после небольшой подготовки справится специалист-технолог или инженер по автоматизации технологических процессов.
  •  Citect предлагает более гибкий инструментарий, оставляя возможность пользоваться простыми средствами. Для более полного использования возможностей Citect желательна более квалифицированная подготовка разработчиков приложений

ГЛАВА 3. ОРГАНИЗАЦИЯ СВЯЗИ С УСТРОЙСТВАМИ ВВОДА/ВЫВОДА

3.1. Аппаратная и программная реализация связи

Для организации взаимодействия компьютеров с контроллерами могут быть использованы следующие аппаратные средства:

1) COM - порты. В этом случае контроллер или объединенные сетью контроллеры подключаются по протоколам RS-232, RS-422, RS-485.

2) Сетевые платы. Использование такой аппаратной поддержки возможно, если контроллеры снабжены интерфейсным выходом на Ethernet.

3) Платы расширения. В этом случае протокол взаимодействия определяется платой и может быть уникальным. В настоящее время предлагаются реализации в стандартах ISA, PCI, CompactPCI, VME. Ввод/вывод аналоговых сигналов производится с помощью АЦП и ЦАП.

Для подсоединения драйверов ввода/вывода к SCADA - системе в настоящее время используются следующие протоколы:

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

Недостатки: ненадежность и зависимость скорости обмена от количества загруженных приложений Windows. Отказ от DDE происходит не мгновенно потому, что в мире наработано большое количество DDE - серверов.

2) Модификации DDE:

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

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

- Advanced DDE (Rockwell).

 Недостатки данных решений главным образом связанных с унификацией:

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

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

3) OPC-протокол (OLE for Process Control), представляет собой применение OLE-технологии связывания и внедрения объектов фирмы Microsoft для систем промышленной автоматизации. Обеспечивает универсальный механизм обмена данными между датчиками, исполнительными механизмами, контроллерами, устройствами связи с объектами и системами SCADA и СУБД.

Основан на модели распределенных компонентных объектов COM/DCOM. Базовым понятием этой модели является элемент данных (Item). Каждый элемент данных имеет значение, время последнего обновления (Timestamp) и признак качества, определяющий степень достоверности значения. Значение может практически любого скалярного типа (булево, целое, с плавающей точкой и т.п.) или строкой. Время представляется с точностью 100 наносекунд. Реальная точность измерения времени обычно хуже и, в общем случае, зависит от реализации сервера и аппаратуры. Качество – это код, содержащий в себе грубую оценку – UNCERTAIN, GOOD или BAD (не определено, хорошее и плохое), а на случай плохой – еще и расшифровку, например QUAL_SENSOR_FAILURE – неисправность датчика.

Следующим вверх по иерархии является понятие группы элементов (OPC Group). Группа создается ОРС-сервером по требованию клиента, который затем может добавлять в группу элементы. Для группы клиентом задается частота обновления данных, и все данные в группе сервер старается обновлять и передавать клиенту с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся частотой обновления. Для каждого клиента всегда создается своя группа (кроме так называемых публичных групп), даже если состав элементов и частоты обновления совпадают. Отсоединение клиента приводит к уничтожению группы. Элементы в группе, таким образом, - это своего рода клиентские ссылки на некие реальные переменные (теги), находящиеся на сервере или физическом устройстве. Пример полного тега: Устройство1.Модуль5.АналоговыйВход3.

На верхней ступени иерархии понятий находится ОРС-сервер. В отличие от элемента и группы он единственный является СОМ-объектом, все остальные объекты доступны через его интерфейсы, которые он предоставляет клиенту.

OPC получил широкую поддержку производителей SCADA-систем, лишен недостатков протоколов DDE и в настоящее время является стандартом де-факто обмена информацией с устройствами нижнего уровня. Производители аппаратных средств, пользуясь спецификацией OPC, имеют возможность имеют возможность разрабатывать единственный сервер ОРС для обеспечения единственного и наиболее общего способа организации доступа к данным и передачи в адрес приложений-клиентов различных производителей программного обеспечения для промышленной автоматизации.  Таким образом протокол OPC позволяет определять различные системы управления и контроля, работающие в распределенной разнородной среде на уровне объектов, устраняет необходимость использования нестандартного оборудования и драйверов,  даёт больший выбор средств при разработке приложений.

DDE и OPC - компоненты являются серверами по отношению к SCADA - системам. По отношению к ПО нижнего уровня (fieldbus) возможна организация Master/Slave и Client/Server. Когда вставная в персональный компьютер плата является Master/Client, то именно плата с поддерживаемым ПО является инициатором опроса промышленных устройств. В случае применения плат типа Slave/Server они реагируют на запросы внешних устройств.

Коммуникационное ПО является многоуровневым. Количество уровней зависит от используемой ОС. Для Windows-платформ ПО включает следующие типы:

1) статическая библиотека, используемая с традиционными языками программирования, такими как C, C++, Pascal;

2) DLL (динамическая библиотека), применяемая со всеми Windows языками программирования (Visual Basic, Visual C/C++, Borland C/C++, Delphi, LabWindows CVI, LabView);

3) DDE-сервер (имеет 16 и 32 битные реализации) и его модификации;

4) OPC-сервер, поддерживающий интерфейс, определенный OPC- спецификацией.

3.2. Средства ввода/вывода InTouch

Поддерживаемые протоколы: DDE, FastDDE, NetDDE, SuiteLink

SuiteLink разработан Wonderware для поддержания быстродействующих промышленных систем. В основе SuiteLink лежит протокол TCP/IP.

Характеристики:

а) Передача данных осуществляется в формате VTQ (Value, Time, Quality - значение, время, качество), в соответствии с которым каждая пересылаемая клиенту единица информации сопровождается метками времени и качества данных.

б) По системному монитору Windows NT (Performance Monitor) осуществляется анализ производительности по передаче данных, степени потребления ресурсов компьютера и сети, что особенно важно для проектирования и сопровождения больших распределенных промышленных сетей.

в) Поддержка обмена данными между приложениями происходит независимо от того, исполняются ли эти приложения на одном узле сети или на разных.

Для реализации функций OPC - клиента Wonderware предлагает OPCLink - сервер, преобразующий OPC в SuiteLink - протокол. Большинство OPC-серверов создают для каждого подключаемого к серверу клиента новый канал связи или нить. Для текущей обработки каждого клиента сервер должен переключаться между нитями. Каждая нить использует DCOM (Distributed Component Object Model) для организации обмена данными, и DCOM также управляет переключением нитей. В итоге возможна достаточно низкая производительность в сети.

Тесты, проведенные фирмой Wonderware, показали, что при обслуживании OPC-сервером 7 клиентов (при передаче 4 целых чисел в режиме обновления) сервер на 95% занимал ресурсы CPU. Это означает, что ресурсы компьютера практически целиком были заняты переключением нитей и DCOM- процедурами.

Поэтому на текущем этапе параметры производительности протокола SuiteLink превосходят параметры DCOM. Поставляемый в комплекте FactorySuite OPCLink Server обеспечивает прием информации с OPC- сервера и передачу ее по протоколу SuiteLink в SCADA - систему InTouch и наоборот

Wonderware предлагает DDE и SuiteLink – серверы для более чем 800 типов контроллеров основных производителей. Если нужного драйвера нет, можно воспользоваться пакетом разработки драйверов FactorySuite Toolkit.

Особенности адресации в InTouch

 

Для организации обмена с приложением определяются каналы обмена или каналы доступа, характеризующиеся следующими параметрами:

1) Имя узла (Node Name).

2) Имя приложения (Application Name) - это имя программы Windows, которая выполняет функции сервера.

3) Имя группы данных или топик (Topic Name). Имя группы данных (топика) определяется при конфигурировании сервера на прием или передачу группы данных, которыми сервер будет обмениваться с контроллером или объединенными в сеть контроллерами.

4) Имя элемента (Item Name).

 

Обмен данными с другими приложениями

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

Приложение-клиент

Приложение-сервер

Группа

Элемент

View

Excel

Sheet1.XLS

R1C1

Excel

View

Tagname

R_Level

Определение имени доступа в словаре переменных InTouch

В InTouch - приложениях вся информация о переменных приложения хранится в Tagname Dictionary (Словарь переменных). Это не что иное, как база данных реального времени - один из центральных компонентов InTouch.

В пакете InTouch используется два базовых типа переменных:

1) Внутренние переменные (Memory) могут быть использованы для создания различных системных констант, моделирования элементов системы управления и в вычисляемых переменных, доступных другим Windows - программам.

2) Переменные ввода/вывода, которые получают или передают свое значение другой Windows - программе,.

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

1) Локальные адреса используются в том случае, когда узлы исполнения имеют свои серверы В/В. На рис. узлы исполнения, каждый со своей копией одного и того же приложения, ссылаются на свои собственные источники данных ввода/вывода.


Сеть View - узлов с собственными серверами ввода/вывода.

Поэтому при определении канала доступа к информации достаточно трехуровневого адреса (Application - приложение, Topic - объект, Item - элемент). Имя узла (Node) в этом случае опускается.

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


Архитектура с двумя View - узлами и сервером ввода/вывода.

Два View - узла исполняют идентичные копии одного и того же приложения и ссылаются на один и тот же источник ввода/вывода (I/O сервер). Поэтому при определении канала доступа к информации ввода/вывода необходимо использовать четырехуровневый адрес (Node - узел, Application -приложение, Topic - объект, Item - элемент).

3.3. Средства ввода/вывода Citect

Для обмена данными с устройствами I/O в Citect могут использоваться следующие способы:

1) Создание динамических библиотек, выполняющих функцию драйверов. Citect поставляется с более чем 120 драйверами ввода/вывода. Все эти драйверы 32 - разрядные и обеспечивают подключение более 300 типов ПЛК. Если нужного драйвера нет, можно воспользоваться пакетом разработки драйверов.

2) Связь через DDE – сервер.

3) Citect может функционировать в качестве и OPC - сервера и OPC - клиента.

Установка связей с устройствами I/O

Осуществляется через утилиту - Express Communications Wizard (система установки связи). Доступ к системе установки связи осуществляется в Citect Explorer из папки Communications соответствующего проекта.


Доступ к мастеру коммуникаций из Citect Explorer.

Двойной щелчок по иконке Express I/O Device Setup запускает процесс установки и конфигурирования устройств ввода/вывода. Последовательность настройки:

1) Определение компьютера как сервера ввода/вывода и присвоение ему уникального имени.

2) Возможность разработки и отладки проекта без физического подключения к реальному устройству ввода/вывода. Просто при конфигурировании устройства ввода/вывода его можно определить как внутреннее ОЗУ (Memory I/O Device) или как файл на диске (Disk I/O Device).

3) Выбор марки контроллера, интерфейсной платы и протокола обмена информацией. Для обмена по OPC-протоколу именно в этом диалоге выбирается протокол OPC, чтобы наделить Citect-приложение функциями OPC-клиента.

4) Вводится адрес устройства. Эту информацию можно найти в документации на используемый сервер ввода-вывода.

3.4. Функциональные модули Citect

Citect ориентирован на реализацию архитектуры клиент - сервер и имеет в своем составе пять функциональных модулей (серверов или клиентов):

1) I/O - сервер ввода/вывода. Обеспечивает передачу данных между устройствами ввода/вывода и другими модулями Citect.

2) Display - клиент визуализации. Обеспечивает операторский интерфейс: отображение данных, поступающих от других модулей Citect, и управление выполнением команд оператора.

3) Alarms - сервер алармов. Cравнивает значения переменных с допустимыми пределами, проверяет выполнение заданных условий и отображает алармы на соответствующем узле визуализации.

4) Trends - сервер трендов. Собирает и регистрирует текущую информацию, позволяя отображать развитие процесса в реальном масштабе времени или в ретроспективе.

5) Reports - сервер отчетов. Генерирует отчеты по истечении определенного времени, при возникновении определенного события или по запросу оператора.

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

Сетевые возможности Citect допускают использование в локальной сети до 256 компьютеров. Каждый из них может играть роль Display Client. Но по меньшей мере один из этих компьютеров должен быть сервером (ввода/вывода, алармов, трендов, отчетов).

Архитектура клиент - сервер может быть представлена разнообразными вариантами: например, один компьютер может быть сервером ввода/вывода данных и сервером алармов, другой - сервером отчетов и сервером трендов. Остальные компьютеры сети являются клиентами визуализации - Display Client

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

Следует отметить, что для рассматриваемых архитектур можно использовать только один сервер алармов, сервер трендов и сервер отчетов. Допускается использование нескольких серверов ввода/вывода (I/O Server).

Конфигурирование Citect-компьютеров в сети

Производится с помощью системы конфигурирования компьютеров (Computer Setup Wizard). При этом Citect по умолчанию использует протокол NetBEUI.

Запуск Computer Setup Wizard производится в Citect Explorer. Для этого следует сначала щелкнуть по строке списка проектов, а затем еще раз щелкнуть по иконке Computer Setup.

Для каждого компьютера определяются следующие параметры:

1) идентификационное имя в сети;

2) сетевые функции (сервер, компьютер оператора, компьютер менеджера);

3) имя каждого сервера;

4) доступ к событиям;

5) начальные настройки.

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

ГЛАВА 4. АЛАРМЫ И СОБЫТИЯ

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

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

Причины, вызывающие состояние аларма:

1) Выход параметров технологического процесса за  допустимые границы.

2) Неисправность в самой SCADA-системе, в контроллерах, каналах связи, в технологическом оборудовании, датчиках и т.п.

4.1. Типовые алармы

Алармы делятся на дискретные и аналоговые.

Дискретные алармы срабатывают при изменении состояния дискретной переменной. При этом для срабатывания аларма можно использовать любое из двух состояний: TRUE / ON (1) или FALSE / OFF (0). По умолчанию дискретный аларм может срабатывать на ON или OFF, в зависимости от конкретной SCADA - системы.

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

1) High и High High (верхний и выше верхнего).

 


Графическая интерпретация алармов типа Hi и HiHi.

Из рис. видно, что алармы Hi и HiHi срабатывают при достижении переменной заданных для каждого аларма пределов (High Alarm, High High Alarm). Для выхода переменной из состояния аларма (HiHi или Hi) необходимо, чтобы ее значение стало меньше порогового на величину, называемую зоной нечувствительности (Deadband).

2) Low и Low Low (нижний и ниже нижнего).

3) Deviation (отклонение от нормы). Отклонении значения переменной от заданного значения (Setpoint), причем это заданное значение в ходе технологического процесса может изменяться либо оператором, либо программно (автоматически). Аларм сработает при выходе значения переменной за границу предельно допустимого отклонения.


Графическая интерпретация алармов типа Deviation.

4) Rate of Change - ROC (скорость изменения).  Алармы типа ROC срабатывают, когда скорость изменения параметра становится больше предельно допустимой. Понятие "зона нечувствительности" (Deadband) к алармам этого типа не применяется.

4.2. Алармы и события в InTouch

В InTouch имеется две системы алармов:

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

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

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

Возникло аварийное событие

RTN

Переменная перешла из аварийного состояния в обычное

SYS

Возникло системное событие

DDE

Получено значение переменной от DDE - клиента

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

В частности, возможно следующее распределение приоритетов по четырем группам важности алармов:

Тип

Событие

ACK

Аларм был подтвержден

ALM

Возникла аварийная ситуация

EVT

Алармы

Диапазон приоритетов

Критические

0 - 249

Существенные

250 - 499

Несущественные

500 - 749

Информационные

750 - 999

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

Каждая переменная связывается с какой-либо группой алармов. Если пользователь не определил такую группу для конкретной переменной, то она автоматически связывается с корневой группой алармов $System.

Условия возникновения аварийных ситуаций определяются в словаре переменных (Tagname Dictionary). После выбора типа переменной откроется диалог ее подробного описания.

Для дискретный переменной указывается:

1) Поле Initial Value с опциями On-1/Off-0 (начальное значение - вкл./откл.) предназначено для задания дискретного состояния переменной в момент запуска WindowViewer (среда исполнения).

2) В поле Input Conversion (преобразование входных значений) указывается тип преобразования входной величины в момент обновления базы данных:

  •  Direct - входная величина читается без преобразования;
  •  Reverse - входная величина после чтения инвертируется.

3) Поля On Msg/Off Msg определяют текст, который будет отображен в окне вывода алармов при срабатывании аларма на ON/OFF.

Вывод информации об алармах

Для отображения информации об аварийных ситуациях или событиях в InTouch предусмотрены два типа объектов (окон): (текущие алармы) и.

1) Alarm Summary (Текущие алармы) на дисплей выводится информация только о текущих подтвержденных или неподтвержденных аварийных ситуациях. В случае возврата ситуации в нормальное состояние запись о ней исчезает из текущей аварийной сводки.

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

Создание системы алармов производится в несколько этапов:

1) Создание объекта (окна) вывода аварийной информации. Для создания объекта вывода алармов следует вывести на экран диалоговое окно Wizard Selection (Выбор мастера) (кнопка Wizard). Далее производится выбор категории Alarm Displays (окна вывода алармов) в списке мастеров, в категории выбирается стандартная система алармов (Standard Alarm Displays).


Стандартный объект вывода аварийной информации.

2) Конфигурирование окна вывода аварийной информации; Конфигурирование окна вывода аварийной информации производится в диалоге Alarm Configuration (параметры окна вывода аварийной информации). В этом диалоге определяется

а) тип окна вывода аварийной информации ("Текущие алармы" или "Архивная сводка алармов"),

б) группа алармов (Alarm Group)

в) границы диапазона приоритетов окна вывода алармов (From/To Priority),

г) дискретные переменные для перехода на предыдущую (Previous Page) и следующую (Next Page) страницу списка алармов.

д) Format Alarm Message (форматирование аварийного сообщения) определяется информация, включаемая в аварийное сообщение. В строку аварийного сообщения можно включить текущую дату (Date), текущее время (Time), тип аларма (Alarm Type), приоритет (Priority), имя переменной (Tagname), ее текущее значение (Value), а также группу алармов (Group Name) и статус аларма (Alarm State).

Конфигурирование стандартной системы алармов

Для входа в диалог конфигурирования стандартной системы алармов следует воспользоваться командой Special/Configure/Alarms. На экране появится диалоговое окно Alarm Properties (Свойства алармов).

Параметры стандартной системы алармов:

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

2) Размер буфера печати подключенного к параллельному порту принтера;

3) Период времени в миллисекундах, через который WindowViewer будет периодически обращаться к принтеру;

4) Поведение окна при добавлении нового аварийного сообщения к списку;

5) Разрешение регистрации событий, связанных с изменением данных в результате операций ввода/вывода, действий оператора, скрипта или системы и т. д.

Работа с удаленными алармами.

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

Для создания такой конфигурации системы алармов следует при определении параметров окна вывода аварийной информации (диалог Alarm Configuration) отметить опцию Server в поле Display Alarms для просмотра аварийной информации, накопленной узлом сервера и произведено конфигурирование сервера алармов в диалоге Свойства WindowViewer.

4.3. Алармы в Citect

Делятся на аппаратные и конфигурируемые.

1) Аппаратные алармы информируют оператора о неисправностях, возникающих в устройствах СУ (контроллерах, модулях ввода/вывода, каналах связи). Citect постоянно производит диагностику собственного состояния и состояния периферийного оборудования. Сведения об обнаруженных неисправностях выводятся оператору автоматически. Это свойство Citect является встроенным и не нуждается в предварительной настройке (конфигурировании). Аппаратные алармы отображаются на специальной странице (Hardware Alarm Page).

2) Конфигурируемые алармыАлармы, вызываемые отклонениями технологических параметров за допустимые границы, неисправностью технологического оборудования, надо предварительно конфигурировать. Система алармов Citect позволяет конфигурировать алармы по отдельным переменным, по группам переменных, по выражениям, по результатам расчетов и т. д.

Типы конфигурируемых алармов:

1) Дискретные алармы срабатывают при изменении состояния дискретной переменной.

2) Аналоговые алармы базируются на анализе выхода значений переменной за указанные верхние и нижние пределы (Hi, HiHi, Low, LoLo, Dev, ROC).

3) Алармы с меткой времени подобны дискретным алармам - аларм срабатывает при изменении дискретного параметра. Однако эти алармы имеют точную привязку ко времени (с разрешением в 1 мс !!!), которая позволяет установить точное время его срабатывания. Таймер обычно считывает время из устройства ввода/вывода. Миллисекундная точность позволяет выявлять взаимосвязи между алармами.

4) Составные алармы срабатывают, когда результат выражения Cicode меняет значения от FALSE к TRUE. Они требуют большего времени на обработку, чем другие типы алармов. Поэтому большое количество составных алармов существенно ухудшает характеристики системы управления. Составные алармы рекомендуется использовать лишь в том случае, когда невозможно применить другие типы алармов. В выражении Cicode могут быть константы, значения переменных, а также результаты сложных вычислений. Пример: HW_TEMP>=80 - запустить состояние аларма, когда значение переменной HW_TEMP будет больше или равно 80.

Конфигурирование алармов

Конфигурирование алармов производится в папке Alarms (рис.). В окне содержания проектов (Contents) появятся четыре иконки, каждая из которых предназначена для конфигурирования определенного типа алармов.

Каждый тип аларма имеет свои специфические параметры (поля) для настройки, но имеются и общие для всех типов алармов параметры:

  1.  Alarm Tag - имя аларма;
  2.  Alarm Name - имя физического устройства, связанного с алармом;
  3.  Variable Tag - переменная, вызывающая аларм;
  4.  Category - номер группы (категории) аларма (см. ниже).

Категории алармов

В системе Citect предусмотрена возможность классифицировать алармы по самым различным признакам: по участкам производства, по типу алармов, имени, приоритету и т. д. При разработке проекта можно определить до 255 категорий. Если категория для аларма не установлена, аларм будет иметь такие же атрибуты, как и аларм категории 0. Категория 255 используется для всех аппаратных алармов.


Интерфейс Citect Explorer с открытой папкой Alarms.

Каждая категория может иметь свой приоритет. Приоритеты алармов могут быть использованы для определения порядка их появления, обеспечивая необходимую для оператора фильтрацию. Важность приоритета уменьшается с увеличением его значения от 1 до 255. Таким образом, приоритет с номером 1 - самый высокий. Например, если алармы с приоритетами от 1 до 8 должны выводиться на экран, то первыми будут выводиться алармы с приоритетом 1 в порядке их поступления, затем - алармы с приоритетом 2 и т. д.

Задание свойств категории алармов производится в диалоге Alarm Categories

1) Поля Alarm On Font и Alarm Off Font предназначены для выбора шрифтов при выводе "включенных" (активных) алармов и "выключенных" алармов (переменная возвратилась в нормальное состояние).

2) Поля ON Action и OFF Action предписывают действие, которое должно быть реализовано при включении (выключении) аларма. Действие задается командой на языке Cicode.

3) Поле ACK Action предписывает действие, которое должно быть реализовано при подтверждении аларма. Также как и для предыдущих полей, действие задается командой на языке Cicode.

4) Поля Log Alarm Transitions (ON, OFF, ACK) определяют момент регистрации алармов данной категории (когда включается, выключается, подтверждается).

Отображение алармов

Для предоставления оператору информации об алармах в Citect можно создавать страницы текущих алармов (Alarm Display) и страницы сводки алармов (Alarm Summary). Более того, Citect предлагает для этих целей готовые шаблоны.

Возможные выводимые поля в Alarm Display (текущие алармы):

  1.  имя переменной, имя аларма, описание аларма;
  2.  категория аларма, справочная информация, зона, уровень доступа;
  3.  тип или состояние аларма: заблокирован, подтвержден, не подтвержден;
  4.  время/дата смены состояния или подтверждения аларма: время и дата возникновения, время и дата окончания, время и дата подтверждения, длительность.

Для дискретных алармов имеется поле состояния: on (вкл.), off (выкл.).

Для алармов с метками времени в поле времени и даты добавлена информация о миллисекундах. Для аналоговых алармов предусмотрены поля для состояний (HiHi, Hi, Lo, LoLo, Rate, Deviation), значения переменной (Value) и полосы удержания аларма (Deadband - зона нечувствительности). Так же, как и на любой графической странице, на страницах текущих алармов и сводок алармов можно расположить различные средства навигации и управления алармами (кнопки перехода на другие страницы проекта, кнопки подтверждения алармов, линейки прокрутки, регистрации алармов в файл или на принтер и т. д.).

ГЛАВА 5. ТРЕНДЫ

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

Тренды реального времени (Real Time) отображают динамическое изменение параметра в текущем времени. Текущее значение параметра выводится в правой части окна тренда.

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

5.1. Тренды в InTouch

Доступны оба типа трендов. Тренды реального времени дают возможность создавать графики изменения во времени 4 переменных (4 пера), в то время как для исторических трендов можно конфигурировать до 8 перьев в одном объекте. Количество трендов в приложении и в одном окне не ограничено.

Архивирование (регистрация) значений переменной

Для архивирования переменной в регистрационный файл необходимо включить опцию Log Data (регистрация данных) при определении переменной в диалоге Tagname Dictionary.

Запись в регистрационный файл производится при изменении переменной на величину, превышающую порог для архивирования (Log Deadband), и по умолчанию один раз в час, если значение переменной за это время не изменилось. Поле Log Deadband находится в диалоге описания переменной.

Срок хранения регистрационных файлов на диске (исключая текущий день) определяется в поле Keep Log Files for в днях. Если в это поле введено значение 0, файлы будут храниться бесконечно долго.

InTouch создает регистрационные файлы с расширением .LGH и .IDX. По умолчанию имена этих файлов имеют формат:

YYMMDD00.LGH и YYMMDD00.IDX,

где: YY, MM, DD - год, месяц и день создания файла; 00 - всегда нули.

Этапы создания тренда реального времени:

1) выбрать инструмент тренд реального времени в панели инструментов WindowMaker, перетащить в рабочее окно;


Рис.4.1.4. Объект "тренд реального времени".

2) конфигурирование тренда

Настройки:

Time Span  - диапазон времени, охватываемый трендом,

Interval - частота вывода значение переменной,

Time Division, Value Division - разрешение сетки по большим и малым делениям горизонтальной и вертикальной осей,

Color - цвета фона и рамки графика

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

Для повышения производительности системы следует отметить опцию Only update when in memory (обновлять, когда в памяти). В этом случае обновление данных тренда будет производиться только в моменты, когда окно с трендом отображается на дисплее. Также рекомендуется уменьшение толщины линии графика и частоту вывода значений переменной.

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

Нажатие кнопки выбора мастер-средств в панели инструментов вызывает появление на экране диалога Wizard Selection (выбор мастер-средств). После выбора в списке категории Trends этот диалог будет иметь следующий вид (рис.).


Диалог Wizard Selection (выбор мастер-средств).

 

Система распределенных архивов

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

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

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

1) создание списка провайдеров архивов;

2) создание и определение параметров архивного тренда;

3) конфигурирование приложения на удаленное архивирование данных;

4) копирование приложения на все узлы.


Распределенная система архивов.

5.2. Тренды в Citect

Реализована единая распределенная система построения трендов реального времени и графиков для анализа ТП. Сбор, хранение и обработку информации для ее представления в графическом виде осуществляет сервер трендов (Trends Server). При необходимости вывода трендов реального времени и архивных трендов на экран компьютера визуализации (Display Client) клиент запрашивает у сервера необходимые данные. Таким образом, по сети передаются только пакеты "полезных данных" меньшего размера, что существенно уменьшает нагрузку на сеть.


Вариант сетевой архитектуры системы Citect.

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

Регистрация данных

Объем хранимой информации ограничивается только размерами жесткого диска. Применяется сжатие файлов.

Конфигурирование трендов можно производить в Citect Explorer или в Project Editor  (папка/меню Tags). Tags (теги) - это внутренние переменные системы Citect, которым присваиваются имена с целью идентификации трендовых переменных при выводе их на экран и регистрации в файлы.

Объем выборки для хранения в файлах задается в процессе конфигурирования тренда временным периодом от 10 миллисекунд до 24 часов в сутки (поле Expression). Частота выборки данных (Sample Period) вводится в формате HH:MM:SS. Можно ввести одну цифру, например 2, и это будет означать 2 секунды. Ввод десятичной цифры система воспринимает, как долю секунды. Например, 0.2 будет означать 200 миллисекунд.

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

Пример расчета дискового пространства, необходимого для файлов тренда.

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

V=464 * N +176 + (T * N * 2) / t ,

где:
V - объем памяти (байт);
N - количество файлов;
T - время хранения информации (сек);
t - период выборки (сек).

Например, если в архив записывается одно значение переменной каждые десять секунд в течение одной недели, и используется пять файлов данных (пять недель), то требуемый объем памяти V= 464*5 +176 + {7*24*60*60*5*2}/10=607296 байт

Отображение трендов

Для отображения трендов на экране в системе Citect предусмотрены специальные шаблоны страниц,  единые для трендов реального времени и архивных трендов.  

  1.  одиночный тренд (SingleTrend) - шаблон для создания страницы с одним окном трендов, в котором имеется до 8 перьев;
  2.  двойной тренд (DoubleTrend-) - шаблон для создания страницы с двумя окнами трендов, в каждом из которых имеется до 8 перьев;
  3.  сравнительный тренд (CompareTrend) - шаблон для создания страницы c двумя трендами, наложенными один на другой в целях их сравнения (до четырех пар графиков);
  4.  масштабный тренд (ZoomTrend) - шаблон страницы с функцией масштабирования;
  5.  выпадающий тренд (PopTrend) - шаблон для вывода тренда в любом месте экрана (в отдельном окне).
  6.  тренды по событию (EventTrend) - шаблон страницы с одним окном для тренда по событию во времени на восемь перьев;

Эти шаблоны практически исчерпывают все потребности разработчика при создании трендов проекта. Создание нового шаблона, Citect происходит в редакторе Graphics Builder. Тренды, созданные с помощью этих шаблонов, является одновременно и трендами реального времени, и архивными трендами.

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

1) перемещение маркера по графикам влево и вправо

2) вывода статистических параметров - минимума, максимума, статистического среднего и стандартного отклонения;

3) изменения разрешения по времени и охватываемому периоду;

4) изменение параметров перьев в реальном времени;

5) вывод данных графика на печать и запись в файл;

6) копирование данных в буфер обмена Windows для их использования в других приложениях (в табличном формате) типа Word, Excel и т. д.

В качестве примера такого шаблона предлагается одиночный тренд (SingleTrend)-, приведенный на рис.


Шаблон одиночного тренда с окном настройки перьев.

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

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

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


Страница одиночного тренда в режиме Runtime.

5.3. Отличия подсистем отображения и архивирования в InTouch и Citect

Подсистема архивирования.

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

В Citect предлагается вводить дополнительную переменную (переменную типа Trend) и с ней связывать переменную Citect - приложения или выражение.

Основным режимом регистрации в InTouch является режим по изменению значения, т. е. регистрация переменной производится только в тот момент, когда изменение значения переменной превысило величину, указанную в Log Deadband.

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

Подсистема отображения.

Для графического отображения архивной информации в InTouch используются два стандартных объекта (Real Time Trend, Historical Trend) и Wizard - объект, детально описанные в настоящей главе. Особенность данных объектов в том, что они могут вставляться в окно, и в них может выводиться до четырех (тренд реального времени) и восьми переменных (архивный тренд). Каждый из указанных объектов масштабируется и поэтому может быть размещен в части окна или на всем окне.

Средства отображения архивных данных в InTouch отличаются простотой встраивания в приложение и связывания с переменными.

В Citect предлагается большое количество шаблонов различных типов трендов: один тренд (до 8 перьев) на странице, два тренда на странице и т. д. Это говорит о том, что Ci Technologies считает подобные шаблоны типичными для использования в проектах (свой опыт компания выразила в шаблонах) и предлагает их пользователям Citect.

В InTouch предлагаются стандартные объекты тренда реального времени и архивного тренда. Исторически сложилось так, что эти объекты разделены. Деление это условное хотя бы потому, что 16 Pen Trend из Productivity Pack функционирует в режиме и тренда реального времени, и архивного тренда.

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


ГЛАВА 6. ВСТРОЕННЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ

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

Два типа встроенных языков:

1) Языки, ориентированные на технологов. Функции в таких языках являются высокоуровневыми, не требующими профессиональных навыков программирования при их использовании. Расширение набора функций достигается с помощью дополнительных инструментальных средств (Toolkits). Разработка дополнительных функций выполняется обычно программистами - профессионалами.

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

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

При настройке SCADA на объекте cоздаются программные фрагменты (скрипты), состоящие из операторов и функций языка, которые связываются с событиями в приложении, такими как нажатие кнопки, открытие окна, выполнение логического условия (a +b > c). Каждое из событий ассоциируется с графическим объектом, окном, таймером, открытием/ закрытием приложения.

Существует два режима выполнения функций:

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

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

6.1. Скрипты в InTouch

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

Типы скриптов

1) Application Scripts (скрипты уровня приложения) относятся ко всему приложению и используются для запуска других приложений, имитации технологических процессов, вычисления значений переменных и т.д.

2) Window Scripts (скрипты уровня окна) связываются с конкретным окном.

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

4) Touch Pushbutton Action Scripts (скрипты, запускаемые кнопками) очень похожи на клавишные скрипты и связываются с объектами, которые будут использоваться в качестве исполнительных кнопок. Эти скрипты запускаются при каждом нажатии на объект-кнопку.

5) Condition Scripts (скрипты по изменению логического выражения) связываются с логической переменной или выражением, которое будет принимать значения либо "истина", либо "ложь". Логические скрипты могут содержать в себе и аналоговые переменные.

6) Data Change Scripts (скрипты по изменению данных) связываются либо с переменной, либо с полем переменной. Эти скрипты исполняются только один раз, когда значение переменной меняется на величину, превышающую заданный допуск.

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

8) Quick Function - скрипты, которые могут вызываться из других скриптов и использоваться в выражениях при определении динамических свойств объектов.

Например, длина выражения в поле Expression диалогов определения динамических свойств объектов должна быть не более 256 символов (цвет линии, цвет заполнения, изменение высоты и ширины, вертикальное и горизонтальное перемещение, вертикальное и горизонтальное заполнение, видимость, мерцание, ориентация, блокировка).

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

Сохраненная функция Quick Functions может быть использована в любом другом скрипте или выражении.

Редактор скриптов

Вызов диалога редактора скриптов в окне WindowMaker осуществляется командой Special/Scripts с последующим выбором типа создаваемого или редактируемого скрипта. Для этого можно также воспользоваться окном Application Explorer, выбрав папку Scripts. На рис.  приведен диалог Application Scripts (скрипты уровня приложения).


Редактор скриптов Application Scripts (уровень приложения).

Встроенные функции

Разбиты на четыре группы:

1) String... - для обработки различных символьных строк и переменных. Имеет до 6 аргументов. Например, синтаксис функции StringFromReal выглядит следующим образом:

StringFromReal(Number,Precision,Type); где

- Number - конвертируемая вещественная величина;
- Precision - количество десятичных знаков;
- Type - тип формата ( "f", "e", "E").

Например,

функция StringFromReal(263.365, 2, "f") возвращает "263.36";

функция StringFromReal(263.365, 2, "e") возвращает "2.63e2";

2) Math... - математические функции. Математические функции работают с целыми и вещественными аргументами, выдавая целый или вещественный результат.

3) System... - системные функции, делятся на две категории: файловые (File) и для работы с Windows - приложениями (Info).

Файловые функции предназначены для считывания и записи информации в файлы. У всех файловых функций есть два общих аргумента - Filename и FillOffset.

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

Аргумент FillOffset (смещение в файле) задает относительную позицию в файле, начиная с которой будут читаться или записываться данные. Смещение задается в байтах от начала файла. Первый байт файла имеет смещение 0. После завершения каждая функция возвращает следующее доступное смещение в файле. Например, если функция читает 5 байтов данных, начиная с 10-го байта, то после завершения функция возвратит 15. Некоторые встроенные функции группы System:

Функция

Описание

FileCopy()

Копирует исходный файл в файл-приемник

FileReadMessage()

Возвращает указанное количество байтов (или всю строку) из указанного файла

InfoDisk()

Возвращает информацию об указанном локальном или сетевом диске

InfoFile()

Возвращает информацию об указанном файле или подкаталоге компьютера или сетевого устройства

4) Misc... - функции для работы с алармами распределенных систем, трендами, печатью и др. Состоит из нескольких подгрупп.

а) Функции, название которых начинается с alm, используются только в распределенных системах алармов, например:

- almAckDisplay(ObjectName,Comment); - подтверждает только те алармы, которые в текущий момент видны в окне отображения алармов, где ObjectName (имя объекта алармов), Comment (комментарий).

б) HT функции архивных трендов, например:

- HTGetPenName(Hist_Tag, UpdateCount, PenNum); - Возвращает имя переменной, связанной в текущий момент с указанным пером указанного тренда

- HTGetValue(Hist_Tag,UpdateCount,PenNum,ValType_Text); - Возвращает значение указанного типа, вычисляемого для указанного пера в пределах всего тренда

где: Hist_Tag (имя тренда), PenNum (номер пера тренда), ValType_Text (строка, указывающая тип возвращаемого значения), Tagname (новое имя пера).

в) wc - функции управления объектами окна (простые списки, текстовые окна, ниспадающие списки и т. д.), например:

- wcDeleteItem("ControlName", ItemIndex); - Уничтожает элемент с заданным порядковым номером как в простом, так и в ниспадающем списке

- wcInsertItem("ControlName", ItemIndex, "MessageTag"); - Вставляет указанное сообщение в список

- wcLoadText("ControlName", "Filrename");.

где: ControlName (имя управляемого окна). ItemIndex (номер, соответствующий позиции элемента), MessageTag (строковое сообщение), Filename (имя файла в формате ASCII).

6.2. Язык Cicode

Cicode - встроенный язык программирования системы Citect, созданный на базе С++ специально для мониторинга и управления приложениями. Предоставляет пользователю доступ к данным проекта в режиме реального времени, а также ко всем переменным, алармам, трендам, отчетам и т. д. Поддерживает многозадачность и удаленный вызов процедур.

1) Команды

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

1) при регистрации оператора для входа или выхода из среды исполнения;

2) при открытии и закрытии графических страниц;

3) при срабатывании алармов, событий, выдаче отчетов

2) Выражения

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

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

3) Функции

Функция - это набор выражений, переменных, операторов, условий выполнения и других функций. Функции эквивалентны подпрограммам или функциям BASIC, Pascal или C.

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

1) Группа Alarm включает более 40 встроенных функций, например:

AlarmAck(Mode, Value)

Подтверждает аларм

AlarmComment(sComment)

Добавляет комментарий в страницу сводки алармов в режиме исполнения

2) Группа Page насчитывает более 20 функций, среди которых часто применяются следующие функции:

PageAlarm(Category)

Выводит страницу текущих алармов

PageDisplay(Page)

Выводит новую страницу на экран

PageFile(sName)

Выводит файл на странице файлов

PageHardware()

Выводит страницу аппаратных алармов

 

3) Keyboard

4) Report

5) Time/date

6) Miscellaneous (функции для работы с алармами, страницами проекта, клавиатурой, отчетами, временем/датой и смешанные функции).

Редактор

Вход в Редактор Cicode (Cicode Editor) осуществляется командой Tools/ Cicode Editor. Cicode - функции записываются в файлы с расширением .CI.

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


Окно Редактора Cicode (Cicode Editor).

 

ГЛАВА 7. БАЗЫ ДАННЫХ

7.1. Общие сведения

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

История развития

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

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

2) Иерархические БД. В таких базах элементы данных строго упорядочены, причем так, что данные одного уровня подчиняются (является подмножеством) данным другого, более высокого уровня. Связи данных могут быть отражены в виде дерева-графа, где допускаются только односторонние связи от старших вершин к младшим. Недостаток: взаимосвязи в реальном мире как правило не являются иерархическим.

3) Сетевые СУБД, учитывали более сложные взаимосвязи между элементами. Управляющие программы для таких СУБД становились все более и более независимыми от физических структур данных. Недостатки: сложность реализации СУБД, чувствительность к модификации программ. Так как каждый элемент данных должен содержать ссылки на другие элементы, требуются значительные объемы памяти, что приводит к снижению быстродействия.

4) Реляционные базы данных (РБД). В РБД все данные представлены в формате таблиц или, по терминологии реляционной алгебры, отношений (relation). Таблица в реляционной алгебре - это неупорядоченное множество записей (строк), состоящих из одинакового набора полей (столбцов). Каждая строка характеризует некий объект, каждый столбец - одну из его характеристик. Совокупность таких связанных таблиц и составляет БД, при этом таблицы полностью равноправны - между ними не существует никакой иерархии. Реляционная модель является простейшей и наиболее привычной формой представления данных. Достоинства:

  1.  Модель данных являются интуитивно понятной конечному пользователю.
  2.  Реорганизация данных на физическом уровне не влияет на выполнение прикладных программ. Одним из важнейших побочных эффектов данного преимущества является появление клиент-серверных архитектур.
  3.  Практически отсутствует дублирования данных.

В настоящее время сущствует пять основных производителей СУБД: IBM, Informix, Microsoft, Oracle и Sybase.

Существует две категории приложений БД:

1) OLTP (Online Transaction Processing - оперативная обработка транзакций). Используются для создания приложений, поддерживающих ежедневную активность организации. Обычно это критические для деятельности приложения, требующие быстроты отклика и жесткого контроля над безопасностью и целостностью данных.

2) DSS (Decision Support System - системы поддержки принятия решений). Как правило, крупнее, чем OLTP-системы. Обычно они используются с целью анализа данных и выдачи отчетов и рекомендаций. Пользователи должны иметь возможность конструировать запросы различной степени сложности, осуществлять поиск зависимостей, выводить данные на графики и использовать информацию в других приложениях типа электронных таблиц, текстовых процессорах и статистических пакетов. Еще более широкую поддержку в процессе принятия решений обеспечивают системы оперативной аналитической обработки (OLAP - Online Analytical Processing).

Критерии оценки БД

  1.  Возможность доступа конечных пользователей к нужной информации в нужном месте и в нужное время
  2.  Открытость и гибкость запросов информации
  3.  Надежность БД
  4.  Распространенность и поддержка ее технологии большим числом независимых производителей ПО
  5.  Интеграция с ПО
  6.  Спектр возможностей
  7.  Стоимость БД и аппаратной платформы для ее поддержки

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

В качестве интерфейса в клиент-серверных системах используется язык структурированных запросов SQL (Structured Query Language). Он представляет собой средство организации, управления и поиска информации в РБД.

Достоинства:

  1.  независимость от поставщика;
  2.  переносимость на разные платформы;
  3.  опора на реляционные принципы хранения информации;
  4.  высокоуровневая структура;
  5.  возможность интерактивного выполнения запросов;
  6.  поддержка со стороны крупных производителей

Особенности промышленных БД

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

Как правило, производственному персоналу всегда не хватает информации. Все они хотели бы иметь какое-то единое средство доступа к информации, например, с мощью и открытостью РБД.

Однако, традиционные БД не всегда применимы в системах промышленной автоматизации. Можно выделить несколько основных ограничений:

1) Интенсивность  генерации данных ПП. Чтобы хранить производственный архив системы, например, с 7500 рабочими переменными, в БД каждую секунду необходимо вставлять 7500 строк. Обычные БД не могут выдержать подобную нагрузку.

2) Большой объем производственной информации. Многомесячный архив завода с 7500 рабочими переменными требует под БД памяти объемом около 1 Терабайта. Сегодняшние технологии такими объемами манипулировать не могут.

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

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

7.2. IndustrialSQL Server

IndustrialSQL Server - СУ РБД реального времени, использующая язык SQL. Обращение к IndustrialSQL Server осуществляется при помощи тех же утилит, что и  Microsoft SQL Server. Поставляется Wonderware как самостоятельный продукт, он, в то же время, является одним из компонентов пакета промышленной автоматизации FactorySuite2000.

Характеристика

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

2) Масштабируемость. IndustrialSQL Server может использоваться как в небольших цехах, так и на крупных промышленных предприятиях с сотнями тысяч параметров.

3) Поддержка временных временные характеристики данных. В язык запросов IndustrialSQL Server включены средства работы с временными характеристиками данных. Разработанные компанией серверы ввода/вывода используют протокол SuiteLink, в котором введена концепция отметок времени и качества информации, выставляемых серверами ввода/вывода.

4) Уменьшение объема хранения информации. IndustrialSQL Server позволяет хранить данные на пространстве, составляющем небольшую долю от соответствующего объема обычной РБД. Например, двухмесячный архив предприятия с 4000 параметров, опрашиваемых с периодичностью от нескольких секунд до нескольких минут, будет занимать около 2 Мб дискового пространства. Используемый алгоритм упаковки информации является алгоритмом сжатия без потерь, сохраняющим высокое разрешение и качество данных.

5) Простота использования. Для установки, конфигурирования и использования IndustrialSQL Server от пользователя не требуется никакого знания языка SQL. Особенностью IndustrialSQL Server является его ориентация на готовые наборы функций. IndustrialSQL Server разрабатывался как не требующая никакого администрирования система управления БД. Резервные копирования базы могут выполняться средствами Microsoft BackOffice.

6) Интеграция с другими компонентами пакета FactorySuite 2000. Являясь базой данных в составе FactorySuite 2000, IndustrialSQL Server тесно связан с любым компонентом этого пакета на любом уровне.

7.3. Plant2SQL

Plant2SQL – СУБД  Citect.

1) Технологические данные хранятся в стандартных MS SQL таблицах. Для обеспечения высокой скорости регистрации используется стандартная подсистема архивов Citect.

Если SQL Server не установлен, то Plant2SQL сохраняет информацию, используя Microsoft Data Engine (MSDE), который поставляется с Plant2SQL.

Размер БД MSDE ограничен 2 Гб и оптимизирован для небольших БД, когда количество одновременно работающих клиентов не превышает 5. При увеличении количества пользователей, производительность сильно падает.

2) Управляющему персоналу не требуется знать SQL или особенности получения данных из SCADA-архивов.

3) Plant2SQL включает ряд клиентских приложений, например, для Microsoft Excel. Оно позволяет пользователю выбирать данные и встраивать их в электронные таблицы. При встраивании допустимо использование всех стандартных средств (tools), чтобы представлять и анализировать информацию, а затем сохранять ее для повторного использования.

4) Встроенные средства резервирования. Отдельный Plant2SQL может подключаться к основному Citect-серверу и автоматически переключаться на резервный Citect-сервер при возникновении проблем с основным.

Замечание. В Plant2SQL не существует синхронизации между основной и резервной базами данных Plant2SQL.

8. ЯЗЫКИ ПРОГРАММИРОВАНИЯ КОНТРОЛЛЕРОВ

8.1. Общие сведения о языках программирования

По мере развития SCADA-систем, наблюдается расширение их функциональных возможностей, в частности интеграция средств программирования контроллеров (Soft Logic систем). В то же время разработчики средств программирования ПЛК начинают включать в свои пакеты средства визуализации и другие функции, характерные для SCADA-систем. Примерами тому могут служить такие известные программные продукты как ISaGRAF (CJ International, Франция), CoDeSys (3S Smart Software Solutions, Германия) и другие.

Программирование ПЛК как правило осуществляется с персонального компьютера (ПК). Традиционно все производители ПЛК имеют собственные разработки инструментального программного обеспечения, оптимизированные под конкретную аппаратуру, например, STEP7 для ПЛК Siemens, Concept для ПЛК Schneider Electric. С другой стороны, при внедрении проекта автоматизации зачастую приходится объединять в единую систему ПЛК разных фирм. Здесь возникает проблема единообразного описания и переносимости программных разработок.

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

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

7.2. Язык последовательных функциональных диаграмм SFC

Язык SFC (Sequental Function Chart) стоит на более высоком уровне по отношению к остальным четырём языкам. Прототипом для создания SFC послужили сети Петри, хотя пути их развития оказались разными. SFC развивается как инструмент описания производственных операций, а сети Петри расширяют возможности моделирования дискретных систем. В отличие от сетей Петри дуги в SFC направлены сверху вниз и отражаются прямыми линиями. Позиции в SFC называют шагами или этапами, и отображаются в виде прямоугольников, что дает возможность реализации диаграмм в символах псевдографики. Задать несколько стартовых шагов в SFC нельзя, только один шаг диаграммы является начальным.

Диаграмма SFC состоит из шагов и переходов между ними. Разрешение перехода определяется условием. С шагом связаны определённые действия. Описания действий выполняются на любом языке МЭК. Сам SFC не содержит управляющих команд ПЛК. Можно создать несколько уровней вложенных SFC-диаграмм. Действия нижнего уровня необходимо описать на языке IL, ST, LD или FBD. Целью применения SFC является разделение задачи на простые этапы с формально определённой логикой работы системы без программирования. Причём для отработки верхнего уровня не требуется детальное описание действий, так же как и привязка к конкретным аппаратным средствам.

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

SFC-диаграмма блока управления реверсивным приводом

8.3. Язык инструкций IL

Язык IL (Instruction List) представляет собой типичный ассемблер с аккумулятором и переходами по меткам. Набор инструкций стандартизирован и не зависит от конкретной целевой платформы. Язык IL позволяет работать с любыми типами данных, вызывать функции и функциональные блоки, реализованные на любом языке. Таким образом, на IL можно реализовать алгоритм любой сложности, хотя текст будет достаточно объемным.

Аккумулятор IL является универсальным контейнером, способным сохранять значения переменных любого типа. В стандарте МЭК вместо термина "аккумулятор" используется термин "результат" (result). Так, инструкция берёт "текущий результат" и формирует "новый результат".

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

8.4. Язык структурированного текста ST

 

Язык ST (Structured Text) – это язык высокого уровня, синтаксически представляющий собой адаптированный язык Паскаль. Вместо процедур Паскаля в ST используются компоненты программ стандарта МЭК. Пример программы на языке ST:

WHILE Counter <>0 DO

  Counter := Counter-1;

  Var1 := Var1*2;

  IF Var1 > 100 THEN

     Var1 := 1;

   Var2 := Var2 +1;

  END_IF

END_WHILE

В большинстве комплексов программирования ПЛК язык ST по умолчанию предлагается для описания действий и условий переходов SFC. Комбинация ST и SFC действительно представляет эффективное средство решения практически любых задач.

8.5. Язык релейных диаграмм LD

Язык релейных диаграмм LD (Ladder Diagram) или язык релейно-контактных схем (РКС) – графический язык, реализующий структуры электрических цепей. Когда в начале 70-х годов XX века релейные автоматы начали вытесняться ПЛК, возникла задача прозрачного переноса релейных схем в ПЛК, которая привела к появлению языка LD.

Графически LD-диаграмма представлена в виде двух вертикальных шин питания, между которыми расположены цепи, образованные соединением контактов. Нагрузкой каждой цепи служит реле. Каждое реле имеет контакты, которые можно использовать в других цепях. При необходимости можно параллельно включить несколько реле, последовательное включение не допускается. Замыкающие и размыкающие контакты обозначаются  " -| |- " и " -|/|- ", обмотки реле "-( )-", что на ранних этапах развития LD, в условиях отсутствия графического интерфейса, давало возможность построения диаграмм с помощью символов псевдографики. Так приведенная на рис, схема эквивалентна выражению: Р1:=(K1 OR K2) AND (NOT K3) 

В LD каждому контакту ставится в соответствие логическая переменная, определяющая его состояние. Если контакт замкнут, то переменная имеет значение ИСТИНА (TRUE). Если разомкнут – ЛОЖЬ (FALSE). Имя переменной пишется над контактом и фактически служит его названием.

Схема цепи LD-диаграммы

Цепь может быть либо замкнутой (ON), либо разомкнутой (OFF). Это состояние цепи отражается на обмотке реле и соответственно на значении логической переменной обмотки ИСТИНА/ЛОЖЬ.

Идеология релейных схем подразумевает параллельную работу  всех цепей. Ток во все цепи подаётся одновременно. В LD решение диаграммы выполняется последовательно слева направо и сверху вниз.

Логически последовательное И (AND), параллельное ИЛИ (OR) соединения контактов и инверсия НЕ (NOT) образуют базис Буля. В результате LD идеально подходит не только для построения релейных автоматов, но и для программной реализации комбинационных логических схем. Благодаря возможности включения в LD функций и функциональных блоков, выполненных на других языках, сфера применения языка практически не ограничена.

8.6. Язык функциональных диаграмм FBD

Язык FBD (Function Block Diagram) – это графический язык программирования. Диаграмма FBD напоминает принципиальную схему электронного устройства на микросхемах. В отличие от LD, связи блоков могут передавать сигналы (переменные) любого типа (логический, аналоговый, время и т.д.), и шины питания не показываются. Выходы блоков могут быть поданы на входы других блоков либо непосредственно на выходы ПЛК. Сами блоки, представленные на схеме как "чёрные ящики", могут выполнять любые функции.

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

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

Изображённая в качестве примера на рис. цепь определяет условие включения питания Power реверсивного привода. Питание подаётся, если направление вращения не менялось (Reversal = Direction), присутствует сигнал включения (On) и торможение закончено (NOT Braking).

Пример FBD-схемы


 

А также другие работы, которые могут Вас заинтересовать

50943. Метод Ейлера вирішення задачі Коші 38 KB
  Мета: Навчитися будувати розвязок задачі Коші по методу Ейлера. Скласти програму. Устаткування: папір формату А4, програмне забезпечення Borland С++, ПК.
50944. Метод Рунге-Кутта вирішення задачі Коші. Складання алгоритму 42 KB
  Мета. Навчитися вирішувати задачу Коші методом Рунге-Кутта; скласти алгоритм. Устаткування: папір формату А4, ПК, програмне забезпечення Borland С++. Хід роботи Правила техніки безпеки Теоретичні дані Індивідуальне завдання.
50946. Екстраполяційний метод Адамса розвязання задачі Коші 41 KB
  Мета. Навчитися знаходити розвязок диференційного рівняння екстраполяційним методом Адамса. Устаткування: папір формату А4, ручка, калькулятор, ПЗ С ++. Хід роботи Правила техніки безпеки Теоретичні дані Індивідуальне завдання. Використовуючи метод Адамса з трьома кінцевими різницями, скласти таблицю наближених значень інтеграла диференційного рівняння, з початковими умовами на відрізку з точністю 0,001. Початковий відрізок встановити методом Рунге-Кутта.
50947. Метод прогонки розвязання крайової задачі. Складання алгоритму 40.5 KB
  Мета. Навчитися використовувати метод прогонки розв’язання крайової задачі звичайного диференційного рівняння. Скласти алгоритм. Устаткування: папір формату А4, ручка, калькулятор, С++.
50948. ОБЩИЕ СВОЙСТВА ВОЗБУДИМЫХ ТКАНЕЙ 173.5 KB
  СВОЙСТВА НЕРВНЫХ ЦЕНТРОВ Мы начинаем изучение новых разделов физиологии ОБЩИЕ СВОЙСТВА ВОЗБУДИМЫХ ТКАНЕЙ и физиология кровообращения Лабораторные работы с которыми Вы познакомитесь при изучении этих разделов отличаются тем что выполняются на животных. Лабораторные работы по разделу ОБЩИЕ СВОЙСТВА ВОЗБУДИМЫХ ТКАНЕЙ Тема 1: СТРУКТУРА И ФУНКЦИЯ РЕФЛЕКТОРНОЙ ДУГИ 1. Ход работы: Объект исследования спинальная лягушка лягушка с удаленным головным мозгом и сохраненным спинным. ОБРАЗЕЦ ПРОТОКОЛА ДЛЯ ВСЕХ ПОСЛЕДУЮЩИХ ЗАНЯТИЙ:...
50949. Изучение статистических закономерностей в ядерной физике 3.61 MB
  Почему прибор за равные промежутки времени при постоянной интенсивности потока излучения регистрирует неодинаковое количество частиц 4. При небольшом напряжении на счетчике величина этого тока пропорциональна количеству пар ионов образованных частицей. Таким образом в данном режиме попадание частицы в объем счетчика вызывает кратковременный но достаточно сильный импульс тока. Для того чтобы световая вспышка была зарегистрирована ФЭУ необходимо чтобы материал сцинтиллятора был прозрачен для собственного излучения а спектр излучения...
50950. ОПРЕДЕЛЕНИЕ ЦЕНЫ ДЕЛЕНИЯ И ВНУТРЕННЕГО СОПРОТИВЛЕНИЯ ГАЛЬВАНОМЕТРА 8.1 MB
  Проверка закона Ампера основана на измерении периодов колебаний Т физического маятника зависящих от тока I. где собственная частота колебаний; частота колебаний при наличии тока. Определить с помощью секундомера время 10 полных колебаний t и вычислить период колебаний маятника T0 = t 10. Повторить определение периода колебаний маятника Т0 еще 4 раза.