Hi. Good afternoon, everyone. Thanks a lot for the kind introduction, Guro. And the other thing is, yeah, your session sort of set a very good context to what I'm about to present. So my name is Shivaram. I'm a part of the Controls and Systems Intelligence team at Ather Energy.

I'll start off by introducing what we do as a company. So you would have seen the previous one-minute video which showed you a glimpse of what our product does. So this company was founded in Chennai in 2013 by Tarun Mehta and Swapnil Jain, who are graduates from ITT Madras.

And then we moved to Bangalore in 2015. This particular scooter that you saw was launched on 5th of June, 2018. And we shipped the first scooter out on 11th of September, 2018. These are some of the specs that you can also find on the website. But essentially, it's a high-performance, intelligent, smart electric scooter with a bunch of features where you also have access to all the scooter information on your app.

So this is—

Meet Point. Point is an electric vehicle charger. You will find Point at your favorite cafe, restaurant, at work, at the gym, at your favorite watering hole—no. Bad idea.

Simply put, you're never more than 4 kilometers away from a Point. Point charges your vehicle pretty fast. It's easy and takes care of the tiny things. Have an electric car? No problem. You can find a Point on the app or on the dashboard if it's an S340.

And if you don't see a Point, ask for one. We are starting off with a few. But you will soon find more in your city, in other cities, and across cities. Ather Grid, an electric vehicle charging network.

So when we started designing the scooter, especially an electric one, we realized that unlike petrol bunks, you don't have as many charging infrastructures across the city. So that's the other thing we sort of started building. We wanted to figure out some sort of a charging infrastructure across the city so that customers don't feel range anxiety when they're riding a scooter. So the small radio that you saw is another product that we developed which is the charging infrastructure. So that has also been installed across various parts of Bangalore.

So now, coming to what I do at Ather.

Wouldn't it be nice if scooters were intelligent? If they already knew where you're going and the best way to get there. If they could figure out problems before the outcome, if they could even update themselves from anywhere. If they did all of these in the background, and all we had to do was press a simple button.

If they even made themselves more simple, if they made every hassle of owning a scooter disappear so that we just get to enjoy the ride. That would be nice.

All right. So that sort of gives a very brief glimpse of what I do at Ather. So like I said, I work for the Software and Intelligence team, of which I work in the Controls and Systems Intelligence team. So I've shown you a bunch of stuff about the product; enough of the marketing. Now I'll go to how we went about achieving this.

So as a startup, a lot of us are either fresh or really young engineers. And without the kind of resources that the other big companies have, we faced a lot of challenges. So I'll briefly take you through the challenges that we faced. And then take you through how we went about overcoming them one by one.

So one of the first things that we wanted to target in the product is that we wanted it to be very customer focused. Because this is a completely new scooter in the sense that it is a lot more powerful than all scooters you have out there. It has a lot more other features.

So something like navigation, you have never seen navigation on your two-wheeler. So that's another feature that we wanted. So all of these sort of show the kind of customer focus that is there in the features of our scooter.

So what that added as a challenge is that the number of things that we had to account for were way too much. So like I said, when we started designing an electric scooter, we realized that you don't have charging infrastructure in the city. So then we went about designing charging infrastructure in the city.

When you design charging infrastructure, you have to understand how we are able to charge the battery. What is the optimal way of charging the battery in a manner that you know you don't either overdesign your battery or charger, but at the same time the customer should be able to charge it fast enough? So those sort of conflicting situations, there are quite a few.

The second one is lack of benchmark data. Since this is first of a kind, we don't really have or we didn't really have benchmark data against which we could say that this is what is out there and this is what we need to improve on. Where that, again, complicated things for us is we didn't know how exactly this product would be used finally by the consumer.

Because this is going to be designed the first time, used by the customer for the very first time, we didn't know how to go about deciding how the usage of the product would happen. Because what that then results in is that we don't know at what point we should stop the design. We don't want to overdesign because we think that maybe people will ride 25 kilometers a day.

So we think that maybe in a big city like Bangalore, maybe people ride roughly 20, 25 kilometers a day, up and down. But that's probably not true. Right? Things like that.

