Method and system for dynamic data collection and context driven actions

Abstract

A method at an analysis module on a computing device, the analysis module being located at a layer in a hierarchical structure of analysis modules and data sources, the method comprising receiving a first dataset from a data source or a lower-level analysis module; analyzing the first dataset to create a second dataset; providing the second dataset to at least one higher-level analysis module, the second dataset being derived from the first dataset; and providing at least one of inference and blocking to a lower-level analysis module.

Description

Technical Field

[0001] This disclosure relates to data collection and processing, and more particularly to multi-layered data collection and constructing context-dependent actions or responses derived from the data. Background Technology

[0002] Modern systems can have multiple sensors that provide a wealth of data about the system. For example, in a vehicle, such sensors can provide information about vehicle operation. The data might relate to the vehicle's physical characteristics, such as tire pressure, battery performance, vibration, position, and so on. Other data might relate to how the vehicle is driven and could include data from accelerator, brake pedal, and steering wheel sensors, LiDAR and RADAR readings, and so on.

[0003] Similar systems exist in other fields. For example, Internet of Things (IoT) systems can include smart homes, where various devices (such as thermostats, refrigerators, alarms, etc.) all provide data. Such data can include, for example, temperature readings, temperature change readings, content information (such as when milk supplies are low), air quality readings (such as the amount of allergens in a room), alarm data when water or smoke is detected, and so on.

[0004] The data and sensor readings from these systems can be used for a variety of functions. For example, in the case of a vehicle, such readings can be used in the model to infer the driver's identity or predict which components may fail. In IoT systems, readings can be used in the model to provide alerts about component failures or potential issues in the home. These determinations can lead to associated actions (or blocks) or notifications based on numerous sensor readings within the system, and can also be based on reports from across many systems.

[0005] However, for data from various sensors or components to be useful, the system needs to interpret this data in a correct and meaningful way. In a vehicle or IoT environment, each manufacturer of the various components of the system may provide different sensors, or similar sensors with different reading calibrations. This can make reading and interpreting the data difficult. Attached Figure Description

[0006] This disclosure will be better understood with reference to the accompanying drawings, in which:

[0007] Figure 1 This is a block diagram illustrating an example system of analytics modules that spans both on-site and remote network deployments;

[0008] Figure 2 This is a block diagram showing an example vehicle system;

[0009] Figure 3 It is a block diagram illustrating the deployment of the vehicle system and its communication with network services;

[0010] Figure 4 This is a block diagram of an example Internet of Things system that can be used with embodiments of this disclosure;

[0011] Figure 5 This is a block diagram of an Internet of Things (IoT) deployment utilizing embodiments of the present disclosure;

[0012] Figure 6 This is a flowchart illustrating the process at an analysis module; and

[0013] Figure 7 This is a block diagram of an example computing device or server that can be used with embodiments of the present disclosure. Detailed Implementation

[0014] This disclosure provides a method at an analysis module on a computing device, the analysis module being located at a layer in a hierarchical structure of analysis modules and data sources, the method comprising: receiving a first dataset from a data source or a lower-level analysis module; analyzing the first dataset to create a second dataset; providing the second dataset to at least one higher-level analysis module, the second dataset being derived from the first dataset; and providing at least one of inference and blocking to a lower-level analysis module.

[0015] This disclosure also provides a computing device including an analysis module located at a layer in a hierarchical structure of analysis modules and data sources. The computing device includes: a processor; and a communication subsystem, wherein the computing device using the analysis module is configured to: receive a first dataset from a data source or a lower-level analysis module; analyze the first dataset to create a second dataset; provide the second dataset to at least one higher-level analysis module, the second dataset being derived from the first dataset; and provide at least one of inference and blocking to a lower-level analysis module.

[0016] This disclosure also provides a computer-readable medium for storing instruction code, including an analysis module located at a layer in a hierarchical structure of analysis modules and a data source, the instruction code, when executed by a processor of a computing device, causing the computing device to: receive a first dataset from a data source or a lower-level analysis module; analyze the first dataset to create a second dataset; provide the second dataset to at least one higher-level analysis module, the second dataset being derived from the first dataset; and provide at least one of inference and blocking to a lower-level analysis module.

[0017] According to embodiments of this disclosure, a cluster array of data collectors is provided that aggregates data from upstream integrated sensors into a hierarchical structure of analysis processors or modules. At the lowest level, the data collectors gather data from the sensors and send it to the lowest-level analysis, typically located close to the sensors. Such sensors may be found, for example, in one or more electronic control units (ECUs) of a vehicle, or in IoT devices found in a home, hospital, or other similar environment.

[0018] The data can then be sent to higher-level analysis, and so on.

[0019] Each level of analytics processor (or module) provides insights, context, and values, and then passes the data or augmented dataset to the next level of analytics processor.

[0020] In this way, a hierarchical structure is built for the analytics and rules engines to analyze sensor information and lower-level analytics. The analytics modules closest to the sensors are referred to as the lowest level in this paper, while those in large data centers may be at the highest level. In this way, the data available for large data centers is likely to be the largest and may come from many systems, such as many vehicles from many fleets. This allows the highest-level analytics modules to make decisions based on the broadest and / or most comprehensive view of the data.

[0021] Conversely, response times from lower-level analysis modules offer faster blocking, but may provide less information.

[0022] According to this disclosure, a blocker is a module capable of performing actions under the command of an analysis system to influence the behavior of the system. Therefore, for example, in a vehicle system, a blocker can be a module that controls vehicle acceleration or braking, can control an infotainment system by providing alarms or visual notifications, can cut off ignition, and so on.

