GO-DRiVeS Intelligent Mobility System

• GO-DRiVeS is a multi-application ecosystem for intelligent mobility, combining physiological sensing, eco-driving analytics, and ride-sharing with modular, research-grade architecture.
• The system leverages advanced sensor integration and neural network classification, achieving 93% accuracy in driving style detection and reducing fuel consumption and emissions.
• Real-world validations demonstrate its capability to optimize safety and efficiency in diverse operational scenarios, including campus ride-sharing and eco-conscious driving feedback.

GO-DRiVeS is a multifaceted application ecosystem for intelligent mobility, research-grade driver monitoring, and eco-safe driving management, implemented across mobile and cloud platforms. Multiple instantiations exist under the GO-DRiVeS name, addressing domains including on-demand ride-sharing for campus environments, in situ physiological/behavioral monitoring using wearable/vehicular sensors, and eco-driving style analysis with real-time feedback and ITS integration. Each variant is defined by rigorous system architectures, data-processing pipelines, and experimental validation in operational environments (Meseguer et al., 2016, Elmalah et al., 18 Jan 2026, González-Ortega et al., 2024).

1. Architectural Paradigms and System Overview

GO-DRiVeS encompasses three main architectural models corresponding to its primary applications:

1. Mobile Physiological Sensing Platform:
   • Implements a multi-activity Android app interfacing Shimmer physiological sensors (ECG, EMG, GSR, IMU), synchronized with a driving simulator over TCP (Android Service and helper classes).
   • Ensures flexible, modular control, supporting multiple sensor streams, real-time visualization, and per-session data storage (González-Ortega et al., 2024).
2. Eco-Driving and ITS-Centric Telemetry:
   • Builds on a four-tier architecture (extension of DrivingStyles): edge (vehicle/phone), local data processing, cloud services, and ITS interfaces for horizontal scalability and real-time stream processing.
   • Integrates OBD-II and smartphone sensors, local neural network inference, edge/cloud-based feedback, and analytics modules (Meseguer et al., 2016).
3. Campus Ride-Sharing Mobile Application:
   • Two-tier client-server architecture (React Native app, Node.js backend, MongoDB) focusing on user-to-vehicle interaction, ride request management, and real-time GPS tracking.
   • Features unified interfaces for users and drivers, FIFO ride matching, and server-managed state transitions (Elmalah et al., 18 Jan 2026).

Each instantiation targets different mobility problems (driver monitoring, eco-driving, campus transport), leveraging tailored technology stacks and communication protocols.

2. Data Acquisition, Sensor Integration, and Preprocessing

GO-DRiVeS implements multi-modal data acquisition adaptable to use-case requirements:

• Physiological Sensing (González-Ortega et al., 2024):
  • Bluetooth SPP (Shimmer library v2.1) for up to four concurrent sensors (ECG: 10.2–128 Hz, EMG/GSR, accelerometer, gyroscope).
  • Per-sensor configuration (sampling rates, range), synchronized session control via background Service listening on port 8080.
  • Real-time plotting (GraphView), CSV-based logging structured per user/session.
• Vehicular Telemetry (Meseguer et al., 2016):
  • OBD-II data (via Bluetooth/Wi-Fi/Ethernet): speed (PID 010D), RPM (010C), MAF (0110), MAP (010B), IAT (010F), TP (0111), engine load (0143).
  • Smartphone APIs for GPS, accelerometer, gyroscope; data tagged with timestamps and GPS.
  • Raw PIDs buffered at 1 Hz (configurable), with local preprocessing: time synchronization, missing-value interpolation, ±3σ outlier filtering.
  • Sliding-window feature extraction (3 s): mean and std of speed, acceleration, RPM; optional FFT features for harsh event detection.
• Campus Ride-Sharing (Elmalah et al., 18 Jan 2026):
  • User-supplied geocoordinates and seat requests; server queries active vehicles and matches via FIFO algorithm.
  • Real-time ride tracking via Socket.IO, with GPS-driven stage transitions.

3. Core Algorithms and Model Architectures

3.1 Neural Network Classification for Driving Style (Meseguer et al., 2016)

• Input Feature Vector (per 3 s window): $\mathrm{mean\_speed}$, $\mathrm{std\_speed}$, $\mathrm{mean\_accel}$, $\mathrm{std\_accel}$, $\mathrm{mean\_RPM}$, $\mathrm{std\_RPM}$.
• Topology: 6-7-3 fully connected feed-forward NN (tanh hidden activation, softmax output).
• Output Classes: Quiet, Normal, Aggressive.
• Training: 16,038 manually labeled segments, backpropagation (learning rate $\,\alpha=0.2\rightarrow0.05\,$, batch size 32, momentum 0.9, $\lambda=1\text{e}-4$, early stopping at 10% validation).
• Performance: Accuracy 93% (per-class precision/recall >90%), MSE <0.02.

3.2 Fuel Consumption and CO₂ Estimation (Meseguer et al., 2016)

• Formulas:
  • Fuel Flow from MAF:

  $$\mathrm{FuelFlow}~[\mathrm{L/h}] = \frac{\mathrm{MAF}~[g/s]\times 3600}{\mathrm{AFR}_A \cdot \mathrm{FD}}$$

  where $\mathrm{AFR}_A=$ actual air-fuel ratio, $\mathrm{FD}=$ fuel density. - Consumption [L/100 km]:

  $$= \frac{\mathrm{FuelFlow}~[\mathrm{L/h}]}{v~[\mathrm{km/h}]}\times100$$ - CO₂ Emissions [g/km]:

  $$= \text{InstantFuelCons}~[\mathrm{L/100~km}] \times m_{\mathrm{CO}_2}~[g/L]$$

  with $$m_{\mathrm{CO}_2} = 3.67 \times C_c \times \mathrm{FD}$$, $C_c=$ carbon content (gasoline: 0.87, diesel: 0.857).

