Программное обеспечение систем управления.

Классификация программных средств АСУТП. Как мы уже упоминали, в типовой архитектуре 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, предъявляется несколько фундаментальных требований:

· он должен быть интуитивно понятен и удобен для оператора/диспетчера;

· единичная ошибка оператора не должна вызывать выдачу ложной команды управления на объект.