To: RTVISC - Working Group 2

From: Dave Rutherford – WG2 Co-chair

 Subject: Report on WG2 Task Force Conference – 5, 6, 7 Aug 97 – St. Michaels, MD

A special WG2 Task Force conference was held in St. Michaels, MD on Tue/Wed/Thurs, 5, 6, 7 Aug 97. One representative from each of the nine (9) suppliers developing CBTC systems was invited, and eight (8) attended. Present also were Geoff Hubbs and Alan Rumsey representing NYCT; Ron Kangas, Jeff Mora and Venkat Pindriprolu representing the FTA; Lou Sanders representing APTA, and Tom McGean and Dave Rutherford representing IEEE WG2.

The goal of the conference was to create a consensus standard for CBTC wayside Ö train communication message content and format.

Attendees:

AFFILIATION	NAME	PHONE	FAX
ADtranz	Jeff Stover	412 655 5346	412 655 5108
Alcatel - SELC	Bill Gallagher	416 742 3900	416 742 9088
APTA	Lou Sanders	202 898 4086	202 898 4019
ATSG (NYCT)	Alan Rumsey	212 266 8527	212 266 8536
NYCT	Geoff Hobbs	212-492-8495	212-492-8360
FTA	Ron Kangas	202 366 0212	202 366 3765
FTA	Jeff Mora	202 366 0212	202 366 3765
FTA	Venkat Pindiprolu	202 366 8061	202 366 3765
GE Harris	Florence Heidel	407 242 5146
GRS	Bill Petit	716 783 2017	716 783 2080
Harmon	Tod Mauerman	562 427 4273	562 427 4993
MATRA	Roland Tousch	011 33 1 49 65 71 73	011 33 1 49 65 71 19
RSE (WG2)	Dave Rutherford	716 292 1440	716 292 1446
TJMPE (IEEE)	Tom McGean	703 280 2299	703 280 0748
US&S	Denny Pascoe	412 688 2710	412 688 2307
WSL	Harry Ryland	011 44 12 49 1426	011 44 12 49 44 1440

SUMMARY

A table (Table 1: see Appendix 1) was created which compared various design aspects of each supplier’s CBTC system designs. The design aspects used were selected to accentuate known differences in each design.

At this point in the conference, discussions among the suppliers and NYCT concluded with the decision that for a number of reasons (see below), it would not be possible for the suppliers to reach a unanimous consensus regarding message format.

One fact that contributed to this decision was that NYCT indicated that if the proposed consensus standard was not unanimously accepted by all suppliers, it would not be included in the RFP for Canarsie as a requirement. NYCT made it clear that it was not in their best interest to eliminate potential suppliers from submitting proposals for the Canarsie project based on their non-conformance to a consensus standard.

The group continued, however, to discuss what they would consider an ‘best fit’ message structure, at least in so far as information content was concerned. The ‘best fit’ structure represents information required by the majority of the suppliers’ systems to implement each of the design aspects summarized in Table 1. This ‘best fit’ structure is summarized in Table 2 (see Appendix 2). While the structure represented the majority of designs for each design aspect, no one supplier conformed to the ‘best fit’ in all aspects.

Thus the attempt to create a consensus standard for the wayside Ö train message was not in itself successful. However, it was agreed by those present that there would be benefit in shifting the focus of the working group to standards for CBTC performance, function and operational specifications.

Such a focus would necessarily require active participation by the transit agencies intent on procuring CBTC systems. This topic will be presented to a group of transit agencies meeting at PATH in New York on 29 September. If there is commitment among the agencies, the proposed change in focus will be presented to the members of WG2 and the full IEEE committee for a decision.

A group of transit agencies met on 24, 25 July at NYCT to discuss the implications of interoperability standards in general and the WG2 efforts to date. The minutes of this meeting (written by Alan Rumsey) are included in Appendix 3.

ABBREVIATED MINUTES

Day 1: August 5^th

! Tom McGean and Lou Sanders welcomed the group and stressed the unique window of opportunity for standardization presented by this meeting.

! Geoff Hubbs and Alan Rumsey gave a brief review of NYCT’s requirements for the Canarsie project:

NYCT requires a ‘smart’ vehicle, i.e., able to perform specified tasks without information from the wayside in the event of a communication failure. NYCT desires at least three qualified suppliers, and interoperability is a key issue.

There is at this point no preferred radio system, and the radio reliability and functionality represent the largest unknown. LIRR may participate in NYCT’s test phase.

If an IEEE interoperability standard can be adopted unanimously, NYCT will specify it as a requirement. It was intially stated that in the case of a non-unanimous consensus standard, those proposers conforming to the standard will be favorably considered, but it will not be a requirement. Later, NYCT indicated that no favorable consideration would be given if conforming would require a design change by the supplier.

