AS/RS Cycle-Time Calculation: Single, Dual and Multi-Command Operating Models

Key takeaways #

• Concurrent travel is the default: Horizontal and vertical motions occur simultaneously in most AS/RS designs; the travel time is the maximum of the individual axis times, not their sum, unless the control system serializes motion.
• Single command (SC) is the baseline: One SC cycle is a single storage or retrieval mission; its time is the sum of travel to a location, transfer dwell, and travel back to the I/O point.
• Dual command (DC) doubles productivity per trip: A DC cycle combines a storage and a retrieval in one round trip, saving one return-to-I/O travel segment compared to two SC cycles.
• Multi-command extends the logic: Multi-command cycles interleave multiple storage and retrieval tasks in one SRM trip, reducing deadhead travel but adding sequencing complexity and higher risk of congestion.
• Availability is a multiplier, not an add-on: Effective throughput equals theoretical throughput multiplied by availability; a 95% available system loses 5% of its theoretical capacity before any other losses.
• Transfer dwell is often underestimated: Load pickup and setdown times (including fork extension, lift, and retraction) can account for 15–30% of total cycle time in high-density systems.
• Always validate with site data: The equations here are transparent and assumption-based; they must be calibrated against measured SRM performance, control-system logs, and actual load profiles.

Scope and objectives of this reference #

This article provides a structured method for calculating AS/RS cycle times across three operating models: single command, dual command, and multi-command. The focus is on the engineering calculation logic, with explicit treatment of concurrent horizontal/vertical travel, transfer dwell, and availability effects. We do not prescribe a specific vendor’s control algorithm or a particular mechanical configuration; instead, we present a generic, transparent framework that you can adapt to your system’s measured parameters.

The objectives are to:

• Define each operating model with a clear mission description.
• Provide equations that separate travel time, transfer dwell, and fixed overhead.
• Explain how to combine horizontal and vertical motion into a single travel-time estimate.
• Show how availability converts theoretical cycle time into effective cycle time.
• Offer a worked example with sensitivity analysis to illustrate the method.
• State the boundaries where this guidance does not apply.

This is an editorial reference from Pearl Gateway Systems, intended for automation engineers, system integrators, and operations planners. It is not a substitute for a vendor’s performance guarantee or a site-specific simulation study.

Definitions, symbols, and units #

To keep the equations readable, we use a consistent set of symbols. Every variable is defined here with its unit. We use SI units throughout, but the logic is unit-agnostic; you may convert to imperial as long as you remain consistent.

All times are in seconds unless otherwise noted. All distances are in meters. All velocities are in meters per second. Availability is a dimensionless fraction. These definitions are used consistently in every equation below.

Concurrent horizontal and vertical travel: the diagonal motion model #

An AS/RS SRM moves simultaneously in the horizontal (along the aisle) and vertical (up the mast) directions. The resulting path is a diagonal in the x-y plane. The time to reach a location (x, y) from the I/O point is not the sum of the horizontal time and the vertical time; it is the maximum of the two, assuming the SRM can accelerate and decelerate independently on each axis and that the control system commands both motions at once.

For a simple move from point A to point B, the travel time is:

t_travel(A→B) = max( t_h(A→B), t_v(A→B) )

where t_h and t_v are the times for each axis to cover its respective distance, including acceleration and deceleration. If the SRM’s control system serializes motion (moves horizontally first, then vertically), the travel time becomes the sum. However, this is a design choice, not a physical necessity. Most modern SRMs use concurrent motion to minimize cycle time.

For a single-axis move with constant acceleration a, maximum velocity v, and distance d, the time is:

t_axis(d, v, a) = d/v + v/a if d ≥ v²/a (i.e., the axis reaches full speed)

t_axis(d, v, a) = 2·sqrt(d/a) if d < v²/a (i.e., the axis never reaches full speed)

