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

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

У каждой отгрузки есть объем и стоимость, а рейс ограничен в объеме. Вы можете подумать об этом как об упрощенной проблеме рюкзака. Итак, есть 1024-1=1023 возможных решений (мы не отправили бы самолет полностью пустым).

Мы могли бы создать электронную таблицу, чтобы перечислить все решение и выбрать самое выгодное из них. Но что, если у вас те же десять отправлений, но два рейса? Это 59 049 решений всего за 10 отправлений.

У крупного экспедитора более десяти отправлений и, конечно, более двух рейсов на выбор, что приводит к триллионам на триллионы возможных решений. Среди них только миллионы осуществимы, а значит, традиционный метод электронных таблиц может найти по крайней мере одно осуществимое решение. Но нам не нужны только осуществимые решения. Нам нужны лучшие, оптимальные решения. Как найти их среди бесчисленных возможностей? Один из ответов - использовать целочисленное программирование.

Целочисленное программирование - это подраздел дискретной оптимизации, область исследования операций, связанных с минимизацией некоторой целевой функции, подверженной ограничениям. Мы хотим минимизировать общие затраты при условии своевременной доставки грузов в нужные пункты, укладываясь в ULD (Unit Load Device - средство пакетирования грузов). Мы стремимся к оптимальному решению, но на практике иногда не можем его достичь. В этом случае мы довольны хорошим или близким решением. Здесь ограничимся простой моделью, в которой оптимальное решение достижимо.

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

Начнем с определения целевой функции. Чтобы минимизировать затраты, нам нужно понять концепцию стандартного веса. Говоря коротко, стандартный вес - это минимальный вес, с которым экспедитор обязуется работать, независимо от того, какой вес предлагается фактически. У нас есть общий вес, стандартный вес и коэффициенты для перегрузок и, наоборот, недовеса. Стандартный вес, умноженный на коэффициент недовеса - это недооценка, поэтому мы можем игнорировать недовес и сосредоточиться на коэффициенте перегрузки, умноженном на саму перегрузку.

Целевая функция - минимизация общей стоимости, определяемой как общий вес всех грузов, присвоенных ULD, умноженный на коэффициент перегрузки. Например, если у ULD1 100 килограммов перегрузки, а ставка за перегрузку для ULD1 – 4 доллара за килограмм, то общая стоимость ULD 1 составит 400 долларов. Итак, нам нужна некоторая нотация для избыточного веса и для его стоимости.

Пусть $inline$ - вес ULD j выше стандартного и $inline$ - коэффициент стоимости для той же ULD. Нам нужно вычислить $inline$ для всех $inline$ . Если $j \in {1, 2, 3}$ , то целевая функция будет $inline$ . Это сворачивается до $\sum y_j^Ec_j^E$ . Мы хотим минимизировать значение, поэтому наша конечная цель:

$\text{min} \sum_{j} y^E_j c^E_j$

Значение для $inline$ не является вычисляемым значением. Это параметр, получаемый из электронной таблицы или базы данных. Но $inline$ мы определили как общий вес перегрузки для ULD $inline$ , который мы можем вычислить как общий вес всех поставок, назначенных ULD (обозначим его $inline$ ), за вычетом стандартного веса этого ULD. Стандартный вес специфичен для типа ULD и также является параметром. Пусть $inline$ - это стандартный вес для ULD $inline$ в килограммах. Тогда сумма дополнительного веса для ULD $inline$ определяется как $inline$ .
Общий вес ULD, конечно, зависит от того, какие грузы отнесены к ULD, и их веса. Поэтому нам нужно выражение для его вычисления, включающее упомянутые выше детали.

Это просто сумма весов грузов, назначенных ULD. Как указать, что партия товара была назначена конкретному ULD? Для этого нам нужен не параметр, а переменная решения. Переменная решения - это то, что решатель может контролировать при минимизации целевой функции.

