Method and system for cloud-based data analysis

Abstract

Systems and methods are provided for connecting multiple customers to a shared, cloud-based AIOps service with a bidirectional intermediate data transport layer. As a feature of the intermediate data transport layer, each customer (and its data) can be isolated from other customers. In various examples, the cloud-based AIOps service can receive sensor data from a customer system via the intermediate data transport layer. The cloud-based AIOps service can analyze the sensor data (e.g., detect anomalies, perform root cause analysis, find optimal conditions, etc.) and modify the operation of one or more customer systems (e.g., modify settings / configurations of sensors on a piece of connected infrastructure) via the intermediate data transport layer. In certain examples, in addition to (or instead of) modifying the operation of one or more customer systems, the cloud-based AIOps service can provide situational prepositioning notifications to the customer.

Description

Background Technology

[0001] Artificial Intelligence for IT Operations (AIOps) is a rapidly growing field in the IT industry. AIOps can refer to the use of artificial intelligence (AI) and machine learning to perform advanced analytics on big data (i.e., time-series data, logs, etc.) for purposes such as anomaly detection, root cause analysis, and others. The predictive capabilities of AIOps can also be used to optimize certain tasks / systems: for example, optimizing the energy efficiency of data centers.

[0002] Traditionally, AIOps services are not inherently distributed (i.e., they are not shared among customers). Instead, they are deployed in separate customer sites. These on-premises deployments are intended to ensure the security of customer data. Attached Figure Description

[0003] This disclosure is described in detail with reference to the following figures, based on one or more different examples. The figures provided are for illustrative purposes only and depict only examples.

[0004] Figure 1 This is a schematic diagram illustrating example cloud-based deployments of AIOps services based on various examples.

[0005] Figure 2 This is another schematic diagram illustrating example cloud-based deployments of AIOps services based on various examples.

[0006] Figure 3 This is another schematic diagram illustrating example cloud-based deployments of AIOps services based on various examples.

[0007] Figure 4 This is a schematic diagram of the intermediate data transmission layer based on various examples.

[0008] Figure 5 This is a schematic diagram of a publish / subscribe message bus communication link for an intermediate data transmission layer, based on various examples.

[0009] Figure 6 These are example computing systems that can be used to implement cloud-based AIOps services, based on various examples.

[0010] Figure 7 It is another example computing system that can be used to implement cloud-based AIOps services, based on various examples.

[0011] Figure 8 These are example computing systems that can be used to combine with cloud-based AIOps services, based on various examples.

[0012] Figure 9A block diagram is depicted of an example computer system 900 in which various embodiments described herein may be implemented.

[0013] These accompanying drawings are not exhaustive and do not limit this disclosure to the exact form disclosed. Detailed Implementation

[0014] As mentioned above, traditionally, AIOps services are not inherently distributed (i.e., they are not shared among customers). Instead, they are deployed in individual customer locations. These separate, location-on-premises deployments are intended to ensure the security of customer data.

[0015] However, these on-premises deployments have certain limitations. In particular, they cannot leverage insights from one customer site and apply those insights in real time to benefit other customers. For example, an AIOps service deployed at the first customer site might discover a suboptimal condition of the temperature sensor on a coolant distribution unit. A second customer might have the same brand / model coolant distribution unit with the same suboptimal temperature sensor condition. Because the AIOps service deployed at the first customer site is not connected to the second customer, it cannot utilize the knowledge gained at the first customer site to benefit the second customer in real time.

[0016] One way to dynamically leverage AIOps-based insights across multiple customer sites is to offer AIOps as a cloud-based service. Using this approach, multiple customers can share data through a shared / public cloud-based AIOps service. Therefore, a shared AIOps service can dynamically leverage insights gained at one customer site to benefit other customers. Expanding on the example in the previous paragraph, a cloud-based AIOps service could send notifications to any customer with the same / similar model of coolant distribution unit regarding suboptimal temperature sensor conditions detected at the first customer site.

[0017] However, cloud-based approaches like these are limited by traditional methods by which customers (and / or their systems) connect to cloud-based services. Typically, these traditional methods (e.g., WebSocket, IPSec, and similar connections) involve a direct connection between the customer and the cloud-based service. These traditional (often direct) connection methods cannot provide the level of security required by many data-sensitive customers (e.g., national laboratories, military customers, etc.) for data-driven services like AIOps.

[0018] For example, WebSocket connections between customers and cloud-based services have known weaknesses in authentication and authorization, and lack an integrated identity system, making them vulnerable to spoofing. Other traditional connection technologies, such as IPSec connections, operate at too low a level of complexity, which can lead to the merging of customer networks, even if the cloud-based service provider is making its best efforts. Therefore, data-sensitive customers cannot accept these types of connections.