The first case is a trapezoidal velocity profile (accelerate, cruise, decelerate). The second case is a triangular profile (accelerate, immediately decelerate). These equations assume symmetric acceleration and deceleration rates, which is a common simplification. If your SRM has asymmetric rates, use the appropriate piecewise formulation.

For a mission with multiple waypoints (e.g., a dual-command cycle), the total travel time is the sum of the segment times, where each segment is computed with the max() rule:

t_travel = Σ max( t_h(segment_i), t_v(segment_i) )

This is the core of concurrent travel modeling. It is a simplification because it ignores the possibility of overlapping acceleration/deceleration curves between segments, but it is a standard and transparent approach for preliminary engineering.

Single-command (SC) cycle: definition and equation #

A single-command cycle is the simplest AS/RS mission. It consists of either a storage operation or a retrieval operation, but not both. The SRM starts at the I/O point, travels to a storage location (or retrieval location), performs a transfer dwell (deposit or extract the load), and returns to the I/O point.

The cycle time is:

t_SC = t_travel(I/O → location) + t_transfer + t_travel(location → I/O) + t_fixed

Because the SRM must return to the I/O point, the travel out and the travel back are typically equal if the location is the same. For a storage operation, the SRM travels empty to the location and returns empty after depositing the load. For a retrieval operation, the SRM travels empty to the location and returns with the load. The load presence affects acceleration and velocity due to mass, but we treat this as a calibration factor, not a first-order equation term.

If we assume the I/O point is at one end of the aisle (x=0, y=0) and the storage location is at (x, y), then:

t_SC = 2 · max( t_h(0→x), t_v(0→y) ) + t_transfer + t_fixed

This is the theoretical single-command cycle time for a single location. In practice, you average over the distribution of locations that the system actually serves. The average SC cycle time is the mean of t_SC over all storage/retrieval locations, weighted by their frequency of use.

The throughput in cycles per hour is:

N_SC = 3600 / t_SC

This is the theoretical maximum for a single SRM, assuming no waiting, no congestion, and no downtime. We adjust for availability in a later section.

Dual-command (DC) cycle: definition and equation #

A dual-command cycle combines one storage and one retrieval in a single round trip. The SRM starts at the I/O point, picks up a load for storage, travels to the storage location, deposits the load (transfer dwell), travels empty to a retrieval location, extracts a load (transfer dwell), travels back to the I/O point, and deposits the retrieved load (transfer dwell).

The cycle time is:

t_DC = t_travel(I/O → S) + t_transfer + t_travel(S → R) + t_transfer + t_travel(R → I/O) + t_transfer + t_fixed

where S is the storage location and R is the retrieval location. Note that there are three transfer dwells: one for the storage deposit, one for the retrieval extract, and one for the final deposit at the I/O point. Some systems count the I/O deposit as part of the next cycle’s pickup; be explicit about your convention to avoid double-counting.

In terms of the concurrent travel model:

t_DC = max( t_h(I/O→S), t_v(I/O→S) ) + t_transfer + max( t_h(S→R), t_v(S→R) ) + t_transfer + max( t_h(R→I/O), t_v(R→I/O) ) + t_transfer + t_fixed

The key benefit of a DC cycle is that it eliminates one return-to-I/O travel segment compared to two SC cycles. Two SC cycles require four travel segments (I/O→S, S→I/O, I/O→R, R→I/O). One DC cycle requires only three travel segments (I/O→S, S→R, R→I/O). The savings depend on the relative positions of S and R; if S and R are close, the savings are small; if they are far apart, the savings are larger.

The throughput in cycles per hour is:

N_DC = 3600 / t_DC

Each DC cycle moves two loads (one in, one out), so the load throughput is 2 × N_DC. This is why DC operation is often preferred for high-throughput systems.

Multi-command (MC) cycle: definition and equation #

A multi-command cycle extends the dual-command logic to more than two loads. The SRM performs a sequence of storage and retrieval operations in one trip, typically starting and ending at the I/O point. The sequence might be: pickup load A, store A, retrieve B, store C, retrieve D, return to I/O. The exact sequence is determined by the warehouse control system (WCS) to minimize travel time, subject to load availability and storage location constraints.

