Комментарии 30
Отличная работа. Главное, про резервное копирование не забывайте, а то, когда навернётся база состояния сегментов, может получиться нехорошо.
Ничто так не облегчает работу, как одновременная заинтересованность конечного пользователя и руководства. Это большая редкость, рад за вас.
Хорошая работа. Наглядно даже для тех, кто ничего не понимает )
Пара вопросов / комментариев:
1. Пользуются ли визуализацией 3D? Кажется, что это избыточно
2. Почему у вас даты в формате YYYY-MM-DD?
3. Нужны ли секунды? Если их убрать, то станет заметно чище
1. 3D моделью пользуются, она необходима для наглядности и отсутствия путаницы, поскольку форсунки валков находятся как снизу, так и сверху. Расположение их только на верхней поверхности 2D усложнило бы интерпретацию.
2. Формат используется в соответствии с международным стандартом формата даты.
3. Секунды действительно не нужны. Оставили для сохранения полноты формата даты-времени, но согласен, что можно и убрать.
Почему у вас даты в формате YYYY-MM-DD?Потому что такой формат лексикографически сортируем.
" То есть, повторюсь, ничего из серии rocket science! Главное требование — чтобы все всегда знали, что происходит, был идеальный порядок и не случались сюрпризы. "
На самом деле это не так. точнее в текущих условиях весь персонал помнит ручную ведомость, и понимает как влияют введённые цифры на конечный расчёт, а некоторые могут на глаз прикинуть верность алгоритмов (в классификации "похоже на правду"). Но всё поменяется через 3-5 лет. спецы уйдут на пенсию/повышение, немного может поменяться технологическая часть установки. Как следствие вся программа превратится в "чёрный ящик", где на входе цифры измерений параметров, а на выходе рекомендации (отчёты). и почти никто не сможет проверить цифру "при помощи калькулятора" (повторить расчёт вручную). и всё, если нет подробного постоянно обновляемого файла документации для актуализации алгоритмов расчётов и изменения форм отчётов(в том числе выгрузки в xml), то жизненный цикл ПО завершится. Одна радость, все будут хотеть от новых программ ваш графический интерфейс. Так что не забрасывайте поддержку и документацию. а если это есть то легко получить патент на ПО (будет что в туалете повесить).
Работая на предприятии, я сталкивался с аналогичными решениями (в сфере ЖКХ), которые отмирали как уходил ведущий специалист или как пропадала фирма разработчик ПО. Потому святое правило, документация и это должно работать вне чужого облака (только на серверах предприятия) уже вошло в привычку. при необходимости писались модули отчётов и внешнего взаимодействия для выгрузки данных или обмене ими.
Спасибо за комментарий. Уловил в нём беспокойство по поводу того, что это коробочное немасштабируемое решение. Но это не так.
Этот продукт — не коробочное решение. У него открытый исходный код и разрабатывался внутри, собственной командой. Сервис крутится на наших серверах. Год назад продукт закрепили за мной. Разобраться не составило большего труда, после чего я добавлял и изменял функционал. Чёрным ящиком продукт стать по определению не может. А новому разработчику поможет разобраться с продуктом документация, в которой описана вся необходимая информация по сервису, начиная от логики работы и заканчивая топиками кафки.
Индастриал, отлично! Автор - большой молодец, пишите еще!
Это же просто электронный журнал учета, так?
В основе системы — да, электронный учёт статусов сегментов. Но мы дополнили это визуализацией, чтобы было наглядно понятно, где и что. Плюс GUI для изменения состояния сегмента, причём этот GUI во многом меняли сами сотрудники цеха так, как им было удобно. В итоге у нас есть и учёт, и удобные для сотрудников интерфейсы изменения состояния, инвентаризации, снятия статусов и аналитики сегментов.
это в первую очередь база данных для многофакторного анализа, определения корреляции данных изменений, а не просто "журнал в эксель". С этими данными потом возможно строить прогнозы, а так же удобная вещь для практикантов (а определи ка зависимость вот этих параметров и есть ли она для других... и визуализируй процесс в виде графика). Человек (практикант) занят и полезность ощущает, и, возможно, его труд пригодится.
Всяким "менеджерам" с "крутым ПО", которое они впаривают для повышения производительности, можно показать и дать исходные данные для сравнения, что бы отцепились.
Работа очень крутая, особенно радует смычка IT и производства.
Как человек 20 лет отработавший на пищевом, и в том числе 15 лет с SAP, продумайте резерв из бумажных носителей, на случай если все упадет, и проводите раз в год тренировки на полный останов электронной системы учета.
Круто. Решил перечитать статью второй раз, но под песню Арии "Здесь куют металл" :)
Вот такие визуализации и помогают адекватно работать с производством. Сразу видно: протечка стали убила целый ряд нижних форсунок по направлению движения, а верхние форсунки забиваются равномерно и чаще, потому что в них прилетает пар с частицами ржавчины. И технологу сразу будет понятно, что в следующей МНЛЗ лучше использовать не водовоздушное охлаждение, а водоструйное под углом.
Спасибо за публикацию, пожалуйста пишите еще, действительно интересно и полезно. Даже для человека из другой сферы
А на чем написано? Какой стек?
Бек написан на django + DRF
Консьюмеры написаны с использованием библиотеки aiohttp
Фронт react+redux
Шина данных kafka
Бд postgres
Разрешите позадавать глупые вопросы,
- кто такие консьюмеры, на чем они запущены, как связаны с железом
- какую роль играет шина данных - от кого к кому данные по ней передаются
- кто рисует 3д, как хранится и обновляется 3д объект
- каким образом собираются данные с форсунок после запуска? насколько я понял первые данные собирали с помощью тестового эмулятора слитка - он же и используется на текущий момент?
p.s. статья отличная, роль бизнес аналитика команда отработала на 5+ ( участие пользователей помогло)
1. Консьюмеры — сервисы, которые забирают данные с распределённых систем обмена сообщениями. Для этой задачи консьюмер написан на Python. С железом связана оперативно-диспетчерская система, данные с которой отправляются в Кafka. 2. Шина данных — распределённая система обмена сообщениями. Такие системы используются для снижения нагрузки на сетевое взаимодействие между сервисами для получения/записи данных. Данные передаются между сервисами, отталкиваясь от бизнес-логики.
3. Все 3D-объекты рисуются средствами библиотеки Three.js из простейших геометрических элементов и хранятся в типизированном буфере. Объект обновляется при изменении изначального состояния.
4. Данные с форсунок вносятся вручную во время проведения плановой переподготовки каждые 8 часов. Да, пока всё ещё используется тестовый эмулятор слитка.
Очень рад за подобный сдвиг в умах людей)
Спасибо за статью. Всегда интересно читать подобное
Немного удивительно, неужели такого софта не было на рынке (не прилагался с самими МНЛЗ-УНРСами?), они же немецкие, и софт там вроде был и должен вот такие вещи покрывать?
Очень много чего есть в производстве, что могло бы покрываться софтом. Но! Все заводы разные. Иногда - сильно разные. Даже в рамках одного завода на разных домнах могут быть разные технологические процессы, их иногда можно "загнать" в единый интерфейс, иногда - нет. Поэтому огромное количество технологических процессов остается за рамками цифровизации. MESы и подобные системы внедряются там, где они действительно нужны и их внедрение "созрело". Очень отрадно, что в НЛМК производственники пошли в ИТ. ИТ может много сделать, но когда ИТ пытается играть лидирующую роль в автоматизации - это скорее приводит к автоматизации фронт-офиса (SAP, HRM, документооборот и т.п.). Еще один момент, что на автоматизацию производства больше нацелены не ИТ, а служба АСУТП. ИТ зачастую "шарахается" от производства, особенно от производства с непрерывным циклом, т.к. это особая ответственность и малейшая ошибка может привести к "снятию головы" CIO. Учитывая, что редко когда CIO промышленного предприятия "вырос" на этом предприятии, а до "промки" мог работать в ритейле))) , современные руководители ИТ стараются дистанцироваться от автоматизации производства, скидывая эту почетную роль на АСУТП, а у тех, обычно, ресурсов мало, а программистов и постановщиков задач еще меньше.
Всё меняется, когда твой софт повышает безопасность производства