Phase I of the Canarsie project will use a two mile test track on the Culver line, and a nominal $1 M will be provided to each of the three suppliers selected for Phase I. Phase I award: April - Aug, 1998. Phase I testing will begin in early 1999 for 6 months. Award for Phase II will be made in Oct. 1999, and the selected supplier will create the interoperability standard.

The specification included in the RFP is based on performance requirements; system architecture is not defined, however several requirements require considerable intelligence on the vehicle.

! Alan Rumsey summarized the 24, 25 July transit agency meeting in NYC on CBTC interoperability and functional and performance requirements. (see Appendix 3 for meeting minutes).

! Dave Rutherford defined the purpose of the meeting and outlined the first day’s agenda.

! Nine suppliers were invited to the conference. All attended with the exception of GEC Alsthom. All suppliers attending came prepared with information describing their system’s topographical representation methodology and train> wayside, wayside>train interface data.

! A preliminary version of Table 1 was proposed as a mechanism for identifying key differences in the design aspects of each supplier’s CBTC system which would affect the train Ö wayside message structure. Additional functional & design aspects were added. Each supplier indicated which of the listed aspects were applicable to his system. The completed Table 1 (see Appendix 1) shows in bold the various aspects in which a majority of the suppliers were essentially equivalent.

! The process of negotiating a consensus standard for wayside Ö train message structure and format began with a discussion of the various methods used by each supplier to represent topographical data. It was considered necessary to reach agreement on topographical representation prior to discussing actual message structure.

At this point, it became apparent that several suppliers were sufficiently divergent in their developed CBTC system designs so that a unanimous standard would not be possible. This being the case, it was agreed not to attempt negotiating a consensus standard and that some benefit could be gained by discussing a "best fit’ standard for topographic data representation and wayside Ö train message structure.

Day 2: August 6^th

! The group completed its discussion of the ‘best fit’ standard, summarized in Appendix 2.

! Ron Kangas advised that FTA was disappointed that a more serious effort had not been made on an interface standard, and indicated FTA’s concern that this could result in a situation where NYCT had a unique CTBC system.

Day 3: August 7^th

• The question was raised as to the future direction of WG2 since it would not be able to achieve the stated purpose of its PAR at this time. Tom McGean noted that this meeting was a Task Force only, and could not decide the future of WG2. However, a recommendation would be appropriate and carry weight with the WG2.
• Bill Petit suggested reconvening WG2 after the NYCT final award to the CBTC leader. Alan Rumsey suggested to instead redirect the WG2 focus to developing core functional and performance stds. for CBTC, including safety, reliability, ATO functions, etc. Interoperability would be left to NYCT and architecture would be left to each supplier.
• Although it was not clear if this effort could be completed in time to affect the Canarsie line, Jeff Hobbs and Alan Rumsey committed to serve actively on WG2 if it undertook this responsibility.
• After much discussion, the Task Force agreed to recommend that WG2 develop a core functional and performance standard for CBTC. Transit agencies would consider this recommendation at their CBTC meeting at the end of September. The support of transit agencies, who set the functional/performance specs, would be essential to success.
• Based on agreement by the transit agencies of the value of the new direction, the full WG2 would take up the proposal in a FAX/e-mail/mail poll. If supported by the members, the proposal would be presented to the full RTVIS committee at its October 97 meeting.
• It was agreed that the current IEEE PAR would be left in limbo, to be reactivated if conditions change. A new/revised PAR would have to be submitted to create the functional/performance standard, but the group could begin the work without PAR approval, so this is not schedule-critical.
• It was agreed that the WG2 meeting in conjunction with the AAR August Meeting in Nashville would be CANCELLED.

 Regards,

David B. Rutherford, Jr. , WG2 Co-Chair

