Лекция 10. Состав СПА Средства АСУ ТП (Программного управления интегрирующие).

10.1. Общая характеристика программного обеспечения

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

1) автоматизация управления технологическими процессами (АСУ ТП);

2) взаимодействие системы с диспетчером (оператором);

3) автоматизированный контроль и измерения (мониторинг);

4) обеспечение безопасности;

5) дистанционное управление, измерение, сигнализация (задачи телемеханики).

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

1) ОРС сервер;

2) средства МЭК-программирования контроллеров;

3) SCADA-пакеты.

Для систем автоматизации, не связанных с АСУ ТП, используются программы LabVIEW, MATLAB, HP-VEE и др., ориентированные на автоматизацию эксперимента, измерений или математическую обработку их результатов. Для простых задач или широко тиражируемых приложений бывает экономически эффективно использовать заказное программирование на С++ или Visual Basic с применением покупных ActiveX элементов, снижающих трудоемкость разработки.

10.2. Развитие программных средств интегрирующей автоматизации

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

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

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

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

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

4) требованиями совместимости с другими СА, работающими на том же предприятии (были необходимы стандартные интерфейсы между программами, созданными разными производителями на разных аппаратно-программных платформах);

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

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

В настоящее время заказные программы естественным путем вытеснены с рынка ПА SCADA-пакетами и аналогичными универсальными средствами автоматизации, а также средствами программирования контроллеров на языках стандарта МЭК 61131-3.

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

SCADA-пакеты не смогли занять сегмент рынка простых систем, которые не требуют предварительного изучения или настройки и построены по принципу «Plug&Play» - «вставил и заиграло». Подобные программы уже не могут быть такими универсальными и функционально насыщенными, как SCADA. Они являются специализированными, ориентированными на узкий круг задач отображения графиков или простейшего управления с небольшим количеством тегов. Примером такой простой программы может служить RLDataView (НИЛ АП).

Экономически целесообразно осталось также разрабатывать заказные программы для серийно тиражируемых, однотипных СА, например систем контроля температуры в силосах элеваторов. Для упрощения и повышения качества заказного программирования широко используются ActiveX элементы, специально разработанные для задач автоматизации: для построения графиков, органов управления и индикации, для отображения технологических схем. Такие системы создаются на языках визуального программирования Visual С++, Visual Basic, VBA, Delphi.

10.3. Графическое программирование

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

Настоящую революцию в программировании СА сделали языки графического программирования. Одним из первых в этом классе был графический язык среды Simulink, входящей в состав MATLAB (MathWorks Inc), а также языки LabVIEW (National Instruments) и HP-VEE (Hewlett Packard). Они были предназначены и успешно использовались для сбора данных, моделирования СА, автоматического управления, обработки собранных данных и их визуального представления в виде графиков, таблиц, звука, с помощью компьютерной анимации. Графические языки были настолько простыми и естественными, что для их освоения зачастую было достаточно метода проб и ошибок без использования учебников и консультаций. Человек, не знакомый с программированием на алгоритмических языках, пользуясь только логикой и понимая постановку прикладной задачи, мог собрать работающее приложение из готовых компонентов, набрасывая их мышкой на экран монитора и проводя графические связи для указания потоков информации.

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

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

10.4. Графический интерфейс

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

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

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

отсутствие «сюрпризов»: знакомые из прошлого опыта операции с элементами на экране должны вызывать знакомые реакции системы;

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

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

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

10.5. Открытость программного обеспечения

Программные средства автоматизации должны удовлетворять требованиям открытости. Для этого они должны поддерживать:

1) стандартные средства программирования МЭК 61131-3;

2) стандарт ОРС для информационной связи с физическими устройствами;

3) стандартные сетевые протоколы Ethernet, Modbus, Profibus, CAN и др.;

4) стандартный интерфейс ODBC для доступа к базам данных с языком запросов SQL;

