G02- Vehicle and interface with backoffice systems Guidelines

Release G02-2015V1.0

This page defines the detailed guidelines of ITxPT vehicle and interface with backoffice systems.

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 2/20

Content

1 Guidelines for using ITxPT specifications for on board systems ..................................................... 3 1.1 Onboard network requirements ................................................................................................ 3 1.2 Requirements on Systems and Services onboard .................................................................... 4 1.3 Validation of compliance ........................................................................................................... 5

1.3.1 STEP 1: IP ADDRESS CHECK ......................................................................................... 6 1.3.2 STEP 2: MODULE NAME CHECK .................................................................................... 7 1.3.3 STEP 3: NEW MODULE SERVICES ANNOUNCEMENT CHECK ................................... 8 1.3.4 STEP 4: NEW MODULE NEEDED SERVICES DISCOVERY CHECK ............................ 8 1.3.5 STEP 5: NEW MODULE DATA PROVIDING CHECK ...................................................... 9 1.3.6 STEP 6: OTHER MODULES DATA UNDERSTANDING CHECK .................................. 10

1.4 Definition of Installation Levels ............................................................................................... 11 1.4.1 BASIC INSTALLATION LEVEL (MINIMUM REQUIREMENTS) ..................................... 11 1.4.2 IMPLEMENTATION EXAMPLE: MEDIUM INSTALLATION LEVEL ............................... 11 1.4.3 IMPLEMENTATION EXAMPLE: HIGH INSTALLATION LEVEL ..................................... 12

1.5 Deployment recommendations & technical “how to” .............................................................. 13 1.5.1 HARDWARE .................................................................................................................... 13 1.5.2 SERVICES ....................................................................................................................... 13

2 Backoffice requirements ................................................................................................................. 18 3 Vehicle–Central AVMS Data Protocol ............................................................................................ 19

3.1 Messages ................................................................................................................................ 19

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 3/20

1 Guidelines for using ITxPT specifications for on board

systems

Onboard IT systems interoperability is the key for expandability, modularity, cost effectiveness and

uptime service maximization, and it is the main objective of the ITxPT architecture. In order to achieve

this, ITxPT specifies three types of requirements for onboard PT IT systems:

Requirements on Systems and Services

Network requirements

Installation requirements

The first two types of requirements are considered in this guidelines. The third one, installation

requirements, are described in G03- Vehicle installation guideline.

1.1 Onboard network requirements

On board network requirements are described in Onboard IP network, Onboard Passenger IP

network, and Onboard Backbone IP Network. Following is a summary of those requirements:

Each vehicle must have its own private IP network called “Onboard IP Network” to

interconnect modules and allow connectivity between applications inside the Vehicle. It will

allow modules to exchange data between them at vehicle level and to communicate with one

or more Back-office IP networks through the same module called “Vehicle Gateway”

Modules on this network should be physically connected over IP media according to TS13149-

7.

If “public” Cellular IP carriers (e.g. using private APN) are used from the vehicle to access the

Back Office, and roaming between cellular and Wi-Fi network are expected, then IP tunnelling/

VPN (with or without encryption) shall be used.

If “public” IP carriers (e.g. Internet connections) are used from the vehicle to access the Back

Office, , encrypted IP tunnelling / VPN tunnelling must be used.

When different vehicles are linked between them for modularity concept, a private IP network

called “Onboard Backbone IP Network” can be stablished in order to allow vehicles in a

modular bus to exchange operating data between them. The concept requires two Ethernet

ports dedicated at the vehicle gateway to the onboard backbone, one port for the front side

and one for the rear side, or one port in the gateway together with a Ethernet switch.

If a link is needed between onboard systems and passenger personal modules, such as

smartphones, in order to provide travel information or extra information for disabled people, an

“Onboard Passenger IP Network” can be established. This network, using wireless IP

solutions (Wi-Fi, Bluetooth or other) will connect personal modules to the vehicle gateway.

Security considerations:

o The Onboard Passenger IP Network must be configured as a DMZ

o Gateways shall use a firewall like linux iptables or similar.

o NAT should be used for local networks (e.g. Onboard network and onboard

backbone).

