Добавил:
sergeevpavel0406@mail.ru СОВА Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Основы проектирования приборов и систем. Лекции

.pdf
Скачиваний:
30
Добавлен:
23.05.2021
Размер:
5.86 Mб
Скачать

Лекция 5

1.1.1Инструмент разработки программного обеспечения (4 часа)

1.1.1.1 Современные методы автоматизированного проектирования программных средств с применением интерактивных графических систем.

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

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

SCADA-система (Supervisory Control And Data Acquisition System) это система сбора данных и оперативного диспетчерского управления. В названии присутствуют две основные комплексные функции, возлагаемые на SCADA-систему:

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

данных и правил (критериев), выполнение которых обеспечивает наибольшую эффективность и

безопасность технологического процесса.

 

Современные SCADA-системы, такие как Trace Mode AdAstra, Genesis

Iconics, Genie Advantech,

GenieDAQ Advantech, FixDynamics (iFIX) Intellution, Factory Suite (InTouch)

Wonderware, Factory Link

US Data, Lookout National Instruments, WinCC Siemens, RealFlex BJ Software Systems, Sitex Jade Software, IGSS Seven Technologies, RSView Rockwell Software Automation, Cimplicity General Electric, DeltaV - Emerson, Fast Tools (VDS) - Yokogawa, PcVue ARC Informatique, Image - Технолинк, КРУГ-2000

НПФ КРУГ , МАИС ЗАО НТЦ Лидер , MasterSCADA InSAT, КВИНТ НИИ Теплоприбор и другие, позволяют достаточно быстро реализовать сбор информации о технологическом процессе, интерфейс с оператором и сохранение истории процесса. Реализация автоматического управления может быть выполнена или с использованием блоков простых типовых алгоритмов управления (ПИД-регулятор, двухпозиционное регулирование и т.д.), или осуществлена по собственным алгоритмам с использованием скриптовых языков,

например, Microsoft Visual Basic (МVB).

Остановимся на основных функциях, которые возлагаются на любую SCADA-систему.

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

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

2)Сохранение принятой информации в архивах.

3)Вторичная обработка принятой информации.

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

5)Прием команд оператора и передача их в адрес контроллеров и исполнительных механизмов.

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

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

8)Формирование сводок и других отчетных документов на основе архивной информации.

9)Обмен информацией с АСУП (комплексной информационной системой).

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

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

Часто программное обеспечение с ярко выраженным упором на функции взаимодействия с оператором

(визуализация и т. п.) называют пакетами MMI (Man Machine Interface), или HMI (Human Machine Interface).

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

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

детерминированность реакции SCADA-системы.

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

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

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

SCADA-система должна быть доступной не только для разработчика, но и для конечного пользователя создаваемой АСУ ТП.

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

Умеренная цена и эффективное использование вложенных средств стоимость системы, затраты на освоение и стоимость работ по созданию, сопровождению и развитию АСУ ТП должны быть оптимальными.

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

Основным информационным элементом SCADA-системы является тег (tag), имеющий уникальное имя и атрибуты. Тег является источником информации и может быть, например, сигналом с аналогового или дискретного датчика, данными, переданными из другого Windows-приложения, выходом блока обработки данных (например, типового ПИД-регулятора), либо может быть введен пользователем с помощью кнопок, переключателей и регулировок. Переменные, определяющие состояние тегов, могут отображаться в реальном масштабе времени в виде совокупности графических динамических образов, для которых в наиболее развитых пакетах определяются пропорциональное перемещение, поворот, масштабирование, цвет, а также видеоряд и звуковое сопровождение. Во всех пакетах имеются и типовые средства отображения: имитаторы регистрирующих приборов с различной шкалой, ползунковые и круговые регуляторы, кнопки, переключатели и т. д. Графические образы объединяются в именованные экранные формы. К атрибутам тега относят характер данных, шкалу, уровни сигнализации и т.д. Обработка данных, логически связанных с тегами, может осуществляться с помощью блоков типовых операций, описанных с использованием простых и в то же время емких специализированных скриптовых языков, либо с использованием традиционных языков типа Microsoft Visual Basic (МVB). Кроме того, имеется возможность подключения инструментария в виде пользовательских DLL-библиотек, а также динамического обмена данными с пользовательскими приложениями по интерфейсу DDE или OPC в локальной сети.

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

