October 22, 1997

To: Members of IEEE Working Group #2: Communications Based Train Control

LIRR will be providing lunch in the conference room, as well as coffee etc., in the morning and for the afternoon break.

 

IEEE Rail Transit Vehicle Interface Standards Committee

MEETING OF WORKING GROUP #2

COMMUNICATION BASED TRAIN CONTROL

PERFORMANCE REQUIREMENTS

November 7, 1997 - 9:00 am

Meeting Agenda

9:00 - 9:05 INTRODUCTIONS

9:05 - 9:20 SUMMARY OF ACTIVITIES SINCE LAST MEETING

- WG2 Task Force Meeting

- CBTC Peer Group Meetings

- Meeting of IEEE Rail Transit Vehicle Interface Standards Committee

9:20 - 9:45 REVISED MANDATE FOR WORKING GROUP #2

- Project Authorization Request (PAR)

- Scope of Proposed Standard

- Purpose of Proposed Standard

- Working Group Membership

- "Guiding Principles" for Working Group

9:45 - 10:00 REMARKS BY TOM PRENDERGAST (PRESIDENT, LIRR)

10:00 - 10:30 BREAK

10:30 - 12:00 REVIEW OF TYPICAL ISSUES TO BE ADDRESSED BY PROPOSED CBTC STANDARD (see attached)

12:00 - 1:00 LUNCH

1:00 - 1:30 ROLE OF CBTC IN LIRR SIGNAL STRATEGY (VIC GRAPPONE)

1:30 - 3:00 REVIEW OF "STRAWMAN" CBTC STANDARD (to be tabled at the meeting)

3:00 - 3:30 BREAK

3:30 - 4:45 NEXT STEPS

- Date and location for next meeting

- Objectives for next meeting

- Assignment of actions

TYPICAL ISSUES TO BE ADDRESSED BY PROPOSED CBTC STANDARD

  1. How much variability in train types and train configurations should be supported by a "standard" CBTC system?
  2. Can a "standard" set of train operating modes, and mode transitions, be defined for CBTC systems. Is there a need to differentiate between light rail, heavy rail and commuter rail?
  3. Can a maximum operating speed be defined?
  4. Can it be assumed that a "standard" CBTC system will be controlled from a central control location, with local control provisions for failure management only, or should alternative line control philosophies be assumed? Should all ATS-level functions be considered optional?
  5. Different transit properties typically have different definitions for both "design headway" and "operating headway". Can standard headway definitions be developed for CBTC system applications?
  6. Should a quantitative safety criteria be defined for CBTC systems, if so, what should this criteria be (e.g. hazard probability of 10-9 per system operating hour)? What "hazards" should be included in this calculation? How should the impact of a "failure" of safety software be addressed?
  7. Can a "standard" method be defined for specifying system availability/reliability requirements for CBTC systems? Can a "standard" method be defined for measuring compliance with these requirements?
  8. Can a "standard" method be defined for specifying system maintainability requirements or defining an overall maintenance philosophy for CBTC systems? Should "standard" requirements be established for CBTC system diagnostic provisions?
  9. Can "standard" environmental criteria be defined for CBTC equipment (ref. WG#8)?
  10. Can it be assumed that a "standard" CBTC system must provide bi-directional train protection?
  11. Should a "standard" be established for CBTC train position resolution, to support operational requirements (or perhaps a range)? What about minimum train separation (i.e. distance to which a following train can safely close-up to a stationary train ahead)?
  12. Should a "standard" be established for commanded speed limit resolution, to meet operational requirements (e.g. 1 mph, less, more)?
  13. Can a "standard" functional approach be established for implementing temporary speed limits (e.g. speed limit resolution; definition of speed limit location)? Is it acceptable for temporary speed limits to be input/removed via a (non-vital) ATS system, or should other "standard" mechanisms be specified? Similarly, is it acceptable for track/switch blocking to be applied/removed via a (non-vital) ATS system?
  14. Can a "standard" functional approach be developed for definition of work zones (protection of track forces)?
  15. Can a "standard" functional approach be developed for moving trains into/out of CBTC territory?
  16. Should a CBTC "standard" also include interlockings, or should interlockings be considered independent of CBTC?
  17. Can "standard" functional requirements be defined for CBTC system check-out after maintenance and/or prior to entering revenue service?
  18. Can any functional "standards" be developed with respect to interfaces between the carborne CBTC equipment and other car subsystems, such as propulsion, brakes, doors, etc. (ref. WG#5)?
  19. If track circuits are retained for broken rail detection, functionally how should CBTC respond to/operate through an unexpected "occupied" track circuit?
  20. Can "standard" functional requirements be defined for cutting/combining trains?
  21. Can "standard" performance requirements be defined for CBTC automatic speed regulation algorithms (e.g. acceptable tolerances around "ideal" speed/distance profiles; acceptable variations around "ideal" trip times; etc.)?
  22. Can a "standard" stopping accuracy be defined for CBTC programmed station stop algorithms?
  23. Can a "standard" functional approach be developed for automatic train regulation (e.g. dwell time modifications; run time modifications; etc.)
  24. Can any "standard" functional requirements be developed for other CBTC-ATS functions (such as system status displays, automatic vehicle identification, train tracking, automatic routing control, definition of operating schedules, junction management, energy management, train hold functions, train stop functions, system performance monitoring, passenger information system interfaces, etc.)?
  25. Can any "standard" functional requirements be established in response to system failures (e.g. NYCT functional requirement to continue to provide civil speed enforcement in the event of loss of RF data communications with the wayside)?