Remote Vibration Monitoring of Combustion Engines Utilising Edge Computing

Abstract

This paper presents a remote vibration monitoring system for combustion engines, utilising edge computing technology. The proposed solution aims to enhance real-time data processing and reduce latency by performing computations closer to the data source. The system integrates vibration sensor, edge computing units, and potentially cloud-based analytics to provide continuous monitoring and early fault detection. The research discusses the architecture, data acquisition process, and implementation challenges. The experimental results show that analysing the values of specific vibration signal measures can be effective in identifying engine anomalies. The results suggest that edge processing can significantly contribute to the reliability of vibration monitoring in similar applications.

1. Introduction

The ability to measure, monitor, and analyse vibration levels is a key task of many devices and systems, especially in industrial solutions and $R\&D$ projects. Vibration is typically a low-amplitude oscillation with frequencies up to several tens of Hz. The measurement of vibrations is used for diagnostic purposes, such as assessing the condition of a machine in operation or the stability of structures subjected to heavy loads. The signal acquired during measurements can be a combination of vibration and acoustic signals (called vibroacoustic signals), which are produced by mechanical vibrations of various objects. This broad term encompasses structural vibrations and sound waves propagating through air or other media. Vibroacoustic signals require different methods of analysis. There is no single, always effective algorithm, as there is no universal place to make measurements, independent of the construction and operation of the object studied. When conducting analyses, the focus is on specific signal measures correlated with the phenomenon under investigation. The number of analysis methods used will depend on the particular situation. In simple diagnostic cases, determining a single measure whose changes reflect the intensity of the phenomenon studied may be sufficient. However, it often turns out that it is necessary to find several different measures and look for relationships between their values and changes in the context of the device state. Vibration signals are typically recorded using acceleration transducers, also known as accelerometers or vibrometers [1,2,3]. In contrast, acoustic signals are recorded using microphones [4,5]. The vibration signal is more useful in most cases [6]. This point of view is supported by the practical challenge of fully isolating the acoustic signal from other signals not caused by the operation of the device under test, which is a common occurrence. Signal processing for determining the technical condition of a machine is not an easy task for any slightly more complex object. Different forms of damage can result in alterations in the time signal waveform.

A review of the existing literature reveals many approaches to vibration analysis and vehicle diagnostics. In most cases, the main measurement element is an accelerometer. It is widely acknowledged that vibration signals contain significant diagnostic information concerning the dynamics of internal combustion or diesel engines. Thus, such signals play a crucial role in the precise diagnosis of particular engine failures [7]. The paper [8] presents a method based on neural networks and frequency analysis, while [9] details a technique that employs recurrent neural networks. The article [10] discusses the application of Principal Component Analysis (PCA) to the analysis of the vibration of an automotive engine for fault detection. The method reduces the data dimensionality and identifies patterns indicative of potential failures. The paper [11] presents vibration distribution measurements of car doors and engine head using the OPPA (One-Pitch Phase Analysis Method) Vibration Distribution Analyser. This method allows for a detailed assessment of the dynamics of the structure, enabling the identification of potential noise and vibration sources. The study of vibrations in a passenger vehicle and the possible impact on the driver’s body in the process of natural operation is the subject of the article [12]. Vibration analysis and its connection to the diagnosis of so-called ignition misfire are extensively discussed in [13,14,15] and the literature cited therein. A comparison of several types of sensors that analyse vibrations located at different points in the car can be found in the paper [16].

In recent years, applications of edge computing technology or machine learning have become increasingly evident in the field of industrial diagnostics [17,18,19,20]. This technology allows data to be processed directly on network edge devices, enabling rapid analysis and the real-time detection of anomalies. The technology has other applications in the vibration monitoring context of engines in combustion engine vehicles. The article [21] presents predictive data analysis and real-time vehicle condition monitoring. The categorisation of vehicle condition, namely as good, critical, moderate, or less serious, is addressed in [22]. In contrast, the article [23] discusses an approach to vibration analysis using neural networks that can be applied to different scenarios, including vehicle engine condition monitoring.

2. Materials and Methods

This chapter describes the methodology for selecting an accelerometer for the target vibration monitoring system. It presents the basic signal measures used to analyse signals in the time domain.

2.1. Analysis of the Use of Selected Types of MEMS Accelerometers

Before developing the target measurement system, a preliminary choice of several available MEMS (Micro-ElectroMechanical System) accelerometers was made. The sensor selection was guided by their parameters, the integration into the measurement system, and the price at this stage. Taking these conditions into account, the following accelerometers were checked: MMA7361LC [24], ADXL335 [25], MPU-6050 [26], and ADXL345 [27]. The basic parameters of the accelerometers considered are given in

Table 1. Selected parameters of the tested accelerometers.

