Edge-Cloud V2X Telemetry Pipeline and Operator Dashboard for Site-Level Supervisory Monitoring of Autonomous Mobile Units in Outdoor Industrial Sites

Featured Application

The proposed platform can be applied to site-level monitoring, reproducible telemetry logging, and operational decision support for autonomous mobile units deployed in container terminals, construction yards, and other harsh outdoor industrial sites.

Abstract

Outdoor industrial sites, including logistics terminals, construction yards, and civil infrastructure worksites, increasingly require supervisory systems for monitoring autonomous mobile units under variable wireless and operational conditions. This study presents an edge-cloud telemetry platform that connects V2X on-board and roadside units to a normalized data pipeline and an operator dashboard. The architecture assigns frame reception and data validation to the edge layer, while cloud services perform stream ingestion, storage, querying, and visualization using a Kafka-Elasticsearch-Grafana stack. A fixed supervisory schema was defined for position, heading, speed, mission state, battery level, and error flags so that virtual fields used in early validation can later be replaced by measured signals without changing downstream interfaces. Physical field validation was conducted using a single test vehicle in a construction-site emulation environment to evaluate communication continuity and dashboard refresh behavior. Multi-unit applicability was examined at the architecture and schema levels, and a preliminary payload-level capacity estimate was derived using the telemetry frequency and payload-length assumptions. Under the tested site conditions, the system maintained continuous reception and visualization over an approximately 700 m distance from the RSU-side reference location. The measured end-to-end display delay averaged 0.78 s, with a standard deviation of 0.059 s and a maximum of 0.96 s. Under a 10 Hz status-message condition, the estimated pure-payload traffic was approximately 23 kbps per mobile unit. These results indicate that V2X-based edge-cloud telemetry can provide a practical baseline for supervisory monitoring in outdoor industrial sites, while simultaneous multi-vehicle validation, detailed network-load evaluation, and long-term field testing remain necessary future work.

1. Introduction

Outdoor industrial sites, including large-scale civil infrastructure projects, earthmoving areas, road construction zones, construction yards, and logistics terminals, are being transformed from equipment-centered workplaces into data-intensive operating environments. Autonomous mobile units, unmanned transporters, and robotic work machines are expected to move simultaneously through shared paths, temporary work zones, unpaved or partially paved routes, and safety-critical areas. In such sites, autonomy performance alone is not sufficient. Operators must also understand the spatial distribution, motion state, mission progress, and abnormal events of multiple assets in near real time.

Figure 1 presents representative outdoor industrial environments in which supervisory monitoring of multiple mobile assets is required. Large-scale civil infrastructure sites contain temporary work zones, material storage areas, and heterogeneous construction equipment. Earthmoving operations involve repeated interactions among excavators, dump trucks, rollers, and other mobile machines under changing ground conditions. Road construction sites further include temporary traffic interfaces, shifting work boundaries, and surrounding obstacles. These characteristics make it difficult to apply a site-specific and locally fixed monitoring system to different projects without repeated integration.

This manuscript extends and restructures a previous domestic study on a V2X-based supervisory software platform for port and construction-site mobilities [1]. Compared with the previous domestic article, the present manuscript newly formalizes the edge-cloud deployment model, defines the supervisory schema as an interface-governance mechanism, adds a preliminary payload-level capacity estimate, and discusses the operational distinction between supervisory display latency and safety-critical control latency. The implementation results are retained and transparently cited, while the narrative is reorganized around deployability in heterogeneous outdoor industrial sites.

Connected and automated vehicles have been widely studied in the context of road transportation, where vehicle-to-everything (V2X) communication provides a standardized means for exchanging safety, mobility, and infrastructure messages [2,3,4]. Message dictionaries such as SAE J2735 and cooperative-awareness message standards provide a basis for structured mobility-state exchange [5,6], while cellular V2X service requirements define communication support for enhanced V2X scenarios [7]. However, the direct adoption of road-oriented V2X concepts in outdoor industrial worksites remains non-trivial because these sites contain unstructured routes, temporary obstacles, equipment-specific missions, heterogeneous machines, and frequent changes in work plans.

Supervisory monitoring for outdoor autonomous mobile units has different requirements from conventional single-vehicle remote control. It must handle multiple mobile units, preserve raw communication logs, provide map-based and time-series views, and remain flexible when some fields are initially unavailable from physical sensors. The need for scalable edge-cloud robotics and distributed computation has been discussed in cloud robotics and edge-computing studies [8,9,10], but practical field systems still require a clear division of functions among the on-board unit, roadside unit, edge computer, cloud storage layer, and operator dashboard.

Recent studies on distributed software systems and industrial IoT architectures also support the use of modular data-ingestion, storage, and visualization layers for monitoring-oriented applications. Performance-evaluation frameworks for distributed systems emphasize the importance of decomposing response time and observing abnormal behavior in production-like software environments [11]. Industrial IoT implementations have also adopted layered architectures in which sensing, networking, middleware, and application layers are separated, and Grafana-based web interfaces are used for remote visualization [12]. These studies indicate that open and modular software stacks can improve traceability, maintainability, and accessibility in monitoring systems. In this context, the present study adopts Kafka, Elasticsearch, and Grafana as reusable software components for stream ingestion, time-series storage and querying, and operator-facing visualization, respectively.

