Real-Time Traffic Data Analysis on Resource-Constrained Edge Devices

Abstract

This paper evaluates the feasibility of real-time traffic data analysis on resource-constrained edge devices using a hybrid processing approach. The proposed architecture integrates an LF Edge eKuiper complex event processing engine, deployed within Docker containers, with a native YOLO deep learning model for pedestrian detection. The model processes video frames at 480 × 240 resolution on CPU-only Raspberry Pi devices, achieving up to 30 FPS. The research specifically investigates the performance limits of Raspberry Pi 3 and Raspberry Pi 4 platforms when simultaneously processing high-throughput simulated traffic data from the SUMO simulator (Belgrade scenario, with vehicle distributions and densities adjusted for small, medium, and large traffic volumes) and live video streams, respectively. Experimental results indicate that while both platforms can process up to 2600 messages per second in the settings without image processing, the introduction of a camera sensor reveals a significant hardware bottleneck. The Raspberry Pi 4 maintains robust real-time performance with an average complex event detection latency of less than 500 ms. In contrast, the Raspberry Pi 3 exhibits severe performance degradation, with image processing delays exceeding 8 s, rendering it unsuitable for real-time safety alerts. The findings demonstrate that with appropriate hardware selection, edge-based complex event processing can successfully detect critical safety events, such as sudden vehicle acceleration near pedestrians, without relying on cloud infrastructure.

1. Introduction

In the domain of smart cities, real-time data processing has evolved from a technical advantage to a critical requirement for urban safety. Key trends such as decentralization and artificial intelligence (AI) integration are redefining system expectations, enabling context-aware systems capable of autonomously responding to environmental conditions. Energy-efficient communication technologies further support this paradigm by enabling reliable and long-lasting connectivity between devices, which is essential for scalable and sustainable smart city systems [1,2]. However, this shift has led to an explosion of high-volume data generated by Internet of Things (IoT) devices. The primary challenge is no longer just data collection, but processing these continuous streams within millisecond time windows to enable immediate action. This is of particular importance in Intelligent Transportation Systems (ITSs), where pedestrian safety depends on the system’s ability to detect and respond to risk situations and hazards in real time.

Traditional IoT architectures were typically divided into three layers: Things, Gateways, and Cloud [3]. However, as the volume of data grows, the centralized Cloud model introduces significant bottlenecks in terms of network bandwidth and latency. To mitigate these issues, Edge Computing that includes functionality and infrastructure of Things and Gateways has emerged as a paradigm shift [4]. In this context, Fog and Edge computing are often considered as referring to similar architectures that aim at moving data processing closer to the source to handle the influx of information from diverse and heterogeneous devices [5].

Thus, the strategy for data analysis is typically divided by its temporal value: edge analytics focuses on answering “what is happening now,” whereas cloud analytics aims to explain “why it happened” [5]. The integration of AI and, in particular, machine learning (ML) enables advanced capabilities such as real-time prediction and pattern recognition. While training ML models requires substantial computational resources found in the cloud, deploying inference models at the edge provides an effective solution for latency-sensitive applications [6]. However, implementing these capabilities on resource-constrained devices remains a significant engineering challenge. To maintain real-time performance, lightweight engines capable of performing Complex Event Processing (CEP) on affordable hardware are required to detect critical safety events as they occur [7]. Recent trends show that containerization, specifically using Docker, provides a flexible and scalable environment for deploying such analytics at the edge [8,9]; additionally, important directions in edge graph learning have recently received research attention [10].

This paper addresses this challenge by proposing an edge-based architecture designed to enhance pedestrian safety through the efficient processing of high-throughput data streams. Specifically, we investigate the feasibility of using a lightweight CEP engine on Raspberry Pi (RPi) platforms to process traffic data. Unlike generic IoT studies, this research utilizes a hybrid validation approach: traffic logic is simulated for the city of Belgrade using the SUMO (Simulation of Urban MObility) simulator, while pedestrian presence is integrated via live video stream analysis using a deep residual learning model [11].

The main contributions of this paper are:

• To design a containerized edge architecture for real-time stream analytics based on a lightweight CEP engine, the Docker containers and the Message Queuing Telemetry Transport protocol (MQTT).
• To implement a real-time complex event detection and analysis system on edge computing devices for traffic-related scenarios. We also aim to perform a comparative performance analysis between the Raspberry Pi 3 and Raspberry Pi 4 platforms, investigating the hardware limits of resource-constrained edge nodes when performing concurrent real-time video inference and complex event processing.
• To validate the system’s ability to detect complex traffic events (e.g., sudden vehicle acceleration near pedestrians) with sub-500 ms latency.

The remainder of this paper is organized as follows. Section 2 provides an overview of related studies in edge analytics. Section 3 describes the research objectives and introduces the underlying edge computing architecture. Section 4 reports on the experimental settings and performance analysis. Finally, Section 5 concludes the paper.

2. Background and Related Work

The challenge of optimizing real-time data processing in smart-city environments has led to various approaches, ranging from simple data filtering to complex hybrid systems.

2.1. Edge Processing Architectures

