Procedure and equipment for the safe processing of fuel delivery requirements

Abstract

System that includes the following: a processor (3) designed to to detect the insertion of a fuel nozzle into the refueling channel of a vehicle (31); to wake up a vehicle telematics system in response to the detection; to receive a tanker truck MAC ID and a token (313) from a remote source on the telematics system after waking up; to validate the token (313) and to establish a wireless connection with the received MAC ID after the token (313) has been validated.

Description

TECHNICAL AREA

[0001] The illustrative embodiments generally relate to a method and a device for the safe processing of fuel supply requirements. BACKGROUND

[0002] On many occasions, drivers reach their destination and realize their vehicle's fuel level is low. Stopping at a gas station before leaving can be inconvenient, especially if there are no gas stations nearby. For example, a driver might leave work at 4:00 PM to avoid rush hour traffic and remember their fuel is low, forcing them to refuel and potentially adding to the traffic congestion. In other scenarios, the area around nearby gas stations might be known for a high crime rate or result in another undesirable detour (long distance or travel time, unpaved roads, etc.).

[0003] US Patent 2015 / 0352947A1 discloses a new smart fuel filler cap and a system for an improved refueling system for a vehicle. Specifically, the smart fuel filler cap can communicate with a user's smartphone to generate a refueling order and send it to a fuel service provider. According to some aspects, sensors in the smart fuel filler cap and / or the user's smartphone can be used to input a low fuel level for the refueling order, which can be specific to the vehicle's location. In some embodiments, the ability to determine and utilize the vehicle's location can be used to selectively grant access to an otherwise secure fuel filler cap for refueling.

[0004] Systems and methods for location-based fuel distribution can be derived from US 2014 / 0129379A1. One embodiment is a method for delivering fuel to a vehicle, including a mobile fuel app that registers the vehicle's location and requests the fuel service, a gateway and authentication server, a location server, a dispatch server, a real-time fuel price server, a back-end server, and a database.

[0005] These systems communicate with an application connected to a fuel delivery vehicle, which then distributes and delivers the fuel to the vehicle. Additionally, the back-end server can be configured to bill the customer for the fuel received.

[0006] The dispensing of goods such as bulk liquids, gases, granules, and powders is electronically monitored in accordance with US 4,345,146A by identifying the recipients of the goods with specific codes and correlating these codes with the quantities dispensed by the donors. The specialized equipment includes a passive module attached to the recipient and a reader connected to the donor via a radio transmitter or cable. SUMMARY

[0007] The object of the invention is to simplify and make the refueling process of a vehicle safer. This object is achieved by a system with the features of claim 1. Advantageous embodiments of the invention are specified in the dependent claims and the following description. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows an illustrative vehicle data processing system; Fig. Figure 2 shows an illustrative system for the safe handling of a fuel delivery; Fig. Figure 3 shows an illustrative fuel request process; Fig. Figure 4 shows an illustrative fuel reception process; The Fig. 5A and Fig. Figure 5B shows illustrative connection processes for the tank truck connection. DETAILED DESCRIPTION

[0008] As required, detailed embodiments of the present invention are disclosed here; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which can be implemented in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of certain components. The specific structural and functional details disclosed here should therefore not be interpreted as limiting, but merely as a representative basis for teaching a person skilled in the art how the present invention can be used in various ways.

[0009] Fig. Figure 1 presents an exemplary block topology for a vehicle-based computing system (VCS) for a vehicle 31. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based computing system may include an in-vehicle visual front-end interface 4. The user may also have the ability to interact with the interface, for example, if it is equipped with a touchscreen. In another exemplary embodiment, interaction is achieved through button presses, a voice dialogue system with automatic speech recognition, and speech synthesis.

[0010] At the in Fig. In the exemplary embodiment shown in Figure 1, a processor 3 controls at least part of the operation of the vehicle-based data processing system. The processor, which is located within the vehicle, allows for in-vehicle processing of instructions and routines. Furthermore, the processor is connected to both non-persistent memory 5 and persistent memory 7. In this exemplary embodiment, the non-persistent memory is random-access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-volatile) memory can include any type of storage that retains data when a computer or other device is shut down. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and other suitable types of persistent storage.

