Rule Server Device Action Triggering
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing device architectures for responding to conditions are inefficient, resource-intensive, and difficult to extend for multiple applications, especially in detecting location-based conditions across different hardware mechanisms, leading to limitations in battery life, resource utilization, and inter-device interoperability.
Innovation Solution
A rule server provides a rule set with hardware-independent conditions and sensor-specific condition tests, allowing devices to register and evaluate conditions without continuous polling, enabling flexible and efficient action execution across various sensors and devices.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If applications continuously poll sensors to detect condition fulfillment, then conditions can be detected reliably, but processor usage, memory consumption, and power consumption increase significantly
Solution Approach 1:
The system performs preliminary configuration by registering condition tests with sensors in advance. The sensor is configured to automatically generate notifications when conditions are met, eliminating the need for continuous polling applications. This preliminary setup allows the system to achieve reliable condition detection while consuming minimal power, as the sensor handles monitoring autonomously without requiring active application intervention.
Solution Approach 2:
The sensor performs self-service by autonomously evaluating registered condition tests and generating notifications when conditions are fulfilled. Instead of requiring applications to continuously poll and evaluate conditions, the sensor itself services the condition monitoring function, reducing processor usage and power consumption while maintaining reliable detection.
2Ease of manufacture
If applications are designed to monitor conditions and execute actions, then the architecture is simple to implement, but it is difficult to extend to multiple applications and devices
Solution Approach 1:
The system implements a universal architecture where a single sensor can serve multiple applications by evaluating different registered condition tests. The sensor acts as a multi-functional component that can monitor various conditions for different applications without requiring separate polling mechanisms. This universal approach enables easy extension to multiple applications and devices while maintaining implementation simplicity through centralized condition management.
Solution Approach 2:
The system introduces an intermediary layer (the condition testing and notification mechanism) between the sensor and multiple applications. This intermediary enables the sensor to communicate condition fulfillment status to multiple applications without requiring each application to directly interface with the sensor. This mediator architecture facilitates easy extension to multiple applications and devices while keeping individual application implementation simple.
3Measurement precision
If applications specify conditions based on specific hardware (e.g., GPS receiver), then location detection is precise, but the application cannot operate on devices with different location mechanisms
Solution Approach 1:
The system implements a universal condition testing interface that can evaluate location-based conditions using different hardware mechanisms. The sensor (whether GPS, WiFi adapter, or other location mechanism) registers condition tests that are hardware-agnostic in their evaluation logic. This allows the same application to operate across devices with different location hardware while maintaining precise location detection through the appropriate sensor for each device type.
Data Source
AI summary
In some scenarios, devices may execute applications that are configured to monitor a set of conditions (e.g., geographic coordinates detected by global positioning system (GPS) receivers), and to execute actions upon detecting the fulfillment of the conditions. However, in such architectures, each application may be responsible for polling the sensors of the device to detect condition fulfillment, and it may be difficult to specify rules in a hardware-independent manner involving multiple applications and/or devices. Presented herein are techniques for configuring devices to perform actions by receiving a rule set from a rule server; registering a set of condition tests for respective conditions of a rule with the sensors of the device; upon being notified by the sensor that a condition test has been fulfilled, evaluating the conditions of the rule; and upon determining a fulfillment of the conditions, executing one or more actions (optionally involving multiple devices and/or applications).