The cycle time for a sequence of n commands is:

t_MC = Σ over all segments [ max( t_h(segment), t_v(segment) ) ] + (n + 1) · t_transfer + t_fixed

where n is the number of storage/retrieval operations in the cycle, and there are n+1 transfer dwells (one for each load handled plus one for the initial pickup at the I/O point). The number of travel segments is n+1: from I/O to the first location, between each pair of locations, and from the last location back to I/O.

The optimization problem is to choose the sequence of locations that minimizes the total travel time. This is a variant of the traveling salesman problem, and it is NP-hard in general. In practice, the WCS uses heuristic algorithms (e.g., nearest neighbor, 2-opt) to find a good sequence quickly. The cycle time equation above is the evaluation function for any given sequence.

Multi-command cycles are most beneficial when there is a high ratio of retrievals to storages, or when the system can batch multiple retrievals before returning to the I/O point. The downside is increased complexity: the SRM must carry only one load at a time (unless it has a dual-load or multi-load carriage), so the sequence must alternate between storage and retrieval in a way that respects the carriage capacity.

For a single-load carriage, a multi-command cycle must alternate: pickup a load, store it, then travel empty to a retrieval location, pick up a load, and either return to I/O or travel to another storage location. The empty travel between a storage and a retrieval is unavoidable unless the carriage can hold multiple loads.

Transfer dwell: modeling load pickup and setdown #

Transfer dwell is the time the SRM spends at a location to physically exchange the load with the rack or the I/O conveyor. It includes fork extension, vertical lift of the load, fork retraction, and any load-positioning verification. This time is often treated as a constant per transfer, but it can vary with load type, rack type, and the precision required.

In our equations, we use a single constant t_transfer for every load exchange. This is a simplification. In a detailed model, you might distinguish between:

• t_pickup: time to extract a load from a rack location.
• t_setdown: time to deposit a load into a rack location.
• t_IO_handoff: time to exchange a load with the I/O conveyor.

These times may differ. For example, a setdown might require more precise positioning than a pickup, or the I/O handoff might involve a conveyor interlock that adds latency. For the purposes of this reference, we use a single t_transfer and note that you should calibrate it from measured data.

Transfer dwell is a significant fraction of total cycle time. In a high-density AS/RS with short travel distances, transfer dwell can dominate. For example, if t_transfer is 15 seconds and the total travel time is 30 seconds, transfer dwell is 33% of the cycle. This is why we emphasize measuring it accurately.

We recommend that you collect time-stamped data from the SRM’s control system to measure t_transfer under real operating conditions. The OPC UA framework [S4] provides a standardized way to access such process data, including timestamps for fork extend, lift, and retract events. This is a practical application of the OPC UA information model for condition monitoring and performance analysis.

Availability effects: from theoretical to effective cycle time #

Theoretical cycle time assumes the SRM operates continuously without interruption. In reality, the system experiences downtime due to mechanical failures, control-system faults, and scheduled maintenance. Availability (A) is the fraction of time the system is available for operation, typically defined as:

A = MTBF / (MTBF + MTTR)

where MTBF is mean time between failures and MTTR is mean time to repair. This is the steady-state availability for a system with exponential failure and repair distributions. It is a standard reliability metric, and the formula is derived from basic queuing theory. The NIST Engineering Statistics Handbook [S2] provides background on statistical methods for estimating MTBF and MTTR from field data.

To convert theoretical throughput to effective throughput, multiply by availability:

N_eff = N_theoretical × A

For example, if the theoretical SC throughput is 40 cycles per hour and availability is 0.95, the effective throughput is 38 cycles per hour. This is a 5% loss, which is often acceptable but must be accounted for in capacity planning.

Availability is not the only loss. Other losses include:

