Industrial automation security remote access

Abstract

Industrial automation secure remote access is provided. Industrial information hubs (IIHs) and industrial development hubs (IDHs) serve as industrial ecosystem platforms on which multiple participants can deliver repeatable and standardized services related to their core competencies. The core of the IIH system revolves around a development ecosystem that creates and delivers value to users (including industrial enterprises, OEMs, system integrators, suppliers, etc.) by aggregating digital content and domain expertise. The IIH system serves as a trusted information broker between the ecosystem and the OT environment of a plant facility and provides a platform for connecting assets, contextualizing asset data, and providing secure access to the ecosystem. As part of this ecosystem, the IIH system uses a secure remote access architecture to allow users to remotely access data about their plant floor assets via a virtual private network connection.

Description

Technical Field

[0001] The topics disclosed in this article generally relate to industrial automation systems, and, for example, to industrial information services. Background Technology

[0002] OT-level systems can be distributed and complex, and may integrate with numerous physical devices. This challenging environment, coupled with domain-specific programming and development languages, can make developing control systems on OT-level systems difficult, resulting in long development cycles for developing, testing, and ultimately deploying new control system designs. Furthermore, given the general lack of current virtualization and simulation capabilities, industrial automation systems must be purchased, programmed, and installed in the physical operating environment before actual testing or optimization can begin. This workflow often leads to project delays or cost overruns. In addition, the inherent complexity and customizable nature of installed industrial monitoring and control systems can make it difficult for owners of industrial assets (e.g., plant owners or industrial enterprise entities) to manage their OT-level systems and protect their proprietary intellectual property from catastrophic failures or cyberattacks. Summary of the Invention

[0003] To provide a basic understanding of some of the aspects described in this paper, a simplified overview is given below. This overview is not an extensive review, nor is it intended to identify key / important elements or to depict the scope of the various aspects described in this paper. Its purpose is merely to present some concepts in a simplified form as a prelude to the more detailed descriptions that follow.

[0004] In one or more embodiments, a system is provided for providing secure remote access to industrial assets, the system comprising: a device interface component configured to communicatively connect to gateway devices deployed at one or more industrial facilities via a cloud platform, wherein the gateway devices are communicatively connected to industrial assets operating at one or more industrial facilities, and the gateway devices respectively perform secure remote access runtime services; a user interface component configured to provide a front-end interface to client devices via the cloud platform, and to receive request data including user identity and credential information via interaction with the front-end interface; and an access management component configured to, in response to determining that user identity and credential information permits access to a subset of industrial assets, establish a virtual private network connection between the client devices and the subset of industrial assets via gateway devices communicatively connected to the subset of industrial assets.

[0005] Furthermore, one or more embodiments provide a method comprising: a system including a processor communicatively connected via a cloud platform to gateway devices installed at one or more industrial facilities, wherein the gateway devices are communicatively connected to industrial assets operating at one or more industrial facilities, and the gateway devices respectively perform secure remote access runtime services; the system providing a front-end interface to client devices via the cloud platform; the system receiving request data including user identity and credential information via interaction with the front-end interface; and the system establishing a virtual private network connection between the client devices and the subset of industrial assets via a gateway device communicatively connected to the subset of industrial assets in response to determining that the user identity and credential information permits access to the subset of industrial assets.

[0006] Furthermore, according to one or more embodiments, a non-transitory computer-readable medium is provided, on which instructions are stored, the instructions causing a system execution operation, executed on a cloud platform and including a processor, in response to execution. The operation includes: communicatively connecting via the cloud platform to gateway devices installed at one or more industrial facilities, wherein the gateway devices are communicatively connected to industrial assets operating at one or more industrial facilities, and the gateway devices respectively performing secure remote access runtime services; providing a front-end interface to a client device via the cloud platform; receiving request data including user identity and credential information via interaction with the front-end interface; and, in response to determining that the user identity and credential information permits access to a subset of industrial assets, establishing a virtual private network connection between the client device and the subset of industrial assets via a gateway device communicatively connected to the subset of industrial assets.

[0007] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and accompanying drawings. These aspects represent various modes that can be practiced, and it is intended that all of these modes be covered herein. Other advantages and novel features will become apparent, taken in conjunction with the accompanying drawings, from the following detailed description. Attached Figure Description

[0008] Figure 1 This is a block diagram of an example industrial control environment.

[0009] Figure 2 This is a block diagram of an example Industrial Development Center (IDH) storage system.

[0010] Figure 3 This is a diagram illustrating the general architecture of an IDH storage system.

[0011] Figure 4 This is a diagram illustrating an example data flow associated with the creation of a new control project for an automation system designed using an IDH storage system.

[0012] Figure 5 This is a diagram showing several example automation object properties related to building, deploying, and executing control projects that can be utilized by the IDH repository system.

[0013] Figure 6 This is a diagram showing the extraction of project telemetry data from control items submitted to the IDH repository system.

[0014] Figure 7 This is a diagram illustrating how project recommendations are generated based on the analysis of extracted project telemetry data.

[0015] Figure 8 This is a diagram illustrating the simulation control of a project by an IDH storage system.

[0016] Figure 9 This is a diagram illustrating the handover documents generated by the IDH repository system.

[0017] Figure 10 This is a diagram illustrating the collection of digital signatures by the IDH repository system.

[0018] Figure 11 This is a diagram showing the submission of a new version of a control project to be archived together with older project versions.

[0019] Figure 12 This diagram illustrates the intelligent backup of device configuration data to the IDH storage system.

[0020] Figure 13 This is a diagram illustrating an example recovery process that can be initiated through an IDH storage system.

[0021] Figure 14 This diagram illustrates the creation and storage of asset models based on equipment profiles submitted by equipment suppliers to the storage system.

[0022] Figure 15 It is a diagram showing the generation of a digital twin of an automated system or industrial environment based on control projects and corresponding asset models.

[0023] Figure 16 This is a diagram illustrating a simulated scenario of a virtualized factory utilizing multiple digital twins.

[0024] Figure 17 This diagram illustrates the use of live data generated by automated system equipment and collected by the IDH storage system to refine the virtual factory.

[0025] Figure 18 This is a diagram illustrating the interaction between multiple users and the virtualization factory.

[0026] Figure 19 This is a diagram illustrating the architecture of industrial assets operating within a factory environment that can be remotely viewed and controlled via an IDH storage system.

[0027] Figure 20 This is a block diagram of an example Industrial Information Center (IIH) storage system.

[0028] Figure 21 This is a block diagram of an example smart gateway device.

[0029] Figure 22 This is a general conceptual diagram of an ecosystem facilitated by the IIH system.

[0030] Figure 23 This is a diagram illustrating the creation and registration of asset models by an OEM for machines being built and delivered to customers.

[0031] Figure 24 This is a diagram illustrating an example asset model that incorporates automated objects.

[0032] Figure 25 This diagram illustrates the commissioning of the machine at the customer facility and the registration of the machine to the IIH system.

[0033] Figure 26 This is a diagram illustrating the deployment of asset models from the vendor repository to the customer repository of the IIH system.

[0034] Figure 27 This is a diagram illustrating the selection and integration of asset models based on machine identity.

[0035] Figure 28 This is a diagram illustrating the architecture of the IIH system, which provides industrial information services to a collection of industrial assets within a factory environment.

[0036] Figure 29 This is a high-level diagram illustrating a common architecture used to provide secure remote access to customers' industrial assets.

[0037] Figure 30 This is a diagram illustrating an example architecture of an IDH repository system that supports the ability to instantiate virtual machine instances as part of the system's digital engineering services on a cloud platform and connect to these virtual machine instances using secure remote access features.

[0038] Figure 31 It is a diagram depicting the registration of a virtual machine image to the image registry.

[0039] Figure 32 This is a diagram illustrating multi-tenant execution of virtual machines on an IDH storage system.

[0040] Figure 33This is a diagram of an example implementation of an IDH repository system, which can provide virtual machines with pre-installed project conversion services.

[0041] Figure 34 This is a diagram showing the virtual machine conversion control program file deployed using the running project conversion service.

[0042] Figure 35 This is a flowchart of an example method for establishing secure remote access to data about industrial assets operating in a factory facility.

[0043] Figure 36a This is a flowchart of the first part of an example method for remotely deploying and securely accessing virtual machines pre-installed with digital design applications for designing and testing industrial projects.

[0044] Figure 36b This is a flowchart of the second part of an example method for remotely deploying and securely accessing virtual machines pre-installed with digital design applications for designing and testing industrial projects.

[0045] Figure 37 This is an example computing environment.

[0046] Figure 38 This is an example of a networked environment. Detailed Implementation

[0047] The subject matter disclosure will now be described with reference to the accompanying drawings, wherein the same reference numerals are used throughout to refer to the same elements. In the following description, numerous specific details are set forth for illustrative purposes to provide a thorough understanding thereof. However, it may be apparent, however, that the subject matter disclosure can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate their description.

[0048] As used herein, the terms “component,” “system,” “platform,” “layer,” “controller,” “terminal,” “station,” “node,” and “interface” are intended to refer to a computer-related entity or an entity related to or part of an operating device having one or more specific functions, wherein such an entity may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to: a process running on a processor, a processor, a hard disk drive, multiple storage drives including attached solid-state drives (screw-on or bolt-on) or removable attached solid-state drives (optical or magnetic storage media); an object; an executable; an executing thread; a computer-executable program, and / or a computer. By way of illustration, both an application running on a server and the server itself can be components. One or more components may reside within an executing process and / or thread, and components may reside on one computer and / or be distributed among two or more computers. Furthermore, the components described herein may execute on various computer-readable storage media on which various data structures are stored. Components can communicate, for example, via local and / or remote processing based on signals having one or more data components (e.g., data from a component interacting with another component in a local system, a distributed system, and / or data from a component interacting with other systems via signals on a network such as the Internet). As another example, a component can be a device having specific functions provided by mechanical components operated by an electrical or electronic circuitry system, wherein the electrical or electronic circuitry system is operated by a software or firmware application executed by a processor, wherein the processor can be located internally or externally to the device and executes at least a portion of the software or firmware application. As yet another example, a component can be a device that provides specific functions through electronic components without mechanical parts, the electronic components including a processor to execute software or firmware providing at least some of the functions of the electronic components. As yet another example, an interface can include input / output (I / O) components and associated processors, applications, or application programming interface (API) components. While the foregoing examples relate to various aspects of components, the aspects or features illustrated are also applicable to systems, platforms, interfaces, layers, controllers, terminals, etc.

[0049] As used herein, the terms "to infer" and "inference" generally refer to the process of reasoning or inferring the state of a system, environment, and / or user based on a set of observations captured via events and / or data. Inference can be used to identify specific contexts or actions, or, for example, to generate probability distributions of states. Inference can be probabilistic, meaning that the calculation of the probability distribution of the state of interest is based on considerations of data and events. Inference can also refer to techniques used to construct higher-level events from a set of events and / or data. Such inference leads to the construction of new events or actions from a set of observed events and / or stored event data, regardless of whether the events are temporally closely related, and regardless of whether the events and data come from a single event and data source or from several event and data sources.

[0050] Furthermore, the term "or" signifies inclusive "or," not exclusive "or." That is, unless otherwise specified or explicitly stated in the context, the phrase "X adopts A or B" is intended to indicate any natural inclusive arrangement. Specifically, the phrase "X adopts A or B" satisfies any of the following instances: X adopts A; X adopts B; or X adopts both A and B. Furthermore, unless otherwise specified or explicitly stated in the context for the singular form, the articles "a" and "an" as used in this application and the appended claims should generally be interpreted as meaning "one or more."

[0051] Furthermore, as used herein, the term "set" excludes an empty set, such as a set containing no elements. Therefore, in the disclosure of this subject matter, "set" includes one or more elements or entities. For illustration, a set of controllers includes one or more controllers; a set of data resources includes one or more data resources; and so on. Similarly, as used herein, the term "group" refers to a collection of one or more entities, for example, a node group refers to one or more nodes.

[0052] Various aspects or features will be presented according to the system, which may include many devices, components, modules, etc. However, it should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all of the devices, components, modules, etc., discussed in conjunction with the accompanying drawings. Combinations of these methods may also be used.

[0053] Figure 1This is a block diagram of an example industrial environment 100. In this example, multiple industrial controllers 118 are deployed throughout the industrial plant environment to monitor and control corresponding industrial systems or processes related to product manufacturing, processing, motion control, batch processing, material handling, or other such industrial functions. The industrial controllers 118 typically execute corresponding control programs to monitor and control the industrial equipment 120 that constitutes the controlled industrial asset or system (e.g., industrial machine). One or more industrial controllers 118 may also include software controllers executing on a personal computer, blade server, or other hardware platform or cloud platform. Some hybrid devices may also combine controller functionality with other functions (e.g., visualization). The control programs executed by the industrial controllers 118 may include any conceivable type of code for processing input signals read from the industrial equipment 120 and controlling output signals generated by the industrial controllers, including but not limited to ladder logic, sequential function charts, function block diagrams, structured text, C++, Python, Javascript, etc.

[0054] Industrial device 120 may include input devices, output devices, or devices that serve as both input and output devices. Input devices provide data related to the controlled industrial system to industrial controller 118, and output devices respond to control signals generated by industrial controller 118 to control various aspects of the industrial system. Example input devices may include telemetry devices (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc.), manual operator control devices (e.g., pushbuttons, selector switches, etc.), safety monitoring devices (e.g., safety mats, safety cords, light curtains, etc.), and other such devices. Output devices may include motor drivers, pneumatic actuators, signaling devices, robot control input devices, valves, etc. Industrial device 120 is an example of such a device. M Some industrial equipment can operate autonomously on the factory network 116 without being controlled by the industrial controller 118.

[0055] Industrial controller 118 can communicate with industrial equipment 120 via hardwired connection or via wired or wireless network. For example, industrial controller 118 may be equipped with local hardwired inputs and outputs to communicate with industrial equipment 120 and influence the control of the equipment. Local controller I / O may include digital I / O that sends discrete voltage signals to and receives discrete voltage signals from field devices, or analog I / O that sends analog voltage or current signals to and receives analog voltage or current signals from the device. Controller I / O can communicate with the controller's processor via a backplane, allowing digital and analog signals to be read into and controlled by the control program. Industrial controller 118 may also communicate with industrial equipment 120 via factory network 116 using, for example, a communication module or integrated networking port. Exemplary networks may include the Internet, intranet, Ethernet, Ethernet / IP, device network, control network, data highway and data highway plus (DH / DH+), remote I / O, fieldbus, Modbus network communication protocol, Profibus process fieldbus, wireless network, serial protocol, etc. The industrial controller 118 may also store persistent data values ​​that can be referenced by the control program and used for control decisions, including but not limited to: measured or calculated values ​​representing the operational status of the controlled machine or process (e.g., tank level, position, alarms, etc.), or captured time-series data collected during the operation of the automated system (e.g., status information at multiple time points, diagnostic occurrences, etc.). Similarly, some intelligent devices—including but not limited to motor drives, machinery, or condition monitoring modules—may store data values ​​used to control the status of operations and / or visualize the status of operations. Such devices may also capture time-series data or events in a log for later retrieval and viewing.

[0056] Industrial automation systems typically include one or more personal machine interfaces (HMIs) 114 that allow factory personnel to view telemetry and status data associated with the automation system and to control aspects of system operation. The HMI 114 can communicate with one or more industrial controllers 118 via a factory network 116 and exchange data with the industrial controllers to facilitate visualization of information related to the controlled industrial process on one or more pre-developed operator interface screens. The HMI 114 can also be configured to allow operators to submit data to the memory address or designated data tag of the industrial controller 118, thereby providing operators with a means to issue commands to the controlled system (e.g., cyclic start commands, equipment actuation commands, etc.), modify setpoint values, etc. The HMI 114 can generate one or more display screens through which operators interact with the industrial controller 118 and thus with the controlled process and / or system. Example display screens can use graphical representations of processes to visualize the current status of an industrial system or its associated equipment. These graphical representations display measured or calculated values, use color or positional animations based on status, present alarm notifications, or employ other such techniques to present relevant data to the operator. The data presented in this manner is read from the industrial controller 118 by the HMI 114 and displayed on one or more display screens according to a display format selected by the HMI developer. The HMI may include a fixed-location or mobile device with a user-installed or pre-installed operating system and user-installed or pre-installed graphical application software.

[0057] Some industrial environments may also include other systems or devices related to specific aspects of the controlled industrial system. These systems or devices may include, for example, one or more data historians 110 that aggregate and store production information collected from the industrial controller 118 and other industrial equipment.

[0058] Industrial equipment 120, industrial controllers 118, HMIs 114, associated controlled industrial assets, and other factory floor systems such as data history databases 110, vision systems, and other such systems operate at the operational technology (OT) level of the industrial environment. Higher-level analytics and reporting systems can operate at a higher enterprise level within the information technology (IT) domain of the industrial environment (e.g., on office network 108 or cloud platform 122). Such higher-level systems may include, for example, an Enterprise Resource Planning (ERP) system 104 that integrates and manages high-level business operations, such as finance, sales, order management, marketing, human resources, or other such business functions. Given these higher-level business considerations, a Manufacturing Execution System (MES) 102 can monitor and manage control operations at the control level. A reporting system 106 can collect operational data from industrial equipment on the factory floor and generate daily or shift reports summarizing operational statistics for controlled industrial assets.

[0059] OT-level systems can be distributed and complex, and may integrate with numerous physical devices. This challenging environment, coupled with domain-specific programming and development languages, can make developing control systems on OT-level systems difficult, resulting in long development cycles for developing, testing, and ultimately deploying new control system designs. Furthermore, given the general lack of current virtualization and simulation capabilities, industrial automation systems must be purchased, programmed, and installed in the physical operating environment before actual testing or optimization can begin. This workflow often leads to project delays or cost overruns. In addition, the inherent complexity and customizable nature of installed industrial monitoring and control systems can make it difficult for owners of industrial assets (e.g., plant owners or industrial enterprise entities) to manage their OT-level systems and protect their proprietary intellectual property from catastrophic failures or cyberattacks.

[0060] To address these and other issues, one or more implementations described herein provide a cloud-based Industrial Development Center (IDH) that supports development and testing capabilities that are easy for industrial customers to use and offered as a service. The IDH includes an enhanced storage platform and associated design tools (collectively referred to as Vault), which acts as a repository where customers can store control project code, equipment configurations, and other digital aspects of industrial automation projects. The IDH system facilitates the easy discovery and management of digital content associated with control systems and can be used for system backup and restore, code conversion, and version management.

