METATRONIX SRL - 2017373 - XPOD

Trasporto pubblico
SPECIFICA Sistemi di controllo e di pianificazione dei veicoli su UNI CENITS
TECNICA strada 13149-7
Parte 7: Architettura di Sistema e di Rete

DICEMBRE 2015

Public transport
Road vehicle scheduling and control systems
Part 7: System and Network Architecture

La specific a tecnica descrive I'architettura di sistema e di rete per

attrezzatura di bordo. Specifica i principi base delle comunicazioni
tra cui una descrizione generale della topologia di rete, schemi di
indirizzi, servizi di rete di base, una panoramica del sistema e
architettura del modulo base.

TESTOINGLESE

La presente norma El la versione ufficiale in lingua inglese della

norma europea CENITS 13149-7 (edizione novembre 2015).

I CS 35.240.60; 43.040.15

© U NI
Riproduzione vietala. Legge 22 aprile 1941 W 633 e successivi aggiornamenli.
ENTE ITALlANo Tutti i diritti sono riservali. Nessuna parte del presente documenlo pub essere riprodotta 0 diffusa
01 NoRMAZloNE con un meuo qualsiasi, folocopie, microfilm 0 allro, senza il consenso seritto dell'UNI.

UNI CENITS 13149-7:2015 Pagina I

 METATRONIX SRL - 20 17373 - XPOD

PREMESSA
La presente specifica tecnica costituisce il recepimento, in lingua
inglese, della specifica tecnica europea CENrTS 13149-7 (edizione
novembre 2015), che assume cos; 10 status di specifica tecnica
nazionale italiana.

La scadenza del periodo di validita del CEN ISOrTS 13149-7 El stata

fissata inizialmente dal CEN per novembre 2018. Eventuali
osservazioni sulla specifica tecnica devono pervenire all'UNI entr�
novembre 2017.

La presente specifica tecnica El stata elaborata sotto la competenza

dell'ente federato all'UNI
UNINFO - Tecnologie Informaliche e loro applicazioni

La presente specifica tecnica El stata ratificata dal Presidente

dell'UNI ed El entrata a far parte del corpo normativo nazionale il
17 dicembre 2015.

