CN113039498A - Method for commissioning field devices in an industrial system network - Google Patents

Method for commissioning field devices in an industrial system network Download PDF

Info

Publication number
CN113039498A
CN113039498A CN201980074908.8A CN201980074908A CN113039498A CN 113039498 A CN113039498 A CN 113039498A CN 201980074908 A CN201980074908 A CN 201980074908A CN 113039498 A CN113039498 A CN 113039498A
Authority
CN
China
Prior art keywords
field device
information
field
service
industrial system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201980074908.8A
Other languages
Chinese (zh)
Other versions
CN113039498B (en
Inventor
罗兰·布劳恩
弗朗西斯科·门多萨
迪尔克·舒尔茨
海科·科齐奥勒克
安德里亚斯·伯格
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
ABB Schweiz AG
Original Assignee
ABB Schweiz AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ABB Schweiz AG filed Critical ABB Schweiz AG
Publication of CN113039498A publication Critical patent/CN113039498A/en
Application granted granted Critical
Publication of CN113039498B publication Critical patent/CN113039498B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4185Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4185Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
    • G05B19/41855Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication by local area network [LAN], network structure
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/4183Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by data acquisition, e.g. workpiece identification
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00Programme-control systems
    • G05B19/02Programme-control systems electric
    • G05B19/418Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41835Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by programme execution
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/23Pc programming
    • G05B2219/23336Identification of program, application, device to be controlled
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/25Pc structure of the system
    • G05B2219/25062Detect physical location of field device
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05BCONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00Program-control systems
    • G05B2219/20Pc systems
    • G05B2219/25Pc structure of the system
    • G05B2219/25428Field device
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)

Abstract

The invention relates to a method for debugging field equipment in an industrial system network, which comprises the following steps: connecting a field device to an industrial system network; providing information about the field device, the information including functional information for the field device; obtaining information related to a role of the field device in the automation application using the functional information for the field device; obtaining a set of parameters for the field device for operation in the automation application using the capability information related to the field device type and the information related to the role of the field device in the automation application; and downloading a parameter set to the field device.

Description

