Authored by: Jean-François Campeau, Vice President and Head of Arene, Woven by Toyota


When people ask what I do for a living, I still think of my mom.

For years she has asked, “Jean-François, what do you actually do for work?” She does not work with technology. Computers and software are mysterious to her. For a long time, I struggled to give her an answer that was both honest and simple. Recently, I found one that feels right:

“I try to make sure your vehicle still works the way you expect after a software update.”

That sounds simple. But as customer expectations rise and software in vehicles is growing more complex, with multiple interconnected layers that define how systems behave, it is simply not so.

Beyond the technical challenge, this shift brings a new responsibility for automakers. They must have a direct, ongoing relationship with customers to deliver updates across the vehicle that actually resonate with their experience of driving, and do so in a way that not only continues to earn, but deepens, trust.

What is a trustworthy software-defined vehicle (SDV)?

I grew up in a middle-class family in Canada where everyone drove Japanese vehicles for their reliability — my mom, my kids, my wife, and my in-laws. When you live in a place where winter can be dangerous, a vehicle is not a toy. It is a lifeline. On a snowy night, you want confidence that your vehicle will safely take you from A to B and back again.

When I think about an SDV, I picture a vehicle that does exactly this and also grows with its driver. It is a vehicle that helps them feel at ease and happy behind the wheel, and, most importantly, keeps them safe on the road. At the heart of it all is trust.

Trust that changes will make a vehicle better rather than unfamiliar. Trust that improvements are guided by care, rather than novelty. Trust that nothing important is lost along the way.

To move in this direction, two important changes are needed in how we approach vehicle development:

• Software needs are defined much earlier, together across teams and at the vehicle level, to keep the vehicle’s behavior predictable and enjoyable for customers, even as software evolves.

• New value is constantly delivered with software through over-the-air (“OTA”) updates that do not regress the customer experience.
  
  

Why is it so difficult for OEMs to deliver on this change?

From the outside, SDVs might look like a simple software problem: update some code, deliver a new version, repeat. In reality, this is a major change in how automakers design, validate, and organize their operations. For companies that have spent decades succeeding with a hardware-first mindset, this is difficult because legacy operating models were not built for software that continues to change after the vehicle leaves the factory floor. More specifically:

Modularization is built for hardware but strained by software

Traditional automotive manufacturing is built on modularization. We split a vehicle into modules or domains, give them to different teams and suppliers, and then assemble everything. For hardware, this works very well.

For software, it worked when each module could be developed largely on its own and treated as a “black box.” As soon as modules start to depend on each other, driven by cross-domain functions, issues become harder to detect and can affect how the vehicle behaves. That can delay features, cause unexpected behavior after an update and make integration and validation more difficult, because changing one domain can affect others, even if we don’t touch them.

Growing complexity and cross-domain behavior

As vehicles gained more computing power and networking capability, cross-domain functions increased in number and complexity. As a result, integrating software from multiple teams became more difficult. Interfaces such as network signals, ECUs, and APIs could change without a clear view of the impact, and information about the vehicle ended up fragmented.

Engineers end up spending more time tracing issues through layers of software and interfaces instead of improving the product. It also increases the risk that a single software change affects multiple functions in ways they did not expect.

A young software engineering practice

Compared to civil or mechanical engineering, software engineering is still young. There is no universal handbook that says, “If your requirements are like this, connect your systems like that, and you will be safe.” Good practices and tools exist, but they are still evolving, especially when trying to scale complex software across millions of vehicles and variants.

The immaturity shows up in practice because only a few people have the expertise that leads to sound intuition. When non-experts are assigned to highly specialized positions, the risk of blind spots increases and it becomes harder to guarantee every update will match or exceed the experience customers are expecting from their vehicle.

Why can’t we just approach software updates in a vehicle like in a phone?

I think about this often when I hear an SDV described as “a phone on wheels.” More than once, my mom has called and said, “They broke my phone.” After an update, the behavior changed just enough that she no longer felt confident using it. Technically, the phone was fine. Emotionally, for her, it was broken.

Now imagine that feeling while driving.

