S03- BackOffice Architecture specifications ITS Standerd-Del/S032015V1_ITxP… · Backoffice...

S03- BackOffice Architecture specifications

Release S03-2015V1.0

This document defines the detailed specifications of ITxPT BackOffice architecture.

S03-2015V1 BackOffice Architecture Specifications 2/59

Content

1 ITxPT BackOffice architecture ......................................................................................................... 4 1.1 Generic BackOffice Network architecture ................................................................................. 4

PTO IP Network ................................................................................................................... 4 PTA IP Network ................................................................................................................... 5 Upper private IP Network .................................................................................................... 7

1.2 Onboard and BackOffice hierarchical structure overview ......................................................... 7 1.3 Backoffice architecture synoptic view ....................................................................................... 8 1.4 Backoffice components ........................................................................................................... 10

Network components ......................................................................................................... 10 AVMS Backoffice ............................................................................................................... 10 Integrator multi-AVMS server ............................................................................................ 10 Passengers Information back-office .................................................................................. 10 Integrator Passengers information back-office .................................................................. 10 Remote Diagnostic back-office .......................................................................................... 10 Central database ............................................................................................................... 10

1.5 Backoffice services ................................................................................................................. 11 Overview ............................................................................................................................ 11 Interfaces ........................................................................................................................... 11 Vehicle connectivity monitoring service/tool ...................................................................... 11 Vehicle master database ................................................................................................... 12 DRS - Device registration service ...................................................................................... 12 Vehicle inventory database ............................................................................................... 12

2 Vehicle-central AVMS data protocol .............................................................................................. 14 2.1 Objectives and Study logic ...................................................................................................... 14

Detailed objectives............................................................................................................. 14 Not considered in this scope ............................................................................................. 14 Study logic ......................................................................................................................... 14

2.2 Efficient use of bandwidth ....................................................................................................... 14 Vehicle GID ........................................................................................................................ 14 Vehicle session .................................................................................................................. 15 Other defaults .................................................................................................................... 15

2.3 Data exchange ........................................................................................................................ 16 Required information from the vehicles Uplink .................................................................. 16 Required information from the AVMS Downlink ................................................................ 30

2.4 IP Protocol ............................................................................................................................... 35 2.5 Message protocol .................................................................................................................... 36

Frame Structure ................................................................................................................. 36 2.6 Events - Logical positioning .................................................................................................... 37

2.6.1 Minimal Workflow...................................................................................................... 37 2.6.2 Recommended Workflow ......................................................................................... 37

2.7 Events - Physical location ....................................................................................................... 38 Minimal Workflow ............................................................................................................... 38

2.8 Testbench ............................................................................................................................... 38 2.8.1 Testbench Protocol choices ..................................................................................... 38

3 Backoffice Dynamic Passenger Information .................................................................................. 40 3.1 Objectives & Study logic ......................................................................................................... 40

Detailed objectives............................................................................................................. 40 3.1.2 Study logic ................................................................................................................ 40

3.2 Regional DPI Architectures ..................................................................................................... 40 3.3 3.3 DPI Services ..................................................................................................................... 42

Overall requirements ......................................................................................................... 42


Planning a trip .................................................................................................................... 43 3.3.2.1 Planning a trip with estimated time ............................................................................ 43

3.3.2.2 Door to door trip planning .......................................................................................... 43

3.3.2.3 Planning a trip in real time ......................................................................................... 43

3.3.2.4 End trip facilities ......................................................................................................... 44

3.3.2.5 How to buy tickets?.................................................................................................... 44

Checking stop times .......................................................................................................... 44 Checking detailed information ........................................................................................... 44 Checking information after a trip ........................................................................................ 45

3.4 Data shared by systems.......................................................................................................... 45 Stop Points ........................................................................................................................ 46 Connection data ................................................................................................................. 46

3.4.2.1 Connection links ........................................................................................................ 46

3.4.2.2 Connection rules ........................................................................................................ 46

3.4.2.2.1 With DatedJourney & StopPoint ID of fetcher ....................................................... 47

3.4.2.2.2 Without DatedJourney & StopPoint ID of fetcher .................................................. 47

3.4.2.2.3 Connection link inside one line ............................................................................. 48

3.4.2.3 Connection monitoring ............................................................................................... 49

3.5 Data Exchange: DPI in SIRI .................................................................................................... 49 Flat description .................................................................................................................. 49 Data provision content by level of object ........................................................................... 49

3.5.2.1 Lines .......................................................................................................................... 49

3.5.2.2 StopPoint ................................................................................................................... 50

3.5.2.3 JourneyPattern inside lines ....................................................................................... 51

3.5.2.4 DestinationDisplay inside lines .................................................................................. 51

3.5.2.5 Connection links ........................................................................................................ 51

SIRI content by level of object ........................................................................................... 51 3.5.3.1 Vehicle Journey Info .................................................................................................. 51

3.5.3.2 Journey Pattern Info .................................................................................................. 52

3.5.3.3 x Vehicle Journey ...................................................................................................... 53

3.5.3.4 x Call .......................................................................................................................... 55

3.5.3.5 TargetedInterchange ................................................................................................. 58


1 ITxPT BackOffice architecture

1.1 Generic BackOffice Network architecture

Since Public Transport has different organization architectures in different countries, it adds some

complexity to the basic Back Office Network architecture. Because of this there will be several different

solutions to get the required connectivity.

WAN links should be use to interconnect Back Office Networks. Encrypted VPN is only required when

using Internet for the WAN link.

Router functionalities that allow this network to transfer messages with other Networks must be

included.

General recommendations concerning termination of VPN tunnels from vehicle are to:

Choose as “high” termination point in the architecture as possible.

Change only termination point when the vehicle change registered owner.

Change of (for example) AVMS system can be done without changing VPN termination point

and instead routing traffic at Back Office level (There has to be a network connection between

the two Back Offices).

PTO IP Network

Each operator must have its own private network called “Operator IP Network” to interconnect their

systems. It will allow functionalities to exchange data between them at operator level, with others

back-office networks and with vehicles “Onboard IP Network”.

Components on this network should be link with IP medium.

“Operator Network” may use Internet for interconnection.

WAN links should be use to interconnect all operator systems connected by different networks

(Internet, private network, operator LANs …). Encrypted VPN is only required when using Internet for

the WAN link.

In order to allow exchange between operators, Router functionalities that allow this network to connect

with “PTA IP Network” must be included.

In case “non IP” network (radio link like TETRA without IP support …) is used to send vehicle status

and small messages to “Operator IP Network”, a “non IP network bridge“ needs to be implemented.

“Gateway” functionalities with this network should be included (out of ITxPT scope).

This type of solutions are exactly what we want to avoid for the future, and is NOT to see as “state of

the art”, although it may be a “path of migration” for countries with poor long-range wireless

infrastructure (e.g. like GPRS, 3G, CDMA).

This picture shows the aimed hierarchical structure for “PTO IP Network”:


Figure 1- PTO IP network

Systems expected to be connected on “PTO IP Network” are the following:

All vehicle gateways waited to be linked on this network must be connected.

WAN links to several “sites” like PTA and Operator Networks may be connected

WAN links to mobile operator Networks (ex. GPRS/EDGE/UMTS/3G/4G)

WAN links to Wireless AP’s

Several DPI and bus stop systems may be connected on the network.

A DDNS like functionality system should be implemented.

At least one of each following server should be implemented, however several others may be

implemented if needed (i.e. In case the operator has several suppliers for the same

functionality,…)

Backoffice systems (like AVMS, DPI, Remote diagnostic)

An PTO “emergency” system may be implemented.

Others systems not identified at this time.

PTA IP Network

This private network called “PTA IP Network” may be used to synchronize bus public transport (but

also other type of public transport may be link) at a PTA level. In this way, several operators working

for the same PTA should share data to propose more efficient data/services to passengers

Components on this network should be link with IP medium.

“PTA IP Network” may use WAN links for interconnection.


A WAN links should be use to interconnect all operator systems connected by different networks

(Internet, private network, operator LANs …). Encrypted VPN is only required when using Internet for

the WAN link.

In order to allow exchange between several PTAs in the same region, router functionalities that allow

this network to connect with an upper network (Regional, National ...) may be included.

This picture shows the aimed hierarchical structure for “PTA IP Network”:

Figure 2- PTA IP network

Systems expected to be connected on “PTA IP Network” are the following:

All vehicle gateways waited to be linked on this network must be connected.

All WAN links to “Operator IP Network” of operators working for this PTA should be allowed to

connect on the network.

A WAN link to “Upper IP Network” may be connected.

A DDNS like functionality system should be implemented.

An AVMS common back-office system and database for coordination of operators working for

this PTA may be implemented.

A vehicle diagnostic database for coordination of operators’ vehicles working for this PTA may

be implemented.

A Passenger Information common back-office system and database for coordination of

operators working for this PTA may be implemented.

A PTA “emergency” system may be implemented.

Others systems not identified at this time.


Upper private IP Network

Upper private networks may be added (i.e. At regional level, country level, Europe level, etc.…).

They should be defined like “PTA network”. Aim of those private networks should be to centralize and

