Вызовы диспетчеризации на горнодобывающем предприятии

Современное горнорудное предприятие открытого типа представляет собой сложную топографическую модель, на которой работает большое количество горнотранспортных комплексов (ГТК), состоящих из экскаваторов разной кубатуры ковша и самосвалов разной вместимости кузова. Это обусловлено как различными типами работ (вскрыша, добыча), так и часто меняющимися горно-геологическими условиями, требующими техники разной характеристики для оптимальной производительности на конкретном участке горных работ. Например, если 18- и 22-кубовые экскаваторы оптимальны на вскрыше, а 5- и 7-кубовые – на добыче, то при сужении забоя 22-кубовые экскаваторы уже не оптимальны, равно как и при селективной выемке 7-кубовые. Здесь лучше подойдут 12-кубовые. То же самое можно сказать о работах по прокладыванию дорог.

Разносортица экскаваторов создает требования к парку самосвалов, где вместимость кузова должна соотноситься с объемом ковша экскаватора: нет смысла ставить 130-тонный БЕЛАЗ под 22-кубовую ложку, которая погрузит его за 3 цикла, что увеличит время конечных операций (постановка под ковш и отъезд). Также непроизводительно будет использовать 220-тонный БЕЛАЗ под 12-кубовой машиной, которая будет его грузить «в час по чайной ложке».

Все это многообразие техники является типичным примером относительно крупного предприятия и предъявляет высокие требования к диспетчеризации – то есть к постоянному внутрисменному контролю за ее распределением с единственной целью: снизить простои техники, чтобы повысить ее производительность.

Не будет новостью сказать, что эти функции невозможно выполнить типичным подходом: диспетчерской с людьми, пытающимися эффективно распределить технику в режиме онлайн с помощью рации. Они не видят полную картину и зачастую не могут правильно интерпретировать сигналы от машинистов экскаваторов, или водителей самосвалов. Поэтому уже давно в постоянный обиход вошли системы автоматической диспетчеризации типа Wenco, Modular, или отечественная разработка группы «Цифра» АСУ ГТК «Карьер».Елена Истомина, Directum: Как no-code меняет стоимость проекта 6 т

Последняя был применена в Восточной Горнорудной Компании (ВГК), на примере которой я продемонстрирую основные вызовы и решения, к которым мы пришли путем доработок основного программного продукта с целью адаптировать базовую версию к реалиям современного горнодобывающего производства, создав в итоге гибкий инструмент, позволяющий минимизировать вмешательство человека (диспетчера), снабдив его «глазами» в карьере.

Коротко о компании: ВГК занимается открытой добычей энергетических углей на о.Сахалин в Охотском море и их экспортом в Азиатско-тихоокеанский регион через собственный рейдовый порт в 28 км от угольного разреза. Добыча в 2019 г составила 9 млн тонн. Запасы – 300 млн тонн. Основные проекты компании: строительство магистрального угольного конвейера из разреза в порт длиной в 28 км и модернизация портовой инфраструктуры с увеличением мощности по перевалке до 20 млн тонн в год.

Мы начали интеграцию системы АСУ ГТК «Карьер» в нашу диспетчеризацию в 2017-м году, и в 2019-м перевели ее уже в опытно-промышленную эксплуатацию. В своем первоначальном варианте она представляла из себя базу, собирающую данные с датчиков, установленных на технике: геопозиции для расчета времени прибытия самосвала под экскаватор, нагрузки на подвеску для определения веса породы, или угля в кузове самосвала, движения стрелы экскаватора для определения его работы, уровня топлива в баках для фиксации его расхода и т.д. Однако очень быстро мы поняли, что главная добавленная стоимость этого продукта – именно в возможности спланировать движение техники таким образом, чтобы минимизировать ее простои. Этой цели отвечал Модуль Оперативного Управления (МОУ), предложенный совместно с продуктом.

Суть этого модуля - в планировании прибытия самосвала под экскаватор: понятно, что последний является звеном, задающим ритм всей работе разреза, и кроме того - самой дорогой инвестицией, поэтому минута его простоя самая дорогая для предприятия. Вторая по дороговизне минута – это минута простоя самосвала, особенно 220-тонного, в очереди под погрузку. И уж совсем криминальная ситуация – когда где-то самосвал ожидает погрузки 2-й, или 3-й в очереди в то время, как в другом забое стоит экскаватор без самосвалов.

МОУ был задуман именно для предотвращения описанных выше вещей. Однако мы сразу столкнулись с тем, что базовый алгоритм, заложенный в его функционал, далек от реалий производства. Формула, заложенная в прогнозирование прибытия самосвала под экскаватор достаточно прямолинейна и не учитывает особенностей разреза. Мы задались вопросом «почему», и посетили несколько горнорудных предприятий, использующих автоматические системы диспетчеризации – среди них Стойленский ГОК (НЛМК) и Карельский Окатыш (Северсталь).