Related research has also addressed adjacent topics such as ITS-G5 and C-V2X communication performance, fleet management and task allocation, digital twins for autonomous mobile robots, and software-defined vehicles. ITS-G5 and C-V2X studies mainly focus on vehicular communication behavior and safety-message exchange [13,14,15], while fleet-management studies address assignment, coordination, and mission planning for multiple robots [16,17]. Digital-twin and software-defined-vehicle studies further emphasize virtual representation, replayable data, software abstraction, and virtualization-based deployment for future autonomous mobility systems [18,19]. However, these research streams usually address communication performance, task allocation, simulation, or vehicle software abstraction separately. The remaining gap is a deployable supervisory telemetry pipeline that connects field-side V2X reception, edge preprocessing, normalized records, cloud-side ingestion and storage, and a web-based operator dashboard for heterogeneous outdoor industrial sites.

A second limitation in many site-level monitoring systems is the dependence on local, vendor-specific infrastructure. When every site requires a dedicated server, local dashboard, and device-specific interface, system relocation or fleet reconfiguration imposes repeated integration costs. A more reusable architecture is to keep the storage, query, and visualization functions in the cloud while moving only the edge data-collection layer to the worksite. This approach allows the same data schema and dashboard logic to be reused across different field environments.

The contribution of this study is threefold. First, an edge-cloud V2X telemetry architecture is proposed for outdoor industrial sites where mobile units, worksite layouts, and communication conditions are heterogeneous. Second, a normalized supervisory schema and data pipeline are implemented so that measured, virtual, and future integration fields can be handled through stable downstream interfaces during staged development. Third, the platform is evaluated through a single-vehicle physical field test and a preliminary payload-level capacity estimate. The field test quantifies communication continuity, dashboard refresh behavior, and operator-visible display delay under the tested site conditions, whereas the capacity estimate provides a lower-bound reference for future multi-unit deployment planning rather than a full validation of large-scale simultaneous operation.

To clarify the originality of the present manuscript relative to previous studies,

Table 1. Comparative positioning of the present manuscript relative to prior research streams.

Research Stream	Typical Focus	Remaining Gap	Position of This Study
Previous domestic V2X supervisory platform [1]	V2X-based dashboard implementation for port and construction-site mobilities	Limited generalization of architecture, schema, and scalability interpretation	Formalizes the previous implementation as a reusable edge-cloud telemetry pipeline
Cloud robotics and edge computing [8,9,10]	Distributed computation, cloud-assisted robotics, and edge offloading	Limited focus on V2X telemetry and field dashboard deployment	Separates field-side V2X reception/edge preprocessing from reusable cloud storage and dashboard services
Distributed systems and industrial IoT monitoring [11,12]	Modular ingestion, middleware, storage, and visualization	Not specialized for mobile-unit V2X messages or outdoor industrial sites	Applies a Kafka-Elasticsearch-Grafana stack to normalized supervisory telemetry
ITS-G5, C-V2X, and V2X communication studies [13,14,15]	Communication performance and safety-message exchange	Mostly road-oriented or communication-centric	Adapts V2X data flow to site-level supervisory monitoring in outdoor industrial environments
Fleet management and task allocation [16,17]	Assignment, coordination, and mission planning for multiple robots	Often assumes an existing monitoring and communication layer	Provides a scheduler-ready supervisory interface while limiting validation to telemetry monitoring
Digital twin and software-defined vehicle studies [18,19]	Virtual representation, replay, optimization, and software abstraction	Less focused on deployable field-to-cloud telemetry pipelines	Provides logged and normalized field records that can support future replay, digital-twin, or SDV integration

summarizes the positioning of the proposed platform against representative research streams.

2. Materials and Methods

2.1. Operational Requirements and Design Principles

The design target was a supervisory monitoring platform rather than an autonomous-driving controller. Therefore, the primary system requirement was to provide operators with timely, reliable, and interpretable information about multiple mobile units. The dashboard refresh target was set to within 1 s from the operational viewpoint, while the edge telemetry ingestion frequency was set to 10 Hz to preserve sufficient temporal resolution for post-operation analysis.

The second requirement was reproducibility. The platform had to store raw frames, parsed records, normalized messages, and time-series query results so that communication degradation, packet loss, latency increase, or abnormal state changes could be reviewed after a test. This requirement is important in outdoor field experiments because incomplete logs often prevent root-cause analysis.

The third requirement was incremental field expansion. In early validation, not all variables are available from physical sensors or controller interfaces. For example, battery level, mission identifier, and some error codes may be simulated at the beginning of development. The platform therefore fixes field names and data types from the first integration stage. When measured data becomes available, the data source can be replaced without modifying the storage index, dashboard query, or visualization panel.

Table 2. System-level requirements and implementation policy.

Requirement	Target	Implementation Policy
Operational refresh	Operator-visible state update within 1 s	Use summarized dashboard queries while retaining high-rate telemetry in storage
Telemetry acquisition	10 Hz status-message ingestion	Perform edge parsing, validation, and controlled streaming to the cloud
Log reproducibility	Raw and normalized records	Store raw V2X frames and normalized JSON records with timestamps
Field extensibility	Measured and virtual fields in one schema	Preserve field names and types; replace only data sources during maturation
Multi-site deployment	Reusable cloud layer	Move only the edge collector to each site while retaining cloud services

summarizes the system-level requirements and corresponding implementation policies used to guide the design of the proposed supervisory monitoring platform.

2.2. Edge-Cloud Architecture

Figure 2 shows the cloud-based development platform used for the supervisory system. The architecture follows a layered model: containerized services are hosted in the cloud, Kubernetes-based orchestration is used for deployment and scaling [20], and Docker-based software packaging is used to maintain application dependencies [21]. This structure separates the field-side V2X reception layer from the cloud-side storage and dashboard layer.