deliver scattered data on upper and lower network in order to OR to bring more efficient data / services

to passengers.

1.2 Onboard and BackOffice hierarchical structure overview

Picture below shows an overview of the aimed hierarchical structure for bus BackOffice and bus

onboard IP networks:

It can be divided in three main parts:

BackOffice IP networks: it includes all networks that are not in a vehicle, such as “Operator

Network”, “PTA Network”. It may be upper ones such as “Regional Network” or “National Network” or

“Europe Network”.

On-board IP networks: it includes all embedded operating networks (“On-board IP network” and ”On-

board backbone IP network”).

On-board to Back-office IP Link: it includes all media types (and associated devices) used for the

communication between back-office and vehicles.

All these networks must use IP as standard protocol for communication.

These networks must use secured protocol to avoid losing data, losing reliability on data, intrusion on

networks…

Figure 3- Overview of IP networks hierarchical structure


1.3 Backoffice architecture synoptic view

Picture below shows a synoptic view, including National organization, PTA and Operator and their

opposite Back-office applications.


Figure 5- Distributed architecture for VPN termination and Backoffice systems

Figure 4- Centralized architecture for VPN termination and Backoffice systems


1.4 Backoffice components

Network components

There are several network components in a back-office network. They permit Systems on a network to

send data to systems on another network. This includes LAN functionalities like a firewall...

AVMS Backoffice

Operator AVMS back-office associated with several vehicles and infrastructures.

Integrator multi-AVMS server

PTA, regional, or upper network server associated with a common database that allows to collect data

from all accessible network and to give access to data to all authorized networks.

Passengers Information back-office

Operator passengers’ information back-office associated with several vehicles and infrastructures.

Integrator Passengers information back-office

PTA, regional, or upper network server associated with a common database that allows to collect data

from all accessible network and to give access to data to all authorized networks.

Remote Diagnostic back-office

Server which collects health state data from vehicles (and may be infrastructure components) and

provide useful data for diagnostic and maintenance purposes. Data may be accessed by other

systems using a web service interface.

Central database

PTA, regional, or upper network common database used by central back-office to save data, or for

sharing common data that are needed at one or more back-office levels. Due to network security, web

service interfaces are recommended.

An example of such database can be a Master Vehicle database that shall use the NOPTIS interface

to exchange data with other systems.


1.5 Backoffice services

Overview

Figure 6- Backoffice service overview

Interfaces

XML:

Noptis DII, status: existing

VLS, status: content TBD, try to use existing standard..

DILS, status: content TBD, try to use existing standard..

VMI, status: content TBD, try to use existing standard..

SNMP:

Typical SNMP traps

% off fleet is offline

% off fleet has been offline more than 3 days

% off fleet has repeatedly battery alarm

Vehicle connectivity monitoring service/tool

A system that continuously is monitoring the status and the connections with all Vehicle gateways.


Centralized distribution system of software for the gateway.

Centralized remote configuration for gateway.

Remote wake-up (when main switch is off) for devices on a vehicle. Typically used for maintenance

and remote updates. An interface for access from other systems need to be specified. (included in

DILS)

Vehicle master database

On the same Back-office as the DRS and Gateway monitoring system a Master Vehicle database is

needed.

It’s here the “physical vehicle ID” (e.g. VIN code, globally unique ID) connects to the “logical vehicle

ID” (e.g. Vehicle GID) and Gateway ID and vehicle IP address.

The interface to receive the basic vehicle information from the master vehicle database must follow

Transmodel, and NOPTIS DII/DOI Production Resources structure. (e.g. Noptis_DII3_ver_F, see ref.

6.1.5) for scheduled system import and export of data.

For systems with real-time demands on the information a web service interface shall be used, in

picture above named VLS interface.

DRS - Device registration service

Registries / joins vehicles “physical ID” and “Logical ID” and changes of “communication address” in

the Vehicle Master database and updates DNS.

Registries devices found in a vehicle in the inventory database. This information originates from the

DNS-SD based device and service inventory within the vehicles.

The information stored in the database shall be accessible via the VLS interface.

Vehicle inventory database

A database that contains basic information about all devices and services found in vehicles..

Other BO systems may retrieve data using a web service (in picture above named “DILS”).

Specify content and interface.

Content for devices is typically:

Type of device

Model

Manufacturer

Serial number

Software version

Hardware version

Current status (ok/nok/errorcode…)

IPv4/IPv6/MAC/ <other> address

DHCP enabled

IP subnet/gateway if static configured.

Connected sub-device(s), (Yes/No, details in xml file)

Device specific attributes ‘screen on right side of driver with 5 buttons and 480x800 resolution,

16 colors, no touch screen’.

Details of the content for devices will be found in S01- Onboard Architecture Specifications, and in the

xml schema for device inventory.

http://wiki.itxpt.org/index.php?title=S01-_Onboard_Architecture_Specifications


Content for services

Type of service

Name

Manufacturer

Serial number

Software version

Protocol version

Current status (ok/nok/errorcode…)

IPv4/IPv6/MAC/ <other> address

Port(s)

Service specific attributes ‘-free text-’.

Details of the content for services will be found in S01- Onboard Architecture Specifications, and in the

xml schema for service inventory.

There is a need for a web service interface for other back-office systems to access data from the

inventory database.

http://wiki.itxpt.org/index.php?title=S01-_Onboard_Architecture_Specifications


2 Vehicle-central AVMS data protocol The main objective is the design of a basic AVMS data protocol on a wireless IP network to allow the

communication of a central AVM system with vehicles equipped with on-board devices from different

suppliers. This basic data protocol must include as a minimum the vehicle identifier (VIN) and the

current location. Based on this data the central AVMS operation should be possible independent from

the vehicle equipment.

For other applications like DPI or remote diagnostic, we assume that back-office to onboard

communication can be managed by each application itself without raising interoperability issue.

2.1 Objectives and Study logic

Detailed objectives

The following detailed objectives can be derived:

Define the messages and data that need to be exchanged between the vehicle and AVMS

Define the IP protocol to be used

Define the detailed protocol for exchanging the data

Create a test bench demonstrating (a subset of) the defined protocol.

Beyond these objectives it is considered as “nice to have” if the protocol could be used for non IP

based networks. However, non IP based communication is not considered in this document.

Not considered in this scope

Standardisation of a data provision interface for providing the definition of the schedules to the vehicle

is not considered as part of this task. It is taken as a precondition for this task that the vehicle and the

central AVMS have synchronised and consistent data.

Standardisation for data provision interface should be supported by NeTEx CEN group.

Study logic

The study logic follows the above objectives:

Define the messages that need to be exchanged

Define the IP protocol to be used

Define the message structure (frame of the protocol)

Define the details for every piece of data to be exchanged including the events that should

trigger the messages

Define the test bench

Develop the test bench.

2.2 Efficient use of bandwidth

Vehicle GID

Using GIDs to identify different objects is helpful when integrating data from different sources. At the

same time there is often a need to reduce the size of messages sent over radio-links.

An observation is that the leading part of GIDs will be identical for most objects sent from a vehicle. A

useful concept is therefore to send this part of the GID once per session and exclude it from the bulk

of messages, while only including the significant part of the GID in each message.


So the idea is to send a number of default-values at the start of a session. After that only the parts of

the GID that differs from previously sent default values are sent. The defaults should be sent in

advance as part of a technical logon.

Vehicle session

The vehicle logs on with the vehicle GID and the central system is then providing a session ID. All

subsequent data exchanges can then be based on the session ID only.

This session ID should be unique and consistent at least from one technical logon until a technical

logoff. Often this value does not need to be sent explicitly as data, but can instead be resolved from

lower levels in the communication, such as a radio-address. If that is possible then this session ID

(underlying radio-address or similar) will be tied to the vehicle GID at technical logon. If no such “no-

cost” identifier is available then the complete vehicle GID is used as a Session ID.

The session ID is linked to the destination system the vehicle is communicating. If the vehicle switches

to another destination system (e.g. moving from one PTA system to another), it has to logon again in

order to obtain a new session.

Other defaults

Analogue it is possible to use session defaults for:

Scope of Drivers

Scope of Blocks

Scope of Duties

Scope Service journeys

Scope of Stops

For the explanation of what the default could be, we assume that for blocks the following GID structure

is used.

Country code (three digits alpha) (mandatory)

GID Type (four digits numeric) (mandatory)

PTA (three digits optional)

Operator (four digits optional)

Block number (five digits mandatory)

A block could have in this case the GID SE.9031001002212345. In this case the default scope of

blocks for the vehicle logging could be SE.90310010022.

The session defaults are linked to the session id of the vehicle, i. e., when a logon to e.g. a block is

received, in the central system the default can be derived from the session id. The defaults linked to

the session need to be stored on the vehicle. If a default needs to be changed, e.g. the vehicle is now

driving blocks of another operator; the defaults need to be overwritten. Alternatively the full GID can be

transmitted instead of negotiating new defaults.

In case an operator A is lending a vehicle temporarily to another operator B, the vehicle GID should

not change but the other defaults will because the vehicle is now operating blocks of operator B and

also it might be operated by employees of operator B or even operator C.


