USE CASES C-ITS CORRIDOR (ENG)

Transcription

1 USE CASES C-ITS CORRIDOR (ENG) PART A: Functional description Date 8 september 2015 Status Final

2

3 Published by Rijkswaterstaat Programma's, Projecten en Onderhoud Realisatiebureau ITS (Programmes, Projects and Maintenance ITS Implementation Office) Author MAPtm Date 8 september 2015 Status Final Version number 1.2 [English translation]

4

5 Contents Introduction 6 1 The Corridor project 8 2 More about C-ITS C-ITS: in the public or private domain? C-ITS structure Cooperative compared with Connected 11 3 Premises and constraints 13 4 Situation in the Netherlands Road works in the Netherlands Measuring network and systems in the Netherlands 17 5 Road Works Warning Premises and constraints Road Works Warning process Minimum CROW layouts to be supported 22 6 Probe Vehicle Data Premises and constraints Basic Probe Vehicle Data Extended Probe Vehicle Data 28 7 Follow-up 29 Appendix A C-ITS standards 30 Appendix B CROW 96a table 32

6 Introduction Background The Corridor project is based on international cooperation between Germany, Austria and the Netherlands with respect to the Rotterdam Frankfurt Vienna corridor. A number of cooperative ITS services (C-ITS) are being developed jointly for this. The objective of the cooperation is to implement cooperative ITS services to improve the traffic flow and safety, with the exchange of information between vehicles and the roadside infrastructure. In the Netherlands, Rijkswaterstaat has taken the initiative for this project and is actively involved in preparations for the introduction of this new technology. The three countries are working closely together with the car industry and service providers to realise several use cases relating to various C-ITS services and applications. Part A includes the functional descriptions of two C-ITS use cases: Road Works Warning and basic Probe Vehicle Data. It aims to provide information about the way in which the new technology can be deployed in Rijkswaterstaat's current operational environment, with a minimum of modifications to the current operating processes and traffic management processes. These functional descriptions will serve as input for the system specifications and technical specifications being drafted as part of the project This will clearly identify which functions the systems will support in the Netherlands. Part B, Dutch C-ITS Corridor Profile, lists the technical and other standards required for the RWW and PVD use cases. The functional description is limited to the use cases which will be implemented in the Netherlands as part of the C-ITS Corridor T project, i.e. Road Works Warning (RWW) and basic Probe Vehicle Data (bpvd). In the context of C-ITS, reference is often made to services, applications and use cases. This document follows the layer structure, from large to small, used in the ETSI standards. This is developed in greater detail in Section 2. Glossary Abbreviation bpvd CAM CEN/ISO C-ITS DENM epvd ETSI HMI I2V IVS IVI Definition basic Probe Vehicle Data (use case) Cooperative Awareness Message Comité Européen de Normalisation / International Organization for Standardization Cooperative ITS Decentralized Environmental Notification Message extended Probe Vehicle Data (use case) European Telecommunications Standards Institute Human Machine Interface Infrastructure to Vehicle In-Vehicle Signage In-Vehicle Information Page 6 of 32

7 IEEE ITS MTM NDW OBU PVD RHW RSU RWS RWW SAE SDO V2I V2V Institute of Electrical and Electronics Engineers Intelligent Transport Systems Motorway Traffic Management system (traffic signalling) Nationale Databank Wegverkeersgegevens - Dutch national road traffic database On Board Unit Probe Vehicle Data (use case) Road Hazard Warning Road Side Unit Rijkswaterstaat Road Works Warning Society of Automotive Engineers Standards Development Organization Vehicle to Infrastructure Vehicle to Vehicle Guide to this document This document (Part A) is part of a set of two (Parts A and B). Part A includes the functional description of the RWW and bpvd use cases. Part B describes the Dutch Profile for the RWW and bpvd use cases. Part A has the following structure: Section 1 contains summary information about the Corridor project. Section 2 gives a general description of C-ITS. Section 3 describes the premises and constraints underlying the functional descriptions. Section 4 gives a summary description of the work currently being undertaken and data gathering in the Netherlands. Section 5 addresses Road Works Warning. Section 6 describes Probe Vehicle Data. Finally, Section 7 lists potential subjects for follow-up studies. Page 7 of 32