Shifting the processing paradigm from the cloud to the edge is a primary strategy for mitigating network bandwidth bottlenecks, enhancing privacy protection and minimizing response latency. For example, Bezerra et al. [12] simulated a Smart Agriculture scenario involving 100 sensors and 20 fog nodes using Python and an MQTT to transmit 3600 messages in total. Their findings demonstrated that local processing can significantly reduce latency and network load. Silva et al. [5] demonstrate that while the cloud remains general purpose and scalable, the edge is superior for specialized, latency-sensitive tasks. The proposed architecture was evaluated using simulated sensors that transmitted data to an MQTT broker, utilizing Apache Edgent at the Gateway level to perform local filtering. Similarly, Xinwei et al. [13] conceptualize the edge as a distributed collection of gateways with lower processing capabilities, arguing that such devices should primarily handle basic operations like local aggregation. In their experimental setup, Apache Storm was deployed on a Raspberry Pi platform serving as an edge device, and they introduced custom algorithms to decouple threads and improve responsiveness. The decentralization of data management is further supported by microservice-based architectures. Bixio et al. [14] implement a layered approach using the Java OSGi standard, and demonstrate that adhering to the single responsibility principle enables three-dimensional scalability: horizontal, functional, and data partitioning. In their framework, the Siddhi Complex Event Processing engine was integrated to handle real-time streams, proving that modular nanoservices can effectively manage complex event logic at the network edge. Likewise, Jin et al. utilized [15] the EdgeX platform deployed on a Raspberry Pi platform as the edge devices leveraging the eKuiper engine. The experiments showed that multiple eKuiper instances can be deployed simultaneously to process different data streams, further reducing latency and enabling flexible resource management at the edge device level. Sreekumar et al. [16] focused on processing video from traffic cameras to monitor vehicle flow on edge devices. In their study, the hardware used included an Intel i7 CPU and an NVIDIA 1080 GTX GPU.

2.2. Complex Event Processing and Intelligence at the Edge

Accounting for temporal context in continuous data stream analysis is of fundamental importance for extracting useful insights into dynamic environments. Corral Plaza [17] demonstrates that isolated sensor readings are of a limited operational value when not processed within temporal windows, illustrating that event frequency rather than single observations can be used to trigger meaningful alerts. Ou et al. [18] investigated streaming data processing to predict the number of passengers in metro systems based on ticket sales. They developed a custom model capable of forecasting the passenger flow in real time. To optimize such processes on resource-constrained devices, Lan et al. [7] propose shifting the analytics closer to the network edge, and show that defining elementary event rules prior to higher-level complex event processing reasoning may significantly reduce bandwidth consumption and computational overhead. To move beyond mere detection toward proactive safety, Akbar et al. [19] integrate machine learning with complex event processing, thus enabling predictive event reasoning in IoT environments. The proposed architecture combined ingestion, stream management, and rule evaluation layers to demonstrate real-time traffic prediction using hybrid historical and live datasets. The focus on “event reasoning” is maintained in [20,21], considering, respectively, multimodal sensing frameworks in which lightweight vision inference is fused through complex event processing rules to trigger automated safety responses, and hybrid neural–pattern recognition pipelines for spatial–temporal reasoning. In general, those studies highlight the importance of stream-oriented infrastructures capable of processing continuous event flows. Stream processing engines support this functionality by enabling filtering, aggregation, joins, and window-based operations directly over transient data streams, thereby minimizing latency compared to storage-centric approaches. Uyanık et al. [22] report on a dedicated distributed complex event processing system based on Python, MongoDB, and MQTT. In the practical IoT edge deployments, the data sources typically correspond to sensors or brokers, while the sinks represent actuators or upstream aggregation layers. Complex event processing extends stream processing by allowing for correlation across multiple heterogeneous event sources using rule-based logic expressed through SQL-like query languages rather than storing data for retrospective analysis. Such systems continuously evaluate incoming events against predefined patterns to detect contextual situations in real time. Although inherently reactive, complex event processing can be enhanced through integration with machine learning models to support predictive reasoning and proactive responses in safety-critical environments [4,23,24,25,26].

2.3. Containerization and Video Analytics on Resource-Constrained Nodes

Docker has emerged as a key technology for managing complex analytics at the edge, providing environment isolation of modular processing layers. Related to the the Gateway component, two types of architecture can be distinguished based on where data processing occurs: fog computing and edge computing (including near-edge and far-edge). Containerization simplifies deployment, improves stability under variable workloads, and enables horizontal scalability on resource-constrained devices. In multi-node setups, a master node may host a local registry for Docker images, while peripheral nodes retrieve them locally, minimizing bandwidth usage [27,28]. A common platform for edge gateways is the Raspberry Pi, a compact single-board computer offering sufficient computational power for lightweight analytics while maintaining low cost and energy consumption [8,9,15,22,28,29,30,31,32]. A minimum configuration of Docker based edge applications generally includes a quad-core ARM Cortex-A53 CPU at 1.2 GHz and 1 GB of RAM [8,9,29]. Such platforms allow concurrent execution of analytics containers for data preprocessing, stream processing, and ML inference [28,30]. Several edge analytics platforms support IoT and real-time data processing. Apache Edgent provides local analytics to reduce the cloud bandwidth, though it is no longer actively maintained [33]. EdgeX Foundry, a microservices-based framework, can run on edge gateways using containerization and integrate rule-based engines, such as EMQX eKuiper, for high-throughput traffic and sensor event processing. EMQX eKuiper, a rule-based edge analytics engine, is integrated into the EdgeX ecosystem. Due to its lightweight footprint and SQL-like query capability, it is suitable for real-time stream processing directly on gateway devices [34]. Raspberry Pi and eKuiper allow modular, scalable, and reproducible deployment of stream processing engines and complex event processing e-based applications, making them suitable for experimentation with heterogeneous sensor data and vision-based event streams in smart city scenarios. In contrast to previous work, we propose an approach capable of processing high-volume of traffic messages in real time while detecting complex events on resource-constrained edge devices such as the Raspberry Pi. Our approach evaluates the system under three test cases with different workload intensities, where the message rate reaches up to 2400 messages per second, with each message containing 11 attributes. While the considered studies explore general edge architectures [5,13], hierarchical CEP optimizations [7], and isolated video analytics [11,29], there is a noticeable lack of research aimed at evaluating the performance limits and scalability of different hardware settings in the context of applying unified stream processing engines. Most of the existing studies either focus on simulation-based event processing on high-performance nodes or perform intensive video analytics on a single device, without assessing the overhead of concurrent, high-throughput data streams.

3. Research Objectives and Edge Computing Architecture