[0061] Figure 2This is a block diagram of an example Industrial Development Center (IDH) storage system 202 according to one or more embodiments of this disclosure. Aspects of the systems, apparatus, or processes described in this disclosure may constitute machine-executable components implemented within one or more machines, for example, implemented on one or more computer-readable media (or media) associated with one or more machines. Such components, when executed by one or more machines (e.g., one or more computers, one or more computing devices, one or more automation devices, one or more virtual machines, etc.), can cause one or more machines to perform the described operations.

[0062] IDH repository system 202 may include a user interface component 204, a project generation component 206, a project telemetry component 208, a project analysis component 210, a project documentation component 212, an asset recovery component 214, a simulation component 216, a simulation component 218, a device interface component 220, an access management component 222, a provisioning component 224, one or more processors 226, and a memory 228. In various embodiments, one or more of the user interface component 204, project generation component 206, project telemetry component 208, project analysis component 210, project documentation component 212, asset recovery component 214, simulation component 216, simulation component 218, device interface component 220, access management component 222, provisioning component 224, one or more processors 226, and memory 228 may be electrically and / or communicatively coupled to each other to perform one or more of the functions of IDH repository system 202. In some implementations, components 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, and 224 may include software instructions stored on memory 228 and executed by processor 226. The IDH storage system 202 may also be compatible with… Figure 2 It may interact with other hardware and / or software components not depicted herein. For example, processor 226 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0063] IDH storage system 202 can be implemented on a cloud platform as a collection of cloud-based services to facilitate access for a wide variety of users with business or technical relationships, including industrial equipment owners (e.g., industrial enterprise entities or plant owners), equipment suppliers, original equipment manufacturers (OEMs), system integrators, or other such user entities. The cloud platform on which system 202 executes can be any infrastructure that allows cloud-capable devices to access and utilize shared computing services. The cloud platform can be a public cloud accessible via the internet by devices with internet connectivity and appropriate authorization to use IDH storage services. In some scenarios, the cloud platform can be provided by a cloud provider as a Platform as a Service (PaaS), and IDH storage system 202 can reside on and execute on the cloud platform as a cloud-based service. In some such configurations, the owner of IDH storage system 202 can offer access to the cloud platform and associated IDH storage services as a subscription service to customers. Alternatively, the cloud platform can be a private cloud operated internally by an industrial enterprise (owner of the plant facility). An example private cloud platform may include a collection of servers that host an IDH repository system 202 and reside on a firewall-protected corporate network.

[0064] User interface component 204 can be configured to receive user input and present output to the user in any suitable format (e.g., visual, audio, haptic, etc.). In some embodiments, user interface component 204 can be configured to communicatively interface with client devices (e.g., laptops, tablets, smartphones, etc.) that are communicatively connected to IDH storage system 202 (e.g., via hardwired or wireless connections). User interface component 204 can then provide an IDH interface environment for the client devices, through which system 202 receives user input data and presents output data. In other embodiments, user interface component 204 can be configured to generate and provide appropriate interface screens to client devices (e.g., program development screens, project submission screens, analysis results screens, etc.) and exchange data via these interface screens. Input data that can be received via various embodiments of user interface component 204 may include, but is not limited to, programming code (including industrial control programming, such as ladder logic programming), device configuration data, engineering drawings, HMI applications, or other such inputs. The output data presented by various implementations of the user interface component 204 may include program code, programming feedback (e.g., errors and highlights, coding suggestions, etc.), control item telemetry and recommendations, item test results, etc.

[0065] Project generation component 206 can be configured to create a control system project comprising one or more project files based on design input received via user interface component 204 and industry knowledge, predefined code modules, and asset models maintained by IDH repository system 202. The control system project may include industrial control code (e.g., ladder logic, structured text, function block diagrams, etc.), one or more HMI applications including one or more HMI interface screen definitions, device configuration files, or other such project files.

[0066] Project telemetry component 208 can be configured to analyze user-submitted industrial control projects and generate project telemetry or statistical information based on that analysis. Example project telemetry data that can be generated by project telemetry component 208 may include, but is not limited to, a list of equipment used in the project, information on how the equipment is used, reports indicating the extent to which equipment or associated software will operate close to hardware or software capacity limits, estimated memory or energy consumption during project operation, or other such statistics.

[0067] Project Analysis Component 210 is configured to analyze project telemetry data generated by Project Telemetry Component 208 and generate design recommendations or warnings based on the analysis. Project Analysis Component 210 can also generate equipment or gear usage statistics inferred from multiple projects submitted by multiple end customers for use by equipment suppliers or OEMs.

[0068] Project documentation component 212 can be configured to generate various project handover or verification documents based on the analysis of the control system project, including but not limited to approval documents, safety verification checklists, I / O inspection documents, audit documents, or other such documents. Asset recovery component 214 can be configured to collect and archive backups of control project files and device configurations, and deploy these archived project files as needed for disaster recovery or remote deployment purposes. Simulation component 216 can be configured to simulate the execution of the industrial control project under test on a virtualized (or simulated) industrial controller. Simulation component 218 can be configured to simulate the operation of a virtualized model of an industrial automation system under the control of the simulated industrial control project. Device interface component 220 can be configured to receive real-time operational and status data from the industrial devices that make up the automation system during operation and deploy control commands to selected devices in the automation system.

[0069] Access management component 222 can be configured to manage remote access to registered resources, such as industrial assets already registered via a gateway device. Provisioning component 224 can be configured to deploy instances of virtual machine images as executable virtual machines within a customer-specified digital engineering space.

[0070] One or more processors 226 may execute one or more of the functions of the systems and / or methods disclosed herein. Memory 228 may be a computer-readable storage medium storing computer-executable instructions and / or information for performing the functions of the systems and / or methods disclosed herein.

[0071] Figure 3 This diagram illustrates a general architecture of an IDH repository system 202 according to one or more implementations. As described above, the IDH repository system 202 can be executed on a cloud platform as a collection of cloud-based storage, analysis, and project editing services. Client devices 302 (e.g., laptops, tablets, desktops, mobile devices, wearable AR / VR devices, etc.) can access the repository system's project development and analysis tools and utilize these tools to load or create control projects for the automation system under development. For this purpose, the system's user interface component 204 can remotely provide an IDH client 304 to the client devices 302. The IDH client 304 includes multiple interface displays that serve as interfaces to the system 202.

[0072] Using tools provided by the repository system 202, users can submit control items 306 to the repository system 202. Typically, control items 306 include digital data or files that facilitate the monitoring and control of automated systems or industrial processes when executed on appropriate industrial equipment deployed within an industrial environment. Control items 306 may include control code (e.g., ladder logic, sequential function charts, structured text, function block diagrams, etc.) intended to be executed on industrial controllers, equipment configuration data (e.g., industrial controller configuration files, motor drive configuration files, etc.), visualization applications (e.g., HMI applications, AR / VR content, etc.), or other such control item data. In some scenarios, control items 306 may also include engineering documentation for their associated automated systems, including engineering drawings (e.g., CAD files), support documents, maintenance plans, or other such documents. In some scenarios where project development is performed using design tools provided by the IDH repository system 202, control items 306 may be submitted as input to ongoing project development; for example, as control code submitted to the repository system 202 when the designer is writing code. Alternatively, users can submit completed control items to a repository for storage, analysis, and feedback. These two scenarios will be described in more detail in this article.

[0073] In addition to serving as cloud-based storage for submitted control items 306, the repository system 202 applies various analyses to the submitted control items 306 and generates project recommendations 308 for improving aspects of the submitted control items. This analysis can be based on customer-specific and supplier-specific information contained in the customer repository 324 and supplier repository 326 maintained on the repository system 202, as well as general industry expertise stored in the knowledge base 328.

[0074] The repository system 202 can maintain multiple customer repositories 324 designated for various end-user entities (e.g., equipment or plant owners, industrial enterprises, etc.). Owners of industrial assets can submit project versions 310 and archive them in their designated customer repositories 324. Users can also define custom plant standards 314, which can be stored in the customer repositories 324 and applied to submitted control projects to ensure compliance with the defined standards. Customer repositories 324 can also store digital asset models 312 corresponding to the industrial assets used at customer facilities. These asset models 312 can be used for various purposes, including but not limited to digital simulations of submitted control projects.

[0075] The storage system 202 can also analyze control items 306 based on supplier-specific data submitted by equipment or equipment suppliers and stored in one or more supplier storage systems 326. Similar to the customer storage system 324, the storage system 202 can maintain multiple supplier storage systems 326 assigned to various equipment suppliers or OEMs. Suppliers can submit equipment profiles 316 or other types of digital models of their equipment or equipment to be stored in their designated supplier storage system 326. These equipment profiles 316 can be used in conjunction with digital twins of customer automation systems or factory environments, or to compare customer usage of their equipment with defined equipment capacity. Suppliers can also submit and store applications 318 or code segments (e.g., control logic, HMI interface displays, reporting tools, etc.) that can be executed in conjunction with the operation of their equipment.

[0076] The submitted control item 306 can also be analyzed in light of other archived items 320 submitted by other customers and considered similar to the submitted item. This analysis may be useful in identifying parts of the submitted control item 306 that deviate from more common approaches used by other designers (e.g., code used for programming specific types of industrial machines or processes). The knowledge base 328 can also store multiple industry-specific standard definitions that can be examined against the submitted control item 306. As will be described herein, other types of information can be stored and managed by the repository system in various storage specifications and can be used to analyze and optimize the submitted control item data.

[0077] As described above, control item 306 can be submitted as one or more completed project documents for a given industrial control project for storage and analysis, or control item 306 can be submitted as design input during project development if the local project development tools of the repository system are being used to create a new project. Figure 4 This is a diagram illustrating an example data flow associated with the creation of a new control project 306 for an automation system designed using a repository system 202, according to one or more implementations. In this example, a client device 302 accesses the project development tools of the repository system and utilizes these tools to create a control project 306 for the automation system under development. The control project 306 may include one or more of the following: industrial controller code (e.g., control logic, structured text, sequence function charts, etc.), device configuration files or parameter settings, an HMI application defining an HMI screen or an AR / VR visualization for visualizing the operation of the automation system, or other such aspects of the control project.

[0078] Therefore, to facilitate project development, the user interface component 204 can provide a development interface display for the client device 302, which allows the user to submit design inputs 404 to the repository system 202 in various supported formats, including but not limited to: control programming executed on an industrial controller, device configuration settings to be downloaded to the corresponding industrial equipment (e.g., motor drivers, sensors, industrial controllers, etc.) to facilitate the configuration of those devices, HMI screen development data, or other such design inputs 404. Based on the design inputs 404, the project generation component 206 generates a control project 306, which includes one or more of the following: compiled controller code, device configuration data, HMI application files, or other executable control project data that can be deployed and executed on appropriate industrial equipment to perform the programmed control functions.

[0079] In some implementations, the repository system 202 can assist developers in designing hybrid project development methodologies, allowing design functionality to be partitioned between local workstations and cloud-based design services. In this regard, the repository system 202 can help designers define which parts of project development will be performed locally and which will be performed on the cloud platform.

[0080] Furthermore, during the development of control project 306, project generation component 206 can generate design feedback 406 designed to assist developers in the development and optimization of control project 306, and this design feedback 406 can be presented to the designer as real-time feedback by user interface component 204. This design feedback 406 can be generated based on analysis of the design input 404 itself and information stored in customer repository 324, supplier repository 326, and knowledge base 328.

[0081] For example, when a designer is entering control code to be compiled and executed on an industrial controller as design input 404, project generation component 206 can perform code analysis on the code and provide recommendations, notifications, or predictions based on analyses related to various code or project quality metrics. This analysis may include determining whether the control code conforms to the engineering standards and practices used at the plant facility for which the code is being developed. To assist in this analysis, engineers at the plant facility can submit control code standard definitions that define the coding standards expected to be followed by all control code before it is permitted to execute within the plant facility. These coding standards can be stored as plant standards 314 in the customer's repository 324 and can be referenced by project generation component 206 when the designer submits design input 404 to determine whether the submitted control code conforms to the plant standards.

[0082] Factory standard 314 can define coding standards based on preferred control behaviors (e.g., preferred control sequences to be used or interlocks that must be identified when performing a specific type of control action, preferred maximum or minimum control setpoints for a specific machine operation, etc.) and preferred code formats. Factory standard 314 can also define preferred parameters or configurations for specific types of equipment (e.g., motor drives, network infrastructure equipment, etc.), and project generation component 206 can monitor submitted design inputs 404 during development to ensure that any equipment configuration submitted by the designer conforms to the defined standards. After determining, based on this assessment, that the designer has entered non-compliant equipment configurations, project generation component 206 can generate design feedback that notifies the user of deviations and indicates permissible configuration parameters.

[0083] Factory standard 314 may also include project-specific standards, including functional specifications or safety verification requirements. Project generation component 206 can monitor design input 404 with reference to the functional project requirements defined by factory standard 314, and generate design feedback upon determining that any part of the submitted design input 404 deviates from the defined functional specifications or safety verification requirements. This design feedback notifies the user of the deviation and provides recommendations on how to bring the deviating parts of the control project into compliance. Factory standard 314 can define functional specifications based on the manufacturing functions to be performed, preferred equipment suppliers, equipment to be used, product output requirements, energy consumption requirements, network utilization requirements, or other such specifications. Based on the functional specifications outlined in factory standard 314, project generation component 206 can infer relevant attributes of the control project based on design input 404 and notify the user if any aspect of the project deviates from these standards. For example, if the functional specifications indicate that only motor drives from the indicated preferred supplier will be used for the new installation, the project generation component 206 can infer from the design input 404 (e.g., from the I / O configuration of the industrial controller, or from the device configuration data included in the design input 404) that equipment from an unapproved supplier is being included in the control project design and notify the user that other equipment from an approved supplier must be replaced.

[0084] In some implementations, project generation component 206 may also compare control codes submitted as part of design input 404 with previously submitted control codes included in archived project version 310 for the same control project or different control projects developed by the same customer. Based on analysis of other control codes submitted by the customer and archived in customer repository 324, project generation component 206 may learn or infer typical coding styles or design methods used by the customer. For example, this may include code indentation preferences, preferences regarding the use of call statements, hierarchical annotation standards, variable or I / O naming standards, or other such preferred programming characteristics. In addition to control coding standards, project generation component 206 may also identify preferred ways in which the customer programs certain control operations. For example, project generation component 206 may identify, based on analysis of archived project version 310, that the customer uses specific control sequences to move material from a source container to a tank, or that the customer typically associates specific control operations with a set of interlocks that must be satisfied before the control operation can be performed.

[0085] Based on these learned customer programming preferences, project generation component 206 can identify, based on a comparison with project version 310, whether the control programming submitted as part of design input 404 deviates from the plant's preferred coding practices or the preferred way the plant controls certain industrial operations, and generate design feedback 406. This design feedback 406 informs of these deviations and suggests alternative control coding that will bring the current project in line with the previous design strategy. The feedback 406 may include, for example, recommendations to add one or more interlocks to the control programming for a specific control operation, recommendations to reorder the sequence of operations to control a specific type of machine, recommendations to rename variables or I / O points to conform to the plant's preferred naming conventions, recommendations to add or modify ladder comments, recommendations to change the indentation of parts of the control code, recommendations to replace duplicate code instances with CALL statements, or other such feedback.

[0086] Project generation component 206 may also reference vendor-specific equipment or device data in one or more vendor repositories 326 to predict whether the user-submitted design input 404 will cause equipment integration or compatibility issues. This determination may, for example, be based on equipment profiles 316 submitted by equipment vendors for access by project generation component 206. Each equipment profile 316 may include digital specification data for a given device and may also document known compatibility issues for that device. Using this information, project generation component 206 may evaluate the submitted design input 404 in light of known limitations of one or more devices to determine whether any part of the submitted control programming or equipment configuration will cause performance or integration problems. This evaluation may also consider inferred interactions between several sets of devices that the user is designing for collaborative operation. For example, if design input 404 suggests that the designer intends to configure two incompatible devices for collaborative operation (based on known compatibility issues documented in equipment profile 316), project generation component 206 may generate design feedback 406 indicating the two incompatible devices.

[0087] The analysis applied by the project generation component 206 can also identify incorrect or suboptimal coding practices within the submitted control code. This identification can be based in part on preferred coding practices defined in standard definition 322 maintained in the knowledge base 328 of the repository system. Coding problems that can be identified by the project generation component 206 may include, but are not limited to, excessive nesting levels, excessive code duplication, and incorrect code indentation. In response to detecting such coding problems in the user-submitted code, the project generation component 206 can provide design feedback that recommends alternative programming methods that will make the control code conform to preferred coding standards (e.g., recommending the use of case statements to eliminate excessive ladder logic).

[0088] Project generation component 206 can also identify modifications or replacements that can be made within control project 306, which can improve memory or network utilization associated with the execution of control project 306. This can include, for example, identifying alternative control code programming—or making other modifications to control project 306 that can reduce the processing load on the industrial controller without changing the intended control functionality. In another example, project generation component 206 can determine whether utilizing currently unused functions of a device (e.g., operating mode or configuration parameter settings) or replacing the device currently used in control project 306 with a different device model can reduce energy consumption or network bandwidth utilization.

[0089] To support enhanced development capabilities, some implementations of the IDH repository system 202 can support control programming based on an object-based data model rather than a tag-based architecture. Automation objects can be used as building blocks for this object-based development architecture. Figure 5 This is a diagram illustrating several example automation object attributes related to the construction, deployment, and execution of control projects 306 that can be utilized by the repository system 202. Automation objects 504 can be created and expanded during design, integrated into a larger data model, and consumed during operation. These automation objects 504 provide a common data structure on the repository system 202 and can be stored in an object library (e.g., a portion of memory 228) for reuse. The object library can store predefined automation objects 504 representing various categories of real-world industrial assets 502, including but not limited to pumps, tanks, values, motors, motor drives (e.g., variable frequency drives), industrial robots, actuators (e.g., pneumatic or hydraulic actuators), or other such assets. Automation objects 504 can represent elements at virtually any level of an industrial enterprise, including individual devices, machines composed of many industrial devices and components (some of which may be associated with their own automation objects 504), and entire production line or process control systems.

[0090] An automation object 504 representing a given type of industrial asset can be encoded with aspects such as 2D or 3D visualization, alarms, control coding (e.g., logic or other types of control programming), analysis, startup processes, test protocols and scripts, verification processes and reports, simulations, diagrams, safety protocols, and other attributes associated with the industrial asset 502 represented by object 504. The automation object 504 can also be geotagged using location information identifying the location of the associated asset. During the operation of control project 306, the automation object 504 corresponding to the given real-world asset 502 can also record the asset's status or operational history data. Typically, the automation object 504 serves as a programmatic representation of its corresponding industrial asset 502 and can be incorporated into control project 306 as an element of control code, 2D or 3D visualization, an industrial asset knowledge base or maintenance guidance system, or other such aspects.

