Getting started

Introduction

Instock ASRS aims to be a transparent, simple, and efficient machine to store, move, and sort bins with inventory for fulfillment operators. A single physical installation of Instock ASRS will be referenced as site in this guide.

Actors

There are four major actors involved in the activity of each site:

• Host system – a part of IT system owned by your organization, that connects to Instock
• Incloud – Instock Cloud – a centralized cloud-based software managing all ASRSs and interfaces to Host system
• Squad – robots working within a grid in tandem with network equipment
• Associates – your personnel at fulfillment site

Instock assumes there is one organization responsible for each site, and a single organization can manage multiple sites. Associates and other users will typically have access to one organization account within Incloud.

Incloud proxies all interactions of ASRS to its users, namely:

• Incloud connects via API to the Host system (and its subsystems such as PIM, WMS, IMS, OMS)
• Incloud provides web-based user interfaces running on workstations of ASRS for Associates’ interaction with ASRS (picking, decanting)
• Incloud provides web-based UIs for visibility of ASRS products, inventory, orders

Associates interact with the System primarily at workstations, sending signals to Incloud about task status via the touchscreen and push-to-light buttons. System refers to a combination of Incloud and the ASRS when it comes to Associate interactions. Under Standard Operating Procedures (SOPs), Associates interact directly with robots only when the robots are physically introduced into or taken out of the System and during on-demand maintenance.

A Squad of robots connects securely to Incloud through the ISP available at your site. The Squad together with network equipment are the only active (having processor/memory) components of ASRS, and therefore we use terms Squad, robots and ASRS interchangeably in this guide when it comes to behavior and actors.

Incloud and the ASRS handle the allocation of bins to storage positions. Storage capacity and inventory are both available in real-time to the Host systems through API and to site managers through Incloud web interfaces.

Both API and UI of Incloud have organization and site as two key variables defining the context of every operation. In other words, all user actions and views are applied to the site currently in focus. Most of the fulfillment variables are also applicable within the context of a site.

Lifecycle

Before diving into specific processes of the ASRS, it’s helpful to have a high-level understanding of a site’s lifecycle:

• site model is created and simulated in a sandbox
• grid is physically installed, grid is initially empty
• robots are introduced into the grid
• empty bins are inserted into the grid at workstations via empty bin reception process
• products are received into a building hosting the site and Host system makes a record of such receiving
• products are decanted into ASRS at workstations via decanting process
• products are picked for customer orders at workstations via picking process
• inventory levels go up and down as picking and decanting continue
• ASRS storage capacity is optimized from time-to-time via consolidation and defragmentation processes

Once bins are inserted into the ASRS they should not be taken out unless through empty bin extraction mode at workstations.

If a site is decommissioned or moved to another location:

• all products are picked out of the grid to nullify inventory
• empty bins are taken out of the grid via empty bin extraction mode
• robots are asked to exit the grid
• site can be turned off and disassembled.

Incloud API

Host system connects to Instock through APIs. API end-points are organized into three groups:

• PIM (Product Information Management) – host system posts data records for products to be picked from ASRS. If there is an ambiguity around assortment to be stored and picked from ASRS, consider posting all available product records. There is no downside from posting records that might not be used, while there is an inconvenience from not having a record at the moment of product induction (Incloud UI will not accept unknown product for decanting at workstation). Having multiple product records with zero inventory is not a burden for Incloud.
• IMS (Inventory Management System) – under normal Internet connectivity between the site and Incloud, movements of inventory are registered by Incloud with a delay of 5-10 seconds after the move is completed. Host IMS can request a slice of movements or inventory position of ASRS via API at any moment.
• OMS (Order Management System) – Host system posts orders for picking and reads statuses of their fulfillment.

See API reference for more details.