Vehicle to Back Office connections using public networks (Internet) must use

Encrypted(secure) VPN tunnels.

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 4/20

1.2 Requirements on Systems and Services onboard

On board Systems and Services requirements are described in “EBSF-D2.3.1-D3.2.1-Overall-

Architecture-Bus-on-board-back-office-IP-network-architecture” in sections 4.4.2 (Vehicle gateway

network functions), 4.4.3 (On board network services), 4.4.6.3 (On board AVMS services), 4.4.4

(Onboard Virtual Modules), and 4.4.6 (On board vehicle services).

In the acquisition process of IT systems, requirements are often expressed as functions, systems/sub-

systems and modules; however, with the exception of installation and network requirements, most

ITxPT requirements are expressed in terms of services belonging to virtual modules. This chapter

will clarify the link between both functional views, the acquisition/tender view and the ITxPT view, so

that ITxPT requirements can be used in an acquisition process for PT IT systems.

Physically, the core of a PT IT system, such as an AVMS or a ticketing system, is made of modules

and software applications. Additionally other components will be required such as computer

equipment, network components, cabling and communication services. In order to use the ITxPT

specifications, two ITxPT concepts should be clear: services and virtual modules:

A module is hardware or virtual component with an IP address on the IP network. A module

can publish services and subscribe to services.

A service delivers data on the IP architecture. A service is hosted by a module and is defined

by an IP port.

ITxPT specifies services for the following onboard virtual modules:

Vehicle Gateway

Multi-application driver terminal, MADT

FMS to IP bridge, FMS2IP

Onboard AVMS

Onboard dynamic passenger information, DPI

Remote diagnostic

For example, a commercially available AVMS whose onboard configuration includes an onboard

computer with location and data and voice communication functions, a driver terminal and a

passenger display, in order to comply with the ITxPT onboard architecture will have to satisfy the

ITxPT services defined for the following onboard virtual modules implicit in the previous configuration:

Vehicle Gateway

Multi-application driver terminal, MADT

Onboard AVMS

Onboard dynamic passenger information, DPI

This means, for instance, that even if this system is able to implement the desired passenger

information functionality using a proprietary protocol to communicate the on board computer with the

passenger display, the system will not comply as an ITxPT AVMS unless it implements the ITxPT

AVMS services, and will not comply as an AVMS DPI unless it implements the ITxPT DPI services.

Only in this way it can be guaranteed that in the future he display could be changed by a new one and

still work with the existing AVMS and vice versa.

The services specified for each virtual module are listed later in the section for the Definition of

Installation Levels, also in this chapter several ITxPT compliance levels are defined for the onboard

architecture.

In conclusion, any acquisition process which wishes to acquire an ITxPT compliant system will have

to:

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 5/20

Identify which ITxPT virtual modules wishes to include in the system

Divide the system functionality into two kinds of functions:

o Functions not relevant for interoperability. Establish your own requirements.

o Functions relevant for interoperability (ITxPT Services). Use ITxPT specifications*

according to the compliance level desired.

*The purpose of ITxPT was not to specify all possible services but just to define the architecture and

specify an important set of services which allowed for a proof of concept; for this reason, some

onboard virtual modules do not have today a specific services definition; these include:

Guidance

Video surveillance

Fare Collection

Driver asístance for eco-driving

Passenger counting

Voice over IP

Traffic Light priority Management

Black box

Consequently, any acquisition process wishing to use the ITxPT architecture must consider the

following:

Not all possible virtual modules are defined in ITxPT specifications.

But the previous statement doesn’t mean that defined ITxPT services cannot be used with

new virtual modules. For instance, a traffic light priority management module needs the

vehicle position, which is already considered in a AVMS service in ITxPT even when traffic

light signal priority has not been considered

Many ITxPT specifications are being used for the development of CEN TS 13149 standards,

which will consider at least the virtual modules considered in ITxPT and more; ultimately,

these standards will substitute and expand ITxPT specifications and should become the

reference for any acquisition process wishing to use the ITxPT architecture.

Additionally, the ITxPT Technical Platform stays at the forefront of the ITxPT specification ongoing

work, and, therefore, will allow to test modules implementing services beyond those defined in ITxPT

