Системы диспетчерского управления и сбора данных (scada-системы). Программное обеспечение систем управления, диспетчеризации и асутп Определение и общая структура SCADA

2.1 SCADA-системы: общие понятия и структура.

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

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

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

Диспетчеризации подлежат системы:

Электроснабжения и электроосвещения;

Противопожарного оборудования и устройства пожаротушения;

Вентиляции и кондиционирования воздуха;

Отопления и горячего водоснабжения;

Канализационных устройств и дренажа;

Газораспределительных пунктов и станций.

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

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

диспетчеризации.

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

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

Зачастую необходимо, чтобы информация о событиях, требующих внимания и

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

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

SCADA – это аббревиатура от слов Supervisory Control Data Acguistion (диспетчерское управление и сбор данных). SCADA представляет собой программное обеспечение, выполняющее следующие функции:

Сбор данных о состоянии инженерного оборудования от контроллеров щитов локальной автоматики;

Хранение и отображение информации о функционировании оборудования за весь срок его работы;

Уведомление обслуживающего персонала о требующих внимания событиях с помощью е-mail, SMS или факс;

Доступ к контролю и управлению оборудованием по локальной сети объекта, через Интернет и т.д.

Сервер диспетчеризации с установленной на нем SCADA системой часто называют «верхний уровень».

SCADA система имеет возможность расширяться/сращиваться с другими системами управления.

2.2 Функциональная структура SCADA.

Удаленные терминалы (RTU). Каналы связи (CS). Диспетчерские пункты управления (MTU). Операционные системы. Прикладное программное обеспечение. Центральный диспетчерский пункт.

Диспетчерское управление и сбор данных (SCADA Supervisory Control And Data Acquisition) является основным и в настоящее время остается наиболее перспективным методом автоматизированного управления сложными динамическими системами (процессами) в жизненно важных и критичных с точки зрения безопасности и надежности областях. Именно на принципах диспетчерского управления строятся крупные автоматизированные системы в промышленности и энергетике, на транспорте, в космической и военной областях, в различных государственных структурах.

За последние 10 15 лет за рубежом резко возрос интерес к проблемам построения высокоэффективных и высоконадежных систем диспетчерского управления и сбора данных. С одной стороны, это связано со значительным прогрессом в области вычислительной техники, программного обеспечения и телекоммуникаций, что увеличивает возможности и расширяет сферу применения автоматизированных систем. С другой стороны, развитие информационных технологий, повышение степени автоматизации и перераспределение функций между человеком и аппаратурой обострило проблему взаимодействия человека-оператора с системой управления. Расследование и анализ большинства аварий и происшествий в авиации, наземном и водном транспорте, промышленности и энергетике, часть из которых привела к катастрофическим последствиям, показали, что, если в 60-х годах ошибка человека являлась первоначальной причиной лишь 20% инцидентов (80%, соответственно, за технологическими неисправностями и отказами), то в 90-х годах доля человеческого фактора возросла до 80%, причем, в связи с постоянным совершенствованием технологий и повышением надежности электронного оборудования и машин, доля эта может еще возрасти (рис.1)

Рис.1. Тенденции причин аварий в сложных автоматизированных системах

Основной причиной таких тенденций является старый традиционный подход к построению сложных автоматизированных систем управления, который применяется часто и в настоящее время: ориентация в первую очередь на применение новейших технических (технологических) достижений, стремление повысить степень автоматизации и функциональные возможности системы и, в то же время, недооценка необходимости построения эффективного человеко-машинного интерфейса (HMI Human-Machine Interface), т.е. интерфейса, ориентированного на пользователя (оператора). Не случайно именно на последние 15 лет, т.е. период появления мощных, компактных и недорогих вычислительных средств, пришелся пик исследований в США по проблемам человеческого фактора в системах управления, в том числе по оптимизации архитектуры и HMI-интерфейса систем диспетчерского управления и сбора данных.

