35077 Attachment B_Program Requirements Document~3.pdf

Road Usage Charge Program

Program Requirements Document

Version 2.1

Date: May 26, 2021

ATTACHMENT B

This page intentionally left blank.

Contents

1. RUC OVERVIEW

1.1 PROGRAM VISION

1.2 OBJECTIVES OF THE PROGRAM

1.3 SYSTEM OBJECTIVES IDENTIFIED BY ODOT

1.4 DOCUMENT REFERENCES

1.5 REQUIREMENT NAMING CONVENTIONS

2. GENERAL REQUIREMENTS

2.1 GENERAL BUSINESS REQUIREMENTS (GBR)

2.2 GENERAL SYSTEM REQUIREMENTS (GSR)

2.3 SYSTEM SECURITY (SS)

2.4 BUSINESS PARTNER PERSONNEL

2.5 SYSTEM REPORTING DEFINITIONS (SRD)

3. PROGRAM AND PARTICIPANT MANAGEMENT (PPM)

3.1 PROGRAM INFORMATION AGREEMENTS (PIA)

3.2 PARTICIPANT ACCOUNTS (PA)

3.3 PERFORMING ACCOUNT UPDATES (PAU)

3.4 CLOSING RUC ACCOUNTS (CRA)

3.5 ONLINE RUC ACCOUNT SERVICE (OS)

4. MILEAGE REPORTING OPTION (MRO)

4.1 MRO ACCURACY

4.2 RECORD ACCUMULATED MILEAGE TRAVELED (RAMT)

4.3 VEHICLE LOCATION DIFFERENTIATION (VLD)

4.4 DETERMINE FUEL USAGE (DFU)

4.5 RESIST FRAUD AND TAMPERING (RFT)

4.6 SAFE AND SECURE (SS)

4.7 TRANSMIT TRAVEL DATA (TTD)

5. DATA COLLECTION SUBSYSTEM (DC)

5.1 RECEIVE DATA FROM MRO (RDM)

5.2 DIFFERENTIATE TRAVEL DATA (DTD)

5.3 CONFIGURABLE PARAMETERS (CP)

5.4 HANDLE ERRORS AND EVENTS (HEE)

5.5 CREATE AND SEND MILEAGE MESSAGE (MM)

6. TRANSACTION PROCESSOR SUBSYSTEM (TP)

6.1 RECEIVE MILEAGE MESSAGE (RMM)

6.2 VALIDATE MILEAGE MESSAGE (VMM)

6.3 HANDLE ERRORS AND EVENTS (HEE)

6.4 CALCULATIONS (C)

6.5 ROUNDING (R)

6.6 STORAGE (S)

6.7 SEND DATA (SD)

7. ACCOUNT MANAGEMENT SUBSYSTEM (AM)

7.1 RECEIVE DATA FROM TP (RDT)

7.2 REPORTING ACCOUNT SETUP AND CLOSURE (ASC)

7.3 PARTICIPANT ATTRIBUTES (PA)

7.4 REPORTING DATA (RD)

7.5 MESSAGE HANDLING (MH)

7.6 MAINTENANCE (M)

8. ACCOUNT MANAGEMENT OPERATIONS (AMO)

8.1 BILL PARTICIPANTS (BP)

8.2 INVOICE TO PARTICIPANTS (ITP)

8.3 REFUNDS (R)

8.4 ACCOUNT ADJUSTMENTS (AA)

8.5 POSTING RUC PAYMENTS (PRP)

8.6 CONTACT MANAGEMENT AND REPORTING (CMR)

8.7 NOTIFICATIONS (N)

8.8 RECOVERING MISSED MILES (RMM)

5 Oregon Department of Transportation

Revision History

Date Of Revision

Reason For the Change and Short Summary of the Revisions Made

Version Number

05.26.21 Created final version of newly created PRD, combining the BRD and the SRS into a single document, removing redundancy and adding new requirements. Advancing to version 2.1 as the current published BRD is v1.8 and SRS is v2.0.

2.1

Definitions

Term Definition

Admin Administrator – A government entity administering a RUC Program. For example, ODOT would be considered the Administrator for the OReGO Program.

AM Account Manager – A type of business partner specifically responsible for participant service, account management, and account operations.

BP Business Partner – Any entity that provides a service that supports the RUC system. An entity providing account management services is an Account Manager. An Account Manager is a type of business partner. A Transaction Processor and Data Collector are also types of business partners.

DC Data Collection Subsystem – A system, operated by a business partner, that receives and stores raw travel data from the MRO and sends travel data to the Transactions Processor subsystem.

GPS Global Positioning System – Provides vehicle location details to the system.

ICD Interface Control Document – Provides technical specifications for communication interfaces within the RUC system.

MRO Mileage Reporting Option – A means of capturing and reporting travel data.

SAM State Account Manager – Account Manager acting on behalf of a State Agency.

ODOT Oregon Department of Transportation

PII Personally Identifiable Information

RUC Road Usage Charge

TP Transactions Processor Subsystem – A system, operated by a business partner, that receives and stores raw travel data sent from the DC. The amount of road usage charge is calculated in this system using the business rules promulgated by the admin.

Travel Data Total miles traveled and, if available, total fuel used. May include vehicle location for location-based MROs.

VCRI Verification Cross Reference Index – A tool used to track the business partner’s certification status of program requirements.

7 Oregon Department of Transportation

1. RUC Overview

1.1 Program Vision