The complete data-flow architecture is shown in Figure 3. A mobile unit transmits V2X messages through an on-board unit (OBU), and a roadside unit (RSU) receives the field-side messages. The edge computer logs the received frames, parses the message payload, validates field ranges, normalizes the records, and forwards JSON-formatted supervisory data to the cloud layer. The cloud layer then performs streaming ingestion, time-series indexing, and visualization.

The field-to-cloud division was selected for practical deployment. V2X reception and parsing must remain close to the physical worksite because antenna placement, propagation environment, and device configuration change from site to site. In contrast, storage, dashboard configuration, and query logic can be reused across sites if the normalized data schema is maintained. This provides a scalable alternative to installing a complete local monitoring system at every field location.

Table 3. Communication and processing roles by system segment.

Segment	Main Function	Data Format	Operational Note
OBU to RSU	Transmit and receive V2X messages	Standard or device-specific raw frame	Field-side mobility and communication data
RSU to Edge	Forward received data and quality information	Raw frame and reception log	Used for traceability and communication diagnosis
Edge to Cloud	Parse, normalize, validate, and stream data	JSON supervisory record	10 Hz ingestion target with load control
Cloud to Dashboard	Index, query, aggregate, and visualize data	Time-series index and dashboard query	Operator display update target within 1 s

summarizes the communication and processing roles assigned to each system segment, from field-side V2X message transmission to cloud-side dashboard visualization.

2.2.1. Field-Test Topology and Deployment Configuration

Figure 4 illustrates the physical and logical deployment topology used in the field test. Unlike the logical data-flow architecture in Figure 3, this topology clarifies the actual relationship among the test vehicle, V2X communication devices, edge computer, cloud-side services, and operator dashboard.

The field-side configuration consisted of a single test vehicle equipped with a V2X on-board unit (OBU) and a roof-mounted antenna, a roadside unit (RSU) installed near the test site, and an edge computer connected to the RSU-side network. The RSU was installed on the rooftop of a three-story building near the test site, and the RSU antenna height was approximately 10–12 m above ground level, estimated from the rooftop installation height. The OBU antenna was mounted on the roof area of the test vehicle, with an estimated antenna height of approximately 1.5–1.8 m above ground level depending on the vehicle body height. The cloud-side configuration consisted of containerized services for stream ingestion, storage, querying, and dashboard visualization.

The OBU transmitted mobility-state messages from the moving test vehicle to the RSU. The RSU received the V2X frames through the fixed rooftop antenna and forwarded the received data to the edge computer through an IP/Ethernet connection. The edge computer performed raw-frame logging, message parsing, field validation, timestamp assignment, and JSON normalization. The normalized supervisory records were then forwarded to the cloud-side data platform. In the present implementation, Kafka, Elasticsearch, object storage, and Grafana were deployed as cloud-side or cloud-connected services, whereas the edge computer was used only for field-side reception, preprocessing, and forwarding. More specifically, Grafana was used as a self-managed Grafana OSS web dashboard service connected to the cloud-side data platform. The dashboard was accessed by the operator through a standard web browser using the host address of the cloud-side Grafana service. It was not deployed on the vehicle, OBU, RSU, or edge computer.

The field validation was conducted using a single test vehicle. Therefore, the experiment verifies the V2X telemetry pipeline and operator-dashboard operation under the tested field configuration, but it does not represent simultaneous multi-vehicle operation.

Table 4. V2X, Edge, Cloud hardware and software configuration used in the field test.

