Industrial automation smart object parent / child data collection propagation

Abstract

The present disclosure relates to industrial automation smart object parent / child data collection propagation. An industrial integrated development environment (IDE) provides a development framework to design, program, and configure multiple aspects of an industrial automation system using a common design environment and data model. Project creation using embodiments of the IDE system can be built on an object-based model rather than, or in addition to, a tag-based architecture. To this end, the IDE system can support the use of automation objects that serve as building blocks for this object-based development structure. These automation objects represent corresponding physical industrial assets and have associated programming attributes related to these assets, including data records and device configuration parameters. Functional relationships between automation objects can be defined to yield an object hierarchy, and object attributes can be propagated across objects up and down the hierarchy.

Description

Technical Field

[0001] This disclosure generally pertains to the collection and dissemination of parent / child data for intelligent objects in industrial automation. Background Technology

[0002] The topics disclosed in this article generally relate to industrial automation systems, and, for example, to industrial programming development platforms. Summary of the Invention

[0003] The following is a simplified overview to provide a basic understanding of some of the aspects described in this paper. This overview is not a comprehensive review, nor is it intended to identify key / important elements or to outline the scope of the various aspects described herein. Its sole purpose is to present some ideas in a simplified form as a prelude to the more detailed descriptions that follow.

[0004] In one or more embodiments, a system for developing industrial applications is provided, the system comprising: a memory storing executable components and a library of automation objects representing corresponding industrial assets, the automation objects having corresponding programming attributes associated with the industrial assets; a user interface component configured to present an integrated development environment (IDE) interface and receive design input via interaction with the IDE interface, the design input defining aspects of an industrial automation project; and a project generation component configured to generate system project data based on the design input, wherein the system project data defines a system project including at least one of an executable industrial control program, an industrial visualization application, or industrial equipment configuration data, the system project data also including instances of automation objects selected from the automation objects stored in the library, and the instances of automation objects including data record configuration parameters as one or more programming attributes, the data record configuration parameters configuring a data collection system in response to deployment of the data collection system to collect data generated by the industrial assets represented by the instances of automation objects.

[0005] Furthermore, one or more embodiments provide a method for developing industrial applications, comprising: presenting an integrated development environment (IDE) interface on a client device by a system including a processor; receiving design input by the system via interaction with the IDE interface, the design input defining aspects of an industrial control and monitoring project; and generating system project data by the system based on the design input, the system project data including at least one instance of an automation object selected from a library of automation objects, the automation object representing a corresponding industrial asset and having corresponding programming attributes associated with the industrial asset, wherein the generation includes at least one of generating an executable industrial control program, an industrial visualization application, or industrial equipment configuration data, and the instance of the automation object includes data record configuration parameters as one or more programming attributes, the data record configuration parameters configuring a data history system in response to the deployment of a data history system to collect data generated by the industrial asset represented by the instance of the automation object.

[0006] Furthermore, according to one or more embodiments, a non-transitory computer-readable medium is provided, on which instructions are stored, which, in response to execution, cause the system to perform operations, said operations including: presenting an integrated development environment (IDE) interface on a client device; receiving design input from the client device via interaction with the IDE interface, the design input defining various control design aspects of an industrial automation project; and generating system project data based on the design input, wherein the generation includes at least one of generating an executable industrial control program, an industrial visualization application, or industrial equipment configuration data, the system project data including instances of automation objects selected from a library of automation objects, the automation objects representing corresponding industrial assets and having corresponding programming attributes related to the industrial assets; and the instances of automation objects including data history configuration settings as one or more programming attributes, the data history configuration settings configuring a data history system in response to deployment of a data history system to collect data generated by the industrial assets represented by the instances of automation objects.

[0007] To achieve the foregoing and related objectives, certain illustrative aspects are described herein in conjunction with the following description and figures. These aspects indicate various modes that can be practiced, all of which are intended to be covered herein. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the figures. Attached Figure Description

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

[0009] Figure 2 This is a block diagram of an example integrated development environment (IDE) system.

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

[0011] Figure 4 This is a diagram illustrating several example automation object properties that can be utilized by an industrial IDE system in conjunction with building, deploying, and executing system projects.

[0012] Figure 5 This is a diagram illustrating the industrial IDE system and the example data flow associated with creating a system project for an automation system designed using the industrial IDE system.

[0013] Figure 6 This is a diagram illustrating an example system project that incorporates automation objects into the project model.

[0014] Figure 7 This is a diagram showing the debugging of the system project.

[0015] Figure 8 This is a diagram illustrating an example architecture where a cloud-based IDE service is used to develop industrial applications and deploy them to a factory environment.

[0016] Figure 9 This is a diagram of an example automation object that has been integrated into the project data model of the system project.

[0017] Figure 10 This diagram illustrates how the project testing component of the IDE system uses test scripts bound to automation objects to test sample system projects.

[0018] Figure 11 This is a diagram illustrating the submission of automated object edits to the IDE system.

[0019] Figure 12 This is a diagram illustrating how an instance of an automation object is modified based on edits submitted to the master version of the automation object stored in the library.

[0020] Figure 13 This diagram illustrates the downloading of a copy of a system project from an industrial IDE system to a local client device.

[0021] Figure 14 This is a diagram illustrating how automated object editing is propagated to a local storage copy of the system project.

[0022] Figure 15 It is a graphical representation of the two-layer relationship between automated objects.

[0023] Figure 16 This is a graphical representation of three encapsulated automation objects.

[0024] Figure 17This is a flowchart of an example method for creating and encapsulating layers of automation objects within an industrial system project using an industrial IDE system.

[0025] Figure 18a This is a flowchart of the first part of an example method for configuring the recording of data generated by an automation system within an automation system project for monitoring and control by the system project.

[0026] Figure 18b This is a flowchart of the second part of an example method for configuring the recording of data generated by an automation system within an automation system project for monitoring and control by the system project.

[0027] Figure 19 This is a flowchart of an example method for defining industrial equipment configurations within an automation system project using automation objects.

[0028] Figure 20 This is an example computing environment.

[0029] Figure 21 This is an example network environment. Detailed Implementation

[0030] This disclosure will now be described with reference to the accompanying drawings, in which similar reference numerals are used to refer to similar elements. In the following description, numerous specific details are set forth for illustrative purposes to provide a thorough understanding of this disclosure. However, it will be apparent that this disclosure can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate description.

[0031] As used herein, the terms “component,” “system,” “platform,” “layer,” “controller,” “terminal,” “station,” “node,” and “interface” are intended to refer to a computer-related entity or an entity related to or part of an operating device having one or more specific functions, wherein such an entity may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a process running on a processor, a processor, a hard disk drive, multiple storage drives (optical or magnetic storage media) including fixed (e.g., secured with screws or bolts) or removable fixed solid-state drives; an object; an executable file; an executing thread; a computer-executable program, and / or a computer. For illustration, a server and an application running on a server can both be components. One or more components may reside within an executing process and / or thread, and components may reside on one computer and / or be distributed among two or more computers. Furthermore, the components described herein may be executable from various computer-readable storage media storing various data structures. These components may communicate via local and / or remote processes, for example, based on signals having one or more data packets (e.g., data from a component interacting with another component in a local system, a distributed system, and / or interacting with other systems via signals through a network such as the Internet). As another example, a component may be a device having specific functions provided by mechanical parts operated by an electrical or electronic circuitry system, which is operated by software or firmware applications executed by a processor, wherein the processor may be internal or external to the device and execute at least a portion of the software or firmware application. As another example, a component may be a device providing specific functions by electronic components rather than mechanical parts, the electronic components including a processor to execute software or firmware that at least partially provides the functions of the electronic components. As yet another example, an interface may include input / output (I / O) components and associated processors, applications, or application programming interface (API) components. While the foregoing examples pertain 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 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 applied to identify a specific context or action, or it can generate a probability distribution of states. Inference can be probabilistic, i.e., calculating the probability distribution of states of interest based on considerations of data and events. Inference can also involve techniques for composing higher-level events based on a set of events and / or data. Such inference results in the construction of new events or actions based on a set of observed events and / or stored event data, regardless of whether the events are closely related in time or whether the events and data come from one or more event and data sources.

[0033] Furthermore, the term "or" is intended to mean inclusive "or" rather than exclusive "or". That is, unless otherwise stated or clearly understood from the context, the phrase "X uses A or B" is intended to mean any natural inclusive permutation. That is, any of the following examples satisfy the phrase "X uses A or B": X uses A; X uses B; or X uses both A and B. Additionally, the articles "a" and "an" used in this application and the appended claims should generally be interpreted as meaning "one or more" unless otherwise stated or clearly understood from the context to refer to the singular form.

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

[0035] Various aspects or features will be presented based on the system, which may include multiple devices, components, modules, etc. It should be understood and appreciated that various systems may include additional devices, components, modules, etc., and / or may exclude all devices, components, modules, etc., discussed in conjunction with the accompanying drawings. Combinations of these methods may also be used.

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

[0037] Industrial equipment 120 may include both input devices that provide data relating to the controlled industrial system to industrial controller 118 and output devices that respond to control signals generated by industrial controller 118 for controlling aspects of the industrial system. Example input devices may include telemetry devices (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc.), manual operator control devices (e.g., pushbuttons, selector switches, etc.), safety monitoring devices (e.g., safety mats, safety ropes, light curtains, etc.), and other such devices. Output devices may include motor drivers, pneumatic actuators, signaling devices, robot control inputs, valves, pumps, etc.

[0038] Industrial controller 118 can communicate with industrial equipment 120 via a hardwired or networked interface. For example, industrial controller 118 may be equipped with native hardwired inputs and outputs to communicate with industrial equipment 120 and control these devices. Local controller I / O may include digital I / O that sends discrete voltage signals to and receives discrete voltage signals from field devices, or analog I / O that sends analog voltage or current signals to and receives analog voltage or current signals from devices. Controller I / O may communicate with the controller's processor via a backplane, allowing digital and analog signals to be read into and controlled by the control program. Industrial controller 118 may also communicate with industrial equipment 120 via a network, such as a communication module or integrated networking port. Exemplary networks may include the Internet, intranet, Ethernet, DeviceNet, ControlNet, Data Highway and Data Highway Plus (DH / DH+), remote I / O, fieldbus, Modbus, Profibus, wireless networks, serial protocols, etc. The industrial controller 118 may also store persistent data values ​​that can be referenced by its associated control programs and used for control decisions. These persistent data values ​​include, but are not limited to, measured or calculated values ​​representing the operational status of the controlled machine or process (e.g., tank level, position, alarms, etc.), or captured time-series data collected during the operation of the automated system (e.g., status information at multiple time points, diagnostic occurrences, etc.). Similarly, some intelligent devices—including, but not limited to, motor drives, instruments, or status monitoring modules—may store data values ​​used to control and / or visualize operational status. Such devices may also capture time-series data or events in logs for later retrieval and viewing.

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

[0040] Some industrial environments may also include other systems or devices related to specific aspects of the controlled industrial system. These systems or devices may include, for example, a data historian 110 that aggregates and stores production information collected from industrial controller 118 or other data sources, an equipment document repository containing electronic documents of various industrial devices constituting the controlled industrial system, an inventory tracking system, a work order management system, a repository of machine or process diagrams and documents, a supplier product document repository, a supplier knowledge base, an internal knowledge base, a work scheduling application, or other such systems, some or all of which may reside on the office network 108 of the industrial environment.

[0041] Higher-level systems 126 can perform functions less directly related to the control of industrial automation systems on the factory floor, and instead focus on long-term planning, advanced supervisory control, analysis, reporting, or other such advanced functions. These systems 126 may reside on an office network 108 located external to the factory facilities, or on a cloud platform with access to the office and / or factory networks. Higher-level systems 126 may include, but are not limited to, cloud storage and analytics systems, big data analytics systems, manufacturing execution systems, data lakes, reporting systems, etc. In some scenarios, applications running at these higher levels within an enterprise can be configured to analyze control system operational data, and the results of this analysis can be fed back to operators at the control system level or directly to controllers 118 or devices 120 within the control system.

