Разработка конструктора для конфигурирования производственных этикеток в системе второго уровня TWS ТПЦ

В статье представлен опыт создания специализированного редактора этикеток для технологического персонала Трубопрокатного цеха (ТПЦ), направленного на устранение ограничений стандартного решения Danieli. Ранее процесс создания шаблонов для различных ГОСТов требовал ручного проектирования уникальных макетов, что снижало гибкость и увеличивало трудозатраты. Разработанный конфигуратор позволяет динамически формировать этикетки на основе универсального ZPL-шаблона, интегрирует параметры ГОСТ, а также обеспечивает централизованное хранение и доступ к шаблонам через систему TWS. Реализация включает визуальный интерфейс для операторов, логику динамической подстановки данных (вес, длина, сорт и др.) и поддержку нормативных стандартов.

https://habr.com/ru/articles/889378/

Что рассказали технологи про интерфейсы на производстве

Технологи — особенные пользователи. У них огромная ответственность, руки в перчатках, на лице — защитные очки. В цехе полутемно или светится раскалённый металл, а им нужно отследить сотни параметров техпроцесса. И им очень хочется, чтобы всё работало как часы. Правда, представления об идеальной работе у них сильно отличаются от привычного UI/UX. Некоторые мастера внезапно просили нас усложнить интерфейсы. Прямо реально усложнить: добавить меню, подменю, передвинуть кнопку, сделать крупнее. Ответ очень простой: они привыкли к старой оракловой системе с интерфейсами из кучи выпадающих меню. Некоторые по 20 лет тыкали в эти менюшки и сформировали мышечную память. Где-то людей просто бесил порядок кнопок, например: «Кнопка «Отменить» всегда была справа. Переставьте, пожалуйста!» Аналогично — с «горячими» клавишами. Если восемь лет назад мастер запомнил, что Ctrl+R означает «Контроль реза», то так и будет нажимать в новой системе, рассчитывая на знакомое поведение. Поэтому мы подняли все старые комбинации и добавили их в новый софт. Теперь работают и новые «горячие» клавиши, и привычные опытным мастерам аккорды. А тут — хороший пример ещё одного принципа. Верх страницы для технологов — визуальный мусор. На макете заголовок смотрится очень хорошо. На практике эту страницу они открывают на мониторе на стене либо каждый день видят много тысяч раз. Им важно, что находится на экране, внутри контентной области. То есть заголовок в проминтерфейсе в такой ситуации надо делать не просто маленьким, а очень маленьким, чтобы он не занимал драгоценного места. В цехах мы узнали ещё много нового про UI/UX, а заодно про себя и свою работу.

https://habr.com/ru/companies/nlmk/articles/862092/

Металлолом наносит ответный удар

Мы многого не знали про железнодорожные вагоны: Вагоны в поезде не умеют обгонять друг друга. Но обгоняют. Один из вагонов обычно не может взять и переехать на параллельный путь. Считается, что вагоны одинаковой типовой длины. Но это не гарантирует, что последний будет в одном и том же месте, если выравнивать первый. И, наконец, знакомьтесь, вагон, который приехал к нам по железной дороге: Наши коллеги из НЛМК в какой-то момент сделали анализ металлолома в вагонах. Вагон фотографируется по мере разгрузки по слоям, потом приходит модель и оценивает засорённость и качество лома. Мы съездили к ним в гости, посмотрели и решили внедрить у себя. В этот момент и проявилась разница между тем, что бывает в теории и на практике. Точнее, она проявлялась несколько раз по ходу процесса, что доставляло нам массу радости.

https://habr.com/ru/companies/omk-it/articles/874324/

ОМК — когда у нас стало за 80 тысяч лицензий на софт, учитывать в тетрадке стало сложно

База данных лицензионного ПО v.1, по ней специалист делал select count(*) from licenses where vendor = '1C' Это очередной пост про изобретение велосипеда, или как мы от учета в тетрадках и экселях пришли к нормальной базе данных. Таких примеров тысячи. Но я расскажу про достаточно интересный объект автоматизации — лицензии на ПО. Тут работа ювелирная: и сэкономить на закупке, и соблюсти лицензионную политику вендора ПО. Чтобы понять масштаб страданий, знайте, что в состав ОМК входит семь металлургических и машиностроительных предприятий, сервисная и торговая сети, более 10 000 пользователей. Мы работаем с 250 вендорами, у нас 800 наименований используемых видов ПО и сильно больше 100 000 лицензий в штуках.