Component	Configuration Used in This Study
Test platform	Single test vehicle used as a moving V2X OBU platform
OBU	THEUS C-V2X OBU, product code ETF-PRO-OC02 (Ettifos Co., Ltd., Seongnam-si, Republic of Korea)
OBU radio interface	LTE PC5-based C-V2X communication
OBU V2X chipset and module	Qualcomm SA515M V2X solution with Quectel AG550Q module (Quectel Wireless Solutions Co., Ltd., Shanghai, China)
OBU processor and operating system	NXP i.MX 8M Plus processor (NXP Semiconductors, Eindhoven, The Netherlands), 1.6 GHz quad-core ARM Cortex-A53 + Cortex-M7 (Arm Limited, Cambridge, UK); Linux operating system
OBU memory and storage	4 GB LPDDR4 RAM and 16 GB eMMC flash storage
OBU GNSS and sensors	u-blox ZED-F9R GNSS (u-blox, Thalwil, Switzerland); magnetometer, 6-axis IMU, and barometer integrated in the OBU platform
OBU antenna configuration	Roof-mounted V2X/GNSS antenna configuration on the test vehicle; RF connectors based on FAKRA interface
OBU frequency and bandwidth	5.855–5.875 GHz operating frequency band and 20 MHz bandwidth
OBU transmit power	+20 dBm typical transmit power
OBU antenna height	Approximately 1.5–1.8 m above ground level, estimated from the test-vehicle roof height
RSU	THEUS C-V2X RSU, product code ETF-PRO-RC01 (Ettifos Co., Ltd., Seongnam-si, Republic of Korea)
RSU radio interface	LTE PC5-based C-V2X communication
RSU V2X chipset and module	Qualcomm SA515M V2X solution with Quectel AG550Q module (Quectel Wireless Solutions Co., Ltd., Shanghai, China)
RSU processor and operating system	NXP i.MX 8M Plus processor (NXP Semiconductors, Eindhoven, The Netherlands), 1.6 GHz quad-core ARM Cortex-A53 + Cortex-M7 (Arm Limited, Cambridge, UK); Linux operating system
RSU memory and storage	4 GB LPDDR4 RAM and 16 GB eMMC flash storage
RSU GNSS	u-blox ZED-F9P GNSS module (u-blox, Thalwil, Switzerland); horizontal CEP less than 1.5 m
RSU network interface	One Ethernet port, RJ45
RSU installation	Fixed RSU installation at an elevated location near the test site
RSU antenna configuration	Two C-V2X/LTE antenna ports and one GPS antenna port, N-type interface
RSU frequency and bandwidth	5.855–5.875 GHz operating frequency band and 20 MHz bandwidth
RSU transmit power	+20 dBm typical and +23 dBm maximum transmit power
RSU antenna height	Approximately 10–12 m above ground level, estimated from the rooftop installation height of the three-story building
Edge computer	Lenovo ThinkPad E16 Gen 3, model 21SR002CKD (Lenovo Group Ltd., Beijing, China)
Edge computer processor	Intel Core Ultra 5 225H processor (Intel Corporation, Santa Clara, CA, USA), 14 cores/14 threads, maximum P-core turbo frequency up to 4.9 GHz
Edge computer memory and storage	16 GB DDR5 memory and 512 GB M.2 SSD
Edge computer operating system	Windows 11 Pro
Edge-side functions	RSU data reception, raw-frame logging, BSM-compatible message parsing, field validation, timestamp assignment, JSON normalization, and forwarding to the cloud-side platform
Message format	Raw V2X frame parsed into normalized JSON-type supervisory records
Telemetry frequency	10 Hz status-message ingestion target
Payload length used for capacity estimation	2304 bit per message
Cloud-side deployment	Containerized data platform for stream ingestion, storage, querying, and dashboard visualization
Streaming layer	Apache Kafka v3.7.0 (Apache Software Foundation, Wakefield, MA, USA)
Storage and query layer	Elasticsearch v8.13.4 and object storage (Elastic N.V., Amsterdam, The Netherlands)
Dashboard layer	Self-managed Grafana OSS v11.0.0 web dashboard accessed through a standard web browser (Grafana Labs, New York, NY, USA)
Dashboard hosting	Cloud-side or cloud-connected self-managed Grafana service; the dashboard was not hosted on the vehicle, OBU, RSU, or edge computer
Number of test runs	Five repeated runs along the same route
Number of collected messages	Not separately counted; continuous reception was confirmed through RSU-side logs and dashboard visualization.
Communication-stability criterion	Continuous RSU-side reception and dashboard visualization without operator-visible interruption within the tested route and distance

summarizes the V2X & Edge hardware and software configuration used in the field test.

2.2.2. Measurement Procedure and Experimental Scope

The field validation was conducted using a single test vehicle. The experiment was designed to verify whether V2X messages transmitted from a moving OBU could be received by the RSU, processed by the edge computer, forwarded to the cloud-side data platform, and visualized through the Grafana dashboard under outdoor construction-site conditions. Therefore, the physical field test validates the telemetry pipeline and dashboard operation under the tested configuration, but it does not represent simultaneous multi-vehicle operation.

The same route was repeated five times to evaluate operator-visible dashboard update behavior. During each run, the RSU-side reception screen was monitored to confirm raw V2X frame reception and parsed message output. The edge computer logged the received frames, converted them into normalized supervisory records, and forwarded them to the cloud-side platform. The cloud-side services then indexed the telemetry records and supplied query results to the dashboard.

The end-to-end display delay was evaluated at the operating system level. In this study, the delay was defined as the time difference between V2X message reception at the edge-side processing environment and the reflection of the corresponding telemetry state in the operator dashboard. Because synchronized timestamps were not assigned at every internal stage of the RSU, edge, streaming, storage, and dashboard pipeline, the reported delay should be interpreted as an operator-visible display delay rather than a decomposed communication or processing latency. Stage-level latency decomposition, including RSU-to-edge, edge-to-stream, stream-to-storage, and storage-to-dashboard delays, remains a subject of future work.

Communication continuity was evaluated within the available route and installation conditions of the test site. The reported approximately 700 m distance represents the maximum verified distance between the RSU-side reference location and the farthest observed OBU position under the tested site condition. It should therefore be interpreted as a site-specific field-test result rather than a general V2X communication-range validation. Previous V2X field and communication-performance studies have also shown that communication quality depends on vehicle speed, site geometry, installation conditions, and scenario configuration [13,14,15].

2.3. V2X Data Acquisition and Normalization

The normalized schema was designed to satisfy four functions: map visualization, motion-state monitoring, time-series analysis, and replayable logging. The minimum measured fields are the device identifier, timestamp, latitude, longitude, heading, and speed. Additional fields such as battery level, mission identifier, operation time, and error codes are included to support practical operations and future scheduler integration.

Timestamp values are represented in an ISO 8601-compatible string format to maintain consistency across logs, storage records, and dashboard queries. Position, heading, and speed are represented as numeric fields so that map panels, direction markers, and gauge panels can use the same values without type conversion. Missing values are handled through a default-value or last-value-hold policy, but missing or abnormal conditions are also recorded through error flags to prevent the operator interface from hiding data-quality issues.

The following schema is intentionally compact. It is not a complete vehicle-control message; instead, it is the minimum operational record required by the supervisory layer. This distinction reduces the coupling between the dashboard and the vehicle controller while preserving the data required for field evaluation.

Table 5. Normalized supervisory input schema.

Field	Type	Role in Dashboard	Policy
device_id	String	Identifies each mobile unit	Mandatory
timestamp	String	Time-series query and replay	ISO 8601-compatible format
latitude, longitude	Float	Map location and trajectory	Mandatory measured values
heading	Float	Marker orientation	Range validation and last-value hold if missing
speed	Float	Gauge and time-series panel	Unit normalization before storage
battery_level	Float or integer	Operational status	Virtual field allowed in early validation
mission_id	String	Mission timeline and scheduler linkage	Virtual or measured field
error_codes	Array or string	Abnormal-state display and filtering	Records missing and abnormal conditions

