ЦП Автоматизированные системы управления и промышленная безопасность

При рассмотрении стоимостных характеристик необходимо учитывать особенности компонентов SCADA и требования к ним в зависимости от выбранной архитектуры АСУ. В рамках принятой нами архитектуры (распределенная двухуровневая АСУ) предполагаемая система управления должна иметь станцию оператора с возможностью визуализации ТП и архивирования данных на верхнем уровне и около десятка контроллеров на нижнем уровне.
Такой комплект предусматривает наличие как минимум двух компонентов SCADA-системы: для верхнего уровня и для нижнего уровня. Используя данные фирм-разработчиков отечественных пакетов по состоянию на осень 2004 г. [1–7] имеем следующую картину стоимости двухкомпонентных SCADA-систем, отраженную в таблице 1. В этой таблице учитывается только стоимость компонентов SCADA-систем без стоимости используемых операционных систем.
Эксплуатационные характеристики
Эксплуатационные характеристики SCADA-системы имеют большое значение, поскольку от них зависит скорость освоения продукта и разработки прикладных систем. Они в конечном итоге отражаются на стоимости реализации проектов.
Удобство использования. Следует отметить, что сервис, предоставляемый SCADA-системами на этапе разработки прикладного ПО, обычно очень высок это вытекает из основных требований к таким системам. Почти все они имеют Windows-подобный пользовательский интерфейс, что во многом повышает удобство их использования, как в процессе разработки, так и в период эксплуатации прикладной задачи.
Наличие и качество поддержки. Необходимо обращать внимание не только на наличие технической поддержки SCADA-систем, как таковой, но и на ее качество. Для зарубежных систем в России возможны следующие уровни поддержки: услуги фирмы-разработчика; обслуживание региональными представителями фирмы-разработчика; взаимодействие с системными интеграторами. Судя по большому количеству установок зарубежных систем, исчисляющихся в тысячах (InTouch 80000, Genesis 30000), можно предположить, что поддержка этих системдостаточно эффективна.
Русификация. Любая система управления, имеющая интерфейс с оператором, должна допускать возможность общения с человеком на его родном языке. Поэтому крайне важна возможность использования в системе различных шрифтов кириллицы, ввод/вывод системных сообщений на русском языке, перевод документации, различных информационных материалов. Для некоторых систем (Image, Trace Mode) эта проблема вообще отсутствует, так как они разрабатывались отечественными фирмами. Для многих зарубежных продуктов проблема русификации в значительной мере снимается, во всяком случае, для подсистем исполнения или подсистем исполнения (RunTime), если они используют наборы шрифтов Windows. Часть зарубежных систем имеют переводы документации на русский язык (InTouch). Нужна ли русифицированная среда разработки? Положительный ответ не очевиден. Но если да , то среда, обязательно протестированная и рекомендованная фирмой-разработчиком. Так как с технической точки зрения проблем с русификацией нет (использование редакторов ресурсов из любой среды разработки Borland C++, Visual C++), то проблема лишь в легитимности этой процедуры. 

