Tracking Reported Vehicles in Traffic Management and Information System using Intelligent Junctions

JOURNAL OF INFORMATION SCIENCE AND ENGINEERING 26, 883-896 (2010) Tracking Reported Vehicles in Traffic Management and Information System using Intelligent Junctions ATILLA ELCI1, BEHNAM RAHNAMA2 AND AMIRHASAN AMINTABAR3 1 Computer Engineering Program Middle East Technical University Kalkanli, North Cyprus, Mersin 10, Turkey 2 Department of Computer Engineering European University of Lefke Gemikonagi-Lefke, North Cyprus, Mersin 10, Turkey 3 School of Computer Science University of Windsor Ontario, N9B3P4 Canada This study highlights a security scenario involving vehicles in a Traffic Management and Information System (TMIS) network. TMIS and its nodal architecture, nicknamed Intelligent Junction (IJ), are summarized from our recent work. System design sets an example to a software architecture implementing autonomous semantic agents through semantic web services, junction-based sensor networks, local- and wide-area networking through wire/wireless integrated communication infrastructure. It is so construed as to provide (near-) real-time services throughout the network. This introduction is with reference to the SOA of Cooperative Labyrinth Discovery Robotics and Traffic Management and Information System Projects. This also takes up several issues including realtime goal-oriented coordination of semantic web services. Especially described are its essential functions crucial to aid security applications. A security scenario concerning tracking and routing reported, say missing, vehicles is considered and shown how to graft it onto TMIS network. Simulation results show promising outcomes. Performance of the system in terms of mean response time is analytically derived. Simulation and analytical results agree. Research involving similar development base is suggested. Keywords: semantic web services (SWS), multi-agent systems, intelligent junction, TMIS, vehicle tracking, traffic network, service ontology 1. INTRODUCTION Traffic Management and Information System (TMIS) application manages a traffic network and avails information. It is a distributed autonomous application designed using semantic web technology, SOA, and multi-agent systems approach. It is implemented through interconnecting “intelligent junctions” in the topology of an urban traffic network. TMIS, due to its intelligent junction (IJ) base, proves decisive in tracking missing vehicles. Quick and efficient response of traffic operators to emergency incidents is vital. Wang et al. [1] presented an efficient layered architecture for such emergency system. Their simulation platform of traffic emergency management system consists of four parts, namely, Incident Detection and Verification Unit, Automatic Dispatch Unit, Scene Display Unit and Evaluation Unit. This modular architecture improves the efficiency in responding incidents. Received March 31, 2009; accepted September 30, 2009. Communicated by Chih-Yung Chang, Chien-Chung Shen, Xuemin (Sherman) Shen, and Yu-Chee Tseng. 883 ATILLA ELCI, BEHNAM RAHNAMA AND AMIRHASAN AMINTABAR 884 Several systems monitor the traffic arrivals and adjust timings in relation to the noticed inputs. Traffic Detectors are varied from metal detectors to advanced image recognition and plate readers. Metal detectors are the most popular in use. Image recognition devices fail in correct recognition and plate reading during bad weather and light illumination. Accordingly, it is necessary to develop an efficient solution, easy to implement with reasonable expenses, and without suffering of humidity situations. This paper initially introduces salient design features of TMIS/IJ in section 2. TMIS design has recently been considered at length [2]. TMIS design choices using autonomous semantic agents lead to new software architecture for distributed environments. Message passing performance of TMIS was studied to estimate its overhead. Design of IJ is introduced in section 3 from one of our recent study [3]. It involves employing autonomous semantic agent based software, sensor networks, and wire/wireless integrated communication infrastructure. Then section 4 introduces a security scenario concerning tracking and reporting of missing vehicles. Service application implementing the scenario and its algorithm are described. In order to evaluate performance of this application, in section 5 TMIS is simulated to use in obtaining steady-state response times. An analytical expression is derived for the same in section 6. Performance comparison by both methods is given in section 7. Section 8 provides a summary and the conclusions of the paper. 2. TMIS ARCHITECTURE TMIS uses IJs as its core. Junctions provide the required information for Junction Management unit. The rest of the system is an information system for collecting and retrieving the required information using semantic web technology. TMIS architecture and its components are illustrated in Fig. 1. Environment Variables Set Junction Junction Manager SWS GPRS/ EDGE/ WiMAX Junction Manager SWS GPRS/EDG E / Wimax TMIS Server Environment Variables Set Critical Path Finder TCP/IP Network UDDI Server ƒ ƒ ƒ Shared TMIS Ontology Database of: Policies User I/F Reporting Emergency Service API Ambulanc Critical Path Navigator e Services Facilitator Environment Variables Set Client Monitoring Fig. 1. TMIS architecture and its components [2]. A client-server solution is possible for such a system, yet it could create a bottleneck at the central site. On the contrary, service-oriented architecture (SOA) & Semantic Web Services (SWS) agent approach distributes load to network by delegating capability to processing nodes [4, 5]. TRACKING REPORTED VEHICLES IN TMIS USING INTELLIGENT JUNCTIONS 885 IJ utilizes semantic web technology to represent network topology, node configuration, and business policy. It responds to information requests; where it does not have the required data, it cooperates with neighbors that may involve broadcasting the query to the network and collating responses. All such communication takes place through messaging. In the following we study the overhead caused by messaging. 2.1 Networking Infrastructure Mobile broadband networks such as WiMAX and 3G are convenient technologies in implementation of TMIS. Positions of IJs are fixed at crossroads and junctions; however, providing a TCP/IP service through wired connection in a wide area such as a metropolitan city is not a recommended solution. On the other hand, a lot of telecommunication companies provide wireless mobile broadband services. Therefore, each IJ is equipped with a wireless broadband modem enabling it to communicate with other IJs and other nodes in the TMIS network as shown in Fig. 1. Lengths of messages passing through TMIS network (cloud) is very short, generally message tag, representing its type, information of transmitting node, and finally missing vehicle info. Therefore, the scheme is practical even in low bandwidths. 2.2 Simulation of Message Passing in TMIS Message broadcasting modus operandi might cause excessive load on TMIS thus invalidating any advantages gained. In order to determine its behavior, and work out an upper bound on the number of messages, simulation experiments were carried out. Simulation of network models of sizes one up to ten ASAs (IJs) for traffic network was conducted using Message Passing Interface 2.0 [6] on VMware v.5 Parallel Virtual Machine [7]. Three different traffic network models were considered based on topology: linear, intermediate, and mesh. In linear network junctions line up along the path, essentially there are no intersections. The linear model is the simplest of the three; although unrealistic, it is included here as a boundary/best case. The mesh model is the most complicated traffic network consisting of fully inter-connected junctions; definitely quite unrealistic as traffic networks come. The mesh model is included here as the worst-case topology. On the other hand, the intermediate model is regarded as quite realistic. Table 1 depicts the maximum number of total messages passed in the network due to propagation of a single message from one node. Obviously these are worst-case scenarios. The numbers are given for all three models. The same is charted in Fig. 2. Table 1. Max number of propagated messages in all models for up to 10 ASAs. # of Nodes 1 2 3 4 5 Linear Model 0 1 2 3 4 Number of Messages Intermediate Fully Model Connected 0 0 1 1 3 3 5 6 7 10 # of Nodes 6 7 8 9 10 Number of Messages Linear Intermediate Fully Model Model Connected 5 9 15 6 11 21 7 13 28 8 15 36 9 17 45 886 ATILLA ELCI, BEHNAM RAHNAMA AND AMIRHASAN AMINTABAR 50 Number of Messages 45 45 Fully Connected Mesh 40 36 35 30 28 25 21Intermediate Model 17 15 13 11 9 8 7 6 20 15 15 10 5 1 0 0 1 2 3 10 7 4 6 5 3 3 2 4 5 9 5 6 Linear Model 7 8 9 10 Number of Nodes Fig. 2. Number of passed messages versus network size. Simulation of network models showed close to linear incremental load on the communication network. For example, for a typical network (intermediate model in Fig. 2) representative of real traffic junction system, message load increased only linearly with the number of IJs. 3. IJ: INTELLIGENT JUNCTION Intelligent Junction (IJ) is an essential component of the TMIS model introduced above. IJ administers its junction lights, senses vehicles from the moment they approach till they leave the junction, recognizes and interacts with them meanwhile noting all contextual implications. IJ implements the conventional junction lights management taking guidance from the policy delegated to it; yet it performs autonomously also heeding local traffic situation and other prevailing exigencies. In doing so, IJ consults its ontology and contextual knowledge base. It cooperates with and complies with requests coming from the neighboring IJs and from the TMIS application running in the central facility. These issues have already been taken up in hour earlier work [2, 3]; so a summary statement is given below. Fig. 3 displays IJ in schematics. IJ may be likened to a processing node if TMIS is taken for a grid. IJ is a composition of Junction Manager Software (JMS), its associated policy, ontology and database, server platform, various peripherals consisting of sensors, displays, traffic lights, networking and communication links. The Junction Manager Software (JMS) performs usual administration and information functions for a junction: handling traffic lights, driving information displays, controlling sensory network, communicating with the wide area network, and interacting with vehicle/driver client. JMS provides much of this functionality through semantic Web services interface. IJ is normally in contact with inhabitants of the junction (vehicles, drivers, passengers, and pedestrians) through elaborated sensor, communication, input and display networks laid out in the junction. For example, as a vehicle enters a junction, it gets noticed through its vehicle RFID tag being sensed. Subsequently, IJ can further find out about a vehicle in its junction database; alternatively, it may inquire neighboring IJs, leader junction, and the central server applications for the same. Such ubiquitous sensing can readily be put to application in security needs [9]. TRACKING REPORTED VEHICLES IN TMIS USING INTELLIGENT JUNCTIONS Junc. Mgr SWS Lights & Displays 887 GPRS / EDGE / WiMAX RFID sensors Fig. 3. Intelligent Junction at a divided road intersection. 4. TRACKING AND REPORTING A VEHICLE IN TMIS/IJ Vehicle tag is a remotely-sensed identification device (possibly a RFID tag) inconspicuously attached to a vehicle such as part of its chassis number sticker, the number plate, or embedded inside dashboard. It allows identification of a vehicle uniquely through its particulars such as make, model, year, chassis number, etc. It may even contain registration and ownership data also allowing updating. Alternatively, the tag can simply supply a unique key identifying the vehicle which is used to fetch the corresponding information from databases. IJ maintains its local databases among which two are of prime interest in this vehicle tracking security application: the Report-At-Sight (RAS) and Vehicle Sighting Exception (VSE) lists. RAS contains details of vehicles reported as missing and not-yet-located or cleared. VSE contains the reports on missing vehicles detected by this IJ. IJ continuously screens its traffic by comparing vehicle tag info against its RAS. If a match is found, a VSE is then issued carrying additional data on locale, date, time, heading (direction, link). The VSE is sent to the neighboring junctions who then forward it to their neighbors. Eventually, VSE propagates to the junction that is executing the Vehicle Tracking and Reporting (VTR) application. VTR is a TMIS-wide specific service being offered by one of the junctions possibly the leader one. Alternatively, and possibly to be preferred if IJ configuration can support, VTR may be executing at each IJ. VTR can interact with IJ, poll its RAS/VSE lists, and request to route the suspect vehicle, all through IJ SWSs. VTR can propagate the sighting exception to other designated services/applications such as Traffic Department Legal Cases and Security Department Patrol Dispatch (TDLC/SCPD) for action at their end. Indeed, VTR is the prime interface with agents external to TMIS. A junction upon receipt of a Missing Vehicle Alert (MVA report indicating a missing vehicle), will take the following actions: (1) Store the missing vehicle’s information into its local database (RAS); (2) Start watching for the missing vehicle in its jurisdiction area; and, (3) spread this message to its neighbors. The missing vehicle’s information could be its plate number or its RFID tag value. One of the junctions also acts as the leader. The leader junction is directly in contact ATILLA ELCI, BEHNAM RAHNAMA AND AMIRHASAN AMINTABAR 888 with the TDLC/SCPD; sending any message to this junction, eventually leads to receipt of that message by the TDLC/SCPD and vice versa. Its duty, upon receipt of an MVA is listed as follows: (1) Record this information into the RAS List in its DB; (2) Also, report the alert to VTR application. Accordingly, an IJ upon sensing a missing vehicle in its jurisdiction area will report the fact in a VSE to its neighboring junctions. Consequently, the leader junction will also receive this report. The leader junction, upon receipt of a VSE will take two actions: (1) Report this result to the TDLC/SCPD; (2) Initiate a missing vehicle detected message (MVD) and announce it to other junctions to stop the search process. To do this, the leader junction propagates the MVD message to the neighboring junctions. As a result, a junction upon receipt of an MVD message, regarding the detection of the missing vehicle, understands that its duty to watch for that missing vehicle is over. The VTR application consists of several concurrent event handler threads such as (A) MVA Handler, (B) RAS Handler, (C) VSE Handler, and (D) MVD Handler. Each handles a specific task as explained below: a. Waiting for MVA message b. If MVA message received extract it from queue If corresponding RAS record does not exist 1. Create RAS record for received MVA message 2. Propagate MVA message to all neighbors A) else than sender a. Waiting for RAS record b. For each RAS extracted from queue: Compare passing vehicle against RAS record If matches, 1. Create corresponding VSE report B)2. Propagate VSE report to all neighbors else than sender a. Waiting for VSE report b. If VSE report received extract it from queue Propagate VSE report to all neighbors else than sender a. Waiting for MVD Message b. If MVD message received extract it from queue If corresponding RAS record is open 1. Close RAS record 2. Propagate MVD message to all neighbors else than sender C) D) Fig. 4. Work flow of simultaneous handlers at different IJs: MVA handler thread (A), RAS handler thread (B), VSE handler thread (C), and MVD handler thread (D). Above mentioned processes are depicted in the attached process diagrams of Fig. 5. 2. Create RAS 0. Missing vehicle incident IJ 1. MVA 12. Close RAS RAS VTR VSE 3. Propagate MVA TMIS Cloud 9. MVD IJ IJ 4. Matching vehicle 5. Create VSE 6. Propagate VSE 11. Close RAS VTR RAS VTR 7. Propagate VSE 8. Close RAS 10. Propagate MVD RAS VSE Fig. 5. Process diagrams showing sequence of events in TMIS according to Fig. 4. TRACKING REPORTED VEHICLES IN TMIS USING INTELLIGENT JUNCTIONS 889 In the rest of the paper, performance of TMIS/IJ in tracking and reporting a vehicle has been studied analytically and through simulation. Simulation configuration is being reported in the next section. Derivation of mean response time is then reported followed by comparison of response time findings for both approaches. 5. SIMULATION MODEL OF TMIS/IJ Tracking and reporting a vehicle in TMIS/IJ have been studied through simulation introduced here. It should be noted that in this simulation work the following have been granted as axioms: (1) A junction can contact its neighbors only; (2) A missing vehicle alert (MVA) may be raised (input by external actors) at any junction as well as at the leader junction or received by VTR Application from other external sources; (3) A missing vehicle may appear at any junction any time (Poisson distribution); (4) To stop screening junction traffic looking for a specific missing vehicle the leader junction (or any other with VTR Application) can issue an advisory (MVD) and propagate it over to all junctions. The TMIS network consists of four nodes internally interacting with others. The simulation model was organized as a set of segments, each of which representing activity of one junction. The number of segments can be varied to simulate the whole traffic network with different number of junctions. All segments are linked to one another to model a complete traffic system. The topology of the traffic network is a directed graph which is represented by an adjacency matrix where each entry is a directed link between two junctions. For example, in the adjacency matrix, the entry at (i, j) = 1 indicates that vehicles can travel from junction i to j, i.e., a one way link exists from junction i to junction j (Fig. 6). (a) (b) Fig. 6. A TMIS network (a) and its corresponding adjacency matrix (b). In the simulation approach, as well as modeling the traffic network, behavior of a missing vehicle is also investigated. A missing vehicle, in this system behaves in the following manner: on the entrance to a junction it decides on which junction to be the next destination. Hence, to simulate the behavior of the missing vehicle a set of probabilities is assigned to outgoing edges of each junction. These probabilities are stored in an exit probability matrix. In fact a missing vehicle leaving junction i, is assumed to choose its destination based on the probabilities listed in the row i of the exit probability matrix. Therefore, sum of probabilities in each row is 1. Fig. 7 (a) corresponds to exit probability values of Fig. 6 (a) In fact, the values of probabilities can be statistically derived from a longrunning observation over a real traffic system on the region and stored in a look-up table. 890 ATILLA ELCI, BEHNAM RAHNAMA AND AMIRHASAN AMINTABAR (a) (b) Fig. 7. (a) The exit probability matrix; (b) The time matrix (in min) related to Fig. 6. In the exit probability matrix, junction number zero indicates the area over which no junction has control, that is, the traffic area outside of TMIS jurisdiction. So, if a missing vehicle leaves from any junction to junction zero, it means that the missing vehicle is not in reach any longer. Another matrix maintains the average traveling time for each link. It is called time matrix throughout this work. A typical example of a time matrix associated with Fig. 6 (a) is shown in Fig. 7 (b). Again, these values can be statistically derived from a long term observation of traffic in a real system and estimated as in [8]. In Fig. 6 (b), the parameter k stands for unknown (and possibly unpredictable) values. In the time matrix NA stands for Not Applicable, where there is no link. In this simulation approach, the propagation delay of delivery of a message from a junction to its neighbors is assumed to be distributed exponentially. In the simulation experiment done on the network depicted in Fig. 6, this value is assumed to be 5ms which is in agreement with the actual delivery time of frames in LANs [10, 11]. Simulation was carried out in the simulation system MATLAB 7.5 in the Windows operating system. Since, from a simulation point of view, TMIS can be considered as a non-terminating system, its steady-state performance measures are of interest. To decrease the effect of the transient state, each simulation run was long enough to ensure that about 5000 MVAs happened in the system. Response time of TMIS was noted subsequently. Next section introduces a derivation of an expression for mean response time as a measure of performance. 6. ANALYTICAL PERFORMANCE OF TMIS/IJ To investigate the performance of TMIS in security applications such as tracking and tracing a missing vehicle, we are interested to see whether the system is able to detect the missing vehicle within a reasonable period of time. For this reason, response time is defined as the duration from which an MVA report reaches a junction to the time the corresponding VSE reached that junction from any junction that has detected the missing vehicle. This period is in fact the summation of the time needed for propagation of the messages in TMIS, plus the time starting from the alert reported till the time the missing vehicle appeared at one of the junctions. This can be defined in Eq. (1) as follows: RT = d(MVA) + TT + d(VSE) (1) where, RT is the response time, d(MVA) is the propagation delay of the MVA message, TRACKING REPORTED VEHICLES IN TMIS USING INTELLIGENT JUNCTIONS 891 d(VSE) is propagation delay of the VSE message back to the initiator junction. TT is the travel time which is the period from the initiation of an alert to the time the missing vehicle gets detected. It is clear that the propagation delays are negligible when compared to the time the missing vehicle travels to reach one of the junctions. Hence, we can make this approximation on Eq. (1) in Eq. (2). RT ≈ TT (2) When a vehicle is discovered missing, an actor usually reports this fact to the nearest junction which is termed as ‘the initiator junction’. From then on, by the time the missing vehicle reaches the next junction, the alert message MVA has already reached all the junctions. So, we can assume that if the missing vehicle is still inside the TMIS area, it will be trapped once exposed to the next junction. Hence, considering Eq. (2), the expression below is valid: m RTmean(i) ≈ ave (TT(i, j)) = ∑ AD(i , j ) × TT(i , j ) × P(i , j ) i ∈ {1..n}, m = n (3) j =0 where, RTmean(i) is the average response time for when the missing vehicle was departing the junction i at the time of alert. The ‘ave (TT(i, j))’ is the average travel time which takes the missing vehicle reaching one of the neighboring junctions. TT(i, j) is the travel time read from the time matrix, and P(i, j) is taken from the exit probability matrix and AD(i, j) is taken from the adjacency matrix. For example, considering the network given in Fig. 6, if we assume that when the alert was given the missing vehicle has just left junction 1, then the mean response time is estimated as follows: RTmean(1) ≈ 0 × NA × 0 + 0 × 0 × 0 + 1 × 7 × 0.4 + 1 × 11 × 0.6 + 0 × NA × 0 = 9.4 (4) which is independent of the parameter k. This phenomenon happens (1) while the missing vehicle roams well inside the TMIS, not on the boarder junctions, and (2) the missing vehicle is roaming at a border junction but the junction has no exit link to junction 0, that is, outside of TMIS. The assumption of roaming only inside TMIS is the same as setting to zero all the links leading to junction 0 in the adjacency matrix. Hence, in the expression Eq. (3) if we vary j starting from 1: m RTmean(i) (for ∀j = 0 AD(i, j) = 0) ≈ ∑ AD(i , j ) × TT(i , j ) × P(i , j ) , i ∈ {1..n}, m = n (5) j =1 where, none of i or j gets the zero value. Consequently k parameter will not appear in the Eq. (5). In general we don’t know in between which two junctions the missing vehicle was located when the alert reported. So, the average travel time between any two junctions in TMIS will give us a good approximation on the average response time: RTmean = 1 n ∑ RTmean(i ) . n i =1 (6) ATILLA ELCI, BEHNAM RAHNAMA AND AMIRHASAN AMINTABAR 892 Applying the Eq. (6) on any TMIS system returns RTmean in a linear combination of a number and the parameter k, which based on the results from the expression Eq. (5), it can be summarized below: 1 n m ∑ ∑ AD(i, j ) × TT(i, j ) × P(i, j ) = n i =1 j = 0 1 n 1 n m AD k P × × + ( ) ∑ (i,0) i,0 (i,0) n ∑∑ AD(i, j ) × TT(i, j ) × P(i, j ) ⇒ n i =1 i =1 j =1 RTmean = (7) RTmean = f(ki,0) + cte, i ∈ {1..n} where cte means a numeric value. Indeed, when the missing vehicle is outside the TMIS we can’t make any comment about it except that the average response time will be more than a certain amount which is cte in Eq. (7). So we shall use the Eq. (3) to compute the mean response time in cases where the missing vehicle is in TMIS area; and, in other cases, we simply state that it’s “unpredictable” due to the unknown “k” in expression Eq. (7). 7. COMPARISON OF PERFORMANCE FIGURES To compare the simulation results with that of the analytical modeling, we take TMIS of Fig. 6 as an example. Table 2 given below summarizes the simulation results and analytical approximations using Eq. (3). It shows a close match between the two approaches where the missing vehicle (MV) is assumed to be inside the TMIS area, here junctions 1 and 3 which have no direct connection to junction 0, the outside world. However, for the other junctions which have exits to the outside of TMIS, the simulation results come up with uncertainty wherever the missing vehicle can leave TMIS. For example, for junction 2 the result of simulation for when the missing vehicle has not left the TMIS, matches the analytical approximations. However, if the missing vehicle leaves junction 2 to junction 0 and in fact leaves the TMIS area, the result of simulation becomes unpredictable. Table 2 depicts the close agreement between simulation and analytical results for the response time. Table 2. Response time of TMIS in Fig. 6 initiating from different junctions. Node # Response time (min) Analytical 9.4 Simulation 9.4003 Node # Response time (min) 1 3 Analytical 8.7 Simulation 8.71 2 4.8 when the MV is inside the TMIS 4.8 + 0.6k2,0 otherwise. (k2,0 is unpredictable) 4.807 when the MV is inside the TMIS, Unpredictable otherwise. 4 4 when the MV is inside the TMIS 4 + 0.6k4,0 otherwise. (k4,0 is unpredictable) 4.0023 when the MV is inside the TMIS Unpredictable otherwise. TRACKING REPORTED VEHICLES IN TMIS USING INTELLIGENT JUNCTIONS 893 8. CONCLUSIONS, PROSPECTS & FUTURE WORK This study presents findings on performance of a system designed based on distributed autonomous application using semantic Web technology, SOA, and multi-agent systems approach. Traffic Management and Information System (TMIS) application manages a traffic network providing information to its constituents at the same time. A security scenario involving tracking and reporting vehicles in TMIS is used as an exemplary process. Salient design features of TMIS/IJ were summarized. TMIS design was recently worked at length [2]. TMIS design choices lead to new software architecture for distributed environments using autonomous semantic agents. While providing extensive inter-connectivity, flexibility and concomitant reliability, its simulation studies also showed tolerable overhead levels. Simulations show high performance and benefit of load distribution using Intelligent Junctions. Design of IJ was worked out in a recent study [3]. It involves employing autonomous semantic agent based software, sensor networks, and wire/wireless integrated communication infrastructure. Simulation study of IJ hints at extensive usability for autonomous and cooperative functionality needed in TMIS sort of real-time applications. A security scenario concerning tracking and rooting of missing vehicles was posed as an exemplary service over TMIS. Service application implementing the scenario and its algorithm were described. In order to evaluate performance of this application, in section 5 TMIS was simulated to use in obtaining steadystate response times. In section 6, an analytical expression was derived for the same if the missing vehicle is actually in TMIS jurisdiction. The response time is unpredictable if the vehicle is outside TMIS. Comparison of the performance figures by both methods are given in section 7 which shows that both agree. Certain limitations of the simulation study reported above have been noted. Simulation was based on a synchronous model. This provided fairly acceptable approximation as indicated by the concurrence of analytical and simulation based response time calculations. On the other hand, as many unrelated events happen in far-flung niches of TMIS, real life case could be better mimicked by an asynchronous approach. Similarly, simulation as based on an M/M/1 model, so a single customer gets served at any time at a junction; in a way, links were served one-at-a-time and each was single lane! Whereas distribution of traffic in a real-life system is dynamic hence the rates get updated continually, this study assumed fixed probabilities of traffic loads (duly fixed exit probabilities) in links. Extensions along these factors may be investigated in the future. In the future, various other applications similar in nature to VTR, such as emergency services, may as well be considered concerning vehicles. Similar cases are also feasible involving drivers, passengers, and pedestrians should they be carrying a remotely-sensed identification device. Features of TMIS/IJ design have been utilized in other distributed applications. IJ’s implementation base of SWS, cooperating agent, and cognitive-semantic support has also been carried over to a mobile robot. This is named as Autonomous Semantic AgentMobile (ASAM). Together with TMIS’s multi-agent nature, such robots can then be used cooperatively to solve problems. Such designs then coined as Multi-ASAM (MASAM) architecture. The case in point is the Cooperative Labyrinth Discovery (CLD) Project we’ve evolved for finding an exit out of an uncharted labyrinth by multiple robots working cooperatively. Design novelties of the CLD robot are highlighted in [12, 13], which 894 ATILLA ELCI, BEHNAM RAHNAMA AND AMIRHASAN AMINTABAR received “A Special Prize for Technical Merit” in RO-MAN’06 Robot Companion Design Contest [14]. This robot also received the First Place in General (Design) Category in METU Robotic Days [15]. Research on the reliability of TMIS/IJ design is being initiated. Essentially, continuity of full service is assured excepting the case of TMIS with segmented sub-networks where only a single link failure may cause partitioning. This is so because of re-configurability through MAS nature of the design where each agent can subsume any other agent’s duties, and availability of multiple paths between any two points in a TMIS. Nevertheless, the effects of link failure and the security of service through re-configurability of TMIS/IJ design may need to be researched [16, 17]. REFERENCES 1. G. Wang, D. Xiao, and J. Gu, “Designs on simulation platform of traffic emergency management system,” in Proceedings of the 10th IEEE International Conference on Computer Modeling and Simulation, 2008, pp. 720-725. 2. A. Elci and B. Rahnama, “Considerations on a new software architecture for distributed environments using autonomous semantic agents,” in Proceedings of the 29th International Computer Software and Applications Conference, Vol. 2, 2005, pp. 133-138. 3. A. Elci and B. Rahnama, “Intelligent junction: Enhancing quality of life through traffic management,” in Proceedings of the 4th Congress on Informatics in Built and Municipality, 2006, pp. 67-74. 4. OASIS, Reference Model for Service Oriented Architecture 1.0, Official OASIS Standard (Normative PDF), Oct. 12, 2006. 5. A. Malloy, N. A. Kraft, J. O. Hallstrom, and J. M. Voas, “Improving the predictable assembly of service-oriented architectures,” IEEE Software, Vol. 23, 2006, pp. 1215. 6. The Message Passing Interface (MPI) standard, 2007, http://www-unix.mcs.anl.gov/ mpi/. 7. Virtual InfrastructureVMWare, http://www.vmware.com/, 2008. 8. T. Iryo and A. Sumalee, Theory and Practical Implications of Link Travel Time Estimation with Limited Information, Transportation Science, The Institute for Operations Research and the Management Sciences, Hanover, MD, 2006. 9. EU IST Project Ubiquitous Sensing and Security in the European Homeland, 2008, http://www.ist-ubisecsens.org. 10. G. Korkmaz, E. Ekici, and F. Ozguner, “A cross-layer multihop data delivery protocol with fairness guarantees for vehicular networks,” IEEE Transactions on Vehicular Technology, Vol. 55, 2006, pp. 865-875. 11. A. Amintabar, A. Kostin, and L. Ilushechkina, “Simulation of a novel leader election protocol with the use of petri nets,” in Proceedings of the 9th IEEE International Symposium on Distributed Simulation and Real-Time Applications, 2005, pp. 283289. 12. B. Rahnama and A. Elci, “Upon human-robot inter communication,” in Proceedings of the 15th IEEE International Symposium on Robot and Human Interactive Com- TRACKING REPORTED VEHICLES IN TMIS USING INTELLIGENT JUNCTIONS 895 munication, 2006. 13. A. Elçi and B. Rahnama, “Semantic robotics: cooperative labyrinth discovery robots for intelligent environments,” A. Tolk and L. C. Jain eds., Vol. 168, 2009, pp. 163- 198. 14. A. Elci and B. Rahnama, “Human-robot interactive communication using semantic web technologies in design and implementation of collaboratively working robots,” in Proceedings of the 16th IEEE International Symposium on Robot and Human Interactive Communication, 2007, pp. 273-278. 15. 4th METU Robotics Days Competition, Middle East Technical University, Ankara, 2007. 16. EU IST Project Mobile Peer-to-Peer Security Infrastructure, 2008, http://www.pepers. org. 17. EU IST Project Dependable Security by Enhanced Reconfigurability, 2008, http:// www. deserec.org. Atilla Elçi researches and teaches on semantic web, semantic robotics, information security, and programming languages. He is Visiting Associate Professor with the Computer Engineering Program at Middle East Technical University (METU) Northern Cyprus Campus. He was with the Computer Engineering Department, and Internet Technologies Research Center (founder, president), Eastern Mediterranean University (2003-2009), North Cyprus; also served as the director of the Informatics/Campus Automation Office. He obtained B.Sc. in Computer/Control at METU, Ankara, Turkey (1970), M.Sc. & Ph.D. in Computer Sciences at Purdue University, W. Lafayette, Indiana, U.S.A. (1973, 1975). He served in the Department of Computer Engineering at METU (1976-1985) as faculty member, director DP Center, assistant to and chairman till 1984. He was associated with the International Telecommunications Union (1985-1997) serving in the UNDP development projects as chief technical advisor in numerous countries. Dr. Elçi established and managed his IT and telecoms company in Turkey (1998-2003); established and headed the Computer Engineering Department at Haliç University, Istanbul (2000-2003). His research and experience encompass web semantics, agent-based systems, robotics, machine learning, knowledge representation and ontology, and natural language translation. Dr. Elçi has numerous refereed publications on web and internet applications, web semantics, e-commerce, e-learning, data communications, networking, billing in telecom agencies, operating systems, computer acquisition, computer science education, software science, software engineering, systems analysis and design, formal languages, theory of translation, natural language translation, data management, microprocessors and microcomputers, LAN, mathematical games, national informatics policy/ planning, informatics surveys. He has organized or served in the committees of numerous international conferences. He has been organizing IEEE ESAS Workshops, SIN Conferences; and, IJRCS Symposiums. He is in the standing/steering committee of COMPSAC conferences. He has edited special issues and authored book chapters. He has agreed to prepare an edited book for Springer on Engineering Semantic Agents by mid 2010. 896 ATILLA ELCI, BEHNAM RAHNAMA AND AMIRHASAN AMINTABAR Behnam Rahnama is currently an Assistant Professor in the Department of Computer Engineering at Lefke European University, North Cyprus. He graduated with Ph.D. in Computer Engineering at Eastern Mediterranean University, North Cyprus, in 2009. He received his B.S. degree in Software Engineering (2003) at Shiraz Azad University of Iran, and M.S. degree (2005) in Computer Engineering at Eastern Mediterranean University. He has published various papers in the field of intelligent systems, robotics, semantic web services, data structure, and security. His research interests include distributed collaborative autonomous semantic robotic systems, semantic reasoning, and semantic intelligence, efficient hierarchical schemas for RDBMS, security and cryptography, and embedded OS/hardware for robotics. He is reviewer of many international refereed conferences in addition to co-chairing annual International Joint Robotics Competition and Symposium (IJRCS) and holding e-presence chair of Security of Information and Networks Conferences (SINCONF). Amirhasan Amintabar is currently a Ph.D. candidate of Computer Science at the University of Windsor in Canada in the field of computer vision. He received his bachelor’s degree in Computer Engineering Hardware upon the implementation of a 12MHz Digital PC oscilloscope as his graduation project in 1998. Having worked in the computer graphics and 3D imaging industry for four years he entered the master’s program at the Computer Engineering Department of Eastern Mediterranean University in 2002. He defended his master’s thesis on distributed system’s coordination in 2004. He engaged with Auto21 projects, Auto Industry Canada, upon the start of his Ph.D. in 3D computer vision in 2007. Amir published various papers in 3D computer vision, distributed systems, web and grid security.