This section describes the implementation details related to each component of the presented system.
5.1. System Component Implementation
This subsection describes the implementation of the wearable device and of the embedded system that enables real-time audio processing, adaptive noise reduction, localization, and safety communication. The focus is on the practical realization of the architecture previously introduced, highlighting hardware choices, signal processing pipelines, and software integration.
Regarding audio acquisition, low-cost electret lavalier microphones (widely used small capacitor microphones) were selected based on preliminary experimental results [
59] and prior validation campaigns comparing frequency response and directivity patterns against professional measurement equipment [
60], because they demonstrated sufficient accuracy for speech detection applications while maintaining cost-effectiveness and compact design suitable for integration into the headphone housing. The selected microphones provide a fixed sampling rate of 48 kHz and are used to capture the acoustic environment surrounding the worker. As described in the architectural design, two microphones are positioned at ear level and are dedicated to audio reproduction after filtering, while a third microphone is used exclusively to feed the VAD pipeline.
Once captured, the audio stream is organized to be compatible with the selected VAD model, namely Silero VAD. This model was chosen due to its suitability for real-time applications and its high computational efficiency. Performance evaluations reported in the official Silero VAD documentation [
26] show that, on high-end CPUs, the model is capable of processing audio chunks significantly faster than real time. To further validate its applicability in our scenario, additional tests were conducted directly on a Raspberry Pi 4 [
61] using audio sampled at 48 kHz and chunk sizes equivalent to 32 ms. In this configuration, Silero VAD processed each chunk in approximately 2.5 ms, resulting in a real-time speed well above the requirements of the system and confirming its feasibility for continuous, low-latency operation on embedded hardware.
For real-time inference, Silero VAD requires an input sampling rate of 16 kHz. Since the microphones are connected to an ADC that natively operates at 48 kHz, the audio stream is initially opened at this rate and segmented into chunks of 1536 samples, corresponding to three times the standard 512-sample window used at 16 kHz. Each chunk is then converted from
int16 to
float32 format and normalized with respect to its maximum absolute value. After this conversion, the chunk is resampled to 16 kHz and passed to the VAD model. The output of the model is a floating-point confidence score in the range
, representing the estimated probability of voice activity within the analyzed time window. The complete processing chain is summarized in Algorithm 1.
| Algorithm 1 Audio processing in real time with Silero VAD model |
- 1:
procedure
AudioProcessing - 2:
Input: Audio stream at 48 kHz - 3:
Output: Confidence score between 0 and 1 for each chunk - 4:
- 5:
- 6:
- 7:
- 8:
- 9:
while True do - 10:
- 11:
- 12:
- 13:
- 14:
- 15:
- 16:
yield - 17:
end while - 18:
end procedure
|
The confidence score produced by the VAD model for each chunk is combined with the equivalent SPL, measured in decibels, to determine the filtering level applied by the digital signal processors. The DSPs accept a discrete filtering level ranging from 0 to 7, where higher values correspond to stronger noise attenuation. To reduce temporal fluctuations and improve stability, the voice activity confidence
v is not computed on a single chunk but averaged over multiple consecutive chunks. Specifically, the system processes
chunks, where
= 48,000 Hz is the sampling rate,
samples is the chunk size, and
is a temporal factor. This results in
chunks being processed together. Given that each chunk has a duration of
s, the total analysis window spans approximately
s, or roughly half a second. The voice activity confidence
v is therefore computed as follows:
where
is the confidence score returned by the Silero VAD model for the
i-th chunk.
The mapping from continuous acoustic features to the discrete filtering domain is then defined as follows:
where
is the voice activity confidence defined earlier,
is the normalized SPL, where the SPL has been computed as the RMS-based sound pressure level in dBFS over the same 16 chunks where the voice confidence was averaged, and
k is a tuning parameter. The SPL computed over the 16 chunks is mapped to the unit interval through min–max normalization: the upper reference value is fixed at 0 dB, while the lower bound is determined empirically for the specific acquisition device. In practice, the minimum reference value corresponds to the SPL measured by the microphone under complete silence conditions, thereby capturing the sensor noise floor. This calibration step ensures that the normalized variable
d reflects relative acoustic intensity with respect to the operational dynamic range of the employed microphone.
The formulation can be interpreted as a bounded decision function implementing a trade-off between two competing objectives: environmental noise attenuation and speech preservation. Specifically, the term models the expected benefit of attenuation under the assumption that noise suppression is desirable when speech presence is unlikely, while the term introduces a compensatory factor that limits attenuation when voice activity is detected. The expression is therefore a convex combination of noise-driven and speech-driven control components, constrained to the unit interval and subsequently quantized to match the discrete control interface of the DSP. This design enforces three desirable properties for real-time embedded operation: boundedness, monotonicity with respect to noise level, and attenuation reduction in the presence of speech.
The specific parametric form was selected to satisfy these structural constraints while maintaining constant-time computation and numerical stability on resource-limited hardware. The value of
k is not theoretically fixed but empirically tuned using the debug dashboard described in
Section 6.1.1, to reflect application-specific safety requirements and perceptual tolerances. Calibration was performed by analyzing system responses across representative acoustic scenarios and selecting values that maximize speech intelligibility while maintaining effective noise reduction. The comparative behavior shown in
Figure 2 illustrates how different values of
k implement distinct operating points along this trade-off curve.
Alternative formulations are possible: adaptive strategies could estimate k online based on contextual statistics of the acoustic environment, while learning-based approaches could replace the analytical mapping with a regression model trained to predict optimal attenuation levels from acoustic features. However, such approaches introduce additional computational cost, training requirements, and reduced interpretability. The proposed formulation was therefore adopted as a deterministic control law that provides predictable behavior, low latency, and explicit tunability suitable for safety-critical embedded deployment.
The quantized filtering level L is then translated into a hardware configuration for the DSPs through a set of GPIO pins. Each filtering level is encoded as a 3-bit value, which is mapped directly to three digital output pins. These pins are mirrored on two independent DSPs, one for each ear cup, ensuring symmetrical and consistent audio processing on both sides. The presence of two separate DSPs is required to maintain true stereo processing and to allow independent but synchronized control of the left and right acoustic channels, which is essential for spatial perception and user comfort. As previously described, to ensure stable auditory perception and prevent rapid oscillations in filtering strength, the system does not update the DSP configuration on a per-chunk basis. Instead, VAD confidence scores are aggregated over half-second time windows and mapped to one of eight discrete filtering levels. This temporal aggregation strategy smooths short-term fluctuations while maintaining responsiveness to changes in acoustic conditions.
The mapping between the 3-bit configuration and the DSP behavior is defined by the tables reported below.
Table 1 shows how the combination of logic levels on the three control pins selects one of the eight available filtering configurations.
Table 2 reports the corresponding attenuation values applied by the DSPs in terms of tone reduction and white noise reduction.
All the audio processing, including VAD inference, SPL computation, and filtering level quantization, is executed on a Raspberry Pi 4. This platform was selected due to its ease of use, extensive software support, and direct access to GPIO pins, which allows seamless interfacing with the electronic board controlling the DSPs. Furthermore, the Raspberry Pi natively integrates both Bluetooth and WiFi modules, which are fundamental for system operation.
The Bluetooth module is used to continuously scan the industrial environment for BLE beacons associated with smart machinery. Each machine is equipped with one or more beacons, and when a beacon is detected, its received signal strength indicator (RSSI) value is compared against a predefined threshold. Depending on whether the RSSI is above or below this threshold, the device subscribes to either a near or a far MQTT topic on the local central server. From that point on, the Raspberry Pi periodically publishes messages to the subscribed topic, containing its own MAC address and the identifier of the detected machine. This mechanism allows the server to maintain an up-to-date view of worker proximity to machinery.
The WiFi module is used to interact with the backend APIs exposed by the local central server. Through these APIs, the Raspberry Pi retrieves the mapping between beacon MAC addresses and machinery identifiers, as well as the RSSI thresholds associated with each beacon. This information is required to correctly interpret BLE scan results and to apply machine-specific proximity logic.
The industrial machines considered in this system are smart machines equipped with programmable logic controllers (PLCs) and network connectivity modules [
62]. They were simulated using digital twins implemented as Python 3/Qt Creator-based virtual clients running on Raspberry Pi devices, each emulating the operations of the Data Collector Manager (DCM) via HTTP POST requests. Each digital twin can simulate machine operations and complex scenarios in real time.
For physical implementation, a modified CNC lathe was integrated into the system, equipped with a PLC that communicates directly with the system supervisor. The DCM by D.Electron acts as middleware, collecting, formatting, and transmitting data to the backend server via HTTP POST requests. When a malfunction or hazardous condition occurs, the PLC transmits real-time information regarding machine downtime, alarms, control display status, maintenance needs, smart service functionalities, and executed programs. All transmitted data follow a structured format containing the machine’s serial number, data type, numeric value, description, and timestamp.
The local central server was implemented using Spring Boot for the backend and Angular for the frontend. In addition to the APIs used by the Raspberry Pi to retrieve beacon configurations, the backend exposes a complete set of services for system management, including visualization and modification of workers, machines, beacons, thresholds, and environmental configurations.
Access to the dashboard is restricted to the safety manager through an authentication mechanism. The dashboard allows real-time monitoring of all system entities and enables the creation and editing of custom messages to be delivered to workers. Each pair of headphones is associated with a dedicated MQTT topic, identified by its MAC address. By correlating MQTT messages published on the near topic with the known mapping between workers and headphones, the dashboard can determine which workers are located near a specific machine. The safety manager can then select these workers and send them personalized messages or forward machine-generated alarms.
When a pair of headphones receives an alarm or a customized message, the filtering system is temporarily disabled by toggling a dedicated control pin. During this interval, the system relies exclusively on passive attenuation, ensuring that the synthesized alarm message is reproduced with maximum clarity. The passive acoustic barrier is dimensioned to provide full baseline hearing protection on its own, preventing harmful noise components from reaching the ear even in the absence of active noise reduction. In this operating mode, no detrimental sound energy bypasses the protective attenuation, and the hearing protection performance remains compliant with the measurement criteria defined by the ISO 4869 framework and the product requirements of the EN 352 series. The selected commercial device complies with the EN 352 standard and provides a noise reduction rating (NRR) of 25 dB, which represents a global attenuation parameter characterizing the overall noise reduction capability of the hearing protector across typical exposure conditions.
Once the message playback is completed, the active filtering system is re-enabled and normal operation resumes. This design choice prevents residual noise components from overlapping with the alarm message. In particular, impulsive noises are only partially mitigated by the DSPs, since active noise reduction algorithms require a short temporal window to adapt their filtering response. This limitation arises from the adaptive nature of DSP-based noise reduction, which requires a finite convergence time to estimate the acoustic transfer function and adjust filter coefficients. Under typical industrial conditions, this adaptation process ranges from several hundreds of milliseconds to a few seconds, making the system inherently less effective against highly impulsive or rapidly varying noise components. Consequently, transient acoustic events may not be sufficiently attenuated and could interfere with the intelligibility of synthesized alarm messages. Moreover, the system is explicitly designed to preserve external voices to maintain situational awareness, which could otherwise interfere with message perception. Temporarily disabling active filtering ensures that neither residual impulsive noise nor intentionally preserved speech masks the alarm, while passive attenuation continues to provide standards-compliant hearing protection and guarantees clear and unambiguous delivery of safety-critical information.
5.2. Data Flow
Industrial environments are typically characterized by the coexistence of high-intensity noise generated by machinery and the voices of workers communicating with each other. This scenario highlights the challenge of achieving effective noise attenuation while preserving situational awareness in hearing protection systems.
The proposed smart headphones primarily rely on passive noise isolation, physically shielding the worker from external sounds. As described in the previous subsection, the device is equipped with three microphones. Two microphones are dedicated to the acquisition of environmental audio, one for each ear, enabling binaural perception and supporting situational awareness, while the third one is specifically used for the VAD algorithm and for the estimation of the SPL expressed in decibels.
Based on the VAD algorithm outputs—namely the estimated probability of speech presence in the acquired audio stream—and the measured SPL, the audio signals captured by the two ear-level microphones are adaptively processed by a DSP-based filter. The filtering parameters are dynamically adjusted in real time to attenuate harmful industrial noise while preserving speech components when vocal activity is detected. The resulting filtered audio stream is then reproduced to the worker through the headphones. In this way, the worker is protected from excessive noise exposure while remaining capable of perceiving colleagues’ voices, which may be essential for warnings or emergency communications.
In parallel with audio processing, the smart headphones also support worker localization within the industrial environment. At system startup, each device retrieves the current configuration of the industrial facility from the central server, including information about installed machinery and the associated BLE beacons. When a worker approaches a machinery, the beacon detection module embedded in the hearing protection system identifies the proximity condition based on the RSSI exceeding a predefined threshold. Upon detection, the device publishes a JSON-formatted message to the system-wide MQTT topic user-near-machinery. The message payload contains two fields: userId, an integer identifying the worker associated with the headphones, and machineryId, an integer identifying the specific machinery. This structured format enables the central server to maintain a precise mapping between workers and machinery in real time. Conversely, when the RSSI falls below the threshold, indicating that the worker has moved away from the machinery, the device publishes a similarly structured message to the complementary topic user-far-machinery, carrying the same userId and machineryId fields. Through this bidirectional notification mechanism, the central server, which hosts the MQTT broker, maintains an up-to-date view of workers’ positions relative to industrial machinery. The use of JSON encoding ensures interoperability and facilitates integration with other system components or third-party monitoring tools.
In addition to proximity-based topics, the MQTT infrastructure defines a dedicated topic for each headphone, uniquely identified by its serial number. Each device is permanently subscribed to its own topic, enabling direct and individualized communication with the corresponding worker. This mechanism supports the delivery of personalized messages or targeted safety alerts.
When a malfunction or hazardous condition is detected by an industrial machinery, the central server is notified. The safety manager can then forward an alarm to all workers considered to be at risk, namely those located in the proximity of the affected machinery. The alarm message is published to the individual MQTT topics of the relevant headphones as a JSON payload containing two fields: message, a string carrying the textual content of the alert, and language, a string specifying the language code (e.g., “it” for Italian, “en” for English) to ensure proper text-to-speech synthesis. Upon reception of the alarm, the headphones convert the textual notification into synthesized speech using a text-to-speech module. Simultaneously, a control signal is sent to the DSP filter to temporarily mute the reproduction of external audio, even if previously filtered. This ensures that the alarm message is delivered with the highest priority and maximum intelligibility.
The presence of the central server, integrating both backend and frontend components, plays a crucial role in the overall system. It is responsible for managing configuration data, coordinating communication, tracking worker positions, and handling safety notifications. As such, the central server represents the core element upon which the operation, supervision, and configurability of the entire system depend.
The overall data flow and interactions among system components described in this section are summarized in
Figure 3.