even before they become CEN standards.

1.3 Validation of compliance

Here is described a basic validation procedures, providing the main steps to plug a new module /

service and to validate its integration on the architecture. These and other procedures are used in the

ITxPT Technical Platform, which is a valuable tool for testing the ITxPT compliance of the modules

and services defined in ITxPT and some others. Formal testing procedures are defined in ITxPT for

testing the compliance of modules according to ITxPT specifications and can be applied on ITxPT

Technical Platforms.

We describe here how a new module should be integrated on the onboard network so that the

services it provides can be fully used by an existing module, and so that it can fully use services

provided by this existing module. Of course the procedure described here can be extended to the case

where more than 2 modules need to interact through the onboard network.

By module we mean “an entity able to provide services to the network and to consume services

available on the network”. Consequently, a module is a simple piece of software running either on a

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 6/20

dedicated or on an existing hardware module (case where a single hardware module hosts several

modules)

Figure 1 - New module on the IP network

Although it is tempting to install the new module on the system and directly turn the whole system on

hoping that communications with existing modules work perfectly fine, we rather recommend

processing to a step by step integration as described thereafter.

To do so, we recommend that integration software tools provided by ITxPT consortium should be used

by any integrator for the following reason:

Since the goal is here to integrate modules coming from different suppliers, it is important to have an

independent tool that can be referred to in order to validate compliancy of each module to the ITxPT

standard. In case of problems encountered during integration, doing so will avoid endless talks

between suppliers, each one of them arguing that they have the correct interpretation of the standard

(it is true that over time the standard will become more and more precise in every details, leaving less

and less room for interpretation, but anyway some interpretation will still be possible)

Figure 2 – ITxPT Integration tools test new module

1.3.1 STEP 1: IP ADDRESS CHECK

In case the new module integration needs a specific hardware to be plugged on the existing

architecture, it must be first verified that this hardware has a unique IP address on the physical

network

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 7/20

IP network with static addresses:

o Verify that the IP address of this new module is the one allocated by the integrator

and that it is not already in use.

o Use appropriate ITxPT integration tool to send a ping command to the desired IP

address and verify that the hardware module is answering back

Remark: fixed IP shall in general be avoided, but needed for modules like the « default gateway » (eg

router).

IP network with dynamic addresses:

o Verify that the assigned address is within the correct range.

o Verify that the auto-IP method is well integrated inside the new module. This is used

as a failover alternative for DHCP on the onboard LAN segment. It is also used as the

primary solution for the “onboard backbone network” (e.g. between gateways in larger

vehicles or virtual vehicles)

o Use appropriate ITxPT integration tool (Wireshark) to observe IP address negotiation

frames exchanged over the IP network

1.3.2 STEP 2: MODULE NAME CHECK

The next step is to obtain a name that can resolve to the IP address obtain in step 1. It is needed to

assign locally a unique name to the module and not use the statically or automatically assigned IP

address for the following reasons:

The IP address provided may be temporary

For a mobile module and a module that can connect to many networks, the module cannot

expect to keep the same IP address in every location and on every different network

An IP address is not a human-friendly way to locate a module providing a service

If it is needed to select a module from a list of available modules, this is easier to do if the list

is presented as text-based names and not as a collection of IP addresses

The method to obtain this unique local name is independent of how the IP address was obtained. For

example the IP address might have been obtained by taking advantage of the link-local addressing

(AutoIP), or been assigned using DHCP, or manually assigned. To get a name that is at least locally

unique and there is no DNS server available, the Multicast DNS (mDNS) is the mechanism to use.

Basically, mDNS consists in choosing a name and ask on the network if anyone is already using it,

then this name is claimed and defended on the local network. If the name is in use, a different name

should be used and the process repeated. The goal with mDNS is to have a system that requires

minimal administration and configuration and that works when DNS is not available.

Use appropriate ITxPT integration tool to verify the correct implementation of mDNS inside the module

hosting the module:

Use wireshark to observe the local name query on the network

From the ITxPT integration tool, make a mDNS query to claim the same name as the new

module. Then connect the new module and observe that the IPxPT tool is answering that the

name requested is already in use, and then observe that the new module repeat the process