Sensor	Acceleration Range [g]	Bandwidth [Hz]	Resolution [bit]	Output Interface
MMA7361LC	±1.5; ±6	400 (X, Y); 300 (Z)	n/a	Analogue
ADXL335	±3	1600 (X, Y); 500 (Z)	10	Analog
MPU-6050	±2; ±4; ±8; ±16	n/a	16	Digital ($I^{2}C$/$SPI$)
ADXL345	±2; ±4; ±8; ±16	6.25–3200	10–13	Digital ($I^{2}C$/$SPI$)

.

The value of the resulting acceleration g was determined using the following formulas (the X axis was used to illustrate the concept):

• MMA7361LC

  $$A_X={\displaystyle \frac{\frac{AD{C}_{val}·V_{ref}}{AD{C}_{res}}-U_{0g}}{SSF}}={\displaystyle \frac{\frac{AD{C}_{val}·5}{16384}-1.65}{0.206}}(SSF=206\mathrm{mV}for\pm 6\mathrm{g}range),$$

  (1)
• ADXL335

  $$A_X={\displaystyle \frac{\frac{AD{C}_{val}·V_{ref}}{AD{C}_{res}}-U_{0g}}{SSF}}={\displaystyle \frac{\frac{AD{C}_{val}·5}{16384}-1.65}{0.330}}(SSF=330\mathrm{mV}),$$

  (2)
• MPU-6050 and ADXL345

  $$A_X={\displaystyle \frac{X_{rd}}{SSF}}.$$

  (3)

In Formulas (1) and (2), the parameter $AD{C}_{val}$ is the value measured by the ADC (Analog to Digital Converter) converter, $V_{ref}$ is the voltage reference of the ADC (5 V), $AD{C}_{res}$ is the resolution of the ADC (for 14-bit resolution, we have 10¹⁴ = 16,384), $U_{0g}$ is the maximum voltage level at 0 g, and $SSF$ denotes Sensitivity Scale Factor expressed as the voltage per 1 g (mV/g). The parameter $X_{rd}$ in Formula (3) means the raw data read from the relevant registers for the given axis, and the parameter $SSF$ is related to the measurement range. In the case of the MPU-6050 for ±2 g, ±4 g, ±8 g, or ±16 g, we have the following sensitivity scale factors: 2048, 4093, 8192, and 16,384, where the unit is LSB/g. However, for ADXL345, which has the same measurement ranges, the coefficients are 256, 128, 64, and 32. In the case of digital sensors, the parameters listed in Table 1 are selected by the software. The acceleration level calculations for the analogue accelerometers were performed using an AVR microcontroller (ATmega88, Microchip, Bialystok, Poland) and its internal ADC, operating at maximal resolution. The 14-bit resolution was achieved through oversampling [28]. This technique increases the $SNR$ (Signal-to-Noise Ratio), making the measurement more stable.

The test stand shown in Figure 1 was used to test the reproduction precision of the sinusoidal signal applied to the exciter. The analysis was performed for the following signal frequencies: 10 Hz, 20 Hz, 30 Hz, 40 Hz, and 50 Hz. The peak-to-peak voltages ($U_{P-P}$) 200 mV, 400 mV, 600 mV, 800 mV, and 1000 mV were set for each frequency listed.

The generator ➂ produces a preset test signal, which is amplified by the amplifier ➁. This stimulates the exciter ➀ on which the accelerometers to be tested are mounted. The generator signal and the accelerometer signal ➄ are recorded using an oscilloscope ➃. The precision of the calculation g described previously was verified using a certified vibration meter ➅. The sample oscillograms recorded during the testing are shown in Figure 2.

The observed phase shifts are attributed to the following: the MEMS accelerometers used in the system include analogue devices with external RC low-pass filters (e.g., ADXL335 and MMA7361LC), as well as digital devices with integrated digital filtering (e.g., ADXL345 and MPU-6050). Filters are an essential part of the signal processing chain, and each introduces a phase shift (or delay). The accelerometer’s response is affected by the time constant of the corresponding filter. For analogue devices, the phase shift can be described by the equation $\varphi \left(\omega \right)=-\mathrm{arrctg}\left(\omega /{\omega }_c\right)$, where ${\omega }_c$ is the angular frequency of the signal and RC is the time constant. For digital devices, the relevant parameter is the group delay, which is typically specified in the component’s datasheet or application notes. In the case of ADXL345, group delay is not explicitly documented, but it is known to depend on the Output Data Rate (ODR) and the frequency of the input signal. The phase shift in such cases can be approximated by using the relation $\varphi \left(\omega \right)\approx -\omega {\tau }_g$, where ${\tau }_g$ (ms) is the group delay. For the MPU-6050, group delay values are specified and vary based on the selected low-pass filter configuration. The measurements presented in the oscillogram were obtained with a bandwidth setting of 94 Hz.

