In 2011, Mark Andreessen famously said that software was eating the world. Time has proven him correct. Humans interact with software nearly continuously thanks to smartphones and wearables and companies rely on software to execute services and operations.
For automakers, software is taking ever bigger bites out of cars. It accounts for up to 50% of a car’s cost today.
Software presents particularly thorny challenges in automotive because of complex integrations with hardware. In a Tesla or Rivian, software controls everything from the infotainment to the hood latch. These days, every automaker’s vehicle performance and safety features are controlled by software. Consider Toyota Guardian, which can stop a car automatically if it detects an object or person in front of it; or lane-keep-assist and adaptive cruise control, which can steer, accelerate, and slow down a vehicle without a driver’s intervention.
Moreover, capabilities like over-the-air updates have made cars ever more connected. And this connectedness will only grow because it is a prerequisite for autonomous driving.
The digital evolution has presented a slew of new challenges to vehicle development. In this article, I’ll focus on two:
- Enabling successful integration between software and hardware
- Ensuring quality and timely delivery of software.
The Toyota Production System (TPS), or lean, offers ways to address these challenges. While “production” suggests the principles apply to manufacturing only, they are universally effective across any human organization. For example, the TPS house’s just-in-time pillar can be applied to the synchronization – or cross-department flow – between hardware and software development teams, as well as delivery of software just as customers need it. Similarly, the jidoka pillar supports rapid bug detection, resolution, and prevention via methods such as pokayoke, andon, and jikotei kanketsu (built-in quality with ownership).
Integrating hardware and software
When I was chief information officer of Toyota Motor Europe, I coordinated the connected cars activities across departments in the region from their inception in 2009 until the creation of Toyota Connected Europe in 2018. I then became advisor to Toyota Connected Europe before moving to Japan in 2020 to serve as advisor to the president of Toyota Systems Corporation. In the initial years, we were developing 11 Multimedia (11 means the year 2011), a segment-first infotainment system with connected features for the Toyota Yaris.
Naturally, many challenges arose. For example, I soon discovered that hardware and software development teams did not share a common language. For instance, when IT faced coordination issues in integrating hardware and software, engineering teams would ask “What is your part number?” That was the only key engineers could use to report a problem. But our software had many versions and no part number at all.
It was only later, when I worked at Toyota in Japan, that a system was developed to manage software versions in the cars to address this challenge structurally. Teams developed versioning software that continuously tracked updates to the vehicle’s software. Hardware and software teams could then easily see which version we were using in development and which versions customers had to support service following delivery. Consequently, this made problem-solving at integration points and customer service simpler and more collaborative.
The application of TPS here was going to the gemba (the place of work) of the R&D and quality engineers to observe and understand the way they work. By comparing it with the way IT worked, we found common ground and methods to find and address issues as a team.
Ensuring quality and timely delivery
Toyota is renowned, rightfully, for its quality. Design, engineering, and production teams methodically work to build quality into a vehicle’s design and target defect-free production through careful process design. Once launched, production teams continuously improve operations to further eliminate problems.
However, it was frustrating to see the quality assurance of a factory in Japan block cars from leaving the factory due to a few remaining bugs in the infotainment software, while knowing the cars would be on a six-week journey on a ship to Europe before reaching any customers. The cars could have been updated upon landing with much better software six weeks later. But the existing quality procedures did not yet consider the possibility of updating software at a different location, as they were designed at a time when there was no such software in the cars.
The learning here is that jidoka is as important as ever. But in the context of software, it can be applied beyond the factory. The cars could still have been stopped at the port of entry in Europe. This approach also visualizes the problem at the point where it should be solved. Had six weeks been insufficient to correct the bugs, and the cars would not have been released for sale.
Software’s influence on the vehicle lies on a spectrum. Of course, any bugs impacting safety must be addressed immediately and the cars should not be allowed to reach customers. But minor software bugs that occur in very specific cases could potentially be addressed later. Putting the customer first, what would they prefer: receiving the infotainment system immediately, even with a few minor bugs, or receiving it six months later with those bugs corrected, but potentially with undiscovered ones? So long as safety is not at stake, a customer will probably prefer the former.
When an operator pulls the andon cord on an assembly line, the line does not stop immediately. The team leader, who runs to the call for help, has time to solve the problem before the line stops. When software bugs appear, software engineers must solve them. Connectivity affords them a longer period to address them before we must stop the line. Companies should take advantage of this to achieve both quality and fast delivery.
While there are many other challenging problems with software, these two are particularly important. Critically, the way we addressed them relied heavily on people. Working across departments to define and align on a common language was fundamental to bridging gaps between hardware and software engineers. And considerate discussion with quality groups to redefine acceptable quality criteria and timelines to address bugs led to breakthrough collaboration that, ultimately, benefited the customer. Software will continue to transform the world in ways we cannot imagine yet. But the TPS principles that can enable effective development are timeless.
Designing the Future Using Lean Product and Process Development
Learn how to reduce time to market, improve quality, and drive innovation in a hands-on, coach-led experience that applies Lean Product and Process Development across your value stream.