Изучение материалов по проблемам построения эффективных и надежных систем диспетчерского управления показало необходимость применения нового подхода при разработке таких систем: human-centered design(или top-down, сверху-вниз), т.е. ориентация в первую очередь на человека-оператора (диспетчера) и его задачи, вместо традиционного и повсеместно применявшегося hardware-centered (или bottom-up, снизу-вверх), в котором при построении системы основное внимание уделялось выбору и разработке технических средств (оборудования и программного обеспечения). Применение нового подхода в реальных космических и авиационных разработках и сравнительные испытания систем в Национальном управлении по аэронавтике и исследованию космического пространства (NASA), США, подтвердили его эффективность, позволив увеличить производительность операторов, на порядок уменьшить процедурные ошибки и свести к нулю критические (не корректируемые) ошибки операторов.

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

Прообразом современных систем SCADA на ранних стадиях развития автоматизированных систем управления являлись системы телеметрии и сигнализации.

Все современные SCADA-системы включают три основных структурных компонента (см. рис. 2) Remote Terminal Unit (RTU) удаленный терминал, осуществляющий обработку задачи (управление) в режиме реального времени. Спектр его воплощений широк от примитивных датчиков, осуществляющих съем информации с объекта, до специализированных многопроцессорных отказоустойчивых вычислительных комплексов, осуществляющих обработку информации и управление в режиме жесткого реального времени. Конкретная его реализация определяется конкретным применением. Использование устройств низкоуровневой обработки информации позволяет снизить требования к пропускной способности каналов связи с центральным диспетчерским пунктом.

Рис. 2. Основные структурные компоненты SCADA-системы

Master Terminal Unit (MTU), Master Station (MS) диспетчерский пункт управления (главный терминал); осуществляет обработку данных и управление высокого уровня, как правило, в режиме мягкого (квази-) реального времени; одна из основных функций обеспечение интерфейса между человеком-оператором и системой (HMI, MMI). В зависимости от конкретной системы MTU может быть реализован в самом разнообразном виде от одиночного компьютера с дополнительными устройствами подключения к каналам связи до больших вычислительных систем (мэйнфреймов) и/или объединенных в локальную сеть рабочих станций и серверов. Как правило, и при построении MTU используются различные методы повышения надежности и безопасности работы системы.

Communication System (CS) коммуникационная система (каналы связи), необходима для передачи данных с удаленных точек (объектов, терминалов) на центральный интерфейс оператора-диспетчера и передачи сигналов управления на RTU (или удаленный объект в зависимости от конкретного исполнения системы).

Функциональная структура SCADA

Существует два типа управления удаленными объектами в SCADA: автоматическое и инициируемое оператором системы.

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

Рис. 3. Основные структурные компоненты SCADA-систем

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

Данное представление SCADA явилось основой для разработки современных методологий построения эффективных диспетчерских систем.

2.3 Особенности SCADA как процесса управления

Области применения SCADA-систем

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

Управление передачей и распределением электроэнергии;

Промышленное производство;

Производство электроэнергии;

Водозабор, водоочистка и водораспределение;

Добыча, транспортировка и распределение нефти и газа;

Управление на транспорте (все виды транспорта: авиа, метро, железнодорожный, автомобильный, водный);

Телекоммуникации;

Военная область.

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

Локальная система управления

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

Локальные системы являются полностью независимыми системами и могут работать по своему циклу без взаимодействия с системами «верхнего уровня».

Система состоит из следующих компонентов:

Датчики;

Локальный контролер/контроллеры;

Исполнительные устройства.

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

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

Центральный диспетчерский пункт

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

Центральный Диспетчерский Пункт предназначен для:

1. Предотвращения и дистанционного выявление причины аварии или сбоя.

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

2. Помощи обслуживающему персоналу в принятии оперативных решений.

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

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

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

Программное обеспечение поставляется только вместе с соответствующим аппаратным ключом, который конструктивно выполнен в виде USB-ключа или платы, которая вставляется в свободный PCI слот компьютера.

