Patent Description:
Ascertaining a fluid level within a tank, such as a liquid petroleum gas (LPG) tank, within a system is an important step to determine when to replace or refill the tank. Some level measurement techniques require an opening or penetration through the tank to detect a level. For instance, a mechanical sensor may utilize a suspended float that changes position at different levels, which then provides a reading to a gauge mounted on the outside of the tank. Other techniques may be contactless, but still require an opening. For example, an ultrasound device may be inserted into and suspended from a top wall of a tank to detect a level.

Other solutions may be exterior to the tank and detect a level without an opening. For instance, a temperature sensitive tape can be placed on the exterior surface of the tank to provide a visual indication of the level. In another example, a device, which is similar to a stud finder in some respects, is passed over the exterior of the tank by an operator to determine the level.

These solutions merely provide a level indication local to the tank. Physical inspection of the tank is required in order to ascertain the status.

<CIT> discloses an ultrasonic liquid level measuring system that can be placed within a support ring having wheels (a dolly). The tank to be measured may be supported by the wheeled support ring surrounding the measuring system. <CIT> discloses an ultrasonic liquid level monitoring system wherein a measurement sensor is mounted on the bottom of a tank and a communications unit is mounted on the top of the tank. Both components are housed in separate shells which do not support the tank. <CIT> discloses a variety of sensor devices for measuring a product level in a tank. <CIT> discloses a tank level measuring system, wherein a measurement sensor is mounted separately from a communications unit in components which are not used to support the tank. <CIT> discloses a level sensor system according to the preamble of claim <NUM>.

A simplified summary is provided herein to help enable a basic or general understanding of various aspects of exemplary, non-limiting embodiments that follow in the more detailed description and the accompanying drawings. This summary is not intended, however, as an extensive or exhaustive overview. Instead, the sole purpose of the summary is to present some concepts related to some exemplary non-limiting embodiments in a simplified form as a prelude to the more detailed description of the various embodiments that follow.

In various, non-limiting embodiments, a sensor assembly is positioned on an exterior of a tank to measure a fluid level within the tank. The sensor assembly includes a sensor device and a control circuit configured to drive the sensor device and evaluate readings to determine the fluid level. The sensor assembly further includes a communications interface to enable communication with a management system via a communications network. The management system can store information (e.g. fill status) related to the tank and additionally communicate with vendors or end users to coordinate resupply, level analysis, etc..

These and other embodiments are described in more detail below.

Various non-limiting embodiments are further described with reference the accompanying drawings in which:.

As discussed in the background, measurements of fluid level in a tank (e.g. an LPG tank) may utilize an opening into the tank and/or provide measurements for local consumption only. Such devices do not provide robust monitoring and management of the tank and physical inspection of the tank and system in which the tank is deployed is often necessary.

In various, non-limiting embodiments, a system and associated methods are provided for tank management. A sensor assembly is associated with a tank. The sensor assembly includes a level sensor to provide a sensor reading indicative of a fluid level within the tank. A control circuit of the sensor assembly interprets the sensor reading and may utilize a communications interface to communicate a level measurement to a remote system and/or a client device in proximity to the tank. Accordingly, the tank can be monitored and managed off-site.

The above noted features and embodiments will be described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout.

<FIG> shows a schematic block diagram of an exemplary, non-limiting embodiment of an Internet-enabled tank management system. System <NUM> can include a tank <NUM>, which is communicatively coupled to a cloud-based system <NUM> and/or a client device <NUM>. The client device <NUM> may also be communicatively coupled with the cloud-based system <NUM>.

As shown in <FIG>, tank <NUM> may be a portable gas cylinder. In <FIG>, a top of the tank <NUM> is facing up and a bottom of the tank <NUM> is facing down. Tank <NUM> is configured to store a suitable liquified pressurized gas, such as liquid petroleum gas. A cylinder stand or foot ring may be attached to the tank <NUM> as shown. The tank <NUM> may be made of a suitable material, such as metal, and the foot ring may be made of a suitable non-metal material, such as plastic. The tank includes an upper portion having a valve port, a lower portion, and a collar (see <FIG>) secured to the lower portion. A suitable handle assembly may be attached to the tank <NUM> at the upper portion. The tank <NUM> can include one or more liners of a material. For instance, the tank <NUM> can include a liner made of a first material, which may be at least one of a metal (e.g. steel, stainless steel, aluminum, etc.), a plastic (e.g. thermoplastic) among others. In certain embodiments, the container can include a wrapping of a second shell, which may be a composite material made of a glass fiber, carbon fiber, or aramid fiber with a thermoplastic or thermoset resin.