[0091] Some implementations of the project analysis component 210 can also predict network traffic or load statistics based on device configuration information obtained from the analysis of control item 306, and generate network configuration recommendations based on these predictions. This analysis can be based on a comparison of the customer's network configuration with known or recommended network configurations. The project analysis component 210 can also generate a network risk report indicating the risk of network failures due to the implementation of the proposed control design.

[0092] Completed control project 306 – using the project editing tools of the repository system (as described above) Figure 4 Developed using a separate control project development platform (e.g., ladder logic development platform, HMI application development platform, device configuration application, etc.) as described above, may be submitted to the repository system 202 for analysis, archiving, or upgrade purposes, such as... Figure 3 As described in the document. In this respect, the IDH repository system 202 serves as a secure and intelligent repository of industrial control projects open to any number of participating industrial customers. It provides both a secure archive of control projects 306 and the ability to analyze these projects 306 for the purpose of generating project recommendations 308. Project recommendations 308 are designed to optimize control designs or guide designers to previously unknown and unused equipment features, which can improve the performance of control projects if these features are used.

[0093] To facilitate intelligent analysis of the submitted control item 306, the IDH repository system 202 may include a project telemetry component 208 that generates project telemetry data for the submitted control item 306. This project telemetry data can provide insights into both the control item itself and the equipment and device topology of the automation system for which the control item 306 is being designed. Figure 6 This is a diagram illustrating the extraction of item telemetry data 602 from control items 306 submitted to the storage system 202. Based on the analysis of control items 306, item telemetry component 208 can determine or infer characteristics of the control item itself, information about the equipment or apparatus constituting the automation system to be monitored and controlled by control items 306, predictions about the performance or resource utilization of the controlled system, estimated impact of control design on the equipment lifecycle of one or more devices, or other such item metrics.

[0094] For example, based on analysis of industrial controller program files—which may include the industrial controller's control code, I / O configuration data, and networking configuration data—project telemetry component 208 can identify input or output devices connected to the industrial controller (e.g., based on an examination of the I / O configuration or control code itself) and record a list of these devices in project telemetry data 602. Similar analysis can be used to determine I / O or control modules configured for use and information about how the controller's I / O is utilized. Project telemetry component 208 can also record inferred functional or topological relationships between any two or more devices or equipment identified as part of the automation system. Project telemetry component 208 can also estimate the total amount of network bandwidth or energy expected to be consumed by the automation system. To generate further insights into how the devices constituting the control system are being used, project telemetry data 602 can also record which subset of the available characteristics of the devices is currently being used by control project 306.

[0095] In addition to metrics for the automated system to be controlled, the project telemetry component 208 can also estimate performance metrics for the control code itself, such as the estimated amount of memory or processing power required to execute various aspects of the control project 306.

[0096] In some cases, project telemetry component 208 can enhance project telemetry data 602 generated for control project 306 by referencing vendor-specific device information stored in device profiles 316 in vendor repository 326. For example, project telemetry component 208 can identify specific device models (e.g., I / O modules, network infrastructure devices, motor drives, servos, actuators, etc.) being used as components in an automation system based on analysis of control project 306. Based on the device identification, project telemetry component 208 can access vendor repository 326 corresponding to the device's vendor, determine if a device profile is available for that device, and if so, retrieve the device's functional specification data from device profile 316 to include in project telemetry data 602. Depending on the device type, this functional specification data may include information such as available I / O, available configuration parameters or functions, available memory or processing power, lifecycle information, response time, physical dimensions, rated power, networking capabilities, operating limitations (e.g., environmental requirements, such as the ambient temperature to which the device is rated), or other such supplemental device information.

[0097] Once the project telemetry data 602 has been extracted for control project 306, the project analysis component 210 of the repository system can generate recommendations or notifications related to the project design based on the analysis of the project telemetry and the encoded industry expertise. Figure 7 This diagram illustrates the generation of project recommendation 702 based on the analysis of extracted project telemetry data 602. By analyzing project telemetry data 602, project analysis component 210 can determine how to use the customer's industrial hardware and software assets and generate recommendations or notifications based on this assessment. This can include determining whether a proposed control project—due to control sequences defined by control programming or configuration parameters set for one or more industrial devices—will cause the hardware or software used in the control project to operate close to or above its rated operating threshold. For example, based on knowledge of the I / O utilization of the control project as recorded in project telemetry data 602 and the I / O capacity of the devices used in the control project (which can be determined based on specification data about those devices as recorded in device profile 316), project analysis component 210 can generate a notification that the proposed control design will cause one or more control devices (e.g., industrial controllers or I / O modules) to operate close to or above their maximum I / O capacity. Based on this assessment, the project analysis component 210 can also recommend alternative control devices with a higher I / O capacity than the currently proposed I / O capacity in the control project, in order to increase the number of spare I / O points for future expansion.

[0098] Project analysis component 210 can also estimate equipment utilization over time based on analysis of project telemetry data 602, cross-referencing this information with equipment lifecycle information recorded in equipment profile 316, and generating notifications regarding the expected lifecycle or failure time of the equipment under conditions of use as proposed in the control project. If an equivalent device with a longer expected lifecycle is available, project analysis component 210 can also generate a recommendation to replace the currently proposed equipment with the equivalent device. Alternatively, project analysis component 210 can recommend modifications to the control project that extend the equipment's lifespan (e.g., by reducing the equipment's operating frequency without otherwise affecting control outcomes).

[0099] In some implementations, the project analysis component 210 may also identify unused features of the device that, if utilized, could improve one or more operational metrics of the control project. These features may be available features of the device that are unknown to the designer (e.g., configuration parameters, potential functions that are inactive by default but can be activated or invoked, etc.). In an example scenario, the project analysis component 210 may discover available features of the device based on the functional specifications documented in the device profile 316 and determine whether any unused features are likely to be relevant to aspects of the control project 306 or whether they can improve the performance metrics of the control project 306. For example, the project analysis component 210 may determine that invoking the device's currently unused operating modes could reduce the device's memory footprint or network bandwidth usage, improve the throughput of the automation system, reduce overall project energy or material consumption, reduce product waste, or unlock another unforeseen improvement in the operation of the project. If such a potential design improvement is identified, the user interface component 204 may send a notification recommending the design modification to the designer (or another user entity associated with the customer). In the example scenario, based on the device profile submitted as part of control project 306, project analysis component 210 can determine that unused features of the driver (e.g., regenerative braking) can reduce overall power consumption and generate a notification identifying the driver and indicating the unused features. This notification can also provide recommendations on when the feature should be invoked during the control sequence to obtain the expected benefits.