The OReGO Program, ODOT’s operational road usage charge (RUC) program, was enacted by Senate Bill 810 (2013). The SB810 requires ODOT to give program participants choices for methods to report miles driven, as well as how they manage and pay their road usage charges. Participants are able to obtain RUC services through nongovernmental entities, and given market-driven choices that are efficient and cost-effective. The intention of the Road Usage Charge System is to implement a cost-effective system for collecting the road usage charge, one that is highly automated and is easy to use and understand.

1.2 Objectives of the Program

To achieve the vision, program objectives were identified:

• A road usage charge per mile for travel on taxable roads in Oregon to be paid by participating vehicle owners.

• A credit of Oregon State fuels tax paid by participating vehicle owners for taxable fuel used, which is not a refundable credit.

• Credit of Oregon State fuels tax for travel on private roads in Oregon and out of state miles.

• Participation for those who own electric vehicles (EV) and vehicles with an average mpg rating of 40 or higher.

• Choices for participants in how their taxable mileage is collected and reported.

• An open system that allows different types of technology to collect and submit mileage and fuel consumption data that includes at least one method that does not use vehicle location technology such as GPS.

• Contracted private sector business partners (BPs) that will help operate the program and provide participants with choices.

• Protection of personally identifiable information from disclosure and the elimination of all location-based and daily metered use information according to stringent timelines, unless the retention is expressly consented to by the participant.

1.3 System objectives identified by ODOT

• The system shall be auditable.

• The system shall collect road usage charge from tax-liable users for travel in Oregon.

• The system shall provide non-refundable credits for Oregon fuel taxes.

• The system shall contain redundancy and backup information.

• The system shall support interoperability and inherit the RUC Open Architecture, which provides private companies the option to offer one or multiple subsystems.

• The system shall be expandable and flexible to accommodate a scalable number of users and revenue collection uses.

• ODOT will validate the system requirements through initial certification, regular monitoring, and periodic system reviews.

1.4 Document References

Other critical program aspects are described in the following documents:

• Interface Control Document (ICD), which provides technical specifications for communication between system interfaces

• Appendix A – RUC Refund Matrix

• Appendix B – Data Reporting Process Flow

• Appendix C – RUC Rate Table

1.5 Requirement Naming Conventions

The requirements are organized using the following convention:

<subject>.<function abbreviation>.<requirement index>.

2. General Requirements

2.1 General Business Requirements (GBR)

ODOT, the Administrator, has developed general business requirements to identify if the Business Partner (BP) has existing core capabilities and securities to support the RUC Program. These requirements define the overarching business process areas including the capability to collect and remit tax payments to the Oregon State Treasury, supporting audits by the Administrator, management of technology configurations and assets, and providing reconcilable reports that show the collection and transfer of revenues through the BP’s accounting systems.

Requirement Description

GBR.1 The BP shall be financially stable through the duration of this Price Agreement (PA). The BP shall be able to provide proof of sustainable business for the past three (3) years at the time of PA establishment. If the BP is a joint venture, then each company comprising the joint venture shall provide proof of business for at the past two (2) years at the time of PA establishment and provide a letter of commitment for sustained business for one (1) year.

BP shall provide proof of financial stability. This proof shall consist of a Dun & Bradstreet Rating (or equivalent) Classification of 1A or higher, and a Composite Credit Rating of “Good (2)” or “High (1)”.

GBR.2 The BP shall use generally accepted accounting principles (GAAP). BP accounting systems shall incorporate industry accepted accounting principles, including separation of duties.

GBR.3 The BP’s corporate financial records shall be auditable.

GBR.4 The BP shall have documented in-place processes for Change and Configuration Management that includes a review period for system changes. For system changes that impact the functionality of the system, Administrator approval is needed.

GBR.5 The BP shall have documented in-place processes and systems for disaster recovery and continuity of operations.

GBR.6 The BP shall conduct banking within the United States. The BP shall have a dedicated U.S. based bank account for all financial transactions, which occur under this Price Agreement. The BP shall be able to remit payments by mail and electronic banking.

GBR.7 All BP’s associated with creating, receiving, sending, and storing RUC travel data, PII, and financial transactions must provide the Administrator an SSAE-18 SOC 2 Type 2 (or equivalent) audit performed within the last one year.

9 Oregon Department of Transportation

2.2 General System Requirements (GSR)

The following are general requirements that are necessary for providing services to support the road usage charge program system.

Requirement Description

GSR.1 The system shall be auditable in order to validate data received from the vehicle and processed, delivered, or received by any subsystem.

GSR.2 The system shall collect data to support the calculations for road usage charge.

GSR.3 The system shall provide credits for applicable fuel taxes.

GSR.4 The system shall collect road usage charge only for taxable miles, as defined by the Administrator.

GSR.5 The system shall align with the RUC open architecture.

GSR.6 The BP system shall have a test environment(s) in addition to a production environment(s). The test environment shall allow the creation of test accounts and shall be exclusive of the production environment. The test environment shall exclusively be used for testing new software and all messages defined in the ICD, before release to the production environment.

2.3 System Security (SS)

System Security must comply with the standards set forth by the Administrator. The BP shall provide the system design and an inventory of information security controls. The BP will share information about Security and Disaster Recovery details for the overall system to ensure adequate protection and assurance of recovery options in the event of an unexpected incident.

2.3.1 Data Protection (DP)

Requirement Description

SS.DP.1 The BP shall provide a system architecture diagram that illustrates each component with the RUC Program systems and their interactions.

