Quick Summary
Connected laboratory automation works best when every physical handoff, software command, completion signal, and recovery responsibility is clearly defined. An interface matrix helps map these boundaries across systems such as AMRs, cobots, PLCs, and test equipment, reducing ambiguity before hardware and software are locked in.
The article recommends Motionwell’s QA laboratory project for building the matrix in four passes: define commands and evidence, assign protocols and data formats, establish timeouts and recovery behavior, and challenge the design with realistic faults. Explicit sample states, controlled result naming, and boundary-level acceptance tests further strengthen traceability and commissioning, helping integrators identify gaps before they become costly rework.
Introduction
A vendor list can look complete while the system design is still full of holes. The mobile robot has a mission API. The cobot has a gripper program. The test machine has its own method file. The PLC has a sequence. Then someone asks who names the result after a failed test and retry, and the room goes quiet.
Before requesting quotations from a Motionwell engineering team you can work with, write down the handoffs. An interface matrix is a brief document that lists the source, destination, command, state, evidence, and recovery owner for each boundary. It is less exciting than a robot simulation and far more useful during commissioning.
Motionwell Automation’s QA laboratory project is a useful question set because it crosses several unlike systems: MiR mission dispatch, a Universal Robots cobot, a 70-position rack, Siemens PLC control, and Instron test equipment. Use the design to expose the questions any connected automation project must answer before hardware locks them in, rather than treating it as a template.
Map the Physical Handoff Before Network Protocols
Start with the sample, container, or workpiece. Follow it from its current location to the next station – record who holds it, how presence is confirmed, and what physical condition permits the next command. A network message is only meaningful when the mechanical handoff is ready.
Name Every Source, Destination, and Ownership Change
For a lab sample, the source might be rack position B12 and the destination might be Instron station two. The mobile base owns transport across the floor. The cobot owns pickup and placement. The fixture owns final location. The PLC may coordinate all three, but coordination does not erase their separate failure modes.
Write one row for each ownership change. If the AMR reports arrival, what confirms that it arrived close enough for the arm to reach? If the gripper closes, what confirms that it holds the intended sample? If the fixture sensor turns on, does that prove correct orientation or only presence?
Define the Ready Condition at Both Ends
A sender can be ready while the receiver is not. The robot may arrive before the test frame completes its previous run. A test machine may be idle while the correct method has not loaded. The matrix should include a ready condition from both sides and the timeout that returns the system to a known state.
Keep these conditions observable. “Station available” should resolve into signals that control engineers and technicians can inspect. Hidden assumptions create the faults that only appear when the line is busy, the network is slow, or an operator pauses one station for maintenance.
Write the Interface Matrix in Four Passes
Do not try to complete the entire architecture in a single meeting. Four short passes keep the discussion grounded and make omissions easier to spot.
Pass One Records Commands, States, and Evidence
List the command in plain language, then name the state change it should produce. Add the evidence that confirms completion. A command such as “start tensile test” might require the correct sample in the fixture, an accepted method, a successful zero reset, and a machine-ready signal before the start trigger is allowed.
| Boundary | Command or event | Completion evidence | Recovery owner |
| Server to scheduler | Release sample priority | Queue entry with sample ID | Lab coordinator |
| Scheduler to AMR | Dispatch mission | Arrival at named station | Fleet controller |
| AMR to cobot | Permit pickup | Dock plus vision alignment | Cell PLC |
| PLC to Instron | Set method and start | Accepted command and test state | Test-cell controls |
| Instron to server | Publish completed result | Named file stored under sample ID | Lab data owner |
The table is a starting shape, not a universal protocol. The actual system may split or combine these responsibilities. What matters is that no command exists without a visible completion condition and a named owner for recovery.
Pass Two Assigns Protocols and Data Shape
Only now attach the technical interface. The laboratory architecture described by Motionwell Automation includes REST-based mission dispatch for MiR, as well as OPC UA, EtherNet/IP, and PROFINET for Siemens S7-1500 orchestration and instrument communication. These protocols solve different connection jobs; listing them does not define the payload.
For every row, specify the identifier, units, allowed values, and acknowledgment. Decide whether the receiving system can reject a stale or duplicated command. A sample ID sent as free text in one interface and a numeric record key in another can create a mismatch even when both networks are healthy.
Pass Three Adds Timeouts, Retries, and Safe Holds
Define how long the sender waits, whether it retries, and what state remains after the timeout. A repeated start command is not equivalent to a repeated status query. One may duplicate work; the other simply asks what already happened. The matrix should mark commands that must be idempotent or protected from repetition.
Motionwell Automation describes verified retries, operator prompt sequences, and safe-hold states in its QA lab system. Translate those ideas into boundary-specific behavior. If vision cannot confirm the sample position, the arm should not improvise a placement. If result upload fails, the sample and local result should remain associated until storage is confirmed.
Pass Four Challenges the Matrix With Faults
Use a short-fault battery before finalizing the request for quotation. Block a rack slot, interrupt an AMR mission, deny an instrument start, and make result storage temporarily unavailable. For each case, walk through the rows and identify the last confirmed state.
If the team cannot agree where the sample is or which system owns the next action, add a state or acknowledgment. Finding that gap in a document costs little. Finding it after a robot, fixture, and control cabinet have been built usually requires simultaneous mechanical and software rework.
Keep Sample State Separate from Machine Position
A sample sitting at a test station is not necessarily “in test”. It may be awaiting setup, paused after a failed command, or complete but waiting for pickup. Physical position and workflow state should be related without being treated as the same fact.
Use Explicit States Across the Full Lifecycle
The Motionwell Automation example uses states such as queued, in transit, at station, in test, completed, and failed. This vocabulary lets a scheduler make decisions without guessing from sensor position. It also gives technicians a clearer view of why a sample has not moved.
Add permitted transitions to the design. A failed sample should not jump straight to completed because someone moved it manually. An in-transit sample should not receive a second mission unless the first mission has been canceled or reconciled. State rules protect the process when physical work and software updates happen at different speeds.
Treat Result Naming as an Interface Contract
Result files are often left until late in the project because they look like an IT detail. In a QA lab, naming is part of traceability. The sample identity, test type, and timestamp must be in a controlled relationship, and the storage response must confirm receipt of the file.
Decide what happens to partial files, repeated tests, and authorized retries. A suffix such as “final2” may be convenient for a person and useless for a scheduler. The matrix should show how a new attempt relates to the original sample and why the earlier result remains visible.
Turn the Matrix Into Acceptance Tests
Every interface row can become at least one positive test and one fault test. Send the valid command and confirm the expected state. Then remove one precondition or response and confirm that the system holds safely without losing identity.
Test One Boundary Before Running End to End
Commission the rack, AMR, cobot, and instrument boundaries separately before asking the whole route to run. This makes faults easier to locate. Once each boundary behaves under normal and failed conditions, run the complete sample journey and confirm that state and evidence remain aligned.
Keep the interface matrix beside the test record. When behavior differs, update the design or the implementation, then repeat the affected test. Do not let the matrix become an early sales document that no longer matches the commissioned system.
A Clear Interface Map Earns the First Quote
Motionwell Automation may be a fit for laboratories that need a custom mobile robot, cobot, instrument, and data workflow engineered as a single project. A standard standalone test cell may need a much smaller integration boundary.
Either way, send the same interface map to potential integrators. A strong response will correct assumptions, expose missing signals, and show how recovery ownership works. A weak response will return a list of hardware. Choose the team that can explain the handoffs before it asks you to approve the machines.
