A toll zone should be a sensing and compute problem, not a pavement problem.
Tollscopic's roadside is gantry-mounted and roadside-cabinet contained. The hard tolling logic moves out of in-pavement infrastructure and out of proprietary lane-controller assumptions. Devices produce evidence; the system normalizes it.
Per-lane equipment, zone-shared equipment, and one cabinet.
Per-lane equipment handles plate capture and classification context. Zone-shared equipment covers trajectory generation, transponder reads, edge compute, and WAN. Device choices are normalized through adapters — the schema below is the durable concept.
Plate capture per lane. Front and rear coverage where the zone supports it.
Transponder reads across the gantry. Independent of plate visibility.
Axle and class evidence via vision; LiDAR where configured. Sidefire + overhead options.
Vehicle trajectory generation. Continuous physical context through the zone.
NVIDIA Jetson Orin in a redundant pair. Edge compute, local buffering, WAN.
Six categories. Each carries its own confidence and provenance.
No single device is the sole source of truth. The platform keeps multiple sources, knows where they came from, and exposes confidence so edge cases can be reviewed rather than hidden.
ANPR/ALPR cameras read visible plates. Confidence per character. Provenance and timestamps preserved.
Sidefire and wide-angle video produce a continuous trajectory through the zone.
Vision-based axle counts. LiDAR for vehicle dimensions. Vehicle-class cues.
RFID / AVI reads. Standard transponder events bound to the vehicle path that produced them.
Lane, time, and geometric position metadata for every observation.
Confidence values, model versions, prompt/config hashes, schema versions.
Correlation starts close to the road.
Vehicle trajectories are generated at the roadside, where timing, geometry, and physical position still have operational meaning. The cloud receives evidence that is already bound to a vehicle path.
hardware: NVIDIA Jetson Orin × 2 power: low draw, cabinet-friendly network: cellular-backed · local buffer storage: SSD · evidence cache form: fits standard roadside cabinet runtime: OTA updates · health checks fallback: hot-failover between Orins
Device outputs are normalized through adapters. The system is not a fixed SKU.
What matters to Tollscopic is the evidence schema. A device may change, but the system still wants the same conceptual outputs: what was observed, where, when, by which device, with what confidence, and how it relates to the trajectory.
{ source_type, source_id,
observed_at, position,
payload, confidence,
device_meta, trajectory_id } The advantage is architectural, not magical.
Reducing dependence on pavement cuts and proprietary lane chains is what makes the system practical over a decade — not just at install time.
No saw-cut, no in-pavement loops, no buried sensors. New devices, new lanes, or new geometries do not require returning to the road surface.
Cameras and sensors evolve quickly. The roadside layer can absorb hardware change without forcing the transaction logic to change with it.
Adding a lane is a sensor and geometry update, not a civil project. The same evidence schema applies across zones.
Pavement maintenance and in-road sensor failure stop being part of the cost model.
Bring the gantry. We bring the rest.
If you have a toll-zone footprint and a back office you do not want to replace, the gantry-only architecture is built for you.