[0042] The various control, monitoring, and analysis devices that make up an industrial environment must be programmed or configured using device-specific configuration applications. For example, an industrial controller 118 is typically configured and programmed using a control programming development application, such as a ladder logic editor (e.g., executed on client device 124). Using such a development platform, designers can write control programs (e.g., ladder logic, structured text, function block diagrams, etc.) to execute desired industrial sequences or processes and download the resulting program files to controller 118. Separately, developers use an HMI development platform (e.g., executed on client device 122) to design visualization screens and associated navigation structures for HMI 114 and download the resulting visualization files to HMI 114. Some industrial devices 120—such as motor drives, telemetry devices, safety input devices, etc.—may also require configuration using separate device configuration tools (e.g., executed on client device 128) specific to the device being configured. Such device configuration tools can be used to set device parameters or operating modes (e.g., high / low limits, output signal format, scaling factor, energy consumption mode, etc.).

[0043] The need to program and configure different aspects of industrial automation systems using separate configuration tools has led to a fragmented design approach. This results in different, related, or overlapping aspects of the automation system being designed, configured, and programmed separately in different development environments. For example, a motion control system might require a control logic programming platform to program the industrial controller and adjust the control loop, another configuration platform to configure the motor driver, and a visual development platform to program the associated HMI. Related peripheral systems—such as vision systems, safety systems, etc.—may also require configuration using separate programming or development applications.

[0044] This separate development approach may also require considerable testing and debugging effort to ensure proper integration of the separately configured system aspects. In this respect, the anticipated data interfaces or coordination actions between different system aspects may require significant debugging due to the failure to properly coordinate the different programming efforts.

[0045] To address at least some of these or other problems, one or more embodiments described herein provide an integrated development environment (IDE) for designing, programming, and configuring multiple aspects of industrial automation systems using a common design environment and data model. Implementations of industrial IDEs can be used to configure and manage automation system devices in a common manner, thereby facilitating integrated multidisciplinary programming of control, visualization, and other aspects of the control system.

[0046] Typically, industrial IDEs support features across the entire automation lifecycle, including design (e.g., equipment selection and sizing, controller programming, visualization development, equipment configuration, testing, etc.); installation, configuration and commissioning; operation, improvement and management; and troubleshooting, expansion and upgrades.

[0047] Industrial IDEs can be implemented by including modular code and visualization libraries specific to industrial vertical markets and common industrial applications within those vertical markets. These code and visualization modules can simplify development and shorten development cycles, while also supporting consistency and reusability across industrial enterprises.

[0048] To support enhanced development capabilities, project creation using IDE system implementations can be built on an object-based model rather than a tag-based architecture, or, in addition to a tag-based architecture, on an object-based model. To this end, IDE systems can support the use of automation objects as building blocks of this object-based development structure. To ensure consistency within and between projects, and to ensure that a given industrial project is dynamically updated to reflect changes to the attributes of industrial assets (e.g., control code, visualization definitions, test scripts, analysis code, etc.), IDE system implementations can use automation object inheritance features to propagate changes made to automation object definitions to all instances of automation objects used throughout the control project. Furthermore, IDE systems allow users to define hierarchical links between automation objects representing different industrial assets or enterprise levels, and to encapsulate these linked objects into a single object that can be moved to other aspects of the system project or copied across multiple projects or project sections. In some implementations, data logging configurations can also be natively embedded within smart objects. In the case of linked automation objects, data logging configurations can be propagated through a defined object hierarchy, allowing parent objects to control the data logging behavior of child objects.

[0049] Figure 2 This is a block diagram of an example integrated development environment (IDE) system 202 according to one or more embodiments of this disclosure. Aspects of the systems, apparatus, or processes described in this disclosure can constitute machine-executable components contained within a machine, such as machine-executable components contained in 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 equipment, virtual machines, etc., can enable the machines to perform the described operations.

[0050] IDE system 202 may include: a user interface component 204 including an IDE editor 224, a project generation component 206, a project deployment component 208, a project testing component 210, a collaboration management component 212, one or more processors 218, and memory 220. In various embodiments, one or more of the user interface component 204, project generation component 206, project deployment component 208, project testing component 210, collaboration management component 212, one or more processors 218, and memory 220 may be electrically coupled and / or communicatively coupled to each other to perform one or more functions of IDE system 202. In some embodiments, components 204, 206, 208, 210, and 212 may include software instructions stored on memory 220 and executed by processor 218. IDE system 202 may also be compatible with… Figure 2 Interacting with other hardware and / or software components not depicted herein. For example, processor 218 may interact with one or more external user interface devices such as a keyboard, mouse, display monitor, touchscreen, or other such interface devices.

[0051] User interface component 204 can be configured to receive user input and present output to the user in any suitable format (e.g., visual, audio, haptic, etc.). In some embodiments, user interface component 204 can be configured to interact communicatively with an IDE client running on a client device (e.g., a laptop computer, tablet computer, smartphone, etc.) that is communicatively connected to IDE system 202 (e.g., via a hardwired or wireless connection). User interface component 204 can then receive user input data and present output data via the IDE client. In other embodiments, user interface component 204 can be configured to generate suitable interface screens (e.g., program development screens) and provide them to the client device, and to exchange data via these interface screens. Input data that can be received via various embodiments of user interface component 204 may include, but is not limited to, programming code, industrial design specifications or objectives, engineering drawings, AR / VR input, DSL definitions, video or image data, project test scripts, or other such inputs. The output data presented by various implementations of the user interface component 204 may include program code, programming feedback (e.g., errors and highlights, coding suggestions, etc.), programming and visual development screens, project test results, etc.

[0052] Project generation component 206 can be configured to create a system project comprising one or more project files based on design input received via user interface component 204 and industry knowledge, predefined code modules, and visualization and automation objects 222 stored by IDE system 202. Project deployment component 208 can be configured to delegate the system project created by project generation component 206 to appropriate industrial devices (e.g., controllers, HMI terminals, motor drives, AR / VR systems, etc.) for execution. To this end, project deployment component 208 can identify appropriate target devices to which the corresponding parts of the system project should be sent for execution, convert these corresponding parts into a format understandable by the target devices, and deploy the converted project components to their corresponding devices.

[0053] Project testing component 210 can be configured to execute test scripts associated with automation object 222 or other elements of the system project to verify the correct execution of various aspects of the project. Collaboration management component 212 can be configured to track instances of the system project that have been downloaded to local client devices, enabling these local versions of the project to be updated on demand in response to modifications submitted to the cloud-based IDE system.

[0054] One or more processors 218 may perform one or more of the functions described herein with reference to the systems and / or methods disclosed herein. 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 systems and / or methods disclosed ...

[0055] Figure 3 This diagram illustrates the general architecture of an industrial IDE system 202 according to one or more implementations. The industrial IDE system 202 can realize a common set of services and workflows not only across design but also across commissioning, operation, and maintenance. In terms of design, the IDE system 202 can support not only industrial controller programming and HMI development, but also system component sizing and selection, device / system configuration, AR / VR visualization, and other features. The IDE system 202 may also include tools to simplify and automate the commissioning of the resulting project and assist in the subsequent management of the deployed system during runtime.

[0056] The implementation of the IDE system 202 on the cloud platform also facilitates collaborative project development, whereby multiple developers 304 contribute design and programming input to the public automated system project 302. The collaborative tools supported by the IDE system can manage design contributions from multiple contributors and perform version control on the aggregated system project 302 to ensure project consistency.

[0057] Based on design and programming input from one or more developers 304, the IDE system 202 generates a system project 302 comprising one or more project files. The system project 302 encodes one or more of the following: control procedures; HMI, AR, and / or VR visualizations; device or subsystem configuration data (e.g., drive parameters, vision system configuration, telemetry device parameters, safety zone definitions, etc.); or other such aspects of the industrial automation system being designed. The IDE system 202 can identify appropriate target devices 306 (e.g., industrial controllers, HMI terminals, frequency converters, safety devices, etc.) on which the corresponding aspects of the system project 302 should be executed, convert the system project 302 into an executable file that can be executed on the corresponding target device, and deploy the executable file to its corresponding target device 306 for execution, thereby delegating the system project 302 to the factory site to realize the automation project.

[0058] To support enhanced development capabilities, some implementations of the IDE system 202 can be built on an object-based data model instead of a tag-based architecture, or in addition to a tag-based architecture, on an object-based data model. Automation objects 222 serve as building blocks for this object-based development architecture. Figure 4This is a diagram illustrating several example automation object attributes that can be utilized by the IDE system 202 in conjunction with the building, deployment, and execution of system projects 302. Automation objects 222 can be created and expanded during design, integrated into larger data models, and consumed during runtime. These automation objects 222 provide a common data structure across the IDE system 202 and can be stored in an object library (e.g., a portion of memory 220) for reuse. The object library can store predefined automation objects 222 representing various categories of real-world industrial assets 402, including but not limited to pumps, tanks, valves, motors, motor drives (e.g., variable frequency drives), industrial robots, actuators (e.g., pneumatic or hydraulic actuators), or other such assets. Automation objects 222 can represent elements at virtually any level of an industrial enterprise, including individual devices, machines consisting of numerous industrial devices and components (some of which may be associated with their own automation objects 222), and entire production lines or process control systems.

[0059] An automation object 222 for a given type of industrial asset can encode aspects such as 2D or 3D visualization, alarms, control codes (e.g., logic or other types of control programs), analysis, startup procedures, test protocols and scripts, verification reports, simulations, charts, safety protocols, and other attributes associated with the industrial asset 402 represented by object 222. The automation object 222 can also be geotagged with location information identifying the location of the associated asset. During the runtime of system project 302, the automation object 222 corresponding to the given real-world asset 402 can also record status or operational history data for the asset. Typically, the automation object 222 serves as a programmable representation of its corresponding industrial asset 402 and can be incorporated into system project 302 as an element of control codes, 2D or 3D visualizations, a knowledge base or maintenance guidance system for the industrial asset, or other such aspects. Furthermore, as will be discussed in more detail below, the automation object 222 can support inheritance, such that changes to any of the attributes of the automation object 222 discussed above are automatically propagated to instances of automation objects used throughout system project 302.

[0060] Figure 5This diagram illustrates an example data flow associated with creating a system project 302 for an automation system designed using an IDE system 202 according to one or more implementations. A client device 504 (e.g., a laptop computer, tablet computer, desktop computer, mobile device, wearable AR / VR device, etc.) executing an IDE client application 514 can access and utilize the IDE system's project development tools to create a comprehensive system project 302 for the automation system being developed. Through interaction with the system's user interface component 204, developers can submit design inputs 512 to the IDE system 202 in various supported formats, including industry-specific control programs (e.g., control logic, structured text, sequential function charts, etc.) and HMI screen configuration inputs. Based on the design input 512 and the information stored in the industrial knowledge base (predefined code modules 508 and visualizations 510, guardrail templates 506, physics-based rules 516, etc.), the user interface component 204 presents design feedback 518, which is designed to assist developers in configuring, controlling, and visualizing the industrial automation system in conjunction with the development system project 302.