The collar may be secured to the lower portion in any suitable manner, such as by welding, or may alternatively be integrally formed with the lower portion. The collar, which may be a circular collar, includes a base that is attached to the lower portion, and a flange extending around and radially outwardly from the base. The flange includes a plurality of notches circumferentially spaced around the flange inward from an edge of the flange. The collar may be made of a suitable material, such as metal, and may be made in a suitable manner, such as pressing. The notches prevent the metal collar from cracking as it is bent during pressing and additionally serve to receive rotational lock clips on the foot ring.

As shown in <FIG>, the tank <NUM> may include indicia <NUM> that provides a tank identification. The indicia <NUM> may provide a machine-readable and/or a human-readable variant of the tank identification. In one embodiment, the indicia <NUM> may be a RFID tag or a NFC transceiver and positioned within the handle assembly. In another embodiment, the indicia <NUM> may be a barcode or a QR code. In an example, the tank identification provided by indicia <NUM> may be unique to tank <NUM> and utilized to retrieve or access information associated with tank <NUM>, request resupply of tank <NUM>, request service on tank <NUM>, request replacement of tank <NUM>, etc. For example, client device <NUM> can retrieve the tank identification from indicia <NUM> and access such functionality via the cloud-based system <NUM>.

A sensor assembly <NUM> is provided on tank <NUM>. For example, as shown in <FIG>, the sensor assembly <NUM> may be housed within the foot ring. Turning to <FIG>, a more detailed illustration of sensor assembly <NUM> in conjunction with tank <NUM> is depicted. The tank <NUM> contains a fluid <NUM> such as a liquid petroleum gas. The fluid <NUM> fills tanks <NUM> to a level <NUM>. Sensor assembly <NUM> is housed within a footring <NUM> and positioned adjacent to tank <NUM>. Specifically, sensor assembly <NUM> is at least partially situated within a surface feature <NUM> or recess formed on a bottom surface <NUM> of tank <NUM>. Surface feature <NUM> may include a generally convex-shaped interface <NUM> for a sensor device <NUM>. The sensor device <NUM> includes an ultrasound sensor <NUM> separated from the interface <NUM> with a gel layer <NUM>. The ultrasound sensor <NUM> may be stabilized with a spring <NUM> or memory foam to maintain contact with interface <NUM>.

The ultrasound sensor <NUM> is coupled to an electronics device <NUM> supplied with power from a battery <NUM>. The sensor assembly <NUM>, including the ultrasound sensor <NUM>, electronics device <NUM>, and battery <NUM> are surrounded by a shock absorbing material <NUM> and housed within footring <NUM>. Footring <NUM> is mounted and secure to the tank <NUM> via a collar <NUM> (described above).

As shown in <FIG>, in one embodiment, the ultrasound sensor <NUM> is positioned to be parallel with respect to fluid level <NUM>. In a further embodiment, the electronics device <NUM> and battery <NUM> may be encapsulated in a resin approved for use in explosive atmospheres.

According to another embodiment, <FIG> illustrates the sensor assembly <NUM> positioned at a center of tank <NUM> and within a stand base <NUM>. In this embodiment, a bottom surface of tank <NUM> may be unaltered. For instance, when the sensor assembly <NUM> is positioned at the center, the surface feature <NUM> may be eliminated. In addition, a conventional bottom surface of the tank <NUM> may provide an interface similar to convex-shaped interface <NUM> described above. Still further, the gel layer <NUM> may be utilized in this embodiment as well as the spring <NUM> or memory foam described above.

Turning to <FIG>, a schematic diagram of sensor assembly <NUM> is illustrated. Sensor assembly <NUM> includes one or more sensors <NUM>, such as ultrasound sensor <NUM> and/or a temperature sensor, coupled to a control circuit <NUM>, which is powered by power source <NUM>, such as battery <NUM>. The sensor <NUM> provides a sensor reading (e.g. an ultrasound signal or a temperature signal) to control circuit <NUM>.