2.3 Data exchange

Required information from the vehicles Uplink

The following minimum information is required in the AVMS from the vehicle:

Generally we want to know when an event occurred so a time-stamp should be included in all

messages.

It must be possible to determine from which vehicle a message was sent. We propose to work

with a session ID.

There are two types of messages:

Request: The message requires a reaction from the central system and therefore needs to be

acknowledged. The acknowledgement can be implicit by the response or explicit when

appropriate. In case of missing acknowledgement, the request needs to be repeated.

Report: The message does not require an acknowledgement from the central system. Also,

there is no monitoring of the reception of such a message. Provision needs to be made within

an implementation of a system to be able to work correctly also in case of report messages

lost.

Below follows the details for each of the different message:

Technical logon request: Logon a vehicle in the AVMS technically, i.e. reporting to AVMS that the

vehicle is switched on and available through radio. The message needs to be acknowledged by the

central system with a technical logon response. Response message from central system (rmfcs):

Technical logon response

Attribute Type Optional Comment

MessageType U-Int-8 No Fixed value 11 = Technical logon

VehicleGID Char-20 No GID of the vehicle

Application identifier Char 16 No

Technical logoff report: The technical logoff implies also every other logoff.


MessageType U-Int-8 No Fixed value 16 = Technical logoff


Default GID value request: Session defaults for specific GIDs are negotiated with the central system

Rmfcs: Central ack


MessageType U-Int-8 No Fixed value 12 = Default value request

Default value type U-Int-8 No

GID type

41 = block

61 = duty

15 = service journey

16 = dead run

51 = employee

11 = line

22 = Stop points

25 = journey pattern points

Default value lenght U-Int-8 No Lenght of the following default

Default value varchar No Details of the default

It is the vehicle´s decision which of these defaults is transmitted to the central system. As long as the

central system has not acknowledged a default, the full GID needs to be used in the following

messages.

Employee logon request


MessageType U-Int-

8 No Fixed value 21 = Driver logon with default

Employee

number

U-Int-

24 No

If a default is negotiated with the central system, the number can

be used

The range needs to fit for the provided default, i.e. if the

remaining part of the number deducted from the GID is 5 digits,

the number should not exceed 99.999

Employee Role U-Int-

8 No


MessageType U-Int-8 No Fixed value 22 = Driver logon with GID

Employee GID Char-20 No If no default is negotiated the GID needs to be used.

Employee Role U-Int-8 No


Duty logon request


MessageType U-Int-

8 No Fixed value 22 = Duty logon with number

Duty Number U-Int-

24 No

If a default is negotiated with the central system, the number

can be used


remaining part of the number deducted from the GID is 5 digits,

the number should exceed 99.999

Journey within

the duty

U-Int-

8 No

Index of journey including the dead runs. If 0 is supplied, the

field is not used.


MessageType U-Int-8 No Fixed value 32 = Duty logon with GID

Duty GID Char-

20 No If no default is negotiated the GID needs to be used.

Journey within the

duty U-Int-8 No

Index of journey including the dead runs. If 0 is supplied,

the field is not used.

Block logon request


MessageType U-Int-

8 No Fixed value 23 = Block logon with number

Block Number U-Int-

24 No

If a default is negotiated with the central system, the number

can be used


remaining part of the number deducted from the GID is 5

digits, the number should exceed 99.999

Index of trip within

the block

U-Int-

8 No

Index of journey including the dead runs. If 0 is supplied, the

field is not used.



MessageType U-Int-8 No Fixed value 33 = Block logon with GID

Block GID U-Int-

24 No If no default is negotiated the GID needs to be used

Index of trip within the

block U-Int-8 No

Index of journey including the dead runs. If 0 is supplied,

the field is not used.

Block logon request


MessageType U-Int-

8 No Fixed value 24 = Service Journey logon

Journey Number U-Int-

24 No

Unique number in scope of the technical line number on a

certain date.

Default does not need to be negotiated as it is in scope of

the line.

LineNumber U-Int-

16 No

Technical line number according to the numbering known

to, and unique within, the transport authority. Not

necessarily the same line number as is shown to the

public.

If default is negotiated

PlannedStartPointGID Char-

20 Yes Journey pattern point GID

PlannedStartTime U-Int-

24 Yes Seconds after midnight UTC passing 24 hours

PlannedEndPointGID Char-


PlannedEndTime U-Int-


NumberOfPoints U-Int-

16 Yes Number of journey pattern points within the trip



MessageType U-Int-8 No Fixed value 34 = Service Journey logon with GID


24 No


certain date.


the line.

LineGID Char-

20 No If no default is negociated the GID needs to be used

PlannedStartPointGID Char-


PlannedStartTime U-Int-


PlannedEndPointGID Char-


PlannedEndTime U-Int-




The optional fields could be used by the central AVMS to countercheck if the data provision on the

vehicle is in sync with the central AVMS. Although it is obvious that by using first, last stop and no of

stops within the journey the countercheck might not deliver 100% certainty on synchronised data, it is

considered that the check will deliver sufficient certainty about synchronised data with a minimum of

data exchange. If the optional fields are used, they must all be included.

Dead Run logon request


MessageType U-Int-8 No Fixed value 25 = Dead run logon

Dead Run Number U-Int-24 No A default needs to be negociated.

It is expected to be the same as the block default.


MessageType U-Int-8 No Fixed value 35 = Dead run logon with GID

Dead Run Number Char-20 No If no default is negociated, the GID needs to be used.


Line Logon request not including time

Used in fallback mode for being able to drive within the system but without being visible on the DPI. It

is mainly used for maintenance, driving school or other special service.


MessageType U-Int-

8 No Fixed value 26 = Line logon request

PatternNumber U-Int-

24 No Pattern number. Must be in scope of the line.

LineNumber U-Int-

16 No

Technical line number according to the numbering known to, and

unique within, the transport authority. Not necessarily the same

line number as is shown to the public.



MessageType U-Int-8 No Fixed value 36 = Line logon request

PatternNumber U-Int-24 No Pattern number. Must be in scope of the line.

LineGID Char-20 No If no default is negotiated the GID needs to be used

Logical Logoff request


MessageType U-Int-

8 No Fixed value 29= Logoff

Type of logoff U-Int-

8 No

23 = block

22 = duty

24 = service journey

25 = dead run

21 = employee

26 = line

If block logoff is sent, it includes also logoff from duty and service

journey or dead run


Localization report

Logical position on journey Var1: Position of the vehicle within the journey


MessageType U-Int-

8 No Fixed value 41 = Logical pos on journey Var1

Last Past Journey Pattern Point U-Int-

32 No

Could be a stop point, a timing point (not stop

point) or another pattern point within the

journey or dead run pattern


DrivenDistanceFromLastPastPoint U-Int-

16 No

Meters driven since passing the Last Journey

Pattern Point

TimeStamp U-Int-

24 Yes

Seconds since midnight. The time stamp might

be omitted if the radio system provides a

sufficient level of service that messages are

delivered real time or within a few seconds


MessageType U-Int-

8 No

Fixed value 51 = Logical pos on journey Var1

using GID

Last Past Journey Pattern Point

GID

Char-

20 No

Could be a stop point, a timing point (not stop

point) or another pattern point within the

journey or dead run pattern


DrivenDistanceFromLastPastPoint U-Int-

16 No

Meters driven since passing the Last Journey

Pattern Point

TimeStamp U-Int-

24 Yes

Seconds since midnight. The time stamp

might be omitted if the radio system provides

a sufficient level of service that messages are

delivered real time or within a few seconds


Logical position on journey Var2: Position of the vehicle within the journey


MessageType U-Int-

8 No Fixed value 42 = Logical pos on journey Var2

Next Journey Pattern

Point

U-Int-

32 No

Could be a stop point, a timing point (not stop point) or

another pattern point within the journey or dead run pattern


DrivenToNextPoint U-Int-

16 No Meters left to the next Pattern Point

TimeStamp U-Int-

24 Yes

Seconds since midnight. The time stamp might be omitted if

the radio system provides a sufficient level of service that

messages are delivered real time or within a few seconds


MessageType U-Int-

8 No Fixed value 52 = Logical pos on journey Var2 using GID

Next Journey Pattern

Point GID

Char-

20 No


another pattern point within the journey or dead run

pattern


DrivenToNextPoint U-Int-

16 No Meters left to the next Pattern Point

TimeStamp U-Int-

24 Yes

Seconds since midnight. The time stamp might be omitted

if the radio system provides a sufficient level of service

that messages are delivered real time or within a few

seconds


Arrival at Stop: Arrival at last stop includes implicit the end of trip


MessageType U-Int-

8 No Fixed value 43 = Logical pos Arrival at Stop

Journey Pattern

Point

U-Int-

32 No

Could be a stop point, a timing point (not stop point) or another

pattern point within the journey or dead run pattern


TimeStamp U-Int-

24 Yes

Seconds since midnight. The time stamp might be omitted if the

radio system provides a sufficient level of service that messages

are delivered real time or within a few seconds


MessageType U-Int-

8 No Fixed value 53 = Logical pos Arrival at Stop using GID

Journey Pattern