Similarly, in terms of charging, where we don't know how exactly electric vehicles are charged, where they charged. That sort of benchmark data is not there for an electric vehicle. So usage model was very difficult. And that, again, resulted in complicated system design.

Testing challenges, as I mentioned, we are a young startup with a whole bunch of very young engineers, not a lot of resources. And obviously, there's a lot of investor pressure. For the folks who are from startups here, you know what that environment is like. So that challenge was always there. And last but not the least, like I said, we wanted to add a bunch of subsystems and features to our scooter. So that, again, complicates the system. Because you have way too many interactions that you now need to handle.

So what did we do? So broadly, there are two parts. One is we went about doing—so this is where I said whatever Guro spoke about earlier sort of sets the right context for this. Because we were in a very similar situation that any system architect or system engineer would be in.

So the first thing that we had to do was make like a physical model of the scooter. So that helped us in a bunch of things like concept selection. What kind of cooling solutions do we need to use? Do we need to use maybe, like, what kind of suspension do we use? For all of those, we actually built our physical model that we built helped us in designing those.

Component sizing, like I said, again, in the earlier ad you would have seen that it says the range is 75 kilometers, and the 0 to 40 times 3.9 seconds, et cetera. So those are worries of customers. But based on that, we finally need to decide, okay, what should be the wattage of our motor? What should be the energy capacity of our battery? For those, again, the physical model that we built helped us in arriving at those.

And obviously, the algorithms that we have implemented, the controls algorithm, et cetera, et cetera, obviously the physical model that we had built was the first point of validation for those algorithms. Because we would do like a modeling sort of simulation. So I'll get into the details of that in a bit.

The second big chunk of work that we did was algorithm development. So a bunch of different kind of algorithms are needed. Because now you have a bunch of separate components. You have a battery. You have a motor. You have a transmission. You have suspension. Now you need to figure out how to make these work together.

So we need to design a bunch of algorithms that sit on any of these components and make sure that, as a system, the performance is optimal. So we had a bunch of supervisory algorithms. We had a bunch of control algorithms that could either keep the temperatures of the battery in check, voltages of the batteries in check.

And the other important piece that I thought to mention here is that we had to design a bunch of filters. So I mean, there's filters over here. So for that, again, we had to use—so over there, also the amount of complexity involved was quite high.

Coming to, so how did bat365 actually help us in what we did here? So for the physical modeling of electric scooter, your usual MATLAB, Simulink, Stateflow is obviously your first go-to point. But apart from that, we used a bunch of toolboxes from the Simscape platform. We modeled the battery. We modeled the motor. And the last two were very helpful when we had to do a lot of black box modeling.

So in a lot of cases, it's not very easy to do first-principles physics-based modeling for all the components. Or maybe you can, but it'll take a lot of time. And even if it takes a lot of time, maybe to get from 80% to 81% of accuracy, maybe you need to spend a lot of time and resources. So at that point, you decide that maybe it's not worth doing like first-principles model. So that's where you decide that, okay, maybe we can do empirical modeling.

So you design a bunch of tests. And then once you have those tests, how do you now say that you have some kind of curve fitting? But what we thought of doing is something like system identification, so where you have a bunch of inputs and a bunch of outputs. And you know the toolbox tells you how the output is related to the input.

Parameter estimation, again, for the components where we don't really have all knowledge of how exactly the subcomponents within that system works, we used parameter estimation. So we built a very basic first-principles physics model. We do a bunch of tests, get the inputs, get the outputs. And now try fitting this input and output to that particular model. And which will tell us that parameter A was so and so. Parameter B was so and so. So it was a slightly different approach to system identification.

Coming to algorithm development, as usual, my MATLAB, Simulink, Stateflow was our first go-to point. Apart from that, we used a Signal Processing Toolbox. Like I mentioned earlier, we had to design a bunch of filters. So for that, we used a Signal Processing Toolbox. Control System Toolbox we obviously needed for any kind of control algorithm design.

