Unify multiple simulation models

Abstract

The present invention provides for unifying multiple simulation models. Design and test simulations scale industrial simulations across multiple different processing nodes and generate a unified view of the distributed industrial simulation based on simulation and graphical data collected from the multiple processing nodes. The system can allow a user to specify different portions of a digital model of an automation system to be executed on respective different distributed processing nodes such that each portion of the model is executed on its specified node and the nodes exchange data as needed to simulate the entire aggregated automation system. To visualize such an aggregated simulation, the design and test system unifies the distributed portions of the model into a unified three-dimensional presentation at a single node and animates the unified view based on data received from the nodes on which the distributed simulation is executed.

Description

Technical Field

[0001] The subject matter disclosed herein generally relates to industrial automation systems and more particularly to digital simulation of industrial systems. Background Art

[0002] At a high level, designing a new industrial automation system typically involves two separate but interrelated engineering efforts to develop the mechanical aspects on one hand and the control aspects on the other hand. Mechanical engineering can involve: selecting or designing the machines that will make up the new system (e.g., industrial robots, machining stations, conveyors, operator workstations, motion equipment, motors, pneumatic actuators, etc.); determining the appropriate positions and orientations of these machines; selecting and positioning sensors that will be used to feed status and operation data to the control equipment, etc. Based on this mechanical design, control engineers design the electrical system for both power connections and data connections, develop control code (e.g., ladder logic, sequential function charts, functional block diagrams, structured text, etc.) to be executed by one or more industrial controllers to control the behavior of the automation system, set up device configurations (e.g., motor drive parameter settings), and develop a human-machine interface (HMI) for visualizing machine status and alarms. As part of the development process, control engineers can also perform digital simulations that test the control programming for virtualization of the mechanical system (e.g., digital twins).

[0003] Given these two engineering threads, the conventional engineering workflow for designing, programming, and testing industrial automation systems typically requires the use of separate design tools for mechanical engineering and control engineering. Since there is usually no direct link between the mechanical design platform and the control design platform, changes made to the mechanical design on the CAD side must be communicated to the control engineers so that the control design can be updated accordingly if necessary. Thus, if the two engineering teams work in parallel and modify their respective designs, it can be difficult to maintain synchronization between the mechanical design and the control design. Summary of the Invention

[0004] A brief overview is given below to provide a basic understanding of some aspects described herein. This overview is neither an extensive review nor is it intended to identify key / important elements or delineate the scope of the aspects described herein. The sole purpose of this overview is to present some concepts in a brief form as a prelude to the more detailed description that follows.

[0005] In one or more embodiments, a system for presenting an industrial simulation is provided. The system includes: a node interface component configured to communicatively connect to a plurality of processing node devices that collectively perform a distributed simulation of an industrial automation system, wherein the distributed simulation includes a plurality of model parts representing respective parts of the industrial automation system, the plurality of model parts being simulated by the plurality of processing node devices respectively, and the node interface component is further configured to collect graphical data and simulation data from the plurality of processing node devices and aggregate the graphical data and the simulation data to generate unified presentation data; and a user interface component configured to present a unified presentation of the industrial automation system on a client device based on the unified presentation data.

[0006] In addition, one or more embodiments provide a method for generating a presentation of an industrial simulation. The method includes: communicatively connecting, by a system including a processor, to a plurality of processing node devices that collectively perform a distributed simulation of an industrial automation system, wherein the distributed simulation includes a plurality of model parts representing respective parts of the industrial automation system, and the plurality of model parts are simulated by the plurality of processing node devices respectively; collecting, by the system, graphical data and simulation data from the plurality of processing node devices; aggregating, by the system, the graphical data and the simulation data to generate unified presentation data; and presenting, on a client device, a unified presentation of the industrial automation system based on the unified presentation data.

[0007] In addition, according to one or more embodiments, a non-transitory computer-readable medium is provided, having instructions stored thereon that, in response to execution, cause a system to perform operations including: communicatively connecting to a plurality of processing node devices that collectively perform a distributed simulation of an industrial automation system, wherein the distributed simulation includes a plurality of model parts representing respective parts of the industrial automation system, and the plurality of model parts are simulated by the plurality of processing node devices respectively; collecting graphical data and simulation data from the plurality of processing node devices; aggregating the graphical data and the simulation data to generate unified presentation data; and presenting a unified presentation of the industrial automation system based on the unified presentation data.

[0008] To achieve the above and related purposes, certain illustrative aspects are described herein in connection with the following description and the accompanying drawings. These aspects indicate various ways in which they may be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a diagram showing the use of separate design platforms for mechanical engineering and control engineering in relation to designing an industrial automation system.

[0010] Figure 2 It is a block diagram of an example CAD system that supports marking a 3D mechanical CAD model using control aspects to facilitate the creation of a dynamic digital twin.

[0011] Figure 3 It is a block diagram of an example control design and test system that also supports marking a 3D model of an automation system using control aspects.

[0012] Figure 4 It is a diagram showing the creation of a mechanical model of an industrial automation system using a CAD system.

[0013] Figure 5 It is a diagram showing adding aspect metadata to a mechanical model to generate an enhanced digital model of an automation system.

[0014] Figure 6 It is an example interface display that can be presented by a CAD system and used to assign aspect metadata to a mechanical CAD model.

[0015] Figure 7 It is a diagram showing the creation of a main I / O list for an automation system project based on assigning aspect metadata to a mechanical model.

[0016] Figure 8 It is an illustration of an example CAD file that has been marked with aspect metadata.

[0017] Figure 9 It is a diagram showing the export of an enhanced digital model to a control design and test platform as part of a virtual commissioning process.

[0018] Figure 10 It is a diagram showing the simulation of a combined mechanical design and control design within a control design and test platform that uses an enhanced digital model to virtually mimic the behavior of a physical automation system under the control of a control program.

[0019] Figure 11 It is a diagram showing the submission of a control design update to a control design and test platform.

[0020] Figure 12 It is a diagram showing the import of an updated digital model from a control design and test platform into a CAD system.

[0021] Figure 13 It is a flowchart of an example method for developing a mechanical CAD model of an industrial automation system and configuring the model to act as a dynamic digital twin executed within a simulation platform.

[0022] Figure 14A flowchart of an example method for generating a dynamic digital twin of an automation system and an associated master I / O list in parallel with the mechanical design of the system.

[0023] Figure 15 A diagram showing the assignment of various parts of a digital model of an industrial automation system to respective processing nodes.

[0024] Figure 16 A diagram showing the scaling of a digital model of an industrial automation system across different processing nodes for distributed simulation.

[0025] Figure 17 A diagram showing the execution of a distributed simulation and the unification of the distributed simulation into a unified 3D view of the system's overall simulation.

[0026] Figure 18 A flowchart of an example method for scaling a digital model of an industrial automation system across multiple processing nodes for distributed simulation.

[0027] Figure 19 A flowchart of an example method for aggregating distributed parts of an industrial simulation into a unified presentation.

[0028] Figure 20 An example computing environment.

[0029] Figure 21 An example networking environment. Detailed Description

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

[0031] As used in this application, the terms "component", "system", "platform", "layer", "controller", "terminal", "station", "node", "interface" are intended to refer to a computer-related entity, or an entity related to or as part of an operating device having one or more specific functions, where such an entity can be hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to: a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical or magnetic storage media) including a solid state storage drive attached (e.g., screwed or bolted) or removably attached; 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 can be components. One or more components can reside within a process and / or an executing thread, and a component can be located on one computer and / or distributed between two or more computers. Further, components as described herein can execute from various computer-readable storage media having various data structures stored thereon. A component can communicate via local and / or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with a local system, another component in a distributed system, and / or across a network such as the Internet with other systems). As another example, a component can be a device having a specific function provided by a mechanical component operated by an electrical or electronic circuitry system that is operated by a software or firmware application executed by a processor, where the processor can be internal or external 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 a specific function through an electronic component without a mechanical component, and the electronic component can include a processor therein to execute software or firmware that at least partially provides the function of the electronic component. As a further example, an interface can include input / output (I / O) components and associated processors, applications, or application programming interface (API) components. Although the foregoing examples are directed to aspects of components, the illustrated aspects or features also apply to systems, platforms, interfaces, layers, controllers, terminals, etc.

[0032] As used herein, the terms "infer" and "inference" generally refer to the process of reasoning or inferring about the state of a system, environment, and / or user based on a set of observations captured via events and / or data. For example, inference can be employed to identify a particular environment or action, or a probability distribution over states can be generated. Inference can be probabilistic, i.e., a probability distribution over a state of interest is calculated based on consideration of data and events. Inference can also refer to techniques for constructing higher-level events from a set of events and / or data. Such inference results in the construction of new events or actions from a set of observed events and / or stored event data, regardless of whether the events are closely related in terms of temporal proximity and regardless of whether the events and data are from one or several event and data sources.

[0033] Additionally, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, the phrase "X employs A or B" is intended to mean any natural inclusive permutation. That is, any of the following instances satisfies the phrase "X employs A or B": X employs A; X employs B; or X employs both A and B. Further, unless otherwise specified or clear from the context that the article refers to the singular form, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more".

[0034] Furthermore, the term "set" as used herein excludes the empty set, e.g., a set with no elements. Thus, a "set" in the present subject matter disclosure includes one or more elements or entities. By way of illustration, a set of controllers includes one or more controllers; a set of data resources includes one or more data resources, etc.; similarly, the term "group" as used herein refers to a collection of one or more entities; for example, a group of nodes refers to one or more nodes.

[0035] Aspects or features will be presented in the context of a system that can include many devices, components, modules, etc. It should be understood and recognized that various systems can include additional devices, components, modules, etc., and / or various systems may not include all of the devices, components, modules, etc. discussed in conjunction with the figures. Combinations of these methods may also be used.

[0036] At a high level, designing a new industrial automation system typically involves two separate but interrelated engineering efforts to develop the mechanical aspect on one hand and the control aspect on the other. Mechanical engineering can involve: selecting or designing the machines that will make up the new system (e.g., industrial robots, machining stations, conveyors, operator workstations, motion equipment, motors, pneumatic actuators, etc.); determining the proper locations and orientations of these machines; selecting and positioning sensors that will be used to feed status and operation data to the control equipment, etc. Based on this mechanical design, control engineers design the electrical system for both power and data connections, develop control code (e.g., ladder logic, sequential function chart, functional block diagram, structured text, etc.) to be executed by one or more industrial controllers to control the behavior of the automation system, set up device configurations (e.g., motor drive parameter settings), and develop a human-machine interface (HMI) for visualizing machine status and alarms. As part of the development process, control engineers can also perform digital simulations that test the control programming for virtualization of the mechanical system (e.g., digital twin).

