/CENELEC Phase 4/EIR/HL/Interface/Non-Functional Interface Requirements

Transcription

1 Project Interface /CENELEC Phase 4/EIR/HL/Interface/ Version: 7.0 Printed by: Holter Printed on: 22 May 2003 Generated from DOORS V5.2 Copyright (c) 2003 UIC / Euro-Interlocking

2 Contents 1 Introduction Background Purpose Scope Unique identification of each statement in the Euro-Interlocking Standard (EIS) 3 2 Requirements Applications Messages Performance Reliability and availability Safety and security Implementation constraints - mandatory Implementation constraints - desirable 9 3 Domain knowledge Domain knowledge: applications Initiation of connection Number of channels Number of addresses Addressing scheme Domain knowledge: messages Functional message volume Event-based communication: message volumes Cyclic communication: message volumes Domain knowledge: performance Network delay Time before reaction to absence of messages owable time delay due to link failure Requirements due to constraints from existing systems Domain knowledge: availability and reliability Availability and reliablity: general considerations Initialisation time and frequency Domain knowledge: safety and security Implementation constraints Physical-layer types Capacity of physical-layer types Relevant CENELEC classes Scope for unauthorised access Minimum capacity Marginal cost of extra capacity Availability Error rate that must be tolerated Message delivery time Redundancy measures to enhance availability Availability of COTS components Long-term support and upgrade Use in command control signalling applications Cost as function of distance 26 4 Terms and abbreviations 26 5 References Documents referenced in text Examples of interface specifications 28 Contents Copyright (c) 2003 UIC / Euro-Interlocking i

3 NFI-1-Com 1 Introduction NFI-2-Com 1.1 Background NFI-3-Com One of the aims of the Euro-Interlocking project is to generate standards for interfacing signalling interlockings with other equipment, where there may be different suppliers of the two systems. The key interfaces are: NFI-4-Com - Interlocking to ETCS Radio Block Centre (RBC) NFI-5-Com - Interlocking to adjacent interlocking (I/L) NFI-6-Com - Interlocking to Traffic Control System (TCS) NFI-7-Com A complete standard for each interface will incorporate both functional and non-functional interface specifications. NFI-8-Com - The functional interface specification will define the types of message passing over the interface and the application protocol. There will be three separate functional interface specifications, one for each interface. NFI-9-Com - The non-functional interface specification shall define how addressing, safety, security and redundancy shall be implemented. There will be only one non-functional specification common to all three interfaces. NFI-10-Com To allow flexibility in the use of commercial, off-the-shelf (COTS) components in the interfaces, the non-functional interface specification will not specify the physical data links. It will, however, at least specify the interface to an appropriate, widely-used industrial transport layer protocol. NFI-11-Com Copyright (c) 2003 UIC / Euro-Interlocking Page 1 of 28

4 TCS-I/L I/L-I/L I/L-RBC Safety, security, addressing Transport layer & physical data links Functional interface specifications Common non- functional interface specification COTS industry standards NFI-31-Com It may be necessary to configure some parameters, such as depending on the type of connection bandwidth, maximum transfer speed, or number of channels. NFI-12-Com This common non-functional interface specification has been identified as the highest priority for the following reasons: NFI-13-Com - it has the widest range of application, to all three interlocking interfaces, and possibly others such as RBC-RBC, and NFI-14-Com - it is intended to be independent on harmonisation of functionality by railways and suppliers. NFI-17-Com 1.2 Purpose NFI-19-Com Within the Euro-Interlocking project, requirements for a standard non-functional interface have been identified. The purpose of this document is to present these requirements and thus provide the remit for a working group of experts who will draft the standard specification. Copyright (c) 2003 UIC / Euro-Interlocking Page 2 of 28

5 NFI-20-Com The requirements in this document have been assembled at a series of workshops of the Euro-Interlocking Interface Specifications (EIIS) working group. This is mainly the industry participants in the Euro-Interlocking project, but the railways have also provided some input. Before finalisation, the document will be reviewed by the Euro-Interlocking Railway Support Team and Industry Support Team. NFI-21-Com 1.3 Scope NFI-22-Com This document comprises non-functional interface requirements for the interfaces from the interlocking system to the traffic control system, to the radio block centre (RBC), and to adjacent interlocking systems. (See also the project context diagram in Euro-Interlocking s Domain Knowledge document.) NFI-222-Com In this document, "interlocking" means "interlocking system", as defined in the Euro-Interlocking Standards. NFI-15-Com This document does not address the RBC-to-RBC interface because it lies outside the scope of the Euro-Interlocking project. However, some requirements may be similar. NFI-16-Com This document does not address the interface between the interlocking and track elements interface because the requirements differ significantly from those of the other interfaces mentioned above. NFI-23-Com 1.4 Unique identification of each statement in the Euro-Interlocking Standard (EIS) NFI-25-Com To allow the unique identification of non-functional interface requirements within the EIS, the letters 'NFI' (non-functional interface) precede the number for each object in this document. NFI-26-Com 2 Requirements NFI-28-Req This chapter presents the non-functional requirements for the three interfaces in question. Copyright (c) 2003 UIC / Euro-Interlocking Page 3 of 28