[0100] Project analysis component 210 can also determine whether any aspect of control project 306 deviates from industry standards or plant standards. This can be based on a comparison between project telemetry 602 and industry standards defined in standard definition 322 (stored in knowledge base 328) or internal standards defined in plant standards 314 stored in customer repository 324. In the case of industry standards, the specific set of standards compared with control project 306 may be the functionality of the industrial vertical in which control project 306 will operate (e.g., automotive, pharmaceutical, food and drug, oil and gas, etc.), as some types of industries may require compliance with a set of vertical-specific control standards or requirements. Therefore, knowledge base 328 can categorize standard definition 322 according to industrial verticals, allowing project analysis component 210 to select an appropriate set of standards to apply to control project 306. Standard definition 322 can define such an industry standard as the required amount of unused I / O that must be reserved as standby capacity, emission or energy consumption requirements, safety integrity level (SIL) requirements, interlocks or permissions that should be associated with a given type of control operation (e.g., associating a "valve open" command with the tank's fill level, preventing a machine start command from being executed until a specified safety interlock is met), or other such standards.

[0101] Example internal standards that can be documented in the customer's factory standard 314 and applied to control item 306 may include, but are not limited to, control coding standards (as combined above). Figure 4 The described equipment is approved by a preferred supplier for use within the plant, and must be associated with safety interlocks or licenses for certain control functions, or other such criteria.

[0102] Project analysis component 210 can also perform any project analysis and generate any design feedback 406, as described above by project generation component 206. Some project analysis results may also trigger expert support checks, causing project analysis component 210 to initiate remote checks of the project, subject to the designer's permission, by a technical support entity.

[0103] Since the control project analysis performed by the project telemetry component 208 and the project analysis component 210 can identify or infer the equipment and networks to be used by the control project 306, the project analysis component 210 can also generate a list of industrial assets or equipment used by the customer's project. The repository system 202 can store this asset list in a customer repository 324 associated with the owner of the control project 306. Furthermore, if any of the discovered equipment or industrial assets has an associated digital device profile 316 available through the asset's supplier and stored in the supplier repository 326, the repository system 202 can retrieve these device profiles 316 from the supplier repository 326 and store them in the customer repository as an asset model 312 corresponding to the equipment. In this respect, the device profile 316 can represent a generic digital representation of the asset it represents, and the project analysis component 210 can convert these generic device profiles 316 into customized asset models 312 representing assets with unique configurations for the customer based on the project telemetry data 602. A device profile 316 for a given industrial device (e.g., an industrial controller, motor drive, safety equipment, etc.) can be customized, for example, by applying specific configuration parameters for the device (such as those obtained from project telemetry data 602) to the device profile 316 to generate a customized asset model 312 for the device. These asset models 312 can serve as the basis for a digital twin of an automation system, which can be used to simulate and test control of project 306, as will be described in more detail herein.

[0104] The results of the analysis performed on the project telemetry data 602 can also be formatted and filtered for use by equipment providers (e.g., equipment suppliers, OEMs, etc.) participating in the repository system ecosystem, and this information can be used by equipment providers as equipment usage statistics 704. For example, for each equipment supplier using its equipment in the controlled project 306, the project analysis component 210 can provide the supplier with data indicating which of its equipment is being used and which features of those equipment are being used. This data can be provided to suppliers in a manner that anonymizes the end customer and prevents the supplier from viewing the customer's proprietary information (e.g., formula data, production statistics, etc.). Typically, the repository system 202 protects the customer's proprietary data while providing sufficient access to provide services. The user interface component 204 allows users to easily control how proprietary data is exposed or hidden from external entities also participating in the IDH platform.

[0105] For a given equipment provider, user interface component 204 can compile statistics on these devices or equipment from multiple control projects 306 submitted by multiple different customers and present the aggregated equipment usage and feature utilization information in any suitable presentation format. For example, information about which equipment or assets of the equipment provider are being used can be presented as the quantity of each asset being used at customer sites, geographic details indicating where the assets are used, charts indicating the relative popularity of the supplier's product line, etc. Similar presentations can be used to convey which features (e.g., operating modes, configuration parameters, etc.) of each of the supplier's products are being used, or how close the products being used are to their functional capabilities, as determined based on aggregated project telemetry data 602 collected from multiple end customers using the supplier's products. Equipment providers can use these statistics 704 to make decisions about whether to discontinue a product due to a lack of popularity; identify potentially useful product features that their customers are not fully utilizing and therefore should be heavily promoted; decide whether to increase or decrease memory, processing, or I / O resources for certain products based on the extent to which customers use these resources; or make other informed decisions regarding product design and promotion.

[0106] While some equipment usage statistics 704 can be presented to equipment providers anonymously to end customers (e.g., for global product usage analysis purposes), other selected statistics 704 can be presented on a per-customer basis based on service or licensing agreements between the equipment provider and its customers. For example, some equipment providers (e.g., OEMs) can offer equipment usage as a subscription service, in which customers purchase a license for a specified degree of equipment usage (e.g., a specified number of operating cycles per month, a finite subset of available equipment features, etc.). In such a case, Project Analysis Component 210 can determine the estimated usage frequency of the provider's equipment based on analysis of Project Telemetry Data 602 and make this information available to the equipment provider for licensing purposes.

[0107] Based on another type of analysis that can be applied to project telemetry data 602, project analysis component 210 can compare control project 306 or its extracted project telemetry data 602 with similar archived projects 320 submitted by other end customers, and identify aspects of the submitted control project 306 that significantly deviate from the corresponding aspects of the similar archived projects 320. User interface component 204 can then present a notification indicating the deviations of control project 306 and recommending project modifications as project recommendation 702, which will bring control project 306 in line with general practices. In this way, repository system 202 can leverage collective industry expertise or general practices to provide recommendations on best practices relative to the submitted control projects. Aspects of the submitted control project 306 that can be compared in this way may include, but are not limited to, interlocking designs for a given type of control operation, device configuration parameters (e.g., motor drive settings, network infrastructure device settings, safety device settings, etc.), control setpoints, the operational sequence or timing of a given type of control operation or sequence, or other such project aspects.

[0108] Some implementations of the repository system 202 can also simulate one or more aspects of the submitted control item 306 to predict whether the control item 306 will produce the desired result relative to one or more controlled machines. This allows for pre-testing of the control item 306 before execution on the physical machine. Figure 8 This diagram illustrates the simulation of control project 306 by IDH storage system 202. In this example, the simulation component 216 of the storage system acts as an industrial controller simulator to perform control programming defined as part of control project 306 for digital twin 810 or other types of virtualization of the automation system being developed and tested for control project 306. In some embodiments, simulation component 218, which builds and simulates digital twin 810, may create digital twin 810 in part based on asset models 312 representing industrial equipment or assets constituting the automation system. As described above, these asset models 312 may be maintained on customer storage 324 and may include equipment profiles 316 obtained from supplier storage 326 and customized based on configuration data obtained from project analysis. Using these asset models 312 and the functional and / or topological relationships between industrial assets represented by asset models 312 as inferred from the analysis of control project 306, simulation component 218 can generate digital twin 810 for which the automation system of control project 306 can be simulated and tested.

[0109] The simulation component 218 can utilize the automation and mechanical characteristics modeled by the digital twin 810 to simulate aspects of the physical automation system to be monitored and regulated by the control item 306. To this end, the simulation component 218 can virtually interface the control item 306 with the digital twin 810 to facilitate the exchange of analog I / O data between the control item 306 (e.g., control code included in the control item 306) and the digital twin 810, thereby simulating real-world control. The simulation component 218 generates digital and analog I / O values ​​based on the static and dynamic characteristics of the physical system modeled by the digital twin 810. These values ​​represent, for example, sensor outputs, metering outputs, or other plant data similar to data expected to be generated by the physical system. The simulated output data 804 is provided to the simulation component 216, which receives the data 804 as one or more virtual physical inputs. The control item 306 processes these inputs according to user-defined control code defined in the item 306 and generates digital and / or analog controller output data 802 based on this processing. The output data 802 represents the physical output (e.g., PID loop control output, solenoid excitation output, motor control output, actuator control output, robot control output, etc.) generated by the industrial controller or other type of control device executing control code and transmitted to hardwired field devices, including automation systems. The controller output data 802 is provided to the appropriate input points of the digital twin 810, which updates the analog output data 804 accordingly.

[0110] In addition to generating simulation output data 804, simulation component 218 can also generate asset response data 806 in response to the simulation controller output data 802, based on analysis of the simulation data exchange and the expected behavior of the modeled industrial asset. For example, based on the automation and mechanical characteristics of the industrial asset modeled in digital twin 810, simulation component 218 can predict the expected behavior of the modeled industrial asset and the behavior of products manufactured by the asset in response to controller output data 802, and communicate this predicted behavior as asset response data 806. Example behaviors represented by asset response data 806 may include, but are not limited to: the movement of products through the industrial asset (including speed, acceleration, position, hysteresis, etc.), the flow rate of fluid through the asset, the expected energy consumption of the asset, the expected degradation rate of the mechanical components of the asset (partially based on friction coefficient information defined in asset model 312), the expected forces applied to the various components of the asset during operation, or other such behaviors.

[0111] User interface component 204 can generate and present simulation results 808 on the client device based on the simulation execution results. These simulation results 808 may include simulated operational statistics of the automated system (e.g., product throughput, expected machine downtime frequency, energy consumption, network traffic, expected machine or equipment lifespan, etc.). In some embodiments, asset response data 806 may be provided to project analysis component 210, which can determine whether any simulated asset response deviates from an acceptable or expected range, defined in the functional specifications stored in the client repository 324. Based on the results of this assessment, user interface component 204 can notify the user of any anticipated deviations from the expected operational range and present recommendations for modifications to control item 306, which may bring one or more predicted performance metrics within acceptable tolerances or ranges (e.g., as defined by the project's design specifications).

[0112] At the end of a new design cycle, the repository system 202 can also generate project handover and verification documents for new control items. Figure 9 This diagram illustrates the handover document 902 generated by the IDH repository system 202. Based on the analysis of the completed control project 306, the repository system's project documentation component 212 can generate various project documents 902, including but not limited to approval documents, security verification checklists, I / O inspection documents, and audit trails. At least some of these documents 902 can be generated based on information stored in the customer repository 324. For example, the project documentation component 212 can generate I / O inspection documents for the control project based on knowledge of the devices connected to the control system I / O (as determined from the control project 306) and information about these devices obtained from the asset model 312 corresponding to them. Similarly, a security verification checklist can be generated based on asset-specific security requirements defined in the asset model 312. Some documents 902 can also be generated based on internal approval requirements defined in plant standards 314. These approval requirements can specify, for example, the personnel who must sign off on various aspects of the control project.

[0113] Documents 212 can also be generated based on industry-specific security or auditing standards defined in standard definition 322 of knowledge base 328. In this regard, some industrial verticals may need to comply with rules specifying how to collect and store electronic records related to the engineering and operation of automated systems, how to obtain electronic signatures for automated systems, and what types of documents must be collected for auditing purposes. For example, plant facilities operating within the food and pharmaceutical industries need to maintain records that comply with Title 21 CFR Part 11. Therefore, project documentation component 212 can identify the types of project documents required to control project 306 based on the industrial vertical for which it is designed and the standard definition 322 defining the documentation requirements for that vertical.

[0114] In some implementations, the IDH repository system 202 can also manage digital or electronic signatures associated with the verification checklist generated by the project documentation component 212. Figure 10 This diagram illustrates the collection of digital signatures by a repository system 202 according to one or more embodiments. In this example, a digital verification list 1008 has been delivered to a client device 1006 associated with a person requiring signatures regarding various aspects of control item 306. The verification list is interactive, allowing each user to submit a digital signature 1004 for a corresponding item on the verification list 1008 via interaction with the list. At the repository system 202, the digital signatures 1004 are received from the client device, and the item documentation component 212 maintains a record of the received signatures 1004 as signature tracking data 1002, which tracks which signatures 1004 have been received for each item on the verification list and from whom the signatures 1004 were received. This signature tracking data 1002 can then be referenced for auditing purposes. In some implementations, the repository system can be configured to deploy components of control item 306 (e.g., control codes, HMI visualization applications, device configurations, etc.) to their respective field devices only after all the necessary signatures 1004 indicating approval for those components have been received.

[0115] The IDH repository system 202 can also be used to archive past and current versions of the control project 306 and perform related version control and analysis functions. Figure 11This diagram illustrates the submission of a new version of control project 306 for archiving alongside an older project version 310. In this example, the customer repository 324 archives past and current versions of control project 306 as project version 310. A new version of control project 306 may result from modifications to control code, device firmware upgrades, the addition of control project 306 to accommodate new equipment, or other such changes to the control project. Archiving the current and past versions of control project 306 allows project development to be documented within the repository system and also allows any version of control project 306 to be selected and deployed to the automation system as part of a disaster recovery process (if a portion of the control project executed on the factory floor is lost and must be reinstalled, or if a new version of control project 306 does not perform as required and the previous version must be redeployed). These capabilities can be managed by the asset recovery component 214 of the repository system.

[0116] In some implementations, when a new version of control item 306 is submitted to the IDH repository system 202, the asset recovery component 214 can analyze the new version of control item 306 using one or more previous versions 310 stored in the customer repository 324 and identify any potential new problems introduced in the new version relative to the previous versions. The asset recovery component 214 can also apply customer-defined item analysis queries defined in the plant standards, as well as generic item analysis queries defined as part of standard definitions 322 stored in the repository system's knowledge base 328, to the new version of control item 306. These generic and custom queries can be configured to identify specific design scenarios within control item 306 that may lead to suboptimal control performance. The asset recovery component 214 can present the results of these item analyses as recommendations 1102.

[0117] In some implementations, if an upgrade to the software application used by control item 306 is available, the customer can submit the current version (e.g., vX) of their control item to upgrade to the latest version (e.g., vY). Asset recovery component 214 can also be configured to manage these upgrades. When the customer loads control item 306 to be upgraded into repository system 202, asset recovery component 214 can analyze control item 306 and perform the upgrade, thereby performing any file conversions required to perform a vX to vY upgrade. As part of the upgrade, asset recovery component 214 can also apply any item analyses discussed above (e.g., analyses similar to those applied by item analysis component 210) to the loaded control item 306. After the upgrade is complete, asset recovery component 214 can provide the upgraded control item files along with recommendations (e.g., item recommendation 702 mentioned above) to improve the operation of the control system or optimize the resource utilization of control item 306 itself.

[0118] By allowing multiple versions of a control project to be archived in the customer repository 324 and deployed on demand to plant floor equipment, the repository system's storage and deployment features enable users to deploy different versions of the same control project at different industrial facilities. This functionality is useful for system integrators or other control solution providers serving multiple customers with different groups of industrial assets on which control projects 306 will be executed, as different versions of control projects 306 may need to be executed at different customer locations.

[0119] Asset recovery component 214 can also implement cybersecurity features that verify the authenticity of the submitted control item 306 to ensure that the item 306 was developed and submitted from a reliable source. This authentication can be based in part on code similarity. For example, when a new version of control item 306 is submitted, asset recovery component 214 can compare the new version with one or more previous item versions 310 previously submitted to and archived by repository system 202. If the comparison yields confirmation that the new version is completely different from a previous version 310 loaded by the same customer entity, asset recovery component 214 can flag the newly submitted control item 306 and initiate the delivery of a security notification to a trusted person associated with the customer, requesting inspection and authorization of the new version. In some implementations, asset recovery component 214 can also prevent the deployment of new versions of control items unless authorization is received from a trusted person. Asset recovery component 214 can also authenticate new control items 306 based on compliance with or deviation from coding styles and standards known to the customer, which can be recorded in customer repository 324 as part of factory standards 314.

[0120] Some implementations of the IDH repository system 202 can also provide "backup as a service" for industrial asset profiles or project files. Figure 12This diagram illustrates the intelligent backup of device configuration data 1206 to IDH storage system 202. In some embodiments, an on-premise software agent at the customer facility may locate supported industrial devices or assets (e.g., assets installed in control cabinet 1204) and initiate a backup of the device configuration data 1206 installed on those devices. Device configuration data 1206 may include control codes, configuration parameter settings, HMI applications, or other such control item data. In some embodiments, these software agents may be deployed and managed by a smart gateway device 1202, which resides on the plant network 116 and acts as a gateway or edge device connecting industrial assets on the plant floor to IDH storage system 202. In such embodiments, smart gateway device 1202 may deliver a copy of device configuration data 1206 to IDH storage system 202, and asset recovery component 214 may store a backup of device configuration data 1206 in customer storage 324 as part of the customer's stored item version 310.

[0121] Project backups can also be configured to be version-driven, allowing the asset recovery component 214 to load and archive changes to the control project in response to the detection of modifications to the project on the factory floor (e.g., when a factory engineer modifies the ladder logic on an industrial controller via a direct connection to the controller). In another scenario, backups of asset profiles can be scheduled, allowing the asset recovery component 214 to retrieve and archive the current device configuration at defined times or according to defined backup frequencies.

[0122] By archiving backups of control items in customer storage 324, device configurations can be restored from the most recent known backup in the event of a disaster. Figure 13 This diagram illustrates an example recovery process that can be initiated through IDH storage system 202. In this example, the industrial environment includes one or more industrial controllers 118, HMIs 114, motor drives 1306, servers running higher-level applications (e.g., ERP, MES, etc.), and other such industrial assets. These industrial assets are connected to a factory network 116 (e.g., a public industrial protocol network, Ethernet / IP network, etc.), which facilitates data exchange between industrial equipment on the factory floor. The factory network 116 can be a wired network or a wireless network.

[0123] When control item 306 needs to be deployed during a recovery operation, it can be delegated to the plant facility via a secure connection between smart gateway device 1202 and the cloud platform where the storage system 202 resides. Asset recovery component 214 can convert archived control item 306 into one or more appropriate executable files (control program file 1302, visualization application 1304, device configuration file 1308, system configuration file, etc.) and deploy these files to appropriate devices in the plant facility to facilitate the deployment or recovery of the control item.

[0124] This backup and recovery architecture can also be used to load system configurations from one facility and deploy them to another, or to load configurations from an OEM and deploy them to customer sites. As part of the deployment process, the asset recovery component 214 can first poll the target equipment on the factory floor to verify which equipment can support and execute the control project files being deployed.

[0125] By providing a public storage and analytics platform on which multiple customers can load and evaluate their control solutions, the IDH Repository System 202 can accelerate modern automation development by creating an open ecosystem for engineers to share and reuse code from private and public repositories, allowing them to easily manage and collaborate with their own content and that of others they trust to accelerate core control development.

[0126] In addition to the features discussed above, implementations of the IDH repository system 202 can support a variety of digital engineering tools that reduce the cost and complexity of acquiring, configuring, and maintaining digital twins of a customer's OT environment, thereby allowing simulations to be performed through a scalable, on-demand cloud workspace. In some implementations, asset models 312 stored on the customer repository 324 can be used to construct digital twins of enterprise automation systems or large portions of industrial environments. As described above, these asset models 312 are digital representations of industrial equipment or assets used in a plant facility. The asset model 312 corresponding to a given industrial asset can define the functional specifications of that asset, including, for example, defining the functions the asset is to perform, available I / O, memory or processing power, supported functions, operational constraints, etc.; the physical dimensions of the asset; the visual representation of the asset; physical, kinematic, or electromechanical characteristics that determine how the virtualized asset behaves in the simulated environment (including friction, inertia, degree of movement, etc.); the asset's 3D animation attributes, or other such asset information. Because the behavior of some industrial assets varies with user-defined configuration parameters or control routines, asset models 312 for some types of industrial assets can also record dedicated equipment configuration parameters or control routines defined by the system designer for the physical assets.

[0127] At least some of the asset models 312 stored in the customer's storehouse can be created for a given customer based on the vendor-specific device profiles 316 that are available on one or more vendor storeshouses 326. Figure 14 This is a diagram illustrating the creation and storage of asset models 312 based on equipment profiles 316 submitted by equipment suppliers to the storage system 202. As described above, project analysis component 210 can identify industrial equipment, assets, or apparatus used or involved in a customer's control project 306. This can include equipment or assets on which parts of the control project 306 will be executed (e.g., industrial controllers, motor drives, safety relays, etc.) and assets inferred to be connected to or otherwise related to these key control assets. For example, project analysis component 210 can examine analysis of configuration and programming files for an industrial controller to determine not only how the controller itself is configured and programmed, but also to identify equipment or assets connected to the controller's I / O (e.g., based on analysis of I / O module configuration data included as part of the controller's configuration and programming files or data tags defined in a tag database of the files). In another example, some industrial assets constituting the controlled automation system can also be inferred based on analysis of HMI applications included in the control project 306 (e.g., based on data tags defined in the HMI applications or definitions of graphical representations of industrial assets). In this way, the analysis of control item 306 can yield information on a larger automation system topology beyond the main monitoring and control equipment. Examples of industrial assets that can be identified through the analysis of control item 306 may include, but are not limited to, industrial controllers, input and output devices connected to the industrial controller's I / O, sensors, telemetry devices, machines, control panels, HMI terminals, safety relays or other safety devices, industrial robots, or other such industrial assets.

[0128] Utilizing this knowledge of the industrial assets that make up the automation system, project analysis component 210 can determine for each discovered industrial asset whether a digital equipment profile 316 is available for that asset in the appropriate supplier repository 326 corresponding to the asset's provider or seller. Product suppliers can submit equipment profiles 316 to the repository system 202 to support their products, and system 202 makes these equipment profiles 316 available to the asset owner for use in digital engineering, simulation, and testing. Project analysis component 210 can retrieve the equipment profiles 316 corresponding to the industrial assets used or involved in the control project 306 and store the profiles 316 as asset models 312 in customer repository 324.

[0129] Since some equipment profiles 316 can represent a generic digital representation of their corresponding physical assets—that is, a representation that does not consider the specific configuration parameters or programming applied to the physical assets by the asset owner—the project analysis component 210 can convert these generic equipment profiles 316 into a custom asset model 312 representing the client's unique configuration assets. This customization can be based on configuration parameters or programming obtained from the control project 306 itself or from project telemetry data 602 generated for the project 306.

[0130] The resulting asset model 312 can be used as the basis for a digital twin 810 of an automation system, which can be used to simulate and test control project 306, as described above. Figure 8 The subject of discussion. Figure 15 This diagram illustrates the generation of a digital twin 810 of an automated system or industrial environment based on control project 306 and the corresponding asset model 312. In some embodiments, simulation component 218 may aggregate asset model 312 into digital twin 810 based on learned or defined relationships between corresponding physical assets represented by asset model 312. The scope of digital twin 810 may encompass a single automated system, a production line, an area within an industrial facility including multiple automated systems, or an entire industrial facility including multiple production areas and automated systems. In some cases, digital twin 810 may be automatically partially generated automatically by simulation component 218 based on control project 306 and asset model 312, and digital design tools provided by simulation component 218 may allow users to modify or extend digital twin 810 to improve the fidelity of the digital twin as needed. In some embodiments, a dedicated digital twin definition language may be used to define the digital twin 810 for control simulation.

[0131] As described above Figure 8 As described, the digital twin 810 can be used to model interactions with a controller simulator to predict how the control programming defined by control project 306 will interact with the virtual factory. The digital twin 810 can also be improved as the design project progresses through the commissioning, optimization, migration, and operator training phases.

[0132] Figure 16 This diagram illustrates a simulated scenario of a virtualized factory 1602 comprising multiple digital twins 810. The virtualized factory 1602 can represent a single automated system with multiple components, each represented by a digital twin 810, or it can represent a larger factory environment in which different automated systems or industrial assets within the factory are represented by corresponding digital twins 810. Data exchange between the virtualized factory 1602 (simulated by simulation component 218) and the simulated control item 306 is combined with the above. Figure 8The descriptions are similar. Generally, simulation component 218 supports the creation of a virtualized factory 1602 using a digital twin 810, which has different levels of fidelity or complexity depending on the simulation requirements, wherein the fidelity of the digital twin 810 depends on the desired result or the required level of accuracy. For example, a higher-fidelity digital twin 810 (e.g., digital twin 810a) can be used for an automated system or industrial asset that is the focus of the simulation, while a lower-fidelity digital twin (e.g., digital twin 810b) can be used to model an automated system or industrial environment that is external to the focus system but must be modeled in order to accurately simulate the operation of the main system. In an example of such a configuration, a higher-fidelity digital twin 810 can be used to model a processing station for which it is designed to control an item 306, while a lower-fidelity digital twin 810 can be used to model a system upstream of the processing station that supplies materials to the processing station. The aggregated virtual factory 1602 can produce accurate simulations of processing stations (taking material feed rates into account), while reducing the modeling effort that would otherwise be required to model the entire system compared to using a high-fidelity digital twin 810. In another example, a higher-fidelity digital twin 810 can also be used to model actual automated systems, while a lower-fidelity digital twin 810 can be used for simpler functions, such as state tracking analysis.

[0133] After debugging the control project (as described above) Figure 13 The fidelity of the virtual factory 1602 can be improved over time based on actual performance data. Figure 17This diagram illustrates the use of field data 1704 generated by the automation system equipment and collected by the IDH storage system 202 to refine the virtual factory 1602. In this example, the storage system's device interface component 220 interfaces with the industrial system via a smart gateway device 1202, which resides on a public network along with the industrial equipment constituting the automation system. During automation system operation, the smart gateway device 1202 collects status and operational data from the equipment constituting the automation system, including data read from data tags on one or more industrial controllers. In some embodiments, the smart gateway device 1202 may contextualize the collected data before delivering it to the storage system 202, and deliver the processed data as contextualized data 1704 to the storage system 202. This contextualization may include timestamping the data and normalizing or otherwise formatting the collected data for analysis by the simulation component 218 relative to the virtual factory 1602. The simulation component 218 can compare the simulated expected behavior of the virtual factory 1602 with the actual behavior determined from the contextualized data 1704, and update the virtual factory 1602 based on the actual monitored behavior of the automated system—including modifying any digital twin 810 as needed—to increase the fidelity of the virtual factory 1602.

[0134] The IDH storage system 202 can also support a multi-user simulation environment in which multiple users can interact with the virtual factory 1602 during the design phase before deploying control project 306 or after project 306 has been commissioned. Figure 18 This diagram illustrates multi-user interaction with the virtualization factory 1602. In this example, multiple users are able to interface with the storage system 202 via user interface component 204 using a wearable device 1802 that presents AR / VR demonstrations to the wearer of device 1802. In some embodiments, user interface component 204 may be configured to verify the wearable device 1802's authorization to access the IDH storage system 202—and in particular, access to the virtualization factory 1602 or other information stored in the wearer's customer storage 324—before allowing the delivery of VR demonstrations to the wearable device 1802. User interface component 204 may authenticate the wearable device 1802 or its owner by using password authentication, biometric identification (e.g., retinal scan information collected by the wearable device 1802 from the user and submitted to user interface component 204), cross-referencing the wearable device 1802's identifier with a set of known authorized devices authorized to access customer storage 324, or other such authentication techniques. Figure 18The demonstration shows access to a client repository and viewing of a virtualized factory 1602 using a wearable AR / VR instrument 1802, but other types of client devices (including handheld devices) can also be used to access the virtual simulation.

[0135] User interface component 204 has an associated virtual presentation component configured to generate virtual reality demonstration data based on the simulation of virtualized factory 1602 under the control of simulation control project 306, for delivery to and execution on authorized wearable device 1802. Upon receipt and execution by wearable device 1802, the demonstration data presents an interactive three-dimensional (3D) virtual reality demonstration of virtualized factory 1602 on the wearable device's display. Typically, virtualized factory 1602—including one or more digital twins 810 as discussed above—can define a visual representation of the physical layout of an industrial facility or area represented by virtualized factory 1602. For example, virtualized factory 1602 can define graphical representations of industrial assets located within the factory—including machines, conveyors, control cabinets, and / or industrial equipment—and the physical relationships between these industrial assets. For each industrial asset, the virtual factory 1602 (e.g., a digital twin 810 representing the industrial asset) can define the asset's physical dimensions and color, as well as any animations supported by the graphical representation (e.g., color-changing animations, positional animations reflecting the asset's movement, etc.). The virtual factory 1602 also defines the physical relationships between industrial assets, including the relative positions and orientations of assets in the factory floor, conduits or pipes extending between assets, and other physical definitions.

[0136] Using wearable device 1802, a user can submit interaction data representing virtual interactions between the user and virtual factory 1602 to user interface component 204. These virtual interactions may include, for example, changing the user's viewing angle within the virtual factory, virtually selecting or interacting with industrial assets or equipment within the virtual factory, or other such interactions. Based on this interaction data, user interface component 204 can update the wearer's viewpoint of virtual factory 1602 to reflect the user's current virtual viewing angle, to present simulated behavior of industrial assets within the user's current virtual field of view, and to present simulated data (e.g., status or operational statistics) related to the assets currently observed within the wearer's field of view.

[0137] This architecture allows multiple users to inspect various aspects of controlling project 306 while it operates within a virtual version of the physical environment in which project 306 will run. This inspection can be performed before debugging control project 306. In the example scenario, control code defined as part of control project 306 can be inspected and approved by designated personnel within the project approval chain. This virtual code inspection process can be linked to internal code verification requirements, where multiple designated inspectors must inspect and sign off on new control code before it is deployed in the field. This virtual code inspection implementation can be driven by user-defined inspection policies defined and stored on the customer repository 324.

[0138] In some implementations, IDH repository system 202 can prevent the deployment of control item 306 until all designated inspectors defined by the code inspection policy have received all appropriate approvals. For example, an inspection policy defined for a given industrial enterprise could stipulate that the plant's safety manager and plant chief engineer must approve the new control code before it is put into use on the plant floor. Therefore, simulation component 218 and simulation component 216 can simulate the operation of industrial assets (such as those defined by virtualized plant 1602) under the control of this new control code, as described above. Figure 8 and Figure 18 As described, user interface component 204 allows inspectors to observe the simulation's operation individually or simultaneously. If satisfied with the operation of the new control code, each inspector can submit approval for the new code to system 202 via user interface component 204 (e.g., in the form of a digital signature, as described above). Figure 10 (as described), and these approvals, associated with control item 306, are stored in the customer storage 324 allocated to the plant. IDH storage system 202 can prevent commissioning of control item 306 (e.g., in conjunction with the above). Figure 13 (The described debugging process) continues until all required approvals defined by the internal code inspection strategy have been received.

[0139] In another example, a multi-user simulation environment can be used to perform a virtual walkthrough of a proposed automation system design (e.g., a mechanical system and associated control systems) being proposed by an OEM for a customer. In this scenario, the OEM can use design tools supported by the repository system 202 to generate a virtual factory 1602 representing the proposed automation system and corresponding control items 306 for monitoring and controlling the automation system. Before construction of the automation system begins, personnel from both the OEM and the factory building the system can simultaneously interface with the virtual factory 1602 and observe the simulated operation of the proposed automation system within the virtual environment, thus providing the customer with the opportunity to provide feedback or propose design changes before construction of the automation system begins.

[0140] Multi-user simulation can also be used in conjunction with operator training. For example, trainees can interface with a virtualized environment alongside a trainer, and different operator training scenarios can be simulated through a repository system 202 within the virtualized factory environment. In such an implementation, various training scenarios (e.g., alarms or downtime requiring operator intervention) can be defined in a customer repository 324, and the simulation component 218 can be configured to virtually formulate these scenarios within a simulated VR environment. Simultaneous multi-user simulation allows trainers to provide guidance and feedback within the virtualized environment.

[0141] Virtual environments can also be used for virtual verification of maintenance or upgrade actions. For example, maintainers can submit proposed changes to controller code (e.g., as combined with the above). Figure 11 The proposed changes are discussed as a new project version, and others can access the repository system 202 to verify them before allowing the modified code to be delegated to the industrial controller for execution. In some implementations, the simulation component 218 can also be configured to perform predictive (or “hypothetical”) analysis on the modified code relative to the virtualization plant 1602 to predict operational changes in the automation system that will result from debugging the modified code, and to generate recommendations for further code modifications based on the results of these predictions. These recommendations can be generated based on similar criteria used to evaluate new control projects (e.g., recommendation 702), including deviations from defined project criteria, incorrect control code formatting, the impact of code modifications on the equipment’s lifecycle, identification of unused equipment features that can improve or simplify the control modifications being implemented, or other such criteria.

[0142] Some implementations of the simulation component 218 can also be configured to test new or modified control items 306 by simulating various stress test scenarios for the item. This can include simulating scenarios such as component failure (e.g., predicting the system's response to valve failure), incorrect or inadequate operator workflows (e.g., predicting the consequences if the operator reacts too slowly to critical events), or other such scenarios. Based on inferences about the system's response to such stress test scenarios, the simulation component 218 can generate recommendations for modifying control items 306 in a way that better anticipates failure scenarios and mitigates undesirable outcomes in response to such scenarios.

[0143] After the project modifications are deployed, simulation component 218 can perform subsequent simulations focused on the modifications to the project, such that the simulation compares the actual machine response with the previously anticipated response resulting from the code change. User interface component 204 can highlight any such deviations in the VR or AR demonstration delivered to wearable device 1802. If the project or code modification only affects a limited portion of the factory (e.g., a single machine), simulation component 218 can perform only a partial simulation of the virtualized factory 1602 in such scenarios, thus focusing the simulation only on the affected portion of the factory and any necessary context related to the affected portion. Simulation component 218 can determine the scope of this subsequent simulation based on the determination of the scope of the control project modifications.

[0144] In some implementations, the IDH repository system 202 may also use the virtualization factory 1602 as a platform for remote interaction with the physical system. Figure 19 This diagram illustrates the architecture of an industrial asset 1902 operating within a factory environment, which can be remotely viewed and controlled via an IDH storage system 202. After deploying control item 306, device interface component 220 can acquire contextualized data 1704 generated by the industrial asset 1902 during operation. This contextualized data 1704 can represent operational or status data of the industrial asset 1902 over time and can be collected, contextualized, and streamed to the storage system 202 by the smart gateway device 1202, as described above. Figure 17As described. Based on the received contextualized data and the virtualized plant 1602 (including one or more digital twins 810), the user interface component 204 can deliver substantially real-time visualizations 1910 of the operation of industrial assets to authorized client devices 1904 authorized to access plant data. These visualizations may include, for example, VR presentations delivered to wearable devices and comprising animated 3D virtual environments defined by the virtualized plant 1602 and animated based on on-site contextualized data 1704. The animated behavior of various industrial assets 1902 synchronized with their respective subsets of contextualized data 1704 can be defined by the digital twins 810 representing these assets and included in the virtualized plant 1602. The visualizations 1910 may also overlay selected subsets of contextualized data 1704 onto or near relevant asset representations (e.g., values ​​representing speed, flow, pressure, product throughput, etc.) and calculated or predicted performance metrics generated by the simulation component 218 within these VR environments. In some implementations, as an alternative to alphanumeric or icon information overlay, Visualization 1910 can use a chatbot to provide verbal audio feedback during the simulation.

[0145] If a user is located within a factory facility and is viewing industrial assets via a wearable device used as client device 1904, visualization 1910 may include an AR presentation that overlays relevant status information and performance statistics within the user's field of view, enabling the information to be located on or near the relevant industrial assets within the field of view. As an alternative to VR or AR presentations, visualization 1910 may include a two-dimensional presentation displayed on a display of another type of client device 1904.

[0146] In addition to allowing remote viewing of the operation or performance statistics of industrial asset 1902, the storage system 202 can also allow the controlled issuance of remote commands 1912 from client device 1904 to the automation system. Remote commands 1912 that can be initiated from client device 1904 via the storage system 202 may include, but are not limited to: instructions to modify control setpoints, start or stop machines, change the current operating mode of machines, or other such commands. In the case of VR-based visualization, these remote commands 1912 can be issued via interaction between the user and a virtualized representation of the relevant industrial asset or its corresponding control panel (e.g., interaction with a virtual control panel I / O device or HMI). In response to receiving such a remote command 1912, the simulation component 218 can allow or deny the issuance of control commands 1908 to the relevant plant shop equipment based on a determination of whether the received command is permitted to be issued remotely in a given current situation. When deciding whether to issue the requested control command 1908, the storage system 202 may consider factors such as, for example, the authorization credentials of the person issuing the remote command 1912, the determination of whether the target machine is in a state where it is permissible to securely issue the control command 1908, and the definition of which types of control commands 1908 are permitted to be issued remotely (which may be stored in the customer storage 324 as part of factory standard 314 or other such standards).

[0147] Furthermore, for certain types of remote interactions (e.g., the issuance of remote command 1912 or remote deployment of control project changes), security considerations may require the repository system 202 to verify the location of the person attempting to perform the remote interaction via the cloud platform within the plant, ensuring clear visual visibility of the affected industrial asset 1902 before initiating the requested operation. For example, if a user is attempting to upgrade firmware on industrial equipment, implement changes to control programming, or issue a certain type of remote command 1912 via the repository system 202, the device interface may first associate the user's geographic location information with known location information about the affected industrial asset and refuse to issue the requested interaction from the user's current location if it is not within a defined area relative to the asset, which is known to allow clear visibility of the asset. The definition of which types of remote interactions require clear visual visibility of the asset can be stored as part of plant standard 314 and may include remote operations that pose a certain degree of risk of causing machine damage or harm when implemented, thus requiring direct visual monitoring by the user during the interaction.

[0148] In some implementations, the aforementioned IDH repository system 202, along with its associated digital design tools and repositories, can operate in conjunction with a cloud-based Industrial Information Center (IIH) system, serving as a multi-partner ecosystem for exchanging information and services among equipment owners, equipment suppliers, and service providers. The IIH system is driven by a digital representation of industrial assets on a secure cloud platform and can leverage asset models 312 and other tools provided by the IDH repository system 202. While industrial asset digitization holds considerable potential value, maximizing the benefits from digital models will require the participation of multiple partners, including industrial customers, OEMs, equipment suppliers, system integrators, and others.

[0149] Several challenges may deter customers or service providers from adopting large-scale digital deployments. For example, existing industrial assets require self-organizing development efforts to organize and collect data. Furthermore, contextualizing data from multiple assets and data sources into actionable data can be difficult and expensive. Security and data ownership issues can also limit collaboration between OEMs and their customers, especially given that industrial customers typically require complete solutions incorporating content from multiple OEMs. Additionally, most OEMs and systems integrators have limited domain expertise in creating digital content, and equipment owners similarly lack the expertise to maintain portions of solutions based on this digital content. Operational technology (OT) use cases need to be addressed at the edge and cloud architectures, with flexibility around different connectivity levels. There is also a strong belief in the separation of OT and IT technologies, including a perceived need to physically decouple OT from IT networks and the cloud.

[0150] To address these and other challenges, the IIH system described in this paper—along with the tools and repositories supported by IDH—can serve as a single industrial ecosystem platform where multiple participants can deliver repeatable and standardized services relevant to their core competencies. At the heart of the IIH system is the development of an ecosystem that creates and delivers value for users, including industrial enterprises, OEMs, system integrators, suppliers, and others, by aggregating digital content and domain expertise. The IIH system acts as a trusted information broker between the ecosystem and the OT environment of the plant facility, providing a platform for connecting assets, contextualizing asset data, and providing secure access to the ecosystem. Furthermore, the IIH system provides tools and support for OEMs and other subject matter experts, enabling them to leverage their digital assets within the ecosystem. The IIH system can reduce the cost and risk of digital modeling of industrial assets, allowing suppliers, OEMs, and end users to collaborate to improve operational efficiency and asset performance.

[0151] Figure 20This is a block diagram of an example Industrial Information Center (IIH) system 2002 according to one or more embodiments of this disclosure. Aspects of the systems, apparatus, or processes described in this disclosure can constitute machine-executable components implemented within one or more machines, for example, implemented on one or more computer-readable media (or media) associated with one or more machines. Such components, when executed by one or more machines (e.g., one or more computers, one or more computing devices, one or more automation devices, one or more virtual machines, etc.), can cause one or more machines to perform the described operations.

[0152] IIH system 2002 may include user interface component 2004, modeling component 2006, simulation component 2008, device interface component 2010, analysis component 2012, access management component 2014, one or more processors 2020, and memory 2022. In various embodiments, one or more of the user interface component 2004, modeling component 2006, simulation component 2008, device interface component 2010, analysis component 2012, access management component 2014, one or more processors 2020, and memory 2022 may be electrically and / or communicatively coupled to each other to perform one or more functions of IIH system 2002. In some embodiments, components 2004, 2006, 2008, 2010, 2012, and 2014 may include software instructions stored in memory 2022 and executed by processor 2020. IIH system 2002 may also be associated with… Figure 20 It may interact with other hardware and / or software components not described herein. For example, the processor 2020 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0153] Similar to the IDH storage system 202, the IIH system 2002 can be implemented on a cloud platform as a collection of cloud-based services to facilitate access for a wide variety of users with business or technical relationships, including industrial equipment owners (e.g., industrial enterprise entities or plant owners), equipment suppliers, original equipment manufacturers (OEMs), system integrators, or other such user entities. The cloud platform on which the system 2002 executes can be any infrastructure that allows cloud-capable devices to access and utilize shared computing services. The cloud platform can be a public cloud accessible via the Internet by devices with Internet connectivity and appropriate authorization to use IIH services. In some scenarios, the cloud platform can be provided by a cloud provider as a Platform as a Service (PaaS), and the IIH system 2002 can reside on and execute on the cloud platform as a cloud-based service. In some such configurations, the owner of the IIH system 2002 can offer access to the cloud platform and associated IIH services to customers as a subscription service. Alternatively, the cloud platform can be a private cloud operated internally by an industrial enterprise (owner of the plant facility). An example private cloud platform may include a collection of servers that host the IIH system 2002 and reside on a firewall-protected corporate network.

[0154] User interface component 2004 can be configured to receive user input and present output to the user in any suitable format (e.g., visual, audio, tactile, etc.). In some embodiments, user interface component 2004 can be configured to communicatively interface with client devices (e.g., laptops, tablets, smartphones, etc.), which are communicatively connected to IIH system 2002 (e.g., via hardwired or wireless connection). User interface component 2004 can then provide an IIH interface environment for the client devices, through which system 2002 receives user input data and presents output data. In other embodiments, user interface component 2004 can be configured to generate appropriate interface screens and provide them to client devices (e.g., program development screens, project submission screens, analysis results screens, etc.), and exchange data through these interface screens.

[0155] Modeling component 2006 can be configured to generate digital asset models or equipment models based on modeling input submitted by the user via a user interface, or to aggregate multiple digital asset models into a larger digital twin or virtualized factory representing the end user's industrial system or environment. Simulation component 2008 can be configured to simulate the operation of a virtualized model of an industrial automation system based on the asset model, digital twin, or virtualized factory. Simulation component 2008 can function similarly to simulation component 218 of the IDH storage system 202.

[0156] The device interface component 2010 can be configured to interface directly or via the smart gateway device 1202 with industrial equipment or assets on the factory floor, and receive real-time operational and status data from these assets for analysis, simulation, or visualization purposes. As part of the process of securely supplying asset models, the device interface component 2010 can also retrieve device identification information or credential information from the smart gateway device 1202. The analysis component 2012 can be configured to perform various types of analysis on the collected industrial asset data, based on the corresponding asset model or digital twin. The access management component 2014 can be configured to securely connect client devices to industrial assets within the factory facility from remote locations without opening inbound ports on the factory's corporate firewall.

[0157] One or more processors 2020 may execute one or more of the functions of the systems and / or methods disclosed herein. Memory 2022 may be a computer-readable storage medium that stores computer-executable instructions and / or information for performing the functions of the systems and / or methods disclosed herein.

[0158] Figure 21 This is a block diagram of an example smart gateway device 1202 according to one or more embodiments of the present disclosure. The smart gateway device 1202 may include a device interface component 2104, an IIH interface component 2106, a gateway analysis component 2108, a user interface component 2110, an analysis scaling component 2112, one or more processors 2120, and a memory 2122. In various embodiments, one or more of the device interface component 2104, IIH interface component 2106, gateway analysis component 2108, user interface component 2110, analysis scaling component 2112, one or more processors 2120, and memory 2122 may be electrically and / or communicatively coupled to each other to perform one or more functions of the smart gateway device 1202. In some embodiments, components 2104, 2106, 2108, 2110, and 2112 may include software instructions stored on the memory 2122 and executed by the processor 2120. The smart gateway device 1202 may also be associated with… Figure 21 It may interact with other hardware and / or software components not depicted herein. For example, processor 2120 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0159] Device interface component 2104 can be configured to communicate and exchange data with industrial equipment and assets within the factory facility. IIH interface component 2106 can be configured to communicate with IIH system 2002 via a cloud platform. Gateway analytics component 2108 can be configured to apply edge-level analytics to data collected from industrial equipment and assets. In some scenarios, these analyses may be based on asset model 312 or machine learning model stored on smart gateway device 1202. User interface component 2110 can be configured to send data to and receive data from client devices via one or more public or private networks. Analytics scaling component 2112 can be configured to scale selected analytics processing to IIH system 2002 on the cloud platform and coordinate distributed analytics between IIH system 2002 and smart gateway device 1202.

[0160] One or more processors 2120 may execute one or more of the functions of the systems and / or methods disclosed herein. Memory 2122 may be a computer-readable storage medium that stores computer-executable instructions and / or information for performing the functions of the systems and / or methods disclosed herein.

[0161] Figure 22 This is a general conceptual diagram of the ecosystem facilitated by IIH System 2002. Generally, IIH System 2002 supports cloud-based environments and associated tools that allow suppliers, OEMs, system integrators, or other industrial service providers to create and deploy digital services for use by owners of industrial assets 2202 at factory facilities. IIH System 2002 can provide a variety of capabilities, including standardized, easy-to-connect solutions for moving information from factory assets 2202 to the cloud platform; common data models (asset models, data models, digital twins, asset machine learning models, etc.) for building and maintaining context from multiple sources and reducing time to value realization; support for information-ready assets from OEMs through pre-built digital twins, machine learning models, analytics, and mixed reality experiences; a secure architecture that allows end users to securely access their OT assets 2202 and information and leverage the ecosystem's domain expertise and content; and a technology platform that enables ecosystem partners to deliver value and monetize services, allowing their customers to easily consume that value.

[0162] Every ecosystem partner can benefit from key outcomes by participating in the IIH ecosystem. For example, owners of industrial assets 2202 will see improved operational efficiency and asset performance through data and insights, as well as higher ROI on equipment and faster rollouts through standardized deployments. OEMs will see new revenue streams throughout the lifecycle of their assets through remote monitoring, predictive maintenance, performance contracts, and Machine-as-a-Service (MAS) products. System integrators and independent software vendors (ISVs) will see rapid application development and lower integration costs through system simulation and validation.

[0163] To support a wide range of diverse stakeholders, the IIH System 2002 leverages trusted information connectivity sources to provide connectivity from core assets to the cloud, data governance, and access management between end users and the ecosystem, including a secure and proven architecture. These services can cover a broad range of connectivity use cases, from fully on-premises and disconnected to intermittent and always-connected. Addressing disconnected or intermittently connected use cases while demonstrating the value of connectivity can accelerate digital maturity and remove barriers to cloud adoption.

[0164] The cloud infrastructure built upon IIH System 2002 provides components that enable the ecosystem to rapidly develop standardized and repeatable solutions, including local connectors, general data models for contextualization, data repositories or data lakes, digital twin profile builders, and pre-built machine learning reference solutions for key use cases. These components enable the ecosystem to deliver predictive maintenance, remote monitoring, expert assistance, and digital workforce productivity (including AR and VR).

[0165] The IIH System 2002 can also provide scalable computing products from the edge to the cloud, which operate in combination with hardware products that include simple gateways, edge computing (e.g., intelligent gateway device 1202), data centers, and cloud computing capabilities that provide optimal near machine, on-premises, and cloud computing capabilities.

[0166] The IIH platform allows asset models 312 to be created, registered, and bound to assets by customers, OEMs, or other participants in the ecosystem. Figure 23This diagram illustrates the creation and registration of an asset model 312 by an OEM for a machine 2304 being built for delivery to a customer. The asset model 312 can be built using the data modeling services of the IIH system and can be deployed from the cloud to the edge or to factory floor equipment (e.g., smart gateway device 1202 or industrial controller). To this end, the IIH system's modeling component 2006 can generate and provide a model development interface, including modeling tools 2308, to the client device 2302 associated with the OEM (via user interface component 2004), and designers can submit modeling input 2310 by interacting with these tools 2308. These modeling tools 2308 allow OEM designers to define one or more digital asset models 312 to associate with the machine 2304 being built, which the purchaser of the machine 2304 can use for cloud-level or edge-level analytics (e.g., performance evaluation or predictive analytics), virtual simulation of the machine 2304, VR / AR visualization, or other such digital engineering purposes.

[0167] Asset model 312 can model various aspects of its corresponding machine 2304. For example, asset model 312 can define the devices and components that constitute machine 2304 (e.g., industrial controllers, drives, motors, transmitters, etc.), including the functional specifications and configuration parameters of each device. In some cases, asset model 312 can define these machine devices and components hierarchically, or otherwise define the functional relationships between devices. Asset model 312 can also define the visual characteristics and 3D animation attributes of machine 2304, which can be used to visualize the machine in simulations or VR demonstrations. For asset model 312 capable of supporting simulations of machine 2304, asset model 312 can also define physical, kinematic, or electromechanical characteristics (e.g., friction, inertia, degree of movement, etc.) that determine how machine 2304 behaves in the simulation environment. Asset model 312 can also include an analysis model designed to process runtime data generated by machine 2304 to produce insights or predictions about machine operation.

[0168] Some aspects of the asset model 312 can be constructed based on an object-based architecture that uses the automation object 504 as a building block. Figure 24This is a diagram illustrating an example asset model 312 incorporating automation objects 504. In this example, various automation objects 504 representing similar industrial equipment, components, or assets (e.g., processes, tanks, valves, pumps, etc.) of machine 2304 have been incorporated into asset model 312. Asset model 312 also defines the hierarchical relationships between these automation objects 504. According to the example relationships, a process automation object representing a batch process can be defined as a parent object of multiple child objects representing equipment and apparatus for executing the process, such as tanks, pumps, and valves. Each automation object 504 has object characteristics or attributes specific to its corresponding industrial asset (e.g., those incorporating the above). Figure 5 Those discussed include analytical models, performance evaluation models, predictive models, visualization attributes, or other such attributes. At least some of the automation objects 504 referenced in asset model 312 may correspond to automation objects 504 defined in one or more industrial control programs used to monitor and control machine 2304.

[0169] At least some of the attributes of each automation object 504 are default attributes based on coded industry expertise associated with the asset represented by object 504 or OEM expertise associated with machine 2304 as a whole. Additional attributes can be modified or added as needed (via design input 512) to customize object 504 for the specific machine 2304 being built. This can include, for example, associating custom control codes, visualizations, AR / VR demonstrations, or help files associated with the selected automation object 504. In this way, automation objects 504 can be created and extended for applications designed to add value to machine operation. Using automation objects 504 to create asset models 312 allows for the creation of shared asset models 312 using common data nomenclature, thereby facilitating easy integration of different vendors and protocols.

[0170] In some implementations, modeling component 2006 may allow designers to select predefined standardized models 2306 and incorporate them into asset model 312. These standardized models 2306 may be stored in knowledge base 328 and may encode any asset attributes or analytical models discussed above for various types of industrial assets. Model attributes defined in standardized models 2306 may be based on industry expertise regarding their corresponding industrial assets. These may include, for example, analytical algorithms designed to calculate and evaluate key performance indicators (KPIs) of the corresponding industrial assets, predictive algorithms designed to predict future operating results or anomalies of the assets, or other such asset-specific models or attributes.

[0171] Asset model 312 can also define which available data items of the corresponding assets (e.g., controller data tag values, equipment configuration parameters, etc.) are related to the data collection and analysis objectives and the functional or mathematical relationships (e.g., correlation and causation) between these selected data items. Some asset models 312 can also combine the machine's business view model (e.g., serial number, financial data, template data, etc.) with the machine's automated representation to produce a composite model 312.

[0172] Once the OEM has developed an asset model 312 for the machine 2304 under construction, model 312 can be registered with the IIH system 2002 and stored in the vendor repository 326 designated for the OEM. The OEM can also register the smart gateway device 1202 with the IIH system 2002. The smart gateway device 1202 stores digital credentials that allow access to and use of the asset model 312. The machine 2304 can then be shipped to the customer facility for installation along with the smart gateway device 1202.

[0173] Figure 25 This diagram illustrates the commissioning of machine 2304 at a customer facility and the registration of the machine to the IIH system 2002. Once installed on the customer's plant network 116, personnel at the plant facility can choose to utilize information services available to machine 2304 and made possible through asset model 312. Therefore, the IIH interface component 2106 of the smart gateway device 1202 can communicatively connect to the cloud platform and send credentials 2502 stored on the smart gateway device 1202 to the IIH system 2002. After verifying the credentials 2502, the device interface component 2010 of the IIH system 2002 registers the smart gateway device 1202 with the system 2002 and provides the asset model 312 to the customer. The manner in which the asset model 312 is provided may depend on the intended destination of the model 312. For example, the asset model 312 may be designed to be implemented internally on the smart gateway device 1202. Therefore, the IIH system 2002 can provide the asset model 312 to the gateway device 1202, such as... Figure 26 As shown. Alternatively, asset model 312 can be designed to execute on a cloud platform. In such a scenario, in response to verifying digital credentials 2502, IIH system 2002 can provide asset model 312 to a customer store 324 allocated to a customer for cloud-based execution, such as... Figure 26 As shown. This method of providing asset model 312 can also involve integrating asset model 312 of machine 2304 into an existing virtualized factory 1602 representing a customer facility. In this respect, asset model 312 can be used as a digital twin of machine 2304, which can be aggregated with other digital twins 810 or other asset models to produce virtualized factory 1602.

[0174] By providing digital asset modeling tools for creating asset models 312 and a platform for securely distributing these models, the IIH System 2002 enables OEMs or other equipment providers to build digital representations of their assets or machine types and add these representations to a cloud-based library. In this way, OEMs can progressively add digital content that can be used to support new or existing installations of their equipment. The IIH System 2002 can manage this digital library for multiple OEMs, suppliers, system integrators, or service providers, organizing models according to industrial verticals (e.g., automotive, food and pharmaceuticals, oil and gas, mining, etc.), industrial applications, equipment classifications or types, or other categories.

[0175] Although Figures 23 to 26 The illustration shows a scenario where asset model 312 is created by an OEM and registered with the IIH system 2002 for use by the purchasers of its equipment; however, in some implementations, end users may also obtain and utilize asset model 312 in other ways. Figure 27 This diagram illustrates the selection and integration of asset model 312 based on machine identity. In this example, machine 2708 includes an optical code (e.g., a two-dimensional barcode, such as a QR code) representing a unique machine identifier that can be scanned by a user's client device 2702. The client device 2702 can then interface with the IIH system 2002 (via user interface component 2004) and submit the scanned machine identifier 2704 and appropriate credentials 2706 identifying the user of the client device 2702 as an authorized person permitted to modify the virtual factory 1602. In response to receiving the machine identifier 2704 and credentials 2706, the modeling component 2006 can retrieve the asset model 312 corresponding to the machine identifier 2704 from an appropriate library (e.g., from a vendor repository 326 corresponding to the machine's manufacturer) and integrate the retrieved model 312 into the customer's larger virtual factory 1602.