And post that, once we actually have a working algorithm on MATLAB and Simulink platform, the most obvious thing to do was directly generate code out of that and port it to the microcontroller. So for that, depending on what environment the algorithm was on, we either used the MATLAB or the Simulink Coder, and in some cases the Embedded Coder.

Like I said, I'll go into slight details of the two broad buckets that I spoke about. The first one is physical modeling of electric scooter. So in this, what we achieved was basically on one platform we were able to model all the three things that we think affect, in this case, right rate.

In our case the product is a scooter. So we want to see, okay, how exactly if the vehicle is driven, let's say from point A to point B, where you typically know maybe that—okay, I'll take an example. Let's say you're driving to your house, let's say, which is in Whitefield. Now we don't know how exactly the ride is going to be. So the first thing that we set out is we actually deployed like a very simple data acquisition system on a bunch of our employees' scooters. And we asked them to ride around town.

So with that data and with the help we got from the data science team, we were able to come up with a representative drive cycle. So we had our drive cycle for what an aggressive rider would ride like in the morning, what a mellow rider would ride like in the evening. So we had these representative drive cycles.

Because without these drive cycles, or as a broader topic the usage model that I was talking about, it's very difficult to decide, how do you design a particular system? So once we got those drive cycles, we put those through the model. And then we would look at various aspects of various components to see whether it is performing well within the range that it's supposed to be kept in, et cetera, et cetera.

So obviously, physical modeling, we had to go into details of modeling all the components. Like I said, in some cases we chose to do empirical modeling. So in the environment model, like I said, we had drive cycle model, ambient temperature model, road gradient, road undulations. So obviously we also had to take care of ambient temperature.

We wanted to see how the battery performs in summers but also in winters and if we are taking it to a different city. So right now, this product is available only in Bangalore. But soon we are going to be shipping it out in Chennai and Pune. So we want to know, Chennai and Pune normally being hotter, we want to see whether the battery temperatures are within check. So for that, we wanted some kind of an ambient temperature model.

Road gradient model to know what kind of slopes exists around the city to know if the model has the climbing capability in areas. Because we have to design the motor torque accordingly. We came up with based on the data that we collected.

We had to classify that based on aggressiveness also, because for an aggressive rider, the system will generally tend to be a lot more inefficient. All of those inefficiencies typically go out as heat, which means your components get more stressed thermally, the temperatures increase. We want to make sure that those are also within control.

And then coming to the vehicle. I spoke about the environment and driver, now coming to the vehicle. We have a model for the battery. We have a model for the motor and controller, the peripherals, the vehicle dynamics. And the other big chunk is the control algorithms. All the control algorithms that I spoke about earlier and the others, which are maybe slightly more trivial, all of that is, again, one chunk.

And again, as I mentioned, the models are of two kinds. You can either have first-principles model. Or it could be a data-driven model, or maybe a mix of both.

Now again, within the vehicle block, like I mentioned, you have this kind of split and how the various subsystems interact with each other. So now you guys might have a question as to whether we did any kind of validation. It's great to build a model. But unless it's validated, it's of no use.

So once we had the initial prototypes ready, we actually did a bunch of rides, controlled as well as uncontrolled, as I would call it. Controlled initially because we wanted to validate our model against at least some kind of control so that we know the rest of the parameters, how they're varying. So initially, a bunch of controlled rides.

And then, once we got data from that data validation, realized that the model was off. In so-and-so parts of the ride, it's not behaving well. We sort of fine-tuned it. So this was, again, a very iterative exercise.

Coming to algorithm development, so most of us are familiar with the V cycle that we typically follow for software implementation. We had to adopt that in a slightly different way. This doesn't look like a V, but it's probably, if you actually go through it, it's probably just a V cycle that looks slightly different.

So like I said, we will build the electric scooter physical model. We had a bunch of requirements coming in the form of a document. We built the algorithm model, again on MATLAB, Simulink, Stateflow environment. Put the two together, did a bunch of closed-loop simulations, what I call as modeling loop.

Post that, we go to the co-generation phase. And after the code gets generated, we did a bunch of software and loop simulation to see whether there is consistency between code and the model. But this was also, again, done on the MATLAB environment itself.

