Assistance for the design of interoperable ... - its-actif.org · ACTIF presentation and usage documents – FA4 1 Introduction 1.1 About this presentation document Assistance for

Assistance for the design ofinteroperable transport in

France: ACTIF

ACTIF presentation and user guide documents

Presentation of Functional Area 4

Manage public transport operations

April 2009

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

ACTIF presentation and user guide documents – FA4

Contents

1 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 public tra nsport operations”..7

2.1 Objectives and services .............................................................................7

2.2 The functional scope presented in ACTIF...................................................7 2.2.1 Segmentation into functional sub-areas..........................................................8

2.3 The limits of the model’s scope: interfaces with the outside world...............9 2.3.1 Transport authorities.......................................................................................9

2.3.2 External service providers ..............................................................................9

2.3.3 Public transport staff and vehicle depot..........................................................9

2.3.4 Intervention teams ..........................................................................................9

2.3.5 Data collection field equipment....................................................................10

2.3.6 Public transport vehicles and on-board equipment.......................................10

2.3.7 Field camera equipment................................................................................10

2.3.8 Control or information field equipment........................................................10

2.3.9 Users.............................................................................................................11

2.3.10 Shared-vehicle offerer.................................................................................11

2.4 Interfaces with the other functional areas of ACTIF...................................11 2.4.1 Provide electronic payment facilities (FA1).................................................11

2.4.2 Manage safety and emergency services (FA2).............................................11

2.4.3 Manage transport infrastructures and their traffic (FA3)..............................12

2.4.4 Provide advanced driver assistance systems (FA5)......................................12

2.4.5 Manage and inform on multimodal transportation (FA6) ............................12

2.4.6 Enforce regulations (FA7)............................................................................13

2.4.7 Manage freight and fleet operations (FA8)...................................................13

2.4.8 Manage shared data (FA9)............................................................................13

3 The functional model........................... ..................................................14

3.1 Functional breakdown...............................................................................14

3.2 Datastores.................................................................................................15

3.3 Functions.................................................................................................17 3.3.1 Functional sub-area: Organise and plan public transport services................17

3.3.2 Functional sub-area: Monitor, control and inform passengers.....................18

3.3.3 Functional sub-area: Manage human and physical resources.......................20

2 Certu – April 2009

ACTIF presentation and user guide documents – FA4

3.3.4 Functional sub-area: Organise shared services.............................................21

3.3.5 Functional sub-area: Manage FA4 shared data.............................................21

3.4 Data-flow diagrams...................................................................................22

4 Standards and legal requirements............... .........................................25

4.1 TRANSMODEL.........................................................................................25

4.2 RDS-TMC.................................................................................................25

4.3 DATEX......................................................................................................25

4.4 DSRC........................................................................................................25

4.5 TPEG........................................................................................................26

4.6 TRIDENT..................................................................................................26

4.7 Geographical repository............................................................................26

Certu – 2009 3

ACTIF presentation and usage documents – FA4

1 Introduction

1.1 About this presentation document

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

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

− a model which provides a representation of transport professions and the interfacesbetween 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 entiremodel in an instructive way and which set out the general principles under which the modelcan be adopted by ACTIF users. Its aim is to present Functional Area 4: "Manage publictransport operations" .

In order to understand the logic behind the ACTIF model as a whole and the principles thathave been adopted to make it more intuitive, comprehensible and user-friendly, please referto the framework document, which provides details of the entire ACTIF model (includingthe thinking behind its development and the modelling rules used). The other functionalareas 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 theperspective of information systems. The activities that it describes are based aroundfunctions designed to collect, store, process and disseminate data of increasingcomplexity.

The basic data comes either from other professions represented within ACTIF, or fromexternal third parties, known as "terminators". In the same way, the information generated bythe 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 notrepresented within ACTIF: field equipment, partner structures and organisations, drivers andusers, etc.

For example, infrastructure managers (whose role is described within ACTIF) receive eventalerts from field equipment (cameras, loops, etc.), which they then processes beforedisseminating their analysis to the people in charge of implementing an event managementstrategy on the ground. If traffic control measures are needed, they communicate the relevantinformation to the infrastructure's users via variable message signs (VMSs) or other types ofmedia (e.g. radio stations). The cameras, loops, VMSs, radio stations and users are allclassed as terminators.

Information may also be sent to the relevant public transport operator, which will take thenecessary control measures (possible service modifications). These control measures will be



communicated to the vehicle (driver) and/or to passengers and other users. The profession ofpublic transport operator is described in the ACTIF model.

The functional chains described in the model are logical chains of information collection,storage, processing and dissemination functions, which send information to other collectionfunctions, storage functions, etc. These logical chains must not be considered solely from theviewpoint of the technical and ICT systems required to achieve them. They must be seenrather as functions that are part of a wider transport service arrangement, which includesautomation 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. Itmay also involve internally cyclical processes, either as part of cooperation betweenpartners, 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 differenttransport professions, but also the information flows that may exist between differentstructures, organisations and systems in the context of a cooperation, collaboration orpooling of resources. Each of the different data functions, datastores and information flowshas been linked with the relevant applicable standards and regulations in the varioustransport professions. The model proposes a generic description of the content and form ofeach of these objects.

