Systems and methods for simulating field devices in an industrial plant

Abstract

Systems and methods for simulating field devices in an industrial plant are provided. In a device configuration method, data of a plant network hierarchy (PNH) and registered devices (RD) in a device management server are synchronized to a device simulation server (SS). In a case where the device management system is not communicatively coupled to any entity control station configured to control an entity field device in an actual plant, at least one function of the device management system is performed in a simulation mode by communicating with a simulation device (SD). Virtual parameters are introduced into the SD. For device configuration, the SD is utilized to simulate configurable device parameters; non-configurable device parameters; and device states, wherein the SD is generated for the RD in the FDCS according to a DD file in the PNH. A parallel communication from a CRH component in the FDCS to the SD in the PNH is performed simultaneously, the parallel communication including sending a communication request from the CRH component to the SD in the PNH.

Description

Technical Field

[0001] Embodiments of the present invention generally relate to systems and methods for field devices in industrial plants. Background Art

[0002] In industrial plants, since it is difficult for engineers to perform the functions of a device management system, for example, it is difficult to perform system configuration and behavior inspection without physical devices, and some functions may not be started, engineers must perform a large amount of work to perform device configuration. For the purpose of device configuration, it is necessary to simulate device communication with a large number of different types of field devices. Existing hardware simulators on the market can be used to support limited functions and limited devices. However, hardware simulators are usually used for the simulation functions of specific devices. Summary of the Invention

[0003] In some embodiments, the device configuration method includes the following processes. Synchronize the data of the plant network hierarchy (PNH) and the data of one or more registered devices (RDs) in the database of the device management server (DMS) to the device simulation server (SS). In the case where the device management system is not communicatively coupled to any entity control station configured to control one or more entity field devices in an actual plant, perform at least one function of the device management system in simulation mode by communicating with a simulated device (SD). Virtual parameters are introduced into the simulated device (SD). For device configuration, use the simulated device (SD) to simulate: i) the value change of configurable device parameters; ii) the value change of non-configurable device parameters (such as process variables); and iii) device state simulation, where the simulated device (SD) is generated from one or more device description files (DD files). The simulated device (SD) under the simulated plant network hierarchy (simulated PNH) in the simulation server (SS) corresponds to one or more registered devices (RDs), and the field device communication server (FDCS) in the device management system typically communicates with the one or more registered devices (RDs). At the same time, perform parallel communication from the communication request handling component (CRH) in the field device communication server (FDCS) to the simulated device (SD) in the plant network hierarchy (PNH) in the simulation server (SS). The parallel communication enables multiple communication requests from the communication request handling component (CRH) to be sent to multiple simulated devices (SDs) in the plant network hierarchy (PNH) in the simulation server (SS). BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 is a block diagram showing a device management system in some embodiments.

[0005] Figure 2 is a flowchart showing the operations and processes of creating a simulated device (SD) using the synchronization of the field device database.

[0006] Figure 3It is a flowchart of a process for creating a single device for simulation using a simulation server tool (SST) in a field device communication server (FDCS).

[0007] Figure 4 It is a view showing an example of a simulation server tool displayed on a display screen.

[0008] Figure 5 It is a view of a simulated user interface where configurable and non-configurable device parameters are displayed on a display screen.

[0009] Figure 6 It is a view showing an example of simulating a device state in a simulated user interface.

[0010] Figure 7 It is a flowchart of the implementation of HART (Highway Addressable Remote Transducer) device simulation (communication method for HART commands) based on a device description file.

[0011] Figure 8 It is a flowchart of a process for implementing device simulation (communication method for device parameters) using a device description file for HART.

[0012] Figure 9 It is a flowchart of a process for FF-H1 communication simulation.

[0013] Figure 10 It is a flowchart of a process for a device management system to communicate with a simulated device (SD). Detailed implementation

[0014] In some aspects, a method and a system are used to simulate factory device communication using a simulated device (SD) during device configuration when the physical device is unavailable. A simulation mode is introduced into the device management system for device configuration, and the field device communication server (FDCS) can be configured to communicate with a physical field device or a simulated device (SD).

[0015] In some cases, a method and a system are used to simulate any type of device, such as FOUNDATION Fieldbus (FF) communication devices and HART communication devices from various manufacturers, based on information extracted from a device description file. The device configuration and / or parameter values of the simulated device (SD) are stored in a simulation database.

[0016] For FF communication devices, communication with field devices is simulated by using parameter-based transactions to read from and / or write to an analog database parameter values including device status.

[0017] For HART communication devices, communication with field devices is simulated by interpreting parameter values stored in an analog database and command structures presented by device description files. Virtual parameters are introduced to simulate communication response codes and device status. Parameter-based transactions for HART communication devices are also supported to provide integration with various application systems.

[0018] Before simulating communication with physical devices, data of the plant network hierarchy (PNH) and data of one or more registered devices (RD) in the field device database of a device management server (DMS) are synchronized to the database of a simulation server (SS).

[0019] A simulation user interface is provided to allow engineers to change and / or simulate parameter values (such as PV values) of configurable and non-configurable parameters as well as device status.

[0020] In some embodiments, a device configuration method includes the following process. Data of the plant network hierarchy (PNH) and data of one or more registered devices (RD) in a device management server (DMS) are synchronized to the database of a device simulation server (SS). In a case where the device management system is not communicatively coupled to any entity control station configured to control one or more physical field devices in an actual plant, at least one function of the device management system is performed in simulation mode by communicating with a simulation device (SD). Virtual parameters are introduced into the simulation device (SD). For device configuration, the simulation device (SD) is used to simulate: i) changes in values of configurable device parameters; ii) changes in values of non-configurable device parameters; and iii) device status simulation, wherein the simulation device (SD) is generated from one or more device description files (DD files). The simulation device (SD) in the plant network hierarchy (PNH) in the simulation server (SS) corresponds to the registered device (RD) in the device management system. Parallel communication from a communication request handling component (CRH) in a field device communication server (FDCS) to the simulation device (SD) in the plant network hierarchy (simulated PNH) in the simulation server (SS) is performed simultaneously. The parallel communication includes sending a communication request from the communication request handling component (CRH) to the simulation device (SD) in the simulated plant network hierarchy (simulated PNH) in the simulation server (SS).

[0021] In some cases, the device configuration method may further include, but is not limited to, determining whether a simulated device (SD) is instantiated in a simulation server (SS).

[0022] In some cases, the device configuration method may further include, but is not limited to, if it is determined that the simulated device (SD) is not instantiated in the simulation server (SS), then instantiating the simulated device (SD) in the simulation server (SS).

[0023] In some cases, the device configuration method may further include, but is not limited to, sending a communication request to the simulated device (SD).

[0024] In some cases, the device configuration method may further include, but is not limited to, analyzing the communication request by the simulated device (SD).

[0025] In some cases, the device configuration method may further include, but is not limited to, generating a communication response based on the analysis result and sending the communication response from the simulated device (SD) to the device management system.

[0026] In some cases, the device configuration method may further include, but is not limited to, selecting one or more segments in a simulated plant network hierarchy (simulated PNH) in the simulation server (SS).

[0027] In some cases, the device configuration method may further include, but is not limited to, selecting one or more device description files (DD files) in a device description service having one or more device information service libraries.

