Вариант 3
Анализ и формализация бизнес-процесса: Распределение грузовиков и каскадный перерасчёт поставок для перевозки жидкого цемента
Контекст и цель
Цель — разработать понятную, устойчивую и масштабируемую систему распределения грузовиков по заказам в рамках фиксированной 12-часовой смены, с возможностью динамического каскадного перерасчёта временных окон (слотов) при возникновении сбоев (поломка, ДТП, задержка на разгрузке) или при появлении дополнительных свободных машин. Система должна гарантировать непересечение слотов на диаграмме Ганта, обеспечивать максимальную прозрачность через визуализацию, иметь событийную архитектуру с чёткими интерфейсами между сущностями и быть устойчивой к форс-мажорным отклонениям, приводящим к задержкам или выходу машины из работы.
Формализация: Сущности, ресурсы и ограничения
Основные акторы (сущности):
Заказ (Order) — содержит ID, объём в кубометрах, клиента, приоритет (от 1 до N) и желаемое окно доставки. Он инициирует потребность в транспортировке и может требовать нескольких поставок.
Поставка (Shipment) — атомарная единица выполнения: один рейс одной машины. Имеет ID, объём, связь с заказом, статус (запланирована, в пути, выполнена, отменена), а также плановое и фактическое время погрузки и разгрузки.
Грузовик (Truck) — основной мобильный ресурс. Обладает ID, вместимостью в кубометрах, текущей геопозицией, статусом (свободен, в работе, в ремонте, недоступен) и временем, когда он возвращается к заводу. Может совершать несколько поставок за смену.
Смена (Shift) — временной горизонт (например, с 06:00 до 18:00), в котором должны быть завершены все поставки. Включает точку погрузки (бетонный завод).
Диспетчер (Dispatcher) — логическая сущность, которая инициирует расчёт, подтверждает перерасчёт и реагирует на события. В системе выступает как активатор процессов.
Ключевые ограничения:
1. Время жизни бетона: жидкий цемент начинает твердеть после загрузки. Стандартное «окно жизнеспособности» — 90 минут от момента погрузки до начала разгрузки. Это жёсткое ограничение на продолжительность поставки.
2. Непересекаемость слотов: на диаграмме Ганта для одного грузовика не может быть двух активных поставок одновременно.
3. Фиксированный горизонт: все поставки должны быть закончены (разгружены) до конца смены.
4. Форс-мажор: любой сбой (поломка, ДТП, задержка) приводит к одному из двух исходов — либо машина выбывает полностью до конца смены, либо возвращается позже, чем предполагалось, и её последующие слоты смещаются или отменяются.
Основные события и интерфейсы
Система строится на событиях. Примеры ключевых событий: OrderCreated — создание заказа, триггер для разбиения на поставки; ShipmentScheduled — поставка назначена на машину и слот; TruckBreakdown — машина вышла из строя, инициирует каскадный перерасчёт; NewTruckAvailable — появилась свободная машина, может запустить оптимизацию; ShipmentCompleted — поставка завершена, обновляется статус машины.
Интерфейсы обеспечивают взаимодействие: ITruckSelector выбирает грузовик по критериям (близость к заводу, вместимость, приоритет клиента); IScheduleEngine управляет расписанием — назначает, пересчитывает, проверяет конфликты; IEventPublisher и IEventListener обеспечивают обмен событиями между компонентами (например, через паттерны Mediator или Observer).
Алгоритм первоначального распределения (прогнозное планирование)
Шаг 1. Разбиение заказов на поставки. Для каждого заказа с объёмом V и максимальной вместимостью машины C количество поставок равно округлённому вверх значению V / C. Каждая поставка имеет объём не больше C.
Шаг 2. Назначение поставок на машины с помощью жадного алгоритма с приоритетами. Для каждой поставки (отсортированной сначала по приоритету заказа, затем по требуемому времени доставки):
— фильтруется пул доступных машин (статус «свободен» или «станет свободен до конца смены»);
— кандидаты сортируются по расстоянию до завода (ближе — лучше), затем по вместимости (должна быть достаточной), и при равенстве — по приоритету заказа;
— выбирается первая подходящая машина и назначается на ближайший свободный временной слот, который укладывается в смену, учитывает полный цикл (погрузка → транзит → разгрузка → возврат) и не нарушает 90-минутное окно жизнеспособности;
— в диаграмму Ганта добавляется новый слот.
Алгоритм каскадного перерасчёта (реактивное планирование)
Активируется событием: TruckBreakdown, ShipmentDelay или NewTruckAvailable.
Шаги:
1. Идентификация всех затронутых поставок — это поставки, назначенные на повреждённую машину после точки сбоя, а также поставки других машин, которые зависят от её завершения (например, по времени на одном объекте).
2. Освобождение соответствующих слотов в расписании.
3. Перераспределение: список затронутых поставок сортируется по приоритету и требуемому времени, затем к каждой применяется тот же алгоритм выбора машины, но только по свободным слотам. Если машина выбыла — поставки назначаются на другие. Если появилась новая машина — система может перераспределить часть нагрузки для оптимизации.
4. Валидация новых слотов: проверка на пересечение, укладку в 90 минут и завершение до конца смены.
5. Публикация события ScheduleRecalculated — обновление диаграммы Ганта и уведомление заинтересованных сторон.
Важно: перерасчёт должен быть ограничен по глубине или времени выполнения, чтобы не зависнуть в случае множественных сбоев.
Подводные камни и риски
Жёсткое 90-минутное окно может привести к выбросу бетона и убыткам. Смягчение: использовать динамическую модель «живучести», учитывающую состав смеси и температуру, а также закладывать временные буферы.
Неточное время мойки или разгрузки вызывает накопление задержек и срыв последующих слотов. Смягчение: использовать исторические данные для прогноза длительности операций на каждом объекте.
Зависимость от точности GPS и статусов может привести к ошибкам (система «думает», что машина свободна, а она в пробке). Смягчение: интеграция с телематикой и возможность ручной коррекции статуса через мобильное приложение водителя.
Перегруз диспетчера — он не успевает реагировать на множество сбоев. Смягчение: система не только пересчитывает, но и предлагает 1–2 лучших варианта на выбор.
Отсутствие буферов делает систему хрупкой: любая мелкая задержка запускает каскадный сбой. Смягчение: заложить временные буферы (10–15 минут) между слотами на высокорисковых маршрутах.
Рекомендации по архитектуре
Система должна быть построена на событийной модели с использованием паттернов Mediator, Observer или Reactor. Для хранения полной истории изменений рекомендуется использовать event sourcing (например, EventStoreDB). Визуализация через диаграмму Ганта обязательна — она должна поддерживать drag-and-drop и автоматически подсвечивать конфликты.
Интеграции: с GPS/телематикой для отслеживания статуса машин, с мобильным приложением водителя для подтверждения операций, с ERP/CRM для синхронизации заказов и приоритетов.
Технологии: бэкенд на .NET C# с паттернами Strategy (для гибкой смены алгоритмов выбора машины) и Mediator (для обработки событий); фронтенд на Svelte/SvelteKit для интерактивной диаграммы; инфраструктура — Docker и Redis (для кэширования текущего состояния расписания).
Заключение
Система распределения грузовиков для перевозки жидкого цемента — это не просто задача оптимизации, а динамическая система управления рисками. Успех зависит от трёх основ: точной формализации сущностей и ограничений (особенно 90-минутного окна), событийной архитектуры, обеспечивающей мгновенную реакцию на сбои, и поддержки человека через визуализацию и рекомендации, а не его замены. При правильной реализации каскадный перерасчёт превращается из хаотичной реакции в предсказуемый и контролируемый процесс, что напрямую повышает надёжность поставок и удовлетворённость клиентов.