[0037] Given these two engineering threads, the conventional engineering workflow for designing, programming, and testing industrial automation systems typically requires the use of separate design tools for mechanical engineering and control engineering. Figure 1 is a diagram showing the use of separate design platforms for mechanical engineering and control engineering related to designing an industrial automation system. A mechanical engineer can develop a mechanical design such as a digital three-dimensional (3D) mechanical model 102 in a computer-aided design (CAD) platform 104. Based on this mechanical model 102 and knowledge of the desired operation sequence, a control engineer can design a control system - including electrical design, I / O definition, and control programming - in one or more control design platforms 106, which can include industrial controller programming applications, electrical drawing applications, device configuration applications, HMI development applications, or other such platforms. For example, a control engineer can refer to the mechanical design related to: determining a list of I / O points required to control the new automation system based on the motors, drives, actuators, safety devices, or other industrial assets present in the system; and mapping industrial controller tags to these I / O points and generating control programming to execute the desired automation sequence.

[0038] The control design platform 106 may also include a digital simulation platform that simulates the execution of a control program for a virtual model of an automation system to test control programming and mechanical design, i.e., a process known as virtual commissioning. Such a simulation platform can mimic the behavior of the mechanical assets of an automation system in response to the execution of a control program on a simulated industrial controller, enabling verification of correct operation. During the commissioning of a physical system, the completed control code, device configuration, and HMI application are downloaded to the appropriate field devices 108 of the automation system.

[0039] Since there is typically no direct link between the mechanical design platform and the control design platform, changes made to the mechanical design on the CAD side must be communicated to the control engineer so that the control design can be updated accordingly if necessary. Thus, if two engineering teams work in parallel and modify their respective designs, it may be difficult to maintain synchronization between the mechanical design and the control design. In addition, since the mechanical model 102 developed on the CAD platform 104 is not capable of being simulated and thus cannot be used for virtual commissioning, if the system design is to be tested via simulation, a virtual-simulable model (e.g., a digital twin) of the automation system must be developed separately from the mechanical CAD model 102 to test the control programming in the virtual domain prior to commissioning.

[0040] To address these and other issues, one or more embodiments of the present disclosure provide an industrial CAD system or an add-on thereto that simplifies the automation system development workflow by integrating the mechanical and control domains into the CAD platform such that the CAD becomes a common information source for both mechanical aspects and electrical and control interface information. According to one or more embodiments, the CAD system may incorporate a set of features that allow a user to use "aspects" to label or mark selected elements of a mechanical CAD drawing within the CAD environment. These aspect designators label the selected mechanical elements as a particular type of industrial asset or control element. For example, a user may label selected elements or components of a mechanical CAD model as a certain type of dynamic or kinematic joint (e.g., a sliding joint, a robotic joint, a rotary joint, a prismatic joint, a helical joint, a cylindrical joint, a planar joint, a spherical joint, etc.), a conveyor, a motor, a gripper (e.g., a mechanical gripper, a suction gripper, etc.), a mechanical load, a sensor, an actuator, or another type of industrial asset. These aspects may also define the attributes or physical geometry of the selected elements of the mechanical design.

[0041] When using these aspects to label selected components of a mechanical CAD model, the CAD platform associates simulation metadata with the selected components based on the type of aspect used to label each component. This simulation metadata defines the behavior of the selected components within a virtual simulation environment—e.g., range of motion, direction, and / or axis of motion, motion constraints, speed, force, etc.—thus transforming the mechanical CAD model into a digital model capable of simulation (e.g., a dynamic digital twin), which can be exported to a simulation and testing platform. Within the simulation and testing platform, the resulting enhanced model can be connected to a simulated industrial controller to test control logic and monitor the simulated operation of the automation system. In this way, both mechanical and simulation markup symbols can be added via the CAD platform to produce a usable simulation and emulation model of the automation system.

[0042] Figure 2 FIG. 4 is a block diagram of an example CAD system 202 that supports labeling a 3D mechanical CAD model with control aspects to facilitate the creation of a dynamic digital twin, in accordance with one or more embodiments of the present disclosure. Aspects of the systems, apparatuses, or processes described in the present disclosure may constitute machine-executable components that are included within a machine, such as one or more computer-readable media (or media) associated with one or more machines. Such components, when executed by one or more machines—such as computers, computing devices, automation devices, virtual machines, etc.—may cause the machines to perform the described operations.

[0043] The CAD system 202 may include a user interface component 204, a mechanical modeling component 206, an aspect metadata component 208, a model export component 210, a model import component 212, one or more processors 218, and a memory 220. In various embodiments, one or more of the user interface component 204, the mechanical modeling component 206, the aspect metadata component 208, the model export component 210, the model import component 212, one or more processors 318, and the memory 320 may be electrically coupled and / or communicatively coupled to each other to perform one or more of the functions of the CAD system 202. In some embodiments, the components 204, 206, 208, 210, and 212 may include software instructions stored on the memory 220 and executed by the processor 218. The CAD system 202 may also interact with Figure 2 other hardware and / or software components not depicted in FIG. 4. For example, the processor 218 may interact with one or more external user interface devices such as a keyboard, a mouse, a display monitor, a touch screen, or other such interface devices.

[0044] The 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, tactile, etc.). In some embodiments, the user interface component 204 can present an interactive display screen on a display device (e.g., a display device associated with a desktop computer, laptop computer, tablet computer, smart phone, etc.), where the display screen serves as an interface to the 3D mechanical design platform. The user interface component 204 can present optional design tools and receive design input related to the mechanical aspects of designing an industrial automation system or machine via interaction with the tools. The user interface component 204 can also present a 3D graphical representation of the automation system based on the design input. As will be described in more detail herein, the design tools available to the user interface component 204 include a set of automation aspects that can be selectively associated with the mechanical elements or components of the automation system being designed. The alternative aspects are based on aspect definitions 222 maintained on the memory 220, and the aspect definitions 222 define the available aspects and the associated simulation data for the corresponding aspects, which can be used by the simulation platform to simulate the operation or behavior of the aspects within the industrial simulation environment.

[0045] The mechanical modeling component 206 can be configured to generate a three-dimensional mechanical model of an automation system or machine based on design input provided by the user via the user interface component 204. The aspect metadata component 208 can be configured to assign aspect metadata to selected elements of the mechanical model according to the design input received from the user. As will be described in more detail herein, the aspect metadata labels the selected elements as a particular type of industrial component or machine (e.g., a particular type of joint, motor, sensor, conveyor, etc.) or labels the selected elements as having a particular physical geometry or behavior. The aspect metadata assigned to a given element is obtained from one or more of the aspect definitions 222, and the one or more aspect definitions 222 correspond to the respective one or more aspects assigned to the element. Adding the aspect metadata to the mechanical model can result in an enhanced mechanical model (e.g., a dynamic digital twin) of the automation system, which can be executed within the simulation platform to mimic the behavior of the automation system under the control of an industrial control program.

[0046] The model export component 210 can be configured to export the enhanced mechanical model to an external system, such as a control design platform or a simulation platform. The model import component 212 can be configured to import the enhanced mechanical model from such an external system. In some cases, the enhanced mechanical model or its associated aspect metadata may have been modified by the external system. These modifications are maintained with the model and thus imported back into the CAD system 202 with the model, thereby maintaining the synchronization between mechanical engineering and control engineering.

[0047] One or more processors 218 may perform one or more of the functions described herein with reference to the disclosed systems and / or methods. The memory 220 may be a computer-readable storage medium storing computer-executable instructions and / or information for performing the functions described herein with reference to the disclosed systems and / or methods.

[0048] Figure 3 is a block diagram of an example control design and test system 302 that also supports tagging a 3D model of an automation system with control aspects. The control design and test system 302 may include a user interface component 304, a simulation component 306, a controller emulation component 308, an aspect metadata component 310, a model import component 312, a model deployment component 314, a node interface component 316, one or more processors 318, and a memory 320. In various embodiments, one or more of the user interface component 304, the simulation component 306, the controller emulation component 308, the aspect metadata component 310, the model import component 312, the model deployment component 314, the node interface component 316, one or more processors 318, and the memory 320 may be electrically coupled and / or communicatively coupled to each other to perform one or more of the functions of the control design and test system 302. In some embodiments, the components 304, 306, 308, 310, 312, 314, and 316 may include software instructions stored on the memory 320 and executed by the processor 318. The control design and test system 302 may also interact with Figure 3 other hardware components and / or software components not depicted in. For example, the processor 318 may interact with one or more external user interface devices such as a keyboard, a mouse, a display monitor, a touch screen, or other such interface devices.

[0049] The user interface component 304 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, the user interface component 304 can present an interactive display screen on a display device (e.g., a display device associated with a desktop computer, laptop computer, tablet computer, smartphone, etc.), where the display screen serves as an interface for controlling the design and / or simulation platform. The user interface can display a virtual 3D simulation of an automated system that is testing an emulated industrial control program, and present operational statistics representing the expected performance of the automated system based on the simulation and other such information. In some embodiments, the user interface component 304 can also present optional design tools and receive design inputs related to configuring aspects of industrial automation (e.g., I / O connections between devices of the virtual system and an industrial controller) via interaction with the tools. Similar to the CAD system 202 described above, the design tools available to the user interface component 304 can include a set of automation aspects that can be selectively associated with the mechanical elements or components of the automated system being designed. The available aspects are based on aspect definitions 322 maintained on the memory 320, and the aspect definitions 322 define the available aspects and the associated simulation data for the corresponding aspects, which can be used by the simulation platform to simulate the operation or behavior of the aspects within the environment of an industrial simulation.

[0050] The simulation component 306 can be configured to: simulate the operation of a virtualized model of an industrial automation system under the control of an industrial control program. The controller simulation component 308 can be configured to simulate the execution of an industrial control program being tested on a virtualized (or emulated) industrial controller.

[0051] The aspect metadata component 310 can be configured to assign aspect metadata to selected elements of a digital model of an automated system based on design inputs received from the user (similar to the aspect metadata component 208 of the CAD system 202). The aspect metadata component 310 can also receive node specification inputs that specify portions of the digital model to be executed on various different processing node devices. The model import component 212 can be configured to import a mechanical CAD model of the automated system or another type of digital model of the system.

[0052] The model deployment component 314 can be configured to partition the digital model into portions based on the node specification inputs and deploy the model portions to various different processing node devices to facilitate distributed simulation of the model. The node interface component 316 can be configured to aggregate graphical and simulation data from the distributed processing node devices into a unified three-dimensional presentation of the simulation.

[0053] One or more processors 318 may perform one or more of the functions described herein with reference to the disclosed systems and / or methods. The memory 320 may be a computer-readable storage medium storing computer-executable instructions and / or information for performing the functions described herein with reference to the disclosed systems and / or methods.

[0054] Figure 4 FIG. is a diagram showing the creation of a mechanical model of an industrial automation system using a CAD system 202. In some embodiments, the CAD system 202 may be executed on a client device such as a desktop computer, laptop computer, tablet computer, mobile device, wearable AR / VR appliance, etc. In other embodiments, the CAD system 202 may be executed on a cloud platform or another high-level platform accessible to multiple users authorized to access the system 202. In such embodiments, the client device may remotely access the design tools of the CAD system and utilize these tools to develop the mechanical model of the automation system being designed.