На всех этих предприятиях АСУ карьера работала сносно, но нам сразу бросилась в глаза достаточно простая топография карьера: одна дорога из забоя на отвал, один отвал, практически отсутствие пересечений. Базовый алгоритм, заложенный в систему, вполне справлялся с поставленной задачей. Кроме того, на этих предприятиях был относительный профицит самосвалов, поэтому не было проблемы обеспечить экскаваторы работой.

На нашем же предприятии картина совершенно иная. Несколько отвалов с разным плечом транспортировки, множественные пересечения дорог, где самосвалы могут тормозить друг друга и сбивать ритм всего разреза – и немаловажно: парк техники, в разы превышающий численность на других предприятиях в смысле концентрации на одном разрезе: около 40 экскаваторов и 130 самосвалов. При всем многообразии причин остановок синхронизация этого парка практически невозможна…

Столкнувшись с этими проблемами, мы решили, что нет иного варианта, как создать на базе «коробочного» решения нашу собственную, усовершенствованную версию системы диспетчеризации. В первую очередь, необходимо было создать не одну, а несколько точек принятия системой решения о направлении самосвала под тот, или иной экскаватор. Обычно эта точка находится на отвале. Но в нашем случае, когда есть несколько отвалов и несколько перекрестков, очевидным решением было поставить контрольные точки на каждом перекрестке, чтобы последний из них давал финальную корректировку водителю самосвала относительно его маршрута. Так как директива, принятая на отвале, могла кардинально отличаться от таковой на последнем перекрестке – вплоть до того, направить ли самосвал на восточный, или западный борт разреза.

Следующее решение – это автоматизация направления самосвалов на заправку. В традиционной практике есть негласная договоренность водителей: передавать самосвал на следующую смену полностью заправленным. При том, что оптимально самосвал заправляется примерно 1,5 раза за сутки, т.е. 0,75 раз за смену. Чтобы решить эту проблему в АСУ ГТК «Карьер» было по нашей инициативе встроено двухуровневое решение об автоматическом направлении самосвалов на заправку: первая директива подавалась при достижении уровня топлива, близкого к критическому, с оглядкой на наличие очереди на заправку и статус самосвала (груженый, или порожний), и вторая – при достижении критического уровня топлива в баке – однозначно на заправку. После внедрения этого решения мы сократили заправки в 1,5 раза, увеличив таким образом производительность всех комплексов.

Следующее решение лежало в области сокращения простоев на обед. На электрических экскаваторах штатным расписанием предусмотрен помощник машиниста. Его задача – работа с кабельным хозяйством. Однако при определенном обучении он может заменить машиниста на время обеда, убрав таким образом этот простой из смены экскаватора. Теперь дело осталось за малым: точно так же ликвидировать обеденные простои самосвалов, работающих под этим экскаватором. Организационные мероприятия решили этот вопрос, предоставив сменных водителей (система «hot seat»). Теперь осталось только каскадировать обеды таким образом, чтобы один сменный водитель смог заменить всех операторов самосвалов на обеденный перерыв – а это до 6 машин на комплекс. И здесь недостающим звеном явился функционал АСУ ГТК «Карьер», который предоставляет диспетчеру возможность планировать и отслеживать каскадирование обеденных перерывов водителей самосвалов. Перерывы планируются заранее: какой самосвал когда останавливается. При этом заранее собирается информация о необходимости обедов – некоторые водители успевают съесть свой паек, ожидая погрузки, или в иные перерывы в работе.

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

И здесь у нас две проблемы. Первая – это возникновение препятствий, объективно ограничивающих скорость самосвала: качество дорог, авария на дороге, медленно двигающийся впереди самосвал (что может быть следствием как качества дороги, так и чрезмерным износом покрышек). Второе – стиль вождения оператора самосвала. И если наше влияние на первое ограничено объективными условиями (на которые мы тоже можем влиять, но это предмет отдельного обсуждения), то второе вполне под нашим контролем. И этот контроль можно обеспечить с помощью так называемого «подсказчика» водителя, встроенного в МОУ, который корректирует желаемою скорость самосвала для того, чтобы привести взаимоотношение экскаватор – самосвал к балансу. Иначе: спрогнозировать прибытие самосвала под ковш так, чтобы он минимизировал время в очереди ожидания погрузки, но при этом прибыл вовремя для того, чтобы экскаватор не простаивал в ожидании самосвала.

Список этих вызовов и доработок, естественно, не конечен. Но внедрив их в изначальный продукт, мы, по принципу Парето, закрыли, наверное, 80% из 100 функционала, отделяющего стандартную версию автоматической диспетчеризации от необходимого на практике набора решений. Эти решения не являются базовыми, но разработав их с целью адаптации изначального программного продукта к реалиям нашего производства, мы фактически создали новый продукт для диспетчеризации техники на горнодобывающем предприятии. И созданные совместно с разработчиком дополнительные модули можно далее адаптировать под специфику любого предприятия.

Автор: Станислав Площенко