SCADA - OLE for Process Control. Концепция стандарта OPC.

OPC (OLE (Object Linking and Embedding связывание и внедрение объектов) for Process Control ) это стандарт взаимодействия между программными компонентами системы сбора данных и управления (SCADA), основанный на объектной модели COM/DCOM фирмы Microsoft. Через интерфейсы OPC одни приложения могут читать или записывать данные в другие приложения, обмениваться событиями, оповещать друг друга о нештатных ситуациях (тревогах), осуществлять доступ к данным, зарегистрированным в архивах (так называемые «исторические» данные). Эти приложения могут располагаться как на одном компьютере, так и быть распределенными по сети, при этом независимо от фирмы - поставщика стандарт OLE for Process Control, признанный и поддерживаемый всеми ведущими фирмами - производителями SCADA-систем и оборудования, обеспечит их совместное функционирование.

Особый класс OPC-приложений представляют собой OPC-серверы конкретных аппаратных устройств они поставляются многими производителями аппаратуры.

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

OPC может использоваться только там, где установлен Microsoft DCOM, а это на сегодня Windows NT, Windows XP, Vista, Windows 7.

OPC не обеспечивает работы в жестком реальном времени, поскольку в DCOM отсутствуют понятия качества обслуживания, крайних сроков и т.п. В то же время контроль «устаревания» данных имеется: каждое передаваемое значение (тег) сопровождается меткой времени происхождения (timestamp). Несмотря на то, что требования жесткого реального времени не выполняются, реальная частота передачи данных порядка 50 миллисекунд достигается без каких-либо специальных мер.

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

Реализация OPC основана на объектной модели COM/DCOM фирмы Microsoft. COM (Component Object Model) это модель многокомпонентных объектов, позволяющая приложению манипулировать удаленными программными объектами, точнее, вызывать те или иные функции (методы) этих объектов так, как будто объекты находятся рядом. Когда объект действительно находиться рядом (в адресном пространстве приложения) тогда это просто COM. Если же объект находится в другой программе на том же компьютере или на другом узле сети, то это DCOM Distributed (распределенная) COM. В распределенном случае (DCOM) вызов любой функции объекта перехватывается специальным агентом - посредником, так называемой proxy/stub DLL, которая исполняет роль представителя объекта у обратившегося к нему клиента.

Proxy/stub DLL упаковывает параметры функции (marshaling - транспортировка) и передает вызов операционной системе, которая (возможно, по сети) доставляет вызов по назначению, то есть заставляет реальный объект выполнить заданную функцию. Результат затем возвращается (примерно по той же цепочке) приложению - клиенту. Удобство использования DCOM состоит в том, что приложение - клиент совершенно не обязано знать, где реально находится объект о степени удаленности объекта оно может судить только по увеличению расхода времени на вызов функции.

OPC-взаимодействие основано на клиент-серверной схеме. OPC-клиент (например, SCADA), вызывая определенные функции объекта OPC-сервера, подписывается на получение определенных данных с определенной частотой. В свою очередь, OPC-сервер, опросив физическое устройство, вызывает известные функции клиента, уведомляя его о получении данных и вручая сами данные. Таким образом, при OPCвзаимодействии используются как прямые COM-вызовы (от клиента к серверу), так и обратные (callback, от сервера к клиенту).

Стандарт OPC, в отличие, например, от устаревшего DDE (Dynamic Data Exchange), хотя и основан на универсальном фундаменте COM/DCOM, разрабатывался специально для использования в промышленной автоматизации, поэтому он имеет вполне содержательную концептуальную сторону, то есть, свою проблемно -ориентированную модель взаимодействия, которая и реализована через совокупность COM-интерфейсов. Эта концептуальная сторона в известной степени независима и представляет самый большой интерес, особенно для пользователя-непрограммиста, для которого тонкости реализации СОМ-интерфейсов не важны.

Стандарт состоит из трех основных спецификаций:

1)доступ к данным реального времени (Data Access);