[0055] The user interface component 204 may present a graphical interface display via the display hardware of the client device. Through interaction with these interface displays, the user may submit mechanical design inputs 404 specifying the mechanical aspects of the automation system being designed. For example, the mechanical design inputs 404 may specify three-dimensional shapes representing mechanical structures or devices to be included in the mechanical design. These shapes may graphically represent such industrial assets as industrial robots, conveyors, machine tools, motors, motor drives, sensors, pipelines, ducts, platforms, safety gates and fences, control cabinets, or other such assets. The mechanical design inputs 404 may also specify the positions and orientations of these graphical representations relative to each other, physical connections between mechanical elements, or other such mechanical properties and relationships. The mechanical modeling component 206 generates a 3D mechanical model 402 of the automation system (e.g., machine assembly, production line, etc.) based on the graphical representations and their relationships defined by the mechanical design inputs 404.

[0056] According to various embodiments, mechanical design inputs 404 can be submitted via the user interface component 204 in any suitable format. For example, the graphical interface display presented by the user interface component 204 can include: a workspace or canvas on which a mechanical model 402 is presented; and an associated toolbar from which the user can select 2D or 3D drawing tools or predefined shapes or components to include in the model 402. In some embodiments, a shape representing a mechanical component can be dragged from the toolbar into the main workspace, or otherwise added to the workspace for placement and orientation in the model 402. The shapes or collections of shapes in the workspace can be manipulated via interaction with the graphical interface. For example, a designer can interact with a selected shape, a collection of shapes, or the entire model 402 to rotate, link, or reposition the shape within the virtual three-dimensional space. Additions or modifications to the mechanical model 402 are stored within a CAD file (e.g., a part or component file) representing the model 402.

[0057] The resulting mechanical model 402 encodes the mechanical layout of the automation system being designed. However, at this stage, the mechanical model 402 is essentially just a three-dimensional technical drawing suitable for use as a guide for building and installing the automation system. Control engineers responsible for designing the electrical and control systems of the automation system can also refer to this model 402 to coordinate the development of the controller I / O list required to monitor and control the new system, design the power distribution lines for supplying power to the system, and generate control programming. Conventionally, if a control engineer wishes to test the control programming by simulating the operation of the automation system under the control of a program within the environment of a simulation system, a digital model of the automation system that can be simulated (e.g., a digital twin) must be developed separately and linked to the simulation controller executing the control program.

[0058] To simplify this workflow and generate a digital twin of the automation system more quickly, embodiments of the CAD system 202 allow users to enhance the completed mechanical model 402 with aspect metadata that transforms the mechanical model 402 into a digital model of the automation system that can be executed within a simulation platform to mimic the operation of the system. Figure 5 FIG. is a diagram showing the addition of aspect metadata 508 to the mechanical model 402 to produce an enhanced digital model 502 of the automation system. In one or more embodiments, the graphical interface display presented by the user interface component 204 can include one or more toolbars for adding aspect metadata to selected elements or components of the mechanical model 402. The aspects available for selection are based on aspect definitions 222 stored on the CAD system 202 (e.g., stored in the memory 220).

[0059] Each aspect definition 222 defines a set of physical, kinematic, or mechatronic properties that indicate how that aspect behaves in a simulation environment. The properties defined by the aspect definition 222 essentially reflect the physical behavior and characteristics of the corresponding physical aspects in the real world. The CAD system 202 classifies the aspect definitions 222 according to the type of mechanical component, control component, or device for which the physical properties are defined. The aspect toolbar presented by the user interface component 204 lists the available aspects for the user to select according to these classifications. Example aspects that can be selected and applied to the mechanical model 402 include, but are not limited to: various types of dynamic or kinematic joints (e.g., sliding joints, rotating joints, robotic arm joints, hinges, etc.), moving surfaces such as conveyors, motors, grippers (e.g., suction grippers, mechanical grippers, etc.), sensors, pneumatic or hydraulic actuators (e.g., pusher arms, stoppers, etc.), rollers, or other such elements of the mechanical system.

[0060] The catalog of aspect definitions 222 can also include various types of robotic end effectors (e.g., mechanical grippers, suction grippers, etc.). The end effector aspect definition 222 can define physical properties (e.g., 3D physical constraints) for its corresponding gripper type, which can be used on the control simulation side to more accurately mimic the operation of the robotic part handling behavior at a low level of abstraction. For example, the suction gripper aspect applied to the representation of the robot defined in the mechanical model 402 can indicate to the simulation platform that the end effector of the robot is to be modeled as a suction gripper, so that the product near the suction gripper can be assumed to have been gripped by the robot (via suction), and can then be moved in coordination with the robotic arm to simulate the movement of the part caused by the robot. In contrast, the mechanical gripper aspect may imply a more complex physical process related to the movement of the part caused by the gripper. In the case of the mechanical gripper aspect, the constraints of the physical engine can be used to determine whether the side of the gripper contacts the corresponding side of the product at an appropriate position and angle before allowing the part to move in coordination with the robot (due to the friction between the gripper arm and the product surface).

[0061] Some aspect definitions 222 can also define the physical geometry or properties that can be associated with the selected elements of the mechanical model 402. Each aspect can also designate the selected machine defined within the mechanical model 402 as a load creator that introduces a product with a specified shape and physical behavior (e.g., collision physics) into the automation system; e.g., via a conveyor feeding the system.

[0062] The process of adding aspect metadata 508 to the mechanical model 402 involves tagging a selected mechanical component or device represented by the mechanical model 402 as one of the available control aspects (represented by one of the aspect definitions 222). This aspect of the tagging workflow can be performed by submitting aspect specification input 504 via an interaction displayed through a graphical interface presented by the user interface component 204. For example, a user can select the type of a robotic joint as an aspect from an aspect toolbar and then select the element in the mechanical model 402 to be tagged as that type of joint. In response to these selections, the aspect metadata component 208 associates the aspect metadata 508 for the selected type of robotic joint with the indicated component of the mechanical model 402, thereby converting the static mechanical representation of the joint into an active virtual control element whose behavior can be virtually simulated within the simulation platform. The aspect metadata 508 assigned to the selected mechanical component is derived from the aspect definition 222 corresponding to the indicated type of aspect.

[0063] The aspect metadata 508 can substantially define any type of information that can be recognized and utilized by the simulation platform to accurately model the runtime movement or behavior of the corresponding mechanical component in response to control inputs or simulated forces. Depending on the aspect, the aspect metadata 508 can include default fixed values or properties that can be globally applied to all instances of the aspect and user-defined metadata that can be customized by the user to conform to the characteristics of the user's system. Figure 6 Is an example interface display 602 that can be presented by the user interface component 204 and used to assign aspect metadata 508 to the mechanical CAD model 402. In this example, the interface display 602 includes a main workspace 606 on which a 3D CAD representation 608 of the mechanical model 402 of the automated system being designed is presented. The interface display 602 can present an aspect toolbar 604 above the main workspace 606 in response to a selection of a control aspect tab 630. The aspect toolbar 604 displays a number of selectable options representing control aspects or categories of aspects that can be selected and added to the model via an interaction with the CAD representation 608 (e.g., control panels, conveyors, dynamic joints, end effectors, kinematic joints, loads, motors, physical properties, physical geometries, physical groups, sensors, etc.).

[0064] At Figure 6In the depicted example, a portion of the CAD representation 608 of conveyor 612 is to be marked as having a "straight conveyor" aspect, identifying this component of the mechanical model 402 as a conveyor and associating simulation metadata with the representation of conveyor 612, which representation can be used by a separate simulation platform to accurately simulate the behavior of conveyor 612. To assign this aspect, the user can interact with the interface display 602 to select the "straight conveyor" option from the drop-down selection 632 of conveyors in the aspect toolbar 604, and then select the representation of conveyor 612 in the CAD representation 608 (the visualization of the mechanical model 402). In response to these selections, an aspect metadata panel is presented on the left side of the main workspace 606, which aspect metadata panel lists a number of fields 614 to 628 for entering user-definable metadata values. These user-definable metadata values are values in addition to the fixed global aspect metadata values associated with the "straight conveyor" aspect, which are also associated with conveyor 612.

[0065] Generally, the list of available user-definable aspect metadata values presented by the user interface component 204 is based on the particular aspect selected. In this way, when the user assigns an aspect to a component of the mechanical model 402, the user interface component 204 prompts the user to enter the values of any user-defined metadata fields that can be used for the selected aspect. In the example shown, the user-definable aspect metadata 508 for the conveyor can include definitions for the front edge 614 and the rear edge 616 of conveyor 612 - which can be automatically identified by the aspect metadata component 208 based on the shape of the mechanical conveyor representation to which the conveyor aspect is assigned, or can be explicitly identified by the user (e.g., by selecting the front and rear edges to indicate their positions). Additionally, the user interface component 204 can prompt the user to enter such user-definable conveyor aspect metadata values as, for example, the operating speed 618, acceleration 620, or deceleration 622 of the conveyor. The user can also be prompted to specify the material of the belt used to convey products along the conveyor 624, which can affect the simulated traversal of products along the conveyor based on the coefficient of friction or other physical properties of the material. The control mode 626 for conveyor 612 (e.g., on-off control, variable speed control, etc.) can also be requested.

[0066] Similar workflows and graphical interfaces to the Figure 6 workflow and graphical interface shown can be used to assign selected aspect metadata to other types of automated system components. According to another example, the aspect metadata 508 for a pneumatic pusher arm can define the direction, starting position, and range of movement of the linear movement of the pusher arm within the three-dimensional coordinate system of the mechanical model 402. The user interface component 204 can also prompt the user to provide a user-defined metadata value for the movement speed of the pusher at startup.

[0067] Some aspect definitions 222 (and the corresponding aspect metadata 508 derived from these definitions 222) can also define the physical characteristics or constraints of the selected mechanical components, and these characteristics and constraints can subsequently be referenced by the simulation platform to accurately simulate the movement and behavior of the components. These characteristics can include, but are not limited to: gear diameter, gear ratio, coefficient of friction, inertia, motion constraints (e.g., known axes of motion and their corresponding motion constraints for a particular type of robot), or other such data. Depending on the type of aspect, some of these aspect metadata values can be user-defined, while other aspect metadata values can be fixed global characteristics that are expected to apply to all instances of that aspect. Some aspect definitions 222 can also define executable scripts that can be executed by a separate simulation platform and applied to the associated elements of the mechanical model 402 (e.g., elements marked by the user with the corresponding aspect), causing the element to mimic the behavior of its corresponding physical component within the simulation environment.

