Акт 1. “Просто выведите всё на один экран”
Хочу рассказать путь — от первого касания до промежуточной точки, до которой мы дошли примерно за два года.
Без ретроспективных украшений и без «так и было задумано с самого начала». Потому что, как обычно бывает в реальных проектах, сначала всё выглядело гораздо проще.
С нами связался технолог с фабрики из соседнего региона — Башкирии.
Разговор был короткий и очень приземлённый. Никакой аналитики, никаких умных слов, никакого аудита.
История данных — не нужна.
Отчёты — не нужны.
Оптимизация — потом, может быть.
Задача звучала буквально так:
«У нас две площадки, разное оборудование. Выведите данные на один экран диспетчера».
На одной площадке — BigDutchman Viper Touch, Orion.
На другой — Stienen PL9200.
Оборудование, интерфейсы, логика отображения — всё разное.
Дополнительной сложностью было то, что площадка с PL9200 не была физически связана локальной сетью с основной, где находился АБК предприятия, куда мы и ставили сам сервер. Для этого проекта было принято решение делать хранение данных на локальном сервере (on-prem), а не облачный хостинг. Нам повезло, что у фабрики были кадры, способные обслуживать и поддерживать это решение.
Эту площадку согласовали подключить через SIM-интернет. Перед этим специально проверили зону на уверенное покрытие сотовой связью и выбрали оператора, чьи вышки были ближе — иначе такие истории быстро превращаются в «у нас снова всё отвалилось».
Фактически диспетчер просто не мог видеть обе площадки одновременно. Чтобы понять общую картину, нужно было переключаться между системами, открывать разные интерфейсы, постоянно держать в голове, где какое оборудование и как оно себя обычно ведёт. Решения искали у официальных дистрибьютеров и поставщиков оборудования, но, очевидно, в текущих реалиях этого не добиться. Менять оборудование — дорого.
Моим контактом поделился ветеринар с другой фабрики, нас посоветовали просто как компанию, которая умеет выводить данные с любого оборудования.
На этом этапе у проекта не было никакой стратегии цифровизации. Никто не говорил про экономию, эффективность или предиктивную аналитику. Была обычная производственная боль: слишком много систем, слишком мало целостной картины.
Мы начали ровно с этого: без вмешательства в управление, изменения уставок и попыток сделать лучше, чем завод-изготовитель.
Мы просто начали забирать данные с контроллеров и сводить их в одном месте.
Там, где был физический интерфейс (COM-порт или RS-485) — подключались к нему. Там, где его не было — использовали программный уровень, по тому же принципу, как это делают официальные приложения производителей. В процессе мы собрали почти весь "зоопарк" протоколов: modbus, mqtt, REST API, WS(web-socket).
Для фабрики ничего не менялось в процессе работы: мы не меняли настройки управления микроклиматом, не меняли их уже работающие программы. Мы подключались параллельно до окончания работ.
Смены работали как обычно. Инженеры делали ровно то же самое, что и раньше. Просто появился экран, на котором данные стали появляться корпус за корпусом.
Первые месяцы проект вообще не воспринимался как что-то значимое.
«Ну да, теперь всё на одном экране — удобно».
Но по мере сдачи этого проекта нам начали задавать интересные и правильные вопросы:
- А сколько хранятся данные? Можно ли посмотреть их за вчера/ месяц назад?
- А можно ли сравнить этот корпус с другим?
- Можно ли добавить сюда другое оборудование? Вентиляторы? Генераторы?
- А есть удаленный доступ?
- А можно сделать тревоги не линейными?
Примером линейных тревог может являться установка: держи температуру от 21℃ до 25℃. Зачастую, необходимо следить за температурой таким образом, что комфортный микроклимат каждый день меняется.
... и много всякого еще.
Почти любая SCADA система обладает этим функционалом, поэтому через пару ВКС мы показали, какими "плюшками" они теперь могут пользоваться.
Не успели мы закрыться по этому проекту, как у клиента начал "разгуливаться аппетит"...