TCIP TWG Kickoff Meetings

1

TCIP TWG Kickoff Meetings

Fare Collection TWG

December 8, 2003

2

Welcome & IntroductionsWelcome & Introductions

Lou SandersLou SandersAPTAAPTA

Henry Rosen / Chung-Chung TamHenry Rosen / Chung-Chung TamFare Collection TWG Co-ChairsFare Collection TWG Co-Chairs

3

Agenda

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

4

TCIP Task Force StructureTCIP Task Force Structure

John FayosJohn FayosCritical LinkCritical 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

• Program Manager– 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 ForceBUS & PARATRANSIT

CEOs COMMITTEE

TCIP TASK FORCE TCIP

CONTRACTORS

PROGRAM MANAGER

TCIPOVERSIGHT

PANEL

TWG CHAIRS COMMITTEE

TWG 2:PASSENGER

INFORMATION

TWG 3:INCIDENT

MANAGEMENT

TWG 4:SW TOOLS

& TEST

TWG 5:ON-BOARD

TWG 1:SCHEDULING/RUNCUTTING

TWG 7:FARE

COLLECTION

TWG 8SPATIAL

REPRSENTATION

TWG 9:FRAMEWORK &PRIORITIZATION

TWG 10:SIGNAL CONTR &PRIORITIZATION

TWG 6:CONTROLCENTER

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 PlansTCIP Status & Review Plans

John FayosJohn FayosCritical LinkCritical 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 ProcessPhase 1: Initial Document Production

Contractors Develop Draft

Standards (v2.4)

Distribute Draft Standards to

TWGs

TWGs Review, Comments, & Recommenda-

tions

Contractor Resolve

Comments and Revise Draft

NTP Authorization

TCIP Oversight

Panel Authorization

Phase 2: Intermediate Review and Approval

Contractor Resolve

Comments and Revise Draft

TWGs Review and Comment

Corrected Draft/Spatial

Business Area to TWGs (v2.5)

TWGs Review and

Approval

Task Force Approval For

Public Posting (v2.6)

Phase 3: Public Review & Comment

NTCIP Joint Committee /

Public Review & Comment

Resolve Comments and Prepare Final

Draft

Phase 4: Final Review and Approval

Distribute Final Draft Standard

to TWGs

TWGs Final Draft Balloting

(v2.7)

Contractor Incorporate

Modifications

Release Authorization

Release Standards

(v3.0)

TCIP Oversight Panel Approval

for Release

15

TCIP 2.4 Review Schedule

• Fare Collection TWG Kickoff Meeting– Dec 8, 1:00-2:30 PM EST

• 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

TCIPTCIP 2.x 2.xRob AyersRob Ayers

ARINCARINC

19

Discussion Topics

• What TCIP 2.x containsWhat TCIP 2.x contains– Incorporates TCIP 1Incorporates TCIP 1– Addition of Data FramesAddition of Data Frames– Concept of OperationsConcept of Operations– DialogsDialogs– XMLXML

20

Building the New Standard

TCIP 2.X DialogsTCIP 2.X Dialogs

Dialog PatternsDialog Patterns MessagesMessages

Data FramesData FramesNew FramesNew Frames TCIP 1 MsgsTCIP 1 Msgs

Data ElementsData ElementsNew ElementsNew Elements TCIP 1 ElementsTCIP 1 Elements

21

New TCIP StandardNew TCIP Standard

• TCIP 3.0TCIP 3.0• Plan to publish a new TCIP standard that incorporates the prior work, as Plan to publish a new TCIP standard that incorporates the prior work, as

well as XML Schema, and Dialogswell as XML Schema, and Dialogs• Single Standard instead of 9 documentsSingle Standard instead of 9 documents

22

TCIP 2.X Standard Outline

• OverviewOverview• DefinitionsDefinitions• ConformanceConformance• Understanding TCIPUnderstanding TCIP• Concept of Operations (For each Business Area)Concept of Operations (For each Business Area)• Dialogs (Meaning of Patterns, Instantiations, Batch)Dialogs (Meaning of Patterns, Instantiations, Batch)• Dialog Patterns (Patterns are specified here)Dialog Patterns (Patterns are specified here)

23

TCIP 2.X Standard Outline (continued)

• Annex A-Data Elements(By Business Area)Annex A-Data Elements(By Business Area)• Annex B-Data Frames (By Business Area)Annex B-Data Frames (By Business Area)• Annex C-Messages (By Business Area)Annex C-Messages (By Business Area)• Annex D-Dialogs (By Business Area)Annex D-Dialogs (By Business Area)• Annex E-XML SchemaAnnex E-XML Schema• Annex F-Sample RFP WordingAnnex F-Sample RFP Wording• Annex G-Traceability MatrixAnnex G-Traceability Matrix