EXO4 и система EXO выполняет следующие функции:

Динамическая визуализация объектов и процессов;

Управление и мониторинг объектами;

Дистанционное чтение аварий и данных;

Многопользовательская система со структурой авторизации и управления

пользователями;

Регистрация и управление событиями;

Слежение за авариями и состояниями (4 уровня приоритетов аварий);

Создание рапортов и отчетов об авариях и неисправностях;

Подтверждение, блокировка и разблокировка аварийных сообщений;

Звуковое и визуальное сопровождение аварийных сообщений;

Перенаправление сообщений об авариях на один или несколько принтеров в

зависимости от времени и (или) события;

Построение графиков и трендов (точек) в реальном времени;

Управление данными и архивированием;

Сетевая коммуникация по технологии клиент-сервер и поддержка различных

протоколов;

Всплывающие подсказки;

Временные программы;

Многооконный интерфейс;

Управление базами данных;

Поддержка проводных и беспроводных устройств передачи данных;

Автоматический переход на зимнее и летнее время;

Синхронизация системы.

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

Линии связи

Под понятием линии связи принимают системы для передачи и приема информации с помощью различных технических средств.

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

Услуги проводной телефонной связи оказывают как государственные компании, так и некоторые коммерческие операторы.

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

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

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

2.4 Тенденции развития технических средств систем диспетчерского управления

Общие тенденции

Прогресс в области информационных технологий обусловил развитие всех 3-х основных структурных компонентов систем диспетчерского управления и сбора данных RTU, MTU, CS, что позволило значительно увеличить их возможности; так, число контролируемых удаленных точек в современной SCADA-системе может достигать 100000.

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

Удаленные терминалы (RTU)

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

Конкретная реализация RTU зависит от области применения. Это могут быть специализированные (бортовые) компьютеры, в том числе мультипроцессорные системы, обычные микрокомпьютеры или персональные ЭВМ (РС); для индустриальных и транспортных систем существует два конкурирующих направления в технике RTU индустриальные (промышленные) PC и программируемые логические контроллеры (в русском переводе часто встречается термин промышленные контроллеры) PLC.

Индустриальные компьютеры представляют собой, как правило, программно совместимые с обычными коммерческими РС машины, но адаптированные для жестких условий эксплуатации буквально для установки на производстве, в цехах, газокомпрессорных станциях и т.д. Адаптация относится не только к конструктивному исполнению, но и к архитектуре и схемотехнике, так как изменения температуры окружающей среды приводят к дрейфу электрических параметров. В качестве устройств сопряжения с объектом управления данные системы комплектуются дополнительными платами (адаптерами) расширения, которых на рынке существует большое разнообразие от различных изготовителей (как, впрочем, и самих поставщиков промышленных РС). В качестве операционной системы в промышленных PC, работающих в роли удаленных терминалов, все чаще начинает применяться Windows NT, в том числе различные расширения реального времени, специально разработанные для этой операционной системы (подробнее см. ниже).

Промышленные контроллеры (PLC) представляют собой специализированные вычислительные устройства, предназначенные для управления процессами (объектами) в реальном времени. Промышленные контроллеры имеют вычислительное ядро и модули ввода-вывода, принимающие информацию (сигналы) с датчиков, переключателей, преобразователей, других устройств и контроллеров, и осуществляющие управление процессом или объектом выдачей управляющих сигналов на приводы, клапаны, переключатели и другие исполнительные устройства. Современные PLC часто объединяются в сеть (RS-485, Ethernet, различные типы индустриальных шин), а программные средства, разрабатываемые для них, позволяют в удобной для оператора форме программировать и управлять ими через компьютер, находящийся на верхнем уровне SCADA-системы диспетчерском пункте управления (MTU). Исследование рынка PLC показало, что наиболее развитой архитектурой, программным обеспечением и функциональными возможностями обладают контроллеры фирмSiemens, Fanuc Automation (General Electric), Allen-Bradley (Rockwell), Mitsubishi. Представляет интерес также продукция фирмы CONTROL MICROSYSTEMS промышленные контроллеры для систем мониторинга и управления нефте- и газопромыслами, трубопроводами, электрическими подстанциями, городским водоснабжением, очисткой сточных вод, контроля загрязнения окружающей среды.

