Light Vehicle OBE --> Payment Device:
request for payment
Definitions
request for payment (Information Flow): Request to deduct cost of service from user's payment account.
Light Vehicle OBE (Source Physical Object): The 'Light Vehicle OBE' includes traveler-oriented capabilities that apply to passenger cars, trucks, and motorcycles that are used for personal travel. The rules vary by jurisdiction, but generally light vehicles are restricted in their weight and the maximum number of passengers they can carry. In ARC-IT, the Light Vehicle OBE represents vehicles that are operated as personal vehicles that are not part of a vehicle fleet and are not used commercially; thus, the choice between the various vehicle subsystems should be based more on how the vehicle is used than how much the vehicle weighs. See also the 'Vehicle' subsystem that includes the general safety and information services that apply to all types of vehicles, including light vehicles.
Payment Device (Destination Physical Object): The 'Payment Device' enables the electronic transfer of funds from the user of a service (I.e. a traveler) to the provider of the service. Potential implementations include smart cards that support payment for products and services, including transportation services and general purpose devices like smart phones that support a broad array of services, including electronic payment. In addition to user account information, the payment device may also hold and update associated user information such as personal profiles, preferences, and trip histories.
Included In
This Triple is in the following Service Packages:
- PM03: Parking Electronic Payment
- ST06: HOV/HOT Lane Management
- ST10: Low Emissions Zone Management
- TI09: Travel Services Information and Reservation
- TM10: Electronic Toll Collection
- TM11: Road Use Charging
This triple is associated with the following Functional Objects:
- Light Vehicle Basic Toll/Parking Payment
- Light Vehicle Interactive Traveler Information
- Light Vehicle Payment Service
This Triple is described by the following Functional View Data Flows:
- tpd-debited_driver_payment_at_vehicle
- tpd-debited_electric_charging_payment
- tpd-debited_payment_at_parking_lot
- tpd-debited_payment_at_toll_plaza
- tpd-debited_road_use_payment
- tpd-request_electric_charging_payment
- tpd-request_payment_at_parking_lot
- tpd-request_payment_at_toll_plaza
- tpd-request_road_use_payment
This Triple has the following triple relationships:
Relationship | Source | Destination | Flow |
---|---|---|---|
Interactive | Payment Device | Light Vehicle OBE | actuate secure payment |
Communication Solutions
No communications solutions identified.Characteristics
Characteristic | Value |
---|---|
Time Context | Now |
Spatial Context | Adjacent |
Acknowledgement | True |
Cardinality | Unicast |
Initiator | Source |
Authenticable | True |
Encrypt | True |
Interoperability | Description |
---|---|
National | This triple should be implemented consistently within the geopolitical region through which movement is essentially free (e.g., the United States, the European Union). |
Security
Information Flow Security | ||||
---|---|---|---|---|
Confidentiality | Integrity | Availability | ||
Rating | Moderate | Moderate | High | |
Basis | Contains charges and possibly balance or personal information. Charge information may or may not be public, and balance and personal information is not, though it may be displayed visually. Could be LOW if no personal or balance information and no identifier is not included in the flow. | Payment related information needs to be correct or the user may be inconvenienced or defrauded. | Contact/proximity payment mechanisms need to be very reliable or large numbers of users will be inconvenienced and the systems that use these interfaces (transit, parking etc.) will be hamstrung by interface failures. |
Security Characteristics | Value |
---|---|
Authenticable | True |
Encrypt | True |