Автоматизация склада: борьба за независимость

Автоматизация в промышленности: Автоматизация складских процессов остается одной из самых востребованных задач. До недавнего времени многие разработчики предлагали свою продукцию единым пакетом, объединяющим аппаратное и программное обеспечение — как «решение под ключ». При таком подходе ПО либо разрабатывается собственными IT-отделами поставщика, либо предоставляется партнерской компанией. В большинстве случаев это привело к тому, что аппаратное оснащение склада может работать только с определенным софтом от того же поставщика. В итоге, все это ставит клиента в зависимость от конкретных решений. Недостатки такого подхода российские компании смогли прочувствовать на собственном опыте, когда многие устройства стали недоступны, а поставщики ушли с рынка.

Зависимое положение не устраивает не только владельцев склада – и не только в России. Ведь рынок уже поделен, все ниши заняты, а крупные компании давно нашли себе партнеров. У многих клиентов установлены автоматизированные складские системы от конкретного поставщика, и работать они могут только с его же оборудованием. Поэтому, например, новым игрокам на рынке складской автоматизации зачастую непросто найти партнеров и клиентов.

Возможный выход из этой непростой ситуации — рассмотрение системы управления складом как некой многослойной модульной структуры, состоящей из независимых блоков — например, WMS и MFC могут быть от различных производителей.

Такой подход позволяет компаниям, специализирующимся в конкретных областях, предлагать свою продукцию как отдельные блоки, которые можно интегрировать с любым ПО и оборудованием от разных поставщиков.

Однако, интеграция различных программных продуктов как между собой, так и с оборудованием требует дополнительных усилий, поскольку программные интерфейсы без дополнительной настройки в большинстве случаев несовместимы между собой. Эффективным решением задачи такой интеграции является разработка промежуточного слоя, так называемого middleware, который содержит адаптеры к интерфейсам всех стыкуемых систем и таким образом позволяет не делать интеграцию «с нуля» для каждого конкретного внедрения. Созданием такого программного продукта целесообразно заниматься третьей стороне — компании, которая не зависит от конкретных поставщиков складских решений.

ПО должно давать возможность интегрировать друг с другом максимально широкий круг решений, а его создание не должно требовать детальных знаний о том, как работает конкретное оборудование.

Звучит красиво? И это не фантастика! Мы уже имеем опыт создания таких проектов.

Пример 1

Компания, занимающаяся производством систем дистанционного управления механизированной техникой, хочет использовать свои разработки для складской логистики, а именно — для управления складскими погрузчиками.

Для реализации такого проекта требуется не только установить необходимое программное и аппаратное обеспечение на технику внутри склада, но и «подружить» их с автоматизированной системой управления складом. Компании хотелось не ограничивать применение своих решений какими-то условиями или конкретной WMS-системой, а наоборот — сделать их применение максимально широким.
Кроме того, так как оператор работает удаленно, то необходимо было обеспечить непрерывную передачу данных между ним и WMS.

Ознакомившись с самой системой дистанционного управления и проанализировав потребность клиента, мы поняли, как интегрировать данное решение с автоматизированной системой склада. Для этого требовалось разработать некий программный адаптер (middleware), содержащий в себе два блока.

Первый блок программного решения работает с интерфейсом системы управления и выводит на удаленный экран водителя информацию из WMS. Этот блок универсален и не зависит от типа WMS-системы, установленной на складе.

Второй блок, наоборот, создается под конкретную WMS. Его задача заключается в том, чтобы получить данные от системы управления погрузчиком и перевести их в код нужного для WMS формата. Информация должна фиксироваться на каждом этапе и передаваться в WMS. Например, конкретный оператор обрабатывает соответствующий заказ — WMS-система должна зафиксировать все этапы выполнения (с какой полки взята какая коробка и т. п.), отметить факт завершения заказа и какой исполнитель им занимался.

Компания «Формат кода» разработала решение для интеграции программного продукта заказчика с различными системами WMS. Благодаря этому каждое новое внедрение требовало лишь настройки, либо доработки адаптеров под интерфейсы новой системы WMS, в то время как основная модель передаваемых между системами данных оставалась неизменной.

Пример 2

Компания, выпускающая автоматизированные складские погрузчики, хотела, чтобы ее техника могла работать с максимальным количеством различных WMS-систем.
Компания производит разные типы погрузчиков, различающиеся своим функционалом и способностью выполнять соответствующие функции. Всех их объединяет одно — погрузчики перемещаются по RFID-меткам и выполняют ограниченное количество операций (направо-налево, вилы вверх-вилы вниз и т. п.). Информация о выполненных операциях должна передаваться в WMS-систему управления складом.

Внутри погрузчика находится оператор, базовые функции которого сведены к контролю. Однако в случае возникновения непредвиденной ситуации он может перехватить управление, а также отправить сообщение в WMS (например, когда паллеты нет, она сломана, паллета не та и т. п.).

Требовалось, чтобы программное решение обеспечивало непрерывную коммуникацию между автоматизированным погрузчиком и WMS, но при этом передаваемая информация была понятна человеку.

Решением здесь стало создание программного адаптера (middleware), переводящего информацию от WMS к погрузчику и обратно. ПО принимает данные о заказе от WMS (некие логические координаты — зона, секция и т. п.) и переводит в код, понятный и автоматическому устройству, и человеку. Получив физические координаты от погрузчика, софт переводит данные в нужный формат для WMS-системы. Такой подход позволяет без вникания во внутреннюю логику устройства самого погрузчика сонастроить его с любой WMS.

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

В двух разных ситуациях создание дополнительного программного адаптера (middleware) позволило достичь поставленных задач и выполнить пожелание заказчика.

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