TCIP TWG Kickoff Meetings

1. TCIP TWG Kickoff Meetings TWG Chair Meeting November 25, 2003

2. Welcome & Introductions Lou Sanders APTA Isaac Tayki / Jerry Lutin TCIP Task Force Co-Chairs

3. Agenda • TCIP Task Force Structure John Fayos • TCIP Status & Review Plans John Fayos • TCIP 2.4 Rob Ayers • TCIP 2.4 Review Objectives Rob Ayers • TCIP Web Site Diane O’Neill • Review Comment Submissions Diane O’Neill • Q&A

4. TCIP Task Force Structure John Fayos Critical Link

5. TCIP Task Force • Task Force Co-Chairs • Isaac Tayki & Jerry Lutin • TWG Chairs Committee • TWG Chairs • Chair Coordinating Forum (CCF) • Task Force Co-Chairs • APTA Technical Team • Staff Advisor • Lou Sanders

6. Technical Working Groups • TWG 1: Scheduling / Runcutting (Dan Overgaard) • TWG 2: Passenger Information (Mark Nawrath) • TWG 3: Incident Management (Edward Mark) • TWG 4: Software Tools & Test (Bill Hiller) • TWG 5: On Board (TBA) • TWG 6: Control Center (Marc Gordon) • TWG 7: Fare Collection (H Rosen & CC Tam) • TWG 8: Spatial Representation (Bibiana Kamler) • TWG 9: CPT & TCIP Framework (Polly Okunieff) • TWG 10: Signal Control & Prioritization (TBA)

7. TCIP Task Force

8. Task Force Co-Chair Responsibilities • Coordinate, in conjunction with APTA, the overall TWG review activities of the TCIP 2.4 standard • Members of the Chair Coordinating Forum (CCF) • Disposition of major and trans-TWG review comments / changes to the standard • Provide overall direction of TSC technical assistance effort • Point of Contact for TWG chairs • Support ongoing TCIP Strategic Planning activities

9. TWG Chair Responsibilities • Coordinate review activities within their TWG • Encourage participation of all group members • Direct TSC technical assistance within their TWG • Act as the primary point of contact between their TWG and the APTA technical team • Review ongoing TCIP Strategic Planning activities

10. TWG Member Responsibilities • Review and comment on applicable areas of the TCIP 2.4 standard • Work with APTA technical team on resolution of review comments • Primary Technical Review Focus: • Concept of Operations: do the functional requirements embodied in the Concept of Operations sufficiently address the operational needs of a transit agency? • Dialogs: will the dialogs successfully implement the functions outlined in the Concept of Operations?

11. TSC Technical Assistance • TSC will be providing technical consultants to support each TWG • TSC TA’s may receive additional tasking direction from the CCF • Responsibilities: • Facilitate discussion within the TWG • Read narrative section of TCIP 2.4 document • Sections 1 thru 9 (pages 1-88) • Review and comment on applicable Narrative sections • Review and comment on applicable Annex sections • Dialogs • Data messages, frames, and elements

12. TCIP Status & Review Plans John Fayos Critical Link

13. Current Status of TCIP • TCIP 2.4 released on Nov 1 • Includes: • TCIP 1 Data Elements and Messages (now called Data Frames) • Concepts of Operation • Dialogs • Includes all business areas except Spatial Representation • Scheduling • Passenger Information • Incident Management • Onboard • Control Center • Signal Priority • Fare Collection • Common Objects

14. TWG Review Process

15. TCIP 2.4 Review Schedule • TWG Chair Webinar Meeting • Nov 25, 2003 • TWG Webinar Kickoff Meetings • Scheduling Dec 15, 1:00-2:30 PM EST • Passenger Information Dec 8, 1:00-2:30 PM EST • Incident Management TBD • Onboard / Control Center TBD • Signal Priority TBD • Fare Collection Dec 8, 3:30 – 5:00 EST • Common Objects TBD • TWG Review Meetings • Group meetings to discuss initial review progress • Jan 21-23, 2004 in Annapolis, Maryland • TCIP 2.4 review cycle complete • Feb 29, 2004

16. Overall Review Schedule • TCIP 2.4 • Review cycle complete by end of February • TCIP 2.5 • Includes Spatial Representation business area • Incorporates TCIP 2.4 review comments • Release in April, 2004 • TWG Review complete in May, 2004 • TCIP 2.6 • Public review version • Release in June, 2004 • TCIP 2.7 • Incorporates public review cycle comments • Final version prior to balloting • TCIP 3.0 • Balloted release version of TCIP

17. Other TWG Activities • Software Tools & Test TWG • TCIP Support Tool Requirements Specifications • RFP Specification Tool • Example TCIP “mini-applications” • Conformance tools • TCIP Simulator • TCIP Framework TWG • Includes Common Objects (CPT) business area • Coordination with other standards efforts • Possible future additional TWG’s (beyond TCIP 3.0) • Safety & Security TWG • Decision Support TWG • Procurement Support TWG • Strategic Planning • TCIP Task Force Co-Chairs and TWG Chairs

18. TCIP 2.x Rob Ayers ARINC

19. Discussion Topics • What TCIP 2.x contains • Incorporates TCIP 1 • Addition of Data Frames • Concept of Operations • Dialogs

20. Building the New Standard

21. New TCIP Standard • TCIP 3.0 • Plan to publish a new TCIP standard that incorporates the prior work, as well as XML Schema, and Dialogs • Single Standard instead of 9 documents

22. TCIP 3.0 Standard Outline • Overview • Definitions • Conformance • Understanding TCIP • TCIP Usage in RFPs • TCIP Data (Types, Elements, Frames, Messages)

23. TCIP 3.0 Standard Outline (continued) • TCIP Dialogs (Patterns, Instantiations, Batch) • Concept of Operations(By Business Area) • TCIP Patterns (Patterns are Specified here) • Annex A-Data Elements(By Business Area) • Annex B-Data Frames(By Business Area) • Annex C-Messages (By Business Area) • Annex D-Dialogs (By Business Area) • Annex E-XML Schema

24. Software Tools • Simulator will implement the dialogs as specified in the new Standard • XML Schema will be available in soft copy • XML Schema are usable by commercial databases, browsers, etc.

25. What is a Dialog? • A dialog specifies how and when a group of messages are used. • Dialogs are based on patterns. A pattern specifies a particular type of transaction which can then be used to implement many dialogs. • Patterns and Dialogs provide the context information necessary to effectively use TCIP messages.

26. Business Areas • TCIP I divided the standard by business areas. We plan to follow these business areas as we develop the dialogs. • TCIP Business Areas: • Passenger Information • Incident Management • Signal Priority • Spatial Representation • Common Public Transportation • Scheduling/Runcutting • Fare Collection • On-Board • Control Center

27. Subscription Dialog Pattern Example - Query Server Server Client Client AaaXxxSub AaaXxxSub Calculation Calculation AaaXxx Complete CptSubErrorNotice Complete Complete Complete Normal Execution of Query Subscription Dialog Error Response to Query Subscription Dialog Query Version of the Subscription Dialog Pattern

28. Pattern Example-Periodic Server Client AaaXxxSub Calculation AaaXxx Interval Calculation AaaXxx Interval Calculation AaaXxx Subscription Expires Complete Complete Normal Execution of Periodic Subscription Dialog

29. Example Dialog TCIP Dialog Definition Page 1 Dialog Name: : Subscribe Master Schedule Version Message Sequence Diagram Business Area: : Sch Dialog Pattern: : Subscription Purpose: :Allows a subscriber to determine the currently available schedules {by route(s) and date(s)} from the Server Client scheduling system. Based on this information the subscriber can elicit the information that is available and required using other dialogs. SchMasterScheduleVersionSub Assumptions: 1. By default this is assumed to be an event driven subscription. Calculation 2. The server side determines what internal event triggers a new schedule to become available. For example users may SchMasterScheduleVersion be editing schedules for future use without making them available to subscribers. 3. This dialog may be used with a schedule repository (other than the scheduling/ru ncutting system) as the server. Schedule Change Calculation SchMasterScheduleVersion Narrative: 1.The subscriber determines the routes (or all routes), and the date range of interest, length of subscription, and Schedule Change prepares a subscription request, and sends it to the server. Calculation SchMasterScheduleVersion 2. The scheduling system (or alternate schedule repository) ("Server") validates the request and determines: A. The request is invalid, unauthorized or cannot be serviced. The server then generates a CptSubErrorNotice to the subscriber and the dialog ends. B. The request can be serviced in part. For example the subscription may be downgraded to expire sooner than what Complete Complete the client requested, or a subset of the requested routes can be serviced, or a narrower date range of schedules are Subscription available than requested. The server may either service the part of the request that is possible, or generate a Expires CptSubErrorNotice as described in A above. If the Server elects to service the part of the request the remaining processing treats the serviceable portion as if it were the entire request. C. The request can be serviced. The server prepares a SchMasterScheduleVersion message in response to the subscription request. Normal Execution o f Event Driven "Subscribe Master Schedule Version" Subscription Dialog 3. Assuming the subscription is an event subscription, the server waits for the list of available, subscribed schedules to change ,and notifies the subscriber using a SchMasterScheduleVersion message. 4. The dialog ends if the server generates a CptSubErrorNotice at any time for the subscription request, or if the subscription expires, or if the subscriber sends a SchMasterSchedule VersionSub message with a request identifier matching the original request and a request type of cancel.

30. eXtended Markup Language (XML) • TCIP I Standards are written in ASN.1 • TCIP 2.X uses XML as the implementation language, & include XML Schemas with the new Standards. • Advantages: Better known, more tools, more rapid supplier acceptance, take advantage of ubiquity of web-based products

31. Data Element Example TCIP Data Element Symbolic name cptdd 100 Descriptive Name CPT-SubscriptionType Definition Provide the type of a requested subscription. The types allow the subscriber to ask for a one-shot provision of the information (query), a periodic update of the information, an update whenever the information changes (event), or cancellation of an existing subscription. Class NameCPT ASN1 name CPT-SubscriptionType Usage 1- Query --provide data once & cancel subscription 2- Periodic --provide data at a defined interval 3- Event --provide data initially and update when it changes

32. Data Element Example (cont) Formal ASN1 DeclarationCPT- SubscriptionType:= INTEGER { Query (1), Periodic (2), Event (3), --4-98 reserved Cancel (99) --100-255 reserved } Data typeINTEGER

33. Data Element XML Schema <xs:element name="requestedType" type="xs:string" />

34. Data Frame Example TCIP Data Frame Identifier cpt1000 ASN1 Name CPT-SubscriptionHeader Data Frame Usage The expiration date and time must be specified. Report Interval is required if the requested Type is periodic, and not allowed otherwise. When the header is included in a subscription request, the information reflects the parameters desired by the subscriber. When the header is included in a response to a subscription request, the information reflects the parameters of the subscription actually provided. Request Identifier is a unique identifier that provided by the subscriber. The number is carried forward from the original request to all responses to the request by the server, and any cancellations must carry the same subscription number as the original request.

35. Data Frame Example (cont) Definition Provide a standardized header structure for subscription requests, cancellations, and responses. Frame bodyCPT-Subscription Header ::= SEQUENCE { requestedType CPT-SubscriptionType, expirationDate CPT-DeactivationDate, expirationTime CPT-DeactivationTime, reportInterval CPT-TimeInterval OPTIONAL, requestIdentifier CPT-RequestIdentifier }

36. Message Example TCIP Message Message Purpose Request or cancel a subscription to the versions of timetable information in effect for specified dates and routes from the scheduling system. This elicits the version information about timetables, not the timetables themselves. A subscriber can use the version information to determine what timetable information it needs to obtain. The elicited message is SchMasterScheduleVersion. Message UsageSubscription type should be Query, Event, or Cancel. Periodic should not be used. Routes, if present, signify which routes the subscriber is interested in. If no routes are present, all is implied. Begin Date, if present, indicates that the subscriber is not interested in timetables that are obsolete prior to the indicated date. End Date, if present, indicates that the subscriber is not interested in timetables that are not scheduled to go into effect until after the indicated date.

37. Message Example (cont) Message Identifier sch 2000 Class Name SCH ANS1 NameSchMasterScheduleVersionSub Definition SchMasterScheduleVersionSub ::= SEQUENCE { subscriptionInfo CPT-SubscriptionHeader, beginDate CPT-ActivationDate OPTIONAL, endDate CPT-DeactivationDate OPTIONAL, routes SEQUENCE OF SCH-RouteID OPTIONAL }

38. Message XML Schema <xs:element name="SCH-MasterScheduleVersionSub"> <xs:complexType> <xs:sequence> <xs:element ref="subscriptionInfo" /> <xs:element minOccurs="0" ref="beginDate" /> <xs:element minOccurs="0" ref="endDate" /> <xs:element minOccurs="0" ref="routes" /> </xs:sequence> </xs:complexType> </xs:element>

39. TCIP 3.0 Standard Summary • Concept of Operations • each business area • Traceability • Incorporates TCIP 1 data elements and messages • Addition of dialogs • Conformance Strategy • TCIP usage in RFP’s

40. TCIP 2.4 Review Objectives • Review technical content in TCIP 2.4 Standard • Each TWG focuses on its business area • In particular, review focus is needed on: • Concept of Operations: do the functional requirements embodied in the Concept of Operations sufficiently address the operational needs of a transit agency? • Dialogs: will the dialogs successfully implement the functions outlined in the Concept of Operations?

41. TCIP Website Diane O’Neill ARINC

42. TCIP Web Site • URL: • http://www.arincxchange.com/exchange/login.cfm • Web site is central distribution center for program information • Web site is account controlled • General public access is provided under APTA Guest accounts • Participant Account Information • User ID: your name as it appears on the Task Force or Technical Working Group Participant Lists • Password: initial password is the same as the user ID.

43. Web Site Content • Content • The TF and each TWG has an area on the site to post information • General Program Information • New Member area • Historical Information • Documents in Review • Documents in Review • Current documents under review • Guidelines for TWG comments and comment form

44. Document Configuration Management • Document Configuration Management • Comments are documented on standard forms • Comment forms are the basis of tracking what and why changes were made • Comments are logged into APTA system • Resolution of comments are proposed • TWG approves proposed resolution • Changes are incorporated in subsequent releases of the standard