[0176] In some implementations, the modeling component 2006 may also prompt the user with additional information about the industrial assets they have collected to fill gaps in the topology of the virtualized factory 1602. For example, the modeling component 2006 may (via the user interface component 2004) send requests for information about where machine 2304 is located within the factory facility or for information about what other undocumented equipment and assets are connected to machine 2304. The modeling component 2006 may incorporate this information into the client's virtualized factory 1602 to produce a more accurate digital representation of their factory environment.

[0177] Figure 28This diagram illustrates the architecture of the IIH system 2002, which provides industrial information services to a collection of industrial assets 2802 within a factory environment. Connectivity services implemented by the device interface component 2010 can be used to connect machines or other industrial assets to the cloud-based IIH system 2002. These connectivity services can provide an enterprise view of multiple automation systems operating within the industrial enterprise, aggregating contextualized data 2806 from multiple smart gateway devices 1202, and operating on this collected data 2806 from the perspective of OEMs or customers. Figure 28 In the depicted example, three smart gateway devices 1202a to 1202c operate on a factory floor, with each gateway device 1202 serving as an edge device to interface a set of industrial assets 2802 with the IIH system 2002. A modeling component 2006 can map all three gateway devices 1202 to a single virtual asset represented by a virtualized factory 1602 on a cloud platform, and a user interface component 2004 can create and present a data presentation 2810 on the end-user's client device based on the virtualized factory 1602 and contextualized data 2806. This connectivity service can integrate smart gateway devices 1202 from different vendors or partners (e.g., robot manufacturers providing their own gateway devices for their robots).

