MotoGP

Everything You Wanted To Know About MotoGP’s 2016 Unified Software, But Were Afraid To Ask

Google+ Pinterest LinkedIn Tumblr

2016 heralds a new era for MotoGP. Two major changes take place to the technical regulations: Michelin replaces Bridgestone as the official tire supplier (for more background on that, see the interview we did at Brno with Michelin boss Piero Taramasso), and everyone will be forced to switch to the spec electronics package, managed by Dorna and developed by Magneti Marelli.

Much confusion surrounds the introduction of spec electronics. Firstly, because there are so very few people who actually understand the role of electronics in motorcycle racing, it being a dark and mysterious art for fans, media, even riders.

Secondly, because the adoption of spec electronics has been a process of constant negotiation between manufacturers, Dorna and Magneti Marelli, as they try to reach a compromise which is acceptable to all parties.

That has resulted in the rules being changed a number of times, with such changes not always being communicated directly or clearly to outside parties.

So where do we stand now, and what is the process? I spoke to Corrado Cecchinelli, Dorna’s head of technology for MotoGP, on progress with the electronics, and especially the spec software package, ahead of the 2016 season.

The 2016 MotoGP Hardware Package

The first thing to clear up was which hardware would be allowed. The 2016 hardware package had undergone a number of changes in the past 18 months, but now, a final agreement has been reached.

The original proposal was to have a single, spec package, as is the case with the current Open class bikes this year and last. But the manufacturers raised objections after receiving feedback from the Open class teams of erratic behavior from the spec hardware sensors.

A source at one Open class team told me that, for example, the gyroscopes measuring lean angle had sometimes been wrong by several degrees. As a result, the hardware package has been revised.

The hardware for all MotoGP bikes will basically be the same as the current Factory Option bikes. That means that the spec ECU (the computer which receives inputs from sensors and controls outputs such as ignition and fueling) will be compulsory, but the rest of the hardware package will not be controlled.

All sensors must be submitted to Dorna for homologation, and can only be used once they have received approval from the Technical Director.

Cecchinelli explains: “[The manufacturers] will just have to submit the sensors to homologation. The dashboard, the switchboard and the inertial platform, which now are compulsory for the Open riders, they will not be compulsory next year in the unified software scenario.”

Sensor Quality Assurance

The reason for factories being allowed to use their own sensors was because they had built relationships with suppliers, and knew those sensors to be reliable. The data coming from the sensors was the same, but each manufacturer had more confidence in the quality of the data from their preferred sensor partners.

“Every manufacturer has their own preferences and traditions and parts that they approve and find reliable, good for their scope, and they are not the same for all. They are used to certain sensors, and they don’t want to change, because they feel they are reliable, for their purpose, and so on,” Cecchinelli said.

The data should be identical, but it was more a matter of quality assurance. “For the hardware which is different, it’s more a matter of reliability and quality process, proprietary quality process, so you get to the end of it by taking your decision on this, say, air temperature sensor, and you want to stick with that.”

Cecchinelli did not expect compatibility issues, as the Magneti Marelli ECU uses industry standard connectors, inputs and outputs, there was a process in place to allow non-compatible parts to be made compatible and then homologated.

There had been some minor controversy in the past over the use of inertial platforms, the sensor package which uses a system of gyroscopes and accelerometers to measure bike attitude and acceleration, or in other words, lean angle, whether the bike is pitching forward under braking or back under acceleration, and how rapidly lean angle and speed are changing.

There were question marks over who would be using which package. However, the 2016 regulations made this all a moot point.

All sensors, including the inertial platform, have to be homologated by Dorna, and they have to be made available to all teams who request them at the same price as the factory which homologated them.

What this also means is that sensors such as the torque sensor used by Honda on their output shaft must also be homologated for use, and must be made available to other teams for the same price as Honda pay. Honda would also have to submit ECU logic to manage the output from the torque sensor, allowing the other factories to use it if they wished.

In contrast to the sensor package, the output side of the ECU would remain unregulated. Modules, actuators and ignition would all be free, meaning that each manufacturer can choose whichever fuel injectors, ignition coils, fuel pumps, regulators etc they please.

As the unified software controls the outputs from the ECU, the action of devices such as injectors and ignition timing has less of an impact than the sensors.

MotoGP’s Spec ECU

Speaking to French website OffBikes, Magneti Marelli engineer Marco Venturi gave an idea of the capabilities of the spec Magneti Marelli ECU, the AGO 340 ECU.

The ECU has two central processors, a 264 MHz 32-bit PowerPC chip managing analog and digital inputs, and running the CAN bus, and an 800 MHz 32-bit dual core processor which actually runs the vehicle dynamics software, which controls the behavior of the bike, and runs the data logger.

