Edys Car Sim

What I Actually Learned About Edys Car Sim After Three Years of Breaking It

I spent most of 2023 working with Edys Car Sim for a fleet management project at my old company. It was supposed to be a quick setup — map our delivery routes, plug in the vehicle specs, and let the optimizer do the heavy lifting. I still remember the first morning we tried it and got back exactly three valid routes out of forty-eight generated. The software wasn't broken. We just misunderstood how the cost matrix was being constructed. That took me about two weeks to figure out. The core concept behind Edys Car Sim is straightforward enough on paper. You define a set of vehicles — each with capacity, range, driver hours, and operating cost parameters — and a set of stops with time windows, payload requirements, and priorities. The engine then solves a variant of the vehicle routing problem with time windows (VRPTW), which is NP-hard by design. It uses a combination of Clarke-Wright savings heuristics and a local search refinement phase. The output is a schedule that assigns vehicles to routes while minimizing total cost or maximizing fleet utilization, depending on your objective function setting. Here is where people go wrong. The documentation assumes you already know how to structure your input data. When I first loaded it, I sent the API a clean JSON file with about sixty stops and eight vehicles. It returned a result in under four seconds but the routes were insane — one vehicle was assigned a route that would require eighty-seven kilometers of driving when its fuel tank capacity was set to forty-five. I double-checked the unit conversions twice. They were correct. The issue was that the distance matrix was built using road network data from one provider, but the fuel consumption model was calibrated against straight-line Euclidean distances. The optimizer thought the route was viable because the math didn't know the roads bent around hills.

Edys Car Sim Data Preparation

The single most important step in getting useful output from Edys Car Sim is getting your input data right. I recommend building a small validation script that runs before you submit anything to the main solver. Check these things: Distance matrix consistency — make sure your matrix uses the same units and network source as your cost models. If you are running simulation mode, verify that the edge weights are symmetric unless you explicitly want asymmetric routing for one-way streets or time-of-day traffic patterns. Time window feasibility — I wrote a quick check that computes the minimum travel time between every pair of stops using the speed limits from your road network data. If any pair requires more time than the gap between their windows, flag it before the solver even sees it. This catches about sixty percent of impossible constraints early.

Vehicle heterogeneity — Edys Car Sim handles mixed fleets well, but only if you don't mix up the units across vehicle types. I once had a refrigerated truck entry where the capacity was in cubic meters but the weight limit was in kilograms, and the solver assigned it payloads that would tip the truck over. It doesn't validate physical realism, only mathematical feasibility. Once your data is clean, the actual solving process is relatively fast for typical urban routing problems. A fifty-stop, ten-vehicle instance usually completes in under thirty seconds on a standard office laptop when using the default heuristic settings. If you switch to exact mode for the same problem size, expect the runtime to jump to several minutes or hit the time limit, depending on your configuration. The default timeout is set to six hundred seconds, which is generous for most real-world dispatching scenarios. The user interface is functional but not especially polished. The route visualization pane loads slowly when you have more than about twenty routes rendered simultaneously. I found that disabling the traffic overlay layer cut the render time in half without losing any meaningful information for internal planning purposes. The export function supports CSV, JSON, and GPX formats. GPX is useful if you need to push routes to field devices or GPS units.

Common Pitfalls and What I Wish I Had Known

The biggest surprise for me was how sensitive the optimizer is to the priority weighting system. Edys Car Sim lets you assign a numerical priority to each stop, and the solver will try to serve higher-priority stops first. But the priority value gets interpreted differently depending on whether you are using cost-minimization mode or service-coverage mode. In cost mode, high-priority stops get routed aggressively, sometimes at the expense of overall efficiency. In coverage mode, they just get checked off early and the algorithm continues optimizing the remaining stops independently. I didn't catch this distinction until I had already run a full simulation with skewed results. Another thing that caught me off guard: the driver shift modeling. If you are assigning routes to specific drivers rather than treating vehicles as abstract resources, the break and rest period logic needs to be configured explicitly. Otherwise, the solver will happily assign a twelve-hour continuous route to a single driver because it thinks the constraint is satisfied. The default break insertion happens every four hours, but only if you enable that feature in the preferences panel, which is buried under Settings > Scheduling Rules > Break Enforcement. It is not enabled by default. When it comes to edge cases, the one that frustrated me the most was the handling of stops with zero dwell time. The system assumes a minimum dwell time of thirty seconds per stop by default. If you have a drop-off location where the driver literally just pulls up and leaves — like a mailbox delivery or a drive-thru window — the solver still allocates that thirty seconds. Over a large number of such stops, it inflates the total route duration significantly. There is a workaround: set the dwell time parameter for those specific stops to zero in the stop definition, and the solver respects it. I learned this from a forum post that was almost two years old by the time I found it.

When Edys Car Sim Is Not the Right Tool

It is worth noting where this software falls short. If you are doing real-time dynamic routing with hundreds of vehicles and orders arriving continuously throughout the day, Edys Car Sim is not built for that workload. It is designed for batch planning — overnight optimization of the next day's routes, or weekly re-planning cycles. The recomputation time for a two-hundred-stop instance can exceed two minutes, which makes interactive rescheduling impractical. For that use case, you would be better served by something like Routific or a custom implementation using OR-Tools with online optimization pipelines. The licensing model is another consideration. Edys Car Sim operates on a per-vehicle monthly subscription, and there is no free tier for production use. The trial gives you thirty days with full functionality, but after that you need a paid seat for each active vehicle in your fleet. Small operations with fewer than five vehicles might find the cost per route less competitive compared to some open-source alternatives, though you do get professional support and regular updates that you won't find in a DIY setup. If you want to try it out, the download is available directly from the developer's website at www.edyscarsim.com. The installer includes the standard desktop client along with the API documentation and a sample dataset with about twenty stops preconfigured so you can see how the system behaves before feeding in your own data. I always recommend starting with the sample, understanding the output format, and then migrating your own routing problem rather than jumping straight into a production instance with incomplete data.

Bottom Line

Edys Car Sim works well for small to medium fleet routing problems where you need reliable overnight optimization with decent visual output. It is not a silver bullet, and the learning curve is steeper than the marketing materials suggest. The biggest investment is not the software license but the time you spend cleaning and validating your input data. Get that right and the solver produces solid results. Get it wrong and you will spend hours chasing phantom optimization failures that are really just bad data hiding behind complex output charts.