https://habr.com/ru/companies/omk-it/articles/870242/

Будущее ИИ на производстве: что ещё возьмут на себя роботы?

Мы видим, как ИИ анализирует рентгеновские снимки , рисует изображения и пишет статьи. Заводы тоже не обделили вниманием , но давайте помечтаем и попробуем представить, что будет дальше: какие ещё задачи будут автоматизированы, а какие аспекты работы останутся за людьми. Всем привет! Меня зовут Житарёв Антон , и я работаю в компании, которая занимается автоматизацией тяжёлой промышленности. Мы внедряем машинное зрение, анализируем полученные данные и даём советы по устранению проблемных участков на линии. Я хотел бы, чтобы мы с вами подумали, как далеко может зайти цифровизация заводов и будет ли место нам, белковым, в этой области через 10 лет?

https://habr.com/ru/specials/868310/

Куда делось металлическое строительство в России

Строительство гостиницы « Ленинградская » Металл в строительстве — история не новая. Некоторые сталинские высотки построены из металла. Конечно, имеется в виду стальной каркас — скелет здания. Стены и перекрытия в таких домах могут быть сделаны из разных материалов: железобетона, дерева, кирпича, камня. В этом — самое главное отличие стальных зданий от железобетонных: в монолитном доме вся «коробка» может быть железобетонной. Плюсы стального каркаса — это скорость строительства, возможность создания сложной архитектуры и свободных планировок. Ещё один большой плюс стали — возможность строительства при низких температурах, что для нашей страны очень существенно. В некоторых северных регионах сезон строительства длится три–пять месяцев. Минус — это дороже. Почему так вышло, что применение стали в жилых домах не получило широкого применения? Главная причина — приоритет в потреблении металла был отдан военной и тяжёлой промышленности. Для жилья была выбрана технология панельного домостроения из железобетона — быстро и дёшево. Эта технология развивалась: пятиэтажки превратились в 9-, 12- и 17-этажки. В 1990-е годы к нам «привезли» монолитный железобетон, из которого уже 30 лет в основном строят многоэтажные жилые дома. Сегодня общая доля построек на стальном каркасе в России, по данным РБК, не выше 15 % от общего количества реализованных проектов, и практически всё это — промышленные объекты. В Норвегии она составляет 48 %, а в Швеции, Великобритании и США — 65–68 %. В жилом многоэтажном сегменте в России сегодня строится менее 1 % зданий на металлокаркасе. Сталь в Европе и США стоит дороже, чем у нас. И даже с учётом этого существенное количество жилья там строят с применением стального каркаса. А почему мы не строим? Я хочу вернуться к технологии, в которой наша страна была лидером много лет назад.

https://habr.com/ru/companies/nlmk/articles/861720/

Я угадаю, что рабочий цеха хочет ввести, с трёх букв

У нас есть система регистрации простоев оборудования. В ней рабочему нужно ввести комментарий о причине простоя вручную. А нам потом надо собирать статистику по этим данным для анализа, как работал цех и что приводило к простоям. Рабочие вводят причины простоя разными словами, от души. «Шланг порвался», «они не успевают дать продукцию», «безобразно обрезана кромка» — это ещё цветочки. Одно только слово «железнодорожный» можно написать десятками способов — жд, Жд, ЖД, ж/д, ж\д, ж /д, ж д, Ж д, ЖД!!! — и так далее. С вывернутыми слешами, двойными пробелами и другими творческими формулировками. В базе 13 миллионов записей, из них 700 тысяч уникальных, из которых остаётся примерно 500 тысяч после нормализации по регистру, слешам, пробелам и т. п. А нам нужно как-то разобраться, что не так и с кем. Если вы сейчас думаете про ML, LLM и прочие модные слова, я вас огорчу. Оказалось, что есть простой кондовый способ, если применить немного ТРИЗа. В итоге получилось, что мы умудрились и рабочим сделать намного удобнее (что вообще-то редкость в реалиях производства), и дико помочь аналитикам.