Point GID

Char-

20 No




TimeStamp U-Int-

24 Yes

Seconds since midnight. The time stamp might be omitted if

the radio system provides a sufficient level of service that

messages are delivered real time or within a few seconds

Departure from Stop


MessageType U-Int-

8 No Fixed value 44 = Logical pos Departure from Stop

Journey Pattern

Point

U-Int-

32 No




Dwell Time at

Stop

U-Int-

16 No

Seconds from Arrival at to Departure from Stop

Zero means the stop has been passed without stopping

‐1 indicates that the field is not used.

TimeStamp U-Int-

24 Yes






MessageType U-Int-

8 No Fixed value 54 = Logical pos Departure from Stop using GID

Journey Pattern

Point

Char-

20 No




Dwell Time at

Stop

U-Int-

16 No

Seconds from Arrival at to Departure from Stop

Zero means the stop has been passed without stopping

‐1 indicates that the field is not used.

TimeStamp U-Int-

24 Yes




Physical location (e.g. GPS, Galileo, xy-coordinates) could be used as heart beat


MessageType U-Int-

8 No Fixed value 45 = Physical Location

Longitude U‐Int‐

24 No

1/1000° Minutes – WGS84

e.g. 9° 10.1234 Minutes: ((9*60)+10.1234)*1000

== > 550123

Accuracy best than ~1.8 m

Real Accuracy ~1.8 m x cos (latitude)

Latitude U-Int-

24 No

1/1000° Minutes – WGS84

Accuracy ~1.8 m

Additional

attributes 8 bit No

Bit 0: 0 = East, 1 = West

Bit 1: 0 = North, 1 = South

Bit 2: 0 = GPS pos. invalid, 1 = GPS valid

Bit 3: 1 = TimeStamp present, 0 = TimeStamp not present

Compass

bearing

U-Int-

16 No

Decimal degrees from 0 north to 359° counted in clockwise

direction.

TimeStamp U-Int-

24 Yes





Off route / On route again request: Vehicle leaving the planned journey pattern


MessageType U-Int-8 No Fixed value 46 = Off route state

Off‐route status U-Int-8 No 0 = on route

1 = off route

Driver to dispatcher messaging request:


MessageType U-Int-8 No Fixed value 56 = Driver predefined message

Message Nr U-Int-

16 No

Message number if predefined. If the message text is transmitted,

the message number to be only used by the central system for

acknowledgement purpose.

Message Text varchar Yes Message text of the pre defined message

RTT, PRTT, Silent alarm request (ack including RTT type required)


MessageType U-Int-8 No Fixed value 57 = RTT

RTT Type U-Int-8 No

Type of RTT

1 = Silent alarm / Emergency

2 = PRTT

3 = RTT

Occupancy / Passenger loading message by driver request (ack)


MessageType U-Int-8 No Fixed value 58 = Occupancy driver

Passenger load U-Int-8 No

Load enumeration value

1 = no more seats

2 = full

3 = passengers left behind

4 = seats available Etc.


Occupancy / Passenger loading automatic report (no ack)


MessageType U-Int-8 No Fixed value 59 = Occupancy automatic

Passenger load U-Int-8 No Load in percent

Passenger counting report (no ack)


MessageType U-Int-

8 No Fixed value 60 = Passenger counting

Boardings U-Int-

8 No Number of passengers boarded

Alightings U-Int-

8 No Number of passengers alighted

Journey pattern point

number

U-Int-

32 No


another pattern point within the journey or dead run pattern

If default is negotiated.


MessageType U-Int-

8 No Fixed value 61 = Passsenger counting using GID

Boardings U-Int-

8 No Number of passengers boarded

Alightings U-Int-

8 No Number of passengers alighted


number GID

Char-

20 No


another pattern point within the journey or dead run

pattern



Driver Response report: Driver response for received text message (pre defined or free text) from

AVMS. Included here can also be the answer of the driver “yes” or “no”


MessageType U-Int-

8 No Fixed value 64 = Driver ack

Reference to the

received message

U-Int-

8 No

The number received with the message to be used in order

to be able to securely identify which message the driver

responded to

Driver response U-Int-

8 No

0 = No

1 = Yes

Remote diagnostic alarms (ack depending on message): Messages showing the status of vehicle

devices and reporting alarms of vehicle devices (e.g. ticket vending machine defect). Usually, on-

board remote diagnostic computer will send alarms to remote diagnostic back-office, which is able to

analyse these alarms and plan maintenance action if required. However, when a vehicle changes

operator, the link between the on-board remote diagnostic computer and the remote diagnostic back-

office may be lost. In this case, there might be a need to define a message to transmit through AVMS

alarms provided by the on-board remote diagnostics device. The content of this message has to be

defined by task 2.3.4.


MessageType U-Int-8 No Fixed value 65 = Remote diagnostics alarm

Priority U-Int-8 No

Message text varchar No

Running state / vehicle state request:

Ignition state

Main switch state

Traction information (coupling of vehicles)


MessageType U-Int-8 No Fixed value 66 = Running state

State information U-Int-8 No

Bits for

Ignition

Main switch

Coupled master

Coupled slave


Vehicle coupling request: Order of the vehicles in the coupling:


MessageType U-Int-8 No Fixed value 67 = Vehicle coupling

Coupling partners number U-Int-8 No Number of vehicles being coupled in total

including the reporting vehicle

First vehicle in the coupling

(vehicle GID)

Char-

20 No

Second vehicle in the coupling

(vehicle GID) Char-

20 No

Third vehicle in the coupling

(vehicle GID) Char-

20 No

etc

Ack report: Acknowledgement of received information from AVMS (technical ack). This message is

only needed in case a radio system is used that is providing an integrated framing (e.g. Tetra). With

the here defined IP based protocol, the acknowledgement will be done on framing level (see section

Error! Reference source not found.)


MessageType U-Int-

8 No Fixed value 70 = Vehicle ack

Request type that is

acknowledged

U-Int-

8 No

Message type of the central system request

123 = Technical Logon Request

124 = Service Journey logon by central system

126 = predefined message from central system

127 = Free text message from central system

128 = Dispatcher Acknowledgement for driver

message

129 = Voice call initiation

130 = Interchange/Connection Instruction for the

driver

Other: Container for additional not standardised information

Message types 71 to 120


Required information from the AVMS Downlink

The following minimum information is required in the vehicle from the AVMS.

Ack response: Acknowledgement of received request from vehicle (technical ack).


MessageType U-Int-8 No Fixed value 121 = Central ack

Request type that is acknowledged U-Int-8 No

Message type of the vehicle request

16 = Technical Logoff report ack

21 = Employee logon ack

22 = Duty logon ack

23 = Block logon ack

24 = Service journey logon ack

25 = Dead run logon ack

26 = Line logon ack

29 = Logical logoff ack

Technical logon response (used as ack for the technical logon of the vehicle) Response to the

technical logon of the vehicle


MessageType U-Int-8 No Fixed value 122 = Technical Logon Response

Session id U-Int-16 No Session id that has to be used by the vehicle during the session

Technical logon request: This message is used to ask a vehicle to logon technically. This could be

used in case of communication from an unknown vehicle or if a session is detected by the central

system


MessageType U-Int-8 No Fixed value 123 = Technical Logon Request


Forced logon/logoff by dispatcher request: Journey assignment or de-assignment of a vehicle by a

dispatcher.


MessageType U-Int-

8 No Fixed value 124 = Service Journey logon by central system


24 No


certain date.


the line.

0 indicates logoff

LineNumber U‐Int‐

16 No




public.

0 indicates logoff


PlannedStartPointGID Char‐


PlannedStartTime U‐Int‐


PlannedEndPointGID Char‐


PlannedEndTime U‐Int‐





MessageType U-Int-

8 No

Fixed value 125 = Service Journey logon with GID by

central system


24 No


certain date.


the line.

0 indicates logoff

LineGID Char-

20 No




public.



0 indicates logoff


PlannedStartPointGID Char‐


PlannedStartTime U‐Int‐


PlannedEndPointGID Char‐


PlannedEndTime U‐Int‐




Pre-defined messaging: ID of the dispatcher selected pre-defined message with or without driver

acknowledgement


MessageType U-Int-8 No Fixed value 126 = predefined message from central system

Message Nr U‐Int‐

16 No

Message number if predefined. If the message text is transmitted,

the message number to be only used by the vehicle for

acknowledgement purpose.

Message Text varchar Yes Message text of the pre defined message

Free text messaging: Text message typed in by the dispatcher with or without driver

acknowledgement


MessageType U-Int-8 No Fixed value 127 = Free text message from central system

Text Length U‐Int‐8 No Byte length of the following text.

Message Text varchar No Message text


Dispatcher Ack request: Dispatcher Acknowledgement of received predefined text message by the

AVMS


MessageType U-Int-

8 No

Fixed value 128 = Dispatcher

Acknowledgement for driver message

Message Nr U‐Int‐

16 No

Message number of the driver message. This number to be used

by the vehicle to identify which predefined message has been

acknowledged by the dispatcher.

Voice call response/initiation: Message to respond to or initiate a voice call including listen in on a

