EN 50159-2:2001

Railway applications - Communication, signalling and processing systems - Part 2: Safety related communication in open transmission systems

Technically equivalent to IEC 62280-2:2002 (Boomerang case) * D115/201: Not to be renumbered as EN 62280-2 * Superseded by EN 50159:2010

Bahnanwendungen - Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme - Teil 2: Sicherheitsrelevante Kommunikation in offenen Übertragunssystemen

Applications ferroviaires - Systèmes de signalisation, de télécommunication et de traitement - Partie 2: Communication de sécurité sur des systèmes de transmission ouverts

Železniške naprave – Komunikacijski, signalni in procesni sistemi – 2. del: Varnostna komunikacija v odprtih prenosnih sistemih

General Information

• Status: Withdrawn
• Publication Date: 22-Mar-2001
• Withdrawal Date: 31-Dec-2002
• ICS: 35.240.60 - IT applications in transport
• ICS: 45.020 - Railway engineering in general
• Technical Committee: CLC/TC 9X - Electrical and electronic applications for railways
• Drafting Committee: CLC/SC 9XA - Communications, signalling and processing systems
• Parallel Committee: IEC/TC 9 - IEC_TC_9
• Current Stage: 9960 - Withdrawal effective - Withdrawal
• Start Date: 01-Sep-2013
• Completion Date: 01-Sep-2013
• Directive: 2008/57/EC - Directive 2008/57/EC of the European Parliament and of the Council of 17 June 2008 on the interoperability of the rail system within the Community (Recast)
• Directive: 96/48/EC - Interoperability of the trans-European high-speed rail system
• Mandate: M/024 - Mandate to CEN/CENELEC/ETSI for programming and standardization in the field of railway equipment
• Ref Project: SIST EN 50159-2:2002 - Railway applications - Communication, signalling and processing systems -- Part 2: Safety related communication in open transmission systems

Relations

• Replaced By: EN 50159:2010 - Railway applications - Communication, signalling and processing systems - Safety-related communication in transmission systems
• Effective Date: 28-Jan-2023

Standards Content (Sample)

SLOVENSKI SIST EN 50159-2:2002
prva izdaja
STANDARD
julij 2002
Železniške naprave – Komunikacijski, signalni in procesni sistemi – 2. del:
Varnostna komunikacija v odprtih prenosnih sistemih
Railway applications - Communication, signalling and processing systems - Part 2:
Safety-related communication in open transmission systems
ICS 35.240.60; 45.020 Referenčna številka
©  Standard je založil in izdal Slovenski inštitut za standardizacijo. Razmnoževanje ali kopiranje celote ali delov tega dokumenta ni dovoljeno

EUROPEAN STANDARD EN 50159-2
NORME EUROPÉENNE
EUROPÄISCHE NORM March 2001
ICS 35.240.60; 45.020
English version
Railway applications -
Communication, signalling and processing systems
Part 2: Safety related communication in open transmission systems
Applications ferroviaires - Bahnanwendungen -
Systèmes de signalisation, de Telekommunikationstechnik, Signal-
télécommunication et de traitement technik und Datenverarbeitungssysteme
Partie 2: Communication de sécurité sur Teil 2: Sicherheitsrelevante
des systèmes de transmission ouverts Kommunikation in offenen Übertragungs-
systemen
This European Standard was approved by CENELEC on 2000-01-01. CENELEC members are bound
to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any
other language made by translation under the responsibility of a CENELEC member into its own
language and notified to the Central Secretariat has the same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Czech
Republic, Denmark, Finland, France, Germany, Greece, Iceland, Ireland, Italy, Luxembourg,
Netherlands, Norway, Portugal, Spain, Sweden, Switzerland and United Kingdom.
CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
Central Secretariat: rue de Stassart 35, B - 1050 Brussels
© 2001 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 50159-2:2001 E
Foreword
This European Standard was prepared by SC 9XA, Communication, signalling and processing systems, of
Technical Committee CENELEC TC 9X, Electrical and electronic applications for railways.
The text of the draft was submitted to the formal vote and was approved by CENELEC as EN 50159-2 on
2000-01-01.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2001-10-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2003-01-01
Annexes designated “informative” are given for information only.
In this standard, annexes A, B, C and D are informative.

