Некоторые конторы выпускают панельные ПЛК, у которых совсем (или почти) нет физических входов-выходов. Т.е. весь ввод-вывод реализуется через модули по Модбас.
И я тут подумал - а чем собственно эта архитектура отличается от той, когда мы имеем панель оператора и те же модули-ввода вывода по Модбас?
Т.е. я беру панель оператора, рисую на ней графику и пишу макросы, которые вызываются по таймеру. Такой функционал в современных панелях есть обычно. Эти макросы могут опрашивать входы, производить вычисления и выдавать данные на выходы, т.е. реализуют традиционную работу ПЛК. При этом макросы пишутся на С-подобном языке, что удобно. И участки общей программы могут быть отдельными макросами и вызываться по отдельным событиям/таймерам, что тоже удобно. И обычно панели оператора имеют поддержку архивации, графиков, таблиц разных, т.е. того что в указанных "панельных ПЛК" есть не во всех.
Так что такое тогда "панельный ПЛК" без встроенного (или почти без) ввода-вывода, что его выделяют как отдельный именно вид контроллера?
Мы, кстати в своей конторе реализовали подобную архитектуру в реале - установка состоит из однотипных модулей, каждый из которых управляется ПЛК, но каскадирование этих модулей осуществляется макросами панели оператора. И все работает.
Но может есть какие-то специфические свойства, которые отделяют панель оператора в указанном применении, от именно "панельного ПЛК"?

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

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

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

А как же контроль времени цикла, контроль приоритета и вызова задач, программный и аппратный Ватчдог?
Панель если повиснет, переведет выполнение программы в макросах в Стор по исключению, в безопасное состонияе вывод?

Как написал один из коллег, для "безответственого" применения сгодится))

Обработчик исключений, деление на ноль, выход за диапазон массива.... выбор действия, в Стоп или обработка прерывания, для подмены индекса, знаменателя и т.д.

Ну ватчдоги и в панели должны же быть, она же тревоги всякие отображает, которые могут лампами не дублироваться часто. Поэтому она должна своевременно доносить до оператора данные. Ну и в распределенных системах главное надежность связи, мне кажется. А она что в панельных контроллерах, что в панелях оператора - одинакова. Наверное правильно выше написали - "грани стираются". Сам-то я за панельные контроллеры с встроенным вводом-выводом = хотя бы базовые функции можно на него повесить.

Есть ещё нюанс -
Обмен между панелью и блоками.
Это или Ethernet или RS485
Если это езернет - то вытекают все болячки локальной сети и ущербность обработки езернета на плк.
А если это 485 интерфейс, то он низкоскоростной и при опросе большого количества переменных может достигать десятки секунд! Что для некоторых техпроцессов недопустимо!

Отображение тревог с ватчдогом и правильной обработкой исключений никак не связано. Своевременно панель делать ничего не должна, в отличии от ПЛК, как нагрузите ЦПУ панели так и работать будет и время выполнения макросов плавать будет и т.д. В нормальных панельных ПЛК ядра ЦПУ делят между ЧМИ и RT ПЛК, при этом часть ПЛК не зависит от ЧМИ. Или вообще делают фактический 2 устройства в одном корпусе, каждый со своим ЦПУ связанных цифровой шиной обмена. По обмену с удаленным IO в ПЛК можно гибко подстроить обмен даже по тем же Modbus RTU/TCP и задачу синхронизации данных выбрать с фиксированным циклом, а если время обмена критично то использовать протоколы обмена Ethercat, Profinet, EthernetIP....

Адресные системы пожарной (!) сигнализации смотрят на Вас с недоумением...

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

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