https://habr.com/ru/companies/omk-it/articles/860196/

Что вообще такое — АСУТП на заводе

Все же знают, что такое АСУТП? Обычно бывает так: все что-то слышали, но никто точно не знает, как вся эта история работает. Мы в целом тоже не до конца знаем, но можем рассказать о практике. Платы старого и нового контроллера Начнём с того, что во всём виноват пар. Первые заводы были незамысловатыми: вода или ветер вращали колёса, они передавали движение на кузнечные меха, пилу, молот, жернова или пресс для масла. Если ветра или воды не было, то часто можно было запустить тот же процесс с ослика. А вот с появлением паровых машин появились изобретатели, которые стали пытаться прикручивать какую-то базовую автоматизацию. Жидкостные компьютеры мы сейчас пропустим и сразу перейдём к электричеству. Электричество в районе 60-х дало возможность делать логические схемы: сначала — на лампах, а потом куда более массово в районе 70-х — на транзисторах. АСУТП на водонасосной станции может выглядеть как четыре поплавка, которые дают сигналы в реле. Упрощённую схему такой АСУТП вы можете наблюдать у себя в бачке унитаза, кстати. Более сложная схема подразумевает, что есть куча датчиков, они отдают свои данные в контроллер, который делает расчёты и сопоставляет разные показания, умеет что-то писать в память и читать разные рецепты, а на выходе управляет сервомоторами и другими штуками плюс сообщает данные соседним станкам. Всё, конечно, чуть сложнее, но теперь вы уже разбираетесь в АСУТП. Сейчас поговорим про такие детали, как операционные системы реального времени, которые нужны, чтобы всё это работало правильно.

https://habr.com/ru/companies/omk-it/articles/845416/

Как нарисовать завод на мнемосхеме

Для фронта MES у нас на заводе используются мнемосхемы производственных цехов. Мы очень любим их проектировать. Допустим, надо отследить позиционирование ковша. Оператор может посмотреть детали, кликнув на нужный ковш, чтобы сразу увидеть его начальное, конечное и текущее положения в производственной цепочке. Или он может быстро просмотреть весь процесс в большом цехе размером с пару стадионов, и сразу среагировать, если что-то пойдет не так. Ещё лет пять назад было бы трудно поверить, что такое возможно. У нас был Oracle, для отображения состояния оборудования и процессов применялись таблицы, графики, диаграммы, были даже текстовые описания. Это было низкоэффективно, требовало изрядно времени и усилий для обработки. Потом пришёл MES и понемногу всё закрутилось. Для MES-интерфейсов потребовался новый подход, т.к. в мире нет унифицированных решений для их разработки. Чтобы внедрить мнемосхемы на производстве, пришлось изрядно поработать. Но задача была вдохновляющая, и оно того стоило.

https://habr.com/ru/companies/nlmk/articles/838714/

#завод #интерфейсы #мнемосхемы #логистика #производство #ui/ux

Что такого сложного — отправить человека в отпуск?

У нас огромное металлургическое производство, и, поскольку ИТ в некоторых своих частях до нас дошло сильно позже банков, то разные нужные документы, например, на отпуск или командировку мы делали руками. В смысле прямо бумажные документы. С помощью синей ручки. После долгой очереди. Что самое парадоксальное, эти бумажные документы сразу сканировались и складывались в СЭД. Вот такой сервис хотелось добавить всем людям в компании. Страница на портале, промежуточный дизайн (это моего коллеги). Автоматизировать это очень хотелось, но задача оказалась трудной. Готовых решений нужной нам сложности нет. Коробок, которые можно аккуратно обработать напильником, тоже не нашлось. Процессы у нас очень хитрозапутанные, и когда мы туда полезли, оказалось, что начинать надо именно с их разбора. Потому что там буквально нагромождение археологических слоёв правил. Иногда — прямо алмазы. Мы одними из первых в России сделали реальный автоматизированный КЭДО для крупного производства, но, как говорится, есть нюанс. И не один.

https://habr.com/ru/companies/omk-it/articles/849468/

