Comments 39
Чувствуется, что "немецкая сталь" это не "просто маркетинг".
один остывший не к месту ковш запросто может нанести ущерба на несколько миллионов рублей
Как то дёшево прям, я думал раз в 50 больше будет
Касательно планировщика - как он работает? Прямым перебором всех вариантов или там что-то более интересное?
В принципе перебор вариантов, но там же масса технологических ограничений. Эти ограничения переводят большую часть таких вариантов в разряд запрещенных. Тут, наверно, самая интересная часть задачи — в генерировании ограничений для конкретного кейса.
По поводу стоимости: мы ведь не выкидываем всю плавку целиком в мусорку, если что-то пошло не так. Просто из более качественного сорта она идет на марку пониже. Разницу в стоимости я примерно прикинул. Зависит от того, какие ферросплавы были добавлены и так далее.
А на программном уровне как это реализуется? Через дерево решений, КА с обновлением запрещенных состояний/переходов или как-то иначе?
ЗЫ Интересно, если сделать по примеру FoldIt игру-убивалку времени или мод для Факторио, не получится ли закраудсорсить внутрицеховую логистику?)
Тоже очень интересно. Программирование в огранчениях?
"Как-то" написать можно, но вот чтобы без макарон и чтобы можно было понять написанный полгода тому код, у меня получилось только с использованием дерева решений. С удовольствием почитаю про архитектуру кода, который не надо примерно целиком переписывать при добавлении нового рабочего центра или коренном изменении графа связей (например, ещё проём в стене пробили).
При множестве "правильных" решений(где есть чуть более и менее правильные) и очень широкой области поиска, неплохо подходит ГА, где ген - само расписание, а "актуальными" на данный момент ограничениями оценивается сам ген.
Тогда если рухнет стена и появилась новая связь - вводятся новые ограничения "оценщики" гена, а текущее расписание продолжает оптимизироваться.
Код при этом состоит из четких маленьких сущностей в один два экрана, а ограничения самостоятельны, просты и очевидны.
Спасибо, в сторону ГА не смотрел, почти с ними не работал. Не подскажете по разработке и внедрению?
Правильно ли я понимаю, что на проде продолжается эволюция?
Как предотвращаются очевидно нежелетальные действия? Через высокий penalty или через хардкод?
Насколько сложно сертифицировать самомодифицирующуюся программу на ГА? Deep learning и нейросети в РФ в критичной инфраструктуре, например, в медицине, лучше просто не использовать именно из-за сертификации.
ГА(ГП) после восьми лет работы с ними для меня стали скорее философией, чем конкретными подходами. Так что на любой вопрос по ним я не могу дать четкого ответа, только собственное представление и понимание.
Давайте я отвечу примерами в упрощенном представлении задачи в контексте этой статьи - "расписание чанов с расплавом на отливку".
Да, но с особенностями. Все зависит от бюджета, рамок и сложности задачи. Можно каждый раз продолжать непрерывно искать от последнего найденного решения, а можно, к примеру купить стойку БД, куда оффлайн рассчитываем решение проблемы расписания с шагом, чтобы забить эту БД(разбиваем общую ситуацию на элементы, нумеруем их, получаем обобщенный хеш который в дальнейшем используем в качестве ключа), а после ищем всегда по алгоритму - текущая ситуация -> получаем хеш -> получаем из БД приближенное решение -> ищем от него более оптимальное от конкретной ситуации. Именно так можно гарантировать отработку ГА за заданное время(за время обращения к БД мы получим "среднее" НО решение).
От конкретной ситуации. Мне очень полюбился подход "ступенек", где у нас есть множество оценок решения, где мы смотрим на каждую последующую оценку только если предыдущие идентичны. (если хуже - решение отбрасываем, если лучше, соответственно - заменяем). Тогда "жесткие" условия задаются бинарной оценкой 0,1, суммируются и ставятся в самом начале. Неважно какая будет "мягкая" оценка(на второй позиции списка оценок), если ухудшается хоть один "жесткий" параметр - такое решение не пройдет. В контексте упомянутой БД, мы всегда можем рассчитать все решения так, чтобы не было нежелательных действий (к примеру "количество догревов"), ГП будет оптимизировать тогда что-то мягкое - "потери в рублях", "общее время простоя".
Могу предложить один из возможных вариантов - у нас на выходе будет полноценное "решение" - конкретное расписание, а не "решатель" как в случае нейросетей. Следовательно мы создаем верификатор "расписания", который содержит математическую/имитационную модель, сертифицируем ее а после подаем найденные решения ей на вход, конвертируя в удобный для верификатора формат. Она их одобряет и у нас на руках "сертифицированное" решение, а не программа которое их генерирует.
Спасибо. Не посоветуете литературу или опенсорсный проект, чтобы знать, когда ГА вовремя и как они правильно используются? И в идеале то же самое, но с неправильно и невовремя.
ГА(ГП) после восьми лет работы с ними для меня стали скорее философией, чем конкретными подходами. Так что на любой вопрос по ним я не могу дать четкого ответа, только собственное представление и понимание.
Через какое-то время познаешь Дао, но при этом понимаешь, что Дао, высказанное словами, не настоящее Дао. А до момента просветления рассказать несложно, но информация будет несколько однобокой. Проходили, увы.
Издательство ДМК "Генетические алгоритмы на Python" Эйял Вирсански - даёт самый приятный и плавный ввод в эту тему. Саму книгу можно читать и не зная Python, а просто воспринимая его как псевдокод. Но тогда теряется другой плюс книги - автор для примеров использует одну из самых популярных библиотек по ГА в Python DEAP, так что после прочтения можно приступать к решению собственных задач с помощь серьезной библиотеки. Под мои задачи DEAP оказалась немного неудобной(нельзя легко сделать ту же "оценку ступенькой", приходится перегружать несколько классов и по мелочи(уже не помню), так что после пары доработок, я написал себе свои заготовки пустышки с чем и работаю до сих пор.
Самое главное в ГА - это отсутствие рамок. Если в книге в гене перемешивают биты, вы должны понимать что это лишь принцип, перемешивайте слова, ассесблерным инструкции, чаны с металлом, людей в очереди и т.п. ГА это лишь идея подходов, изложенная в конкретных примерах.
То есть по сути для каждой рецептуры стали создается электронная технологическая карта, учитывающая время выполнения промежуточных операций над расплавом и скорость охлаждения стали в ковше (чтобы избежать догрева, если придется "ждать в очереди")? И затем в начале цикла грубо говоря идет команда "начинай процесс", в нужный момент времени, когда с учетом расположения и выполнения графика впереди идущими сталевозами наиболее вероятно попасть в максимальный разрыв подачи стали на УНРС?
Вот такие корпоративные блоги мне нравятся. Пишут посты о том, что происходит внутри и как устроено. Спасибо и добро пожаловать :)
Спасибо за статью! Отличная наглядная иллюстрация к книге "Цель" (Элияху Голдратт)
Какую SCADA используете?
Всегда недоумевал, если температура расплава ~1600 градусов, то почему не плавится ковш? Он же не из вольфрама наверное, а тоже из стали
Он прогорает. Внутри футеровка в несколько слоёв разных материалов. Её периодически меняют.
Вот тут вы можете видеть 1 Тб стали
Долго вчитывался. Как так всего лишь один терабайт стали?
Ковш изнутри выкладывают огнеупорным кирпичом, и этот кирпич часто меняют, потому что прогорает. То же самое и с доменными печами
Интересный такой тетрис !
Сверху падают фигурки, наверно по десятку квадратиков и по нескольку штук, и их робот должен уложить оптимально.
Интересно в чем отливают ёмкость для этой лавы
Увидел превью, захотелось бурой посыпать сверху :) Я считаю, что автор может продолжить цикл общих образовательных статей. Об истории металла, с античных лет. О современных сплавах, о составе стали рассказать, про автомобильный коленвал. И как плавить мельхиор ;)
Прекрасная статья, очень здорово что есть такое окно теперь в реальную реальность.
Как вы тренировали сеть и какую для распознавания номеров и значимой инфы?
Как реализовали непрерывное отслеживание движения? Переход между камерами, кадрами, видеопотоками?
Там использовалось несколько сетей, например, для детекции объектов применяли yolov3. Сети тренировали, когда уже развернули систему видеокамер, оттуда брали кадры для разметки и обучения. Целостные траектории строятся на двух компонентах — координатах объектов и сигналах состояний, по которым можно определить значимые события. Основное событие для отслеживания — передача ковша. Передача ковша, например, со сталевоза на кран может быть осуществлена в рамках конечного множества точек на схеме цеха. Вы отслеживаете попадание объектов в эти точки и при определенной комбинации сигналов состояний фиксируете то или иное событие. Тут, конечно, сразу возникают вопросы фильтрации шумов в сигналах и так далее, но идейно подход такой.
А почему обязательно греть, нельзя заблоговременно в термос сунуть или подуть коли перегрели?
вот уж не ожидал на хабре найти блог родного НЛМК
Варим суп из стали: оптимизация логистики ковшей и как устроен цех КЦ № 2