Why Ford decided to merge its next-gen architecture into its current platform

by oqtey
Why Ford decided to merge its next-gen architecture into its current platform

When Ford poached Doug Field from Apple in 2021, the company had high hopes for the mild-mannered engineer. Field would lead the charge on developing “the next-gen Blue Oval Intelligence tech stack to deliver smart, connected vehicles, and services that improve over time through constant updates,” it said in the release.

Now, as Ford grapples with stagnant EV sales and project delays, Field is wrestling with the challenge of how to enact that bold vision of the future, given the harsh realities of the present.

At the time of his hire, the only car company with a snappy, seamless, and satisfying software experience was Tesla. Legacy automakers like Ford could only look on with envy as Elon Musk’s company pushed out monthly over-the-air updates that amazed and delighted his many customers.

Ford wanted that too, and so it hired Field to lead the effort. In addition to heading Apple’s secretive car project, Field also served as chief engineer at Tesla overseeing the Model 3’s design. Who better to turn this lumbering 121-year-old company into a cutting-edge software shop?

Who better to turn this lumbering 121-year-old company into a cutting-edge software shop?

Four years later, there have been some notable successes — and some equally notable setbacks. Ford has rolled out a number of new features, including its popular and highly rated BlueCruise hands-free driver assist system. The Ford Digital Experience is the new Android-powered infotainment system that enhances rather than blocks smartphone mirroring. And the automaker launched a Silicon Valley-based skunkworks project to design its next-gen EV.

But while its rivals roll out high-performing, affordable electric models, Ford’s sales have slowed significantly. The Mustang Mach-E and F-150 Lightning have seen year-over-year sales drops. And earlier this week, Reuters scooped that the automaker was scrapping its high-cost next-generation electrical architecture, also known as FNV4 (for fully networked vehicle). The platform was costly, contributing to a $5 billion loss on EVs and software in 2024, but also a key effort to update and improve Ford’s software experience, the publication said.

The decision didn’t come lightly, Field says in a rare interview. “Stopping any engineering project for a leader like me is always hard,” he says. “You put a lot of time and effort into these things. But the world in which we started this project is not the world we live in today.”

‘A more incremental approach’

The world that Ford lives in today is one where ICE and hybrid vehicles are selling at higher rates than the company’s electric options. It’s also one in which President Trump’s trade war is expected to jack up the costs for key automotive parts, including EV batteries. That leaves Field with the challenge of developing software not only for the company’s EVs, which are essentially rolling computers, but also its gas-guzzling, 12V-battery powered internal combustion engine (ICE) vehicles. Field says it was more cost-effective to adapt Ford’s third-generation architecture — FNV3, now rebranded as X.3 — to the full range of the lineup, rather than build a new platform with a more limited application.

“By taking a more incremental approach, we’ve vastly expanded the number of vehicles in our portfolio that are going to get the latest infotainment systems and BlueCruise,” Field says. “That wasn’t in the plan before with FNV4, because it really required a lot of change to a vehicle to incorporate it.”

Still, you can imagine why Ford was interested in pursuing the project to begin with. FNV4 was going to be the company’s first crack at a zonal architecture, the type of which has become increasingly popular among EV manufacturers. A zonal architecture means fewer electronic control units (ECUs), less wiring, and most importantly, less production cost. Tesla pioneered the use, and it has since been adapted by several EV-only shops, including Rivian and Scout.

“Stopping any engineering project for a leader like me is always hard.”

Instead, Ford will stick with a domain-based architecture, which Field admits is “not as elegant,” but allows his team to develop software for a broader range of vehicles. In a domain, or features-based architecture, a car may have dozens of ECUs to control everything from power windows to the HVAC system to the infotainment platform.

In Field’s thinking, a handful of primary ECUs embedded with the most important software code send out commands to the rest of the vehicle’s microprocessors. The software does the heavy lifting, making the exact number of control units open to interpretation. After all, microprocessors are relatively cheap. And that way the company’s engineers can design a system that’s compatible with EVs like the Mustang Mach-E, all the way up to more complex ICE vehicles, like an F-150 Super Duty with uplifter modules to raise and lower snow plows.