In one example, the control circuit <NUM> may interpret the sensor reading from an ultrasound sensor into a fluid level. The fluid level may be stored by control circuit <NUM> and/or communicated, via communications interface <NUM>, to cloud-based system <NUM> and/or client device <NUM>.

In another example, the control circuit <NUM> may interpret a temperature signal from a temperature sensor. The control circuit <NUM> may store or communicate the temperature reading. In another aspect, the control circuit <NUM> may compare the temperature reading to a threshold and issue an alarm, for example, via communications interface <NUM>, when the temperature reading exceeds the threshold.

Turning to <FIG>, illustrated is a schematic block diagram of an exemplary, non-limiting embodiment for control circuit <NUM>. As shown in <FIG>, control circuit <NUM> includes one or more processor(s) <NUM> configured to executed computer-executable instructions <NUM> such as instructions composing a control and communication process for sensor assembly <NUM>. Such computer-executable instructions can be stored on one or more computer-readable media including non-transitory, computer-readable storage media such as memory <NUM>. For instance, memory <NUM> can include non-volatile storage to persistently store instructions <NUM>, settings <NUM> (e.g. configuration settings, calibration settings, identification information, etc.), and/or data <NUM> (e.g., sensor data, battery status, etc.). Memory <NUM> can also include volatile storage that stores instructions <NUM>, other data (working data or variables), or portions thereof during execution by processor <NUM>.

Control circuit <NUM> includes a communication interface <NUM> to couple control circuit <NUM>, via the Internet or other communications network, to various remote systems such as, but not limited to, backend systems, client devices, other controllers, or Internet-enabled devices (e.g., IoT sensors). Communication interface <NUM> can be a wired or wireless interface including, but not limited, a WiFi interface, an Ethernet interface, a Bluetooth interface, a fiber optic interface, a cellular radio interface, a satellite interface, etc. The communications interface <NUM> can be configured to communicate with client devices and/or cloud-based systems through a local area network co-located with the tank system (e.g. a home network) as described above. The communications settings, thus established, can be stored in memory <NUM>. According to various embodiments, the communication interface <NUM> may utilize communication technologies such as, but not limited to, SigFox, NB-IoT, <NUM>, <NUM>, Lora, or the like.

Using the communication interface <NUM>, the control circuit <NUM> may carry out wireless sniffing. In particularly, the control circuit <NUM> may utilize the communication interface <NUM> to locate nearby wireless access points, determine respective signal strengths, etc. Such information may facilitate geo-locating the tank <NUM>, for example.

A component interface <NUM> is also provided to couple control circuit <NUM> to various components of the sensor assembly <NUM>. For instance, component interface <NUM> can connect control circuit <NUM> to sensors (such as ultrasound sensor <NUM>) or input/output devices (e.g., buttons, indicators, LEDs, displays, etc.). Via the component interface <NUM>, the control circuit <NUM> can acquire readings from sensors. Accordingly, component interface <NUM> can include a plurality of electrical connections on a circuit board or internal bus of control circuit <NUM> that is further coupled to processor <NUM>, memory <NUM>, etc. Further, the component interface <NUM> can implement various wired or wireless interfaces such as, but not limited to, a USB interface, a serial interface, a WiFi interface, a short-range RF interface (Bluetooth), an infrared interface, a near-field communication (NFC) interface, etc..

As shown in <FIG>, the control circuit can include an integrated level sensor <NUM>. Accordingly, the level sensor configured to provide a fluid level reading of the tank system can be included in a common housing with the other components of the control circuit <NUM> (i.e. processor <NUM>, memory <NUM>, etc.). However, it is to be appreciated that the level sensor <NUM> may be a separate component coupled to control circuit <NUM> via the component interface <NUM>, as shown in <FIG>, for example.