silent alarm


MessageType U-Int-8 No Fixed value 129 = Voice call initiation

RTT Type U-Int-8 No

Type of RTT

1 = Silent alarm / Emergency

2 = PRTT

3 = RTT

Call Type U-Int-8 No

Type of the call:

1 = Single call

2 = Line call

3 = Fleet call

4 = Other group call

Options (Talk group, Phone number) U-Int-8 Yes

Bits for further options

Bit 1 = Phone number included

Bit 2= Talk group

Phone number Char-20 Yes Phone number for call back option

Talk group Char-20 Yes Talk group identifier


Interchange/Connections instructions or information request: Instructions to wait for or end a

connection and other connection relevant information


MessageType U-Int-8 No Fixed value 130 = Interchange/Connection

Instruction for the driver

LineNumber U‐Int‐16 No Technical line number the driver has to wait for


Waiting Time U‐Int‐8 No Waiting time in minutes

Journey pattern point number U‐Int‐32 No Point where to wait



MessageType U-Int-8 No

Fixed value 131 = Interchange/Connection

Instruction for the driver using GID for journey pattern

point

LineNumber U‐Int‐

16 No

Technical line number the driver has to wait for




GID

Char-

20 No

Point where to wait




Instruction for the driver using GID for Line

Line GID Char-20 No Technical line GID the driver has to wait for



Journey pattern point number U-Int-32 No Point where to wait





Instruction for the driver

Line GID Char-20 No Technical line GID the driver has to wait for



Journey pattern point GID Char-20 No Point where to wait


Localization request: Request to the vehicle to send its location (logical, physical or both)


MessageType U-Int-8 No Fixed value 134 = Dispatcher request for localisation

Type U‐Int‐8 No

Type of required localisation

1 = GPS

2 = Logical

3 = GPS and Logical

Dispatch actions: Not included but may be included on a later stage


Other: Container for additional not standardised information


2.4 IP Protocol

The task of this chapter is to identify the basic network protocol to be used for the vehicle – AVMS

data protocol. The following two options are available

TCP/IP

UDP

TCP/IP

Advantages:

Handshake

Ack on TCP level

Retransmission part of protocol

Order of packets secured

Disadvantages:

Next packet out of transmit sequence send only when previous packet acknowledged

Large overhead if only small packets are transmitted (high costs in public networks)

Number of open sessions might be an issue


UDP

Advantages:

Open connection. Fire and forget

Less traffic

Less overhead due to no handshake (more cost efficient)

Better real time performance due to immediate transmit rather than handshake first

Disadvantages:

Ack and retransmission on application level required

Peaks of packets may arise with buffer overflow

UDP will be used. Reason for this decision is to provide for the possibility to use the same protocol in a

private APN environment without VPN between the vehicle and the central AVMS.

2.5 Message protocol

Frame Structure

The following telegram structure is proposed using an End to End Framing common to all telegrams.

The specific telegram is then part of the Body. The codification of the telegrams is big endian.


Protocol Type Char No Type of the protocol. Always "E" (for EBSF)

Protocol

Version U-Int-8 No Version of the protocol. For the test bench 1 to be used.

Length U-Int-8 No Length of the complete telegram

Options U-Int-8 No

Optional fields are added to the framing – 8 bit particular from

left to right

7: Sequence number

6: Timestamp seconds

5: Timestamp milliseconds (not including the seconds)

4: Vehicle session id

3:

2: Ack sequence number

1: Ack required (0 = no ack, 1 = ack). Using this bit, the protocol

user can request an ack for any message.:

0: CRC

Sequence

number U-Int-8 Yes Sequence number identifying every single message.

Timestamp

seconds

U-Int-

32 Yes Seconds since 1970, ISO C

Timestamp

milliseconds

U-Int-

16 Yes Milliseconds



Vehicle

session id

U-Int-

16 Yes

Session id provided by the central system as response to the

technical logon. As long as there is no session id provided, 0 to

be used. If there are other means, e.g. the ip address, to identify

the vehicle, the session id can be omitted.

Ack sequence

number U‐Int‐8 Yes

Sequence number of the telegram that is acknowledged with the

current telegram.

CRC U‐Int‐

16 Yes CRC – CRC type to be defined

Body Varchar No Telegram content as per the sections above

2.6 Events - Logical positioning

2.6.1 Minimal Workflow

1. Assign the vehicle to the vehicle journey it will work.

2. Report each departure from a stop, or passage of a stop, along the route as they take

place.

3. Sign off the vehicle from the vehicle journey when the vehicle journey is completed.

4. Repeat 1 through 3.

2.6.2 Recommended Workflow

1. Report that the vehicle is manned (Duty, Driver, Block).

2. Assign the vehicle to the vehicle journey it will work, if it has not already been signed on.

3. Make an advance assignment of the following vehicle journey.

4. Report when arrival to a stop is due.

5. Report that the vehicle has arrived at the stop.

6. Report that the vehicle departs from or passes the stop.

7. Repeat 4, 5 and 6.



10. Report that the vehicle is unmanned.

There could also be additional reports between step 2 and 8.

Step 3, advance assignment of the next journey, might be omitted in some systems and when the next

vehicle journey is not known.

Step 4, reporting that a vehicle is due to arrive at a stop, should only be included if it is essential to

give this type of information, such as in a subway station.

Step 5, reporting that a vehicle has arrived at a stop, might be omitted at the cost of losing arrival

information.

Step 1 and 10, reporting that the vehicle is manned or is unmanned, might be omitted in some

systems.


2.7 Events - Physical location

Minimal Workflow

There is a minimum requirement for reports from an AVL-system concerning a vehicle working journeys:

1. Assign the vehicle to the vehicle journey it will work.

2. Report position when doors are opened or closed and at certain time intervals.



2.8 Testbench

It is the common understanding of the task group that not all messages can be demonstrated in the test bench. However, proof of principle is envisaged to be demonstrated. To achieve this, the following messages have been pointed out to proof the principle:

Technical logon by the vehicle, with specific ack defined

Technical logoff by the vehicle

Physical location of the vehicle

Free text message from central AVMS to the vehicle

With this test bench setup it will be possible to demonstrate the interaction of a vehicle AVMS from

one supplier (supplier A) with the central AVMS of another supplier (supplier B). It will be possible to

follow the vehicle of supplier A on the map of the central AVMS of supplier B. Additionally, as an eye-

catcher, it will be possible from the central AVMS of supplier B to send free text instructions to the

vehicle of supplier A. The message should be displayed on the driver screen.

2.8.1 Testbench Protocol choices

Frame content

Protocol type ‘E’

Protocol version 1

Optional fields

SeqNumber & ack bit Yes

Timestamp sec No

Timestamp millisec No

Vehicle session id No

CRC No

Technical logon request (n°11 uplink)

Ack message: Yes (by Technical logon response message)

Application identifier: proposal 1 – onboard EBSF AVMS


Technical logon response (n°122 downlink)

Ack message:

No Session id: 0

Technical logoff report (n°16 uplink)

Ack message: Yes

Physical location (n°45 uplink)

Ack message: No

Optional fields

TimeStamp No

Free text messaging request (n°127 downlink)

Ack message: Yes

Text codification: UTF-8

Ack report (n°70 uplink)

Ack message: No …

Used for downlink message 127

Ack response (n°121 downlink)

Ack message: No …

Used for uplink message 16

General remark for ack mechanisms: ack messages are exchanged without ‘functional’ process (no

repetition rules defined)


3 Backoffice Dynamic Passenger Information

3.1 Objectives & Study logic

Detailed objectives

The goal is to better integrate passenger information on different levels in a multimedia environment at

several locations and using the specified SIRI protocol (Standard Interface for Real time Information)

and the IFOPT model (Identification of Fixed Object in PT).

Detailed objectives are:

Define the DPI services which should be offered to customers

Identify types of regional DPI architecture

Define the IFOPT & SIRI implementations to support those services & architecture, identify

missing services and data in current SIRI version.

Some of these objectives are covered by other tasks:

Multi-application Driver Screen

Application messaging for Multi-application Driver Screen

3.1.2 Study logic

This study logic is proposed:

Collect the different types of regional DPI architectures

o Describe the architectures

o Identify if specific needs are involved by architectures.

Define the DPI services which should be offered to customers � Identify the different types

and content of DPI

Identify the relevant data required.

Describe the overall data model and data flow required, i.e. Define the IFOPT & SIRI

implementation

o In accordance to the services

o In accordance to the architecture

Define the IFOPT elements to use – identifying rules

Define the SIRI services and information involved, as mandatory and optional.

Some requirements will be defined and exported to other tasks:

Service requirements vs. on-board IP architecture

AVMS installations

Vehicle data requirements

3.2 Regional DPI Architectures

Passenger information should be consistent regardless of the source of information, hence there is a

need for a coordinated passenger information at a regional level. It is possible to either manage DPI

media on a regional level or in each local AVMS, or possibly a mix.


However, in order to embrace DPI at regional level, we observe a tendency to have systems where:

AVMS and DPI are distinct applications

All information are integrated in a regional DPI database (central ‘hub’).