Много материалов и исследований по промышленной автоматизации посвящено конкуренции двух направлений PC и PLC; каждый из авторов приводит большое количество доводов за и против по каждому направлению. Тем не менее, можно выделить основную тенденцию: там, где требуется повышенная надежность и управление в жестком реальном времени, применяются PLC. В первую очередь это касается применений в системах жизнеобеспечения (например, водоснабжение, электроснабжение), транспортных системах, энергетических и промышленных предприятиях, представляющих повышенную экологическую опасность. Примерами могут служить применение PLC семейства Simatic (Siemens) в управлении электропитанием монорельсовой дороги в Германии или применение контроллеров компании Allen-Bradley (Rockwell) для модернизации устаревшей диспетчерской системы аварийной вентиляции и кондиционирования на плутониевом заводе 4 в Лос-Аламосе. Аппаратные средства PLC позволяют эффективно строить отказоустойчивые системы для критических приложений на основе многократного резервирования. Индустриальные РС применяются преимущественно в менее критичных областях (например, в автомобильной промышленности, модернизация производства фирмой General Motors), хотя встречаются примеры и более ответственных применений (метро в Варшаве управление движением поездов). По оценкам экспертов, построение систем на основе PLC, как правило, является менее дорогостоящим вариантом по сравнению с индустриальными компьютерами.

Аппаратно-программный комплекс диспетчерского контроля (АПК-ДК) является последней реализацией функций диспетчерского контроля на современном техническом уровне.

Использование средств вычислительной техники расширило функциональные возможности системы АПК-ДК не только для поездного диспетчера, но позволило решить и основные задачи контроля состояния технических средств систем ЖАТ на перегонах и станциях диспетчерского участка.

Таким образом, система АПК-ДК имеет двойное назначение и обеспечивает:

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

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

Состояние перегонных устройств систем ЖАТ контролируют автоматы контроля сигнальных точек (АКСТ), выполненные на базе специализированных контроллеров. Наибольшее распространение имеет блок АКСТ-СЧМ, представляющий собой генератор частоты, формирующий посылаемые в линию связи циклические восьми импульсные частотные посылки в соответствии с состоянием контролируемых объектов. При восьми выходных импульсах благодаря манипуляции по длительности импульсов и пауз (интервалов) АКСТ-ЧМ позволяет контролировать состояние семи дискретных датчиков (реле) и двух пороговых датчиков.

Рисунок 3.1 - Структурная схема системы АПК ДК

При проектировании АПК-ДК определяется перечень параметров, контролируемых каждым АКСТ-СЧМ.

Для систем автоблокировки параметры выбирают из следующего перечня: отсутствие основного питания на сигнальной точке; отсутствие резервного питания; перегорание основной нити лампы красного огня; перегорание резервной нити лампы красного огня; перегорание нити лампы разрешающего огня; установленное направление движения; сход изолирующего стыка; пропадание постоянного напряжения блока БС-ДА; занятость блок участка; неисправность АКСТ-СЧМ или линии ДСМ; пропадание обоих фидеров питания на объектах с аккумуляторным резервом; аварийный отказ.

При проектировании для каждого АКСТ-ЧМ устанавливается несущая частота (частота настройки генератора), поскольку все АКСТ перегона работают по общей физической линии с частотным разделением каналов.

На одной физической цепи может работать до 30 АКСТ-ЧМ со следующим разделением частот.

На станциях (линейных пунктах) принимается и анализируется информация от АКСТ-СЧМ соответствующими концентраторами (промышленный компьютер). Структурно система состоит из устройства съема данных и удаленного от него на расстояние около 1 км рабочего места маневрового диспетчера. Связь осуществляется по четырехпроводной линии.

