You set the working conditions, Akılkent compares the routes.
Your vehicle list, collection points and working hours come together. The software evaluates different visit orders and presents the result as a map and a report. You do not need to know any algorithms to use it.
A good route is not just a short road.
Can the vehicle enter that street? When should it unload? Does the work fit the shift? For a plan to be usable in the field these questions must be answered together. Akılkent accounts for the following working conditions:
- Different vehicles: vehicles with different capacities and speeds are planned together
- Point-vehicle compatibility: each point is assigned only to a suitable vehicle
- Unloading returns: when full, the vehicle goes to the facility and continues its route; this time is in the plan
- Working hours: the shift length you set is respected when planning
- Multiple trips: where there is a transfer station, a vehicle can make more than one trip
- Collection points: every point is assigned to a suitable vehicle; if capacity or shift length is insufficient, unassigned points are listed separately and the additional vehicle need is stated
How is the route plan built?
For thousands of collection points a vast number of visit orders is possible. Akılkent first finds a feasible plan, then evaluates better alternatives. Technically this is a hybrid search method.
Groups the points
Points are divided into zones by geographic proximity, vehicle compatibility and capacity. Each zone is a candidate vehicle shift.
Builds the first route
A first route is built for each zone using real road network distances. Unloading returns and the shift limit are placed in the plan at this stage.
Improves the visit order
Points are moved between routes and visit orders are changed. Every change is evaluated for fuel and time; changes that worsen the solution are rejected.
Compares alternative plans
Different route layouts are tried. The best plan found within the allotted time is presented; this does not mean the best of all possible plans is guaranteed.
Distance and time are computed over the real road network, not as the crow flies; one-way streets, turn restrictions and heavy vehicle bans are reflected in the plan. Fuel consumption and carbon emissions are part of the objective function. They are not a report prepared afterwards but criteria that shape the route.
Planning that learns from experience
This module is not a ready-made route library; it is an original solver our team designed from scratch. Instead of planning every area the same way, it acts on the structure of the data, reuses what it learned from previous solutions on similar jobs, and verifies its own results separately. Details of the method are not disclosed because of a pending patent.
What it does
- Analyses the structure of an instance before solving it; chooses the construction and search strategy accordingly
- Records what it learns from every instance it solves and uses it on similar instances
- Computes a lower bound for the solution it finds; when the bound equals the solution, optimality is proven
- No result is accepted on the solver's word alone. A separate verifier recomputes distances and checks coverage and capacity rules
What it brings
- Every district is different. A narrow-street old centre and a wide-boulevard new neighbourhood are not solved with the same strategy; the solver makes that distinction itself
- Builds on previous solutions: assesses which methods worked on similar planning jobs
- Solution quality is measurable: how close the solution is to the best possible is reported numerically
- The core is written in C++; in large districts where runs take hours, intermediate results are saved safely
Details of the method are not disclosed while the patent and publication process continues.
Solver options
All options use the same model and satisfy the same constraints; the difference is the search budget, that is, solution quality versus time. The field supervisor chooses by the needs of the day.
| Option | When | What it does |
|---|---|---|
| Fast planning | 1–2 minutes. Daily revisions, vehicle breakdowns and emergencies. | Applies a construction solution and a short local search; renews the plan in minutes. |
| Balanced solution | 5–10 minutes. The standard daily collection plan. | Accounts for container fill uncertainty probabilistically and uses the full search budget. |
| High quality | 10 minutes and more. Weekly planning and fleet sizing before tenders. | Uses an uncertainty-robust model and a deep search; aims for the shortest total road with the fewest vehicles. |
| Expert mode | For institutions that request it. | An additional search method is enabled in the final improvement stage and the time split can be tuned. A worse solution is never accepted; the route never gets worse. |
| Planning that learns from experience | Across different area structures and repeated planning jobs. | Picks the method from the structure of the data, builds on previous solutions and verifies results separately. |
Validation: first against exact solutions, then with real data
| Step | What was done |
|---|---|
| Mathematical model | The problem was modelled as a mixed-integer programme; optimal solutions were produced with a commercial exact solver on small instances. |
| Heuristic validation | The hybrid solver was compared with these exact solutions. On instances of up to 259 nodes it was also benchmarked against a widely used open-source solver. |
| Real data | A model analysis on the vehicle, container, shift and road network data of a metropolitan district municipality. Non-value-adding time fell from 30.9% to 6.2%, fuel consumption and emissions by 34.5%, with every container covered. |
| Independent review | TOBB ETÜ Industrial Engineering graduation project and poster first prizes; first place in Türkiye among 106 teams at the YAEM 2026 Congress. |
| Time | On the 27-vehicle shift data of a metropolitan district, a district-wide plan was produced in under 20 minutes; the time depends on the number of points and vehicles. After a vehicle breakdown or roadworks the plan is regenerated in the same time on the same data. |
The results are based on an academic analysis; the routes have not yet been driven in the field. Savings measured in a pilot will be published on this page.
Comparison by approach
No product names are given; each row represents a type of approach and summarises its typical state, individual products may differ.
| Approach | Collection-specific constraints | Extra hardware | Data in country | Emissions |
|---|---|---|---|---|
| Akılkent | Six constraints in the core: heterogeneous fleet, point-vehicle compatibility, unloading returns, shift length, multiple trips, full coverage (details on the Solid waste page) | Not needed | Domestic hosting or on-premise installation | In the objective function, per vehicle |
| Hardware-based smart waste platforms | Yes | Sensor and terminal per point and vehicle | Mostly foreign cloud | Limited |
| General-purpose route software | Usually not; designed for parcels and delivery, varies by product | Not needed | Foreign cloud | Limited |
| Vehicle tracking systems | Usually not; tracks vehicles, does not plan | Vehicle device | Yes | Limited |
| Open-source solvers | Partly; requires modelling expertise | Not needed | Depends on the institution | Mostly outside reporting |