In addition to the proposal for a repository for the transport professions, the aim of this kindof model is for it to be used in the description of existing or planned systems. In order todescribe its organisation, operation and interfaces with partners and the outside world, thecontent of messages and databases and the technical implementation of functions must bespecified. The use of knowledge that is already organised means time savings can be madeby 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 professionscovered by ACTIF are grouped into functional areas, each of which corresponds tostructures, organisations or services found in the real world. The ACTIF model contains ninefunctional areas. They are segmented and numbered in accordance with the equivalentEuropean 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 thisdocument is to show the logic used in the representation proposed in the model, and the wayin which this working basis and reference can be used in practice.

Certu – 2009 5


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;

− data-flow diagram;

− datastores;

� associated standards.



2 Scope of the functional area “Manage public transportoperations”

2.1 Objectives and services

Public transport (in France, at least) is defined as all means of passenger transportimplemented under the jurisdiction of a public authority. This definition covers:

− all urban and interurban public transport, regardless of the transport mode used(bus/coach, tram, boat, metro or train), including long-distance services;

− vehicles made available to users (in urban and non-urban contexts) under the authority ofa public corporation in the context of contracts concluded with the operator (sharedbicycles or cars);

− taxis that operate under the authority of and with the consent of public corporationswithin the scope of an urban transport plan.

The services described in the ACTIF model are theoretically limited to functions performedby a public transport operator acting on behalf of a public transport authority. Theprofessions and services described will supply systems with information required for themanagement of the physical and human resources allocated to the service. This means:

− with regard to planning, also known as theoretical time or planned time: defining the"theoretical" offer with the designation of lines, routes, stops/stations served andtimetables (service and timetable planning);

− with regard to immediate planning: allocating physical and human resources (vehicleand crew scheduling);

− in real time: supervising and controlling the transport offer, and providing of passengerinformation (control);

− finally, managing demand for non-scheduled services (demand-responsive transport andshared-vehicle management).

These services are generally implemented in the context of information systems that aremore or less automated, known as AVL–RTPI (Automatic Vehicle Location and Real-TimePassenger Information) systems.

The aim of the ACTIF model is to illustrate the information exchanges that may beenvisaged between public transport network operators and the different partners that mayintervene in the realisation of services. Here, we are thinking in particular of the managers ofinfrastructures used to perform the service, of emergency and rescue services that mayintervene on a transport line or in a bus, and of multimodal information systems which maybe informed in real time of service modifications.

2.2 The functional scope presented in ACTIF

As indicated in the previous paragraph, the functional scope of FA4 corresponds closely tothe functions performed by AVL–RTPI information systems. However, the informationcollection, storage and dissemination functions are not all automated. Above all, AVL–RTPIsystems intervene in order to provide controllers with decision-making assistance: the idea isto send back images that are as precise as possible reflecting the reality of the service, inorder to determine, where appropriate, adaptations to the basic service offer; these

Certu – 2009 7


adaptations must then be passed on to vehicles (and their drivers, where applicable) andusers.

This means that, in terms of real time, managing public transport operations essentiallyinvolves controlling transport services – and informing passengers, who increasingly seekmore information.

This therefore involves:

− monitoring vehicles, communicating with them and issuing commands, orders orinstructions via data collection and control equipment;

− having usable passenger information equipment available to deliver messages.

This real-time operation presupposes that data relating to the transport offer and adaptationoptions is known. It is therefore a question of being able to simultaneously reconcileenvisaged adaptations with the theoretical service offer (which the user has paid for) and themanagement of human and physical resources. For this reason, the ACTIF model has takenthe following two functional sub-areas into consideration:

− manage human and physical resources;

− organise and plan public transport services.

Furthermore, it seemed necessary to take account of all newly proposed products andactivities in connection with public transport. This includes demand-responsive transport(DRT), shared-vehicle management (bicycles or cars) and taxi fleet management.

Finally, like all the other functional areas described in ACTIF, a sub-area has been identifiedwith the aim of retrieving and updating the repositories, thus making it possible to presentand use data, and historise operating data with a view to reuse at a later date.

2.2.1 Segmentation into functional sub-areas

In the ACTIF model, the choice was made to segment this functional area into fivefunctional sub-areas:

− sub-area 4.1: Organise and plan the public transport services – i.e. the description of thetransport offer (definition of lines, stops/stations served, timetables, transport modes,etc.), from the receipt of requests from public transport authorities through to thepublication of this information in different formats and/or media;

− sub-area 4.2: Monitor, control and inform passengers – including the real-timemonitoring of the performance of the service and feedback of field information, dialoguewith drivers and/or vehicles, and sending instructions or control orders. This alsoincludes real-time passenger information.

