By Álvaro Eguinoa
If you’re an engineer and a Formula 1 fan, one of your biggest intellectual challenges in 2026 may well be the Honda phenomenon.
Honda is an example of investment, commitment and knowledge. Perhaps they got it wrong on the first attempt, but we won’t dwell on that. They have shown that they have more than enough capability to be among the best.
Now, after many other challenges have been overcome, what is making the headlines has to do with energy deployment, which is controlled by software.
I read that, in Singapore, they realised that turbo behaviour and energy deployment are affected by multiple factors. One of them is the varying grip of the track. The delay — which is variable — in turbo response is compensated for and combined with energy deployment, but engine behaviour cannot be predicted if grip itself is unpredictable.
This will be part of the explanation, and they don’t have to disclose any more details.
So, what’s going on?
Software is a major leap forward in electronics because it allows us to model reality, to the extent that we can describe it in technical terms. Engineers have been programming and testing software for a long time. My bet is that the software isn’t doing anything its creators don’t expect it to do. I think the problem lies elsewhere.
Software can do exactly what you ask it to do, and the system can still fail to work properly.
Perhaps the model of reality isn’t accurate enough because we’re missing parameters needed to understand it. If I were responsible for the money in this project, what I’d ask for is a really thorough definition of the system. Every part of it. And all its interactions and interfaces.
That would include, alongside temperature and humidity, the mechanical interaction with the track, battery charge levels outside the expected margins, an extra kilogram of weight, one point of aerodynamic load, one degree of wing angle, rain of grade X… whatever the local experts consider relevant.
And if we can understand these relationships, then describe them in requirements. And develop an exhaustive validation strategy that prevents unexpected effects from showing up at every race simply because we’ve moved outside nominal operating conditions and haven’t defined what the system should do in those circumstances.
The right approach to anything in this world — and certainly to a Formula 1 car — is systems engineering. And we’re talking about an enormous, complex model. Engineers need to anticipate and predict not only what happens when everything works as expected, but also what happens when individual parts fail, when common-cause failures occur, and when components degrade.
So, where are the requirements defining how the vehicle as a whole should behave? Where are the interfaces defined? How have interactions between components and the environment been mapped to ensure that they work together as intended?
And, more importantly, how is it possible that, in an environment where physical testing has been reduced, sufficiently accurate testing tools haven’t been developed?
Looking at the engineering tools available, I think there may be a gap when it comes to integration. Power has been measured on a test bench for a long time. Mechanical and environmental testing is well established. A circuit simulator can be excellent for aerodynamics, provided there is good correlation with reality.
But the main tool for validating the system is understanding the interfaces and the operating models. The whole system.
If there’s one thing I appreciate about this era of Formula 1, it’s that it’s showing us how you can be the best at what you do and still fail to integrate your work with everyone else’s.
All I have left to say is that SafeSuite allows you to model electromechanical systems of any complexity, work as a team with continuous synchronisation, and define interface models and tests.
Orihara-san, please check your free trial at cynoss.net/pricing.
2027 is waiting for us.