A general framework of multiple coordinative data fusion modules for real-time and heterogeneous data sources

3.1 Modelling and design

In coordinative network approaches, the ability to share information among subsystems in the network is important to enhance the network-based system’s judgment and decision-making process. Subsequently, in the MCDFM framework, we assume that each node in the network performs DF to produce local decisions before performing any global data manipulation with a coordinative decision approach. The MCDFM consists of several DF modules. For each module, there are three main DF processing phases: preprocessing, filtering, and decision. Figure 2 shows the MCDFM framework that consists of three main stages to achieve local and coordinative decisions. The following subtopics provide a brief overview of the preprocessing, filtering, and decision-making processes that are applied in Section 4.

Figure 2

The MCDFM framework.

The decision for each DF module, indicated by D F 1 … n is known as a local decision. This module evaluates the condition or state of the data source variables being observed over time. Agent-based module provides mechanisms that play essential roles in achieving coordinative decision. The agents enable the modules to interact in attempt to better describe an observed situation and make accurate decisions. Depending on the selected DF method’s ability, knowledge sharing and information exchange are performed by the agents to achieve a decision at a higher or coordinative level.

Let x represents the data that needs to be incorporated, which consists of { x 1 , x 2 , … , x n } . x represents various kinds of data from various sources such as sensors or cloud-based systems, in the form of historical or real-time data. Let P be the preprocessing algorithms of the proposed DF module, which consists of { p 1 , p 2 , … , p n } . During the P stage, various algorithms are implemented depending on the sensing method and type of data collected to ensure data completeness, consistency, and format. Let F represents the filtering technique, which consists of { f 1 , f 2 , … , f n } . The complexity of the sets of data has a close relationship with the selection of methods to produce an estimation of features. For example, homogeneous and heterogeneous data may require different DF methods, and in some scenarios, a combination of both data complexities requires more than one method to perform feature estimation.

Let D be the decision method that is incorporated in the proposed module to achieve the desired outcome. Each block which consists of P , F and D is denoted with D F , which consists of { D F 1 , D F 2 , … , D F n } . As shown in Figure 2, each D F module produces a local decision at the output. Let D l represents the local decision for each D F , which consists of { d 1 l , d 2 l , … , d n l } . Let D c be the coordinative output, which consists of { d 1 c , d 2 c , … , d n c } .

All data types are fed to each D F module (denoted with D F 1 to D F n ). At the output of the DF preprocessing, filtering, and decision, the result D l is produced. The MCDFM framework contains n number of D F modules that contribute to the coordinative approach. A coordinative output, D c , is achieved after reasoning and manipulation of all D l s made by each D F module. We design the proposed framework to fit a data-responsive application that requires a high-efficiency rate and accuracy. However, the efficiency and accuracy are tightly related to the chosen algorithms in the preprocessing, filtering, and decision phases. For MCDFM discussion purpose, we provide a conceptual example scenario of the TLC system to understand the implementation better. This issue is elaborated on in Section 4.

3.2 Case study

The proposed framework is intended for any field of study that requires MCDFM to support the system operation. This case study explains the implementation of the MCDFM framework by considering the TLC system. The case study scenario focuses on three road intersections along with Jalan Klang Lama, Kuala Lumpur, which are labeled as S903, S904, and S905. Figure 3 shows the location of the MCDFM framework case study.

Figure 3

The location of the case study in Kuala Lumpur.

Each TLC is equipped with its own control unit to handle traffic operations and to collect raw traffic data. The intersections network faces heavy traffic flow during a certain time of the day from S903 (Kuala Lumpur), going down to S905 (Puchong). The distance between S903 and S904 is 450 meters, while S904 to S905 is 500 meters. Figure 4 shows the overview of the heavy flow directions. The blue color arrows show heavy traffic direction movement from one intersection to the adjacent junction.

Figure 4

Heavy flow direction from S903 to S905 (right to the left).

Due to the short distance between S904 and S903, S904 tends to have a spillover queue that interrupts S903 performance during the peak hours of the day. During this condition, whenever the green signal is given to KL – Puchong direction from S903 to S904, no car can leave the yellow box at S903 due to S904 overwhelmed traffic condition. This scenario proves that other intersections can influence each intersection’s performance in the same movement direction, which indicates that they should be observed as a network of intersections. The coordinative frameworks can give a better overview of intersection conditions to improve TLC decision-making.

4.1 Test setting

This section further discusses the applicability of the MCDFM framework in a TLC system. The major goal of this case study is to show how the suggested framework addresses traffic congestion as a domain problem. Table 2 shows example data of S904 for movement direction from north to south.