− sub-area 4.3: Manage human and physical resources – including the receipt ofinformation from depots concerning personnel and rolling stock, and the allocation ofwork;

− sub-area 4.4: Organise shared services – this involves matching service requests withknowledge of the service offer in order to suggest a suitable response (shared vehicles,carpooling, DRT, taxis, etc.);

− sub-area 4.5: Manage FA4 shared data.



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

The functional area "Manage public transport operations" may be required to exchangeinformation with other services, structures and people that, in turn will be emitters or targetsof information.

Some of these emitters or targets of information are described in the ACTIF model in otherfunctional areas. Here, we are thinking, for example, of areas and activities relating totransport infrastructure management, electronic ticketing systems or passenger information.

Other services are not described functionally in ACTIF: these are "terminators", whichinclude not just field equipment and vehicles, but also partner structures such as localtransport authorities or shared-vehicle service providers, and people such as users of servicesor drivers.

These terminators are described as being "external": they are not people who participatedirectly in the system and who may take charge of all or part of certain functions: If theopposite were true, they would be deemed "internal actors", which are not modelled inACTIF. In order to indicate the limits of the functional scope, references to certain internalactors may be put in italics in certain cases.

2.3.1 Transport authorities

Public transport authorities entrust public service missions to operators. In terms ofinformation exchanges, they are required to provide regular reminders of service objectives,whether in connection with normal timetable periods, planned or unplanned events, or crisissituations.

In return, FA4 emits data on services performed and service quality. This data supplies thecyclical mechanism that evaluates the service and strategies put in place to control theservice.

2.3.2 External service providers

In this case, the external service providers represented in FA4 are not mediators capable ofdelivering information to passengers. Indeed, most of the time, operators use their ownsystems (the passenger information aspect of AVL–RTPI).

External service providers are essentially viewed in this functional area as partners that may,in certain cases, be led to request the implementation of special services. These are thereforepartner structures, often public transport clients, such as businesses, administrations or publicservices (schools or hospitals). In this way, they have an influence on the definition of theoffer.

2.3.3 Public transport staff and vehicle depot

The monitoring of vehicles and staff and the final allocation of jobs and runs to vehicles anddrivers ultimately takes place in the depot: this makes it possible to check the arrival anddeparture of vehicles, the general state of vehicles, and the availability of drivers. Theexchanges provided for with the automatic vehicle location (AVL) system therefore concern:

- as AVL input, absences and feedback from staff and vehicles, and the visual state of rollingstock;

- in return, the information system communicates vehicle and driver allocation instructions,and information on scheduled and ongoing maintenance.

2.3.4 Intervention teams

In the main, these are teams that will be called upon to intervene on the ground shouldspecific events or incidents arise within the network. These teams receive maintenance

Certu – 2009 9


intervention requests on behalf of the system (AVL aspect of AVL–RTPI) and send backintervention reports (progress, availability of rolling stock, etc.).

2.3.5 Data collection field equipment

For AVL systems, it needs to be possible to monitor vehicles so as to be able to control theirprogress (advance/delay with regard to a run) and their operational status. The firstgenerations of equipment were generally installed at fixed points along the routes travelled.These sensors would send back indicator-type information concerning:

- the vehicle itself;

- the equipment and surroundings at these fixed points (this could concern noise-levelinformation at a stop/station, or the state of the infrastructure itself, e.g. the state of rails orfixed equipment).

These sensors do not receive any information.

2.3.6 Public transport vehicles and on-board equipment

Equipment for sending back information from the vehicle and communicating with it or itsdriver is represented through this terminator. This is therefore equipment that is intendedexclusively for transport operations. The links provided for between the functional area andthis set of emitters/receivers are:

- As system input, indicators concerning the vehicle (position, speed, load, operationalstatus) and "control messages" generated automatically or triggered by the driver to signalcircumstances requiring a control intervention, or to report that an action or instruction hasbeen carried out. Communications with the controller are also taken into consideration.These communications are generally linked to elements of dialogue between the controllerand the driver.

- As system output, communications from the controller to the vehicle, which may includeservice and/or control instructions.

Note: for remotely guided vehicles, functions belonging to FA5 of ACTIF may also be used.

2.3.7 Field camera equipment

This is equipment installed either at fixed points or in the vehicles themselves to enable alive view of situations. This equipment, which is requested more and more, complementscontrol tools. The processing of video signals may be shared with other functional areas(electronic ticketing and fare evasion detection, regulatory enforcement by means of videoimages showing, for example, cars using bus lanes). Video signals may, where necessary,also be shared with emergency or security services.

The model only takes account of information flows from the cameras to the control system.

2.3.8 Control or information field equipment

This equipment only receives information produced by the AVL–RTPI system. It may be on-board or fixed equipment.

Depending on the situation, this equipment will constitute one of the interfaces between theAVL system and vehicles or their drivers when it includes signalling or control elements(traffic lights, barriers corresponding to orders to advance or wait), or the interface betweenthe RTPI system and the passenger when it includes information on the scheduled run (nextstop/station, changes with other services, estimated time of arrival at the terminus, servicedisruptions).

