технологическими процессами
В типовой архитектуре SCADA-системы явно просматриваются два уровня:
уровень локальных контроллеров , взаимодействующих с объектом управления посредством датчиков и исполнительных устройств;
уровень оперативного управления технологическим процессом, основными компонентами которого являются серверы, рабочие станции операторов/диспетчеров, АРМ специалистов.
Каждый из этих уровней функционирует под управлением специализированного программного обеспечения (ПО). Разработка этого ПО или его выбор из предлагаемых в настоящее время на рынке программных средств зависит от многих факторов, прежде всего от решаемых на конкретном уровне задач.
Различаютбазовое иприкладное программное обеспечение (рис.1).
Рис. 1. Классификация программных средств системы управления.
Базовое ПО включает в себя различные компоненты, но основным из них является операционная система (ОС) программно-технических средств АСУТП. Каждый уровень АСУТП представлен «своими» программно-техническими средствами: на нижнем уровне речь идет о контроллерах, тогда как основным техническим средством верхнего уровня является компьютер. В соответствии с этим в кругу специалистов появилась и такая классификация: встраиваемое и настольное программное обеспечение.
Очевидно, требования, предъявляемые к встраиваемому и настольному ПО, различны. Контроллер в системе управления наряду с функциями сбора информации решает задачи автоматического непрерывного или логического управления. В связи с этим к нему предъявляются жесткие требования по времени реакции на состояние объекта и выдачи управляющих воздействий на исполнительные устройства. Контроллер должен гарантированно откликаться на изменения состояния объекта за заданное время.
Для решения подобных задач рекомендуется применение ОС реального времени (ОСРВ). Такие операционные системы иногда называют детерминированными, подразумевая под этим гарантированный отклик за заданный промежуток времени. Большинство микропроцессорных устройств (в том числе контроллеры и компьютеры) используют механизм прерываний работы процессора. В ОС реального времени, в отличие от ОС общего назначения (не гарантирующих времени исполнения), прерываниям присвоены приоритеты, а сами прерывания обрабатываются за гарантированное время.
Выбор ОС зависит от жесткости требований реального времени. Для задач, критичных к реакции системы управления, в настоящее время применяются такие операционные системы реального времени, как OS-9, QNX , VxWorks. В системах с менее жесткими требованиями к реальному времени возможно применение версий Windows NT/CE, точнее их расширений реального времени.
O S-9 относится к классу Unix-подобных операционных систем реального времени и предлагает многие привычные элементы среды Unix. Все функциональные компоненты OS-9, включая ядро, иерархические файловые менеджеры, систему ввода/вывода и средства разработки, реализованы в виде независимых модулей. Комбинируя эти модули, разработчик может создавать системы с самой разной конфигурацией - от миниатюрных автономных ядер, ориентированных на ПЗУ контроллеров, до полномасштабных многопользовательских систем разработки.
OS-9 обеспечивает выполнение всех основных функций операционных систем реального времени: управление прерываниями, межзадачный обмен информацией и синхронизация задач.
Операционная система QNX разработки канадской фирмы QNX Software Systems Ltd. является одной из наиболее широко используемых систем реального времени. QNX гарантирует время реакции в пределах от нескольких десятков микросекунд до нескольких миллисекунд (в зависимости от быстродействия ПЭВМ и версии QNX). Кроме того, высокая эффективность QNX в задачах управления в реальном времени обеспечивается такими свойствами, как многозадачность (до 250 задач на одном узле), встроенные в ядро системы сетевые возможности, гибкое управление прерываниями и приоритетами, возможность выполнения задач в защищенном и фоновом режимах.
Операционная система QNX нашла применение как на нижнем уровне АСУТП (ОС для контроллеров), так и на верхнем уровне (ОС для программного обеспечения SCADA).
Операционная система реального времени VxWorks предназначена для разработки ПО встроенных компьютеров, работающих в системах «жесткого» реального времени. К операционной системе VxWorks прилагается и инструментальная среда Tornado фирмы Wind River Systems со средствами разработки прикладного программного обеспечения. Его разработка ведется на инструментальном компьютере в среде Tornado для последующего исполнения на целевом компьютере (контроллере) под управлением VxWorks.
ОС VxWorks поддерживает целый ряд компьютерных платформ, в том числе Intel 386/486/Pentium, PowerPC, DEC Alpha. К платформам, поддерживаемым инструментальной средой Tornado, относятся Sun (Solaris), HP 9000/400,700, DEC Alpha, PC (Windows 95 и NT) и другие.
Операционная система Windows знакома всем как настольная система. Но это, прежде всего, относится к платформам Windows 3.хх/95, в которых действительно отсутствует поддержка реального времени. Ситуация резко изменилась с появлением Windows NT. Сама по себе Windows NT не является операционной системой реального времени в силу ряда ее особенностей. Система поддерживает аппаратные (а не программные) прерывания, отсутствует приоритетная обработка отложенных процедур и др. Но в конце ХХ века ряд фирм предприняли серьезные попытки превратить Windows NT в ОС жесткого реального времени. И эти попытки увенчались успехом. Компания VenturCom разработала модуль Real Time Extension (RTX) - подсистему реального времени (РВ) для Windows NT. Эта подсистема имеет собственный планировщик со 128 приоритетами прерываний, который не зависит от NT. Максимальное время реакции на прерывание составляет 20-80 мкс вне зависимости от загрузки процессора. Теперь при каждом прерывании от таймера приоритет передается критичным по времени задачам. А в оставшееся от их работы время могут выполняться «медленные» процессы: ввод/вывод, работа с диском, сетью, графическим интерфейсом и т. п.
32-разрядная Windows CE была создана компанией Microsoft для малых компьютеров (калькуляторов), но в силу ряда достоинств стала претендовать на роль стандартной ОС реального времени. К числу этих достоинств относятся:
открытость и простота стыковки с другими ОС семейства Windows;
время реакции порядка 500 мкс;
значительно меньшие по сравнению с другими ОС Windows требования к ресурсам памяти и возможность построения бездисковых систем.
А в 1999 году компанией Direct by Koyo ОС Windows CE была впервые установлена на платформу микроPLC.
Выбор операционной системы программно-технических средств верхнего уровня АСУТП определяется прикладной задачей (ОС общего пользования или ОСРВ). Но наибольшую популярность и распространение получили различные варианты ОС Windows (Windows NT/2000). Ими оснащены программно-технические средства верхнего уровня АСУТП, представленные персональными компьютерами (ПК) разной мощности и конфигурации - рабочие станции операторов/диспетчеров и специалистов, серверы баз данных (БД) и т. д.
Такая ситуация возникла в результате целого ряда причин и тенденций развития современных информационных и микропроцессорных технологий.
Вот несколько основных аргументов в пользу Windows:
Windows имеет очень широкое распространение в мире, в том числе и в России, в связи с чем легко найти специалиста, который мог бы сопровождать системы на базе этой ОС;
эта ОС имеет множество приложений, обеспечивающих решение различных задач обработки и представления информации;
ОС Windows и Windows-приложения просты в освоении и обладают типовым интуитивно понятным интерфейсом;
приложения, работающие под управлением Windows, поддерживают общедоступные стандарты обмена данными;
системы на базе ОС Windows просты в эксплуатации и развитии, что делает их экономичными как с точки зрения поддержки, так и при поэтапном росте;
Microsoft развивает информационные технологии (ИТ) для Windows высокими темпами, что позволяет компаниям, использующим эту платформу «идти в ногу со временем».
Также следует учитывать и то, что неотъемлемой частью верхнего уровня АСУ ТП является человек, время реакции которого на события недетерминировано и зачастую достаточно велико. Да и сама проблема реального времени на верхнем уровне не столь актуальна.
В 90-х годах широкое распространение получила ОС реального времени QNX. Имеется множество примеров использования QNX на всех уровня иерархической структуры АСУТП (от контроллеров до серверов и рабочих станций). Но в последние годы активность компании на рынке SCADA-систем значительно снизилась, что привело и к снижению числа продаж этого программного продукта. Объясняется это тем, что еще в 1995 году компания QNX Software Systems Ltd. объявила об «уходе» во встроенные системы.
С точки зрения разработки системы управления предпочтительна такая программная архитектура, в которой ПО всех уровней управления реализовано в единой операционной системе. В этом случае «автоматически» снимаются все вопросы, связанные с вертикальным взаимодействием различных программных компонент системы управления. Но на практике это далеко не так. Достаточно часто в разрабатываемых системах контроля и управления нижний и верхний уровни реализуются в разных ОС. И наиболее характерна ситуация, когда на уровне контроллера используется ОС реального времени, а на уровне оператора/диспетчера SCADA-система функционирует подWindowsNT. Без специализированных решений по организации взаимодействия между подсистемами здесь не обойтись.
Для функционирования системы управления необходим и еще один тип ПО - прикладное программное обеспечение (ППО).
Известны два пути разработки прикладного программного обеспечения систем управления:
создание собственного прикладного ПО с использованием средств
традиционного программирования (стандартные языки
программирования, средства отладки и т.д.);
использование для разработки прикладного ПО существующих
(готовых) инструментальных средств.
Первый вариант является наиболее трудоемким. Применение высокоуровневых языков требует соответствующей квалификации разработчиков в теории и технологии программирования, знания особенностей конкретной операционной системы, тонкостей аппаратного обеспечения (контроллеров). С точки зрения основных критериев - стоимости и времени разработки - этот вариант неприемлем в большинстве случаев.
Второй вариант является более предпочтительным. Почему? А потому, что на сегодняшний день в мире уже создано несколько десятков инструментальных систем, хорошо поддерживаемых, развиваемых и нашедших применение при создании десятков и сотен тысяч проектов автоматизации. Эти проверенные временем программные средства упрощают (разработчики интерфейсов - не высококлассные программисты, а специалисты по автоматизации), ускоряют и значительно удешевляют процесс разработки.
С точки зрения области применения готовые инструментальные средства можно разделить на два класса:
средства, ориентированные на разработку программ управления внешними устройствами, контроллерами - CASE -системы (Computer Aided Software Engineering );
средства, ориентированные на обеспечение интерфейса оператора/ диспетчера с системой управления – SCADA -системы(Supervisory Control And Data Acquisition - диспетчерское управление и сбор данных).
Контроллеру требуется программа , в соответствии с которой он взаимодействует с объектом. В одних случаях речь идет только о сборе данных с объекта, в других - о логическом управлении (например, выполнении блокировок). Наконец, одно из основных применений контроллера - реализация функций непрерывного управления отдельными параметрами или технологическим аппаратом (процессом) в целом.
Фирмы, производящие оборудование для построения систем автоматизации, всегда стремились сопровождать свою продукцию набором программных инструментов, с помощью которых пользователь по определенным правилам и соглашениям мог бы описывать логику работы контроллера. На раннем этапе развития этих программных средств набор поддерживаемых ими функций обеспечивался нестандартными языками. Со временем правила и соглашения совершенствовались и на определенном этапе были оформлены в виде специальных языков программирования, образовав то, что сейчас называется CASE -инструментарием.
В 1992 году Международная Электротехническая Комиссия (МЭК, IEC - International Electrotechnical Commission,) взяла под контроль процессы, связанные с развитием этого типа прикладного ПО. Были выдвинуты требования открытости системы, выполнение которых позволило бы унифицировать программные средства и упростить разработку:
возможность разработки драйверов для контроллеров самими пользователями, т.е. сопровождение программных продуктов по программированию контроллеров специальными инструментальными средствами;
наличие коммуникационных средств (интерфейсов) для взаимодействия с другими компонентами системы управления;
возможность портации ядра системы на ряд программно-аппаратных
платформ.
На рынке появилось большое количество пакетов, удовлетворяющих вышеописанным требованиям. Практически во всех этих пакетах среда разработки реализована в Windows -интерфейсе, имеются средства загрузки разработанного приложения в исполнительную систему.
Названия некоторых из этих пакетов приведены ниже:
RSLogix 500, RS Logix 5, RSLogix 5000 фирмы Rockwell Software для программирования контроллеров различных семейств Allen-Bradley;
DirectSOFT для контроллеров семейства Direct Logic фирмы Koyo;
пакеты PL7и Concept - ПО для программирования контроллеров различных семейств компании Schneider Electric;
пакеты STEP 5, STEP 7 Micro, STEP 7 для программирования контроллеров семейств S5 и S7 фирмы Siemens;
пакет Toolbox для конфигурирования контроллеров семейства Moscad;
пакет TelePACEдля программирования контроллеров серий
TeleSAFE Micro 16 и SCADAPack фирмы Control Microsystems.
Стандартом МЭК 1131-3 определены пять языков программирования контроллеров: три графических (LD, FBD, SFC) и два текстовых (ST, IL).
LD (Ladder Diagram) - графический язык диаграмм релейной логики. Язык LD применяется для описания логических выражений различного уровня сложности.
FBD (Function Block Diagram) - графический язык функциональных блоковых диаграмм. Язык FBD применяется для построения комплексных процедур, состоящих из различных функциональных библиотечных блоков - арифметических, тригонометрических, регуляторов и т.д.).
SFC (Sequential Function Chart) - графический язык последовательных функциональных схем. Язык SFC предназначен для использования на этапе проектирования ПО и позволяет описать «скелет» программы - логику ее работы на уровне последовательных шагов и условных переходов.
ST (Structured Text) - язык структурированного текста. Это язык высокого уровня, по мнемонике похож на Pascal и применяется для разработки процедур обработки данных.
IL (Instruction List) - язык инструкций. Это язык низкого уровня класса ассемблера и применяется для программирования эффективных, оптимизированных процедур.
В конце 90-х годов появились открытые программные продукты ISaGRAF, InControl (Wonderware), Paradym (Intellution), предназначенные для разработки, отладки и исполнения программ управления как дискретными, так и непрерывными процессами.
Сейчас уже можно сказать, что подавляющее большинство контроллеров и систем управления обслуживается программными продуктами, реализующими стандарт МЭК 1131-3.
Широкое применение в России нашел пакет ISaGRAF французской компании CJ International.
Основные возможности пакета:
Поддержка всех пяти языков стандарта МЭК 1131-3 плюс реализация языка Flow Chart как средства описания диаграмм состояний. При этом ISaGRAF позволяет смешивать программы и процедуры, написанные на разных языках, а также вставлять кодовые последовательности из одного языка в коды, написанные на другом языке.
Наличие многофункционального отладчика, позволяющего во время
работы прикладной задачи просматривать состояние программного
кода, переменных, программ и многое другое.
Поддержка различных протоколов промышленных сетей.
Реализация опций, обеспечивающих открытость системы для доступа к внутренним структурам данных прикладной ISaGRAF-задачи, а также возможность разработки драйверов для модулей ввода/вывода, разработанных самим пользователем, и возможность переноса ISaGRAF-ядра на любую аппаратно-программную платформу.
Набор драйверов для работы с контроллерами различных фирм-производителей: PEP Modular Computers, Motorola Computer Group и др.
Наличие дополнительных интерактивных редакторов для описания переменных, констант и конфигураций ввода/вывода.
Встроенные средства контроля за внесением изменений в программный код ISaGRAF-приложения и печати отчетов по разработанному проекту с большой степенью детализации, включая печать таблиц перекрестных ссылок для программ и отдельных переменных.
Полное документирование этапов разработки.
Программные средства верхнего уровня АСУТП (SCADA-пакеты) предназначены для создания прикладного программного обеспечения пультов контроля и управления, реализуемых на различных компьютерных платформах и специализированных рабочих станциях. SCADA - пакеты позволяют при минимальной доле программирования на простых языковых средствах разрабатывать многофункциональный интерфейс, обеспечивающий оператора/диспетчера не только полной информацией о технологическом процессе, но и возможностью им управлять.
В своем развитии SCADA - пакеты прошли тот же путь, что и программное обеспечение для программирования контроллеров. На начальном этапе (80-е годы) фирмы-разработчики аппаратных средств создавали собственные (закрытые) SCADA-системы, способные взаимодействовать только со «своей» аппаратурой. Начиная с 90-х годов, появились универсальные (открытые) SCADA - программы.
Понятие открытости является фундаментальным, когда речь идет о программно-аппаратных средствах для построения многоуровневых систем автоматизации. Более подробно об этом будет сказано ниже.
Сейчас на российском рынке присутствует несколько десятков открытых SCADA-пакетов, обладающих практически одинаковыми функциональными возможностями. Но это совсем не означает, что любой из них можно с одинаковыми усилиями (временными и финансовыми) успешно адаптировать к той или иной системе управления, особенно, если речь идет о ее модернизации. Каждый SCADA-пакет является по-своему уникальным, и его выбор для конкретной системы автоматизации, обсуждаемый на страницах специальной периодической прессы почти на протяжении последних десяти лет, по-прежнему остается актуальным.
Ниже приведен перечень наиболее популярных в России SCADA-пакетов.
Классификация программных средств АСУТП. Как мы уже упоминали, в типовой архитектуре SCADA-системы явно просматриваются два уровня:
· уровень локальных контроллеров , взаимодействующих с объектом управления посредством датчиков и исполнительных устройств;
· уровень оперативного управления технологическим процессом, основными компонентами которого являются серверы, рабочие станции операторов/диспетчеров, АРМ специалистов.
Каждый из этих уровней функционирует под управлением специализированного программного обеспечения (ПО). Разработка этого ПО или его выбор из предлагаемых в настоящее время на рынке программных средств зависит от многих факторов, прежде всего от решаемых на конкретном уровне задач. Различают базовое и прикладное программное обеспечение (см. рисунок 5.1).
Рисунок 5.2 - Классификация программных средств системы управления.
Базовое ПО включает в себя различные компоненты, но основным из них является операционная система (ОС) программно-технических средств АСУТП. Каждый уровень АСУТП представлен «своими» программно-техническими средствами: на нижнем уровне речь идет о контроллерах, тогда как основным техническим средством верхнего уровня является компьютер. В соответствии с этим в кругу специалистов появилась и такая классификация: встраиваемое инастольное программное обеспечение.
Очевидно, требования, предъявляемые к встраиваемому и настольному ПО, различны. Контроллер в системе управления наряду с функциями сбора информации решает задачи автоматического непрерывного или логического управления. В связи с этим к нему предъявляются жесткие требования по времени реакции на состояние объекта и выдачи управляющих воздействий на исполнительные устройства. Контроллер должен гарантированно откликаться на изменения состояния объекта за заданное время.
Выбор операционной системы программно-технических средств верхнего уровня АСУТП определяется прикладной задачей (ОС общего пользования или ОСРВ). Но наибольшую популярность и распространение получили различные варианты ОС Windows. Ими оснащены программно-технические средства верхнего уровня АСУТП, представленные персональными компьютерами (ПК) разной мощности и конфигурации - рабочие станции операторов/диспетчеров и специалистов, серверы баз данных (БД) и т. д.
Такая ситуация возникла в результате целого ряда причин и тенденций развития современных информационных и микропроцессорных технологий.
Вот несколько основных аргументов в пользу Windows:
· Windows имеет очень широкое распространение в мире, в том числе и в Казахстане, в связи с чем легко найти специалиста, который мог бы сопровождать системы на базе этой ОС;
· эта ОС имеет множество приложений, обеспечивающих решение различных задач обработки и представления информации;
· ОС Windows и Windows-приложения просты в освоении и обладают типовым интуитивно понятным интерфейсом;
· приложения, работающие под управлением Windows, поддерживают общедоступные стандарты обмена данными;
· системы на базе ОС Windows просты в эксплуатации и развитии, что делает их экономичными как с точки зрения поддержки, так и при поэтапном росте;
· Microsoft развивает информационные технологии (ИТ) для Windows высокими темпами, что позволяет компаниям, использующим эту платформу «идти в ногу со временем».
Также следует учитывать и то, что неотъемлемой частью верхнего уровня АСУ ТП является человек, время реакции которого на события недетерминировано и зачастую достаточно велико. Да и сама проблема реального времени на верхнем уровне не столь актуальна.
Для функционирования системы управления необходим и еще один тип ПО - прикладное программное обеспечение (ППО). Известны два пути разработки прикладного программного обеспечения систем управления:
· создание собственного прикладного ПО с использованием средств традиционного программирования (стандартные языки программирования, средства отладки и т.д.);
· использование для разработки прикладного ПО существующих (готовых) инструментальных средств.
· Программные средства верхнего уровня АСУТП (SCADA-пакеты) предназначены для создания прикладного программного обеспечения пультов контроля и управления, реализуемых на различных компьютерных платформах и специализированных рабочих станциях. SCADA - пакеты позволяют при минимальной доле программирования на простых языковых средствах разрабатывать многофункциональный интерфейс, обеспечивающий оператора/диспетчера не только полной информацией о технологическом процессе, но и возможностью им управлять.
В своем развитии SCADA - пакеты прошли тот же путь, что и программное обеспечение для программирования контроллеров. На начальном этапе (80-е годы) фирмы-разработчики аппаратных средств создавали собственные (закрытые) SCADA-системы, способные взаимодействовать только со «своей» аппаратурой. Начиная с 90-х годов, появились универсальные (открытые) SCADA - программы.
Понятие открытости является фундаментальным, когда речь идет о программно-аппаратных средствах для построения многоуровневых систем автоматизации. Более подробно об этом будет сказано ниже.
Сейчас на российском рынке присутствует несколько десятков открытых SCADA-пакетов, обладающих практически одинаковыми функциональными возможностями. Но это совсем не означает, что любой из них можно с одинаковыми усилиями (временными и финансовыми) успешно адаптировать к той или иной системе управления, особенно, если речь идет о ее модернизации. Каждый SCADA-пакет является по-своему уникальным, и его выбор для конкретной системы автоматизации, обсуждаемый на страницах специальной периодической прессы почти на протяжении последних десяти лет, по-прежнему остается актуальным.
Ниже приведен перечень наиболее популярных в России и Казахстане SCADA-пакетов.
· Trace Mode/Трейс Моуд (AdAstrA) - Россия;
· InTouch (Wonderware) - США;
· FIX (Intellution) - США;
· Genesis (Iconics Co) - США;
· Factory Link (United States Data Co) - США;
· RealFlex (BJ Software Systems) - США;
· Sitex (Jade Software) - Великобритания;
· Citect (CI Technology) - Австралия;
· WinCC (Siemens) - Германия;
· RTWin (SWD Real Time Systems) - Россия;
· САРГОН (НВТ - Автоматика) - Россия;
· MIK$Sys (МИФИ) - Россия;
· Cimplicity (GE Fanuc) - США;
· RSView (Rockwell Automation) - США и многие другие.
Последовательность представления пакетов в приведенном выше перечне в достаточной степени случайна. Констатируется лишь сам факт существования той или иной системы. Предлагается исходить из предпосылки, что SCADA-пакет существует, если с помощью него уже реализовано хотя бы несколько десятков проектов. Вторая предпосылка - нет абсолютно лучшей SCADA-системы для всех случаев применения. SCADA - это всего лишь удобный инструмент в руках разработчика, и ее адаптация к конкретной системе автоматизации - вопрос квалификации и опыта.
Основные функции SCADA-систем. Программное обеспечение типа SCADA предназначено для разработки и эксплуатации автоматизированных систем управления технологическими процессами. Резонно задать вопрос: а что же все-таки первично – разработка или эксплуатация? И ответ в данном случае однозначен – первичным является эффективный человеко-машинный интерфейс (HMI), ориентированный на пользователя, т. е. на оперативный персонал, роль которого в управлении является определяющей. SCADA – это новый подход к проблемам человеческого фактора в системах управления (сверху вниз), ориентация в первую очередь на человека (оператора/диспетчера), его задачи и реализуемые им функции.
Такой подход позволил минимизировать участие операторов/диспетчеров в управлении процессом, но оставил за ними право принятия решения в особых ситуациях.
А что дала SCADA-система разработчикам? С появлением SCADA они получили в руки эффективный инструмент для проектирования систем управления, к преимуществам которого можно отнести:
· высокую степень автоматизации процесса разработки системы управления;
· участие в разработке специалистов в области автоматизируемых процессов (программирование без программирования);
· реальное сокращение временных, а, следовательно, и финансовых затрат на разработку систем управления.
Прежде, чем говорить о функциональных возможностях ПО SCADA, предлагается взглянуть на функциональные обязанности самих операторов/диспетчеров. Каковы же эти обязанности? Следует сразу отметить, что функциональные обязанности операторов/диспетчеров конкретных технологических процессов и производств могут быть существенно разными, да и сами понятия «оператор» и «диспетчер» далеко не равнозначны. Тем не менее, среди многообразия этих обязанностей оказалось возможным найти общие, присущие данной категории работников:
· регистрация значений основных технологических и хозрасчетных параметров;
· анализ полученных данных и их сопоставление со сменно-суточными заданиями и календарными планами;
· учет и регистрация причин нарушений хода технологического процесса;
· ведение журналов, составление оперативных рапортов, отчетов и других документов;
· предоставление данных о ходе технологического процесса и состоянии оборудования в вышестоящие службы и т. д.
Раньше в операторной (диспетчерской) находился щит управления (отсюда - щитовая). Для установок и технологических процессов с несколькими сотнями параметров контроля и регулирования длина щита могла достигать нескольких десятков метров, а количество приборов на них измерялось многими десятками, а иногда и сотнями. Среди этих приборов были и показывающие (шкала и указатель), и самопишущие (кроме шкалы и указателя еще и диаграммная бумага с пером), и сигнализирующие. В определенное время оператор, обходя щит, записывал показания приборов в журнал. Так решалась задача сбора и регистрации информации.
В приборах, обслуживающих регулируемые параметры, имелись устройства для настройки задания регулятору и для перехода с автоматического режима управления на ручное (дистанционное). Здесь же, рядом с приборами, находились многочисленные кнопки, тумблеры и рубильники для включения и отключения различного технологического оборудования. Таким образом решались задачи дистанционного управления технологическими параметрами и оборудованием.
Над щитом управления (как правило, на стене) находилась мнемосхема технологического процесса с изображенными на ней технологическими аппаратами, материальными потоками и многочисленными лампами сигнализации зеленого, желтого и красного (аварийного) цвета. Эти лампы начинали мигать при возникновении нештатной ситуации. В особо опасных ситуациях предусматривалась возможность подачи звукового сигнала (сирена) для быстрого предупреждения всего оперативного персонала. Так решались задачи, связанные с сигнализацией нарушений технологического регламента (отклонений текущих значений технологических параметров от заданных, отказа оборудования).
С появлением в операторной/диспетчерской компьютеров было естественным часть функций, связанных со сбором, регистрацией, обработкой и отображением информации, определением нештатных (аварийных) ситуаций, ведением документации, отчетов, переложить на компьютеры. Еще во времена первых управляющих вычислительных машин с монохромными алфавитно-цифровыми дисплеями на этих дисплеях усилиями энтузиастов-разработчиков уже создавались «псевдографические» изображения - прообраз современной графики. Уже тогда системы обеспечивали сбор, обработку, отображение информации, ввод команд и данных оператором, архивирование и протоколирование хода процесса.
Хотелось бы отметить, что с появлением современных программно-технических средств автоматизации, рабочих станций операторов/диспетчеров, функционирующих на базе программного обеспечения SCADA, щиты управления и настенные мнемосхемы не канули безвозвратно в лету. Там, где это продиктовано целесообразностью, щиты и пульты управления остаются, но становятся более компактными.
Появление УВМ, а затем и персональных компьютеров вовлекло в процесс создания операторского интерфейса программистов. Они хорошо владеют компьютером, языками программирования и способны писать сложные программы. Для этого программисту нужен лишь алгоритм (формализованная схема решения задачи). Но беда в том, что программист, как правило, не владеет технологией, не «понимает» технологического процесса. Поэтому для разработки алгоритмов надо было привлекать специалистов-технологов, например, инженеров по автоматизации.
Выход из этой ситуации был найден в создании методов «программирования без реального программирования», доступных для понимания не только программисту, но и инженеру-технологу. В результате появились программные пакеты для создания интерфейса «человек-машина» (Man/Humain Machine Interface, MMI/HMI). За рубежом это программное обеспечение получило название SCADA (Supervisory Control And Data Acquisition – супервизорное/диспетчерское управление и сбор данных), так как предназначалось для разработки и функциональной поддержки АРМов операторов/диспетчеров в АСУТП. А в середине 90-х аббревиатура SCADA (СКАДА) уверенно появилась и в лексиконе российских специалистов по автоматизации.
Оказалось, что большинство задач, стоящих перед создателями программного обеспечения верхнего уровня АСУ ТП различных отраслей промышленности, достаточно легко поддается унификации, потому что функции оператора/диспетчера практически любого производства достаточно унифицированы и легко поддаются формализации.
Таким образом, базовый набор функций SCADA-систем предопределен ролью этого программного обеспечения в системах управления (HMI) и реализован практически во всех пакетах. Это:
· сбор информации с устройств нижнего уровня (датчиков, контроллеров);
· прием и передача команд оператора/диспетчера на контроллеры и исполнительные устройства (дистанционное управление объектами);
· сетевое взаимодействие с информационной системой предприятия (с вышестоящими службами);
· отображение параметров технологического процесса и состояния оборудования с помощью мнемосхем, таблиц, графиков и т.п. в удобной для восприятия форме;
· оповещение эксплуатационного персонала об аварийных ситуациях и событиях, связанных с контролируемым технологическим процессом и функционированием программно-аппаратных средств АСУ ТП с регистрацией действий персонала в аварийных ситуациях.
· хранение полученной информации в архивах;
· представление текущих и накопленных (архивных) данных в виде графиков (тренды);
· вторичная обработка информации;
· формирование сводок и других отчетных документов по созданным на этапе проектирования шаблонам.
К интерфейсу, созданному на базе программного обеспечения SCADA, предъявляется несколько фундаментальных требований:
· он должен быть интуитивно понятен и удобен для оператора/диспетчера;
· единичная ошибка оператора не должна вызывать выдачу ложной команды управления на объект.
Структура программного обеспечения (ПО). Программное обеспечение является такой же неотъемлемой частью современной системы, как и аппаратное обеспечение.
Часть программного обеспечения - системное ПО, обычно поставляется фирмой и рассчитано на конкретную вычислительную платформу. Функционально близко к системному программному обеспечению находится специальное программное обеспечение, предназначенное не для автоматического управления, а для оперативного наблюдения за ходом процессов в системе, ведения архивов, отчётов, наглядного представления текущих параметров процессов, организации виртуальных измерительных приборов, дисплеев и т.п. Эти системы обычно не работают в жёстком реальном времени. Имеется достаточное количество таких готовых систем (Trace Mode, UltraLogik и др.). В целях обеспечения независимости от производителя, а также в целях повышения надёжности и проблемной ориентированности часто такие системы создают специально.
Другая часть программного обеспечения - драйверы устройств, должна быть результатом согласования фирм-разработчиков устройств и фирм-разработчиков системного ПО. Согласование достигается путём следования стандартам разработки драйверов.
Наконец, имеется ещё один тип программного обеспечения, предназначенного для решения либо конкретных вычислительных задач, или для управления специальными нестандартными устройствами. Это прикладное программное обеспечение вынужден создавать разработчик конкретной системы. При этом часто приходится использовать язык ассемблера, так как требуется высокое быстродействие и предсказуемость поведения программы.
Системное программное обеспечение . Возможность работы в реальном времени, обеспечение высокого уровня надежности при работе, поддержка стандартов на все виды интерфейсов - все эти требования позволяют выделить промышленные вычислительные системы в отдельный класс. Основное требование (помимо надёжности), предъявляемое к вычислительным системам данного класса, - это гарантированное время реакции на произошедшее событие. Из данного условия сразу можно выделить отличительные качества промышленных вычислительных систем:
Адаптация вычислительного блока к датчикам и периферийным устройствам;
Использование распространенных и проверенных промышленных стандартов;
Использование операционных систем реального времени (ОСРВ).
Операционные системы реального времени . Как и всякая другая операционная система, ОСРВ выполняет следующие основные функции, необходимые при использовании средств вычислительной техники в автоматике:
Обеспечение бесконфликтного взаимодействия параллельных задач с аппаратурой;
Бесконфликтное разделение ресурсов вычислительной системы (память, диски и т.п.);
Обеспечение надежной передачи данных между процессами в адресных пространствах;
Обеспечение стандартных средств доступа к ресурсам;
Обеспечение стандартных телекоммуникаций и сетевой поддержки;
Поддержание службы времени (системных и сетевых таймеров);
Создание вычислительной среды повышенной надёжности;
Но ОСРВ эти функции выполняет за гарантированное и известное время.
Многие современные операционные системы, способные обрабатывать "на лету" поступающие запросы, в какой-то степени можно отнести к операционным системам реального времени. Как правило, такие операционные системы являются клонами ОС UNIX, где основным принципом построения ОС является разделение времени с целью предоставить каждому пользователю свой ресурс.
Главный критерий, по которому операционные системы можно разделить на обычные и операционные системы реального времени, - это детерминированная, строго определенная задержка времени ожидания или прерывания, необходимая процессу, прежде чем он получит управление. В ОСРВ различают два основных элемента - это время отклика и детерминизм. Время отклика определяет, как часто система может "отвечать" в среднем. Детерминизм - это показатель наибольшей задержки системы. Некоторые операционные системы, например DOS, являются недетерминированными и непригодны для использования в реальном масштабе времени.
Системы реального времени также делятся на "soft real-time" и "hard real-time" - мягкое реальное время (МРВ) и жёсткое реальное время (ЖРВ). Для МРВ-систем возможна потеря внешнего события (прерывания) без оказания серьезного влияния на систему в целом. Потерянное прерывание в ситуации с ЖРВ имеет серьезные последствия, как например, "потеря" аварийной ситуации в системе исключения столкновений на авиалиниях. Следует также понимать, что ЖРВ не связано с абсолютными значениями времени реакции ОС, так как есть процессы со временами работы, исчисляющимися сотыми долями секунды (например, в энергетических системах), а есть такие, для которых характерные постоянные времени равны часам (тепловые процессы).
В настоящее время интерес к операционным системам реального времени очень велик и известно множество ОС реального времени. Каждая из ведущих фирм-производителей, выпускающих промышленные компьютеры, обязательно имеет версию своей операционной системы для работы в реальном масштабе времени. Для компании Hewlett-Packard (HP) - это HP RT, для компании SGI - это ОС REACT, а для систем фирмы Motorola - это целое семейство различных ОС РВ.
Прикладное программное обеспечение для САУ можно разбить на следующие группы:
Дополнение к операционной системе (драйверы и т.п.);
Программы управления, передачи данных, обработки данных, планирования и т.п., то есть прикладные вычислительные задачи;
Программное обеспечение локальных регуляторов. Эта часть программного обеспечения часто создаётся для специализированных микроконтроллеров.
Для создания этих разнородных частей прикладного программного обеспечения используются разные методы программирования. Наиболее традиционной частью являются прикладные вычислительные задачи, для которых стараются использовать программирование на языках высокого уровня. Обычно здесь удаётся обойтись программированием на языке С, С++, Pascal, привлекая для этого интегрированные среды типа Visual C, Builder или Delphi.
При создании программного обеспечения для локальных контроллеров важно придерживаться следующих принципов:
При разработке проекта стараться обеспечить однородность вычислительной платформы, что позволит в дальнейшем упростить программирование. Реально это означает, что целесообразно в локальных системах использовать не специализированные микроконтроллеры, а PC-совместимые контроллеры. Но в ряде задач наиболее эффективны именно специализированные контроллеры, как, например, специальные DSP-процессоры в задачах цифровой обработки сигналов.
При разработке микропрограмм для локальных контроллеров необходимо тщательно обосновывать выбор контроллеров, причём, основным аспектом является не экономический, так как стоимость микроконтроллеров постоянно снижается, а системный.
Альтернативой традиционному программированию микроконтроллеров, в принципе, является технология Java, предполагающая сетевую загрузку исполняемых программ в контроллеры.
Международная Электротехническая Комиссия (МЭК) в 1993 г. утвердила стандарт IEC 1131-3. Этот международный стандарт входит в группу IEC 1131 стандартов, которые охватывают различные аспекты использования программируемых логических контроллеров (ПЛК). Стандарт IEC 1131-3 описывает синтаксис и семантику пяти языков программирования ПЛК.
Инструменты разработки и отладки программного обеспечения . Наиболее перспективными являются интуитивно-понятные разработчику средства визуального проектирования. Визуальные средства предполагают, что проектировщик (пользователь) не должен писать практически никакого кода программы ни на одном из языков программирования. Вместо этого он производит размещение тех или иных наглядных графических образов (пиктограмм) на рабочем поле. Они представляют собой отображение некоторых стандартных блоков, алгоритмов, устройств. Соединяя эти образы в соответствии с требуемой структурой, и задавая свойства отдельных компонент, пользователь быстро получает требуемое представление своей системы. Избежать программирования удаётся за счёт объектно-ориентированного характера такой модели, при котором необходимые коды программ уже инкапсулированы в стандартных блоках.
Но здесь заключается и слабая сторона такого подхода. Реально имеются две негативные стороны использования стандартных библиотек функций:
Закрытость исходных кодов (и в смысле недоступности, и в том смысле, что пользователь не заинтересован разбираться в чужих кодах);
Неоптимальность кодов именно для той конкретной ситуации, в которой находится данный разработчик системы автоматики ("универсальное - значит не оптимальное").
Эти два пункта реально приводят к тому, что пользователь- разработчик автоматической системы не может гарантировать надёжность работы всей системы, так как в неё входят закрытые компоненты, и не может гарантировать оптимальности в смысле быстродействия работы критичных к этому параметру частей системы. Визуальные методы программирования ограниченно пригодны в случае хорошо известных задач, не критичных к быстродействию и надёжности.
Чтобы добиться абсолютно предсказуемого поведения программного обеспечения с учётом работы в реальном времени разработчик автоматических систем вынужден создавать и собственное программное обеспечение. Наиболее целесообразный подход здесь следующий:
По мере возможности пользоваться языками высокого уровня;
Лишь в случае нехватки быстродействия или надёжности использовать Ассемблер.
Такой подход позволит инженеру в области автоматики решить сразу две задачи:
Обеспечить реальную возможность передачи исходных кодов программ другим разработчикам, в том числе, и при смене вычислительной платформы;
Добиться существенной экономии времени разработки программного обеспечения. Известно, что наиболее "расточительно" в этом смысле программирование на Ассемблере.
Стандартными средствами во всех случаях являются специальные программные продукты, предназначенные для разработки программного обеспечения: редакторы, трансляторы, компоновщики, отладчики. Наиболее целесообразно использовать специальные интегрированные среды разработки, объединяющие все эти средства. Такие среды разработки имеются практически для всех языков программирования.
Сопровождение программного обеспечения - это возможность гарантировать передачу программных комплексов, их переналадку в случае необходимости, исправление обнаруженных ошибок, устранение сбоев. Возможность сопровождения программного обеспечения зависит от следующих основных факторов:
Обеспечение разработчиком сервисных услуг;
Наличия доступной технической документации, в том числе, открытых кодов программ;
Использование при разработке средств, доступных пользователям;
Минимизация зависимости программного обеспечения от разработчика. Ключевым в этом вопросе является использование промышленных методов создания программного обеспечения.
От правильного выбора программного продукта, удовлетворяющего требованиям сопровождения, часто зависит судьба всей системы автоматики и эффективности вложения средств.
литература
1. Мирошник И.В. Теория автоматического управления. Линейные системы: Учебное пособие для вузов. - СПб.: Питер, 2005. - 336 с.
4. Орлов А.И. Менеджмент: Учебник. – М.: "Изумруд", 2003. URL: http://www.aup.ru/books/m151/
10. Туманов М.П. Технические средства автоматизации и управления: Учебное пособие. – М.: МГИЭМ, 2005, 71 с. URL: http://rs16tl.rapidshare.com/files/21651582/2889232/ Tehnicheskie_sredstva_avtomatizatsii_i_upravleniya.rar
11. Михайлов В.С. Теория управления. – К.: Выща школа, 1988.
О замеченных опечатках, ошибках и предложениях по дополнению: [email protected].
