Windows CE

Для многих Windows CE ассоциируется с ОС, созданной для карманных компьютеров. Достаточно большой класс карманных компьютеров основан на этой ОС, при этом ее возможности и области применения гораздо шире. Windows CE разрабатывалась не только для рынка карманных компьютеров, но и для рынка бытовой техники и встраиваемых систем. Не зря в названии ОС есть аббревиатура CE, что, по одной версии, означает Consumer Electronic, а по другой - Consumer Edition (To consume – потреблять в составе чего-то).

Глобальная идея Б. Гейтса - внедрить Windows CE во все устройства, которые "питаются" электричеством. Уже сейчас эта система используется в Интернет-приставках (WebTV), сотовых телефонах, карманных компьютерах, в автомобилях, промышленных системах и т.п.

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

Это позволяет создавать ОС под конкретное устройство и его функции. Высокая надежность устройств с Windows CE обеспечивается тем, что эти системы могут выполняться непосредственно из ROM или специальной Flash памяти. При желании прикладные программы можно разместить в той же Flash памяти, что позволит существенно повысить надежность всей системы.

Наличие в Windows CE поддержки стандартных коммуникационных протоколов Internet: sockets, TCP/IP и PPP позволяет использовать такие системы для практически полноценного доступа в Internet. Для осуществления dial-up соединений в Windows CE встроена поддержка протоколов подмножества TAPI и Unimodem.

Windows CE, хотя и появилась на рынок как "ОС для карманных компьютеров", но поддерживает большой выбор мониторов (монохромные (gray scale), LCD, цветные VGA дисплеи и даже TV) с широким спектром разрешений (до 1024х768)), различные типы процессоров (Hitachi SH3,SH4, NEC 4100, Philips 3900, Intel 486 и более поздние, MIPS, Motorola PowerPC и процессоры технологии ARM), накопители CD-ROM и DVD, поддерживает наборы "чипсетов" для периферийных шин (PCI, ISA и т.д.) и многое другое.

Windows CE - это полноценная 32-х разрядная, объектно-ориентированная, многозадачная ОС с поддержкой фиксированной очереди приоритетов с исполнением до завершения. Она имеет встроенные функции энергосбережения, поэтому у разработчика есть реальная возможность управлять питанием CPU и даже выключать дисплей в целях экономии энергопотребления (что неплохо используется в Cassiopeia E-105 при проигрывании аудио (MP3 файлов) - здорово экономит аккумуляторы!). Windows CE 3.0, поддерживает Java и DirectX-компоненты, и является при этом ОС реального времени, т.е. способна обеспечить гарантированное, быстрое время отклика (так называемый детерминизм) и низкие задержки, необходимые для интенсивно работающих приложений реального времени.

В систему добавлены часы реального времени, драйверы устройств, основанные на потоках, устанавливаемые приоритеты драйверов устройств, механизм DLL для потоков реального времени, семафоры, и изоляция в режиме реального времени для "non-real-time" потоков, поддержка схемы приоритетов (32 уровня).

Windows CE поддерживает реентерабельность (процессы с низким приоритетом могут отдавать управление процессам с более высоким приоритетом), и обеспечивает вытесняющее управление критическим разделом (preemptable critical section management).

При всех этих возможностях Windows CE не такая "прожорливая" по памяти, как ее конкуренты. Минимальная конфигурация, состоящая из ядра (500 наиболее распространенных функций Win32 API, простая база данных, драйверы для ROM, RAM, FAT файловой системы), коммуникационных протоколов (TCP/IP, PPP, и IrDA) и одного приложения, не требующего для работы дисплея, может вполне обходиться ОП 256KB и требовать менее 0.5 MB ПЗУ.

Для полноценной работы Windows CE, использующей все компоненты архитектуры, требуется всего 2 MB ПЗУ, выполняется она (вместе с графической оболочкой) в ОП менее 512 KB. В карманных компьютерах Windows CE вместе с полным комплектом офисных приложений требует до 4 MB ПЗУ и всего 2 MB ОП.

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

