US20170192628A1

US20170192628A1 - System, method, and machine-readable medium for simultaneously displaying connected industrial assets in multiple display modes

Info

Publication number: US20170192628A1
Application number: US15/151,206
Authority: US
Inventors: Sean P. O'Connor; Kristin Anderson; Clement Chi
Original assignee: General Electric Co
Current assignee: General Electric Co
Priority date: 2015-12-31
Filing date: 2016-05-10
Publication date: 2017-07-06
Also published as: US20190079504A1; US10156841B2; US20170192414A1; US10234853B2; US20190079505A1; US10444743B2; WO2017117348A1; US20170195332A1; US10156842B2; US20170195331A1; US10719071B2

Abstract

This disclosure provides for a system and method for managing network-connected industrial assets. A user may request monitored data for one or more of the network-connected industrial assets using a client device that is communicatively coupled to an Industrial Internet of Things (IIoT) machine. The IIoT machine monitors and records data for various metrics for one or more industrial assets communicatively coupled to the IIoT machine. Using the client device, the user can request the display of various views of the one or more industrial assets including a hierarchical tree structure and a topology view. Furthermore, the hierarchical tree structure and topology view are designed to be simultaneously displayed by the client device so that the user can view information about a selected industrial asset from either the hierarchical tree structure, the topology view, or both.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority to U.S. Pat. App. No. 62/273,782, titled “SYSTEMS AND METHODS FOR MANAGING INDUSTRIAL ASSETS” and filed Dec. 31, 2015, the disclosure of which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

The subject matter disclosed herein generally relates to displaying connections between network-connected devices and, in particular, to simultaneously displaying different display modes within the same graphical user interface, where each display mode displays corresponding network-connected devices.

BACKGROUND

Software-implemented processes have a direct influence over many aspects of society. Digital consumer companies are disrupting the old guard and changing the way we live and do business in fundamental ways. For example, recent companies have disrupted traditional business models for taxis, hotels, and car rentals by leveraging software-implemented processes and interfaces to create new business models that better address consumers' needs and wants.
An Internet of Things (IoT) has developed over at least the last decade, representing a network of physical objects or “things” with embedded software that enables connectivity with other similar or dissimilar things. In some examples, connected things can exchange information, or can receive remote instructions or updates, for example via the Internet. Such connectivity can be used to augment a device's efficiency or efficacy, among other benefits.
Similar to the way that consumer device connectivity is changing consumers' lifestyles, embedded software and connectivity among industrial assets presents an opportunity for businesses to alter and enhance operations, for example, in fields of manufacturing, energy, agriculture, or transportation, among others. This connectivity among industrial assets is sometimes referred to as the Industrial Internet of Things (IIoT).
Industrial Internet applications are typically isolated, one-off implementations. However, these implementations limit the opportunities to create economies of scale, and fall short of unlocking the potential of connecting multiple machines and data around the globe.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings.

FIG. 1 is a block diagram illustrating an asset management platform, according to an example embodiment.

FIG. 2 is a block diagram illustrating different edge connectivity options that an IIoT machine provides, in accordance with an example embodiment.

FIG. 3 illustrates a client device of FIG. 2, according to an example embodiment.

FIG. 4 illustrates a graphical user interface that displays a hierarchical tree structure, according to an example embodiment.

FIG. 5 illustrates asset information displayed for an industrial asset selected from the hierarchical tree structure of FIG. 4, according to an example embodiment.

FIG. 6 illustrates a second graphical user interface that displays a second hierarchical tree structure, according to an example embodiment.

FIG. 7 illustrates a third graphical user interface that displays a topology view corresponding to the second hierarchical tree structure of FIG. 6, according to an example embodiment.

FIG. 8 illustrates the graphical user interface of FIG. 7 where a group node has been selected for viewing, according to an example embodiment.

FIG. 9 illustrates another graphical user interface that includes the display of a hierarchical tree structure and a corresponding topology view, according to an example embodiment.

FIGS. 10A-10C illustrate a method, in accordance with an example embodiment, for displaying connected industrial assets as a hierarchical tree structure and/or in a topology view.

FIG. 11 is a block diagram illustrating components of a machine, according to some example embodiments, able to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION

This disclosure provides a system, method, and machine-readable medium for simultaneously displaying a hierarchical tree structure of connected industrial assets and a topology view of those connected industrial assets, where the industrial assets are either in communication with or connected to an IIoT machine. The technical benefit provided by this disclosure is the simultaneous display of connected industrial assets in two different viewing modes within the same graphical user interface of a client or interface device in communication with the IIoT machine. In this manner, a user can interact with the hierarchical tree structure and/or the topology view without having to instantiate a new graphical user interface or depart from the currently viewed graphical user interface.
Accordingly, in one embodiment, this disclosure provides a system that includes a machine-readable medium storing computer-executable instructions, and at least one hardware processor communicatively coupled to the machine-readable medium that, when the computer-executable instructions are executed, configures the system to display a hierarchical tree structure comprising a first plurality of nodes, wherein a first node selected from the first plurality of nodes represents a network-connected industrial asset, and receives a selection to display a topology view corresponding to the hierarchical tree structure, with the topology view comprising a second plurality of nodes, wherein a first node selected from the second plurality of nodes represent the network-connected industrial asset. The at least one hardware processor further configures the system to determine a location to display the topology view, with the location being determined based on the second plurality of nodes, and display the topology view at the determined location, wherein a second node selected from the second plurality of nodes is designated as a central node of the topology view, and one or more nodes of the second plurality of nodes are displayed connected to a perimeter of the central node. In addition, the hierarchical tree structure and the topology view are displayed within the same graphical user interface.
This disclosure also describes a method that includes displaying, by at least one hardware processor, a hierarchical tree structure comprising a first plurality of nodes, wherein a first node selected from the first plurality of nodes represents a network-connected industrial asset, and receiving, by at least one hardware processor, a selection to display a topology view corresponding to the hierarchical tree structure, with the topology view comprising a second plurality of nodes, wherein a first node selected from the second plurality of nodes represents the network-connected industrial asset. The method further includes determining, by at least one hardware processor, a location to display the topology view, the location being determined based on the second plurality of nodes, and displaying, by at least one hardware processor, the topology view at the determined location, wherein a second node selected from the second plurality of nodes is designated as a central node of the topology view, and one or more nodes of the second plurality of nodes are displayed connected to a perimeter of the central node. Finally, the hierarchical tree structure and the topology view are displayed within the same graphical user interface.
Furthermore, this disclosure provides for a machine-readable medium comprising computer-executable instructions that, when executed by at least one hardware processor, causes a system to perform a plurality of operations, the operations comprising displaying a hierarchical tree structure comprising a first plurality of nodes, wherein a first node selected from the first plurality of nodes represents a network-connected industrial asset, and receiving a selection to display a topology view corresponding to the hierarchical tree structure, with the topology view comprising a second plurality of nodes, wherein a first node selected from the second plurality of nodes represent the network-connected industrial asset. The plurality of operations also include determining a location to display the topology view, the location being determined based on the second plurality of nodes displaying the topology view at the determined location, wherein a second node selected from the second plurality of nodes is designated as a central node of the topology view, and one or more nodes of the second plurality of nodes are displayed connected to a perimeter of the central node. The hierarchical tree structure and the topology view are displayed within the same graphical user interface.
Unless explicitly stated otherwise, components and functions are optional and may be combined or subdivided, and operations may vary in sequence or be combined or subdivided. In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of example embodiments. It will be evident to one skilled in the art, however, that the present subject matter may be practiced without these specific details.
Industrial equipment or assets, generally, are engineered to perform particular tasks as part of a business process. For example, industrial assets can include, among other things and without limitation, manufacturing equipment on a production line, wind turbines that generate electricity on a wind farm, healthcare or imaging devices (e.g., X-ray or MRI systems) for use in patient care facilities, or drilling equipment for use in mining operations. The design and implementation of these assets often takes into account both the physics of the task at hand and the environment in which such assets are configured to operate.
Low-level software and hardware-based controllers have long been used to drive industrial assets. However, with the rise of inexpensive cloud computing, increasing sensor capabilities, and decreasing sensor costs, as well as the proliferation of mobile technologies, there are new opportunities to enhance the business value of some industrial assets.
While progress with industrial equipment automation has been made over the last several decades, and assets have become ‘smarter,’ the intelligence of any individual asset pales in comparison to intelligence that can be gained when multiple smart devices are connected together. Aggregating data collected from or about multiple assets can enable users to improve business processes (for example, by improving effectiveness of asset maintenance or improving operational performance).
In an example, an industrial asset can be outfitted with one or more sensors configured to monitor an asset's operations or conditions. The date from the one or more sensors can be recorded or transmitted to a cloud-based or other remote computing environment. By bringing such data into a cloud-based computing environment, new software applications can be constructed, and new physics-based analytics can be created. Insights gained through analysis of such data can lead to enhanced asset designs, or to enhanced software algorithms for operating the same or similar asset at its edge, that is, at the extremes of its expected or available operating conditions.
Systems and methods described herein are configured for managing industrial assets. In an example, information about industrial assets and their use conditions, such as gathered from sensors embedded at or near industrial assets themselves, can be aggregated, analyzed, and processed in software residing locally or remotely from the assets. In an example, applications configured to operate at a local or remote processor can be provided to optimize an industrial asset for operation in a business context. In an example, a development platform can be provided to enable end-users to develop their own applications for interfacing with and optimizing industrial assets and relationships between various industrial assets and the cloud. Such end-user-developed applications can operate at the device, fleet, enterprise, or global level by leveraging cloud or distributed computing resources.
The systems and methods for managing industrial assets can include or can be a portion of an (IIoT. In an example, an IIoT connects industrial assets, such as turbines, jet engines, and locomotives, to the Internet or cloud, or to each other in some meaningful way. The systems and methods described herein can include using a “cloud” or remote or distributed computing resource or service. The cloud can be used to receive, relay, transmit, store, analyze, or otherwise process information for or about one or more industrial assets.
In an example, a cloud computing system includes at least one processor circuit, at least one database, and a plurality of users or assets that are in data communication with the cloud computing system. The cloud computing system can further include or can be coupled with one or more other processor circuits or modules configured to perform a specific task, such as to perform tasks related to asset maintenance, analytics, data storage, security, or some other function, as further described herein.
In an example, a manufacturer of industrial assets can be uniquely situated to leverage its understanding of industrial assets themselves, models of such assets, and industrial operations or applications of such assets, to create new value for industrial customers through asset insights. In an example, an asset management platform (AMP) can incorporate a manufacturer's asset knowledge with a set of development tools and best practices that enables asset users to bridge gaps between software and operations to enhance capabilities, foster innovation, and ultimately provide economic value.
In an example, an AMP includes a device gateway that is configured to connect multiple industrial assets to a cloud computing system. The device gateway can connect assets of a particular type, source, or vintage, or the device gateway can connect assets of multiple different types, sources, or vintages. In one embodiment, the multiple connected assets belong to different asset communities (e.g., logical and/or physical groups of assets that are assigned by the end user and/or by the AMP), and the asset communities are located remotely or locally to one another. The multiple connected assets are in use (or non-use) under similar or dissimilar environmental conditions, or can have one or more other common or distinguishing characteristics. For example, information about environmental or operating conditions of an asset or an asset community can be shared with the AMP. Using the AMP, operational models of one or more assets can be improved and subsequently leveraged to optimize assets in the same community or in a different community.
FIG. 1 is a block diagram illustrating an AMP 102, according to an example embodiment. In various embodiments, one or more portions of the AMP 102 reside in an asset cloud computing system 104, in a local or sandboxed environment, or are distributed across multiple locations or devices. The AMP 102 may be configured to perform any one or more of data acquisition, data analysis, or data exchange with local or remote assets or with other task-specific processing devices.
In one embodiment, the AMP 102 includes an asset community 106 that is communicatively coupled with the asset cloud computing system 104. An IIoT machine 108 is communicatively coupled with one or more of the assets of the asset community 106. The IIoT machine 108 receives information from, or senses information about, at least one asset member 110 of the asset community 106, and configures the received information for exchange with the asset cloud computing system 104. In one embodiment, the IIoT machine 108 is communicatively coupled to the asset cloud computing system 104 or to an enterprise computing system 112 via a communication gateway 114. The communication gateway 114 may use one or more wired and/or wireless communication channels that extends at least from the IIoT machine 108 to the asset cloud computing system 104.
In one embodiment, the asset cloud computing system 104 is configured with several different and/or similar layers. For example, the asset cloud computing system 104 may include a data infrastructure layer 116, a Cloud Foundry layer 118, and one or more modules 120-128 for providing various functions. In one embodiment, the data infrastructure layer 116 provides applications and/or services for accessing data maintained by the asset cloud computing system 104. In addition, the Cloud Foundry layer 118 executes Cloud Foundry, which is an Open Source platform-as-a-service (PaaS) that supports multiple developer frameworks and an ecosystem of application services. Cloud Foundry facilitates the development and scaling of various applications. Cloud Foundry is available from Pivotal Software, Inc., which is located in Palo Alto, Calif.
Furthermore, and as shown in FIG. 1, the asset cloud computing system 104 includes an asset module 120, an analytics module 122, a data acquisition module 124, a data security module 126, and an operations module 128. Each of the modules 120-128 includes or uses a dedicated circuit, or instructions for operating a general purpose processor circuit, to perform the respective functions. In an example, the modules 120-128 are communicatively coupled in the asset cloud computing system 104 such that information from one module can be shared with another. The modules 120-128 may be co-located at a designated datacenter or other facility, or the modules 120-128 may be distributed across multiple different locations.
The asset cloud computing system 104 may be accessible and/or provide information to one or more industrial applications and/or data centers 132-138. For example, the cloud computing system 104 may provide information to one or more devices in the energy industry 132, one or more devices in the healthcare industry 134, one or more devices in the transportation industry 136, and/or one or devices that are connected as an IoT for industry 138. In this manner, the asset cloud computing system 104 becomes a distribution center for various industry devices 132-138 such that any one device may access the asset cloud computing system 104 for information about one or more assets in the asset community 106.
Furthermore, and in one embodiment, the AMP 102 is communicatively coupled with an interface device 130. The interface device 130 may be configured for data communication with one or more of the IIoT machine 108, the communication gateway 114, or the asset cloud computing system 104. The interface device 130 may be used to monitor or control one or more assets of the asset community 106. For example, and in one embodiment, information about the asset community 106 is presented to an operator at the interface device 130. The information about the asset community 106 may include, but is not limited to, information from the IIoT machine 108, information from the asset cloud computing system 104, information from the enterprise computing system 112, or combinations thereof. In one embodiment, the information from the asset cloud computing system 104 includes information about the asset community 106 in the context of multiple other similar or dissimilar assets, and the interface device 130 may include options for optimizing one or more members of the asset community 106 based on analytics performed at the asset cloud computing system 104.
One or more of the assets of the asset community 106 may be configurable by way of one or more parameters being updated by the interface device 130. For example, where an asset 110 is a wind turbine, an operator of the interface device 130 may request that a parameter for the wind turbine 110 be updated, and that parameter update is pushed to the wind turbine 110 via one or more of the devices of the AMP 102, such as the asset cloud computing system 104, the communication gateway 114, and the IIoT machine 108, or combinations thereof.
Further still, the interface device 130 may communicate with the enterprise computing system 112 to provide enterprise-wide data about the asset community 106 in the context of other business or process data. For example, choices with respect to asset optimization can be presented to an operator in the context of available or forecasted raw material supplies or fuel costs. In an example, choices with respect to asset optimization can be presented to an operator in the context of a process flow to identify how efficiency gains or losses at one asset can impact other assets. In an example, one or more choices described herein as being presented to a user or operator can alternatively be made automatically by a processor circuit according to earlier-specified or programmed operational parameters. In an example, the processor circuit can be located at one or more of the interface device 130, the asset cloud computing system 104, the enterprise computing system 112, or elsewhere.
In one embodiment, the asset community 106 includes one or more wind turbines as assets, such as the wind turbine 110. A wind turbine is a non-limiting example of a type of industrial asset that can be a part of, or in data communication with, the AMP 102. In another embodiment, the asset community 106 includes one or more healthcare-related devices as assets, such as imaging devices (e.g., an MRI scanner), biometric monitoring devices (e.g., an EEG monitor), and other such devices or combination of devices.
The asset community 106 may include assets from different manufacturers or vintages. The various assets (e.g., wind turbines, generators, solar panels, hydroelectric turbines, MRI scanners, buses, railcars, etc.) of the asset community 106 can belong to one or more different asset communities, and the asset communities can be located locally or remotely from one another. For example, the members of the asset community 106 can be co-located within a single community (e.g., a wind farm), or the members can be geographically distributed across multiple different communities (e.g., one or more geographically disparate wind farms). Furthermore, the one or more assets of the asset community 106 may be in use (or non-use) under similar or dissimilar environmental conditions, or may have one or more other common or distinguishing characteristics.
The asset community 106 is also communicatively coupled to the asset cloud computing system 104. In one embodiment, the AMP 102 includes a communication gateway 114 that communicatively couples the asset community 106 to the asset cloud computing system 104. The communication gateway 114 may further couple the asset cloud computing system 104 to one or more other assets and/or asset communities, to the enterprise computing system 112, or to one or more other devices. The AMP 102 thus represents a scalable industrial solution that extends from a physical or virtual asset (e.g., the industrial asset 110) to a remote asset cloud computing system 104. The asset cloud computing system 104 optionally includes a local, system, enterprise, or global computing infrastructure that can be optimized for industrial data workloads, secure data communication, and compliance with regulatory requirements.
The asset cloud computing system 104 is configured to collect information and/or metrics about one or more assets and/or asset communities 106. In one embodiment, the information from the asset 110, about the asset 110, or sensed by the asset 110 is communicated from the asset 110 to the data acquisition module 124 in the asset cloud computing system 104. In one embodiment, an external sensor, such as a temperature sensor, gyroscope, infrared sensor, accelerometer, and the like, is configured to sense information about a function of the asset 110, or to sense information about an environmental condition at or near the asset 110. The external sensor may be further configured for data communication with the communication gateway 114 (e.g., via one or more wired and/or wireless transmission mediums) and the data acquisition module 124. In one embodiment, the asset cloud computing system 104 is configured to use the sensor information in its analysis of one or more assets, such as using the analytics module 122. As discussed below with reference to FIGS. 3-9, a user may use a client device, such as the interface device 130, to request this monitored data for display on the interface device 130.
An operational model for the asset 110 may be employed by the asset cloud computing system 104. In one embodiment, the asset cloud computing system 104 invokes the asset module 120 to retrieve the operational model for the asset 110. The operational model may be stored in one or more locations, such as in the asset cloud computing system 104 and/or the enterprise computing system 112.
In addition, the asset cloud computing system 104 is configured to use the analytics module 122 to apply information received about the asset 110 or its operating conditions (e.g., received via the communication gateway 114) to or with the retrieved operational model. Using a result from the analytics module 122, the operational model may be updated, such as for subsequent use in optimizing the asset 110 or one or more other assets, such as one or more assets in the same or different asset community. In one embodiment, information and/or metrics about the asset 110 is used by the asset cloud computing system 104 to inform selection of an operating parameter for a remotely located asset that belongs to a different second asset community.
The IIoT machine 108 is configured to communicate with the asset community 106 and/or the asset cloud computing system 104. Accordingly, in one embodiment, the IIoT machine 108 includes a software layer configured for communication the asset community 106 and the asset cloud computing system 104. Further still, the IIoT machine 108 may be configured to execute an application locally at the asset 110 of the asset community 106. The IIoT machine 108 may be configured for use with or installed on gateways, industrial controllers, sensors, and other components.
In one embodiment, the IIoT machine 108 is implemented as a software stack that can be embedded into hardware devices such as industrial control systems or network gateways. The software stack may include its own software development kit (SDK). The SDK includes functions that enable developers to leverage the core features described below.
One responsibility of the IIoT machine 108 is to provide secure, bi-directional cloud connectivity to, and management of, industrial assets, while also enabling applications (analytical and operational services) at the edge of the IIoT. The latter permits the delivery of near-real-time processing in controlled environments. Thus, the IIoT machine 108 connects to the asset cloud computing system 104 and communicates with the various modules 120-128. This allows other computing devices, such as the interface device 130, running user interfaces/mobile applications to perform various analyses of either the industrial asset 110 or other assets within the asset community 106.
In addition to the foregoing, the IIoT machine 108 also provides security, authentication, and governance services for endpoint devices. This allows security profiles to be audited and managed centrally across devices, ensuring that assets are connected, controlled, and managed in a safe and secure manner, and that critical data is protected.
In order to meet requirements for industrial connectivity, the IIoT machine 108 can support gateway solutions that connect multiple edge components via various industry standard protocols. FIG. 2 is a block diagram illustrating different edge connectivity options that an IIoT machine 108 provides, in accordance with an example embodiment. There are generally three types of edge connectivity options that an IIoT machine 108 provides: machine gateway (M2M) 202, cloud gateway (M2DC) 204, and mobile gateway (M2H) 206.
Many assets may already support connectivity through industrial protocols such as Open Platform Communication (OPC)-UA or ModBus. A machine gateway component 208 may provide an extensible plug-in framework that enables connectivity to assets via M2M 202 based on these common industrial protocols.
A cloud gateway component 210 connects an IIoT machine 108 to the asset cloud computing system 104 via M2DC. As discussed above, the asset cloud computing system 104 provides various machine data services 214 and a remote management portal 216 for managing various connected industrial assets and/or the IIoT machine 108.
In one embodiment, the IIoT machine 108 is configured with a mobile gateway component 212 that facilitates bypassing asset cloud computing system 104 and establishing a direct connection to an industrial asset (e.g., the industrial asset 110). In some circumstances, the direct connection is used in maintenance scenarios. When service technicians are deployed to maintain or repair machines, they can connect directly from their machine (e.g., interface device 130) to understand the asset's operating conditions and perform troubleshooting. In certain industrial environments, where connectivity can be challenging, the ability to bypass the cloud and create this direct connection to the asset is helpful and technically beneficial.
The IIoT machine 108 may be deployed in various different ways. For example, the IIoT machine 108 may be deployed on the communication gateway 114, on various controllers communicatively coupled to one or more assets, or on sensors that monitor the industrial assets or the asset community 106. Where the IIoT machine 108 is deployed directly on one or more machine controllers, this deployment decouples the machine software from the machine hardware, allowing connectivity, upgradability, cross-compatibility, remote access, and remote control. It also upgrades industrial and commercial assets, which have traditionally operated standalone or in very isolated networks, to be connected directly to the asset cloud computing system 104 for data collection and live analytics.
Where the IIoT machine 108 is deployed on one or more sensors that collect and/or monitor data from one or more of the industrial assets, the sensors collect asset and environmental data, which is then communicated to the asset cloud computing system 104 for storage, analysis, and visualization.
Customers or other users of the asset cloud computing system 104 may create applications to operate, or reside on, the asset cloud computing system 104. While the applications reside on, or are executed by, the asset cloud computing system 104, these applications may leverage monitored data (or other metrics) gathered by IIoT machines (e.g., IIoT machine 108) that are in communication with one or more industrial assets or asset communities. In summary, the asset cloud computing system 104 contributes to the IIoT by providing a scalable cloud infrastructure that serves as a basis for PaaS, which is what developers use to create Industrial Internet applications for use in the IIoT.
In one embodiment, and as shown in FIG. 2, various user devices 218-226 communicate with the IIoT machine 108 via the mobile gateway 212. The user devices 218-226 may be considered various embodiments of the interface device 130. However, in alternative embodiments, the user devices 218-226 communicate with the IIoT machine 108 via the asset cloud computing system 104, such as through one or more of the modules 120-128. Where the user devices 218-226 access data and/or services provided by the asset cloud computing system 104 and/or IIoT machine 108, the user devices 218-226 are considered client devices.
The user devices 218-226 may comprise, but are not limited to, mobile phones, desktop computers, laptops, portable digital assistants (PDAs), smart phones, tablets, ultra-books, netbooks, wearable devices (e.g., smartwatch or assisted-vision devices), multi-processor systems, microprocessor-based or programmable consumer electronics, or any other communication device that a user may utilize to access the asset cloud computing system 104 or the IIoT machine 108. In some embodiments, the user devices 218-226 include a display module (not shown) to display information (e.g., in the form of user interfaces). In further embodiments, the user devices 218-226 include one or more of touch screens, accelerometers, gyroscopes, cameras, microphones, global positioning system (GPS) devices, and so forth.
In one embodiment, a user uses one or more of the client devices 218-226 to retrieve and/or view monitored data from one or more of the assets of the asset community 106. FIG. 3 illustrates a client device 300 of FIG. 2, according to an example embodiment. In one embodiment, the client device 300 includes one or more processor(s) 304, one or more communication interface(s) 302, and a machine-readable medium 306 that stores computer-executable instructions for one or more modules 308 and data 310 used to support one or more functionalities of the modules 308.
The various functional components of the client device 300 may reside on a single device or may be distributed across several computers in various arrangements. The various components of the client device 300, furthermore, may access one or more other components of the AMP 102 (e.g., one or more of the module 120-128, the IIoT machine 108, the communication gateway 114, or any of services available through the gateway 210), and each of the various components of the client device 300 may be in communication with one another. Further, while the components of FIG. 3 are discussed in the singular sense, it will be appreciated that in other embodiments multiple instances of the components may be employed.
The one or more processors 304 may be any type of commercially available processor, such as processors available from the Intel Corporation, Advanced Micro Devices, Texas Instruments, or other such processors. Further still, the one or more processors 304 may include one or more special-purpose processors, such as a Field-Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC). The one or more processors 304 may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. Thus, once configured by such software, the one or more processors 304 become specific machines (or specific components of a machine) uniquely tailored to perform the configured functions and are no longer general-purpose processors.
The one or more communication interfaces 302 are configured to facilitate communications between the client device 300, the asset cloud computing system 104, the communication gateway 114, the enterprise computing system 112, and/or IIoT machine 108. The one or more communication interfaces 302 may include one or more wired interfaces (e.g., an Ethernet interface, Universal Serial Bus (USB) interface, a Thunderbolt® interface, etc.), one or more wireless interfaces (e.g., an IEEE 802.11b/g/n interface, a Bluetooth® interface, an IEEE 802.16 interface, etc.), or combinations of such wired and wireless interfaces.
The machine-readable medium 306 includes various modules 308 and data 310 for implementing the client device 300. The machine-readable medium 306 includes one or more devices configured to store instructions and data temporarily or permanently and may include, but not be limited to, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM) and/or any suitable combination thereof. The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store the modules 308 and the data 310. Accordingly, the machine-readable medium 306 may be implemented as a single storage apparatus or device, or, alternatively and/or additionally, as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. As shown in FIG. 3, the machine-readable medium 306 excludes signals per se.
In one embodiment, the modules 308 are written in a computer-programming and/or scripting language. Examples of such languages include, but are not limited to, C, C++, C#, Java, JavaScript, Perl, Python, or any other computer programming and/or scripting language now known or later developed. The modules 308 may also be implemented via one or more computer-programming and/or scripting language libraries, such as Polymer.
With reference to FIG. 3, the modules 308 of the client device 300 include, but are not limited to, a user interface module 312, an asset selection module 314, a listener module 316, a treeview module 318, and a topology view module 320. The data 310 referenced and used by the modules 308 include asset data 322, treeview display data 324, topology display data 326, treeview logic 328, and topology view logic 330. The client device 300 may further include one or more output devices (not shown) communicatively coupled to the processor(s) 304 and include, but are not limited to, touch-screen displays, liquid crystal displays (LCDs), light-emitting diode (LED) displays, one or more speakers, vibrational controllers, force feedback devices, and other such output devices or combination of output devices.
The user interface module 312 is configured to provide access to, and interactions with, the client device 300. In one embodiment, the user interface module 312 provides one or more graphical user interfaces, which may be provided using the Hypertext Transfer Protocol (HTTP). The graphical user interfaces are displayable by the client device 300 and accept input from the user for interacting with the client device 300. Further still, the user interface module 312 may be configured to provide such interfaces to one or more clients displayable by the client device 300, such as a web client, one or more client applications, or a programmatic client. By interacting with the user interface module 312, the user can instruct the client device 300 to display information about a selected industrial asset. Further still, the user interface module 312 is configured to generate a display of various graphical elements used by one or more of the modules 308, such as graphical elements leveraged by the asset selection module 314, the treeview module 320, and/or the topology view module 320.
With reference to FIG. 1 and FIG. 3, the asset selection module 314 is configured to receive a selection of an industrial asset being monitored by the IIoT machine 108. In one embodiment, the asset selection module 314 communicates with the IIoT machine 108 to obtain a list of industrial assets that are being monitored by the IIoT machine 108. For example, the asset selection module 314 may obtain a list of the industrial assets within the asset community 106. Industrial assets that are accessible using the client device 300 are stored as asset data 322, which is leveraged by the asset selection module 314 in providing asset selection options via the user interface module 312. In one embodiment, the asset selection module 314 operates with the user interface module 312 to display a selectable menu, such as a drop-down menu, of selectable industrial assets. In an alternative embodiment, the asset selection module 314 displays groups of industrial assets that may be selected by the user, such as the asset community 106. After making a selection of an industrial asset or asset community, the asset selection module 314 then invokes the treeview module 318 and/or the topology view module 320 to display the asset data 322 and the industrial assets that correspond thereto.
The listener module 316 is configured to “listen” for events generated by the user interface module 312, the asset selection module 314, the treeview module 318, and/or the topology view module 320. In this regard, interactions with the client device 300 may be considered as one or more events, such as user selections of items displayed by the client device 300 or messages generated by one or more of the modules 308. The listener module 316 is configured to listen to these events and communicate the messages associated with such events to the targeted module and/or external system (e.g., the IIoT machine 108). In this manner, the listener module 316 facilitates communications between the various modules 308 and between the client device 300 and other external systems.
The treeview module 318 is configured to display a graphical Web component having one or more graphical elements that correspond to the industrial assets represented by the asset data 322. In one embodiment, the asset data 322 includes information about one or more of the industrial assets and includes, but is not limited to, the name of the industrial asset, the industrial asset community to which the industrial asset belongs or has been assigned, a physical (e.g., geographical) location of the industrial asset, a logical location (e.g., “4th floor of the ABC Building”) of the industrial asset, asset information of the industrial asset, one or more parent nodes of the industrial asset, and/or one or more child nodes of the industrial asset. The asset data 322 may be stored as a JavaScript Object Notation (JSON) object, where the asset data 322 is represented as multi-dimensional array, such that each element of the array corresponds to an industrial asset monitored by the IIoT machine 108.
The treeview module 318 leverages treeview logic 328 to display information corresponding to the asset data 322, which is represented as the treeview display data 324. In one embodiment, the treeview logic 328 is configured to display the treeview display data 324 as a hierarchical tree structure. FIG. 4 illustrates a graphical user interface 402 that displays a hierarchical tree structure 404, according to an example embodiment.
As shown in FIG. 4, the hierarchical tree structure 404 includes a plurality of nodes 404A-404J. The plurality of nodes 404A-404J include a parent node 404A that organizes the child nodes 404B-404J. In one embodiment, the parent node 404A is a logical structure for visually organizing the child nodes 404B-404J, which represent industrial assets corresponding the asset data 322. Accordingly, with reference to FIG. 4, the term “child node” and “industrial asset” may be used interchangeably, as the child nodes 404B-404J each correspond to an industrial asset. In this regard, the treeview module 318 is configured to interpret the asset data 322 so as to identify the various parent node/child node relationships, and to generate logical nodes (e.g., parent node 404A) for organizing the child nodes 404B-404J. Accordingly, in alternative embodiments, there may be child nodes of the parent node 404A that are logical nodes, whose further child nodes correspond to industrial assets. Thus, the hierarchical tree structure 404 may be a “nested” or multi-level tree structure, depending on the logical arrangement of the industrial assets as indicated by the asset data 322.
As mentioned above, each of the child nodes 404B-404J illustrated in FIG. 4 correspond to an industrial asset. In this manner, each of the child nodes 404B-404J may be a selectable element that displays asset information for a corresponding industrial asset. FIG. 5 illustrates asset information 502 displayed for a selected industrial asset 404D (e.g., child node 404D), according to an example embodiment. In one embodiment, the asset information 502 includes information about the industrial asset 404D including, but not limited to, performance efficiency, a number (e.g., absolute and/or percentage) of total alerts raised for the industrial asset 404D, a number (e.g., absolute and/or percentage) of critical alerts raised for the industrial asset 404D, a number (e.g., absolute and/or percentage) of major alerts raised for the industrial asset 404D, and a number ((e.g., absolute and/or percentage) of warnings raised for the industrial asset 404D.
In this regard, the IIoT machine 108 may distinguish between various types of alerts, which, as illustrated in FIG. 5, may include “critical” alerts, “major” alerts, and warnings. The conditions for these alerts may be stored and maintained by the IIoT machine 108.
A warning may include a deviation in performance by the industrial asset being monitored by the IIoT machine 108. In this regard, the IIoT machine 108 may maintain one or more performance thresholds for a given industrial asset and, when the IIoT machine fails to meet these performance thresholds, the IIoT machine 108 may record this failure as a warning. Examples of such warnings may include the industrial asset operating too hot (e.g., exceeding a temperature threshold), operating too cold (e.g., being less than a temperature threshold), being intermittently responsive, a loss of network communication packets between the industrial asset and the IIoT machine 108, and other such performance-related conditions or combination of conditions.
A major alert may be an alert corresponding to an industrial asset failing to meet or exceed a performance threshold over a given predetermined period of time. In this regard, the difference between a major alert and a warning may be that a warning may correspond to a single instance of a performance deviation whereas a major alert corresponds to a successive performance deviation. As one example, the IIoT machine 108 may implement an electronic “heartbeat” for monitoring the connected industrial assets by way of one or more echo requests communicated using the Internet Control Message Protocol (ICMP). Where the monitored industrial asset fails to respond to one or more echo requests after a predetermined number of attempts and/or after a predetermined period of time by the IIoT machine 108, the IIoT machine 108 may transition the operating state of the monitored industrial asset to a major alert state. In one embodiment, a major alert is resolved or cleared where the IIoT machine 108 determines that the monitored industrial asset is operating within expected performance thresholds (e.g., is being responsive to echo requests via ICMP, is not exceeding temperature thresholds, etc.).
A critical alert may be an alert corresponding to a determination by the IIoT machine 108 that a monitored industrial asset has conclusively failed or is non-responsive to the IIoT machine 108. In this regard, the state for a monitored industrial asset may first transition to a major alert state when a failure is detected, where the state for the monitored industrial asset may remain until another condition is satisfied (e.g., the monitored industrial asset has failed to respond to the IIoT machine 108 within a predetermined time period or after a predetermined number of attempts have been made). Thus, when this second condition is met or satisfied, the IIoT machine 108 may then transition the state of the monitored industrial asset to the critical state. In one embodiment, the critical state for the monitored industrial asset is resolved after intervention by an operator or other user of the AMP 102.
As discussed above, the alerts and/or warnings for a given industrial asset may be included in the asset data 322. In one embodiment, where the given state of an industrial asset is included in the asset data 322, the treeview module 318 interprets such state as a graphical indicator (or combination of graphical indicators), which is then stored as the treeview display data 324. For example, and in one embodiment, the treeview display data 324 stores a multi-dimensional table that correlates the possible states of the industrial assets with graphical indicators. In this embodiment, a warning state may be associated with text in a first color (e.g., red), a major alert state is associated with a child node having text in a first color (e.g., red) and a background in a second color (e.g., grey), and a critical alert state is associated with a child node having text in a second color (e.g., white) and background in a third color (e.g., red). In this manner, the treeview module 318 is configured to display the conditions of one or more monitored industrial assets using visual or graphical indicators to help the user of the client device 300 quickly identify which industrial assets may be experiencing technical problems or difficulties.
FIG. 6 illustrates a second graphical user interface 602 that displays a second hierarchical tree structure 604, according to an example embodiment. As illustrated in FIG. 6, the second hierarchical tree structure 604 includes nodes 604A-604K, which may correspond to previously obtained asset data 322. In contrast to the first hierarchical tree structure 404 illustrated in FIG. 4, the hierarchical tree structure 604 includes at least four nodes that correspond to logical structures for organizing the industrial assets represented by the obtained asset data 322. In this regard, the at least four nodes include the parent node 604A, a first organizational node 604D, and two organizational nodes 604E-604F, which are child nodes of the first organizational node 604D.
In one embodiment, the nodes 604D-604F correspond to two or more industrial assets that have one or more characteristics in common, as indicated by the obtained asset data 322. As discussed above, the obtained asset data 322 for the industrial assets may include the name of the industrial asset, the industrial asset community to which the industrial asset belongs or has been assigned, a physical (e.g., geographical) location of the industrial asset, a logical location (e.g., “4th floor of the ABC Building”) of the industrial asset, and asset information of the industrial asset. Thus, the industrial assets may be grouped according to various levels of granularity depending on the characteristics or properties associated with the industrial assets.
As one example, the industrial assets may be grouped by location. Applying this example to FIG. 6, the nodes 604E-604F may represent industrial assets in different rooms (e.g., “Room 406” and “Room 408”) and the node 604D may represent the industrial assets for a given floor (e.g., “Floor 4”). As another example, the nodes 604E-604F may represent industrial assets having different functions (e.g., “Computed Tomography” and “MRI”), and the node 604D may represent the industrial assets for a given field of medicine (e.g., “Cardiology”).
In some instances, the asset data 322 may not include a characteristic or property that groups the corresponding industrial assets. Where there is no characteristic and/or property grouping the industrial assets, the treeview module 318 is configured to display a node corresponding to the industrial asset as a child node under a corresponding parent node (e.g., parent node 604A). In this manner, the industrial assets represented by the obtained asset data 322 may be grouped and illustrated in a hierarchical tree structure (e.g., hierarchical tree structure 404 and/or hierarchical tree structure 604) according to various characteristics and/or properties.
In addition to the treeview illustrated in FIGS. 4-6, the module 308 of the client device 300 also supports displaying the industrial assets in a topology view via the topology view module 320. The topology view module 320 may implement the topology view by executing the topology view logic 330 and referencing the topology display data 326, which include the logic for executing the topology view and the elements for displaying the topology view, respectively. In one embodiment, the topology display data 326 is based on the obtained asset data 322 and includes, but is not limited to, the text, colors, and/or icons associated with nodes illustrated in the topology view displayed by the topology view module 320.
In one embodiment, the topology view provides a view that illustrates the connections between the various industrial assets. These connections may be based on network connectivity (e.g., how the industrial assets are interconnected) or on one or more of the characteristics or properties that the industrial assets have in common (e.g., determined from the obtained asset data 322).
In addition, the topology view may be requested by selecting a graphical element associated with the display of the topology view. FIG. 6 illustrates that the graphical user interface 602 may include a first graphical element 606 associated with the node 604D and a second graphical element 608 associated with the graphical user interface 602. As discussed below with reference to FIG. 7, depending on which graphical element 606, 608 is selected, the topology view module 320 may or may not display the child nodes 604E-604F of the node 604D. More particularly, and in one embodiment, where the graphical element 608 is selected, the child nodes 604E-604F are not displayed whereas if the graphical element 606 is selected, the child nodes 604E-604F are displayed.
FIG. 7 illustrates a third graphical user interface 702 that displays a topology view 704 corresponding to the second hierarchical tree structure 604 of FIG. 6, according to an example embodiment. As shown in FIG. 7, the topology view 704 includes a central node 704A, around which are displayed other child nodes, such as the group node 704E, the group node 704F, the group node 706, and nodes 708-712.
In displaying the topology view 704, the topology view module 320 is configured to display the central node 704A at a relative center of a portion of the graphical user interface 702. In one embodiment, the central node 704A represents one or more pieces of networking equipment through which connected industrial assets communicate with a WAN (e.g., the Internet). Thus, the central node 704A may be a router, switch, modem, or other networking equipment which is communicatively connected (e.g., via one or more wired and/or wireless connections) to other industrial assets, which are represented as child nodes. In one embodiment, an edge between the central node 704A and a child node (e.g., an individual node or group node) signifies that the central node 704A is communicatively connected.
Where the hierarchical tree structure occupies a one-half portion of the graphical user interface 702, the topology view 704 is displayed in the other one-half portion. Accordingly, the topology view module 320 then determines the width and height of the portion where the topology view 704 is to be displayed, where the width and height are given as pixels (e.g., 400 pixels in height and 300 pixels in width). The topology view module 320 then determines the center of this portion given the determined width and height. This determined center, represented by a set of two-dimensional coordinates, becomes the location of the central node 704A.
The topology view module 320 then determines two-dimensional coordinates for each of the child nodes to be displayed around the central node 704A. In one embodiment, the child nodes are configured to be displayed along the perimeter of an imaginary circle drawn around the central node 704A. Accordingly, in this embodiment, the topology view module 320 determines the placement of corresponding child nodes by dividing 360 (e.g., the number of degrees in a circle) by the number of child nodes. The resulting quotient yields the number of degrees where each child node is to be placed about the imaginary circle drawn around the central node 704A. In an alternative embodiment, the topology view module 320 implements the D3.js library, which is available from D3JS.org, to determine the placement of the corresponding child nodes.
Each child node is also displayed at a determined distance from the central node 704A depending upon the size of the child node. In this regard, a child node may be assigned a variety of sizes and, in one embodiment, selected from three different preconfigured sizes: a default value size, a large value size, and an extra-large value size. Each of the three sizes are intended to accommodate the amount of text and/or graphics to be displayed within the child node. Where the child node is a default value size (e.g., having one graphic or 3-4 characters of text), the child node is displayed at a default distance away (e.g., 30 pixels) from the central node 704A at a location based on the quotient determined previously. Where the child node is assigned a large value size (e.g., having 5-10 characters of text), the child node is displayed at a distance (e.g., 50 pixels) greater than the distance assigned to the default value size. Finally, where the child node is assigned an extra-large value size (e.g., having more than 10 characters of text), the child node is displayed at a distance (e.g., 75 pixels) greater than the distance assigned to the large value size. In this manner, the child nodes of the central node 704A are displayed encircling the central node 704A, but at a sufficient distance so that the text and/or graphics displayed within the child node are legible and/or readable to the user of the client device 300.
In some instances, a child node may be the parent node of additional child nodes. For example, as illustrated in FIG. 7, the child node 706 is a parent node to three child nodes 706A-706C. The child node 706 is a group node as it represents a cluster (i.e., one or more) of industrial assets that have one or more designated characteristics or properties in common. As discussed above, such characteristics or properties may include the location of the industrial assets, a technician assigned to service the industrial assets, the install date of the industrial assets, or other such characteristics or properties.
However, child nodes 706A-706C are illustrated as being connected to the child node 706 (i.e., the group node) because each of child nodes 706A-706C are communicatively connected (e.g., through a wired connection, wireless connection, or both) to one or more of the industrial assets contained within the child node 706. Child nodes 706A-706C are illustrated separately from child node 706 because each of child nodes 706A-706C (e.g., the industrial asset represented by the node) has a characteristic or property different than the industrial assets grouped within the child node 706. As an example, supposing that the industrial assets of child node 706 are grouped according to install date, child nodes 706A-706C may each have a different install date. As another example, supposing that the industrial assets of child node 706 are grouped according to location and technician, child nodes 706A-706C may each have a different location and/or technician.
In this manner, the topology view 704 may display group nodes (e.g., child node 706) having ungrouped child nodes (child nodes 706A-706C) where one or more of the characteristics or properties of the ungrouped child nodes are different than the industrial assets of the group node (e.g., child node 706), but are connected to one or more of the industrial assets of the group node through one or more wired and/or wireless connections.
In determining the two-dimensional coordinates of where to display child nodes 706A-706C, the topology view module 320 accounts for the fact that the parent node (e.g., node 706) is already displayed relative to the central node 704A. Thus, in one embodiment, the topology view module 320 uses one-half of the available circumference for displaying the child nodes 706A-706C, which equates to
$\frac{180}{number of nodes}$
rather than
$\frac{360}{number of nodes} .$
In this manner, and as shown in FIG. 7, the child nodes 706A-706C are displayed relative to the bottom half of the node 706 rather than being displayed at equal thirds around the total circumference of the node 706. In an alternative embodiment, the location of the for one or more of the child nodes 706A-706C are determined using the methods and/or functions available through the D3.js library.
While FIG. 7 illustrates that some of the nodes of the topology view 704 may be connected to the central node 704A, there may be some nodes where there is no connection displayed. For example, there is no connection displayed between the group node 704E and the central node 704A, nor is there a connection displayed from the child nodes 708-712 to the central node 704A. This is because the group node 704E and the child nodes 708-712 are each configured to access a WAN (e.g., the Internet) through networking equipment different than the networking equipment represented by the central node 704A. Further still, the group node 704E and the child nodes 708-712 are still considered part of the industrial asset community monitored by the IIoT machine 108 based on one or more characteristics and/or properties established by an operator or technician of the industrial assets represented by the group node 704E and the industrial assets represented by the child nodes 708-712. In this manner, industrial assets may still form part of an industrial asset community even if the industrial assets are not all communicatively coupled to the same networking equipment.
As alluded to above, the topology view 704 further distinguishes between group nodes and nodes representing industrial assets. In one embodiment, a group node, such as one of nodes 704E, 704F, and 706, is identifiable as a group node because such group nodes include a grouping identifier, such as a number, associated with, or written within, the node. In an embodiment where the grouping identifier is a number, the number signifies the number of nodes and/or industrial assets represented by the group node. Thus, group node 704E represents at least 10 other industrial assets and group node 704F represents at least eight other industrial assets. Where a node does not include a grouping identifier associated with, or written within, the node, the node may represent an individual industrial asset, such as an MRI scanner, CT machine, wind turbine, or other industrial asset. Alternatively and/or additionally, the grouping identifier associated with, or written within, a given node represents the number of child nodes (e.g., group nodes and/or individual nodes) associated with the given node. Although shown as a number in FIG. 7, the grouping identifier may be represented as other textual characters and/or graphics (e.g., one or more icons).
A user may view the nodes and/or industrial assets associated with a group node by manipulating (e.g., selecting) the group node. FIG. 8 illustrates the graphical user interface 702 of FIG. 7 where the group node 704F has been selected for viewing, according to an example embodiment. As shown in FIG. 8, by selecting the group node 704F, the topology view module 320 responds by displaying child nodes 802-816 corresponding to industrial assets associated with the group node 704F. Furthermore, in expanding the group node 704F, the topology view module 320 may determine a location within the graphical user interface 702 for displaying the child nodes 802-816 of the group node 704F.
The expanded group node 704F also includes a central node 818. In one embodiment, the topology view module 320 is configured to display different images of the central node 818, depending on whether the central node 818 represents networking equipment through which the child nodes 802-816 communicate with a WAN or whether the child nodes 802-816 communicate with a WAN through other networking equipment. In other words, the image of the central node 818 indicates whether the networking connection from the child nodes 802-816 to the central node 818 terminates with the central node 818.
As illustrated in FIG. 8, the double-ringed circle representing the central node 818 indicates that the networking equipment is associated with a different node; in other words, that the network connection between the child nodes 802-816 and the networking equipment does not terminate at central node 818. Where the central node 818 appears as the double-ringed circle, this image signals to the user that there is another node through which child nodes 802-816 communicate with the WAN (e.g., the Internet). To determine the node where the network connection from the child nodes 802-816 terminate, the user may reference the corresponding hierarchical tree structure (e.g., hierarchical tree structure 604). Where the child nodes 802-816 communicate with the WAN through the central node 818, the central node 818 may appear other than double-ringed circle, such as a single-ringed circle, an image or icon of networking equipment, or other such images or combination of images.
In one embodiment, the topology view module 320 determines a two-dimensional coordinate for displaying the central node 818 of the group node 704F and, subsequently, the two-dimensional coordinates for displaying each of the child nodes 802-816. The topology view module 320 may perform this determination, for example, by determining an expected height and width (e.g., in pixels) of the expanded group node 704, and then identifying a two-dimensional coordinate representing a center of the expected height and width, such that the expansion of the group node 704F avoids displaying child nodes 802-816 as overlapping on other nodes of the topology view. This two-dimensional coordinate may be relative to the graphical user interface 702 and/or the portion of the graphical user interface 702 where the topology view is displayed. By locating a two-dimensional coordinate in this manner, the topology view module 320 avoids obscuring other nodes that may be displayed when the group node 704F is expanded.
FIG. 9 illustrates another graphical user interface 902 that includes the display of a hierarchical tree structure 908 and a corresponding topology view 910, according to an example embodiment. As shown in FIG. 9, the graphical user interface 902 is effectively divided into two portions: a first portion 904 occupied by the hierarchical tree structure 908 and a second portion 906 occupied by the topology view 910. Furthermore, each of the nodes 908A-908Q include a corresponding node 910A-910Q in the topology view 910. Using the operations discussed above, the treeview module 318 and the topology view module 320 support the simultaneous display of the hierarchical tree structure 908 and the corresponding topology view 910. Where a grouping threshold has been reached (e.g., a predetermined number of industrial assets having one or more designated characteristics and/or properties in common has been reached), one or more of the industrial assets listed in the hierarchical tree structure 908 may be displayed as a group node within the corresponding topology view 910. In this manner, a user using the client device 300 may view both the hierarchical tree structure of connected industrial assets and their corresponding topology.
The topology view module supports a number of different viewing options and manipulations to the topology view illustrated in each of FIGS. 7-9. For example, using an input device, a user may select a particular child node and move it about the portion of the graphical user interface where the topology view is displayed. Further still, the topology view module 320 is configured to continuously draw the edge from the child node to its parent node. By allowing a user to move the child node about the portion of the graphical user interface, the topology view module 320 adds greater readability of the node titles.
The topology view module 320 also supports the movement of the topology view. For example, a user may select the parent node of the topology view and “drag” it to other parts of the viewable area. Further still, using one or more input elements (e.g., a slider or the like), the user can zoom in and/or out on the topology view so that a user can inspect details or see a macro view of the entire topology view. In this manner, the user can manipulate various aspects of the topology view so as it increase its readability and to further inspect different elements displayed in the topology view.
FIGS. 10A-10C illustrate a method 1002, in accordance with an example embodiment, for displaying connected industrial assets as a hierarchical tree structure and/or in a topology view. The method 1002 may be implemented by one or more of the modules 308 and data 310 of the client device 300 and is discussed by way of reference thereto.
With reference to FIG. 10A and FIG. 3, the user interface module 312 initially receives a request to display information about industrial assets connected to a given IIoT machine (e.g., IIoT machine 108) (Operation 1004). The user interface module 312 then communicates this request to the asset selection module 314, which, as explained above, then communicates the request to the IIoT machine 108 (Operation 1006). As explained previously, the asset selection module 314 then obtains a list of connected industrial assets, which are stored as asset data 322 (Operation 1008). Using the obtained asset data 322, and as discussed above, the treeview module 318 then displays a hierarchical tree structure of the industrial assets represented by the asset data 322, where the display of the hierarchical tree structure is according to the treeview logic 328 and one or more elements selected from the treeview display data 324 (Operation 1010). Examples of the displayed hierarchical tree structure include the hierarchical tree structure 404 illustrated in FIG. 4 and the hierarchical tree structure 604 illustrated in FIG. 6.
The treeview module 318 then waits for input relative to the displayed hierarchical tree structure and/or the graphical user interface in which the hierarchical tree structure is displayed. These inputs include, but are not limited to, whether asset information was received for one or more of the displayed industrial assets (Operation 1012), whether a topology view mode was selected and/or requested (Operation 1014), and whether one or more nodes were selected from the displayed hierarchical tree structure (Operation 1016). Where each of these operations are determined in the negative (e.g., the “NO” branch of Operation 1012, the “NO” branch of Operation 1014, and the “NO” branch of Operation 1016), the operational flow of method 1002 returns to the respective operation (e.g., Operation 1012, Operation 1014, and/or Operation 1016). While Operations 1012-1016 are illustrated as proceeding separately from Operation 1010, one of ordinary skill in the art will appreciate that Operations 1012-1016 may be performed concurrently (e.g., in parallel) or sequentially (e.g., in serial).
With regard to Operation 1012, the client device 300 may receive updated asset information for one or more of the displayed industrial assets, such as by receiving updated asset information from the IIoT machine 108 (e.g., the “YES” branch of Operation 1012). Where updated information is received, operational flow proceeds to Operation 1018 as illustrated in FIG. 10B. As discussed previously, the asset information may include a change in state associated with the connected industrial asset, such as warning state, a major alert state, and/or a critical alert state. In response to the received asset information, the treeview module 318, the topology view module 320, and/or the asset selection module 314 then updates the asset data 322 corresponding to the industrial asset having the updated asset information (Operation 1018). In addition, the updated asset information may cause a change in the display of the node within the hierarchical tree structure (or topology view, when applicable). As explained previously, one or more of the states assignable to a node may be associated with specific colors and/or text indicating the state of the industrial asset represented by the node. Accordingly, updates to the asset data 322 may also cause the treeview module 318 (or the topology view module to display a change in state of the corresponding node of the associated industrial asset (Operation 1020). Operational flow of the method 1002 then returns to Operation 1012.
With regard to Operation 1016, the treeview module 318 and/or the topology view module 320 determine whether a node has been selected from the hierarchical tree structure and/or the topology view (Operation 1016). Where this determination is made in the affirmative (e.g., “YES” branch of Operation 1016), the treeview module 318 and/or the topology view module 320 then displays asset information (e.g., from the obtained asset data 322) for industrial asset represented by the selected node (Operation 1022 of FIG. 10B). Although not illustrated in FIGS. 10A-10C, a selected node may be a group node (e.g., representing two or more industrial assets), in which case, the selection of the node causes the treeview module 318 and/or the topology view module 320 to expand the selected node (e.g., the expansion of group node 604D of FIG. 6). Operational flow then returns to Operation 1016.
With regard to Operation 1018, the treeview module 318 and/or the topology view module 320 determines whether a topology view has been selected for the displayed hierarchical tree structure (Operation 1014). Where this determination is made in the affirmative (e.g., the “YES” branch of Operation 1014), the topology view module 320 determines a location to display a central node for the selected topology view (Operation 1024 of FIG. 10B). As explained above, the topology view module 320 is configured to display the central node at a center location within a portion of the graphical user interface where the topology view is to be displayed. The topology view module 320 then determines the locations for displaying the child nodes encircling the central node (Operation 1026). As discussed above, the topology view module 320 accounts for the number of child nodes to be displayed along with any other graphical elements associated with the child node (e.g., any alphanumeric characters, icons, etc.) in determining these locations. The topology view module 320 then displays the selected topology view (Operation 1028).
As with the treeview module 318, the topology view module 320 waits for input relative to the displayed topology view. These inputs include, but are not limited to, whether a group node was selected (Operation 1030) and/or whether a node representing an individual industrial asset was selected (Operation 1032) from the displayed nodes of the topology view. Where each of these operations are determined in the negative (e.g., the “NO” branch of Operation 1030 and/or the “NO” branch of Operation 1032), the operational flow of method 1002 returns to the respective operation (e.g., Operation 1030 and/or Operation 1032). While Operations 1030-1032 are illustrated as proceeding separately from Operation 1028, one of ordinary skill in the art will appreciate that Operations 1030-1032 may be performed concurrently (e.g., in parallel) or sequentially (e.g., in serial).
With Operation 1030, the topology view module 320 determines whether a group node is selected (Operation 1030). Where this determination is made in the affirmative (e.g., “YES” branch of Operation 1030), the method 1002 proceeds to Operation 1034 of FIG. 10C. At Operation 1034, the topology view module 320 determines a location to display a central node of the group of industrial assets represented by the selected group node. The topology view module 320 next determines a location of each of the nodes representing individual industrial assets and/or additional group nodes for the selected group node (Operation 1036). The topology view module 320 then displays the expanded group of industrial assets and/or group nodes within the displayed topology view (Operation 1038).
Although FIG. 10C illustrates that operational flow of method 1002 ends after Operation 1038, one of ordinary skill in the art will appreciate the method 1002 may continue after selection of the group node. Accordingly, in one embodiment, operational flow of method 1002 may return and/or proceed to one or more of the Operations illustrated in FIGS. 10A-10C.
With regard to Operation 1032, the topology view module 320 determines whether a node representing an individual industrial asset has been selected (Operation 1032). Where this determination is made in the affirmative (e.g., the “YES” branch of Operation 1032), the method 1002 proceeds to Operation 1040 as illustrated in FIG. 10C. At Operation 1040, the topology view module 320 displays the asset information associated with the industrial asset represented by the selected node (Operation 1040). The method 1002 then returns to Operation 1030 and/or Operation 1032 as illustrated in FIG. 10B.
In this manner, this disclosure provides a system, method, and machine-readable medium for simultaneously displaying a hierarchical tree structure of connected industrial assets and a topology view of those connected industrial assets, where the industrial assets are either in communication with or connected to an IIoT machine. The technical benefit provided by this disclosure is the simultaneous display of connected industrial assets in two different viewing modes within the same graphical user interface of a client or interface device in communication with the IIoT machine. In this manner, a user can interact with the hierarchical tree structure and/or the topology view without having to instantiate a new graphical user interface or depart from the currently viewed graphical user interface.

Modules, Components, and Logic

Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (e.g., code embodied on a machine-readable medium) or hardware modules. A “hardware module” is a tangible unit capable of performing certain operations and may be configured or arranged in a certain physical manner. In various example embodiments, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware modules of a computer system (e.g., a processor or a group of processors) may be configured by software (e.g., an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In some embodiments, a hardware module may be implemented mechanically, electronically, or any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic that is permanently configured to perform certain operations. For example, a hardware module may be a special-purpose processor, such as a FPGA or an ASIC. A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware module may include software executed by a general-purpose processor or other programmable processor. Once configured by such software, hardware modules become specific machines (or specific components of a machine) uniquely tailored to perform the configured functions and are no longer general-purpose processors. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.
Accordingly, the phrase “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, “hardware-implemented module” refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where a hardware module comprises a general-purpose processor configured by software to become a special-purpose processor, the general-purpose processor may be configured as respectively different special-purpose processors (e.g., comprising different hardware modules) at different times. Software accordingly configures a particular processor or processors, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple hardware modules exist contemporaneously, communications may be achieved through signal transmission (e.g., over appropriate circuits and buses) between or among two or more of the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource (e.g., a collection of information).
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions described herein. As used herein, “processor-implemented module” refers to a hardware module implemented using one or more processors.
Similarly, the methods described herein may be at least partially processor-implemented, with a particular processor or processors being an example of hardware. For example, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules.
Moreover, the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines including processors), with these operations being accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., an Application Program Interface (API)).
The performance of certain of the operations may be distributed among the processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processors or processor-implemented modules may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm). In other example embodiments, the processors or processor-implemented modules may be distributed across a number of geographic locations.