Развенчиваем мифы об ИТ в металлургии

Привет, Хабр, меня зовут Иван Белов, я руководитель Backend-разработки в НЛМК ИТ. Регулярно принимаю на работу новых специалистов из различных отраслей и хорошо знаю, какие заблуждения есть у тех, кто мало знаком с нашей отраслью. Давайте попробуем развенчать самые распространенные мифы и послушаем истории наших айтишников.

https://habr.com/ru/specials/848832/

Весь бекэнд сталелитейной компании — как это у нас устроено

Пять лет назад у нас почти не было собственной разработки бэка: очень многие вещи делались силами подрядчиков, вендорами и командами поддержки. «Почти не было» — потому что всё же было много SAP и легаси-систем, разработанных, например, на Oracle, которые не менялись по многу лет. Если производству было нужно что-то кастомное, то можно было взять готовый кубик у вендора и аккуратно доточить его напильником силами команды интегратора либо же перетоптаться. Сейчас у нас есть собственная микросервисная разработка. В целом в бекэнде — около 200 разработчиков, которые пишут на современном технологическом стеке. Административно всё устроено так: есть профильные и функциональные центры компетенций, например, есть первые переделы (обработка руды и всё такое), есть прокатное производство, есть выплавка, есть ремонты, есть HR-системы и так далее. Функционально все бекэнд-разработчики объединены в нашем Центре компетенций. Я и лидеры гильдии отвечаем за соответствующие стеки. Мы не трогаем уровень микроконтроллеров технологического оборудования, не лезем в АСУ ТП (там есть отдельное подразделение со своей атмосферой), поэтому основная часть нашей работы находится на уровне управления производством. Есть ещё системы управления закупками, продажами, логистикой, планирования на различном уровне. Значительная часть наших задач — разработка цифровых помощников, оптимизаторов производства и многих других вещей, про которые вы уже несколько лет читаете у нас в блоге на Хабре. Мы делаем архитектуру, логику, реализацию под конкретное производство и контрибьютим это в свой набор компонентов.

https://habr.com/ru/companies/nlmk/articles/832474/

Есть ли на заводе IT? Как уехать из хаоса веб-разработки к нормальной компании

Сегодня мир IT представляет собой разнообразную экосистему с множеством компаний, специализирующихся на различных аспектах разработки программного обеспечения. Однако среди них есть и такие, где условия работы и требования к сотрудникам могут вызывать сомнения. Одним из таких мест может стать завод, где IT-департамент функционирует в условиях, далёких от идеала. В этой статье мы рассмотрим, почему работа на заводе в IT может стать настоящим испытанием для разработчика, как это влияет на его карьеру и что можно сделать, чтобы найти более подходящее место работы. Зарплата и ожидания: 50 тысяч рублей за полный стек Давайте начнем с зарплаты. Для многих веб-разработчиков, работающих на полном стеке, 50 тысяч рублей может казаться заманчивым предложением. Однако эта сумма часто бывает мизерной по сравнению с объемом работы и ожиданиями, которые возлагаются на сотрудников. Программисты, которых нанимают на такие должности, часто сталкиваются с ситуацией, когда вместо комфортного выполнения задач приходится решать абсолютно нереальные задачи, надеясь, что завтра не придется переписывать всю систему заново. Хаос и нереальные сроки Внутри таких компаний царит настоящий хаос. Проектные сроки уезжают в космос, и разработчики все чаще оказываются в положении, когда планирование проекта напоминает скорее гадание на кофейной гуще, чем осмысленное руководство. Кажется, что каждый новый проект становится эпопеей, где фраза «мы хотим здесь свой Яндекс» звучит как предсказание будущих проблем, а не как реальная задача.

https://habr.com/ru/articles/833216/

Оптимизатор монтажей прокатного стана-2000

Оптимизация завода делается на разных уровнях. Вот пост про 48-недельное планирование (верхнеуровневая кластеризация заказов в серии) с посуточным планированием и графикованием цеха (что и в какой последовательности производить, чтобы потребовался минимум переналадок) с шагом планирования 10 минут. Я занимался графикованием одного станка, правда, размером с огромный цех в несколько футбольных полей. Таких задач на заводе сотни, и вот я один из тех айтишников, кто их решал. Верхнеуровнево про работу цеха проката есть тут , поэтому сразу без вступлений давайте я расскажу про оптимизацию.