- 3 - EN 50159-2:2001
Contents
Introduction .4
1  Scope .5
2  Normative references.5
3  Definitions.5
4  Reference architecture .11
5  Threats to the transmission system.13
6  Requirements for defences .13
6.1  Introduction.13
6.2  General requirements.14
6.3  Specific defences .14
7  Applicability of defences against threats.19
7.1  Introduction.19
7.2  Threats/defences matrix .19
7.3  Choice and use of safety code and cryptographic techniques.20
Annex A (informative)  Guideline for defences.21
A.1  Applications of time stamps .21
A.2  Choice and use of safety codes and cryptographic techniques .22
Annex B (informative) Bibliography.28
Annex C (informative) Guidelines for use of the standard.29
C.1  Scope/purpose.29
C.2  Classification of transmission systems.29
C.3  Procedure.31
C.4  Example.32
Annex D (informative) Threats on open transmission systems.36
D.1  System view.36
D.2  Derivation of the basic message errors .37
D.3  Threats.38
D.4  A possible approach for building a safety case.39
D.5  Conclusions.43

Introduction
If a safety-related electronic system involves the transfer of information between different locations, the
communication system then forms an integral part of the safety-related system and it must be shown that
the end to end transmission is safe in accordance with ENV 50129.
The safety requirements for a data communication system depend on its characteristics which can be
known or not. In order to reduce the complexity of the approach to demonstrate the safety of the system
two classes of transmission systems have been considered. The first class consists of the ones over which
the safety system designer has some degree of control. It is the case of the closed transmission systems
whose safety requirements are defined in EN 50159-1. The second class, named open transmission
system, consists of all the systems whose characteristics are unknown or partly unknown. This standard
defines the safety requirements addressed to the transmission through open transmission systems.
The transmission system, which is considered in this standard, has in general no particular preconditions to
satisfy. It is from the safety point of view not or not fully trusted and is considered as a ”black box”.
This standard is closely related to EN 50159-1 ”Safety-related communication in closed transmission
systems” and ENV 50129 ”Safety related electronic systems for signalling”.
The standard is dedicated to the requirements to be taken into account for the transmission of safety-
related information over open transmission systems.
Cross-acceptance, aimed at generic approval and not at specific applications, is required in the same way
as for ENV 50129 ”Safety related electronic systems for signalling”.

- 5 - EN 50159-2:2001
1  Scope
This European Standard is applicable to safety-related electronic systems using an open transmission
system for communication purposes. It gives the basic requirements needed, in order to achieve safety-
related transmission between safety-related equipment connected to the open transmission system.
This standard is applicable to the safety requirement specification of the safety-related equipment,
connected to the open transmission system, in order to obtain the allocated safety integrity level.
The properties and behaviour of the open transmission system are only used for the definition of the
performance, but not for safety. Therefore from the safety point of view the open transmission system can
potentially have any property, as various transmission ways, storage of messages, unauthorised access,
etc. The safety process shall only rely on properties, which are demonstrated in the safety case.
The safety requirement specification is a precondition of the safety case of a safety-related electronic
system for which the required evidences are defined in ENV 50129. Evidence of safety management and
quality management has to be taken from ENV 50129. The communication related requirements for
evidence of functional and technical safety are the subject of this standard.
This standard is not applicable to existing systems, which had already been accepted prior to the release of
this standard.
This standard does not specify:
- the open transmission system,
- equipment connected to the open transmission system,
- solutions (e.g. for interoperability),
- which kinds of data are safety-related and which are not.
2  Normative references
This European Standard incorporates by dated or undated reference, provisions from other publications.
These normative references are cited at appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of these publications apply to this
European Standard only when incorporated in it by amendment or revision. For undated references the
latest edition of the publication referred to applies.
EN 50126 Railway applications - The specification and demonstration of Reliability, Availability,
Maintainability and Safety (RAMS)
EN 50128 Railway applications - Communications, signalling and processing systems - Software
for railway control and protection systems
ENV 50129 Railway applications - Safety related electronic systems for signalling
3  Definitions
For the purpose of this standard, the following definitions apply:
3.1
access protection
processes designed to prevent unauthorised access to read or to alter information, either within user
safety-related systems or within the transmission system
3.1.1
hacker
a person trying deliberately to bypass access protection

