#плк — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #плк, aggregated by home.social.
-
Хроники цифровых заводов: как надували технологии IIoT
Привет, Хабр. В прошлой статье мы прошлись по уровням АСУТП/АСУП и вспомнили, что будет, если эти уровни неудачно смешать. В этой статье уделим время IIoT-платформам и IIoTу в целом. Революция интернета вещей случилась примерно в 2015 году и вызвала сильнейшее недоумение у всех, кто работал в промышленной автоматизации. Было много разговоров на тему, что IoT (Internet of Things) — это наше новое будущее, были прогнозы Гартнера о миллиардах датчиков уже совсем скоро, и всем казалось, что начинается какая-то новая эра. Но сотрудники на заводах никак не могли взять в толк, что происходит. Что такого необычного и революционного привнёс IoT? Датчик, который через сеть сливает с себя информацию в какое-то ПО? А ничего, что промавтоматизация существует уже более полувека? В общем, массовое увлечение IoT и появление термина «интернет вещей» встретили на заводах с недопониманием. Никто не спорил, что за этим будущее. Но придумать какой-то термин (который, фактически, означает очень широкую сферу) и с ним носиться? Это казалось максимально странным. Столкновение бывалых автоматизаторов и свежеиспечённых «инженеров IoT» заслуживает отдельной статьи, и я обязательно напишу её в этом цикле. А пока расскажу об итогах. Как ни странно, IoT (и его промышленное воплощение IIoT) оказался не простым маркетинговым ходом. Всё-таки до 2015 года цена среднего датчика была больше чуть ли не на порядок. «Революция» IoT создала целые классы доступных устройств, работающих как на периферии, так и в сердце техпроцесса. Появилась новая тенденция: начали обвязывать и брать под контроль буквально всё. Началась эра накопления данных. Для продолжения процесса нажмите кнопку
-
Многопоточность в SCADA системах
Пишу SCADA-ядро на C++ для инженерных систем: опрос ПЛК, кэширование значений, правила автоматики и управление исполнительными механизмами. На текущем этапе упёрся в практический вопрос многопоточности: как правильно разделять потоки чтения и записи, как сериализовать доступ к одному каналу связи, и насколько оправдано использование std::condition_variable. В статье показываю текущую реализацию потока опроса ПЛК и хочу услышать мнение коллег, которые разрабатывали промышленные SCADA-системы.
https://habr.com/ru/articles/1029582/
#scada #c++ #modbus #thread #mutex #многопоточность #плк #диспетчеризация #автоматизация #асутп
-
Многопоточность в SCADA системах
Пишу SCADA-ядро на C++ для инженерных систем: опрос ПЛК, кэширование значений, правила автоматики и управление исполнительными механизмами. На текущем этапе упёрся в практический вопрос многопоточности: как правильно разделять потоки чтения и записи, как сериализовать доступ к одному каналу связи, и насколько оправдано использование std::condition_variable. В статье показываю текущую реализацию потока опроса ПЛК и хочу услышать мнение коллег, которые разрабатывали промышленные SCADA-системы.
https://habr.com/ru/articles/1029582/
#scada #c++ #modbus #thread #mutex #многопоточность #плк #диспетчеризация #автоматизация #асутп
-
Многопоточность в SCADA системах
Пишу SCADA-ядро на C++ для инженерных систем: опрос ПЛК, кэширование значений, правила автоматики и управление исполнительными механизмами. На текущем этапе упёрся в практический вопрос многопоточности: как правильно разделять потоки чтения и записи, как сериализовать доступ к одному каналу связи, и насколько оправдано использование std::condition_variable. В статье показываю текущую реализацию потока опроса ПЛК и хочу услышать мнение коллег, которые разрабатывали промышленные SCADA-системы.
https://habr.com/ru/articles/1029582/
#scada #c++ #modbus #thread #mutex #многопоточность #плк #диспетчеризация #автоматизация #асутп
-
Многопоточность в SCADA системах
Пишу SCADA-ядро на C++ для инженерных систем: опрос ПЛК, кэширование значений, правила автоматики и управление исполнительными механизмами. На текущем этапе упёрся в практический вопрос многопоточности: как правильно разделять потоки чтения и записи, как сериализовать доступ к одному каналу связи, и насколько оправдано использование std::condition_variable. В статье показываю текущую реализацию потока опроса ПЛК и хочу услышать мнение коллег, которые разрабатывали промышленные SCADA-системы.
https://habr.com/ru/articles/1029582/
#scada #c++ #modbus #thread #mutex #многопоточность #плк #диспетчеризация #автоматизация #асутп
-
CoreBus — универсальный Modbus терминал
CoreBus — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII и много чего еще. Приложение развивается уже довольно давно. Но была одна фича, которой не хватало, чтобы сделать CoreBus по-настоящему универсальным терминалом. Мне об этом писали еще с первых релизов. В личных сообщениях и в комментариях к статьям. Эта идея формулировалась по-разному, но суть была одна. И поэтому хочу представить вам новый режим - "Modbus мониторинг"!
https://habr.com/ru/articles/1021344/
#modbus #c# #corebus #opensourse #плк #terminal #logger #modbus_rtu #modbus_ascii #modbus_tcp
-
CoreBus — универсальный Modbus терминал
CoreBus — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII и много чего еще. Приложение развивается уже довольно давно. Но была одна фича, которой не хватало, чтобы сделать CoreBus по-настоящему универсальным терминалом. Мне об этом писали еще с первых релизов. В личных сообщениях и в комментариях к статьям. Эта идея формулировалась по-разному, но суть была одна. И поэтому хочу представить вам новый режим - "Modbus мониторинг"!
https://habr.com/ru/articles/1021344/
#modbus #c# #corebus #opensourse #плк #terminal #logger #modbus_rtu #modbus_ascii #modbus_tcp
-
CoreBus — универсальный Modbus терминал
CoreBus — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII и много чего еще. Приложение развивается уже довольно давно. Но была одна фича, которой не хватало, чтобы сделать CoreBus по-настоящему универсальным терминалом. Мне об этом писали еще с первых релизов. В личных сообщениях и в комментариях к статьям. Эта идея формулировалась по-разному, но суть была одна. И поэтому хочу представить вам новый режим - "Modbus мониторинг"!
https://habr.com/ru/articles/1021344/
#modbus #c# #corebus #opensourse #плк #terminal #logger #modbus_rtu #modbus_ascii #modbus_tcp
-
CoreBus — универсальный Modbus терминал
CoreBus — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII и много чего еще. Приложение развивается уже довольно давно. Но была одна фича, которой не хватало, чтобы сделать CoreBus по-настоящему универсальным терминалом. Мне об этом писали еще с первых релизов. В личных сообщениях и в комментариях к статьям. Эта идея формулировалась по-разному, но суть была одна. И поэтому хочу представить вам новый режим - "Modbus мониторинг"!
https://habr.com/ru/articles/1021344/
#modbus #c# #corebus #opensourse #плк #terminal #logger #modbus_rtu #modbus_ascii #modbus_tcp
-
Российский микроконтроллерный блок управления судовыми преобразователями частоты. Часть 1
Статья посвящена микроконтроллерным системам управления преобразователями частоты для электроприводов на базе асинхронных электродвигателей. Приводится описание российского микроконтроллерного блока управления БУПЧ, который входит в состав преобразователей частоты концерна «Русэлпром»: его технические характеристики, особенности, преимущества и недостатки по сравнению с западными аналогами. Рассматривается преобразователь частоты мощностью 1,67 МВА, управляемый блоком БУПЧ, который является базовым преобразователем частоты для судовых систем электродвижения концерна «Русэлпром». Первая часть статьи
https://habr.com/ru/articles/1011248/
#судовая_система_электродвижения #судовой_электропривод #преобразователь_частоты #система_управления #блок_управления #микроконтроллер #микроконтроллерная_су #плк #БУПЧ
-
Как построить открытую АСУТП. Создание пользовательских типов данных
Как создавать пользовательские типы данных в открытой АСУТП? Зачем объединять скорость, температуру и статус двигателя в одну переменную? В ИТ-команде «Северстали» мы занимаемся разработкой компонентов для открытой АСУТП. В этой статье разберём, как создавать и применять пользовательские типы данных в нашей среде разработки Flogic. В этой статье вы узнаете, как структурировать данные, повысить читаемость кода и переиспользовать тип переменных по всему проекту.
https://habr.com/ru/companies/severstal/articles/1009136/
#сезон_heavy_digital #асутп #иткомпания #iec_61499 #плк #среда_разработки
-
Как построить открытую АСУТП. Создание пользовательских типов данных
Как создавать пользовательские типы данных в открытой АСУТП? Зачем объединять скорость, температуру и статус двигателя в одну переменную? В ИТ-команде «Северстали» мы занимаемся разработкой компонентов для открытой АСУТП. В этой статье разберём, как создавать и применять пользовательские типы данных в нашей среде разработки Flogic. В этой статье вы узнаете, как структурировать данные, повысить читаемость кода и переиспользовать тип переменных по всему проекту.
https://habr.com/ru/companies/severstal/articles/1009136/
#сезон_heavy_digital #асутп #иткомпания #iec_61499 #плк #среда_разработки
-
Как построить открытую АСУТП. Создание пользовательских типов данных
Как создавать пользовательские типы данных в открытой АСУТП? Зачем объединять скорость, температуру и статус двигателя в одну переменную? В ИТ-команде «Северстали» мы занимаемся разработкой компонентов для открытой АСУТП. В этой статье разберём, как создавать и применять пользовательские типы данных в нашей среде разработки Flogic. В этой статье вы узнаете, как структурировать данные, повысить читаемость кода и переиспользовать тип переменных по всему проекту.
https://habr.com/ru/companies/severstal/articles/1009136/
#сезон_heavy_digital #асутп #иткомпания #iec_61499 #плк #среда_разработки
-
Как построить открытую АСУТП. Создание пользовательских типов данных
Как создавать пользовательские типы данных в открытой АСУТП? Зачем объединять скорость, температуру и статус двигателя в одну переменную? В ИТ-команде «Северстали» мы занимаемся разработкой компонентов для открытой АСУТП. В этой статье разберём, как создавать и применять пользовательские типы данных в нашей среде разработки Flogic. В этой статье вы узнаете, как структурировать данные, повысить читаемость кода и переиспользовать тип переменных по всему проекту.
https://habr.com/ru/companies/severstal/articles/1009136/
#сезон_heavy_digital #асутп #иткомпания #iec_61499 #плк #среда_разработки
-
Чтение и запись переменных из ПЛК по Modbus в C#-приложении
Modbus — это открытый и очень распространённый протокол обмена данными в промышленной автоматизации. Он работает по модели master–slave: мастер (например, PC-приложение) запрашивает данные у ведомого устройства (ПЛК), получая или записывая значения регистров. На практике Modbus кажется простым — всего лишь массив 16-битных регистров. Но как только возникает задача читать типизированные переменные, поддерживать несколько проектов в одном ПЛК, минимизировать количество запросов и безопасно работать с соединением, всё быстро усложняется. В этой статье я описываю реальный подход, который использовал для чтения и записи переменных из ПЛК и отображения их в приложении на C#.
-
Чтение и запись переменных из ПЛК по Modbus в C#-приложении
Modbus — это открытый и очень распространённый протокол обмена данными в промышленной автоматизации. Он работает по модели master–slave: мастер (например, PC-приложение) запрашивает данные у ведомого устройства (ПЛК), получая или записывая значения регистров. На практике Modbus кажется простым — всего лишь массив 16-битных регистров. Но как только возникает задача читать типизированные переменные, поддерживать несколько проектов в одном ПЛК, минимизировать количество запросов и безопасно работать с соединением, всё быстро усложняется. В этой статье я описываю реальный подход, который использовал для чтения и записи переменных из ПЛК и отображения их в приложении на C#.
-
Хроники цифровых заводов. Уровни и ошибки
Когда речь заходит про умные заводы, «темные производства», цифровых двойников, промышленный интернет вещей и вообще будущее многие настолько воодушевляются, что упускают из фокуса важные вещи. А именно – общую логику построения систем автоматизации заводов. Основы основ, описанные в ISA-95 или ГОСТ Р МЭК 62264-1-2014, всегда звучат в рассказах, презентациях или описаниях. Авторы используют такие термины, как SCADA, PLC, IIoT-платформа или MES. Но вот правила работы и уровни промышленной автоматизации часто трактуют неверно. И это очень зря. Уровни автоматизации – это такая особенная штука, которая при неудачном смешивании может вызвать целую кучу проблем. Потому всегда нужно держать в голове пирамидку АСУ ТП/АСУП, о которой мы сегодня и поговорим. И не пугайтесь. Как и всегда, я постараюсь рассказать понятно даже о самом сложном. Добро пожаловать в основы Цифрового Завода. Для продолжения процесса нажмите кнопку
https://habr.com/ru/articles/1002810/
#PLC #MES #scada #erp #bi #ISA95 #плк #асу_тп #iiot #сезон_heavy_digital
-
Тип данных Real и его расхождение с реальностью при определении расстояния с помощью инкрементального энкодера
В этой статье описан наш опыт выявления причин ошибки в расчете положения подъемного сосуда в шахтном стволе по сигналам с инкрементальных энкодеров, который может быть полезен другим разработчикам, наладчикам и инженерам АСУТП, работающим не только с подъемным оборудованием, но и с любым другим, где малые приращения используются для расчета больших величин. Начнем с небольшого погружения в предметную область. Наша организация специализируется на наладке шахтных подъемных установок, это, выражаясь совсем простым языком, «как лифт, только для шахты». Принцип действия подъемной установки, в целом, как у лифта — привод вращает барабан, на который наматывается канат, на который подвешен подъемный сосуд — бадья, клеть или скип, в зависимости от производственной задачи — проходка ствола или тоннеля, добыча полезных ископаемых или подъем/спуск людей. Основная часть подъемной установки — подъемная машина, это барабан с редуктором и приводом (их может быть два), тормозная система, а также системы управления, контроля и защиты. На одной из таких подъемных машин, которую мы ввели в эксплуатацию и обслуживаем, положение подъемного сосуда для большей надежности контролируется одновременно двумя устройствами — САУ (Система автоматизированного управления) и АЗКД (Аппарат защиты и контроля движения). Для этого с каждого из двух датчиков углового положения вала — инкрементальных энкодеров, установленных на левом и правом редукторе (машина двухприводная), сигнал дублируется на счетные модули двух ПЛК (программируемых логических контроллеров), в САУ и в АЗКД, соответствующего канала, левого или правого. То есть, и в САУ, и в АЗКД установлено по два отдельных ПЛК, контролирующих так называемые левый и правый канал управления, относящиеся, соответственно, к левому и правому приводам подъемной машины, всего четыре ПЛК, из которых два ПЛК левого канала и в САУ, и в АЗКД получают данные с энкодера левого привода, а два ПЛК правого канала, соответственно, с правого.
https://habr.com/ru/articles/996540/
#ПЛК #энкодер #Real #приращение #точность #АСУ #АСУТП #автоматизация
-
От контроллеров до операторов: моделирование меняет подход к автоматизации на всех уровнях АСУ ТП
Давайте представим, что нам нужно построить сложный объект — скажем, самолет, поезд или вообще атомную электростанцию. Строить «наобум» невероятно дорого и рискованно. Гораздо разумнее выполнить предварительные расчеты и скорректировать слабые места. Есть разные виды расчетов, ну например расчет прочности конструкции, расчет стомости сорружения или эксплуатации, расчет последствий аварии (для АЭС). Расчеты бывают статические например расчет фундамента, расчет толщщины стены, или просто расчет нагрузки на балку. И динамические - расчет некоторого процесса разворащивающегося во времени например: расчет процесса нагрева котла в доме, расчет процесса разгона авиационного двигателя, расчет процесс поддержания давления в кабине самоелета при изменении высоты. В динамических расчетах сложных объектах, как правило необходмо учитывать работу автоматической системы управления (АСУ), поскольку система управления влияет на процесс. Если мы говоримт об АСУ ТП (Автоматической Системе Управления Технологическими Процессами), то само название как бы намекает на наличие некоторого процесса во времени, а значит тут есть место для динамического рассчета. Вот здесь-то на сцену и выходит "Среда динамического моделирования технических систем SimInTech." Хотите узнать, как поведёт себя котельная установка, двигатель, система вентиляции и тд? Вместо того, чтобы собирать макет и проводить натурные испытания (иногда практически невозможные), мы используем SimInTech. SimInTech — это программное обеспечение, в котором можно создать математическую модель объекта и провести все испытания на компьютере, без риска и лишних затрат. Это позволяет найти ошибки и оптимизировать конструкцию объекта и отладить систему управления ещё до начала реального производства.
https://habr.com/ru/articles/986186/
#simintech #simulink #matlab #математическое_моделирование #осрв #плк #асутп
-
АСУ ТП?.. Это очень просто! Или как устроена современная котельная. Часть 2: софт
Продолжаем разговор про АСУ ТП и устройство котельной, начатый в прошлой статье . Сегодня поговорим про программное обеспечение (ПО), которое ей управляет.
https://habr.com/ru/companies/wirenboard/articles/987926/
#diy #плк #wirenboard #wiren_board #асу #асутп #котельная #отопление #диспетчеризация
-
Граничные вычисления простыми словами: почему IoT больше не хочет бегать в облако
Край, на котором всё решается В мире IT редко появляется слово, которое не звучит из каждого утюга, но производит тихую революцию. «Edge computing» - одно из таких. После того, как датчик научился проводить вычисления быстрее, чем кто-то моргнет, сломалось сразу несколько привычных концепций. Датчики теперь не глупые, весь трафик не обязательно гнать на удаленный сервер или в облако, а децентрализация систем вышла на какой-то новый уровень. Edge-вычисления стремительно ворвались в IT-сферу, но не как очередной модный термин, а как вынужденная эволюция. Мир нарастил такое количество данных и устройств, что централизованная модель - «собираем всё в облако и там разбираемся» - просто перестала справляться. Задержки, медлительность протоколов IoT, приватность. Список проблем рос быстрее, чем дата-центры. И вот - вычисления переезжают на край сети. Буквально. Сегодня попробуем разобраться, что такое edge-контроллеры, зачем они нужны и почему без них не будет ни автономных машин, ни умных заводов, ни нормального Интернета вещей.
https://habr.com/ru/companies/beget/articles/971386/
#edge #edgeконтроллер #контроллер #ПЛК #граничные_вычисления #edge_computing #MQTT #OPC_UA #IIoT #IoT
-
Щёлк-щёлк — и поехали: как релейная автоматика стала прообразом IIoT. Часть 2
Напомню, что мы исследуем историю релейной автоматики и, неразрывно связанной с ней, релейной логики. И пытаемся понять, как в первой половине ХХ века огромные заводы работали, выполняли сложнейшие операции и почти не сбоили. Хотя все современные инженеры IIoT на тот момент еще даже не родились, а устройства ПЛК только шли в разработку. В первой части мы узнали, что главной хитростью автоматизаторов тех лет оказалось реле. Именно с помощью этих простых устройств делали ооочень непростые вещи. Но ХХ век шел вперед и инженеры сталкивались вызовами, масштаб которых раньше сложно было представить.
https://habr.com/ru/companies/beget/articles/963772/
#автоматизация #автоматика #плк #асутп #реле #релейная_автоматика #релейная_логика #релейная_защита #булева_алгебра #винтаж
-
Щёлк-щёлк — и поехали: как релейная автоматика стала прообразом IIoT. Часть 1
Если когда-нибудь у вас в руках было электромагнитное реле , то вы знаете этот приятный щелчок, когда оно срабатывает. За этим звуком — целая эпоха. Задолго до того как умный чайник получил Wi-Fi, а на заводах развернули первые SCADA, инженеры XX века строили умные системы на реле, шаговых искателях и Булевой алгебре. Без микропроцессоров, без языков верхнего уровня, без OTA-обновлений. Только электромеханика. Щёлк-щёлк и ехали поезда, крутились турбины, говорили абоненты. Давайте посмотрим, какой была автоматизация до появления ПЛК. И оценим вклад в историю прогресса одной из ключевых промышленных технологий - релейной автоматики.
https://habr.com/ru/companies/beget/articles/963766/
#автоматизация #автоматика #плк #асутп #реле #релейная_автоматика #релейная_логика #релейная_защита #булева_алгебра #винтаж
-
Цифровой двойник пассажирского посадочного моста: реальный кейс решения сервисной задачи
В работе инженера по автоматизации нередко возникают задачи, выходящие за рамки типового программирования. Одной из таких является поиск и устранение неисправностей в сложных мехатронных системах, где не всегда очевидно, какой механизм или устройство работает некорректно. На помощь может прийти полезный инструмент - цифровой двойник .
https://habr.com/ru/articles/958392/
#цифровой_двойник #плк #scada #3d #дифференциальные_уравнения #привод #механика #энкодер #моделирование #troubleshooting
-
Миграция программируемых логических контроллеров в непрерывном производстве: кейс и грабли
Кейс: замена иностранных ПЛК на заводе по производству непрерывного стекловолокна, сокращение простоев и внедрение мотивации персонала без остановки производства Замена иностранных ПЛК на отечественные: что пошло не так и как исправили В 2024 году выполнена замена 12-летних Schneider TSX на отечественные программируемые логические контроллеры (ПЛК) и SCADA - платформу — прямо на работающей линии непрерывного производства стекловолокна, где каждая остановка печи = потеря партии и дорогостоящий простой. В этом посте рассказываем, как за полгода ушли от сбоящих контроллеров к полностью отечественной архитектуре с Modbus-TCP, LD-кодом и отчётами, которые легли в основу механизма мотивации операторов. Структура Материал основан на практическом опыте инженеров, работавших над миграцией установки по получению непрерывного стекловолокна на отечественные ПЛК и SCADA. В статье описываются технические решения и сложности, с которыми столкнулись в процессе замены оборудования. Все цифры и схемы приведены для наглядности и воспроизводимости.
-
Лавандовый раф или стакан самогона: есть ли место на заводе хипстеру с макбуком
Привет, постоянные и не очень читатели! Приходит как-то молодой IT-специалист со свежим стеком из Docker’ов, микросервисов и К8s на завод. В цеху сверкают панели управления, гудят моторы, а он пытается подключиться к этому промышленному добру. И, внезапно (нет), оказывается, что привычный IT-стек здесь не работает — у заводчан свои протоколы, свои легенды и свои правила. Годами. Десятилетиями. Из уст в уста, от конунга к сыну и т.д. и т.п. Айтишник достаёт ноутбук, спрашивает, какая тут точка доступа, а в ответ — тишина. Только матёрый усатый автоматчик (спец по работе с автоматизированными системами на заводах) медленно поднимает глаза, откашливается и с лёгкой тоской в голосе говорит: — Тут, сынок, Modbus по RS-485. Без TLS. Без DHCP. И если что, мы это на Delphi писали, в 2004-м. И это ещё повезло, что на Delphi в 2004-м :) А могло быть написанно в другой стране (году этак в 1990-м) на паскале или фортране. Так и живут некоторые заводы, где вместо YAML — скрипты на паскале, вместо DevOps — старая добрая флешка с патчами, а вместо облачных масштабируемых серверов — шкаф с вентиляцией (в лучшем случае) и приклеенным на скотч листом: «Работает — не трожь!». Хотя по оценке того же Ростеха, если массово развернуть промышленный интернет вещей (IIoT) в разных секторах, это принесёт нашей экономике ~5,5 трлн рублей выгоды. Но пока такие цифры выглядят фантастикой. В этой статье я расскажу о том, как сталкиваются два мира: IT и OT (Operational Technology). Какие сложности у айтишников в SCADA, почему интернет вещей часто работает без интернета, и как улучшение кибербеза может ухудшить его при внедрении IIoT. Дропдаун
-
Функциональная безопасность и анализ риска, комментарии инженера (часть 5)
После проведения HAZOP и формирования контуров безопасности ПСБ с определением целевого уровня полноты безопасности, нам, как инженерам реализующим систему безопасности прислали исходные данные: технологическая схема с КИП, перечень контуров безопасности, матрица причинно-следственных связей, значение целевого УПБ. Мы, как подготовленные инженеры, понимаем из чего могут быть построены контура безопасности, отвечающие заданному целевому УПБ. Осталось подобрать оборудование, собрать контура, посчитать результирующее значение УПБ и сравнить его с целевым. Если подходить к решению задачи правильно и грамотно, ПСБ еще на предыдущих этапах должна быть разделена на систему аварийного останова ESD и систему технологических защит PSD. ESD предназначена именно для предотвращения катастрофы, аварии и гибели людей. PSD предназначена для защиты оборудования и технологического процесса (например, не дает загубить катализатор в реакторе или выпустить некачественную продукцию). Позже, когда будем разбираться, в чем разница между ESD и ПАЗ разберем этот вопрос подробнее. Когда мы говорим о снижении риска до целевого значения и расчете уровня полноты безопасности, мы говорим про ESD. Весь перечень контуров безопасности сразу делим на две части: контура с целевым УПБ1 и ниже, и контура с целевым УПБ2,3. При объективно проведенном анализе рисков контуров УПБ3 будет очень ограниченное количество, обычно несколько единиц. Подобрать оборудование для обеспечения УПБ3 контура в целом достаточно сложно. тут 30 станиц текста с формулами и графика
https://habr.com/ru/articles/913328/
#scada #plc_контроллер #esd #плк #промышленная_автоматизация #промышленное_программирование #автоматизация #анализ_рисков #функциональная_безопасность
-
Функциональная безопасность и анализ риска, комментарии инженера (часть 4)
Для снижения риска технологического процесса или технического устройства (защиты человека от гибели или травмирования), всегда задействованы несколько различных «слоев безопасности»: методы, мероприятия, технические решения, подходы направленные на обеспечение безопасности. Можно выделить следующие слои безопасности: - совершенствование технологического процесса с целью исключения опасных факторов – уменьшить давление в системе, снизить объем опасных веществ, изменить технологическую схему, уменьшить количество оборудования…; - ОСУП (организация системы управления процессом) – контроль состояния оборудования, контроль за технологическим процессом, уменьшить количество персонала в потенциально опасной зоне, построить эффективную систему обучения и инструктажей …; - система сигнализации о приближении к опасным границам и квалификация операторов – наладить полноценную систему сигнализации, выделить сигнализации приоритета 1, которые требуют незамедлительных действий от операторов, постоянно и квалифицированно вести анализ срабатывания сигнализации, максимально исключить ложные срабатывания, наладить систему постоянных тренингов для поддержания необходимой квалификации операторов (в правильно построенной системе, сигнализации уровня 1 срабатывают крайне редко при реальной угрозе аварии, количество параметров для крупного объекта не превышает 10-50, каждое ложное срабатывание детально исследуется, программа подготовки и квалификация операторов должны обеспечивать корректные действия персонала при срабатывании сигнализации). В правильно построенной системе, сигнализации должны быть разделены на аварийные и информационные, с разной схемой визуализации и разными журналами, но на практике все сигнализации собирают в один перечень, называют «Перечень сигнализаций и ПАЗ», и в системе управления нет разницы между сигнализацией о перегреве реактора и сигнализацией о низкой температуре теплофикационной воды в операторной. В результате в общий журнал сигнализаций каждый день пишется по 1000 записей, 999 из которых не имеют какого-то смысла.
https://habr.com/ru/articles/913290/
#scada #plc_контроллер #esd #плк #промышленная_автоматизация #промышленное_программирование #промышленные_системы_управления #автоматизация #анализ_рисков #функциональная_безопасность
-
Функциональная безопасность и анализ риска, комментарии инженера (часть 3)
В данной статье на примерах попробуем разобрать порядок построения системы безопасности технологического процесса на основе анализ рисков. Поскольку цель статьи постараться объяснить «нормальным инженерных языком» назначение и порядок создания системы безопасности технологических объектов на основе анализа рисков, придерживаться «процедур в соответствии с ГОСТ-МЭК..» и описывать процедуры я не буду. Еще раз напомню, что любой технологический процесс или техническое устройство несет потенциальный риск – угрозу жизни и здоровью работающих или находящихся по близости людей. Риск есть всегда и для всех, все живое рискует погибнуть. Риск, которому мы все подвержены в повседневной жизни называют фоновым. Для каждого производства или технологического процесса существует значение риска, принятого как допустимое. При построении нового процесса или технологического объекта необходимо принять такие меры обеспечения безопасности, чтобы обеспечить расчетный риск не выше допустимого. В целом порядок создания системы безопасности будет следующим: - исследуем риски, выявляем факторы риска, оцениваем значение; - если значение риска превышает допустимое, разрабатываем дополнительные мероприятия (технологические, организационные и т.д.) для снижения риска до приемлемого; - если технологическими и организационными решениями снизить риск до приемлемого не удается, переходим к созданию приборной системы безопасности (ПСБ), определяем контура безопасности, оцениваем требуемый уровень полноты безопасности (SIL) контуров, строим систему аварийного останова (ESD);
https://habr.com/ru/articles/913266/
#scada #plc_контроллер #esd #плк #промышленная_автоматизация #промышленное_программирование #автоматизация #анализ_рисков #функциональная_безопасность
-
Функциональная безопасность и анализ риска, комментарии инженера (часть 2)
Различие в подходах: нормы или анализ рисков. Поскольку практически любой производственный процесс или техническое устройство несут потенциальную опасность жизни и здоровью людей, необходимо разработать и использовать определенный набор организационных и технических мероприятий, для снижения этой опасности (риска) до приемлемого уровня. Для обеспечения безопасности технологического процесса или технического устройства, снижения риска получения травмы или гибели до допустимого значения, возможны два подхода – выполнить технологический процесс в соответствии с «нормативными документами» или провести анализ рисков, выявить все источники и разработать компенсирующие мероприятия. В бывшем СССР сложилась система норм и правил, которые жестко регламентировали требования, как организационные, так и технические. Эта система была унаследована и РФ. Достаточно посмотреть «Общие правила взрывобезопасности для взрывопожароопасных химических, нефтехимических и нефтеперерабатывающих производств» утверждены приказом Федеральной службы по экологическому, технологическому и атомному надзору от 15 декабря 2020 года № 533. Документ содержит 70 страниц ценных указаний. И таких «нормативных документов» у нас бесконечное количество, при желании можно найти «нормативку» на все случаи жизни. Соответственно проектировщику не надо понимать процесс, детально знать все особенности технологии, иметь опыт эксплуатации, достаточно просто найти нужную «нормативку» и выполнить все требования. Эксперт при проведении экспертизы проектной документации также проверяет технические решения на соответствие «нормативке», и инспектор Ростехнадзора тоже будет проверять объект на соответствие этой же «нормативке». При этом никого не волнует, на сколько обеспечена реальная безопасность технологического процесса (технологической установки), эффективность и достаточность принятых решений, возможность устойчивой работы оборудования и т.д. Соответствие нормам снимает ответственность за конечный результат со всех – проектировщиков, экспертов, инспекторов, и перекладывает всю ответственность на эксплуатацию, людей, которые непосредственно работают на технологической установке и реально рискуют своей жизнью. действительно интересно?
https://habr.com/ru/articles/913226/
#scada #plc_контроллер #esd #плк #промышленная_автоматизация #промышленное_программирование #автоматизация #функциональная_безопасность #анализ_рисков
-
Функциональная безопасность и анализ риска, комментарии инженера (часть 1)
Что такое безопасность технологического процесса или технической системы (устройства), что такое риск и вообще зачем все это? По анализу рисков и функциональной безопасности написано бесконечное количество статей (большая часть в переводе), брошюр, методичек и разнообразных презентаций. В большинстве случаев этот материал носит научно-популярный характер, с огромным количеством терминов, аббревиатур, сокращений до трех букв, абстрактных рассуждений вперемешку с теорией вероятности, и для нормального инженера выглядит как полный бред. И в большинстве случаев это и есть полный бред. Трудно понять, как этот псевдо-научный поток теоретических рассуждений можно связать с реальным технологическим объектом, техническими устройствами, реакторами, колоннами, компрессорами, насосами, печами и т.д. Многие инженеры приходят к справедливому выводу – никак. И дело не в методах, методиках, ГОСТ-ах по анализу риска и функциональной безопасности, а в специалистах, которые не понимая реального смысла и целей этих методов, решение реальных задач заменяют процессом и процедурами, с формальным соблюдением отдельных пунктов методик, с безумными выводами, и своими безграмотными действиями полностью дискредитировали саму идею функциональной безопасности, основанной на оценке риска. Данная статья, это попытка техническим инженерным языком объяснить подход к построению систем безопасности технологических объектов (технических устройств) на основе анализа риска и функциональной безопасности. В основу статьи положен собственный опыт участия в процедурах анализа рисков и построения функциональной безопасности, определения уровня SIL для контуров безопасности, формирования требований к техническому обслуживанию и периодичности испытаний систем противоаварийной защиты для сложных технологических установок переработки нефти. Статья полностью написана самостоятельно и не является переводом с англоязычных источников. Поскольку это собственный опыт, не буду утверждать, что все изложенное абсолютно правильно и объективно, возможны ошибки, недопонимание основополагающих положений стандартов, и вообще поверхностный и однобокий подход. Прошу понять и простить. для тех, кому это интересно
https://habr.com/ru/articles/913206/
#scada #plc_контроллер #esd #плк #промышленная_автоматизация #функциональная_безопасность #автоматизация #анализ_рисков #промышленное_программирование
-
Собираем демо чемодан из подручных остатков к выставке WBCE2025
Это краткая история о том, как за пару вечеров с помощью россыпи мелочевки с алиэкспресс, термопистолета и WAGO-вских клемм собрать демонстрационный чемодан к выставке.
https://habr.com/ru/articles/908602/
#асу_тп #асу #скада #диспетчеризация #овик #плк #plc #демонстрация_прототипа #своими_руками #scada
-
[Перевод] ПИД vs Интеллектуальные системы
Циклы управления на основе ПИД контролируют большинство автоматизированных процессов на промышленных предприятиях. Алгоритм пропорционально-интегрально-дифференциального (ПИД) регулирования прост, надёжен и за последние 50 лет применялся в сотнях тысяч систем управления. Однако не все промышленные процессы можно контролировать с помощью ПИД-регуляторов. Многофакторные, нелинейные и случайные процессы, например, требуют более продвинутых методов управления. Раньше подобные технологии были доступны только в академических лабораториях и в аэрокосмической отрасли, но с появлением доступных вычислительных платформ даже самые сложные алгоритмы стали доступны промышленным пользователям. Читать дальше
-
[Перевод] Пора ли менять DCS на универсальную систему управления?
Что такое универсальная система управления (UCS), и действительно ли она способна заменить распределённые системы управления (DCS) в будущих задачах по управлению технологическими процессами? Каковы основные преимущества UCS?
-
[Перевод] Виртуальный ПЛК – следующий шаг в цифровой трансформации архитектур автоматизации
Статья Дэвида Хамфри (David Humphrey), директора по исследованиям аналитического агентства ARC Europe, в которой рассматривается появление программно-определяемой автоматизации на уровне контроллера и ее влияние на то, как АСУ ТП будут проектироваться, развертываться и управляться в будущем. Речь идет о виртуальных ПЛК (vPLC) – программных средств, эмулирующих функции физических программируемых логических контроллеров.
https://habr.com/ru/articles/870360/
#vPLC #виртуальный_ПЛК #виртуальный_контроллер #virtual_PLC #плк #plc #plc_контроллер #асу_тп
-
[Перевод] Виртуальный ПЛК – следующий шаг в цифровой трансформации архитектур автоматизации
Статья Дэвида Хамфри (David Humphrey), директора по исследованиям аналитического агентства ARC Europe, в которой рассматривается появление программно-определяемой автоматизации на уровне контроллера и ее влияние на то, как АСУ ТП будут проектироваться, развертываться и управляться в будущем. Речь идет о виртуальных ПЛК (vPLC) – программных средств, эмулирующих функции физических программируемых логических контроллеров.
https://habr.com/ru/articles/870360/
#vPLC #виртуальный_ПЛК #виртуальный_контроллер #virtual_PLC #плк #plc #plc_контроллер #асу_тп
-
[Перевод] Виртуальный ПЛК – следующий шаг в цифровой трансформации архитектур автоматизации
Статья Дэвида Хамфри (David Humphrey), директора по исследованиям аналитического агентства ARC Europe, в которой рассматривается появление программно-определяемой автоматизации на уровне контроллера и ее влияние на то, как АСУ ТП будут проектироваться, развертываться и управляться в будущем. Речь идет о виртуальных ПЛК (vPLC) – программных средств, эмулирующих функции физических программируемых логических контроллеров.
https://habr.com/ru/articles/870360/
#vPLC #виртуальный_ПЛК #виртуальный_контроллер #virtual_PLC #плк #plc #plc_контроллер #асу_тп
-
[Перевод] Виртуальный ПЛК – следующий шаг в цифровой трансформации архитектур автоматизации
Статья Дэвида Хамфри (David Humphrey), директора по исследованиям аналитического агентства ARC Europe, в которой рассматривается появление программно-определяемой автоматизации на уровне контроллера и ее влияние на то, как АСУ ТП будут проектироваться, развертываться и управляться в будущем. Речь идет о виртуальных ПЛК (vPLC) – программных средств, эмулирующих функции физических программируемых логических контроллеров.
https://habr.com/ru/articles/870360/
#vPLC #виртуальный_ПЛК #виртуальный_контроллер #virtual_PLC #плк #plc #plc_контроллер #асу_тп
-
Зачем нужна диспетчеризация, или как «приготовить» SCADA на Linux
Множество инженерных систем, работающих на поддержание комфортных, или требуемых условий (температура и влажность воздуха, содержание СО2 и примесей, уровень освещенности, температура воды), время от времени выходят из строя, требуют технического обслуживания. Раньше дежурный инженер несколько раз за смену обходил все оборудование и проверял его исправность и режимы работы. Кому-то стало жарко в помещении - потопал менять уставку температуры на установке за тридевять земель. И так каждый раз. Если что-то выходило из строя, то узнавали об этом либо в очередной обход, либо от пострадавших.
https://habr.com/ru/articles/868996/
#асу #скада #диспетчеризация #овик #асутп #плк #plc #hvac #scada #scada_разработка_программирование
-
Ретроспектива: создание одних из первых автоматизированных рабочих мест
Продолжаю рассказ о предшественниках ПЛК , и сегодня коснемся об одних из первых в стране АРМов – автоматизированных рабочих мест и периферии для автоматизированной поверки датчиков.
-
Чужой в модуле Wiren Board: вживляем контроллер Lavritech с LoRaWAN
Мы разрабатываем модульные контроллеры Lavritech и считаем, что если объединить два хороших устройства, то можно получить решение еще универсальнее и интереснее. Так и сделали: интегрировали контроллер Lavritech в разные Modbus-модули Wiren Board — релейные, аналоговых и дискретных входов, счетчики электроэнергии — из обычного модуля получили ПЛК. В статье подробно расскажем о том, как разрабатывали решение, какие проблемы преодолевали и что получили в итоге.
https://habr.com/ru/companies/wirenboard/articles/852966/
#wiren_board #lavritech #esp32 #контроллер #modbus #rs485 #плк #lorawan #1wire #разработка
-
[Перевод] Коммуникации ПЛК
Как и в случае со многими функциями внутри программируемых логических контроллеров, мы можем обнаружить системы связи, встроенные непосредственно в модуль центрального процессора или установить дополнительные модули для расширения системы и повышения ее гибкости. Добавление усовершенствованных коммуникационных модулей в систему связи контроллеров является важным строительным блоком современных ПЛК. В какой-то мере модули, интерфейсы и системы связи, обеспечивающие сетевое соединение, способствуют превращению традиционных ПЛК в контроллеры автоматизации (ПАК).
https://habr.com/ru/articles/848754/
#плк #контроллер #коммуникации #связь #интерфейс #plc #plc_контроллер
-
Предшественники ПЛК – К1-20, МС2102 – история создания первых отечественных АРМов
Уважаемые коллеги, позвольте поделиться экскурсом в прошлое отечественной автоматизации, а именно в историю создания одних из первых отечественных аппаратных и программных средств АСУ ТП. Меня зовут Михаил Непомнин, ранее я был начальником КБ автоматизации ЭПО «Сигнал» и, как говорится из первых уст, готов рассказать о разработке первых автоматизированных рабочих мест.
https://habr.com/ru/articles/845016/
#арм #плк #МС2702 #контроллер #К120 #поверка #датчик #автоматизация_тестирования
-
[Перевод] Назад в будущее ПЛК
Технология программируемых логических контроллеров совершенно точно достигла зрелости – ей уже 60 лет. В связи с чем возникает вопрос: станут ли нынешние ПЛК «пенсионерами» и сойдут ли их будущие версии в могилу? Такое предположение кажется уместным, учитывая быстрое, а порой экспоненциальное развитие компьютерного оборудования, программного обеспечения, искусственного интеллекта, облачных сервисов и средств связи. Благодаря этим достижениям информационные технологии постепенно проникли в ранее изолированную сферу операционных технологий. В свете этих событий приводим статью Джеффа Пейна, опубликованную в журнале Control Engineering о будущем контроллеров и приложений промышленной автоматизации на фоне происходящей в последние десятилетия эволюции ПЛК.
https://habr.com/ru/articles/835410/
#плк #plc #plc_контроллер #modbus #iec_611313 #codesys #opc_ua #mqtt #асу_тп
-
ОбАСУчиваем дачу. Опыт эксплуатации и новые идеи
Окончание затянувшейся истории. Начало здесь. Продолжение здесь. «Когда дела идут хорошо, что-то должно случиться в самом ближайшем будущем» Второй закон Чизхолма. Итак, в начале июня дачная автоматика заработала. Поначалу всё шло хорошо, но вскоре появился странный эффект — в произвольный момент времени стало срабатывать УЗО. Причём, только в случае работы насоса от автоматики. В ручном режиме срабатывания не происходило. Хотя, вроде бы разницы между двумя режимами со стороны насоса быть не должно — контактная группа реле скоммутирована параллельно ручному выключателю. Иногда УЗО срабатывало буквально через несколько минут, иногда после довольно продолжительного времени. Вообще ещё в 2020г., когда мы делали на даче ремонт, и, в том числе, был установлен нормальный щиток вместо кое-как прикрученных «соплей», доставшихся от старых хозяев, знакомые мастера, увидев что я ставлю УЗО, говорили — оно у тебя выбивать будет, на дачных участках это обычное дело. Но за три года оно ни разу не сработало. А тут вдруг стало. В это время я находился в отъезде, так что разбираться в проблеме возможности не было. А через пару недель должна была уехать на летний отдых семья, и планировалось, что дача будет поливаться автоматически. А тут такая засада… Я поразмыслил, и попросил друга снять УЗО, заменив его автоматом с током срабатывания заведомо большим, чем у автомата на входе щитка — такое временное решение представлялось самым простым. Опасности, что кого-то в результате «дёрнет» не было — даче предстояло функционировать в полностью безлюдном режиме.
https://habr.com/ru/articles/816391/
#асутп #автоматизация #дача #плк #plc_контроллер #хоббипроекты #умная_дача #умный_дом #diyпроекты
-
10 видов угроз, с которых надо начинать мониторинг ИБ в АСУ ТП
Коллеги, всем привет! Меня зовут Илья Косынкин. В компании Positive Technologies я руковожу разработкой продукта для глубокого анализа трафика в технологических сетях — PT ISIM. На проектах в различных компаниях мы много сталкиваемся с практическими вопросами о том, как выстроить мониторинг ИБ в АСУ ТП. И это закономерно, ведь наша система решает именно эту задачу. Появилась идея описать, какую пользу может принести мониторинг ИБ в АСУ ТП, не уходя глубоко в детали функциональности продуктов, их классов и возможной архитектуры внедрения в инфраструктуру компании. Только value от этого процесса, без описания cost. При этом постараюсь рассказать вам научно-популярно, без воды. А для наглядности я буду использовать в статье скрины интерфейсов наших решений. Если интересно — добро пожаловать под кат
https://habr.com/ru/companies/pt/articles/814325/
#cybersecurity #софт #кибератаки #впо #инженерное_по #асу_тп #windows #linux #плк #технологическая_сеть
-
Разработка универсального ПЛК для домашних агрегатов
Некоторое количество оборудования в домашнем хозяйстве имеет довольно похожую структуру. В нем есть мотор, пользовательский интерфейс в виде кнопок и дисплея, управление подсветкой и местным освещением, электромеханические элементы в виде замков, соленоидов, клапанов, реле и множество защитных датчиков и выключателей. Рынок полон предложений для реализации системы управления для всего этого. Но дело в том, что меняются возможности индустрии разработки электроники, ценовые балансы и запросы потребителей. Сделать свой универсальный ПЛК иной раз проще чем приобрести и освоить экосистему стороннего производителя.
-
Разработка универсального ПЛК для домашних агрегатов
Некоторое количество оборудования в домашнем хозяйстве имеет довольно похожую структуру. В нем есть мотор, пользовательский интерфейс в виде кнопок и дисплея, управление подсветкой и местным освещением, электромеханические элементы в виде замков, соленоидов, клапанов, реле и множество защитных датчиков и выключателей. Рынок полон предложений для реализации системы управления для всего этого. Но дело в том, что меняются возможности индустрии разработки электроники, ценовые балансы и запросы потребителей. Сделать свой универсальный ПЛК иной раз проще чем приобрести и освоить экосистему стороннего производителя.