The primary objective of this research is to address this shortcoming of the related research by analyzing the capabilities of the Raspberry Pi 3 and Raspberry Pi 4 platforms for processing high-volume data within a hybrid environment. Unlike previous approaches, this work evaluates the performance of the LF Edge eKuiper engine as a unified processing layer, simultaneously handling simulated city-scale traffic data generated by the SUMO simulator (i.e., Belgrade, the capital of Serbia, scenario) and real-time vision-based events. By deploying a core analytical engine within Docker containers and integrating it with a native deep learning inference, we aim at quantifying the system latency and event detection accuracy, and determining the operational limits of resource-constrained devices in proactive smart-city safety scenarios. The reported comparative analysis provides practical insights into how different edge hardware settings scale when tasked with complex, multi-source event reasoning. The primary objective of this research is to evaluate the feasibility of large-volume data processing in real time on an edge device in a traffic safety context. The proposed data processing pipeline is based on a stream processing engine designed to operate on resource-constrained edge hardware, such as a Raspberry Pi. Data originating from multiple heterogeneous sources are transmitted to an MQTT broker, which acts as a central message broker. To emulate real-world conditions, the SUMO traffic simulator was used to generate vehicular traffic data. In addition, live video streams from EarthCam.com were used to simulate real-time camera input, from which the pedestrians are detected. Data from both the sources were forwarded to a dedicated MQTT broker. Based on these input streams, the system detects safety-relevant complex events in real time, such as abnormal vehicle speeds or unexpected movement patterns, while simultaneously maintaining situational awareness of pedestrian presence at a crossroad. The overall goal is to develop a smart crossroad system capable of monitoring vehicular movement across a wider area and pedestrian activity at an intersection in real time. A visual overview of the proposed scenario is presented in Figure 1.

One of the critical events detected by the proposed system is related to sudden (i.e., sharp) acceleration or deceleration. If a vehicle exhibits a sudden change in speed within a short time interval, pedestrians are warned of the increased risk associated with potentially dangerous driving behavior. All data processing is performed locally, at a single intersection, which serves as a representative model of the proposed edge computing architecture. The experiment evaluates whether large-volume heterogeneous data can be processed at the edge in a timely manner, without relying on a cloud-based infrastructure for deep analytics. To illustrate this idea, the research focuses on detecting a complex event that triggers an alert when vehicle acceleration occurs in the presence of pedestrians. Acceleration of vehicle i is defined as the change in velocity over a given time interval $\mathrm{\Delta }t$, where K is a preset threshold representing the maximum time interval (in seconds) between two subsequent events:

$$A(i,t)={\displaystyle \frac{\mathrm{\Delta }V}{\mathrm{\Delta }t}},$$

(1)

where $0<\mathrm{\Delta }t<K$ and $\mathrm{\Delta }V=V\left(t\right)-V(t-\mathrm{\Delta }t)$.

The cumulative acceleration of single vehicle i over a period T is defined as the number of times vehicle i generates sudden acceleration, i.e., acceleration above a given threshold $A_{thr}$:

$$N_1(i,t_0,T,A_{thr})=\sum _{t=t_0}^{t_0+T}f(i,t,A_{thr}),$$

(2)

where:

$$f(i,t,A_{thr})=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}\left|A(i,t)\right|>A_{thr}\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right..$$

(3)

Equation (4) calculates the number of vehicles in lane L which generates at least one sudden acceleration within a given period T:

$$N_2(L,t_0,T,A_{thr})=\sum _{i\in L}g(i,t_0,T,A_{thr}),$$

(4)

where:

$$g(i,t_0,T,A_{thr})=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}{N}_1(i,t_0,T,A_{thr})>0\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right..$$

(5)

In the reported study, we set the threshold parameter $A_{thr}$ to 1. This particular value is selected keeping in mind that the vehicle speed is expressed in meters per second (m/s). It should be noted, however, that this value is taken only for the purpose of illustration. In general, it should be considered as a parameter which may be tailored according to given requirements.

A pseudocode condition for triggering the alert is defined as follows:

$$P\left(t\right)>0\wedge N_2(L,t,T,A_{thr})>0\wedge (\exists i\in L)(N_1(i,t,T,A_{thr})\ge G),$$

(6)

where $P\left(t\right)$ represents the number of detected pedestrians at moment t, and G is a preset threshold representing the number of cumulative acceleration events for a single vehicle. It should be noted that Equation (6) is not given as a comprehensive alarm condition, but rather as condition applied to illustrate the overall functionality of the system. In general, the alarm condition may be tailored to particular requirements.

4. Experimental Evaluation and Performance Analysis

4.1. Experimental Setup

The overall setup for evaluating and testing the proposed edge computing infrastructure is illustrated in Figure 2, including a traffic simulation generator, an MQTT server, and an event detection service deployed on the edge device. The traffic simulation generator runs on a Dell Precision workstation configured with an Intel i9 CPU and 64 GB RAM. The data generated by the simulator are transmitted approximately every second via a dedicatedly developed custom application. The MQTT server is deployed on an HP workstation configured with an Intel i7 CPU and 32 GB RAM. The edge devices are based on Raspberry Pi platforms: Raspberry Pi 3 and Raspberry Pi 4.

In the considered scenario, traffic data are generated using the SUMO simulator, focusing on one of the busiest areas of the city of Belgrade, Serbia. The map representation of the given urban area is given in Figure 3. The simulation runs for 7400 s (i.e., over two hours), during which a variable amount of data is produced each second. The SUMO simulation is configured using real-world map data extracted from OpenStreetMap for the entire urban area of Belgrade. Therefore, the simulation may be considered representative for the purpose of evaluation of the system performance under controlled yet realistic conditions. The traffic network is generated using the osmconvert software component, followed by the netconvert component to produce a net.xml file used in SUMO. The selected geographic area corresponds to the bounding box defined by coordinates (20.41648, 44.75332) and (20.51147, 44.82524).

The dedicated custom application transmits the generated data to the MQTT broker (formatted as JSON files) in real time. The attributes of each message are summarized in

Table 1. JSON message attributes.

