WP-1 Report/Minutes
for April 02, 2004 Conference Call
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.
Return to
Systems Work Groups
Some of these pages may include links to documents in the Adobe PDF format. Please download the Adobe PDF reader if you have not already done so.
