1. Overview:

In modern passenger cars, various components work together to realise a smooth and superlative driving experience: Both to the user driving the car and to users riding the car. Primary interaction of driver of the vehicle is with the Automotive HeadUnit. An Automotive HeadUnit, also called as Infotainment System, is a unified interface (typically touchscreen in modern cars) to receive information and control various aspects of the vehicle.

Representative image of HeadUnit (Ref:1) :

Modern Automotive HeadUnits are equipped with advanced technologies and capabilities. One of the primary capability of HeadUnit is to communicate with backend systems. Communication with backend happens over internet using data connection via a DCM (Data Communication Module) or using user’s hotspot. HeadUnit communicates with backend services to:

• invoke initialisation API sequences
• send ON-WAKE messages to backend services
• fetch vehicle configuration parameters
• fetch state of vehicle parameters
• fetch user information and user specific configuration parameters
• update changes to user information by user
• save updated state of various vehicle parameters

This list of interactions are events with defined execution time, sequence and periodicity. Different manufacturers define and implement these interactions differently, resulting in a myriad combination and timings of above listed events. There is currently no standard or specification on interface specification, execution time and periodicity of these events.

2. The Problem:

As modern automotive HeadUnits become more advanced and provide more advanced features and experience, supporting backend services also have evolved into advanced and complex systems. Development of backend systems becomes complex and their testing becomes ever more challenging.
While traditional API testing is sufficient to validate individual APIs, such testing may be limited when it comes to testing complex interactions between HeadUnit and Backend. Developers and Testers respond with custom scripts and tools to emulate the sequence of events. But such approaches are siloed with limited sharing or re-use. Chances are high that team members duplicate scripts and tools already developed by other team members. Individual team members might come up with similar mechanisms to test the sequence of events from HeadUnit. Some better than others.
Usually, the sequence of events/interactions scripted by developer is limited to happy path. This is helpful to developer to test the basic use case. However, for any alternative use case or negative scenario the script needs to be modified. Typically, these scripts and changes are not version controlled. This could lead to repetition and wasted effort to make and revert changes.
Many scripts typically have hardcoded values and externalization or parameterization of scripts depends on maturity and foresight by developers. Many a times, scripts with hardcoded values are not portable and even if shared with other team members, additional effort needs to be spent to update the script with correct parameter values.

3. The Solution:

When the real hardware is not available or when it is not feasible or is not safe for operation, a safer, simpler imitation of the real hardware is used. Usually, the imitation has the same interface, look and feel of the real device.

However, simulator differs from real device:

• number of functions in simulator may be limited as compared to real hardware.
• simulator functions may have simplified implementation.
• simulator functions may be allowed but function is not at all implemented or does nothing.
• limited integration with physical devices such as Bluetooth, CAN, speedometer, GPS, sensors, etc.

A Simulator is defined as (Ref:2):
“a machine designed to provide a realistic imitation of the controls and operation of a vehicle, aircraft, or other complex system, used for training purposes.”

In case of simulator for an automotive Head Unit, many of the internal capabilities of the real device are not available or not implemented. Event generation and event processing is coded by developers as per need.

4. Benefits

Even though the simulator needs to be developed and coded, availability of such simulator during development is very helpful.
Following are some benefits:

• Enables testers to perform tests as if using the real device.
• Reduces wasted effort in developing custom test scripts by team members.
• Provides capability to invoke API calls to backend systems even in absence of a physical/real Head Unit.
• Depending on mechanism of parameterization, testers can customize head unit parameters without having to edit code and inadvertently break functionality.
• Parameterization of the simulator allows testers to customize Head Unit parameters as per need.
• Provides repeatability: as the functions are coded, any operation on the UI can be repeated as per need.
• Capability to automate test cases using automation tools like Selenium, Appium, TestComplete, etc. Possible to incorporate these automated tests as smoke test or sanity tests as part of CICD pipeline.
• When properly implemented, simulator provides scope for testing complex user interactions.

References:

1. https://www.parkers.co.uk/toyota/yaris-cross/review/interior/
2. https://nehrusciencecentre.gov.in/motion-simulator-ride/