SS.DP.2 The BP shall provide the physical location of the RUC program system servers.

SS.DP.3 The BP shall provide the security measures implemented across the RUC program system.

SS.DP.4 The BP shall document the implemented process for Information Asset Classification in accordance with the Administrator’s Information Asset Handling Requirements that will be provided by the Administrator.

SS.DP.5 The BP shall document the personally-identifiable information (PII) that is stored, and the corresponding system the data is stored in, and the operational controls that maintain the appropriate level of security and access to the PII.

SS.DP.6 The BP shall make the Administrator aware of any system breach or potentially significant informational breach immediately upon discovery.

SS.DP.7 The BP shall provide data masking for all participant financial information from its employees. At a minimum, means of financial information (including but not limited to ACH, credit and debit card data) shall be masked.

SS.DP.8 The BP shall provide a data modification notification to the participant, through the account contact method provided, as soon as changes are saved in the account information.

SS.DP.9 The BP shall refer to the Oregon state data retention statutes for clarification:

http://arcweb.sos.state.or.us/pages/rules/oars_100/oar_166/166_300.html The applicable data retention statutes will be provided by the Administrator.

http://arcweb.sos.state.or.us/pages/rules/oars_100/oar_166/166_300.html

2.3.2 Payment Protection (PP)

Requirement Description

SS.PP.1 The BP shall provide proof of compliance with industry security standards required for the payment options provided.

Example: Compliance with Payment Card Industry Data Security Standards (PCI-DSS) is required for credit and debit card transactions.

SS.PP.2 The BP shall provide its information security policy for how payment security is addressed in these areas:

• Firewalls to protect financial data

• Protection for stored financial data

• Restrictions to financial data, physical or otherwise

• Tracking of access to financial data

• Regularly testing security systems and processes

2.3.3 System Level Security (SLS)

Requirement Description

SS.SLS.1 The system shall manage separate tiers of access for personnel, allowing for separation of duties and administrative tasks. Documentation defining the access provided for each tier must be provided to, and approved by, the Administrator.

SS.SLS.2 The BP systems shall encrypt passwords and log all access attempts to account and log files, compliant with current NIST guidelines.

SS.SLS.3 The BP shall provide a description of the authentication methods used for systems that store personally identifiable information.

SS.SLS.4 The BP shall provide a description of the antivirus and antimalware applications being used, scan frequencies, and the scope of the scans.

The system shall include mechanisms for detection and notification about potential and realized viral and malware threats.

SS.SLS.5 The BP shall provide a description for an incident response process that includes descriptions of triggers, triaging of the incident, notification steps and monitoring steps.

SS.SLS.6 The BP shall provide a description of server management policies utilized for any server related to RUC processing, identifying firewalls, level of encryption (at least AES-256b), and communications.

SS.SLS.7 The BP shall provide a description of backup management policies for testing processes, restore processes, accessibility to back up information, level of encryption (at least AES-256b), and media type used.

SS.SLS.8 The BP shall provide a description of network security such as public/private network separation, encryption (at least AES-256b), and identification of firewalls.

SS.SLS.9 The BP shall provide a description of intrusion detection that includes detection, internal monitoring practices, and incident response.

SS.SLS.10 The BP shall provide its policy for encryption for each level where program data will reside (file, database, disk, etc.). This policy shall include the procedure for preventing unauthorized access. Encryption requirements shall conform to system requirement ID SS.RDM.2.

SS.SLS.11 The BP shall provide its policy for IT system lifecycle management, which shall include, but not be limited to, the change control process (authorization through implementation), security patch process, and ongoing maintenance of updates. Lifecycle management activities shall occur throughout the system development lifecycle including design, acquisition, implementation, configuration, testing, maintenance, and replacement of system components.

11 Oregon Department of Transportation

SS.SLS.12 The BP shall provide its policy for remote access that includes the specific uses of remote access to program data, authentication method(s), encryption used, mobile device policy, and security measures.

SS.SLS.13 The BP shall provide its policy for wireless management that includes the specific uses of wireless access to program data, encryption used, guest/non-guest access levels, and incident response. Also, if the BP uses industry supported access standards 802.11, it shall indicate which standard is being employed. (i.e. 802.11a, 802.11b, 802.11e, 802.11g, 802.11i, 802.11n)

SS.SLS.14 The BP shall retain participant account data and account financial information for 6 years.

(Statute 166-300-0015 and 166-300-0025), allowing for the exception in Senate Bill 810 (“SB 810”), 2013 Oregon Laws, chapter 781, regarding location and daily metered use data.

SS.SLS.15 The BP shall retain computer system security access logs for 3 years, and other system security records for 3 years after superseded or expired.

2.3.4 Disaster Recovery (DR)

Requirement Description

SS.DR.1 The BP shall provide a plan that details its process for disaster recovery, including back up and redundancy, in the event that an incident threatens or impacts normal business operations.

2.3.5 Restricted Data Management (RDM)

Requirement Description

SS.RDM.1 Transmission of Level 3 data between any subsystems shall be secured, at minimum, in accordance with current NIST guidelines and approved by the Administrator. Current NIST guidelines will be at time of contract signing and throughout contract as guidelines are updated by NIST. Upon notice that NIST guidelines have been updated, the BP shall provide a plan to comply with updated guidelines within 60 business days.

Level 3 data is any sensitive information intended for limited business use that may be exempt from public disclosure because such disclosure may jeopardize the privacy or security of individuals. Personally Identifiable Information (PII) qualifies as Level 3 data.