[0028] In some cases, non-configurable device parameters are read-only device parameters and are immutable.

[0029] In some cases, the simulated device (SD) may further include, but is not limited to, manufacturer information that identifies the manufacturer of one or more entity field devices; device type information that identifies the device type of one or more entity field devices; and a device database that stores one or more parameter attributes extracted from one or more device description files (DD files) using a device description service having one or more device information service libraries; configuration values of the simulated device (SD); and parameter values of the simulated device (SD).

[0030] In some cases, the device database also stores information on all function blocks and parameters.

[0031] In some cases, the device database also stores the parameter type, parameter size, and parameter offset for command communication of the parameters participating in the communication request or communication response.

[0032] In some cases, the simulated device (SD) may further include, but is not limited to, logic for accessing function blocks and individual parameters.

[0033] In some cases, the simulation device (SD) may also include, but is not limited to, logic for interpreting HART communication requests using a device description service having one or more device information repositories, and logic for accessing parameter values and HART communication response data.

[0034] In some cases, the device configuration method may also include, but is not limited to, creating a plant network hierarchy (PNH) in a device management client (DMC); registering the device in a database in the device management system to create a registered device (RD) in the device management system; and configuring the registered device (RD) to create one or more registered devices (RD) in the database of the device management system before synchronizing the data of the plant network hierarchy (PNH) and the data of one or more registered devices (RD) to a simulation server (SS).

[0035] In some cases, the device configuration method may also include, but is not limited to, switching a communication request from a physical device that may or may not exist in a plant to one or more simulation devices (SD) in a simulation server (SS) before simulating, for device configuration, i) configurable device parameters, ii) non-configurable device parameters; and iii) device states.

[0036] In some cases, the device configuration method may also include, but is not limited to, determining whether one or more simulation devices (SD) are found in a simulation server (SS); creating one or more simulation devices (SD) in the simulation server (SS); and using the created one or more simulation devices (SD) to configure: i) configurable device parameters; ii) non-configurable device parameters; and iii) device states.

[0037] In some cases, the device configuration method may also include, but is not limited to, accessing a simulation database (SDB) in a simulation server (SS); and generating a communication response by one or more simulation devices (SD).

[0038] In some cases, the device configuration method may also include, but is not limited to, simulating a device for at least one of the device types of HART devices, FF devices, Profibus devices, and ISA100.

[0039] The simulation of a device is performed by configuring device parameters and simulating communication with the device, but without simulating the device itself, i.e., without simulating the internal logic of the device.

[0040] The device status indicates the health of the device, but HART devices do not display the parameters of the device status. HART devices append the device status to the communication response data. Since there are no parameters defining the device status and the user cannot change the device status, virtual parameters are introduced into the simulation database to simulate the device health. Communicating with the device is simulated by reading and writing the virtual parameters of the device status.

[0041] Configurable device parameters, such as device tags and measurement units, are presented to the application system for viewing, use, and editing.

[0042] Non-configurable device parameters are presented to the application system for viewing and use only, and the application system cannot change the value of the parameters, such as temperature.

[0043] Virtual parameters are not displayed by the device. Virtual parameters are only used to simulate communication with the device to access specific device attributes, such as device status.

[0044] For an actual device, if the application system or the end user changes the unit of temperature, from degC to degF, the temperature value will change accordingly.

[0045] However, the device simulator cannot simulate the internal logic of the device, so even if the unit changes, the temperature value will not change.

[0046] Again, we simulate communication with the device by reading and writing virtual parameters for the device status rather than for the device internal logic.

[0047] Introducing virtual parameters into the simulation device (SD) is part of the process for simulating the instantiation of a HART device. The overall workflow can include, but is not limited to, synchronizing the database, enabling the simulation mode, executing the configuration function, instantiating the simulation device (SD), sending requests to the simulation device (SD), and receiving and processing responses from the simulation device (SD).

[0048] The term "configuration of parameters" applies to actual devices and is only used to change the values of configurable parameters. The term "simulation of parameters" applies to device simulators and is used to change not only the values of configurable parameters but also the values of non-configurable parameters and device status.

[0049] The device configuration method and system as described above will enable an engineer to perform field device configuration in parallel with, for example, the control system configuration of a configuration device to adjust parameter values and to check device compatibility and system behavior in the absence of available field devices. More specifically, the device configuration method and system as described above will enable an engineer to perform field device configuration in parallel with, for example, the control system configuration of a configuration device to adjust parameter values and to check device compatibility and system behavior when the device management system is not communicatively coupled to any entity control station configured to control one or more entity field devices in an actual plant.

[0050] The device configuration method and system as described above will enable an engineer to check system behavior when replacing an analog device (SD) with another analog device (SD) of a different type, where no entity device has been presented yet.

[0051] The device configuration method and system as described above will enable an engineer to simulate process variables and device states in a very convenient manner in the absence of available field devices. More specifically, the device configuration method and system as described above will enable an engineer to simulate process variables and device states in a very convenient manner when the device management system is not communicatively coupled to any entity control station configured to control one or more entity field devices in an actual plant.

[0052] The device configuration method and system as described above will enable an engineer to perform the configuration of the device management system as soon as possible even before the actual device is deployed or connected to the system. In other words, the device configuration method and system as described above will enable an engineer to perform the configuration of the device management system as soon as possible when the device management system is not communicatively coupled to any entity control station configured to control one or more entity field devices in an actual plant.

[0053] The device configuration method and system as described above will enable an engineer to simulate multiple devices of different types from different manufacturers in parallel with or simultaneously with each other.

[0054] Figure 1 is a block diagram showing a device management system in some embodiments.

[0055] The device management system 1000 may include, but is not limited to, a device management client (DMC) 110, a device management server (DMS) 120, a field device communication server (FDCS) 200, and a simulation server (SS) 300. The device management client (DMC) 110 is communicatively and operably coupled to the field device communication server (FDCS) 200. The device management server (DMS) 120 is communicatively and operably coupled to the simulation server (SS) 300.

[0056] The device management system 1000 is configured to synchronize data of a plant network hierarchy (PNH) and data of one or more registered devices (RD) in a field device database (FDDB) 121 in the device management server (DMS) 120 to the simulation server (SS) 300. In a case where the device management system 1000 is not communicatively coupled to a control station 600 as an entity control station via a control bus interface 400 and a control network interface 500, and the control station is configured to control one or more entity field devices such as an entity HART device 700 and an entity FF device 800 in an actual plant, the device management system 1000 is configured to execute at least one function of the device management system 1000 in a simulation mode by communicating with the simulation server (SS) 300.

[0057] The device management system 1000 is configured to introduce virtual parameters into a simulation device (SD).

[0058] The simulation server (SS) 300 is configured to simulate, for device configuration, using the simulation device (SD): i) a change in the value of a configurable device parameter; ii) a change in the value of a non-configurable device parameter; and iii) device state simulation, wherein the simulation device (SD) is generated from one or more device description files (DD files) in a simulation plant network hierarchy (simulation PNH) in the simulation server (SS) 300 of one or more registered devices (RD) in the device management server (DMS) 120 in the device management system 1000.