https://habr.com/ru/companies/nlmk/articles/825814/

GPT для генерации кода в реальном применении на производстве

Почти все используют GPT или другие LLM-based-решения для генерации кода. Есть куча проектов, где так же генерируют фронт (код интерфейсов). Собственно, когда у нас появилась дизайн-система со множеством компонентов, стало понятно, что это идеальная документация для обучения модели, ведь она включает в себя описание типов, аргументы, тесты и состояния использования компонентов. В какой-то момент я начал задумываться, почему мы не используем код, который есть в дизайн-системе, чтобы он автоматически генерировался помощником. Достаточно векторизовать эту базу, дальше модель сможет на основе нашей дизайн-системы выдавать готовые решения по текстовому запросу. Многие наши компоненты достаточно сложные. Самый сложный — таблица, потому что у нас много разных типов таблиц для производственных данных. Внезапно выяснилось, что разработчику нужно три дня, чтобы вникнуть в матчасть и написать свою первую таблицу — или же примерно 30 секунд на запрос «сделай мне таблицу для такой-то задачи», чтобы GPT-4 выбрал подходящие параметры и сразу показал, что надо. Либо дал скорректировать запрос, если таблица не подходит.

https://habr.com/ru/companies/nlmk/articles/826754/

Непреодолимая легкость повышения утилизации GPU

Привет, Хабр! Я Антон, DevOps-инженер в Selectel. В апреле у нас проходил ML-митап, где я и мой коллега, ML-Ops инженер Ефим Головин , рассказали, как подбираем конфигурацию ML-инфраструктуры и повышаем утилизацию GPU. Запись нашего выступления можно посмотреть на YouTube . Материал вышел интересным, поэтому мы решили оформить пересказ в текстовый формат. В этой статье вы узнаете, как перенести лучшие практики из мира производства в сферу машинного обучения, подобрать конфигурацию вычислительной инфраструктуры под ML-нагрузки и максимально эффективно ее использовать. Впереди много интересного, так что давайте начнем!

https://habr.com/ru/companies/selectel/articles/822651/

Отвага и отвага: как мы выбирались из полного абзаца с неработающей ERP на 39 производствах

39 наших площадок вагоноремонтных депо перешло из холдинга РЖД в Группу ОМК. Нам надо было за год перейти на новую систему управления производством, потому что оставаться в ИТ-ландшафте железных дорог было нельзя. Мы выбрали 1С ERP и восемь месяцев от ТЗ до дедлайна вместе с подрядчиком героически внедряли первую её очередь. Итогом стало: Прошлая система отключена. Новая система запущена в фактической альфе, функционал — около 40 %, и она не работала. Пользователи из депо готовы поднять нас на вилы, сжечь и растоптать. И повторить. Многие данные вбиваются без проверок сотрудниками цехов, то есть в первичке — настоящий ад. Чтобы вы понимали, какой: чуть не влетели на 29 миллиардов рублей, потому что кто-то забил серийный номер в стоимость. Железо не тянет всё это на местах, в том числе и серверы. Каналы тоже всё это не тянут. Между двумя полями ввода на одной форме — от 30 секунд до разрыва и вбивания всех данных заново. Поскольку мы успели собрать ТЗ только с центрального офиса, от региональных депо появляются всё новые и новые требования. Мало кто понимает, как это всё работает, а надо править прямо в бою. Вторая-третья линии поддержки (пять человек нашего ИТ-отдела) не понимают мастеров, первой линии вообще нет, и ресурса нет, чтобы её создать. Хвост обращений — несколько тысяч неотвеченных тикетов. Ковид и карантины. Бухгалтерия немного нервничает. А дальше — обычная для вагоноремонтного депо ситуация: нужно любыми доступными средствами выполнить задачу. Выбора нет! Собственно, продолжаю рассказывать, что именно мы сделали.

https://habr.com/ru/companies/omk-it/articles/823188/

