AI systems in transport: where automation fails
AI systems in transport are built as a "perception — decision — execution" chain, and failure most often occurs at the junction of blocks, not inside one of them.
Perception outputs a confident but incorrect assessment of the scene, the planner takes it as fact and builds a trajectory — then the error is not damped but accumulates.
That is why autonomous transport control is tested not by individual modules, but by how the chain behaves when sources diverge.
Sensor failure rarely looks like "the sensor went silent": more often it is degradation.
Dirt and a water film on the optics, glare from low sun, snow in the field of view, calibration drift after washing or impact — each source loses reliability in its own way, and the failure sets of a camera, radar and rangefinder hardly overlap.
A single sensor will not confirm the scene, and an algorithm trained on clean data will not see the substitution.
Localization failure is more insidious externally: the vehicle drives straight, but when satellite corrections are lost or it matches a similar section, the deviation from the map grows nonlinearly.
The first to feel this is not the operator but the planner — its trajectory has already been built from an incorrect position. Hence the requirement for redundancy of localization channels and for an honest transition to a safe mode instead of continuing to move.
The flip side is false braking activation: a phantom object in noise, a shadow, a reflection from a guardrail. Sudden braking in traffic creates a risk of a rear-end collision, and on a route — schedule disruption and idle equipment during loading.
For a carrier, these are two different failure consequences: a missed obstacle and a stop where there should not be one.
Our engineers start with a failure map for a specific route: where redundancy is needed, where arbitration between sources works, and where it is more honest to limit the mode. We analyze how this is addressed in the project.
Effect of AI systems in the transport fleet and on site
The first effect is visible in reduced downtime. A unit that previously failed suddenly and took equipment out of schedule becomes noticeable in advance: the model tracks degradation from telemetry — rising temperature, changing vibration, pressure drop.
The signal arrives tens of hours before failure, and repair moves from emergency to a planned window.
Second — an eliminated class of failures that a human physically does not have time to resolve.
The reaction time of the control loop is tens of milliseconds versus a second for an operator, and it is this difference that covers scenarios with a sudden obstacle, a wheel that has lost traction, or a communication loss with the dispatcher. The safety fallback triggers before the driver would have had time to make a decision.
Third — route predictability. The arrival time forecast is calculated from the actual condition of the equipment, not from the schedule, so the dispatcher plans loading and unloading windows reliably.
Schedule deviations become isolated rather than every shift — reserve capacity has to be kept an order of magnitude less often.
Fourth — equipment utilization. Fuel and charge consumption, shift changes, and maintenance are distributed according to the forecast, and a unit does not sit idle waiting for a post to free up.
The share of time when the vehicle actually works grows by tens of percent: the same fleet covers a larger volume of trips.
Implementation formats: from operator prompts to autonomy
The mode is chosen not by the "level of automation" as such, but by the environment and by who is responsible for the decision at a specific moment.
The same set of sensors and models gives different results depending on whether the territory is enclosed, whether the environment is marked, and whether a human remains in the control loop. Below are four working formats that are actually chosen between at the start of a project.
| Option | When it fits | Limitations |
|---|---|---|
| Advisory analytics based on telemetry | The fleet is already in operation, data flows from the vehicle: need to reduce downtime and consumption | Does not control the vehicle — the effect depends on how the dispatcher and driver react to the conclusions |
| Assistive mode | Production equipment, the driver remains in the loop, need to remove some errors on difficult sections | The decision is still made by a human: fatigue and distraction remain risk factors |
| Hybrid driving mode | The route is divided into predictable and difficult sections, partial reduction of operator workload is needed | Requires clear rules for handover of control and operator training |
| Autonomous loop in an enclosed area | Quarry, port, warehouse: marked environment, limited speed, no general traffic | Does not transfer to public roads: infrastructure and dispatching are needed |
The formats are not mutually exclusive: telemetry analytics usually comes first — it shows where automation makes sense at all and where prompts are sufficient. An autonomous loop in an enclosed area makes sense when the environment is marked and predictable.
Let's discuss your route and site — we will return with an assessment and a plan for which mode will give the effect first.
Work stages: from data audit to handover to operation
We carry out the work in stages, each ending with a verifiable result: the next step does not begin until the previous one is accepted. This way, mismatch in the control loop or a data deficit surfaces at an early stage — when a fix takes days, not a rework of the entire system.
- Data audit. We analyze what has already been recorded from the sensors, on which routes and in which modes, where the gaps are, and how previous datasets were labeled. The output is a list of scenarios that are missing for training and validation.
- Control loop diagram. We fix the connections of perception, route planning, and actuators, the locations of limiters, and behavior when an individual channel fails. This is the reference document for all further tuning.
- Data preparation and labeling. We add the missing scenes, remove outliers, and split the sample so that the validation part does not overlap with the training one. Otherwise, metrics on the bench are good, but on the track the system behaves differently.
- Sensor calibration. We bring sensor readings into agreement with each other and with the vehicle coordinate system, and check on reference objects: a mismatch of a couple of degrees causes false braking on a flat section.
- Testing at the proving ground. We run scenarios of increasing complexity — communication loss, signal substitution, channel failure. Each run writes a log, which we use to analyze the cause of the deviation, not just the fact itself.
- Acceptance and handover. We show metrics on an agreed set of checks, hand over configurations, diagrams, and the update procedure, and train your team.
At each step it is visible which scenarios are covered, which remain, and with what margin the system operates — handover is based on facts, not promises.
What remains with the customer: models, diagrams, and procedures
Handover of a solution is not a final presentation, but a set of artifacts by which your team itself updates, rolls back, and explains the system's behavior. Each item is verifiable: if the result cannot be reproduced from it without us, it is not considered closed.
- Trained models — weights in reproducible form, pinned versions, metrics not only average but also by slices: night, precipitation, dense traffic, non-standard maneuvers.
- Labeling and datasets — raw and labeled sets, labeling rules, procedure for resolving disputed cases, share of cross-validation.
- Integration diagram with the dispatcher — exchange points, message formats, timeouts, command priority, and the procedure by which a human takes over control.
- Operator action procedure — what is visible on the screen, under what conditions a maneuver is confirmed, how to act when the communication channel fails.
- Data access policies — modes for reading telemetry and recordings, retention periods, anonymization, log of access to sensitive sets.
- Build configurations — pinned dependencies and parameters so that six months later the environment builds to the same state as at acceptance.
- Acceptance scenarios — a list of checks and threshold values by which you yourself accept the next release.
- Documentation — artifact map, analysis of frequent failures, and the person responsible for each layer.
The package is considered closed when your team has performed retraining on new data and rolled back a version without our participation.
Case study: autonomous equipment in an enclosed area
Pilot operation was launched at a quarry with dirt roads: six pieces of equipment, route "loading — hauling — unloading".
Before that, the vehicles drove under remote control: an operator guided one or two units and intervened on average once every six cycles — to correct the course at the shoulder, drive around a puddle, confirm crossing an intersection.
The cycle took about 14 minutes, and false stops accumulated at 10–12 per shift: dust, slanting sun, and reflections on the body were read as an obstacle.
What was changed
We retrained perception on our own dataset from the site and added temporal consistency between frames and sensor channels — a single outlier such as a dust cloud or reflection no longer causes braking.
The planner received a coverage map and speed limits where a human may be present, so some confirmations were removed from the logic. Everything is computed by a production compute module NVIDIA — without custom electronics that are hard to service in the field.
| Metric | Before | After |
|---|---|---|
| Share of cycles without operator intervention | 84% | 97% |
| False stops per shift | 10–12 | 1–2 |
| Cycle time | ~14 min | ~10.5 min |
Cycle time fell not due to speed: pauses for confirmation were removed and the acceleration and braking profile was rebuilt. One operator now supports four units instead of two.
Each intervention and stop is analyzed using a recording fragment, so the next release closes specific scenarios rather than "improving everything at once." The metrics hold both in rain and in darkness.
What to do if telematics and dispatching are already implemented
Telematics and dispatching are already working — this is more the rule than the exception. The loop is assembled, vehicles are on the line, data is written for every trip.
The question is not what to build from scratch, but how to embed an intelligent layer without stopping the fleet and without changing onboard equipment.
Integration with existing telematics and dispatching goes through the interfaces that already provide data: we do not touch controllers and sensors, we read the stream that is generated onboard.
Backward compatibility is maintained through parallel connection — the dispatcher's office works in the same mode, operators are not retrained, and the output of the intelligent module comes as an additional feature: a warning, a risk assessment, a route prompt.
Data migration is a separate step. Historical archives of trips and events are unloaded into the new loop, brought to a unified format, and serve to tune models on the real behavior of a specific fleet: the model learns on your routes and your driving style, not on averaged data. Access is segmented, and the data remains in your ownership.
Next is gradual expansion. Pilot launch on a limited group of vehicles: we compare readings with current telematics, look at the share of false activations and reaction time. Then we add the next class of tasks, and each step builds on the previous one.
Embedding into the current loop therefore proceeds without stopping processes: first parallel operation and comparison of results, then transferring the function to the main mode.
Failures on difficult roads and false activations: common doubts
Doubts usually concern not the model, but the behavior of the system at the boundaries: communication is lost, a sensor goes silent, a scenario has never appeared in the sample. Below are four explanations with technical answers.
What happens if communication is lost on the route?
The vehicle does not stop where the loss caught it: the map and traffic rules are onboard, the autonomous loop reduces speed, keeps it in the lane, and stops in a permitted place. The operator channel serves observation and task assignment, not motion control.
A sensor has failed — will the system notice?
Critical channels are duplicated and physically separated. Discrepancy in readings is checked against the map and the other channels: the failed one is disabled, the vehicle switches to the backup and reduces maximum speed. The event is written to the log with a timestamp.
There is little training data — will rare scenarios remain uncovered?
We collect rare cases purposefully: labeled runs at the proving ground, synthetic scenes, augmentation of recorded fragments. Acceptance counts the share of closed scenarios from the list of dangerous ones, not average accuracy — following the logic of ISO 21448.
How is control handover to the operator arranged?
This is a protocol, not a button: request, confirmation from both sides, allotted reaction time. If the operator does not respond or the channel has degraded, control remains with the onboard automation — it maintains a safe mode.
Passenger safety is a property of the entire system, not of a single model: channel duplication, independent control of decisions, and the actions described in each situation above. These checks also form the basis of acceptance tests.Let's discuss the task: operating mode and delivery scope for the facility
To return with an assessment and work plan, and not with general timelines, we need inputs on the facility. They determine the delivery scope, the depth of checks, and which stages will proceed in parallel and which only sequentially.
- Type of facility and movement scenarios: dedicated lane, enclosed site, warehouse logistics, or mixed traffic — the operating mode of the control loop depends on this.
- Onboard composition: which sensors and compute module are already installed, what can be added without reworking the body and wiring harnesses.
- Requirements for failure behavior: stopping at a safe point, handover of control to the operator, duplication of communication channels.
- Data: run recordings, telemetry, labeling, incident logs — the behavior model is tuned and tested on them.
- Verification loop: proving ground, simulation bench, and the share of scenarios that must be closed before acceptance.
- Timeline constraints: when the first working loop is needed, and when acceptance and handover to operation are needed.
- Whom to coordinate with: who on the customer side accepts the result and remains responsible for operation at the facility.
Describe the task in whatever way is convenient — in text, a route diagram, or a list of scenarios. We will return with an assessment, a stage-by-stage work plan, timelines for each stage, delivery scope, and distribution of responsibility between the parties. Let's discuss the task before designing anything.