[0068] Some aspect definitions 222 can also specify control I / O interfaces for their corresponding assets. For example, assigning the aspect metadata 508 of a sensor (e.g., light eye, proximity switch, etc.) to a selected element of the digital model 402 representing the sensor can specify the selected element as a digital input device that provides a digital input value to an industrial controller in response to detecting an object within the detection range of the sensor. In this scenario, the detection range can be a user-defined aspect metadata value. In another example, the aspect metadata 508 for the type of pusher arm can specify that the arm requires digital controller outputs to control the forward and retracted states of the pusher arm (e.g., forward is ON, retracted is OFF), and requires two digital inputs to read the states of two corresponding proximity switches at the extreme ends of the travel of the pusher arm, thereby detecting when the arm is in the fully forward or fully retracted state. Generally, the aspect definitions 222 of system components with known or expected I / O for docking with an industrial controller can define the inputs and / or outputs (analog and digital) required to monitor and / or control these system components. When ready to simulate the model 502 within the simulation and test platform, this I / O information can facilitate enhancing the connection between the digital model 502 and the simulated controller.

[0069] In addition, in some embodiments, when an aspect with an associated I / O definition is added to the mechanical model 402, the aspect metadata component 208 can automatically populate the aggregated list of system I / O using the I / O points defined by the corresponding aspect definition 222. Figure 7FIG. is a diagram showing the creation of a master I / O list 702 for an automated system project based on the assignment of aspect metadata 508 to a mechanical model 402. When aspects are selectively assigned to elements of the mechanical model 402 as described above, the aspect metadata component 208 determines whether the aspect definition 222 corresponding to the aspect defines an input or output for the aspect. In addition to assigning aspect metadata 508 to the mechanical model 402, any aspect I / O 706 defined in the aspect definition 222 is added to the master I / O list 702 of the automated system. The master I / O list 702 can be presented in a human-readable format and referenced by a control engineer when designing a control system and associated control logic. For example, the master I / O list 702 can populate a tag browser within a simulation platform that allows a user to selectively associate virtual machine I / O with corresponding controller I / O points.

[0070] In some embodiments, the master I / O list 702 can be integrated with or otherwise stored with the enhanced digital model 502 of the automated system such that the I / O list 702 is transmitted with the model 502. Thus, the enhanced digital model 502 includes not only the 3D layout of the new system, but also the I / O mapping of the entire system. The master I / O list 702 can be generated prior to the start of the design of the control system based on the specified aspect metadata 508, thereby providing useful design constraints (i.e., the I / O required to operate the automated system) to the control engineer.

[0071] Some aspect metadata 508 can also designate components of the mechanical model 402 as load sources that introduce discrete items of a product (e.g., boxes, luggage, manufactured parts, fluid materials, or other such products) into the system. When a load source aspect marker is applied to an element of the mechanical model 402, the user interface component 204 can prompt the user to provide user-defined operating parameters for the designated load source, such as the rate at which the product is introduced into the system, the shape of the product (e.g., a box or cylinder having specified dimensions, an item made of a flexible material and having a randomly variable shape, etc.), the collision physics properties associated with the product, or other such characteristics. When the enhanced digital model 502 is subsequently imported into the simulation platform, the simulation platform simulates the release of product items through the marked load source based on the load source aspect metadata 508.

[0072] In some embodiments, the functionality for marking a 3D mechanical model 402 with aspect metadata 508 as described above can be added to an existing CAD application as a plug-in or add-on. In such embodiments, the installation of the aspect metadata add-on enables a new aspect toolbar or ribbon - for example, Figure 6The aspect toolbar 604 shown in - is added to the existing development interface of the CAD application and loads the aspect definition 222 into the CAD application. The new toolbar lists the aspects that can be used to label the mechanical model 402 developed using the native drawing and development tools of the CAD application. In this way, the process of converting a mechanical CAD model into a dynamic digital twin via aspect tagging can be easily integrated into the existing design workflow that has been executed on the CAD platform. Similarly, although the above example assumes that the mechanical model 402 is created in the same CAD system 202 in which the model 402 is tagged with aspect metadata 508, some embodiments may import mechanical models developed in a separate CAD platform and allow the user to label these imported mechanical models with aspect metadata 508 to facilitate the creation of a dynamic digital twin.

[0073] In addition, some embodiments may allow a user (e.g., an asset owner, an original equipment manufacturer, a system integrator, etc.) to use user-defined aspect definitions 222 to extend the available aspects that can be applied to a CAD model. Thus, in addition to the catalog of available aspect designations supported by the add-on (as defined by the aspect definition 222), the user may develop and add their own aspects - including associated simulation attributes - and add their own aspects to the aspect toolbar, where the user-defined aspects may be selected and added to the mechanical CAD model 402 as aspect metadata 508. In this way, the CAD system 202 can support the definition of company-specific control components in addition to the definition of industry-specific control components.

[0074] When an element of the mechanical CAD model 402 is tagged with an aspect as described above, the aspect metadata 406 defined by the aspect is associated with the CAD entity identifier of the selected element. Figure 8 is an illustration of an example CAD file 802 that has been labeled with aspect metadata 508. Generally, each element of a mechanical CAD drawing or model has an associated unique CAD entity identifier (ID) 804, and the attributes 808 of the element (e.g., size, color, orientation, location, etc.) are associated with the CAD entity identifier 804. The type 806 of the element (e.g., sphere, cube, line, etc.) is also defined for each entity ID 804. These entity IDs 804 are typically inherent in the existing CAD framework of the CAD platform, and the CAD file 802 of a given CAD model 402 includes the entity IDs 804 of the elements that make up the model 402.

[0075] When a user marks selected components of a mechanical model 402 using the aspects described above, aspect metadata 508 of the selected aspects is added to the CAD file 802 of the model in association with the entity ID 804 of the selected components. Since the aspect metadata 508 is associated with the local entity ID 804 of the CAD file, the aspect metadata 508 is retained within the CAD file 802 itself rather than in a separate file and is thus transmitted together with the CAD file 802. In this way, the CAD file 802 of the model can be imported into substantially any simulation platform as an enhanced digital model 502 capable of being simulated by an automation system, and the aspect metadata 508 for each entity ID 804 causes the corresponding components of the model 402 to be recognized by the simulation platform as control components or activation components.

[0076] As described above, using aspect metadata 508 to label a mechanical model 402 results in an enhanced digital model 502 of the automation system being designed, which can be exported to a separate simulation platform for virtual commissioning. Figure 9 FIG. is a diagram showing the export of an enhanced digital model 502 to a control design and test system 302 as part of a virtual commissioning process. Once the mechanical model 402 has been labeled using aspect metadata 508, the resulting enhanced digital model 502 can be exported to a separate control design and test system 302 using the model export component 210 of the CAD system. In an example embodiment, the graphical interface of the CAD system may include an optional export function that, when selected, causes the model export component 210 to export the digital model - including its embedded aspect metadata and main I / O list 702 - to the design and test system 302. As an alternative to directly exporting the model 502 to the test system 302, the model export component 210 can export the digital model 502 to a file having a format that can subsequently be imported into the test system 302 (e.g., via the model import component 312 of the test system).

[0077] In this example, the control design and test system 302 includes a controller simulation component 308 that simulates the execution of an industrial control program being tested on a virtualized (or simulated) industrial controller, and a simulation component 306 that simulates the operation of a virtualized model of an industrial automation system under the control of the industrial control program. Within the control design and test system 302, an enhanced digital model 502 of the automation system (including a mechanical model 402 enhanced with aspect metadata 508 and a master I / O list 702) can be interfaced with control programming (e.g., ladder logic), which allows both the mechanical design and the control design to be virtually simulated and tested before finalizing the overall design and proceeding to the build and installation phase, where the control programming is developed for the automation system to create a virtual test environment. Figure 10 FIG. Figure 10 is a diagram showing the simulation of a combined mechanical design and control design within a control design and test system 302 that uses an enhanced digital model 502 to virtually mimic the behavior of a physical automation system under the control of a control program 1008. The aspect metadata 508 applied to selected elements of the mechanical model 402 as described above causes those elements to be recognized by the simulation component 306 of the test platform as control elements or activation elements, and indicates how the simulation component 306 is to behave with respect to each element in response to control and physical stimuli within the simulation environment.

[0078] Since the enhanced digital model 502 models the mechanical characteristics of the automation system and the behavioral attributes of the components that make up the model (by means of aspect metadata 508), the enhanced digital model 502 can be used to simulate the expected operation and behavior of the automation system under the control of a simulated control program 1008. This can include viewing and verifying the response of the simulated system to control inputs in terms of movement, speed, flow, temperature, fill level, movement of products through the system, etc. In Figure 10 the example depicted in FIG. Figure 10 , the controller simulation component 308 of the test system 302 acts as an industrial controller emulator to execute the control program 1008, which is developed and tested against the virtual model 502 of the automation system created within the CAD system 202.

[0079] The simulation component 306 can utilize the mechanical characteristics and associated aspect metadata 508 encoded in the enhanced digital model 502 to simulate the operational aspects of an automated system to be monitored and regulated by the control program 1008. To achieve this, a user (e.g., a control engineer) can virtually dock the control program 1008 with the enhanced digital model 502 to facilitate the exchange of simulated I / O data between the program 1008 and the digital model 502, thereby simulating the real-world control and operation of the automated system. To this end, a developer can use the configuration tools of the test platform (e.g., a tag browser) to selectively map the controller I / O defined by the control program 1008 to the I / O of the active control elements of the enhanced digital model 502 (i.e., the control elements marked with aspect metadata 508 designate these elements as having associated inputs and outputs available for docking with the I / O of an industrial controller, as recorded by the master I / O list 702). In an example scenario, a control engineer can define PLC tags and I / O addresses that drive motors, actuators, or other components defined in the mechanical model 402 and selectively link the tags and associated I / O addresses to the I / O points defined for the modeled components. This I / O mapping between the control program 1008 and the digital model 502, which is part of the overall automated system design, can be stored as PLC connection data 1006 in a properly formatted file (e.g., a spreadsheet or another type of file) and integrated with the digital model 502. Thus, in addition to the mechanical design aspects, the digital model 502 also maintains this aspect of the control design.

[0080] The control program 1008 can include any conceivable type of code for processing input signals read into the controller and controlling output signals from the controller - including but not limited to ladder logic, sequential function charts, function block diagrams, or structured text - and is designed to regulate the automation system modeled by the digital model 502. During simulation, the simulation component 306 generates digital and analog I / O values based on the static and dynamic characteristics of the physical system represented by the digital model 502, and these digital and analog I / O values represent, for example, sensor outputs, metering outputs, or other plant data similar to the data expected to be generated by the physical system. This simulated output data 1004 is provided to the simulation component 308 that executes the control program 1008, and the simulation component 308 receives this data 1004 as one or more virtual physical inputs. The control program 1008 processes these inputs according to a user-defined algorithm and generates digital and / or analog controller output data 1002 based on this processing. This output data 1002 represents the physical outputs (e.g., PID loop control outputs, solenoid excitation outputs, motor control outputs, actuator control outputs, robot control outputs, etc.) that would be generated by the controller executing the control program 1008 and sent to the hardwired field devices including the automation system. According to the user-defined I / O mapping, the controller output data 1002 is provided to the appropriate input points of the digital model 502.

