DEV Community: Suraj Informatics

Designing the Data Model Behind a Turnstile Access Control System

Suraj Informatics — Wed, 21 Oct 2026 12:25:19 +0000

A turnstile looks like hardware, but most of the engineering sits behind it. If you are integrating readers and barriers into a gate platform, the data model decides whether the first week is smooth or full of denied entries.

The decision the controller must make

When someone presents a credential, the controller has roughly a second to answer one question: open or stay locked. That needs three lookups.

Identity: does this credential map to an active person?
Policy: is this person allowed at this gate, in this zone, at this time?
State: are they already inside (anti-passback), or has the pass expired?

A minimal schema

person(id, name, type, status)
credential(id, person_id, kind, value, valid_from, valid_to)
policy(person_id, gate_id, zone, shift_start, shift_end)
event(id, gate_id, credential_id, ts, result, reason)

Keep event append-only. Denied attempts are as valuable as granted ones, because they expose data errors and misplaced readers.

Offline first

Gate hardware should keep a local copy of the allow-list and keep deciding when the network drops. Queue events locally and sync later. A turnstile that waits for a server on every read will fail on the first bad connection.

Fail-safe is not optional

Treat fire alarm and power loss as hard inputs that release the barrier regardless of software state. Test this during commissioning.

Metrics worth tracking

Read success rate per reader
Average passage time at peak
Denials per hundred reads, split by reason
Tailgating alerts, if you use presence sensors

For the physical side, barrier types and a rollout plan, see the turnstile access control system guide.

Designing Room-Level Location Logic for a Hospital RTLS

Suraj Informatics — Fri, 16 Oct 2026 11:15:24 +0000

BLE beacons and RFID readers in a hospital do not tell you "the pump is in room 304". They tell you that tag A1F3 was heard by receiver R-3-07 at -71 dBm. Turning that stream into a reliable room-level location is the core software problem in any hospital RTLS.

The raw data

from dataclasses import dataclass
from datetime import datetime

@dataclass
class Sighting:
    tag_id: str        # tag on the device
    receiver_id: str   # fixed receiver, mapped to a room or zone
    rssi: int          # signal strength in dBm
    ts: datetime

Step 1: smooth the noise

RSSI jumps around as people walk past and doors open. Never decide location from a single reading. Keep a short window per tag and receiver and use the median:

from statistics import median
from collections import defaultdict, deque

WINDOW = 5
buf = defaultdict(lambda: deque(maxlen=WINDOW))

def add(s: Sighting):
    buf[(s.tag_id, s.receiver_id)].append(s.rssi)

def strength(tag, receiver):
    vals = buf[(tag, receiver)]
    return median(vals) if vals else None

Step 2: pick a room, with hysteresis

Choose the receiver with the strongest smoothed signal, but only move the device to a new room if the new room wins by a margin for a few cycles. Without this, a pump near a wall will "flicker" between two rooms all day.

MARGIN = 6   # dB the new room must win by
CONFIRM = 3  # consecutive cycles

def decide(current_room, candidates, streak):
    best_room, best = max(candidates.items(), key=lambda kv: kv[1])
    if best_room == current_room:
        return current_room, 0
    if best - candidates.get(current_room, -200) >= MARGIN:
        streak += 1
        if streak >= CONFIRM:
            return best_room, 0
    return current_room, streak

Step 3: handle silence

Tags go quiet when batteries die, when a device is in a shielded room, or when it has left the building. Store a last_seen time and show "last seen in ICU, 2 hours ago" instead of pretending the location is current. Alert when a high-value device goes silent near an exit.

Lessons from the field

Map every receiver to a room in a config table, not in code. Rooms get renumbered.
Log raw sightings for a week before tuning MARGIN and CONFIRM.
Room-level accuracy needs enough receivers; software cannot fix a receiver that hears three rooms equally.

For the business side (which equipment to tag first, maintenance and audit benefits), see this guide to the hospital asset tracking system.

Designing a Plate Reading Pipeline for Truck Gates: Events, Confidence and Fallbacks

Suraj Informatics — Tue, 13 Oct 2026 06:30:30 +0000

If you are building or integrating plate reading at an industrial gate, the camera and the model are the easy part. The hard part is turning noisy reads into reliable events that the rest of your gate system can trust.

One read, one event

Treat every read as an immutable event, not a database row you keep updating. A minimal shape:

{
  "event_id": "gate2-in-20261013T061244-0187",
  "lane": "gate-2-in",
  "plate_raw": "MH43 AB 1234",
  "plate_norm": "MH43AB1234",
  "confidence": 0.91,
  "image_ref": "images/gate2/0187.jpg",
  "captured_at": "2026-10-13T06:12:44Z"
}