[0059] The Field Device Communication Server (FDCS) 200 and the Simulation Server (SS) 300 are configured to simultaneously perform parallel communication from a communication request handling component (CRH) 240 in the Field Device Communication Server (FDCS) 200 to a simulated device (SD) in a simulated plant network hierarchy (simulated PNH) in the Simulation Server (SS), where the parallel communication includes sending a communication request from the communication request handling component (CRH) 240 to the simulated device (SD) in the simulated plant network hierarchy (simulated PNH) in the Simulation Server (SS). In a case where the device management system 1000 is not communicatively coupled to an entity control station 600 via a control bus interface 400 and a control network interface 500, the communication request from the communication request handling component (CRH) 240 can be sent to the simulated device (SD) in the simulated plant network hierarchy (simulated PNH) in the Simulation Server (SS), and the control station is configured to control one or more entity field devices such as an entity HART device 700 and an entity FF device 800 in an actual plant.

[0060] The device management system 1000 may include, but is not limited to, a device management client (DMC) 110 and a device management server (DMS) 120. The device management client (DMC) 110 is interchangeably and operably coupled to the device management server (DMS) 120. The device management client (DMC) 110 is interchangeably and operably coupled to the Field Device Communication Server (FDCS) 200. The device management server (DMS) 120 is interchangeably and operably coupled to the Simulation Server (SS) 300. The device management client (DMC) 110 may include, but is not limited to, a simulation user interface (simulation UI) 111. The simulation user interface (simulation UI) 111 can be used to communicate with the device management server (DMS) 120 and the Field Device Communication Server (FDCS) 200. The device management server (DMS) 120 may include, but is not limited to, a field device database (FDDB) 121. The device management server (DMS) 120 is configured to allow data in the field device database (FDDB) 121 to be synchronized with the Simulation Server (SS) 300.

[0061] The Field Device Communication Server (FDCS) 200 may include, but is not limited to, an Interface Standard Service (OPC Service) 210, a HART Communication Manager (HARTCM) 220, a FF Communication Manager (FF CM) 230, a Communication Request Handling Component (CRH) 240, and a Control Bus Driver (CBD) 250. The Interface Standard Service (OPC Service) 210 is configured to act as an interface between the Device Management Client (DMC) 110 and the HART Communication Manager (HART CM) 220, and between the Device Management Client (DMC) 110 and the FF Communication Manager (FF CM) 230. The HART Communication Manager (HART CM) 220 is configured to manage HART communication between the Field Device Communication Server (FDCS) 200 and the physical HART device 700 via the control bus interface 400, the control network interface 500, and the control station 600 configured to control the physical HART device 700. The FF Communication Manager (FF CM) 230 is configured to manage FF communication between the Field Device Communication Server (FDCS) 200 and the physical FF device 800 via the control bus interface 400, the control network interface 500, and the control station 600 configured to control the physical FF device 800.

[0062] A Communication Request Handler (CRH) 240 is interchangeably and operably coupled between a HART Communication Manager (HARTCM) 220 and a Control Bus Driver (CBD) 250. The Communication Request Handler (CRH) 240 is also interchangeably and operably coupled between a FF Communication Manager (FF CM) 230 and the Control Bus Driver (CBD) 250. The Communication Request Handler (CRH) 240 is configured to determine communication requests from the HART Communication Manager (HART CM) 220 to an entity HART device 700 via a control bus interface 400, a control network interface 500, and a control station 600 configured to control the entity HART device 700. The Communication Request Handler (CRH) 240 is configured to determine communication requests from the FF Communication Manager (FFCM) 230 to an entity FF device 800 via the control bus interface 400, the control network interface 500, and the control station 600 configured to control the entity FF device 800. The Communication Request Handler (CRH) 240 is configured to determine communication requests from the HART Communication Manager (HART CM) 220 to an Analog Server (SS) 300. The Communication Request Handler (CRH) 240 is configured to determine communication requests from the FF Communication Manager (FF CM) 230 to the Analog Server (SS) 300. The Control Bus Driver (CBD) 250 is used when the HART Communication Manager (HART CM) 220 communicates with the entity HART device 700. The Control Bus Driver (CBD) 250 is used when the FF Communication Manager (FF CM) 230 communicates with the entity FF device 800.

[0063] The Analog Server (SS) 300 may include, but is not limited to, a Device Database Synchronization Tool (DDBSNC) 310, a Simulation Server Tool (SST) 320, a Simulation Database (SDB) 330, a HART Device Description Service (HART DD) 340, a FF Device Description Service (FF DD) 350, a simulated HART device 360, and a simulated FF device 370.

[0064] A Device Management Client (DMC) 110 is configured to provide various functions to a device engineer to create a Plant Network Hierarchy (PNH), register Registered Devices (RDs), and configure the Registered Devices (RDs).

[0065] The Field Device Database (FDDB) 121 stores data of the Plant Network Hierarchy (PNH) and data of one or more Registered Devices (RD).

[0066] The Field Device Communication Server (FDCS) 200 is configured to manage communication channels with the Entity HART Device 700 and with the Entity FF Device 800 via the Control Bus Interface 400, the Control Network Interface 500, and the Control Station 600 configured to control the Entity FF Device 800 and the Entity HART Device 700. The Field Device Communication Server (FDCS) 200 is configured to send requests from the Device Management Client (DMC) 110 to the Entity HART Device 700 and the Entity FF Device 800 via the Control Bus Interface 400, the Control Network Interface 500, and the Control Station 600. The Field Device Communication Server (FDCS) 200 is configured to receive responses to the requests from the Entity HART Device 700 and from the Entity FF Device 800 via the Control Bus Interface 400, the Control Network Interface 500, and the Control Station 600. The Field Device Communication Server (FDCS) 200 is configured to send back the corresponding functions among the various functions of the Device Management Client (DMC) 110 to the Entity HART Device 700 and the Entity FF Device 800 via the Control Bus Interface 400, the Control Network Interface 500, and the Control Station 600.

[0067] The Device Management System 1000 can be configured to be in simulation mode. The Device Management Client (DMC) 110 is configured to: when the Device Management System 1000 is placed in simulation mode, send communication requests to the Simulation Devices (SD), e.g., the Simulated HART Device 360 and the Simulated FF Device 370, instead of the Entity HART Device 700 and the Entity FF Device 800.

[0068] The Simulation Server (SS) 300 includes a Simulation Database (SDB) 330, which stores the corresponding configurations and parameter values of the Simulation Devices (SD).

[0069] The Simulation Server (SS) 300 includes a HART Device Description Service (HART DD) 340, which can be implemented through the device information service library provided by the HART Foundation.

[0070] The Simulation Server (SS) 300 includes a FF Device Description Service (FF DD) 350, which can be implemented through the device information service library provided by the Fieldbus Foundation Group.

[0071] A Device Database Synchronization Tool (DDBSNC) 310 is communicatively and operably coupled to a Device Management Server (DMS) 120 that includes a Field Device Database (FDDB) 121 storing Registered Devices (RD). The Device Database Synchronization Tool (DDBSNC) 310 is configured to enable an engineer to create a Simulated Plant Network Hierarchy (Simulated PNH) and Simulated Devices (SD). The Device Database Synchronization Tool (DDBSNC) 310 is configured to enable an engineer to extract information on the Plant Network Hierarchy (PNH) and device parameter values from the Field Device Database (FDDB) 121 to create a Simulated Plant Network Hierarchy (Simulated PNH) and Simulated Devices (SD). That is, the Device Database Synchronization Tool (DDBSNC) 310 is configured to synchronize data on the Plant Network Hierarchy (PNH) and data on one or more Registered Devices (RD) in the Field Device Database (FDDB) 121 in the Device Management Server (DMS) 120 to a Simulation Server (SS) 300. Once the Field Device Database (FDDB) 121 is synchronized to the Simulation Server (SS) 300, the engineer can choose to switch communication requests sent by a Device Management Client (DMC) 110 in the Device Management System 100 to the Simulated Devices (SD).