• Waiting time for the I/O conveyor to be ready.
• Congestion at the I/O point if multiple SRMs share it.
• Operator intervention for exception handling.
• Load misalignment or sensor faults that require retries.

These losses are often captured in a separate factor called “operational efficiency” or “utilization.” The effective throughput is then:

N_eff = N_theoretical × A × η_operational

where η_operational is the operational efficiency (0–1). This is a pragmatic approach: availability captures the reliability dimension, and operational efficiency captures the process dimension. Both must be measured or estimated from site data.

We emphasize that availability is a site-specific parameter. You cannot use a generic value from a textbook; you must measure it for your system or use the vendor’s guaranteed MTBF/MTTR values as a starting point. The NASA Systems Engineering Handbook [S3] provides guidance on how to allocate and verify such performance requirements across the system lifecycle.

Worked example #

This section walks through a complete calculation for a single-aisle AS/RS with one SRM. All input values are explicitly labeled as illustrative assumptions unless otherwise noted. You must replace them with your system’s measured data.

Inputs and units #

Step 1: Single-axis travel time function #

We define the time for a single axis to cover distance d with max velocity v and acceleration a. The threshold distance for reaching full speed is d_threshold = v²/a.

For the horizontal axis: d_threshold_h = (3.0)² / 0.8 = 9.0² / 0.8 = 11.25 m.

For the vertical axis: d_threshold_v = (1.0)² / 0.5 = 1.0 / 0.5 = 2.0 m.

If d ≥ d_threshold, t = d/v + v/a. If d < d_threshold, t = 2·sqrt(d/a).

Step 2: Single-command cycle to a representative location #

We choose a representative storage location at the far end of the aisle and mid-height: (x=70 m, y=6 m). The I/O point is at (0, 0).

Horizontal distance: 70 m. Since 70 ≥ 11.25, t_h = 70/3.0 + 3.0/0.8 = 23.33 + 3.75 = 27.08 s.

Vertical distance: 6 m. Since 6 ≥ 2.0, t_v = 6/1.0 + 1.0/0.5 = 6.0 + 2.0 = 8.0 s.

Concurrent travel time for one segment: max(27.08, 8.0) = 27.08 s.

SC cycle time: t_SC = 2 × 27.08 + 12 + 3 = 54.16 + 12 + 3 = 69.16 s.

Theoretical SC throughput: N_SC = 3600 / 69.16 = 52.05 cycles per hour.

Step 3: Dual-command cycle to two representative locations #

Storage location S = (70, 6) as above. Retrieval location R = (20, 9).

Segment I/O → S: computed above, 27.08 s.

Segment S → R: horizontal distance = |70 − 20| = 50 m. Since 50 ≥ 11.25, t_h = 50/3.0 + 3.0/0.8 = 16.67 + 3.75 = 20.42 s. Vertical distance = |6 − 9| = 3 m. Since 3 ≥ 2.0, t_v = 3/1.0 + 1.0/0.5 = 3.0 + 2.0 = 5.0 s. Concurrent time = max(20.42, 5.0) = 20.42 s.

Segment R → I/O: horizontal distance = 20 m. Since 20 ≥ 11.25, t_h = 20/3.0 + 3.0/0.8 = 6.67 + 3.75 = 10.42 s. Vertical distance = 9 m. Since 9 ≥ 2.0, t_v = 9/1.0 + 1.0/0.5 = 9.0 + 2.0 = 11.0 s. Concurrent time = max(10.42, 11.0) = 11.0 s.

Total travel time = 27.08 + 20.42 + 11.0 = 58.50 s.

Transfer dwells: 3 transfers × 12 s = 36 s.

Fixed overhead: 3 s.

t_DC = 58.50 + 36 + 3 = 97.50 s.

Theoretical DC throughput: N_DC = 3600 / 97.50 = 36.92 cycles per hour. Since each DC cycle moves 2 loads, the load throughput is 73.85 loads per hour.

Step 4: Multi-command cycle (illustrative sequence) #

