Software in the Loop

What Is Software in the Loop

Software in the Loop is a way of testing automotive application code by using a simulated environment. This provides a quicker and more cost-effective method for evaluating new features and discovering bugs than live testing in a production product. It tends to be used in the early stages of the development process before more expensive hardware in the loop testing, and then live production assessments in prototype vehicles are made before release.

Benefits of Software in the Loop

As code becomes central in the shift towards Software-Defined Vehicles (SDVs), there is greater focus on application development in the automotive sector. The applications being developed include advanced safety, infotainment, user experience and emerging autonomous driving capabilities. Software in the Loop testing speeds up and reduces costs through these primary benefits:

  • Simulations can be run on generic desktop computing equipment rather than requiring specialized equipment. This enables many tests to be performed by numerous software engineers.
  • Purely software-based simulations can be performed faster than in real-time, speeding up the testing process.
  • Many iterations of a test can be performed with minor adjustments in parameters, enabling an in-depth and comprehensive analysis.
  • Software developers can develop features faster than the slower pace of hardware development.
  • Individual elements of a software product can be tested without the need to complete the entire product first.
  • Multiple tests can be conducted simultaneously to speed up development, even running simultaneously on a single testing computer.
  • Simulations can be adapted for use with hardware in the Loop testing later in the development process.
  • Results can be easily shared internally between development teams within an OEM and with third-party suppliers.

Examples of Software in the Loop

Software in the Loop testing can be applied in many scenarios. For example, to test an Advanced Driver-Assistance System (ADAS), the inputs recorded from cameras, radar, LiDAR, ultrasonics, and other sensors under a comprehensive range of conditions will be modeled. This could include the detection of heavy surrounding traffic, the effects of rain or snow on sensor inputs, or a vehicle unexpectedly stopping very quickly. The behavior of the ADAS system software can then be assessed against these different environmental changes to see if the required level of safety is delivered.

Another example could be testing the ergonomics of a digital cockpit design. The physical car interior characteristics and various driver body shapes and sizes can be tested against each other to ensure that every potential customer can interact with the digital cockpit systems comfortably.

One more example could be an infotainment system composed of components from various in-house and third-party suppliers. The compatibility of these components to work together can be tested within a simulated model of the infotainment system hardware to ensure sufficient responsiveness and prevent bugs.

How Software in the Loop Works

To create a Software in the Loop testing environment, developers will generate models of real-world conditions against which their application designs will be assessed. The models will simulate dynamic systems, such as physical hardware stresses, human inputs from drivers, and road conditions. A range of sensor data inputs will be simulated. The code being tested can be run with every possible combination of inputs to find bugs, assess performance, and ensure the necessary functionality is delivered.

Software in the Loop Vs. Hardware in the Loop

Hardware in the Loop and Software in the Loop are closely related, but the software version generally sits at an earlier stage in the development process. Where hardware in the Loop tests the physical ECUs and control circuitry alongside operational applications, Software in the Loop will test the code within a simulation of the hardware it is intended to run on against emulated sensor inputs and actuation outputs. This can inform the development of hardware, which will be tested in a simulated environment before release.
The QNX® Hypervisor is a real-time, Type 1 hypervisor that offers virtualization technology and enables the secure separation of multiple operating environments on a single SoC. QNX Hypervisor brings containers to connected automobiles as a way to segment non-safety applications from critical systems.

Check Out Our Other Ultimate Guides

Structural Dependency
Learn about software-defined vehicles, including their benefits and architecture.
Structural Dependency
Covers topics such as embedded systems protection, security exploits and mitigation, and best practices
Structural Dependency
Learn how cloud computing for automotive works and its benefits.
Read the Guide
Structural Dependency
Defines autonomous systems and the various levels of autonomy
Read the Guide