Для разработчиков очень важны доступность и возможности средств разработки, т.к. это почти на 50% определяет успех подобного типа систем. В этом смысле Windows CE является очень перспективной системой - практически все средства разработки от Microsoft, существующие для "больших окон", имеют свои аналоги для Windows CE. Это Windows CE ToolKit for Microsoft Visual C++, Visual Basic и J++. Для работы этих SDK требуются соответствующие среды разработки для Windows NT 4.0 и выше.

19. Классификация программных средств систем управления технологическими процессами

Различают базовое и прикладное программное обеспечение (рис.1).

Рис. 1. Классификация программных средств системы управления.

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

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

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

Выбор ОС зави­сит от жесткости требований реального времени. Для задач, критичных к реакции системы управления, в настоящее время применяются такие операционные системы реального времени, как OS-9, QNX, VxWorks. В системах с менее жесткими требованиями к реальному времени возможно применение версий Windows NT/CE, точнее их расширений реального времени.

OS-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-система функционирует под Windows NT. Без специализированных решений по организации взаимодействия между подсистемами здесь не обойтись.

Ø Для функционирования системы управления необходим и еще один тип ПО - прикладное программное обеспечение (ППО).

Известны два пути разработки прикладного программного обеспечения систем управления:

- создание собственного прикладного ПО с использованием средств

традиционного программирования (стандартные языки

программирования, средства отладки и т.д.);

- использование для разработки прикладного ПО существующих

(готовых) инструментальных средств.

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

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

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

- средства, ориентирован­ные на разработку программ управления внешними устройствами, контрол­лерами - 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).

В конце 90-х годов появились открытые программные продукты ISaGRAF, InControl (Wonderware), Paradym (Intellution), предназначенные для разработки, отладки и исполнения программ управления как дискретными, так и непрерывными процессами.

Сейчас уже можно сказать, что подавляющее большинство контроллеров и систем управления обслуживается программными продуктами, реализующими стандарт МЭК 1131-3.

-

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

В своем развитии SCADA - пакеты прошли тот же путь, что и программное обеспечение для программирования контроллеров. На начальном этапе (80-е годы) фирмы-разработчики аппаратных средств создавали собственные (закрытые) SCADA-системы, способные взаимодействовать только со «своей» аппаратурой. Начиная с 90-х годов, появились универсальные (открытые) SCADA - программы.

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

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

Ниже приведен перечень наиболее популярных в России SCADA-пакетов.

q Trace Mode/Трейс Моуд (AdAstrA) - Россия;

q InTouch (Wonderware) - США;

q FIX (Intellution) - США;

q Genesis (Iconics Co) - США;

q Factory Link (United States Data Co) - США;

q RealFlex (BJ Software Systems) - США;

q Sitex (Jade Software) - Великобритания;

q Citect (CI Technology) - Австралия;

q WinCC (Siemens) - Германия;

q RTWin (SWD Real Time Systems) - Россия;

q САРГОН (НВТ - Автоматика) - Россия;

q MIK$Sys (МИФИ) - Россия;

q Cimplicity (GE Fanuc) - США;

q RSView (Rockwell Automation) - США и многие другие.

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

· До недавнего времени задача регистрации информации в реальном времени могла быть решена либо на уровне программного обеспечения концентратора (контроллера верхнего уровня), либо на уровне SCADA-системы. При этом речь идет о больших потоках данных о процессе, поступающих от большого количества датчиков (нескольких сот или тысяч) в реальном масштабе времени и с высокой частотой (периоды опроса – порядка секунд и даже долей секунд). На уровне АСУТП эта информация нужна для оперативного управления технологическим процессом.

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

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

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

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

В результате, информация, имеющаяся и успешно используемая в АСУТП, недоступна для верхнего уровня.

Таким образом, назрела необходимость создания и внедрения в процесс управления так называемых исторических архивов производственных данныхили баз данных реального времени (БДРВ) масштаба предприятия.

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

