Contactless Fare Media System Standard Part 2: Contactless Fare Media Data Format and Interface Stan

1
Contactless Fare Media System StandardPart 2
Contactless Fare Media Data Format and Interface
Standard

• Tomas Oliva

Using Standards to Make Smart Choices Talking
Technology and Transportation (T3) May 17, 2006
2
UTFS Elements of Standardization
PART 3 Regional Central System Interface
Specification
PART 4 System Security Planning and
Implementation Guideline
PART 2 Contactless Fare Media Data Format and
Interface Standard
3
General Scope of the Part 2 Standard

• Applies to contactless card-based fare collection
  systems
• Requires a Proximity Integrated Circuit Card
  (PICC) with a Card Operating System, compliant
  with ISO/IEC144432-4, with a minimum of 2KB of
  useable memory
• Provides a specification for components of the
  data architecture to be used on the card
• Uses existing standards and common practices
  where possible

4
General Purpose of the Part 2 Standard

• Define a common set of data objects that enable
  compliant PICCs and Card Interface Devices (CID)
  to be used interchangeably with each other within
  a system
• Enable multiple transit agencies within a region
  to accept each others fare media
• Provide a set of data objects and associated
  software logic that, once developed, can be
  applied to other projects/systems

5
Objectives of the Part 2 Standard

• Accommodate most known fare products and related
  services currently used in the US
• Base card data components on open standards to
  enable open sourcing from multiple vendors
• Ensure that new interface device technologies can
  be adopted within the core application
  infrastructure

6
Advantages of Adoption

• Interoperability
• Transit agencies can accept other agencies smart
  cards.
• Agency systems can be procured at different
  times.
• Reduced Cost
• Reduced need for customization and
• re-engineering.
• Transit agencies can purchase equipment from
  multiple vendors (competitive procurement).
• Potential to share costs through common
  operations.

7
Use of the Part 2 Standard

• The Standard is not sufficient to build a
  functioning system or to achieve
  interoperability for example, agencies must also
  define
• PICC file structure (Standard provides an example
  only)
• PICC data definition mapping (need to make
  choices)
• List of fare products that will be accepted and
  processed by the system
• Security is outside the scope of the Standard,
  although the data architecture does provide for
  the implementation of security schemes.

8
Mechanism for Adoption Use

• Achieve consensus for UTFS adoption among
  participating agencies.
• Define business rules for regional program
  participation (including ownership, governance,
  regional fare products, fee and revenue sharing).
• Identify distinct messages and implementation
  approach to be used within the region.

9
Key Terms in the Standards

• Following from ISO standards
• PICC Proximity Integrated Circuit Card
• PCD Proximity Coupling Device
• CID Card Interface Device

10
Card-Reader Transaction Overview
11
General Description

• The basic data architecture is built on a set of
  objects made up of a defined set of elements.
• Each core object is 16 bytes in length.
• Standard makes provisions for additional data
  through extensions to the core objects, which are
  also no longer that 16 bytes.

12
Object Definition Format

• Objects are defined in a consistent format to
  assist in interpretation.
• Each object is specified in its own section of
  the standard.
• Object specification
• Includes a summary explanation of the objects
  function, and a table listing the elements that
  are part of the object, along with heir size,
  potential values, position, and a description.
• Concludes with a users information subsection
  that provides additional details about the
  elements that are part of the object.

13
Core Objects
14
Directory Index Object (DIO)

• Contains pointers that identify the location
  (file) in which most other data objects are
  stored
• For each file, provides
• ID of the file
• Size of the file
• Type of file
• Ownership (if applicable) of the file
• A card normally contains only one DIO
• Enables AFC system to quickly locate other data
  objects, while enabling the contents of data
  files to be flexible and dynamic

15
Transit Application Profile Object (TAPO)

• The TAPO is a required core object that
  identifies the PICCs origin, issuer, and general
  capabilities/limitations required by the transit
  application.
• The TAPO is encoded or configured at the PICC
  pre-issuance stage or the PICC initialization
  stage.
• The PICC contains only one TAPO.
• Sample elements Country ID, Region ID, Issuer
  ID, Transit application expiry date, PICC
  Manufacturer ID, Issuing CID ID

16
PICC Holder Profile Objects (PHPO)

• The PHPO identifies the transit patrons profile
  relative to their personal preferences for
  transit fare products and services
• The PICC contains only one PHPO.
• An optional PHPO extension must be utilized for
  secret or private profile protection.
• Sample elements Fare class code, birth date of
  patron, language preference, start and end of
  profile, and associated discount

17
Add/Deduct Value History Objects (ADVO)

• The ADVO will record up to eight of the most
  recent add or Autoload (Unload) value
  transactions from the T-purse and/or stored value
  products.