JSON Field	Type
new_timestep_time	Long
timestep_time	Float
vehicle_angle	Float
vehicle_id	String
vehicle_lane	String
vehicle_pos	Float
vehicle_slope	Float
vehicle_speed	Float
vehicle_type	String
vehicle_x	Float
vehicle_y	Float

. The MQTT broker is capable of handling more than 10,000 messages per second at the Quality of Service (QoS) level 0, even when deployed on devices with limited computational resources, such as Raspberry Pi platforms. Figure 4 illustrates the distribution of sudden accelerations of vehicle movements.

To integrate the information on real-time pedestrian presence, live video footage from one side of the monitored intersection, captured over a two-hour period, is analyzed using a YOLO model for real-time object detection deployed on a camera connected to an edge device. The primary objective of this monitoring is to extract information on pedestrian presence during different time intervals. The selected frames of this footage, with pedestrian detection results obtained from both the platforms, respectively, are given in Figure 5.

A Raspberry Pi platform was used with the Docker and Docker containers to manage and execute the required services. For the purpose of complex event processing, the EMQX Kuiper (eKuiper) engine was selected due to its lightweight architecture and compatibility with edge computing constraints. As described, live stream video data were captured and displayed on a screen. A camera was positioned to record the display and to detect pedestrians. For pedestrian detection and counting, the YOLOv8n model was employed, implemented within the OpenCV (cv2) framework. This model processes input frames at a resolution of 480 × 240 pixels, achieving a processing rate of 30 FPS. The inference is performed exclusively on CPU, without hardware acceleration. The environment was set up to monitor the central area of the considered crossroad. Figure 6 illustrates the camera view along with the detected pedestrian count.

For real-time data stream processing from all the sources (i.e., the traffic data and live stream video data), a set of rules for monitoring driving behavior and pedestrian presence at a given crossroad have been implemented on the eKuiper engine. The layout of the intersection and the applied rules are illustrated in Figure 7. The considered intersection comprises six street segments.

For each street segment, a separate set of rules determines the numbers and types of vehicles (e.g., cars, trucks, motorcycles, buses), their accelerations and changes in direction. Combined with the rules determining the number of pedestrians, complex traffic safety events are simulated. An example of an eKuiper rule illustrating the implementation of the proposed approach is shown in Figure 8.

We consider a 3 × 2 × 2 experimental design. The first variable is related to traffic volume. Three distinct test cases were considered using the SUMO simulator for the given urban area, with different numbers of messages per second for each case, as illustrated in Figure 9. Test case 1 represents low traffic volume (i.e., the blue line), test case 2 medium traffic volume (i.e., the green line), and test case 3 high traffic volume (i.e., the red line). All three simulations lasted for 7400 s and were generated using different parameter settings, as summarized in

Table 2. SUMO configuration parameters.

SUMO Variables	Test Case 1 (Low)	Test Case 2 (Medium)	Test Case 3 (High)
P_MOTO	5.351446	3.351446	3.051446
P_PASS	1.950482	1.050482	0.750482
P_TRUCK	2.975723	1.575723	1.075723
P_BUS	5.051446	3.351446	2.751446
DURATION	6000	4000	4000
END_TIME	7400	7400	7400

.

The second variable is related to the Raspberry Pi platform. We applied two platforms: Raspberry Pi 3 (ARMv8, 64-bit, 1.4 GHz, 1 GB RAM, Gigabit Ethernet over USB 2.0) and Raspberry Pi 4 (ARMv8, 64-bit, 1.8 GHz, 4 GB RAM, Gigabit Ethernet over USB 2.0). The third variable is related to the computer vision workload, i.e., settings with or without a camera connected to the edge device. Multiple rules were executed on the devices, but the reported analysis focuses specifically on cases involving high vehicle acceleration. Parameters K and G, applied in Equations (2) and (6), are set to values 3 s and 2, respectively. Testing the hardware under image processing workloads was aimed at evaluating whether the additional computational load affects the performance of the system and determining whether the selected hardware and computer vision model can operate in real time.

4.2. Performance Evaluation and Analysis

Prior to the experiment, it was necessary to test whether the developed custom application is capable of transmitting the required volume of simulated traffic data to support real-time performance. This capability is essential, as the primary objective of the system is to perform predictions based on live data streams. The obtained measurements confirm that records are transmitted in a manner consistent with their generation by the SUMO traffic simulator. An insight into the time required to transmit messages generated by the SUMO traffic simulator to the central sever in different test cases (of low-, middle- and high-traffic volume) is given in Figure 10.

For the purpose of the main experiment, the clocks of all system components, including both Raspberry Pi platforms, were synchronized using the NTP server, ensuring consistent timestamping required for the correct execution of the window-based rules. The results obtained in the experimental settings without the camera connected to the edge device are summarized in

Table 3. The results obtained in the experimental settings without the camera connected to the edge device.

Without Camera		TW		CW		STW		SCW
		RPi3	RPi4	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4
Low-traffic volume	T	12:43:11 0.564	12:43:11 0.610	23:46:35 0.978	23:46:35 0.978	05:19:30 0.545	05:19:30 0.545	12:18:35 0.014	12:18:35 0.014
	M	4.82	4.82	4.5	4.5	4.97	4.97	4.82	4.82
	I	veh1806	veh1806	veh341	veh341	veh1145	veh1145	veh1806	veh1806
	C	76	75	82	82	567	571	233	233
Middle-traffic volume	T	18:53:38 0.548	18:53:38 0.564	23:34:18 0.889	23:34:18 0.889	12:30:26 0.370	12:30:26 0.355	07:53:57 0.108	07:53:57 0.092
	M	5.18	5.18	6.45	6.45	6.45	6.45	6.45	6.45
	I	moto929	moto929	moto929	moto929	moto929	moto929	moto929	moto929
	C	128	128	111	111	1247	1252	342	342