3.2
authenticity
the state in which information is valid and known to have originated from the stated source
3.3
authorisation
the formal permission to use a product/service within specified application constraints
3.3.1
unauthorised access
a situation in which user information or information within the transmission system is accessed by
unauthorised persons or hackers
3.3.2
confidentiality
the property that information is not made available to unauthorised entities
3.4
check
a process to increase assurance about the state of a system
3.4.1
redundancy check
a type of check that a predefined relationship exists between redundant data and user data within a
message, to prove message integrity
3.5
cryptographic techniques
output data are calculated by an algorithm using input data and a key as a parameter. By knowing the
output data, it is impossible within a reasonable time to calculate the input data without knowledge of
the key. It is also impossible within a reasonable time to derive the key from the output data, even if
the input data are known
3.6
data
a part of a message which represents some information
3.6.1
data corruption
the alteration of data
3.6.2
user data
data which represents the states or events of a user process, without any additional data. In case of
communication between safety-related equipment, the user data contains safety-related data
3.6.3
additional data
data which is not of any use to the ultimate user processes, but is used for control, availability, and
safety purposes
3.6.4
redundant data
additional data, derived, by a safety-related transmission process, from the user data

- 7 - EN 50159-2:2001
3.6.4.1
safety code
redundant data included in a safety-related message to permit data corruptions to be detected by the
safety-related transmission process. Suitable encoding techniques may include
3.6.4.1.1
non cryptographic safety code
redundant data based on non cryptographic functions included in a safety-related message to permit
data corruptions to be detected by the safety-related transmission process
3.6.4.1.1.1
cyclic redundancy check (CRC)
the CRC is based on cyclic codes, and is used to protect messages from the influence of data
corruptions
3.6.4.1.2
cryptographic safety code
redundant data based on cryptographic functions included in a safety-related message to permit data
corruptions and unauthorised access to be detected by the safety-related transmission process
3.6.4.1.2.1
message authentication code (MAC)
a cryptographic function of the whole message and a secret or public key. By the whole message is
meant also any implicit data of the message which is not sent to the transmission system
3.6.4.1.2.2
manipulation detection code (MDC)
a function of the whole message, but in contrast to a MAC there is no secret key involved. By the
whole message is meant also any implicit data of the message which is not sent to the transmission
system. The MDC is often based on a hash function
3.6.4.2
sequence number
an additional data field containing a number that changes in a predefined way from message to
message
3.6.4.3
time stamp
information attached to a message by the sender
3.6.4.3.1
relative time stamp
a time stamp referenced to the local clock of an entity is defined as a relative time stamp. In general
there is no relationship to clocks of other entities
3.6.4.3.2
absolute time stamp
a time stamp referenced to a global time which is common for a group of entities using a transmission
network is defined as an absolute time stamp
3.6.4.3.3
double time stamp
when two entities exchange and compare their time stamps, this is called double time stamp. In this
case the time stamps in the entities are independent of each other

3.6.4.4
source and destination identifier
an identifier is assigned to each entity. This identifier can be a name, number or arbitrary bit pattern.
This identifier will be used for the safety-related transmission. Usually the identifier is added to the
user data
3.7
defence
a measure incorporated in the design of a safety communication system to counter particular threats
3.8
error
a deviation from the intended design which could result in unintended system behaviour or failure
3.9
failure
a deviation from the specified performance of a system. A failure is the consequence of an fault or
error in the system
3.9.1
random failure
a failure that occurs randomly in time
3.9.2
systematic failure
a failure that occurs repeatedly under some particular combination of inputs, or under some particular
environmental condition
3.10
fault
an abnormal condition that could lead to an error in a system. A fault can be random or systematic
3.10.1
random fault
the occurrence of a fault based on probability theory and previous performance
3.10.2
systematic fault
an inherent fault in the specification, design, construction, installation, operation or maintenance of a
system, subsystem or equipment
3.11
hazard
a condition that can lead to an accident
3.11.1
hazard analysis
the process of identifying the hazards which a product or its use can cause
3.12
information
a representation of the state or events of a process, in a form understood by the process
3.13
integrity
the state in which information is complete and not altered

