ACTIF Modèle - Présentation DF9€¦ · Web viewAssistance for the design of interoperable transport in France (ACTIF) is a toolkit put in place by MEEDDM, the French ministry

Assistance for the design of interoperable transport in

France: ACTIFACTIF presentation and user guide documents

Presentation of Functional Area 3

Manage transport infrastructures and their traffic

January 2010

Centre for the study of urban planning,transport and public facilities

Documents de présentation et d'utilisation d'ACTIF - DF3

Contents1. Introduction...............................................................................................4

1.1 About this presentation document ...............................................................4

1.2 General principles behind the model............................................................4

1.3 The aim of the model – a framework for interoperability..............................5

1.4 Introduction to the functional area................................................................5

1.5 Document contents.......................................................................................6

2. Scope of the functional area "Manage transport infrastructures and their traffic"................................................................................................72.1 Objectives and services.................................................................................7

2.2 The functional scope presented in ACTIF.....................................................82.2.1 Focus on traffic control.....................................................................................82.2.2 Using traffic data ..............................................................................................92.2.3 Processing event data .......................................................................................92.2.4 Data on environmental conditions....................................................................92.2.5 Managing atypical points..................................................................................92.2.6 Managing current and scheduled work sites...................................................102.2.7 Describing the network and managing reference data....................................10

2.3 The limits of the model’s scope: interfaces with the outside world..............102.3.1 Public Ttransport authorities...........................................................................112.3.2 Law enforcement authorities...........................................................................112.3.3 Network operators ..........................................................................................112.3.4 Service providers............................................................................................112.3.5 Atmospheric conditions systems.....................................................................122.3.6 Intervention teams...........................................................................................122.3.7 Users...............................................................................................................122.3.8 Field equipment and data collection...............................................................122.3.9 Field camera equipment..................................................................................122.3.10 Environmental conditions field equipment...................................................132.3.11 Information or control equipment.................................................................13

2.4 Interfaces with the other functional areas of ACTIF....................................142.4.1 Provide electronic payment facilities (FA1)...................................................142.4.2 Manage safety and emergency services (FA2)...............................................142.4.3 Manage public transport operations (FA4).....................................................142.4.4 Provide advanced driver assistance systems...................................................142.4.5 Manage and inform on multimodal transportation (FA6) ..............................152.4.6 Enforce regulations (FA7)..............................................................................152.4.7 Manage freight and fleet operations (FA8).....................................................152.4.8 Manage shared data (FA9)..............................................................................15

2 Certu - 2009

ACTIF presentation and user guide documents – FA3

3. The functional model..............................................................................173.1 Functional breakdown.................................................................................17

3.2 Datastores...................................................................................................19

3.3 Functions.....................................................................................................223.3.1 Functional sub-area: Produce traffic data.......................................................223.3.2 Functional sub-area: Manage events...............................................................243.3.3 Functional sub-area: Regulate traffic..............................................................253.3.4 Functional sub-area: Provide environmental information.............................273.3.5 Functional sub-area: Manage upkeep and maintenance of transport infrastructures .........................................................................................................283.3.6 Functional sub-area: Manage a network's particular structures and atypical points..................................................................................................................................303.3.7 Functional sub-area: Manage FA3 shared data...............................................31

3.4 Data-flow diagrams......................................................................................31

4. Standards and legal requirements.........................................................374.1 Geographical repository..............................................................................38

4.2 RDS-TMC....................................................................................................38

4.3 DATEX.........................................................................................................38

4.4 DSRC...........................................................................................................38

4.5 LCR..............................................................................................................38

4.6 MI2/SIREDO................................................................................................38

4.7 TPEG...........................................................................................................39

4.8 TRIDENT.....................................................................................................39

Certu – 2009 3


1. Introduction

1.1 About this presentation document

Assistance for the design of interoperable transport in France (ACTIF) is a toolkit put in place by MEEDDM, the French ministry for sustainable development, designed to help transport system designers and project managers to make them interoperable, i.e. capable of exchanging information, collaborating and sharing technical solutions. The system is based on:

a method for implementing interoperable transport systems, described in a methodological guide;

a model which provides a representation of transport professions and the interfaces between them;

a set of tools for accessing and using the knowledge described in the model.

This document is part of a set of similar documents, which are designed to present the entire model in an instructive way and which set out the general principles under which the model can be adopted by ACTIF users. Its aim is to present Functional Area 3: Manage transport infrastructures and their traffic.

In order to understand the logic behind the ACTIF model as a whole and the principles that have been adopted to make it more intuitive, comprehensible and user-friendly, please refer to the framework document, which provides details of the entire ACTIF model (including the thinking behind its development and the modelling rules used). The other functional areas of ACTIF are each dealt with in a specific presentation document.

These documents are available for public viewing and download on the following website: http://www.its-actif.org.

1.2 General principles behind the model

The ACTIF model provides a representation of transport professions, viewed from the perspective of information systems. The activities that it describes are based around functions designed to collect, store, process and disseminate data of increasing complexity.

The basic data comes either from other professions represented within ACTIF, or from external third parties, known as "terminators". In the same way, the information generated by the processing function is disseminated to other professions or to terminators. The word "terminator" refers to entities, individuals or systems for which the internal logic is not represented within ACTIF: field equipment, partner structures and organisations, drivers and users, etc.

For example, infrastructure managers (whose role is described within ACTIF) receive event alerts from field equipment (cameras, loops, etc.), which they then process before disseminating their analysis to the people in charge of implementing a field event management strategy. If traffic control measures are needed, they communicate the relevant information to the infrastructure's users via variable message signs (VMSs) or other types of media (e.g. radio stations). The cameras, loops, VMSs, radio stations and users are all classed as terminators.

4 Certu – 2009

http://www.its-actif.org/


Information may also be sent to the relevant public transport operator, which will take the necessary control measures (possible service modifications). These control measures will be communicated to the vehicle (driver) and/or to passengers and other users.

The functional chains described in the model are logical chains of information collection, storage, processing and dissemination functions, which send information to other collection functions, storage functions, etc. These logical chains must not be considered solely from the viewpoint of the technical and ICT systems required to achieve them. They must be seen rather as functions that are part of a wider transport service arrangement, which includes automation or human intervention (with NICTs then used to assist decision-making).

This may involve closed processes, i.e. which originate from and end with a terminator. It may also involve internally cyclical processes, either as part of cooperation between partners, or where there are plans to assess the processes and strategies implemented.

1.3 The aim of the model – a framework for interoperability

The aim of the model is therefore to represent not only the internal logic of the different transport professions, but also the information flows that may exist between different structures, organisations and systems in the context of a cooperation, collaboration or pooling of resources. Each of the different data functions, datastores and information flows has been linked with the relevant applicable standards and regulations in the various transport professions. The model proposes a generic description of the content and form of each of these objects.

In addition to the proposal for a repository for the transport professions, the aim of this kind of model is for it to be used in the description of existing or planned systems. In order to describe its organisation, operation and interfaces with partners and the outside world, the content of messages and databases and the technical implementation of functions must be specified. The use of knowledge that is already organised means time savings can be made by starting from definitions already contained in the model.

1.4 Introduction to the functional area

In order to make the representation easier to understand and use, the transport professions covered by ACTIF are grouped into functional areas, each of which corresponds to structures, organisations or services found in the real world. The ACTIF model contains nine functional areas. They are segmented and numbered in accordance with the equivalent European framework (FRAME):

FA1: Provide electronic payment facilities;

FA2: Manage safety and emergency services;

FA3: Manage transport infrastructures and their traffic;

FA4: Manage public transport operations;

FA5: Provide advanced driver assistance systems;

FA6: Manage and inform on multimodal transportation;

FA7: Enforce regulations;

FA8: Manage freight and fleet operations;

FA9: Manage shared data.

Each functional area has its own professions and functional sub-areas. The aim of this document is to show the logic used in the representation proposed for FA3: Manage

Certu – 2009 5


transport infrastructures and their traffic in the model, and the way in which this working basis and reference can be used in practice.

1.5 Document contents