summarizes the normalized supervisory input schema used for dashboard visualization, time-series storage, and replayable logging.

2.4. Streaming Storage and Dashboard Implementation

The streaming layer is implemented using Apache Kafka because log-oriented streaming systems are suitable for collecting and delivering high-rate operational data with low latency [22]. The storage and query layer are implemented with Elasticsearch, which provides JSON-based indexing and time-oriented searches [23]. Grafana is used as the operator-facing visualization layer because it supports time-series panels, map-oriented visualization through data sources and plug-ins, and dashboard composition for operational monitoring [24,25].

A practical advantage of this software stack is that Apache Kafka 3.7.0, Elasticsearch 8.13.4, and Grafana OSS 11.0.0 are widely used open-source or open-core software components with extensive documentation, ecosystem support, and practical applicability in monitoring-oriented systems. Their use reduces dependence on vendor-specific monitoring software and allows the telemetry ingestion, storage, query, and visualization layers to be reconfigured or redeployed across different field sites. This property is important for outdoor industrial applications because the field-side V2X devices, antenna installation, and edge configuration may vary by site, whereas the cloud-side data pipeline and dashboard logic should remain reusable.

The dashboard was not treated as a static screen. Instead, it was implemented as a set of panels that can be revised when field-test requirements change. This design choice is important for empirical development because an outdoor-site operator often requests new summary fields, additional filters, or a different visual order after observing the first trial.

Before constructing the operator dashboard, cloud-side data-management and platform-operation interfaces were configured to verify whether telemetry data could be stored, traced, and managed across the proposed pipeline. As shown in Figure 5, Elasticsearch was used to inspect indexed telemetry records and verify field-level schema behavior, object storage was used to retain raw data and intermediate files for traceability, and the Kubernetes dashboard was used to monitor the operational status of platform workloads and services. A test set of 2000 JSON-type mobility records was inserted according to the required supervisory fields, and the extract–transform–load (ETL) process was verified to confirm that field additions, modifications, and deletions could be handled without disrupting the general pipeline structure.

2.5. Preliminary Scheduler-Interface Definition

Outdoor industrial sites require more than a passive state display. Mobile units may execute transport, waiting, recovery, inspection, and charging missions under constraints such as one-way paths, geofenced areas, work spots, speed limits, and resource availability. In this study, these operational requirements were considered at the interface-definition level to support future scheduler-supervisory integration. The experimentally validated scope of the present work was limited to telemetry acquisition, storage, visualization, and field verification.

The scheduler itself is outside the experimental scope of this paper. However, the interface was designed to remain algorithm-independent so that future mission-sequence information and telemetry feedback can be connected to the supervisory platform without modifying the communication and storage layers. Classical multi-robot task-allocation studies show that task allocation and trajectory planning should be separable from the physical communication layer when multiple robots or mobile units are operated [16,17]. Following this principle, the platform defines a preliminary set of interface fields for job definition, operational constraints, mobile-resource status, assignment results, and monitoring feedback.

Table 6. Preliminary interface fields for future scheduler-supervisory integration.

Interface Element	Example Interface Variables	Use in Supervisory Operation
Job definition	job_class, dispatch_priority	Defines the work request and dispatch importance
Operational constraint	allowable_time_range, velocity_limit, operational_boundary, resource_availability	Restricts assignment and route execution
Mobile resource	unit_identifier, operating_mode, readiness_status	Represents mobile-unit readiness and current mode
Assignment result	assigned_order, expected_arrival_time	Transfers assigned mission sequence to the dispatcher
Monitoring feedback	location, orientation, velocity, energy_status, fault_flags	Provides feedback for monitoring, future scheduler integration, and event handling

summarizes the preliminary interface fields required for future scheduler-supervisory integration.

The scheduler-related fields were included as a preliminary interface design element. In the present implementation, the 10 Hz telemetry stream was used for state monitoring and dashboard visualization, not for closed-loop task reassignment or autonomous replanning. A future mission dispatcher may receive assignment results through a REST interface and forward mission sequences to mobile units or vehicle controllers [26]. Conversely, the telemetry stream may provide state feedback to the scheduler or operator. However, this bidirectional scheduler-supervisory operation was not experimentally validated in the present study.

2.6. Payload-Level Traffic Estimation Method for Preliminary Capacity Planning

In addition to the physical V2X field test, a payload-level traffic estimation was defined to estimate the minimum telemetry traffic required when the same supervisory schema is extended to multiple mobile units. This analysis was not treated as an additional wireless field experiment; rather, it was formulated as a lower-bound capacity-planning method based on telemetry frequency, payload length, and fleet size.

For a fleet of N mobile units, the pure-payload data rate was calculated as R_N = N × f_s × L_p, where f_s is the telemetry frequency and L_p is the payload length per message. IP/TCP overhead, Kafka headers, retransmission, encryption or TLS processing, synchronization traffic, packet loss, network congestion, Elasticsearch indexing cost, and Grafana query load were excluded from this calculation. Therefore, the resulting values represent minimum payload-level requirements rather than complete wireless network-load measurements.

3. Results

3.1. Dashboard Composition

The implemented dashboard consists of multiple panels for map-based monitoring, status summarization, time-series inspection, and operational-history analysis. Because the dashboard can be extended or rearranged according to field-test requirements, this section presents representative panels selected to illustrate the main supervisory functions of the proposed platform. The dashboard supports both fleet-level supervision and selected-unit inspection by integrating mobility position, route traces, instantaneous status, and selected operational indicators without requiring manual access to raw logs.