SS.RDM.2 The BP shall encrypt Level 3 Data at rest with AES-256 bit or stronger.

2.4 Business Partner Personnel

Business partner personnel act as the primary representation of the program for participants and the public.

These requirements are designed to ensure that BP personnel are properly vetted to be entrusted with the program information and trained to meet or exceed the program objectives.

Requirement Description

BPP.1 The BP shall have all personnel with access to any participant information or travel data vetted by performing a background check that includes:

a) Social Security Number Validation

b) State Criminal Background Check (encompassing the past 7 years)

c) Federal Criminal Background Check (encompassing the past 7 years)

d) State & National Sex Offender Registry

e) State Records Locator If a U.S. based background check is unavailable, an equivalent background check format shall be provided to the Administrator for review and approval.

BPP.2 The Account Manager shall provide a process for Administrator approval that describes how it will verify, to a reasonable extent, the identity of the person contacting the Account Manager prior to releasing account information to them. Examples include Individual PIN or Password verification.

BPP.3 The BP shall define the roles and responsibilities of their operation to provide sufficient assurance of segregation of duties. This shall include and not be limited to the BP’s process for oversight and review.

BPP.4 The Oregon Account Manager (OAM) shall provide Account Management subsystem read-only access to the Administrator subsystem for account and financial details.

BPP.5 The BP shall provide read-only access to the Account Management subsystem pursuant to an audit investigation.

Access to daily metered use and location information will be restricted for the Administrator based upon limitations set forth in ORS 319.915.

BPP.6 The BP or any entity working with the BP shall not disclose personally identifiable information used or developed for reporting travel data by an enrolled vehicle, or for administrative services related to the collection of per-mile road usage charges to any person except:

• The registered vehicle owner or lessee;

• A financial institution, for the purpose of collecting per-mile road usage charges owed;

• Employees of the Administrator;

• An Administrator approved BP (e.g. certified service provider);

• A contractor for a certified BP, but only to the extent the contractor provides services directly related to the certified BP’s agreement with the Administrator;

• An entity expressly approved by the registered owner or lessee of the subject vehicle to receive the information; or

• A police officer pursuant to a valid court order based on probable cause and issued at the request of a federal, state or local law enforcement agency in an authorized criminal investigation involving a person to whom the requested information pertains.

2.5 System Reporting Definitions (SRD)

Similar functions across subsystems that reference the same resources should process, store, and send information in a similar manner. The intention is to adhere to consistent usage for general definitions and practices.

Requirement Description

SRD.1 For purposes of reporting data to the Administrator, the BP shall define a day as 12:00:00 am to 11:59:59 pm UTC.

SRD.2 The BP shall reconcile time zone differences for all data transmissions between components and subsystems.

SRD.3 The BP shall maintain the RUC rate table to be used by all components and subsystems, as specified by the Administrator.

SRD.4 The BP shall support changes to the Rate Table as used within all components and subsystems, as directed by the Administrator.

SRD.5 The BP shall secure the following identification numbers, provided by the Administrator, before assigning an MRO to a participant's vehicle for the purposes of collecting and reporting travel data:

• AMID – Business Partner Identification Number, to be assigned by the Administrator (as defined in the ICD)

13 Oregon Department of Transportation

• CertID – Certification Identification Number, to be assigned by the Administrator for each MRO certified for RUC mileage collection (as defined in the ICD)

SRD.6 The BP shall destroy the saved mileage messages’ location and daily metered use information, per statute, not later than 30 days after dispute resolution for a single quarterly reporting period, or a noncompliance investigation, whichever is latest.

3. Program and Participant Management (PPM) Participant Management is a crucial part of an effective program. BPs may supplement with other information if it does not conflict with Administrator messaging.

The BP will have ongoing, direct contact with participants, and is expected to provide participant success stories and other program information for public relations messages. In response to an Administrator request, the BP shall provide nonproprietary program information for the legislation process or other public information use.

3.1 Program Information Agreements (PIA)

The BP is expected to request the participants provide their consent for participation in the program. The Administrator’s Participant Agreement, will be provided by the Administrator. It is to be used verbatim, and must be accepted separately from any other terms and conditions presented by the BP.

Participant acceptance, via electronic signature of ODOT’s Agreement and the application approved by the Administrator Subsystem, are required before the participant can establish a RUC account with the BP.

Because the program involves tax liability for the participant, the BP is required to retain the electronic signatures and agreement information, and provide all e-signature documentation and agreement information to the Administrator upon request.

Requirement Description

PPM.PIA.1 The BP shall be responsible for communicating and updating published policies related to privacy and data retention, to and for the participants and Administrator.

PPM.PIA.2 RUC program Terms and Conditions from the BP, beyond that provided the Administrator, shall be reviewed by the Administrator before publishing to the public.

PPM.PIA.3 If the BP presents any of its own RUC program terms and conditions, beyond that provided by Administrator, to the participant, the BP shall:

• Request consent for this separate set of terms and conditions

• Request the consent as its own approval step

PPM.PIA.4 If the BP requests the participant to expressly approve an entity to receive their PII, then the BP shall:

• Request this express approval as a separate step

• Provide this express approval request as a unique agreement with separate terms and conditions.

Note: The definition of PII can be found in ORS 319.915[3][a][F].

PPM.PIA.5 The BP shall capture and retain the electronic signatures and agreement information for all required agreements, and provide to the Administrator upon request.

Examples:

