This page is about the next steps and therefore the potential improvements that could be made to the application

Table of Contents

• 1. General
• 2. Home
• 3. Downtimes
• 4. Vehicles Overview

1. General

• transforming the batch data pipeline into a real time streaming data pipeline using for example Apache Kafka
• changing from batch automotive fleet data to API requests from real automotive fleets
• optimize the fit of our prediction model by tuning the values for
  • Learning_rate
  • Max_depth
  • N_estimators
  • Gamma
  • Alpha
  • Lambda
• improve the data foundation
  • each row should represent an update from a vehicle during its drive instead of a finished journey

improving the dashboard views as follows:

2. Home

The following features could not be fulfilled due to time and resource constraints, but they would definitely benefit the end user of this view.

• Enable the user to filter the dashboard and its different graphs using the date-picker.
• Costs prediction: in order to enable quick business decisions based on key figures, the end-user should be able to see predictions about the development of costs. For example, the development of the maintenance costs of a vehicle could be predicted based on the construction year and the driven miles. The end-user would be able to use this information for future planning purposes.
• Delayed vehicles: in present, the dashboard informs the end-user about the delayed vehicles and their positions. We are planning to improve this feature and also deliver the reason of the delay and eventually suggest better routes. In order to do this, we would analyze the duration of the stops, we would gather traffic information regarding traffic jams and construction sites and another relevant information, which would help the algorithm determine the cause of the delay. On the other hand, using this analysis, the algorithm could inform the driver/fleet manager about traffic jams and/or construction sites and suggest better routes.
• Another interesting suggestion would be the prediction of the carbon footprint development. This way, the end-user would be able to make improvements on e.g. vehicles in order to reduce the emissions.

3. Downtimes

• Enable the user to apply multiple filters on the different graphs.
• Add accident probability prediction: using sensor data from different parts of the vehicle, we would be able to predict whether a certain vehicle is at higher risk to cause an accident due to technical problems.
• Optimize calendar visibility: make it editable, filter by date or by weeks

4. Vehicles Overview

4.1. Realtime Map:

• Enable the user to filter the map: Due to the library Dash we were not able to do this. It is not possible to use the position points as input for a callback. Therefore it is not possible to filter from a map. Also in the other direction this is only partly possible, so the position points on the map are the callback output.

Here are two more features we thought about to increase the value of the map:

• Include status and traffic warning An additional data basis in form of a csv file or an API would be required for the integration of traffic warnings.
• Display routes of filtered vehicles The implementation was not possible for us due to our data basis. However, since we only had one position per day, it would have been an important function for the business case to simplify the management of the automotive fleet

4.2. Vehicle Overview

• Connect bar chart with filter underneath To make the dashboard even more interactive, interactive filtering from graph to table would be very helpful. Similar to the realtime map, however, you have the problem that you cannot address the corresponding columns of the dataframe via the legend. The legend dots cannot be used as a callback input, so filtering from graph to table is not possible.