5) наиболее распространенные операционные системы(ОС) (Windows ХР/СЕ, Linux);

6) веб-технологию;

7) обмен данными с Microsoft Office.

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

10.6. Информационная связь с физическими устройствами

Информационная связь с физическими устройствами в СА осуществляется с помощью методов DDE, OLE, COM, DCOM и OPC.

Технология обмена данными между приложениями Windows с аббревиатурой DDE (Dynamical Data Exchange - динамический обмен данными) появилась в 1987 г. вместе с Windows 2.0. В ПА DDE использовалась для обмена данными между SCADA в качестве DDE-клиента и физическим устройством, которое поставлялось с DDE-сервером.

После появления OLE (Object Linking and Embedding - связывание и внедрение объектов) фирмы Microsoft, а позже COM (Component Object Model - модель многокомпонентных объектов) и DCOM (Distributed СОМ - СОМ для распределенных систем) технология DDE была полностью вытеснена этими новыми средствами, которые оказались гораздо более эффективными.

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

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

Одной из составляющих СОМ является Automation* - средства взаимодействия программ, написанных на С++ с программами на языке VBA (Visual Basic for Application) или Delphi, а также с программами на языках сценариев (VBScript, JScript). Благодаря автоматизации СОМ-объект может быть также размещен и исполняться на веб-странице.

Расширение СОМ в виде DCOM позволяет программам взаимодействовать между собой, даже если они исполняются на разных компьютерах локальной сети. Поэтому DCOM явилась универсальной программной технологией, которая как нельзя лучше позволяет осуществить взаимодействие между SCADA в качестве клиента и сервером, обеспечивающим интерфейс к аппаратным средствам ПА. Именно благодаря этому свойству DCOM была использована в качестве базы для разработки стандарта ОРС « OLE for Process Control» - «OLE для управления процессами», который лежит в основе всех современных SCADA-пакетов, взаимодействующих с аппаратурой через ОРС-сервер.

10.7. Базы данных

СА работают с большими объемами данных, которые необходимо хранить, сортировать, группировать, извлекать и представлять в виде, удобном для пользователя. Данные извлекаются с помощью языка запросов SQL (Structured Query Language - структурированный язык запросов), который стал стандартом в СА. Наиболее распространенными системами управления базами данных (СУБД) являются Microsoft SQL Server, Wonderware Industrial SQL Server, Microsoft Access и Excel.

Основными свойствами СУБД являются:

1) наличие пользовательского интерфейса на базе языка запросов SQL;

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

Открытые системы используют обращение к СУБД через драйвер ODBC (Open Database Connectivity - подключение к открытой базе данных). ODBC используется, когда необходимо обеспечить независимость прикладной программы от типа СУБД или типа ОС и требуется подключиться к нескольким различным СУБД (например, одновременно к MS SQL Server, MS Excel, MS Access, Paradox и др.). При использовании нескольких ODBC-драйверов ими управляет менеджер драйверов. ODBC-драйвер транслирует стандартный SQL-запрос в формат запроса для конкретной СУБД. Таким образом, для работы с новой базой данных пользователю достаточно добавить в систему новый ODBC-драйвер, не изменяя прикладную программу.

10.8. Операционные системы реального времени

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

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

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

ОС жесткого РВ - гарантирует выполнение задачи за заранее известное время.

ОС мягкого РВ - реализует особые меры для устранения неопределенности времени выполнения, однако полностью неопределенность не устраняется.

Стандарт POSIX (Portable Operating System Interface for Computer Environments) IEEE 1003.1 даёт следующее определение РВ: способность ОС обеспечить требуемый уровень сервиса в определённый промежуток времени. Следовательно, ОС РВ отличаются своим поведением, а не внутренним принципом построения. Поэтому если вероятность появления недопустимо больших задержек достаточно низка для достижения требуемого уровня сервиса (например, если она меньше допустимой вероятности отказа системы), то такая ОС в конкретном применении может рассматриваться как ОС РВ. В частности, в соответствии с POSIX ОС Windows ХР при управлении медленными (тепловыми) процессами может рассматриваться как ОС РВ.

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

