g02- vehicle and interface with backoffice systems guidelines its standerd-del... · 2016. 6....
TRANSCRIPT
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.