As our project continues to evolve from concept to implementation, one of the most significant decisions we’ve made recently concerns the infrastructure for edge computing. After technical evaluations and a recommendation from our Scientific Advisor, Prof. Teresa Vazão, we are going to use the Raspberry Pi 4 Model B (1GB) as the local computing hub to serve as the intermediary between wearable devices and the central system.
Why Edge Computing?
The Dynamic Emergency Monitoring System (DEMS) is designed to monitor patients' vital signs in real time through wearable devices. To ensure quick and efficient data handling, our architecture incorporates edge computing, where initial processing happens close to the source — in this case, on a local gateway. This layer offers critical benefits:
- Real-time signal processing and anomaly detection
- Reduced bandwidth and energy consumption
- Prioritization of urgent data transmission
- Temporary data storage and buffering
- Improved resilience and offline operation if cloud connectivity is interrupted
Why the Raspberry Pi 4 Model B?
After comparing a range of microcontrollers and edge-capable devices, the Raspberry Pi 4 Model B (1GB) stood out due to the following advantages:
Balanced Performance for Prototyping
With its quad-core 1.5GHz processor and 1GB of RAM, it can handle multiple data streams, apply signal processing algorithms (e.g., low-pass filters, moving average, FFT), and manage local storage simultaneously — all essential for early testing and validation.
Built-in Connectivity
With Wi-Fi and Bluetooth support, the Raspberry Pi can connect directly to multiple wearable devices. This makes it well-suited for reading data in parallel from several patient wristbands and serving as a local communication hub.
Local Data Storage for Synchronization
One of the most important roles the Raspberry Pi plays in our architecture is temporarily storing processed data locally. This allows the system to:
- Buffer data in case of connectivity loss with the main server
- Log information for historical review or debugging
- Package and forward summaries or time-series chunks to our app interface
- Improve responsiveness of the app by reducing the need for constant live streaming
Processed data — including filtered vital signs, triage status, and alert events — is stored in structured formats (e.g., CSV file or SQL database, yet to decide) and sent to the app interface used by healthcare professionals. This enables the medical staff to access real-time patient overviews and historical data at a glance, enhancing situational awareness in emergency units.
Integration in Our System Architecture
In our system, the Raspberry Pi serves as a smart bridge between the wearables and the cloud. It:
- Reads sensor data via Wi-Fi
- Applies preprocessing algorithms (e.g., outlier filtering, smoothing)
- Detects abnormal readings in real-time
- Stores logs for synchronization with the app interface
- Transmits relevant data to a central server or directly to the application layer
This architecture ensures low-latency local processing while maintaining access to a centralized view of patient conditions through the app.
Next Steps
The adoption of the Raspberry Pi 4 Model B (1GB) as our edge computing node represents a key milestone in validating the feasibility of our solution. It enables us to bridge the gap between raw sensor data and actionable clinical information by ensuring real-time processing, efficient data transmission, and robust temporary storage. The device’s flexibility, performance, and cost-effectiveness make it ideal for our prototype phase and future scalability.
With this foundation in place, we are now equipped to proceed with testing real-time monitoring scenarios, integrating with our app interface, and optimizing the flow of critical patient information. Ultimately, this choice strengthens our system’s ability to support emergency healthcare professionals in making faster, more informed decisions — improving triage accuracy and patient outcomes in high-pressure environments.