[0178] Once these multiple gateways are integrated, the IIH system 2002 can provide a single view of the entire plant via data presentation 2810. In an example implementation, user interface component 2004 can deliver a customized dashboard to an authorized client device that visualizes selected portions of the virtualized plant 1602 and presents a selected subset of contextualized data 2806—or the results of analysis performed on that data 2806—via the dashboard. In some implementations, user interface component 2004 can deliver a 3D VR presentation depicting the substantially real-time operation of industrial assets 2802 to wearable devices or other types of client devices. These VR presentations can be generated based on asset models 312 and digital twins 810 that constitute the virtualized plant 1602 and are animated using contextualized data 2806. The IIH system 2002 can allow users to invoke asset-specific views of the plant by selecting assets of interest via the presentation.

[0179] Similar to the combination above Figure 19 The described architecture allows the IIH system 2002 to facilitate remote monitoring and interaction with industrial assets 2802. In other words, in addition to providing visualization, the IIH system 2002 can receive remote commands from users via interaction with these visualizations for selected industrial assets 2802, and the device interface component 2010 can deliver the requested commands to the asset 2802, depending on asset-specific restrictions on the issuance of remote commands.

[0180] In the implementation where asset model 312 is deployed on smart gateway device 1202, gateway device 1202 can use model 312 to add contextualized metadata to operational data items generated by their respective industrial assets 2802 to produce contextualized data 2806. Contextualized metadata added to a given data item may include, for example, a machine or asset identifier indicating the machine from which the data is obtained, values ​​of other data items related to the data item defined by asset model 312 (determined by correlations and causal relationships defined in model 312), synchronization timestamps, or other such metadata. This data contextualization helps the IIH system's analytics component 2012 to more quickly focus on valuable insights into the performance of industrial assets 2802 by meaningfully pre-modeling the data at the gateway level based on the industry expertise encoded in asset model 312.

[0181] The analysis component 2012 of the IIH system can perform analysis on contextualized data 2806 based on the digital twin 810 and asset model 312 of the virtualized factory 1602, and generate notifications or recommendations based on the results of the analysis. For example, the analysis can identify when operational aspects of the industrial asset 2802 (e.g., speed, pressure, flow rate, product throughput, downtime, etc.) exceed (e.g., by the OEM or other industry experts) acceptable ranges defined in the asset model 312. Based on these results, the analysis component 2012 can also generate recommendations for modifying the controls of the industrial asset 2802 to bring operation within defined ranges; for example, by modifying setpoints, changing control sequences, etc. In addition to generating notifications or as an alternative to generating notifications, the IIH system 2002 can send control commands (via the device interface component 2010) to the industrial asset 2802, which change the operation of the asset 2802 in a manner predicted to restore performance metrics to compliance.

[0182] Some implementations of the analysis component 2012 can be configured to perform predictive analysis on the collected contextualized data 2806 and, in response to predicting future operational problems based on the results of the analysis, generate notifications or recommendations for modifying operations to mitigate the problems. This predictive analysis can be assisted by a simulation component 2008, which can perform simulations of asset performance based on the virtualized plant 1602 and the historical performance of the asset 2802 determined according to the contextualized data 2806. Analysis of the contextualized data 2806 can also be performed based on machine learning models 2804 specifically designed for the corresponding asset 2802 and obtained from the supplier repository 326 or knowledge base 328. In this regard, the IIH system 2002 can maintain a library of machine learning models 2804 designed by equipment suppliers to gain insights into the operation of their equipment. Suppliers can register these machine learning models 2804 in a manner similar to asset models 312, or they can include these machine learning models 2804 as part of their corresponding asset models 312.

[0183] The smart gateway device 1202, debugged using asset model 312, can also be configured to perform local plant-level analysis on data collected from asset 2802. For this purpose, each gateway device 1202 may include a gateway analysis component 2108 capable of performing analysis functions similar to those of the analysis component 2012 of the IIH system 2002 (see [link to documentation]). Figure 21 Gateway device 1202 can apply these analyses to data collected from a subset of industrial assets connected to it. Based on the results of these local analyses, gateway device 1202 can send control feedback to one or more of their associated assets 2802 without waiting for analysis results from the cloud platform. Alternatively, gateway device 1202 can selectively send plant-level analysis results to IIH system 2002 for additional processing, storage, or notification purposes.

[0184] In some implementations, the IIH system 2002 and the smart gateway device 1202 can collaborate to manage the partitioning of computing resources between the cloud platform and the factory floor. For example, if the smart gateway device 1202 detects an asset-related event in the factory floor that requires additional computing power, the gateway's analytics scaling component 2112 can package the data and send it to the IIH system 2002 for higher-level processing. This may include collecting relevant data items needed for analysis and streaming these data items to the cloud platform while production continues (distributed computing). In this way, complex computations can be automatically pushed to the IIH system 2002, where more robust analysis can be applied through the analytics component 2012. Similarly, the analytics component 2012 of the IIH system 2002 can determine that the analytical or simulation results obtained by the IIH system 2002 are relevant to the operation of the industrial asset 2802 managed by the smart gateway device 1202. In response to this determination, device interface component 2010 can send the analysis results to the relevant gateway device 1202 for further plant-level processing. Gateway analysis component 2108 of gateway device 1202 can perform this additional processing based on the edge-level asset model 312 maintained on gateway device 1202. Based on the result of this further processing, gateway device 1202 can deliver control signals to industrial assets to change the operation of the assets. Analysis component 2012 of IIH system 2002 and gateway analysis component 2108 of smart gateway device 1202 can also collaborate to partition the processing of analysis tasks between IIH system 2002 and gateway device 1202. The determination of when an analysis task or part of an analysis task should be scaled to IIH system 2002 or gateway device 1202 can be based on the determination of where the analysis results will be consumed (e.g., by industrial assets in the form of control feedback, or by cloud-based systems for reporting or visualization purposes).

[0185] Cloud-level or gateway-level asset models 312 can also be used to model proposed modifications to automated systems and predict operational outcomes resulting from the implementation of those modifications. The results of this predictive analysis can be delivered to client devices in the form of predicted operational statistics or recommended changes to the proposed modifications that are more likely to produce the expected results of the modifications.

[0186] Knowing the customer's asset inventory, the IIH System 2002 can also send product announcements or notifications tailored to the known equipment the target customer will use. This can include sending recommendations based on the product lifecycle (e.g., recommending replacement when existing equipment is determined to be nearing the end of its lifecycle, such as based on the correlation between data generated by the equipment and lifecycle information recorded in the equipment's asset model). The IIH System 2002 can also provide the ability to upload equipment configurations and run simulations on a cloud platform to predict the results of firmware upgrades (or the impact of other types of system modifications) to the equipment. Notifications related to specific types of industrial equipment can include a rendered map of the customer's business, overlaid with hotspots indicating where the relevant equipment is currently in use. The IIH System 2002 can use this information to notify local maintenance personnel at those locations that an upgrade should be performed.

[0187] The IIH System 2002, implemented in conjunction with the IDH repository system 202, can create a cloud-based ecosystem that generates and delivers value for providers and owners of industrial equipment. The IIH System 2002 can act as a trusted information broker between the ecosystem and the customer's OT environment, providing a platform for connecting assets, contextualizing data, and providing secure access to the ecosystem. Furthermore, the IIH System 2002 can provide tools and support for OEMs and other subject matter experts, enabling them to leverage their digital assets within the ecosystem. The IIH System 2002 can reduce the cost and risk of industrial digital modeling, allowing suppliers, OEMs, and end users to collaborate to improve operational efficiency and asset performance.

[0188] To facilitate secure remote access to customers' factory floor assets, the IIH system 2002 may include one or more access management components 2014 (see [link to relevant documentation]). Figure 20 This provides users with the ability to securely connect to assets within their factory from remote locations without opening inbound ports on the factory's corporate firewall. Figure 29This is a high-level diagram illustrating a general architecture 2900 for providing secure remote access to industrial assets 2202 for customers. As in the previous example, intelligent gateway device 1202 resides on factory network 116 and acts as a gateway device or edge device. Intelligent gateway device 1202 can execute runtime components (e.g., as part of IIH interface component 2106 of the gateway device) that allow authorized devices to remotely access data on industrial assets 2202 via the cloud-based infrastructure of IIH system 2002. After intelligent gateway device 1202 has been deployed on factory network 116 and interfaced with other industrial assets 2202 through network 116, gateway device 1202 can send its credential information to IIH system 2002, which registers gateway device 1202 and its associated assets 2202 and data (e.g., data tags on industrial assets 2202 that can be used for remote access).

[0189] To access data on industrial assets 2202 via gateway device 1202, IIH system 2002 can execute portal 2902 as a cloud-based service (implemented by user interface component 2004). Portal 2902 can provide a front-end interface to remote client device 1904 requesting access to asset 2202 from its remote location. This front-end interface allows users at remote client device 1904 to input credential information that uniquely identifies the user and establishes the user's credentials, thereby verifying that the user is authorized to access a specific set of industrial assets 2202 at one or more industrial facilities interfaced with IIH system 2002 via smart gateway device 1202.

[0190] The cloud-based IIH system 2002 may include server infrastructure 2904, which cooperates as the IIH system's access management component 2014 and manages secure remote access to industrial assets 2202 at different locations via corresponding smart gateway devices 1202. Server infrastructure 2904 may include an access server (which may function as the system's access management component 222, or may execute one or more access management components 222), responsible for managing access to registered resources, such as registered industrial assets 2202, via gateway devices 1202. Server infrastructure 2904 may also include an API server that exposes an API to IIH system clients, and a distributed set of relay servers that execute algorithms to determine the optimal or fastest connection path between a set of industrial assets 2202 and client devices 1904 requesting access to those assets 2202. Server infrastructure 2904 may also include one or more database servers that serve as backup data storage for the access server and API server.

[0191] In the example scenario, client device 1904, belonging to a user affiliated with an industrial enterprise, can connect to portal 2902. Portal 2902 delivers a public front-end interface display to client device 1904, allowing the user to submit identification and credential data to system 2002. After verifying the validity of the user's credential data, portal 2902 determines, based on the user's identity and / or industrial enterprise affiliation, which subset of registered industrial assets 2202 (i.e., assets 2202 registered with and connected to IIH system 2002 via smart gateway device 1202) the user is allowed to access. Portal 2902 can then deliver an enterprise-specific interface to client device 1904, listing the available assets the user is allowed to access, and portal 2902 allows the user to select from these available assets. Based on this selection, server infrastructure 2904 establishes a Virtual Private Network (VPN) connection between remote client device 1904 and the selected asset 2202 via gateway device 1202, facilitated by a secure remote access runtime service executed on gateway device 1202. User interface component 2004 can then deliver a suitable data presentation to client device 1904, which presents real-time or historical data (e.g., status data, operational data, performance data, health or diagnostic data, production statistics, etc.) retrieved from asset 2202 via a VPN connection. Server infrastructure 2904 can establish this VPN connection without opening inbound ports through the factory's corporate firewall.