Method for commissioning field devices in an industrial system network
Cross Reference to Related Applications
This application claims benefit of the filing date of european patent application No. 18206305.7 filed on 2018, 11, 14, which is incorporated herein by reference in its entirety.
Technical Field
The invention relates to a method for commissioning field devices in an industrial system network.
Background
Commissioning of field devices in an industrial system network requires manual intervention, which can lead to errors and take time and effort.
Disclosure of Invention
It would therefore be advantageous to have a means of reducing or eliminating manual intervention for commissioning field devices in an industrial system network. The object of the invention is solved by the subject matter of the independent claims, wherein further embodiments are incorporated in the dependent claims.
In one aspect, a method of commissioning field devices in an industrial system network is provided.
The method comprises the following steps:
a) connecting a field device to an industrial system network;
c) providing information about the field device, the information including functional information for the field device;
d) obtaining information related to a role of the field device in the automation application using the functional information for the field device;
f) utilizing capability information (capability information) related to the field device type and information related to the role of the field device in the automation application to obtain a set of parameters for the field device for operation in the automation application; and
g) the parameter sets are downloaded to the field device.
In an example, the functional information for the field device includes an identity of the field device.
In an example, the identity of the field device is inferred from the industrial system network.
In an example, the identity of the field device is determined according to one or more of: the location of the field device in the industrial system network; an identity of one or more devices in proximity to the field device; and (4) manual input.
In an example, the functional information for the field device includes at least one capability of the field device.
In an example, step c) includes providing, by the field device, information about the device.
In an example, the method includes step b) of providing an address to the field device.
In an example, the address is a network address.
In an example, step b) includes collecting metadata for the field device and for at least a portion of the industrial system network to generate an address that is subsequently provided to the field device.
In this manner, a DNS name can be generated and provided to the field device that incorporates application-related semantics into the site name of the field device. Thus, using field Device (DNS) names helps operators to obtain/identify devices more efficiently and easily.
In an example, the method includes a step e) of obtaining at least some of the capability information using information about the field device provided by the field device.
In an example, at least some of the capability information is obtained from a server separate from the field device.
In an example, in step c), the information provided by the field device about the field device includes at least some of the capability information.
In an example, in step d), information related to the role of the field device is obtained from a server separate from the field device.
In an example, in step f), the parameter set is obtained from a server separate from the field device.
In an example, the parameter set includes data related to different devices of the same device type.
In an example, a method includes mapping a set of parameters to a field device.
In an example, the mapping includes a process of at least some of the data of the set of translation parameters.
In this manner, a parameter set may be used for an older device of the same device family, and the older parameter set may be mapped to a newer field device, involving some data transformation if necessary. In this way, device replacement is simplified.
In an example, the method includes a step h) of implementing a browsing process to match the controller with the field device, the matching including utilization of control-related functionality for the field device.
In an example, the functionality related to control comes from an information model implemented in the field device.
In an example, control-related functionality for a field device is included within functional information provided by the device.
Drawings
Exemplary embodiments will be described below with reference to the following drawings:
FIG. 1 illustrates a detailed static view of an architecture of an example of an implementation of a method of commissioning field devices in an industrial system network;
fig. 2 shows a detailed example of device discovery and parameterization within an example of a method of commissioning field devices in an industrial system network (UML interaction diagram);
fig. 3 shows a detailed example of signal matching within an example of a method of commissioning field devices in an industrial system network (UML interaction diagram);
fig. 4 to 5 show detailed examples of the deployment of components and hardware nodes within examples of a method of commissioning field devices in an industrial system network;
FIG. 6 depicts an excerpt of the OPC UA address space of a device OPC UA server; and
FIG. 7 illustrates an exemplary control flow diagram for an HMI service.
Detailed Description
Fig. 1 to 7 relate to a method for commissioning field devices in an industrial system network. A method of commissioning field devices in an industrial system network includes:
a) connecting a field device to an industrial system network;
c) providing information about the field device, the information including functional information for the field device;
d) obtaining information related to a role of the field device in the automation application using the functional information for the field device;
f) obtaining a set of parameters for the field device for operation in the automation application using the capability information related to the field device type and the information related to the role of the field device in the automation application; and
g) the parameter sets are downloaded to the field device.
According to an example, the functional information for the field device includes an identity of the field device.
According to an example, the identity of the field device is inferred from the industrial system network.
According to an example, the identity of the field device is determined according to one or more of: the location of the field device in the industrial system network; an identity of one or more devices in proximity to the field device; and (4) manual input.
According to an example, the functional information for the field device includes at least one capability of the field device.
According to an example, step c) includes providing, by the field device, information about the device.
According to an example, the method comprises a step b) of providing an address to the field device.
According to an example, the address is a network address.
According to an example, step b) includes collecting metadata for the field device and for at least a portion of the industrial system network to generate an address that is subsequently provided to the field device.
According to an example, the method comprises a step e) of obtaining at least some of the capability information using information about the field device provided by the field device.
According to an example, at least some of the capability information is obtained from a server separate from the field device.
According to an example, in step c), the information provided by the field device about the field device includes at least some of the capability information.
According to an example, in step d), information relating to the role of the field device is obtained from a server separate from the field device.
According to an example, in step f), the parameter set is obtained from a server separate from the field device.
According to an example, the parameter set includes data related to different devices of the same device type.
According to an example, a method includes mapping a set of parameters to a field device.
According to an example, the mapping includes a process of at least some of the data of the set of translation parameters.
According to an example, the method comprises a step h) of implementing a browsing process to match the controller with the field device, the matching comprising utilization of control-related functionality for the field device.
According to an example, the functionality related to control comes from an information model implemented in the field device.
According to an example, control-related functionality for a field device is included within functional information provided by the device.
Continuing with the figures, a plug-and-play system implementing a method of commissioning field devices in an industrial system network is shown and will now be described in detail.
FIG. 1 depicts a static view of a reference architecture, with the architecture focusing on ANSI/ISA-952 level and level 1 (level). The controller and the field devices communicate via OPC UA over ethernet for commissioning and operation. Existing fieldbus and analog connections may be included by having IO gateway nodes that arbitrate between different networks. With OPC UA servers, controllers and field devices become IIoT devices that are accessible by the plant owner from the internet when needed and are self-describing.
In particular, fig. 1 shows a controller OPC UA server storing control logic programs and controller state information. There are also device OPC UA servers that provide data and services for connected field devices. While classical client/server connections manage the self-commissioning of controllers and field devices, cyclic real-time communication for closed-loop control is supported by OPC UA publish/subscribe connections (IEC 62541-14).
With TSN enabled network switches, deterministic real-time control loops are possible. The publish/subscribe communications may be broker-based (e.g., via AMQP or MQTT) or broker-less. In the latter case, the publisher sends the data set to the multicast IP address via UDP intercepted by the subscriber. Using the lower level network protocols IGMP or MMRP, network traffic can be reduced so that the network switch only forwards network packets for which the subscriber has been registered.
In order to discover connected OPC UA servers, the reference architecture suggests an OPC UA controller local discovery server and a device local discovery server according to IEC 62541-12. Resource-constrained devices may alternatively use multicast dns (mdns) instead of local discovery servers, e.g., which is also implemented by Apple Bonjour or Spotify Connect. The mDNS may advertise a discovery URL for the OPC UA server to the client using DNS SRV records.
The controllers in the reference architecture provide for IEC 61131 runtime that can execute the PLCopen control logic program (R5). It can import control logic compatible with PLCopen from the engineering repository via the controller OPC UA server. The control logic exposes functional blocks that require input signals, for example, from a connection of a sensor, such as a level indicator. The control algorithm then calculates an output value, for example, for an actuator, such as a valve for a heat exchanger. The control algorithm runs cyclically, for example once every 100ms, and even once every 1ms for a particular application. 61131 run-time is decoupled from the actual field device and can run on different deployment targets.
The OPC UA server reveals information about the field devices in the reference architecture. Such a server may run on a dedicated network node or directly on a field device if the server has the appropriate CPU power and memory. On a dedicated node (such as an IO gateway), a server may manage data and services for a large number of field devices. The field devices are connected to the OPC UA server via a communication channel. This may encapsulate the fieldbus or analog communications, in which case it needs to be configured appropriately.
Device management is responsible for providing drivers for communication channels and parameterization for field devices. It obtains the driver from a common device driver repository (e.g., from a particular vendor or other organization). For example, the Fieldcom Group is in the process of setting up such servers for FDI device packages. The parameterization may depend on the imported engineering data and may also be altered via user input from the OPC UA client if fine-tuning is required. However, in order to make the equipment have basic characteristics, the imported engineering data is sufficient. Device management uploads the parameterizations to the field device.
Finally, the architecture contains a plug-and-play service that looks for connected controllers and handles signals that match field devices. The plug-and-play service has a built-in OPC UA client to obtain the required signal names from the controller and to browse the OPC UA server for the field device for matching signal names. It knows different semantic standards such as OPC UA, IEC 61987 or NAMUR NE131 of the device, which help to perform signal matching. For example, it may be deployed on an industrial PC or controller.
The device parameterization follows the procedure in fig. 2. First, in the case of a field device connected via an additional network connection, the device OPC UA server optionally scans the communication channel to which it is connected. Otherwise, this step may be omitted. Subsequently, the device OPC UA server announces itself on the network, which is obtained by the device management component.
The device management obtains the device IDs of the connected field devices, which may consist of the manufacturer name, the product type ID and the serial number (see IEC 62541-100).
If the device OPC UA server does not provide an ID, or if the provided ID is unknown to the device management or the format is unknown, it may attempt to deduce the device identity from the context information. Device management may, for example, analyze the network address of a device and determine surrounding devices in the same subnet. If these devices are known for device management and the engineering repository includes specifications of devices in the same area that have not been found on the network, it can predict which device has been connected. The device may also carry other information, such as geographic location, known nature of device type characteristics, or references to other devices, which may help infer its identity. If device management cannot determine device identity using any of the described methods, it can ask a human user for input and thus obtain a device ID.
The device management uses the ID to query a common device driver repository and engineering repository parameterization data for the device driver. If the device does not have a meaningful host name, device management may generate such a name by incorporating information from the device's OPC UA server. For example, in the case where a device has been replaced by a newer version, the engineering repository may contain parameterized data for older types of devices. In this case, the engineering repository may provide a mechanism that allows parameters to be mapped from one equipment type to another if the equipment belongs to the same family or at least has significant functional overlap. Mapping may involve changing parameter names, changing parameter types (e.g., converting 32-bit encoding to 64-bit encoding), and even changing parameter values (e.g., converting a predefined range of parameter values to another range).
It uploads the information to the OPC UA server, which forwards it to the actual field device. Finally, the OPC UA server updates its content and signals readiness to the device management. After this update process, the field device can be easily parameterized.
Now, signal matching can start, as shown in fig. 3. The plug-and-play service continuously searches for a controller OPC UA server connected to the network. The plug and play service connects to such a server and obtains a list of input and output signals required to execute the configured control logic program. Subsequently, the service will connect to any device OPC UA server that has been connected or is being connected during factory commissioning.
The plug-and-play service browses the address space of the OPC UA server and attempts to find a matching tag name for the configured device. Subsequently, the plug-and-play service searches for a PLCopen function with a specified input signal (primarily for actuators) and output signal (primarily for sensors). Once found, the plug-and-play service attempts to find a match with the signal name from the controller. In case the controller and the device use different signal names (since they have been configured independently), the matching may also depend on other information, such as physical location in the OPC UA address space and network configuration.
In case of a match, the plug-and-play service sets up a subscription of the controller to the output signal. This may be an OPC UA client/server connection that subsequently needs to handle the client session on the device OPC UA server, or it may be an OPC UA publish/subscribe connection via multicast UDP/IP or proxy. For fast loop control, the controller OPC UA server can bypass writing signal values into its address space and forward them directly to the 61131 runtime to compute the control logic output.
After setting the subscription, the plug-and-play service disconnects from the device OPC UA server and sets a flag in the controller OPC UA server to ask the human engineer for final approval. The found configuration may be relayed to an engineer who may perform a final check before actually starting the process.
The deployment of components and hardware nodes is flexible and allows different application context and resource constraints to be resolved. Fig. 4 and 5 show two different variants, wherein fig. 4 shows a classic setup (UML deployment diagram) and wherein fig. 5 shows a setup with smart field devices (UML deployment diagram).
The classical deployment in fig. 4 features a controller device, an IO gateway with connected field devices and a device management server. The latter also hosts a plug and play service that can then serve different controllers and IO gateways connected to the ethernet network link. The benefit of this deployment is investment protection. The deployment does not require IIoT enabled field devices, as the IO gateway can manage the required IIoT communications. Existing installations with fieldbus or analog connections can be updated with a small addition to the hardware.
The deployment with intelligent IIoT field devices (fig. 5) does not include IO gateway devices. The field device has sufficient computing power and memory and network interfaces to host its own OPC UA server and expose it on an ethernet network link. As a deployment variant, the controller device hosts a plug-and-play service and thus becomes an independent autonomous agent with the ability to configure itself given network access.
Many other forms of deployment are conceivable, for example, hosting 61131 runtime on a powerful actuator, factory side server, or cloud platform. These deployments depend on the particular application context, business constraints, and available hardware.
Fig. 6 depicts an excerpt of the OPC UA address space of a device OPC UA server. The address space follows the OPC UA specification for devices and contains a device set (DeviceSet) in its object tree. The IoT device (iotview) involved is according to PLCopen and the special ctrl configuration of the device itself. It therefore reveals important identifying information such as serial number, manufacturer, and required communication protocol.
As suggested by the reference architecture, the iotview contains special function blocks that expose their input and output variables, which are typically specified only for the controller. This functional block on the device is independent of any application or control function running on it. The plug-and-play service uses this information to match the signal name from the controller.
The following provides additional information regarding the details of a method of commissioning field devices in an industrial system network.
PnP service specification
The following section specifies different services from the plug and play service (pnp service) of fig. 1, which are used to satisfy the plug and play functionality. The services are described with an emphasis on the reader of this document should be able to implement them. For each service, a detailed description is given as well as the input and output of the service. In addition to some core services, a pseudo-code abstraction of the resulting implementation is provided.
Searching server (FindServers)
The findServers functionality allows OPC UA servers available in the network to be identified and made accessible for further processing in the PnPServer.
The findServers service returns to the server or discovers servers known to the server. The detailed behavior of the discovery server is described in detail in, for example, the paper by L.D urkop et al published on pages 248 to 253 in the industrial informatics (INDIN) of the 11 th IEEE international conference, 7 th 2013, for the use OPC-UA for the automatic configuration of real-time Ethernet Systems (OPC-UA is used for automatic configuration of real-time Ethernet Systems). Additionally, the same behavior may be implemented using a multicast dns (mdns) protocol, for example, if resource constraints exist within the device. The pnp service uses a discovery method to identify all available OPC UA servers within the network in order to support a self-debugging step. Thus, the pnp servicece also filters the utilized OPC UA servers in order to avoid duplicate processing of the device.
The mDNS version of the service does not require specific parameters.
Browsing
The PnP service provides browsing functionality to scan OPC UA information models and check signals that can be matched to each other.
And analyzing the information model of the discovered OPC UA server by the browsing service. Once the findServers service identifies the OPC UA endpoint, the browsing service begins to connect to the server and browse its information model. Thus, the service starts to browse the types, which are inherited by the PLCopen [3] type. Once these types are identified, they are stored by the service for use in the second phase of the browsing process. In this second phase, the browse service looks up to collect instances of the PLCopen type. During the two-phase browsing process, the service follows the hierarchical structure references of the information model only by using the depth-first search algorithm (DFS). At each node, the browsing service invokes a matching service to look for possible matches between the identified signals of the control logic and the potential input and output signals of the browsed device. By using this matching service, the browsing service can also be used for non-PLCopen consistency information models. The following pseudo-code fragments visualize the functionality of the browsing service. The pseudo-code fragment also includes a matching service call for each node.
Embodiments of List 1 browsing services
Figure BDA0003064375740000111
Parameter(s)
Inputting:
-the ID of the current node
-list of matching rules that should be applied during the browsing process
Integers indicating the direction of viewing, complying with the OPC UA specification for reference
And (3) outputting:
-the node that is matching is stored in a global list
Matching
As long as both signals satisfy the matching criteria described in the so-called matching rule object, the service matches them to each other.
The matching service is used to identify which input signal of the device fits the output signal of the control logic and vice versa. The service itself can only be used with the browsing service. It cannot be invoked by itself. Therefore, so-called matching rule objects need to be implemented and added to the browsing service. These matching rule objects check at each node whether the input/output signals can fit into the signals of the control logic. If these input/output signals are suitable, the pnp provider will process it and subscribe to the necessary multicast address to start distributing signals within a particular multicast group due to the specification of the matching rule object.
Parameter(s)
Inputting:
-the ID of the current node
-a pointer to an OPC UA client instance that gets more information from the current node if necessary
And (3) outputting:
boolean values indicating positive or negative match results
Matching rule (Matchingcule)
A matching rule is an object that inherits from the base class and provides the functionality to match two given signals to each other as nodeids.
The matching rules concept allows the PnPServer to be easily extended using different business logic for matching signals of controllers and devices. Due to this, this is not an explicit service of the pnp service, but a core functionality that makes the pnp service flexible and easy to extend. The following pseudo code illustrates the structure of the base class and its functionality that needs to be implemented by the derived objects.
List 2 implementation of Matchingcule base Category
Figure BDA0003064375740000121
These matching objects are used in the matching service to identify which nodes/signals should be matched to each other. A match indicates that the value stored within the node is subscribed to or published depending on the type of signal (input or output signal).
Add node (Addnodes)
The addnucleotides service is designed to add appropriate signal structures to the controller to store the necessary information for matching input and output signals. This structure is unnecessary if the controller supports PLCopen.
The addNodes service enables nodes to be added to the information model during runtime. PnPServer uses this functionality to support controllers or devices that do not conform to PLCopen. These devices are supported by adding specific node structures to the information model, storing detailed information about their input and output signals, data types and endpoint information. The pnp service then uses this data to achieve a match between the two signals.
Parameter(s)
Inputting:
-list of nodes added to information model
End point url
And (3) outputting:
-status flag
Operation of
This section describes the runtime functionality of PnPServer.
At startup, the PnP service will update its matching table. This means that the PnP service gets all input and output signals from the controller to provide input for the matching service. During runtime, the PnP service itself is organized in different states. Most of these states are set internally, e.g. to check if a new device is available (state _ new _ device _ is _ available) which has not been explored before. However, some of them are set externally, in particular according to other functionalities of the PnP service (such as the replacement functionality) (state _ matching _ mode). While the PnP service is in the matching mode, it waits for a new device that has not been previously browsed.
It finds that the communication between the server listeners is done via the message queue. Once a new endpoint is received, the PnP service updates a signal matching table containing signals from the controller and matched signals from the device to the controller. If not all signals are matched, then the PnP service invokes a browse service. If all signals are matched after this browsing process, the PnP service will not attempt to match signals even if new devices are available. The pseudocode below will generally understand the process flow of the PnP service.
List 3PnP service execution method implementation
Figure BDA0003064375740000141
HMI
FIG. 7 illustrates the control flow of the HMI service. In the presentation program embodiment, the PnPServer provides a simple Command Line Interface (CLI). CLI is used to trigger different services/functionalities of PnPServer
In general, the control flow of an HMI service is divided into two parts: commissioning and device replacement. The debug phase begins immediately after startup. At this stage, the pnp service waits for the discovery of a new device announced by the server/functionality. Thus, the user presses "I" to listen to the new device. Once a new device appears, the pnp service browses the device and uses the matching service for identifying signals that may be matched. If the signals are matched and not all signals of the controller are matched, the HMI jumps back to listening for new equipment. If all signals are matched, then the PnPServer shows a matching table and requires that the table be verified. If the user presses "ok", then the PnPServer will trigger the controller and all other devices to start production. In another case, the matching results may be defective, such that manual repair signal matching is necessary.
The second part of the HMI service is an announcement of device replacement. During the production state, this functionality is triggered by pressing "r". Hereafter, the pnp service lists all devices that can be replaced. The user needs to select a device from the list. In the next step, the affected ones of the analysis will be completed by the PnPServer and presented to the user. Based on this analysis, the PnPServer requires that the device be validated for replacement and that all device-affected settings be placed in emulation mode. The device that should now be replaced can be unplugged and a new device can be plugged in. In doing so, the pnp service jumps back to listening, identifying a new device, starting to browse for the new device and matching the new signal with a non-matching signal in the controller. Again, the matching table is presented and needs to be verified by the user.

