Меня зовут Ася, и я занимаюсь решениями по оптимизации в НЛМК-ИТ. Много лет я работала .NET разработчиком, мечтала о профессиональном росте. Коллеги из проекта по календарному планированию и графикованию поверили в меня и взяли в команду, несмотря на то, что на тот момент я не имела релевантного опыта. Я узнала, что математические модели востребованы и в металлургии. И вот мы выпустили в опытно-промышленную эксплуатацию проект оптимального планирования производства на основе класса программ Solver.

Здесь хочу рассказать об оптимизации очередей производства в прокатном и электросталеплавильном цехах НЛМК-Калуга. На фото прокатный цех:

Когда я начала работать, специалисты составляли планы загрузки агрегатов в Excel. В прокатном цехе это план для прокатного стана, а в электросталеплавильном для МНЛЗ (машина непрерывного литья заготовок). Это основные агрегаты двух цехов, они работают непрерывно день и ночь и одномоментно могут производить только один вид продукции, потом переключаться на другой.

Естественно, это был не предел оптимизации, всё зависело от опыта планировщиков. Были случаи, что забывали заказы — ну, просто потому что даже лучшие из людей не идеальны.

Чтобы узнать какими средствами мы оцифровали процесс планирования производства, прошу под кат.

С чем мы работаем

Вот пример трёх заказов. Два из них на одну и ту же продукцию, а третий - на другую. Здесь различие между типами продукции представлено только двумя параметрами для простоты: диаметр и класс прочности. Но в реальности таких параметров больше: длина, технологическая карта, вес пакета.

Между диаметрами самые долгие переналадки оборудования, поэтому тут они задают длительность. Переналадки между классами прочности обычно 1-2 часа, поэтому они будут сделаны «внутри» перевалки между диаметрами. Как видите, можно скомпоновать вот так в порядке времени отгрузки:

А можно переставить виды продукции оптимальнее, уменьшив время переналадок:

Поэтому первое, что мы можем сделать — это сгруппировать все подобные заказы вместе. Когда типов продукции всего 3, то количество возможных вариантов 3! = 6 штук, т.к. это перестановки без повторений (вспомним из комбинаторики). Но в реальности количество заказов 150-200 шт на 40-55 видов продукции. Например в октябре 2021 видов продукции было 48. Даже если сгруппировать по типу продукции, то  это  48! = 1,2413915592536072670862289047373e+61 вариантов. Немало, не правда ли? Алгоритмически перебрать все варианты не представляется возможным, а еще в этом упрощенном случае не учитываются ряд заданных факторов:

• производить нужно к датам из заказов;

• экспортные марки (все не класса прочности А500С) нужно производить после хотя бы после недолгого проката ГОСТ (класс прочности А500С), потому что нужно наладить оборудование;

• начинать экспортные марки в выходные нельзя, потому что технологи на выходных;

• нужно планировать профилактические ремонты по 8-12 часов 2-3 раза в месяц, их нельзя делать в выходные и не желательно в пятницу. Желательно совмещать их со сменой диаметра арматуры.

Получается, что задача похожа на NP-полную, да еще и наличие дополнительных условий. Как же нам ее решить? На помощь приходит такой класс программ как «солверы», иначе - «решатели», иначе - «оптимизаторы». Для примера, это IBM CPLEX Solver, Gurobi, Google OR Tool и другие.

В качестве движка мы выбрали  IBM CPLEX Solver, потому что он умеет оперировать с такими сущностями, как временные интервалы и переставлять их между собой в зависимости от ограничений. Это очень удобно, потому что отражает жизненную ситуацию, когда мы оперируем именно интервалами производства определенного типа продукции.

Вот так, например, выглядит определение переменных-интервалов:

dvar interval RepairInterval[ i in repairIds] in repairStartAfter[i]..repairEndBefore[i] size repairDuration[i]; // интервал ремонта
dvar interval RollInterval [ i in rollIds ] optional in rollIntervalStart[i]..rollIntervalEnd[i] size rollDuration[i] intensity profFunction; // интервал прокатки

А так, например, ограничения в модели:

forbidStart(RepairInterval[i.id], weekendFunction); // ограничение не начинать ремонт в выходные

Суть математической модели в IBM CPLEX Solver это:

• определение констант и переменных (в том числе интервалов)

• задание объектной функции, т.е. что мы минимизируем или максимизируем

• наложение ограничений на переменные в блоке subject to { … }

Как это работает на практике

Чтобы уйти от человеческого фактора, оцифровать процесс планирования и довести сменно-суточные задания до цеха не на бумаге, а в электронном виде, мы написали отдельный сервис. Сервис написан на .NET (язык C#), также для математического моделирования использовали язык IBM OPL. Интерфейс для представления результатов его работы выглядит так:

И сменно-суточное задание формируется тоже автоматически после расчета, где разноцветную "колбасу" с календарного плана мы просто нарезали кусками по суткам. Потом это можно распечатать и подписать.

Для оцифровки и автоматизации процесса планирования у нас все уже было готово: ERP и MES системы хранили сбытовые заказы, остатки и отгрузки. А также они были готовы отправлять это в наш сервис.

Нам осталось только сгруппировать потребность по материалу, вычесть остатки и отгрузки. А потом подать все это на вход «решателя» Solver.

Особенности планирования в прокатном и сталеплавильных цехах

Электросталеплавильный цех производит заготовку для дальнейшей обработки в прокатном цехе. В прокате из заготовки производят стальную арматуру или уголок. Чтобы прокатный цех не встал, он должен всегда иметь «подкат», т.е. запас заготовок определенных марок стали. При этом заготовка должна быть произведена именно к началу проката – не сильно раньше и не позже (не затариваем склад). Для этого нужно увязать между собой производственные планы двух цехов.

Эту задачу решили двумя разными последовательными расчетами:

• сначала запускаем расчет плана производства для прокатного цеха, потому что заказы прокатного цеха – это заказы от клиентов и имеют свои уникальные даты отгрузки;

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

Итог

Проект автоматизации построения планов для завода НЛМК-Калуга длился около 6 месяцев. Важно, что к моменту старта проекта в полной мере была реализована базовая автоматизация и учетные системы с выходными данными:

• Отдел продаж аккуратно ведет учет заказов и отгрузок в своей учетной системе.

• На производстве внедрили MES-систему для учета остатков на складе.

В результате мы смогли успешно справиться с проектом календарного планирования. Самым большим достижением считаю, что расчет модели прокатного и электросталеплавильного цехов занимает не более 10 минут. Теперь человек здорово экономит время, все выглядит стандартизировано, и уход любого планировщика в отпуск теперь не проблема.