Systems and methods for wetstock management

Abstract

A method can include receiving data characterizing wetstock in one or more fuel tanks of a fueling station, identifying an occurrence of wetstock loss by an artificial intelligence (AI) engine in response to receiving the data, determining a cause of the wetstock loss by the AI engine, and providing, to a user interface displayed on one or more user devices, an alert regarding the occurrence of the wetstock loss and a selectable widget configured to receive a user request for additional information regarding the occurrence of the wetstock loss or the cause of the wetstock loss.

Description

Attorney Docket No.: 047376-351001 WOSYSTEMS AND METHODS FOR WETSTOCK MANAGEMENTCROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 681,553, filed August 9, 2024, entitled “Providing smart alerts for fueling stations,” U.S. Provisional Patent application No. 63 / 681,517, filed August 9, 2024, entitled “Conducting extreme variance reporting analysis for fuel storage facilities,” and U.S. Provisional Application No. 63 / 689,227, filed August 30, 2024, entitled “Analysis and user interfaces for fuel storage facilities,” the entirety of each of which are hereby incorporated by reference.FIELD

[0002] The present disclosure relates generally to methods for providing alerts regarding wetstock losses in fueling stations.BACKGROUND

[0003] Wetstock management is part of day-to-day operations of a fuel storage facility, such as a fueling station. Typically, wetstock management involves monitoring of fuel stock at a fuel storage facility using a variety of measurement devices, such as automatic tank gauges (ATGs), fuel leak detection sensors, magnetostrictive probes, and so forth, evaluating measurements to detect abnormal, and often unsafe, events affecting the fuel stock (e.g., fuel losses, fuel excesses, tank defects, operational issues, fuel transactions, etc.), and performing corrective actions as necessary.SUMMARY

[0004] In general, systems and methods for providing alerts regarding wetstock losses from fueling stations are provided.

[0005] An example implementation of the subject matter described herein is a method with the following features. Data characterizing wetstock in one or more fuel tanks of a fueling station can be received. An occurrence of wetstock loss can be identified by an artificial intelligence (Al) engine. The Al engine can determine a cause of the wetstock loss. An alert regarding the occurrence of the wetstock loss, along with a selectable widget configured to receive a user request for additional information regarding the occurrence ofAttorney Docket No.: 047376-351001 WO the wetstock loss or the cause of the wetstock loss, can be provided to a user interface displayed on one or more user devices. In some embodiments, providing the alert includes displaying a visual indicator representing the alert on the user interface.

[0006] The described method can be implemented in a variety of ways. For example, the method can be implemented within a system that includes at least one data processor and a non-transitory memory storing instructions for the processor to perform aspects of the method. Alternatively or in addition, the method can be included in non-transitory computer readable memory storing the method as instructions which, when executed by at least one data processor forming part of at least one computing system, causes the at least one data processor to perform operations of the method.

[0007] In some embodiments, receiving the data can include receiving data from one or more sensors coupled to the one or more fuel tanks. In some implementations, the data includes data characterizing a volume of fuel in each fuel tank of the one or more fuel tanks, data characterizing a temperature of fuel in each fuel tank of the one or more fuel tanks, data characterizing an environment of the fueling station, data characterizing a flow rate of fuel through fuel lines connected to the one or more fuel tanks, data characterizing fuel transactions, data characterizing fuel deliveries, or a combination thereof.

[0008] In some implementations, identifying the occurrence of the wetstock loss can include applying a machine learning (ML) model to determine that a variance of the data is outside of a learned variance interval. In some implementations, identifying the occurrence of wetstock loss can include applying a ML model to provide a representation of the data and comparing a parameter characterizing the representation of the data to a learned parameter value. The ML model can include a regression model.

[0009] In some implementations, the alert indicates drainback to a fuel tank of the one or more fuel tanks. In some implementations, the alert indicates a leak in a fuel line associated with a fuel tank of the one or more fuel tanks. In some implementations, the alert indicates a leak in a fuel meter of a fuel dispenser connected to the one or more fuel tanks. In some implementations, the alert indicates a leak in a fuel tank of the one or more fuel tanks.BRIEF DESCRIPTION OF THE DRAWINGSAttorney Docket No.: 047376-351001 WO

[0010] The disclosed subject matter can be more readily understood with reference to the accompanying drawings, which are as follows:

[0011] FIG. 1 A is a schematic of an exemplary fueling station;

[0012] FIG. IB is the schematic of FIG. 1 A with various example sources of wetstock loss indicated;

[0013] FIG. 2 is a flowchart illustrating an example method of providing alerts regarding wetstock losses from a fueling station;

[0014] FIG. 3 is a diagram of a data flow for an example smart alerts application;

[0015] FIG. 4 is a flowchart illustrating an example method of providing alerts regarding wetstock losses from a fuel tank and fuel lines of a fueling station;

[0016] FIG. 5 is a flowchart illustrating an example method of providing alerts regarding wetstock losses from a fuel line of a fueling station;

[0017] FIG. 6A provides example of fuel line data upon which isolated transaction analysis (ITA) was performed;

[0018] FIG. 6B provides another example of fuel line data upon which isolated transaction analysis (ITA) was performed;

[0019] FIG. 6C provides another example of fuel line data upon which isolated transaction analysis (ITA) was performed;

[0020] FIG. 6D provides another example of fuel line data upon which isolated transaction analysis (ITA) was performed;

[0021] FIG. 7 is a flowchart illustrating an example method of providing real-time alerts regarding wetstock losses from a fueling station;

[0022] FIG. 8 is a plot of example data characterizing wetstock in a fuel tank that has been segmented and fit with models;

[0023] FIG. 9 provides plots of example data characterizing quiet time movement (QTM) analysis performed by a smart alerts application;Attorney Docket No.: 047376-351001 WO

[0024] FIG. 10A is one implementation of a portion of a user interface (UI) of a smart alerts application;

[0025] FIG. 10B is another implementation of a UI of a smart alerts application;

[0026] FIG. 10C is another implementation of a portion of a UI of a smart alerts application;

[0027] FIG. 10D is another implementation of a portion of a UI of a smart alerts application;

[0028] FIG. 10E is another implementation of a portion of a UI of a smart alerts application;

[0029] FIG. 10F is another implementation of a portion of a UI of a smart alerts application;

[0030] FIG. 11 is a flowchart illustrating an example method of conducting extreme variance reporting (EVR) analysis for fuel storage facilities;

[0031] FIG. 12 is a diagram of a data flow for an example EVR application;

[0032] FIG. 13 A is one implementation of a UI of an EVR application for detecting and flagging extreme variances;

[0033] FIG. 13B is another implementation of a UI of an EVR application for detecting and flagging extreme variances;

[0034] FIG. 13C is yet another implementation of a UI of an EVR application for detecting and flagging extreme variances;

[0035] FIG. 13D is still another implementation of a UI of an EVR application for detecting and flagging extreme variances;

[0036] FIG. 13E is another implementation of a UI of an EVR application for detecting and flagging extreme variances;

[0037] FIG. 13F is yet another implementation of a UI of an EVR application for determining EVR;Attorney Docket No.: 047376-351001 WO

[0038] FIG. 13G is still another implementation of a UI of an EVR application for detecting and flagging extreme variances;

[0039] FIG. 13H is another implementation of a UI of an EVR application for detecting and flagging extreme variances;

[0040] FIG. 14 is a flowchart illustrating a method of conducting enhanced loss analysis (ELA) for fuel storage facilities;

[0041] FIG. 15 is a diagram of a data flow for an example ELA application;

[0042] FIG. 16A is one implementation of an overview user interface (UI) of an ELA application;

[0043] FIG. 16B is one implementation of a tank calibration impact UI of the ELA application of FIG. 16A;

[0044] FIG. 16C is one implementation of a tank calibration UI of the ELA application of FIG. 16 A;

[0045] FIG. 16D is one implementation of a tank calibration impact UI of the ELA application of FIG. 16A;

[0046] FIG. 16E is one implementation of a known meter impact UI of the ELA application of FIG. 16A;

[0047] FIG. 16F is one implementation of a meter drift impact UI of the ELA application of FIG. 16 A;

[0048] FIG. 16G is another implementation of a meter drift impact UI of the ELA application of FIG. 16A;

[0049] FIG. 16H is one implementation of a significant events impact UI of the ELA application of FIG. 16A;

[0050] FIG. 161 is one implementation of a top issues UI of the ELA application of FIG. 16 A;

[0051] FIG. 16J is another implementation of an overview UI of an ELA application;Attorney Docket No.: 047376-351001 WO

[0052] FIG. 16K is another implementation of a top issues UI of an ELA application;

[0053] FIG. 17 is a diagram of a decomposition of example sources of fuel loss configured to be used by an ELA application;

[0054] FIG. 18 is a block diagram of an example wetstock monitoring, analysis, and alerting system and an example fueling station;

[0055] FIG. 19A is one implementation of a dashboard UI of a master application;

[0056] FIG. 19B is one implementation of a nozzle out of use UI of the master application of FIG. 19A;

[0057] FIG. 19C is one implementation of a latest water readings UI of the master application of FIG. 19A; and

[0058] FIG. 20 is a block diagram of an example implementation of a wetstock monitoring, analysis, and alerting system.DETAILED DESCRIPTION

[0059] Traditional wetstock management typically involves the manual evaluation of wetstock measurements by a storage facility operator. The storage facility operator can be responsible for monitoring the measurements in order to identify anomalies and respond appropriately. However, the practice of relying upon humans to manually monitor large sets of measurements is prone to error and can result in the failure to detect and resolve problems at an early stage. Such failure, in the context of wetstock management, can lead to potentially catastrophic consequences such as environmental contamination, loss of revenue, reputation damage, and public health risks.

[0060] Disclosed are methods for automatically providing alerts regarding wetstock losses. The methods can leverage computational models, such as artificial intelligence (Al) models, to identify occurrences of wetstock loss using data characterizing wetstock in a fueling station. For each identified occurrence of wetstock loss, a potential cause of the loss can be automatically determined, and an alert regarding the occurrence can be provided, for example, using a user interface. Users (e.g., fuel storage facility operators) can receive the alerts, for example, by accessing an alert application on their computer system. TheAttorney Docket No.: 047376-351001 WO disclosed methods enable alerts regarding wetstock losses to be provided to the user in real time, enabling the user to quickly see and easily be aware of the detected potential problems and their root causes without requiring the user to manually evaluate wetstock measurement data.

[0061] The disclosed methods can be implemented on a computer system that is configured to monitor, analyze, and provide alerts regarding wetstock. Such a computer system can assess a greater amount and a greater variety of data characterizing wetstock as compared to, for example, the amount and variety of data that a storage facility operator can manually evaluate. Furthermore, by leveraging Al techniques such as machine learning, such a computer system can detect features in data characterizing wetstock that are indicative of potential wetstock issues before said features are manually identifiable. Accordingly, such a computer system can identify potential wetstock losses more efficiently and more accurately than a manual evaluator (or a team of manual evaluators).

[0062] Information regarding wetstock analyses and alerts regarding wetstock losses to users through one or more user interfaces (UI(s)). The UI(s) can enable vital information and urgent alerts to be provided in an easily digestible manner that facilitates efficient addressing of wetstock issues. Moreover, the UI(s) can quickly notify users of urgent issues and, if multiple issues are present, allow users to efficiently determine which issues to prioritize. In some implementations, the UI(s) enable alerts and information regarding multiple different fueling stations to be reviewed by a single user, thereby, for example, providing insights into potentially systemic issues affecting more than one fueling station. For example, the UI(s) can provide insight into equipment failures that are occurring in the same model of equipment at multiple different fueling stations, insight into potential theft from multiple different locations, or insight into environmental issues impacting multiple different fueling stations.

[0063] In some implementations, by providing information regarding wetstock analyses, as well as alerts regarding wetstock losses through a user interface, the disclosed methods enable multiple users to receive information and alerts simultaneously. The UI can also enable information and alerts to be provided to a user regardless of the user’s location. In particular, the UI can provide information and alerts to a user on a personal device such as a smartphone or a laptop to which they always have access, thereby enabling the user to take actions to address wetstock issues even when the user is not physically present at the fueling station that is being monitored by the computer system.Attorney Docket No.: 047376-351001 WO

[0064] Certain implementations will now be described to provide an overall understanding of the principles of the structure, function, manufacture, and use of the devices and methods disclosed herein. One or more examples of these implementations are illustrated in the accompanying drawings. Those skilled in the art will understand that the devices and methods specifically described herein and illustrated in the accompanying drawings are non- limiting implementations and that the scope of the present invention is defined solely by the claims. The features illustrated or described in connection with one implementation may be combined with the features of other implementations. Such modifications and variations are intended to be included within the scope of the present invention.

[0065] Further, in the present disclosure, like-named components of the implementations generally have similar features, and thus within a particular implementation each feature of each like-named component is not necessarily fully elaborated upon. Additionally, to the extent that linear or circular dimensions are used in the description of the disclosed systems, devices, and methods, such dimensions are not intended to limit the types of shapes that can be used in conjunction with such systems, devices, and methods. A person skilled in the art will recognize that an equivalent to such linear and circular dimensions can easily be determined for any geometric shape. Sizes and shapes of the systems and devices, and the components thereof, can depend at least on the anatomy of the subject in which the systems and devices will be used, the size and shape of components with which the systems and devices will be used, and the methods and procedures in which the systems and devices will be used.

[0066] A schematic of an exemplary fueling station 100 is provided in FIG. 1 A. The fueling station 100 in the illustrated implementation of FIG. 1 A includes fuel storage 110 including numerous fuel tanks 120, numerous fuel dispensers 140, a point-of-sale (POS) terminal 150, store 160, and an onsite controller 170.

[0067] In the illustrated implementation, the fueling station 100 includes three fuel tanks 120, but a fueling station can include a different number of fuel tanks (e.g., one, four, five, etc.). Each fuel tank 120 can be configured to contain fuel such as, for example, regular unleaded (e.g., 87 octane) gasoline, mid-grade (e.g., 89 octane) gasoline, premium (e.g., 91 octane) gasoline, or diesel fuel. In some implementations, one or more of the fuel tanks 120Attorney Docket No.: 047376-351001 WO contain the same type of fuel. In some implementations, one or more of the fuel tanks 120 contain different types of fuel.

[0068] As shown in FIG. 1, the fuel tanks 120 are configured to be in fluid and operable communication with one or more fuel dispensers 140. In the illustrated implementation, four fuel dispensers 140 are shown, but a fueling station can include another number of fuel dispensers (e.g., one, two, three, five, ten, etc.). Each of the fuel dispensers 140 in this illustrated implementation is a different type of fuel dispenser, but any one or more of the fuel dispensers at a fueling station can be the same as or different from any one or more other fuel dispensers at the fueling station.

[0069] One or more fuel lines can operatively connect each fuel tank 120 to the fuel dispensers 140. A single fuel line can operatively connect a fuel tank 120 to a single fuel dispenser 140 or can operatively connect a fuel tank 120 to each of a plurality of fuel dispensers 140. A fuel tank 120 can have a single fuel line operatively connected thereto or can have a plurality of lines operatively connected thereto.

[0070] Each fuel dispenser 140 can include one or more fuel nozzles configured to dispense fuel therethrough. Each nozzle can be operatively coupled to a pump configured to cause fuel to flow from a fuel line to the nozzle. Each nozzle can be operatively coupled to a fuel meter configured to measure an amount of fuel pumped through the nozzle.

[0071] The fuel tanks 120 can each be in operable communication with one or more sensors 130. Each sensor 130 can be configured to measure data characterizing a fuel tank 120, for example, data characterizing an amount of fuel that enters the fuel tank (e.g., during a fuel delivery), data characterizing an amount of fuel removed from the fuel tank (e.g., during dispensing of fuel from a fuel dispenser 140), or data characterizing a physical property (e.g., temperature, pressure, etc.) of the fuel contained in the fuel tank.

