Patent Description:
This disclosure relates generally to healthcare environments, and, more particularly, to methods and apparatus to facilitate proximity detection and location tracking.

Real-time location systems (RTLS) monitor asset distribution and usage, providing actionable information to help control costs and improve the quality and efficiency of care. Systems that have been developed to track and analyze activities in clinical settings have included installing Radio Frequency Identification (RFID) or infrared (IR) reader infrastructures into buildings to capture position information. RFID sensors may be placed on the people and/or assets that need to be tracked.

However, this is an expensive and time-consuming solution because it requires pulling power and data cabling to all the required locations. Location accuracy can also vary depending on technology. Typical RFID systems have a tolerance of approximately plus-or-minus ten feet, further limiting their range. RFID and IR-based sensors, though, are highly susceptible to drift due to interference in the environment (e.g., a patient room) and cross talk between locations that are physically separated, but have a line of sight between them (e.g., two patient rooms across the hall from each other).

Therefore, it would be desirable to design a system and method for tracking locations and interactions between people and assets in an environment with minimal infrastructure requirements and standardized technologies. <CIT> discloses a system for determining real time location of leaf node device, the system including at least one battery-powered Bluetooth Low Energy (BLE) enabled leaf node device, wherein the at least one leaf node device is associated with a corresponding monitored asset; and at least one beam forming reader node in communication, via BLE, with the at least one leaf node, the reader node creating a plurality of sectorized beams in a plurality of sectors and collecting data related to the at least one leaf node device from at least one of the plurality of sectors, wherein a location processing facility determines the real-time location of the at least one leaf node device based on the data collected by the beam forming reader node.

Certain examples provide improved systems, apparatus, methods, and media for real time location system management.

Certain examples provide an apparatus including a real time location system (RTLS) health processor. The example RTLS health processor includes an event processor to process an event included in a message from an RTLS device to identify event information related to the RTLS device, the event relating to a health of the RTLS device and the event information including an event type and an event detail. The example RTLS health processor includes a health analyzer to compare the event detail to a prescribed bound for the event type, the event relating to a health of the device. The example RTLS health processor includes an output generator to, when the event information is outside the prescribed bound, trigger a response to address the event with respect to the RTLS device.

Certain examples provide a computer-readable storage medium including instructions that, when executed, cause a processor to be configured to implement a real time location system (RTLS) health processor. The example RTLS health processor is to include an event processor to process an event included in a message from an RTLS device to identify event information related to the RTLS device, the event relating to a health of the RTLS device and the event information including an event type and an event detail. The example RTLS health processor is to include a health analyzer to compare the event detail to a prescribed bound for the event type, the event relating to a health of the device. The example RTLS health processor is to include an output generator to, when the event information is outside the prescribed bound, trigger a response to address the event with respect to the RTLS device.

Certain examples provide a processor-implemented method for a real time location system (RTLS). The example method includes processing, using a processor, an event included in a message from an RTLS device to identify event information related to the RTLS device, the event relating to a health of the RTLS device and the event information including an event type and an event detail. The example method includes comparing, using the processor, the event detail to a prescribed bound for the event type, the event relating to a health of the device. The example method includes, when the event information is outside the prescribed bound, triggering, using the processor, a response to address the event with respect to the RTLS device.

The features and technical aspects of the system and method disclosed herein will become apparent in the following Detailed Description set forth below when taken in conjunction with the drawings in which like reference numerals indicate identical or functionally similar elements.

In the following detailed description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific examples that may be practiced. These examples are described in sufficient detail to enable one skilled in the art to practice the subject matter, and it is to be understood that other examples may be utilized and that logical, mechanical, electrical and other changes may be made without departing from the scope of the subject matter of this disclosure. The following detailed description is, therefore, provided to describe an exemplary implementation and not to be taken as limiting on the scope of the subject matter described in this disclosure. Certain features from different aspects of the following description may be combined to form yet new aspects of the subject matter discussed below.

The terms "first," "second," and the like, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. As the terms "connected to," "coupled to," etc. are used herein, one object (e.g., a material, element, structure, member, etc.) can be connected to or coupled to another object regardless of whether the one object is directly connected or coupled to the other object or whether there are one or more intervening objects between the one object and the other object.

As used herein, the terms "system," "unit," "module," "engine," etc., may include a hardware and/or software system that operates to perform one or more functions. For example, a module, unit, or system may include a computer processor, controller, and/or other logic-based device that performs operations based on instructions stored on a tangible and non-transitory computer readable storage medium, such as a computer memory. Alternatively, a module, unit, engine, or system may include a hard-wired device that performs operations based on hard-wired logic of the device. Various modules, units, engines, and/or systems shown in the attached figures may represent the hardware that operates based on software or hardwired instructions, the software that directs hardware to perform the operations, or a combination thereof.

In addition, it should be understood that references to "one embodiment" or "an embodiment" of the present disclosure are not intended to be interpreted as excluding the existence of additional embodiments that also incorporate the recited features.

Certain examples provide novel systems and associated methods that enable hospitals and/or other healthcare institutions to capture real time location data regarding their assets. Signals emitted by beacons, such as low-energy (e.g., Bluetooth Low Energy (BLE), etc.) beacons are captured by receivers. Software associated with the receivers captures, analyzes, and filters the collected location data, which can then be forwarded to a cloud-based server and associated software, which can facilitate crowd-sourcing to further analyze the data. Unlike other real-time location services, using low-energy and/or other wireless communication (e.g., Wi-Fi, etc.), beacons can be tracked and data can be exchanged without opening ceilings or drilling walls to run cables in a lengthy, invasive installation. Instead, a wireless beacon-receiver tracking network can be configured in days, rather than months. Certain examples enable location tracking of equipment for inspection and preventative maintenance, equipment location for patient care, and analysis and insight into collected data regarding how, when, and how often equipment is used.

In certain examples, beacon-based data can be made available to users via Web-based interface and associated application. The Web-based interface can be accessible via a desktop computer, laptop, tablet computer, smart phone, etc. Location asset data can be integrated with other management system(s), for example.

Certain examples of the presently disclosed technology improve proximity detection and location tracking of resources in an environment such as a hospital. An example system disclosed herein includes one or more beacon tags affixed to assets within the environment and that transmit (e.g., periodically, aperiodically and/or as a one-time event) beacon messages. The beacon messages are received by a mobile reader badge that listens for beacon messages transmitted in the environment. For example, disclosed example reader badges (sometimes referred to herein as "readers," "badges" or "mobile wireless bridges") may include a network interface to receive beacon messages transmitted via low power Bluetooth Low Energy (BLE). In some disclosed examples, the reader badges process the received beacon messages and communicate information obtained from the beacon messages to one or more real-time location services (RTLS) servers via a communication infrastructure. For example, disclosed example reader badges may aggregate and communicate a batch of beacon messages (e.g., a threshold number of beacon messages, a threshold interval of time (e.g., a window of interest), etc.) to an RTLS server via a Wi-Fi infrastructure (e.g., a wireless network). In some disclosed examples, the RTLS server processes the received batch of beacon messages to facilitate real-time location tracking of the resources in the environment. In some disclosed examples, the RTLS server may report the location of resources via charts, graphs, tables, etc..

Real-time location services enable improved patient workflow via proximity detection and location tracking in a healthcare environment, such as a hospital. Location tracking can be used to locate resources such as mobile assets (e.g., patients, intravenous (IV) pumps, telemetry units, wheelchairs, etc.) within the hospital. For example, location tracking can be used to locate a "lost" or "missing" IV pump within a patient's room. Proximity detection facilitates an improved understanding of how interactions occur during the patient workflow. For example, based on the proximity to a soap dispenser, a user (e.g., a system administrator) can determine whether a caretaker washed their hands prior to interacting with a patient.

Example systems and methods disclosed herein facilitate improved proximity detection and location tracking by creating a hospital tracking network within the hospital using the communication infrastructure already installed in the hospital. Beacon tags are installed throughout a location or building. For example, beacon tags can be affixed to stationary assets (e.g., patient room entry ways, sinks, water fountains, hallways, etc.) and mobile assets such as hospital beds, IV pumps, soap dispensers, etc. In some disclosed examples, the beacon tags are also included in disposable patient tags provided to the patient upon admission of a hospital stay. Beacon tags are low-cost, low-power transmitters of beacon messages. A beacon message (sometimes referred to herein as a "beacon") includes information about the beacon tag such as a unique identifier (e.g., a tag identifier such as a media access control (MAC) address) and a tag type identifier (e.g., whether the beacon tag is affixed to a fixed-location asset or to a mobile asset). In some disclosed examples, the beacon tags broadcast (e.g., advertise, communicate, transmit, etc.) beacon messages at preset frequencies (e.g., ten times a second, once a second, once a minute, etc.). For example, a beacon tag affixed to a fixed-location asset (e.g., a sink) may broadcast beacon messages ten times a second, while a beacon tag affixed to a mobile asset (e.g., a wheelchair) may broadcast beacon messages at relatively shorter intervals (e.g., once a second).

