# A Synergistic Elixir-EDA-MQTT Framework for Advanced Smart Transportation Systems
## 6 Evaluation
### Fault Tolerance Testing  
In fault tolerance testing, we designed two primary experimental scenarios to assess the system's performance on fault tolerance: interruptions of the MQTT Broker service and terminations of Elixir processes. The system's response in these scenarios reflects its recovery capabilities and robustness. * MQTT Broker Service Interruption: In this experiment, we demonstrate the system's resilience when a critical communication component fails. With the MQTT broker positioned at the network edge, maintaining the integrity of complex event transmissions is crucial, especially when encountering unforeseen incidents such as power  
Figure 10: Different constrained network conditions testing. outages. Equally important is the ability of MQTT clients to reconnect and quickly return to low-latency operations. As shown in the logs and the accompanying figure, we simulated the latency variations during a broker power outage and subsequent restart. Here, latency refers to the delay experienced by the passenger application in reconnecting to the restarted broker. The log data, with initial latencies exceeding 3000 ms back to the average condition of 10 ms, indicate that the reconnected passenger application rapidly processed messages sent during the outage. When the broker is powered down, the connection between the broker and clients breaks down immediately, the message sent by the driver application will be stored in the broker immediately, and the passenger will automatically keep trying to reconnect and listen to the same topic. When the MQTT broker is powered again, the system will process the omitted events first then quickly return back to normal performance. The system swiftly transitioned from high latency back to low latency, demonstrating rapid recovery capabilities. * Elixir Process Interruption: Before the details of the experimental setup, it is necessary to briefly explain the language logic of Elixir that underpins its fault tolerance. In BEAM-based systems, resilience is fundamentally rooted in the complete isolation and independence of each process. This isolation is a key aspect of Elixir's fault tolerance, ensuring that a crash in one process does not affect others. BEAM processes are lightweight, concurrent entities managed by the virtual machine (VM), which schedules their execution. Typically, BEAM employs as many schedulers as there are available CPU cores, with each scheduler operating in its own thread, while the entire VM runs within a single OS process [38]. Figure 11 shows a simplified version of the real experiment environment. Moreover, each process can maintain its state and communicate with other processes to manipulate or access this state. In Elixir, data immutability is a core principle. Processes act as containers for this data, preserving immutable structures over time, sometimes indefinitely. In addition to its inherent resilience, Elixir further enhances fault tolerance through the implementation of specialized supervisor processes. These supervisor processes are solely responsible for supervision processes, which are called child processes. Whenever a child process terminates, the supervisor promptly initiates a replacement, utilizing various strategies to manage these processes. This approach effectively reduces the cascading failures and the frequency of restarts that might be triggered by linked process crashes. Our experimental setup within the passenger application is depicted in Figure 11, which includes a primary supervisor executing the rest_for_one strategy. This strategy ensures that when a child process crashes, the supervisor terminates all subsequently listed processes in the child specification. This is particularly crucial for Process_1, which gathers other system components and needs to maintain consistent state updates to avoid data conflicts. Both the SystemSupervisor and ServerSupervisor employ the one_for_one strategy, whereby the crashing and restarting of their supervised processes do not impact the operation of others.