2)обработка тревог и событий (Alarms & Events);

3)доступ к историческим данным (Historical Data Access). OPC-серверов тоже может быть три вида, соответственно:

1)OPC-серверы физических устройств обычно являются только серверами данных (Data Access

Servers);

2)Серверы тревог;

3)Серверы исторических данных.

Серверы тревог и исторические серверы чаще всего «паразитируют» на серверах данных.

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

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

Центральное

место среди спецификаций OPC занимает

доступ к

данным реального времени

(DataAccess). Это самая старая и отработанная спецификация.

 

 

Базовым понятием этой спецификации является элемент данных (Item). Каждый элемент данных (то

есть фактически

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

значение,

время последнего обновления

(timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа: булево, целое, с плавающей точкой и т.п., или строкой (так называемый OLE VARIANT). Время представляется с 100 % наносекундной точностью. Качество - это код, содержащий в себе грубую оценку достоверности параметра - UNCERTAIN, GOOD и BAD (не определено, хорошее и плохое), а на случай плохой оценки - еще и расшифровку, например, QUAL_SENSOR_FAILURE неисправность датчика.

Следующим вверх по иерархии является понятие группы элементов (OPC Group). Группа создается OPC-сервером по требованию клиента, который затем может добавить в группу элементы (Items). Для группы клиентом задается частота обновления данных, и все данные в группе сервер старается обновлять и передавать клиенту с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Группа всегда создается для каждого клиента своя, даже если состав элементов и частоты обновления совпадают. Отсоединение клиента приводит к уничтожению созданных для него групп.

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

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

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

Пример полного имени тега: Устройство_1. Модуль_2. Аналоговый Вход_3 (в качестве разделителя используется точка). При добавлении элемента в группу клиент всегда указывает это полное имя. Заметим, что группы, создаваемые клиентом на сервере, не обязаны совпадать (и, как правило, не совпадают) с подразделами пространства имен сервера, элементы в группу добавляются вразнобой. Единственное, что их объединяет, это общая частота обновления и синхронность отправки клиенту.

Наконец, на верхней ступеньке иерархии понятий находится сам OPC-сервер. Из всех перечисленных (OPC-группа, OPC-элемент) он единственный является COM-объектом, все остальные объекты доступны через его интерфейсы, которые он предоставляет клиенту.

Схема взаимодействия ОРС-клиентов с ОРС-сервером представлена на рисунке 10.

Рисунок 10 - Схема взаимодействия ОРС-клиентов с ОРС-сервером

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

При синхронном обмене клиент осуществляет инициативное чтение или запись данных. Запись может быть только синхронной. Затраты ресурсов компьютера на поддержку OPC-взаимодействия и предельно достижимая интенсивность обмена между клиентом и сервером зависят от ряда факторов, но прежде всего от того, находится ли сервер непосредственно в адресном пространстве клиента (так называемый внутризадачный - InProcess Server) или он является самостоятельным приложением. В последнем случае важно, расположен сервер на том же компьютере, что и клиент, или на другой станции локальной сети. Третий по важности фактор это возможность группировки данных для отправки клиентам. Так, передача раз в 1 секунду 100 тегов займет значительно меньше ресурсов, чем одного тега через каждые 10 миллисекунд.

Предельная пропускная способность внутризадачного сервера может достигать 1 млн. элементов OPC в секунду, что значительно превышает все реальные потребности (при тактовой частоте процессора типа Pentium - 233 МГц). Однако не все OPC-серверы имеют внутризадачный (InProcess) вариант для этого они должны оформляться как динамические библиотеки (DLL), а не как самостоятельные программы.

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

Наконец, для удаленного сервера (в сети Ethernet 10BaseT) пропускная способность оказалась заключена в пределах 330 7000 элементов в секунду (наилучший и наихудший варианты соответствуют тем же самым крайним случаям).

Приведенные цифры практически все производители SCADA-систем поддерживают OLE for Process Control, среди них Fix Dynamics (Intellution), FactorySuite 2000 (Wonderware), Genesis (Iconics), FactoryLink

(US Data), Lookout (National Instruments) и т.д. могут варьироваться в зависимости от системной конфигурации, а также особенностей реализации сервера и клиента.

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

Первоначально OLE (Object Linking and Embedding) была задумана как технология интеграции программных продуктов, входящих в комплект Microsoft Office. Предшественницей OLE является реализованная в Windows технология динамического обмена данными DDE (Dynamic Data Exchange), до сих пор широко применяемая в данной среде. Однако многие разработчики не без оснований считают, что DDE трудно использовать, поскольку это технология низкого уровня. По существу, DDE представляет собой модель взаимодействия процессов - протокол, с помощью которого приложение может организовать канал обмена данными с DDE-сервером, находящимся на том же компьютере. DDE - это асинхронный протокол. Иными словами, после установления связи вызывающая сторона передает запрос и ожидает возврата результатов. Такой механизм более сложен, чем синхронный вызов функции, так как нужно учитывать вероятность нарушения связи, таймауты и другие ошибки, которые приложение должно распознавать и исправлять. Низкая популярность DDE вынуждала Microsoft искать различные способы его усовершенствования.

В качестве технологии более высокого уровня была реализована OLE 1.0 или OLE 1 (Object Linking and Embedding - связывание и внедрение объектов). Она расширила возможности протокола DDE и, используя его как базовый механизм коммуникаций, позволила активизировать встроенный объект в документе, то есть получить составной документ. Таким образом, OLE 1.0 унаследовала многие проблемы асинхронного протокола. Эта технология имела множество недостатков, а ее компоновка была слишком сложна для пользователей среднего уровня. Кроме того, установленные связи легко нарушались, например, в результате изменения маршрута доступа к файлу связанного объекта.

Первое воплощение OLE: OLE 1, представляло собой механизм создания и работы с составными документами (compound documents). С точки зрения пользователя, составной документ выглядит единым набором информации, но фактически содержит элементы, созданные двумя или несколькими разными приложениями. С помощью OLE 1 пользователь мог, например, объединить электронную таблицу, созданную в Microsoft Excel, с текстовым документом, сформированным в Microsoft Word. Идея состояла в том, чтобы документно-ориентированная (document-centric) модель работы с компьютером позволила бы пользователю больше думать об информации и меньше о приложениях, ее обрабатывающих. Как следует из слов связывание и внедрение , составные документы можно создать, либо связав два разных документа, либо полностью внедрив один документ в другой.

OLE 1, как и большинство первых версий программных продуктов, была несовершенна. Архитекторы OLE создали группу технологий, область применения которых гораздо шире составных документов. Основу OLE 2 составляет важнейшая из этих технологий - Модель многокомпонентных объектов (Component Object Model - СОМ). Новая версия OLE не только обеспечивает поддержку составных документов лучше, чем первая, но и, несомненно, идет куда дальше простого объединения документов, созданных в разных приложениях.

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

Благодаря этим преимуществам, СОМ скоро стал частью технологий, не имеющих никакого отношения к составным документам. Однако в Microsoft хотели сохранить общее имя для всей группы технологий, в основе которых лежит СОМ. Компания решила сократить название Object Linking and Embedding до OLE - эта комбинация более не рассматривалась как аббревиатура - и был опущен номер версии.

1.1.1.3 Методика создания программного проекта. Основные функции SCADA-систем.

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

органы управления различных типов, например кнопки, рубильники, ползунковые или поворотные регуляторы;

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

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

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

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

иными словами, предсказуемое время отклика на внешние события; драйверы к оборудованию нижнего уровня АСУ ТП; сетевые функции;

средства защиты информации от несанкционированного доступа в систему (СЗИ от НСД); многооконный графический интерфейс и другие очевидные функции, такие как импорт

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

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

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

кнопка «Старт»; полосковый индикатор состояния аналогового входа «Температура»; табло «Авария».

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

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

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

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

Например, если при превышении значения 90 параметра «Температура» нам нужно включить табло «Авария», то делается запись:

IF ТЕМПЕРАТУРА > 90 THEN АВАРИЯ=1 ELSE

АВАРИЯ=0

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

На этом шаге процесс «программирования» заканчивается. Остается запустить полученный проект под

управлением следующей неотъемлемой части всех пакетов SCADA программы-монитора, или Runtime.

1.1.1.4 Инструментальный пакет Genesis фирмы Iconics (США)

Инструментальный пакет Genesis разрабатывается фирмой Iconics (США) с 1986 года.

В Genesis реализована вытесняющая приоритетная многозадачность на основе специальной программы-ядра реального времени, RTS (Real Time Server). RTS обеспечивает опрос каналов ввода-вывода с гарантированным временем реакции до 50 мс. В составе пакета имеется более 250 драйверов к оборудованию ведущих производителей средств автоматизации. Одной из главных отличительных черт пакета является его модульность, что позволяет конечному пользователю сократить финансовые затраты, приобретая только необходимые для реализации проекта части пакета.

RTS состоит из исполнительной и инструментальной частей. Исполнительная часть отвечает за опрос каналов ввода-вывода, выполнение алгоритмов сбора информации и управления, а также обрабатывает запросы всех остальных приложений Genesis. В состав инструментальной части входит средство конфигурирования RTS при помощи графического языка функциональных блоков. Иными словами, если вы можете описать поведение вашего процесса в виде блок-схемы, для вас не составит большого труда повторить то же самое на языке графических символов Strategy Builder инструмента создания стратегии для RTS. Библиотека предлагаемых функциональных блоков включает в себя блоки ввода-вывода аналоговых и цифровых сигналов, математических и логических операций, блоки реализации алгоритмов управления типа PID-регуляторов, интеграторов и еще множество самых разнообразных элементов для построения алгоритмов.

Не менее важной частью Genesis является модуль GraphWorX, реализующий интерфейс человекмашина (MMI). Эта часть Genesis позволяет создавать при помощи специализированного графического редактора экраны отображения поведения процесса и выводить их на дисплей оператора. Набор возможностей GraphWorX достаточно богат - возможно создавать кадры отображения практически любой сложности, от текстов и мнемосхем процесса до кадров с анимацией в реальном времени. Следующий модуль Genesis - AlarmWorX - отвечает за отображение и ведение архива аварийных ситуаций. Форма генерируемых отчетов и сообщений может произвольно настраиваться. Предусмотрена возможность автономного использования этого модуля без остальных частей пакета Genesis.

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

Модуль DataSpy реализует функции интерфейса OPC с другими приложениями Windows.

Один из наиболее важных модулей Genesis - I/O Server - отвечает за связь пакета с конкретным оборудованием АСУ ТП. Каждый I/O Server обслуживает определенный тип внешних устройств вводавывода. Принимаемые и выдаваемые данные представляются в стандартном формате ODBC (Open Database Connectivity - программный интерфейс доступа к базам данных, встроенный в Windows) фирмы Microsoft,

что делает их доступными для других приложений Windows. Несмотря на огромный список оборудования, для которого соответствующие драйверы уже написаны, фирма Iconics поставляет инструментарий (I/O Server Tool Kit) для создания собственных вариантов I/O Server.

1.1.1.5 Инструментальный пакет Trace Mode фирмы AdAstra (Россия)

Московская фирма AdAstra разработала пакет Trace Mode, который выгодно отличают следующие

преимущества:

1)Простота освоения такого сложного продукта, как SCADA-система.

2)Доступность консультаций производителя.