24

What is a Dialog?

• A dialog specifies how and when a group of messages are used.A dialog specifies how and when a group of messages are used.• Dialogs are based on patterns. A pattern specifies a particular type of Dialogs are based on patterns. A pattern specifies a particular type of

transaction which can then be used to implement many dialogs.transaction which can then be used to implement many dialogs.• Patterns and Dialogs provide the context information necessary to Patterns and Dialogs provide the context information necessary to

effectively use TCIP messages.effectively use TCIP messages.

25

Pattern Example - Query

Client Server

AaaXxxSub

AaaXxx

CptSubErrorNotice

Normal Execution of Query Error Response to Query

Calculation

CompleteComplete

Client Server

AaaXxxSub

Calculation

CompleteComplete

26

Pattern Example-Periodic

Subscription Expires

Client Server

AaaXxxSub

AaaXxx

Normal Execution

Calculation

CompleteComplete

Timeout

Timeout

Timeout

AaaXxx

AaaXxxAaaXxx

27

Dialog Components

•NameName•PatternPattern•Business AreaBusiness Area•PurposePurpose•NarrativeNarrative•Sequence DiagramSequence Diagram•AssumptionsAssumptions•NotesNotes•Message IdentificationMessage Identification

28

eXtended Markup Language (XML)

• TCIP I Standards are written in ASN.1TCIP I Standards are written in ASN.1• TCIP 2.X uses XML as the implementation language, & include XML TCIP 2.X uses XML as the implementation language, & include XML

Schemas with the new Standards.Schemas with the new Standards.• Advantages: Better known, more tools, more rapid supplier acceptance, Advantages: Better known, more tools, more rapid supplier acceptance,

take advantage of ubiquity of web-based productstake advantage of ubiquity of web-based products

29

Data Element Example

Name CPT-SubscriptionTypeIdentifier cptdd 100Purpose 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, or all existing subscriptions.

UsageDefinition ENUMERATED{ Query (1), Periodic (2), Event (3), Cancel (99), CancelAll (100), -- 4-98 reserved-- 101-255 reserved

} (0..255)

30

Data Element XML SchemaXML-TAG CPT-SubscriptionType

XML-SCHEMA<xsd:simpleType name="CPT-SubscriptionType" >

<xsd:annotation> <xsd:appinfo> Query (1) Periodic (2) Event (3) Cancel (99) CancelAll (100) -- 4-98 reserved -- 101-255 reserved </xsd:appinfo> <xsd:documentation> </xsd:documentation> </xsd:annotation> <xsd:union> <xsd:simpleType> <xsd:restriction base="xsd:unsignedInt"> <xsd:minInclusive value="0"/> <xsd:maxInclusive value="255"/> </xsd:restriction> </xsd:simpleType> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xs:enumeration value="Query"/> <xs:enumeration value="Periodic"/> <xs:enumeration value="Event"/> <xs:enumeration value="Cancel"/> <xs:enumeration value="CancelAll"/> </xsd:restriction> </xsd:simpleType > </xsd:union></xsd:simpleType>

31

Data Frame Example

Name CptSubscriptionHeader

Identifier cpt 1000

Purpose Provide a standardized header structure for subscription requests, cancellations, and responses.

Usage The expiration date and time must be specified.

Report Interval is required if the requestedType 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. Subscriber and host identifiers are agency-assigned unique numbers to identify systems/applications.

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.

Definition SEQUENCE {requestedType CPT-SubscriptionType,expirationDate CPT-DeactivationDate,expirationTime CPT-DeactivationTime,reportInterval CPT-TimeInterval OPTIONAL,requestIdentifier CPT-RequestIdentifier,subscriberIdentifier CPT-ApplicationID,hostIdentifier CPT-ApplicationID }

32

Data Frame Example XMLXML-TAG CptSubscriptionHeaderXML-SCHEMA

<xsd:complexType name="CptSubscriptionHeader" > <xsd:annotation> <xsd:documentation> </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="requestedType" type="CPT-SubscriptionType" > </xsd:element> <xsd:element name="expirationDate" type="CPT-DeactivationDate" > </xsd:element> <xsd:element name="expirationTime" type="CPT-DeactivationTime" > </xsd:element> <xsd:element name="reportInterval" type="CPT-TimeInterval"minOccurs="0"> </xsd:element> <xsd:element name="requestIdentifier" type="CPT-RequestIdentifier" > </xsd:element> <xsd:element name="subscriberIdentifier" type="CPT-ApplicationID" > </xsd:element> <xsd:element name="hostIdentifier" type="CPT-ApplicationID" > </xsd:element> </xsd:sequence></xsd:complexType>

33

Message ExampleName CptStoppointListSub