This document is arranged as follows: presentation of the functional scope:

− objectives and services, functional scope;− interfaces with the outside world and other functional areas within ACTIF;

presentation of the functional segmentation:− functional breakdown, datastores and functions;− data-flow diagram;

associated standards and regulations.

6 Certu – 2009


2. Scope of the functional area "Manage transport infrastructures and their traffic"

2.1 Objectives and services

The ACTIF model is derived from the older European KAREN model, and then the FRAME model, which had (and still has) the specificity of being very much geared towards road transport. The corresponding functional area (Functional Area 3) still deals with traffic management, and comprises two separate activities: managing urban traffic and managing interurban traffic.However, the issues at stake with regard to multimodality very quickly led the team in charge of the ACTIF model to consider the possibility of using the model for non-road-based transport infrastructures. Two parallel activities were undertaken: The first involved describing the infrastructure management activities that are present in

other transport modes. The second involved checking that, regardless of the contributions or modifications

provided by the first activity, the ACTIF model would always respond or correspond to the expectations of road-based transport. In this respect, the level of coherence between the SDIR (Schéma Directeur de l'Information Routière – Road Information Master Plan) and SDER (Schéma Directeur de l'Exploitation Routière – Road Operation Master Plan) approaches was tested, together with the ACTIF model.

Overall, initial observations revealed significant similarities in the logic used to describe professions with links to transport infrastructure management. The key phases are: describing the network proper(ly?) (in order that reference points on the network and

atypical points can be described, so that, subsequently, any point on the network can be designated in a one-to-one, unambiguous fashion);

defining operating policy and strategies, which in turn should generally make it possible to define – in addition to service levels – the resources to be implemented in order to monitor the development of the service and all actions to be implemented to achieve the desired service level;

ensuring the upkeep and maintenance of the network, which means scheduling and managing works, as well as operations associated with each work site;

ensuring real-time operation, including information feedback on traffic conditions and events, and putting in place operating strategies;

managing the resources allocated to upkeep and maintenance.

Although the approaches are similar, there are also some notable differences: In the way in which traffic is controlled or in which the network’s atypical points are

managed. In particular, whereas road traffic management is essentially a matter of managing flows that must be oriented using information and incitements (journey times, recommendations, warning messages) and possibly regulations (limits, restrictions or rules concerning access, speed, overtaking, etc.), in most other cases, traffic management is individualised and brings with it the possibility of direct links between the management centre and the vehicle (air traffic, sea traffic, river traffic, rail traffic, etc.).

In the definition of infrastructures' atypical points, their management, and the impacts on traffic control and the operation of routes upstream and downstream. Managing a tunnel or a bridge as part of operating a road infrastructure is not the same as operating a port or

Certu – 2009 7


airport for sea or air routes: in the first case, vehicles are delayed or diverted via parallel routes (if a meshed network exists); in the second case, the means of transport are cancelled, delayed or diverted.

The problem for the designers of the model was knowing whether, in a representation of information systems, the logical chains of information collection, processing and dissemination functions may be represented independently of transport modes. In practice, the two cases presented show that: The traffic manager must be able to envisage direct relations with the vehicle or its

driver/pilot/captain, or possibly with a third party, who will send back orders or instructions. This is also a case which could ultimately be envisaged for road traffic management, even if we know that the nature of messages ("time of arrival required"), for example, will not be the same. In this respect, considering the possibility of an information flow is coherent with the intentions of the ACTIF model.

Atypical points such as tunnels or bridges are "inserted" linearly with regard to the transport infrastructure, whereas ports and airports (and certain stations) are points of origin or termini. These atypical points are not necessarily managed by the same bodies that manage the routes that serve them; indeed, this is often the case. All atypical points may be subject to specific operating rules that are different from the rules for the routes taken by the means of transport concerned (because of safety, weather, accidents, etc.). These rules may, where necessary, lead to the closure of an atypical point, have impacts on traffic, usually upstream, but sometimes downstream too: in this case, means of transport must be diverted onto other networks and/or other atypical points. Interconnections must then be envisaged with the services in charge of managing routes (air, sea and river routes, railways, roads), the services in charge of managing fleets, and, where necessary, with the means of transport themselves, either directly or via field equipment. The representation of these potential, theoretical flows in a profession-based model can be envisaged for all modes of transport.

The stand taken in the ACTIF model has therefore been to propose all imaginable information flows so that they are represented either in the context of an operational logic for a single structure or organisation that sends back the necessary information for an integrated "network + atypical point" management, or in the context of different structures that must interact and interoperate. ACTIF applications (together with the associated OSCAR tool) have enabled both possible cases to be tested.

2.2 The functional scope presented in ACTIF

Because of the history of the ACTIF model, the first versions of which resulted from European framework architectures (KAREN, followed by FRAME), the representation proposed in Functional Area 3, "Manage transport infrastructures and their traffic", has not followed the profession-based structure described above to the letter.

2.2.1 Focus on traffic controlFirst of all, European architectures today are still very much focused on road traffic management. The representation proposed in the ACTIF model will therefore be centred on the traffic control profession. However, this representation no longer takes into consideration the separation between urban and interurban traffic: on the one hand, there is no need to make this distinctions, as the professions, field equipment are essentially the same and the data comparable; on the other hand, a set of "reflexive flows" (see the model presentation document) makes it possible to

8 Certu – 2009


take account of information exchanges between the different managers or operators that may be required to work together (these reflexive flows are absent in FRAME); finally, the model is intended to be used for any mode of transport, and therefore any network.The corresponding functional sub-area of ACTIF takes account of the following at the same time: real-time monitoring of the situation, and therefore the analysis of measures

implemented in the context of current management strategies; the definition (or redefinition) of these strategies at the request of local transport

authorities, calling upon terminators via interfaces, and the deferred analysis of field returns.

This sub-area takes into account many interfaces with other functional areas and partners who could participate in traffic control measures. In particular, this may be other infrastructure management services. The activation of traffic management strategies is triggered by traffic data, planned or unplanned events or environmental data, the processing of which is an integral part of the infrastructure management profession.

2.2.2 Using traffic data In view of the substantial initial bias towards road-based input, the ACTIF model has isolated a sub-area dedicated to the feedback of traffic information. This basic data comes from sensors within the infrastructure, together with other equipment in parallel (toll barriers, car park entrances/exits, etc.). This data supplies the processing functions that produce count data (with a view to deferred or real-time analysis), traffic forecasts and journey times; or, where necessary, which put event detection functions on alert. In particular, this is the case for video data, which was isolated in this sub-area. Note: in the context of individual traffic management, the detection of means of transport by field equipment may been seen as either a specific event (if abnormal) or a basic stimulus for traffic control.

2.2.3 Processing event data Event information may come from different sources (vehicles, partner bodies, field equipment, etc.). These events may be unplanned (accidental) or planned (demonstrations or other organised events). They lead to an analysis of the situation, which is passed on to the traffic control or work-site management functions, if managed by the same operator. The possibility of reflex management is provided for, with the option of activating immediate (alert) information on field equipment. This analysis may be passed on to another partner where management is coordinated between operators, or even multimodal.

2.2.4 Data on environmental conditionsFollowing requests from the structures in charge of road traffic, and in the spirit of the SDIR and SDER, the processing of data relating to weather and environmental conditions is the subject of a specific sub-area. This sub-area may be activated for all transport modes (e.g. dedicated meteorological services at ports and airports).This specific event information may also concern meteorological or atmospheric pollution data, which will be processed as appropriate to the infrastructure (and its manager): special traffic control for routes or atypical points, alerts concerning maintenance work, etc.

2.2.5 Managing atypical points.As indicated above, a specific functional sub-area has been created, initially to isolate those aspects of management that are specific to tunnels and other engineering structures within

Certu – 2009 9


road infrastructures. This sub-area was subsequently extended during work on Version 5 of ACTIF, which takes into account all atypical points that may require specific management that is detached from the rest of the transport route. When applying ACTIF in order to model a traffic management system, it is not necessary to use this sub-area if there is no special management for existing structures (bridges, tunnels, etc.). However, if the closure of a tunnel, bridge or airport (due to an accident or bad weather) results in a chain of measures which affect all traffic and require the implementation of synergies between infrastructure networks, the modelling must isolate this atypical point. Interfaces have been created in order to take account of the synergies to be implemented.

