Locksmith architecture

Snowdaddy Locksmith Solutions

An automotive locksmith operation with its own vehicle platform: standard diagnostics, fleet tracking and signed telemetry on a stack written from the engine up. Key and immobiliser work is done on professional key tools; the platform reads, signs and keeps the vehicle's data.

  • Engine and emissions diagnostics over the standard OBD-II protocols
  • Every device batch signed; stale and replayed batches refused
  • Fleet positions, trips, geofences, alerts, drivers and reports
  • Nothing is served outside the platform's private network

How a reading travels

The phone is a bridge with a screen; the node is the computer

An adapter on the vehicle's diagnostic port talks to the phone. The phone holds the link and its transmit gate, signs every batch and draws the screens. The code cross-reference, fleet records, alerts and reports all run on the node.

Adapter
OBD-II adapters over Bluetooth or Wi-Fi. The connection is profile-first: plugging in does not connect, no protocol is swept at the vehicle, and nothing is read without a chosen workflow.
Transmit gate
Four modes, active, passive, listen and quiet, on the one path to the adapter. A receive-only mode exists because a stray request can upset an immobiliser.
Ingest
Signed JSON. The server refuses a batch timestamped more than five minutes from its own clock and a signature it has already accepted; every refusal is logged with its reason.
Storage
PostgreSQL with telemetry partitioned by month. Sensitive fields are encrypted at rest with AES-256-GCM, under keys separated by data category and derived from a master key that is never stored beside the database.
Portals
Customer, technician and administrator surfaces, plus security and research surfaces for staff, reachable only over the private network.
Diagram: the vehicle's diagnostic port talks to the phone, which signs every batch and sends it into the private network; the node's engine and database serve the customer, technician and administrator portals; stale or replayed batches are refused Vehicle diagnostic port, standard OBD-II Phone a bridge with a screen transmit gate, signs every batch signed batches PRIVATE NETWORK Node C++ engine core PostgreSQL, encrypted at rest hash-chained ledger Customer Technician Admin refused: a batch older than five minutes or a signature already seen
Device, node and portals: one pipeline for every surface

The platform

What the platform does

Every portal is a role-scoped view of the same engine. A fleet owner sees only their fleet; the server decides the scope, never the client.

  • Standard diagnostics

    Engine and emissions fault codes, live data, readiness, freeze frame and VIN over SAE J1850, ISO 9141-2, ISO 14230-4, ISO 15765-4 CAN and SAE J1939. Manufacturer modules such as ABS, airbag and body are not read by the platform.

  • Cross-referenced codes

    Each observed code is matched against the shared OBD reference and a per-make overlay: cause, ordered fix steps, severity. An unknown code is shown as a learning signal, never as an error.

  • Fleet tracking

    Live positions, trips with replay, geofences with enter and exit alerts, drivers and shifts, and reports with a behaviour score meant for coaching.

  • Security monitoring

    For staff: accepted and refused batches, bad signatures, replays and clock skew per device, and ledger verification per origin. It has already caught a tracker whose clock drifted past the five-minute window.

  • Research intake

    For staff: test batches classified reading by reading, a written lesson to close each batch, and discoveries raised from frames nothing decodes yet.

  • Signed releases

    Every release is signed with keys only the operator holds. The node checks the signature and every file's hash before installing, and rolls back if the new version fails its health check.

Honesty over theatre: key and immobiliser work is done on professional key tools, never by the platform, and a control appears in the app only when the connected interface offers that capability.

For businesses with fleets

What a fleet brings, and what it gets

A fleet is set up by the operator with the owner: vehicles, drivers, rules and geofences. Drivers run the Android app on their shift; every phone and every device joins the private network before it can reach anything.

The fleet
A name, a contact and a time zone.
Vehicles
A unit number, and optionally the VIN, plate, year, make and model; a VIN reported by a device ties the vehicle to its records.
People
The fleet owner, optional dispatchers and viewers, and drivers with their own phone sign-in.
Rules
Speed limit, idle minutes, trip gap, harsh braking and acceleration thresholds, and work hours.
Hardware
An Android phone per driver, and optionally an OBD adapter for engine data beside the GPS.
  • Trips and replay

    Every trip with a speed-coloured path and its alert pins, replayed on the map.

  • Alerts

    Speeding, harsh braking and acceleration, idling, geofence enter and exit, shift start and end; acknowledged in the portal.

  • Drivers

    A roster, the vehicle on shift, assignment, and a sign-in for each driver's phone.

  • Reports

    Per vehicle and per driver, with a behaviour score and a CSV export.

Signed device data, a hash-chained record per origin and access only over the private network are the same for every fleet; alerts live in the portal inbox, never in an outside text or mail service.

Security built into the data

Constraints, not conventions

The rules that protect a customer's vehicles are enforced where they cannot be skipped: in the signing key on the device, in the database and in the ledger. A phone never speaks to the database and never holds a connection string; it signs JSON and posts it.

In the new portals, names, VINs and similar personal details are drawn as images instead of page text, which blocks bulk scraping; a screenshot still shows them.

Device identity
Every device signs what it sends. The server verifies per-device secrets for installed units; enrolment of phones with keys held in the phone's hardware keystore is built on the server and not yet deployed.
Replay
A batch more than five minutes from the server's clock, or a signature already accepted, is refused and counted against the device.
At rest
Data is organised into five domains. Sensitive fields are encrypted with AES-256-GCM, with lookups through blind indexes; decryption happens on the node, never on a device.
Ledger
Hash-chained per origin and verified per origin. Receipts are sealed over their content, so an edited record makes its receipt stale.
Releases
Signed by the operator; checked file by file before anything moves; the previous version stays in place for an automatic rollback.
Outward
The node makes no outside calls: no mail, no text messages, no push services.

The stack

Written from the engine up

No framework we did not write sits between the customer and the data. Every component does one job, and the boundary between them is the contract.

  • Engine core

    C++: sessions, accounts, fleet, telemetry, diagnostics, security and research routes in one binary, with its own self-tests.

  • Web framework

    Custom PHP and JavaScript, rendered on the server, with personal details drawn as images, and no CDN.

  • Bridge and tooling

    Python for the diagnostic bridge, capture next to professional tools, key generation and rotation, and release signing.

  • Android app

    One app for technicians and drivers: diagnostics, trips and shifts, each batch signed before it leaves the phone.

  • Database

    PostgreSQL bound to the node itself, telemetry partitioned by month, one active plug per vehicle enforced in the schema.

  • Serving

    Only on the private network: a device must join it before it can open anything, and nothing listens on a public address.

Snowdaddy Locksmith Solutions

Your vehicles, your fleet, one honest platform

Operated by Legit Locksmith Systems LTD, one of the four disciplines of Snowdaddy Solutions.