Interview with Glen De Vos: Container Technology Energizes the Transition to Software-Defined Autos
Bringing flexibility, manageability, and new opportunities to embedded software deployment
Enable a Software-Defined Architecture from the Start
OEMs need software-first thinking. When they think about any feature of the vehicle, they should be thinking of it in terms of the software architecture first, and what it will take to control that windshield wiper, lift gate, or propulsion system — whatever the function of that feature is. In other words, what do I need from a software architecture standpoint to enable that feature to work properly and let that drive the hardware requirements? Also, they should have a project mindset: What does the customer need, and how do I meet their need for a specific vehicle and a specific application? How do I architect my software so that it can meet the needs of a broader market, so that I can reuse that code and run it on any underlying hardware through virtualization?
Container Technology Is Vital to the Future of Automobiles
Container technology is new. Automotive is one of the trailing verticals in terms of adopting modern software architectures, in which you’re virtualizing the compute, abstracting software from the underlying operating system, containerizing the applications. The hyperscalers, the cloud providers — other industries have already moved in this direction. The auto industry is still very much locked in the old-school, monolithic model. Today, you define the hardware. You optimize the software on the hardware. There’s lots of little individual boxes that talk together. But they don’t share really well. The physical architecture in the car hasn’t been ready to support a more modern software architecture. We just couldn’t do it. Well, that’s what’s changing. It’s a chance to restart with a clean sheet for improving the architecture at OEM central.
Automotive Demands More
When developing, deploying, and operating automotive software, you need to bring it all together to make sure it is compliant with some of the critical requirements for the industry, such as ISO 26262 for functional safety. We have to be compliant, in terms of the product as well as the DevOps environment, with the functional safety requirements and the General Data Protection Regulation (GDPR) data security requirements that are unique to automotive. Then there are the cybersecurity requirements for automotive. And, finally, there is measuring the quality of the software and focusing on traceability — tracing from requirements all the way through implementation verification.
Refinements Over Time Are a Bonus for the Software-Defined Vehicle
I can see containerizing something like a functional safety feature, like adaptive cruise control. It becomes a package that I can now sell to early customers. And because it is there, it’s proven. I won’t require the customer to pay me up front for engineering to develop it. It’s ready and good to go. That’s the first dimension. The other dimension is across time. For instance, ongoing refinements: As I implement machine learning on a radar, I can do much more with adaptive cruise control. Or, incorporating more advanced features, things that make the car feel more natural, such as cutting curves in an optimal way. I can introduce [this] and charge a one-time fee or a new licensing charge, or make it part of a subscription. I can provide a roadmap of updates. Containerization is important because it breaks the code into functional modules that you can manage.
Getting Past Go for This Foundational Shift
For a given customer, you might go through two or three proofs of concept for something of significant magnitude. Software architecture is sitting at the core of a vehicle, and if the architecture doesn’t work, the vehicle doesn’t work. It’s not like evaluating a new technology for lighting, or a new sensor — if that doesn’t work, I can back off and use what I had before. With a vehicle architecture–related shift, it needs a thorough vetting and proving process, because the worst thing for an OEM is to delay and miss a launch date. Typically, we’ll go through two or three of these types of proofs of concept to have the ability to demonstrate that it’s right. The next one becomes a lot easier because you can point to what you did, and over time the task becomes much more manageable.
The Elevator Pitch for Container Technology
Containers enable you to manage and control the software on your vehicles much more effectively. They make it manageable and more cost-effective, and they open up those new revenue models. That’s what containers bring. If you keep doing it the way you have been doing it, you, as the OEM, will never get to those software revenue streams that we have talked about. You will never get to the efficiency of software costs in vehicles, and you really won’t get to the software-defined vehicle at all.
ABOUT WIND RIVER
Wind River is a global leader in delivering software for the intelligent edge. The company’s technology has been powering the safest, most secure devices in the world since 1981 and is found in more than 2 billion products. Wind River offers a comprehensive portfolio supported by world-class global professional services and support and a broad partner ecosystem. Wind River software and expertise are accelerating digital transformation of critical infrastructure systems that demand the highest levels of safety, security, performance, and reliability. To learn more, visit Wind River at www.windriver.com.