Publish-subscribe messaging
MQTT separates the component producing telemetry from the component consuming it. This reduces direct coupling, but requires an explicit interface specification so message meaning and ownership remain clear.
Telematics & Connected Vehicle
MQTT Development Guide
A practical engineering guide to using MQTT for vehicle telemetry, from firmware and TCU integration through LTE transport, cloud ingestion, and engineering dashboards.
Engineering model
How MQTT fits together
MQTT provides a lightweight publish-subscribe model for moving telemetry between connected vehicle software and cloud systems. A useful implementation separates signal production, message exchange, connectivity, cloud API integration, and dashboard presentation so each boundary can be tested independently. The resulting telemetry pipeline depends on an interface specification, the behavior of the TCU or firmware module, available LTE connectivity, and the expectations of the connected vehicle dashboard.
Core concepts
The parts of a practical MQTT setup
Telemetry pipeline
The telemetry pipeline covers data production, MQTT transport, cloud API integration, and presentation in an engineering dashboard. Failures must be localized to one of these stages rather than treated as a single connectivity problem.
Vehicle connectivity
The TCU or firmware module depends on cellular connectivity to move telemetry beyond the vehicle. LTE availability and behavior therefore affect whether MQTT data can reach the cloud API.
Embedded implementation
An ESP32 or other hardware prototype can implement a bounded firmware module that produces telemetry and participates in the MQTT interface before full vehicle integration.
Define the MQTT system boundary
Start by identifying what produces telemetry, what transports it, and what consumes it. This prevents the MQTT connection from becoming an undefined substitute for an interface specification.
A connected vehicle telemetry path commonly contains a firmware module or TCU, an MQTT exchange, a cloud API, and an engineering dashboard. MQTT carries the telemetry between software components, while LTE provides the cellular data path used by the vehicle. The interface specification should describe the responsibility of each component and the information expected at each boundary.
| Component | Primary responsibility | Failure question |
|---|---|---|
| Firmware module | Produce defined vehicle telemetry | Is the expected data produced at the source? |
| TCU | Coordinate vehicle-side connectivity and data upload | Is the TCU connected and attempting the upload? |
| MQTT | Transport telemetry between publishing and consuming components | Is the message exchange operating as specified? |
| Cloud API | Accept or expose telemetry for software integration | Does the cloud interface receive the expected data? |
| Engineering dashboard | Present engineering status or telemetry | Is the dashboard showing current and correctly interpreted data? |
Turn the interface specification into an implementation
The implementation should make the telemetry contract explicit before connectivity is optimized. The same contract should be usable by a firmware module, the cloud API, and the engineering dashboard.
- 01
Identify the telemetry owner
For every value, record whether the firmware module or TCU produces it, and define the expected meaning and update behavior in the interface specification.
- 02
Define the MQTT exchange
Specify which software component publishes each telemetry group and which component consumes it. Keep names and responsibilities stable across development and integration.
- 03
Map telemetry to the cloud API
Define how MQTT data becomes cloud-facing data through the API specification, including the information required by downstream software and the engineering dashboard.
- 04
Implement the bounded firmware capability
On the hardware prototype or target platform, implement acquisition and data upload separately from dashboard presentation so the firmware module remains testable.
An ESP32 can be used as a hardware prototype for exercising the firmware module and MQTT integration. Its Wi-Fi and Bluetooth capabilities do not replace the LTE path used by a TCU, so prototype results should be interpreted against the connectivity path being tested.
Understand the telemetry path in operation
An MQTT development effort is easier to diagnose when the complete path is modeled as a sequence rather than as one connection.
- 01
Produce
The firmware module or TCU obtains the engineering signal or telemetry value according to the interface specification.
- 02
Prepare
The vehicle-side software organizes the value for data upload through the defined MQTT interface.
- 03
Transport
MQTT carries the telemetry while LTE provides the cellular data connection used by the connected vehicle.
- 04
Integrate
The receiving software makes the telemetry available through the cloud API or another defined software boundary.
- 05
Present
The engineering dashboard summarizes the received signals, states, or results for monitoring and troubleshooting.
Test the implementation systematically
Testing should distinguish message production, transport, integration, and presentation. Each test needs an expected observation at the boundary under examination.
- Test the firmware module with known telemetry inputs and verify that the produced data matches the interface specification.
- Test MQTT integration independently from the engineering dashboard so transport behavior is not hidden by presentation logic.
- Test data upload over the intended LTE path, including the conditions represented by the hardware prototype.
- Test the cloud API with the expected telemetry shape and confirm that the receiving software exposes the required information.
- Test the engineering dashboard against known inputs so displayed status and telemetry can be compared with the source values.
| Test focus | Input | Expected evidence |
|---|---|---|
| Firmware module | Known telemetry condition | Produced data matches the interface specification |
| MQTT integration | Defined publish and consume path | Telemetry is available at the receiving boundary |
| LTE data upload | Vehicle-side upload attempt | The expected telemetry reaches the cloud-facing boundary |
| REST API integration | API specification and received telemetry | The software interface exposes the required data |
| Engineering dashboard | Known engineering signals or results | Displayed values correspond to the test input |
Record whether a failure occurs before MQTT, during the MQTT exchange, at the cloud API, or in the engineering dashboard. This classification is more useful than labeling every missing value as an MQTT failure.
Troubleshoot missing or incorrect telemetry
Troubleshooting should move from the source toward the dashboard and use evidence at each interface. Avoid changing several layers at once, because that removes the ability to identify which boundary changed the result.
- 01
Confirm source production
Check whether the firmware module or TCU is producing the expected telemetry and whether the value changes when the underlying engineering condition changes.
- 02
Confirm vehicle-side connectivity
Check the LTE path and determine whether the TCU is able to perform the expected data upload.
- 03
Confirm MQTT exchange
Check whether the defined MQTT publisher and consumer are using the same interface expectations and whether telemetry is visible at the receiving boundary.
- 04
Confirm cloud API integration
Compare the received telemetry with the API specification and check whether the cloud API exposes the expected information.
- 05
Confirm dashboard interpretation
Compare the engineering dashboard with the cloud-facing data and determine whether the issue is presentation, timing, or missing input.
- If the source value is wrong, investigate the firmware module or TCU before changing MQTT integration.
- If the source is correct but no data reaches the cloud-facing boundary, investigate LTE, data upload, and MQTT boundaries separately.
- If the cloud API contains the expected value but the engineering dashboard does not, investigate dashboard integration and interpretation.
- If values appear delayed or incomplete, compare observations across the same defined interval instead of relying on a single dashboard view.
Integrate MQTT with surrounding software
MQTT is one interface in a larger connected vehicle system. Integration work should preserve clear ownership between MQTT, the cloud API, and the engineering dashboard.
Use the API specification and interface specification as the integration contract. MQTT can transport vehicle telemetry, while a REST API can provide a resource-oriented software interface for cloud integration. The two interfaces should not be treated as interchangeable: one describes telemetry exchange, while the other describes how software accesses the resulting information.
- Keep telemetry meaning consistent from the firmware module through the TCU, MQTT exchange, cloud API, and engineering dashboard.
- Separate connectivity status from telemetry validity; LTE availability does not prove that the produced data is correct.
- Keep the engineering dashboard focused on engineering signals, states, or results rather than using it as the only diagnostic observation point.
- Use the hardware prototype to expose interface assumptions before integrating the full connected vehicle path.
Monitor a telemetry pipeline
Monitoring should show enough of the path to distinguish source, connectivity, transport, integration, and presentation conditions.
| Observation area | Useful engineering question | Interpretation |
|---|---|---|
| Firmware module | Is the expected telemetry being produced? | A source problem exists if the defined value is absent or incorrect before upload. |
| TCU and LTE | Is the vehicle connected for data upload? | A connectivity problem may prevent the telemetry from leaving the vehicle. |
| MQTT exchange | Is telemetry available at the receiving boundary? | A transport or interface problem may exist if source data is not observed there. |
| Cloud API | Is the expected telemetry exposed to software? | An integration problem may exist even when MQTT transport is operating. |
| Engineering dashboard | Does the displayed state match the source and cloud-facing data? | A presentation or interpretation problem may exist after successful ingestion. |
The engineering dashboard should support monitoring, not replace evidence from the telemetry pipeline. Correlating dashboard observations with source and cloud API observations makes troubleshooting more precise.
Engineering pitfalls
Common mistakes
Treating MQTT as the entire system
MQTT only describes one messaging boundary. A telemetry failure may instead originate in the firmware module, TCU, LTE connection, cloud API, or engineering dashboard.
Skipping the interface specification
Without an explicit interface specification, producers and consumers can appear connected while disagreeing about telemetry meaning or expected data.
Using dashboard output as the only evidence
A missing dashboard value does not identify the failing layer. Check source production, data upload, MQTT exchange, and cloud API integration separately.
Assuming prototype connectivity represents TCU connectivity
An ESP32 hardware prototype can exercise MQTT integration, but its Wi-Fi and Bluetooth capabilities do not demonstrate the LTE behavior of a TCU.
Changing several layers during troubleshooting
Changing the firmware module, MQTT integration, cloud API, and dashboard together makes the observed improvement difficult to attribute. Isolate one boundary at a time.
Confusing data upload with valid telemetry
Successful upload only indicates that data moved through part of the path. The value can still be incorrect, incomplete, or incorrectly presented.
FAQ
MQTT questions
- What should be specified before implementing MQTT telemetry?
- Define the producing component, consuming component, telemetry meaning, data upload responsibility, and cloud-facing integration in the interface specification and API specification.
- Does a working MQTT connection prove that the telemetry pipeline works?
- No. The firmware module or TCU may produce incorrect data, LTE may prevent upload, the cloud API may omit the data, or the engineering dashboard may display it incorrectly.
- How should MQTT be tested with a hardware prototype?
- Use the hardware prototype to test the firmware module, MQTT exchange, and expected telemetry observations separately. Compare each result with the interface specification rather than relying only on dashboard output.
- Where does LTE fit in an MQTT implementation?
- LTE is the cellular data connectivity used by the TCU or connected vehicle. MQTT defines the telemetry messaging boundary, while LTE affects whether the vehicle can reach the surrounding software system.
- When should a REST API be used alongside MQTT?
- Use MQTT for the defined telemetry exchange and a REST API for resource-oriented cloud or software integration when that boundary is part of the API specification. They serve different interface responsibilities.
Engineering support
Discuss an MQTT Project
Need a focused MQTT implementation, telemetry pipeline, or engineering dashboard? Get practical support across firmware modules, connectivity integration, testing, and troubleshooting.