Machine and Software Architecture

The modules, methods, applications and so forth described in conjunction with FIGS. 1-10C are implemented in some embodiments in the context of a machine and an associated software architecture. The sections below describe a representative architecture that is suitable for use with the disclosed embodiments.
Software architectures are used in conjunction with hardware architectures to create devices and machines tailored to particular purposes. For example, a particular hardware architecture coupled with a particular software architecture will create a mobile device, such as a mobile phone, tablet device, or so forth. A slightly different hardware and software architecture may yield a smart device for use in the “internet of things” while yet another combination produces a server computer for use within a cloud computing architecture. Not all combinations of such software and hardware architectures are presented here as those of skill in the art can readily understand how to implement the inventive subject matter in different contexts from the disclosure contained herein.

Example Machine Architecture and Machine-Readable Medium

FIG. 11 is a block diagram illustrating components of a machine 1100, according to some example embodiments, able to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, FIG. 11 shows a diagrammatic representation of the machine 1100 in the example form of a computer system, within which instructions 1116 (e.g., software, a program, an application, an applet, an app, or other executable code) for causing the machine 1100 to perform any one or more of the methodologies discussed herein may be executed. For example, the instructions 1116 may cause the machine 1100 to execute the flow diagrams of FIGS. 10A-10C. Additionally, or alternatively, the instructions 1116 may implement one or more of the components of FIGS. 1-3. The instructions 1116 transform the general, non-programmed machine 1100 into a particular machine 1100 programmed to carry out the described and illustrated functions in the manner described. In alternative embodiments, the machine 1100 operates as a standalone device or may be coupled (e.g., networked) to other machines. In a networked deployment, the machine 1100 may operate in the capacity of a server machine or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine 1100 may comprise, but not be limited to, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a PDA, or any machine capable of executing the instructions 1116, sequentially or otherwise, that specify actions to be taken by machine 1100. Further, while only a single machine 1100 is illustrated, the term “machine” shall also be taken to include a collection of machines 1100 that individually or jointly execute the instructions 1116 to perform any one or more of the methodologies discussed herein.
The machine 1100 may include processors 1110, memory/storage 1130, and I/O components 1150, which may be configured to communicate with each other such as via a bus 1102. In an example embodiment, the processors 1110 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Radio-Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 1112 and processor 1114 that may execute the instructions 1116. The term “processor” is intended to include multi-core processor that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions 1116 contemporaneously. Although FIG. 11 shows multiple processors 1110, the machine 1100 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core process), multiple processors with a single core, multiple processors with multiples cores, or any combination thereof.
The memory/storage 1130 may include a memory 1132, such as a main memory, or other memory storage, and a storage unit 1136, both accessible to the processors 1110 such as via the bus 1102. The storage unit 1136 and memory 1132 store the instructions 1116 embodying any one or more of the methodologies or functions described herein. The instructions 1116 may also reside, completely or partially, within the memory 1132, within the storage unit 1136, within at least one of the processors 1110 (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine 1100. Accordingly, the memory 1132, the storage unit 1136, and the memory of processors 1110 are examples of machine-readable media.
As used herein, “machine-readable medium” means a device able to store instructions 1116 and data temporarily or permanently and may include, but is not limited to, RAM, ROM, buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., Erasable Programmable Read-Only Memory (EEPROM)) and/or any suitable combination thereof. The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions 1116. The term “machine-readable medium” shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions (e.g., instructions 1116) for execution by a machine (e.g., machine 1100), such that the instructions, when executed by one or more processors of the machine 1100 (e.g., processors 1110), cause the machine 1100 to perform any one or more of the methodologies described herein. Accordingly, a “machine-readable medium” refers to a single storage apparatus or device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices. The term “machine-readable medium” excludes signals per se.
The I/O components 1150 may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components 1150 that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components 1150 may include many other components that are not shown in FIG. 11. The I/O components 1150 are grouped according to functionality merely for simplifying the following discussion and the grouping is in no way limiting. In various example embodiments, the I/O components 1150 may include output components 1152 and input components 1154. The output components 1152 may include visual components (e.g., a display such as a plasma display panel (PDP), a LED display, a LCD, a projector, or a cathode ray tube (CRT)), acoustic components (e.g., speakers), haptic components (e.g., a vibratory motor, resistance mechanisms), other signal generators, and so forth. The input components 1154 may include alphanumeric input components (e.g., a keyboard, a touch screen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), point based input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or other pointing instrument), tactile input components (e.g., a physical button, a touch screen that provides location and/or force of touches or touch gestures, or other tactile input components), audio input components (e.g., a microphone), and the like.
In further example embodiments, the I/O components 1150 may include biometric components 1156, motion components 1158, environmental components 1160, or position components 1162 among a wide array of other components. For example, the biometric components 1156 may include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram based identification), and the like. The motion components 1158 may include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope), and so forth. The environmental components 1160 may include, for example, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometers that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detection concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components 1162 may include location sensor components (e.g., a GPS receiver component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.
Communication may be implemented using a wide variety of technologies. The I/O components 1150 may include communication components 1164 operable to couple the machine 1100 to a network 1180 or devices 1170 via coupling 1182 and coupling 1172, respectively. For example, the communication components 1164 may include a network interface component or other suitable device to interface with the network 1180. In further examples, communication components 1164 may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices 1170 may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).
Moreover, the communication components 1164 may detect identifiers or include components operable to detect identifiers. For example, the communication components 1164 may include Radio Frequency Identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional bar codes such as Universal Product Code (UPC) bar code, multi-dimensional bar codes such as Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF416, Ultra Code, UCC RSS-2D bar code, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals). In addition, a variety of information may be derived via the communication components 1164, such as location via Internet Protocol (IP) geo-location, location via Wi-Fi® signal triangulation, location via detecting a NFC beacon signal that may indicate a particular location, and so forth.