[0061] In addition to control procedures and visualization definitions, some implementations of the IDE system 202 can be configured to receive digital engineering drawings (e.g., computer-aided design (CAD) files) as design input 512. In such implementations, the project generation component 206 can generate parts of the system project 302 based on analysis of existing design drawings, for example, by automatically generating control and / or visualization codes. Drawings that can be submitted as design input 512 can include, but are not limited to, P&ID drawings, mechanical drawings, flowcharts, or other such documents. For example, P&ID drawings can be imported into the IDE system 202, and the project generation component 206 can identify the elements (e.g., tanks, pumps, etc.) conveyed through the drawings and the relationships between them. The project generation component 206 can associate or map the elements identified in the drawings with appropriate automation objects 222 corresponding to these elements (e.g., tanks, pumps, etc.) and add these automation objects 222 to the system project 302. Equipment-specific and asset-specific automation objects 222 include appropriate codes and visualizations to be associated with the elements identified in the drawings. Typically, the IDE system 202 can examine one or more different types of drawings (mechanical, electrical, piping, etc.) to determine relationships between equipment, machines, and / or assets (including identifying common elements across different drawings) and intelligently associate these elements with appropriate automation objects 222, code modules 508, and / or visualizations 510. The IDE system 202 can combine generated code or project data for system project 302, utilizing physics-based rules 516 as needed, and predefined code modules 508 and visualizations 510.

[0062] The IDE system 202 can also determine whether predefined visualizations are applicable to any of the objects discovered in the mapping and generate appropriate HMI screens or AR / VR content for the discovered objects based on these predefined visualizations. To this end, the IDE system 202 can store industry-specific, asset-specific, and / or application-specific visualizations 510 that can be accessed on demand by the project generation component 206. These visualizations 510 can be categorized according to industry or industrial vertical market (e.g., automotive, food and pharmaceuticals, oil and gas, pharmaceuticals, etc.), type of industrial asset (e.g., type of machine or industrial equipment), type of industrial application (e.g., batch processing, flow control, web tension control, sheet metal stamping, water treatment, etc.), or other such categories. Predefined visualizations 510 can include visualizations in various formats, including but not limited to HMI screens or windows, mashups aggregating data from multiple pre-specified sources, AR overlays, VR objects representing 3D virtualizations of associated industrial assets, or other such visualization formats. The IDE system 202 can select an appropriate visualization for a given object based on a predefined association between object type and visualization content.

[0063] In another example, markings applied by the user to engineering drawings can be understood through some implementations of the project generation component 206 to convey specific design intent or parameters. For example, red pen markings can be interpreted as indicating a safety area, two circles connected by a dashed line can be interpreted as a gear relationship, and a thick line can indicate a cam relationship. In this way, designers can draft design goals on existing drawings in a way that the IDE system 202 can understand and utilize to generate code and visualizations. In another example, the project generation component 206 can learn permissions and interlocks (e.g., valves and their associated states) used as necessary prerequisites for starting a machine based on analysis of the user's CAD drawings. The project generation component 206 can generate any suitable code (ladder logic, function blocks, etc.), device configurations, and visualizations for incorporation into the system project 302 based on the analysis of these drawings and markings. In some implementations, the user interface component 204 may include design tools for developing engineering drawings within the IDE platform itself, and the project generation component 206 may generate the code as a background process when the user creates a drawing for a new project. In some implementations, the project generation component 206 can also convert the state mechanism diagram into a corresponding programming sequence, thereby generating at least skeleton code that can be enhanced by developers with additional programming details as needed.

[0064] Furthermore, or alternatively, some implementations of the IDE system 202 can support goal-based automation programming. For example, the user interface component 204 can allow a user to specify the production goals of the automation system being designed (e.g., specifying that the bottling plant being designed must be able to produce at least 5,000 bottles per second during normal operation) and any other relevant design constraints applied to the design project (e.g., budget constraints, available site space, available control cabinet space, etc.). Based on this information, the project generation component 206 will generate parts of the system project 302 to meet the specified design goals and constraints. These parts of the system project 302, which can be generated in this way, may include, but are not limited to, equipment and equipment selection (e.g., how many pumps, controllers, stations, conveyors, drives, or other assets will be needed to meet the definition of the specified goals), associated equipment configurations (e.g., regulation parameters, network settings, drive parameters, etc.), control codes, or HMI screens suitable for visualizing the automation system being designed.

[0065] Some implementations of the project generation component 206 can also generate at least some of the project code for system project 302 based on knowledge of parts already ordered for the project being developed. This may involve accessing customer account information maintained by the equipment supplier to identify equipment already purchased for the project. Based on this information, the project generation component 206 can add appropriate automation objects 222 and associated code modules 508 corresponding to the purchased assets, thereby providing a starting point for project development.

[0066] Some implementations of the project generation component 206 can also monitor customer-specific design approaches for co-programmed functions (e.g., pumping applications, batch processing, palletizing operations, etc.) and generate recommendations for design modules (e.g., code module 508, visualization 510, etc.) that the user might want to incorporate into the current design project, based on inferences about the designer's goals and methods learned to achieve those goals. To this end, some implementations of the project generation component 206 can be configured to monitor design input 512 over time and, based on this monitoring, determine the correlation between certain design actions (e.g., adding certain code modules or segments to the design project, selecting certain visualizations, etc.) and the type, sequence, or process of the industrial asset being designed. The project generation component 206 can record these known correlations and generate recommendations based on these correlations during subsequent project development phases. For example, if the project generation component 206 determines, based on the analysis of the design input 512, that the designer is currently developing a control project involving an industrial piece of equipment that has been programmed and / or visualized in the past in a repetitive and predictable manner, then the project generation component 206 can instruct the user interface component 204 to present recommended development steps or code modules 508 that the designer may wish to incorporate into the system project 302, based on how the equipment has been configured and / or programmed in the past.

[0067] In some implementations, the IDE system 202 may also store and implement guardrail templates 506, which define design guardrails designed to ensure that a project conforms to internal or external design standards. Based on design parameters defined by one or more selected guardrail templates 506, the user interface component 204 may provide dynamic recommendations or other types of feedback as a subset of design feedback 518, which is designed to guide developers in ensuring that system project 302 conforms to internal or external requirements or standards (e.g., certifications such as TUV certification, internal design standards, industry-specific or vertical market-specific design standards, etc.). This feedback 518 may take the form of text-based recommendations (e.g., instructions to rewrite control code to conform to defined programming standards), syntax highlighting, error highlighting, code snippet auto-completion, or other such formats. In this way, the IDE system 202 can customize design feedback 518 according to the type of industrial system being developed and any applicable internal design standards, including programming recommendations, recommendations for predefined code modules 508 or visualizations 510, error highlighting, and syntax highlighting, etc.

[0068] Guardrail templates 506 can also be designed to conform to global best practices applicable to other aspects of control procedures or project development. For example, if a developer's control procedure is deemed too complex (as defined by standards specified by one or more guardrail templates 506), the user interface component 204 can generate and present an alert. Because different vertical markets (e.g., automotive, pharmaceuticals, oil and gas, food and pharmaceuticals, marine, etc.) must comply with different standards and certifications, the IDE system 202 can maintain a library of guardrail templates 506 for different internal and external standards and certifications, including custom-designed, user-specific guardrail templates 506. These guardrail templates 506 can be categorized according to industrial vertical markets, the type of industrial application, plant facilities (in the case of custom-designed internal guardrail templates 506), or other such categories. During development, the project generation component 206 can select and apply a subset of guardrail templates 506 determined to be relevant to the project currently being developed, based on aspects such as the industrial vertical market associated with the project, the type of industrial application being programmed (e.g., flow control, span tension control, specific batch processing, etc.), or other such aspects. Project generation component 206 can utilize guardrail template 506 to enable rule-based programming, thereby presenting programming feedback (a subset of design feedback 518) based on industry expertise and best practices in coding (e.g., identifying inefficiencies in the code being developed and recommending appropriate corrections).

[0069] Users can also run their own internal guardrail template 506 against code provided by external vendors (such as OEMs) to ensure that the code conforms to internal programming standards. In such a scenario, vendor-provided code can be submitted to the IDE system 202, and the project generation component 206 can analyze the code against the internal coding standards specified by one or more custom guardrail templates 506. Based on the results of this analysis, the user interface component 204 can (e.g., using highlighting, overlay text, etc.) indicate portions of the vendor-provided code that do not conform to the programming standards outlined in the guardrail template 506 and display suggestions for modifying the code to conform to the standards. As an alternative to recommending these modifications, or in addition to recommending these modifications, some implementations of the project generation component 206 can be configured to automatically modify the code to conform to the standards based on the recommendations.

[0070] When proposing coding suggestions as part of design feedback 518, project generation component 206 may invoke selected code modules 508 stored in a code module database or selected automation objects 222 stored in an automation object library 502 (e.g., on memory 220). Code modules 508 include standardized coding segments for controlling common industrial tasks or applications (e.g., pallet packaging, flow control, web tension control, pick and place applications, conveyor control, etc.). Similarly, automation objects 222 representing corresponding industrial assets may have standardized control codes associated with them for monitoring and controlling their respective assets. In some implementations, code modules 508 and / or automation objects 222 may be categorized according to one or more of the following: industrial vertical market (e.g., automotive, food and pharmaceutical, oil and gas, textiles, marine, pharmaceuticals, etc.), industrial application, or the type of machine or equipment to which code module 508 or automation object 222 is applicable.

[0071] In some implementations, project generation component 206 can infer the programmer's current programming task or design goal based on program input provided by the programmer (as a subset of design input 512), and determine whether one of the predefined code modules 508 or automation objects 222 can be appropriately added to the control program being developed to achieve the inferred task or goal. For example, project generation component 206 can infer, based on analysis of design input 512, that the programmer is currently developing control code for transferring material from one tank to another, and in response, recommend a predefined code module 508 containing standardized or frequently used code for controlling valves, pumps, or other assets required to achieve the material transfer. Similarly, project generation component 206 can recommend an automation object 222 representing one of the tanks or other industrial assets involved in transferring material (e.g., valves, pumps, etc.), wherein the recommended automation object 222 includes associated control code for controlling its associated assets and a visualization object that can be used to visualize the assets in an HMI application or another visualization application.

[0072] Customized guardrail template 506 can also be defined to capture the nuances of the client site that should be considered in the project design. For example, guardrail template 506 may record the fact that the automation system being designed will be installed in an area where power outages are common, and this factor will be taken into account when generating design feedback 518, such as by recommending the implementation of backup uninterruptible power supplies and suggesting how these power supplies should be combined, as well as recommending programming or control strategies that consider these power outages.

[0073] The IDE system 202 can also use the guardrail template 506 to guide users in selecting equipment or devices for a given design objective, for example, based on: the industrial vertical market, the type of control application (e.g., sheet metal stamping, die casting, pallet packaging, conveyor control, sheet tension control, batch processing, etc.), project budget constraints, physical constraints of the installation site (e.g., available floor space, wall or cabinet space; dimensions of the installation space, etc.), and existing equipment at the site. Some or all of these parameters and constraints can be provided as design input 512, and the user interface component 204 can present equipment recommendations as a subset of design feedback 518. In conjunction with the equipment recommendations, the project generation component 206 can also recommend corresponding automation objects 222 representing the recommended equipment for inclusion in the system project 302.

[0074] In some implementations, project generation component 206 may also determine whether some or all of existing equipment can be repurposed for the new control system being designed. For example, if a new bottling line is to be added to a production area, there may be opportunities to utilize existing equipment since some bottling lines already exist. Decisions about which equipment and facilities can be reused will influence the design of the new control system. Therefore, some design inputs provided to the IDE system 202 as design input 512 may include details of the customer’s existing systems within or near the installation site. In some implementations, project generation component 206 may apply artificial intelligence (AI) or conventional analytical methods to this information to determine whether existing equipment specified in design input 512 can be repurposed or utilized. Based on the results of this analysis, project generation component 206 may generate a list of any new equipment that may need to be purchased as design feedback 518.