Referring to <FIG>, an exemplary, non-limiting embodiment of a cloud-based system <NUM> is illustrated. As shown in <FIG>, cloud-based system <NUM> includes one or more processor(s) <NUM> configured to execute computer-executable instructions <NUM> such as instructions composing a server process to orchestrate tank monitoring and management. Such computer-executable instructions can be stored on one or more computer-readable media including non-transitory, computer-readable storage media such as memory <NUM> or storage <NUM>. For instance, storage <NUM> can include non-volatile storage to persistently store instructions <NUM> and/or tank information <NUM> (e.g., history data, fluid level data, filling history, fluid type, tank identifications, etc.) received from sensor assemblies <NUM> associated with various tanks <NUM>. Memory <NUM> can also include volatile storage that stores instructions <NUM>, other data (working data or variables), or portions thereof during execution by processor <NUM>. The tank information <NUM> can be stored in association with tank identifications (e.g. serial numbers or other identifiers) of tanks <NUM> having sensor assemblies <NUM> associated therewith.

Cloud-base system <NUM> further includes a communication interface <NUM> to couple cloud-based system <NUM>, via the Internet or other communications network, to sensor assemblies <NUM> and client devices <NUM>. Communication interface <NUM> can be a wired or wireless interface including, but not limited, a WiFi interface, an Ethernet interface, a Bluetooth interface, a fiber optic interface, a cellular radio interface, a satellite interface, etc. As shown in <FIG>, cloud-based system <NUM> can service a plurality of sensor assemblies <NUM>, which include sensor assembly <NUM><NUM>, sensor assembly <NUM><NUM>,. , sensor assembly <NUM>n, where n is an integer greater than or equal to one. The sensor assemblies <NUM> can be associated with different tanks <NUM>. Similarly, a plurality of client devices <NUM><NUM>, <NUM><NUM>,. , <NUM>m (where m is an integer greater than or equal to one) can communicate with cloud-based system <NUM>. Client devices <NUM> can be associated with various users such as tank owners, gas vendors, manufacturers, etc..

Turning now to <FIG>, a schematic block diagram of an exemplary, non-limiting embodiment of a client device is illustrated. Client device <NUM> includes one or more processor(s) <NUM> configured to execute computer-executable instructions such as instructions composing a management application <NUM>. Such computer-executable instructions can be stored on one or more computer-readable media including non-transitory, computer-readable storage media such as memory <NUM> or storage <NUM>. For instance, storage <NUM> can include non-volatile storage to persistently store management application <NUM> and/or data <NUM> (e.g., tank identification, level readings, etc.). Memory <NUM> can also include volatile storage that stores instructions, other data (working data or variables), or portions thereof during execution of management application <NUM> by processor <NUM>.

Client device <NUM> further includes a communication interface <NUM> to couple client device <NUM>, via the Internet or other communications network, to a tank <NUM> and/or cloud-based system <NUM>. Communication interface <NUM> can be a wired or wireless interface including, but not limited, a WiFi interface, an Ethernet interface, a Bluetooth interface, a fiber optic interface, a cellular radio interface, a satellite interface, etc. Client device <NUM> can further include a user interface <NUM> that comprises various elements to obtain user input and to convey user output. For instance, user interface <NUM> can comprise of a touch display, which operates as both an input device and an output device. In addition, user interface <NUM> can also include various buttons, switches, keys, etc. by which a user can input information to client device <NUM>; and other displays, LED indicators, etc. by which other information can be output to the user. Further still, user interface <NUM> can include input devices such as keyboards, pointing devices, and standalone displays.

In accordance with an embodiment, client device <NUM> is a computing device, which is readily carried by a user, such a smartphone or tablet device. However, it is to be appreciated that client device <NUM> can be other portable form-factors such as a laptop computer, a convertible laptop, a watch computing device, or the like. Moreover, client device <NUM> can be a desktop computer, or other larger, less portable computing device. That is, management application <NUM> can be installed and executed on substantially any computing device provided that such a computing device can communicate with cloud-based system <NUM> and/or sensor assemblies <NUM> (tanks <NUM>) as described herein.

Referring now to <FIG>, illustrated is a flow diagram of a method <NUM> for managing a tank. Method <NUM> can be implemented, for example, by sensor assembly <NUM> described above. At <NUM>, a sensor reading is received from an ultrasound sensor. The sensor may be mounted to a tank housing a pressurized fluid such as shown in <FIG>. At <NUM>, a fluid level within the tank is determined based on the sensor reading. At <NUM>, the fluid level and a tank identification is transmitted to a cloud-based system.