3)Trace Mode имеет драйверы к оборудованию, распространенному в России.

4)Стоимость пакета для большинства потребителей вполне приемлема.

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

Затем полученные файлы стратегии поведения системы запускаются под управлением соответствующего монитора реального времени (МРВ) или Профайлера.

Среди функциональных возможностей пакета имеется возможность программирования задач верхнего и нижнего уровня АСУ ТП в одной инструментальной среде.

Лекция 6

1.1.1.1 Стандартные языки программирования промышленных программируемых контроллеров SFC, FBD, LD, ST, IL согласно международному стандарту МЭК 61131 Программируемые контроллеры .

В то время как в сфере компьютерных приложений объектно-ориентированное программирование (ООП) давно стало составной частью всех ведущих языков, в сфере контроллерных приложений оно применяется крайне редко. Говорят, что это происходит в силу некоторой консервативности свойственной программистам контроллеров (ПЛК). Отчасти это действительно так. Но все же в более значительной степени здесь сказываются ограниченные возможности инструментов программирования. Конечно, почти все современные контроллерные платформы дают возможность, так или иначе, использовать C++ (за дополнительные деньги). Однако компилятор обеспечивает только лишь аспекты чистого программирования. Функции отладки и ввода в эксплуатацию этих систем практически непригодны для контроллерных приложений. Даже для элементарного мониторинга значений входов-выходов приходиться писать вызовы библиотечных функций. О таких приемах как «горячая» замена кода прикладной программы без остановки контроллера вообще нужно забыть. Помимо этого автоматы и задачи с битовыми операциями реализуются в C++ достаточно сложно.

