9.1. Развитие программных средств автоматизации
Для решения перечисленных выше задач первоначально использовались универсальные языки программирования высокого уровня и команда профессиональных программистов. Однако практика показала крайне низкую эффективность такой разработки. Оказалось, что разработка системы должна выполняться не программистами, а специалистами той предметной области, которая нуждается в автоматизации, т. е. технологами, а также системными интеграторами, которые осуществляют комплексное внедрение системы.
Необходимость в разработке средств программирования, предназначенных специально для систем автоматизации и ориентированных на технологов, была вызвана следующими причинами:
- требованием надежности программного обеспечения. Система, написанная целиком на алгоритмическом языке для конкретного заказа, содержала слишком много программного кода, на тщательную разработку и тестирование которого не хватало времени;
- сжатыми сроками внедрения системы и ограниченной стоимостью работ. Для создания системы в короткий срок при ограниченном бюджете требовалось большое количество готовых универсальных программных компонентов, уже написанных и тщательно оттестированных;
- необходимостью модификации системы в процессе ее эксплуатации. Внести изменения в специализированную программу мог только написавший ее программист, который к этому времени обычно работал уже на другом предприятии. Поэтому вместо того, чтобы модифицировать программное обеспечение, его приходилось переписывать заново;
- требованиями совместимости с другими системами автоматизации, работающими на том же предприятии. Были необходимы стандартные интерфейсы между программами, созданными разными производителями на разных аппаратно-программных платформах;
- высокими требованиями к качеству пользовательского интерфейса. Ограниченный бюджет времени и финансовых ресурсов не позволял разработать достаточно хороший программный интерфейс на универсальных алгоритмических языках.
Разделение труда по созданию программных средств автоматизации
Перечисленные причины привели к следующему разделению труда по созданию программных средств для систем автоматизации: фирмы, специализирующиеся на программном обеспечении, создают универсальные системы программирования задач автоматизации (SCADA-пакеты и средства МЭК-программирования), а инжиниринговые фирмы (системные интеграторы [Куцевич]) адаптируют эти средства к нуждам конкретного заказчика. В результате достигается решение всех перечисленных выше проблем. Более того, благодаря существенному упрощению процесса адаптации по сравнению с классическим программированием изменения в алгоритмы управления могут быть внесены, например, технологом эксплуатирующей организации без привлечения системных интеграторов или программистов.
В настоящее время заказные программы естественным путем вытеснены с рынка промышленной автоматизации SCADA-пакетами и аналогичными универсальными средствами автоматизации, а также средствами программирования контроллеров на языках стандарта МЭК 61131-3 [Lewis, Петров].
Заказные и специализированные программные средства автоматизации
В силу своей универсальности SCADA-пакеты оказались слишком дорогими для применения в простых задачах, когда, например, необходимо записать в компьютер несколько значений температуры или сделать один контур управления температурой в термошкафе. Эту проблему частично удается решить введением зависимости цены SCADA-пакетов от количества тегов, однако остается нерешенной проблема трудоемкости изучения и сложности адаптации SCADA к простым задачам, а также высокая стоимость консультаций по применению. SCADA-пакеты не смогли занять сегмент рынка простых систем, которые не требуют предварительного изучения или настройки и построены по принципу " Plug&Play" - "вставил - и заиграло". Подобные программы уже не могут быть такими универсальными и функционально насыщенными, как SCADA. Они являются специализированными, ориентированными на узкий круг задач отображения графиков или простейшего управления с небольшим количеством тегов. Примером такой простой программы может служить RLDataView фирмы RealLab!.
Экономически целесообразно осталось также разрабатывать заказные программы для серийно тиражируемых, однотипных систем автоматизации, например, систем контроля температуры в силосах элеваторов [Бабенко]. Для упрощения и повышения качества заказного программирования широко используются ActiveX элементы, специально разработанные для задач автоматизации: для построения графиков, органов управления и индикации, для отображения технологических схем [Денисенко]. Такие системы создаются на языках визуального программирования Visual C++, Visual Basic, VBA, Delphi.
9.1.1. Графическое программирование
Языки визуального программирования появились в начале 90-х годов и содержат большое число стандартных функций и библиотек, а также готовых средств визуализации. Они позволяют создавать очень удобные и эффектные программы, однако достигается это за счет резкого увеличения объема программного кода. Поэтому языки визуального программирования, как и текстовые, по-прежнему не позволяют модифицировать алгоритмы силами технологов без участия профессиональных программистов.
Настоящую революцию в программировании систем автоматизации сделали языки графического программирования. Одним из первых в этом классе был графический язык среды Simulink, входящей в состав Matlab (MathWorks Inc), а также языки LabVIEW (National Instruments) и HP-VEE (Hewlett Packard). Они были предназначены и успешно использовались для сбора данных, моделирования систем автоматизации, автоматического управления, обработки собранных данных и их визуального представления в виде графиков, таблиц, звука, с помощью компьютерной анимации. Графические языки были настолько простыми и естественными, что для их освоения зачастую было достаточно метода проб и ошибок без использования учебников и консультаций. Человек, не знакомый с программированием на алгоритмических языках, пользуясь только логикой и понимая постановку прикладной задачи, мог собрать работающее приложение из готовых компонентов, набрасывая их мышкой на экран монитора и проводя графические связи для указания потоков информации.
Первые языки программирования алгоритмов работы систем автоматизации были нестандартными. Каждая фирма, создававшая контроллер или SCADA-пакет, предлагала свой язык. Это требовало от системных интеграторов дополнительных усилий и затрудняло освоение новых SCADA пакетов и средств программирования контроллеров.
Поэтому появление в 1993 году стандарта на языки программирования контроллеров МЭК 61131-3 [IEC] было большим шагом в направлении создания открытых систем автоматизации и обеспечило снижение стоимости разработки, сокращение сроков, повышение качества реализации алгоритмов автоматизации и возможность детального изучения языков программирования, пригодных для любого контроллера. МЭК 61131-3 устанавливал стандарты для пяти языков программирования, рассчитанных на специалистов разных профессий, не связанных с программированием.
9.1.2. Графический интерфейс
Создание графических интерфейсов пользователя на компьютере явилось большим достижением в направлении развития средств диспетчерского управления. Главным эффектом от применения графического интерфейса является существенное снижение количества ошибок, допускаемых оператором (диспетчером) в стрессовых ситуациях при управлении производственными процессами. Проектирование пользовательского интерфейса основано на следующих принципах [Wang]:
- узнаваемость: назначение элементов экрана должно быть понятно без предварительного обучения, допустимые манипуляции с этими элементами также должны быть понятны интуитивно. Пользовательский интерфейс не должен содержать излишней детализации;
- логичность: пользователь, имеющий опыт работы с одной программой, должен быть способен быстро, практически без обучения, адаптироваться к любой аналогичной программе;
- отсутствие "сюрпризов": знакомые из прошлого опыта операции с элементами на экране должны вызывать знакомые реакции системы;
- восстанавливаемость: система не должна быть чувствительна к ошибкам оператора. Оператор должен иметь возможность отменить любое свое неправильное действие. Для этого используются многократные подтверждения, отмены, возврат на несколько шагов назад, установка контрольных точек и т. п.;
- наличие удобной справки, подсказок, встроенных в пользовательский интерфейс, средств контекстного поиска и замены;
- адаптация к опыту пользователя: начинающий пользователь должен иметь более простой интерфейс с большим количеством подсказок. Для опытного пользователя количество подсказок должно быть уменьшено, поскольку они мешают в работе.
9.1.3. Открытость программного обеспечения
Программные средства автоматизации должны удовлетворять требованиям открытости (см. "Понятие открытой системы" 1). Для этого они должны поддерживать:
- стандартные средства программирования МЭК 61131-3;
- стандарт ОРС для связи с физическими устройствами;
- стандартные сетевые протоколы Ethernet, Modbus, Profibus, CAN и др.;
- стандартный интерфейс ODBC для доступа к базам данных c языком запросов SQL;
- наиболее распространенные операционные системы (Windows XP/CE, Linux);
- веб-технологию;
- обмен данными с Microsoft Office.
Перечисленные средства удовлетворяют общепризнанным или официальным стандартам, имеются в свободной продаже, разрабатываются несколькими независимыми производителями, конкурирующими между собой (последнее не касается MS Windows и MS Office).
9.1.4. Связь с физическими устройствами
Связь программного обеспечения с физическими устройствами в системах автоматизации осуществляется с помощью методов 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 COM - "СОМ для распределенных систем") [Круглински] технология DDE была полностью вытеснена этими новыми средствами, которые оказались гораздо более эффективными.
Технология COM предоставляет средства для взаимодействия между разрозненными программными модулями, написанными на разных языках программирования, которые собираются в единую систему во время исполнения. Взаимодействие COM объекта с другими программами или программными модулями выполняется через программные интерфейсы c использованием метода "клиент-сервер".
Одной из составляющих COM является Automation - средства взаимодействия программ, написанных на С++ с программами на языке VBA (Visual Basic for Application) или Delphi, а также с программами на языках сценариев (VBScript, JScript). Благодаря автоматизации COM-объект может быть также размещен и исполняться на веб-странице.
Расширение COM в виде DCOM позволяет программам взаимодействовать между собой, даже если они исполняются на разных компьютерах локальной сети. Поэтому DCOM явилась универсальной программной технологией, которая как нельзя лучше позволяет осуществить взаимодействие между SCADA в качестве клиента и сервером, обеспечивающим интерфейс к аппаратным средствам промышленной автоматизации. Именно благодаря этому свойству DCOM была использована в качестве базы для разработки стандарта OPC [Iwanitz] - "OLE for Process Control" - "OLE для управления процессами", который лежит в основе всех современных SCADA пакетов, взаимодействующих с аппаратурой через OPC сервер.
9.1.5. Базы данных
Системы автоматизации работают с большими объемами данных, которые необходимо хранить, сортировать, группировать, извлекать и представлять в виде, удобном для пользователя. Данные извлекаются с помощью языка запросов SQL (Structured Query Language - "структурированный язык запросов"), который стал стандартом в системах автоматизации. Наиболее распространенными системами управления базами данных (СУБД) являются Microsoft SQL Server, Wonderware Industrial SQL Server, Microsoft Access и Excel. Основными свойствами СУБД являются:
- наличие пользовательского интерфейса на базе языка запросов SQL;
- возможность одновременного обслуживания нескольких пользователей;
- корректность работы с данными.
Открытые системы используют обращение к СУБД через драйвер ODBC (Open Database Connectivity - "подключение к открытой базе данных"). ODBC используется, когда необходимо обеспечить независимость прикладной программы от типа СУБД или типа операционной системы и требуется подключиться к нескольким различным СУБД (например, одновременно к MS SQL Server, MS Excel, MS Access, Paradox и др.). При использовании нескольких ODBC драйверов ими управляет менеджер драйверов. ODBC драйвер транслирует стандартный SQL запрос в формат запроса для конкретной СУБД. Таким образом, для работы с новой базой данных пользователю достаточно добавить в систему новый ODBC драйвер, не изменяя прикладную программу.
9.1.6. Операционные системы реального времени
Быстродействие ПЛК или компьютера влияет на величину динамической погрешности системы автоматизации и запас ее устойчивости при наличии обратной связи. Для улучшения этих характеристик используют быстродействующие модули ввода-вывода и компьютер (ПЛК) с высокопроизводительным процессором. Это позволяет улучшить динамические характеристики системы, однако большинство операционных систем (ОС) не могут обеспечить одно и то же время выполнения задачи при повторных ее запусках, т. е. время выполнения является случайной величиной. В некоторых случаях непредсказуемость времени исполнения задачи приводит к отказу системы.
Пусть, к примеру, автомат подсчитывает количество бутылок на конвейере. Если бутылки появляются напротив датчика с периодом 1 с, а время реакции системы на появление бутылки составляет 0,7 с, то система кажется работоспособной. Однако, если задержка является случайной величиной, то в некоторый момент времени она может оказаться больше 1 с, что приведет к появлению случайной ошибки в количестве бутылок, т.е. к отказу системы. Величина ошибки определяется статистической функцией распределения случайных задержек.
Для устранения этой проблемы был разработан класс операционных систем, которые обеспечивают детерминированное (т.е. не случайное) время выполнения задач и время реакции на аппаратные прерывания. Такие ОС получили название операционных систем реального времени ОС РВ) [Galvin] и были поделены на ОС жесткого и мягкого реального времени. Отличительным признаком ОС РВ является не время выполнение задач, а гарантированность постоянства величины этого времени для одной и той же задачи.
ОС жесткого реального времени гарантирует выполнение задачи за заранее известное время. В ОС мягкого реального времени приняты особые меры для устранения неопределенности времени выполнения, однако полностью неопределенность не устраняется.
Стандарт IEEE 1003.1 даёт следующее определение РВ: "Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени". Следовательно, ОС РВ отличаются своим поведением, а не внутренним принципом построения. Поэтому если вероятность появления недопустимо больших задержек достаточно низка для достижения требуемого уровня сервиса (например, если она меньше допустимой вероятности отказа системы), то такая ОС в конкретном применении может рассматриваться как ОС РВ. В частности, в соответствии с определением стандарта POSIX операционная система Windows XP при управлении медленными (тепловыми) процессами может рассматриваться как ОС РВ.
Тем не менее, существуют определенные методы построения операционных систем, которые обеспечивают прямоугольную плотность распределения вероятности задержки и поэтому относятся к ОС жесткого реального времени независимо от уровня предоставляемого сервиса. В ОС жесткого РВ процесс представляется на выполнение одновременно с указанием требуемого времени выполнения [Galvin]. Планировщик ОС либо разрешает выполнение, гарантируя требуемое время, либо отклоняет процесс как невозможный для исполнения. Для этого планировщик должен точно знать, сколько времени требуется каждой функции ОС для выполнения задачи.
Базовыми требованиями для обеспечения режима реального времени являются следующие [Furr]:
- высокоприоритетные задачи всегда должны выполняться в первую очередь;
- должна быть исключена инверсия приоритетов (см. ниже);
- процессы и потоки, время выполнения которых нельзя планировать, никогда не должны полностью занимать ресурсы системы.
Инверсией приоритетов называют ситуацию, когда поток с высоким приоритетом требует предоставления ресурса, который уже занят потоком с более низким приоритетом. Получается, что высокоприоритетный поток стоит в очереди, в то время как исполняется низкоприоритетный (происходит "инверсия приоритетов"). Такая ситуация возможна, если имеется поток со средним приоритетом, который блокирует завершение выполнение потока с низшим приоритетом, а поток с высшим приоритетом не может начаться, поскольку захвачен необходимый ему ресурс. Основным методом решения этой проблемы в ОС РВ является наследование приоритетов [Jean J. Labrosse], которое заключается в следующем. Если низкоприоритетный поток блокирует выполнение нескольких высокоприоритетных потоков, то низкоприоритетный поток игнорирует назначенный ему первоначально приоритет и выполняется с приоритетом, который является наивысшим в блоке ожидающих его потоков. После окончания работы поток принимает свой первоначальный приоритет.
Для обеспечения режима реального времени в ОС могут быть реализованы следующие требования [Furr, Jean J. Labrosse]:
- поддержка динамических приоритетов (которые можно менять в процессе выполнения задачи) в многозадачном режиме с вытесняющим ядром (как для процессов, так и для потоков);
- возможность наследования приоритетов;
- возможность вытеснения задач ядром ОС;
- ограниченная латентность прерываний (время, в течение которого прерывание запрещено - на время обработки критической секции кода);
- выполнение сервисов ОС с приоритетом, который назначается клиентом сервиса.
В системах РВ обычно отсутствует виртуальная память, поскольку этот метод использует подкачку страниц с диска, время выполнения которой является непредсказуемым.
Наиболее распространенными в ПЛК и компьютерах для решения задач автоматизации являются операционные системы Windows CE, QNX Neutrino и OS-9.
Windows CE.NET
Многозадачная операционная система жесткого реального времени Windows CE.NET корпорации Microsoft поддерживает микропроцессоры с архитектурой ARM, StrongARM и xScale, MIPS, SH, X86-совместимые и имеет следующие свойства:
- допускает одновременное выполнение до 32 процессов;
- имеет 256 уровней приоритетов;
- поддерживает вытесняющую многозадачность;
- обеспечивает карусельное исполнение цепочек с одинаковым приоритетом;
- поддерживает вложенные прерывания;
- имеет среднее время обработки прерывания 2,8 мкс (на Pentium 166 МГц), поддерживает вложенные прерывания;
- обеспечивает время обработки потока прерываний (Interrupt Service Thread, IST), равное 17,9 мкс (на Pentium 166 МГц);
- в минимальной конфигурации может быть установлена при объеме ОЗУ 200 Кб.
Ядро этой ОС принципиально отличается от ядра ОС для настольных компьютеров. В Windows CE.NET объединены все возможности систем реального времени и последние технологии Windows. Планирование выполняется на основе приоритетов, для устранения инверсии используется наследование приоритетов. Несмотря на наличие возможности работы с виртуальной памятью, для обеспечения режима жесткого реального времени ее отключают.
Windows CE .NET поддерживает Microsoft Visual Studio .NET и Microsoft eMbedded Visual C++ с языками программирования Visual C++, Visual C#, and Visual Basic .NET.
QNX Neutrino
QNX Neutrino корпорации QNX Software Systems является операционной системой реального времени и обеспечивает многозадачный режим с приоритетами [Цилюрик]. Поддерживает микропроцессоры семейств ARM, StrongARM, xScale, x86, MIPS, PowerPC, SH-4.
QNX относится к микроядерным ОС (т.е. реализует только базовые функции ядра - управление адресным пространством ОЗУ и виртуальной памяти, процессами и потоками, обеспечивает межпроцессорную коммуникацию). Состоит из ядра, планировщика процессов и сервисов. Построена на основе сервисов - небольших задач, выполняющих основные функции ОС. Такая структура позволяет отключить любую ненужную функциональность, не изменяя ядро. Каждый драйвер, приложение, протокол или файловая система выполняются вне ядра, в защищенном адресном пространстве.
Инверсия приоритетов преодолевается с помощью распределенного наследования приоритетов.
OS-9
Операционная система OS-9 фирмы Microware System является многозадачной и многопользовательской, работает в режиме мягкого реального времени. Используется во встраиваемых приложениях на платформах ARM, StrongARM, MIPS, PowerPC, Hitachi SuperH, x86, Pentium, XScale, Motorola 68K [Бурдонов].
|
|