6 NFI-68-Req An interlocking that uses interfaces based on the interface specification shall be able to comply with the Euro-Interlocking Standards [3], including but not limited to those addressing performance [1], availability [2a] and reliability [2b]. NFI-29-Com 2.1 Applications NFI-30-Req Communication shall take place using logical communication channels between applications running on physically-separated computers. NFI-33-Req Each logical communication channel is a bi-directional link between two applications. Broadcasting is not required. NFI-34-Req Each application shall be capable of establishing separate logical communication channels to other relevant applications. NFI-35-Req The communication shall not impose any real-time constraints on the application (e.g. the application may be cyclic or use a more complex tasking mechanism). NFI-36-Req Each application shall be allocated a logical identification which will uniquely identify it among all other applications using the interface specification to be developed on the basis of this document. NFI-37-Req One of the applications (to be pre-defined) shall initiate connection of a logical communication channel by using the logical identification of the calling and called applications. It is envisioned that in this context, the interlocking system will be the slave (server) and the TSC and RBC will be the masters (clients). Site data of some kind will be necessary to indicate which of two adjacent interlocking systems is the client (master). Copyright (c) 2003 UIC / Euro-Interlocking Page 4 of 28

7 NFI-38-Req Either application shall be able to initiate disconnection at any time. NFI-39-Req When a channel becomes unavailable for any reason, both applications shall be made aware of this quickly enough for them to take action in line with the functional and safety requirements of the application. NFI-40-Com 2.2 Messages NFI-42-Req Exchange of data between applications over each logical communications channel shall be in the form of messages. NFI-43-Req A functional interface specification for each type of application shall define the content of the messages. NFI-44-Req The only constraint on the content of messages from the non-functional interface specification shall be a limit on maximum message length, and a means of identifying the length of message. NFI-45-Req The logical communications channel shall only deliver complete messages. NFI-46-Req The logical communications channel shall deliver the messages to the receiving application in the same order as the sending application sends them. NFI-47-Req The logical communications channel shall provide a means for the receiving application to verify that the delay between sending and receiving the message is less than a pre-defined limit, which may be different for each logical communication channel. NFI-41-Com 2.3 Performance NFI-288-Com The capacity and message delivery time of a logical communication channel shall be sufficient to enable an interlocking to comply with the requirements of the Euro-Interlocking Performance Requirements [1]. Copyright (c) 2003 UIC / Euro-Interlocking Page 5 of 28

8 NFI-302-Com The Euro-Interlocking Performance Requirements specify: 1. High Level Performance Targets (train headways) for a complete railway system (section 3.2). 2. Response times from TCS operator command input to TCS operator status display update (section 3.1). 3. Frequency of status updates on TCS operator status display (section 4.4). 4. Specific response times for processing within the interlocking (section 4.1). NFI-303-Com Items 1-3 in this list need to include some allowance for the performance of the communications between the interlocking and other systems. The requirements specified here are intended to be compatible with these requirements and with the Domain Knowledge in section 3 of the present document. NFI-304-Com The performance of a logical communications channel will be dependent on the performance of the underlying transport layer and physical network. The following requirements are those which an implementation of the Non-functional Interface Specification will be capable of achieving, assuming adequate network capacity and error-free message delivery. For some applications a lower requirement will be adequate and a lower performance network can be tolerated. NFI-305-Req A single logical communications channel shall be capable of delivering messages containing a total of 25,000 octets of application data in one second. NFI-306-Req The message delivery time from one application to another (assuming no requirement to re-send a message because of errors) shall be less than 0.5 seconds. This includes encryption and decryption. Encryption can be either in the same computer as the applications, or in a security gateway as part of the Copyright (c) 2003 UIC / Euro-Interlocking Page 6 of 28