Пусть параметр $inline$ представляет вес брутто груза $inline$ в килограммах.
Например, $inline$ означает, что груз 4 весит 500 килограммов.

Пусть $x_{i, j}$ - переменная решения, принимающая значение 1, если отгрузка $inline$ назначена ULD $inline$ , и $inline$ в противном случае. Таким образом, когда мы хотим подсчитать все отгрузки, назначенные ULD 3, мы можем выполнить цикл по всем переменным $x_{i, j}$ , где $inline$ . Если бы у нас было 4 отгрузки, и отгрузка номер 1 и 3 была назначена ULD 3, это выглядело бы так:

$x_{1,3} + x_{2,3} + x_{3,3} + x_{4,3} = 1 + 0 + 1 + 0 = 2$

Но нам нужен общий вес, а не количество. Для его получения можно просто умножить каждую переменную решения на весовой параметр. Поскольку переменная решения принимает значение 0, если ей не присвоен вес, то этот вес обнуляется и не включается в общий. Допустим, веса для грузов с первого по четвертый - 10, 50, 25 и 5. Тогда общий вес в ULD 3 будет таким:

$g_1x_{1,3} + g_2x_{2,3} + g_3x_{3,3} + g4x_{4,3} = (10)(1) + (50)(0) + (25)(1) + (5)(0) = 10 + 25 = 35$

Давайте выпишем этот расчет общего веса в общем виде. Определим общий вес ULD $inline$ как $inline$ . Тогда $y_1=g_1x_{1,1}+g_2x_{2,1}+ … + g_ix_{i, 1}$ , и $y_2=g_1x_{1,2}+g_2x_{2,2} +…+ g_ix_{i, 2}$ . Мы можем свернуть это, используя нотацию суммирования $y_1 = \sum g_ix_{i, 1}$ и $y_2=\sum g_ix_{i, 2}$ . Поскольку мы хотим, чтобы это было верно для всех возможных $inline$ , мы используем знак «для всех»: $\forall$ . Это дает нам конечную форму нашего ограничения общего веса:

$y_j=\sum_{i \in I}g_ix_{i,j} \forall j \in J$

Дополнительный вес

Теперь, когда у нас есть общий вес, мы можем применить нашу формулу для дополнительной нагрузки:

$y_j^E = y_j-U_j^P \quad \forall j \in J$

Например, если $inline$ и and $inline$ , то дополнительный вес $inline$ килограммов. Умножим это на коэффициент соимости, чтобы получить результат в долларах. На первый взгляд это может показаться достаточным, но как насчет случая, когда общий вес всего груза для ULD не превышает стандартный вес? В этом случае, если бы мы использовали формулу «как есть», то вес перегрузки был бы отрицательным числом. Например, если стандартный вес составляет 1650 килограммов, а общий присвоенный - 1000 килограммов, то перегрузка = 1000–1650 = -650. Целевая функция умножит это число на коэффициент для перегрузок и мы получим отрицательное число. Как если бы перевозчик платил нам за доставку меньше стоимости стандартного веса.

Вот, чего мы действительно хотим: $\text{max}(y_j^E, 0)$ .
Это то же самое, что просто установить 0 для переменной, что так же просто, как создать ограничение $inline$ .

$y_j^E >= y_j - U_j^P \quad \forall j \in J$ , $y_j^E >= 0 \quad \forall j \in J$

Итак, мы реализовали функцию max() в математическом программировании: a = max (b, c), то есть a >= b && a >= c. Давайте посмотрим на наши определения.
Целевая функция: $\text{min} \sum_{j} y^E_j c^E_j$
$inline$ : Коэффициент перегрузки ULD $inline$
$inline$ : Перегрузка ULD $inline$ ; $inline$
$inline$ : Стандартный вес ULD $inline$
$inline$ : Вес отгрузки брутто $inline$
$x_{i, j}$ : переменная решения; $x_{i, j}=1$ , если отгрузка $inline$ назначена ULD $inline$ , $inline$ в противном случае.
$inline$ : общий вес всех грузов, назначенных ULD $inline$ ; $y_j=\sum_{i \in I}g_ix_{i,j} \quad \forall j \in J$

