Interoperable Communication-Based Signaling (CBS) Overview

1
Interoperable Communication-Based Signaling
(CBS)Overview

• January 21, 2009
• Bill Petit
• www.billpetit.com

2
First Things

• Safety Briefing
• Project Member introductions
• FRA / APTA introductions

3
Safety Briefing

• Exits
• CPR
• 911
• Restrooms
• Please set cell phones to stun or turn off

4
Project Team Introductions

• Bill Petit
• John Fayos, Critical Link
• Terry Tse, FRA
• Howard Moody, RRF
• Paul Bousquet, VNTSC

• Alstom
• Pete Hart
• Jack Perkins
• GETS
• Greg Hann
• Safetran
• Bo Chang
• Jim Hoelscher
• USS
• Chinnarao Mokkapati

5
Please give them your opinions on what you see
today
Some Other Introductions

• FRA Office of RD
• Sam Alibrahim
• Terry Tse
• APTA
• Lou Sanders

• FRA Office of Safety
• Tom McFarlin
• Mark Hartong
• Tyrone Clements
• Sean Crain
• Manuel Galdo

6
Agenda

• Overview and Questions (approx 1 hour)
• Demonstrations (4 groups at approx ½ hour each)
• For other groups Critical Link info, Internet
  access
• 400 Final Questions and Answers
• Wrap-up
• Social hour with informal Q/A till 630 (courtesy
  of Critical Link)

7
Demo Group Assignments

• People with earlier flights
• Distribute golden tickets

8
Topics

• Birds Eye View
• What we set out to do, What we did
• System Architecture
• Signal Based Architecture
• PTC Operation
• Compatibility with ACSES
• Interoperability
• Background
• AREMA Manual Parts and Status
• Demonstration Project

9
What we set out to do

• Define Interoperability for a PTC system based
  on signaling principles
• Complete system providing stand-alone ability to
  set and protect routes, deliver onboard
  authorities in terms of aspects instead of text
  authorities, enforce onboard authorities
  including predictive braking.
• Focus on train control
• Work with interoperable comms system per RESC
• Basic system defined with ability to add
  additional functionality as needed.

10
What we did

• Alstom, USS, GETS and Safetran agreed to and
  helped publish architecture and interoperability
  recommended practices through a Professional
  Industry Association (AREMA)
• AREMA consists of suppliers, railroads,
  consultants and regulators
• Available to anyone interested
• Through FRA and Private (supplier) funding
• Defined Test Layout to incorporate multiple
  suppliers
• Developed Communications Router and Simulators
  for Test Environment
• Replaced simulators with suppliers equipment
• Suggested Recommended Updates to AREMA Manual
  Parts based on testing results

11
What we did

• Focused on Interoperability and Architecture
• Doesn't include
• Standard ADU
• Standard Location Determination System
• Braking Algorithm
• Specific Communication system (designed to use
  variety of available systems)
• CAD (use of any type system)

12
System Architecture
13
How We got Here History of Train Control Part
1 (since you can't know where you are going
unless you know where you have been)
14
Track Warrant Control (Dark Territory)
Movement Authority conveyed by track warrant
Permission to occupy a Block of track Verbal
(forms-based) communication Enforcement by Human
15
Automatic Block Signal (ABS)
Two main tracks, each with an assigned direction
of movement Movement authority and operating
speed conveyed by signal system and verbal
authorities Tracks are signaled only for movement
in assigned direction Train separation and
operating speed information provided by signal
system with enforcement by human
16
Train Control System (TCS) (or cTc)
Multiple main tracks, each signaled for traffic
in both directions Movement authority and
operating speed conveyed by signal system with
enforcement by human Train dispatcher requests
switches and signals from distant location
17
TCS with Cab Signals and Speed Control
Multiple Main Tracks, each signaled for traffic
in both directions Movement authority and
operating speed conveyed by signal system with
information sent through the rails Train
dispatcher controls switches and signals from
distant location Speed limit enforced by onboard
equipment as well as reactive enforcement of
authority overruns
18
(No Transcript)
19
What is CBS?

• Defined Communications Based Signaling as a
  radio based cab signal system which meets
  requirements of a PTC system.

20
What is CBS?

• Why This Architecture?
• Allows use of safety principles developed over
  multiple decades of signaling experience
• Allows designs to be based on existing vital
  systems currently proven in revenue service (e.g.
  processor-based interlocking controllers,
  processor-based onboard systems)
• Systems based on this architecture have been
  accepted for revenue service with enhanced
  operational capabilities (e.g. ACSES, ITCS)
• Avoids complexity of vital track warrant systems
  with complex rules and display of onboard text
  authorities

21
What is CBS?

• Operates the same as a conventional Cab Signal
  System with civil speed, and positive stop
  enforcement. Onboard aspect display instead of
  wayside signals
• Virtual Block Occupancies used instead of
  physical track circuits.
• Can also be used in conjunction with physical
  track circuits depending on application