• Model Adaptation: Real-time estimation on device, batch calibration in cloud.

3.3 First-Come First-Serve Matching Algorithm (Elmalah et al., 18 Jan 2026)

• Definition:

$$\text{function}\;\mathrm{matchRequest}(r):\;\text{for}\;c\in C:\;\text{if}\;c.\mathrm{availableSeats}\geq r.\mathrm{seats}:\;c.\mathrm{assign}(r);\;\text{return}\;\mathrm{ACCEPTED};\;\text{return}\;\mathrm{REJECTED}$$

• $O(|C|)$ time complexity (linear in candidate vehicle list).
• Ensures fairness but not large-scale optimization.

4. User Interaction, Feedback, and Synchronization

• Mobile Physiological Monitoring (González-Ortega et al., 2024):

  • Activities: Main, File Management, Device Management; background Service for control and data relay.
  • User flow: sensor pairing, custom configuration, real-time graphs, session storage/export.
  • Synchronization with Unity-based simulators via two-step handshake (PC–Android TCP, <30 ms timestamp alignment).
  • Feature extraction: on-device HRV (SDNN), EMG window means/stddev, GSR statistics, steering gyroscope features (mean, std, zero-crossings).
• Eco-Driving Feedback (Meseguer et al., 2016):
  • Acoustic/haptic alerts (e.g., acceleration >0.5g).
  • On-screen eco-tips (e.g., steady speed, early up-shifting, throttle moderation).
  • Style-weighted post-trip summaries; gamification via driver ranking.
• Ride-Sharing User Experience (Elmalah et al., 18 Jan 2026):
  • Registration and approval, ride request with map-based UI.
  • Real-time socket notifications—drivers receive requests, accept/reject, stage progression.
  • Live tracking, optimized routing using ORS API.

5. Experimental Validation and Key Findings

5.1 Physiological Sensing (González-Ortega et al., 2024)

• Platforms: Android devices (range: single-core/quad-core, Android 2.3–8.1).
• Tested Modes: 4 sensors, up to 60 min, max battery drain <6%.
• Findings:
  • Higher gyroscope variability (σ_ω) in urban vs interurban.
  • Positive correlations (Pearson’s r, $p<0.05$) between mean RPM/speed and specific traffic offenses.
  • In fatigued drivers, HRV amplitude is suppressed, EMG/GSR means are elevated.

5.2 Eco-Driving and Emissions (Meseguer et al., 2016)

• Dataset: $N=16,038$ segments from $N=75$ routes (10 s segments).
• Results: Quiet drivers yielded mean consumption 6.6 L/100 km (σ=0.5), mean CO₂ 10 kg/100 km; aggressive drivers at 8.0 L/100 km, 15 kg/100 km CO₂. Aggressive styles increase consumption by 20% and emissions up to 50%.

5.3 Ride-Sharing Performance (Elmalah et al., 18 Jan 2026)

• Environment: Node.js v16 backend, MongoDB v5, Intel Xeon/16GB RAM, tested with iPhoneX and Android emulator.
• Metrics:
  • Response times ($T_{\mathrm{avg}}$): 120 ms (50 users) → 260 ms (200 users).
  • Throughput ($\lambda$): 420/s (50), 610/s (200).
  • Linear $T_{\mathrm{avg}}$ scaling up to 100 users, followed by graceful degradation; Socket.IO overhead ≈20 ms.

6. Extensibility, Integration, and Adaptation

• Physiological Application: Modular design allows refactoring for clinical or athletic monitoring, alternate sensors via pluggable interfaces, encrypted storage, BLE/GATT custom support, portable data export, and custom processing pipelines (González-Ortega et al., 2024).
• Eco-Driving/ITS: Inherits core DrivingStyles NN and formulas; extended with federated learning, PCA/autoencoder-based feature selection, additional sensors (OBD voltages, gear position, biometrics), REST/AMQP interfaces conforming to ETSI ITS standards, and privacy-preserving, GDPR-compliant data handling (Meseguer et al., 2016).
• Ride-Sharing: Recommendations for future development include multi-stop/multi-request routing (e.g., VROOM, ORS with contraction hierarchies), backend microservices migration (Docker/Kubernetes), stage automation with geofencing, cloud-native scaling, dynamic pricing (Elmalah et al., 18 Jan 2026).

7. Comparative and Evaluative Insights

GO-DRiVeS, across its variants, is sharply distinguished by context-driven optimization:

• Campus Ride-Sharing (Elmalah et al., 18 Jan 2026):
  • Unified user-driver app, FIFO logic, rapid prototyping and low barrier to entry (no payment system). Current limitations include lack of large-scale matching optimization and manual state transitions.
• Eco-Driving (Meseguer et al., 2016):
  • Real-time, on-device neural inference and feedback, full ITS integration, supports both individual and fleet deployments.
• Physiological Monitoring (González-Ortega et al., 2024):
  • Modular, extensible design; rapid sensor integration, high synchrony with simulators; features adaptable for clinical research or sports contexts.

A plausible implication is that GO-DRiVeS, as a nomenclature, has developed into a suite of mobility and research platforms sharing principles of modularity, real-time analytics, and vertical integration from sensor edge to analytics dashboards. However, the specific instantiation should always be clarified according to research context and technical requirements.