TOP LEVEL CATEGORIES	ALC	ADZ	GEC	GEH	GRS	HAR	MAT	USS CSEE	WSL
1. TOPOGRAPHIC DATA
- on board		X		X	X	X	X	X	X
- broadcast to train	(Ö )
- wayside	X	X		X	(Ö )	X			X
2. LOA XMIT
- xmit each train	X	X		X	X	X			X
- broadcast to zone							X	X
3. LOA (obstacle or EOR)
- actual obs. Position		X		X	X	X	X	X	X
- target point includes safety margin from obs.	X
4. ROUTE XMIT
- as switch positions					X	X	X	X	X
- as segments		X		X
- no route info xmitted	X
5. OBSTACLE XMIT
- civil limits as LOA	X
- TSR treated as LOA	X
- unaligned/open switch	X	X		X	X	X	X	X	X
- vehicle ahead	X	X		X	X	X	X	X	X
- End of Route	X	X		X	X	X	-	-	X
6.TEMP SPEED RESTRIC’s
- acknowledge required				X			X	X
- treated as temp. topo data		X		X	X	X	X	X	X
- rcv’d as LOA obstacle	X
7. ONBOARD SAFE SPEED LIMIT CALC
- uses topo data		X		X	X	X	X	X	X
- topo data not used	X
- route info used		X		X	X	X	X	X	X
- route info not used	X
8. CIVIL SPEED
- calc from topo data		X		X	X	X	X	X	X
- xmitted as LOA data	X
9. FREQ MSG XMIT
- periodic	1s	1s			1s	PTG	2s	2s	1s
- non-periodic (as needed) - (within range)				X		LOA
10. EMERGENCY STOP
- periodic permiss to go	(Ö )	X			X	X	X	X
- emerg stop request	X	X		X					X
- broadcast						X	X	X	X
- per train	X	X		X	X		X	X	X
11. W>T DATA RATE
- (assume 20 trains per zone)	4*1200	64K		?	38.4K	9.6K	9.6K	9.6K	2.4K
12. T>W DATA RATE
- (assume 20 trains per zone)	4*600	64K		?	38.4K	9.6K	4.8K	4.8K	2.4KM
13. VIRTUAL/MOVING BLOCK
- virtual					Ö		X	X
- moving block	X	X		X	Ö	X	Ö	Ö	X
14. LOCATION
- sector/segment	X	X		X	X	X	X	X	X
- offset within segmt		X		X		X	X	X	X
- var seg. Lengths		X		X	X	X	X	X	X
- fixed seg lengths	X
- position resolution
-fixed (size)	20’
- variable (max)		1’		5’-50’	15’	1’	3’	3’	3’
- ATP uncertainty	20’	Var		5’	5’	5’-15’	15’	15’	<15’
15. GRADE REP
- grade per segment		X		X	X	X	X	X
- point of vert inflect.	X
- other									X
16. LOCATION REL TO.
- segment		X		X	X	X	X	X	X
- seg/offset		X		X		X	X	X	X
- zone start	X	X
17. SPEED RESOLUTION (MPH) - COMMANDED	3.5	.25		1.0	1.0	1.0	.25	.25	3.5
18.TRAIN POS. RPT
- physical		F/R		F/R	F	F	R	R	F
- virtual		F
- antenna pos	X
- train length					X	X	X	X	X
19. POS. UPDATE
- xponders	X	X			X	X	X	X	X
- ranging						X
- loops
- GPS (Diff)				X
20. TOPO UPDATE
- CBTC Radio		X		X	X	X
- Separate Radio							X	X
- TWC loops
- other									X
- online/offline		OFF		OFF	ON	STA	OFF	OFF	OFF
21. BRAKING CURVE SELECTION	X	-		-	-	-	-	-	-
22. INTRUSION (NEGATIVE SENSOR)							X	X
23. VERIF METHOD
- CRC	X	X		X	X	X			X
- 2 times	X								X
- other
- time stamp					X		X	X
- sequence	X	X			X	X			X
- arithmetic code							X	X

ONBOARD DATABASE	WAYSIDE-TO-TRAIN (ATP)	TRAIN-TO-WAYSIDE (ATP)
FIXED DATA Train Performance Data -accel rate(s) -safe brake rate -max speed ATP Identity(ies)	PERIODIC (~ 1s per train) Wayside Identity Train ATP Identity Onboard Database Version (+ verification data per subset) Absolute LOA -Sector (Zone) ID -Segment ID -Offset (ft) Route Information to LOA -# of Switches -Switch Positions Traffic Direction Traffic Direction after LOA to Next Home Signal (i.e. permission to proceed past LOA following loss of data communications) Emergency Stop (Set/Reset) Data to Ensure Message Integrity (e.g. sequence numbers, CRC’s etc.) - timestamp? Ancillary Communications Protocols	PERIODIC (~ 1s per train) Wayside Identity Train ATP Identity Train Limits that Bound Train Position (including uncertainties and train integrity considerations) -Train "Front" Posn. -Sector (Zone) ID -Segment ID -Offset -Train "Rear" Posn -Sector (Zone) ID -Segment ID -Offset Train Stopped (Zero Speed) Data to Ensure Message Integrity (e.g. sequence numbers, CRC’s etc.) - timestamp? Ancillary Communications Protocols

