Routing Integration with third party software

Bytecurve360 includes integration with certain commercial routing software products like Versatrans / Traversa and Transfinder.  The integration works as follows:

  1. The ‘unit of integration’ is a Run.  This means that the interfaces will connect to the routing software and bring in all the Runs that need to be refreshed in the Bytecurve360 application.  Since a Run is called by different terms in different routing software products, this translates to pulling:
    1. ‘Routes’ from Versatrans
    2. ‘Trips’ from Transfinder
    3. ‘Runs’ from Traversa
  2. A Run in Bytecurve360 is defined as the path between the first student pick-up point and the last student drop-off point, the routing interface does not bring any references to terminals / yards / park-outs when bringing in the Runs from the routing software.
  3. The Bytecurve360 application includes multiple checks and balances tied to the assignment of vehicles and drivers to Route and hence driver/vehicle assignments are not included in the data pulled by the automated interface.
  4. Bytecurve360 requires two parameters for each Run for the application to function as designed:
    1. Dispatch type, which is one of ‘AM’, ‘PM’, or ‘Mid’ (for mid-day Runs).
    2. The days-of-the week the Run needs to operate

In most routing software, there is no provision to store this explicitly, and this information is often included as part of the Run description.   Bytecurve recommends that these parameters be coded explicitly in one of the user-defined fields that most routing software vendors provide.  If not provided, the routing interface will try to extract the values of these parameters from the Run description to the extent it is able to, and this could impact the proper functioning of the Bytecurve360 system.

  1. Packaging of Runs into Routes will need to be done in the Bytecurve360 application through the UI screens provided for this.  
  2. When Runs are packaged into Routes in Bytecurve360, the system calculates the ‘yard departure time’ based on the scheduled time at the first stop and the designated departure yard for the route, using Google’s mapping service to determine the drive time to the first stop.  Similarly, the system also calculates the ‘yard return time’ based on the time at the last stop and the depot the vehicle is designated to return to.
  3. When Runs are refreshed from the routing software, any change in the location or time of the first or last stop will result in an update to the yard departure and/or yard return times.  This may or may not update the task start or task end time, depending on the value of a flag that lets the system auto-update task times [additional details in the Scheduling section].
  4. The integration is implemented through automated interfaces with the routing software application, using the ‘Application Programming Interface’ (API) provided by the software vendor.  This requires additional set-up for the Bytecurve360 application to be granted permissions to access the customers route data in the routing software.