[0019] In the context of this paper, examples of currently disclosed technologies utilize a bidirectional intermediate data transfer layer (e.g., HPE's remote device access technology) to connect multiple customers to a shared, cloud-based AIOps service. As a feature of the intermediate data transfer layer, customers (and the data they provide to the AIOps service) can be completely isolated from each other. Therefore, examples of currently disclosed technologies can dynamically leverage AIOps-based insights across multiple customer sites while maintaining robust data security.

[0020] In various examples, cloud-based AIOps services can receive sensor data from customer systems via an intermediate data transmission layer that connects the cloud-based AIOps service to multiple customers. This intermediate data transmission layer can provide these connections while maintaining data isolation. Therefore, the cloud-based AIOps service can analyze this sensor data (e.g., detect anomalies, perform root cause analysis, find optimal conditions, etc.) and modify the operation of one or more customer systems via the intermediate data transmission layer (e.g., modify the settings / configuration of sensors on a connected infrastructure). In some examples, in addition to (or instead of) modifying the operation of one or more customer systems, the cloud-based AIOps service can provide customers with site-preset notifications. These notifications can inform customers about the operational status of their systems(s). For example, a notification could inform a customer of an abnormal operation of a barometer sensor in one of their critical machines.

[0021] As described above, the intermediate data transmission layer connecting cloud-based AIOps services to multiple customers can be a layered communication platform, such as HPE's Remote Device Access Platform (“RDA”). This layered communication platform can utilize “intermediary servers” (“intermediaries”) and data transmission “tunnels” to establish secure channels between customers and cloud-based AIOps services. For example, an intermediary (which can be a piece of computer hardware or software) can act as a smart switch, combining a first data transmission tunnel to the customer with a second data transmission tunnel to the AIOps service.

[0022] In various examples, an intermediate data transfer layer can provide a publish / subscribe message bus communication link between the intermediary and the cloud-based AIOps service. Through the intermediary and this publish / subscribe message bus communication link, clients can publish messages to the AIOps service about certain topics (e.g., raw metric / sensor data topics), which the AIOps service can pre-subscribe to read / receive. As described below, all these messages can be visible only to the AIOps service. Through this link and the intermediary, the AIOps service can also publish messages to clients about specific topics (e.g., notifications and operational modification topics) that clients (or their systems) can pre-subscribe to read / receive. In this way, multiple clients can share data with a public cloud-based AIOps service, which can then apply insights derived from a given client's data, benefiting multiple clients. All of this is achieved in a way that isolates clients (and their data) from each other, as will be described in more detail below.

[0023] Figure 1 This is a schematic diagram illustrating an example cloud-based deployment of AIOps services.

[0024] The example deployment includes cloud platform 100 and customers 120, 130, and 140. An intermediate data transfer layer 110 connects each customer to cloud platform 100 (and the AIOps services residing therein) in a manner that isolates customers (and their data) from each other.

[0025] Cloud Platform and AIOps Services: Cloud platform 100 can be any cloud platform capable of providing public / distributed cloud-based AIOps services. For example, cloud platform 100 can be HPE's Greenlake cloud platform. In some embodiments, cloud platform 100 can be a public cloud platform. In other embodiments, cloud platform 100 can be a "hybrid" cloud platform having some aspects of a public cloud platform and some aspects of a private cloud platform. For example, a hybrid cloud platform can combine on-premises data centers with public cloud services.

[0026] Residing within cloud platform 100 are AIOps services 102 and 104. AIOps services can refer to services that utilize artificial intelligence and / or machine learning to perform data analysis for purposes such as anomaly detection, root cause analysis, optimization of task / customer systems, and other items. In some examples, AIOps services 102 and 104 may be different versions of AIOps services provided by an AIOps service provider. For example, AIOps service 102 may be a more expensive premium service subscription than AIOps service 104. In another example, these two AIOps services can be customized for different customer applications. For example, AIOps service 102 may be customized to perform analysis for energy sector customers / applications, while AIOps service 104 may be customized to perform analysis for data centers. Although only two AIOps services are depicted in the example illustration, in other examples, the service provider may offer any number of AIOps services based on price, application type, etc.

[0027] Customers: Customers 120 and 130 subscribe to AIOps service 102, and customer 140 subscribes to AIOps service 104. As used herein, a customer can refer to any individual or entity subscribing to an AIOps service. Customers can occupy different sectors. For example, customers 120 and 130 could occupy the energy sector. In contrast, customer 140 could operate a data center. Although in Figure 1 The example depicts only three customers, but in other examples, many additional customers can subscribe to the AIOps service. Therefore, the AIOps service can apply insights gained from one customer's data to benefit other customers. In other words, a given customer can benefit in real time from insights derived from other customers' data.

[0028] As shown in the figure, a given customer can have a customer system and a customer Kafka cluster.

[0029] Customer System Customer systems can refer to the equipment and infrastructure systems connected to a customer, including both hardware and software systems. For example, if customer 120 operates a nuclear power plant, then customer 120's customer systems could include all connected equipment and infrastructure systems of the power plant (e.g., nuclear reactor, coolant distribution unit, computing / software systems, etc.).

[0030] Customer Kafka clusterThe client's Kafka cluster can be a software communication bus that uses streaming processing to facilitate communication between a given client's client system and external systems (e.g., AIOps services 102 and 104) via an intermediate data transmission layer. As shown in the diagram, the client's Kafka cluster can connect to the intermediate data transmission layer 110 in various ways. For example, the client's Kafka cluster can connect to the intermediate data transmission layer 110 using a TLS / TCP connection initiated by the client or the service provider. In some examples, these connections can be made over IPSec. In other examples, the client can connect to the interface of the intermediate transport layer 110 via a REST API using JSON or Avro.

[0031] Through any of these methods, customers can connect to intermediate data transfer layers (such as intermediate data transfer layer 110) with minimal modification to their Kafka clusters. Therefore, customers can subscribe to one of the cloud-based AIOps services depicted without having to re-equip their systems. In this way, AIOps services 102 and 104 can be provided in a customer-friendly, modular manner. Furthermore, due to the unique characteristics of intermediate transport layer 110 (which will combine...) Figure 4 (To be described in more detail), all of these are achieved in a data-secure manner.

[0032] Various topics can reside in a client's Kafka cluster. These topics can include raw metric topics, notification topics, and operation modification topics. Here, a topic can refer to a category or generic name for a stream of specific types of data (i.e., raw metric data, notification data, etc.) used for storing and publishing such data. As described above, producers can publish data to a topic, and consumers can read data from that topic by subscribing to it. For example, a client system of client 120 can publish raw sensor data (e.g., data associated with the operation of a temperature sensor in a coolant distribution unit) to a raw metric topic residing in the Kafka cluster of client 120. As described below, a data consumer residing in AIOps service 102 can subscribe to this raw metric topic via a publish / subscribe message bus communication link of intermediate transport layer 110. Through this intermediate link, AIOps service 102 can stream the sensor data published by the system of client 120 in real time, while client 120 and its data remain isolated from clients 130 and 140.

[0033] Intermediate Data Transmission Layer: Intermediate data transmission layer 110 can be a bidirectional data transmission layer that connects multiple clients to one or more cloud-based AIOps services while maintaining data isolation between clients. As described above, intermediate data transmission layer 110 can be a hierarchical communication platform, such as HPE's Remote Device Access Platform (RDA). In various examples, this hierarchical communication platform can use "intermediaries" and data transmission "tunnels" to establish secure channels between clients and cloud-based AIOps services. An intermediary can refer to a piece of computer software or hardware that can combine a first data transmission tunnel to a client (e.g., client 120, 130, or 140) with a second data transmission tunnel to an AIOps service (e.g., AIOps service 102 or 104). In this way, the intermediary can establish a secure, dedicated channel between a client and one of the cloud-based AIOps services.

[0034] In various examples, the intermediate data transmission layer 110 can provide a publish / subscribe message bus communication link between the intermediary and the cloud-based AIOPS service. A publish / subscribe message bus communication link can refer to a communication system / link that allows a message sender (i.e., a publisher) to subscribe to read / consume messages published on one or more topics by a data consumer. Via the intermediary and this publish / subscribe message bus communication link, a client (or its system) can publish messages to the AIOps service about certain topics (e.g., raw metric / sensor data topics), which the AIOps service can pre-subscribe to consume / receive. As described below, all these messages can be visible only to the AIOps service. Through the publish / subscribe message bus communication link and the intermediary, the AIOps service can also publish messages to clients about certain topics (e.g., notification and operation modification topics) that can be pre-programmed to consume / receive by the client's Kafka cluster (or the client's system).

[0035] In some examples, JSON or AVRO can be used to facilitate communication between the intermediate data transfer layer 110 and the client's REST API. This will be combined with... Figures 4-5 An example of intermediate data transmission layer 110 is described in more detail.

[0036] Themes and processors: Figure 1 The client Kafka cluster and AIOps service can include various components that publish or subscribe to each other via a publish / subscribe message bus communication link through the intermediate transport layer 110. Through this communication architecture, AIOps services 102 and 104 can perform real-time analytics for multiple clients and dynamically leverage insights gained from a single client's data across a larger client base. Examples of the topics and processors that make this possible are described in more detail below.

[0037] Original metric topic Raw sensor data can be published to the raw metrics topic. This raw sensor data can be data associated with the operation of the client system. For example, raw sensor data from a coolant distribution unit in client 120 can be published to the raw metrics topic residing in the Kafka cluster of client 120. Here, the raw sensor data can include data associated with coolant temperature, coolant pressure, coolant flow rate, power consumption, etc. Raw sensor data can also include data associated with the operation of the sensor itself (e.g., data associated with the operation of a temperature sensor, which can indicate that the temperature sensor has failed / damaged).

[0038] As shown in the diagram, in some examples, the REST API can be used as an interface between the original metric topic and the intermediate data transmission layer 110. However, in other examples, other interfaces / interface methods can be used.

[0039] Notifications and Operations to Modify Topic As will be described in more detail below, the AIOps service can publish to notification topics and operation modification topics via the publish / subscribe message bus communication link of the intermediate data transmission layer 110. In some examples, a REST API can be used as the interface between the intermediate data transmission layer 110 and the notification and operation modification topics. Publishing an operation modification topic to a client's Kafka cluster is just one of many ways the AIOps service can modify the operations of that client system. Similarly, publishing a notification topic to a client's Kafka cluster is just one of many ways the AIOps service can provide notifications to clients. For example, performance anomalies can be checked by publishing a Kafka topic to a database for later use.

[0040] AIOps services can include data consumers, one or more trained machine learning models, analytics processors, notification processors, and operation modification processors.

[0041] Data Consumers Data consumers can subscribe to raw metric topics residing in a client's Kafka cluster. Therefore, data consumers can read / consume raw sensor data published by client systems to their respective raw metric topics.

[0042] Analysis Processor Once the data consumer has read the data, the analytics processor can apply the analytics to various purposes of the customer's sensor data, such as detecting anomalies, performing root cause analysis, and optimizing certain tasks / customer systems.

[0043] In some examples, the analysis processor can use one or more trained machine learning models to perform analysis. For instance, combining... Figure 3The described method utilizes historical data extracted from one or more customers to train these machine learning models. This historical data may relate to past operations of the customer's system. For example, historical data may include information associated with past raw metric / sensor data, previously detected anomalies, previous root cause analyses, information associated with optimizations of certain tasks / customer systems, previous notifications, previous operational modifications made in response to various analytical insights, etc.