During testing, it was observed that the accuracy of the acceleration measurement improves with increasing signal frequency and amplitude. This issue was evident in accelerometers tested at lower frequencies (below 20 Hz) and peak-to-peak voltages up to 200 mV. This behaviour can be attributed to the internal structure of MEMS sensors, which are known to exhibit 1/f noise, most prominent at low frequencies and small accelerations (i.e., low excitation amplitudes). This phenomenon is illustrated in Figure 3.

In this experiment, the AVR microcontroller was also used to process signals from digital accelerometers (MPU-6050, ADXL345) communicating via the $I^{2}C$ serial interface. In addition, the MCP4725 chip was used as an external digital-to-analogue converter (DAC) to record the processed signal with an oscilloscope. The wiring diagram is shown in Figure 4. The direction of the data flow is indicated by the dashed lines.

The MPU-6050 digital sensor was selected for the target measurement system. It is also important to consider the measurement range and mounting aspect of the accelerometer. Because the accelerometer is mounted on the engine, a running alternator has the potential to cause interference, affecting the voltage signal from the analogue sensors. The MPU-6050 combines a 3-axis accelerometer, a gyroscope, and a digital thermometer. Its various applications can be found, for example, in the works [29,30,31,32]. A key feature of this sensor is the built-in hardware Digital Motion Processor (DMP), which facilitates the conversion of processed data from all three sensors to a specific position relative to Earth, thus allowing the microcontroller to perform this task [26]. The simplified internal structure of the MPU-6050 is shown in Figure 5.

The 16-bit integrated ADCs enable simultaneous sampling of every axis, eliminating the need for an external multiplexer. The accelerometer uses separate masses, meaning that acceleration along a given axis induces a displacement on a given mass, which is then differentially detected by capacitive sensors. According to the data sheet, the system is resistant to thermal drift.

2.2. Time-Domain Analysis of Vibration Signals

The vibrations and oscillations, appearing during the equipment operation, are often used as a source of information on the technical condition of the equipment. The signals acquired during measurements require a range of analytical methodologies. In conducting such analyses, the objective is to identify signal measures that correlate sufficiently with the phenomenon under investigation. The number of analysis methods used is contingent on the specific circumstances of each case. In simple diagnostic cases, it may be sufficient to determine a single measure (indicator), the changes of which reflect the intensity of the studied phenomenon. However, more complex cases generally require the determination of multiple indicators and the investigation of the relationship between their values and the device state. The following measures can be determined from the signals recorded in the time domain [33,34,35,36,37]:

• Average value $\overline{x}$:

  $$\overline{x}={\displaystyle \frac{1}{T}}{\int }_0^{T}x\left(t\right)dt,$$

  (4)

  where $x\left(t\right)$—signal analysed; T—time for which we calculate the value of the signal;
• Peak value $X_P$:

  $$X_P=\underset{0<t\le T}{max}\left(\left|x\left(t\right)\right|\right),$$

  (5)
• Peak-to-peak value $X_{P-P}$:

  $$X_{P-P}=\left|\underset{0<t\le T}{max}x\left(t\right)-\underset{0<t\le T}{min}x\left(t\right)\right|,$$

  (6)
• Root mean square (RMS) value $X_{RMS}$:

  $$X_{RMS}=\sqrt{{\displaystyle \frac{1}{T}}{\int }_0^T{x}^2\left(t\right)dt},$$

  (7)
• Variance $\upsilon$:

  $$\upsilon ={\displaystyle \frac{1}{T}}{\int }_0^T{\left[x\left(t\right)-\overline{x}\right]}^{2}dt,$$

  (8)
• Standard deviation $\sigma$:

  $$\sigma =\sqrt{{\displaystyle \frac{1}{T}}{\int }_0^T{\left[x\left(t\right)-\overline{x}\right]}^{2}dt},$$

  (9)
• Skewness S:

  $$S={\displaystyle \frac{\frac{1}{T}{\int }_0^T{[x\left(t\right)-\overline{x}]}^3}{{\left[\frac{1}{T}{\int }_0^T{[x\left(t\right)-\overline{x}]}^{2}dt\right]}^{\frac{3}{2}}}}dt,$$

  (10)
• Kurtosis K:

  $$K={\displaystyle \frac{\frac{1}{T}{\int }_0^T{[x\left(t\right)-\overline{x}]}^{4}dt}{{\left[\frac{1}{T}{\int }_0^T{[x\left(t\right)-\overline{x}]}^{2}dt\right]}^2}},$$

  (11)
• Form factor $SF$:

  $$SF={\displaystyle \frac{X_p}{\frac{1}{T}{\int }_0^T|x\left(t\right)|dt}},$$

  (12)
• Crest factor $CF$:

  $$CF={\displaystyle \frac{X_P}{X_{RMS}}},$$

  (13)
• Impulse factor $IF$:

  $$IF={\displaystyle \frac{X_P}{\overline{x}}}.$$

  (14)

