IEEE Rail Transit Vehicle Interface Standards Committee

 

MEETING OF WORKING GROUP #2

COMMUNICATION BASED TRAIN CONTROL

 

Date:            November 1, 2002 - 9:00 am

 

Place: BART, 1000 Broadway, Oakland, CA

 

Attendees:

 

Name

Representing

Email

Corinne Braban

Siemens

Corinne.Braban@ts.siemens.fr

Fred Childs

PATH

fchilds@panynj.gov

George Clark

LUL (Infraco JNP)

George.Clark@infracojnplimited.co.uk

Michael Crispo

CTA

mcrispo@transitchicago.com

Jeff Eilenberg

US&S

jeeilenberg@switch.com

Nicolas Estivals

RATP (Paris)

Nicolas.Estivals@ratp.fr

Mircea Georgescu

Alcatel Canada

Mircea.Georgescu@tas.alcatel.ca

Harvey Glickenstein

PB

h.glickenstein@ieee.org

Vic Grappone

Grappone Tech.

vgrappone@msn.com

Jim Hoelscher

Alstom Signaling

James.Hoelscher@transport.alstom.com

Geoff Hubbs

NYCT

gehubbs2@nyct.com

Harold Gillen

US&S

h.c.gillen@switch.com

Ken Karg

Bombardier

kenneth.karg@us.transport.bombardier.com

John Lewis

MBTA

jlewis@mbta.com

Charlie Martin

Lea + Elliott

cmartin@leaelliott.com

Byron Morgan

SF MUNI

Byron.Morgon@ci.sf.ca.us

Ed Mortlock

Parsons

Edwin.Mortlock@parsons.com

Eugene Nishinaga

BART

enishin@bart.gov

Bill Petit

Safetran

bill.petit@ieee.org

Alan Rumsey

Parsons

alan.rumsey@parsons.com

Mickey Senase

STV Inc.

msenase@bsda.com

Tom Sullivan

TSD

Tom.Sullivan@tsd.org

Errol Taylor

WMATA

etaylor@wmata.com

John Vogler

NJ Transit

jvogler@njtransit.com

Robert Walsh

Bombardier

Robert.e.walsh@us.transport.bombardier.com

David Zahorsky

STV Inc.

zahorsdj@stvinc.com

 

 

Minutes of Meeting:

 

 

1.                  HOUSEKEEPING ITEMS

 

1.1.            Introductions

 

Alan Rumsey thanked BART for hosting this meeting of Working Group #2 (WG2) of the Rail Transit Vehicle Interface Standards Committee (RTVISC).

 

1.2.            Review of Previous WG2 Meeting Minutes

 

The minutes of the previous WG2 meeting held on August 21, 2002 were reviewed and accepted as written.

 

1.3.            Date/Location of Next WG2 Meeting

 

The next WG2 meeting will be held on Monday, February 10, 2003.  The location is still to be defined but will likely be on the east coast, possibly Washington, DC.

 

1.4.            Liaison Activities

 

1.4.1.      CBTC Peer Group Meeting

 

Alan Rumsey reported on the CBTC Peer Group meeting that had been held at BART on October 30/31.

 

The objective of the CBTC Peer Group meetings is to provide a forum for transit agencies to share past experiences, and discuss future plans, with respect to implementation of CBTC systems. The Peer Group meetings also provide a means for transit agencies to explore common operational needs, and operational differences, which may influence CBTC standardization initiatives. The group has committed to actively support the efforts of the WG2 in developing CBTC standards, and to promote the use of such standards in future CBTC procurements.

 

As input to WG2, the CBTC Peer Group identified three potential areas for future CBTC standardization efforts, namely:

 

a)            Trainborne CBTC subsystem to car equipment interfaces

b)            Wayside CBTC subsystem to solid state interlocking interfaces

c)            Safe braking model for profile-based CBTC systems

 

The CBTC Peer Group was of the opinion that standardization efforts in these areas would likely offer greater benefits in the short term, than attempting to develop consensus industry standards for the train-to-wayside interfaces.

 

It was agreed that future WG2 CBTC standardization efforts should be discussed further at the next WG2 meeting.

 

The CBTC Peer Group had also discussed the potential use of the bi-directional CBTC train-to-wayside data radio communication link to transmit other non-train control data (such as video), as was briefly discussed at the last WG2 meeting.  The general consensus of the CBTC Peer Group was that until more operational and application-specific design experience had been gained with the use of radio communications for real-time, safety-critical train control functions, it would not be prudent to attempt to utilize the same data link for other non-related high bandwidth applications.  It was acknowledged that while technology may be available to provide a radio datalink with sufficient bandwidth to support both train control and non-train control functions, and such technology may offer cost benefits in terms of an integrated radio infrastructure, various "institutional" issues still need to be addressed related to the maintenance and configuration control of a shared datalink over time.

 

It was however recognized that even if separate radio datalinks were provided for CBTC and non-CBTC data, there would still be a requirement for configuration control and frequency management to avoid mutual interference between the different systems.  (Charlie Martin advised that airport authorities, for example, are particularly concerned with the use of 2.4 GHz spread spectrum for CBTC, as this frequency is widely used for other applications.)

 