[0081] In addition to generating the simulated output data 1004, the simulation component 306 also generates system response data 1018 based on an analysis of the expected behavior of the modeled automation system in response to the simulated controller output data 1002 and the simulated data exchange. The simulation component 306 estimates and simulates the response of the virtual automation system to the simulated controller outputs (and the timing of these outputs) based on the constraints defined by the aspect metadata 508 associated with the corresponding control elements of the digital model 402, as well as the behavioral and physical properties. For example, based on the mechanical and behavioral characteristics of the industrial components (e.g., conveyors, industrial robots, machines, simulated products, etc.) modeled by the enhanced digital model 502 as represented by the aspect metadata 508, the simulation component 306 can predict the expected behavior of the modeled industrial components and the behavior of the products manufactured, processed, or manipulated by the components in response to the controller output data 1002, and transmit this predicted behavior as the system response data 1018. Example behaviors represented by the system response data 1018 can include but are not limited to the movement and trajectories of industrial robots, the movement of products through the simulated automation system (including speed, acceleration, position, lag, collisions, gripper failures, etc.), the flow rate of fluids through the system, the expected energy consumption of the system, the expected degradation rate of the mechanical components of the system (partially based on the friction coefficient information defined in the enhanced digital model 502), the expected forces applied to the various components of the system during operation, or other such behaviors.

[0082] In the case of industrial robots having end effectors for gripping and moving items of a product (e.g., for stacking or piling product items, moving an item from one conveyor to another, etc.), the simulated interaction between these robots and the product can depend in part on the type of gripper aspect metadata 508 associated with the end effector of the robot. For example, as described above, the suction gripper aspect metadata 508 can indicate to the simulation component 306 that it can be assumed that the product near the suction gripper has been gripped by the robot as long as the suction actuator is properly aligned over the part, and can then be moved with the robot arm to simulate the movement of the part by the robot until the part is released. Alternatively, the mechanical gripper aspect metadata 508 can define more involved physical properties to be considered by the simulation component 306 before it can be assumed that the part has been firmly gripped by the robot. This can include determining whether the two arms of the gripper contact the respective sides of the product and are at an appropriate angle or orientation when the actuator is in the gripping position, before allowing the product to move with the robot. Since the firm gripping of the product by the mechanical gripper depends on the proper alignment of the product when it enters the pick-up station (where the robot grips the part) and the relative alignment of the product with the robot's gripper at the time of pick-up, the simulation component 306 can evaluate these factors during the simulation to determine whether the product has been properly gripped, or alternatively to determine whether a mis-grip may occur due to misalignment. Instructions on how to properly evaluate this gripping behavior can be provided by the mechanical gripper aspect metadata 508 assigned to the robot.

[0083] As described above, one or more components of the mechanical model 402 can be tagged with aspect metadata 508 that designates these components as load sources. Based on this load source aspect metadata, the simulation component 306 can identify these components of the model as load sources that introduce products (e.g., manufactured parts, boxes, bottles, fluid materials, etc.) into the tested automation system and animate these components to simulate the release of the products according to the metadata. The default and user-defined metadata parameters assigned to these components can define the frequency at which the products are released, the product type (e.g., discrete solid items or liquid materials), the shape of the products (e.g., boxes with specified dimensions, spherical objects, items with a random amorphous shape due to the flexible material of the manufactured item, etc.), the speed at which the products traverse the system, and so on. The movement of these products through the simulated automation system can also be based on conveyor aspect metadata associated with the conveyor representation on which the products move (e.g., the speed of the conveyor, the material of the belt used to convey the products, etc.). The simulation component 306 can also simulate predicted collisions between product items or between products and machines (e.g., collisions with pusher arms or robot arms due to untimely control sequences). The effects of these collisions can be predicted and simulated based on physical rules and geometries modeled in part by the aspect metadata 508. The simulation component 306 can also use the physical rules defined by the aspect metadata 508 to determine whether a mechanical gripper has properly gripped a product item or whether some or all of the product items might fall due to improper gripping.

[0084] A user interface component 304 associated with the test system 302 can generate a visualization 1014 that presents the results of the simulation on a client device. The visualization 1014 can present a graphical representation of the automation system based on the enhanced digital model 502 and animate the graphical representation based on the system response data 1018 and / or statistical information from other computations related to the simulation session, thereby producing a three-dimensional visual demonstration of the automation system in operation. Some of the simulation data can also be presented on the visualization 1014 as an alphanumeric overlay. This simulation technique can be used to test and debug control programs without putting field equipment and machines at risk, to test modifications to machine operations and estimate how such modifications affect certain key performance indicators or financial metrics, or to perform other types of analysis.

[0085] In some embodiments, the user can control the speed of the simulation at a high level of granularity. For example, the user can choose to perform the simulation in real time, such a simulation depicting the operation of the automation system as it would occur in real time. Alternatively, the user can selectively choose to perform some or all stages of the control sequence or processing of the simulation faster than real time according to a user-specified time base. This causes the simulation and its associated analysis to occur within a compressed time frame.

[0086] In the illustrated example, the control design and test system 302 can allow a user to add or modify aspects of a control design. This can include implementing and testing modifications to the control program 1008 based on simulation observations. Some control design modifications submitted via the control design and test system 302 can also be directed at enhancing the digital model 502. Figure 11 FIG. is a diagram showing the submission of control design updates to the control design and test system 302. During the process of testing and debugging, a control engineer can submit a control design input 1106 via the user interface component 304 of the test platform. The control design input 1106 can include: additions or modifications to the control program 1008 being tested against the enhanced digital model 502, modifications to the I / O mapping between the model 502 and the control program 1008, updates to the master I / O list 702 to add new I / O points or delete unnecessary I / O points, or other such modifications, some of which may affect the enhanced digital model 502 or its associated metadata 508.

[0087] In some embodiments, the control design and test system 302 can also include an aspect metadata component 310 (see Figure 3 ), which supports the addition or modification of aspect metadata 508 in a manner similar to the CAD-side aspect metadata component 310. The workflow for adding or modifying aspect metadata 508 to the model 502 in the control design and test system 302 can be similar to the workflow for adding or modifying aspect metadata 508 on the CAD side. That is, the interface display presented by the user interface component 340 (e.g., visualization 1014) can include an aspect toolbar similar to Figure 6 the toolbar 604 shown in, which can be used to add new aspect metadata to the model 502. User-defined aspect metadata values for a given mechanical element can also be modified by: selecting the mechanical element on the graphical representation of the model 502 to invoke the user-defined aspect metadata fields for that element, thereby allowing the user to modify any available user-defined values (including values that may have been added and set in the CAD system 202).

[0088] To facilitate synchronization between mechanical engineering work and control engineering work, some embodiments of the CAD system 202 and the control design and test system 302 may support the round-tripping of engineering data between the two systems. According to this round-tripping method, as discussed above, mechanical design information and associated control aspects can be marked on the CAD system 202, and the resulting simulatable model 502 can be exported to the control design and test system 302. Within the control design and test system 302, the control program 1008 being tested can be used to simulate the enhanced digital model 502 - a mechanical model 402 enhanced with aspect metadata 508 and further enhanced with PLC connection data 1006 and the main I / O list 702. During testing and debugging, the control engineer can submit control design inputs 1106 that require modifications 1102 to the enhanced digital model 502, its associated aspect metadata 508, PLC connection data 1006, or the main I / O list 702, which were originally developed on the CAD system 202.

[0089] As Figure 12 shown, after implementing these modifications on the control test side, the updated model 502 - including any modifications made to the aspect metadata 508, PLC connection data 1006, or the main I / O list 702 - can be imported back into the CAD system 202 by the model import component 212 of the CAD system. In one or more embodiments, a user of the CAD system 202 can import the updated model 502 by selecting an import tool available on the interface display of the CAD system by the user interface component 204. After the modified model 502 has been imported, the CAD system 202 detects the changes or additions made by the control engineer on the control design and test system 302, including PLC connection data 1106, updates to the aspect metadata 508, and updates to the main I / O list 702. Thus, the design inputs submitted by the mechanical engineer and the control engineer via their respective development platforms are easily shared between the two engineering groups. This two-way transfer of design information ensures that the mechanical and control design data remain synchronized, allowing for continuous iteration between the machine design and the design of the control system that controls these mechanical aspects. This improved design workflow facilitates two-way synchronization between the engineering work done on the simulation / control side and the engineering work done on the CAD / mechanical side, with CAD being the focus of the two engineering threads.

[0090] In some embodiments, changes made to model 502 can be version controlled by CAD system 202. For example, CAD system 202 can include tools for recording the changes made to model 402 and the reasons for making the changes (such as being submitted by a user). Similar version control features can also be supported by control design and test system 302.

[0091] By integrating the ability to add aspect metadata into the mechanical models within the CAD system itself, embodiments of the present disclosure can provide engineers with tools to quickly and easily generate a dynamic digital twin of the automated system being designed, without having to separately develop a simulation-ready model from scratch. Since in some embodiments, the aspect metadata tool can be added to an existing CAD system as a modular add-on, the process of using aspect metadata to label mechanical models to produce a digital twin can be intuitively integrated into the existing mechanical design workflow. Additionally, by supporting two-way transfer of design data between the mechanical engineering platform and the control engineering platform, embodiments of the present disclosure can facilitate synchronization between the two engineering threads, where the enhanced CAD model serves as a common source of the latest design information across the two engineering disciplines.

[0092] Figures 13 to 14 Various methods in accordance with one or more embodiments of the present application are shown. Although for purposes of simplified explanation, one or more of the methods shown herein are shown and described as a series of acts, it should be understood and appreciated that the claimed invention is not limited by the order of the acts, since according to the invention, some acts may occur in a different order than shown and described herein and / or concurrently with other acts. For example, those skilled in the art will understand and appreciate that a method may alternatively be represented as a series of interrelated states or events, such as being represented in a state diagram. Additionally, not all of the acts shown may be required to implement the method according to the claimed invention. Further, when different entities perform different parts of the method, an interaction diagram may represent the method or manner in accordance with the subject matter disclosed herein. Still further, two or more of the disclosed example methods may be implemented in combination with one another to achieve one or more of the features or advantages described herein.

[0093] Figure 13Illustrated is an example method 1300 for developing a mechanical CAD model for an industrial automation system and configuring the model to be used as a dynamic digital twin for execution within a simulation platform. Initially, at 1302, mechanical design inputs are received by a CAD platform. In an example implementation, the mechanical design inputs submitted via interaction with the graphical development interface of the CAD platform specify the mechanical properties of the automation system in accordance with the three-dimensional shape representing the mechanical structure, machine, or equipment to be included in the mechanical design. Generally, the mechanical design inputs can define the automation system as a mechanical assembly that includes industrial assets such as industrial robots, conveyors, machining machines, motors, motor drives, sensors, pipes, conduits, platforms, safety doors and fences, control cabinets, or other such assets. The mechanical design inputs also define the relative positions, orientations, and physical relationships between these assets. At 1304, the CAD platform generates a three-dimensional mechanical model of the industrial automation system based on the mechanical design inputs received at step 1302.