In this work, numerical calculations are performed in the microcontroller. It is important to note that the time T that appears in (4)–(12) should be replaced by the number of signal samples, and the integration should be replaced by adding the collected samples.

3. Data Acquisition and Edge Processing

This chapter outlines the implementation of measurements using 3G/4G modems and the benefits of an edge computing approach. It also describes the underlying concept of the vibration monitoring system and the communication protocol that has been implemented.

3.1. Measurement System with 3G/4G Communication

Remote automotive measurement systems require reliable wireless communication to transmit data to central servers. Although LoRa and SigFox are sometimes used, their limited network coverage can be a constraint in remote areas [38,39,40]. In contrast, mobile telecommunication networks offer near-ubiquitous availability, which makes them suitable for automotive applications that demand continuous and reliable data transmission [41].

Cellular networks have evolved significantly—from analogue 1G systems with basic Circuit Switched Data to 2G technologies introducing more efficient packet-switched modes such as GPRS (General Packet Radio Service) [42]. Today’s 4G (LTE - Long Term Evolution) and emerging 5G networks provide high-speed, low-latency communication. Based on Orthogonal Frequency Division Multiple Access (OFDMA), LTE achieves data rates exceeding 1 Gbps and is widely used in modern measurement systems [43].

Although 5G adoption is growing, 3G and especially 4G technologies remain practical for distributed mobile sensing, offering sufficient speed and reliability for many current automotive monitoring applications.

Currently, a wide range of 3G and 4G modules are available that are easily integrable into measurement systems. Produced by various manufacturers, these modules typically offer UART (Universal Asynchronous Receiver-Transmitter) compatibility with microcontroller-based systems (Figure 6). Their availability and flexibility make them ideal for reliable and cost-effective mobile data transmission in applications such as automotive monitoring, environmental monitoring, and logistics.

Communication between the microcontroller unit (MCU) and 3G/4G modems typically uses the AT command language via UART, with commands starting with “AT” to perform specific operations. For example, “AT+CPIN” enters the SIM card PIN for network authentication.

Modern 3G/4G modems often include an integrated TCP/IP stack, supporting network communication protocols. Some also support application protocols such as HTTP (Hypertext Transfer Protocol) and MQTT (Message Queue Telemetry Transport), simplifying embedded software by offloading networking tasks [41].

3.2. Edge Computing for Improved Performance of the Measurement System

Edge computing is a kind of distributed computing that brings computation or data storage closer to the location where they are produced. Instead of relying on a centralised data processing infrastructure like traditional cloud computing, in the edge computing approach, data are processed and analysed at the “edge” of the network, near the source of the data (Figure 7, “edge layer”).

This idea is popular among IoT devices, sensors, and local servers. However, such a concept requires higher computing power of the computing device, which implies a higher price. Properly implemented edge computing can reduce latency, conserve bandwidth, improve real-time processing, and improve overall performance and reliability. As IoT devices, including connected vehicles, continue to grow in number, edge computing enables more efficient scaling by distributing processing tasks across numerous edge nodes. This approach enables more efficient handling of the growing data load generated by numerous devices while preventing the overload of central data servers. In the case of connected vehicles, edge computing improves reliability and resilience. Ensuring continuous connectivity to centralised cloud servers in remote or rural areas can pose significant challenges. Edge computing allows onboard devices and systems to continue operating even if they lose connection to the central server. This makes systems more resilient to network outages or interruptions, as local processing ensures that critical tasks can still be performed. The costs associated with transmitting, storing, and processing large amounts of data in centralised data centres can be reduced by offloading the data processing to the edge. Furthermore, processing data locally allows for faster decision making, leading to operational efficiency and cost savings. In the presented system, several parameters are calculated from the signals recorded in the time domain: average value $\overline{x}$, peak value $X_P$, peak-to-peak value $X_{P-P}$, root mean square (RMS) value $X_{RMS}$, variance $\upsilon$, standard deviation $\sigma$, skewness S, kurtosis K, form factor $SF$, crest factor $CF$, and impulse factor $IF$. Such an approach is typical for edge computing systems, where some parameters are calculated onboard, and the calculated data are then sent to the MQTT broker instead of sending much more data when the raw data would be sent.

Communication with the MQTT broker, which is deployed in the cloud, can be established using a mobile router installed onboard the vehicle. In the absence of such equipment, a 3G/4G LTE modem may be used as an alternative. Both concepts are presented in block diagram form in Figure 8. In scenarios where a mobile router is not available, sensor data are transmitted to the processing unit, which can also act as an MQTT client. Alternatively, the MQTT client functionality can be provided by the 3G/4G LTE modem itself, assuming the use of a more advanced (and typically more expensive) router with extended capabilities. The processing unit forwards the data to the modem, which establishes an Internet connection. Once connected, the MQTT client communicates with the MQTT broker located in the cloud. The MQTT broker is configured with a fixed IP address, allowing any MQTT client with knowledge of this address to establish a connection. In the case where the vehicle is equipped with a dedicated mobile router that provides a Wi-Fi network on board, the processing unit communicates wirelessly with the router through Wi-Fi using an ESP32 module.