The information flows described in ACTIF are output flows from FA4 and its informationsystems. They include the initial parameters (description of the service and consideration ofrepositories), scheduled runs, and passenger information.



2.3.9 Users

As part of the representation of the profession "Manage public transport operations", usersappear as targets or emitters of information as soon as they interact or come into contactdirectly with the information system, i.e. via telephone, e-mail, text message or similarmeans. Just because information is delivered over a public announcement system or on ascreen (information or control equipment, which may be on board the vehicle), it does notnecessarily mean that the user will receive this information.

For this reason, the only exchanges with users that are taken into account are as follows:

- as input for FA4, "specific journey requests", normally made outside a regular service (e.g.DRT, booking a vehicle or trip, booking a taxi);

- in return, the user receives a "shared vehicle supply and demand match" message.

2.3.10 Shared-vehicle offerer

This actor has one or more vehicles that may be available for a given service (or journey).This may be a private individual (carpooling), a vehicle-hire manager (car-share schemes),or an operator liable to set up a DRT service.

This service provider informs potential users of its available services and receives supply anddemand match notifications from the management system. In the case of private individuals,all direct contact takes place outside the ACTIF model: ACTIF takes care of initialcoordination only, by supplying contact details to each party.

In the case of a public transport operator, this may lead to the chartering and monitoring of aDRT vehicle.

2.4 Interfaces with the other functional areas of ACTIF

In order to take account of the possible interfaces between structures, professions andorganisations involved in the transport sector, the ACTIF model provides for informationexchanges between the different functional areas described. Certain information exchangesmay already be in place on the ground; others may not yet have been converted intotechnical solutions, or may never have been implemented.

Below, you will find the information flows proposed by ACTIF, functional area byfunctional area.

2.4.1 Provide electronic payment facilities (FA1)

Depending on the feedback and information processing techniques implemented, electronicticketing systems implemented in public transport systems may provide an instant overviewof ridership on transport services.

The "passenger flow validation data" proposed between functional sub-area 1.8, "Monitorservice consumption", and functional area 4.2, "Monitor, control and inform passengers"makes it possible to transfer aggregate data, i.e. data that has been validated and anonymised.

No information exchanges from FA4 to FA1 are provided for. It is assumed that any faremodification instructions will be passed on either via the transport authority (or operator, if ithas the necessary powers), or from FA6, "Manage and inform on transportationcoordination".

2.4.2 Manage safety and emergency services (FA2)

As with most other functional areas, the model makes provisions so that public transportoperators can report an accidental event that may require the intervention of emergency orsecurity services.

Certu – 2009 11


The exchanges envisaged therefore concern sub-areas relating to the supervision/control ofthe service (sub-area 4.2) on the one hand, and incident call management (sub-area 2.1) onthe other. These exchanges are as follows:

- as output from FA4, incident (or accident) notifications;

- as input, the clearing of incident notification messages (so that the next step can be known).

In the model, subsequent information concerning operating instructions to be implemented atthe request of emergency services does not come directly into contact with FA4. Instead, it ispassed on by one of the following: the external actors "transport authorities" or "networkoperators" (for infrastructure or public transport issues); FA6 if the overall management ofthe transport offer can be described on the ground; or the transport infrastuctrure manager,which passes on instructions and information concerning the operations implemented.

2.4.3 Manage transport infrastructures and their traffic (FA3)

The links considered in the model between the public transport operators and infrastructureoperators concern:

− as FA3 input, forecast traffic data and scheduled journey times, as well asrecommendations for modifications to services in the event of a specific servicemodification procedure being implemented;

− as output, public transport operators submit requests for priority at traffic lights (whichmay be processed in real time by sending messages to information and commandequipment or as part of a more general traffic control strategy), and provide informationconcerning scheduled events (special services) or accidental events.

2.4.4 Provide advanced driver assistance systems (FA5)

AVL–RTPI systems increasingly incorporate options enabling the real-time monitoring ofvehicle fleets using geolocation and the remote communication of instructions. Theseinstructions are either sent to the driver (human interface for on-board equipment) or sentdirectly to the vehicle (in the case of remotely controlled vehicles). FA5 enables themodelling of functional chains that are to be provided for in on-board systems. Accordingly,the model proposes the following data flows:

� output from the vehicle, such as "disseminated vehicle data" (information on theposition and operational status of the vehicle and/or driver);

� input to the vehicle, notably "public transport vehicle control commands".

2.4.5 Manage and inform on multimodal transportation (FA6)

The aim of FA6 is to group together, in real time, all data relating to transport supply anddemand so as to propose synoptic charts to each of the partners that interact within a givenarea and across a set of transport infrastructures. In addition to this first role, the idea is to beable to coordinate the transport available by putting in place a coordinated offer, andpossibly by establishing transport management plans between several actors. Another role ofFA6 is to supply passenger information, either upstream of journeys or, where possible,during journeys. This may constitute the functional basis of a multimodal informationsystem.