[0023] Many factors need to be considered when determining whether to take action. The process of determining whether to take action can be done in-place within the system, such as at the vehicle itself, or in the cloud or other network environments. Where the action occurs can be based on various factors, such as security, availability, speed, and whether the operation applies to a single system or multiple systems. Blocking can be rule-based or based on machine learning (ML). Even the decision of what data to use to make the decision can be variable.

[0024] With so many variables, data-driven analysis and decision-making are processor-intensive.

[0025] Therefore, according to embodiments of this disclosure, feedback is provided to lower-level analysis modules that can filter or concentrate data provided to higher-level analysis. As used herein, data filtering feedback indicates that higher-level analysis modules can notify lower-level modules that the higher-level modules require less data or, in some cases, more data to allow lower-level data analysis modules to effectively filter the data.

[0026] In this way, the system can gradually become more efficient over time. Specifically, by identifying the key factors for making decisions and then removing other factors from the data the system is processing, the system can become more efficient.

[0027] Furthermore, by identifying where decisions can be made closer to the data source and then configuring analytics closer to the source to take over decision-making, the system can gradually become more efficient over time.

[0028] In some other embodiments, filtering decisions can also be made at lower levels. Specifically, a lower-level analysis module may notice excessive noise in the data that prevents it from making an effective decision, thus delegating the decision-making authority back to a higher level.

[0029] Now to Figure 1 For reference, a simplified block diagram of this system is shown. Specifically, Figure 1 The deployments shown are in-situ 110 deployments and data center 112 deployments, each containing various elements. For example, an in-situ 110 deployment could be a vehicle deployment, a smart home deployment, a hospital deployment, a factory deployment, a commercial deployment, and so on.

[0030] Multiple sensors 120 can provide data to multiple analysis modules 130. Sensors 120 can be any sensor capable of providing data. In a vehicle environment, such sensors may include position, pressure, vibration, infotainment, ignition, or other sensors associated with the vehicle.

[0031] Analysis module 130 in Figure 1 In this embodiment, it is shown as a distributed engine. Specifically, the analytics module 130 includes multiple analytics modules that can be distributed in a hierarchical manner, with some analytics modules deployed in-situ at 110 and others in the cloud or data center 112.

[0032] Data from sensor 120 is passed up through the hierarchical structure of analysis module 130 to analysis repository 140 within data center 112. For example, using machine learning, feature selection can identify which data is useful and which may be redundant, thereby modifying the data flow to the various analysis modules for future processing.

[0033] Various configuration information can be provided back to the analysis module 130, for example, through the configuration module 150.

[0034] The analysis module can also control blocking. Specifically, multiple blockers 122 exist in place 110. Blockers can control physical or computational processes. For example, in a vehicle environment, a blocker can limit acceleration or cause braking. In a computing environment, a blocker can allow blocking such as closing processes, removing files, closing network ports, restarting or resuming processes, etc. Blockers 122 communicate with a notification module 132 that can be deployed across data center 112 and in place 110.

[0035] For example, data from the brake sensors can be reported periodically each time the brake is engaged and during engagement. The analysis module 130 can determine that only every five measurement cycles are used to determine the blockage, and this information can be relayed back to the sensor control, thereby reducing the reporting frequency and effectively filtering the data generated by the sensors.

[0036] Additional data from other sensors, or combinations of data from different sensors, can also be used for blocking.

[0037] Therefore, the aforementioned feedback loop can lead to a reduction in reporting. Specifically, at the start of system installation, sensors can send all data to all analysis modules. As the system continues to operate, inferences are made, and the analysis modules can report features back to the sensor framework or lower-level analysis modules regarding those features being used and those not being used. The data collector, including the sensors and / or analysis modules, can then infer the needs of the analysis modules and determine that some data is irrelevant. In this case, lower-level modules can construct a summarized / characterized view of the data flow. For example, a module might summarize 10,000 events into a single event, "a tire is losing pressure," to reduce the communication and processing load. Such lower-level sensors and / or analysis modules can then filter out this data before passing it to higher-level analysis modules to improve efficiency.

[0038] Efficiency is not defined solely in terms of bandwidth in this disclosure. Processing unnecessary data can also slow down the analysis module, and response speed can be a significant factor in various systems, such as vehicle systems.

[0039] Beyond filtering relevant data, lower-level analysis modules can handle more inference and the resulting blocking and notification. Specifically, assuming lower-level analysis modules have access to relevant data, higher-level analysis modules can send the feature set used to obtain inferences to lower-level analysis modules. Therefore, the higher layer can inform the lower layer how to characterize / summarize the event sequence, as the lower layer might not be able to interpret such a sequence without this input. This is referred to as inference delegation in this disclosure.

[0040] Lower-level analytics modules can then take over the task of finding those features and making inferences. By providing the data needed to make these inferences available to the lower levels, these inferences will be faster, thus leading to faster response times in some cases, and further freeing up higher-level analytics to look at more complex inferences.

[0041] In this way, by using detection-based machine learning, features can be selected from many reported features, and blocking can be customized based on these features.

[0042] Furthermore, even in rule-based systems rather than machine learning systems, it may not be necessary to predefine rules, and the rules can be dynamically updated based on data feedback from machine learning algorithms. Therefore, such systems can use data intelligence to discover and dynamically extract a context-aware set of features from one or more given data streams. The system then derives a model from those extracted features to infer the likelihood of values ​​occurring based on observations of previous iterations of the stream.