3.3. Data Acquisition System

The data acquisition system consists of a few components. The system facilitates the collection of sensor data and its transmission to client applications through an MQTT broker. The MQTT protocol (Message Queuing Telemetry Transport) is a lightweight, publish/subscribe messaging protocol designed for use with low-bandwidth or unreliable networks, which fits well in the described case (cars may drive in regions with unstable 3G/4G connections). Each measurement node in the system is responsible for collecting vibration data using the MPU-6050 accelerometer. Communication between the sensor and the AVR microcontroller is accomplished using the $I^{2}C$ interface (Figure 9). The microcontroller performs key operations, including data acquisition, parameter computation, and transmission handling. The AVR transmits the data to the second board, which is based on the ESP32 microcontroller (Figure 10). It is necessary to connect to the Internet using a Wi-Fi connection. If the car is not equipped with Wi-Fi connectivity onboard, an additional module with a 3G/4G modem is used for the Internet connection. The data are then sent to the central server via the MQTT protocol. The central server is, in fact, an MQTT broker, responsible for receiving and transmitting messages between the connected nodes (cars and storing and presentation devices).

The MPU-6050 communicates with the AVR microcontroller over the $I^{2}C$ protocol, which allows multiple devices to be connected to a single bus consisting of two lines: $SCL$ (“clock line”) and $SDA$ (“data line”). The AVR microcontroller periodically requests sensor readings, calculates several parameters from the measured data, and sends the parameters to the ESP32 board. The communication process consists of the following steps:

Step 1:

The AVR reads vibration data from the MPU-6050 sensor.

Step 2:

The AVR calculates several parameters: average value $\overline{x}$, peak value $X_P$, peak-to-peak value $X_{P-P}$, root mean square (RMS) value $X_{RMS}$, variance $\upsilon$, standard deviation $\sigma$, skewness S, kurtosis K, form factor $SF$, crest factor $CF$, and impulse factor $IF$.

Step 3:

The AVR sends the calculated and converted data to the ESP32 over UART. This involves a serial communication protocol to pass the data between the two devices.

Step 4:

The ESP32 is responsible for connecting to the Internet and transmitting the data to the broker with the MQTT protocol (described in the next section of the article).

In the solution described, the ESP32 (Wi-Fi module) is used for communication with the server. It is a low-cost microcontroller with built-in Wi-Fi and Bluetooth capabilities. It serves as a bridge between the sensor node and the Internet. The key functions of the ESP32 in this system are Wi-Fi connectivity and the MQTT client. Direct communication between the AVR microcontroller and the Internet is not possible. The important function of the ESP32 is an MQTT client. It receives data from the AVR microcontroller and sends them to an MQTT broker. The sensor board with the AVR and ESP32 microcontrollers is shown in Figure 10, while the board that acts as an MQTT broker is shown in Figure 11.

The ESP32 handles the communication with the broker, subscribing and publishing to specific topics. The topics’ names for testing purposes consist of a few letters and an additional eight decimal digits forming unique numbers. The number is assigned during the system configuration. The MQTT communication is described in more detail in the next section. The MQTT protocol helps to achieve reliable communication with the server in the described system and provides efficient data transfer between the sensor node and a server in the cloud, where the data can be processed, visualised, or stored for further analysis. The MQTT broker is set up on a Raspberry Pi board in the described system. So the Raspberry Pi acts as the central MQTT broker, handling communication between the sensor nodes and the cloud or other data storage systems. The Raspberry Pi hosts the MQTT broker, which is Eclipse Mosquitto. It is an open source (EPL/EDL licensed) message broker that implements the MQTT protocol versions 5.0 and 3.1. The broker is responsible for managing the incoming and outgoing messages from the sensor nodes. The broker manages topics to which sensor nodes can publish data and where clients (such as cloud servers or monitoring systems) can subscribe to receive the data. We have written a client application that helps during practical system tests. The app is presented in Figure 12 and communicates with the broker installed on the Raspberry Pi. Generally, Raspberry Pi and the broker may also be connected to one of the commercial cloud servers, forwarding the data to a cloud-based storage or processing service. The cloud server is optional, but in a complete system, a cloud server can be used to store or process the incoming data or parameters. Such an approach gives great scalability.