ONBOARD DATABASE	WAYSIDE-TO-TRAIN (ATP)	TRAIN-TO-WAYSIDE (ATP)
DATA DOWNLOADED FROM THE WAYSIDE (ATP) - (For current zone as a minimum) Topographical Data -Stationing Reference -Sector (Zone) ID -Zone Boundary -Zone West Connect -Zone East Connect -Segment ID -Segment Length -Seg. West Connect -Seg. East Connect -Switch ID’s -Converge Connect -Normal Connect -Reverse Connect -Segment Speed Limit -Segment Grade -Home Signals -End of Track -Station Platforms -East Connect -West Connect -Orientation -Transponders -ID -Location -East Connect -West Connect Database Version Number	DATA TRANSMITTED AS NEEDED Database Downloads Slow Speed Order (Set/Reset) - (as database update) -Speed Limit -Start Position -End Position -Route Info. Restricted Speed (Set/Reset) Work Zones (Set/Reset) - (as database update) Data to Ensure Message Integrity (e.g. sequence numbers, CRC’s etc.) - timestamp? Ancillary Communications Protocols	DATA TRANSMITTED AS NEEDED

ONBOARD

WAYSIDE

CALCULATED DATA Train Front Position (incl. position uncertainties) Train Length Train Integrity Train Rear Position (incl. position uncertainties and train integrity considerations) Train Speed (incl. speed measurement uncertainties) Train Travel Direction ATP (Speed/Distance) Profile Maximum Authorized Speed at Current Location (from ATP profile) Train "Berthed" at Station Platform Operating Mode In/Out CBTC Territory

CALCULATED DATA MA Limit for Each Train Train Tracking -CBTC Trains -Non-CBTC Trains Zone-to-Zone Transfer

MINUTES OF MEETING

Purpose: Meeting of Transit Property Representatives on the Subject of Communication-Based Train Control (CBTC) for Consensus Development and Standardization

Date: July 24/25, 1997

Attendees: See attached sign-in sheets

Minutes:

