How We Designed a Scalable Roller AGV Line-Side Logistics System for Four Production Lines

In this four-line workshop Roller AGV logistics project, we needed to plan line-side logistics automation for an electronics manufacturing workshop with four production lines.

The project did not begin by converting all four lines at once. Instead, one production line was selected for Phase One. The first phase was used to validate Roller AGV docking, onboard buffering, task dispatching, and production/test data collection before the proven model was rolled out to the remaining lines.

The project handled magazine/carrier-type loads. Each unit weighed up to approximately 5.81 kg and measured about 230 x 219 x 311 mm. Line-side handoff used roller interfaces, the AGV was designed with four onboard buffer positions, and the upper-level system connected to the logistics layer through the SRD Standard API.

In this application, the Roller AGV did more than move materials between production areas. It also completed automatic roller handoff at the line side and acted as the execution layer between production logistics and the dispatching system.

So the real design question was not:

How many AGVs do four production lines need?

It was:

How can we first establish a stable and verifiable line-side logistics model, then replicate the same interfaces, task logic, and data structure across the remaining production lines?

Why We Did Not Convert All Four Production Lines at the Same Time

If the final goal is to cover four production lines, the most direct approach may seem to be converting all four at the same time.

In theory, that could complete the workshop automation faster.

But it would also increase project risk.

A line-side AGV project involves more than the vehicle itself. It also includes:

• Production-Line Interface;
• Roller Docking;
• AGV Route;
• Buffer Positions;
• Task Dispatch;
• Upper-Level API;
• Production Data Collection.

When these elements are integrated for the first time, they often require on-site validation and adjustment.

For this reason, the project adopted:

Phase One - Transform One Line First

rather than:

Transform All Four Lines at Once

The value of the first line was not simply that it became automated.

More importantly, it was used to verify:

Can this logistics logic run reliably in real production?

Why the First Line Had to Be Designed as a Standard Template

If the first production line were built only as a quick demonstration, later expansion could require substantial redesign.

For example:

The first line could use one roller height while the second line uses another interface.

The first line could use one task-naming logic while the third line requires a different software structure.

The first phase might go live quickly, but replication costs would increase with every additional line.

A better objective for Phase One was therefore to establish a:

Repeatable Logistics Pattern

The following elements needed to be standardized as much as possible:

• AGV docking position;
• roller transfer method;
• material information format;
• task creation logic;
• buffer-position logic;
• API communication;
• test-data acquisition;
• operator display logic.

Once the first line had been validated, the remaining three lines could then follow a:

Copy + Adjust

approach rather than:

Redesign from Scratch

That is the real value of converting one line first.

Why Two Trips per Hour Still Required Careful Logistics Design

The project used a design basis of:

2 trips/hour per line

with a planning load of approximately:

20 kg per tray

Looking at one production line alone, two logistics tasks per hour may not seem demanding.

Once all four lines are operating, however, task demand no longer comes from only one source.

If several lines generate requests at the same time, the vehicle system must switch continuously between multiple line-side interfaces.

So the fleet cannot be designed only around the average number of tasks per day.

It also needs to consider:

• whether tasks from different lines may arrive at the same time;
• travel distance per trip;
• Roller Docking time;
• vehicle waiting time at the interface;
• whether onboard buffer positions can combine multiple tasks;
• task priority;
• whether completed production or test material also needs to be collected.

Even when average logistics frequency is not high, a shared multi-line fleet still requires:

Task Coordination

rather than a simple fixed shuttle route.

Why Four Onboard Buffer Positions Mattered More Than Simply Carrying More Material

The Roller AGV in this project was designed with:

4 Buffer Positions

The most obvious interpretation is:

The AGV can carry more material in one trip.

But the more important benefit is that the vehicle does not have to complete only one point-to-point task at a time.

Multiple buffer positions allow the dispatching system to arrange more flexible combinations of:

• material waiting for line-side delivery;
• completed production or test material waiting for return;
• logistics tasks for different production lines;
• loads associated with later tasks already assigned to the vehicle.

This turns the AGV from a:

Single-Load Transport Vehicle

into a logistics node with a degree of:

Mobile Buffer

capacity.

The four buffer positions therefore do more than increase transport capacity.

They also change:

Task Combination + Route Planning + Docking Sequence

Why Roller Docking Was Critical to Unmanned Line-Side Handoff

If the AGV only moves material close to the production line but an operator still needs to remove the carrier manually, the system achieves only:

Automated Transportation

rather than:

Automated Line-Side Handoff

The project therefore used Roller AGV docking with the production line.

A complete material-handling task can then follow:

Task Created

then:

AGV Dispatched

then:

AGV Arrives at Line Side

then:

Docking Confirmed

then:

Roller Transfer

then:

Material Position Confirmed

then:

Task Completed

Only when the final handoff is automated does the AGV become a true part of the production-line logistics system.

Why the Production-Line Interface Had to Be Standardized

A Roller AGV can actively transfer material, but that does not mean it can dock automatically with any production line without preparation.

The project still needed to standardize and confirm:

• Roller Height;
• Roller Direction;
• Tray Bottom Structure;
• Docking Position;
• Sensor Detection;
• Transfer Permission;
• PLC / Control Signal.

If the first and second production lines use different mechanical interfaces, the same AGV may still require different control logic for each line.

That would directly reduce the value of replicating the first line across the remaining three.

So Phase One needed to verify more than:

AGV works.

It also needed to verify:

The line-side interface can become a standard.

Why Production and Test Data Were Included in a Logistics Project