with a request for a new name

Connect first the module, then from the ITxPT tool make a name request through mDNS

mechanism and verify that the module is answering to the request warning that it already

claimed this specific name.

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 8/20

1.3.3 STEP 3: NEW MODULE SERVICES ANNOUNCEMENT CHECK

The goal here is to verify that services provided by the new module can be discovered by the ITxPT

integration tools and that every field of each service is defined properly.

Figure 3 – New module services announcement

--> Use appropriate ITxPT integration tool (Avahi service discovery tool for example) to perform

services check.

The first service that should be checked if the module is hosted by a new hardware module is the

module inventory service:

Check that the symbolic name of the module inventory service is _inventory

Check that the protocol of the module inventory service is _tcp

Send HTTP request to retrieve detailed information about the new module (type of module,

model, manufacturer, serial number, software version, hardware version, current status, …)

1.3.4 STEP 4: NEW MODULE NEEDED SERVICES DISCOVERY CHECK

The goal here is to verify that the new module is able to discover services provided by other modules

that it needs to work properly.

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 9/20

Figure 4 – Other modules services discovery

--> Use appropriate ITxPT integration tool (Avahi service discovery tool for example) to simulate the

announcement of services needed by the new module.

(Personal comment: to be able to verify that services are discovered properly on the new module side,

the new module must implement a specific log file detailing the result of its discovery routine

should we impose module suppliers to implement such a log file in their design to facilitate integration

process?)

1.3.5 STEP 5: NEW MODULE DATA PROVIDING CHECK

The goal here is to verify that the new module services provide appropriate data to existing module. 2

things must be verified in particular:

Use of proper data exchange protocol specific to each service (tcp, udp broadcast, http,…)

Data format of XML files exchanged

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 10/20

Figure 5 – New module data providing

--> Use appropriate ITxPT integration tool (Wireshark) to spy packets traffic over the network

1.3.6 STEP 6: OTHER MODULES DATA UNDERSTANDING CHECK

The goal here is to verify that the new module is able to understand and use data sent through

existing modules services. 2 things must be verified in particular:

Use of proper data exchange protocol specific to each service (tcp, udp broadcast, http,…)

Data format of XML files exchanged

Figure 6 – Existing function data understanding

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 11/20

--> Use appropriate ITxPT integration tool (Wireshark) to spy packets traffic over the network

1.4 Definition of Installation Levels

Three installation levels are defined here regarding the installation of IT system onboard in PT

vehicles. The first one corresponds to the minimum requirements supporting a compliant ITxPT IT

architecture. The two others are defined as implementation examples. Both can be personalized

depending of PTA/PTO needs.

1.4.1 BASIC INSTALLATION LEVEL (MINIMUM REQUIREMENTS)

The basic installation level of vehicle systems in a PT vehicle is based on the ITxPT “support

functions” which are the main shared functions to build an ITxPT compliant IT architecture. It

corresponds to the minimum requirements to implement an ITxPT IT architecture. These functions are

required to support the “service functions” dependent on the PTO/PTA vehicles fleets and back-office

needs.

ITxPT support function requested Comments

MADT Chapter in S02- Onboard Architecture Specifications

FMS2IP Chapter in S02- Onboard Architecture Specifications

Communication Gateway Interface to Mobile Customer Modules? Customer Internet access?

Geo localization Resolution, NMEA frames requested?

Time synchronization Chapter in S02- Onboard Architecture Specifications

System monitoring

+IP switch (functional point of view not as a hardware module / basic network functionalities)

1.4.2 IMPLEMENTATION EXAMPLE: MEDIUM INSTALLATION LEVEL

A medium installation level can be defined as implementation example of a standard set of information

systems based on standard “service functions” like AVMS, passenger information and ticketing.

Usually these are well known applications with a largely consistent set of functions. For the vehicle

operator it is necessary to decide, which of these functions really should be implemented in a vehicle.

ITxPT function Function needed [Y/N] Comments

AVMS

Passenger Information

Ticketing

The possible answer of a supplier to these medium installation requirements could be found in the

following table. With this table it is possible to see with which services the requirements are fulfilled.

ITxPT function

