WO2015081340A2 - Système de péage - Google Patents

Système de péage Download PDF

Info

Publication number
WO2015081340A2
WO2015081340A2 PCT/US2014/067938 US2014067938W WO2015081340A2 WO 2015081340 A2 WO2015081340 A2 WO 2015081340A2 US 2014067938 W US2014067938 W US 2014067938W WO 2015081340 A2 WO2015081340 A2 WO 2015081340A2
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
usage
road
data
ive
Prior art date
Application number
PCT/US2014/067938
Other languages
English (en)
Other versions
WO2015081340A3 (fr
Inventor
Otman A. Basir
William Ben Miners
Original Assignee
Ims Solutions Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ims Solutions Inc. filed Critical Ims Solutions Inc.
Priority to CA2932191A priority Critical patent/CA2932191A1/fr
Publication of WO2015081340A2 publication Critical patent/WO2015081340A2/fr
Publication of WO2015081340A3 publication Critical patent/WO2015081340A3/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points

Definitions

  • Road User Charging (RUC) schemes may have one or more of a variety of objectives. These might include: Reduction of congestion, to encourage a shift to other transport modes, emissions reduction, and revenue generation.
  • Time-Distance-Place (TDP) road user charging schemes may have a number of factors that make 100% compliance with the scheme even more difficult to achieve. These factors include:
  • TDP schemes often cover a wide area, on more than just the major roads. Thus it is not realistic to cover all charged roads with on- street compliance checking equipment.
  • a Precision Usage-Based Transportation Infrastructure Charging service includes a powerful dynamic road and infrastructure usage engine that can fairly assess road usage based on any combination of mileage, time of day, vehicle mass, location, road class, defined zones and other relevant parameters.
  • This flexible service leverages detailed vehicle driving information to generate road usage summaries, detailed validation data, and invoices or bills where appropriate.
  • This service applies not only to movement along road networks, but also includes time-based and complex rules that support usage-based charging within parking lots, and usage-based charging based on per-person transportation efficiency and environmental impact. In scenarios where dynamic road tolling services are deployed, rules can be introduced to adjust for mass transit.
  • the service enables road tolling as a revenue tool without the need for traditional gantries and their relatively high capital and ongoing operational costs.
  • the precision usage-based transportation infrastructure charging service leverages telematics to precisely assess vehicle location and movements through the road network to generate accurate invoices for each individual.
  • Benefits of this approach include flexible application of rules both up front and throughout its operation. Examples include applying road tolling across all roads in a geographical area, application to only specific roads or road classes at specific times of day, and significantly more complex schemes to meet the unique needs of road tolling programs.
  • the entire road network can be tolled using this service, including accurately differentiating between in-state and out-of-state travel, in addition to separating between private and public roads.
  • Invoice generation is integrated to charge each vehicle owner fairly based on their use of the public road network.
  • the precision usage-based road charging system can also be applied to both existing and new parking facilities to enable usage-based charging services that ensure travelers are charged fairly for their use of the parking infrastructure.
  • This parking service is designed to deliver a seamless and convenient traveller experience while quickly and conveniently transitioning to or from mass transit.
  • This Usage-Based Parking service includes a suite of reports, alerts, and monitoring tools to enable the rapid deployment of services across existing and new parking facilities. With this service, commuters can simply drive into the parking lot and enter into a building, board a train, or use another mode of transportation. No additional steps are introduced to ensure the time between modes of transportation is kept to an absolute minimum.
  • This expedient transition is very important to ensure the driver remains focused on their journey, and does not need to be delayed or interrupted to wait in line for conventional tickets obtained from kiosks and placed on the dashboard. If the traveller is interested, online and mobile interfaces are used to access parking history, current charges, and to deliver relevant insights or constructive feedback.
  • a system objectively assesses transportation infrastructure usage by measuring or obtaining one or more parameters describing vehicle usage, driving, vehicle occupants, environmental, and infrastructure impact.
  • the transportation infrastructure usage assessment may be configurable before and/or after deployment to assess usage using static or dynamic rules.
  • the vehicle driving information may include, but is not restricted to, idling time, emissions, mileage, time of day, vehicle mass, location, road class, vehicle class, and defined zones.
  • the road usage information may be transformed into a usage fee or toll. Fees may include, but are not restricted to, flexible gantry-free road tolling, precision road usage fees, and seamless and expedited parking.
  • the usage fees for services may be delivered to the vehicle owner by generating transportation infrastructure usage summaries, detailed validation data, and invoices/bills with objective evidence to support each usage fee.
  • the individual usage information is validated using aggregate vehicle movement information, vehicle movement information from vehicles in close proximity to the vehicle in question, and/or infrastructure reference points.
  • the precision road usage fee can be applied on individual lanes or lane segments. Precision road usage fees are realized by identifying individual lanes using precise absolute and/or relative location data and computing fees using static or dynamic rules.
  • the rules may include the total number of occupants within the vehicle.
  • the dynamic road usage fee computation rules may include exceptions for emergencies and emergency vehicles (police, ambulance, firetruck, towtruck).
  • the dynamic rules may include time- varying parameters such as traffic congestion peak times, and recent traffic load estimates.
  • the precision location information may obtained through augmenting vehicle location observations with relevant information from one or more external sources including, but not restricted to, satellite and terrestrial data sources, internal vehicle movement sensors, and high-precision 3-axis accelerometers.
  • the expedited parking service may be realized through identifying the time and duration where the vehicle location rests within known parking zones and applying static or dynamic parking fee rules.
  • the static parking fee rules may be those which are provided a priori for one or more parking zones/lots based on time of day, road class, season, and vehicle size.
  • the dynamic parking fee rules may include a factor to compensate for (or encourage) the use of mass transit.
  • a system validates road usage compliance by automatically obtaining and cross referencing license plate details on restricted use lanes against location data reported from the vehicle.
  • the flow of goods may be optimized throughout a transportation network by dynamically adjusting transportation infrastructure usage fees with the intent of modifying driving patterns.
  • the system may dynamically create, remove, or expand dedicated restricted-use lanes (i.e. HOT lanes) to optimize the flow of traffic based on historical, current, and predicted vehicular travel.
  • restricted-use lanes i.e. HOT lanes
  • the system may minimize aggregate emissions by dynamically adjusting transportation infrastructure usage fees to influence transportation decisions.
  • the transportation infrastructure usage fee information may be conveyed to the traveller as an estimated total journey cost during route planning and/or dynamically while in transit.
  • the number of occupants may be manually specified for each journey.
  • the number of occupants may be automatically determined using an occupant detection system.
  • the occupant detection system obtains cues from one or more personally identifiable sources to infer total occupants and/or the identity of occupants.
  • Sources may include the presence of phones, RF emitting devices, and/or passive RFID elements within personal items (i.e. credit cards).
  • the transportation infrastructure impact may be delivered to the traveller in advance of, or during the planning of their journey to support informed travel decisions based on expected infrastructure usage charges, environmental impact, travel time, and other characteristics.
  • the fee rules may be structured in the form of virtual gantries to simulate the same behavior as traditional gantry-based road tolling.
  • the most likely number of occupants may be determined based on context, location, or historical usage patterns.
  • the default number of occupants can be specified in advance, and overridden as required on a journey by journey basis.
  • the number of occupants can be specified as one, two, or more.
  • Figure 1A is a schematic of telematics hardware that could be used to implement the road tolling system.
  • Figure IB is a schematic of a security implementation of the road tolling system.
  • Figure 2 is a schematic of roadside compliance checks for the road tolling system.
  • Figure 3 is a schematic of the road tolling system.
  • Figure 4 is a schematic of the telematics platform major components.
  • Figure 5 schematically shows the data flow of the telematics platform.
  • Figure 6 schematically shows the telematics platform architecture.
  • Figure 7 shows example charging and billing schemas.
  • Figure 8 shows access to the Road User data storage through a secure web portal.
  • Figure 9 shows example charge processing.
  • Figure 10 shows example charging and billing schemas.
  • Figure 11 shows an example scheme 1 travel pattern.
  • Figure 12 shows an example scheme 2 travel pattern.
  • Figure 13 shows an example of charge classes.
  • a motor vehicle 10 includes a plurality of data gathering devices that communicate information to an appliance (IVE) 12 installed within the vehicle 10.
  • the example data gathering devices include a global positioning satellite (GPS) receiver 14, a three-axis accelerometer 16, a gyroscope 18 and an electronic compass 20, which could be housed within the appliance 12 (along with a processor and suitable electronic storage, etc. and suitably programmed to perform the functions described herein).
  • GPS global positioning satellite
  • Data may also be collected from an onboard diagnostic port (OBD) 22 that provides data indicative of vehicle engine operating parameters such as vehicle speed, engine speed, temperature, fuel consumption (or electricity consumption), engine idle time, car diagnostics (from OBD) and other information that is related to mechanical operation of the vehicle.
  • OBD onboard diagnostic port
  • any other data that is available to the vehicle could also be communicated to the appliance 12 for gathering and compilation of the operation summaries of interest in categorizing the overall operation of the vehicle. Not all of the sensors mentioned here are necessary, however, as they are only listed as examples.
  • the appliance 12 may also include a communication module 24 (such as cell phone, satellite, wi-fi, etc.) that provides a connection to a wide-area network (such as the internet).
  • a communication module 24 such as cell phone, satellite, wi-fi, etc.
  • the communication module 24 may connect to a wide-area network (such as the internet) via a user's cell phone 26 or other device providing communication.
  • the in vehicle appliance 12 gathers data from the various sensors mounted within the vehicle 10 and stores that data.
  • the in vehicle appliance 12 transmits this data (or summaries or analyses thereof) as a transmission signal through a wireless network to a compliance back-office application on a server 30 (also having at least one processor and suitable electronic storage and suitably programmed to perform the functions described herein).
  • the server 30 utilizes the received data to determine where and how the vehicle 10 is being driven. For example, driving events and driver behavior are recorded by the server 30, such as fuel and/or electricity consumption, speed, driver behavior (acceleration, speed, etc.), distance driven and/or time spent in certain insurance-risk coded geographic areas, distance drive and/or time spent/time of day/day of the week on certain roads or lanes, etc.
  • the on-board appliance 12 may record the amount of time or distance in high- risk areas or low-risk areas, or high-risk vs. low risk roads.
  • the on-board appliance 12 may collect and transmit to the server 30 (among other things mentioned herein): Speed, Acceleration, Distance, Fuel consumption, Engine Idle time, Car diagnostics, Location of vehicle, Engine emissions, etc.
  • the server 30 includes a plurality of profiles 32, each associated with a vehicle 10 (or alternatively, with a user).
  • the profiles 32 each contain information about the vehicle 10 (or user) including some or all of the gathered data (or summaries thereof), payment information, payment history, etc. Some or all of the data (or summaries thereof) may be accessible to the user via a computer 31 over a wide area network (such as the internet) via a portal, such as fuel efficiency, environmental issues, location, maintenance, etc. The user can also customize some aspects of the profile 32.
  • the server 30 may be numerous physical and/or virtual servers at multiple locations.
  • the server 30 may collect data from appliances 12 from many different vehicles 10 to use the Road Charging Scheme.
  • the server 30 permits each user/owner to access only his own profile 32 and receive information based upon only his own profile 32.
  • the server 30 may not only reside in traditional physical or virtual servers, but may also coexist with the on-board appliance, or may reside within a mobile device. In scenarios where the server 30 is distributed, all or a subset of relevant information may be synchronized between trusted nodes for the purposes of aggregate statistics, trends, and geo- spatial references (proximity to key locations, groups of drivers with similar driving routes).
  • the present system provides roadside compliance checks.
  • RSE roadside equipment
  • DSRC - the IVE 12 would normally have a facility to respond to interrogation by a DSRC system with a specific compliance checking message.
  • the system may also include an Automatic Number Plate Recognition (ANPR) system 38 having a camera for reading the vehicle license plate. This of course relies on the security of the vehicle number plate.
  • ANPR Automatic Number Plate Recognition
  • Vehicle classifier The benefit or use of a vehicle classifier depends very much on the details of the scheme. If there are different charges or exemptions for different classes of vehicles, and these classes can be detected by some sort of on-road measurement, then a classifier provides a useful cross-check to other data.
  • the present system links all of the above data from the same vehicle 10 together, with a very high degree of accuracy. For some types of roadside equipment 36 and traffic conditions, this may be quite challenging. It is usually necessary in high traffic flow conditions to have some sort of spatial overlap between the capture zones of the three types of equipment.
  • Roadside compliance checking equipment may take several forms: [0076] Fixed equipment - mounted on a gantry or pole. All of the above equipment is mounted over the lane(s) to be monitored. System is unattended in use.
  • Transportable equipment as fixed equipment, but demountable to move from site to site. This could also cover trailer-mounted equipment. Again, system is unattended in use.
  • Mobile equipment this is equipment that is vehicle-mounted, and is used either while the vehicle is moving, performing checks on other moving vehicles, or may also be used while the vehicle is stopped at the roadside, for checking passing vehicles. System is attended in operation.
  • Hand-Held equipment this is equipment for a compliance officer on foot to conduct compliance checks on a stationary vehicle. This could be in parking lots, or as a part of a stop-team operation (see below).
  • Stop-team equipment if it envisaged to run stop teams to stop a targeted or random selection of vehicles, consideration needs to be given to equipment they might need to select suspicious vehicles, and what they would do after vehicles are stopped.
  • a compliance back office system is essential for any compliance system. This may be a part of the wider charging and payments back office on server 30, or a separate, but linked system. Functions might include: Monitoring and control of all road side equipment 36, automatic number plate recognition 38. Reception and processing of events data from IVE 12. Reception and processing of data from the road side equipment 36. Holding and updating various databases used for data mining cross-checks.
  • Any TDP charging scheme relies very heavily on the basic security of the IVE 12.
  • a range of safeguards and security features are integrated within the IVE 12, from power interruption through to data integrity measures and movement detection.
  • Features included in IVE 12 units include:
  • SIM card e.g. communication device 24; Figure 1
  • the removal or replacement of a SIM card is detected by the IVE 12 and logged as a tamper event.
  • the IVE 12 s paired with a specific SIM card during provisioning and deployment. Any discrepancies between the IVE 12 serial number and the SIM card are logged for further analysis. This information will be queued for transmission to the back office systems once the original SIM card is re-inserted.
  • a virtual-private-network is used to maintain transport security between the IVE 12 and the back office systems 30. This approach leverages a mature and proven encrypted tunnel to deliver information between the IVE 12 and back office systems 30 without intermediate eavesdropping or tampering opportunities.
  • Positional and vehicle information is collected and stored in a manner to ensure internal adjustments to individual data elements are detected. Over time, additional positional and vehicle information is stored in separate segments or blocks. Each block is associated with its predecessor and successor to help ensure all blocks are successfully transmitted and received. Missing blocks are reliably detected, in addition to missing or tampered elements within blocks.
  • the IVE 12 automatically powers up when movement is detected (e.g. by accelerometers 16). This feature ensures the IVE 12 continues to collect relevant positional and vehicular information even if a method is employed to tamper with the power signal to prevent reliable ignition detection / engine running.
  • Active antennas are deployed with the IVE 12, allowing the presence or absence of an antenna to be detected. If an antenna is removed or disconnected, the time and approximate location of the disconnect and subsequent reconnect is logged for future analysis. Shielded or blocked antennas are detected using alternate complementary sources of information (e.g. accelerometer 16 and OBD-II 22) [0099] Accelerometer
  • the 3D accelerometer 16 is available for a range of applications, including waking up the IVE 12 when motion is detected. When combined with the power signal analysis to determine engine status and positional sensors, the additional accelerometer information provides a secondary source to identify: Vehicle movement without engine running (vehicle towing / stolen vehicle) or Vehicle movement with jammed / blocked GPS 14 signal.
  • Information from the OBD-II 22 interface provides complementary information to augment existing GPS 14 and accelerometer 16 sensors within the IVE 12.
  • the additional OBD-II 22 information provides another reference to verify consistency and validity of sensor information.
  • An internal battery is designed into specific variants of the ⁇ 12 to support data collection and event generation even while disconnected from the vehicle 10. This feature is valuable to characterize behavior after removal from the vehicle 10, or while attempted fraudulent activity is in progress.
  • Hybrid Internal / External Antennas are designed into specific variants of the ⁇ 12 to support data collection and event generation even while disconnected from the vehicle 10. This feature is valuable to characterize behavior after removal from the vehicle 10, or while attempted fraudulent activity is in progress.
  • a variant of the IVE is planned with multiple antennas (both internal and external). Use of multiple antennas is valuable to ensure GPRS connections and GPS reception is possible even if a portion of the available antennas are blocked or shielded. The switching between internal and external antennas will be handled automatically by the embedded software residing on the IVE. Events that may require a switch between the external and internal antenna may include the removal or shield of the external antenna, tampering of external antenna or the malfunction of either antenna.
  • the GPS receiver 14 is capable of detecting jamming.
  • Jamming is usually defined as a RF signal that either intentionally or unintentionally interferes with the reception of GPS signals.
  • the GPS receiver's sensitivity and filtering can help overcome interfering RF signals and allow the reception of GPS signals necessary to provide navigational data.
  • Event messages sent over the normal long-range communications system 24 (GPRS or similar). This of course relies on that communication channel being open, and not in itself subject to tampering. Error status within a DSRC transaction seen by roadside equipment 36. This of course requires the vehicle 10 to pass such equipment. As each method has shortcomings, the combination of both techniques is the optimal solution.
  • IVE Power supply is 1. No IVE ANPR read for non- Faulty IVE disconnected removed from IVE, or detected when exempt vehicle with
  • Accelerometer Event logged that Low GPS signal e.g. / speed detection speed / accelerometer in an underground car movement detected park.
  • distance travelled is less 2. Minimum If a vehicle is seen at Faulty IVE (but than reality. distance check several enforcement unlikely).
  • CBO to CBO Availability of MOT odometer Sources of alternative data may checks ("data new data. comparison to charge be more for commercial trucks Mining") Periodic random records. than for private vehicles. For checking example additional data may be available from VOSA for these vehicles, also delivery route and destination details may be available.
  • the stopping officer may be able to gather further evidence by inspection of the vehicle or installation;
  • the address of the vehicle owner is unknown (e.g. not correctly registered with DVLA, or could be an overseas vehicle); or
  • the owner has not paid existing penalties.
  • IVE 12 may use either a 'thin client' or 'smart client' approach. Each approach offers different opportunities and problems in compliance checking and enforcement.
  • COLLECTING DATA the DriveSyncTM or Smartphone GPS antenna in the vehicle receives signals from the Earth's system of satellites and passes this positional data to the DriveSyncTM telematics hub for processing, storage and management.
  • TRANSFERRING DATA At regular predefined intervals, the DriveSyncTM telematics hub uses cellular wireless networking to seamlessly upload (transfer) the accumulated encrypted (256 bit AES) trip data to the DriveSyncTM server for compiling into a variety of reports and maps.
  • the DriveSync Telematics platform consists of the following major functional components:
  • DriveSync On-Board Unit (OBU / IVE 12) - a device installed in road user vehicle which is responsible for collecting data from a number of sensors and interfaces (GPS, accelerometer, anti-tampering, OBD II) and delivering it to the back office system via wireless link (GSM/GPRS, WiMax or other).
  • GPS Global System for Mobile Communications
  • OBD II OBD II
  • GSM/GPRS Global System for Mobile Communications
  • WiMax Wireless Local Area Network
  • DriveSync Telematics back office module responsible for communication with OBU, as well as all aspects of driving data processing, including: trip generation, GEO coding, event handling, driving reports generation.
  • Charging System module responsible for charge object management, charge calculation and processing, payment processing and revenue sharing.
  • Road Charging Web Portal providing all stakeholders with a user friendly web- based GUI allowing them to access data and features provided by the DriveSync Telematics system.
  • the stakeholders access to the information is regulated in according to their authorization level based on security model configuration;
  • Real-time charge reporting and display module This module allows the user to keep track of road charges as they incur and accumulate.
  • the module can be implemented on an in-vehicle unit, smartphone, or other devices such as desk computers, laptops, notebooks, etc.
  • Identification module with short distance wireless capabilities to enable compliance enforcement.
  • the back office solution provides the following main functionality:
  • OBD II data vehicle diagnostic trouble codes, alerts, Environmental reports, odometer, VRM
  • Event-based data such as: Automatic Vehicle Location (AVL) ping, GEO fence zone crossing event, etc.
  • AOL Automatic Vehicle Location
  • the DriveSync Telematics Platform Overall Architecture [0220] The DriveSync Telematics Platform Overall Architecture [0221] The back office platform handles communication with DriveSync On-Board Units (OBU) installed on road user vehicles.
  • OBU DriveSync On-Board Units
  • the communication with OBU consists of the following types:
  • Driving data collection GPS tracking, acceleration, etc.
  • Event handling (tamper events, power loss, GEO-fence breach, etc.);
  • Device configuration (device profile configuration, GEO-fence setup, etc.);
  • Device communication is bi-directional.
  • the uplink is used to deliver driving data, diagnostics and events to the back office server as well as to deliver response triggered by an interactive feature.
  • the downlink is used for device management and configuration, firmware update and to send interactive feature requests.
  • Data collected from DriveSyncTM OBU by the DriveSync Telematics server is persisted in database and, depending on data type, guided to particular data processing module. For example: collected driving data is used for trip and driving report generation. Generated trip logs and driving reports could be later accessed by all relevant stakeholders (road users, RUSP Customer Support) via web-based GUI (Road Charging Web Portal). Collected driving data is also guided to Charging Rule Engine for charge generation.
  • the Charging Rule Engine generates charges based on collected driving data and a set of Charging Objects (Boundaries and Roads) defined by Charging Schemes. Generated charges are passed to the Billing System Module for charge rate calculation, electronic invoice generation and payment processing.
  • the Billing System module calculates charges based on defined Price Plan.
  • the Price Plan consists of one or more Billing Schemes, each scheme containing a set of Charge Classes with respective rates and rate factors for defined Vehicle, User and Time Classes.
  • Example Charging and Billing Schemas are shown in Figure 7.
  • Management of Price Plan as well as Charge Scheme is done through the DriveSync Telematics platform Road Charging Web Portal and potentially could be delegated to Scheme Owners. New Charge Scheme could also be imported into the system via scheme import facility.
  • Billing System module In addition to charges the Billing System module also performs tax and revenue sharing calculations. Based on pre-defined accounting periods, Billing System module will generate electronic invoices, payment settlement requests and revenue sharing records. Payment settlement requests are handled by the Automated Settlement module which performs payment collection activities via 3 rd party financial institution. For the Road Pricing Demonstration Project, payment settlement and revenue sharing will be done by a means of a simulated system, representing a hypothetical financial institution.
  • the Road Charging Web Portal offers wide range of functionality to all major stakeholders, specifically:
  • KPI Dashboard [0256] Charge Object Management
  • RBS Role Based Security
  • Data communication between OBU / IVE 12 and the back office server is based on a TCP protocol.
  • the first layer of protection is typically handled by a Virtual Private Network (VPN) between communication provider (such as GSM/GPRS provider) and the back office platform.
  • VPN Virtual Private Network
  • the second layer of protection is data encryption which is part of the communication protocol.
  • the encryption is based on AES-256 standard.
  • Telematics back office platform has been designed from the ground up as a highly available and fault tolerant system [CAP079] .
  • CAP079 fault tolerant system
  • the system utilizes exiting wireless networks such as GPRS, 3G, LTE and Wi- Fi for data transmission.
  • Data frequency transmission can be configured so as to manage realtime billing and data transmission cost. When not in wireless coverage area, all driving information is still stored, but would only be transferred when in coverage.
  • Access to the secure Road User Personal Information through the secure web portal, shown in Figure 8, is an optional service.
  • RU Personal Information will be transferred in batch file nightly to the Scheme Owner.
  • the system will present the detailed trip information for all trips taken on a daily basis, with the associated details.
  • the Road User will have two views to review the data and be able to quickly note trips that they want to dispute/contest.
  • the driving data will be pulled up once per day, at various times depending upon the individual RU driving and nightly garage pattern (i.e. covered garage out of GSM coverage)
  • the main trip listing would be noted as a 'chargeable trip.'
  • the icon denoting the chargeable trip, or switching views to the Billing module the user would be able to see the details of the billing that affected that trip.
  • the user could click on the appropriate navigation icon to display a Google map that would show the trip from start to stop.
  • the system would receive information in two ways; with our connection directly to the vehicles computer system (through the OBDII connection), for most cars (2002 & newer) we can read the odometer directly from the car; the second system would ask for periodic updates from the Road User as to the actual mileage showing on the cars odometer. These update requests would occur as pop-ups after a RU has signed onto the secure portion of the reporting web site.
  • the Road Users would receive their monthly incentive of Loyalty points for their weekly review of the billing statement and input of their odometer. This input can be verified against actual readings IMS pulls from the OBDII port where available.
  • the system uses two redundant systems for reporting distance traveled - one based on GPS positional readings and the other using vehicle odometer readings from the On- Board-Diagnostic (OBD II) Adaptor. Not all vehicles will require a redundant OBDII system for measuring distance traveled but it is expected that the percentage using this feature will validate the accuracy of the overall system on an ongoing basis. When available the system will combine GPS with odometer to enhance accuracy.
  • OBD II On- Board-Diagnostic
  • Vehicle position is derived from the latitude and longitude reported by a GPS receiver residing on the OBU.
  • the GPS receiver reports the latitude and longitude of the vehicle once per second to an accuracy of 5m.
  • the GPS receiver first acquires or reacquires the vehicle's position, the latitude and longitude of this position are recorded. This recorded latitude and longitude becomes the reference vehicle position.
  • the OBU embedded software then tracks the vehicle through a virtual grid of approximately 10m x 10m: Latitude (North-South) 11.1m and Longitude (East- West) 6.1m. These are consolidated into 'zones' measuring 12.2m East-west and 22.2m North-South using the coordinates reported by the GPS receiver. When the vehicle passes through one of these zones in a north, east, south or west direction or some combination of these directions, a record is stored containing an incremented value representing the relative change in vehicle position. The new reference position becomes the south-east corner of the new zone entered.
  • a running total of the distance traveled by the vehicle from the time of the last recorded position to the time at which the zone change is position-detected is accumulated by the OBU using the data derived from the GPS receiver.
  • This recorded data representing the vehicle's position is transferred from the OBU to the server applications and decoded to recover distance traveled by the vehicle for reporting purposes. Specifically, the recorded accumulated distance based on positional changes at the time of zone crossings is used to calculate the total distance traveled by the vehicle.
  • the OBD II interpreter used by IMS Inc. gathers date from the vehicle odometer to provide a report of the distance traveled by the vehicle independent from the GPS receiver. This distance reported by the OBD II interpreter will be used to validate the distance traveled measured by the GPS-based applications.
  • Vehicle position is derived from the latitude and longitude reported by a GPS receiver residing on the OBU.
  • the GPS receiver reports the latitude and longitude of the vehicle once per second.
  • the GPS receiver first acquires or reacquires the vehicle's position, the latitude and longitude of this position are recorded. This recorded latitude and longitude becomes the reference vehicle position.
  • the OBU embedded software then tracks the vehicle using the coordinates reported by the GPS receiver. As the vehicle passes to the north, east, south or west direction or some combination of these directions, a record is stored containing an incremented value representing the relative change in vehicle position.
  • the new reference position becomes the south-east corner of the new zone entered.
  • a running total of the distance traveled by the vehicle from the time of the last recorded position to the time at which the 20 meter change is position detected is accumulated by the OBU derived from the data reported by the GPS receiver.
  • This recorded data representing the vehicle's position is transferred from the OBU to the server applications and decoded to recover distance traveled by the vehicle for reporting purposes. Specifically, the recorded accumulated distance between 20 meter changes in vehicle position is used calculate the total distance traveled by the vehicle.
  • the OBD II interpreter used by IMS Inc. provides a report of the distance traveled by the vehicle independent from the GPS receiver. This distance reported by the OBD II interpreter could be used to validate the distance traveled measured by the GPS-based applications. [CAP015] This can be used by the Compliance and Assurance contractors to validate the actual distance traveled, against the calculated GPS position.
  • Driving data captured by OBU 12 is uploaded to Telematics server for further data processing.
  • the Telematics module performs several data processing steps, including trip generation and reverse GEO coding.
  • Example Charge Processing is shown in Figure 9. Based on collected driving data and Charge Objects (Boundaries and Roads) defined by Charging Schemes the Charging Rule Engine generates chargeable events [CAPO 14] corresponding to various driving activities, such as: distance driven within a chargeable object [CAPO 16], entry charge [CAP020], exit charge [CAP021], etc.
  • DriveSync OBU reports driving data (such as driving distance) in metric units, however, Charging Rule Engine has capability to convert units to a different system, in accordance with the UK derogation on road signs for example [CAPO 17].
  • Example Charging and Billing Schemas are shown in Figure 10.
  • the requirement to handle a minimum distance for charging [CAP022] will be implemented by means of stepped rating. Stepped rating allows applying variable rates based on the amount of consumed units. For example: rate distance at $0.01/mile for initial 10 units (miles), then change rate to $0.02/mile for a number of units (miles) between 10 and 50 and then use rate $0.03/mile for anything above 49 miles.
  • Taxation engine performs tax calculation for all charges produced by the Rating module. All charge records are persisted in database as billing data which is used for electronic invoice generation as well as for various reports.
  • Billing data is also used for payment settlements generation and for revenue sharing. Based on pre-defined accounting periods, the Billing System module will generate electronic invoices, payment settlement and revenue sharing records. Payment settlement is handled by the Automated Settlement module which performs payment collection activities via 3 rd party financial institution. For the Road Pricing Demonstration Project, payment settlement and revenue sharing will be done by a means of a simulated payment processing system, representing a hypothetical financial institution.
  • Electronic invoices as well as settlement and revenue sharing reports could be accessed by respective stakeholders via Road Charging Web Portal, or files transferred by XML.
  • the Billing system module does offer a capability to calculate charges in pounds Sterling.
  • the Charging Rules engine will define the charge to be applied to each Charge Class which could consist of one or both of Nominal tariffs applied to Reported Distances, or as modified by the appropriate factors for use, vehicle and time class, and/or for Entry / Exit charges, which may be dependent on the user, vehicle and time classes of the event.
  • One of the main principals of the proposed system is to show the value to consumers for using other Telematics functionalities, so consumers will want to put such technology in their vehicles. As such, as part of the sign-up process to participate in the initial program, consumers will be notified and give permission to share their driving data in exchange offers and LBS marketing information. Consistent with Privacy Policy, consumers can withdraw their consent at any time and be opted out of the program as well.
  • the system offers a peer reporting tool to show the RU the comparison of their driving habits against their peers in the demonstration program. This is currently done for attributes such as; speed, time of day, aggressive driving behaviours (acceleration / deceleration), cornering, anticipation.
  • attributes such as; speed, time of day, aggressive driving behaviours (acceleration / deceleration), cornering, anticipation.
  • the system displays content titles on the right navigation of the reporting suite that are dynamically driven with respect to the implications of the various driving behaviours shown on the left. The concept is to highlight to drivers the implications of their driving without the 'gotcha' aspect of the reporting.
  • the system will provide a capability to supply Charge Statements to each Road User for all charges incurred in all Schemes.
  • Each Charge Statement should contain the following:
  • the system will offer as an optional capability the option of itemized detail in a Charge Statement, such as individual Charge Record details or analysis of Charge Objects over time, time classes during accounting periods, etc.
  • Notification through in- vehicle devices or smartphones will allow RU's to know in real-time the implications of traveling on various roads or cordon areas as they drive.
  • the system will push down to our IVE the parameters for the Charge Objects and hence be able to notify and display the current charges for that specific trip (estimated only) right on the device display.
  • an information bubble is located beside the field to allow the user to understand why the information is being requested and how it will be used. This also builds trust as the disclosure level is usually higher than most data collection or registration sites that put usage statements only in legal copy.
  • a multi-step registration process to collect the necessary data also allows for a greater completion percentage of those consumers interested. After the data has been collected a confirmation of data is requested which allows the user to review and or edit data that has been input. Upon completion, a screen message setting next step expectations is displayed and emailed to the interested party.
  • the portal will allow participants to manage their account and make any administrative changes to their profile. Through the portal, the participant can:
  • the user while online verifying the individual charge records, can simply click on an input box next to the charge summary. This allows a dynamic record to be created with the relevant charge data reference number attached, and an opportunity for the RU to input commentary to explain why they are disputing the charge.
  • the email tracking system logs the Dispute and will track responses and response time for KPI measurement.
  • the system gathers positive consent (versus implied consent) to use personal and driving information to receive value-added marketing offers and services.
  • positive consent to use personal and driving information to receive value-added marketing offers and services.
  • RU Road User
  • they will have to review and make a positive consent action to agree to the Confidentiality Agreement and Consent form as a Road User.
  • the system takes extra steps to ensure strong data protection for Personal Information. This is accomplished by separating the driving data / trip data, from the Personal Information. In this way, if the system is ever successfully hacked, the person would only have access to driving data that could't be attributed to any individual.
  • Measures ensuring data security include:
  • IMS DriveSync Telematics back office platform is based on a 3-tier architecture providing enhanced security by physically separating database, application and Web front-end layers;
  • DriveSync OBU and DriveSync Telematics back office platform communication is encrypted (AES-256 encryption);
  • Private Road User information is stored outside of the main database in LDAP Directory, driving data stored in the main database is depersonalized in order to enhance privacy protection;
  • Network and system monitoring tools are used for intrusion detection as well as to watch for suspicious activities
  • Scheme 1 Travel Pattern is shown in Figure 11. Based on the assumptions listed above, each of the users will produce two distance-based charge records and four event- based Charge Records (two entry and two exit records) per 24 hours.
  • Telematics platform supports multiple charge classes as defined by the "Scheme Template Guidance" document. Requested charge classes, time classes, user classes and vehicle classes are supported by the DriveSync Telematics platform Billing Module.
  • Example Charge Classes are shown in Figure 13.
  • the Telematics Platform does not imply any limitations regarding the number of supported Schemes other than system performance. The anticipated number of Schemes and Charge Objects used in the Road Pricing Demonstrations Project should not be causing any performance issues.
  • the Telematics back office platform is designed as a horizontally scaleable system and takes advantage of clustering on all layers of the application which allows managing platform capacity growth in a cost efficient manner.
  • the solution can support up to Max (currently 10) Schemes operating simultaneously within each Demonstration. Each Scheme to be tested individually and working in combination with other Scheme Templates provided.

Landscapes

  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Traffic Control Systems (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)

Abstract

Cette invention concerne un service de tarification de précision pour infrastructures de transport basé sur l'utilisation, comprenant un moteur dynamique d'utilisation des routes et infrastructures qui peut estimer équitablement l'utilisation des routes sur la base de n'importe quelle combinaison comprenant le kilométrage, le moment de la journée, la masse du véhicule, l'emplacement, le type de route, les zones prédéfinies et autres paramètres pertinents. Ledit service flexible associe des informations détaillées de conduite de véhicule pour générer des résumés d'utilisation de route, des données détaillées de validation et des factures si nécessaire. Ledit service ne concerne pas uniquement le déplacement le long des réseaux routiers, mais il comprend également des règles complexes basées sur le temps qui supportent une facturation basée sur l'utilisation dans les parcs de stationnement, ainsi qu'une facturation basée sur l'utilisation sur la base de l'efficacité de transport des personnes et de l'impact environnemental.
PCT/US2014/067938 2013-11-29 2014-12-01 Système de péage WO2015081340A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA2932191A CA2932191A1 (fr) 2013-11-29 2014-12-01 Systeme de peage

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201361910183P 2013-11-29 2013-11-29
US61/910,183 2013-11-29

Publications (2)

Publication Number Publication Date
WO2015081340A2 true WO2015081340A2 (fr) 2015-06-04
WO2015081340A3 WO2015081340A3 (fr) 2015-08-27

Family

ID=52118018

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/067938 WO2015081340A2 (fr) 2013-11-29 2014-12-01 Système de péage

Country Status (2)

Country Link
CA (1) CA2932191A1 (fr)
WO (1) WO2015081340A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10964207B2 (en) 2018-11-19 2021-03-30 Fortran Traffic Systems Limited Systems and methods for managing traffic flow using connected vehicle data

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7215255B2 (en) * 2003-01-21 2007-05-08 Bernard Grush Method and apparatus for a satellite positioning-based metering system for use in transport-related applications
GB2451167A (en) * 2007-07-16 2009-01-21 Charles Graham Palmer Separation of cost calculation means and payment services in a Position-Based Charging system.
FR2969357B1 (fr) * 2010-12-17 2013-06-14 Nomadic Solutions Systeme et procede de gestion de covoiturage
US10339724B2 (en) * 2011-07-26 2019-07-02 United Parcel Service Of America, Inc. Methods and apparatuses to provide geofence-based reportable estimates

Also Published As

Publication number Publication date
WO2015081340A3 (fr) 2015-08-27
CA2932191A1 (fr) 2015-06-04

Similar Documents

Publication Publication Date Title
US20220092884A1 (en) Road tolling
US20210049725A1 (en) Vehicle traffic and vehicle related transaction control system
US20210183175A1 (en) System of privacy oriented automated electric vehicle miles traveled usage fee assessment and settlement using utility smart grid communication network
AU763951B2 (en) The traffic information and pricing (TIP) system
CN101911130B (zh) 道路收费系统
JP4167490B2 (ja) 道路通行料徴収システム
EP1993076B1 (fr) Evaluation de péage routier
EP2193504B1 (fr) Système de péage routier
EP3507763A1 (fr) Système, procédé et dispositif pour la gestion de mobilité personnelle à assistance numérique
US20120215594A1 (en) System and method for gps lane and toll determination and asset position matching
EP2390861B1 (fr) Procédé et système de contrôle de trafic et contrôle d'émission de trafic
US9934682B2 (en) Systems and methods for monitoring roadways using magnetic signatures
US20220020229A1 (en) System and method for mobile toll calculation and payment
US10672266B2 (en) Systems and methods for monitoring roadways using magnetic signatures
Forkenbrock et al. A new approach to assessing road user charges
Arneodo et al. Towards a “Smart Region” paradigm: Beyond Smart Cities borders: Piedmont Region experience
WO2015081340A2 (fr) Système de péage
Patil et al. Smart Toll Booth System Using Smart Contract
Donath et al. Technology enabling near-term nationwide implementation of distance based road user fees
Bandi et al. CV2X-PC5 Vehicle Based Tolling Transaction System
Ungemah et al. Colorado mileage-based user fee study.
EP4372702A2 (fr) Systeme et procede permettant de reduire la charge de traitement sur des serveurs de fond dans un systeme echelonne par miles de vehicule
US20230056836A1 (en) System and method to preserve user's privacy in a vehicle miles traveled system
Bomberg et al. Mileage-based user fees: defining a path toward implementation phase 2, an assessment of technology issues
GB2617461A (en) Road user charging

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14815168

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase in:

Ref document number: 2932191

Country of ref document: CA

NENP Non-entry into the national phase in:

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 071016)

122 Ep: pct application non-entry in european phase

Ref document number: 14815168

Country of ref document: EP

Kind code of ref document: A2