[0043] Vehicle examples

[0044] Extend Figure 1 Summary Figure 2 A high-level overview of the vehicle system is shown. Figure 2 In the example, the vehicle computing system 210 includes multiple sensors. In some cases, such sensors may be associated with an electronic control unit (ECU). For example, in Figure 2 In one embodiment, a plurality of driver sensor units 220 are shown, each having a sensor 222. Such sensors may include sensors associated with the seat, mirrors, accelerator, brake pedal, vehicle position (such as Global Navigation Satellite System (GNSS)), steering wheel sensors, weight sensors, pressure sensors on the steering wheel, and so on.

[0045] In addition, such as Figure 2 As seen in the embodiments, the blocker 224 may be associated with the driver sensor unit 220 and may allow certain actions to be taken, such as disabling the accelerator, activating the braking system, etc.

[0046] In other cases, the sensor may include a key sensor unit 230, which may include an ignition or key sensor 232. In some cases, the key sensor unit 230 may sense a code or password or a mobile device. Furthermore, the blocker 234 may allow the key to be disabled to effectively lock the vehicle.

[0047] In other cases, the in-vehicle infotainment (IVI) unit 240 includes sensors 242 associated with the infotainment system. For example, this could include Bluetooth for pairing with external devices such as mobile phones. TM Transceiver. In other cases, sensor 242 may include information about which radio station the driver has tuned to, whether the driver is using a CD player or media streaming device, including the identity of such device, equalizer settings for the vehicle's audio system, etc. In other cases, sensor 242 may provide information about in-vehicle climate control settings. Other options for sensor 242 are also possible.

[0048] The blocker 244 associated with the IVI unit 240 can allow voice commands or prompts to be made through the infotainment system, and place visual indicators on the infotainment system, such as messages displayed to the driver on the console.

[0049] Data collector 250 can collect data from various systems. Controller 252 can also control interruptors within various sensor systems.

[0050] Data from data collector 250 may optionally flow via data repeater 254 to one or more processors 260 having one or more analysis modules. Processors 260 using the one or more analysis modules can make inferences and decisions about what action (if any) to perform. In some cases, such actions can be transmitted from processor 260 to controller 252.

[0051] In some embodiments, processor 260 may use communication subsystem 264 to communicate with network element 280 and / or network element 290 via network 270. Network elements 280 and 290 may be any server or cloud service. For example, network element 280 may be a fleet management center, a vehicle manufacturer's data center, a component manufacturer's data center, etc.

[0052] Each element in network elements 280 and 290 may have one or more analysis modules. Figure 2 In the example, network element 280 includes analysis module 282, and network element 290 includes analysis modules 292 and 294. However, this is provided only as an example, and more or fewer analysis modules may exist within the system.

[0053] In some cases, network 270 may be, for example, the Internet. In other cases, network 270 may be any wired or wireless network capable of communicating with the vehicle's computing system. For example, in some cases, the network may include a wired system associated with a charging port on an electric vehicle. In other cases, if the vehicle is near a building or house with a known Wi-Fi router, the network may include short-range wireless communication, such as a Wi-Fi network. Other options are possible.

[0054] Therefore, the communication subsystem 264 can be any communication mechanism that allows wired or wireless communication with the network 270, including Ethernet, Wi-Fi, Near Field Communication (NFC), Infrared Data Association (iRDA), cellular communication, satellite communication, and so on. The structure of the communication subsystem 264 depends on the type of communication that the subsystem will perform.

[0055] According to this disclosure, the multi-layered structure of the analytics engine can provide optimizations in data analysis and processing by customizing data flow to higher layers and pushing instructions to lower layers, thereby accelerating processing or handling situations where network connectivity may be interrupted. In this regard, now... Figure 3 For reference, it shows an example of a hierarchical structure for the analytics engine and data source.

[0056] exist Figure 3 In the example, vehicle 310 may consist of many components. Parties including drivers, vehicle owners (such as fleet owners), vehicle manufacturers, specific component manufacturers, and in some cases regulatory agencies such as the Transportation Security Administration (TSA) may be interested in determining the health status of one or more components and may take action, if necessary, to prevent component failure and to make decisions about new vehicles or components in the future. Embodiments of this disclosure provide the necessary information.

[0057] Therefore, in Figure 3 In one embodiment, vehicle 310 includes multiple sensors 314, 315, 316, 317, 318, and 319, which can constitute multiple different types of sensors providing different types of data. The sensors and... Figure 3 In the example, one or more analysis modules, shown as analysis modules 320, 322, and 324, communicate with each other.

[0058] Furthermore, vehicle 310 can communicate with one or more network components or cloud services. Figure 3 In the example, the network location has analysis modules 330, 332, 334, 336, 338, and 340, which together with the analysis modules on the vehicle provide a hierarchical structure of the analysis modules.

[0059] Similarly, vehicle 350 includes multiple sensors 352 and multiple analysis modules 356. Vehicle 360 ​​includes multiple sensors 362 and analysis modules 366. Similarly, vehicle 370 includes multiple sensors 372 and analysis modules 376.

[0060] Figure 3 The example provided only includes four vehicles communicating with network elements, each equipped with the same number of sensors and analytics modules. However, this is merely for simplicity; in reality, thousands or millions of vehicles can communicate with analytics systems that have different configurations of sensors and analytics modules.

[0061] use Figure 3 For example, in one scenario, the battery could be a component of interest to all parties. In this case, the battery could include a sensor 314 that monitors it.