This case differed from a conventional line-side delivery project because the target was not limited to automatic material transport.

The project also included:

• Material Quantity;
• Test Result;
• Work Order Record;
• Line-Head Display Information.

In other words, the project also served as a:

Digital Demonstration Line

The logistics system therefore could not know only:

A tray needs to be delivered to Line 1.

It also needed to be able to associate:

• what the tray contained;
• which work order it belonged to;
• what the test result was;
• what production information should be displayed.

This required the logistics task to be linked with production data.

The project therefore expanded from:

Physical Material Flow

to:

Material Flow + Production Data Flow

Why Test Results Could Not Be Separated Completely from Logistics Tasks

If test results are stored only inside the local test equipment while the logistics system has no access to them, material movement and product status become disconnected.

For example:

A carrier may have completed testing.

The logistics system knows:

Material Ready for Pickup

but does not know:

Test Result

That limits downstream automatic routing and traceability.

Because this project required production/test data collection, a more appropriate system relationship is:

Production / Test Event

then:

Material Status Updated

then:

Logistics Task Created

then:

AGV Executes Transfer

This means the system knows not only that material is moving, but also:

Why this material needs to move.

Why the SRD API Had to Be Validated on the First Pilot Line

The project used:

SRD Standard API

to connect the customer's upper-level system with the automated logistics layer.

For a single AGV demonstration, API integration may appear secondary.

But if the project later expands from:

1 Line

to:

4 Lines

the importance of the system interface increases quickly.

In the future, all production lines may use the same mechanism to:

• Create Task;
• Send Material Information;
• Receive AGV Status;
• Return Task Result;
• Collect Production Data.

If the interface is standardized only after all four lines are installed, the project may require substantial repeated integration work.

Phase One therefore needed to validate both:

Physical Flow

and:

Digital Interface

Why a Multi-Line System Could Not Dispatch Only the Nearest Vehicle

When only the first line is operating, the task environment is simple:

one request,

one or a small number of AGVs,

and one line-side destination.

Once the system expands to four production lines, dispatching may need to deal with:

• Line 1 requesting replenishment;
• Line 2 returning completed material;
• Line 3 waiting for docking;
• Line 4 generating another production task.

At that point, selecting the:

Nearest Available AGV

is not necessarily the best strategy.

The system also needs to consider:

• Vehicle Buffer Availability;
• Current Load;
• Target Line;
• Docking Point Availability;
• Existing Assigned Tasks;
• Route Conflict;
• Task Priority.

In a four-line shared fleet, the dispatching object is therefore not simply an empty vehicle.

It is:

Vehicle + Material + Buffer Position + Route + Production Task

Why Line-Side Buffering Reduced the Coupling Between AGV Logistics and Production Takt

The production line wants material to be:

Already available when it is needed.

But an AGV cannot remain parked beside every production line.

A properly sized line-side buffer therefore creates some flexibility between logistics timing and production timing.

If the next batch of material can arrive in the line-side buffer in advance, a short AGV delay caused by another task does not necessarily create an immediate production shortage.

The purpose of a buffer is therefore not:

To store more material beside the line.

It is:

To provide a certain amount of time coverage.

This is why the project needed to consider both:

AGV Buffer Positions

and:

Line-Side Transfer / Buffer Positions

instead of solving every logistics issue by adding more vehicles.

Why Buying More AGVs Would Not Necessarily Solve the Logistics Problem

If a production line occasionally waits for material, an intuitive response may be:

Add another AGV.

But the real bottleneck may not be vehicle quantity.

The issue may instead come from:

• Docking Point occupied;
• late task release from the upper-level system;
• insufficient Line-Side Buffer;
• long Roller Transfer time;
• multiple lines generating tasks at the same time;
• Material Information not updated in time.

If the true bottleneck is the interface or task logic, adding vehicles may create more:

Traffic + Waiting + Scheduling Complexity

Before expanding to all four lines, Phase One therefore needed to answer:

Is the real bottleneck transport capacity, interface capacity, buffer capacity, or system response time?

Only after that question is clear does fleet sizing become meaningful.

Why Phase One Had to Prove More Than 'The AGV Can Run'

The case positioned the first phase as a demonstration production line and as the basis for later replication across the remaining lines.

So Phase One needed to validate:

Roller Docking

Can it remain stable in real production?

4-Position AGV Buffer

Does it match the actual task pattern?

SRD API

Can it create tasks and return results reliably?

Production/Test Data

Can it be collected and displayed correctly?

Dispatch Logic

Can it support the real production takt?

If these conditions are validated on site, expanding from one line to four lines changes from:

New System Development

to:

Standardized Rollout

That is the greatest value of a pilot line.

Why This Project Was Really About a Replicable Workshop Logistics Architecture

If we look only at the equipment, this project can easily be described as:

Adding Roller AGVs to the production lines.

But the full system actually established the following architecture:

Production Task

then:

SRD API

then:

AGV Dispatch

then:

Roller AGV

then:

Line-Side Docking

then:

Material Transfer

then:

Production / Test Data

then:

Task Feedback

The first production line was only the first application point for this architecture.

The real goal was to validate a:

Standardized Intralogistics Pattern

that could continue to be deployed across the remaining production lines.

So the value of the project was not limited to automating one line. It established a reusable logistics and data-interface framework for the entire four-line workshop.

Planning a Multi-Line AGV Logistics Project?

Coolyne can evaluate your production flow, line-side interfaces, buffer requirements, fleet sizing, and system integration needs. Contact Coolyne to discuss your application.