Motionwell Automation designs and builds laboratory automation systems for regulated QA and test labs in Singapore. The reference build is a QA Lab Transformation programme that has run for four consecutive years with the same customer, projects P23078 through P26078, and is now being replicated for other manufacturers. The architecture stays the same each time: an autonomous mobile robot moves samples between storage and the benches, a collaborative robot loads and unloads the instruments, vision confirms what the robot is holding and where it is putting it, and a server-based scheduler decides what gets tested next.
The short version for anyone comparing options: laboratory automation is not one machine. It is a transport layer, a handling layer, a scheduling layer, and a traceability layer, and a project fails when any one of them is missing. A robot arm bolted next to a tester with no scheduler and no sample record just moves the queue somewhere else. This page explains what each layer does, how the instrument interfaces are surveyed before anything is quoted, what actually drives project cost, and how a lab that cannot stop testing gets automated anyway.
What does a laboratory automation system actually do?
| Layer | What it does | What it replaces | Typical hardware |
|---|---|---|---|
| Transport | Moves samples between storage, benches, and return | Technicians walking trays across the lab | AMR, or AGV where the route is fixed |
| Handling | Loads and unloads instruments, opens fixtures, presents samples | Manual loading between test cycles | Collaborative robot, application tooling, gripper |
| Scheduling | Decides sample order, station assignment, priority overrides | A whiteboard and whoever is on shift | Server task scheduler with PLC execution |
| Traceability | Tracks sample state, names and files every result | Manual logbooks and hand-typed filenames | State machine in PLC, network file store |
The reason the four layers are listed separately is that they fail separately. A lab can have excellent instruments and still lose a day to a sample that was tested, passed, and then filed under the wrong name. Our delivered work in this space is documented on the laboratory and QA automation industry page, and the full system build is covered in the QA lab automation case study.
Why did one QA lab keep ordering for four years?
Because the scope grew instead of restarting. The first phase covered a defined cluster of instruments and sample formats and had to prove one thing: that a sample could leave the rack, be tested, and come back with a result filed correctly, without a technician in the loop. Once that held under real production load, each following year added instrument types, sample formats, and floor coverage on the same control and data model.
That pattern is worth copying. It gives the lab a working system within one budget cycle, it exposes the awkward instruments early, and it means the second phase is integration work rather than a new architecture. The same rolling, site-by-site approach is how we deploy the electronic device history record (EDHR) system for a medical device OEM, where each site joins an existing data model instead of getting its own.
How do samples move between benches?
An autonomous mobile robot handles transport when routes change, when the floor is shared with people, and when new stations will be added later. The AMR navigates by its own map, takes missions from the scheduler over an API, and manages its own charging between jobs. Motionwell buys and integrates Youibot AMRs, and we have delivered AGV installations where the route is genuinely fixed and a guided vehicle is the cheaper honest answer.
The engineering problem in transport is not navigation. It is the tolerance stack between an AMR that parks to within a few millimetres and a robot arm that has to reach into a rack slot. Three mechanisms close that gap: a physical docking feature at each station, hand-eye vision that measures the actual offset before the arm commits, and a compliant gripper that tolerates what is left. Skip the vision correction and the cell works in commissioning and starts dropping samples in month three, when floor markings wear and rack legs get nudged.
Storage is part of transport. A sample rack under system control has an addressable position for every slot, a record of what sits in each one, and a rule for what happens when a technician takes a sample by hand. Racks that are not under system control are the most common source of traceability gaps we are called in to fix.
How does a robot tend a laboratory instrument?
The arm is the easy part. Collaborative robots with the reach and payload for lab work are commodity hardware now, and we buy and deploy JAKA cobots, with grippers from Schunk and DH Robotics and application tooling designed in-house. We also have integration experience on customer-supplied Universal Robots units across three projects, where the customer had already standardised on that platform.
The hard part is the instrument’s control interface, and it decides the project. Four cases come up:
- Native digital I/O. Start, busy, done, and error as discrete signals. A PLC drives this directly and it is the most reliable option available.
- Serial or Ethernet command set. The instrument accepts parameter setting, zero reset, start, and returns status and results. This gives the scheduler real feedback and is what we push for.
- Software API on the instrument PC. Workable, and it makes result capture clean, but it puts a PC in the critical path and its update policy becomes your problem.
- GUI only. No exposed interface. Options narrow to driving the vendor software or physically actuating the control, both of which need to be agreed with the instrument owner before anyone quotes.
This survey happens before design, not during commissioning. An instrument list with make, model, firmware, and interface type is the single document that most changes a lab automation proposal.
Fixture and sample presentation is the other half of tending. Specimen geometry drives the tooling: a coupon, a syringe barrel, a plate, and a moulded part each need different gripping, different approach vectors, and different confirmation that the part actually seated. Vision does that confirmation. We integrate Keyence and Cognex systems for presence, orientation, identifier reading, and post-load verification, and how those cameras are specified, lit, and calibrated is covered in our machine vision inspection guide.
Labs are shared spaces, so safeguarding is designed in rather than added. Depending on the station that means guarding and interlocked doors, area laser scanners, or speed and separation monitoring where people and robots share the aisle. The reasoning behind each choice is in our note on collaborative robot safety standards, and every delivered cell goes through LVD and CE testing before shipment.
How does the scheduler decide what gets tested next?
A server-based task scheduler holds the work orders. It knows which samples are queued, which stations can run which test, which stations are busy or in fault, and which jobs carry priority. It issues missions to the AMR and jobs to the cell, and the PLC executes them with deterministic timing and reports back. Splitting it this way keeps the queue logic where it can be changed by software people and keeps motion and safety where they belong.
Three things separate a scheduler that survives contact with a real lab from one that does not:
- Priority override. A rush sample from a line stoppage must jump the queue without breaking the record of what was displaced.
- Station-aware routing. When one instrument goes down, the queue redistributes to compatible stations instead of stalling.
- Mixed manual and automatic operation. Technicians will keep running samples by hand at some benches. The scheduler has to accept that a sample left the system and came back, rather than treating it as lost.
Total laboratory automation or connected islands?
Total laboratory automation, in the strict sense of one continuous automated path from sample receipt to filed result, is the right target for a lab with high volume, stable methods, and instruments that all expose control interfaces. Most manufacturing QA labs are not that lab. They have three or four high-volume tests worth automating end to end and a long tail of low-volume methods where a technician is faster and cheaper.
The practical target is a single scheduler and a single sample record covering the whole lab, with automated execution on the tests that earn it. That gives one queue, one audit trail, and a defined path to automate the next test later. Chasing full coverage on day one is how lab automation budgets get spent on the wrong benches.
How is every sample traced from rack to result?
Each sample is an object with an identifier and an explicit state: queued, in transit, loaded, in test, completed, failed, returned. Every transition is timestamped from one clock, so the record does not depend on which PC wrote it. Result files are named by rule from the sample identifier, method, and timestamp, then uploaded to the network location the quality system reads. No one types a filename.
Exception paths carry the same discipline, and they are what auditors look at. A retry is recorded as a retry. An operator intervention is recorded with the prompt that triggered it. A safe-hold is a state, not a gap. Data integrity expectations in regulated labs come down to the ALCOA+ principles, attributable, legible, contemporaneous, original and accurate, and an automated lab is usually better at all of them than a manual one, provided the exception handling was designed rather than bolted on.
Traceability is also where lab automation meets the rest of the quality system. For a medical device manufacturer, test results feed the device history record, which is why our EDHR work and our lab work share a data model rather than sitting in separate systems.
What drives the cost of a laboratory automation project?
We do not publish project prices, and any number quoted before the instrument survey is fiction. These are the variables that move the figure, in rough order of impact:
| Cost driver | Why it moves the number |
|---|---|
| Number of distinct instrument types | Each interface is separate integration work, and it does not amortise |
| Instrument interface availability | Digital I/O or an Ethernet command set is cheap; GUI-only instruments cost real engineering |
| Sample format count | Each geometry may need its own tooling, fixture, and vision recipe |
| Transport topology | Fixed route with an AGV is one class; multi-floor or shared-aisle AMR routing is another |
| Safeguarding scope | Guarded stations, scanners, and certification testing scale with the number of cells |
| Data and validation scope | Network integration, controlled naming, and IQ/OQ/PQ documentation add engineering, not hardware |
| Phasing | Building one system that grows costs less over four years than four systems that do not talk |
For context on the range: a benchtop liquid handler or a single automated tester from an instrument distributor is a catalog purchase, and it sits far below a lab-wide transport, scheduling, and traceability system, because those are engineering projects rather than products. Both can be the correct decision. If one bench is the bottleneck, buy the instrument.
How do you automate a lab that cannot stop running?
Phasing is the whole answer, and it is a design constraint from day one.
- Workflow map and sample census. Volumes per test, peak days, sample formats, current touch points, and where the time actually goes. Two weeks of honest data beats an estimate.
- Instrument interface survey. Make, model, firmware, control interface, result output. This is the go or no-go gate.
- Concept and layout. Route, station positions, rack capacity, safeguarding, and reach envelope checked against the real floor plan, including door widths, floor level changes, and lift access if the AMR crosses floors.
- Off-site build and FAT. The cell is built and debugged at our facility against instrument surrogates. Customer witnesses the acceptance test before anything ships.
- Installation in windows. Rigging, power, network, and safeguarding go in during shutdowns or weekends. Nothing that touches the running workflow happens during a production shift.
- Shadow running. The system runs the workflow in parallel while technicians keep the manual path. Discrepancies are found here, not after cutover.
- Station-by-station acceptance and expansion. Each station is accepted on its own, and the next phase begins from a working system.
Motionwell has run this pattern for four consecutive years in one lab, and delivered an AMR and cobot training cell to an institutional customer where staff learn the same workflow before it reaches their production lab. Our engineering, assembly, and commissioning happen in Singapore under an ISO 9001:2015 quality system, with bizSAFE Level 3 site practice.
Getting started
The proposal is only as good as the input, so bring the following to the first review:
- Instrument list with make, model, and control interface for every machine in scope
- Sample formats with dimensions, weight, and how each is currently held or fixtured
- Volumes per test method, daily average and peak, plus required turnaround for rush samples
- Lab floor plan with bench positions, aisle widths, door widths, and any floor level changes
- Data destination for results, and who owns the naming convention today
- Regulatory scope, including whether IQ/OQ/PQ documentation is required
Frequently Asked Questions
What does a laboratory automation system include?
Four layers, not one machine. Transport moves samples between storage and benches, usually with an autonomous mobile robot. Handling loads and unloads the instruments, usually with a collaborative robot and application-specific tooling. Scheduling decides what gets tested next and on which station. Traceability records the state of every sample and files each result under a controlled name. Remove any one layer and you have an island of automation that still needs a technician to feed it.
Can robots operate the lab instruments we already own?
Usually, but the answer comes from a survey rather than a brochure. Some instruments expose digital I/O, serial, or Ethernet control that a PLC can drive directly, including start, parameter set, and end-of-test handshake. Others only offer an operator GUI, in which case the software is driven through its own interface or the physical control is actuated. Instruments with no accessible interface and no exposed control are the ones we flag before quoting.
How long does a laboratory automation project take, and does the lab stop running?
The lab keeps running. Motionwell builds and debugs the cell at our Woodlands Link facility against instrument surrogates, so factory acceptance testing happens off your floor. Site work is scheduled into shutdown windows or weekends, and the system runs in parallel with the manual workflow until each station is accepted. Typical delivery for a first phase runs 16 to 24 weeks from concept approval, longer where validation documentation is in scope.
How does an automated lab hold sample traceability for an audit?
Every sample is an object with an identifier and an explicit state: queued, in transit, loaded, in test, completed, failed, returned. Each transition is timestamped by one clock, and each result file is named by rule rather than by a technician. Exception handling is the part auditors examine hardest, so retries, operator prompts, and safe-hold states are all written into the same record instead of breaking the chain.