Patent Application
20170330448
This patent specification relates to systems and methods for handling latent anomalies in field devices.
Electronic devices are typically subjected to a battery of tests during development and production in an attempt to limit or eliminate anomalies (e.g., defects) that affect the operation of the device after its point of sale. However, despite the testing, there may be instances which latent anomalies occur after the point of sale. Accordingly, systems and methods for handling these latent anomalies are needed.
Systems and methods for handling latent anomalies in field devices are described herein. When an anomaly is detected, the system can earmark the presence of the detected anomaly with a flag or other notification, and announce the existence of the anomaly to a user. In some embodiments, a self-test may be distributed to devices in the field that may be potentially affected by the latent anomaly so that those devices can monitor for the presence of the anomaly and take appropriate action if detected.
In one embodiment, a method for handling latent anomalies is provided. The method can include evaluating a plurality of data sources to detect existence of a latent anomaly, and in response to detecting existence of the latent anomaly: identifying a subset of a plurality of field devices that has potential to exhibit the latent anomaly; and providing a self-test to each field device in the identified subset such that each field device in the identified subset can monitor for the latent anomaly and perform an action in response to monitoring the occurrence of the latent anomaly.
In another embodiment, a field device for handling a latent anomaly is provided that can include a plurality of sensors, communications circuitry, non-volatile memory, and a processor. The process can be operative to receive a self-test module via the communications circuitry, wherein the self-test module comprises instructions that enables the field device to monitor for existence of a latent anomaly, store the received self-test module in the non-volatile memory, and periodically perform a self-test in accordance with the instructions to determine whether the latent anomaly exists within the field device.
In yet another embodiment, a system for handling latent anomalies is provided that can include a plurality of data sources that indicate potential existence of a latent anomaly in at least one of a plurality of field devices, wherein a first one of the plurality of data sources comprises a test system capable of running a battery of tests that subject a test device to stresses that the field device could potentially incur over its operational life, and latent anomaly handing system that receives data from the plurality of data sources. the latent anomaly handling system can be operative to evaluate the data to detect existence of a latent anomaly, and in response to detecting existence of the latent anomaly: identify a subset of a plurality of field devices that has potential to exhibit the latent anomaly, provide a self-test to each field device in the identified subset such that each field device in the identified subset can monitor for the latent anomaly and perform an action in response to monitoring the occurrence of the latent anomaly.
A further understanding of the nature and advantages of the embodiments discussed herein may be realized by reference to the remaining portions of the specification and the drawings.
In the following detailed description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of the various embodiments. Those of ordinary skill in the art will realize that these various embodiments are illustrative only and are not intended to be limiting in any way. Other embodiments will readily suggest themselves to such skilled persons having the benefit of this disclosure.
In addition, for clarity purposes, not all of the routine features of the embodiments described herein are shown or described. One of ordinary skill in the art would readily appreciate that in the development of any such actual embodiment, numerous embodiment-specific decisions may be required to achieve specific design objectives. These design objectives will vary from one embodiment to another and from one developer to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming but would nevertheless be a routine engineering undertaking for those of ordinary skill in the art having the benefit of this disclosure.
It is to be appreciated that while one or more devices are described further herein in the context of being used in a residential home, such as a single-family residential home, the scope of the present teachings is not so limited. More generally, the devices are applicable to a wide variety of enclosures such as, for example, duplexes, townhomes, multi-unit apartment buildings, hotels, retail stores, office buildings, and industrial buildings. Further, it is understood that while the terms user, customer, installer, homeowner, occupant, guest, tenant, landlord, repair person, and the like may be used to refer to the person or persons who are interacting with the hazard detector in the context of one or more scenarios described herein, these references are by no means to be considered as limiting the scope of the present teachings with respect to the person or persons who are performing such actions. The embodiments discussed herein may be implemented in any suitable smart home device such as, for example, a thermostat, hazard detection system, a camera system, or a security system. It should be further understood that some embodiments discussed herein may be executed on any device that is not necessarily tied to an enclosure. For example, devices such as personal electronics (e.g., smart phones, laptops, tablets, desktops, music players), automobiles, and household electronics (e.g., washing machine, dryer, dishwashing machine) may all experience latent anomalies that require handling.
As defined herein, a latent anomaly refers to a defect that exists or is discovered to exist within a device after that device has been sold or shipped to the end user. Such devices may be referred to herein as field devices. The defect may exist in hardware or software or both hardware and software. The defect may be an anomaly because its occurrence is rare and hard for a user or existing self-test mechanisms to detect, but has the potential to affect certain operations of the device. Or, perhaps, the anomaly does not exist with a state of embedded software included with the device at the time of shipment, but exists after a software update to that device post-sale. Embodiments discussed herein provide different mechanisms for identifying and responsibly managing latent defects in field devices. It should be appreciated that while the present disclosure is provided predominantly in the context of a smart home environment where field devices are electronic devices therein, one skilled in the art would recognize that the disclosure is not so limited. That is, the techniques, methods, and technologies described herein can equally be applied to a wide variety of electronic devices in and outside of a smart home environment, including but not limited to vehicles such as cars, trucks, motorcycles, etc., appliances such as refrigerators, televisions, vacuum cleaners, dishwashers, clothes washing and drying machines, laundry irons, water softeners, water filtration systems, watering systems, etc., consumer/commercial electronics such as personal computers, laptops, tablets, mobile phones, key fobs, etc., industrial systems such as waste water monitoring/treatment, steel manufacturing, vehicle manufacturing technologies, etc., and communication systems such as cellular/internet antennas and equipment, etc.
Hazard detection system 105 can monitor environmental conditions associated with enclosure 100 and alarm occupants when an environmental condition exceeds a predetermined threshold. The monitored conditions can include, for example, smoke, heat, humidity, carbon monoxide, carbon dioxide, radon, and other gasses. In addition to monitoring the safety of the environment, hazard detection system 105 can provide several user interface features not found in conventional alarm systems. These user interface features can include, for example, vocal alarms, voice setup instructions, cloud communications (e.g. push monitored data to the cloud, or push notifications to a mobile telephone, or receive software updates from the cloud), device-to-device communications (e.g., communicate with other hazard detection systems in the enclosure, including the communication of software updates between hazard detection systems), visual safety indicators (e.g., display of a green light indicates it is safe and display of a red light indicates danger), tactile and non-tactile input command processing, and software updates.
Hazard detection system 105 can implement multi-criteria state machines according to various embodiments described herein to provide advanced hazard detection and advanced user interface features such as pre-alarms. In addition, the multi-criteria state machines can manage alarming states and pre-alarming states and can include one or more sensor state machines that can control the alarming states and one or more system state machines that control the pre-alarming states. Each state machine can transition among any one of its states based on sensor data values, hush events, and transition conditions. The transition conditions can define how a state machine transitions from one state to another, and ultimately, how hazard detection system 105 operates. Hazard detection system 105 can use a dual processor arrangement to execute the multi-criteria state machines according to various embodiments. The dual processor arrangement may enable hazard detection system 105 to manage the alarming and pre-alarming states in a manner that uses minimal power while simultaneously providing relatively failsafe hazard detection and alarming functionalities. Additional details of the various embodiments of hazard detection system 105 are discussed below.
Enclosure 100 can include any number of hazard detection systems. For example, as shown, hazard detection system 107 is another hazard detection system, which may be similar to system 105. In one embodiment, both systems 105 and 107 can be battery powered systems. In another embodiment, system 105 may be line powered, and system 107 may be battery powered. Moreover, a hazard detection system can be installed outside of enclosure 100.
Thermostat 110 can be one of several thermostats that may control HVAC system 120. Thermostat 110 can be referred to as the “primary” thermostat because it may be electrically connected to actuate all or part of an HVAC system, by virtue of an electrical connection to HVAC control wires (e.g. W, G, Y, etc.) leading to HVAC system 120. Thermostat 110 can include one or more sensors to gather data from the environment associated with enclosure 100. For example, a sensor may be used to detect occupancy, temperature, light and other environmental conditions within enclosure 100. Remote thermostat 112 can be referred to as an “auxiliary” thermostat because it may not be electrically connected to actuate HVAC system 120, but it too may include one or more sensors to gather data from the environment associated with enclosure 100 and can transmit data to thermostat 110 via a wired or wireless link. For example, thermostat 112 can wirelessly communicate with and cooperates with thermostat 110 for improved control of HVAC system 120. Thermostat 112 can provide additional temperature data indicative of its location within enclosure 100, provide additional occupancy information, or provide another user interface for the user (e.g., to adjust a temperature setpoint).
Hazard detection systems 105 and 107 can communicate with thermostat 110 or thermostat 112 via a wired or wireless link. For example, hazard detection system 105 can wirelessly transmit its monitored data (e.g., temperature and occupancy detection data) to thermostat 110 so that it is provided with additional data to make better informed decisions in controlling HVAC system 120. Moreover, in some embodiments, data may be transmitted from one or more of thermostats 110 and 112 to one or more of hazard detections systems 105 and 107 via a wired or wireless link.
Central panel 130 can be part of a security system or other master control system of enclosure 100. For example, central panel 130 may be a security system that may monitor windows and doors for break-ins, and monitor data provided by motion sensors. In some embodiments, central panel 130 can also communicate with one or more of thermostats 110 and 112 and hazard detection systems 105 and 107. Central panel 130 may perform these communications via wired link, wireless link, or a combination thereof. For example, if smoke is detected by hazard detection system 105, central panel 130 can be alerted to the presence of smoke and make the appropriate notification, such as displaying an indicator that a particular zone within enclosure 100 is experiencing a hazard condition.
Enclosure 100 may further include a private network accessible both wirelessly and through wired connections and may also be referred to as a Local Area Network or LAN. Network devices on the private network can include hazard detection systems 105 and 107, thermostats 110 and 112, computer 124, and central panel 130. In one embodiment, the private network is implemented using router 122, which can provide routing, wireless access point functionality, firewall and multiple wired connection ports for connecting to various wired network devices, such as computer 124. Wireless communications between router 122 and networked devices can be performed using an 802.11 protocol. Router 122 can further provide network devices access to a public network, such as the Internet or the Cloud, through a cable-modem, DSL modem and an Internet service provider or provider of other public network services. Public networks like the Internet are sometimes referred to as a Wide-Area Network or WAN.
Access to the Internet, for example, may enable networked devices such as system 105 or thermostat 110 to communicate with a device or server remote to enclosure 100. The remote server or remote device can host an account management program that manages various networked devices contained within enclosure 100. For example, in the context of hazard detection systems according to embodiments discussed herein, system 105 can periodically upload data to the remote server via router 122. In addition, if a hazard event is detected, the remote server or remote device can be notified of the event after system 105 communicates the notice via router 122. Similarly, system 105 can receive data (e.g., commands or software updates) from the account management program via router 122.
Hazard detection system 105 can operate in one of several different power consumption modes. Each mode can be characterized by the features performed by system 105 and the configuration of system 105 to consume different amounts of power. Each power consumption mode corresponds to a quantity of power consumed by hazard detection system 105, and the quantity of power consumed can range from a lowest quantity to a highest quantity. One of the power consumption modes corresponds to the lowest quantity of power consumption, and another power consumption mode corresponds to the highest quantity of power consumption, and all other power consumption modes fall somewhere between the lowest and the highest quantities of power consumption. Examples of power consumption modes can include an Idle mode, a Log Update mode, a Software Update mode, an Alarm mode, a Pre-Alarm mode, a Hush mode, and a Night Light mode. These power consumption modes are merely illustrative and are not meant to be limiting. Additional or fewer power consumption modes may exist. Moreover, any definitional characterization of the different modes described herein is not meant to be all inclusive, but rather, is meant to provide a general context of each mode.
Hazard detection system 205 can use a bifurcated processor circuit topology for handling the features of system 205. Both system processor 210 and safety processor 230 can exist on the same circuit board within system 205, but perform different tasks. System processor 210 is a larger more capable processor that can consume more power than safety processor 230. That is, when both processors 210 and 230 are active, processor 210 consumes more power than processor 230. Similarly, when both processors are inactive, processor 210 may consume more power than processor 230. System processor 210 can be operative to process user interface features. For example, processor 210 can direct wireless data traffic on both high and low power wireless communications circuitries 212 and 214, access non-volatile memory 216, communicate with processor 230, and cause audio to be emitted from speaker 218. As another example, processor 210 can monitor data acquired by one or more sensors 220 to determine whether any actions need to be taken (e.g., shut off a blaring alarm in response to a user detected action to hush the alarm).
Safety processor 230 can be operative to handle safety related tasks of system 205, or other types of tasks that involve monitoring environmental conditions (such as temperature, humidity, smoke, carbon monoxide, movement, light intensity, etc.) exterior to the hazard detection system 205. Safety processor 230 can poll one or more of sensors 220 and activate alarm 234 when one or more of sensors 220 indicate a hazard event is detected. Processor 230 can operate independently of processor 210 and can activate alarm 234 regardless of what state processor 210 is in. For example, if processor 210 is performing an active function (e.g., performing a WiFi update) or is shut down due to power constraints, processor 230 can activate alarm 234 when a hazard event is detected. In some embodiments, the software running on processor 230 may be permanently fixed and may never be updated via a software or firmware update after system 205 leaves the factory. In other embodiments, processor 230 may be updated when system 205 is in the field.
Compared to processor 210, processor 230 is a less power consuming processor. Thus by using processor 230 in lieu of processor 210 to monitor a subset of sensors 220 yields a power savings. If processor 210 were to constantly monitor sensors 220, the power savings may not be realized. In addition to the power savings realized by using processor 230 for monitoring the subset of sensors 220, bifurcating the processors also ensures that the safety monitoring and core monitoring and alarming features of system 205 will operate regardless of whether processor 210 is functioning. By way of example and not by way of limitation, system processor 210 may comprise a relatively high-powered processor such as Freescale Semiconductor K60 Microcontroller, while safety processor 230 may comprise a relatively low-powered processor such as a Freescale Semiconductor KL15 Microcontroller. Overall operation of hazard detection system 205 entails a judiciously architected functional overlay of system processor 210 and safety processor 230, with system processor 210 performing selected higher-level, advanced functions that may not have been conventionally associated with hazard detection units (for example: more advanced user interface and communications functions; various computationally-intensive algorithms to sense patterns in user behavior or patterns in ambient conditions;
algorithms for governing, for example, the brightness of an LED night light as a function of ambient brightness levels; algorithms for governing, for example, the sound level of an onboard speaker for home intercom functionality; algorithms for governing, for example, the issuance of voice commands to users; algorithms for uploading logged data to a central server; algorithms for establishing network membership; algorithms for facilitating updates to the programmed functionality of one or more elements of the hazard detection system 205 such as the safety processor 230, the high power wireless communications circuitry 212, the low power wireless communications circuitry 214, the system processor 210 itself, etc., and so forth), and with safety processor 230 performing the more basic functions that may have been more conventionally associated with hazard detection units (e.g., smoke and CO monitoring, actuation of shrieking/buzzer alarms upon alarm detection). By way of example and not by way of limitation, system processor 210 may consume on the order of 18 mW when it is in a relatively high-power active state and performing one or more of its assigned advanced functionalities, whereas safety processor 230 may only consume on the order of 0.05 mW when it is performing its basic monitoring functionalities. However, again by way of example and not by way of limitation, system processor 210 may consume only on the order of 0.005 mW when in a relatively low-power inactive state, and the advanced functions that it performs are judiciously selected and timed such that the system processor is in the relatively high power active state only about 0.05% of the time, and spends the rest of the time in the relatively low-power inactive state. Safety processor 230, while only requiring an average power draw of 0.05 mW when it is performing its basic monitoring functionalities, should of course be performing its basic monitoring functionalities 100% of the time. According to one or more embodiments, the judiciously architected functional overlay of system processor 210 and safety processor 230 is designed such that hazard detection system 205 can perform basic monitoring and shriek/buzzer alarming for hazard conditions even in the event that system processor 210 is inactivated or incapacitated, by virtue of the ongoing operation of safety processor 230. Therefore, while system processor 210 is configured and programmed to provide many different capabilities for making hazard detection unit 205 an appealing, desirable, updatable, easy-to-use, intelligent, network-connected sensing and communications node for enhancing the smart-home environment, its functionalities are advantageously provided in the sense of an overlay or adjunct to the core safety operations governed by safety processor 230, such that even in the event there are operational issues or problems with system processor 210 and its advanced functionalities, the underlying safety-related purpose and functionality of hazard detector 205 by virtue of the operation of safety processor 230 will continue on, with or without system processor 210 and its advanced functionalities.
High power wireless communications circuitry 212 can be, for example, a Wi-Fi module capable of communicating according to any of the 802.11 protocols. For example, circuitry 212 may be implemented using WiFi part number BCM43362, available from Murata. Depending on an operating mode of system 205, circuitry 212 can operate in a low power “sleep” state or a high power “active” state. For example, when system 205 is in an Idle mode, circuitry 212 can be in the “sleep” state. When system 205 is in a non-Idle mode such as a Wi-Fi update mode, software update mode, or alarm mode, circuitry 212 can be in an “active” state. For example, when system 205 is in an active alarm mode, high power circuitry 212 may communicate with router 223 so that a message can be sent to a remote server or device.
Low power wireless communications circuitry 214 can be a low power Wireless Personal Area Network (6LoWPAN) module or a ZigBee module capable of communicating according to an 802.15.4 protocol. For example, in one embodiment, circuitry 214 can be part number EM357 SoC available from Silicon Laboratories. Depending on the operating mode of system 205, circuitry 214 can operate in a relatively low power “listen” state or a relatively high power “transmit” state. When system 205 is in the Idle mode, WiFi update mode (which may require use of the high power communication circuitry 212), or software update mode, circuitry 214 can be in the “listen” state. When system 205 is in the Alarm mode, circuitry 214 can transmit data so that the low power wireless communications circuitry in system 207 can receive data indicating that system 205 is alarming. Thus, even though it is possible for high power wireless communications circuitry 212 to be used for listening for alarm events, it can be more power efficient to use low power circuitry 214 for this purpose. Power savings may be further realized when several hazard detection systems or other systems having low power circuitry 214 form an interconnected wireless network.
Power savings may also be realized because in order for low power circuitry 214 to continually listen for data transmitted from other low power circuitry, circuitry 214 may constantly be operating in its “listening” state. This state consumes power, and although it may consume more power than high power circuitry 212 operating in its sleep state, the power saved versus having to periodically activate high power circuitry 214 can be substantial. When high power circuitry 212 is in its active state and low power circuitry 214 is in its transmit state, high power circuitry 212 can consume substantially more power than low power circuitry 214.
In some embodiments, low power wireless communications circuitry 214 can be characterized by its relatively low power consumption and its ability to wirelessly communicate according to a first protocol characterized by relatively low data rates, and high power wireless communications circuitry 212 can be characterized by its relatively high power consumption and its ability to wirelessly communicate according to a second protocol characterized by relatively high data rates. The second protocol can have a much more complicated modulation than the first protocol.
In some embodiments, low power wireless communications circuitry 214 may be a mesh network compatible module that does not require an access point or a router in order to communicate to devices in a network. Mesh network compatibility can include provisions that enable mesh network compatible modules to keep track of other nearby mesh network compatible modules so that data can be passed through neighboring modules. Mesh network compatibility is essentially the hallmark of the 802.15.4 protocol. In contrast, high power wireless communications circuitry 212 is not a mesh network compatible module and requires an access point or router in order to communicate to devices in a network. Thus, if a first device having circuitry 212 wants to communicate data to another device having circuitry 212, the first device has to communicate with the router, which then transmits the data to the second device. In some embodiments, circuitry 212 can be used to communicate directly with another device that has circuitry 212.
Non-volatile memory 216 can be any suitable permanent memory storage such as, for example, NAND Flash, a hard disk drive, NOR, ROM, or phase change memory. In one embodiment, non-volatile memory 216 can store audio clips that can be played back by speaker 218. The audio clips can include installation instructions or warnings in one or more languages. Speaker 218 can be any suitable speaker operable to playback sounds or audio files. Speaker 218 can include an amplifier (not shown).
Sensors 220 can be monitored by safety processor 230 (and, in some embodiments, system processor 210), and can include safety sensors 221 and non-safety sensors 222. One or more of sensors 220 may be exclusively monitored by one of system processor 210 and safety processor 230. As defined herein, monitoring a sensor refers to a processor's ability to acquire data from that monitored sensor. That is, one particular processor may be responsible for acquiring sensor data, and possibly storing it in a sensor log, but once the data is acquired, it can be made available to another processor either in the form of logged data or real-time data. For example, in one embodiment, system processor 210 may monitor one of non-safety sensors 222, but safety processor 230 cannot monitor that same non-safety sensor. In another embodiment, safety processor 230 may monitor each of the safety sensors 221, but may provide the acquired sensor data (or some information indicative of the acquired sensor data) to system processor 210.
Safety sensors 221 can include sensors necessary for ensuring that hazard detection system 205 can monitor its environment for hazardous conditions and alert users when hazardous conditions are detected, and all other sensors not necessary for detecting a hazardous condition are non-safety sensors 222. In some embodiments, safety sensors 221 include only those sensors necessary for detecting a hazardous condition. For example, if the hazardous condition includes smoke and fire, then the safety sensors might only include a smoke sensor and at least one heat sensor. Other sensors, such as non-safety sensors, could be included as part of system 205, but might not be needed to detect smoke or fire. As another example, if the hazardous condition includes carbon monoxide, then the safety sensor might be a carbon monoxide sensor, and no other sensor might be needed to perform this task.
Thus, sensors deemed necessary can vary based on the functionality and features of hazard detection system 205. In one embodiment, hazard detection system 205 can be a combination smoke, fire, and carbon monoxide alarm system. In such an embodiment, detection system 205 can include the following safety sensors 221: a smoke detector, a carbon monoxide (CO) sensor, and one or more heat sensors. Smoke detectors can detect smoke and typically use optical detection, ionization, or air sampling techniques. A CO sensor can detect the presence of carbon monoxide gas, which, in the home, is typically generated by open flames, space heaters, water heaters, blocked chimneys, and automobiles. The material used in electrochemical CO sensors typically has a 5-7 year lifespan. Thus, after a 5-7 year period has expired, the CO sensor should be replaced. A heat sensor can be a thermistor, which is a type of resistor whose resistance varies based on temperature. Thermistors can include negative temperature coefficient (NTC) type thermistors or positive temperature coefficient (PTC) type thermistors. Furthermore, in this embodiment, detection system 205 can include the following non-safety sensors 222: a humidity sensor, an ambient light sensor, a push-button sensor, a passive infra-red (PIR) sensor, and one or more ultrasonic sensors. A temperature and humidity sensor can provide relatively accurate readings of temperature and relative humidity. An ambient light sensor (ALS) can detect ambient light and the push-button sensor can be a switch, for example, that detects a user's press of the switch. A PIR sensor can be used for various motion detection features. A PIR sensor can measure infrared light radiating from objects in its field of view. Ultrasonic sensors can be used to detect the presence of an object. Such sensors can generate high frequency sound waves and determine which wave(s) are received back by the sensor. Sensors 220 can be mounted to a printed circuit board (e.g., the same board that processors 210 and 230 may be mounted to), a flexible printed circuit board, a housing of system 205, or a combination thereof.
In some embodiments, data acquired from one or more non-safety sensors 222 can be acquired by the same processor used to acquire data from one or more safety sensors 221. For example, safety processor 230 may be operative to monitor both safety and non-safety sensors 221 and 222 for power savings reasons, as discussed above. Although safety processor 230 may not need any of the data acquired from non-safety sensor 222 to perform its hazard monitoring and alerting functions, the non-safety sensor data can be utilized to provide enhanced hazard system 205 functionality. The enhanced functionality can be realized in alarming algorithms according to various embodiments discussed herein. For example, the non-sensor data can be utilized by system processor 210 to implement system state machines that may interface with one or more sensor state machines, all of which are discussed in more detail below in connection with the description accompanying
Lighting circuitry 225 may represent any light such as LEDs that may be used to illuminate portions of system 205. Lighting circuitry 225 may selectively illuminate the LEDs to convey information to a user, or can be used to provide a nightlight in some embodiments.
Alarm 234 can be any suitable alarm that alerts users in the vicinity of system 205 of the presence of a hazard condition. Alarm 234 can also be activated during testing scenarios. Alarm 234 can be a piezo-electric buzzer, for example.
Power source 240 can supply power to enable operation of system 205 and can include any suitable source of energy. Embodiments discussed herein can include AC line powered, battery powered, a combination of AC line powered with a battery backup, and externally supplied DC power (e.g., USB supplied power). Embodiments that use AC line power, AC line power with battery backup, or externally supplied DC power may be subject to different power conservation constraints than battery only embodiments. Battery powered embodiments are designed to manage power consumption of its finite energy supply such that hazard detection system 205 operates for a minimum period of time. In some embodiments, the minimum period of time can be one (1) year, three (3) years, or seven (7) years. In other embodiments, the minimum period of time can be at least seven (7) years, eight (8) years, nine (9) years, or ten (10) years. Line powered embodiments are not as constrained because their energy supply is virtually unlimited. Line powered with battery backup embodiments may employ power conservation methods to prolong the life of the backup battery.
In battery only embodiments, power source 240 can include one or more batteries or a battery pack. The batteries can be constructed from different compositions (e.g., alkaline or lithium iron disulfide) and different end-user configurations (e.g., permanent, user replaceable, or non-user replaceable) can be used. In one embodiment, six cells of Li—FeS2 can be arranged in two stacks of three. Such an arrangement can yield about 27000 mWh of total available power for system 205.
Power conversion circuitry 242 includes circuitry that converts power from one level to another. Multiple instances of power conversion circuitry 242 may be used to provide the different power levels needed for the components within system 205. One or more instances of power conversion circuitry 242 can be operative to convert a signal supplied by power source 240 to a different signal. Such instances of power conversion circuitry 242 can exist in the form of buck converters or boost converters. For example, alarm 234 may require a higher operating voltage than high power wireless communications circuitry 212, which may require a higher operating voltage than processor 210, such that all required voltages are different than the voltage supplied by power source 240. Thus, as can be appreciated in this example, at least three different instances of power conversion circuitry 242 are required.
High quality power circuitry 243 is operative to condition a signal supplied from a particular instance of power conversion circuitry 242 (e.g., a buck converter) to another signal. High quality power circuitry 243 may exist in the form of a low-dropout regulator. The low-dropout regulator may be able to provide a higher quality signal than that provided by power conversion circuitry 242. Thus, certain components may be provided with “higher” quality power than other components. For example, certain safety sensors 221 such as smoke detectors and CO sensors may require a relatively stable voltage in order to operate properly.
Power gating circuitry 244 can be used to selectively couple and de-couple components from a power bus. De-coupling a component from a power bus insures that the component does not incur any quiescent current loss, and therefore can extend battery life beyond that which it would be if the component were not so de-coupled from the power bus. Power gating circuitry 244 can be a switch such as, for example, a MOSFET transistor. Even though a component is de-coupled from a power bus and does not incur any current loss, power gating circuitry 244 itself may consume a finite amount of power. This finite power consumption, however, is less than the quiescent power loss of the component.
Self-test module 250 may include one or more programs for testing different hardware components, device functionality, and/or software. Self-test module 250 may store tests specifically designed to detect whether a latent anomaly exists in system 205 or to monitor for the occurrence of the latent anomaly.
It is understood that although hazard detection system 205 is described as having two separate processors, system processor 210 and safety processor 230, which may provide certain advantages as described hereinabove and hereinbelow, including advantages with regard to power consumption as well as with regard to survivability of core safety monitoring and alarming in the event of advanced feature provision issues, it is not outside the scope of the present teachings for one or more of the various embodiments discussed herein to be executed by one processor or by more than two processors.
Latent anomaly handling system 300 may be responsible for determining whether a latent anomaly exists in a subset of field devices or all field devices, in general, based on data received from field devices 310, direct inputs 320, and empirical inputs 330. In some embodiments, direct inputs 320 and empirical inputs 330 may be derived from data received from field devices 310. Direct inputs 320 may represent latent anomalies that are actually observed in one form or another. For example, a direct input may be derived from a user report indicating that something is not functioning properly in his/her device. As another example, a direct input may be derived from user returns of the field device, where a technician evaluates the returned device to determine the latent anomaly. As yet another example, a direct input can be derived from one or more field based self-tests that are performed by the field unit. For example, in the context of a hazard detection system, self-tests can include a buzzer self-test, a smoke sensor self-test, and speaker self-test. If the field device fails the self-test, it may report the failure as a direct input. In yet another example, a direct input can be derived from devices being tested in a testing system (e.g., a system that is able to subject the device to a battery of tests, tests that can be automatically performed over time to represent the stresses the device may incur over its operational lifetime).
Empirical inputs 330 may represent latent anomalies that are empirically observed in data collected from field devices. The data may be collected from field devices 310 or from devices that are being tested by the testing system. The data may not explicitly show existence of an anomaly (at least something that is glaringly obvious as a potential problem), but analysis of the data indirectly shows that an anomaly is present. For example, historical events such as software crashes, Internet downtimes, lack of smartphone connectivity may be observed, and based on those observations, an inference can be drawn that a device is experiencing some sort of latent anomaly. Empirical inputs 330 may also include analysis of data logs provided by field and tested devices.
Latent anomaly handling system 300 can process inputs 320 and 330 and data from field devices 310 to determine how to handle the anomaly. System 300 can handle anomalies differently depending on the severity of the anomaly, whether the anomaly is detectable using circuitry resident on board the field device, and whether the anomaly is a hardware issue or a software issue. If the severity of the anomaly is considered relatively high, system 300 may inform the owners of the field devices known to potentially exhibit that anomaly to cease using their devices. In some embodiments, with user permission, system 300 may issue a disable device command to the field device, thereby disabling it and preventing its further use. If the severity of the anomaly is relatively low, system 300 may inform the owners that an issue is known to exist with the device and may recommend that certain features not be used. If the anomaly stems from a software issue, system 300 can instruct the field device to perform a software update. If the anomaly stems from a hardware issue, system 300 may determine if the anomaly is detectable. If it detectable, system 300 may instruct the field units to download and install a self-test so that the device can monitor for the occurrence of the anomaly and take appropriate action if the anomaly is monitored.
At step 430, a determination is made as to whether the detected anomaly will prevent desired device operations. Desired device operations may include, e.g., the ability of a sensor to perform in accordance within a particular range (e.g., previously specified) of operation, the ability of an actuator to actuate within a particular range (e.g., previously specified) of operation, the ability of a sensor or actuator to perform as previously mentioned within a specified time frame (e.g., whether the detected anomaly will prevent a sensor from performing its desired operations for at least one year, etc.). Desired device operations can also include, for example, uncompromised operation of hardware components such as sensors, integrated circuits, power sources, mechanical components, display components, audio components, or any other suitable component. Some desired device operations may be classified as being relatively important, whereas other device operations may be classified as being relatively less important. For example, a device operation classified as relatively important may include device operations that provide safety features or features deemed critical or necessary for the device to operate in the manner for which it was originally designed. In some embodiments, if the detected anomaly will prevent desired operations, then that device should no longer be used. An anomaly which will prevent desired device operations is contrasted to an anomaly that will not prevent desired device operations. Such an anomaly may affect a device operation classified as being relatively less important. For example, a device operation classified as being relatively less important can include a non-safety feature or non-critical feature that does not affect operation of the relatively important device operations. If the determination at step 430 is that the anomaly is one that will prevent desire operations, process 400 may instruct the owners of the identified subset to cease using the field device (at step 435). Process 400 may also send instructions to the identified subset to indicate that the device should no longer be used. For example, the device may display its light as red to indicate that this is a problem, or it may playback a spoken message indicating that it should no longer be used.
If the determination at step 430 is NO, process 400 may determine whether the anomaly is correctable via a software update (step 440). If YES, a software update may be performed for at least the identified subset to correct the detected anomaly (at step 445). If the determination at step 440 is NO, then it may be inferred that the anomaly is a hardware problem, and a self-test can be provided to the identified subset of field devices (step 450). The identified subset of field devices can then monitor for the detected anomaly, using the self-test, and take appropriate action if and when it is detected. For example, if the anomaly is detected, the field device may notify the owner via a push notification to his smart phone, cause an email to be sent to the owner, display a light or other indicator to signify that there is a potential issue with the device, or playback a spoken message informing the owner of the issue.
It is understood that the steps shown in
In some scenarios, an anomaly may not be actually detected to exist on a known set of devices, but may be suspected to exist. In situations where a suspected (but not confirmed) anomaly exists, a software update may be transmitted to all devices or a subset of those devices. The software update may include a self-test to determine whether the suspected anomaly does exist. Those devices that confirm existence of the suspected anomaly may report the existence to a central server, which may process the report and issue a software update (if the anomaly can be corrected via software) or may issues an instruction to inform the user to cease using the device.
At step 520, a determination is made as to whether an anomaly has been detected. The anomaly may be a hardware failure, a software failure, or combination thereof that prevents the device from adequately providing one or more basic features or enhanced features. If the anomaly has been previously detected, its existence may be permanently stored in the non-volatile memory. In some embodiments, detected presence of the anomaly may be accessible in the non-volatile memory during boot of the non-volatile memory. In other embodiments, the anomaly detection performed at step 520 may be performed each time the non-volatile memory is accessed. If the determination of step 520 is NO, process 500 may proceed with normal operation of the device, as indicated by step 530. However, if the determination of step 520 is YES, the device may operate in a reduced capacity (e.g., a capacity that is similar to the normal operation, but fewer features are enabled), and alert the user with an audible message, a visual indicator, or both, as indicated by step 540. The alert may be presented immediately, or it may be presented along with other messages as part of a normally scheduled announcement or in response to a user request for the messages. In addition, if an anomaly is detected, feedback can be sent back to a cloud service indicating that an anomaly has been detected, and include device-specific information such as model number, manufacturing date, and information regarding boards, operating system version, embedded software versions in different chips, etc.
It is understood that the steps shown in
HF Env portion 614 can optionally store high frequency environment variables. For example, portion 614 can store variables that need to be changed relatively frequently, such as for security purposes. Debug portion 606 may include logs for implementing debugging operations. Image 0 and 1 portions 608 and 610 may each include a different version of code for enabling operation of the hazard detection system. Audio portion 612 may store one or more audio files, for example, that may be played back through the speaker (e.g., speaker 218). Failure variable portion 616 may store detected failures, including detected anomalies. Failure variable portion 616 may be separate from the failure variable contained in ENV portions 602 and 604. In some embodiments, failure variable portion 616 may be a redundant version of the failure variable contained in ENV portions 602 and 604.
Image portions 608 and 610 can be either an active or inactive portion, depending on which portion is currently being used for the software executing on the hazard system. For example, if the hazard system is booted using code stored in image portion 608, image portion 608 would be the active portion, and image portion 610 would be the inactive portion. As defined herein, an active portion of code may be code that has been installed in (and being run from) the ‘local’ memory associated with a processor. As defined herein, an inactive portion of code may be code that exists in a memory (e.g., NVM) but is not currently installed in (and being run from) the ‘local’ memory associated with a processor. During a software update process (e.g., an over the air download embodiment), a newly downloaded software update package can be stored in the inactive portion. In other embodiments, the downloaded software update package can be stored in any available portion, including the active portion. The software stored in NVM 600 may serve as storage for all of the software running on each of the processors and/or devices contained within the hazard system, but not all the code is executed from the NVM 600. Respective code portions for each processor and/or device can be installed therein and the locally installed code may be executed.
Each portion can include code and/or data necessary to identify information or perform operations associated with its name. For example, header portion 620 can include header information for identifying the location of image 0 in NVM 600. Signature portion 622 may include proprietary information used for authentication. Manifest portion 624 may specify the contents of image 0. For example, manifest portion 624 may specify the software version and its audio kit language. Audio kit portion 628 may contain code and/or files for enabling playback of speech in a specific language. For example, in one embodiment, audio kit portion 628 for image 608 may include speech files in the English language, whereas an audio kit portion for image 610 may include speech files in the French language.
Microprocessor (μP) portions 630, 632, 634, 636, and 638 may each store code or firmware for enabling operation of its (or their) respective microprocessor. The code stored in portions 630, 632, 634, 636, and 638 may be installed in and executed by their respective microprocessors. For example, first (μP) portion 630 may include firmware for enabling a first μP to operate. In some embodiments, the first μP may be similar to system processor 210 of
It is understood that the steps shown in
If the CRC fails on that portion, anomaly detected data may be programmed into the failure variable, as indicated by step 850. Programming the anomaly detected data into the failure variable ensures that the device is made aware of the existence of the anomaly even if it is not persistent. At step 860, an audible message may be emitted to alert the user of the anomaly. The audible message may be a generic message such as “replace your device” and it may be message that trumps all other potential audible messages that could be reported based on what is stored in the failure variable.
It is understood that the steps shown in
It is understood that the steps shown in
In some embodiments, it may be desirable to proactively subject field units to a battery of tests to simulate stresses the field unit could potentially incur over its operational life, thereby proactively discovering any possible latent defects. The tests may be designed to test and stress many operational features, circuitry, and components of the field device, and a testing system is able to monitor and record the results of each test. The testing system can also test user scenarios. Some of the operational features may include visual features such as, for example, specific display of lights of LEDs, content displayed on a display screen, and/or other user interface elements. Other operational features can include audio features such as, for example, voice message playback, buzzer alarm, and/or audio beeps or clicks made in response to user input. Yet additional operational features can include wireless communications between field devices, a field device and a router, a field device and a smart phone, and/or a field device and another smart device such as a smart light.
The test system may be designed to automatically test products in various user scenarios. For example, when setting up a device, there are many user interactions that need to be tested such as visually detecting the color of lights and other UI elements. Another example is when a product speaks, it may be desirable to ensure that playback of audio files is sufficiently clear and devoid of pops, clicks, or garbling that may occur when a product is under stress. The test system can automate the detection of these features so that a trained human does not have to physically observe the device in test.
The test system apparatus can include a testing platform that takes the shape of a fully enclosed box, in which the device being tested resides. The test system can include an array of test sensors such as, for example, a camera, a video camera, a webcam, a microphone, a vibration sensor, and any other suitable sensor. The test system can also include lighting, device and sensor mounting hardware, green screen fabric, sound insulation, power, and connections. The test system may also include control circuitry for controlling the sensors and the device, and may include a data logger for storing the results of the tests.
As mentioned above, the test system may be able to monitor visual outputs of the device. This can be accomplished using computer vision techniques that use an initial setup phase for identifying (and defining) particular areas of interests (AOIs) on the device to be monitored and a test phase for continuously monitoring those AOIs during the battery of tests. The setup phase is now discussed in conjunction with
At step 1035, area of interest selections may be received in response to user selections. For example, the user may be presented with the cleaned image of the device under test and provided with graphical user interface (GUI) selection tools that allow the user to define the areas of interest that he or she wants the test system to monitor. Using the GUI selection tools, the user may draw polygons, circles, or other geometric shapes around particular objects on the device. For example, if the user would like to monitor a light ring, he can draw a circle around the light ring. As another example, if the user would like to monitor a LCD screen, he can draw a rectangular shape around the display. If desired, the user can also mask areas that are not to be observed. For example, referring back to the light ring, the user may not want to monitor the space inside the ring and may mask that interior space.
At step 1037, the system may approximate a boundary border and a centroid for the device. The centroid and boundary may be determined by the shape of the device and areas removed from chroma keying and morphological opening. A frame of reference can be obtained based on a combination of the centroid and the boundary. The centroid may then be used as a reference point for storing the location of each area of interest selection (e.g., the GUI selected polygons and circles). After all GUI selections of AOIs are selected and stored as AOI specifications, one or more reference images may be stored. Objects specified in the AOI specifications can be identified based its similarity to the reference image. Thus, the reference image may provide a basis for enabling step 1050 to identify objects in the image.
Returning to step 1030, and assuming that the AOIs and reference images are stored, process 1000 may proceed to step 1040. At step 1040, generic region(s) of interest may be isolated in the cleaned image. For example, the generic region can be the device itself. As another example, an image processing controller may identify one or more generic regions that exist on the device. These generic regions may serve as starting points for enabling the image processing controller to more particularly identify objects in the cleaned image. In addition, at step 1040, the centroid and boundary may be determined by the shape of the device (in the prepared image) and areas removed from chroma keying and morphological opening.
At step 1050 the objects are identified using a detection process that uses shape matching 1052 and feature matching 1054 to compare the cleaned image to the reference image(s). Each comparison generates a similarity score and the combination of scores is used to identify the object. Shape matching 1052 may be performed by applying a combination of Gaussian and Laplacian functions to reduce an image to its edges and then computing the Hu's image moments. Feature matching 1054 may be a brute-force matching method performed after extracting features using Accelerated-KAZE, outlying matches are then removed using Random Sample Consensus (RANSAC).
After the objects are identified, the areas of interest are re-aligned based on the centroid, boundary border, and the identified objects (at step 1060). After the re-alignment of the area of interest is complete, the area of interests are identified and the device is ready for the test phase (step 1070).
It is understood that the steps shown in
At step 1130, the AOI processor can extract color and status from the pixels associated with the AOI. For example, the pixels can be converted to a Hue-Saturation-Value format to determine the color and status (ON or OFF) of each pixel of the AOI. A state of the AOI is determined based on an average of the Hue-Saturation-Values and status of all pixels associated with that AOI (step 1135). For example, if the AOI is a light ring, the state may indicate the color being emitted by the light ring. The determined state of the AOI may be transmitted to a data logger (step 1140). The data logger may be able track changes in state as the color in the AOI changes over time.
It is understood that the steps shown in
The test system can also test audible outputs, including spoken words. In one embodiment, cloud speech API (e.g., Google's Cloud Speech API) can be used to provide recognition of the spoken words detected within the test fixture. Utterances can be detected based on the Root-Mean-Squared power of the audio signal, and a specified quiet interval. Utterances can then be transcribed using the cloud speech API and can be verified against reference speech specifications. The results can be sent to a data logger that can keep track of instances in which the utterances do not match the reference speech.
The test system can test any number of suitable factors, including HVAC operations of a thermostat, and integration with third party devices. Moreover, the flexibility of the test system enables proactive detection of latent anomalies, the detection of which is discussed below in connection with
At step 1250, a determination is made whether the test results is the same as the expected result. If the determination is YES, process 1200 can loop back to step 1210. If the determination is NO, process 1200 may flag the delta in results as a discrepancy at step 1260. At step 1270, a determination is made whether to fail the device. The failure determination may be a qualitative assessment and not a binary one. For example, it may be that the device fails the test once every ten test, but passes the other nine tests. The data related to the flag may be evaluated to ascertain potential occurrence of a latent anomaly in the device (as indicated by step 1280).
At step 1285, a determination is made as to whether a latent anomaly exists. If NO, process 1200 may return to step 1210. If the determination is YES, in accordance with step 1295 process 1200 may proceed with step 425 in
It is understood that the steps shown in
It is understood that although the software update techniques are described herein with respect to a hazard detection system, these techniques may also be used in any system or device where it is desired to maintain sensing and monitoring of other events while updating the operational capabilities of one of more components of that system or device. For example, the other events can include events that are not necessarily tied to hazards such as smoke, CO, and heat, but can include motion detection, sound detection, and the like. Events reported by remote devices may also be taken into account. For example, security device such as window and door sensor, and motion detection sensors that provide feedback to a system may quality as other events.
Any processes described with respect to
It is to be understood that any or each module or state machine discussed herein may be provided as a software construct, firmware construct, one or more hardware components, or a combination thereof. For example, any one or more of the state machines or modules may be described in the general context of computer-executable instructions, such as program modules, that may be executed by one or more computers or other devices. Generally, a program module may include one or more routines, programs, objects, components, and/or data structures that may perform one or more particular tasks or that may implement one or more particular abstract data types. It is also to be understood that the number, configuration, functionality, and interconnection of the modules or state machines are merely illustrative, and that the number, configuration, functionality, and interconnection of existing modules may be modified or omitted, additional modules may be added, and the interconnection of certain modules may be altered.
Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that the particular embodiments shown and described by way of illustration are in no way intended to be considered limiting. Therefore, reference to the details of the preferred embodiments is not intended to limit their scope.
This application is a continuation-in-part of U.S. patent application Ser. No. 15/085,059, filed Mar. 30, 2016, which claims the benefit of U.S. Provisional Patent Application No. 62/256,117, filed Nov. 16, 2015, the disclosures of which are incorporated by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| 62256117 | Nov 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15085059 | Mar 2016 | US |
| Child | 15665958 | US |