2.2.6 Managing current and scheduled work sitesThe ACTIF model takes into account the scheduling of upkeep and maintenance work sites, which may be: - either planned in the medium term: in this case, information can be relayed to users in advance;- or planned in the short term, e.g. following information concerning bad weather or accidents.In ACTIF, the idea is therefore to be able to provide coherent information to users of the infrastructure (and their users or customers, if different) by means of traffic control measures.

2.2.7 Describing the network and managing reference dataBecause of the history of the ACTIF model, the decision was taken to deal with the operation of existing infrastructures only. This means that the creation of new infrastructures is not dealt with in Functional Area 3 of ACTIF. This is why the description of the network, available transport services and service levels is absent from these professions. It was not reintroduced in Version 5 of the ACTIF model. More specifically: The databases that make it possible to describe points on the network and manage the

road repository are dealt with in the same way as other functional areas of ACTIF, i.e. via Functional Area 9, "Manage shared data". Updates are taken into account through modifications to the repository (information flows between FA9 and FA3). Users (e.g. archives users, information service providers) can then update cartographic data or online offers;

Furthermore, the notions of service levels and offer descriptions are underpinned by the option of implementing new operating strategies (see above). For example, in Version 5 of the model, we did not envisage confining strategy definition and the monitoring of strategies in progress in two different functional sub-areas.

In the case of a specific need or request, these developments will be able to be integrated in the long term.

2.3 The limits of the model’s scope: interfaces with the outside world

Functional Area 3, "Manage transport infrastructures and their traffic", could potentially be required to exchange information with other services, structures and people that, in turn, will become sources or targets of information.Some of these emitters or recipients of information are described in the ACTIF model in other functional areas. In particular, this concerns areas and activities relating to emergency management or public transport operations, which will emit or receive data regarding events

10 Certu – 2009


(accidents) and current management strategies (which will affect the operation of transport lines).Other services are not described functionally in ACTIF: these are "terminators", which include field equipment, together with partner structures such as atmospheric conditions systems (in France: Météo France), external service providers (radio stations) and people such as users of services, drivers or intervention teams. These terminators are described as being "external": they do not participate directly in the system, and are not responsible for any functions (in whole or part). these persons would be "internal actors", and as such not modelled in ACTIF apart from in terms of their functions – for example, control operators. In order to indicate the limits of the functional scope, references to certain internal actors may be put in italics in certain cases.

2.3.1 Transport authoritiesIn ACTIF, links are envisaged between public transport authorities and most functional areas. The interfaces with FA3 concern:- upstream: traffic and transport policy, in order to structure the service and define operating strategies; - downstream, in order to receive measured or forecast traffic data: information on current strategies and any requests for action or for traffic information to be taken into account.

2.3.2 Law enforcement authoritiesThe information exchange considered in the model takes account of regulations that are applicable and to be implemented on work sites, and which infrastructure operators must be informed of by the law enforcement authorities. However, information on infrastructure usage rules to be followed is transmitted in Functional Area 7, "Law enforcement ".

