SIST-TS CEN/TS 13149-7:2016
(Main)Public transport - Road vehicle scheduling and control systems - Part 7: System and Network Architecture
Public transport - Road vehicle scheduling and control systems - Part 7: System and Network Architecture
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/or 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 IEC 61375 series. (See also 4.8.)
Öffentlicher Verkehr - Planungs- und Steuerungssysteme für Straßenfahrzeuge - Teil 7: IP-basierende Vernetzung in einem Fahrzeug, Netzwerk- und Systemarchitektur
Transport public - Systèmes de planification et de contrôle des véhicules routiers - Partie 7 : Architecture Système et Réseau
Javni prevoz - Sistemi za časovno razporejanje in nadzor cestnih vozil - 7. del: Sistem in arhitektura omrežja
Ta tehnična specifikacija določa splošna pravila za podatkovni komunikacijski sistem v vozilu med različnimi sistemi, ki se lahko uporabljajo v vozilih javnega prevoza, vključno s sistemi za podporo delovanja, potniškimi informacijskimi sistemi, sistemi za pobiranje voznine itd.
Ta tehnična specifikacija opisuje naslednje:
– zahteve za omrežje IP v vozilu;
– pregledna arhitektura in komponente za omrežje, ki deluje na podlagi internetnega protokola, v vozilu;
– modularna struktura arhitekture omrežja;
– pristop storitveno usmerjene arhitekture (SOA) in pristop k določanju storitev.
Sistemi, neposredno povezani z varnim upravljanjem vozila (vključno s pogonskim upravljanjem, zavornimi sistemi in sistemi odpiranja vrat), so zunaj področja uporabe te tehnične specifikacije in so obravnavani prek drugih organov za standardizacijo. Vendar se lahko arhitektura, opisana v tej tehnični specifikaciji, uporablja za podporne storitve, npr. za sporočila z varnostnimi informacijami. Vmesniki za ključne varnostne sisteme naj bi bili na voljo prek namenskih prehodov z ustreznimi varnostnimi določbami; za namene te tehnične specifikacije se ti obravnavajo preprosto kot zunanji viri informacij.
Ta tehnična specifikacija je namenjena predvsem za vozila s fiksnim primarnim ogrodjem, kjer je omrežja mogoče namestiti trajno in je sistemska konfiguracija v glavnem sestavljena iz integracije, prilagoditve ali odstranitve funkcionalnih končnih sistemov, ki ustvarjajo in/ali porabljajo podatke. Vozila javnega prevoza, sestavljena iz začasno povezanih enot za namene delovanja (zlasti vlaki, pri katerih se rutinsko priklaplja ali odklaplja lokomotive, vagone ali kompozicije), zahtevajo dodatne mehanizme, ki komunikacijskim omrežjem omogočajo samodejno vnovično konfiguracijo. Ti mehanizmi so na voljo prek drugih standardov, zlasti skupine standardov IEC 61375 (glej tudi 4.8.).
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TS CEN/TS 13149-7:2016
01-marec-2016
-DYQLSUHYR]6LVWHPL]DþDVRYQRUD]SRUHMDQMHLQQDG]RUFHVWQLKYR]LOGHO
6LVWHPLQDUKLWHNWXUDRPUHåMD
Public transport - Road vehicle scheduling and control systems - Part 7: System and
Network Architecture
Öffentlicher Verkehr - Planungs- und Steuerungssysteme für Straßenfahrzeuge - Teil 7:
IP-basierende Vernetzung in einem Fahrzeug, Netzwerk- und Systemarchitektur
Transport public - Systèmes de planification et de contrôle des véhicules routiers - Partie
7 : Architecture Système et Réseau
Ta slovenski standard je istoveten z: CEN/TS 13149-7:2015
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
43.040.15 $YWRPRELOVNDLQIRUPDWLND Car informatics. On board
9JUDMHQLUDþXQDOQLãNLVLVWHPL computer systems
SIST-TS CEN/TS 13149-7:2016 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TS CEN/TS 13149-7:2016
---------------------- Page: 2 ----------------------
SIST-TS CEN/TS 13149-7:2016
CEN/TS 13149-7
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
November 2015
TECHNISCHE SPEZIFIKATION
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 - Systèmes de planification et de Öffentlicher Verkehr - Planungs- und
contrôle des véhicules routiers - Partie 7 : Architecture Steuerungssysteme für Straßenfahrzeuge - Teil 7:
Système et Réseau System- und Netzwerkarchitektur
This Technical Specification (CEN/TS) was approved by CEN on 19 October 2015 for provisional application.
The period of validity of this CEN/TS 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 CEN/TS 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, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR 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.
---------------------- Page: 3 ----------------------
SIST-TS CEN/TS 13149-7:2016
CEN/TS 13149-7:2015 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 6
2 Terms and definitions . 6
3 Symbols and abbreviations . 8
4 Design principles . 8
4.1 Introduction . 8
4.2 Design goals. 9
5 Network architecture . 10
5.1 Introduction . 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 Communication 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 Communication Types . 20
6.4 Data Structure . 21
Annex A (informative) Example usages . 22
A.1 Typical vehicle network architecture . 22
A.2 Function and service groups . 23
A.3 Example of a service record . 23
Bibliography . 24
2
---------------------- Page: 4 ----------------------
SIST-TS CEN/TS 13149-7:2016
CEN/TS 13149-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/or 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 - Part 1: WORLDFIP
definition and application rules for onboard data transmission
— EN 13149-2:2004, Public transport - Road vehicle scheduling and control systems - Part 2: 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 - Road vehicle scheduling and control systems - Part 4: General
application rules for CANopen 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 - Road vehicle scheduling and control systems - Part 6: CAN
message content
— CEN/TS 13149-7:2015, Public transport - Road vehicle scheduling and control systems - Part 7:
System and Network Architecture
— CEN/TS 13149-8:2013, Public transport - Road vehicle scheduling and control systems - Part 8:
Physical layer for IP communication
— prCEN/TS 13149-9, Public Transport - Road Vehicle Scheduling and Control Systems - Part 9: IP-
based Networking Inside A Vehicle, Information Services
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, 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
---------------------- Page: 5 ----------------------
SIST-TS CEN/TS 13149-7:2016
CEN/TS 13149-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 “hotspots” 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 EN 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 EN 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 IP-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 IP-communication networks on board PT vehicles.
This part specifies the cables, connectors and other equipment including pin assignment and
environmental requirements.
1
— prCEN/TS 13149-9 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) In development and registered as CEN/WI 00278382.
4
---------------------- Page: 6 ----------------------
SIST-TS CEN/TS 13149-7:2016
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 IP based solution, this Technical Specification draws on a range of IETF Requests for Comment
(RFCs), not all of which may be formal standards. A list of those cited is presented in the Bibliography.
5
---------------------- Page: 7 ----------------------
SIST-TS CEN/TS 13149-7:2016
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/or 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 IEC 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
---------------------- Page: 8 ----------------------
SIST-TS CEN/TS 13149-7:2016
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 applications 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.
Key
M1 – M4 Modules
SRV1 – SRV5 Services
A1 – 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
---------------------- Page: 9 ----------------------
SIST-TS CEN/TS 13149-7:2016
CEN/TS 13149-7:2015 (E)
3 Symbols and abbreviations
API Application Programming Interface
AVMS Automated Vehicle Monitoring System
AVL Automated Vehicle Location
CAN Controller Area Network
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
IP Internet Protocol
IT Information Technologies
LAN Local Area Network
mDNS Multicast 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
---------------------- Page: 10 ----------------------
SIST-TS CEN/TS 13149-7:2016
CEN/TS 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 or 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
or systems. These again emphasize the need for the on-board systems and networks to be secure,
configurable and adaptable.
9
---------------------- Page: 11 ----------------------
SIST-TS CEN/TS 13149-7:2016
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 shall have a private IP 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.
Modules on the network may be connected physically (as described in CEN/TS 13149-8) or virtually
over alternative IP-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 IP-based). A typical example would be the automotive CAN (Controller Area Network); there
may also be serial buses like RS485; 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, shall be via suitably secure gateways.
Figure 2 shows an example overview of a generic on board IP network, with an external network and
gateway allowing exchange of data between external and primary networks.
10
---------------------- Page: 12 ----------------------
SIST-TS CEN/TS 13149-7:2016
CEN/TS 13149-7:2015 (E)
Key
M1 – M5 Hardware modules
M51 and M52 Virtual modules (hosted by hardware module M5)
M6 Module providing a gateway
IP Primary network
N Other on board network
Figure 2 — A generic on board system with an external network
5.4 IP 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, B or C subnets may be
implemented, as recapped in the table below.
11
---------------------- Page: 13 ----------------------
SIST-TS CEN/TS 13149-7:2016
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
subscribers).
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 allocate in the range 192.168.0.1/24 to 192.168.0.253/24,
holding the address 192.168.0.254 reserved for the default communication gateway of the sub-network (i.e. for
connection to off-vehicle networks).
A module which provides a DHCP server shall be able to have its DHCP server disabled.
12
---------------------- Page: 14 ----------------------
SIST-TS CEN/TS 13149-7:2016
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, [192.168.0.1/24 to 192.168.0.200/24] and second range, [192.168.0.201/24
to 192.168.0.253/24].
— Self and Manual: second range, [169.254.0.201/24 to 169.254.0.253/24]. First range is automatically
allocated.
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 (mDNS) is
recommended for the primary network.
13
---------------------- Page: 15 ----------
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.