Being in a vehicle is a multi-sensory experience. Your eyes, ears, hands, and feet are engaged. Your brain constantly compares what is happening to what it expects. When those match, you feel safe. When they do not, your survival instinct wakes up.

When a software update changes how a vehicle behaves, even slightly, and no longer matches what the driver expects, it can affect enjoyment at best and safety at worst. They do not experience it as a software issue. They feel that the vehicle or even the brand has disappointed them, therefore, we cannot treat updates to a vehicle in the same casual way we treat updates to mobile apps, and this requires a change in how we work, not just what we deliver.

Rethinking how we work

From my experience, a few changes are essential if we want to deliver a truly trustworthy SDV.

Turn black boxes into white boxes

We cannot manage what we do not understand, and for SDVs that means treating software as a core vehicle system that shapes the user experience, not a collection of black boxes. OEMs need to take direct responsibility for how software behaves end to end. While partners are essential and their IP must be respected, black boxes create risk. OEMs are accountable for the complete vehicle and need partners to share details about key behaviors, architectures, and interfaces. Transparency in those areas enables OEMs to understand and govern the integrated system, keep the user experience consistent as software evolves, and lower the risk of something customers rely on being altered.

Manage system architecture and interfaces at the vehicle level

No one buys a domain. We buy a vehicle, so system architecture — especially control loops for driver interaction — must be defined and governed at the vehicle level. Interfaces should be standardized, and the OEM as integrator is responsible for carefully controlling changes, because each update can ripple across domains. These choices help keep the vehicle feeling consistent across model variants and over time.

Make system behavior visible to everyone contributing to it

The ability to keep your balance when something unexpected is thrown at you is what agility represents for me. In SDV development, this means giving engineers visibility into how their work affects the vehicle’s behavior, not just their component, so issues are found and fixed earlier. It supports faster, safer improvements instead of disruptive fixes.

Use virtualization and invest in tools as long-term assets

“It worked at my desk” is not enough. We need environments that accurately reflect the actual vehicle. Virtualization brings the vehicle closer to the developer’s desk, so engineers can test how software behaves long before hardware exists. When companies treat these environments and tools as long‑term assets and keep improving them, customers see updates that work as intended the first time, across a wide range of use cases and model variants.

Ultimately, it is about transparency and collaboration, and how we scale both. Arene is my team’s response to that challenge.

How does Arene enable trust in the SDV era?

With Arene, we are unifying how software is developed based on the vehicle’s requirements, tested and integrated across the vehicle as a whole. It is a software platform for people. Developers, operators, and decision-makers across the automotive ecosystem who are all contributing to delivering “ever-better vehicles” for customers.

Arene brings together the SDK, tools, and data needed to understand and build vehicle software as a complete system. The Arene SDK provides shared frameworks and standardized interfaces that make system behavior visible across teams, while Arene Tools support designing, testing, and validating changes through virtualized environments that surface issues earlier. Arene Data maintains a vehicle-level view of expected behavior and conditions, informed by customer needs, so updates reflect what people actually value.

At Woven by Toyota, we also have the unique privilege of learning first-hand from Toyota and its group companies’ long history of building reliable vehicles at a global scale. By working together, side by side, Arene is being built in a way that will allow it to keep improving the driving experience with those key tenets of safety, quality, and trust front of mind.

Living, ever-better driving experiences over time

When I think about why software-defined vehicles and Arene matter, I do not picture architectures or databases. I picture my family. They are driving on a winter night in Canada, comfortable and enjoying the ride, but confident they will get where they need to go — with peace of mind, even if a complex software update was made just before their ride.

And over time, as my children have families of their own and their needs change, that same confidence will stay in place. Confidence that their vehicle will continue to meet their needs, grow with them, and do so without ever breaking that fundamental feeling of ease. For me, that simple expectation is what a trustworthy SDV must

protect. To achieve this, it will depend on an industry willing to work in the open, share understanding across boundaries, and build software-driven experiences with trust at the center.

Jean-François Campeau expanding on this content at KAKEZAN 2026, Woven by Toyota’s flagship technology showcase and gathering.