A reader badge is a mobile wireless bridge that facilitates mobile tracking by "listening" and receiving beacon messages broadcast by beacon tags. The reader badge includes a BLE controller to receive connection-less beacon messages broadcast by beacon tags. The reader badge also includes a Wi-Fi controller to establish a connection with an RTLS server. The reader badge may be worn or transported by hospital caregivers. For example, a reader badge may be worn as a lanyard or clipped to the caregiver's clothing. As the caregiver moves about the hospital, the reader badge passively collects beacon messages and communicates reader messages to an RTLS server at the backend of the system. In some examples, the reader badge collects a number (e.g., a predetermined number) of beacon messages or waits a period (e.g., a predetermined period of time) prior to communicating the reader messages. In some examples, the reader badge generates and communicates a reader message as a beacon message from a beacon tag is received. A reader message includes information received from the beacon message such as a unique identifier of the source beacon tag and a spatial location of the source beacon tag. In some examples, the reader badge includes a timestamp identifying when the beacon message was received by the reader badge in the reader message. In some examples, the reader badge includes a received signal strength indication (RSSI) value (e.g., a power ratio in decibels of the measured power to one milli-watt (dBm)).

Example reader badges disclosed herein include a proximity engine to process the beacon messages and determine distance from the source (e.g., the beacon tag that broadcast the corresponding beacon message). For example, a hospital room may include a first beacon tag affixed to a door, a second beacon tag affixed to an infusion pump, a third beacon tag affixed to a bed, and a fourth beacon tag included in a patient tag (e.g., a disposable bracelet including patient identification information such as name, sex, date of birth information). As the caregiver moves about the hospital room, the reader badge may receive beacon messages from each of the beacon tags. The proximity engine can determine the RSSI strength for each of the beacon messages and associate RSSI strength with a respective beacon tag.

In some examples, the proximity engine determines which beacon tags are proximate (e.g., near or closely located) to the reader badge. For example, the proximity engine can compare the RSSI strength of a beacon message to a threshold and if the RSSI strength satisfies the threshold (e.g., the RSSI strength is greater than a threshold), the proximity engine identifies the source beacon tag as proximate to the reader badge. In some examples, the proximity engine discards beacon messages that are not proximate to the reader badge.

For example, fixed beacon receivers can be plugged into alternating current power outlets throughout a hospital. The beacon receivers capture transmissions from beacon tags moving around them and then forward the unique identifiers of those tags via the hospital's Wi-Fi network to a cloud-based server. Hospitals can view location information based on that data. The beacon tags can be attached to an asset and/or be worn by staff members or patients, for example.

In the example, mobile BLE receivers in the form of a badge device, similar to a pager, can be worn by clinical personnel. As with the fixed receivers, these badge devices also capture beacon transmissions and forward the data via the Wi-Fi network. The system can use big-data analytics and crowd-sourcing to expand the solutions range and real-time accuracy. Users can then use a Web-based application to easily find assets (e.g., the closest assets, all assets of one type, a specific device, etc.). For example, if a staff member were looking for a clean infusion pump, he or she could make a request via an application on his or her tablet and then access location data related only to items within the same zone in which they are located, for example.

Example systems and methods disclosed herein include an RTLS server that monitors and/or reports tracking location and interactions between people and assets in an environment. For example, the RTLS server can aggregate reader messages from the one or more reader badges included in an environment (e.g., the hospital). The RTLS server may be in connection with the reader badges via a wireless Intranet network (e.g., a wireless local area network, etc.) and/or a wireless Internet connection.

As healthcare assets continue to become smaller and more ergonomic, RTLS tracking with a small footprint becomes increasingly important. Additionally, as a hospital's inventory of healthcare equipment gets leaner, the equipment is likely to be cleaned more often. Therefore, an asset tracking beacon should withstand frequent, repeated cleaning with harsh disinfecting chemicals.

Certain examples provide an improved housing that can be applied with BLE and/or other location tracking technology to healthcare assets (e.g., scanner, IV pumps, monitors, etc.). In certain examples, a computerized maintenance management system (CMMS) and/or source system can organize and monitor assets and can remove and reassociate beacons from one asset to another asset on demand. Beacons can be installed on ergonomic items that do not have flat surfaces. Beacons can be developed with housings to withstand rigorous healthcare cleaning protocols while maintaining a small footprint to not disturb normal usage of equipment to which the beacon is applied.

A quality of location data provided by a real time location platform can depend on health of devices deployed to receive sensory and/or location events. If deployed devices are not functioning as intended, the location data produced by the system may be inaccurate/unreliable. To help ensure accurate location data, support teams can monitor system health, isolate problematic devices and correct the problems through reconfiguration/replacement/upgrades/etc..

Certain examples provide receiver health methods and systems for real time location platforms. Certain examples define a mechanism and associated application programming interface (API) specification by which location receivers deployed as part of a real time location platform can transmit system health information using an event-based messaging framework. The data/events provided can be captured and utilized to maintain the system and help ensure improved or optimal performance.

Devices used to implement a real time location platform may have numerous dependencies, including a reliable power supply (e.g., battery, outlet, etc.), network connectivity and acceptable environmental conditions (e.g. min/max operating temperature, etc.). With a large number of devices deployed, it is not feasible or cost effective to manually inspect each device in the field on a regular basis. Certain examples facilitate device self-reporting of health status and associated system events to help maintain a functioning system.

In certain examples, location devices are designed to submit event data (e.g., as JavaScript Object Notation (JSON) documents, etc.) to a service interface (e.g., a representational state transfer (REST) or RESTful service interface, etc.). There are numerous events defined, and these events can be sent in response to a condition (e.g., device regaining network connectivity, device placed on charger, device removed from charger, etc.) or on a time schedule that is configurable as part of the device profile. Events include a set of base (e.g., header, etc.) attributes that are used for ongoing system health management. In addition, each event includes a details section where attributes/data specific to an event type can be included.

In certain examples, receiver health includes a set of events defined for receiver devices (e.g., Bluetooth receiver devices, BLE receiver devices, etc.). The set of events can be defined according to an API, for example. In certain examples, a gateway client API includes a service interface specification or API for the RESTful service used by the device to post receiver health events, etc..

Certain examples provide a centralized health and monitoring capability for large scale systems that include a plurality of devices deployed in a wide range of environments. Without such monitoring, deployed systems may fall into disrepair over time and/or the costs of monitoring/maintaining such systems may threaten the commercial viability of the dependent products, for example.

Certain examples, when utilized, result in improved system performance, higher customer satisfaction, higher return on investment for the customer, lower cost of ownership for the customer, lower support costs for the supplier and increased profit margin for the supplier, etc..

Types and details of health events reported by devices can be extended/modified in a variety of ways to propose a "unique" set of health events. The mechanisms/protocols by which the events are delivered (e.g. JSON/XML/CSV or HTTP/JMS/SMTP, etc.) and/or captured can also be varied to propose a "unique" solution, for example.

The foregoing systems and methods can be deployed to provide real-time location services. Real-time location services (RTLS) facilitate tracking people and assets in an industrial setting, such as a hospital. The example RTLS system described herein is designed to create location awareness of assets by capturing location and proximity information from beacon tags installed throughout the hospital. Examples disclosed herein utilize reader badges worn by healthcare workers (e.g., doctors, nurses, administrators, janitors, etc.) that receive beacon messages from beacon tags that are installed in and/or affixed to assets such as hallways, rooms, equipment, patients, etc. for which location and/or proximity information is to be collected between the beacon tags and the tagged asset. For example, the beacon tags may broadcast beacon messages including a unique identifier (e.g., a signature, a MAC address, a serial number, etc.) associated with the corresponding beacon tags. As the healthcare workers walk around the hospital, their reader badges collect beacon messages transmitted from beacon tags throughout the hospital. In some disclosed examples, the reader badges aggregate the beacon messages and transmit a batch of beacon messages to an RTLS server for processing. The example RTLS server disclosed herein processes the beacon messages to create location awareness through proximity and probability.

In some disclosed examples, beacon tags are installed in and/or attached to fixed-location (e.g., placed on stationary (or near stationary)) assets. For example, some "known location" beacon tags may be affixed to hallways, doors, windows, sinks, etc. As disclosed below, in some examples, the RTLS server utilizes the beacon messages received from "known location" beacon tags to determine a location for the reader badge.

In some disclosed examples, beacon tags are affixed to mobile assets such as equipment. For example, some "mobile location" beacon tags may be affixed to beds, wheelchairs, patients, etc. As disclosed below, in some examples, the RTLS server utilizes the beacon messages received from the "mobile location" beacon tags to determine what assets are near the corresponding reader badges (e.g., the reader badge that aggregated and transmitted a batch of beacon messages).

In addition, comparing the asset locations during different timestamp intervals may be useful in determining how the assets were moved and/or when caregivers interacted with the assets. For example, consider an example in which a wheelchair (e.g., a mobile-location asset) is located in a first patient room. In the illustrated example, assume that the wheelchair is affixed with a mobile-location asset beacon tag and that the first patient room is affixed with a fixed-location asset beacon tag. In the illustrated example, when a caregiver wearing a reader badge walks into the first patient room, their reader badge collects beacon messages broadcast by the wheelchair beacon tag and the first patient room beacon tag. In the illustrated example, the caregiver location is assigned to the first patient room based on the beacon messages broadcast by the first patient room beacon tag. In addition, since the wheelchair is "seen" in the same location, the wheelchair location may also be updated to the first patient room.

In the illustrated example, while the caregiver is in the first patient room, their reader badge collects beacon messages broadcast by the wheelchair beacon tag and the first patient room beacon tag. If the caregiver begins moving the wheelchair (e.g., from the first patient room to a second patient room), their reader badge will continue to collect beacon tags broadcast by the first patient room badge tag, but will also begin collecting beacon messages broadcast by a second patient room beacon tag. In the illustrated example, once the caregiver enters the second patient room, the caregiver location is updated to the second patient room. Additionally, in the illustrated example, since the wheelchair is still "seen" by the caregiver (e.g., the wheelchair location is determined to be proximate to the caregiver), the location of the wheelchair is also updated to the second patient room.