Keep the raw string and the normalised one. When a dispute comes up, the raw read and the image are your evidence.

Normalise before you match

Strip spaces and separators, force upper case, and handle the classic confusions: O and 0, I and 1, B and 8. Validate against the plate formats you expect, such as Indian state formats or Gulf formats, but do not reject a read just because it fails validation. Route it for review instead.

Use confidence as a routing rule

A single threshold is too blunt. Three bands work better:

High: match to the booked trip and open the barrier automatically.
Medium: show the guard the image and the best match, and let them confirm.
Low: ask for manual entry and store it as an override with a user ID.

Tune the bands on a week of your own lane data, not on vendor samples.

Deduplicate bursts

A truck that stops under the camera can produce several reads. Collapse reads of the same normalised plate in the same lane inside a short window, and keep the highest-confidence image.

Fail soft

Gates cannot stop because a network link dropped. Buffer events at the edge, give each one a stable event_id, and make the server side idempotent so a replay never creates a second trip record.

For the business side, including where plant and port gates use this and what to test in a trial, see the full guide: number plate recognition for plant and port gates.

Building Fleet Tracking for Industrial Sites: Events, Geofences and Data Joins

Suraj Informatics — Wed, 07 Oct 2026 16:40:15 +0000

Fleet tracking looks simple from the outside: put a GPS device in a truck and draw dots on a map. In industrial environments, the interesting engineering starts after the dot appears.

Events, not just coordinates

A plant or port cares less about latitude and longitude and more about events: vehicle entered gate 2, stopped at weighbridge 1, idled 18 minutes at bay 4, exited at 14:32. Turning raw GPS pings into these events means:

defining geofences as polygons around gates, weighbridges and bays,
handling GPS drift (a stationary truck can "move" a few metres every minute),
debouncing entry/exit so one wobble at a fence line does not create ten events.

Joining data from different systems

Fleet data becomes useful when it is joined with other sources:

Source	Key	What it adds
GPS tracker	device ID + time	position, speed, ignition
Fuel dispenser	vehicle ID + time	litres issued
Weighbridge	number plate + time	gross and tare weight
Gate ANPR	number plate + time	entry and exit stamps

The hard part is identity: the tracker knows a device ID, the gate camera knows a plate, the dispenser knows an RFID tag. A clean vehicle master table that maps all three is the backbone of the system.

Useful derived metrics

fuel_per_km      = litres_issued / km_driven
idle_ratio       = idle_minutes / ignition_on_minutes
site_turnaround  = exit_time - entry_time

Outliers in these three numbers explain most fleet cost problems on industrial sites.

Alerts that people act on

Too many alerts and supervisors ignore them all. Start with three: long idling inside the site, fuel-per-km above the vehicle's own average, and overdue maintenance. Tune thresholds during a pilot before scaling.

For the operational side of this, covering features, weekly KPIs and a rollout plan, read this guide to vehicle fleet management for plants and ports.

Building the Data Flow Behind an Unmanned Weighbridge

Suraj Informatics — Sun, 04 Oct 2026 17:15:15 +0000

An unmanned weighbridge looks like a hardware project: load cells, cameras, an RFID reader, a boom barrier. In practice most of the work is software, and specifically one question: when is a weighment valid?

The event sequence

A single weighment is a small state machine:

VEHICLE_DETECTED: RFID read or number-plate match
POSITION_OK: platform sensors confirm all axles are on the scale
WEIGHT_STABLE: the indicator reports a stable value for N readings
EVIDENCE_CAPTURED: camera snapshots stored with the transaction ID
TRANSACTION_CLOSED: slip issued, barrier opened, record sent onward

If any state fails or times out, the transaction moves to EXCEPTION and a supervisor is alerted. Nothing is silently accepted.

Reading the indicator

Most weight indicators push a continuous string over RS-232 or TCP. The terminal parses it, checks the stability flag and keeps a short rolling window. The key design rule: the weight value never passes through a user-editable field.

Idempotent ERP posting

The weighment is posted to the ERP (often SAP) with the transaction ID as the key. If the network drops, the terminal retries, and the ERP rejects duplicates. This avoids the classic double goods-receipt problem.

Evidence storage

Photos are stored against the transaction ID with the time stamp and gross, tare and net weights. When someone disputes a weight months later, a single lookup returns everything.

Handling exceptions

The exception path deserves as much design as the happy path. Typical cases: unknown RFID tag, plate read with low confidence, weight outside the order tolerance, or a camera offline. Each case gets a clear rule: hold the barrier, alert a supervisor, or allow with a flag. Log the decision and who made it, so audits can follow the trail.

