- Email: [email protected]
ElisaTM – Car to infrastructure communication in the field
Computer Networks 55 (2011) 3169–3178
Contents lists available at ScienceDirect
Computer Networks journal homepage: www.elsevier.com/locate/comnet
ElisaTM – Car to infrastructure communication in the field Benno Schweiger a,⇑, Christian Raubitschek b, Bernard Bäker c, Johann Schlichter d a
BMW Research and Technology, Hanauer Straße 46, 80992 Munich, Germany BMW Group, Knorrstraße 147, 80788 Munich, Germany Technische Universität Dresden, Institut für Automobiltechnik Dresden, George-Bähr-Straße 1c, 01062 Dresden, Germany d Technische Universität München, Institut für Informatik, Boltzmannstraße 3, 85748 Garching, Germany b c
a r t i c l e
i n f o
Article history: Available online 17 June 2011 Keywords: Car to infrastructure Car to car C2I C2C C2X Traffic light communication
a b s t r a c t Car to infrastructure (C2I) communication as an aspect of Intelligent Transportation Systems (ITS) is a topic that is currently under wide research. Most works however deal with theoretical analysis, simulative evaluation or closed testbeds. There are only a few publications describing real world application of C2I on real world streets with real world traffic. In this paper we present the results of initial tests and measurements performed in the testbed ElisaTM (Efficient Light Signal Adaptation Testbed Munich). The testbed consists of four intersections in a mostly residential area in Munich, Germany. The results include an analysis of data availability and data quality under different traffic conditions. Ó 2011 Elsevier B.V. All rights reserved.
1. Introduction Intelligent Transportation Systems (ITS) are an approach to improve different means of transportation, such as public transport or vehicular traffic and generally traffic flow. Early applications have been safety and emergency systems, reducing traffic congestions and transportation times followed by parking guidance and toll collection systems. Due to recent discussions, current and future legal requirements concerning fuel consumption and pollutant emission, another issue became a focal point: Using ITS for efficiency purposes. One aspect of ITS is making use of traffic signal information. This is and has been the focus of numerous research and applied research projects at both scientific institutes and the automotive industry. To be mentioned are in particular recent state-aided projects which partially dealt with the named issue like aktiv [1], PReVENT [2], INVENT [3], CVIS [4] and PRE-DRIVE C2X [5]. Here, the investiga⇑ Corresponding author. Tel.: +49 89 382 66378; fax: +49 89 382 66398. E-mail addresses: [email protected] (B. Schweiger), [email protected] (C. Raubitschek), [email protected] (B. Bäker), [email protected] (J. Schlichter). 1389-1286/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2011.05.022
tions primarily took place in limited non-public test beds under synthetic conditions for research purposes and for demonstrating the feasibility of communication from infrastructure to cars (C2I) or cars to cars (C2C). Using traffic signal information for efficiency has also been the focus of research activities for a long time. Considerable potential for reducing fuel consumption and reducing pollutant emissions has been identified. In this paper a subset of efforts and results from different institutions will be described. Furthermore some standardization activities in the field of car to X (C2X) Communication will be presented. Current research, motivated by legal requirements and the rising fuel prices, leads to the conclusion, that using traffic signal information offers a high potential for reducing fuel consumption and pollutant emission and is worth implementing in a real traffic environment. This leads to the main cause of our investigation. Our intention was to investigate the behavior and performance of a real world C2I-Communication setup with real world traffic conditions. The technology we use is in focus of some standardization efforts of different committees. The ElisaTM (Efficient Light Signal Adaptation Test bed Munich) test bed is a cooperation between the traffic department of the City of Munich, the Siemens AG Mobility Division and
3170
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
BMW. It is located in a mostly residential area in Munich, Germany and consists of four intersections with different conditions as to lane number, turning directions, frontage development. The results shown include an analysis of data availability and data quality under different traffic conditions. 1.1. Structure of this paper In Section 2 we describe the state of the art regarding investigations of public research institutes and the automotive industry as well as the standardization efforts concerning C2X-Communication. In Section 3 we give a description of the technology and hardware used in ElisaTM and any details about the implementation of the communication of the traffic lights to the cars. Section 4 offers details about the test bed like geographic data, types of intersection and the traffic adaptive control system of the traffic lights. The tests for data availability and reliability including their results are presented in Section 5. In Section 6 we close our article with a conclusion and future prospects.
cast range of about 300 m in an also nonpublic test bed. There was no more information about data quality or broadcasting details [10]. 2.2. Automotive industry As early as 1981 the automotive industry, respectively Volkswagen, dealt with this topic in real traffic field trials named ‘‘‘Wolfsburger Welle’’’ with an infrared based communication [11]. Beside Volkswagen the automotive manufacturer Audi did some research concerning this topic starting in 2006. In the state aided project Travolution [12] they equipped some traffic lights in the city of Ingolstadt in Germany with communication modules for telling the on-board computer in the test car the time of the next green phase of an upcoming traffic signal light. They used the communication standard IEEE 802.11. No further details about the standard used or other information about the used communication units, the data quality, the broadcasting range or generally the feasibility of such systems in the real world are available. 2.3. Standardization efforts
2. Related work and standardization efforts Using traffic signal information for improvement of efficiency has been a focus of research activities for a longtime. In this section a subset of efforts of universities, scientific institutes and the automotive industry will be mentioned. Furthermore some standardization activities in the field of C2X-Communication will be shown. 2.1. Public research institutions Numerous research activities focused on vehicle fuel reduction through the use of predictive traffic signal information for computing efficient driving strategies. In 2003, the University of Stuttgart identified possible fuel reductions up to 40% [6] in traffic signal affected areas. In 2009 and 2010 the University of California Riverside and Clemson University found energy and emission savings for vehicles ranging from 12–14% to 47% in theoretical and simulative investigations [7,8]. In 2008 an on-board driving assistance system was built at the Robotiker–Tecnalia Technology Center in Zamudio, Spain, that brought traffic light information inside a car. For communication they used the IEEE 802.11a standard for convergence reasons with the current technology at that time. Their test bed consisted of a 500 m straight track without any obstacles in the line of sight and without any other road users. They reached broadcast ranges from 95 m up to 430 m depending on velocity and other conditions with a data transmitting success rate from 65% to 95% [9]. In 2010 researchers at the Technische Universität Dresden, Germany, built a prototype driver assistance information system, based on an ad hoc-network communication system. The aim was fuel-efficient and safe approaching and crossing of vehicles at traffic light controlled intersections. For the communication issue a modification of the IEEE 802.15.4 standard was used with an identified broad-
There are numerous activities to create standards for C2X-Communication both for means of communication and for data structure and content. Only a subset of them could be named here. The CAR 2 CAR Communication Consortium (C2CCC) [13] is a non-profit industrially driven consortium consisting of car manufacturers, equipment suppliers and research organizations. The aim of this organization is to increase road safety and efficiency by means of ITS. It supports the creation of a European standard for future communicating vehicles spanning all manufacturers. As a key contributor the C2CCC works in close cooperation with European and international standardization organizations in particular ETSI TC ITS1 [14] and CEN 2 [15]. The European aided project PRE-DRIVE C2X [5] lasted for 2 years and ended in June 2010. With a large scale C2X field trial based on the European COMeSafety [16] architecture for C2X-Communication systems the project developed a detailed specification for such systems and a functionally verified prototype. The experiences gained from the recent projects and the C2CCC are currently being applied in future standardization efforts and research projects like simTD (Safe and Intelligent Mobility Test Field Germany) [17] or the PREDRIVE C2X successor DRIVE C2X. The project simTD is also a partnership of numerous automotive and telecommunication companies, research organizations and the governments of the state Hessia and the City of Frankfurt. The test bed to be installed will be situated in the city of Frankfurt, Germany. The project is aimed at promoting research and testing of C2X-Communication and its applications and will put the results of previous research projects into practice. For this purpose 1 European Telecommunications Standards Institute Technical Committee for Intelligent Transportation Systems. 2 Comité Européen de Normalisation (European Committee for Standardization).
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
realistic traffic scenarios will be addressed in a large-scale real-world test field around Frankfurt. Other issues of simTD are building a political, economic and technological framework to successfully set up C2C and C2I networking. 3. Design and implementation 3.1. Motivation As mentioned before, most work in the field of C2ICommunication was either done only in simulation or under synthetic conditions. These approaches lack the possibility to verify that the discovered positive effects are achievable under real life conditions as well. The possibility of verifying the potentials of C2I-Communication thus was a major motivational aspect to establish a test bed on real life streets. We want to be able to determine whether the functions we develop work in reality. Especially the aspect of having traffic-adaptive traffic lights adapting to real people and cars instead of time controlled traffic lights is one that promises to be interesting. With time-controlled traffic lights, prediction is easy as the traffic light controller knows exactly, when the next phase change will happen. As soon as a traffic light controller adapts itself to traffic, it loses that deterministic behavior. Phase changes become dependent on requests registered by sensors such as induction loops in the road. That makes any prediction fuzzy. Handling this fuzziness is a challenge for all functions. We also expect to collect valuable experience on how to handle the equipment and how to solve those small problems that always show up unexpectedly when applying new technology to the field. Solving these problems might give good insight towards developing a solution suitable for series production. One last motivational point is the prospect of having a locally close test bed for applications developed in statefunded research projects, where the distance to the respective test beds complicates testing. Having a test bed nearby enables us to do more efficient testing, since we can test basic functions before a long drive, e.g. to the simTD test bed in Frankfurt. 3.2. Selecting technology Because being able to use the test bed for applications developed in state funded projects, is part of our motivation, our choice of technology to be used in our test bed is somehow affected by the choices made in these projects. Since (at least for German projects) simTD seems to establish its architecture as the de facto standard, we want to be as compatible with simTD as possible. Using original simTD hardware was not possible since its development is scheduled to be completed several months after our test bed is scheduled to be operable. For the communication technology our choice was pretty clear. We chose IEEE 802.11p [18] since it is on the best way to become an industry standard. It is not only used by simTD, but also by several other projects all over the world (aktiv [1], NoW [19], PRE-DRIVE C2X [5]).
3171
Concerning hardware, we decided to use the Denso Wireless Safety Unit in the cars. For the Intelligent Roadside Stations (IRS) connected to the traffic light controller, Siemens used their own hardware. As basic communication framework we use ACUp which was developed as part of the project aktiv [20]. 3.3. Communication protocols Since the test bed is supposed to be compatible to simTD applications, we wanted to use the simTD protocol stack. Unfortunately, due to several delays in simTD, the finished protocol stack was not available at the time Elisa was scheduled to start. So we chose to build our own implementation of the simTD protocol specifications. While not being able to directly transfer applications from simTD to Elisa (or vice versa), this guarantees an easy transition, as the applications use the same information items. In detail, we implemented the Signal Phasing and Timing (SPAT) and intersection geometry (MAP) messages. 3.3.1. SPAT messages SPAT messages contain information about the current status of an intersection and its traffic lights as well as a prediction of the time remaining until the next signal changes. An overview of the most important elements is given in Table 1. More detailed information can be found in the official simTD deliverable D21.4 [21]. In the ElisaTM test bed some limitations are made to the SPAT messages: Due to the lack of statistical data, it was not possible to fill the field likelyTime with meaningful values. Instead, it is calculated as the average of minTime and maxTime. The field confidence is set to a constant value. The number of phase changes contained in each SPAT message is limited to one. 3.3.2. MAP messages MAP messages contain information about the geometry of an intersection. The geometry is represented by a hierarchical structure with the intersection as root element. An overview of the elements in a MAP message is given in Fig. 1. The actual coordinates of each lane are given by a NodeList containing at least two points. Points are given as longitudinal, latitudinal and vertical offsets to a reference point. The coordinates of the reference point are given in WGS84 format. In addition to the geometry information a MAP message also contains information about which lanes are connected to each other. 3.4. Lab test for communication Since the traffic lights of the test bed are part of the public road network, updating the software of the communication boxes is difficult. For safety and security reasons, there is no remote access, so updates have to be installed by physically going to each intersection. To keep the number of visits to a minimum, the communication setup should be tested before deploying the hardware. For these tests, a lab testing environment is necessary. The simple solution of putting the transmitter next to the receiver
3172
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
Table 1 Most important information elements in SPAT messages [21]. Item
Description
IntersectionId IntersectionStatus
Unique identifier of the intersection Information about the status of the intersection
MovementState
currentState minTime maxTime likelyTime confidence
The color the traffic light currently shows Minimum number of seconds the traffic light stays in currentState Maximum number of seconds the traffic light stays in currentState Most likely number of seconds the traffic light stays in currentState The confidence for likelyTimeToChange
Conflict Area ApproachObject.Approach.DrivingLane ApproachObject.Approach
ApproachObject
ApproachObject.Egress
Intersection.ReferencePoint
DrivingLane.NodeList
Intersection Fig. 1. Intersection geometry in a MAP message.
on a table and starting to test was not possible, because the transmitter is developed by Siemens in Vienna, Austria and the receiver by BMW in Munich, Germany. To solve this problem, an OpenVPN [22] based solution was employed. A common IP based VPN would not work because the communication protocol as described in Section 3.3 does not use IP. For situations like these OpenVPN offers a bridge mode [23], where two separate LANs are connected to each other on the link layer. The OpenVPN server works like an Ethernet switch connecting the networks on both sides. Fig. 2 illustrates the setup. Using this setup, we were able to test our implementation of the communication protocols and reduce the effort necessary to deploy our solution to the field. 4. Testbed The test bed is located in the outer part of Munich, Germany, in a mostly residential area. It spans four consecutive intersections on the main road. 4.1. InterSection 1 InterSection 1 is the northernmost intersection in the test bed. It consists of two single lane roads crossing at
an angle of almost 90°. The antenna of the IRS is mounted above the southbound stop line of the northern approach (marked with an arrow in Fig. 3), ca. 13 m from the center of the intersection. All corners of the intersection are occupied by residential houses with front gardens. 4.2. InterSection 2 InterSection 2 is approximately 600 m south of InterSection 1. It is very similar in terms of geometry to InterSection 1, also consisting of two single lane roads crossing at an angle of almost 90°. The corners are also covered by residential houses with gardens and the antenna is also mounted on above the southbound stop line of the northern approach (see Fig. 3), ca. 12 m from the center of the intersection. 4.3. InterSections 3 and 4 InterSections 3 and 4 are located so close to each other that they are handled by a single traffic light controller. This results in them sharing one IRS. Together they consist of two single-lane approaches from the east and one from the west intersecting with the main road. The northern part of the main road is also single-lane while the southern
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
Traffic Light Controller
Application Unit
Signal Transmitter
CCU
OpenVPN Client LAN Siemens
3173
OpenVPN Server LAN BMW
Internet Fig. 2. Overview of the VPN setup.
Fig. 3. Positions of the roadside stations. (Ó2010 Google – Ó 2010 DigitalGlobe, GeoContent, AeroWest, GeoEye).
northbound approach has a dedicated right turn lane and traffic light. The antenna of the IRS is mounted above the northbound stop line of the southern approach (see Fig. 3), 10 m from the center of interSection 4. Directly south of interSection 4 the road goes crosses under a railway. The south western corner is currently a construction site without any high rising structures. All other corners are again covered by residential houses with gardens. 4.4. Traffic lights All traffic lights in the test bed have a predefined cycle time of 60–90 s depending on the time of day. The cycle time is defined as the time during which a traffic light goes through all four states (red, red/yellow, green, yellow). All regarded intersections are equipped with induction loops to gather traffic information, buttons for pedestrians
wishing to cross and a system that gives preferred treatment to public busses. The regulation of the traffic lights is fully adaptive with the premise to only give red on the main road if traffic on the side streets or crossing pedestrians demands it. The area is also frequented by several bus lines. The busses are equipped with transmitters that announce them to the traffic light controller. The controller ensures a swift passing of busses by changing the signal changes in their favor. This adaptiveness makes predictions difficult and fuzzy, since not even the traffic light controller knows how it will act in a couple of seconds. 5. Initial tests Before any in-car functions can be tested in the test bed, we need to gather information about what data quality we can expect. In the following we describe our test of the two
3174
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
main aspects of data quality: availability and reliability. Aspects of data security such as integrity and authenticity are not regarded in this work since including these topics would expand the scope too much. During all tests, the IRSs in the test bed were configured to a data rate of 6 Mbps and a transmission power of 18 dBm. 5.1. Data availability One very interesting point when dealing with C2I-Communication is where the data is available. Many factors determine the range of the radio signal sent by the IRS, e.g. line-of-sight conditions, blockage by other vehicles and transmission power. There are several works dealing with this using a simulative approach or synthetic test conditions (e.g. [24,25]), but real life data is hardly available. 5.1.1. Test design To measure the data availability we determine the average rate of receiving a complete message from a traffic light at any given point in the test bed. All senders are set to send messages at a rate of 1 Hz. Perfect reception would result in receiving at the same rate. Since we are interested in real life performance, the measurement is done by equipping a vehicle with a receiver and driving through the test bed on a route that uses all streets equally (see Fig. 4). The western approach of interSection 3 is a one way road, so we had to take a detour to include it. Following this route would result in always taking a turn at the intersections. That in turn results in never driving in the constant traffic flow on the main road. To amend that, we also took measurements during driving up and down on the main road only, without taking any turns. Based on the characteristics of the 5.9 GHz radio frequency, it is to be expected that signal reception is better if there are less obstacles between sender and receiver. This should lead to better reception during low traffic volume, because at high traffic volume the probability for e.g. a large truck blocking the signal is higher. To be able to measure the effect of traffic volume on data availability, measurements were performed during different traffic conditions. For heavy traffic volume, we chose the afternoon rush hour weekdays around 5 p.m. Low traffic volume measurements were performed at night time, weekdays around 11 p.m.
5.1.2. Results For evaluation of the logged data, we spanned a grid with a resolution of 10x10m across the test bed. For each cell the number of visits and the number of received SPAT messages is calculated. Fig. 5 shows a visualization of the reception probability for each intersection. The first obvious fact is the much shorter range in the side streets. This is caused by the location of the antennas: They are mounted approximately 10–15 m from the center of the intersection on the main road. This and the fact that most corners of the intersections are covered by buildings results in poor line-of-sight (LOS) conditions in the side streets. As can be seen in Fig. 5, good reception of the SPAT messages is available at ranges up to 400 m with single messages reaching as far as 500 m. We could not yet find a reason why the range of interSection 2 is significantly smaller than interSection 1. The hardware is identical and the layout of the intersection is almost the same. The poor range of interSection 4 to the north might be explained be a partially shadowing of the radio signal by the traffic lights of interSection 3. Finding the cause for these two issues requires an in depth analysis of hardware and the radio characteristics at the intersections. A direct comparison of the rush hour and the low traffic volume scenarios confirms the initial assumption: A high traffic volume causes the reception probability to drop. Fig. 6 shows this fact more clearly: The reception probability during rush hour is approximately 10% lower compared to low traffic volume. 5.2. Data reliability The availability of data is useless, if the prediction included in it is not correct. Because of the traffic adaptiveness of the traffic lights in the test bed, correctness of the prediction cannot be a given fact. Future in-car functions can work with imperfect information if it is known exactly how reliable the information is and how large deviations may be. These characteristics are what we call data reliability. 5.2.1. Test design To determine the confidence of data, we place our measurement vehicle near each IRS to get near perfect reception and log all incoming SPAT messages for a period of one hour per IRS. This was done during late morning to noon. At this time the traffic volume is volatile, so we
N
Fig. 4. Route through test bed.
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
3175
Fig. 5. Probability of reception during rush hour and low traffic volume. Images rendered with [26].
can expect periods of high volume as well as low volume. As a reference to compare to, we use log files created by the traffic department of the City of Munich showing the real switching times of each traffic light. Using this data we could compare the predicted time to the next switch with the actually observed time and calculate any deviations.
5.2.2. Results The most obvious aspect of data reliability is the overall correctness. A SPAT message is correct, if the phase changes it predicts happen at in the interval defined by min- and max-time. Since the reference data only has a resolution of 1 s, a deviation of ±1 s has to be considered as measurement error. Analysis of our data shows, that
3176
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
1 0.9
0.7 0.6 0.5 0.4 0.3
PnoitpeceRfoytilibabor
0.8
0.2 0.1 0 -400
-300
-200
-100
0
100 Distance
Low Traffic
200
300
400
500
Rush Hour
Fig. 6. Reception probability interSection 1 main road.
86.7% of all SPAT messages are correct. Fig. 7 shows the distribution of the deviation. Noticeable are the spikes at 65 and again at 135 s. A closer look at the data shows the reason for this: If there is no request from the induction loops in the side roads, no pedestrians wishing to cross and no request from public busses, the red phase for the main road will be omitted. However the traffic light controller seems to be unable to predict times that are longer than its cycle time. In these cases the minTime and maxTime both count down to 0 just to be set to a value close to the cycle time in the next SPAT message without any phase change in between. This results in incorrect SPAT messages for the whole first green phase with an error of approximately the cycle time. If at the end of the second green phase there are still no re-
quests for a phase change, the red phase is omitted again, causing the SPAT messages to be erroneous with the messages for the first phase having a deviation of twice the cycle time. Even if a SPAT message is not totally correct, it can still prove useful. Future in-car functions may not need an exact prediction of the next phase change. Important is merely, whether the prediction for the next k seconds is correct. A correct prediction in this sense means that the time span to the next change is predicted as greater than k if there is no change in the next k seconds and a predicted time less than k seconds if there will be a change in the next k seconds. The detailed conditions can be found in Table 2. We calculated the probability of error by reviewing every single SPAT message. Table 3 shows the results for
Fig. 7. Distribution of deviation from min–max interval.
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
3177
Table 2 Conditions for correctness over k seconds Phase change predicted
No phase change predicted
Phase changed
realTime 6 k ^ maxTime 6 k
realTime 6 k ^ minTime > k
Phase not changed
realTime > k ^ maxTime 6 k
realTime > k ^ minTime > k
Table 3 Probability of error in predicting phase change within k seconds. k=5s k = 10 s k = 20 s
Phase change predicted
No phase change predicted
Phase changed
13.47% 24.73% 46.38%
0.11% 0.14% 0.18%
Phase not changed
2.06% 3.41% 6.06%
84.35% 71.93% 47.38%
the southbound lane of interSection 1. The other lanes and intersections show similar results. As can be seen, the probability for a phase change happening that is not predicted is very small. On the other hand, there is a fairly high number of phase changes that happen later than predicted. This is caused by the same phenomenon as stated above: Without a request from crossing traffic the signal for the main road stays green, the expected change just does not happen. 6. Conclusion and future work In this paper we described the process of designing and deploying the C2I-Communication test bed ElisaTM. We presented the results of the initial tests. The results show the performance of C2I-Communication as it is available now. By showing reliable message reception at 300 m distance and a maximum range of 500 m, we confirmed assumptions about the range of 802.11p based communication made by previous work. We showed what kind of reliability can be expected from traffic adaptive traffic lights. 86.7% of all SPAT messages were correct. When regarding the short term prediction of the next 5 s, the probability of error was only 2.2%. While this is not perfect information, it does enable certain in-car functions. Concerning future work, our initial tests assured us that traffic light communication in reality can hold up to the expectation raised by theoretical considerations. We can now implement in-car functions and evaluate them in real life traffic. Apart from that, we identified several aspects which can be improved. Concerning data availability, finding a way to improve signal reception in side streets is required. The most obvious solution of placing the antenna in the center of the intersection is not possible at most intersections because there simply is no holding structure to mount anything. Regarding data reliability, there is great room for improvement. The phase change prediction used was only
a first step. Our results and the following discussions showed the need for more sophisticated algorithms. One possibility would be to use statistical models to calculate a useful likelyTime and confidence. Having that information would make the prediction much more valuable. When the potential to improve the prediction is realized, the next step would be to make the traffic light controller listen to messages the cars are sending. Using such messages gives the traffic light controller much more detailed information about the current traffic flow than the induction loop based data it has now. This would enable a better adaption of the traffic light to the current requirements of traffic.
References [1] aktiv Forschungsinitative, aktiv Website. (accessed 09.29.10). [4] CVIS Consortium, CVIS Website. . [8] S. Mandava, K. Boriboonsomsin, M. Barth, Arterial velocity planning based on traffic signal information under light traffic conditions, in: 12th International IEEE Conference on Intelligent Transportation Systems, St. Louis, Mo, USA, 2009, pp. 160–165. [9] I. Iglesias, L. Isasi, M. Larburu, V. Martinez, B. Molinete, I2V communication driving assistance system: on-board traffic light assistant, in: 2008 IEEE 68th Vehicular Technology Conference, vol. 2, 2008, pp. 1–5, doi:10.1109/VETECF.2008.437. . [10] P. Schuricht, B. Bäker, Entwicklung eines Fahrerinformationssystems für eine energieeffiziente Fahrzeugbetriebsführung im Bereich von Lichtsignalanlagen, in: 1. Symposium zum Thema Automatisierungs-, Assistenzsysteme und eingebettete Systeme für Transportmittel – AAET 2010, Braunschweig, 2010. [11] C. Voy, W. Zimdahl, W. Mainka, F. Stock, Device for guiding traffic in accordance with the principle of the Green Wave, Patent Application DE 3126481 A1, 1981. [12] Travolution Consortium, Travolution Website. (accessed 09.29. 10). [14] ETSI, ETSI Intelligent Transport Systems Website. (accessed 09.29.10). [15] CEN, CEN Website. (accessed 09.29.10). [16] COMeSafety Consortium, COMeSafety Website (accessed 09.29.10).
3178
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
[17] simTD Consortium, simTD Website. (accessed 09.29. 10). [19] A. Festag, G. Noecker, M. Strassberger, B. Bochow, M. Torrentmoreno, S. Schnaufer, R. Eigner, C. Catrinescu, J. Kunisch, Network on Wheels: Project Objectives, Technology and Achievements, in: Proceedings of 5rd International Workshop on Intelligent Transportation (WIT), March, Hamburg, Germany, 2008, pp. 211– 216. [20] BMW Forschung und Technik, KAS - AKTIV Communication Unit, White Paper. , 2008. [21] simTD Consortium, simTD Deliverable D21.4 Spezifikation Kommunikationsprotokolle. , (accessed 09.29.10). [22] OpenVPN, OpenVPN Website. (accessed 09.29.10). [24] D.N. Cottingham, I.J. Wassell, R.K. Harle, Performance of IEEE 802.11a in Vehicular Contexts, in: 2007 IEEE 65th Vehicular Technology Conference - VTC2007-Spring, IEEE, 2007, pp. 854–858, doi:10. 1109/VETECS.2007.185. . [25] J. Maurer, Strahlenoptisches Kanalmodell für die FahrzeugFahrzeug- Funkkommunikation, Ph.D. Thesis, Universität Karlsruhe, 2005. [26] M. Vaaraniemi, Very Detailed Navigation Maps on 3D Terrain Models, Diploma Thesis, Universität Stuttgart, 2009.
Benno Schweiger studied Information Engineering and Management at the University of Karlsruhe. He graduated in 2007. After a brief stint as head of IT at a service provider for pharmacies, he started his Ph.D. Thesis at BMW Research and Technology in 2009. His research interests are Car2X-Communication based prediction systems.
Christian Raubitschek studied Electrical Engineering at the Technische Universität München with focus on control systems, automation and human machine communication and graduated in 2008. After that, he worked for a year in the development division for automotive Head-Up-Displays at BMW in Munich. Since 2009 he does his Ph.D. in automotive engineering in the field of predictive energy management at BMW in cooperation with the Technische Universität Dresden.
Bernard Baeker has his background in the field of Electrical Engineering with the focus on mobile and immobile energy and information management. He studied at the Technical University Braunschweig (1989– 1993) and has written his doctorate dealing with energy efficient vehicle systems in cooperation with the research and development of Volkswagen AG in Wolfsburg (1994– 1998). After that he was seven years with Daimler AG in Stuttgart, responsible for advanced vehicle test and diagnosis systems and corresponding production approaches. Since 2005 he is the chair of the vehicle mechatronics department at the Institute of Automotive Technologies Dresden – IAD at the Technische Universität Dresden.
Johann Schlichter heads since 1991 the chair of Applied Informatics/ Cooperative Systems at the TU Mnnchen (TUM). From 1982 to 1985 he was part of a research group at the Siemens Research Laboratory in Princeton, NJ. He then joined to the Xerox Research Center in Rochester, NY doing research in the area of electronic publication systems. Before joining TUM in 1991 he worked for 1.5 years at Softlab GmbH, Munich, on the field of software development methodologies. His current interests are Social Software, Computer Supported Cooperative Work, mobile context-aware information and collaboration systems.
Contents lists available at ScienceDirect
Computer Networks journal homepage: www.elsevier.com/locate/comnet
ElisaTM – Car to infrastructure communication in the field Benno Schweiger a,⇑, Christian Raubitschek b, Bernard Bäker c, Johann Schlichter d a
BMW Research and Technology, Hanauer Straße 46, 80992 Munich, Germany BMW Group, Knorrstraße 147, 80788 Munich, Germany Technische Universität Dresden, Institut für Automobiltechnik Dresden, George-Bähr-Straße 1c, 01062 Dresden, Germany d Technische Universität München, Institut für Informatik, Boltzmannstraße 3, 85748 Garching, Germany b c
a r t i c l e
i n f o
Article history: Available online 17 June 2011 Keywords: Car to infrastructure Car to car C2I C2C C2X Traffic light communication
a b s t r a c t Car to infrastructure (C2I) communication as an aspect of Intelligent Transportation Systems (ITS) is a topic that is currently under wide research. Most works however deal with theoretical analysis, simulative evaluation or closed testbeds. There are only a few publications describing real world application of C2I on real world streets with real world traffic. In this paper we present the results of initial tests and measurements performed in the testbed ElisaTM (Efficient Light Signal Adaptation Testbed Munich). The testbed consists of four intersections in a mostly residential area in Munich, Germany. The results include an analysis of data availability and data quality under different traffic conditions. Ó 2011 Elsevier B.V. All rights reserved.
1. Introduction Intelligent Transportation Systems (ITS) are an approach to improve different means of transportation, such as public transport or vehicular traffic and generally traffic flow. Early applications have been safety and emergency systems, reducing traffic congestions and transportation times followed by parking guidance and toll collection systems. Due to recent discussions, current and future legal requirements concerning fuel consumption and pollutant emission, another issue became a focal point: Using ITS for efficiency purposes. One aspect of ITS is making use of traffic signal information. This is and has been the focus of numerous research and applied research projects at both scientific institutes and the automotive industry. To be mentioned are in particular recent state-aided projects which partially dealt with the named issue like aktiv [1], PReVENT [2], INVENT [3], CVIS [4] and PRE-DRIVE C2X [5]. Here, the investiga⇑ Corresponding author. Tel.: +49 89 382 66378; fax: +49 89 382 66398. E-mail addresses: [email protected] (B. Schweiger), [email protected] (C. Raubitschek), [email protected] (B. Bäker), [email protected] (J. Schlichter). 1389-1286/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2011.05.022
tions primarily took place in limited non-public test beds under synthetic conditions for research purposes and for demonstrating the feasibility of communication from infrastructure to cars (C2I) or cars to cars (C2C). Using traffic signal information for efficiency has also been the focus of research activities for a long time. Considerable potential for reducing fuel consumption and reducing pollutant emissions has been identified. In this paper a subset of efforts and results from different institutions will be described. Furthermore some standardization activities in the field of car to X (C2X) Communication will be presented. Current research, motivated by legal requirements and the rising fuel prices, leads to the conclusion, that using traffic signal information offers a high potential for reducing fuel consumption and pollutant emission and is worth implementing in a real traffic environment. This leads to the main cause of our investigation. Our intention was to investigate the behavior and performance of a real world C2I-Communication setup with real world traffic conditions. The technology we use is in focus of some standardization efforts of different committees. The ElisaTM (Efficient Light Signal Adaptation Test bed Munich) test bed is a cooperation between the traffic department of the City of Munich, the Siemens AG Mobility Division and
3170
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
BMW. It is located in a mostly residential area in Munich, Germany and consists of four intersections with different conditions as to lane number, turning directions, frontage development. The results shown include an analysis of data availability and data quality under different traffic conditions. 1.1. Structure of this paper In Section 2 we describe the state of the art regarding investigations of public research institutes and the automotive industry as well as the standardization efforts concerning C2X-Communication. In Section 3 we give a description of the technology and hardware used in ElisaTM and any details about the implementation of the communication of the traffic lights to the cars. Section 4 offers details about the test bed like geographic data, types of intersection and the traffic adaptive control system of the traffic lights. The tests for data availability and reliability including their results are presented in Section 5. In Section 6 we close our article with a conclusion and future prospects.
cast range of about 300 m in an also nonpublic test bed. There was no more information about data quality or broadcasting details [10]. 2.2. Automotive industry As early as 1981 the automotive industry, respectively Volkswagen, dealt with this topic in real traffic field trials named ‘‘‘Wolfsburger Welle’’’ with an infrared based communication [11]. Beside Volkswagen the automotive manufacturer Audi did some research concerning this topic starting in 2006. In the state aided project Travolution [12] they equipped some traffic lights in the city of Ingolstadt in Germany with communication modules for telling the on-board computer in the test car the time of the next green phase of an upcoming traffic signal light. They used the communication standard IEEE 802.11. No further details about the standard used or other information about the used communication units, the data quality, the broadcasting range or generally the feasibility of such systems in the real world are available. 2.3. Standardization efforts
2. Related work and standardization efforts Using traffic signal information for improvement of efficiency has been a focus of research activities for a longtime. In this section a subset of efforts of universities, scientific institutes and the automotive industry will be mentioned. Furthermore some standardization activities in the field of C2X-Communication will be shown. 2.1. Public research institutions Numerous research activities focused on vehicle fuel reduction through the use of predictive traffic signal information for computing efficient driving strategies. In 2003, the University of Stuttgart identified possible fuel reductions up to 40% [6] in traffic signal affected areas. In 2009 and 2010 the University of California Riverside and Clemson University found energy and emission savings for vehicles ranging from 12–14% to 47% in theoretical and simulative investigations [7,8]. In 2008 an on-board driving assistance system was built at the Robotiker–Tecnalia Technology Center in Zamudio, Spain, that brought traffic light information inside a car. For communication they used the IEEE 802.11a standard for convergence reasons with the current technology at that time. Their test bed consisted of a 500 m straight track without any obstacles in the line of sight and without any other road users. They reached broadcast ranges from 95 m up to 430 m depending on velocity and other conditions with a data transmitting success rate from 65% to 95% [9]. In 2010 researchers at the Technische Universität Dresden, Germany, built a prototype driver assistance information system, based on an ad hoc-network communication system. The aim was fuel-efficient and safe approaching and crossing of vehicles at traffic light controlled intersections. For the communication issue a modification of the IEEE 802.15.4 standard was used with an identified broad-
There are numerous activities to create standards for C2X-Communication both for means of communication and for data structure and content. Only a subset of them could be named here. The CAR 2 CAR Communication Consortium (C2CCC) [13] is a non-profit industrially driven consortium consisting of car manufacturers, equipment suppliers and research organizations. The aim of this organization is to increase road safety and efficiency by means of ITS. It supports the creation of a European standard for future communicating vehicles spanning all manufacturers. As a key contributor the C2CCC works in close cooperation with European and international standardization organizations in particular ETSI TC ITS1 [14] and CEN 2 [15]. The European aided project PRE-DRIVE C2X [5] lasted for 2 years and ended in June 2010. With a large scale C2X field trial based on the European COMeSafety [16] architecture for C2X-Communication systems the project developed a detailed specification for such systems and a functionally verified prototype. The experiences gained from the recent projects and the C2CCC are currently being applied in future standardization efforts and research projects like simTD (Safe and Intelligent Mobility Test Field Germany) [17] or the PREDRIVE C2X successor DRIVE C2X. The project simTD is also a partnership of numerous automotive and telecommunication companies, research organizations and the governments of the state Hessia and the City of Frankfurt. The test bed to be installed will be situated in the city of Frankfurt, Germany. The project is aimed at promoting research and testing of C2X-Communication and its applications and will put the results of previous research projects into practice. For this purpose 1 European Telecommunications Standards Institute Technical Committee for Intelligent Transportation Systems. 2 Comité Européen de Normalisation (European Committee for Standardization).
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
realistic traffic scenarios will be addressed in a large-scale real-world test field around Frankfurt. Other issues of simTD are building a political, economic and technological framework to successfully set up C2C and C2I networking. 3. Design and implementation 3.1. Motivation As mentioned before, most work in the field of C2ICommunication was either done only in simulation or under synthetic conditions. These approaches lack the possibility to verify that the discovered positive effects are achievable under real life conditions as well. The possibility of verifying the potentials of C2I-Communication thus was a major motivational aspect to establish a test bed on real life streets. We want to be able to determine whether the functions we develop work in reality. Especially the aspect of having traffic-adaptive traffic lights adapting to real people and cars instead of time controlled traffic lights is one that promises to be interesting. With time-controlled traffic lights, prediction is easy as the traffic light controller knows exactly, when the next phase change will happen. As soon as a traffic light controller adapts itself to traffic, it loses that deterministic behavior. Phase changes become dependent on requests registered by sensors such as induction loops in the road. That makes any prediction fuzzy. Handling this fuzziness is a challenge for all functions. We also expect to collect valuable experience on how to handle the equipment and how to solve those small problems that always show up unexpectedly when applying new technology to the field. Solving these problems might give good insight towards developing a solution suitable for series production. One last motivational point is the prospect of having a locally close test bed for applications developed in statefunded research projects, where the distance to the respective test beds complicates testing. Having a test bed nearby enables us to do more efficient testing, since we can test basic functions before a long drive, e.g. to the simTD test bed in Frankfurt. 3.2. Selecting technology Because being able to use the test bed for applications developed in state funded projects, is part of our motivation, our choice of technology to be used in our test bed is somehow affected by the choices made in these projects. Since (at least for German projects) simTD seems to establish its architecture as the de facto standard, we want to be as compatible with simTD as possible. Using original simTD hardware was not possible since its development is scheduled to be completed several months after our test bed is scheduled to be operable. For the communication technology our choice was pretty clear. We chose IEEE 802.11p [18] since it is on the best way to become an industry standard. It is not only used by simTD, but also by several other projects all over the world (aktiv [1], NoW [19], PRE-DRIVE C2X [5]).
3171
Concerning hardware, we decided to use the Denso Wireless Safety Unit in the cars. For the Intelligent Roadside Stations (IRS) connected to the traffic light controller, Siemens used their own hardware. As basic communication framework we use ACUp which was developed as part of the project aktiv [20]. 3.3. Communication protocols Since the test bed is supposed to be compatible to simTD applications, we wanted to use the simTD protocol stack. Unfortunately, due to several delays in simTD, the finished protocol stack was not available at the time Elisa was scheduled to start. So we chose to build our own implementation of the simTD protocol specifications. While not being able to directly transfer applications from simTD to Elisa (or vice versa), this guarantees an easy transition, as the applications use the same information items. In detail, we implemented the Signal Phasing and Timing (SPAT) and intersection geometry (MAP) messages. 3.3.1. SPAT messages SPAT messages contain information about the current status of an intersection and its traffic lights as well as a prediction of the time remaining until the next signal changes. An overview of the most important elements is given in Table 1. More detailed information can be found in the official simTD deliverable D21.4 [21]. In the ElisaTM test bed some limitations are made to the SPAT messages: Due to the lack of statistical data, it was not possible to fill the field likelyTime with meaningful values. Instead, it is calculated as the average of minTime and maxTime. The field confidence is set to a constant value. The number of phase changes contained in each SPAT message is limited to one. 3.3.2. MAP messages MAP messages contain information about the geometry of an intersection. The geometry is represented by a hierarchical structure with the intersection as root element. An overview of the elements in a MAP message is given in Fig. 1. The actual coordinates of each lane are given by a NodeList containing at least two points. Points are given as longitudinal, latitudinal and vertical offsets to a reference point. The coordinates of the reference point are given in WGS84 format. In addition to the geometry information a MAP message also contains information about which lanes are connected to each other. 3.4. Lab test for communication Since the traffic lights of the test bed are part of the public road network, updating the software of the communication boxes is difficult. For safety and security reasons, there is no remote access, so updates have to be installed by physically going to each intersection. To keep the number of visits to a minimum, the communication setup should be tested before deploying the hardware. For these tests, a lab testing environment is necessary. The simple solution of putting the transmitter next to the receiver
3172
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
Table 1 Most important information elements in SPAT messages [21]. Item
Description
IntersectionId IntersectionStatus
Unique identifier of the intersection Information about the status of the intersection
MovementState
currentState minTime maxTime likelyTime confidence
The color the traffic light currently shows Minimum number of seconds the traffic light stays in currentState Maximum number of seconds the traffic light stays in currentState Most likely number of seconds the traffic light stays in currentState The confidence for likelyTimeToChange
Conflict Area ApproachObject.Approach.DrivingLane ApproachObject.Approach
ApproachObject
ApproachObject.Egress
Intersection.ReferencePoint
DrivingLane.NodeList
Intersection Fig. 1. Intersection geometry in a MAP message.
on a table and starting to test was not possible, because the transmitter is developed by Siemens in Vienna, Austria and the receiver by BMW in Munich, Germany. To solve this problem, an OpenVPN [22] based solution was employed. A common IP based VPN would not work because the communication protocol as described in Section 3.3 does not use IP. For situations like these OpenVPN offers a bridge mode [23], where two separate LANs are connected to each other on the link layer. The OpenVPN server works like an Ethernet switch connecting the networks on both sides. Fig. 2 illustrates the setup. Using this setup, we were able to test our implementation of the communication protocols and reduce the effort necessary to deploy our solution to the field. 4. Testbed The test bed is located in the outer part of Munich, Germany, in a mostly residential area. It spans four consecutive intersections on the main road. 4.1. InterSection 1 InterSection 1 is the northernmost intersection in the test bed. It consists of two single lane roads crossing at
an angle of almost 90°. The antenna of the IRS is mounted above the southbound stop line of the northern approach (marked with an arrow in Fig. 3), ca. 13 m from the center of the intersection. All corners of the intersection are occupied by residential houses with front gardens. 4.2. InterSection 2 InterSection 2 is approximately 600 m south of InterSection 1. It is very similar in terms of geometry to InterSection 1, also consisting of two single lane roads crossing at an angle of almost 90°. The corners are also covered by residential houses with gardens and the antenna is also mounted on above the southbound stop line of the northern approach (see Fig. 3), ca. 12 m from the center of the intersection. 4.3. InterSections 3 and 4 InterSections 3 and 4 are located so close to each other that they are handled by a single traffic light controller. This results in them sharing one IRS. Together they consist of two single-lane approaches from the east and one from the west intersecting with the main road. The northern part of the main road is also single-lane while the southern
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
Traffic Light Controller
Application Unit
Signal Transmitter
CCU
OpenVPN Client LAN Siemens
3173
OpenVPN Server LAN BMW
Internet Fig. 2. Overview of the VPN setup.
Fig. 3. Positions of the roadside stations. (Ó2010 Google – Ó 2010 DigitalGlobe, GeoContent, AeroWest, GeoEye).
northbound approach has a dedicated right turn lane and traffic light. The antenna of the IRS is mounted above the northbound stop line of the southern approach (see Fig. 3), 10 m from the center of interSection 4. Directly south of interSection 4 the road goes crosses under a railway. The south western corner is currently a construction site without any high rising structures. All other corners are again covered by residential houses with gardens. 4.4. Traffic lights All traffic lights in the test bed have a predefined cycle time of 60–90 s depending on the time of day. The cycle time is defined as the time during which a traffic light goes through all four states (red, red/yellow, green, yellow). All regarded intersections are equipped with induction loops to gather traffic information, buttons for pedestrians
wishing to cross and a system that gives preferred treatment to public busses. The regulation of the traffic lights is fully adaptive with the premise to only give red on the main road if traffic on the side streets or crossing pedestrians demands it. The area is also frequented by several bus lines. The busses are equipped with transmitters that announce them to the traffic light controller. The controller ensures a swift passing of busses by changing the signal changes in their favor. This adaptiveness makes predictions difficult and fuzzy, since not even the traffic light controller knows how it will act in a couple of seconds. 5. Initial tests Before any in-car functions can be tested in the test bed, we need to gather information about what data quality we can expect. In the following we describe our test of the two
3174
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
main aspects of data quality: availability and reliability. Aspects of data security such as integrity and authenticity are not regarded in this work since including these topics would expand the scope too much. During all tests, the IRSs in the test bed were configured to a data rate of 6 Mbps and a transmission power of 18 dBm. 5.1. Data availability One very interesting point when dealing with C2I-Communication is where the data is available. Many factors determine the range of the radio signal sent by the IRS, e.g. line-of-sight conditions, blockage by other vehicles and transmission power. There are several works dealing with this using a simulative approach or synthetic test conditions (e.g. [24,25]), but real life data is hardly available. 5.1.1. Test design To measure the data availability we determine the average rate of receiving a complete message from a traffic light at any given point in the test bed. All senders are set to send messages at a rate of 1 Hz. Perfect reception would result in receiving at the same rate. Since we are interested in real life performance, the measurement is done by equipping a vehicle with a receiver and driving through the test bed on a route that uses all streets equally (see Fig. 4). The western approach of interSection 3 is a one way road, so we had to take a detour to include it. Following this route would result in always taking a turn at the intersections. That in turn results in never driving in the constant traffic flow on the main road. To amend that, we also took measurements during driving up and down on the main road only, without taking any turns. Based on the characteristics of the 5.9 GHz radio frequency, it is to be expected that signal reception is better if there are less obstacles between sender and receiver. This should lead to better reception during low traffic volume, because at high traffic volume the probability for e.g. a large truck blocking the signal is higher. To be able to measure the effect of traffic volume on data availability, measurements were performed during different traffic conditions. For heavy traffic volume, we chose the afternoon rush hour weekdays around 5 p.m. Low traffic volume measurements were performed at night time, weekdays around 11 p.m.
5.1.2. Results For evaluation of the logged data, we spanned a grid with a resolution of 10x10m across the test bed. For each cell the number of visits and the number of received SPAT messages is calculated. Fig. 5 shows a visualization of the reception probability for each intersection. The first obvious fact is the much shorter range in the side streets. This is caused by the location of the antennas: They are mounted approximately 10–15 m from the center of the intersection on the main road. This and the fact that most corners of the intersections are covered by buildings results in poor line-of-sight (LOS) conditions in the side streets. As can be seen in Fig. 5, good reception of the SPAT messages is available at ranges up to 400 m with single messages reaching as far as 500 m. We could not yet find a reason why the range of interSection 2 is significantly smaller than interSection 1. The hardware is identical and the layout of the intersection is almost the same. The poor range of interSection 4 to the north might be explained be a partially shadowing of the radio signal by the traffic lights of interSection 3. Finding the cause for these two issues requires an in depth analysis of hardware and the radio characteristics at the intersections. A direct comparison of the rush hour and the low traffic volume scenarios confirms the initial assumption: A high traffic volume causes the reception probability to drop. Fig. 6 shows this fact more clearly: The reception probability during rush hour is approximately 10% lower compared to low traffic volume. 5.2. Data reliability The availability of data is useless, if the prediction included in it is not correct. Because of the traffic adaptiveness of the traffic lights in the test bed, correctness of the prediction cannot be a given fact. Future in-car functions can work with imperfect information if it is known exactly how reliable the information is and how large deviations may be. These characteristics are what we call data reliability. 5.2.1. Test design To determine the confidence of data, we place our measurement vehicle near each IRS to get near perfect reception and log all incoming SPAT messages for a period of one hour per IRS. This was done during late morning to noon. At this time the traffic volume is volatile, so we
N
Fig. 4. Route through test bed.
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
3175
Fig. 5. Probability of reception during rush hour and low traffic volume. Images rendered with [26].
can expect periods of high volume as well as low volume. As a reference to compare to, we use log files created by the traffic department of the City of Munich showing the real switching times of each traffic light. Using this data we could compare the predicted time to the next switch with the actually observed time and calculate any deviations.
5.2.2. Results The most obvious aspect of data reliability is the overall correctness. A SPAT message is correct, if the phase changes it predicts happen at in the interval defined by min- and max-time. Since the reference data only has a resolution of 1 s, a deviation of ±1 s has to be considered as measurement error. Analysis of our data shows, that
3176
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
1 0.9
0.7 0.6 0.5 0.4 0.3
PnoitpeceRfoytilibabor
0.8
0.2 0.1 0 -400
-300
-200
-100
0
100 Distance
Low Traffic
200
300
400
500
Rush Hour
Fig. 6. Reception probability interSection 1 main road.
86.7% of all SPAT messages are correct. Fig. 7 shows the distribution of the deviation. Noticeable are the spikes at 65 and again at 135 s. A closer look at the data shows the reason for this: If there is no request from the induction loops in the side roads, no pedestrians wishing to cross and no request from public busses, the red phase for the main road will be omitted. However the traffic light controller seems to be unable to predict times that are longer than its cycle time. In these cases the minTime and maxTime both count down to 0 just to be set to a value close to the cycle time in the next SPAT message without any phase change in between. This results in incorrect SPAT messages for the whole first green phase with an error of approximately the cycle time. If at the end of the second green phase there are still no re-
quests for a phase change, the red phase is omitted again, causing the SPAT messages to be erroneous with the messages for the first phase having a deviation of twice the cycle time. Even if a SPAT message is not totally correct, it can still prove useful. Future in-car functions may not need an exact prediction of the next phase change. Important is merely, whether the prediction for the next k seconds is correct. A correct prediction in this sense means that the time span to the next change is predicted as greater than k if there is no change in the next k seconds and a predicted time less than k seconds if there will be a change in the next k seconds. The detailed conditions can be found in Table 2. We calculated the probability of error by reviewing every single SPAT message. Table 3 shows the results for
Fig. 7. Distribution of deviation from min–max interval.
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
3177
Table 2 Conditions for correctness over k seconds Phase change predicted
No phase change predicted
Phase changed
realTime 6 k ^ maxTime 6 k
realTime 6 k ^ minTime > k
Phase not changed
realTime > k ^ maxTime 6 k
realTime > k ^ minTime > k
Table 3 Probability of error in predicting phase change within k seconds. k=5s k = 10 s k = 20 s
Phase change predicted
No phase change predicted
Phase changed
13.47% 24.73% 46.38%
0.11% 0.14% 0.18%
Phase not changed
2.06% 3.41% 6.06%
84.35% 71.93% 47.38%
the southbound lane of interSection 1. The other lanes and intersections show similar results. As can be seen, the probability for a phase change happening that is not predicted is very small. On the other hand, there is a fairly high number of phase changes that happen later than predicted. This is caused by the same phenomenon as stated above: Without a request from crossing traffic the signal for the main road stays green, the expected change just does not happen. 6. Conclusion and future work In this paper we described the process of designing and deploying the C2I-Communication test bed ElisaTM. We presented the results of the initial tests. The results show the performance of C2I-Communication as it is available now. By showing reliable message reception at 300 m distance and a maximum range of 500 m, we confirmed assumptions about the range of 802.11p based communication made by previous work. We showed what kind of reliability can be expected from traffic adaptive traffic lights. 86.7% of all SPAT messages were correct. When regarding the short term prediction of the next 5 s, the probability of error was only 2.2%. While this is not perfect information, it does enable certain in-car functions. Concerning future work, our initial tests assured us that traffic light communication in reality can hold up to the expectation raised by theoretical considerations. We can now implement in-car functions and evaluate them in real life traffic. Apart from that, we identified several aspects which can be improved. Concerning data availability, finding a way to improve signal reception in side streets is required. The most obvious solution of placing the antenna in the center of the intersection is not possible at most intersections because there simply is no holding structure to mount anything. Regarding data reliability, there is great room for improvement. The phase change prediction used was only
a first step. Our results and the following discussions showed the need for more sophisticated algorithms. One possibility would be to use statistical models to calculate a useful likelyTime and confidence. Having that information would make the prediction much more valuable. When the potential to improve the prediction is realized, the next step would be to make the traffic light controller listen to messages the cars are sending. Using such messages gives the traffic light controller much more detailed information about the current traffic flow than the induction loop based data it has now. This would enable a better adaption of the traffic light to the current requirements of traffic.
References [1] aktiv Forschungsinitative, aktiv Website.
3178
B. Schweiger et al. / Computer Networks 55 (2011) 3169–3178
[17] simTD Consortium, simTD Website.
Benno Schweiger studied Information Engineering and Management at the University of Karlsruhe. He graduated in 2007. After a brief stint as head of IT at a service provider for pharmacies, he started his Ph.D. Thesis at BMW Research and Technology in 2009. His research interests are Car2X-Communication based prediction systems.
Christian Raubitschek studied Electrical Engineering at the Technische Universität München with focus on control systems, automation and human machine communication and graduated in 2008. After that, he worked for a year in the development division for automotive Head-Up-Displays at BMW in Munich. Since 2009 he does his Ph.D. in automotive engineering in the field of predictive energy management at BMW in cooperation with the Technische Universität Dresden.
Bernard Baeker has his background in the field of Electrical Engineering with the focus on mobile and immobile energy and information management. He studied at the Technical University Braunschweig (1989– 1993) and has written his doctorate dealing with energy efficient vehicle systems in cooperation with the research and development of Volkswagen AG in Wolfsburg (1994– 1998). After that he was seven years with Daimler AG in Stuttgart, responsible for advanced vehicle test and diagnosis systems and corresponding production approaches. Since 2005 he is the chair of the vehicle mechatronics department at the Institute of Automotive Technologies Dresden – IAD at the Technische Universität Dresden.
Johann Schlichter heads since 1991 the chair of Applied Informatics/ Cooperative Systems at the TU Mnnchen (TUM). From 1982 to 1985 he was part of a research group at the Siemens Research Laboratory in Princeton, NJ. He then joined to the Xerox Research Center in Rochester, NY doing research in the area of electronic publication systems. Before joining TUM in 1991 he worked for 1.5 years at Softlab GmbH, Munich, on the field of software development methodologies. His current interests are Social Software, Computer Supported Cooperative Work, mobile context-aware information and collaboration systems.