High-traffic volume	T	17:47:59 0.561	17:47:59 0.624	22:30:46 0.738	22:30:46 0.738	15:39:40 0.541	15:39:40 0.541	09:29:21 0.645	09:29:21 0.645
	M	5.18	5.18	4.11	4.11	6.45	6.45	6.45	6.45
	I	moto929	moto929	veh19	veh19	moto929	moto929	moto929	moto929
	C	130	131	46	46	1232	1245	343	343

. Time is given in milliseconds and represented using the Unix timestamp format (HH:MM:SS.ms). For each test case, the table provides: the time at which the maximum acceleration was observed (T), the value of the maximum acceleration (M), the ID of the vehicle generating the maximum acceleration (I), and the total count of sharp acceleration events (C). All four parameters are recorded for each test case across four types of windows: Time Window (TW), Count Window (CW), Sliding Time Window (STW), and Sliding Count Window (SCW).

Table 4. The results obtained in the experimental settings with the camera connected to the edge device.

With Camera		TW		CW		STW		SCW
		RPi3	RPi4	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4
Low-traffic volume	T	02:38:33 0.002	02:38:32 0.987	18:13:00 0.062	18:12:59 0.047	08:48:23 0.168	08:48:23 0.152	04:45:48 0.648	04:45:48 0.632
	M	4.97	4.97	4.61	4.82	4.97	4.97	4.82	4.82
	I	veh1145	veh1145	veh194	veh1806	veh1145	veh1145	veh1806	veh1806
	C	107	109	80	81	544	558	233	233
	N	953	6004	972	6082	968	6418	966	7338
	A	6681.38	1060.36	6627.67	1058.97	7096.31	1070.08	7109.21	1068.03
Middle-traffic volume	T	15:04:57 0.838	15:04:57 0.822	07:55:50 0.791	07:55:43 0.388	01:35:56 0.900	01:35:49 0.224	17:21:28 0.341	17:21:20 0.080
	M	4.61	4.61	5.18	6.45	6.45	6.45	6.45	6.45
	I	veh194	veh194	moto929	moto929	moto929	moto929	moto929	moto929
	C	99	97	109	107	941	1247	346	343
	N	1006	5521	584	4177	566	4480	567	4486
	A	6819.69	1242.67	9259.18	1207.40	9238.10	1166.41	9212.68	1164.66
High-traffic volume	T	10:13:17 0.569	10:13:08 0.520	06:03:53 0.540	06:03:48 0.357	22:05:59 0.364	22:05:50 0.930	08:51:12 0.811	08:51:04 0.133
	M	5.18	5.18	5.18	6.45	6.45	6.45	6.45	6.45
	I	moto929	moto929	moto929	moto929	moto929	moto929	moto929	moto929
	C	164	183	114	111	976	1256	345	343
	N	924	5283	582	4319	569	4498	568	4474
	A	6891.79	1205.09	8668.72	1166.77	9194.21	1162.66	9205.95	1167.81

presents the results obtained in the experimental settings with the camera connected to the edge device. Besides the corresponding rows defined above, this table contains two additional rows. The row N indicates the number of messages reporting the detected number of pedestrians, and the row A provides the average time, in milliseconds, between two consecutive messages delivering pedestrian count data.

Based on the obtained results, it can be concluded that for Test Case 1 (TC1, low-traffic volume), the count of sharp acceleration events (C) is similar between the no-camera and camera scenarios on both the Raspberry Pi 3 and Raspberry Pi 4 platforms, except when using sliding time windows. Comparing TC1 results between the camera and no-camera scenarios on the same platform indicates that the greatest variation occurs when employing a time window or sliding time windows. The comparison results for TC1 are illustrated in Figure 11.

For Test Case 2 (TC2, middle-traffic volume), a conclusion similar to Test Case 1 was reached: both platforms produced the same results in no-camera settings. When using the camera, greater discrepancies were observed with sliding time windows, as the Raspberry Pi 3 platform generated 25% fewer events than the Raspberry Pi 4 platform, compared to the Test Case 1 where the difference was only 4%. The results for the Test Case 2 are presented in Figure 12.

Considering the Test Case 3 (TC3, high-traffic volume), as shown in Figure 13, it was concluded that the obtained results were similar to those of the Test Case 2. Specifically, the sliding time window exhibited the largest discrepancy when using the camera, with the Raspberry Pi 3 platform generating 21% fewer events than the Raspberry Pi 4 platform.

The information regarding the number of detected pedestrians was configured to be sent every second. Based on results summarized in Figure 14, it can be concluded that the transmission time on the Raspberry Pi 3 platform exceeded 6.6 s and increased further in test cases with a higher message rate per second. For the count window, the average time between consecutive transmissions reached 10 s.

On the Raspberry Pi 4 platform, based on results summarized in Figure 15, it can be concluded that the average time for transmitting the message on the number of detected pedestrians ranged between 1.05 and 1.25 s between consecutive transmissions.

The maximum acceleration in the Test Case 1 was recorded by the vehicle with ID veh1145, measuring 4.97. This result was observed on both platforms (with and without the camera), but only when using the sliding time window. Although the same dataset was consistently used for this low-traffic volume test case, this event was not detected in every scenario. In all the considered scenarios, except for the count windows with the camera, events observed on the Raspberry Pi 3 were also detected on Raspberry Pi 4. The results are summarized in

Table 5. Results of testing TC1, max acceleration.

Low-Traffic Volume	TW		CW		STW		SCW
	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4
Without camera	4.82	4.82	4.5	4.5	4.97	4.97	4.82	4.82
	veh1806	veh1806	veh341	veh341	veh1145	veh1145	veh1806	veh1806
With camera	4.97	4.97	4.61	4.82	4.97	4.97	4.82	4.82
	veh1145	veh1145	veh194	veh1806	veh1145	veh1145	veh1806	veh1806

.

In the Test Case 2, vehicle moto929 exhibited the maximum acceleration, reaching 6.45. This event was detected on both platforms, with and without the camera, when using the STW and the SCW. It was also observed that the results for the TW and CW were identical when the camera was not used, consistently across both the platforms. The results are summarized in