9 communications link. In either case, the message delivery time includes any encryption or decryption. NFI-51-Com 2.4 Reliability and availability NFI-53-Req The availability of a logical communications channel shall enable an interlocking to comply with the Euro-Interlocking Availability Requirements [2a] and Reliability Requirements [2b]. NFI-307-Com The Euro-Interlocking Reliability Requirements specify levels of reliability for two classes of failure: a significant failure and a major failure. Two levels of reliability are specified: R-class High and R-class Normal. In some applications, failure of communication between the interlocking and an RBC, TCS or adjacent interlocking will have an effect equivalent to a significant failure. For this reason, the MBTF of one logical communications channel shall be 10 times the MTBF between signficant failures of an interlocking. These requirements relate to a failure which requires human intervention to repair the system before normal operation can be resumed. NFI-308-Com The availability of a logical communications channel will be dependent on the performance of the underlying transport layer and physical network. The following requirements are those which an implementation of the Non-Functional Interface Specification will be capable of achieving, assuming adequate network reliability and availability, and assuming the use of redundant data links if necessary. For some applications a lower requirement will be adequate and a lower reliability network can be tolerated. Copyright (c) 2003 UIC / Euro-Interlocking Page 7 of 28

10 NFI-309-Req Where the R-class High is required, the MTBF for a logical communications channel, for failures requiring human intervention to restore normal operation, shall be at least 5*10E7 hours (about 6,000 years). NFI-310-Req Where R-class Normal is required, the MTBF for a logical communications channel, for failures requiring human intervention to restore normal operation, shall be at least 10E5 hours (about 10 years). NFI-311-Req The MTBF for a logical communications channel, for failures requiring automatic re-initialisation resulting in a loss of communications for more than 2 seconds, shall be at least 1 year (10E4 hours). NFI-285-Req Availability shall be enhanced by the use of more than one physical data link where necessary. NFI-54-Req Redundancy management of alternative physical data links shall be transparent to the application. NFI-55-Req The interface specification shall take into account the diagnostic and network management systems necessary to achieve required availability. However, physical network management shall lie outside the scope of the interlocking system. NFI-52-Com 2.5 Safety and security NFI-301-Com The appropriate safety integrity level (SIL) for each implementation of an interface will depend on the tolerable hazard rate (THR) resulting from a hazard analysis. It is anticipated that in practice, involved applications and functions will be SIL4. NFI-56-Req The frequency of undetected message corruption shall meet the CENELEC standards EN [1] and EN [2] for vital communications between two SIL4 applications. This shall be true even if one or both of the applications is not SIL4. Copyright (c) 2003 UIC / Euro-Interlocking Page 8 of 28

11 NFI-57-Req In closed networks, protection mechanisms must be provided to address all the possible threats to communication as defined in CENELEC [4]. NFI-58-Req In open networks, protection mechanisms must be provided to address all the possible threats to communication as defined in CENELEC [5]. NFI-59-Req There is no requirement to protect the confidentiality of information contained in messages. NFI-61-Com 2.6 Implementation constraints - mandatory NFI-67-Req The non-functional interface specification shall define rules for use of commercial, off-the-shelf (COTS) transport layer protocols. NFI-69-Req It shall be possible to implement the transport layer on a range of COTS physical networks, to allow the selection of a cost-effective option to suit the available bandwidth and requirements of the application. NFI-70-Req The non-functional interface specification shall not impose any implementation. Each supplier is allowed to implement the different mechanisms either in a multi-layer ISO protocol approach, as a specific interface package or directly at application level, provided the implementation does not restrict the ability to connect units from other suppliers. NFI-71-Req The non-functional interface specification shall not incorporate anything subject to intellectual property rights (IPR) that would prevent the unrestricted use of the specification by any railway or industry participant in the Euro-Interlocking project. NFI-62-Com 2.7 Implementation constraints - desirable NFI-63-Com This section contains additional desirable requirements. These should be satisfied by the non-functional interface specification if possible, but it should be noted they may not be entirely compatible with one another, and with the mandatory requirements. Copyright (c) 2003 UIC / Euro-Interlocking Page 9 of 28

12 NFI-64-Com The non-functional interface specification should make use of TCP and/or UDP as a transport layer protocol and of IP as the network layer. NFI-65-Com The non-functional interface specification should allow a simplified option without any cryptographic coding for use in closed communications networks, for lower-sil applications, or where a COTS security gateway is used [6]. NFI-66-Com The non-functional interface specification should re-use relevant information from ETCS standards, e.g. terms used in the standards, logical identification of applications, safety and security methods, and cryptographic key management, if reasonable. NFI-72-Com 3 Domain knowledge NFI-73-Com This chapter presents domain knowledge relevant to the non-functional interface specification. The purpose of this chapter is to provide additional information which is not easily captured as a list of prescriptive requirements. NFI-292-Com This chapter presents quantitative descriptions of interfaces. The corresponding figures will always depend on the application. However, to provide an order of magnitude, this chapter presents examples and estimates based on current applications. Unless otherwise noted, the figures present the consensus from workshops. NFI-74-Com The domain knowledge has been derived by considering the requirements of three different applications (interlocking-rbc, interlocking-interlocking, interlocking-tcs) and of a range of physical communications layers which may be used. The information was then organised under the same headings as the requirements in Chapter 2. NFI-75-Com 3.1 Domain knowledge: applications NFI-76-Com Initiation of connection Copyright (c) 2003 UIC / Euro-Interlocking Page 10 of 28