At the fleet-supervision level, the dashboard provides a map-based overview of the operating area, where mobile units are displayed with their latest positions and route traces. This view enables the operator to understand the spatial distribution of assets and inspect the movement pattern of a selected unit within the monitored site. In addition to the map view, the dashboard includes a gauge-type panel for instantaneous speed display and site-level monitoring panels, as shown in Figure 6.

Figure 7 shows the fleet-level summary table configured to display representative supervisory fields, including mobile-unit identifier, accumulated operation time, speed, temperature, mission state, battery level, and payload weight. In the implemented example, mission states such as transport, collection, standby, and inspection were visualized with distinct markers to improve operator readability. Battery status was also presented as a compact visual indicator to support rapid condition assessment across multiple units.

To clarify the interpretation of the dashboard fields,

Table 7. Classification of dashboard fields according to data-source status in the implemented validation.

Dashboard Field	Data-Source Status in This Study	Role in Dashboard
device_id/mobile-unit identifier	Assigned or parsed from the device-side record	Unit identification and ID-based filtering
timestamp	Generated during message processing	Time-series indexing, dashboard query, and replay
latitude, longitude	Measured from the V2X/GNSS-based mobility-state message	Map visualization and trajectory display
heading/orientation	Measured from the mobility-state message when available	Marker orientation and direction-history display
speed	Measured or parsed from the mobility-state message	Gauge display and time-series monitoring
battery level	Virtual or scenario-based field in the present validation	Demonstration of operational-status visualization
mission state/mission_id	Virtual or predefined scenario field in the present validation	Demonstration of mission-state display and future scheduler linkage
operation time	Derived or scenario-based monitoring variable	Operational-history visualization
payload weight	Virtual or scenario-based field in the dashboard example	Future integration with logistics or construction-workload data
error codes/fault flags	Virtual or event-flag field in the present validation	Abnormal-state display and future diagnostic integration

classifies the representative variables according to their data-source status in the implemented validation. The dashboard was designed to accept measured, assigned, derived, and virtual fields through the same normalized schema. In the present field test, position-related variables were obtained from the V2X/GNSS-based mobility-state messages, whereas some operational variables, such as mission state, battery level, payload weight, and fault flags, were included as virtual or scenario-based fields to verify dashboard extensibility for future integration.

For selected-unit inspection, the dashboard supports ID-based filtering and focused visualization of a single mobile unit. In this mode, the operator can examine the detailed position history of the selected asset on the map while simultaneously inspecting associated scalar indicators such as speed or battery state. This two-level design enables the dashboard to be used both for broad supervisory monitoring and for more focused investigation of a specific mobile unit.

3.2. Time-Series and Operational-History Monitoring

In addition to instantaneous status display, the dashboard was configured to support time-series monitoring and operational-history inspection. Figure 8 shows representative time-series panels implemented for this purpose.

The accumulated operation-time panel in Figure 8a compares the operating-duration trends of multiple mobile units over the selected monitoring interval. This view allows operators to identify relative utilization differences among units and detect assets with unusually long or short operating histories.

The movement-direction history panel in Figure 8b visualizes categorical heading or direction states over time. Instead of showing only the latest direction value, this panel provides a temporal record of directional changes, enabling operators to inspect repeated movement patterns, route-following behavior, and abnormal directional transitions in constrained outdoor sites.

The selected-unit battery-level panel in Figure 8c displays the state-of-charge history of a selected mobile unit. This panel supports operational diagnosis by showing whether the battery level remains stable, decreases gradually, or exhibits discontinuous changes during the monitoring period. Together, these time-series panels complement the map and summary-table views by enabling post-operation inspection of usage, movement, and energy-state history.

3.3. Field-Test Configuration

The field evaluation was conducted using a single test vehicle and focused on communication continuity and operator-visible dashboard update behavior. The test was designed to verify whether V2X messages transmitted from a moving OBU could be received by the RSU, processed by the edge computer, forwarded to the cloud-side data platform, and displayed through the operator dashboard under outdoor construction-site conditions. Therefore, the experiment validates the telemetry pipeline and dashboard operation under the tested configuration, but it does not represent simultaneous multi-vehicle operation.

The test vehicle was equipped with a V2X OBU configuration consisting of an externally mounted antenna and an in-vehicle OBU unit. The OBU antenna was attached to the roof area of the test vehicle to improve field-side message transmission and reception, while the OBU main unit was operated inside the vehicle. The RSU was installed at an elevated location near the test site to receive V2X messages from the moving vehicle and forward them to the edge-side processing environment. The edge computer then received the RSU data, performed message parsing and normalization, and transmitted the normalized telemetry records to the cloud platform. Figure 9 shows the field-test installation conditions, including (a) the OBU antenna mounted on the test vehicle, (b) the OBU main unit, and (c) the RSU setup.

The edge environment was monitored during the test to verify whether mobility data were continuously received and forwarded to the cloud database. Figure 10 shows the edge-side reception screen, where raw V2X frames and parsed BSM information were monitored during the field test. The purpose of this test was not to compare wireless technologies or validate fleet-scale operation, but to confirm that V2X messages could be received, decoded, normalized, and converted into a usable supervisory stream under the proposed edge-cloud architecture.