- 9 - EN 50159-2:2001
3.14
message
information, which is transmitted from a sender (data source) to one or more receivers (data sink)
3.14.1
valid message
a message whose form meets in all respects the specified user requirements
3.14.2
message integrity
a message in which information is complete and not altered
3.14.3
authentic message
a message in which information is known to have originated from the stated source
3.14.4
message stream
an ordered set of messages
3.14.5
message enciphering
transformation of bits by using a cryptographic technique within a message, in accordance with an
algorithm controlled by keys, to render casual reading of data more difficult. Does not provide
protection against data corruption
3.14.6
feedback message
a feedback message is defined as a response from a receiver to the sender, via a return transmission
channel
3.14.7
message handling
the processes, outside the direct control of the user, which are involved in the transmission of the
message stream between participants
3.14.8
message errors
a set of all possible message failure modes which can lead to potentially dangerous situations, or to
reduction in system availability. There may be a number of causes of each type of error
3.14.8.1
repeated message
a type of message error in which a single message is received more than once
3.14.8.2
deleted message
a type of message error in which a message is removed from the message stream
3.14.8.3
inserted message
a type of message error in which an additional message is implanted in the message stream
3.14.8.4
resequenced message
a type of message error in which the order of messages in the message stream is changed

3.14.8.5
corrupted message
a type of message error in which a data corruption occurs
3.14.8.6
delayed message
a type of message error in which a message is received at a time later than intended
3.14.8.7
masqueraded message
a type of inserted message in which a non-authentic message is designed to appear to be authentic
3.15
process
3.15.1
user process
a process within an application that contributes directly to the behaviour specified by the user of the
system
3.15.2
transmission process
a process, within an application, that contributes only to the transmission of information between user
processes, and not to the user processes themselves
3.15.3
access protection process
a process within a system that contributes only to the access protection of information in the system,
and not to the user processes or transmission processes themselves
3.16
safety
freedom from unacceptable levels of risk
3.16.1
safety-related
carries responsibility for safety
3.16.2
safety integrity level
a number which indicates the required degree of confidence that a system will meet its specified
safety features
3.16.3
safety case
the documented demonstration that the product complies with the specified safety requirements
3.17
transmission system
a service used by the application to communicate message streams between a number of
participants, who may be sources or sinks of information
3.17.1
closed transmission system
a fixed number or fixed maximum number of participants linked by a transmission system with well
known and fixed properties, and where the risk of unauthorised access is considered negligible

- 11 - EN 50159-2:2001
3.17.2
open transmission system
a transmission system with an unknown number of participants, having unknown, variable and non-
trusted properties, used for unknown telecommunication services, and for which the risk of
unauthorised access shall be assessed
3.18
threat
a potential violation of safety including access protection of a communication system
3.19
timeliness
the state in which information is available at the right time according to requirements
3.20
validity
the state of meeting in all respects the specified user requirements.
4  Reference architecture
This reference architecture for a safety-related transmission system is based on:
• The non trusted transmission system, whatever internal transmission protection mechanisms are
incorporated.
• The safety-related transmission functions.
• The safety-related access protection functions.
For the purposes of this standard, the open transmission system is assumed to consist of everything
(hardware, software, transmission media, etc.) occurring between two or more safety-related equipment
which are connected to the transmission system.
The open transmission system can contain some or all of the following:
• Elements which read, store, process or re-transmit data produced and presented by users of the
transmission system in accordance with a program not known to the user. The number of the users is
generally unknown, safety-related and non safety-related equipment and equipment which are not
related to railway applications can be connected to the open transmission system.
• Transmission media of any type with transmission characteristics and susceptibility to external
influences which are unknown to the user.
• Network control and management systems capable of routing (and dynamically re-routing) messages
via any path made up from one or more than one type of transmission media between the ends of open
transmission system, in accordance with a program not known to the user.
The open transmission system may be subject to the following:
• Other users of the transmission system, not known to the control and protection system designer,
sending unknown amounts of information, in unknown formats.
• User of the transmission system who may attempt to gain access to data originating from other users, in
order to read it and/or mimic it without authorisation from the system manager to do so.
• Any kind of additional threats to the integrity of the safety-related data.
A principle structure of the safety-related system using an open transmission system is illustrated in
Figure 1. The principle model of a safety-related message is shown in Figure 2.