[0044] In some examples, the analysis processor can select one of several trained machine learning models based on various factors such as the data type being analyzed and the type of analysis being performed (i.e., anomaly detection, root cause analysis, optimization, etc.).

[0045] As an illustration, the analytics processor of AIOps service 102 can be dedicated to anomaly detection. Even for this single type of analytics, the analytics processor can utilize multiple different trained machine learning models. For example, customer 120 can operate a nuclear power plant. Therefore, customer systems of customer 120 can include various connected equipment / infrastructure systems of the nuclear power plant (e.g., turbines, generators, nuclear reactors, coolant distribution units, etc.). The analytics processor can utilize separate machine learning models to detect operational anomalies for each type of connected equipment / infrastructure system. For example, the analytics processor can utilize a first set of machine learning models to detect operational anomalies in the coolant distribution unit and a second set of machine learning models to detect anomalies in the nuclear reactor. The various machine learning models in the first set can be trained to detect anomalies for different operating parameters of the coolant distribution unit (e.g., coolant temperature, coolant flow rate, the relationship between coolant temperature and coolant flow rate, etc.). In another example, the analytics processor can utilize machine learning models trained for different operating contexts. For example, the analytics processor can utilize separate machine learning models based on climate (e.g., hot and dry vs. cool and humid) or operating load (e.g., high vs. low, constant vs. intermittent, etc.).

[0046] In summary, analytics processors residing in AIOps services can employ machine learning models specifically tailored for a variety of applications. While these machine learning models can be highly customized, their insights can still be leveraged to benefit a broad customer base. This is due to factors such as... Figure 1 The architecture shown demonstrates its distributed capabilities. In other words, by providing a secure pipeline for streaming data analytics, cloud-based AIOps service providers can grow a large global customer base. Within these customer groups, insights can be shared while maintaining data isolation. As this customer base expands, the insights generated also increase. Similarly, with a large customer base, even highly specific insights can benefit multiple customers.

[0047] For example, when a customer site in Phoenix, Arizona (a hot, dry climate) is operating under high intermittent loads, AIOps Service can identify the optimal coolant temperature for a specific model of coolant distribution unit. As part of its global customer base, AIOps Service may have a customer in Dubai (another hot, dry climate) operating the same model of coolant distribution unit under similar loads. Therefore, AIOps Service can implement operational modifications at each customer site based on analytics insights to optimize coolant temperature.

[0048] As described above, a given AIOps service's analytics processor can use one or more trained machine learning models to perform various types of analysis (e.g., anomaly detection, root cause analysis, optimization, etc.) on data from one or more customers. In response to this analysis, the AIOps service can determine one or both of the following: notifications and actionable modifications are required.

[0049] Notification processor For example, the notification processor of an AIOps service can determine that a notification is needed and publish the notification to one or more notification topics residing in the client's Kafka cluster. As mentioned above, these publications can be carried over the publish / subscribe message bus communication link of the intermediate data transmission layer 110.

[0050] The notification can provide information about the operating conditions of a customer's system as analyzed by the analysis processor. For example, one notification could provide information about the detection of abnormal operation of a temperature sensor in a coolant distribution unit within customer 120's coolant distribution unit. Another notification could provide information about a predicted fault in the electrical windings of a generator within customer 120's generator.

[0051] As described above, the notification processor can send notifications to multiple clients related to the operating conditions of a system analysis for a single client. For example, the analysis processor of AIOps service 102 can detect abnormal operation of a temperature sensor in a coolant distribution unit of client 120. The notification processor of AIOps service 102 can then determine that client 130 has a similar coolant distribution unit. Therefore, even if the analysis processor does not detect abnormal operation in the coolant distribution unit of client 130, the notification processor can still send notifications to the notification topics of clients 120 and 130.

[0052] In some examples, customers can have dashboards that are pre-subscribed to consume messages published to their notification topics. Therefore, dashboards located at customer locations 120 and 130 can be pre-subscribed to consume notification messages published to their respective customer notification topics. In this way, personnel at each customer location are able to view notifications generated in response to real-time analytics insights provided by AIOps service 102.

[0053] Modify the processor The AIOps service's operation modification processor can determine the necessary operation modifications and publish them to one or more operation modification topics residing in the client's Kafka cluster. As mentioned above, these publications can be carried over the publish / subscribe message bus communication link of the intermediate data transmission layer 110.

[0054] Operational modifications can be made to the operation of a client's system in response to analytical insights from an analytics processor. This modification can be applied to one or both of the client's software and hardware systems. Expanding on one example from the above, when client 120 in Phoenix, Arizona, is operating under high intermittent load, the analytics processor of AIOps service 102 can identify the optimal coolant temperature for a specific model of coolant distribution unit. Client 130 could be located in Dubai (another hot and dry climate) and could be running the same model of coolant distribution unit under similar loads. Therefore, the operational modification processor of AIOps service 102 can publish operational modifications based on this analytical insight into operational modification topics residing in the Kafka clusters of clients 120 and 130. The coolant distribution units of clients 120 and 130 (or some other operations controller) can be pre-subscribed to read these operational modification topics, and the operation of these systems / devices can be modified accordingly.

[0055] Figure 2 This is a schematic diagram illustrating another example of a cloud-based deployment of AIOps services.

[0056] This example deployment is similar to the combination Figure 1 The described deployment differs in that it uses the customer's metrics database to extract sensor data and transfer it from the customer's system to one or more cloud-based AIOps services, rather than a Kafka cluster. In some examples, connectors can be used in conjunction with JSON / Avro to manage data traffic between the intermediate data transfer layer and each customer's metrics database. Using this architecture, the customer's investment in their metrics database can be leveraged.

[0057] Figure 3 This is a schematic diagram illustrating another example of a cloud-based deployment of AIOps services. This example deployment is similar to combining... Figure 2The deployment described differs in that historical data is extracted here for the purpose of offline model training.

[0058] Such as combination Figure 1 The machine learning model can be trained using historical data extracted from the metrics databases of one or more customers. This historical data may be related to past operations of the customer's system. For example, historical data may include information associated with past raw metrics / sensor data, previously detected anomalies, previous root cause analyses, information associated with optimizations of certain tasks / customer systems, previous notifications, previous operational modifications made in response to various analytical insights, etc.

[0059] As shown in the figure, model training module 302 receives historical data from customers 320, 330, and 340. However, in other examples, the model training module can receive historical data from any number of customers / customer databases. As mentioned above, by providing a secure pipeline for streaming analytics, cloud-based AIOps service providers can grow a large global customer base. Therefore, for model training purposes, a cloud-based AIOps service provider can be able to extract historical data from a large subset of customers. With rich data sources, the cloud-based AIOps service provider can train a series of machine learning models tailored to various customers / customer applications. As these machine learning models consume more data (from more / more diverse customer applications), they can become more insightful.

[0060] Figure 4 This is a schematic diagram of an intermediate data transmission layer based on various examples. As mentioned above, this intermediate data transmission layer can be implemented using HPE's Remote Device Access (RDA) platform.

[0061] The diagram shows the intermediate data transmission layer 410 at its center. The right side of the diagram shows the cloud-based AIOps service 422. The left side of the diagram shows clients 432, 434, 436, and 438.

[0062] The intermediate data transmission layer 410 can be a bidirectional data transmission layer that connects multiple clients to one or more cloud-based AIOps services while maintaining data isolation between clients. As shown in the figure, the intermediate data transmission layer 410 connects clients 432, 434, 436, and 438 to AIOps service 422.

[0063] In various examples, intermediate data transmission layers can be deployed across multiple geographic regions to improve availability and disaster tolerance. As shown in the figure, intermediate data transmission layer 410 is deployed across four geographic regions (indicated by dashed lines), but in other examples, the intermediate data transmission layer can be deployed across any number of regions.

[0064] Each region deployment of the intermediate data transmission layer 410 may include multiple intermediaries and nodes supporting various support and maintenance functions (e.g., service nodes, high-throughput proxy nodes, file cache nodes, repository nodes, etc.). As described below, intermediaries can be implemented by computer software or hardware that acts as a switchboard connecting clients to the AIOps service 422.