2.3.3 Network operators Although described in Functional Areas 3 and 4, network operators have also been described in ACTIF as terminators: it seemed helpful, when using OSCAR, to be able to distinguish between operators who are direct partners of action implemented (who will be described functionally) and operators with whom links are looser and involve exchanging only reference data or basic data via FA9 and providing information about general operating policies. This is, for example, the case for CRICRs (Centres Régionaux d'Information et de Coordination Routières – Regional Road Information and Coordination Centres) with regard to local operators.The following exchanges may then be expected: requests for traffic information to be taken into account (in order to relay them), and traffic operation policy.

2.3.4 Service providersThis includes, for example, information services liable to provide or pass on information about a population or an extended territory with regard to local services, e.g. radio stations or disseminators of information to subscribers. Information exchanges taken into account are therefore events, real-time traffic data (traffic jam or slow traffic alerts), forecast traffic data ("green", "orange", "red" and "black" days designated by Bison Futé in France, journey time estimates, etc.) and travel recommendations produced. In return, these services may communicate specific information concerning structures or atypical points, or regarding planned events, to infrastructure operators.

Certu – 2009 11


2.3.5 Atmospheric conditions systemsIn ACTIF, these systems are essentially emitters of information on atmospheric conditions (meteorological or environmental). This information may be:- Analysed directly by the sub-areas in charge of traffic control, managing structures and atypical points, managing specific events (rain, wind, snow, etc.) or the upkeep of infrastructures (weather warnings). This therefore involves data that can be used directly by the system.- Filtered by the functional sub-area in charge of providing information on environmental conditions, if this data cannot be used directly in infrastructure management decisions. These systems are, for the most part, partner structures and organisations, such as Météo France, which must be distinguished from sensors installed by the operators themselves. This link is essentially used when modelling a real system in order to consider whether it would be better to set up a system of sensors belonging to the operator (see Atmospheric conditions field equipment) or to receive information from an external provider. The requirements in terms of reliability and responsibility for information are therefore not the same: they are formalised by a contract. For purposes of simplification, ACTIF has not described the contractual links that may exist between infrastructure operators and these structures. They must be considered separately from the model.

2.3.6 Intervention teamsIntervention trams receive intervention requests accompanied by a set of information to be taken into account. In return, they communicate information on their location, status and activity, and provide regular reports of upkeep and maintenance actions implemented.

2.3.7 UsersIn Functional Area 3 of the ACTIF model, infrastructure users are essentially emitters of information: they communicate data on events ("event declarations") directly using the means of communication they have available, or which are made available to them on the roadside.Users are never considered as direct recipients of information: the information they receive as passengers or drivers is passed on to them via field information or control equipment (variable message signs, traffic signals, barriers, etc.). This case is considered in Functional Areas 4 and 6, in their sections on passenger information, and in Functional Area 8, where it is possible to issue instructions directly to drivers/pilots/captains.

2.3.8 Field equipment and data collectionThis equipment comprises sensors installed on the ground to provide the operator's information system with raw data relating to vehicle counts (e.g. "vehicle flow", "car park occupancy", "service area occupancy"), the state of the infrastructure (e.g. "state of surface covering"), or the state of specific equipment for atypical points. This data will be used to produce traffic data, provide information about safety conditions around atypical points and schedule maintenance work. Because of the way the model is constructed, this equipment does not receive any information from the system. Neither does it send back any information on their state of operation: the quality of the data communicated and its consistency or otherwise with other data received from elsewhere is sufficient to identify faulty equipment.

2.3.9 Field camera equipmentIn the ACTIF model, camera equipment was distinguished from other data collection equipment, as it enables feedback in the form of real-time views of traffic conditions on the

12 Certu – 2009


infrastructure in question. It will be possible to use this data directly to classify events and implement control strategies. Furthermore, through concordance with the SDER, and following requests from road operators, this equipment can provide data to a video datastore which may be shared between several operators in the context of a coordinated operation of transport infrastructures.

2.3.10 Environmental conditions field equipmentThis equipment, which is managed, and often set up, by the infrastructure operator itself, consists of sensors installed on the ground. Their role is to take measurements of atmospheric pressure, temperature, precipitation or air composition and send back this data to the operator's information system. Several targets may be envisaged, depending on whether it is possible to interpret the results directly in terms of infrastructure management measures.

2.3.11 Information or control equipmentThis equipment consists of favoured interfaces between the infrastructure manager and users. They enable the dissemination of the following on the ground:- simple information, such as instructions (concerning speed, safety, etc.), suggestions (recommended routes, etc.), or information on traffic conditions via variable message signs or other signalling equipment;- specific commands to temporarily prohibit, restrict or control access to a route, by means of barriers, lights or other signalling equipment.This equipment receives commands and sends back feedback on their operational status.

Certu – 2009 13


2.4 Interfaces with the other functional areas of ACTIF

Functional Area 3 interacts with other functional areas described in the ACTIF model. The links considered here are not necessary exhaustive. They are capable of covering cases and needs already encountered with regard to applications.

2.4.1 Provide electronic payment facilities (FA1)Links with electronic ticketing or toll systems described in FA1 concern: - as output from FA3, recommendations specific to traffic control strategies, such as fare modifications including free travel;- as input, feedback on flows at toll plazas, enabling the production of traffic information.

2.4.2 Manage safety and emergency services (FA2)With the emergency services modelled in FA2, the exchanges considered in the ACTIF model take account of:- as output from FA3, alerts on structures and atypical points, and incident/accident notifications (as the operator is often the first to be informed), as well as operational measures implemented for a specific intervention (ensuring routes are safe, facilitating contraflow access for emergency vehicles, etc.); FA3 also produces travel recommendations;- as input, infrastructure operators may be informed by emergency services of incidents/accidents and requests for local priority.

2.4.3 Manage public transport operations (FA4)The links considered in the model between the public transport operators represented in FA4 and infrastructure operators concern: as output from FA3, forecast traffic data and expected journey times, as well as

recommendations for modifications to services in the event of a specific service modification procedure being implemented;

as input, public transport operators send requests for priority at traffic lights (which may be processed in real time by sending messages to information and control equipment or as part of a more general traffic control strategy), and provide information concerning planned events (special services) or accidental events.

2.4.4 Provide advanced driver assistance systemsIn the profession-based model, on-board systems in vehicles are not considered to be emitters of information ("disseminated vehicle data"). This data makes it possible to produce traffic data or provide information on environmental conditions. Messages from infrastructure operators to vehicles' on-board equipment are displayed:- either by means of field information and control equipment (and possibly regulatory enforcement equipment): this equipment may pass on information or give instructions (or even orders) issued by infrastructure operators;- or through Functional Area 8, which allows for vehicle management across the infrastructure.The development of remote vehicle control by the infrastructure could lead to this type of relation between infrastructure operators and vehicles being taken into consideration in future versions of the model.

2.4.5 Manage and inform on multimodal transportation (FA6)

14 Certu – 2009


In previous versions of the model, FA3 contained a sub-area dedicated to multimodal transport management. During work on Version 5, it seemed more coherent to transfer this sub-area in FA6: in order to be able to disseminate accurate and useful information to users (who are travelling or preparing their journey), it is necessary to be aware of the full transport offer that is theoretically available, as well as traffic conditions, so as to provide users with real-time advice. This advice must be coherent with measures (Plans de Gestion de Déplacements – Transport Management Plans) implemented. Therefore, FA6 now covers aspects relating to multimodal transport management. Consequently, the interfaces between the two functional areas are as follows:- as output from FA3, traffic data (forecast or observed) and journey times, information on events and traffic conditions (including video data where applicable), current traffic management strategies, data on current or planned work sites, travel advice produced, as well as data on the available capacity of car parks and service areas;- as input, FA6 sends data on overall transport conditions, and recommendations for modifications to traffic management strategies.

2.4.6 Enforce regulations (FA7)The links envisaged in the model concern only the emission of new contextual thresholds to be applied on the ground. These thresholds result from measures implemented on the ground as part of traffic management strategies: for example, they concern speed or access restrictions implemented because of poor weather or pollution conditions. These processes are not necessarily automated. The fact that they are taken into consideration in ACTIF reflects, above all, the existence of relations between infrastructure operators and authorities responsible for enforcing regulations.

2.4.7 Manage freight and fleet operations (FA8)FA8, "Manage freight and fleet operations", is the most extensive functional area of the model. It makes it possible to organise and follow the movements of merchandise by monitoring transport sequences, handling at intermodal platforms and storage in warehouses or at platforms. Aside from this monitoring information, it is the contractual context that is often used in this area to describe the relations between the different intervention levels. FA8 also includes a particular sub-area that allows the monitoring of goods transport on a dedicated infrastructure.Relations between FA3 and FA8 are therefore very important:- output data from FA3 concerns travel advice, recommendations for modifications to services, specific recommendations in the context of special travel conditions (e.g. lane closures for wide loads- il ne s’agit pas de fermeture de voies, mais de mesures pour les convois exceptionnels accompagnement par la police par exemple, signalisation particulière, emprunt de voies spécifiques), event information and requests for actions or traffic information sent directly to fleet managers to be taken into account;- as input, FA8 may, if necessary, send: requests for routes or infrastructure reservations; specific operational decisions to be implemented vis-à-vis abnormal loads; alerts regarding hazardous transport; and transport documents or monitoring information.

2.4.8 Manage shared data (FA9)Functional Area 9 fulfils two specific functions:- managing reference data;- managing and sharing historised data.The existing flows between the two functional areas are as follows: - as output from FA3, subscription requests and data to be historised;

Certu – 2009 15


- as input, notifications of reference data to be used, and the status reports and analyses requested.Historised data includes all data that can be stored for later use (i.e. deferred access). In the ACTIF model, this data may come from any of the datastores. This concerns traffic data, events, work sites, strategies described, and strategies implemented on the ground (which will supply the log books retrieved after the event to analyse a given strategy). Links between each of the datastores and Functional Area 9 are described in the sub-area "Manage FA3 shared data": here, the flow concerns data to be historised.This part gives feedback relating to status reports and analyses, which may concern the operator itself just as much as other partners, hence the need to manage subscription requests. The reference data corresponds to the ways of describing information in order to make it comprehensible and usable by the people receiving it. Generally, these are frameworks associated with a vocabulary and syntax that ensure that transport infrastructures, events and traffic conditions are described in a consistent and unambiguous way. In the ACTIF model, in addition to these frameworks, transport infrastructures are considered as items of reference data in themselves (like the theoretical public transport offer). These repositories may be different for different partners: on a given route, the geolocation of points may be defined in terms of geographical coordinates (X, Y and possibly Z), or curvilinear abscissae (PR “mileposts”, distances with respect to fixed points on a bus route plan). However, it must be possible for the data exchanged to be understood without ambiguity by the people who receive it, and who will have to use it. This is why it is necessary to have a "translator" available to enable transfers from one repository to another – or, in any case, to propose the correct meaning in the correct reference database. It is the links with Functional Area 9, "Manage shared data", which allow this. If necessary, FA9 warns, manages and issues requests for new reference data to be taken into consideration. In terms of transport infrastructure, this will include integrating new routes, for example.

16 Certu – 2009


3. The functional model

3.1 Functional breakdown

In accordance with the principle described in Chapter 2 (on the functional scope), the functional sub-areas taken into consideration in the model are as follows.3.1 Produce traffic data

This aggregated function shall handle the collecting of "raw" data relating to traffic (counting data, video feed, etc.) and process this raw data into aggregated data and/or calculating complex data (detecting anomalies by analysing video feed, calculating travel times, etc). It shall also disseminate raw and calculated data to other system functions.

3.2 Manage events This aggregate function provides means of managing events that occur on the network that are either planned (maintenance work, demonstrations, etc.) or due to a certain number of unforeseen causes (poor weather, accidents, etc.). It enables these events to be detected through internal functionalities or via other functional areas. In return, this function may involve other functional areas in event management, e.g. by issuing recommendations for service modifications, or intervention requests.

3.3 Regulate traffic This aggregate function is responsible for traffic supervision and control resources. Traffic data is continuously analysed; if an event occurs, a traffic management strategy is implemented. Various key parties will have defined these different strategies beforehand. A strategy involves the coordinated implementation of a set of measures; a measure can also be broken down, into several fundamental actions. A measure may consist of, for example, informing a partner, activating field equipment, or sending an intervention team to a given point on the network. This aggregate function also provides a continuous improvement loop mechanism: one of its functions is responsible for analysing the results obtained following the activation of a strategy. This analysis may lead to proposals for improvements to strategies.

3.4 Provide environmental information

This aggregate function provides means enabling the collection and archiving of data on changes in atmospheric conditions (noise, pollution, etc.) in the vicinity of a given transport infrastructure or for a group of infrastructures. This data is used to forecast atmospheric pollution levels or issue weather alerts, with the aim of planning the necessary maintenance work and implementing infrastructure operation strategies or transport management strategies on a larger scale. Both archived data and forecast data are then sent to other parts of FA3, and to other functional areas within the system.

3.5 Manage upkeep and maintenance of transport infrastructures

This aggregate function manages all information necessary for maintaining transport infrastructure, maintaining the equipment necessary for the proper operation of this infrastructure, and scheduling work and occasional interventions with the aim of maintaining quality and continuity of service (e.g. winter serviceability for roads and rivers, safety, information and data collection

Certu – 2009 17


equipment). The function schedules maintenance work according to the upkeep or repair work that has been identified as necessary in the short or long term. When the scheduled date for work arrives, a function checks that the various conditions for carrying out the work are fulfilled (e.g. maintaining a minimum distance between two work sites on one section of road) and, if this is the case, launches the work site. This involves sending a maintenance team to the site concerned.

3.6 Manage a network’s particular structures and atypical points

This aggregate function contains the features required to manage a transport network's atypical points. This mainly concerns infrastructure or other points for which decisions on operation and closure may be taken independently of the rest of the network to which they belong, chiefly for safety reasons, or reasons of capacity. On a road network, this includes bridges, tunnels, flood zones and areas liable to other hazards. However, the function description has been broadened to include specific structures which may be found on waterways (bridges, tunnels, locks), railways (bridges, tunnels, stations), air routes (a decision may be taken to close an airport due to bad weather or other alerts). This function provides management resources for technical equipment for collecting information about status, traffic or particular events which may affect the operation of the structure in question. It evaluates the current situation (both for vehicles and for drivers/pilots and their passengers), on the basis of a broad range of input data. This assessment allows the function to generate and disseminate warning messages to drivers/pilots (caution, new regulations, closures) on the one hand, and to event management functions (sub-area 3.2) and traffic management functions (sub-area 3.1) on the other. The function provides personnel (control operators) responsible for taking rapid decisions with the resources necessary to supervise the assessment process and override any automatic assessment if need be.

3.7 Manage FA3 shared data

This aggregate function provides an interface with the management of reference data and historised data in FA9.To do this, it collects reference data required by FA3 activities from FA9 and integrates them into the various datastores of FA3. In parallel, it extracts data awaiting historisation from the FA3 datastores and transmits this data to the ad-hoc function of FA9.

18 Certu – 2009


3.2 Datastores

The representations proposed in the ACTIF model are designed to make it easier to follow the functional chain for data processing from its origin through to the dissemination of the various possible products. These representations are based around the datastores required for this processing. 3.1 Traffic and forecasts datastore

This datastore contains traffic data relating to a given infrastructure. On the road network, in particular, it collects data on car park occupancy (urban network) and service area occupancy (interurban network). The data within this datastore is divided into three groups: the first concerns data from the current road network, the second concerns car park data, and the third concerns service area occupancy data; each group may, in turn, contain three sets of data (historical data, current data, forecast data).

The current data in the road network part of the datastore may contain the following elements (non-exhaustive list):- date/time; - location; - flow; - speed; - inter-vehicle distance; - occupancy; - queues; - count data.For each point on the network that supplies all or some of this data, a set of data such as that described above shall be provided. Each of these sets will contain current and historical data. Forecast data may concern another set of points on the network and contain a smaller subset of the above data.

The second group of the datastore will contain data relating to car parks within the urban road network. For each car park, data may be divided into three groups: historical data, current data, and forecast data. Below is a (non-exhaustive) list of the different elements that current data of this group may contain:- date/time; - car park location; - count data; - occupancy status.There will be a dataset for each of the car parks within the urban road network, and each dataset will contain current and historical data. Count data may correspond to either the number of vehicles in the car park or the number of spaces available. Whichever option is chosen will be valid for all car parks managed by a given system. The increase/decrease indicator relating to forecast data may contain no values.

The third group of the datastore will contain data on vehicle parking provided free of charge at service areas on the interurban road network. For each service area, data may be divided into three sets: historical data, current data, and forecast data. Below is a (non-exhaustive) list of the different elements that current data for a group may contain:- date/time; - service area location; - count data;- occupancy status.There will be a dataset for each service area in the interurban road network, with historical and current data in each dataset. Count data may correspond to either the number of vehicles in the service area, or the number of spaces available. Whichever option is chosen will be valid for all service areas managed by a specific system. The increase/decrease indicator relating to forecast data may contain no values.For other networks, traffic data will be configured according to infrastructure requirements (track occupancy, planned departures and arrivals, etc.).

3.2 Traffic management This datastore contains the description of traffic management strategies (notion of Plans de Gestion de Déplacements [Transport Management

Certu – 2009 19


strategy datastore Plans] on the road network) which may be put in place according to traffic conditions (traffic and event data), atmospheric conditions (ozone pollution alerts), etc. In non-road-based transport networks, these strategies may lead to a direct command being sent to the driver/pilot of the vehicle, or to the vehicle directly (direction, speed, altitude, stops/stations for boats or trains).

3.3 Environmental conditions datastore

This datastore contains data on environmental conditions in the geographical area managed by the system. This data will have been produced by functions belonging to this functional area, using input received by these functions.Below is a (non-exhaustive) list of the different elements that this datastore may contain:- day/date;- time;- location;- temperature;- humidity;- wind direction;- wind speed;- pollution levels.The number of entries will be determined by sampling. The number and type of pollutants recorded may vary according to the location and system.

3.4 Events datastore This datastore contains data relating to current and foreseeable events, as well as recommendations made following the evaluation of these elements.Data relating to events may include the following elements:- start date/time; - foreseeable duration; - current duration;- event location; - event type; - event severity; - number and types of vehicles; - strategy used;- emergency service vehicles used.The data for some of these entries will be supplied as and when there are changes in event status, while other data will be updated as the impact of the event develops and as event management actions are carried out.

3.6 Maintenance datastore

This datastore contains data relating to upkeep and maintenance work on the road network managed by the system. This data includes, for each of the three "areas" (i.e. network upkeep and maintenance, winter serviceability, maintenance of equipment), the following information:- estimated needs in terms of operations/works;- intervention recommendations (an intervention corresponds to an upkeep or maintenance operation, or to winter serviceability works);- scheduled or current interventions.

3.7 Specific engineering structure management datastore (e.g. for bridges, tunnels, stations)

This datastore collects information from the field equipment of specific structures and providers of traffic information, weather information, etc., and the management strategies to be applied in accordance with this information. It also contains the status of each item of equipment.

3.9 Video datastore This datastore contains video flows acquired from camera-type equipment.

3.10 Current traffic management strategy

This datastore contains data on the traffic management strategy currently being implemented by the system. Below is a (non-exhaustive) list of the different elements that this data may contain:- the reference of the current strategy;

20 Certu – 2009


datastore - the conditions that triggered the strategy;- date and time that the strategy was initiated;- scheduled measures;- measures implemented/yet to be implemented;- details of actions realised for each measure (content of action, expected results, resources mobilised, time taken, time initiated, etc.);- scheduled completion time for the implementation of the strategy;- risks identified;- specific points.

3.11 Planned works datastore

This datastore contains the list of scheduled upkeep and maintenance works.The following elements are specified for each work site (non-exhaustive list):- equipment requiring intervention;- upkeep/maintenance operations to be carried out;- resources to be mobilised (human and material);- scheduled intervention dates and durations;- expected disruption across the network (e.g. 2 lanes reduced to 1 lane for 1 km).

3.12 Current works datastore

This datastore contains data on work currently being implemented on the network, as well as work that has been scheduled but which has been terminated, or indeed not yet launched. Below is a (non-exhaustive) list of the different elements that this data may contain:- reference of works in progress;- conditions that caused work to be terminated or postponed;- date and time launched;- details of actions carried out/in progress/yet to be carried out (content of actions, expected results, resources mobilised, time taken, time initiated, etc.);- scheduled completion date and time;- risks identified- specific points.This data includes the following information at the very least:- identification of the strategy;- conditions for initiation;- details of measures to be applied.

Certu – 2009 21


3.3 Functions

The tables below contain the full names and descriptions of the model's functions, ordered by functional sub-area.

3.3.1Functional sub-area: Produce traffic data3.1.1 Collect traffic data

This low-level function collects traffic data from the road network. This data is supplied in the form of raw input from sensors (e.g. counting loops) belonging to functions capable of detecting the presence of all types of road vehicle, from bicycles to heavy goods vehicles. This raw data input is processed in order to provide current data on traffic flows, traffic speeds, etc. This data is then transferred to the datastore, where it is made available to other functions.

3.1.2 Collect urban car park occupancy data

This low-level function collects traffic data relating to entries and exits from urban car parks, as well as data on the parking spaces themselves. This data is supplied in the form of raw input via sensors belonging to the function capable of detecting the passage and presence of all types of road vehicle, from bicycles to heavy goods vehicles. Data collected and car park entrances/exits is processed in order to obtain current traffic count data, such as the number of vehicles entering and leaving each car park. This data is then transferred to the datastore, where it is made available to other functions.

3.1.3 Collect service area vehicle occupancy data

This low-level function collects data relating to entries and exits from service-area car parks on the interurban network. This data is supplied in the form of raw input via sensors capable of detecting the passage of all types of road vehicle, from bicycles to heavy goods vehicles. This raw data is processed in order to obtain current count data, namely the number of vehicles entering and leaving a given service area. The resulting data is then transferred to the datastore, where it is made available to other functions.

3.1.4 Compile traffic data

This low-level function compiles summary data using the raw data that has been collected. The compilation process involves verifying, converting, consolidating, aggregating and summarising these raw data so that they can be processed and disseminated by other functions.This phase also includes the reconstitution of traffic data, in the event that the raw data collected is not usable (faulty equipment, outlying data, etc.).

3.1.5 Detect traffic anomalies

This low-level function is responsible for detecting anomalies using traffic flow analysis. This function is typically implemented in systems such as DAB (Détection Automatique de Bouchons – Automatic Congestion Detection) systems. As output, it produces alerts warning of an abnormal event that has occurred (traffic jam, suspected accident, etc.).

3.1.6 Provide traffic forecasts

This low-level function supplies traffic forecasts. It uses current and historical traffic data collected across the network as input for algorithms that forecast traffic flows. These forecasts are produced periodically or on request. The forecasts are then transferred to the datastore, where they are made available to other functions.

22 Certu – 2009


3.1.7 Disseminate traffic forecast data

This low-level function disseminates data prepared by other functions to predetermined recipients. It is responsible for recipient management, formatting and dissemination to the ad-hoc media concerned.It manages data access issues and applicable dissemination rules (subscriptions, push or pull mode, etc.), and also handles requests from other functions or terminators. It is also capable, where required, of disseminating data to several media and in several formats.

3.1.8 Calculate journey times

This low-level function calculates journey times between points on the network covered by the system. It uses current and forecast traffic data from across the network as input to perform these calculations. Journey times are produced periodically or on request. They are then transferred to the datastore, where they are made available to other functions.

3.1.9 Disseminate journey times

This low-level function disseminates data prepared by other functions to predetermined recipients. It is responsible for recipient management, formatting and dissemination to the ad-hoc media concerned.It manages data access issues and applicable dissemination rules (subscriptions, push or pull mode, etc.), and also handles requests from other functions or terminators. It is also capable, where required, of disseminating data to several media and in several formats.

3.1.10 Produce traffic data

This low-level function prepares data extracted from the datastore so that it can be disseminated to other functions or terminators. This extracted data can either be raw data collected by the collection functions, or forecast data.Processing involves extracting the data from the datastore, transforming and/or calculating new data (e.g. indicators) and producing all or part of this data in a predefined format. The function can prepare data in different ways, depending on its intended recipients.

3.1.11 Disseminate traffic data

This low-level function disseminates data prepared by other functions to predetermined recipients. It is responsible for managing the list of recipients, formatting the data to be disseminated and the actual dissemination on ad-hoc media. It manages data access issues and applicable dissemination rules (subscriptions, push or pull mode, etc.), and also handles requests from other functions or terminators. Finally, where necessary, it is capable of disseminating data via several media and in various formats.

3.1.12 Collect video data

This low-level function is responsible for collecting video flows from camera-type equipment.

3.1.13 Detect anomalies using video

This low-level function is responsible for detecting anomalies using video flow analysis. This function is typically implemented in AID cameras. As output, it produces alerts warning of any abnormal events that may have occurred (e.g. pedestrian on the roadway, vehicle travelling the wrong way, stopped vehicle).

Certu – 2009 23


3.1.14 Disseminate video data

This low-level function disseminates data prepared by other functions to predetermined recipients. It is responsible for managing the list of recipients, formatting the data to be disseminated and the actual dissemination on ad-hoc media.It manages data access issues and applicable dissemination rules (subscriptions, push or pull mode, etc.), and also handles requests from other functions or terminators. Finally, where necessary, it is capable of disseminating data via several media and in various formats.

3.3.2 Functional sub-area: Manage events

3.2.1 Identify and classify events

This low-level function identifies and classifies events. It uses data on events supplied by other functions, both within this and other functional areas represented in ACTIF (public transport operators, commercial fleet operators, users), by functionalities in other functional areas of the system, and by terminators. This data is identified and classified as a particular type of event, according to its source, using internal "rules" specific to the function. It is then transferred to the datastore, where it is made available to other functions.

3.2.2 Compile event data

This low-level function compiles summary data using the raw data that has been collected. The compilation process involves verifying, converting, consolidating, aggregating and summarising these raw data so that they can be processed and disseminated by other functions.This function also prepares event data so that it can be disseminated to other functions or terminators.This data may be raw data collected by the collection functions, or compiled data.The function can prepare data in different ways, depending on its intended recipients.

3.2.3 Assess events and determine responses

This low-level function evaluates and determines responses to events detected by other functions. Periodically, it reviews event data collected and, where appropriate, recommends action to be taken. These recommendations include proposed modifications to public transport services, the production of local emergency signals, as well as proposals to allow free passage at toll plazas.

3.2.4 Disseminate event data


24 Certu – 2009


3.3.3Functional sub-area: Regulate traffic3.3.1 Analyse traffic conditions

This low-level function is designed to select the most appropriate traffic management strategy, based on: - current and forecast traffic conditions (vehicle flows, parking availability in car parks and service areas);- events that have occurred;- any alerts concerning bridges or tunnels;- requests for priority issued by public transport or emergency vehicles;- current and forecast environmental conditions;- recommendations for strategy modifications resulting from coordinated transport management.The function continuously analyses this data and decides, if necessary, to activate a traffic management strategy (a set of measures), chosen from a pre-defined list of strategies, or to initiate a single measure. A "measure" will consist of activating a piece of field equipment, sending information to a partner, etc.If the system decides to activate (or deactivate) a strategy, this command is transmitted to the activation function, which is responsible for implementing the command. In cases where only a single measure is to be initiated, the command is sent directly to the implementation function.In all cases, the analysis function receives an implementation report. The traffic data analysis process is continuous: once a decision is taken to activate a strategy, the effectiveness of the strategy is assessed using new data received. The system may suggest a new, more appropriate strategy.

3.3.2 Activate / deactivate a traffic management strategy

This low-level function activates a traffic management strategy. On receiving the strategy reference, this function extracts the implementation details from the Strategy datastore and then launches the necessary measures, including commands relating to field equipment.The activated strategy is transmitted to the datastore in order to be historised. This function may also request that a traffic management strategy belonging to another system be activated. It will then receive progress reports on the activation of this strategy and, if necessary, ensure its own measures are coordinated with those of the other system.

3.3.3 Implement traffic management strategies

This low-level function is responsible for triggering, sequencing and coordinating the traffic management measures to be implemented as part of the activation of a traffic management strategy. Its input is the strategy activated and the list of measures associated with this strategy. It then activates the functions of the systems responsible for implementing each measure. In return, it receives progress reports on the implementation of these measures, which enables it to produce an overall progress report.

3.3.4 Develop traffic management strategies

This low-level function elaborates traffic management strategies. It uses the policies in force as input data:- infrastructure operation policy; transport policy.Using this data, it develops a set of strategies that can be applied to different contexts. These strategies are transmitted to the Strategy datastore, where they are made available to the traffic conditions analysis function.

Certu – 2009 25


3.3.5 Assess traffic management strategy efficiency

This low-level function is responsible for analysing reports and summaries relating to the implementation of traffic management strategies, and subsequently deducing how these strategies can be improved. The reports will give details of: the context at the moment when the strategy is triggered (current events, traffic conditions, weather conditions, etc.); all strategies that are applicable at this time; the strategy selected; measures taken; the expected results; and the results actually obtained.Areas for improvement may concern modifications to strategy trigger conditions, measures to be applied, resources to be mobilised, etc. They may also recommend the scrapping of a strategy that is no longer suitable, or the creation of a new strategy.

3.3.6 Manage field equipment

This low-level function manages field equipment within the network covered by the system. It receives commands from the function responsible for implementing the traffic management strategy, and converts these commands into display orders for the field equipment specified in the command.In case of emergency (in particular, in the event of an accident), this function may receive emergency display commands directly.This function also checks the status of the field equipment under its responsibility, and sends back details of any faults observed to the upkeep and maintenance functions. These faults are also signalled to those functions responsible for putting in place transport strategies, so that these elements are taken into account.

3.3.7 Produce traffic advisories

This low-level function is responsible for producing traffic advisories. These must take account of current traffic conditions across the network covered by the system. They may take different forms, depending on the identified recipients.

3.3.8 Carry out in-field response

This low-level function manages field interventions vis-à-vis traffic events (e.g. traffic jams). It plans the intervention, defines the necessary resources and issues progress reports at regular intervals on the action it has taken and the results obtained.

3.3.9 Disseminate strategy data relating to ongoing traffic management

This low-level function disseminates data prepared by other functions to predetermined recipients. It is responsible for recipient management, formatting and dissemination to the ad-hoc media concerned.It manages data access issues and applicable dissemination rules (subscriptions, push or pull mode, etc.), and also handles requests from other functions or terminators. It is also capable of disseminating data to several media and in several formats.

3.3.10 Mobilise traffic partners

This low-level function is responsible for mobilising partners identified in connection with the implementation of a traffic management strategy. This mobilisation may take several forms, including:- information on the strategy triggered;- information on the current and future situations;- a specific action request.The partners identified shall include, at the very least, all those who participated in the production of the strategies.

26 Certu – 2009


3.3.4 Functional sub-area: Provide environmental information3.4.1 Collect atmospheric and weather conditions data.

This low-level function collects weather data. This data may either be supplied by meteorological systems, or be detected by sensors installed in the vicinity of the transport infrastructure concerned. The data obtained is then transferred to the datastore, where it is made available to other functions.

3.4.2 Collect atmospheric pollution data

This low-level function uses sensors to collect data on atmospheric pollution in the vicinity of the transport infrastructure concerned. The data obtained is then transferred to the datastore, where it is made available to other functions.

3.4.3 Collect noise pollution data

This low-level function uses sensors to collect data on noise pollution generated by the road network in the vicinity of the transport infrastructure concerned. The data obtained is then transferred to the datastore, where it is made available to other functions.

3.4.4 Forecast environmental conditions

This low-level function makes predictions concerning future environmental conditions in the geographical area covered by the system, on the basis of data collected and data supplied by other functions. These forecasts are produced using an algorithm and static data, and then transferred to the datastore, where they are made available to other functions.

3.4.5 Compile environmental conditions data

This low-level function compiles summary data using the raw data that has been collected.The compilation process involves verifying, converting, consolidating, aggregating and summarising these raw data so that they can be processed and disseminated by other functions.

3.4.6 Process environmental conditions data

This low-level function prepares data extracted from the datastore so that it can be disseminated to other functions or terminators.This extracted data can either be raw data collected by the collection functions, or forecast data.Processing involves extracting the data from the datastore, transforming and/or calculating new data (e.g. indicators) and producing all or part of this data in a predefined format. The function can prepare data in different ways, depending on its intended recipients.

3.4.7 Disseminate environmental conditions data


Certu – 2009 27


3.3.5Functional sub-area: Manage upkeep and maintenance of transport infrastructures

3.5.1 Collect maintenance needs

This low-level function identifies the upkeep and maintenance needs of the infrastructure and its equipment. It identifies these needs on the basis of data relating to traffic volumes recorded, weather conditions, and the state of the infrastructure (road surfaces, banks, equipment); network events (e.g. accidents); and upkeep and maintenance criteria. In particular, it specifies the following:- sections of the network where upkeep and maintenance operations are to be carried out;- the nature of these operations;- the earliest and latest dates between which these operations can be carried out;- the scale of these operations (duration, resources, etc.);- prerequisites for these operations to be triggered;- the foreseeable impacts on traffic, etc.

3.5.2 Collect winter serviceability requirements

This low-level function identifies needs in terms of winter serviceability work on the road network. It identifies these needs on the basis of data relating to the state of road surfaces; weather forecasts; and criteria for such work. In particular, it specifies the following:- sections of the network where this work is to be carried out;- the nature of this work;- the earliest and latest start and finish dates between which this work can be carried out;- the scale of these operations (duration, resources necessary, etc.);- prerequisites for this work to be triggered;- the foreseeable impacts on traffic, and therefore on the proposed operating conditions before and during work, etc.

3.5.3 Collect equipment maintenance needs

This low-level function identifies the maintenance needs of equipment on the transport infrastructure concerned. It identifies these needs on the basis of faults observed on the various items of equipment across the network (data/information collection field equipment; closure, management or other equipment for bridges, tunnels and particular structures such as locks or airports). In particular, it specifies the following:- the equipment on which the maintenance operations are to be carried out;- the nature of these operations;- the earliest and latest dates between which these operations can be carried out;- the scale of these operations (duration, resources necessary, etc.);- prerequisites for these operations to be triggered;- the foreseeable impacts on traffic, and therefore on the proposed operating conditions before and during work, etc.

28 Certu – 2009


3.5.4 Analyse upkeep and maintenance requirements

This low-level function is designed to select works to be launched or terminated, depending on:- the provisional works schedule (scheduled work sites);- current and forecast transport conditions (traffic conditions, current events, car park and service area availability).The function continuously analyses all this data and decides, where necessary, whether to launch or terminate scheduled work or work in progress. If the system decides to launch (or terminate) work, details of the work site concerned are transmitted to the launch/terminate function, which will implement the command.

3.5.5 Schedule work sites

This low-level function is responsible for scheduling upkeep and maintenance works. It produces a schedule of work to be implemented, based on upkeep and maintenance needs collected beforehand. The schedule also takes account of applicable regulatory restrictions (e.g. concerning distances between work sites). The following elements are specified for each work site (non-exhaustive list):- the equipment requiring intervention;- the upkeep/maintenance operations to be carried out;- the resources to be mobilised (human and material);- the scheduled intervention dates and durations;- expected disruption across the network (e.g. 2 lanes reduced to 1 lane for 1 km).

3.5.6 Launch / terminate work sites

This low-level function launches or terminates upkeep/maintenance work. Upon receiving the reference for the work site, this function extracts the implementation details from the relevant Works datastore and then requests the implementation of actions associated with the work site (information on the start of work, marking of the zone concerned, action relating to the work site proper, etc.). The work site reference is transferred to the datastore for historisation. This function can also ask another system to implement work. It will then receive progress reports on the implementation of this work and, if necessary, ensure its own measures are coordinated with those of the other system.

3.5.7 Implement upkeep and maintenance actions

This low-level function is responsible for triggering, sequencing and coordinating upkeep and maintenance actions to be implemented as part of the launch (or termination) of a work site. As input, it receives the list of actions associated with this work site. It then activates those functions of the system responsible for implementing each action. In return, it receives progress reports on the implementation of these actions, which enables it, in turn, to produce an overall progress report for the work site.

3.5.8 Carry out upkeep and maintenance operations

This low-level function monitors and manages interventions carried out on the ground as part of upkeep and/or maintenance work. It plans the intervention, defines the resources and means necessary through the structure responsible for these maintenance interventions, and issues progress reports at regular intervals on the action it has taken and the results obtained.

Certu – 2009 29


3.5.9 Disseminate data on planned and current maintenance work


3.3.6Functional sub-area: Manage a network's particular structures and atypical points

3.6.1 Collect field equipment data

This low-level function collects information resulting from different sensors and surveillance devices set up to assist with the management of structures. Using these sensors, it analyses analogue data to obtain information about the real-time operation of a given structure (video, opacity sensors, smoke sensors, operational status of fans, etc., in tunnels; meteorological conditions on the approach to bridges, state of cables, etc.). It transfers data to the Specific structure management datastore, where it is made available to other system functions.

3.6.2 Collect information from other services

This low-level function collects specific information that may determine the operating conditions (or even the closure) of the structure from external information providers or other information services. This may include meteorological information, forecast traffic data, or information relating to the transport of hazardous or wide loads. It analyses this information and transfers it to the Specific structure management datastore, where it is made available for other system functions.

3.6.3 Analyse information received

This low-level function analyses data received and consequently deduces the status of the infrastructure concerned with regard to the traffic to be carried and the strategy or measures to be implemented in order to respond to any malfunctions observed. On this basis, it may propose the opening or closure of the bridge or tunnel to all or some types of vehicle.This function enables the control operator to validate these proposals before they are implemented by means of information displays intended for drivers and other passengers.

30 Certu – 2009


3.6.4 Disseminate data relating to planned or current measures

This low-level function disseminates locally implemented or scheduled operational measures to all partners. This may include simple information indicating a need for data collection or control equipment to be maintained, or information on the closure of a structure or the implementation of a specific operational measure that has consequences on the infrastructure's traffic management, or even on the intervention of emergency or operational teams. It is responsible for managing the list of recipients, formatting the data to be disseminated and the actual dissemination on ad-hoc media.It manages data access issues and applicable dissemination rules (subscriptions, push or pull mode, etc.), and also handles requests from other functions or terminators. Finally, where necessary, it is capable of disseminating data via several media and in various formats.

3.6.5 Manage closure equipment

This low-level function controls closure equipment for structures. It receives commands from the control operator via the information analysis function, and converts these commands into closure orders for the equipment specified in the command.This function also verifies the status of the closure equipment under its responsibility, and sends back details of any faults observed to the upkeep and maintenance functions.

3.3.7Functional sub-area: Manage FA3 shared data3.7.1 Collect reference data

This low-level function makes it possible to collect reference data from different sources (e.g. description files for a road network, cartographic data, etc.). This data comes from a centralised repository (FA9).

3.7.2 Prepare data for historisation

This low-level function extracts a set of data from the various datastores within functional sub-area 3.3 and prepares this data to be historised in FA9. This preparation process may involve several stages: ensuring consistency, transformation, aggregation, consolidation, calculations, etc.

3.4 Data-flow diagrams

Data-flow diagrams are the representations proposed in the ACTIF model to make it possible to follow the functional chain for data processing from its origin through to the dissemination of the various possible products. They are based around central datastores which stock data that has been (or is to be) processed and the algorithms necessary for this processing. These functional diagrams follow the generic pattern adopted in the modelling rules (see the overall model presentation document).

Certu – 2009 31


32 Certu – 2009


Certu – 2009 33


34 Certu – 2009


Certu – 2009 35


36 Certu – 2009


4. Standards and legal requirementsThe various standards described in ACTIF essentially concern the domain of road-based transport and road infrastructures. This characteristic results from the fact that ITS framework architectures have historically focussed on road infrastructures. However, future developments of the model will have to take account of demand from other modes. The main standards indicated below concern exchange formats and event locations:

Name References DescriptionRDS-TMC ENV 12313, XP ENV 12313,

PR NF EN ISO 14819Traffic and travel information – RDS-TMC with ALERT-C and ALERT-PLUS

DATEX ENV 13777 DATEX specification for traffic information messages

DSRC ENV 12253, ENV 12795, ENV 12834, ENV 13372

Dedicated short-range communications

LCR NF P99-340, NF P99-341, NF P99-342

Road information and control – Road control language

MI2/SIREDO Count data collectionSEDT Exchange format used to transfer data

between the SIER (Service Interdépartemental d'Exploitation Routière – Interdepartmental Road Operation Service) and Paris City Council, as well as between Paris City Council's network server (known in French as a "serveur grossiste") and service operators

Signal-controlled junctions

NF P99-071-1 & 2 This defines the functional characteristics necessary for data exchanges in series mode between a traffic signal controller and an external control system(Standard defining the DIASER communication protocol)


NF P99-100 This defines the minimum specifications for a traffic signal controller, with the intention of preventing erroneous messages from appearing on traffic signals at junctions


NF P99-022 This describes the test methods for the different characteristics (electrical, electromagnetic and functional) of traffic signal controllers


NF P99-110 This defines the functional characteristics, types of information exchanged, types of connectors to be used for wire-to-wire connections between junction controllers and external bodies

TPEG ISO/CEN standard concerning the delivery of traffic and travel information (TTI)

TRIDENT European prestandard defining the data exchange formats and services for public transport and road transport.

Certu – 2009 37


Here, we shall also mention geographical repositories, which will be used to describe the routes and networks of infrastructures proper.

4.1 Geographical repository

This concerns the different repositories that are used to geolocate an object and map it onto a cartographic medium. Note: today, all data relating to public service provision – particularly transport – must be published on geographical media, in accordance with the INSPIRE directive.This means referencing each element of a public transport offer (e.g. road-based elements according to the road repository, and other public transport services with lines and stops/stations) on cartographic media: hence the need to identify and use systems of coordinates resulting from recognised national or international standards (Lambert and Lambert II, WG84, etc.) and widely used geolocation processes (GPS, Galileo, etc.).

4.2 RDS-TMC

RDS (Radio Data System) enables the dissemination of data simultaneously with an FM radio broadcast, using the subcarrier of the radio frequency concerned.TMC (Traffic Message Channel) is a European standard developed by CEN with the aim of specifying the coding, delivery (using the FM-RDS subcarrier) and decoding of traffic information. There are two types of information:

event information, which uses the Alert-C protocol; traffic and journey time information, which uses the Alert-Plus protocol.

4.3 DATEX

This standard enables data exchanges between different partners. It acts as a data dictionary for the dissemination of road information.

4.4 DSRC

DSRC (Dedicated Short-Range Communications) is a short-range communications standard with a spectrum allocated in the 5.8–5.9 GHz range. It enables data exchanges between fixed beacons and mobile receivers over short distances. This technique is used in particular for electronic contactless toll collection.

4.5 LCR

LCR (Langage de Commande Routier – Road Control Language) is a standard for controlling field equipment, especially VMSs.

4.6 MI2/SIREDO

SIREDO and MI2 correspond to standards for collecting count data. SIREDO stations manage traffic counting loops. At the French infrastructure ministry (MEEDDM), count data is then centralised on an MI² node. MI2 nodes are interconnected via the Ministry's I² network and are present at the CRICRs, the CNIR (Centre National d'Information Routière – National Centre for Traffic Information) and certain DDEs (Directions Départementales d'Équipement – Departmental Infrastructure Directorates).

38 Certu – 2009


4.7 TPEG

TPEG (Traffic Protocol Expert Group) is an ISO/CEN standard for the transmission of traffic and travel information (TTI). One of the characteristics of TPEG is the multiplicity of its carrier systems (DAB, internet), whereas RDS-TMC is only supported by the subcarrier of FM radio broadcasts. TPEG can handle various TTI applications, for all transport modes: e.g. road traffic information, arrival and departure times for trains, trams, buses, ferries and aeroplanes.

4.8 TRIDENT

European prestandard defining the data exchange formats and services for public transport and road transport.

Certu – 2009 39