Offline mode

Plants lose network more often than anyone admits. The terminal should keep a local queue of transactions and evidence, continue weighing under the same rules, and sync when the link returns, using the same idempotent keys.

Monitoring

Each terminal sends a heartbeat. A dashboard shows queue length, average platform time and exception counts per site, which is where truck turnaround improvements actually become visible.

We wrote a non-technical overview of the same system for plant and port managers. It covers features and rollout planning: intelligent terminal for weighbridges.

Validating Container Numbers from Gate OCR with the ISO 6346 Check Digit

Suraj Informatics — Sun, 04 Oct 2026 10:16:52 +0000

Container depots and terminals increasingly read container numbers with OCR cameras at the gate. OCR is fast, but it is not perfect: a smudged 8 becomes a B, a 0 becomes an O. The good news is that every shipping container number carries its own error check, defined in ISO 6346. You can catch most misreads with a few lines of code before they reach your yard system.

Anatomy of a container number

A container number like CSQU3054383 has four parts:

CSQ - the owner code (3 letters)
U - the equipment category (U for freight containers)
305438 - the serial number (6 digits)
3 - the check digit

How the check digit works

Give each letter a value starting at A = 10, skipping multiples of 11 (so 11, 22 and 33 are never used). Digits keep their own value.
Multiply each of the first 10 characters by 2 to the power of its position (1, 2, 4, 8 ... 512).
Add the results, take the remainder after dividing by 11, then take the last digit (a remainder of 10 becomes 0).

import re

def letter_values():
    values, n = {}, 10
    for ch in "ABCDEFGHIJKLMNOPQRSTUVWXYZ":
        if n % 11 == 0:
            n += 1
        values[ch] = n
        n += 1
    return values

VALUES = letter_values()
PATTERN = re.compile(r"^[A-Z]{3}[UJZ][0-9]{7}$")

def check_digit(first10: str) -> int:
    total = sum((VALUES[c] if c.isalpha() else int(c)) * 2 ** i
                for i, c in enumerate(first10))
    return total % 11 % 10

def is_valid(number: str) -> bool:
    number = number.replace(" ", "").upper()
    return bool(PATTERN.match(number)) and check_digit(number[:10]) == int(number[10])

print(is_valid("CSQU3054383"))  # True
print(is_valid("CSQU3054388"))  # False - OCR misread

Using it at the gate

Reject or flag any OCR reading that fails the check, and ask the gate clerk to confirm only those trucks.
Try likely swaps (O/0, B/8, I/1) on a failed read and accept a candidate only if exactly one passes.
Log both the raw OCR text and the corrected number, so you can measure camera accuracy over time.

This small check turns OCR from "usually right" into something a yard system can trust, which is what makes truly automated gates possible at depots and terminals.

For the bigger picture of how gates, weighbridges, yards and rail sidings work together at an inland depot, see this guide to the inland container depot (ICD).

Modelling Truck Flow Through a Container Terminal as Events

Suraj Informatics — Sat, 03 Oct 2026 10:37:26 +0000

Container terminals are a good example of a system where the interesting data is not the state but the events. A truck enters the gate, gets weighed, picks up a box in the yard and leaves. If each of those moments is recorded as an event, almost every operational question becomes a simple query.

The events

A minimal event table for the land side of a terminal:

CREATE TABLE truck_events (
  id          BIGINT PRIMARY KEY,
  visit_id    BIGINT NOT NULL,      -- one truck visit
  vehicle_no  VARCHAR(20) NOT NULL, -- read by ANPR
  container   VARCHAR(11),          -- read by OCR, ISO 6346 format
  event_type  VARCHAR(20) NOT NULL, -- GATE_IN, WEIGH_1, YARD_PICK, WEIGH_2, GATE_OUT
  location    VARCHAR(30),          -- gate lane, weighbridge id, yard block
  created_at  TIMESTAMP NOT NULL
);

Questions it answers

Truck turnaround time: GATE_OUT minus GATE_IN per visit_id.
Where trucks wait: the gap between consecutive events in the same visit shows which stage is slow.
Yard hot spots: count YARD_PICK events per block per hour.

Why automatic capture matters

The model only works if events are recorded at the moment they happen. Manual entry adds delay and typing errors, so the timestamps drift and the analysis lies. That is why terminals pair this kind of data model with OCR and ANPR cameras at the gate and an unmanned weighbridge: the event is created by the hardware, not by a clerk.

For the operational side (the quay, the yard, the gate and the KPIs terminal managers track), see this guide to container terminal operations.

