The SDV is designed to be enhanced over its lifetime through over-the-air updates. New cloud-based virtualization allows for development to take place before silicon is available and after the car is on the road.
Software and hardware for embedded systems are often intricately connected. Developers are constrained by limited resources and tight deadlines and there’s a requirement to ensure flawless integration. This leads to multiple rounds of on-device testing.
Such an approach is not effective for rapid product development lifecycles, and it’s also at odds with the demands of service-led business models. Automotive OEMs are embracing the concept of the software-defined vehicle (SDV) and instead of critical or limited firmware updates, which are often only applied during servicing, the SDV is designed to be developed and enhanced over its entire lifetime.
A platform approach is necessary to make the SDV a reality. By decoupling hardware and software, application and architecture design can be more flexible, and additional functionality can be implemented over time. Decoupling encourages greater software reuse across different vehicles with minimal adaptation between platforms. Vehicle owners also benefit from improved safety and vehicle reliability, along with a reduction in energy consumption.
Such an approach will fundamentally change vehicle software development. We’ll start to see the industry “shift left”, with software completed earlier in the product development lifecycle, even when prototype hardware is not available. The industry can also “stretch right”, with the ability to update vehicles after they’ve been sold. This offers potential for OEMs to create new revenue streams from cloud-based services, supporting vehicles through multiple owners, using over-the-air (OTA) updates to add functionality throughout the lifetime of a vehicle.
Shift left, stretch right diagram
Building on Continuous Integration and Deployment
The concept of continuous integration and continuous, or near-continuous, deployment, has been used successfully in the enterprise space for years. “Shifting left” and “stretching right” is the next logical step and the requirements for both largely coincide if development teams choose the correct software development methodology.
SDVs are no different to other embedded systems and supporting technologies, such as virtualization and the use of software containers, which can be used to isolate software modules and abstract them from underlying hardware. Benefits to this approach include easier integration with the cloud-based processes for many value-added services. These services will often fuse the core car capabilities with artificial intelligence (AI) and cloud-based analytics.
The core change for embedded systems is to remove the need for prototyping on physical hardware, or at least reduce it to the bare minimum to ensure assumptions about timing and hardware behavior are realistic. However, the embedded space does call for an additional component.
How Virtualization and Simulations Are Driving Development
Containerization is an important element in the adoption of continuous integration and deployment methodologies in the cloud environment, reducing application hardware dependencies. Applications can be packaged alongside the support libraries and device drivers with which they were tested, isolating them from the underlying operating system. An additional layer of isolation and protection is required in the embedded environment, and this is provided by virtualization. Under virtualization, a hypervisor maps the I/O messages to the underlying hardware. The hypervisor’s management of the virtual platform also helps enforce secure isolation between functionally independent tasks running on the same processor complex.
Containerization boosts flexibility and the ability for OEMs to deploy updates. This is particularly beneficial for parts of the system where OTA updates are likely to be frequent, such as the infotainment modules in the vehicle cabin. While they will be more decoupled, hardware interfaces and the dependencies they impose will remain vitally important to the functionality of the car’s real-time control and safety systems. Developers need to see how hardware changes impact their software and the digital twin is the solution.
A digital twin is a virtual model that replicates hardware and firmware behavior. Using a digital twin, there’s no need for developers to access hardware to perform most of their tests. The twin can run in desktop tools or cloud-based containers either in interactive debug mode or in highly automated regression test suites. The regressions perform a variety of tests that accelerate quality-control checks whenever changes are made. Increasingly, teams are also making use of analytics and machine-learning techniques to find bugs faster.
Updates can be tested against any other code modules or subsystems to check whether changes lead to unexpected interactions or problems. The digital twin does not entirely replace hardware in the project. Conventional hardware-in-the-loop (HIL) tests are still necessary to check the behavior of digital twin simulations against real-world conditions, but once divergences in behavior are ironed out, the digital twin can be used extensively to support mid-life updates. Extensive pre-hardware tests can run at speed in the cloud across multiple servers, giving OEMs the confidence to roll out OTA updates with new features as soon as they’re ready.
SDV virtual model
Using Highly Detailed Models
The accuracy of models is important, although many tests do not require fully timing-accurate models. Highly detailed models typically run slower than fast models optimized for analyzing instruction throughput and application logic on the target processor. The test time and verification process can be streamlined by partitions that only run those component or subsystem models that need fully detailed simulations.
Although digital twin models can be built by OEMs and subsystem suppliers, there’s a significant advantage to creating partnerships with the right semiconductor suppliers. Vendors such as NXP Semiconductors have committed to developing models of their silicon platforms for as much as a year before the products are ready to ship to OEMs for assembly into prototypes and end products.
Digital models can also help OEMs and subsystem providers to understand how architectural innovations can benefit target applications. Magnetoresistive random access memory (MRAM) is a great example, providing a high-performance alternative to flash memory that also overcomes the limitations of volatile DRAM and SRAM for persistent data. A basic model may treat non-volatile memory such as flash and MRAM as equivalent and make no distinction in latency or bandwidth. More accurate models can reflect the differences in write and read times and other aspects of behavior.
The differences can be leveraged by changes to the code base that take full advantage of the technology where available. As a result, by adopting a model-centric approach to development, software teams can help specify future hardware implementations to improve performance over several generations.
Continuous Improvement
The methodologies underpinning stretch right will enable continuous improvements to both product quality and service revenue. Along with OTA updates for the vehicle itself, OEMs can collect sensor data from the running systems and apply them to a variety of machine-learning and analytics systems. This information can be filtered and applied to digital twin simulations to gauge real-world performance.
This enables improvements to be tested in the regression environment before being deployed in a new OTA update, and shorter times between development and deployment will lead to a much faster cycle of product refinement. This will see improvements to existing hardware, while enabling a further shift left for future generations. It’s also a further demonstration of how a holistic approach to development, encompassing continuous integration and digital twins, can streamline product design and support.
This content was based on an article previously published in EEtimes.