• Agreement to Terms and Conditions including the Participant Agreement

• Agreement to Participant PII disclosure, if expressly approved

• Agreement to BP retention of location based and daily metered use data, if consented to.

PPM.PIA.6 For the purpose of obtaining the participant eSignature on the Participant Agreement, the BP shall require the participant to type their first and last name, in accordance with the current guidelines for first level of NIST electronic authentication (NIST level 1) and approved by the Administrator.

PPM.PIA.7 The BP, upon Administrator's request, shall have the ability to provide the information related to the executed Participant Agreement and program terms and conditions, including:

a) Participant Name and VIN

b) Participant Agreement Date/Time Stamp, at time of application submission

c) Participant Program Application

d) Participant Electronic Authorization (eSignature)

e) Version and content of Participant Agreement

f) Version and content of any other Terms & Conditions to which the participant consented at the time of application submission

This information shall be provided through standard document and information formats (including pdf, MS Excel, MS Word and CSV) as specified by the Administrator.

PPM.PIA.8 The BP shall validate that the first and last name of the participant’s eSignature match the first and last name as entered during the enrollment process.

PPM.PIA.9 If the BP requests the participant allow retention of location based and daily metered use data (per ORS 319.915[4][a][B]), then the BP shall request this express approval separate from the Participant Agreement.

PPM.PIA.10 If the BP intends to collect data from the participant and enrolled vehicle beyond the minimum required to calculate road usage charges and related fuel tax credits, the BP shall request the consent from the participant in the BP Terms and Conditions.

PPM.PIA.11 The BP shall present any agreements required by the Administrator in its entirety to the participant.

3.2 Participant Accounts (PA)

BPs shall implement processes for enrolling participants, onboarding vehicles, participants leaving the program, updating account information, handling incoming inquiries, and distributing MROs (if needed). Some of the information gathered at the time of enrollment includes name, VIN and vehicle description, mailing address, contact information, and MRO selection. See the ICD for the full required list of data elements.

Requirement Description

PPM.PA.1 The BP shall implement processes for enrolling participants, onboarding vehicles, processing participants leaving the program, updating account information, handling incoming inquiries, and distributing MROs (if needed).

PPM.PA.2 The BP shall provide details for Administrator approval, regarding the processes they will use for the capabilities of the online service, including participant enrollment and account access, program and contact information, and secure payment processing.

PPM.PA.3 The BP shall record the initial odometer reading for a vehicle. The BP shall be able to correct their initial odometer reading, as needed.

PPM.PA.4 The BP shall assign a unique MRO of the requested type to each vehicle on the participant's account.

PPM.PA.5 The BP shall allow multiple MRO types under the same account.

PPM.PA.6 The BP shall check the vehicle(s) indicated on the enrollment to ensure it is compatible with the MRO selected by the participant.

PPM.PA.7 The BP shall communicate with their participant when their vehicles are accepted or declined for the program.

PPM.PA.8 The BP shall decline the participant who does not accept the Participant Agreement, and shall not send the enrollment information to the Administrator for approval.

15 Oregon Department of Transportation

PPM.PA.9 The BP shall require an electronic signature from the participant to submit the enrollment information and acceptance of the Terms and Conditions.

PPM.PA.10 The BP shall capture, retain, and transmit all enrollment information to the Administrator, as defined in the ICD.

PPM.PA.11 The BP shall notify the Administrator of all MRO types, including the MRO configuration information, used in RUC Program operations at program start, and of any changes to MROs and related system components that occur.

See “MROConfigVersion” code block in section 2.2 and 3.10.1 of the Interface Control Document (ICD) for details.

PPM.PA.12 The BP shall advise the participant during the enrollment process if there is a condition which will affect their ability to participate. Examples include: program or MRO requirements, vehicle registration address, etc.

PPM.PA.13 Upon receiving an enrollment from a participant, the BP shall review the vehicle information and determine the highest EPA combined MPG rating for the enrolled vehicle type defined below and report it to the Administrator within the Account and VIN Update message:

The BP shall use the EPA fuel economy data (published at www.fueleconomy.gov) to determine the EPA combined MPG value for the vehicle. If the combined MPG value is not published by the EPA, the BP shall use the best available source to determine MPG. The BP shall determine MPG based on the following logic:

• If the vehicle is powered by gas, diesel or compressed natural gas (CNG), or is a standard hybrid, use the rounded combined MPG value

• If the vehicle is fully electric-powered or uses tax-exempt fuel, no MPG rating is to be used

• Remaining vehicles are plug-in hybrids, use the rounded combined MPGe (PHEVComb) value

If the BP is unable to identify a value that meets the requirement, the BP must contact the Administrator for assistance.

PPM.PA.14 The Account Manager shall deliver an email upon receipt of the enrollment application submission containing the following information:

• Statement regarding conditional approval into the OReGO program

• Enrollment Application Date (the date the application was submitted)

• Applicant First and Last Name

• Enrolled Vehicle VIN

PPM.PA.15 The Account Manager shall allow account creation and account closure.

3.3 Performing Account Updates (PAU)

BPs will be responsible for the ongoing maintenance of accounts as participants provide information or require assistance. BPs must develop procedures including: updating participant information, vehicles joining and leaving the program, applying account incentives, placing accounts on hold, and making account adjustments.

Requirement Description

PPM.PAU.1 The BP shall perform any applicable adjustments to the accounts, as specified by the Administrator, and shall be transferred to the participant account with no administrative fees or withholdings.