The server should subscribe to the MQTT topics where the sensor nodes publish their data. The server may also visualise the data (e.g., by generating reports or graphs or sending alerts). Another important functionality may be to store the data in a cloud database or other data storage systems for later analysis. To ensure data integrity, a checking mechanism should be considered. That may be a CRC (Cyclic Redundancy Check) check in the communication between the AVR, ESP32, and the client applications. It has not yet been achieved in the system. In the production system, it will be important to secure the MQTT communication, e.g., TLS/SSL encryption for the messages and MQTT client authentication. Another important element is good power management. The system should be turned off when the engine is not running. If the system should work even during the parking state, depending on the deployment scenario, the power requirements of the measuring system should be carefully considered. The system can implement power-saving mechanisms by activating deep sleep modes for the AVR and ESP32 during time intervals when not actively transmitting data. Another option is to send less information during the parking state and to extend the time interval between messages. The system should be awakened only just before the measurement. After awakening, it calculates and sends the data and returns to the efficient sleep state. This should save the car’s battery for a longer time.

3.4. MQTT Protocol

The MQTT protocol in the system is used to communicate with the client application. MQTT (Message Queuing Telemetry Transport) is a lightweight, publish–subscribe network protocol designed for low-bandwidth, high-latency, or unreliable networks, commonly used in Internet of Things (IoT) systems [44]. MQTT is good for scenarios where a small code footprint and minimal network bandwidth are essential [45]. MQTT operates on the publish/subscribe model. Devices (called clients) communicate with a central server, known as a broker, to exchange messages. A client can either publish data to a topic or subscribe to topics to receive messages. The broker manages the message distribution between clients, ensuring efficient and reliable message delivery even when clients are intermittently connected or have limited bandwidth. An MQTT client may be the remote measurement system or an application that collects and presents the measured data. MQTT is widely used in IoT and machine-to-machine (M2M) communication. Its lightweight nature and efficient message delivery make it suitable for applications in various industries, including controlling and monitoring smart home devices like lights, thermostats, and security cameras; is employed to collect sensor data, control machinery, and monitor systems in real-time; and is used for vehicle monitoring systems to report on fuel consumption, diagnostics, and traffic updates. Smart grids and energy monitoring systems use MQTT to collect data from meters and manage power distribution [46]. MQTT has several advantages. For a distributed system, the most important advantages are low bandwidth and a good quality of service (QoS) mechanism for message delivery, which ensures reliability and flexibility. Due to its lightweight design and centralised broker architecture, MQTT can easily scale to support thousands or millions of devices in large IoT deployments. Implementing MQTT in the system, we are sure that even if we extend our system, we will not meet the limitations of the communication protocol used. Several other protocols are commonly used in IoT systems. CoAP (Constrained Application Protocol) is a lightweight protocol similar to HTTP, designed for constrained devices and networks. It operates over UDP, and, compared to MQTT, it is more suitable for resource-constrained devices. However, the quality of service (QoS) in this case is much worse. AMQP (Advanced Message Queuing Protocol) is a messaging protocol that provides more robust features than MQTT, including message routing, queuing, and security features. It is used in large-scale enterprise systems, but in the case of the presented system, it introduces too much overhead. Another example may be HTTP, which is widely used for web applications; however, it is less suitable for real-time, low-latency, or low-bandwidth IoT systems due to its heavier protocol overhead. XMPP (Extensible Messaging and Presence Protocol) is often used for instant messaging and presence information in IoT, offering an open standard and real-time communication, but with higher complexity than MQTT.

4. Results

This section presents and discusses the results obtained from tests conducted under real-world conditions.

The measurement system was tested on the Hyundai vehicle (Hyundai Motor, Bialystok, Poland) shown in Figure 13. The AVR microcontroller was responsible for calculating the signal from the accelerometer, attached to the engine block on the intake manifold, where a pre-tapped process hole was used. The MPU-6050 was configured with DLPF_CFG = 0x02 in the ACCEL_CONFIG register, which sets its bandwidth at 94 Hz, with a sampling rate of 1 kHz and a delay of 3 ms, and AFS_SEL = 0x03, which sets its maximum measurement range. For the $I^{2}C$ bus, a transmission speed of 100 kHz was configured on the AVR microcontroller and the MPU-6050 by setting the SMPLRT_DIV register to 0x07. Although the sampling rate of 1 kHz would theoretically allow the capture of frequency components up to 500 Hz (according to the Nyquist criterion), the effective bandwidth of the measurement system is limited to approximately 94 Hz due to the configured low-pass filter setting. Consequently, the physical vibration signals that can be reliably acquired and analysed are confined to this frequency range. This limitation is acceptable for the intended application, as the dominant vibration components of internal combustion engines typically occur within the 0 to 100 Hz band. The selected filter setting represents a trade-off between attenuating high-frequency noise and preserving diagnostically relevant signal content. This bandwidth restriction has been taken into account during the design of the system and the interpretation of the acquired data. The sensor mounting angle, relative to the ground, was approximately ${60}^{\circ }$. However, following the integration of the accelerometer in the PCB, and taking into account the angle mentioned above, a ${180}^{\circ }$ rotation of the axis was obtained.

