I recently had a discussion with a client about simulating sensors for safety critical systems. With 2 planes falling out of the sky due to a bad response to invalid sensor data, the discussion was certainly timely. There are environmental situations that are relatively easy to create in a lab (temperature for example), but most sensor failure behavior and extreme environment response is harder to physically recreate, requiring simulation.
In this article, we will discuss creating a simulated sensor on Promenade’s HiL system aptly named PHiL. PHiL is our test board, with over 60 pin headers, exposing the IO on an STM32F407 processor. It runs our embedded Parlay codebase, which enables control from the Parlay UI of all of the "items" such as GPIO, ADCs, PWMs. It also allows us to hook up to the system buses.
Most of the sensors we work with are on an embedded serial bus: I2C or SPI. We need to make PHiL behave as our sensor, replacing the real one. To be a replacement sensor, we need access to the bus on the Unit under Test - to be able to disable the *real* sensor and connect it to our PHiL board pin headers. Then, our PHiL board can become a simulated sensor and will behave any way we tell it.
Below is how this works within the Promenade's Parlay system:
The Unit under Test is the master in an I2C or SPI communications interface. PHiL simulates the sensor as a slave device and our Parlay test system communicates how it should behave. Unfortunately, there is not a one-size fits all – each sensor needs a custom PHiL item on PHiLand custom Python code on Parlay. But once we have it in place, we can make the simulated sensor behave any way we choose, setting up scripts to test all sorts of behaviors.
For example, suppose the sensor being simulated is pressure sensor that has some configuration writes, and pressure reads. PHiL will pass the write information (configuration in this case ) to a Parlay Python item that will process the configuration information and stream back appropriate pressure data for future pressure reads. The Python script can send any pressure data we want - erratic, out of bounds, unmoving...
With this technique any sensor behavior can be simulated, scripted,and tested. Below are some examples of what we can do with a pressure sensor:
· Create an erratic profile.
· Generate pressures out of bounds both high and low
· Simulate pressure response to other system events (using other IO lines)
· Stretch an I2C clock line, or hold the data line low...
The extensiveness of the testing should be commensurate with the criticality of performance, but the sky is the limit on what can be tested this way. And speaking of the sky...