<FIG> indicates types of data communicated in the systems and methods described above. The data are coded to indicate a source and/or means via which the data are communicated. For example, information supporting manufacturing and/or filling lines from Operations may relate to data acquired from indicia <NUM>. Information supporting Logistics and/or the Consumer may relate to data provided via geolocation and/or communication interface <NUM>. Moreover, the level of the gas in a cylinder may be provided via both sources.

<FIG> further indicates an intended target or purpose of the data. For example, at a filling line, indicia <NUM> may be read and a corresponding ID is sent to a database. The database may return information such as cylinder information including data of manufacture, date for requalification, weight tare, etc. The cylinder bearing indicia <NUM> may be segregated if the date for requalification has passed. Further, a number of times the cylinder has been filled can be recorded by reading indicia <NUM> at the filling lines.

Logistics may also be supported with the systems and methods described herein. For instance, a distributor, through a platform, may be warned of a need of the consumer (e.g. low fluid level). In response, a delivery order may be automatically created. The distributor may expedite delivery of a new cylinder depending on consumer need. The new cylinder may also bear indicia <NUM> as described above. Thus, a cylinder ID may be registered in the consumer history. Analysis of orders and deliveries may indicate consumer patterns to enable the distributor to anticipate needs of the consumers.

A consumer, using management application <NUM> for instance, may notify a dealer or distributor of a need for a new cylinder. The new cylinder is registered in a consumer account. The management application <NUM> enables the consumer to benefit from short delivery times, consult sites selling a product close to a residence, to be rewarded with offers, promotions, or bonuses, and the consumer is also aware of a consumption pattern.

In another embodiment, via a mobile device having the management application <NUM>, a geolocation of a cylinder may be acquired. Thus, a distribution of assets may be identified, tracked, and managed. For instance, a number of times a particular indicia <NUM> is read by a mobile device, or other reader, is recorded.

One of ordinary skill in the art can appreciate that the various embodiments of the system described herein can be implemented in connection with any computing device, client device, or server device, which can be deployed as part of a computer network or in a distributed computing environment such as the cloud. The various embodiments described herein can be implemented in substantially any computer system or computing environment having any number of memory or storage units, any number of processing units, and any number of applications and processes occurring across any number of storage units and processing units. This includes, but is not limited to, cloud environments with physical computing devices (e.g., servers) aggregating computing resources (i.e., memory, persistent storage, processor cycles, network bandwidth, etc.) which are distributed among a plurality of computable objects. The physical computing devices can intercommunicate via a variety of physical communication links such as wired communication media (e.g., fiber optics, twisted pair wires, coaxial cables, etc.) and/or wireless communication media (e.g., microwave, satellite, cellular, radio or spread spectrum, free-space optical, etc.). The physical computing devices can be aggregated and exposed according to various levels of abstraction for use by application or service providers, to provide computing services or functionality to client computing devices. The client computing devices can access the computing services or functionality via application program interfaces (APIs), web browsers, or other standalone or networked applications. Accordingly, aspects of the system can be implemented based on such a cloud environment. For example, cloud-based system <NUM> can reside in the cloud environment such that the computer-executable instruction implementing the functionality thereof are executed with the aggregated computing resources provided by the plurality of physical computing devices. The cloud environment provides one or more methods of access to the cloud-based system <NUM>, which are utilized by management application <NUM> on client device <NUM> and sensor assembly <NUM>. These methods of access include IP addresses, domain names, URIs, etc. Since the aggregated computing resources can be provided by physical computing device remotely located from one another, the cloud environment can include additional devices such as a routers, load balancers, switches, etc., that appropriately coordinate network data.

<FIG> provides a schematic diagram of an exemplary networked or distributed computing environment, such as a cloud computing environment <NUM>. The cloud computing environment <NUM> represents a collection of computing resources available, typically via the Internet, to one or more client devices. The cloud computing environment <NUM> comprises various levels of abstraction: infrastructure <NUM>, a platform <NUM>, and applications <NUM>. Each level, from infrastructure <NUM> to applications <NUM> is generally implemented on top of lower levels, with infrastructure <NUM> representing the lowest level.

