Комментарии 22
Простите, но это галимый пиар и "джинса" — тема не раскрыта. Просто ещё одна железка с IP66. Что конкретно ЭТОТ контроллер имеет в качестве программной поддержки "умного завода"? Какое ПО нужно "удалённо обновлять"? Куда этот контроллер должен ставиться (на станок? на цех? на предприятие?) и чем он лучше обычного ПК в безвентиляторном исполнен? Какие протоколы полевых шин он поддерживает, чтобы снимать инфу со станков с ЧПУ (условный кейс)?
Это просто еще одна интерпретация т.н. Field Agent — полевого агента.
Это контроллер, который может подключаться в практически любую систему, чтобы обеспечить ее связь с облаком. Основная функция — сборка и первичный анализ информации с существующих датчиков и систем, с последующей отправкой в облако. Управление — это уже второстепенная и на первом этапе внедрения IIoT обычно не реализуемая функция. Это потом, когда в облаке начинают вырисовываться оптимизационные стратегии, ее можно добавить, чтобы задавать более оптимальные режимы работы оборудования или людей.
Часто заводы живут по принципу: сломалось – починили, работаем дальше.
Т.е. о ППР (планово предупредительных ремонтах), которым сто лет в обед современные «эффективные менеджеры» и разработчики АСУ ТП не в курсе?
Современная стратегия — в том числе того, что описано в статье — переход от ППР и аварийно-восстановительных ремонтов к ТО по техническому состоянию, путём мониторинга (тока, вибро- и других видов технической диагностики, температур...)
ППР не очень легко предусмотреть, когда ресурс от устройства к устройству может сильно меняться. Допустим у вас есть две машины — одна под дедушкой, который ездит 4 тыщи в год, а другая под таксистом со 100 тыс в год. ППР выдаст для дедушки не очень приятный вариант и то, если он приедет в сервис.
А станок в сервис не затянешь и информацию "о километраже" нужно сначала из него вытащить.
Данная статья, у любого асутпшника, вызывает удивление, улыбку и недоумение. Все описанные «кейсы» существуют со времен царя Гороха. Сбор данных с многих тысяч (в буквальном смысле) датчиков? Анализ ПДК? Моделирование ТП на основании текущих показателей, исторических значений или внешних возмущений? Все это давно и давно используется и накоплена неисчисляемая уйма решений. Всего-лишь еще один контроллер в полку десятки и сотен контроллеров. И вместо вот этой вот воды, лучше бы написали, почему стоит выбрать данное решение, а не какой-нибудь Сименс, Шнайдер, Митсубиси, Адам/ИспДас (прости господи, но зато за копейки). Рассказали, как обстоят дела с интеграцией в существующие системы, как оно поддерживается популярными SCADA. И главное понимать, что описанная «IoT» — это обычная АСУ ТП, но, видимо, АСУ ТП продавать сложнее, чем хайповый «интернет вещей».
Даже если результаты мониторинга будут показывать, что все ок, то все равно будет выполнен капремонт с регламентированной заменой и/или дефектовкой всего перечня оборудования.
Так в этом и смысл таких систем. При классическом подходе с регламентированной заменой вы основываетесь на "средней температуре" по больнице. Тоже самое если вы "закладываете" ресурс на этапе проектирования. И в итоге вы тратите сколько-то денег на ППР и прочее плановое обслуживание. А теперь представьте, что вы могли бы тратить вполовину меньше и при этом не иметь никаких негативных последствий для производство? Или условно, вам надо будет останавливать вашу печь не по два раза в год, а всего один раз в год? Или если система за вас будет считать и рекомендовать, что при очередном ППР стоит заменить также вот этот датчик или клапан, так как его ресурс подходит к концу и он может не дотянуть до следующего планового ремонта?
Стоит ли это дополнительных датчиков и расходов на более навороченную систему мониторинга?
Другое дело КП, когда по совокупности накопленного износа (или даже других факторов, на которые мы не можем повлиять никакими измерениями, например фактором сезонности, контрактных или гарантийных обязательств) основного оборудования нет возможности продолжать работу без полной остановки ТП и/или переходе на резерв. Иногда сроки КП можно отодвинуть на основании текущих показателей, но иногда это невозможно, даже если все показатели в норме. Примеров можно привести массу, к примеру, возьмем какой-нибудь турбодетандер разложения воздуха, допустим Ротофлоу, который устанавливается поставщиком и для обслуживания которого у нас нет ни квалификации, ни опыта (или как сейчас модно говорить — экспертизы). Согласно обязательствам срок службы агрегата 5 лет (условно), а значит, хотим мы этого или нет, но через 5 лет либо приедет фура с новым турбодетандером и он будет заменен целиком, либо будет произведен КП по месту.
И все это существует и работает не один десяток лет.
Вы просто ошибаетесь насчет того, что это существует и работает десяток лет везде. В том то и дело, что в каких-то сферах, например нефтяной, это уже давно реализовано, а в других все еще есть дядя Вася — механик, который на глаз и цвет определяет, когда данному котлу или мотору придет капец. И это, если он еще не пьяный. Во многих случаях роль сигнализатора выполняет обыкновенный механический счетчик моточасов, который может сломаться, и никто об этом не узнает и т.д. А где-то водитель подрабатывает левым извозом. Новое и невероятно революционное в том, что сегодня можно мониторить практически все, затратив на это гораздо меньше средств. И это позволяет внедрить такие практики текушего ремонта и обслуживания, о которых раньше только мечтали. Еще раз — в некоторых, но достаточно весомых сферах.
У немцев, например, не клинит. Как пример правильного проектирования
перекидной клапан на зерне — относительно маломощное устройство и способен работать когда поток зерна не занимает весь объем трубы — в идеале сначала приостановить подачу (буквально 5сек), потом переключать.
«Компьютеризация», «автоматизация», «специализация» и тому подобное, это прекрасно — но если бы первоначально все подобные предприятия оборудовали сетью датчиков, реал-таймом связанных с общедоступным агрегатором статистики — про подобное я бы почитал с большим удовольствием
Первый случай рассмешил. Обходы не отменили, просто оптимизировали.
А что, на заводе, где используется аммиак, раньше не было датчиков? Не верю.
IIoT-технологии позволят уйти от ремонта по факту поломки к системе прогнозов неисправности (например, программа предупредит о том, что надо заменить определенные детали).
Один я вижу тут «нелогичность»? Замена износившихся деталей называется «техническое обслуживание» или «плановый ремонт» или «текущий ремонт». О том, за какое время та или иная деталь износится — и так заранее примерно известно. График техобслуживания и ремонтов тоже обычно заранее составляется.
А поломки по причине брака в деталях вряд ли IIoT предскажет.
Другое дело, что IIoT удобен для поддержания режимов, контроля за производством. Но это давным давно известно под именем «автоматизация производства». Ребрендинг?
Представим, что на заводе работают 150 станков с ЧПУ. С каждого устройства придется собирать данные: сколько часов оно было в работе, какой объем продукта получили на выходе, что с процентом брака. Если обрабатывать всю информацию «по старинке» вручную и заносить в бумажный журнал, можно сойти с ума.
Станки с ЧПУ объединялись в сети и передавали информацию на центральный компьютер ещё лет 30 назад — в СССР. Сам видел такое на производстве.
Да, сейчас электроника на порядки дешевле и «умнее». Но зачем подавать идею автоматического сбора данных, как какое-то ноухау?
Почему бы не вспомнить о временах, когда пахали на лошадях? )
Интернет вещей в промышленности: как работают «умные» заводы?