Comments 28
Очень может быть, но пока сложно представить. При разработке активно используется нечто похожее на vPLC, это действительно очень удобно.
Что-то упростить в ПЛК можно только упростив программирование этих ПЛК. Но во всей этой статье слово программирование встречается только в названии хаба куда эта стаья помещена.
Текст похож на галюцинацию какого-то ИИ.
идея может и имеет смысл, но на малых системах пока нет необходимости применять подобное, а на больших возникают другие вопросы, вроде: как проводит аудит безопасности подобной системы? где будет разделения уровней автоматизации? как обеспечивать надежность отдельных виртуальных ПЛК и что бы они не мешали друг другу? Допустимо ли использовать в Safety-периметре?
В больших системах вообще централизация управления - сомнительная вещь, всегда вроде стремились к децентрализации для повышения надежности )
Что будет, если накроется сервак, в котором крутятся несколько виртуальных ПЛК, управляющих технологическими процессами, которые нельзя прерывать? Сразу куча испорченной продукции на разных стадиях? Куча агрегатов, зависших в непонятном состоянии?
Интегрировал как то у Сименса СКАДу для Электростанции на двух серваках с дублированием, переключение менее пары секунд при потере ведущего сервера, так что это решаемо.
В виртуализации есть схема с узлами, которые работают независимо друг от друга. И в случае выхода из строя узла, на котором работает виртуальный плк, его функции принимает другой узел, на котором есть реплика данных этого плк. Есть даже миграция в режиме онлайн, но для этого нужен отдельный сервер хранения образов виртуального плк и там даже не прерываются сеансы связи и потоки информации.
Так уже. ЧМИ часто ставят в конфигурацию сервер-клиент, так как иначе сеть не будет вывозить все то огромное количество данных. Я был свидетелем как на малом металлургическом заводе (печь, МНЛЗ и прокатный стан) выбило питание в серверной где крутились виртуальные машины в серверной. Никто не пострадал, но весь завод встал.
SoftPLC существуют давно и это не фантазия.
Тот же сименс преподобный выпускает для своих промышленных ПК надстройку, можно плат с профибасом натолкать и сделать периферию распределенную.
https://mall.industry.siemens.com/mall/en/WW/Catalog/Products/10268313?activetab=productinformation
ПЛК это в первую очередь высоконадежное устройство и реалтаймом. Судя по тенденциям с выдуманной открытой АСУ ТП, вместо того, что бы везде напихать OPC UA и OPC UA TSN и жить счастливо, мы изобретаем троллейбус из буханки хлеба. Еще ведь питона натолкают и будут хлопать в ладоши.
Почему никому в голову не ударило сокеты унифицировать у процессоров? Да потому что под это государство денег не даст, а тут КИИ, кибербезопасность и прочее...
полностью согласен! как-то я работал в одном цехе, где не было ПЛК, были устройства связи с объектом, модули Advantech ADAM + самописная SCADA на сервере. и это была огромная проблема. Цех изо всех сил пытался перейти на нормальные ПЛК и нормальную СКАДУ. Но сложное руководство комбината каждый раз проваливало эту задачу. Вся проблема была в надежности и быстродействии.
Никогда сервер не будет надежней ПЛК и панели оператора, которые стоят в шкафу. У "программного ПЛК" точек отказа намного больше. в случае цеха, где я работал - это конвертеры RS485-Ethernet, 2 свитча, 2 медиаконвертера оптики, сервер, и non-RTOS операционная система сервера. Кроме того, нормальный ПЛК - это физический объект, а не виртуальное нечто типа "софт плк" (в конкретном случае можно считать, что его нету), на железо есть регламенты обслуживания и функциональных проверок предприятия, типа протяжки клемм, продувки пыли, что может быть выполнено просто техниками КИПиА, в отличие от софтплк, где требуются инженера на эти же задачи (предположим, что их можно хоть как-то сформулировать). Кроме того, отказ одного нормального ПЛК на одном технологическом участке не ведет к отказу нормального ПЛК на другом участке. софт плк - сервак грохнулся, и все софтплк пошли по одному месту.
Как то немного сомнительно выглядит, врятли в нашей стране крупные производства захотят переходить на подобную систему в отказ от обычного плк. Надёжность все таки решает, когда на серве крутиться слишком много, его отказ становиться слишком болезненым. По опыту с плк редко что то происходит, но а вот сервак нет нет да и упадёт раз в несколько лет, не часто но все же
моторчики то куда подключать будем? к lpt порту, как match3? Так они и то сделали внешнюю плату для этого. Чтобы взаимодейтвовать с внешним миром все равно нужны всякие dio и aio. Уже сейчас есть тенденция делать относительно "тупые" модули ввода вывода на modbus. это хорошо до тех пор пока скорости 9600 бод "хватит на всех". Как только чтото побыстрее - модуль становиться более интеллектуальным. в результате современный частотник уже сложнее простого плк, и иногда обладает функциями программирования.
алгоритмы управления все равно реализует софт, вопрос только где он крутиться
Англичане распространяют свою агентуру во всех странах, их интересующих. Американцы в 90-х решили, что агентура не нужна, ибо они могут все узнать через компьютеры и интернет. А, если все узнать, то и на все воздействовать. Что они и делали неоднократно. Например разрушив иранские центрифуги для обогащения урана. И даже в PLC Siemens нашли вирус. Что в принципе невозможно, но факт. И даже Саяно-Шушенскую ГЭС разрушили именно они, но это неточно. Было дело, вскрывал я станок, который отказался работать при перемещении его с одного места на другое. Повезло, взломал и работать заставил. А если нет, тогда чего? Производство встанет. И вставало. Почему и импортозамещение. А виртуальный PLC - 100% воздействие. Потому самый простой способ защиты - сделать железный PLC и не подключать его к сети.
Вы что использовали ChatGPT для генерации комментария?
даже Саяно-Шушенскую ГЭС разрушили именно они
К счастью ее пока никто не разрушил, там просто поломались турбины, точнее взлетели.
Не нужно искать тайные смысли там, где их нет. На СШГЭС ситуация проста до банальности. В следствие советского раздолбайства и пофигизма не смогли точно сделать турбину и все остальное юстировать. А еще ее утопили и погнули когда доставляли по воде. Масса, как и скорость турбины очень большая. При выходе на расчетную частоту вращения, турбина давала очень сильные колебания и входила в резонанс с конструкцией машинного зала, что неизбежно приводит к разрушению конструкции.
Но "высокоинтеллектуальное" руководство посчитало, что негоже гонять турбину на мощности ниже проектной. Поэтому распорядилось снять лимиты с механизма блокировки вращения турбины. Большая частота вращения, больше энергии, больше денег, так жадность менеджмента и погубила станцию. Вот и все, не надо придумывать себе всякие фантазии в виде англичанка гадит, слишком много почестей делаете им.
В моем комментарии сказано, что англичане распространяют свою агентуру. В случае с Саяно-Шушенской ГЭС английские агенты должны были ее взорвать или сделать что-то подобное. Такого не замечено, потому это не они. Наиболее употребляемые PLC немецкие и американские. В программировании англичане несильны. Потому или немцы или американцы. А упомянутая вами причина аварии - для успокоения народа. У нас как правило заключения политически нейтральны. В среде автоматизаторов информация распространяется именно такая: вирус в системе управления. Ему и имя есть. А про советское разгильдяйство - СССР в те времена уже не существовал. А ППРы делаются регулярно в промышленной эксплуатации.
В случае с Саяно-Шушенской ГЭС английские агенты должны были ее взорвать или сделать что-то подобное.
Я тоже люблю различные как их называют теории заговора. Но в данном случае это точно не этот случай. Дело в том, что в районе г. Красноярска есть закрытие площадки хранения радиоактивных материалов. В случае прорыва СШГЭС все это смыло бы в море, затем по воде, согласно течению принесло бы к берегам туманного Альбиона. Я не спорю, что существует английская агентура, и возможно она работает против РФ, но пакостить не ценой же собственного экологического благополучия.
А упомянутая вами причина аварии - для успокоения народа
Официальная причина друга, во всем виноваты шпильки. Но любой человек знающий школьный курс физики прекрасно поймет, что во всей вселенной не существует шпилек способных удержать подобные агрегаты. Все банально просто, энергия не может просто исчезнуть, она переходит из одного вида в другой. В случае СШГЭС энергия могла уйти только в разрушение, а энергии там было немерено, поэтому все и разворотило.
как правило заключения политически нейтральны
Потому что не надо искать того, чего нет. Под такие случаи легко маскировать действия "каких-то врагов". На практике все банально просто, тупость, жадность, раздолбайство и является причинами подобных проблем. Я детально разбирал различные техногенные аварии, например в Красноярском крае горела Березовская ГРЭС и я вообще не был удивлен. Потому что Юнипро экономит на безопасности. Им русские предложили хороший проект, но они отказали, потому что турецкий оказался в три раза дешевле. Как турки замечательно строят мы знаем на примере землетрясений и вообще в принципе. Турки шьют замечательные вещи и делают вкусные продукты питания, но строительство не их конек явно.
В среде автоматизаторов информация распространяется именно такая: вирус в системе управления.
Дате пруфы интересно почитать, можете в личику. Я лично разговаривал со старожилами, которые устанавливали турбины и "латали" их в советское время. Никакой точно юстировки не делали, именно поэтому советский союз покупал западную оптику, гигантов строили, но точно юстировать не могли. И именно из-за отсутствия точной технологической культуры не смогли правильно отцентрировать турбину, т.е. у нее есть смещение центра тяжести. Из-за этого начинаются сильные колебания, это как вибро в телефоне. Крутится двигатель, а болтается весь телефон. Вот и тут такая же ситуация. Сильнее крутится, сильнее вибрирует, а потом бац и резонанс, и все, далее можно просто посмотреть на ТвойТелевизор к чему приводит резонанс на больших строительных объектах.
А про советское разгильдяйство - СССР в те времена уже не существовал
Это какая-то фантастика. Читаем на ресурсе "однако в постоянную промышленную эксплуатацию она была принята лишь 13-го декабря 2000-го года". Вы случайно не в курсе, почему в пром эксплуатацию не сдали еще во время советского союза, если 17 октября 1970 года в основные сооружения станции был уложен первый кубометр бетона, а уже к 1986 году выработано 80 млрд кВт⋅ч?
А можно в середине статьи не съежать на другую абриеватуру...
Как уж заметили выше плк это не только софт, но и аналоговые каналы управления и связи с датчиками. Замену старому доброму токовому физическому каналу 4-20 мА что-то не видать пока. Вся метрология датчиков основана на аналоговых каналах, а не цифровых и виртуальной плк здесь не нужен, он превращается в лишнее звено cистемы управления не более.
Remote IO на profinet/ethernetip/ethercat и т.п. вполне справляются.
согласен! цифровые каналы связи датчика с ПЛК может и имеют достоинства, но ни одно из них не нужно основной массе предприятий. по моему опыту даже богатые компании не хотят использовать цифровые шины. Зато из-за цифровых шин растут требования к квалификации киповцев, и, соответственно, зарплата.
А с "софтПЛК" потребуется еще и более высокая квалификация инженеров при эфемерных преимуществах.
IO-link можно считать заменой 4-20. Имел возможность поиграть с ним на одной установке с устройствами от ifm.
Автор молодец толи Гугл перевод с индусского, толи цифровой бред гпт. Даже не попытался привести статью к какому-то предмету для обсуждения или осмысления. Просто какая-то чушь.
Основная проблема виртуализации это realtime, если safety вынести на отдельные контроллеры то вполне может быть жизнеспособно. Сервера можно дублировать для отказоустойчивости и крутить сервер скады и vPLC на одном железе. А плюсы это упрощённое программирование и обеденная среда разработки, но это все скорее для крупных задач, а небольшие станки продолжат работать на классических PLC.
Вообще тема с виртуальными плк это как 3д моделирование, можно в виртуальной песочнице смоделировать бизнес процесс, который необходимо запустить или изменить. И такой вариант позволит избежать много шишек, которые возникнут на этапе внедрения без оного. Например, определить модели датчиков и сенсоров, необходимых для этого процесса. Ибо скорее всего на практике получается, что выбрали определенный датчик, а он оказался не подходящим в реальных условиях.
Ту же интеграцию с другими сервисами, например в виртуальности протестировать, не ломая работающий процесс. Да много каких выгод дает данданная возможность
Но в этом случае нужно виртуализировать не только плк, но и всю периферию, соединения и пр. Весь процесс.
А при успешной реализации виртуальной модели, перенести все в живую будет делом техники. Кроме этого, на этой виртуальной системе можно тестировать и обучать персонал работе на участке, как тренажоре и с устранением неисправностей.
Как вариант, можно комбинировать работу виртуальных плк с железными, например, при отказах, передавать часть функций на железо, где это критически важно или при длительном переходе между узлами витруальных серверов, обрыве линий связи... С другой стороны с виртуальными плк ты видешь актуальность данных в работе плк, настройках...
Перевод хороший, ИМХО на основе материала лучше было бы сделать более информативную полноценную статью, т.к. тема достаточно обширная.
В исходном материала на картинке есть Docker, а в тексте отсутствует. У вас же Docker вообще исчез из картинки. ИМХО картинку оставили бы как в оригинале, Firewall переводится как МСЭ, как говориться переводите либо все, либо ничего. Ну и картинка от David Humphrey так себе поясняет структуру, скорее запутывает. Лучше бы подошла инфографика с разделением на уровни программной и аппаратной логики.
Статье не хватает конкретики, а именно что подразумевается под программным слоем исполнения vPLC. David Humphrey на картинке указал что это Docker. Подобный подход у меня был в посте Метеостанция на Banana Pi M64 (Linux, C#, Docker, RabbitMQ, AvaloniaUI), где я ссылался на опыт Toradex. Но это может быть не только Docker, но и полноценный гипервизор с запуском различных ОС. т.е. на одном устройстве могут соседствовать например Linux и Windows системы.
В посте никак не оговаривается ситуация с распределением аппаратных ресурсов между vPLC. Необходимо каким-то образом управлять и распределять ресурсы. Например, я пробрасывал устройство GPIO как есть, напрямую в docker контейнер строками:
devices:
- /dev/i2c-1
- /dev/gpiochip1
volumes:
- /sys/bus/w1/devices:/sys/bus/w1/devices
- /sys/devices/w1_bus_master1:/sys/devices/w1_bus_master1Но это монопольный доступ, а как быть в случае совместного доступа.
Еще момент с распределением ответственности. Когда один вендор поставляет готовую железку с ПО и сам полностью за нее отвечает, вопросов не возникает. А как быть в случае появления внештатной ситуации, когда за железо и ПО отвечают разные вендоры. Вопросов на самом деле с vPLC вагон и маленькая тележка.
В завершение поста у David Humphrey просто написаны общие фразы без конкретики. Хотелось бы увидеть, например сравнительную таблицу плюсов и минусов подхода использования традиционных PCL и vPLC. Как говориться идеальных средств не бывает и всегда присутствуют отрицательные моменты и ограничения.
Относительно vPLC все довольно абстрагировано и это пока теоретические модели, что касается этапов реализации таких виртуальных платформ, на мой взгляд это программные логические контроллеры, которые сегодня уже присутствует в виде коробочных решений на базе CISC x86 где вся логика управления внешним, расширяемым GPIO, это софт с пользовательским интерфейсом (IDE) построения логических поведенческих сценариев в алгоритме с настройками параметров коммуникаций, мониторингом и симуляцией. Такие контроллеры идут на базе одноплатных SBC - IPC.
Виртуальный ПЛК – следующий шаг в цифровой трансформации архитектур автоматизации