[0062] The network provides an analysis module, in Figure 3 Examples include analysis modules 320, 322, and 324 on the vehicle itself and analysis modules 330 to 340 in network elements. These analysis modules can have an interconnected hierarchical structure. For example, as... Figure 3 As shown, the solid lines between analysis modules can represent direct connections between analysis modules in a hierarchical structure. Such direct connections allow subsets of data to be provided from lower-level analysis modules to higher-level analysis modules.

[0063] Dashed lines indicate inferences provided between analysis modules at the same level. Such inferences can provide processing insights within the analysis module, allowing the analysis module to assume some of the responsibilities of data processing, blocking, and notification.

[0064] The blocking and configuration processes are in opposite directions, such as... Figure 3 The thicker line is shown in the example.

[0065] Therefore, in Figure 3 The example illustrates a hierarchical structure where each analysis module in the analysis module can augment the battery data with data from other sensors considered relevant, as well as analytical information (such as inferences), which is generated and fed to other analysis modules as higher-level data.

[0066] In addition to data collection and expansion, the analytics modules generate blocks that flow towards lower levels of the hierarchical model of sensors and actuators to influence changes in the vehicle based on inferences from one or more analytics modules. These blocks can also provide restrictions or filtering on data supplied from lower-level analytics modules or data accumulators.

[0067] For example, in some cases, analysis module 320 can be an electrical analysis module or a powertrain analysis module. Analysis module 322 can be a vehicle-wide analysis module. Analysis module 330 can be a regional analysis module. Analysis module 340 can be a vehicle manufacturer-wide analysis module. Analysis module 336 can be a component manufacturer-wide analysis module.

[0068] Other options are possible.

[0069] Data processing and analysis

[0070] When data is observed from sensors such as sensor 314 and sent up to the analysis modules, these analysis modules can correlate other sensor data with the battery sensor.

[0071] Powertrain analysis data is fed into electrical analysis and vice versa, because there may be some relationship between them, although humans may not be able to determine the exact nature of such a relationship a priori. In this case, the expected relationship could be that the braking mechanism is used to generate electricity for the battery, while the battery is used to power some aspect of the powertrain. The vehicle-wide analysis module can take the electrical analysis information and battery information to determine appropriate actions for the vehicle, such as reducing battery power for less critical functions to conserve it for more important functions when the power supplied by the battery may not be sufficient for all functions.

[0072] The data is provided to the regional analysis module 330, which correlates the battery data with data from other vehicles within the jurisdiction of the regional transportation authority to determine the safety of the battery.

[0073] Vehicle manufacturers can analyze engine 340 to correlate data from other components to identify which factors under their control can help or prevent battery malfunctions that could inconvenience the user. Other options are possible.

[0074] Effects and Tags

[0075] Because actual battery degradation is sensed within the system, and the system analyzes factors associated with various levels of degradation, the electrical system analysis module can correlate information from the powertrain analysis—that is, for this specific vehicle, there are numerous cold starts and short-circuit drives leading to poor battery performance. The analysis module can then send this expanded information, along with data on the largest sources of battery consumption, to the vehicle manufacturer. The vehicle manufacturer's analysis can use this information to standardize extraneous factors, thereby improving the quality of the analysis.

[0076] Factor identification and efficiency improvement

[0077] The analysis engine can also send relevant factor information to lower-level analysis modules and sensors. Analysis modules that receive relevant factor information from higher-level analysis modules can stop sending irrelevant information to those modules, but continue sending such information to other analysis modules that still consider it relevant.

[0078] If there is no analysis module that requires certain information, the relevant information report can reach the sensor, and the sensor can stop sensing certain factors.

[0079] In this way, the system's efficiency improves over time. High-quality factors can be identified, and failure risks can be predicted. Some of these predictions can help manufacturers conduct part recalls, even if in some scenarios this may require human approval for such recalls.

[0080] In some cases, battery recalls can be initiated by the component manufacturer. The most likely and critical predictors of this failure can be fed into the system along with a set of mitigation measures. Vehicles that have not yet experienced the failure can monitor relevant factors and take remedial action as appropriate. For example, if a battery failure is only detected under certain weather conditions, the manufacturer can limit the impact of the recall by replacing the component only in vehicles that are likely to face similar conditions.

[0081] Other examples are possible.

[0082] Block

[0083] In addition to analyzing data and providing inferences, the system also provides the ability to take direct action. Figure 3 The multi-layered analysis available in the system allows the application of the correct set of blocking actions from a large set of possible actions applicable to a particular vehicle.

[0084] For example, a battery health indicator could be limiting engine start / stop at traffic lights to keep the engine running when the battery needs additional charging. In this scenario, electrical analysis from the vehicle could be correlated with original equipment manufacturer (OEM) analysis and regional analysis to determine the local climate. This might require some vehicles to disable engine start / stop, while other vehicles using the same battery and driving habits in different locations might not require any mitigation measures at all.

[0085] Furthermore, in some cases, factors and blocks can be pushed down to the vehicle analytics level so that vehicles not connected to network analytics components can make the same decisions. This can be useful in scenarios where vehicles may not have continuous internet communication. For example, a vehicle might be traveling in a rural area without internet access. Therefore, some embodiments of this disclosure allow factors for blocking to be pushed down to the appropriate level where possible. Blocking can also be changed if further analysis is required.