Infrastructure <NUM> generally encompasses the physical resources and components on which cloud services are deployed. For instance, infrastructure <NUM> can include virtual machines <NUM>, physical machines <NUM>, routers/switches <NUM>, and network interfaces <NUM>. The network interfaces <NUM> provide access to the cloud computing environment <NUM>, via the Internet or other network, from client devices such as computing devices <NUM>, <NUM>, <NUM>, etc. That is, network interfaces <NUM> provide an outermost boundary of cloud computing environment <NUM> and couple the cloud computing environment <NUM> to other networks, the Internet, and client computing devices. Routers/switches <NUM> couple the network interfaces <NUM> to physical machines <NUM>, which are computing devices comprising computer processors, memory, mass storage devices, etc. Hardware of physical machines <NUM> can be virtualized to provide virtual machines <NUM>. In an aspect, virtual machines <NUM> can be executed on one or more physical machines <NUM>. That is, one physical machine <NUM> can include a plurality of virtual machines <NUM>.

Implemented on infrastructure <NUM>, platform <NUM> includes software that forming a foundation for applications <NUM>. The software forming platform <NUM> includes operating systems <NUM>, programming or execution environments <NUM>, web servers <NUM>, and databases <NUM>. The software of platform <NUM> can be installed on virtual machines <NUM> and/or physical machines <NUM>.

Applications <NUM> include user-facing software applications, implemented on platform <NUM>, that provide services to various client devices. In this regard, the backend system <NUM> of the well management system <NUM> described herein is an example application <NUM>. As illustrated in <FIG>, client devices can include computing devices <NUM>, <NUM> and mobile device <NUM>. Computing devices <NUM>, <NUM> can be directly coupled to the Internet, and therefore the cloud computing environment <NUM>, or indirectly coupled to the Internet via a WAN/LAN <NUM>. The WAN/LAN <NUM> can include an access point <NUM> that enables wireless communications (e.g., WiFi) with mobile device <NUM>. In this regard, via access point <NUM> and WAN/LAN <NUM>, mobile device <NUM> can communicate wirelessly with the cloud computing environment <NUM>. Mobile device <NUM> can also wirelessly communicate according to cellular technology such as, but not limited to, GSM, LTE,WiMAX, HSPA, etc. Accordingly, mobile device <NUM> can wirelessly communicate with a base station <NUM>, which is coupled to a core network <NUM> of a wireless communication provider. The core network <NUM> includes a gateway to the Internet and, via the Internet, provides a communication path to the cloud computing environment <NUM>.

These features as well as other features are further described in Appendices A-C, which are attached hereto and form a part of this specification.

As mentioned above, while exemplary embodiments have been described in connection with various computing devices and network architectures, the underlying concepts may be applied to any network system and any computing device or system in which it is desirable to implement an image segmentation system.

Also, there are multiple ways to implement the same or similar functionality, e.g., an appropriate API, tool kit, driver code, operating system, control, standalone or downloadable software objects, etc. which enables applications and services to take advantage of the techniques provided herein. Thus, embodiments herein are contemplated from the standpoint of an API (or other software object), as well as from a software or hardware object that implements one or more embodiments as described herein. Thus, various embodiments described herein can have aspects that are wholly in hardware, partly in hardware and partly in software, as well as in software.

As utilized herein, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or.

Further, as used herein, the term "exemplary" is intended to mean "serving as an illustration or example of something.

Claim 1:
A level sensor system, comprising:
a tank (<NUM>) configured to store a liquified pressurized gas;
a supporting part (<NUM>, <NUM>) for supporting the tank (<NUM>) in a vertical orientation, said supporting part being a footring (<NUM>) or a base (<NUM>); and
a sensor assembly (<NUM>) associated with the tank (<NUM>), the sensor assembly (<NUM>) comprising:
an ultrasound sensor (<NUM>) configured to output a sensor reading indicative of a fluid level within the tank (<NUM>);
a control circuit (<NUM>) configured to interpret the sensor reading and determine the fluid level; and
a communications interface (<NUM>) for transmitting the fluid level to a remote system;
characterized in that the sensor assembly (<NUM>) is encapsulated in a shock absorbing material (<NUM>) and housed within the supporting part (<NUM>, <NUM>).