In the illustrated example, after the wheelchair is moved from the first patient room to the second patient room, confidence that the wheelchair is located in the second patient room rather than the first patient room may be low. However, in the illustrated example, each time a caregiver walks into the first patient room and does not "see" the wheelchair, confidence that the wheelchair is located in the first patient room decreases. Additionally, in the illustrated example, each time a caregiver walks into the second patient room and does "see" the wheelchair, confidence that the wheelchair is located in the second patient room increases. In the illustrated example, the "crowd" (e.g., the caregivers) provides different snapshots of what is "seen" at different locations and at different times. As disclosed herein, an RTLS server may analyze the different snapshots to facilitate proximity detection and location tracking of assets in an environment.

Referring to <FIG>, an example environment <NUM> in which examples disclosed herein may be implemented to facilitate proximity detection and location tracking using a mobile wireless bridge is illustrated. The example environment <NUM> of <FIG> includes example beacon tags <NUM>, an example reader badge <NUM> and an example real-time location services (RTLS) server <NUM>.

In the illustrated example of <FIG>, the beacon tags <NUM> are implemented using low-power BLE transmitters and include a single coin-cell battery. In some examples, the single coin-cell battery provides power to the corresponding beacon tag <NUM> for two or more years. In the illustrated example, beacon tags <NUM> are installed throughout the environment <NUM> on two types of assets. For example, one or more beacon tag(s) <NUM> may be located on (e.g., affixed to) fixed-location assets such as doors, rooms, hallways, water fountains, etc. In addition, one or more beacon tag(s) <NUM> may be located on (e.g., affixed to) mobile-location assets such as patients (e.g., inserted within a patient tag), beds, IV pumps, wheelchairs, etc. Although the illustrated example of <FIG> includes only two beacon tags <NUM>, other environments are likely to include additional beacon tags. For example, different environments may include tens, hundreds and/or thousands of beacon tags affixed to assets. In general, accuracy of the proximity detection and location tracking of assets in an environment is increased and/or decreased based on adding or reducing the number of beacon tags placed in the environment.

In the illustrated example of <FIG>, the example beacon tags <NUM> periodically advertise their presence in the environment <NUM>. For example, the beacon tags <NUM> may broadcast example beacon messages <NUM> every one second. In other examples, the beacon tags <NUM> may broadcast beacon messages <NUM> aperiodically and/or as a one-time event. In some examples, the beacon tags <NUM> may broadcast beacon messages <NUM> at different time intervals. For example, beacon tags <NUM> located on fixed-location assets may broadcast beacon messages <NUM> every two seconds, while beacon tags <NUM> located on mobile-location assets may broadcast beacon messages <NUM> every second. In some examples, beacon tags located on mobile-locations assets may broadcast beacon messages <NUM> at a first frequency (e.g., once every second) while the mobile-location asset is stationary and may broadcast beacon messages <NUM> at a second frequency (e.g., once every half-second) while the mobile-location asset is moving. However, other time intervals may additionally or alternatively be used.

In the illustrated example, the beacon messages <NUM> include tag identifying information <NUM> and tag-type identifying information <NUM>. For example, tag identifying information <NUM> may be a unique identifier of the beacon tag <NUM> such as a MAC address, a serial number, an alphanumeric signature, etc. The example tag-type identifying information <NUM> identifies whether the beacon tag <NUM> broadcasting the beacon message <NUM> is affixed to a fixed-location asset or affixed to a mobile-location asset. However, the beacon messages <NUM> may include additional or alternative information. For example, the beacon messages <NUM> may include information identifying the software version being executed by the beacon tags <NUM>, may include information identifying a power level of the beacon tag <NUM>, etc..

In the illustrated example of <FIG>, the beacon messages <NUM> are received by the reader badge <NUM>. In the illustrated example, the reader badge <NUM> is worn by a hospital caregiver <NUM> such as a doctor, a nurse, etc. As the hospital caregiver moves through the hospital, the reader badge <NUM> collects beacon messages <NUM> broadcast by the beacon tags <NUM>. For example, while the hospital worker <NUM> is visiting a patient in an example patient room #<NUM>, the example reader badge <NUM> may collect one or more beacon message(s) from a fixed-location asset beacon tag located on a door of the patient room #<NUM>, one or more beacon message(s) from a fixed-location asset beacon tag located on a sink in the patient room #<NUM>, one or more beacon message(s) from a mobile-location asset beacon tag located on the patient's identification tag, one or more beacon message(s) from a mobile-location asset beacon tag located on a bed in the patient room #<NUM>, etc..

In the illustrated example of <FIG>, the reader badge <NUM> generates example reader messages <NUM> in response to receiving the beacon messages <NUM>. For example, the reader badge <NUM> may create a reader message <NUM> including the tag identifying information <NUM> and the tag-type identifying information <NUM> included in the beacon message <NUM> and append example badge identifying information <NUM>, an example timestamp <NUM>, example signal strength information <NUM>, and example channel identifying information <NUM>. In the illustrated example, the badge identifying information <NUM> is a string of alphanumeric characters that uniquely identifies the reader badge <NUM> (e.g., a MAC address, a serial number, an alphanumeric signature, etc.). The example timestamp <NUM> identifies a date and/or time (e.g., January <NUM>, <NUM>, <NUM>:<NUM>:<NUM> pm) when the beacon message <NUM> was received by the reader badge <NUM>. The example signal strength information <NUM> identifies signal strength of the beacon message <NUM> when it was received by the reader badge <NUM> (e.g., a received signal strength indication (RSSI) value). The example channel identifying information <NUM> identifies a channel on which the beacon message <NUM> was received (e.g., a Bluetooth frequency channel such as channel <NUM>, channel <NUM> or channel <NUM>).

In the illustrated example of <FIG>, the reader badge <NUM> periodically communicates a group (e.g., a batch) of reader messages <NUM> to the RTLS server <NUM>. For example, the reader badge <NUM> may transmit one or more reader messages <NUM> that were collected over a period of time (e.g., thirty seconds). Additionally or alternatively, the reader badge <NUM> may communicate one or more reader message(s) <NUM> aperiodically and/or as a one-time event. For example, the reader badge <NUM> may collect a threshold number of reader messages <NUM> prior to transmitting the collected reader messages <NUM> to the RTLS server <NUM>. In some examples, the reader badge <NUM> transmits the reader messages <NUM> as they are created by the reader badge <NUM>.

In the illustrated example of <FIG>, the RTLS server <NUM> is a server and/or database that facilitates proximity detection and location tracking. In some examples, the RTLS server <NUM> is implemented using multiple devices. For example, the RTLS server <NUM> may include disk arrays or multiple workstations (e.g., desktop computers, workstation servers, laptops, etc.) in communication with one another.

In the illustrated example, the RTLS server <NUM> is in communication with the reader badge <NUM> via one or more wireless networks represented by example network <NUM>. Example network <NUM> may be implemented using any suitable wireless network(s) including, for example, one or more data busses, one or more wireless Local Area Networks (LANs), one or more cellular networks, the Internet, etc. As used herein, the phrase "in communication," including variances thereof (e.g., communicates, in communication with, etc.), encompasses direct communication and/or indirect communication through one or more intermediary components and does not require direct physical (e.g., wired) communication and/or constant communication, but rather additionally includes communication at periodic or aperiodic intervals, as well as one-time events.

In the illustrated example of <FIG>, the RTLS server <NUM> utilizes the reader messages <NUM> to facilitate proximity detection and location tracking of assets in the environment <NUM>. In the illustrated example, the RTLS server <NUM> selects a portion of reader messages <NUM> received from the reader badge <NUM> to determine a location of the reader badge <NUM>. For example, the RTLS server <NUM> may process the reader messages <NUM> to identify a first subset of reader messages <NUM> (e.g., one or more reader messages) that were received by the reader badge <NUM> during a first window of interest (e.g., a five second window) and that were fixed-location asset tag type (e.g., based on the tag-type information <NUM> included in the first subset of reader messages). In the illustrated example of <FIG>, the RTLS server <NUM> utilizes the signal strength information <NUM> included in the first subset of reader messages <NUM> to determine a nearest fixed-location asset. For example, a relatively stronger RSSI value may indicate that the broadcasting beacon tag <NUM> is closer in proximity to the reader badge <NUM> than a beacon tag <NUM> associated with a relatively weaker RSSI value. In the illustrated example of <FIG>, the RTLS server <NUM> updates the location of the reader badge <NUM> based on the nearest fixed-location asset.

In the illustrated example of <FIG>, once the RTLS server <NUM> associates the reader badge <NUM> with a location (e.g., the location of the nearest fixed-location asset), the RTLS server <NUM> identifies a second subset of reader messages <NUM> (e.g., one or more reader messages) that were received by the reader badge <NUM> during the first window of interest (e.g., a five second window, etc.) and that were mobile-location asset tag type (e.g., based on the tag-type information <NUM> included in the second subset of reader messages <NUM>). For example, the RTLS server <NUM> may update the location of a mobile-location asset based on its proximity to the reader badge <NUM>.