13 NFI-77-DK This section states which party initiates a connection and under what circumstances. (These descriptions apply only to establishing a logical link, not to commands at application level.) NFI-110-DK For the three interface types, initialisation occurs as follows: NFI-78-DK - Interlocking-RBC interface: RBC connects to interlocking (interlocking waits for RBC to connect) NFI-79-DK - Interlocking-interlocking interface: Defined client interlocking connects to defined server interlocking NFI-80-DK - Interlocking-TCS interface: TCS connects to interlocking (interlocking waits for TCS to connect). NFI-81-Com Number of channels NFI-82-DK This section describes the number of channels required to/from each system. (One logical point-to-point connection needs one channel.) NFI-111-DK For the three interfaces types, the number of channels is as follows: NFI-83-DK - Interlocking-RBC interface: Many to many: One RBC can communicate with one or many interlockings (e.g. rail line with small interlockings at each station, and where one RBC is enough for the number of trains). One interlocking can communicate with zero or many RBCs (e.g. area with one large interlocking and lots of trains). NFI-84-DK - Interlocking-Interlocking interface: One interlocking can communicate with zero or more other Copyright (c) 2003 UIC / Euro-Interlocking Page 11 of 28

14 interlockings. (Could be zero if the interface is at track level, e.g. with automatic blocks or a relay interface between interlockings.) Number of links depends on geography of network and the size of the interlockings. NFI-85-DK - Interlocking-TCS interface: At any given time: One TCS can control many interlockings. One pre-defined area within an interlocking underlies just one TCS. Examples: Which TCS is in control can vary by night/day. Also, local TCS can take over in case of communications failure. NFI-86-Com Number of addresses NFI-87-DK This section presents data on the number of addresses required within an open network for a whole railway infrastructure organisation. NFI-91-DK The maximum number of elements to be linked via open systems equals the sum of the number of interlockings, RBCs, and TCSs times the number of infrastructure companies. This yields a world total number of addresses. NFI-112-DK Data for the three interface types is as follows: NFI-88-DK - Interlocking-RBC interface: Number of RBCs: < 1000 (for example: 1 RBC every 40 route-km on DB) NFI-89-DK - Interlocking-interlocking interface: Number of interlockings: < 10,000 Copyright (c) 2003 UIC / Euro-Interlocking Page 12 of 28

15 NFI-90-DK - Interlocking-TCS interface: Number of TCSs: < 1000 NFI-92-Com Addressing scheme NFI-93-DK In this context, a 24-bit, ETCS-type addressing scheme is adequate: - 10-bit area code (1024 railways, countries or areas, as allocated by UIC Fiche), - 14-bit equipment ID (16384 items of equipment of each type per area). Current equipment types include: radio infill unit, field element (e.g. level crossing), interlocking-related, RBC, balise, engine, and key management entity. The UIC wants to extend the addressing scheme from 3 to 4 bytes. NFI-94-Com 3.2 Domain knowledge: messages NFI-293-Com The volume of data over an interface will depend on the application. However, to provide an order of magnitude, this section presents examples and estimates based on current applications. NFI-105-DK Limit for TCP and IP is typically about 1500 octets per message. NFI-104-DK EuroRadio has a limit of 1023 octets per message. NFI-102-Com Functional message volume NFI-95-DK This section presents the functional message volume excluding protocol on each logical channel (worst case, excluding diagnostics) The figures reflect needs for coming 5-10 years. Required functional message volume could increase in the future. Copyright (c) 2003 UIC / Euro-Interlocking Page 13 of 28

