Почему разработчикам железа важно проводить качественный cusdev

Когда речь заходит об автоматизации процессов в нефтехимической отрасли, часто срабатывает стереотип, что производство сложное, значит, автоматизировано там всё, до чего можно дотянуться, благодаря АСУТП-системам. На самом деле не совсем так.

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

ndeqnl0fx7be2zqxfyqmem7klw8.png

Большинство некритичных процессов не автоматизировано, но это можно сделать с помощью технологий интернета вещей, а не АСУТП.

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

В этом посте мы и поговорим об этой проблеме и о том, как ее решить.

IoT в нефтехимии


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

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

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

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

Это первый полезный кейс возможного применения IoT на производстве.

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

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

В общем, как замена масла в автомобиле каждые 15 000 километров. Кто-то может накатать это за полгода, кому-то потребуется год, а у кого-то уйдёт ещё больше времени, в зависимости от того, как активно используется конкретное авто.

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

Если все это учитывать и проводить обслуживание таким образом, то можно сократить затраты на обслуживание динамического оборудования на 20, а то и на 30 процентов. С учетом масштабов производства — это очень существенные цифры, без потери качества и без снижения уровня безопасности. И это готовый кейс для использования IIoT на предприятии.

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

Это и есть то модное data driven decision, когда решения принимаются на основе полноценной работы с данными, которые собрали. Облака и аналитика сегодня пользуются особой популярностью, на Открытых Инновациях в этом году очень много говорили о бигдате и облаках. Все готовы работать с бигдатой, обрабатывать, хранить, но сначала данные необходимо собрать. Об этом говорят меньше. Сейчас очень мало хардварных стартапов.

Третий кейс IoT — трекинг персонала, обеспечение навигации по периметру и прочее. Мы используем это, чтобы следить за перемещением сотрудников и мониторить закрытые зоны. Например, проводятся в зоне какие-то работы, во время которых в ней не должны быть посторонние — и есть возможность это наглядно контролировать в реальном времени. Или обходчик пошёл проверять насос, и уже долгое время находится у него и не движется — может быть, человеку стало нехорошо, нужна помощь.

О стандартах


Ещё одна проблема — нет и интеграторов, готовых делать решения для индустриального IoT. Потому что в этой сфере до сих пор нет устоявшихся стандартов.

К примеру, как обстоят дела у нас дома: есть wifi-роутер, можно купить что-то ещё для умного дома — чайник, розетку, IP-камеру или лампочки — подключить всё это к уже имеющемуся wifi, и всё заработает. Точно заработает, потому что wifi — это стандарт, под который всё заточено.

А вот в сфере решений для предприятий стандартов такого уровня распространённости нет. Дело в том, что сама компонентная база стала доступной по стоимости сравнительно недавно, что позволило железкам на такой базе конкурировать с человеческим ресурсом.

Если наглядно сравнивать, то цифры будут примерно таких масштабов.

Один датчик АСУТП для применения в промышленности стоит около $2000.
Один LoRaWAN-датчик — 3–4 тысячи рублей.

10 лет назад были вообще только АСУТП, без альтернатив, LoRaWAN появилась лет 5 назад.

Но мы не можем просто взять и использовать LoRaWAN-датчики на всей территории наших предприятий

Выбор технологий


С домашним wifi все понятно, с оборудованием офисов всё примерно так же.

Популярных и общеиспользуемых стандартов в плане IoT в промышленности нет. Есть, конечно, куча разных индустриальных стандартов, которые фирмы разрабатывают под себя.

Взять, к примеру, wireless HART, который сделали ребята из Emerson — тоже 2,4 ГГц, почти тот же wifi. Зона такого покрытия от точки до точки — 50–70 метров. Если учесть, что площади наших установок превышают размеры нескольких футбольных полей, становится грустно. Да и одна базовая станция в таком случае может уверенно обслуживать до 100 устройств. А мы сейчас обустраиваем новую установку, там уже на начальных этапах более 400 датчиков.

А еще есть NB-IoT (NarrowBand Internet of Things), предоставляется операторами сотовой связи. И снова не для использования на производстве — во-первых, банально дорого (оператор взымает плату за трафик), во-вторых, формируется слишком сильная зависимость от операторов связи. Если надо поставить такие датчики в помещения типа бункера, где связь не ловит, и нужно туда ставить дополнительное оборудования — придётся обращаться к оператору, платно и с непрогнозируемыми сроками исполнения заказа на покрытие сетью объекта.