Базовые требования для обеспечения режима РВ:

1) высокоприоритетные задачи всегда должны выполняться в первую очередь;

2) должна быть исключена инверсия приоритетов;

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

Инверсия приоритетов - ситуация, когда поток с высоким приоритетом требует предоставления ресурса, который уже занят потоком с более низким приоритетом. Получается, что высокоприоритетный поток стоит в очереди, в то время как исполняется низкоприоритетный (происходит «инверсия приоритетов»). Такая ситуация возможна, если имеется поток со средним приоритетом, который блокирует завершение выполнение потока с низшим приоритетом, а поток с высшим приоритетом не может начаться, поскольку захвачен необходимый ему ресурс. Основным методом решения этой проблемы в ОС РВ является наследование приоритетов: если низкоприоритетный поток блокирует выполнение нескольких высокоприоритетных потоков, то низкоприоритетный поток игнорирует назначенный ему первоначально приоритет и выполняется с приоритетом, который поток принимает свой первоначальный приоритет.

Для обеспечения режима РВ в ОС могут быть реализованы следующие требования:

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

2) возможность наследования приоритетов;

3) возможность вытеснения задач ядром ОС;

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

5) выполнение сервисов ОС с приоритетом, который назначается клиентом сервиса.

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

Наиболее распространенными в ПЛК и компьютерах для решения задач автоматизации являются ОС Windows СЕ, QNX Neutrino и OS-9.

Windows CE.NET. Многозадачная ОС жесткого РВ корпорации Microsoft поддерживает микропроцессоры с архитектурой ARM, StrongARM и xScale, MIPS, SH, Х86-совместимые и имеет следующие свойства:

1) допускает одновременное выполнение до 32 процессов;

2) имеет 256 уровней приоритетов;

3) поддерживает вытесняющую многозадачность;

4) обеспечивает карусельное исполнение цепочек с одинаковым приоритетом;

5) поддерживает вложенные прерывания;

6) имеет среднее время обработки прерывания 2,8 мкс (на Pentium 166 МГц), поддерживает вложенные прерывания;

7) обеспечивает время обработки потока прерываний (Interrupt Service Thread, 1ST), равное 17,9 мкс (на Pentium 166 МГц);

8) в минимальной конфигурации может быть установлена при объеме ОЗУ 200 Кб.

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

Windows CE.NET поддерживает Microsoft Visual Studio.NET и Microsoft eMbedded Visual С++ с языками программирования Visual С++, Visual С# и Visual Basic.NET.

QNX Neutrino (корп QNX Software Systems) - ОС РВ и обеспечивает многозадачный режим с приоритетами. Поддерживает микропроцессоры семейств ARM, StrongARM, xScale, x86, MIPS, PowerPC, SH-4.

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

Инверсия приоритетов преодолевается с помощью распределенного наследования приоритетов.

OS-9. (Microware System) - многозадачная и многопользовательская, работает в режиме мягкого РВ. Используется во встраиваемых приложениях на платформах ARM, StrongARM, MIPS, PowerPC, Hitachi SuperH, x86, Pentium, XScale, Motorola 68K.

10.9. Состав ПА. ОРС-стандарт

Стандарт OPC - разработан международной организацией ОРС Foundation членами которой являются более 400 фирм, работающих в области СА и измерительной техники. Основатели - фирмы Fisher-Rosemount, Rockwell Software, Opto 22, Intellution и Intuitive Technology. Первая версия стандарта OPC выпущена в 1998 г. В совет директоров OPC Foundation в 2008 году входили представители Siemens AG, Emerson Process Management, Yokogawa, Honeywell, Rockwell Automation, ICONICS.