[0094] At 1306, aspect specification input data is received by the CAD platform (via interaction with the graphical development interface of the CAD platform). The aspect specification input data assigns control aspects to selected elements of the mechanical model generated at step 1304. The control aspects can be selected from a list of available aspects presented in the toolbar or ribbon of the graphical development interface of the CAD platform. The aspect definitions can be classified according to the type of mechanical element, control element, or industrial equipment associated with these aspects. Each aspect defines a set of simulation properties for its associated type of mechanical or control element, such as physical or kinematic properties or behaviors, physical geometry, motion constraints, etc., which can be recognized and utilized by the simulation platform to determine how the element moves or behaves within the simulation environment. Example aspects that can be selected and applied to the mechanical model include, but are not limited to: various types of dynamic or kinematic joints (e.g., sliding joints, rotary joints, robotic arm joints, hinges, etc.), moving surfaces such as conveyors, motors, grippers (e.g., suction grippers, mechanical grippers, etc.), sensors, pneumatic or hydraulic actuators (e.g., pusher arms, stoppers, etc.), rollers, or other such elements of the mechanical system.

[0095] At 1308, control aspect metadata corresponding to the control aspect selected at step 1306 is assigned to the selected components of the mechanical model (also selected at step 1306). At 1310, it is determined whether the assignment of aspects to the selected components of the mechanical model is complete. If additional aspects are to be assigned to the model ( "No" at step 1310), the method returns to step 1306, and steps 1306 and 1308 are repeated such that another component of the mechanical model is marked with the selected aspects. Alternatively, if the assignment of aspects to the mechanical model is complete ( "Yes" at step 1310), the method proceeds to step 1312, where it is determined whether the CAD system has received an export command. If an export command is received ( "Yes" at step 1312), the method proceeds to step 1314, where the mechanical model enhanced with the aspect metadata applied through the iteration of steps 1306 and 1308 is exported to a control simulation platform for simulation as a dynamic digital twin of the automation system. The aspect metadata applied by the CAD system indicates to the simulation platform regarding how the various components or elements of the mechanical model behave within the simulation environment in response to the simulation control by the control program being tested.

[0096] Figure 14 An example method 1400 for generating a dynamic digital twin of an automation system and an associated master I / O list in parallel with the mechanical design of the system is shown. Initially, at 1402, a mechanical design input is received by the CAD platform. The mechanical design input specifies the mechanical attributes of the industrial automation system being designed. At 1404, based on the mechanical design input received at step 1402, a three-dimensional mechanical model of the industrial automation system is generated within the CAD platform. At 1406, an aspect specification input is received by the CAD platform. The aspect specification input selects control aspects and assigns the control aspects to the selected components of the mechanical model. Generally, steps 1402 through 1408 are similar to steps 1302 through 1308 of method 1300.

[0097] At 1410, it is determined whether the aspect metadata of the selected component assigned to the mechanical model at step 1408 defines the associated I / O of the aspect. In this regard, if the aspect assigned to the model component defines the characteristics of an industrial asset that typically interfaces with an industrial controller via one or more digital or analog inputs or outputs, then these inputs or outputs can be defined by the aspect metadata. If the aspect metadata defines the associated I / O (yes at step 1410), the method proceeds to step 1412, where the associated I / O defined by the aspect metadata is added to the cumulative master I / O list of the automation system. This master I / O list records the total I / O required to interface the automation system with the industrial controller to facilitate system monitoring and control. If the aspect metadata does not define the associated I / O (no at step 1410), i.e., the selected aspect corresponds to a component of the automation system that typically does not interface with the industrial controller, the method proceeds to step 1414 without updating the master I / O list at 1412.

[0098] At 1414, it is determined whether the assignment of aspects to the mechanical model is complete. If additional aspects are to be assigned to the model (no at step 1414), the method returns to step 1406 and steps 1406 to 1412 are repeated for another component of the mechanical model. Alternatively, if the assignment of aspects is complete (yes at step 1414), the method proceeds to step 1416, where the enhanced mechanical model (with associated aspect metadata) and the master I / O list are exported to a control design platform. Control engineers can refer to the master I / O list to assist in designing the electrical and control systems of the automation system.

[0099] The amount of memory and processing resources required to perform an industrial simulation varies according to the size or complexity of the simulation. In the case of large-scale simulations, a single hardware machine may not have sufficient resources to perform the entire simulation without sacrificing at least simulation speed, and in some cases, may not be able to perform the simulation under any circumstances, given the limitations of local processing capabilities.

[0100] To address this issue, some implementations of the design and test simulation 302 can be configured to scale a digital model 502 across multiple different processing nodes. For example, the system 302 can allow a user to specify different portions of the model 502 to be executed on respective different distributed processing nodes such that each portion of the model 502 is executed on its specified node and the nodes exchange data as needed to simulate the entire aggregated automation system. To visualize the aggregated simulation, the design and test system 302 can unify the distributed portions of the model 502 into a unified 3D presentation at a single node (e.g., the system 302) and animate the unified view based on graphical and simulation data received from the nodes on which the distributed simulation is executed.

[0101] Figure 15 FIG. is a diagram showing the assignment of respective portions of the digital model 502 to respective processing nodes. Although the examples described herein assume that the model scaled for distributed simulation is the digital model 502 created by applying the aspect metadata as described above, the techniques described herein for scaling an industrial simulation across multiple nodes and generating a unified presentation of the distributed simulation at a single node can be applied to substantially any type of virtualized industrial automation system or factory regardless of the means by which the virtualized system is created.

[0102] As Figure 15 shown, a user can submit node assignment data 1502 via the user interface component 304. The node assignment data 1502 identifies the portions of the digital model 502 to be executed on respective different processing nodes. That is, the node assignment data 1502 defines the division of the digital model 502 into portions to be separately executed on different hardware machines or processing nodes. In some implementations, in addition to defining the division of the model 502 into portions to be separately executed, the node assignment data 1502 can also identify, for each defined portion of the digital model 502, the target node on which the defined portion is to be executed. Alternatively, the node assignment data 1502 can only define the division of the digital model 502 into portions and the model deployment component 314 can select, from the available processing nodes, the target nodes on which the respective defined portions of the model 502 are to be executed.

[0103] Any suitable definition criteria can be used to define the node assignment. For example, a user can identify machines or production areas to be simulated on respective different processing nodes via interaction with a graphical representation of the digital model 502 presented on a client device.

[0104] In some embodiments, the node specification defined by the node-specified data 1502 can be stored with the model 502 as the node definition 1506, which can then be referenced by the model deployment component 314 to determine how the digital model 502 should be deployed for distributed simulation.

[0105] Figure 16 is a diagram showing the scaling of the digital model 502 for distributed simulation across different processing nodes. Nodes 16041 to 1604 N represent different hardware machines or processing nodes on which different parts of the digital model 502 can be executed to facilitate distributed simulation of the automated modeling system (where N is a non-zero integer greater than 1). In some scenarios, 16041 to 1604 N can be different hardware platforms networked together to facilitate data exchange between the nodes. Alternatively, nodes 16041 to 1604 N can be processing nodes executing on a cloud platform (e.g., as virtual machines). Based on the node definition 1506 defined by the user, the model deployment component 314 can generate model parts 16021 to 1602 N that include the various different parts of the digital model 502 defined by the node definition 1506, and deploy these model parts 16021 to 1602 N to the respective nodes 16041 to 1604 N for distributed execution. The model deployment component 314 can send the model parts 16021 to 1602 N to their designated nodes 16041 to 1604 N via a secure connection over a private network (e.g., an office network or a factory network) and / or a public network (e.g., the Internet).

[0106] Figure 17 is a diagram showing the execution of the distributed simulation and the unification of the distributed simulation into a unified 3D view of the entire simulated system. Nodes 16041 to 1604 N are each capable of executing the simulation of their respective model parts 16021 to 1602 N in synchronization with the execution of other model parts executing on other nodes. To facilitate the coordinated simulation of the model parts 16021 to 1602 N that represent an aggregated automated system or factory, the processing nodes 16041 to 1604 NThe analog data can be exchanged as needed so that the analog actions on the first model part 16021 that affect the analog operations of the second model part 16022 are transferred from the node 16041 on which the first model part 16021 is executed to the node 16042 on which the second model part 16022 is executed. In this regard, when the model parts 16021 to 1602 N are distributed across different nodes 16041 to 1604 N the physical, electrical, or data links between the modeled components (e.g., mechanical or electrical components, I / O devices, etc.) defined by the original digital model 502 are maintained.

[0107] The distributed simulation can be driven by one or more industrial control programs 1008 ( Figure 17 not shown) such that the processing nodes 16041 to 1604 N simulate the operation of the modeled automation system under the control of the industrial control program 1008, and the one or more industrial control programs 1008 are executed by a physical industrial controller or a simulated industrial controller (e.g., the controller simulation component 308 as described above regarding Figure 10 ). In the case of the simulated control program 1008, the program 1008 can be executed by a virtualized industrial controller executed on one or more of the processing nodes 16041 to 1604 N or can operate on a separate processing node 1604 that exchanges the monitored and controlled signals of the simulation with the other nodes 16041 to 1604 N . In the case of the industrial control program 1008 executed by an actual industrial controller, the controller can be networked to the processing nodes 16041 to 1604 N to facilitate the exchange of the analog response data of the distributed simulation and the control signals generated by the industrial controller based on the execution of the control program 1008.

[0108] Even if the model parts 16021 to 1602 N that make up the simulation are distributed across multiple processing nodes 16041 to 1604 N the design and test system 302 can still demonstrate a unified 3D view of the distributed simulation. To this end, the node interface component 316 can unify the graphics from the distributed model parts 16021 to 1602 N and the user interface component 304 can generate aggregated unified presentation data 1702 representing these unified graphics. The user interface component 304 presents the unified presentation data 1702 on the client device as an interactive 3D graphical visualization 1706 representing the overall modeled automation system, which includes any appropriate simulation result data (e.g., status indications, alphanumeric operation information, etc.).

[0109] In an example implementation, the node interface component 316 may collect simulation data generated by the respective nodes 1604 based on simulations of their respective model portions 1602 via a common and / or private network connecting the system 302 to the nodes 1604. The simulation data from a given node 1604 represents the behavior and state of the virtualized components represented by the model portion 1602 managed by that node 1604, where the behavior and state are based on control signals generated by the control program 1008 and on behavior data and simulation states received from other nodes 1604 based on simulations of their respective model portions 1602. The node interface component 316 also collects graphic data from each of the processing nodes 16041 to 1604 N where the graphic data from a given node 1604 includes an animated 3D representation of the model portion 1602 managed by that node 1604. To produce an aggregated view of the composite automation system, the node interface component 316 aggregates the graphic data received from all of the nodes 16041 to 1604 N to produce an aggregated 3D presentation of the automation system, and animates the resulting unified presentation 1702 based on the simulation data received from the nodes 16041 to 1604 N This may include: animating the movement of virtual machines, animating the movement of products through the automation system, overlaying simulated state information at appropriate locations within the unified 3D representation, or other such animations. The unified presentation data 1702 is sent to the client device to be presented as a visualization 1706, which is updated in real time to reflect the current state of the distributed simulation. The visualization 1706 may be similar in format and behavior to the visualization 1014 described above.