The regional DPI database is fed by producer systems as AVMS, specific control centres, etc., and is

used by information systems which manage the presentation of information for their driven media /

device.

From an Integrator perspective, where one wants consistent coordinated information in all media, it is

recommended that the source of data always is the central hub, regardless if the DPI-system resides

in the local AVMS or not, and if the data is produced in the same AVMS as or not.

Figure 7- DPI Regional Architecture

This view can be enhanced with the current state of systems used to provide DPI at a local level,

completed by the recent adding of multimodal services, in order to provide:

Regional view of transport with new high level of services media and devices

Local operator devices like way sides and on-board signs able to provide multimodal

information, if required on specific connection points.


Figure 8– DPI Regional Architecture where local DPI systems enhance multimodal information

These two types of architectures have to be considered to propose exchanges allowing:

To shift to an architecture where DPI and AVMS are totally separated (including a total

separation of operator sign infrastructures moved to regional transport authorities?),

To maintain the services provided by an operator through its own sign infrastructures, in case

of disruption of the link with the other systems (loosing external information could by accepted,

but not losing its own services).

3.3 3.3 DPI Services

Overall requirements

From the traveler point of view, expected DPI services are to be able to:

plan a trip

obtain departure or arrival times for stops

obtain detailed information along his trip

obtain information after his (missed) trip (acclaims)

These services could be provided by different types of devices and systems:

Customer management team / Device MMI

Non interactive / interactive devices

Fixed / on-board / mobile devices

To have an efficient information, these services should use and be able to give information which can facilitate or permit the trip (boarding assistance, wheelchair ramp, cycles allowed …) and should use and be able to give information about disturbing events (diversion, disruption …).


As everyone can expect, these services should provide information which reflect the current network state. Expected times, changed aimed times and journey route changes should be used and provided to travelers.

In addition to the core systems used usually to provide DPI (AVMS), external systems could be used to improve the accuracy of the information used, as Infrastructure Applications (Road management), which can act on travel times (snow / ice running conditions …). For DPI applications, the impact of these external applications is applied through timetables and disruption messages provided by AVMS systems.

Planning a trip

Planning a trip could be the first step of a traveler. This type of service is growing larger from operator network level to regional level.

3.3.2.1 Planning a trip with estimated time

At least, to plan a trip at a regional level, an application should have

The timetables for the expected day

The connection links between stops

Dated timetables should provide information (by journey) identifying vehicle features (wheelchair ramp…) and service features (cycles allowed …).

Estimated timetable should provide information (by journey) identifying vehicle features (wheelchair ramp …), service features (cycles allowed) and disruptions.

Other attributes may be required to build a trip, like cost, earth protection efficiency… Which level of network description could support these attributes? For instance, regarding the cost model for a region, standalone tickets, subscribes:

Due to the high complexity of a regional view for ticket cost rules, partners have identified that

it is the role of another application to calculate the cost of a specific trip inside a regional

network.

Hence there is a need for an interface with an external database/application

Even if other application calculates a travel cost, trip application should be able to give the

information.

3.3.2.2 Door to door trip planning

In case of door to door trip planning, access points to public transport should be used when the stop access is not on external public area.

3.3.2.3 Planning a trip in real time

The choice of the timetables used for this service should be made carefully.

Estimated timetables: they give a good estimation for the next minutes.

Short Term Change timetables: they give a good estimation for the next hours.

It could be a good choice to use pessimistic timetables to plan a trip in real time conditions.

Travel planning applications should handle disturbances, for instance, when a part of the initial

travel is not possible (line interruption …).


3.3.2.4 End trip facilities

It was identified that passengers may check specific facilities linked with stops when planning a trip. For instance, tourists may require to find a “bike rental service” at the end of their bus travel.

3.3.2.5 How to buy tickets?

This type of information could be of interest for travelers. Information on ticket sale can be attached to different kind of objects:

Vehicle

Station

Point of interest

Web site

…

Checking stop times

To provide stop times, an application should have:

Estimated times for stops,

Relevant lines and destinations.

In order to provide a complete service, vehicle features, service features and disruptions information should be available.

In any case, call times should be characterized:

Planned

Aimed

Estimated

Actual

It may be better to qualify estimated times: disruption level, quality level.

Different levels of information may be required by users, depending on their needs:

Departure time (users willing to catch a bus) / arrival time (users waiting for someone arriving

by bus)

Check in / check out times: earlier departure / latest arrival

Stop platform in case of a multi-platform stop (general need)

…

Checking detailed information

To provide detailed information along the trip, it could be important to obtain specific to user profile / detailed / general information linked to:

Lines

Stops

Connection links

Different levels of information may also be linked to these transport objects. For instance:


Operational level: traffic state (line), closed sections (stops), waiting time (connections) …

Facility level: journey facilities, stop facilities, connection area map …

Touristic / city information / advertising levels: multimedia content linked to lines, stops,

geographic areas.

These kinds of information could / should be linked to specific attributes to be able to provide them according to user profile.

Checking information after a trip

It was identified by partners that this need is covered through statistic and record functions of a bus network management system. For this reason, this need is not analyzed by this Back-office Dynamic Passenger Information working group. For specific DPI purposes, actual times are identified as required in chapter “Checking stop times”.

3.4 Data shared by systems

In case of a regional architecture with central database, the data used by systems could be separated in two categories:

The atomic data owned by one system (e.g. a planned timetable)

The atomic data owned (shared) by several systems (e.g. a common stop point).

We talk about atomic data, because, for instance, two different systems may provide different planned timetable for two different lines. These two atomic data are owned each one by a different system (we will talk about ‘Multi Unique Producer’).

For a stop point, the same stop may be “owned” by several systems (‘Multi Owners’). In this case, it is necessary to define which system updates the “reference” data and provides them (‘Identified Producer’). However, in case of a loss of connection, a system should be able to work without the proper “reference” data.

http://wiki.itxpt.org/index.php?title=File:Figure_11_-_Data_shared_by_DPI_systems.png


Figure 9 - Data shared by DPI systems

Stop Points

Sharing Stop Points between several systems can be handled by using two layers of attributes:

a common layer

a proprietary layer.

By default, a system using a stop point but not defined as the “Identified Producer” can create its own definition of a new stop point at the common and proprietary layers, and update the common layer when the stop point is provided in the central HUB.

The common layer handles the attributes shared by systems for DPI purposes, for example names (normal, long, short, Text to Speech), multimedia contents…, and his external ID.

The proprietary layer handles the attributes not shared by systems, for example specific geographic description for localization purpose, internal ID…

In order to provide a global regional or national DPI, with a consistent level of information, it may be necessary to use a unique DPI system as “Identified Producer” for all Stop Points.

Connection data

3.4.2.1 Connection links

A connection link is the infrastructure definition of a connection.

The definition of connection links follows the same principle as for stop points: we will use a common layer with an initial definition and a later update when the data is provided by the central HUB.

The usual information of a connection link are:

Feeder Point

o Stop Point ID

Fetcher Point

o Stop Point ID

Transfer time between the feeder and the fetcher points

Many transfer times may be identified, for example peak-hour transfer time …

DPI information related to connection link (optional)

o Textual

o Area map for travel assistance

o Moving facilities or restrictions for travelers with disability

o …

Sometimes a connected point is defined for non-managed transportation mode like a bicycle rent park.

3.4.2.2 Connection rules

A connection rule is a dated information which defines one or many planned connections, between a feeder (distributor) and a fetcher (taker).

There are two ways to identify connection rules, from the fetcher point of view:

Using the DatedJourney ID and the StopPoint ID of the fetcher


o these information are known by the producer of the definition

Without these information

o these information aren’t known by the producer or the definition is not published

Connection rules may also be used to define inter-lines connection capabilities, without trying to manage nor protect connections. For this kind of use, the second model of rules should be used, without time reference.

3.4.2.2.1 With DatedJourney & StopPoint ID of fetcher

A planned connection could be defined by

DatedJourney ID and StopPoint ID of the fetcher

Line ID, Direction(s), and StopPoint ID of the feeder

Window time

Maximum Waiting time.

The diagram shown below is used to identify possible connection rules.

Figure Erreur ! Pas de séquence spécifié.– Diagram allowing to identify connection rules

3.4.2.2.2 Without DatedJourney & StopPoint ID of fetcher

A planned connection is defined by

Date / Time validity

Line ID, Direction(s), and StopPoint ID of the fetcher

Line ID, Direction(s), and StopPoint ID of the feeder

Window time

Maximum Waiting time

In this case, Date/Time validity and Timetables of a Stop Point for a specific Line / Direction allow to identify the fetcher(s) (many fetchers depending on Time validity), without an initial specific DatedJourney ID.

http://wiki.itxpt.org/index.php?title=File:Figure_12_-_Diagram_allowing_to_identify_connection_rules.png


These two kinds of definition permit each system to follow the connection with stop timetables of the other system, and provide time information.

A specific case is to define line to line connection without management / protection connection: a maximum waiting time is set to specific value identifying this case.

3.4.2.2.3 Connection link inside one line

It may be useful to define a connection link inside the same line (and perhaps at the same stop point), for instance for a line with a fork.

Figure 10 – Connection link within the same line