[0072] The Simulation Server (SS) 300 includes a Simulation Server Tool (SST) 320. The Simulation Server Tool (SST) 320 is configured to manage a simulated environment, such as simulation projects, device turnaround time settings for each device, and provide alternatives for engineers to manage the Simulated Plant Network Hierarchy (Simulated PNH), such as adding, deleting, and / or modifying the Simulated Plant Network Hierarchy (Simulated PNH), IO modules, and Simulated Devices (SD) in addition to device management.

[0073] The Simulation Server (SS) 300 is configured to instantiate a Simulated Control Station and Simulated Devices (SD). The Simulation Server (SS) 300 is configured to forward communication requests from a Field Device Communication Server (FDCS) 200 to the Simulated Devices (SD) and return responses to the Field Device Communication Server (FDCS) 200

[0074] The Field Device Communication Server (FDCS) 200 includes a Communication Request Handling component (CRH) 240. The Communication Request Handling component (CRH) 240 is configured to determine whether a communication request from a Device Management Client (DMC) 110 in the Device Management System 1000 is to be sent to the physical HART device 700 and the physical FF device 800, or to the simulated HART device 360 and the simulated FF device 370.

[0075] The Communication Request Handling component (CRH) 240 can be configured to have a simulation switchtable. The simulation switchtable is used to determine whether the communication is to be sent to simulated devices (SDs) in the factory or to physical devices, such as the physical HART device 700 and the physical FF device 800. By enabling and disabling the simulation mode at the selective levels from the control system type level to the device level in the Plant Network Hierarchy (PNH), simultaneous communication from the Device Management Client (DMC) 110 to both simulated devices (SDs) in the factory and to physical devices (such as the physical HART device 700 and the physical FF device 800) can be achieved.

[0076] Table 1 shows an example of the simulation switchtable.

[0077] Table 1

[0078]

[0079]

[0080] If not specified by the user, each level of the factory hierarchy inherits the simulation mode of its predecessor and overrides the inherited mode when necessary. When the simulation mode of the previous level is enabled, subsequent plant hierarchy nodes inherit the simulation mode of the previous level. As shown in Table 1, when the control system type, Item 1, Control Station 0101 enables the simulation mode, if the user does not specify IOM1, Node 01, Slot 01, they inherit the simulation mode. At the device level of the plant hierarchy, communication with simulated devices (SDs) is enabled only when all of its previous levels are enabled in simulation mode and the device itself is also enabled in simulation mode. For example, when the plant hierarchy node Channel 02 disables the simulation mode, even if Devices M and N are enabled in simulation mode, the communication with Devices M and N under Channel 02 will be sent only to the physical Devices M and N.

[0081] When a parallel communication request is sent from a Device Management Client (DMC) 110 to a Communication Request Handler (CRH) 240, the Communication Request Handler (CRH) 240 will send communication requests to physical devices and / or Simulated Devices (SD) based on an analog switching table. When some devices are in physical device mode and some devices are in analog mode, the Communication Request Handler (CRH) 240 sends communication requests to physical devices and Simulated Devices (SD) simultaneously.

[0082] The device management system 1000 includes a Device Management Client (DMC) 110. The Device Management Client (DMC) 110 is an enhanced user interface configured to allow an engineer to simulate values of configurable and non-configurable parameters of a device and the device status.

[0083] Unlike physical field devices (e.g., physical HART device 700 and physical FF device 800), a Simulated Device (SD) (e.g., simulated HART device 360 and simulated FF device 370) does not have any physical hardware resources. A Simulated Device (SD) (e.g., simulated HART device 360 and simulated FF device 370) consists of multiple pieces of device information such as manufacturer-related information, device type, and device revision.

[0084] The Simulation Server (SS) 300 includes a Simulation Database (SDB) 330. The Simulation Database (SDB) 330 stores parameter attribute information extracted from device description files, e.g., parameter type, default value, etc. The Simulation Database (SDB) 330 stores configurations and parameter values of the Simulated Device SD. The Simulation Database (SDB) 330 stores information on all command transaction structures for the simulated HART device 360: parameter type, parameter size, parameter offset of the command transaction of the parameters participating in a communication request or communication response. The Simulation Database (SDB) 330 stores information on all function blocks and parameters for the simulated FF device 370, e.g., index, sub-index, views in the function block. The Simulation Database (SDB) 330 stores the logic for interpreting HART communication requests, accessing parameter values, and generating HART communication response data for the simulated HART device 360. The Simulation Database (SDB) 330 stores the logic for accessing function blocks and individual parameters for the simulated FF device 370: e.g., FF network management functions such as obtaining a list of field devices, reading object descriptions; reading a list of function blocks; and accessing parameter values using an index and a sub-index.

[0085] Execute device configuration:

[0086] Device configuration can be implemented in two ways using a simulation device (SD): 1) Create simulation devices (SDs) such as simulated HART devices 360 and simulated FF devices 370 by using the synchronization of the field device database (FDDB) 121 in the device management server (DMS) 120 in the device management system 1000; and 2) Create individual devices for simulation by using the simulation server tool (SST) 320 in the field device communication server (FDCS) 200.

[0087] Create simulation devices (SDs) by using the synchronization of the field device database (FDDB):

[0088] Generally, devices such as HART devices and / or FF devices are registered in the device management client (DMC) 110 in the device management system 1000 through manual registration or import from other projects. The registered devices (RDs) (e.g., registered HART devices and registered FF devices) in the device management client (DMC) 110 can be synchronized with the simulation server (SS) 300, so that the registered devices (RDs) can be simulated in the simulation server (SS) 300.

[0089] Figure 2 It is a flowchart showing the operations and processes of creating simulation devices (SDs) by using the synchronization of the field device database.

[0090] In step S101, create a plant network hierarchy (PNH) in the device management client (DMC) 110 in the device management system 1000.

[0091] In step S102, register devices such as HART devices and / or FF devices in the device management client (DMC) 110 in the device management system 1000 through manual registration or import from other projects.

[0092] In step S103, synchronize the data of the plant network hierarchy (PNH) and the data of one or more registered devices (RDs) in the field device database (FDDB) 121 in the device management server (DMS) 120 to the simulation server (SS) 300 through the device database synchronization tool (DDBSNC) 310.

[0093] In step S104, the communication request sent from the Device Management Client (DMC) 110 is switched from the Control Bus Driver (250) in the Field Device Communication Server (FDCS) 200 to the Simulation Server (SS) 300. The communication request originates from the Device Management Client (DMC) 110. When the simulation mode is enabled, the Communication Request Handler (CRH) 240 switches the communication request from the Control Bus Driver (CBD) 250 to the Simulation Server (SS) 300.