Главная цель стандарта OPC - обеспечение возможности совместной работы (интероперабельности) СА, функционирующих на разных аппаратных платформах, в разных промышленных сетях и производимых разными фирмами. До разработки стандарта ОРС SCADA-пакет нужно было адаптировать к каждому новому оборудованию индивидуально. Существовали длинные списки «поддерживаемого оборудования», очень сложной была техническая поддержка. При модификации оборудования нужно было вносить изменения во все драйверы, каждый из которых поддерживал протокол обмена только с одной клиентской программой. Число таких драйверов доходило до сотен.

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

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

ОРС-сервер как средство взаимодействия с техническим устройством может быть использован при разработке заказных программ на С++, Visual Basic, VBA, Delphi и т.п. В этих задачах ОРС-сервер используется как Microsoft DCOM-объект, от которого он отличается только стандартизацией обозначений и специфическими терминами из области ПА. Применение ОРС-сервера при разработке заказных программ позволяет скрыть от разработчика всю сложность общения с аппаратурой, представляя простой и удобный метод доступа к аппаратуре через интерфейсы СОМ-объекта.

Стандарт ОРС состоит из нескольких частей:

1) ОРС DA (ОРС Data Access) - спецификация обмена данными между клиентом (например SCADA) и аппаратурой (контроллерами, модулями в/в и др.) в реальном времени;

2) ОРС Alarms & Events (А&Е) - спецификация уведомления клиента о событиях и сигналах тревоги, которые посылаются клиенту по мере их возникновения (пересылает аварийные сигналы, действия оператора, информационные сообщения, результаты контроля состояния системы);

3) ОРС HDA (Historical Data Access) - спецификация доступа к предыстории процесса (к сохраненным в архиве данным) (обеспечивает унифицированный способ доступа с помощью DCOM технологии. Обеспечивает чтение, запись и изменение данных);

4) ОРС Batch - спецификация особых физико-химических ТП обработки материалов, которые не являются непрерывными (в таких процессах выполняется загрузка нескольких видов сырья в определенных пропорциях согласно рецепту, устанавливаются режимы обработки, а после выполнения цикла обработки и выгрузки готового материала загружается новая партия сырья. ОРС-сервер выполняет обмен между клиентом и сервером рецептами, характеристиками технологического оборудования, условиями и результатами обработки);

5) ОРС Data eXchange - спецификация обмена данными между 2-мя ОРС DA-серверами через сеть Ethernet;

6) ОРС Security - спецификация, определяющая методы доступа клиентов к серверу и обеспечивающая защиту важной информации от несанкционированной модификации;

7) ОРС XML-DA - набор гибких, согласующихся друг с другом правил и форматов для представления первичных данных с помощью языка XML, веб технологий и сообщений SOAP;

8) OPC Complex Data - дополнительные спецификации к ОРС DA и XML- DA, позволяющие серверам работать со сложными типами данных, такими как бинарные структуры и XML-документы;

9) ОРС Commands - набор программных интерфейсов, позволяющих ОРС клиентам и серверам идентифицировать, посылать и контролировать команды, исполняемые в техническом устройстве (в контроллере, модуле в/в);

10) ОРС Unified Architecture - принципиально новый набор спецификаций, который уже не базируется на DCOM технологии. Из перечисленных спецификаций в России широко используются только две: ОРС DA и реже - ОРС HDA.

10.10. ОРС DA-сервер

Сервер ОРС DA - наиболее широко используетсмя в ПА. Обеспечивает обмен данными (запись и чтение) между клиентской программой и физическими устройствами. Данные состоят из 3-х полей: значение, качество и временная метка. Параметр качества данных позволяет передать от устройства клиентской программе информацию о выходе измеряемой величины за границы динамического диапазона, об отсутствии данных, ошибке связи и другие.

Существуют 4 стандартных режима чтения данных из ОРС-сервера:

1) синхронный режим: клиент посылает запрос серверу и ждет от него ответ,

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

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

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

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

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

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

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