The data logger can handle 1024 channels and log at rates of between 1Hz and 1KHz, up to a total of 8GB of data.

The basic sensor package used by most factories uses around 26 different sensor inputs, such as throttle position, suspension travel, pneumatic valve control, etc, as well as inputs from the ECU’s internal sensors (accelerometers, temperature and voltage), and the inputs from the inertial platform (which consists of 6 accelerometers and 6 gyroscopes).

Black Magic: The ECU Software

Of course, the real magic in motorcycle electronics is in the software used to control the behavior of the bike. Traction control, launch control, engine braking, power delivery, all of these are controlled by programs written by engineers and loaded onto the ECU.

Currently, each factory can write its own programs, giving them great control over the way the bike behaves.

The software engineers writing these programs are free to pick and choose which sensor inputs they believe are relevant, combine and manipulate those inputs in whatever way they see fit, and then decide how to control engine power and torque based on the results of that data manipulation.

This means that the software for each manufacturer can behave differently. One factory may use sensors on the front forks to measure fork extension, and use that to control wheelies.

Another factory may use data from the gyroscopes and accelerometers to detect the bike starting to shift its weight from the front wheel to the rear, and control wheelies when the rate at which that changes becomes too high.

Such differences appear in every area, the characteristics of each bike determined to an extent by software. How well a bike gets out of a corner, how easy they are to launch off the line, how well they are to handle braking for a corner are all determined to a greater or lesser extent by the software they use.

That software is what is to change for 2016. Every bike on the MotoGP grid will use the so-called unified software, the common software written by Magneti Marelli.

The unified software is based on the current version of the Open class software, with additional input from the three manufacturers who were in MotoGP when the move to spec software was agreed. Here, too there will be changes, though.

Corrado Cecchinelli explains again: “The agreement, which is ratified in an FIM document, is that the software will start as close replica of the current Open riders software,” Cecchinelli said.

“It will just be ported into full torque system, which means that all the strategies will have a torque reduction as an output, and not a throttle reduction, so you have to have a good model of your engine. But the software strategies will be the same as the current Open riders.”

“Only the platform will be pure torque, and of course it will be written so that it may work on the factory machines and all engines. So it has to address for instance more refined pneumatic timing systems, seamless gearboxes and so on. But this is nothing conceptual, it’s just sort of porting the strategies into a more universal platform.”

Torque vs. Alpha N

Porting to a torque-based system is a major improvement. At the moment, the current Open class software uses the so-called Alpha N system, which measures throttle opening and engine RPM. This provides very simplistic control of the engine, which tends to be slow to react.

Factors such as engine load are often overlooked, and the system uses reactive control, rather than active control. For example, the ECU closes the throttle butterflies to control wheelies, which the engine takes a few milliseconds to respond to.

A torque-based system is a far more powerful way of controlling a motorcycle. The ECU has a theoretic model of the engine in its memory and knows how much torque (or acceleration/deceleration power, if you will) the engine can provide under any specific set of conditions.

When the rider opens the throttle at a specific amount, the ECU uses that to calculate how much torque it thinks the rider is requesting. That will be different riding up a steep hill rather than coming over a crest, for example, and will be different in a lower gear at full lean than at the end of the straight at Qatar.

The aim of a torque-based system is to provide consistent response to the throttle for a rider, rather than forcing them to figure out how the throttle will respond under changing conditions. It is safe to assume that all of the factories in MotoGP are currently using a torque-based approach in their ECU software.

Who Writes The Software?

The switch to a torque-based model was the most important request from the manufacturers, but Ducati, Honda and Yamaha are also able to provide input into improving the unified software.

Here, too, there has been some confusion over who is doing what and how, but Cecchinelli explained that there was a very clear division of responsibilities. All code would be written and implemented by the Magneti Marelli engineers, with the factories providing suggestions for functionality.

“When the factories agree on something, they will submit as improvement proposals,” Cecchinelli said. Which form they submit them in was completely up to them, but the preferred method was via Simulink models, which are a form of software modeling which can be imported directly into Matlab, the language used to write the unified software.

“Factories can submit proposals in whatever form they want, but basically it will be like logic flow charts of the strategies they want to be implemented,” Cecchinelli said. “They can submit Simulink models. This is the best way. The worst way being just a Word document, in between there is a way, but they will submit agreed ideas and concepts, they will not write the software.”

The aim was to make a single set of software, capable of handling multiple engine layouts and configurations, Cecchinelli told me. “We will not have different versions or flags, we will stick to one single software for all, and at the moment we don’t have any negative feedback on the engine not working on a specific engine layout.”

