Cargo Crane Safety Control

Adding sensors or modifying the crane would have excluded units already in the field and touched cost and certification. Instead the system reads values the commercial controller already produces — load, angle, and the rest — so nothing new is attached. The integration spec was negotiated with the crane manufacturer.

Mobile equipment reports over LTE, and streaming every raw value strained the lines. Protocol slimming was examined but not completed; instead sampling was fixed at 1 Hz — frequent enough to catch load changes, light enough to stay stable. It has run reliably since. The slimming remains unfinished work.

Sensor streams are time-series; cranes, users, and documents are relational. TimescaleDB on top of PostgreSQL keeps both in one store — time-partitioned queries stay fast as data grows, and joins against relational data remain possible with a single database to operate.

The crane's own controller clamps the physical tipping limits, but working beyond rated capacity slipped through unnoticed. Judging strictly against the manufacturer's rating table — overload and angle — the control system's role was limited to judgment and notification, sent to both the operator and the site safety manager. The machine controls; the system alerts.

Screen design had drifted toward consumer-app conventions, blurring the information hierarchy. I proposed putting legibility before polish — a plainer screen whose states read instantly on site — and aligned the designer on that standard. The field responded well, and the same standard carried into the golf cart control screens.

Site safety documents were exchanged by hand, repeatedly, though the required set rarely changed. Frequently used documents are stored in the app and sent with one action — in the same app as hazard alerts, because field staff do not juggle apps by purpose.

Shipped in production models, currently in commercial operation.