In the illustrated example of <FIG>, the RTLS server <NUM> selects a reader message of the second subset of reader messages <NUM> and classifies the corresponding mobile-location assets relative location to the reader badge <NUM> based on the RSSI value <NUM> included in the selected reader badge <NUM>. For example, the RTLS server <NUM> classifies mobile-location asset as relatively-far assets when the signal strength information <NUM> satisfies a first threshold (e.g., the RSSI value is less than (-<NUM>) decibels, etc.). The example RTLS server <NUM> of <FIG> classifies mobile-location assets as relatively-immediate assets when the signal strength information <NUM> satisfies a second threshold (e.g., the RSSI value is greater than (-<NUM>) decibels, etc.). In the illustrated example of <FIG>, the RTLS server <NUM> classifies mobile-location assets as relatively-near assets when the signal strength information <NUM> does not satisfy the first threshold and the second threshold. For example, the RTLS server <NUM> may classify mobile-location assets as relatively-near assets when the RSSI value is less than (-<NUM>) decibels and greater than (-<NUM>) decibels.

In the illustrated of <FIG>, depending on the relative location classifications, the RTLS server <NUM> updates the location of the mobile-location asset and/or updates an asset-location confidence score associated with the mobile-location asset. In the illustrated example, the asset-location confidence score represents a probability (or likelihood) that a mobile-location asset may be found at the currently assigned asset-location. For example, when a mobile-location asset is "seen" in the same location, the RTLS server <NUM> increases the asset-location confidence score of the mobile-location asset. When the mobile-location asset is "seen" in a different location, the RTLS server <NUM> decreases the asset-location confidence score of the mobile-location asset. Additionally, when the asset-location confidence score fails to satisfy a location threshold (e.g., is less than a location threshold), the asset-location of the mobile-location asset may be updated based on, for example, the location of the reader badge <NUM> that collected the beacon message <NUM> emitted from the mobile-location asset (e.g., by the beacon tag <NUM> affixed to the mobile-location asset).

In the illustrated example, when a mobile-location asset is classified as relatively-far, the example RTLS server <NUM> of <FIG> discards the reader message <NUM> and the RTLS server <NUM> makes not change to the location of the mobile-location asset and/or the asset-location confidence score associated with the mobile-location asset. For example, the reader badge <NUM> may have collected a relatively weak beacon message emitted from a mobile-location asset passing through the hallway outside of the patient room #<NUM>. In some examples, the reader badge <NUM> may filter such beacon messages (e.g., beacon messages <NUM> that are associated with weak (e.g., low) RSSI values) rather than communicate the weak beacon messages to the RTLS server <NUM>.

When a mobile-location asset is classified as a relatively-immediate asset, high signal strength (e.g., an RSSI value greater than (-<NUM>) decibels, etc.) may be indicative of a mobile-location asset that is in-front of the hospital worker <NUM>, is being used by the hospital worker <NUM> and/or is being moved by the hospital worker <NUM>. In some such instances, the location of the mobile-location asset may be assumed to be the same as the location of the reader badge <NUM>. In the illustrated example, the example RTLS server <NUM> of <FIG> updates the location of the mobile-location asset to the location of the reader badge <NUM>. In addition, the example RTLS server <NUM> increments the asset-location confidence score of the mobile-location asset (e.g., the probability of the mobile-location asset being located at the updated asset-location is increased). In some examples, if the beacon tag <NUM> is relatively-immediate to the reader badge <NUM>, an assumption may be made that the caregiver is interacting with the corresponding assets. For example, the caregiver may be pushing a patient in a wheelchair.

In the illustrated example of <FIG>, when a mobile-location asset is classified as a relatively-near asset (e.g., is associated with a medium signal strength), the example RTLS server <NUM> of <FIG> compares the current location associated with the mobile-location asset to the location of the reader badge <NUM>. In the illustrated example, the RTLS server <NUM> increases the asset-location confidence score of the mobile-location asset when the current asset-location is the same as the location of the reader badge <NUM>. For example, the mobile-location asset is "seen" in the same location as it is currently assigned. In some examples when the current asset-location is not the same as the location of the reader badge <NUM>, the example RTLS server <NUM> decreases the asset-location confidence score of the mobile-location asset. In addition, the example RTLS server <NUM> compares the asset-location confidence score of the mobile-location asset to a location threshold and, when the asset-location confidence score fails to satisfy the location threshold (e.g., is less than the location threshold), the RTLS server <NUM> updates the asset-location of the mobile-location asset to the location of the reader badge <NUM> that received the corresponding beacon message <NUM>.

In the illustrated example of <FIG>, the example environment <NUM> includes an example dock module <NUM>. The example dock module <NUM> may be used to charge one or more reader badges <NUM>. In some examples, the dock module <NUM> receives beacon messages <NUM> from beacon tags <NUM> and/or transmits reader messages <NUM> to the RTLS server <NUM>.

<FIG> illustrates various components included in an example beacon tag <NUM>, an example beacon badge <NUM>, an example hub module <NUM> and example dock module <NUM>. For example, the beacon tag <NUM> includes one or more BLE chips (labeled "Beacon") <NUM> to transmit beacon messages <NUM>, one or more power sources <NUM> (e.g., one or more coin-cell batteries) and a system-on-a-chip (SOC) <NUM> to manage the one or more BLE chips <NUM> and the one or more power sources <NUM>. The example beacon badge <NUM> includes one or more BLE chips <NUM> (labeled "transceiver") to receive beacon messages 106a -109a, one or more Wi-Fi chips <NUM> to communicate with a wireless network (e.g., the example network <NUM>), one or more power sources (e.g., one or more batteries) <NUM>, one or more sensors <NUM> (e.g., a motion sensor, an accelerometer, a gyroscope, etc.) and a system-on-a-chip (SOC) <NUM> to manage the one or more BLE chips <NUM>, the one or more Wi-Fi chips <NUM>, the one or more power sources <NUM> and the one or more sensors <NUM>. The example beacon badge <NUM> also includes an example module connector <NUM> to connect the beacon badge <NUM> to the example hub module <NUM> and/or the dock module <NUM>.

In the illustrated example of <FIG>, the beacon badge <NUM> is connectable to the example hub module <NUM>. The connection between the beacon badge <NUM> and the hub module <NUM> may include a mechanical connection, an electrical connection, or combinations thereof. In the illustrated example, the hub module <NUM> may be used to track asset interactions with fixed locations. In a healthcare environment, examples of fixed locations include soap dispensers, beds, walls, equipment, etc. In other environments, such as a retail environment, fixed locations may include wall sconces, light fixtures, mirrors, shelving, and other such fixed locations.

The hub module <NUM> may be leveraged to identify particular locations. As an example, the beacon badge <NUM> may be coupled, via a badge connection <NUM>, to a hub module <NUM> placed on an entrance to a restricted area to identify when a person wearing a beacon tag <NUM> enters (or approaches) the restricted area. In one embodiment, the hub module <NUM> includes a system-on-a-chip (SOC) <NUM> to manage components of the hub module <NUM>, one or more power sources <NUM> (e.g., one or more batteries and an external power source (e.g., an AC/DC connection)) to extend the battery life and capabilities of the beacon badge <NUM>, one or more sensors <NUM> communicatively coupled to the SOC <NUM>, and a badge connection <NUM> for connecting the beacon badge <NUM> to the hub module <NUM>.

In the illustrated example, the beacon badge <NUM> may be connectable (e.g., mechanically coupled, electronically coupled, etc.) to the example dock module <NUM>. In the illustrated example, the dock module <NUM> may be used to charge one or more beacon badges <NUM>. Accordingly, and in one embodiment, the dock module <NUM> includes an external power connector <NUM> (e.g., an AC connector), a charging indicator <NUM> to indicate whether the beacon badge <NUM> is charged or charging, and a badge connection <NUM> for connecting the beacon badge <NUM> to the dock module <NUM>. In one embodiment, the dock module <NUM> is portable. For example, the dock module <NUM> may be placed throughout one or more environments, such as at cash registers, podiums, counters, nursing stations, break rooms, hallways, etc., and a caregiver may couple their beacon badge <NUM> to the dock module <NUM>, via a badge connection <NUM>, when they are off-duty.

<FIG> illustrates an example environment <NUM> illustrating interaction between premises <NUM>, <NUM> via a cloud <NUM>. In the example of <FIG>, one or more fixed beacons <NUM> and one or more mobile beacons <NUM> are positioned in a facility <NUM> (e.g., a hospital, clinic, etc.). The beacons <NUM>, <NUM> are affixed (e.g., permanently affixed, removably affixed, etc.) to locations, assets, etc. For example, the fixed beacon <NUM> can be mounted on a wall at a location in the facility <NUM> at which asset(s) may be located to provide a location to a receiver. The mobile beacon <NUM> can be affixed (e.g., permanently, removably, etc.) to an item to be located and tracked (e.g., an intravenous (IV) pump, imaging scanner (e.g., x-ray, CT, ultrasound, etc.), crash cart, lab cart, etc.), for example.

The beacons <NUM>, <NUM> are detected and read (e.g., via Bluetooth™, Bluetooth Low Energy (BLE), near field communication (NFC), etc.) by one or more mobile receivers <NUM> and/or fixed receivers <NUM>, for example. For example, the mobile receiver <NUM> includes logic to process its location (e.g., with respect to the fixed beacon <NUM>, etc.). The mobile receiver <NUM> can be worn by a person and/or mobile asset to create a crowdsourced environment in which the mobile receiver <NUM> interacts with beacons <NUM>, <NUM> and informs the system <NUM> of the receiver <NUM> location and presence of beacon(s) <NUM>, <NUM> within range of the location, for example. The fixed receiver <NUM> is configured with its location in the facility <NUM>. The fixed receiver <NUM> can be mounted on a wall in a location where crowdsourcing is reduced (e.g., storage locations, enclosed locations, etc.) to interact with beacons <NUM>, <NUM> and inform the system <NUM> of the receiver <NUM> location and presence of beacon(s) <NUM>, <NUM> within range of the location, for example. The mobile receiver(s) <NUM> and fixed receiver(s) <NUM> process which asset(s) are located within range (e.g., as indicated mobile beacon(s) <NUM> and/or fixed beacon(s) <NUM>, etc.) and notify other component(s) of the system <NUM>.

