How much do you know about the major changes in product development brought about by software-defined cars?

The software and hardware of embedded systems are often tightly coupled and intricately intertwined. Developers face constraints such as limited resources and tight deadlines, and must ensure seamless integration. This requires multiple rounds of device testing.

This approach does not work well with rapid product development lifecycles and is not compatible with service-oriented business models. Rather than relying solely on critical or limited firmware updates during repairs, automakers are embracing the concept of software-defined vehicles (SDVs) . SDVs aim to continue to evolve and enhance throughout their lifecycle.

A platform approach is necessary to achieve SDV. By decoupling hardware and software, application and architecture design become more flexible, and additional features can be added over time. Decoupling also helps increase software reuse in different models and reduce the cost of adaptation between platforms. Car owners will also enjoy greater safety and reliability while reducing energy consumption.

This approach will revolutionize automotive software development. We will see the industry "shift left" to complete software earlier in the product development lifecycle, even before prototype hardware is in production. At the same time, the industry can "stretch right" to continue updates after the vehicle is sold. This allows automakers to find new revenue streams through cloud-based services, make their services available to owners of different models, and add features throughout the life of the car through over-the-air (OTA) updates.

The concepts of continuous integration and continuous deployment (or near-continuous deployment) have been successfully applied in the enterprise space for many years. "Shifting left" and "extending right" are the next logical steps. If the development team chooses the right software development method, the requirements of the two are largely consistent.

SDVs are not fundamentally different from other embedded systems and supporting technologies. For example, virtualization and software containers can isolate software modules and abstract them from the underlying hardware. The advantage of this approach is that it can be more easily integrated with cloud processes for multiple value-added services. Such services often combine core automotive functions with artificial intelligence (AI) and cloud-based analytics.

The core change with embedded systems is that you no longer need to do extensive prototyping on physical hardware, or at least minimize the work involved to ensure that assumptions about timing and hardware behavior hold true. However, embedded systems do require one additional component.

Containerization is an important element of adopting continuous integration and deployment methods in cloud environments, which can reduce the hardware dependency of applications. Applications can be packaged together with supporting libraries and device drivers for testing, thus isolating them from the underlying operating system. In embedded environments, an additional layer of isolation and protection is required, which is provided by virtualization technology. In a virtualized environment, the hypervisor maps I/O messages to the underlying hardware. The management of the virtual platform by the hypervisor also helps to securely isolate independent tasks running on the same processor complex.

Containerization increases the flexibility and ability of automakers to deploy updates. This is particularly helpful for parts of the system that require frequent OTA updates, such as the entertainment center console module in the cabin. Although these modules will be more independent, the hardware interfaces and their dependencies are still very important for the real-time control and safety systems of the car. Developers need to understand how hardware changes affect their software, and digital twin technology can solve this problem.

A digital twin is a virtual model that replicates the behavior of hardware and firmware. With the help of digital twin technology, developers can complete most tests without accessing the hardware. Digital twins can be run in interactive debugging mode or highly automated regression test suites, either on desktop tools or in cloud-based containers. Regression testing speeds up quality control checks when changes are made by performing multiple tests. In addition, the team can use analysis and machine learning techniques to find bugs faster.

Updates can be tested against any code module or subsystem to see if the changes will cause unexpected interactions or issues. Digital twins do not completely replace hardware in a project. Traditional hardware-in-the-loop (HIL) testing is still necessary to check the behavior of the digital twin simulation under real-world conditions, but once behavioral differences are resolved, digital twins can be used extensively to support mid-cycle updates. Extensive pre-hardware testing can be run at high speed on multiple servers via the cloud, giving automakers the confidence to deploy OTA updates based on new features at scale as soon as they are ready.

Model accuracy is very important, although many tests do not require fully accurately timed models. Highly sophisticated and detailed models typically run slower, while those optimized for analyzing the target processor's instruction throughput and application logic are faster. Test time and verification processes can be simplified by running only the partitions of component or subsystem models that require fully detailed simulation.

While automakers and subsystem suppliers can build digital twins on their own, there are significant advantages to partnering with the right semiconductor supplier. Suppliers such as NXP Semiconductors commit to developing models of their chip platforms a year in advance, before the products are delivered to automakers for assembly into prototypes and final products.

Digital models can also help automakers and subsystem suppliers understand what benefits architectural innovations can bring to target applications. Magnetoresistive random access memory (MRAM) is a good example. It is a high-performance alternative to flash memory while overcoming the limitations of volatile DRAM and SRAM in persisting data. Basic models can treat non-volatile memories such as flash and MRAM as equivalent memories, with no difference in latency or bandwidth. More accurate models can reflect their differences in read and write times and other behaviors.

These differences can be exploited by making changes to the code base to take advantage of existing technologies. Thus, by taking a model-centric development approach, software teams can help specify future hardware implementations to improve performance over multiple generations.

Approaches that support “reaching right” will continue to improve product quality and service revenue. In addition to OTA updates to the car itself, automakers can collect sensor data from running systems and apply it to a variety of machine learning and analytical systems. This information can be filtered and applied to digital twin simulations to evaluate performance in the real world.

This allows improvements to be tested in a regression environment before new OTA updates are deployed, reducing the time between development and deployment and accelerating the product improvement cycle. This not only enhances existing hardware, but also lays the foundation for future technological changes. This also further proves that a holistic development approach that includes continuous integration and digital twins helps simplify product design and support.