[0110] The unified presentation of the distributed simulation may be navigated via interaction with the visualization 1706. For example, a user may interact with the visualization 1706 to select a different perspective, zoom distance, or other visualization properties. These interactions are translated into navigation input 1704, which is submitted to the user interface component 304. The node interface component 316 then updates the visualization 1706 based on the input 1704.

[0111] In some embodiments, a user may, via interaction with the visualization 1706, select a portion of the virtualized automation system corresponding to one of the model portions 1602 executing on a node 1604, and in response, the user interface component 304 may update the visualization 1706 to present a detailed view of the model portion 1602 selected by the user, where the detailed view is animated based on data from the particular node 1604 managing the selected model portion 1602.

[0112] Although Figure 17The architecture depicted for aggregating distributed industrial simulations into a unified presentation has been described herein as unifying distributed simulations generated and deployed as described above with respect to Figure 15 and Figure 16 but some implementations of the node interface component 316 can generate a unified presentation 1702 of distributed industrial simulations created and deployed using other techniques and are not limited to the unification of model portions 1602 derived from digital models 502 enhanced with aspect metadata 508.

[0113] The method described herein for unifying distributed industrial simulations into an aggregated presentation can allow large industrial simulations across multiple processing nodes to be scaled while still providing a unified view of the entire virtualized system. The method can also facilitate high-fidelity simulation of such automated systems by leveraging amplified processing resources made possible by distributing the simulation across multiple processing nodes.

[0114] Figures 18 to 19 Illustrates various methods in accordance with one or more embodiments of the present subject matter application. Although, for purposes of simplifying the description, one or more of the methods shown herein are shown and described as a series of acts, it should be understood and appreciated that the present invention is not limited by the order of the acts, as some acts may occur in a different order than shown and / or concurrently with other acts shown and described herein. For example, those skilled in the art will understand and appreciate that the method may alternatively be represented as a series of interrelated states or events, such as in a state diagram. Additionally, not all of the acts shown may be required to implement the method in accordance with the present innovation. Further, when different entities perform different portions of the method, an interaction diagram may represent the method or manner in accordance with the present subject matter disclosure. Still further, two or more of the disclosed example methods may be implemented in combination with one another to achieve one or more of the features or advantages described herein.

[0115] Figure 18 Illustrates an example method 1800 for scaling a digital model for distributed simulation across multiple processing nodes of an industrial automation system. Initially, at 1802, node-specifying data is received that defines portions of the depiction of the digital model of the industrial automation system to be executed on separate processing nodes. In an example scenario, the node depiction data can specify portions according to groups of devices, production lines, areas of a factory facility, or other such depictions. At 1804, a simulatable model portion representing the portions of the industrial automation system depicted by the node-specifying data is generated. At 1806, the model portion generated at step 1804 is deployed to various different processing nodes for distributed simulation of the industrial automation system according to the node-specifying data.

[0116] Figure 19 An example method 1900 for aggregating distributed parts of an industrial simulation into a unified presentation is shown. Initially, at 1902, the system on which the distributed simulation is to be aggregated is communicatively connected to a plurality of processing nodes that execute the various parts of the distributed industrial simulation, where the distributed simulation simulates the operation of an industrial automation system. At 1904, simulation and graphical data are collected from the plurality of processing nodes via the connection established at step 1902. At 1906, the simulation and graphical data collected at step 1904 are aggregated into a unified three-dimensional presentation of the industrial automation system. The unified presentation depicts the simulated operation of the industrial automation system. At 1908, the three-dimensional presentation is rendered on a client device.

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

[0118] Similarly, as used herein, the term PLC or automation controller may include 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 cooperate with various network devices across a network. This can essentially include any type of control, communication module, computer, input / output (I / O) device, sensor, actuator, and human-machine interface (HMI) that communicates via a network, the network including a control network, an automation network, and / or a public network. A PLC or automation controller can also communicate with and control various other devices, such as standard or safety-rated I / O modules including analog, digital, programmed / smart I / O modules, other programmable controllers, communication modules, sensors, actuators, output devices, and the like.

[0119] The network can include: a public network such as the Internet; an intranet; an automation network such as a Control and Information Protocol (CIP) network; a secure network; and Ethernet / IP. The automation network includes DeviceNet and ControlNet. Other networks include Ethernet, DH / DH+, Remote I / O, Fieldbus, Modbus, Profibus (Process Fieldbus), CAN (Controller Area Network), wireless network, serial protocol, etc. In addition, network devices can include various possibilities (hardware and / or software components). These include components such as: switches with Virtual Local Area Network (VLAN) capabilities, LANs, WANs, proxies, gateways, routers, firewalls, Virtual Private Network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and / or other devices.

[0120] To provide context for various aspects of the disclosed subject matter, Figure 20 and Figure 21 the following discussion is intended to provide a brief general description of a suitable environment in which aspects of the disclosed subject matter can be implemented. Although the embodiments have been described above in the general context of computer-executable instructions that may run on one or more computers, those skilled in the art will recognize that the embodiments can also be implemented in conjunction with other program modules and / or as a combination of hardware and software.

[0121] Generally, program modules include routines, programs, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In addition, those skilled in the art will understand that the methods of the present 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, etc., each of which can be operably coupled to one or more associated devices.

[0122] The embodiments illustrated herein can also be practiced in a distributed computing environment where certain tasks are performed by remote processing devices linked through a communication network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

[0123] Computing devices generally include various media, which may include computer-readable storage media, machine-readable storage media, and / or communication media. The terms computer-readable storage media and machine-readable storage media are used differently from each other herein as follows. A computer-readable storage media or a machine-readable storage media can be any available storage media that can be accessed by a computer and includes volatile media and non-volatile media, removable media and non-removable media. By way of example and not limitation, a computer-readable storage media or a machine-readable storage media can be implemented in conjunction with any method or technology for storing information such as computer-readable instructions or machine-readable instructions, program modules, structured data, or unstructured data.

[0124] Computer-readable storage media can 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, compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage devices, magnetic tape cartridges, tapes, magnetic 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 the required information. In this regard, the terms "tangible" or "non-transitory" as applied to storage devices, memories, or computer-readable media herein should be understood as modifiers that only exclude propagating transient signals themselves and do not disclaim rights to all standard storage devices, memories, or computer-readable media that are not only propagating transient signals themselves.

[0125] For various operations on information stored by the media, the computer-readable storage media can be accessed by one or more local or remote computing devices - for example, via an access request, query, or other data retrieval protocol.

[0126] Communication media typically embody computer-readable instructions, data structures, program modules, or other structured or unstructured data in a modulated data signal such as a carrier wave or other transmission mechanism, and include any information delivery or transmission media. The term "modulated data signal" or signal refers to a signal that sets or changes one or more of its characteristics 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 a wired network or a direct wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media.

[0127] Refer again to Figure 20, An example environment 2000 for various implementations to implement the aspects described herein includes a computer 2002, which includes a processing unit 2004, a system memory 2006, and a system bus 2008. The system bus 2008 couples system components to the processing unit 2004, and the system components include, but are not limited to, the system memory 2006. The processing unit 2004 can be any of a variety of commercially available processors. Dual microprocessors and other multiprocessor architectures can also be used as the processing unit 2004.

[0128] The system bus 2008 can be any of several types of bus structures that can also be interconnected with 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. The system memory 2006 includes a ROM 2010 and a RAM 2012. The basic input / output system (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), EEPROM, where the BIOS contains basic routines that help transfer information between elements within the computer 2002 during startup, for example. The RAM 2012 can also include high-speed RAM, such as static RAM for caching data.

[0129] The computer 2002 also includes an internal hard disk drive (HDD) 2014 (e.g., EIDE, SATA), one or more external storage devices 2016 (e.g., a magnetic floppy disk drive (FDD) 2016, a memory stick or flash drive reader, a memory card reader, etc.), and an optical disk drive 2020 (e.g., which can read from or write to a CD-ROM disk, a DVD, a BD, etc.). Although the internal HDD 2014 is shown as being within the computer 2002, the internal HDD 2014 can also be configured for external use in a suitable chassis (not shown). Additionally, although not shown in the environment 2000, a solid-state drive (SSD) can be used in addition to or in place of the HDD 2014. The HDD 2014, the external storage device 2016, and the optical disk drive 2020 can be connected to the system bus 2008 through an HDD interface 2024, an external storage interface 2026, and an optical disk drive interface 2028, respectively. The interface 2024 for external drive implementation can include at least one or both of a universal serial bus (USB) and an Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technology. Other external drive connection technologies are within the scope of the concepts of the implementations described herein.

[0130] The drive and its associated computer-readable storage medium provide non-volatile storage of data, data structures, computer-executable instructions, and the like. For computer 2002, the drive and the storage medium provide storage of any data in a suitable digital format. Although the above description of the computer-readable storage medium refers to various types of storage devices, those skilled in the art should understand that other types of storage media that are computer-readable - whether currently existing or to be developed in the future - can also be used in the exemplary operating environment. In addition, any such storage medium can contain computer-executable instructions for performing the methods described herein.

[0131] Many program modules can be stored in the drive and in RAM 2012, including an operating system 2030, one or more application programs 2032, other program modules 2034, and program data 2036. All or part of the operating system, applications, modules, and / or data can also be cached in RAM 2012. The systems and methods described herein can be implemented using various commercially available operating systems or combinations of operating systems.

[0132] Computer 2002 can optionally include emulation technology. For example, a hypervisor (not shown) or other intermediary can emulate the hardware environment for operating system 2030, and the emulated hardware can optionally be different from Figure 20 the hardware shown therein. In such an embodiment, operating system 2030 can be one of a plurality of virtual machines (VMs) hosted at computer 2002. In addition, operating system 2030 can provide a runtime environment such as a Java runtime environment or a.NET framework for application programs 2032. A runtime environment is a consistent execution environment that allows application programs 2032 to run on any operating system that includes the runtime environment. Similarly, operating system 2030 can support containers, and application programs 2032 can be in the form of containers, which are lightweight, independent, executable software packages that include, for example, code, runtime, system tools, system libraries, and settings for the application.

[0133] In addition, a security module such as a Trusted Platform Module (TPM) can be utilized to enable computer 2002. For example, using the TPM, a 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 layer in the code execution stack of computer 2002, such as being applied at the application execution level or the operating system (OS) kernel level, thereby enabling security at any level of code execution.

[0134] A user can input commands and information into the computer 2002 through one or more wired / wireless input devices, such as a keyboard 2038, a touch screen 2040, and a pointing device such as a mouse 2042. Other input devices (not shown) may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control or other remote controls, a joystick, a virtual reality controller and / or a virtual reality headset, a gamepad, a stylus, an image input device such as a camera device, a gesture sensor input device, a visual motion sensor input device, an emotion or face detection device, a biometric input device such as a fingerprint or iris scanner, etc. These input devices and other input devices are generally connected to the processing unit 2004 through an input device interface 2044 that can be coupled to the system bus 2008, but can also be connected through other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, interfaces, etc.