Стандарт "Программируемые контроллеры" (МЭК 61131) - это международный стандарт, который был опубликован в 1993 году и широко используется разработчиками и Пользователями.

Рынок средств автоматизации наводнен промышленными контроллерами самых различных производителей следующих известных фирм: ABB, Allen-Breadley, Honeywell, Omron, PEP Modular Computers и многих других. Общим для контроллеров этих фирм выступает "язык общения". Программное обеспечение для них разрабатывается в соответствии со стандартом на языковые конструкции (языки программирования ПЛК - PLC), определенные в части 3 стандарта МЭК 61131. По разным оценкам до 80 % ПЛК рынка обслуживается программными продуктами, реализующими в той или иной мере этот стандарт.

МЭК 61131-3 определяет три уровня совместимости инструментальных систем:

базовый уровень (Base Level);

уровень переносимости функции (Portability Level); уровень переносимости приложений (Application Level).

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

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

Стандарт МЭК 61131-3 определяет два компонента:

общие элементы; собственно языки программирования.

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

Вторая часть стандарта посвящена описанию мнемоники стандартных языков программирования контроллеров: SFC, FBD, LD, ST и IL.

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

Третья часть этого стандарта, определяет мнемонику языков программирования.

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

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

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

Рисунок 11 - Язык последовательных функциональных схем

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