No safety requirements shall be placed upon the non-trusted characteristics of the open transmission
system. Safety aspects are covered by applying safety procedures and safety encoding to the safety-
related transmission functions.
Non Safety-Related
Safety-Related Safety-Related
Equipment
Equipment Equipment
Non
Safety-Related
Safety-Related Application
Application Application
Process
Process Process
Information
Information
Defences
Safety-Related Safety-Related
against
Transmission Transmission
transmission
Process Process
errors
Safety-Related
Defences Transmission
Safety-Related Safety-Related
against
System
Access Protection Access Protection
unauthorised
Process Process
access EN 50159-2
Safety-Related
Message
Open Transmission System
Figure 1 - Structure of safety-related system using a non trusted transmission system
Additional Data of the Open Transmission System
Safety-Related Access Protection
Safety-Related
Transmission Protection
User Data
Safety-Related
Application
Message
Information
Figure 2 - Model of a safety-related message

- 13 - EN 50159-2:2001
5  Threats to the transmission system
Only threats to the transmission systems shall be considered. Threats to the safety-related equipment shall
be considered in accordance with ENV 50129.
This standard refers to communications between generic applications using a transmission system whose
characteristics are (at least partially) unknown.
It is therefore necessary to define a main hazard for safety independently from the functionality of the
particular application and of the characteristics of the network; the pertinent definition is: ”Failure to obtain
an authentic (and consequently valid) message at the receiver end”.
With reference to annex D, a set of possible basic message errors has been derived.
The corresponding threats are:
• repetition,
• deletion,
• insertion,
• resequence,
• corruption,
• delay,
• masquerade.
Meeting the requirements of this standard does not give protection against intentional or unintentional
misuse coming from authorised sources. The safety case shall address these aspects.
6  R equirements for defences
6.1  Introduction
Certain techniques have been adopted in data transmission systems (non-safety-related, safety-related) in
the past. These techniques form a ”library” of possible methods accessible to the control and protection
system designer, to provide protection against each threat identified above.
These techniques that can be seen as logical defences are not a complete set, new techniques may be
developed in the future which offer new possibilities to the designer. Such new techniques may be used to
provide protection against these threats, provided that the coverage of the techniques is well understood
and has been analysed.
To reduce the risk associated with the threats identified in the preceding section, the following safety
services shall be considered and provided to the extent needed for the application:
• message authenticity,
• message integrity,
• message timeliness,
• message sequence.
The following set of known defences has been outlined:
a) Sequence number;
b) Time stamp;
c) Time-out;
d) Source and destination identifiers;
e) Feedback message;
f) Identification procedure;
g) Safety code;
h) Cryptographic techniques.
6.2  General requirements
1) Adequate defences shall be provided against all identified threats to the safety of systems using open
communication networks. Any threats which are not to be assumed shall be agreed with the safety
authority and/or railway authority and shall be put into the safety-related application conditions. Annex
D derives a possible list of threats, to be used as guidance.
2) Detailed requirements for the defences needed for the application shall take into account:
- the level of risk (frequency/consequence) identified for each particular threat, and
- the safety integrity level of the data and process concerned.
Annex A (guidelines for defences) gives guidance on the selection of currently known techniques to
give defence against threats. Issues of effectiveness addressed in this annex should be carefully
considered when the defence is chosen.
3) The requirements for the defences needed shall be included in the system requirements specification
and in the system safety requirements specification for the application, and shall form input to the
”assurance of correct operation” portion of the safety case for the application.
4) All defences shall be implemented according to the requirements defined in ENV 50129. This implies
that the defences:
- shall be implemented completely within the safety-related transmission equipment of the system, or
- may include access protection measures not implemented within the safety-related equipment. In
this case, the continued correct functioning of the access protection processes shall be checked
with adequate safety-related techniques for the application.
5) Mandatory requirements for particular defences are given in the following sections. They apply when
the particular defence is used.
6) Other defences than those described in this standard may be used, provided that analysis of their
effectiveness against threats is included in the safety case.
7) The safety case, as described in ENV 50129 shall include:
- analysis of each defence used in the safety transmission system,
- the safety reaction in case of a detected transmission error.
6.3  Specific defences
The following subclauses show short introductions and the requirements for specific defences, which are
effective either alone or in combination against single or combined threats. All general requirements listed
above shall be applied.
More detailed descriptions of the defences and the relation with all possible threats are given in informative
annex A (guidelines for defences).

