Vehicular networking and road weather related research in Sodankylä

Introduction Conclusions References Tables Figures

ultimate commercial architecture. The WiSafeCar project drew an outline for the commercially operating intelligent vehicular access network architecture, with a general deployment proposal. Even if the commercial deployment did not take place, the developed system served as the basis for a more advanced project, Eureka Celtic Plus CoMoSeF (Co-operative 5 Mobility Services of the Future) project (Sukuvaara et al., 2015), along with other intelligent traffic related research. The focus in the CoMoSeF project was on near-the-market services and multi-standard communication. The aim was to not only to serve vehicles, but also exploit vehicle-originating data to ultimately enhance the very same services. Similarly, RSUs are not just serving the vehicles as connectivity points, but also host 10 RWS capabilities to provide additional data for the services. Both of these properties are combined in the Finnish Meteorological Institute approach to employing vehicular networking architecture to provide route weather information for vehicles passing our combined RWS/RSU. The enhanced RWS/RSU was also studied in NPP-funded SNAPS (Snow, Ice and Avalanche applications) project, where it represented the win-15 ter traffic data and enhanced service source for bypassing vehicles as well as online customers of local stakeholders. The Sodankylä RWS is equipped with up-to-date road weather measurement instrumentation, compatible with (but not limited to) the equipment of operational RWS. The procedure was to design, develop and test both the local road weather service generation, and the service data delivery between RWS and ve-20 hicles. The vehicle passing the combined RWS/RSU is supplemented wirelessly and automatically with up-to-date road weather related data and services, and at the same time possible vehicle-oriented measurement data is delivered upwards to database, to be used as part of weather information. IEEE 802.11p is the primary communication protocol, but also traditional Wi-Fi communication is supported, together with cellular 25 3G access as a backbone. Furthermore, the winter traffic data gathered from the vehicles was studied in Interreg IV A Nord Intelligent Road project. More advanced road weather services to be delivered directly to vehicles were intensively studied in EU FP7 Road Operation). As the result of all these projects and research work, the interactive RWS station, together with research vehicles, forms the pilot system in Sodankylä, acting as a real-life test bed for the present and yet to come demonstration systems.

Research Road Weather Station
FMI has constructed a special combined Road Weather Station and Road Side 5 Unit (RWS/RSU) to the Northern Finland, nearby its facilities in Sodankylä. The station, viewed in Fig. 1, is equipped with up-to-date road weather measurement instrumentation. The general objective is to design, develop and test both the local road weather service generation and the service data delivery between RWS and vehicles. The collection of RWS measurements is listed in Fig. 2.

10
The IEEE 802.11p VANET standard is used as the primary communication entity. Traditional Wi-Fi (IEEE 802.11g/n) and cellular networking (3G) are used as reference methods for the existing operative solution and as the alternative communication methods if VANET network is not available.
The interaction between vehicle and RWS represents the typical V2I communica-15 tion. The vehicle passing the RWS/RSU is supplemented wirelessly and automatically with up-to-date road weather related data and services, and at the same time possible vehicle-oriented measurement data is delivered upwards. As seen in Fig. 3 Discussion Paper | Discussion Paper | Discussion Paper | Discussion Paper | system and operational procedure is presented in simplified format in Fig. 4. The same software entity maintains the data delivery between RWS and vehicles and RWS and FMI site, while gathering and updating the local weather data of RWS/RSU. The communication system, originally presented by Mäenpää (2013), supports the operations in IEEE 802.11p, traditional Wi-Fi and 3G environments. The communica-5 tion software has been generated with Python general-purpose, high-level programming language. The Python version 2.7.3 has been used throughout our development process. All the operations are running in parallel Python .py-modules. Basically all the communication elements are using same operation module, presented in Fig. 4. Depending on the usage profile (RWS, vehicle in V2I, vehicle in V2V) different kind 10 of initiation process is required. The RWS/RSU has an infinite-loop Python operation procedure, which has been initiated before starting any other elements. Therefore it is expected to perform to specialized eternal loop of its network operations already before any vehicle is about to initiate communication. One module generally supports only one communication protocol, so in order to enable parallel operation of 802.11p and 15 802.11n one must initiate parallel modules for this. Finally, the 3G communication can't be initiated in this manner, as it is not practical to broadcast data in cellular network, and ultimately not allowed by the commercial network operators. We have decided to arrange 3G operation simply by forcing end users to fetch up-to-date RWS data in predefined intervals from the RWS stations nearby. Therefore, RWS only needs to ensure 20 that the up-to-date data is always stored in the RWS download folder. 2. When one is found the vehicle radio form a connection and the data exchange between the computers in RWS and vehicle can begin. 3. When the connection between vehicle and RWS devices has been established and the IP of the vehicle PC is visible for RWS host computer, the latter starts pushing messages to vehicle PC's IP at a constant rate. 4. When the connection is lost the IP-address disappears and messages will not be sent anymore.
5. Up-to-date RWS data is stored and updated regularly to download folder, in order to support 3G based data fetch by the vehicles out of range.
After this procedure the cycle begins again and vehicle radio starts searching for the nearby IEEE 802.11p/Wi-Fi networks. Server software is the same for both Wi-Fi (IEEE 802.11n) and IEEE 802.11p communication. In the software only minor difference exists between the protocol procedures, in terms of different IP and message delivery rate. The complete server side code is presented in Fig. 4. As stated before, different protocols are launched in the 15 parallel Python software modules. During the communication tests we have used only UDP-messages, but the TCP messages are supported as well. 3G communication is purely based on TCP-messages.
There are two threads that run at all times inside the RWS server; A weather condition monitoring script and a message sending script. The weather monitor just reads 20 the data and saves it into a table that the messaging script can read. This is done in order to speed up the sending of messages.
Vehicle computer is using the same Python communication modules as RWS, presented in In the Client side we have two to three threads running at the same time: 1. The Wi-Fi connection is only used during IEEE 802.11n communication.
2. For the system evaluation purposes, the GPS values are constantly being moni-5 tored and saved into a GPS-table. This table is used when a message is received in order to pinpoint the location where the message was received. We can also monitor the speed and direction from the GPS data and see how many messages are lost during transit from the numbers that are included in each message.

