U.S. patent application number 15/824085 was filed with the patent office on 2019-05-30 for door fault identification.
The applicant listed for this patent is Schlage Lock Company LLC. Invention is credited to Daniel Langenberg, Nathanael L. Thomas.
Application Number | 20190162705 15/824085 |
Document ID | / |
Family ID | 66632209 |
Filed Date | 2019-05-30 |
![](/patent/app/20190162705/US20190162705A1-20190530-D00000.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00001.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00002.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00003.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00004.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00005.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00006.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00007.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00008.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00009.png)
![](/patent/app/20190162705/US20190162705A1-20190530-D00010.png)
View All Diagrams
United States Patent
Application |
20190162705 |
Kind Code |
A1 |
Langenberg; Daniel ; et
al. |
May 30, 2019 |
DOOR FAULT IDENTIFICATION
Abstract
A method according to one embodiment includes receiving sensor
data from a plurality of sensors of a door device associated with a
door, analyzing the sensor data to determine behavior data
indicative of a behavior of the door device, and comparing the
behavior data to a plurality of representative data associated with
a plurality of door faults to determine a corresponding likelihood
that the sensor data corresponds with each of the door faults.
Inventors: |
Langenberg; Daniel;
(Zionsville, IN) ; Thomas; Nathanael L.; (Carmel,
IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Schlage Lock Company LLC |
Carmel |
IN |
US |
|
|
Family ID: |
66632209 |
Appl. No.: |
15/824085 |
Filed: |
November 28, 2017 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G01C 19/5776 20130101;
G01N 29/14 20130101; G01P 13/00 20130101; G01P 15/0802 20130101;
G01N 29/4481 20130101; G01N 2291/0258 20130101; G01N 29/4454
20130101; G06N 3/08 20130101 |
International
Class: |
G01N 29/44 20060101
G01N029/44; G06N 3/08 20060101 G06N003/08; G06F 17/30 20060101
G06F017/30; G01C 19/5776 20120101 G01C019/5776; G01P 13/00 20060101
G01P013/00; G01P 15/08 20060101 G01P015/08 |
Claims
1. A method, comprising: receiving sensor data from a plurality of
sensors of a door device associated with a door; analyzing the
sensor data to determine behavior data indicative of a behavior of
the door device; and comparing the behavior data to a plurality of
representative data associated with a plurality of door faults to
determine a corresponding likelihood that the sensor data
corresponds with each of the door faults.
2. The method of claim 1, wherein analyzing the sensor data
comprises applying one or more filters to the sensor data.
3. The method of claim 1, wherein analyzing the sensor data
comprises performing at least one of filtering or synthesizing the
sensor data to determine one or more inertial measurements
indicative of the behavior of the door device.
4. The method of claim 3, wherein the plurality of sensors
comprises one or more environmental sensors adapted to generate
sensor data indicative of a physical environment of the door
device; and wherein analyzing the sensor data comprises determining
an environmental context of the door device based on the sensor
data generated by the one or more environmental sensors.
5. The method of claim 4, wherein the behavior data is determined
based on the one or more inertial measurements and the
environmental context of the door device.
6. The method of claim 5, wherein the behavior data comprises data
indicative of at least one of an acceleration of the door, a peak
velocity of the door during a closing phase of the door, a peak
opening angle of the door, a duration of movement of the door from
the peak opening angle to a latch zone of the door, or a duration
of movement of the door from the latch zone to a closed position of
the door.
7. The method of claim 1, wherein receiving the sensor data from
the plurality of sensors comprises: receiving accelerometer data
indicative of an acceleration of the door device from one or more
accelerometers; receiving gyrometer data indicative of a velocity
of the door device from one or more gyrometers; and receiving
magnetometer data indicative of at least one of an orientation of
the door device or a magnetic field sensed by one or more
magnetometers.
8. The method of claim 7, wherein analyzing the sensor data
comprises analyzing the accelerometer data to detect any
high-acceleration event or high-vibration event experienced by the
door device.
9. The method of claim 7, wherein analyzing the sensor data
comprises analyzing the gyrometer data to detect an abnormal
velocity experienced by the door device.
10. The method of claim 1, further comprising monitoring for one or
more external forces acting upon the door device; and waking one or
more of the plurality of sensors in response to detecting an
external force acting upon the door device.
11. The method of claim 1, further comprising displaying a most
likely fault solution to a user based on the corresponding
likelihood that the sensor data corresponds with each of the door
faults.
12. The method of claim 11, wherein displaying the most likely
fault solution further comprises displaying a recommended
maintenance operation for the door.
13. The method of claim 1, wherein comparing the behavior data to
the plurality of representative data associated with a plurality of
door faults further comprises comparing the behavior data to
representative data associated with normal operation of the
door.
14. A door fault identification system, comprising: at least one
processor; and at least one memory comprising a plurality of
instructions stored thereon that, in response to execution by the
at least one processor, causes the door fault identification system
to: receive sensor data from a plurality of sensors of a door
device associated with a door; analyze the sensor data to determine
behavior data indicative of a behavior of the door device; and
compare the behavior data to a plurality of representative data
associated with a plurality of door faults to determine a
corresponding likelihood that the sensor data corresponds with each
of the door faults.
15. The door fault identification system of claim 14, wherein the
behavior data comprises initial behavior data; wherein the at least
one memory comprises a fault prediction database stored thereon;
and wherein the plurality of instructions further causes the door
fault identification system to: receive user input indicative of
maintenance performed on the door; receive new sensor data from the
plurality of sensors in response to receipt of the user input
indicative of the maintenance performed; analyze the new sensor
data to determine new behavior data indicative of the behavior of
the door device; compare the new behavior data to the plurality of
representative data associated with the plurality of door faults to
determine a new corresponding likelihood that the new sensor data
corresponds with each of the door faults; and update a fault
prediction database that includes the plurality of representative
data associated with the plurality of door faults based on the
maintenance performed and the comparison of the new behavior data
to the plurality of representative data.
16. The door fault identification system of claim 15, wherein to
update the fault prediction database comprises to update weights of
a machine learning algorithm; and wherein each of the weights is
associated with a corresponding door fault.
17. The door fault identification system of claim 16, wherein to
update the fault prediction database comprises to update weights of
an artificial neural network.
18. The door fault identification system of claim 14, wherein the
plurality of instructions further causes the door fault
identification system to display a most likely fault solution to a
user based on the corresponding likelihood that the sensor data
corresponds with each of the door faults.
19. The door fault identification system of claim 1, wherein the
plurality of sensors comprises an accelerometer adapted to generate
accelerometer data indicative of an acceleration of the door
device, a gyrometer adapted to generate gyrometer data indicative
of an orientation of the door device, and a magnetometer adapted to
generate magnetometer data indicative of a sensed magnetic field;
and wherein to analyze the sensor data comprises to (i) analyze the
accelerometer data to detect any high-acceleration event or
high-vibration event experienced by the door device and (ii)
analyze the gyrometer data to detect any high velocity spikes
experienced by the door device.
20. The door fault identification system of claim 19, wherein the
plurality of sensors further comprises one or more environmental
sensors adapted to generate sensor data indicative of a physical
environment of the door device; wherein to analyze the sensor data
comprises to (i) at least one of filter or synthesize the sensor
data to determine one or more inertial measurements indicative of
the behavior of the door device and (ii) determine an environmental
context of the door device based on the sensor data generated by
the one or more environmental sensors; and wherein the behavior
data is determined based on the one or more inertial measurements
and the environmental context of the door device.
Description
BACKGROUND
[0001] The operation of a door typically degrades over time due to
various faults or abnormalities in the operation of the door. For
example, there may be hinge problems, lock problems, door closer
problems, warping frames, door expansion/contraction, threshold
problems, and/or other factors that prevent the door from operating
properly. The root cause of the improper door operation is often
difficult to diagnose, for example, because many different door
faults can exhibit similar symptoms. The door faults may also
slowly manifest over time, and therefore technicians and users may
not recognize the problem. Or, the technicians and users may simply
ignore the problem until it damages the door or surrounding
structures (e.g., the door frame) or it becomes a safety or
security concern.
[0002] Maintenance technicians often rely on their experience and
training to identify the root cause of the abnormal/improper door
operation. Typically, the maintenance technician will move the door
between an open and closed position, visually inspect the door and
ancillary structures for signs of wear or loose parts, listen for
various sounds throughout the range of motion, and/or feel for any
door vibrations or "sticking points" throughout the range of
motion. More advanced examination may include, for example, using a
force gauge to determine the amount of force required to open and
close the door. Due to the wide array of potential door faults and
associated door hardware, oftentimes, the maintenance technician
must make multiple trips between the location of the door and that
of the parts warehouse as the technician is troubleshooting and
repairing the door.
SUMMARY
[0003] According to an embodiment, a method may include receiving
sensor data from a plurality of sensors of a door device associated
with a door, analyzing the sensor data to determine behavior data
indicative of a behavior of the door device, and comparing the
behavior data to a plurality of representative data associated with
a plurality of door faults to determine a corresponding likelihood
that the sensor data corresponds with each of the door faults.
[0004] In some embodiments, analyzing the sensor data may include
applying one or more filters to the sensor data.
[0005] In some embodiments, analyzing the sensor data may include
performing at least one of filtering or synthesizing the sensor
data to determine one or more inertial measurements indicative of
the behavior of the door device.
[0006] In some embodiments, the plurality of sensors may include
one or more environmental sensors adapted to generate sensor data
indicative of a physical environment of the door device, and
analyzing the sensor data may include determining an environmental
context of the door device based on the sensor data generated by
the one or more environmental sensors.
[0007] In some embodiments, the behavior data may be determined
based on the one or more inertial measurements and the
environmental context of the door device.
[0008] In some embodiments, the behavior data may include data
indicative of at least one of an acceleration of the door, a peak
velocity of the door during a closing phase of the door, a peak
opening angle of the door, a duration of movement of the door from
the peak opening angle to a latch zone of the door, or a duration
of movement of the door from the latch zone to a closed position of
the door.
[0009] In some embodiments, receiving the sensor data from the
plurality of sensors may include receiving accelerometer data
indicative of an acceleration of the door device from one or more
accelerometers, receiving gyrometer data indicative of a velocity
of the door device from one or more gyrometers, and receiving
magnetometer data indicative of at least one of an orientation of
the door device or a magnetic field sensed by one or more
magnetometers.
[0010] In some embodiments, analyzing the sensor data may include
analyzing the accelerometer data to detect any high-acceleration
event or high-vibration event experienced by the door device.
[0011] In some embodiments, analyzing the sensor data may include
analyzing the gyrometer data to detect an abnormal velocity
experienced by the door device.
[0012] In some embodiments, the method may further include
monitoring for one or more external forces acting upon the door
device, and waking one or more of the plurality of sensors in
response to detecting an external force acting upon the door
device.
[0013] In some embodiments, the method may further include
displaying a most likely fault solution to a user based on the
corresponding likelihood that the sensor data corresponds with each
of the door faults.
[0014] In some embodiments, displaying the most likely fault
solution may include displaying a recommended maintenance operation
for the door.
[0015] In some embodiments, comparing the behavior data to the
plurality of representative data associated with a plurality of
door faults may include comparing the behavior data to
representative data associated with normal operation of the
door.
[0016] According to another embodiment, a door fault identification
system may include at least one processor and at least one memory
comprising a plurality of instructions stored thereon that, in
response to execution by the at least one processor, causes the
door fault identification system to receive sensor data from a
plurality of sensors of a door device associated with a door,
analyze the sensor data to determine behavior data indicative of a
behavior of the door device, and compare the behavior data to a
plurality of representative data associated with a plurality of
door faults to determine a corresponding likelihood that the sensor
data corresponds with each of the door faults.
[0017] In some embodiments, the behavior data may include initial
behavior data, the at least one memory may include a fault
prediction database stored thereon, and the plurality of
instructions may further cause the door fault identification system
to receive user input indicative of maintenance performed on the
door, receive new sensor data from the plurality of sensors in
response to receipt of the user input indicative of the maintenance
performed, analyze the new sensor data to determine new behavior
data indicative of the behavior of the door device, compare the new
behavior data to the plurality of representative data associated
with the plurality of door faults to determine a new corresponding
likelihood that the new sensor data corresponds with each of the
door faults, and update a fault prediction database that includes
the plurality of representative data associated with the plurality
of door faults based on the maintenance performed and the
comparison of the new behavior data to the plurality of
representative data.
[0018] In some embodiments, updating the fault prediction database
may include updating weights of a machine learning algorithm, and
each of the weights may be associated with a corresponding door
fault.
[0019] In some embodiments, updating the fault prediction database
may include updating weights of an artificial neural network.
[0020] In some embodiments, the plurality of instructions may
further cause the door fault identification system to display a
most likely fault solution to a user based on the corresponding
likelihood that the sensor data corresponds with each of the door
faults.
[0021] In some embodiments, the plurality of sensors may include an
accelerometer adapted to generate accelerometer data indicative of
an acceleration of the door device, a gyrometer adapted to generate
gyrometer data indicative of an orientation of the door device, and
a magnetometer adapted to generate magnetometer data indicative of
a sensed magnetic field, and analyzing the sensor data may include
analyzing the accelerometer data to detect any high-acceleration
event or high-vibration event experienced by the door device and
analyzing the gyrometer data to detect any high velocity spikes
experienced by the door device.
[0022] In some embodiments, the plurality of sensors may further
include one or more environmental sensors adapted to generate
sensor data indicative of a physical environment of the door
device, and analyzing the sensor data may include filtering and/or
synthesizing the sensor data to determine one or more inertial
measurements indicative of the behavior of the door device and
determining an environmental context of the door device based on
the sensor data generated by the one or more environmental sensors,
and the behavior data may be determined based on the one or more
inertial measurements and the environmental context of the door
device.
[0023] Further embodiments, forms, features, and aspects of the
present application shall become apparent from the description and
figures provided herewith.
BRIEF DESCRIPTION OF THE DRAWINGS
[0024] The concepts described herein are illustrative by way of
example and not by way of limitation in the accompanying figures.
For simplicity and clarity of illustration, elements illustrated in
the figures are not necessarily drawn to scale. Where considered
appropriate, references labels have been repeated among the figures
to indicate corresponding or analogous elements.
[0025] FIG. 1 is a simplified block diagram of at least one
embodiment of a door fault identification system;
[0026] FIG. 2 is a simplified block diagram of at least one
embodiment of a computing system;
[0027] FIG. 3 is a simplified block diagram of at least one
embodiment of a door device of the system of FIG. 1;
[0028] FIG. 4 illustrates various inertial characteristics of the
door device of FIG. 3;
[0029] FIG. 5 is a simplified flow diagram of at least one
embodiment of a method for door fault identification;
[0030] FIG. 6 is a simplified flow diagram of at least one
embodiment of a method for analyzing sensor data to determine
inertial measurements of the door's behavior;
[0031] FIG. 7 is a simplified flow diagram of at least one
embodiment of a method for determining the likelihoods of various
door faults;
[0032] FIG. 8 is a graph depicting sensor data for normal
operations of the door according to at least one embodiment;
[0033] FIG. 9 is a graph depicting various door zones of motion of
the door according to at least one embodiment;
[0034] FIGS. 10-14 are graphs depicting sensor data associated with
the operation of the door during various door fault states; and
[0035] FIGS. 15-16 are a simplified flow diagram of at least one
embodiment of a method for updating a fault prediction database and
associated algorithm.
DETAILED DESCRIPTION
[0036] Although the concepts of the present disclosure are
susceptible to various modifications and alternative forms,
specific embodiments have been shown by way of example in the
drawings and will be described herein in detail. It should be
understood, however, that there is no intent to limit the concepts
of the present disclosure to the particular forms disclosed, but on
the contrary, the intention is to cover all modifications,
equivalents, and alternatives consistent with the present
disclosure and the appended claims.
[0037] References in the specification to "one embodiment," "an
embodiment," "an illustrative embodiment," etc., indicate that the
embodiment described may include a particular feature, structure,
or characteristic, but every embodiment may or may not necessarily
include that particular feature, structure, or characteristic.
Moreover, such phrases are not necessarily referring to the same
embodiment. It should further be appreciated that although
reference to a "preferred" component or feature may indicate the
desirability of a particular component or feature with respect to
an embodiment, the disclosure is not so limiting with respect to
other embodiments, which may omit such a component or feature.
Further, when a particular feature, structure, or characteristic is
described in connection with an embodiment, it is submitted that it
is within the knowledge of one skilled in the art to implement such
feature, structure, or characteristic in connection with other
embodiments whether or not explicitly described. Additionally, it
should be appreciated that items included in a list in the form of
"at least one of A, B, and C" can mean (A); (B); (C); (A and B); (B
and C); (A and C); or (A, B, and C). Similarly, items listed in the
form of "at least one of A, B, or C" can mean (A); (B); (C); (A and
B); (B and C); (A and C); or (A, B, and C). Further, with respect
to the claims, the use of words and phrases such as "a," "an," "at
least one," and/or "at least one portion" should not be interpreted
so as to be limiting to only one such element unless specifically
stated to the contrary, and the use of phrases such as "at least a
portion" and/or "a portion" should be interpreted as encompassing
both embodiments including only a portion of such element and
embodiments including the entirety of such element unless
specifically stated to the contrary.
[0038] The disclosed embodiments may, in some cases, be implemented
in hardware, firmware, software, or a combination thereof. The
disclosed embodiments may also be implemented as instructions
carried by or stored on one or more transitory or non-transitory
machine-readable (e.g., computer-readable) storage media, which may
be read and executed by one or more processors. A machine-readable
storage medium may be embodied as any storage device, mechanism, or
other physical structure for storing or transmitting information in
a form readable by a machine (e.g., a volatile or non-volatile
memory, a media disc, or other media device).
[0039] In the drawings, some structural or method features may be
shown in specific arrangements and/or orderings. However, it should
be appreciated that such specific arrangements and/or orderings may
not be required. Rather, in some embodiments, such features may be
arranged in a different manner and/or order than shown in the
illustrative figures unless indicated to the contrary.
Additionally, the inclusion of a structural or method feature in a
particular figure is not meant to imply that such feature is
required in all embodiments and, in some embodiments, may not be
included or may be combined with other features.
[0040] Referring now to FIG. 1, in the illustrative embodiment, a
system 100 for door fault identification includes a door device
102, a server 104, a mobile device 106, and an interface device
108. As described in greater detail below, the system 100 leverages
the sensor data collected from various sensors of the door device
102 to detect abnormalities in the behavior of a door to which the
door device 102 is secured and identify the corresponding fault(s)
(e.g., root cause) of the abnormalities. In some embodiments, the
historical logging of the sensor data and/or the subsequent
analysis of that data (e.g., data derived from the filtering,
synthesis, and/or other analysis of the sensor data) may allow for
improved detection of door faults that arise over time.
[0041] It should be appreciated that the system 100 may provide
notice to the maintenance technician before a detected door fault
causes a door failure and/or identify the particular time at which
a fault occurred, which may help the technician schedule repairs
and better target the estimated replacement date. Additionally, the
system 100 may identify and notify the technician regarding the
most likely door faults based on the analysis of the sensor data,
which informs the technician regarding the proper tools and parts
to bring to the door site for repairs. Further, the system 100 may
provide feedback to the installer of a door device 102 (e.g., a
door closer) indicating whether the device was installed according
to the desired parameters of operation. The techniques described
herein may improve the troubleshooting ability of new or less
experienced technicians, for example, by providing a list of likely
faults and thereby ensuring they don't attempt to "repair" an
entirely unrelated aspect of the door operation.
[0042] The system 100 may also involve an evaluation of the
historical behavior of the door's operation and/or an analysis of
the maintenance performed, for example, in order to improve the
ability of the system 100 to accurately identify the most likely
door faults based on the presented sensor data. For example, in
some embodiments, the system 100 may dynamically update a fault
prediction database/library based on the recommended or identified
likely faults, the maintenance performed by the technician, and the
resulting operation of the door. In other words, the
pre-maintenance (pre-solution) and post-maintenance (post-solution)
sensor data and the actual maintenance performed may be leveraged
to update the fault prediction determination. Specifically, in some
embodiments, the system 100 may utilize an artificial neural
network and/or other machine learning algorithm for fault
prediction and update the various weights accordingly.
[0043] It should be appreciated that each of the door device 102,
the server 104, the mobile device 106, and the interface device 108
may be embodied as any type of device or collection of devices
suitable for performing the functions described herein. More
specifically, in the illustrative embodiment, the door device 102
may be embodied as an access control device or other device coupled
to a door. For example, in various embodiments, the door device 102
may be embodied as an electronic lock (e.g., a mortise lock, a
cylindrical lock, or a tubular lock), a door closer, a door
operator, an auto-operator, a door-mounted credential reader, an
exit device, a panic bar, a door-mounted camera system, and/or
another suitable device coupled to, secured to, mounted to,
embedded within, and/or integrally formed with a door. In the
illustrative embodiment, the server 104 is configured to
communicate with the door device 102 over a wired or wireless
communication connection to exchange various data (e.g., raw sensor
data, filtered/synthesized data, analyzed data, fault data, fault
prediction database data, behavior data, probabilistic data,
historical data, and/or other relevant data) depending on the
particular embodiment. Similarly, the mobile device 106 may be
configured to communicate with the door device 102 and/or the
server 104 to exchange data. For example, in some embodiments, the
maintenance technician may receive fault notifications or
fault-related information from the door device 102 and/or the
server 104. In the illustrative embodiment, the interface device
108 is communicatively coupled to the server 104 to permit a user
to access the data stored thereon (e.g., such that a user may
receive, view, and/or exchange data with the server 104). Further,
in some embodiments, the system 100 may include a gateway device
communicatively coupled to the door device 102 such that other
devices of the system 100 (e.g., the server 104 and/or the mobile
device 106) may communicate with the door device 102 via the
gateway device.
[0044] In some embodiments, the door device 102 may communicate
with the server 104 and/or the mobile device 106 over any suitable
wireless communication connection (e.g., Bluetooth, Wi-Fi, etc.)
established between the door device 102 and the device 104, 106.
Additionally, in the illustrative embodiment, the mobile device 106
may communicate with the server 104 using any suitable wireless
communication connection. For example, in various embodiments, the
mobile device 106 may communication with the server 104 over Wi-Fi,
WiMAX, a WAN (e.g., the Internet), and/or a suitable
telecommunications network/protocol. As such, it should be
appreciated that the illustrative server 104 may be located at one
or more remote locations relative to the devices 102, 106. In other
embodiments, it should be appreciated that one or more of the
communication connections may be wired. The interface device 108
may be embodied as any device local or remote to the server 104
and, therefore, may be configured to communicate with the server
104 over any suitable communication connection. For example, in
some embodiments, the interface device 108 may be embodied as
another mobile device, whereas in other embodiments, the interface
device 108 may be embodied as a peripheral device coupled to the
server 104.
[0045] It should be appreciated that each of the door device 102,
the server 104, the mobile device 106, and/or the interface device
108 may be embodied as a computing device similar to the computing
device 200 described below in reference to FIG. 2. For example, in
the illustrative embodiment, each of the door device 102, the
server 104, and the mobile device 106 includes a processing device
202 and a memory 206 having stored thereon operating logic 208 for
execution by the processing device 202 for operation of the
corresponding device. Additionally, in some embodiments, the
interface device 108 may also include a processing device 202,
memory 206, and operating logic 208. Further, in some embodiments,
it should be appreciated that the door device 102 may include an
environment (e.g., a hardware environment) similar to the
environment 300 as described below in reference to FIG. 3.
[0046] It should be further appreciated that, although the server
104 is described herein as one or more computing devices outside of
a cloud computing environment, in other embodiments, the server 104
may be embodied as a cloud-based device or collection of devices.
Further, in cloud-based embodiments, the server 104 may be embodied
as a "serverless" or server-ambiguous computing solution, for
example, that executes a plurality of instructions on-demand,
contains logic to execute instructions only when prompted by a
particular activity/trigger, and does not consume computing
resources when not in use. That is, the server 104 may be embodied
as a virtual computing environment residing "on" a computing system
(e.g., a distributed network of devices) in which various virtual
functions (e.g., Lamba functions, Azure functions, Google cloud
functions, and/or other suitable virtual functions) may be executed
corresponding with the functions of the server 104 described
herein. For example, when an event occurs (e.g., data is
transferred to the server 104 for analysis), the virtual computing
environment may be communicated with (e.g., via a request to an API
of the virtual computing environment), whereby the API may route
the request to the correct virtual function (e.g., a particular
server-ambiguous computing resource) based on a set of rules. As
such, when a request for data analysis or application of machine
learning is made, the appropriate virtual function(s) may be
executed to perform the appropriate analysis and transmit the
information back to the door device 102 and/or to storage before
eliminating the instance of the virtual function(s).
[0047] Although only one door device 102, one server 104, one
mobile device 106, and one interface device 108 are shown in the
illustrative embodiment of FIG. 1, the system 100 may include
multiple door devices 102, servers 104, mobile devices 106, and/or
one interface devices 108 in other embodiments. For example, as
indicated above, the server 104 may be embodied as multiple servers
in a cloud computing environment in some embodiments. Further, in
some embodiments, maintenance technicians may use different mobile
devices 106 to communicate with the door device 102 and/or the
server 104.
[0048] Referring now to FIG. 2, a simplified block diagram of at
least one embodiment of a computing device 200 is shown. The
illustrative computing device 200 depicts at least one embodiment
of a door device, server, mobile device, and/or interface device
that may be utilized in connection with the door device 102, the
server 104, the mobile device 106, and/or the interface device 108
illustrated in FIG. 1. Depending on the particular embodiment,
computing device 200 may be embodied as a reader device, credential
device, access control device, door closer (e.g., closer, operator,
or auto-operator), server, desktop computer, laptop computer,
tablet computer, notebook, netbook, Ultrabook.TM., mobile computing
device, cellular phone, smartphone, wearable computing device,
personal digital assistant, Internet of Things (IoT) device, camera
device, control panel, processing system, router, gateway, and/or
any other computing, processing, and/or communication device
capable of performing the functions described herein.
[0049] The computing device 200 includes a processing device 202
that executes algorithms and/or processes data in accordance with
operating logic 208, an input/output device 204 that enables
communication between the computing device 200 and one or more
external devices 210, and memory 206 which stores, for example,
data received from the external device 210 via the input/output
device 204.
[0050] The input/output device 204 allows the computing device 200
to communicate with the external device 210. For example, the
input/output device 204 may include a transceiver, a network
adapter, a network card, an interface, one or more communication
ports (e.g., a USB port, serial port, parallel port, an analog
port, a digital port, VGA, DVI, HDMI, FireWire, CAT 5, or any other
type of communication port or interface), and/or other
communication circuitry. Communication circuitry of the computing
device 200 may be configured to use any one or more communication
technologies (e.g., wireless or wired communications) and
associated protocols (e.g., Ethernet, Bluetooth.RTM., Wi-Fi.RTM.,
WiMAX, etc.) to effect such communication depending on the
particular computing device 200. The input/output device 204 may
include hardware, software, and/or firmware suitable for performing
the techniques described herein.
[0051] The external device 210 may be any type of device that
allows data to be inputted or outputted from the computing device
200. For example, in various embodiments, the external device 210
may be embodied as the door device 102, the server 104, the mobile
device 106, and/or the interface device 108. Further, in some
embodiments, the external device 210 may be embodied as another
computing device, switch, diagnostic tool, controller, printer,
display, alarm, peripheral device (e.g., keyboard, mouse, touch
screen display, etc.), and/or any other computing, processing,
and/or communication device capable of performing the functions
described herein. Furthermore, in some embodiments, it should be
appreciated that the external device 210 may be integrated into the
computing device 200.
[0052] The processing device 202 may be embodied as any type of
processor(s) capable of performing the functions described herein.
In particular, the processing device 202 may be embodied as one or
more single or multi-core processors, microcontrollers, or other
processor or processing/controlling circuits. For example, in some
embodiments, the processing device 202 may include or be embodied
as an arithmetic logic unit (ALU), central processing unit (CPU),
digital signal processor (DSP), and/or another suitable
processor(s). The processing device 202 may be a programmable type,
a dedicated hardwired state machine, or a combination thereof.
Processing devices 202 with multiple processing units may utilize
distributed, pipelined, and/or parallel processing in various
embodiments. Further, the processing device 202 may be dedicated to
performance of just the operations described herein, or may be
utilized in one or more additional applications. In the
illustrative embodiment, the processing device 202 is programmable
and executes algorithms and/or processes data in accordance with
operating logic 208 as defined by programming instructions (such as
software or firmware) stored in memory 206. Additionally or
alternatively, the operating logic 208 for processing device 202
may be at least partially defined by hardwired logic or other
hardware. Further, the processing device 202 may include one or
more components of any type suitable to process the signals
received from input/output device 204 or from other components or
devices and to provide desired output signals. Such components may
include digital circuitry, analog circuitry, or a combination
thereof.
[0053] The memory 206 may be of one or more types of non-transitory
computer-readable media, such as a solid-state memory,
electromagnetic memory, optical memory, or a combination thereof.
Furthermore, the memory 206 may be volatile and/or nonvolatile and,
in some embodiments, some or all of the memory 206 may be of a
portable type, such as a disk, tape, memory stick, cartridge,
and/or other suitable portable memory. In operation, the memory 206
may store various data and software used during operation of the
computing device 200 such as operating systems, applications,
programs, libraries, and drivers. It should be appreciated that the
memory 206 may store data that is manipulated by the operating
logic 208 of processing device 202, such as, for example, data
representative of signals received from and/or sent to the
input/output device 204 in addition to or in lieu of storing
programming instructions defining operating logic 208. As shown in
FIG. 2, the memory 206 may be included with the processing device
202 and/or coupled to the processing device 202 depending on the
particular embodiment. For example, in some embodiments, the
processing device 202, the memory 206, and/or other components of
the computing device 200 may form a portion of a system-on-a-chip
(SoC) and be incorporated on a single integrated circuit chip.
[0054] In some embodiments, various components of the computing
device 200 (e.g., the processing device 202 and the memory 206) may
be communicatively coupled via an input/output subsystem, which may
be embodied as circuitry and/or components to facilitate
input/output operations with the processing device 202, the memory
206, and other components of the computing device 200. For example,
the input/output subsystem may be embodied as, or otherwise
include, memory controller hubs, input/output control hubs,
firmware devices, communication links (i.e., point-to-point links,
bus links, wires, cables, light guides, printed circuit board
traces, etc.) and/or other components and subsystems to facilitate
the input/output operations.
[0055] The computing device 200 may include other or additional
components, such as those commonly found in a typical computing
device (e.g., various input/output devices and/or other
components), in other embodiments. It should be further appreciated
that one or more of the components of the computing device 200
described herein may be distributed across multiple computing
devices. In other words, the techniques described herein may be
employed by a computing system that includes one or more computing
devices. Additionally, although only a single processing device
202, I/O device 204, and memory 206 are illustratively shown in
FIG. 2, it should be appreciated that a particular computing device
200 may include multiple processing devices 202, I/O devices 204,
and/or memories 206 in other embodiments. Further, in some
embodiments, more than one external device 210 may be in
communication with the computing device 200.
[0056] Referring now to FIG. 3, a simplified block diagram of at
least one embodiment of an environment 300 of the door device 102
is shown. The illustrative environment 300 includes a processor
302, an input/output ("I/O") subsystem 304, a memory 306, inertial
sensors 308, environmental sensors 310, a real-time clock 312, one
or more indicators 314, and communication circuitry 316. It should
be appreciated that one or more of the components of the
environment 300 described herein may be embodied as, or form a
portion of, one or more embedded controllers and/or integrated
circuits of the door device 102. For example, in some embodiments,
the processor 302, the I/O subsystem 304, the memory 306 and/or
other components of the door device 102 may be embodied as, or form
a portion of, a microcontroller or SoC. Further, depending on the
particular embodiment, the components of the environment 300 may be
closely positioned to one another or distributed throughout the
door device 102 (i.e., separated from one another). In some
embodiments, one or more of the components of the environment 300
(e.g., a sensor 308, 310) may be located external to a housing
(e.g., a primary housing) of the door device 102.
[0057] The processor 302 may be embodied as any type of
processor(s) capable of performing the functions described herein.
In particular, the processor 302 may be embodied as one or more
single or multi-core processors, microcontrollers, or other
processor or processing/controlling circuits. For example, in some
embodiments, the processor 302 may include or be embodied as an
arithmetic logic unit (ALU), central processing unit (CPU), digital
signal processor (DSP), and/or another suitable processor(s). The
processor 302 may be a programmable type, a dedicated hardwired
state machine, or a combination thereof. Processors 302 with
multiple processing units may utilize distributed, pipelined,
and/or parallel processing in various embodiments. Further, the
processor 302 may be dedicated to performance of just the
operations described herein, or may be utilized in one or more
additional applications. In the illustrative embodiment, the
processor 302 is of a programmable variety that executes algorithms
and/or processes data in accordance with operating logic as defined
by programming instructions (such as software or firmware) stored
in the memory 306. Additionally or alternatively, the operating
logic for the processor 302 may be at least partially defined by
hardwired logic or other hardware. Further, the processor 302 may
include one or more components of any type suitable to process the
signals received from input/output devices or from other components
or devices and to provide desired output signals. Such components
may include digital circuitry, analog circuitry, or a combination
thereof.
[0058] The memory 306 may be of one or more types of non-transitory
computer-readable media, such as a solid-state memory,
electromagnetic memory, optical memory, or a combination thereof.
Furthermore, the memory 306 may be volatile and/or nonvolatile and,
in some embodiments, some or all of the memory 306 may be of a
portable variety, such as a disk, tape, memory stick, cartridge,
and/or other suitable portable memory. In operation, the memory 306
may store various data and software used during operation of door
device 102 such as operating systems (e.g., real-time operating
systems (RTOS)), applications, programs, libraries, and drivers.
The memory 306 is communicatively coupled to the processor 302 via
the I/O subsystem 304, which may be embodied as circuitry and/or
components to facilitate input/output operations with the processor
302, the memory 306, and other components of the door device 102.
For example, the I/O subsystem 304 may be embodied as, or otherwise
include, memory controller hubs, input/output control hubs,
firmware devices, communication links (i.e., point-to-point links,
bus links, wires, cables, light guides, printed circuit board
traces, etc.) and/or other components and subsystems to facilitate
the input/output operations. Depending on the particular
embodiment, the memory 306 may be included with the processor 302
and/or coupled to the processor 302 depending on the particular
embodiment. For example, in some embodiments, the processor 302,
the I/O subsystem 304, the memory 306, and/or other components of
the environment 300 may form a portion of a system-on-a-chip (SoC)
and be incorporated on a single integrated circuit chip.
[0059] The inertial sensors 308 are configured to generate sensor
data (e.g., by virtue of one or more signals), which may be
interpreted by the processor 302 to determine one or more inertial
characteristics of the door device 102. For example, in some
embodiments, the inertial sensors 308 may include one or more
accelerometers 318 (e.g., 2-axis or 3-axis accelerometers), one or
more magnetometers 320 (e.g., 1-axis, 2-axis, or 3-axis
magnetometers), and/or one or more gyrometers 322 (e.g., 1-axis,
2-axis, or 3-axis gyrometers). In other embodiments, the inertial
sensors 308 may include additional or alternative sensors to
determine the same and/or other inertial characteristics of the
door device 102.
[0060] As shown in reference to FIG. 4, the door device 102 is
depicted as an electronic lock secured to a door 400. Further, the
illustrative door device 102 includes one or more accelerometers
318 sensing, individually or collectively, acceleration of the door
device 102 along at least three different (e.g., orthogonal) axes
and one or more gyrometers 322 sensing, individually or
collectively, orientation of the door device 102 about at least
three different (e.g., orthogonal) axes. That is, the gyrometers
322 sense the roll, pitch, and yaw of the door device 102. In
particular, the illustrative one or more accelerometers 318 include
the A.sub.x, A.sub.y, and A.sub.z axes and the illustrative one or
more gyrometers 322 sense the orientation G.sub.x of the door
device 102 about the A.sub.x axis, the orientation G.sub.y of the
door device 102 about the A.sub.y axis, and the orientation G.sub.z
of the door device 102 about the A.sub.z axis. It should be further
appreciated that the gyrometer data may be indicative of the
angular velocity of the door device 102. As described in greater
detail below, the sensor data (e.g., acceleration data and
gyrometer data) generated by the sensors may be analyzed throughout
the range of motion of the door 400 between the open position 402
and the closed position 404. Although the open position 402 is
depicted as a fully open position at ninety degrees and the closed
position 404 is depicted as a fully closed position at zero
degrees, it should be appreciated that, in the illustrative
embodiment, the sensor data may be analyzed based on the techniques
described herein regardless of whether the door 400 is fully opened
or fully closed. Indeed, in some embodiments, the problem exhibited
by the door 400 may be, for example, a failure to fully close.
Further, in some embodiments, the fully open position may be
greater or less than ninety degrees.
[0061] The environmental sensors 310 are configured to generate
sensor data (e.g., by virtue of one or more signals), which may be
interpreted by the processor 302 to determine one or more
corresponding internal or external environmental characteristics of
the door device 102. For example, in some embodiments, the
environmental sensors 310 may include one or more air pressure
sensors 324 configured to determine the air pressure in the
external physical environment of the door device 102. In such
embodiments, the pressure sensors 324 may be embodied, for example,
as single or differential pressure sensors. Further, in some
embodiments, the environmental sensors 310 may include one or more
temperature sensors 326 configured to determine one or more
internal temperatures of the door device 102 and/or the temperature
of the external physical environment of the door device 102. In
such embodiments, the temperature sensors 326 may be embodied as
infrared or direct measurements sensors. In some embodiments, one
or more of the temperature sensors 326 may be embodied as a
temperature dependent resistor. Additionally, in some embodiments,
the environmental sensors 310 may include one or more humidity
sensors 328 (e.g., hydrometers) configured to determine a humidity
of the physical environment of the door device 102 and/or one or
more light sensors 330 configured to sense an amount of light in
the physical environment of the door device 102. In such
embodiments, one or more of the light sensors 330 may be embodied
as, or otherwise include, a photo-diode or other suitable
light-sensing mechanism. In other embodiments, the environmental
sensors 310 may include additional or alternative sensors to
determine other environmental characteristics of the door device
102.
[0062] It should be appreciated that, in some embodiments,
additional and/or alternative sensors other than those described
above may be included in the environment 300. For example, in
various embodiments, the sensors may be embodied as, or otherwise
include, proximity sensors, optical sensors, light sensors,
electromagnetic sensors, hall effect sensors, audio sensors (e.g.,
microphones), temperature sensors, motion sensor, piezoelectric
sensors, cameras, and/or other types of sensors. Of course, the
environment 300 may also include components and/or devices
configured to facilitate the use of the sensors. By way of example,
the sensors may detect various characteristics of the physical
environment of the door device 102 (internal and/or external to the
door device 102), electrical characteristics of the door device
102, electromagnetic characteristics of the door device 102 or its
surroundings, and/or other suitable characteristics. Data from the
sensors may be used by the door device 102 or, more particularly,
the processor 302 to determine whether the door is operating
properly/normally and, if not, identify the door fault(s) most
likely to be the root cause of the improper operation. In other
embodiments, as described herein, the door device 102 may transmit
the sensor data or a calibrated, filtered, synthesized, and/or
otherwise processed version thereof to the server 104 for
identification of the door fault(s). It should be further
appreciated that, in some embodiments, one or more of the sensors
of the door device 102 may be embodied as a microelectromechanical
systems (MEMS) device.
[0063] The real-time clock 312 is configured to track the amount of
time associated with various conditions of the door device 102. For
example, as described herein, the real-time clock 312 may be used
to determine the amount of time that lapsed throughout various
stages of the opening/closing of the door. That is, the real-time
clock 312 may be used to track the amount of time the door was
within one or more door zones. Although the real-time clock 312 is
shown as a discrete component in FIG. 3, it should be appreciated
that the real-time clock 312 may form a portion of another
component of the door device 102 in other embodiments. For example,
in some embodiments, the processor 302 may include the real-time
clock 312. It should be appreciated that, in some embodiments, the
real-time clock 312 may be a software-or firmware-implemented
timer. Further, in other embodiments, the real-time clock 312 may
be embodied as any type of timer or counter suitable for performing
the functions described herein.
[0064] The one or more indicators 314 may be embodied as any one or
more devices or components configured to display a message to a
user of the door device 102. For example, in some embodiments, the
indicator(s) 314 may indicate to the user whether the door is
operating properly. Depending on the particular embodiment, the
indicator(s) 314 may be embodied, or otherwise include, an e-ink
display, LEDs, light pipes, LCDs, and/or other suitable visual
indicator(s). In some embodiments, the indicator(s) 314 may be
embodied as a mechanically-driven display system that includes two
or more messages.
[0065] The communication circuitry 316 may be embodied as any
communication circuitry, transceiver, device, or collection
thereof, capable of enabling communications between the door device
102 and other remote devices (e.g., the server 104, the mobile
device 106, and/or other remote devices). The communication
circuitry 316 may be configured to use any one or more wired and/or
wireless communication technologies and associated protocols. For
example, in some embodiments, the illustrative door device 102 may
be configured to communicate via Wi-Fi (e.g., infrastructure or ad
hoc mode), Wi-Fi Direct, Bluetooth (including Bluetooth Low Energy
(BLE)), Zigbee, Near Field Communication (NFC), IEEE 902.15, and/or
other suitable wireless communication protocol(s). Further, in some
embodiments, the door device 102 may be configured to communicate
via Ethernet, serial communication links, and/or another suitable
wired communication mechanism.
[0066] It should be appreciated that the environment 300 may
include additional or alternative components, such as those
commonly found in a door device, in other embodiments. Further, in
some embodiments, one or more of the components of the environment
300 described herein may be omitted from the environment 300 of a
particular door device 102.
[0067] Referring now to FIG. 5, in use, the system 100 may execute
a method 500 for door fault identification. As described above,
depending on the particular embodiment, each of the blocks of the
method 500 may be executed by the door device 102 and/or the server
104. However, for brevity of the description, the method 500 is
described herein as being primarily executed by the door device
102. It should be appreciated that the particular blocks of the
method 500 are illustrated by way of example, and such blocks may
be combined or divided, added or removed, and/or reordered in whole
or in part depending on the particular embodiment, unless stated to
the contrary. The illustrative method 500 begins with block 502 in
which the door device 102 monitors for external forces acting on
the door. If a force is detected in block 504, the door device 102
wakes the sensors (e.g., the sensors 308, 310) of the door device
102 from a sleep state or low power state in block 506. For
example, in some embodiments, one or more of the sensors of the
door device 102 (e.g., an accelerometer) may be powered and
configured to sense door movement, and in response to detection of
the force, the other sensors of the door device 102 may be powered
or changed from the low power state to a higher power state (e.g.,
via a command from the processor 302). In some embodiments, the
processor 302 may transmit a wake-up signal to the sensors and/or
other components of the door device 102 to transition the
sensors/components to a powered (or more fully powered) state. In
other embodiments, it should be appreciated that the door device
102 and/or one or more of the sensors may remain in a fully powered
state such that it unnecessary to wake the device/sensors.
[0068] In block 508, the door device 102 records the sensor data
generated by the sensors (e.g., the sensors 308, 310). For example,
in some embodiments, the sensor data may be stored in the memory
306 of the door device 102 for subsequent analysis. In block 510,
the door device 102 may perform filtering and/or calibration of the
sensor data. For example, in some embodiments, the door device 102
may perform basic filtering (e.g., to "smooth" out the data) and
calibrate the data values in preparation for the analysis described
herein. Depending on the particular embodiment, the door device 102
may filter and/or calibrate the sensor data in real-time or after
the data collection has concluded (e.g., depending on the
particular hardware architecture of the environment 300).
[0069] In block 512, the door device 102 determines whether the
door has stopped moving (e.g., for at least a predetermined
threshold period of time). If not, the method 500 returns to block
508 in which the door device 102 continues to record the sensor
data. In other words, in the illustrative embodiment, the door
device 102 records the sensor data throughout the relevant range of
motion of the door. As described below, a door fault may cause the
door may be stopped without going through the full range of
anticipated motion (e.g., before closing). As such, it should be
appreciated that the range of motion of the door may vary depending
on the particular door, any existing door faults, and/or other
operational considerations.
[0070] As described herein, in some embodiments, the door device
102 may filter, calibrate, and analyze the sensor data. However, in
other embodiments, the server 104 may perform one or more of those
functions. Accordingly, it should be appreciated that the door
device 102 may transmit the raw sensor data, the filtered sensor
data, the calibrated sensor data, the filtered and calibrated
sensor data, and/or other analyzed/processed versions thereof to
the server 104 for further analysis.
[0071] If the door device 102 determines that the door has stopped
moving (e.g., for at least a predetermined threshold period of
time), the method 500 advances to block 514 in which the door
device 102 and/or the server 104 analyzes the sensor data to
determine one or more inertial measurements of the door's behavior.
To do so, the door device 102 and/or the server 104 may execute the
method 600 of FIG. 6 described below. In block 516, the door device
102 and/or the server 104 determines an environmental context of
the door device 102 based on the sensor data generated by the
environmental sensors 310 or data derived therefrom. For example,
in some embodiments, the environmental context of the door device
102 may describe or indicate the internal and/or external air
pressures, temperatures, humidity, and/or light experienced by the
door device 102. Further, in some embodiments, the environmental
context may identify any abrupt changes in an environmental
parameters or characteristic.
[0072] In some embodiments, the analysis of the sensor data (e.g.,
from the sensors 308, 310) may include applying various filters
(e.g., per-channel averaging filters, multiple-channel filtering,
and/or other suitable filters), performing various data synthesis
(e.g., multiple sensor synthesis), performing cross-correlation
analysis, and/or otherwise analyzing the sensor data or data
derived therefrom. For example, in some embodiments, the inertial
sensors 308 may include a 6-axis or 9-axis inertial measurement
unit (IMU) that allows for multiple sensor data streams to be
analyzed, averaging out the errors, and synthesizing the data into
a single, higher quality signal indicative of the corresponding
inertial measurement(s) of the door device 102. In some
embodiments, multiple sensors may be "combined" by leveraging
linear (or non-linear) quadratic estimation techniques, such as a
Kalman filter, or employing similar techniques, which may allow
noise and drift in the data to be eliminated or reduced.
[0073] In block 518, the door device 102 and/or the server 104
determines behavior data indicative of the behavior of the door
device 102 based on the sensor data and/or data derived therefrom.
It should be appreciated that the behavior data may vary depending
on the particular embodiment. For example, in various embodiments,
the behavior data may be indicative of one or more accelerations of
the door (e.g., a maximum acceleration, a minimum acceleration, an
average acceleration, a standard deviation of acceleration, maximum
acceleration within the latch region, etc.), a peak velocity of the
door during a closing phase of the door, a peak opening angle of
the door, a duration of movement of the door from the closed
position to the maximum open position, a duration of movement of
the door from the maximum open position to the closed position, a
duration of movement of the door from the peak opening angle to a
latch zone of the door, or a duration of movement of the door from
the latch zone to a closed position of the door, a temperature
(e.g., at the start, middle, and/or end of the open/close phase), a
humidity (e.g., at the start, middle, and/or end of the open/close
phase), an air pressure (e.g., at the start, middle, and/or end of
the open/close phase), and/or a light intensity (e.g., at the
start, middle, and/or end of the open/close phase). However, it
should be appreciated that the behavior data may include data
indicative of other characteristics of the door device 102 and/or
its physical environment.
[0074] Additionally, in block 518, the door device 102 and/or the
server 104 may determine the likelihood of various faults (e.g.,
identified in a fault prediction database) based on the sensor data
and/or data derived therefrom and fault data indicative of one or
more possible door faults. For example, the analyzed sensor data
(e.g., the behavior data) may be compared to representative fault
data (e.g., one or more historical signals) corresponding with
faults stored in a fault prediction database. Based on the
comparison, the door device 102 and/or the server 104 may determine
the likelihood that the analyzed sensor data (e.g., the behavior
data) corresponds with one or more (e.g., each) of the faults in
the fault prediction database. More specifically, in some
embodiments, the comparison and/or other analysis may yield a
percentage likelihood/probability that the sensor data corresponds
with the representative fault data and, therefore, with the fault.
It should be appreciated that the representative fault data may be
pre-stored on the door device 102 and/or the server 104 depending
on the particular embodiment. In some embodiments, the
representative fault data (e.g., historical signals) may be
identified in a laboratory environment and/or created/modified over
time. In some embodiments, the door device 102 and/or the server
104 may execute the method 700 of FIG. 7 in determining the
likelihood of various faults as described below.
[0075] In block 520, the door device 102 and/or the server 104 may
store and/or transmit the various data described above. In some
embodiments, the likelihoods may be communicated from the door
device 102 or server 104 to a maintenance department (e.g., to the
interface device 108), via a wired and/or wireless communication
connection, via audible codes or indicators (e.g., the indicator(s)
314), and/or through another suitable mechanism. In some
embodiments, the sensor data, analyzed data, and/or determined
likelihoods may be transmitted according to a predetermined
schedule (e.g., periodically).
[0076] In some embodiments, in block 522, the door device 102
and/or the server 104 may evaluate the historical behavior of the
door. For example, as described herein, the door device 102 and/or
the server 104 may analyze the maintenance performed (e.g.,
identified based on user input) in order to improve the ability to
accurately identify the most likely door faults based on the
instant sensor data. To do so, in some embodiments, the door device
102 and/or the server 104 may execute the method 2000 of FIGS.
20-21. Further, in some embodiments, the historical door behavior
may be analyzed to determine whether there are any trends and, if
so, the maintenance technician may be notified.
[0077] Although the blocks 502-522 are described in a relatively
serial manner, it should be appreciated that various blocks of the
method 500 may be performed in parallel in some embodiments.
[0078] Referring now to FIG. 6, in use, the system 100 may execute
a method 600 for analyzing sensor data to determine inertial
measurements of the door's behavior. As described above, depending
on the particular embodiment, each of the blocks of the method 600
may be executed by the door device 102 and/or the server 104.
However, for brevity of the description, the method 600 is
described herein as being primarily executed by the door device
102. It should be appreciated that the particular blocks of the
method 600 are illustrated by way of example, and such blocks may
be combined or divided, added or removed, and/or reordered in whole
or in part depending on the particular embodiment, unless stated to
the contrary.
[0079] The illustrative method 600 begins with block 602 in which
the door device 102 receives the sensor data from the one or more
accelerometers 318, the one or more magnetometers 320, and the one
or more gyrometers 332. As described above, the sensor data is
further filtered, synthesized, and/or otherwise analyzed. For
example, in the illustrative embodiment, the door device 102
analyzes the accelerometer data generated by the accelerometer(s)
318 to detect any high-acceleration events (e.g., from someone or
something abusing the door, impacts to the door, the door hitting
the frame or latch, etc.), high-vibration events (e.g., from the
door rubbing against the frame or ground), and/or other abnormal
acceleration. Further, in block 606, the door device 102 analyzes
the gyrometer data generated by the gyrometer(s) 332 to detect any
high-velocity spikes (e.g., correlating with any detected
acceleration spikes) and/or other abnormal velocity. In other
embodiments, it should be appreciated that the sensor data may be
further analyzed to detect one or more other characteristics of the
corresponding signals.
[0080] In block 608, the door device 102 filters the sensor data to
"smooth" the data without degrading the data to the extent that the
signal characteristics described herein are unidentifiable. For
example, in some embodiments, the sensor data (e.g., the data from
the sensors 308, 310) may pass through a finite impulse response
(FIR) filter, an infinite impulse response (IIR) filter, an
averaging or Gaussian filter (e.g., a running average filter),
and/or other suitable filter(s). In block 610, the door device 102
determines the door velocity based on the filtered gyrometer data.
Further, in block 612, the door device 102 determines one or more
inertial measurements of the door's behavior based on the filtered
sensor data. For example, in some embodiments, the sensor data may
be "combined" to create one or more inertial measurement values
that serve as a high accuracy representation of the door's actual
inertial behavior.
[0081] Although the blocks 602-612 are described in a relatively
serial manner, it should be appreciated that various blocks of the
method 600 may be performed in parallel in some embodiments.
[0082] Referring now to FIG. 7, in use, the system 100 may execute
a method 700 for determining the likelihoods of various door
faults. As described above, depending on the particular embodiment,
each of the blocks of the method 700 may be executed by the door
device 102 and/or the server 104. However, for brevity of the
description, the method 700 is described herein as being primarily
executed by the door device 102. It should be appreciated that the
particular blocks of the method 700 are illustrated by way of
example, and such blocks may be combined or divided, added or
removed, and/or reordered in whole or in part depending on the
particular embodiment, unless stated to the contrary.
[0083] The illustrative method 700 begins with block 702 in which
the door device 102 receives the sensor data (e.g., raw data) from
the sensors (e.g., the sensors 308, 310). In block 704, the door
device 102 pre-processes the sensor data to generate "sanitized" or
"calibrated" sensor data that is meaningful. For example, in some
embodiments, the sensor data is indicative of the door angle, door
speed, orientation (gyrometer), air pressure, temperature, and/or
other contextual information and may be expressed in raw units of
measure (e.g., ohms, volts, etc.). Further, in some embodiments,
the sanitized data may be indicative of similar features and may be
expressed in engineering units (e.g., degrees, meters per second,
etc.), filtered, synthesized, and/or otherwise processed.
[0084] In block 706, the pre-processed data may be segmented into a
plurality of operating regions associated with the predefined door
zones. For example, in some embodiments, the door device 102 may
segment the data into door zones similar to those depicted in FIG.
9. It should be appreciated that FIG. 9 illustrates a door angle
signal 900 (e.g., determined from a potentiometer or an analysis of
other sensor data) indicative of an angle of the door relative to
the closed position and ten predefined door zones 902-920.
Specifically, the illustrative door zones include an initial
opening zone 902 (e.g., 0-1 degrees), a latch zone during opening
904 (e.g., 1-15 degrees), a main zone during opening 906 (e.g.,
15-70 degrees), a backcheck zone 908 (e.g., 70+degrees), a
hold-open zone 910 (e.g., door not moving but not in the frame), a
main zone during closing 912 (e.g., max angle to 15 degrees), a
latch zone during closing 914 (e.g., 15-3 degrees), a frame zone
during closing 916 (e.g., 3-1degrees), a closed position 918 (e.g.,
1-0 degrees), and a resting position 920 (e.g., 0 degrees).
However, it should be appreciated that the door device 102 may
segment the data into a different number of and/or otherwise
characterized operating regions in other embodiments.
[0085] In block 708, the door device 102 selects one of the
operating regions (e.g. door zones). Further, the door device 102
selects a feature (e.g., maximum velocity of the door during close)
in block 708 and generates a feature detection score based on the
selected feature in block 710. In particular, in block 714, the
door device 102 may perform feature detection on the data in the
selected operating region based on the selected feature. In some
embodiments, it should be appreciated that the door device 102 may
utilize any suitable feature extraction, feature detection, and/or
score fusion algorithms, techniques, and/or mechanisms for
generating the feature detection score. It should be further
appreciated that each of the door faults may be associated with one
or more features in one or more of the operating regions.
[0086] In block 716, the door device 102 determines whether to
select another feature. In other words, in some embodiments, the
door device 102 determines whether there are any remaining features
for which a feature detection score has not yet been generated. If
so, the method 700 returns to block 710 in which the door device
102 selects another feature and generates the feature detection
score for that feature. Otherwise, the method 700 advances to block
718 in which the door device 102 generates an operating region
score based on the one or more feature detection scores generated
for the selected operating region (e.g., door zone). It should be
appreciated that the operating region score may be based on a score
fusion of the feature detection scores determined for that region.
In some embodiments, the operation region score may be indicative
of potential issues in the selected operating region (e.g., the
door closer is leaking in the main zone, the latch is not
completing in the latch zone, etc.).
[0087] In block 720, the door device 102 determines whether to
select another operating region. In other words, in some
embodiments, the door device 102 determines whether there are any
remaining operation regions (e.g., door zones) for which an
operating region score has not yet been generated. If so, the
method 700 returns to block 708 in which the door device 102
selects another operating region, determines the feature detection
scores for that operating region, and generates an operating region
score based on those feature detection scores as described above.
Otherwise, the method 700 advances to block 722 in which the door
device 102 generates one or more system scores based on the various
operating region scores. In the illustrative embodiment, the system
scores may identify the likelihoods of various door faults based on
the analyses described herein. Further, it should be appreciated
that, in some embodiments, the method 700 may be executed in
conjunction with an artificial neural network or other suitable
machine learning algorithm(s). In such embodiments, it should be
appreciated that the system scores may be embodied as the output
values of the neural network or machine learning. In some
embodiments, the system scores may only identify a predefined
number of the most likely faults identified.
[0088] Although the blocks 702-722 are described in a relatively
serial manner, it should be appreciated that various blocks of the
method 700 may be performed in parallel in some embodiments.
[0089] Referring now to FIG. 8, a graph 800 depicting the sensor
data expected for normal operation of the door according to at
least one embodiment. As shown, the sensor data depicted includes
the door angle 802, the acceleration 804 in the x-direction
(A.sub.x), the acceleration 806 in the y-direction (A.sub.y), and
the acceleration 808 in the z-direction (A.sub.z). It should be
appreciated that, in the illustrative embodiment, the acceleration
808 in the z-direction will typically include the least amount of
information, because the door should not move much (if any)
vertically during normal operation. As such, in some embodiments,
the acceleration 808 may be used to determine the noise of the
sensor(s), which may be used to calibrate the system for offset
and/or drift errors. Additionally, the acceleration 808 may be
leveraged to detect significant or extreme shock/vibration events
and vertical motion events (e.g., a door being lifted above a risen
threshold). Additionally, in the illustrative embodiment, the
acceleration 804 in the x-direction is the tangential force. Based
on the angular velocity (e.g., determined from the gyrometer(s)
322) and the tangential acceleration 808, the door device 102 can
estimate the positioning on the door. Additionally, in some
embodiments, the acceleration 808 may be utilized to verify one or
more gyrometer measurements. In the illustrative embodiment, the
acceleration 806 in the y-direction corresponds with motion on the
face of the door, or the physical acceleration of the door, which
may correlate to angular acceleration. As depicted in the graph
800, when the door begins its opening 810 phase during normal
operation, the door gets to its maximum acceleration 812 and then
its maximum speed 814. As the door approaches the fully open or
hold-open position, the door begins to slow down 816 until the peak
818 of the door movement is reached. As the door closes 820, the
sensor data typically does not reveal anything remarkable during
normal operation until the door contacts the frame and latch
822.
[0090] Referring now to FIGS. 10-14, various graphs depicting
sensor data associated with the operation of the door during
various door fault states are shown. As described herein, the door
device 102 may analyze the sensor data to determine the likelihood
of various door faults and inform the maintenance technician of
such likelihoods for more informed repair of the door device 102.
It should be appreciated that the graphs depicted in FIGS. 10-19
are included to illustrate the various principles described herein
and therefore the technologies described herein should not be
limited to the door faults described in reference to those
figures.
[0091] Referring to FIGS. 10-12, the graph 1000 of FIG. 10 depicts
the sensed accelerations (e.g., via the accelerometer(s) 318) of
the door device 102 in the x-direction, the y-direction, and the
z-direction. Additionally, the graph 1000 depicts the door angle,
which may be determined either directly or indirectly from the
sensor data depending on the particular embodiment. As shown, the
accelerometer data reveals significant multi-dimensional vibration
of the door device 102 during the middle part of the door closing
cycle. In some embodiments, such vibrations may indicate a
significant amount of noise (e.g., a loud audible groan) during the
closing cycle and may be a result of, for example, the door rubbing
against the bottom threshold. Similarly, the graph 1100 of FIG. 11
depicts the various sensed orientations (e.g., via the gyrometer(s)
322) of door device 102, which reveals a similar vibration. Based
on the analyzed sensor data using the techniques described herein,
the door device 102 may inform the technician that rubbing against
the bottom threshold has a high likelihood of being the root cause
(e.g., a probable door fault). Accordingly, the technician may
repair the threshold and reassess the operation via the sensor data
as shown in the graph 1200 of FIG. 12. As shown, the significant
vibration in the accelerations is gone, indicating that the repair
was generally successful. However, there remains some minor
vibration, which indicates that further analysis and fault
prediction may be advised.
[0092] Referring now to FIGS. 13-14, the graphs 1300, 1302, 1400,
1402 depict various sensor data associated with a closer backcheck
being set improperly. It should be appreciated that, when a door
closer backcheck is set improperly, the door may collide with the
backstop with a significant impact, which may cause wear to the
door hardware (e.g., the hinges) and the door itself. In some
embodiments, a symptom of such a condition may be an acceleration
impact at a high or maximum door angle indicating a collision. As
shown, the graphs 1300, 1400 depict the door angle, the graph 1302
depicts the three-dimensional accelerations sensed by the door
device 102, and the graph 1402 depicts the three-dimensional
orientations sensed by the door device 102. As described above, the
acceleration along the z-axis should remain constant due to
gravity, the acceleration along the x-axis is the tangential
acceleration, and the acceleration along the y-axis is the door
acceleration and deceleration. As shown, the graph 1302 depicts
normal operation until a multi-dimensional acceleration spike
occurs at the peak door angle. The door device 102 may analyze the
sensor data to determine that the acceleration signal amplitude
exceeds the expected signal value and thereby deduce that an object
likely stopped the motion of the door. Further, because the signal
spike has a relatively high-frequency, the door device 102 may
deduce that a rigid body caused the door to stop moving. As such,
considered collectively, the door device 102 may ascertain that the
door hit an object such as a door stop. In other words, it should
be appreciated that the door device 102 may indicate a relatively
high likelihood that contact with the door stop is the root door
fault. The gyrometer data depicted in the graph 1402 further
suggests that the backcheck did activate; however, the rate of
change of the signal indicates that the velocity changed
dramatically, which is likely due to a collision with a rigid body.
Further, the upward slope of the signal indicates that something
continued to push the door (i.e., moving it faster) until the door
hit the backstop. Due to the additionally noted force pushing the
door, the door closer 102 may indicate that the fault may have been
due to a user interacting with the door (e.g., to force the door to
90 degrees or beyond) rather than improper door closer
operation.
[0093] Referring now to FIGS. 15-16, in use, the system 100 may
execute a method 1500 for updating a fault prediction database and
associated algorithm. As described above, depending on the
particular embodiment, each of the blocks of the method 1500 may be
executed by the door device 102 and/or the server 104. However, for
brevity of the description, the method 1500 is described herein as
being jointly executed by the door device 102 and the server 104.
It should be appreciated that the particular blocks of the method
1500 are illustrated by way of example, and such blocks may be
combined or divided, added or removed, and/or reordered in whole or
in part depending on the particular embodiment, unless stated to
the contrary.
[0094] The illustrative method 1500 begins with block 1502 in which
the server 104 may populate the fault prediction database with
representative fault data and fault solutions. It should be
appreciated that the representative fault data may include various
weights associated with a machine learning algorithm (e.g., an
artificial neural network). As described above, the fault
prediction database includes fault data that is representative of
various prospective faults or fault conditions and configured to be
compared (directly or indirectly) with sensor data generated by the
door device 102 during operation of the door. Accordingly, in block
1504, the door device 102 receives and compares the "new" sensor
data (e.g., received from the door device 102) to the
representative fault data stored in the fault prediction database
as described above. In block 1506, the door device 102 determines
and rates the faults and fault solutions. For example, as described
above, in some embodiments, the representative fault data may be
compared to the door behavior data to determine whether the
corresponding fault is likely based on the underlying sensor data.
In some embodiments, each of the faults in the fault prediction
database may identify a corresponding fault solution to resolve the
fault.
[0095] In block 1508, the door device 102 displays the most likely
fault solution(s) to the user/technician. For example, in some
embodiments, the door device 102 may display the fault solutions to
the user via the interface device 108. In other embodiments, the
door device 102 may transmit the fault solutions to the mobile
device 106 for display to the user. In yet other embodiments, the
door device 102 may display the fault solutions locally via the
indicator(s) 314 of the door device 102. In block 1510, the door
device 102 receives user input (e.g., from the technician)
indicating the maintenance performed on the door. It should be
appreciated that maintenance performed may or may not be the
maintenance recommended depending on the particular circumstances.
For example, in some embodiments, the technician may ignore the
recommendations of the door device 102.
[0096] In block 1512, after the maintenance has been performed, the
door device 102 captures and analyzes additional sensor data
associated with the operation of the door based on the techniques
described above to determine whether there are any further faults
associated with the door operation. As described above, it should
be appreciated that the analysis may be performed on the door
device 102 or the server 104 depending on the particular
embodiment. In block 1514, the door device 102 determines whether
the operation of the door is in a good state (e.g., operating
normally and/or satisfactorily). If not, the method 1500 returns to
block 1504 in which the door device 102 again compares the sensor
data to the fault data stored in the fault prediction database to
determine the most likely door fault(s). Otherwise, the method 1500
advances to block 1516 in which the door device 102 transmits the
pre-solution data and the post-solution data to the server 104. For
example, the pre-solution and post-solution data may include the
raw sensor data and/or the filtered, analyzed, and/or otherwise
processed sensor data. Further, in some embodiments, the
pre-solution and post-solution data may include the various
likelihoods, behavioral data, the maintenance performed, and/or
other data described herein.
[0097] In block 1518 of FIG. 16, the server 104 compares the
solution data to the fault prediction database to determine whether
the fault prediction already associates the identified likely fault
with the maintenance performed. If the server 104 determines in
block 1520 that the combination is already known, the method 1500
advances to block 1522 in which the server 104 updates the fault
prediction database with the appropriate weights. For example, as
described above, the weights of the various faults and/or solutions
may be associated with an artificial neural network or other
machine learning algorithm. If the combination is not known, the
method 1500 advances to block 1524 in which the server 104 compares
the solution data to an unverified (e.g., premature) fault
prediction database. In other words, in some embodiments, the
system 100 may include an unverified fault prediction database that
includes fault data and corresponding solutions that are possible
matches but not yet confirmed to the extent necessary to
confidently suggest those solutions for the corresponding
faults.
[0098] In block 1526, the server 104 determines whether the
fault/solution combination matches an existing combination
identified in the unverified fault prediction database. If not, the
method 1500 advances to block 1528 in which the server 104 adds the
fault/solution combination to the unverified fault prediction
database. Otherwise, the method 1500 advances to block 1530 in
which the server 104 updates the solution data and the unverified
fault prediction weight/score. In block 1532, the server 104
determines whether the weight/score of the unverified fault
prediction combination exceeds a predetermined threshold. If so, in
block 1534, the server 104 moves the solution data (e.g., the
fault/solution combination) from the unverified fault prediction
database to the standard fault prediction database from which
solutions are drawn for user recommendations.
[0099] Although the blocks 1502-1534 are described in a relatively
serial manner, it should be appreciated that various blocks of the
method 1500 may be performed in parallel in some embodiments.
* * * * *