Figure 11 shows the representative civil construction-site map used as the field-test environment. The site was selected to reflect an unstructured outdoor worksite rather than a laboratory-only test space. It includes open operating areas, curved internal roads, irregular work zones, surrounding slopes, local structures, and practical constraints for antenna placement and communication coverage. These characteristics are consistent with typical civil engineering worksites in which mobile equipment must operate under changing route, visibility, and wireless-propagation conditions. Although the available area limited the maximum measurable communication range, the site provided a realistic basis for verifying whether the proposed V2X-based telemetry pipeline could support field-side reception and operator-visible monitoring in an outdoor industrial environment.

3.4. Site-Specific Communication Continuity and Dashboard Update Behavior

The field test confirmed continuous reception and dashboard visualization over an approximately 700 m distance from the RSU-side reference location under the tested site conditions. The measurement could not be extended to 1 km because of the physical area limitation of the test site. Therefore, the reported distance should be interpreted as a site-specific field-test result rather than a general validation of V2X communication range. Within the available route and installation conditions, the position marker and trajectory were continuously reflected in the dashboard, and the operator-visible update interval remained within the 1 s target.

The end-to-end display delay was evaluated by repeating the same route five times and comparing the time from V2X message reception at the edge-side processing environment to dashboard reflection at the operational-system level. The measured average delay was 0.78 s, the standard deviation was 0.059 s, and the maximum measured delay was 0.96 s. These values indicate that the proposed pipeline satisfied the second-level supervisory monitoring target under the tested operating condition. However, they should not be interpreted as decomposed communication or processing latency values for individual pipeline stages.

Table 8. Summary of available operator-visible display-delay measurement results.

Test Item	Description or Value
Test platform	Single test vehicle
Number of repeated route tests	5
Telemetry frequency	10 Hz
Measurement scope	From V2X message reception at the edge-side processing environment to dashboard reflection
Average display delay	0.78 s
Standard deviation	0.059 s
Maximum display delay	0.96 s
Run-level delay distribution	Not separately stored in the present test
Stage-level latency decomposition	Not separately measured
Pipeline stages not separately quantified	V2X radio transmission, RSU forwarding, edge parsing, Kafka ingestion, Elasticsearch indexing, and Grafana query/rendering

summarizes the available aggregate statistics of the operator-visible end-to-end display-delay measurement. Although the same route was repeated five times, run-level delay distributions and stage-level latency values were not separately stored in the present test. Therefore, the table reports the aggregate delay metrics used in this study and explicitly identifies the measurement scope and limitations.

The reported delay values represent operator-visible end-to-end display delay at the supervisory-system level. They do not separately quantify V2X radio latency, RSU forwarding time, edge parsing time, Kafka ingestion delay, Elasticsearch indexing time, or Grafana query and rendering delay. Because synchronized timestamps were not assigned at every internal stage of the RSU, edge, streaming, storage, and dashboard pipeline in the present test, stage-level latency decomposition remains a subject of future work.

Figure 12 shows real-time trajectory and location monitoring through the map panel and cloud-data linkage. The dashboard visualized the OBU trajectory as sequential position markers while the test vehicle moved away from the RSU-side reference location. Based on the map display, the distance between the RSU-side reference point and the farthest observed OBU position was confirmed to be more than approximately 700 m. This result confirms that V2X-based telemetry could be received, processed through the edge-cloud pipeline, and displayed as an operator-facing trajectory under the tested site condition, without changing the dashboard schema during the test.

3.5. Payload-Level Traffic Estimation for Preliminary Capacity Planning

Using the payload-level estimation method defined in Section 2.6, a preliminary capacity-planning calculation was performed under the same telemetry condition used in the field configuration. The telemetry frequency was set to 10 Hz, and the payload length per message was assumed to be 2304 bits. Under this condition, the pure-payload data rate per mobile unit was calculated as 23.04 kbps. This result should be interpreted as a minimum capacity estimate rather than a measured multi-vehicle wireless result, because the field test did not operate a large fleet simultaneously.

Figure 13 shows the estimated payload throughput as a function of the number of mobile units. The throughput increases linearly because the analysis considers only pure payload traffic. The estimated throughput was 115.20 kbps for 5 units, 230.40 kbps for 10 units, 460.80 kbps for 20 units, and 1.152 Mbps for 50 units.

Table 9. Payload traffic estimate under the 10 Hz telemetry condition.

Number of Mobile Units	Telemetry Frequency	Payload Length per Message	Estimated Pure-Payload Throughput
1	10 Hz	2304 bit	23.04 kbps
5	10 Hz	2304 bit	115.20 kbps
10	10 Hz	2304 bit	230.40 kbps
20	10 Hz	2304 bit	460.80 kbps
50	10 Hz	2304 bit	1.152 Mbps

Note: Values represent payload-only estimates and exclude wireless protocol overhead, retransmission, encryption, synchronization, and dashboard query overhead.

summarizes the estimated payload throughput for 1, 5, 10, 20, and 50 mobile units under the same 10 Hz telemetry condition. Because the operator dashboard does not need to render every high-rate sample, the platform stores high-frequency data in the time-series layer and displays summarized values on the dashboard. This separation helps maintain operator usability while preserving high-resolution telemetry for analysis. For practical deployment, additional design margins should be considered because protocol overhead, retransmission, security-layer data, time-synchronization messages, and dashboard query overhead are not included in the payload-only estimate.

4. Discussion

The results show that an edge-cloud design can reduce the integration burden of site-level autonomous mobile-unit monitoring. The edge layer absorbs variability in V2X device configuration and field communication conditions, whereas the cloud layer preserves a reusable data pipeline and dashboard. This division is particularly useful when the same supervisory system must be applied to several outdoor sites with different layouts and equipment types. The most important practical benefit of the normalized schema is interface stability. In field development, a system often begins with partial measurements and virtual values. If the storage index and dashboard are designed only after all physical data are available, early integration is delayed. In the proposed approach, field names and data types are fixed at the initial integration stage, and virtual values are gradually replaced by measured sources. This allows dashboard development, data storage, and scenario testing to proceed before full sensor integration is completed.