[0086] Although the above is about Figure 3 The example outlined here concerns battery sensors, but the same example can be applied to any system within a vehicle. For instance, the security of an onboard computer system can be monitored in a similar manner. In this case, if an access attempt is detected, such as using the engine computer port, USB port, wireless communication, etc., this access attempt can be examined on various analytics engines to determine whether it is a valid attempt or whether it constitutes a hacking attack. Similarly, in some cases, information and analysis can be performed on the vehicle itself to enable rapid action. Furthermore, network elements may also involve compiling experience from multiple vehicles and various inferences made based on those experiences. Such information can then be pushed to the vehicle's own analytics modules.

[0087] Internet of Things (IoT) scenarios

[0088] Although Figure 2 and Figure 3 The embodiments provided illustrate the deployment of a hierarchical analytics module system in a vehicle, but such a system, capable of dynamically learning from multiple sensor inputs from different types of sensors and different systems, can also be deployed in other environments. For example, such systems could include the use of IoT devices. This could be in home automation scenarios or other situations such as businesses, hospitals, factories, emergency responders, etc. Therefore, the extension... Figure 1 Summary Figure 4 This provides a high-level overview of IoT deployment in a hospital environment. Figure 4 In the example, hospital system 410 includes multiple IoT devices. For instance, such devices can be associated with medical equipment used within the hospital. These sensors can report on the use of hospital equipment, its location, whether maintenance or repair of any parts is needed, and so on. For example, in… Figure 4 In one embodiment, multiple IoT devices 420 are shown.

[0089] The hospital system may also include multiple sensor modules 430. For example, such a sensor module may include sensor 432, which may be associated with radio frequency or near-field communication sensors in corridors or doorways to sense when staff with short-range communication identification enter or leave the area. In other cases, sensor 432 may include pressure sensors in hospital beds, temperature, environmental, overflow, or other sensors in mechanical areas, etc.

[0090] In addition, such as Figure 4 As seen in the embodiments, the blocker 434 may be associated with the sensor 432 and may allow certain actions to be taken, such as calling staff such as doctors or nurses to different areas via a pager associated with a doctor or nurse or via the hospital’s loudspeaker system; alerting maintenance or support personnel to environmental factors; closing doors; and so on.

[0091] In other cases, hospital system 410 may include access to various information within patient database 440. For example, the system may allow the calculation of statistics such as the number of hospital admissions and discharges to ensure that staffing levels meet demand.

[0092] The data collector 450 can collect data from various systems, including IoT devices 420, sensors 432, and a patient database 440. The controller 452 can further control the blocker or provide commands to the IoT devices.

[0093] Data from data collector 450 may optionally flow via data repeater 454 to one or more processors 460 having one or more analysis modules. Processors 460 using the one or more analysis modules can make inferences and decisions about what action (if any) to perform. In some cases, such actions can be transmitted from processor 460 to controller 452.

[0094] In some embodiments, processor 460 may use communication subsystem 464 to communicate with network element 480 and / or network element 490 via network 470. Network elements 480 and 490 may be any server or cloud service. For example, network element 480 may be a regional health authority, a medical device manufacturer's data center, a medical supplier's data center, a government regulatory agency, etc.

[0095] Each network element in network elements 480 and 490 may have one or more analysis modules. Figure 4 In the example, network element 480 includes analysis module 482 and network element 490 includes analysis modules 492 and 494. However, this is provided only as an example, and more or fewer analysis modules may exist within the system.

[0096] In some cases, network 470 can be, for example, the Internet. In other cases, network 470 can be any wired or wireless network that can communicate with the hospital system. Other options are possible.

[0097] Therefore, the communication subsystem 464 can be any communication mechanism that allows wired or wireless communication with the network 470, including Ethernet, cellular communication, satellite communication, etc. The structure of the communication subsystem 464 depends on the type of communication that the subsystem will perform.

[0098] According to this disclosure, the multi-layered structure of the analytics engine can provide optimizations in data analysis and processing by customizing data flow to higher layers and pushing instructions to lower layers, thereby accelerating processing or handling situations where network connectivity may be interrupted. In this regard, now... Figure 5 For reference, it shows an example of a hierarchical structure with analytics engines and data sources from multiple hospital systems.

[0099] exist Figure 5 In the example, hospital system 510 may include multiple devices and components. Parties including those within the hospital, hospital administrators, regional health authorities, national health authorities, medical device manufacturers, healthcare providers, or government authorities may be interested in determining the status, deployment, health, or other characteristics of one or more devices or components within the hospital system, and may take action as needed. Embodiments of this disclosure provide the information necessary to achieve this.

[0100] Therefore, in Figure 5 In one embodiment, the hospital system 510 includes multiple devices or sensors 514, 515, 516, 517, 518, and 519, which can constitute multiple different types of devices or sensors providing different types of data. Sensors and Figure 5 In the example, one or more analysis modules, shown as analysis modules 520, 522, and 524, communicate with each other.

[0101] Therefore, for example, a hospital might be interested in knowing the location of emergency trolleys and ensuring that such trolleys are positioned where they are most needed. In this regard, emergency trolleys may include location sensors that can use, for example, Wi-Fi triangulation technology to determine the trolley's location within the hospital. Such trolleys may also include devices indicating that they are being used, and this data can be fed into an analysis module within the hospital system 510. The hospital system can analyze the trolley's usage and location, using historical data from a database, etc., and determine that the trolley needs to be repositioned. In this regard, if the trolley is robotic, it can be repositioned automatically. Otherwise, a caregiver can be dispatched to reposition the trolley. The analysis module can receive data about the trolley and use inference models to dynamically determine the disruptions that should occur.