The CBTC Peer Group had also discussed issues impacting the more widespread deployment of CBTC technology.  From a user’s perspective, one of the most significant risk elements in deploying CBTC on an existing transit system was seen to be the integration of CBTC technology with existing signaling technology to support mixed mode operations either as a regularly scheduled mode of operation, or as an infrequent, unscheduled mode of operation (for example during cutover of the new CBTC system, or as a result of infrequent trainborne CBTC equipment failures.)  The generic problem is that the signaling principles associated with CBTC technology are different to the signaling principles associated with any track circuit-based "back-up" system, and transitions between these signaling principles are often complex. 

 

It was acknowledged that support for mixed-mode operations could probably not be standardized, given the range of applications and the differences in the existing signaling technologies and signaling principles.  General guidelines based on experience to date would however suggest that:

 

a)             When implementing CBTC don't design the system to support mixed mode operations (a mix of equipped and unequipped trains) unless mixed mode operations is absolutely required as a regularly scheduled mode because of the specific network operations

 

b)             When cutting over CBTC, where possible, equip all train first and then cut over the line section-by-section; the costs/risks of designing the system to support mixed-mode operations during the cut-over are likely to outweigh any perceived benefits that may be derived from early cut-over with a partially equipped fleet

 

c)             To deal with infrequent, unscheduled mixed mode operations during and after cut-over, provide a secondary means of train detection to detect/track unequipped/failed trains (and to provide movement authority limits for following equipped trains), but avoid, where possible, providing a secondary signaling system to provide/enforce authority limits for the unequipped/failed trains - instead, rely on operating procedures and/or reduced train operating speeds.

 

1.4.2.      IEC Technical Committee 9 (TC9) Working Group 40 (WG40)

 

Alan Rumsey reported on a meeting of IEC TC9 WG40 (Railway Applications – Urban Guided Transport Management and Command/Control Systems – UGTMS), held in New York on October 28/29, 2002.

 

The standard being developed by this international committee is intended to define functional, system and interface requirements for command, control, and management systems used on urban, guided passenger transport lines and networks. Trains operating on such lines may include heavy-duty underground (metro) trains, commuter trains, light rail trains, trams and regional trains.

 

The standard will be divided into four parts.

 

Part 1, “System Principles and Fundamental Concepts”, will provide an introduction to the standard and deal with the main concepts, the system definition, the system principles and the main functions of UGTMS.

 

Part 2, “Functional Specifications”, will deal with the standardisation of functions and will take into account all essential requirements and assignment of safety integrity level (SIL). Two types of functions are envisaged for a given level of automation: mandatory functions (e.g. train localisation) and optional functions (e.g. CCTV monitoring of platforms and tracks).

 

Part 3, “System Specifications”, will deal with the architecture of the system and the allocation of the requirements and functions identified in part 2 to architecture constituents (SRS),

 

Part 4, “Interface Specifications”, will deal with the definition of the interfaces, as well as the data exchanged by them, for the interoperable and interchangeable constituents identified in part 3.  For interfaces between UGTMS constituents, two levels will be considered: the logical interface or FIS (Functional Interface Specification) and the physical and logical interface or FFFIS (Form Fit Functional Interface Specification).

 

The group is currently working on Part 1.  No schedule has yet been established for Parts 2, 3 and 4.

 

This IEC standardization effort is related to a similar European research program also referred to as UGTMS.

 

1.4.3.      IEC Technical Committee 9 (TC9) Working Group 39 (WG39),

 

Post Meeting Note:

 

Sam Lott, who was unable to attend the WG2 meeting, has provided the following status report on IEC TC9 WG39 – Automated Urban Guideway Transit Standard.

 

The last meeting of WG39 was held on October 17th and 18th in Rennes, France.  The principle objective of the meeting was to prepare a rough draft document to be submitted to the IEC Board that represents the current status of the WG39 standard as of the end of 2002.  This document is called a Committee Draft (CD).

 

The work at prior meetings had substantially dealt with the development of a preliminary hazard analysis format and the development of safety critical risk conditions that are applicable to fully automated systems (i.e. DTO – driverless train operations and UTO – unmanned train operations).  The list of hazardous conditions is intended to only represent aspects of fully automated operations that are different from manned train operations.  In other words, hazardous conditions that are identical for both non-automated/semi-automated and fully automated systems are not a concern of this safety standard.  These are dealt with by other existing standards.

 

Based on this early preparation work, WG39 has realized that it is not possible to complete a universal hazard analysis and risk assessment that can be applied worldwide.  There are risks that are considered acceptable in some cultures of the world, which in other cultures are not considered acceptable.  Therefore, the standard will provide certain minimum safety requirements, but more importantly will provide a framework for hazard analysis and risk assessment that can be followed for each application of the standard wherever the project is located.

 

The standard will comprise the following chapters:

 

1.      Scope

2.      Normative References (i.e., other standards referenced herein)

