This article is part of the TechXchange: VMs, Unikernels, and Containers.
What you’ll learn:
- How containerization can be deployed in automotive in a manner that’s certified cyber-secure while retaining the latest levels of functional safety.
- How Arm’s SOAFEE initiative is bringing automotive functional safety and real-time requirements to the cloud.
- How NXP’s S32G3 family is building upon capabilities of previous generations of automotive compute silicon to tackle functional safety, high-speed networking, and security.
Traditionally, vehicle original equipment manufacturers (OEMs) have sourced the needed boxes from their best suppliers, plugged them together, and—voilà—they produced a vehicle packed with technology that was popular with consumers from five years earlier.
There was never an option to upgrade any hardware, even though it was available on other vehicles from the same platform. This is due to the complexity of today’s automotive supply chain, coupled with the cost and effort of integration, validation, and regulatory certification.
Nor could you update the software to take advantage of a new capability. In a best-case scenario, a software update would reluctantly be offered to resolve a minor issue. But things are changing with the advent of the software-defined vehicle (SDV).
The dream is to offer additional features to vehicles after they roll out to the driver on the road, enabling them to customize their cars, almost like they update their smartphones. And the driver may not even be the owner. Instead, following the trend of shared mobility, features and capabilities will follow the driver to the vehicle they use.
Vehicle electrical/electronic (E/E) architectures are changing dramatically to achieve this flexibility. Domain and zonal architectures (Fig. 1) mean that each hardware box integrated into the platform will be networked. This allows for data exchange across high-speed, time-sensitive Ethernet networks and collaboration between processors over PCIe.
At the core of this new architecture is a vehicle computer coordinating functionality within the vehicle and interfacing with cloud services. Furthermore, functions may even be split across electronic control units (ECUs) so that, when manufactured, the hardware may not be programmed to execute a specific function. Instead, that decision will be made when the software is installed during vehicle manufacture, spreading it across the most appropriate resources.
Learning from the Cloud
The automotive industry is looking to the cloud for inspiration in making this happen inside the vehicle. There, virtualization and containerization have made software-as-a-service (SaaS) robust under extreme loading, cyberattacks, and during software updates. Virtualization uses a hypervisor to enable several operating systems (OSs) to run on a single server. Memory, storage, and networking are then shared across the OSs. However, virtualized OSs are slow to start when more resources are needed.
Containerization uses a single OS that provides separate user spaces (containers) for the applications it executes. Should one app go wrong or need updating, the others continue, unaffected by what’s happening elsewhere.
In addition, if a container is operating at its limit, a replica can be quickly started to share the load, allowing for dynamic or “elastic” orchestration. Key technologies in this space are Kubernetes for operating containerized applications (Fig. 2) and Docker for creating containerized applications. But other, lighter-weight solutions are emerging that fit the needs of automotive systems more appropriately.
For automotive, K3s1 is a highly available version of Kubernetes for resource-constrained hardware that supports Arm processors. Coupled with today’s continuous integration/continuous deployment (CI/CD) software development processes and over-the-air (OTA) updates, the puzzle pieces are in place to support the SDV vision.
Automotive Industry is Changing
Recognizing that implementing such change is a task for a community, not just individuals, representatives from the semiconductor industry, cloud computing, automakers, and other suppliers have formed the Scalable Open Architecture for Embedded Edge (SOAFEE) project.2 This industry-led collaboration includes companies such as Arm, AWS, Bosch, CARIAD, Continental, Red Hat, SUSE, and Woven by Toyota (Fig. 3).
The initiative encompasses not only software for vehicle hardware but also for the cloud with a cloud-native software development approach. Cloud services are used to create a continuous integration/continuous deployment (CI/CD) pipeline for building, containerizing, validating, and deploying software that works both in the cloud and on embedded hardware.
Naturally, the project covers security, supports real-time needs, and provides support for functional safety through mixed-criticality awareness. Thus, comfort features can be deployed or updated without impacting services related to safety-critical capabilities.
If vehicle feature differentiation is to come through software, the higher-level application software is meant to define differentiation, not the lower-level software. There are other similar approaches.
One such approach is Vehicle OS from Vector. Its runtime environment is known as Base Layer, which can be adapted for microcontrollers, microprocessors, or a cloud-based backend. Delivering this environment is Software Factory, which automates the development workflow, integration of low-level software, middleware, and apps, with distribution to the vehicle or backend.
TTTech Auto also sees a future for an open standard Car.OS3, noting that most infotainment software is built on a common software stack. Such an approach also supports the “develop once, deploy many times” ethos already highlighted.
Hardware for the Software
While cloud applications can be very robust and reliable, this is achieved through brute-force computing power and massive, elastic redundancy on an x86 hardware platform that’s common across the industry.
To replicate it in the vehicle, a new generation of processors is needed that fulfill these capabilities while also delivering high-speed networking, determinism, and functional safety. And, due to the increased attack surface resulting from these mobile networked devices, a carefully constructed approach to cybersecurity in both software and hardware is needed.
A new generation of vehicle network processors is at the forefront of enabling the SDV revolution. One example is the NXP S32G3 family, which builds on the capabilities of the previous generation of automotive compute silicon (Fig. 4). The design tackles the three main areas required at the core of the new E/E architecture.
The first is functionally safe processing, covered by up to four lockstep Arm Cortex-M7 microcontrollers and up to eight cluster lockstep Arm Cortex-A53 microprocessors. These provide configurable ASIL D lockstep clusters and two ASIL B independent clusters.
On startup, memory and logic built-in self-test (BIST) check for possible issues, while a fault collection and control unit (FCCU) monitors operation, placing the device in a safe state should a failure be detected. Peripherals can also be assigned to specific cores at boot, enabling virtualization and containerization that supports fast startup and follows strict orchestration rules. This ensures, in hardware, that resources can’t be impacted by code execution failures elsewhere on the device. Demonstration applications have already been created that use K3s for containerization.
High-speed communication is essential to SDVs, from daily operations to OTA updates. This brings us to the second core area: networking. However, the interrupts associated with CAN/CAN-FD, Ethernet, and others make determinism challenging.
To counteract this, the S32G3 offers a Low Latency Communication Engine (LLCE) complete with its own cores for handling legacy networks (CAN, FlexRay, LIN, and SPI). It includes offloading for AES encryption, time synchronization (IEEE 802.1AS), and flexible buffering. For Ethernet, up to three 2.5-Gb MACs are integrated into a separate Packet Forwarding Engine (PFE) supporting IEEE 1588v2 and AVB/TSN for deterministic communication. Further automotive interfaces and two PCI Express (PCIe) 3.0 interfaces (two lanes each) are available, too.
The third and final piece is security, starting with an advanced Hardware Security Engine (HSE). Integrating typical cryptographic functions (AES, SHA, ECC, RSA), it meets current security specifications such as E-safety Vehicle Intrusion Protected Application (EVITA).
By establishing a root-of-trust at boot time, the processor ensures all modern security mechanisms are available that limit attacks and make certain only certified software and updates can be deployed to the vehicle. Finally, hardware support for Intrusion Detection and Prevention Systems (IDPS) with communication packet filtering and inspection help detect cyberattacks that can circumvent authentication and encryption mechanisms.
Development is accelerated with a range of hardware platforms (RDB3, GoldBox 3), enablement software from NXP and its partners (Fig. 5), along with the Vehicle Integration Platform (GoldVIP) supporting rapid connected gateway development and proof-of-concept efforts.
Processors Ready for SDVs
SDVs make huge promises to the public, both to those who want to own and those who only want to use personal transport. It’s clear that the current approach of connecting 150 ECUs with different hardware and software from various suppliers can’t deliver this vision.
OEMs are taking over the software development for their vehicles, leveraging new E/E architectures that can support the CI/CD workflows needed for the continuous rollout of new features and updates. Much of this process can be copied from existing cloud software development processes.
However, they must also be tuned to the vehicle’s deterministic, functionally safe environment and the unique cybersecurity needs of automotive. New generations of ASIL D processors with hardware that simplifies virtualization and containerization, coupled with state-of-the-art security, are ready to take on this massive challenge.
Read more articles in the TechXchange: VMs, Unikernels, and Containers.
References
3. https://www.tttech-auto.com/knowledge-platform/open-caros-and-software-defined-vehicle