Why fleet visibility breaks down
Each cycler vendor ships its own software with its own idea of a channel, a step and a test. That is fine for operating one device. It fails when a lab manager has to answer simple questions across the fleet.
- Which channels are free today — and which will be free next week?
- Which tests are running for which project, and who is waiting for the results?
- Which cycler stopped overnight, and since when?
- Which units are in maintenance or calibration and must not be booked?
- How utilised is the fleet, per vendor and per station type?
Without a common view the answers live in people's heads, in a spreadsheet or in a chat thread — and they are out of date by the time someone reads them.
What to unify — and what to leave alone
| Layer | Recommendation |
|---|---|
| Control, step programming | Leave in the vendor software. Replacing it is expensive, risky and rarely necessary. |
| Raw data and vendor file formats | Keep in the vendor system. Export or push only the signals you need for reports and traceability. |
| Station status (free, running, maintenance, out of service) | Unify. This is the core of fleet visibility and needs only a few fields. |
| Test assignment (project, test case, specimen) | Unify. It connects the cycler to the work the lab actually sells. |
| Schedule and reservations | Unify. Capacity planning only works with one calendar across all vendors. |
| Live values (voltage, current, temperature) | Optional second step, once status is reliable. |
Three ways to build the common layer
| Option | Strengths and limits |
|---|---|
| Manual status in a lab system | Staff set a station to running, available or maintenance. Zero integration effort and a good first step. Limit: depends on discipline, no live values. |
| Push from vendor software or a small script | A script or the vendor's export/API pushes measured values via REST at an interval. Works with almost every vendor that has any export. Limit: you maintain one small adapter per vendor. |
| Publish to an MQTT broker | Cyclers or gateways publish JSON to a topic; the lab system subscribes. Good for many devices and near-real-time values. Limit: needs a broker and a topic and permission convention. |
Most labs combine them: manual status first, push adapters for the two or three vendors with the most channels, MQTT where a gateway already exists.
A minimal vendor-neutral data model
The neutral layer works because it is small. Resist mirroring every vendor field; map each vendor onto the same few concepts.
- Station: stable ID, name, vendor/type, location, number of channels.
- State: running, available, maintenance, out of service — with the time it started.
- Assignment: project, test case and specimen currently on the station.
- Channel occupancy: which of the station's channels are used (a count is enough to start).
- Measured values: timestamp, channel name, value, unit — only if you need them.
- Source and freshness: which adapter reported it and when, so a silent adapter is visible.
Rolling it out in practice
- 1
Inventory the fleet
List every cycler with vendor, channel count, chamber and owner. Anything not listed will not show up in the overview.
- 2
Agree on the state vocabulary
Four states are enough. Write down when a station counts as running (a test is in progress) versus available.
- 3
Start with manual or derived status
Show the overview before integrating anything. Status derived from the test that is in progress beats status nobody updates.
- 4
Automate the biggest vendor first
Pick the vendor with the most channels, write one adapter, run it in parallel with manual status for a week and compare.
- 5
Show freshness
Display when each station last reported. A stale value that looks live is worse than none.
- 6
Connect it to planning
Link the status view to reservations and the backlog, so free channels today and expected free channels next month come from the same data.
What to look for in software
- Vendor-neutral by design: stations are a generic concept, not one vendor's device list.
- An open ingestion path (REST and MQTT) so you can connect any cycler that can export data.
- A live overview with status per station that can run on a wall monitor.
- Reservations and conflict warnings on the same stations, so planning and status match.
- Multi-tenant permissions, so a customer or a team sees only its own stations and tests.
- An API or tool interface that lets scripts and assistants query the fleet state.
Be sceptical of any tool that promises out-of-the-box connectors for every vendor: file formats and export options differ by firmware and licence. A small, well-documented ingestion path usually ages better than a long connector list.