Такие системы от различных производителей (в том числе и от производителей SCADA-систем) уже появились в России и с каждым днем находят все более широкое применение. Среди них IndustrialSQL Server – компонент интегрированного пакета FactorySuite (Wonderware), iHistorian - компонент семейства Intellution Dynamics и другие.

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

Наличие базы данных реального времени масштаба предприятия – это только лишь предпосылка для их решения (необходимое, но недостаточное условие). Ряд разработчиков инструментальных систем предлагают использовать с этой целью специальный тип программных продуктов. Это могут быть небольшие системы, предназначенные для решения отдельных типовых задач, например, системы расчета и согласования материальных балансов. Появился ряд интегрированных систем, поддерживающих, наряду с функциями хранения и представления информации, решение задач расчета тепловых и материальных балансов, планирования, оптимизации и т.п. К наиболее известным программным продуктам этого класса ПО относятся InfoPlus компании Aspen Tech, «Калькулятор качества» фирмы ПЕТРОКОМ, PI System (Plant Information System) компании OSIsoft.

Современное развитие информационных технологий (ИТ) создало предпосылки для успешной интеграции всех уровней управления многоуровневой системы и создания интегрированной информационной системы предприятия.

20. Основные функции 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, предъявляется несколько фундаментальных требований:

- он должен быть интуитивно понятен и удобен для

оператора/диспетчера;

- единичная ошибка оператора не должна вызывать выдачу

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

21. Архитектурное построение SCADA-систем

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

C появлением концепции открытых систем (начало 90-х) программные средства для операторских станций становятся самостоятельным продуктом.

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

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

Рис. 2.1. Клиент-серверная архитектура.

Клиент-серверная архитектура предполагает, что вся информация о технологическом процессе от контроллеров собирается и обрабатывается на сервере ввода/вывода (сервер базы данных), к которому по сети подключаются АРМ клиентов.

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

Количество операторских станций, серверов ввода/вывода (серверов БД) определяется на стадии проектирования и зависит, прежде всего, от объема перерабатываемой в системе информации. Для небольших систем управления функции сервера ввода/вывода и станции оператора (HMI) могут быть совмещены на одном компьютере.

В сетевых распределенных системах средствами SCADA/HMI стало возможным создавать станции (узлы) различного функционального назначения: станции операторов/диспетчеров, серверы с функциями HMI, “слепые” серверы (без функций HMI), станции мониторинга (только просмотр без прав на управление) для специалистов и руководителей и другие.

SCADA-программы имеют в своем составе два взаимозависимых модуля: Development (среда разработки проекта) и Runtime (среда исполнения). В целях снижения стоимости проекта эти модули могут устанавливаться на разные компьютеры. Например, станции оператора, как правило, являются узлами Runtime (или View) с полным набором функций человеко-машинного интерфейса. При этом хотя бы один компьютер в сети должен быть типа Development. На таких узлах проект разрабатывается, корректируется, а также может и исполняться. Некоторые SCADA-системы допускают внесение изменений в проект без остановки работы всей системы. Программное обеспечение SCADA-серверов позволяет создавать полный проект системы управления, включая базу данных и HMI.

· Важным аспектом в структурном построении сетевых систем управления является структура базы данных реального времени (централизованная или распределенная). Каждая из структур в SCADA/HMI-системах реализуется разными разработчиками по-разному. От реализации существенно зависят эффективность обеспечения единства и целостности базы данных, ее надежность, возможности модификации и т.д.

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

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

· С точки зрения структурного построения SCADA-пакетов различают:

- системы, обеспечивающие полный набор базовых функций HMI;

- системы, состоящие из модулей, реализующих отдельные

функции HMI.

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

Во втором случае система создается полностью модульной (сервер ввода/вывода, сервер алармов, сервер трендов, и т.д.). Для небольших проектов все модули могут исполняться на одном компьютере. В проектах с большим количеством переменных модули можно распределить на несколько компьютеров в разных сочетаниях. Вариант клиент-серверной архитектуры такой системы представлен на рис. 2.2.

В клиент-серверной архитектуре системы управления, представленной на рис. 2.2, функции сбора и хранения данных, управления алармами и трендами распределены между тремя серверами. Функция HMI реализуется на станциях-клиентах.

