21. Traffic management and control
21.0 Overview of service
21.0.1 Transport context
The purpose of traffic management and control is to keep the user of road vehicles moving safely, particularly in circumstances where this becomes difficult: excess demand, poor weather, etc. It is a natural complement to traffic regulation, which imparts and enforces rules on road users that are intended to maintain safety etc.
The first traffic management tool was probably the divided carriageway, with the associated regulation to drive always on the left or right of the dividing line (depending on country!). The first ITS tool was the traffic signal, with the associated regulation to stop at a red light. However, with computerisation, networking, detector systems, and more recently personal and in-vehicle systems, the array of tools used to drive behaviour has increased hugely – and continues to expand, especially in the area of direct road-user interaction though cooperative ITS.
The purpose of traffic management has also undergone considerable development. In many places, “maintaining flow and safety” has been joined by “maintaining good environmental standards” (especially air quality). There are also, in some cases, issues of accessibility to roads and roadspace (e.g. for public transport and emergency vehicles) and economics (e.g. to facilitate the effective operation of commercial zones).
This section presents traffic management and control standards under the following functional areas.
It will be seen that the standards environment varies greatly among these areas. There are many “integration focussed” standards associated with architectures, and also with road network information. In many areas, though, there are few or no relevant European standards, with practices devolved either to national bodies, industry standards or simply supplier choice. However, note that there are extensive cross-links between these areas, and therefore.
21.0.2 Scope of this section
Traffic management has no unique, unambiguous definition. For the purposes of this section, it is any practice by a responsible authority which aims to have a direct influence on the nature, and behaviour of users of public roads. Within this scope, traffic control is the subset of practices which impose specific behaviours.
The politics of traffic management are not addressed by this section. Traffic management tools are impartial as to whether (for example) car use is to be encouraged or discouraged on a particular road, and the same system will often be usable in both cases – with only system configurations or operational practices changed. However, politics (local, national and European) will certainly be important in determining which systems would have the greatest effect. They may also limit which tools can be deployed; for example, local privacy concerns might rule out any camera-based system.
Non-road traffic management (for example on railways or by aircraft) is excluded from this definition. So is the management of traffic on private roads, although of course many of the techniques used for public roads may still be applicable.
Practices with an indirect effect on road traffic are excluded, although many will still have a transport and ITS component. For example, mechanisms to improve public transport services may be undertaken with a view to managing the mix of traffic on the roads, but is not covered here; for this, reference should be made to the section of this document on public transport (section 17).
Practices related to the management of roads as infrastructure (for example, carriageway maintenance) are excluded. Such activities may of course give rise to traffic management requirements, for example the task of managing traffic through roadworks.
There are some areas that are more difficult to separate out, and those with an interest in such areas should also review closely the relevant sections elsewhere in this document.
21.0.3 Overview of stakeholders/actors
The primary actors in traffic management and control are of course:
-
The “traffic authority”: the body or bodies responsible for the operation of the road network and authorised to impose measures to achieve this.
-
The “traffic unit”: an element subject to the authority’s management and controls, i.e. normally a vehicle and/or its driver.
-
Deployment and use of traffic management ITS are subject to the usual processes: service design, procurement, service operation, maintenance, etc. Associated with this is a range of stakeholders including – in addition to traffic authority roles – external advisers, vehicle manufacturers, national and European legislators, the financial sector (for tolling and charging use cases), operators of vehicle fleets, and of course the systems industry that designs, builds and maintains the ITS technology used.
21.0.4 Links to other ITS services
As noted above, traffic management and control have many interactions with other service domains. This most directly affects traffic and travel information (see section 22) and cooperative ITS (see section 9), although most other sections also have connections to traffic management, which are indicated in the relevant text below.
21.0.4.1 Links with traffic and travel information
A primary goal of traffic management is the encouragement or discouragement of road users to take specific routes, travel at specific times, or change modes. Historically, information tools have been used largely independently of traffic control, although this has changed more recently with the possibility of (for example) detecting current or potential queues and passing relevant information to “upstream” road users. This section will cover tools specifically related to mechanisms that are normally embedded in traffic management architectures (for example, variable message signs), but section 22 covers the creation and publication of specific information types.
21.0.4.2 Links with Cooperative ITS
Cooperative mechanisms allow for a targeted or even individualised interaction with specific road users, as well as providing novel channels for traditional messages. C-ITS is still a rapidly developing area and it is not yet clear where it will have its largest traffic management impact. Broadly, there are three classes of interaction:
-
C-ITS as a supplement to existing traffic management and control services – for example, in-vehicle displays indicating current speed limit or status of upcoming traffic signals.
-
C-ITS as a means of supplementary or complementary data provision, ranging from location reporting to in-vehicle cameras – supporting, for example, improved understanding of traffic flows, incident detection and even potentially enforcement situations.
-
C-ITS as a means of directing or even enforcing individual vehicle behaviour – for example, through navigation aids, GLOSA or ISA.
All of these will have a potential role in traffic management. However, the majority of challenges for such practices lie in the construction and operation of the C-ITS channel, and these are handled in section 9.
21.0.4.3 Links with other services
Other service interactions include with:
-
Electronic Fee Collection/Tolling (section 10), where these are used to limit traffic; potentially this may also be a source of traffic data.
-
Freight and Fleet (section 12), where selective management of goods vehicles is required.
-
Parking (section 16), especially in the management of access to and from car parks.
-
Public Transport (section 17), where selective management of buses and trams is required.
-
Railway traffic information (section 18), around level crossings (and indirectly in the management of associated parking facilities).
-
Road Traffic Data, Spatial Data/TN-ITS (section 19), for any issue requiring detailed infrastructure understanding.
21.1 Traffic management and control architectures
21.1.1 Purpose
The purpose of this functional area is to integrate systems and tools needed to enable effective traffic management and control.
Traffic management is a complex functional area, encompassing a range of mechanisms from regulation and infrastructure through to tactical control. The ITS tools in this application domain therefore need to:
-
align with, and support, policy choices and decisions
-
take account of fixed characteristics of the road network design and connectivity
-
take account of fixed interventions such as hard signage and road markings
A complication is that these “background” factors are not entirely fixed, but subject to change. For example, roadworks may require a policy change to introduce barriers, reduce speed limits etc., and to introduce temporary replacements for existing fixed signage/markings.
21.1.2 Actors
Different aspects of traffic management involve a wide range of actors, as described in sections 21.2 et seq. Each separate service area will have requirements for its systems to interconnect to those of other service areas, and this will be the basis for overall architecture design.
Nevertheless, the task of designing, delivering and managing an overall architecture is likely to be a focussed activity between senior traffic managers and the relevant policy and funding authorities, with or without external assistance from system architects.
21.1.3 System context
At high level, the system context for traffic management is that shown in Figure 21.0 below. The individual components of this are of various types, as described in the remainder of this section.
Figure 21.0: high level systems architecture for traffic management
21.1.4 Relevant standards
There are many standards associated with traffic management. While some of these are specific to a particular traffic management function, others are oriented specifically towards all or part of the architecture structure as a whole.
In Europe the premier framework for traffic management is the DATEX II framework. DATEX II is not primarily aimed at device control, but rather at the structuring of data relevant to traffic management – and especially at traffic information, especially for professional use (e.g. by other traffic managers or information service providers).
The principal standards within the DATEX II framework are as follows:
Complementary to DATEX II are a range of standards that address the communications and connectivity of traffic management systems. The communications layer is not special to traffic management, and the more general ITS context is presented in section 8 (communications).
However, the following are more focussed:
On the input from asset systems, the following is of particular relevance (see also section 19, Road Traffic Data, Spatial Data/TN-ITS):
The technical standards listed above are complemented by the following standards and guidance which address the more practical contexts of integrating (principally) a variety of traffic management tools:
CEN TR 17401:2020: Intelligent transport systems - Urban-ITS - Mixed vendor environment guide
Finally, the following standard addresses an important aspect of policy, specifically road safety, and the implication for traffic management systems:
ISO 39001:2012: Road traffic safety (RTS) management systems — Requirements with guidance for use
21.1.5 Legislation
There is currently no Europe-wide legislation that requires a specific approach to be adopted to traffic management system architectures. However, Directive 2010/40/EU, “on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport” (the “ITS Directive”) explicitly mandates the use of DATEX II (i.e. the EN16157 series of standards, in current and subsequent versions) for a wide range of outputs, specifically those related to traffic information.
Systems using data that may be considered personal (generally originating in the “detectors” and “connected vehicles” architectural components) will be subject to European regulation on the processing of such data, that is to say to GDPR. This may have implications for, principally, cybersecurity design and practice across the architecture.
21.2 Road user detection and identification
21.2.1 Purpose
The purpose of this functional area is to monitor who is using the road network in order to inform traffic management, control and information strategies.
Traffic management can be done passively (for instance, just using fixed signs for speed limits, turn restrictions, etc), and even ITS do not always need to be “intelligent” (for instance, traffic signals still have a useful safety function when they operate on a fixed-time basis). However, for many circumstances – particularly where traffic is heavy, varies over the course of the day, and involves a mix of different road users with different policy priorities – it is very helpful to monitor the current status of the road network, through detecting and/or identifying vehicles.
The data so obtained can give information about current and future flows, which can be compared with models of road capacity to predict potential congestion problems. Data can also indicate actual or likely congestion. This may enable changes to be made in controlling ITS (for example, traffic signal settings, speed limits, routing indications or information messages) that mitigates or relieves the problem.
21.2.2 Actors
This function is often undertaken wholly within the traffic authority.
Additional actors may include contracts who undertake detection and supply raw road usage data; external holders of repositories of vehicle data identifiers (e.g. number plate registration authorities or fleet managers); and individual road users. The figure below indicates this; the dotted lines indicate that all links are “optional”, i.e. may not always be present.
Figure 21.1: actors for road user detection and identification
21.2.3 System context
The systems environment for the detection and identification function is characterised by:
-
A wide array of potentially useful detector technologies
-
Generally, a relatively simple set of data to be captured and used: vehicle location, type and sometimes additional information (e.g. speed, occupancy)
Systems involved in this function are presented in the figure below.
Figure 21.2: actors for road user detection and identification
There are many different forms of technology that can be used for detection purposes. Inductive loops are widely used; cameras are also popular; and there are a number of radio-based technologies that can also be effective. Most of these are point-based, i.e. they detect vehicles moving past or near a specific geographical location.
Detectors are able to provide additional information, beyond the simple existence of a vehicle. Different detection technologies allow for different categories of information to be established, or in some cases estimated. Examples include vehicle type (car versus bus/HGV), individual vehicle identity (e.g. using number plate recognition), number of occupants (perhaps using IR detection), etc.
Each technology has shortcomings that may be problematic in certain circumstances. Inductive loops and magnetometers work using the properties of the metals used to construct vehicles; they struggle to detect smaller vehicles such as bicycles, and cannot detect pedestrians. On the other hand, camera systems can be politically difficult because of privacy concerns, even if they actually record minimal information.
Detection and identification become much easier where a road user is equipped with C-ITS facilities, since it can then present relevant data directly to the traffic management system. Further contextual information can also be provided that may be relevant to traffic management, for example its intended destination. For more guidance on this, see section 9 on C-ITS standards.
Systems used principally for other purposes can contribute data incidentally to assist traffic management. Examples include detectors used for tolling purposes; AVL devices on public transport vehicles used for service management; and roadside cameras used for security purposes.
Whatever the technology used, a detector will need to communicate its data to the systems involved in managing traffic. This could be local (e.g. linked only to a specific junction) or wide-area (e.g. for a centralised city system). Section 8 covers communications standards relevant to ITS.
21.2.4 Relevant standards
The range of technologies used in detectors may have their own, non-transport-specific, standards; these are not covered here. For strict ITS purposes, relevant standards focus on the content of messages passed from detector to traffic management system.
The following European standards may apply:
The DATEX II framework (EN 16157 series; see section 21.1) does not specifically address the provision of data from detectors. However, it does include data structures that enable the transfer of information relating to identified road users between management centres etc. (for example, the identity of vehicles involved in an incident).
There are currently no European standards specifically for ANPR.
The following international standards relate to the use of probe vehicle data (i.e. in a C-ITS context):
ISO 19414:2020: Intelligent transport systems — Service architecture of probe vehicle systems
ISO TS 29284:2012: Intelligent transport systems — Event-based probe vehicle data
For privacy issues in traffic management systems, see the following:
National authorities may also have specifications relevant to the detection and identification function. For example the UK’s UTMC programme [Bibliography] includes specifications for detector outputs designed for use with traffic management and control systems, including solutions using ANPR as well as detection of user devices (via WiFi/Bluetooth “sniffing”).
21.2.5 Legislation
No relevant European legislation has been identified that that requires the use of specific systems standards for road user detection and identification.
GDPR regulations impose restrictions on systems that involve personal information. National authorities typically have more specific guidance about how these should be interpreted and managed. This applies particular to camera based solutions, including ANPR where only number plate information is captured (this may still constitute personal data).
Roadside equipment is subject to European regulations on EMC. Radiocommunications is governed by spectrum licensing regulations.
National authorities have specific regulatory requirements on ITS that are deployed at the roadside, including location, physical construction, electrical behaviour, etc.
21.3 Traffic signals operation
21.3.1 Purpose
The purpose of this functional area is to manage the settings of traffic signals in order to maintain traffic flow for road users.
Traffic signals are the principal control measure available to most traffic authorities. They are set to operate at a point in the network (a junction, a pedestrian crossing, a tunnel entrance etc.) in order to either pass or stop traffic travelling along a particular route.
21.3.2 Actors
This function is usually undertaken wholly within the traffic authority.
There can be relationships with external actors (see figure below), for instance when a traffic signal operated by one authority is available to respond to the requirements of an external actor (e.g. a neighbouring traffic authority or emergency services). Also, in some cases individual vehicles (for example, buses or emergency service vehicles) can request changes to traffic signal settings. This is normally achieved by a request being sent to the owing authority, who decides whether and how to respond.
Figure 21.3: actors for traffic signal operation
21.3.3 System context
The systems environment for the traffic signals operation involves:
-
Traffic signals themselves.
-
Signal controllers: a single controller will normally be responsible only for the signals around a particular network point (e.g. a junction), but can occasionally also be set to control other nearby signals.
-
Often, supervisory software to coordinate the behaviour of multiple signal controllers (at city level, along a link etc.).
-
Input data from traffic detectors, traffic models etc.
-
Settings requests from external actors, as identified above.
Figure 21.4: systems for traffic signal operation
The traffic signals and their controllers are safety critical tools and are therefore tightly regulated, for example to ensure that different arms of a junction do not see a green signal at the same time. Signal controllers and their associated signals are therefore designed and operated as a “black box” by a single supplier (even where the components are separately sourced), and – other than where needed for regulatory compliance – standards within this “unit” are not normally applicable.
The systems approach taken by supervisory software is quite variable. Some solutions are quite localised, and may even be embedded in the signal controller; for example, products based on MOVA (“microprocessor enabled vehicle activation”) algorithms use data from local detectors to adjust signal settings in real time. Others operate at a higher level and may be hierarchical; for example solutions based on the UTMC architecture [Bibliography] may have “strategy” tools that, based on current road conditions, select:
-
Whether signal controllers are left autonomous or coordinated through an area-based system such as SCOOT
-
Whether to change the settings on information channels such as variable message signs
-
Whether to trigger incident management measures
Therefore, there are several specification frameworks that may be applicable; in addition to UTMC (principally in the UK), regional solutions include OCIT (principally Germany/Austria, [Bibliography]), DIASER (France, [Bibliography]), IVERA (Netherlands, [Bibliography]), RSMP (Sweden, [Bibliography]), and others. Outside Europe, there are other approaches again.
As this is a central function of traffic management, many architectural approaches will focus extensively on traffic signal control. The great majority of the discussion and references under section 21.1 above therefore have significant relevance to traffic signal control.
21.3.4 Relevant standards
A number of European standards have a direct impact on the design and operation of traffic signals. Among these, the following are significant (each will contain references to other specific standards as necessary):
EN 50556:2018: Road traffic signal systems
EN 12368:2015: Traffic control equipment - Signal heads
EN 12675:2017: Traffic signal controllers – functional safety requirements
EN 50293:2012: Electromagnetic Compatibility - Road Traffic Signal Systems
In specific architectures, the following European standards may also apply:
National authorities may also have specifications relevant to traffic signals operation. The following European standard provides an extensive overview of the main European regional frameworks and how their technical approaches compare:
NOTE: While this standard does not focus uniquely on traffic signal operation, this does form a substantial core of its content.
Some international standards also relate to traffic signals operation, generally with a focus on data links from centre to signals, including the following; however, these have limited support in Europe, where European or national specifications are generally more widely used.
Traffic signals operation is relevant to the following other sections, which provide additional relevant guidance for specific contexts:
-
Section 21.2, Road user detection and identification (relevant to identifying triggers for signal settings)
-
Section 21.4, Zone access control (traffic signals form a useful means of access control)
-
Section 21.6, Traffic modelling (models often need to test network behaviour under different signal settings, which requires an understanding of how the signal control system behaves)
-
Section 21.8, Road works management (often roadworks use temporary traffic signals)
-
Section 21.9, Air quality management (air quality data, increasingly, is being used to drive strategies that streamline or exclude traffic flows in local areas)
-
Section 21.11, Road network optimisation (in conjunction with traffic modelling, designing a suitable deployment and connectivity of traffic signals is a key part of good road planning)
-
Section 21.12, Special user route management (traffic signals systems and configurations can be designed to respond to specific vehicle types – freight, public transport, and emergency service vehicles are all commonly considered)
-
Section 21.13, Traffic enforcement (for violations by road users of red traffic signals)
-
Section 17 on public transport (relevant for bus priority triggering)
-
Section 9 on cooperative ITS and CCAM (relevant where road users or their vehicles provide data directly on their existence, location, speed, route, etc.).
21.3.5 Legislation
No relevant EU legislation has been identified that constrains the specific technical approach used in designing or operating traffic signals systems.
However, national authorities have specific regulatory requirements on traffic signals and signal controllers to ensure their safe operation. This may be presented as technical specifications, functional requirements, test-based type approval processes, etc.
There is less legislative burden on other aspects of traffic signals operation (e.g. supervisory software, external requests). These aspects are largely left to traffic authorities and their system suppliers to deploy, in light of local circumstances. However there are some general regulations; for example, in the UK the Traffic Management Act 2004 requires traffic authorities to facilitate “the expeditious movement of traffic on road networks for which another authority is the traffic authority”.
21.4 Zone access control
21.4.1 Purpose
The purpose of this functional area is to control the passage of traffic from one part of the network to another, or between networks, where specific conditions apply.
Traffic policy will often include a requirement to restrict or prevent certain types of road user using specific parts of the network. Such restrictions may be of a number of types; cases include the following:
-
Some roads may not be able to sustain certain types of vehicle – for example heavy goods vehicles might need to be kept away from narrow lanes or weak bridges, while bicycles might need to be kept away from very fast roads.
-
Some zones may be subject to environmental or cultural policy controls – for example, some or all motorised traffic might be restricted from heritage city areas or zones where air quality is a particular challenge.
-
Some road sections might be designated for specific vehicles only, as part of transport policy – for example “buses only” roads.
-
Some road sections might be subject to strong security controls – for example roads near sensitive buildings
-
Some roads might be subject to traffic restrictions because of modelling that indicates overall transport flow is improved by particular network geometry.
21.4.2 Actors
This function may be undertaken wholly within the traffic authority. However, there will often be external reasons that make the zone restriction appropriate, and while this may be managed through non-technical channels, there are circumstances in which a systems approach may be appropriate.
Examples of external actors that may be involved include managers of bridges, tunnels, etc; car park operators; managers of private networks, e.g. port and airport authorities; emergency services; public transport operators; and railway network operators (for example, around level crossings).
NOTE: Managers of private networks may act as the traffic authority for their own network, or may create requirements for the public network authority that their networks connect to. These are two distinct cases.
21.4.3 System context
Zone restrictions may be imposed solely using passive measures, for example fixed “no entry” signs. Where zones are subject to selective access limitations, particularly if they may vary from time to time (e.g. by time of day or when air quality becomes problematic), an ITS component may be necessary.
Simple ITS solutions include barriers that can be activated only be authorised road users. Identifying who is authorised can be done by the road authority itself (i.e. using a vehicle identification system – (see Section 21.2); alternatively, it can be done by road users being issued with specific tools to identify themselves as having access (for example a smart card, a readable tag, a temporary QR code, etc.)
Other approaches may dispense with physical barriers (perhaps because they would cause too much disruption to traffic flow – for example, at a tunnel entrance or at the boundary of a clean air zone). In this case, access will tend to be restriction by policing breaches, i.e. identifying road users who are not authorised and imposing a penalty. Again, this may be undertaken either wholly by the traffic authority (for example, by matching ANPR results against a list of authorised vehicles) or with the active involvement of the road user (i.e. containing a device or mechanism to enable it to confirm its eligibility for access).
Another type of zone access management relates to cases where certain vehicles are limited to operating within a specific zone (i.e. are not authorised to exit that zone). This approach is not currently widely used, although with the advent of “highly automated” vehicles (SAE Level 4), this may become a major use case in the near future. While this can also be managed as above, it need not involve any roadside equipment, if there is a suitable arrangement of vehicle self-reporting and geofencing. For more on this, see Section 9 on cooperative ITS and CCAM.
Some zonal systems do not restrict access by vehicles, but do impose additional constraints on those vehicles (or their owners). Examples include zones where (certain) vehicles are required to adopt lower speed limits, to change from fossil fuel to electric power, to use specific lanes, etc. The systems contexts for these are very similar to other zonal systems, although the means of identification and/or enforcement that are adopted will clearly be linked to the specific purpose of the zone.
21.4.4 Relevant standards
Few European standards directly address zone access management, but the following are useful in many circumstances:
CEN TS 17378:2019: Intelligent transport systems - Urban ITS - Air quality management in urban areas
Zone access management may use the tools presented in Section 21.2 (road user detection/ identification) and 21.3 (traffic signal operation). The following other Sections may also be relevant:
-
Section 21.8, Road works management (this may require a zone where traffic restrictions are put into place)
-
Section 21.9, Air quality management (similarly, this may involve the creation and operation of a restricted access zone)
-
Section 21.13, Traffic enforcement (where access restrictions are breached)
-
Section16 on parking (for management of access to car parks)
-
Section 12 on freight and fleet (for management of goods vehicles)
-
Section 9 on systems using C-ITS (for example, where V2I interactions are used to control access measures such as barriers)
21.4.5 Legislation
There is little legislation directly relevant to zone access management, i.e. requiring specific approaches to be taken. However, there may be legislation that restricts or controls the processes by which zone access systems can be put in place. For example, the London congestion charge scheme required primary national legislation to enable action by the Mayor, in the form of the Greater London Authority Act 1999.
However, there are several regulatory frameworks under which zone access management might be considered as a possible response measure. Particularly important is the following:
Delegated Regulation (EU) 2015/962., “Provision of EU-wide real-time traffic information services” and DR 2022/670 may also be relevant. This states that:
… road authorities and road operators shall provide the static road data they collect and update pursuant to Article 8 in a standardised format, if available, or in any other machine readable format.
“Static road status data” is defined to include, inter alia:
(c) traffic signs reflecting traffic regulations and identifying dangers, such as:
(i) access conditions for tunnels;
(ii) access conditions for bridges;
(iii) permanent access restrictions;
(iv) other traffic regulations;
…
(g) location of tolling stations;
(h) identification of tolled roads, applicable fixed road user charges and available payment methods;
National regulations, including specific designated zones, may also affect where zone access management tools are required.
21.5 Traffic speed control
21.5.1 Purpose
The purpose of this functional area is to control the speed of traffic through mandatory or advisory speed limits.
Permanent speed limits on road Sections will be determined by a number of factors, including national legislation (based on the type of road), local policy decisions (generally determined to maximise safety and/or network flow). In addition, speed limits can in some places be temporarily reduced, depending on current conditions of network congestion, weather, events, etc.
21.5.2 Actors
This function is generally the direct responsibility of the traffic authority, and wholly under its control.
Enforcement (see Section 21.13) may be a traffic authority duty or a police duty, or a combination of the two.
Minimum speed limits (including no-stopping zones) can be managed in the same way as maximum speed limits. However these usually have different policy goals and associated regulation. See also Section 16 (Parking).
21.5.3 System context
Permanent speed control is usually imposed solely using passive measures, for example fixed speed limit signs, or even notional measures, such as national speed limits which are not otherwise signed. Traffic management techniques can also be used to control speeds at a network level, for example by designing road networks with deliberate bottlenecks (see Section 21.11) or, dynamically, using traffic signal settings to disperse, relocate, or create traffic queues.
Where speed limits are dynamic (e.g. varying by time of day or in order to enable traffic queue management), an ITS component is likely to be necessary. The typical ITS solution for dynamic speed limits is the variable message sign that mimics a fixed speed limit sign, but whose image can be changed according to current management requirements.
Speed limits that apply to vehicles rather than road segments are rarely the concern of the traffic authority. The usual technologies used in this case are tachographs and vehicle speed limiters, which are wholly within the structure of the vehicle (or occasionally with real-time links to a fleet manager). In principle, a C-ITS solution would enable the traffic authority to take some measure of control, but in practice this seems unlikely to be beneficial.
For means to provide current speed information, see Section 21.10. For enforcement of traffic speed limits, see Section 21.13.
An intermediate step between information and enforcement is the vehicle-activated speed limits sign, which is now quite widespread. This uses a detection system (Section 21.2) to determine when a road user is exceeding the current local speed limit, and then activates a (usually mandatory) “reminder” speed limit VMS which is otherwise unlit.
However, the technology of “Intelligent Speed Adaptation” (ISA) is also relevant here. Under ISA, an external authority has the power to impose a speed limit directly on vehicles under its area of control; in principle this can be dynamic and need not even be informed to the vehicle user (for example, this might be appropriate for automated vehicles). ISA clearly requires both a vehicle capable of being externally speed-limited, and a C-ITS mechanism to communicate current applicable speed limits.
21.5.4 Relevant standards
There are few European standards that directly affect the ITS used for traffic speed control using ITS, other than those relating generally to the tools deployed (detectors, signage, etc). ISA is an area where standards are emerging (see Section 9 on C-ITS).
Speed control may use the tools presented in Section 21.2 (road user detection/ identification) and 21.3 (traffic signal operation). The following other Sections may also be relevant:
-
Section 21.4, Zone access control (for zones where speed limits are subject to particular management rules)
-
Section 21.7, Road incident management (limiting traffic speeds in the vicinity of an incident can help to maintain safety of the parties involved, services in attendance, and other road users)
-
Section 21.8, Road works management (rarely, dynamic speed limits might be relevant for these)
-
Section 21.9, Air quality management (for which speed limits may be a useful means to reduce emissions, as well as potentially reducing traffic demand)
-
Section 21.13, Traffic enforcement (where speed limits are breached)
-
Section 16 on parking (for speed management within a parking zone)
-
Section 12 on freight and fleet (for solutions specifically affecting goods vehicles)
-
Section 9 on systems using C-ITS (including in-vehicle displays of speed limits, violation warnings, early warnings of incidents, and ISA)
21.5.5 Legislation
Legislation on traffic speeds is largely aimed at permanent speed limits. Some legislation also exists to enable dynamic speed limits. Legislation is predominantly at a national level. At present, almost none of this legislation requires a particular systems approach to be adopted in speed control.
At a European level the Delegated Regulation (EU) 2015/962, “Provision of EU-wide real-time traffic information services” is relevant. This states that:
… road authorities and road operators shall provide the dynamic road status data they collect and update pursuant to Article 9 in DATEX II (CEN/TS 16157 and subsequently upgraded versions) format or any machine-readable format fully compatible and interoperable with DATEX II.
“Dynamic road status data” is explicitly defined to include “dynamic speed limits”.
Additionally, an important enabling regulation is Regulation (EU) 2019/2144 of the European Parliament and of the Council. This Regulation imposes a mandatory requirement for many new safety features to be installed in all new cars, vans trucks and buses sold in Europe from 2022 – including intelligent speed assistance as a variant of ISA that can be overridden by the driver. Outline functional factors are described in the Regulation but there is no specific imposition of systems architecture, standards or technology solutions.
For legislation associated with detectors, VMS, or C-ITS, see the appropriate Sections of this Section.
21.6 Traffic modelling
21.6.1 Purpose
The purpose of this functional area is to estimate the development of traffic behaviour based on available current data.
Modelling is a broad discipline and there are many approaches available for specific circumstances:
-
At the highest level there are techniques like the gravity model, which seeks to understand the long term development of transport demand between population centres based on basic demographic factors of population number (or density) and physical distance.
-
In the middle are techniques like assignment models, where a demand for origin-destination trips is mapped onto a (more or less stylised) node-and-link network graph; variants may include or exclude mode choice, time of day, travel costs, etc.
-
More granular are microsimulation tools, where individual road users are given “behaviours”, and the resulting effect on the network is observed – especially for network points where congestion repeatedly occurs, but also sometimes for other issues such as accident potential.
-
Finally there are very detailed models of individual driving behaviour, based on human factors such as tiredness, attentiveness, stress, route familiarity etc. These may be coupled with local models for junction design (angles of approach, tree growth, signal placement etc.).
Each level of modelling may learn from, or incorporate elements of, the more detailed models below it. The constraints on this clearly include processing load, but are generally based on modelling goals – i.e., what do you want to estimate? It is not necessary to model all (actual and potential) drivers individually to determine whether to invest in a highway expansion. Conversely, to improve safety around a junction, it is not necessary to consider the massed potential demand from nearby population centres.
21.6.2 Actors
Unlike other aspects of traffic management, modelling is not a “duty” of any specific actor. Rather, anyone can develop and run models, and use the results for their specific purpose. For example, sustainability campaigners may develop models specifically to demonstrate the negative consequences of traffic networks or proposed traffic developments.
Within traffic authorities, models are used for a broad range of purposes, depending on the decisions that they are intended to assist with. Strategic decisions on network development and investment are generally supported by coarser large-scale models. Tactical development (e.g. on whether to replace a junction by a roundabout) tends to use assignment and/or microsimulation models. What-if planning (for example, how to manage potential events or incidents) uses similar tools based on a scenario where network capacity or traffic demand is varied.
Operational control (i.e. the setting of signals etc. in response to current network conditions) can also benefit from modelling – if we do X, will the problems get better or worse? However, since this is a real-time activity, the pressure on model performance, available data, usable outcome and staff time makes this challenging in many circumstances.
21.6.3 System context
Most traffic modelling is “offline”: data is collected, a suitable model run (either once or many times), the model outcomes are documented, and a report prepared to capture the results of the process and thereby help decision-making.
This applies to modelling for network investment and development, for example. Potentially, live data could be drawn from traffic monitoring systems, but the challenges rarely justify any marginal benefit. Capturing a data dump is generally more than enough, and often data is gathered in entirely other ways (for example, human surveys). Systems using this approach may therefore be developed and operated in an entirely standalone fashion.
The exception is for models which integrate into operational control. For example: an accident happens at some point of the network, and the traffic authority needs to know how to adjust its traffic control and information services to minimise the impact.
If live information is fed into a model, an intervention made in the model, and the model run at faster than real time, it is possible in principle to estimate the effect of the intervention. If this is done with multiple potential interventions, an optimal solution (or at least a good solution) could be quickly arrived at. This could be automated further, with the optimal solution fed back automatically to adjust signal settings etc. This approach, however, is hugely complex and technically demanding, and it is not currently in widespread use.
The figure below describes the potential connectivity of modelling systems.
Figure 21.5: systems for operational use of models
21.6.4 Relevant standards
There are no European standards that directly affect the design and integration of traffic models. However, the following international guideline document is relevant, including to operational use cases:
Road network optimisation (Section 21.11) is the major aim of coarser, longer-term models. Models for operational use will need to relate to the tools presented in Section 21.2 (road user detection/ identification), 21.3 (traffic signal operation), and 21.10 (road network information and advice). The following other Sections may also be relevant:
-
Section 21.4, Zone access control (controlled zones need to be properly incorporated into models)
-
Section 21.8, Road works management (where road works are required, modelling can provide valuable prior insight on how best to adjust control systems)
-
Section 21.9, Air quality management (the impact on air quality may be an important output of a traffic model, and an important goal in any operational intervention)
-
Section 21.12., Special user route management (this can focus on the locations of such users, constraints on specific vehicles, etc.)
-
Section 9 on systems using C-ITS (including in-vehicle displays of speed limits, violation warnings, early warnings of incidents, and ISA)
21.6.5 Legislation
No relevant European legislation has been identified that constrains the specific technical approach used in designing or operating modelling systems.
Operational models which are closely integrated into traffic control systems may, however, require some kind of regulatory approval, especially if there is a risk perceived to the safety critical operations of the traffic control system.
21.7 Road incident management
21.7.1 Purpose
The purpose of this functional area is to detect and manage unplanned disruptions on the road network.
“Detection” may originate through a direct observation (e.g. through CCTV), an external report (e.g. by a call from a road user), or an inference from other monitoring information (e.g. exceptional and localised congestion). Since incidents can develop in unforeseen ways, similar information gathering is often necessary throughout the incident management process – noting that, once an incident is known to be underway, traffic managers (and road users) will be prompted to seek current information.
“Management” is a complex area. For some incident types (e.g. where there has been an injury or the incident status causes increased risk to others), the emergency services will be closely involved and may take a command role; in these cases, the traffic manager will need to support, response to, or obey instructions from those services. For less serious incidents, this may not be necessary.
Tools available directly to the traffic manager include :
-
Incident management systems: technologies that document descriptions of the incident, actions taken and current interventions in force. Such systems will also record, and may include interfaces with, participants involved in managing the incident.
-
Non-ITS interventions, such as temporarily closing a road with physical barriers, for example to allow repair work to be conducted on the road infrastructure.
-
Provision of information directly to current road users (for example through VMS) and to potential road users (for example through websites).
-
Provision of information indirectly to road users, through third party information service providers (for example via satnav services).
-
Provision of information to managers of fleets (for example, public transport operators or freight operators) who can then control the behaviour (route, speed, timing, etc.) of the vehicles under their management.
-
Adjustments to signal timings to relocate traffic queues, or (more effectively) to manage the new level of demand after the impact of the above tools.
21.7.2 Actors
As noted above, the actors involved in incident management depend on the nature and severity of the incident. In addition to traffic managers, they may include emergency services (police, ambulance, fire, etc.). Managers of external information services (such as routing guidance systems) and vehicle fleets (public transport, freight, etc.) may be separately addressed; in some cases this may provide them with better opportunities to respond safely and effectively than simply allowing them to use general-purpose incident information.
In the main, road users are passive consumers of the incident management function. The exception is where they (or, in a C-ITS context, their vehicles) choose to provide information about the incident to the traffic manager.
Occasionally other important actors may be directly involved in managing the incident, especially for incidents at sensitive locations: site owners (ports and airports, business parks, etc.), security services, etc.
21.7.3 System context
Where incidents are managed wholly via human interaction (for example, viewing CCTV screens and then manually adjusting settings of signs and signals), the system context is straightforward: no specific interconnectivity is required.
The figure below indicates the other case, i.e. where there is a specific system configured for incident management.
Figure 21.6: Systems for incident management
21.7.4 Relevant standards
The primary European standard relevant to incident management systems, from a traffic management perspective, is:
Also of relevance is the following European standard; while this is directly aimed at public transport operations, it has close connections to incidents as managed by the traffic manager:
The following international standards do not directly address the design of incident management systems, but are applicable to mechanisms that publish broadcast information about current incidents:
Data links to incident management systems relate to the tools presented in section 21.2 (road user detection/ identification), 21.3 (traffic signal operation), and 21.10 (road network information and advice). The following other sections may also be relevant:
-
Section 12 on freight and fleet (especially where vehicles are carrying hazardous loads)
-
Section 9 on systems using C-ITS (including in-vehicle displays of speed limits, violation warnings, early warnings of incidents, and ISA)
Some ITS products allow for complex patterns of intervention to be pre-set as “scenarios”, so that they can be activated quickly and coherently when required. There are no current standards that specify how such scenarios should be documented, created or communicated.
21.7.5 Legislation
For incident management, the principal relevant European legislation is the Delegated Regulation (EU) 2015/962, “Provision of EU-wide real-time traffic information services”. This states that:
… road authorities and road operators shall provide the dynamic road status data they collect and update pursuant to Article 9 in DATEX II (CEN/TS 16157 and subsequently upgraded versions) format or any machine-readable format fully compatible and interoperable with DATEX II.
“Dynamic road status data” is defined to include the following list of circumstances; some of these are operational rule changes, and some are purely informative, but many may be regarded as part of incident management:
(a) road closures;
(b) lane closures;
(c) bridge closures;
(d) overtaking bans on heavy goods vehicles;
(e) roadworks;
(f) accidents and incidents;
(g) dynamic speed limits;
(h) direction of travel on reversible lanes;
(i) poor road conditions;
(j) temporary traffic management measures;
(k) variable road user charges and available payment methods;
(l) availability of parking places;
(m) availability of delivery areas;
(n) cost of parking;
(o) availability of charging points for electric vehicles;
(p) weather conditions affecting road surface and visibility.
21.8 Roadworks management
21.8.1 Purpose
The purpose of this functional area is to manage traffic in the vicinity of roadworks.
In many ways, the use of ITS in support of this functional area mirrors that for incident management (section 21.7). There are three major differences:
-
Roadworks are not unplanned, but known in advance.
-
Roadworks involve the directed intervention of professional technicians on the roadway, operating under regulatory system.
-
Because of the above, roadworks may involve specialist ITS that can, in principle, integrate with the existing (“static”) traffic management systems in the area.
In fact, there is a blurred distinction between incidents and roadworks. Some incidents can lead directly to roadworks (for example, a burst water main). In these cases, the management approach adopted will need to incorporate elements of both functional areas, initially focussing on the incident (for example, response to injuries) and later transitioning to focus on the works (when the cause of disruption is stabilised and under control). Conversely, roadworks undertaken at short notice (for example, to fix an emergency electrical fault) have many of the characteristics of an incident; they need rapid response, and may even involve emergency services (for example, police ensuring that people keep their distance from the works site.
Tools available directly to the traffic manager include:
-
Works management systems: technologies that describe works locations, timing, nature, and who is in attendance. Where third parties are involved (for example, utility companies or works contractors), they are likely to be linked to these systems.
-
Non-ITS interventions, such as traffic cones and diversion signs.
-
Provision of information current road users, information service providers and fleet managers, as for incidents.
-
Deployment of portable VMS near the roadworks.
-
Deployment of portable traffic signals at the roadworks.
-
Adjustments to signal timings in the primary traffic management system.
21.8.2 Actors
The actors in roadworks management are typically:
-
The entity requiring the works. This is often a utility company but can be the traffic authority itself – either acting as a highways authority (for example, where potholes need to be filled or when road geometry is being changed), or even as a traffic authority (for example, for the installation of loops or painting of white/yellow lines.)
-
The traffic authority, which needs to adapt local traffic management to the temporarily restricted network.
-
The entity conducting the works – typically a contractor.
Completed works normally require to be certified as safe before the road is reopened. This may involve the works sponsor, the traffic authority, or both.
21.8.3 System context
From an ITS perspective the principal systems involved are the temporary VMS and temporary signals. Often, these will be operated as standalone systems under the control of the contractor, with no links to the traffic authority’s systems, although this can cause unnecessary congestion – especially where the works are close to a signalised junction.
Some suppliers of portable traffic management products are therefore beginning to build their systems with interfaces that allow such integration (for example, using the UTMC architecture and tools [Bibliography]). Under such an architecture, the traffic authority has the opportunity to temporarily insert the portable VMS and signals into its area management system. Contractors are usually content with this arrangement, but it requires close coordination for at least the following reasons:
-
The potential for including portable systems cannot be allowed to compromise the cybersecurity of the primary system. A very robust process is therefore needed to authorise the inclusion, and termination, of the temporary arrangement.
-
The portable signs and signals operate in the context of a specific physical restriction on the roadway. There needs to be good management coordination between the two, so that they begin and end operation at exactly the same time. Similarly, the static system needs to have, and to be able to use, the exact locations of the portable systems (both actual geographical points and in terms of the node-link architecture of the road network).
-
Area traffic management systems can have quite delicate balances of timing etc., and a new device or restriction suddenly inserted can cause significant unintended disruption to this balance. This is primarily a matter of design of the software algorithms.
-
Occasionally, portable devices may become faulty or be damaged, or even just moved (or stolen!). The static system must have a means to identify and react to this problem.
Changes to “static” traffic management systems (signals, VMS and other information services, etc.) tend to made manually. As with incidents, though, some ITS products allow for complex patterns of intervention to be pre-set as “scenarios”.
Works management systems are not normally considered as ITS. While they could potentially be linked into traffic management applications, such practice is not yet widespread. However, some authorities have explored the opportunity for pushing driver information form the works management system (for example, that the contractor has arrived on site and works have not begun).
21.8.4 Relevant standards
Many of the standards in section 21.7 (Incident management) are relevant for roadworks management as well. In particular, the primary European standard relevant to roadworks management systems, from a traffic management perspective, is:
For both static and portable tools, sections 21.3 (traffic signal operation), and 21.10 (road network information and advice) are relevant. Section 21.10 also addresses non-roadside information, such as broadcasts and web-based services.
National authorities may have additional relevant standards and specifications. For example, the UK makes use of the “Electronic Transmission of Notifications” specification (“EToN”, Bibliography), and XML-based protocol to be used by roadworks sponsors for advising the relevant highways authorities of necessary works.
The following other sections may also be relevant:
-
Section 9 on systems using C-ITS (in which “road works warning” is a relatively mature use case)
21.8.5 Legislation
As noted in section 21.7, Delegated Regulation (EU) 2015/962, “Provision of EU-wide real-time traffic information services” requires road authorities and road operators to provide “dynamic road status data…in DATEX II (CEN/TS 16157 and subsequently upgraded versions) format or any machine-readable format fully compatible and interoperable with DATEX II”, and this includes roadworks – and in particular road closures, lane closures and “temporary traffic management measures”.
National authorities may have additional regulation on systems to be used for the management of road works; for example the UK requires “statutory undertakers” (mainly utility companies) to hold licences for highway works, as well as codes of practice for conduct of works and some additional legal tools (such as “lane rentals”, in which the roadworks sponsor will pay the highway authority in compensation for disruption caused while works are underway).
21.9 Air quality management
21.9.1 Purpose
The purpose of this functional area is to change, as far as possible, the location and behaviour of road users in order to ensure that air quality across an area remains acceptable.
This activity includes some or all of the following aspects:
-
Monitoring the current air quality levels.
-
Modelling the likely development of air quality, given the expected developments of traffic.
-
Providing information and, where appropriate, warnings about expected air quality levels.
-
Adjusting control systems to mitigate negative outcomes, for example by relocating queues out of areas with (or expecting to have) low air quality.
-
Feedback of information and control decisions into models.
Monitoring air quality levels can be done in one of three ways. First, traffic managers have their own network of air quality monitoring stations, which provide actual data. This clearly requires the installation of roadside equipment (or, potentially, circulating vehicles with air quality equipment on board). Such data will tend to be focussed on specific points, as well as specific pollutants, and accuracy levels will depend on the nature (and cost) of the equipment.
Second, third party information may be imported as data feeds. This may be directly relevant – that is, external sources of current and expected air quality data (for example ground-level ozone predictions from meteorological services). This may or may not include some assumptions by the external provider of traffic effects, and so must be used with caution. Third parties may also provide important contextual information; for example, meteorological services can provide data on temperature inversions, wind patterns or ultraviolet insolation, industry can provide data on emissions from factory chimneys, etc. While this contextual information does not directly provide air quality information, it may help improve the quality of models.
Third, traffic managers can also estimate (traffic-based) emissions based on traffic behaviour, using their knowledge of the number, type, speed etc. of vehicles on the road. Data sources for this are those described in section 21.2, together with models of the emissions of individual vehicle types.
Air quality modelling is a broad discipline and generally regarded as outside the realms of ITS proper. However it can intersect with traffic modelling (see section 21.6) and combined tools do exist, especially where the models incorporate feedback.
Information and warnings are addressed under section 21.10. Control systems are addressed principally under sections 21.3 (traffic signal operation), 21.4 (zone access control) and 21.5 (traffic speed control).
21.9.2 Actors
In air quality management, the traffic authority may act unilaterally, in which case most of the measures will be invisible to outside actors; in this case, air quality is modelled or monitored by the traffic manager’s own systems, information provided through traffic websites and VMS, and control actions imposed through signal settings.
More often, the traffic manager may act under the direction of a separate arm of the public body which is responsible for air quality management as a whole. In this case, he/she will receive directions from – and report on results to – them, and they will normally be able to take any necessary policy or enforcement action (for example, deciding on changes to access zones).
Traffic managers may be called on to identify specific faulty or non-compliant vehicles, and take direct enforcement action (see section 21.13).
21.9.3 System context
As noted above, the system context for air quality management includes many of the tools used by traffic managers for other purposes (road user detection, traffic signal operation, zone access control, etc). However, in contexts where they are used as part of an air quality management function, these systems may need to import, use or expert additional types of data.
Exceptions are the air quality monitoring stations and air quality modelling tools. In practice, these are often combined, such that the monitoring stations communicate directly to a central tool that uses the input to compile an “air quality picture” with at least some level of modelling involved (topography, etc), and often also consuming additional external data (for meteorological predictions).
There will also be a system that consumes air quality data (current and future, actual or modelled) and uses rules to select how to change the traffic information and traffic control systems.
There are many options for how these functions can be included in a traffic management systems architecture. The diagram below is one option.
Figure 21.7: systems for air quality management
The sophistication of air quality management systems used for traffic management will vary. It is likely that a system wholly under the control of traffic managers will be relatively simple, while one that is run by a separate air quality unit will be able to include more complexity – not all of which may be relevant to the traffic manager.
21.9.4 Relevant standards
The principal directly relevant standard is provided by the following, which includes numerous additional standards references:
CEN TS 17378:2019: Intelligent transport systems - Urban ITS - Air quality management in urban areas
National authorities may have additional relevant standards and specifications. For example the UTMC architecture (Bibliography) includes specifications for data interfaces for air quality data.
In addition, there may be national standards that relate to the construction, siting, and performance of roadside air quality monitoring stations.
Other standards relevant to the architecture for managing air quality through traffic management are addressed in the following connected sections:
-
Section 21.2, Road user detection and identification (relevant to identifying current traffic loads as a modelling input)
-
Section 21.3, Traffic signals operation (since decisions on air quality may affect signal settings)
-
Section 21.4, Zone access control (many traffic management zones are so designated for issues related to air quality)
-
Section 21.6, Traffic modelling (both in terms of including air quality as a modelled parameter, and as a means of predicting the traffic response to proposed interventions)
-
Section 12 on freight and fleet (since freight vehicles are often high emitters, diverting their routes and/or streamlining their passage through “green waves” may be an important part of air quality management)
There has been some debate on the potential for cooperative ITS and CCAM (see section 9) to provide direct real-time data on their exhaust emissions. This is, however, at an early stage and raises difficult legal and practical questions.
21.9.5 Legislation
The principal EU legislation in this area is Directive 2008/50/EC, “On ambient air quality and cleaner air for Europe”. This sets limits on a wide range of pollutants; many of the regulated pollutants are common traffic emissions, including sulphur dioxide, nitrogen dioxide and oxides of nitrogen, particulate matter (PM10 and PM2.5), carbon monoxide, benzene, and ozone. (Some, like lead, are no longer a significant traffic issue; others, like arsenic or cadmium, are more aimed at industrial pollution.)
National authorities may have additional regulation. For example, the UK maintains a schedule of “national air quality objectives”, based on (but extending) EU regulations and limits. Then, if a local authority finds any places where the objectives are not likely to be achieved, it must declare an Air Quality Management Area there and develop a Local Air Quality Action Plan.
These regulatory mechanisms provide the basis for action on air quality. They do not, however, currently specify technical standards for the systems used in achieving compliant results.
Roadside equipment is subject to European regulations on EMC. Radiocommunications is governed by spectrum licensing regulations. National authorities have specific regulatory requirements on ITS that are deployed at the roadside, including location, physical construction, electrical behaviour, etc.
21.10 Road network information and advice
21.10.1 Purpose
The purpose of this functional area is to inform current and potential road users of the traffic situation, and guide them to make appropriate route and timing plans for their journey.
There are many kinds of tactical information that may be provided on the operational status and behaviour of the road network. This includes:
-
“Base data” on the road network (network topology, speed limits, one-way systems, narrow roads, steep hills etc.)
-
Points of interest
-
Charges and tolls
-
Temporary changes (roadworks, closures for events, etc.), both current and planned
-
Congestion status
-
Some processed data, such as average journey times
-
“Dynamic” control information (variable speed limits, tidal flows, etc)
-
General advice (e.g. “congestion expected this weekend because of the upcoming sport event”)
-
Background reminders (“don’t drink and drive”, “if you are tired, take a break”)
21.10.2 Actors
The traffic manager will be responsible for compiling and providing “official” traffic information and advice to road users. Some of this will be provided direct, using tools under direct control (for example, variable message signs) or closely linked (for example, municipal websites).
Some information may also be provided directly to specific categories of road user, either as a matter or routine or on request. Examples might include information to local public transport companies regarding the status of bus priority systems, or information to police services on the situation in the vicinity of an accident (current or past).
A specific case of directly-provided information is where the traffic manager makes use of CCAM facilities to provide information directly into the vehicle.
However, a lot of information for road users is created or mediated by external information service providers (satnav companies, events organisers, journey planning services, radio broadcasters, etc.). These will typically take some, but not all, of their input data from the traffic manager.
Similar tools may be used in other circumstances, for example:
-
Parking guidance systems may include the use of VMS, satnavs, and apps – this is addressed in section 16.
-
Public transport information similarly often includes dynamic real time signage (especially at bus stops, trams stops etc.) which are in effect VMS – this is addressed in section 17.
These are directly relevant because there is often a desire to make common use of information services in support of overall transport policy. For example, roadside VMS usually used for pure traffic purposes can give relevant parking or public transport information (e.g. “Park&Ride second left”, “bus time to city centre: 12 minutes”). Conversely, certain types of bus stop sign can be used to carry general traffic messages (e.g. “city centre traffic expected high this weekend”).
A full exploration of the entities and systems involved in providing traveller information – but not information to special actors such as emergency services – is provided in section 22, “Traffic and Traveller Information”. In particular, section 22 covers the functions and architectures that might be used by a third party provider. This section addresses the traffic manager’s end of the process.
21.10.3 System context
The systems involved in road network information provision are of two types, based on the interaction of the actors involved: systems used by the traffic manager to provide information directly, and systems where it is provided through a third party.
Direct-provision systems include the installation and use of VMS, as well as the use of CCAM channels for in-vehicle-information services. Indirect systems focus – from the traffic manager’s perspective – on the publication of a suitable information data feed. (In addition some information may be provided through non-ITS means, for example by radio interviews.)
Figure 21.8: systems for road network information and advice
21.10.4 Relevant standards
There are many standards relating to the provision of traffic information. For VMS the most significant standards are the following:
CEN TS 16157-4:2014: Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 4: Variable Message Sign (VMS) Publications
ISO TS 20684-10:2021 Intelligent transport systems — Roadside modules SNMP data interface — Part 10: Variable message signs
For CCAM, the following standards apply (but see also section 9).
CEN ISO TS 17425:2016: Intelligent transport systems - Cooperative systems - Data exchange specification for in-vehicle presentation of external road and traffic related data
CEN ISO TS 19321:2020: Intelligent transport systems - Cooperative ITS - Dictionary of in-vehicle information (IVI) data structure
FprCEN ISO TS 19321: Intelligent transport systems - Cooperative ITS - Dictionary of in-vehicle information (IVI) data structures
For data feeds to third parties, some of the standard cited above may be relevant; in addition, the following standards apply (but see also section 22):
CEN ISO TS 18234-4:2006: Traffic and Travel Information (TTI) - TTI via Transport Protocol Expert Group (TPEG) data-streams - Part 4: Road Traffic Message (RTM) application (ISO/TS 18234-4:2006)
FprCEN ISO TS 19321: Intelligent transport systems - Cooperative ITS - Dictionary of in-vehicle information (IVI) data structures
For specific types of information provision, other standards may be relevant, including particularly other parts of the EN 16157 (DATEX II) series – for example:
CEN TS 16157-6: Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 6: Parking publications (may be used to inform road users of the fullness of local car parks, and to help guide them towards available spaces)
CEN TS 16157-10: Intelligent transport systems - DATEX II data exchange specifications for traffic management and information - Part 10: Energy infrastructure publication (may be used to inform road users of the location of available electric vehicle charging points)
The standards relating to the protocol suite RDS-TMC (described fully in section 22, Traffic and travel information) include the following, which relates specifically to the information content of traffic messages:
EN ISO 14819-2:2013: Intelligent transport systems - Traffic and travel information messages via traffic message coding - Part 2: Event and information codes for Radio Data System - Traffic Message Channel (RDS-TMC) using ALERT-C
National authorities may have additional relevant standards and specifications. For example the UTMC architecture (Bibliography) includes specifications for data interfaces for VMS.
In addition, there may be national standards that relate to the construction, siting, and performance of roadside systems such as VMS.
Other standards relevant to the architecture for managing air quality through traffic management are addressed in the following connected sections:
-
Section 21.4, Zone access control (signage may be required to advise on the current status of the zone)
-
Section 21.10, Air quality management (a key aspect of this is informing users what current air quality levels are; information may also be used to discourage certain vehicles from particular routes/times)
-
Section 21.13, Traffic enforcement (where VMS are used to provide mandatory signage, such as illuminated signs for speed limits, lane closures, etc.)
-
Section 12 on freight and fleet (for where information, including on VMS, may be applicable only to particular classes of vehicle)
21.10.5 Legislation
The principal EU legislation in this area is Directive 2010/40/EU, “on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport” (the “ITS Directive”) and the set of Regulations emerging from it. This Directive has been amended by Decision (EU) 2017/2380 of the European Parliament and of the Council of 12 December 2017 amending Directive 2010/40/EU as regards the period for adopting delegated acts.Specifically relevant are the following:
Delegated Regulation (EU) 2015/962, “Provision of EU-wide real-time traffic information services”
These explicitly mandate the use of DATEX II, i.e. the EN16157 series of standards, in current and subsequent versions.
Also potentially of relevance is Delegated Regulation (EU) 2017/1926, “Provision of EU-wide multimodal travel information services”. This specifies the use of NeTEx (CEN/TS 16614 series) for static data, and SIRI (CEN/TS 15531 series) for real-time data. However, closely related to public transport operations (see section 17) and only affects traffic management to a limited extent.
Roadside equipment is subject to European regulations on EMC. Radiocommunications is governed by spectrum licensing regulations. National authorities have specific regulatory requirements on ITS that are deployed at the roadside, including location, physical construction, electrical behaviour, etc.
21.11 Road network optimisation
21.11.1 Purpose
The purpose of this functional area is to develop the road network in a way that maximises the goals of traffic policy.
Changes may be required in response to either demand challenges (e.g. new areas of construction or changed land use) or policy challenges (e.g. reduction in emissions, promotion of active travel).
There is a complex interaction with other aspects of transport management, for example how public transport operations are arranged locally, as well as with non-transport issues, such as economic development activities. In this mix, the traffic manager’s role is rarely to lead, and more often to support wider city programmes.
The interventions involved may include physical restructuring (e.g. road construction or road widening), changes in usage rules (e.g. freight limitations, reduced speed limits), or enforcement changes (e.g. the introduction of speed cameras). Often, interventions will need a mixture of these – for example, where a roundabout is replaced by a signalised junction with pedestrian crossings and red-light violation.
Network changes will involve three steps:
-
Understanding road use demand (patent and latent), in terms of origin-destination needs, time of day, and vehicle type.
-
Developing network architecture options, and testing how they might affect the way (actual and potential) road users choose to conduct their journeys.
-
Selecting a goal structure and putting in place a works programme to implement it, taking into account factors such as cost.
Such developments take a long time, and in most larger cities there is a permanent, evolving catalogue of developments at various stages of design and completion. This complicates the role of the traffic manager, who has to consider not only how the network is affected by each separate development, but also the way that separate works interact with each other.
For developments that relate specifically to particular classes of road use, see also section 21.12.
21.11.3 System context
Traffic management ITS are important at various stages of the network development process.
Understanding demand involves recording actual road usage patterns (cf. section 21.2 on road user detection and identification) and complementing them with other data – such as surveys – and then capturing these patterns into a traffic demand model (cf. section 21.6 on traffic modelling).
Developing options for the road infrastructure (for example, lane additions or restrictions, one-way traffic or turn bans, no-parking areas or speed limits) is fully covered in section 19 (Road Traffic Data, Spatial Data/TN-ITS). Assignment models then match the demand to each architecture option (see again section 21.6).
Selecting and implementing a goal architecture is generally a matter of political choice, contract development, etc; the traffic manager’s primary role here is often simply to ensure that suitable roadworks management activities are in place (as described in section 21.8).
21.11.4 Relevant standards
There are no current standards specifically aimed at traffic management in its role to support network development. However, as noted above, this function involves a particular application of several other activities such as road user detection, modelling, or roadworks management, which are therefore implicitly relevant.
21.11.5 Legislation
Network optimisation mechanisms are complex and there is little, if any, directly relevant legislation, beyond occasional references that state that optimising the network is a legal duty of certain traffic authorities.
Legislation may of course be relevant to the tools used in the network optimisation process (for example, during road user detection and identification, during notification of roadworks etc.). These are identified in the appropriate sections elsewhere in this document.
21.12 Special user route management
21.12.1 Purpose
The purpose of this functional area is to support the use of routes for specific groups of road users in line with the goals of traffic policy.
Section 21.11 above focusses on changes to the network and its operation as a whole, and while many stakeholders are involved in the design and modelling steps, the outcomes are changes to the general operation of the network. However, traffic policy will often identify specific groups of users for which more active and focussed steps are appropriate, either because they are the target of priority policies (to improve modal flow, accessibility, etc.), or conversely because policy requires their inhibition or containment (for emissions reduction, safety of other road users, etc.).
In addition, there are also circumstances when a more active level of route management is required for all road users. This includes cases where either the network is compromised or network loading is unusual.
The typical use cases of this function include the following:
-
Scheduled bus routes
-
Recommended freight routes
-
Preferred diversion routes
-
Priority cycling routes
-
Green waves on priority roads (e.g. radial routes at peak hour)
-
Emergency service routes and routing
In most cases, the traffic manager will be asked to determine and manage the route that the affected vehicles are on. However, in a few cases there may be wider implications. For example, to speed the access of an emergency service vehicle to its destination, it may be appropriate to choke back traffic from a wider area so that the emergency service vehicle’s route is kept as clear as possible.
Aside from the traffic manager, the other key actors involved in this function are:
-
Transport policy decision makers, who will determine what priorities exist and guide how far they need to be supported by the traffic manager
-
Relevant road user groups which are the target of the special route management (noting that in some cases this may be all road users)
It is noted that the more vehicles there are that require active prioritisation, the harder it will be to grant it to all of them – although this does depend on circumstance, for example a platoon of emergency service vehicles rushing to the same major accident may all benefit from intervention in favour of a single route.
21.12.3 System context
Services beyond those described in section 21.11 depend on a direct, often system-based, connection between specific user groups and the traffic management system. There are three broad categories for this:
-
CAV-based systems – for example, freight vehicle priority may make use of communications directly from truck on-board equipment.
-
Systems based on fleet management systems – for example, freight vehicle priority may make use of a data feed from a freight operator’s central system, which maintains separate links with its vehicles.
-
“Out of band” systems – for example, diversion information published by the traffic manager on a website could be used by a human freight manager to optimise truck routing in his own systems.
Out of band systems are relatively easy to establish (for instance they require little cybersecurity protection) but are often inefficient and unable to handle real-time optimisation.
Service requests from vehicles/fleets may be active or passive. In an active case, the vehicle/fleet must push out a “please provide service” request. In the passive case, it may do no more than register its travel information (location, direction, perhaps also speed and destination), with the traffic management system determining what action if any should be taken.
The possible actions of the traffic management system are of two kinds:
-
It may adjust current settings on traffic management tools, i.e. in fulfilment of the service request. Generally, this means adjusting traffic signal timings, although other actions are also possible (for example opening barriers, changing mandatory speed limits, etc.)
-
It may provide information back to the requesting vehicle/fleet on the current road situation, including what action, if any, has been taken in response to a specific request.
Figure 21.9: systems for special user route management
21.12.4 Relevant standards
The principal architectures for traffic management systems (see section 21.1), including DATEX, contain standardised data structures to model routes (i.e. combinations of links and nodes that constitute a valid path through the road network).
There are no standards that specify how vehicle priority may be decided or granted: this is a deep function within the traffic management algorithms, and based heavily on local policy priorities and contractual agreements.
For standards related to the management of vehicles by fleet managers, and for the creation of priority requests, see:
-
Section 17 on public transport (for routes designated for public transport)
-
Section 12 on freight and fleet (for routes designated for, or forbidden to, goods vehicles)
Other sections that are relevant to this function are
-
Section 21.3, Traffic signal operation (for the signal setting process)
-
Section 21.4, Zone access control (a request may be sent for access into a controlled zone, either to open a physical barrier or to avoid a financial penalty)
-
Section 21.8, Road works management (roadworks will frequently make use of diversions, reduce capacity, and/or reduce road speed)
-
Section 9 on systems using C-ITS (for mechanisms involving CAVs )
21.12.5 Legislation
There is no current legislation that specifically addresses how ITS are used in the establishment of special user routes. Legislation and regulation (European, national and/or local) does, however, sometimes address:
-
The circumstances under which special user routes should be arranged
-
The principles relating to their designation
-
The obligations of traffic managers when they are designated
These regulations may indirectly imply additional legislative obligations – for example, it is again appropriate to cite the ITS Directive (see section 21.10.5) which places specific obligations on the information that traffic managers must provide in the event of a diversion being put in place, including reference to specific standards.
21.13 Traffic enforcement
21.13.1 Purpose
The purpose of this functional area is to detect non-compliance of road users to traffic regulations; to identify non-compliant road users; and to impose, where necessary, appropriate penalties.
Many traffic regulations are mandatory for road users, and open in principle to enforcement. The extent to which enforcement is undertaken may vary by circumstance; local policies (and pragmatics, such as available funding) may cause this to vary over time, independent of changes to the regulations themselves.
The typical use cases of this function include the following:
-
Speeding
-
Red light running (including red light at pedestrian crossings)
-
Unauthorised entry (for instance, into a road barred to HGVs)
-
Unauthorised roadspace usage (for instance, a private car in a bus lane)
-
Wrong-way running
-
Emissions breaches
-
Unauthorised parking (including overstaying)
The sensitivity of enforcement (including potential risk both to all road users and to the road authority itself) means that traffic managers rarely have total freedom to determine how their systems and processes operate. Indeed, the function will rely heavily on the re-use of data already available to traffic managers through other traffic management functions. However, some systems may be implemented specifically for enforcement purposes.
21.13.2 Actors
Compliance with regulations is a matter for road users. By its nature, therefore, enforcement tends to require more human involvement than most other aspects of traffic management. (This could potentially ease as vehicles become more automated.)
Enforcement – and penalty imposition, where relevant – may be undertaken by the road authority itself, or by the police service, or by a third party (such as a car park operator). Often, enforcement will be a shared function between two or more of these, which complicates the systems challenges unless the interface is clearly defined.
Shared usage is sometimes a practical response; for example, the traffic authority may own and operate a network of cameras and detectors, but pass information on breaches of regulation to the police for the process of penalties. Sometimes the police service has a “second-line” role: primary enforcement is undertaken directly by the road authority, and passed to the police only on default (for instance, the accused road user denying a problem and refusing to pay a fine).
In some cases this can become complex, for example if the vehicle is leased, borrowed or stolen.
Where an erring road user is known to be a member of a managed fleet, it will generally be appropriate to contact (and penalise if appropriate) the fleet manager rather than the driver of the vehicle.
Contractors may also be involved at many stages of the process.
21.13.3 System context
At present, legal codes mean that enforcement depends substantially on some form of visual mechanisms by way of witness evidence, whether direct (as with traffic wardens) or indirect (i.e. through a still or video camera mechanism). Camera systems will need to meet the relevant local legal test for evidential robustness.
Additional ITS solutions are involved in two main areas:
-
Detector systems that recognise a potential non-compliance event and trigger either a human operator’s view or a camera record, or both. Examples include Doppler radar (for speed), vehicle classification systems (for “no-trucks” bans), and infra-red emissions signature tools.
-
Post-processing systems that assist in the process of decision-making (whether a penalizable offence has occurred, whether a penalty could/should be applied). This include image processing software, for example to estimate vehicle speed (using road markings) or to extract vehicle identification (through ANPR).
21.13.4 Relevant standards
Enforcement is a regulatory function and derives its specifications from that source. Accordingly, there are no European or international technical standards that specify how systems should (or should not) be used in the enforcement context. However, the following may be relevant, especially looking forward to a more connected road user environment:
CEN/TR 16742:2014: Intelligent transport systems - Privacy aspects in ITS standards and systems in Europe.
For standards related to the management of vehicles by fleet managers, and for the creation of priority requests, see:
-
Section 17 on public transport (for routes designated for, or forbidden to, public transport)
-
Section 12 on freight and fleet (for routes designated for, or forbidden to, goods vehicles)
-
Other sections that are relevant to this function are
-
Section 21.2, Road user detection and identification (relevant to identifying road users who may have broken regulations)
-
Section 21.3, Traffic signal operation (for circumstantial information on the phase of the signals when a vehicle passed them)
-
Section 21.4, Zone access control (for circumstantial information on the status of current access restrictions when the vehicle passed the boundary or was detected inside the zone)
-
Section 21.5, Traffic speed control (for circumstantial information on the status of current speed limits at the point and time where the vehicle was detected)
-
Section 9 on systems using C-ITS (for mechanisms involving CAVs ).
21.13.5 Legislation
Enforcement legislation is embedded in national legal codes.
The aspects of enforcement that include the need for road user identification are addressed in section 21.2 (Road user detection and identification).
Roadside equipment is subject to European regulations on EMC. Radiocommunications is governed by spectrum licensing regulations. National authorities have specific regulatory requirements on ITS that are deployed at the roadside, including location, physical construction, electrical behaviour, etc.
21.14 Applicable regulations
The following regulations are cited in this section. (21).
Directive 2010/40/EU, “on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport” (the “ITS Directive”)
This Directive has been amended by Decision (EU) 2017/2380 of the European Parliament and of the Council of 12 December 2017 amending Directive 2010/40/EU as regards the period for adopting delegated acts.
Delegated Regulation (EU) 2015/962, “Provision of EU-wide real-time traffic information services”
Delegated Regulation (EU) 2017/1926, “Provision of EU-wide multimodal travel information services”
Directive 2014/30/EU of the European Parliament and of the Council of 26 February 2014 on the harmonisation of the laws of the Member States relating to electromagnetic compatibility
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data
21.15 Bibliography
-
DVM Exchange: see http://www.dvm-exchange.nl/
-
IVERA: see https://www.ivera.nl/
-
OCIT: see https://www.ocit.org/
-
UTMC: see http://www.utmc.eu/
-
DATEX II, beyond what is published as EN16157 series: see http://www.datex2.eu/
-
RSMP: for core specification see https://github.com/rsmp-nordic/rsmp_core, for Signal Exchange Lists see https://github.com/rsmp-nordic/rsmp_sxl_traffic_lights/
-
DIASER: AFNOR – NF P99-071, Road traffic signal control by traffic lights - Standard controller dialogue specification - Diaser