Основний посібник з оптимізації території та алгоритмів укладання контейнерів | Частина 2 серії "Створення розумних контейнерних терміналів".
Кожен, хто грав у Tetris, розуміє основну задачу управління контейнерним двором: ефективне розміщення елементів, враховуючи майбутні рухи. Але на відміну від Tetris, операції контейнерного терміналу включають кілька конкурентних цілей, складні обмеження та реальні наслідки, де помилки можуть коштувати мільйони.
Розуміння головоломки контейнерного терміналу
Уявіть собі величезну шахову дошку, де кожен хід впливає не тільки на поточний стан, але й має наслідки для майбутніх операцій. Контейнерний термінал зазвичай обробляє сотні або тисячі контейнерів щодня, кожен з яких має свої вимоги:
- Контейнер з охолоджувачем довжиною 40 футів потребує постійного джерела живлення
- Контейнер з небезпечними товарами вимагає спеціальних зон безпеки
- Контейнер, що відправляється завтра, повинен бути доступнішим, ніж той, що відправляється наступного тижня
Складність зростає експоненційно, якщо врахувати, що типовий двір може мати:
- Більше 50,000 місць для контейнерів
- Різні типи контейнерів (стандартні, рефрижераторні, з відкритим верхом)
- Різні розклади відправлення
- Різні судноплавні компанії з пріоритетними зонами
- Обмеження за обладнанням та графіки обслуговування
Створення системи оцінювання: основа розумного укладання
Коли я почав розробляти цю систему, я зрозумів, що мені потрібно знайти спосіб систематично оцінювати можливі позиції контейнерів (позиція контейнера визначається тріадою значень: бухта, ряд та ярус). Ось значно спрощена версія того, як система оцінює позиції:
def calculate_container_position_score(container, block, position):
# Початковий бал — 0
score = 0.0
# Перевірка основних обмежень
if not is_position_valid(container, block, position):
return float('-inf')
# Оцінка розподілу ваги
stack = get_container_stack(block, position)
weight_score = calculate_container_weight_score(container, stack)
score += weight_score * WEIGHT_FACTOR
# Оцінка часу відправлення
etd_score = calculate_container_departure_score(container, stack)
score += etd_score * ETD_FACTOR
# Оптимізація відстані
distance_score = calculate_container_distance_score(container, position)
score += distance_score * DISTANCE_FACTOR
...
# Групування за судноплавною компанією
...
# Спеціальне оброблення контейнерів
...
return score
Давайте розглянемо деякі складові оцінки:
Розподіл ваги (Стійкість укладання)
Система оцінює розподіл ваги для забезпечення стабільності укладання:
- Важчі контейнери повинні бути розміщені нижче за легші
- Кожен стос має максимальну вагову ємність (зазвичай 150,000 кг)
- Визначте оптимальну різницю в вазі між контейнерами (в цьому випадку близько 30,000 кг)
- Оцінка зменшується, коли розподіл ваги стає менш ідеальним
Оптимізація часу відправлення
Оцінка ETD (очікуваний час відправлення) враховує:
- Контейнери, що відправляються раніше, повинні бути більш доступними
- Ідеальне групування має контейнерів з подібними часами відправлення
- Максимальний поріг різниці в ETD (N днів)
- Оцінка штрафує позиції, що потребують майбутнього перегрупування
Спеціальні вимоги до обробки
Система оцінювання включає спеціалізовану логіку для різних типів контейнерів:
- Рефрижераторні контейнери:
- Повинні бути поблизу точок живлення
- Максимальна відстань до джерела живлення (10 метрів в цьому випадку)
- Потрібна наявність доступної потужності для рефрижераторів у блоці
- Небезпечні вантажі:
- Для небезпечних товарів повинні бути призначені конкретні блоки
- Вимоги до розподілу між несумісними класами
-
Максимальна кількість стосів небезпечних вантажів у блоці
Контейнери високого пріоритету: -
Врахування потреб преміум-клієнтів
-
Обробка вантажів, що потребують термінового відправлення
-
Спеціальні вимоги до обробки
Ця система оцінювання є основою для розумного розміщення контейнерів, що дозволяє ефективно керувати роботою двору, одночасно забезпечуючи безпеку та виконання операційних вимог. Давайте детальніше розглянемо кожен елемент.
Розподіл ваги: основа безпеки
Розподіл ваги не полягає лише в тому, щоб ставити важкі контейнери на дно. Йдеться про створення стабільних стосів, які здатні витримувати різні умови:
def calculate_weight_score(container, stack):
"""
Обчислення оцінки на основі ваги для розміщення контейнера.
Аргументи:
container: Об'єкт контейнера з атрибутом ваги
stack: Список об'єктів контейнерів, що представляє поточний стос
Повертає:
float: Оцінка від 0 до 100
"""
if not stack:
return 100 # Ідеальна оцінка для порожнього стосу
max_stack_weight = 150000.0 # Максимальна вага 150 тонн
current_stack_weight = sum(c.weight for c in stack)
# Перевірка загального ліміту ваги
if current_stack_weight + container.weight > max_stack_weight:
return -100
# Перевірка розподілу ваги (важчі контейнери повинні бути внизу)
top_container = stack[-1]
if container.weight > top_container.weight:
return -100
# Оцінка на основі різниці ваги
weight_difference = top_container.weight - container.weight
max_weight_difference = 30000.0 # Ідеальна різниця до 30 тонн
return min(weight_difference / max_weight_difference, 100)
Невірне розміщення контейнерів може створити каскадні операційні ризики — як затримана ланцюгова реакція.
Фактор ваги в укладанні контейнерів критичний з двох основних причин:
- Стійкість стосу
- Важчі контейнери вгорі створюють небезпечний тиск вниз
- Приклад: Контейнер вагою 30 тонн на контейнері вагою 20 тонн може спричинити перекидання або обвал стосу
- Максимальна вага стосу
- Кожна позиція стосу має обмеження ваги в залежності від умов на землі
- Приклад: Типове обмеження стосу — 150 тонн
- Перевищення цього ліміту може пошкодити покриття двору або спричинити осідання
Управління часом: мистецтво доступності
У контейнерних терміналах кожен контейнер має запланований час відправлення, і ефективність роботи двору залежить велику міру від того, як система керує цими часовими обмеженнями.
Часова проблема
Розглянемо стос контейнерів з такими часами відправлення:
- Знизу: Відправляється завтра
- Середина: Відправляється через 2 дні
- Вершина: Відправляється через 5 днів
Це вимагає двох переміщень — спочатку переміщення верхнього контейнера, потім середнього, щоб отримати доступ до контейнера внизу. Кожне переміщення:
- Триває кілька хвилин часу крана
- Містить витрати на операційні витрати
- Збільшує ризик пошкоджень або затримок
- Впливає на продуктивність терміналу
Оптимізація часу відправлення
Система оцінювання оцінює тимчасову доступність, використовуючи кілька факторів:
def calculate_container_departure_score(container, stack):
"""
Оцінка доступності на основі часу відправлення.
Аргументи:
container: Контейнер, який потрібно розмістити
stack: Існуючий стос контейнерів
Повертає:
float: Оцінка від 0 (погано) до 100 (оптимально)
"""
if not stack:
return 100 # Позиція на землі ідеальна
# Обчислення часових конфліктів
conflicts = 0
weighted_conflicts = 0
for existing_container in stack:
if existing_container.departure_time > container.departure_time:
conflicts += 1
# Вагові конфлікти за різницею часу
time_diff = (existing_container.departure_time -
container.departure_time).days
weighted_conflicts += conflicts * (1 + (time_diff / 7))
# Штраф на основі:
# 1. Кількості конфліктів
# 2. Різниці часу
# 3. Позиції в стосі
base_penalty = ...
time_penalty = ...
return max(0, 100 - base_penalty - time_penalty)
Обмеження чистих евристик
Хоча ця система оцінювання дала хорошу основу, я швидко зрозумів її обмеження:
Статичність проти динамічної реальності
Як і алгоритм шахів, який враховує лише поточний стан дошки, цей алгоритм не міг передбачити виникаючі чи сталеві патерни.
Людський фактор
Оператори терміналів часто приймають рішення на основі досвіду та інтуїції, які важко кількісно оцінити. Цей тип знань не так просто вловити в статичних правилах.
Обчислювальна складність
Якщо розмір двору збільшується, кількість можливих позицій зростає значно. Для кожного контейнера потрібно оцінити:
- Кілька блоків
- Кілька позицій у кожному блоці
- Кілька конфігурацій стосів
- Кілька часових горизонтів
Погляд у майбутнє: від правил до інтелекту
Ці обмеження вказали мені на необхідність більш складних рішень. У наступній статті ми розглянемо, як архітектура, орієнтована на події, дозволяє здійснювати оптимізацію в реальному часі. Наприкінці цієї серії ми побачимо, як сучасні операції терміналів потребують системи, яка здатна:
- Вчитися на історичних даних
- Адаптуватися до змінних патернів
- Передбачати майбутні стани двору
- Динамічно балансувати кілька цілей
Подорож від основних евристик до інтелектуальної оптимізації лише починається, але розуміння цих основ є ключовим для створення більш складних рішень.
Це стаття 2 серії "Створення розумного контейнерного термінала: від евристик до ШІ". Для додаткової інформації прочитайте вступ тут.
Перекладено з: Container Yard Optimization Basics: Building the Foundation