8 1 The Corridor project A few years ago, European cooperation on C-ITS resulted in the foundation of the Amsterdam Group ( which aims to bring C-ITS stakeholders around the table to accelerate the implementation throughout Europe. Further to the Amsterdam Group initiative, Germany, Austria and the Netherlands then started the Corridor project. This project aims to roll out two use cases on the Rotterdam - Frankfurt - Vienna corridor: Road Works Warning and basic Probe Vehicle Data. In addition to these two use cases there is also an interest in In- Vehicle Signage (IVS). For the time being, IVS is not being developed in the Dutch Corridor project. On 10 June 2013 the Ministers of Germany, Austria and the Netherlands signed a Memorandum of Understanding to initiate the implementation of the two use cases, RWW and PVD. Given the complexity of the technology it was agreed, in consultation with the other stakeholders, including the car industry, to divide the introduction into stages. The initial implementation (Day One) will therefore offer less functionality than C-ITS will eventually offer. In terms of RWW, the principle is that as soon as there are road works (of short duration, long duration, moving or stationary) a message will be sent to road users. Initially the emphasis was on short duration road works (shorter than one day) but this will have to be extended to moving, long duration and unplanned road works (emergency repairs and incident management). However, for the time being this document will focus on RWW and short duration road works. For Day One, the basic Probe Vehicle Data use case will be limited to gathering information transmitted by vehicles using CAM messages Only the standard data transmitted by vehicles will be received. At a later stage, scenarios may be introduced in which the Probe Vehicle Data is also buffered in the vehicle and transmitted at intervals, or where vehicles transmit data to a receiving ITS station via one or more intermediaries. This will be the extended Probe Vehicle Data use case. Figure 1. Rotterdam Frankfurt Vienna corridor. Page 8 of 32

9 2 More about C-ITS Those working on C-ITS often provide functional descriptions of the operation of the systems (technical or otherwise). However, Section 2 describes the context in which the ITS services operate. This is because a range of standards, protocols and agreements are needed for the integrated operation of the system (interoperability). 2.1 C-ITS: in the public or private domain? In the Netherlands, tasks relating to traffic are clearly separated. For example, private parties are responsible for informing road users. Traffic management is currently a public task. Various service provides (e.g. ANWB and VID) provide traffic information to road users through channels such as radio and apps, based on NDW data and other sources. Several navigation systems also use their own and NDW data to provide current and personalised route information to road users. Road managers use systems such as DRIPS (variable message displays) and traffic signals to implement traffic management. Control scenarios, based on agreements between the relevant road managers, determine how traffic is diverted, buffered or otherwise accommodated. This supports effective local and regional traffic management. At times, the worlds of traffic information and traffic management may conflict. This is because traffic information is primarily intended for the individual road users. However, the objective of traffic management is to optimise the operation of a network. Consequently, individuals may sometimes be inconvenienced to benefit road users as a whole. C-ITS provides opportunities for services in several areas, such as safety, traffic management and the provision of information. Which of those services are provided by the market and which by the public sector is currently being discussed, both nationally and internationally. For now an obvious choice would be for time and safety-critical applications to be provided from the roadside and come under the responsibility of the road manager. In case of the Corridor this is Rijkswaterstaat. In case of C-ITS this concerns both roadside and in-car (vehicle) systems which have to communicate with each other unambiguously and securely. Standards to ensure C-ITS interoperability are being developed in the international arena. 2.2 C-ITS structure Services, applications and use cases are some of the terms frequently used to indicate different application levels in C-ITS. However, they are not used consistently and are sometimes used interchangeably. ETSI standard TS Basic Set of Applications (V1.1.1) provides some guidance for the terms to be used. Here we will discuss the meaning of these terms, both in relation to this standard and also in view of the interpretation of these terms by the Corridor partners. Page 9 of 32

10 ETSI defines "application" and "use case": ITS application: system that defines and implements an ITS service to users of the system ITS use case: procedure of executing an application in a particular situation with a specific purpose Although this document uses the term "service", it is not actually defined. Indirectly, it may be concluded from the document that an ITS service is a set of ITS applications. The document (ETSI TS ) refers to only four services: Active Road Safety Cooperative Traffic Efficiency Cooperative Local Services Global Internet Services However, the range of services is dynamic and growing. The range services mentioned in ETSI TS is incomplete and not entirely up to date. The document dates from 2009 and has not been updated since. To determine the set of services an application belongs to we first have to consider the use cases of the application. These determine the service the application is classified under. Service: highest level of aggregation within C-ITS. Distinguishes traffic warning systems, traffic information systems and data gathering systems, etc. Broadly speaking, this defines the division between various subjects. Application: a service can include a number of applications. These are all separate systems, linked to the key objective. Examples: Road Hazard Warning and Cooperative Awareness. Both these systems come under the main heading (service) Active Road Safety. Use case: next we can subdivide an application, to create variants of the application. These variants, or developments of specific components are known as use cases. Road Works Warning is an example. Figure 2. Layered structure of C-ITS. RWW and bpvd (dark green blocks) are being developed as part of the Corridor project Page 10 of 32

11 Management layer Security layer USE CASES C-ITS CORRIDOR Part A: Functional description 8 september 2015 The layered structure of services, applications and use cases was described above. However, that only provides the functional structure within C-ITS. A lot of work is then needed to make a use case operational. The standards being developed by the Standards Development Organizations (SDOs) need to be profiled. That means that each standard has to be supplemented by the information needed to apply a use case in accordance with local legislation, regulations and guidelines. In the context of C-ITS, the applicable standards can be grouped as follows 1 : Management layer Application layer Facilities layer Network and Transport layer Media and Access layer Security layer Each component has its own function. This facilitates the classification of new and existing standards. Within the RWW and PVD services the ETSI-DENM and ETSI- CAM standards cover the transmission of substantive data. These standards are incorporated into the Facility layer. For example, the Security layer addresses message security, and the Network and Transport layer defines connection standards (3/4G or G5). Application layer Facilities layer Network & Transport layer Access layer Figure 3. Layers within C-ITS 2.3 Cooperative compared with Connected At present there are three key developments in ITS: ITS based on cooperative systems, ITS based on connected systems and ITS based on autonomous systems. The last of these three is outside the scope of this report. Often these are independent systems in a vehicle, related to safety and comfort. Examples include Adaptive Cruise Control and Lane Departure Warning. Road Works Warning and Probe Vehicle Data can use both cooperative and connected systems. In principle, these systems have the same functionality; information is transmitted from one place to another. However, the methods used for this are different, which can lead to different service levels. Here we will discuss the differences between the cooperative and connected systems. Cooperative Cooperative systems are systems where vehicles communicate with each other and/or with RoadSide Units (RSUs). Communications is across short distances: between 500 m and 1.5 km. Within this range a vehicle can send a message to 1 C-ITS Architecture ETSI TC ITS EN v1.1.1 (2010-9) Page 11 of 32

12 another vehicle or an RSU using a WiFi-P connection (also known as ITS-G5). Similarly, an RSU can send a message to a vehicle. Often the RSU will be connected to a remote central station. Cooperative systems are generally considered as time and safety-critical systems. This means that aspects such as the transmission speed, location reliability and guaranteed reception are extremely important. At present, the infrastructure for cooperative communications (WiFi-P) is not available on a large scale and will therefore require investment. Connected Connected systems are based on communications between vehicles and a central station, across longer distances. This can be based on two-way communications (3/4G) or broadcasting (FM/DAB). These connections are handled by existing networks and therefore do not require additional investments. Connected systems are mostly used to inform vehicle drivers across longer distances. They can be rolled out relatively quickly using apps, etc. The data communications delays means connected systems are less suitable for time and safety-critical applications. Page 12 of 32

13 3 Premises and constraints Before this functional description was written there were some issues about which decisions had to be made. These issues were discussed by the NL Corridor project team. This resulted in the definition of a number of premises and constraints, both general and specific to certain use cases. Main road network and secondary road network This functional description is limited to C-ITS applications on motorways. Applications for the secondary road network will not be considered. CROW guidelines In general, when implementation C-ITS applications we will follow existing CROW (infrastructure, traffic & transport centre of expertise) guidelines where possible. CROW publication Road Works / Measures on highways 96a (in Dutch: Werk in Uitvoering / Maatregelen op autsnelwegen 96a ) will be used as the guideline for road works. It is essential that existing approaches and methods do not constrain the opportunities provided by new technology. Amsterdam Group This functional description is based on the documents produced by the Amsterdam Group and the Corridor Partners. Human Machine Interface (HMI) Aspects relating to the Human Machine Interface are outside the scope of this functional description. This means that it is specified what information has to be presented to road users and at what time, but not when and in what way it is presented to the road users. That responsibility lies with the car industry. Back-office C-ITS and the use cases described in this document require accurate and current information. For example, for road works this would include the exact road configuration, location and position of lane closures, starting and ending times of the works, etc. The process to gather this information is outside the scope of this functional description. It is assumed that the required information is available. Cooperative compared with Connected The Corridor partners (Germany, the Netherlands, Austria) have agreed to implement the C-ITS use cases. Here, the "C" represents cooperative, using WiFi-P (also known as G5). The "connected variant, which uses different communications technology such as 3/4G and DAB, is considered as relevant to creating awareness of the Corridor use cases and to organise the underlying processes. The NL-Corridor project team has indicated that the emphasis is on "cooperative". The connected variants will be left to parties operating in the market. However, the NL-Corridor (Rijkswaterstaat) will support these developments, specifically in terms of the provision of information. Coordination with the market In addition to the definition of the use cases, from the road manager's perspective, we also need coordination with the market (OEMs) as the transmitting party, to ensure that the information transmitted will indeed be used. It will also be Page 13 of 32

14 necessary to encourage the market to provide data which will be made available through the NDW to develop information services. The coordination effort is outside the scope of this functional description. RSU implementation The required beacon density for ITS in the Netherlands is not yet known. This will depend on the requirements which all the applications, services and use cases (of which RWW and bpvd are just two) make together. Using the experience gained with this project and other input this will have to be determined and then lead to an ITS design guideline. For the NL-Corridor project it is assumed for bpvd that the messages will be gathered in the same locations where PVD is transmitted. For RWW is assumed that where there are signals (both fixed using MTM2 (Motorway Traffic Management system) and temporarily, with MRS (Mobile Road Signaling)) the first red cross (lane closure) indicates the start of the road works and the "end of restrictions" sign the end of the road works (see also 5.2). In places where there are no signals, the best location for the RSU will be determined in each case separately. The RWW message should be transmitted upstream of the start of the road works. The distance between the RSU and the start of the road works should not be too large, otherwise during the time it takes to travel between the RSU and the road works the message might become invalid, but the distance should also not be too short as enough reaction time should be provided. As a minimum, the RSU should be installed downstream of the last entry slip road leading to the road. Given the fact that the distance between signal gantries is based on similar traffic management premises, it is assumed that the gantry with the "change lane arrow" (the gantry upstream of the red cross) provides the best position for the RSU. Given technical considerations too, it would be preferable for the RSUs to be installed on existing MTM gantries given the availability of power and communications networks and better coverage and range. To save costs, RSUs could be fitted to every other MTM gantry, or even only to just the gantries downstream of entry slip roads. This would provide broad coverage at a much lower cost. Another option would be to fit road inspector vehicles with C-ITS stations. Although this is not a true RWW deployment scenario it is a highly relevant safety application which can lead to significant gains. However, this would require additional coordination as information from these vehicles would have to be coordinated with, and consistent with, other signs on vehicles and gantries. This safety application will require further consideration. The NL-Corridor project is currently working with the assumption that there will be: - Mostly fixed RSUs, connected to a central station - A limited number of portable RSUs, connected to a central station This is based on the preference expressed above (i.e. to install the RSUs on MTM gantries) and because it is assumed that the beacon network created in this way will also provide a good basis for other applications, services and use cases in future. Portable RSUs are considered as a temporary solution which will not be needed in the long term and which, given the logistics disadvantages, will only be used when absolutely necessary. Current processes The premise is that the initial implementations of C-ITS will cause or require the least possible change to the current processes. Page 14 of 32

15 Practical aspects The premise is that the initial implementation of C-ITS will be carried out in the near future on the Corridor. Consequently the focus is on what is practical and feasible. Futureproofness and feasibility within the project period will have to be considered at all stages. The NL-Corridor project team gives priority to feasibility. Consequently, this functional description is limited to the initial implementation. The final functionalities and options in the longer term are greater than those described in this document. Page 15 of 32

16 4 Situation in the Netherlands 4.1 Road works in the Netherlands There are some specific traffic management issues in the Netherlands which may have a direct or indirect impact on the development of the RWW use case for the Netherlands. The most relevant of these are: Rush hour lanes/additional lanes Safety trailers (signal trailers/lane closure trailers) Traffic signals (MTM) Loop data (monitoring information) SPIN (System for Planning and Information in the Netherlands) Traffic Control Centre CROW (infrastructure, traffic & transport centre of expertise) NDW (National Data Warehouse, national road traffic information database) The number of hard shoulder rush hour lanes and additional narrow rush hour lanes on the left edge of the carriageway has increased significantly in the Netherlands in recent years. These lanes are much less common in surrounding countries and are never located on the left of the carriageway, as is common in the Netherlands. The high density of MTM signals in the Netherlands is also unusual. Around 40% of all main roads in the Netherlands feature MTM, which is used on a much smaller case in other countries. Over 75% of the route of the Corridor project has MTM signals (see Figure 4). Motorway with MTM signals Figure 4. Corridor route in the Netherlands Consequently, the inductive loop measurement network in the Netherlands is much denser than in other countries. If there is no MTM then road works are normally indicated by temporary signal gantries (MRS). SPIN is the central logging, acceptance and registration system for road works in the Netherlands. It provides detailed information for practically all planned road works, such as time, location, impact on the traffic flow and the diversions in operation. Page 16 of 32

17 Consequently, there is a wealth of information about planned road works available in the Netherlands. A similar system is used in Austria. However, the traffic management measures in the field are often implemented slightly differently than planned, recorded and coordinated in SPIN. In some respects, the approach taken to road works in the partner countries differs significantly from that in the Netherlands. First of all, signals (MTM) are rarely used in the other countries. Similarly, temporary signals over the road are rarely if ever used. Outside the Netherlands, the demarcation and protection of road works largely relies on truck mounted attenuators and temporary signs. Apart from the use of signals, the approach taken to road works warnings in Austria is closes to that in the Netherlands. Road works are always indicated by one or more signs on the hard shoulder. If a mobile lane closure is used then a preliminary warning vehicle moves along with the worksite on the hard shoulder. Germany takes a different approach to protecting road works sites. Truck mounted attenuators are used, but these are often the first indication road users get about road works ahead. Rumble strips and warnings in the verge are not used. Signs are occasionally placed as a preliminary warning of temporary road works. Hence the RWW use case in Germany differs from that in the Netherlands as less information is shared with road users. 4.2 Measuring network and systems in the Netherlands There is a variety of measuring systems in and around the road infrastructure (e.g. inductive loops and cameras) to measure traffic data (primarily speed and intensity). On the main road network the traffic flow is mostly measured using inductive loops. In some locations infrared units (PID: Passive Infrared Detectors) are used. In addition to providing static historical data, more and more systems provide realtime online information. These measurements cover the main road network and large parts of the secondary road network in the Netherlands. Speed, travel time and intensity are the primary traffic parameters. In the Netherlands the NDW (national road traffic information database) is the Single Point of Access. This means that practically all traffic data in the Netherlands is made available by NDW in accordance with defined quality requirements. At present, the data flow measured by the vehicle or an app (Floating Car data) is not included in the NDW dataset. Other countries in Europe are also developing Single Points of Access. However, the implementation is different in each country. For example, in Germany the access to the data is provided centrally, but not the data itself. Page 17 of 32

18 5 Road Works Warning In the C-ITS framework, the Road Works Warning (RWW) use case forms part of the Road Hazard Warning application. The RWW use case relies on communications between roadside systems and vehicles. The key objective is to reduce the number of collisions with protective objects near road works. The aim is to implement this using the Road Works Warning use case. This provides timely warnings to drivers about the hazard zone they are approaching, including information about lane layout changes, lane availability, temporary speed limits, and any other restrictions affecting the road section. Earlier Dutch reports 2 have covered Road Works Information (RWI) and Road Works Data (RWD). These are not separate use cases within the C-ITS layers, but different scenarios relating to other use cases. RWI comes under the Traffic Information and Recommended Itinerary use case. RWD comes under extended Probe Vehicle Data. As RWD and RWI will not be rolled out in the Corridor project they are not covered in this report. 5.1 Premises and constraints CROW 96a CROW 96a provides the starting point for road works in the Netherlands and therefore also for the NL-Corridor project. We will now describe how the measures in the CROW 96a guideline are supported (in full or in part) for the Road Works Warning use case. DENM To implement RWW the Amsterdam Group has selected the DENM variant. At present, DENM is the only suitable message specification available as a draft standard. DENM (Decentralized Environmental Notification Message) was originally intended for sending messages between vehicles about anything observed in their environment. Some minor modifications are needed to make DENM suitable for RWW. The DENM standard, including the minor RWW modifications is a widely accepted, also by the car industry. In future, other message sets such as IVI (In-Vehicle Information) may provide better and more extensive options. Whether or not, and how any migration from DENM to IVI will be implemented will have to be agreed at the European level. This concerns issues such as version management, duplicated services, etc. In the context of this document, DENM is based on ETSI EN v RSU implementation As indicated in the discussion of the general premises and constraints, it has been decided to use mostly fixed RSUs connected to a central station. An exception is made for MRS (Mobile Road Signaling). These gantries will be fitted with a temporary, mobile RSU. Their functionality will be limited as the central station will 2 Primarily the report Overview of Standards for First Deployment of C-ITS. Page 18 of 32

19 have little information available. If an MRS is not used, then a portable RSU could be installed on the safety trailer. Road works types The Amsterdam Group identified three types of road works relevant to RWW: 1. Short term mobile 2. Short term stationary 3. Long term stationary For the time being, the emphasis in the Netherlands will be on the second type: short term stationary. Short term mobile will be deployed where permanent signals (MTM2) are available and will be used as a supplementary measure. Similar support can be provided for short term stationary. For example a rolling road closure where an MTM is used and moves along with the rolling closure. In areas where there are no fixed signals, consideration could be given to placing a portable RSU on the vehicle. Long term stationary will be similar to short term stationary if safety trailers and MTM are used. If trailers and MTM are not used there will often be a new road configuration. In that case the question arises if RWW messages should actually be transmitted. As long term stationary is on the agenda of the Amsterdam Group but has not been developed so far it is not covered by this report. Road works start The RWW message contains the event position which indicates the start of the road works. According the CROW guidelines the datum (zero point) of the road works is the truck mounted attenuator, the start of the work area. For the implementation of RWW in practice it was decided to define the start of the road works as the first gantry where the lane is closed (red cross, X location), rather than the zero-point. This is because from that point onwards the lane is closed and should not be used by traffic. Additionally, according to road workers, the area upstream of the safety trailer is the most dangerous area. Hence the event position should be upstream of the trailer. Road Works Warning - Day One The use case was described from the perspective of the road manager. Obviously, its development will also depend on the way in which the information received is used in cars. In meetings and workshops earlier this year the car industry indicated that for the time being only a limited part of the information in the RWW messages transmitted by the RSUs will be used. The car industry gives priority to information about lane closures. This relates both to road works and more general obstructions (stationary vehicles). The aim is to prevent collisions with stationary vehicles. There is less interest in providing additional information, e.g. about speed restrictions, etc. 5.2 Road Works Warning process Below we will use an example to explain how measures relating to road works are structured, and how this will be translated to the Road Works Warning use case. Current road works process The process which has been used for years in the Netherlands on motorways with signals is described below. See also Figure 5. Page 19 of 32

20 It is Tuesday night, 21:05 h, and a traffic team is standing by on the A58L, upstream of the Baars intersection, waiting till they can implement a lane closure at verge marker post Part of the surface of the left-hand lane (lane 1) has to be replaced. The traffic team contacts the traffic control centre and requests permission from the traffic control manager to implement the road closure (approved in advance and allocated a SPIN number). The traffic control manager assesses the request on the basis of the current situation on the roads and decides that the closure will not lead to undue traffic disruption. The traffic control manager then indicates the measure on the traffic signals. Lane 1 is now marked with a red cross and speed restrictions are in place. The traffic team drives onto the A58. The truck mounted attenuator stops at The contractor can now safely position the safety trailer and deploy it, downstream of the truck mounted attenuator. Once the trailer is in position the contractor places the traffic cones along the length of lane 1. Once the trailer is positioned the truck mounted attenuator can drive away. Once the lane is fully coned off the contractor with the heavy plant arrives at 21:15. The work can now start. If there are no permanent signal gantries then a temporary MRS mobile gantry is used. This provides a limited form of signalling. Figure 5 Setting up road works RWW C-ITS process The C-ITS RWW use case warns drivers about the lane closure and other restrictions relating to road works. When the traffic control manager closes lane 1 with red crosses and implements speed restrictions, the RSU on the gantry where the "change lane arrow" is displayed (Y location) transmits RWW messages to the vehicles using WiFi-P. In this way the vehicles receive information about the lane Page 20 of 32

21 closure and speed restrictions, including the exact location, time, duration, etc. (see Part B for further details). The information contained in the RWW message is based on MTM information and is therefore consistent with the indications on matrix signals. The timing is also synchronised with MTM; the message starts when the red cross appears and stops when the red cross disappears. The Onboard Unit (OBU) receives the RWW message (the reception point) about 1 to 1.5 km upstream of the start of the road works (based on: start of the road works at X location, transmitted from Y location, gantry distance on average 800 m, WiFi-P range 0.5 to 1.5 km). This ensures that the information is available in the car well in time and enables the OBU to inform the driver in time that they have to adapt their speed and/or change lane (the alert point). The way in which the driver is actually informed depends on how the OBU processes and presents the information. This implementation is determined by the market (i.e. the car industry). It is quite possible that the car industry decides not to use some of the information (e.g. speed limits). It should be noted that although it is uncertain if and how the OBU processes and presents the information, it is still in the interest of the road manager to provide all relevant information timely and completely. Although this will not guarantee the correct and complete operation of RWW, it is an essential prerequisite for it. If an MRS mobile gantry is used because there are no signals along the road, then the messages will be transmitted by a temporary portable RSU. Its functionality will be limited as the central station will have little information available (MRS units operate autonomously). The objective is to provide the same functionality in settings with and without traffic signals. However, at present this is difficult to implement in practice. Figure 6 C-ITS process within RWW. Left: with MTM Attention: speed limit 90 km/h, hard shoulder and right-hand lane closed for 500 m. Right: with MRS Attention: road works ahead. Figure 7 indicates the locations where information is transmitted, and what is transmitted. The functional structure of the traffic management measure is shown on the left. The technical implementation is shown on the right, and includes some, but not all, elements of the DENM standard. It is important to note that the location where the information is displayed in the car (the alert point) is not determined in Page 21 of 32

22 advance. It could depend on the vehicle's speed, the car manufacturer or the weather conditions. However, this point will always be somewhere in the Communication Zone. Figure 7 Structure of an RWW C-ITS DENM message Minimum CROW layouts to be supported In the Netherlands, CROW publication 96a is the guideline for defining road works layouts and measures. Road managers and traffic control stations use the guideline to assess proposed road works (generally submitted by contractors) in terms of safety and traffic flow. The table lists the CROW 96a layouts which can be implemented in full or in part with DENM messages. Layouts which are not fully covered by a DENM message described and explained in Part B of this report: Dutch C-ITS Corridor Profile. The layouts defined in the CROW 96a guideline were assessed on their compatibility with the DENM standard. The results of this assessment are included in the table below. Based on the DENM fields to be completed, it was determined if a measure can be communicated using DENM. The following traffic management and functional fields were considered: Lane marked with a red X Lane closed with a truck mounted attenuator Lane status Hard shoulder status Speed limit Can the obstruction be passed? (e.g. safety trailer) The assessment of these criteria was classified as: Yes, No, Not applicable. This is because a measure might not be associated with a lane closure, in that case it is marked n/a (not applicable). In the DENM standard the value x/not available is Page 22 of 32

23 used. Some layouts have to be communicated using several DENM messages. This is because one layout might be associated with several different speed limits. If the whole layout can be covered by one or more DENM messages then it is classified as ***. If the essence can be communicated, but not all options are covered, the measure is classified as **. If it is only possible to communicate that there are road works then the classification is *. The following traffic management elements cannot be handled by DENM: Narrow lanes Carriageway division Works exit/entrance Special features relating to parallel lanes, intersections and situations different from the standard CROW 96a layouts. The layouts printed in italics are not widely used. Appendix B includes a full assessment of all the traffic management layouts. Type Description Applica ble Notes Static, short duration (rolled out as part of Day One) 110 Next to the carriageway, outside the obstacle-free *** zone (in the verge) 112 Next to the carriageway, outside the obstacle-free *** zone (exit slip road closure) 120 Next to the carriageway, within the obstacle-free *** zone 130 On the hard shoulder, more than 1.10 m from the *** edge marking line 140 On the hard shoulder, more than 1.10 m from the *** edge marking line 210 On the hard shoulder, within 1.10 m from the edge *** marking line 220 On the left-hand lane, or on the left within 3.50 m *** from the edge marking line 230 On the left next to the carriageway, over 3.50 m *** from the edge marking line 240 Several adjacent lanes *** 250 Several adjacent lanes (via the hard shoulder) *** 310 Several adjacent lanes (via the hard shoulder) *** 311 Several adjacent lanes (via the hard shoulder), without MTM ** Traffic guided to the hard shoulder by beacons, without a red cross Rolling road closure (outside the current scope) 410 On the right next to the carriageway, within the *** obstacle-free zone 420 On the hard shoulder, more than 1.10 m from the *** edge marking line 430 On the hard shoulder, more than 1.10 m from the *** edge marking line 440 On the full hard shoulder or the right-hand lane *** 441 On the full hard shoulder or the right-hand lane *** Covered by DENM, but not by Page 23 of 32

24 Corridor Day One 930 Right-hand lane *** Covered by DENM, but not by Corridor Day One 931 Intermediate lane *** 932 Left-hand lane *** Covered by DENM, but not by Corridor Day One 933 Rush-hour lane *** 934 Lane next to the rush-hour lane *** 944 Rolling road closure, on the left *** 945 Rolling road closure, on the right *** Static, long-term (outside the current scope) 510 Hard shoulder closed, no speed restriction *** 520 Hard shoulder closed, with speed restriction *** 620 Lane closure - one lane *** 630 Lance closure - several lanes *** 640 Closure with lane changeovers * Narrow lanes cannot be indicated 650 Closure with lane changeovers * Narrow lanes cannot be indicated 660 Closure using the hard shoulder * Narrow lanes cannot be indicated 670 Closure using the hard shoulder * Narrow lanes cannot be indicated 680 Closure relating to road works in the central reservation * Narrow lanes cannot be indicated 710a Example 4-0 system, with MTM * Narrow lanes cannot be indicated 710b Example 4-0 system, with MTM * Narrow lanes cannot be indicated 711a Example 4-0 system, without MTM * Narrow lanes cannot be indicated 711b Example 4-0 system, without MTM * Narrow lanes cannot be indicated 720a Example 3-1 system, with MTM * 3-1 system division cannot be indicated 720b Example 3-1 system, with MTM * 3-1 system division cannot be indicated 721a Example 3-1 system, without MTM * 3-1 system division cannot be indicated 721b Example 3-1 system, without MTM * 3-1 system division cannot be indicated 730a Example 3-0 system, with/without MTM *** 730b Example 3-0 system, with/without MTM *** 910 Lane adjacent to entry/exit slip road * Works exit/entrance cannot be indicated 911 Lane adjacent to entry/exit slip road * Works exit/entrance cannot be indicated 912 Right-hand and left-hand lane beyond the entry *** slip road 913 Right-hand and left-hand lane beyond the entry slip road *** Page 24 of 32

25 914 Right-hand and left-hand lane near a division/merging point 915 Right-hand and left-hand lane near a division/merging point 920 Work area on the right * Works exit/entrance cannot *** *** be indicated 921 Work area on the right * Works exit/entrance cannot be indicated 922 Examples: * Works exit/entrance cannot 923 Example design, entry/exit slip road: work area on the right 924 Example design, entry/exit slip road: work area on the left 925 Example design, entry/exit slip road: work area on the left 940 Right-hand lane closure *** 941 Right-hand lane closure *** 942 Left-hand lane closure *** 943 Left-hand lane closure and both directions *** Table 1: CROW 96a measures and DENM messages be indicated * Works exit/entrance cannot be indicated * Works exit/entrance cannot be indicated * Works exit/entrance cannot be indicated Page 25 of 32

26 6 Probe Vehicle Data The primary purpose of Probe Vehicle Data (PVD) is to gather information provided by vehicles. The data elements include speed and direction. Two use cases have been defined for the Probe Vehicle Data application: 1. Basic Probe Vehicle Data based on messages continuously transmitted by vehicles 2. Extended Probe Vehicle Data based on data stored in vehicles which is transmitted at intervals, when passing an RSU. Extended PVD - outside the scope The extended version makes additional requirements of the in-vehicle equipment. As a result the car industry is currently very hesitant to implement this. Data has to be stored and may have to be aggregated. Additionally, a privacy issue could arise if this makes it possible to monitor the driving behaviour and profiles of drivers. Hence, in the initial implementation the extended version will not be considered and at present there are no conclusions associated with this. However, to make this document more comprehensive, extended Probe Vehicle Data is discussed in greater detail in section Premises and constraints DENM and CAM compared Vehicles fitted with C-ITS systems can transmit two message types: CAM (Cooperative Awareness Message) and DENM (Decentralized Environmental Notification Message). CAM messages relate to the status and position of the vehicle and are transmitted continuously. In contrast, DENM provides information about the environment, as observed by the vehicle, and is only transmitted occasionally. Initially, PVD will be based on CAM messages as the car industry has indicated that this will be introduced on new vehicles from 2015/2016. Currently there is no information about how, and if, vehicles will transmit DENM messages. Similarly, it has not been decided when vehicles will start transmitting DENM messages. In the context of this document, CAM is based on ETSI EN ETSI EN v Receiving everything At present it is unknown what opportunities the new data will provide. Hence, it has been decided that for the time being, data will only be gathered. The potential uses to which the data can be put, and how it has to be processed, can be analysed in other activities. Data gathering and storage also introduces privacy considerations, and the possibilities, and impossibilities, are currently unclear. Where possible (permitted) the intention is to make the gathered data available to third parties for other purposes. Again, the consequences in terms of storage and processing capacity are unclear. Roadside as a router At the time of the initial implementations the coverage provided by vehicles equipped with C-ITS will be limited. Hence a several safety-related use cases based on V2V (see section 2.4) will not be feasible - there will simply be too few vehicles which can communicate with each other. Page 26 of 32

27 The RSU network could then distribute this data onwards (bypass). The RSUs receive the vehicle messages and retransmit them to other passing vehicles, and possibly also upstream. In this case, the roadside infrastructure essentially operates as a router for V2V messages. This provides added value, especially during the initial implementations when there will be relatively few C-ITS vehicles on the road. However, the project team has decided not to include this use case in the scope for the time being. However, it might be worthwhile to discuss this use case with the car industry, to implement additional use cases more quickly. 6.2 Basic Probe Vehicle Data The basic Probe Vehicle Data use case operates on the basis of information from various sensors in the vehicle, which is transmitted as CAM messages. The CAM messages contain information about parameters such as the vehicle speed and direction. The information can be received by other vehicles. Further to this these may decide to take actions related to safety or other issues, such as offering advice on the speed or manoeuvres to the driver. RSUs can also receive messages from passing vehicles and use it for local purposes (Automatic Incident Detection, AID) or forward it to a back office (traffic control centre) for further analysis and traffic management purposes. Key limitations of this use case: Only messages from vehicles within range of the RSU will be received. The RSU only receives current information from a vehicle when it passes. Hence there is no historic information about the road upstream of the point of reception. The way in which data is gathered with a PVD is fairly similar to the way it is currently gathered using inductive loops. In this case too, data is gathered from point locations. Until all vehicles have been fitted with C-ITS units it will not be possible to measure traffic intensity using PVD. The traffic intensity is a key traffic management parameter which is highly relevant to a number of traffic management applications. However, new parameters such as the acceleration, deceleration and direction of vehicles offer new and additional options. For example, an AID (Automatic Incident Detection) algorithm can be optimised using these new parameters. For the basic PVD use case the Corridor project aims to access at least the following vehicle parameters: Vehicle position Vehicle speed Vehicle driving direction Vehicle lights status Vehicle length Deceleration and acceleration This data can be forwarded to a central station, either directly or after aggregation. This information can then be used to make a better assessment of the situation on the road and even the weather conditions at a particular location. At the central station the data can be combined with data from other sources, allowing for even better conclusions about the situation on the road. Vehicles need not provide all this data. Some fields of the CAM standard could be left blank (optional fields) while other fields may get the value "not available". It Page 27 of 32

28 could therefore happen that a CAM message is complete and correct, but functionally incomplete or even empty. 6.3 Extended Probe Vehicle Data Although extended Probe Vehicle Data is outside the current scope, it is still described here given its relevance. This is because the extended PVD use case supplements the basic PVD use case. The same vehicle data is accessed by CAM messages. The main difference between extended and basic PVD is that with extended PVD the data is buffered by a vehicle when it is not within range of an RSU. As soon as a vehicle comes within range of an RSU the buffered data is transmitted. This means that data about areas without RSU coverage can still be accessed, albeit with a delay. The size of the delay depends of the vehicle speed and the density of the RSUs. The information provided by extended PVD is the same as for basic PVD. The added value of this use case is that information is stored in the vehicle and therefore available to the next RSU. For example, if RSUs are installed every 5 km, then basic PVD will only include information about the speed and lights status of vehicles within range of an RSU. If extended PVD is used, vehicles store the information between RSUs and it is accessed when a vehicle comes within range of an RSU. This data is valuable as the data storage standard includes the locations. Page 28 of 32

29 7 Follow-up The following items can serve as input for further studies: Support Both the Functional description (Part A) and the profiles (Part B) need to be coordinated between Rijkswaterstaat and the C-ITS Corridor Project team to unify the approaches. They will also have to be discussed with the partners in Germany and Austria to promote harmonisation. Other standards This document mostly refers to the DENM and CAM standards which are described in Part B of this document. However, there is a range of other relevant standards, some more technical, some more general. These standards are listed in Part B. They will be assessed and profiled where necessary. (Here profiled means: supplemented by the information needed to apply a use case in accordance with local legislation, regulations and guidelines.) Road Side Unit Initially, it will be assumed that the RSUs will be fitted near the traffic detection gantries, at an average spacing of 1.5 km. The choice of location of the RSUs should not only depend on technical factors, but also on traffic management considerations. For example, entry and exit slip roads motorway should also need be considered. Dialogue with suppliers In addition to the coordination between the C-ITS Corridor partners, it is also important that the functional description (Part A) and the profiles/use cases (Part B) are discussed with suppliers and the car industry (OEMs). This coordination should ensure that all parties know what to expect of the initial C-ITS implementation. Vehicles driving in the wrong direction Based on the PVD, an RSU might conclude that a vehicle is driving in the wrong direction. This information can be presented to other road users, possibly with a new use case (connected and/or cooperative). Message transmission start and end times Even before road works start, DENM messages can be transmitted, including the time from which the message is valid. However, one has to consider the fact that the positions of all the objects and DENM elements may only be known once the road works have been set up on the motorway. Hence, exactly when transmissions can start has yet to be determined. An interface to the MTM will also have to be considered. Further analysis of rolling roadblocks and long-term closures This document is mostly concerned with short-term static closures. Rolling roadblocks (mobile carriageway closures) and long-term closures (also known as systems, e.g. 4-0) are not considered. However, these traffic management measures are used relatively frequently in the Netherlands. It would therefore be interesting to analyse these measures and determine if the DENM standard covers them adequately. Page 29 of 32

30 Appendix A C-ITS standards Many standards are being developed in various countries and regions. They aim to reduce complexity and enable any stakeholder to understand, use the systems identically. These standards provide a unified basis within which different systems can communicate with each other, or they provide security. Hence, standards can enable systems from different suppliers to communicate with each other (interoperability). In case of C-ITS this concerns both roadside and in-car (vehicle) systems which have to communicate with each other unambiguously and securely. Standards to ensure C-ITS interoperability are being developed in the international arena. C-ITS and standards development organisations Every standard is developed by a standards development organisation (SDO). As they are developed by the SDOs in a long process (from draft technical specifications to standards) involving stakeholder working parties these standards receive widespread support. This appendix lists the SDOs relevant to C-ITS. There are SDO for different areas of technology, applications and regions. Standards can address both technical and process issues. The following SDOs are relevant to C-ITS: ETSI CEN/ISO SAE IEEE There are also platforms and standards which are relevant to C-ITS because of the underlying processes and services. Some examples include: Datex DVM-EXCHANGE TISA ETSI (Europe) ETSI is a major SDO in the field of telecommunications. The 3/4G standards for mobile telephone were developed by ETSI. Hence it is an important SDO in relation to C-ITS. This is because the way in which messages are transmitted is essential to the effective operation of services. According to the European Commission's mandate 453, ETSI is the SDO within C-ITS responsible for technical communications. CEN/ISO (CEN = European / ISO = worldwide, but both are used worldwide) CEN and ISO are SDOs which primarily work with local standards bodies to develop standards which can be used internationally rather than locally. CEN's major role is to develop standards which can be implemented quickly and easily by the market. CEN develops standards in many areas. SAE (American) SAE is the American equivalent of ETSI and CEN/ISO. The standards developed by this SDO should also be considered, to obtain worldwide compatibility (primarily among car manufacturers). Page 30 of 32

31 IEEE (American, standards used worldwide) IEEE is the SDO which developed the communications standard for WiFi communications. This standard defines the structure for communications based on MAC addresses. In Europe an ITS-G5 protocol operates on top of the IEEE standard. Page 31 of 32