The observed 0.78 s average display delay and the maximum delay below 1 s met the operator-visible supervisory monitoring target, but they should not be interpreted as safety-critical control latency. The proposed pipeline does not replace low-latency vehicle control, collision avoidance, or emergency braking functions, which require dedicated real-time communication and control logic at the vehicle or edge-control level. Instead, the platform is positioned as a supervisory telemetry layer for operator awareness, reproducible logging, dashboard-based interpretation, and future scheduler-interface integration. This distinction is important because outdoor industrial sites require both real-time control functions at the vehicle or edge level and higher-level monitoring functions for operation management and post-test analysis.

The payload-based scalability analysis complements the field-test result without claiming an additional wireless experiment. The analysis provides a lower-bound traffic estimate that can be used during early capacity planning. Because the values are based only on payload length and telemetry frequency, the actual network design should include additional margins for IP/TCP overhead, Kafka headers, retransmission, encryption or TLS processing, time synchronization, packet loss, network congestion, Elasticsearch indexing cost, and concurrent Grafana dashboard queries. This distinction is important for avoiding overinterpretation of payload-level results as complete wireless capacity measurements.

The present field validation has several limitations. First, the physical test used a single test vehicle, and simultaneous multi-vehicle operation was not experimentally evaluated. Therefore, the results demonstrate the feasibility of the telemetry pipeline and dashboard under the tested configuration, but they do not fully validate large-scale fleet operation. Second, the maximum verified communication distance was bounded by the available field area, and a direct 1 km evaluation was not performed. The reported approximately 700 m distance should therefore be interpreted as a site-specific result influenced by the test route, antenna placement, line-of-sight condition, surrounding structures, and local propagation environment. Third, adverse weather, non-line-of-sight propagation, severe network congestion, and long-term continuous operation were not tested.

The timestamp policy also limits the interpretation of the delay results. In the present test, synchronized timestamps were not assigned at every internal stage of the RSU, edge, streaming, storage, and dashboard pipeline. Therefore, the measured end-to-end delay was evaluated at the operator-visible display level rather than by decomposing latency across every pipeline segment. Future tests should assign a unique message identifier and synchronized timestamps at each stage so that V2X radio latency, RSU forwarding time, edge parsing time, Kafka ingestion delay, Elasticsearch indexing time, and Grafana query/rendering delay can be separately quantified. Packet reception rate, packet loss, jitter, update-interval distribution, CPU usage, memory usage, and Kafka broker load should also be included in future experiments to support a more complete evaluation of field communication quality and platform scalability.

Another limitation is that the mission scheduler was connected only conceptually through preliminary interface fields. Closed-loop task reassignment, autonomous replanning, and scheduler-driven vehicle control were not experimentally validated in this study. Future work should quantify the relationship between communication quality and mission-level decisions. For example, reduced reception quality or delayed telemetry could trigger task reassignment, route replanning, or a safe waiting mode. However, such functions require additional validation beyond the telemetry- and dashboard-focused scope of the present work.

Security was not the primary focus of the present implementation. However, industrial V2X-based supervisory systems require security mechanisms at both the communication and platform layers. Future deployment should consider V2X authentication, ITS certificate management, message-integrity verification, spoofing protection, encrypted edge-to-cloud communication, Kafka pipeline cybersecurity, and role-based access control for Grafana dashboards. These functions are necessary before the proposed platform can be used in safety-relevant or security-sensitive industrial operations.

5. Conclusions

This study presented an edge-cloud V2X telemetry platform for supervisory monitoring of autonomous mobile units in outdoor industrial sites. The platform combines V2X message reception, edge-side parsing and normalization, Kafka-based streaming, Elasticsearch-based time-series storage, and Grafana-based operator visualization. A fixed supervisory schema was defined so that measured, virtual, and future integration fields can be handled consistently during staged development.

Physical field validation was conducted using a single test vehicle in a construction-site emulation environment. Under the tested site conditions, the system maintained continuous reception and dashboard visualization over an approximately 700 m distance from the RSU-side reference location. The dashboard reflected position and trajectory information within the 1 s operational target, and the measured operator-visible display delay averaged 0.78 s with a maximum of 0.96 s. These results demonstrate the feasibility of the proposed telemetry pipeline and dashboard under the tested configuration, but they do not constitute full validation of simultaneous multi-vehicle operation.

A payload-level capacity estimate further showed that, under a 10 Hz telemetry condition and a 2304-bit payload assumption, the minimum pure-payload traffic is 23.04 kbps per mobile unit, approximately 0.46 Mbps for 20 units, and approximately 1.15 Mbps for 50 units. These values should be interpreted as lower-bound capacity-planning estimates rather than complete network-load or scalability-validation results, because IP/TCP overhead, Kafka headers, retransmission, encryption or TLS processing, synchronization traffic, packet loss, network congestion, Elasticsearch indexing cost, and Grafana query load were not included.

The proposed architecture provides a practical field-tested baseline for supervisory telemetry acquisition, logging, storage, and dashboard visualization in outdoor industrial sites. Future work will extend the platform toward simultaneous multi-vehicle field testing, synchronized stage-level latency measurement, packet-loss and jitter analysis, communication-load evaluation, security-enhanced V2X communication, and experimentally validated scheduler integration.