• Train location determination done by on-board
  equipment (Definition of how to indicate a block
  is occupied, not how position is determined).
• Communication, including cab signal aspect
  transmission from wayside to trains, via a
  digital data communications network.
• Ability to define shorter virtual blocks as
  needed, along with higher number of cab signal
  aspects available provides substantial
  performance gains

22
Defined CBS Architecture

Form Translator
Computer Aided Dispatch Station (CAD)
Signal Logic Processor (SLP)
Data communications network
Wayside Interface Unit and Physical Appliances
(WA)
Onboard Logic Processor (OBLP)
To Train equipment
23
What are components of CBS?

• CAD operation (i.e dispatching) is the same as in
  conventional CTC system.
• CTC dispatching provides greatest efficiency
• Form generation can also be used with non-vital
  conversion to signal and switch requests (CBS
  system enforces vitality of operation)
• Interface to CBS system same as conventional code
  line interface
• Additional information in system (e.g. train
  speed) can be used for enhanced dispatching and
  other business benefits
• Train management easily overlaid on this system
  without compromising safety

24
What are components of CBS?

• Signal Logic Processor (SLP) does all the vital
  logic and sends controls to wayside appliances
  (WA) and signal aspect info to the On Board Logic
  Processor (OBLP).
• Based on existing proven vital interlocking
  controller systems currently in revenue service.
• Application logic development tools (creators,
  verifiers, testers) already exist
• SLP also processes Bulletins (such as temporary
  speed restirctions) received from CAD via Form
  Translator, and communicates them to various
  OBLPs.
• Temporary speed restrictions can also be done by
  application logic by limiting aspects available
  per block

25
What are components of CBS?

• OBLP provides signal aspect and speed limit info
  to train operators, and performs vital overspeed
  protection, profile stops, civil and temporary
  speed enforcement.
• Onboard topograhical database allows civil speed
  enforcement, predictive (positive stop)
• Allows up to 255 aspects
• Aspects combined with virtual blocks that can be
  defined as any size provide full range of
  performance capabilities
• Based on existing proven on-board vital equipment

26
What are components of CBS?

• Messages use ATCS addressing and vital protocols
  currently accepted and in wide use today
• Supports data transmission over a wide variety of
  media (not linked to specific communication
  media)
• Safety of system in message architecture does
  not require vital communication system
• Communication system can be designed to support
  needed functionality.

27
Control Office (CAD)
Existing cTc Territory
Controls and Indications (non-vital)
Wayside Bungalow
Cab Signal sent through rails
28
Control Office (CAD)
CBS
Controls and Indications (non-vital)
Proceed Aspect (vital)
Occupying Block RRR.LLL.123456 (vital)
Set Switch Normal
Profile Calculation to next change point (vital)
Switch Locked Normal
29
Compatibility with ACSES

• Similar Architectures
• Current ACSES uses rail-based cab instead of
  radio based cab
• Current ACSES uses databases uploaded from
  transponders rather than onboard database
• Future Amtrak plans for onboard database
• Formats are generally similar
• Use of ATCS addressing and datagrams for
  temporary speed restrictions and positive stop
  override

30

• INTEROPERABILITY THROUGH AREMA MANUAL PARTS

31
Background

• Roundtable discussions at 2005 AREMA CS
  Conference generated request for interoperability
  guidelines for radio-based cab signal systems
• Manual Parts approved for 2009 AREMA Manual of
  CS Recommended Practices

32
Approved Manual Parts

• 23.2 CBS System Requirements
• 23.3 CBS System Design Guidelines
• 23.4 CBS System Interoperability Requirements
• 23.5 CBS Infrastructure Database

33
Section 23.2

• 23.2.1 Recommended Functional Requirements of a
  CBS System.
• Define the recommended system functional
  requirements.
• 23.2.2 Recommended RAMS, Environmental and Other
  Requirements for Signaling Systems Using CBS
  Architecture.
• Define the recommended reliability, availability,
  maintainability, and safety (RAMS),
  environmental, electromagnetic compatibility, and
  quality assurance requirements.

34
Section 23.3

• 23.3.1 Recommended Design Guidelines for a CBS
  System
• Define the recommended system architecture and
  interfaces based on conventional signaling
  principles.

35
Section 23.4

• 23.4.1 Recommended Communications Protocols for a
  CBS system
• Define the recommended system communication
  protocol (based on ATCS addressing and datagram)
• Capable of being transported over a variety of
  communications channels (e.g. IP, ITP)
• 23.4.2 Recommended Communications Messages for a
  CBS System
• Define the recommended standard messages for
  communications between CBS subsystems

36
Section 23.5

• 23.5.1 Recommended Onboard Database Guidelines
  for a CBS system
• Define the recommended structure and content of
  the onboard database

37
Interoperability Demo
38
Project Administration

• Funded (partially) by FRA Office of RR
  Development
• Administered through Railroad Research Foundation
  through a Cooperative Agreement with FRA

39
Project Administration

