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

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



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

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

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

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 минут, чтобы вести нормальную картину наблюдения, собирать данные и вообще отслеживать состояние оборудования. А в случае с обходчиками эта периодичность равна часу в лучшем случае.



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

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


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

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



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

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

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

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

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

И о главном


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

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

Что делать


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

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

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

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

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

Комментарии (27)


  1. Iceg
    16.11.2018 12:07

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

    Разработчики про это просто не знают.

    Собственно, потому оно и стоит не $1000 за термопару, а $1, нет? За взрывозащищенное исполнение себестоимость вырастет до 100, за сертификаты и маркировку еще $900 сверху.


    1. maledog
      16.11.2018 12:16

      Ага. Тоже сейчас посмотрел стоимость взрывозащитных корпусов для видеонаблюдения. Кожух стоит как 10 датчиков. Да и сертификацию никто не отменял. А цены там такие. что стоимость раз в 100 возрастет.


    1. digitalsibur Автор
      16.11.2018 15:03
      +1

      Например, посмотрите системы Стрелец-ПРО. Взрывозащита — не всегда дорого. Это просто важно сделать на этапе проектирования устройства, и получить сертификат.


      1. Iceg
        18.11.2018 21:57

        Извещатель пожарный ручной взрывозащищенный радиоканальный. Взрывозащищенный корпус: маркировка взрывозащиты: 0 ExiaIICT5. Цена 27615.76 руб
        Может, я не туда смотрю, но… кнопка за 30 тысяч?

        Это просто важно сделать на этапе проектирования устройства, и получить сертификат.
        Мне кажется, «просто» и «получить сертификат» в одном предложении несовместимы. Знаю историю, как одна компания на «получить сертификат» безрезультатно потратила несколько миллионов. Когда стоимость откатов стала превышать потенциальный профит, забили на это дело.


  1. prolis
    16.11.2018 12:23

    Что нам надо:
    1.Надёжное электропитание
    2.Надёжные каналы связи
    3.Защитные исполнения
    4.Стоимость на любой вкус
    Что мы хотим?
    -LoRaWAN?


    1. dkhromenko
      17.11.2018 05:38

      4. Стоимость на любой вкус
      4. Стоимость — договорная


  1. rub_ak
    16.11.2018 12:43

    1. Зачем нефтяникам IoT?
    2. Как связан IoT и LoRaWAN?


    1. digitalsibur Автор
      16.11.2018 15:07
      +1

      IoT нужен нефтяникам, как и всем остальным, чтобы автоматизировать процессы. В нашем случае LoRaWAN — это часть нашей IoT-системы.


    1. yvm
      16.11.2018 15:16
      +1

      Да.


  1. boroda_el
    16.11.2018 15:01
    +1

    Вот автор пишет, что с радиосетью не сложилось — слишком много устройств, слишком большой радиус. А акб тоже проблемы — нужно менять. А почему бы не использовать провода? Что-нибудь типа 485, modbus, с питанием по той же паре, с подключение всех датчиков шлейфом?


    1. digitalsibur Автор
      16.11.2018 15:05
      +1

      С радиосетью всё сложилось, работает. Но стоимость прокладки проводов на то количество устройств, которое нам необходимо, убьёт эффекты.


  1. Satyricon
    16.11.2018 17:54

    У вас, наверное, безопасников нет. Какой радиоканал? Это не секурно и не надёжно. Запретить!
    А вообще вся эта автоматизация должна была быть предусмотрена ещё на этапе строительства. Ну а про цену на взрывозащиту уже выше сказали.


    1. ianzag
      17.11.2018 11:47

      Протокол LoRaWAN подразумевает защиту передаваемых данных.


    1. hobogene
      17.11.2018 14:51

      Безопасников там, по опыту, более, чем достаточно :-)


  1. filinstop
    17.11.2018 09:48

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


    1. digitalsibur Автор
      17.11.2018 09:50

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


      1. hobogene
        19.11.2018 01:18

        Дерево и mesh это не одно и то же все-таки. Хотя тут кто во что горазд, тот так и называет. Плюс если данные нужны раз в час, то «на 59 минут» можно все гасить. Но возни, конечно, много будет с этим. Особенно если найдется пара узлов, через которые четверть трафика будет ходить, и они-то по закону бутерброда и умрут первыми. Star с деривативами в этом плане попроще.


  1. hobogene
    17.11.2018 09:48

    Базовую станцию найти подходящую в плане взрывозащиты будет потруднее, чем датчик. Надеяться на то, что ее можно будет поставить в сторонке (в зеленой зоне) я бы сильно не стал. Может, удастся. Может, нет.
    И нет надежды, что ее заново переделают «от самой платы и цепи до изоляции проводов.»


    1. ianzag
      17.11.2018 11:49

      Базовая станция сама по себе — вещь сравнительно простая. SX1308 + пара SX1257 и вот вам уже базовая станция. Осталось подобрать антенну и запихнуть в соответствующий корпус.


      1. hobogene
        17.11.2018 14:39

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


        1. ianzag
          17.11.2018 17:14

          Тогда какую бы вы посоветовали схематику?
          PS: Интерес не праздный.


          1. hobogene
            17.11.2018 18:11

            Я свой потенциал реалистично оцениваю. Мне повезло (действительно, просто повезло) поднабраться опыта, поигравшись с относительно крупными LoRaWAN проектами у нас в стране и не у нас в стране. И я могу указать на очевидные и бросающиеся в глаза потенциальные проблемы в имеющемся или предлагаемом решении, основываясь на вышеупомянутом опыте (частенько горьком). Но это не значит, что я лично могу разработать базовую станцию или ее LoRa-часть.

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


  1. hobogene
    17.11.2018 18:24

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

    Про количество каналов все-таки не совсем так уж радужно. Да и базуха опять дорожает, если больше восьми каналов надо.
    А на какой процент потери пакетов ориентируетесь, если не секрет?

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


    Я бы вот на жестяную стенку ее не крепил. На горизонтальную трубу на какой-нибудь кабельной стяжке или типа того подвесил.
    image
    Видите, какой формы корпус? Специально так, чтобы антенна вплотную к стене не оказалась. Да и то еще прокладку между стеной и устройством рекомендуют ставить. Чтобы не было жалоб про LoRa, которая почему-то только на 300 метров бьет.


  1. sub31
    18.11.2018 08:20

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


    1. hobogene
      18.11.2018 14:32

      Вполне возможно, что в данном случае хватит мух. И это ни разу не упрек.


  1. hobogene
    19.11.2018 01:21

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


    Ну и нетехнический момент — как только все это взлетит, бизнес у разработчика с немалой вероятностью просто отожмут.