Программно-аппаратные платформы, на которых реализована SCADA-система. Анализ перечня таких платформ необходим, поскольку от него зависит ответ на вопросы распространения SCADA-системы на имеющиеся вычислительные средства, а также оценка стоимости эксплуатации системы (прикладная программа, разработанная в одной операционной среде, может выполняться в любой другой, которую поддерживает выбранный SCADA-пакет). В различных SCADA-системах этот вопрос решен по разному.
Подавляющее большинство SCADA-систем реализовано на платформах MS Windows. Именно такие системы предлагают наиболее полные и легко наращиваемые человеко-машинные интерфейсные (Man Machine Interface MMI) средства. Учитывая продолжающееся усиление позиций Microsoft на рынке операционных систем (ОС) следует отметить, что даже разработчики многоплатформных SCADA-систем, такие как United States DATA Co, приоритетным считают дальнейшее развитие своих SCADA-систем на платформе Windows NT. Некоторые фирмы, до сих пор поддерживавшие SCADA-системы на базе ОС реального времени (РВ), начали менять ориентацию, выбирая системы на платформе Windows NT. Все более очевидным становится применение ОС реального времени, в основном, во встраиваемых системах. Таким образом, основным полем, где сегодня разворачиваются главные события глобального рынка SCADA-систем, стала ОС MS Windows NT на фоне всё ускоряющегося сворачивания активности в области MS DOS, MS Windows 3.xx/95.
Имеющиеся средства сетевой поддержки. Одна из основных особенностей современного мира систем автоматизации высокая степень интеграции этих систем. В любой из них могут быть задействованы объекты управления, исполнительные механизмы, аппаратура, регистрирующая и обрабатывающая информацию, рабочие места операторов, серверы баз данных и т.д. Очевидно, что для эффективного функционирования в этой разнородной среде SCADA-система должна обеспечивать высокий уровень сетевого сервиса. Желательно, чтобы она поддерживала работу в стандартных сетевых средах (ARCNET, ETHERNET и т.д.) с использованием стандартных протоколов (NETBIOS, TCP/IP и др.), а также обеспечивала поддержку наиболее популярных сетевых стандартов из класса промышленных интерфейсов (PROFIBUS, CANBUS, LON, MODBUS и т.д.) Обобщенная схема подобной системы приведена на рис.1.
Встроенные командные языки. Большинство SCADA-систем имеют встроенные языки высокого уровня, VBasic-подобные языки, позволяющие сгенерировать адекватную реакцию на события, связанные с изменением значения переменной, с выполнением некоторого логического условия, с нажатием комбинации клавиш, а также с выполнением некоторого фрагмента с заданной частотой относительно всего приложения или отдельного окна.
Поддерживаемые базы данных. Практически все SCADA-системы, в частности, Genesis, InTouch используют синтаксис ANSI SQL, который не зависит от типа базы данных. Таким образом, приложения виртуально изолированы, что позволяет менять базу данных без серьезного изменения самой прикладной задачи, создавать независимые программы для анализа информации, использовать уже наработанное программное обеспечение, ориентированное на обработку данных.
Графические возможности. Для специалиста-разработчика системы автоматизации, также как и для специалиста- технолога , чье рабочее место создается, очень важен графический пользовательский интерфейс (Graphic Users Interface MMI). Функционально графические интерфейсы SCADA-систем очень похожи. В каждой из них существует графический объектно-ориентированный редактор с определенным набором анимационных функций. Используемая векторная графика дает возможность осуществлять широкий набор операций над выбранным объектом, а также быстро обновлять изображение на экране, используя средства анимации.

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

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

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

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 (англ. Supervisory Control And Data Acquisition) — система диспетчерского контроля и сбора данных.
Основная задача SCADA – это сбор информации о множестве удаленных объектов, поступающей с пунктов контроля, и отображение этой информации в едином диспетчерском центре. Кроме этого, SCADA должна обеспечивать долгосрочное архивирование полученных данных. При этом диспетчер зачастую имеет возможность не только пассивно наблюдать за объектом, но и ограниченно им управлять, реагируя на различные ситуации.
Основные задачи, решаемые SCADA-системами:
• Обмен данными с УСО (устройства связи с объектом, то есть с промышленными контроллерами и платами ввода/вывода) в реальном времени через драйверы.
• Обработка информации в реальном времени.
• Отображение информации на экране монитора в понятной для человека форме (HMI, англ. Human Machine Interface — человеко-машинный интерфейс).
• Ведение базы данных реального времени с технологической информацией.
• Аварийная сигнализация и управление тревожными сообщениями.
• Подготовка и генерирование отчетов о ходе технологического процесса.
• Осуществление сетевого взаимодействия между SCADA ПК.
• Обеспечение связи с внешними приложениями (СУБД, электронные таблицы, текстовые процессоры и т. д.). В системе управления предприятием такими приложениями чаще всего являются приложения, относимые к уровню MES.

SCADA-системы позволяют разрабатывать АСУ ТП в клиент-серверной или в распределенной архитектуре (DCS, англ. Distributed Control System — распределённая система управления).