Connection link definitions:

Feeder point:

o Stop Point ID = pX

o Line ID = 1

Direction = S>West

Fetcher point:


o Line ID = 1

Direction = W>North

And

Feeder point:


o Line ID = 1

Direction = N>West

Fetcher point:


o Line ID = 1

Direction = W>South

Connection information displayed on the vehicles (static information)


Running direction W>North or W>South: no information

Running direction S>West: connection to Line 1A

Running direction N>West: connection to Line 1B

3.4.2.3 Connection monitoring

In order to provide information about the protection processed by the fetcher system, a monitored connection object must be provided by the fetcher system containing at least the connection protection state.

3.5 Data Exchange: DPI in SIRI

Flat description

The communication model of SIRI is designed as a flat model. This means that there is not an object database used as a reference when exchanging information, therefore the content and detail of an object have to be exchanged each time this object is used.

Example: while sending data concerning many journeys, using the same pattern: each stop point information and attributes are transmitted for each journey.

This model is used today with no bandwidth problem. However the need of increasing the perimeter and detail level of DPI data linked to transportation objects (lines, patterns, stop points, connections …), requires to change this model in order to to exchange:

Data provision at the level of each object type. Data provision are low-frequency exchanges

which define object attributes and references. Object references will then be used in higher

frequency data exchanges.

SIRI object definition containing mostly object references. .

Example:

data provision: definition of stop points, exchanged only when a stop is created or modified.

data provision: exchange definition of lines, exchanged only when a line is created or

modified.

data provision: exchange definition of patterns, with reference to stop points and lines.

Exchanged only when a pattern is created or modified.

Vehicle journey including stop point, line and pattern references, exchanged daily.

We will define below data provision for DPI common objects and attributes and SIRI object

definitions.

Data provision content by level of object

Fields defined below are often not available in SIRI interface Mandatory fields

3.5.2.1 Lines

LineGID Name elements published to travelers:

o Short public known Label


o Name

o Short name

o Long name

o Voice announcement sequence – could be:

TTS Text

Voice file references

=> This element may be provided for different languages Public Line Code (SMS services by example) Transport Mode Code LineOwnerGID Display attributes

o Line Icon (file reference – different sizes)

o Textual rules for line (foreground – background - font)

Additional attribute extension list – could be for specific profiles

o Type – Content – Profile

3.5.2.2 StopPoint

StopPointGID (used as StopPointRef) Name elements published to travelers:

o Name

o Short name

o Long name

o Platform name

o Voice announcement sequence – could be:

TTS Text

Voice file references

=> This element may be provided for different languages Public StopPoint Code (SMS services by example) Transport Mode Code StopPointOwnerGID Orientation (degrees) Geographical position Access point reference Area map file reference Facility monitoring services Additional attributes Extension list – could be for specific profiles


o Type – Content – Profile

Lots of other attributes or information could be linked to stop points (external DB or not): ticket vending machines, points of interest, specific services…

3.5.2.3 JourneyPattern inside lines

JourneyPatternGID Origin place info (many fields) Destination place info ? (many fields) Direction reference Stop point list

o StopPointRef

o DestinationDisplayRef

Arrival platform name & boarding activity and Departure platform name & boarding activity for calls are consider as potentially real time modified fields.

3.5.2.4 DestinationDisplay inside lines

DestinationDisplayGID Destination info (many fields) Via: 0 to * Via place info (many fields) External ref: 0 to * [ devide code / destination code ]

3.5.2.5 Connection links

It may be of interest to add some attributes at connection link level

o maps

o voice help TTS text / files

SIRI content by level of object

Below are defined different objects linked to DPI information, their attributes are underlined in yellow.

3.5.3.1 Vehicle Journey Info

This object describes information at the level of a Pattern (not depending on a journey) and at the level of a Journey (time dependent).

Service Info ::: 0:1 ServiceInfoGroup See below ServiceInfoGroup

Service End

Point

Names

OriginRef 0:1 ⇒Journey-

PlaceCode

Identifier of the origin of the journey; helps

to identify the vehicle journey on arrival

boards.

OriginName 0:1 NLString Name of the origin of the journey; helps to

identify the vehicle for the public.


OriginShortName 0:1 NLString Short name of the origin of the journey;

helps to identify the vehicle for the public.

Via 0:* +Structure Description of a via point on a journey.

PlaceRef 0:1 ⇒Journey-

PlaceCode Identifier of the via point of the journey.

PlaceName 0:1 NLString Name of a via point of the journey, helps to

identify the line.

PlaceShortName 0:1 NLString Short name of a via point of the journey,

helps to identify the line.

DestinationRef 0:1 ⇒Journey-

PlaceCode

Identifier of the destination of the journey;


DestinationName 0:1 ⇒Journey-

PlaceCode

Name of the destination of the journey;

help to identify the vehicle for the public

DestinationShort-

Name 0:1

⇒Journey-

PlaceCode

Name of the destination of the journey;


Journey

Info

VehicleJourney-

Name 0:1 NLString Name of the Vehicle Journey.

JourneyNote 0:1 NLString Additional descriptive text associated with

the journey.

End Times

HeadwayService 0:1 xsd:boolean

Whether this is a Headway Service, that is

one shown as operating at a prescribed

interval rather than to a fixed timetable.

OriginAimed-

DepartureTime 0:1 xsd:boolean Timetabled Departure Time from Origin.

DestinationAimed-

ArrivalTime 0:1 xsd:boolean Timetabled Arrival time at Destination

The ServiceInfoGroup provides optional data about descriptive attributes of a vehicle journey

Service

Info

OperatorRef 0:1 ⇒OperatorCode Operator of the Journey.

ProductCategoryRef 0:1 ⇒Product-

CategoryCode

Product Category of the journey - subdivides

a transport mode E.g. express, local.

ServiceFeatureRef 0:* ⇒ServiceFeature-

Code

Classification of the service into arbitrary

Service Feature(s), E.g. school bus.

VehicleFeatureRef 0:* ⇒VehicleFeature-

Code

Feature(s) of the Vehicle. E.g.

'suitableForWheelChairs'.

3.5.3.2 Journey Pattern Info

JourneyPatternRef 0:1 ⇒Journey-PatternCode Identifier of the Journey Pattern that

the Journey follows.


Journey

Pattern

Info

VehicleMode 0:1

air; bus; coach; ferry;

metro; rail; tram;

underground

Mode of transportation such as bus,

rail, etc.

RouteRef 0:1 ⇒RouteCode Identifier of Route that Journey follows.

PublishedLineName 0:1 NLString Name or Number by which the line is

known to the public.

DirectionName 0:1 NLString

Name of the relative direction the

vehicle is running along the line, for

example, "inbound" or "outbound”.

ExternalLineRef 0:1 ⇒LineCode

Alternative Identifier of Line that an

external system may associate with the

journey.

3.5.3.3 x Vehicle Journey

Many objects linked to Vehicle Journeys are used: DatedVehicleJourney EstimatedVehicleJourney TargetedVehicleJourney MonitoredVehicleJourney

The MonitoredVehicleJourney element is described below, this element integrates the most important part of the DPI information handled by SIRI for a specific journey.

MonitoredVehicleJourney +Structure

Provides real-time information

about the vehicle journey along

which a vehicle is running.

Vechicle LineRef 0:1 ⇒LineCode Identifier for the line. DetailLevel:

minimum

Journey

Identity

DirectionRef 0:1 ⇒DirectionCode

Identifier of the relative direction

the vehicle is running along the

line, for example, "in" or "out",

“clockwise”. Distinct from a

destination.

DetailLevel: minimum.

FramedVehicle-

JourneyRef 0:1

+FramedVehicle-

JourneyRef-

Structure

Reference to the dated vehicle

journey that the vehicle is running.

Unique with the data horizon of the

service. See SIRI Part 2.

DetailLevel: basic.

Journey-

Pattern-Info ::: 0:1

JourneyPattern-

InfoGroup

See SIRI Part 2

JourneyPatternInfoGroup.

DetailLevel: normal.

Vehicle-

Journey-Info ::: 0:1

Vehicle-

JourneyInfoGroup

See SIRI Part 2

VehicleJourneyInfoGroup.



Disrupt-

ionGroup ::: 0:1 DisruptionGroup

See SIRI Part 2 DisruptionGroup.


Journey-Prog-

ressinfo ::: 0:1

JourneyProgress-

InfoGroup

See SIRI Part 2

JourneyProgressInfoGroup.


Journey-Prog-

ressinfo ::: 0:1

JourneyProgress-

InfoGroup

See SIRI Part 2

JourneyProgressInfoGroup.


Train-Block-

Part

TrainBlockPart 0:1 TrainBlockPart-

Structure

Associates Stop Visit with a part of

a train: used when trains split or

merge. DetailLevel: normal.

NumberOf-BlockParts 0:1 xsd:positiveInteger

Total number of block parts

making up the train of which this is

part.

TrainPartRef 0:1 ⇒TrainPartCode Identifier of train block part.

PositionOfTrainBlockPart 0:1 NLString

Description of position of

TrainBlockPart within train. Used

to guide passengers to find the

