SCADA *

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

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

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

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

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

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

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

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

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

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

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

Я Иван Балашов, в интеграторе К2Тех руковожу направлением цифрового производства и внедряю цифровые решения в промышленности. В этом кейсе расскажу, как мы собирали пазл из обрывков информации о настройках систем, внедряли российскую SCADA взамен западной, мигрировали функционал MES, и все это без остановки производства.

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

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

Отправлять такие оповещения в Telegram значит их гарантированно потерять. Поэтому мы решили сделать интеграцию с Exolve API для их автоматической отправки для мгновенного оповещения ответственных специалистов через SMS.

На основе 18-летнего опыта работы в сфере АСУ ТП и детального анализа рынка мы представили рейтинг отечественных решений, охватывающий: «Каскад Цифра», «Альфа Платформа», «МастерСКАДА 4D», REDKIT SCADA 2.0, «СимплСКАДА», «ИнтраСКАДА» и «РАПИД СКАДА».

В исследовании оценены функциональность, надежность, масштабируемость, совместимость с ОС (включая Astra Linux, РЕД ОС), поддержка промышленных протоколов (OPC UA, Modbus, МЭК 61850), интеграция с базами данных (PostgreSQL, InfluxDB, Oracle) и ERP-системами.

Всем привет! Недавно несколько российских компаний (и Positive Technologies в их числе) провели исследование, которое было посвящено перспективам развития рынка автоматизированных систем управления технологическим процессом в России. Как безопасники, мы, конечно же, сосредоточились на вопросах защиты автоматизированных систем управления с учетом современных вызовов и киберугроз. Особенностями отечественного рынка АСУ ТП и нашими рекомендациями по безопасной разработке делимся с вами в этой статье.

Что такое универсальная система управления (UCS), и действительно ли она способна заменить распределённые системы управления (DCS) в будущих задачах по управлению технологическими процессами? Каковы основные преимущества UCS?

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

Летом 2023 года к к нам обратилось предприятие химической промышленности крупного Российского холдинга. На нем  много лет использовалась SCADA-система Wonderware InTouch. Из-за санкционных наложений, иностранный вендор расторг контракт на обслуживание и техподдержку. Более того, была предпринята попытка удаленно остановить производство путем отключения серверов SCADA. Последствия удалось минимизировать, изолировав промышленную сеть, однако функционал системы снизился на треть, а ее развитие и масштабирование оказалось невозможным. Нам было необходимо решить следующие проблемы:

1.     Отсутствие возможности обслуживания данной системы. Ввиду того, что данную SCADA систему разрабатывала и обслуживала иностранная компания, после начала СВО все контракты по обслуживанию и технической поддержке были расторгнуты. 

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

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

Сборка макета для тестирования

Подготовка микрокомпьютеров и виртуального сервера

Установка утилиты mbpoll для тестирования датчиков

Установка InfluxDB

Установка Telegraf

Установка Grafana

Получаем данные от датчиков в Telegraf

Добавляем шаблон плагина датчика в конфигурацию Telegraf

Проверяем передачу данных в InfluxDB

Установка срока хранения данных в InfluxDB

Подключаем Grafana к InfluxDB

Тестирование Front Control Compact

Выводы

Полезные ссылки

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

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

Вы научитесь получать данные через протокол Modbus на примере датчиков XY-MD02 и PZEM-016, доступных на известных маркетплейсах. Первый из них измеряет температуру и влажность окружающей среды, а второй — параметры электрической сети, такие как напряжение, ток, мощность, потребляемая энергия и частота переменного тока. Используя полученные знания, можно будет подключать и другие аналогичные датчики.

Среди всех разновидностей протокола Modbus в этой статье будет использован Modbus RTU (Remote Terminal Unit), который применяется в промышленности для сбора данных через RS-485 или RS-232. Заметим, что длина линии RS-485 может достигать 1200 м.

Множество инженерных систем, работающих на поддержание комфортных, или требуемых условий (температура и влажность воздуха, содержание СО2 и примесей, уровень освещенности, температура воды), время от времени выходят из строя, требуют технического обслуживания. Раньше дежурный инженер несколько раз за смену обходил все оборудование и проверял его исправность и режимы работы. Кому-то стало жарко в помещении - потопал менять уставку температуры на установке за тридевять земель. И так каждый раз. Если что-то выходило из строя, то узнавали об этом либо в очередной обход, либо от пострадавших.