Иногда SCADA-системы комплектуются дополнительным ПО для программирования промышленных контроллеров. Такие SCADA-системы называются интегрированными и к ним добавляют термин SoftLogіс.

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

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

COM (англ. Component Object Model — Объектная Модель Компонентов; произносится как [ком]) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих распределённых компонентов, каждый из которых может использоваться во многих программах одновременно. Стандарт воплощает в себе идеи полиморфизма и инкапсуляции объектно-ориентированного программирования. Стандарт COM мог бы быть универсальным и платформо-независимым, но закрепился в основном на операционных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были созданы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, а также XPCOM.
DCOM
Выпущенная в 1996 году технология DCOM (англ. Distributed COM — распределённая COM) основана на технологии DCE/RPC (разновидности RPC). DCOM позволяет COM-компонентам взаимодействовать друг с другом по сети. Главным конкурентом DCOM является другая известная распределённая технология — CORBA. Технология DCOM обеспечивает базовые установки безопасности, позволяя задавать, кто и из каких машин может создавать экземпляры объекта и вызывать его методы.
COM+
В составе Windows 2000 была выпущена технология COM+, которая расширяла возможности разработчиков COM-компонентов, предоставляя им некоторые готовые услуги, например:
улучшенную поддержку потоков;
доступ к контексту, в котором выполняется компонент (например, компоненты, используемые в ASP, могут с этой возможностью получить доступ к внутренним объектам той страницы, на которой они выполняются).
COM+ объединяет компоненты в так называемые приложения COM+, что упрощает администрирование и обслуживание компонентов. Безопасность и производительность — основные направления усовершенствований COM+. Некоторые идеи, заложенные в основу COM+, были также реализованы в Microsoft .NET.

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

Большинство ведущих производителей распределенных систем управления и программируемых контроллеров стали расхваливать открытость как главный атрибут своей продукции. И хотя то, что при этом предлагалось, было далеко от идеала, поставщики управляющих устройств действительно стали выполнять часть своих обещаний. При помощи технологии Ethernet и ставшего стандартом де-факто протокола TCP/IP операторские станции действительно можно было подключать к некоторым распределенным системам управления и ПЛК. Однако странные, необъяснимые и невоспроизводимые отказы систем всё же возникали; нередко по прошествии длительного времени стабильной работы. 
Надежность часто определяется как "возможность успешного выполнения предписанных функций в течение определенного периода времени"; при этом учитываются все источники аппаратных и программных отказов системы.
Анализируя возможные причины неисправностей в открытой системе, не приходится удивляться необъяснимым и случайным отказам. В плане надежности и безопасности открытые системы не имеют ничего общего с фирменными распределенными системами управления и ПЛК (DCS/PLC). Характеристики открытых систем более гибкие, более сложные и сравнительно неуправляемые (по крайней мере, с точки зрения обеспечения согласованной работы всех компонентов и частей системы, что является целью сертификации).
Коммуникационные протоколы фирменной системы, поставщиком продуктов для которой являлся единственный производитель, обычно создавались одним и тем же коллективом разработчиков, иногда даже одним человеком. Все сообщения, которыми могли обмениваться операторская станция и контроллер, были, как правило, четко определены. Если в системе каким-то чудом появлялось неверное сообщение, подпрограммы контроля ошибок просто отбрасывали все, что не относилось к разряду допустимых пересылок. Все программное обеспечение, от драйверов до обработчиков сообщений, писалось одной и той же командой программистов, работавших по единой спецификации. Создание устойчивого программного обеспечения является в такой ситуации сравнительно простой задачей.
Сбои были нередки даже в таких условиях, однако когда они случались, было совершенно ясно, кто несет за это ответственность. Вся ответственность за надежность и безопасность работы фирменных DCS-систем и систем на базе контроллеров лежала на единственном коллективе разработчиков, что принципиально невозможно в случае открытых систем.
В открытых системах вероятность передачи непредвиденных данных выше. Коммуникационные протоколы общего назначения стали гораздо сложнее, что затруднило задачу фильтрации некорректных сообщений. Единого коллектива разработчиков, отвечающего за весь проект целиком, нет, и кто должен нести ответственность за возникновение сбоя, совершенно непонятно. В результате систему приходится часто перезагружать, информация об отказах не регистрируется, и автоматизированные системы управления становятся менее надежными.
Несмотря на все усилия, прилагаемые разработчиками для повышения качества создаваемого ими программного обеспечения, независимые проверки показали, что во многих организациях ситуация с разработкой ПО может быть охарактеризована словом "хаос". Выяснилось также, что программисты не всегда разбираются в методах обеспечения безопасности и надежности ПО, и, хотя многих из них никак нельзя упрекнуть в отсутствии профессионализма, разброс в характеристиках программных продуктов слишком велик. Одного этого более чем достаточно, чтобы значительно повысить вероятность отказа системы управления.