Software development was progressing apace, with a meeting held last week in Bologna to discuss a list of software bugs found and submitted by the factories.

Though Cecchinelli denied any knowledge of how far factory testing had progressed, it is clear that bug reports cannot be submitted if the engines are not already running using the software. At this stage, they will only be running on the dyno, with circuit testing not due to start until later in the year.

Cecchinelli said he hoped testing on track would start before the Valencia test, allowing the MotoGP riders to get their first taste of the new software at the test after the final race of the year.

“A good goal for me would be to put the factories in the condition to test on track before Valencia,” he said. “My idea is to do that with test riders so that maybe in the Valencia after-race test they can be tested with the championship riders. This is my goal. Which doesn’t mean that if we reach that goal, they will actually do this. But I would put them in the position to do that if they want.”

Keeping Complexity With The Factories

The one complaint which the current Open class teams have is that the software takes a lot of time and effort to optimize, and this required resources which the private teams simply did not have.

Cecchinelli admitted that the 2016 software would be even more complex, but he believed that despite this, the job of the private teams would be easier.

As the manufacturers will be more closely involved with the private teams, part of the package they will be supplying is a bike with software which already has a very good base setting. The bike will be much closer to being race ready than the current generation of Open class machines, Cecchinelli believes.

Asked about the complexity, Cecchinelli responded, “I think that what you call complexity goes with the power, the ability of the software. By power I mean calculation power and software ability. So I expect from that perspective, things will only get worse. We will have better software, which means more difficult to tune, but this is in line with a scenario where the pure garage manufacturers will disappear in favor of buying the factory machines from the year before.”

“There will be more involvement from the companies, so I think that it is true that the software will be in theory more difficult to tune for a small independent team, but the manufacturers’ involvement will be so high that in the end, small teams will benefit from the development done by the big R&D departments of the companies.”

“In theory it will be more difficult for them, but actually they will have to do much less job, because it will be 99% tuned by the company. It means that for instance it requires a very good engine model, so you have to make a very good engine picture on the dyno.”

“This is out of the reach of a small team, but it’s 90% of the job, once it’s done by someone else and you get the results, everything works better with less effort, actually. Even if more effort is actually involved, it is not you as a small team to put the effort in. ”

The burden of providing a working base setup has been shifted, from the private teams to the manufacturers. But of course the difference between the factories and the private teams will remain.

The factories will have the resources to get the very best out of the unified software. They will no longer be able to control which sensor inputs are used to control wheelies and traction, for example, but they will be able to go through and find the right balance between all of the data available and match power output to the conditions on the track.

Just as a professional photographer can get more out of Photoshop than an amateur can, so the factories will still be able to tweak the unified software more precisely than the private teams.

The private teams and factory teams will probably start the 2016 close together, but the factory teams will always be the ones who can squeeze the final few percent out of the spec software.

“That’s for sure. And that will not change,” Cecchinelli admitted, but the gap between the factories and the satellite and independent teams should not be as big as it has been historically.

“The big part of the calibration will be done by professional and big structures instead of small teams. Then the small teams just can make the customization for rider-specific needs for that corner or whatever. The small things that you do because your rider is different to another rider, has a different taste, has a different gearbox, things like this.”

“But for instance, all of the engine delivery, which is 90% of the result, is taken care at home by the company. So yes, in theory, it is more complicated, but actually the big complication is taken care by someone else.”

Will this mean that riders for independent teams will be able to win again? It has been nearly ten years since Toni Elias won at Estoril, which was the last time that happened.

Victory is likely to remain as remote a prospect as every for the independent teams, especially as to actually win a race, they have to beat Marc Márquez, Valentino Rossi, Dani Pedrosa and Jorge Lorenzo, let alone Andrea Dovizioso and Andrea Iannone, and Maverick Viñales and Aleix Espargaro.

But the battle behind the leaders should at least be closer, factories no longer having a major advantage in the software they use. They will continue to have the resources to run countless simulations optimizing the software for each race track, and each rider, but the advantage they will gain from that will be cut to a couple of tenths, rather than the best part of a second or more.

Will the unified software make that much of a difference? From the perspective of September 2015, there is reason to be optimistic. But the proof of the pudding is in the eating, and we will only know for sure once the 2016 season gets underway.

Photo: © 2015 Tony Goldsmith / www.tonygoldsmith.net – All Rights Reserved

This article was originally published on MotoMatters, and is republished here on Asphalt & Rubber with permission by the author.

David Emmett

One of MotoGP's most respected journalists, David Emmett is the proprietor of the esteemed MotoMatters. We are very grateful to republish David's work here on A&R...though dread the day we ever again get in a car with him.

Comments