Testing Communications in the Connected Car
Automotive suppliers incorporate more and more microprocessors in vehicles – from powertrain to Driver Assistance (ADAS) to Infotainment to Electronic Control Units (ECU). As a result, software complexity increases with each additional component or subsystem. Managing the implementation, operation, and quality of that additional complexity presents a challenge. Automotive suppliers want to deliver increased functionality while preserving operational safety standards.
Layer 3 and 4 Testing
Our communication performance tests reveal how well the automotive components and subsystems perform under adverse network conditions, so that the component provider can anticipate, plan and address component behavior under these conditions.
The figure to the left illustrates the OSI model of communications networking. IWL tests for the correct implementation of the protocols at Layer 3 the Network Layer and Layer 4 the Transport Layer.
Layer 2, the Data Link Layer, and Layer 1, the Physical Layer, represent the lower level electronic signaling and physical interfaces supporting the network communication. The chip and card suppliers for these products provide tests for these layers.
The Automotive Ethernet standard: 100BASE-T1 is fully supported.
Mobile Network Performance Testing
Typically communications performance testing for connected cars means a mobile network.
Mobile networks perform more poorly than their wired network counterparts on four performance metrics: Throughput, Round Trip Time (RTT), Jitter and Packet Loss.
The component or subsystem designer must tune and improve the network communication algorithms to yield optimum performance. However, in some conditions, the network will prove inadequate and the user must be notified to "try again later."
Components and Subsystems that Require Testing
Components exchanging data with another component, another vehicle, a satellite or other external communication nodes (vehicle-to-infrastructure communication) require network communications testing:
- Safety systems
- Driver assistance (ADAS)
Functional Tests include:
- Negative Testing (Fuzz Testing)
- Inopportune Testing
- Conformance/Compliance Testing
- Interoperability Testing
- Deep-path Testing
Stress and Reliability Tests include:
- Load Testing
- Stress Testing
- Performance Testing
- Line Speed Testing
- Robustness (Security) Testing
- Endurance Testing
AUTOSAR Testing Solution
The AUTomotive Open System Architecture is used for most ECUs (electronic control units). (See diagram). For infotainment and driver assistance (NAV), the original AUTOSAR standard did not scale well, so developers used embedded operating systems, such as – Elektrobit, Euros, Freescale, Green Hills, Linux, Mentor Graphics, QNX and many others.
AUTOSAR classic did not scale well for Infotainment and Driver Assistance, but the future version does.
The automotive supplier may choose to:
Read the standards specifications and do the implementation. License an AUTOSAR implementation from an embedded system supplier Implement an open source solutions
Protocol and Robustness Testing: Why is this important?
TCP, IPv4, IPv6 related protocols are used in AUTOSAR and open source embedded software.
Unfortunately, many of the existing TCP/IP stacks or engines are not sufficiently robust for automotive quality standards.
The testing results for a popular desktop operating system are published here and reveal the poor quality of implementations that were “certified” at the highest levels.
How does one effectively test?
The TCP family is used in AUTOSAR.
How do we test for robustness, security, interoperability and conformance/compliance?
Use Maxwell Pro TCP/IP Test Suite to send pathological TCP segments to the device under test.
- The device will have to respond appropriately.
- It should not hang or crash.
- It should exhibit the proper behavior as defined in the standards document