• Railroad Research Foundation subcontracts for
• Project Management Bill Petit
  (www.billpetit.com)
• Test Environment Critical Link
  (www.criticallink.com)
• Participating suppliers
• Alstom
• GETS Global Signaling
• Safetran Systems
• Union Switch Signal

40
Critical Link Background

• Critical Link designs and builds customized
  embedded processing systems
• Hardware, software, firmware
• From concept inception through production
  management
• Work in a number of different industries
• Underlying technologies remain the same
• 25 engineers, located in Syracuse, NY

41
Critical Link Transportation And Standards Work

• Communication Based Train Control
• Data communication system design and
  implementation
• Simulator Design
• FIS system (interface between UP office and
  Safetran field equipment)
• IEEE 1570 Highway-Rail Interface
• APTA TCIP (Transit Communications Interface
  Profiles) standard development

42
Project Goals

• Demonstrate overall architecture and
  interoperablity through adherence to AREMA Manual
  Parts (and suggest modifications as needed)
• Cooperate with other groups (e.g. AAR Railway
  Electronics Standards Committee)
• Part of pathway towards fully interoperable
  systems

43
Test Environment

• Provide communications between components
• Uses IP network
• Capable of simulating delays and error rates
• Logs communication messages
• Simulators verified subsystem functionality and
  interfaces
• Supplier equipment replaces simulators as they
  were developed

44
Test Environment Simulators

• Communications Router
• WA Simulator
• Vehicle Display Simulator
• OBLP Simulator
• SLP Simulator
• USS Office

44
45
Basic Territory for each supplier to simulate
46
Overall Territory with Each Supplier covering One
Section
GETS
Safetran
USS
Alstom
47
(No Transcript)
48
Representation of Overall Test Layout
49
Project Status

• Test Environment defined and developed
• Test Drivers / Simulators developed for all
  subsystems
• CAD Office System integrated into test
  environment
• All suppliers systems integrated into test
  environment (replacing simulators)

50

• Simulator Screen Shots

51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55

• Suppliers Equipment Integrated in Demo

56
(No Transcript)
57
(No Transcript)
58
(No Transcript)
59
GETS SLP Equipment Rack

• SLP (GETS VHLC)
• Interfaces to Genisys Control Office
• Processes Signaling Logic
• Interfaces to SLP Protocol Converter
• Interfaces to WA for Switch Control

Diagnostic Terminal

• SLP Protocol Converter
• Converts Between GE and ICBS Messaging
• Uses ICBS Database for Status Mapping
• Transmits Block Statuses to GE SLP
• Receives Switch Signal Statuses from GE SLP
• Interfaces to Comm. Router (ICBS Network)

• WA (GETS VHLC)
• Interfaces to SLP

60
GETS OBLP Equipment Rack

• OBLP (GETS ITCS Onboard Computer)
• Location Determination Using ITCS Equivalent
  Database
• Enforces Targets
• Interfaces to OBLP Protocol Converter
• Interfaces to Vehicle Simulator Loco Interface
  Panel

GETS ITCS Locomotive Display
Vehicle Simulator Diagnostic Terminal

• Locomotive Interface Panel
• Acknowledgement Input
• Reverser Handle Input
• In/Out Mode Switch

• OBLP Protocol Converter
• Converts Between GE and ICBS Messaging
• Uses ICBS Database for Status Mapping
• Receives Block Statuses from OBLP
• Transmits Switch Signal Statuses to OBLP
• Interfaces to Comm. Router (ICBS Network)

61
Alstom ICBS SLP and WA Equipment Rack
Ethernet Hub
VPI Power and VRD Relays
VPI2 SLP
WA Local Panel
VPI2 WA
Power Supply
62
Alstom Vehicle Rack
MicroCabmatic III
63
USS SLP and WA
64
Equipment from all 4 suppliers
65
Demonstration

• Break into 4 small groups
• Remember your group name
• Alstom
• GETS
• Safetran
• USS
• When your group is called, proceed into Critical
  Link lab with your representative

66
Demonstration

• In order to keep things moving, please hold your
  questions until we are all gathered back together
  in this room.

67
What you'll see

• Overview of each suppliers equipment
• Overview of Comm Router Capabilities
• Ability to throw switches (if signal not cleared)
  on each suppliers territory

68
What you'll see

• Use of USS OBLP simulator on Alstom territory
• Demonstrate received messages for switch
  positions and signal status
• Alstom OBLP starting in GETS territory
• Demonstrate ability to upgrade and downgrade
  in-block signals
• Demonstrate overspeed penalty brake
• Demonstrate profile braking stop when approaching
  a stop signal

69
What you'll see

• GETS OBLP starting in GETS territory
• Demonstrate braking, profile, following moves
• Use of Alstom OBLP on USS territory moving
  through their territory
• Show information available related to occupied
  blocks and subsections, signals and switches in
  advance, distance to go, civil speed

70
Questions / Comments ?(Backup details available
at www.billpetit.com/icbs.html)

• Bill.Petit_at_ieee.org