Transmission Medium

In various example embodiments, one or more portions of the network 1180 may be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), the Internet, a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, the network 1180 or a portion of the network 1180 may include a wireless or cellular network and the coupling 1182 may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications (GSM) connection, or other type of cellular or wireless coupling. In this example, the coupling 1182 may implement any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (1×RTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standard, others defined by various standard setting organizations, other long range protocols, or other data transfer technology.
The instructions 1116 may be transmitted or received over the network 1180 using a transmission medium via a network interface device (e.g., a network interface component included in the communication components 1164) and utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Similarly, the instructions 1116 may be transmitted or received using a transmission medium via the coupling 1172 (e.g., a peer-to-peer coupling) to devices 1170. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions 1116 for execution by the machine 1100, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Language

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein.
Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present disclosure. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single disclosure or inventive concept if more than one is, in fact, disclosed.
The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims

What is claimed is:

1. A system comprising:

a machine-readable medium storing computer-executable instructions; and

at least one hardware processor communicatively coupled to the machine-readable medium that, when the computer-executable instructions are executed, configures the system to perform operations comprising:

displaying a hierarchical tree structure comprising a first plurality of nodes, wherein a first node selected from the first plurality of nodes represents a network-connected industrial asset;

receiving a selection to display a topology view corresponding to the hierarchical tree structure, the topology view comprising a second plurality of nodes, wherein a first node selected from the second plurality of nodes represents the network-connected industrial asset;

determining a location to display the topology view, the location being determined based on the second plurality of nodes;

displaying the topology view at the determined location, wherein:

a second node selected from the second plurality of nodes is designated as a central node of the topology view; and

one or more nodes of the second plurality of nodes are displayed connected to a perimeter of the central node; and

wherein the hierarchical tree structure and the topology view are displayed within the same graphical user interface.

2. The system of claim 1, wherein selection of the first node displays asset information corresponding to the network-connected industrial asset.

3. The system of claim 1, wherein the at least one hardware processor further configures the system to:

receive asset information corresponding to the network-connected industrial asset; and

change the display of the first node selected from the second plurality of nodes in response to the received asset information.

4. The system of claim 3, wherein the received asset information indicates a state of the network-connected industrial asset, the state being selected from a group consisting of: a warning state, a major alert state, and a critical alert state.

5. The system of claim 1, wherein:

the graphical user interface comprises a plurality of portions;

the hierarchical tree structure is displayed within a first portion selected from the plurality of portions;

the location to display the topology view is further based on a second portion selected from the plurality of portions; and

the display of the topology view further comprises displaying the topology view within the second portion.

6. The system of claim 1, wherein:

the second plurality of nodes further comprises a third node representing a third plurality of nodes; and

selection of the third node causes the system to display the third plurality of nodes at a location determined based on the determined location of the second node and the number of nodes represented by the third node.

7. The system of claim 1, wherein the at least one hardware processor further configures the system to:

receive asset information corresponding to the network-connected industrial asset, the asset information indicating a first state of the network-connected industrial asset;

display the first node according to the received asset information;

receive updated asset information corresponding to the network-connected industrial asset, the updated asset information indicating a second state of the network-connected industrial asset; and

display the second node according to the received updated asset information, wherein the second state is different than the first state.

8. A method comprising:

displaying, by at least one hardware processor, a hierarchical tree structure comprising a first plurality of nodes, wherein a first node selected from the first plurality of nodes represents a network-connected industrial asset;

receiving, by at least one hardware processor, a selection to display a topology view corresponding to the hierarchical tree structure, the topology view comprising a second plurality of nodes, wherein a first node selected from the second plurality of nodes represents the network-connected industrial asset;

determining, by at least one hardware processor, a location to display the topology view, the location being determined based on the second plurality of nodes;

displaying, by at least one hardware processor, the topology view at the determined location, wherein:

9. The method of claim 8, wherein selecting the first node causes a display of asset information corresponding to the network-connected industrial asset.

10. The method of claim 8, wherein the method further comprises:

receiving asset information corresponding to the network-connected industrial asset; and

changing the display of the first node selected from the second plurality of nodes in response to the received asset information.

11. The method of claim 10, wherein the received asset information indicates a state of the network-connected industrial asset, the state being selected from a group consisting of: a warning state, a major alert state, and a critical alert state.

12. The method of claim 8, wherein:

the graphical user interface comprises a plurality of portions;

13. The method of claim 8, wherein:

selecting the third node causes a display of the third plurality of nodes at a location determined based on the determined location of the second node and the number of nodes represented by the third node.

14. The method of claim 8, further comprising:

receiving asset information corresponding to the network-connected industrial asset, the asset information indicating a first state of the network-connected industrial asset;

displaying the first node according to the received asset information;

receiving updated asset information corresponding to the network-connected industrial asset, the updated asset information indicating a second state of the network-connected industrial asset; and

displaying the second node according to the received updated asset information, wherein the second state is different than the first state.

15. A machine-readable medium comprising computer-executable instructions that, when executed by at least one hardware processor, causes a system to perform a plurality of operations, the operations comprising:

displaying the topology view at the determined location, wherein:

16. The machine-readable medium of claim 15, wherein selecting the first node causes a display of asset information corresponding to the network-connected industrial asset.

17. The machine-readable medium of claim 15, wherein the plurality of operations further comprise:

18. The machine-readable medium of claim 17, wherein the received asset information indicates a state of the network-connected industrial asset, the state being selected from a group consisting of: a warning state, a major alert state, and a critical alert state.

19. The machine-readable medium of claim 15, wherein:

the graphical user interface comprises a plurality of portions;

20. The machine-readable medium of claim 15, wherein: