IEEE Rail Transit Vehicle Interface Standards Committee
MEETING OF WORKING GROUP #2
COMMUNICATION BASED TRAIN CONTROL
Date: April 19, 2006 - 8:30 am
Place: Bombardier, Pittsburgh
Attendees:
Name
/Representing
/ EmailCorinne Braban / Siemens / .
Fred Childs / PATH /
Dave Dimmer / Alcatel /
Marc Drolet / Bombardier /
Harvey Glickenstein / PB /
Ken Karg / Bombardier /
Norm May / Lea+Elliott /
Dan McFadden / Lea+Elliott /
Alain Quidu / Alstom /
Alan Rumsey / Parsons /
Carl Thompson / Gannett Fleming /
Robert Walsh / Bombardier /
Minutes of Meeting:
1. HOUSEKEEPING ITEMS
1.1. Introductions
Alan Rumsey thanked Bombardier for hosting this 36th 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 January 25 2006 were reviewed and accepted as written, except that the last paragraph of section 1.5 was revised as follows:
“Corinne Braban reported that a System Architecture had been developed under the MODURBAN Project but there were a number of open areas where no consensus had been reached on functional allocations. Firth Whitwam also reported that the UITP had initiated a survey of transit authorities to determine the level of interest in interoperable systems.”
1.3. IEEE-SA Standards Board Bylaws on Patents in Standards
Alan Rumsey provided two PowerPoint slides from the IEEE-SA Standards Board and advised the WG2 membership that:
· The IEEE’s Patent Policy is consistent with the ANSI patent policy and is described in Clause 6 of the IEEE-SA Standards Board Bylaws;
· Early disclosure of patents which may be essential for the use of standards under development is encouraged;
· Disclosures made of such patents may not be exhaustive or include all patents that may be essential for the use of standards under development, and neither the IEEE, the WG nor the WG Chairman ensure the accuracy or completeness of any disclosure or whether any disclosure is of a patent that, in fact, may be essential for the use of the standards under development.
An opportunity was then provided for WG2 members to identify or disclose patents that they believed may be essential for the use of the standards under development by WG2. No patents were identified by the WG2 members present during the meeting.
1.4. Liaison with IEC Technical Committee 9 (TC9) Working Group 40 (WG40)
The international standard being developed by this working group is intended to define functional, system and interface requirements for command, control, and management systems used on urban, guided passenger transport lines and networks, and as such its objectives parallel some of the IEEE WG2 objectives.
The working group includes representatives from France, Germany, Italy, Japan, China, Canada, Singapore, the UK, and the US. Alan Rumsey is the US representative on the working group. Lou Sanders is the US representative on TC9. Bombardier have indicated a willingness to provide a second US representative on WG40.
The IEC standard is intended to be divided into four parts:
· Part 1: "System Principles and Fundamental Concepts"
· Part 2: "Functional Specifications"
· Part 3: "System Specifications/System Architecture", and
· Part 4: "Interface Specifications"
Part I has been successfully balloted.
Work on Part II is in progress. The last meeting was held in London, England on March 6/7, 2006. The next meetings will be held in Italy on June 1/2, 2006 and in Singapore on September 25/26, 2006
Work on Part III is currently not scheduled to commence before 2007. Work on Part IV is currently not scheduled to commence before 2009.
IEEE Std. 1474.1 is being used as one input to this IEC effort.
1.5. European “MODURBAN” Project Summary
MODURBAN is a four year European research project (2005 – 2009)
The project goal is to define a CBTC-type system for urban transit applications in Europe that will be interoperable and provide for interchangeability of equipment from different suppliers. Principle activities will involve completion of functional requirements, definition of a system architecture, definition of subsystem requirements, and specification of interfaces. In addition prototype subsystems will be developed and a field test will be undertaken.
The MODURBAN project is also providing inputs to IEC TC9 WG40.
Given the number of open areas where no consensus had been reached on functional allocations, the future of the MODURBAN project is somewhat unclear.
A survey of transit authorities, initiated by UITP to determine the level of interest in interoperable systems, has been issued.
The MODURBAN system architecture includes a “Spot Transmission System”. The Eurobalaise is being consider as one possibility for this system.
1.6. Date/Location of Next WG2 Meeting
The next WG2 meeting will be held on Tuesday, August 29, 2006. The meeting location is not confirmed and both East Coast and West Coast locations are currently being considered. Norm May agreed to explore if Lea + Elliott could possibly host the next meeting. BART will also be approached as a potential meeting location (ACTION: Alan Rumsey).
The working group supported and encouraged increased transit agency participation in WG2.
A second WG2 meeting was also tentatively scheduled for Thursday, November 16 (to be confirmed).
2. PROPOSED RECOMMENDED PRACTICE FOR CBTC SYSTEM DESIGN AND FUNCTIONAL ALLOCATION
Following discussions at the last WG2 meeting it was the WG2 Chair’s recommendation that the proposed standard be re-classified as a “Recommended Practice”. The basis for this recommendation was that while there could be many possible system designs to achieve the performance and functional requirements of IEEE Std. 1474.1, the current state-of-the-art and industry trends indicate that in many areas there is a preferred approach to allocating the functional requirements to the individual CBTC subsystems. The proposed Recommended Practice for Communications-Based Train Control (CBTC) System Design and Functional Allocations would document these preferred approaches as current best industry practice. In those areas where there is no clear-cut recommendation, the document could also describe the alternative approaches.
The proposal to re-classify the proposed standard as a “Recommended Practice” was endorsed by the WG2 members.
Draft 4.0 of the proposed IEEE document had been prepared based on the above recommendation. Written comments on Draft 4.0 had been received from Corinne Braban, Alain Quidu and Ken Karg, and were distributed to the meeting participants.
2.1. Proposed Scope/Purpose/Introduction
Agreement was reached on the following scope and purpose for the Recommended Practice and a Project Authorization Request (PAR) will now be raised on this basis.
Scope
This recommended practice establishes a preferred system design and functional allocation for CBTC systems.
Purpose
The purpose of this recommended practice is to define a preferred CBTC system design/system architecture to achieve the CBTC performance and functional requirements of IEEE Std. 1474.1-2004, and to allocate functions to the major CBTC subsystems.
It was also agreed to add a note in the Introduction section to clarify that in those areas where there is no clear-cut recommended practice, and alternative approaches are described, that it is not the intent of the document to provide any recommendation or guide as to which alternative approach should be selected for a specific application. This decision would typically be made by the CBTC system supplier, in association with the authority having jurisdiction.
2.2. Section 4 (General Requirements)
No changes were made to Section 4.
2.3. Section 5 (CBTC System Design)
Last paragraph of section 5.1 re-written as:
“The recommended allocation of ATP, ATO and ATS functions to the above major CBTC subsystems is defined in sections 6, 7 and 8 respectively. Where there is no clear-cut recommendation to a given functional allocation, alternative approaches to good practice are described.”
2.4. Section 6 (ATP Functional Allocations)
Section 6.0 was reviewed in detail and specific agreed changes included:
a) Figure 2 will be updated based on meeting discussions.
b) Figure 3 (and Definitions section) will be updated to delete references to “Absolute MAL (Vital)”, “Non-vital MAL” and “variable” safety margin.
c) “For example …..” bracket in requirement 6.1.2.3 and requirement 6.6.1.2 will be deleted.
d) Requirement 6.1.4.1 will be re-stated using similar wording to requirement 6.1.4.2
e) Cross reference to 8.5.3.1 will be added to note 2 in requirement 6.2.1.1
f) Reference to “all trains” in note 1 of requirement 6.2.1.4 will be changed to “all equipped trains”.
g) For the purposes of this recommended practice, determining the limit of movement protection will be represented as a two step process. First, the limit of movement protection for a given train will be determined based on fixed and variable ATP data associated with the location of trains ahead of the given train, and the status of the route ahead of the given train. A single functional allocation will be defined for this step (i.e. wayside function). The limit of movement protection may then subsequently be modified (i.e. made more restrictive) in response to other variable ATP data input to the CBTC system (e.g. loss of switch status). Alternative functional allocations will be described for this step (i.e. either wayside or train-borne function). The document will be restructured based on the above as a number of requirements are affected. (ACTION: Alan Rumsey).
h) Alternative approaches to achieving requirement 6.2.1.7 will be included.
i) Describing each alternatives as “option 1” and “option 2” may be confusing and may imply that all “option 1” alternatives (for example) must be selected together which is not the intent. Other approaches to describing alternatives will be explored. (ACTION: Alan Rumsey).
j) In note 1 of requirement 6.4.1.3 (option 1), change “train-borne” to “wayside”
k) Consider including “door status” as an input to requirement 6.5.1 (or define an additional requirement).
l) Second paragraph of section 6.7 will be changed to a “note”.
m) In requirement 6.7.2.1 change “that” to “than”.
n) Add requirement for close-up and coupling from IEEE Std. 1474.1-2004.
o) Expand requirement 6.7.3.2.
p) Expand section 6.8 to clarify alternative approaches to managing fixed ATP databases.
q) Section 6.9 will be reworked to better reflect requirements for platform edge doors and to show links to other functions. (ACTION: A. Rumsey).
A review will be undertaken to ensure that all of the functional requirements defined in IEEE Std. 1474.1-2004 have been captured in the new recommended practice. (ACTION: Norm May).
2.5. Section 7 (ATO Functional Allocations)
Section 7.0 was reviewed and specific agreed changes included:
a) Figure 4 will be added to show relationship between ATO functions (similar to Figure 2 for ATP functions). ACTION: Alain Quidu.
b) It will be clarified that while ATO may be optional, if an ATO mode is provided, certain ATO functions become mandatory.
c) CBTC-ATS input will be added to requirement 7.2.1.2
d) Requirement 7.2.1.3 to be updated based on changes to 6.9.1
e) Cross reference in requirement 7.3.1.1 to be corrected to 6.2.1.
f) Requirement 7.4.1.1 to be updated for consistency with ATP section.
2.6. Section 8 (ATS Functional Allocations)
Section not reviewed.
2.7. Section 9 (Data Flows Between CBTC Subsystems)
Section not reviewed.
2.8. Timeline to Complete Recommended Practice
The working group agreed to target to have the recommended practice ready for ballot by the end of 2006 or early 2007.
3. ANY OTHER BUSINESS
Alan Rumsey agreed to update and distribute draft D5.0 of the proposed recommended practice in July for review at the next WG2 meeting in August. (ACTION)
Bombardier provided an interesting tour of their manufacturing a test facilities.
Minutes prepared by:
Dr. Alan F. Rumsey
WG2 Chair
WG2 Meeting - Page 5 - April 19, 2006