The sample data is divided into three categories, which are nonpeak, medium peak, and peak periods. Available features in the example data are source, speed, latitude (lat), longitude (lon), and time. The heading indicates the vehicle movement direction where “N” stands for north while “S” refers to south. The source represents each individual vehicle identified as GPS16, GPS17, GPS18, GPS19, GPS20, GPS21, GPS22, GP23, and GPS24. Speed represents vehicle speed, while lat and lon represent latitude and longitude of a vehicle. Time in the sample data indicates the time a record is captured.

4.2 Test scenario

Three different scenarios are identified: nonpeak, medium peak, and peak periods. However, only a few sample data are included for discussion purposes to emphasize three different traffic scenarios. Each unique source (sample data in Table 2) represent a vehicle. The accumulated count of unique sources within a predefined time interval represents the number of vehicles at the intersection. The speed column in the data holds the speed of vehicles at a specific location within a specific time interval. Finally, the location of each vehicle describes the distance or gap between vehicles on lanes. These five kinds of input go through preprocessing, filtering, and decision phases, based on selecting suitable methods for each phase. DF techniques chosen for the MCDFM framework are shown in Table 3.

The techniques utilized for preprocessing steps are data cleansing and windowing. The estimation technique chosen for the MCDFM framework is EKF, while Fuzzy Logic is used as a decision phase method to produce a congestion level at an intersection.

In this scenario, each TLC acts as an independent D F module ( D F 1 , D F 2 , … , D F n ) of MCDFM; therefore, each TLC is represented as D F 1 (S903), D F 2 (S904), and D F 3 (S905). Each TLC collects the required traffic data ( { x 1 , x 2 , … , x n } ), which in this case, are speed, source, time, latitude, and longitude within a certain interval of time ( t ). After performing preprocessing ( { p 1 , p 2 , … , p n } ), filtering ( F ), and decision ( D ), local decision ( y ) is generated. Average count, average speed, and average density are features that are produced within a specific interval (60 s) from sets of data. The average speed feature is generated from the estimation of single column data over time, while average count and average density are derived from a combination of more than one column that exists in the dataset. Fuzzy logic utilizes all of the features to determine a crisp set of congestion indicators. Table 4 shows traffic features and their variable states.

Fuzzy sets of average count features are identified as low volume, medium volume, and high volume. This value tells how many vehicles pass through an intersection within a specific time interval. Average speed indicates the distance a vehicle travels within a specific time interval. This variable is categorized as low speed, medium speed, and high speed. Figure 5 shows the coordinative calculation of (a) minimum speed, (b) average speed, and (c) maximum speed to find a relational pattern between the streets in terms of speed.

Figure 5

Speed coordinative calculation: (a) minimum speed calculation, (b) average speed calculation, and (c) maximum speed calculation.

The average density measures the number of vehicles occupying a certain length of the road segment by lane. This feature reflects the actual vehicle flow at a specified time, and usually, movement patterns are easily predicted during the nonpeak hour and peak hour periods. It is identified as low density, medium density, and high density. Figure 6 shows the average density calculation in the coordinate approach to obtain the global view of the coordinate features.

Figure 6

Calculation of average density as a coordinate feature.

Fuzzy logic fuses all of these features to achieve a decision for the individual TLC. Table 5 shows an example of the decision of fuzzy logic. In this example, fuzzy rules are set in five congestion level indicators: very low congestion, low congestion, medium congestion, high congestion, and very high congestion. In Table 5, only three examples are given to demonstrate fuzzy membership. These membership functions need to be converted to a crisp value that drives the system to better decisions and improvements.

This congestion indicator describes the situation of the covered area of each individual TLC at the microlevel. The coordinative approach has an important role to play to obtain a global view of the intersections network. The interactions between the D F modules ({ D F 1 , D F 2 … , D F n }) gather local decisions to improve the overview of the road condition for certain vehicle movement direction. For example, the heaviest flow and heavy traffic jam created at S905 are the microlevel of observation, but to solve this traffic issue, a clear picture of the whole network condition (from S903 to S905) is considered. Figure 7 shows the GUI of Sena Traffic Control Center (Trafficsens) of the case study.

Figure 7

The Sena traffic control center (Trafficsens).

4.3 Results and discussion

Contingency actions provide various mechanisms to deal with unforeseen real-time circumstances at intersections. TLC operations at S903 and S904 should be responsive and adaptive to the current condition in order for S905 to avoid the worst-case scenario. A coordinative decision visualizes the big picture of the problem being observed, and this is how the response mechanism reacts according to the need of the system. For TLC-related study, coordinative output could help in determining traffic movement with the heaviest flow, incident detection, sensor fault, and green time optimization. Table 6 shows the result of D F module based on the features derived from three different test scenarios at S904. This result is presented in 60 s time frame.