requested Services provided Services needed Comments

AVMS

-Run Monitoring: Vehicle running

state - Vehicle block logon / logoff.

-Pattern Monitoring: Line, Journey

route description – Stop progress.

-Vehicle Monitoring: Progress

between stop information.

-Journey Monitoring: Journey and

Stops timetables.

-Disruption Messaging: Network –

-Geolocalization service.

-Bus-FMS service

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 12/20

line – between stops.

-Connection Monitoring:

Connected lines at specific stops,

with or without connection

protection

Passenger

Information None

From AVMS :

•Operational state

•Journey

•Localization

•Messaging

From BO DPI:

•DPI static information

related to network and not

carried by AVMS:

•Non-operational textual &

multimedia messages

From Data vehicle:

•Stop request state

•Doors state

•Geographic position

From Ticketing:

•Tariff zone or section

Specific user’s profile carried

by ticket - like blind person

Ticketing Based on Tickego

open specifications

For sizing the needed infrastructure inside a vehicle a third table is needed, in which the supplier

provides the information of the needed modules by the proposed solution.

Provided service Module Comments

AVMS

Passenger Information

Ticketing

1.4.3 IMPLEMENTATION EXAMPLE: HIGH INSTALLATION LEVEL

Based on the medium installation level, a high installation level can be defined as implementation

example of an extra set of information systems in addition to the “standard set“ based on high “service

functions” like videosurveillance, passenger counting or telediagnostic.

For the vehicle operator it is necessary to decide, which of these functions really should be

implemented in a vehicle.

ITxPT function Function needed [Y/N] Comments

Passenger Counting

Telediagnostic

Traffic Light Control

Videosurveillance

The possible answer of a supplier to these medium installation requirements could be found in the

following table. With this table it is possible to see with which services the requirements are fulfilled.

ITxPT function

requested Services provided Services needed Comments

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 13/20

Passenger Counting

Telediagnostic

•Real-time information about the health status

of the vehicle

•Context data for advanced troubleshooting of

failures

•Diagnostic control over critical sub-system

with dedicated specific sensors

-Geolocalization

service

- Bus-FMS service

Traffic Light Control

Videosurveillance

For sizing the needed infrastructure inside a vehicle a third table is needed, in which the supplier

provides the information of the needed modules by the proposed solution.

Provided service Module Comments

1.5 Deployment recommendations & technical “how to”

1.5.1 HARDWARE

Since the Vehicle Gateway is a core component in the onboard network infrastructure, it is very

important that it is designed to follow the ITxPT defined power states and power consumption rules.

Eg. Be able to stay active even when the “main switch” is off, so that modules may be started directly

from the backoffice. This can be used for major upgrades etc.

During development, a managed network switch with the possibility to configure a port to forward all

traffic (sniff port), this lets you see all the traffic on the network.

1.5.2 SERVICES

1.5.2.1 MDNS / DNS-SD IMPLEMENTATIONS

APPLE BONJOUR / MDNSRESOLVER

The implementation used by the Vehicle Gateway in ITxPT testbench is based on Apple Bonjour

mDNS/DNS-SD library versopn 107-6. After a few years without any updates at all Apple has since the

project started updated the library and changed the license terms. The original library is lacking a lot of

functionality (and has quite a few bugs) which makes it hard to work with - it is recommended to

develop a library on top of the dns_sd library before using it.

A new version has been developed by Apple, the sourcecode is available and is released under

Apache 2.0 license. The code should work on the most popular standard or embedded operating

systems. The new version has not been tested in the ITxPT testbench, mainly due to compiler

incompatibilities.

The new mDNS responser is available from Apple:

Apple Bonjour / mDNSResponder

Apple mDNSResponder source

Apple also provide a conformance kit for mDNS/DNS-SD, this has not beed investigated yet.

AVAHI

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 14/20

Avahi is the mDNS implementation currently used and developed by the opensource community. It

has a LGPL license. It is used extensively on the Linux desktop and should be more thoroughly tested.

It contains a backwards compatible API to Apple Bonjour. The Avahi applications and libraries have a

larger executable size than Apple Bonjour which may be a problem on an embedded module.

avahi.org

