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

Существует два типа управления удаленными объектами в 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-программ.