Motionwell Automation builds the laboratory automation software that sits above the robots in a QA lab, and the delivered reference is specific enough to describe rather than illustrate. In a medical device manufacturer’s quality laboratory in Singapore, a server application holds a priority-sorted work order queue and dispatches transport missions to the mobile robot by proximity and battery level, while an Allen-Bradley PLC holds the storage logic for 70 sample positions across 7 racks and runs a formal six-state machine for every sample with each transition stamped at millisecond resolution. The same PLC drives the lab’s Instron universal testing machines bidirectionally, performing zero-reset, setting test speed, triggering the test and acknowledging completion, then naming the result file by rule and uploading it to network storage. Server and PLC synchronise robot position and station status over Ethernet/IP. That programme has been re-ordered in four consecutive years and the architecture is now being replicated for other manufacturers. The cells are designed, assembled and tested at our Woodlands Link facility under ISO 9001:2015 with bizSAFE Level 3 site practice.
The short answer, before you read further. Laboratory automation software is three jobs that get shopped for as one. A queue decides what is tested next and on which station. A record holds the state of every sample and survives being interrupted. An execution layer talks to instruments and robots in deterministic time and reports back. Those three want different homes: the queue belongs where policy can be changed by people who write software, the execution belongs in the controller that already holds motion and interlocks, and the record has to be written once, from one clock, by whichever of them owns the transition. A lab automation project that buys a robot and leaves these three to be sorted out during commissioning gets a fast machine with a manual logbook bolted to it.
Where we stand, said plainly. We do not sell a LIMS, an MES, an electronic lab notebook or a scheduling product, and we are not a reseller for any of them, so nothing on this page is written to move a licence. If your benches are fast enough and the actual problem is that results are keyed in by hand, a records project is the cheaper answer than a robot and we will say so. What we build is the layer between a work order and a moving machine: queue logic, sample state, instrument handshakes, controlled file naming, and the interface to whatever system your quality organisation already runs.
This page covers the software and scheduling layer only. The transport, tending and sample-flow hardware that sits underneath it is on our laboratory automation capability page, and the delivered build is documented in the QA lab automation case study. If you already have an instrument list and a daily sample volume, skip ahead and talk to an engineer.
What does laboratory automation software actually have to do?
Five jobs, and they are worth separating on paper because they are usually bought as one line item and then discovered as five during commissioning. Naming them separately is also how you find out which ones you already own.
| Responsibility | The question it answers | Where it runs on the delivered system | What is missing without it |
|---|---|---|---|
| Work order intake | What has been asked for, by whom, and how urgently | Server work order management | Someone still walks a list to the lab |
| Dispatch and scheduling | What is tested next, on which station, by which vehicle | Server queue, priority-sorted | A robot that waits to be told what to do |
| Execution and handshake | Start the test, set the parameters, know when it ended | Allen-Bradley PLC, bidirectional to the Instron machines | A technician pressing start on an automated cell |
| Sample state and record | Where is this sample right now, and what happened to it | Six-state machine in the PLC, millisecond transitions | A traceability gap that appears during error recovery |
| Storage and inventory | What is in slot 47, and is it still there | PLC-native storage logic, 70 positions across 7 racks, barcode verification | A rack the system believes rather than knows |
The split across the third column is the design decision this page is really about. Queue policy changes often, in software, by people who think in work orders. Execution timing changes rarely, in a controller, and must not depend on a network round trip. Storage state has to be correct even when the server is being patched. Putting all five in one place is how a lab ends up with either a PLC nobody can extend or a scheduler that cannot be trusted to stop a machine.
One consequence worth stating early: the scheduler is not the safety system and is not the quality decision. It never decides that a sample passed, and it never decides that an axis may move into a shared space. Those live in the PLC code that executes the sequence and in the safety architecture around it, and a scheduler that reaches into either is a scheduler that has to be re-validated every time a queue rule changes.
Where does the scheduler stop and the LIMS start?
At the point where a decision stops being about the next 90 seconds and starts being about the record. The scheduler is a real-time system: it needs to know that station 3 is mid-test, that the vehicle is at 34 percent charge, that a rush sample has arrived. A laboratory information management system is a records system: it owns methods, specifications, the release decision and the certificate. Asking either one to do the other’s job is the interface mistake we see repeatedly in labs that already have both.
| Decision | Sits with the records system | Sits with the scheduler | Argued about in every project |
|---|---|---|---|
| What test method applies to this sample | Yes | No | Which system holds the method version |
| What order the queue runs in | No | Yes | Who may override a priority, and is the override logged |
| Which station a sample goes to | No | Yes | Whether an operator may pin a sample to a station |
| Whether a result passes | Yes | No | Where the limit values are stored and who edits them |
| What the result file is called | No | Yes | Whose naming convention wins |
| When a sample is finished | Shared | Shared | Whether “tested” and “released” are the same event |
The right-hand column is the useful one. Those five arguments are cheap on a whiteboard and expensive in commissioning week, because each one is really a question about authority rather than about software. Settle them in writing before the interface is specified, and name the person who owns each answer.
The delivered QA laboratory sits at one end of the range: there is no MES or LIMS in the loop at all, and the work orders originate in the server application itself. That was correct for one lab with a defined instrument set. The other end of the range looks like our warehouse fleet work, where transport requests come from the customer’s existing SAP EWM over standard RFC and BAPI interfaces because the work orders already lived there and moving them would have been a records project pretending to be an automation project. Which end you sit at is decided by where your work orders already exist, not by which architecture is more modern.
How does the scheduler decide what gets tested next?
On the delivered system the server maintains a priority-sorted queue of pending test requests, assigns transport missions to an available vehicle based on proximity and battery level, and tracks each mission through to completion, synchronising robot position and station status with the PLC over Ethernet/IP. Underneath that description sit four inputs, and a scheduler that is missing any of them degrades in a predictable way.
- Priority. A rush sample from a line stoppage has to jump the queue, and what it displaced has to remain visible. An override that quietly reorders the queue with no record is the feature that makes an audit uncomfortable later.
- Station capability. Which stations can run which method. Without this the queue is a single file line and one busy instrument stalls everything behind it.
- Station status. Free, mid-test, faulted, or held. This is the input that GUI-only instruments cannot supply, which is why the instrument survey decides the scheduling scope before anything else does.
- Vehicle state. Position and charge. The mobile robot is a shared resource with a duty cycle, and a queue that ignores charging simply moves the stall to the afternoon.
Two policy questions belong to the lab rather than to the integrator, and they should be answered before the queue logic is written. First, may the scheduler reorder work to group tests that share instrument settings, or must samples run in the order they were registered? That is a quality decision with a scheduling consequence, not the other way round. Second, what happens to a sample whose method is not in the automated set at all: does it stay in the queue as a visible manual job, or does it never enter the system? Both answers are workable. Discovering that nobody chose one is not.
What the scheduler should not be asked to do is optimise. A lab queue is small, the constraints are hard, and a rule that a technician can predict is worth more than an algorithm that produces a better sequence nobody can explain when a batch is late. The behaviour to specify is the one you can describe to an auditor in a sentence.
What does a sample record have to survive?
Error recovery, mainly. A record that is clean during a clean run and vague during a retry is the record that fails review, because a reviewer opens the exceptions first. On the delivered system every sample position moves through a formal state machine inside the Allen-Bradley PLC, and the transitions are the record rather than a log written alongside it.
| State | What it means | What the next transition depends on |
|---|---|---|
| Queued | Registered in a work order, awaiting transport | A vehicle and a compatible station being available |
| In-Transit | Vehicle dispatched, sample being carried | Arrival and docking at the target station |
| At-Station | Delivered to the instrument, awaiting test start | The instrument accepting parameters and a start trigger |
| In-Test | Test executing, data being recorded | Completion acknowledgment from the instrument |
| Completed | Test finished, result uploaded, awaiting return | A return mission being scheduled |
| Failed | Test or transport error | Operator intervention, recorded with the operator identity |
Three properties make this a record rather than a status display. Transitions are enforced, so a sample cannot appear In-Test without having passed through In-Transit and At-Station, and an invalid transition attempt is blocked and logged as an exception rather than silently ignored. Each transition is stamped at millisecond resolution and carries the sample identity, the source and destination states, the station and, where a person intervened, the operator identity. And the transitions are written by the controller that actually caused them, from one clock, so the sequence of events does not depend on which machine wrote which line.
Result files are named by rule from that same record and uploaded to network storage, which removes the step where a correct test becomes a wrong file. In a lab whose results feed a device history record, those files and their audit trail are electronic records under 21 CFR Part 11, which asks for named accounts, a secure computer-generated time-stamped audit trail, and accurate and complete copies for inspection. The equipment-side reading of that rule is set out on our 21 CFR Part 11 and electronic record page, and where the whole system has to be qualified rather than just tested, the route runs through computer system validation.
Why build the storage logic into the PLC instead of buying a system?
Because on that lab it removed a second software system from between the work order and the robot. The alternative was a purchased warehouse or lab execution system, which would have brought a database, a reporting layer and vendor support, and would also have added its own failure mode, its own version cycle and non-deterministic timing across the interface. Building the storage logic in ladder inside the Allen-Bradley PLC kept slot allocation, state and execution timing in one place.
That decision has a price, and it should be understood by anyone thinking of copying it.
| Route | What it buys | What it costs | Where it fits |
|---|---|---|---|
| Storage and state native in the PLC | Deterministic timing, one place to look, no second product to validate or license | Extensions are written in ladder rather than in SQL; reporting has to be built on the server | A defined instrument set at the scale of 70 positions in 7 racks |
| Purchased execution system driving the cell | Database, reporting and vendor support out of the box | A second system in the critical path, with its own timing and release cycle | Site-wide scope, or a lab that already runs a validated system |
| Server queue above a PLC execution layer | Queue policy changes in software; motion and state stay deterministic | Two codebases and one interface that has to be specified properly | The delivered QA laboratory, and the pattern we would repeat |
The honest boundary: the PLC-native approach suits 70 positions across 7 racks and would not suit a site-wide system, and where a customer already runs a validated execution system the deliverable is the interface rather than a rewrite. This is the same reasoning that decides whether a setting belongs in the controller or above it, worked through for operator interfaces on our HMI and SCADA integration page.
What happens to the queue when a test fails?
The interesting part of a scheduler is not the happy path. Three behaviours are worth specifying in writing, because they are what determines whether an overnight run produces results or a room full of stalled samples.
Retry with a recorded reason. On the delivered positioning stack each layer retries its own tolerance check up to three times before escalating to an operator alert with the specific failure mode logged. Retrying is not the notable part; logging the reason is. A cell that recovers silently teaches nobody anything, and a drifting rack looks exactly like a clean run until the day it does not.
Escalate without stopping the lab. A faulted station should take itself out of the assignment pool, not stop the queue. Samples in flight to that station need a defined destination, and samples already at it need a rule: wait, return to the rack, or hold in place for a person. Choose one per station type at design time.
Keep the record continuous through the intervention. When a person opens a door, removes a specimen or restarts a test, that is a transition with an operator identity attached, not a gap in the timeline. The measure of the design is that the audit trail survives error recovery rather than breaking at it, which is the opposite of how a manual logbook behaves under the same pressure.
One more, easy to forget: define what happens when the server is unavailable. If the PLC holds storage state and execution, the cell can finish what it is doing and hold, rather than losing the queue. If the queue lives somewhere that goes down with the network, decide now whether the lab stops or reverts to manual, and write the procedure for reconciling the record afterwards.
What does “integrated” mean when four suppliers’ software is involved?
Integrated laboratory automation solutions are sold as though the word means one vendor. In practice it means one queue and one sample record, with every interface named and owned. A lab with four suppliers and a single record is integrated. A lab with one supplier and three places where a sample’s status can be looked up is not.
| Interface | What crosses it | What happens when it is unavailable |
|---|---|---|
| Instrument to controller | Zero-reset, speed setting, start trigger, completion acknowledgment, test data | The station drops out of the pool; nothing else is affected |
| Server to controller | Missions, robot position, station status, over Ethernet/IP | Execution continues to completion, then holds; the queue stops advancing |
| Server to mobile robot | Transport missions, progress, vehicle state | Transport stops; samples remain in their recorded state |
| System to network storage | Named result files | Results must buffer and reconcile, or the lab loses filing, not testing |
| System to quality records | Sample registration and results | Manual entry resumes, with a reconciliation job afterwards |
Write that table for your own lab before signing anything, with a named owner against each row. It is the document that turns “integrated” from an adjective into a scope. The equivalent exchange on the transport side, between a fleet manager and the systems above it, is set out on our AMR and AGV integration page, and the wider picture of how this lab work fits a QA testing operation is on the laboratory and QA automation industry page.
Can a scheduling layer be added to a lab that already has instruments and robots?
Often, and control system modernisation on existing production machines is our largest line of work this year, so a retrofit of this shape is familiar territory rather than an experiment. Whether it is straightforward comes down to four things, all of which can be checked before anyone quotes.
- Does each instrument report status, not just accept a start? Without busy, done and error, the scheduler is guessing. This is the item that changes the answer more than any other.
- Is the storage addressable? A rack with an identity for every slot can be brought under system control. A shelf that people put trays on cannot, until it is replaced or instrumented.
- Does every sample carry an identity the system can read? Barcode verification is what turns a rack position into a record. Identity written on a label in pen is not an input to software.
- How many clocks are there? Merging a timeline across a PLC, an instrument PC and a server is only defensible when they are synchronised to one time source, and that is a configuration job that is easy to do at build and awkward to do afterwards.
Where those four hold, a scheduling and record layer can usually be added over existing hardware in phases, starting with the tests that carry the volume. Where they do not, the honest sequence is to fix the instrument interfaces and the storage first, because software written over an unreadable rack inherits the problem rather than solving it.
Getting started
The software layer is scoped from a different set of inputs than the mechanical layer, and these six are the ones that change the answer:
- Instrument list with the status path for each, not just make and model: what it reports back, over what interface
- Volume and priority policy: samples per method per day, peak behaviour, and who may declare a sample urgent
- The manual set: which methods will keep running by hand, and how those samples enter and leave the record
- Result destination and naming, including who owns the convention today and who is allowed to write to that storage
- The existing records system, if any, and whether it is validated
- Regulatory scope: whether the sample record forms part of a device history record or a qualified system
Frequently Asked Questions
Is the scheduling software a product we licence, or is it written for our lab?
It is written for the lab and delivered as part of the system, not licensed per seat. On the delivered QA laboratory the queue and mission dispatch run as a server application and the storage, state and instrument handshake logic runs inside an Allen-Bradley PLC, so there is no separate software product with its own version cycle sitting between your work order and the robot. We do not sell a LIMS, an MES or an electronic lab notebook, and we do not resell anyone else's. Where your quality organisation already runs one of those and it is validated, the deliverable becomes the interface to it rather than a replacement for it.
Can a scheduler run instruments that give no status feedback?
It can execute them, but it cannot honestly schedule them, and the difference decides how much the software layer is worth. A scheduler assigns work by knowing which station is free, which is mid-test and which has faulted. An instrument that accepts a start command but reports nothing back forces the software to guess with a timer, and a timer that is wrong leaves a robot waiting at a busy station or a sample removed mid-test. The lab's Instron machines are driven bidirectionally, with zero-reset, speed setting, start trigger and completion acknowledgment, which is why they can sit in a live queue. Survey the status path on every instrument before anyone quotes the scheduling scope.
Does the scheduler have to know about samples a technician runs by hand?
Yes, or the sample record has a hole in it exactly where an auditor will look. Technicians keep running low-volume methods manually, and a sample that leaves the automated rack by hand has to be recorded as removed by a named person rather than treated as lost or, worse, left showing as available. The practical requirement is that every rack slot is addressable, that the system knows what is in each one, and that there is a defined manual path with its own logged transition. Labs that skip this end up with two truths, the rack and the record, and reconciling them by hand is the job the automation was bought to remove.