Attendance:
Walt Bonneau | 3PCI/PANYNJ |
Barney Louie* | BART |
Bob Murray | BART |
Henk Dannenberg | Philips |
Levent Eyuboglu* | LACMTA |
Karim Aboud* | CTA |
Darshana Patel* | CTA |
David Faust | CTA |
Brian Monk | Cubic |
Diane Battilana | ERG |
Cynthia Chin-Pack * | LACMTA (Observer) |
Alexander Pi | Scheidt-Bachmann |
Christian Flurscheim* | ERG (Sub) |
Mauro Arteaga | LACMTA |
Etienne Lamairesse | ASK |
Following were absent members and observers:
Al Chan* | Booz-Allen Hamilton |
Mike Meringer | OTI |
Chung-Chung Tam | CTA (Observer) |
Rick Sterns | Booz-Allen Hamilton |
Kevin Krest | G&D |
Tim Weisenberger | Volpe |
Geraud Najman | Thales (Visitor) |
* Subs- attended
Member addition & removal: Geraud Najman (Thales) issued a written requested to become part to WP-1. We want to welcome him to WP-1. Geraud is located in France.
I have included his email address within the WP-1 broadcast list.
Meeting Conducted time and location:
The meeting was conducted from 11:00m until 12:10PM Eastern Time
1.) Location of next WP-1 "Face-to-Face" Meeting: It was agreed that the next meeting would be hosted by the LACMTA in Los Angles, CA.. The date is set for May 11th with a starting time of 8:30am. The meeting will conclude at 5:30pm. WP-4 is planning to have their meeting on May 12th. Both Cynthia Chin-Pack and Mauro Arteaga will our point of contact from LACMTA.
2.) Agency Numbering Scheme (Still open):
It was noted that additional review would be needed before a reasonable solution would be offered to the WP-1 for discussion and approval. Below is one potential option offered by BAH:
At the last face-to-face, I took an action item regarding the numbering scheme for agencies participating in smart card programs, specifically to check on the National Transit Database. Following is a link to the data tables for 2001.
http://www.ntdprogram.com/NTD/NTDData.nsf/DataTableInformation?OpenForm&2001
FTA has assigned each agency a unique identifier, as explained in the Introduction document. Within each identifier, the first digit is the FTA region, then a 3-digit organization number, then a letter.
3.) Results of the April 02 conference call:
- Resolution "Item "E": was discussed briefly. There is still disagreement as to the technical approach offered by Cubic and that of using a separate Transfer Product object. Cubic offered to submit a more detailed explanation of using the THO and Transfer Code method. Scheidt-Bachmann will issue a detailed explanation of how a separate Transfer Product Object would work. During the next call we will conclude on the approach(s) to prove extended documentation in support of our final approach.
Below are the original notes from the March 25th meeting for record only!
- The issue was defined as: If a Pass product was used where two transfers are issued and one transfer is used but a separate transaction occurs in between the transfers how does the last transfer get associated with the original product that created the transfers?
There would be a transfer issued with the use of a Pass Product where:
Index P1 | P2 | P3 |
Start Time/Issued 13:00 | Time 13:00 | Time 14:00 |
Time Now 13:00 | Time 2:00 | Time 14:30 |
Transfer Code written in THO | i.e 25 | i.e 37 |
Rts Prod ID is written in THO | | |
- Table 2-05A below was discussed with the following results stated in Yellow highlights. All other data element remains the same.
"Updated" Table 2-05A Product Index Object [PIO] – Core
Field | Size | Values | Pos. | Description |
| | | | |
| | | | |
RtsActionMap | 8 | 0-127 | 24-31 | A map of sequential bits containing 1’s and 0’s that may be read to achieve status of previous Autoload events. (E.g. if the posted RtsAutoloadEventID is set at 20 and the sequential bit map contains 8 bits of which bit 2 is set to a zero. This would imply that Autoload event posted (20) minus 2 or 18 had not been retrieved) |
RtsActionEventID | 6 | 0-63 | 32-37 | This field represents the system generated Autoload Event Identifier for the most recently Autoload of this PICC. It is recorded here to prevent devices performing duplicate loads of the same product from different station or on-board devices. Note: Pending Autoload event list that are resident in the CID should be disabled is no central or backend computer activity has occurred within 72 hours. |
RtsTransAppStatus | 2 | 0-1 | 38-39 | The value of this field represents the Negative List status of the Transit Application: 0 = PICC Transit Application is active 1 = PICC Transit Application is negative-listed, blocked and inactive and cannot be reactivated 2 = FF, PICC Transit Application is negative-listed, blocked and inactive but can be reactivated 3 = Reserved |
RtsTPurse&SVUse This Data Element remains after extensive discussion but if these bits are needed for a more important function in the future this data element may be removed. | 2 | | 40-41 | Indicates the use of an Agency specific Stored Value Purse and/or the T Purse: 0=Reserved 1=An SV Purse was used 2=The T Purse was used 3=An SV Purse & the T Purse were used Note: If an agency specific purse was used then the Agency ID is that indicated by the last Transaction History Log entry |
Total | | | | |
ERG has agreed to review the following modified Table-07 submitted by Cubic to address the RtsCIDTransactionNumber data element that was added at the expense of other data element bit reductions as requested by ERG. In addition, modifications were made to some of the text to account for these changes.
Modified Table 2-07 Pass and Transfer Product Objects
Field | Size | Values | Pos. | Description |
RtsPassVersion | 2 | 0–3 | 0-1 | Data Format Version for the Pass Product Objects: 0 = version 0 1 = version 1 2 = version 2 3 = Version 3 Each Product Object contains this field so that an update to the formats does not require a complete PICC re-write in a single transaction |
RtsExtensionStatus | 1 | 0-1 | 2 | 0 = No Product Object Extension 1 = Product Object Extension required |
RtsAutoloadSubscribed | 1 | 0–3 | 3 | Autoload Setting where 0=Not subscribed 1=Subscribed [Threshold] |
RtsPaymentType | 2 | 0–3 | 4-5 | Payment Type Code. Indicates the manner in which revenue was originally collected for the purchase of the Product: 0=Cash or T Purse [Refundable] 1=Credit/Debit or SV Purse [Non-refundable?] 2=Directed Autoload 3=Subscribed Autoload |
RtsRenewedInAdvance) | 1 | 0-1 | 6 | Indicates that this Product has been renewed in advance of its existing expiry Date 0=Not renewed in advance 1=Renewed in advance The actual renewal invocation will only take place after the existing product has expired. The renewal will invoke a new product written with a new expiry date/time |
RtsLocationEncodingType | 1 | 0–1 | 7 | Describes the type of location validity encoding depicted by RtsLocationEncoding Field. E.g. 0=Agency’s encoding format version 0 [Sector/Route/Sector Coding] 1=Agency’s encoding format version 1 [Point to Point Coding] |
RtsExpDate | 16 | Date () | 8-23 | Expiry date for the Product where: Bits Denotation 0 – 4 day (1–31) 5 – 8 month (1–12) 9 – 15 year (0–99) Validity start date can be calculated from RtsExpDate & the number of days of validity indicated by RtsProdID. If ‘RtsProdID’ indicates an Open Dated [Rolling Period] Pass Product, then RtsExpDate is initially encoded with an expiry date that is further in the future than Purchase Date plus the Product Validity Period’. Open Dated Passes normally don’t last forever & are set to expire at a date related to the purchase date. Therefore, the actual encoded expiry date for open dated passes will normally be within one month to a year from product purchase date, depending on Product ID. The Open Dated Product’s RtsExpDate is re-encoded, to match the Start [first use] Date & the validity period, on its invocation at a Gate or Validator |
RtsExpTime | 11 | 0-1439 | 24-34 | Time this product expires. Time in minutes past midnight. |
RtsRemTrips/Rides [NA to Transfers] | 5 | 0-31 | 35-39 | Number of remaining transit Trips/Rides for the current product. Does not include any trips associated with a renewal in advance |
RtsUseSequenceNumber | 8 | 0-255 | 40-47 | Identifies the product’s ‘use sequence number’ if required |
RtsProdID | 8 | 0-255 | 48-55 | The Regional Administrator & the participating transit agencies within the region define the Pass Product ID codes. The applicable code is posted to the PICC when it is autoloaded or when the customer buys the pass product at a vending machine, ticket booth, or other device. There are up to 255 possible pass product codes for each Agency & up to 255 for regional pass products. Once selected, these codes are normally fixed and permanent for the duration of the product’s validity. A product ID code cannot be changed until all ‘on card products’ of that ID have expired. The RtsProdID code, together with other data elements such as RtsExpDate & RtsExpTime are captured, by the fare gate CID, and used in Transaction Records for accounting, demographic reporting, and other downstream fare collection system processing. For example only: (New York City Transit (NYCT) Metro PICC) 0 = Reserved [T Purse/SV] 1 = 2 Ride Pass 2 = Weekly Off peak Pass 3 = Rolling monthly unlimited pass 4 = Rolling monthly Transit Center pass 5 = 3-day unlimited tourist pass 6 – 255 = additional products for NYCT |
RtsLocationEncoding | 32 | | 56-87 | Indicates the location validity of the Pass Product within the Region. Examples: Sector/Route/Sector Encoding Bits Denotation 0 – 10 Valid Sector a 11 – 21 Valid Sector b 22 – 31 Valid Route Number connecting Sectors a & b Point to Point Encoding: Bits Denotation 0 – 15 Point a = RtsLocationID a [0-65,535] 16 – 31 Point b = RtsLocationID b [0-65,535] |
RtsCIDTransactionNumber | 8 | 0-255 | 88-95 | This field represents the LSB of the Sequential Event Identifier assigned by the Device’s CID |
RtsCIDID | 16 | 0–65535 | 96-111 | CID ID. Unique Identify [within the Region] of the Device’s CID |
Data Authentication Code [DAC] or Cyclic Redundancy Check (CRC) | 16 | 0-65,535 | 112-127 | DAC for ‘product owner’ load & use authentication Or CRC for data error detection only |
Add RtsActionSequenceNumber This requested data element will be removed unless ERG demonstrates a valid reason to have it considered by the next conference call. There is not other room(bits) in the PO to accommodate this request at present! | There doesn’t seem to be any support for directed loads via actionists? Probably need discussion on Autoloads in general ERG has suggested that this Data Element is needed to "Keep track of the Action List activity" ERG will issue a Action List as a item of inclusion. |
5.) Next Conference Call subjects to be discussed and resolved:
(April 9, 2004 @ 11:00am ET)
Discuss and finalize the following items:
- Product Object (Pass and Transfers): Finalization of this Object!
- Start the Stored Value & T-Purse Object (See attached Table2-08)
Table 2-08 Stored Value (SV) & T-Purse Product Objects
Field | Size | Values | Pos. | Description |
RtsValueVersionID | 2 | 0–3 | 0-1 | Data Format Version for the Value Object: 0 = version 0 1 = version 1 2 = version 2 3 = Version 3 Each Value Object Record contains this field so that an update to the formats does not require a complete PICC re-write in a single transaction |
RtsExtensionStatus | 1 | 0-1 | 2 | 0 = No Transaction Object Extension 1 = Transaction Object Extension required |
RtsAutoSubscribe | 2 | 0–3 | 3-4 | This field represents the Autoload subscription indicator for this load: 0 = Reserved 1 = Threshold 2 = Recurring 3 = Recurring & Threshold |
RFU | 1 | 0-1 | 5 | |
RtsValueExpires | 1 | 0 = Normal 1 = Expires | 6 | Expiry indicator. Indicates that this is a Single Load SV product that expires on date indicated by RtsExpRecurDate |
RtsRemValueSign | 1 | 0-1 | 7 | Value designates a positive or negative balance. 0 = Positive 1 = Negative |
RtsRemValue | 16 | 0-65,535 | 8-23 | Remaining currency value. |
RtsExpRecurDate | 16 | Date () | 24-39 | Date that this product expires or Last Recurring Load Date. Format ddmmyy 0-4 = day (1-31) 5-8 = month (1-12) 9-15 = year (0-99) 0 = Not Applicable |
RtsRecurringAutoloadType | 4 | 0 – 15 | 40-43 | Used to differentiate SV Recurring Autoload types 0 = Reserved 1 = Weekly 2 = Monthly 3-15 Reserved |
RtsAutoloadThreshold | 4 | 0-15 | 44-47 | Autoload threshold is when the T-Purse will be Threshold-loaded and a funds charge transaction will be sent to the customer’s bank. 0 = reserved for future use 1 = balance is equal to or less than zero down to but not less than the PICC deposit value (default, permanent standard) 2 = balance is less than $5.00 3–15 = reserved for future use |
RtsSVThreshholdLoadAmount | 15 | 0 – 32,767 | 48-62 | Value to Add for a Threshold Autoload |
RFU | 1 | | 63 | |
RtsSVRecuringLoadAmount | 15 | 0 – 32,767 | 64-78 | Value to Add for a Recurring Autoload |
RFU | 1 | | 79 | |
RtsCurrencyCode | 4 | 0-15 | 80-83 | Currency of the value of this Product. The currency code is considered fixed and permanent* where indicated and consistent for all regions that recognize and adhere to this transit smart PICC Regional Interoperability Standard. The fare collection system conforming to these specifications will recognize the defined currency and deduct the equivalent of that currency from the T-purse. Codes are: 0 = Reserved for future use 1 = US Dollar (default, permanent standard)* 2 = Canadian Dollar (permanent standard)* 3 = Euro (permanent standard)* 4 = Pound Sterling (proposed)* 5 = Japanese Yen (proposed)* 6 = Hong Kong Dollar (proposed)* 7 = Mexican Pesos (proposed)* 8 - 15 reserved for future use |
RFU | 4 | 0 | 84-87 | Reserved for future use |
RtsCIDTransactionNumber | 8 | 0-255 | 88-95 | This field represents the LSB of Event Identifier assigned by the issuing machine’s CID |
RtsCIDID | 16 | 0–65535 | 96-111 | Issuing Machine CID ID. Used to identify the Encoding equipment. |
Data Authentication Code [DAC] or Cyclic Redundancy Check (CRC) | 16 | 0-65,535 | 112-127 | DAC for authentication & error detection Or CRC for error detection only |
Total | | | | |
end
"
Alternative dDistance -bBased Fare"Zone Check definition:
Distance Based Fare is a product that charges on the basis of distance traveled. This may be related to mileage, specific locations (stops or stations), or fare zones (covering zone checks). Zone checks A record shall be made that allows a distance-based fare to be calculated. The entry record shall contain the location of origin and other information required by business rules. For charging the distanced-base fare, there are three methods:
In a closed or dual tag system (tag required at entry and exit)
should beare defined, as a dual tag system, or closed system, where a tag is required at entry and exit. and in some cases can be fully a closed system. There are three two methods::
Closed System (requiring tag at entry and exit)
1) Mmaximum or appropriate fare for the trip charged on entry and rebate, (if any is due,) on exit.; (Note: patron does not have to tag out, but will not receive a possible rebate if he does not.)
2) MinimumTtoken fare charged on entry and remaining fare charged on exit.
based on entry token,. (Wwhere the entry token contains the station of origin and other information required by business rules.); Proof of payment check definition:In an Oopen or Mixed Systemsingle tag system (which may be proof of payment or driver-enforced):
3):, t The appropriate fare for the trip is paid on entry and the card may later be checked, (using any an appropriate reading device such as handheld, farebox, etc.,) to assure that the correct fare has been paid based on the trip taken. If not, additional fare, fine or surcharge is or fine charged or citation issued per the tariffbusiness rules. (Data on card must reflect entry location or zone and amount paid.) A proof of payment check is not considered a second tag.
"Fare Enforcement Check"
A Fare Enforcement Check is the process of reading the card to determine that the passenger has paid the correct fare for the trip. This may be a flat fare or a distance-based fare. It most commonly occurs in an open or Proof of Payment environment, but may also occur in a closed (dual tag) system. Depending on business rules, any or all of the following may occur:
A record may be made on the card of the fare enforcement check.
Additional data on the card, such as cardholder profile, remaining value, etc., may be read
Remaining fare due may be charged
Fare enforcement personnel may "turn off" the card
A citation or warning may be issued (typically this is a manual process or done with a handheld printer, and it does not involve the patron’s card)
A fine or surcharge may be deducted from the t-purse.