SCADA *

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

В DevelSCADA используется версия протокола OPC UA, так как он на данный момент является наиболее популярным и кросплатформенным. Так же протокол OPC UA имеет множество механизмов по защите соединения, что может быть актуальным при работе по незащищенном каналам связи (к примеру через сеть интернет).

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

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

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

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

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

Система поддерживает работу с двумя видами скриптов - скрипты интерфейса и скрипты ПЛК. Оба типа скриптов имеют идентичные интерфейсы для взаимодействия с системой, но при этом имеют разное предназначение.

Сегодня, говоря о беспроводных датчиках Интернета вещей (IoT), мы представляем себе компактные устройства, идеально подходящие для небольших помещений и ограниченных пространств. Однако, перенося такие датчики в реальную производственную среду — будь то заводские цеха, строительные площадки или удалённые объекты инфраструктуры — возникают совершенно новые требования, которые зачастую кардинально меняют концепцию продукта. "Беспроводному" датчику приходится эволюционировать и обзавестись… проводами. Как это происходит и почему — разберёмся в этой статье.

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

Российская промышленность находится в фазе активной цифровизации, где концепции Индустрии 4.0 и Промышленного интернета вещей (IIoT) перестают быть просто трендами, а становятся необходимым инструментом для повышения эффективности, гибкости и глобальной конкурентоспособности предприятий. Эти технологии кардинально меняют подходы к управлению производством, открывая путь к созданию «умных» заводов нового поколения.

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

Опираясь на обширный опыт внедрения решений для промышленного IIoT, в этой статье мы рассмотрим:

1. Суть и принципы Индустрии 4.0 и IIoT: Как они меняют промышленный ландшафт?

2. Важную роль сбора данных: Почему надежные датчики — фундамент для цифровизации?

3. Конкретные решения для российских реалий: Как преодолеваются вызовы суровых условий эксплуатации и специфических требований?

4. Реальные примеры применения: Какие практические задачи решаются с помощью современных технологий беспроводного мониторинга на отечественных предприятиях?

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

Каждый пост автомойки — это работа целого набора исполнительных механизмов, датчиков, насосов и клапанов. Сбой хотя бы одного элемента — и автомойка простаивает, бизнес теряет деньги, а клиенты уезжают к конкурентам. А когда на объекте нет персонала (что типично для моек самообслуживания), без надежной автоматизации вся модель рассыпается.

В статье покажем, как инженер Андрей Демшин выстроил систему, в которой автоматика не просто управляет подачей воды и химии, а обеспечивает все бизнес-процессы. На реальном примере сети «Чистомытов» в Санкт-Петербурге разберем, какие технологии помогли превратить автомойки в стабильный бизнес.

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

Сегодня автоматизированные системы управления технологическими процессами (АСУ ТП) становятся всё более «программно-ориентированными». Если раньше основным считались контроллеры и оборудование, то сейчас главная ценность — это софт: логика процессов, алгоритмы управления, интерфейсы операторов и интеграция с другими уровнями автоматизации.

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

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

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

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

1. REGUL R500 (Astra IDE)

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

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

Выбор SCADA системы определяет решение, которое скорее всего вы будете использовать в течение как минимум 10+ лет. Поэтому крайне важно понимать принципы выбора ПО. Предлагаем ознакомиться с мнением Роя Кока (Roy Kok) – инженера с более чем 30-летним опытом работы в области электротехники и промышленной автоматизации.

После проведения HAZOP и формирования контуров безопасности ПСБ с определением целевого уровня полноты безопасности, нам, как инженерам реализующим систему безопасности прислали исходные данные: технологическая схема с КИП, перечень контуров безопасности, матрица причинно-следственных связей, значение целевого УПБ. Мы, как подготовленные инженеры, понимаем из чего могут быть построены контура безопасности, отвечающие заданному целевому УПБ. Осталось подобрать оборудование, собрать контура,  посчитать результирующее значение УПБ и сравнить его с целевым.

Если подходить к решению задачи правильно и грамотно, ПСБ еще на предыдущих этапах должна быть разделена на систему аварийного останова ESD и систему технологических защит PSD. ESD предназначена именно для предотвращения катастрофы, аварии и гибели людей. PSD предназначена для защиты оборудования и технологического процесса (например, не дает загубить катализатор в реакторе или выпустить некачественную продукцию). Позже, когда будем разбираться, в чем разница между ESD и ПАЗ разберем этот вопрос подробнее.