Table 6. Results of testing TC2, max acceleration.

Middle-Traffic Volume	TW		CW		STW		SCW
	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4
Without camera	5.18	5.18	6.45	6.45	6.45	6.45	6.45	6.45
	moto929	moto929	moto929	moto929	moto929	moto929	moto929	moto929
With camera	4.61	4.61	5.18	6.45	6.45	6.45	6.45	6.45
	veh194	veh194	moto929	moto929	moto929	moto929	moto929	moto929

.

The Test Case 3 yielded the same sharp acceleration results as those observed in the Test Case 2. Furthermore, similar to the Test Case 2, the results for the TW and CW were consistent across both platforms when the camera was not used. The results are summarized in

Table 7. Results of testing TC3, max acceleration.

High-Traffic Volume	TW		CW		STW		SCW
	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4	RPi3	RPi4
Without camera	5.18	5.18	4.11	4.11	6.45	6.45	6.45	6.45
	moto929	moto929	veh19	veh19	moto929	moto929	moto929	moto929
With camera	6.35	6.45	5.18	6.45	6.45	6.45	6.45	6.45
	moto929	moto929	moto929	moto929	moto929	moto929	moto929	moto929

.

The detection times of sharp acceleration events were analyzed separately. Regarding timing, it can be concluded that the event detection time in the Test Case 1 (i.e., low-traffic volume) is identical or differs by less than 50 ms across both the Raspberry Pi platforms, with and without the camera. The results are summarized in

Table 8. Differences in detection of max acceleration in TC1 on Raspberry Pi3 and Raspberry Pi4.

Low-Traffic Volume		TW		CW		STW		SCW
		Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$
Without camera	RPi3	12:43:11.564	−46	23:46:35.978	0	05:19:30.545	0	12:18:35.014	0
	RPi4	12:43:11.610		23:46:35.978		23:46:35.978		12:18:35.014
With camera	RPi3	02:38:33.002	15	18:13:00.062	15	08:48:23.168	16	04:45:48.648	16
	RPi4	02:38:32.987		18:12:59.047		08:48:23.152		04:45:48.632

.

In the Test Case 2 (i.e., middle-traffic volume), the detection times on both platforms without the camera were similar, with differences of less than 20 ms. Larger discrepancies occurred for the CW, STW, and SCW when using the camera, with differences reaching up to 7676 ms. The results are summarized in

Table 9. Differences in detection of max acceleration in TC2 on Raspberry Pi3 and Raspberry Pi4.

Middle-Traffic Volume		TW		CW		STW		SCW
		Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$
Without camera	RPi3	18:53:38.548	−16	23:34:18.889	0	12:30:26.370	15	07:53:57.108	16
	RPi4	18:53:38.564		23:34:18.889		12:30:26.355		07:53:57.092
With camera	RPi3	15:04:57.838	16	07:55:50.791	7403	01:35:56.900	7676	17:21:28.341	8261
	RPi4	15:04:57.822		07:55:43.388		01:35:49.224		17:21:20.080

.

In the Test Case 3 (i.e., high-traffic volume), a difference of 63 ms was observed in the no-camera scenario when using the Time Window, while no differences were detected in the other test scenarios without camera. When the camera was included, differences exceeded 8 s. The results are summarized in

Table 10. Differences in detection of max acceleration in TC3 on Raspberry Pi3 and Raspberry Pi4.

High-Traffic Volume		TW		CW		STW		SCW
		Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$	Time	$\mathsf{\Delta }$
Without camera	RPi3	17:47:59.561	−63	22:30:46.738	0	15:39:40.541	0	09:29:21.645	0
	RPi4	17:47:59.624		22:30:46.738		15:39:40.541		09:29:21.645
With camera	RPi3	10:13:17.569	9049	06:03:53.540	5183	22:05:59.364	8434	08:51:12.811	8678
	RPi4	10:13:08.520		06:03:48.357		22:05:50.930		08:51:04.133

.

A comprehensive analysis of CPU and memory utilization was conducted for both platforms across all experimental configurations, including scenarios with and without camera input, three levels of traffic intensity, and four window types. The results are summarized in

Table 11. Results of testing CPU and RAM on RPi3.

Case	Camera	Volume	CPU (%)				RAM (MB)
			MIN	MAX	N95	AVG	MIN	MAX	N95	AVG
Nothing	NO	/	2.50	23.10	4.80	3.64	335	349	346	342.90
Running	NO	/	2.30	17.10	4.80	3.54	430	452	450	443.89
TW	NO	Low	2.50	33.30	20.10	16.16	475	488	486	481.73
TW	NO	Middle	2.50	77.70	58.90	39.11	475	489	487	482.85
TW	NO	High	2.70	65.90	58.13	39.51	476	490	487	483.18
CW	NO	Low	2.50	32.90	21.15	16.04	470	486	483	479.30
CW	NO	Middle	2.30	65.70	59.40	39.51	470	487	485	480.80
CW	NO	High	2.50	65.20	60.14	40.51	473	487	485	481.07
STW	NO	Low	3.20	29.00	20.70	16.62	476	489	487	482.52
STW	NO	Middle	2.50	67.80	60.00	40.22	477	490	488	484.00
STW	NO	High	2.50	66.70	59.50	39.14	477	491	488	483.83
SCW	NO	Low	2.30	33.30	21.06	16.38	474	487	484	480.49
SCW	NO	Middle	2.10	67.20	59.40	35.17	473	489	486	481.55
SCW	NO	High	2.50	66.70	60.03	38.95	474	489	486	481.78
TW	YES	Low	88.40	95.00	92.04	94.10	531	571	540	536.22
TW	YES	Middle	87.90	97.10	97.07	94.58	525	574	546	536.88
TW	YES	High	88.80	98.20	97.69	94.72	528	583	548	539.33
CW	YES	Low	89.60	95.10	94.70	93.25	494	516	513	502.29
CW	YES	Middle	89.50	98.20	98.00	96.48	494	514	510	503.19
CW	YES	High	91.20	98.40	98.00	96.57	498	513	512	504.99
STW	YES	Low	88.50	95.40	94.26	92.37	526	574	540	535.72
STW	YES	Middle	89.70	98.30	97.81	96.67	527	549	548	542.37
STW	YES	High	90.80	98.30	97.80	96.46	530	575	550	542.44
SCW	YES	Low	83.90	97.40	96.40	93.29	532	618	582	550.55
SCW	YES	Middle	89.60	98.60	98.00	96.55	527	585	550	543.36
SCW	YES	High	89.10	98.30	97.96	96.27	533	584	548	542.57