[0011] The processor is also equipped with a number of different inputs that allow the user to communicate with it. In this exemplary embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4, which can be a touchscreen, and a BLUETOOTH input 15 are provided. An input selector 51 is also provided to allow the user to switch between different inputs. Inputs to both the microphone and the auxiliary connector are converted from analog to digital by a converter 27 before being sent to the processor. Although not shown, many of the vehicle components and accessories connected to the VCS can use a vehicle network (such as a CAN bus, among others) to send data to and from the VCS (or components thereof).

[0012] Outputs to the system can include, among other things, a visual display 4 and a speaker 13 or a stereo system output. The speaker is connected to an amplifier 11 and receives a signal from the processor 3 via a digital-to-analog converter 9. The output can also be made along the bidirectional data streams shown at 19 and 21, respectively, to a remote BLUETOOTH device such as a PND 54 or a USB device such as a vehicle navigation device 60.

[0013] In one exemplary embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate with a user's mobile device 53 (for example, a mobile phone, smartphone, PDA, or any other device that has wireless connectivity to remote networks) 17. The mobile device can then be used, for example, to communicate with a network 61 outside the vehicle 31 by communicating 55 with a cell tower 57 59. In some embodiments, the tower 57 can be a WiFi access point. The communication between the mobile device and the BLUETOOTH transceiver is represented by the signal 14.

[0014] Pairing a mobile device 53 with the BLUETOOTH transceiver 15 can be initiated by pressing a key 52 or a similar input. Accordingly, the CPU is instructed to pair the onboard BLUETOOTH transceiver with a BLUETOOTH transceiver in a mobile device.

[0015] Data can be transmitted between the CPU 3 and the network 61, for example, using a data plan, data-over-voice, or DTMF tones associated with the mobile device 53. Alternatively, it may be desirable to include an onboard modem 63 with antenna 18 to transmit data between the CPU 3 and the network 61 via the voice band 16. The mobile device 53 can then be used, for example, to communicate with a network 61 outside the vehicle 31 by means of communication 55 with a mobile phone mast 57 59. In some embodiments, the modem 63 can establish communication 20 with the mast 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB mobile modem, and communication 20 can be mobile communication.

[0016] In an illustrative embodiment, the processor is equipped with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the Bluetooth transceiver to establish wireless communication with a remote Bluetooth transceiver (such as one present in a mobile device). Bluetooth is a component of the IEEE 802 PAN (Personal Area Network) protocols. The IEEE 802 LAN (Local Area Network) protocols include Wi-Fi and have considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other communication methods that can be used in this area include free-space optical communication (such as IrDA) and non-standard consumer IR protocols.

[0017] In another embodiment, the mobile device 53 includes a modem for voice band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiplexing can be implemented when the owner of the mobile device can speak through the device while data is being transmitted. At other times, when the owner is not using the device, the data transmission can utilize the entire bandwidth (in one example, 300 Hz to 3.4 kHz). Although frequency division multiplexing may be widespread and continues to be used for analog cellular communication between the vehicle and the internet, it has been largely replaced for digital cellular communication by hybrids of CDMA (code domain multiple access), TDMA (time domain multiple access), and SDMA (space domain multiple access).These are all ITU IMT-2000 (3G) compliant standards, providing data rates of up to 2 Mb / s for stationary or walking users and 385 Kb / s for users in a moving vehicle. 3G standards are now being superseded by IMT-Advanced (4G), which provides 100 Mb / s for users in a vehicle and 1 Gb / s for stationary users. If the user has a data plan associated with the mobile device, it is possible that the data plan will allow broadband transmission, enabling the system to utilize a much greater bandwidth (which speeds up data transmission). In another embodiment, the mobile device 53 is replaced by a cellular communication device (not shown) installed in the vehicle 31. In yet another embodiment, the mobile device (ND - Nomadic Device) 53 can be a wireless local area network (LAN - Local Area Network) device capable, for example (and among others), of communicating over an 802.11g network (i.e.,to communicate via WiFi) or a WiMax network.