Le norme UNI sono elaborale cercando di tenere conlo dei punli di vista di tutte le parti
inleressate e di conciliare ogni aspetto conflitluale, per rappresentare il Teale stato
dell'arte della maleria ed il necessaria grado di consenso.
Chiunque ritenesse, a seguilo dell'applicazione di quesla norma, di poter fornire 5ug­
gerimenli per un suo miglioramento 0 per un suo adeguamenlo ad uno state dell'arte
in evoluzione e pregato di inviare i propri conlributi all'UNI, Enle Nazionale Ilaliano di
Unificazione, che Ii terra in considerazione per ['eventuale revisione deUa norma 5le5sa.

Le norme UNI sono revisionate, quando necessaria, con la pubblicazione di nuove edizioni 0
di aggiornamenti.
E importante pertanto che gli utilizzatori delle stesse si accertino di essere in possesso
dell'ultima edizione e degli eventuali aggiornamenti.
Si invitano inoitre gli utilizzatori a verificare I'esistenza di nor me UNI corrispondenti alle
nor me EN 0 ISO ove citate nei riferimenti normativi.

UNI CENITS 13149·7:2015 © UNI Pagina 11

 METATRONIX SRL· 20 17373 · XPOD

TECHNICAL SPECIFICATION CENITS 13149-7

SPECIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION November 2015

ICS 35.240.60; 43.040.15

English Version

Public transport - Road vehicle scheduling and control

systems - Part 7: System and Network Architecture

Transport public - Systemes de planification et de Offentlicher Verkehr - Planungs- und

controle des vehicules routiers - Partie 7: Architecture 5teuerungssysteme fUr 5tragenfahrzeuge - Tejl 7:
Systeme et Reseau System- und Netzwerkarchitektur

This Technical Specification (CENjTS) was approved by (EN on 19 October 2015 for provisional application.

The period of validity of this CENjTS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CENjTS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark. Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, lceland,lreland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia. Spain. Sweden, Switzerland. Turkey and
United Kingdom.

EUROPEAN COMMITTEE FORSTA NDARDIZATION

C OMITE EU ROPEEN DE NORM ALISATION
EURO PAISCHES KOMITEE FOR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels

© 2015 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 13149·7:2015 E
worldwide for CEN national Members.

UNI CENfTS 13 149·7 2

: 0 15
 METATRONIX SRL -20 17373 -XPOD

CEN/TS 13 149-7:2015 (E)

Contents Page

European foreword ....................................................................................................................................................... 3

Introduction .................................................................................................................................................................... 4
1 Scope . .
........ ............................................................................ ....................................................................... . .... .. 6
2 Terms and definitions . . . . ..
........... .. .. ............................... ........................................ . ............................... .. . . . .. 6
3 Symbols an d abbreviations . .
...... .. ...................................... """""""""""""""""''''................................... 8
4 Design prin cipies . . . . .
.......................................... ............................................... .. .. ............. .............................. 8
4.1 Introduction . . .
.......................................................................................... ..................................... .. .................. 8
4.2 Design goals . . . . . . . .. .
. .. ........ ..... ........... . . ... . . . . . . . . .
.. ..... ...... ......... ....................................... ............. . . ........ ..... ........... 9
5 Network architecture .
............................................................................................ .................................... 10
5.1 Introducti0n .
..................................................................... ............................................................................. 10
5.2 Network overview ........................................................................................................................................ 10
5.3 Gateways to other networks . . . . .. .. .. .......................................................................................................... 10
5.4 IP addressing ................................................................................................................................................. 11
5.5 Name registration and resolution of modules ................................................................................... 13
5.6 Communication Protocols ......................................................................................................................... 15
5.7 Communi cation methods .......................................................................................................................... 16
5.8 Network security .......................................................................................................................................... 17
5.9 Considerations on coupled vehicles ...................................................................................................... 18
6 Service architecture .................................................................................................................................... 18
6.1 Service oriented architecture (SOA) ..................................................................................................... 18
6.2 Service Information ..................................................................................................................................... 18
6.3 Commun ication Types . . .............. ............... ................................................................................................. 20
6.4 Data Structure . . . . .
..................................................................... ............ ................. ....... .. ............................... 21
Annex A (informative) Example usages . . .. .
.............................................................. ......... . ....... ........................ 22
A.l Typical vehicle network architecture .
................................................................ .................................. 22
A.2 Function and service groups .
.... ............................................................................................................... 23
A.3 Example of a service record ..................................................................................................................... 23
Bibliography .
........................ ........................................................................................................................................ 24

2
UNI CENITS 13 149-7:20 15
 METATRONIX SRl· 20 1 7 37 3· XPOD

CEN/TS 1 3 149·7:2015 (E)

European foreword

This document (CEN/TS 13149·7:2015) has been prepared by Technical Committee CEN/TC 278
"Intelligent transport systems", the secretariat of which is held by NEN.

Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/OI' CENELEC] shall not be held responsible for identifying any or all such patent
rights.

This Technical Specification is Part 7 of a series of European Standards and Technical Specifications that
includes:

EN 13149·1:2004, Public transport· Road vehicle scheduling and control systems· Part1: WORLDFIP
definition

EN 13149·2:2004, Public transport· Road vehicle scheduling and control systems· Part2: WORLDFIP
cabling specifications

CEN/TS 13149 ·3:2007, Public transport · Road vehicle scheduling and control systems· Part 3:
WorldFIP message content

EN 13149 ·4:2004, Public transport· Roadvehicle scheduling and control systems· Part4: General
application rules forCA Nopen transmission buses

EN 13149 ·5:2004, Public transport· Road vehicle scheduling and control systems· Part 5: CANopen
cabling specifications

CEN/TS 13149·6:2005, Public transport· Roadvehicle scheduling and control systems· Part6: CAN
message content

CEN/TS 13149·7:2015, Public transport· Road vehicle scheduling and control systems · Part 7:
System and Network Architecture

C EN/TS 13149·8:2013, Public transport· Road vehicle scheduling and control systems· Part 8:
Physical layer forIP communication

prCEN/TS 13149·9, Public Transport· Road VehicleScheduling andControlSystems· Part 9: Ip·

based NetworkingInside AVehicle, InformationServices

According to the CEN·CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to announce this Technical Specification: Austria, 8elgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal. Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

3
UNI CENITS 1 3149·7 :201 5
 METATRONIX SRL - 20 17373 -XPOD

CEN/TS 1 3 149-7:2015 (E)

Introduction

This Technical Specification is Part 7 of a series of European Standards and Technical Specifications.
The scope of this series is on-board data communication systems on public transport vehicles.
Public Transport (PT) vehicles have an increasing array of information and communications systems,
including ticket machines, Automated Vehicle Location (AVL) systems, destination displays, passenger
announcement systems, vehicle monitoring systems, etc. Other systems are beginning to be included
such as advertising screens, tourist guides, WiFi "hots pots" and infotainment.
In addition, equipped PT vehicles will usually have a communications facility to enable voice and data to
be exchanged with the control centre, other PT vehicles, PT infrastructure and roadside devices for
instance in requesting priority at traffic signals. Many types of communication channel are used
including public and private wireless communication networks.
These systems may be provided by a number of different suppliers and may need to be integrated. For
instance:
a ticket machine may need location information to update fare stages;

next-stop and destination information may be drawn from schedule information held in the ticket
machine;

vehicle location systems may be used to drive signal priority requests.

As data exchange between functional units becomes more widespread, a networked approach begins to
become efficient. With standardized underlying technology, the PT vehicle begins to look like a local
area network: making use of IEEE 802 communications and the Internet Protocol (IP) suite.
Without a clear technology framework, integrating these systems would require complex technical
discussions every time a device is procured. The existing E N 13149 standards recognized this long ago
in respect of the core vehicle systems, but these have not been adapted to IP networking.
Existing Parts 1 to 6 of E N 13149 specify two independent frameworks, generally referred to as
"WorldFIP" (Parts 1 to 3) and "CANbus" (Parts 4 to 6). These have not been developed with IP as a
networking protocol and there has been strong interest in the community to migrate towards this
approach. Parts 7 to 9 are therefore intended to provide an I P-based approach, with updated content
(i.e. independent of Parts 1 to 6).
CEN/TS 13149-7:2015 specifies the Network and System Architecture for on board equipment. It
describes basic principles of communications including a general description of the network
topology, addresses schematics, basic network services, a system overview and basic module
architecture.

CEN/TS 13149-8 specifies the Physical Layer for lP-communication networks on board PT vehicles.
This part specifies the cables, connectors and other equipment including pin assignment and
environmental requirements.

prCEN/TS 13149-91 specifies in detail the profiles of basic and generic Services as well as profiles
of specific services.

It is expected that EN 13149 Parts 1 to 6 will no longer be adopted once Parts 7 to 9 are complete. With
these Technical Specifications, it will be easier to achieve:

1) 111 development and registered as CEN/WI 00278382.

4
UNI CENfTS 13 149-7 :201
 METATRONIX SRL - 20 17373 - XPOD

CEN/TS 13149-7:2015 (E)

more efficient development of PT components;

lower cost, lower risks and a smoother on board integration of PT equipment;

more efficient operation and maintenance of on board PT equipment;

high quality intermodal passenger services based on intermodal PT information;

integration of new PT services.

As an JP based solution, this Technical Specification draws on a range of lETF Requests for Comment
(RFCs), not all of which may be formal standards. A list of those cited is presented in the Bibliography.

5
UNI CENfTS 13 149·7 :20 15
 METATRONIX SRL - 2017373 - XPOD

CEN/TS 13149-7:2015 (E)

1 Scope

This Technical Specification specifies the general rules for an on-board data communication system
between the different systems that may be used within public transport vehicles. This includes
operational support systems, passenger information systems, fare collection systems, etc.
This Technical Specification describes:
the requirements for an on board IP network;

the overview architecture and components for an IP based on-board network;

the modular structure of the network architecture;

the Service Oriented Architecture (SOA) approach, and approach to defining services.

Systems directly related to the safe operation of the vehicle (including propulsion management, brake
systems, door opening systems) are excluded from the scope of this Technical Specification and are
dealt with in other standardization bodies. However, the architecture described in this Technical
Specification may be used for support services such as safety information messages. Interfaces to
safety-critical systems should be provided through dedicated gateways with appropriate security
provisions; for the purposes of this Technical Specification, these are regarded as simply external
information sources.
This Technical Specification is designed primarily for vehicles with a fixed primary structure, where
networks can be installed on a permanent basis and the system configuration task consists largely of
the integration, adjustment or removal of the functional end systems that produce and/OJ· consume
data. Public transport vehicles consisting of units linked temporarily for operational purposes
(specifically, trains in which individual engines, cars or consists are routinely connected and
disconnected) require additional mechanisms to enable the communications network itself to
reconfigure. Such mechanisms are provided through other standards, notably the lEe 61375 series. (See
also 5.9.)

2 Terms and definitions

For the purposes of this document, the following terms and definitions apply.
2.1
application
piece of software constructed to capture, process and/or interpret data within the context of a business
process; for example estimating vehicle location within the transport network

2.2
function
logical set of data processing activities that fulfils a business need

EXAMPLE Automated Vehicle Monitoring System (AVMS).

2.3
module
hardware or virtual component with an IP address on the IP network

EXAMPLE OnBoardUnit (on board computer).

6
UNI CENITS 13149-7 :
 METATRONIX SRL - 20 17373 - XPOD

CEN/TS 13149-7:2015 (E)

2.4
service
mechanism to deliver data on the IP architecture

EXAMPLE Provision of information about the vehicle location within the transport network.

Note 1 to entry: Thus, a module will host one or more appl ications which are designed to implement functions;
a service is provided by an application via a module (using an IP port), and communicates across the IP network.
In particular, a module can host several applications, an application can provide several services, and identical
services can be provided multiple times by different applications. Figure 1 depicts this relationship
diagrammatically.

Ai A2 A3 A4

AS A6 A7

Key
M l - M4 Modules
SRV1 -SRVS Services
A l -A7 Applications
IP Primary network

Figure 1 - Relationship between terms (example)

Applications, and the functions they support, are liable to regularly change and are independent of the
technical features described in this Technical Specification. prCEN/TS 13149-9 addresses the definition
of specific data structures for some key functions.

7
UNI CEN/TS 13 149-7 2
: 0 15
 METATRONIX SRL -2017373 -XPOD

CEN/TS 13149-7:2015 (El

3 Symbols and abbreviations

API Application Programming Interface

AVMS Automated Vehicle Monitoring System

AVL Automated Vehicle Location

CAN Controller Area N etwork

DHCP Dynamic Host Configuration Protocol

DNS Domain Name System

DNS-SD DNS based Service Discovery

DPI Dynamic Passenger Information

FTP File Transfer Protocol

GPS Global Positioning System

HTTP HyperText Transfer Protocol

JP I nternet Protocol

IT I nformation Technologies

LAN Local Area Network

mDNS M u lticast DNS

MMI Man Machine Interface

PT Public Transport

PTA Public Transport Authority

PTO Public Transport Operator

QoS Quality of Service

SOA Service Oriented Architecture

SSH Secure Shell protocol

TELNET TErminaL NETwork

UDP User Datagram Protocol

WLAN Wireless Local Area Network

4 Design principles

4.1 Introduction

This clause describes the design principles adopted in the development of EN 13149, Parts 7 to 9. These
consist of:
the operational characteristics which are routinely required of an integrated on·board systems
network, and the goals for which this Technical Specification has been designed;

the language used to describe the systems and their connectivity.

8
UNI CENITS 1 3149-7 :20
 METATRONIX SRl-2 0 17373 -XPOD

CENjTS 13149-7:2015 (E)

4.2 Design goals

4.2.1 Enabling communications

Different systems on the vehicle may benefit from exchanging data with each other, in an automated
and sometimes real-time manner. This requires a framework which identifies clearly the approach to
configuration and structure of data exchanges through standard mechanisms. IP-based communications
is very mature and capable of delivering this goal.
4.2.2 Enabling interoperability

Similarly, there are advantages in adopting a standard for system architecture and data structures
which is independent of manufacturer. Interconnection between modules of different suppliers will be
facilitated by the use of standardized software and hardware interfaces. The Service Oriented
Architecture approach is now widely used and accepted.
4.2.3 Ease of configuration

The need for manual intervention in the configuration and operation of units can be avoided by
ensuring that there is maximum opportunity for them to self-identify and self-describe to the network.
Manual configuration also needs to be supported, for example where system parameters are subject to
operator policy choices.
4.2.4 Quality of monitoring

The system has to include mechanisms to monitor the health of modules and services and prevent
failures. Helpful alerts can then be provided to the people responsible for managing the system.
4.2.5 Maintainability

It is desirable to make on-board systems simple to maintain, through software updates, device
interrogation, problem diagnosis, etc. Remote monitoring and maintenance of IT systems is now
commonplace, but requires suitably designed communications access.
In the case of on-board systems, it is particularly important to be able to interrogate a system from a
convenient point on the vehicle, and to avoid the need to access 01' uninstall deeply-buried equipment.
4.2.6 Migration

Currently there already exist several IP and non-IP systems and different IT architecture in PT vehicles,
and it will not be practical to migrate them all to a fully-functional IP network immediately. Therefore,
the architecture has to allow for the gradual roll-out of new modules and services onto an IP backbone,
while still enabling the inclusion of proprietary systems while they remain important operational
components. This raises interoperability challenges and would imply the need for some kind of gateway
access and data translation.
4.2.7 Supporting fleet changes

Vehicles will typically be liable to change the PT service they are running, which alters the way in which
they need to be integrated into the operator's control systems. This includes a number of special cases,
such as:
where an operator "shares" a vehicle with another operator during operation;

where an operator uses the same vehicle for several authorities, during the same day.

Operators/authorities may therefore need to operate fleets of vehicles using different IT architectures
01' systems. These again emphasize the need for the on-board systems and networks to be secure,
configurable and adaptable.

9
UNI CENfTS 13 1 49-7 :2 015
 METATRONIX SRL - 20 17373 - XPOD

CEN/TS 13149-7:2015 (E)

5 Network architecture

5.1 Introduction

This clause describes the on-board IP network and the technical mechanisms to be used to connect
modules to it. It covers IP addressing, name registration and resolution, communication protocols and
communication methods.
5.2 Network overview

Each vehicle shaIl have a private JP network (the "primary on-board IP network" or just "primary
network") to interconnect modules, This should be provide the primary means by which modules
exchange data within the vehicle level, and by which the modules share common resources,
M odules on the network may be connected physicaIly (as described in CEN/TS 13149-8) or virtuaIly
over alternative lP-capable bearers,
5.3 Gateways to other networks

Beside the primary network, a vehicle may have several other communication networks (which may or
may not be lP-based), A typical example would be the automotive CAN (ControIler Area Network); there
may also be serial buses like RS48S; and there could be a wireless network (perhaps WiFi) for
passenger access,
Such networks ("external networks") may be connected to the primary network. Such connections,
where they exist, shaIl be via suitably secure gateways,
Figure 2 shows an example overview of a generic on board IP network, with an external network and
gateway aIlowing exchange of data between external and primary networks,

10
UNI CENfTS 13 149-7 :201
 METATRONIX SRL - 2017373 - XPOD

CENjTS 13149-7:2015 (E)

Key
M 1 - MS Hardware modules
MS1 and MS2 Virtual modules (hosted by hardware module MS)

M6 Module providing a gateway

JP Primary network

N Other on board network

Figure 2 - A generic on board system with an external network

5.4 JP addressing

5.4.1 General addressing considerations

Each module needs to have an IP address on the network. To fulfil the requirement of an easy
configuration, automatic mechanisms like DHCP or self-assignment (link local) should be used. If IP
addresses are allocated manually, a suitable management procedure shall be described and adopted.
Each type of IP·addressing can be used for on board IP network depending of the implementation
context.
New modules should support manual, DHCP and self-assignment.
Either IPv4 or IPv6 may be used, provided the core network devices and the address assignment
mechanism are suitable.
5.4.2 Address space

5.4.2.1 Address space in IPv4

For vehicle primary networks using IPv4, address assignment should respect the private address map
described in the RFC1918. Depending on the size of the network, class A, 8 or C subnets may be
implemented, as recapped in the table below.

11
UNI CENfTS 131 49-7 : 201 5
 METATRONIX SRL · 20 1 7 37 3· XPOD

CEN/TS 13149·7:2015 (E)

Where the vehicle will not require more than 256 addresses, a single class C subnet will be sufficient
and should be used.
Table 1 - Address space options

RFC1918 Number of Classful Largest CIDR block Host id

IP address range
name addresses description (subnet mask) size

24·bit block 10.0.0.0 - 16,777,216 Single class A 10.0.0.0/8 (255.0.0.0) 24 bits

10.255.255.255

20·bit block 172.16.0.0 - 1,048,576 16 contiguous class 172.16.0.0/12 20 bits

172.31.255.255 Bs (255.240.0.0)

16·bit block 192.168.0.0 - 65,536 256 contiguous 192.168.0.0/16 16 bits

192.168.255.255 class Cs (255.255.0.0)

.
192.168.0.0 - 256 Single class C 192.168.0.0/8 8 bits
192.168.0.255 (255.255.255.0)

5.4.2.2 Address space in IPv6

For vehicle primary networks using IPv6, address assignment should respect the requirements of
RFC4291, depending on the address type (unicast, multicast, anycast) defined by the prefix notation.
According to RFC3177, the on board modules should receive a /48 prefix (considered as home network
su bscribers).
5.4.3 Manual assignment

Manual IP assignment may be either hard·coded into the device, or configurable over the network.
Beside a careful management of the assignment to prevent duplicates, maintenance support may
depend on ensuring the address is not inadvertently changed. If the IP address is hard coded, it will be
necessary at each exchange to ensure that there remains no duplication. A reference to the installation
position would reduce potential errors using this manual configuration.
5.4.4 Automatic assignment

5.4.4.1 DHCP assignment

The Dynamic Host Configuration Protocol (DHCP) is a way to assign IP addresses. Using DHCP means
identifying a pool of addresses dedicated to be allocated to the module that can send DHCP requests to a
DHCP server. This server is responsible for assigning and managing unique addresses to each module,
based on RFC2131.
The type of address respects the IPv4 classes and IPv6 requirements depending on the number of
addresses the DHCP server shall manage.
With DHCP, the addressing map may dynamically change. This shall be regarded when implementing in
an environment with a DHCP assignment.
The DHCP server shall provide a range of special private addresses.
EXAMPLE The server could be configured to all ocate in the range 192.168.0.1/24 to 192.168.0.253/24,
holding the a d d ress 192.168.0.254 reserved for the default communication gateway of the sub·network (Le. for
connection to off-vehicle networks).

A module which provides a DHCP server shall be able to have its DHCP server disabled.

12
UNI CENITS 13149· 7:2015
 METATRONIX SRL - 20 17373 - XPOD

CEN/TS 13149-7:2015 (E)

5.4.4.2 Self-assignment

The IPv4 and IPv6 protocols both have standardized techniques of self-assignment of IP addresses.
For IPv4, RFC3927 defines the dynamic allocation of IP addresses in the 169.254.0.0/16 range
("IPv4 Link-Local" address assignment, IPv4LL);

For IPv6, RFC4862 defines the self-assignment of link-local addresses assigned with the fe80::/64
prefix.

5.4.4.3 Mixed assignment

Mixed assignment of IP addresses is possible by respecting assignment rules of sections 5.4.4.1 and
5.4.4.2 as appropriate. The private range of the primary network shall be divided into 2 distinguishable
ranges using one of the following combinations:
the first range dedicated to DHCP assignment and the second range for manual assignment;

the first range dedicated to self-assignment and the second range for manual assignment.

EXAMPLES

DHCP and Manual: first range, [ 1 92.168.0.1/24 to 192.168.0.200/24J and second range, [192.168.0.201/24
to 192.168.0.253/24J.

Self and Manual: second range, [169.254.0.201/24 to 169.254.0.253/24J. First range is automatically
all ocated.

5.5 Name registration and resolution of modules

5.5.1 Domain name options

For convenience, it will normally be the case that modules are assigned domain names. An IP system
can operate fully without this logical step but it is useful to reduce the complexity. As the IP address
may change in time, resolution locally by unique name is more convenient, scalable and inter-operable.
Module names are assigned and registered to point to the IP address of the module. The registration of
names is independent from the allocation of IP addresses.
There are two principal ways of name management: server based ("unicast") or distributed
("multicast"). Figure 3 illustrates the two methods. The Multicast Domain Name System (mONS) is
recommended for the primary network.

13
UNI CENITS 13 149-7 :2015
 METATRONIX SRL· 2017373· XPOD

CEN/TS 13149·7:2015 (E)

GEq �ONS0se
1
ose ��>--::
8qmONS o EG
�r- m��s q
ONSCI I IONSCI I
:7
I T
Eqose
GrnONS
Key
ONS S Domain Name System Server
ONS e Domain Name System Client
Eq Module

App Application

mON S se Multicast Domain Name System Server + Client

Figure 3 - DNS architecture and Multicast DNS architecture (example)

5.5.2 Unicast Domain Name System (DNS)

Unicast DNS or classical DNS, is commonly used in global networking. This system has a hierarchical
server system, where globally unique names shall be assigned, allocated and managed. It translates
domain names into IP addresses for locating modules or services in a network.
The definitive descriptions of the rules for forming domain names are given in RFCI035, RFC1123, and
RFC2181.
Name assignment via unicast DNS is not recommended in the context of this Technical Specification
because of the load it may place on the DNS server in a potentially restricted environment.
5.5.3 Multicast Domain Name System (mDNS)

mDNS is similar to a Unicast DNS, except that in the case of mDNS, each module hosts its own DNS
server that listens and responds on a multicast channel. mDNS simplifies name resolution and enables
dynamic scalability and evolution in a local network. mDNS is defined in RFC6762.
In mDNS, the modules send a DNS query to the multicast address in the same domain (.Iocal), on a
dedicated port (5353) using the UDP protocol. mDNS is recommended in the IP on board network, in
order to simplify and to avoid heavy maintenance and update of a unicast DNS server.
Module names shall be defined based on module class and a two·digit index.
The following module classes are recommended to be used. Additional classes can be defined.

14
UNI CENITS 13149·7:2015
 METATRONIX SRL -2 0 17373 -XPOD

CEN/TS 13149-7:2015 (E)

Table 2 - Module classes

OnBoardUnit TicketVendingMa chine Printer

SideOisplay Annou ncementSystem AutomaticPassengerCounting

FrontOisplay MMI Mobilel nterface

RearOisplay CommunicationGateway TestDevice

InteriorOisplay VideoSystem Other

TicketValidator Camera

Examples for module names constructed under this protocol include OnBoardUnitOl, FrontDisplayOl
FrontDisplay02, CameraOl, Camera02 and Camera03.
5.6 Communication Protocols

5.6.1 The IP suite

The Internet Protocol suite is the set of communications protocols used for the Internet and similar
networks, and generally the most popular protocol stack for wide area networks. Under the huge
number of protocols based on IP the following are recommended in this Technical Specification.
5.6.2 The TCP framework

5.6.2.1 Transport Control Protocol (TCP)

The Transport Control Protocol is a transmission protocol for connection oriented communications.
This means that this protocol covers the need to introduce, establish and manage a secure end to end
connection between two entities or destinations. The detailed description and specification are in the
RFC793.
TCP should be used for the exchange of most data types, where time is not critical. It supports the
application layer protocols HTTP, FTP and SSH, which should be used as indicated below.
5.6.2.2 HyperText Transfer Protocol (HTTP)

The HyperText Transfer Protocol is based on TCP. In addition, HTTP defines nine methods (sometimes
referred to as "verbs") indicating the desired action to be performed on the identified resource. In
systems based on the EN 13149 series, the two most important methods are likely to be the GET and
the POST methods. The detailed description and specification are in the RFC2616.
HTTP protocol should be used for event triggered data (see 6.3.1).
5.6.2.3 File Transfer Protocol (FTP)

The File Transfer Protocol is based on TCP and is used for file transfer between two entities. The
detailed description and specification are in RFC959.
FTP protocol should be used for file transfer.
5.6.2.4 Secure Shell (SSH)

The Secure Shell Protocol is based on TCP. It is used for remote terminal access and control. The
detailed description and speCification are in RFC4253.
SSH protocol should be used for remote terminal access and control.

15
UNI CENITS 13149-72
: 015
 METATRONIX SRL - 201 7373 - XPOD

CEN/TS 13149-7:2015 (E)

5.6.3 The UDP framework

5.6.3.1 User Datagram Protocol (UDP)

The User Datagram Protocol is a transmission way for connectionless communications. It allows easy
data exchange between two entities, each defined by an IP address and a port number without
"handshaking mechanisms". Thus UDP does not guarantee the safe delivery of datagrams to destination,
or their arrival order. It is also possible that datagram's are received in multiple copies. This protocol is
used for high frequency and/or high volume data flows where the loss of one datagram is not a critical
issue like GPS coordinates, odometer, ete. and provides a technical base for higher level protocols such
as RTP for video flows (see below). The detailed description and specification are in RFC768.
UDP should be used for high frequency or time-critical data (see 6.3.3). It is also used for the application
layer protocols RTP and NTP/SNTP, as indicated below.
5.6.3.2 Real-time Transport Protocol (RTP)

The Real-time Transport Protocol is based on UDP, in order to manage issues on latency variation (such
jitter and out-of-order packet arrival). The detailed description and specification are in RFC3SS0.
RTP protocol is recommended to be used for stream data (see 6.3.2).
5.6.3.3 Network Time Protocol (NTP) / Simple Network Time Protocol (SNTP)

The Network Time Protocol is based on UDP. It is used for clock synchronization between computer
systems. The detailed description and specification are in RFC130S.
The Simple Network Time Protocol is an alternative to NTP using simplified algorithms. The detailed
description and specification are in RFC4330 and RFCS90S.
SNTP protocol is recommended to be used for clock synchronization.
5.7 Communication methods

5.7.1 Data exchange options

Based on the common use of TCP/IP definition, the general communication in the vehicle is
server/client based. However for this there are several generic mechanisms for data exchange. The
major three which shall be used in this Technical Specification are the Request/Response mechanisms,
the Subscription and the Multicast transmission.
5.7.2 Request/Response

In server/client based communication, the commonly used type of communication is request/response.

This is the most generic way to communicate, typically used by protocols like HTTP (detailed in S.6.2.2)
or FTP (detailed in S.6.2.3).
5.7.3 Subscription

To set up a notification request, the client contacts the server and registers its requirements. As a result
of a demand from one or several clients, the server acknowledges the requests (positively or
negatively). After a successful subscription, the server provides updated data automatically to the
subscribing clients, based on their subscription profiles.
A corresponding request and acknowledgement may be used when a subscribing client wishes to
terminate its subscription.

16
UNI CENITS 13149-7:201 5
 METATRONIX SRL - 20 173 73 - XPOD

CENjTS 13149-7:2015 (E)

5.7.4 Data Multicast

This type of communication behaviour is typically used by network services that are of importance for
many modules on the network, or for data sent out with a high frequency. Figure 4 depicts the
difference between these both mechanisms.
The design recommendation is to use multicast rather than broadcast; it allows for certain devices to be
excluded while maintaining efficiency in message delivery. In addition, IPv6 has no broadcast
mechanism.

Multicast Broadcast

�T n_ )

Tn Tn
Tl
G
T1

G Tn Tn

Key
Tl Data server

Tn Data clients

Figure 4 - Broadcast vs. Multicast (example)

5.8 Network security

The architecture of on-vehicle systems shall be secure against both endogenous (internally-generated)
and exogenous (externally-generated) threats.
Endogenous threats arise from malicious or badly engineered modules being connected to the network.
Confidentiality compromise may arise if one module should allow external access to a second module
on the network. Availability compromise may arise if one module sends messages which swamp the
network.
Exogenous threats include deliberate compromise from hacking, viruses and denial of service attacks,
which come through the general I nternet. They also include network overload arising from other
connected systems such as gateways to other networks or from "tunneled" services such as advertising
or services to passenger modules.
Individual components should be designed to protect themselves against threats to integrity and
confidentiality, as if they were connected to an unprotected network.
This includes technical security aspects such as firewall protection. Protection should be kept regularly
updated, as the threat environment is continually evolVing.
If network security is specifically requested for a function, secure communication protocols shall be
used.

17
UNI CENfTS 13 149-7:20 15
 METATRONIX SRl · 2 0 17373 · XPOD

CEN/TS 13149·7:2015 (E)

5.9 Considerations on coupled vehicles

Vehicles may be coupled physically (as typically on rail trains), or virtually (e.g. because they are
travelling in convoy). A physical connection may allow for a fixed (wired) communication connection,
whereas a virtual connection will need to rely on radio communication and be much more susceptible
to interruption.
For establishing a communication network between two (or more) coupled vehicles there are two
possibilities:
a network in each vehicle;

a common network for all vehicles.

If a common network is used for all modules in all vehicles, then the bandwidth for communication over
the vehicle connections shall be sufficient for fulfilling the inter·vehicle requirements. Additionally,
there are mechanisms needed which start a network reconfiguration process after the coupling or
decoupling of vehicles.
If every vehicle has its own network a service is needed to synchronize any information which it is
desired to exchange between the coupled vehicles.

6 Service architecture

6.1 Service oriented architecture (SOA)

Service·oriented architecture (SOA) is a philosophy of software design, where the functionality of an

application is split into discrete pieces, and the components of this functionality are offered
transparently as "services" to other applications. The receiving application does not need to know the
identity of its data provider: it merely needs to know how the service is constructed. With this kind of
design, the reuse of existing functions in a system is simplified and the complexity of applications may
be reduced.
A Service in an SOA is characterized by the following characteristics:
a Service is available on the network;

a Service represents a technical functionality;

the interface of the Service is well-defined and be published to the service-users;

the Service is independent of the operating system of network and platform or the applications
environment that serves it;

every Service is registered in a public inventory list (Le. available to all authorized users of the
network).

Annex A (informative) provides an example to demonstrate a possible description of services within a

typical vehicle build.
6.2 Service Information

6.2.1 Service framework options

For the publication and discovery of services, the techniques of DNS-SD are recommended. For the
discovery of the needed services, it is important to know the base protocol which is supported by this
service (TCP or UDP), which upper protocols is used and how the service is named (detailed in 6.2.3.2).

18
UNI CENfTS 13 149·7 :20
 METATRONIX SRL - 20173 73 XPOD
-

CEN/TS 13149-7:2015 (E)

As alternative, manual configuration can be used but is not recommended.

6.2.2 Manual configuration

Service registration and discovery can be managed manually with module-by-module configuration
including:
the services which have to be started locally and their attributes;

the services which are expected remotely on the IP network and their hosting modules defined by
an IP address and a port number.

6.2.3 Configuration using DNS-SD

6.2.3.1 Use of DNS-SD

DNS Service Discovery (DNS-SD) should be used for both module and service inventory for the primary
network. This mechanism enables an automatic discovery of which services are available on network
without having to know module or service names in advance.
DNS-SD is defined in RFC 6763. It uses standard DNS programming interfaces, servers, and packet
formats (PTR, SRV and TXT records).
DNS-SD is recommended to be used with mDNS (detailed in 5.5.3). DNS-SD is supported by mDNS but
does not require it.
6.2.3.2 Service registration and naming

For the registration of a service in DNS-SD a SRV record is used. This SRV record consists of the
following attributes:
_< service name > ._ < sub protocol > ._ < upper protocol > . _ < protocol > . < domain > TTL Class
SRV Priority Weight Port Target
The fields are defined as follows:
_ < service name > : the symbolic name of the concerned service;

_< sub protocol > : the sub protocol name of the concerned service;

_ < upper protocol > : the upper protocol name of the concerned service;

_ < protocol > : The protocol name of the service (TCP or UDP);

< domain > : The domain of validity of the service (e.g.: .local);

TTL: DNS field indicating the time to live of the response;

Class: DNS field indicating the class of the service, always IN for the services;

SRV: indicating it is an SRV record;

Priority is the priority of this target host. The client application shall subscribe to the service with
the lowest priority value;

Weight is the server selection mechanism. The weight field specifies a relative weight for entries
with the same priority. If the Priority and the Weight is equal, one of the two is selected randomly;

Port: is the UDP or TCP port where the service is available;

Target: The name of the server that provides this service.

19
UNI CENITS 131 49-7:2015
 METATRONIX SRL - 2017373 - XPOD

CEN/TS 13 149-7:2015 (E)

The DNS-SD name of a service should preferably inform both: the "what" and "how" of a service. Even if
an existing application level protocol is reused, e.g. http, for a new purpose it is recommended not to
use _http for the service name. Rather use a more descriptive name like, e.g. jnventory.
The values for priority and weight are intended for solving naming conflicts.
6.2.3.3 Record maintenance

One of the major goals for this Technical Specification is to provide a flexible environment for IT
systems in public transport vehicles, with a minimum need for manual configuration. To achieve this
flexibility, it is designed not to rely on a Single module to configure other modules. The use of mDNS and
DNS-SD framework permits all modules to search the network to get a current list of what is installed,
and what data are available, and then to self-configure accordingly.
Each module shall populate its TXT and SRV records with relevant information and status.
6.2.3.4 Providing additional information

For providing more information (e.g. multicast address for UDP-based services or versions of different
services) the usage of TXT- Records (defined in RFC1035) is recommended. Using the following syntax,
some additional attributes can be published:
attribute = value

Table 3 shows typical examples of attributes.

Table 3 - Attributes and example usage

Attribute Type of service Example value Description

vel' all Services 1.0 Version of the service

path HTTP Services testversioll_l.l Additional path for add ressing the module
If present, this additional path will be needed
for requests to the HTTP Service

l11ulticast UDP Services 239.0.0.1 Multicast address, where the information is

provided

sntp-server SNTP services 192.168.0.22 Address where the SNTP-Server in the network
can be found

Additional specific attributes can be added for specific services. A standard set is being developed in
prCEN/TS 13 149-9.
6.3 Communication Types

NOTE With regard to the data provided by the services different communication protocols are (best) suited.

6.3.1 Event Triggered Data

If the data provided by the service changes due to external or internal non time-based events, a point­
to-point communication protocol should be used as defined in 5.6.2, in connection with subscription
mechanisms.
The usage of cyclic data requests of consuming services is not recommended.

20
UNI CENITS 13149·7:20 15
 METATRONIX SRL - 2017373 - XPOD

CEN/TS 13149-7:2015 (E)

6.3.2 Streaming of Data

This type of communication is used for synchronous communication. It could use multicast or unicast.
To ensure that packet traffic for a voice (or other media) connection will not be delayed or dropped due
to interference from other lower priority traffic, a relatively high priority is normally set. The needs
resulting from this type of communication may introduce the concept of Quality of Service (QoS).
NOTE Streaming functions can influence the communication flow on the media; in this case, critical messages
could be disturbed unless care is taken to provide these using a high priority mechanism.

6.3.3 High Frequency Data

For the provision of data changing with a high frequency (i.e. data which is provided every 5 s or less)
the usage of UDP is recommended. In an IPv6 environment, such data should be distributed by
multicast.
6.4 Data Structure

6.4.1 Data structure options

For the provision of data in a structured way, there are currently two principal description systems:
XML and ISON.
ISON is nowadays most commonly used in mobile applications, XML in data exchange between servers
and in embedded systems. For the primary network, the use of XML is recommended.
6.4.2 XML

XML is the Extensible Markup Language. Based on tags, pairs of values and attributes, it is
straightforward to communicate easily over different systems or APls. Based on a defined structure,
text coded data provide a nexible and common interface between systems.
XML is a profile of the Standard Generalized Markup Language (SGML; ISO 8879:1986), maintained by
the World Wide Web Consortium (see Bibliography).
The definitions of services in prCEN/TS 13149-9 will be defined using XML.
6.4.3 IS0N

The lavaScript Object Notation (lSON) is used to transfer data in a human readable form and (like XML)
consists of tags, pairs of values and attributes. ISON is defined in RFC7159 and is most commonly used
in data exchange between applications on mobile devices and back office systems.
While ISON is not explicitly used within the EN 13149 Technical Specifications, it may be useful in some
peripheral contexts and for external integration (for example in system management devices).

21
U N I CENITS 131 49-7:2 0 1 5
 METATRONIX SRL -20 17373 -XPOD

CEN/TS 13149-7:Z015 (E)

Annex A
(informative)

Example usages

A_1 Typical vehicle network architecture

Figure A.1 shows an example of on board IP network.

Vl

Key
GATEWAY communication gateway service
Bus-FMS Bus-FMS interface
MI - M2 modules
AI - A4 applications (or functions)
LOC SRV location service
NTP SRV Network Time Protocol (NTP) Service for time synchron ization

FMStolP SRV Bus-FMS to IP gateway service

SRV I to 4 011 board services (any other service)

VI vehicle I

Figure A.1 - Example of on board JP network with services

The primary network is the central blue bar, with the associated services that interact over it. Also
shown are:
a gateway unit (GW), allowing and managing con nectivity to both the outside world and to other
on-board systems (perhaps networks to allow passenger access to the i nternet);

ZZ
UNI CENITS 13149- 7:2015
 METATRONIX SRL - 20 17373 - XPOD

CEN/TS 13149-7:201 5 (E)

- a gateway unit (FMStoIP) allowing and managing connectivity to the vehicle's own management
systems, through the CAN J 1939 network (orange).
Each provides a service on the primary network for these purposes.
Aside from the two network gateways, there are two modules (M1 and M2) shown each of which
delivers three operational services. Individual services are provided through separate applications
(orange boxes).

A.2 Function and service groups

It is convenient to describe services in groups, based on the types of function (or application) that
provide them. A useful list, which has emerged from the European Bus Systems of the Future ( EBSF)
project and from the German IP-KOM- Q V project ("IP communication in public transport"), is as
follows:
Ce nt
r alc ommunic at
i onse rvices are the interface to the background systems like back offices and
ITCS;
B a
sic servicesare the low level functionalities that are based near the real hardware without any
further inelegance e.g. GPS receiver;
Dri v
e rc ommunic at
i onser v
ices provide data to the driver and receive instructions from the driver;
Ve hic e
l op
e rati onse rvices provide information on the vehicle platform, from the vehicle chassis, as
well as on the equipment required for PT operation;
Drivi ng op
er at
i onse rv
ices provide additional information on the operation of the PT service;
Ticke it ngse rvices support all function concerning tickets (e.g. vending, cancellation) inside the
vehicle;
Pa
sse ng
er c ommunic at
i onse rvices provide data for passengers over channels like displays or audio
announcement; in future communication to passenger mobiles may also make use of these services.
These functional groups are currently being used as the basis for the specification of prCEN/TS 13149-
9.

A.3 Example of a service record

An example SRV record (as defined in 6.2.3.2, Service registration and naming) is as follows:
_ServiceExample._OnBoardUnit._http._tcp.locaI 86400 IN SRV 0 0 5060 192.168.0.21
In this example, we have:
the service name is "Se rv
ice£x ampl
e";

the service is provided over HTTP;

the service is provided over rcp;
the service is provided over on the local domain;
the service has a time to live of 86 400 s, i.e. 24 h;
the service has a priority of 0 and a weight of 0;
the service is accessible on port 5060;
the service is delivered by the server at the address 192.168.0.21.

23
UNI CENfTS 13 149-7:20 15
 METATRONIX SRL - 201 73 73 - XPOD

CEN/TS 13149-7:2015 (E)

Bibliography

[1] CEN/TS 1 6614 (all parts), Publ

i cr
t a n
sp or t - N etw o
r ka ndTi meta bleEx ch
a nge(N eTEx)

[2] EN 12896, Roa dr

t a n
sp o
r t a nd r
t affi c t elema it c
s - Publ
i cr
t a n
sp o
r t - Refe
r ence d
a a
t model

[3] C EN/TS 15531 (all parts), Publi c r

t a n
sp o
r t - Se
r v
i cei nt e
raf ce fo
rr e
a -l it mei nfo
r ma it onr ela it ng t o
p ubl
i cr
t a n
sp o
r t o
p e
ra it on
s

[4] ISO/IEC 7498-1 : 1994, Infor ma it on t echnology- Op enSy

s t ems Int e
r connecti on- Basi c
Refe
r enceM odel: T heBasi cM odel

[5] IEEE 802.3, Sta nd

ar d fo
r Info
r ma it onT echnology- E t he
rn et

[6] RFC793 Transmission Control Protocol (TCP)

[7] RFC768 User Datagram Protocol (UDP)

[8] RFC791 IPv4 specification

[9] RFC959 File Transfer Protocol (FTP)

[10] RFCl035 Domain names - implementation and specification

[11] RFC l 123 Requirements for Internet Hosts - Application and Support

[12] RFC1305 Network Time Protocol (VerSion 3) Specification, Implementation and Analysis

[13] RFC1323 TCP Extensions for high performance

[14] RFCl918 Address Allocation for Private Internets

[15] RFC2131 Dynamic Host Configuration Protocol

[16] RFC2181 Clarifications to the DNS Specification

[17] RFC2616 Hypertext Transfer Protocol - HTTP/Ll

[18] RFC2460 Internet Protocol, Version 6 (IPv6) Specification

[19] RFC2782 A DNS RR for specifying the location of services (DNS SRV)

[20] RFC3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites

[21] RFC3550 RTP: A Transport Protocol for Real-Time Applications

[22] RFC3927 Dynamic Configuration of lPv4 Link-Local Addresses

[23] RFC4253 The Secure Shell (SSH) Transport Layer Protocol

[24] RFC4291 IP Version 6 Addressing Architecture

24
UNI CENITS 1 3 149-7:2015
 METATRONIX SRL - 20 17373 -XPOD

CEN/TS 13149-7:2015 (E)

[25] RFC4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI

[26] RFC4862 IPv6 Stateless Address Autoconfiguration

[27] RFCS905 Network Time Protocol Version 4: Protocol and Algorithms Specification

[28] RFC6762 Multicast DNS, Further information on multicast DNS operation can be found through
IANA at http://www,iana,org/assignments/multicast-addresses for IPv4, mDNS for IPv6 is
Similarly presented at http://www,iana,org/assignments/ipv6-multicast-addresses

[29] RFC6763 DNS-Based Service Discovery

[30] RFC7159 The JavaScript Object Notation (JSON) Data Interchange Format

[31] The current version of XML is described in http://www,w3,org/TR/2008/REC-xml-20081126

25
UNI CENfTS 131
49-7:2015
 METATRONIX SRL - 20 17373 - XPOD

Via Sannio, 2 - 20137 Milano Riproduzione vietala

ENTE ITAUANo Via delle Colonnelle, 18 - 00186 Roma Legge 22 aprile 1941 N° 633
e successivi aggiornamenli.
01 NoRMAZloNE www.unLcom