[0102] Furthermore, the hospital system 510 can communicate with one or more network components or cloud services. Figure 5 In the example, the network location has analysis modules 530, 532, 534, 536, 538, and 540, which together with the analysis modules within the hospital system provide a hierarchical structure for the analysis modules.

[0103] Similarly, hospital system 550 includes multiple devices or sensors 552 and multiple analysis modules 556. Hospital system 560 includes multiple devices or sensors 562 and analysis modules 566.

[0104] Figure 5 The example provided only includes three hospital systems communicating with network elements, each configured with the same number of sensors and analytics modules. However, this is merely for simplicity; in reality, dozens, hundreds, or thousands of hospital systems can communicate with analytics systems that have different configurations of sensors and analytics modules.

[0105] use Figure 5 For example, in one scenario, a dedicated medical device can be a component of interest to all parties. In this case, the dedicated medical device may include one or more sensors 514 that monitor it.

[0106] The network provides an analysis module, in Figure 5 The examples include analysis modules 520, 522, and 524 within the hospital system itself, as well as analysis modules 530 to 540 in network elements. These analysis modules can have an interconnected hierarchical structure. For example, as... Figure 5 As shown, the solid lines between analysis modules can represent direct connections between analysis modules in a hierarchical structure. Such direct connections allow subsets of data to be provided from lower-level analysis modules to higher-level analysis modules.

[0107] Dashed lines indicate inferences provided between analytics modules at the same level. Such inferences can provide processing insights within analytics modules, allowing these modules to assume some of the responsibilities of data processing, blocking, and notification.

[0108] The blocking and configuration processes are in opposite directions, and... Figure 5 The example is shown with a thicker line.

[0109] Therefore, in Figure 5 The example illustrates a hierarchical structure where each analysis module in the analysis module can augment the medical device data with data from other sensors deemed relevant, as well as analytical information (such as inferences), which is generated and fed to other analysis modules as higher-level data.

[0110] In addition to data collection and expansion, the analytics modules generate blocks that flow towards lower levels of the hierarchical model of sensors and actuators to influence changes in the hospital system based on inferences from one or more analytics modules. These blocks can also provide restrictions or filtering on data supplied from lower-level analytics modules or data accumulators.

[0111] For example, in some cases, analysis module 520 may be a device usage optimization module. Analysis module 522 may be associated with a hospital-level health authority-wide analysis module. Analysis module 330 may be associated with a regional analysis module. Analysis module 340 may be associated with a medical device manufacturer analysis module. Analysis module 336 may be associated with a government health authority. Other options are possible.

[0112] Data processing and analysis

[0113] When data is observed from the device or sensor 514 and sent up to the analysis modules, these analysis modules can correlate other sensor data with the device or sensor 514.

[0114] and Figure 3 Similar to vehicle systems, hospital systems' analytics modules can acquire data from various sources and correlate and interpret this data, which may not initially be apparent to human observers. In this regard, various objectives within the system can include optimizing equipment use, minimizing costs, reducing treatment time, and so on, and the hierarchical structure of the analytics modules can dynamically work towards these objectives without requiring excessive human intervention beyond the configured parameters.

[0115] The data is provided to the regional analysis module 530, which correlates various hospital data with data from other hospitals within the jurisdiction of the regional health authority to determine the effectiveness of the regional healthcare system.

[0116] The medical device manufacturer's analytics engine 540 can correlate data from other sensors or devices to identify which factors, under their control, can help or prevent equipment malfunctions that could endanger patient safety or cause inconvenience to the hospital system. Other options are possible.

[0117] Factor identification and efficiency improvement

[0118] The analysis engine can also send relevant factor information to lower-level analysis modules and sensors. Analysis modules that receive relevant factor information from higher-level analysis modules can stop sending irrelevant information to those higher-level modules, but continue sending such information to other analysis modules that still consider it relevant.

[0119] If no analysis module needs certain information, the relevant information report can be routed down to lower-level analysis modules, or in some cases to devices or sensors (if they can be controlled), and in some cases, devices or sensors can stop sensing certain factors, and / or lower-level analysis modules can stop collecting certain data from devices or sensors.

[0120] In this way, the system's efficiency improves over time. High-quality factors can be identified, and optimization can occur.

[0121] Block

[0122] In addition to analyzing data and providing inferences, the system also provides the ability to take direct action. Figure 5 The multi-layered analysis available in the system allows the application of the correct set of blocking actions from a large set of possible actions.

[0123] For example, actions in medical equipment could include positioning the device correctly, identifying incorrect use of the device and warning medical personnel, identifying potential erroneous readings on the device and indicating that the device should be taken out of use until it is repaired, and so on.

[0124] Therefore, according to Figure 4 and Figure 5 In one embodiment, the hierarchical modular system can be used in a hospital environment.

[0125] Furthermore, while vehicle and hospital IoT environments are discussed in this disclosure, this disclosure is not limited to any particular use case and can be used in any situation where the device or sensor can provide data and the system can provide blocking.

[0126] Analysis module processing

[0127] An analytics module is a software or hardware module on a computing device that receives data, processes the data according to rules or based on machine learning inference, and produces results including blocking, notification, inference, and providing datasets to other analytics modules within the various hierarchical layers.

