From 2016, the entire MotoGP class will switch to a single, spec software for the electronics on the bikes. Development of the software is to become a collaborative process, with the factories competing in MotoGP supplying code and requirements through a single website.
This much we know. But what we don’t know is much more interesting. Which technologies will be supported? Which functions will be available? How sophisticated will the software be? Who will lead the software process, the factories or Dorna?
To get answers to all of these questions and more I spoke to MotoGP’s Director of Technology, Corrado Cecchinelli at Silverstone. He is the man in charge of the process of making the switch to the spec, or unified software, as it is now being called. Cecchinelli will manage the development process, and define the goal of the unified software, trying to create a level playing field for all of the competitors.
It was a long and interesting interview. We covered many subjects, from the logistics of the development process, to the technologies which will be allowed, to what Cecchinelli sees as the objective of the software, and the goals it should achieve.
Cecchinelli described in some detail how the development process for the unified software is to work, and how the process will be managed. It will be a collaborative process, but it will not, as some fans had hoped, be a fully open process, with fully public access to the code.
Cecchinelli then set out his vision for the unified software, both in terms of implementation at the track and its application in production bikes. The goal is that any MotoGP-level electronics engineer should be able to extract the maximum performance from the software, rather than requiring mastery of an arcane and excessively complex piece of software.
It should be fully usable by the engineers in the independent or non-factory teams, allowing them to use the software to its full potential. This is one of the complaints made by the Open teams at the Sepang test at the start of the year, when they were handed an extremely powerful, but extremely complex software update. The update was soon dropped, in favor of an evolution of the existing software.
Cecchinelli’s vision of how the unified software should be applicable to road-going machines makes for interesting reading. The aim is for technology developed at the track to be directly transferrable to production bikes. That does not mean restricting technology, but rather focusing it on making it usable for all riders.
The idea is not to remove traction control and engine braking, but to keep them relevant to production bikes, and improve rideability. Though the software will still allow turn-by-turn settings, Cecchinelli made a strong case for why it should be removed, and the focus switched to other technology areas.
The aim, Cecchinelli was keen to emphasize, was to prevent factories getting into a spending war over extreme performance, and make them focus instead on providing the rider with a more rideable package.
Cecchinelli admitted that the unified software would not stop factories from spending money, but his aim was to limit the return on throwing ever larger resources at the field of electronics which had no direct relevance to MotoGP. We started on the subject of the development process, and where it stands at the moment.
David Emmett: As I understand it, the championship software is to be developed by Magneti Marelli, together with the factories, all of the factories will be able to have input, and it will be done by a collaborative website. First of all, how far along are you with the project?
Corrado Cecchinelli: The idea, and at the moment, it is still only an idea, is to do like you say. We handle the project, and the way it works is that we can have some sort of spontaneous or natural evolution of software. I can have ideas, the Marelli guys can have ideas, and so we will introduce them.
Or evolution as requested by the end users, which will be everybody, including the manufacturers in 2016. And yes, the plan is to make the process more formal and public and fair, by means of a tool on a reserved area on our Sharepoint server.
We will have an area where all the restricted area permit holders, will have the chance to input their requests, so we will evaluate them, and after saying yes or no, we put them in a priority, and that priority will be public, and everyone will know what’s going on.
Which is more or less the way it is working now with the present Open software, but it’s a less refined approach now, it’s just a mailing list.
DE: A little bit like bug tracking software … Will every request be public, or will the request be private, and only go public when the request has been evaluated?
CC: The idea is that all the requests, if you want us to consider your request, you have to put it there, so it will be automatically public. But public means open to the other members of the list, of the allowed list, which will be one or two people per manufacturer, something like this. It will not be an open website, open to the public. It will be a restricted area on a website.
DE: So it won’t be completely open source, so I could not go to the website and look at the source code?
CC: You will not have this chance. But all the participants will. So it’s a matter of defining the dimension of this group. Some of them will have write permission, others just read permission, but these are just details.
DE: Who will be leading the direction of the software? Will it be Dorna and Magneti Marelli, or will it be the factories.
CC: Actually, it will be myself. I will in the end take all the requests into consideration and decide which ones are yes and which ones are no, and order the yes ones into a priority. Which answers your question, because in the end, this is the direction of the software.
Of course, it must be an organic process. So sometimes if you want to do this, you have to do that beforehand, so the direction is not that free. You are not free to pick just one of the activities and do that, because maybe you will need to do something before that, and probably the outcome will be that you will have to do something else before that. But in general, I’m free to decide.
The tool I’m talking about is very close to being ready at the moment. I am the only allowed user, I’m training myself to use it. If we are talking about 2016 common software, we will be ready well in advance of when the manufacturers need it, because they decided that they will not participate in the evolution process, so as not to reveal their secrets, until a certain date [31st June 2015], when they will agree to freeze their proprietary software. So I think we will be ready with the tool in a few weeks’ time. And I think we will need it in years’ time. This is more or less the situation now.
If the tool is ready and it is working well, we can use it for the present software evolution by replacing the mailing list. I can use it with the Open teams with a different users list. I think we will do that, because it is also something which helps us in testing it, before the real proper use.
DE: Do you intend to use the Open software to control the more advanced aspects of the electronics? For example, will it still support a seamless gearbox?
CC: Yes.
DE: There’s a lot of complaints about the general level of electronics, is it your idea to restrict the level of the electronics, or to allow the factories to continue at the level they are now.
CC: This is a very big project which will involve different parties, because it will involve myself – the organizer’s side – the manufacturers’ side, the teams’ side, at the least. And I think there are at least two different opinions on this.
My opinion may be close to the teams’ opinion, but I don’t know, I can tell you it’s my opinion. My opinion is that it it should be something reasonable that is not science fiction level. For me, the idea is the present Open riders’ software, plus evolution.
We will continue with the evolution as it is now, but of course you can understand that once the evolution goes on with different partners, it will take a different pace. But still, the concept is the present software with evolution. Which is not the best possible in the world…
DE: So the goal is to make good, functioning software, not the most amazing software you can build?
CC: The goal is, there is something that we want to be at the top, but this is not performance, it is the compromise between ease of use and performance. This is what we want to bring to the top, and this is not what the factory software does.
They are not the best compromise of all, they are very complicated, almost impossible to understand by human beings, but the power is so high. So they are not the best compromise, they are the best performance. This is not what we are looking for, what I am looking for.
In this process, as I said, I think the teams, which means to me the independent structures, I think they will be with me, but I don’t think this is the idea of the big MSMA manufacturers. Because they ideally would like to get to the result of everybody having the same features as now, which of course is not possible. So I cannot tell now what will be the result in the end, but I told you what the idea is.
DE: So the idea is that an independent team with one, maybe two electronics guys can get the best out of the electronics package?
CC: My idea is that all the users have the capability to use it 100%. This is the idea, this is my concept. Of course, I think we have to put ourselves in the scenario where the level of the users is higher than now, which means that the potential can be higher than now.
Because I think that the manufacturers’ involvement will be more than now even in the non-factory teams. So I think the level will be higher, but that as the organizer, our goal is that anybody has the skills to use the full potential, so that it is fair in principle.
The goal is not as powerful as possible. In principle I would not like that the bigger you are, the more you can use the potential of the software. Of course, still, the bigger you are, the better rider you will have, and the better team, and everything. But I can work on my side of the equation, not on everything.
DE: So there hasn’t been a decision on what will be allowed and what won’t, whether the software will allow turn-by-turn adjustment, etc?
CC: This is not decided now, but there is the very high chance that my idea, which is starting from the present open software, will be the choice. Which means that we will have all the strategies, and they will depend on the position on the track.
Which, I have to say, is something I don’t like at all. Because it needs some tuning effort which to me is a waste, because it has no production return at all, not return on road bikes at all. I think that we as the organizer should feel the responsibility of steering the investments towards road-relevant areas. This is what I feel as my responsibility, which I am not managing to do, but I feel as a general, high-level goal. In this idea, turn-by-turn tuning for me is a waste of money.
DE: What would be a more relevant goal for production bikes? Throttle response? Fuel consumption?
CC: If we put ourselves in the present scenario, rideability for example. Which means a lot of things: engine brake control, traction control, all the present strategies can have an important return on production machines in the present scenario. I would like just to remove the possibility to tune them turn-by-turn, because this will save some useless work, and possibly, everybody will be forced to find a compromise solution, which again is more road relevant.
For sure, the result will be a machine that works as a better compromise everywhere, which is a more production-oriented bike. Then of course you can even think about a different scenario where something else is allowed which is banned at the moment: just to name a few, electronic suspension, ABS, things like this.
DE: Because ABS is going to be compulsory on production bikes in the EU from 2016, electronic suspension is becoming more common on road bikes…
CC: I don’t think this is the moment to introduce this, but they can be areas where it would be interesting to steer the investments. If we as the organizer manage to make the manufacturers spend their money in road-relevant areas, I think this is healthy for everybody, and in return, we have more chance that the sport will survive. Because it has a return. Because the manufacturers don’t see racing as a pure marketing cost, they want to have an R&D return.
But, although this is what they say, this is not what they actually look for.
DE: What they look for is success, at any cost?
CC: Yes. So my idea is that if you have a strategy that you can tune turn-by-turn, if you have ten people going around the track and making pictures and measure everything, you can tune it better. If you have twenty people, you can tune it even better. And there is no limit to this, because if you have 1000 people, it would be a little bit better than having 900. So you can still be tempted to spend money there. This is why we should remove some areas.
DE: You don’t think turn-by-turn has any use on the road? It seems to me that now, GPS is becoming ubiquitous, and more and more integrated into vehicles, they are already built in in cars. You don’t see the possible crossover between that and racing?
CC: No. I don’t see it at all, because first of all, as you know, GPS is not allowed in MotoGP. The way it works is completely different, and completely senseless for production machines, because it’s just counting the wheel turns and resetting it at any split timing loop.
But even if we allowed the GPS to be used, first of all, at the moment, GPS technology is not accurate enough. This is not a motorcycling problem, a problem of people operating in the motorcycle business. But even if in the future, it becomes so accurate that it can be good for the goal, still the problem is that knowing where you are on a road is not enough.
Because if you know where you are on a track, you know the road camber angle, the surface friction coefficient and whatever you would like. But if you know where you are on the road, there is no use for it, unless you have all the world mapped with the camber, the steepness of the road, the friction coefficient.
And still you don’t know anything, because if it’s wet, or dirty, it changes. So I don’t see any potential use of changing the strategies depending on the place where you are.
The only use I know of is that I think I read that the Nissan GTR goes only full power only in proximity of a track. So this is maybe the only use of different strategies depending on the place. But this is not depending a corner, it’s just depending on whether you are on a track or not.
DE: So to summarize, the goal is that you want powerful software, but only so powerful that any well-trained, efficient engineer can extract maximum potential from the software?
CC: I don’t see any other value in getting the extra 10%. You will not notice on the TV, and the show will be possibly worse.
Photo: © 2014 Scott Jones / Photo.GP – All Rights Reserved
This article was originally published on MotoMatters, and is republished here on Asphalt & Rubber with permission by the author.
Comments