Рис. 2.2. Архитектура модульной SCADA.

Например, SCADA Citect имеет в своем составе пять функциональных модулей (серверов или клиентов):

§ I/O - сервер ввода/вывода. Обеспечивает передачу данных между

физическими устройствами ввода/вывода и другими модулями Citect.

§ Display - клиент визуализации. Обеспечивает операторский интерфейс: отображение данных, поступающих от других модулей Citect, и управление выполнением команд оператора.

§ Alarms - сервер алармов. Отслеживает данные, сравнивает их с

допустимыми пределами, проверяет выполнение заданных условий и

отображает алармы на соответствующем узле визуализации.

§ Trends - сервер трендов. Собирает и регистрирует трендовую

информацию, позволяя отображать развитие процесса в реальном

масштабе времени или в ретроспективе.

§ Reports - сервер отчетов. Генерирует отчеты по истечении

определенного времени, при возникновении определенного события

или по запросу оператора.

В одной сети можно использовать только один сервер алармов, сервер трендов и сервер отчетов. В то же время допускается использование нескольких серверов ввода/вывода (I/O Server). Количество компьютеров с установленным модулем Display (обеспечивающим операторский интерфейс) в сети практически не ограничено.

22. SCADA как открытая система

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

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

Рис. 2.3. Интеграция SCADA в систему управления.

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

Реализация этой задачи требует от SCADA-системы наличия типовых протоколов обмена с наиболее популярными промышленными сетями, такими, как Profibus, ControlNet, Modbus и другими.

С другой стороны, SCADA-системы должны поддерживать интерфейс и со стандартными информационными сетями (Ethernet и др.) с использованием стандартных протоколов (TCP/IP и др.) для обмена данными с компонентами распределенной системы управления.

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

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

Наиболее широко применимы два механизма обмена:

- ODBC (Open Data Base Connectivity - взаимодействие с открытыми базами данных) – международный стандарт, предполагающий обмен информацией с РБД посредством ODBC-драйверов. Как стандартный протокол компании Microsoft, ODBC поддерживается и наиболее распространенными приложениями Windows;

- SQL (Structured Query Language) – язык структурированных запросов.

· Программное обеспечение SCADA должно взаимодействовать с контроллерами для обеспечения человеко-машинного интерфейса с системой управления (рис. 2.3). К контроллерам через модули ввода/вывода подключены датчики технологических параметров и исполнительные устройства (на рис. 2.3 не показаны).

Информация с датчика записывается в регистр контроллера. Для ее передачи в базу данных SCADA-сервера необходима специальная программа, называемая драйвером. Драйвер, установленный на сервере, обеспечивает обмен данными с контроллером по некоторому физическому каналу. Но для реализации обмена необходим и логический протокол.

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

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

Для взаимодействия драйверов ввода/вывода и SCADA до недавнего времени использовались два механизма (рис. 2.4):

- DDE (Dynamic Data Exchange - динамический обмен данными);

- обмен по собственным (известным только фирме-разработчику) протоколам.

Рис. 2.4. Обмен информацией с помощью DDE-протокола.

Взамен DDE компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами – OLE (см. ниже). А вскоре на базе OLE появился новый стандарт OPC, ориентированный на рынок промышленной автоматизации.

· OPC-интерфейс

OPC – это аббревиатура от O LE for P rocess C ontrol (OLE для управления процессами). Технология OPC основана на разработанной компанией Microsoft технологии OLE (Object Linking and Embedding – встраивание и связывание объектов). Под объектами здесь подразумеваются так называемые компоненты, которые представляют собой готовые к использованию мини-приложения. Встраивая и связывая эти компоненты, можно разрабатывать приложения компонентной архитектуры. Этот новый подход к разработке приложений, предложенный компанией Microsoft, получил название технологии COM (Component Object Model – модель компонентных объектов). Теперь приложение-клиент может удаленно вызывать те или иные функции этих объектов так, как будто объекты находятся «рядом». Объект может нахо­диться и в самом деле рядом (в адрес­ном пространстве приложения) - тогда это просто СОМ.