The receiver(s) <NUM>, <NUM> communicate over a channel <NUM>, such as Wi-Fi, etc., with a middleware gateway <NUM> to transmit information regarding beacon <NUM>, <NUM> location to a middleware engine <NUM>. The middleware gateway <NUM> can be an edge device, gateway device, hub, and/or other electronic device to interface between the premises <NUM> and the cloud <NUM>, for example. The middleware engine <NUM> can reside on the cloud <NUM> to process received beacon <NUM>, <NUM> and receiver <NUM>, <NUM> data and calculate location information. The middleware engine <NUM> can also publish location events to one or more receiving/subscribing recipients, for example.

For example, one or more consuming applications <NUM> access location data from the middleware engine <NUM> via the cloud <NUM> to leverage the location data for scheduling, tracking, (re)ordering, maintenance, billing, protocol compliance, treatment evaluation, employee evaluation, resource evaluation, and/or other resource management application(s), etc. Alternatively or in addition, an application programming interface (API) <NUM> provides location awareness data for consumption by one or more hospital applications <NUM>-<NUM> at a second facility (e.g., hospital, clinic, etc.) <NUM>. For example, a hospital computerized maintenance management system (CMMS) <NUM>, a hospital bed management system <NUM>, and/or other hospital system <NUM>, hospital application <NUM>, etc., can receive and process asset location information via the API <NUM>.

<FIG> illustrates an example architecture <NUM> of the hospital network <NUM> and the cloud <NUM> of <FIG>. As shown in the example of <FIG>, the hospital network <NUM> communicates with the cloud <NUM> via the middleware or location gateway <NUM>, which can be divided (as shown in the example of <FIG>) into a client location gateway 318a and a server location gateway 318b. The example hospital network <NUM> includes a badge configuration tool <NUM> used to configure a badge <NUM> (e.g., a hospital staff badge, smart phone, etc.) for one or more parameters such as Wi-Fi network, gateway connectivity, gateway security credential/certificate, etc. The tool <NUM> can communicate with the badge <NUM> via Wi-Fi, Bluetooth, NFC, etc. Further, the badge <NUM> communicates with the client location gateway 318a to provide location information to the cloud <NUM>.

Additionally, firmware <NUM> can communicate with the badge <NUM> to update firmware, settings, etc., on the badge <NUM>. The example firmware <NUM> can provide and/or be associated with a software development kit (SDK) to enable integration of application(s) into the badge <NUM>, for example. Using the SDK, the firmware <NUM> can provide notifications, offers, and/or other customizations to the badge <NUM> and/or a user/wearer of the badge <NUM>, for example.

The example hospital network <NUM> of <FIG> also includes a location toolbox application <NUM>, which communicates with a beacon <NUM> (e.g., a Bluetooth beacon, BLE beacon, etc.) and/or a hub <NUM> (e.g., via Bluetooth, BLE, etc.). The beacon <NUM> and/or hub <NUM> can also communicate with the badge <NUM> and/or the client location gateway 318a, for example. The toolbox <NUM> provides configuration and/or authorization application(s), setting(s), configuration(s), etc., for the hub <NUM>, badge <NUM>, and/or beacon <NUM>, etc. For example, the toolbox <NUM> can be used to set beaconing frequency, beacon range, beacon transmission mode, etc. The toolbox <NUM>, beacon <NUM>, and/or badge <NUM> can communicate via the hub <NUM> with the client location gateway 318a, etc..

The example hospital network <NUM> of <FIG> can also include a passive reader <NUM>, access point <NUM>, and passive tag <NUM>. The Wi-Fi access point <NUM> helps relay locating information by presence (e.g., in the facility <NUM>), zone (e.g., in a particular area of the facility <NUM>), location (e.g., actual location), etc. The passive tag <NUM> and passive reader <NUM> can interact to provide location information in the hospital network <NUM> to the client location gateway 318a, for example.

The client location gateway 318a communicates with the server location gateway 318b at the cloud <NUM>. The client location gateway 318a also communicates with a middleware engine <NUM> such as a locationing server <NUM>. The example server <NUM> provides a plurality of features including a management user interface (UI), a system health monitor, configuration information, insights/analytics, etc. The example server <NUM> communicates with beacon/site management services <NUM> and a site builder <NUM>, which helps to map out a location (e.g., the hospital network <NUM>, etc.) and beacons found at the location.

Using a service bus <NUM>, the server location gateway 318b, beacon/site management services <NUM>, and/or the site builder <NUM> can communicate with a geographic information system (GIS) <NUM> to create map(s) of the facility <NUM> to be stored using georeferenced location coordinates, for example. Fixed receivers placed in the facility <NUM> can be identified and added to the map using the site builder <NUM> and GIS <NUM>. A location engine <NUM> can be used to leverage the map(s) and geographic information to associate location(s) with detected beacon events to derive a location for a particular asset, for example. Using the GIS <NUM> and site builder <NUM>, maps can be modified/updated in real time (or substantially real time given some data processing, transmission, and/or storage latency, etc.) to make fast, fluid changes based on incoming data, for example. The GIS <NUM> provides spatial context to the inside of the facility <NUM> mapped by the site builder <NUM>, for example. Using the GIS <NUM> platform, distance(s) between objects can be derived and georeferenced coordinates can be included. Information generated by the location engine <NUM> can be consumed by one or more products <NUM> including asset management <NUM>, hospital information system (HIS) <NUM>, and/or other third party system <NUM>, etc. Badge configuration services <NUM> can also help with badge configuration on the server/cloud side, helping to update the badge configuration tool <NUM> at the hospital <NUM>, for example.

In certain examples, a user interface device <NUM>, such as a server, desktop computer, laptop computer, tablet computer, smart phone, and/or other computing device providing a graphical user interface (GUI) enables a Web-based and/or other console to be provided via the interface to one or more users. The user interface device <NUM> provides information, such as via a Web-based console and/or other GUI, etc., regarding connected local devices, such as beacons, badges, receivers, etc. Health status information such as heartbeat, location, MAC address and/or other device identifier (e.g., universally unique identifier (UUID), minor value, major value, etc.), firmware information, battery life, timestamp, signal strength, etc., can be viewed, interacted with, and/or otherwise modified, routed to another system/program, etc., via the user interface device <NUM>, for example. The user interface device <NUM> can be a router, gateway, and/or other edge device such as gateway 318a, 318b, server <NUM>, etc., and/or a separate device in communication with the hospital network <NUM> and/or cloud <NUM>, for example.

Thus, certain examples provide systems and methods to monitor and manage badge(s), beacon(s), and receiver(s) and provide health statistics for such devices. Certain examples provide APIs that allow devices installed at a location to communicate status information to the cloud <NUM> infrastructure to be processed to display reports, analytics, facilitate interaction for repair/update, etc., to drive notifications, alerts, maintenance, etc., for system health and ongoing system operation. Certain examples facilitate monitoring and evaluation of network and system performance and retuning/reconfiguring/redefining desired network and/or system operation.

More generally, <FIG> illustrates a basic real time location platform <NUM> including a number of monitored devices <NUM>-<NUM> and an edge device <NUM> in a facility <NUM>, along with a cloud health processor <NUM> and management service(s) <NUM> in a cloud <NUM>. The monitored devices <NUM>-<NUM> can include one or more beacons, badges, and/or receivers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc. The edge device <NUM> can include the location gateway <NUM>, etc. The cloud health processor <NUM> can include the location server <NUM>, etc. The management services <NUM> can include beacon/site management services <NUM>, badge configuration services <NUM>, etc..

The cloud health processor <NUM> defines a mechanism and associated API specification by which location receivers <NUM>, <NUM>, <NUM> deployed as part of a real time location platform <NUM>, <NUM> can transmit system health information using an event-based messaging framework. The data/events provided can be captured and utilized to maintain the system <NUM>, <NUM> and help ensure optimal and/or otherwise improved performance.

In certain examples, given numerous dependencies, connectivity issues, and power concerns, the system <NUM> is configured such that the devices <NUM>-<NUM> self-report their health status and associated system events to the health processor <NUM> via the edge device <NUM> to help maintain a functional system <NUM>, <NUM>, <NUM>. For example, location devices <NUM>-<NUM> are designed to submit event data (e.g., JSON documents, and/or other format/protocol such as XML, CSV, HTTP, JMS, SMTP, etc.) via the edge device <NUM> to an interface (e.g., a RESTful service interface, etc.) at or in communication with the health processor <NUM>. In certain examples, the user interface device <NUM> can form part of the health processor <NUM> and/or be in communication with the health processor <NUM> to process and display device <NUM>-<NUM> health information.

A plurality of events can be defined. An event includes a set of base (e.g., header, etc.) attributes that are used for ongoing system health management. In addition, each event includes a details section in which attributes/data specific to an event type can be included. For example, numerous events can be defined, and these events can be sent in response to a specified condition (e.g., device regaining network connectivity, e.g., device placed on charger, e.g., device removed from charger, etc.) and/or on a time schedule that is configurable as part of the device profile. The following table provides some examples of receiver health-related events:.

