Scada система что это такое

Что такое SCADA

Слово SCADA означает «Диспетчерское управление и сбор данных». Определение четко объясняет, каковы функции и цели системы SCADA, а именно надзор, контроль и сбор данных.

Система SCADA является частью архитектуры, которая включает в себя:

• Один или несколько компьютеров, соединенных друг с другом, которые выполняют функции управления и реализуют человеко-машинный интерфейс (HMI)
• Серия периферийных устройств (RTU, модули ввода/вывода, ПЛК), которые взаимодействуют с процессом (машины, установки и т.д.) через датчики и исполнительные механизмы
• Сеть связи с различными носителями передачи и протоколами связи, способная обеспечить правильный обмен данными между периферийными устройствами и диспетчерскими компьютерами

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

Надзор

ДЕМО

Надзор — это функция, которая позволяет оператору иметь непосредственное представление о состоянии процесса и контролировать, как процесс развивается с течением времени, анализируя последовательность рабочих состояний.

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

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

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

Контроль

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

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

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

Сбор данных

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

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

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

Что такое программное обеспечение SCADA

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

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

Однако все программное обеспечение SCADA, независимо от сложности, должно иметь общие черты в отношении следующих тем:

• Коммуникация: набор средств разработки и коммуникационных драйверов для взаимодействия с большинством электронных устройств (ПЛК, контроллеров, счетчиков и т.д.) от различных производителей, работающих на рынке промышленной автоматизации. Он позволяет строить БД переменных для обмена с внешними устройствами и включает в себя наиболее распространенные протоколы связи, такие как OPC, Siemens, Omron, Allen Bradley, Modbus RTU, Modbus TCP, KNX, Bacnet и др.
• Человеко-машинный интерфейс (HMI): набор инструментов разработки и графических библиотек для создания статических и анимированных шаблонов. Важно подчеркнуть важность графики при разработке приложения SCADA. Человеко-машинный интерфейс (HMI) на самом деле тем эффективнее, чем больше он способен предоставить оператору оперативное и полное изображение всего процесса, выделяя состояние, эволюцию и неожиданные отклонения (сигналы тревоги).
• Информация о процессе: набор инструментов разработки, позволяющих оператору иметь всю информацию, описывающую текущее состояние процесса (онлайн-данные) и его эволюцию с течением времени (исторические данные). Например, чтобы позволить оператору оперативно уведомляться в случае неисправности или анализировать графические тенденции отслеживаемых и записанных переменных процесса.
• Отчеты: набор инструментов разработки для сортировки и обработки информации, полученной в результате процесса, с целью создания отчетов для менеджеров по производству и качеству. Отчеты обычно относятся к конкретной производственной партии, выделяя ее характеристики и удостоверяя ее соответствие требованиям.
• Архитектура: набор инструментов и правил для построения сложных архитектур в случае взаимодействия нескольких приложений друг с другом через локальные (LAN) или публичные (Internet) сети и способных взаимодействовать с несколькими операторами как локальными, так и удаленными (через браузер)

Зачем использовать программное обеспечение SCADA

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

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

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

Типы программного обеспечения SCADA

Первое отличие касается типа программной платформы:

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

Второе отличие касается архитектуры системы SCADA:

• Система, состоящая из одного диспетчерского ПК, подключенного к полевым устройствам. Это самый распространенный случай, который не обязательно является самым простым. Вы можете иметь очень сложные системы SCADA, с несколькими предприятиями для наблюдения, которые распределены по географическим районам, удаленным друг от друга; точно так же, как на сложность системы влияет количество переменных для управления (от нескольких единиц до десятков тысяч тегов), разнообразие подключенных полевых устройств, различные протоколы связи. В простейших случаях, когда система SCADA состоит из одного ПК, подключенного к одной машине (обычно управляемой одним ПЛК), мы также говорим о SCADA-HMI.
• Системы, состоящие из нескольких диспетчерских ПК, соединенных друг с другом через локальную сеть (LAN) или публичную сеть (Internet) и распределенных на нескольких иерархических уровнях. Наиболее распространенная система характеризуется несколькими ПК на одном иерархическом уровне, подключенными к центральному ПК; ПК второго уровня различаются по географическим характеристикам (каждый ПК относится к своей географической зоне) или функциональному (каждый ПК управляет определенной функцией); центральный ПК делает всю информацию доступной из одного места.

Наконец, третье различие касается требований к реальному времени:

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

Выбор программного обеспечения SCADA

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