The 3G communication is conducted by the vehicle. Vehicle PC has a simple
Python module running in parallel with other modules, which fetches the nearest RWS data in pre-defined intervals. Time stamps of the different data contents are compared to select the most recent one.

The vehicular measurements
In order to fulfil the concept of serving vehicles and exploiting their data, we are also 15 conducting measurements in the vehicles and collecting the data. Our vehicle data consists of mainly pilot-type service data like accident warning information, with more systematic measurement data of friction measurements, external temperature sensors and vehicle telematics data collected from CAN-bus. The accident warnings are simply initiated by pushing emergency button in vehicle computer unit, to be later on inte-20 grated to the vehicle internal systems. The friction measurements and telematics data represent more sophisticated vehicle observations. FMI is using two different optical friction monitoring sensors in its road weather services. Vaisala DSC 111 friction monitoring instrument is tailored for fixed friction measurements. It has been deployed permanently into the Sodankylä special RWS, intro-  Fig. 6). RCM411 has been designed for quality control and optimization of winter maintenance. RCM411 is also suitable for runway condition reporting. The 5 sensor can be installed to a vehicle in order to monitor the surface conditions in real time. RCM411 detects all typical surface states like Dry (green line color in the map), Moist (light blue), Wet (dark blue), Slushy (violet), Snowy (white) and Icy (red). RCM411 also measures water and ice layer thicknesses in fractions of millimeters up to 3 mm. A model based on the surface type and amount is used to estimate coefficient of friction.
10 Acceleration based µ TEC Friction Meter can be integrated to the same user interface installed in a cell phone.
Friction monitoring is occurring on the measuring vehicle continuously. The friction measurement data is collected from the measuring vehicle in pre-defined intervals through 3G communication or through IEEE 802.11p or Wi-Fi communication when-15 ever entering in the range of Sodankylä RWS. Friction data of other vehicles or from the RWS can be delivered back to the vehicle as reference data. Currently we do not have any application deployed for this purpose, and this is not in the scope of the project.
Telematic data collected from vehicle CAN-bus has been recently employed for our 20 vehicle data contents. At the moment we are generally exploiting the temperature data only, but we are actively seeking the possibilities to use vehicular telematics data as a source or at least an indicator of meteorological services. In addition to existing vehicular data sources, we are also possessing Taipale Telematics Sensior system, which can be used to fusion the data of different external data 25 sources. At the moment we are only getting navigation and temperature data from the Sensior, but the additional sensor instrumentation is under consideration.  Fig. 7. The historical data series captured from the RWS are presented in our public local database, in http://litdb.fmi.fi/rws.php. The website contents are tailored also to the mobile devices of Android-based operating system as well as iPhone and Jolla, aiming to present our vision of road weather services user interface scalable for different environments. In addition to this, we are collecting the 10 measurement data into historical time series, to be exploited in the future research. An example of such data set, road frost data from the winter 2014-2015, is presented in Fig. 8. The frost measurement is conducted with multiple temperature sensors buried in different depths, indicating frost when temperature below zero. In the warm periods and at the end of winter season, frost is melting first from the ground level, which can 15 clearly be seen in Fig. 8.
As an example of the pilot measurements in Sodankylä, the data throughput estimation measurements conducted between combined RWS/RSU and passing vehicle are presented in Figs. 9 and 10. In this measurement we focused on the IEEE 802.11p based VANET (Vehicular Area Networking) communication, comparing it to the tra-20 ditional Wi-Fi based communication in the same environment and conditions (based on IEEE 802.11g standard). On the RWS/RSU side the host computer located in the station was employed to broadcast data for the passing vehicles in pre-defined packet size and interval, respectively. Many different combinations were briefly tested, until the optimal rate (1500 byte packets in 1 ms interval) was found and further used in the mea-25 surements. Figure 9 presents the results with 80 km h −1 vehicle speed, Fig. 10 Sukuvaara (2009Sukuvaara ( , 15 2013Sukuvaara ( , 2015 and Sukuvaara et al. (2015).

Conclusions
This paper has been introducing the research work related vehicular networking and road weather services conducted in Sodankylä, binded to our concept of interactive road weather station as a service hotspot road weather services and data collection. and 3G communications. In the future, 4G and 5G communication will be employed and tested as well.
Our research shows that our approach of hybrid communication offers considerable approach for serving vehicles with real-time weather and traffic information. We have also constructed an extensive set of road weather measurements, to be exploited as 5 part of road weather services of FMI as well part of vehicular networking research. Detailed and more specific data contents with local area weather data can be delivered to vehicles in service hotspots located beside road. Whenever outside the range of any RWS, 3G cellular data ensures that the most critical information related to weather and traffic is always up to date. As a summary, our approach of combined RWS/RSU represents our imagination of merging modern road weather services and vehicular intelligence, and stands for respectable test bed for the future road weather and networking services as well.
FMI's combined Road Weather Station (RWS)/Road Side Unit (RSU) in Sodankylä is the unique research platform combining very advanced road weather measurements 15 with versatile collection of the most common wireless communication methodologies used in vehicular environment. Together with harsh, arctic road weather conditions it represents incomparable development environment and pilot RWS station within the field of ITS (Intelligent Transport Systems) and vehicular networking.