16 NFI-113-DK Message volume for the three interlocking types (broken down by direction of data flow) is as follows: NFI-96-DK - message volume from interlocking to RBC: 64 kbps AZD: 128 kbps SNCF: 10 kbps NFI-97-DK - message volume from RBC to interlocking: 1kbps For system restarts after a failure, there is a cost tradeoff between bandwidth and reliability: low bandwidth requires costlier high reliability, and costlier high bandwidth permits lower reliability. NFI-98-DK - message volume over interlocking-interlocking interface (both directions): 14kbps SNCF: 2kpbs With cyclic communication: AZD:128 kbps Message volume depends on selectivity of information transferred. (To what extent do you treat the two interlockings as one big one?) Numbers reflect current interlocking functions. Euro-Interlocking may differ. NFI-99-DK - Message volume from interlocking to TCS: 64kbps SNCF: 16kbps (in fact, 32,000 bits every 2 seconds) AZD: 192 kbps NFI-100-DK - Message volume from TCS to interlocking: 400bps SNCF: 200bps NFI-101-Com Event-based communication: message volumes NFI-103-DK This section presents the length and frequency of messages (worst case) for event-based communication. Copyright (c) 2003 UIC / Euro-Interlocking Page 14 of 28

17 NFI-106-DK Length and frequency of event-based communication for the three interfaces types is as follows: NFI-107-DK - Interlocking-RBC interface: About 200 octets per event (or heartbeat message). But a number of events can be transmitted together. (Example from DB: up to 10 events per message) NFI-294-DK - Example of interlocking-rbc interface: CIRnet on DB CIRnet is a 10-year-old interface from interlocking to LZB or to ETCS pilot. Telegrams are event-driven, and occur at least every 500 seconds (if there is not event after 500 seconds, a 440-byte heartbeat or "live" message is sent). One telegram can contain information on up to 10 elements, with 40 bytes of information per element. Plus the telegram always contains about 360 bytes of protocol overhead and safety-code overhead. At start up, first there is a ping-pong exchange of safety messages to initialise the protocol. This means about 4-6 message requiring about 1 second each. Then information about the whole interlocking must be transmitted. A telegram concerning 10 elements is 760 bytes. 10 telegrams concerning a total of 100 elements (a medium-sized station) is about 7600 bytes. But this reflects the experience with LZB, where not all routes are equipped because of the high cost of adapting interlockings and installing loops. The ETCS philosopy is equip all routes. NFI-108-DK - Interlocking-interlocking interface: Open for comment. (Communication between interlockings often cyclic, not event-based) NFI-109-DK - Interlocking-TCS interface: TCS is normally the bottleneck, not the interlocking. British Rail specification for this interface: SSI (Alstom and Invensys): 5 octets per event and up 12 events per message. Copyright (c) 2003 UIC / Euro-Interlocking Page 15 of 28

18 NFI-114-Com Cyclic communication: message volumes NFI-115-DK This section presents the length and frequency of messages (worst case) for cyclic communication. NFI-116-DK Limit for TCP and IP is typically about 1500 octets. NFI-117-DK Data for the three interfaces types is as follows: NFI-118-DK - Interlocking-RBC interface: Volumes for route-based coding are much lower than volumes for element-based coding. AZD: up to 2kB every 200ms. NFI-296-Com Example of interlocking-rbc interface: SBB ETCS pilot line (1a) between Luzern and Olten Each telegram contains a 54-byte protocol stack and 22 bytes of safety code. It also contains 7bytes of data for each route set. In this project, there are a maximum of 50 routes per interlocking. A cyclic transmission occurs every 250 milliseconds. Given that all 50 routes appear in telegram, 426 bytes must transfer every 250 milliseconds. NFI-297-Com Example of interlocking-rbc interface: SBB new Mattstetten-Rothrist line Each telegram contains a 54-byte protocol stack, 34 bytes safety code, and 5 bytes of "border exits". It also contains 0.5 bytes for each route set. In this project, there are a maximum of 178 routes per interlocking. A cyclic transmission occurs every 500 milliseconds. Given that all 178 routes appear in the telegram, 182 bytes must transfer every 500 milliseconds. NFI-119-DK - Interlocking-interlocking interface: AZD: up to 2kB every 200ms, including what sometimes today are TCS functions, such as train numbers and text messaging between stations. Consensus: Usually much lower today. Copyright (c) 2003 UIC / Euro-Interlocking Page 16 of 28

