WO2015131012A2 - Distributed rules engines for robust sensor networks - Google Patents
Distributed rules engines for robust sensor networks Download PDFInfo
- Publication number
- WO2015131012A2 WO2015131012A2 PCT/US2015/017924 US2015017924W WO2015131012A2 WO 2015131012 A2 WO2015131012 A2 WO 2015131012A2 US 2015017924 W US2015017924 W US 2015017924W WO 2015131012 A2 WO2015131012 A2 WO 2015131012A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- rule
- rules
- node
- function
- execute
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
- A61B17/00—Surgical instruments, devices or methods, e.g. tourniquets
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
- G01S5/00—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations
- G01S5/02—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations using radio waves
- G01S5/0205—Details
- G01S5/0236—Assistance data, e.g. base station almanac
-
- G—PHYSICS
- G01—MEASURING; TESTING
- G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
- G01S5/00—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations
- G01S5/02—Position-fixing by co-ordinating two or more direction or position line determinations; Position-fixing by co-ordinating two or more distance determinations using radio waves
- G01S5/0284—Relative positioning
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B7/00—Signalling systems according to more than one of groups G08B3/00 - G08B6/00; Personal calling systems according to more than one of groups G08B3/00 - G08B6/00
- G08B7/06—Signalling systems according to more than one of groups G08B3/00 - G08B6/00; Personal calling systems according to more than one of groups G08B3/00 - G08B6/00 using electric transmission, e.g. involving audible and visible signalling through the use of sound and light sources
- G08B7/062—Signalling systems according to more than one of groups G08B3/00 - G08B6/00; Personal calling systems according to more than one of groups G08B3/00 - G08B6/00 using electric transmission, e.g. involving audible and visible signalling through the use of sound and light sources indicating emergency exits
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
Definitions
- This description relates to operation of sensor networks such as those used for security, intrusion and alarm systems installed on commercial or residential premises.
- Security systems often include an intrusion detection panel that is electrically or wirelessly connected to a variety of sensors. Those sensors types typically include motion detectors, cameras, and proximity sensors (used to determine whether a door or window has been opened). Typically, such systems receive a very simple signal (electrically open or closed) from one or more of these sensors to indicate that a particular condition being monitored has changed or become unsecure.
- Government entities, companies, academic institutions, etc. issue credentials to employees, contractors, students, etc. to control access to buildings and facilities, indoors and outdoors. Individuals who bypass security systems to gain access, either intentionally or unintentionally, are difficult to identify and locate.
- rales engine As a subcomponent, many devices use a rales engine as a subcomponent for processing rules that control and monitor processes or devices.
- the execution of rales may produce no output as when monitoring devices update internal values and processes, or execution of rules may be indication that a rule has fired (executed).
- rules and data updates are sent to the rules engine and rules either fire or do not fire.
- another component evaluates the output of the ru les engine and determines an action to take such as where results should he sent or if additional processes are needed or if the rule is chained to other rules or in a general sense how to route the outputs from firing of the rales.
- the specifics of the data gathering system includes a network of multiple sensors that collect data as well as a system to determine from the sensor data that monitor events and locations of events.
- a connection to the indicators could he wired and powered network or could be wireless.
- Detection sensors include some or all of Fire and Smoke and Toxic gas or chemical detectors, alarm boxes, audio detectors, structural change detectors, people counters, and motion sensors.
- detectors/sensors report location data as well as raw sensor data.
- FIG. 1 is a schematic diagram of an exemplary networked security system.
- FIG. 2 is a block diagram of generic application layer manager.
- FIG. 3 is a block diagram showing an example process on the application layer manager.
- FIG. 4 is a diagram of exemplary state transitions on the application layer manager.
- FIGS. 5-7 are flow charts depicting processing across distributed rules engines.
- FIG. 8 is a block diagram of components of an example networked security system.
- Example security systems may include an intrusion detection panel that is electrically or wirelessly connected to a variety of sensors.
- Those sensors types may include motion detectors, cameras, and proximity sensors (used, e.g., to determine whether a door or window has been opened).
- proximity sensors used, e.g., to determine whether a door or window has been opened.
- Such systems receive a relatively simple signal (electrically open or closed) from one or more of these sensors to indicate that a particular condition being monitored has changed or become unsecure.
- typical intrusion systems can be set-up to monitor entry doors in a building.
- a proximity sensor senses a magnetic contact and produces an electrically closed circuit.
- the proximity sensor opens the circuit, and sends a signal to the panel indicating that an alarm condition has occurred (e.g., an opened entry door).
- Data collection systems are becoming more common in some applications, such as home safety monitoring.
- Data collection systems employ wireless sensor networks and wireless devices, and may include remote server-based monitoring and report generation.
- wireless sensor networks generally use a combination of wired and wireless links between computing devices, with wireless links usually used for the lowest level connections (e.g., end-node device to hub/gateway).
- the edge (wirelessly-connected) tier of the network is comprised of resource-constrained devices with specific functions. These devices may have a small-to-moderate amount of processing power and memory, and may be battery powered, thus requiring that they conserve energy by spending much of their time in sleep mode.
- a typical model is one where the edge devices generally form a single wireless network in which each end-node communicates directly with its parent node in a hub-and-spoke-style architecture (also known as a star topology).
- the parent node may be, e.g., an access point on a gateway or a sub-coordinator which is, in turn, connected to the access point or another sub-coordinator.
- FIG. 1 an exemplary (global) distributed network topology for a Wireless Sensor Network (WSN) is shown.
- the distributed network 10 is logically divided into a set of tiers or hierarchical levels 12a- 12c.
- the global distributed network topology for the sensor network includes distributed rule engines denoted by the circle element "R" at individual nodes or collections of nodes.
- R distributed rule engines
- an upper tier or hierarchical level 12a of the network are disposed servers and/or virtual, servers 14 running a "cloud computing" paradigm that are networked together using well-established networking technology such as Internet protocols or which can be private networks that use none or part of the Internet.
- the distributed network 10 has direct links between devices (nodes) as shown and discussed below.
- the distributed network 10 includes a second logically divided tier or hierarchical level 12b, referred to here as a middle tier that involves gateways 16 located at central, convenient places inside individual buildings and structures. These gateways 16 communicate with servers 14 in the upper tier whether the servers are stand-alone dedicated servers and/or cloud based servers running cloud applications using web programming techniques.
- the middle tier gateways 16 are also shown with both local area network 17a (e.g., Ethernet or 802.1 1) and cellular network interfaces 17b.
- the distributed network topology also includes a lower tier (edge layer) 12c set of devices that involve fully-functional sensor nodes 18 (e.g., sensor nodes that include wireless devices, e.g., transceivers or at least transmitters, which in FIG. 1 are marked in with an "F") as well as constrained wireless sensor nodes or sensor end-nodes 20 (marked in the FIG. 1 with "C").
- fully-functional sensor nodes 18 e.g., sensor nodes that include wireless devices, e.g., transceivers or at least transmitters, which in FIG. 1 are marked in with an "F"
- constrained wireless sensor nodes or sensor end-nodes 20 marked in the FIG. 1 with "C”
- wired sensors can be included in aspects of the distributed network 10.
- Constrained computing devices 20 as used herein are devices with substantially less persistent and volatile memory other computing devices, sensors in a detection system. Currently examples of constrained devices would be those with less than about a megabyte of flash/persistent memory, and less than 10-20 kbytes of RAM/volatile memory). These constrained devices 20 are configured in this manner; generally due to cost/physical configuration considerations.
- the edge (wirel essly-connected) tier of the network is comprised of highly resource-constrained devices with specific functions. These devices have a small-to-moderate amount of processing power and memory, and often are battery powered, thus requiring that they conserve energy by spending much of their time in sleep mode.
- a typical model is one where the edge devices generally form a single wireless network in which each end-node communicates directly with its parent node in a hub-and-spoke-style architecture.
- the parent node may be, e.g., an access point on a gateway or a sub-coordinator which is, in turn, connected to the access point or another sub-coordinator.
- Each gateway is equipped with an access point (fully functional node or "F" node) that is physically attached to that gateway and that provides a wireless connection point to other nodes in the wireless network.
- the links (illustrated by lines not numbered) shown in FIG. I represent direct (single-hop network layer) connections between devices.
- a formal networking layer (that functions in each of the three tiers shown in FIG. 1) uses a series of these direct links together with routing devices to send messages (fragmented or non- fragmented) from one device to another over the network.
- the WSN 10 implements a state machine approach to an application layer that runs on the lower tier devices 18 and 20. Discussed below is an example of a particular implementation of such an approach. States in the state machine are comprised of sets of functions that execute in coordination, and these functions can be individually deleted or substituted or added to in order to alter the states in the state machine of a particular lower tier device.
- the WSN state function based application layer uses an edge device operating system (not shown, but such as disclosed in the above mentioned provisional application) that allows for loading and execution of individual functions (after the booting of the device ) without rebooting the device (so-called "dynamic
- edge devices could use other operating systems provided such systems allow for loading and execution of indi vidual functions (after the booting of the device) preferable without rebooting of the edge devices.
- the application layer manager 30 is generic in the sense that the application layer manager 30 does not depend upon specific application solution or "business" logic details in the devices that are updated, e.g., devices 18, 20 (lower tier 12c FIG. 1).
- the application layer manager 30 handles "pass-offs" (changes in functions currently operating) from function to function, on, e.g., the nodes, e.g., devices 18, 20. These pass-offs are requested by actual state functions executing in the nodes or devices 18, 20.
- the application layer manager 30 accomplishes such "pass-offs" (changes in functions currently operating) using a transition table (FIG. 4) that serves as a central descriptor for the state functions.
- Inputs to the application layer manager 30 include parsed messages from the network layer via interface 32.
- the application layer manager 30 includes interrupt and polling based inputs via processor peripheral interrupts from interrupt interface 34 and polled sensor/peripheral inputs via interface 36.
- the application layer manager 30 involves characterizing inputs sufficiently to apply rules 38 that dictate changes in configuration, stored data, and/or precipitate message generation.
- the application layer manager 30 has rules 38 and a configuration manager 40 as well as a message generator/parser 42.
- the application layer manager 30 uses network message and sensor processor peripheral based inputs, local data stores 44 (for transition table) and lists, configuration management functions, rules set, and report generation capabilities as shown.
- Edge Application Layer Architecture
- an application module set 50 includes an application layer 50 for the edge devices 18 and 20 (FIG. 1) is shown.
- the application module set 50 includes a layer 52 that is managed by the application layer manager (FIG. 4) and a layer 54 that is not managed by the application layer manager.
- the application layer manager is separate from, e.g., isolated from these other firmware modules used at the edge of the WSN (e.g., wireless web modules, etc. not shown) in order to apply changes in the application layer code without requiring changes to code in these other modules.
- real-time processing of motion ISR and motion filter are not handled by the application layer manager, whereas motion report generator and heart beat generator are handled by the application layer manager.
- the application module set 50 depicted in the example of FIG. 3 includes functions managed by the application layer, e.g., a motion report generator 53a and heartbeat generator 53b that are in communication with a stack 56. Changes to the application lay er 52 are possible by having an understanding of the details of the workings of the application layer 52 without the need to fully understand all of the details of these other isolated mod ules. Thi s is desirable as different groups of individuals and/or systems may be tasked with the coding and maintenance of the respective modules. Also, the application layer 52 is configured in a general way that supports the upgrading of portions of the application layer (e.g., individual business rules, reports, filters, and other functions) without requiring updating of the entire application layer.
- portions of the application layer e.g., individual business rules, reports, filters, and other functions
- FIG. 3 in addition depicts a state diagram among various processes running in the application module set and with interaction with a transition table as set out below.
- FIG. 4 an exemplary situation involving the Application layer manager 50 (A.pp_Mgr()) where there are two states (State 1 with functions A, B, and C, and State 2 with functions D and E) is shown.
- the transition table governs state transitions.
- the transition table shows what state (or states in the case of a nondeterministic finite automaton) a finite semi-automaton or finite state machine will move to, based on the current state of the machine and other inputs.
- a state table is essentially a truth table in which some of the inputs are the current state and the outputs include the next state along with other outputs.
- a state table is one of several ways to specify a state machine, other ways being a state diagram, and a characteristic equation.
- State 1 is the normal state and has an entry point, "Tunc A.” Normally, State 1 executes "Func A” which requests “Func B” which requests execution of "Func C.” In the example, a condition occurs (actual condition is implementation specific and the detail of which is not necessary to understand what follows). Under this situation with the condition occurring State 1 transitions to State 2 when “Func B” requests execution of "Func D” rather than "Func C.” State 2 may exists for only one cycle (D-E-exit) or many cycles (D-E-D-E-...-exit). However, when the exit occurs in this example, it does so without calling any function. By default then, the AppMgr's Idle function runs Func A since it is the entry point function.
- a "typical" application 60 on a motion sensor handles a motion sensor's raw data with an interrupt routine, the motion sensor interrupts directly call a motion filter that maintains its own state and declares, when appropriate, a "motion event" 62.
- the motion event is handled 64 (after perhaps a bit of un- deterministic latency) by a motion report generator that calls a wireless program stack to place the report into that stack's out-going queue.
- the motion report generator waits 66 for an ACK message and re-sends the message, as necessary, until an ACK is received.
- a heartbeat message is generated 68 periodically and placed into the wireless stack out-going message queue, and an ACK is awaited. (Heartbeat messages are not re-submitted after deliver ⁇ ' failure, but a new heartbeat message is not sent until the result of the previou s send is obtained from the wireless stack.)
- the application layer is configured to satisfy the requirement of modularity by defining and linking together different portions of the application layer so that individual portions are updatable over the wireless link without breaking the overall application processing.
- the application layer instantiates 72 an "object” that is a fundamental building block for the application layer "machine,"
- the instantiated object uses an array of function pointers. Each function pointer selves as a “keeper”, e.g., holding of a particular state of the corresponding function.
- the instantiated object also includes a special manager function (application layer manager 30 or "AppMgr") that tracks 74 which function is running in the machine (i.e., which array index value is in effect).
- State transitions are accomplished by the current function transferring function control to a next appropriate function by changing 76 this index value (or asking AppMgr to change the index value.
- the AppMgr is general with "hardwired" business logic residing in the individual state functions, rather than in the AppMgr and individual states are changed by replacing the corresponding function with a new version of that function, transmitted from an external host such as a server or gateway. Making changes to an allowed state transition (either adding a new transition or deleting an old one) is accomplished by replacing the functions that participate in the state with the new functions to perform the state change.
- the AppMgr is configured 78 to actually change the current index value for the current state function, whereas in other implementations the old function directly activates 80 the new function, without using the AppMgrQ as an intermediary.
- AppMgrQ has a mapping 82 of allowed transitions and checks 84 for violations of this mapping (i.e., if a given function fries to pass control to another function and in so doing make a state transition that is not allowed) AppMgrQ will prohibit the change and raise an exception.
- This functionality in AppMgrQ helps to verify that changes to the state machine behavior are valid and that changes to the state machine behavior actually take place, since an error message will be generated by AppMgrQ 86 when an erroneous state change is requested by a function. Othenvise, individual states are changed by replacing the corresponding function with a new version of that function, 88.
- N_i be the "current index" value maintained by AppMgrQ.
- N_i is a global variable that retains its value from one pass through AppMgrQ to the next.
- AppMgr is a root function that is exec uted by a scheduler such as in the operating system running on the edge device. AppMgr runs completely through every few milliseconds. Each time AppMgrQ runs, AppMgr executes the function pointed to by p_AppFunc[N_i].
- the state machine can be implemented as a set of arrays, whereas in more complex implementations the state machine is implemented as a set of functions that are linked through a linked list to allow for an indeterminate number of states in the state machine.
- N_i would change to a different value, say N k so that on the next call of AppMgrQ, a different state would be entered (i.e., p_AppFunc[N_k] would run).
- p_AppFunc[N_k] would run.
- An example of the single-run function would be the sending of a report.
- An example of the multi-run function would be the activity of a sensor filter that acts on raw data from a sensor device.
- the various functions p_AppFunc[i] not only decide when they should request that AppMgrQ make a state change, but these functions indicate what new function(s) (e.g., what new value(s) of N i) AppMgrQ should choose from, as AppMgrQ is configured to be fairly generic and thus all business logic, including the description of transitions between states, is contained in the p AppFunc[] functions.
- the two p_AppFunc[] functions need to have different tasks done at the same time, for example, simultaneously filtering data from two sensors (e.g., de-bouncing a switch and filtering motion data from an accelerometer.
- One general approach to providing an AppMgr is to ran two state functions at a time (execute both with each pass through AppMgr).
- Another approach keeps AppMgr simple and just requires that application states provided with code to make calls to each other and thus invoke each other. That is, p AppFuncfN i] requests execution of p AppFuncfN k] upon termination of execution of p_AppFunc[N_i] and vice versa.
- the two app functions split the time and attention of AppMgr without AppMgr planning for time sharing.
- the various versions of p AppFunc[] are maintained in an executable code repository in the gateway and cloud, and each such function can have an ID number that is used to differentiate one version of a function from another (and in many cases the differences in the generations or versions of the function may be small but important, so getting exactly the right ID number is important).
- ID number used to differentiate one version of a function from another (and in many cases the differences in the generations or versions of the function may be small but important, so getting exactly the right ID number is important).
- the requested change to a different function or state becomes very specific with respect to a code version, therefore it is logical that the parameter used by a function to request a state change (function change) is actually the I D number of the new function.
- a simple way to manage versions is to give App Layer state functions their own file type.
- File type is maintained as one of the fields in the file index in, e.g., flash memory so that the initialization process of Ap MgrQ during bootup searches for files of that type in the flash memory, and produces the array of function pointers, with index i running from 0 to a maximum value, i max.
- AppMgrQ maps each value i to a function
- AppMgrQ a return value of 0x396B. This return value is a request to run the function p_AppFunc[] having the function ID "0x396B.”
- AppMgrQ uses the state table to determine if request to mn p_AppFunc[] having the function ID "0x396B is a transition that is allowed for function ID 0x3 ! C7, and if so, what value of i corresponds to function 0x396B. If it is a valid request, AppMgrQ sets N i equal to the new value of i corresponding to function ID "0x396B and, upon next execution of AppMgrQ, the new function ID "0x396B would run.
- AppMgrQ During initialization of AppMgrQ and the prod ucing of the state table, simple graph analysis algorithms run to ensure that each state is reachable (no states are isolated) and to make sure that all states are part of a single state machine (i.e., there are not two smaller and totally separated sets of states). The state table validation also requires that no state transition can involve a transition to a non-existent function.
- AppMgrQ al ways has a stem state (idle state) with function ID 0x0001 that runs when the index N__i is undefined. Initialization of the state machine is done in a second state (initialize state) with its own generic function, with function ID 0x0000.
- AppMgrQ will re-run function 0x0000 and then transition to state function 0x0001. It is a further requirement that one and only one of the user-supplied functions in the complete function set is identified as the entry state. This is the state called by 0x0001 automatically . From that point on the user-supplied functions request the state changes as part of their return values.
- AppMgr Idle When a function exits with no new function requested, AppMgr Idle will simply run the entry point function again. In some cases with very simple nodes, there may he NO entry function, in which case the idle function will just run itself until an event- initiated function is run.
- State 1 is the normal state and has the entry point, Func A.
- State 2 transitions to State 2 when Func B requests the execution of Func D rather than Func C.
- State 2 may exist for only one cycle (D-E-exit) or many (D-E-D-E- ...-exit), but when exit occurs in this example, it does so without calling any function.
- the AppMgr's Idle function runs Func A since it is the entry point function.
- the nodes may be implemented using any appropriate type of computing device, such as a mainframe work station, a personal computer, a server, a portable computing device, or any other type of intelligent device capable of executing instructions, connecting to a network, and forwarding data packets through the network.
- the nodes can execute any appropriate computer programs to generate, receive, and transmit data packets for use on the network.
- the application layer flexibility discussed above is derived in particular from the use of rules engines in the form of independent software agents or rule implementation modules (independently running functions that check input conditions and react accordingly). See for example the routing/rules messaging discussed in the provisional application mentioned above.
- the application layer dexterity arises (as just one implementation example) from programmable state machine methods with the new element of dynamically loaded "root functions" that embody specific rules (typically one rule for each root function) and are run by the operating system of the end-device according to a function priority established for the system.
- root functions typically one rule for each root function
- These functions can be transmitted to an end-device in small messages (i.e., messages not containing a complete re-statement of the entire executable code base of the device) and installed and ran quickly.
- the resulting edge architecture can support frequent updates.
- FIG. 2 above illustrates a generic application layer with network message and sensor / processor peripheral based inputs, local data stores and lists, configuration management functions, rules set, and report generation capabilities.
- distributed rule engines are denoted by the circle element "R" at individual nodes or collections of nodes.
- Each of the three tiers shown in FIG. 1 e.g., cloud/enterprise, gateway, and edge devices
- Inputs to the application layer include parsed messages from the network layer and processor peripheral interrupts and polled sensor/peripheral input.
- An application management process characterizes inputs sufficiently to apply rules that dictate changes in configuration, stored data, and/or precipitate message generation.
- the rules engines are distributed rule engines (denoted by the circle element "R", mentioned above) at individual nodes or collections of nodes. These distributed rules engines involve the generation of a message that is passed from an output of one device to an input to another device (i.e., an action/deferral) or a rule may determine an action based on a value of the input or a value of several inputs or otherwise a combination of several inputs, other data, and a current configuration of the node.
- FIG. 7 certain rules executed in the network of FIG. 1 are layered or subordinated or distributed.
- a rule can start execution in an application layer of a first one of the tiers discussed above, and the result of that execution produces or causes execution of a rale in an application l ayer of a different one of the three tiers discussed in FIG. 1.
- the servers 14 in the cloud/enterprise tier 12a produce 90 duplicates or modified versions of rules in the server application layer (not shown). These servers 14 in the cloud/enterprise tier 12a distribute 92 these duplicated or modified versions of the rules among application layers (not shown) resident in gateway devices 16 in the middle tier 12b. Likewise, upper layer tiers delegate work to the edge application layer 12c by distributing (depicted also in 92) to the edge layer devices 18, 20 rules to execute.
- the gateway/edge devices that received the duplicated or modified versions of such rules, for execution, the application layer in such devices transfers function control 94 to the received rales by changing index (or asking
- the gateway/edge devices that received the duplicated or modified versions of such rules, execute the duplicated or modified versions of the rules at the received tier and results in the form of reports are generated and returned to the tier determined by the rule.
- Rules in the application layer of the edge layer 12c may be deleted or temporarily suppressed by the actions of the rules distributed from the other layers 96a.
- Rules may take various logical forms, including the relatively simple "if-then" form 96b, reproduced below where the rale to produce a particular entry and generate a report is trigged if an input x is observed:
- rules may involve composite inputs, such as the if-then rule below that operates on inputs a, b, c, over a time period x to trigger an action, such as generate a report. "if a, b, and c have occurred within time x, then generate report y"
- Rules can also be cascaded to execute consecutively on the same or different engines by a first executing rale invoking a second rule 97a-97e, such as the example where when rule 1 is satisfied within a time period x, rule I (or AppMgrQ activates rule 2, to generate a report if rule 2 is satisfied in period x. "if rale 1 has been satisfied within time x, then activate rule 2; if rale 2 is satisfied within time x then generate report y"
- Rules may be simple in form and yet involve relatively complex computations, such as involving a computation from a neural network.
- the distributed rules engines may be implemented using any appropriate type of computing device, such as a mainframe work station, a personal computer, a server, a portable computing device, or any other type of intelligent device capable of executing instructions, connecting to a network, and forwarding data packets through the network.
- the rule engines can execute any appropriate computer programs to generate, receive, and transmit data packets for use on the network.
- FIG. 8 shows an example of a security system having features of the WSN described with respect to FIG. I and having the various functionalities described herein.
- correlation processing receives inputs from certain constrained nodes (although these can also be fully functional nodes). These inputs may include credential information and video information, and the correlation processing may produce correlated results that are sent over the network.
- Context management processing receives inputs from certain constrained nodes (although these can also be fully functional nodes) e.g., credential information and video and grouping information, and performs context processing with results sent over the network.
- the network supports operation of emergency exit indicators; emergency cameras as well as distributed rule processing and rule engine/messaging processing.
- Range extenders are used with e.g., gateways, and a real time location system receives inputs from various sensors (e.g., constrained type) as shown.
- Servers interface to the WSN via a cloud computing conf guration and parts of some networks can be run as sub-nets.
- the sensors provide in addition to an indication that something is detected in an area within the range of the sensors, detailed additional information that can be used to evaluate what that indication may be without the intrusion detection panel being required to perform extensive analysis of inputs to the particular sensor.
- a motion detector could be configured to analyze the heat signature of a warm body moving in a room to determine if the body is that of a human or a pet. Results of that analysis would be a message or data that conveys information about the body detected.
- Various sensors thus are used to sense sound, motion, vibration, pressure, heat, images, and so forth, in an appropriate combination to detect a true or verified alarm condition at the intrusion detection panel.
- Recognition software can be used to discriminate between objects that are a human and objects that are an animal; further facial recognition software can be built into video cameras and used to verify that the perimeter intrusion was the result of a recognized, authorized individual.
- video cameras would comprise a processor and memory and the recognition software to process inputs (captured images) by the camera and produce the metadata to convey information regarding recognition or lack of recognition of an individual captured by the video camera.
- the processing could also alternatively or in addition include information regarding characteristic of the individual in the area captured/monitored by the video camera.
- the information would be either metadata received from enhanced motion detectors and video cameras that performed enhanced analysis on inputs to the sensor that gives characteristics of the perimeter intrusion or a metadata resulting from veiy complex processing that seeks to establish recognition of the object.
- Sensor devices can integrate multiple sensors to generate more complex outputs so that the intrusion detection panel can utilize its processing capabilities to execute algorithms that analyze the environment by building virtual images or signatures of the environment to make an intelligent decision about the validity of a breach.
- the memor ⁇ ' stores program instructions and data used by the processor of the intrusion detection panel.
- the memor ⁇ ' may be a suitable combination of random access memory and read-only memor ⁇ ', and may host suitable program instructions (e.g.
- the stored program instruction may include one or more authentication processes for authenticating one or more users.
- the program instructions stored in the memory of the panel may further store software components allowing network communications and establishment of connections to the data network.
- the software components may, for example, include an internet protocol (IP) stack, as well as driver components for the various interfaces, including the interfaces and the keypad .
- IP internet protocol
- Other software components suitable for establishing a connection and communicating across network will be apparent to those of ordinary skill.
- Program instructions stored in the memory, along with configuration data may control overall operation of the panel.
- the monitoring server includes one or more processing devices (e.g., microprocessors), a network interface and a memory (all not illustrated).
- the monitoring server may physically take the form of a rack mounted card and may be in communication with one or more operator terminals (not shown).
- An example monitoring server is a SUR.GARDTM SG-System III Virtual, or similar system.
- each monitoring server acts as a controller for each monitoring server , and is in communication with, and controls overall operation, of each server.
- the processor may include, or be in communication with, the memory that stores processor executable instructions controlling the overall operation of the monitoring server.
- Suitable software enable each monitoring server to receive alarms and cause appropriate actions to occur.
- Software may include a suitable Internet protocol (IP) stack and applications/clients.
- IP Internet protocol
- Each monitoring server of the central monitoring station may be associated with an IP address and port(s) by which it communicates with the control panels and/or the user devices to handle alarm events, etc.
- the monitoring server address may be static, and thus always identify a particul ar one of monitoring server to the intrusion detection panels.
- dynamic addresses could be used, and associated with static domain names, resolved through a domain name service.
- the network interface card interfaces with the network to receive incoming signals, and may for example take the form of an Ethernet network interface card
- the servers may be computers, thin-clients, or the like, to which received data representative of an alarm event is passed for handling by human operators.
- the monitoring station may further include, or have access to, a subscriber database that includes a database under control of a database engine.
- the database may contain entries corresponding to the various subscriber devices/processes to panels like the panel that are serviced by the monitoring station.
- the processes can be implemented, at least in part, via a computer program product, i.e., a computer program tangibly embodied in one or more tangible, physical hardware storage devices that are computer and/or machine-readable storage devices for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.
- a computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
- a computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a network.
- Actions associated with implementing the processes can be performed by one or more programmable processors executing one or more computer programs to perform the functions of the calibration process. All or part of the processes can be
- FPGA field programmable gate array
- ASIC application-specific integrated circuit
- processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
- a processor will receive instructions and data from a read-only storage area or a random access storage area or both.
- Elements of a computer include one or more processors for executing instructions and one or more storage area devices for storing instructions and data.
- a computer will also include, or be operatively coupled to receive data from, or transfer data to, or both, one or more machine -readable storage media, such as mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks.
- Tangible, physical hardware storage devices that are suitable for embodying computer program instructions and data include all forms of non-volatile storage, including by way of example, semiconductor storage area devices, e.g., EPROM, EEPROM, and flash storage area devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks and volatile computer memory, e.g., RAM such as static and dynamic RAM, as well as erasable memory, e.g., flash memory.
- semiconductor storage area devices e.g., EPROM, EEPROM, and flash storage area devices
- magnetic disks e.g., internal hard disks or removable disks
- magneto-optical disks e.g., magneto-optical disks
- CD-ROM and DVD-ROM disks e.g., RAM such as static and dynamic RAM, as well as erasable memory, e.g., flash memory.
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201580021841.3A CN106796511A (en) | 2014-02-28 | 2015-02-27 | For the distributed rule engine of healthy and strong sensor network |
EP15754909.8A EP3111322B1 (en) | 2014-02-28 | 2015-02-27 | Distributed rules engines for robust sensor networks |
JP2016572358A JP2017508228A (en) | 2014-02-28 | 2015-02-27 | Distributed rules engine for robust sensor networks |
Applications Claiming Priority (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201461946054P | 2014-02-28 | 2014-02-28 | |
US61/946,054 | 2014-02-28 | ||
US201461973962P | 2014-04-02 | 2014-04-02 | |
US61/973,962 | 2014-04-02 | ||
US14/464,070 | 2014-08-20 | ||
US14/464,070 US10152864B2 (en) | 2014-02-28 | 2014-08-20 | Distributed rules engines for robust sensor networks |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2015131012A2 true WO2015131012A2 (en) | 2015-09-03 |
WO2015131012A3 WO2015131012A3 (en) | 2015-11-19 |
Family
ID=54009786
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2015/017924 WO2015131012A2 (en) | 2014-02-28 | 2015-02-27 | Distributed rules engines for robust sensor networks |
Country Status (1)
Country | Link |
---|---|
WO (1) | WO2015131012A2 (en) |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100217651A1 (en) * | 2009-02-26 | 2010-08-26 | Jason Crabtree | System and method for managing energy resources based on a scoring system |
US20120311614A1 (en) * | 2011-06-02 | 2012-12-06 | Recursion Software, Inc. | Architecture for pervasive software platform-based distributed knowledge network (dkn) and intelligent sensor network (isn) |
CN202475489U (en) * | 2011-12-23 | 2012-10-03 | 北京泰克华诚技术信息咨询有限公司 | Wireless sensor network capable for updating program |
-
2015
- 2015-02-27 WO PCT/US2015/017924 patent/WO2015131012A2/en active Application Filing
Also Published As
Publication number | Publication date |
---|---|
WO2015131012A3 (en) | 2015-11-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10854059B2 (en) | Wireless sensor network | |
EP3111322B1 (en) | Distributed rules engines for robust sensor networks | |
Serpanos et al. | Internet-of-things (IoT) systems: architectures, algorithms, methodologies | |
US10084826B1 (en) | Protocol agnostic security by using out-of-band health check | |
CN107426252B (en) | The method and apparatus of web application firewall service is provided | |
US10402221B2 (en) | Preemptive operating system without context switching | |
EP3111621A1 (en) | Rules engine combined with message routing | |
WO2015130639A1 (en) | Wireless sensor network | |
CN114885012A (en) | System access method and system of Internet of things platform | |
WO2015131012A2 (en) | Distributed rules engines for robust sensor networks | |
Dimitrios et al. | Internet of Things (IoT) Systems: Architectures, Algorithms, Methodologies | |
WO2015130641A1 (en) | Context specific management in wireless sensor network | |
Aita | Consistent management of dynamic policies in distributed IoT applications |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15754909 Country of ref document: EP Kind code of ref document: A2 |
|
ENP | Entry into the national phase |
Ref document number: 2016572358 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 20167026931 Country of ref document: KR Kind code of ref document: A |
|
REEP | Request for entry into the european phase |
Ref document number: 2015754909 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2015754909 Country of ref document: EP |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15754909 Country of ref document: EP Kind code of ref document: A2 |