train block part. E.g. 'Front four

coaches'

OperationalInfo ::: 0:1 OperationalInfo-

Group

See SIRI Part 2

OperationalInfoGroup.

BlockRef &

CourseOfJourneyRef:


VehicleRef: DetailLevel: basic

Calling Pattern

PreviousCalls 0:1 +Stucture

Information on stops called at

previously, the origin stop and all

intermediate stops up to but not

including the current stop. Should

only be included if the detail level

was requested.

DetailLevel: calls.

PreviousCall 0:* +Stucture

Information on a stop called at

previously. See PreviousCall

element.

MonitoredCall 0:1 +Stucture Information about a call at stop.

See MonitoredCall element.

OnwardCalls 0:1 +Stucture

Information on calls at the

intermediate stops beyond the

current stop, up to and including

the destination. Should only be

included if the detail level was


requested.

DetailLevel: calls.

OnwardCall 0:* +Stucture Information on an onward stop call.

See OnwardCall element.

IsCompleteStop-

Sequence 0:1 xsd:boolean

Whether the call sequence is

simple, i.e. represents every call of

the route and so can be used to

replace a previous call sequence.

Default is false.

3.5.3.4 x Call

Many objects linked to Calls are used:

DatedCall

EstimatedCall

PreviousCall

MonitoredCall

OnwardCall

They have similar structures, PreviousCall element is lore light.

MonitoredCall +Structure Information about a call at current

stop.

Stop

Identity

StopPointRef 0:1 ⇒StopPoint-Code

Identifier of the stop. Defaults to that

of context i.e. that specified on

Monitoring Point.

VisitNumber 0:1 VisitNumber-Type

For journey patterns which involve

repeated visits by a vehicle to a stop,

the VisitNumber is used to

distinguish each separate visit.


Order 0:1 xsd:positiveInteger

For implementations for which the

overall Order within journey pattern is

not used for VisitNumber, (i.e. if

VisitNumberIsOrder is false) then

can be used to associate the overall

Order as well if useful.

StopPointName 0:1 NLString Name of the Stop.

Call Real-

time

VehicleAtStop 0:1 xsd:boolean

Whether vehicle is at stop at the

current time. If absent, unknown


Vehicle-LocationAtStop 0:1 Location-Structure Location that vehicle will take up at

stop point. DetailLevel: normal.


Call Rail

ReversesAtStop 0:1 xsd:boolean Whether vehicle reverses at stop.

Default is false. DetailLevel: normal.

Platform-Traversal 0:1 xsd:boolean

For Rail, whether this is a platform

traversal at speed, typically triggering

an announcement to stand back.

Default is false. DetailLevel: normal.

SignalStatus 0:1 xsd:NMTOKEN

Status of signal clearance for train.

This may affect the presentation

emphasis given to arrival or

departures on displays – e.g. cleared

trains appear first, flashing in green.

Call

Property

TimingPoint 0:1 xsd:boolean

Whether the stop is a timing point, i.e.

times are measured at this point. In

some systems this is a measure of

data quality as non-timing points are

interpolated.

BoardingStretch 0:1 xsd:boolean Whether this is a Hail and Ride Stop.

Default is false. DetailLevel: full.

RequestStop 0:1 xsd:boolean

Whether Vehicle stops only if

requested explicitly by passenger.

Default is false. DetailLevel: full.

Destination-Display 0:1 NLString

Name of the journey destination ;

helps to identify the vehicle for the

public. Since vehicles can change

their destination during a journey, the

destination included here should be

what the vehicle will display when it

reaches this stop. DetailLevel:

normal.

Call Note CallNote 0.* NLString Text annotation that applies to this

call. DetailLevel: full.

Disruption-

Group ::: 0:1 DisruptionGroup

See SIRI Part 2 DisruptionGroup.


Arrival

AimedArrival-Time 0:1 xsd:dateTime

Arrival Time in either the original or

Production Timetable. DetailLevel:

minimum.

ActualArrival-Time 0:1 xsd:dateTime Observed time of arrival. DetailLevel:

minimum.

ExpectedArrival-Time 0:1 xsd:dateTime Estimated time of arrival. DetailLevel:

minimum.

ArrivalStatus 0:1

ononTime; early;

delayed; cancelled;

arrived; noReport

Classification of the timeliness of the

arrival part of the call according to a

fixed list of values. This may reflect a

display policy, for example calls less


than one minute behind target time

are still classified as on-time.

Applications may use this to guide

their own display of times. If not

specified, same as DepartureStatus.


Arrival-PlatformName 0:1 NLString

Bay or platform name. Inherited

property. Can be omitted if equal as

the DeparturePlatformName. If there

not an arrival platform name separate

from the departure platform name, the

precedence is (i) any arrival platform

on any related dated timetable call

element, (ii) any departure platform

name on this call element; (iii) any

departure platform name on any

related dated timetable call.

DetailLevel: basic.

ArrivalBoarding-Activity 0:1

alighting;

noAlighting;

passthru

Type of alighting activity allowed at

stop. Default is alighting. DetailLevel:

normal.

Departure

AimedDeparture-Time 0:1 xsd:dateTime

Departure Time in either the original

or Production Timetable. DetailLevel:

minimum.

ActualDeparture-Time 0:1 xsd:dateTime Actual observed time of departure.

DetailLevel: minimum

Expected-DepartureTime 0:1 xsd:dateTime Estimated time of departure.

DetailLevel: minimum

DepartureStatus 0:1

ononTime; early;

delayed; cancelled;

arrived; noReport

Classification of the timeliness of the

departure part of the call, according to

a fixed list of values. This may reflect

a display policy, for example calls

less than one minute behind target

time are still classified as on-time.

Applications may use this to guide

their own display of times.

DetailLevel: normal

DeparturePlatformName 0:1 NLString

Bay or platform name from which

vehicle will depart. Inherited property.

DetailLevel: basic.

DepartureBoardingActivity 0:1

boarding;

noBoarding;

passthru

Type of boarding activity allowed at

stop. Default is boarding. DetailLevel:

normal.

Bording AimedHeadway-

Frequency 0:1

Positive-

DurationType

For frequency based services, target

interval between services at stop.



Expected-

HeadwayInterval 0:1

Positive-

DurationType

Estimated interval for frequency

based service. DetailLevel: minimum.

any Extensions 0:1 Any Placeholder for user extensions.

3.5.3.5 TargetedInterchange

This element is used for connections definitions.

Note lack of DPI information and attributes

TargetedInterchange +Structure Information on any planned connections. If

omitted: No connections.

Identity

InterchangeCode 0:1 ⇒Interchange-

Code Identifier of Journey Interchange.

DistributorVehicle-

JourneyRef 1:1

⇒DatedVehicle-

JourneyCode

Identifies the distributor dated vehicle

journey.

Connection

Distributor-

ConnectionLink 1:1 +Structure

ConnectionLink over which interchange

takes place.

ConnectionCode 1:1 ConnectionCode Identifier of connection Link.

StopPointRef 0:1 ⇒StopPoint-Code

Interchange stop from which the distributor

journey departs. If omitted: the distributor

journey stop is the same as the feeder

journey stop, i.e. that of the containing

dated call

Interchange-

Duration 0:1

PositiveDuration-

Type

Time (Duration) required by passenger to

change from feeder to distributor.

Frequent-

TravellerDuration 0:1

PositiveDuration-

Type

Time (Duration) required by passenger

who is familiar with interchange to change

from feeder to distributor. If absent, use

InterchangeDuration and a standard

weighting.

Occasional-

TravellerDuration 0:1

PositiveDuration-

Type

Time (Duration) required by passenger

who is not familiar with interchange to

change from feeder to distributor. If absent,

use InterchangeDuration and a standard

weighting.

ImpairedAccess-

Duration 0:1

PositiveDuration-

Type

Time (Duration) required by impaired

mobility passenger to change from feeder

to distributor. If absent, use

InterchangeDuration and a standard

weighting.

Identity Distributor-

VisitNumber 0:1 VisitNumber-Type

Sequence of visit to stop within distributor

vehicle journey. Increases monotonically,

but not necessarily sequentially.


DistributorOrder 0:1 xsd:positive-

Integer

For implementations for which the overall

Order within journey pattern is not used for

VisitNumber, (i.e. if VisitNumberIsOrder

is false) then can be used to associate the

overall Order as well if useful.

Interchange

Properties

StaySeated 0:1 xsd:boolean Whether Vehicle stops only if requested

explicitly by passenger. Default is false.

Guaranteed 0:1 xsd:boolean

Whether the interchange is guaranteed.

Default is false; interchange is not

guaranteed.

Advertised 0:1 xsd:boolean Whether the interchange is advertised as a

connection. Default is false.

MaximumWaitTime 0:1 PositiveDuration-

Type

Maximum Additional that Distributor will

wait for Feeder.

any Extensions 0:1 any Placeholder for user extensions.

S03- BackOffice Architecture specifications ITS Standerd-Del/S032015V1_ITxP… · Backoffice...

Documents

Transcript of S03- BackOffice Architecture specifications ITS Standerd-Del/S032015V1_ITxP… · Backoffice...