Использовать чистый wifi на площадках невозможно. Даже домашние каналы забиты что на 2,4 ГГц, что на 5 ГГц, а у нас производственная площадка с огромным количеством датчиков и оборудования, а не просто по паре компьютеров и мобильных на квартиру.

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

Поэтому альянс LoRaWAN видится весьма хорошим выходом, технология активно развивается и, на мой взгляд, имеет все шансы дорасти до полноценного стандарта. После расширения RU868 частотного диапазона, у нас каналов стало больше, чем в Европе, а значит, по ёмкости сети можно вообще не стесняться, что делает LoRaWAN отличным протоколом для периодического сбора параметров, скажем, раз в 10 минут или раз в час.

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

w5tt-4ktrk8aofrnlmq0btmwzt4.png

Чего же ещё не хватает?

Отсутствие диалога


Между хардварными разработчиками и заказчиками из нефтехимии или нефтегаза не хватает диалога. И получается, что айтишники делают отличное с точки зрения IT железо, которое невозможно массово использовать на нефтехимическом производстве.

Например, железка на LoRaWAN для измерения температуры труб: повесил на трубу, прикрепил хомутиком, повесил радиомодуль, закрыл точку контроля — и всё.

oj0xi0k-sohlz1-4ynbzz9gqnqo.jpeg

Оборудование в части IT подходит абсолютно, а вот проблемы для индустрии.

Батарея на 3400 мА·ч. Конечно, не самая простая, здесь тионилхлоридная, что дает ей возможность работать и в -50 и не терять емкость. Если мы раз в 10 минут посылаем инфу с такого датчика, он посадит батарею за полгода. В штучном решении ничего страшного —раскрутил датчик, вставил новую батарейку за 300 рублей раз в полгода.

А если это десятки тысяч датчиков на огромной площадке? На это уйдёт огромное количество времени. Убрав человеко-часы, затрачиваемые на обходы, мы получим то же время на обслуживание системы.

Довольно очевидное решение проблемы — ставить батарею не за 300 рублей, а за 1000, но зато на 19 000 мА·ч, её придётся менять уже раз в 5 лет. Это нормально. Да, это немного повысит стоимость самого датчика. Но отрасль может это себе позволить и отрасли это действительно необходимо.

Никто не касдевит, поэтому никто не знает про нужды отрасли.

И о главном


А ещё самое главное, на чём спотыкаются именно из-за банального отсутствия диалога. Нефтехимия — это производство, и производство довольно опасное, где возможен сценарий локальной утечки газа и формирования взрывоопасного облака. Поэтому всё без исключений оборудование должно обладать взрывозащитой. И иметь соответствующие сертификаты взрывозащиты согласно российскому стандарту ТР ТС 012/2011.

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

Что делать


Всё просто — общаться. Мы готовы к прямому диалогу, меня зовут Василий Ежов, владелец продукта IoT в СИБУРе, вы можете писать мне здесь в личку или на почту — ezhovvs@sibur.ru. У нас есть готовые ТЗ, мы всё расскажем и покажем, какое и для чего нам нужно оборудование и что нужно учитывать.

Прямо сейчас мы уже строим ряд проектов на LoRaWAN в зелёной зоне (там, где у нас взрывозащита не является обязательным параметром), смотрим, как оно в целом, и подходит ли LoRaWAN для решения задач в таких масштабах. На маленьких тестовых сетях нам очень понравилось, сейчас строим сеть с высокой плотностью датчиков, где на одной установке планируется около 400 датчиков. По количеству для LoRaWAN это немного, но вот по плотности сети — уже многовато. Так что проверим.

На ряде высокотехнологичных выставок от меня производители железок вообще впервые слышали о взрывозащите и её необходимости.

Так что это, прежде всего, проблема коммуникации, которую мы и хотим решить. Мы очень сильно за cusdev, это полезно и выгодно всем сторонам, заказчик получает нужную железку под свои нужды, а разработчик не тратит время на создание чего-то ненужного или полную переделку имеющихся железок с нуля.

Если вы уже делаете что-то подобное и готовы расшириться на нефтегазовый и нефтехимический сектор — просто пишите нам.

© Habrahabr.ru