В качестве устройства съема данных используется MicroPC, содержащее:

• 1) процессорную плату 5025А;
• 2) две платы дискретного ввода-вывода 5600;
• 3) четыре OPTO RAС, специальным образом подключенных к дискретным датчикам.

Следует отметить, что для контроля над работой только одной половины сортировочной станции, включающей в себя три парка (парк приема, сортировочный парк и парк отправления), необходимо контролировать около полутора тысяч объектов. Если умножить это число на стоимость одного модуля оптронной развязки фирмы Crayhill, то получим цифру около 15000 долларов США. Цифра для разработчиков по нынешним временам, увы, не малая. Поэтому, разработчиками было принято решение при помощи стандартных модулей УСО организовать входную матрицу. Цена сразу упала на порядок, обошлись 96-го модулями I/O типа G4IDC5. Пришлось разработать и изготовить саму матрицу, однако затраты на это оказались несопоставимо меньшими, чем если бы задача была решена "в лоб". Оптронная матрица представляет собой модульную структуру, каждый из модулей которой позволяет подключать 16 дискретных сигналов постоянного или переменного тока напряжением от 12 до 30 В. Модули при помощи разъемов устанавливаются на "материнской" плате, которая в свою очередь стандартными кабелями OCTAGON SYSTEMS соединяется с OPTO RACами. Рабочее место маневрового диспетчера реализовано на ПЭВМ типа IBM AT с многотерминальной видеоплатой, поддерживающей работу четырех мониторов. После определения аппаратных средств у разработчиков встал вопрос о выборе операционной системы (ОС), под управлением которой будет функционировать система ДК. Исходя из требований к функциям системы ДК можно придти к выводу, что данная ОС должна

обладать, как минимум следующими возможностями:

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

Всеми вышеперечисленными свойствами обладает ОС QNX, что и

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

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

Очень мощным является реализованный в QNX механизм обмена сообщениями, на базе которого система ДК была реализована в технологии клиент - сервер, повышающей надежность работы и позволяющей с незначительными издержками увеличивать как число устройств съема данных, так и потребителей информации. Поддержка многопользовательского режима требуется в связи с тем, что в системе одновременно могут работать несколько пользователей. Подключение дополнительных рабочих мест пользователей планируется осуществить на базе локальной сети, одним из узлов которой будет рабочее место маневрового диспетчера. Поддержка в QNX нескольких сетевых стандартов дает возможность для выбора: Ethernet, Arcnet, Token Ring и т.д.

Требование высокой производительности и работы в режиме реального времени становится понятным, если принять во внимание число контролируемых датчиков и заданную частоту съема их показаний - не менее 5 раз в секунду. Причем изменения состояний нескольких десятков датчиков происходят практически при каждом опросе. Проблему надежной передачи данных по каналу связи разработчикам удалось решить при помощи объединения в сеть QNX устройства съема и рабочего места диспетчера, что позволило использовать системный сетевой протокол и реализовать этот обмен независимым от среды передачи данных для прикладных программ. Сеть по последовательному каналу довольно устойчиво работает при скорости передачи данных в 4800 бод. Для увеличения пропускной способности сети мы использовали реализованный сетевым драйвером механизм сжатия/разжатия данных, являющийся прозрачным для прикладных программ.