Thus, each receiver transmits health/operating details to the processor <NUM> via the API (e.g., API <NUM>, etc.) when associated events are executed. In certain examples, a Wi-Fi reconnect does not include a roaming and/or access point transition for a mobile receiver. In certain examples, a heartbeat timer restarts on device reboot. In certain examples, a heartbeat interval is set to be frequent enough to monitor temperature changes, eliminating a need for temperature threshold events, for example. In certain examples, a beacon, badge, etc., can transmit similar health/operating details to the processor <NUM>. In certain examples, a reason for reboot and/or associated error details (e.g., system error log, etc.) can be provided.

In certain examples, a service interface (e.g., API) specification can be provided, such as for a RESTful service, etc., used by device(s) <NUM>-<NUM> to post health events. The service interface can define a health API and/or a reference API that provides definition for location events, time, firmware updates, system health, receiver configuration, etc. For example, a location event request can be formatted as a JSON object to include a beacon MAC address, UUID, RSSI, battery life (e.g., percentage of battery life remaining, battery value, etc.), timestamp (e.g., a time at which the beacon event was received, etc.), receiver MAC address, etc. A get time request can be implemented as a JSON formatted object including a time, such as a UNIX time, POSIX time, Epoch time, UTC time, etc., for example. A firmware update can be implemented as a binary file providing an application/octet stream to a target device <NUM>-<NUM>, for example. A system health request can be implemented, for example, as a JSON formatted object including an event type, device MAC address, timestamp, firmware version, depth of discharge (e.g., percent of battery life remaining, etc.), temperature (e.g., device temperature in Fahrenheit, Celsius, etc.), details (e.g., any additional details provided for the event), etc. A receiver configuration request can be implemented, for example, as a JSON formatted object including a scan interval (e.g., a period of time for which received beacons are being evaluated to determine which beacons should be transmitted, etc.), a scan channel (e.g., BLE channel(s) on which the device should listen, etc.), heartbeat interval, Wi-Fi transmission frequency, profile name/ID, beacon type, proximity range, RSSI low (e.g., weakest RSSI signal strength considered within the range that a beacon should be processed, etc.), RSSI high (e.g., strongest RSSI signal strength considered within the range that a beacon should be processed, etc.), beacon hit count (e.g., a number of beacon hits required to be received within a scan interval, etc.), scan retention interval (e.g., a number of scans that occur before results of a scan are stored for transmission, etc.), send closest only (e.g., if true, all beacons received within the given range will be transmitted by the device, else only the closest (e.g., highest RSSI value) beacon is to be transmitted, etc.), suppress repeats (e.g., if true, transmissions from the device will be suppressed if they are the same as the previous scan interval, etc.), time service URL (e.g., uniform resource locator exposing the time service, etc.), event service URL (e.g., uniform resource locator exposing the event service, etc.), firmware service URL (e.g., uniform resource locator exposing the firmware service, etc.), firmware filename, etc..

The quality of location data provided by the real time location platform <NUM>, <NUM> is dependent on the health of the devices deployed to receive sensory/location events. If the deployed devices are not functioning as intended, the location data produced by the system has the potential to be inaccurate/unreliable. To help ensure accurate location data, support system(s) and/or team(s) (e.g., health processor <NUM> and management service <NUM>) must be able to monitor system health, isolate problematic devices and correct the problems through reconfiguration, replacement, upgrade, etc. Thus, certain examples provide a centralized health and monitoring capability for large scale systems that include many thousands of devices deployed in a wide range of environments. Without this system, deployed systems would fall into disrepair over time and/or the costs of monitoring/maintaining such systems would threaten the commercial viability of the dependent products. Certain examples monitor system health and provide maintenance/solutions to enable improved system performance, higher customer satisfaction, higher return on investment for a customer, lower cost of ownership for the customer, lower support costs for a supplier, increased profit margin for the supplier, etc..

In certain examples, the user interface device <NUM> (e.g., executed by and/or working in conjunction with the health processor <NUM>, etc.) provides a plurality of views showing asset status information for a facility. For example, the interface <NUM> provides a Web-based device health console that includes a site overview providing information for some or all RTLS devices at the site. For example, an example GUI running on the interface device <NUM> can provide a site overview, fixed receiver view, mobile receiver view, fixed beacon view, mobile beacon view, and/or event view, etc..

The example overview provides a health overview of a gateway <NUM> and/or other edge device <NUM> through which health information is provided by monitored device(s) <NUM>-<NUM>. For example, connection status, data routing travel time, event throughput, etc., can be measured and reported via the example console.

The example fixed receiver view provides heartbeat, anchor location, and firmware information for fixed receivers at the site, for example. The example fixed receiver view can be used to determine whether a fixed receiver is offline and to verify that fixed receivers have the correct firmware, for example. If a receiver has not sent a heartbeat to the gateway for a certain time interval (e.g., in the past hour, etc.), the receiver will show as offline. The offline status indicates that either the receiver cannot connect to the gateway or Wi-Fi or that the receiver has been unplugged, for example.

The example mobile receiver view provides heartbeat, battery, location, and firmware information for mobile receivers at the site, for example. The mobile receiver view can be used to determine whether a mobile receiver is offline and to verify that fixed receivers have the correct firmware, for example. If a receiver has not sent a heartbeat to the gateway for a certain time interval (e.g., in the past hour, etc.), the receiver will show as offline. The offline status indicates that either the receiver cannot connect to the gateway or Wi-Fi or that the receiver is out of battery, for example. The location of the receiver represents the last place that a fixed beacon saw the mobile receiver and the last time at which the mobile receiver was seen, for example.

The example fixed beacon view provides a fixed beacon MAC address, battery life remaining, anchor location, and timestamp and address of the last mobile receiver that saw the fixed beacon. If a fixed beacon has not been detected by a mobile receiver for a certain time interval (e.g., in the past hour, etc.), the beacon will show as offline. The offline status indicates that the beacon is masked from a receiver, the beacon is out of battery, or the closest receiver is out of battery, for example. The location of the beacon represents the last place that the mobile receiver saw the fixed beacon and a timestamp at which that sighting occurred, for example.

The example mobile beacon view provides a mobile beacon MAC address, battery life remaining, timestamp and address of the last receiver to see the mobile beacon, and information regarding the location of the fixed device (e.g., fixed receiver, fixed beacon, etc.) with respect to which the mobile beacon is positioned. If a mobile beacon has not been detected for a certain time interval (e.g., in the past hour, etc.), the beacon will show as offline. The offline status indicates that the beacon is masked from a receiver, the beacon is out of battery, or the closest receiver is out of battery, for example. The location of the beacon represents the last place that the receiver saw the fixed beacon and a timestamp at which that sighting occurred, for example.

The example event view provides a sensory event history for a chosen beacon or receiver. A timestamp represents a time at which a given sensory event occurred (e.g., between a beacon and a receiver, etc.). An RSSI represents a beacon's signal strength, and a major/minor value represents the beacon major and minor of the chosen beacon, for example.

<FIG> illustrates an example implementation of the cloud health processor <NUM>. In the example of <FIG>, the processor <NUM> includes a message receiver <NUM>, a message evaluator <NUM>, an event processor <NUM>, a health analyzer <NUM>, a health alert notifier <NUM>, and an output generator <NUM>.

The example message receiver <NUM> monitors for a message from a receiver (e.g., from one or more devices <NUM>-<NUM> including one or more beacons, badges, and/or receivers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.). When a message is received, the example message evaluator <NUM> evaluates the received message to determine a message type associated with the message (e.g., location message, firmware message, time message, receiver configuration message, health message, etc.). If the message is not a receiver health message, then, the message evaluator <NUM> sends the message to another processor, such as the location engine <NUM>, site builder <NUM>, consuming product(s) <NUM>, etc..

If the message is a health message, then the message evaluator <NUM> sends the message to the event processor <NUM>. The example event processor <NUM> processes the health message to identify an event type indicated by the message. For example, the message may indicate an on charge event, off charge event, forced reboot event, unforced reboot/system error event, Wi-Fi reconnect event, heartbeat event, etc. Based on the event type, the event processor <NUM> processes the details of the event.

The event processor <NUM> provides the message details and event type to the health analyzer. Based on the event type, the example health analyzer <NUM> compares the details of the event to a threshold, range, standard, norm, etc. If the event is within normal or expected behavior, the event can be logged via the output generator <NUM>. If the event is outside and/or otherwise deviates from the prescribed bound(s), the health alert notifier <NUM> can be triggered in response to the event. In some examples, the health alert notifier <NUM> can generate a response message or instruction to the device via the output generator <NUM> to adjust a level, setting, mode, etc., in response to the event (e.g., not charging enough, not charging properly, irregular heartbeat, reboot needed, etc.) such as to send a message to a user, automatically adjust a device setting, trigger a maintenance request, alert hospital staff to a failing device, change in setting/configuration warranted, etc. Thus, the output generator <NUM> can provide an update and/or other message to the device and/or a third party (e.g., beacon/site management services <NUM>, badge configuration services <NUM>, consuming product(s) <NUM>, etc.) to repair, replace, and/or adjust the affected device(s). An alert, update, and/or other message can be generated to help ensure reliable operation and uptime of the RTLS system <NUM>, <NUM>, for example.