PPM.PAU.2 The BP shall allow the participant to add an unlimited number of qualified vehicles to the account as long as that participant is the enrolled registered owner.

PPM.PAU.3 If a new MRO is needed, the BP shall have a replacement process that associates the new MRO with the vehicle on the account.

PPM.PAU.4 For changes in miles, fuel use, RUC, and fuel tax credit amounts the BP shall adjust the participant account, per the jurisdictional rules where and when the miles were driven.

PPM.PAU.5 The BP shall maintain current fuel efficiency values for all vehicles. The values shall be validated in a quality review process at least once per year and transmit changes to the Administrator.

PPM.PAU.6 The BP shall manage the status of the MRO based on the MRO's ability and authority to report required data for the enrolled vehicle. The BP shall report the status change of the MRO within 48 hours of notification for the status change, as defined in the ICD.

PPM.PAU.7 The BP shall be able to manage the status of the MRO for the vehicle on the account without affecting the VIN status or the account status.

Example: If the BP is notified that the MRO has been lost, the BP shall be able to deactivate the MRO without discontinuing the vehicle on the participant's account.

3.4 Closing RUC Accounts (CRA)

The BPs process for closing accounts will involve deactivating MROs and reviewing financial activity for the closed accounts. When a participant leaves the program, all of their associated vehicles will also leave the program. The BP will notify the Administrator that the participant is leaving the program.

Requirement Description

PPM.CRA.1 The BP shall terminate the account upon request of the participant.

PPM.CRA.2 The BP shall have the ability to terminate a participant account under the conditions of non-payment or the participant’s violation of any agreements.

PPM.CRA.3 The BP shall provide online account access to the participants, at a minimum displaying RUC related information and financial functions, for an amount of time after account closure, as directed by the Administrator.

PPM.CRA.4 When a vehicle is discontinued from the program, the BP shall change the MRO status to de-activated and stop gathering and reporting travel data.

PPM.CRA.5 When a vehicle is discontinued from the program, the BP shall consider the discontinue date the earliest of the notification date or termination date.

3.5 Online RUC Account Service (OS)

The BP will create an online presence for participants to receive information about the program and their accounts. The online service will be the primary way that participants will enroll and manage their accounts.

Requirement Description

PPM.OS.1 The BP shall make available a service provided by a software application running online and making its facilities available through the internet via an interface.

PPM.OS.2 The BP online service shall allow new volunteers to sign up to become a participant.

PPM.OS.3 The BP shall work with the Administrator on the design and layout of its online website.

PPM.OS.4 The BP’s online service shall include the Administrator's published program information. The Administrator will provide the program information to the BP.

17 Oregon Department of Transportation

PPM.OS.5 Mileage reporting options shall be offered to the participant for collection and reporting travel data.

PPM.OS.6 Invoices and statements shall be available through the online service interface to the participant.

PPM.OS.7 The online service shall have contact information for the BP and the Administrator.

PPM.OS.8 The BP shall provide access to the participant to view miles traveled and, if available, fuel consumed through the online service interface.

PPM.OS.9 The BP’s online service shall include a means for the participant to view the charges on the account by Rule ID/SubRule ID.

4. Mileage Reporting Option (MRO) The Mileage Reporting Option (MRO) interfaces with vehicles to collect raw travel data for those that are subject to road usage charging. The travel data is reported by the MRO to the Data Collection subsystem for complied communications.

The following MRO, DC, TP, and AM requirement sections describe the reporting process. Data flows typically from the Mileage Reporting Option to the Data Collection subsystem, then through the Transaction Processor subsystem to the Account Management subsystem, and finally on to the Administrator subsystem.

MRO DC TP AM AdminMRO Reporting

DC

Reporting

TP

Reporting

AM

Reporting

VIN Summary Report Mileage and RUC Revenue Report

Errors and Events Report Formal Tax Report

Mileage Message

MRO Reporting: The MRO sends data to the Data Collection subsystem. This interface has yet to be standardized, but is required to have a pre-defined consistent reporting period configured, defined by the Account Manager.

DC Reporting: The Data Collection subsystem sends data to the Transaction Processor subsystem. This interface is standardized with message content/format defined in the ICD as the:

− Mileage Message The DC reporting period is not required to have a pre-defined consistent reporting period configured, however is required to send a minimum of once per quarter.

TP Reporting: The Transaction Processor subsystem sends data to the Account Management subsystem.

This interface has yet to be standardized. The TP reporting period is not required to have a pre-defined consistent reporting period configured, however is required to send a minimum of once per quarter.

AM Reporting: The Account Management subsystem sends data to the Administrator subsystem. This interface is standardized with message content/format defined in the ICD as the following messages:

− VIN Summary Message

− Mileage and RUC Revenue Message

− Error and Events Message

− Formal Tax Report The AM reporting period is required to have a pre-defined consistent reporting period configured defined by the Administrator, currently defined as weekly, monthly, and quarterly.

4.1 MRO Accuracy

MRO.ACC.1 The BP shall validate the MRO accuracy by having a third party perform testing to validate accuracy of miles traveled and fuel consumed +/- 5% of actual. These results shall be provided to the Administrator.

4.2 Record Accumulated Mileage Traveled (RAMT)

MRO.RAMT.1 The MRO shall monitor and collect travel data for the vehicle to which it is assigned.

MRO.RAMT.2 The MRO shall collect accumulated distance traveled.

