Как мы перенесли управление инженерными системами в облако и сэкономили заправке 20% электроэнергии +22


В прошлом году сделали пилотный проект по облачной диспетчеризации для одной из сети АЗС. 

Проект интересный по двум причинам. Во-первых, у заказчика уже был опыт с системой автоматизации и диспетчеризации всех обычных инженерных систем в «стекляшке», но, прямо скажем, не самый удачный. Так что от нас потребовался апдейт. Во-вторых, мы все переделали сделали диспетчеризацию облачной, причем включили в неё еще и топливную автоматику. А это больше тысячи параметров — объём и уровень топлива в резервуаре, его температура, давление в топливном трубопроводе, жидкость и пары в купольной шахте, переполнение резервуара, низкий уровень топлива и многое другое. 

Вообще облачная диспетчеризация — хорошая штука для компаний, у которых есть не один, а несколько (лучше — много), территориально распределённых объектов. Дальше я расскажу, почему. А заодно о том, как мы реализовали этот конкретный проект. 

Верхнеуровневая автоматизация нужна, чтобы между всеми системами здания было взаимодействие, и они работали в единой логике. Ведь часто как бывает: в межсезонье в здании работает и кондиционер, и отопление. Одним холодно, другим душно. А электроэнергию при этом расходуют обе системы. 

Для начала мы стали разбираться, что накручено в уже существующей системе автоматизации и почему лыжи не едут. Первая задача была собрать все разрозненные системы АЗС и все имеющиеся датчики (разного типа, от разных производителей) в один красивый паззл. 

 Получилась примерно такая картина из систем АЗС:

  • освещение внешнее

  • освещение внутреннее

  • отопление радиаторное: электрическое, внутреннее

  • тепловая завеса на входе (спойлер очень энергозатратная)

  • вентиляция

  • кондиционирование

  • промышленный холод: холодильники для продуктов глубокой заморозки

  • технологии приготовления пищи: оборудование для фастфуда, микроволновки

  • технологии заправки (отдельная история «на сладкое»)

Вышло, что на АЗС есть девять серьёзных потребителей электроэнергии. Оборудование для локальной автоматизации было установлено, но протоколов взаимодействия между системами явно не доставало. 

Чтобы не увеличивать расходы, мы предложили не только выстроить работу всех систем, но и использовать облачную диспетчеризацию. Это и есть основная фишка проекта. Суть её в том, что не нужно помещение, колл-центр, серверное оборудование и собственно диспетчер. Вместо этого есть Облако КРОК (привет, коллеги!), специализированная цифровая платформа и веб-интерфейс, к которому заказчик получает доступ с любого рабочего места. Никакого «капекса»: компания покупает услугу облачной диспетчеризации по подписке и ежемесячно по тарифу оплачивает услугу. За это она получает не  только инфраструктуру, но и сервисную поддержку по решению. 

Настройка систем

Что мы делали конкретно? Вот, к примеру, внешнее освещение. В первую очередь, взяли архивную статистику по уровню освещённости и по фактическому включению групп освещения, проанализировали, сделали выводы и настроили алгоритм управления так, чтобы учитывалось сразу несколько параметров: уровень освещения в течение дня, время года, конкретный месяц… Тем самым исключили ситуации, когда летом в 4.30 уже светло, а заправка все равно продолжает светиться, как ёлка. 

Интерфейс управления наружным освещением
Интерфейс управления наружным освещением

В случае с внутренним освещением сделали автоматическое включение и выключение света от датчика присутствия во всех технических зонах и помещениях с непостоянным присутствием персонала. Есть, например, кабинет менеджера АЗС. 60% времени менеджер проводит вне его стен. А так как это небольшая тёмная комната без окон, то человек, выходя, часто забывает свет погасить. Знакомо? Теперь свет отключается автоматически по датчику.  

Интерфейс управления и контроля состояния внутреннего освещения
Интерфейс управления и контроля состояния внутреннего освещения

Для системы обогрева отключили ручную регулировку. Совсем. Вместо этого установили комфортную для конкретного сезона температуру. Настроить «под себя» теперь нельзя ни радиаторы, ни тепловую завесу на входе, которая, кстати, «кушает» 9 киловатт*часов. И если сотрудник её на полную мощность включил, а потом посетитель дверь чуть дольше подержал открытой, то все тепло моментально уходит, и мы греем улицу а вместе с теплом улетучиваются и деньги заказчика 

Согласовали режимы систем вентиляции, отопления, кондиционирования. Настроили так, чтобы их работа не пересекалась и не было «задвоения». В аппаратах, которые готовят еду, выставили режимы в зависимости от времени суток и количества посетителей на заправке. Логика простая: ночью гонять аппарат, который греет сосиски для хот-догов, нет смысла. И, конечно, в обычной ситуации никакой оператор или диспетчер не будет следить, чтобы в определённое время эта самая «сосикогрейка» отключилась. 

