Benefits of Software Containers in Safety-Critical Environments
The transition from hardware-defined to software-defined vehicles is changing everything about the auto industry and beyond. It opens up a world of possibilities for connected, autonomous and electric vehicles, with more innovation than ever before. It also lets OEMs introduce new features quickly, both before and after sale, to meet evolving consumer tastes and needs.
To fulfill its promise, however, the software-defined vehicle requires a hardware architecture that is more optimized and designed for evolution, and a software architecture that is more open and enables a new approach to software development and management. OEMs need the flexibility to modify individual functions rather than issue updates to entire monolithic code bases, and they need a technology that ensures that any changes will not negatively affect adjacent safety-critical software in the vehicle.
Software containerization provides that flexibility. Making containers a reality in the safety-critical automotive environment will require shifts in automotive software architecture, as well as standardization across the industry.
New architectures
As software-driven functionality has increased in the automotive world, the compute hardware has evolved. Instead of electronic control units (ECUs) with dedicated hardware and software performing specific functions, high-performance compute platforms have emerged, such as central vehicle controllers (CVCs) and open server platforms (OSPs). CVCs up-integrate body control functions and networking, while OSPs consolidate functions around the specific domains of advanced driver-assistance systems (ADAS) and user experience.
The new approach to hardware saves space and cost, but it also demands a new approach to software. If software is monolithic — as it has been with ECUs — improvements will require full retesting and validation of the entire device it runs in, and any over-the-air (OTA) updates will be much larger than necessary, requiring bandwidth and time.
Key to moving away from the monolithic approach is modularization and abstraction of functions into manageable software blocks, a practice common in the IT world. Controlling a device within the vehicle, for example, is performed by specialized software that handles all signaling to and from the device while presenting a standard, simplified service interface to higher levels of software. This way, the higher-level software does not have to be concerned with the details of how the device is managed, and developers – who are sometimes far removed from the specifics of a vehicle – can focus on just the higher-level logic.
In fact, all vehicle functions can be abstracted and presented as services to other software, creating what is known as a service-based architecture. Software containers fit neatly into this approach.
Containerization, developed for use in cloud computing, places applications in standard structures that ensure that the dependencies — in the form of service interfaces — among applications are known and controlled. This helps drive stability and consistency in the code base, simplifying isolation of services, and effectively reducing the chances of interfering with other software. It also improves security by keeping attacks that target one application from spreading to others.
By using containers, OEMs and suppliers can adopt modern, agile software methodologies: small teams continually improving individual functions throughout the life of a vehicle with OTA updates, with such changes integrated quickly and automatically. By aligning with open specifications such as that of the Cloud Native Computing Foundation, an OEM and its suppliers can easily update vehicle platforms and even port functions from one platform to another, saving time and money while reducing the risk of errors and systemwide failures.
To learn more, read our white paper.