Identifier cpt 2001

Purpose Request a specified version of stoppoint information

Usage Subscription type should be query. If the information changes, then a new version number should be created by the scheduling system or schedule repository (server). The subscriber can become aware of such updates using the Subscribe Master Schedule Version dialog.

The subscriber is able to determine the appropriate version of the stoppoints to request using the Subscribe Master Schedule Version dialog, thus the query does not need to be qualified with dates or other information.

The include-details field indicates whether the response message should include additional details in the response message. These details provide optional information about a stoppoint (such as whether it is ADA-accessible). This detail is not required for all applications using the stop point list.

An agency may decide to include all stoppoints for the agency within a stop point version, or to limit aversion to the stoppoints included on a route or group of routes, however all stoppoints referenced in a pattern list (SchPatternList message) must be included in the version of the stoppoints referenced by that pattern list.

Definition SEQUENCE {subscriptionInfo CptSubscriptionHeader,stoppointVersion CPT-StoppointVersion,include-details CPT-Boolean}

34

Message XML Schema

XML-TAG CptStoppointListSub

XML-SCHEMA <xsd:complexType name="CptStoppointListSub" > <xsd:annotation> <xsd:documentation> </xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="subscriptionInfo" type="CptSubscriptionHeader" > </xsd:element> <xsd:element name="stoppointVersion" type="CPT-StoppointVersion" > </xsd:element> <xsd:element name="include-details" type="CPT-Boolean" > </xsd:element> </xsd:sequence></xsd:complexType>

35

Populated Message Example

=======================XML Message===================<SCH-MasterScheduleVersionSub> <subscriptionInfo> <requestedType>1</requestedType> <expirationDate>20091225</expirationDate> <expirationTime>0</expirationTime> <requestIdentifier>88</requestIdentifier> </subscriptionInfo> <beginDate>20020121</beginDate> <endDate>20020121</endDate> <routes> <SCH-RouteID>1</SCH-RouteID> <SCH-RouteID>5</SCH-RouteID> </routes></SCH-MasterScheduleVersionSub>

36

TCIP 2.X Standard Summary

• Concept of OperationsConcept of Operations– each business areaeach business area

• TraceabilityTraceability• Incorporates TCIP 1 data elements and messagesIncorporates TCIP 1 data elements and messages• Addition of dialogsAddition of dialogs• Conformance StrategyConformance Strategy• TCIP usage in RFP’sTCIP usage in RFP’s

37

TCIPTCIP FC FCRob AyersRob Ayers

ARINCARINC

38

What FC Contains

• 5.9 Fare Collection5.9 Fare Collection

• 5.9.1 Upload Fare Related Operating Data5.9.1 Upload Fare Related Operating Data

• 5.9.2 Download Fare Related History Data5.9.2 Download Fare Related History Data

• 5.9.3 Report Onboard Fare Equipment Health Events5.9.3 Report Onboard Fare Equipment Health Events

• 5.9.4 Report Passenger Count to Onboard Systems5.9.4 Report Passenger Count to Onboard Systems

• 5.9.5 Other Dialogs5.9.5 Other Dialogs

• Version relied on PA NY/NJ RIS (e.g. how many bits define a smartcard)Version relied on PA NY/NJ RIS (e.g. how many bits define a smartcard)

• APTA UTFS is responsible for definition of electronic fare media and transactions. TCIP APTA UTFS is responsible for definition of electronic fare media and transactions. TCIP to coordinate with those efforts.to coordinate with those efforts.

39

FC Dialogs

CCoonncceepptt ooff OOppeerraattiioonnss DDiiaallooggss BBuussiinneessssAArreeaa

55..99..11 UUppllooaadd FFaarreeRReellaatteedd OOppeerraattiinngg DDaattaa

UUppllooaadd FFaarree CCoolllleeccttiioonn DDaattaa FFCC

55..99..22 DDoowwnnllooaadd FFaarreeRReellaatteedd HHiissttoorryy DDaattaa

DDoowwnnllooaadd FFaarree CCoolllleeccttiioonn DDaattaa FFCC

55..99..33 RReeppoorrtt OOnnbbooaarrddFFaarree EEqquuiippmmeenntt HHeeaalltthhEEvveennttss

SSuubbssccrriibbee FFaarree CCoolllleeccttiioonn HHeeaalltthh FFCC

55..99..44 RReeppoorrtt PPaasssseennggeerrCCoouunntt ttoo OOnnbbooaarrddSSyysstteemmss

SSuubbssccrriibbee OOnnbbooaarrdd PPaasssseennggeerr CCoouunntt FFCC

40

FC Questions

41

TCIP WebsiteTCIP Website

Diane O’NeillDiane O’NeillARINCARINC

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