|
a draft is started based on the Getting Started with FP-AI-NANOEDG1 |
Condition monitoring is a major component of the predictive maintenance systems, allowing production performance improvement, maintenance cost reduction, and a drastic decrease of the downtime due to routine maintenance. The FP-AI-NANOEDG1 function pack helps to jump-start the implementation and development of condition monitoring applications designed with the NanoEdge™ AI Studio solution from Cartesiam (a member of the ST Partner program).
NanoEdge™ AI Studio simplifies the creation of autonomous Machine Learning libraries with the possibility of running not just inference but also training on the edge. It facilitates the integration of predictive maintenance capabilities as well as the security and detection with sensor patterns self-learning and self-understanding, exempting users from special skills in mathematics, Machine Learning, data science, or creation and training of Neural Network.
FP-AI-NANOEDG1 implements a wired interactive CLI to configure the node, record the data, and manage the learn and detect phases. For simple operation in the field, a standalone battery-operated mode allows basic controls through the user button, without using the console.
This article provides an overview of the following topics:
- Overview of the required hardware and software,
- Setting up the hardware and software components,
- Performing the vibration sensor data collection using the provided function pack,
- Generating, Installing, and testing the NanoEdge™ AI machine learning libraries on the sensor node STEVAL-STWINKT1B using the provided function pack, and
- Some links to useful online resources, which can help a user to better understand the project and then customize the project for his own needs.
For full user instructions of the FP-AI-NANOEDG1 V2.0 please refer to this article.
1. Hardware and software overview
1.1. SensorTile Wireless Industrial Node Evaluation Kit STEVAL-STWINKT1B
The STWIN SensorTile wireless industrial node (STEVAL-STWINKT1B) is a development kit and reference design that simplifies the prototyping and testing of advanced industrial IoT applications such as condition monitoring and predictive maintenance. It is powered with Ultra-low-power Arm® Cortex®-M4 MCU at 120 MHz with FPU, 2048 kbytes Flash memory (STM32L4R9). STWIN SensorTile is equipped with a microSD™ card slot for standalone data logging applications. STWIN SensorTile is equipped with a wide range of industrial IoT sensors including:
- an ultra-wide bandwidth (up to 6 kHz), low-noise, 3-axis digital vibration sensor (IIS3DWB)
- a 6-axis digital accelerometer and gyroscope iNEMO inertial measurement unit (IMU) with machine learning (ISM330DHCX)
and much more. Please refer to this link for all the sensors and features supported by STWIN. Other attractive features include:
- a Li-Po battery 480 mAh to enable standalone working mode
- STLINK-V3MINI debugger with programming cable to flash the board
- a Plastic box for ease of placing and planting the SensorTile on the machines for condition monitoring. For further details, the users are advised to visit this link
1.2. FP-AI-NANOEDG1 V2.0 Software Description
The STM32Cube function packs leverage the modularity and interoperability of STM32 Nucleo and expansion boards running STM32Cube MCU Packages and Expansion Packages to create functional examples representing some of the most common use cases in certain applications. The function packs are designed to fully exploit the underlying STM32 ODE hardware and software components to best satisfy the final user application requirements.
Function packs may include additional libraries and frameworks, not present in the original STM32Cube Expansion Packages, which enable new functions and create more targeted and usable systems for developers.
STM32Cube ecosystem includes:
- A set of user-friendly software development tools to cover project development from the conception to the realization, among which are:
- STM32CubeMX, a graphical software configuration tool that allows the automatic generation of C initialization code using graphical wizards
- STM32CubeIDE, an all-in-one development tool with peripheral configuration, code generation, code compilation, and debug features
- STM32CubeProgrammer (STM32CubeProg), a programming tool available in graphical and command-line versions
- STM32CubeMonitor (STM32CubeMonitor, STM32CubeMonPwr, STM32CubeMonRF, STM32CubeMonUCPD) powerful monitoring tools to fine-tune the behavior and performance of STM32 applications in real-time
- STM32Cube MCU & MPU Packages, comprehensive embedded-software platforms specific to each microcontroller and microprocessor series (such as STM32CubeL4 for the STM32L4+ Series), which include:
- STM32Cube hardware abstraction layer (HAL), ensuring maximized portability across the STM32 portfolio
- STM32Cube low-layer APIs, ensuring the best performance and footprints with a high degree of user control over the HW
- A consistent set of middleware components such as FreeRTOS™, USB Device, USB PD, FAT file system, Touch library, Trusted Firmware (TF-M), mbedTLS, Parson, and mbed-crypto
- All embedded software utilities with full sets of peripheral and applicative examples
- STM32Cube Expansion Packages, which contain embedded software components that complement the functionalities of the STM32Cube MCU & MPU Packages with:
- Middleware extensions and applicative layers
- Examples running on some specific STMicroelectronics development boards
To access and use the sensor expansion board, the application software uses:
- STM32Cube hardware abstraction layer (HAL): provides a simple, generic, and multi-instance set of generic and extension APIs (application programming interfaces) to interact with the upper layer applications, libraries, and stacks. It is directly based on a generic architecture and allows the layers that are built on it, such as the middleware layer, to implement their functions without requiring the specific hardware configuration for a given microcontroller unit (MCU). This structure improves library code reusability and guarantees easy portability across other devices.
- Board support package (BSP) layer: supports the peripherals on the STM32 Nucleo boards.
The top-level architecture of the FP-AI-NANOEDG1 V2.0 function pack is shown in the following figure.
2. Project setup with example application
2.1. HW prerequisites and setup
To use the FP-AI-NANOEDG1 V2.0 function pack on STEVAL-STWINKT1B, following hardware items are required:
- STEVAL-STWINKT1B development kit board,
- Windows® powered laptop/PC (Windows® 7, 8, or 10),
- A USB cable to connect the PC to the Micro-B USB connector (CN17) on the board,
- A microSD™ card for data logging,
2.2. Software requirements
2.2.1. FP-AI-NANOEDG1 V2.0
- Download the FP-AI-NANOEDG1 V2.0, package from ST website, extract and copy the .zip file contents into a folder on your PC. The package contains binaries and source code with project files for three IDEs (STM32CubeIDE, Keil, and IAR), for sensor board STEVAL-STWINKT1B.
2.2.2. An IDE
- One of the following IDEs must be installed:
- STMicroelectronics - STM32CubeIDE version 1.4.2
- IAR Embedded Workbench for Arm (EWARM) toolchain V8.50.5 or later
- RealView Microcontroller Development Kit (MDK-ARM) toolchain V5.31
2.2.3. STM32 ST-LINK Utility
- A software interface for programming STM32 microcontrollers. This software is only required to install the prepared binaries provided in the function pack folder at start. Note that this software will be used by not just users to install the already provided binaries but by STM32CubeIDE also to program the boards with the generated binaries.
- This software can be downloaded from STSW-LINK004.
2.2.4. Tera Term
- Tera Term is an open source and freely available software terminal emulator, which is used to host the CLI of the FP-AI-NANOEDG1 through serial connection.
- Users can download and install the latest version available from Tera Term.
2.2.5. NanoEdge AI Studio
The function pack is to be powered by Cartesiam. For this, the user needs to generate the libraries from the NanoEdge AI Studio and then embed these libraries in the FP-AI-NANOEDG1. The Studio can be downloaded from this link. Cartesiam provides a free evaluation version for the STMicroelectronics boards.
2.3. FP-AI-NANOEDG1 console application
FP-AI-NANOEDG1 V2.0 provides an interactive command-line interface (CLI) application. This CLI application equips a user with the ability to configure and control the sensor node, to log the vibration data using industrial-grade sensors onboard, which will be used to generate the Cartesiam NanoEdgeTM AI libraries, as well as to perform learning and (anomaly) detection operations of these AI libraries on the edge. The following sections provide a small guide on how a user can install this CLI application on a sensor board and control it through the CLI from a PC.
2.3.1. Get the function pack
The first step is to get the function pack. The FP-AI-NANOEDG1 V2.0 can be downloaded from ST website. Once the pack is downloaded, the user can unpack/unzip it and copy the contents to a folder on the PC. The steps of the process along with the contents of the folder are shown in the following image.
2.3.2. Installing the CLI application on the sensor board STEVAL-STWINKT1B
Once the package has been downloaded and unpacked, the next step is to program the sensor node with the binary of the function pack. For the convenience of the users, the function pack is equipped with a pre-built binary file of the project. The sensor board can be very easily programmed with the provided binary by simply performing a drag-and-drop action as shown in the figure below.
2.3.3. Use the command line interface (CLI)
Once the sensor board is programmed with the binary of the project, the next step is to set up the serial connection of the board with the PC through the Tera Term. To do so, start Tera Term and create a new connection by either selecting from the tool bar or by pressing Alt + N , select the proper connection to establish the serial communication with the board, for us in this case this is COM10 - USB Serial Device (COM 10) as shown in the figure below.
Set the parameters:
- Terminal
- [New line]:
- [Receive]: CR
- [Transmit]: CR
- [New line]:
- Serial
- The interactive console can be used with the default values.
Once the connection is made the user will see a message like below. If this message does not appear, the user can try to reset the board, to make this message appear.
Typing help will show the list of all available commands as presented in the table below.
| Command name | Command string | Note |
|---|---|---|
| CS1 - Generic Commands | ||
| help | help | Lists all registered commands with brief usage guidelines. Including the list of applicable parameters. |
| info | info | Shows firmware details and version. |
| uid | uid | Shows STM32 UID. |
| date_set | date_set <date&time> | Sets date and time of the MCU system. |
| date_get | date_get | Gets date and time of the MCU system. |
| reset | reset | Resets the MCU System. |
| start | start <"datalog", "neai_learn", or "neai_detect" > | Starts an execution phase according to its execution context, i.e. datalog, neai_learn or neai_detect. |
| stop | stop | Stops all running execution phases. |
| CS2 - PdM Specific Commands | ||
| neai_init | neai_init | (Re)initializes the AI model by forgetting any learning. Used in the beginning and / or to create a new NanoEdge AI model. |
| neai_set | neai_set <param> <val> | Sets a PdM specific parameters in an execution context. |
| neai_get | neai_get <param> | Displays the value of the parameters in the execution context. |
| neai_save | neai_save | Saves the current knowledge of the NanoEdge AI library in the flash and returns the start and destination address, as well as the size of the memory (in byte), used to save the knowledge. |
| neai_load | neai_load | Loads the saved knowledge of the NanoEdgeAI library from the flash memory. |
| CS3 - Sensor Configuration Commands | ||
| sensor_set | sensor_set <sensorID>.<subsensorID> <param> <val> | Sets the ‘value’ of a ‘parameter’ for a sensor with sensor id provided in ‘id’. |
| sensor_get | sensor_get <sensorID>.<subsensorID> <param> | Gets the ‘value’ of a ‘parameter’ for a sensor with sensor id provided in ‘id’. |
| sensor_info | sensor_info | Lists the type and ID of all supported sensors. |
| config_load | config_load | Loads the configuration parameters from the DeviceConfig.json and execution_config.json files in the root of the microSD™ card.
|
| CS4 - File System Commands | ||
| ls | ls | Lists the directory contents. |
| cd | cd <directory path> | Changes the current working directory to the provided directory path. |
| pwd | pwd | Prints the name/path of the present working directory. |
| cat | cat <file path> | Display the (text) contents of a file. |
3. Data collection
Once the user has verified that the binary has been programmed successfully and the serial connection is already setup to the sensor node, user can start the data logging. The following section provides a basic guide for performing the data log.
3.1. Configure the sensor for data logging
The STEVAL-STWINKT is equipped with industrial-grade sensors. The FP-AI-NANOEDG1 V2.0 provides the capability of configuring and logging the inertial data through a wide band low noise 3D vibrometer (IIS3DWB) which is capable of handling an output data rate of 26.6 kHz, and a 3D accelerometer + 3D Gyro iNEMO inertial measurement unit (ISM330DHCX) with machine learning core, through the CLI application. The CLI interface provides the user with the capability to not just log the data with the default configurations of the sensor but also equip the user with the capability to configure the sensors and subsensors. The configurable options for these sensors and subsenors include:
- Activate/deactivate the sensor or a sub-sensor,
- Set an output data rate (ODR) from the list of available options,
- Set full scale range from the list of available options.
These configurations can be performed using the commands provided in command set three (CS3) in the table above. The list of all the supported sensors and sub-sensors can be displayed on the CLI console by entering the command:
$ sensor_info
This command will show the supported sensors with their sensor and sub-sensor IDs. The detailed information of a given supported sensor or sub-sensor can be shown by typing command:
$ sensor_get <sensor_id.sub-sensor_Id> all
Similarly, the values for any of the available configurable parameters can be set through command
$ sensor_set <sensor_id.sub-sensor_Id> <param> <val>
3.2. Logging the data
Once the sensor is configured to the wished configuration values, the data logging can be started by simply entering the command
$ start datalog
in the CLI console. While the data logging is in progress, the green light on the STWIN will be blinking in order to show that the data log is in progress. Once the data is logged for the required time, the process can be stopped by either pressing the Esc button on the keyboard or by typing the command
$ stop
in the CLI console. With every successful data logging command, a new data acquisition folder will be created in the SD card with the name format STM32_DL_XXX. This folder will contain for every data log a DeviceConfig.json, an AcquisitionInfo.json file, and .dat files for all the active sensors. Note that for every sub sensor a separate .dat file is created, with naming convention sensor_name_SUBSENSORTYPE. For example for IIS3DWB, a file is created named as IIS3DWB_ACC.dat. The JSON files contain the information for sensor configurations and acquisition specific information such as device UUID.
4. Condition monitoring using NanoEdge AI Machine Learning library
This section provides complete method to set up an application for condition monitoring using FP-AI-NANOEDG1. The steps are provided with brief details in the diagram below.
The details on how to set up the sensor board with function pack as well as data collection have been already provided in the sections above. Following sections provide the details on library generation, installation, training and testing.
4.1. Generating a condition monitoring library
The AI libraries for the condition monitoring for this function pack are generated and provided by NanoEdge AI Studio, a solution provided by Cartesiam. This section provides a step-by-step guide on how to generate these condition monitoring libraries, installing them on the sensor node by linking them to the provided project in FP-AI-NANOEDG1 and then using them to perform the condition monitoring on the edge, by running first in training and then detection mode.
4.1.1. Data logging for normal and abnormal conditions
The library generation requires some sample data to be provided to the NanoEdge AI Studio. This data will provide the context of the set up to be monitored. The first step is to log the data for the normal and abnormal conditions using the data logging application provided in this function pack. Note that this data is to generate the libraries, so the users are advised to record data by exposing all the possible normal and any known abnormal conditions.
4.1.2. Data preparation for library generation with NanoEdge AI Studio
The data logged through the datalogger is in the binary format and is not user readable in its current condition. In order to convert this data to useful form, FP-AI-NANOEDG1 provides Python™ utility scripts. These scripts along with example usage can be found in a Parser_for_HS_Logged_Data.ipynb , a Python™ Jupyter™ Notebok, located on the path FP-AI-NANOEDG1/Utilities/AI-resources/DataLog/ as shown in the figure below.
The notebook provides all the flow for taking the normal and abnormal data acquisition folders and creating the NanoEdge AI studio compliant data files.
4.1.3. Library generation using NanoEdge AI Studio
The process of generating the libraries with Cartesiam NanoEdge AI studio consists of five steps.
- Hardware description
- Choosing a microcontroller type : Arm® Cortex®-M4
- Maximum amount of RAM to be allocated for the library: Usually a few Kbytes will suffice (but it depends on the data frame length used in the process of data preparation, you can start with 32 Kbytes).
- Sensor type : 3-axis accelerometer
- Providing the sample contextual data to adjust and gauge the performance of the chosen model. This step will require data for:
- Nominal or normal case
- Abnormal case
- Benchmarking of available models and choose the one that complies with the requirements.
- Validating the model for learning and testing through the provided emulator which emulates the behavior of the library on the edge.
- The final step is to compile and download the libraries. In this process, the flag
"-mfloat-abi"has to becheckedfor using libraries with hardware FPU. All the other flags can be left to the default state.
Detailed documentation on the NanoEdge AI Studio.
4.2. Installing the NanoEdgeAI Machine Learning library
Once the libraries are generated and downloaded from Cartesiam NanoEdge AI Studio, the next step is to incorporate these libraries to FP-AI-NANOEDG1. The FP-AI-NANOEDG1, comes with the library stubs in the place of the actual libraries generated by NanoEdge AI Studio. This is done to make it easy for users to link the generated libraries and have a place holder for the libraries, which are generated by following the steps provided in the previous section. In order to link the actual libraries, the user needs to copy the generated libraries and replace the existing stub/dummy libraries and header files NanoEdgeAI.h, and libneai.a files present in the folders Inc, and lib, respectively. The relative paths of these folders are /FP_AI_NANOEDG1_V2.0/Middlewares/Third_Party/Cartesiam_NanoEdge_AI_Library/ as shown in the figure below.
Once these files copied, the project must be reconstructed and programmed on the sensor board in order to link the libraries. For this, the user needs to open the .project file from the FP-AI-NANOEDG1 folder, located at the path /FP_AI_NANOEDG1_V2.0/Projects/STM32L4R9ZI-STWIN/Applications/NanoEdgeConcole/STM32CubeIDE/ as shown in the step 2 in figure below.
To install the new firmware after linking the library, connect the sensor board, and rebuild the project using the play button. See the console for the outputs and wait for the Build and Download success message as shown in step 4 in the figure below.
Once the sensor-board is programmed successfully, the following welcome message will appear in the CLI (Tera Term terminal). If the message does not appear you can try to reset the board by pressing RESET button.
4.3. Testing the NanoEdgeAI Machine Learning library
Once the STWIN is programmed with the FW with a valid library, the condition monitoring libraries are ready to be tested on the sensor board.
Note, that although the library generation process shows some performance metrics in the NanoEdge AI Studio, in their initial form, the libraries have zero knowledge of the normal and abnormal conditions, and to perform the condition monitoring effectively, it is important to learn the normal behavior of the setup/machine that is required to be monitored. This can be achieved by starting the learning process.
The learning phase can be started by simply issuing a command start neai_learn in the CLI console. Starting this command will show the process of learning and will show a message on the console every time learning is performed on a new signal, as shown in the below snippet.
$$ start neai_learn
NanoEdgeAI: starting
$ {"signal": 1, "status": success}
{"signal": 2, "status": success}
{"signal": 3, "status": success}
{"signal": 4, "status": success}
{"signal": 5, "status": success}
{"signal": 6, "status": success}
{"signal": 7, "status": success}
{"signal": 8, "status": success}
{"signal": 9, "status": success}
The process can be stopped either by issuing the
$ stop
command or by simply pressing the ESC key on the keyboard.
The learning can also be started by performing a long-press of the user button. Once the learning is happening, pressing the user button again will stop the learning process.
Once the normal conditions are learnt, the user can start the condition monitoring process by starting the neai_detect mode. This mode can be started by issuing the command
$ start neai_detect NanoEdgeAI: starting
or by short pressing the user button on the sensor board. If the similarity of the current signal will be less than the threshold, the similarity will be printed on the CLI console showing the signal is an anomaly as shown in the snippet below. Nothing will be printed in the CLI console if the similarity is higher than 90% to the normal signals. Other than this the orange LED will blink fast (alternating 200 msec on-off sequence) to show the anomaly is detected.
4.3.1. Some hyper-parameters in condition monitoring
For the convenience of the users, the CLI application also provides some handy options to fine-tune the inference and learning process of the condition monitoring easily. Users can see all the variables they can play with by issuing the following command:
$ neai_get all NanoEdgeAI: signals = 0 NanoEdgeAI: sensitivity = 1.000000 NanoEdgeAI: threshold = 95 NanoEdgeAI: timer = 0
Each of the these parameters can be configured using neai_set <param> <val> command. The details are provided in the command table above.
This section provides small details on neai_set signals <nr of signals> . Using this command, a user can start the learning or condition monitoring mode for a given number of samples. For example, to learn on 100 signals, the user can issue this command, before issuing the learn command. In the following snippet, an example is presented where the learning is performed for 10 signals.
$ neai_set signals 10
NanoEdge AI: signals set to 10
$ start neai_learn
NanoEdgeAI: starting
$ {"signal": 1, "status": success}
{"signal": 2, "status": success}
{"signal": 3, "status": success}
{"signal": 4, "status": success}
{"signal": 5, "status": success}
{"signal": 6, "status": success}
{"signal": 7, "status": success}
{"signal": 8, "status": success}
{"signal": 9, "status": success}
{"signal": 10, "status": success}
NanoEdge AI: stopped
The threshold parameter is used to report the anomalies. For any signal which has similarities below the threshold value is reported as anomaly. The default value used in the CLI application is 90. Users can change this value by using neai_set threshold <val> command.
The sensitivity parameter is used as an emphasis parameter. The default value is set to 1. Increasing this sensitivity will mean that the matching of the signals is to be performed more strictly, reducing it will also reduce the matching calculation process, i.e. resulting in higher matching values.
For details, users are invited to read the detailed documentation of NanoEdge AI studio.
5. Autonomous and button-operated modes
In addition to the normal functioning as provided in the sections above, the FP-AI-NANOEDG1 V2.0 also comes equipped with an extended autonomous and button-operated mode. The purpose of the extended mode is to enable the users to operate the FP-AI-NANOEDG1 V2.0 on STWIN even in the absence of the CLI console.
All the (default) values required for running different execution phases (datalog, learn, and detect) are provided in the FW. Based on these configurations different modes (learn, detect, and datalog) can be started and stopped through the user-button on the node. In addition to this that users can change these settings, by providing the configurations in the form of JSON files onto the microSD™ card, and the values in these configuration files will override the default values provided in the FW.
Other than this button-operated mode, the autonomous mode is also equipped with a special mode, called “auto mode”. The auto-mode can be initiated automatically, at the device power-up stage or whenever a reset is performed. In this mode, the user can choose to have one or even a chain of modes/commands (up to ten commands) to run in a sequence as a list of execution steps. For example, these commands could be learning the nominal mode for a given duration and then start the detection mode for anomaly detection. Other than this, this mode can also be used to start the datalog operations or even to pause all the executions for a specific period of time by putting the sensor node in the "idle" phase.
The following sections provide brief details on different blocks of these extended autonomous modes.
5.1. Interaction with user
As mentioned before, the auto-mode can work even when no connectivity (wired or wireless) available, although it also works as a button-operated mode when the console is available and is fully compatible and consistent with the current definition of the serial console and its Command Line Interface (CLI). The supporting hardware for this version of the function-pack (STWIN) is fitted with three buttons:
- User Button, the only SW usable,
- Reset Button, connected to STM32 MCU reset pin,
- Power Button connected to power management,
and three LEDs:
- LED_1 (green), controlled by Software,
- LED_2 (orange), controlled by Software,
- LED_C (red), controlled by Hardware, indicates charging status when powered through a USB cable.
So, the basic user interaction for button-operated operations is to be done through two buttons (user and reset) and two LEDs (Green and Orange). Following we provide details on how these resources are allocated to show the users what execution phases are active or to report the status of the sensor-node.
5.1.1. LED Allocation
In the function pack four execution phases exist:
- idle: the system waits for a specified amount of time.
- datalog: sensor(s) output data are streamed onto an SD card.
- learn: all data coming from the sensor(s) are passed to the NanoEdge AI library to train the model.
- detect: all data coming from the sensor(s) are passed to the NanoEdge AI library to detect anomalies.
At any given time, the user needs to be aware of the current active execution phase. We also need to report the outcome of the detection when the detect execution phase is active, telling the user if an anomaly has been detected. In addition, if a fatal error occurs and consequently the FW has stopped, the user needs to be notified, either to debug or to reset the node.
In total, we need the interaction mechanism to code six different states with the two available LEDs, so we need at least three patterns in addition to the traditional On-OFF options. At any given time the LED can be in one of the following states:
| Pattern | Description |
|---|---|
| OFF | the LED is always OFF |
| ON | the LED is always ON |
| BLINK | the LED alternates ON and OFF periods of equal duration (400 ms) |
| BLINK_SHORT | the LED alternates short (200 ms) ON periods with a short OFF period (200 ms) |
| BLINK_LONG | the LED alternates long (800 ms) ON periods with a long OFF period (800 ms) |
These patterns of each of the LEDs indicate the state of the sensor-node. Following table describes the state of the sensor-node for any of the patterns:
| Pattern | Green | Orange |
|---|---|---|
| OFF | Power OFF | |
| ON | idle | System error |
| BLINK | Data logging | MicroSD™ card missing |
| BLINK_SHORT | Detecting, no anomaly | Anomaly detected |
| BLINK_LONG | Learning, status OK | Learning, status FAILED |
5.1.2. Button Allocation
In the extended autonomous mode, the user can trigger any of the four execution phases or a special mode called the auto mode. The available modes are:
- idle: the system waits for a specified amount of time.
- datalog: sensor(s) output data is streamed onto an SD card.
- learn: all data coming from the sensor are passed to the NanoEdge AI library to train the model.
- detect: all data coming from the sensor are passed to the NanoEdge AI library to detect anomalies.
- auto mode: a succession of predefined execution phases.
For triggering these phases the FP-AI-NANOEDG1 V2.0 is equipped with the support of the user button. In the STEVAL-STWINKT1B sensor-node, there are two software usable buttons:
- The user button: This button is fully programmable and is under the control of the application developer.
- The reset button: This button is used to reset the sensor-node and is connected to the hardware reset pin, thus is used to control the software reset.
In order to control the executions phases, we need to define and detect at least three different button press modes of the user button. The reset button is used to trigger the auto-mode at the reset or power-up mode(if configured through execution_config.json file).
Following are the types of the press available for the user button:
| Button Press | Description |
|---|---|
| SHORT_PRESS | The button is pressed for less than (200 ms) and released |
| LONG_PRESS | The button is pressed for more than (200 ms) and released |
| DOUBLE_PRESS | A succession of two SHORT_PRESS in less than (500 ms) |
| ANY_PRESS | The button is pressed and released (overlaps with the three other modes) |
In the table below a mapping for this different kind of button press patterns is provided:
| Current Phase | Action | Next Phase |
|---|---|---|
| Idle | SHORT_PRESS | detect |
| LONG_PRESS | learn | |
| DOUBLE_PRESS | datalog | |
| RESET | auto-mode if configured or idle | |
| learn, detect or datalog or auto-mode | ANY_PRESS | idle |
| RESET | auto-mode if configured or idle. |
5.2. Configuration
When the sensor-node is being operated from the interactive console, the users can configure the parameters of the sensors on the node as well as the parameters of different execution phases. In the absence of the console, the user can either use the default values for these parameters provided in the firmware, or FP-AI-NANOEDG1 V2.0 also provides the users with the capability of override the default parameters through the configuration files. The json configuration files are to be placed in the root path of the microSD™ card. There are two configuration files that are used for this purpose. These configuration files are
- DeviceConfig.json : This configuration file contains the configuration parameters for sensors, such as the
fullScale,activeStatus, andODR(output data rate) of the sensors, andenablestatus. - execution_config.json: This configuration file contains the information about the executions phases when the sensor node is being operated in the autonomous mode, such that
timer(time to run an execution phase),signals(number of signals to be used in the learn or detect phases) and many more.
- DeviceConfig.json : This configuration file contains the configuration parameters for sensors, such as the
The following sections provide brief details along with simple example files for these two.
5.2.1. execution_config.json
execution_config.json is used to configure any execution context and phases as well as it provides the auto-mode activation at reset and its definition.
Here is the definition of different parameters that can be configured in this file:
- info: gives the definition of auto-mode as well as each execution context, any field present overrides the FW defaults.
- version: is the revision of the specification.
- auto_mode: if true, auto mode will start after reset and node initialization.
- execution_plan: is the sequence of maximum ten execution steps.
- start_delay_ms: indicates the initial delay in milliseconds applied after reset and before the first execution phase starts when auto mode is selected.
- phases_iteration: gives the number of times the execution_plan is executed, zero indicates an infinite loop.
- phase steps execution context settings.
- learn:
- - timer_ms: specifies the duration in ms of the execution phase. Zero indicates an infinite time.
- - signals: specifies the number of signals to be analyzed. Zero indicates an infinite value for signals.
- detect:
- - timer_ms: specifies the duration in ms of the execution phase. Zero indicates an infinite time.
- - signals: specifies the number of signals to be analyzed. Zero indicates an infinite value for signals.
- - threshold: specifies a value used to identify a signal as normal or abnormal.
- - sensitivity: specifies the sensitivity value for the NanoEdge AI library.
- datalog:
- - timer_ms: specifies the duration in ms of the execution phase. Zero indicates an infinite time.
- idle:
- - timer_ms: specifies the duration in ms of the execution phase. Zero indicates an infinite time.
- learn:
- info: gives the definition of auto-mode as well as each execution context, any field present overrides the FW defaults.
5.2.1.1. default example
If no microSD™ card is preset, or If no valid file on the root of the file system of the microSD™ card can be found, then all the FW defaults are applied. The default configuration for the auto mode is equivalent to the following execution_config.json example file:
{
"info": {
"version": "1.0",
"auto_mode": false,
"phases_iteration": 0,
"start_delay_ms": 0,
"execution_plan": [
"idle"
],
"learn": {
"signals": 0,
"timer_ms": 0
},
"detect": {
"signals": 0,
"timer_ms": 0,
"threshold": 90,
"sensitivity": 1.0
},
"datalog": {
"timer_ms": 0
},
"idle": {
"timer_ms": 1000
}
}
}
5.2.2. DeviceConfig.json
The DeviceConfig.json file contains the parameters for the sensor-node and sensor-configurations. These parameters include:
- UUIDAcquisition: Unique identifier of acquisition (control and data files in folder)
- JSONVersion: version of current DeviceConfig.json file.
- Device: Datalogging HW and FW setup for current Acquisition
- deviceInfo: Board-level info
- Sensor: an array of sensors, each containing parameters, and configurations for a given sensor. Here following are the sample configuration parameters for a sample sensor:
- id: identifier of the sensor
- name: name or part number of the sensor
- sensorDescriptor: description of the sensor parameters
- subSensorDescriptor: an array of all sub-sensors in the sensor containing the configurations for each of the sub-sensors. Each element of the array contains the following parameters:
- id : identifier for the sub-sensor
- sensorType: type of the subsensor, for example
"ACC"for accelerometer - dimensions: number of dimensions of the data produced by the subsensor
- dimensionsLabel: a string array of
length = dimensionscontaining the labels of each sensor - unit : unit of the measure for the sensor
- dataType : type of the output sensor produce
- FS : an array of values available to be used as fullscale. This value controls the sensitivity of the sensor to measure small changes
- ODR : an array of the values that can be used as the output data sampling rates\
- samplesPerTs : minimum and maximum value of the samples before inserting a new time stamp. This option is used in the case of a time-stamped data acquisition is required. :*:*:* sensorStatus : the current or used values for the sensor and sub-sensor parameters
- subSensorStatus : an array for the parameter values for all the sub-sensors, each element contains:
- ODR : the set output data rate for the subsensor
- ODRMeasured: the current data rate with which the data is recorded, (this can differ from the requested data rate by +-10%)
- initialOffset : offset in the sensor values
- FS : value of the full scale used in the data acquisition
- sensitivity: sensitivity of the sensor
- isActive: a boolean to tell if the sub-sensor was active or not during the acquisition
- samplesPerTs: after how many samples a new timestamp is added
- tagConfig: data tagging labels configuration for current acquisition. This information is used for tagging the data during the data logging. The tags to the data acquisitions can be added using soft or hard tagging. But as the data tagging is out of the scope of this wiki more details are not provided. The interested readers are invited to visit the HSDatalog page for more details.
More detailed information on these files as well as the other files in the data acquisition folders can be found here.
5.2.2.1. Sample DeviceConfig.json file
If no microSD™ card is preset, or If no valid file on the root of the file system of the microSD™ card can be found with the device configurations, then all the FW default values are applied. By default only the vibrometer (id: 0.0) is active and all other sub-sensors are inactive. The configurations for the vibrometer are as follow:
- - isActive: true
- - ODR: 26667 Hz
- - Full Scale: 16 g
These default configurations are equivalent to the following DeviceConfig.json example file:
{
"UUIDAcquisition": "0fef93bf-7a52-4af3-a44d-b3a05ca571a6",
"JSONVersion": "1.0.0",
"device": {
"deviceInfo": {
"serialNumber": "000F000B374E50132030364B",
"alias": "STWIN_001",
"partNumber": "STEVAL-STWINKT1",
"URL": "www.st.com\/stwin",
"fwName": "FP-AI-NANOEDG1",
"fwVersion": "2.0.0",
"dataFileExt": ".dat",
"dataFileFormat": "HSD_1.0.0",
"nSensor": 2
},
"sensor": [
{
"id": 0,
"name": "IIS3DWB",
"sensorDescriptor": {
"subSensorDescriptor": [
{
"id": 0,
"sensorType": "ACC",
"dimensions": 3,
"dimensionsLabel": [
"x",
"y",
"z"
],
"unit": "g",
"dataType": "int16_t",
"FS": [
2,
4,
8,
16
],
"ODR": [
26667
],
"samplesPerTs": {
"min": 0,
"max": 1000,
"dataType": "int16_t"
}
}
]
},
"sensorStatus": {
"subSensorStatus": [
{
"ODR": 26667,
"ODRMeasured": 26667,
"initialOffset": 0.307801,
"FS": 16,
"sensitivity": 0.488,
"isActive": true,
"samplesPerTs": 1000,
"usbDataPacketSize": 3000,
"sdWriteBufferSize": 32768,
"wifiDataPacketSize": 0,
"comChannelNumber": -1
}
]
}
},
{
"id": 1,
"name": "ISM330DHCX",
"sensorDescriptor": {
"subSensorDescriptor": [
{
"id": 0,
"sensorType": "ACC",
"dimensions": 3,
"dimensionsLabel": [
"x",
"y",
"z"
],
"unit": "g",
"dataType": "int16_t",
"FS": [
2,
4,
8,
16
],
"ODR": [
12.5,
26,
52,
104,
208,
417,
833,
1667,
3333,
6667
],
"samplesPerTs": {
"min": 0,
"max": 1000,
"dataType": "int16_t"
}
},
{
"id": 1,
"sensorType": "GYRO",
"dimensions": 3,
"dimensionsLabel": [
"x",
"y",
"z"
],
"unit": "mdps",
"dataType": "int16_t",
"FS": [
125,
250,
500,
1000,
2000,
4000
],
"ODR": [
12.5,
26,
52,
104,
208,
417,
833,
1667,
3333,
6667
],
"samplesPerTs": {
"min": 0,
"max": 1000,
"dataType": "int16_t"
}
},
{
"id": 2,
"sensorType": "MLC",
"dimensions": 1,
"dimensionsLabel": [
"MLC"
],
"unit": "mdps",
"dataType": "int8_t",
"FS": [],
"ODR": [
12.5,
26,
52,
104
],
"samplesPerTs": {
"min": 0,
"max": 1000,
"dataType": "int16_t"
}
}
]
},
"sensorStatus": {
"subSensorStatus": [
{
"ODR": 6667,
"ODRMeasured": 0,
"initialOffset": 0,
"FS": 16,
"sensitivity": 0.488,
"isActive": false,
"samplesPerTs": 1000,
"usbDataPacketSize": 2048,
"sdWriteBufferSize": 16384,
"wifiDataPacketSize": 0,
"comChannelNumber": -1
},
{
"ODR": 6667,
"ODRMeasured": 0,
"initialOffset": 0,
"FS": 4000,
"sensitivity": 140,
"isActive": false,
"samplesPerTs": 1000,
"usbDataPacketSize": 2048,
"sdWriteBufferSize": 16384,
"wifiDataPacketSize": 0,
"comChannelNumber": -1
},
{
"ODR": 0,
"ODRMeasured": 0,
"initialOffset": 0,
"FS": 0,
"sensitivity": 1,
"isActive": false,
"samplesPerTs": 1,
"usbDataPacketSize": 9,
"sdWriteBufferSize": 1024,
"wifiDataPacketSize": 0,
"comChannelNumber": -1
}
]
}
}
],
"tagConfig": {
"maxTagsPerAcq": 100,
"swTags": [
{
"id": 0,
"label": "SW_TAG_0"
},
{
"id": 1,
"label": "SW_TAG_1"
},
{
"id": 2,
"label": "SW_TAG_2"
},
{
"id": 3,
"label": "SW_TAG_3"
},
{
"id": 4,
"label": "SW_TAG_4"
}
],
"hwTags": [
{
"id": 5,
"pinDesc": "",
"label": "HW_TAG_0",
"enabled": false
},
{
"id": 6,
"pinDesc": "",
"label": "HW_TAG_1",
"enabled": false
},
{
"id": 7,
"pinDesc": "",
"label": "HW_TAG_2",
"enabled": false
},
{
"id": 8,
"pinDesc": "",
"label": "HW_TAG_3",
"enabled": false
},
{
"id": 9,
"pinDesc": "",
"label": "HW_TAG_4",
"enabled": false
}
]
}
}
}
- FP-AI-NANOEDG1
- DB4196: Artificial Intelligence (AI) condition monitoring function pack for STM32Cube
- User Manual : User Manual for FP-AI-NANOEDG1 V2.0
- Wiki: How to perform condition monitoring on STM32 using FP-AI-NANOEDG1
- Getting Started with FP-AI-NANOEDG1: Getting Started with FP-AI-NANOEDG1 V1.0, at STM32L562E-DK
- STEVAL-STWINKT1B
