Рисунок 2. Циклограмма наследования,
выстроенная через открытые библиотеки PHP [13].
Во-первых, подыскивается подходящее свободное место для хранения, при этом необходимо учитывать особые требования к хранению (например, для охлажденных товаров или опасных грузов) или специально отведенные места для хранения. Эта информация содержится в основных данных материала и необходима для принятия решения о том, подходит ли место склада. Свойства склада (грузоподъемность, размеры и т. д.) из основных данных склада сравниваются с требованиями LE на основе информации о месте хранения выбирается и резервируется одно из доступных мест хранения, чтобы -гарантировать, что это место хранения не будет передано кому либо другому. Для этого требуется доступ на запись к информации о месте хранения [4, c. 141144].
Затем создается заказ на транспортировку для выполнения складирования. Отдельные этапы процесса перевозки контролируются путем идентификации погрузочной единицы и отсека для хранения. После завершения приемки на склад LE переносится на новое место хранения путем обновления информации о месте хранения. В течение периода хранения условия хранения контролируются: датчики фиксируют условия окружающей среды, такие как температура на складе глубокой заморозки, и обеспечивают соблюдение
установленных предельных значений. Условия окружающей среды обычно определяются независимо от хранящихся товаров и не адаптируются динамически к содержимому склада. Кроме того, контролируется количество запасов, при этом покупатель получает уведомление, если отчетный запас падает ниже прописанного количества, что позволяет своевременно разместить повторный заказ. Для этого мониторинга требуется доступ для чтения к данным запасов и основным данным материалов, в которых хранятся отчетные запасы.
Рисунок 3. Алгоритм наследования создаваемых API [11].
Процесс отпуска материала инициируется внешним заказом, например, заказом на отгрузку или заказом на пополнение запасов. Во-первых, необходимый товар должен быть найден на складе, что требует доступа на чтение данных инвентаризации. Если искомый товар имеется на складе несколько раз, выбор осуществляется в соответствии со стратегией работы склада. Помимо правил, связанных с товарами (таких как «первым поступило -- первым отправлено» или «первым истек срок годности -- первым отправлено»), также могут быть приняты во внимание такие факторы, как транспортные расходы. Выбранный LE зарезервирован, и создается приказ об удалении. После удаления со склада движение запасов фиксируется путем обновления информации о месте хранения. При передаче товара на отгрузку проводится проводка запасов со склада и соответствующие данные запасов удаляются, для этого также можно использовать фреймворк Eventuate Tram Saga. Хранение данных относится к постоянному хранению информации на носителях данных [5, c. 174].
Одной из возможных проблем может стать количество исходных значений, которые будут перегружать код. Однако предложенный алгоритм сбора данных предполагает, что каждая переменная, обозначающая конкретный товар, будет вызываться лишь в случае либо пополнения ячейки, либо уменьшения количества товара в ней. В примерах, рассмотренных выше, контроль осуществлялся благодаря облачному хранению, что снижает затраты на центральный алгоритм.
В системе управления складом могут встречаться разные типы данных, и для каждого из этих типов данных могут использоваться разные концепции хранения данных, будь то централизованные или децентрализованные. В контексте этого текста под хранением данных понимается хранение основного экземпляра набора данных. Важно отметить, что простой копии записи или идентификатора, указывающего на запись (например, в центральной базе данных), недостаточно.
Следует отметить, что, согласно этому определению, наличие активной вычислительной единицы не является обязательным условием локального хранения данных. Данные также могут храниться на пассивных транспондерах RFID или простых носителях данных, таких как дискеты или USB-накопители, при условии, что носитель данных допускает перезапись. Когда дело доходит до децентрализованного хранения данных, необходимо учитывать особенности PHP. Это означает, что согласованность, доступность и устойчивость к разделению не могут быть достигнуты одновременно. В контексте децентрализованного управления складом это означает, что в случае сбоя связи с самоуправляемой складской зоной информация об имеющихся на ней запасах либо перестанет быть доступной, либо вам придется продолжать работу с копиями, которые могут быть неактивны. В таком случае, созданная система воплощает политику разрозненных кусков бизнес функциональности, которые собираются вместе в случае запроса посредством централизованного UI, программы складского управления, реализующей данный принцип [6, c. 24].
3. Оптимизация складских операций.
Данные внешних заказов (заказы, объявления о доставке и т. д.) возникают вне зоны ответственности системы управления складом и запускают процессы на складе. Данные заказа, такие как позиции заказа или адрес доставки, необходимы для управления этими процессами. Эти данные могут храниться непосредственно на затронутых устройствах хранения. Для входящей поставки (поступления товара) эти данные должны быть доступны по прибытии и предоставлены поставщиком. Но в случае заказов или заказов на отгрузку сначала необходимо идентифицировать затронутые единицы хранения и передать им данные заказа. В этом случае данные о накопителях можно будет использовать для контроля и наблюдения за последующими процессами.
Данные внутренних заказов, такие как заказы на хранение и поиск, заказы на транспортировку и заказы на комплектацию, используются для выполнения внешних заказов или для реализации внутренних складских процессов (например, перемещения в складскую организацию, заказы на пополнение). Заказы на хранение могут быть записаны непосредственно в единицы складирования, чтобы передать транспортному средству назначение транспортировки. С другой стороны, заказ на аутсорсинг сначала должен быть передан в хранимое подразделение. Информацию о месте посадки придется передавать транспортным средствам другим способом. Транспортному средству в любом случае необходимо управлять этой информацией, чтобы знать пункт назначения, поэтому имеет смысл хранить весь заказ на самом транспортном средстве.
Сохранение основных данных материалов, релевантных для склада, на самих товарах дает то преимущество, что информацию о товарах можно считывать даже при отсутствии центрального органа. Если одни и те же материалы доступны несколько раз в разных единицах складирования на складе, соответствующие основные данные материала также должны быть доступны несколько раз в соответствующих единицах складирования, складах или зонах хранения (избыточность). Чтобы избежать несоответствий, следует убедиться, что каждый узел имеет текущую запись основных данных, но только тогда, когда она действительно предназначена для использования. Прежде чем использовать набор основных данных, вы можете проверить, актуален ли он. Однако существует риск несоответствий из-за неправильного многократного создания записей основных данных для одного и того же материала, аналогично центральному хранению данных.
Одним из вариантов автоматического сбора данных являются активные или полуактивные PHP протоколы (метки) UHF в сочетании с одной или несколькими стационарными антеннами. Активные транспондеры характеризуются большой, часто перезаписываемой памятью объемом до нескольких мегабайт и большим диапазоном считывания. Протоколы PHP можно считывать без прямого визуального контакта, что позволяет одновременно обнаруживать несколько транспондеров с помощью одного процесса считывания, известного как массовое обнаружение. Это может сэкономить время, например, при получении товара. Преимущество массового захвата увеличивается с увеличением количества считываемых тегов. Однако из- за высокой стоимости активные транспондеры можно прикрепить лишь к небольшому количеству (обычно высококачественных) изделий. Активные и полуактивные протоколы также могут быть оснащены внешними датчиками, например, датчиками температуры, для регистрации изменения температуры во время транспортировки. Эту информацию можно оценить при обеспечении качества [10, c. 148-164].
Активные протоколы также можно использовать для контроля условий хранения. Если измеренные значения выходят за пределы допустимого диапазона, транспондеры выдают соответствующий сигнал тревоги в среде хранения через подключенные датчики. Эти возможности становятся возможными благодаря собственному источнику питания, либо от батарей, либо от подключения к сети. В полуактивных транспондерах дополнительный источник питания используется только для поддержания энергонезависимой памяти и работы датчиков. Если используется несколько протоколов обнаружения, метки все равно записываются в разных местах. Поэтому желательно синхронизировать зоны хранения и чтения данных считывателей с децентрализованным управлением складом, чтобы материалы и информация были доступны в одном и том же месте.
Другой вариант сбора данных -- использование RFID-ворот и пассивных меток. Из-за отсутствия стабильного и достаточно мощного источника питания к пассивным меткам невозможно подключить дополнительные датчики. Радиус действия транспондеров зависит от полосы частот и условий окружающей среды. По сравнению с низкочастотными метками передача данных в PHP протоколах происходит быстрее. Поэтому требуются более мощные антенны, чем в активных системах. Обратите внимание, что низкочастотные транспондеры -- единственные транспондеры, которые нельзя использовать в системах массового обнаружения. Когда товары поступают на хранение, они сначала идентифицируются, и соответствующая информация о товарах, такая как тип продукта, размеры и вес, сохраняется в заказе на хранение. Эти заказы на размещение, которые еще не были обработаны, могут быть запрошены сотрудниками через узлы ввода-вывода и отображены на этих устройствах.
После выбора заказа его статус меняется с «открыто» на «в работе». Это изменение состояния синхронизируется службой каталогов на всех других узлах ввода-вывода, чтобы предотвратить одновременное редактирование двумя пользователями одного и того же задания [7, c. 18].
Как только сотрудник выбирает заказ на размещение, запрос на размещение отправляется всем активным узлам складской зоны вместе с ранее сохраненной информацией о товаре. Они проверяют, могут ли они принять рассматриваемый товар. Сюда входит проверка наличия достаточного свободного места, утверждение типа продукции для хранения на складе и соблюдение максимальных размеров хранения. Проверка заканчивается отправкой подтверждения или отклонения запрашивающему узлу ввода-вывода на хранение. Если получено подтверждение, на запрашивающий компьютер также отправляется информация о подходящем месте хранения. Узлы, фиксирующие хранилище, не будут принимать дальнейшие запросы в течение ограниченного времени, чтобы избежать возможных конфликтов при резервировании места для хранения. Однако эта остановка запроса будет отменена самое позднее после получения ответа от запрашивающего узла.
Когда отправленные сообщения достигают запрашивающего узла ввода- вывода, он выбирает один из полученных обещаний. Результат выбора отправляется обратно отправителям промисов. Выбранный узел складской зоны затем резервирует соответствующее место хранения для новых запросов на размещение. Затем этот узел отправляет подтверждение резервирования запрашивающему узлу ввода-вывода. Получив это подтверждение, узел ввода- вывода обновляет место хранения в порядке хранения и отображает результат пользователю. Затем товары транспортируются в соответствующее место хранения и хранятся. Приемка на склад завершается подтверждением приемки на узел склада, который обновляет свой инвентарный список хранящимися товарами и отменяет резервирование места хранения.
Для поиска сохраненного продукта пользователь вводит нужные атрибуты продукта на узле ввода-вывода и отправляет их всем узлам, запрошенным из службы каталогов. Узлы ищут товары, соответствующие указанным атрибутам, и отправляют список результатов поиска исходному узлу ввода-вывода. Результаты поиска из различных узлов области хранения объединяются, сортируются и отображаются пользователю. Эта последовательность операций работает аналогично для запасов, при этом поиск ведется не по конкретным атрибутам товара, а по всем товарам, имеющимся на складе. Полученные результаты поиска можно использовать, например, для составления заказов клиентов. Здесь узел ввода-вывода отправляет запрос на удаление товара с искомыми атрибутами во все узлы складской зоны. Они проверяют, возможен ли аутсорсинг в зоне их ответственности, и отправляют соответствующий ответ обратно на узел ввода-вывода. Подобно процессу заказа на размещение, описанному ранее, узлы складской зоны, которые зафиксировали, не будут принимать другие конкурирующие запросы в течение определенного периода времени. Узел ввода-вывода выбирает вариант на основе всех полученных ответов и отправляет результат своего выбора (утверждение или отклонение) обратно в соответствующие узлы области хранения. Когда узел зоны хранения получает одобрение, он резервирует товары для вывоза. Это резервирование отправляется обратно в качестве подтверждения на узел ввода- вывода, который затем обновляет заказ на аутсорсинг, указав конкретные сведения о товарах, подлежащих аутсорсингу, и пункте назначения. Результат этого обновления отображается пользователю на экране [8, c. 251-273].
Принятие исходящего заказа происходит таким же образом, как описано для входящих заказов. Если товар вывезен успешно, сотрудник подтверждает это, отправляя подтверждение вывоза ответственному узлу склада через узел ввода-вывода. Затем он обновляет список инвентаря. Узел ввода-вывода помечает состояние задания разгрузки как завершенное и сообщает об этом обновленном состоянии службе каталогов. Как только сообщение о завершенном задании достигает службы каталогов, она обновляет список заданий на всех остальных узлах ввода-вывода в соответствии со своим собственным списком заданий. Реализация распределенной системы требует больше усилий, чем центральных систем, из-за интенсивного общения между участниками сети. Это особенно актуально для операций запроса, которые отправляются посредством широковещательной рассылки и ответы, на которые необходимо обработать позже. Синхронизация таких данных, как основные данные или данные заказа, увеличивает сложность. Такие помехи, как задержка, дрожание и шум, могут повлиять на сетевую связь и привести к задержкам или отсутствию ответов. Эти сбои могут быть вызваны помехами, коллизиями сообщений и ограниченной полосой пропускания [9, c. 1].