Часть 1. История систем автоматизации
Часть 3. Мифы on-line модификации прикладного ПО ПЛК
SCADA (Supervisory Control And Data Acquisition) – вариант человеко-машинного интерфейса (ЧМИ), если перевести почти дословно – диспетчеризация, управление и обработка данных.
История развития ЧМИ
Первый ЧМИ систем автоматизации состоял из локально расположенных на объекте индикаторов, указателей, манометров, вентилей и подобных механических устройств. С развитием технологических процессов для контроля и управления объектом организовывались специальные помещения – операторные или диспетчерские. В этих помещениях размещались щиты с «щитовыми приборами»: манометры, механические, пневматические и электрические индикаторы и указатели, лампы сигнализации, самописцы и т.д. С появлением электронных систем управления в дополнение к щиту управления появились консоли ЭВМ с текстовыми монохромными мониторами на базе электронно-лучевой трубки, информация о технологическом процессе выводилась построчно в виде текстовых сообщений. С развитием первых электронных систем на монохромных текстовых мониторах начали отображать мнемосхемы технологического процесса с использованием символов псевдографики. Из-за недостаточной производительности и низкой надежности, первые электронные системы использовалась в качестве дублирующих к пневматической или электрической щитовой системе управления, на мониторах отображались только оперативные данные процесса для контроля и регулирования, система безопасности и сигнализации выполнялась на реле независимо от системы регулирования, история процесса «хранилась» в виде распечатанной на матричном принтере перфоленте.
С увеличением производительности вычислительной техники и появлением «объемных» устройств хранения данных (жестких дисков), системы управления эволюционировали в DCS и появились дополнительные функции:
накопление и возможность просмотра исторических данных о параметрах технологического процесса в виде таблиц, а позже в виде графиков-трендов;
формирование и хранение журнала сигнализаций;
многостраничные мнемосхемы технологического процесса;
функции управления оборудованием;
функции управления сигнализациями.
В это же время появился сам термин SCADA, который изначально относился к ЧМИ, реализованном на консоли DCS. В первых SCADA операторские консоли получали оперативные данные для отображения на мнемосхемах непосредственно из контроллеров, а для накопления исторических данных использовалась отдельная ЭВМ системы архивирования и хранения.
С появлением и развитием персональных компьютеров, SCADA выделилась в отдельный программный продукт, который уже не зависел от производителей DCS. Производители DCS в объеме своей системы управления поставляют SCADA как часть общего решения, и в этом случае SCADA максимально интегрирована с остальным оборудованием и программным обеспечением DCS. Но на рынке систем автоматизации появилось множество самостоятельных программных продуктов, которые используя стандартизированные протоколы могут интегрироваться с широким спектром ПЛК и программным обеспечением самых разных производителей.
Обзор решений SCADA
Основные функции SCADA:
обмен данными с ПЛК или другими устройствами;
формирование интерфейса для оператора (отображение оперативной информации о технологическом процессе, обработка действий оператора, мнемосхемы, панели и т.д.);
формирование сигнализаций по технологическим параметрам;
управления сигнализациями, формирование журнала сигнализаций (технологических, системных);
формирование журнала действий оператора;
формирование пользовательских отчетов;
накопление и предоставление оператору исторических данных о технологическом процессе (тренды);
обеспечение интерфейса внешних приложений к оперативным и историческим данным.
SCADA была и остается одним из вариантов ЧМИ. Реализация средствами SCADA контуров управления или защит для промышленных решений не допускается. Все контуры управления и защит должны быть реализованы в ПЛК и функционировать независимо от SCADA. Кратковременное нарушение связи между ПЛК и SCADA не должно приводить к невозможности выполнения функций управления или защиты.
Для реализации необходимого функционала в SCADA выполняется несколько процессов, которые также называют серверами, приложениями или задачами. В зависимости от реализации и необходимой производительности, все серверы, процессы и приложения SCADA могут выполняться на одном физическом хосте или могут быть распределены между несколькими хостами.
В самом простом вариант все функции, приложения и процессы реализованы в одном приложении и функционируют на одном физическом хосте (под хостом понимается физический компьютер). При этом приложение на хосте используется и для обработки и накопления данных (в качестве сервера в/в, сервера сигнализации и исторического сервера), и для реализации интерфейса оператора (операторская консоль), и в качестве инженерной станции (настройка и внесение изменений в SCADA). В простых решениях резервирование SCADA выполняется простым дублированием хостов с SCADA приложением, хосты полностью независимы, никакой синхронизации данных и выполняемых функций между хостами не предполагается, каждый хост самостоятельно обменивается данными с ПЛК и ведет независимые архивы. Такое решение имеет ряд недостатков: с увеличением количества хостов увеличивается нагрузка на сеть и интерфейсы контроллеров, при «простое» хоста исторические данные будут частично потеряны, все изменения конфигурации необходимо выполнять на каждом хосте, невозможно добиться полной синхронизации данных и событий по времени на разных хостах (хосты получают данные от ПЛК со сдвигом по времени). Если в системе более трех операторских консолей и объем в/в более 1000 переменных это решение уже не эффективно.
В более сложном варианте SCADA реализуется в клиент-серверной архитектуре, когда функции сервера в/в, сервера сигнализации, исторического сервера выполняются на одном высокопроизводительном хосте который называют SCADA-сервер, а для функций операторской консоли используются отдельные один или несколько хостов который называют SCADA-станция (станция оператора). Основная нагрузка по обработке данных в такой конфигурации ложится на SCADA-сервер. Станции оператора все данные получают с серверов и не имеют прямого доступа к ПЛК, обмен данными с ПЛК ведет только сервер. Пользовательская конфигурация SCADA хранится на сервере (конфигурация ввода/вывода, сигнализации, истории, экраны мнемосхем и т.д.).
В зависимости от реализации, изменения в операторском интерфейсе (мнемосхемы) могут автоматически реплицироваться с сервера на все станции оператора или копироваться на каждую станцию вручную.
Для больших систем как правило сервер в/в и сервер хранения истории выносят на отдельный хост, так как это наиболее ресурсоемкие процессы. В высокопроизводительных решениях для хранения всех данных (оперативных, исторических, конфигурации) используются SQL-серверы, некоторые разработчики дорабатывают стандартные SQL-серверы с целью увеличения производительности.
Практически во всех решениях SCADA-серверы резервируются. Резервирование реализуется двумя основными вариантами:
дублированные полностью независимые серверы, когда каждый сервер работает полностью независимо от другого, самостоятельно обменивается данными с ПЛК, независимо ведет историю процесса, формирует сигнализации и журналы. В данном решении нет понятия «основной» и «резервный» сервер. Внесение изменений в конфигурацию необходимо выполнять на каждом сервере. Синхронизация баз данных между серверами как правило не выполняется, хотя есть решения и с синхронизацией. Станции оператора в каждый момент времени подключены к одному из серверов, при отказе одного сервера станции переключаются на другой сервер. Переключение занимает некоторое время (до 10 секунд), что несколько «нервирует» операторов. Простота реализации обеспечивает достаточно высокую надежность и отказоустойчивость. В целом решение не очень удобное в эксплуатации, но вполне работоспособное для средних систем до пяти станций оператора.
«горячее» резервирование серверов, когда в каждый момент времени один сервер является «основным», второй «резервным». Под сервером в данном случае понимается не физический хост, а приложение или процесс, например сервер в/в или сервер сигнализации. Обмен данными с ПЛК ведет только основной сервер, резервный сервер синхронизирует свои базы оперативных и исторических данных с основным сервером. При отказе текущего основного сервера он переводится в режим «остановлен» или «резервный», а резервный переводится в режим «основной». При восстановлении отказавшего сервера, он в фоновом режиме синхронизирует репликации всех своих баз с основным сервером. В сложных решениях в нормальном режиме основные и резервные серверы (процессы, приложения) распределены между хостами, например основной сервер в/в будет на одном хосте, а основной сервер истории на другом. Станции оператора подключены к основному серверу (в некоторых решения возможно автоматическое распределение станций между основным и резервным сервером для балансирования нагрузки). При смене основного сервера станции переключаются «безударно», фактически никакого «переключения» нет, просто меняется путь к хосту основного сервера, оператор переключения не замечает. Решение с «горячим» резервированием более сложное, необходим эффективный алгоритм контроля работоспособности основного сервера, механизм распределения процессов между серверами, механизм синхронизации репликаций баз данных и контроль загрузки хостов и сети. Не у всех разработчиков решения содержат весь необходимый функционал, не всегда функционал выполнен качественно, не всегда обеспечена необходимая отказоустойчивость системы. На практике далеко не все решения, даже от крупных разработчиков, способны устойчиво работать при высокой нагрузке: более десяти операторских станций и десяти тысяч переменных (более 5 тысяч аналоговых переменных). При качественной реализации решение с «горячим» резервированием имеет несомненные преимущества, но стоимость будет значительно выше. При этом использовать бюджетные решения сомнительного качества на ответственных задачах очень рискованно.
Обмен данными SCADA с ПЛК или другими устройствами, сервер ввода/вывода
В общем случае, основной объем внешнего обмена данными SCADA ведет с ПЛК.
Объем потока данных между SCADA и ПЛК зависит от размера системы автоматизации, типа используемых данных, наличия в обмене дополнительной и диагностической информации, периода и временных интервалов между пакетами данных и т.д. Соответственно от параметров обмена данными будут зависеть необходимые для первичной обработки ресурсы. Процесс, обеспечивающий обмен данными с ПЛК и первичную обработку данных называется сервером ввода/вывода (далее сервер в/в).
Функции первичной обработки зависят от реализации SCADA и сервера в/в, в большинстве случаев это проверка целостности пакетов данных, выделение из пакетов значений переменных (иногда с метками времени), масштабирование переменных из «сырых единиц» в «инженерные единицы» если это требуется, буферизация данных, предоставление данных другим службам и процессам.
Если источником данных для SCADA является ОРС-шлюз, то он может выполнять часть функций по первичной обработки данных.
До широкого распространения OPC протокола все SCADA содержали внутренний набор драйверов для подключения ПЛК. Сейчас OPC протокол стал фактически универсальным средством обмена между разными приложениями в системах автоматизации. Все производители ПЛК в случае применения собственных закрытых протоколов передачи данных, предлагают OPC-шлюз или OPC-сервер для обеспечения интерфейса к SCADA.
Вторым универсальным и широко распространенным протоколом для обмена между SCADA и ПЛК является протокол Modbus в двух основных реализациях: Modbus-RTU поверх RS-485(232) и Modbus-TCP поверх Ethernet+TCP. Modbus наверно самый простой и легко реализуемый протокол, этим объясняется его популярность для простых решений, но при этом Modbus имеет ряд ограничений и недостатков, которые надо учитывать при построении ответственных систем.
В случае использования протокола Modbus или аналогичного, данные передаются от ПЛК к SCADA как набор битовых или байтовых пакетов (стандартная функция 0х04 Modbus – прочитать из ведомого устройства определенное количество байт начиная с указанного), деление полученного пакета на 1,2 или 4 байтные переменные и интерпретация переменных как целочисленные или с плавающей точкой выполняет сервер в/в в SCADA, поэтому правильное распределение и интерпретация данных является ответственностью разработчика конфигурации ввода/вывода. Метка времени данных практически никогда не используется, фактически ведущее устройство Modbus (мастер) получает данные из буфера ведомого устройства. В большинстве решений актуальность данных в буфере ПЛК не контролируется, протокол Modbus этого не предполагает, контроль работоспособности ПЛК и актуальности данных необходимо выполнять в прикладной программе (частое решение, контрольный бит с периодическим переключением). При нестабильной работе сети, с учетом повторных запросов и таймаутов, данные могут поступать в SCADA со значительным запаздыванием (в зависимости от настроек сети и протокола до нескольких секунд), что может быть критично для объектов автоматизации с высокой степенью ответственностью. Но для большинства задач передача данных в SCADA с запаздыванием не критична, а при небольшом объеме данных и правильно построенной и штатно работающей сети, запаздывание составляет доли секунды.
Кроме Modbus существует много других открытых стандартизированных промышленных протоколов, которые также очень широко применяются в разных задачах автоматизации. В свободном доступе можно найти как спецификации по этим протоколам, так и другую разнообразную информацию, дающую представление о достоинствах, недостатках и области применения.
Практически все промышленные протоколы передачи данных выполняют контроль целостности данных, как минимум проверяется четность или контрольная сумма.
Производительность SCADA определяется в первую очередь пропускной способностью интерфейсов обмена данными с ПЛК и производительностью сервера в/в. В сложных решениях, предназначенных для объектов с высокой степенью ответственности, производители используют собственные проприетарные протоколы, позволяющие детерминировать время обмена, обеспечивающие контроль актуальности данных в ПЛК, и передачу данных из ПЛК с метками времени. Практически все решения основаны на Ethernet+TCP и позволяют передавать большие объемы данных и служебной информации. Для интеграции ПЛК с проприетарным протоколом к сторонним SCADA производители ПЛК предоставляют OPC-шлюз.
Функции преобразования данных и масштабирования значения переменных сервером в/в.
Простые ПЛК часто работают только с целочисленными переменными. Например, аналоговый вход 4-20мА в простом ПЛК выглядит как двухбайтовая беззнаковая целочисленная переменная, принимающая значение от 0 до 65535. При подключении к ПЛК датчика температуры со шкалой от -50 до +50 градусов, в ПЛК «инженерным единицам» температуры -50 будет соответствовать значение в «сырых единицах» 0, а «инженерным единицам» температуры +50 будет соответствовать значение в «сырых единицах» 65535. Если ПЛК не может работать с переменными с плавающей точкой, чтобы в SCADA передать показания датчика температуры с максимальной точностью, правильно из ПЛК в SCADA передать значение в «сырых единицах», т.е. в виде целочисленной двухбайтовой переменной со значением 0...65535, а масштабирование в «инженерные единицы» -50...+50 с преобразованием в 4-х байтовую переменную с плавающей точкой выполнить в сервере в/в SCADA.
Функции преобразования могут использоваться при работе с булевыми переменными. Часто в SCADA из ПЛК передается переменная в виде «слова состояния» – одно или двух байтовая переменная, в которой каждый бит является флагом (например, слово состояния для насосного агрегата, где 1-й бит будет флагом состояния «стоит/работает», 2-й бит - «норма/авария», 3-й бит - «готов/не готов», 4-й бит – режим управления «мест/дист» и т.д. Использование «слова состояния» вместо набора булевых переменных – очень хорошая практика. Если функционал SCADA не позволяет обращаться непосредственно к битам в слове (указать через точку номер бита в слове), то в сервере в\в SCADA необходимо извлечь из «слова состояния» значения необходимых битов и сформировать внутренние булевых переменные, которые можно будет использовать в других процессах SCADA (для анимации мнемосхем, формирования сигнализации и т.д.).
Так же очень хорошей практикой является использование в SCADA и ПЛК иерархических объектно- ориентированных структур данных. Например, для насоса создается структура PUMP которая содержит набор данных (перечень очень условный):
PUMP.current – токовая нагрузка, 4-х байтовая переменная;
PUMP.work – флаг состояния «стоит/работает», булевая переменная;
PUMP.mode – флаг режима управления «мест/дист», булевая переменная;
PUMP.fault – флаг исправности «норм/авар», булевая переменная;
и т.д.
Использование структур данных значительно облегчает разработку проекта в SCADA и позволяет избежать лишних ошибок при использовании данных в различных приложениях, но несколько увеличивает нагрузку на сервер в/в. Возможность создания и использования иерархических объектно-ориентированных структур данных в SCADA и ПЛК является несомненным преимуществом, но не все решения имеют такой функционал.
Метка времени значения переменной
Метка времени значения переменной нужна в первую очередь для контроля актуальности данных, построения последовательности событий и корректного формирования журналов событий и сигнализации.
В сложных решениях метка времени значению присваивается в модуле в/в ПЛК, при этом значение переменной имеет наиболее актуальную метку времени, т.е. время, когда значение поступило на вход модуля ввода. В более простых решениях метка может присваиваться центральным процессором в момент получения значения от модуля ввода, но если время передачи пакетов от модуля ввода до центрального процессора не детерминировано, то ошибка метки времени не предсказуема (например, если процессор опрашивает модуль по протоколу Modbus).
В простых решениях присвоение метки времени значению переменной выполняется в сервере в/в или в ОРС-шлюзе. В самом простом решении метка времени для значения переменной вообще не используется, значение сопоставляется со временем только при записи в базу сервера истории или в журнал сигнализации, т.е. для значения указывается текущее время сервера на момент выполнения записи в журнал или базу.
Если метка времени присваивается в сервере в/в, а тем более в сервере истории или сервере сигнализации, то метка времени носит очень условный характер, и зависит от используемого протокола, пропускной способности и загрузки сети, порядка формирования данных в буфере обмена ПЛК и сервера в/в и т.д. В результате - события, которые являются следствием, могут иметь метку времени такую же или более раннюю, чем метка времени причины (например, при закрытии пневматического отсечного клапана, концевой выключатель «закрыто» может иметь метку времени раньше, чем было отключено питание на соленоид).
На практике необходимость построения последовательности событий с использованием метки времени с точностью до нескольких миллисекунд встречается только в сложных и быстротекущих технологических процессах. Если задача автоматизации не требует сложного и детального анализа последовательности событий с высокой точностью, то нет смысла переплачивать за невостребованный функционал.
Формирование и обработка сигнализаций
Все сигнализации в SCADA можно условно разделить на следующие группы:
Технологические сигнализации – формируются при изменении состояния параметров технологического процесса или оборудования, например выход параметра за границу установленного диапазона, закрытие клапана, включение насоса и т.д. Основное назначение технологической сигнализации – привлечь внимание оператора к изменению параметра технологического процесса или состоянию оборудования, если это изменение требует корректирующих действий или корректирующее действие может потребовать в течении какого то времени.
Системные сигнализации – формируются при выявлении опасных ошибок или отказов в системе автоматизации, когда требуется вмешательство специалиста. Например, отказ одного сервера из резервированной пары.
Сигнализации по событиям или действиям оператора – формируются при регистрации события или действия оператора, которые могут иметь важное значение для технологического процесса. Например, отключение защит по насосному агрегату. Основное назначение – проинформировать весь оперативный персонал о важном событии.
В зависимости от реализации SCADA, в самых простых решениях технологические сигнализации могут формироваться в сервере в/в, в сложных решениях в отдельном процессе – сервере сигнализаций, в решениях для задач высокой степени ответственности флаги сигнализации для параметров технологического процесса формируются непосредственно в модуле ввода/вывода ПЛК или в прикладной программе центрального процессора и обрабатываются в SCADA в сервере сигнализации.
Формирование флагов сигнализации с метками времени в ПЛК с последующей передачей в SCADA позволяет более точно и корректно сформировать последовательность событий и журналы сигнализации, но значительно увеличивает нагрузку на ПЛК и канал передачи данных от ПЛК к SCADA. Необходимость такого решения в каждом конкретном случае должна быть обоснована. Для большинства задач, когда флаги сигнализации не используются в прикладной программе ПЛК и формирование последовательности событий с точностью до миллисекунд не требуется, целесообразно формировать флаги сигнализации в SCADA.
Технологические сигнализации в большинстве задач автоматизации рассматриваются как часть системы безопасности технологического процесса, поэтому сервер сигнализации как вычислительный процесс имеет высокий приоритет, что позволяет оперативно обрабатывать поступающую информацию, формировать флаги сигнализации и изменение звуковой и световой сигнализации на интерфейсе оператора.
В большинстве SCADA решений в сервере сигнализации реализована система приоритетов, т.е. каждому флагу или событию можно назначить необходимый уровень важности, и для каждого уровня определяется порядок и последовательность обработки событий, более важные события обрабатываются первыми. Группировка по приоритетам позволяет акцентировать внимание оператора на более важных событиях с более высоким приоритетом, а также определяет порядок отображения событий на мнемосхемах и сортировку событий в оперативных журналах.
Основной принцип «философии» построения системы сигнализации – предоставить оператору максимум той информации, которая нужна ему в данный момент для принятия решения и выполнения корректирующих действий, и не загружать операторский интерфейс информацией, которая в данный момент для оператора не имеет значения. Разработка системы сигнализации в соответствии с «философией» требуется для средних и больших систем автоматизации, содержащих более пятисот параметров сигнализации.
Система управления сигнализациями может несколько отличаться в разных реализациях SCADA . В сложных решениях «философия» системы управления сигнализациями хорошо продумана и многие функции реализованы производителем. В простых решениях производитель предоставляет базовый функционал без какой-либо «философии», и реализация управления системой сигнализации полностью выполняется в прикладной конфигурации силами инженеров.
Пример «философии» управления сигнализацией.
Формирование приоритетов для событий:
Наивысший – события в системе безопасности технологического процесса, требующие немедленных оперативных действий.
Высокий – события технологического процесса, требующие от оператора вмешательства.
Нормальный – события технологического процесса, о которых оператор должен быть проинформирован.
Низкий – события, которые не имеют для оператора какой-либо важности.
На станции оператора на всех экранах (мнемосхемах) должно быть выполнено постоянное окно на 10-15 строк для вывода оперативных сигнализаций. Сигнализации с наивысшим и высоким приоритетом должны выводиться в верхней части окна и выделяться цветом (красный, желтый). Сигнализации с нормальным приоритетом должны выводится в окно ниже более приоритетных сообщений.
Содержание сообщения должно включать время и технологическую информацию, позволяющую оператору идентифицировать событие и принять необходимое решение (технологическая позиция, описание позиции и причина сигнализации, граница технологического параметра, текущее значение технологического параметра и т.д.)
Сортировка сообщений в оперативном окне должна выполняться по времени поступления и приоритету, на самой верхней строчке окна будет последнее поступившее сообщение с наибольшим приоритетом. На мнемосхеме технологические позиции, находящиеся в зоне сигнализации, также должны выделяться цветом (цветная рамка вокруг технологической позиции). Сообщение о переходе параметра в зону сигнализации для параметров с наивысшим, высоким и нормальным приоритетом должно сопровождаться коротким звуковым сигналом, сигналы должны различаться в зависимости от приоритета сообщения.
Сигнализации нормального, высокого и наивысшего приоритета должны быть «приняты» оператором, т.е. оператор должен подтвердить прием сигнализации нажатием кнопки «принять сигнализацию». Допускается специальной кнопкой принять все сигнализации отображенных в оперативном окне, но при этом принимаются только те сигнализации, которые видны оператору. Сообщения, находящиеся за видимыми пределами окна должны быть выведены в видимую часть окна (например постраничным пролистыванием), просмотрены оператором и осознанно приняты. В литературе факт принятия оператором сигнализации имеет наименование «квитирование».
Сообщение в окне сигнализации до приема оператором должно выделяться градацией цвета или «миганием». Для сообщений высокого и наивысшего приоритетов после приема оператором сообщение остается в оперативном окне, пока технологический параметр находится в зоне сигнализации. После возврата технологического параметра в зону рабочего значения, принятая оператором сигнализация удаляется из оперативного окна.
Для сообщений с нормальным приоритетом принятое оператором сообщение сразу удаляется из оперативного окна.
События с низким приоритетом, не представляющие интереса для оператора, в оперативное окно не выводятся и звуковая сигнализация не формируется, для таких событий выполняется только запись в журнале сигнализации. Такие сигнализации называются в литературе «события».
Для всех событий по всем сигнализациям независимо от приоритета формируется запись в журнале сигнализаций. Отдельная запись формируется для каждого события: параметр вошел в зону сигнализации, сообщение о сигнализации принято оператором, параметр вышел из зоны сигнализации. Содержание записи должно быть максимально полным (обычно запись в журнале содержит больше информации о событии, чем запись в оперативном окне), чтобы в последствии при необходимости можно было детально проанализировать все события.
Средства просмотра журнала сигнализации должны обеспечивать возможность фильтрации, сортировки и поиска записей, выгрузки сформированного списка записей в файл. Необходимая глубина журнала определяется задачей автоматизации, обычно глубина составляет 30-90 суток.
Решения SCADA предназначенные для сложных технологических процессов, содержат дополнительный функционал для управления сигнализациями – группировка, подавление ручное и автоматическое, анализ ложных или избыточных срабатываний. В основном такой функционал реализован в SCADA для DCS от ведущих производителей и ориентирован на определенные технологические процессы.
Количество активных сигнализаций при нормальном режиме работы объекта должно быть минимальным, в хорошо организованной системе сигнализации допустимым считается не более 10 сообщений. Сообщений нормального и высокого приоритета, которые по факту не требуют действия оператора, в хорошо организованной системе должно быть не более 10 в час (критерий очень условный). При большом количестве избыточной сигнализации, оператор перестает своевременно реагировать на новые сообщения и может пропустить важное событие.
Если на действующем объекте на нормальном технологическом режиме в оперативном окне постоянно находится более 10 активных сообщений, или каждые несколько минут срабатывает звуковая сигнализация, которая по факту не требует действий оператора, то что-то сделано не правильно. В первую очередь необходимо проанализировать значения уставок сигнализации, если параметры процесса в нормальном режиме находятся на границе сигнализации или за границей, разумно пересмотреть границы сигнализации или рабочие значения технологических параметров (например, предупредительная сигнализация по верхнему уровню в колонне установлена на 80%, но оператор по технологическим причинам вынужден держать рабочее значение в диапазоне 70-75% и при небольших допустимых колебаниях процесса срабатывает предупредительная сигнализация, разумно изменить уставку сигнализации с 80 на 85%, что значительно уменьшит избыточную сигнализацию или снизить рабочее значение уровня до 65-70%).
Сложные объекты автоматизации обычно содержат большое количество резервированного технологического оборудования. Находящееся в резерве, остановленное или выведенное в ремонт технологическое оборудование может быть причиной избыточной сигнализации. Дополнительный функционал по управлению сигнализациями в сложных SCADA содержит инструменты для построения иерархической структуры сигнализации на основе технологических участков, блоков и технологического оборудования, с возможностью подавления избыточной сигнализации до единицы оборудования или технологического участка.
Подавление избыточной сигнализации может быть автоматическим, например для оборудования, находящегося в резерве по тем технологическим параметрам, которые будут в зоне сигнализации до ввода оборудования в работу (например давление нагнетания на резервном насосе будет в зоне сигнализации по низкому значению до пуска насоса).
«Ручное» подавление избыточной сигнализации используется для оборудования, выведенного в ремонт или демонтированного. Например, насос выведен в ремонт и на нем отключены и демонтированы все приборы. Для исключения избыточной сигнализации необходимо подавить всю сигнализацию по этому насосу. В SCADA насос переводится в режим «техобслуживания», сигнализация подавляется, но и пуск насоса невозможен до выключения режима «техобслуживания». Вывод оборудования в ремонт - это очень ответственная операция, поэтому управление оборудованием в SCADA должно быть выполнено на отдельной странице с доступом только начальника смены или другого ответственного руководителя объекта.
Еще один пример автоматического подавления сигнализации - это сложные технологические объекты, когда изменение состояния объекта вызывает целую цепочку следствий и формированию большого количества сообщений в системе сигнализации. Например, технологическая печь с двадцатью горелочными устройствами. В результате нарушения технологического режима на объекте происходит отключение печи, закрываются отсечные клапаны на коллекторе основного газа. Следствием это события будет погасание пламени на всех горелочных устройствах (сигнализация от датчиков контроля пламени), закрытие всех индивидуальных отсечных клапанов на горелочных устройствах, падение давления в коллекторе, увеличение разряжения в топке и т.д. В результате одного события – отключение печи, в оперативный журнал сигнализации будет выдано более 50 сообщений, которые для оператора уже не представляют важности. При этом сообщения о других событиях, которые действительно важны для оператора, будут «потеряны» в общем потоке. При наличии правильно выполненной системы подавления сигнализации, в оперативный журнал поступит только одно сообщение об отключении печи, а вся избыточная сигнализацию по печи, которая является следствием отключения, будет подавлена.
К реализации автоматического подавления сигнализации надо относится очень аккуратно и осознано, с глубоким пониманием технологического процесса. Например, по системе контроля загазованности на взрывопожароопасном объекте и аналогичным системам безопасности, а также для сигнализации с наивысшим приоритетом, ручное и тем более автоматическое подавление сигнализации не допускается.
Если вы приобрели дорогую систему DCS, потратьте время и изучите все ее возможности и «философию» решений, такие системы содержат готовый и развитый функционал, который надо понять и научится корректно использовать. На практике в дорогих SCADA в большинстве случаев используется не более 30% функционала системы, приобретенные ресурсы используются крайне нерационально.
Исторические данные и сервер истории
Исторические данные о технологическом процессе нужны в первую очередь для анализа изменения технологического режима, выявления причины отклонений от режима, контроля за работой и настройки ПИД-регуляторов . Также исторические данные могут использоваться для построения технологических отчетов, режимных листов.
Иногда исторические данные используют для расчета материального и энергетического баланса технологического объекта, но в этом случае для корректного расчета балансов из ПЛК или КИП (расходомеров) в сервер истории SCADA должны передаваться значения сумматоров с накоплением, если просто интегрировать мгновенные значения КИП (тренд текущих значений), то сумма будет некорректной.
База данных для хранения истории.
В 90-х годах в простых решениях для хранения истории широко применялись «плоские файлы», когда в двоичный файл с заданной периодичностью записывается 4-х байтовое значение переменной. Размер файла равен суточному объему данных с учетом периодичности записи, файл создается в первую секунду суток и заполняется значениями по мере их поступления. Чтобы рассчитать метку времени для любого значения в файле нужно определить порядковый номер значения от начала файла и умножить на период записи. Количество файлов соответствовало количеству переменных, для которых велась история процесса. Для уменьшения количества одновременно открытых файлов применялась буферизация с периодической записью значений из буфера в файл. Прямой доступ к файлам позволял не использовать функции операционной системы (Windows) для работы с базами данных, что значительно повышало производительность чтения-записи. Всю обработку данных, процесс записи, чтения и выборки, необходимо было реализовать в SCADA. Такое решение имело много ограничений, но для небольших систем позволяло использовать в качестве хостов простые ПК (компьютеры) и не приобретать дорогое серверное железо, и это было большим преимуществом.
Также для простых решений широко применялись и применяются файловые базы данных типа dBase или аналогичные. Для работы с базой данных SCADA может использовать стандартный драйвер операционной системы или собственный драйвер, адаптированный под задачи системы и более производительный. Такое решение не требует наличия SQL-сервера и может работать практически на любой аппаратной платформе, требования к аппаратной платформе будут зависеть от объема данных. При использовании файловой базы большую часть функций по работе с данными необходимо реализовывать в SCADA системе, соответственно качество работы, функционал и производительность сервера истории сильно зависит от разработчика SCADA. С учетом современного развития аппаратных средств ограничение для файловых баз данных скорее связано с возможностями SCADA и операционной системы. В целом решение с файловой базой данных вполне приемлемо для небольших серверов истории до 1000 переменных.
В более сложных решениях для хранения исторических данных используются SQL-серверы. Для обеспечения максимальной производительности многие разработчики оптимизируют стандартные SQL-серверы и используют собственный или доработанный драйвер для доступа к базам. Для высокопроизводительных решений использование SQL сервера требует соответствующей аппаратной платформы и определенной коммерческой версии SQL-сервера, и в целом решение получается достаточно дорогое.
Разработчики SCADA систем, ориентированные на средний сегмент рынка автоматизации, для снижения стоимости решений все чаще используют варианты SQL-серверов свободные от лицензирования. С учетом текущего развития аппаратных средств вычислительной техники и свободных SQL-серверов, предлагаемые решения обеспечивают необходимую производительность и функционал для большинства задач автоматизации.
Использование SQL сервера для средних систем имеет несомненные преимущества:
Масштабирование под задачу, SQL сервер может быть установлен на хосте с сервером в/в, на отдельном хосте с необходимой аппаратной платформой, а для очень больших задач может применяться кластерное решение, возможности масштабирования бесконечные и масштабирование реализуется средствами самого SQL сервера;
для резервирования серверов, синхронизации, репликации и резервного копирования данных используются встроенный функционал SQL-сервера;
SQL-сервер включает большое количество встроенных функций для обработки данных;
SQL сервер используется не только для хранения истории процесса, но и для всех журналов, а также для хранения конфигурации и настройки самой SCADA.
Собственный внутренний функционал SQL сервера значительно облегчает задачи разработчику SCADA по хранению и обработке любых данных, обеспечению сохранности, резервному копированию, экспорту в сторонние приложения, обслуживанию баз данных и т.д., при этом SQL сервер - это качественный продукт, который тестируется и используется большим сообществом пользователей.
Объем базы исторических данных и требования к производительности сервера истории сильно зависят от настройки периода записи.
Для очень грубого расчета в качестве примера можно принять следующие условия: 5000 переменных с плавающей точкой (4 байта) и меткой времени (8 байт), период записи 1 секунда, при очень грубом подсчете получаем объем данных порядка 200 мегабайт в час или 5 гигабайт в сутки. При глубине хранения 30 суток получим объем порядка 150 гигабайт. При текущем уровне развития систем хранения объем не критичный, но и количество переменных и глубина архива может быть значительно больше.
Для расчета производительности сервера истории надо учитывать, что одновременно выполняется запись поступающих данных и несколько потоков чтения, если операторы просматривают историю процесса на разных станциях. Дополнительно требуется обработка данных, создание временных таблиц, расчет усредненных или аппроксимированных данных для вывода на экран, построение отчетов с обработкой значений за час, смену или сутки.
Для снижения нагрузки на сервер истории как правило формируются несколько групп исторических данных с разным периодом записи: условно быстрые 1 сек и медленные 5 - 30 сек.
В простых решениях обычно не предусматривается какой-либо предварительной обработки данных и просто записывается текущее значение. В более сложных решениях для получения более объективных данных сервер истории выполняет расчет среднего (средневзвешенного) максимального и минимального значения за период между записями. Соответственно в последствии можно проанализировать средние, максимальные и минимальные значения технологического параметра.
Для отображения истории процесса в SCADA используются специальные окна или экраны. В большинстве решений SCADA имеет развитый функционал для настройки масштабирования как по значению, так и по временному интервалу. Как правило в одном окне может отображаться до 16 перьев (трендов, переменных), большее количество перьев тяжело воспринимается оператором. Тренды могут быть сгруппированы в предопределенные экраны по единицам оборудования или технологическим блокам. Линия тренда может строится «ломанной» по точкам значений технологического параметра, или может использоваться аппроксимация для сглаживания.
Во многих решениях для отображения истории технологического процесса используются два типа трендов: оперативные тренды и исторические тренды. Оперативный тренд обычно составляет 10-30 минут от текущего времени и содержит все полученные сервером в/в значения для более детального анализа. Оперативный тренд хранится в оперативной памяти или буфере и не предназначен для долговременного хранения. Как правило накопление значений для оперативных трендов ведется с момента открытия соответствующего окна, если окно закрыть – накопленные данные не сохраняются, при повторном открытии окна запись начинается заново, соответственно нет возможности пролистывания по времени глубже установленного периода 10-30 минут. Исторические тренды хранятся в архиве сервера истории, период записи зависимости от настройки времени для группы. Оперативные тренды предназначены для оперативного контроля технологических параметров, например для контроля стабильности процесса – если линии тренда «ровные», значит объект работает стабильно и не требуется дополнительный анализа и вмешательство в технологический процесс. Оперативные тренды часто используются при настройке ПИД-регуляторов или других инструментов управления технологическим режимом.
В зависимости от решения в SCADA для просмотра оперативных и исторических трендов могут использоваться разные средства. В простых решениях для просмотра оперативных трендов используются всплывающие окна, а для просмотра исторических трендов необходимо открыть специальный экран, просмотр в одном окне оперативных и исторических трендов невозможен. В сложных решениях текущие и исторические тренды могут отображаться в одном окне, система строит линию тренда используюя и исторические и текущие значения, и для оператора не существует понятия «оперативные» и «исторические» тренды, он просто видит историю процесса и не задумывается, как система строит график используя исторические и оперативные значения.
Тренды или графики истории технологического процесса – это очень удобный инструмент не только для анализа ранее произошедших событий (отказов, остановов, сбоев в технологическом процессе, отклонения от норм технологического режима), но и для оперативного контроля технологического режима и стабильности технологического процесса. Для сложных технологических процессов рекомендуется на многомониторной станции оператора, один монитор специально определить для постоянного отображения трендов. Оператор должен иметь возможность вывести на монитор несколько групп трендов, сгруппированных по оборудованию, технологическому блоку или произвольному набору технологических параметров. Визуализация изменения технологических параметров позволяет оператору быстро «одним взглядом», оценивать стабильность технологического режима без «пролистывания» нескольких экранов мнемосхем, и своевременно реагировать на отклонение режима.
Построение интерфейса оператора
Для взаимодействия оператора с технологическим объектом в всех современных SCADA используется графический интерфейс, позволяющий визуализировать информацию о технологическом процессе в виде экранов мнемосхем, детальных окон, графиков, таблиц и т.д. Экраны мнемосхем содержат статические объекты – колонны, трубопроводы, эскизы оборудования и т.д., и динамические объекты, отображающие значения параметров технологического процесса, цифровые и текстовые индикаторы, пиктограммы и элементы анимации, сигнализирующие о состоянии оборудования или КИП.
Простые решения содержат набор графических примитивов, пиктограмм и средства построения элементов отображения, анимации и управления. Например, для отображения насоса с шестью состояниями (остановлен, работает, авария, выведен в ремонт, готов к пуску, не готов к пуску) необходимо подобрать шесть соответствующих иконок, сформировать форму отображения, подготовить скрипт, который будет анимировать форму в зависимости от состояния переменной, а также выполнять действия по клику мышкой или нажатию комбинации клавиш. На одной форме может использоваться несколько наборов иконок для разных переменных, тогда объем работы увеличивается. Для среднего объекта автоматизации набор анимированных форм может измеряться сотнями. Понятно, что разработка на «простой SCADA» из примитивов всего объема графических элементов требует значительного времени, а также требуется длительная отладка для выявления максимального числа неизбежных ошибок, которые вносятся инженерами в процессе разработки.
В более сложных решениях большинство элементов интерфейса уже содержатся в пакете разработки SCADA, и этих элементов достаточно для построения большинства мнемосхем под самые разные задачи. Элементы содержат все необходимые скрипты, иконки, действия, настройка элемента под определенные задачи выполняется конфигурацией (постановкой-снятием галочек), что не только ускоряет процесс разработки интерфейса, но и уменьшает количество потенциальных ошибок. Максимальное использование «встроенного функционала» SCADA обеспечивает большее быстродействие, более устойчивую работу и возможность миграции на новые релизы программных пакетов без необходимости повторной переработки всего проекта. Многие молодые инженеры считают встроенный функционал «урезанным», «недостаточно гибким» и «серым», и для внесения индивидуальности в проект наполняют его элементами собственной разработки, что неизбежно вызывает сложности при дальнейшей эксплуатации и обновлении версий. Если вы купили дорогую SCADA, в которую разработчики уже вложили большое количество труда, в том числе и в отладку встроенного функционала, правильно изучить этот функционал и максимально использовать.
Сложные SCADA, в основном входящие в состав DCS систем, кроме набора графических элементов содержат и определенную «философию» построения интерфейса оператора.
В качестве элементов философии можно обозначить следующие требования:
Доступ к любой мнемосхеме, экрану или окну должен выполняться максимум в три клика мышкой, или нажатием предопределенной комбинации клавиш или клавиши на «функциональной клавиатуре» (меню - основное окно – дополнительное окно – детальное окно);
Цветовые решения для фона и рисунков – максимально должны использоваться оттенки серого цвета (колонны, трубопроводы, эскизы оборудования и т.д.);
Количество цветных элементов на мнемосхеме должно быть минимальным;
Цветные пиктограммы используются для отображения параметров процесса и элементов управления (показания приборов, клапаны, приводные задвижки и т.д.);
Желтый и красный цвет используется для предупреждающей и аварийной сигнализации, зеленый для нормальных значений технологического режима;
Оператор не должен «рассматривать» мнемосхемы с целью поиска отклонений технологического режима, все отклонения должны выявляться системой управления с формированием предупредительной сигнализации;
Оператор должен иметь возможность быстро проанализировать причины сигнализации и получить максимальную информацию о причинах отклонения технологического режима;
Количество сигнализаций должно быть минимальным;
Использовать специальные панели для предоставления сводной информации о текущем состоянии сигнализации по технологическому участку или группе оборудования – количество активных принятых/непринятых сообщений для каждого уровня приоритета;
Любые цветовые изменения на мнемосхеме должны привлекать внимание оператора и требовать выполнения корректирующих действий;
Минимизация или исключение на мнемосхемах информации, не связанной с управлением технологическим процессом. Не надо «перечерчивать» технологические схемы с рабочей документации, отображать вспомогательные линии (пароспутники, энергосреды, азот, воздух КИП и т.д.), это перегружает интерфейс и не несет какого-либо смысла для оператора;
Максимально использовать «поточную схему», движение технологических сред слева-на право, без петель и множественных пересечений;
Не надо прорисовывать все технологические линии, можно использовать разрывы линий;
Вспомогательные КИП могут отображаться без привязки к линиям (например, давление азота или пара на установку);
Не надо стараться сохранить пропорции аппаратов;
Мнемосхема – это не лист технологической схемы из проекта и не фотография технологического объекта, это схема управления объектом;
Минимальная детализация основной мнемосхемы, редко используемые элементы управления целесообразно вынести на отдельный экран или всплывающие окна (например, панель управления розжигом печи, панель управления насосом, панель зонных датчиков температуры реактора, мнемосхема с межблочными отсекателями);
Отдельные мнемосхемы для регулирования технологического режима, отдельные для пусковых операций, переключений и противоаварийной защиты.
Детальная «философия» для построения интерфейса оператора зависит от сложности и особенностей объекта автоматизации и требований заказчика.
Большинство реализаций SCADA, кроме самых простых, обеспечивают поддержку нескольких мониторов (дисплеев) на одной станции оператора. Многодисплейная станция – это не расширение средствами операционной системы одного рабочего окна на несколько мониторов, а поддержка в SCADA с возможностью распределения задач и функционала между несколькими дисплеями. Один дисплей настраивается для просмотра мнемосхем основного технологического процесса, второй для отображения и управления оперативными сигнализациями и трендами, третий для специальных мнемосхем и экранов системы безопасности (загазованность, управление межблочных отсекателями, панели аварийного останова и т.д.), четвертый для оперативного управления динамическим оборудованием, управления печами, детальные дисплеи ПИД-регуляторов и т.д. Разделение функционала SCADA между дисплеями также является частью «философии» системы управления.
В качестве инструмента для отображения на мониторах в большинстве современных SCADA используется язык структурированной разметки HTML, поэтому многие SCADA позволяют формировать WEB страницы для удаленного просмотра мнемосхем через браузер. Функционал и возможности работы со SCADA через браузер обычно сильно ограничены и зависят от конкретной реализации.
Многие крупные заказчики в технических заданиях в качестве одного из критериев для SCADA указывают время открытия экрана мнемосхемы и время обновления значений на экране. Это не совсем корректно. «Медленная» обработка экранов характерна для совсем простых решений в следствии их слабой проработки, и для очень сложных решений, входящих в состав DCS из-за большого объема функционала, связанного с обработкой экранов. Использование HTML тоже не предполагает высокого быстродействия. Чтобы обеспечить приемлемое время обновления экранов в сложных решениях нужно следовать заложенной в DCS философии построения интерфейса оператора. На практике, время открытия экранов в 1-3 секунды и обновление значений до 1 секунды можно считать приемлемым.
На сегодня на рынке автоматизации представлен очень широкий спектр самых разных решений SCADA, от простого встроенного WEB-интерфейса ПЛК до сложной клиент-серверной архитектуры с большим набором дополнительного функционала в DCS.
Выбор конкретной SCADA, ее функционала, топологии построения, аппаратной и программной реализации будет зависеть от требований объекта автоматизации.