The initial sensor readings (engine stopped) for each axis were $A_x$ = −0.76 g, $A_y$ = 0.00 g, $A_z$ = 0.50 g. Knowing these values, we can calculate the angles ($\alpha$, $\beta$, $\gamma$) of the inclination of the accelerometer from each axis in degrees [°] and thus determine its precise position, which affects the values obtained during the actual measurements. By carrying out the necessary calculations, we obtain the following:

$$\alpha ={\displaystyle \frac{atan\left(\frac{A_x}{\sqrt{A_y^2+A_z^2}}\right)180}{\pi }}=-56.{66}^{\circ }\left(inclinationfromtheX\text{-}axis\right),$$

(15)

$$\beta ={\displaystyle \frac{atan\left(\frac{A_y}{\sqrt{A_x^2+A_z^2}}\right)180}{\pi }}=0.{00}^{\circ }\left(inclinationfromtheY\text{-}axis\right),$$

(16)

$$\gamma ={\displaystyle \frac{atan\left(\frac{A_z}{\sqrt{A_x^2+A_y^2}}\right)180}{\pi }}=33.{34}^{\circ }\left(inclinationfromtheZ\text{-}axis\right).$$

(17)

The value $\beta =0$ means that the rotation axis of the accelerometer is the Y-axis. During vibration, the angles change dynamically from the static location.

The parameter calculation time was set to 5 ms. This measurement interval is chosen based on the assumption that time-domain metrics would be computed immediately after data acquisition. The duration was determined through tests conducted in the Atmel Studio IDE, where the number of clock cycles required for data buffering, metric computation across all three axes, internal memory storage, and data transmission was measured. The program used for testing purposes was written in assembly language for the ATmega88 microcontroller (Microchip, Bialystok, Poland) running at 20 MHz. The total processing time was found to be approximately 4.78 ms. As a result, the sampling interval of 5 ms was selected to ensure reliable real-time operation. Precise timing was ensured by using an interrupt from an overflow Timer0 implemented in the microcontroller structure.

The tests were conducted at normal engine operation and different rotational speeds between 1000 and 3500 rpm with a step of 500 rpm. The values of the measures (4)–(14) for the signal relative to each axis were then calculated in successive 5-second time windows (1000 samples were collected, calculations were then performed, and further samples were then transmitted to the buffer). The results are presented in

Table 2. Calculated measures for engine vibration in the X-axis direction.

Rotational Speed [rpm]	$\overline{\mathit{x}}$	${\mathit{X}}_{\mathit{P}}$	${\mathit{X}}_{\mathit{P}-\mathit{P}}$	${\mathit{X}}_{\mathit{RMS}}$	$\mathit{\upsilon }$	$\mathit{\sigma }$	S	K	$\mathit{SF}$	$\mathit{CF}$	$\mathit{IF}$
1000	−0.78	−0.52	−1.52	0.78	0.02	0.13	−0.24	2.15	1.01	−0.66	0.67
1500	−0.80	0.16	−0.84	0.88	0.14	0.37	0.36	2.01	1.10	0.18	−0.20
2000	−0.79	0.42	−0.58	0.99	0.36	0.60	0.05	1.66	1.21	0.42	−0.53
2500	0.48	1.59	0.59	0.83	0.47	0.68	−1.04	4.55	1.16	1.90	3.22
3000	−0.77	0.48	−0.52	0.94	0.30	0.54	−0.05	2.44	1.19	0.51	−0.63
3500	−0.71	0.33	−0.67	0.87	0.25	0.50	−0.59	3.75	1.20	0.38	−0.46

,

Table 3. Calculated measures for engine vibration in the Y-axis direction.

Rotational Speed [rpm]	$\overline{\mathit{x}}$	${\mathit{X}}_{\mathit{P}}$	${\mathit{X}}_{\mathit{P}-\mathit{P}}$	${\mathit{X}}_{\mathit{RMS}}$	$\mathit{\upsilon }$	$\mathit{\sigma }$	S	K	$\mathit{SF}$	$\mathit{CF}$	$\mathit{IF}$
1000	−0.07	0.08	−0.92	0.10	0.01	0.07	0.01	1.89	1.23	0.84	−1.22
1500	−0.07	0.31	−0.69	0.14	0.02	0.13	0.13	2.38	1.22	2.14	−4.64
2000	−0.06	0.27	−0.73	0.17	0.02	0.15	0.08	2.24	1.19	1.61	−4.19
2500	−0.55	−0.12	−1.12	0.58	0.03	0.18	−0.17	2.23	1.05	−0.21	0.22
3000	−0.06	0.80	−0.20	0.40	0.16	0.40	−0.04	1.97	1.16	2.00	−13.96
3500	−0.26	1.64	0.64	0.89	0.72	0.85	0.24	1.95	1.14	1.85	−6.34

and

Table 4. Calculated measures for engine vibration in the Z-axis direction.