Computing Truck Turnaround Time from Gate Events: A Simple Data Model

Suraj Informatics — Wed, 30 Sep 2026 12:49:11 +0000

Plants that automate their gates with RFID or ANPR end up with a stream of events: a vehicle was seen at the gate, stood on the weighbridge, docked at bay 4, left. Turning that stream into a useful truck turnaround time (TAT) report is a small but surprisingly fiddly data problem. Here is a simple model that works.

The events

Each reader, camera or weighbridge terminal emits an event with the same shape:

from dataclasses import dataclass
from datetime import datetime

@dataclass
class GateEvent:
    visit_id: str      # one truck visit (gate pass / trip number)
    vehicle: str       # plate or RFID tag
    stage: str         # REPORTED, GATE_IN, WEIGH_1, BAY_CALL, DOCK_IN, DOCK_OUT, WEIGH_2, GATE_OUT
    ts: datetime

The key design choice is visit_id. Using the vehicle number alone breaks as soon as the same truck makes two trips in a day.

Stage durations

ORDER = ["REPORTED", "GATE_IN", "WEIGH_1", "BAY_CALL", "DOCK_IN", "DOCK_OUT", "WEIGH_2", "GATE_OUT"]

def stage_durations(events):
    ts = {e.stage: e.ts for e in events}
    out = {}
    for a, b in zip(ORDER, ORDER[1:]):
        if a in ts and b in ts:
            out[f"{a}->{b}"] = (ts[b] - ts[a]).total_seconds() / 60
    if "REPORTED" in ts and "GATE_OUT" in ts:
        out["TAT"] = (ts["GATE_OUT"] - ts["REPORTED"]).total_seconds() / 60
    return out

Note that TAT starts at REPORTED, not GATE_IN. Time spent queuing outside the gate is real turnaround time, even if the gate register never sees it. An ANPR camera a little way up the approach road is the easiest way to capture it.

Things that go wrong in real data

Missing events. A tag is not read at one stage. Report the visit as incomplete rather than guessing.
Duplicate reads. Readers fire several times as a truck passes. Keep the first read per stage per visit.
Clock drift. Sync every device to one NTP source, or stage durations turn negative.
Value-adding vs waiting. Only DOCK_IN->DOCK_OUT is loading. Everything else is waiting, and that is where the savings are.

Why it matters

Once each stage has a duration, you can group by shift, product, transporter or gate and see exactly where trucks lose time. This is the approach behind the stage-wise TAT dashboards in GATIVRA, the plant logistics platform from Suraj Informatics.

For the business side (what TAT means, the formula and seven ways to reduce it), see the full guide: TAT in Logistics: What Truck Turnaround Time Means and How to Cut It.

How Weighbridge Software Moves Data from the Scale to Your ERP

Suraj Informatics — Mon, 28 Sep 2026 17:03:17 +0000

In plants, ports and logistics parks, the weighbridge is one of the few places where physical goods turn into data. Every truck is weighed at least twice (in and out), and those numbers end up on invoices, purchase orders and stock reports. If the data flow is manual, errors creep in fast.

Here is a simple way to think about how modern weighbridge software moves data from the platform to the ERP.

1. Identify the vehicle

Before any weight is recorded, the system needs to know which truck is on the platform.

RFID tags for regular transporters
ANPR cameras that read number plates for vehicles without tags

The vehicle ID is matched against an expected order or gate pass.

2. Control the platform

Traffic lights and boom barriers let only one vehicle onto the platform at a time and hold it until it is positioned correctly. The software, not an operator, decides when the vehicle may enter and leave.

3. Capture a stable weight

The software reads the stable weight from the weight indicator and stores it with:

vehicle ID
timestamp
camera image of the truck on the platform

That combination is what makes the record tamper-proof and easy to audit.

4. Generate the ticket

After the second weighment, gross, tare and net weights are calculated and the weighment ticket is generated automatically. No typing, no re-keying.

5. Sync to ERP in real time

The record goes to a central system and, through APIs, to the ERP or terminal management system. Purchase orders, sales orders and invoices stay in sync with actual weights, instead of waiting for end-of-day uploads.

Why this matters

Most weighbridge disputes are not about the scale. They are about which vehicle was weighed, and when. Linking every weighment to an automatic vehicle ID and a camera image answers that before anyone has to ask.

Full guide (manual vs unmanned, features to look for, FAQ): What is weighbridge software?

Suraj Informatics: https://www.surajinformatics.com
Suraj Informatics UAE: https://www.surajinformatics.ae
GATIVRA platform: https://www.gativra.com