• Размеры проекта: первым моментом, который нужно установить, является количество переменных для управления (tag), где «tag» означает внешнюю переменную, т.е. переменную, обмениваемую с полевыми устройствами. Количество тегов важно, поскольку оно влияет на выбор лицензии, время отклика системы и затраты на разработку.
• Интерфейс с полевыми устройствами: необходимо убедиться, что программное обеспечение SCADA поддерживает все протоколы связи с полевыми устройствами. Или, в качестве альтернативы, что OPC-сервер доступен для установки на ПК, чтобы обеспечить связь по протоколу OPC.
• Подключение к другому программному обеспечению: проверьте, требуется ли приложение для взаимодействия с другим программным обеспечением, таким как MES или ERP; в этих случаях сопряжение обычно осуществляется через протоколы OPC UA Server и OPC UA Client.
• Доступность через браузер: запрос на то, чтобы удаленные операторы могли получить доступ к серверному приложению через браузер со стационарных (настольный компьютер) или мобильных (смартфон) устройств.
• Взаимодействие с внешней СУБД: проверьте, должно ли приложение взаимодействовать с внешней СУБД (MySQL, . ) для записи таблиц данных (функция Datalogger) или для взаимодействия через определенные инструкции (API), которые позволяют выполнять общие запросы (SELECT, INSERT, UPDATE, . )
• Дистанционное обслуживание: возможность доступа оператора к удаленным устройствам (обычно ПЛК) с использованием SCADA в качестве «моста» для программирования удаленных устройств без прямого подключения (фиксированный IP, DNS или другое).

SCADA, IoT и Индустрия 4.0

Аббревиатуры IoT и IIoT (Internet of Things and Industrial Internet of Things) обозначают все те технологии, которые позволяют преобразовать любой объект, будь то датчик, исполнительный механизм, транспортное средство или устройство, в устройство, подключенное к Интернету, которое способно отправлять данные в облако с помощью легких и быстрых протоколов, таких как MQTT (Message Queue Telemetry Transport).

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

Эти системы, благодаря своей архитектуре, особенно подходят для управления:

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

Эти системы включают в себя ключевые технологии (Key Enabling Technologies — KET’s) Индустрии 4.0 (SCADA, IoT, облако, большие данные, кибербезопасность).

Примеры приложений SCADA

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

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

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

Ниже приведен ряд примеров применения SCADA; В каждом примере есть ссылка на дополнительную информацию:

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

SCADA система, что это такое

SCADA (Supervisory Control And Data Acquisition) представляет собой программный пакет, предназначенный для выполнения функций сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления в реальном времени. ПО даного класса может являться частью АСУ ТП, АСКУЭ, системы экологического мониторинга, научного эксперимента, автоматизации здания и т. д. SCADA-системы используются во всех отраслях деятельности, где требуется обеспечивать операторский контроль за технологическими процессами.

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

Функции cовременной скада

Основные функции hmi scada следующие:

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

Рынок SCADA систем

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

Требования к современным SCADA

Какие же требования предъявляются к современным scada системам ? В основном, разработчиков scada систем заботит следующее:

• Надежность и безопасность функционирования в промышленной среде;
• Наличие большого количества драйверов к аппаратуре управления (ПЛК, ОП, распределенные системы ввода-вывода). В частности, полная поддержка современных стандартов ОРС (DA, HDA, A&E, UA);
• Широкие возможность передачи данных по открытым протоколам (OPC, OLE DB/ODBC, XML и т.п.) на верхние уровни управления;
• Развитые встроенные программные средства обработки и представления данных (например, язык программирования VB), наличие богатых возможностей для реализации графического и управляющего интерфейса;
• Простота и удобство расширения системы, наличие различных типов узлов (сервера, клиенты, совмещенные, только для чтения, runtime, development, тонкие клиенты, web, под iOS/Android и т.п.), а также гибкая система лицензирования и масштабирования;
• Легкость освоения, качество технической документации, техническая поддержка;
• Постоянное обновление продукта производителем для поддержки новых версий ОС и актуальных заплаток кибербезопасности.

Мировой лидер цифровой трансформации компания GE Digital предлагает две современные scada системы GE iFIX , GE СIMPLICITY . Для ознакомления и тестирование можно получить демонстрационные полнофункциональные версии SCADA cистем бесплатно можно скачать с нашего сайта перейдя на страницу с описанием конкретной скады.

HMI / SCADA iFIX

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

CIMPLICITY

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

Часть 4. Немного про SCADA

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

С увеличением производительности вычислительной техники и появлением «объемных» устройств хранения данных (жестких дисков), системы управления эволюционировали в 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, ее функционала, топологии построения, аппаратной и программной реализации будет зависеть от требований объекта автоматизации.

• scada
• plc
• plc контроллер
• dcs
• плк
• рсу
• асутп
• промышленная автоматизация
• промышленное программирование
• промышленные системы управления

