Комментарии 34
Статья о реализации AR монитора доступна по ссылке.
плюсик за труды.
добавлю, что прозрачные таблички с цифрами я бы сделал не прозрачными.
Добротное описание. Сейчас для заводов DATA-ориентированный подход к управлению техпроцессами становится нормой. Повсеместно трубят о Индустрии 4.0, на предприятиях появляются сети датчиков промышленного интернета вещей, IoT-платформы с их яркими и информативными дашбордами. Контроль уставок у измеряемых параметров в тысячах точках контроля. Вобщем, предположу, что эта статья сработает как отличное приложение к Вашему резюме. Инженера с описанной в статье экспертизой промпредприятия явно заметят.
Спасибо за позитивный комментарий! Хочу немного пожаловаться: к сожалению, изначально руководство не видело перспектив в подобной системе, и она была реализована скорее не благодаря, а вопреки.
Это встречается к сожалению довольно таки часто, внезависимости от фирмы и направления. Часто от простого непонимания, отсутствия желания, он не может знать больше меня и так далее. Часто вы просто быстрее своего времени .
Как я заметил по себе, мы делаем это из за внутреннего удовольствия в новом, эти идеи, которые в тебе сидят и просятся внаружу и да, подобная работа грозит выгоранием, это темная сторона креатива ;(
Вы молодец, продолжайте дальше и желаю вам найти больше понимающего руководства.
Руководство крупных предприятий не то чтобы против модернизации, но чаще выходит так, что инновации ломают налаженные процессы и привычки (тоже важный фактор), что на короткой дистанции приводит к убыткам, а это приводит к сокращению финансирования. Поэтому придерживается принципа "работает - не трогай".
Хотелось бы увидеть итог деятельности в виде - меня заметили владельцы предприятия и сделали директором завода, но нет. Недавно был на современном цементном заводе, спросил - чьё ПО, оказалось Сименс. А тут всё самостоятельно сделано, здорово.
Как правило, своих специалистов часто обесценивают. За "забором" специалисты качественнее и умнее. Я предлагал создать своё локальное подразделение для разработки ПО, но моё предложение не восприняли всерьез. Хотя на том же предприятии, будучи в статусе ведущего инженера АСУ ТП, я разработал информационную систему в сфере ОТ и ТБ.
Отчасти это оправданно стоимостью сопровождения и поддержки. Со сторонней компанией можно заключить юридически понятный контракт на сопровождение, со своим отделом - ну вот увольняетесь Вы, как главный разработчик, и кто будет поддерживать эту систему? Ведь наверняка ни проектной документации, ни даже комментариев в коде особо нет. Стоимость владения получается непомерной - особенно с учётом зарплат отделу разработчиков.
Отчасти не соглашусь. По своему опыту могу сказать, что да, компания платит большие деньги за разработку и реализацию проекта, который в большинстве случаев будет иметь "детские болезни" потому что исполнитель мало знает о специфике производственных процессов. А после реализации проекта, поддержка проекта со стороны исполнителя практически равна нулю или не эффективна. В конечном итоге мы самостоятельно устраняем все недочеты. Я всё же убежден, что собственный отдел разработки будет более эффективен и менее затратен по финансам.
Недавно был на современном цементном заводе, спросил - чьё ПО, оказалось Сименс. А тут всё самостоятельно сделано, здорово.
Хорошо, да не хорошо.. Нехорошо тем, что изначально стоит довольно странная SCADA per rectum ad astra, и именно это подтолкнуло автора на постройку велосипедного завода. Чего только стоит то, что при рестарте приложения теряются логи. При таком хранении они, вообще, никакого смысла не имеют. Упомянутый вами Сименс умеет нормальную работу с логами "из коробки", а для аналитики есть MES.
Плохо тем, что для сопровождения описанной системы вместе с ней надо продавать автора.
Плохо тем, что труды автора никак не оценили. Я имею в виду то, что руководство обращается с просьбой запилить фичу в системе, которую автор сделал в своё личное время, но не выделяет ресурсов заниматься этим в рабочее время. В моём понимании (а я достаточно поработал с подобными объектами) это нормально, если такой проект начинается, как личная инициатива. Если он показал себя и понравился руководству, но, продолжается, как личная инициатива - это неправильно. На этом этапе, проект должен из небольшого DIY таки перейти на промышленные рельсы. Если имеющаяся SCADA совершенно не справляется даже с базовым функционалом этого класса продуктов - значит, встаёт вопрос об переделке проекта или замене системы целиком. Да, для этого необходима некоторая бюрократия - например, служебные записки о том, что логи не сохраняются.
Хорошо тем, что автор создал серьёзный продукт, который приносит реальную пользу, и получил колоссальный опыт. С таких вещей начинаются стартапы. Я так понимаю, что завод получил оный продукт, практически, в подарок, и права на интеллектуальную собственность не имеет - то есть, автор волен распоряжаться наработками по своему усмотрению.
Обычно, если продукт создан сотрудником в рабочее время, предприятие, если там есть понимание и юристы, оставляет права за собой.
Как я уже писал в статье, данный "продукт" является модифицированной версией моего pet-проекта, который разрабатывался задолго до трудоустройства в компанию. Компания это прекрасно понимает и осознает, что никаких прав на данное ПО она не имеет.
Мной был разработан второй проект, который компания заказала уже на коммерческой основе, там, да, разработанное ПО полностью принадлежит компании.
Все, что создано в рабочее время, принадлежит работодателю. Даже если это pet-проекты, не имеющие отношения к работодателю.
Скроллинг названия в AR выглядит не очень, если хочешь быстро посмотреть что там за параметр. Проще разбить название на две строки
Приветствую.
Когда начал читать, думал написать коммент: есть же такая вещь как [iba](https://www.iba-ag.com/ru/ibapda) и подобные, в месяц бы уложились макс до просмотра графиков сигналов с контроллеров, а не со скады.
Потом понял, что вы пошли дальше и запилили свой интр-с.. В плане саморазвития - хорошо, но ошибка в том, что ушло 6 лет. Столько лет назад, проще было бы вам свичнуться в прогеры, чем сейчас.
PHP еще выбрали, по моему, зря, надо было C# брать или Python, (Go на тот момент, наверно, не был так на слуху, а то бы и его как вариант).
А так совет для всех, кто автоматизирует на производстве не благодаря, а вопреки, и в свое собст время - валите оттуда, никто вас не оценит, и не заметит даже (руководителей ваших могут заметить, которые покажут вашу разработку наверху, если дойдет до такого).
Трудно с вами не согласиться. На тот момент, предприятие было на этапе перехода к новому собственнику, и тогда у меня сложилось ложное впечатление, что всё может измениться в лучшую сторону.
Сейчас у меня более опытный взгляд на построение подобных систем и многое я бы сделал иначе, и выбор языка программирования не особо имеет значение.
А так совет для всех, кто автоматизирует на производстве не благодаря, а вопреки, и в свое собст время - валите оттуда, никто вас не оценит, и не заметит даже
Заметят, оценят на уровне погладить по головке. Но, чтобы это хоть как-то продвинуть - надо не лениться заниматься бюрократией. Другой способ - начать, подсадить предприятие на систему, открыть свою контору и продолжать поддерживать и развивать систему на контракте :)
Рекомендация же валить - совершенно правильная.
А какую пользу-то принесла эта автоматизация, в конечном итоге? Раньше же всё и без неё работало много лет, если армы даже к сети не были подключены и сбрасывали логи при перезагрузке. Значит никому эти данные и не были особо нужны.
А сейчас? Стало меньше простоев? Ремонты стали проводиться быстрее? Ремонтники стали работать эффективнее?
А какую пользу-то принесла эта автоматизация, в конечном итоге? Раньше же всё и без неё работало много лет, если армы даже к сети не были подключены и сбрасывали логи при перезагрузке. Значит никому эти данные и не были особо нужны.
Это можно сравнить с бухгалтерией. Если не смотреть, откуда и куда деньги приходят и уходят - жить можно. Если понимать, что приносит денег больше, что меньше, а на что можно тратить поменьше - совсем другая жизнь.
Что касается объекта Гидрофол, там был установлен регистратор данных, который собирал измерения со всех необходимых датчиков. Регистратор умеет отдавать данные по протоколу Modbus TCP/IP, чем мы непременно воспользуемся, а в качестве устройства, которое будет передавать данные на сервер, был выбран дешевый промышленный контроллер от компании SIEMENS Simatic S7-1200, CPU 1214C. Данный контроллер будет опрашивать регистратор и отправлять полученные данные на сервер сбора данных. Ниже фото тыловой (интерфейсной) части регистратора.
Я уже понял, что основная скада работала per rectum, но это не повод изолировать от неё данные. Если у вас уже есть линия связи на удалённом объекте, подключаете дополнительные переменные к имеющейся скаде по модбасу, а уже из неё забираете данные тем же методом, что и все остальные. Контроллер тут лишний.
Это я понимаю, но на Гидрофоле вообще нет никакой SCADA системы и автоматизации. Установка контроллера преследовала двойную цель: сбор данных и возможность в перспективе его интеграции в процесс управления объектом. Тратить целый контроллер только на передачу данных - это нерационально. И при использовании SCADA, есть такая неприятная штука, как лицензионное ограничение количества используемых тегов (источники, каналы и т.п.).
Если добавить в цепочку передачи данных SCADA систему, то это добавит дополнительный узел, который может стать потенциальной проблемой, что привет к снижению надежности. Да и опростить с сервера удаленный узел по Modbus TCP не составляет проблем.
Это я понимаю, но на Гидрофоле вообще нет никакой SCADA системы и автоматизации.
У меня, в отличие от вас, нет в голове общей картины производства :)
Если это совершенно другой участок производства со своей системой автоматики - то понятно.
Тратить целый контроллер только на передачу данных - это нерационально.
Совершенно верно. Но, из вашего поста я понял так, что это и есть основной смысл установки контроллера потому, что вы не упомянули об этом:
Установка контроллера преследовала двойную цель: сбор данных и возможность в перспективе его интеграции в процесс управления объектом.
В любом случае, получается, что контроллер установили "на вырост" - для сбора данных можно прекрасно обойтись без него.
И при использовании SCADA, есть такая неприятная штука, как лицензионное ограничение количества используемых тегов (источники, каналы и т.п.).
Понятно. У вас не было запаса по тегам. Опять же - бюрократия, служебные записки, заказ ;)
Если добавить в цепочку передачи данных SCADA систему, то это добавит дополнительный узел, который может стать потенциальной проблемой, что привет к снижению надежности.
Проблема надёжности - это скада, которая там используется :)))
Да и опростить с сервера удаленный узел по Modbus TCP не составляет проблем.
Это совершенно не проблема. Просто, у меня в голове после вашего поста сложилась картина, что объект "Гидрофол" - это составная часть установки, которой управляет проект в АдАстра. Если это так, то было бы логично, если б данные с этого объекта заходили в скаду. Опять же, у меня сложилось впечатление, что вы построили нечто, частично реализующее функциональность MES-систем. При этом, некоторые данные вы завели напрямую в вашу систему в обход скады. Работает - и хорошо, все довольны. Но, с точки зрения архитектуры АСУ ТП - это дикое спагетти, как и многое другое в вашем посте :)))
AR классный. Но уж очень мерцает. Попробуй не перерисовывать цифры поверх, если они не менялись.
Круто, классно, молодец!)))
Но есть несколько вопросов.
Почему не использовали временную базу данных? Influxdb например? Она с коробки может читать напрямую из Сименса, опрашивать по modbus и т.п. Так же можно для сбора данных использовать node-red, да и визуализацию можно сделать там же.
Очень много туда на визуализацию данных. Есть много готовых продуктов,: grafana, Apache superset.
Зачем для сбора modbus использовать контроллер? Есть адаптеры ethernet что могут работать в режиме виртуального com порта.
P.S. так же вашу систему никто кроме Вас не может ни развивать, ни поддерживать, для собственника это не очень хорошо.
С уважением, Ваш коллега по АСУ ТП)
Почему не использовали временную базу данных? Influxdb например? Она с коробки может читать напрямую из Сименса, опрашивать по modbus и т.п. Так же можно для сбора данных использовать node-red, да и визуализацию можно сделать там же.
Начало реализации системы было в начале 2017 года. К тому моменту я не знал о существовании InfluxDB, да и в нашей АСУ ТП на тот момент не использовались решения от SIEMENS. Касательно Node-RED: да, это классное решение для эксплуатации системы людьми, далекими от написания кода, но мне проще и быстрее было написать код модуля, чем дополнительно интегрировать данный инструмент в систему. На тот момент систему планировалось использовать как локальный диагностический инструмент, и о каком-либо масштабном использовании речи не шло.
Очень много туда на визуализацию данных. Есть много готовых продуктов,: grafana, Apache superset.
Я не любитель сторонних зависимостей в своих проектах, несмотря на то что они упрощают разработку и сокращают время на её реализацию.
Зачем для сбора modbus использовать контроллер? Есть адаптеры ethernet что могут работать в режиме виртуального com порта.
Я уже отвечал: https://habr.com/ru/companies/timeweb/articles/844552/comments/#comment_27413094
если коротко, то контроллер устанавливался на перспективу.
P.S. так же вашу систему никто кроме Вас не может ни развивать, ни поддерживать, для собственника это не очень хорошо.
Если под "собственником" вы имеете в виду компанию, то компания не ставила целей для разработки данной системы, все реализовано на голой инициативе. У меня сложилось устойчивое ощущение, судя по действиям "ближайшего" руководства, что у собственников была одна политика: "Крутитесь как хотите, только не морочьте нам голову своими проблемами". И как я уже говорил ранее, система была создана исключительно на энтузиазме, без каких-либо надежд на интеграцию в бизнес-процессы.
Круто, классно, молодец!)))
С уважением, Ваш коллега по АСУ ТП)
Спасибо большое за оценку, и я очень рад, что моё "творчество" читают коллеги).
автор, Вы проделали огромную работу, набрались опыта. Вопрос только в том, что любая самоделка или самописное - это мина замедленного действия. Я через это проходил, работал я как-то на предприятии, на котором в одном из дивизионов не было покупной SCADA-системы, была самописная. И это было адски сложно в эксплуатации, система работала хорошо пока сам ее автор был в составе дивизиона. В своем развитии она сильно отставала от любых готовых продуктов, так как ее поддерживал 1 (один) человек. Нельзя было просто купить "умную железку" (похожую, например, на ВИЭР-104К) и подключить в промышленную сеть, закинуть нужные модули в скаду. трейс моуд поддерживает виэры. Сейчас по работе наибольшие проблемы доставляет 3 самодельных платы, установленная недобросовестным поставщиком.
и это проблема любого самописного софта. серьезную систему разрабатывает коллектив, который постоянно мониторит все изменения автоматизации. а самоделка - это всегда нехватка времени и ресурсов. Забегая вперед - "а что делать, если руководству на все плевать?". забить или искать другую работу. "Не стоит быть большим роялистом, чем сам король".
в тех сообществах профессионалов, где я вращаюсь, считается, что все должно быть заводского изготовления или готовым изделием, которое настраивается под конкретную задачу.
PS: пишу это с уважением, без желания обидеть или оскорбить. Вы реально мозговитый товарищ, раз поразбирались во всех этих тонкостях.
Статья о реализации AR монитора доступна по ссылке.
Как я делал систему сбора данных на провинциальном заводе и что из этого вышло