- 15 - EN 50159-2:2001
6.3.1  Sequence number
6.3.1.1  Introduction
Sequence numbering consists of adding a running number (called sequence number) to each message
exchanged between a transmitter and a receiver. This allows the receiver to check the sequence of
messages provided by the transmitter.
6.3.1.2  Requirements
The safety case shall demonstrate the appropriateness in relation to the safety integrity level of the
process, and the nature of the safety-related process, of the following:
• the length of the sequence number;
• the provision for initialisation of the sequence number;
• the provision for recovery following interruption of the sequence of the messages.
6.3.2  Time stamp
6.3.2.1  Introduction
When an entity receives information the meaning of the information is often time related. The degree of
dependence between information and time may differ between applications. In certain cases old
information can be useless and harmless and in other cases the information could be a potential danger for
the user. Depending on the behaviour in time of the processes which interchange information (cyclic, event
controlled etc.) the solution may differ.
One solution which covers time-information relationships is to add time stamps to the information. This kind
of information can be used in place of or combined with sequence numbers depending on application
requirements. Different uses of time stamps and their properties are shown in annex A.
6.3.2.2  Requirements
The safety case shall demonstrate the appropriateness in relation to the safety integrity level of the
process, and the nature of the safety-related process, of the following:
• the value of the time increment;
• the accuracy of the time increment;
• the size of the timer;
• the absolute value of the timer (e.g. UTC (universal co-ordinated time) or any other global clock);
• the synchronism of the timers in the various entities;
• the time delay between originating of information and adding a time stamp to it;
• the time delay between checking the time stamp and using the information.
6.3.3  Time-out
6.3.3.1  Introduction
In transmission (typically cyclic) the receiver can check if the delay between two messages exceeds a
predefined allowed maximum time. If this is the case, an error shall be assumed.

Figure 3 - Cyclic transmission of messages
If a back channel is available, supervision can be performed by the sender. The sender starts a timer when
sending a message i. The receiver of message i responds with an acknowledge message j related to the
received message i. If the sender does not receive the corresponding acknowledge message j within a
predefined time, an error shall be assumed.

Figure 4 - Bi-directional transmission of messages
6.3.3.2  Requirements
The safety case shall demonstrate the appropriateness in relation to the safety integrity level of the process
and the nature of the safety related process of the following:
• the acceptable delay,
• the accuracy of the time-out.
6.3.4  Source and destination identifiers
6.3.4.1  Introduction
Multi-party communication processes need adequate means for checking the source of all information
received, before it is used. Messages shall include additional data to permit this.
Messages may contain a unique source identifier, or a unique destination identifier, or both. The choice is
made according to the safety-related application. These identifiers are added in the safety-related
transmission functions for the application.