SCADA
Supervisory Control And Data Acquisition

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

Системы SCADA активно используются для диспетчерского контроля в промышленности и энергетике

Назначение и задачи SCADA-систем

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

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

Задачи SCADA-систем:

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

Структура SCADA-систем

Структура системы SCADA

Любая SCADA-система включает три компонента: удалённый терминал (RTU – Remote Terminal Unit), диспетчерский пункт управления (MTU – Master Terminal Unit) и коммуникационную систему (CS – Communication System).

Удаленный терминал подключается непосредственно к контролируемому объекту и осуществляет управление в режиме реального времени. Таким терминалом может служить как примитивный датчик, осуществляющий съем информации с объекта, так и специализированный многопроцессорный отказоустойчивый вычислительный комплекс, осуществляющий обработку информации и управление в режиме реального времени. Интервью TAdviser: Управляющий по ИТ «ВкусВилла» Дмитрий Апаршев — о приоритетах цифровизации

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

Коммуникационная система необходима для передачи данных с RTU на MTU и обратно. В качестве коммуникационной системы могут использоваться следующие каналы передачи данных: выделенные линии, радиосети, аналоговые телефонные линии, ISDN сети, сотовые сети GSM (GPRS). Зачастую устройства подключаются к нескольким сетям для обеспечения надёжности передачи данных.

Особенности процесса управления в SCADA-системах

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

Защита SCADA-систем

Среди некоторых пользователей систем SCADA бытует мнение — если система не подключена к интернету, тем самым она застрахована от кибератак. Эксперты не согласны.

Физическая изоляция бесполезна против атак на SCADA-системы, считает Файзел Лакхани (Faizel Lakhani), эксперт по защите информационных ресурсов. По его мнению, физическая изоляция систем равносильна борьбе с ветряными мельницами [1] .

Файзел Лакхани (Faizel Lakhani), президент компании SS8

Мнения российских экспертов относительно защищенности систем АСУ ТП и SCADA созвучны. Поскольку вопросы безопасности АСУ ТП попали в фокус всеобщего внимания, некоторые производители защитных решений приступили к разработке продуктов, ориентированных на противостояние угрозам для промышленных информационных комплексов (к числу таких продуктов, в частности, может относиться безопасная операционная система — среда для функционирования только доверенных приложений) [2] .

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

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

Как современные HMI/SCADA решения могут ускорить переход к Индустрии 4.0

Большая часть данных, используемых промышленными решениями IoT, поступает из программного обеспечения автоматизации HMI / SCADA. Как ускорить трансформацию производства с учетом этого? Технологии автоматизации, такие как программное обеспечение HMI / SCADA, существуют уже много лет. Они послужили толчком к тому, что многие называют «третьей промышленной революцией». В 2020 году, когда достигнут следующий этап, известный как «Индустрия 4.0», многие компании переосмысливают свое будущее и пытаются понять, как они могут реализовать преимущества, приносимые цифровой трансформацией. Решения для автоматизации являются неотъемлемой и ключевой частью процесса, открывая эру, в которой оперативные данные немедленно анализируются с помощью алгоритмов искусственного интеллекта /машинного обучения. ИИ автоматически оптимизирует операции через «замкнутый контур» или предупреждает человека о дальнейших действиях. HMI / SCADA позволяют принимать более взвешенные решения для быстрого реагирования. Преобразование оперативных данных в аналитику, которую затем можно использовать для оптимизации процессов, приносит истинную ценность для бизнеса, превращая автоматизацию в слой, на котором пользователи могут строить свои цифровые преобразования. По сути, автоматизация становится основой стратегии оцифровки компании [3] .

Цифровое преобразование помогает снизить издержки

Оценка риска

С момента запуска операционной технологии [4] . производители сталкиваются с тремя основными проблемами: как одновременно повысить доступность, управлять рисками и сократить расходы. Конечная цель — обеспечить оптимальную эффективность активов для максимизации желаемых результатов. Производители могут использовать HMI / SCADA для улучшения видимости, оптимизации операций и улучшения качества и производительности. Беглый взгляд — операторы знают, что важно, и какие действия будут правильными для повышения эффективности и снижения затрат. Первоначально надо пройти стадию оценки рисков. Она включает в себя процесс оценки критичности всех активов в рамках бизнеса и выставления оценки: высокая, средняя и низкая. Затем аналитические решения предоставляют оптимизированный план, позволяющий сократить расходы и в то же время соответствующим образом снизить риск неудачи с учетом вероятностей и последствий. Рекомендации, выданные аналитикой, возвращаются в процесс через уровень автоматизации, HMI / SCADA, и в этом случае оператор сможет проверить рекомендуемые параметры перед их отправкой в реальный процесс или непосредственно в ПЛК. Эта трансформация данных используется для принятия более обоснованных решений, проактивности и оптимизации процессов.

