Архитектура skada системы trace mode

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

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

2.2. Архитектурное  построение 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. Архитектура модульной SCADA.

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

• I/O - сервер ввода/вывода. Обеспечивает передачу данных между физическими устройствами ввода/вывода и другими модулями Citect.
• Display - клиент визуализации. Обеспечивает операторский интерфейс: отображение данных, поступающих от других модулей ^ Citect, и управление выполнением команд оператора.
• Alarms - сервер алармов. Отслеживает данные, сравнивает их с допустимыми пределами, проверяет выполнение заданных условий и отображает алармы на соответствующем узле визуализации.
• Trends - сервер трендов. Собирает и регистрирует трендовую информацию, позволяя отображать развитие процесса в реальном масштабе времени или в ретроспективе.
• Reports - сервер отчетов. Генерирует отчеты по истечении определенного времени, при возникновении определенного события или по запросу оператора.  
   
  В одной сети можно использовать только один сервер алармов, сервер трендов и сервер отчетов. В то же время допускается использование нескольких серверов ввода/вывода (I/O Server). Количество компьютеров с установленным модулем Display (обеспечивающим операторский интерфейс) в сети практически не ограничено. 
  

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

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

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

Концепция открытых систем предполагает свободное взаимодействие программных средств SCADA с программно-техническими средствами разных производителей. Это актуально, так как для современных систем автоматизации характерна высокая степень интеграции большого количества компонент. В системе автоматизации кроме объекта управления задействован целый комплекс программно-аппаратных средств: датчики и исполнительные устройства, контроллеры, серверы баз данных, рабочие места операторов, АРМы специалистов и руководителей и т. д. (рис. 3.1). При этом в одной системе могут быть применены технические средства разных производителей.  
Очевидно, что для эффективного функционирования в этой разнородной среде 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 до недавнего времени использовались два механизма (рис. 3.2): 

• DDE (Dynamic Data Exchange - динамический обмен данными); 
•  
  о бмен по собственным (известным только фирме-разработчику) протоколам.

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

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

 OPC – это аббревиатура от OLE for Process Control (OLE для управления процессами). Технология OPC основана на разработанной компанией Microsoft технологии OLE (Object Linking and Embedding – встраивание и связывание объектов). Под объектами здесь подразумеваются так называемые компоненты, которые представляют собой готовые к использованию мини-приложения. Встраивая и связывая эти компоненты, можно разрабатывать приложения компонентной архитектуры. Этот новый подход к разработке приложений, предложенный компанией Microsoft, получил название технологии COM (Component Object Model – модель компонентных объектов). Теперь приложение-клиент может удаленно вызывать те или иные функции этих объектов так, как будто объекты находятся «рядом». Объект может находиться и в самом деле рядом (в адресном пространстве приложения) - тогда это просто СОМ.  
OPC представляет собой коммуникационный стандарт, поддерживающий взаимодействие между полевыми устройствами, контроллерами и приложениями разных производителей. Стандарт OPC описывает компонентные объекты, методы и свойства (базирующиеся на технологии OLE/COM) для серверов данных реального времени, таких как PLC, DCS, систем архивирования данных и других, и обеспечивает передачу информации, содержащейся на этих серверах, стандартным OLE-клиентам. 
 
Стандарт состоит из трех основных спецификаций: 
 
- доступ к данным реального времени (Data Access); 
 
- обработка тревог и событий (Alarms & Events); 
 
- доступ к историческим данным (Historical Data Access).