Real-Time Data Processing in 2W EVs

Software @Ather is about bringing forth few exciting application building strategies to make it robust and also as contemporary as possible. Many a times there were questions asked on what is the secret sauce of software @Ather especially EVs? How does it stack up with other e-commerce applications that we know about? Here is an attempt to showcase the same.

Real-time data is something quintessential to the EV segment. Electric vehicles are capable of sending detailed information about their current states from each of the units of control (ECU) and IoT sensors, that are in place. The amount of data generated potentially goes up to 100s of KBs per second and up to 10s of GBs per month, per vehicle. 

What is the relevance of all this data? 

The data sent by each vehicle provides insight about its running state, and also highlights any deviation of the current state from the actual state of each ECU. All the ECUs work together to relay this information that is processed as metrics/errors on the cloud, as shown in the diagram below.

Data is sent at a very high frequency via the IoT broker to the cloud. This stream of data is continuous and has aggressive reconnection strategies. The IoT broker pushes data via topics using a Messaging Queue(MQ). MQs are set up with different topics that work heterogeneously around raw data collection, sorting of data by time and vehicle, cloud storage at different stages of processing, and pushing the data to processing units to churn out useful information on the dashboard for users/riders. The dashboard data could be strictly internal like the vehicle’s health, current state of the battery, errors, etc. On the other hand, data sent over via backend applications to the mobile app, can help convert them into features which are customer-facing.

Let's take a look at customer-facing features like understanding the current state of charge on the battery and sending information to the customer both on the vehicle dashboard and on the Ather mobile app. If you see the complexity of this system, data has to be processed in real time and processed data/features have to be delivered to both, the internal-facing dashboard and the customer-facing app. Each vehicle is sending this information to the cloud every second and the processing needs to happen at a pace that ensures that all relevant data points have been collected, or are being well formed. There are many possibilities that can arise during real time processing. For instance, take someone who travels 30km to and from work. On their way back, if the charge is < X% there may be a need for identifying the nearest charging location based on GPS. This triggers a Navigation notification to the customer which helps them not only remember to charge the vehicle, but also help them get to the nearest charging point.

With reference to the above example, data processing speed or the capacity at which data has to be drawn, parallels the way typical e-commerce applications handle large volumes of requests when customers are using their platforms. One key difference to highlight here, is that on two-wheeler EVs, data comes in consistently at the same frequency whereas in e-commerce use cases there are times where request volumes are low i.e. it’s a distributed volume across the day where there would be peaks and troughs seen on the platform. So, from a capacity standpoint data handling architecture is almost the same, whereas in the two-wheeler EV segment, data would sit somewhere very close to mid-peak to peak by volume scenarios in comparison with the e-commerce applications.