In the virtual loop

With tens of millions lines of code in a single vehicle, the automotive industry is experiencing rapid growth in software content. This explosive growth comes with its own challenges: transition from single core to multicore platforms, developing AUTOSAR (AUTomotive Open System Architecture) applications, integration and test of embedded software and functional safety and these are just some of the concerns directly linked with growing software content. For many years, developers of automotive embedded control systems have relied upon well-established functional level design approaches such as model-in-the-loop or software-in-the-loop. However, these approaches do not take into account the underlying hardware platform. The increased complexity of these platforms means that developers cannot wait for the ECU hardware to be physically available in order to start developing, integrating and testing their embedded software. New and better techniques need to be introduced that enable early development, integration and test, while also improving the developer’s productivity and containing associated costs.

Figure 1 - Shifting the development of ECUs to earlier in the design cycle

Simulation technologies are being used to establish a virtual Hardware-in-the-Loop (vHIL) environment well before physical hardware is available. Such an environment combines the simulation of digital hardware using VDK for MCUs with other simulators including analog hardware and mechanical system simulation. A vHIL environment is the foundation for a broad range of development activities including early software development, system integration, performance validation, fault and coverage testing in support of ISO 26262 and regression testing. The result is an enhanced development process that shifts design task earlier, improves testing coverage and identifies possible defects early in the design, leading to better overall product quality and reliability, reduced costs and faster time to market.

Growing content

In recent years, software content in automotive applications has grown drastically. This has led to an increased number of challenges related to recalls and redesigns due to software. The implication of these recalls has had a negative impact on costs as well as brand image. A simple search through the recent automotive recalls and industry discussions currently on-going, illustrate this trend. As an example, an article from IEEE spectrum highlighted the ‘Recalls of 936,000 More Vehicles for Electrical and Software Fixes’. The article emphasised how software related issues could effect mechanical systems, such as the software upgrade that would ease the transition between gears to reduce the possibility of damage.

With between 10 and 100 million lines of code, integrated across 50 to 100 controllers and 150 distributed functions, every car manufacturer is affected by the growing concern of increased software in automotive development. The result is that software development has become the biggest challenge for automotive companies. When it comes to safety critical applications, it then becomes essential to identify new methodologies and tools that will help improve software quality and reliability, scale to the complexity of automotive systems and enable companies to contain software testing costs.

Over the past 20 years the development of the ECU has seen some significant evolution. Three areas are of interest are: modeling and simulation; code generation and AUTOSAR. The fundamental elements of ECUs are the hardware platform (digital and analogue), the embedded software infrastructure (OS, connectivity, etc.) and the control algorithm, combined to achieve the targeted function. From a development perspective, the validation and verification of the ECU cannot happen independently and must take place in the context of the environment with which the ECU interacts.

In the mid 90s, modeling and simulation emerged as a key approach to model the algorithm and the environment. These models could then be simulated together. Tools such as Matlab/Simulink have played an essential role when it relates to functional simulation of the algorithm. The need for such simulation was driven by the increased complexity of the systems under development. Such simulation environment is also known as Model-In-the-Loop (MIL).

Figure 2 - Limitations of ‘in-the-loop’ technologies

Following the deployment of modeling and simulation, the concept of code generation made in-roads. Given that the developer had models, the idea was to start ‘compiling’ the models from the graphical representation used in algorithm designs to a high-level language like C. The generated code could be executed on a PC, specialised hardware or on an embedded target. Code could be generated for the control algorithms or the environment models. The use of code generation led to multiple development platforms including Software-in-the-Loop (SIL); in this approach the control algorithm generated code is compiled on a host PC and executed in conjunction with the environment model. This approach focuses on software correctness and execution speed. Processor-in-the-Loop (PIL) is an approach where the control algorithm is executed on an evaluation board. This approach enables the software to be run on the target hardware architecture. With Hardware-in-the-Loop (HIL), the actual hardware platform executing the embedded software is used in conjunction with code generated for the environment model and executed on a dedicated hardware platform.

A few years ago AUTOSAR emerged as a standardised automotive software architecture driven by leading automotive OEM and tier one companies. An AUTOSAR simulator has been used in the development of embedded software, they however are compiled for execution on a host PC and do not incorporate any MCU hardware consideration. The evolution of this development process has been focused on early validation of the design and its generated code to avoid design iterations late in the development process. The approaches described above have provided a great set of benefits to automotive ECU developers, but still leave developers with development gaps.

