Blog series: QAC Automotive and Robotics Quality Assurance (No. 6)

Blog series: QAC Automotive and Robotics Quality Assurance (No. 6)

colourful image of self driving vehicle and person crossing the street

QAC Automotive and Robotics (QAaR) Quality Assurance

Welcome to the sixth edition of the QAaR newsletter. In this edition, we’ll focus on sharing more information about vehicle data and different types of communication networks that might be part of a vehicle.

This document will go into more detail about the most important communication protocol in CAV vehicles, CAN, and how the data generated by several components can be used for testing purposes.

QA Consultants’ Automotive and Robotics Quality Assurance Workstreams

Research and Grand Projects
Grant budgets allow for research and development of new technologies that position QAC to become a world leader in quality assurance services.

AQS (Automotive Quality Services)
Testing and Quality Assurances services exclusively developed for Automotive and Autonomous Road vehicles.

RQS (Robotics Quality Services)
Testing and Quality Assurance services exclusively developed for Robotics and Autonomous small vehicles.

Safety and Cybersecurity
Focus on developing services that adhere to ISO’s compliance verification testing automation Cybersecurity, and Connectivity standards.

Automotive System Integration Testing

Mesh Model with Static and Dynamic Obstacles

As mentioned in previous editions of the QAaR Newsletter, our team has created a framework for Automotive System Integration Testing (SIT). We have learned that automobiles are very complex. These days, vehicles have numerous electric components controlled by many different data types, all of which are being called to perform actions at the same time in a fraction of a second. In order to build a fully integrated testing platform, it was necessary to deeply understand the different types of data, through different communication networks, with different protocols that are part of a connected and autonomous vehicle. In this edition, the focus is on CAN protocol and how CAN messages can be handled by our test framework.

Silver car with arrows naming parts of the car

SIT testing components in a vehicle can be complex. The picture above shows a small portion of components required to be checked during a simple test that goes through several different communication protocols. Through a model-based testing approach, we have built out all valid SIT test cases based on the components and how they interact with each other.

Each component may respond in a different way given an action performed by the driver, the passenger or by another component in the vehicle.

Challenges to the test vehicles

  • How to identify an action and the components involved?
  • What components are impacted by an action?
  • What component(s) is (are) expected to receive data messages?
  • What is the communication protocol (network + data type)?
  • How do we capture the information we can identify the in-vehicle network?
  • How we ensure the expected components received specific communication from another component and reacted as expected?

Example of Automotive Components and Some of their States

Engine System Braking System Steering System Infotainment System Electrical System HVAC System Instrument Cluster

ECU

  • Control Timing
  • Idle Speed
  • A/F Mixture

Speed Control Units

  • Cruise
  • Adaptive Cruise
  • Manual

Gear

  • Parking
  • Reverse
  • Neutral
  • Drive
Breaking Line Value

  • Pos1 Open
  • Pos2 Close
  • Pos3 Partial

 

 

 

 

 

 

 

 

Lane Assist

  • Send warning
  • No warning

Lane Keep

  • Correct right
  • Correct left
  • No correct

Lane Centering

  • Continuous correction
  • Disabled

 

 

Audio

  • Radio (AM/FM)
  • CD/DVD
  • Aux 3.5mm
  • USB
  • Bluetooth

Voice Commands

  • Text
  • Phone

 

 

 

 

Head Lights

  • On
  • High
  • Off

Brake Lights

  • On
  • Off

Turn Left Front Light

  • On
  • Off

Turn Left Rear Light

  • On
  • Off
Temperature

  • Low
  • Med
  • High

Head Direction

  • Foot
  • Foot & Body
  • Body & Face
  • Windscreen

Defrost Rear

  • On
  • Off

 

Speedometer

  • Zero
  • Low
  • Med
  • High

Low Fuel

  • Alert off
  • Alert on

Washer Fluid

  • Alert off
  • Alert on

 

 

The idea behind how automotive system integration tests happen