[0128] Specifically, now for reference Figure 6 It illustrates the process at the analysis module according to this disclosure. Figure 6 The process begins at block 610 and proceeds to block 612, where the analysis module can receive data from a lower-level analysis module or a data source. For example, the analysis module can receive data from a sensor or an ECU. The data can be a single sensor reading, multiple sensor readings, or a combination of readings from different sensors. In other cases, the data can be a dataset processed and output by a lower-level analysis module.

[0129] In some cases, the analysis module can also receive inferences or blocking from other analysis modules, as shown at block 614. Specifically, blocking or notifications can be received from higher-level layers. For example, a blocking or notification might indicate that certain data is not needed at the higher-level analysis module. In other cases, a notification might indicate that the frequency of data can be reduced. Additional options for customizing data to higher-level modules can also be received.

[0130] In other cases, inferences can be received from analysis modules at the same level. Such inferences can provide the type of data being used to make decisions at that analysis module, which may be useful to the current analysis module.

[0131] Other options are possible.

[0132] Once the first dataset is received at block 612, and using any inferences, blocking, or notifications received from other analysis modules, the current analysis module can analyze the first dataset at block 620 to create a second dataset. The second dataset can be customized for specific higher-level analysis modules. In other cases, the second dataset can also be used to provide blocking or notifications to other lower-level analysis modules, or to provide inferences to analysis modules at similar levels.

[0133] From block 620, the process proceeds to block 630, where a second dataset is provided to a higher-level analysis module. As indicated above, the second dataset can be customized for this second analysis module or a higher-level analysis module, and in some cases, the current analysis module can create multiple datasets customized for different higher-level modules.

[0134] In addition, in some cases, a second dataset can indicate that the current analysis module is providing uncertain data, is too verbose, or is not providing data in a timely manner, thus pushing decision-making to a higher-level module.

[0135] The process proceeds from block 630 to block 640, where the current analysis module can provide notifications or block lower-level analysis modules.

[0136] The process then proceeds to block 650 and ends.

[0137] Therefore, multiple analysis modules are used, each module performs... Figure 6 The process enables a dynamic environment in which the system can become more efficient over time, optimizes the data used and transmitted between modules, and makes inferences without human intervention, etc.

[0138] Such a system can rely on different datasets from multiple data sources. In this way, Figure 6 The analysis module can be implemented for vehicle scenarios. Figure 2 and Figure 3 The system, or Figure 4 and Figure 5 Systems and IoT scenarios, etc.

[0139] Therefore, based on Figures 1 to 6 The system provides a hierarchical analysis module system, where analysis modules reside at various levels that allow for certain decisions and blockages. Some decisions can be made at lower levels, while others may be made at higher levels, where higher levels can optimize the data reaching them to allow for efficiency in decision-making time, bandwidth usage, processor usage, and so on.

[0140] Computing devices, such as vehicle computing systems, IoT devices, ECUs, or web servers, can be any type of computing device. For example, regarding... Figure 7 A simplified computing device is provided that can perform the above embodiments.

[0141] exist Figure 7 In the computing device 710, a processor 720 and a communication subsystem 730 are included, wherein the processor 720 and the communication subsystem 730 cooperate to perform the methods of the embodiments described herein.

[0142] Processor 720 is configured to execute programmable logic, which can be stored on computing device 710 along with data, and Figure 7In the example, it is shown as memory 740. Memory 740 can be any tangible, non-transitory computer-readable storage medium, such as DRAM, flash memory, optical (e.g., CD, DVD, etc.), magnetic (e.g., magnetic tape), flash drive, hard disk drive, or other memory known in the art. In one embodiment, processor 720 may also be implemented entirely in hardware and does not require any stored program to perform logical functions.

[0143] Alternatively, or in addition to memory 740, computing device 710 may access data or programmable logic from external storage media, for example, via communication subsystem 730.

[0144] The communication subsystem 730 allows the computing device 710 to communicate with other devices or network elements.

[0145] In one embodiment, communication between the various components of the computing device 710 can be achieved via an internal bus 760. However, other forms of communication are also possible.

[0146] The embodiments described herein are examples of structures, systems, or methods having elements corresponding to the elements of the technology of this application. This written description enables those skilled in the art to make and use embodiments having alternative elements that also correspond to the elements of the technology of this application. Therefore, the intended scope of the technology of this application includes other structures, systems, or methods that are not different from the technology of this application as described herein, and also includes other structures, systems, or methods that are not substantially different from the technology of this application as described herein.

[0147] Although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring the operations to be performed in the specific order shown or sequentially, or to perform all the shown operations to achieve the desired result. In some scenarios, multitasking and parallel processing may be employed. Furthermore, the separation of the various system components in the above implementation should not be interpreted as requiring such separation in all implementations. Rather, it should be understood that the described program components and systems can often be integrated together in a single software product or packaged into multiple software products. In some cases, functionality can be implemented entirely in hardware, and such solutions can be functional equivalents of software solutions.

[0148] Furthermore, technologies, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations can be combined or integrated with other systems, modules, technologies, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other can be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are those that can be identified and made by those skilled in the art.

[0149] While the foregoing detailed description has shown, described, and pointed out the essential novel features of this disclosure applicable to various implementations, it should be understood that various omissions, substitutions, and modifications in the form and details of the illustrated systems can be made by those skilled in the art. Furthermore, the order of the method steps does not imply their order of appearance in the claims.