[0018] In one embodiment, incoming data can be routed via a data-over-voice or data plan through the mobile device, through the on-board Bluetooth transceiver, and to the vehicle's internal processor 3. In the case of certain temporary data, the data can be stored, for example, on the hard disk drive (HDD) or another storage medium 7 until the data is no longer needed.

[0019] Additional sources that may be connected to the vehicle include a personal navigation device 54, which may have, for example, a USB connection 56 and / or an antenna 58; a vehicle navigation device 60 with a USB 62 or other connector; an on-board GPS device 24; or a remote navigation system (not shown) that has connectivity to the network 61. USB is one of a class of serial network protocols. IEEE 1394 (Firewire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of standards for device-to-device serial communication. Most of the protocols are implementable for either electrical or optical communication.

[0020] Furthermore, the CPU could communicate with a variety of other auxiliary devices 65. These devices could be connected via a wireless 67 or wired 69 connection. The auxiliary device 65 could include, among other things, personal media players, wireless medical devices, portable computers, and the like.

[0021] Alternatively, or in addition, the CPU could, for example, be connected to a vehicle-based wireless router 73 via a WiFi transceiver (IEEE 803.11) 71. This could allow the CPU to connect to remote networks within range of the local router 73.

[0022] In addition to the exemplary processes being executed by a vehicle data processing system located in a vehicle, in certain embodiments the exemplary processes can be executed by a data processing system that communicates with a vehicle data processing system. Such a system may include, among other things, a wireless device (e.g., a mobile phone) or a remote data processing system (e.g., a server) connected by the wireless device. Collectively, such systems may be referred to as vehicle-associated computing systems (VACS). In certain embodiments, specific components of the VACS may perform certain parts of a process, depending on the specific implementation of the system.As an example, and not as a limitation, if a process involves a step of sending or receiving information with a coupled wireless device, it is likely that the wireless device will not perform this part of the process, since the wireless device would not "send and receive" information to itself. A person of average expertise recognizes when it is inappropriate to apply a particular data processing system to a given solution.

[0023] In each of the illustrative embodiments discussed here, a representative, non-limiting example of a process executable by a data processing system is shown. With respect to each process, the data processing system executing the process can be configured as a specialized processor for the limited purpose of carrying out the process. Not all processes need to be executed in their entirety and are to be understood as examples of types of processes that can be performed to achieve elements of the invention. Additional steps can be added to or removed from the exemplary processes as desired.

[0024] A system is proposed in which a driver can request fuel delivery to a vehicle. Either via a vehicle telematics unit, a smart device, or even a phone call, a driver can contact a remote fuel delivery service and request fuel delivery to a specified vehicle. The driver can provide vehicle location information, such as GPS, VIN, license plate number, make, model, color, etc., as well as anything else that might facilitate vehicle identification when the tanker truck driver is on site. The tanker truck driver can then deliver a load of fuel to the vehicle, communicate wirelessly to authorize the fuel delivery and receive payment, refuel the vehicle, and drive away, with little or no involvement from the vehicle driver in the process.When the driver returns to the vehicle, he finds it filled with the specified quantity.

[0025] Fig. Figure 2 shows an illustrative system for the safe handling of fuel deliveries. In this illustrative example, the vehicle has a fuel flap or fuel channel 201 that communicates with a vehicle data processing system. The usability of this channel (unlocking, unlocking, etc.) can be enabled, if desired, by a command from the vehicle data processing system. In other examples, the fuel flap or fuel channel can be always usable and purely mechanical, without any actual connection to the vehicle data processing system. In both arrangements, it is possible to add a mechanism or rely on existing vehicle sensors to detect the amount of fuel dispensed, ensuring that the customer is not overcharged.

[0026] A driver using the Vehicle Data Processing System (VCS) 205 (in this example) can send a refueling request via a Human Machine Interface (HMI) 203. This request, also in this example, is handled by the Telematics Control Unit (TCU) 207. The VCS can, for example, retrieve and transmit the current fuel level, a desired fuel level or quantity, and all location and vehicle information needed to identify and locate the vehicle. The request information can be sent to the Cloud 211 for handling. This information might include, for example, a token for handling the request, a vehicle location, a current fuel level, vehicle identification information, a desired fuel quantity, and so on.

[0027] The request can then be sent to a refueling company for processing, which can dispatch a truck. When the truck arrives at the vehicle, it can, in this example, insert a refueling nozzle or request access to the vehicle. This can cause the vehicle to wake up, allowing the refueling process to begin. The truck (which in this example has not yet been validated and is not in direct communication with the vehicle) can send a cloud request that includes, among other things, the vehicle's original token (to prove that the truck is the requested one), a vehicle MAC ID, and a truck ID.This information is forwarded from the cloud to the TCU, which can then activate the vehicle's Wi-Fi (for direct communication with the truck) and validate the token (validation can also be performed via the VCS or another suitable module). The MAC address is added, at least temporarily, to an approved list, allowing the truck to connect to the VCS via Wi-Fi.

[0028] Once validation is complete, the VCS can send a command directly to the truck to begin refueling. A refueling level report may be sent again to confirm the previous request. The VCS can also instruct the truck to stop refueling when the tank is full or a desired fill level is reached. Upon completion of the process, the truck sends a fuel dispensed quantity to the VCS, which, along with a measured dispensed amount (for verification purposes to ensure the truck is not reporting an over-dispensed fuel amount) and a truck ID, is uploaded to the cloud. Payment can be handled via the cloud, through a direct connection to the VCS, or by other suitable means. WiFi can then be deactivated, and the vehicle can return to a fully powered-off state.In other examples, a report can be sent from the TCU and / or the cloud to the driver, so that the driver knows that fuel has been dispensed, what the cost was and how much fuel was delivered, as well as any other information that may be useful.

[0029] Fig. Figure 3 shows an illustrative fuel request process. With regard to the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the example procedures shown here. When executing code that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, where appropriate, firmware acting according to a pre-configured processor can cause the processor to act as a special-purpose processor, provided for the purpose of executing the procedure or a reasonable variant thereof.

[0030] In this example, the driver has arrived at a destination and refueling may be desirable. The driver can set parameters that indicate when refueling requests should be sent, so they are not bothered every time the vehicle is parked, although the refueling request could also be always enabled. For example, the driver could set a request to be sent Monday to Friday, 6:00 AM to 5:00 PM, when the fuel level drops below 40%. This covers the driver's typical working hours and allows refueling while the driver is at work. If desired, the refueling request could also switch to an always-on state when the vehicle's fuel level falls below a minimum threshold.In yet another example, the system could determine (for instance, via a cloud database of services or service coverage areas) whether a delivery service is available for a given area before offering the service. This database could also dynamically include current delivery capacities and times for a given area (i.e., even if a service is available in a given area, the driver might not receive a fuel delivery if a high number of requests have been received).

[0031] After the vehicle is parked (301), the process checks whether the fuel level is low (203) or—in other examples—whether request parameters are met. If there is no basis for asking the driver whether a fuel delivery is desired, the process can be terminated. Otherwise, the process can provide the driver with a fuel delivery option (305). This can be a simple request, such as "Would you like fuel delivered?", or it can list, in a selectable manner, one or more delivery services capable of fulfilling the driver's request. These can be displayed on an HMI or announced via a vehicle speaker if an HMI is not available.In other examples, the driver may use a smart device to process the request, although the device may need to be provided with some vehicle-identifying information and the device may need to transmit some information to the vehicle to handle the request (such as a token if that is the method used for authentication).

[0032] If the driver accepts the request 307 or otherwise indicates that a fuel delivery is desired (which could also take the form of an explicit request from the driver, meaning the driver can request a fuel delivery even without a formal request), the driver can enter a desired fuel quantity, desired cost, etc., and, if applicable, a fuel type. Vehicle identification information 309 (such as, but not limited to, GPS location, VIN, make, model, color, license plate number, etc.) and refueling parameters 311 can be sent to the cloud for handling. In this example, the process also generates a unique token 313, which is used to handle a connection request when the fuel arrives, and it is also sent to the cloud 315 for use by the tanker truck.

[0033] Fig. Figure 4 shows an illustrative fuel reception process. With regard to the illustrative embodiments described in this figure, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the example procedures shown here. When executing code that provides instructions for performing some or all of the steps of the procedure, the processor can be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, where appropriate, firmware acting according to a pre-configured processor can cause the processor to act as a special-purpose processor, provided for the purpose of executing the procedure or a reasonable variant thereof.

[0034] While the communication described is direct between the vehicle and the tanker truck, a cloud intermediary could also be used to handle all this information if a direct connection was not desired or could not be managed. For example, the truck could send all access requests to the TCU via the cloud, and the TCU and / or VCS could send all instructions to the truck via the cloud. Furthermore, multiple servers in the cloud could be used (for example, a vehicle OEM server and a refueling company server) to handle these requests. The direct connection can allow for faster command processing; however, using the cloud model can result in a slight delay, for example, when sending an instruction to stop refueling.

[0035] In this example, when the truck arrives at the vehicle, the process determines that a fuel flap (if present) has been opened (401) and a nozzle is detected (403). In other examples, such as for vehicles with a locked fuel flap, the truck might need to send a notification via the cloud that it has arrived, which can then trigger the fuel flap to be unlocked for use. In yet another example, a truck could notify a user that it has arrived, and the user could be provided with one or more vehicle camera images, allowing the user to verify this notification and instruct the unlocking of the fuel flap.

[0036] In this example, the truck driver inserts a nozzle, which can then cause the vehicle to verify a token sent from the truck to the vehicle via the cloud (405; such verification could also occur at the cloud level). The truck's MAC address, also provided by the truck in this example, is used to establish the direct wireless connection between the vehicle and the truck (407). The refueling authorization and / or a start command can then be sent wirelessly from the vehicle to the truck (409). After an appropriate amount of fuel (the requested amount or a "full" quantity) has been dispensed, the process can issue a stop command. In response to the stop command (or while refueling is in progress), the process can receive a dispensed amount of fuel (411).This can be compared with a measured quantity of fuel delivered and / or reported to the cloud along with a truck ID (413) to ensure the figures match. Payment can be made from the vehicle to the truck, via the cloud, or by another suitable method.

[0037] The Fig. 5A and Fig. Figure 5B shows illustrative connection processes for tank truck connection. Regarding the illustrative embodiments described in these figures, it should be noted that a general-purpose processor can be temporarily activated as a special-purpose processor for the purpose of executing some or all of the example procedures shown here. When executing code that provides instructions for performing some or all of the steps of the procedures, the processor can be temporarily repurposed as a special-purpose processor until the procedure is complete. In another example, where appropriate, firmware acting according to a pre-configured processor can cause the processor to act as a special-purpose processor, provided for the purpose of executing the procedures or a reasonable variant thereof.

[0038] Fig. Figure 5A illustrates a truck-side process. In this example, the truck sends a MAC ID and the token provided with the original fuel delivery request (or has it sent on its behalf by a server) 501 before or after its arrival. Authorization to connect to the vehicle (for example, when the truck is on-site) can be received from the cloud 503. This can be done, for example, by verifying the token. The truck then receives a connection request from the VCS 505, and since the truck has the appropriate MAC ID, it can connect wirelessly to the vehicle 507. Communication to control refueling and / or for other purposes can then proceed.

[0039] Fig.Figure 5B shows an illustrative example of a vehicle-side process for connecting to the truck via WiFi or another suitable wireless medium. The vehicle receives the truck's MAC address and the token (in this example, originally generated by the vehicle) 511. The vehicle validates the token 513 and, if invalid, rejects the refueling process 515. The rejection can take any number of forms. If the vehicle can physically prevent refueling, it can do so; in other examples, the vehicle refuses direct wireless communication with the truck and / or declines to send refueling commands or make a payment.

[0040] If the token is valid, the process connects the vehicle and the truck via a wireless connection 517. Then, refueling-related commands can be sent 519, as well as refueling parameters and / or refueling data (quantity dispensed, cost, etc.).

[0041] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the description are descriptive rather than limiting, and it is understood that various modifications can be made without deviating from the concept and scope of protection of the invention. Furthermore, the features of different implementation embodiments can be combined to form further embodiments of the invention. Reference symbol list: 1 Vehicle-Based Computing System (VCS) 3 processors 4 Visual Front-End Interface / Screen 5 Non-persistent memory (RAM) 7 Persistent storage (HDD or flash memory) 9 Digital-to-Analog Converters 11 amplifiers 13 speakers 14 Signal between the mobile device and the BLUETOOTH transceiver 15 BLUETOOTH transceivers 16 Data transmission between CPU and network via voice tape 17 Communication between the mobile device and the BLUETOOTH transceiver 18 Antenna for the on-board modem 19 Bidirectional data streams to a remote BLUETOOTH device 20. Modem communication with a mobile phone mast 21 Bidirectional data streams to a USB device 23 USB inputs 24 GPS input 25 Auxiliary entrance 27 Analog-to-Digital Converters 29 microphone 31 vehicles 33 Auxiliary entrance 51 input selectors 52. Button for pairing the mobile device with the BLUETOOTH transceiver 53 Mobile device (mobile phone, smartphone, PDA) 54 Personal Navigation Device (PND) 55 Communication of the mobile device with a mobile phone mast 56 USB connection of the personal navigation device 57 mobile phone masts 58 Antenna of the personal navigation device 59 Vehicle communication with a network 60 Vehicle navigation device 61 Network 62 USB ports on the vehicle navigation system 63 On-board modem 65 Additional devices (e.g. personal media players, medical devices, portable computers) 67 Wireless connection to auxiliary devices 69 Wired connection to auxiliary devices 71 WiFi transceivers (IEEE 803.11) 73 Vehicle-mounted wireless router 201 Fuel flap or fuel channel 203 Human Machine Interface (HMI) 205 Vehicle data processing system 207 Telematics Control Unit (TCU - Telematics Control Unit) 209 trucks 211 Cloud 301 vehicles parked 303 Fuel level low 305 Fuel Delivery Option 307 Request accepted 309 Vehicle identification information 311 Refueling parameters 313 Unique Token 315 tokens sent to the cloud 401 Fuel flap open 403 Nozzle detected 405 Token Verification 407 Direct wireless connection between vehicle and truck 409 Refueling authorization and / or start command 411 Quantity of fuel delivered received 413 truck IDs reported to the cloud 501 MAC ID and token sent from the truck 503 Approval received from vehicle to connect via cloud 505 Connection request received from VCS 507 Wireless connection established with the vehicle 511 MAC ID of the truck and token received from the vehicle 513 tokens validated 515 Refueling process refused 517 Wireless connection established between vehicle and truck 519 refueling commands and refueling data sent

Claims

[1] System comprising the following: a processor (3) designed to to detect the insertion of a fuel nozzle into the refueling channel of a vehicle (31); to wake up a vehicle telematics system in response to the detection; to receive a tanker truck MAC ID and a token (313) from a remote source on the telematics system after waking up; to validate the token (313) and to establish a wireless connection with the received MAC ID after the token (313) has been validated. [2] System according to claim 1, wherein the processor (3) is further configured to send refueling control commands via the wireless connection. [3] System according to claim 1, wherein the processor (3) is further configured to receive a message about the delivered fuel via the wireless connection. [4] System according to claim 3, wherein the processor (3) is further configured to report the fuel dispensed received with the message, the fuel dispensed measured by the vehicle (31) and a truck ID to a remote device. [5] System according to claim 1, wherein the processor (3) is further configured to report the completion of fuel delivery to a wireless user device. [6] System according to claim 1, wherein the processor (3) is further configured to instruct wireless payment for the dispensed fuel after completion of the fuel dispensing.

Images