[0192] Any of the aforementioned IIH system functions that require remote access to industrial asset 2202 can be used Figure 29 The connectivity architecture 2900 described herein is used to manage remote access by customers to their industrial assets and associated data. For example, architecture 2900 can be used as a remote connectivity backbone for retrieving contextualized data 2806 and delivering it as a data presentation 2810 to remote users, as described above. Figure 28 As described. Therefore, the VPN connection is used as a data channel to feed real-time data from asset 2202 to data presentation 2810 at client device 1904. The VPN connection can also be used as a data channel to deliver analysis results generated by analysis component 2012, in addition to raw or contextualized data retrieved from industrial assets via gateway device 1202.

[0193] The secure remote connection architecture 2900 can also operate in conjunction with the modeling component 2006, which can map contextualized data from multiple gateway devices 1202 to a single virtualization factory 1602, as discussed above. This virtualization factory 1602 can then be visualized as a unified data presentation 2810 on the client device 1904 via a secure remote VPN connection.

[0194] The VPN connection established by the secure remote access features of the IIH system 2002 can also allow users to submit control commands to selected industrial assets 2202 via server infrastructure 2904. This can include, for example, via [the above-mentioned method]. Figure 28 The described dashboard, which presents data demonstration 2810, allows for interactive commands.

[0195] Although Figure 29 The text describes a secure remote access technology used during the operational phase of an industrial project to establish a VPN connection between a remote user's client device and the industrial asset 2202 they are running. However, the service implementing the secure remote access technology can also be used to provide secure connections to client-specific virtual machines instantiated by the IDH repository system 202 during project development. Figure 30 This diagram illustrates an example architecture for an IDH storage repository system 202 that supports the ability to instantiate virtual machine instances as part of the system's digital engineering services on a cloud platform and connect to these virtual machine instances using secure remote access features. In this example, the IDH storage repository system 202 shares a portal 2902 and server infrastructure 2904 with the IIH system 2002, including the above-mentioned combination. Figure 29 The discussion focuses on secure remote access features. The IDH Repository System 202 supports cloud-based digital engineering services, including those mentioned above. Figures 2 to 19 Those described. These digital engineering services also include features that allow users to create instances of Virtual Machine 3020 on a cloud platform, which can be used to execute vendor-provided digital engineering applications that users are entitled to use under their subscription contracts with those vendors.

[0196] exist Figure 30 In the example architecture, the cloud-based system 202 can be accessed by a remote client (the owner of client device 1904) authorized to access the digital engineering services implemented by system 202. System 202 can also be accessed by one or more service providers 3004 that provide and maintain the digital engineering services. To support the instantiation and execution of virtual machines 3020, system 202 can maintain various virtual machine images 3002 on an image registry 3006 (which may be part of storage 228). Virtual machine images 3002 can be vendor-specific, so each vendor repository 326 may include its own dedicated image registry 3006 for storing vendor-specific virtual machine images 3002. System 202 allows software vendors to submit and register their own virtual machine images for use by their customers in the system's digital engineering environment.

[0197] The image registry 3006 serves as the initial storage location for virtual machine images 3002 to be hosted on the IDH storage system 202. Virtual machine images 3002 can be created, registered, and managed by service providers 3004 (e.g., control software vendors) who wish to offer their design software as a remote design service to authorized clients. Figure 31 This diagram depicts the registration of a virtual machine image 3002 to an image registry 3006 according to one or more implementations. Each virtual machine image 3002 may include a base image 3110 and associated image metadata 3112 (e.g., inventory units, version information, the date the image 3002 was submitted, a bill of materials, etc.). A service provider 3004 (e.g., a software vendor providing digital engineering software) may submit the virtual machine image as the base image 3110 and associated image metadata 3112 to an API service 3102, which facilitates the uploading of the image and associated metadata. The API service 3102 uploads the base image 3110 to an image storage 3106 (e.g., blob storage). The API service 3102 also uploads the image metadata 3112 to a document database 3104 for storing metadata associated with each image. From image storage 3106, base image 3110 is promoted to shared library 3108, and the promoted image is tagged with metadata 3112 from document database 3104 to produce shared virtual machine image 3002 ready to be deployed as a virtual machine.

[0198] Return now Figure 30 Virtual machine image 3002, already registered in image registry 3006, is exposed to the digital engineering services of the IDH storage system, allowing customers to remotely access and deploy selected virtual machines 3020 to remotely execute automated design software and services. Remote users can submit their identity and credentials to portal 2902 via client device 1904 (as combined above). Figure 29 Accessing digital engineering services is done via portal 2902 and the IDH repository system. In some implementations, users can access these services through their web browsers. Once a user's identity and credentials have been authenticated by the system's authentication service 3018, portal 2902 can present a customized front-end interface on the user's client device 1904, which includes a list of available digital engineering services that the user is permitted to access. The front-end interface can be user-specific or enterprise-specific, allowing the services available to a given user to depend on the user's identity or the industry to which the user belongs.

[0199] API application 3012 provides a framework for managing access to digital engineering services, allowing authenticated users to browse, select, and deploy virtual machine images 3002 as running virtual machines 3020. These virtual machines can be used to remotely visualize and operate design software that allows user access and use. In this regard, each virtual machine image 3002 can be designed by its vendor to remotely execute industrial design applications or services provided by the vendor. These design applications and services can include, but are not limited to, control logic development software or platforms, HMI development software, industrial controller simulators, industrial asset or plant simulators, project analysis software, engineering drawing applications, or other such design applications.

[0200] Once a user has been authenticated by the system's authentication service 3018, the user can interact with a list of available services presented via a front-end interface to select one or more virtual machine images 3002 to be deployed and executed in the user's dedicated digital engineering space. System 202 assigns a remote digital engineering space to each participating client entity, where users belonging to that entity can deploy and run virtual machines 3020 for the purpose of designing and testing their control system projects and associated software (control programs, HMIs, digital twins, analytics, data collection, control simulations, etc.). When a user selects a virtual machine image 3002 from the image registry 3006, provisioning service 3008 (e.g., services implemented by one or more provisioning components 224) deploys an instance of virtual machine image 3002 as an executable virtual machine 3020 within the user-specified digital engineering space. Once deployed, the user can remotely access the virtual machine 3020 via client device 1904 and use the digital engineering functions supported by the selected virtual machine 3020. This can include, for example, using the virtual machine 3020 as a development platform to create and test industrial control code or HMI applications; using the virtual machine 3020 to simulate the execution of control programs uploaded by users to the digital engineering space; building and running digital twins of one or more industrial assets on the virtual machine 3020 that supports factory simulation (this may involve interfacing the digital twins with simulated industrial control programs executed on the simulated virtual machine 3020); testing industrial equipment configuration parameters; and developing engineering drawings or other such engineering functions. Some virtual machine images 3002 may be pre-configured with the design software that those images are designed to support, so that the deployed virtual machine 3020 is pre-installed with the desired design software.

[0201] Secure remote access service 3014 can be used to connect remote client device 1904 to provisioning service 3008 and deployed virtual machine 3020. These remote access services 3014 can be used in combination as described above. Figure 29The discussed secure remote access architecture (e.g., server infrastructure 2904 and its associated servers) is used to implement secure connections between virtual machines 3020 hosted by IDH repository system 202 and remote client devices 1904. In the example implementation, runtime services similar to those executed on intelligent gateway device 1202, which manages secure remote connections to physical assets on the factory floor, can be supplied to virtual machine 3020. This allows the use of secure remote access server infrastructure 2904 to create similar secure remote connections to virtual machines 3020 hosted in a customer's digital engineering space.

[0202] As described above, customer entities registered to access and use the digital engineering services supported by the IDH repository system 202 can be allocated corresponding digital engineering space within the system's cloud architecture. Figure 32 This diagram illustrates the multi-tenant execution of virtual machine 3020 on IDH storage system 202. Multiple customers can deploy, execute, and access their own set of virtual machines 3020 on various isolated, customer-specific digital engineering spaces 3202 assigned to them. These digital engineering spaces 3202 can be part of each customer's storage 324. This architecture allows each customer to log into system 202 and execute selected industrial design functions on demand within their own design space without having to install and configure the required design software on their own machines. This architecture allows users to remotely visualize and interact with these virtualized design functions via their client devices 1904 using secure remote access service 3014, perform desired engineering tasks, and deactivate the instantiated virtual machines 3020 upon completion.

[0203] When a user remotely requests that virtual machine 3020 be provisioned to their digital engineering space 3202, provisioning service 3008 creates an instance of virtual machine 3020 based on the corresponding virtual machine image 3002 and identifies virtual machine 3020 using the tenant identifier associated with the user's digital engineering space 3202. Provisioning service 3008 may also identify virtual machine 3020 using the stock inventory unit (SKU) associated with the customer entity to which the user belongs (e.g., an industrial enterprise), the version number of the associated SKU, and the user's user identity. Virtual machine 3020 is also registered to a secure remote access architecture, allowing users to securely connect to virtual machine 3020 from their remote client device 1904. If a domain for virtual machine 3020 has not yet been created, a domain for virtual machine 3020 is created within digital engineering space 3202, and the user requesting virtual machine 3020 is added to the domain and granted domain management privileges. Service 3008 then completes the registration process between the virtual machine's runtime service and the secure remote access service, enabling the user's client device 1904 to securely access and execute commands targeting the virtual machine 3020 and its pre-installed design software. Users can remotely start, stop, destroy, or re-image the virtual machine 3020 from the remote client device 1904. In the example implementation, portal 2902 (implemented by user interface component 204) can remotely visualize digital engineering software or applications running on the virtual machine 3020 on the user's client device via a VPN connection established by the secure remote access architecture 3014. This connection allows users to remotely use the engineering software from their client device 1904, providing a user experience similar to executing the engineering software locally on the client device 1904.

[0204] This method allows users to instantiate libraries for virtual machines 3020 that perform various digital engineering functions before ceasing use after the virtual machine 3020 has completed its task, and to remotely interface with these virtual machines 3020 to perform remote digital engineering tasks. Each virtual machine image 3002 represents a virtual machine category and instantiates a virtual machine 3020 that has been configured with design software corresponding to that image category. System 202 also provides an ecosystem for software vendors to create and register virtual machine images 3002 containing their contents in image registry 3006, enabling their customers to use the system's provisioning service 3008 to deploy corresponding virtual machine instances from registry 3006 and connect to these instances using a secure remote access architecture.

