Comments 16
А в чем проблема использовать конвейерные весы? Зачем делать такой сложный механизм анализа? В производстве, если вы делаете высокую точность, 1 минута - это очень много. PID регуляторы отрабатывают порой миллисекунды и крутятся на ПЛК. Да, возможно я не понял суть задачи и мы делали что-то похожее, но так или иначе потом переносили софтовые решения на железо. Иметь кусок программы (для управления, а не для статистики и анализа) в производственном цикле - это огромный риск. Но, если описанный технологический процесс не имел вообще никакой автоматизации, то да, временно, таким сложным, софтовым решением можно закрыть эту "дыру".
Я просто не понимаю, как микросервисы, web и Pyton ассоциируются с надёжностью, доступностью, отказоустойчивостью на уровне промышленной автоматизации? А уж тем более файлы на сетевом диске!
Про конвейерные весы я тоже подумал. Часть автоматизации описана очень плохо. Типовых схем нет. Я также не понял, что за датчик подаваемого воздуха и почему 3-4 секунды занимает процесс измерения. В хорошем КИПиА за это отвечает расходомер и измеряет он намного быстрее, чем 3-4 секунды. КИПиА часть и АСУТП часть очень мало раскрыты, а то, что есть вызывает много вопросов.
Мы описали пилотный проект: на этом этапе ключевой задачей было подтвердить работу архитектуры и замкнутого контура управления. Датчик воздуха измеряет поток в реальном времени, а 3–4 секунды — это периодичность передачи данных в систему мониторинга, что было достаточно для целей тестирования и отработки гипотез.
Я - инженер КИПиА и я не знаю никаких "датчиков воздуха". У газа есть давление, температура, расход как минимум. Есть процентное содержание различных газов. Просто датчик воздуха не существует.
Кстати, металлургические процессы и сами хорошо описаны в литературе и их автоматизация хорошо раскрыта. Причем эти книги даже есть в пиратском доступе. Какие гипотезы Вы хотели отработать, если то, что есть в литературе на голову выше?
Плотный проект - это круто! И это несомненно будет работать, но не долго. Через небольшое время, камера покроется слоем пыли, а сетевой диск отвалится и оператор не нажмет кнопку. И так далее. В вашей модели в основе - "костыли", которые "подпирают" процесс, но не автоматизируют. Автоматизация предполагает унификацию, сокращение участков обработки информации, упрощение, отказ от промежуточных блоков обработки, что ведёт к надёжности и возможности запустить линейные и цикличные процессы в автоматическом или автоматизированном режиме (надеюсь понимаете в чем разница) и уже потом отказ от оператора или максимальное снижение зависимости от действий оператора. Не просто так учат в университетах отдельно на промышленную автоматизацию и там нет Pyton, потому что он там не нужен (медленно и не надёжно, требует больших ресурсов для вычисления, что недопустимо для процессов). То, что вы сделали подходит для проведения исследований и переноса этого алгоритма на автоматизацию через ПЛК.
В данном случае на производстве уже была сформированная концепция проекта с жёсткими бюджетными ограничениями. Интеграция промышленных весов в существующее оборудование была технически невозможна. В статье мы как раз показали, как с помощью подручных средств — можно автоматизировать процесс без вмешательства в основную инфраструктуру.
Вы полезли на минное поле. Я не смогу Вам объяснить и не словить минус. Удачи!
Update: если тщательный анализ ТЗ говорит, что заказчик хочет Боинг последней модели по цене жигулей, или на хорошее решение там не заложены деньги, то безопаснее и выгоднее в это не лезть.
Ребята, ну какие жы вы тогда автоматизаторы, если не можете интегрировать весы? Вот тут у меня ещё больше вопросов, причём к вашей компетенции и профессионализму. Вы сейчас пишете настолько не корректные вещи, но при этом стремитесь сказать, что не вмешиваетесь в основную инфраструктуру. А в чем тогда смысл вашей доработки - аналитика или все же автоматизация?
А что касается использования подручных средств, то и из веток можно "шалаш" собрать, но будет ли являться это промышленным объектом, вот в чем вопрос. Если бы вы написали, что сделали дополнение к существующий автоматизации, которое позволяет повысить производительность, снизить затраты и так далее, это было бы корректно, ну так вы гордо с максимализмом заявили: "Промышленная автоматизация металлургического производства. Архитектурные решения и техническая реализация" - теперь вам и пишут "коллеги", хотя я не уверен, что вы именно автоматизацией занимаетесь, что то, что вы сделали - не тянет на автоматизацию и даже к "заплатке" мало относится. Ну так вы себя дальше "закапываете", заявляя что не можете интегрировать весы и говорите про какой-то эфимерный датчик воздуха.
Вы вообще понимаете, что такое архитектура автоматизации, что лежит в её основе и как технически это все реализуется?
Ребята показали просто несколько иной подход к асу тп. Обычно приходит сразу на ум когда слышу асу тп это плк и scada и надежность. Был ли подход ребят оправдан покажет время. Пока , как кажется , выбор странноват, но возможно вопрос цены решающий был. Вместо дорогого пром оборудования использовать опенсорс решения
Мне нравится открытость Вашего ума, желание понять логику и мотивы.
Моё же мнение следующее. если это опасное или вредное производство (из текста это не понятно, но по смыслу должно быть хотя бы вредным), то у регуляторов могут быть какие-то свои требования (в Казахстане есть). И при наличии этих требований часто реализовать по-другому, кроме как ПЛК, SCADA, ПАЗ попросту нельзя. Большинство металлургических производств как минимум вредные. Если это вредное производство, + если у РФ есть к таким производствам требования то, вероятно, эта "автоматизация" не проходит по требованиям.
Необходимость в "другом" подходе в статье никак не обоснована, хотя бы элементарными прикидками по надёжности и быстродействию.
Как мне показалось, судя по другим статьям автора. Ребята делали решение на стеке, с которым имеют опыт. Пример оверинженеринга. Надежность и оправданность такого решения видится довольно сомнительной. Особенно если система не просто мониторинг, но и управление (подача воздуха) в один момент цена ошибочного решения может стать сильно высокой. Как-то возникала задача контроля геометрии изделия выходящего с прокатного стана (оценка износа роликов) ее предлагали решить с помощью пром камер. Я предлагал с помощью микрофонов и датчиков вибрации оценки звука.
А где заявленная в заголовке автоматизация производства? Вижу только один процесс и то - то что с ним сделали сложно назвать автоматизацией.
Согласен с сообщениями выше. Если смотреть на текст, то получилось типа мы на Феррари поехали за картошкой.
Конвейерные весы+ расходомер должны были решить проблему многократно дешевле и сильно точнее и надёжнее.
Может, действительно, все сложнее. Но я говорю только на основе прочитанного.
У статьи есть ряд серьёзных проблем. Мы мало что знаем о самом процессе. Я понимаю, что раскрытие информации может быть запрещено заказчиком. Однако никто не может запретить дать хотя бы какую-то обобщенную информацию, не позволяющую идентифицировать заказчика. Хотя бы какой-то минимум, это пирометаллургия или гидрометаллургия. (дальше понятно, что это пирометаллургия, но это должно быть написано). Во введении нет части КИПиА, нет ничего про базы данных, например.
мало что рассказано о "старых средствах" КИПиА и АСУТП. даже хотя бы в общем (я помню про возможный NDA).
мало что знаем про ТЗ. Возможно, ТЗ дурканутое (типа засекать время в курилке, если люди сидят больше 10 минут включить распылители воды).
АСУ ТП должны работать в реальном времени. Тема никак не раскрыта.
"Python" - это не про надёжность, у него точно другая сфера применения, где ему почти нет конкурентов.
Интеграция с XRF-анализатором: Параллельно с видеоаналитикой система интегрируется с XRF-анализатором через консольное Windows-приложение. По нажатию клавиши "пробел" через заданное время например (10 секунд) делается скриншот экрана анализатора. OpenCV извлекает цифровые значения из изображения, после чего данные упаковываются в CSV-файлы и сохраняются в сетевую папку.
Я не знаю как это комментировать... Читать из скриншота...
Автоматический мониторинг файлов: Отдельный модуль раз в минуту проверяет сетевую папку на появление новых CSV-файлов с данными анализа. При обнаружении новых файлов система автоматически их парсит и загружает данные на платформу для дальнейшей обработки.
в серьезной автоматизации так не делается. одно в другое пишет напрямую обычно.
Для того чтобы платформа могла определить, на каком оборудовании какой процесс происходит, ей необходимы два типа данных:
обычно это делается по-другому, состояние кнопок, переключателей, и/или контакторов через ПЛК.
Дополнительно система выполняет мониторинг процессов: например, если масса сырья выше нормы, она может подать команду на увеличение подачи воздуха в печь, чтобы обеспечить нужный температурный режим и поддержать стабильность плавления.
мне правда хотелось бы, чтобы автор(ы) лучше понимали физику и химию процесса, потому что плавление и подача воздуха взаимоисключают друг друга.
автоматически включает сигнальную лампочку. Оператор, видя сигнал, останавливает конвейер
это не автоматизация. так не должно быть, всё должно быть на автомате.
также ничего не сказано про матмоделирование, оно обычно нужно для металлургических процессов.
Из статьи и ответных комментариев делаю вывод: молодые ребята, программисты (с современным складом ума и опытом в прикладном программировании и это видно из профиля и предыдущих статей автора) , решили, что автоматизация = простое программирование и не более, решили сделать за небольшие деньги автоматизацию металлургического производства (ну это они так решили, что будут именно автоматизацию делать, а не маленький узел аналитики), используя свой небольшой опыт, не понимая суть, смысл и логику промышленной автоматизации, сделали по своему, как умели.
Да, что-то получилось и стало работать, не смотря на множество костылей и подпорок и ребята решили заявить о себе через Хабр, думая что вся автоматизация так работает и им скажут что они большие молодцы, но ребята не могли подумать, что автоматизация работает по другому и множество людей, которые годами с этим работают и знают это всё изнутри, будут не согласны с таким заявлением и прямым текстом скажут ребятам, что они в корне не правы и все, что они сделали и гордо называют автоматизацией, не является таковым. Но ребята решили доказать, что они правы и ввиду своей некомпетентности в вопросах автоматизации просто потопили себя ещё глубже...
Итог всей басни: ребята, учитесь и называйте вещи своими именами, если вам указывают на некорректность ваших заявлений, не спешите доказать что вы умнее, сначала потрудитесь выяснить, почему вам на это указали и только потом делайте выводы и пишите ответные комментарии. В мире немало умных людей, а уж на Хабре их предостаточно и здесь "раскатают" таких экспертов, как вы.
В целом, все неплохо, идеи хорошие, а реализацию до ума можно довести и вы сможете делать аналитику сложных промышленных процессов, главное вникайте в их суть. Для вас это новая сфера и отрасль и там не работают банальные принципы программирования и логика сильно другая. Там нет FrontEnd и BackEnd, там базы данных только на уровне MES систем и устроены они не по классической схеме. И так далее, это совсем другая среда. Простой прикладной программист не зайдёт сюда "с ноги" и не скажет, какой он крутой. Просто не сможет
Промышленная автоматизация металлургического производства. Архитектурные решения и техническая реализация