Вот еще парочка слайдов: 

Интерфейс управления климатом: вентиляция, кондиционеры, радиаторы, тепловая завеса
Интерфейс управления климатом: вентиляция, кондиционеры, радиаторы, тепловая завеса
Контроль промышленного холода: холодильники, витрины, лари
Контроль промышленного холода: холодильники, витрины, лари

Кастомный подход

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

ПЛК выполняет несколько функций: 

  • облачный шлюз;

  • шлюз, в котором можно загрузить локальную диспетчеризацию и через приложение управлять конкретной АЗС в случае, если связь с облаком нарушится. Например, выставлять уставку по любому из помещений; 

  • накопление статистики по работе и последующее усовершенствование алгоритмов взаимодействия. 

Программное обеспечение — российское решение с поддержкой же в России. Если честно, вменяемой альтернативы организации облачного сервиса на тот момент не было. Да и сейчас нет, потому что в таких проектах важен определенный функционал. Всё-таки мы имеем дело со сложной автоматикой и взаимной согласованностью самых разных систем. 

И вот тут самое время сказать про ту самую «изюминку» в проекте — топливную автоматику. Штука для АЗС нужная, многие заправки её используют, да и нам самим было действительно интересно её сделать. Честно, это оказалось мегасложной задачей. В комплектную топливную автоматику (систему управления, поставляемую вместе с топливной системой АЗС) зашито более 1000 параметров, которые мы научились вытаскивать, с кодами ошибок и онлайн-результатами, самодиагностикой сбоев. 

Вот как это выглядело в интерфейсе: 

После того, как систему запустили, начался обязательный этап пусконаладки под нагрузкой. Без неё было не обойтись, потому что речь идёт о решении, которого ещё не существует на рынке. Как это происходит в реальности? Настроили датчики, посмотрели, какая энергоэффективность. Дальше наблюдаем, можно ли ещё подкрутить. Меняется время года — корректируем температурный режим, время перехода досветки и так далее. 

Минус 20%

Интерес к облачной диспетчеризации множится, когда заказчик имеет не один объект, а много объектов, причем распределённых, в разных районах или регионах. При чем объектов достаточно небольших и «простых», чтобы было экономически невыгодно создавать на каждом из них отдельную систему диспетчеризации. Ситуация: звонит оператор заправки, сообщает о проблеме — жарко в помещении. Туда выезжает сервисная бригада, смотрит, что случилось, надо ли кондиционер настроить. А оказывается, что дело в вентиляции. Нужен электрик, который с ней разберётся. Это второй выезд. А так как заправки раскиданы по региону, то и расстояния значительные. В конечном итоге это все складывается в эксплуатационные затраты. А наша система позволяет увидеть и определить, вообще в кондиционере дело или нет?.. Значит, заказчик сразу может понять, какой мастер нужен на той или или иной АЗС. 

Вот ещё пример: для рефрижераторов по промышленному холоду программа сопоставляет температуры — то, что происходит на борту, и уставку. Если значения выходят за лимиты, в веб-интерфейсе появляется предупреждение — рефрижераторы сломаны, обратите на них внимание. Это вопрос уже выезда эксплуатации.

А теперь главные цифры. По факту за счет автоматизации нам удалось увеличить энергоэффективность на 20%, по сравнению с обычной, «неумной», АЗС. Кстати, по первоначальным расчетам, экономия на электроэнергии для одной конкретной заправки должна была составить не менее 12%. Но поскольку проект пилотный, и мы действительно заморочились тонкими настройками, процент существенно вырос. Расчетный период окупаемости проекта — 3-3,5 года.  Ну а если представить, что «подписка» на облачную диспетчеризацию есть на 10-20-30 заправках, легко понять, что экономия будет ощутимой. Ну и имидж энергоэффективного предприятия еще никому не помешал.  

Фотопруф для наглядности:

Продолжение следует

Проект этот у нас продолжается, кстати. Сейчас работаем с АЗС той же сети, но уже в другом регионе. Заправки не идентичны, и на втором объекте мы подключились на этапе проектирования. Постарались максимально все предусмотреть в проекте. 

Уже есть интересные примеры. Вот, скажем, продаются две тепловые завесы. Разница в цене у них не так велика, при этом одна с возможностью автоматизации, а у второй только пульт управления. Ещё из любопытного в проекте — более экономичные беспроводные датчики. Плюс солнечные панели, для которых мы устанавливаем элементную базу и настраиваем их согласованную с другими системами работу. 

Моя почта - ITsarev@croc.ru. Если остались вопросы, пишите - обсудим. 




К сожалению, не доступен сервер mySQL