[0150] When messages are sent to / from electronic devices, such operations may not be instantaneous or directly from the server. They can be delivered synchronously or asynchronously from servers or other computing system infrastructure that support the devices / methods / systems described herein. The foregoing steps may include, in whole or in part, synchronous / asynchronous communication to / from devices / infrastructure. Furthermore, communication from electronic devices can be to one or more endpoints on the network. These endpoints can be served by servers, distributed computing systems, stream processors, etc. Content delivery networks (CDNs) can also provide communication to electronic devices. For example, in addition to a typical server response, a server can provide or instruct a content delivery network (CDN) to wait for the electronic device to download at a later time (such as subsequent activity of the electronic device). Therefore, data can be sent directly from servers or other infrastructure (such as distributed infrastructure or CDNs, as part of the system or separate from the system).

[0151] Typically, storage media can include any combination or some of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed, floppy, and removable disks; another magnetic medium, including magnetic tape; optical media such as compact discs (CDs) or digital video discs (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. One or more such computer-readable or machine-readable storage media are considered part of an article of manufacture (or article of creation). An article of manufacture or article of creation can refer to any single or multiple components manufactured. One or more storage media may be located in a machine that executes machine-readable instructions, or at a remote site from which machine-readable instructions can be downloaded via a network for execution.

[0152] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations of the foregoing details. The appended claims are intended to cover such modifications and variations.

Claims

1. A method at an analysis module on a computing device, the analysis module being located at a layer within a hierarchical structure of analysis modules and data sources, the method comprising: Receive the first dataset from the data source or a lower-level analysis module; Analyze the first dataset to create the second dataset; The second dataset, which is derived from the first dataset, is provided to multiple higher-level analysis modules. Receive data filtering feedback from each of the plurality of higher-level analysis modules; Receive a third dataset from the data source or the lower-level analysis module; The third dataset is processed to create a corresponding dataset for each higher-level analysis module, wherein each corresponding dataset for a given higher-level processing module is processed according to the data filtering feedback received from the given higher-level processing module; Provide each higher-level analysis module with its corresponding dataset; as well as Provide at least one of inference and blocking to the lower-level analysis module.

2. The method according to claim 1, further comprising: Receive a blocking or notification from a higher-level analysis module before the analysis is performed.

3. The method according to claim 1, further comprising: Prior to the analysis, an instruction is received from a second analysis module at the same layer as the analysis module.

4. The method of claim 3, wherein the instruction delegates decision-making to the analysis module.

5. The method of claim 1, wherein the blocking restriction on the first dataset for future iterations of the reception and analysis is provided to the lower-level analysis module.

6. The method of claim 5, wherein the blocking includes a notification for reducing the number of reports.

7. The method of claim 1, wherein the analysis is based on at least one of a machine learning process and a rule-based process.

8. The method of claim 1, wherein the data source is at least one of a sensor in the vehicle or an Internet of Things device.

9. The method of claim 1, further comprising repeating the method multiple times to dynamically improve the efficiency of the hierarchical structure of the analysis module and the data source.

10. A computing device, the computing device comprising an analysis module located at a layer within a hierarchical structure of analysis modules and data sources, the computing device comprising: processor; as well as Communication subsystem The computing device using the analysis module is configured as follows: Receive the first dataset from the data source or a lower-level analysis module; Analyze the first dataset to create the second dataset; The second dataset, which is derived from the first dataset, is provided to multiple higher-level analysis modules. Receive data filtering feedback from each of the plurality of higher-level analysis modules; Receive a third dataset from the data source or the lower-level analysis module; The third dataset is processed to create a corresponding dataset for each higher-level analysis module, wherein each corresponding dataset for a given higher-level processing module is processed according to the data filtering feedback received from the given higher-level processing module; Provide each higher-level analysis module with its corresponding dataset; as well as Provide at least one of inference and blocking to the lower-level analysis module.

11. The computing device of claim 10 is further configured to: receive a blocking or notification from a higher-level analysis module before analyzing the first dataset.

12. The computing device of claim 10 is further configured to: receive an instruction from a second analysis module at the same layer as the analysis module before analyzing the first dataset.

13. The computing device of claim 12, wherein the instruction delegates decision-making to the analysis module.

14. The computing device of claim 10, wherein the computing device is configured to: provide the blocking to the lower-level analysis module to limit the use of the first dataset for future iterations of the reception and analysis.

15. The computing device of claim 14, wherein the blocking includes a notification for reducing the number of reports.

16. The computing device of claim 10, wherein the computing device is configured to perform analysis based on at least one of a machine learning process and a rule-based process.

17. The computing device of claim 10, wherein the data source is at least one of a sensor in a vehicle or an Internet of Things device.

18. The computing device of claim 10, wherein the computing device is further configured to: repeatedly receive and analyze the first dataset, provide the second data, and provide at least one of the inference and blocking, to dynamically improve the efficiency of the hierarchical structure of the analysis module and the data source.

19. A computer-readable medium for storing instruction code, the computer-readable medium comprising an analysis module located at a layer within a hierarchical structure of analysis modules and a data source, the instruction code, when executed by a processor of a computing device, causing the computing device to: Receive the first dataset from the data source or a lower-level analysis module; Analyze the first dataset to create the second dataset; The second dataset, which is derived from the first dataset, is provided to multiple higher-level analysis modules. Receive data filtering feedback from each of the plurality of higher-level analysis modules; Receive a third dataset from the data source or the lower-level analysis module; The third dataset is processed to create a corresponding dataset for each higher-level analysis module, wherein each corresponding dataset for a given higher-level processing module is processed according to the data filtering feedback received from the given higher-level processing module; Provide each higher-level analysis module with its corresponding dataset; as well as Provide at least one of inference and blocking to the lower-level analysis module.

Images