- 17 - EN 50159-2:2001
• Inclusion of a source identifier in messages can enable users of the messages to verify that messages
are from the intended source, without the need for any dialogue between users. This can be useful, for
example, in uni-directional or broadcast communication systems.
• Inclusion of a destination identifier in messages can enable users of the messages to verify that
messages are intended for them, without the need for any dialogue between users. This can be useful,
for example, in uni-directional or broadcast communication systems. Destination identifiers can be
chosen to identify individual destinations, or groups of users.
6.3.4.2  Requirements
The safety case shall demonstrate the appropriateness, in relation to the safety integrity level of the
process and the nature of the safety-related process, of the following:
• the uniqueness of the identifiers for entities in the entire transmission system;
• the size of the identifier data field.
6.3.5  Feedback message
6.3.5.1  Introduction
Where an appropriate transmission channel is available, a feedback message may be sent from the
receiver of safety-critical information to the sender. The contents of this feedback message may include:
• data derived from the contents of the original message, in identical or altered form;
• data added by the receiver, derived from its own local user process information;
• additional data for safety or security purposes.
The use of such a feedback message can contribute to the safety of the process in a variety of ways:
• by providing positive confirmation of reception of valid and timely messages;
• by providing positive confirmation of reception of corrupted messages, to enable appropriate action to
be taken;
• by confirming the identity of the receiving equipment;
• by facilitating synchronisation of clocks in sending and receiving equipment;
• by facilitating dynamic checking procedures between parties;
• etc.
6.3.5.2  Requirements
The existence of a return channel does not intrinsically provide a defence against any identified threat; it is
an enabling mechanism for other defences at the application level. Therefore, there are no specific safety
requirements for such a feedback channel.
6.3.6  Identification procedure
6.3.6.1  Introduction
The previous section covered the requirements for entities to be identified.
Open transmission systems may additionally introduce the risk of messages from other (unknown) users
being confused with information originating from an intended source (a form of masquerade).
A suitably designed identification procedure within the safety-related process can provide a defence against
this threat.
Two types of identification procedure can be distinguished:
• bi-directional identification
Where a return communication channel is available, exchange of entity identifiers between senders and
receivers of information can provide additional assurance that the communication is actually between
the intended parties.
• dynamic identification procedures
Dynamic exchange of information between senders and receivers, including transformation and
feedback of received information to the sender, can provide assurance that the communicating parties
not only claim to possess the correct identity, but also behave in the manner expected. This type of
dynamic identification procedure can be used to preface the transmission of information between
communicating safety-related processes and/or it can be used during the information transmission itself.
6.3.6.2  Requirements
Identification procedure forms a part of the safety-related application process. The detailed requirements
shall be defined in the safety requirement specification.
6.3.7  Safety code
6.3.7.1  Introduction
In an open transmission system, in general, transmission codes are used to detect bit and/or burst errors,
and/or to improve the transmission quality by error correction techniques.
The safety-related process shall not trust those transmission codes from the point of view of safety.
Therefore an additional safety code under the control of the safety-related process is required to detect
message corruption.
6.3.7.2  Requirements
The safety case shall demonstrate the appropriateness, in relation to the safety integrity level of the
process and the nature of the safety-related process, of the following:
• the capability for detection of all expected types of errors.
• the probability of detection of message corruption.
Guidance for selection of safety codes is given in annex A.
6.3.8  Cryptographic techniques
6.3.8.1  Introduction
Cryptographic techniques can be used if malicious attacks within the open transmission network cannot be
ruled out.
This is usually the case when the safety-related transmission system uses a
• public network;
• radio transmission system;
• transmission system with connections to public networks.
These techniques can be combined with the safety encoding mechanism or provided separately. Annex A
shows some possible solutions.
Cryptographic techniques imply the use of keys and algorithms. The degree of effectiveness depends on
the strength of the algorithms and the secrecy of the keys. The secrecy of a key depends on its length and
its management.
- 19 - EN 50159-2:2001
6.3.8.2  Requirements
The safety case shall demonstrate the appropriateness, in relation to the safety integrity level of the
process and the nature of the safety-related process, of the following:
• technical choice of cryptographic techniques, including
- performance of encryption algorithm
- justification of selected key length
- frequency of key change
- physical storage of keys
• management activities, including
- production, storage, distribution and revocation of confidential keys
- management of equipment
- review process of adequacy of cryptographic techniques, in relation to risks of malicious attacks.
The cryptographic algorithm shall be applied to all user data and it may be applied over some additional
data that is not transmitted but is known to the sender and receiver (implicit data).
Reasonable assumptions shall be described about nature, motivations, financial and technical means of
potential attacker, taking into account also modifications (both technical, as increase of power of
computers, decrease of costs of fast processors, spread of knowledge about algorithms, and ”social”, as
economic conflicts, worsening of vandalism.) that can be expected during the life-time of the system.
For the key management, standardised techniques are highly recommended (e.g. according to
ISO/IEC 11770).
7  Applicability of defences against threats
7.1  Introduction
The defences outlined in clause 6 can be related to the set of possible threats, defined in clause 5. Each
defence can provide protection against one or more threats to the transmission. In the safety case it shall
be demonstrated that there is at least one corresponding defence or combination of defences for the
defined possible threats in accordance to Table 1.
7.2  Threats/defences matrix
The X’s in Table 1 indicate that a defence can provide a protection against the corresponding threat.