In this case study, road users along Jalan Klang Lama experience heavy traffic during peak periods in the morning, when most vehicles enter the city center and leave the city toward the residential areas in the evening. The nonpeak period occurs during holiday seasons or public holidays. At other times, road users experience the medium peak periods, especially for Kuala Lumpur – Puchong direction (S903 to S905).

From the results, the intersections experience very smooth traffic movement during the nonpeak periods by achieving very low congestion levels. This condition occurs in two different ways. First, when there are fewer vehicles on the road with medium speed but low density, or a medium number of vehicles with medium speed and low density. Second, during the medium peak period, vehicle speed and density are at the average level. This scenario illustrates a smooth traffic movement with the average number of stops compared to the previous scenario.

The peak period is when almost every vehicle in the lanes experiences the greatest number of stops. This means fewer vehicles pass through within a certain interval, with a low average speed value and high density. This is the condition when the road is fully occupied, having a high congestion level. Each traffic data from the intersections in the network needs to go through the same DF stages (preprocessing, filtering, and decision) to produce a congestion level value as a local decision. An example of a local decision is shown in Figure 8, which shows five congestion levels (very low congestion, VLC; low congestion, LC; medium congestion, MC; high congestion, HC; and very high congestion, VHC).

Figure 8

The local and coordinative decisions of each DFM.

A congestion level gives the idea of each intersection’s current situation, whether it is experiencing smooth vehicle movement or suffering from overloaded conditions. Figure 8 depicts a 15-minute congestion level situation for all S903 ( D F 1 ), S904 ( D F 2 ), and S905 ( D F 3 ) and the coordinative MCDFM. The faded blue line in the chart shows the boundary of five congestion levels (VLC, LC, MC, HC, and VHC). Table 7 shows a summary of the D F module’s decisions that describe the transition of traffic conditions over time.

The collective output from each D F module is the essential step to achieve a coordinative decision. In this example scenario, each TLC acts as a software agent that provides autonomous response to the environment condition. The reaction depends on the situation the intersections network is experiencing as the outcome of the coordinative decision. Based on the scenario discussed, the coordinative decision informs which movement direction suffers from HC and VHC condition together with the time. With coordinative decisions achieved, various control mechanisms can be deployed to improve traffic conditions. Based on Table 7, during the nonpeak periods, all the intersections experience VLC and LC, which indicates that the green time duration given to each TLC manages to control the number of vehicles that pass through each intersection.

The medium peak period shows that S903, S905, and MCDFM experience MC conditions, and only S905 experiences HC with high vehicle volume. However, during the peak period, S903 and S904 experience VHC conditions, S905 experiences MC, and the entire route of the MCDFM experiences HC. Consequently, road users experience a higher number of stops to wait for green, stuck in the yellow crisscross grid (box) area, and longer travel time. The coordinative results of the MCDFM during the peak period at 17:45 and 19:00 are categorized as HC and VHC accordingly. This coordinative decision helps the TLCs provide a better mechanism for handling these situations, such as performing dynamic green time allocations based on the needs and traffic coordination for a set of traffic movements that suffer from heavy congestions. This action reduces the number of vehicles at each intersection quicker, while reducing the time required to solve this problem.

This work attempts to propose the MCDFM framework for environments with heterogeneous and real-time data sources. The proposed framework provides a robust, flexible, and responsive coordinative system of multiple data fusion design. The related works, such as Moattari and Majd [34] and He et al. [35], proposed a centralized estimation for global or coordinative decision-making, which manifests the disadvantages of the centralized systems. Fortino et al. [36] proposed a collaborative DF framework of a specific domain of homogeneous body sensor networks. Bienzeisler et al. [37] and Elmas and Sönmez [38] proposed a multi-agent system’s collaborative decisions and considered the centralized approach. Comparing with the related works, the MCDFM framework provides coordinative features as part of multiple data fusion modules. The coordinative framework of a multi-agent system provides various merits other than the ability to communicate. The abilities to share resources, perform information exchange, and produce coordinative decisions that contribute to the flexibility and robustness are some other merits that we attempt to fully utilize in the MCDFM framework.

We address a few limitations of the MCDFM framework related to its development and validation as follows: (i) The proposed framework is yet to be implemented in a real-world TLC system and needs more proper testing. (ii) More data, methods, and evaluation metrics need to be considered in the testing scenarios. (iii) The framework needs to be tested in several domains to demonstrate and verify its general applicability.