1. Nabil Ghaly (NYCT) welcomed participants to the meeting.
2. Venkat Pindiprolu (FTA) introduced the purpose of the meeting and summarized standardization benefits.
1. The need for transit agencies to "take charge" in driving the market, establishing needs, and striving for standardization to reduced costs, was emphasized.
2. A proposed CBTC course at the National Transit Institute was described and comments were solicited from participants as to the course content, frequency and anticipated attendance from each agency.
3. The issue of using an unlicensed RF band for CBTC was discussed (ref. current proposed use of the ISM 2.4 GHz band). It is estimated that radio component costs would increase by a factor of three to move to the 5.8 GHz band.
3. Doug Haluza (LIRR) made reference to a "Call for Papers" for the 1998 ASME/IEEE Joint Railroad Conference, and encouraged papers on CBTC.
4. Nabil Ghaly (NYCT) presented the NYCT signal modernization program including the background to the selection of CBTC technology as the most appropriate and most cost-effective technology as NYCT’s future standard.
1. The key safety requirements for NYCT include signal protection for unequipped trains, signal protection for failed trains, and broken rail detection.
2. The need for an Auxiliary Wayside System (AWS) was described and mixed fleet operations was discussed.
3. The NYCT interoperability requirements were stressed.
4. The NYCT conceptual CBTC design includes intelligent vehicles, distributed CBTC wayside architecture, and independence between CBTC and interlocking controls.
5. Key system interfaces and issues effecting interoperability (functional allocation, system architecture, failure modes/responses, performance requirements, database formats, user interfaces, maintenance diagnostics, etc.) were discussed.
6. NYCT’s procurement strategy was described.
7. Issues of technology obsolescence, life cycle costs and systems integration were also discussed.
5. Steve Mullerheim (BART) described the status of BART’s AATC program.
1. Hughes EPLR radio network/radio ranging system was described.
2. It was noted that BART’s needs differ from NYCT. At BART an ATC system is already installed, therefore AATC will only provide train location/speed code generation functions.
3. BART also has a different philosophy to NYCT. BART assumes that AATC will fail so infrequently, that there is therefore little or no need for any back-up capability.
4. It is important for BART that the AATC system is not an "orphan" system and as a result an association is currently being negotiated with an established signaling supplier.
5. It is proposed that the AATC system make use of a wayside tag reader enhancement for lateral (track to track) discrimination and system initialization (check-in/check-out).
6. AATC system-wide implementation at BART will be essentially a sole source procurement. BART are not looking for competitive procurement on individual line segments.
7. The following key issues were noted:
1. Radio versus radio network.
2. Radio ranging versus transponders.
3. Vehicle versus wayside centric architectures.
4. Software verification and validation.
6. Patty Devlieg (MUNI) provided a summary of the MUNI ATCS project.
1. ATCS is a proprietary system and as a consequence MUNI are essentially locked-in to this system on future extensions.
2. Database changes cannot be made in-house (was not a requirement of the initial specification); requires Contractor to make changes.
3. MUNI does not require broken rail detection through ATCS.
4. The importance of organizational commitment to a new technology project was stressed.
5. At MUNI, the independent safety consultant process has been very successful.
6. The following key issues were noted:
1. Attention to systems integration.
2. Managing software development.
3. Providing timely interface data to the Contractor.
4. Operating Plan is a key top level design document.
5. Proven system does not necessarily translate to easy implementation.
7. Peter Furkey (PATH) noted that the existing PATH system is similar to NYCT in terms of technology. They are also planning signaling replacement and a move to ATO in conjunction with new car procurement.
1. Conceptual design has been developed based on AF coded track circuits. However, PATH are re-assessing technology based on CBTC evolution. There is a timing problem, as PATH need to be doing something quickly.
2. Current recommendation is to delay signal replacement for 5 years until CBTC standard has been established. The existing signaling system has been brought into state of good repair and could be kept operational for another 5 - 10 years.
3. The alternative for PATH is AF coded track circuits. Mature systems available which could be implemented with limited problems, but PATH does not want to purchase the "last" track circuit based system. Trying to avoid a costly mistake.
4. PATH believes that a CBTC standard established to meet NYCT needs, should meet PATH’s needs.
8. John LaForce (SEPTA) noted that SEPTA were planning for CBTC on a light rail (trolley line) in 1999 (based on NYCT standard) but project is being advanced.
1. EFI (Engineer, Furnish and Install) procurement is being considered based on design criteria which would establish key architectural requirements
2. Currently no plans for CBTC on rapid transit or commuter rail, but watching LIRR experience with grade crossing.
9. Victor Grappone (LIRR) advised that LIRR’s signal strategy for the next 20+ years is based on CBTC. ($700 million program of which more than 50% would be for CBTC).
1. Three pilot projects are planned:
1. One very interactive with Canarsie - synergy with NYCT.
2. One related to grade crossing (constant warning times and near side station stop, with tie in to intelligent highway signs).
3. One being LIRR’s own pilot project (15-20 miles), near Babylon to demonstrate basic safe train separation.
2. LIRR believe that a CBTC system that satisfies NYCT’s requirements should satisfy LIRR requirements (other than grade crossing).
10. John Lewis (MBTA) noted that MBTA are looking at CBTC for the Green Line to provide enhanced safety. On the Blue Line, anticipated ridership increases could also lead to consideration of CBTC in the 2000+timeframe.
11. John Vogler (NJT) noted that NJT predominately use, or plan to use, traditional cab signaling systems on both the mainline and on light rail lines.
1. They are about to award a contract for positive train stop on lines that may not get cab signaling for some time; this will be a modified version of the Amtrak transponder system, but Amtrak now also looking at radio interface.
2. NJT do not want to be leader in CBTC - needed something that could be implemented quickly.
12. Dave Rutherford summarized information needs for standardization, with emphasis on the current IEEE efforts to develop interface standards for CBTC.
1. IEEE dealing with basic ATP functions only.
2. Six objectives have been established for CBTC standards.
13. During subsequent discussions, the following was noted:
1. Transit property should have ability to modify databases without going back to supplier.
2. Database downloads should be transparent to operations.
3. PROM-based databases onboard vehicle are not desirable.
4. Fleet interoperability should be transparent to operations and maintenance.
5. CBTC should support a range of headway requirements.
6. It is desirable to be able to continue to end of authority in the event of loss of data communication.
7. Fleet initialization should not impact operations.
8. Additional bandwidth should be provided for other uses such as passenger information and health monitoring.
9. No concerns on vital and non-vital messages on same channel.
10. CBTC should have capability to interface with conventional interlockings.
11. General desire is to move away from track circuits (long term).
12. Standardizing carborne interfaces - e.g. to propulsion/brakes/doors, slip/slide, transponders, etc. is also desirable.
13. Desire to ultimately obtain licensed spread spectrum band will need industry consensus.
14. General level of comfort with 2.4 GHz for now.
15. Use of non-vital central for track blocks/switch blocks/slow speeds acceptable if appropriate consideration of potential hazards in the design and associated operating procedures.
14. A report on the upcoming supplier meeting to address CBTC standards will be published by August 13, 1997.
15. A follow on meeting of transit property representatives was scheduled for September 29, 1997; Peter Furkey (PATH) will host.

 Prepared by:

____________________________________

Dr. Alan F. Rumsey, ATSG