Rotational Speed [rpm]	$\overline{\mathit{x}}$	${\mathit{X}}_{\mathit{P}}$	${\mathit{X}}_{\mathit{P}-\mathit{P}}$	${\mathit{X}}_{\mathit{RMS}}$	$\mathit{\upsilon }$	$\mathit{\sigma }$	S	K	$\mathit{SF}$	$\mathit{CF}$	$\mathit{IF}$
1000	0.47	0.69	−0.31	0.49	0.01	0.10	1.40	2.02	1.02	1.40	1.43
1500	0.48	0.72	−0.28	0.50	0.01	0.11	0.26	1.77	1.03	1.45	1.49
2000	0.49	0.73	−0.27	0.50	0.01	0.11	−0.03	2.07	1.02	1.47	1.50
2500	0.47	0.81	−0.19	0.52	0.05	0.22	−1.13	3.75	1.08	1.55	1.71
3000	0.50	1.49	0.49	0.76	0.33	0.58	−0.01	1.59	1.23	1.96	2.99
3500	0.40	1.75	0.75	0.81	0.50	0.71	0.29	1.81	1.27	2.15	4.41

. They are also available in the client application shown in Figure 12.

Considering the position of the sensor, analysis of the acceleration data obtained in the Z-axis direction is warranted. The highest recorded acceleration value was 1.75 g. This represents almost $12\%$ of the sensor’s measurement range, indicating a sufficient safety margin. For parameters such as the value of $X_{RMS}$, the variance $\upsilon$, and the standard deviation $\sigma$, increasing values are visible for increasing rotational speed, especially above 2500 rpm. The increasing $X_{RMS}$ parameter indicates an increase in the overall vibration of the engine. This may be due to the higher dynamic forces in the piston–crankshaft system resulting from more combustion cycles per second. The variance $\upsilon$ indicates the dispersion of vibration values around the mean, so an increase in variance means that the vibration amplitudes become more variable and less stable. In contrast, an increase in standard deviation $\sigma$ signifies increased randomness in vibrations. A similar relationship can be observed considering the values of parameters, such as the form factor $SF$, the crest factor $CF$, and the impulse factor $IF$. An increase in each of these parameters can be seen as the rotational speed increases. In summary, a comprehensive analysis of these parameters provides significant insight into the nature of the vibration. This is because each of these parameters is related to a different aspect of the vibration signal. The $SF$ ratio, in particular, is important here, as it defines the relationship between the $X_{RMS}$ value to the average value $\overline{x}$ of the vibration signal. An increase in $SF$ indicates that the increasing signal amplitude fluctuations are relative to the mean value. The parameter $CF$, on the other hand, quantifies the magnitude of the signal’s peaks relative to the value $X_{RMS}$, indicating the presence of the fast impulsive peaks in the signal as $CF$ increases. Finally, the $IF$ parameter shows the proportion of the vibration signal dominated by sudden pulses relative to its $\overline{x}$. The situation described above is illustrated in Figure 14.

5. Conclusions

This study has demonstrated the feasibility and effectiveness of a remote vibration monitoring system for internal combustion engines, leveraging edge computing and low-cost hardware components. The integration of the MPU-6050 digital accelerometer with AVR and ESP32 microcontrollers allowed for real-time signal acquisition and preprocessing, reducing latency and data transfer overhead. The ability to transmit processed data to a central server for further analysis was verified, marking an important step toward the development of scalable, distributed diagnostic systems. The diagnostic capability of the system was evaluated using statistical parameters in the time domain, including the value of the root mean square (RMS) $X_{RMS}$, the variance $\upsilon$, the standard deviation $\sigma$, and the impulse factor $IF$. An observed increase in these metrics was associated with deteriorating engine conditions, highlighting their potential as early indicators of mechanical faults. However, to achieve more granular and accurate fault identification, the addition of frequency domain analysis and spectral features is recommended.

The proposed system advances the state of knowledge in the domain of embedded vibration diagnostics by demonstrating the feasibility of real-time edge processing of multiple time-domain and statistical features derived from tri-axial accelerometer signals. Implementing on-board computation significantly reduces transmission bandwidth requirements while maintaining diagnostic fidelity. This approach enables scalable deployment in distributed monitoring scenarios, particularly for mobile and resource-constrained environments. In addition, the system (ESP32) supports over-the-air (OTA) firmware updates through GSM communication, allowing the remote deployment of algorithmic improvements and configuration changes. The modular architecture, combined with the OTA capability, provides a flexible and upgradable platform for the future development of adaptive diagnostic algorithms and application-specific feature sets. The article highlights inherent hardware constraints that can arise during the integration of measurement system components. These issues are presented in more detail in the Appendix A.

Despite promising results, several limitations must be addressed before large-scale deployment. These include the limited computational resources available on edge devices, challenges in multi-sensor data fusion, and the need for robust data encryption to ensure privacy and integrity in data transmission. Moreover, scalability under various environmental conditions and engine configurations remains an open question.