Почему современное программное обеспечение для автоматизации имеет значение

Восемьдесят пять процентов данных, используемых аналитическими инструментами, такими как программное обеспечение управления эффективностью активов (APM) или программное обеспечение управления операциями (OPM), поступают «с поля» (данные OT). Таким образом, правильная настройка уровня автоматизации необходима для обеспечения возможности принятия решений в Индустрии 4.0.

Основная цель программного обеспечения для автоматизации состоит в том, чтобы предоставить оператору окно в приложении с мнемосхемами, представлениями трендов, представлениями сигналов, алармами и т. д. Однако новые технологии делают HMI / SCADA более мощным, простым в использовании и более «подключенными».

Мобильность становится все более важной. Сейчас операторы хотят просматривать оперативные данные там, где находятся, «в поле», а не только на месте оператора. Кризис COVID-19 показал, насколько важно работать удаленно для поддержания работы наших критически важных инфраструктурных предприятий.

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

Цифровое преобразование не всегда означает, что все должно находиться в облаке.

Многие инструменты могут быть развернуты на месте как часть решений компании по автоматизации или управления рабочими процессами, которые, по сути, становятся краевым узлом для промышленного интернета.

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

Типичные области применения варьируются от стандартных рабочих процедур до процедур технического обслуживания или обходов оператора.

Ключевые факторы

Цифровое преобразование не происходит в одночасье; это – длинный путь. Как и любое путешествие, оно должно включать в себя ясную и достижимую цель, будь то финансовая, операционная или какая-либо другая. Чтобы путешествие было успешным – нужно предпринимать правильные шаги. Рекомендуется сделать один шаг назад, вернуться к аспектам ИТ и ОТ, чтобы определить основные проблемы.

Не будет вредным включить в команду пару внешних, свежих глаз, чтобы задавать вопросы. Например, как можно сэкономить на производственных потерях, чтобы быть более конкурентоспособным? Как можно оптимизировать стратегии обслуживания и сократить время простоя? Как снизить риски и повысить производительность?

Как только цели установлены, следующая задача — составить план реализации. Многие промышленные объекты уже начали путь, сами не осознавая этого. Но у путешествий также могут быть сложности. Одной из ключевых проблем, определенных в рамках Индустрии 4.0 и Консорциумом индустриального интернета, является функциональная совместимость. С появлением таких стандартов, как OPC UA, это становится меньшей проблемой. Когда OPC UA применяется к уровню автоматизации, он не только обеспечивает связность, но и обеспечивает структурированную безопасность передачи данных. Не возможно управлять, анализировать или оптимизировать тем, чего не видно. Для существующих установок или инфраструктур важно обеспечить, отсутствие сбоев в производстве и операционной технологии в процессе оцифровки. В противоположность внедрению систем ERP, рекомендуется начинать с малого и развертывать новую систему в своем собственном ритме.

Начните со слоя автоматизации

Первый шаг — модернизировать то, что существует, оценить пробелы и начать построение на этой оценке. Технологии автоматизации могут помочь снизить риск сбоев и стать очень ценным пограничным узлом развертывания. Это зрелые и проверенные технологии, которые могут предоставить новые возможности, гарантируя, что приложение остается безопасным, доступным и совместимым.

Таким образом, процесс цифрового преобразования должен принимать во внимание потребности пользователя и гарантировать, что на оператора изменения повлияют положительно. Цель состоит в том, чтобы облегчить жизнь операторам, инженерам, производственному менеджменту и т. д.

Современные HMI / SCADA могут доставлять контент на любое подключенное устройство — ПК, смартфон, планшет — предоставляя инструменты, которые соответствуют потребностям пользователя. Мобильные устройства продемонстрировали способность повышать эффективность, а недавние исследования показали, что операторы с мобильными АРМ на 30% более эффективны, чем операторы, использующие стационарные устройства.

Таким образом, если рассматривать путь цифровой трансформации — он начинается со слоя автоматизации.

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

За счет использования автоматизации как основной части цифрового преобразования, появляется возможность воспользоваться многими ее преимуществами.

Каталог SCADA-систем и проектов

Основной раздел каталога: SCADA

Примечания

1. ↑Физическая изоляция бесполезна против атак на SCADA-системы
2. ↑Безопасность АСУ ТП и контроль привилегированных пользователей
3. ↑Автоматизация «на краю»: современный HMI и SCADA
4. ↑Операционная технология