[0065] exist Figure 4 In the example diagram, AIOps service 422 and each client (and in some cases, each client's system) can be referred to as a "site". As used herein, a site can refer to a publisher or consumer of messages transmitted via an intermediate data transmission layer.

[0066] A site can have a unique identifier called a site ID. This site ID can be a simple printable string, such as a UUID, a public-DNS hostname, an email address with a location tag, etc. In various examples, to ensure uniqueness, all or part of the site ID can be assigned by an entity outside the site's control. In some examples, customers can use an automated registration process to obtain their site ID(s). In other examples, customers can obtain their site ID via a registration API.

[0067] In some examples, a site ID can be cryptographically bound to a site identity certificate, such as an X.509 certificate. These site identity certificates can be used for site authentication. An intermediate data transfer layer (e.g., HPE's RDA) can leverage hardware security devices (such as the Trust Platform Module) included within the site to verify the site identity certificate and its associated site identity.

[0068] As described above, sites (e.g., client / client systems, AIOps service 422) can connect to intermediate stations using data transfer tunnels instead of connecting to each other. These data transfer tunnels can be viewed as secure conduits between the site and the intermediate station. Each tunnel can be protected in various ways. For example, tunnels may require: (1) multiple forms of mutual authentication (e.g., via TLS, SSH, or IPSec); (2) authorization via access control mechanisms; and (3) the use of encrypted communication to prevent tampering and eavesdropping (e.g., multiple orthogonal encryption methods of numerical domains can be employed to improve resilience against decryption attacks). Additional mechanisms (e.g., maintaining security keys, tokens, and certificates) can also be used for security.

[0069] Although sites cannot connect directly, data can be transferred between them using a tunneling connection via a middleman. This combination of tunnels can be called a session. A session will be described in more detail using the following example.

[0070] In this example, client 432 subscribes to AIOps service 422. AIOps service 422 has performed analytics and determined that a notification must be sent to client 432.

[0071] To this end, AIOps service 422 (i.e., the session client) can first connect to the intermediary by establishing, authenticating, and authorizing a tunnel with the intermediary. Once the tunnel is established, authenticated, and authorized (e.g., using the site ID of AIOps service 422), AIOps service 422 can send a start session request to the intermediary. In response to the start session request, the intermediary can perform an authorization check via a session-level access control mechanism. This session-level access control mechanism can consider any number of factors, such as the session client / source site (e.g., AIOps service 422), the destination site (e.g., client 432), and the activity to be performed (sending / publishing notifications). For example, the intermediary's authorization check can verify that client 432 has subscribed to AIOps service 422 (e.g., the authorization check can verify that client 432's site ID appears on AIOps service 422's active subscriber list).

[0072] If the intermediate service's authorization check is permitted, the intermediate service sends a message along the tunnel to client 432 (i.e., the destination site) to request the establishment of a session. Client 432 can perform a second authorization check on the session request. This client-side check can verify that AIOps service 422 is a service that client 432 knows and trusts, that the connection is within an allowed time window, that client 432 has the right to use the service, and that client 432 has pre-subscribed to notification messages published by AIOps service 422. In some examples, the client can manage the client-side authorization check.

[0073] If both the intermediary authorization check and the client-side authorization check pass, an end-to-end session can be established. All of these actions can occur automatically and transparently.

[0074] In summary, a "session" can refer to the combination of a first tunnel to the AIOps service and a second tunnel to the client at the intermediary. A client or AIOps service can initiate a session by first establishing, authenticating, and authorizing a tunnel to the intermediary. For example, AIOps service 422 can initiate a session with client 432 by first establishing / authenticating / authorizing a first tunnel to the intermediary. Once the first tunnel is established / authenticated / authorized, AIOps service 422 can send a start session request to the intermediary, requesting to establish a session with client 432. In response to the start session request, the intermediary can perform an authorization check to determine if the session is authorized. If the intermediary's authorization check passes, client 432 can perform a second authorization check before establishing the session. Therefore, if both the intermediary's authorization check and client 432's authorization check pass, a session can be established between AIOps service 422 and client 432. In other words, the first tunnel to AIOps 422 only connects to the second tunnel to client 432 when the intermediate server and client 432 authorize AIOps 422 to initiate a session. This multi-faceted authorization / authentication process is part of the reason why the intermediate data transfer layer 410 can maintain the security and isolation of client data. Some additional notes regarding this authorization / authentication process are provided below.

[0075] First, the process is reversible. For example, client 432 could be the session client / origin site, while AIOps service 422 could be the destination site. In this reversible example, similar checks could be performed to authorize each side of the session.

[0076] Second, a given customer (and consequently its system) can connect to any intermediary in the world. Therefore, the firmware in the customer's interface with the intermediate data transmission layer (and / or in each customer system) can intelligently select the lowest latency, highest bandwidth, or other "optimal" connection path for the customer / customer system. For example, the firmware in customer 432's interface can determine that an intermediary in a first geographical region of the intermediate data transmission layer 410 is the optimal connection path for customer 432.

[0077] Third, without active authorization from the intermediary, tunnels may not connect to and / or communicate with each other (in some examples, each tunnel may run in a separate process, a separate namespace, and a separate cgroup, further isolating the tunnels from each other). Therefore, the intermediary in the illustrated architecture can be viewed as a gatekeeper facilitating secure “data transfer tunnels” that enable data transfer between a shared cloud-based AIOps service and its multiple clients.

[0078] Figure 5This is a schematic diagram of a publish / subscribe message bus communication link for an intermediate data transmission layer, based on various examples. In some examples, this publish / subscribe message bus communication link may be a feature of HPE's RDA (such as combined with...). Figure 4 (as described).

[0079] A publish / subscribe message bus communication link can refer to a communication system / link that allows message senders (i.e., publishers) to subscribe to read / consume messages published on one or more topics by data consumers. In this way, the publish / subscribe message bus communication link facilitates the transmission of data in the form of messages between multiple clients (i.e., clients 502, 504, and 506) and their subscribed public AIOps service (i.e., AIOps service 510). Here, the publish / subscribe message bus communication link also includes intermediaries, which act as switching boards connecting AIOps service 510 to its clients without requiring the clients to be connected to each other (i.e., through this architecture, a given client / client environment may never see messages sent by another client or messages intended for other clients).

[0080] For example, AIOps service 510 can determine that a notification must be sent to customers 502 and 506, but not 504 (e.g., the notification could relate to an anomaly detected in the operation of a temperature sensor used in machines owned by customers 502 and 506, but not to 504). Therefore, a publish / subscribe message bus communication link (which could be a combination of...) is used. Figure 4 (Described tunnel), AIOps service 510 can publish relevant notification messages to intermediate device 530. AIOps service 510 can also send a first start session request and a second start session request to intermediate device 530, requesting to start sessions with clients 502 and 506 respectively.

[0081] Such as combination Figure 4 In response to a session start request, the intermediary 530 can perform an authorization check by inspecting a session-level access control mechanism. This session-level access control mechanism can consider any number of factors, such as the session client / origin site, the destination site, and the activity to be performed. For example, a first intermediary authorization check can verify that client 502 has subscribed to notification messages published by AIOps service 510, and a second intermediary authorization check can verify that client 506 has subscribed to notification messages published by AIOps service 510.

[0082] If the intermediary's authorization check is permitted, the intermediary can send messages along separate tunnels to clients 502 and 506 respectively to request the establishment of a session. Each client can perform a second authorization check on the session request. This client-side check can verify that AIOps service 510 is a service known and trusted by the client, that the connection is within an allowed time window, and that the client has pre-subscribed to notification messages published by AIOps service 510. In some examples, each client can manage the client-side authorization check.

[0083] If the authorization checks for both the intermediary and the client pass, separate end-to-end sessions can be established between AIOps 510 and client 502, as well as between AIOps 510 and client 506. Therefore, notification messages from AIOps service 510 can be published to the notification topics subscribed to by clients 502 and 506.

[0084] Such as combination Figure 4 As described, the process can be reversed when any customer wants to publish to a topic subscribed to by AIOps service 510. For example, for the purpose of performing analytics, customer 504 might want to stream sensor data from its system to AIOps 510. Therefore, customer 504 can establish / authorize / authenticate a tunnel to intermediary 530 and send a start session request to intermediary 530, requesting to begin a session with AIOps service 510. Assuming both the intermediary and AIOps service 510 authorize the start session request, customer 504 can publish a message to the original metric topic, which data consumers residing in AIOps service 510 can pre-subscribe to read.

[0085] Figure 6 These are example computing systems that can be used to implement cloud-based AIOps services, based on various examples.

[0086] Now for reference Figure 6 The computing component 610 can be, for example, a server computer, a controller, or any other similar computing component capable of processing data. Figure 6 In the example implementation, computing component 610 includes hardware processor 612 and machine-readable storage medium for 614.

[0087] The hardware processor 612 may be one or more central processing units (CPUs), semiconductor-based microprocessors, and / or other hardware devices suitable for retrieving and executing instructions stored in the machine-readable storage medium 614. The hardware processor 612 may fetch, decode, and execute instructions, such as instructions 616-620, to control a burst preloading process or operation for estimating available bandwidth. Alternatively or supplementary to retrieving and executing instructions, the hardware processor 612 may include one or more electronic circuits comprising electronic components for the function of executing one or more instructions, such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other electronic circuits.

[0088] Machine-readable storage medium 614, such as machine-readable storage medium 614, can be any electrical, magnetic, optical, or other physical storage device that contains or stores executable instructions. Therefore, machine-readable storage medium 614 can be, for example, random access memory (RAM), non-volatile RAM (NVRAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some examples, machine-readable storage medium 614 can be a non-transient storage medium, where the term "non-transient" excludes transient propagation signals. As described in detail below, machine-readable storage medium 614 can be encoded with executable instructions, such as instructions 616-620. In various examples, the instructions can be executed dynamically.

[0089] As described above, computer system 600 can be used to implement cloud-based data analytics services (e.g., AIOps services). Therefore, hardware processor 612 can execute instructions 616 to cause the cloud-based data analytics service to receive customer sensor data associated with one or more systems of one or more customers. This customer sensor data can be received from an intermediate data transmission layer that connects the cloud-based analytics service to multiple customers while maintaining data isolation between customers.

[0090] Customer sensor data may include data associated with the operation of one or more of the customer's systems, including the operation of sensors within the systems(s). The customer's systems may include the customer's connected devices and infrastructure systems (which may include hardware and software systems). Therefore, an example of customer sensor data may include data associated with the coolant flow rate of the customer's coolant distribution unit.

[0091] Such as combination Figures 1-5As described, the intermediate data transmission layer can be a bidirectional data transmission layer that connects multiple clients to one or more cloud-based data analytics services while maintaining data isolation between clients. This intermediate data transmission layer can be a layered communication platform, such as HPE's Remote Device Access (RDA) platform. In various examples, this layered communication platform can use a "middleman server" ("middleman") and data transmission "tunnels" to establish a secure conduit between clients and the cloud-based data analytics services. A middleman can refer to a piece of computer software or hardware capable of combining a first data transmission tunnel to the client with a second data transmission tunnel to the cloud-based data analytics service. In this way, the middleman can establish a secure, dedicated conduit between clients and the cloud-based data analytics services.

[0092] As mentioned above, data transmission tunnels can be secured in various ways. For example, data transmission tunnels may require: (1) multiple forms of mutual authentication (e.g., via TLS, SSH, or IPSec); (2) authorization via access control mechanisms; and (3) the use of encrypted communication to prevent tampering and eavesdropping (e.g., orthogonal encryption methods in the digital domain can be employed to improve resilience against decryption attacks). Additional mechanisms (e.g., maintaining security keys, tokens, and certificates) can also be used for security.

[0093] Such as combination Figure 4 The term "session" can refer to the combination of a first tunnel to a customer and a second tunnel to a cloud-based data analytics service at the intermediary. To establish a session, a session client (e.g., a specific customer) can first connect to the intermediary by establishing / authorizing / authenticating to the intermediary. Once the tunnel is established / authorized / authenticated (e.g., by verifying the customer's unique identifier / site ID), the customer can send a start session request to the intermediary. In response to the start session request, the intermediary can perform a first authorization check by examining a session-level access control mechanism. This session-level access control mechanism can consider any number of factors, such as the session client (e.g., the customer), the destination (e.g., the cloud-based data analytics service), and the activity to be performed (sending the customer's sensor data to the cloud-based data analytics service). For example, the intermediary's authorization check could verify whether the customer requesting the session has subscribed to the cloud-based data analytics service.

[0094] If the intermediary's authorization check is permitted, the intermediary can send a message along the tunnel to the cloud-based data analytics service requesting to establish a session. The cloud-based data analytics service can then perform a second authorization check on the session request. This authorization check verifies that the customer is a customer known and trusted by the cloud-based data analytics service, that the connection is within the permitted time window, and that the customer has subscribed to the cloud-based data analytics service.

[0095] If both the intermediary and AIOps-side authorization checks pass, an end-to-end session can be established. All of these actions can occur automatically and transparently.

[0096] Such as combination Figure 4 As described, the process is reversible. For example, as will be described in conjunction with Instruction 620, a cloud-based data analytics service can modify the operation of (multiple) client systems via an intermediate data transfer layer by establishing a session with the client whose system is being modified or with the client system itself. In this reversal example, similar authorization checks can be performed to authorize each side of the session.

[0097] Such as combination Figure 5 As described, in various examples, the intermediate data transmission layer can utilize a publish / subscribe message bus communication link between a middleman and a cloud-based data analytics service. A publish / subscribe message bus communication link can refer to a communication system / link that allows a message sender (i.e., a publisher) to subscribe to read / consume messages published on one or more topics by a data consumer. Therefore, via the middleman and this publish / subscribe message bus communication link, a client (or its system) can publish messages to the cloud-based data analytics service about certain topics (e.g., sensor data topics), which the cloud-based data analytics service can pre-subscribe to consume / receive. These messages can be visible only to the cloud-based data analytics service. Through this link and the middleman, the cloud-based data analytics service can also publish messages to clients about certain topics (e.g., notifications and operational modification topics) that the client (or its system) can pre-subscribe to consume.

[0098] The hardware processor 612 can execute instructions 618 to enable cloud-based data analytics services to analyze customer sensor data.

[0099] This analysis can be performed in a variety of ways and used for a variety of purposes. For example, cloud-based analytics services performing analysis on customer sensor data can include detecting anomalies in customer system operations, performing root cause analysis, optimizing certain tasks / customer systems, predicting failures in customer systems, predicting that customer systems will reach certain capacity limits, and other types of analysis.

[0100] In some examples, cloud-based analytics services can use one or more trained machine learning models to perform data analysis. These models can be trained using historical data extracted from one or more customers. This historical data can be related to past operations of the customer's system. For example, historical data may include information associated with past raw metric / sensor data, previously detected anomalies, previous root cause analyses, information associated with optimizations of certain tasks / customer systems, previous notifications, previous operational modifications made in response to various analytical insights, etc. In other examples, these machine learning models can be trained using on-site / real-time customer data.

[0101] In some examples, cloud-based analytics services can select one of several trained machine learning models based on various factors such as the type of data being analyzed and the type of analysis being performed.

[0102] As an illustration, cloud-based analytics services can be dedicated to anomaly detection. Even for this single type of analysis, cloud-based analytics services can leverage multiple different trained machine learning models. As mentioned above, cloud-based analytics services can utilize individual machine learning models to detect operational anomalies in various types of customer systems. Even when analyzing a specific customer system (e.g., a customer's coolant distribution unit), cloud-based analytics services can utilize a separate machine learning model trained to detect anomalies for different operating parameters (e.g., coolant temperature, coolant flow rate, the relationship between coolant temperature and coolant flow rate, etc.). In another example, cloud-based analytics services can utilize machine learning models trained for different operating environments. For example, cloud-based analytics services can utilize separate machine learning models based on climate (e.g., hot and dry vs. cool and humid) or operating load (e.g., high vs. low, constant vs. intermittent, etc.).

[0103] As described above, cloud-based analytics services can use one or more trained machine learning models to perform various types of analysis (e.g., anomaly detection, root cause analysis, task / condition optimization, etc.) on customer sensor data from one or more customers. In response to this analysis, the cloud-based analytics service can determine which operational modifications are needed.

[0104] The hardware processor 612 can execute instructions 620 to cause a cloud-based data analytics service to modify the operation of one or more client systems in response to analytics performed during instructions 618. This modification can be directed at one or both of the client's software and hardware systems.

[0105] In some examples, the modification can be accomplished via an intermediate data transfer layer. For instance, as described in conjunction with instruction 616, a cloud-based data analytics service can modify the operation of one or more client systems via an intermediate data transfer layer by establishing a session with the client whose system is being modified or with the client system itself.

[0106] In some examples, cloud-based data analytics services can modify the operations of a client system by publishing one or more messages to a pre-subscribed operation modification topic on the client system (or a client's operation controller).

[0107] As mentioned above, cloud-based data analytics services can modify the systems of multiple customers in response to analytical insights derived from data from a single customer. This can happen when the analytical insights are relevant to more customers than to the single customer from whom the data originated. For example, a cloud-based data analytics service might discover a suboptimal condition of the temperature sensor on a coolant distribution unit while analyzing data from a first customer. A second customer might have a coolant distribution unit of the same brand / model with the same suboptimal temperature sensor conditions (which may not yet have been discovered / identified by the cloud-based data analytics service). Here, because the analytical insights are relevant to both customers, the cloud-based data analytics service can modify the operation of the coolant distribution units at both customer locations based on these insights.

[0108] Figure 7 It is another example computing system that can be used to implement cloud-based AIOps services, based on various examples.

[0109] Now for reference Figure 7 The computing component 710 can be, for example, a server computer, a controller, or any other similar computing component capable of processing data. Figure 7 In the example implementation, computing component 710 includes hardware processor 712 and machine-readable storage medium for 714.

[0110] The hardware processor 712 and the machine-readable storage medium 714 may be the same as or similar to the hardware processor 612 and the machine-readable storage medium 614, respectively. Therefore, the machine-readable storage medium 714 can be encoded with executable instructions, such as instructions 716-720. In various examples, the instructions can be executed dynamically.

[0111] Computer system 700 can be used to implement cloud-based data analytics services (e.g., AIOps services). Therefore, hardware processor 712 can execute instruction 716 to cause the cloud-based data analytics service to receive customer sensor data from one or more systems of one or more customers. This customer sensor data can be received from an intermediate data transmission layer that connects the cloud-based analytics service to multiple customers while maintaining data isolation between customers. This instruction can be the same as / similar to the instruction described in conjunction with instruction 616.

[0112] The hardware processor 712 can execute instructions 718 to enable a cloud-based data analytics service to analyze customer sensor data. These instructions may be the same as or similar to those described in conjunction with instructions 718.

[0113] The hardware processor 712 can execute instructions 720 to cause a cloud-based data analytics service to initiate actions in response to data analytics executed in conjunction with instructions 718.

[0114] Here, initiating an action can include any number of transactions, including but not limited to: modifying the operation of one or more customer systems; providing one or more customers with notifications related to one or more customer systems; and triggering on-site replacement of components of one or more customer systems.

[0115] Cloud-based data analytics services can modify the operation of one or more client systems in the same or similar manner as described in conjunction with Directive 620.

[0116] As described above, the notification can provide information about the operating conditions of the customer system analyzed during the execution of instruction 718. For example, a first notification can provide information about the detection of abnormal operation of a temperature sensor in a customer's coolant distribution unit. A second notification can provide information about a predicted fault in the electrical windings of another customer's generator. In response to a prediction that a given customer system will reach its capacity limit on a specific date, a third notification can provide recommendations that various resources used by the given customer system (e.g., memory, computer cores, disk space, network bandwidth, etc.) must be increased before a certain date.

[0117] Cloud-based data analytics services can deliver notifications via an intermediate data transmission layer by establishing a session with the customer being notified.

[0118] In some examples, cloud-based data analytics services can provide notifications to customers by publishing one or more messages to notification topics that customers have pre-subscribed to consume. In some examples, customers may have dashboards that pre-subscribe to consume messages published to notification topics. In this way, people at each customer location can be able to view notifications generated in response to real-time analytics insights from the cloud-based analytics service.

[0119] As described above, in response to analytical insights derived from data from a single customer, cloud-based data analytics services can provide notifications to multiple customers. This can happen when the analytical insights are relevant to more customers than to the single customer from whom the data originated. For example, a cloud-based data analytics service might detect an anomaly in the temperature sensor operation of a coolant distribution unit while analyzing data from a first customer. A second customer might have a coolant distribution unit of the same brand / model (which may or may not have the same anomalous temperature sensor operation). Here, because the analytical insight can be relevant to both customers (even if it is preventative for the second customer), the cloud-based data analytics service can provide notifications to both customer locations based on the insight.

[0120] Triggering on-site replacement of components in one or more customer systems can take many forms. For example, in response to a prediction that a temperature sensor in a customer's coolant distribution unit will fail within a month, a cloud-based data analytics service can schedule a replacement technician to replace the temperature sensor at the customer's site within a week. Similarly, a cloud-based data analytics service can order replacement parts for the customer and / or plan delivery to the customer's location.

[0121] Figure 8 These are example computing systems that can be used to participate in cloud-based AIOps services, based on various examples. In some examples, example computing system 800 may be the computing system of the first customer of a cloud-based data analytics service.

[0122] Now for reference Figure 8 The computing component 810 can be, for example, a server computer, a controller, or any other similar computing component capable of processing data. Figure 8 In the example implementation, computing component 810 includes hardware processor 812 and machine-readable storage medium for 814.

[0123] The hardware processor 812 and the machine-readable storage medium 814 may be the same as or similar to the hardware processor 612 and the machine-readable storage medium 614, respectively. Therefore, the machine-readable storage medium 814 may utilize executable instruction encoding, such as instructions 816-820. In various examples, the instructions may be executed dynamically.

[0124] The hardware processor 812 can execute instructions 816 to provide sensor data from a first customer to a cloud-based data analytics service via an intermediate data transmission layer. The sensor data from the first customer may be data associated with one or more systems of the first customer.

[0125] Here, the sensor data from the first customer and the intermediate data transmission layer can be the same as / similar to those described in conjunction with the preceding figures. Therefore, the hardware processor 812 can provide the sensor data from the first customer to the cloud-based data analytics service via the intermediate data transmission layer in the same / similar manner as described in conjunction with those figures.

[0126] The hardware processor 812 can execute instructions 818 to receive, via an intermediate data transmission layer, a notification generated by the cloud-based data analytics service in response to the analysis of sensor data from a second client by the cloud-based data analytics service. Here, the notification and the intermediate data transmission layer can be the same as / similar to those described in conjunction with the preceding figures. Therefore, the hardware processor 812 can receive the notification from the cloud-based data analytics service via the intermediate data transmission layer in the same / similar manner as described in conjunction with those figures.

[0127] Here, the computing system 800 is associated with the first customer (not the second customer). However, the notification received by the hardware processor 812 is in response to a cloud-based data analytics service. Second customer data This is generated through analysis. A particular benefit of the systems / architectures described above is that they can facilitate the sharing of insights across a large customer base while maintaining the isolation of each customer's data from other customers. For example, the first customer located in San Diego, California, can immediately (or nearly immediately) benefit from insights gained by analyzing data from a second customer located in Melbourne, Australia.

[0128] The hardware processor 812 can execute instructions 820 based on the notification to modify one or more operations in the first customer system. This can be achieved in many ways. For example, the notification may relate to an abnormal operation of a temperature sensor in a coolant distribution unit of a second customer's coolant distribution unit. The notification may include information about the abnormal operation, such as a set of instructions that can be used to verify whether a temperature sensor on a coolant distribution unit of the first customer's coolant distribution unit exhibits the same / similar abnormal operation. The notification may also include a set of instructions on how to modify the operation of the coolant distribution unit and / or the temperature sensor to fix the problem. Therefore, the hardware processor 812 can follow these instructions to determine whether operational modification is needed, and if so, perform the operational modification.

[0129] Figure 9 A block diagram depicts an example computer system 900 in which various examples described herein may be implemented. The computer system 900 includes a bus 902 or other communication mechanism for transmitting information, and one or more hardware processors 904 coupled to the bus 902 for processing information. The hardware processors 904 may be, for example, one or more general-purpose microprocessors.

[0130] Computer system 900 also includes main memory 906, such as random access memory (RAM), cache, and / or other dynamic storage devices, coupled to bus 902, for storing information and instructions to be executed by processor 904. Main memory 906 can also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by processor 904. When stored in storage media accessible to processor 904, these instructions present computer system 900 as a special-purpose machine customized to perform the operations specified in the instructions.

[0131] The computer system 900 also includes a read-only memory (ROM) 908 or other static storage device coupled to a bus 902 for storing static information and instructions of the processor 904. A storage device 910, such as a disk, optical disk, or USB thumb drive (flash drive), is provided and coupled to the bus 902 for storing information and instructions.

[0132] Computer system 900 can be coupled via bus 902 to display 912, such as a liquid crystal display (LCD) (or touchscreen), for displaying information to the computer user. Input device 914, including alphanumeric keys and other keys, is coupled to bus 902 for transmitting information and command selections to processor 904. Another type of user input device is cursor control 914, such as a mouse, trackball, or arrow keys, for transmitting directional information and command selections to processor 904 and for controlling cursor movement on display 912. In some examples, the same directional information and command selections can be achieved by receiving touches on a touchscreen without a cursor.

[0133] The computing system 900 may include a user interface module that implements a graphical user interface, which may be stored as executable software code executed by computing devices(s). This module and other modules may include components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0134] Generally, the terms “component,” “engine,” “system,” “database,” and “data storage” used herein can refer to logic contained in hardware or firmware, or to a collection of software instructions that may have entry and exit points written in programming languages ​​such as Java, C, or C++. Software components can be compiled and linked into executable programs installed in dynamic link libraries, or can be written in interpreted programming languages ​​such as BASIC, Perl, or Python. It should be understood that software components can be invoked from other components or themselves, and / or can be invoked in response to detected events or interrupts. Software components configured to execute on a computing device can be provided on a computer-readable medium such as optical discs, digital video discs, flash drives, magnetic disks, or any other tangible medium, or as digital downloads (and can initially be stored in a compressed or installable format that needs to be installed, decompressed, or decrypted before execution). Such software code can be stored, in part or in whole, on a storage device executing the computing device. Software instructions can be embedded in firmware such as EPROM. It should also be understood that hardware components may include interconnected logic units, such as gates and flip-flops, and / or may include programmable units, such as programmable gate arrays or processors.

[0135] Computer system 900 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic, which, in conjunction with the computer system, make computer system 900 a special-purpose machine or program computer system 900 as a special-purpose machine. According to one example, the techniques herein are executed by computer system 900 in response to processor(s) 904 executing one or more sequences of one or more instructions contained in main memory 906. Such instructions can be read into main memory 906 from another storage medium, such as storage device 910. Execution of the instruction sequence contained in main memory 906 causes processor(s) 904 to perform the processing steps described herein. In alternative examples, hardwired circuitry can be used in place of or in combination with software instructions.

[0136] As used herein, the term "non-transient medium" and similar terms refer to any medium that stores data and / or instructions that enable a machine to operate in a particular manner. Such non-volatile medium can include both non-volatile and / or volatile media. Non-volatile media include, for example, optical discs or magnetic disks, such as storage device 910. Volatile media include dynamic memory, such as main memory 906. Common forms of non-transient media include, for example, floppy disks, hard disks, solid-state drives, magnetic tape or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a perforated pattern, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassette tapes, and their network versions.

[0137] Non-transient media differ from transmission media, but can be used in conjunction with them. Transmission media participate in the transmission of information between non-transient media. For example, transmission media include coaxial cables, copper wires, and optical fibers, including the cables that make up bus 902. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication.

[0138] Computer system 900 also includes a network interface 918 coupled to bus 902. Network interface 918 provides bidirectional data communication coupling with one or more network links connected to one or more local networks. For example, network interface 918 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or modem to provide data communication connectivity to a corresponding type of telephone line. As another example, network interface 918 may be a Local Area Network (LAN) card to provide data communication connectivity to a compatible LAN (or a WAN component communicating with a WAN). Wireless links may also be implemented. In any such implementation, network interface 918 transmits and receives electrical, electromagnetic, or optical signals carrying streams of digital data representing various types of information.

[0139] A network link typically provides data communication to other data devices via one or more networks. For example, a network link can provide a connection to a host computer or to a data device operated by an Internet Service Provider (ISP) via a local network. The ISP, in turn, provides data communication services through a global packet data communication network now commonly referred to as the "Internet." Both local networks and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. Signals carried by various networks and by network interfaces 918, carrying digital data to and from computer systems 900, are example forms of transmission media.

[0140] Computer system 900 can send messages and receive data, including program code, through (multiple) networks, network links, and network interface 918. In the example of the Internet, the server can send application request codes through the Internet, ISP, local network, and network interface 918.

[0141] The received code can be executed by processor 904 when it is received, and / or stored in storage device 910 or other non-volatile memory for later execution.

[0142] Each process, method, and algorithm described in the foregoing sections may be contained in a code component executed by one or more computer systems or computer processors, including computer hardware, and may be fully or partially automated by the code component. One or more computer systems or computer processors may also operate to support the performance of the associated operations, which may occur in a “cloud computing” environment or as “Software as a Service” (SaaS). These processes and algorithms may be implemented, partially or entirely, in dedicated circuitry. The various features and processes described above may be used independently of each other or may be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of this disclosure, and certain method or process boxes may be omitted in some implementations. The methods and processes described herein are not limited to any particular sequence, and the boxes or states associated with them may be executed in other suitable sequences, or may be executed in parallel, or in some other manner. Boxes or states may be added to or removed from the disclosed examples. The execution of certain operations or processes may be distributed among computer systems or computer processors, residing not only within a single machine but also deployed across multiple machines.

[0143] As used herein, the circuit can be implemented using any form of hardware, software, or a combination thereof. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FGAs, logic components, software routines, or other mechanisms can be used to construct the circuit. In implementations, the various circuits described herein can be implemented as discrete circuits, or the described functions and features can be shared partially or entirely among one or more circuits. Even if the various features or elements of the functionality can be described or claimed separately as separate circuits, these features and functions can be shared among one or more common circuits, and such description does not require or imply the need for separate circuits to implement these features or functions. In cases where the circuit is implemented entirely or partially using software, such software can be implemented to operate with a computing or processing system, such as computer system 900, capable of performing the functions described herein.

[0144] As used herein, the term “or” may be interpreted as inclusive or exclusive. Furthermore, descriptions of resources, operations, or structures in the singular form should not be construed as excluding the plural form. Conditional language, such as, among others, “may,” “can,” “able,” or “may,” unless specifically stated or otherwise understood in the context in which they are used, is generally intended to convey that some examples include certain features, elements, and / or steps, while other examples do not.

[0145] Unless otherwise expressly stated, the terms and phrases used in this document, and their variations thereof, should be interpreted as open-ended, not restrictive. Adjectives and terms with similar meanings such as “regular,” “traditional,” “normal,” “standard,” “known,” etc., should not be interpreted as limiting the described item to a given time period or items available at a given time, but should be understood to include regular, traditional, normal, or standard techniques that may be available or known at any time now or in the future. In some cases, the appearance of expansive words and phrases such as “one or more,” “at least,” “but not limited to,” or other similar phrases should not be interpreted as an intention or necessity to narrow the scope where such expansive phrases could be used.

Claims

1. A computer-implemented method, comprising: In response to the establishment of a first data transmission tunnel between the first client computer system and the intermediate data transmission layer, a second data transmission tunnel is established by the cloud-based data analytics service from the cloud-based data analytics service to the intermediate device. The intermediate unit includes computer hardware or software serving as a switching board that connects the first data transmission tunnel to the first client computer system and the second data transmission tunnel to the cloud-based data analytics service. The intermediary accesses the publish / subscribe message bus between the first client computer system, the intermediary, and the cloud-based data analytics service to enable communication between the cloud-based data analytics service and the first client computer system. The publish / subscribe message bus receives a publish message from the first client computer system and delivers the publish message to the cloud-based data analytics service. In response to the intermediate data transmission layer combining the first data transmission tunnel and the second data transmission tunnel at the intermediate device and establishing the publish / subscribe message bus, the cloud-based data analytics service receives sensor data from the client computer system via the first data transmission tunnel and the second data transmission tunnel; The cloud-based data analytics service generates sensor data insights from the sensor data; as well as In response to generating the sensor data insights, the cloud-based data analytics service transmits the sensor data insights to a second client computer system via the publish / subscribe messaging bus, without providing the sensor data from the first client computer system to the second client computer system; and Based on the sensor data insights, initiate one or more actions to optimize the second client computer system or make changes to the second client computer system.

2. The computer-implemented method of claim 1, wherein the intermediary is a first intermediary, and wherein initiating the one or more actions comprises: A third data transmission tunnel is established by the cloud-based data analytics service, from the cloud-based data analytics service to the second intermediate device of the intermediate data transmission layer; The cloud-based data analytics service sends a request to the second intermediary to initiate a session with the second client computer system; as well as In response to the establishment of a fourth data transmission tunnel from the second client computer system to the second intermediary and its combination with the third data transmission tunnel at the second intermediary, the cloud-based data analytics service initiates at least one of the following actions via the combined third and fourth data transmission tunnels: Modify the operation of one or more systems in the second client computer system; Provide notifications relating to one or more systems in the system of the second client computer system; as well as Triggering on-site replacement of components of one or more systems in the second customer computer system.

3. The computer-implemented method according to claim 2, wherein the intermediate data transmission layer includes a publish / subscribe message bus communication link.

4. The computer-implemented method of claim 3, wherein the operation of modifying the given system of the client includes: The cloud-based data analytics service publishes an operation modification message to the operation modification topic subscribed to by the first client computer system via the publish / subscribe message bus communication link.

5. The computer-implemented method of claim 3, wherein providing a notification to the first client computer system comprises: The cloud-based data analytics service publishes notification messages to the dashboard subscription notification topics located at the site of the first client computer system via the publish / subscribe message bus communication link.

6. The computer-implemented method of claim 2, wherein the first intermediate unit and the second intermediate unit comprise the same intermediate unit.

7. The computer-implemented method according to claim 1, wherein: At the intermediate unit, the first data transmission tunnel to the customer is combined with the second data transmission tunnel to the cloud-based data analytics service, and a session is established between the customer and the cloud-based data analytics service. as well as Before the session is established, the session must be authorized by the intermediary and at least one of the following: the cloud-based data analytics service and the client.

8. The computer-implemented method of claim 7, wherein the first data transmission tunnel to the customer cannot be combined with a data transmission tunnel to another customer.

9. The computer-implemented method of claim 1, wherein analyzing the sensor data comprises at least one of the following: Abnormal detection; Predicting failures; Predicted capacity limitations; Perform root cause analysis; and Optimize the first customer's computer system.

10. The computer-implemented method of claim 2, wherein the first intermediate device and the second intermediate device comprise different intermediate devices.

11. The computer-implemented method of claim 1, wherein the intermediate data transmission layer connects the cloud-based analytics service to multiple client computer systems while maintaining data isolation between the multiple client computer systems.

12. The computer-implemented method according to claim 1, further comprising: Before establishing the second data transmission tunnel, the session-level access control of the first client computer system is determined, including the session client / source site, the destination site, and the action to be performed. as well as Before establishing the second data transmission tunnel, determine the subscription status of the first client computer system when it subscribes to the sensor data insights from the cloud-based data analytics service.

13. A cloud-based data analysis system, comprising: At least one processor; as well as A memory storing instructions that, when executed by the at least one processor, cause the cloud-based data analytics system to perform a method, the method comprising: In response to the establishment of a first data transmission tunnel between the first client computer system and a first intermediate device in the intermediate data transmission layer, a second data transmission tunnel is established from the cloud-based data analytics system to the first intermediate device. The intermediate unit includes computer hardware or software serving as a switching board that connects the first data transmission tunnel to the first client computer system and the second data transmission tunnel to the cloud-based data analysis system. The first intermediary accesses the publish / subscribe message bus between the first client computer system, the first intermediary, and the cloud-based data analytics system to enable communication between the cloud-based data analytics system and the first client computer system. The publish / subscribe message bus receives a publish message from the first client computer system and delivers the publish message to the cloud-based data analysis system. In response to the intermediate data transmission layer combining the first data transmission tunnel and the second data transmission tunnel at the first intermediary and establishing the publish / subscribe message bus, sensor data is received from the first client computer system via the first data transmission tunnel and the second data transmission tunnel; Generate sensor data insights from the sensor data: In response to the generation of the sensor data: Establish a third data transmission tunnel from the cloud-based data analysis system to the second intermediate device in the intermediate data transmission layer; Send a request to initiate a session with the first client computer system; and In response to the establishment of a fourth data transmission tunnel from the first client computer system to the second intermediary and its combination with the third data transmission tunnel at the second intermediary, based on the sensor data insights into the operation of the system that modifies the first client computer system via the combined third and fourth data transmission tunnels, one or more actions are initiated to optimize the second client computer system or to make changes to the second client computer system.

14. The cloud-based data analysis system according to claim 13, wherein the first intermediate unit and the second intermediate unit comprise the same intermediate unit.

15. The cloud-based data analysis system according to claim 13, wherein: At the first intermediary, the first data transmission tunnel leading to the first client computer system is combined with the second data transmission tunnel leading to the cloud-based data analysis system, and a session is established between the first client computer system and the cloud-based data analysis system. as well as Before the session is established, it must be authorized by the first intermediary and at least one of the following: the cloud-based data analytics system and the first client computer system.

16. The cloud-based data analysis system of claim 15, wherein the first data transmission tunnel to the first client computer system cannot be combined with a data transmission tunnel to another client computer system.

17. The cloud-based data analysis system according to claim 16, wherein the intermediate data transmission layer includes a publish / subscribe message bus communication link.

18. The cloud-based data analysis system according to claim 17, wherein the operation of modifying the first client computer system includes: An operation modification message is published to the system-subscribed operation modification topic of the first client computer system via the publish / subscribe message bus communication link.

19. The cloud-based data analysis system according to claim 13, wherein the first intermediate unit and the second intermediate unit comprise different intermediate units.

20. A non-transient computer-readable storage medium comprising instructions that, when executed by at least one processor of a computing system, cause the computing system to perform a method, the method comprising: Establish the first data transmission tunnel from the first client computer system to the intermediate data transmission layer. The intermediary includes computer hardware or software that operates a switching board that connects the first data transmission tunnel to the first client computer system and the second data transmission tunnel to a cloud-based data analytics service. The intermediary sends a request to initiate a session with the cloud-based data analytics service; The intermediary accesses the publish / subscribe message bus between the first client computer system, the intermediary, and the cloud-based data analytics service to enable communication between the cloud-based data analytics service and the first client computer system. The publish / subscribe message bus receives a publish message from the first client computer system and delivers the publish message to the cloud-based data analytics service. In response to the establishment of a second data transmission tunnel from the cloud-based data analytics service to the intermediate station and its combination with the first data transmission tunnel at the intermediate station and the establishment of the publish / subscribe message bus, sensor data is provided to the cloud-based data analytics service via the combined first and second data transmission tunnels; Generate sensor data insights from the sensor data; In response to generating the sensor data insight, the sensor data insight is transmitted to the second client computer system via the publish / subscribe message bus without providing the sensor data from the first client computer system to the second client computer system; as well as Based on the sensor data insights, initiate one or more actions to optimize the second client computer system or make changes to the second client computer system.

21. The non-transient computer-readable storage medium of claim 20, wherein the intermediate data transmission layer connects the cloud-based analytics service to multiple client computer systems while maintaining data isolation between the multiple client computer systems.

Images