MRO.RAMT.3 The MRO shall store all data sent to the Data Collection subsystem for computing accumulated distance traveled until the data is acknowledged as received by the Data Collection subsystem, even under periods of sustained disruption of service.

MRO.RAMT.4 The MRO shall report data to the Data Collection subsystem consistent with the configured MRO reporting period.

MRO.RAMT.5 The MRO reporting period for each MRO type shall be defined by the BP and consistently configured for all MROs of the same type.

MRO.RAMT.6 Location based MRO shall either contain hardware to determine location or interface with external user-provided wireless devices that contain hardware to determine location.

MRO.RAMT.7 The MRO shall record the distance traveled in the applicable Rule ID/SubRule ID in which the vehicle is traveling.

See the RUC Rate Table in Appendix C.

MRO.RAMT.8 The MRO shall calculate total distance traveled by vehicle per AM reporting period within +/-5% of the actual value.

MRO.RAMT.9 When an MRO is capable of operating with or without location differentiation, the BP shall provide a notification and gain consent from the vehicle owner each time the functionality changes.

4.3 Vehicle Location Differentiation (VLD)

Requirement Description

MRO.VLD.1 Location based MROs shall be able to determine the location of the vehicle within 26 feet of accuracy of the border between applicable Rule ID/SubRule IDs.

19 Oregon Department of Transportation

MRO.VLD.2 The system shall provide a means for updating map definitions and data points, as well as the definition of each Rule ID/SubRule ID, when changes are warranted based on business rule definitions.

MRO.VLD.3 The BP must utilize a mapping functionality approved by the Administrator, to differentiate taxable and non-taxable miles.

4.4 Determine Fuel Usage (DFU)

Requirement Description

MRO.DFU.1 In vehicles that use fuel as a motive power, if the vehicle interface used by the MRO allows monitoring of, or an estimate of, fuel usage (based on parameters such as MAF or MAP sensor data), the MRO shall record the accumulated fuel used by the vehicle for the applicable Rule ID/SubRule ID.

MRO.DFU.2 If data to calculate estimates of fuel consumption is available, the MRO, or an approach approved by the Administrator, shall calculate estimates of fuel consumption per each AM reporting period within +/-5% of the actual value.

4.5 Resist Fraud and Tampering (RFT)

A major aspect of electronic security is the MRO’s resistance to fraud and tampering. The MRO shall be designed in a manner that resists tampering or deliberately altering the accumulation of travel data.

Requirement Description

MRO.RFT.1 The BP shall have the ability to detect and record unauthorized access (or attempt to access) to the MRO using mechanisms such as encryption keys, hash codes, and/or intrusion prevention systems.

MRO.RFT.2 If the MRO has multiple sources for the same piece of data, it shall verify that the data sources correspond. For example, if an MRO collects vehicle speed from the vehicle data port and location information via GPS, it shall ensure that the speed value from the data port falls within a reasonable tolerance threshold of the speed value derived from the location data. The tolerance threshold parameter requires approval from the Administrator.

MRO.RFT.3 The MRO shall detect and record when its mechanism to accurately collect required travel data has been compromised. For example, when an OBD II device has been disconnected or when a vehicle telematics subscription has been deactivated.

MRO.RFT.4 The MRO shall determine whether or not it is capturing required travel data for the associated vehicle.

MRO.RFT.5 The MRO shall contain a record of the current hardware and software version. Changes to the MRO hardware or software shall be transmitted to the Data Collection subsystem.

MRO.RFT.6 If a location based MRO employs a connection to a third-party device for obtaining location data, it shall authenticate with the device before transmitting the data.

4.6 Safe and Secure (SS)

The MRO is responsible to secure all data and communications involving any collected travel data.

Requirement Description

MRO.SS.1 The MRO shall not compromise the operation of any original equipment, (from the manufacturer (OEM)) systems or functionality in a vehicle.

MRO.SS.2 The MRO shall not compromise the safety of the operator or passengers of a vehicle.

MRO.SS.3 Physical and logical connections to the vehicle that are required for collecting travel data shall be restricted to only the minimum required for the purposes of collecting RUC.

MRO.SS.4 The MRO shall be certified to be compliant with Title 47 of the Code of Federal Regulations (CFR) and other applicable FCC regulations.

4.7 Transmit Travel Data (TTD)

After verifying the data sources, the MRO will send the travel data to the Data Collection subsystem.

Requirement Description

MRO.TTD.1 The MRO shall send the accumulated travel data or data sufficient to compute accumulated travel data, to the Data Collection subsystem, according to the configured MRO reporting period.

MRO.TTD.2 The MRO shall send error and event log data to the Data Collection subsystem (as defined in the

ICD).

MRO.TTD.3 If the MRO collects data for more than one vehicle, each vehicle’s data shall be delineated when sent to the Data Collection subsystem.

MRO.TTD.4 The MRO shall authenticate with the Data Collection subsystem prior to transmitting data to prevent unauthorized transmissions.

5. Data Collection Subsystem (DC) The Data Collection subsystem is designed to collect travel data from multiple types of MRO technology and store the data for later communication and audits. After storage the Data Collection subsystem creates and transmits a mileage message to the Transaction Processor subsystem.

The Data Collection subsystem is not required to reside in the MRO. Options include:

• Physically locating the Data Collection subsystem directly in the MRO and sending the mileage message to the Transaction Processor subsystem directly from the MRO.

OR

• Implementing the Data Collection subsystem separately, using the MRO to collect travel data and communicate it to the Data Collection subsystem, and the Data Collection subsystem sends the mileage message to the Transaction Processor subsystem.

