Pull to refresh

Comments 30

Отличная работа. Главное, про резервное копирование не забывайте, а то, когда навернётся база состояния сегментов, может получиться нехорошо.

ежедневно распечатывать результаты

раз в месяц подшивать

раз в квартал - сверка

раз в год - перепроверка

электронный документооборот - это дело такое XD

Прям хотел то же самое написать, а меня уже опередили) А то я читал статью и мне прям страшно было, что вот вдруг там нет бэкапов и все навернется

Да ладно, это же не ванильный финтех... Предположу, что и бэкапы есть, и внутренняя сеть предприятия с air gap от Интернет. ;)

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

Хорошая работа. Наглядно даже для тех, кто ничего не понимает )

Пара вопросов / комментариев:

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 часов. Да, пока всё ещё используется тестовый эмулятор слитка.

Очень рад за подобный сдвиг в умах людей)

UFO just landed and posted this here

Спасибо за статью. Всегда интересно читать подобное

Немного удивительно, неужели такого софта не было на рынке (не прилагался с самими МНЛЗ-УНРСами?), они же немецкие, и софт там вроде был и должен вот такие вещи покрывать?

Очень много чего есть в производстве, что могло бы покрываться софтом. Но! Все заводы разные. Иногда - сильно разные. Даже в рамках одного завода на разных домнах могут быть разные технологические процессы, их иногда можно "загнать" в единый интерфейс, иногда - нет. Поэтому огромное количество технологических процессов остается за рамками цифровизации. MESы и подобные системы внедряются там, где они действительно нужны и их внедрение "созрело". Очень отрадно, что в НЛМК производственники пошли в ИТ. ИТ может много сделать, но когда ИТ пытается играть лидирующую роль в автоматизации - это скорее приводит к автоматизации фронт-офиса (SAP, HRM, документооборот и т.п.). Еще один момент, что на автоматизацию производства больше нацелены не ИТ, а служба АСУТП. ИТ зачастую "шарахается" от производства, особенно от производства с непрерывным циклом, т.к. это особая ответственность и малейшая ошибка может привести к "снятию головы" CIO. Учитывая, что редко когда CIO промышленного предприятия "вырос" на этом предприятии, а до "промки" мог работать в ритейле))) , современные руководители ИТ стараются дистанцироваться от автоматизации производства, скидывая эту почетную роль на АСУТП, а у тех, обычно, ресурсов мало, а программистов и постановщиков задач еще меньше.

Sign up to leave a comment.