We illustrate a 4-command cycle: store at S1=(70,6), retrieve from R1=(20,9), store at S2=(50,3), retrieve from R2=(10,6).

Segments and concurrent times:

• I/O → S1: 27.08 s (computed above).
• S1 → R1: 20.42 s (computed above).
• R1 → S2: horizontal = |20−50| = 30 m, t_h = 30/3.0 + 3.75 = 10.0 + 3.75 = 13.75 s. Vertical = |9−3| = 6 m, t_v = 6.0 + 2.0 = 8.0 s. Concurrent = max(13.75, 8.0) = 13.75 s.
• S2 → R2: horizontal = |50−10| = 40 m, t_h = 40/3.0 + 3.75 = 13.33 + 3.75 = 17.08 s. Vertical = |3−6| = 3 m, t_v = 5.0 s. Concurrent = max(17.08, 5.0) = 17.08 s.
• R2 → I/O: horizontal = 10 m, t_h = 10/3.0 + 3.75 = 3.33 + 3.75 = 7.08 s. Vertical = 6 m, t_v = 8.0 s. Concurrent = max(7.08, 8.0) = 8.0 s.

Total travel = 27.08 + 20.42 + 13.75 + 17.08 + 8.0 = 86.33 s.

Transfer dwells: 5 transfers × 12 s = 60 s.

Fixed overhead: 3 s.

t_MC = 86.33 + 60 + 3 = 149.33 s.

Loads moved = 4. Load throughput = 4 × (3600 / 149.33) = 4 × 24.11 = 96.44 loads per hour.

Step 5: Availability and operational efficiency adjustment #

Effective SC throughput = 52.05 × 0.95 × 0.90 = 44.50 cycles per hour.

Effective DC load throughput = 73.85 × 0.95 × 0.90 = 63.14 loads per hour.

Effective MC load throughput = 96.44 × 0.95 × 0.90 = 82.45 loads per hour.

Sensitivity analysis #

The most sensitive parameter in this example is the horizontal travel time, because the aisle is long (80 m) and the horizontal velocity (3.0 m/s) is the limiting factor for most segments. If we increase v_h by 10% to 3.3 m/s, the horizontal time for the 70 m segment becomes 70/3.3 + 3.3/0.8 = 21.21 + 4.125 = 25.34 s, a reduction of 1.74 s per segment. For the SC cycle, this reduces t_SC by 2 × 1.74 = 3.48 s, or about 5%.

Transfer dwell is the second most sensitive parameter. If t_transfer increases from 12 s to 15 s, the SC cycle time increases by 3 s (one transfer), and the DC cycle time increases by 9 s (three transfers). This is a 9.2% increase in DC cycle time, which directly reduces throughput.

Availability is a linear multiplier. A drop from 0.95 to 0.90 reduces effective throughput by 5.3% (relative), which is significant over a year of operation.

Limitations of this example #

This example uses a single representative location for the SC cycle, which is not the average over the entire rack. The true average SC cycle time requires integrating over the distribution of storage/retrieval locations. The DC and MC examples use specific location pairs; the average over all possible pairs will differ. The acceleration model assumes symmetric rates and ignores jerk (rate of change of acceleration), which can add time in practice. The availability and operational efficiency values are illustrative assumptions and must be replaced with measured data. The multi-command sequence is not optimized; a better sequence could reduce travel time. Finally, the example assumes a single SRM with no interference from other equipment, which is a simplification for a real system.

Average cycle time: moving from single locations to rack distributions #

The worked example computes cycle time for specific locations. For capacity planning, you need the average cycle time over the entire rack, weighted by the frequency of use of each location. This is a critical step because the average is not the arithmetic mean of the extremes; it depends on the storage policy (e.g., random, class-based, dedicated) and the retrieval policy (e.g., FIFO, LIFO, random).

For a single-command cycle with random storage and retrieval, the average travel time is the expected value of the max() function over the joint distribution of horizontal and vertical distances. If the I/O point is at one corner of the rack, the average horizontal distance is L/2 and the average vertical distance is H/2, but the average of the max() is not simply max(L/2, H/2). It is the integral of the max() over the rack area.