19 NFI-120-DK - Interlocking-TSC interface: AZD: up to 3kB every 200ms; one message could be up to 1kB SNCF: every 2 seconds NFI-121-Com 3.3 Domain knowledge: performance NFI-122-DK This section presents domain knowledge concerning performance of interfaces. NFI-124-DK Required performance varies for different categories of message. A major distinction is normal and emergency messages. NFI-125-DK Preferred option: one fast channel, even for messages not requiring highest speed. NFI-126-Com Network delay NFI-127-DK This section presents data on network delay, i.e. typical transmission time when the system is in a normal, fault-free operating state. Maximum transmission time must be less than the time before reaction to absence of messages in section NFI-128-DK These times are for transmission only, and don t include other contributing times, like internal processing and object controllers (for signals). NFI-129-DK Data for the three interfaces types is as follows (see also NFI-306-Req): NFI-130-DK - Interlocking-RBC interface: Consensus from workshops: < 0.5 seconds. Depends on functionality split between interlocking and RBC. Must be short so cab aspect closely follows lineside aspect. NFI-131-DK - Interlocking-interlocking interface: Consensus of workshops: < 0.5 seconds Depends on distance, interlocking functionality, and number of objects. Copyright (c) 2003 UIC / Euro-Interlocking Page 17 of 28

20 NFI-132-DK - Interlocking-TCS interface: Consensus of workshops: Typically 0.5 seconds. Depends on distance, interlocking functionality and number of objects. Commands tend to go faster than statuses. NFI-133-Com Time before reaction to absence of messages NFI-135-DK This section presents data on the maximum time before a receiving application must react to an absence of messages. Data for the three interfaces types is as follows: NFI-136-DK - Interlocking-RBC interface: < 2 second desirable for new systems (< 10 seconds may be adequate because this is comparable with the ETCS air gap and this is still better than with lineside signals without continuous ATP.) Example of reaction to absence of messages: Revoke movement authority. NFI-137-DK - Interlocking-interlocking interface: < 2 seconds desirable for new systems < 5 seconds allowed with existing systems on some railways (Under existing operational rules, must be able to put signal to red immediately.) Example of reaction to absence of messages: Set variables to restrictive state. NFI-138-DK - Interlocking-TCS interface: For new systems: < 10 seconds desirable for normal commands AZD: < 2 seconds for emergency commands Example of reaction to absence of messages: TCS informs user of loss of connection. NFI-145-Com owable time delay due to link failure NFI-146-DK This section presents data on the maximum allowable time delay caused by the failure of a communication link, including failure detection and switchover between redundant paths. NFI-287-DK The time delay due to a link failure must be less than the maximum time before the receiving application must react to absence of messages (see NFI-133-DK) Copyright (c) 2003 UIC / Euro-Interlocking Page 18 of 28

21 NFI-147-DK The maximum allowable time delay for the three interface types is as follows: NFI-148-DK - Interlocking-RBC interface: < 2 seconds NFI-149-DK - Interlocking-interlocking interface: < 2 seconds NFI-150-DK - Interlocking-TCS interface: < 10 seconds AZD: < 2 seconds for emergency commands NFI-151-Com Requirements due to constraints from existing systems NFI-152-DK This section presents requirements arising from constraints inherited from existing systems. NFI-153-DK Interlocking-interlocking interface: Shorter delays in interface than those in NFI-131 compensate for use of vital transmission protocol (instead of direct or relay link) NFI-161-Com 3.4 Domain knowledge: availability and reliability NFI-299-Com Availability and reliablity: general considerations NFI-162-DK This section presents domain knowledge concerning availability and reliability for the three interfaces types. NFI-289-Com Failure of a logical communication channel between the interlocking and RBC, TCS or adjacent interlocking is always "significant" as defined in the Euro-Interlocking Reliability Requirements. [2b] NFI-164-DK Availability depends on both mean time between failures and time needed to restore the logical link (which may need to have redundancy to meet this requirement). NFI-165-DK Required availability depends on customer needs at each installation (could depend for example on traffic level). Copyright (c) 2003 UIC / Euro-Interlocking Page 19 of 28

22 NFI-167-DK For system restarts after a failure, there is a cost trade-off between bandwidth and reliability: low bandwidth requires costlier high reliability, and costlier high bandwidth permits lower reliability. NFI-169-DK In the interlocking-tcs interface, lower availability is acceptable if local control is possible when communication fails; otherwise reliability must be same as for RBC and interlocking-interlocking links. NFI-156-Com Initialisation time and frequency NFI-157-DK This section presents the duration and frequency of initialisation (of the complete application-to-application link), for each of the three interface types. NFI-155-DK Initialisation time should not exceed 10 seconds for any of the three interfaces. NFI-298-Com In each of the three interface types, initialisation cannot occur more than once a year. NFI-170-Com 3.5 Domain knowledge: safety and security NFI-171-DK This section presents domain knowledge on safety and security. NFI-173-DK Here are the observed safety integrity levels (SIL) for current applications that use of each of the three interface types: NFI-174-DK - Interlocking-RBC interface: SIL4 except for some messages from RBC to interlocking NFI-175-DK - Interlocking-interlocking interface: SIL4 Copyright (c) 2003 UIC / Euro-Interlocking Page 20 of 28

