Performance parameters of Module Communication ...

Performance parameters of Module Communication in a cooperative platform for Rerouting and Monitoring of Dangerous Goods Transports A. Fioravanti1, M. F. Cabrera-Umpierrez1, M. T. Arredondo1, Evangelos Bekiaris2, M.-P. Bianconi3, Michael Ortgiese4, 1 Life Supporting Technologies / Universidad Politécnica de Madrid, Ciudad Universitaria s/n, 28040 Madrid, Spain 2 Centre for Research and Technology Hellas / Hellenic Institute of Transport 6th Km. Charilaou-Thermi Road, 57001 Thermi, Greece 3 Centro Ricerche Fiat Strada Torino, 50 10043 Orbassano TO, Italy 4 PTV AG Karlsruhe Stumpfstr. 1 76131 Karlsruhe, Germany

Abstract - GoodRoute is an R&D project, financed by the European commission in order to develop a decentralized system for minimum risk route calculation, re-routing, driver support, and enforcement. The article describes and discusses the outcomes of the final GoodRoute pilot tests, concerning the communication between the different modules involved in the use cases. An outlook is given on potential directions for further development, which are supposed to be important for a successful implementation of the system across Europe.. Keywords: Intelligent communication control, enforcement, dangerous good transportation.

1

Introduction

The number of dangerous goods transports on European roads is constantly growing, and simultaneously the concerns about the safety of people and the environment along the routes are augmenting. Jurisdiction alone can neither solve the problems in dangerous goods logistics nor guarantee a safety-optimized usage of the traffic infrastructure. A comprehensive risk-management is needed, which is able to close severe lacks of information. Such a lack of information is given when, for example, dangerous goods transports are denied access to modern tunnels, although the alternative routes lead through highly populated areas. This happens most of the times just because the class or the characteristics of the goods are unknown. Such a problematic shift of the safety risk to critical areas could be avoided, if infrastructure operators were informed easily and rapidly about the actual condition of vehicle and the goods loaded on it. Dispatchers do also need dynamic real-time information when planning a route. This is due to the fact that the safety of a

transport depends on quickly changing factors like weather conditions and the current traffic. In case of an accident, mitigation forces usually learn about the details concerning the driver, the vehicle and the dangerous goods just when they arrive at the place where the accident had happened. This way, valuable time resources for the preparation of the reaction are lost. The positive news is that most of the information needed is already available, it is just not possible to have it processed and provided to the persons who need it in real-time. The European Union stepped up to tackle this problem by financing the research-and-development project GoodRoute. GoodRoute has created an information and communication system which is able to collect data from all the stakeholders in the logistics process (e.g., dispatchers, infrastructure operators, drivers, etc.), from Web services (e.g., weather information services or traffic management centre) or from vehicle sensors (e.g., smoke sensors in the trailer). The data can then be processed in order to calculate a transportation route that is both safe and cost-efficient. All actors involved in the process are provided with the information they need, according to the current situation. The GoodRoute project has successfully ended in January 2009. This article discusses some of the outcomes that concern the communication between the different modules in this decentralized system. It discusses the results of the final pilot tests, taking into consideration their relevance for future development and deployment of the system.

2

The Goodroute System

3

Method

The GoodRoute system consists of six major subsystems:

In order to ensure the representativeness of the GoodRoute pilot tests, three different test sites were selected:

•

The Decision Support System

-

Frejus tunnel – Italy

•

The Web Portal

-

Gotthard Strassentunnel – Switzerland

•

The On-Board Telemetry System

-

A highway between Turku and Helsinki – Finland

•

The On-Board PDA

•

The Conflict Resolution

•

The Local Node

The three test sites represent three different landscape formations, which have an influence on the characteristics of the roads and thus on possible connection problems between the modules. Furthermore, this allowed for tests in different weather conditions, such as heavy winter when testing in Finland in December 2008. This can also affect the system performance.

Although each one of these sub-systems consists of various hardware and software modules, they will be considered as autonomous stand-alone black boxes for integration purposes, with only the information flow between them being of interest, [1]. As the differences between all those subsystems and their particular functions are not important within this article, a less complex terminology shall be used in the following text: Decision Support System, Web Portal and Conflict Resolution together form the Control Centre. The Control Centre is to be imagined as a Web service, which processes information, including input from users like infrastructure operators. The On-Board PDA and the On-Board Telemetry System are components of the “On-Board Unit” (OBU).

The selection of those different locations is especially important when it comes to testing the communication that involves the Local Node. For example, a node placed before a tunnel entrance, a bridge or in a valley can behave differently compared to one placed in the open area of a Northern European highway, [4]. The test scenarios used had been elaborated from the project’s use cases and can therefore be considered to represent the aspects most critical for a future implementation of the system. The test scenarios involved: -

Rerouting use cases

The OBU is the GoodRoute installation in the vehicle, collecting vehicle information from the CAN bus, communicating with the other subsystems and supporting the driver by providing user interfaces. The Local Node is a module consistent of a desktop computer and a DSRC transmitter. It is meant to be installed either in a fixed location, such as a tunnel entrance, or in a mobile instance, such as a police car. It is capable of exchanging information with both the Control Centre and the dangerous goods vehicles, [2].