For a rectangular rack with continuous uniform distribution of locations, the average single-command travel time can be approximated by:

t_travel_avg_SC ≈ max( t_h(L/2), t_v(H/2) )

This is a rough approximation. A more accurate method is to discretize the rack into a grid of locations, compute the travel time to each, and take the weighted average. This is straightforward to implement in a spreadsheet or script.

For dual-command cycles, the average is more complex because it depends on the joint distribution of storage and retrieval locations. A common simplification is to assume that storage and retrieval locations are independent and uniformly distributed. The average travel time is then the expected value of the sum of three segments: I/O→S, S→R, and R→I/O. The expected value of the S→R segment is the average distance between two random points in the rack, which is a known geometric problem.

We recommend that you perform a discrete simulation or numerical integration over your actual rack layout and storage policy. The equations in this article provide the framework, but the average values must come from your data. The MHI fundamentals page [S1] provides a high-level overview of AS/RS components and operation, which is useful for framing the problem, but it does not provide specific cycle-time formulas.

I/O point location and peripheral interface effects #

The I/O point location has a first-order effect on cycle time. In our equations, we assumed the I/O point is at one end of the aisle (x=0, y=0). If the I/O point is at the other end (x=L, y=0), the travel distances change, and the average cycle time may increase or decrease depending on the storage policy.

In some systems, the I/O point is at a mid-aisle position, or there are multiple I/O points (e.g., one at each end). This changes the travel model: the SRM may not need to return to the same I/O point after each cycle. For example, in a dual-command cycle, the SRM might pick up a load at I/O point A, store it, retrieve a load, and deliver it to I/O point B. This is a “cross-aisle” or “pass-through” operation, and it can reduce travel time compared to returning to the same point.

The peripheral interface (conveyor, AGV, or manual station) also affects cycle time through the transfer dwell at the I/O point. If the I/O conveyor is slow or has a long interlock time, the SRM may wait before it can deposit or pick up a load. This waiting time is not captured in the basic t_transfer; it is an additional delay that depends on the peripheral system’s performance.

We recommend that you model the I/O point as a queueing station with a service time equal to the peripheral handoff time. The SRM’s cycle time then includes waiting time at the I/O point, which is a function of the arrival rate of loads and the service rate of the peripheral. This is a more advanced model, but it is necessary for systems with high throughput or slow peripherals.

For related guidance on conveyor interfaces, see our article on Conveyor Photoeye Placement: Capacity Planning and Bottleneck Analysis. The same principles of bottleneck analysis apply to the AS/RS I/O interface.

Multi-aisle systems and aisle transfer cars #

When an AS/RS has multiple aisles, the cycle-time calculation must account for the possibility of an SRM serving more than one aisle. This is typically done with an aisle transfer car, which moves the SRM from one aisle to another. The transfer car adds a new dimension to the cycle-time model: the SRM’s travel time now includes the time to move between aisles, and the transfer car itself can become a bottleneck.

In a multi-aisle system with one SRM per aisle, the cycle-time calculation is the same as for a single aisle, but the overall system throughput is the sum of the individual SRM throughputs, subject to shared resources (e.g., I/O conveyors, transfer cars). If an SRM can serve multiple aisles via a transfer car, the cycle time for a mission in a different aisle includes the transfer car travel time and the time to move the SRM onto and off the car.

The transfer car travel time is analogous to the SRM’s horizontal travel time, but with its own velocity and acceleration profile. The SRM must also perform a “docking” operation at each aisle, which is a form of transfer dwell. These times must be added to the mission cycle time.

For a detailed treatment of transfer car selection and application boundaries, see our article on Aisle Transfer Cars: Selection Criteria and Application Boundaries. The key takeaway for cycle-time calculation is that the transfer car introduces a new travel segment and a new dwell time, both of which must be measured and included in the model.

