OmniAir's Tim McGuckin writes about progress with the Electronic Payment Services National Interoperability Specification, which aims to provide the US with payment capabilities at lane level using any ETC component protocol. The OmniAir Consortium was founded to advance US national deployment of open, effective and interoperable transportation technology systems. Through its member-defined programmes, companies and individuals join to work for open standards, interoperability, third-party certification and
An integration team is currently preparing a test toll lane at the NYSBA's Beacon Bridge
OmniAir's Tim McGuckin writes about progress with the Electronic Payment Services National Interoperability Specification, which aims to provide the US with payment capabilities at lane level using any ETC component protocol
TheAt the device level OmniAir supports deployment of 5.9GHz DSRC, the communications protocol underpinning the safety and mobility goals of the USDOT's IntelliDriveSM programme. However, interoperability does not end at the device. Because of OmniAir's roots with
Testing a model
In an effort to provide the capability for payment system operators to achieve back office interoperability at a national level, OmniAir's Board of Directors charged its EPS Committee with creating a valid, test-ready specification. With funding support from I-95 Corridor Coalition and OmniAir members, the Committee would validate a proof of concept. The aim of this new standard, the Electronic Payment Services National Interoperability Specification (EPSNIS) is to provide payment capabilities at lane level using any ETC component protocol (915MHz, video or 5.9GHz DSRC) in much the same way that credit cards are used in retail sales. From day one, the goal of the EPS Committee was to create a specification that would allow adopters enough flexibility to accommodate their individual business practices.I-95 Corridor Coalition policy requires all proposed projects to have a Coalition member as a sponsor. In late 2008, the
The project began in earnest in early 2009 with creation of an EPSNIS team (OmniAir members that provide much or all of their time free of charge) which includes: PANYNJ (sponsor); OmniAir; JAFA Technologies (project manager);
The EPS Committee had to develop a set of functional requirements. At the highest level it did not simply want to select a widely used commercial specification because it felt none were completely appropriate. Nor for several reasons could it emulate a proprietary protocol. The EPSNIS would also accommodate individual business rules; participating operators and financial institutions were allowed to reach individual agreements as to where certain functions occurred within the national network.
In other words, this specification came with no mandates. For example, it was decided that the EPSNIS would not address a provision for dictating who holds ultimate fiduciary responsibility for toll payment in scenarios such as when the tag or in-lane equipment does not function properly. This would be determined as part of a contractual arrangement between a clearing corporation, OBU provider and (toll facility) operator - the three main parties on the EPS model the EPSNIS supports.
Other issues, such as violation enforcement, where and how discounts are applied, and vehicle classification mismatches, would also be determined as part of individual agreements.
Next, the Committee agreed that it would not be OmniAir's intention to dictate methods of audit and/or reconciliation, as the proposed EPSNIS is intended only to provide a standardised path to move data and financial transactions between participating agencies and their financial institutions. The Committee's very strong desire was to create a specification that would not preclude any agency (if it suits their individual business model to do so) from participating in a national network of the type envisioned by OmniAir and enabled by the EPSNIS.
Because OmniAir does not include all tolling facility operators, the Committee sought input from that community to help ensure it met its goals of providing maximum flexibility to support a competitive market for those who wish to participate and make use of the specification.
The committee disseminated the following list of functional requirements for comment. While the toll industry generally accepted these requirements, some operators remain hesitant to cede control of tag and account ownership.
Functional requirements
Support for numerous traditional and non-traditional OBU providers is required. This creates competition, provides improved value to end users, increases ETC penetration rates and reduces operators' costs. In short, an agency or operator could process an OBU for payment that was issued by an entity that provisions OBU in the same manner as banks provision/issue credit cards today.An intermediated network topology (clearing corporation model) is required. This makes it easier/faster for non-traditional OBU providers to join the network. It also buffers operators against the risks and expenses of dealing directly with each OBU provider (and any unique requirements a provider may have in order to implement its particular business model).
The clearing corporation is not required to contract with each operator. This decision is expected to minimise the work required by operators to join and stay on the network as the number of clearing corporations grows. This means that: each clearing corporation contracts with and interfaces with every OBU provider; and each operator contracts and interfaces with one clearing corporation.
If a clearing corporation on an EPSNIS-based network chooses to provide inter-network toll processing, then it will privately negotiate all systems' interfaces with the respective existing regional tolling reciprocity network. These parties may mutually agree that their resulting systems' interfaces may be controlled by the EPSNIS, by some modification of the EPSNIS, or by some other systems interface control document. This keeps participation by these existing networks voluntary and minimises the number of parties with which existing networks would need to negotiate and do business.
Core network topology
The EPSNIS controls the technical interfaces between the: operator and clearing corporation systems; and clearing corporation and OBU provider systems (Figure 1). Note that the illustration's single clearing corporation and OBU provider does not imply only one of each; many providers and clearing corporations are expected who would also be interoperable with each other. This differs from the topology of existing regional tolling reciprocity networks which operate as 'peer-to-peer' constructs, where most network members act both as OBU providers and operators, and where decisions about the network are made by network members acting as a committee. By contrast, in an EPSNIS network the roles of the OBU provider and the operator are completely independent from one another. This allows a network member to specialise in operating a facility or managing customer payment accounts, or to do both. The clearing corporation role is new, central to the network, and completely independent from that of an OBU provider or an operator. The clearing corporation implements the EPSNIS and is effectively responsible for managing, growing, and operating the network that services the operators who specify the EPSNIS and contract with the corporation.EPSNIS status
The EPS Committee has created three documents in preparation for a lane test: EPSNIS functional requirements (described above); a test-ready EPSNIS Draft Version 1.0; and an EPSNIS test specification (to be used byAn integration team is now preparing a toll lane at New York Bridge Authority's Beacon Bridge. System integration is being led by Telvent-Caseta. MARK-IV is readying the 5.9GHz DSRC onboard and roadside systems. Testing is scheduled to begin in early March and lasts 45 days, using two NYSBA-supplied, 5.9GHz DSRC OBU-equipped vehicles producing approximately 50 transactions per day. The lane test, conducted by SwRI, will probably result in specification modifications. The project closes at the end of May.
Next steps
The next logical steps in the EPS Committee's plan pertain to implementation because OmniAir's mission is to produce tools intended to be deployed.NSYSBA does not issue tags or manage accounts. Therefore, the EPS Committee believes that testing the EPSNIS at an actual regional interoperability consortium member (engaging with MTA Bridges & Tunnels or Dulles Toll Road and sending transactions through their network) is needed. This would support another key element: presentation of the relative value of the EPSNIS via a cost-benefit study capturing capex/opex via a common taxonomy for the compared systems. Neither resides within the scope, budget or schedule of the EPSNIS Test Project described herein. More funding is being sought.
Conclusion
The EPSNIS is not a mandate nor does it invite a revolution in the toll industry. It simply recognises and leverages an existing business model. It gives the tolling community the choice of: playing an active role in the evolution of payment services in the USA; and taking the steps needed to exploit it, on its terms.European precedent
In 2004 theThe EETS and the EPSNIS are similar in that the customer is disassociated from his particular toll road operator for the purposes of ETC account and tag management. They differ in that the EPSNIS is a voluntarily adopted specification while the EETS is mandatory.