Claims (20)

1. A method of commissioning field devices in an industrial system network, the method comprising:
a) connecting a field device to an industrial system network;
c) providing information about the field device, the information including functional information for the field device;
d) utilizing the functional information for the field device to obtain information related to a role of the field device in an automation application;
f) obtaining a set of parameters for the field device for operation in the automation application utilizing capability information related to a type of the field device and information related to the role of the field device in the automation application; and
g) downloading the parameter set to the field device.
2. The method of claim 1, wherein the functional information for the field device includes an identity of the field device.
3. The method of claim 2, wherein the identity of the field device is inferred from the industrial system network.
4. The method of any of claims 2-3, wherein the identity of the field device is determined according to one or more of: a location of the field device in the industrial system network; an identity of one or more devices in proximity to the field device; and (4) manual input.
5. The method of any of claims 1-4, wherein the functional information for the field device includes at least one capability of the field device.
6. The method of any one of claims 1 to 5, wherein step c) comprises providing, by the field device, the information about the device.
7. The method according to any one of claims 1 to 6, comprising a step b) of providing an address to the field device.
8. The method of claim 7, wherein the address is a network address.
9. The method of any one of claims 7 to 8, wherein step b) includes collecting metadata for the field device and for at least a portion of the industrial system network to generate the address that is subsequently provided to the field device.
10. Method according to one of claims 1 to 9, comprising a step e) of obtaining at least some of the capability information using the information about the field devices provided by the field devices.
11. The method of claim 10, wherein the at least some of the capability information is obtained from a server separate from the field device.
12. The method according to one of claims 1 to 11, wherein in step c) the information provided by the field device about the field device comprises at least some of the capability information.
13. The method according to any of claims 1 to 12, wherein in step d) the information relating to the role of the field device is obtained from a server separate from the field device.
14. The method of any of claims 1-13, wherein in step f), the set of parameters is obtained from a server separate from the field device.
15. The method of claim 14, wherein the set of parameters comprises data related to different devices of a same device type.
16. The method according to any one of claims 14 to 15, wherein the method comprises: mapping the parameter set to the field device.
17. The method of claim 16, wherein the mapping comprises a process of converting at least some of the data of the parameter set.
18. Method according to one of claims 1 to 17, comprising a step h) of implementing a browsing process to match a controller with the field device, the matching comprising the utilization of control-related functionalities for the field device.
19. The method of claim 18, wherein the functionality related to control is from an information model implemented in the field device.
20. The method of any of claims 18-19, wherein the functionality related to control for the field device is included within the functional information provided by the device.
CN201980074908.8A 2018-11-14 2019-11-11 Method for commissioning field devices in an industrial system network Active CN113039498B (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP18206305.7 2018-11-14
EP18206305.7A EP3654123B1 (en) 2018-11-14 2018-11-14 Method of comissioning a field device in an industrial system network
PCT/EP2019/080902 WO2020099340A1 (en) 2018-11-14 2019-11-11 Method of comissioning a field device in an industrial system network

Publications (2)

Publication Number Publication Date
CN113039498A true CN113039498A (en) 2021-06-25
CN113039498B CN113039498B (en) 2024-08-09

Family

ID=64476921

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980074908.8A Active CN113039498B (en) 2018-11-14 2019-11-11 Method for commissioning field devices in an industrial system network

Country Status (4)

Country Link
US (1) US11940778B2 (en)
EP (1) EP3654123B1 (en)
CN (1) CN113039498B (en)
WO (1) WO2020099340A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114189438A (en) * 2021-12-15 2022-03-15 重庆邮电大学 A method for automatic discovery and configuration of industrial equipment based on OPC UA

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3929673B1 (en) * 2020-06-24 2024-08-07 ABB Schweiz AG Field device configuration tool
EP3961323A1 (en) * 2020-08-25 2022-03-02 ABB Schweiz AG Replacement of industrial field device
EP4040245A1 (en) * 2021-02-09 2022-08-10 Siemens Aktiengesellschaft Method, computer-implemented-tool, contraption and configuration arrangement for configuring a device to be commissioned of a set of devices for commissioning with a technical or cyber-physical system
US20240056451A1 (en) * 2021-04-01 2024-02-15 Nippon Telegraph And Telephone Corporation Communication system, anomaly detection apparatus, anomaly detection method, and program
US11936740B2 (en) * 2021-05-18 2024-03-19 Schneider Electric USA, Inc. Modeling and management of industrial network using OPCUA
CN114827207A (en) * 2022-04-27 2022-07-29 机械工业仪器仪表综合技术经济研究所 Production process rapid reconstruction method based on OPC UA
EP4293438A1 (en) * 2022-06-13 2023-12-20 Abb Schweiz Ag Generating configuration information for newly integrated field devices
DE102022133650A1 (en) * 2022-12-16 2024-06-27 Codewrights Gmbh System and method for accessing a control unit to at least one field device

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070250180A1 (en) * 2006-04-11 2007-10-25 Invensys Systems, Inc. Method and supporting configuration user interfaces for streamlining installing replacement field devices
EP1901145A2 (en) * 2006-08-23 2008-03-19 MicroNet Sensorik GmbH Field device and method of operating the same
CN102662903A (en) * 2012-03-31 2012-09-12 浪潮电子信息产业股份有限公司 Method for realizing hot-plug of PCIE equipment by CPLD or FPGA
CN103748524A (en) * 2011-03-31 2014-04-23 Abb技术有限公司 A method of engineering and diagnosing a field device and a system thereof
WO2014094982A1 (en) * 2012-12-20 2014-06-26 Abb Ag Commissioning system and method for a secure exchange of sensitive information for the commissioning and configuring of technical equipment
US20140274181A1 (en) * 2013-03-15 2014-09-18 Rosemount Inc. Resource optimization in a field device
EP3065010A2 (en) * 2015-03-06 2016-09-07 Yokogawa Electric Corporation Field device commissioning system and method
CN105940355A (en) * 2014-02-21 2016-09-14 西门子公司 Method and field device for starting an industrial automation network
CN106325229A (en) * 2015-06-30 2017-01-11 邻元科技(北京)有限公司 Distributed computing network system
US20170034308A1 (en) * 2014-01-31 2017-02-02 Abb Schweiz Ag Method for commissioning and joining of a field device to a network
CN108459574A (en) * 2018-03-27 2018-08-28 重庆邮电大学 It is a kind of that system is managed based on the semantic field device information with OPC UA

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080301270A1 (en) * 2007-06-01 2008-12-04 Abb Ag System and method for directed provision and installation of device-specific functionalities, in particular for field devices
DE102010029952B4 (en) * 2010-06-10 2019-06-27 Endress + Hauser Process Solutions Ag Method for integrating at least one field device in a network of automation technology
DE102011079890A1 (en) * 2011-07-27 2013-01-31 Codewrights Gmbh System and method for operating field devices in an automation system
US8818417B2 (en) * 2011-10-13 2014-08-26 Honeywell International Inc. Method for wireless device location using automatic location update via a provisioning device and related apparatus and system
DE102012108990A1 (en) * 2012-09-24 2014-05-15 Endress + Hauser Process Solutions Ag Method for locating a field device in an automation system
DE102013216501A1 (en) * 2013-08-20 2015-02-26 Vega Grieshaber Kg Instrument access device, field device and method for controlling access to a meter
WO2016070899A1 (en) * 2014-11-03 2016-05-12 Siemens Aktiengesellschaft Method for starting up an industrial automation network, and field device
JP6248985B2 (en) * 2015-06-11 2017-12-20 横河電機株式会社 Information search system and information search method
WO2017002019A1 (en) * 2015-06-29 2017-01-05 Abb Schweiz Ag Method and system to increase processing capability of field devices in an industrial control system
DE102015116381B4 (en) * 2015-09-28 2023-08-31 Abb Schweiz Ag Method for managing and configuring field devices in an automation system
GB2559902B (en) * 2015-10-12 2022-07-06 Fisher Rosemount Systems Inc I/0-Abstracted field device configurations
DE102016104141A1 (en) * 2016-03-08 2017-09-14 Sick Ag Device and method for connecting a mobile device to a field device
US20180024847A1 (en) * 2016-07-22 2018-01-25 Fisher-Rosemount Systems, Inc. Help system for a portable industrial device
US10324434B2 (en) * 2016-10-12 2019-06-18 Fisher-Rosemount Systems, Inc. Method and system for commissioning process control hardware
DE102017104912A1 (en) * 2017-03-08 2018-09-13 Endress+Hauser Process Solutions Ag Method for parameterizing a field device of automation technology
US11327729B2 (en) * 2017-05-31 2022-05-10 Abb Schweiz Ag Field device interfaces in industrial control systems
JP6939162B2 (en) * 2017-07-13 2021-09-22 横河電機株式会社 Plant control support device, plant control support method, plant control support program and recording medium

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070250180A1 (en) * 2006-04-11 2007-10-25 Invensys Systems, Inc. Method and supporting configuration user interfaces for streamlining installing replacement field devices
EP1901145A2 (en) * 2006-08-23 2008-03-19 MicroNet Sensorik GmbH Field device and method of operating the same
CN103748524A (en) * 2011-03-31 2014-04-23 Abb技术有限公司 A method of engineering and diagnosing a field device and a system thereof
CN102662903A (en) * 2012-03-31 2012-09-12 浪潮电子信息产业股份有限公司 Method for realizing hot-plug of PCIE equipment by CPLD or FPGA
WO2014094982A1 (en) * 2012-12-20 2014-06-26 Abb Ag Commissioning system and method for a secure exchange of sensitive information for the commissioning and configuring of technical equipment
US20140274181A1 (en) * 2013-03-15 2014-09-18 Rosemount Inc. Resource optimization in a field device
US20170034308A1 (en) * 2014-01-31 2017-02-02 Abb Schweiz Ag Method for commissioning and joining of a field device to a network
CN105940355A (en) * 2014-02-21 2016-09-14 西门子公司 Method and field device for starting an industrial automation network
US20170176982A1 (en) * 2014-02-21 2017-06-22 Siemens Akiengesellschaft Field device and method for starting up an industrial automation network
EP3065010A2 (en) * 2015-03-06 2016-09-07 Yokogawa Electric Corporation Field device commissioning system and method
CN106325229A (en) * 2015-06-30 2017-01-11 邻元科技(北京)有限公司 Distributed computing network system
CN108459574A (en) * 2018-03-27 2018-08-28 重庆邮电大学 It is a kind of that system is managed based on the semantic field device information with OPC UA

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HEIKO KOZIOLEK ETAL.: "Self-Commissioning Industrial IoT-Systems in Process Automation: A Reference Architecture", 《2018 IEEE INTERNATIONAL CONFERENCE ON SOFTWARE ARCHITECTURE (ICSA)》, 31 July 2018 (2018-07-31), pages 196 - 205 *
刘军钢: "基于Device Net的智能数据采集系统的设计与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》, 15 March 2017 (2017-03-15), pages 140 - 1500 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114189438A (en) * 2021-12-15 2022-03-15 重庆邮电大学 A method for automatic discovery and configuration of industrial equipment based on OPC UA
CN114189438B (en) * 2021-12-15 2023-09-05 重庆邮电大学 Industrial equipment automatic discovery and configuration method based on OPC UA

Also Published As

Publication number Publication date
EP3654123A1 (en) 2020-05-20
US11940778B2 (en) 2024-03-26
US20210286346A1 (en) 2021-09-16
EP3654123B1 (en) 2022-02-16
CN113039498B (en) 2024-08-09
WO2020099340A1 (en) 2020-05-22

Similar Documents

Publication Publication Date Title
CN113039498B (en) Method for commissioning field devices in an industrial system network
US12228918B2 (en) System and method for interoperable communication of an automation system component with multiple information sources
CN108667807B (en) A protocol adaptive method and system based on monitoring cloud platform and gateway
Alaya et al. Toward semantic interoperability in oneM2M architecture
US8407349B2 (en) Discovering and identifying manageable information technology resources
US7017148B2 (en) Apparatus and method for UPnP device code generation using XML
CN108377207A (en) A kind of access of platform of internet of things equipment and configuration method
US7603266B2 (en) Generic emulator of devices in a device communications protocol
TWI506553B (en) Method and system for automatic detecting and resolving apis
JP6201917B2 (en) System and method for configuring field devices
CN101185307A (en) Gateway device and control device
CN109120477B (en) Dynamic analysis method, device, server and storage medium based on modbus protocol
Panda et al. Plug&Produce Integration of Components into OPC UA based data-space
CN107818268A (en) The access control method and server of big data platform
Jacoby et al. FA 3 ST Service–An open source implementation of the reactive asset administration shell
CN116016667A (en) A unified management method and system for multiple types of registration centers on a cloud native platform
CN104793984A (en) Equipment modeling method and device and cloud platform
US20230019659A1 (en) Generating application programming interface based on object models from network devices
JP2004126817A (en) Setting tool device and program product
CN101145953B (en) Method and system for dynamic debugging of network device management software
CN119561673B (en) Service registration method, blockchain total system, edge node, medium and product
Paulino et al. A middleware framework for the web integration of sensor networks
CN111641668B (en) Heterogeneous execution engine in network center process control system
CN117082158A (en) Heterogeneous micro-service framework treatment system, method and equipment
CN116233272A (en) NC-Link-based multi-source heterogeneous device protocol conversion method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
OSZAR »