[0075] In some implementations, the IDE system 202 can provide design recommendations based on an understanding of the physical environment in which the automation system being designed will be installed. For this purpose, information about the physical environment can be submitted to the IDE system 202 in the form of 2D or 3D images or videos of the factory environment (as part of design input 512). In some implementations, this environmental information can also be obtained from an existing digital twin of the factory or through analysis of scanned environmental data obtained by wearable AR devices. The project generation component 206 can analyze this image, video, or digital twin data to identify physical elements within the installation area (e.g., walls, beams, safety fences, existing machines and equipment, etc.) and the physical relationships between these elements. This can include determining distances between machines, lengths of pipework, locations and distances of wiring harnesses or cable trays, etc. Based on the results of this analysis, the project generation component 206 can add context to the generated schematic diagram as part of system project 302, generate recommendations for optimal locations of equipment or machines (e.g., recommending minimum spacing between power cables and data cables), or make other improvements to system project 302. At least some of these design data can be generated based on physics-based rule 516, which can be referenced by project generation component 206 to determine physical design specifications such as: minimum safe distance from hazardous equipment (which can also be considered as a factor in determining the appropriate installation location of safety equipment relative to the equipment, given the expected human or vehicle reaction time defined by physics-based rule 516), material selection capable of withstanding the expected load, piping configuration and regulation for the specified flow control application, wiring specifications suitable for the expected electrical load, minimum distance between signal wiring and electromagnetic field (EMF) sources to ensure negligible electrical interference to data signals, or other such design features dependent on physics rules.

[0076] In the example use case, the relative positions of machines and equipment specified by the physical environment information submitted to the IDE system 202 can be used by the project generation component 206 to generate design data for an industrial safety system. For example, the project generation component 206 can analyze distance measurements between safety equipment and hazardous machines and, based on these measurements, determine the appropriate placement and configuration of safety equipment and associated safety controllers to ensure that machines will shut down within a sufficient safety reaction time to prevent injury (e.g., in the event of a person crossing a light curtain).

[0077] In some implementations, the project generation component 206 may also analyze photographic or video data of existing machines to determine inline mechanical characteristics such as gears or cams and incorporate that information as a factor into one or more guardrail templates 506 or design recommendations.

[0078] As described above, the system project 302 generated by the IDE system 202 for a given automation system being designed can be built on an object-based architecture that uses automation objects 222 as building blocks. Figure 6 This is a diagram illustrating an example system project 302 incorporating automation objects 222 into a project model. In this example, various automation objects 222 representing assets (e.g., processes, tanks, valves, pumps, etc.) of similar industrial equipment, systems, or automated systems have been incorporated into system project 302 as elements of a larger project data model 602. Project data model 602 also defines the hierarchical relationships between these automation objects 222. According to the example relationships, a process automation object representing a batch process can be defined as a parent object representing multiple child objects of equipment and apparatus such as tanks, pumps, and valves that perform the process. Each automation object 222 has object characteristics or attributes specific to its corresponding industrial asset (e.g., combined with the above). Figure 4 Those discussed include executable control procedures for controlling assets (or for coordinating the actions of assets with other industrial assets) and visualizations that can be used to present relevant information about assets during runtime.

[0079] At least some of the attributes of each automation object 222 are default attributes defined by the IDE system 202 based on coded industry expertise related to the asset represented by the object. These default attributes may include, for example, industry-standard or recommended control codes for monitoring and controlling the asset represented by the automation object 222, 2D or 3D graphical objects that can be used to visualize operations or statistics about the asset, alarm conditions associated with the asset, analysis or reporting scripts designed to generate executable insights into the behavior of the asset, or other such attributes. Developers can modify or add other attributes as needed (via design input 512) to customize the automation object 222 for the specific asset and / or industrial application for which the system project 302 is being developed. This may include, for example, associated custom control codes, HMI screens, AR demonstrations, or help files associated with the selected automation object 222. In this way, automation objects 222 can be created and expanded as needed during design for consumption or execution by the target controlled equipment during runtime.

[0080] Once the development and testing of system project 302 have been completed, the debugging tools supported by IDE system 202 can simplify the process of debugging the project in the field. With system project 302 completed for a given automation system, system project 302 can be deployed to one or more target control devices for execution. Figure 7This diagram illustrates the commissioning of system project 302. Project deployment component 208 can compile or otherwise convert the completed system project 302 into one or more executable files or configuration files that can be stored and executed on the corresponding target industrial equipment of the automation system (e.g., industrial controller 118, HMI terminal 114 or other types of visualization systems, motor drive 710, telemetry device, vision system, safety relay, etc.).

[0081] Conventional control program development platforms require developers to specify the type of industrial controller (e.g., controller model) to which the control program will run before development, thus binding the control program to a specified controller. Controller-specific guardrails are then imposed during program development, limiting how the program can be developed given the capabilities of the chosen controller. In contrast, some implementations of the IDE system 202 can abstract project development based on a specific controller type, allowing designers to develop the system project 302 as a logical representation of an automation system in a way that is agnostic to where and how the various control aspects of the system project 302 will operate. Once the project is developed and the system project 302 is ready for commissioning, the user can (via user interface component 204) specify the target device to execute the corresponding aspect of the system project 302. In response, the allocation engine of the project deployment component 208 converts the aspects of the system project 302 into corresponding executable files formatted for storage and execution on their respective target devices.

[0082] For example, among other project aspects, system project 302 may also include control code, visualization screen definitions, and motor driver parameter definitions. After project development is complete, users can identify which target devices—including industrial controller 118, HMI terminal 114, and motor driver 710—will execute or receive these corresponding aspects of system project 302. Project deployment component 208 can then convert the controller code defined by system project 302 into a formatted control program file 702 for execution on the designated industrial controller 118 and send the control program file 702 to controller 118 (e.g., via factory network 116). Similarly, project deployment component 208 can convert the visualization definitions and motor driver parameter definitions into a visualization application 704 and a device configuration file 708, respectively, and deploy these files to their respective target devices for execution and / or device configuration.

[0083] Typically, project deployment component 208 performs any necessary transformations to enable aspects of system project 302 to be executed on designated devices. Regardless of how the elements of system project 302 are distributed, any inherent relationships, handshakes, or data sharing defined within system project 302 will be maintained. In this way, implementations of IDE system 202 can decouple the project from how and where it will run. This also allows the same system project 302 to be debugged at different plant facilities with different sets of control equipment. That is, some implementations of IDE system 202 can assign project code to different target devices based on the specific devices found in the field. IDE system 202 can also enable portions of the project files to be debugged as emulators or on cloud-based controllers.

[0084] As an alternative to allowing users to specify the target control devices to which system project 302 should be deployed, some implementations of the IDE system 202 can proactively connect to the factory network 116 and discover available devices, identify the control hardware architecture present in the factory field, infer appropriate target devices for the corresponding executable aspects of system project 302, and deploy system project 302 to these selected target devices. As part of this commissioning process, the IDE system 202 can also connect to a remote knowledge base (e.g., a web-based or cloud-based knowledge base) to determine which discovered devices are outdated or require firmware upgrades to properly execute system project 302. In this way, the IDE system 202 can serve as a link between the equipment vendor's and customer's factory ecosystem via a trusted connection in the cloud.

[0085] Intelligent propagation can be used to propagate copies of system project 302 to multiple plant facilities with different equipment configurations, so that even if the field equipment does not perfectly match the defined target (e.g., if different pump types are found at different locations), project deployment component 208 intelligently associates project components with the correct industrial assets or control equipment. For target equipment that does not perfectly match the expected asset, project deployment component 208 can calculate the estimated impact of running system project 302 on suboptimal target equipment and generate warnings or recommendations to reduce the expected deviation from optimal project execution.

[0086] As described above, some implementations of the IDE system 202 can be implemented on a cloud platform. Figure 8This diagram illustrates an example architecture where a cloud-based IDE service 802 is used to develop and deploy industrial applications in a factory environment. In this example, the industrial environment includes one or more industrial controllers 118, HMI terminals 114, motor drives 710, a server 801 running higher-level applications (e.g., ERP, MES, etc.), and other such industrial assets. These industrial assets are connected to a factory network 116 (e.g., a generic industrial protocol network, an Ethernet / IP network, etc.), which facilitates data exchange between industrial devices on the factory floor. The factory network 116 can be wired or wireless. In the example shown, the advanced server 810 resides on a separate office network 108 connected to the factory network 116 (e.g., via a router 808 or other network infrastructure device).

[0087] In this example, IDE system 202 resides on cloud platform 806 and executes as a collection of cloud-based IDE services 802 accessible to authorized remote client devices 504. Cloud platform 806 can be any infrastructure that enables shared computing services (such as IDE services 802) to be accessed and utilized by devices capable of connecting to the cloud. Cloud platform 806 can be a public cloud accessible via the Internet by appropriately authorized devices 504 with Internet connectivity and utilizing IDE services 802. In some scenarios, cloud platform 806 can be provided as a Platform as a Service (PaaS) by a cloud provider, and IDE services 802 can reside on and execute on cloud platform 806 as a cloud-based service. In some such configurations, the owner of IDE services 802 can offer access to cloud platform 806 and associated IDE services 802 as a subscription service to customers. Alternatively, cloud platform 806 can be a private cloud operated internally by an industrial enterprise (owner of factory facilities). An example private cloud platform may include a collection of servers that host IDE services (802) and reside on a corporate network protected by a firewall.

[0088] The cloud-based implementation of IDE system 202 facilitates collaborative development among multiple remote developers authorized to access IDE service 802. When system project 302 is ready for deployment, it can be delegated to the factory facility via a secure connection between office network 108 or factory network 116 and cloud platform 806. As discussed above, industrial IDE service 802 can convert system project 302 into one or more appropriate executable files—control program file 702, visualization application 704, device configuration file 708, system configuration file 812—and deploy these files to appropriate devices in the factory facility to facilitate the implementation of automation projects.

[0089] As described above, the system project 302 generated by the implementation of the industrial IDE system 202 can merge multiple automation objects 222. Figure 9 This is a diagram of example automation object 222, which has been integrated into project data model 602 of system project 302. (See the above for details.) Figure 4 and Figure 6 The system project 302 discussed herein may incorporate instances of automation objects 222 used as programmed representations of industrial assets, processes, or other industrial entities. Assets that can be represented by a given automation object 222 may include equipment-level assets (e.g., motor drives, valves, pumps, etc.) and machine-level assets (presses, tanks, processing stations, etc.). Automation objects 222 may represent off-the-shelf industrial equipment or machines provided by equipment or equipment suppliers, or may include custom automation objects 222 representing custom machines provided by OEMs or other types of machine manufacturers.

[0090] Project data model 602 can define hierarchical relationships between multiple automation objects 222 integrated as part of system project 302. These hierarchical relationships can represent physical and / or functional relationships between the represented assets. Based on example relationships, a process automation object 222 representing a batch process can be defined as a parent object representing multiple sub-automation objects 222 representing the equipment and gear (e.g., tanks, pumps, and valves) performing the process. In another example, an automation object 222 representing a machine or production line can be defined as a parent object, under which multiple sub-automation objects 222 representing workstations or sub-machines within that machine or production line are defined. These sub-automation objects 222 themselves can have multiple sub-automation objects 222 representing the equipment-level assets that make up these workstations or sub-machines.

[0091] Each industrial object 222 can provide functionality similar to that of a data tag serving as a container for input data received from its corresponding industrial asset and output data sent to its corresponding industrial asset (e.g., receiving digital and analog data values ​​from the asset as processed by system item 302, and digital and analog values ​​generated by system item 302 and sent to the asset). Additionally, each industrial object 222 includes multiple programmable attributes relating to the represented industrial asset, examples of which are combined above. Figure 4Discussion. These attributes may include, for example, control logic that can be executed as part of system project 302 to monitor and control the represented asset. This associated control logic can be pre-developed to exchange input and output data with its associated industrial asset via defined input and output tags corresponding to the asset's physical inputs and outputs (i.e., the asset's digital and analog I / O). During the execution of system project 302, the object's control logic can process the inputs received from the asset and generate outputs for said asset based on the results of that processing.