[0072] Each of the one or more fuel dispensers 140 and each of the one or more sensors 130 can be configured to be operatively coupled to the POS terminal 150. The POS terminal 150 in this illustrated implementation is shown as being located inside the store 160, but a POS terminal 150 can be located elsewhere at a fueling station. The POS terminal 150 can be configured to communicate data associated with fuel transactions, data received from the one or more fuel dispensers 140, and / or data from each of the one or more sensors 130 to aAttorney Docket No.: 047376-351001 WO computer system. In some implementations, the POS terminal 150 is configured to communicate the data associated with fuel transactions, the data received from the one or more fuel dispensers 140, and / or the data from each of the one or more sensors 130 directly to the computer system. In some implementations, the POS terminal 150 is configured to communicate the data associated with fuel transactions, the data received from the one or more fuel dispensers 140, and / or the data from each of the one or more sensors 130 indirectly to the computer system by transmitting the data associated with fuel transactions, the data received from the one or more fuel dispensers 140, and / or the data from each of the one or more sensors 130 to the onsite controller 170.

[0073] The onsite controller 170 can be, for example, a forecourt controller or other controller. In some implementations, the onsite controller 170 is configured to communicate the data associated with fuel transactions, the data received from the one or more fuel dispensers 140, and / or the data from each of the one or more sensors 130 directly to the computer system. The onsite controller 170 in this illustrated implementation is shown as being located inside the store 160, but an onsite controller can be located elsewhere at a fueling station.

[0074] In some implementations, the onsite controller 170, instead of or in addition to the POS terminal 150, is configured to receive the data from the one or more fuel dispensers 140 and / or the data from each of the one or more sensors 130. In such implementations, the onsite controller 170 is configured to communicate the data received from the one or more fuel dispensers 140 and / or the one or more sensors 130 directly to the computer system. In some implementations, instead of the POS terminal 150 and / or the onsite controller 170 directly communicating the data associated with fuel transactions, the data received from the one or more fuel dispensers 140, and / or the data from each of the one or more sensors 130 directly to the computer system, the POS terminal 150 and / or the onsite controller 170 is configured to communicate at least some of the data associated with fuel transactions, the data received from the one or more fuel dispensers 140, and / or the data from each of the one or more sensors 130 to a remote computer system, such as a cloud server or other computer system, which is configured to communicate the data received from the POS terminal 150 and / or the onsite controller 170 to the computer system.

[0075] FIG. IB illustrates aspects of the fueling station 100 of FIG. 1 A that may be causes of wetstock loss, that is, loss of fuel stored at the fueling station 100. From initialAttorney Docket No.: 047376-351001 WO loading at a terminal, to delivery, to storage at the fuel tanks 10 and on to the fuel dispensers 140, there are many points where fuel can be lost or stolen. As shown in FIG. IB, possible causes of wetstock include leaks, actual losses, and perceived losses. Leak causes include fill line leaks (e.g., leak at a line through which fuel is supplied to a fuel tank 120), pump leaks at a fuel dispenser 120, tank leaks at a fuel tank 120, fuel line leaks (e.g., leak at a line along which fuel is delivered from a fuel tank 120 to one or more of the fuel dispensers 140), and offset fill leaks. Actual loss causes include meter drift (e.g., drift of a fuel meter at a fuel dispenser 140), theft or fraud at a fuel dispenser 140, theft from a fuel tank 120, temperature- induced evaporation at a fuel tank 120, and fuel theft at delivery of fuel to a fuel tank 120. Perceived loss causes include a wrong delivery volume (e.g., a wrong volume of fuel delivered to a fuel tank 120), phase separation at a fuel tank 120, tank calibration error at a fuel tank 120, water ingress at a fuel tank 120, density changes at a fuel tank 120, missing fuel transaction data, drainback (e.g., fuel flowing back to a fuel tank 120 after a transaction in which fuel is dispensed from a fuel dispenser 140 to a customer), and pump tests not being recorded (e.g., tests of a pump at a fuel dispenser 140 not being recorded).

[0076] In some implementations, alerts regarding wetstock losses can be provided by a dedicated application, referred to herein as a “smart alerts” or “smart alarms” application, configured to automatically detect potential problems at a fueling station and provide a notification to a user indicating one or more detected potential problems. The smart alerts application can be configured to provide notifications of potential problems to a user via a user interface (UI) provided via a display of a laptop computer, mobile telephone, or other computer system in operative communication with the computer system that is executing the smart alerts application. The notification provided to the user can be provided in real time to allow the user to quickly see and easily be aware of the detected potential problems and their root causes. The smart alerts application can thereby enable the user to take an action to address the potential problems soon after the problems are detected, thus facilitating the avoidance or mitigation of adverse effects of the detected potential problems.

[0077] In some implementations, the smart alerts application is configured to analyze conditions and generate notifications for numerous fuel stations, which may allow for a single server (e.g., a cloud server) or other computing system to provide smart alarms support for multiple fueling stations. This can facilitate efficient updating the smart alerts application, reduce per-user cost (e.g., due to sharing of support resources with other users), and / or allowAttorney Docket No.: 047376-351001 WO for increased processing and / or storage capability (e.g., by allowing an owner of the smart alerts application to use the same server or other computing system for multiple customers). In other implementations, the smart alerts application is configured to analyze conditions and generate notifications for a single fueling station, which may help prevent multiple users being simultaneously affected by an unexpected power supply error or other error causing partial or complete unavailability and / or unreliability of the smart alerts application for a period of time.

[0078] In some implementations, the smart alerts application is configured to be accessed and used at a location remote from the location of a fueling station being monitored by the application. For example, the smart alerts application can be configured to be accessed and used at a remote location in another city, state, or country than the fuel station. Such remote operability can allow the user to begin addressing potential problems detected by the smart alerts application without physically visiting the fueling station and, as a result, increase the speed and efficiency at which the problems are resolved.

[0079] Upon receipt of a notification indicating a detected potential problem from the smart alerts application, the user can determine actions to be taken to resolve the detected problem. In some situations, the user may determine that a detected problem is insignificant or otherwise not concerning, in which case the user may decide not to take any action to address the detected problem or may decide to delay action until further analysis of the detected problem is performed. The smart alerts application can be configured to enable the user to access additional detail regarding detected potential problems using the UI to further understand the one or more detected potential problems. By allowing user assessment of the detected potential problem(s), human and infrastructure resources may be used efficiently and effectively to only address those problems that the user assesses as needing attention.

[0080] The smart alerts application can be configured to analyze fueling-related conditions and generate notifications for multiple categories of alerts. Example categories of alerts are described in further detail below.

[0081] One category of alerts is drainback. Drainback refers to fuel flowing back from a fuel line to a fuel tank (e.g., a fuel tank 120 of the fueling station 100 shown in FIG. 1) after a transaction in which fuel is dispensed from a fuel dispenser (e.g., a fuel dispenser 140 of the fueling station 100 shown in FIG. 1) to a customer.Attorney Docket No.: 047376-351001 WO

[0082] Another category of alerts is line leak. A line leak occurs when fuel leaks on a line connecting a fuel tank (e.g., a fuel tank 120 of the fueling station 100 shown in FIG. 1) to one or more fuel dispensers (e.g., the fuel dispensers 140 of the fueling station 100 shown in FIG. 1).

[0083] Yet another category of alerts is meter leak. A meter leak occurs when fuel is leaking out of a fuel meter of a fuel dispenser (e.g., a fuel dispenser 140 of the fueling station 100 shown in FIG. 1). The fuel meter as a result does not accurately measure fuel pumped by a pump of the fuel dispenser.

[0084] Yet another category of alerts is real-time loss. One type of real-time loss alert is a smart loss alert. A smart loss alert can be triggered when an amount of fuel unexplained by fuel transactions is detected as leaving a fuel tank (e.g., a fuel tank 120 of the fueling station 100 shown in FIG. 1). For example, a smart loss alert can be triggered by a fuel leak or by fuel spillage. Another type of real-time loss alert is a sudden loss alert. Like smart loss alerts, sudden loss alerts can be triggered when an amount of fuel unexplained by fuel transactions is detected as leaving the fuel tank. Sudden loss alerts can be triggered for significant detected losses, for example, losses that exceed 1000 liters. Sudden loss of fuel can result from, for example, fuel theft.

[0085] Yet another category of alerts is quiet time movement (QTM). Quiet time for a fuel tank (e.g., a fuel tank 120 of the fueling station 100 shown in FIG. 1) is a time period without a fuel transaction (that is, without fuel being dispensed from the fuel tank to a customer by a fuel dispenser such as, e.g., a fuel dispenser 140 of the fueling station 100 shown in FIG. 1) or a fuel delivery (that is, without fuel being added into the fuel tank). During quiet time, the wetstock amount in a fuel tank should stay substantially constant. QTM refers to fuel leakage during quiet time.

[0086] In some implementations, the smart alerts application is configured to receive as inputs raw data regarding the fuel tank(s) being analyzed, including data associated with fuel transactions for each of one or more fuel tanks being monitored (at the same fueling station or at different fueling stations) provided on a regular (e.g., periodic) basis, such as every 10 minutes, every 20 minutes, every 30 minutes, etc., and data associated with fuel stock inventory (e.g., raw tank inventory records including fuel level and volume, fuel temperature, and water volume) measured and provided on a regular (e.g., periodic) basis, such as everyAttorney Docket No.: 047376-351001 WO30 seconds, every minute, every 15 seconds, etc. Data associated with fuel transactions may be delayed, for example, to allow for transactions processing time, with typical delays being in a range of about 15 to 30 minutes. Data associated with fuel transactions and data associated with fuel stock inventory can be provided from the fueling station to the smart alerts application (e.g., to the server or other computer system executing the smart alerts application) by data collection devices such as sensors (e.g., ATGs, etc.) at the fuel station(s) being monitored and point-of-sale (POS) terminals at the fuel station(s) being monitored. The data collection devices can also provide data associated with fuel station equipment configuration to the smart alerts application.

[0087] A flowchart of an example method 20 of providing alerts regarding wetstock losses from a fueling station is shown in FIG. 2. The method 20 can be performed, all or in part, by one or more processors of a computer system, for example a computer system configured to execute a smart alerts application. For example, the method 20 can be implemented as instructions stored in non- transitory memory of the computer system. Alternatively, or in addition, the method 20 can be included in non-transitory computer readable memory storing the method 20 as instructions which, when executed by one or more processors forming part of a computer system, cause the processor(s) to perform operations of the method 20. Additional details regarding a computer system that can perform operations of the method 20 are discussed herein with reference to FIG. 20.

[0088] The method 20 is intended only as an example implementation of a method of providing alerts regarding wetstock losses from a fueling station. In some implementations, a method of providing alerts regarding wetstock losses from a fueling station can include operations performed in a different order than the operations of the method 20. In some implementations, a method of providing alerts regarding wetstock losses from a fueling station can include operations in addition to those of the method 20. In some implementations, a method of providing alerts regarding wetstock losses from a fueling station can omit aspects of the method 20.

[0089] At 205, data characterizing wetstock in one or more fuel tanks of a fueling station is received. The data can include, e.g., data from one or more sensors coupled to the one or more fuel tanks, data from one or more fuel meters of fuel dispensers coupled to the one or more fuel tanks, data from a POS terminal of the fueling station, data from an onsite controller (e.g., a forecourt controller) of the fueling station, and the like. In someAttorney Docket No.: 047376-351001 WO implementations, the data includes data characterizing a volume of fuel in each fuel tank, data characterizing a temperature of fuel in each fuel tank, data characterizing environmental conditions (e.g., air temperature, ground temperature, etc.) of an environment of the fueling station, data characterizing a flow rate of fuel through fuel lines connected to the fuel tanks, data characterizing fuel transactions, data characterizing fuel deliveries, and the like.

[0090] At 210, in response to receiving the data characterizing the wetstock, an artificial intelligence (Al) engine identifies an occurrence of wetstock loss. The Al engine can include one or more trained Al models. In some implementations, the Al engine includes a machine learning (ML) model such as a regression model, a classification model, segmentation model, or a combination thereof. In some implementations, the Al engine includes a generative Al models such as a large language model (LLM), an adversaria] network, a diffusion model, a recurrent neural network, an autoencoder, or a combination thereof.

[0091] In some implementations, identifying an occurrence of wetstock loss involves applying a trained ML model to determine that a variance of (at least a portion of) the data characterizing the wetstock is outside of a learned variance interval. The learned variance interval can be a range of variance values that the model learned, during training, represents a normal amount of variance of a characteristic or property of the wetstock, that is, an amount of variance of a characteristic or property of the wetstock that is not indicative of an issue with the wetstock.

[0092] In some implementations, identifying an occurrence of wetstock loss involves applying a trained ML model to provide a representation of (at least a portion of) the data characterizing the wetstock. The representation can be, e.g., a regression model that has been fit to (at least a portion of) the data characterizing the wetstock, or another suitable representation. In some implementations, a parameter of the representation provided by the ML model (e.g., if the representation is a linear fit, a slope of the linear fit) to a learned value of the parameter (e.g., a learned slope value). The learned parameter value can indicate, in some implementations, a threshold value associated with normal amounts of wetstock loss, that is, amounts of wetstock loss that are not indicative of an issue with the wetstock.

[0093] At 215, the Al engine determines a potential cause of the wetstock loss. In some implementations, determining a cause of the wetstock loss can involve, for example, analyzing a configuration of fuel dispenser nozzles or fuel lines to determine whether thereAttorney Docket No.: 047376-351001 WO has been a change to the configuration relative to a previously determined configuration, determining whether there are any stuck probe issues, determining whether there are any issues with a particular fuel line, and the like.

[0094] At 220, an alert regarding the occurrence of the wetstock loss is provided. The alert can include an indication of the cause of the wetstock loss. The alert can be provided in a variety of formats. In some implementations, the alert is provided in a visual format, e.g., as an icon on a graphical user interface. In some implementations, the alert is provided in an audio format, e.g., as an alarm using a speaker. In some implementations, the alert is provided in a tactile format, e.g., as a vibration through a haptic feedback device.

[0095] In some implementations, the alert is provided to a user interface displayed on one or more user devices. The user devices can be communicatively coupled to the computer system implementing the method 200, e.g., via a wired connection or via a wireless network. In some implementations, in addition to the alert, a selectable widget (e.g., a button, a checkbox, a link, or the like) can be provided on the user interface. The selectable widget can be configured to receive a user request for additional information regarding the occurrence of the wetstock loss or the cause of the wetstock loss. In response to selection of the selectable widget by a user using their user device, additional information such as data associated with the identified occurrence of wetstock loss, information regarding a representation of data characterizing the wetstock loss provided by a ML model, information regarding parameters learned by the ML model, and / or the like can be provided to the user via the user interface.By providing both the alert and the selectable widget, the smart alerts application ensures that the occurrence of wetstock loss, and the cause of the loss, is efficiently communicated to users and allows users to quickly request additional information about the wetstock loss, thereby enabling users to easily determine actions to address the wetstock loss without requiring the users to directly inspect the data characterizing the wetstock.

[0096] FIG. 3 shows a data flow 300 for an example smart alerts application 304. As shown, data 302 characterizing wetstock in one or more fuel tanks can be provided as input to the smart alerts application 304. An Al engine 306 of the smart alerts application 304 can identify one or more occurrences of wetstock loss and, for each identified occurrence, determine a potential cause of the loss. The smart alerts application 304 can provide alerts regarding the identified occurrences of wetstock loss using a user interface 318. The alerts can include, e.g., an alert 308 regarding drainback, an alert 310 regarding a line leak, an alertAttorney Docket No.: 047376-351001 WO312 regarding a meter leak, an alert 314 regarding quiet time movement, and an alert 316 regarding real-time loss.

[0097] As described, in some implementations, a smart alerts application (e.g., the smart alerts application 304 shown in FIG. 3) can be configured to provide alerts regarding a fuel tank as well as alerts regarding fuel lines connected to the fuel tank. An example method 40 of providing alerts regarding wetstock losses from a fuel tank and fuel lines of a fueling station is provided in FIG. 4.

[0098] The method 40 can be performed, all or in part, by one or more processors of a computer system configured to execute the smart alerts application. For example, the method 40 can be implemented as instructions stored in non-transitory memory of the computer system. Alternatively, or in addition, the method 40 can be included in non-transitory computer readable memory storing the method 40 as instructions which, when executed by one or more processors forming part of a computer system, cause the processor(s) to perform operations of the method 40. Additional details regarding a computer system that can perform operations of the method 40 are discussed herein with reference to FIG. 20.