[0135] A monitor 2044 or other type of display device can also be connected to the system bus 2008 via an interface such as a video adapter 2048. In addition to the monitor 2044, a computer generally also includes other peripheral output devices (not shown), such as speakers, printers, etc.

[0136] The computer 2002 can operate in a networking environment using a logical connection via wired and / or wireless communication to one or more remote computers, such as the remote computer 2048. The remote computer 2048 can be a workstation, a server computer, a router, a personal computer, a portable computer, a microprocessor-based entertainment appliance, a peer device, or other common network nodes, and generally includes many or all of the elements described for the computer 2002, but for the sake of brevity, only the memory / storage device 2050 is shown. The depicted logical connections include wired / wireless connections to a local area network (LAN) 2052 and / or a larger network such as a wide area network (WAN) 2054. 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 be connected to a global communication network, such as the Internet.

[0137] When used in a LAN networking environment, the computer 2002 can be connected to the local network 2052 through a wired and / or wireless communication network interface or adapter 2056. The adapter 2056 can facilitate wired or wireless communication with the LAN 2052, and the LAN 2052 can also include a wireless access point (AP) arranged thereon for communicating with the adapter 2056 in a wireless mode.

[0138] When used in a WAN networking environment, computer 2002 can include a modem 2058 or can communicate via other means for establishing communication over a WAN 2054, such as by connecting to a communication server on the WAN 2054 via the Internet. The modem 2058, which can be an internal or external device and a wired or wireless device, can be connected to the system bus 2008 via an input device interface 2060. In a networking environment, program modules or portions of program modules depicted with respect to computer 2002 can be stored in a remote memory / storage device 2050. It should be understood that the network connections shown are examples and that other means of establishing a communication link between computers can be used.

[0139] When used in a LAN or WAN networking environment, in addition to the external storage device 2016 as described above, computer 2002 can also access a cloud storage system or other network-based storage systems; or instead of the external storage device 2016 as described above, computer 2002 can access a cloud storage system or other network-based storage systems. Generally, a connection between computer 2002 and a cloud storage system can be established over a LAN 2052 or WAN 2054, for example, via an adapter 2056 or a modem 2058, respectively. When connecting computer 2002 to an associated cloud storage system, the external storage interface 2026 can manage the storage provided by the cloud storage system in the same way as other types of external storage, with the help of the adapter 2056 and / or the modem 2058. For example, the external storage interface 2026 can be configured to provide access to cloud storage sources as if these sources were physically connected to computer 2002.

[0140] Computer 2002 is operable to communicate with any wireless device or entity that is operatively arranged in a wireless communication configuration, such as a printer, scanner, desktop computer and / or portable computer, portable data assistant, communication satellite, any device or location associated with a wirelessly detectable tag (e.g., kiosk, newsstand, store shelf, etc.), and a telephone. This can include Wi-Fi and wireless technologies. Thus, the communication can be of a predefined structure like a conventional network or can be an ad hoc communication between at least two devices.

[0141] Figure 21FIG. 0 is a schematic block diagram of an exemplary computing environment 2100 with which the disclosed subject matter may interact. The exemplary computing environment 2100 includes one or more clients 2102. The clients 2102 may be hardware and / or software (e.g., threads, processes, computing devices). The exemplary computing environment 2100 also includes one or more servers 2104. The servers 2104 may also be hardware and / or software (e.g., threads, processes, computing devices). For example, the servers 2104 may house threads to perform transformations by employing one or more of the embodiments described herein. A possible communication between the clients 2102 and the servers 2104 may be in the form of data packets adapted to be transmitted between two or more computer processes. The exemplary computing environment 2100 includes a communication framework 2106 that may be used to facilitate communications between the clients 2102 and the servers 2104. The clients 2102 are operatively connected to one or more client data storage devices 2108 that may be used to store information local to the clients 2102. Similarly, the servers 2104 are operatively connected to one or more server data storage devices 2110 that may be used to store information local to the servers 2104.

[0142] The above-described matter includes examples of the innovations of the subject matter. Of course, it is not possible to describe every conceivable combination of components or methods for purposes of describing the disclosed subject matter, but one of ordinary skill in the art will recognize that many additional combinations and permutations of the subject matter innovations are possible. Accordingly, the disclosed subject matter is intended to cover all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.

[0143] Specifically, with respect to the various functions performed by the above-described components, devices, circuits, systems, etc., unless otherwise indicated, the terms used to describe these components (including references to “means”) are intended to correspond to any component that performs the specified function of the described component (e.g., a functional equivalent), even if that component is not structurally equivalent to the disclosed structure that performs the functions of the exemplary aspects of the disclosed subject matter shown herein. In this regard, it should also be recognized that the disclosed subject matter includes computer-readable media and systems having computer-executable instructions for performing the actions and / or events of the various methods of the disclosed subject matter.

[0144] In addition, although certain features of the disclosed subject matter may have been disclosed with respect to only one of several implementations, such features may be combined with one or more other features that may be desirable and advantageous for any given or particular application in other implementations. Further, to the extent that the terms "includes" and "including" and their variants are used in the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term "comprising".

[0145] In this application, the word "exemplary" is used to mean serving 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 concepts in a concrete fashion.

[0146] The various aspects or features described herein may be implemented as a method, apparatus, or article of manufacture using standard programming and / or engineering techniques. As used herein, the term "article of manufacture" is intended to include a computer program accessible from any computer-readable device, carrier, or medium. For example, the computer-readable medium may include, but is not limited to: magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips...), optical disks [e.g., compact disc (CD), digital versatile disc (DVD)...], smart cards, and flash memory devices (e.g., cards, sticks, key drives...).

Claims

1. A system for presenting an industrial simulation, comprising: a memory that stores executable components; a processor operatively coupled to the memory and executing the executable components, the executable components including: a node interface component configured to communicatively connect to a plurality of processing node devices that jointly perform a distributed simulation of an industrial automation system, wherein, the distributed simulation includes a plurality of model parts that represent respective parts of the industrial automation system, the plurality of model parts are respectively simulated by the plurality of processing node devices, and the node interface component is further configured to: collect graphical data and simulation data from the plurality of processing node devices, and aggregate the graphical data and the simulation data to generate unified presentation data, and receive node specification data that defines the plurality of model parts as a depiction of a digital model of the industrial automation system; an aspect metadata component configured to associate the node specification data with the digital model; and a user interface component configured to: present a unified presentation of the industrial automation system on a client device based on the unified presentation data.

2. The system according to claim 1, wherein The plurality of processing node devices include hardware machines residing on a common network or virtual machines executing on a cloud platform.

3. The system according to claim 1, wherein, The user interface component is further configured to: update the unified presentation according to the navigation input in response to receiving navigation input data that defines navigation through the unified presentation via an interaction with the unified presentation.

4. The system according to claim 3, wherein, the navigation input includes selecting a region of the automation system corresponding to a model part simulated on a processing node device among the plurality of processing node devices, and the user interface component is configured to: convert the unified presentation to a detailed view of the region of the industrial automation system based on a subset of the simulation data and the graphical data received from the processing node device.

5. The system according to claim 1, wherein, The unified presentation is a three-dimensional graphical representation of the industrial automation system, and the three-dimensional graphical representation is animated according to the simulation data received from the plurality of processing node devices.

6. The system according to claim 1, wherein The executable components further include a model deployment component configured to generate the model parts based on the depiction defined by the node specification data and deploy the model parts to the plurality of processing node devices.

7. The system according to claim 6, wherein, The node specification data further defines the identity of the processing node device to which each of the model parts among the model parts will be deployed among the plurality of processing node devices.

8. The system according to claim 1, wherein, the user interface component is further configured to receive aspect specification input data that marks selected elements of a three-dimensional (3D) mechanical model as a specified aspect of the industrial automation system, and The aspect metadata component is further configured to assign aspect metadata to selected components according to the aspect specification input data, the aspect metadata defining the analog behavior of the selected components to generate the digital model of the industrial automation system.

9. A method for generating a demonstration of an industrial simulation, comprising: communicatively connecting, by a system including a processor, to a plurality of processing node devices that jointly perform a distributed simulation of an industrial automation system, wherein the distributed simulation includes a plurality of model parts representing respective parts of the industrial automation system, and the plurality of model parts are respectively simulated by the plurality of processing node devices; collecting, by the system, graphical data and simulation data from the plurality of processing node devices; receiving, by the system, node specification data that defines the plurality of model parts as a depiction of a digital model of the industrial automation system; associating, by the system, the node specification data with the digital model; aggregating, by the system, the graphical data and the simulation data to generate unified demonstration data; and presenting, based on the unified demonstration data, a unified demonstration of the industrial automation system on a client device.

10. The method according to claim 9, wherein, The plurality of processing node devices include hardware machines residing on a common network or virtual machines executing on a cloud platform.

11. The method according to claim 9 further comprises: updating, by the system, the unified demonstration according to the navigation input in response to receiving navigation input data that defines navigation through the unified demonstration via an interaction with the unified demonstration.

12. The method according to claim 11, wherein the receiving of the navigation input data includes: receiving a selection of an area of the automation system corresponding to a model part among the model parts simulated on a processing node device among the plurality of processing node devices, and the updating includes: converting the unified demonstration to a detailed view of the area of the industrial automation system based on a subset of the simulation data and the graphical data received from the processing node device.

13. The method according to claim 9, wherein The presenting includes: presenting a three-dimensional graphical representation of the industrial automation system and animating the three-dimensional graphical representation according to the simulation data received from the plurality of processing node devices.

14. The method according to claim 9, further comprising: generating, by the system, the model parts based on the depiction defined by the node specification data; and deploying, by the system, the model parts to the plurality of processing node devices.

15. The method according to claim 14, wherein, The node specification data further defines, for each of the model parts, the identity of the processing node device to which the model part among the plurality of processing node devices will be deployed.

16. A non-transitory computer-readable medium having instructions stored thereon that, in response to execution, cause a system including a processor to perform operations, the operations including: Communicatively connected to a plurality of processing node devices that jointly perform distributed simulation of an industrial automation system, wherein the distributed simulation includes a plurality of model parts representing respective parts of the industrial automation system, and the plurality of model parts are respectively simulated by the plurality of processing node devices; Collecting graphical data and simulation data from the plurality of processing node devices; Receiving node specification data that defines the plurality of model parts as a depiction of a digital model of the industrial automation system; Associating the node specification data with the digital model; Aggregating the graphical data and the simulation data to generate unified presentation data; and Presenting a unified presentation of the industrial automation system based on the unified presentation data.

17. The non-transitory computer-readable medium according to claim 16, wherein, The plurality of processing node devices include hardware machines residing on a common network or virtual machines executing on a cloud platform.

18. The non-transitory computer-readable medium according to claim 16, wherein, The presenting includes: presenting a three-dimensional graphical representation of the industrial automation system and animating the three-dimensional graphical representation according to the simulation data received from the plurality of processing node devices.

Images