Dashboard OBD-II para Coche

Descripción

I built the OBD-II Car Dashboard to connect three areas of engineering that are often discussed separately: physical telemetry, an edge application, and cloud-based historical analysis. The system reads live diagnostic information from a vehicle through an ELM327-compatible OBD-II interface, processes it on a Raspberry Pi, presents current values through a local dashboard, and stores selected observations in Azure SQL. The project gave me a concrete way to apply my experience with IoT telemetry, real-time data processing, Python services, web interfaces, cloud architecture, and operational diagnostics to a system where unreliable connections and imperfect sensor data are normal conditions.

The acquisition layer communicates with the vehicle through standardized diagnostic requests while respecting the fact that supported parameters vary by make, model, adapter, and operating state. I treated each reading as a typed observation with a timestamp, source, unit, and quality status rather than passing anonymous numbers directly to the UI. That design comes from data engineering and distributed-systems practice: meaning must travel with the value. Unsupported commands, timeouts, malformed replies, and adapter disconnects become explicit states, allowing downstream components to distinguish no data from a valid zero and preventing a temporary communication issue from becoming misleading telemetry.

The Raspberry Pi acts as an edge boundary. It is close enough to the vehicle to collect data and serve a responsive local experience even when the internet is unavailable. Python handles device communication and normalization, while a Flask service exposes a controlled interface to the dashboard. I separated acquisition frequency from presentation frequency so the UI could remain useful without coupling every browser refresh to a diagnostic request. This reflects my experience with edge-to-cloud synchronization and event-driven systems: components operate at the cadence appropriate to their responsibility, and buffering absorbs differences between a physical source, a user interface, and remote storage.

The React dashboard focuses on comprehension rather than simply displaying every available parameter. Current values need labels, units, clear unavailable states, and visual treatment that does not imply false precision. Historical context can make a reading more meaningful, but it must not distract from the immediate operating state. My experience building web applications influenced the component boundaries and data flow, while accessibility training informed choices such as readable labels, non-color-only status cues, and predictable updates. A telemetry dashboard should help a person understand the system; visual activity alone is not evidence that the interface is communicating well.

Azure SQL stores selected time-series observations for later exploration. I designed the persistence model around efficient append operations, timestamps, parameter identity, and the ability to query a bounded period without pulling the entire history. The edge process can continue its local role if cloud persistence is temporarily unavailable, then resume controlled delivery rather than blocking the dashboard. That approach applies cloud-resilience patterns on a small scale: isolate external dependencies, preserve essential local behavior, retry with limits, and make synchronization status observable. It also creates a foundation for comparing trips, detecting patterns, and evaluating future analytics without claiming that raw diagnostics alone provide a complete assessment of vehicle health.

Security and privacy are part of the architecture because vehicle telemetry can reveal behavior, timing, and location-related patterns even when the project is not collecting explicit location data. I minimize the data selected for storage, keep service interfaces narrow, validate input and output contracts, and treat cloud credentials as external secrets rather than application content. Knowledge from security engineering, identity, cryptography, and compliance-oriented design shaped the trust boundaries between the adapter, edge device, browser, and Azure service. The project is a personal prototype, but the data-flow reasoning is the same discipline required for a production connected-device platform.

Reliability work centered on diagnostics and graceful degradation. Logs distinguish device discovery, adapter communication, parsing, local service behavior, and cloud persistence so failures can be traced to the correct boundary. The dashboard can report stale or unavailable data instead of silently freezing the last value. Tests cover parsing and normalization independently from the physical adapter, while integration checks verify representative request and response flows. These practices reflect my background in production diagnostics and incident readiness: systems should reveal what they know, what they cannot know, and where a failure occurred without requiring invasive debugging during operation.

The finished project demonstrates an end-to-end telemetry architecture in a compact environment. Data moves from a physical machine through a constrained protocol, an edge computer, a web service, a user interface, and a cloud database, with different reliability and security concerns at every step. It allowed me to apply knowledge from Raspberry Pi and Python development, Azure architecture, SQL, real-time systems, secure distributed design, and predictive AI foundations. Most importantly, it reinforced that useful analytics begin with trustworthy acquisition and clear provenance. Before a model can predict anything responsibly, the system must collect, label, transport, and retain observations in a way that can be explained.