Каждый груз должен лететь

На этом этапе мы могли бы написать это на Python и отправить его решателю. Если бы мы это сделали, то обнаружили бы, что решатель назначил нулевые поставки любому рейсу, и мы можем быстро понять почему: лучший способ минимизировать целевую функцию - не накапливать никаких затрат. Это приводит к следующему ограничению: каждая партия должна быть назначена какому-то ULD. Мы распространим это на каждый груз, который должен быть назначен одному и только одному ULD, хотя в действительности мы можем разделить груз на несколько ULD и даже на несколько рейсов.

Это означает, что $x_{i, j}$ может равняться только 1 для одного значения $j$. Например, если мы рассматриваем отгрузку 13, то $x_{13,1}+x_{13,2}+ x_{13,3}+ … + x_{13, J}=1$ . Мы хотим применить это ограничение для каждой отгрузки $inline$ (которую мы записываем как $\forall i\in I$ ), и мы можем свернуть сложение с помощью оператора суммирования ( $\sum$ ), поэтому наше окончательное ограничение:

$\sum_{j \in J} x_{i, j}=1\quad\forall i \in I$

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

Ограничения объема и веса

Давайте определимся $inline$ , как максимальную грузоподъемность в килограммах ULD $inline$ и $inline$ как максимальный объем в кубических метрах ULD $inline$ . Давайте все же определимся $inline$ , а объем в кубических метрах груза $inline$ . Для ограничения модели максимальной грузоподъемностью и максимальным объемом, у нас есть условия:

$y_j<=U_j^M \quad \forall j \in J$

$\sum_{i \in I} x_{i,j} v_ i <= U_j^V \quad \forall j \in J$

Ветеран отрасли сразу же поймет, что это не соответствует действительности. Почему? Потому что эти ограничения рассматривают груз так, как будто его можно вылить, как воду, в любой объем. В реальности грузы жесткие или имеют другие ограничения, например, по укладке. 10 кубических метров груза не могут быть упакованы в произвольный объем, равный именно 10 кубическим метрам. Чтобы справиться с этими случаями, нужно решить задачу об упаковке в контейнеры. Мы проверяем, поместятся ли определенные объемы внутри других, но это выходит за рамки данной статьи.

Теперь решатель назначает отгрузки ULD, соблюдая максимальный вес и объем при минимизации общей стоимости. Но есть еще одна проблема: мы ничего не сказали о назначении отправлений и о соблюдении сроков доставки. На самом деле существует четыре метки времени, которые необходимо учитывать при назначении отгрузки:

Время, когда отгрузка фактически готова к консолидации с другими отгрузками в ULD и загрузке на рейс. Давайте используем $inline$ , чтобы представить время готовности отгрузки $inline$ .
Время, к которому груз должен быть выгружен в пункте назначения, деконсолидирован и доступен для получения, как правило, из грузового терминала. Давайте используем $Q_i^+$ для представления крайнего срока поставки отгрузки $inline$ .
Время, к которому весь груз должен быть доставлен в грузовой терминал для погрузки на рейс. Давайте используем $inline$ для представления времени отсечения груза ULD $j$.
Время прибытия рейса: это время, к которому груз на рейсе становится доступным для получения на складе назначения. Давайте используем $inline$ для представления времени прибытия рейса ULD $inline$

Источник и назначение