Passport checks (e.g., when entering a structure or another country)

-

A test driver

The Local Node is an autonomous module that collects and processes information from all the vehicles in its action radius. It is the Local Node that enables the GoodRoute system to immediately react to local situation parameters, e.g. by sending a stopping command to a vehicle driver, making him wait for a police inspection, or by sending a re-routing message. The Local Node’s business logic is ADR-based (“European Agreement concerning the International Carriage of Dangerous Goods by Road”) and can be updated via messages from the Control Centre. This ensures that the system can be adapted to changing requirements and legislation or the special needs in a certain country, [3].

-

A co-driver (for reasons of security)

-

Infrastructure personnel, e.g. tunnel operators

-

Emergency alarms

-

Enforcement cases

Involved in every pilot test were:

The GoodRoute technical team, in charge of installing the hardware, etc. The nine test scenarios were completed up to 4 times each test day, in order to get sufficient data. The test vehicle was provided by IVECO and contained: •

A truck tractor OBU

•

A trailer OBU

•

A PDA

•

A sensor net

The driver’s user interface consisted of the OBU interface and a PDA. The OBU displayed messages up to 14 digits and plays sound files with instructions for the driver, e.g. “Tunnel closed. Please stop safely and wait for re-routing.” The PDA held the navigation system and allowed for driver input as long as the vehicle was not moving. During the tests, each subsystem stored all the communication data, together with a time stamp, in a log-file. The OBU, e.g., stored all the data received from the CAN bus, as well as the messages from Local Node and Control Centre. After the completion of the tests, the log-files were analyzed in order -

To find communication errors,

-

To calculate mean latencies, and

To identify possible causes for bad system performance, due to external events.

4

Results

Table XX. displays the results of the communications tests from the Local Node to the Control Centre after receiving the relevant data from the truck’s OBU. The number of checks is higher in the Turku case as due to the harsh weather conditions in Finland, a higher variability of the results had been expected. Table XX. Results of the communications tests Frejus S. Gottard Turku tunnel tunnel Numbers of 15 15 25 checks Time for 3 4 4,5 alarm to reach the Control Centre (mean in seconds) Errors total 2 1 1 Error rate 13% 7% 4%

Total 55 3.8775

4 7.27%

The error rate communication tests between Local Node and on board unit is been 7.27%.

The alarm evoking communication could fail for two reasons: The first reason is a failure of the communication between OBU and Local Node in the first place. Those errors are probably due to the fact that the antennas of OBU and Local Node are directional devices and therefore have a high need for visibility. Failure of this communication occurred when the traffic conditions were suboptimal, e.g. when the truck was in a curve, [5]. The second reason for the communication to fail was to be sought in the connection between the Local Node and the Control Centre. In this case, the most important factor was the whole ambient condition, including temperature, wind, precipitation, etc. The difference in the error rate between the Frejus site and the Turku site cannot be explained by means of statistics only. The results indicate that there might be a siterelated influence factor, all further interpretation has to take into account the very events and conditions when the error occurred. As the tests in Turku were held in November under low temperatures and yet the lowest error rate was measured, the antenna communication seems to be the major problem, [6]. It can be stated that the results from the Finnish test site show that the system at least does have the capability of being rather reliable as long as traffic and track conditions are favourable. Hence, in order to allow for a Europe-wide implementation, the DSCR communication needs to be improved, for example by giving the antennas a wider range or a higher tolerance to visibility problems. As obviously the communication between Local Node and OBU is a source of errors, even if the error rate could be diminished by technical improvements, the question remains why a Local Node is needed at all. The answer is that the Local Node apart from this also has its strengths. One is that a Local Node, placed at a strategic location such as a frontier, will under good conditions respond faster than a Control Centre that is addressed via GPRS communication. Additionally, the Local Node allows the decentralization of certain processes, thus avoiding the accumulation of requests at the Control Centre. This saves resources and makes the whole system more economical to run. This advantage especially applies for mobile Local Nodes, such as the ones that could be installed in police cars. Therefore, the idea of completely eliminating the Local Node from the system is probably not a good one. Still, there is one scenario where a temporary elimination of the Local Node could be considered. Whenever the Local Node cannot be reached by the OBU in an urgent case, the connection for enforcement purposes could be established to the Control Centre via SMS.

5

References

[1] Paglé K., Amditis E., Kauber M., Emmanouilidis V., Patrinos A., Bianconi M.P., et al.. “GoodRoute Deliverable D6.1”, 2007. [2] Bekiaris E., Gemou M.. GoodRoute Deliverable D7.1, 2006. [3] Bianconi M.P., Fioravanti A.. “GoodRoute Deliverable D5.2”, 2007. [4] Gaeta E., Cabrera-Umpierrez, M.F., Arredondo M.T., Bekiaris E.. “Reliable Monitoring of dangerous good transportation through enforcement systems.” ITS Conference New York, 2008. [5] Amditis E., Paglé K.. “Good Route System Architecture for Dangerous Goods Road Transportation. Proceedings of the 10th International Conference on Applications of Advanced Technologies in Transportation”, 2008. [6] GoodRoute Consortium. “Grant Agreement No. 027873 – GoodRoute Description of Work”, 2005.