Rethinking the Concept of “Lane” in AVALON

In most MLFF (Multi-Lane Free-Flow) ETC projects, the concept of a lane is deeply embedded in system design.

AVC is configured per lane, ANPR cameras are mounted at lane centers, triggers are routed based on lane IDs, and axle-counting sensors are assigned lane by lane. In this traditional approach, the entire tolling logic assumes that lanes are fixed, symmetric, and clearly defined.

But real-world MLFF deployments rarely follow this ideal model.

Projects are shaped by budget constraints, existing infrastructure, gantry limitations, and accuracy requirements. As a result, customers may choose to install one camera for every 1.5 lanes, or deploy three cameras to cover two lanes. The same applies to sensors and LiDAR units: a five-lane highway may be equipped with four, six, or even three 2D LiDARs—sometimes mounted asymmetrically.

At that point, the classic lane-based logic starts to break down.

If a camera covers more than one lane, where should triggers be sent?

If the number of LiDARs does not match the number of lanes, how should vehicle detection be assigned?

And what happens when vehicles change lanes or do not respect lane discipline at all?

These are not edge cases—they are everyday realities in modern MLFF systems.

From Lane-Centric to Highway-Centric Thinking

For these reasons, in the Invis MLFF Total Solution, we deliberately moved away from a rigid lane-based architecture.

Instead of defining the system around lanes, we define the entire highway section under the gantry as a single, unified detection space.

This approach is implemented through a fully integrated solution where AVALON (AVC)NEXOR (Zone Controller )AEROS (ANPR cameras)2D LiDARs, and axle-counting sensors  operate together over a native communication architecture and protocol stack.

Because these subsystems are developed as parts of one ecosystem they are perfectly synchronized by design.

During system configuration, instead of assigning devices to lane numbers, we provide AVALON with the horizontal position of each subsystem:

cameras, LiDARs, and axle sensors. From this information, the system builds a spatial model of the roadway.

Once this model exists, decision-making is no longer tied to lanes.

How AVALON Sees the Road

AVALON does not ask, “Which lane is this vehicle in?”

It asks, “Where is this vehicle, and which combination of resources can describe it best?”

Based on vehicle position and trajectory, the system may trigger the front image from one camera and the rear image from another—even if those cameras are not assigned to the same lane. Sensor data from LiDARs and axle counters is fused dynamically, based on geometry and timing rather than lane IDs.

The outcome is a per-vehicle data model, not a per-lane one.

Each vehicle is detected once, tracked continuously, and processed as a single entity. The system guarantees that every vehicle generates exactly one complete transaction for the Back Office System (BOS), enriched with the best available images and sensor data, regardless of how many devices were involved.

Why This Matters

By removing lane dependency, the system gains a level of flexibility that traditional architectures simply cannot offer.

Customers are free to design sensor and camera layouts based on budget, accuracy requirements, and physical constraints, without being forced into artificial symmetry. Redundancy becomes easier to implement, because overlapping device coverage can be used intelligently rather than being locked to lane boundaries. Most importantly, real-world driving behavior—lane changes, drifting, non-standard vehicles—is handled naturally and accurately.

Because AVC, ZC, ANPR, and sensor interfaces are all developed by Invis as a unified platform, this highway-centric logic is not an add-on or workaround. It is a core architectural principle, deeply embedded in how AVALON and NEXOR operate together.

This shift—from lane-centric to highway-centric design—is what allows Invis MLFF systems to remain accurate, scalable, and future-ready, even as deployment scenarios become more complex.

That is the real meaning of “lane” in AVALON.Start writing here…