DCS

The idea

A tag, an antenna and a box.

Workers on a site wear RFID tags, each one unique, so the system knows the moment someone walks past a receiver. Receivers go in strategic, identifiable places around the site, and they pick up each passing tag with a timestamp, the tag’s identifier, its battery level and more, and hand it to the nearest DCS box.

The box is a Raspberry Pi in a custom enclosure, with its own battery and charging. It does very little thinking on its own: it takes the raw reads from the antennas and posts them to my API, and everything after that, the processing and the management, happens in the cloud.

Movement

Following someone through a site.

With antennas at the gates and doorways, and a tag on every worker, a person’s path through a job site shows up as a series of reads, one box after another. Those reads went up to the DCS site manager, a proxy that passed them on into Eyrus’s .NET ingestion point, where the analysis happened.

People were the main thing tracked: who was on a job site, for job costing, billing and payroll. Trucks and equipment carried tags too, so Eyrus could track deliveries coming and going, and watch equipment to detect and deter theft.

There were several antennas on a site, and everything turned on following a tag’s identifier from one to the next. That analysis lived in the .NET product. I was responsible for getting the raw reads off the antennas connected to a DCS box and into the proxy in an authenticated, safe way, and the proxy turned around and passed them on to be ingested.

The box

Hardware from someone else, software from me.

The hardware design, the prototyping and, in the end, the manufacturing were handled by Never Stop Building, and the person behind it was Jason Fox. That covers the enclosure, the Raspberry Pi and the choice of components. My part was everything that ran on it, and it was firmware in all but name: launch scripts, daemons and Sidekiq workers that start on their own when the box powers up, talk to the RFID hardware and the other physical pieces to gather their readings, watch the battery and power over the Pi’s GPIO pins, and report in. The cloud managed all of it remotely, with health checks and automated software updates.

It was an Internet of Things system, a fleet of small computers run from the cloud, and it had to work with nobody standing next to it. A box on a fence at a building site loses its network and loses its power, and nobody is there to sort it out.

The hard part

An update that can’t fail.

The hardest thing to get right was updating the software on boxes I couldn’t touch. What runs on a box is Ruby, not a compiled program, so an update means fetching a new set of code that has to start cleanly on a machine I may never see again, and a failed update means a box someone has to go and fix.

I engineered it out of git repositories and bash scripts, handing out versions as git tags on GitHub. A release is a git tag. The box stops its services, checks out the tag, runs any scripts it hasn’t run before, reloads monit’s configuration, starts everything again and tells the API it’s done. Those scripts were inspired by Rails migrations, for the one-off changes a box needs when it moves from one version to the next.

The update ran in isolation, with rollback from the cloud, and it had to survive everything that comes with a Ruby project on a small computer, Bundler included.

The fleet

Every box, and how it’s doing.

The cloud side was two separate pieces with different jobs. The first is the Rails management app and API, where Eyrus configures sites, gates, antennas, tags and the boxes themselves. The boxes ask it now and then for their settings and for reboot commands.

It was clear early on that detailed metrics and status would matter as much as the features, so each box reports its health and its heartbeat, and the app shows outages, restarts, the software version it runs and a connectivity timeline. From there a box can be restarted, or its software updated, from anywhere.