23 NFI-176-DK - Interlocking-TCS interface: SIL level depends on type of message. Below SIL4 for some functions. WRS: whole thing is SIL2. SNCF and RHK: SIL2 only NFI-177-DK For the interlocking-tcs interface, here are some examples of various SIL requirements: NFI-178-DK - High SIL requirement (SIL4): safety override commands, and the status information serving as basis for decisions to use safety override commands. Railtrack SNCB/NMBS BS MAV FS SpA JBV NS REFER CD CFR BV BLS SBB/CFF RFF NFI-179-DK - Low SIL requirement (SIL2): normal route setting. NFI-180-DK - SIL requirement that depends on operational rules: instructions to trains on basis of status indications on TCS NFI-181-DK - Some functions might not be SIL4, but are carried out according to special procedures that raise the overall safety level to SIL4. NFI-182-Com 3.6 Implementation constraints NFI-183-DK This section presents domain knowledge about the characteristics of the physical layer. These characteristics constitute implementation contraints. NFI-184-Com Physical-layer types Copyright (c) 2003 UIC / Euro-Interlocking Page 21 of 28

24 NFI-185-DK From the viewpoint of their characteristics, the following are the main physical-layer types: NFI-186-DK - Point-to-point, closed. NFI-187-DK - Multiple users, closed. NFI-188-DK - Multiple users, open. NFI-192-Com Capacity of physical-layer types NFI-193-DK The three physical-layer types typically have the following capacity levels: NFI-194-DK - Point-to-point, closed: High capacity. The railway or supplier control the solution. NFI-195-DK - Multiple users, closed: High capacity. The railway or supplier control the solution. NFI-196-DK - Multiple users, open: Here, both high and low-capacity must be considered because of potential savings on low-capacity service provided by an external partner. NFI-189-Com Relevant CENELEC classes NFI-190-DK The relevant CENELEC classes for each of the three physical-layer types are follows: NFI-191-DK - Point-to-point, closed: Class 1-2 NFI-197-DK - Multiple users, closed: Classes 3 and 4 Copyright (c) 2003 UIC / Euro-Interlocking Page 22 of 28

25 NFI-198-DK - Multiple users, open: Classes 5-7 There is a grey area between classes 4 and 5, which forsee some use of open networks by some equipment in otherwise closed network. NFI-199-Com Scope for unauthorised access NFI-210-DK The scope for unauthorised access within each of the three physical layer types is as follows: NFI-201-DK - Point-to-point, closed: low NFI-202-DK - Multiple users, closed: low NFI-203-DK - Multiple users, open: high if packet-based medium if circuit-based NFI-204-Com Minimum capacity NFI-205-DK The following is the minimum capacity to be expected from each of the physical-layer types (the capacity will usually be higher): NFI-206-DK - Point-to-point, closed: > 1 megabit / second NFI-207-DK - Multiple users, closed: > 1 megabit / second NFI-208-DK - Multiple users, open, high-capacity: > 1 megabit / second NFI-209-DK - Multiple users, open, low-capacity: for example, about 64 kilobit / second NFI-211-Com Marginal cost of extra capacity Copyright (c) 2003 UIC / Euro-Interlocking Page 23 of 28

26 NFI-212-DK The marginal cost of extra capacity (the addition cost for each additional unit of capacity) for each of the three physical-layer types is as follows: NFI-213-DK - Point-to-point, closed: low NFI-214-DK - Multiple users, closed: low NFI-215-DK - Multiple users, open: high NFI-216-Com Availability NFI-217-DK For all physical-layer types, availability depends on implementation and provisions for redundancy. NFI-218-Com Error rate that must be tolerated NFI-219-DK The error rate that must be tolerated: - is lower in closed physical layers than in open ones, and - rises with the capacity of an open physical layer. NFI-220-Com Message delivery time NFI-221-DK The message delivery time: NFI-223-DK - is shorter in closed physical layers than in open ones. NFI-224-DK - improves with the capacity of an open physical layer. NFI-225-DK - varies more in a packet connection than in a circuit connection. NFI-226-Com Redundancy measures to enhance availability NFI-227-DK This section describes measures available to provide redundancy in order to enhance availability. For each of the physical-layer types, redundancy measures are as follows: NFI-229-DK - Point-to-point, closed: Copyright (c) 2003 UIC / Euro-Interlocking Page 24 of 28