The ACTIF model therefore proposes interfaces between the transport operators representedin FA4 and the services responsible for proposing coordinated services or, at the very least,passenger information. The interfaces taken into account in the model are as follows:

- from FA6 to FA4, data concerning transport conditions and recommendations for servicemodifications;

- from FA4 to FA6, service modifications linked to control decisions. It is also via this flowthat operators take account of service modifications implemented following



recommendations. Note: all information relating to the theoretical public transport offerpasses between FA4 and FA6 via FA9, "Manage shared data"; this data is considered as a setof reference data that transport management strategies will be based on.

2.4.6 Enforce regulations (FA7)

2.4.7 Manage freight and fleet operations (FA8)

Interfaces between FA4 and these two functional areas have not been taken into account.

2.4.8 Manage shared data (FA9)

Like all the other functional areas, the data used to communicate with public transportoperators and their AVL–RTPI systems is defined according to specific repositories, whichmay change over time. Here, we are thinking, for example, of changes in technical andregulatory elements (e.g. the accessibility of networks and information) or changes in thestandards and exchange profiles used to describe the transport offer available (lines, routes,networks, etc.).

Historised data comprises all data that can be retrieved from the different datastores toproduce status reports and analyses.

At the request of public transport experts, data relating to the "theoretical transport offer" iscollected from sub-area 4.1, "Organise and plan public transport services", and sent to sub-area 9.1, "Manage repositories".

The idea is to be able to distinguish between flows relating to the theoretical transport offer(seen as a reference) and real-time information exchanges that may lead to servicemodifications (see interfaces with FA6) when using the model.

In the current version of the model, no provision is made for exchanges concerning"disseminated status reports and analyses" – which would enable the evaluation and updateof public transport control strategies. This data is normally used by public transportauthorities to propose new service instructions. This exchange may be incorporated ifrequested by experts in the profession.

Certu – 2009 13


3 The functional model

The following chapter presents the content of the model.

3.1 Functional breakdown

4.1 Organise and planpublic transportservices

This aggregate function manages basic data, plans and organises theproduction of services, and manages and maintains resources.

4.2 Monitor, controland inform passengers

This aggregate function is commonly known by the abbreviationAVL–RTPI (Automatic Vehicle Location and Real-Time PassengerInformation).

The two functionalities – automatic vehicle location and passengerinformation – traditionally go hand in hand, in that the data enablingthe second functionality is naturally and directly established by thefirst.

The aim of automatic vehicle location (AVL) is to continuouslyadapt public transport services to circumstances on the ground. AVLis taken into account by a key internal actor, the controller (aninternal actor that appears in the model through its function). It hastwo functions: monitoring public transport, and controlling publictransport. The term "passenger information" here is limited toimmediate information on the functioning of public transportservices and related disruptions, and should not be understood in thewider sense used in FA6, for example. Passenger information islimited to the production of information aimed at passengers; thedelivery of this information is dealt by the "Disseminate operatingdata" function.

4.3 Manage humanand physical resources

This aggregate function is responsible for the centralisedmanagement of human and physical resources, as opposed to "localmanagement", which is carried out in vehicle depots and crewfacilities. It comprises two independent components:

- central management of personnel (human resources management,payroll, etc.);- central management of rolling stock (fleet management).

4.4 Organise sharedservices

This aggregate function enables the planning and organisation ofshared services, ranging from public transport, such as DRT, toshared-vehicle management; it also includes private initiatives suchas carpooling.

4.5 Manage FA4shared data

This aggregate function provides an interface with the managementof FA9 reference data and historised data.To do this, it collects reference data required by FA4 activities fromFA9, and incorporates this data into the various FA4 datastores.

In parallel, it extracts data awaiting historisation from FA4 datastoresand transfers this data to the ad-hoc function of FA9.



3.2 Datastores

4.1 Instantaneousproduction datastore

This datastore contains a continuously updated image of thetheoretical (or planned) production and actual production of publictransport services, that changes according to events that influencethis production and control measures taken in reaction to theseevents.

Typically, the datastore is initialised at the beginning of the day'soperations, and is based on the latest version of short-term planning.At the end of the day, it provides a detailed status report of actualproduction.

Information on events, control actions and the monitoring of theseactions is kept in order to retrace and audit the normal running ofthe service and any disruptions, as well as to supply elements thatcan be added to control tactics and strategy libraries.

The datastore contents correspond to the "Monitoring and control"chapter/package in Transmodel, in addition to the "Service timesand service modifications" part of the "Travel information"chapter/package for the "Provide travel information" function.Information concerning the changing status of infrastructure andvehicles could also be included.

4.2 Public transportnetwork descriptiondatastore