for Raspberry Pi3, and in

Table 12. Results of testing CPU and RAM on RPi4.

Case	Camera	Volume	CPU (%)				RAM (MB)
			MIN	MAX	N95	AVG	MIN	MAX	N95	AVG
Nothing	NO	/	0.50	15.20	2.50	2.10	680	710	692	683.22
Running	NO	/	0.50	15.50	2.90	2.25	824	865	838	829.35
TW	NO	Low	2.00	22.30	11.40	9.20	908	934	922	914.03
TW	NO	Middle	2.00	30.80	21.80	16.30	909	935	924	915.07
TW	NO	High	2.20	30.60	22.00	16.48	913	943	925	916.22
CW	NO	Low	1.70	21.50	11.40	9.04	905	946	924	914.53
CW	NO	Middle	2.00	31.70	22.20	16.93	908	939	921	914.47
CW	NO	High	1.20	32.20	22.39	17.20	912	941	926	915.98
STW	NO	Low	2.20	22.30	11.50	9.28	914	940	926	917.02
STW	NO	Middle	2.20	30.20	22.40	16.94	914	941	925	916.95
STW	NO	High	1.00	33.20	22.00	16.63	913	938	923	916.38
SCW	NO	Low	2.20	21.80	11.60	9.31	913	939	925	916.74
SCW	NO	Middle	1.00	30.20	22.60	14.68	913	943	924	916.66
SCW	NO	High	2.00	33.60	22.30	16.04	909	936	921	914.57
TW	YES	Low	56.90	72.30	64.20	61.24	995	1064	1038	1019.36
TW	YES	Middle	56.90	79.10	70.07	62.78	995	1071	1042	1021.49
TW	YES	High	57.10	77.60	66.08	71.00	995	1059	1041	1022.42
CW	YES	Low	57.50	74.00	64.40	62.97	1047	1104	1088	1069.05
CW	YES	Middle	58.50	78.70	71.60	69.31	1045	1093	1080	1064.33
CW	YES	High	59.30	80.20	72.60	70.14	1044	1095	1080	1064.19
STW	YES	Low	57.40	72.00	64.80	62.61	1001	1071	1044	1026.72
STW	YES	Middle	57.50	78.10	70.80	68.20	998	1052	1039	1023.01
STW	YES	High	57.20	76.30	69.70	67.17	1000	1061	1040	1022.90
SCW	YES	Low	56.80	72.30	63.70	62.06	1005	1067	1050	1029.78
SCW	YES	Middle	57.20	76.70	69.40	67.02	1003	1075	1043	1026.01
SCW	YES	High	57.60	78.40	70.50	67.65	1002	1063	1044	1026.38

for Raspberry Pi4.

The obtained results indicate that, in the idle state, CPU utilization remains below 5% for Raspberry Pi 3 and below 3% for Raspberry Pi 4, while memory usage is approximately 346 MB and 692 MB, respectively. When the system is initialized without input data, CPU utilization remains largely unchanged, while memory usage increases by approximately 104 MB (Pi 3) and 146 MB (Pi 4). Under full workload with camera input, Raspberry Pi 3 exhibits CPU utilization exceeding 95%, indicating resource saturation. The memory usage in this case increases moderately but does not represent a limiting factor. This results in significant latency (i.e., exceeding 9 s), indicating that real-time processing is not achievable on this platform. In contrast, Raspberry Pi 4 maintains CPU utilization below 75%, enabling stable real-time processing with latency below 3 s.

To provide a more comprehensive evaluation, end-to-end latency is analyzed using multiple statistical measures, including the minimum, maximum, median, 95th percentile (P95), and average values. The obtained measurements are expressed in milliseconds and rounded to integer values. In the scenario without camera input, the total latency is calculated as the time difference between the detection of a sudden acceleration event and the timestamp of the last message describing the given event. With camera input, the total latency is calculated as the time difference between the detection of a complex event and the timestamp of the last message describing the underlying sudden acceleration event. The results are summarized in

Table 13. Results of comparing latency on RPi3 and RPi4.

Case	Camera	Volume	PRi3-SUMO-CEP-Latency					PRi4-SUMO-CEP-Latency
			MIN	MAX	N95	MED	AVG	MIN	MAX	N95	MED	AVG
