Warehouse OS Abstraction Layer for Flexible ASRS Integration

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

The integration of Warehouse Management Systems (WMS) with automated storage and retrieval systems is costly, time-consuming, and inflexible, with hard-coded integrations leading to high risks of errors and difficulties in modifying material flow handling processes, and the need for tailored parameters results in a combinatorial explosion of variants that are impossible to test effectively.

Innovation Solution

An operating system that translates orders from the WMS into tasks using an abstraction layer, eliminating the need for hard-coded integrations by providing a constrained set of abstractions and device driver managers to manage hardware components, allowing compatibility and flexibility in hardware selection and upgrade.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If hard-coded integration is used between WMS and automated storage and retrieval system, then integration stability is improved, but adaptability and ease of modification deteriorate

Engineering Contradiction:

Improveintegration stabilityVSAvoidease of modification

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The integration architecture is segmented into distinct layers: the WMS layer, the operating system layer with abstraction interfaces, and the hardware component layer. This segmentation allows the WMS to interact with standardized interfaces rather than hard-coded integrations, enabling independent modification of each layer without affecting others. The abstraction layer acts as a stable contract that maintains reliability while allowing adaptability in underlying implementations.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

An operating system with abstraction interfaces is introduced as an intermediary between the WMS and hardware components. This intermediary layer provides stable, standardized interfaces that the WMS can rely on, while the underlying hardware and implementation details can be modified without affecting the WMS. The intermediary maintains integration stability while enabling ease of modification through its abstracted interface contract.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If parameters are used to tailor MFH process to different warehouse operators, then adaptability is improved, but system complexity and testing requirements explode combinatorially

Engineering Contradiction:

Improvetailoring capabilityVSAvoidnumber of variants

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system uses parameter changes within a constrained set of predefined parameters to tailor the MFH process to different warehouse operators. Rather than creating separate configurations for each variant, the same flexible operating system framework handles different scenarios by adjusting parameter values. This approach provides adaptability without the combinatorial explosion of variants, as the system dynamically adapts to different parameter settings rather than maintaining separate code paths for each combination.

Inventive Principle:

Principle #35Parameter changes

3Reliability

If brute-force integration is implemented, then integration completeness is improved, but integration cost and time increase

Engineering Contradiction:

Improveintegration completenessVSAvoidintegration time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The operating system implements universal, standardized abstraction interfaces that can work with multiple types of hardware components and warehouse configurations. This universality allows the same integration framework to handle diverse hardware components without requiring custom brute-force integration for each component type. The multi-functional abstraction layer provides complete integration capability across different hardware platforms while significantly reducing integration time through reuse of standardized interfaces.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentEP4645187A1Operating system for automated storage and retrieval system

Publication Date: 2025.11.05 AUTOSTORE TECH AS

Figure 1
Figure 2
Figure 3A~3B

AI summary

The disclosure relates to a computer-implemented method, comprising: receiving, via a first application programming interface of an operating system of an automated storage and retrieval system installed in a warehouse, an order; translating, by the operating system, the order received via the first application programming interface into one or more tasks to be carried out within the warehouse; identifying, by the operating system, a first hardware component suitable for carrying out a first task of the one or more tasks, wherein the first hardware component is associated with the automated storage and retrieval system; and instructing, by the operating system, a first device driver associated with the first hardware component to generate a first set of commands for the first hardware component for carrying out the first task.