Когда мы говорим о снижении риска до целевого значения и расчете уровня полноты безопасности, мы говорим про ESD.

Весь перечень контуров безопасности сразу делим на две части: контура с целевым УПБ1 и ниже, и контура с целевым УПБ2,3. При объективно проведенном анализе рисков контуров УПБ3 будет очень ограниченное количество, обычно несколько единиц. Подобрать оборудование для обеспечения УПБ3 контура в целом достаточно сложно.

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

Можно выделить следующие слои безопасности:

- совершенствование технологического процесса с целью исключения опасных факторов – уменьшить давление в системе, снизить объем опасных веществ, изменить технологическую схему, уменьшить количество оборудования…;

- ОСУП (организация системы управления процессом) – контроль состояния оборудования, контроль за технологическим процессом, уменьшить количество персонала в потенциально опасной зоне, построить эффективную систему обучения и инструктажей …;

- система сигнализации о приближении к опасным границам и квалификация операторов – наладить полноценную систему сигнализации, выделить сигнализации приоритета 1, которые требуют незамедлительных действий от операторов, постоянно и квалифицированно вести анализ срабатывания сигнализации, максимально исключить ложные срабатывания, наладить систему постоянных тренингов для поддержания необходимой квалификации операторов (в правильно построенной системе, сигнализации уровня 1 срабатывают крайне редко при реальной угрозе аварии, количество параметров для крупного объекта не превышает 10-50, каждое ложное срабатывание детально исследуется, программа подготовки и квалификация операторов должны обеспечивать корректные действия персонала при срабатывании сигнализации). В правильно построенной системе, сигнализации должны быть разделены на аварийные и информационные, с разной схемой визуализации и разными журналами, но на практике все сигнализации собирают в один перечень, называют «Перечень сигнализаций и ПАЗ», и в системе управления нет разницы между сигнализацией о перегреве реактора и сигнализацией о низкой температуре теплофикационной воды в операторной. В результате в общий журнал сигнализаций каждый день пишется по 1000 записей, 999 из которых не имеют какого-то смысла.

В данной статье на примерах попробуем разобрать порядок построения системы безопасности технологического процесса на основе анализ рисков. Поскольку цель статьи постараться объяснить «нормальным инженерных языком» назначение и порядок создания системы безопасности технологических объектов на основе анализа рисков, придерживаться «процедур в соответствии с ГОСТ-МЭК..» и описывать процедуры я не буду.

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

В целом порядок создания системы безопасности будет следующим:

- исследуем риски, выявляем факторы риска, оцениваем значение;

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

- если технологическими и организационными решениями снизить риск до приемлемого не удается, переходим к созданию приборной системы безопасности (ПСБ), определяем контура безопасности, оцениваем требуемый уровень полноты безопасности (SIL) контуров, строим систему аварийного останова (ESD);

Различие в подходах: нормы или анализ рисков.

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

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

В бывшем СССР сложилась система норм и правил, которые жестко регламентировали требования, как организационные, так и технические. Эта система была унаследована и РФ. Достаточно посмотреть «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» утверждены приказом Федеральной службы по экологическому, технологическому и атомному надзору от 15 декабря 2020 года № 533. Документ содержит 70 страниц ценных указаний. И таких «нормативных документов» у нас бесконечное количество, при желании можно найти «нормативку» на все случаи жизни. Соответственно проектировщику не надо понимать процесс, детально знать все особенности технологии, иметь опыт эксплуатации, достаточно просто найти нужную «нормативку» и выполнить все требования. Эксперт при проведении экспертизы проектной документации также проверяет технические решения на соответствие «нормативке», и инспектор Ростехнадзора тоже будет проверять объект на соответствие этой же «нормативке». При этом никого не волнует, на сколько обеспечена реальная безопасность технологического процесса (технологической установки), эффективность и достаточность принятых решений, возможность устойчивой работы оборудования и т.д. Соответствие нормам снимает ответственность за конечный результат со всех – проектировщиков, экспертов, инспекторов, и перекладывает всю ответственность на эксплуатацию, людей, которые непосредственно работают на технологической установке и реально рискуют своей жизнью.

Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это?

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

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

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

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

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