Не обошлось и без некоторых сложностей. ОС QNX гарантирует, в случае если при передаче сообщения какая-нибудь задача окажется заблокированной, то система через некоторое время автоматически снимет блокировку, вернув код ошибки. К сожалению, данный механизм не всегда срабатывает. Задача может зависнуть в таком состоянии на неопределенно долгое время. Разработчикам пришлось отслеживать и исправлять данную ситуацию программным способом. По их мнению, возможно, это объясняется наличием ошибки в сетевом драйвере Net.fd версии 4.22 и при переходе на версию 4.23 удастся от нее избавиться. Желание создать систему, не привязанную жестко к конкретным аппаратным средствам, приводит к необходимости написания драйверов устройств. Тот, кто писал и отлаживал драйверы устройств под DOS, знает - особенное неудобство доставляет то, что интерфейс ОС для драйверов и прикладных программ различный. Что касается QNX, то написание и отладка драйверов ничем не отличается от написания и отладки остальных программ. Программный интерфейс общий для всех программ. Довольно быстро были написаны драйверы для платы Octagon 5600 и многоэкранной видеокарты. Так как в состав QNX входит большое число менеджеров устройств и различных драйверов, то во многих случаях можно просто воспользоваться предоставляемым сервисом, а не разрабатывать собственное программное обеспечение. Для подключения модема и организации сети между устройством съема и рабочим местом диспетчера использовался стандартный менеджер последовательных каналов.

Вследствие того, что QNX имеет небольшой размер и модульную структуру, стало возможным установить данную ОС на Micro PC. Ядро ОС, модуль сетевой поддержки, менеджер встроенной файловой системы и прикладные программы удалось разместить всего в 256Кб флеш-памяти и 100Кб статического ОЗУ. При работе требуется немногим более 1Мб оперативной памяти. Инсталляция программного обеспечения на Micro PC производилась при помощи удобного средства EKit - пакета для установки QNX во встраиваемые системы. Возможность удаленного изменения версий программ в нашем случае крайне необходима, так как Micro PC в рабочем режиме не имеет ни экрана, ни клавиатуры, ни дисковода. Прозрачный доступ к файлам в сети QNX значительно облегчает работу, а менеджер встроенной файловой системы Efsys позволяет перепрограммировать флеш-память и статическое ОЗУ при помощи обычной команды копирования файлов. После перезаписи имеется возможность программной перезагрузки удаленного компьютера с обновленной версией. С организацией программного перезапуска у разработчиков возникли некоторые проблемы. Попытка его осуществления практически всегда приводила к тому, что перезапускаемая машина зависала намертво. Это затруднение удалось обойти установив параметр отмены "горячей" перезагрузки при генерации образа ОС. Одной из основных задач, поставленных перед проектировщиками системы ДК, была задача предусмотреть возможность ее интеграции c уже имеющимися программными разработками. В качестве одной из таких разработок можно привести систему ведения графика исполненного движения, реализованную другими разработчиками в среде Windows NT. Учитывая негативный опыт, полученный при реализации собственных протоколов под DOS, было принято решение применять для стыковки исключительно стандартные протоколы. Де-факто, такими стандартными протоколами является семейство протоколов TCP/IP, что явилось еще одним весомым доводом в пользу системы, обеспечивающей их поддержку. Пакет TCP/IP для QNX предоставляет разработчику не только возможность программировать на уровне Socket API, но и использовать преимущества сетевой файловой системы (NFS), вызовов удаленных процедур (RPC) в стандарте ONC, многих полезных служб, например, telnet и ftp. Система ДК, реализованная на базе передовых аппаратных и программных технологий способствует получению диспетчером достоверной информации и значительно облегчает управление оперативной работой станции. Ведение протокола работы позволяет обнаружить "узкие места" и избежать не нужных материальных затрат. В перспективе появляется задача автоматического формирования многочисленных документов, которые до сих пор заполняются вручную.

Структура программного обеспечения (ПО). Программное обеспечение является такой же неотъемлемой частью современной системы, как и аппаратное обеспечение.

Часть программного обеспечения - системное ПО, обычно поставляется фирмой и рассчитано на конкретную вычислительную платформу. Функционально близко к системному программному обеспечению находится специальное программное обеспечение, предназначенное не для автоматического управления, а для оперативного наблюдения за ходом процессов в системе, ведения архивов, отчётов, наглядного представления текущих параметров процессов, организации виртуальных измерительных приборов, дисплеев и т.п. Эти системы обычно не работают в жёстком реальном времени. Имеется достаточное количество таких готовых систем (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].

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

В типовой архитектуре 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-пакетов.