Блог компании Kauri
Промышленное программирование
Разработка для интернета вещей
Софт
Интернет вещей
Комментарии 22
+4

Простите, но это галимый пиар и "джинса" — тема не раскрыта. Просто ещё одна железка с IP66. Что конкретно ЭТОТ контроллер имеет в качестве программной поддержки "умного завода"? Какое ПО нужно "удалённо обновлять"? Куда этот контроллер должен ставиться (на станок? на цех? на предприятие?) и чем он лучше обычного ПК в безвентиляторном исполнен? Какие протоколы полевых шин он поддерживает, чтобы снимать инфу со станков с ЧПУ (условный кейс)?

0

Это просто еще одна интерпретация т.н. Field Agent — полевого агента.
Это контроллер, который может подключаться в практически любую систему, чтобы обеспечить ее связь с облаком. Основная функция — сборка и первичный анализ информации с существующих датчиков и систем, с последующей отправкой в облако. Управление — это уже второстепенная и на первом этапе внедрения IIoT обычно не реализуемая функция. Это потом, когда в облаке начинают вырисовываться оптимизационные стратегии, ее можно добавить, чтобы задавать более оптимальные режимы работы оборудования или людей.

0
Часто заводы живут по принципу: сломалось – починили, работаем дальше.

Т.е. о ППР (планово предупредительных ремонтах), которым сто лет в обед современные «эффективные менеджеры» и разработчики АСУ ТП не в курсе?
0

Современная стратегия — в том числе того, что описано в статье — переход от ППР и аварийно-восстановительных ремонтов к ТО по техническому состоянию, путём мониторинга (тока, вибро- и других видов технической диагностики, температур...)

0

ППР не очень легко предусмотреть, когда ресурс от устройства к устройству может сильно меняться. Допустим у вас есть две машины — одна под дедушкой, который ездит 4 тыщи в год, а другая под таксистом со 100 тыс в год. ППР выдаст для дедушки не очень приятный вариант и то, если он приедет в сервис.
А станок в сервис не затянешь и информацию "о километраже" нужно сначала из него вытащить.

0
Простите, но аналогия немного неверная. Информация «о километраже» любого оборудования на предприятии известна — будь то двигатель приточной вентиляции, флотационные насосы, ТЭНы, МЭО, погрузчики, форсунка плавильной печи, датчик уровня и вплоть до болтовых и клепаных соединений (обвешивание которых датчиками порой совершенно нерационально). Любой завод/комбинат — это прежде всего непрерывность производства на определенных отрезках времени, и сроки ППР закладываются чуть-ли не на этапе проектирования, на основании опыта эксплуатации схожих ТП, которые в дальнейшем определяются опытом конкретной эксплуатации в сложившихся условиях. Отсюда вытекает и резервирование, и классическая схема для жизненно важных для производства техпроцессов (например, кислородные цеха металлургических предприятий): в_работе — в_резерве — в_ремонте, ведь ППР — это не только профилактическая замена «рулевых тяг» на дедушкином Москвиче, т.е. текущий ремонт, если другими словами, но и капитальный ремонт оборудования и агрегатов, с полным выводом их из эксплуатации на время ремонта. Даже если результаты мониторинга будут показывать, что все ок, то все равно будет выполнен капремонт с регламентированной заменой и/или дефектовкой всего перечня оборудования.

Данная статья, у любого асутпшника, вызывает удивление, улыбку и недоумение. Все описанные «кейсы» существуют со времен царя Гороха. Сбор данных с многих тысяч (в буквальном смысле) датчиков? Анализ ПДК? Моделирование ТП на основании текущих показателей, исторических значений или внешних возмущений? Все это давно и давно используется и накоплена неисчисляемая уйма решений. Всего-лишь еще один контроллер в полку десятки и сотен контроллеров. И вместо вот этой вот воды, лучше бы написали, почему стоит выбрать данное решение, а не какой-нибудь Сименс, Шнайдер, Митсубиси, Адам/ИспДас (прости господи, но зато за копейки). Рассказали, как обстоят дела с интеграцией в существующие системы, как оно поддерживается популярными SCADA. И главное понимать, что описанная «IoT» — это обычная АСУ ТП, но, видимо, АСУ ТП продавать сложнее, чем хайповый «интернет вещей».
0
Даже если результаты мониторинга будут показывать, что все ок, то все равно будет выполнен капремонт с регламентированной заменой и/или дефектовкой всего перечня оборудования.

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

0
Вы смешиваете плановый, неплановый, текущий и капитальный ремонт. Если срок службы условного исполнительного механизма какого-либо оборудования 100.000 часов, то либо он будет заменен не более чем через 100.000 часов работы и вне зависимости от показателей работы снятых с каких либо датчиков, либо решение принимается по результатам мониторинга (на любой выбор — датчики температуры, вибрации, токопроводности, визуальный контроль или даже просто «ой, Михалыч, чувствую, что сейчас все эммм… сломается»), что в определенных ситуациях, разумеется, дает возможность значительно увеличить срок службы тех или иных агрегатов. Это лишь вопрос отвественности той или иной стороны, а так же вероятности волшебной трансформации планового ремонта в неплановый со всеми вытекающими. В случае выхода этого условной детали или агрегата из строя ранее установленного заводом-изготовителем срока службы — ответственность ложится на одну сторону. В случае превышения установленного срока службы вы все риски ложатся на другую. Стоит ли они того — это, конечно, решает каждый сам, для каждой конкретной ситуации. В любом случае, замена по результатам оценки установленного нормами технического состояния — это обычный плановый ремонт, в этом нет ничего нового. И все это существует и работает не один десяток лет. Поэтому ноу-хау какое-то странное — вроде подается как что-то новое и невероятно революционное, а по факту 20+ лет назад все это уже было. Это что касается ТР.

