Statistical Control
In his January 2015 blog, Scott Jenson writes:
With my "live in the future and build what's missing" motto, I arrived at several hundred connected devices at home some time ago. And interesting problems emerge when you have 500 devices around. E.g. with the "industry standard" failure rate, I have several nodes on my network dead every day. For many reasons: depleted batteries, sensors being eaten by dogs, taken away by kids, flooded by rain after being pierced by birds (they especially like the swimming pool floating thermometer), etc. I also once had several radio controlled relays I built into some legacy products (coffee makers etc) and their power supplies died making them inoperable.
Based on the relatively large network and relatively high node failure rate, I realized a Smart Home system should have several means of dealing with the problem. The two most important are:
1. Being aware of the problem and locating the faulty devices. First of all the system must be able to detect there is a problem. This requires some prerequisites from the network protocols and the application layer. For example to detect a device is off the network, it has to be sending "keep alive" packets repeatedly. If no keep alive is seen for a specified period of time, the device should be flagged as faulty and the system should notify other devices (if needed) and humans (if needed). Falling out of the network is obviously not the only faulty state. The device may be overloaded, overheated or report some other kind of error too.
2. Dealing with the sensory data. This is the essence of what the "smart" in "smart home" means to me. The system has to realize the data from a faulty sensor is unreliable. Just like on an airplane. If a sensor reports data that is way off the scale, or is simply old, it should drop it and take other actions. When unreliable data is detected, an Airbus switches from a normal law to an alternate law, giving the controls to pilots. Same here. We don't want to execute a number of rules programmed in the rules engine when the condition triggering the rules cannot be trusted.
But also we can act based on statistics. Assuming there are 2-5 temperature sensors in each room (a safe average), I don't need each of them to report proper readings. I can easily filter out the ones that go haywire. And continue normal operation. I can also trigger an alert to users to check the system. If a sensor in a room reports very low temperature, it may be because the window is open or broken.
In any case the rules engine itself has to be able to process sets of information, not just solitary data points. It is the prerequisite for any statistical control. Have you ever thought a smart home system can be that complex to deliver the expected User Experience? It clearly turns out the Smart Home UX is an EasyHard problem. The perfect challenge we have accepted at Silvair.
we just assume there won’t be many smart devices in our homes because it is so damn hard to put them there in the first place! With the two previous standards in place, it would be child’s play to add items to a home and it would quickly change this from a game of things to a game of swarms
With my "live in the future and build what's missing" motto, I arrived at several hundred connected devices at home some time ago. And interesting problems emerge when you have 500 devices around. E.g. with the "industry standard" failure rate, I have several nodes on my network dead every day. For many reasons: depleted batteries, sensors being eaten by dogs, taken away by kids, flooded by rain after being pierced by birds (they especially like the swimming pool floating thermometer), etc. I also once had several radio controlled relays I built into some legacy products (coffee makers etc) and their power supplies died making them inoperable.
Based on the relatively large network and relatively high node failure rate, I realized a Smart Home system should have several means of dealing with the problem. The two most important are:
1. Being aware of the problem and locating the faulty devices. First of all the system must be able to detect there is a problem. This requires some prerequisites from the network protocols and the application layer. For example to detect a device is off the network, it has to be sending "keep alive" packets repeatedly. If no keep alive is seen for a specified period of time, the device should be flagged as faulty and the system should notify other devices (if needed) and humans (if needed). Falling out of the network is obviously not the only faulty state. The device may be overloaded, overheated or report some other kind of error too.
2. Dealing with the sensory data. This is the essence of what the "smart" in "smart home" means to me. The system has to realize the data from a faulty sensor is unreliable. Just like on an airplane. If a sensor reports data that is way off the scale, or is simply old, it should drop it and take other actions. When unreliable data is detected, an Airbus switches from a normal law to an alternate law, giving the controls to pilots. Same here. We don't want to execute a number of rules programmed in the rules engine when the condition triggering the rules cannot be trusted.
But also we can act based on statistics. Assuming there are 2-5 temperature sensors in each room (a safe average), I don't need each of them to report proper readings. I can easily filter out the ones that go haywire. And continue normal operation. I can also trigger an alert to users to check the system. If a sensor in a room reports very low temperature, it may be because the window is open or broken.
In any case the rules engine itself has to be able to process sets of information, not just solitary data points. It is the prerequisite for any statistical control. Have you ever thought a smart home system can be that complex to deliver the expected User Experience? It clearly turns out the Smart Home UX is an EasyHard problem. The perfect challenge we have accepted at Silvair.
Comments
Post a Comment