JMDNS/MDNSJAVA – JAVA BASED

mdnsjava

This is mdnsjava (not in the Maven repo) that I used instead, due to stability problems in JmDNS:

mdnsjava

You use it with a "listener" that react when different services connects and disconnects. So far it has

worked perfectly.

JmDNS

For java based applications the JmDNS may be used. This is a pura java implementation and does not

use Apple Bonjour, this means that there is a desent java API to be used.

jmdns.sourceforge.net

The old library that really did not work properly (on android) can be found here (also in the Maven

repo):

sourceforge.net

JmDNS and mdnsjava is used in the same manner, however JmDNS are having some issues to

trigger on some messages like when a service restarts and also having some issue with detecting

services that the local module tries to register.

It might be so that the problems are related to configuration (changing between multiple network

interface?) or that something is used in a wrong way (documentation is minimal to say the least),

however Cybercom had the same implementation problem. mdnsjava is almost used in the same way,

and it worked directly using the same configuration.

MDNS/DNS-SD EXPERIENCES

For simple tests and discovery the dig commandline application (part of bind-utils) may be used.

To find all webservers:

# dig +noall +answer +additional -t any -p 5353 @224.0.0.251 _http._tcp.local.

To find all services:

# dig +short -t any -p 5353 @224.0.0.251 _services._dns-sd._udp.local.

To get all details, use the avahi-browse command:

# avahi-browse -a -r

Since a few of the ITxPT services are defined to use _ebsf_socket._udp.local,

_ebsf_multicast._udp.local. or _ebsf_socket._tcp.local as the service type a bit more work is needed to

locate a service. You need to first search for the service type (for example : _ebsf_multicast._udp),

and then loop through the result and locate the correct service name (for example : FMStoIP). From

this filtered result you may choose a service to resolve and then connect to, you may need to get som

TXT parameters from the service host to be able to connect to the actual service.

A few tips to get a mDNS service up and running:

Make sure the module has an IP adress before trying to search for a mDNS/DNS-SD service.

For multicast networking to function a valid multicast/default route is needed, i.e don't try to

search for a service until DHCP client has completed.

mDNS/DNS-SD information is not 100% reliable at all times. If the expected service is missing

you may need to to a manual search again after some time. This is typically for modules that

by some reason starts up at a different time or by some reason are restarted.

Make sure that you refresh your records in time.

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 15/20

1.5.2.2 MADT RECOMMENDATIONS

As the MADT function is to provide a unique display interface for several different applications, it plays

a central role in the ITxPT architecture and must consequently be designed with care. The following

recommendations might be helpful.

Hardware:

Display size: at least 7 inches wide to ensure proper and quick information understanding for the

driver.

Display resolution: 800x480 pixels or higher

Touch screen: although optional, it is recommended because the flexibility it brings in terms of user

actions is more suitable compared to hard keys interface.

Software:

Web browser:

Since MADT function is to display web based HMI, it has to host a web browser.

The use of Webkit, which is an open source web browser engine library, is recommended in order to

integrate a web browser into MADT software. Since Webkit is already widely spread (it is for example

used in some of the most famous web browsers like Apple Safari, Google Chrome or Opera), verifying

how a generated web page might look on the MADT can be simply done by opening this page with

one of those web browser.

http://www.webkit.org/

Web server:

The technology of the web servers hosting the web pages depends of course of the technologies used

inside the web pages. As it is recommended to build dynamic pages, web pages will probably contain

some server code like PHP or Java Server Pages (JSP). In the case of PHP, Apache server can be

used and in the case of JSP Tomcat server is a good solution.

http://www.apache.org/

http://tomcat.apache.org/

Framework:

To design the whole MADT application software (the web pages container for instance) it might also

be a good idea to use Qt framework especially because it already integrates Webkit library and

because it is a cross-platform framework (application software can run on Windows, Linux,…)

http://qt.digia.com/ http://qt-project.org/doc/qt-5.0/qtwebkit/qtwebkit-index.html

Design approach:

Two different approaches exist in order to design the MADT application software:

1. The web page displayed on the MADT is generated by the remote application. In this case the

web server is located remotely and MADT job is simply to connect to this remote web server