[0094] In step S105, as the communication request is sent to the Simulation Server (SS) 300, the Simulation Device (SD) is utilized to simulate i) changes in the values of configurable device parameters; ii) changes in the values of non-configurable device parameters; and iii) device status simulation, via the use of a Simulation User Interface (Simulation UI) 111, where the Simulation Device (SD) is generated from one or more Device Description Files (DD Files) in the Plant Network Hierarchy (PNH) in the Simulation Server (SS) 300 for one or more Registered Devices (RDs) in the Field Device Communication Server (FDCS) 200 in the Device Management System 1000.

[0095] In step S106, the Simulation Server (SS) 300 locates the Simulation Device (SD).

[0096] In step S107, it is determined whether the Simulation Device (SD) is found in the Simulation Server (SS) 300.

[0097] In step S108, if it is determined in step S107 that the Simulation Device (SD) is not found in the Simulation Server (SS) 300, the Simulation Server (SS) 300 creates the Simulation Device (SD) with the following parameters, including: i) configurable and non-configurable device parameters read from the device description file; and ii) virtual parameters introducing HART device status.

[0098] In step S109, after the configuration in step S108, the Simulation Server (SS) 300 forwards the communication request to the Simulation Device (SD), such as the Simulated HART Device 360 and the Simulated FF Device 370. If it is determined in step S107 that the Simulation Device (SD) is found in the Simulation Server (SS) 300, the Simulation Server (SS) 300 forwards the communication request to the Simulation Device (SD), such as the Simulated HART Device 360 and the Simulated FF Device 370.

[0099] In step S110, when a communication request is received by a simulation device (SD) such as the simulated HART device 360 and the simulated FF device 370, the simulation device (SD) interprets the communication request and accesses the simulation database (SDB) 330. Then, the simulation device (SD) generates a communication response and returns the communication response to the simulation server (SS) 300.

[0100] In step S111, the simulation server (SS) 300 sends the communication response that has been returned from a simulation device (SD) such as the simulated HART device 360 and the simulated FF device 370 to the simulated user interface (simulated UI) 111 of the device management client (DMC) 110 within the device management system 1000.

[0101] Create a single device for simulation using the simulation server tool (SST) 320 in the simulation server (SS) 300:

[0102] Figure 3 Is a flowchart of a process for creating a single device for simulation using the simulation server tool (SST) 320 in the simulation server (SS) 300. Figure 4 Is a view showing an example of the simulation server tool (SST) 320 displayed on a display screen.

[0103] In addition to synchronizing the field device database (FDDB) 121 in the device management server (DMS) 120, an engineer can also use the simulation server tool (SST) 320 to add a single device to the simulated plant network hierarchy (simulated PNH).

[0104] Reference Figure 3 , will describe the process of creating a single device for simulation using the simulation server tool (SST) 320 in the simulation server (SS) 300.

[0105] In step S201, start the simulation server tool (SST) 320.

[0106] In step S202, the simulation server tool (SST) 320 selects one or more segments in the simulated plant network hierarchy (simulated PNH) in the simulation database (SDB) 330 in the simulation server (SS) 300.

[0107] In step S203, the Simulation Server Tool (SST) 320 selects a device description file (DD file) using the HART Device Description Service (HART DD) 340 and using the FF Device Description Service (FF DD) 350. The Simulation Server Tool (SST) 320 selects the device type from the device description file (DD file). The Simulation Server Tool (SST) 320 extracts parameter information from the selected device description file (DD file). The Simulation Server Tool (SST) 320 creates a simulation database (SDB) 330.

[0108] In step S204, the Communication Request Handling Component (CRH) 240 switches the communication request from the Control Bus Driver (CBD) 250 to the Simulation Server (SS) 300. The communication request originates from the Device Management Client (DMC) 110. When the simulation mode is enabled, the Communication Request Handling Component (CRH) 240 will switch the communication request from the Control Bus Driver (CBD) 250 to the Simulation Server (SS) 300.

[0109] In step S205, the simulation user interface (simulation UI) 111 is started to automatically start the Simulation Server (SS) 300 and create a simulation device (SD) through the simulation database 330.

[0110] In step S206, through the Device Simulation Server (SS) 300, for device configuration, the engineer uses the simulation user interface (simulation UI) 111 to simulate: i) the value change of configurable device parameters; ii) the value change of non-configurable device parameters; and iii) device status simulation.

[0111] In step S207, the functions of the Device Management Client (DMC) 110 in the device management system 1000 are executed. A communication request is sent to the simulation device (SD) in the Simulation Server (SS) 300, for example, the simulation HART device 360 and the simulation FF device 370. The simulation device (SD) generates a communication response and returns the communication response to the Simulation Server (SS) 300. The Simulation Server (SS) 300 sends the communication response that has been returned from the simulation devices (SD) such as the simulation HART device 360 and the simulation FF device 370 to the simulation user interface (simulation UI) 111 of the Device Management Client (DMC) 110 in the device management system 1000.

[0112] Simulate configurable / non-configurable device parameters:

[0113] As described above, simulate i) the value change of configurable device parameters; and ii) the value change of non-configurable device parameters.

[0114] Figure 5It is a view of configurable device parameters and non-configurable device parameters displayed on the display screen.

[0115] Non-configurable device parameters may include, but are not limited to, the primary variable value of the field device. Non-configurable device parameters are read-only device parameters and cannot be changed because non-configurable device parameters reflect the measured values of actual physical quantities detected by the sensor hardware. In the case where the field device is a temperature sensor, the non-configurable device parameter includes the primary variable value of the temperature sensor device. Non-configurable device parameters are read-only device parameters and cannot be changed because non-configurable device parameters reflect the actual temperature measurement values detected by the temperature sensor hardware.

[0116] Device simulation provides a way to change the value similar to changing configurable parameters, so that any temperature value can be freely simulated, such as 0 degrees Celsius, 33 degrees Celsius.

[0117] Configure the simulation user interface (simulation UI) 111 so that engineers can apply different user inputs to various data types. For example, text boxes are used for string or floating values, drop-down lists are used for enumerated values, and dedicated dialog boxes are used for bit enumerations, etc. Simulating any desired value for read-only parameters is achieved by changing the values in the simulator database.

[0118] Simulate device status:

[0119] The HART device status reflects the actual condition or operating state of the device. Device simulation will provide a way to change the device value so that any device condition can be simulated, such as normal, in need of maintenance, device failure.

[0120] Figure 6 It is a view of an example of simulating device status in the simulation user interface.

[0121] The simulation user interface (simulation UI) 111 can be used for simulating device status. Similarly, for other non-configurable parameters, the parameter values can be modified and / or simulated in the simulation user interface (simulation UI) 111, and the device status can also be simulated. The simulation user interface (simulation UI) 111 will interpret and display each data bit of the device status and allow the engineer to change the value of each bit of the device status, and then save it to the simulation database (SDB) 330 for simulation.

[0122] Simulate HART communication with the device description file:

[0123] The simulation function for simulating HART devices will support HART's "device parameter-oriented communication method" (OSI layer 8) and "HART commands" (OSI layer 7) to support a wider range of advanced applications.

[0124] The communication between the application system (layer 7) and the HART device can include, but is not limited to, requests and responses encoded with HART commands, which are basically binary data streams.

[0125] Generally, the HART communication requests sent from the application system are processed by the HART device, and the HART device will respond by sending back the corresponding HART communication response.