The Data Collection subsystem shall monitor the MRO functions and accumulated data, detect any anomalies that are indicative of possible tampering or attempted fraudulent alteration of travel data, and record such events in the event logs.

5.1 Receive Data from MRO (RDM)

Requirement Description

DC.RDM.1 The Data Collection subsystem shall have the ability to facilitate the process of data collection, allowing specific, structured information to be gathered in a systematic fashion.

DC.RDM.2 The Data Collection subsystem shall receive, accept and validate data inputs prior to committing the data to storage.

DC.RDM.3 If the Data Collection subsystem receives data for multiple vehicles, it shall maintain the data from each vehicle separately.

DC.RDM.4 The Data Collection subsystem shall authenticate with the MRO prior to receiving transmitted data to prevent unauthorized transmissions.

21 Oregon Department of Transportation

5.2 Differentiate Travel Data (DTD)

Requirement Description

DC.DTD.1 The Data Collection subsystem shall report the miles traveled by the applicable Rule ID/SubRule ID.

DC.DTD.2 The Data Collection subsystem shall compute the fuel usage according to the fuel use method value and report it by the applicable Rule ID/SubRule ID.

FuelUseMethod as described in the ICD:

• 1 = Actual fuel use expected but not captured, calculated by using EPA

• 2 = Actual fuel use captured and used for calculation

• 3 = Fuel use calculated by using EPA

• 4 = Fuel not taxable

For FuelUseMethod value 1 or 3, use this for the fuel usage calculation:

Count of Miles / EPA combined MGP Rating = Fuel Usage

5.3 Configurable Parameters (CP)

Requirement Description

DC.CP.1 The system shall allow for the following configurable parameters at a minimum:

• Communications address of the Transaction Processor subsystem

• Data Storage period

• Rule ID/SubRule ID mapping

DC.CP.2 Data for each vehicle must be reported from the Data Collection subsystem to the Transaction Processor subsystem at least once per quarterly reporting period in the mileage message, as defined by the ICD.

5.4 Handle Errors and Events (HEE)

Requirement Description

DC.HEE.1 The Data Collection subsystem shall have a system uptime of 99.99%.

DC.HEE.2 The Data Collection subsystem shall store and transmit any Disconnect events with MRO Health Code 3 to the Transaction Processor subsystem via the mileage message, and associate any such events with the applicable vehicle and MRO ID.

Disconnect The DC has received information from the MRO, directly or indirectly, that indicates the MRO is not able to send data to the DC. This is to communicate the discovery by the DC that an MRO cannot report required data.

DC.HEE.3 The Data Collection subsystem shall store and transmit any Reconnect events with MRO Health Code 4 to the Transaction Processor subsystem via the mileage message, and associate any such events with the applicable vehicle and MRO ID.

Reconnect After receiving a disconnect event (defined above), the DC received information, directly or indirectly, that indicates the MRO has re-established the ability to report data to the DC. All Reconnect events must be preceded by a Disconnect event. This is to communicate the resolution of the disconnect event.

DC.HEE.4 The Data Collection subsystem shall store and transmit any reporting for New Vehicle Health Code 5 to the Transaction Processor subsystem via the mileage message, and associate any such events with the applicable vehicle and MRO ID.

New Vehicle The DC received the first indication, directly or indirectly, from the MRO that data is being collected and sent to the DC. This is the activation of the MRO, or the first mileage message received with an MROStatus of 1 (activated).

5.5 Create and Send Mileage Message (MM)

Requirement Description

DC.MM.1 The mileage message shall be created from the accumulated data received from the MRO and data created in the Data Collection subsystem, and conform to the specifications detailed in the ICD.

DC.MM.2 The mileage message shall reflect all event conditions reported by the MRO and determined by the Data Collection subsystem during the DC reporting period in the mileage message.

DC.MM.3 All mileage messages with travel data shall be transmitted to the Transaction Processor subsystem.

DC.MM.4 The Data Collection subsystem shall ensure that there is no overlap in the date and time between sequential reporting mileage messages.

DC.MM.5 The Data Collection subsystem shall ensure that each acknowledged mileage message sent has a unique Message ID.

DC.MM.6 The Data Collection subsystem shall accept an acknowledgement message from the Transaction Processor subsystem that includes the Message ID of the mileage message received.

DC.MM.7 The Data Collection subsystem shall include travel data for mileage messages that are not acknowledged by the Transaction Processor subsystem with the next scheduled mileage message transmission.

DC.MM.8 For purposes of reporting miles traveled by day, a day shall be defined as 12:00:00 am to 11:59:59 pm UTC.

DC.MM.9 If the distance traveled reported by the MRO is not reported in miles, the Data Collection subsystem shall use the unit of measure reported by the MRO to convert the distance traveled into miles with 99.99% accuracy.

6. Transaction Processor Subsystem (TP) The Transactions Processor subsystem receives mileage messages from the Data Collection subsystem, calculates the RUC, stores the messages, and transmits the mileage message to the Account Management subsystem.

The Transactions Processor subsystem performs these primary tasks:

1. Receive mileage information (mileage messages) from the Data Collection subsystem

2. Validate mileage messages and handle errors and events

3. Calculate and round the road usage charge

4. Store and send the travel and configuration information to the Account Management subsystem

6.1 Receive Mileage Message (RMM)

Requirement Description

TP.RMM.1 The Transaction Processor subsystem shall have the ability to collect, store, modify and…