
Когда говорят про промышленные сети автоматизации, почему-то сразу представляют идеальную картинку из каталога — все датчики опрашиваются, ПЛК синхронизированы, а данные летят без потерь. В реальности же даже с такими монстрами как PROFIBUS или EtherCAT вечно вылезают нюансы, которые в спецификациях мелкими буквами пишут. Вот, к примеру, в проекте для металлургического комбината под Челябинском мы как-то три дня искали причину сбоев в сети — оказалось, монтажники кабель рядом с силовыми шинами проложили, экранирование не заземлили. А все потому что в техзадании про физический уровень много кто забывает.
Помню, как лет пятнадцать назад доминировали в основном последовательные интерфейсы типа RS-485. Тогда и ПЛК были попроще — Siemens S7-300, например, с модулями CP 342-5. Сейчас же, конечно, упор на Ethernet-based решения, но и старые системы никуда не делись. На том же заводе по производству автокомпонентов под Калугой до сих пор работают модернизированные линии с PROFIBUS DP, хотя уже постепенно переводим на PROFINET.
Интересно наблюдать, как меняется подход к программированию контроллеров. Раньше в Step 7 Classic в основном STL использовали, сейчас уже TIA Portal с SCALANCE-коммутаторами настраиваешь через графический интерфейс. Но парадокс — чем сложнее становится инструментарий, тем больше скрытых проблем возникает. В прошлом месяце как раз на объекте ООО Наньцзин Жуцянь Автоматизированное Оборудование при запуске линии сборки электрощитов столкнулись с тем, что ПЛК Siemens S7-1500 не видел часть IO-Link датчиков. Два дня разбирались — оказалось, в конфигураторе не тот GSD-файл подгрузили.
Кстати, про программируемые логические контроллеры — многие до сих пор считают, что чем новее модель, тем лучше. На практике же для 80% задач хватает возможностей ПЛК среднего класса. Мы в своих проектах часто используем контроллеры серии S7-1200, они и по цене оптимальны, и функционала для типовых решений более чем достаточно. Разве что для систем безопасности берем S7-1500 с F-версиями.
Расскажу про один характерный случай на пищевом производстве в Подмосковье. Заказчик хотел объединить в единую сеть три технологические линии — две старые на Modbus RTU и одну новую на EtherCAT. Причем данные со всех линий должны были стекаться в общую SCADA-систему. Сложность была в том, что протоколы разные, временные метки не синхронизированы.
Пришлось ставить шлюзы протоколов, причем не стандартные решения, а кастомные конфигурации на базе WAGO 750-8xx. Самое неприятное выяснилось при наладке — оказалось, на старых линиях датчики температуры имеют разное время отклика, плюс помехи от частотных преобразователей. Пришлось дополнительно ставить фильтры сигналов и переписывать часть логики опроса.
Вот здесь как раз пригодился опыт команды ООО Наньцзин Жуцянь Автоматизированное Оборудование в области интеграции разнородных систем. Использовали подход с буферизацией данных через OPC UA сервер, что позволило нивелировать рассинхронизацию. Но пришлось повозиться с настройкой временных окон — где-то увеличили периодичность опроса, где-то наоборот, уменьшили чтобы не перегружать сеть.
Самая распространенная ошибка — недооценка нагрузки на сеть. Всегда кажется, что ?и так сойдет?. Помню, на одном из объектов по производству строительных материалов заказчик сэкономил на коммутаторах — поставили обычные офисные вместо промышленных. Результат — постоянные потери пакетов при пиковых нагрузках, когда одновременно несколько приводов запускались.
Еще один момент — резервирование. Многие проектировщики до сих пор пренебрегают кольцевыми топологиями или дублированием линий связи. А потом при обрыве кабеля вся линия встает. Мы в последних проектах всегда закладываем MRP или аналогичные технологии, особенно для ответственных участков. Да, дороже, но простоя оборудования обходятся несопоставимо дороже.
Отдельно стоит сказать про документацию. Часто встречаю ситуации, когда после монтажа схемы подключения не соответствуют реальности. Особенно это касается распределенных систем вроде AS-i — там где один датчик неправильно адресован, может полсегмента работать некорректно. Поэтому сейчас всегда требуем от монтажников фотофиксацию каждого подключения.
Современные программируемые логические контроллеры — это уже не просто устройства для замены реле, а полноценные сетевые узлы. При программировании приходится учитывать не только логику управления, но и сетевые аспекты — время прохождения сигнала, приоритеты телеграмм, обработку ошибок связи.
Например, в проекте для логистического центра использовали распределенную систему на базе ПЛК Beckhoff CX с EtherCAT. Пришлось тщательно рассчитывать циклы обмена данными между удаленными модулями ввода-вывода — где-то уменьшали количество данных в одном телеграмме, где-то увеличивали частоту опроса критичных датчиков.
Интересный случай был при отладке системы управления прессом — там оказалось критичным время реакции на аварийный сигнал. Стандартные настройки EtherCAT давали задержку около 10 мс, а нужно было не более 2 мс. Пришлось переконфигурировать сеть, выделив аварийные сигналы в отдельный datagram с высшим приоритетом.
Сейчас активно развиваются технологии TSN — но честно говоря, пока это больше для showcase-проектов. В реальной промышленности переход будет постепенным, учитывая количество установленного оборудования с традиционными полевыми шинами.
Более практичное направление — интеграция IT и OT сетей. Но здесь тоже много подводных камней — вопросы безопасности, разные требования к детерминизму, квалификация персонала. Мы в ООО Наньцзин Жуцянь Автоматизированное Оборудование постепенно внедряем сегментирование сетей с помощью промышленных файрволов, но процесс непростой.
Лично я считаю, что в ближайшие 5-7 лет основным трендом будет не столько появление новых протоколов, сколько совершенствование инструментов диагностики и управления существующими сетями. Уже сейчас вижу, как востребованы системы типа SINEC NMS от Siemens — возможность мониторить состояние сети в реальном времени серьезно упрощает жизнь службам эксплуатации.
Кстати, про диагностику — недавно общался с коллегами с завода в Липецке, они внедрили систему предиктивной аналитики на базе PNI-данных. Оказалось, что по статистике сетевых ошибок можно предсказывать выход из строя определенных компонентов за 2-3 недели до фактического отказа. Вот это действительно полезное применение технологий Industry 4.0, а не просто модные слова.