[0126] In the case of device simulation, the HART communication requests are processed by the device simulation function. The device simulation function has the logic to interpret the HART communication requests and return the corresponding HART communication responses. When the simulated device (SD) 360 is created, all the parameter information of the command transaction structure is extracted from the device description file using the HART device description service (HART DD) 340 and saved by the simulated device (SD). The parameter information includes the parameter type, parameter size, and the parameter offset of the command transaction of the parameters participating in the communication request or communication response. When a communication request is received at the simulated device (SD), the simulated device (SD) will process the request through the following steps:

[0127] 1) Search for the request parameters of the command based on the parameter offset and parameter size in the communication request;

[0128] 2) Reduce the bytes of the parameter values in the request, decode the parameter values according to the parameter type, and write the parameter values into the simulation database 330;

[0129] 3) Read the parameter values of the response parameters from the simulation database 330; and

[0130] 4) Encode the parameter values according to the parameter type and generate the communication response bytes based on the parameter offset and parameter size in the communication response.

[0131] As long as the device description (DD) information is available, by using the device description (DD) information in the device simulation function, the simulation function for simulating HART devices will support general commands, idiomatic commands, and device-specific commands for any manufacturer and any model.

[0132] Some HART field devices do not support all common commands and idiomatic commands (HART commands). Device simulation will provide default implementations for these commands (common commands and idiomatic commands) according to the HART specifications provided by the HART Foundation when necessary, even for those HART devices that do not support common commands and idiomatic commands.

[0133] Figure 7 is a flowchart of the implementation of HART device simulation based on device description files.

[0134] In step S301, a device description (DD) file is loaded into the library of the HART device description service (HART DD) 340.

[0135] In step S302, all parameter information is extracted from the device description (DD) file by using the HART device description service (HART DD) 340. The parameter information can include, but is not limited to, parameter size, parameter type, offset and response in the communication request, and they are saved in any memory of the simulated device (SD).

[0136] In step S303, the communication request is received by the simulated HART device 360.

[0137] In step S304, once the simulated HART device 360 receives the communication request, the simulated HART device 360 analyzes the communication request.

[0138] In step S305, the parameter information for writing is determined, where the parameter information is extracted from the simulated device (SD) memory.

[0139] In step S306, the parameter values are written into the simulated database (SDB) 330, where based on the parameter size and the offset in the communication request, the bytes of the parameter values for the requested parameters are reduced, and the parameter values are decoded according to the parameter type.

[0140] In step S307, the parameter information for response is determined, where the response parameters are extracted from the memory of the simulated device (SD).

[0141] In step S308, the parameter values are read from the simulated database (SDB) 330.

[0142] In step S309, a communication response is generated, where the parameter values are encoded into bytes according to the parameter type and parameter size, and the bytes are appended to the communication response based on the parameter offset in the response.

[0143] In step S310, the communication response is returned to the simulated user interface (simulated UI) 111.

[0144] Simulating HART communication using a device description file (parameter based transactions):

[0145] The term "parameter based transactions" refers to performing device reads or writes by specifying parameter names, such as reading "tag_name" or writing "message", which otherwise would have to be done using some low-level protocol specific commands such as HART commands or addressing mechanisms.

[0146] Figure 8 is a flowchart of a process for implementing device simulation (parameter based transactions) using a device description file for HART.

[0147] In step S401, a device description (DD) file is loaded.

[0148] In step S402, all parameter information is extracted from the device description (DD) file using the HART device description service (HART DD) 340. The parameter information can include but is not limited to parameter size, parameter type, and response, which are stored in any memory of the simulated device (SD).

[0149] In step S403, a communication request is received by the simulated HART device 360.

[0150] In step S404, once the simulated HART device 360 receives the communication request, the simulated HART device 360 analyzes the communication request.

[0151] In step S405, the simulated HART device 360 checks the type of the communication request to determine whether the communication request is a "write" or a "read" based on the analysis of the communication request by the simulated HART device 360.

[0152] In step S406, if it is determined that the type of the communication request is "write", the parameter value is written to the simulated database (SDB) 330, where the parameter value is converted or changed according to the parameter type, and the parameter value is written directly to the simulated database (SDB) 330 without directly decoding the bytes.

[0153] In step S407, if it is determined that the type of the communication request is "read", the parameter value is read from the simulated database (SDB) 330, where the parameter value is read from the simulated database (SDB) 330 and then the parameter value is converted or changed according to the parameter type.

[0154] In step S408, the parameter value is directly returned to the simulated user interface (simulated UI) 111 in the device management client (DMC) 110 without decoding the parameter value into bytes.

[0155] Simulate FF-H1 communication using the communication method oriented to device parameters:

[0156] The FF-H1 communication simulation aims at the functions of the FF-H1 application layer and the user application. The FF-H1 services are to simulate device address assignment, tag service lookup, obtaining OD (object description), obtaining NMOD (network management object description), directory information, obtaining OD (object description) directory information, identifying devices and / or obtaining a live list, reading block lists and block parameters, and writing block parameters.

[0157] Figure 9 is a flowchart of the process of FF-H1 communication simulation.

[0158] In step S501, load the device description (DD) file.

[0159] In step S502, extract device information from the device description file of the FF device description service (FF DD) 350, and create support structures for the OD (object description) list, the device list, the OD (object description) directory information, the NMOD directory information, the block list, and the block parameter list.

[0160] In step S503, receive a communication request.

[0161] In step S504, analyze the type of the communication request.

[0162] In step S505, determine whether to obtain an OD (object description).

[0163] In step S506, if it is determined that an OD (object description) needs to be obtained, obtain the OD (object description) from the OD (object description) list.

[0164] In step S507, if it is determined that no OD (object description) needs to be obtained, determine whether to obtain a tag.

[0165] In step S508, if it is determined that a tag needs to be obtained, obtain the tag from the device list.

[0166] In step S509, if it is determined that no tag needs to be obtained, determine whether to identify or obtain a live list.

[0167] In step S510, if it is determined that the activity list needs to be identified or obtained, device information is obtained from the device list.

[0168] In step S511, if it is determined that the activity list does not need to be identified or obtained, it is determined whether to read the FMS (Fieldbus Message Specification) / read block list.

[0169] In step S512, if it is determined that the FMS (Fieldbus Message Specification) / read block list needs to be read, block information is obtained from the block list.

[0170] In step S513, if it is determined that the FMS (Fieldbus Message Specification) / read block parameters do not need to be read, it is determined whether to read the FMS (Fieldbus Message Specification) / read block parameters.

[0171] In step S514, if it is determined that the FMS (Fieldbus Message Specification) / read block parameters need to be read, the FMS (Fieldbus Message Specification) / block parameters are read from the block parameter list.

[0172] In step S515, if it is determined that the FMS (Fieldbus Message Specification) / read block parameters do not need to be read, it is determined whether to write the FMS (Fieldbus Message Specification) / write block parameters.

[0173] In step S516, if it is determined that the FMS (Fieldbus Message Specification) / write block parameters need to be written, the FMS (Fieldbus Message Specification) / block parameters are written to the block parameter list.

[0174] In step S517, if it is determined that the FMS (Fieldbus Message Specification) / block parameters do not need to be written to the block parameter list, the response data is returned to the simulated user interface (simulated UI) 111 of the device management client (DMC) 110.