This datastore contains the description of the public transportnetwork, as defined by the service objectives established by thepublic transport authority. It includes details of all transport lines,stops/stations, service times and frequencies, and consequently allrolling stock and personnel requirements. It also contains dataenabling fixed and on-board equipment to be configured, incorrespondence with the cartography and road repositories.The contents of the datastore largely correspond to the "Networkdescription" chapter/package in Transmodel, in addition to basicdata from the "Travel information" chapter/package.

4.3 Public transportservice planningdatastore

This datastore contains long- and short-term planning data forregular, special and demand-responsive public transport services, aswell as strategies to be implemented according to traffic conditionsor specific service modification recommendations.

The contents of the datastore correspond to the followingTransmodel chapters/packages: "Tactical planning components","Vehicle scheduling", "Driver scheduling", "Times and versions","Rostering" and "Personnel service management".

Certu – 2009 15


4.4 Maintenance plandatastore

This datastore contains maintenance planning information forrolling stock, fixed equipment and infrastructure:

- periodic and preventive maintenance;

- occasional maintenance, works.

For a given maintenance operation, the following information isavailable: the object concerned (vehicle, fixed equipment,suspended or modified stops/stations, etc.), the maintenance status(forecast, planned, completed, cancelled, etc.), the planned andactual date, time, duration and location (depending on themaintenance status and the nature of the object concerned).

4.5 Rolling-stockresources datastore

This datastore contains information on the characteristics andplanned availability of rolling stock, particularly passenger transportvehicles and shared vehicles.

Specific "Public transport" elements concerning vehicles can befound in the "Vehicle characteristics" part of the "Vehiclescheduling" chapter/package of Transmodel.

4.6 Human resourcesdatastore

This datastore contains information on the characteristics andplanned availability/absence of staff, particularly drivers.

Specific "Public transport" elements concerning human resourcescan be found in the "Employee" and "Driver" classes of Transmodeland their related objects.

4.7 Shared vehicleservices datastore

This datastore contains data relating to shared vehicles (offers,requests, supply–demand matching, etc.).



3.3 Functions

3.3.1 Functional sub-area: Organise and plan public transport services

4.1.1 Manage publictransport networkdescription data

This low-level function manages data describing the public transportnetwork, as defined by the service objectives requested by the publictransport authority, and match this data to elements in thecartography and road repositories (in order to define lines andstops/stations) and to service time and frequency elements (in orderto determine the resources required). The data concerned is mainlythat of the "Network description" chapter/package of Transmodel,and the basic data from the "Travel information" chapter/package.

4.1.2 Configureequipment

This low-level function is responsible for configuring fixed and on-board equipment. It develops configuration scenarios for downloadonto this equipment.

4.1.3 Collect publictransport planning data

This low-level function collects all the input data needed for publictransport service planning.

4.1.4 Plan publictransport services

This low-level function allocates human and physical resources toidentified and dated public transport services.Typically, the following planning stages are identified: vehiclescheduling, crew scheduling, rostering and service orders. Theprocess is developed over different timescales, including: - long-term planning, which leads to a theoretical basic repository;- short- and medium-term planning, which states projected services,together with the associated human and physical resource allocation.This low-level function covers: - regular services; - special services (e.g. school services); - demand-responsive services (i.e. services that are planned but onlyprovided on request shortly before – typically, the day before travel).

4.1.5 Disseminateplanning data

This low-level function disseminates data from service planningactivities – in particular, details of services provided in the short andmedium term, and of driver and vehicle schedules.

4.1.6 Provideinformation on thetransport network

This low-level function provides information on the part of thetransport offer that concerns the network: this includes networktopography and static offer data, in relation to the cartography androad repositories.

4.1.7 Provideinformation ontransport service times

This basic provides information on the part of the transport offer thatconcerns service times: timetables for lines (regular and DRTservices, special services of interest to a wide range of people),temporary or permanent modifications to regular service times, etc.

Certu – 2009 17


3.3.2 Functional sub-area: Monitor, control and inform passengers

4.2.1 Collect fielddata

This low-level function continuously collects data from fieldequipment and various partners, and disseminates it by all availabledata links.

4.2.2 Compilepassengerinformation

This low-level function compiles and formats messages to bedisseminated to passengers, based on data produced by the "Controlpublic transport" function. It assesses the target of these messages interms of network topography elements (stops/stations, etc.) andequipment (fixed and on-board signs, speakers, etc.).For times relating to the arrival of the next vehicle, thecompilation/formatting of the message is relatively simple; theproblem lies more with determining which equipment to use for whicharrivals.For traffic disruptions, decisions relating to message addressing aremore complex and cannot necessarily be solved in a totally automaticmanner. Under these circumstances, compiling and formattingmessages is more complicated and, in some cases at least, may alsorequire human intervention.For example, a control action such as the modification of a run willgive rise to a delay warning in both text and vocal form; the messagemust then be disseminated in text and vocal form in the vehicleconcerned, and in a slightly different text form at the stops/stationsconcerned.