• The ADVO is an optional object, although if
  used, at least 2 are required.
• Sample elements Payment type (cash, credit,
  recurring load, etc.), transaction date and time,
  value added or deducted, location where
  transaction took place.

18
Transaction History Objects (THO)

• The THO contains up to 16 of the most recent
  transactions, after which the oldest transaction
  is overwritten.
• Allows for up to 16 transaction types to be
  defined.
• The THO is a required core object.
• Sample elements Fare product used, agency where
  PICC was used, is the transaction linked to the
  previous transaction (i.e. transfer rules),
  transaction value.

19
Transaction Types

• 0 Reserved
• 1 Load
• 2 Product Blocked
• 3 Product Un-Blocked
• 4 Validation or Deduction
• 5 Validation or Deduction Date and Time
  Override
• 6 Reserved
• 7 Configuration Change

• 8 Previous Transaction Undone
• 9 Reserved
• 10 Reserved
• 11 Negative List Status Change
• 12 Unload
• 13 Reserved
• 14 Reserved
• 15 Out of Region T-Purse Use

20
Product Index Object (PIO)

• A mandatory index of the transit fare products
  (defined by Product Objects) on a specific PICC
  application.
• Provides summary details of the transit fare
  products currently stored on the PICC.
• Enables AFC system to quickly identify products
  that might be applied to the current fare
  payment.
• PICC contains only one PIO and one PIO extension
  but can have two additional extensions, if
  required.
• Sample elements PICC transaction sequence
  number (maximum of 127 transactions are tracked),
  fare product used in last transaction, product
  type codes.

21
Available Product Objects

• The Standard accommodates any fare products that
  are time-, prepaid ride/trip-, value-, or
  reward-based, and those with linked (e.g.
  bankcard) accounts.
• A given fare product is represented by a single
  Product Object with or without object extensions.
  
• There are 256 distinct Product Types available to
  each Agency (253 pass types, one stored value,
  one account linked and one AutoValue-based
  product).
• Each Agency defines the Fare Product Type Codes,
  and the rules for use of those products.

22
Pass and Transfer Product Objects (PTPO)

• Contains the required information or
  functionality and data representing either a pass
  or transfer product.
• PTPO is a core object required by the standard.
• Sample elements Whether the user has subscribed
  to Autoload, pass or transfer expiry date and
  time, number of remaining trips or rides, where
  the product is valid (i.e., specific zone)

23
Stored Value and T-Purse Product Objects (SVTPPO)

• Stored value objects are agency-specific.
• The T-Purse is the regional stored value fare
  product, usually stored in local currency (US).
• When the PICC is initialized, SVTPPO are usually
  set at 0.
• Autoload feature can be enabled.
• There can only be one instance of a T-Purse on a
  PICC.
• Sample elements Frequency of autoload, autoload
  threshold (trigger), autoload amount

24
Account Linked Product Object (ALPO)

• Used to define a fare product that is tied
  (linked) to a host-based account, such as a
  credit or debit card
• Acts like a T-Purse product, except does not
  require pre-funding
• There can be only one instance of an Account
  Linked product on a PICC
• Sample elements Accumulated value used in a
  particular day, definition of time period for
  which a transaction limit applies, time period
  start, number of transactions performed during
  time limit.

25
Account Linked Reference Object (ALRO)

• The ALRO is an object containing the Account
  Linked Product reference information (e.g.,
  bankcard number) that requires secure access.
• The ALRO object must occupy a dedicated file on
  the PICC with a separate security write key.
• Sample elements Daily limit of payments that can
  be performed on account, bankcard information
  from which payment is made, bankcard expiry date.

26
Autovalue Product Object (APO)

• Implemented when an agency or regional operator
  wants to provide incentives (rewards) for
  frequent use or bulk fare purchases.
• Sample elements Type of autovalue product,
  accumulation of value units today, accumulation
  of value units this week, last week, 2 weeks ago,
  and 3 weeks ago.

27
Evolution of the Standard

• Add provision for use of PICC products that dont
  meet all of the requirements (Limited Use PICCs)
• Develop an Implementation Guide
• Develop Certification and Testing requirements

28
Review Points

• Comprehensive description of objects and their
  elements accommodating a broad range of fare
  collection related transactions.
• Users have significant flexibility in selecting
  how to use the objects.
• While the Standard does provide PICC
  specifications, the focus is on data formats and
  a standardized communication protocol with the
  CID. This opens up future possibilities for the
  implementation of other electronic form factors
  such as key fobs, mobile telephones fitted with
  contactless chips, etc.

29
More Information

• Martin Schroeder, P.E., APTA
• mschroeder_at_apta.com
• 202-496-4885