Sharing Hardware Lab Equipment and Dev Boards Across an Engineering Team

Software teams can usually solve contention by spinning up another copy. Hardware teams can't. There are four of the new revision boards, one JTAG debugger that works with them, one thermal chamber and one oscilloscope with the right probes. Everyone needs them in the same week.

The failure modes are physical and expensive. Someone reflashes a board in the middle of another engineer's soak test. A prototype disappears to a desk on another floor for a week. The logic analyser is "somewhere." A remote engineer can't tell whether the board on the rack is free without messaging three people.

This guide covers how to share lab equipment across a team: what to inventory, how to label it, how to handle remote access, when to use a board-farm tool, and how to run lightweight reservations from chat.

Step 1: Inventory with the questions that matter

A lab inventory isn't an asset register. Finance needs serial numbers. Engineers need to know which board has which fix.

For each item, record:

Field	Example	Why it matters
Short name	evt2-board-03	What people type and say
Revision / config	EVT2, rework R14 applied	Not all boards are equal
Location	Rack B, shelf 2	Where to find it
Attached to	Host lab-pi-03, serial /dev/ttyUSB2	For remote use
Power control	PDU outlet B-07	Remote power cycle
Sharing mode	Pool / dedicated / instrument	Which rules apply
Owner	Firmware team	Who decides disputes

Separate items into three groups, because they need different rules:

• Pooled DUTs (devices under test): interchangeable boards anyone can use. These need short, visible claims.
• Unique items: the only board with a particular rework, a customer-returned unit, a golden reference. These need claims and owner approval for anything destructive.
• Instruments and rigs: scopes, analysers, power analysers, thermal chambers, RF shielded boxes. Sessions are long and setup is fiddly, so interrupting them is costly.

Step 2: Label everything with its name

Put a printed label with the short name on every board, cable bundle and instrument. Not the asset tag, the name people use in chat.

This sounds trivial and is the single most effective step. When someone sees a board on a bench, the label tells them what to look up. When a remote engineer says "I've got evt2-board-03," the person in the lab knows exactly which one not to touch.

Add a second small label with "Lock before use" and the channel name if you use chat-based locks. It's a cheap reminder for visitors from other teams.

Step 3: Decide how remote access works

Many hardware teams now have engineers who rarely touch the lab. Remote access changes the sharing problem: a board on a rack can be in use with nobody standing next to it.

The usual setup for each DUT:

• A small host (often a single-board computer) attached to the board's serial console and USB.
• A network-controlled power switch or PDU outlet, so the board can be power-cycled remotely.
• A known way to flash it from the host.

Once boards are remotely usable, an empty bench tells you nothing about whether a board is free. You need a claim system that remote and local engineers both check.

Step 4: Consider a board-farm tool for automated access

If you run automated tests against hardware, look at a board-farm tool. One open-source example is labgrid, which models boards as "places" managed by a coordinator. Its client can list places, show who holds them, and reserve and lock them. Per labgrid's documentation:

labgrid-client -v places                  # list places
labgrid-client who                        # who holds what
labgrid-client reserve board=imx6-foo     # reserve by tag
labgrid-client -p evt2-board-03 acquire   # lock a place (alias: lock)
labgrid-client -p evt2-board-03 release   # release it (alias: unlock)

Reservations can wait for a matching place to become free, which suits CI jobs that need "any board with this tag." Check the docs for your installed version, as options differ between releases.

When a board-farm tool fits: automated test pipelines against hardware, a dedicated lab engineer to run the coordinator and exporters, and boards that are fully remote-controllable.

When it's overkill: a team of eight sharing a dozen boards and a few instruments, mostly by hand. Running a coordinator and exporters is real infrastructure. And instruments like a thermal chamber or an oscilloscope aren't "places" in any useful sense.

Many teams use both: the board-farm tool for automated access to racked boards, and something simpler and human-friendly for everything else.

Step 5: Run human reservations from chat

For people, the requirement is simple: claim the thing, show everyone you have it and until when, and let others know when it's free. The place most hardware teams already coordinate is their chat tool.

Lockit is a bot for Slack, Discord and Microsoft Teams that does exactly this. Each board or instrument is a resource:

@Lockit new

Give it the label name (evt2-board-03), a description with revision and location ("EVT2, R14 rework, Rack B shelf 2, serial on lab-pi-03"), and a channel such as #hw-lab for lock and release updates.

Then, in Slack:

@Lockit lock evt2-board-03
@Lockit release evt2-board-03
@Lockit list

On Discord, durations can be written naturally:

/lockit lock resource:thermal-chamber duration:till 6pm

When something is taken, you see who has it and when their lock ends, with Alert when released (a ping when it frees up) and Ask for takeover (the holder gets Release and Approve and Reject Request). Every lock has an end time: the duration given, else the resource's default, else the workspace default, else 48 hours.

Suggested defaults by item type

Item type	Default lock	Reasoning
Pooled DUT	4 hours	Covers a debug session; forgotten locks clear by end of day
Unique board	1 day	Longer work, but should never sit for a week unclaimed
Bench instrument	2 hours	Ask for longer when you lock
Thermal chamber / long rig	Stated per lock	Soak tests vary; always give a duration

Per-resource and workspace defaults can be set through the API on paid plans.

What Lockit won't do in a lab

• It doesn't control hardware. It won't power-cycle a board or block someone from plugging in.
• It doesn't take future-dated bookings. If the thermal chamber needs to be booked for next Thursday, put that on a shared calendar and lock it when the session starts.
• It has no calendar integration.

It's a visible, expiring record of who holds what, which is the part most labs are missing.

Step 6: Rules for destructive actions

Write these down and pin them in the lab channel:

• Never reflash or rework a board you don't hold. If it's locked by someone else, ask for a takeover.
• Unique boards need owner approval for destructive work. Locking golden-ref-01 doesn't give you permission to change its firmware.
• Leave it how you found it. If you change jumpers, firmware or cabling, either restore it or note the change in the resource description with @Lockit edit <name>.
• Release when you walk away. Remote engineers can't see that you've left.

Step 7: Review once a quarter

Look at what's always locked and what's never locked. Always-locked items are capacity problems; buy another, or split the pool. Never-locked items may be broken, missing, or not worth tracking. Remove them so the list stays useful.

Related reading

For phones and tablets specifically, see shared test devices for mobile QA. For single-seat tools like an expensive EDA or analysis licence, see sharing software licences across a team.

Lockit is free for two resources with unlimited locks and members. Starter is $17/month for up to 100 resources, which covers most labs. See pricing.

FAQ

Do we need a board-farm tool or is a chat bot enough?

If your tests run automatically against racked boards, a board-farm tool like labgrid earns its setup cost. If people mostly share boards and instruments by hand, a chat-based lock is enough, and it covers instruments that a board farm doesn't model.

How do remote engineers know a board is free?

They check the resource list in chat instead of the bench. For that to work, everyone, including people in the lab, has to lock before use.

What should go in a resource description?

Revision, rework state, location and how to reach it remotely. Update it when the configuration changes.

Can Lockit show lab equipment availability for next week?

No. Lockit shows who holds each item now and until when. Plan long sessions on a calendar and lock the equipment when they start.