to get the appropriate web page. To do so, the MADT should register a service to let know

applications on the network that it has web pages display capability. Once the service has

been discovered by the application, the application sends to the MADT the URL of the web

page it has to connect to.

2. The web page displayed on the MADT is generated locally by the MADT. In this case the web

server needs to be located locally on the MADT. It is not necessary for the MADT to register

any specific service here, but instead to discover the services registered by applications in

order to then get raw information from them and start building web pages around them.

Since one approach or the other might be more convenient depending on the application, the best

solution is probably to implement both of them so that the MADT application software can answer

different needs.

Configuration:

The MADT application software should be highly configurable through the use of a configuration file.

Parameters might include:

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 16/20

The size of the web browser window inside the screen

The number of applications (number of tabs) that can be displayed

Colors and font

…

Other:

The MADT can register additional services that might be useful for applications. For example it

might be interesting to create a service allowing applications to send to the driver an important

message or an alert that could be automatically displayed as a pop-up on top of current web

page.

AJAX (Asynchronous Javascript and XML) can be used to make fast updates of a web page

content without the need to do a full page reload that would be visible by the user

It is really important that the interfaces (=XMLs) are precisely defined and that there are not any

dummy-values for free customization. Optional parameters are no problem, but it has to be clear and

common sense which parameter contains which value and what is the meaning of this value.

The names of the services have to be standardized

1.5.2.3 FMS2IP RECOMMENDATIONS

FMS2IP services

FMS2IP gateway registers 1 service for each PGN.

FMS2IP services are multicast services, meaning that they must be registered with the

_ebsf_multicast type. The transport protocol must be _udp.

Attribute address must be used in the TXT record to specify the multicast IP address the service

consumer must connect to. Attribute port must be used in the TXT record to specify the port that the

service consumer should connect to.

Once the FMS2IP service is discovered by the consumer, the consumer must first join the multicast

group defined by the IP address specified in the service TXT record, and then open a UDP socket on

the port also specified in the service TXT record.

FMSoverIP is one of the last services defined in the EBSF project. It has not matured yet with

requirements from the actual usecases from different partners. ITxPT will permit to received return of

experience and validation of such services.

FMS-data frames may come very frequent (10ms) and may also be timecritical depending on how the

data is used by the client applications. FMSoverIP service must be able to either filter out

duplicated/irrelevant data but also keep a short delay between reading the CAN-frame to multicast on

the network.

1.5.2.4 GPS RECOMMANDATIONS

ITxPT Specification:

The NMEA frame are encapsulated in XML format. Example:

<nmea_rmc>

$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003

.1,W*6A

</nmea_rmc>

NMEA frames used:

Rmc, zda : 1st level, considered as basic NMEA data,

Gsa, gga : 2nd level, considered as detailed NMEA data,

Gsv : 3rd level, considered as advanced NMEA data.

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 17/20

For tesbench the service uses “_ebsf_socket” interface with UDP.

For testbench we propose also to support “hhtp” interface using http GET command.

The names of the three identified services are :

GeolocalizationReferenceBasic,

GeolocalizationReferenceDetailed,

GeolocalizationReferenceAdvanced.

In case of several modules providing the Geographical Localization services, for UDP socket the port

number must be different for each producer.

ITxPT Implementation :

The specification has not been respected. Here is an extract of the logs :

_gps_rmc._ebsf_multicast._udp.local. service at 192.168.0.7:44000

address=239.255.42.21

port=44000

_gps_gga._ebsf_multicast._udp.local. service at 192.168.0.7:44001

address=239.255.42.21

port=44001

Only RMC and GGA frames are available, and none of the 3 identified services.

GPS position is one of the most important services for the ITxPT Technical Platform since localisation

and speed can be used for many types of applications.

During the meetings different approaches has been used to standardise the protocol to distibute the

GPS data.

The word geolocalisation is prefeered to use instead of GPS as this will include other sources such as

Glonass and Gallileo. The discussions on a backup/secondary service has not been concluded but

utilizing the priority field in the mDNS/DNS-SD announcement of the geolocalisation SRV record to

announce several sources of data. The secondary localization service must send data to a different