27 NFI-228-DK - Multiple users, closed: Redundancy provided by private network. Concern: Redundant connection from interlocking and related systems to private network. NFI-230-DK - Multiple users, open: In trunk system, redundancy provided by service provider Concern: Redundant connection from interlocking and related systems to trunk system. NFI-231-Com Availability of COTS components NFI-232-DK COTS components and service are available on the market for all three of the physical-layer types. NFI-233-Com Long-term support and upgrade NFI-234-DK This section presents, for each of the physical-layer types, the prospects for long-term support and upgrade: NFI-235-DK - Point-to-point, closed: Dependant on hardware and internal service provider (could be spun off!) NFI-236-DK - Multiple users, closed: Dependant on hardware supplier (or spare parts inventory) NFI-237-DK - Multiple users, open: Dependant on service provider NFI-238-Com Use in command control signalling applications NFI-239-DK This section presents the existing or prospective use of each of the three physical-layer types in command control signalling applications: NFI-240-DK - Point-to-point, closed: a lot Copyright (c) 2003 UIC / Euro-Interlocking Page 25 of 28

28 NFI-241-DK - Multiple users, closed: some NFI-242-DK - Multiple users, open: some (most circuit-switched, some packet-switched) NFI-243-Com Cost as function of distance NFI-244-DK This sections states how cost rises as function of distance for each of the three physical-layer types: NFI-245-DK - Point-to-point, closed: rises fastest NFI-246-DK - Multiple users, closed: rises fast NFI-247-DK - Multiple users, open: fixed, or rises slowly NFI-248-Com 4 Terms and abbreviations NFI-249-Com This document uses the followings terms and abbreviations: NFI-250-Com AZD: AZD Praha Ltd. NFI-251-Com bps: bits per second NFI-252-Com COTS: commercial, off-the-shelf NFI-255-Com ETCS-ID: A 24-bit addressing scheme: - 10-bit area code (1024 railways, countries or areas, as allocated by UIC Fiche), - 14-bit equipment ID (16384 items of equipment of each type per area). NFI-256-Com I/L: interlocking system as defined in Euro-Interlocking Standards Copyright (c) 2003 UIC / Euro-Interlocking Page 26 of 28

29 NFI-257-Com interlocking: interlocking system as defined in Euro-Interlocking Standards NFI-258-Com IP: Internet protocol NFI-259-Com kb: kilobyte NFI-260-Com kbps: kilobits per second NFI-261-Com logical communication channel: connection for data exchange between applications, independent of the physical data link NFI-262-Com peer-to-peer link: a link where either application can initiate communication, (i.e. no master/slave or client/server link). NFI-263-Com RBC: radio block centre (for ETCS) NFI-265-Com TCP: transmission control protocol NFI-266-Com TCS: traffic control system NFI-267-Com UDP: user datagram protocol NFI-268-Com WRS: Westinghouse Rail Systems NFI-269-Com 5 References NFI-270-Com 5.1 Documents referenced in text NFI-271-Com [1] Euro-Interlocking Performance Requirements (Version 6.12 slated for approval at 15 May 2003 Steering Group meeting) NFI-291-Com [2a] Euro-Interlocking Availability Requirements (Version 6.7 slated for approval at 15 May 2003 Steering Group meeting) NFI-272-Com [2b] Euro-Interlocking Reliability Requirements (Version 6.15 slated for approval at 15 May 2003 Steering Group meeting) Copyright (c) 2003 UIC / Euro-Interlocking Page 27 of 28

30 NFI-273-Com [3] Euro-Interlocking Standards. Latest versions available from your organisation s Industry Support Team or Railway Support Team member. NFI-274-Com [4] CENELEC EN NFI-275-Com [5] CENELEC EN NFI-276-Com [6] Application Scenarios for Open and Closed Networks Bombardier Transportation 3NSS004865D0006 Draft 2.2 of 28 April 2003 NFI-277-Com 5.2 Examples of interface specifications NFI-278-Com [7] FIS Between Trackside Sub-systems - Safe Application Service Alstom SI/TRK/UP/2 Version 2.0-draft A 19 September 2001 NFI-279-Com [8] Functional Interface Specification for Transport Layer Emulation Using Euroradio safety Protocol over TCP/IP networks Alstom/Railtrack TCS Joint Project Team SIR/Safe/Safe/5/TCP/1 Draft C for Issue 1, 15 June NFI-280-Com [9] In AEIF web site ( ERTMS/ETCS Class 1 Specifications: - Subset-056: STM FFFIS Safe Time Layer m Jun Subset-057: STM FFFIS Safe Link Layer m Nov2002 Copyright (c) 2003 UIC / Euro-Interlocking Page 28 of 28