Разработали серийный корпус, плату, воткнули туда одноплаточник на Linux + Armbian, установили MasterSCADA4D и давай автоматизировать вентиляцию, освещение и другое инженерное оборудование.

Здравствуйте, пользователи сообщества Хабр.

Цель статьи: Описание способа передачи данных из закрытого контура АСУ ТП (промышленная технологическая сеть), в глобальную сеть интернет, 100% защита от взлома.

Невероятный подарок от Raspberry до нового года мы уже не ждали. Многие любители малинок из средней школы не поймут о чем речь, однако Raspberry CM5 это то что мы так ждали, так еще и в том же форм факторе что и CM4.

Доброго времени суток всем!

Вот и настал очередной этап рассказать о моем проекте и куда в итоге он меня привел. Предыдущие мио публикации по данной теме можно найти в моем профиле. С момента последней публикации прошло 7 лет, за это время произошло очень много всего, как вокруг моей разработки, так и того, чему она стала инициатором. После выпуска 2-й версии системы в 2017-м году, она достаточно успешно показала себя в нескольких крупных внедрениях. Объем поддержки и разработки системы ощутимо вырос и стал достаточно много требовать моего личного времени. Кроме того – меня пригласил один крупный холдинг создать им некую отраслевую скада—систему, поэтому времени на свое хобби, в рамках которого так и продолжал развиваться мой проект, стало не очень много. Поэтому в 2020-м году я объявил в кругах АСУТП, что буду не против дать проекту возможность встать на коммерческие рельсы. Неспешно пошли предложения, и также не спешно шел процесс их обсуждений и анализа продукта заинтересованными сторонами. В конечном итоге, на меня вышла группа ИТ-компаний, которые очень заинтересовались продуктом и возможностью диверсифицировать с его помощью бизнес еще и на рынок АСУТП. Так в июле 2022-го года родилась компания-вендор, в основу которой вошла интеллектуальная база проекта с исходным кодом 2-й версии моей разработки. Я вошел в состав ее учредителей и сейчас занимаю должность технического директора компании. За полтора года была сформирована отличная команда: разработчиков, инженеров и менеджеров. Первоочередной задачей, которая была поставлена перед нами – было создание новой версии скады, которая бы удовлетворяла текущим тенденциям и ситуациям, которые происходили в это самое время. А события, как вы понимаете, в этот период сыпались как из рога изобилия, и с каждым из них мы всей командой все больше понимали, что именно сейчас мы делаем то, что нужно нашему рынку автоматизации и это то, что нужно уже сейчас. Насколько у нас это получилось – теперь можно будет оценить, ведь буквально в начале февраля этого года мы выпустили официальный первый релиз нашего нового продукта: SCADA+ 3.0! И выпущен он уже компанией-вендором, которая теперь специализируется на его разработке, поддержке и сопровождении.

Для отладки ППО на ПЛК потребовалось настроить симуляцию устройства, которое опрашивается по протоколу Modbus RTU. Все ниже перечисленные программы и действия произведены в ОС Windows.

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

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

Как я уже рассказывал, американская коррупция превратила физика-ядерщика в былдокодера, но далеко от ядерных реакторов у меня оторваться сразу не получилось, несмотря на всю мою оторванность. Поэтому первые коммерчески успешные проекты у нашей копании были связанны технологиями «говна и пара», как на флоте называют ядерный реактор атомных подводных лодок. Не спрашивайте почему реактор ядерный, а подлодка атомная, это науке не известно. Но в итоге наше ПО начало применяться для проектирования систем управления АПЛ: сначала в качестве системы моделирования, потом для автоматической генерации управляющего ПО, дальше – больше, и уже наш код стоит непосредственно в системе управления.

Технология программируемых логических контроллеров совершенно точно достигла зрелости – ей уже 60 лет. В связи с чем возникает вопрос: станут ли нынешние ПЛК «пенсионерами» и сойдут ли их будущие версии в могилу? Такое предположение кажется уместным, учитывая быстрое, а порой экспоненциальное развитие компьютерного оборудования, программного обеспечения, искусственного интеллекта, облачных сервисов и средств связи. Благодаря этим достижениям информационные технологии постепенно проникли в ранее изолированную сферу операционных технологий.

В свете этих событий приводим статью Джеффа Пейна, опубликованную в журнале Control Engineering о будущем контроллеров и приложений промышленной автоматизации на фоне происходящей в последние десятилетия эволюции ПЛК.