Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 87
CHAPTER 8
Conclusions
The best approach to take when determining the management and organization for a
smartcard-based AFC environment will be determined by the existing capabilities of the region.
If the region has an agency of good size with a significant level of experience in large-volume
smartcard-based fare collection operations, then logically that agency should become the lead
agency in developing a fare collection approach for the region. If an existing governing body pre-
sides over the transit agencies in the region and has a strong engineering support staff, then log-
ically that governing body should lead the regional fare collection effort. If neither of these
previous conditions exists, then the project should be led by a management committee that rep-
resents each of the agencies in the region.
Regarding implementation and operations, the best approach depends on the composition of
the agencies in the region. If the region has a lead agency, it may make sense for that agency to
become the central provider and integrator for operational services to the other agencies. Thus,
the non-lead agencies outsource this function to the lead agency. This is a practical approach
because the non-lead agencies lack the experience and depth to perform these functions and with
this approach they do not need to commit resources to develop the core competency or expert-
ise in this area. The lead agency simply builds on what it already does well and is compensated
for this effort. If a region is run by a regional planning organization or a management commit-
tee, then a centralized approach is the obvious method. This approach is likely to be the result of
the regional planning organization or management committee creating a specification of busi-
ness rules derived from the fare policies of the regional agencies. The specification can now be
put out to open bid where third-party contractors can propose solutions for program imple-
mentation. Regardless of the approach taken, agencies or management committees are best
served by employing transit consultants to assist in their planning and implementation efforts.
An agency will seldom possess the same level of in-house expertise as does the consulting firm.
Regardless of the management approach adopted, a fundamental step is the creation of a par-
ticipant agreement acceptable to all participants. This agreement should be viewed as extensible
to new participants in the region in the future. Another basic consideration should be an analy-
sis of external factors influencing electronic fare payments. For example, if contactless bankcards
have been introduced and are held by many patrons in a region, then perhaps the acceptance of
contactless bankcards would be a system design imperative.
It is always good practice to verify the results of system integration incrementally. Thus, a
phased approach is the most responsible method of deploying a regional smartcard-based fare
collection program. One approach for phasing this deployment would involve supplementing
the Card Interface Device (CID) equipment into fare collection and issuing smartcard fare media
initially to agency employees only. This would allow for real live data and statistics to be compiled
for system-validation purposes with less risk than a full public deployment. Another strategy
87
OCR for page 88
88 Smart Card Interoperability Issues for the Transit Industry
would be to introduce only a few fare products initially. This approach also limits the complex-
ity of the system analysis and can give an ideal opportunity to uncover weaknesses or problems
in the new system.
A contracting strategy balances the costs of management of vendor(s) versus the costs of
equipment and services provided by vendor(s). Although a single vendor approach is the easiest
to manage, the cost of products and services may not be as competitive, because very few single
respondents can supply the complement of equipment and services for a regional smartcard-
based fare collection system. Multiple vendors may provide a more competitive contract process,
but the management is more complex and costlier. Given the many individual schedules that
must be coordinated, the multiple vendor contract approach may lead to a longer elapsed time
between the project inception and deployment when compared with the single procurement
contract model. The decision to use multiple vendors may also be determined by the size of the
agency and the scale of the deployment. The larger the project, the higher the degree of com-
plexity required to manage the overall project.
Financial management issues, such as settlement of payment and funds pool management,
should be decided by a finance committee set up by the region. The decision of whether clearing
and settlement should be centralized is the decision of the committee. A centralized clearing-
house is the easiest approach; however, the overhead required to operate the clearinghouse may
be a barrier. A decentralized approach, where agencies must have relationships with each other
for reimbursement and transfer privilege, requires greater effort on the part of any given agency
to maintain these multiple relationships. This method, however, might be the most financially
practical solution. The adoption of one approach over another is best indicated by the level of
inter-agency use by patrons. More specifically, if an agency has predominantly single-agency
transactions, then centralized clearing is inefficient.
Current deployments of smartcard-based fare collection systems throughout the world
demonstrate that there is no clear technical or business model for creating an interoperable envi-
ronment. Every system studied shows some attempt of using currently available standard fea-
tures for smartcard-based systems, but these implementations are mainly proprietary because of
waivers granted with respect to the use of these standards. For example, most smartcards com-
ply with the ISO/IEC 14443 standard; however differences in the implementation of minute
details, such as response timing, can preclude the interoperation of cards and readers. Not all of
the readers used in these projects are fully ISO/IEC 14443 compliant, nor do they all support both
Type A or B smartcards, and only one agency has implemented a full ISO/IEC 7816-4 command
set to define the communication between the card and the reader in a standard manner. With
regard to security, smartcard applications, interfaces, and back-end systems, the implementations
involve a mixture of schemes, all of which are mainly proprietary. The current system imple-
mentations show they can be the first step in effectively moving the transit industry toward inter-
operability. The next challenge for smartcard-based systems should be to adopt standards in
order to move toward this goal. If transit systems make full compliance to ISO/IEC 14443 and
ISO/IEC 7816-4 a procurement requirement from equipment integrators, the problem of smart-
card hardware interoperability could, to a large degree, be solved.
Almost all current national and international transit implementations of smartcard-based fare
collection systems are proprietary. To reach true interoperability and a competitive environment
for smartcard-based fare collection solutions, transit must insist on using standards throughout
all tiers of the system. Doing so will result in greater availability of multi-source vendors to sup-
ply products and services at a greater cost savings to agencies. As standards such as ISO/IEC
14443 and ISO/IEC 7816 become more ubiquitous, transit fare collection components must be
built on them. It is projected that form factors for contactless fare media will be expanding from
just cards to soon include watches, fobs, and cell phones. Other contactless applications on the
OCR for page 89
Conclusions 89
horizon include banking, retail, and building access. Transit must keep standards a priority and
look for new form factors and cooperation with other potential issuers like banks or retailers.
Limited-use smartcards, also known as memory logic cards, have restricted capabilities and
are a low-cost solution for transit agencies. On this class of card, the processor provides
read/write and limited or no security for these operations. These cards are best suited for appli-
cations that do not require a great deal of data or high security, such as a one-trip ticket or daily
pass. At a minimum, these cards should adhere to the ISO/IEC 14443 specification parts 2
through 3. [These parts define the radio frequency power and signaling interface scheme, of
which there are two (Type A and B), and define the initialization and anti-collision procedures.]
This class of smartcard typically offers a very small amount of memory, on the order of 48 bytes,
and they are only suited to applications with limited memory requirements. At this time, no
limited-use cards support the ISO/IEC 7816-4 commands and only implement proprietary com-
mands. Although this precludes the transparent substitution of limited-use cards from one ven-
dor to the product of another vendor, the low cost of these devices is likely to determine their use
in emerging AFC systems, despite their inherent lack of interoperability.
Full-featured smartcards, which contain a microprocessor, are more expensive, but offer
greater capabilities than the limited-use smartcards. These cards are best suited for long-term
use, because they offer greater storage capacity, the capability of storing of multiple applications,
and a higher security model. These cards should not only offer the same ISO/IEC 14443 Parts 2
through 3 requirements of the limited-use cards, but also be Part 4 compliant. (ISO/IEC 14443
Part 4 defines the transmission protocol and framing for data exchange.) As memory storage size
on smartcards increases, the value of a robust transmission protocol will become more evident.
The fully featured smartcard should also adhere to the entire APDU set defined in Part 4 of the
ISO/IEC 7816 specification, which standardizes a command set used for data exchange between
the reader/writer unit and the smartcard. Adopting ISO/IEC 7816 Part 4 and 3DES as the stan-
dard security level would standardize the security process for the smartcards. This would solve a
major problem with current smartcard implementations, where most security schemes are pro-
prietary. Requiring these ISO specifications would virtually turn smartcards into a commodity
item and increase the number of smartcard sources available and increase vendor competition.
The reader/writer device, also known as a proximity coupling device (PCD) or CID, should
also adhere to standards. The difference between a PCD and a CID is that a PCD is a "dumb"
device, commanded by a host controller device such as a single board computer in a faregate or
TVM. It is the primary job of the PCD to pass instructions and data between the host controller
and a smartcard. Conversely, a CID is a self-contained unit constructed with an embedded
processor and code to implement the instructions and business logic and is connected directly
to the components responsible for the radio frequency (RF) generation and modulation. A PCD
can be an interchangeable device, no matter what model or manufacturer; however, it is also a
slower solution for smartcard transactions because of its additional layer of communication to
an external host processor. The CID model offers faster smartcard transaction times, but also
makes a change in reader/writer deployment more difficult, because a rewrite of the logic will
probably be required. In an interoperable environment, both the PCD and CID must be able to
work with both Type A and B smartcards as defined in the ISO/IEC 14443 Part 2 specification.
Also, the CID must be able to add at least two SAMs in its design. The SAM allows a safe method
for both deploying secret key information for authentication and encrypting the data transmit-
ted during a secure smartcard transaction.
A common data model is also critical to achieve interoperability for smartcard-based systems.
A minimum set of data elements common to all systems must be defined and used. This set of
data should consist of information about the cardholder, including card identification number,
card issuer identification, patron profile code, and card validity period, and information about
OCR for page 90
90 Smart Card Interoperability Issues for the Transit Industry
the products, including product identification number, product validity period, and fare amount
for electronic purse transactions. This set of data should also contain information about the jour-
ney, such as agency identification number, date/time of journey event, entry and exit location of
journey, and route number.
Also, adopting a regional data standard that meets the minimum data element set, such as the
RIS or the Universal Transit Farecard Standards (UTFS), is highly desirable and essential if intra-
regional operability between regions is desired. The RIS and UTFS also offer other data items
that can be used within other agencies. Another benefit of adopting a published data model stan-
dard is that it is easily understood and allows for competitive vendor selection for implementa-
tion and further system expansion and maintenance.
The data standard adopted by transit should have broad capabilities to allow for many types
of electronic fare payments. If it is broad and flexible enough, it can allow non-transit applica-
tions such as parking, bridge and highway tolls, retail, access control, movies, and school ser-
vices, to share a common purse with transit applications. The RIS has been designed in such a
manner and should serve as a preferred path for future implementations based on a stored-
value/transit application model. This can be used in addition to the acceptance of bankcards
directly.
A standard approach for security on both hardware components and data flow throughout
the system tiers must be defined and established for smartcard-based fare collection systems.
Hardware and communications channels should be as secure as messages between a front-end
device and the bank clearinghouse [e.g., the Verifone security model for personal identification
number (PIN) pads]. In the PIN pad model, if a hardware device is ever tampered with or altered
in order to "sniff " messages, the unit becomes permanently inoperable. The same level of secu-
rity should be applied to PCDs and CIDs. For the software layer, there must be a standard pro-
posal to generate a signature for a transaction; this ensures data integrity and fully encrypts the
data stream to provide data confidentiality. Current public algorithms such as SHA1 for signa-
tures and DES/3DES for encryption would be solid choices for this approach.
A standard API was developed for this project and was designed to prove that a software layer
with a common command set could be created to work between a host application and different
manufacturer/model PCD/CID, which then interface with a smartcard. All smartcards for this
project must be at least ISO/IEC 14443 Parts 2 to 3 compliant. Today, virtually no PCD/CID
offers a common way to poll (search for) or query/update an ISO/IEC 14443 Part 2- to 3(4)-
compliant proximity integrated circuit card (PICC) in the generated RF field. All PCDs/CIDs
offer either a very small subset of the ISO/IEC 7816 Part 4 commands or their own proprietary
commands. This API proved that the commands supplied by the manufacturer for each of the
PCDs/CIDs selected for the project can be translated into a common set of newly defined com-
mands, thus forming a seamless layer between the host application and the PCD/CID. If this API
is instituted by the PCD/CID manufacturers as a driver or maintained as a TCRP dynamic load
library (DLL) module, the API would ensure that any TCRP-compliant PCD/CID could be inter-
changed without any affect on the system.
Since the inception of this project, technology and industry requirements have changed and
the need for the API has diminished. The transit industry is moving from the PCD model toward
the CID model, where the business logic is integrated in the device. The CID today is capable of
higher processing power and becoming a central component of fare collection device (e.g., fare-
gates and TVMs), thus a generalized programming strategy seems more inapplicable than it did
at the outset of this project and the API itself may not be the most efficient mechanism moving
forward; however, it may prove of great value in the incremental modernization of legacy sys-
tems or early proprietary smartcard implementations.
OCR for page 91
Conclusions 91
Transit must compel the use of standards as a part of all future procurement efforts to foster
the interoperability of smartcard-based AFC systems. Anything short of full compliance to
ISO/IEC 14443 and ISO/IEC 7816-4 should no longer be acceptable for transit applications. New
and emerging AFC programs must accept and embrace an agreed-on standard data format defin-
ing the data elements to be held on the smartcard. The RIS or UTFS are flexible systems ideally
suited for this use. If transit agencies collectively resolve to make using these standards a high pri-
ority in system development and procurement projects, the cause of smartcard interoperability
in transit AFC systems will be greatly advanced.