In addition, this low-level function is able to manage the display ofinformation either on printed documents or on dynamic equipment(generally at stops/stations) and in vehicles.

4.2.3 Compileinformation forpublic transportauthorities

This low-level function compiles activity information, aimed at thepublic transport authority.

4.2.4 Disseminateoperating data

This low-level function disseminates operations information aimed atproduction units and fixed and on-board equipment, in real time, nearreal time or deferred time.Work involves three different phases:

data acquisition, either by access to datastores or by reception of ad-hoc messages; physical addressing operations and possible formatconversions; dissemination to addressees.

It also disseminates all information required by the systems of partneroperators, notably relating to service modifications that they must takeinto account.



4.2.5 Control publictransport

The aim of this low-level function is to take decisions enabling publictransport services to run as smoothly as possible, by adapting them tosituations on the ground, and to monitor the implementation of thesedecisions.

Along with the "Monitor public transport" function, it constitutes anessential work tool for controllers.

Circumstances requiring action shall be identified by the "Monitorpublic transport" function and by links with actors on the ground, inthe form of public transport control messages or direct exchanges withdrivers (by radio or possibly video). The continuous assessment ofperformance also enables intervention needs to be identified.Decisions take the form of control actions, communicated to driversvia control messages and/or via direct exchanges.

A control action may be the reduction, creation or cancelling of aparticular run, or the allocation of an additional vehicle, etc. See also"Control actions" in the "Monitor and control" chapter/package ofTransmodel.

Another way of ensuring efficient control is to ask traffic managers toapply a given scenario or strategy in order to facilitate the circulationof public transport vehicles. Traffic managers can then adapt theconfiguration of traffic control equipment. Typically, some or alltraffic signal controllers will receive instructions to give priority toany trams detected.

This function naturally has vehicle indicator forecast aids at itsdisposal (notably for estimated arrival times at stops/stations), inaddition to performance assessment aids. It may also have variousdecision-making assistance tools at its disposal, such as control tacticsand strategy libraries or control action simulators.

4.2.6 Monitor publictransport

This low-level function ensures the real-time monitoring of thelocation and status of vehicles on the network, and detects deviationsin relation to theoretical arrival times. It also monitors the status ofon-board equipment.

4.2.7 Communicatewith drivers

This low-level function enables a human system operator (usually acontroller) to communicate directly with drivers, by means of radio orpossibly monodirectional or bidirectional video.

Certu – 2009 19


3.3.3 Functional sub-area: Manage human and physical resources

4.3.1 Managepersonnel

This low-level function centrally manages the operating personnel ofpublic transport services, particularly drivers.

4.3.2 Managerolling stock

This low-level function manages the turnover of rolling stock, by keepingup-to-date records on the state, lifespan and maintenance of vehicles andtheir equipment.

4.3.3 Planmaintenance

This low-level function optimises maintenance plans by adopting relevantcriteria and by taking into account incidents observed on vehicles orinfrastructure. Maintenance planning must also take account of plannedworks on the network.

4.3.4 Monitorinfrastructure andfield equipmentstatus

This low-level function continuously monitors roadside and fixedequipment. It makes it possible to rapidly identify incidents, anomalies ordeteriorations, and produce the corresponding reports.

4.3.5 Monitorrolling-stockstatus

This low-level function checks that rolling stock and on-board equipmentare functioning correctly, on a day-to-day basis. This enables the regulardetection of any incidents, anomalies or deteriorations, the production ofcorresponding reports, and the rapid reporting of consequences in termsof vehicle availability.

4.3.6 Assessmaintenanceneeds

This low-level function assesses rolling stock, equipment andinfrastructure maintenance needs. Based on the characteristics of thesephysical resources, and of breakdowns and incidents reported, itestablishes a list of maintenance intervention requirements, relating torepairs, upkeep, servicing or checks.

4.3.7 Monitormaintenanceinterventions

This low-level function is responsible for monitoring and coordinatingmaintenance operations. Their implementation is the responsibility of the"Intervention team" terminator.

This function lists maintenance intervention request on the basis of theMaintenance Plan. In return, it receives intervention reports specifyingthe maintenance work carried out.

It disseminates the list of planned or ongoing maintenance operations tothe vehicle depot (where it is acted upon), as well as to the networkdescription management function, in case the planned maintenance workshould affect transport planning, e.g. roadworks that deteriorate orprevent the use of certain sections of road, suspension of stops/stations,temporary or permanent changes to stop/station locations, etc.

4.3.8 Disseminateresource data

This low-level function disseminates data relating to human resources(drivers) and physical resources (vehicles). This data primarily describesthe characteristics of these resources, as well as their current and forecastavailability.

4.3.9 Monitorpersonnelavailability

This low-level function monitors personnel availability (drivers). Itcollects notifications on absences and the return to work of personnel;these absences/returns are rapidly reported via updates of the Humanresources datastore.



3.3.4 Functional sub-area: Organise shared services

4.4.1 Collect offersand requests forshared vehicleservices