MIL and PIL do not take into account the underlying hardware platform, which are increasing in complexity and capabilities (e.g. newer MCU for automotive applications leverage multicore implementations). HIL requires the ECU hardware to be available and a significant gap in time and effort exist between the PIL and HIL availability.

Virtual hardware benefits

Looking at the overall development process, it is clear that modeling and simulation has brought significant value. However these concepts have only been applied to the control algorithm and the environment models; they have not been applied to the hardware platform. This has mostly been due to the fact that hardware oriented simulation to date has not been able to meet the execution speed expectation of developers. In addition these simulation environments are often contained within semiconductor companies and not easily accessible to developers at OEM and tier one companies.

Virtual prototyping has emerged over the past few years as a key methodology to enable early software development. This proves models digital hardware at a higher level of abstraction using the IEEE 1666 SystemC Language including support for Transaction-Level Modeling. Virtual prototypes are a fast software model emulating a hardware platform (MCUs or a network of ECUs) and execute on a desktop PC (Windows or Linux). Virtual prototypes execute unmodified software binaries that execute on the hardware platform. Virtual prototypes deliver key capabilities including: observability; controllability; non-intrusiveness; determinism; and scriptability.

Figure 3 - Example of vHIL on a PC using Simulink

These capabilities are enabled through virtual prototype software development tools that work in parallel with existing software tool chains. For example, developers can use virtual prototypes to stop the full system execution at any point in time (even in a heterogeneous multicore hardware platform). They can then read and modify any internal values, correlate hardware and software execution or apply scripts.

A Virtual Development Kit (VDK) is a software development kit integrating a virtual prototype as the embedded hardware target. A VDK can be easily maintained, deployed and archived to distributed teams worldwide.

Virtual prototypes provide the technology required to complement the current limitations of the existing development approach. A vHIL environment, combining a VDK executing the embedded software and executing in conjunction with the environment simulation, can be available earlier, deployed more easily and provide a more efficient development platform. Overall it enables developers to integrate, in a simulation environment, the last key element of the ECU: the physical hardware. Overall the deployment of such technology will lead to reduced development costs, improved software quality and system reliability.

These benefits are delivered through the major areas of availability, productivity and deployability. Early availability will enable developers to start software development early, to front-load test development and execution. The visibility and controllability provided by a vHIL environment enables developers to identify and fix problems more efficiently. With the capability to deploy and maintain, the set-up and maintenance of such environments can be centrally located, making them simpler to archive, or be deployed through FTP or a server farm and easily reconfigured.

Figure 4 - Earlier fault testing using VDKs

Once the VDK is integrated in a vHIL environment, a broad range of use cases can be addressed. First, the system integration and test can be done virtually, developers can front-load the development of the test and their execution. It is a well understood concept that finding errors earlier in the design process significantly reduces the cost of fixing issues later on. The second use case is for coverage and fault testing. In this case a vHIL environment provides significant advantages as fault can be injected anywhere, the state of the system can be modified and permanent fault can also be created. Corner cases can be tested and validated. Here again, to understand what errors should be corrected or modification included earlier represents a great benefit. A last example is regression testing. A virtual environment can easily be deployed in a server farm, thus allowing the overnight and early validation of multiple software stacks representing different vehicles or vehicle configurations.

Management perspective

As management considers the deployment of a virtual approach for automotive electronics, several considerations come to mind. The decision to broadly deploy VDKs in the development process will most likely be based on a strategic direction to improve the development process. Analysis done by leading OEM and tier one suppliers, show that a qualitative analysis decision factor is often based on mitigating development risks, while a quantitative analysis factor will be most influenced by engineers’ productivity. For companies new to this approach, a pilot project should be considered to establish internal experience. A pilot project will be most efficient if clearly defined and targeted to be executed in parallel to a production project. It should also leverage the wide variety of shared knowledge on the topic from industry events and conferences. Finally when it comes to the deployment of virtual technologies, it must be supported by a vendor with a broad range of capabilities including: experience with simulation and tool technologies for hardware, long term established engagements with the automotive IP and semiconductor supply chain, a global presence for local support and deployment services and a financially stable vendor with an investment approach to support long term automotive projects and industry growth.

The complexity of MCU hardware, functional safety certification and system complexity are driving automotive OEM and tier one companies to continue evolving the development process. Virtual prototypes and VDKs bring modeling and simulation concepts to the hardware, thus enabling the creation of a virtual environment that includes the embedded software, the ECU hardware and the environment being controlled. The integration of a virtual Hardware-in-the-Loop solution in the development process for ECUs enables automotive OEM and tier one companies to contain/reduce development costs, improve software quality and increases the overall system reliability.