Если же объект находится в другой программе на том же компьютере или на другом узле сети, то это DCOM - Distributed (распределенная) СОМ.

Так что же такое ОРС? OPC представляет собой коммуникационный стандарт, поддерживающий взаимодействие между полевыми устройствами, контроллерами и приложениями разных производителей. Стандарт OPC описывает компонентные объекты, методы и свойства (базирующиеся на технологии OLE/COM) для серверов данных реального времени, таких как PLC, DCS, систем архивирования данных и других, и обеспечивает передачу информации, содержащейся на этих серверах, стандартным OLE-клиентам.

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

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

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

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

Использование технологии OPC в настоящее время возможно лишь в операционных системах, построенных на технологии OLE/COM, т.е. в ОС Microsoft Windows 95/98 и Windows NT. Идут разработки поддержки этой технологии для операционной системы UNIX.

Таким образом, любое устройст­во, для которого есть ОРС -сервер, мо­жет использоваться вместе с любой со­временной SCADA -системой, реализованной на платформе MS Windows.

Развивающая стандарт OPC некоммерческая организация OPC Foundation (https://www.opcfoundation.org), насчитывает свыше 200 членов. В нее входят почти все ведущие мировые производители программно-аппаратных средств автоматизации.

Хотя стандарт ОРС и основан на универсаль­ном фундаменте - COM / DCOM, он разра­батывался специально для использова­ния в промышленной автоматизации и поэтому имеет вполне содержатель­ную концептуальную сторону.

Стандарт состоит из трех основных спецификаций:

- доступ к данным реального времени (Data Access);

- обработка тревог и событий (Alarms & Events);

- доступ к историческим данным (Historical Data Access).

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

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

Стандарт OPC позволяет написать лишь один-единственный драйвер (рис. справа) для доступа к данным, поступающим в едином формате от самых различных источников.

OPC-интерфейс допускает различные варианты обмена: с физическими устройствами, с распределенными сетевыми системами управления и с любыми приложениями (рис.2.5). На рынке имеются и инструментальные пакеты для написания OPC-компонентов.

Рис. 2.5. Обмен данными по OPC-интерфейсу.

Использование технологии OPC позволяет конечным пользователям выбирать программно-аппаратные средства, наиболее отвечающие их потребностям, независимо от того, кто их производит.

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

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

С другой стороны, сегодня в мире существует множество компаний, занимающихся разработкой различных программных компонентов для SCADA-систем, например, ActiveX-объектов. Их использование при разработке систем автоматизации упрощает и ускоряет процесс проектирования. Этот процесс все больше начинает напоминать процесс «сборки» прикладного программного обеспечения из готовых компонентов. Снижаются требования к квалификации программистов – количество задач, решаемых системой с помощью программ собственной разработки на высокоуровневых языка типа C или Visual Basic уменьшается. Все это способствует расширению области применения SCADA-систем.

· ActiveX-объекты

ActiveX – это технология Microsoft, основанная на COM/DCOM (см. выше) и предназначенная для написания сетевых приложений. Она предоставляет программистам наборы стандартных библиотек, значительно облегчающих процесс кодирования.

Стандарт ActiveX позволяет программным компонентам взаимодействовать друг с другом по сети независимо от языка программирования, на котором они написаны (Visual Basic, Visual C++, Borland Delphi, Borland C++, любые средства разработки на Java).

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

Технология ActiveX включает в себя клиентскую и серверную части.

Серверная часть технологии ActiveX реализована с помощью Microsoft Internet Information Server (IIS).

Клиентская технология ActiveX реализуется на машине-клиенте с помощью библиотек, поставляемых вместе с Microsoft Internet Explorer, являющимся полнофункциональным Wев-браузером (WWW - World Wide Web) и контейнером для ActiveX-элементов. Сегодня технология ActiveX успешно внедряется в системы, функционирующие на Windows-платформе. Нет сомнения, что в ближайшее время эти технологии будут использоваться и на других платформах, так как информационные технологии развиваются очень высокими темпами.

Какое же отношение технология ActiveX имеет к SCADA-системам? Разработчики SCADA-программ на платформе WindowsNT/2000/XP воспользовались этой технологией Microsoft. Сейчас уже многие SCADA являются контейнерами для ActiveX-объектов. А это значит, что огромное количество готовых к многократному использованию ActiveX-объектов, создаваемых многочисленными производителями подобного программного продукта, могут встраиваться с минимальным программированием в SCADA-приложения. И тогда процесс разработки человеко-машинного интерфейса будет напоминать работу с конструктором, заключающуюся в подборе и встраивании готовых компонентов.

В режиме исполнения ActiveX-компоненты поддерживают динамический обмен данными с другими сетевыми программно-аппаратными компонентами по OPC-интерфейсу.

Пример ActiveX-объекта приведен на рис. 2.6.

Рис. 2.6. ActiveX-объект «Сводка сигнализации».

Итак, открытость программного обеспечения SCADA обеспечивается целым рядом факторов, а именно:

- возможностью создания собственных программных модулей

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

- наличием специальных драйверов для связи SCADA с наиболее

популярными контроллерами разных фирм;

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

драйверов;

- возможностью их работы в типовых операционных системах;

- наличием типовых программных интерфейсов (DDE, OLE, OPC, ActiveX, ODBC, SQL и др.), связывающих ПО SCADA с другими программно-аппаратными средствами системы управления, включая и СУБД.

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

23. Актуальность интеграции программных средств АСУТП и АСУП

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

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

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

Вверху, на уровне АСУП (в мировой практике этот уровень управления получил название ERP - Enterprise Resources Planning - планирование ресурсов предприятия), имеются структуры, обеспечивающие финансово-хозяйственную деятельность предприятия в целом, планирование и учет производства, в том числе:

- управление финансами;

- бухгалтерcкий учет;

- энергетическое обеспечение;

- материально-техническое обеспечение;

- сбыт готовой продукции;

- ремонтно-техническое обеспечение;

- управление персоналом и т. д.

Результатом их деятельности являются планы, задания, регламенты, которые в качестве управляющих воздействий «спускаются» на уровень АСУТП. Вот здесь и возникает главный вопрос - а на базе какой информации все эти задания и планы вырабатывались? Дело в том, что автоматически «поднять» оперативную информацию до уровня принятия стратегических решений долгое время не удавалось. В результате информация для принятия управленческих решений часто была не только не оперативной (устаревшей), но и недостоверной (человеческий фактор).

В России исторически сложилось так, что автоматизация управления промышленными предприятиями долгое время осуществлялась по двум достаточно обособленным и независимым друг от друга направлениям (АСУТП и АСУП).

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

· В 90-х годах прошлого века в России (особенно в нефтегазовой отрасли) начался бурный процесс модернизации технических средств автоматизации. На смену морально и физически устаревшим средствам пришли современные программно - технические комплексы. Это и контроллеры (PLC) различных производителей, и DCS различных масштабов, на базе которых можно строить интегрированные системы управления не только технологическими установками, а даже цехами и небольшими заводами. SCADA -системы уже стали неотъемлемой частью многих модернизированных и вновь введенных АСУТП.

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

Положительные результаты автоматизации технологических процессов очевидны – успешно идет процесс замены морально и физически устаревших средств автоматизации на современные и надежные микропроцессорные системы (DCS или SCADA). На предприятиях появились специалисты, владеющие компьютерными системами и современными методами управления, специалисты по информационным технологиям (ИТ).

· Для решения задач автоматизации управления административно-хозяйственной деятельностью предприятий (АСУП) в последнее время создается и широко внедряется большое количество типовых систем управления. По функциональным возможностям все эти системы неравнозначны. Среди них имеются и так называемые коробочные продукты, реализующие очень небольшое количество функций (бухгалтерские, складские и т. п.), и мощные системы, способные моделировать происходящие на предприятии процессы управления (SAP/R3, Baan, Oracle Applications). Представлены и системы среднего класса