multicast address or port to avoid interfering with the primary localization service.

The Localization service is defined in S02- Onboard Architecture Specifications.

The final proposal is a single UDP multicast socket where raw NMEA0183 sentences are sent with

<NMEA> xml-tags around it. A single socket for all sentences are used to make sure the client reads

the sentences in correct order.

As position (speed/time) are time critical to show the correct result for passengers and other systems

there must be a minimal delay and processing from reading the serial NMEA0183 signal and forward it

on the multicast socket.

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 18/20

2 Backoffice requirements

ITxPT Backoffice requirements and specifications have been considered in several sections in more

than one document. The following table groups the ITxPT backoffice specifications into logical parts

and indicates the ITxPT documents and chapters which serve as a reference.

Type of requirements Reference

Requirements for interoperability

between Back offices

These have been considering in a specific guideline G02-

Backoffice systems interoperability guideline

Backoffice Network

requirements

S02- Backoffice Architecture specifications

-Backoffice components

-Backoffice services

General Backoffice Services:

-Vehicle connectivity monitoring

service/tool

-Vehicle master database

-DRS

–Module registration service

-Vehicle inventory database

S02- Backoffice Architecture specifications

-Backoffice services

Dynamic Passenger Informacion S02- Backoffice Architecture specifications

-DPI Services

Multi_AVMS Coordination

S02- Backoffice Architecture specifications

-7 (Multi_AVMS Coordination)

Also considered in G02- Backoffice systems interoperability

guideline

Remote Diagnostic S02- Backoffice Architecture specifications

-8 (Remote diagnostic back-office reference model)

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 19/20

3 Vehicle–Central AVMS Data Protocol

The ITxPT defined, in S02- Backoffice Architecture specifications, and tested in a testbench a data

communication protocol between the onboard AVMS virtual module and the backoffice. The

specifications of this protocol include:

A global identifier, GID, which can be used for different objects such as vehicle, driver, block,

duty, service journey and stop.

A procedure for obtaining a session ID to identify vehicles and link to it defaults (driver, block,

duty, service..)

UDP will be used

A message (datagram) structure definition including the following fields:

o Protocol type

o Protocol version

o Message length

o Options

o Optional fields:

Sequence number

Timestamp seconds

Timestamp millisenconds

Vehicle session ID

ACK sequence number

ACK required

CRC

Body of the message

A set of messages according to its body

3.1 Messages

The following messages have been defined to be sent from the vehicle to the Back office. The

indicated ID is the message type. For some messages two messages types are defined, the second

one should be used when using GID.

VEHICLE TO BACK OFFICE

ID Message

11 Technical Logon Request

16 Technical Logoff Request

12 Default Value Request

21/31 Driver Logon Request

22/32 Duty Logon Request

23/33 Block Logon Request

24/34 Service Journey Logon Request

25/35 Dead Run Journey Logon Request

26/36 Line Logon request not including time

29 Logical Logoff request

41/51 Logical Position on Journey1

42/52 Logical Position on Journey2

43/53 Arrival at Stop

G02-2015V1.0 Vehicle and interface with backoffice systems Guidelines 20/20

44/54 Departure from Stop

45/55 Physical location

46 Off route / On route again request

56 Driver to dispatcher messaging request

57 RTT, PRTT, Silent alarm request

58 Occupancy / Passenger loading message by driver request

59 Occupancy / Passenger loading automatic report

60/61 Passenger counting report

64 Driver Response report

65 Remote diagnosis alarm

66 Running state / vehicle state request

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

70 Ack report

BACK OFFICE TO VEHICLE

ID Message

121 Ack response (Central ACK)

122 Technical logon response

123 Technical Logon Request

124 Forced logon/logoff by dispatcher request (Service Journey logon by central system)

125 As 124 with GID

126 Predefined message from Central system

127 Free text messaging

128 Dispatcher Ack request

129 Voice call response/initiation

130 Interchange/Connections instructions or information request

134 Localization request

136 to 200 Dispatch actions

201 to 255 Other

NOTES:

This set of messages is not mean to be complete; an AVMS will likely need to use other

messages types too.

Today, no standardisation process has been initiated for this communication protocol.