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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О стандартах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И о главном

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

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

Что делать

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Два успеха частной космонавтики

На прошлой неделе произошло два достаточно важных события для частной космонавтики. Прежде всего, два пилота Virgin Galactic могут сверлить дырки в своих костюмах под значки астронавтов — поднявшийся 13 декабря до 82,7 км SpaceShipTwo оказался выше линии 50 миль, которая ...

Дайджест свежих материалов из мира фронтенда за последнюю неделю №343 (10 — 16 декабря 2018)

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.     Медиа    |    Веб-разработка    |    CSS    |    Javascript    |    Браузеры Медиа • Подкаст «Frontend Weekend» #83 – Илья Климов о том, как и зачем был создан образовательный проект JavaScript.Ninja• Девшахта #61: TypeScript и его ...