US20190229976A1 - Alert throttling - Google Patents
Alert throttling Download PDFInfo
- Publication number
- US20190229976A1 US20190229976A1 US15/876,162 US201815876162A US2019229976A1 US 20190229976 A1 US20190229976 A1 US 20190229976A1 US 201815876162 A US201815876162 A US 201815876162A US 2019229976 A1 US2019229976 A1 US 2019229976A1
- Authority
- US
- United States
- Prior art keywords
- reporting
- anomalous event
- iot device
- processor
- data center
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000002547 anomalous effect Effects 0.000 claims abstract description 83
- 230000009471 action Effects 0.000 claims abstract description 33
- 230000004044 response Effects 0.000 claims abstract description 19
- 238000000034 method Methods 0.000 claims abstract description 18
- 238000004891 communication Methods 0.000 claims abstract description 17
- 230000001667 episodic effect Effects 0.000 claims abstract description 7
- 239000013598 vector Substances 0.000 claims description 15
- 230000007774 longterm Effects 0.000 claims description 3
- 230000001052 transient effect Effects 0.000 claims description 2
- 238000012544 monitoring process Methods 0.000 claims 1
- 230000008676 import Effects 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 230000008569 process Effects 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 3
- 239000000872 buffer Substances 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 239000007943 implant Substances 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 101100369993 Mus musculus Tnfsf10 gene Proteins 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000010267 cellular communication Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 238000013179 statistical model Methods 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000036962 time dependent Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2823—Reporting information sensed by appliance or service execution status of appliance services in a home automation network
- H04L12/2825—Reporting to a device located outside the home and the home network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0681—Configuration of triggering conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0686—Additional information in the notification, e.g. enhancement of specific meta-data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/215—Flow control; Congestion control using token-bucket
-
- 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
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/30—Services specially adapted for particular environments, situations or purposes
- H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
- H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40208—Bus networks characterized by the use of a particular bus standard
- H04L2012/40215—Controller Area Network CAN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40267—Bus for use in transportation systems
- H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
Definitions
- the present disclosure generally relates to throttling of alerts in Internet-of-Things (IoT) systems.
- IoT Internet-of-Things
- IoT systems typically comprise a network of physical devices, vehicles, consumer devices and appliances and other items which comprise embedded electronics, software, sensors, actuators, network connectivity, and so forth. IoT allows objects to be sensed or controlled remotely across existing network infrastructure, often enabling improved efficiency, accuracy and economic benefit in addition to reduced human intervention.
- IoT technology enables reporting anomalies from IoT devices to data centers. Such anomalies may range from problems which call for minor debugging to problems which, in severe instances, may result in loss of life or limb.
- the ability to report these anomalies in real-time or near real-time may enable a fix to be sent, with appropriate security, over-the-air, to the reporting device. Additionally, similar devices which may also call for the fix, or which may be suspected of requiring the fix, may also be sent the fix, even without those particular devices sending reports of anomalies.
- FIG. 1 is a simplified illustration of a plurality of Internet of Things (IoT) devices operative to communicate with a data center in accordance with an embodiment of the present disclosure
- IoT Internet of Things
- FIG. 2 is a simplified pictorial illustration of an exemplary embodiment of the system of FIG. 1 , in which the IoT devices are connected vehicles;
- FIG. 3 is a simplified depiction of an embodiment of a connected vehicle-data center system in the embodiment depicted in FIG. 2 ;
- FIG. 4 is a depiction of operational functions of a reporting engine of FIG. 3 ;
- FIG. 5 is a flowchart of an exemplary method executed by one of the IoT devices of FIG. 1 .
- Appendix A is an exemplary Python code listing for one embodiment of the data center.
- Appendix B is an exemplary Python code listing for one embodiment of a reporting engine in an IoT device.
- methods, systems, and apparatus are described in which data to be used by a processor is stored in a memory.
- Network communications with a data center are enabled via a network interface.
- the processor maintains a reporting policy for reporting anomalous events to the data center, the reporting policy having at least one rule for determining a reporting action to be taken by the processor in response to an anomalous event.
- the processor further monitors the IoT device for a report of an occurrence of the anomalous event.
- the processor performs the reporting action according to the at least one rule, in response to the report of the occurrence of the anomalous event.
- An episodic update to the reporting policy from the data center may be received at the processor, which modifies the reporting policy in accordance with the update.
- Related methods, systems, and apparatus are also described.
- FIG. 1 is a simplified illustration of a plurality of Internet of Things (IoT) devices 110 A- 110 C which are operative to communicate with a data center in accordance with an embodiment of the present disclosure.
- the system 100 of FIG. 1 comprises the plurality of exemplary IoT devices 110 A- 110 C in communication over a network 120 via a network gateway 130 with a data center 140 .
- the data center 140 comprises a server 150 or other appropriate mechanism for communication with the network gateway 130 .
- the plurality of IoT devices 110 A- 110 C typically have the ability to communicate anomalous events to the data center 140 .
- the data center 140 may be a data center associated with an original equipment manufacturer (OEM).
- OEM original equipment manufacturer
- one of the IoT devices 110 B may be IoT enabled thermostat, then the IoT device 110 B may be able to notify its respective OEM of an anomalous event, for example, a critical failure, which it may be experiencing, via the data center 140 .
- OEM original equipment manufacturer
- one of the IoT devices 110 B may be IoT enabled thermostat, then the IoT device 110 B may be able to notify its respective OEM of an anomalous event, for example, a critical failure, which it may be experiencing, via the data center 140 .
- Such reporting of anomalous events enables the OEM to track and anticipate problems, and where needed, to send appropriate software fixes to the plurality of IoT devices 110 A- 110 C when possible.
- the network 120 may be a local area network (LAN), a wide area network (WAN), or a cellular telephone communication network, for example, a Long-Term Evolution (LTE) network.
- the network may comprise various network components depending on its particular nature.
- a LAN might contain various switches and routers
- a WAN might additionally include edge servers, and so forth, as is known in the art.
- An LTE network might comprise various access network nodes, base stations, and other hardware and software adapted for packet transport in accordance with Evolved Packet Core architecture, as is known in the art.
- FIG. 2 is a simplified pictorial illustration of an exemplary embodiment of the system of FIG. 1 , in which the plurality of IoT devices 110 A- 110 C are connected vehicles 210 A- 210 D. It may be of use to the OEM to receive reports regarding various anomalies from the connected vehicles 210 A- 210 D.
- the various anomalies include, but are not limited to mechanical anomalies, In-Vehicle Network (IVN) anomalies, cyber security anomalies, etc.
- the OEM typically maintains a data center, such as data center 240 , which communicates over a network, such as LTE network 220 with the connected vehicles 210 A- 210 D.
- the data center 240 (hereinafter simply referred to as “the data center 240 ”) to anticipate potential problems in advance.
- the data center 240 typically comprises a server 250 which receives and processes these reports of anomalies.
- anomaly reports might be related to an entire vehicle-model and not to a specific vehicle (e.g. connected vehicle 210 B), and then a large number of reports might be received, and thus the data center 240 might incur significant costs due to usage fees for using the LTE network 220 .
- the release cycle of software updates might be long, since extensive testing is needed before any new software can be delivered to the connected vehicles 210 A- 210 D in the field.
- the data center 240 might be overwhelmed with unneeded reports, since an issue causing the reports is already well-known and is in the process of being resolved.
- FIG. 2 which is described in further detail below with reference to FIG. 3 speaks of a connected vehicle, e.g., the connected vehicles 210 A- 210 D.
- the description herein in terms of connected vehicles 210 A- 210 D is not meant to be limiting, but rather exemplary. Accordingly, it is understood that other embodiments might comprise other IoT devices besides connected vehicles.
- medical implants such as pace makers may also be mobile IoT devices which might, either periodically or episodically, report an anomalous event pertaining to the implant.
- Other IoT devices which are in mobile or ambulatory situations might also implement embodiments of the description herein.
- FIG. 3 is a simplified depiction of an embodiment of a connected vehicle 310 —data center 340 system, in the embodiment depicted in FIG. 2 .
- Connected vehicle 310 corresponds to any of the connected vehicles 210 A- 210 D of FIG. 2
- data center 340 corresponds to the data center 240 of FIG. 2 .
- ECUs electronice control units
- 320 A- 320 N are embedded electronic systems that control one or more of the electrical system or subsystems in a vehicle.
- ECUs 320 A- 320 N Engine Control Module (ECM), Transmission Control Module (TCM), Central Control Module (CCM), Central Timing Module (CTM), General Electronic Module (GEM), Body Control Module (BCM), Suspension Control Module (SCM), and so forth.
- ECM Engine Control Module
- TCM Transmission Control Module
- CCM Central Control Module
- CTM Central Timing Module
- GEM General Electronic Module
- BCM Body Control Module
- SCM Suspension Control Module
- One of the ECUs 320 A- 320 N, in the connected vehicle 310 might detect an anomalous event.
- the one of the ECUs 320 A- 320 N which detected the anomalous event may report the anomalous event to the data center 340 .
- a communications ECU 330 which may comprise hardware and software components, enables the one of the ECUs 320 A- 320 N to report the anomalous event to the data center 340 as described below.
- CAN bus controller area network bus
- the BCM might, under such circumstances send a report to the data center 340 along the lines of the following:
- BCM event: code 2110 : BCM silenced on CAN bus #2, at uptime X2 seconds.
- BCM event: code 2130 : BCM self reset, at uptime X3 seconds.
- the communications ECU 330 comprises an LTE modem 350 , which is adapted for communications with the data center 340 over an LTE communications network, such as the LTE network 220 of FIG. 2 . It is appreciated that in other IoT systems, the LTE modem 350 may be replaced with an appropriate network interface. Additionally, the communications ECU 330 comprises memory 367 and one or more processor 365 . The memory 367 of the communications ECU 330 is operative to store data used by the one or more processor 365 . The memory 367 may comprise Random Access Memory (RAM), where machine readable instructions may reside during runtime, and a secondary memory. The secondary memory may include, for example, a flash memory, or a nonvolatile memory where a copy of the machine readable instructions or software may be stored. The secondary memory may also include ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM).
- RAM Random Access Memory
- the one or more processor 365 typically comprises dedicated hardware logic circuits, in the form of an application-specific integrated circuit (ASIC), field programmable gate array (FPGA), or full-custom integrated circuit, or a combination of such devices.
- ASIC application-specific integrated circuit
- FPGA field programmable gate array
- DSP digital signal processor
- This software may be downloaded to the processor in electronic form, over a network, for example.
- the software may be stored on tangible storage media, such as optical, magnetic, or electronic memory media.
- the one or more processor 365 in combination with the memory 367 is operative as a reporting engine 360 .
- FIG. 4 is a depiction of operational functions of the reporting engine 360 .
- the reporting engine 360 maintains at least one reporting policy 370 for reporting anomalous events to the data center 340 , the at least one reporting policy 370 for determining a reporting action to be taken by the one or more processor 365 in response to an anomalous event of various types, as will be detailed below.
- the at least one reporting policy 370 determines what the reporting engine 360 does for specific types of anomaly report. For example, a grade is assigned to the anomalous event which is reported. The grading may be performed by looking up the anomalous event which is to be reported in a table or matrix containing a list of known anomalous events and their respective grades. The assigning of the grade is not necessarily part of a reporting mechanism or engine. For example, the grade may be assigned by whatever module that raised the anomaly event in question.
- Grades may be applied to the anomaly event on a scale, ranging, for example, from: ⁇ Debug, Informational, Warning, Error, Fatal ⁇ .
- the at least one reporting policy 370 might have one rule for “Debug” grade anomalies, and a second rule for “Error” grade anomalies, and so forth.
- another rule may state that an anomaly event relating to the vehicle entertainment center may wait until a next regularly scheduled report.
- probability is one variable which might be used to set the at least one reporting policy 370 . Other examples will be provided below.
- the data center 340 may modify the at least one reporting policy 370 and then send an updated version of the at least one reporting policy 370 to the reporting engine 360 .
- the data center 340 is notified if the anomaly persists, and can thereby assess how many vehicles are still experiencing the anomaly. Nonetheless, an actual number of LTE cellular sessions initiated in order to continue to report this anomaly, and a workload in the data center 340 for recording these received reports, is accordingly decreased by three orders of magnitude.
- Such a saving is significant in any IoT environment (e.g., the system 100 of FIG. 1 ), but is even more significant in an environment which includes a high cost of reporting associated, in the present embodiment, with cellular network charges.
- the data center 340 may modify the at least one reporting policy 370 and then send an updated version of the at least one reporting policy 370 to the reporting engine 360 .
- the modification may be a modification of the at least one reporting policy 370 with respect to a specific anomaly.
- the modification may be delivered to a connected vehicle 310 which has reported this anomaly but not to other connected vehicles which have not reported the same anomaly.
- the modification may be a modification of the at least one reporting policy 370 which can be delivered to any relevant vehicle (for example, the same model; the same manufacturer; all vehicles which have the same model part which reported the anomaly regardless of vehicle manufacturer, etc.) that connects to the data center 340 for any reason (e.g., to deliver a periodic report).
- any relevant vehicle for example, the same model; the same manufacturer; all vehicles which have the same model part which reported the anomaly regardless of vehicle manufacturer, etc.
- a policy update might be transient, and the reporting policy might be reset to its original state when the vehicle is next turned off and on.
- the policy update might have an expiration date and time.
- the policy update might be permanent, in which case it may be that only the data center 340 or an authorized service center may revoke the permanently modified reporting policy. Accordingly, when connected vehicle 310 reports an anomaly for which the default policy was modified, connected vehicle 310 may also report the modified rule itself. This is because the rule under which the report was made may now affect the way in which the report is treated.
- the data center 340 might want to introduce an additional policy update (e.g., which modifies the rule yet again).
- Table 1 describes various categories of reporting options or rules and reporting actions, which the reporting engine 360 might take in response to the at least one reporting policy 370 that applies to a received anomaly report.
- Updates of policy which are sent to the vehicles 310 are to be verified by reporting engine 360 to be genuine and authentic.
- the policy updates may also be protected against replay-attack by means of an ever-increasing version number or its equivalent as is known in the art. It is appreciated that, by contrast to a software patch or other fix sent to the connected vehicle over the air (or which may be applied at a service center), an update to the at least one reporting policy 370 may be released to the connected vehicle 310 , often after a relatively short process (several hours up to 1-2 days), thus allowing fast response and significant savings in preventing unneeded (and potentially expensive) cellular communication.
- Appendix A is an exemplary Python code listing for one embodiment of the data center 340 .
- Appendix B is an exemplary Python code listing for one embodiment of the reporting engine 360 in an IoT device, such as connected vehicle 310 .
- the token bucket (in general) is a method often implemented in packet switched computer networks and telecommunications networks. Token buckets can be used to check that data transmissions, in the form of packets, conform to defined limits on bandwidth and burstiness (a measure of the unevenness or variations in the traffic flow). Token buckets can also be used as a means for scheduling in order to ensure that the timing of transmissions comply with the limits set for the bandwidth and burstiness.
- the token bucket 380 is based on an analogy of a fixed capacity bucket into which tokens, typically representing an anomaly report, are added. When the bucket is full, the anomaly is either logged by the reporting engine 360 ; reported to the data center 340 ; or another appropriate action may be taken.
- reporting options applies to reporting options which are useful when characteristics of the anomaly to be reported are known a priori, and the OEM or the operator of the data center 340 is able to develop (or has already developed) a statistical model of anomalies in order to determine either ‘the probability or the bucket size for reporting the anomaly.
- an anomalous event may occur which is not known a priori or, alternatively, the statistics for occurrences of said anomalous event may not be known a priori. Accordingly, a rule for reporting the anomalous event may not be associated with the at least one reporting policy 370 .
- determining a root cause of the anomalous event by post processing often requires logging of parameters of interest or a state vector of the connected vehicle 310 (which will be an a priori known list) for further analysis.
- unknown anomalous events occur with state vectors varying significantly between two occurrences. (Note: when the state vector is the same for two occurrences of a previously unknown anomalous event, the anomalous event statistics may then be modeled and calculated a priori).
- the confidence that the anomalous event is legitimate is to be developed at the source (the connected vehicle 310 itself) rather than at the data center 340 .
- the following method may be used in an attempt to determine the root cause of the anomalous event and a subsequent sequence trail of the anomalous event.
- a state vector x (p 1 , p 2 , p 3 , . . . p n ), which constitutes a weighted representation of the parameters of interest is calculated, yielding a pair ⁇ E, x ⁇ . For example, if a vehicle hits a pot hole in a road on its daily commute each day over a series of four days, and this an excessive vibration event, the excessive vibration event may be a previously unknown anomalous event.
- the validity of the event E (which may be used to determine if the anomalous event E is to be logged or not) uses a negative exponential model over time, i.e., confidence is proportional to e ⁇ t .
- a first occurrence of the anomalous event E might be at time to, with a corresponding state vector x 0 .
- a second occurrence of the anomalous event E might be at time t 1 , with a corresponding state vector x 1 .
- Confidence in the validity of the anomalous event is based on the following formula:
- ⁇ 2 (x 1 ⁇ x 0 ) is a variance of the state vectors difference
- ⁇ is an exponent coefficient (as will be discussed below in greater detail).
- the second occurrence of the anomalous event increases the confidence value if the anomalous event occurs again with different parameters of interest. In this way, anomalous events that occur due to steady state errors are filtered out. All of this is to say that the confidence is calculated assuming that the pair ⁇ E, x ⁇ will be substantially the same at each instance of the event E. If the variance (i.e., ⁇ 2 (x 1 ⁇ x 0 )) is large, then confidence in the validity of the event will increase.
- the confidence value of the anomalous event determines the logging priority of the anomalous event and tracking of the anomalous event is stopped in order to conserve resources on the CPU. That is to say, once the threshold is exceeded, the previously unknown event now becomes a known event. On the other hand, if the event does not repeat, it remains “unknown”.
- Validating and throttling, as described above, of an anomalous event which is not known a priori can be controlled by modifying t check , an exponent coefficient (i.e., ⁇ , as mentioned above), state vector element weights (which may be provided by an outside equipment manufacturer or a vehicle designer for each sensor, so, for instance, the brake may have a high weight, and the entertainment center may have a low weight) and the weight of the mean squared operation (i.e., the variance, ⁇ 2 (x 1 ⁇ x 0 )) when calculating the confidence.
- an exponent coefficient i.e., ⁇ , as mentioned above
- state vector element weights which may be provided by an outside equipment manufacturer or a vehicle designer for each sensor, so, for instance, the brake may have a high weight, and the entertainment center may have a low weight
- the weight of the mean squared operation i.e., the variance, ⁇ 2 (x 1 ⁇ x 0 )
- FIG. 5 is a flowchart of an exemplary method executed by one of the IoT devices of FIG. 1 .
- data to be used by a processor is stored in a memory.
- network communications with a data center are enabled via a network interface.
- the processor maintains a reporting policy for reporting anomalous events to the data center, the reporting policy having at least one rule for determining a reporting action to be taken by the processor in response to an anomalous event.
- the IoT device is monitored by the processor for a report of an occurrence of the anomalous event.
- the processor performs the reporting action according to the at least one rule in response to the report of the occurrence of the anomalous event (step 550 ).
- the processor receives an episodic update to the reporting policy from the data center.
- the processor modifies the reporting policy in accordance with the update (step 570 ).
- software components of the embodiments of present disclosure may, if desired, be implemented in ROM (read only memory) form.
- the software components may, generally, be implemented in hardware, if desired, using conventional techniques.
- the software components may be instantiated, for example: as a computer program product or on a tangible medium. In some cases, it may be possible to instantiate the software components as a signal interpretable by an appropriate computer, although such an instantiation may be excluded in certain embodiments of the present disclosure.
- Appendix B is an exemplary Python code listing for one embodiment of a reporting engine in an IoT device, such as the connected vehicles 210 A- 210 D of FIG. 2 :
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Automation & Control Theory (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- The present disclosure generally relates to throttling of alerts in Internet-of-Things (IoT) systems.
- IoT systems typically comprise a network of physical devices, vehicles, consumer devices and appliances and other items which comprise embedded electronics, software, sensors, actuators, network connectivity, and so forth. IoT allows objects to be sensed or controlled remotely across existing network infrastructure, often enabling improved efficiency, accuracy and economic benefit in addition to reduced human intervention.
- The use of IoT technology enables reporting anomalies from IoT devices to data centers. Such anomalies may range from problems which call for minor debugging to problems which, in severe instances, may result in loss of life or limb. The ability to report these anomalies in real-time or near real-time may enable a fix to be sent, with appropriate security, over-the-air, to the reporting device. Additionally, similar devices which may also call for the fix, or which may be suspected of requiring the fix, may also be sent the fix, even without those particular devices sending reports of anomalies.
- The present disclosure will be understood and appreciated more fully from the following detailed description, taken in conjunction with the drawings in which:
-
FIG. 1 is a simplified illustration of a plurality of Internet of Things (IoT) devices operative to communicate with a data center in accordance with an embodiment of the present disclosure; -
FIG. 2 is a simplified pictorial illustration of an exemplary embodiment of the system ofFIG. 1 , in which the IoT devices are connected vehicles; -
FIG. 3 is a simplified depiction of an embodiment of a connected vehicle-data center system in the embodiment depicted inFIG. 2 ; -
FIG. 4 is a depiction of operational functions of a reporting engine ofFIG. 3 ; and -
FIG. 5 is a flowchart of an exemplary method executed by one of the IoT devices ofFIG. 1 . - BRIEF DESCRIPTION OF THE APPENDICES
- The present disclosure will be understood and appreciated more fully from the following detailed description, taken in conjunction with the Appendices in which:
- Appendix A is an exemplary Python code listing for one embodiment of the data center; and
- Appendix B is an exemplary Python code listing for one embodiment of a reporting engine in an IoT device.
- Overview
- In one embodiment, methods, systems, and apparatus are described in which data to be used by a processor is stored in a memory. Network communications with a data center are enabled via a network interface. The processor maintains a reporting policy for reporting anomalous events to the data center, the reporting policy having at least one rule for determining a reporting action to be taken by the processor in response to an anomalous event. The processor further monitors the IoT device for a report of an occurrence of the anomalous event. The processor performs the reporting action according to the at least one rule, in response to the report of the occurrence of the anomalous event. An episodic update to the reporting policy from the data center may be received at the processor, which modifies the reporting policy in accordance with the update. Related methods, systems, and apparatus are also described.
- Reference is now made to
FIG. 1 , which is a simplified illustration of a plurality of Internet of Things (IoT)devices 110A-110C which are operative to communicate with a data center in accordance with an embodiment of the present disclosure. Thesystem 100 ofFIG. 1 comprises the plurality ofexemplary IoT devices 110A-110C in communication over anetwork 120 via anetwork gateway 130 with adata center 140. Thedata center 140 comprises aserver 150 or other appropriate mechanism for communication with thenetwork gateway 130. - The plurality of
IoT devices 110A-110C typically have the ability to communicate anomalous events to thedata center 140. Thedata center 140 may be a data center associated with an original equipment manufacturer (OEM). For example, one of theIoT devices 110B may be IoT enabled thermostat, then theIoT device 110B may be able to notify its respective OEM of an anomalous event, for example, a critical failure, which it may be experiencing, via thedata center 140. Such reporting of anomalous events enables the OEM to track and anticipate problems, and where needed, to send appropriate software fixes to the plurality ofIoT devices 110A-110C when possible. - In
FIG. 1 , thenetwork 120 may be a local area network (LAN), a wide area network (WAN), or a cellular telephone communication network, for example, a Long-Term Evolution (LTE) network. The network may comprise various network components depending on its particular nature. By way of example, a LAN might contain various switches and routers, a WAN might additionally include edge servers, and so forth, as is known in the art. An LTE network might comprise various access network nodes, base stations, and other hardware and software adapted for packet transport in accordance with Evolved Packet Core architecture, as is known in the art. - Reference is now made to
FIG. 2 , which is a simplified pictorial illustration of an exemplary embodiment of the system ofFIG. 1 , in which the plurality ofIoT devices 110A-110C are connectedvehicles 210A-210D. It may be of use to the OEM to receive reports regarding various anomalies from the connectedvehicles 210A-210D. The various anomalies include, but are not limited to mechanical anomalies, In-Vehicle Network (IVN) anomalies, cyber security anomalies, etc. The OEM typically maintains a data center, such asdata center 240, which communicates over a network, such asLTE network 220 with the connectedvehicles 210A-210D. These reports allow the OEM data center 240 (hereinafter simply referred to as “thedata center 240”) to anticipate potential problems in advance. By way of example, if a large pool of vehicles of a particular model experience brake failure after driving 25,000 miles, then brake failure may be anticipated by the OEM/data center 240 in other vehicles of that particular model which are nearing the 25,000 mile mark. Thedata center 240 typically comprises aserver 250 which receives and processes these reports of anomalies. - In some cases, anomaly reports might be related to an entire vehicle-model and not to a specific vehicle (e.g. connected
vehicle 210B), and then a large number of reports might be received, and thus thedata center 240 might incur significant costs due to usage fees for using theLTE network 220. Furthermore, due to safety requirements of the automotive industry, the release cycle of software updates might be long, since extensive testing is needed before any new software can be delivered to the connectedvehicles 210A-210D in the field. In the meantime, if the reported anomaly is frequent and exists in many connectedvehicles 210A-210D, thedata center 240 might be overwhelmed with unneeded reports, since an issue causing the reports is already well-known and is in the process of being resolved. - It is appreciated that the embodiment of
FIG. 2 which is described in further detail below with reference toFIG. 3 speaks of a connected vehicle, e.g., the connectedvehicles 210A-210D. The description herein in terms of connectedvehicles 210A-210D is not meant to be limiting, but rather exemplary. Accordingly, it is understood that other embodiments might comprise other IoT devices besides connected vehicles. By way of example, medical implants such as pace makers may also be mobile IoT devices which might, either periodically or episodically, report an anomalous event pertaining to the implant. Other IoT devices which are in mobile or ambulatory situations might also implement embodiments of the description herein. - Reference is now made to
FIG. 3 , which is a simplified depiction of an embodiment of a connectedvehicle 310—data center 340 system, in the embodiment depicted inFIG. 2 . Connectedvehicle 310 corresponds to any of the connectedvehicles 210A-210D ofFIG. 2 , anddata center 340 corresponds to thedata center 240 ofFIG. 2 . As is known in the art, in automotive systems, electronic control units (ECUs) 320A-320N are embedded electronic systems that control one or more of the electrical system or subsystems in a vehicle. Types of ECU include Engine Control Module (ECM), Transmission Control Module (TCM), Central Control Module (CCM), Central Timing Module (CTM), General Electronic Module (GEM), Body Control Module (BCM), Suspension Control Module (SCM), and so forth. One of the ECUs 320A-320N, in the connectedvehicle 310 might detect an anomalous event. The one of theECUs 320A-320N which detected the anomalous event may report the anomalous event to thedata center 340. Acommunications ECU 330, which may comprise hardware and software components, enables the one of theECUs 320A-320N to report the anomalous event to thedata center 340 as described below. - By way of example, suppose that communication from the BCM to a controller area network bus (the “CAN bus”) is faulty, resulting in communication errors on the CAN bus. In response, the BCM is effectively silenced, and eventually resets. The BCM might, under such circumstances send a report to the
data center 340 along the lines of the following: - BCM event: code 2100: communication errors on CAN bus #2, at uptime=X1 seconds.
BCM event: code 2110: BCM silenced on CAN bus #2, at uptime=X2 seconds.
BCM event: code 2130: BCM self reset, at uptime=X3 seconds. - The
communications ECU 330 comprises anLTE modem 350, which is adapted for communications with thedata center 340 over an LTE communications network, such as theLTE network 220 ofFIG. 2 . It is appreciated that in other IoT systems, theLTE modem 350 may be replaced with an appropriate network interface. Additionally, thecommunications ECU 330 comprisesmemory 367 and one ormore processor 365. Thememory 367 of thecommunications ECU 330 is operative to store data used by the one ormore processor 365. Thememory 367 may comprise Random Access Memory (RAM), where machine readable instructions may reside during runtime, and a secondary memory. The secondary memory may include, for example, a flash memory, or a nonvolatile memory where a copy of the machine readable instructions or software may be stored. The secondary memory may also include ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM). - The one or
more processor 365 typically comprises dedicated hardware logic circuits, in the form of an application-specific integrated circuit (ASIC), field programmable gate array (FPGA), or full-custom integrated circuit, or a combination of such devices. Alternatively, or additionally, some or all of the functions of the processor may be carried out by a programmable processor, such as a microprocessor or digital signal processor (DSP), under the control of suitable software. This software may be downloaded to the processor in electronic form, over a network, for example. Alternatively, or additionally, the software may be stored on tangible storage media, such as optical, magnetic, or electronic memory media. - The one or
more processor 365 in combination with thememory 367 is operative as areporting engine 360. Reference is now additionally made toFIG. 4 , which is a depiction of operational functions of thereporting engine 360. - The
reporting engine 360 maintains at least onereporting policy 370 for reporting anomalous events to thedata center 340, the at least onereporting policy 370 for determining a reporting action to be taken by the one ormore processor 365 in response to an anomalous event of various types, as will be detailed below. The at least onereporting policy 370 determines what thereporting engine 360 does for specific types of anomaly report. For example, a grade is assigned to the anomalous event which is reported. The grading may be performed by looking up the anomalous event which is to be reported in a table or matrix containing a list of known anomalous events and their respective grades. The assigning of the grade is not necessarily part of a reporting mechanism or engine. For example, the grade may be assigned by whatever module that raised the anomaly event in question. - Grades may be applied to the anomaly event on a scale, ranging, for example, from: {Debug, Informational, Warning, Error, Fatal}.
- Thus, the at least one
reporting policy 370 might have one rule for “Debug” grade anomalies, and a second rule for “Error” grade anomalies, and so forth. An initial, default rule might state, for example, that any anomaly report rated “Error” or worse must be reported immediately with probability p=1.0. Other rules may be particular—for example, a rule might state that an anomaly event relating to the brakes with a grade level of Warning or higher must be reported with probability p=1.0. However, another rule may state that an anomaly event relating to the vehicle entertainment center may wait until a next regularly scheduled report. As will be described below, probability is one variable which might be used to set the at least onereporting policy 370. Other examples will be provided below. - However, after receiving a certain number, designated N, of anomaly reports from some large number N of connected vehicles 310 (for example, there might be 1,000,000 vehicles), where all N of the anomaly reports describe a same anomalous phenomenon, the
data center 340 is deemed to be aware of the reported anomalous phenomenon. Accordingly, there is not much point to keep sending more reports describing the same already reported anomalous phenomenon. Thus, thedata center 340 may modify the at least onereporting policy 370 and then send an updated version of the at least onereporting policy 370 to thereporting engine 360. For example, the particular anomaly, which had previous been reported 1,000,000 times to thedata center 340 may now have its associated reporting probability p set to p=0.001. - As a result of modifying the reporting probability p from p=1.0 to p=0.001 the
data center 340 is notified if the anomaly persists, and can thereby assess how many vehicles are still experiencing the anomaly. Nonetheless, an actual number of LTE cellular sessions initiated in order to continue to report this anomaly, and a workload in thedata center 340 for recording these received reports, is accordingly decreased by three orders of magnitude. Such a saving is significant in any IoT environment (e.g., thesystem 100 ofFIG. 1 ), but is even more significant in an environment which includes a high cost of reporting associated, in the present embodiment, with cellular network charges. - It is appreciated that when determining the reporting-probability, p, relative to the number of reports seen, N, the
data center 340 is assured of receiving reports which accurately reflect an up to date status of the relevant anomaly per some target time-period. For example, assuming it is required that thedata center 340 will have an up to date, accurate status per second, and assuming that the number of reports received by thedata center 340 per second is N=1,000,000, it is safe to set the reporting-probability p to 0.001 (as in the example above), but not to 0.000001. This is so in the present example, since an expectation, EX, for the number of vehicles that will experience the anomaly per second is EX=p*N=0.001*1000000=1000. 1000 reports of an anomaly is a reasonably large enough number that thedata center 340 can be assumed to have an accurate assessment of the real status on the basis of these received reports. On the other hand, for p=0.000001, EX=p*N=0.000001*1000000=1, meaning a single vehicle reporting the anomaly each second. This frequency of vehicles reporting anomalies is presumably too small, resulting in a fluctuating and non-accurate status measured at thedata center 340. Since the number of active vehicles changes over time, the probability p may actually be a vector of time-dependent probabilities, designed to ensure that the expectation EX is above some desirable threshold at all times. These figures of the number of active vehicles at different time-windows are usually known from previously gathered statistics, which is not related specifically to the embodiments described herein. - As was noted above, the
data center 340 may modify the at least onereporting policy 370 and then send an updated version of the at least onereporting policy 370 to thereporting engine 360. In some embodiments, the modification may be a modification of the at least onereporting policy 370 with respect to a specific anomaly. In some embodiments the modification may be delivered to aconnected vehicle 310 which has reported this anomaly but not to other connected vehicles which have not reported the same anomaly. Alternatively, the modification may be a modification of the at least onereporting policy 370 which can be delivered to any relevant vehicle (for example, the same model; the same manufacturer; all vehicles which have the same model part which reported the anomaly regardless of vehicle manufacturer, etc.) that connects to thedata center 340 for any reason (e.g., to deliver a periodic report). - In some embodiments, a policy update might be transient, and the reporting policy might be reset to its original state when the vehicle is next turned off and on. Alternatively, the policy update might have an expiration date and time. In other embodiments the policy update might be permanent, in which case it may be that only the
data center 340 or an authorized service center may revoke the permanently modified reporting policy. Accordingly, when connectedvehicle 310 reports an anomaly for which the default policy was modified,connected vehicle 310 may also report the modified rule itself. This is because the rule under which the report was made may now affect the way in which the report is treated. In addition, thedata center 340 might want to introduce an additional policy update (e.g., which modifies the rule yet again). - Table 1, below, describes various categories of reporting options or rules and reporting actions, which the
reporting engine 360 might take in response to the at least onereporting policy 370 that applies to a received anomaly report. -
TABLE 1 REPORTING POLICY REPORTING ACTION Deterministic Report the anomaly immediately Action Log the anomaly, and report when the vehicle connects (for any reason) to the data center 340 Log the anomaly, and report when a scheduled report back session with the data center 340 occurs Log the anomaly, and report when a log buffer reaches its capacity limit Discard the report Probabilistic With probability p, report the anomaly, else discard the Action report With probability p, report the anomaly, else log the report Token Bucket When the token bucket 380 is full, log the anomaly with 380 Action a number of its occurrences, and empty the token bucket (Token bucket 380 with a specific When the token bucket 380 is full, report the anomaly bucket size is with the number of its occurrences and empty the setup - see token bucket 380 explanation below) Vehicle Status Report the anomaly at a specific date and/or time Based Action Report the anomaly when the vehicle is at a specific location (e.g., its home location, or a service center) Report the anomaly when the vehicle is operating at or above (or below) a certain speed Report the anomaly when the vehicle is operating at or above (or below) a certain number of engine rotations per minute Report the anomaly when the vehicle is operating at or above (or below) a certain engine temperature - Table 1 describes a variety of exemplary reporting actions. It is appreciated, however, that the reporting actions might be applied in combination. For example, a first anomaly report might be reported with probability of p=0.01 if the vehicle is operating above a certain speed. Or, a second anomaly report might be reported if either the
token bucket 380 is full, or when a scheduled report back session with thedata center 340 occurs. - Updates of policy which are sent to the
vehicles 310 are to be verified by reportingengine 360 to be genuine and authentic. The policy updates may also be protected against replay-attack by means of an ever-increasing version number or its equivalent as is known in the art. It is appreciated that, by contrast to a software patch or other fix sent to the connected vehicle over the air (or which may be applied at a service center), an update to the at least onereporting policy 370 may be released to theconnected vehicle 310, often after a relatively short process (several hours up to 1-2 days), thus allowing fast response and significant savings in preventing unneeded (and potentially expensive) cellular communication. - Reference is now made to Appendix A, which is an exemplary Python code listing for one embodiment of the
data center 340. - Reference is now made to Appendix B, which is an exemplary Python code listing for one embodiment of the
reporting engine 360 in an IoT device, such asconnected vehicle 310. - Referring back to Table 1, a brief discussion of the
token bucket 380 is now provided. The token bucket (in general) is a method often implemented in packet switched computer networks and telecommunications networks. Token buckets can be used to check that data transmissions, in the form of packets, conform to defined limits on bandwidth and burstiness (a measure of the unevenness or variations in the traffic flow). Token buckets can also be used as a means for scheduling in order to ensure that the timing of transmissions comply with the limits set for the bandwidth and burstiness. - The
token bucket 380, as may be implemented in embodiments described herein, is based on an analogy of a fixed capacity bucket into which tokens, typically representing an anomaly report, are added. When the bucket is full, the anomaly is either logged by thereporting engine 360; reported to thedata center 340; or another appropriate action may be taken. - The above discussion of reporting options applies to reporting options which are useful when characteristics of the anomaly to be reported are known a priori, and the OEM or the operator of the
data center 340 is able to develop (or has already developed) a statistical model of anomalies in order to determine either ‘the probability or the bucket size for reporting the anomaly. - In certain cases, an anomalous event may occur which is not known a priori or, alternatively, the statistics for occurrences of said anomalous event may not be known a priori. Accordingly, a rule for reporting the anomalous event may not be associated with the at least one
reporting policy 370. In such cases, determining a root cause of the anomalous event by post processing often requires logging of parameters of interest or a state vector of the connected vehicle 310 (which will be an a priori known list) for further analysis. Typically, unknown anomalous events occur with state vectors varying significantly between two occurrences. (Note: when the state vector is the same for two occurrences of a previously unknown anomalous event, the anomalous event statistics may then be modeled and calculated a priori). - In order to minimize reporting of false positives for anomalous events, the confidence that the anomalous event is legitimate is to be developed at the source (the
connected vehicle 310 itself) rather than at thedata center 340. The following method may be used in an attempt to determine the root cause of the anomalous event and a subsequent sequence trail of the anomalous event. - A) When an unknown anomalous event E occurs, a state vector x=(p1, p2, p3, . . . pn), which constitutes a weighted representation of the parameters of interest is calculated, yielding a pair {E, x}. For example, if a vehicle hits a pot hole in a road on its daily commute each day over a series of four days, and this an excessive vibration event, the excessive vibration event may be a previously unknown anomalous event.
- B) The validity of the event E (which may be used to determine if the anomalous event E is to be logged or not) uses a negative exponential model over time, i.e., confidence is proportional to e−t. A first occurrence of the anomalous event E might be at time to, with a corresponding state vector x0. A second occurrence of the anomalous event E might be at time t1, with a corresponding state vector x1. Confidence in the validity of the anomalous event is based on the following formula:
-
confidence(t 1)=confidence(t 0)*σ−2(x 1 −x 0)*α*e −t - where σ2 (x1−x0) is a variance of the state vectors difference, and α is an exponent coefficient (as will be discussed below in greater detail). The second occurrence of the anomalous event increases the confidence value if the anomalous event occurs again with different parameters of interest. In this way, anomalous events that occur due to steady state errors are filtered out. All of this is to say that the confidence is calculated assuming that the pair {E, x} will be substantially the same at each instance of the event E. If the variance (i.e., σ2 (x1−x0)) is large, then confidence in the validity of the event will increase. On the other hand, if the state vectors x1 and x0 are similar, then the variance will approach zero, and confidence in the validity of the event will, accordingly, decrease. At a certain point, the confidence will exceed a threshold, as explained below, and the event is considered to be a “valid” event.
- C) If the confidence, as calculated above by the connected
vehicle 310, is greater than the threshold (which might be provided manually or by some higher order analytics), the event is immediately reported to thedata center 340 with its accompanying state vectors. Thus, previously unknown events with varying state vectors can be identified and post processed with higher priority. - D) At time t0+tcheck, the confidence value of the anomalous event determines the logging priority of the anomalous event and tracking of the anomalous event is stopped in order to conserve resources on the CPU. That is to say, once the threshold is exceeded, the previously unknown event now becomes a known event. On the other hand, if the event does not repeat, it remains “unknown”.
- E) Steady state errors will typically have a very low confidence (close to 0) at time t0+tcheck. So, continuing with the above example of the car hitting a pothole, one event is caused per day for the one car. However, if ten thousand cars driving 5 miles have 1000 vibration events in those 5 miles, at a certain point this particular vibration event will pass the threshold, and the event will become known.
- F) Validating and throttling, as described above, of an anomalous event which is not known a priori can be controlled by modifying tcheck, an exponent coefficient (i.e., α, as mentioned above), state vector element weights (which may be provided by an outside equipment manufacturer or a vehicle designer for each sensor, so, for instance, the brake may have a high weight, and the entertainment center may have a low weight) and the weight of the mean squared operation (i.e., the variance, σ2 (x1−x0)) when calculating the confidence.
- Applying the above method for determining the root cause of the anomalous event enables the
data center 340 to use captured state vectors to simulate and understand the unknown anomalous event. - Reference is now made to
FIG. 5 , which is a flowchart of an exemplary method executed by one of the IoT devices ofFIG. 1 . Atstep 510 data to be used by a processor is stored in a memory. Atstep 520 network communications with a data center are enabled via a network interface. Atstep 530, the processor maintains a reporting policy for reporting anomalous events to the data center, the reporting policy having at least one rule for determining a reporting action to be taken by the processor in response to an anomalous event. - At
step 540 the IoT device is monitored by the processor for a report of an occurrence of the anomalous event. The processor performs the reporting action according to the at least one rule in response to the report of the occurrence of the anomalous event (step 550). - At
step 560 the processor receives an episodic update to the reporting policy from the data center. In response to receiving the episodic update, the processor modifies the reporting policy in accordance with the update (step 570). - It is appreciated that software components of the embodiments of present disclosure may, if desired, be implemented in ROM (read only memory) form. The software components may, generally, be implemented in hardware, if desired, using conventional techniques. It is further appreciated that the software components may be instantiated, for example: as a computer program product or on a tangible medium. In some cases, it may be possible to instantiate the software components as a signal interpretable by an appropriate computer, although such an instantiation may be excluded in certain embodiments of the present disclosure.
- It is appreciated that various features of embodiments which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of embodiments which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.
- It will be appreciated by persons skilled in the art that embodiments described herein are not limited by what has been particularly shown and described hereinabove. Rather the scope of embodiments are defined by the appended claims and equivalents thereof:
- Appendix A is an exemplary Python code listing for one embodiment of the data center:
-
#--------------------------------------------------------------- # Name: CV_DataCenter # Purpose: # # Author: # # Created: 21/05/2017 #--------------------------------------------------------------- #!/usr/bin/env python import random from multiprocessing.connection import Listener # Fixed policy def updatePolicy1(msg_id, total_reports): return [1.0,1] # Define an updated policy def updatePolicy(msg_id, total_reports): if total_reports < 10: return [1.0,1] elif total_reports < 20: return [0.5,3] else: return [0.25,5] # Receive all incoming reports and handle them def handleMessages (conn, num_of_msg_types, reports, est_msg_cnts): while True: # Get the message mess_in = conn.recv( ) # Do something based on message received if type(mess_in) == list and len(mess_in) == 4: msg_id = mess_in[0] reports[msg_id] += 1 total_reports = reports[msg_id] batch_size = mess_in[1] ratio = mess_in[2] pbs = mess_in[3] est_msg_cnts[msg_id] += batch_size/ratio #print “Got anomaly #”, msg_id, “count = ”, batch_size, “policy = ”, [ratio,pbs] mess_out = updatePolicy (msg_id, total_reports) conn.send (mess_out) elif type(mess_in) == str and mess_in == ‘close’: break else: print (“Got a bad message = ”, mess_in) def main( ): num_of_msg_types = 10 est_msg_cnts = num_of_msg_types*[0] reports = num_of_msg_types*[0] address = (‘localhost’, 6000) # family is deduced to be ‘AF_INET’ listener = Listener(address, authkey=‘secret password’) conn = listener.accept( ) print ‘Connection accepted from’, listener.last_accepted handleMessages (conn, num_of_msg_types, reports, est_msg_cnts) conn.close( ) listener.close( ) print “\nExecution summary:” print “------------------\n” print “Number of reports received =”, sum(reports) print “Estimated # messages sent (total) =”, sum(est_msg_cnts) print “Estimated # messages sent (details):” print est_msg_cnts if ——name—— == ‘——main——’: main( ) - Appendix B is an exemplary Python code listing for one embodiment of a reporting engine in an IoT device, such as the
connected vehicles 210A-210D ofFIG. 2 : -
#-------------------------------------------------------------------- # Name: Reporting Engine # Purpose: # # Author: # # Created: 21/05/2017 #-------------------------------------------------------------------- #!/usr/bin/env python import time import random from multiprocessing.connection import Client # Initialize policies data structure def initPolicies(num_of_msg_types): return num_of_msg_types*[[1.0,1]] # Initialize message buffers data structure def initMsgBuffs(num_of_msg_types): return num_of_msg_types*[0] # Pick message to send at random def pickMessage(num_of_msg_types): msg_id = random.randint(0,num_of_msg_types-1) return msg_id # Process message - Decide if message is ignored, batched or sent def processMessage (msg_id, policies, msg_buffs): batch_size = 0 # With some probability, the message is discarded if random.random( ) < policies[msg_id][0]: msg_buffs[msg_id] += 1 #Buffer limit reached? if msg_buffs[msg_id] == policies[msg_id][1]: batch_size = msg_buffs[msg_id] msg_buffs[msg_id] = 0 return batch_size # Send all the anomaly reports def sendMessages (conn, num_of_msg_types, policies, msg_buffs): num_of_events = 100000 print “Generating”, num_of_events, “anomaly events\n” for i in xrange(num_of_events): if (i+1)%(num_of_events/10) == 0: print “Anomaly events generated so far:”,i+1, “...” msg_id = pickMessage(num_of_msg_types) batch_size = processMessage (msg_id, policies, msg_buffs) if batch_size > 0: # Message includes: msg-id, count, current policy mess_out = [msg_id,batch_size,policies[msg_id][0],policies[msg_id][1]] conn.send(mess_out) mess_in = conn.recv( ) #Updating policy policies[msg_id] = mess_in # Flush all remaining reports def flushMessages (conn, num_of_msg_types, policies, msg_buffs): print “\nFlushing buffered anomaly events” for msg_id in xrange(num_of_msg_types): batch_size = msg_buffs[msg_id] if batch_size > 0: # Message includes: msg-id, count, current policy mess_out = [msg_id,batch_size,policies[msg_id][0],policies[msg_id][1]] conn.send(mess_out) mess_in = conn.recv( ) def main( ): num_of_msg_types = 10 policies = initPolicies (num_of_msg_types) msg_buffs = initMsgBuffs (num_of_msg_types) address = (‘localhost’, 6000) conn = Client(address, authkey=‘secret password’) sendMessages(conn, num_of_msg_types, policies, msg_buffs) flushMessages (conn, num_of_msg_types, policies, msg_buffs) conn.send(‘close’) conn.close( ) print “Done!” if ——name—— == ‘——main——’: main( )
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/876,162 US11777785B2 (en) | 2018-01-21 | 2018-01-21 | Alert throttling |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/876,162 US11777785B2 (en) | 2018-01-21 | 2018-01-21 | Alert throttling |
Publications (2)
Publication Number | Publication Date |
---|---|
US20190229976A1 true US20190229976A1 (en) | 2019-07-25 |
US11777785B2 US11777785B2 (en) | 2023-10-03 |
Family
ID=67299569
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/876,162 Active 2039-07-04 US11777785B2 (en) | 2018-01-21 | 2018-01-21 | Alert throttling |
Country Status (1)
Country | Link |
---|---|
US (1) | US11777785B2 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2023200526A1 (en) * | 2022-04-15 | 2023-10-19 | Qualcomm Incorporated | Managing transmission of misbehavior reports |
US11908253B2 (en) * | 2018-12-12 | 2024-02-20 | Gm Cruise Holdings Llc | Dynamic data preservation based on autonomous vehicle performance needs |
Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020119427A1 (en) * | 2001-02-23 | 2002-08-29 | Hewlett-Packard Company | Trusted computing environment |
US20060003689A1 (en) * | 2004-05-17 | 2006-01-05 | Pointshot Wireless Inc. | Qualitative determination of system health in centralized network management |
US20070073740A1 (en) * | 2005-09-29 | 2007-03-29 | Kirshenbaum Evan R | Retrieving a value associated with a property based on a hierarchy of components |
US20080052395A1 (en) * | 2003-02-28 | 2008-02-28 | Michael Wright | Administration of protection of data accessible by a mobile device |
US20080133732A1 (en) * | 2006-12-01 | 2008-06-05 | Fujitsu Limited | Operation Management System and Method for Network-Connected Apparatus, and Agent for Apparatus Operation Management |
US20090033515A1 (en) * | 2007-07-31 | 2009-02-05 | Craig Cavanaugh | Real-time event notification |
US20100082513A1 (en) * | 2008-09-26 | 2010-04-01 | Lei Liu | System and Method for Distributed Denial of Service Identification and Prevention |
US20100229236A1 (en) * | 2009-02-08 | 2010-09-09 | Rybak Michal Andrzej | Method and system for spam reporting with a message portion |
US20110141915A1 (en) * | 2009-12-14 | 2011-06-16 | Choi Hyoung-Kee | Apparatuses and methods for detecting anomalous event in network |
US20120106329A1 (en) * | 2010-10-27 | 2012-05-03 | Futurewei Technologies, Inc. | System and Method for Machine-to-Machine Application Based Congestion Control |
US20120254947A1 (en) * | 2011-03-31 | 2012-10-04 | International Business Machines Corp. | Distributed Real-Time Network Protection for Authentication Systems |
US20150071074A1 (en) * | 2013-09-12 | 2015-03-12 | Oracle International Corporation | Methods, systems, and computer readable media for regulation of multi-priority traffic in a telecommunications network |
US20150106324A1 (en) * | 2013-10-11 | 2015-04-16 | Accenture Global Services Limited | Contextual graph matching based anomaly detection |
US20150195145A1 (en) * | 2014-01-06 | 2015-07-09 | Cisco Technology, Inc. | Scheduling a network attack to train a machine learning model |
US20150304437A1 (en) * | 2014-04-16 | 2015-10-22 | Facebook, Inc. | Location-Based Content Promotion on Online Social Networks |
US20170026295A1 (en) * | 2014-04-03 | 2017-01-26 | Zhongxing Microelectronics Technology Co. Ltd | Method and apparatus for limiting rate by means of token bucket, and computer storage medium |
US20170084147A1 (en) * | 2014-12-30 | 2017-03-23 | Google Inc. | Premises management system with prevention measures |
US9712549B2 (en) * | 2015-01-08 | 2017-07-18 | Imam Abdulrahman Bin Faisal University | System, apparatus, and method for detecting home anomalies |
US20180091327A1 (en) * | 2016-09-24 | 2018-03-29 | Apple Inc. | Anomaly Detection By Resident Device |
US20180183832A1 (en) * | 2016-12-22 | 2018-06-28 | Kung-Wei Chang | Security routing system for use in iot apparatus |
US20180324636A1 (en) * | 2017-05-03 | 2018-11-08 | Subhasis Laha | Dynamic policy based control for autonomous transmission of data by iot or non-iot device |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7626940B2 (en) | 2004-12-22 | 2009-12-01 | Intruguard Devices, Inc. | System and method for integrated header, state, rate and content anomaly prevention for domain name service |
US7606149B2 (en) | 2006-04-19 | 2009-10-20 | Cisco Technology, Inc. | Method and system for alert throttling in media quality monitoring |
US8863256B1 (en) | 2011-01-14 | 2014-10-14 | Cisco Technology, Inc. | System and method for enabling secure transactions using flexible identity management in a vehicular environment |
US8738583B2 (en) | 2011-02-09 | 2014-05-27 | Cisco Technology, Inc. | Efficiently delivering event messages using compiled indexing and paginated reporting |
WO2014171999A2 (en) * | 2013-02-04 | 2014-10-23 | Vanderbilt University | Method and system for high-accuracy differential tracking of global positioning system (gps) receivers |
US10257729B2 (en) * | 2013-03-15 | 2019-04-09 | DGS Global Systems, Inc. | Systems, methods, and devices having databases for electronic spectrum management |
US10244504B2 (en) * | 2013-03-15 | 2019-03-26 | DGS Global Systems, Inc. | Systems, methods, and devices for geolocation with deployable large scale arrays |
US10271233B2 (en) * | 2013-03-15 | 2019-04-23 | DGS Global Systems, Inc. | Systems, methods, and devices for automatic signal detection with temporal feature extraction within a spectrum |
WO2015055259A1 (en) | 2013-10-18 | 2015-04-23 | Telefonaktiebolaget L M Ericsson (Publ) | Classification of detected network anomalies using additional data |
US20180205755A1 (en) * | 2017-01-19 | 2018-07-19 | University Of North Texas | Systems and methods for adaptive vulnerability detection and management |
-
2018
- 2018-01-21 US US15/876,162 patent/US11777785B2/en active Active
Patent Citations (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020119427A1 (en) * | 2001-02-23 | 2002-08-29 | Hewlett-Packard Company | Trusted computing environment |
US20080052395A1 (en) * | 2003-02-28 | 2008-02-28 | Michael Wright | Administration of protection of data accessible by a mobile device |
US20060003689A1 (en) * | 2004-05-17 | 2006-01-05 | Pointshot Wireless Inc. | Qualitative determination of system health in centralized network management |
US20070073740A1 (en) * | 2005-09-29 | 2007-03-29 | Kirshenbaum Evan R | Retrieving a value associated with a property based on a hierarchy of components |
US20080133732A1 (en) * | 2006-12-01 | 2008-06-05 | Fujitsu Limited | Operation Management System and Method for Network-Connected Apparatus, and Agent for Apparatus Operation Management |
US20090033515A1 (en) * | 2007-07-31 | 2009-02-05 | Craig Cavanaugh | Real-time event notification |
US20100082513A1 (en) * | 2008-09-26 | 2010-04-01 | Lei Liu | System and Method for Distributed Denial of Service Identification and Prevention |
US20100229236A1 (en) * | 2009-02-08 | 2010-09-09 | Rybak Michal Andrzej | Method and system for spam reporting with a message portion |
US20110141915A1 (en) * | 2009-12-14 | 2011-06-16 | Choi Hyoung-Kee | Apparatuses and methods for detecting anomalous event in network |
US20120106329A1 (en) * | 2010-10-27 | 2012-05-03 | Futurewei Technologies, Inc. | System and Method for Machine-to-Machine Application Based Congestion Control |
US20120254947A1 (en) * | 2011-03-31 | 2012-10-04 | International Business Machines Corp. | Distributed Real-Time Network Protection for Authentication Systems |
US20150071074A1 (en) * | 2013-09-12 | 2015-03-12 | Oracle International Corporation | Methods, systems, and computer readable media for regulation of multi-priority traffic in a telecommunications network |
US20150106324A1 (en) * | 2013-10-11 | 2015-04-16 | Accenture Global Services Limited | Contextual graph matching based anomaly detection |
US20150195145A1 (en) * | 2014-01-06 | 2015-07-09 | Cisco Technology, Inc. | Scheduling a network attack to train a machine learning model |
US20170026295A1 (en) * | 2014-04-03 | 2017-01-26 | Zhongxing Microelectronics Technology Co. Ltd | Method and apparatus for limiting rate by means of token bucket, and computer storage medium |
US20150304437A1 (en) * | 2014-04-16 | 2015-10-22 | Facebook, Inc. | Location-Based Content Promotion on Online Social Networks |
US20170084147A1 (en) * | 2014-12-30 | 2017-03-23 | Google Inc. | Premises management system with prevention measures |
US9712549B2 (en) * | 2015-01-08 | 2017-07-18 | Imam Abdulrahman Bin Faisal University | System, apparatus, and method for detecting home anomalies |
US20180091327A1 (en) * | 2016-09-24 | 2018-03-29 | Apple Inc. | Anomaly Detection By Resident Device |
US20180183832A1 (en) * | 2016-12-22 | 2018-06-28 | Kung-Wei Chang | Security routing system for use in iot apparatus |
US20180324636A1 (en) * | 2017-05-03 | 2018-11-08 | Subhasis Laha | Dynamic policy based control for autonomous transmission of data by iot or non-iot device |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11908253B2 (en) * | 2018-12-12 | 2024-02-20 | Gm Cruise Holdings Llc | Dynamic data preservation based on autonomous vehicle performance needs |
WO2023200526A1 (en) * | 2022-04-15 | 2023-10-19 | Qualcomm Incorporated | Managing transmission of misbehavior reports |
Also Published As
Publication number | Publication date |
---|---|
US11777785B2 (en) | 2023-10-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN115225519B (en) | Using machine learning to monitor link quality and predict link failure | |
CN109802941A (en) | A kind of login validation method, device, storage medium and server | |
US8069236B2 (en) | Flow control of events based on threshold, grace period, and event signature | |
CN110719299A (en) | Honeypot construction method, device, equipment and medium for defending network attack | |
US11777785B2 (en) | Alert throttling | |
JPWO2019102911A1 (en) | Abnormal communication detection device, abnormal communication detection method, program | |
CN110837432A (en) | Method and device for determining abnormal node in service cluster and monitoring server | |
CN106656636A (en) | Cloud platform fault detection method and device | |
CN112732560B (en) | Method and device for detecting leakage risk of file descriptor | |
CN111953635A (en) | Interface request processing method and computer-readable storage medium | |
US20150277892A1 (en) | Multi-phase software delivery | |
CN111181897A (en) | Attack detection model training method, attack detection method and system | |
US8904533B2 (en) | Determining heavy distinct hitters in a data stream | |
Xiao et al. | A quantitative study of accountability in wireless multi-hop networks | |
CN110460486A (en) | The monitoring method and system of service node | |
CN107005433B (en) | Flow table entry timing processing method and device | |
CN110515782A (en) | Test method, test device and the test macro of server | |
US11770328B2 (en) | Network including data integrity monitoring | |
CN113079063A (en) | Offline judgment method, system and device for charging device and computer storage medium | |
CN112929347A (en) | Frequency limiting method, device, equipment and medium | |
CN110430118B (en) | Bill mail managing method, apparatus, computer device and computer readable storage medium | |
Radanovic et al. | Limiting the influence of low quality information in community sensing | |
CN113872978B (en) | DNS hijacking monitoring method and device and electronic equipment | |
WO2022176128A1 (en) | Analysis device, analysis system, analysis method and analysis program | |
CN111711537B (en) | Method, device and equipment for updating standby main node list |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DHESIKAN, SUBHASRI;SUDHAAKAR, RAGHURAM S.;HOLCOMB, KEVIN;AND OTHERS;SIGNING DATES FROM 20180110 TO 20180121;REEL/FRAME:044683/0641 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
AS | Assignment |
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SUDHAAKAR, RAGHURAM S.;REEL/FRAME:051803/0583 Effective date: 20200207 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT VERIFIED |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
CC | Certificate of correction |