[0099] The method 40 is intended only as an example implementation of a method of providing alerts regarding wetstock losses from a fuel tank and fuel lines of a fueling station. In some implementations, a method of providing alerts regarding wetstock losses from a fuel tank and fuel lines of a fueling station can include operations performed in a different order than the operations of the method 40. In some implementations, a method of providing alerts regarding wetstock losses from a fuel tank and fuel lines of a fueling station can include operations in addition to those of the method 40. In some implementations, a method of providing alerts regarding wetstock losses from a fuel tank and fuel lines of a fueling station can omit aspects of the method 40.[000100] At 405, data characterizing wetstock in a fuel tank in a time interval is received. In response to receiving the data characterizing the wetstock, at 410, a determination as to whether a nozzle configuration or a fuel line configuration differs from a predetermined configuration is made. In some implementations, the determination is performed by an Al engine such as the Al engine 306 of FIG. 3. The predetermined nozzle configuration or fuel line configuration can be a configuration that was learned by a model (e.g., an ML model) of the Al engine.Attorney Docket No.: 047376-351001 WO[000101] If it is determined that the nozzle configuration or the fuel line configuration does differ from the predetermined configuration (415), an alert regarding a configuration error is provided (420). On the other hand, if it is determined that neither the nozzle configuration nor the fuel line configuration differs from the predetermined configuration (425), a determination as to whether there is a stuck probe is made (430). In some implementations, determining whether there is a stuck probe involves determining that a probe of an automatic tank gauge (ATG) is stuck in a stationary position.[000102] If it is determined that there is a stuck probe (435), data characterizing fuel transactions corresponding to the stuck probe are removed (440). A determination is then made as to whether there is an issue associated with a fuel line (450). The determination as to whether there is an issue associated with the fuel line (450) is also made if it is determined that there is no stuck probe (445).[000103] If no fuel line issue is detected (455), an indication that there are no errors associated with the fuel tank for the time interval is provided (460). In some implementations, providing the indication of no errors involves providing no alerts (e.g., a smart alarms application executing the method 40 may do nothing). In some implementations, providing the indication of no errors involves providing information that explicitly indicates that no errors have been detected. For example, a smart alarms application executing the method 40 may display, on a user interface, a phrase such as “No Errors Detected,” or may display a visual representation of the time interval using a particular color (e.g., green). If, on the other hand, a fuel line issue is detected (465), an alert regarding the issue associated with the fuel line is provided (470).[000104] FIG. 5 provides an example method 50 of providing alerts regarding wetstock losses from a fuel line of a fueling station. The method 50 is an example implementation of an isolated transactions analysis (ITA) algorithm. In some implementations, determining, at 450 of the method 40 shown in FIG. 4, whether there is an issue associated with a fuel line can include aspects of the method 50 shown in FIG. 5.[000105] The method 50 can be performed, all or in part, by one or more processors of a computer system configured to execute the smart alerts application. For example, the method 50 can implemented as instructions stored in non-transitory memory of the computer system. Alternatively, or in addition, the method 50 can be included in non-transitory computerAttorney Docket No.: 047376-351001 WO readable memory storing the method 50 as instructions which, when executed by one or more processors forming part of a computer system, cause the processor(s) to perform operations of the method 50. Additional details regarding a computer system that can perform operations of the method 50 are discussed herein with reference to FIG. 20.[000106] The method 50 is intended only as an example implementation of a method of providing alerts regarding wetstock losses from a fuel line of a fueling station. In some implementations, a method of providing alerts regarding wetstock losses from a fuel line of a fueling station can include operations performed in a different order than the operations of the method 50. In some implementations, a method of providing alerts regarding wetstock losses from a fuel line of a fueling station can include operations in addition to those of the method 50. In some implementations, a method of providing alerts regarding wetstock losses from a fuel line of a fueling station can omit aspects of the method 50.[000107] At 502, a determination is made as to whether the data characterizing the wetstock includes data associated with at least a threshold number of isolated transactions (ITs) corresponding to a fuel line. If it is determined that there is insufficient available data associated with ITs (504), no alert regarding the fuel line is provided (516). On the other hand, if it is determined that there is sufficient available data associated with ITs (506), a determination is made as to whether a variance of any transaction is outside of a predetermined variance interval (508).[000108] If it is determined that there are no transactions with a variance outside of the variance interval (510), a determination is made as to whether a variance of any transaction differs from a baseline variance (512). If there is no determined difference between the variance of any transaction and the baseline variance (514), no alert regarding the fuel line is provided (516).[000109] If it is determined that there are transactions with variances outside of the variance interval (518), a determination is made as to whether fuel losses increase with time when the fuel line is out of use (520). If there is no fuel loss increase when the fuel line is out of use (522), a determination as to the number of nozzles associated with the fuel line is made (524). If there is one nozzle associated with the fuel line (526), a determination is made as to whether a correlation exists between transaction variance and transactions (530). If it is determined that there is no correlation between variance and transactions, an alert regarding aAttorney Docket No.: 047376-351001 WO line leak is provided (538). If it is determined that there is a correlation between variance and transactions (542), an alert regarding a meter leak is provided (544).[000110] If there is more than one nozzle associated with the fuel line (528), a determination is made as to whether the nozzles are different from one another (534). If the nozzles are determined to be identical (536), an alert regarding a line leak is provided (538). If there are two or more distinct nozzles (540), an alert regarding a meter leak is provided (544).[000111] FIGS. 6A-6D provide plots of data characterizing ITA performed ML model (e.g., a model configured to perform the method 50 of FIG. 5). The ML model used in the examples of FIG. 6A-6D can be, in some implementations, used by an Al engine (e.g., the Al engine 306 shown in FIG. 3) of a smart alerts application to provide alerts regarding wetstock losses from a fueling station.[000112] FIG. 6 A shows a first plot 602, a second plot 604, a third plot 606, and a fourth plot 608. The plots 602 and 604 correspond to a first fuel line (“Line LI”) and the plots 606 and 608 correspond to a second fuel line (“Line L2”). In the plots 602 and 606, the horizontal axes indicate different nozzles of the respective fuel line and the vertical axes indicate a transaction variance value. In the plots 604 and 608, the horizontal axes indicate an amount of time out-of-use for the respective fuel line and the vertical axes indicate a transaction variance value.[000113] In the plot 602 and the plot 606, respectively, the lines 602a and 606a indicate transaction variance limits delimiting, for each fuel line, a variance interval learned by the model during training that defines a normal transaction variance amount for the fuel line. In some implementations, the model is trained on historical transaction data for the fuel lines to learn the transaction variance limits (and, thus, the transaction variance intervals). In some implementations, the model is trained on simulated transaction data for the fuel lines to learn the transaction variance limits.[000114] In the plot 602 and the plot 606, respectively, the lines 602b and 606b indicate a reference mean value that has been learned by the model. In the plot 602, the data points 602c fall between the lines 602a and are therefore determined by the model to be within the learned variance interval (that is, within the transaction variance limits), while the data pointsAttorney Docket No.: 047376-351001 WO602d fall outside the lines 602a and are therefore determined by the model to be outliers. The data points 602d include data corresponding to both a first nozzle and a second nozzle of the first fuel line. In the plot 606, all of the data points 602c fall between the lines 602a.[000115] In the plot 604 and the plot 608, respectively, the lines 604a and 608a indicates a detectable loss threshold that has been learned by the model, and the lines 604c and 608c indicate a threshold slope that has been learned by the model. The line 604b in the plot 604 indicates an estimated relationship between variance and time out-of-use.[000116] In this example, as shown in the plots 602 and 604, the model determined that the variance in the data associated with the first fuel line differs significantly from the reference variance learned by the model and that the data associated with the first fuel line indicates no statistically significant difference between the two nozzles of the first fuel line. Based on these determinations, the model determined that there is a line leak in the first fuel line and provided an alert regarding the line leak. In contrast, as shown in the plots 606 and 608, the model determined that no alert is necessary regarding the second fuel line.[000117] The example of FIG. 6B is similar to that of FIG. 6 A. FIG. 6B shows a first plot 610, a second plot 612, a third plot 614, and a fourth plot 616. The plots 610 and 612 correspond to a first fuel line (“Line LI”) and the plots 614 and 616 correspond to a second fuel line (“Line L2”). In the plots 610 and 614, the horizontal axes indicate different nozzles of the respective fuel line and the vertical axes indicate a transaction variance value. In the plots 612 and 616, the horizontal axes indicate an amount of time out-of-use for the respective fuel line and the vertical axes indicate a transaction variance value. In this example, as shown in the plots 610 and 612, the model determined that the variance in the data associated with the first fuel line differs significantly from the reference variance learned by the model and that the data associated with the first fuel line indicates no statistically significant difference between the two nozzles of the first fuel line. Based on these determinations, the model determined that there is a line leak in the first fuel line and provided an alert regarding the line leak. In contrast, as shown in the plots 612 and 614, the model determined that no alert is necessary regarding the second fuel line.[000118] FIG. 6C shows a first plot 618, a second plot 620, a third plot 622, and a fourth plot 624. The plots 618 and 620 correspond to a first fuel line (“Line LI”) and the plots 622 and 624 correspond to a second fuel line (“Line L2”). In the plots 618 and 622, the horizontalAttorney Docket No.: 047376-351001 WO axes indicate different nozzles of the respective fuel line and the vertical axes indicate a transaction variance value. In the plots 620 and 624, the horizontal axes indicate an amount of time out-of-use for the respective fuel line and the vertical axes indicate a transaction variance value. In this example, as shown in the plots 618 and 620, the model identified a loss of correlation with time out-of-use and determined that one of the nozzles of the first fuel line had a high concentration of associated outlying data points. Based on these determinations, the model determined that there is an issue with the fuel meter associated with one of the nozzles of the first fuel line and provided an alert regarding the meter issue. In contrast, as shown in the plots 622 and 624, the model determined that no alert is necessary regarding the second fuel line.[000119] FIG. 6D shows a first plot 626, a second plot 628, a third plot 630, and a fourth plot 632. The plots 626 and 628 correspond to a first fuel line (“Line LI”) and the plots 630 and 632 correspond to a second fuel line (“Line L2”). In the plots 626 and 630, the horizontal axes indicate different nozzles of the respective fuel line and the vertical axes indicate a transaction variance value. In the plots 628 and 632, the horizontal axes indicate an amount of time out-of-use for the respective fuel line and the vertical axes indicate a transaction variance value. In this example, as shown in the plots 626 and 628, the model determined than an average variance differed significantly from the reference variance range and determined that one of the nozzles of the first fuel line had a high concentration of associated outlying data points. Based on these determinations, the model determined that there is an issue with the fuel meter associated with one of the nozzles of the first fuel line and provided an alert regarding the meter issue. In contrast, as shown in the plots 630 and 632, the model determined that no alert is necessary regarding the second fuel line.[000120] As described, in some implementations, a smart alerts application (e.g., the smart alerts application 304 shown in FIG. 3) is configured to provide real-time loss alerts (e.g., smart loss alerts or sudden loss alerts). An example method 70 of providing real-time loss alerts for a fueling station is illustrated in FIG. 7.[000121] The method 70 can be performed, all or in part, by one or more processors of a computer system configured to execute the smart alerts application. For example, the method 70 can implemented as instructions stored in non- transitory memory of the computer system. Alternatively, or in addition, the method 70 can be included in non-transitory computer readable memory storing the method 70 as instructions which, when executed by one or moreAttorney Docket No.: 047376-351001 WO processors forming part of a computer system, cause the processor(s) to perform operations of the method 70. Additional details regarding a computer system that can perform operations of the method 70 are discussed herein with reference to FIG. 20.[000122] The method 70 is intended only as an example implementation of a method of providing real-time loss alerts for a fueling station. In some implementations, a method of providing real-time loss alerts for a fueling station can include operations performed in a different order than the operations of the method 70. In some implementations, a method of providing real-time loss alerts for a fueling station can include operations in addition to those of the method 70. In some implementations, a method of providing real-time loss alerts for a fueling station can omit aspects of the method 70.[000123] At 705, data characterizing wetstock in a fuel tank is received. At 710, the data is divided into one or more data segments, each of which corresponds to a time interval. The method 70 then proceeds to 715. At 715, each of 720, 725, 730, 735, 740, 745, 750, and 755 is performed for each of the one or more data segments.[000124] At 720, a model that represents the data segment is determined. The model can be, for example a regression model determined using, for example, machine learning. A determination is then made as to whether the model that represents the data segment indicates a wetstock loss during the time interval to which the data segment corresponds (725).[000125] If the model indicates wetstock loss during the time interval (730), a determination as to whether a parameter of the model representing the data segment is less than a threshold parameter value is made (735). In some implementations, the parameter of the model is, for example, a slope of the model.[000126] If the parameter value is less than the threshold value (740), a determination as to whether an amount of wetstock loss is greater than a threshold loss value is made (745). If the wetstock loss exceeds the threshold loss value (750), an alert regarding the wetstock loss during the time interval to which the data segment corresponds is provided (755). In some implementations, if the amount of wetstock loss for the time interval is determined to be significant (e.g., in excess of 1000 liters), the alert regarding the wetstock loss can be a sudden loss alert indicating, for example, potential fuel theft.Attorney Docket No.: 047376-351001 WO[000127] FIG. 8 provides a plot 802 of example data characterizing wetstock in a fuel tank. In the plot 802, the horizontal axis represents time and the vertical axis represents cumulative variance. The line 802a indicates the data characterizing the wetstock. The lines 802b divide the data characterizing the wetstock into four data segments: a first data segment corresponding to a first time interval 804a, a second data segment corresponding to a second time interval 804b, a third data segment corresponding to a third time interval 804c, and a fourth data segment corresponding to a fourth time interval 804d. The line 802c represents a model that has been fit to the data characterizing the wetstock.[000128] FIG. 9 provides plots of example data characterizing quiet time movement (QTM) analysis performed by a smart alerts application. In this example, the smart alerts application provided a QTM alert. A first plot 902 indicates a reconciled tank inventory (that is, tank inventory equal to the difference between the amount of fuel that has been put into the tank (e.g., from deliveries) and the amount of fuel dispensed from the tank through fuel transactions) over a time interval between 2:00 and 12:00 on May 5, 2020. As shown in the plot 902, a period of QTM loss was identified by the smart alerts application between approximately 7:00 and approximately 10:00. A second plot 904 indicates wetstock inventory in the tank over the time interval.[000129] As described, a smart alerts application can include a user interface (UI) through which the application provides alerts regarding wetstock losses. In some implementations, the UI can be accessed using a device such as a smartphone or a laptop computer. The smart alerts application can be configured to provide alerts to the UI by, for example, displaying visual indicators (e.g., a graphical symbols) representing the alerts on the UI. In some implementations, when the smart alerts application provides an alert to the UI, the smart alerts application can be configured to provide a selectable widget (e.g., a button, a checkbox, a link, or the like) that is configured to receive a user request for additional information regarding the alert. By providing such a selectable widget, the smart alerts application can ensure that users are quickly and clearly notified of potential wetstock issues while also allowing the user to selectively access additional data that could impact how the identified issue is addressed.[000130] FIG. 10A illustrates one implementation of a portion 1000a of a user interface (UI) of a smart alerts application. In this illustrated implementation, the user has selected to view notifications of smart alerts for a fueling station identified as “Station 2Attorney Docket No.: 047376-351001 WOName / Identifier” (UI feature 1002). Station 2 has 21 smart alerts (UI feature 1006), three of which are shown in FIG. 10 A. The remaining smart alerts for Station 2 can be accessed, for example, by scrolling down using a scroll bar of the UI. For each of the alerts, information is provided to assist the user in determining whether to take any action in response to the alert. The information includes a category of the alert (“meter issue” for each of the three visible alerts), a component type associated with the art (“nozzle” for each of the three visible alerts), a description, a business day, a start date and time, and a cleared date and time.[000131] Smart alerts for any additional fueling stations to which the user has access rights are available to the user via the UI portion 1000a. In this illustrated implementation, another fueling station identified as “Station 1 Name / Identifier”( UI feature 1004) on the UI portion 1000a is selectable for viewing by a user. Station 1 has 22 smart alerts (UI feature 1008) in this example. Additional fueling stations are accessible to this particular user, as indicated by the statistics on a menu 1010 of the UI portion 1000a indicating that a total of 894 alerts (UI feature 1012) exist for fueling stations accessible to the user. While the menu 1010 is shown on a left side of the UI portion 1000a in FIG. 10A, in other UI implementations, such a menu can be located elsewhere.[000132] The menu 1010 also shows a breakdown 1014 of the categories of the alerts. Only three of the categories (sudden loss, line leak, and meter issue) are visible in FIG. 10A. Other categories can be accessed by, for example, scrolling down using a scroll bar of the UI. In this example, there are 13 sudden loss alerts, 606 line leak alerts, and 209 meter issue alerts. Each of the categories of alerts is selectable by the user to allow the user to examine a select one or more of the categories, which may allow the user to quickly examine alerts of a highest priority. For example, sudden loss alerts may be of a highest priority because they are indicative of possible large fuel loss needing immediate attention.[000133] FIG. 10B illustrates the UI portion 1000a of FIG. 10A with the user having selected in the menu 1010, using a first checkbox 1016 and a second checkbox 1018, to view QT movement alerts (of which there are 52 total) and smart loss alerts (of which there is one total). In this example, Station 1 (1002) has one of the QT movement and smart loss alerts (1008) and Station 2 (1002) has two of the QT movement and smart loss alerts (1006), both being QT movement alerts in this example.Attorney Docket No.: 047376-351001 WO[000134] As shown in FIG. 10B, the UI 1000 can provide an identification 1020 of the logged-in user (name “User” in this example). In the illustrated implementation, the user identification 1020 is provided in an upper right comer of the UI 1000. In other implementations, the identification 1020 can be displayed elsewhere.[000135] FIGS. 10C illustrates a portion 1000b of the smart alerts application UI for managing training of a machine learning model executed by the smart alerts application. The machine learning model can be, for example, a model applied by an Al engine of the smart alerts application (e.g., the Al engine 306 of the smart alerts application 304 shown in FIG. 3). In the illustrated implementation, the UI portion 1000b enables the user to select either “Manual Training” or “Auto Training” (1022) and allows the user to choose whether the model is trained for an entire site (e.g., an entire fueling station) or for fuel tanks (1024). The UI portion 1000b is also configured to receive a user-selected start date for the model training (1026) and a user-selected end date for the model training (1028). User controls 1030 enable the user to view a training result, initiate model training, and clear information entered into the fields 1022, 1024, 1026, and 1028.[000136] Additional example portions of the UI of the smart alerts application are provided in FIGS. 10D-10F. FIGS. 10D shows a portion 1000c of the smart alerts application UI for alert settings management. FIG. 10E shows a portion lOOOd of the smart alerts application UI for machine learning model threshold management. FIGS. 10F shows a portions lOOOe of the smart alerts application UI for providing metadata that provides additional information about fuel tank characteristics.[000137] In some implementations, in conjunction with, or as an alternative to, providing smart alerts regarding wetstock losses, extreme variance reporting (EVR) analysis can be performed for a fuel storage facility. EVR analysis can be executed by a dedicated application, referred to herein as an EVR application. As explained in further detail herein, the EVR application can be configured to perform EVR analysis for a fuel storage facility to detect anomalous gains and losses of fuel at the fuel storage facility.[000138] The EVR application can be configured to provide results of EVR analysis for a fuel storage facility to a user, for example, via a user interface (UI) provided via a display of a laptop computer, mobile telephone, or other computer system, to allow the user to see quickly and easily if fuel gain / loss for a particular fuel tank at a particular fuel storage facilityAttorney Docket No.: 047376-351001 WO is normal or not. If the fuel gain / loss is normal, the fuel gain / loss is not flagged as being an anomaly by the EVR application, and the user need not take any action to address the tank’s gain / loss (if any). The user may access additional details regarding the tank using the UI to further understand the normal result that is indicative of normal data behavior. If the fuel gain / loss is not normal, the fuel gain / loss is flagged as being an anomaly by the EVR application, and the user may take an action to address the flagged anomaly.[000139] In some implementations, an anomaly flagged by the EVR application is a predicted anomaly, not necessarily an actual anomaly. The user may thus decide not to take any action to address the flagged anomaly or may decide to delay action until further analysis of the flagged anomaly is performed. The user may access additional details regarding the tank using the UI to further understand the anomalous result that is indicative of anomalous data behavior.[000140] In some implementations, the EVR application is configured to conduct EVR for numerous fuel stations, which may allow for a single server (e.g., a cloud server) or other computing system to provide EVR support for multiple fueling stations. This can facilitate efficient updating the EVR application, reduce per-user cost (e.g., due to sharing of support resources with other users), and / or allow for increased processing and / or storage capability (e.g., by allowing an owner of the EVR application to use the same server or other computing system for multiple customers). In other implementations, the EVR application is configured to perform EVR for a single fueling station, which may help prevent multiple users being simultaneously affected by an unexpected power supply error or other error causing partial or complete unavailability and / or unreliability of the EVR application for a period of time.[000141] In some implementations, the EVR application is configured to be accessed and used at a location remote from the location of a fueling station being monitored by the application. For example, the EVR application can be configured to be accessed and used at a remote location in another city, state, or country than the fuel station. Such remote operability can allow the user to begin addressing potential problems detected by the EVR application without physically visiting the fueling station and, as a result, increase the speed and efficiency at which the problems are resolved.[000142] In some implementations, the EVR application includes an artificial intelligence (Al) engine. The Al engine can apply a machine learning (ML) model trained on a historicalAttorney Docket No.: 047376-351001 WO dataset for a particular fuel storage facility that can be used to process new raw data (e.g., sensor and / or other measurement data) from the fuel storage facility to flag potential anomalies that the user may then choose to address in any way deemed necessary. The anomalies can include fuel data problems (e.g., incorrectly reported transactions or readings, etc.) and / or genuine fuel issues (e.g., leaks, thefts, etc.). The server or other computing system that includes the EVR application is configured to perform all of the data preprocessing and modeling after the raw data is collected and transmitted to the server or other computing system using a file transfer protocol or other data transmission method.[000143] The EVR application including ML that trains on a historical dataset can enable the EVR application to train a reduced dataset without prior curation of the data by an expert. The EVR application is thus configured to perform unsupervised anomaly detection. The EVR application including ML may also allow for increased EVR accuracy as compared to traditional EVR models, improved work efficiency of system users, through reduced false model flags, better automation of model training, and interpretability of results, and / or faster detection, as compared to traditional EVR models, of risks on fuel storage facilities that can result in financial losses, compromised safety, and / or environmental damage.[000144] In some implementations, the EVR application provides increased model reliability and resistance to data quality problems through automated data checks. As the EVR application adapts automatically to the historical dataset and determines boundaries of non-anomalous data, the EVR application reliably monitors larger number of fuel storage facilities without human involvement. The EVR application can be configured to always flag input data points clearly outside ranges seen in the training dataset or that do not conform to domain-specific correctness rules. In this way, the EVR application draws may user attention to data problems without risk of omitting genuine risks that would otherwise be masked by data issues.[000145] An example method 1100 of performing EVR analysis for fuel storage facilities is illustrated in FIG. 11. The method 1100 can be performed, all or in part, by one or more processors of a computer system configured to execute an EVR application. For example, the method 1100 can implemented as instructions stored in non- transitory memory of the computer system. Alternatively, or in addition, the method 1100 can be included in non- transitory computer readable memory storing the method 1100 as instructions which, when executed by one or more processors forming part of a computer system, cause theAttorney Docket No.: 047376-351001 WO processor(s) to perform operations of the method 1100. Additional details regarding a computer system that can perform operations of the method 1100 are discussed herein with reference to FIG. 20.[000146] The method 1100 is intended only as an example implementation of a method of performing EVR analysis for fuel storage facilities. In some implementations, a method of performing EVR analysis for fuel storage facilities can include operations performed in a different order than the operations of the method 1100. In some implementations, a method of performing EVR analysis for fuel storage facilities can include operations in addition to those of the method 1100. In some implementations, a method of performing EVR analysis for fuel storage facilities can omit aspects of the method 1100.[000147] At 1105, data characterizing the one or more fuel storage facilities is received. The data can include, e.g., data from one or more sensors coupled to one or more fuel tanks, data from one or more fuel meters of fuel dispensers coupled to one or more fuel tanks, data from a POS terminal of a fuel storage facility, data from an onsite controller (e.g., a forecourt controller) of a fuel storage facility, and the like. In some implementations, the data includes data characterizing a volume of fuel stored at each fuel storage facility, data characterizing a temperature of fuel stored at each fuel storage facility, data characterizing environmental conditions (e.g., air temperature, ground temperature, etc.) of an environment of each fuel storage facility, data characterizing a flow rate of fuel through fuel lines connected to fuel tanks at each fuel storage facility, data characterizing fuel transactions or transactions at each fuel storage facility, data characterizing fuel deliveries to each fuel storage facility, and the like.[000148] At 1110, in response to receiving the data, an artificial intelligence (Al) engine identifies one or more anomalous subsets of the data characterizing the one or more fuel storage facilities. The Al engine can include one or more trained Al models. In some implementations, the Al engine includes a machine learning (ML) model such as a regression model, a classification model, segmentation model, or a combination thereof. In some implementations, the Al engine includes a generative Al models such as a large language model (LLM), an adversarial network, a diffusion model, a recurrent neural network, an autoencoder, or a combination thereof. At 1115, an indication of each identified anomalous subset is provided.Attorney Docket No.: 047376-351001 WO[000149] In some implementations, a query regarding a first anomalous subset of the one or more anomalous subsets is received (1120). The query can be provided, for example, by a user of the EVR application that is executing the method 1100 and can include, for example, a request for additional information regarding the first anomalous subset. The query can be, for example, a natural language query, or can be provided using one or more widgets on a user interface associated with the EVR application.[000150] In response to the query, an indication of a cause of the first anomalous subset can be provided (1125). The cause can be an issue with a process for obtaining the data characterizing the one or more fuel storage facilities, for example, an issue with a sensor from which the data is received. The cause can also be an issue with wetstock of at least one of the one or more fuel storage facilities. The indication of the cause can be provided in a variety of formats. In some implementations, the indication of the cause is provided in a visual format, e.g., as text or a plot on a graphical user interface.[000151] FIG. 12 illustrates an example data flow 1200 for an EVR application 1204. As shown, data 1202 characterizing one or more fuel storage facilities can be provided as input to the EVR application 1204. An Al engine 1206 of the EVR application 1204 can determine whether the data 1202 includes any anomalies corresponding to potential issues.[000152] If the Al engine 1206 determines that there are no anomalies in the data 1202, the EVR application 1204 can provide an indication 1208 that the data 1202 is normal using a user interface 1220. In some implementations, the user can respond to the indication 1208 with a query 1210 regarding the indication 1208 that the data is normal. In response to the query 1210, the EVR application 1204 can provide additional information 1212 regarding the data 1202 to the user via the user interface 1220 to, for example, allow the user to manually evaluate features of the data 1202.[000153] If the Al agent 1206 identifies an anomalous subset of the data 1202, the EVR application 1204 can provide an indication 1214 of the anomalous subset using the user interface 1220. In some implementations, the user can respond to the indication 1214 with a query 1216 regarding the anomalous subset. In response to the query 1216, the EVR application 1204 can provide an indication 1218 of a possible cause of the anomalous subset 1218 to the user via the user interface 1220 to, for example, allow the user to determine further action(s) to address the cause.Attorney Docket No.: 047376-351001 WO[000154] As described, in some implementations, the Al engine of an EVR application can include a ML algorithm. A variety of ML algorithms may be selected for use by an Al engine (e.g., the Al engine 1206 shown in FIG. 12) of an EVR application (e.g., the EVR application 1204 shown in FIG. 12), including algorithms such as quantile regression, support vector regression, ordinary least squares regression (OLSR), linear regression, logistic regression, ridge regression, Least Absolute Shrinkage and Selection Operator (LASSO) regression, Elastic Net regression, stepwise regression, nearest-neighbor regression, multivariate adaptive regression splines (MARS), kernel regression, locally estimated scatterplot smoothing (LOESS), ordinal regression, robust linear regression, Poisson regression, Bayesian linear regression, neural network regression, decision forest regression, boosted decision tree regression, artificial neural networks (ANN), Random Forest, Rotation Forest, Bayesian statistics, case-based reasoning, Gaussian process regression, inductive logic programming, learning automata, learning vector quantization, informal fuzzy networks, conditional random fields, genetic algorithms (GA), Information Theory, support vector machine (SVM), Averaged One-Dependence Estimators (AODE), Group method of data handling (GMDH), instance-based learning, lazy learning, Maximum Information Spanning Trees (MIST), Isolation Forest, Local Outlier Factor, and One-Class Support Vector Machines.[000155] Four example implementations of ML models for the EVR application are described below. In each of the implementations, the ML model is trained per tank on daily data, ignoring any days marked for exclusion. Inputs for the ML model include opening stock, closing stock, current day’s temperature, prior day’s temperature, deliveries, and transactions. The ML model flags each day for each tank with one of two flags (e.g., 0 or 1, No or Yes, etc.) to indicate no potential anomaly detected (e.g., 0, No, etc.) or to indicate a potential anomaly (e.g., 1, Yes, etc.). In some implementations, one or more other inputs are also provided, such as any known activity that may be quantified and affect the daily balance of fuel entering and leaving the tank. Examples of such inputs include emptying the whole tank for cleaning or pump tests when some fuel leaves the tank but is not recorded as a transaction.[000156] In a first implementation, the ML model uses linear regression and outlier scores. A regression model for variance is built as in a traditional regression model, and scores are calculated based on regression residuals, but borders are not determined based on flags orAttorney Docket No.: 047376-351001 WO anomalies in training data. Instead, outlier limits for scores are calculated using a statistical method such as Tukey’s method (for boxplots). As a result, there is no risk of overflagging anomalies as long as the variances in the new raw data stay similar to the training period. The inputs and outputs for one example of the first ML model implementation are shown in Table 1.TABLE 1[000157] Table 1 shows data for two days, one day per row. The parameters “Opening,” “Closing,” “Transactions,” and “Daily Loss / Gain (DLG)” are parameters associated with the wetstock at different instances of time. In some implementations, the relationship between these parameters is as follows:Transactions = Opening - Closing + DLGFor both days the model calculates the scores based on daily recommendations and trained parameters, then compares to the same lower / upper borders. Scores are not expressed directly in litres. The model score can be determined based on a comparison of DLG and transactions along with reference to the lower and upper borders associated with the model. The result, which can be tagged as “OK” or “Flag,” can indicate a level of risk involved with the wetstock loss.[000158] In a second implementation, the ML model uses quantile regression and includes separate models for normal loss and normal gain. For example, models can be built that flag only 5% most extreme gains and 5% most extreme losses for given stock / transactions / temperature levels. This model does not include any borders displayed in the UI but calculates maximum permitted loss / gain for each new input dynamically. The inputs and outputs for one example of the second ML model implementation are shown in Table 2.TABLE 2Attorney Docket No.: 047376-351001 WO[000159] The inputs in Table 2 are the same as the inputs in Table 1. Table 2 shows that the allowed DLGs (in liters) are calculated separately for each set of inputs, and observed values exceeding either border are flagged.[000160] In a third implementation, the ML model uses unsupervised outlier detection. In this model, a multivariate outlier detection method is applied, such as robust ellipsoid, isolation forest, or one-class support vector machine (SVM). This model is configured to detect unusual patterns in data associated with a fuel tank.[000161] In a fourth implementation, the ML model is a hybrid ML model that includes two or more ML models. One of the ML models used can be an existing EVR analysis approach so that, for example, only one new model needs to be implemented.[000162] A first view of an example UI 1300 of an EVR application is provided in FIG. 13 A. The UI 1300 includes an indication that the fuel storage facility includes five fuel tanks, identified on the UI 1300 as Tank 1 (diesel), Tank 2 (diesel), Tank 3 (unleaded), Tank 4 (super unleaded), and Tank 5 (unleaded) (1302). In response to a user selection of any one of the indicated tanks, the EVR application is configured to display on the UI 1300 information regarding EVR analysis for the selected tank in a table 1308. In the illustrated example, Tank 2 has been selected, so the table 1308 displays information regarding EVR analysis for Tank 2. The UI 1300 also provides an option for the user to select all of the tanks (1304).[000163] Each row of the table 1308 corresponds to a date. In FIG. 13 A, four days’ worth of data is shown for Tank 2. Information for subsequent days can be accessed by scrolling down using the scroll bar 1306 on the right side of the UI 1300. Days for which the EVR application identified at least one anomaly for Tank 2 are flagged with alert symbols 1310. In the illustrated example, each alert symbol 1310 is a circle with an exclamation point in the circle, but other alert symbols may be used, such as a star, an alarm bell, the letter A (for “alert”), the letter W (for “warning”), a blinking dot, a triangle with an exclamation point in the triangle, a square with an exclamation point in the square, or another symbol.Attorney Docket No.: 047376-351001 WO[000164] FIG. 13B shows another view of the UI 1300. As shown, the UI 1300 can include a first drop-down menu 1312 that enables a fuel storage facility to be selected. In FIG. 13B, the selected fuel storage facility is the “Glencaim” fuel storage facility. The UI 1300 can also include a second drop-down menu 1314 that enables an organization or grouping of fuel storage facilities to be selected. In FIG. 13B, the selected organization is “Test Site With Data.”[000165] A user identification 1316 indicating the user who is operating the EVR application is provided in the top right corner of the UI 1300. In some embodiments, the number of options in available for selection in the menu 1312 and / or the menu 1314 varies based on credentials or access permissions of the user who is operating the EVR application.[000166] In FIG. 13B, the UI 1300 indicates that the fuel storage facility selected from the menu 1312 includes four fuel tanks, identified on the UI 1300 as Tank 1 (super unleaded), Tank 2 (unleaded), Tank 3 (diesel), and Tank 4 (super diesel) (1302). Tank 1 has been selected by the user, so the UI 1300 displays information regarding EVR analysis for Tank 1 in the table 1308.[000167] FIG. 13C illustrates another view of the UI 1300. As shown in FIG. 13C, each row of the table 1308 that displays information regarding EVR analysis for the selected fuel tank includes a checkbox 1316. In response to a user selection of a checkbox 1316, the EVR application is configured to display additional information 1318 regarding the EVR analysis for the selected fuel tank on the date corresponding to the selected row of the table 1308. In the illustrated example, the user selected the row of the table 1308 corresponding to the date “July 25, 2024.” The displayed additional information 1318 allows the user to examine details that caused the alert to be generated by the EVR application and thus allow the user to determine what, if any, corrective action the user should begin to address the anomaly. One example of a corrective action is contacting the fueling station owner and / or other fueling station personnel to inform the fueling station owner and / or personnel of the potential anomaly and / or to suggest a corrective action to be performed immediately such as deactivating a particular fuel dispenser for consumer use. Another example of a corrective action is adjusting the data afterwards, if needed.[000168] FIG. 13D illustrates an administrator view of the UI 1300 of the EVR application. The administrator view of the UI 1300 may be accessible only to those users with certainAttorney Docket No.: 047376-351001 WO access privileges. In this illustrated implementation, the UI 1300 displays several selectable view options (1320). The view options include a configuration (config) map view, a statistical view, a site config view, a delay settings view, an include / exclude view, and a general site notes view. In FIG. 13D, the statistical view has been selected. Other selected views allow the user to view information about the data values used in training datasets, potential data issues detected, and a description of data relationships on the fuel tank (see FIG. 13G).[000169] Additional administrator views of the UI 1300 are provided in FIGS. 13G-13H. FIG.13G shows extended information about the patterns and relationships identified on a specific fuel tank, which enables a user, for example, an administrator of the EVR application, to better understand the fuel tank characteristic and application flags and predictions. FIG. 13G shows description of the whole tank dataset. FIG. 13H shows an explanation of individual machine learning model prediction that can be easily understood and verified by a knowledgeable user. As shown in FIG. 13G, a user of the EVR application may learn from the displayed information that the fuel tank inventory measurement system at Tank 1 tends to show systematically higher fuel losses when transactions on a tank is relatively high and when the fuel stock level is close to depletion. As a result, the user may understand when the EVR application would, for example, flag a small gain on a day with very high transactions but not flag a large loss on almost-depleted tank. As shown in FIG. 13H, the EVR application has flagged the day of 4 January 2024 as potential anomaly and shows what values of input data would change the prediction. As a result, a user of the EVR application may decide, for example, to investigate first whether the correct delivery amount was reconciled in the system.[000170] FIGS. 13E and 13F illustrate views of the UI 1300 during EVR model validation for a user of the EVR application. As shown in FIG. 13E, the UI 1300 allows the user to input a date range and a stock volumes range, allows default ranges to be read from data, allows the user select to display only flagged days, only days that are not flagged, or both, allows the user to switch between delivery and non-delivery days, allows the user to upload a model file and retrain the model on a selected range using a “train model” button, and allows the user to recalculate the model limits graph using a “visualize” button. In FIG. 13E, the EVR application displays a graph indicating results of the model validation.[000171] As shown in FIG. 13F, the UI 1300 allows the user to change the inputs to the model and allows the user to see the model output of the model with the changed inputs usingAttorney Docket No.: 047376-351001 WO a “calculate prediction” button. The EVR application can be configured to display various graphs 1322 for analyzing variances.[000172] In some implementations, in conjunction with, or as an alternative to, providing smart alerts regarding wetstock losses and / or performing EVR analysis, enhanced loss analysis (ELA) can be performed for a fuel storage facility. ELA analysis can be executed by a dedicated application, referred to herein as an ELA application. As explained in further detail herein, the ELA application can be configured to perform ELA analysis for a fuel storage facility to provide categorizations of where fuel loss or gain is occurring in the fuel storage facility.[000173] The ELA application can be configured to provide results of ELA for a fuel storage facility to a user, for example, via a user interface (UI) provided via a display of a laptop computer, mobile telephone, or other computer system. The user may thus review the categorization and decide whether or not take an action to address fuel loss or gain for a fuel tank and associated fuel dispenser(s) and, if so, what one or more actions would be most likely to effectively address the fuel loss based on the possible cause(s) identified by the ELA application. An action the user may decide to take includes, in some implementations, sending a text, email, phone call, and / or other communication to a fueling station employee to disable one or more fuel dispensers associated with the fuel loss or gain until further investigation occurs, to check fuel transactions data for the fuel dispenser(s) associated with the fuel loss or gain, or the like and / or sending a text, email, phone call, and / or other communication to a fuel delivery company that delivered fuel to a fuel tank associated with the fuel loss or gain. In some implementations, the user may decide not to take any action to address the fuel loss or gain, or the user may decide to delay action until further analysis of the fuel loss or gain is performed. The UI is configured to allow the user to access additional detail regarding the fuel loss or gain to further understand the identified possible cause(s) of the fuel loss or gain.[000174] In some implementations, the ELA application is configured to receive as inputs raw data regarding the fuel tank(s) and the fuel dispenser(s) being analyzed. In an exemplary implementation, the raw data includes fuel transactions data for each of one or more fuel tanks and the one or more fuel dispensers being monitored (at the same fueling station or at different fueling stations) provided on a regular basis, such as every 10 minutes, every 20 minutes, every 30 minutes, etc., and fuel stock inventory measurement data (e.g., raw tankAttorney Docket No.: 047376-351001 WO inventory records including fuel level and volume, fuel temperature, and water volume) measured and provided on a regular period basis, such as every 30 seconds, every minute, every 15 seconds, etc. Raw fuel transactions data may be delayed, e.g., to allow for fuel transactions processing time, with typical delays being in a range of about 15 to 30 minutes. As will be appreciated by a person skilled in the art, fuel transactions data and fuel stock inventory measurement data can be provided from the fueling station to the ELA application, e.g., to the server or other computer system executing the ELA application, by data collection devices such as sensors (e.g., ATGs, etc.) at the fuel station(s) being monitored and point-of- sale (POS) terminals at the fuel station(s) being monitored. The data collection devices can also provide fuel station equipment configuration data to the ELA application.[000175] In some implementations, the EVR application is configured to conduct EVR for numerous fuel stations, which may allow for a single server (e.g., a cloud server) or other computing system to provide EVR support for multiple fueling stations. This can facilitate efficient updating the EVR application, reduce per-user cost (e.g., due to sharing of support resources with other users), and / or allow for increased processing and / or storage capability (e.g., by allowing an owner of the EVR application to use the same server or other computing system for multiple customers). In other implementations, the EVR application is configured to perform EVR for a single fueling station, which may help prevent multiple users being simultaneously affected by an unexpected power supply error or other error causing partial or complete unavailability and / or unreliability of the EVR application for a period of time.[000176] In some implementations, the EVR application is configured to be accessed and used at a location remote from the location of a fueling station being monitored by the application. For example, the EVR application can be configured to be accessed and used at a remote location in another city, state, or country than the fuel station. Such remote operability can allow the user to begin addressing potential problems detected by the EVR application without physically visiting the fueling station and, as a result, increase the speed and efficiency at which the problems are resolved.[000177] An example method 1400 of performing ELA for fuel storage facilities is illustrated in FIG. 14. The method 1400 can be performed, all or in part, by one or more processors of a computer system configured to execute an ELA application. For example, the method 1400 can implemented as instructions stored in non-transitory memory of the computer system. Alternatively, or in addition, the method 1400 can be included in non-Attorney Docket No.: 047376-351001 WO transitory computer readable memory storing the method 1400 as instructions which, when executed by one or more processors forming part of a computer system, cause the processor(s) to perform operations of the method 1400. Additional details regarding a computer system that can perform operations of the method 1400 are discussed herein with reference to FIG. 20.[000178] The method 1400 is intended only as an example implementation of a method of performing ELA for fuel storage facilities. In some implementations, a method of performing ELA for fuel storage facilities can include operations performed in a different order than the operations of the method 1400. In some implementations, a method performing ELA for fuel storage facilities can include operations in addition to those of the method 1100. In some implementations, performing ELA for fuel storage facilities can omit aspects of the method 1400.[000179] At 1405, data characterizing the one or more fuel storage facilities is received. The data can include, e.g., data from one or more sensors coupled to one or more fuel tanks, data from one or more fuel meters of fuel dispensers coupled to one or more fuel tanks, data from a POS terminal of a fuel storage facility, data from an onsite controller (e.g., a forecourt controller) of a fuel storage facility, and the like. In some implementations, the data includes data characterizing a volume of fuel stored at each fuel storage facility, data characterizing a temperature of fuel stored at each fuel storage facility, data characterizing environmental conditions (e.g., air temperature, ground temperature, etc.) of an environment of each fuel storage facility, data characterizing a flow rate of fuel through fuel lines connected to fuel tanks at each fuel storage facility, data characterizing fuel transactions at each fuel storage facility, data characterizing fuel deliveries to each fuel storage facility, and the like.[000180] At 1410, in response to receiving the data, an artificial intelligence (Al) engine identifies an occurrence of a fuel loss or a fuel gain. The Al engine can include one or more trained Al models. In some implementations, the Al engine includes a machine learning (ML) model such as a regression model, a classification model, segmentation model, or a combination thereof. In some implementations, the Al engine includes a generative Al models such as a large language model (LLM), an adversarial network, a diffusion model, a recurrent neural network, an autoencoder, or a combination thereof.Attorney Docket No.: 047376-351001 WO[000181] At 1415, the Al engine determines a categorization for the identified occurrence of the fuel loss or the fuel gain. The categorization can define, for example, a cause of the occurrence of the fuel loss or the fuel gain. At 1420, an indication of the categorization is provided.[000182] In some implementations, a query regarding the categorization is received (1120). The query can be provided, for example, by a user of the ELA application that is executing the method 1400 and can include, for example, a request for additional information regarding the categorization or the identified occurrence of the fuel loss or the fuel gain. The query can be, for example, a natural language query, or can be provided using one or more widgets on a user interface associated with the ELA application. In response to the query, information characterizing the occurrence of the fuel loss or the fuel gain can be provided (1125).[000183] An example data flow 1500 for an ELA application 1504 is provided in FIG. 15. As shown, data 1502 characterizing one or more fuel storage facilities can be provided as input to the ELA application 1504. An Al engine 1506 of the ELA application 1504 can identify occurrences of fuel loss or fuel gain based on the data 1502 and can determine a categorization for each identified occurrence. The ELA application 1504 can provide an indication 1508 of a determined categorization to a user using a user interface 1516. In some implementations, the user can respond to the indication 1508 with a query 1510 regarding the categorization. In response to the query 1510, the ELA application 1504 can provide information 1512 characterizing the identified occurrence of fuel loss or fuel gain to the user via the user interface 1516.[000184] FIGS. 16A-16O illustrate various views of an example UI 1600 of an ELA application. As shown in FIG. 16 A, the UI 1600 includes an identification of the logged-in user (name “UserName” in this example) on the UI in an upper right corner, although the identification may be displayed elsewhere or may not be displayed at all. The UI 1600 is configured to show an ELA network overview for a selected organization among a plurality of organizations available to the user, for a selected site among a plurality of sites for the selected organization, for a selected fuel tank among a plurality of fuel tanks at the selected site, and in a selected date range. In this illustrated view, all organizations are selected, all sites for the selected organization are selected, all fuel tanks are selected, and the selected date range is March 15, 2024 to June 13, 2024. In some instances, a user may have only oneAttorney Docket No.: 047376-351001 WO organization available for selection, a selected organization may have only one site, and / or a selected site may have only one fuel tank.[000185] Information shown via the ELA network overview in the UI 1600 can be based on the data received by the ELA application, e.g., by the server or other computer system executing the ELA application, for the selected organization(s), selected site(s), and selected fuel tank(s), e.g., fuel transaction data associated with the selected fuel tank(s) and thus also associated with the selected site(s) and the selected organization(s), data received from one or more fuel dispensers associated with the selected fuel tank(s) and thus also associated with the selected site(s) and the selected organization(s), and data from each of one or more sensors configured to acquire data characterizing the fuel stored in the selected fuel tank(s). The information shown in this illustrated implementation includes raw variance information, adjustment impacts information, book variance information, impact information, and ELA variance information.[000186] The raw variance information reflects variance in the data received by the ELA application for the selected organization(s), selected site(s), and selected fuel tank(s) without any adjustment of the data by the ELA application. The ELA application is thus configured to determines the raw variance information based on the data received by the ELA application for the selected organization(s), selected site(s), and selected fuel tank(s). In this illustrated implementation the raw variance information is -9.61M, indicating a 9.61M loss. The raw variance information and other information on the ELA network overview is in dollars or other currency, which may be selected by the user or may be a default currency.[000187] The adjustment impacts information shows information in the data received by the ELA application for the selected organization(s), selected site(s), and selected fuel tank(s) that the ELA application is configured to use in adjusting the raw variance information. The adjustment impacts information includes transaction information, fuel stock information, fuel delivery information, and other information. In this illustrated implementation the transaction information is -64211.83 (indicating a 64211.83 loss), the fuel stock information is -4.93 (indicating a 4.93 loss), the fuel delivery information is -14451.85 (indicating a 14451.85 loss), and the other information is -2993.03 (indicating a 2993.03 loss).[000188] The fuel stock information is usually canceled out over more than one day. The actual amount of closing fuel stock adjustments in this period in this illustratedAttorney Docket No.: 047376-351001 WO implementation is 166.9K. This information shown on the ELA network overview highlights the benefit of the adjustments made, as the stock adjustment impact will typically be zero as opening and stock impacts cancel out, unless there is impact on the first day in the selected range.[000189] The book variance information shows the raw variance information that the ELA application adjusted based on the adjustment impacts information. In other words, the book variance equals the raw variance added to a sum of all the adjustment impacts information. In this illustrated implementation the book variance information is -9.69M, indicating a 9.69M loss. The variance thus increased, e.g., the loss became greater, when the adjustment impacts information was considered.[000190] The impact information shows possible causes of the variance as analyzed by the ELA application using the data received by the ELA application for the selected organization(s), selected site(s), and selected fuel tank(s). The variance is a loss in this illustrated implementation of FIG. 16A but can be a gain or a loss. The ELA network overview identifies five possible causes: calibration, temperature, known meter, meter drift, and other significant events. In this illustrated implementation the calibration impact is -3.6K (indicating a 3.6K loss), the temperature impact is -968.8 (indicating a 968.8 loss), the known meter impact is -49.2K (indicating a 49.2K loss), the meter drift impact is -44K (indicating a 44K loss), and no impact of other significant events has been found. The ELA network overview thus shows to the user in this illustrated implementation that the known meter impact has the highest impact among the identified possible causes of the variance and the temperature impact has the lowest impact among the identified possible causes of the variance (other than the other significant events, which has no impact).[000191] The calibration impact (also referred to herein as “tank calibration impact”) reflects impact of fuel tank calibration (also referred to herein as “tank calibration”). Selecting the calibration impact on the UI 1600 (FIG. 16A), such as by clicking on the arrow in the “Calibration Impact” box, clicking on the “Tank Calibration Impact” tab on the ELA application UI, or otherwise selecting the calibration impact, is configured to show a fuel tank calibration impact UI that allows the user to see details of the calibration impact.[000192] As shown in FIG. 16B, the UI 1600 can be configured to display information regarding total calibration impact. In this illustrated implementation, the fuel tank calibrationAttorney Docket No.: 047376-351001 WO impact shows total calibration impact per day (across all selected fuel tanks), shown on a bar plot in this illustrated implementation; total calibration impact per fuel tank, shown on a bar plot in this illustrated implementation; and calibration impacts per tank (same as the total calibration impact per fuel tank graph), shown as a drill-down table in this illustrated implementation, with the option to summarize per site and organization. The fuel tank calibration impact allows a user viewing the fuel tank calibration impact to analyze the displayed information to see a visualization of data, e.g., to see a possible cause of gain / loss, and to make decisions based on the data to trigger one or more corrective actions. Examples of corrective actions include actions regarding fuel delivery timing recommendations, fuel delivery amount recommendations, fuel dispenser shutoff recommendations, and fuel meter reset recommendations.[000193] As will be appreciated by those skilled in the art, an amount of fuel in a fuel tank can be calculated using a probe in the fuel tank that transmits a signal to an ATG that indicates a height of fuel in the fuel tank. The ATG calculates the amount of fuel in the fuel tank based on the height of fuel in the fuel tank and on a known diameter of the fuel tank. The ATG then transmits the calculated amount of fuel in the fuel tank to the ELA application. An error can occur in the ATG’s calculation of the amount of fuel in the fuel tank because of tank calibration.[000194] Tank calibration generally refers to the dependence of fuel volume in a fuel tank on height of fuel in the fuel tank. Fuel tanks can have an irregular shape that makes it difficult to determine a volume of the fuel tank. Fuel tanks can vary in volume even between a same model of fuel tank due to any number of factors such as manufacturing tolerances. Tank calibration is a manual process that typically involves filling an empty fuel tank in measured portions until the fuel tank is full to determine a total volume of the fuel tank. Tank calibration is relatively time-consuming and prevents the fuel tank from being used in dispensing fuel from any fuel dispenser during the tank calibration process. Tank calibration for a fuel tank typically occurs on a regular schedule with months between tank calibrations, often six months, twelve months, or more. Thus, any error that occurred in tank calibration resulting in an inaccurate calculation of the fuel tank’s volume will carry over until the next tank calibration.[000195] An ATG for a fuel tank typically has a built-in strapping table of fuel level (fuel height) to tank volume. As mentioned above, a probe in the fuel tank transmits to the ATG aAttorney Docket No.: 047376-351001 WO signal that indicates a height of fuel in the fuel tank. The ATG calculates the amount of fuel in the fuel tank based on the height of fuel in the fuel tank and on a known diameter of the fuel tank as indicated in the strapping table. The data reported by the ATG may appear to show a fuel loss or gain of a certain amount when, upon consideration of other data associated with the fuel tank, a fuel loss or gain did not occur at all or did not occur at that certain amount. The ELA application is configured to consider the other data to “recalibrate” the fuel tank to reduce likelihood of identifying a false loss or gain.[000196] The ELA application is configured to create over time a tank calibration table virtually based on the ELA application’s own calculations instead of relying on the data reported by the ATG to the ELA application. The ELA application is configured to create the tank calibration table using the data received from the one or more fuel dispensers and the data received from each of one or more sensors configured to acquire data characterizing the fuel stored in the fuel tank.[000197] As shown in FIG. 16C, the ELA application can be configured to cause the UI 1600 to display fuel tank calibration information.[000198] Referring again to FIG. 16A, the temperature impact reflects impact of temperature on fuel in the fuel tank. In general, a high enough temperature causes evaporation of fuel and thus appears as a fuel loss, e.g., fuel not in the fuel tank and not otherwise accounted for such as in the transactions data as being sold fuel. The ELA application is configured to receive temperature information for the fuel tank and / or the fuel in the fuel tank and to use the received temperature information to compensate for fuel likely lost due to evaporation since a known amount of fuel can be considered to be lost for each X amount of time that the measured temperature is above Y degrees.[000199] In an exemplary implementation, the ELA application is configured to determine temperature impact according to the following formula: (L2 closing stock - recalibrated closing) - (L2 opening - recalibrated opening) + transactions impact - delivery impact. Transactions impact is temporarily zero (until automatic temperature control (ATC) adjusted transactions are available in daily reconciliations). The fuel dispenser includes the ATC so that there is a consistent temperature at the fuel dispenser. Delivery impact is calculated (L2 deliveries - book deliveries) if delivery is adjusted otherwise the delivery impact is calculated as ambient temperature recalibrated minus raw deliveries.Attorney Docket No.: 047376-351001 WO[000200] Selecting the temperature impact in the view of the UI 1600 shown in FIG. 16A, such as by clicking on the arrow in the “Temperature Impact” box, clicking on the “Temperature Impact” tab on the ELA application UI, or otherwise selecting the temperature impact, is configured to show a temperature UI that allows the user to see details of the temperature impact.[000201] As shown in FIG. 16D, the ELA application can be configured to cause the UI 1600 to display information regarding a temperature impact. In this illustrated implementation the temperature impact shows total temperature impact per day (across all selected tanks), shown on a bar plot in this illustrated implementation; total temperature impact per tank, shown on a bar plot in this illustrated implementation; and temperature impacts per tank (same as the total temperature impact per tank graph), shown as a drill-down table in this illustrated implementation, with the option to summarize per site and organization.[000202] The known meter impact reflects impact of a fuel dispenser’s fuel meter measurement of fuel dispensed from the fuel dispenser. In general, the fuel meter measures an amount of fuel dispensed by the fuel dispenser. A fuel meter typically does not measure from zero because a meter tolerance is allowed by law. Thus, a fuel meter’s measurement of dispensed fuel may be higher or lower than the actual amount of fuel dispensed. The known meter impact indicates impact of meter drift based on the meter setting previously reported to the ELA application reflecting the meter setting when a meter technician installed the meter.[000203] In an exemplary implementation, the ELA application is configured to calculate known meter impact on a nozzle per day as meter adjusted transactions - book transactions per that nozzle, with impact per site / tank being a sum over all the nozzles. Known meter impact will be zero in cases when meter setting is unknown.[000204] The ELA application is configured to compensate transactions data using a fuel meter’s known meter tolerance. For example, if a fuel meter is known to have a +0.3mL tolerance, the fuel meter is known to measure 0.3mL more fuel being dispensed than was actually dispensed. The ELA application is configured to compensate each transaction associated with the fuel meter by 0.3mL to account for the fuel meter’s known meter tolerance that falsely indicates more fuel being dispensed than was actually dispensed. For another example, if a fuel meter is known to have a -0.2mL tolerance, the fuel meter is knownAttorney Docket No.: 047376-351001 WO to measure 0.2mL less fuel being dispensed than was actually dispensed. The ELA application is configured to compensate each transaction associated with the fuel meter by 0.2mL to account for the fuel meter’s known meter tolerance that falsely indicates less fuel being dispensed than was actually dispensed.[000205] Selecting the known meter impact on the view of the UI 1600 shown in FIG. 16A, such as by clicking on the arrow in the “Known Meter Impact” box, clicking on the “Known Meter Impact” tab on the UI 1600, or otherwise selecting the known meter impact, is configured to cause the ELA application to display information regarding the known meter impact that allows the user to see details of the known meter impact.[000206] A view of the UI 1600 displaying information regarding known meter impact is shown in FIG. 16E. In this illustrated implementation the known meter impact shows total meter impact per day (across all selected tanks), shown on a bar plot in this illustrated implementation; total meter impact per tank, shown on a bar plot in this illustrated implementation; meter impacts per nozzle against the book transactions (as the meter impact should be proportional to known over- / under-dispensing and transactions volume), shown on a scatter plot in this illustrated implementation; and meter drift impacts per nozzle (same as the meter impacts per nozzle), shown as a drill-down table in this illustrated implementation, with the option to summarize per site and organization.[000207] The meter drift impact reflects impact of a fuel dispenser’s fuel meter drifting over time in measuring fuel dispensed from the fuel dispenser. Over time, mechanical components of a fuel dispenser experience wear and tear that cause “drift” of meter measurements and thus cause under-dispensing or over-dispensing. Meter drift is typically about + / -0. l%-0.2%. However, after enough time, the drift causes by wear and tear will cause the fuel meter to be outside the meter tolerance of + / -0.3% allowed by law. Thus, fuel meters are typically reset on a regular schedule with months between fuel meter resets, often six months, twelve months, or more. However, there is often a period of time before the fuel meter reset in which the meter measurements will be outside the known meter tolerance, typically a meter drift of about + / -0.5 %. The variance from the known meter tolerance continues until the next fuel meter reset.[000208] The ELA application is configured to profile a fuel meter’s meter drift based on the received fuel transaction transaction data and the data received from the fuel dispenserAttorney Docket No.: 047376-351001 WO that includes the fuel meter. The profile indicates a normal amount of meter drift for the fuel meter. The ELA application is thus configured to determine when the fuel meter is likely to drift and thus when reset of a fuel meter would be advisable, e.g., before the drift becomes outside the meter tolerance allowed by law and to limit any over-dispensing (which is a loss to the fueling station because fuel was dispensed without being paid for by a fueling customer) or under-dispensing (which results in overpayment by a fueling customer by paying for fuel that was not dispensed). The ELA application is configured to provide the advisable time for fuel meter reset to a user via the UI 1600.[000209] In an exemplary implementation, the ELA application is configured to evaluate meter drift of a fuel meter based on isolated transactions involving the fuel meter. In general, an isolated transaction is a single fuel transaction that occurs without the fuel dispenser dispensing fuel in any other fuel transactions, e.g., fuel is being dispensed from only one of a plurality of nozzles of the fuel dispenser. Isolated transactions allow for cleaner analysis of meter drift than non-isolated transactions because it is known for an isolated transaction that a fuel meter’s measurement is for only that one transaction.[000210] Selecting the meter drift impact on the view of the UI 1600 shown in FIG. 16A, such as by clicking on the arrow in the “Meter Drift Impact” box, clicking on the “Meter Drift Impact” tab on the 1600, or otherwise selecting the meter drift impact, is configured to cause the ELA application to display information regarding the a meter drift that allows the user to see details of the known meter drift impact.[000211] A positive meter impact indicates over-dispensing. A negative meter impact indicates under-dispensing. For example, assume the meter drift is estimated to 0.1%, e.g., the meter is over-dispensing systematically 0.1% of actual transactions, and on a given period book transactions equal 10001. The ELA application is configured to calculate “meter drift adjusted’” transactions as 1001 (calculated as 1000 + 0.1% x 1000). This means the meter drift impact would be +1, as ELA variance is calculated as closing - opening - delivery + transactions.[000212] A view of the UI 1600 displaying information regarding meter drift impact is shown in FIG. 16F. Additional meter drift reflects possible loss based on how a fuel meter may have shifted from its original settings over time. The ELA application is aware of theAttorney Docket No.: 047376-351001 WO original settings from data received by the ELA application from the fueling station where the meter is located.[000213] Another view of the UI 1600 displaying information regarding meter drift impact is shown in FIG. 16G. In this illustrated implementation the UI 1600 shows total meter drift impact per day (across all selected tanks), shown on a bar plot in this illustrated implementation; total meter drift impact per tank, shown on a bar plot in this illustrated implementation; meter drift impacts per nozzle against the book transactions (as the meter impact should be proportional to estimated over- / under-dispensing in the period and transactions volume), shown on a scatter plot in this illustrated implementation; and meter drift impacts per nozzle (same as the meter drift impacts per nozzle (same as), shown as a drill-down table in this illustrated implementation, with the option to summarize per site and organization.[000214] Referring again to FIG. 16A, the impact of significant events reflects impact of events on fuel loss / gain that are not included in any of the calibration impact, the temperature impact, the known meter impact, and the meter drift impact. Examples of the significant events include possible causes of fuel loss or gain discussed herein, e.g., water ingress at a fuel tank, fuel dispenser leaks, fuel tank leaks, failed fuel tank testing, fuel theft (e.g., at a fuel dispenser or at a fuel tank), fuel spill during delivery of fuel to a fuel tank, etc. In an exemplary implementation, the ELA application is configured to allow the user to select which one or more of a plurality of significant events for the ELA application to evaluate and show via the UI 1600.[000215] As shown in this illustrated implementation, the impact of significant events can include a list of each identified significant event and its associated gain / loss impact. To determine the impact of significant events, the ELA application is configured to compensate the book variance using the data received from one or more fuel dispensers and the data received from each of one or more sensors. The ELA application can also receive data manually input by a user regarding a fuel tank and / or a fuel dispenser and use this received data in determining the impact of significant events. For example, a user may manually report an amount of fuel that was spilled during delivery of fuel to a fuel tank.[000216] Selecting the impact of significant events on UI 1600, such as by clicking on the arrow in the “Impact of Significant Events” box, clicking on the “Significant Events” tab onAttorney Docket No.: 047376-351001 WO the UI 1600, or otherwise selecting the impact of significant events, is configured to cause the ELA application to display on the UI 1600 information regarding significant events that allows the user to see details of the impact of significant events.[000217] A view of the UI 1600 displaying information regarding significant events I provided in FIG. 16H. In this illustrated implementation the UI 1600 shows impact over time, e.g., all significant events combined against date, to show how the significant events occur over time, shown on a bar plot in this illustrated implementation; total significant event impact per site, shown on a bar plot in this illustrated implementation; total significant impact per event type (across all selected sites and tanks), shown on a bar plot in this illustrated implementation; and significant events per site (same as the total significant event impact per site graph), shown as a drill-down table in this illustrated implementation, with the option to summarize per site and organization[000218] The ELA variance information shows the book variance information that the ELA application adjusted with the impact information. In this illustrated implementation the ELA variance information is -9.79M, indicating a 9.79M loss. The variance thus increased, e.g., the loss became greater, when the book variance is reduced by the variance attributed to the causes in the impact information.[000219] In some implementations, as in this illustrated implementation, the ELA application is configured to determine a top ten possible causes of the ELA variance based on an amount of gain / loss contributed by that cause. Instead of a top ten, the ELA application can be configured to determine another number of top possible causes, e.g., five, eight, fifteen, twenty, etc.[000220] The ELA application is configured to provide the top ten possible causes of the ELA variance to a user via the UI 1600. The top ten issues can be determined based on magnitude of impact, positive or negative. Thus, for example, an impact of -200 would be ranked higher than an impact of +100.[000221] In this illustrated embodiment, as shown in FIG. 16 A, the UI 1600 includes a “Top 10 Issues” button that a user can select, such as by clicking on the button or otherwise selecting the button, to cause the ELA application to display information regarding the top ten identified issues on the UI 1600.Attorney Docket No.: 047376-351001 WO[000222] A view of the UI 1600 displaying information regarding top issues is provided in FIG. 161. The information regarding the top issues in this illustrated implementation shows the top ten ELA contributors but another top number of issues can be shown, e.g., five, twelve, fifteen, etc. Each of the top issues is listed with an identification of the site (site name in this illustrated implementation) associated with the gain / loss, an identification of the tank (tank 1 = Tl, tank 2 = T2, etc. in this illustrated implementation) at the site associated with the gain / loss, an identification of the impact (e.g., meter setting, meter drift, calibration, temperature, etc.), and an amount attributed to the impact. The information regarding the top issues shows a full breakdown of all the sites contributing to the ELA variance in a list identifying each site (site name in this illustrated implementation), an identification of tank(s) at the site associated with the gain / loss, an identification of the impact (also referred to herein as a “factor”), and a sum attributed to the impact. A total of the sums is also shown and corresponds to the ELA variance.[000223] Referring again to FIG. 16A, the UI 1600 is configured to allow the user to access informational explanations of each of the raw information, the adjustment impacts information, the book variance information, the impact information, and the ELA variance information. In this illustrated implementation, the informational explanations are accessible by hovering over a “?” in the respective box on the UI 1600 to cause a pop-up box to appear, although other methods of access are possible.[000224] FIG. 16J illustrates another implementation of an ELA application UI 1600. Information shown on the ELA application UI 1600 of FIG. 16J is for a selected organization(a), a selected site at the selected organization, a selected fuel tank at the selected site, and in a selected date range. The selections are not shown in FIG. 16J. In this illustrated implementation, the raw variance information is -405.98K; the adjustment impacts information includes transactions information (58262.52), fuel stock information (0.00), and fuel delivery information (313320.48); the book variance information is -34.40K; the impact information includes tank calibration impact (-208.5), temperature impact (215.1), known meter impact (-13.8K), meter drift impact (-6K), and impact of significant events including water ingress at the fuel tank (-212), tank leak (-1072), and fuel theft (-12844); and the ELA variance information is -840.62. The ELA application UI of FIG. 10 includes a “Top 10 Issues” button configured to be selected by a user to allow the user to receive more information about possible top impacts contributing to the ELA variance.Attorney Docket No.: 047376-351001 WO[000225] FIG. 16K illustrates another implementation UI 1600 of an ELA application displaying information regarding top issues. In this illustrated implementation, ten top issues are listed and seventeen sites are listed in a full breakdown of all the sites contributing to the ELA variance, with a total attributed to the seventeen sites being -44493.[000226] FIG. 17 illustrates one implementation of a loss sources decomposition configured to be used by an ELA application as described herein.[000227] A block diagram of an example wetstock monitoring, analysis, and alerting system 1800 is provided in FIG. 18. In the illustrated implementation, the system 1800 includes a smart alerts application 1802, an EVR application 1804, and an ELA application 1806.[000228] The system 1800 is communicatively coupled to various components of a fueling station 1808. The fueling station 1808 includes fuel storage 1810 and a fuel dispenser 1816. The fuel storage 1810 includes numerous fuel tanks 1812. The fuel dispenser 1816 includes fuel nozzles 1822, each of which is connected to a respective fuel meter 1820 and a respective pump 1818. The fuel dispenser 1816 is coupled to the fuel storage 1810 by one or more fuel lines 1814. One or more sensors 1826 can be coupled to the fuel storage 1810, the fuel lines 1814, and / or the fuel dispenser 1816. In some implementations, the fueling station 1808 can include additional components such as, for example, a POS system or an onsite controller.[000229] As shown in FIG. 18, the system 1800 can be communicatively coupled to components of the fueling station 1808. In the illustrated implementation, the system 1800 is communicatively coupled to the sensor(s) 1826 and to the fuel dispenser 1816. The smart alerts application 1802 can be configured to use data provided by the sensor(s) 1826 and / or the fuel dispenser 1816 to provide alerts regarding wetstock losses from the fuel storage 1810. The EVR application 1804 can be configured to perform EVR analysis for the fueling station 1808 using the data provided by the sensor(s) 1826 and / or the fuel dispenser 1816. The ELA application 1806 can be configured to perform ELA for the fueling station 1808 using the data provided by the sensor(s) 1826 and / or the fuel dispenser 1816.[000230] While the system 1800 is depicted as being associated with a single fueling station 1808, in some implementations, the system 1800 is configured to perform wetstock monitoring, analysis, and alerting for multiple fueling stations. For example, the system 1800Attorney Docket No.: 047376-351001 WO can be configured to perform wetstock monitoring, analysis, and alerting at least two, at least five, at least 10, at least 25, at least 50, or at least 100 fueling stations.[000231] In some implementations, the disclosed applications, including the smart alerts application, the EVR application, and the ELA application can be accessed through a single master application. The master application can be configured to be accessed by a user via a UI provided via a computer system (e.g., a laptop computer, a desktop computer, an electronic tablet, a mobile telephone, etc.) in operative communication with the server or other computing system that is executing the master application.[000232J FIG. 19A illustrates a Ul 1900 of a master application. In FIG. 19A, the UI 1900 displays a master application dashboard. The dashboard includes an identification of the logged-in user (name “UserName” in this example) in an upper right corner, although the identification may be displayed elsewhere or may not be displayed at all. The master application dashboard shows a plurality of widgets (also referred to herein as “tiles”) each showing a different type of information. In this illustrated implementation the widgets include a Reports widget, a Nozzles / Tanks widget, a Low Stock Level widget, a Deliveries widget, an Alarms Status widget, and a Water Reading Status widget. In an exemplary implementation, the tiles that are visible on the master application dashboard can be chosen by a user of the master application dashboard, and an arrangement of multiple tiles can be customized by a user.[000233] The Reports widget shows reports available to the user. Clicking, or otherwise selecting, one of the reports in the Reports widgets is configured to allow the user to view the report. In this illustrated implementation the reports include Investigation Summary, Daily Reconciliation, Tank Criticality, Period Summary, Potential Overfill, and Protentional Lost Transactions.[000234] Selection of the Investigation Summary report is configured to show ELA analysis performed by an ELA application. The ELA analysis is configured to be provided via an ELA application UI, such as the ELA application UI 1600 of FIG. 16A.[000235] Selection of the Daily Reconciliation report is configured to show reconciliation of transactions by day, such as for the current day, one selected day, or a plurality of selectedAttorney Docket No.: 047376-351001 WO days. The reconciliation of transactions is based on fuel transaction data received by the master application.[000236] Selection of the Tank Criticality report is configured to show critical issues associated with any fuel tanks being monitored by the user.[000237] Selection of the Period Summary report is configured to show a summary of information for a selected period of time.[000238] Selection of the Potential Overfill report is configured to identify any one or more fuel tanks among the one or more fuel tanks being monitored by the user that have been potentially overfilled in a fuel delivery. A volume of each of the fuel tank(s) is known by the master application, e.g., as reported by an ATG associated with the fuel tank or as reconciled by the ELA application that is part of the master application. Deliveries of fuel are reported to the master application via the Deliveries Widget, discussed further below, so the master application knows an amount of fuel delivered to a particular fuel tank. The master application is configured to compare the volume of a fuel tank with a total amount of fuel in the fuel tank (amount of fuel delivered to the fuel tank added to a previous known amount of fuel in the fuel tank). If the total amount of fuel in the fuel tank is greater than the volume of the fuel tank, the fuel tank has been potentially overfilled.[000239] Selection of the Protentional Lost Transaction report is configured to show anticipated future lost transactions.[000240] The Nozzles / Tanks widget shows information regarding nozzles and tanks at the fuel storage facility / facilities being monitored by the user. Multiple types of information is available via the Nozzles / Tanks widget. The Nozzles / Tanks widget is configured to allow a user to view all of the types of information, e.g., by clicking on or otherwise selecting “View All,” or a selected one of the types of information, e.g., by selecting one of the types of information from a drop down menu. The types of information in this illustrated implantation are flow rate, tank out of use, and nozzle out of use.[000241] Maintaining flow rate is important because slower flow rates than expected negatively impact fueling customer experience because it takes longer to pump fuel through a nozzle than expected, which may cause the customer to stop pumping fuel before the customer would have otherwise stopped pumping fuel, thus reducing an amount paid to aAttorney Docket No.: 047376-351001 WO seller of the fuel, may cause a fuel dispenser to break and be unusable, and / or may cause the customer to not visit that fueling station in the future, thereby causing lost transactions. In this illustrated implementation, with Flow Rate selected, the Nozzles / Tanks widget shows an overview of flow rate for all the nozzles at the fuel storage facility / facilities being monitored by the user including an identification of a fuel associated with each of the nozzles and a number of nozzles associated with each of the flow rates. In this illustrated implementation the overview of flow rate is shown in a graph.[000242] In this illustrated implementation the types of fuels include unleaded, diesel, petrol, and compressed natural gas (CNG). Knowing the types of fuel may be useful to the user in identifying whether a certain type of fuel is having more flow rate problems than other types of fuels. For example, diesel filters tend to become clogged faster than filters for other types of fuels, so the Flow Rate widget indicating problematic nozzles for diesel may allow for the diesel filters to be cleaned or replaced before the flow rate becomes any slower due to a clogged filter.[000243] In this illustrated implementation the flow rates for the nozzles include slow flow, heavy goods vehicle (HGV) slow flow, declining flows, and OK flow. The slow flow identifies nozzles having a slower flow rate than a flow rate known by the master application. The HGV slow flow HGV fuel is pumped at a higher rate than non-HGV fuel, typically about twice as high. Thus, looking at an individual HGV fuel flow rate may not appear to be slow when the flow rate is slower than expected for HGV fuel. The declining flow identifies nozzles that have a flow rate trending downward, which may allow for those nozzles to be referred for maintenance before the flow rate declines further. The OK flow indicates nozzles with an expected, OK flow rate.[000244] With Nozzle Out of Use selected, the Nozzles / Tanks widget shows an overview of nozzles out of use for all the nozzles at the fuel storage facility / facilities being monitored by the user including an identification of a fuel associated with each of the nozzles and a number of nozzles out of use. Since information shown on a UI via the master application is configured to be real time based on the most recent data, the number of nozzles out of use is a current reflection of nozzles out of use for that day. Knowing a number of nozzles out of use for a day is important because a higher number of nozzles out of use than expected in a day may help explain lower transactions than expected.Attorney Docket No.: 047376-351001 WO[000245] A view of the UI 1900 following selection of the Nozzles widget is shown in FIG. 19B. In this illustrated implementation grades of fuels associated with nozzles out of use include unleaded, super unleased, diesel, super diesel, and CNG. A percentage of all nozzles associated with a particular grade of fuel is provided on the UI 1900 for one or more of the fuel types. The UI 1900 in this illustrated implementation shows percentages for the top four fuel grades having nozzles out of use: unleaded (7.50%), super unleased (3.75%), super diesel (3.75%), and diesel (7.5%). The UI 1900 in this illustrated implementation also shows information indicating a percentage of a total number of the nozzles out of use for a certain amount of time: 7.50% nozzles out of use for the prior 2 days, 3.75% of nozzles out of use for the prior 7 days, and 3.75% of nozzles out of use for the prior 30 days. Knowing how long certain nozzles have not been used for any fuel transactions may help a fueling station owner or other interested party make decisions such as evaluating size of future fueling stations and whether to close a certain fueling station. The UI 1900 in this illustrated implementation also shows a listing of each site for each company being monitored by the user and for each site information for one nozzle including a site identification (ID), a tank ID, a fuel dispenser (pump) ID, a nozzle ID, a grade of fuel dispensable from the nozzle, a date of a last transaction for fuel dispensed from the nozzle, a length of time elapsed since the last transaction, and a number of days of fuel stock available for dispensing from the nozzle.[000246] Referring again to FIG. 19A, with Tank Out of Use selected, the Nozzles / Tanks widget shows an overview of tanks similar to the overview of nozzles discussed above regarding selection of Nozzle Out of Use. The overview of tanks shows out of use for all the tanks at the fuel storage facility / facilities being monitored by the user including an identification of a fuel associated with each of the tanks and a number of thanks out of use.[000247] The Low Stock Level widget shows information regarding fuel stock in the fuel tanks at the fuel storage facility / facilities being monitored by the user. Knowing fuel stock may help a fueling station owner or other interested party make decisions about fuel deliveries, e.g., when to order a fuel delivery, how often a tank should be refilled, whether a new fuel delivery company should be used, etc. Multiple types of information is available via the Low Stock Level widget. The Low Stock Level widget is configured to allow a user to view all of the types of information, e.g., by clicking on or otherwise selecting “View All,” or a selected one of the types of information, e.g., by selecting one of the types of informationAttorney Docket No.: 047376-351001 WO from a drop down menu. The types of information in this illustrated implantation are low stock level and stock levels.[000248] In this illustrated implementation, the Low Stock Level widget shows an overview of stock level for all the tanks at the fuel storage facility / facilities being monitored by the user. In this illustrated implementation the overview of stock level is shown in a graph. In this illustrated implementation, the overview of stock level is for 7641 tanks and the graph indicates tanks having an OK stock level (173 tanks, 2.3% of total) and tanks having a low stock level (7468 tanks, 97.7% of total).[000249J The Deliveries widget shows information regarding confirmation status of fuel deliveries to tanks at the fuel storage facility / facilities being monitored by the user. In this illustrated implementation, the Deliveries widget shows an overview of fuel delivery confirmation for all the tanks at the fuel storage facility / facilities being monitored by the user. In this illustrated implementation the overview of fuel delivery confirmation is shown in a graph. In this illustrated implementation, the overview of fuel delivery confirmation is for 7641 tanks and the graph indicates 173 tanks have had deliveries confirmed (2.3% of total) and indicates 7468 tanks not having had deliveries confirmed (97.7% of total).[000250] The Deliveries widget is configured to allow a user to view all of the types of information, e.g., by clicking on or otherwise selecting “View All,” or a selected one of the types of information, e.g., by selecting one of the types of information from a drop down menu. The types of information in this illustrated implantation are data submission (Submit Data) and delivery confirmation (Confirm Deliveries).[000251] Data submission allows a user to submit an amount of fuel delivered to a particular fuel tank in a particular fuel delivery. The master application will know fuel level in a particular tank based on data received one or more sensors configured to acquire data characterizing the fuel stored in the fuel tank. The master application may thus be able to determine that a delivery occurred because a fuel level in a particular tank increases. However, the master application cannot determine whether the correct amount of fuel was delivered to the fuel tank without knowing the amount of fuel that was intended to be delivered to the fuel tank in that particular delivery. The amount of fuel that was intended to be delivered to the fuel tank in that particular delivery, e.g., as reflected in paperwork provided to the fueling station by a fuel delivery person, is submitted by selecting the SubmitAttorney Docket No.: 047376-351001 WOData option, which causes the UI 1900 to display a data submission view. The unconfirmed deliveries for fuel tanks shown in the Deliveries widget indicate that fuel increases in the fuel tank have been detected by the master application but that fuel delivery information has not yet been submitted to confirm a fuel delivery.[000252] In some implementations, if there is a discrepancy between the amount of fuel increase in a fuel tank and the intended amount of fuel to be delivered as reflected in confirmed delivery information, the master application is configured to generate an alert.[000253] The Alarms Status widget shows currently identified alarms associated with the fuel storage facility / facilities being monitored by the user. In this illustrated implementation the Alarms Status widget shows a number of active alarms and a number of active investigations, e.g., investigations into possible causes of active alarms. In this illustrated implementation the Alarms Status widget shows that there are 12 active investigations.[000254] In this illustrated implementation the Alarms Status widget shows that there are 3641 active alarms for the fuel storage facility / facilities being monitored by the user and the top types of alarms contributing to the total number of alarms. In this illustrated implementation the top types of alarms are daily alerts (300), ATG / site controller alarms (300 and 250), smart alarms (also referred to herein as “smart alerts”) (1432), real time reconciliation alarms (real time transactions reconciliation alarms), sir alerts (16), ALDTLR alerts (300), and data submission alerts (300).[000255] The Water Reading Status widget shows an overview of water readings in fuel tanks at the fuel storage facility / facilities being monitored by the user. The water readings are based on data received one or more sensors configured to acquire data characterizing the fuel stored in the fuel tanks. The overview of water readings in this illustrated implementation shows water reading information for the prior twenty-four hours, although information may be shown for another period of time. In this illustrated implementation water readings information is shown for 9468 tanks as: 30 tanks having lOmm-O.Olmm water (coded green to show low concern level), 46 tanks having 24.99mm-10.01mm water (coded yellow to show medium concern level), 1365 tanks having at least 25mm water (coded red to show high concern level), and 4770 tanks with no water readings being collected (coded grey to show no classified concern level).Attorney Docket No.: 047376-351001 WO[000256] As shown in FIG. 19C, the master application can be configured to display on the UI 1900 information regarding water readings in response to a user selection of the Water Reading Status widget. The UI 1900 in this illustrated implementation shows a number of fuel tanks in each of the four water level categories: 30 tanks having lOmm-O.Olmm water (coded green to show low concern level), 45 tanks having 24.99mm-10.01mm water (coded yellow to show medium concern level), 1357 tanks having at least 25mm water (coded red to show high concern level), and 3146 tanks with no water readings being collected (coded grey to show no classified concern level) for a total of 9468 tanks. The UI 1900 in this illustrated implementation also shows a listing of each site being monitored by the user and for each site information for one tank including, a tank number, a grade of fuel stored in the tank (in this illustrated implementation: unleaded, super unleaded, diesel, super diesel, and CNG), a water level for the day prior to the current day, a previous water reading, a latest water reading (color-coded as in the overview), a date of the latest water reading, a status of the water level reading (in this illustrated implementation: ongoing issue or new issue), and an increased status (indicating whether or not the water reading has increased from the previous water level reading).[000257] In some implementations, the master application does not include the ELA application but does include one or more other applications.[000258] The disclosed methods and applications can be implemented using any suitable computer system. An example computer system 2000 is provided in FIG. 8. In some implementations, the computer system 2000 can execute all or part of the methods 20 (FIG. 2), 40 (FIG. 4), 50 (FIG. 5), 70 (FIG. 7), 1100 (FIG. 11), and / or 1400 (FIG. 14). In some implementations, the computer system 2000 can execute a smart alerts application (e.g., the smart alerts application 304 of FIG. 3 or the smart alerts application 1802 of FIG. 18), an EVR application (e.g., the EVR application 804 of FIG. 8 or the EVR application 1804 of FIG. 18), and / or an ELA application (e.g., the ELA application 1504 of FIG. 15 or the ELA application 1806 of FIG. 18).[000259] The computer system 2000 can include at least one processor 2050 and non- transitory computer readable memory storage (e.g., memory 2052) containing instructions that cause the processor 2050 to perform operations. The processor 2050 is coupled to an input / output (I / O) interface 2054 for sending and receiving communications from other components, including, for example, a sensor that is operatively coupled to a fuel tank (e.g.,Attorney Docket No.: 047376-351001 WO the sensors 130 shown in FIG. 1A), a fuel meter of a fuel dispenser, a POS system (e.g., the POS system 150 shown in FIG. 1A), and / or an onsite controller (e.g., the onsite controller 170 shown in FIG. 1).[000260] In some implementations, the disclosed methods are implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structural means disclosed in this specification and structural equivalents thereof, or in combinations of them. In some implementations, the disclosed methods are implemented as one or more computer program products, such as one or more computer programs tangibly embodied in an information carrier (e.g., in a machine-readable storage device), or embodied in a propagated signal, for execution by, or to control the operation of, data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). A computer program (also known as a program, software, software application, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file. A program can be stored in a portion of a file that holds other programs or data, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.[000261] The processor 2050 can include any type of data processor suitable for the execution of a computer program. Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any processor of any type of digital computer. The processor 2050 can execute one or more computer programs to perform the disclosed methods, all or in part, by operating on input data and providing output data.[000262] The memory 2052 can include any suitable information carrier for embodying computer program instructions and data. In some implementations, the memory 2052 includes read-only memory, random-access memory, non-volatile memory, including, in some implementations, semiconductor memory devices, (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks, (e.g., internal hard disks or removable disks), magneto-Attorney Docket No.: 047376-351001 WO optical disks, and optical disks (e.g., CD and DVD disks), or a combination thereof. In some implementations, the memory 2052 includes one or more mass storage devices for storing data, for example, magnetic, magneto-optical disks, or optical disks.[000263] In some implementations, the computer system 2000 is implemented as a laptop computer, a desktop computer, a server, or the like. In some implementations, the computer system 2000 is implemented as or includes special purpose logic circuitry, for example, an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).[000264] The computer system 200 can, among other things, monitor parameters of, for example, a fueling station and can send signals to actuate and / or adjust various components of, for example, the fueling station. In certain instances, the computer system 2000 can communicate status with and send actuation and / or control signals to one or more of the various components of the fueling station. The computer system 2000 can be configured to perform its functions with various degrees of autonomy.[000265] To provide for interaction with a user, the computer system 800 can include a display device 2056, for example, a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to a user and a keyboard and a pointing device, (e.g., a mouse or a trackball), by which the user can provide input to the computer system 2000. In some implementations, the computer system 2000 can include additional devices for facilitating interaction with a user. For example, the computer system 2000 can be configured to provide sensory feedback to the user (e.g., visual feedback, auditory feedback, or tactile feedback), and can be configured to receive input from the user in any form, for example, acoustic, speech, or tactile input.[000266] In some implementations, the display 2056 is remote from, for example, the processor 2050. The display 2056 can be, for example, a display or a monitor of a second computer system, for example, a user device such as a user’s laptop or desktop computer. The processor 2050 can be configured to display a user interface for, e.g., a smart alarms application, an EVR application, an ELA application, or the like on the display 2056. In some implementations, the computer system 2000 can include more than one display 2056. For example, the processor 2050 can be configured to display a user interface on two or more user devices.Attorney Docket No.: 047376-351001 WO[000267] In some implementations, the computer system 2000 includes a back-end component (e.g., a data server), a middleware component (e.g., an application server), or a front-end component (e.g., a client computer having a graphical user interface or a web interface through which a user can interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, and front-end components. The components of the system can be interconnected by any form or medium of digital data communication, for example, a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), in some implementations, the Internet.[000268] A computer system such as the computer system 2000 that is configured to monitor, analyze, and provide alerts regarding wetstock can assess a greater amount and a greater variety of data characterizing wetstock as compared to, for example, the amount and variety of data that a storage facility operator can manually evaluate. Furthermore, by leveraging computational techniques such as machine learning, such a computer system can detect features in data characterizing wetstock that are indicative of potential wetstock issues before said features are manually identifiable. Accordingly, such a computer system can identify potential wetstock losses more efficiently and more accurately than a manual evaluator (or team of manual evaluators).[000269] A computer system such as the computer system 2000 that is configured to monitor, analyze, and provide alerts regarding wetstock can provide information regarding wetstock analyses (e.g., information regarding EVR analysis or ELA) and alerts regarding wetstock losses to users through one or more user interfaces (e.g., a UI of a smart alarms application, a UI of an EVR application, a UI of an ELA application, etc.). The UI(s) can enable vital information and urgent alerts to be provided in an easily digestible manner that facilitates efficient addressing of wetstock issues. Moreover, the UI(s) can quickly inform users of urgent issues and, if multiple issues are present, allow users to efficiently determine which issues to prioritize. In some implementations, the UI(s) enable alerts and information regarding multiple different fueling stations to be reviewed by a single user, thereby, for example, providing insights into potentially systemic issues affecting more than one fueling station. For example, the UI(s) can provide insight into equipment failures that are occurring in the same model of equipment at multiple different fueling stations, insight into potentialAttorney Docket No.: 047376-351001 WO theft from multiple different locations, or insight into environmental issues impacting multiple different fueling stations.[000270] In some implementations, by providing information regarding wetstock analyses (e.g., information regarding EVR analysis or ELA), as well as alerts regarding wetstock losses through a user interface (e.g., a UI of a smart alarms application, a UI of an EVR application, a UI of an ELA application, etc.), a computer system such as the computer system 2000 enables multiple users to receive information and alerts simultaneously. The UI can also enable information and alerts to be provided to a user regardless of the user’s location. In particular, the UI can provide information and alerts to a user on a personal device such as a smartphone or a laptop to which they always have access, thereby enabling the user to take actions to address wetstock issues even when the user is not physically present at the fueling station that is being monitored by the computer system.[000271] In some implementations, a computer system such as the computer system 2000 that is configured to monitor, analyze, and provide alerts regarding wetstock can be integrated with a control system for a fueling station to, for example, enable detected wetstock issues to be automatically or semi-automatically addressed. For example, such a computer system may be configured to receive data characterizing wetstock (from, e.g., one or more sensors, one or more fuel meters, etc.), identify an issue, provide an alert to a user regarding the issue (e.g., by displaying an icon indicative of the loss on a user interface of an application that the user accesses via another computer system), and, upon approval from the user, transmit control signals to one or more components of the fueling station to address the cause of the issue. For example, if the issue is determined to be a sensor error or a meter error, the computer system can be configured to alert the user regarding the error and transmit signals to the sensor or the meter to, e.g., recalibrate or reconfigure the sensor or the meter without direct user intervention.[000272] The techniques described herein can be implemented using one or more modules. As used herein, the term “module” refers to computing software, firmware, hardware, and / or various combinations thereof. At a minimum, however, modules are not to be interpreted as software that is not implemented on hardware, firmware, or recorded on a non-transitory processor readable recordable storage medium (i.e., modules are not software per se). Indeed “module” is to be interpreted to always include at least some physical, non-transitory hardware such as a part of a processor or computer. Two different modules can share theAttorney Docket No.: 047376-351001 WO same physical hardware (e.g., two different modules can use the same processor and network interface). The modules described herein can be combined, integrated, separated, and / or duplicated to support various applications. Also, a function described herein as being performed at a particular module can be performed at one or more other modules and / or by one or more other devices instead of or in addition to the function performed at the particular module. Further, the modules can be implemented across multiple devices and / or other components local or remote to one another. Additionally, the modules can be moved from one device and added to another device, and / or can be included in both devices.[000273] Approximating language, as used herein throughout the specification and claims, may be applied to modify any quantitative representation that could permissibly vary without resulting in a change in the basic function to which it is related. Accordingly, a value modified by a term or terms, such as “about” and “substantially,” are not to be limited to the precise value specified. In at least some instances, the approximating language may correspond to the precision of an instrument for measuring the value. Here and throughout the specification and claims, range limitations may be combined and / or interchanged, such ranges are identified and include all the sub-ranges contained therein unless context or language indicates otherwise.[000274] A person skilled in the art will appreciate that a value referred to as “constant” may not be precisely constant but nevertheless be considered to be substantially constant for any one or more reasons, such as manufacturing tolerances and sensitivity of measurement equipment.[000275] While this disclosure contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular implementations of particular inventions. Certain features that are described in this disclosure in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination. Moreover, although features may be described as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.Attorney Docket No.: 047376-351001 WO[000276] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Moreover, the separation of various system components in the implementations described should not be understood as requiring such separation in all implementations, and it should be understood that the described components and systems can generally be integrated together in a single product or packaged into multiple products.[000277] Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results.[000278] Other implementations can be within the scope of the following claims.

Claims

Attorney Docket No.: 047376-351001 WOCLAIMS1 . A method comprising: receiving data characterizing wetstock in one or more fuel tanks of a fueling station; identifying an occurrence of wetstock loss by an artificial intelligence (Al) engine in response to receiving the data; determining a cause of the wetstock loss by the Al engine; and providing, to a user interface displayed on one or more user devices: an alert regarding the occurrence of the wetstock loss, the alert comprising an indication of the cause of the wetstock loss; and a selectable widget configured to receive a user request for additional information regarding the occurrence of the wetstock loss or the cause of the wetstock loss.

2. The method of claim 1 , wherein receiving the data comprises receiving data from one or more sensors coupled to the one or more fuel tanks.

3. The method of claim 1, wherein the data comprises data characterizing a volume of fuel in each fuel tank of the one or more fuel tanks, data characterizing a temperature of fuel in each fuel tank of the one or more fuel tanks, data characterizing an environment of the fueling station, data characterizing a flow rate of fuel through fuel lines connected to the one or more fuel tanks, data characterizing fuel transactions, data characterizing fuel deliveries, or a combination thereof.

4. The method of claim 1, wherein identifying the occurrence of the wetstock loss comprises applying a machine learning (ML) model to determine that a variance of the data is outside of a learned variance interval.

5. The method of claim 1, wherein identifying the occurrence of wetstock loss comprises: applying a ML model to provide a representation of the data; and comparing a parameter characterizing the representation of the data to a learned parameter value.

6. The method of claim 5, wherein the ML model comprises a regression model.Attorney Docket No.: 047376-351001 WO7. The method of claim 1, wherein providing the alert comprises displaying a visual indicator representing the alert on the user interface.

8. The method of claim 1, wherein the alert indicates drainback to a fuel tank of the one or more fuel tanks.

9. The method of claim 1 , wherein the alert indicates a leak in a fuel line associated with a fuel tank of the one or more fuel tanks.

10. The method of claim 1, wherein the alert indicates a leak in a fuel meter of a fuel dispenser connected to the one or more fuel tanks.

11. The method of claim 1 , wherein the alert indicates a leak in a fuel tank of the one or more fuel tanks.

12. A system comprising: at least one processor; and non-transitory memory storing instructions which, when executed by the at least one processor, cause the at least one processor to perform operations comprising: receiving data characterizing wetstock in one or more fuel tanks of a fueling station; identifying an occurrence of wetstock loss by an artificial intelligence (Al) engine in response to receiving the data; determining a cause of the wetstock loss by the Al engine; and providing, to a user interface displayed on one or more user devices: an alert regarding the occurrence of the wetstock loss the alert comprising an indication of the cause of the wetstock loss; and a selectable widget configured to receive a user request for additional information regarding the occurrence of the wetstock loss or the cause of the wetstock loss.

13. The system of claim 12, further comprising one or more sensors configured to couple to the one or more fuel tanks and to the at least one processor, wherein receiving the data comprises receiving data from the one or more sensors.

14. The system of claim 12, wherein the data comprises data characterizing a volume of fuel in each fuel tank of the one or more fuel tanks, data characterizing a temperature of fuelAttorney Docket No.: 047376-351001 WO in each fuel tank of the one or more fuel tanks, data characterizing an environment of the fueling station, data characterizing a flow rate of fuel through fuel lines connected to the one or more fuel tanks, data characterizing fuel transactions or transactions, data characterizing fuel deliveries, or a combination thereof.

15. The system of claim 12, wherein identifying the occurrence of the wetstock loss comprises applying a machine learning (ML) model to determine that a variance of the data is outside of a learned variance interval.

16. The system of claim 12, wherein identifying the occurrence of wetstock loss comprises: applying a ML model to provide a representation of the data; comparing a parameter characterizing the representation of the data to a learned parameter value.

17. The system of claim 12, wherein the alert indicates drainback to a fuel tank of the one or more fuel tanks, a leak associated with a fuel tank of the one or more fuel tanks, or a combination thereof.

18. The system of claim 12, wherein the ML model comprises a regression model.

19. The system of claim 12, wherein providing the alert comprises displaying a visual indicator representing the alert on the user interface.

20. A non-transitory computer readable storage medium storing instructions which, when executed by at least one processor, cause the processor to perform operations comprising: receiving data characterizing wetstock in one or more fuel tanks of a fueling station; identifying an occurrence of wetstock loss by an artificial intelligence (Al) engine in response to receiving the data; determining a cause of the wetstock loss by the Al engine; and providing, to a user interface displayed on one or more user devices: an alert regarding the occurrence of the wetstock loss the alert comprising an indication of the cause of the wetstock loss; and a selectable widget configured to receive a user request for additional information regarding the occurrence of the wetstock loss or the cause of the wetstock loss.

Images