[0175] Although the description has been made in the case of HART and FF communication protocols, the simulation method described here can also be applied to ISA100 and Profibus (Process field bus).

[0176] Communication between the device management system and the simulated device (SD):

[0177] Figure 10 is a flowchart of the process of communication between the device management system 1000 and the simulated device (SD).

[0178] In step S601, the field device database (FDDB) 121 of the device management server (DMS) 120 of the device management system 1000 is synchronized to the simulation server (SS) 300.

[0179] In step S602, the simulation mode is enabled in the device management system 1000.

[0180] In step S603, the functions of the device management system 1000 are executed.

[0181] In step S604, a communication request is sent from the device management client (DMC) 110 to the simulation server (SS) 300 through the functions of the device management system 1000.

[0182] In step S605, it is determined whether the simulation server (SS) 300 has instantiated the simulation device (SD).

[0183] In step S606, if it is determined that the simulation device (SD) has not been instantiated by the simulation server (SS) 300, the simulation server (SS) 300 instantiates the simulation device (SD).

[0184] In step S607, if it is determined that the simulation device (SD) has been instantiated by the simulation server (SS) 300, the communication request is sent by the simulation server (SS) 300 to the simulation device (SD).

[0185] In step S608, the communication request is analyzed by the simulation device (SD), and response data is generated by the simulation device (SD) as the analysis result, and the response data is sent back by the simulation device (SD) to the simulation server (SS) 300.

[0186] In step S609, the response is sent by the simulation server (SS) 300 to the device management client (DMC) 110.

[0187] In step S610, the response from the simulation device (SD) is received and processed through the functions of the device management system 1000.

[0188] The systems and methods in the above embodiments can be deployed, in part or in whole, by a machine or circuit that executes computer software, software components, program code, and / or instructions on one or more processors. The one or more processors can be part of a general-purpose computer, server, cloud server, client, network infrastructure, mobile computing platform, fixed computing platform, or other computing platform. The one or more processors can be any type of computing device or processing device capable of executing program instructions, code, binary instructions, etc. The one or more processors can be or can include a signal processor, digital processor, embedded processor, microprocessor, or any variant such as a coprocessor, e.g., a math coprocessor, graphics coprocessor, communication coprocessor, etc., that can directly or indirectly facilitate the execution of program code or program instructions stored thereon. Additionally, the one or more processors can enable the execution of multiple programs, threads, and code. Threads can execute simultaneously to enhance the performance of the one or more processors and facilitate the concurrent operation of applications. The program code, program instructions, etc., described herein can be implemented in one or more threads. The one or more processors can include a memory that stores code, instructions, and programs as described herein. The processor can access a non-transitory processor-readable storage medium through an interface, and the non-transitory processor-readable storage medium can store the code, instructions, and programs described herein and elsewhere. The non-transitory processor-readable storage medium associated with a processor for storing programs, code, program instructions, or other types of instructions executable by a computing or processing device can include, but is not limited to, one or more of: memory, hard disk, flash drive, RAM, ROM, CD-ROM, DVD, cache, etc.

[0189] A processor can include one or more cores, which can increase the speed and performance of the multi-processor. In some embodiments, the processing can be a dual-core processor, quad-core processor, other chip-level multi-processor, etc., that combines two or more independent cores.

[0190] The methods and systems described herein can be deployed, in part or in whole, by a machine that executes computer software on a server, client, firewall, gateway, hub, router, or other such computer and / or network hardware.

[0191] A software program can be associated with one or more clients, which can include file clients, print clients, domain clients, Internet clients, intranet clients, and other variants such as auxiliary clients, host clients, distributed clients, etc. The client can include one or more of a memory, a processor, a computer-readable medium, a storage medium, physical and virtual ports, a communication device, and an interface, which can access other clients, servers, machines, and devices via a wired or wireless medium, etc. The program or code described herein can be executed by the client. In addition, other devices required to execute the methods described in this application can be considered as part of the infrastructure associated with the client. The client can provide an interface to other devices, which include servers, other clients, printers, database servers, print servers, file servers, communication servers, distributed servers, etc. Such coupling and / or connection can facilitate the remote execution of the program via a network. The networking of some or all of these devices can facilitate the parallel processing of the program or method at one or more locations. In addition, any device connected to the client via an interface can include at least one storage medium capable of storing methods, programs, applications, code, and / or instructions. A central repository can provide program instructions to be executed on different devices. In this embodiment, a remote repository can be used as a storage medium for program code, instructions, and programs.

[0192] A software program can be associated with one or more servers, which can include file servers, print servers, domain servers, Internet servers, intranet servers, and other variants such as auxiliary servers, host servers, distributed servers, etc. The server can include one or more of a memory, a processor, a computer-readable medium, a storage medium, physical and virtual ports, a communication device, and an interface, which can access other servers, clients, machines, and devices via a wired or wireless medium, etc. The method, program, or code described herein can be executed by the server. In addition, other devices required to execute the methods described in this application can be considered as part of the infrastructure associated with the server. The server can provide an interface to other devices, which include clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers, social networks, etc. Such coupling and / or connection can facilitate the remote execution of the program via a network. The networking of some or all of these devices can facilitate the parallel processing of the program or method at one or more locations. Any device connected to the server via an interface can include at least one storage medium capable of storing programs, code, and / or instructions. A central repository can provide program instructions to be executed on different devices. In this embodiment, a remote repository can be used as a storage medium for program code, instructions, and programs.

[0193] The methods and systems described herein can be deployed, in part or in whole, via a network infrastructure. The network infrastructure can include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices, and other active and passive devices, modules, and / or components known in the art. In addition to other components, the computing and / or non-computing devices associated with the network infrastructure can also include storage media such as flash memory, buffers, stacks, RAM, ROM, etc. The processes, methods, program code, and instructions described herein and elsewhere can be executed by one or more network infrastructure elements.

[0194] The methods, program code, and instructions described herein and elsewhere can be implemented on or via a mobile device. The mobile device can include a navigation device, a cellular phone, a mobile phone, a mobile personal digital assistant, a laptop, a palm top, a netbook, a pager, an e-book reader, a music player, etc. In addition to other components, these devices can include storage media such as flash memory, buffers, RAM, ROM, and one or more computing devices. The computing devices associated with the mobile device can be enabled to execute the program code, methods, and instructions stored thereon. Alternatively, the mobile device can be configured to cooperate with other devices to execute the instructions. The mobile device can communicate with a base station, which interfaces with a server and is configured to execute program code. The mobile device can communicate on a peer-to-peer network, a mesh network, or other communication networks. The program code can be stored on a storage media associated with the server and executed by a computing device embedded within the server. The base station can include a computing device and a storage media. The storage device can store the program code and instructions executed by the computing device associated with the base station.

[0195] Computer software, program code, and / or instructions can be stored on and / or accessed from a machine-readable medium, which can include: computer components, devices, and recording media that hold digital data for computing for a period of time; semiconductor memories, known as random access memories (RAM); mass storage, which is typically used for more permanent storage, such as optical discs, various forms of disk storage, such as hard disks, magnetic tapes, magnetic drums, cards, and other types; processor registers, caches, volatile memories, non-volatile memories; optical storage, such as CDs, DVDs; removable media such as flash memory, such as USB sticks or USB drives, floppy disks, magnetic tapes, paper tapes, punched cards, independent RAM disks, Zip drives, removable mass storage, offline storage, etc.; other computer memories, such as dynamic memories, static memories, read / write memories, variable memories, read-only memories, random access memories, sequential access memories, location-addressable memories, file-addressable memories, content-addressable memories, network-attached storage, storage area networks, barcodes, magnetic ink, etc.