<FIG> illustrates an example implementation of the monitored device <NUM>, <NUM>, <NUM> (with the example monitoring device <NUM> shown in <FIG> for purposes of example illustration only). As described above, the monitored devices <NUM>-<NUM> can include one or more beacons, badges, and/or receivers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc. In the example of <FIG>, the monitored device <NUM> includes a memory <NUM>, a health monitor <NUM>, a processor <NUM>, and a communication interface <NUM>.

The example memory <NUM> stores identification data for the device <NUM> as well as instructions for execution by the processor <NUM> of the device <NUM>. The memory <NUM> can store status and/or other health information for the device <NUM> as determined by the health monitor <NUM>, for example.

<FIG> depicts an example state diagram <NUM> illustrating example health states of a monitored device <NUM>-<NUM>. The example state diagram <NUM> can be stored as a state machine to alter the memory <NUM> and configure the processor <NUM> as directed by the health monitor <NUM> of the device <NUM>-<NUM>, for example. As shown in the example of <FIG>, a plurality of states can include an operating state <NUM>, offline state <NUM>, error state <NUM>, low power state <NUM>, no heartbeat state <NUM>, configuration state <NUM>, reset state <NUM>, reboot state <NUM>, etc. The monitored device <NUM>-<NUM> can transition among states <NUM>-<NUM> according to the example state machine <NUM>.

For example, the monitored device <NUM>-<NUM> can transition to the operating state <NUM> when operating normally according to its configuration. The monitored device <NUM>-<NUM> can transition to the offline state <NUM> when the device <NUM>-<NUM> cannot find a network connected (e.g., to a gateway, Wi-Fi, etc.), for example. The monitored device <NUM>-<NUM> can transition to the error state <NUM> when it detects a problem with its operation, an issue/error outside its defined states, etc. The monitored device <NUM>-<NUM> can transition to the low power state <NUM> when the battery of the device <NUM>-<NUM>, available wall outlet power, etc., is running low on power, for example. The monitored device <NUM>-<NUM> can transition into the no heartbeat state <NUM> when it has not detected another device's heartbeat for a certain time interval, for example.

The monitored device <NUM>-<NUM> can transition into the configuration state <NUM> when the monitored device <NUM>-<NUM> is being configured and/or otherwise set up in its configuration mode. For example, a technician can set up the monitored device <NUM>-<NUM> in configuration mode. The health processor <NUM>, gateway <NUM> (e.g., 318a and/or 318b, etc.), another device <NUM>-<NUM>, etc., can trigger the configuration state <NUM> at the monitored device <NUM>-<NUM> to adjust parameter(s)/setting(s) of the device <NUM>-<NUM>, for example.

The monitored device <NUM>-<NUM> can transition into the reset state <NUM> when instructed to reset its settings to its default settings, for example. For example, a technician, health processor <NUM>, gateway <NUM>, another device <NUM>-<NUM>, etc., can trigger the reset state <NUM> to reset the monitored device <NUM>-<NUM> to its factory default. The monitored device <NUM>-<NUM> can transition into the reboot state <NUM> when a reboot is triggered for the device <NUM>-<NUM> (e.g., by a technician, health processor <NUM>, gateway <NUM>, another device <NUM>-<NUM>, etc.), for example.

<FIG> shows an example data flow <NUM> between a beacon (e.g., a fixed <NUM> or mobile beacon <NUM>, etc.), a receiver (e.g., a fixed <NUM> or mobile receiver <NUM>, etc.), and the cloud health processor <NUM> via the gateway <NUM>. At <NUM>, the beacon <NUM>, <NUM> provides a signal (e.g., a heartbeat, a ping, a status signal, etc.) within its range. For example, the beacon <NUM>, <NUM> broadcasts a signal in its communication range to identify itself and provide its status.

At <NUM>, the receiver <NUM>, <NUM> relays the beacon signal to the gateway <NUM>/edge device <NUM>. For example, the receiver <NUM>, <NUM> receives the beacon signal when in range of the beacon <NUM>, <NUM> and packages information from the received beacon signal and generates a communication for the gateway <NUM>/edge device <NUM>.