This low-level function receives information from users andpredetermined shared-vehicle offerers, regardless of their presence orotherwise on the network. The means that may be used includeconventional mail, e-mail, telephone, SMS and websites.The information in question may consist of specific requestsaddressed to DRT services or shared vehicles, or carpooling and car-sharing service offers.

4.4.2 Organisevehicle-sharing

This low-level function organises vehicle-sharing.Here, the term "vehicle-sharing" is used in the broadest sense of theword, and includes both free and pay services.

This may include: shared vehicles (without driver) made available tothe public by public and private organisations or individuals (bikes,cars, etc.); carpooling; taxis for individual or collective use; ambulance services.

The organisation for vehicle-sharing includes:

recording service offers made by organisations or individuals; recording user requests; matching supply and demand; subsequently organising contact between shared-vehicle offerers andthose requesting transport. Matching may involve numerous actions, ranging from simplypassing on selective contact lists, through to organising bookings.

4.4.3 Provideinterested parties withsupply–demandmatches

This low-level function addresses specific information to individualusers or shared-vehicle offerers, regardless of their presence orotherwise on the network. The means that may be used includeconventional mail, e-mail, telephone, SMS and websites.

3.3.5 Functional sub-area: Manage FA4 shared data

4.5.1 Collectreference data

This low-level function collects reference data from a centralisedrepository (FA9).

4.5.2 Prepare data forhistorisation

This low-level function extracts data from the different datastores ofFA4 and prepares it for historisation in FA9. This preparation processmay involve several stages: ensuring consistency, transformation,aggregation, consolidation, calculations, etc.

Certu – 2009 21


4 Standards and legal requirements

The "Standards" object is used in ACTIF to model and illustrate where and when officialstandards, de facto standards, good practices and recommendations are to be applied. Thenotion of a "standard", as understood in the context of NF (French standards) and AFNOR(the French standards organisation), has therefore been considerably extended in order toalso take account of "prestandards" or technical specifications, Work Items on which there isalready an applicable or applied consensus, good practices, laws or simple recommendations.

Standards may concern functions, datastores, messages and terminators.

4.1 TRANSMODEL

This is a European conceptual data model based on the Entity/Association formalism andwhich is targeted at public transport companies, as well as service providers with links totransport and user information. Transmodel can be used as a medium for the development ofsoftware applications, as well as their communication or integration within an informationsystem. Version 5 deals with aspects of generic modelling of networks, user information,operation monitoring, multimodality (in addition to the bus mode that was predominant inprevious versions, other modes such as trams, light metros and trolleybuses have also beentaken into account).

It can be viewed at www.sitp.its.setec.fr (in UML format) and at www.transmodel.org

4.2 RDS-TMC

RDS (Radio Data System) enables the dissemination of data simultaneously with an FMradio broadcast, using the subcarrier of the radio frequency concerned.

TMC (Traffic Message Channel) is a European standard developed by CEN with the aim ofspecifying the coding, delivery (using the FM-RDS subcarrier) and decoding of trafficinformation. 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 dictionaryfor the dissemination of road information.

4.4 DSRC

DSRC (Dedicated Short-Range Communications) is a short-range communications standardwith a spectrum allocated in the 5.8–5.9 GHz range. It enables data exchanges between fixedbeacons and mobile receivers over short distances. This technique is used in particular forelectronic contactless toll collection. However, it may also be used in other contexts, such aspassenger information.

Certu – 2009 25


4.5 TPEG

TPEG (Traffic Protocol Expert Group) is an ISO/CEN standard for the transmission oftraffic and travel information (TTI). One of the characteristics of TPEG is the multiplicity ofits carrier systems (DAB, internet), whereas RDS-TMC is only supported by the subcarrierof 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 andaeroplanes.

4.6 TRIDENT

This European prestandard uses the TRANSMODEL model. It defines the data exchangeformats and services for public transport and road transport. These exchange specificationsconcern theoretical information and event typology. It is based on the following in particular:

a model for peer-to-peer exchanges between suppliers and customers with subscriptionpossibilities;

an object-oriented data model written in UML, based on the Transmodel v. 4.1conceptual data model (developed for public transport);

an exchange format in the form of XSD schemas (XML Schema Definition, where XMLstands for Extensible Markup Language).

4.7 Geographical repository

This concerns the different repositories that are used to geolocate an object and map it onto acartographic medium. Note: today, all data relating to public service provision – particularlytransport – must be published on geographical media, in accordance with the INSPIREdirective.

This means referencing each element of a public transport offer (e.g. road-based elementsaccording to the road repository, and other public transport services with lines andstops/stations) on cartographic media: hence the need to identify and use systems ofcoordinates resulting from recognised national or international standards (Lambert andLambert II, WG84, etc.) and widely used geolocation processes (GPS, Galileo, etc.).


Documents

Assistance for the design of interoperable ... - its-actif.org · ACTIF presentation and usage documents – FA4 1 Introduction 1.1 About this presentation document Assistance for