[0196] The methods, devices, apparatuses, and systems described herein can transform physical items and / or intangible items from one state to another. The methods and systems described herein can also transform data representing physical items and / or intangible items from one state to another.

[0197] The modules, engines, components, and elements described herein (including the flowcharts and block diagrams in the figures) imply logical boundaries between the modules, engines, components, and elements. However, in accordance with software or hardware configuration practices, the modules, engines, components, and elements and their functions can be implemented on one or more processors, computers, machines via a computer-executable medium, the one or more processors, computers, machines being capable of executing program instructions stored thereon, as an overall software structure, as separate software modules, or as modules using external routines, code, services, or any combination of these components, and all such implementations are within the scope of the present disclosure. Examples of such machines may include (but are not limited to): personal digital assistants, laptop computers, personal computers, mobile phones, other handheld computing devices, medical devices, wired or wireless communication devices, sensors, chips, calculators, satellites, tablet PCs, e-books, gadgets, electronic devices, devices with artificial intelligence, computing devices, network devices, servers, routers, glasses with embedded processors, etc. Additionally, the modules, engines, components, and elements or any other logical components in the flowcharts and block diagrams can be implemented on one or more machines, computers, or processors capable of executing program instructions. Given the above description and the accompanying drawings that refer to these descriptions, some functional aspects of the disclosed system are set forth. Unless explicitly stated from the context or otherwise clearly indicated, the specific arrangement of the software for implementing these functional aspects should not be inferred from these descriptions. It should also be understood that the various steps identified and described above can be changed, and the order of the steps can be adapted to the specific application of the technology disclosed herein. All such changes and modifications fall within the scope of the present invention. Unless required by a specific application, or explicitly stated from the context or otherwise clearly indicated, the description of the order of the various steps should not be construed as requiring a specific order of execution of these steps.

[0198] The above methods and / or processes and their steps can be implemented in accordance with hardware, software, or any combination of hardware and software applicable to a specific application. The hardware can include general-purpose computers and / or dedicated computing devices or specific aspects or components of specific computing devices. These processes can be implemented in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, or other programmable devices, as well as in internal and / or external memories. Alternatively, or in addition, these processes can also be embodied in application-specific integrated circuits, programmable gate arrays, programmable array logic, or any other device or combination of devices that can be configured to process electronic signals. It should also be understood that one or more processes can be implemented as computer-executable code capable of being executed on a machine-readable medium.

[0199] Computer-executable code can be created using an object-oriented programming language, which can be stored, compiled, or interpreted to run on various combinations of the above devices and processors, processor architectures, or combinations of different hardware and software, or any other machine capable of executing program instructions.

[0200] Accordingly, in one aspect, each of the methods described above and combinations thereof can be embodied in computer-executable code that, when executed on one or more computing devices, performs each of its steps. In another aspect, the methods can be embodied in a system that performs its steps and can be distributed in various ways across devices, or all functions can be integrated into a dedicated, stand-alone device or other hardware. In another aspect, the devices for performing the steps associated with the above processing can include any of the above hardware and / or software. All such arrangements and combinations are intended to fall within the scope of the present disclosure.

[0201] Although certain embodiments of the present invention have been described, these embodiments have been presented by way of example only and are not intended to limit the scope of the invention. In fact, the novel embodiments described herein can be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the embodiments described herein can be made without departing from the spirit of the invention. The appended claims and their equivalents are intended to cover forms or modifications that fall within the scope and spirit of the invention.

Claims

1. A device configuration method, comprising: Synchronize data of the factory network hierarchy and data of one or more registered devices in the database of the device management system to the simulation server; and In the case where the device management system is not communicatively coupled to any entity control station configured to control one or more entity field devices for an actual factory, perform at least one function of the device management system in simulation mode by communicating with one or more simulation devices; Introduce virtual parameters into the one or more simulation devices; For device configuration, use the one or more simulation devices to simulate: i) configurable device parameters; ii) non-configurable device parameters; and iii) device status, wherein the one or more simulation devices are generated from one or more device description files in the factory network hierarchy in the simulation server for the one or more registered devices in the field device communication server in the device management system; and Simultaneously perform parallel communication from a communication request processing component in the field device communication server to the one or more simulation devices in the factory network hierarchy in the simulation server, wherein the parallel communication includes sending communication requests from the communication request processing component to the one or more simulation devices in the factory network hierarchy in the simulation server.

2. The device configuration method according to claim 1, further comprising: Determine whether the simulation device is instantiated in the simulation server.

3. The device configuration method according to claim 2, further comprising: If it is determined that the simulation device is not instantiated in the simulation server, instantiate the simulation device in the simulation server.

4. The device configuration method according to claim 1, further comprising: Send a communication request to the simulation device.

5. The device configuration method according to claim 1, further comprising: Analyze the communication request by the simulation device.

6. The device configuration method according to claim 5, further comprising: Send a communication response from the simulation device to the device management system based on the analysis result.

7. The device configuration method according to claim 1, further comprising: Select one or more segments in the factory network hierarchy in the simulation server.

8. The device configuration method according to claim 7, further comprising: Use a device description service with one or more device information service libraries to select the one or more device description files.

9. The device configuration method according to claim 1, wherein, The non-configurable device parameters are read-only device parameters and are immutable.

10. The device configuration method according to claim 1, wherein, The simulation device includes: Manufacturer information that identifies the manufacturer of the one or more entity field devices; Device type information that identifies the type of the one or more entity field devices; and A device database that stores one or more parameter attributes extracted from the one or more device description files; configuration values of the simulation device; and parameter values of the simulation device.

11. The device configuration method according to claim 10, wherein, The device database also stores information on all function blocks and parameters.

12. The device configuration method according to claim 11, wherein, The device database also stores parameter type, parameter size, and parameter offsets for command communication of parameters participating in communication requests or communication responses.

13. The device configuration method according to claim 10, wherein, The simulation device further includes: Logic for accessing function blocks and individual parameters.

14. The device configuration method according to claim 10, wherein, The simulation device further includes: Logic for interpreting HART communication requests, accessing parameter values, and HART communication response data.

15. The device configuration method according to claim 1, further comprising: Create the factory network hierarchy in the device management system; Register devices in the database in the device management system to create registered devices in the device management system; and Before synchronizing the data of the factory network hierarchy and the data of the one or more registered devices to the simulation server, the device management system configures the registered devices to create the one or more registered devices in the database in the device management system.

16. The device configuration method according to claim 15, further comprising: For the device configuration, simulate: i) the configurable device parameters, ii) the non-configurable device parameters; And iii) before the device status, switch the communication request from the control bus driver in the field device communication server to the simulation server.

17. The device configuration method according to claim 1, further comprising: Access the simulation database in the simulation server; And Generate a communication response by the one or more simulation devices.

18. The device configuration method according to claim 1, further comprising: Simulate devices for at least one of the device types of HART devices, FF devices, Profibus devices, and ISA100.

Images