[0205] In some scenarios, users can deploy and run multiple virtual machines (VMs) 3020 within their digital engineering space 3202 and configure two or more of these VMs 3020 to interact with each other to perform digital engineering tasks. For example, a first VM 3020 equipped with an industrial simulation platform can be configured to interface with a second VM 3020 equipped with a controller simulator. Users can configure these two VMs 3020 to exchange simulated I / O signaling, thereby simulating factory operations under the control of an industrial control program simulated by the controller simulator (using a digital twin of the factory). Users can remotely control the simulation (the results of which are presented on the user's client device), modify the control program as needed until correct control operations are confirmed, and then discontinue the use of VM 3020 after completing control program testing.

[0206] For auditing purposes, IDH storage system 202 can also maintain database 3016 (see Figure 30 Database 3016 records all transactions generated through API application 3012. Information that can be recorded in database 3016 may include, for example: records of instantiated virtual machines 3020; timestamps indicating the time when virtual machines 3020 were instantiated; the identity of the user who instantiated each virtual machine 3020; records of when each virtual machine 3020 was started, stopped, re-imaged, or destroyed; or other such information.

[0207] In some implementations, some of the virtual machine images 3002 may be pre-configured with a project conversion service, which is designed to upgrade and convert control programming files from a first version to a second version. Figure 33 This is a diagram of an example implementation of an IDH repository system 202, which can provide a virtual machine 3020 with pre-installed project conversion services. Similar to the above combination... Figures 30 to 32 In the described example scenario, a remote user of client device 1904 can remotely access the system's provisioning service 3008 to selectively deploy and run virtual machines 3020 on their designated design space 3202 from virtual machine images 3002 stored on image registry 3006. The available virtual machine images 3002 include images pre-configured with project conversion service 3302, which is designed to upgrade or convert industrial control program files or other aspects of control project 306 from a first version to a second version.

[0208] Figure 34This diagram illustrates the use of a deployed virtual machine 3020 running a project conversion service to convert control program files. In this example scenario, a user has instantiated a virtual machine 3020 with a pre-configured project conversion service 3302 within a dedicated digital engineering space in a customer repository 324 of their affiliated customer entity. The user can deploy the virtual machine 3020 as an instance of a corresponding virtual machine image 3002 pre-configured with the conversion service 3302. Once instantiated, the virtual machine 3020 can apply its project conversion service 3302 to control program files 3402a (e.g., ladder logic files or other types of control program files) stored in the customer repository 324 to upgrade or convert the files from a first version (vX) to a second version (vY), resulting in a new, upgraded control program file 3402b. The resulting converted control program file 3402b can be stored on the user's customer repository 324, downloaded to the user's client device 1904, or deployed to a factory floor controller for execution. The original program file 3402a can be stored in the customer repository as an archived project version 310.

[0209] In some implementations, the project conversion service 3302 executed by the virtual machine 3020 can be combined in a manner similar to the above. Figure 11 The described method of project conversion functionality of asset recovery component 214 is as follows. Some project conversion services 3302 can also be configured to apply any project analyses discussed above (e.g., those similar to those applied by project analysis component 210) to control program file 3402a, and, upon completion of the conversion, provide an upgraded control program file 3402b along with recommendations for improving the operation of the control program or optimizing the resource utilization of the control program itself (e.g., the project recommendation 702 described above).

[0210] In some scenarios, as part of the conversion of control program file 3402a, project conversion service 3302 can replace parts of the control program defined in file 3402a with equivalent automation object 504 to produce upgraded program file 3402b.

[0211] although Figure 34 The initial program file 3402a residing on the customer repository 324 is described. However, in some scenarios, users can also directly upload the program file to the virtual machine 3020 for conversion by the conversion service 3302. Furthermore, some virtual machines 3020 can be configured with a project conversion service 3302, which is designed to convert aspects of the system project 306 other than the control code, including but not limited to HMI applications, industrial AR / VR visualization applications, industrial equipment firmware, or other such control project aspects.

[0212] Figures 35 to 36b Various methods according to one or more embodiments of this application are illustrated. Although for the purpose of simplicity, the one or more methods shown herein are shown and described as a series of actions, it should be understood and appreciated that the invention is not limited to the order of actions, as some actions may occur in a different order than those shown and described herein and / or simultaneously with other actions. For example, those skilled in the art will understand and recognize that a method may alternatively be represented, for example, as a series of interrelated states or events in a state diagram. Furthermore, not all of the actions shown may be required to implement the method according to the invention. Additionally, an interaction diagram may represent a methodology or approach according to this disclosure when different entities formulate different parts of the method. Furthermore, two or more of the disclosed example methods may be implemented in combination with each other to achieve one or more features or advantages described herein.

[0213] Figure 35 An example method 3500 for establishing secure remote access to data regarding industrial assets operating in a factory facility is illustrated. Initially, at 3502, registration data for a set of industrial assets at the industrial facility is received at a cloud-based Industrial Information Center (IIH) system. The registration data is received from a gateway device installed at the industrial facility and communicatively connected to the industrial assets (e.g., via a factory network). At 3504, the industrial assets are registered in the IIH system in association with the industrial enterprise that owns the industrial assets.

[0214] At step 3506, a front-end interface is delivered to a client device connected to the cloud-based IIH system. The front-end interface may include prompts for identification or authentication data used to determine the scope of secure remote access provided to the user of the client device. At step 3508, credential information is received from the client device via interaction with the front-end interface. Credential information may be, for example, a username and password, biometric information, the output of a scanned optical code, or other such data. At step 3510, a determination is made as to whether the credential data has been authenticated. If the credential data has not been authenticated ("No" at step 3510), the method returns to step 3506. Alternatively, if the credential data has been authenticated ("Yes" at step 3510), the method proceeds to step 3512, in which a Virtual Private Network (VPN) connection is established between the client device and the industrial asset via a gateway device. The VPN connection allows remote viewing of data related to the industrial asset (e.g., operational data, status data, or health data), and in some cases, the VPN connection allows control commands to be remotely delivered from the client device to one or more assets. VPN connections can be established based on the interaction between the IIH system and the Secure Remote Access Runtime Service running on the gateway device.

[0215] Figure 36a The first part 3600a illustrates an example method for remotely deploying and securely accessing virtual machines pre-installed with digital design applications for designing and testing industrial projects. Initially, at 3602, the virtual machine image is registered on a cloud-based Industrial Development Center (IDH) system. The virtual machine image can be registered by a vendor developing industrial digital engineering applications (e.g., industrial control code development platforms, HMI development applications, industrial equipment configuration software, industrial controller simulators, industrial simulation platforms, etc.) and can be pre-configured with secure remote access runtime services. Each virtual machine image can also be pre-configured with an industrial design application.

[0216] At step 3604, a request to access digital engineering services available on the IDH system is received from the client device. This request can be received via interaction with a front-end interface provided to the client device by the IDH system. At step 3606, a determination is made as to whether the credential information received from the client device as part of the request has been authenticated. If the credential data has not been authenticated ("No" at step 3606), the method returns to step 3604. Alternatively, if the credential data has been authenticated ("Yes" at step 3606), the method continues to step 3608, in which a customer-specific IDH interface is delivered to the client device. The customer-specific IDH interface lists the available remote digital engineering services available to the user of the client device based on the user's identity or customer affiliation.

[0217] The method proceeds to Figure 36b The second part, 3600b, is shown. At 3610, a request is received from the client device to invoke an industrial design application installed on a virtual machine image as a selected remote digital engineering service among available remote digital engineering services. At 3612, in response to the request, a virtual machine is deployed and executed on a cloud-based digital engineering space allocated to the user's client. The virtual machine includes an instantiation of a virtual machine image and is capable of executing the industrial design application installed on its parent virtual machine image.

[0218] At 3614, a secure remote access runtime service running on the virtual machine is used to establish a secure VPN connection between the client device and the virtual machine. At 3616, remote access to an industrial design application running on the virtual machine is permitted via the secure VPN connection.

[0219] In some scenarios, industrial design applications running on virtual machines can be project conversion applications designed to upgrade or convert submitted industrial project files (e.g., controller program files, HMI application files, etc.) from version one to version two.

[0220] The embodiments, systems, and components described herein, as well as the control systems and automation environments in which the various aspects set forth in this specification can perform, may include computer or network components capable of interacting across networks, such as servers, clients, programmable logic controllers (PLCs), automation controllers, communication modules, mobile computers, onboard computers for mobile vehicles, wireless components, control components, etc. Computers and servers include one or more processors configured to execute instructions stored in a medium, said one or more processors being electronic integrated circuits that perform logical operations using electrical signals. The medium may be, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, and removable memory devices, which may include memory sticks, memory cards, flash drives, external hard disk drives, etc.

[0221] Similarly, the term PLC or automation controller as used herein can encompass functionality that can be shared across multiple components, systems, and / or networks. As an example, one or more PLCs or automation controllers can communicate and collaborate with various networked devices across a network. This can essentially include any type of control device, communication module, computer, input / output (I / O) device, sensor, actuator, and human-machine interface (HMI) communicating via a network, including control networks, automation networks, and / or public networks. PLCs or automation controllers can also communicate with and control a variety of other devices, such as standard or safety-grade I / O modules, including analog modules, digital modules, programmable / intelligent I / O modules, other programmable controllers, communication modules, sensors, actuators, output devices, etc.

[0222] Networks can include public networks such as the Internet, intranets, and automation networks such as Control and Information Protocol (CIP) networks, including DeviceNet, ControlNet, security networks, and Ethernet / IP. Other networks include Ethernet, DH / DH+, remote I / O, fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols, Open Platform Communication Unified Architecture (OPC-UA), etc. Additionally, network devices can include a wide variety of possibilities (hardware components and / or software components). These include components such as switches with Virtual Local Area Network (VLAN) capabilities, LANs, WANs, agents, gateways, routers, firewalls, Virtual Private Network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and / or other device components.

[0223] In order to provide context for the various aspects of the disclosed topic, Figure 37 and Figure 38 The following discussion is intended to provide a brief, general description of suitable environments in which the aspects of the disclosed subject matter can be implemented. Although the implementations have been described above in the general context of computer-executable instructions that can run on one or more computers, those skilled in the art will recognize that implementations can also be implemented in combination with other program modules and / or as a combination of software and hardware.

[0224] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will understand that the methods of this invention can be practiced using other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, and personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, each of which can be operatively coupled to one or more associated devices.

[0225] The implementations illustrated herein can also be practiced in distributed computing environments, where certain tasks are performed by remote processing devices linked via a communication network. In a distributed computing environment, program modules can reside on both local and remote memory storage devices.

[0226] Computing devices typically include a variety of media, which can include computer-readable storage media, machine-readable storage media, and / or communication media, these terms being used interchangeably herein. A computer-readable storage medium or a machine-readable storage medium can be any available storage medium accessible by a computer, and includes volatile and non-volatile media, removable media, and non-removable media. By way of example and not limitation, a computer-readable storage medium or a machine-readable storage medium can be implemented using any method or technique for storing information such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0227] Computer-readable storage media may include, but are not limited to: random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible and / or non-transitory media that can be used to store desired information. In this regard, the terms “tangible” or “non-transitory” used herein to describe storage devices, memories, or computer-readable media should be understood as modifiers that exclude only the propagation of transient signals themselves, and do not waive the rights of all standard storage devices, memories, or computer-readable media that do not only propagate transient signals themselves.

[0228] Computer-readable storage media can be accessed by one or more local or remote computing devices, for example via access requests, queries or other data retrieval protocols, to perform various operations on the information stored on the media.

[0229] Communication media typically embody computer-readable instructions, data structures, program modules, or other structured or unstructured data in the form of data signals, such as modulated data signals, carrier waves, or other transmission mechanisms, and include any information delivery or transmission medium. The term "modulated data signal" or signal refers to a signal that sets or alters one or more characteristics of its properties in a manner that encodes information in one or more signals. By way of example and not limitation, communication media include wired media such as wired networks or direct wired connections, as well as wireless media such as acoustic, RF, infrared, and other wireless media.

[0230] Refer again Figure 37 An example environment 3700 for implementing various embodiments of the aspects described herein includes a computer 3702, which includes a processing unit 3704, system memory 3706, and a system bus 3708. The system bus 3708 couples system components to the processing unit 3704, including but not limited to the system memory 3706. The processing unit 3704 can be any processor from a variety of commercially available processors. Dual-microprocessor architectures and other multiprocessor architectures can also be used as the processing unit 3704.

[0231] System bus 3708 can be any of several types of bus architectures; it can also interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. System memory 3706 includes ROM 3710 and RAM 3712. The Basic Input / Output System (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, and contains basic routines, for example, that help transfer information between components within computer 3702 during startup. RAM 3712 can also include high-speed RAM, such as static RAM for caching data.

[0232] Computer 3702 also includes an internal hard disk drive (HDD) 3714 (e.g., EIDE, SATA), one or more external storage devices 3716 (e.g., floppy disk drive (FDD) 3716, memory stick or flash drive reader, memory card reader, etc.), and an optical disc drive 3720 (e.g., capable of reading from or writing to CD-ROMs, DVDs, BDs, etc.). While the internal HDD 3714 is shown as residing within computer 3702, it can also be configured for external use in a suitable chassis (not shown). Additionally, although not shown in environment 3700, a solid-state drive (SSD) can be used in addition to or in place of the HDD 3714. The HDD 3714, external storage devices 3716, and optical disc drive 3720 can be connected to system bus 3708 via HDD interface 3724, external storage interface 3726, and optical disc drive interface 3728, respectively. The interface 3724 for the external drive implementation may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external drive connection technologies are considered in the implementations described herein.

[0233] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, etc. For computer 3702, the drive and storage medium are adapted to store any data in a suitable digital format. Although the above description of computer-readable storage media refers to various types of storage devices, those skilled in the art will understand that other types of computer-readable storage media, whether currently existing or developed in the future, may also be used in the example operating environment, and furthermore, any such storage medium may contain computer-executable instructions for performing the methods described herein.

[0234] Multiple program modules, including an operating system 3730, one or more application programs 3732, other program modules 3734, and program data 3736, can be stored in the drive and RAM 3712. All or part of the operating system, applications, modules, and / or data can also be cached in RAM 3712. The systems and methods described herein can be implemented using a variety of commercially available operating systems or combinations of operating systems.

[0235] Computer 3702 may optionally include emulation technology. For example, a hypervisor (not shown) or other intermediate program may emulate the hardware environment used for operating system 3730, and the emulated hardware may optionally be different from the hardware used for operating system 3730. Figure 37 The hardware shown is illustrated. In such an implementation, the operating system 3730 may include one of a plurality of virtual machines (VMs) hosted at the computer 3702. Furthermore, the operating system 3730 may provide a runtime environment for the application 3732, such as a Java runtime environment or the .NET Framework. A runtime environment is a consistent execution environment that allows the application 3732 to run on any operating system that includes a runtime environment. Similarly, the operating system 3730 may support containers, and the application 3732 may be in the form of a container, which is a lightweight, standalone, executable software package that includes, for example, code, runtime, system tools, system libraries, and application settings.

[0236] Furthermore, security modules such as Trusted Processing Modules (TPMs) can be used to enable the computer 3702. For example, using a TPM, the boot component hashes the next boot component in time and waits for the result to match a security value before loading the next boot component. This process can occur at any level of the computer 3702's code execution stack, such as at the application execution level or at the operating system (OS) kernel level, thereby enabling security at any level of code execution.

[0237] Users can input commands and information into computer 3702 through one or more wired / wireless input devices (e.g., keyboard 3738, touchscreen 3740, and pointing devices such as mouse 3742). Other input devices (not shown) may include microphones, infrared (IR) remote controls, radio frequency (RF) remote controls or other remote controls, joysticks, virtual reality controllers and / or virtual reality headsets, game controllers, styluses, image input devices such as camera devices, gesture sensor input devices, visual motion sensor input devices, emotion or face detection devices, biometric input devices such as fingerprint or iris scanners, etc. These and other input devices are typically connected to processing unit 3704 via input device interface 3744, which can be coupled to system bus 3708, but may also be connected via other interfaces, such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, etc. Interfaces, etc.

[0238] Monitor 3744 or other types of display devices can also be connected to system bus 3708 via an interface such as video adapter 3746. In addition to monitor 3744, the computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0239] Computer 3702 can operate in a networked environment via wired and / or wireless communication to one or more remote computers, such as remote computer 3748, using logical connections. Remote computer 3748 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other common network node, and typically includes many or all of the elements described with respect to computer 3702; however, for simplicity, only memory / storage device 3750 is shown. The depicted logical connections include wired / wireless connections to a local area network (LAN) 3752 and / or a larger network such as a wide area network (WAN) 3754. Such LAN and WAN networking environments are common in offices and companies and facilitate enterprise-wide computer networks such as intranets, all of which can connect to global communication networks such as the Internet.

[0240] When used in a LAN networking environment, computer 3702 can connect to local network 3752 via a wired and / or wireless communication network interface or adapter 3756. Adapter 3756 can facilitate wired or wireless communication with LAN 3752, and LAN 3752 may also include a wireless access point (AP) disposed thereon for communicating with adapter 3756 in wireless mode.

[0241] When used in a WAN networking environment, computer 3702 may include modem 3758, or may be connected to a communication server on WAN 3754 via other means (e.g., via the Internet) for establishing communication over WAN 3754. Modem 3758, which may be internal or external and wired or wireless, may be connected to system bus 3708 via input device interface 3742. In a networking environment, program modules depicted relative to computer 3702 or parts thereof may be stored in remote memory / storage device 3750. It will be understood that the network connection shown is illustrative, and other means of establishing communication links between computers may be used.

[0242] When used in a LAN or WAN networking environment, in addition to the external storage device 3716 described above, the computer 3702 can also access cloud storage systems or other network-based storage systems, or access cloud storage systems or other network-based storage systems in place of the external storage device 3716. Typically, the connection between the computer 3702 and the cloud storage system can be established via LAN 3752 or WAN 3754, for example, through adapter 3756 or modem 3758. When connecting the computer 3702 to the associated cloud storage system, the external storage interface 3726 can manage the storage provided by the cloud storage system, just as it would manage other types of external storage, with the help of adapter 3756 and / or modem 3758. For example, the external storage interface 3726 can be configured to provide access to cloud storage sources as if those sources were physically connected to the computer 3702.

[0243] Computer 3702 is operable to communicate with any wireless device or entity operatively arranged wirelessly, such as a printer, scanner, desktop and / or portable computer, portable data assistant, communication satellite, any equipment or location associated with a wirelessly detectable tag (e.g., kiosk, newsstand, shop shelf, etc.), and telephone. This can include Wi-Fi and Wireless technology. Therefore, communication can be a predefined structure like a conventional network or simply self-organized communication between at least two devices.

[0244] Figure 38This is a schematic block diagram of a sample computing environment 3800 that can interact with the disclosed subject matter. The sample computing environment 3800 includes one or more clients 3802. Clients 3802 can be hardware and / or software (e.g., threads, processes, computing devices). The sample computing environment 3800 also includes one or more servers 3804. Servers 3804 can also be hardware and / or software (e.g., threads, processes, computing devices). For example, server 3804 can accommodate threads to perform transformations by employing one or more implementations described herein. One possible communication between clients 3802 and server 3804 can be in the form of data packets suitable for transmission between two or more computer processes. The sample computing environment 3800 includes a communication framework 3806 that can be used to facilitate communication between clients 3802 and server 3804. Clients 3802 are operatively connected to one or more client data storage devices 3808, which can be used to locally store information on clients 3802. Similarly, server 3804 can be operatively connected to one or more server data storage devices 3810, which can be used to locally store information to server 3804.

[0245] The above description includes examples of subject-matter innovation. For the purposes of describing the disclosed subject matter, it is certainly impossible to describe every conceivable combination of components or methods, but those skilled in the art will recognize that many other combinations and arrangements of the invention are also possible. Therefore, the disclosed subject matter is intended to encompass all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

[0246] In particular, and with regard to the various functions performed by the aforementioned components, devices, circuits, systems, etc., unless otherwise stated, the terminology used to describe such components (including references to "means") is intended to correspond to any component (e.g., a functionally equivalent component) that performs the specific function of the described component, even if it is not structurally equivalent to the disclosed structure, the component still performs the functions of the exemplary aspects of the disclosed subject matter shown herein. In this regard, it will also be appreciated that the disclosed subject matter includes systems and computer-readable media having computer-executable instructions for actions and / or events of various methods for performing the disclosed subject matter.

[0247] Furthermore, while a particular feature of the disclosed subject matter may be disclosed only for one of several implementations, such features may be combined with one or more other features of other implementations, which may be desirable and advantageous for any given application or particular application. Moreover, with regard to the use of the terms "includes" and "including" and their variations in the detailed description or claims, these terms are intended to be included in a manner similar to the term "comprising."

[0248] In this application, the word "exemplary" is used to indicate that it is used as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the word "exemplary" is intended to present the concept in a concrete manner.

[0249] The various aspects or features described herein can be implemented as methods, apparatus, or articles of art using standard programming and / or engineering techniques. The term "article of art" as used herein is intended to encompass any computer program accessible from any computer-readable device, carrier, or medium. For example, computer-readable media may include, but are not limited to: magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes, etc.), optical discs (e.g., compact discs (CDs), digital versatile discs (DVDs), etc.), smart cards, and flash memory devices (e.g., cards, sticks, key drives, etc.).

Claims

1. A system for providing secure remote access to industrial assets, comprising: Memory, the memory storing executable components; as well as A processor, operatively coupled to the memory, executes the executable component, the executable component comprising: A device interface component configured to communicatively connect via a cloud platform to gateway devices deployed at one or more industrial facilities, wherein the gateway devices are communicatively connected to industrial assets operating at the one or more industrial facilities, and the gateway devices respectively perform secure remote access runtime services. The user interface component is configured to provide a front-end interface to the client device via the cloud platform and to receive request data including user identity and credential information through interaction with the front-end interface. An access management component, configured to: in response to determining that the user's identity and the credential information allow access to a subset of the industrial assets, establish a virtual private network connection between the client device and the subset of the industrial assets via a gateway device communicatively connected to the subset of the industrial assets in the gateway device; and An analytics component, configured to analyze contextualized data obtained from a subset of the industrial assets, based on a virtualized factory that executes on the cloud platform and includes a digital asset model of the industrial assets. The contextualized data includes industrial data and contextual metadata added to the industrial data by the gateway device. The user interface component is configured to: present a unified presentation of a subset of the industrial assets on the client device via the virtual private network based on the contextualized data, and to present the results of the analysis via the unified presentation. The access management component is configured to establish the virtual private network connection without opening the inbound port through the firewall at the industrial facility where the gateway device resides.

2. The system according to claim 1, wherein, The user interface component is also configured to present data stored on a subset of the industrial assets via the virtual private network connection on the client device.

3. The system according to claim 2, wherein, The data is at least one of the following: asset status data, asset operation data, asset performance data, asset diagnostic data, or production statistics.

4. The system according to claim 1, wherein, The user interface component is configured as follows: In response to determining the user's identity and the credential information allowing access to a subset of the industrial assets, a list of the subset of industrial assets is presented for selection. In response to selecting an industrial asset from the list, a presentation of the data retrieved from that industrial asset is delivered to the client device.

5. The system according to claim 1, wherein, The user interface component is also configured to receive remote control commands from the client device for a subset of the industrial assets, and the access management component is configured to send the remote control commands to the industrial assets via the virtual private network connection.

6. The system according to claim 1, wherein, The access management component is configured to execute one or more algorithms to determine the optimal connection path from the client device to the gateway device for establishing the virtual private network connection.

7. The system according to claim 1, wherein, The device interface component is configured to receive the industrial data as the contextualized data, and The analysis component is configured to analyze the industrial data based on the contextual metadata.

8. The system according to claim 7, wherein, At least one of the contextual metadata defines the correlation between two or more items of the industrial data, identifies the machine that generated the industrial data, or applies a synchronized timestamp to the industrial data.

9. The system according to claim 1, wherein, The asset model defines visual representations and functional specification data for the industrial assets corresponding to the asset model.

10. A method for providing secure remote access to industrial assets, comprising: A system including a processor is communicatively connected via a cloud platform to gateway devices installed at one or more industrial facilities, wherein the gateway devices are communicatively connected to industrial assets operating at the one or more industrial facilities, and the gateway devices respectively perform secure remote access runtime services. The system provides a front-end interface to the client device via the cloud platform; The system receives request data, including user identity and credential information, through interaction with the front-end interface; In response to determining the user's identity and the credential information that allows access to a subset of the industrial assets, the system establishes a virtual private network connection between the client device and the subset of the industrial assets via a gateway device communicatively connected to the subset of the industrial assets in the gateway device. The system analyzes contextualized data obtained from the subset of industrial assets, based on a virtualized factory that executes on the cloud platform and includes a digital asset model of the industrial assets. The contextualized data includes industrial data and contextual metadata added to the industrial data by the gateway device. The system presents a unified presentation of a subset of the industrial assets on the client device via the virtual private network based on the contextualized data, and presents the results of the analysis through the unified presentation. The establishment includes: establishing the virtual private network connection without opening the inbound port through the firewall at the industrial facility where the gateway device resides.

11. The method of claim 10, further comprising: Data stored on a subset of the industrial assets is presented on the client device via the virtual private network connection.

12. The method according to claim 11, wherein, The presented data includes at least one of the following: asset status data, asset operation data, asset performance data, asset diagnostic data, or production statistics.

13. The method of claim 10, further comprising: In response to determining the user's identity and the credential information allowing access to a subset of the industrial assets, the system presents a list of the subset of industrial assets for selection on the client device. In response to receiving an instruction from the client device to select an industrial asset from the list, the system delivers a presentation of the data retrieved from that industrial asset to the client device.

14. The method of claim 10, further comprising: The system receives remote control commands from the client device for a subset of industrial assets. as well as The system sends the remote control command to the industrial asset via the virtual private network connection.

15. The method according to claim 10, wherein, The establishment process includes executing one or more algorithms to determine the optimal connection path from the client device to the gateway device for establishing the virtual private network connection.

16. A non-transitory computer-readable medium storing instructions that, in response to execution, cause system execution operations on a cloud platform and include a processor, the operations comprising: The cloud platform is communicatively connected to gateway devices installed at one or more industrial facilities, wherein the gateway devices are communicatively connected to industrial assets operating at the one or more industrial facilities, and the gateway devices respectively perform secure remote access runtime services. The cloud platform provides a front-end interface to the client device. Request data, including user identity and credential information, is received through interaction with the front-end interface; In response to determining that the user's identity and the credential information allow access to a subset of the industrial assets, a virtual private network connection is established between the client device and the subset of the industrial assets via a gateway device communicatively connected to the subset of the industrial assets in the gateway device. A virtualized factory, based on a digital asset model executed on the cloud platform and including a subset of the industrial assets, analyzes contextualized data obtained from the subset of industrial assets, wherein the contextualized data includes industrial data and contextual metadata added to the industrial data by the gateway device; and Based on the contextualized data, a unified presentation of a subset of the industrial assets is presented on the client device via the virtual private network, and the results of the analysis are presented through the unified presentation. The establishment includes: establishing the virtual private network connection without opening the inbound port through the firewall at the industrial facility where the gateway device resides.

Images