TW	NO	Low	912	1973	1763	962	1081	912	1973	1753	961	1078
TW	NO	Middle	941	2780	1899	1028	1230	925	2765	1888	1010	1219
TW	NO	High	949	2808	1905	1038	1237	949	2792	1894	1033	1231
TW	YES	Low	1547	16,361	13,083	6994	7212	1575	3004	3001	2243	2160
TW	YES	Middle	1712	18,234	14,945	7727	7884	1654	7082	4655	2117	2478
TW	YES	High	1789	20,658	16,317	8042	8556	1662	7010	3864	2444	2622
CW	NO	Low	961	1976	1962	976	1163	961	1962	1960	969	1190
CW	NO	Middle	968	2815	1905	1037	1243	961	2799	1885	1027	1237
CW	NO	High	977	2822	1911	1045	1248	962	2822	1905	1039	1244
CW	YES	Low	1464	17,639	14,527	7453	7641	1510	2325	2997	2123	2158
CW	YES	Middle	1637	21,973	17,752	9584	9818	1591	6111	3855	2144	2280
CW	YES	High	1812	23,156	18,834	9741	9926	1623	7107	3120	2304	2393
STW	NO	Low	1064	2110	1916	1105	1227	1064	2110	1916	1103	1226
STW	NO	Middle	1018	2987	2062	1175	1377	1018	2987	2034	1167	1366
STW	NO	High	1030	2960	2063	1178	1383	1015	2960	2055	1173	1377
STW	YES	Low	1947	18,322	15,214	8136	8328	2405	5405	3781	2207	2398
STW	YES	Middle	2012	22,551	18,338	10,171	10,393	2164	3547	3483	2250	2404
STW	YES	High	2086	23,843	19,521	10,429	10,614	2268	6935	3812	2478	2699
SCW	NO	Low	967	2032	1840	1014	1138	967	2017	1840	1010	1136
SCW	NO	Middle	968	2869	1956	1080	1283	979	2869	1945	1071	1272
SCW	NO	High	961	2870	1960	1091	1290	961	2870	1952	1066	1280
SCW	YES	Low	2591	17,408	14,131	8043	8267	1687	3426	3320	2064	2206
SCW	YES	Middle	2654	20,279	16,992	9778	9931	1788	5335	3670	2645	2641
SCW	YES	High	2532	22,611	18,264	9997	10,503	1958	6554	3239	2382	2425

.

The results of complex event detection tests are given in

Table 14. Results of testing detection of CEP on Raspberry Pi3 (without camera) and Raspberry Pi4 (with camera).

Case	Volume	PRi3-CEP-with no Camera						PR4i-CEP-with no Camera
		Num. E.	MIN	MAX	N95	MED	AVG	Num. E.	MIN	MAX	N95	MED	AVG
TW	Low	76	72	794	753	396	403	76	17	485	471	97	219
TW	Middle	121	16	1234	1086	484	531	122	16	1079	969	305	384
TW	High	190	61	1211	1094	688	661	190	32	1203	951	492	464
CW	Low	73	31	1078	1039	455	534	74	32	1281	949	250	371
CW	Middle	108	124	1081	984	533	544	109	16	1053	922	486	497
CW	High	208	31	1046	966	504	521	210	16	1141	986	422	486
STW	Low	87	62	1188	1127	846	721	90	47	879	826	481	461
STW	Middle	205	62	1157	1149	640	615	208	31	1015	953	453	487
STW	High	208	15	1281	1163	445	526	217	15	1078	938	453	487
SCW	Low	90	140	1097	1066	657	626	90	47	906	786	428	426
SCW	Middle	203	47	1190	1125	751	696	204	16	1234	987	490	495
SCW	High	212	31	921	863	478	479	216	15	1099	1037	485	493

. As observed above, Raspberry Pi 3 was unable to process both the image and the rules in real time; therefore, it was used exclusively for rule processing, while the computer vision task of pedestrian detection was handled separately. The number of pedestrians at the intersection was provided to the Raspberry Pi 3 by the Raspberry Pi 4. The delay was calculated as the difference in time (in milliseconds) between detection of two consecutive sudden accelerations of a vehicle in a lane (i.e., $(\exists i\in L)(N_1(i,t,T,A_{thr})\ge 2)$, cf. Equation (2)) and detection of a complex event (cf. Equation (6)).

4.3. Discussion

The comparative analyses demonstrated that the Raspberry Pi 3 and Raspberry Pi 4 were capable of processing up to 2600 messages per second within the eKuiper CEP Docker when no computationally intensive image processing is involved. Under those conditions, the difference in response time between the platforms was less than 50 ms. When a camera was introduced as an additional sensor for continuous image processing, the experiment showed that only the Raspberry Pi 4 (with 4 GB of RAM) performed satisfactorily. The Raspberry Pi 3 exhibited significantly longer image processing times compared to the Raspberry Pi 4 platform. Additionally, the interval between successive event transmissions increased with higher message rates, ranging from approximately 1.06 s to 1.24 s.

Table 11 and Table 12 show that the window type had minimal impact on CPU and memory usage in the scenarios without camera input, i.e., the differences between CPU and memory usage for different windows remained under 3%. However, the hardware differences were pronounced: CPU utilization on Raspberry Pi 3 rose from 20% to around 60% (P95), whereas for Raspberry Pi 4 it remained stable between 11% and 23% (P95). This highlights the insight that the hardware configuration has greater influence than window setting.

The sliding windows detected the most events, emphasizing the importance of proper window selection. In addition, Table 11 and Table 12 show that the selection of window type does not critically interacts with hardware limits, implying that the preferred selection of sliding windows does not open additional hardware or safety requirements. Finally, it should be noted that the considered use case focused on pedestrian presence and sudden vehicle acceleration, but the reported architecture is rather general and can accommodate other traffic safety rules based on additional sensor input aimed at enhancing context-aware event detection (e.g., related to unexpected stops, congestion, vehicle proximity, heavy vehicle presence, weather and lighting conditions, etc.).

5. Conclusions

The development of smart systems, such as Smart Cities, requires real-time data processing that is aware of the temporal context in which events occur. This paper proposed a design of a containerized edge architecture based on a lightweight CEP engine, the Docker containers and the Message Queuing Telemetry Transport protocol (MQTT), aimed at real-time high-volume traffic data analytics. It also presented a comparative performance analysis between the Raspberry Pi 3 and Raspberry Pi 4 platforms, investigating the hardware limits of resource-constrained edge nodes when performing concurrent real-time video inference and complex event processing. The study demonstrated that low-cost edge devices, such as Raspberry Pi 4, can successfully support integrated stream processing and computer vision-based event detection, enabling timely alerts and enhancing traffic safety without relying on a cloud infrastructure. Future work will explore distributed resource management for multimedia data using platforms such as Apache NiFi and MiniFi, as well as dynamic adaptation of processing rules based on broader contextual factors, including city-wide conditions, time of day, and other environment-specific characteristics relevant to smart-city deployments.