3.      Terms and Definitions

4.      Methodology

5.      System Description

6.      Risk Assessment of Hazardous Situations

·         Identification of hazardous situations

·         Comparative risk assessment

·         Identification of Corrective Actions

7.      Safety Requirements

 

WG39 will be meeting next in Copenhagen on February 20-21, 2003, in Italy on May 22-23, and in Singapore (International APM Conference) on September 4-5.

 

1.4.4.      APTA Rail Conference

 

Tom Sullivan advised that he had been asked by APTA to moderate a session at the 2003 Rail Conference that would compare the pros and cons of inductive loop and RF train-to-wayside data communications.

 

1.5.            Ballot Status of Draft D9.1 of Proposed Standard 1474.2

 

Alan Rumsey encouraged members of the ballot group for the proposed standard 1474.2 (User Interface Requirements for CBTC Systems) to submit their ballots as soon as possible – if they had not already done so.  The closing date for ballots is Wednesday, November 6 and to date less than 50% of the ballot group had submitted their votes.

 

2.                  UPDATES TO IEEE STD. 1474.1-1999 “CBTC PERFORMANCE AND FUNCTIONAL REQUIREMENTS”

 

2.1.            Review of Changes from Draft D2.0 to Draft D3.0

 

2.1.1.      Section 4 (General Requirements)

 

Section 4, as updated at the previous WG2 meeting, was reviewed and additional revisions were identified, specifically with respect to subsection 4.6 (Entering/exiting CBTC territory), to address operations both with and without train crews.

 

2.1.2.      Section 6.1 (ATP Functional Requirements)

 

Section 6.1, as updated at the previous WG2 meeting, was reviewed and additional minor revisions identified.  Specifically, revisions were identified to section 6.1.2.1 (Safe braking model), section 6.1.7 (Zero speed detection), and section 6.1.8 (Door opening control protection interlocks).  It was agreed that requirements specific to APM applications should be covered either in Annex C or by reference to the ASCE standard.

 

It was also agreed to clarify in section 6.1.13 (work zone and work train protection) that a movement authority could be granted through a blocked switch, if the blocked switch were aligned in the required position.

 

Bill Petit agreed to provide correct references to the IEEE Std. 1570-2000 in section 6.1.15.  (ACTION)

 

2.1.3.      Section 6.2 (ATO Functional Requirements)

 

Section 6.2, as updated at the previous WG2 meeting, was reviewed and additional minor typographical revisions were identified to section 6.2.3 (Door control).

 

2.1.4.      Section 6.3 (ATS Functional Requirements)

 

Section 6.3, as updated at the previous WG2 meeting, was reviewed and additional revisions identified.  Specifically, revisions were identified to section 6.3.1 (General), 6.3.2 (ATS user interface), 6.3.4 (Train routing), and 6.3.7 (Restricting train operations).   With respect to section 6.3.7, it was agreed to link these requirements back to the hazard analysis now required under section 6.3.2.

 

2.2.            Line-by-Line Review of Section 5.3 (System Safety Requirements)

 

Section 5.3 was reviewed and it was agreed that no significant changes were required to this section, except to replace all references to MIL-STD-882C.  Specifically, instead of referencing Tasks 102, 202, 204, 205 and 206 of MIL-STD-882C, this section will now reference a new Annex E. 

 

Similarly, instead of referencing paragraphs 4.5 and 4.6 of MIL-STD-882C, it was agreed that a “Risk Assessment Matrix” should be added to this section.

 

Jim Hoelscher agreed to develop the new Annex E and the “Risk Assessment Matrix”, for incorporation into the next draft of 1474.1 (Revised). (ACTION)

 

It was also agreed to expand section 5.3 to include a new subsection that will define the basic safety principles that should be reflected in any CBTC system design to provide for:

 

a)            Safety during normal operations

b)            Safety  during abnormal operations

c)            Safety following system failures

d)            Safety during failure recovery.

 

A draft of this new subsection will be prepared for review at the next WG2 meeting.

 

2.3.            Line-by-Line Review of Section 5.1 (CBTC Factors Contributing to Achievable Headways)

 

Section 5.1 was reviewed and generally found to be acceptable as written.

 

It was agreed to incorporate minor revisions to reflect that CBTC factors that contribute to achievable headways also include CBTC equipment reaction times to establish movement authority limits through interlockings, and the efficiency of the ATO automatic speed regulation function.

                                               

3.                  ANY OTHER BUSINESS

 

3.1.            Next Meeting Agenda

 

The agenda for the next WG2 meeting on February 10, 2003 will be to review section 5.3 (System safety requirements) – revised to incorporate agreements at this meeting – and section 5.4 (System assurance requirements).  It was agreed that there should be no further reviews of sections 4 and section 6, pending a future line-by-line review of the complete, revised standard.

 

Alan Rumsey will reissue the draft standard (as draft D4.0), no later than January 31, 2003.

 

It remains the objective of WG2 to ballot the revised standard during 2003.

 

 

Minutes prepared by:

 

Dr. Alan F. Rumsey

WG2 Chair