Why is software just as important as an engine for a modern vehicle? How can a startup struggle against huge corporations? How to deal with team chaos? And, most interestingly, why and how should the manufacturers change their core approach to vehicle design? Anton Rysin, former Vice President at Arrival Technology shares his views about groundbreaking innovations that are reshaping the entire industry right now.
Anton, what was your main area of expertise at Arrival?
Arrival is an absolutely wonderful company offering a unique product. We were developing state-of-the-art electric-powered commercial vehicles, a van and a bus, competing for orders with some of the world’s largest automobile manufacturers. Unlike big companies with developed production facilities and tens of thousands of employees, we had nothing at the start, just the ideas. To stay ahead of our peers, we followed advanced working methodologies. For instance, instead of conventional conveyor assembly housed in a monstrous building, we used a network of micro-factories. But it was not just the assembly procedures that made our approach unique. Also, all Arrival vehicles worked on a single code base.
Why does single code base matter?
This was the key to developing our software quicker. To begin with, software in a modern electric car is not just a nice addition to the electric motors, batteries, interior control panels and so on. I think the attitude towards onboard computers and software as just “extras” is a relic of the petrolhead era of our fathers. For an electric car, the software is the real backbone. Without it, such a car is just a pile of metal. By constantly improving the car’s software, you can make it increasingly faster and more efficient. And this is, of course, a strong competitive advantage.
In other words, we couldn’t afford spending several years to create dedicated software for a bus, and then another several years to create some different software for a van (and there were six more products expected in the lineup). In addition, both the van and the bus were constantly undergoing changes and improvements: existing modules were replaced, new ones were added. And just from the start, we had to figure out how to interconnect dozens of these devices inside the vehicle, so that the Arrival van or bus would be more profitable than the usual diesel vehicles.
So Arrival has a common “operating system” and kind of separate program modules for different systems?
Roughly speaking, we created vehicle software that was not strictly bound to a specific hardware platform. In my role as Vice President of Program Management, I created a unique framework capable of building machines like LEGO kits. But to do this, I had to change my entire approach to handling both software and hardware components.
When I joined the company, I faced quite a few challenges. The team had a lot of talented engineers fully committed to their own narrow tasks: one was developing the battery charging system, another was working on the connectivity module. We decided to shuffle the deck and focus on functions instead of separate modules. For example, there is a charging function that combines several controllers. The door opening function, the navigation function — just a few dozen functions that sum up into a car.
You mean an entire car can be created out of such functions?
It can be done and it should be done. Moreover, it is possible to perform this process in a nearly semi-automatic mode. The framework we developed enabled us to design the necessary functions, while the system completed the connections and interactions between them, ensuring the machine’s overall operability.
The idea sounds quite simple, but in fact it had tons of work and some very innovative approaches under the hood. For example, we learned how to add new or replacement modules in a Plug-and-Play fashion: you can use the same code for the vehicles with, say, different headlights (or motor!), adapt the drivers a bit, but in the end we didn’t have to alter the core code for the entire van or bus. Also, we learned how to describe the module characteristics that are yet unknown to us, so that we could quickly incorporate them into our functions later.
But all of this software still needs to be updated…
Yes, just like any software. From this point of view, an electric van is no different from a smartphone in our pocket. And just like with a smartphone, we can deliver updates over the air, without having to take a vehicle to a service center. Moreover, since we treat the vehicle as a set of functions supported by specific hardware and software, we can roll out some new features without even changing the physical components. For instance, by simply updating the software, we expanded the ADAS functionality, a driver assistance system, to our vehicles. Just imagine, an employee comes in the morning, gets into their van, and discovers that the software has been updated: the vehicle has new multimedia features or significantly improved energy efficiency. With Arrival vehicles, this was not a fantasy, but a reality.
So you created a commercial vehicle similar to Tesla?
Arrival and Tesla are different companies with different products, but we had something in common indeed. Our vehicles were the only fifth generation electric-powered solutions on the market: they run on software that links different modules together and makes it easy to add new ones as needed. Typical fifth generation cars are cheaper and they even have fewer chips in them (according to a study by McKinsey). They are also more reliable because a failure of a single module or its software usually does not freeze the entire vehicle. Also, they can be updated over the air and can be added with new bells and whistles (including features and services available by subscription) without changing the hardware. So far there are no other similar solutions on the market, competitors are just approaching the fifth generation.
How difficult is it to work on such innovative products?
It is definitely not an easy job. I had to be engaged with everything: creating applications architecture, diving into the module selection nuances, choosing frameworks and code bases, calibrating cameras, certifying the vehicles together with the teams. And mind that just getting it done was not enough: everything had to be done twice as fast compared to peers and at just a third of their costs. Jumping over your head every day is difficult, but it is the only way to find solutions that move forward not just your company, but the industry as a whole.
My time at Arrival is over, but I am pleased to think that the solutions I came up with yesterday are being worked on by competitors trying to adapt them for their products of tomorrow.
