Как меняется сумма от перемены мест в графике производства

Меня зовут Ася, и я занимаюсь решениями по оптимизации в НЛМК-ИТ. Много лет я работала .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#, также для математического моделирования использовали язык OPL. Интерфейс для представления результатов его работы выглядит так:

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

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

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

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

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

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

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

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

Итог

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

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

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

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