In certain examples, the gateway <NUM>/edge device <NUM> can process and react to the beacon signal data from the receiver <NUM>, <NUM> (e.g., by logging the beacon signal data, generating a response (e.g., configuration, reset, reboot, error, acknowledgement, etc.) to return to the receiver <NUM>, <NUM> (and/or through the receiver <NUM>, <NUM> to the beacon <NUM>, <NUM>). In other examples, at <NUM>, the gateway <NUM>/edge device <NUM> relays the message from the receiver <NUM>, <NUM> to the health processor <NUM>. At <NUM>, the health processor <NUM> generates a response (e.g., configuration, reset, reboot, error, acknowledgement, etc.) to return, via the gateway <NUM>/edge device <NUM>, to the receiver <NUM>, <NUM> (and/or through the receiver <NUM>, <NUM> to the beacon <NUM>, <NUM>).

At <NUM>, if the receiver <NUM>, <NUM> receives no beacon signal, then the receiver <NUM>, <NUM> provides feedback to the gateway <NUM>/edge device <NUM> to be routed to the health processor <NUM> regarding the missing/unavailable/offline/erroring beacon <NUM>, <NUM>, for example. At <NUM>, the health processor <NUM> (and/or its gateway <NUM>/edge device <NUM>, etc.) can log the information and generate a response (e.g., to the receiver <NUM>, <NUM>, to the gateway <NUM>/edge device <NUM>, to the beacon <NUM>, <NUM>, to a service request, etc.).

At <NUM>, if the gateway <NUM>/edge device <NUM> receives no receiver communication, then the gateway <NUM>/edge device <NUM> to can trigger a response and/or send an alert to the health processor <NUM> regarding the missing/unavailable/offline/erroring receiver <NUM>, <NUM>, for example. At <NUM>, the health processor <NUM> (and/or its gateway <NUM>/edge device <NUM>, etc.) can log the information and generate a response (e.g., to the receiver <NUM>, <NUM>, to the gateway <NUM>/edge device <NUM>, to a service request, etc.).

At <NUM>, if the receiver <NUM>, <NUM> receives no gateway/edge device communication, then the receiver <NUM>, <NUM> can enter an offline <NUM> or error <NUM> state, for example, until, at <NUM>, receiving an instruction such as a reset, reboot, heartbeat communication from the gateway <NUM>/edge device <NUM>, etc..

While example implementations of the systems <NUM>, <NUM>, <NUM>, <NUM> are illustrated in <FIG>, one or more of the elements, processes and/or devices illustrated in <FIG> may be combined, divided, re-arranged, omitted, eliminated and/or implemented in any other way. Further, the example components of <FIG> can be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example components of <FIG> can be implemented by one or more analog or digital circuit(s), logic circuits, programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or field programmable logic device(s) (FPLD(s)). When reading any of the apparatus or system claims of this patent to cover a purely software and/or firmware implementation, at least one of the example components of <FIG> is/are hereby expressly defined to include a tangible computer readable storage device or storage disk such as a memory (e.g., a read only memory (ROM), hard drive, flash memory, other volatile and/or non-volatile memory, etc.), a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc. storing the software and/or firmware. Further still, the example systems of <FIG> can include one or more elements, processes and/or devices in addition to, or instead of, those illustrated in <FIG>, and/or may include more than one of any or all of the illustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions for implementing the systems, states, and data flows of <FIG> are shown in <FIG>. In these examples, the machine readable instructions comprise program(s) for execution by a processor such as the processor <NUM> shown in the example processor platform <NUM> discussed below in connection with <FIG>. The program(s) can be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a DVD, a Blu-ray disk, or a memory associated with the processor <NUM>, but the entire program and/or parts thereof can alternatively be executed by a device other than the processor <NUM> and/or embodied in firmware or dedicated hardware. Further, although the example program(s) are described with reference to the flowcharts illustrated in <FIG>, many other methods of implementing the example systems may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

As mentioned above, the example process(es) of <FIG> can be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a ROM, a CD, a DVD, a cache, a random-access memory (RAM) and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, "tangible computer readable storage medium" and "tangible machine readable storage medium" are used interchangeably. Additionally or alternatively, the example process(es) of <FIG> can be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage device or storage disk in which information is stored for any duration (e.g., for extended time periods, permanently, for brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable storage device and/or storage disk and to exclude propagating signals and to exclude transmission media. As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term "comprising" is open ended.

<FIG> illustrates a flow diagram of an example method <NUM> to monitor receiver and/or other device health in a real time location system. At block <NUM>, messages are monitored to detect a message from a receiver. For example, the example message receiver <NUM> monitors for a message from a receiver (e.g., from one or more devices <NUM>-<NUM> including one or more beacons, badges, and/or receivers <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, etc.). At block <NUM>, when a message is received, the message is evaluated to determine a message type. For example, the example message evaluator <NUM> evaluates the received message to determine a message type associated with the message (e.g., location message, firmware message, time message, receiver configuration message, health message, etc.). At block <NUM>, the message type is compared to a health message type. If the message is not a health message, then, at block <NUM>, the message is redirected for further processing. For example, when the message is not a receiver health message, the message evaluator <NUM> sends the message to another processor, such as the location engine <NUM>, site builder <NUM>, consuming product(s) <NUM>, etc..

If the message is a health message, then, at block <NUM>, the health message is processed to identify an event type indicated by the health message. For example, the message evaluator <NUM> sends the message to the event processor <NUM>. The example event processor <NUM> processes the health message to identify an event type indicated by the message. For example, the message may indicate an on-charge event, off-charge event, forced reboot event, unforced reboot/system error event, Wi-Fi reconnect event, heartbeat event, etc. At block <NUM>, based on the event type, the event processor <NUM> processes the details of the event. For example, the event processor <NUM> digests information associated with the event type and additional details if provided in the message.

At block <NUM>, the event is compared to prescribed bound(s) for the event. For example, the event processor <NUM> provides the message details and event type to the health analyzer. Based on the event type, the example health analyzer <NUM> compares the details of the event to a threshold, range, standard, norm, etc. At block <NUM>, if the event is within normal or expected behavior, the event is logged. For example, the event can be logged via the output generator <NUM>. At block <NUM>, if the event is outside and/or otherwise deviates from the prescribed bound(s), a response to the event is triggered. For example, the health alert notifier <NUM> can be triggered in response to the event. In some examples, the health alert notifier <NUM> can generate a response message or instruction to the device via the output generator <NUM> to adjust a level, setting, mode, etc., in response to the event (e.g., not charging enough, not charging properly, irregular heartbeat, reboot/reset needed, reconfiguration warranted, etc.) such as to send a message to a user, automatically adjust a device setting, trigger a maintenance request, alert hospital staff to a failing device, change in setting/configuration warranted, etc. At block <NUM>, an output is provided. For example, the output generator <NUM> can provide an update and/or other message to the device and/or a third party (e.g., beacon/site management services <NUM>, badge configuration services <NUM>, consuming product(s) <NUM>, etc.) to repair, replace, and/or adjust the affected device(s). An alert, update, and/or other message can be generated to help ensure reliable operation and uptime of the RTLS system <NUM>, <NUM>, for example.

<FIG> provides further detail regarding an example implementation of processing an event based on the identified event type (block <NUM> of the example of <FIG>). At block <NUM>, a time associated with the event is processed. For example, the received message for the event can include a time associated with the event that is processed by the event processor <NUM> to determine a timestamp associated with the event and/or a related message, a time since last response, time since heartbeat, etc..

At block <NUM>, firmware is verified. For example, the received message for the event can include an indication of firmware version for the associated device <NUM>-<NUM>, and the event processor <NUM> can determine whether or not the device <NUM>-<NUM> has the latest and/or proper firmware.

At block <NUM>, system health is evaluated. For example, the event processor <NUM> and/or health analyzer <NUM> can evaluate event contents to determine an error code, indication of device <NUM>-<NUM> state, time since epoch, device battery life remaining, device temperature, and/or other event detail to determine a system health of the device <NUM>-<NUM> (e.g., a receiver, etc.).

At block <NUM>, receiver configuration is determined. For example, the health processor <NUM> can stored receiver configuration information, which can then be analyzed and compared to the evaluation of the system health and other event information such that the event processor <NUM>, health analyzer <NUM>, etc., of the health processor <NUM> can determine whether the receiver configuration is contributing to and/or otherwise causing the event, an adjustment to the receiver configuration can remedy an issue associated with the event, etc..

At block <NUM>, an analysis of the event is generated based on the time, firmware verification, system health evaluation, and receiver configuration determination. For example, the health processor <NUM> and its components can analyze the event based on timing (e.g., time of occurrence, time since last contact, time interval, etc.), firmware (e.g., old version, incorrect/inapplicable version, etc.), system health, receiver configuration, etc., to develop an understanding of the event, an impact of the event, and potential next action(s) for the event. For example, the analysis of the event by the event processor <NUM> can determine whether or not the event fits within expected, allowed, and/or other operational bounds for the receiver, that type of event, etc. Control can then return to block <NUM> at which the event is determined to be within or outside its bounds, or example.

Thus, in certain examples, each receiver sends details regarding its system health to an API hosted by the edge device <NUM> and/or health processor <NUM> based on execution of certain events (e.g., on-charge, off-charge, forced reboot, unforced reboot/system error, network reconnect, heartbeat, etc.), and the health processor <NUM> can evaluate such health details to determine a response/next action, etc..

<FIG> provides further detail regarding an example implementation of triggering a response to the event (block <NUM> of the example of <FIG>). At block <NUM>, the processing of the event is reviewed to determine the type and nature of the event. For example, the event is reviewed by the health processor <NUM> to determine whether the event affects the operation of a receiver, an edge device, beacon, etc., such as an unresponsive receiver, a receiver not getting a beacon signal, a receiver having low battery, a receiver recently rebooted, etc..

At block <NUM>, available options for response are compared against results of the event processing to determine a most appropriate available response or responses. For example, the output generator <NUM> can provide an update and/or other message to the device and/or a third party (e.g., beacon/site management services <NUM>, badge configuration services <NUM>, consuming product(s) <NUM>, etc.) to repair, replace, and/or adjust the affected device(s). An alert, update, and/or other message can be generated to help ensure reliable operation and uptime of the RTLS system <NUM>, <NUM>, for example. Reconfiguration information, a reboot or reset instruction, Wi-Fi credentials, etc., can be provided in response to the event, for example.

If the response is determined to be a reconfiguration of the affected device <NUM>-<NUM>, then, at block <NUM>, reconfiguration information is provided for output at block <NUM> to the device <NUM>-<NUM>. For example, receiver parameters can be adjusted to operate on a different frequency, with a different time interval, looking for another beacon, at a different power level, with a heartbeat adjustment, etc. If the response is determined to be a reset of the affected device <NUM>-<NUM>, then, at block <NUM>, a reset command is sent for output at block <NUM> to the device <NUM>-<NUM> to reset the device <NUM>-<NUM> in a default or factory state, etc. If the response is determined to be a reboot, then, at block <NUM>, a reboot command is sent for output at block <NUM> to the affected device <NUM>-<NUM> to reboot or restart the device <NUM>-<NUM>. If the response is determined to be to generate a log of the event, then, at block <NUM>, a log entry is generated to be conveyed to a user, another system, etc., in the output of block <NUM>. If the response is determined to be maintenance of the affected device <NUM>-<NUM>, then, at block <NUM>, a maintenance request is generated for output at block <NUM> to a service center, operator, scheduling system, maintenance professional, etc. If the response is determined to be an alert, then, at block <NUM>, an alert is generated for output at block <NUM> to an operator, other system, service center, log, user interface, etc. For example, an alarm (e.g., an alphanumeric, audible, visual, haptic, and/or other alarm) can be generated as an alert. A charging reminder can be generated as an alert, for example.

At block <NUM>, if an additional response is to be provided, then control returns to block <NUM>. Otherwise, control returns to block <NUM> to generate an output.

<FIG> is a block diagram of an example processor platform <NUM> capable of executing the instructions of <FIG> to implement the example systems and components disclosed and described herein with respect to <FIG>. The processor platform <NUM> can be, for example, a server, a personal computer, or any other type of computing device.

The processor <NUM> of the illustrated example executes the instructions to implement the example message receiver <NUM>, the example message evaluator <NUM>, the example event processor <NUM>, the example health analyzer <NUM>, the example health alert notifier <NUM>, the example output generator <NUM>, and/or, more generally, the example health processor of <FIG>.

The input device(s) <NUM> permit(s) a user to enter data and commands into the processor <NUM>.

The output devices <NUM> can be implemented, for example, by display devices (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touchscreen, a tactile output device, a printer and/or speakers). The interface circuit <NUM> of the illustrated example, thus, typically includes a graphics driver card, a graphics driver chip or a graphics driver processor.

The coded instructions <NUM> of <FIG> may be stored in the mass storage device <NUM>, in the volatile memory <NUM>, in the non-volatile memory <NUM>, and/or on a removable tangible computer readable storage medium such as a CD or DVD.

From the foregoing, it will appreciate that the above disclosed methods, apparatus and articles of manufacture facilitate proximity detection and location tracking of assets in an industrial setting. As described above, example disclosures uniquely eliminate the expensive and difficult-to-maintain infrastructure. An example benefit of the disclosed techniques includes determining location awareness of assets in the industrial setting without constructing a new infrastructure. In some disclosed examples, the location awareness of assets is determined by "crowd-sourcing" probability proximity locations of the assets.

While prior RTLS systems and associated devices did not have an ability to provide health status information and communicate between a processor and device(s) to update configuration, restart/reset, alert, and/or otherwise respond to a health event, certain examples provide receivers, beacons, badges, and/or other RTLS devices with electronic circuitry and programming to store, communicate, and respond to health status events. Certain examples provide a health processor, embedded in an edge device and/or implemented in a cloud, that processes system health events and communicates with and controls the RTLS devices to address such health events. Thus, certain examples not only provide new technology previously absent from RTLS devices and associated systems but also provide an ecosystem and infrastructure to help ensure improved RTLS uptime, reliability, automated maintenance/configurability/troubleshooting, and accuracy for health asset monitoring, tracking, and management.

Claim 1:
An apparatus comprising:
a real time location system, RTLS, including a cloud health processor (<NUM>), the cloud health processor (<NUM>) including:
an event processor (<NUM>) to process an event included in a message from an RTLS device to identify event information related to the RTLS device, the event relating to a health of the RTLS device and the event information including an event type and an event detail, wherein the health of the RTLS device includes at least a reboot status of the RTLS device,
a health analyzer (<NUM>) to compare the event detail to a prescribed bound for the event type, the event relating to the health of the RTLS device; and
an output generator (<NUM>) to, when the event information is outside the prescribed bound, trigger a response to address the event with respect to the RTLS device, wherein the response includes at least one of a charging reminder, a power level adjustment, an alarm, a reboot, or a heartbeat adjustment.