ОРС DA-сервер может иметь (не обязательно) пользовательский интерейс, который позволяет выполнять любые вспомогательные функции для облегчения работы с оборудованием. Например, ОРС-сервер NLopc (НИЛ АП) позволяет, помимо обмена данными со SCADA, выполнять следующие полезные функции:

1) поиск подключенного к промышленной сети оборудования;

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

3)создание иерархического представления имен тегов;

4) наблюдение значений тегов;

5) управление правами доступа к ОРС-серверу.

Рис.10.1.Простой пример взаимодействия прикладных программ и физических устройств через ОРС-сервер на одном компьютере

В соответствии со стандартом, ОРС-сервер во время инсталляции автоматически регистрируется в реестре Windows. Запуск сервера осуществляется так же, как любой другой программы, или автоматически из клиентской программы.

Примеры архитектуры систем, включающих ОРС-серверы и ОРС-клиентов, показаны на рис. 10.1 и 10.2. В качестве ОРС-клиента может выступать программа на языке С++ (например, SCADA-пакет) или программа на языке Visual Basic, VBA, Delphi или любая другая программа, поддерживающая внедрение СОМ-объектов (рис. 10.1). Программа на языке С++ взаимодействует с ОРС-сервером через интерфейс ОРС Custom, а программа на Visual Basic, VBA, Delphi - через интерфейс автоматизации ОРС Automation. ОРС-сервер и ОРС-клиенты могут работать только на компьютерах и контроллерах с ОС, поддерживающими технологию DCOM (например, Windows ХР и Windows СЕ).

ОРС-сервер подключается к физическим устройствам любым способом; эти способы стандартом не предусмотрены. Например, сервер NLopc (НИЛ АП) использует для каждого физического устройства свой драйвер (рис. 10.2).

Клиентская программа и ОРС-сервер могут быть установлены на одном и том же компьютере, как показано на рис. 10.1, или на разных компьютерах сети Ethernet (рис. 9.2). При наличии нескольких компьютеров каждый из них может содержать ОРС-сервер и подключенный к нему физические устройства.

Рис.10.2.Пример применения ОРС-технологии для сетевого доступа к данным в СА

В такой системе любой ОРС-клиент с любого компьютера может обращаться к любому ОРС-серверу, в том числе к расположенному на другом компьютере сети. Это достигается благодаря технологии DCOM, использующей удаленный вызов процедур (RPC - Remote Procedure Call). Например, SCADA на рис. 10.2 может обратиться за данными к модулю в/в по пути, указанному на рис. 10.2 штриховой линией. Компьютеры и контроллеры в такой архитектуре могут работать с разными промышленными сетями. Обмен данными с ПЛК, работающими с ОС Windows СЕ, выполняется точно так, как с компьютерами.

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

10.11. ОРС HDA-сервер

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

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

Существует 2 типа HDA-серверов:

1) простой сервер данных предыстории для построения графиков (трендов);

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

Работа с данными заключается в чтении, записи или изменении данных.

10.12. Спецификация ОРС UA

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

1) доступность только на ОС семейства Microsoft Windows;

2) связь с технологией DCOM, исходные коды которой являются закрытыми.

Это:

1) не позволяет решать вопросы надежности ПО,

2) не позволяет выявлять и устранять возникающие программные отказы;

3) бывают проблемы конфигурирования, связанные с DCOM;

4) неточные сообщения DCOM о прерываниях связи;

5) неприспособленность DCOM для обмена данными через Интернет;

6) неприспособленность DCOM для обеспечения информационной безопасности.

В связи с этим в 2006г. ОРС Foundation предложил новую стандартную спецификацию для обмена данными в системах ПА, получившую название «ОРС Unified Architecture» - «ОРС с унифицированной архитектурой», которая рассматривается как ОРС-стандарт нового поколения.

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

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

ОРС UA использует несколько различных форматов данных, основным