“I would care less about the number of microprocessors in my vehicle,” Field says. “If I have 50 of them and four really share in all of the major operations that we want to do for the customer, and a lot of the others have very little software and perform much more of a service function to those big ones, I’m kind of getting towards the whole point of the project.”

Field doesn’t have the luxury of developing software for a handful of cars that were built from the ground-up to be computers. He has to wrangle a vast, complex software network that integrates codes from a variety of suppliers that Ford has worked with for decades.

And in navigating those relationships, Field may have to step on a few toes, because “those companies do not want to become contract electronics manufacturers. They want to sell full systems.” He understands this concern, but his approach will necessitate centralizing and consolidating some of these modules under Ford’s control in order to ensure everything works harmoniously.

The key is the software, Field says. Get that centralized and under your control, and then simplify the interfaces. Figuring that out is more important than eliminating or replacing every microprocessor in the vehicle, sort of like how the brain sends out signals to the rest of the body.

“I would care less about the number of microprocessors in my vehicle.”

“When you’re drawing something on a piece of paper, there’s a very complicated loop between your brain and your hand. And it’s slow, but it’s very adept,” Field says. “If you touch your hand to a stove, it’s not doing a round trip through your brain. It’s going straight through the lizard brain and creating a reaction. There’s parts of the car that need to work that way.”

Field wants to replicate that instantaneous process for critical functions, like automatic emergency braking, traction control, or airbag deployment. Other functions, like pinch protection for windows, can be centralized into a module that Ford controls.

“We’ve already selected what parts of vehicle functionality that currently exist in modules we’d want to start bringing into central compute,” he added. “We’ve called it a super zonal, central compute with a super zonal. So, it’s like one zone.”

Ford’s hands-free BlueCruise system in a Mustang Mach-E.
Image: Ford

The idea of a “software-defined vehicle” has quickly become a buzzy way to describe the auto industry’s slow-motion shift to vehicles with cellular connections that can accept over-the-air (OTA) updates to introduce new features or fix bugs in the software. The idea makes sense when you’re talking about an EV, which is essentially an always-on computer with a huge battery that sits in your driveway and waits for the latest update. But as Ford’s EV sales slowed down, the company was forced to pivot to take into consideration its millions of ICE and hybrid vehicles too.

While the skunkworks team develops the next-generation vehicle that’s so crucial to Ford’s future, Field was left with the task of figuring out how to design a software delivery system for giant gas-powered trucks and commercial vans. “We can’t leave those products stranded from a digital and software perspective and just focus on EVs,” he says.

A lot of that work focuses on energy management. An EV with an 81kWh battery can passively receive a big software update without losing much energy. But that same update could drain the 12V battery in a gas-powered Ford Bronco without proper oversight.

“We have ways that we can do partial updates,” Field says. “We will do large scale downloads while the vehicle is in operation. We will monitor the battery and know when to start an OTA or when not to start an OTA.”

Being able to push software updates to tens of thousands of vehicles, regardless of powertrain, is ultimately why Ford decided to kill FNV4, which Field says was risky, but still the right move. The automaker’s sales team is happy, as are Ford’s integrated services team and its thousands of dealers. The road ahead will still be a hard one, with EV sales stalling out and a mercurial and EV-hostile administration in the White House — but Field thinks Ford can get there.

And after all, what difference does it make to the customer which type of architecture they get? “Zonal architecture is for engineers and industry analysts and other things,” he says. “It’s kind of irrelevant to the customer.”

What is relevant to the customer is an amazing software experience in a car they love, not necessarily the overall package in which it is delivered, he concludes.

“Software is supposed to be soft,” Field says, “and the industry has made it hard and made it match up to the physical boxes. So to me, like the biggest thing is, are you making your software soft, putting it where you need it to be, and not being at the whim of the legacy of where all the software sits?”

Related Posts

Leave a Comment