Отвага и отвага: замена ERP на действующем вагоноремонтном производстве с тестами прямо в бою

Если бы мы были обычной компанией, то вы никогда не услышали бы эту историю. Это то, во что ни один здравомыслящий человек не должен вписываться ни при каких условиях, это тип задачи, который просто невозможен для ИТ по своей сути, но нам нужно было это сделать. Потому что производство ставит реальные задачи. А они пахнут далеко не розами. Итак, мы 80 лет ремонтируем вагоны, у нас 39 точек на карте: вагоноремонтных депо и участков отцепочного цеха от Белгорода до Белогорска, и раньше мы входили в состав РЖД. Потом вошли в ОМК, и понадобилось переехать из одного ИТ-контура в другой. Мы пользовались для управления производством и для отчётности частями софта РЖД. Софт был понятен, привычен, очень глубоко интегрирован во всё, что у нас есть, и в ландшафт РЖД. Дальше у нас был простой выбор: либо мы остаёмся вообще без систем, либо внедряем свои. РЖД была не готова держать в своём контуре компанию чужой группы, а переход в DMZ после подсчётов оказался почти таким же по цене, как новое внедрение. С учётом отдельной лицензии SAP — даже дороже. В итоге мы оказались в ситуации, когда за год нужно было выделиться в отдельный контур, внедрить 1С ERP, запустить на ней управленческий и бухгалтерский учёт, само управление производством, и всё это — без шансов сделать что-то не то. На всякий случай подскажу, что мы умеем ремонтировать вагоны. Мы не занимаемся внедрением ERP, и вообще на этот проект у нас было всего человек пять айтишников. Сюра в ситуацию добавил тот факт, что подрядчик понял задачу не как «Нужно кровь из носу сделать до дедлайна», а как «Нужно расписать план работ до дедлайна, а там — как пойдёт». В общем, на начало проекта мы ещё не понимали, что нам придётся повидать. Не повторяйте такого дома. Никогда!

https://habr.com/ru/companies/omk-it/articles/821023/

Особый фронтенд на заводе: desktop first, тёмные помещения, промышленные интерфейсы и специфика производственных систем

Привет, Хабр! Меня зовут Олег Рогов, я руковожу фронтенд-разработкой НЛМК. У нас команда на 70+ человек, в основном мы делаем интерфейсы для промышленных систем. Например, дизайнеры рисуют схему цеха или огромную таблицу сравнения для коксохима, мы всё это внедряем и потом поддерживаем на фронтах. Наши фронты — это в основном широкоформатные экраны, поэтому мы пишем приложение под них в первую очередь. Причём экран такой, около которого сидит инженер (часто в защитных очках) и смотрит на него при не самом хорошем освещении. По большей части мы визуализируем производственные системы, дашборды состояний цехов, разные прикладные штуки вроде больших таблиц выработки руды, временные ряды загрузки оборудования, финансовый анализ производства, логистику, инженерный анализ возможного отказа оборудования. 80 % наших задач крутится вокруг систем управления производством, то есть мобильное приложение или планшет — это для нас редкий экран, но и такое разрабатываем.

https://habr.com/ru/companies/nlmk/articles/817477/

Про дверь к коксу и дверевого

Это коксовая батарея, внутри которой из угля выпекают высокотемпературный многотонный пирог. Высота батареи — девять метров, а двери — пять. А еще есть у нас такая профессия — дверевой. Это специальный человек, который, в частности следит за тем, чтобы двери в коксовую батарею открывались и закрывались. Дверь открывает специальная огромная машина, которая ездит параллельно батарее. Она снимает створку, затем выталкивает кокс. На противоположной стороне похожая машина снимает свою створку и принимает коксовый пирог в вагон поезда. В одну дверь толкают, а из противоположной двери ловят в вагон, всё просто. Малейший дефект двери даёт утечку газа из печи. А мы это очень не любим по двум причинам: Мы живём в Липецке и хотели бы, чтобы он и дальше оставался самым чистым городом металлургов в России. Это снижает КПД печи. И вот когда к нам в ИТ постучались экологи, мы пошли смотреть, что можно улучшить.

https://habr.com/ru/companies/nlmk/articles/814511/