But most of you will probably point out that there are a few more aspects to V cycle than just this. But like I mentioned, for the constraints that we had, we had to limit what we use as a process. And I talk about what we plan to do for our next design. So over there, hopefully, we will cover a lot of the other aspects of V cycle, which will be very helpful tools.

Coming to the key takeaways. Like I said, testing time, testing efforts, resources are always a challenge, even for a big company. You can imagine how challenging it would have been for us. So this model plus Model-Based Design plus algorithm development went a long way in reducing testing efforts. Because like I said, a whole bunch of simulations were done on model environment or in a very controlled setup.

So what we could do was instead of testing like 100 cases, probably we would do a bunch of simulations which can run a lot faster. And maybe only, let's say the model is not able to capture, because of its accuracy, maybe let's say it's not able to capture some aspect of, let's say, battery or motor. Then in that case, only those 10 test cases are something we would actually go and perform. So that way we were able to save a lot of time on testing.

The second one being increased ease of implementing complex algorithm. So typically in software, your algorithm is going to be complex. And if you have to also hand code it, then there is the additional complexity. So one of the things where we were able to use these products really well is we focused all our efforts on actually making the algorithm complex because we didn't want to worry about, again, now hand coding that.

Because otherwise, it's like a two-step problem that you have to solve. So we focused all our efforts on the algorithm development. And post that, once we felt that the algorithm was good enough, we would just like, click of a button, we would just get the embedded C code. And then we would go ahead with the integration and testing process.

So field issues rapidly resolved. Any new product is bound to have issues. So when we shipped our scooters in September, we did face a bunch of issues initially. Again, where the Model-Based Design sort of helped us a lot is that because the models were on one framework, the physical model as well as the algorithm models, since they were all on one framework, we would actually like pull out the field data, play it back through the model, see where the model seems to be misbehaving or the algorithm seems to be misbehaving. And we could quickly fix the errors. And because you would have seen in the previous, this one, that we have ODS software update capability. So we were immediately able to fix issues on customer vehicles because of that.

One of the other things that I felt helped a lot is because Simulink, so when you have your algorithm on Simulink or a Stateflow sort of environment, in my opinion, it is also self documenting. Because you don't have to go out of your way and again document that. Because it's already graphical. And in a sense, it is already very like a flowchart, sort of self documenting.

So what that again helped us with is that in terms of navigation through the algorithm, let's say I had designed the algo, but someone else had to fix the issue because maybe I was not available. And because the algorithm is already in a graphical form, it's very easy for readability, traceability, navigation through the code. All of that becomes a lot more easier if it's not in the form of text. So that's one of the really key takeaways, I think.

So I mentioned that for at least the first generation of scooters, which is the Ather 450 and 340, our focus areas for Model-Based Design was mainly in coming up with an accurate plant model. Secondly, for development of the algorithms. One of the things that I probably forgot to mention here is that now that we have a lot of field data, we obviously can fine-tune our algorithm, all the things that I mentioned in the second bullet point. And with the ODS software update capability that we have, we can update the scooters with more improved algorithms. So that was for our first generation of scooters.

Now coming to, we have already started our work on second generation of scooters. What we will do here is that now we don't have to start from scratch to build a plant model. We already have a decently working plant model. It'll just be fine-tuning of certain things based on field data that we get.

The second being a very important thing for us because, like I said, earlier when we started off building our first product, we didn't have any like benchmark data to say that this is how scooter would be used, this is how it would be run, this is when it would be charged, things like that.

But now that we have quite a few scooters out there, we make use of that field data. And that will sort of form the core of our usage model. So hopefully, when we design the next scooter, we will use that as the basis to maybe—let's say we have overdesigned something in our first generation of scooters. Then we will be able to cut down on that.

The third bit is basically maximize use of MBD for software. So in the first generation, as I mentioned, our main focus area was using MBD to come up with a really good plant model, and also use it for like complex algorithms. But now what we plan to do is because we have seen the ease that we get when we use an MBD-based approach, we plan to maximize the use of Model-Based Design in a lot of our firmware.

So that's pretty much it. Thank you.