Программная система является открытой, если для нее определены и описаны используемые форматы данных и процедурный интерфейс, что позволяет подключить к ней внешние , независимо разработанные компоненты.
Разработка собственных программных модулей. Перед фирмами-разработчиками систем автоматизации часто встает вопрос о создании собственных (не предусмотренных в рамках систем SCADA) программных модулей и включение их в создаваемую систему автоматизации. Поэтому вопрос об открытости системы является важной характеристикой SCADA-систем. Фактически открытость системы означает доступность спецификаций системных (в смысле SCADA) вызовов, реализующих тот или иной системный сервис. Это может быть и доступ к графическим функциям, функциям работы с базами данных и т.д.
Драйверы ввода-вывода. Современные SCADA-системы не ограничивают выбора аппаратуры нижнего уровня, так как предоставляют большой набор драйверов или серверов ввода-вывода и имеют хорошо развитые средства создания собственных программных модулей или драйверов новых устройств нижнего уровня. Сами драйверы разрабатываются с использованием стандартных языков программирования. Вопрос, однако, в том, достаточно ли только спецификаций доступа к ядру системы, поставляемых фирмой-разработчиком в штатном комплекте (система Trace Mode), или для создания драйверов необходимы специальные пакеты (системы FactoryLink, InTouch), или же, вообще, разработку драйвера нужно заказывать у фирмы-разработчика.
Для подсоединения драйверов ввода-вывода к SCADA используются два механизма стандартный динамический обмен данными (Dynamic Data Exchange DDE) и обмен по внутреннему (известному только фирме разработчику) протоколу. В SCADA-системах основным механизмом, используемым для связи с внешним миром, до сих пор остается механизм DDE. Но из-за своих ограничений по производительности и надежности он не совсем пригоден для обмена информацией в реальном масштабе времени. Взамен DDE компания Microsoft предложила более эффективное и надежное средство передачи данных между процессами OLE (Object Linking and Embedding включение и встраивание объектов). Механизм OLE поддерживается в RSView, Fix, InTouch, Factory Link и др. На базе OLE появляется новый стандарт OPC (OLE for Process Control OLE для АСУТП), ориентированный на рынок промышленной автоматизации. Новый стандарт, во-первых, позволяет объединять на уровне объектов различные системы управления и контроля, функционирующие в распределенной гетерогенной среде; во-вторых, устраняет необходимость использования различного нестандартного оборудования и соответствующих коммуникационных программных драйверов. С точки зрения SCADA-систем, появление OPC-серверов означает разработку программных стандартов обмена с технологическими устройствами. Поскольку производители полностью разбираются в своих устройствах, то эти спецификации являются для них руководством к разработке соответствующих драйверов. Так как эти программные драйверы уже появляются на рынке, разработчики SCADA-систем предлагают свои механизмы связи с OPC-драйверами. OPC-интерфейс допускает различные варианты обмена: получение сырых данных с физических устройств, из распределенной системы управления или из любого приложения (рис.2). На рынке появились инструментальные пакеты для написания OPC-компонентов, например, OPC-Toolkits фирмы FactorySoft Inc., включающий OPC Server Toolkit, OPC Client Toolkit, примеры OPC-программ.