Марія БровінськаAgroTech
10 September 2026, 15:41
2026-09-10
How Kernel made traffic flows at production facilities predictable with TransitHUB
A few years ago, at night, there were queues of grain trucks under the Kernel elevators — dozens of cars at once. The drivers spent the night in the cabins, and a guard with a flashlight counted the cars and made sure that no one got ahead. A truck could stand under the gate for up to three days: the carrier did not earn money during this time, the company overpaid for downtime, which was included in the tariff by contractors, and the company did not understand when exactly the raw materials would arrive.
Today, this picture is no longer there. But, as it turned out, removing the live queue turned out to be a much more difficult task than simply «making slot reservations.» Over six years, Kernel’s internal platform for managing transport logistics — TransitHUB — has grown from a simple electronic recording tool into a highly critical production system, on which the reception and shipment of 30 elevators, 6 factories and 5 terminals depend, and it is used by about 50,000 drivers.
A few years ago, at night, there were queues of grain trucks under the Kernel elevators — dozens of cars at once. The drivers spent the night in the cabins, and a guard with a flashlight counted the cars and made sure that no one got ahead. A truck could stand under the gate for up to three days: the carrier did not earn money during this time, the company overpaid for downtime, which was included in the tariff by contractors, and the company did not understand when exactly the raw materials would arrive.
Today, this picture is no longer there. But, as it turned out, removing the live queue turned out to be a much more difficult task than simply «making slot reservations.» Over six years, Kernel’s internal platform for managing transport logistics — TransitHUB — has grown from a simple electronic recording tool into a highly critical production system, on which the reception and shipment of 30 elevators, 6 factories and 5 terminals depend, and it is used by about 50,000 drivers.
Why a long queue is not about inconvenience, but about money
At first glance, the task sounds simple: instead of a live queue, an electronic one, the driver registers and waits for a call. But a live queue is not only an inconvenience for the driver. It is also a chronic lack of forecasting.
In a live queue, it is not enough for a driver to simply arrive — he also has to «defend» his position: monitor the traffic, not miss the moment of the call, be ready to defend his place if someone tries to skip ahead. For the carrier, this is a problem of fleet efficiency: while the car is in an indefinite queue, it is difficult to predict when it will be free for the next flight. And for the company itself, the problem is even wider — at the checkpoint, only the fact of the arrival of cars is visible, but there is no understanding of how much transport is still on the road, with what cargo and when it will arrive.
One trip through the eyes of a driver
The driver starts working with the system long before arriving at the facility. He creates a trip, records the departure, adds information about the transportation — and the car becomes «visible» to the company’s system even before it physically arrives at the checkpoint.
This allows you to check documents in advance. The driver downloads the TTN (goods and transport invoice) from a smartphone, and the document immediately goes for remote verification by the responsible employees of the enterprise — verification takes place before arrival, not after. If there is an error in the documents, it can be detected even before the truck physically arrives, and you don’t have to waste time at the checkpoint.
When the car enters a defined geofence, the driver registers in an electronic queue. The system works not only with the fact of arrival, but also with the future flow — it understands which cars are already on the road and when to expect them. And it works both ways: at all Kernel plants and at some elevators, TransitHUB is used not only for receiving the harvest, but also for shipping — synchronizing transport with production readiness, loading points and the right moment of call.
Multiqueue: one physical, several logical
One of the features that best shows the difference between a live queue and TransitHUB is multi-queue. Physically, there may be one flow of machines at the enterprise, but from a production point of view, this flow is branched into several logical queues — for example, by cargo, carrier, or consignor who places the goods for storage — and for each the system sets its own pace of passage.
Therefore, the machine that registered tenth, in a certain production situation, can leave earlier than the one that is first — if its cargo is needed by production right now. The electronic queue here does not work like a simple FIFO list: the order is adjusted to the current production situation, which can change repeatedly during the day.
For drivers, this logic is not always intuitive: the typical reaction is «how is that, I am standing first, and the car that arrived later left earlier.» This became a separate product insight for the team: it is not enough to build the right algorithm — its logic must be understandable to the user, otherwise drivers will simply bombard support and dispatchers with questions.
The dispatcher hasn’t disappeared — but his job has changed
An analogy with an air traffic controller is appropriate here: a significant part of the processes at the airport is automated, but without a person, planes do not land or take off. Similarly, in TransitHUB, the controller works with a digital interface and formalized rules, but it is he who manages exceptions and makes operational decisions: calls cars for loading or unloading, individually or in groups, depending on production needs.
If the called car does not arrive on time, the dispatcher returns it to the end of the queue. The system also allows for official movement to the beginning of the queue (for example, due to security requirements) and each such action is logged and published in the corresponding channel of the facility so that the driver can see why his position in the queue has changed. A kind of audit trail is formed, which allows you to restore the logic of the queue change after the fact.
The digital dispatch format has also given the company something unexpected: a separate dispatcher is no longer needed at each facility. One specialist or a centralized group can remotely manage queues at several enterprises at once — in practice, one centralized team already serves all terminals in an entire region.
The software starts not with the «create queue» button, but with a map of the area
The implementation of TransitHUB at a new facility does not start with system setup, but with an analysis of physical logistics: the team, together with the enterprise, studies entrances, places where traffic may accumulate, available parking lots, gas stations, and traffic routes — and only then designs a geofence and buffer zone.
A geofence is not a universal radius around an object, but a zone whose size is determined by the real geography of the area and where the driver can safely and comfortably wait for the call. In some cases, it is dozens of kilometers from the enterprise itself — the driver waits not on the roadside in front of the checkpoint, but in a parking lot, gas station or other suitable place. A buffer zone is designed separately — an intermediate point where the car arrives after the call before the direct arrival.
A challenge is not a call to «drive up,» but a regulation
Each facility has its own arrival schedule after the call — tied, in particular, to the geography of the geofence: if the waiting points are located tens of kilometers away, the driver needs to be given a realistic travel time. The call notification is sent via several channels at once — push, Telegram, SMS and a voice call, which can be repeated automatically up to five times if the driver does not answer. Unlike a live queue, the driver can rest normally all this time, and not hold a position at the gate.
If there is a dispute about a delay, the system leaves a digital trail: when the message was sent, whether the driver received it, whether the call was answered, and when the event occurred. In the dispatcher interface, the stages of the process are highlighted in green, yellow, and red — from normal to violation of regulations — so the dispatcher’s attention is focused on deviations, rather than routine trips that the system processes automatically.
What’s under the hood?
For the driver, TransitHUB is a few screens on a smartphone. Behind them is a production system with a backend based on Oracle APEX + PL/SQL, an Oracle Autonomous Database, a web based on JavaScript + Vue.js, and a mobile application: Android is already in production, iOS on Flutter is in development. The infrastructure works through Cloudflare, and the DevOps department is working separately on the stability of the system.
TransitHUB’s target availability SLA is 99,8%, and this is not a formal metric. Every two years, the system undergoes an external penetration test: independent experts look for vulnerabilities, classify them by criticality, and after they are fixed, a re-test is performed.
The thing is that there is no quick «manual mode» for TransitHUB. As Maksym Chayka, head of IT projects at Kernel Logistics, explains: «After switching to an electronic queue, the operating model itself changes: cars are no longer standing in front of the gate, but are dispersed in a geofence and move according to digital rules. If the system becomes unavailable, we cannot restore the old order in a few minutes — we need to re-coordinate transport, notify drivers, and actually restore the process. Therefore, the stability of TransitHUB is not a matter of the convenience of the IT service, but one of the conditions for the continuity of cargo acceptance.»
The hardest thing is not to write a system, but to change people’s habits
In wartime, the average age of drivers has increased significantly, and with it the share of users who find it more difficult to quickly adapt to digital tools. Therefore, support here is not a formal helpdesk, but part of daily operation: the first line works directly with drivers and dispatchers, helping with registration, flights, and queues. You can contact them, in particular, via the Telegram bot; support is available daily from 7:00 to 22:00.
Today, after more than six years of work on the product, the technical setup of a new facility takes approximately one or two working days — but this is not the time for full implementation. It is much more difficult to change the usual way people work. As Viacheslav Melnyk, TransitHUB service development coordinator, says: «Switching to an electronic queue is not just about starting to work in a new interface. You need to change the very paradigm of work. People have been used to managing a live queue in a certain way for years, and these habits do not disappear when the system is launched. Live and electronic queues cannot fully work at the same time. Sometimes it is working with people on the ground that becomes one of the most difficult stages of implementation.»
A separate class of tasks is created by conditions that were not present in the initial scenarios: during the operation of electronic warfare (EW) means, the GPS signal may be blocked or distorted, so the system cannot reliably determine the driver’s geolocation. For such objects, TransitHUB has provided the ability to disable geofence checking where the EW makes GPS positioning unreliable, so that an external technological limitation does not stop the operational process.
What’s next: harvest and first external client
The TransitHUB team is currently piloting a new scenario — transport coordination during loading during the harvest season, when it is necessary to drive vehicles between several loading points in different settlements at the same time. The situation there changes along with the pace of the harvest and the weather: at one point there may be too much transport, while at another there is not enough. The pilot’s task is to see such imbalances and promptly redistribute transport between points.
And after more than six years of internal operation, TransitHUB began to be offered to the external market as a SaaS solution. Along with the product itself, the client receives accumulated expertise in traffic flow management — how to build queue logic, work with geofences and buffers, and configure regulations. Operational support also remains with the Kernel team: the client does not need to separately build a service infrastructure around the product.
The team is currently undergoing its first implementation for an external commercial client — a large Ukrainian agricultural holding — and is preparing to move to production. After launch, the team plans to separately talk about this case: how the connection was made, what difficulties they encountered, and what results they obtained in real operation.