Comparison with shuttle and lift systems #

The cycle-time equations in this article are specific to a single-mast SRM that moves in both horizontal and vertical directions. Other AS/RS architectures, such as multi-level shuttle systems, use a different motion model. In a shuttle system, a lift moves vertically to a rack level, and a shuttle moves horizontally within that level to store or retrieve loads. The lift and the shuttle operate sequentially, not concurrently, because the shuttle must be positioned at the correct level before it can enter the rack.

This changes the travel-time calculation fundamentally. The cycle time for a shuttle system is the sum of the lift travel time and the shuttle travel time, not the max() of the two. The lift is often the bottleneck because it is shared among multiple shuttles. The shuttle’s travel time within a level is a separate component, and the transfer dwell includes the shuttle’s entry into and exit from the rack.

For a detailed discussion of shuttle system data signals and condition monitoring, see our article on Multi-Level Shuttle Systems: Data Signals and Condition Monitoring. For the interface between shuttles and lifts, see Shuttle Lift Interfaces: Capacity Planning and Bottleneck Analysis. These articles provide the architectural context that is essential for choosing the correct cycle-time model.

Our recommendation is to use the concurrent travel model (max()) only for single-mast SRMs. For shuttle systems, use a sequential model (sum of lift and shuttle times). For hybrid systems (e.g., a single-mast SRM that also carries a shuttle), use a combination of both models, with the shuttle operation treated as an additional transfer dwell.

Control-system sequencing and command interleaving #

The cycle-time equations assume that the SRM executes a fixed sequence of commands without delay. In reality, the control system (WCS or SRM controller) decides the sequence and timing of commands. The control system can introduce delays through:

• Command queueing: the SRM may wait for the next command if the queue is empty.
• Sequencing optimization: the control system may reorder commands to reduce travel time, which changes the cycle-time distribution.
• Interlocking: the SRM may wait for a confirmation signal from a peripheral before proceeding.
• Exception handling: the SRM may pause or retry if a load is misaligned or a sensor fails.

These control-system effects are not captured in the basic cycle-time equations. They are part of the operational efficiency factor (η_operational) that we introduced earlier. To estimate η_operational, you need to measure the actual cycle time over a representative period and compare it to the theoretical cycle time. The ratio is your operational efficiency.

The OPC UA framework [S4] is useful for this purpose because it provides a standardized interface for reading SRM status, command execution times, and fault logs. By analyzing this data, you can quantify the delays introduced by the control system and identify opportunities for improvement.

For a discussion of control-system time synchronization, which is critical for correlating events across multiple devices, see our article on Control-System Time Synchronization: Commissioning and Acceptance Checklist. Accurate time synchronization is a prerequisite for measuring cycle times and diagnosing delays.

Safety and guarding: how they affect cycle time #

Safety systems can affect cycle time in ways that are often overlooked. For example, if the SRM’s travel path includes a personnel access door or a maintenance zone, the control system may reduce speed or stop the SRM when the door is open. This adds time to the cycle, but it is not a constant; it depends on how often the door is opened and for how long.

Machine guarding, as required by OSHA 29 CFR 1910.212 [S5], is a legal requirement for all machines, including AS/RS equipment. The guarding itself does not directly affect cycle time, but the interlocks associated with the guarding can. For example, a guard door interlock may require the SRM to come to a complete stop before the door can be opened, and then re-accelerate after the door is closed. This adds a fixed time penalty each time the door is used.

We recommend that you include these safety-related delays in your operational efficiency factor. They are not part of the theoretical cycle time, but they are a real and measurable component of effective cycle time. The frequency of safety events depends on the site’s operating procedures, so this is a site-specific parameter.

Safety is a boundary condition for cycle-time optimization. You should never reduce safety margins or disable interlocks to improve cycle time. The OSHA standard [S5] is a minimum requirement, and site-specific risk assessments may impose additional constraints. Our editorial recommendation is to treat safety as a