Automotive suppliers and government organizations like the NHTSA are working towards the creation of autonomous, self-driven cars with the twin goals of greater operational safety and more efficient fuel consumption.
Advanced driver assistance systems (ADAS) refer to the various vehicle systems for automating, adapting, and enhancing safety and better driving, such as adaptive cruise control, automatic braking, and car lane adherence (staying in the correct lane).
In this journey to autonomous vehicles, a variety of ADAS subsystems are emerging as milestones. Thus today's connected car has “semi-autonomous” capabilities.
At the same time, drivers and passengers (riders) want in-car entertainment systems that are intuitive to use, keep drivers safe on the road and maximize the rider's connection to the rest of his/her life. These systems are categorized as In-car entertainment (ICE), or in-vehicle infotainment (IVI). This includes support for:
- USB media devices with the rider's songs and favorite playlists
- Smart Radio so the rider does not miss favorite radio broadcasts and podcasts.
- Handsfree calling and text message alerts
What parts of this require communications testing?
ADAS technology is based upon vision/camera systems, sensor technology, car data networks, Vehicle-to-Vehicle or Vehicle-to-Infrastructure systems. ADAS will increasingly leverage wireless network connectivity to offer improved value by using car-to-car and car-to-infrastructure data.
The connected car infotainment systems already incorporate wireless and 3G/4G network connectivity along with satellite downloads and Bluetooth.
Bluetooth testing issues
Since the introduction of iOS 8, car owners have been battling dropping Bluetooth connections, no Bluetooth connections and even problems playing music via USB ports as well as functionality loss such as lack of text messaging or other features.
This particular set of problems highlights a key issue with connected car developments: version mismatches.
The average automobile is expected to be on the road 11.4 years.
However, the average age of a smart phone is 21 months.
Thus the combinations of automobile models, smart phone models, and operating system revisions that require Bluetooth compatibility testing and checking is very large. Empirical evidence suggests that no one is conducting this level of testing!
Here's an example:
Testing the communication performance of the Infotainment and ADAS systems.
In-vehicle networks are mobile networks. Mobile networks perform more poorly than their wired counterparts on the following four performance metrics:
- Round Trip Time (RTT)
- Packet Loss
Emulating these conditions in the lab with our network emulator, will demonstrate how well the infotainment and ADAS subsystems will perform over the range of conditions that occur on mobile networks.
Our white paper, “Emulating 3G/4G Networks” describes the minimum and maximum values, one may expect for each of the four performance metrics above.
Here's an example:
On a 4G/LTE network, jitter can vary from zero/none to 6 ms.
- What happens to your app when confronted with 6 ms of jitter?
- Does it compensate for the jitter and still provide a great user experience?
- If it does not, can you improve it?
Your goal is precise, deterministic performance data for all of the minimum and maximum conditions for each of the four performance metrics. Then depending on the resulting quality, you can attempt to optimize it through further engineering and warn the user of the limits of your app or device under suboptimal network conditions.
Why use a network emulator? Why not do some ad hoc testing with a 3G or 4G telephone?
Using a 3G or 4G telephone will not allow you to correlate poor performance with network conditions. You might learn that at 10 am the 3G phone was fine, but at noon, the voice quality was not acceptable. But what caused the unacceptable voice quality? Packet loss? If so, how much?
Until you have accurate answers to these questions, you will not be able to tune your app or device to perform correctly at these limits.
And, what if you have the answers, but you simply cannot accommodate the limits in your app or device?
You will need to create a message or other indicator for the user to let her know. Consider:
“Current network conditions are poor. Try again later.”
“I am really sorry, but I cannot respond right now.”
How will your app perform in a moving car when the source of the data is a satellite?
Both infotainment and ADAS applications may have source information originating from a geosync satellite.
This communications scenario has two key components: the fixed delay from the satellite to the ground station and the variable delay from the cell tower to the automobile. The signal from the ground station to the geosync satellite travels about 22,000 miles up and then 22,000 miles back down.
- Geosync satellite communication automatically introduces a network delay of about 0.24 seconds or 240 milliseconds.
- Other variables include the link rate, min and max payload size, header overhead queue length, and so on.
And of course, that is just on the satellite side.
In addition, one must factor in the minimum and maximum range of network conditions from the ground station to the cell tower.
Finally, the variable network traffic from the cell tower to the automobilemust become part of the overall emulation to clearly model all the operational conditions for infotainment and ADAS communication originating from a geosync satelittle.
Testing Infotainment and ADAS (driver assistance) communication in the connected car can be addressed with the Maxwell family of Network Emulators. Configure Maxwell in your lab network to emulate any combination of access networks including 3G, 4G/LTE, satellite and many others.