Язык последовательных функциональных схем (Sequential Function Charts или Grafcet) позволяет формулировать логику программы на основе чередующихся процедурных шагов и транзакций (условных переходов), а также описывать последовательно-параллельные задачи в понятной и наглядной форме.

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

Основные достоинства SFC:

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

предварительное проектирование программного обеспечения. 2) Язык функциональных блоков FBD.

Язык функциональных блоков (Function Block Diagrams) позволяет создать программную единицу практически любой сложности на основе стандартных кирпичиков (арифметические, тригонометрические, логические блоки; ПИД-регуляторы; блоки, описывающие некоторые законы управления; мультиплексоры и т.д. (рис. 12)).

Рисунок 12 - Язык функциональных блоков

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

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

Язык релейных диаграмм или релейной логики (Ladder Diagrams), применяется для описания логических выражений различного уровня сложности и использует в качестве базовых элементов программирования. Графические элементы "контакты" (contacts) и "катушки" (coils) связаны с входными и выходными каналами, соответственно (рис. 13).

Рисунок 13 - Язык релейных диаграмм

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

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

Язык структурированного текста (Structured Text) относится к классу текстовых языков высокого уровня, его корни в таких известных языках программирования, как ADA, PASCAL и С. На основе этого языка можно создавать гибкие процедуры обработки данных (рис. 14).

C:= A AND NOT B

Рисунок 14 - Язык структурированного текста

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

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

До 1993 года практически каждый ПЛК сопровождался своим АССЕМБЛЕРОМ. Выросли целые поколения программистов, ориентированных на определенные виды микропроцессоров. Освоение новой техники сталкивалось с проблемой освоения очередного языка программирования под новый кристалл. Отдельные мнемонические конструкции АССЕМБЛЕРОВ были похожи, но о каком-либо стандарте не было и речи.

Появление языка инструкций (Instruction List) в наборе стандартных языков - это унификация интерфейса языка программирования низкого уровня, не ориентированного на какую-либо микропроцессорную архитектуру (рис. 15).

LD

A

ANDN

B

ST

C