[0092] Furthermore, control logic associated with different automation objects 222, defined by project data model 602 as having hierarchical relationships with each other, can interact or collaborate based on these defined relationships. For example, based on the defined hierarchical relationship between a first automation object 222 representing a tank (defined as the parent object) and a second automation object 222 representing a valve associated with the tank (defined as a child object of the first object), system project 302 can link two sets of control logic associated with the first and second automation objects 222 respectively, such that the control logic associated with these two automation objects 222 performs coordinated monitoring and control of the machine. Linking the two sets of control logic in this way may include, for example, linking the data tags of the child object 222 to the corresponding data tags of the parent object 222 according to the hierarchical relationship defined by model 602.

[0093] Industrial object 222 may also include associated HMI objects that visualization systems (e.g., HMI applications, 2D or 3D augmented reality or virtual reality systems, etc.) can use to present animated graphical representations of assets. These HMI objects may include one or more HMI interface screens designed to present information about the asset (e.g., a report screen presenting statistical or operational data about the asset, a screen presenting an animated graphical representation of the asset, etc.), various graphical objects representing the asset that can be imported into industrial visualization applications, or other such objects.

[0094] Automation object 222 may also include analysis scripts designed to analyze data generated by the asset to produce insights into the asset's performance or operational status. Example analyses that can be performed through the analysis scripts of the automation object may include, but are not limited to, assessing the asset's current operational status and predicted future operational status (e.g., determining the asset's predicted time of failure), determining when the asset requires maintenance, or other such metrics. Similar to the control logic of the automation object, the analysis scripts may be designed to interface with known data items generated by the industrial asset (e.g., asset-specific data tags) so that data associated with these data items can be processed by the scripts.

[0095] Automation object 222 can also define alarm information associated with industrial assets. This alarm information may include definitions of conditions that trigger an alarm (e.g., when a specified data item representing an operational metric of the asset falls outside the defined range of normal behavior, or when the state of a specified digital tag meets alarm conditions, etc.) and alarm messages presented in response to alarm triggering. This alarm information can be referenced by a visualization system (e.g., an HMI application, augmented reality, or virtual reality system, etc.), which can present alarm messages about industrial assets based on the alarm definitions defined by automation object 222.

[0096] Some implementations of the automation object 222 may also define test attributes as part of a global testing framework supported by the IDE system 202. These test attributes may include object-specific test scripts designed to test and debug the automation object 222 and associated aspects of the system project 302 that references the object 222. The object's test attributes may also include object-specific test scenario definitions, which can advantageously be used to run one or more test scenarios against the automation object 222 and associated project elements of the referenced object 222. The test scenario definitions may be pre-designed based on industry expertise related to the industry asset or process represented by the automation object 222. The test attributes associated with the automation object 222 can alleviate the need to write test scripts to test and debug the system project 302.

[0097] Figure 10 This diagram illustrates how the project testing component 210 of the IDE system uses test scripts 1002 bound to automation objects 222 to test sample system project 302. Automation object 222 may be configured with pre-bound test scripts 1002 specific to the type of industrial asset represented by automation object 222 and / or definitions of test scenarios 1004. During or after the development of system project 302 as described above, the project testing component 210 of the IDE system may, as appropriate, execute test scripts 1002 associated with one or more selected automation objects 222 to verify the correct response of system project 302, thereby validating the project. For this purpose, test script 1002 may define simulated test inputs 1012 to be provided to automation object 222 and / or associated project code using object 222, as well as the expected responses of automation object 222 and its associated project code to the simulated inputs 1012.

[0098] According to the example test procedure, the project test component 210 can execute one or more test scripts 1002 associated with one or more corresponding automation objects 222 for system project 302. The execution of the test scripts 1002 may involve, for example, feeding simulated test inputs 1012 to control code or other elements of system project 302 according to a sequence defined by the test scripts 1002; setting values ​​of numerical or simulated program variables defined by system project 302 according to a defined sequence; starting control routines of system project 302 according to a defined sequence; testing animated objects or other visual elements defined by system project 302; verifying data links between control routines; verifying relationships between program elements and drawing elements; confirming that device configuration settings or parameter values ​​are suitable for a given industrial application executed by system project 302; or otherwise interacting with system project 302 according to a test procedure defined by the test scripts 1002. During testing, the project testing component 210 can monitor test results 1006 or the system project 302's response to test interactions defined by test script 1002, and determine whether these test results 1006 match the expected results defined by test script 1002. In this way, the correct operation of the system project 302 can be verified before deployment without developing custom test scripts to debug the system project code.

[0099] In some testing scenarios, test script 1002 can define a test sequence that is applied holistically to system project 302 rather than to a specific control program or routine. For example, project test component 210 can execute test script 1002, which verifies links or relationships across design platforms such as control code, visualization applications, electronic drafting, panel layout definitions, wiring schedules, and piping diagrams—links or relationships that might otherwise not be tested.

[0100] If test result 1006 indicates incorrect operation of one or more aspects of system item 302, item test component 210 may generate and present one or more design recommendations 1008 indicating possible modifications to system item 302 that would correct the operation of the item. These design recommendations 1008 may include, for example, control code modifications or replacements, recommended corrections to data tag addresses, recommended corrections to HMI graphical object references, recommended corrections to mechanical or electrical drawings to align with control codes (e.g., adding missing output devices to electrical drawings corresponding to output devices referenced in control programming), recommended modifications to configuration parameters of industrial equipment, or other such corrections.

[0101] Test attributes for some automated objects 222 can define multiple test scenarios 1004 that should be run on object 222 and its corresponding control code and project elements to ensure comprehensive testing of object 222 and related code. These scenarios 1004 are based on pre-learned industry expertise related to the industrial assets or processes represented by the automated objects and their related project elements. In some implementations, each defined test scenario 1004 may have its own associated test script 1002, or a specific way of applying the test script 1002 may be defined (e.g., verifying which routines of the control code of the system project, which other project elements should be cross-referenced for verification purposes, etc.). During testing of system project 302, project test component 210 can sequentially execute one or more test scripts 1002 according to each defined test scenario 1004 to comprehensively verify the correct operation of system project 302 across all platforms (control programming, visual configuration, drawing, equipment configuration, etc.).

[0102] In some implementations, the project testing component 210 may also be configured to generate a verification checklist based on the analysis of system project 302, and output the verification checklist via user interface component 204. This verification checklist can provide instructions on field tests and checks that should be performed in conjunction with debugging the automated system being developed for system project 302. These field tests and checks may include tests that should be performed on the automated system hardware and electrical connections that cannot be performed solely through testing system project 302. Example verification checklists may include a list of I / O points whose connectivity should be verified, instructions for visually inspecting equipment mounted on panels, a sequence of manual panel interactions that should be performed to verify correct machine operation, or other such information.

[0103] Return to Figure 9 Automation object 222 may also include historical configurations as attributes, which define data generated by the corresponding industrial asset and to be archived in the data history recording device. This historical configuration may be referenced by a data history system or application, which performs this as part of system project 302 to configure the data history system to collect and archive data items defined by that configuration. Similar to other attributes of automation object 222, the historical configuration attribute may specify a subset of available data generated by the corresponding industrial asset based on relevant industry expertise encoded into object 222, known to be relevant to an assessment of the asset's performance or operating condition.

[0104] Some implementations of automation object 222 may also define security features or protocols associated with the associated industrial assets. These security features may include, but are not limited to: definitions of user roles permitted to perform certain actions related to the industrial assets, encryption protocols to be applied to data generated by the assets, network security protocols to be implemented on the assets, or other such security features. The security information defined by these implementations of automation object 222 may be used by system item 302 (e.g., based on user roles) to regulate access to specified functions of the industrial assets, configure network devices to support specified network security protocols, or configure other security-related devices.

[0105] The implementation of the IDE system 202 can support a development architecture, thereby propagating changes made to automation objects 222 stored in the automation object library 502 to instances of those automation objects 222 used in the system project 302. Figure 11 This diagram illustrates the submission of automation object edits 1102 to the IDE system 202. As described above, automation objects 222 are maintained in an automation object library 502 (which may be part of storage 220). Through interaction with the user interface component 204 and the associated IDE editor 224, developers can add selected automation objects 222 from the library 502 to the system project 302 as instances of these automation objects 222. Figure 11 In the example depicted, object 222a is an instance of automation object 222 that the developer has selected and added to system project 302. In some scenarios, project generation component 206 may also automatically select automation object 222 and add it to project 302 based on inferences related to the automation system developing project 302 for it (e.g., based on design goals or engineering drawings submitted to system 202).

[0106] The IDE editor 224 allows the user to modify the properties of selected automation objects 222 stored in library 502. To this end, the user interface component 204 can generate a user interface and (e.g., via IDE client 514) transmit the user interface to client device 504, which enables the user to browse available automation objects 222 and submit edits 1102 to the selected objects 222. The above combination can be modified in this way for any of the defined automation objects 222. Figure 9Any attribute described. For example, a designer might want to modify the control code associated with a specific industrial asset (e.g., a pump, tank, press, etc.) that has an automation object 222 with definitions stored in library 502. Therefore, a user can submit an edit 1102 to update the control code for the associated automation object 222. Such an edit can be used to update the sequence of operations or control behavior for the associated industrial asset.

[0107] Similarly, users can submit edit 1102 to update the visual properties of the selected automation object 222, for example, to replace or edit the graphical representation of the corresponding asset. Edit 1102 can also be submitted to add or remove alerts from the list of alert definitions associated with object 222, or to edit existing alert definitions. Security features, test scripts, and analytics code associated with automation object 222 can also be modified by submitting appropriate edits 1102.

[0108] These edits 1102 target automation object definitions stored in the automation object library 502. Upon receiving an object edit 1102 (submitted via user interface component 204) for the selected automation object 222, the project generation component 206 updates the target automation object 222 based on the received edit 1102 to produce an updated automation object 222. This updated automation object 222 replaces the previous version of the automation object 222 in the library 502.

[0109] If an instance of the automation object 222 that was edited 1102 before receiving edit 1102 has already been added to an existing system project 302, the project generation component 206 can also update all instances of the automation object 222 found within project 302. Figure 12 This diagram illustrates how an instance 222a of an automation object is modified based on an edit 1102 submitted to the master version of the automation object 222 stored in library 502. When the automation object 222 in library 502 has been modified as described above, the project generation component 206 identifies all instances 222a of the automation object used in any system project 302 that uses the object 222 and propagates the modifications to these instances. This may include updating control code, visualization, analysis code, security features, or other attributes reflecting the modifications defined by edit 1102. In this way, all instances 222a of the automation object automatically inherit the modifications made to the master version of the automation object 222 stored in library 502.

[0110] Figure 12 The system project 302 is described as being stored on the IDE system 202 itself (e.g., in a context where...). Figure 8The example scenario depicted (where the IDE system 202 is implemented as a cloud service and stored on a cloud-based storage device) illustrates this. However, in some implementations, the IDE system 202 can also propagate automated object editing to system projects already deployed to local client devices for local editing. Figure 13 This diagram illustrates the downloading of a copy of system project 302 from IDE system 202 to local client device 504. In this example, client device 504 executes an IDE client 514 that allows client device 504 to access the project development tools and environment of the IDE system. IDE client 514 can be provided to client device 504 by IDE system 202, or it can be a client application installed on client device 504 and configured to interface with IDE system 202. The user can interact with IDE client 514 to copy version 3021 of system project 302 from the cloud-based IDE system 202 to the local storage device of the client device for local viewing and development. After the local version 3021 has been copied, a primary copy of system project 302 is stored on IDE system 202.

[0111] Once copied to client device 504, developers can use the project development tools supported by IDE client 514 to view and edit the local version 3021. At least some of these development tools may be similar to those supported by IDE system 202 described above (see, for example...). Figure 5 For example, some implementations of the IDE client 514 can support the use of design guardrails to ensure that local edits made to the local version 3021 of the project—such as control program changes, HMI modifications, changes to equipment configuration parameters, modifications to automation objects, etc.—comply with internal or external design standards. As in the previous examples, various implementations of the IDE client 514 can enable users to submit edits to the local version 3021 of the project as one or more of the following design inputs: control programming (e.g., ladder logic, DLS programming, sequential function charts, structured text, function block diagrams, etc.), design changes to visual applications such as HMIs (e.g., adding, removing, or repositioning graphical objects), industrial equipment configuration parameter values, or other such design inputs.

[0112] In the example scenario, the developer can choose to modify the existing system project 302 to suit deployment on an automation system that deviates from a typical installation and requires modification of system project 302. For example, system project 302 may be designed to program and configure a standardized automation system built to perform specific industrial functions and installed at multiple locations or facilities within an industrial enterprise. New installations of this automation system can deviate from the standard installation in various ways, including but not limited to replacing one or more devices in the automation system with equipment from alternative suppliers, adding or omitting workstations, installation modifications to adapt to the physical limitations of the installation location, special control requirements deviating from standard requirements (e.g., differences in product design, control modifications to adapt to differences in materials or components used to manufacture the product), or other such deviations. To accommodate these changes, the developer can download a local version 3021 of system project 302 and implement the necessary modifications on the local version 3021.

[0113] Figure 14 This diagram illustrates the propagation of automated object edits to a local storage copy of system item 302. In this example scenario, the user at client device 504b has already downloaded the above-described combination... Figure 13 The system project 302 described is a local version 3021. The main version of the automation object library 502, containing automation objects 222, is still stored on the cloud platform associated with the IDE system 202. This allows any authorized developer to access the automation library 502 to not only add selected automation objects 222 to the system project 302, but also to modify selected automation objects 222 as part of project development, or to reflect modifications to the corresponding industrial assets represented by objects 222. Figure 14 In the example shown, the developer at client device 504a submits a set of edits 1102 for a selected automation object 222 stored in library 502 (e.g., updating the object's control code, visual representation, test scripts, etc.). In response to receiving these edits 1102, project generation component 206 ( Figure 14 (Not shown in the image) Update the main version of the selected automation object 222 stored in library 502 according to edit 1102.

[0114] Furthermore, given that the selected automation object 222 has already been edited, the project generation component 206 also identifies all local and remote storage versions of any system project 302 that has incorporated instances of the selected automation object 222. This includes identifying any system project 302 stored on a cloud storage device associated with the IDE system 202, as well as any version 3021 of the system project 302 that has been downloaded to a local client device (e.g., client device 504b) for local development. In this regard, the collaboration management component 210 can track all instances of the system project 302 that have been downloaded to the local client device, enabling these local versions of the project 302 to be updated on demand in response to modifications submitted to the cloud-based IDE system 202.

[0115] In response to the submission of object edit 1102 and the corresponding modification to the major version of the automation object 222 targeted by edit 1102, project build component 206 also distributes automation object update 1402 to all IDE clients 514b on which local version 3021 of system project 302 using automation object 222 is stored. Update 1402 reflects the automation object edit 1102 submitted by the developer using client device 504a, and when executed by local IDE client 514b, update 1402 updates all instances of automation object 222 according to edit 1102. In this way, updates to automation object 222 in object repository 502 are automatically broadcast to all instances of object 222 currently in use in system project 302.

[0116] In some implementations, the local developer at client device 504b may be provided with the option to allow update 1402 to be incorporated into their local version 3021 of system project 302 or to refuse to implement update 1402. Thus, before updating the local version of automation object 222, user interface component 204 may present information about object edits 1102 on the user's client device 504b, and may also present a prompt for the developer to approve the local implementation of the edits. Information about the edits 1102 may include, for example, the identity of the automation object 222 affected by these edits and a summary of each modification to object 222 to be implemented through the edits (e.g., indications of which object properties will be modified and how those properties will be changed). Based on a review of these edits, the local developer may choose to implement update 1402 on their local version 3021, or alternatively, the local developer may choose to refuse the edits and prevent the implementation of update 1402 on the local version 3021 of project 302.

[0117] As described above, project data model 602 can define the hierarchical relationships between multiple automation objects 222 included in system project 302 (see, for example, Figure 6 ). Figure 15 It is a graphical representation of a simple two-level relationship between automated objects 222. Figure 15 The representation depicted can be generated by the user interface component 204 and presented within the development interface of the IDE system 202. At least some of the hierarchical relationships between the automation objects 222 can be defined by the user during project development. For example, a portion of the design input 512 submitted by the user can specify the automation objects 222 to be included in the system project 302, as well as the links between the automation objects 222 that define their functionality or hierarchical relationships. Figure 15 In the example depicted, the first automation object 222a representing the tank (tank 100) is linked to two other automation objects 222b and 222c representing the tank inlet solenoid valve and the tank outlet solenoid valve, respectively. The valve automation objects 222b and 222c serve as child objects of the parent tank object 222a, thus reflecting the functional relationships of similar physical assets.

[0118] Each automation object 222 has multiple associated inputs and outputs, represented as marker nodes 1502 on a graphical representation of the object. The available inputs and outputs for object 222 depend on the type of industrial asset, equipment, process, or entity represented by object 222. Users can define relationships between objects 222 as data links between selected inputs and outputs of object 222. For example, the output of inlet valve object 222b, representing the closed state of a corresponding valve, can be linked to an input on tank automation object 222a to read the closed state of the inlet valve. This link allows the closed state of the inlet valve to be provided to and processed by tank object 222a. The open state output of inlet valve object 222b can similarly be linked to an appropriate input on tank object 222a. A similar data link can be defined between tank object 222a and outlet valve object 222c. Links between the inputs and outputs of objects can be represented by connection lines 1504 between nodes 1502 representing the linked inputs and outputs.

[0119] By selectively linking the inputs and outputs of automation objects 222 in this way, hierarchical parent-child relationships can be defined for any number of automation objects 222 in system project 302, and these relationships can be recorded in a manner such as... Figure 6 The project data model 602 is shown below. Although... Figure 15Only a two-level hierarchy consisting of three automation objects 222 is depicted, but any number of automation objects 222 representing various industrial assets, equipment, processes, production lines, plants, or other industrial entities can be linked to form object hierarchies with more than two levels. These defined hierarchies can reflect the functional or hierarchical relationships between the corresponding industrial entities and assets. For example, an object 222 representing a plant can have multiple sub-objects 222 representing production lines, and the production line itself can have sub-objects 222 representing the machines and industrial equipment that make up the corresponding line.

[0120] If system project 302 is viewed during runtime, and the project view is animated using real-time data from the running automation system, then user interface component 204 can present object 222, associated links, and data flow between objects 222. Figure 15 In the example depicted, a numerical value is presented next to each object node 1502, where the value represents the value currently being generated or consumed by that node 1502.

[0121] Creating the hierarchical relationships between automation objects 222 in this way is a project development pattern supported by the IDE system 202, which is used to define the functional aspects of the resulting system project 302. For example, as described above, linking two or more automation objects 222, each having associated control logic for monitoring and controlling its corresponding industrial assets, allows the control logic associated with the respective object 222 to be linked, such that data values ​​generated by the logic of one automation object 222 are consumed by the logic of another linked automation object 222 according to the user-defined link. The resulting aggregated control logic can be used to monitor and control the aggregated system represented by the linked automation objects (e.g., ...). Figure 15 (The system of tanks and valves depicted in the image).

[0122] The parent-child relationships between automation objects 222 can also determine the inheritance of object configurations between those objects 222. For example, as mentioned above, some automation objects 222 may include historical configuration attributes that define data logging characteristics for associated industrial assets. At least some of these data logging attributes can be set by the user during the design phase of system project 302; for example, by submitting data logging configuration parameters of automation objects 222 as part of design input 512 (see...). Figure 5Data logging configuration parameters—and other properties of the automation object 222—can be set by invoking an object editing window that allows users to view and edit the object's modifiable properties. This window can be accessed by selecting the object property button 1506 associated with each object representation. In other scenarios, the data logging properties associated with a given automation object 222 can be predefined as part of the object's default configuration based on pre-coded knowledge of the public data collection requirements of the industrial asset represented by the object 222.

[0123] During runtime, the data logging configuration parameters associated with automation object 222 can be referenced by applications or data history systems that are part of the execution system project 302. In some implementations, project deployment component 208 can convert the data logging configuration or history associated with each automation object instance into a suitable data history profile, which can then be sent to appropriate data collection systems to configure them based on the object's history configuration parameters. The object's data logging configuration instructs the data history system about which data items associated with the object's corresponding industrial asset should be collected and archived, and may also specify other data logging attributes, including but not limited to the frequency of data item collection, the location to store the recorded data, the organization or pattern of the recorded data, etc. The object's history configuration may also specify the conditions for collecting specific data items; for example, based on periodic time series or in response to defined trigger conditions. In this way, data history attributes natively embedded within automation object 222 can facilitate the collection and archiving of data generated by controlled industrial systems using data history configurations.

[0124] If an automation object 222 with data history attributes, as discussed above, is linked to other automation objects as part of an object hierarchy, then the data record attributes associated with object 222 can propagate upwards or downwards along the hierarchy to other linked automation objects 222. The way data record configuration information is propagated across the object hierarchy can depend on the parent-child relationships defined between objects 222. For example, in... Figure 15 In the example depicted, tank object 222a is used as a parent object of two sub-objects 222b and 222a that represent the inlet valve and outlet valve of the tank. The data history configuration associated with tank object 222a can not only define the data recording attributes of the tank itself, but also control how and when data is recorded for the two valves represented by sub-objects 222b and 222c.

[0125] Typically, a parent automation object 222 representing a specific asset (e.g., a tank, a press, etc.) can be pre-coded with asset-specific knowledge of which sub-assets (e.g., valves, motor drives, etc.) are typically associated with the parent asset, and knowledge of the data available from these sub-assets. Based on this knowledge, and data recording attributes defined for the parent object 222 (user-defined or predefined), the parent object 222 can identify the conditions under which data generated by the sub-assets should be collected and archived, as well as the frequency at which data should be collected from the sub-assets, the location where data should be archived, or other such data recording characteristics. Based on this information, the parent object 222 can configure the data recording attributes of the sub-assets accordingly, thereby producing an aggregated data recording configuration for the monitored and controlled automation system.

[0126] In some implementations, the user-defined data history attributes of the selected automation object 222 can be used as the automation object editor 1102 (see [link]). Figure 11 The changes are submitted to the main version of automation object 222 stored in the automation object repository 502. In some scenarios, system 202 can propagate historical configuration edits to the above-mentioned combination. Figure 12 Other instances of the modified automation object 222 described. Alternatively, the user can specify that the edits apply only to subsequently created instances of the automation object 222, such that existing instances of the automation object maintain their existing configuration, while instances created after the edits are submitted will reflect the new data recording configuration.

[0127] Some implementations of the IDE system 202 allow users to encapsulate multiple layers of automation objects 222 into a single encapsulated object, which can be moved or copied throughout the system project 302. Figure 16 These are example graphical representations of three packaged automation objects 1602a to 1602c. Package object 1602a is a can 100. Figure 15 The object hierarchy depicted is an encapsulated version, with encapsulated objects 1602b and 1602c representing object hierarchies of two other tanks (tank 200 and tank 500). Encapsulated object 1602 serves as a reusable unit representation of an object hierarchy with any number of hierarchical levels. Each encapsulated object 1602 may have associated inputs and outputs that allow the encapsulated object to be linked to other automation objects 222 or encapsulated object 1602. Figure 16 (Not shown in the diagram). The inputs and outputs associated with a given encapsulated object 1602 may depend on the various automation objects 222 within the hierarchy represented by the encapsulated object 1602 and the relationships defined between these objects 222.

[0128] Once created, the encapsulated object 1602 can be moved or copied as needed throughout system project 302 or between projects. When the encapsulated object 1602 is copied, the entire hierarchy of automation objects represented by the encapsulated object 1602 is copied at the location of the new instance of the encapsulated object 1602. The new instance of the encapsulated object 1602 includes all automation objects 222 included in the original encapsulated object 1602, the object attributes associated with those objects 222, and the data links between the objects 222 defined in the original encapsulated object 1602. If system project 302 is being viewed during the runtime of the monitored and controlled automation system, the user can select and expand the encapsulated object 1602 to view the hierarchy of linked automation objects 222 represented by the encapsulated object 1602, and the data flow between those objects 222. Figure 15 and Figure 16 In the example depicted, Figure 16 The encapsulated object 1602a depicted in the diagram expands to display system 202. Figure 15 The diagram shows the hierarchy of automation objects and the real-time data flow between linked objects 222. The hierarchical representation can then be selectively collapsed back into the encapsulated representation as needed.

[0129] By allowing a multi-level collection of linked automation objects 222 to be encapsulated within a reusable encapsulated object 1602 as described above, system 202 allows scaling of the selected object hierarchy across system projects 302 or between projects 302 as needed. This encapsulation method is not limited to encapsulation of object hierarchies. More precisely, in some implementations, encapsulated object 1602 may represent any combination of automation objects, control code routines (e.g., code module 508 or custom routines), or other program elements supported by IDE system 202.

[0130] As described above Figure 7 and Figure 8 As shown, system project 302 may include device configuration information as part of the project definition. This device configuration information can be converted into device profile 708 by project deployment component 208, and then device profile 708 can be deployed to its corresponding industrial equipment to facilitate the configuration of those devices according to the system project definition. Some implementations of IDE system 202 may allow the device configuration information to be defined as an attribute of automation object 222 corresponding to the industrial equipment to be configured. The device configuration information of a given automation object 222 can be used as an automation object edit 1102 for that object 222 (see [link]). Figure 11A portion of the configuration is submitted to system 202. In the example scenario, the device parameters of automation object 222 can be edited by invoking an object editing window accessible via edit button 1506 on object 222. The specific device parameters presented and available for editing in this editing window depend on the type of industrial equipment represented by the automation object. Once the user has set the device configuration parameters as needed, the edited device configuration becomes an embedded attribute of automation object 222, which remains bound to object 222. When system project 302 is deployed by project deployment component 208 (see...), the system configuration is then... Figure 7 and 8 Any device configuration information embedded in the automation object 222 included in project 302 is converted into the corresponding device configuration file 708 of the industrial device represented by object 222, and the resulting device configuration file 708 is deployed to the device.

[0131] Industrial equipment that can be configured in this way may include, but is not limited to, motor drives, industrial controllers, telemetry devices, industrial robots, HMI terminals or other types of visualization devices, safety relays, data recording devices, network infrastructure equipment (e.g., routers, hubs, switches, etc.), or other industrial equipment. Essentially any type of equipment configuration parameters can be associated with automation object 222 for deployment to associated industrial equipment, including but not limited to network or communication settings (e.g., network address), operating mode settings, upper or lower operating limits, operating parameters (e.g., parameters of variable frequency drives or other types of industrial equipment), scaling factors, safety settings, power settings, security settings, or other such equipment configuration settings.

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

[0133] Figure 17An example method 1700 for creating and encapsulating hierarchical levels of automation objects within an industrial system project using an industrial IDE system is illustrated. First, at 1702, design input is received via interaction with the industrial IDE system. The design input may be submitted in one or more of the following forms: industrial controller programs (e.g., ladder logic, sequential function charts, script control codes such as industrial DSLs, etc.), HMI screen development input, industrial equipment or gear selection, engineering drawing input, etc. In some embodiments, the design input may also include complete engineering drawings (e.g., P&ID drawings, electrical drawings, mechanical drawings, etc.), which can be parsed and analyzed by the industrial IDE to identify components (e.g., industrial equipment, machines, gears, conduits, pipes, etc.) in the industrial automation system being designed, as well as the functional and physical relationships between these components.

[0134] Design input also includes selecting automation objects from a library for inclusion in the system project. Automation objects are building blocks of industrial automation system projects and represent various types of real-world industrial assets or processes, including but not limited to pumps, tanks, valves, motors, motor drives (e.g., variable frequency drives), industrial robots, actuators (e.g., pneumatic or hydraulic actuators), or other such assets. Automation objects are associated with various attributes or characteristics (e.g., control codes, visual objects or interfaces, test scripts, safety features or protocols, etc.) depending on the asset or process they represent.

[0135] At 1704, additional design inputs defining the hierarchical relationships between the selected automation objects added to the project in step 1702 are received, thereby generating a hierarchy of automation objects. In some implementations, the hierarchical relationships can be defined via interaction with a graphical representation of the automation objects presented in the development workspace of the IDE system. For example, inputs and outputs associated with automation objects can be selectively linked to each other to specify that selected output data from a first automation object will be consumed by selected data inputs from a second automation object. These links can define parent-child relationships between the selected automation objects, thereby generating an object hierarchy that reflects the physical and / or functional relationships between the physical industrial assets represented by the objects. The hierarchical relationships can link the functions or attributes of automation objects; for example, by merging control codes associated with linked objects to generate control programs capable of monitoring and controlling an automation system including the represented industrial assets.

[0136] At 1706, a determination is made regarding whether an instruction to encapsulate the hierarchy of automation objects defined in step 1704 has been received. If such an instruction is received (yes at step 1706), the method proceeds to step 1708, in which a single encapsulation object representing the hierarchy of automation objects is created. The encapsulation object includes data inputs and outputs that can be linked to other automation objects or encapsulation objects. The inputs and outputs of the encapsulation object depend on the individual automation objects represented by the encapsulation object and the relationships defined between them. The encapsulation object is extensible across system projects, allowing it to be moved or copied across projects or multiple projects. When an encapsulation object is copied, the new instance of the encapsulation object includes the functionality of the automation object hierarchy defined for the original encapsulation object, as well as any user-defined attributes of the automation objects constituting the hierarchy.

[0137] Figure 18a The first part of Example Method 1800a is shown. Example Method 1800a is used to configure the data logging attributes of an automation system to be monitored and controlled by the system project within an automation system project. First, at 1802, design input is received via interaction with an industrial IDE system (similar to step 1702 of Method 1700). At 1804, additional design input is received, defining the hierarchical relationships between the selected automation objects added to the project in step 1802, thereby generating a hierarchy of automation objects (similar to step 1704 of Method 1700).

[0138] At 1806, other design inputs are received, which set the data recording configuration settings of the industrial asset as attributes of a first automation object representing the industrial asset within the automation object. These data recording configuration settings may include, but are not limited to, the identity of the data items to be collected and archived associated with the corresponding industrial asset of the object, the frequency of data collection, the storage location of the recorded data, and the organization or pattern of the recorded data. At 1808, the data recording configuration settings received in step 1806 are associated with the first automation object, making the data recording configuration an embedded attribute of the object.

[0139] At step 1810, based on the object hierarchy defined in step 1804, a determination is made regarding whether the first automation object has a parent-child relationship with the second automation object in the hierarchy. If such a relationship is defined ("Yes" at step 1810), the method proceeds to step 1812, where the data recording configuration of the second automation object is set based on the defined relationship between the first and second automation objects and the data recording configuration of the first automation object. In the example scenario, based on the object relationship and the data recording configuration of the first object, the first object can identify the conditions under which data generated by the corresponding asset of the second object should be collected and archived, as well as the frequency at which the data should be collected, the location where the data should be archived, or other such data recording characteristics. Based on this information, the first object can configure the data recording attributes of the second object accordingly, thereby generating an aggregated data recording configuration for the monitored and controlled automation system.

[0140] Then the method proceeds to... Figure 18b The second part, 1800b, is shown. At 1814, a determination is made as to whether an instruction to deploy the system project has been received. If such an instruction is received ("Yes" at step 1814), the method proceeds to step 1816, in which the system project is compiled into one or more executable files that can be deployed and executed on industrial equipment of the automation system. The executable files include historical configuration files that configure one or more data histories according to data record configurations defined in the first and second automation objects.

[0141] Figure 19 An example method 1900 for defining industrial equipment configurations within an automation system project using automation objects is shown. First, at 1902, design input for the industrial automation system project is received via interaction with an industrial IDE system (similar to step 1702 of method 1700). At 1904, additional design input is received defining hierarchical relationships between selected automation objects to generate a hierarchy of automation objects (similar to step 1704 of method 1700).

[0142] At 1906, other design input is received, which sets the device configuration parameters of the industrial equipment to attributes representing the automation object of the industrial equipment. Example device configuration parameters that can be set in this way may include, but are not limited to, network or communication settings (e.g., network address), operating mode settings, upper or lower operating limits, operating parameters (e.g., parameters of a variable frequency drive or another type of industrial equipment), scaling factors, safety settings, power settings, or other such device configuration settings. In some embodiments, the device configuration parameters can be set by interacting with a graphical representation of the automation object to invoke a device configuration window that allows the user to input values ​​for the configuration parameters. The device parameters presented in this configuration window and available for editing depend on the type of industrial equipment represented by the automation object. At 1908, the device configuration parameters received in step 1906 are associated with the automation object such that the parameters become embedded attributes of the object.

[0143] At step 1910, a determination is made regarding whether an instruction to deploy the system project has been received. If such an instruction is received ("Yes" at step 1910), the method proceeds to step 1912, in which the system project is compiled into one or more executable files that can be deployed and executed on industrial equipment within the automation system. The executable files include device configuration files that configure the industrial equipment corresponding to the automation object according to device configuration parameters defined in the automation object.

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

[0145] Similarly, the term PLC or automation controller as used herein can 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 collaborate with various networked devices across a network. This can include virtually any type of controller, communication module, computer, input / output (I / O) device, sensor, actuator, and human-machine interface (HMI) communicating via a network, including control networks, automation networks, and / or public networks. PLCs or automation controllers can also communicate with and control a variety of other devices, such as standard or safety-rated I / O modules including analog modules, digital modules, programmable / intelligent I / O modules, other programmable controllers, communication modules, sensors, actuators, output devices, etc.

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

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

[0148] Typically, program modules include routines, programs, components, data structures, etc., that perform specific tasks or implement specific abstract data types. Furthermore, those skilled in the art will understand that the methods of this invention can be practiced with 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 operatively coupled to one or more associated devices.

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

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

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

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

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

[0154] Refer again Figure 20 An example environment 2000 for implementing various embodiments of the various 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, including but not limited to the system memory 2006, to the processing unit 2004. The processing unit 2004 can be any of a variety of commercially available processors. A dual-microprocessor or other multiprocessor architecture may also be used as the processing unit 2004.

[0155] System bus 2008 can be any of several types of bus architectures, which can also use any of a variety of commercially available bus architectures to interconnect to memory buses (with or without memory controllers), peripheral buses, and local buses. System memory 2006 includes ROM 2010 and RAM 2012. The Basic Input / Output System (BIOS) can be stored in non-volatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM, wherein the BIOS contains basic routines that facilitate the transfer of information between elements within the computer 2002, for example, during startup. RAM 2012 may also include high-speed RAM such as static RAM for caching data.

[0156] Computer 2002 also includes an internal hard disk drive (HDD) 2014 (e.g., EIDE, SATA), one or more external storage devices 2016 (e.g., floppy disk drive (FDD) 2016, memory stick or flash drive reader, memory card reader, etc.), and an optical disc drive 2020 (e.g., capable of reading from or writing to CD-ROMs, DVDs, BDs, etc.). Although the internal HDD 2014 is shown as residing within computer 2002, it can also be configured for external use in a suitable chassis (not shown). Additionally, although not shown in environment 2000, a solid-state drive (SSD) may be used in addition to the HDD 2014, or an SSD may replace the HDD 2014. The HDD 2014, external storage devices 2016, and optical disc drive 2020 can be connected to the system bus 2008 via HDD interface 2024, external storage interface 2026, and optical drive interface 2028, respectively. The interface 2024 for the external driver implementation may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external driver connectivity technologies are considered in the implementations described herein.

[0157] Drives and their associated computer-readable storage media provide non-volatile storage of data, data structures, computer-executable instructions, etc. For Computer 2002, drives and storage media are adapted to store any data in a suitable digital format. Although the above description of computer-readable storage media refers to a corresponding type of storage device, those skilled in the art will understand that other types of computer-readable storage media, whether currently existing or developed in the future, can also be used in the example operating environment, and furthermore, any such storage medium may contain computer-executable instructions for performing the methods described herein.

[0158] Multiple program modules can be stored in the drive and 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.

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

[0160] Furthermore, the computer 2002 can be enabled using a security module such as a Trusted Processing Module (TPM). For example, using a TPM, the startup component hashes the next startup component in time and waits for the result to match a security value before loading the next startup component. This process can occur at any layer of the computer 2002's code execution stack, such as at the application execution level or the operating system (OS) kernel level, thus enabling security to be implemented at any code execution level.

[0161] Users can input commands and information into computer 2002 through one or more wired / wireless input devices such as keyboard 2038, touchscreen 2040, and pointing devices such as mouse 2042. Other input devices (not shown) may include microphone, infrared (IR) remote control, radio frequency (RF) remote control, or other remote control, joystick, virtual reality controller and / or virtual reality headset, gaming pad, stylus, image input device (e.g., camera), gesture sensor input device, visual motion sensor input device, emotion or face detection device, biometric input device (e.g., fingerprint or iris scanner), etc. These and other input devices are typically connected to processing unit 2004 via input device interface 2044, which can be coupled to system bus 2008, but may also be connected via other interfaces such as parallel port, IEEE 1394 serial port, gaming port, USB port, IR interface, etc. Connect via interfaces, etc.

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

[0163] Computer 2002 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 2048, via wired and / or wireless communications. Remote computer 2048 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer-to-peer device, or other general-purpose network node, and typically includes many or all of the elements described relative to computer 2002, although only memory / storage device 2050 is shown for simplicity. 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 connect to global communication networks such as the Internet.

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

[0165] When used in a WAN networking environment, computer 2002 may include modem 2058, or may be connected to a communication server on WAN 2054 via other means for establishing communication over WAN 2054, such as via the Internet. Modem 2058, which may be an internal or external wired or wireless device, may be connected to system bus 2008 via input device interface 2042. In a networking environment, program modules described relative to computer 2002 or parts thereof may be stored in remote memory / storage device 2050. It will be understood that the network connection shown is an example and other means of establishing communication links between computers may be used.

[0166] When used in a LAN or WAN networking environment, in addition to or replacing the external storage device 2016 as described above, the computer 2002 can also access cloud storage systems or other network-based storage systems. Typically, a connection between the computer 2002 and the cloud storage system can be established, for example, via adapter 2056 or modem 2058 through LAN 2052 or WAN 2054. When connecting the computer 2002 to an associated cloud storage system, the external storage interface 2026 can manage the storage provided by the cloud storage system, just as other types of external storage, with the help of adapter 2056 and / or 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 the computer 2002.

[0167] Computer 2002 is operable to communicate with any wireless device or entity operatively arranged in wireless communication, such as printers, scanners, desktop and / or portable computers, portable data assistants, communication satellites, any equipment or location associated with wirelessly detectable tags (e.g., kiosks, newsstands, shop shelves, etc.), and telephones. This can include Wi-Fi and... Wireless technology. Therefore, communication can be a predefined structure like a conventional network or simply self-organized communication between at least two devices.

[0168] Figure 21 This is a schematic block diagram of a sample computing environment 2100 with which the disclosed subject matter can interact. The sample computing environment 2100 includes one or more clients 2102. Clients 2102 can be hardware and / or software (e.g., threads, processes, computing devices). The sample computing environment 2100 also includes one or more servers 2104. Servers 2104 can also be hardware and / or software (e.g., threads, processes, computing devices). Servers 2104 can accommodate threads to perform transformations by employing one or more implementations, such as those described herein. One possible communication between clients 2102 and servers 2104 can be in the form of data packets suitable for transmission between two or more computer processes. The sample computing environment 2100 includes a communication framework 2106 that can be used to facilitate communication between clients 2102 and servers 2104. Clients 2102 are operatively connected to one or more client data storage devices 2108 that can be used to store local information of clients 2102. Similarly, server 2104 is operatively connected to one or more server data storage devices 2110 that can be used to store local information of server 2104.

[0169] The foregoing description includes examples of the invention. It is certainly impossible to describe every conceivable combination of components or methodologies in order to describe the disclosed subject matter, but those skilled in the art will recognize that many other combinations and substitutions of the invention are possible. Therefore, the disclosed subject matter is intended to cover all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

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

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

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

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

Claims

1. A system for developing industrial applications, comprising: A memory that stores executable components and a library of automation objects representing corresponding industrial assets, the automation objects having corresponding programming attributes associated with the industrial assets; as well as A processor operatively coupled to the memory, the processor executing the executable component, the executable component comprising: A user interface component, configured to present an integrated development environment (IDE) interface and receive design input via interaction with the IDE interface, the design input defining various aspects of an industrial automation project; and A project generation component, configured to generate system project data based on the design input. in, The system project data defines a system project, including at least one of the following: executable industrial control programs, industrial visualization applications, or industrial equipment configuration data. The system project data also includes an instance of a first automation object selected from the library of automation objects, and An instance of the first automation object includes one or more data record configuration parameters as one of the programming attributes, which configure the data collection system in response to the deployment of the data collection system to collect data generated by the industrial asset represented by the instance of the first automation object. The system project data also defines the hierarchical relationship between instances of the first automation object and instances of the second automation object, and The project generation component is also configured to set one or more data record configuration parameters for the instance of the second automation object as follows: Based on the hierarchical relationship and the data recording configuration parameters of the instance of the first automated object, the first automated object identifies the conditions under which data generated by the asset corresponding to the second automated object should be collected; and The first automation object configures the data record configuration parameters of the second automation object instance based on the identified conditions.

2. The system according to claim 1, wherein, The data recording configuration parameters include at least one of the following: the identity of the data item to be collected by the data collection system generated by the industrial asset, the frequency at which the data item is to be collected by the data collection system, the storage location where the data collection system will store the data item, the organization of the data item, or the conditions for triggering the collection of the data item.

3. The system according to claim 1, wherein, At least one of the data record configuration parameters is editable via interaction with a graphical representation of the instance of the first automation object.

4. The system according to claim 1, wherein, The project generation component is configured to define the hierarchical relationship to generate an object hierarchy based on a subset of specified design inputs, using one or more links between the inputs and outputs of the first automation object instance and the inputs and outputs of the second automation object instance.

5. The system according to claim 4, wherein, The project generation component is also configured to, in response to receiving instructions encapsulating the object hierarchy, create a single encapsulated object representing the object hierarchy, and The encapsulated object can be extended across the system projects.

6. The system according to claim 1, wherein, An instance of the first automation object also includes device configuration parameter settings as one or more of the programming attributes, the device configuration parameter settings defining the values ​​of device configuration parameters of the industrial asset represented by the instance of the first automation object.

7. The system according to claim 6, wherein, The project generation component is configured to generate device configuration data based on device configuration parameter settings associated with an instance of the first automation object. The device configuration data configures the industrial asset represented by the instance of the first automation object according to the device configuration parameter settings in response to the deployment of the industrial asset represented by the instance of the first automation object.

8. The system according to claim 6, wherein, The device configuration parameter settings include at least one of the following: network address, communication settings, operation mode settings, operation upper or lower limit, operation parameters, scaling factor, security settings, power settings, or safety settings.

9. The system according to claim 1, wherein, The automated object is represented as at least one of the following as the industrial asset: industrial process, controller, control program, tag within the control program, machine, motor, motor driver, telemetry device, tank, valve, pump, industrial safety equipment, industrial robot or actuator.

10. A method for developing industrial applications, comprising: The integrated development environment (IDE) interface is presented on the client device by the system, which includes the processor. The system receives design input via interaction with the IDE interface, the design input defining various aspects of the industrial control and monitoring project; as well as The system generates system project data based on the design input. The system project data includes at least one instance of a first automation object selected from a library of automation objects. Each automation object represents a corresponding industrial asset and has relevant programming attributes associated with that industrial asset. in, The generation includes generating at least one of the following: an executable industrial control program, an industrial visualization application, or industrial equipment configuration data. An instance of the first automation object includes one or more data record configuration parameters as one of the programming attributes, which configure the data history system to collect data generated by the industrial assets represented by the instance of the first automation object in response to the deployment of the data history system. The receipt of design input includes receiving the definition of the hierarchical relationship between instances of the first automation object and instances of the second automation object, and The method further includes: In response to receiving the definition of the hierarchical relationship, the definition includes an instance of the first automation object, an instance of the second automation object, and an object hierarchy defining the hierarchical relationship. The system sets one or more data record configuration parameters for an instance of the second automation object, including: Based on the hierarchical relationship and the data recording configuration parameters of the instance of the first automated object, the first automated object identifies the conditions under which data generated by the asset corresponding to the second automated object should be collected; and The first automation object configures the data record configuration parameters of the second automation object instance based on the identified conditions.

11. The method according to claim 10, wherein, The data recording configuration parameters include at least one of the following: the identity of the data item generated by the industrial asset to be collected by the data history system, the frequency at which the data item is to be collected by the data history system, the storage location where the data item is to be stored by the data history system, the organization of the data item, or the conditions for triggering the collection of the data item.

12. The method according to claim 10, wherein, Receiving the design input includes receiving the values ​​of the data record configuration parameters via interaction with a graphical representation of an instance of the first automation object.

13. The method of claim 10, further comprising: In response to receiving an instruction to encapsulate the object hierarchy, the system creates a single encapsulated object representing the object hierarchy, wherein the encapsulated object can be extended across the industrial control and monitoring project.

14. The method of claim 10, wherein, Receiving the design input includes receiving device configuration parameter values ​​for an instance of the first automation object. The equipment configuration parameter values ​​are the values ​​of the equipment configuration parameters of the industrial asset represented by the instance of the first automation object, and The method further includes: in response to receiving the device configuration parameter value, the system sets the device configuration parameter value to one or more programming attributes of the instance of the first automation object.

15. A non-transitory computer-readable medium storing instructions thereon, the instructions causing a system including a processor to perform operations in response to execution, the operations including: The integrated development environment (IDE) interface is presented on the client device by the system, which includes the processor. The system receives design input via interaction with the IDE interface, the design input defining various aspects of the industrial control and monitoring project; as well as The system generates system project data based on the design input. The system project data includes at least one instance of a first automation object selected from a library of automation objects. Each automation object represents a corresponding industrial asset and has relevant programming attributes associated with that industrial asset. in, The generation includes generating at least one of the following: an executable industrial control program, an industrial visualization application, or industrial equipment configuration data. An instance of the first automation object includes one or more data record configuration parameters as one of the programming attributes, which configure the data history system to collect data generated by the industrial assets represented by the instance of the first automation object in response to the deployment of the data history system. The receipt of design input includes receiving the definition of the hierarchical relationship between instances of the first automation object and instances of the second automation object, and The operation also includes: In response to receiving the definition of the hierarchical relationship, the definition includes an instance of the first automation object, an instance of the second automation object, and an object hierarchy defining the hierarchical relationship. The system sets one or more data record configuration parameters for an instance of the second automation object, including: Based on the hierarchical relationship and the data recording configuration parameters of the instance of the first automated object, the first automated object identifies the conditions under which data generated by the asset corresponding to the second automated object should be collected; and The first automation object configures the data record configuration parameters of the second automation object instance based on the identified conditions.

16. The non-transitory computer-readable medium according to claim 15, wherein, The data history configuration settings include at least one of the following: the identity of the data items generated by the industrial assets to be collected by the data history system, the frequency at which the data items are to be collected by the data history system, the storage location where the data items are to be stored by the data history system, the organization of the data items, or the conditions for triggering the collection of the data items.

Images