A model that abstracts a vehicle can be represented by a set of components and how their states interact with other components and their respective states. When a state of a component changes from an initial state to a different state, that change might affect one or more components in a vehicle. If we consider a simple scenario where two vehicle’s components are verified: Gear, an engine system component; and Speedometer, an instrument cluster component, whenever a gear state changes to reverse (either from parking to reverse, or from neutral to reverse), the speedometer is affected and should have its state set to zero.

In the test execution framework developed by our team, we call an activator any component which state affects one or more components in a vehicle. The impacted components, the ones that react to an activator is called a responder. The mechanism of checking the current state of a component is called the listener.

In order to understand how a listener works and all mechanisms involved in the process of listening, we need to understand how the states of a component can be identified. Although the high complexity of the whole framework, the idea is relatively simple: components in a vehicle keep communicating each other all the time, sending and receiving messages through different buses, known as communication networks and further detailed in next sections.

 

Our approach focuses on a model-based SIT framework that constitutes four main steps: generation of the system’s functional model, generation of test cases, prioritization of test cases, and execution of test cases using machine learning algorithm. The system under test (SUT) model comprises of both physical hardware-in-the-loop (HIL) and virtual (simulated) components.

Vehicle Communication Networks

Different communication networks are found in a vehicle and each of them transmits a specific type of data to ECUs. The protocols explored by QAC are:

  • Controller Area Network (CAN)
  • Media Oriented Systems Transport (MOST)
  • Local Interconnect Network (LIN)
  • Flexray Automotive Communication Bus
  • Automotive Ethernet
  • Onboard Automotive LTE, Wi-Fi, and Bluetooth connected devices

Automotive ECU system

 

CAN protocol is the current standard for a vehicle communication network, used for several purposes, including powertrain, chassis, and body systems. MOST is a bus standard for vehicle multimedia networks designed to enable the transfer of high-quality audio, video, and data. LIN is a vehicle communication protocol that uses a single master to achieve a superior cost-performance ratio, used in switch input and sensor input actuator control. FlexRay is a high-speed communication protocol that provides a high degree of flexibility and reliability. Automotive Ethernet is basically a diagnostic protocol for engine, chassis, and body electronic connection control units used for network connections.

As an example, ECU controls items such as crank position and air-fuel mixture which will maximize thrust while conserving fuel. As you accelerate, the engine control unit will tell the combustion components to speed up hence the car will go faster. When an ECU or component fails, it will produce a fault code which can be read through the On-Board Diagnostic (ODB). This mechanism is ideal not only for testing but for diagnostics on vehicles after purchase. As our automotive system integration testing model evolves, our technology advances to understand all those communication protocols and improve the listeners’ capabilities to detect the current state and. From there, the test execution can be performed by the framework to validate that the state matches the expected results from a test case.

QAC Investing on Quality Assurance Technologies for Automotive Industry

One of the biggest challenges in the automotive industry is to develop a testing suite to resolve public safety risks created by inadequate software testing in connected and autonomous vehicles (CV/AVs). The current standard methodology and best practices do not provide a comprehensive solution to the automotive software system integration testing (SIT). This is due to the existence of a complex combination of various systems and components in CV/AVs. This complication causes performing manual SIT, which ensure proper coverage of requirements, to be extremely difficult or even infeasible in many cases.

Silver car with see-through components

Our approach focuses on a model-based SIT framework that constitutes four main steps: generation of the system’s functional model, generation of test cases, prioritization of test cases, and execution of test cases using a machine learning algorithm. The system under test (SUT) model comprises both physical hardware-in-the-loop (HIL) and virtual (simulated) components.

In our next edition, we will present research that the QAaR team has completed that highlights the exposures, and knowledge sharing of Connected and Autonomous vehicle cybersecurity threats and opportunities to use advanced QA techniques.

Our approach focuses on a model-based SIT framework that constitutes four main steps: generation of the system’s functional model, generation of test cases, prioritization of test cases, and execution of test cases using a machine learning algorithm. The system under test (SUT) model comprises both physical hardware-in-the-loop (HIL) and virtual (simulated) components.