Providing synchronized multi-sensor data in Renode with RESD

When deploying consumer-facing products which process multi-sensor data in the field it’s almost impossible to predict all possible scenarios. But massively scalable, reliable and deterministic testing in simulation can get you much closer to that ideal state. The open source Renode framework enables unprecedented levels of automated testing for hardware products, both in development and throughout the product’s lifecycle, by providing determinism and running production binaries just like on the target hardware. Renode supports hundreds of embedded platforms and comes with a range of developer-oriented features such as state saving and replaying, advanced hooks and events, comprehensive tracing, multi-core debugging, etc.

End-to-end sensor-to-actuator flow

Renode provides in-depth control over the environment of simulated hardware, as it is meant to enable end-to-end testing of real production firmware, from sensor input to actuator output. Support for sensors like humidity, temperature or acceleration has been around for many years, alongside the ability to input synthetic and recorded data (showcased e.g. in the TensorFlow Lite integration demos showing gesture recognition with a simulated nrf52840 board). Renode’s testing capabilities allow you to work with end-to-end data, as well as process it and act based on it.
But the pre-existing Renode APIs were not enough for especially demanding scenarios requiring concurrent input of multiple streams of sensor data for processing such as embedded AI, which depend on multiple variables. In that case, it’s necessary to correlate the inputs in the same time domain to ensure consistency to enable faster testing and development. That is why, working together with our customers over the past few months, the RESD format was created.

New synchronized Renode Sensor Data format

A Renode Sensor Data (RESD) file consists of a single file header with the definition of sensor configurations etc., followed by a variable number of data blocks to contain your sensor data. Data stored in the file is split into independent channels, each of a given type (e.g., temperature or acceleration). This allows the use of a single input file for multi-value sensors like IMU. It is also possible to include multiple channels of the same type (each one identified by a unique channel ID), e.g., two channels for temperature sensor readings.

As complex testing scenarios often require streaming a lot of data, the RESD file is encoded in a binary format to limit the file size, and all the numeric data is expressed in little endian for better portability. Since Renode is used in a CI context in many customer projects, the goal was to build a file format that allows you to conveniently add real or fake sensor data to your simulation.

Your sample data will have timestamps encoded as unsigned 8-byte values expressed in virtual nanoseconds counted from the start of the execution. The RESD parser can optionally provide support for a global timestamp addend that is applied to all samples in the file (e.g., to allow loading the same input file twice in different moments of the virtual time). The RESD file format provides a convenient way to define different types of samples like constant frequency samples and arbitrary timestamp samples.

Constant frequency samples will appear in simulation with a defined frequency and contain an additional sub-header providing information about the timestamp of the first sample in a series as well as the period between consecutive samples. For constant frequency blocks, sample timestamps are calculated directly from the start time and period configuration parameters.

When it comes to arbitrary timestamps, you do not specify a period between the samples but instead provide a specific timestamp for each one to simulate irregular sensor readings.

In some complex cases, like when sensor readings depend on additional input generated by a device (for example, blinking LED influencing the value of photodiode), you may also need to provide metadata to keep track of some crucial information related to the sensor reading. Metadata in the RESD file is represented in a binary-encoded dictionary, where each entry consists of a key name, key type, and value.

Supported sensor data types

Currently, your RESD files can use any of the following supported sample types:

• Temperature as a signed 4-byte value expressed in millidegrees Celsius.
• Acceleration as a set of 3 signed 4-byte values expressed in micro g (standard acceleration due to gravity) mapped to X, Y, and Z dimensions.
• Angular rate as a set of 3 signed 4-byte values expressed in tens of microradians per second mapped to X, Y, and Z dimensions.
• Voltage encoded as an unsigned 4-byte value represented in nanovolts, which can be used to describe arbitrary ADC input.
• ECG Signal as a signed 4-byte value represented in nanovolts.
• Custom data sample that can be used to define any model-specific input.

Additionally, there is a dedicated sample type for measurements taken by the MAX86171 AFE sensor, which depends on channel configuration. For example, the value of LED exposure directly influences the photodiode output. A MAX86171 AFE sample (each corresponding to a single AFE sample in RESD) is described as a one-byte unsigned value containing a number of active channels followed by a list of measurement frames, each encoded as a four-byte unsigned value.

Using multi-sensor data in Renode

Loading a RESD file containing samples of your data sensor’s readings can be done using the FeedSamplesFromRESD command in Renode’s Monitor:

sysbus.i2c.sensor FeedSamplesFromRESD path channelId startTime offsetTime

This command requires you to provide the path to your RESD file and the ID of the channel you want to load into your simulation. The latter is required if your RESD file has multiple tracks of any sample type (like multiple temperature readings tracks). You also need to define a startTime parameter, which is a time in the simulation after which the samples will be added. In some specific cases, you may want to use the offsetTime parameter to easily manipulate your samples’ timestamps.

Build complex testing scenarios with Antmicro

Renode provides you with a straightforward way to reliably test your hardware in advanced real-life scenarios. As a useful addition to your project’s development environment, it can increase the quality, speed, and reproducibility of your project’s testing process. If you need commercial support building complex test cases, reach out to Antmicro at contact@antmicro.com.