Введем еще один набор $inline$ , который мы определим как набор рейсов, чей источник и назначение совпадает с отправлением и получением груза $inline$ . Другими словами, если отправление 85 имеет происхождение из Гонконга и пункт назначения в Лондоне, то $J_{85}$ - это набор всех ULD с отправлением из Гонконга и пунктом назначения в Лондоне.
Теперь мы можем использовать $j \in J_i$ для получения набора ULD, который совпадает с торговым путем отгрузки $inline$ , или мы можем использовать $j \notin J_i$ для получения набора ULD, который не совпадает. Чтобы запретить привязку груза к ULD, который не соответствует его источнику и назначению, просто ограничим $x_{i,j} = 0$ для всех таких рейсов. Ограничение полностью описывается так:

$\sum_{j \notin J_i} x_{i,j}=0 \quad \forall i \in I$

Сроки поставки

При работе с временными метками в оптимизации удобно представлять нужные моменты как время Unix. Плюсы подхода:

Хранение дат как чисел.
Не нужно обрабатывать часовые пояса.
Решатель использует прямые сравнения «больше-меньше».

Рейс должен прибыть до срока доставки груза:
$\sum_{j \in J_i}T_j^+x_{i,j}<=Q_i^+ \quad \forall i \in I \quad$
Обратите внимание, что так же, как и для вышеприведенное ограничение по отправлению и назначению, мы указали, что это ограничение действует только для ULD в наборе $inline$ , где $inline$ - это набор ULD, которые совпадают с отправлением и получением отгрузки $inline$ . Вот и все! Посмотрим на всю модель.

Полная модель

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

Параметры

$inline$ : Набор всех отправлений. Одна отправка представлена $inline$
$inline$ : Набор всех ULD. Индивидуальный ULD представлен в нижнем регистре $inline$ .
$inline$ : Набор всех ULD, которые совпадают с отправителем и получателем груза $inline$ .
$inline$ : Вес брутто отгрузки $inline$ в килограммах.
$inline$ : Объем в кубических метрах отгрузки $inline$
$inline$ : Коэффициент перегрузки ULD $inline$ в долларах США за килограмм
$inline$ : Максимальная весовая вместимость ULD $inline$ в килограммах
$inline$ : Максимальная объемная мощность ULD $inline$ в кубических метрах
$inline$ : Стандартный вес ULD $inline$ в килограммах

$inline$ : Допустимое время доставки к терминалу ULD $inline$ .
$inline$ : Время прибытия ULD $inline$ .
$inline$ : Время готовности к отгрузке $inline$ .
$inline$ : Срок доставки $inline$ .

Переменные решения и целевая функция:
$inline$ : Общий вес по ULD $inline$
$inline$ : Перегрузка ULD $inline$ в килограммах.
$x_{i,j}$ : 1 если отправка $inline$ назначена ULD $inline$ , 0 в противном случае.

Целевая функция

$\text{Minimize} \sum y_j^Ec_j^E$

Ограничения

$inline$ - общий вес отправлений по ULD $j$: $y_j=\sum_{i \in I} g_ix_{i,j} \quad \forall j \in J$
Дополнительный вес jE это max(0, yj-UjP):
$y_j^E >=y_j-U_j^P \quad \forall j \in J$
$y_j^E >=0 \quad \forall j \in J$
Каждая поставка должна быть назначена ровно на 1 ULD: $\sum_{j \in J} x_{i,j}=1 \quad \forall i \in I$ .
ULD $inline$ не может превышать максимальный вес: $y_j<=U_j^M \quad \forall j \in J$
ULD $inline$ не может превышать максимальную вместимость: $\sum_{i \in I}x_{i,j}v_i <= U_j^V \quad \forall j \in J$

Дальнейшие шаги

В этой статье описывается математическое программирование, лежащее в основе назначения груза полету. Но просто записать математику недостаточно. Следующий шаг - реализация программы, вероятно, в AML, как Pyomo, или с использованием собственного API решателя, например, Python API Gurobi. После этого разработчик напишет код для передачи параметров всех доступных отправлений и рейсов. Затем экземпляр модели отправляется решателю. Решатель установит значения переменных решения оптимальным образом. Затем разработчик должен что-то сделать со значениями переменных принятия решений.

Задача о доставке грузов