Table 1 - Threats/defences matrix

Defences
S equence Time Time- Source and Feed-back Identification Safety Cryptographic
Threats
number stamp out destination message procedure code techniques
identifiers
Repetition X X
Deletion X
2) 1) 1)
Insertion X  X X X
Resequence X X
3)
Corruption    X X
Delay X X
1) 1) 3)
Masquerade   X X  X
1) Application dependent
2) Only applicable for source identifier
Will only detect insertion from invalid source
If unique identifiers cannot be determined because of unknown users, a cryptographic technique shall be used, see 6.3.8.
3) See 7.3 and A.2.
7.3  Choice and use of safety code and cryptographic techniques
The choice of safety code and cryptographic techniques shall be determined according to the following:
• whether or not unauthorised access can be ruled out
• the type of cryptographic code proposed
• whether or not the safety-related access protection process is separated from the safety-related process.
Guidance on these issues is given in A.2.

- 21 - EN 50159-2:2001
Annex A (informative)
Guideline for defences
A.1  Applications of time stamps
A time stamp can be used for different purposes:
1) To state the time of an event in an entity which is of importance for the process receiving the
information. Events can be time related to each other. If we have knowledge of times and values for a
sequence of events it is possible to interpolate between values and increase the accuracy of calculated
values (e.g. for speed, acceleration). Transmission delays can be handled.
Constraints:
• If an absolute time stamp is used, the time in the entities needs to be synchronised. Each entity
needs to have a safe time checking and update of the global time. The network delays have an
effect on global clock distribution, information validity and process performance.
• Absence of messages will not be detected if a dialogue communication procedure is not provided.
2) To order event sequences which can be checked by the receiver.
Constraints:
• If the time granularity is too coarse, the sequencing properties of events can be indeterminate. In
such cases the information shall be complemented with sequence numbers
• The order of messages is affected by network routing of messages and time delays in the network.
• Absence of messages will not be detected if a dialogue communication procedure is not provided.
3) To measure time between events received from an entity sending a sequence of messages thereby
also checking for events not being delayed.
If information from an entity (A) is requested repeatedly from another entity (B), then the latter gets
information of the partner’s local clock from the time stamps. This information can be related to its own
clock by taking the transfer delays into account. A logical clock has been created from the local clock of
entity (B).
Constraints:
• The logical clock is affected by varying time delays in the network and the processing in entity (A).
4) To check the validity of information of an entity (A) by requiring a return of a time stamp delivered from
an entity (B) in a previous message to the entity (A). This ensures a specific response (identity) and
also checks against a predefined loop time. A sequence number (or label) created and time supervised
in entity (B) will do the same work. No global time is needed (unless required by other applications).
The receiver detects loss of information using a time-out.
Constraints:
• The procedure shall handle interruption due to initialisation or fault conditions.
• The procedure will not guarantee authentication of the messages.
5) To create a procedure called double time stamping [A155]. This procedure inherits the properties of a
combination of case 2, 3 and 4. The double time stamping procedure allows for asynchronous clocks in
the entities thereby avoiding problems associated with keeping entities updated with global time. The
method can be used for
a) creating a logical clock from the partners' local clock and relative time stamps from the own local
clock (and organising a clock synchronisation between the two entities);
b) relating events to the relative
...