Другое дело КП, когда по совокупности накопленного износа (или даже других факторов, на которые мы не можем повлиять никакими измерениями, например фактором сезонности, контрактных или гарантийных обязательств) основного оборудования нет возможности продолжать работу без полной остановки ТП и/или переходе на резерв. Иногда сроки КП можно отодвинуть на основании текущих показателей, но иногда это невозможно, даже если все показатели в норме. Примеров можно привести массу, к примеру, возьмем какой-нибудь турбодетандер разложения воздуха, допустим Ротофлоу, который устанавливается поставщиком и для обслуживания которого у нас нет ни квалификации, ни опыта (или как сейчас модно говорить — экспертизы). Согласно обязательствам срок службы агрегата 5 лет (условно), а значит, хотим мы этого или нет, но через 5 лет либо приедет фура с новым турбодетандером и он будет заменен целиком, либо будет произведен КП по месту.
0
И все это существует и работает не один десяток лет.

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

0
Друзья, завязывайте уже с этим «галимым пиаром» и переходите к написанию интересных статей о микроконтроллерах и технологиях (благо, судя по вашему сайту, квалификация у вас для этого достаточная).
0
Так как Kauri занимается в том числе и разработкой IIoT-решений для заводов, мы сделали свой контроллер, который идеально подойдет для любого производства.

Хорошо бы эту ценную мысль не прятать в середине «публикации», а поместить в самом начале для экономии времени. Дальше читать нет смысла. И это Ленинград, что ж тогда в глубинке вытворяют?
+1
что ж тогда в глубинке вытворяют?

Офтоп не про заводы. Но производство. Элеватор. Заклинивает перекидной клапан(такая штука переводит поток зерна). Компетенции работников не хватает. SCADA ругается. Местный электрик с мотнажником. Один замыкает нужные провода. А другой приваривает лом, чтоб не перевели случайно. Ещё раз ПРИВАРИВАЕТ.

0
Там заклинивает, если зерно не выбежало — например короткие «штаны».

У немцев, например, не клинит. Как пример правильного проектирования
0

Клинит у всех: и у немцев, и у испанцев и у поляков. Нет такого оборудования с которым нет проблем. Объёмы не те. Вы работали с этим оборудованием? У наших тоже есть прекрасные клапана. Но когда объёмы выражаются миллионами тонн, то любое оборудование выходит из строя. Где то раньше, где то позже.

0
поинт бы не понят. клинит не из-за плохого клапана, а из-за неверного проектирования его установки.

перекидной клапан на зерне — относительно маломощное устройство и способен работать когда поток зерна не занимает весь объем трубы — в идеале сначала приостановить подачу (буквально 5сек), потом переключать.
0

Интересно, куда с появлением IoT, подевалась наука/специальность/направление "АПП" — автоматизация производственных процессов.

0
наука никуда не подевалась — см специальности в ВУЗах. просто на волне хайпа всплыла туча «пены»
+1
Умные заводы… хм, у нас с этим намного проще — днём дымят по чуть-чуть, а ночью или в туман чадят на полную. И утром рыжий снег.
«Компьютеризация», «автоматизация», «специализация» и тому подобное, это прекрасно — но если бы первоначально все подобные предприятия оборудовали сетью датчиков, реал-таймом связанных с общедоступным агрегатором статистики — про подобное я бы почитал с большим удовольствием
0
Даже если эту сеть датчиков сегодня и поставят, то увидев завтра утром «рыжий снег» в первых от отчётах опытной эксплуатации системы — как уже не раз в истории было, громко и с ужасом захлопнут весь этот шкаф со всеми старыми скелетами (не дай бог, кто ещё это увидит!) и продолжат существовать как раньше (ибо "`не взлетела` эта ваша новая система", как будет сказано в очередном отчёте о внедрении).
0

Первый случай рассмешил. Обходы не отменили, просто оптимизировали.


А что, на заводе, где используется аммиак, раньше не было датчиков? Не верю.

0
IIoT-технологии позволят уйти от ремонта по факту поломки к системе прогнозов неисправности (например, программа предупредит о том, что надо заменить определенные детали).


Один я вижу тут «нелогичность»? Замена износившихся деталей называется «техническое обслуживание» или «плановый ремонт» или «текущий ремонт». О том, за какое время та или иная деталь износится — и так заранее примерно известно. График техобслуживания и ремонтов тоже обычно заранее составляется.

А поломки по причине брака в деталях вряд ли IIoT предскажет.

Другое дело, что IIoT удобен для поддержания режимов, контроля за производством. Но это давным давно известно под именем «автоматизация производства». Ребрендинг?

Представим, что на заводе работают 150 станков с ЧПУ. С каждого устройства придется собирать данные: сколько часов оно было в работе, какой объем продукта получили на выходе, что с процентом брака. Если обрабатывать всю информацию «по старинке» вручную и заносить в бумажный журнал, можно сойти с ума.


Станки с ЧПУ объединялись в сети и передавали информацию на центральный компьютер ещё лет 30 назад — в СССР. Сам видел такое на производстве.
Да, сейчас электроника на порядки дешевле и «умнее». Но зачем подавать идею автоматического сбора данных, как какое-то ноухау?

Почему бы не вспомнить о временах, когда пахали на лошадях? )
0
Умные заводы уже давно существуют — днем работают с фильтрами для виду, на ночь фильтры снимают…
Только полноправные пользователи могут оставлять комментарии., пожалуйста.