Automotive development fleets depend on the reliable transmission of low-frequency measurementsystem metadata, including hardware identifiers, firmware versions, and calibration states, to support remote diagnostics and over-the-air update workflows. This thesis designs, implements, and evaluates an MQTT-based prototype for metadata transmission from a DSPC-class vehicle sender to a laptop-hosted backend, employing a full-factorial experiment with 1 260 runs across seven independent campaigns and varying TLS transport security (on/off), MQTT QoS level (0/1/2), message rate (0.05/0.1 msg/s), ten payload-padding levels (0–4 096 B), and three network scenarios (baseline, 100 ms delay with jitter, 1 % packet loss). The central empirical finding is that the prototype, which establishes a new MQTT/TCP connection for each metadata publication (a per-message connection design), introduces a delivery reliability constraint when TLS is enabled. In the baseline scenario, the TLS-enabled configuration with QoS produced only 91.6 % successful message persistence in the subscriber-side SQLite database, whereas the TLS-enabled configuration with QoS 1 achieved complete persistence in all evaluated scenarios. Inter-host clock drift between campaigns with TLS disabled and TLS enabled rendered cross-campaign absolute latency comparisons invalid. Latency comparisons are therefore restricted to within-campaign differences between QoS levels, because inter-host clock drift prevents valid absolute comparisons across campaigns. Within this limitation, the baseline scenario indicates an additional latency of approximately 49 ms for QoS 1 and approximately 100 ms for QoS 2 relative to QoS 0, under the unverified assumption of an approximately stable clock offset within each campaign. Whether this assumption actually held cannot be confirmed from the available data. Sender-side CPU and RSS indicate small but measurable TLS context overhead (+0.004 percentage points CPU, +0.16 MB RSS), interpreted as coarse indicators given the 1-second sampling interval. Based on these results, the TLS-enabled configuration with QoS 1 is recommended for the evaluated prototype when transport security and delivery completeness are required within the evaluated laboratory setup and parameter range. This evaluation does not cover persistent MQTT sessions, mutual TLS authentication, or offline store-and-forward buffering.