Method for replacing a first sensor with a second sensor

Abstract

The invention discloses a method for exchanging a first sensor with a second sensor at a measuring point in a network-based measuring system, comprising the following steps, wherein steps a) to g) are performed once during commissioning of the first sensor: a) Connecting the first sensor to the network-based measurement system; b) Requesting a network address from the first sensor; c) Detecting the specific location of the first sensor; d) Identifying the first sensor; e) Assigning a network address to the first sensor; f) Configuring the first sensor; g) Storing the configuration of the first sensor, in particular with checksum and / or hash; h) Swap the first sensor with the second sensor; i) Requesting a network address from the second sensor; j) Detecting the specific location of the second sensor; k) Identifying the second sensor; l) Sending the stored configuration of the first sensor to the second sensor if the second sensor is to replace the first sensor; or sending the stored configuration of the first sensor to the second sensor if the second sensor is the same as the first sensor, and the current configuration of the second sensor differs from the stored configuration of the first sensor; and m) Assigning the original network address of the first sensor to the second sensor.

Description

[0001] The invention relates to a method for exchanging a first sensor with a second sensor, a computer program product, a network device and a measuring system.

[0002] Field devices connected to a higher-level system, such as a (process) control system (or a programmable logic controller (PLC) or Supervisory Control and Data Acquisition (SCADA)), via digital data communication (i.e., a fieldbus), identify themselves and have a configuration (parameterization) specific to the corresponding measuring point. If such a field device is replaced with another (even if it is an identical model), it cannot immediately perform the function of the previous system, as neither the identification nor the configuration matches the measuring point.

[0003] This problem was addressed in various devices of the registration ring by a so-called "HistoROM" module, which stores the aforementioned data. In the event of a device replacement, the HistoROM from the old device is inserted into the new device, which can then immediately take over the functions of the old device, since the HistoROM contains the entire device identity and configuration.

[0004] In the case of analytical measuring instruments, the sensors are often physically separated from the actual fieldbus-enabled field devices (transmitters), for example, in the applicant's Memosens technology, where the actual sensor is connected to a transmitter via a cable. Typically, the sensor element must be frequently removed from the process for maintenance or replacement purposes, as sensor systems in analytical systems are subject to high wear. This is not a problem with Memosens technology, as the sensor only stores calibration and adjustment values. The field device identity and configuration belonging to the measuring point are stored in the transmitter. This allows for easy sensor replacement without the need for recommissioning.

[0005] It is becoming clear that in the future, classic fieldbuses (Profibus PA / DP, Modbus RS485, HART, Foundation Fieldbus, and similar) will be replaced by communication systems that can be integrated into Ethernet network infrastructures. Systems such as Ethernet Advanced Physical Layer (Ethernet-APL or APL for short (see https: / / www.profibus.com / download / apl-white-paper / )) and Single-Pair Ethernet (SPE) are particularly advantageous in this regard, as they enable simple and long cabling and can also provide power. However, classic Ethernet (possibly with PoE) and wireless Ethernet variants (WLAN) will also play a role.

[0006] In Ethernet-based networks, network participants are typically addressed via a unique IP address. While these network addresses can be assigned manually and statically, dynamic addressing is almost always used in practice to simplify network configuration and avoid manual errors and address collisions. Dynamic addressing is usually accomplished using DHCP (Dynamic Host Configuration Protocol). This provides field devices with a unique IP address, allowing the higher-level system to contact them via a variety of Ethernet protocols (PROFINET, Ethernet / IP, OPC / UA, ModbusTCP, etc.).

[0007] The following problem can occur: If a sensor is connected directly to the network, replacing it will cause the new sensor to appear as an unconfigured or incorrectly configured device, while the control system will no longer be able to reach the old device. This results in a communication failure. The new device must therefore first be put into operation, for example, by backing up and restoring the configuration of the old device and then "onboarding" or integrating it into the control system.

[0008] This makes frequent sensor replacement, as is necessary in analytical measurement technology, especially for pH, oxygen and ion-selective electrode sensors, impractical for a directly connected sensor in such network systems, as the required effort is high and requires actions not only by a technician directly at the measuring point, but also by the system administrator of the control system, which is time-consuming and costly.

[0009] In the case of the IO-Link fieldbus, this problem is solved by the "Data Storage" method: Each IO-Link port connected to the IO-Link master is assigned to exactly one measuring point and exactly one sensor system. The IO-Link master always stores a backup of all device settings. If a device is replaced, the IO-Link master writes the target configuration to the new field device, eliminating the need for manual intervention. However, this method only works with a point-to-point connection like IO-Link, as only here can the physical port be uniquely assigned and directly connected to the intelligent controller (IO-Link master). A point-to-point connection is a type of connection where communication via the medium (cable) takes place only between exactly two participants.This is the case with IO-Link: The IO-Link master communicates with each IO-Link field device directly, so there are no bus addresses. It is therefore even possible to label the cable itself with the measurement point designation, as it is unambiguous.

[0010] The PROFINET fieldbus offers the "Simple Device Replacement" (SDR) feature, which allows sensors to be replaced with identical sensors without individual manual configuration. PROFINET devices are typically assigned device names and IP addresses using the "Discovery and Configuration Protocol" (DCP), which enables, but also requires, local network management of the corresponding (local) PROFINET network. A DHCP server is also required for the entire network; this server operates independently of the DCP, and the DHCP server must be coordinated with the DCP.

[0011] Bus systems, such as Modbus RS485, operate multiple communication devices on a single communication line, each of which can be distinguished and addressed via a unique address. From the perspective of the communication master, the physical location of the devices cannot be determined. The same limitation exists in an outdated 10BASE2 Ethernet network.

[0012] However, modern Ethernet networks do not use shared cabling, as this has proven too susceptible to interference and too slow in practical applications. Instead, hub architectures have become the standard, eliminating the problem of electrical interference through dedicated cabling between network participants and the hub.

[0013] Therefore, each bus system has its own unique solution (see above, such as PROFINET, Modbus, IO-Link), offering advantages for that specific system. A generic solution does not yet exist, and users must know and correctly apply the specific solution for each bus.

[0014] Network hubs, especially across different bus systems, share a common element, at least at the communication level: the individual participants share the network bandwidth and can interfere with each other. For this reason, hubs have been almost completely replaced by network switches, whose network topology is identical to that of network hubs from a cabling perspective.

[0015] The difference here is that switches allow for the mutual isolation of participants from one another. For example, if three computers A, B, and C and a server are connected to a switch in a star topology, and computer A communicates with the server and computer B with computer C, this can be achieved through a logically "direct connection" (switching) between the respective participants. The bandwidth remains at its maximum because the two data connections can operate without interference from each other. Furthermore, a network switch can isolate faulty network participants that would, for example, cripple the network by flooding it with broadcast requests. These advanced switching functionalities are found in modern "managed switches," which are commonly used in professional Ethernet networks.

[0016] Managed switches allow the administration and monitoring of data connections running through the switches via management control protocols such as the Simple Network Management Protocol (SNMP). This includes monitoring network traffic (utilization), allowing and blocking network participants based on their MAC address, distributing rules governing how network participants can communicate with each other, and creating virtual subnets.

[0017] Since each network port in such a switched-network topology can be uniquely assigned, managed switches using the SNMP protocol can also determine which network device is connected to which port. The identification of the network devices is typically done via their Ethernet MAC address.

[0018] When a sensor is connected to the Ethernet network (e.g., via APL or SPE), it can, in principle, be uniquely assigned to a network port via its MAC address. A DHCP server uses the sensors' MAC addresses for identification when assigning IP addresses. The control system can then communicate with the sensors using the IP addresses assigned via DHCP.

[0019] However, if a sensor is replaced by another sensor of the same type, as described above, the DHCP server would assign the new sensor a new IP address because it has a different MAC address. The old sensor would no longer be reachable by the control system, and the new sensor would be unknown to the system. Even if the control system were to accept the sensor as a replacement for the old one, its configuration would not be identical to that of the previous sensor, meaning the measurement task could not be directly transferred.

[0020] The invention is based on the objective of realizing, in a generally valid way, the rapid interchangeability of sensors known from classic sensor-transmitter combinations or specialized fieldbus protocols such as IO-Link in an Ethernet-based network, even with directly connected sensors (without their own transmitter).

[0021] The task is solved by a method for exchanging a first sensor with a second sensor at a measuring point in a network-based measurement system, comprising the following steps, wherein steps a) to g) are performed once during the commissioning of the first sensor: a) Connecting the first sensor to the network-based measurement system; b) Requesting a network address from the first sensor; c) Detecting the specific location of the first sensor; d) Identifying the first sensor; e) Assigning a network address to the first sensor; f) Configuring the first sensor; g) Storing the configuration of the first sensor, in particular with checksum and / or hash; h) Swap the first sensor with the second sensor; i) Requesting a network address from the second sensor; j) Detecting the specific location of the second sensor; k) Identifying the second sensor; l) Sending the stored configuration of the first sensor to the second sensor if the second sensor is to replace the first sensor; or sending the stored configuration of the first sensor to the second sensor if the second sensor is the same as the first sensor, and the current configuration of the second sensor differs from the stored configuration of the first sensor; and m) Assigning the original network address of the first sensor to the second sensor.

[0022] One embodiment provides that the identification of the sensor is based on the type of sensor, in particular information about the type, manufacturer, firmware version and / or serial number, or by means of a unique identifier, in particular a Universally Unique Identifier.

[0023] One design provides that the configuration of the sensor involves parameters and settings, in particular regarding the measuring principle, measuring duration, measuring interval, measuring cycle, transmission cycle, network settings and fieldbus settings, among others.

[0024] One design provides that private data, in particular login data, private key(s) and certificate(s), of the first sensor are stored as part of the configuration.

[0025] One design provides that a counter is incremented for each sensor when the sensor is used as a "second sensor", i.e., as a replacement sensor.

[0026] One design provides that the counter is stored in the sensor and in the network-based measurement system, whereby a comparison of the stored counter reading in the network-based measurement system and the counter reading stored in the sensor is used to determine whether the connected device is an old device and must first be overwritten with configuration data for correct operation.

[0027] One design provides that the second sensor is a new sensor or a sensor with factory settings.

[0028] One design provides that the second sensor is any sensor, whereby the counter reading is used to determine whether the sensor needs to be overwritten with configuration data.

[0029] One implementation involves replacing the MAC address of the second sensor with the MAC address of the first sensor.

[0030] One implementation provides that in step g) “saving the configuration of the first sensor” this configuration is saved as the target configuration and after a sensor exchange the target configuration is loaded into the second sensor.

[0031] One design provides that the sensor sends a change in its configuration and, if necessary, the target configuration is updated.

[0032] One design provides that the sensor is queried after a change in configuration, especially cyclically, and the target configuration is updated if necessary.

[0033] One design provides for the configuration to be continuously and historically backed up.

[0034] One design involves performing a differential data backup.

[0035] The task is further solved by a computer program product comprising program instructions which, when executed on a computer system, cause the computer system to perform a procedure as described above.

[0036] The task is further solved by a network device that includes means for implementing a procedure as described above.

[0037] The task is further solved by a measuring system comprising at least a first sensor, a second sensor and a network device as described above with a control service, which is designed to carry out a procedure as described above.

[0038] This will be explained in more detail using the following figures. Fig. Figure 1 shows a measuring system. Fig. Figure 2 shows a measuring system in one configuration. Fig. Figure 3 shows a measuring system in one configuration. Fig. Figure 4 shows a symbolic representation of the measuring system.

[0039] In the figures, identical features are marked with the same reference symbols.

[0040] First, three embodiments of a measuring system in which the claimed method is applied and in which the claimed device is arranged will be discussed. Subsequently, the claimed method will be described with regard to the replacement of a first sensor with a second sensor in such a measuring system.

[0041] A measuring system typically comprises several measuring points. A measuring point includes one or more sensors. A measuring point is generally defined as a fixed or mobile structure where a physical and / or chemical parameter is measured over a defined period.

[0042] A measuring point is, for example, a container with a pipeline leading from it. To measure the container's fill level as a process variable, two level sensors, for example, with radar as the sensor unit, are attached to the tank. To measure the flow velocity in the pipeline, a flow meter is attached, whose sensor unit determines the flow velocity of the medium flowing through the pipeline as the primary process variable according to the Coriolis principle. Furthermore, a temperature measuring device is installed at the measuring point, which determines the temperature of the medium flowing through the pipeline using a high-precision temperature sensor as its sensor unit. Additionally, the conductivity and pH value of the medium in the container are determined. The entirety of these sensors on this container constitutes a measuring point.

[0043] The term "sensor" is used below, with more details provided further below. However, this also generally includes other field devices such as actuators or relays.

[0044] Fig. Figure 1 shows a measuring system 1. The measuring system 1 includes at least a first sensor 2a, a second sensor 2b and a third sensor 2c.

[0045] Sensor 2a, like the other sensors 2b-f (see below), is, for example, an ion-sensitive sensor, in particular a pH sensor, conductivity sensor, turbidity sensor, temperature sensor, oxygen sensor, a sensor for measuring the absorption of electromagnetic waves in the medium, for example, with wavelengths in the UV, IR, and / or visible range, or a sensor for measuring the concentration of metallic or non-metallic substances. Other configurations of sensor 2a are possible, such as a pressure sensor, level sensor, or flow sensor. The sensor type is part of the "sensor type," along with information about the manufacturer, serial number, or firmware version of the sensor. Sensors 2a-f are used to determine a measured quantity. For this purpose, the sensor typically includes at least one sensor element for detecting a measured quantity in process automation. Sensor 2a-f, with its sensor element, is placed in the medium to be measured.If multiple sensors are depicted, they can be designed the same or differently.

[0046] In Fig. In the first step, sensors 2a, 2b, and 2c are connected to an intermediate unit 5 via a network-based protocol 10. The intermediate unit 5 is configured here as a switch 6. The intermediate unit 5 is connected, for example, to the higher-level unit 3 via a non-network-based protocol 11 (HART, WirelessHART, Modbus, PROFIBUS, Foundation Fieldbus, IO-Link, Bluetooth, or RFID). The higher-level unit 3 is in turn connected to an operator panel 4. The intermediate unit 5 can also be connected to the higher-level unit 3 via a network-based protocol, such as Ethernet-APL. Fig. In Figure 1, this is indicated by the reference symbol "10" in parentheses, as is the case in the other figures. The connection of the higher-level unit 3 to the associated switch 6 depends on the technology. There are corresponding switches, such as an Ethernet APL switch, SPE switch, etc. A gateway, which can also be integrated into the switch or the operator panel, can convert one protocol into a second, for example, HART, Modbus, PROFIBUS, Foundation Fieldbus, or others.

[0047] The higher-level unit 3 is, for example, a control system, a programmable logic controller (PLC), or similar device. Using the higher-level unit 3, the sensors 2a-c can optionally be operated, configured, and parameterized via an operating unit 4. The entire measurement system 1 can be controlled and operated via the higher-level unit 3.

[0048] The network-based protocol 10 comprises a TCP / IP protocol. In one embodiment, the network-based protocol 10 includes, for example, Ethernet Advanced Physical Layer (Ethernet-APL) as the physical layer. "Physical layer" here is to be understood according to the ISO / OSI reference model (Open Systems Interconnection Model), which is a reference model for network protocols as a layered architecture. This refers to layer 1, the "physical layer," sometimes called the "bit transmission layer" in German. The use of other network-based protocols is possible due to the inventive concept. In one embodiment, the protocol comprises a standard according to IEC 63171-7, in particular Single-Pair Ethernet (SPE). In another embodiment, the protocol is designed as a wireless protocol, in particular according to an IEEE 802.11 standard, i.e., WiFi or WLAN.

[0049] Connection 10 supplies power to sensors 2a-f and enables bidirectional data exchange. For example, measurement data or configuration data is transmitted.

[0050] Some network-based protocols 10 combine communication and power supply, such as Ethernet-APL or SPE. Power over Ethernet (PoE) is also possible. The sensor 2a-f can be powered via an external power supply 8 if the power supplied via the network-based protocol 10 is insufficient or cannot be supplied at all, for example, when the protocol 10 is implemented as a wireless protocol. This is in Fig. 1 is the case with sensor 2b and is indicated symbolically.

[0051] Fig. Figure 2 shows one configuration. The sensors 2a, 2b, 2c are located in an Ex area 9, as is the intermediate unit 5, which is configured as a switch 6.

[0052] The terms "Ex-capable" or "Ex-zone 9" refer to intrinsic safety, a technical property of a device or system that, due to specific design principles, ensures that even in the event of a fault, no unsafe condition arises. This can be achieved through predetermined breaking points, special power sources, or other measures, thus preventing a hazardous situation from occurring. A fault describes situations for which a risk exists. For example, the possibility of sparking when closing an electrical circuit is only a risk within potentially explosive atmospheres. Intrinsic safety is a key requirement of the global process industry, which demands an easy-to-implement solution for the control and power supply of field devices in potentially explosive atmospheres.

[0053] The intermediate unit 5 / 6 from the hazardous area 9 is connected to another intermediate unit 5 in the non-hazardous area via the network-based protocol 10. The network-based protocol 10 is also hazardous area-compatible. The intermediate unit 5 in the non-hazardous area is configured as a switch 6 and gateway. This intermediate unit 5 thus acts as an intermediary between the network-based protocol 10 and connected units 3 (for example, a higher-level unit) and another operator panel 7 (optional operator panel in the non-hazardous area), which are connected here via Ethernet 10 (classic, but also possible as APL or SPE).

[0054] Fig. Figure 3 shows one configuration. Here, three sensors 2a, 2b, 2c and 2d, 2e, 2f are located in the hazardous area 9 and the non-hazardous area, respectively, and are each connected via the network-based protocol 10 to an intermediate unit 5, which is configured here as a switch 6. An operator panel 7 is optionally connected to the switch 6 in the hazardous area 9. The switch 6 in the hazardous area 9 is connected to the switch 6 in the non-hazardous area. An additional operator panel 7 is optionally connected to the switch in the hazardous area 9. The further cabling and protocol at the switch 6 in the non-hazardous area are configured as shown above, i.e., via Ethernet 10 to the operator panel 7 and via a non-network-based protocol 11 to the higher-level unit 3. However, a network-based protocol 10 is also possible here.

[0055] In the above-described configurations of a measurement system 1 with a large number of different sensors 2a-f in the Ex and non-Ex area, rapid interchangeability must be ensured for each sensor, including measurement point-specific and network-specific characteristics such as configuration and parameters.

[0056] In summary, the solution to the above-mentioned task consists of providing a network service which, by advantageously utilizing the properties of the Ethernet network topology used, automatically and uniquely identifies, assigns and configures the connected field devices in a universally valid way by controlling the "managed switches".

[0057] The following describes how the claimed method makes it possible to exchange a first sensor with a second sensor and to perform the same measurement tasks with little or no delay and minimal effort.

[0058] When replacing the old sensor ("first sensor") with a new sensor ("second sensor"), the following functions must be fulfilled: ▪ ▪ Detection of the specific location (network connection, i.e., the network address (IP address, "IP")) of the connected sensors ▪ Identification of the sensor, in particular the exact type of sensor connected to a network port, i.e. information about the type of sensor and which manufacturer, possibly with the serial number and firmware version. ▪ Storage of the configuration, in particular the entire configuration, of the sensor connected to a network port ▪ If applicable, storage of any certificates of the sensor connected to a network connection ▪ Retain the network address of the old sensor even with the new sensor ▪ Automatic configuration of the new sensor

[0059] In one configuration, the sensor's settings are continuously and historically stored.

[0060] These tasks are performed by an additional control service located on the same network, which uses the management functions of the participating managed switches to detect changes in network participants and initiate the necessary actions. This control service is referred to below as the "Field Device Configuration Controller" (FDCC). From this point forward, it will simply be called the "FDCC".

[0061] The FDCC can be part of the control system 12. It can also be part of a switch 6 or edge device, or a separate component with its own microcontroller and memory. Generally, the FDCC is part of the network.

[0062] For the processes to function correctly, the new device must, as mentioned, receive the same IP address as the old device. As previously explained, this is not possible with a conventional DHCP server. However, the FDCC works closely with and controls the DHCP server. In one configuration, the FDCC completely takes over the tasks of the DHCP server. A separate DHCP server then no longer exists. This is advantageous because it avoids a complex relationship between the FDCC and potentially several different DHCP server implementations. This is possible because the network used to operate the sensors is merely a subnet of limited size, within which a dedicated DHCP server, in the form of the FDCC, can handle the task of assigning IP addresses within this subnet.

[0063] The following process describes this configuration.

[0064] A DHCP server, or more specifically the FDCC, can send and receive various standardized messages, including the following: ▪ “DHCP Discover”: A client without an IP address sends a broadcast request for address offers to all DHCP servers in the local network. ▪ “DHCP Offer”: The DHCP servers respond with corresponding values ​​to a DHCP Discover request. ▪ “DHCP request”: The client requests one of the offered IP addresses, further data, and an extension of the lease time from one of the responding DHCP servers.

[0065] Fig. Figure 4 shows a measuring system with four sensors 2a-d, each connected to a port of a switch 6. The FDCC 12 is also connected to the switch 6. The FDCC 12 can also be part of the switch 6 ( Fig. 1 and Fig. 3). Fig. Figure 2 shows the design of the FDCC 12 as part of an operating panel 7.

[0066] Unlike the DHCP server, the FDCC has an SNMP control connection to all participating “managed switches 6”, however, for the sake of simplicity, the following description will be referred to in the singular.

[0067] SNMP stands for Simple Network Management Protocol, a network protocol used to monitor and control all network devices from a central station. The protocol governs communication between the monitored devices and the monitoring station. SNMP defines the structure of the data packets that can be sent and the communication flow. Among other things, SNMP handles tasks such as monitoring network components, remote control and configuration of network components, and fault detection and notification.

[0068] Initially, a data processing unit, such as a PC or an integrated microcontroller, with an installed FDCC 12, as well as the control system 3, are connected to a switch 6. The control system 3 receives an IP address from the FDCC 12 in its role as a DHCP server (or it has been statically assigned). No sensor is connected yet.

[0069] Now, for example, a sensor 2a is connected to port 1 ( Fig. 4) This will now request an IP address from a DHCP server on the network via broadcast using a “DHCP Discover” message including MAC address M.

[0070] The FDCC receives the "DHCP Discover" message, indicating that a new device has entered the network. This information is also available to the FDCC 12 via the SNMP control channel of Switch 6. The FDCC 12 uses Switch 6 to determine the exact port, i.e., its location within the network hierarchy (multiple cascaded switches may be involved), which is then reported by Sensor 2a. In essence, the sensor identifies which port on which switch within the network hierarchy the sensor is using. Therefore, the FDCC 12 also acts as a "network hierarchy monitor."

[0071] Before assigning an IP address, the FDCC 12 uses an "FDCC Type Request" message (e.g., via UDP packet; addressing is still done directly via the sensor's MAC address M and not via IP address) to determine the type of sensor. For example, it might be an APL-enabled pH sensor from manufacturer H, type T, with firmware version F and serial number S. The "FDCC Type Request" message is a query from the FDCC 12 to the sensor, specifying the type of sensor, such as manufacturer, type, firmware, or serial number. The general purpose is to uniquely identify the sensor. This is achieved, for example, with the manufacturer, type, firmware, and / or serial number information mentioned above.

[0072] Other possibilities are conceivable, such as a unique ID like the "Universally Unique Identifier" (UUID) or others.

[0073] Since the FDCC 12 does not yet know the target configuration for this measuring point at the respective port, it can now generate an IP address (e.g., 192.168.0.42) and communicate it to sensor 2a via a DHCP offer message. The FDCC 12 then stores in an associated or integrated database that a pH sensor with MAC address M and metadata H, T, F, and S, and the IP address 192.168.0.42, has been installed at the specific port "Port 1" of a particular switch in the network hierarchy. As mentioned, this is for sensor identification; this can also be done using another identifier, such as the UUID or others.

[0074] The sensor 2a can now be commissioned via the control system 3 using any Ethernet-based fieldbus protocol (e.g., PROFINET, OPC / UA, APL, SPE, etc.). The sensor 2a is then configured accordingly, i.e., the measurement parameters (measurement principle, measurement duration, measurement interval, measurement cycle, transmission cycle, etc.), network settings, and fieldbus settings are set.

[0075] In the next step, the entire sensor configuration is saved. The measurement parameters mentioned above, network settings, and fieldbus settings are part of this configuration. Similarly, for the purposes of this registration, any login data (username, generally an identifier, with password, certificate(s), and private keys) is also considered part of the "configuration." This corresponds to the "target configuration" at this measuring point. The configuration is saved in memory assigned to the FDCC, such as the memory of a microcontroller or switch, or in a corresponding database.

[0076] The steps described above are now repeated for all newly installed sensors in the measurement system. The target configuration is then saved for each sensor at its respective measuring point. Once all measuring points are configured, an overall target configuration is generated.

[0077] All communication to and from the FDCC is preferably encrypted so that the transmitted data cannot be intercepted or manipulated.

[0078] In one configuration (while the sensor is already operational), sensor 2a can send an "FDCC Configuration Update Notification" message to FDCC 12. This informs FDCC 12 that sensor 2a's configuration has changed. Alternatively, FDCC 12 can determine this through a cyclical query (e.g., by polling) of all known sensors. The changed configuration can then be saved as the new target configuration. The "FDCC Configuration Update Notification" message is a message from the sensor to FDCC, indicating that the configuration has changed and how. The complete configuration or just the changes can be sent.

[0079] When a field device's configuration is detected, the FDCC will contact it and load the new configuration via an "FDCC Configuration Read" message, storing it in the assigned memory or database. In one implementation, this is done along with a timestamp. The configuration is provided with a unique identifier of its overall state (e.g., a checksum or hash (e.g., MD5) of all configuration data). This identifier can be retrieved directly from the sensor, even without downloading the configuration.

[0080] The data transmitted via "FDCC Configuration Read" can include security-relevant data, particularly login credentials, private keys, and sensor certificates. If this data is transferred to the replacement sensor via "FDCC Configuration Write" (see below), the replacement sensor becomes indistinguishable to a higher-level communication system (such as a control center), even if that system uses an encrypted communication protocol and, for example, mTLS (mutual client / server authentication). This is especially true when the IP address is transferred and, in some configurations, the MAC address is also transferred.

[0081] It is important that communication takes place via a secure and encrypted communication channel, as is preferred for all communication. As mentioned, the FDCC also transmits security-relevant information via this communication channel: login data, the private key, and the certificate that the sensor uses to communicate with the control system. This information is also stored in the FDCC database.

[0082] If the sensor is subsequently reconfigured, the process is repeated. The FDCC saves a new data record containing a backup of the sensor configuration. The aforementioned hash of the configuration data is used to detect whether any changes have occurred in the sensor since the last configuration was saved.

[0083] If the sensor is now unplugged, the switch recognizes that there is no longer a field device on "Port 1", which the FDCC immediately learns via its SNMP connection.

[0084] The FDCC can now store the information about the connection interruption, including a timestamp, in its database for the data of the field device that was previously connected to "Port 1".

[0085] If the sensor is later reconnected, the FDCC can recognize it as the same sensor using the mechanisms described above, since the H, T, F, and S values ​​are identical (or the sensor is uniquely identified by other means, see above). The configuration hash can also be used to determine whether the sensor still contains the last known configuration. If there is a discrepancy, the FDCC can write the configuration to the sensor using an "FDCC Configuration Write" message. This automatic process can be enabled or disabled globally or selectively for each field device by the system operator. The "FDCC Configuration Write" message is a message that writes the target configuration (or at least a configuration different from the sensor's current configuration) to the sensor and is sent by the FDCC to the sensor.The data written to the replacement sensor using "FDCC Configuration Write" makes the replacement sensor indistinguishable from the original sensor to a higher-level communication system (such as a control center).

[0086] If, however, a different, identical sensor is connected to "Port 1" instead of the original one, the FDCC detects the change. This occurs based on the changed MAC address (M) via the switch, as well as the DHCP Discover message that the sensor sends shortly after connection. The FDCC then determines the H, T, F, and S information, or identifies the sensor in another unique way, and can recognize that a different sensor of the same type is connected to the port. In this case, the FDCC can then decide that the new sensor should replace the original one (in one configuration, this behavior can be set by the operator).Before the DHCP offer message, the entire configuration of the old sensor (including login data, private key, certificate(s), and network-specific settings) is written to the new sensor via the "FDCC Configuration Write" message. Then, the same IP address as the old sensor is assigned to the new sensor via a DHCP offer message.

[0087] The new sensor becomes "visible" to the control system only from this point onward. However, since it has the same IP address, possibly the same certificate(s), possibly the same MAC address (see below), and the same configuration as the old sensor, the control system will not be able to detect any difference. The control system will therefore communicate with the sensor immediately and without interruption. In one configuration, the field device (the sensor) now generates a diagnostic message in its diagnostic system, so that the device change is also detectable at the control system level for the operator's diagnostic purposes.

[0088] Through the described process, a sensor's IP address is no longer primarily linked to its MAC address, but rather to the respective measuring point—and thus the physical network connection. In one implementation, the MAC address of a replacement sensor is also changed by the FDCC to the MAC address of the replaced sensor. This results in the indistinguishability of the replaced sensor from the one being replaced at the network communication level. By restoring the device configuration and, optionally, the (private) security features (such as login data, private key(s), and certificate(s)) of the replaced sensor, the indistinguishability of the replaced and replacement sensors is subsequently achieved at the application level as well.

[0089] Ideally, the replacement device (“second sensor”) is either a completely new device or the device has been reset to factory settings (complete reset or “Resef”), thus acting as a new device.

[0090] As mentioned above, in one implementation, the MAC address of the second sensor is replaced with the MAC address of the first sensor. MAC addresses are essentially unique, but replacing a first sensor with a second one-to-one poses no problem: during the exchange, a MAC address is used that has already been assigned to a device of the same type. In this implementation, the MAC address is selected from a pool of addresses.

[0091] The only time a problem can arise is if a user reconnects a device that was previously disconnected from the network without taking any further steps (such as a complete reset, see above), and the one-to-one exchange described above has already taken place, as two "identical" devices are now connected. However, this can be resolved as follows: using the "managed switched" network, the FDCC can ensure that subsequently added devices with identical MAC addresses are rejected, i.e., the corresponding new device is blocked (the switch port is deactivated) to prevent a network collision.

[0092] In one implementation, a counter is used for each device, which is incremented with every replacement. The FDCC manages the counter value. The counter value is stored in the device itself and in the network, preferably in the FDCC. Thus, when a device is replaced by another, the counter is incremented and stored in both the device and the FDCC. If the previously used device reappears at the connection of the current device (for example, after a repair), the FDCC can compare its stored counter value with the counter value stored in the device to determine whether the connected device is an older device and must first be overwritten with configuration data for correct operation. The counter is also incremented during this process, which again designates the previous device as an older device, ensuring that only one device can always maintain the guaranteed current configuration.

[0093] This process therefore makes it possible to replace a sensor in a directly Ethernet-enabled sensor system without requiring reconfiguration and separate commissioning during the changeover.

[0094] In the event that a field device of the same type T, but with a different firmware version F or device variant H (or manufacturer), is connected to "Port 1", rules may be stored in the FDCC that transform the configuration data into the respective data model of this exchange device.

[0095] In the event that a completely different type of field device is connected to "Port 1", a decision can be made (configurable by the operator) as to whether the field device should be rejected or actually put into operation as a new device.

[0096] The claimed solution thus offers a method for exchanging a first sensor with a second sensor at the application level, independent of the communication protocol. With the proposed solution, it is therefore possible, using the FDCC, to equip any Ethernet protocol with the device-swapping functionality described here, without these protocols needing to be aware of this or require any extensions.

[0097] The system, independent of any specific communication protocol, allows the restoration of a sensor's entire configuration, extending beyond the configuration options of a single communication system. For example, the PROFINET configuration might only reflect subsets of the overall configuration, such as those accessible via the web server also provided by the sensor.

[0098] The aforementioned data backup, particularly differential data backup with a historical history, is one implementation. In this configuration, the measuring system can mark a specific configuration (of the respective sensor) as a "reference" so that it is preferentially written to the device in the event of a device replacement. The preferred configuration is not necessarily the most recent one, but a specific one. Furthermore, the data history can be used to visualize a comparison of configuration changes over time. However, the ability to revert to a previous state is particularly advantageous if a misconfiguration of the field device prevents correct operation.The protocol-independent method, meaning it is independent of the fieldbus protocol used, allows for the creation of a backup of the entire system (not just the configuration elements addressable by a specific fieldbus protocol in the sensor), essentially a digital image of the current system. This can also be done differentially. Preferably, this backup is performed historically (i.e., over time), so that it is possible to restore not only to the last known state but to any point in time. The backup includes all security-relevant information such as access data and private keys. A "clone" of the system can also be created and installed in a similar or identical system, for example, when constructing a new factory.

[0099] This results in an "FDCC service" which, for example, performs the following functions: ▪ Network hierarchy monitor ▪ DHCP server ▪ Field device identifier ▪ Field device backup service ▪ Field Device Configurator

[0100] The FDCC enables the operator to perform the usual and necessary maintenance and replacement processes for maintenance-intensive sensors used in analytical measurement technology in a way that is advantageous for the user. The FDCC eliminates the need for manual intervention and thus minimizes installation downtime. This is achieved through a beneficial combination of network hierarchy monitoring and restoration of field device identity and configuration, depending on the location and type of the field devices involved. List of reference symbols 1 measuring system 2a-f Sensor 3. Higher-level unit 4 Control unit 5 intermediate unit 6 Switch 7 Control panel 8 external energy supply 9 Ex-area 10 network-based protocol 11. Non-network-based protocol 12 FDCC

Claims

[1] Method for exchanging a first sensor with a second sensor at a measuring point in a network-based measuring system, comprising the following steps, wherein steps a) to g) are carried out once when the first sensor is put into operation: a) Connecting the first sensor to the network-based measuring system; b) Request a network address from the first sensor; c) detecting the specific location of the first sensor; d) identifying the first sensor; e) Assigning a network address to the first sensor; f) Configuring the first sensor; g) storing the configuration of the first sensor, in particular with checksum and / or hash; h) replacing the first sensor with the second sensor; i) Requesting a network address from the second sensor; j) detecting the specific location of the second sensor; k) identifying the second sensor; I) Sending the stored configuration of the first sensor to the second sensor if the second sensor is to replace the first sensor; or sending the stored configuration of the first sensor to the second sensor if the second sensor is the same as the first sensor and the current configuration of the second sensor differs from the stored configuration of the first sensor; and m) Assign the original network address of the first sensor to the second sensor. [2] Method according to claim 1, wherein the identification of the sensor (2a-f) is the type of sensor, in particular information about the type (T), manufacturer (H), firmware version (F) and / or serial number (S), or by means of a unique identifier, in particular a universally unique identifier. [3] Method according to claim 1 or 2, wherein the configuration of the sensor comprises parameters and settings, in particular with regard to the measuring principle, measuring duration, measuring interval, measuring cycle, transmission cycle, settings with regard to the network and settings with regard to the fieldbus, among others. [4] Method according to one of the preceding claims, wherein private data, in particular login data, private key(s) and certificate(s), of the first sensor are stored as part of the configuration. [5] Method according to one of the preceding claims, wherein a counter is incremented for each sensor when the sensor is used as a “second sensor”, i.e. as a replacement sensor. [6] Method according to the preceding claim, wherein the counter is stored in the sensor and in the network-based measuring system, wherein a comparison of the stored counter reading in the network-based measuring system and the counter reading stored in the sensor is used to determine whether the connected device is an old device and must first be overwritten with configuration data in order to function correctly. [7] Method according to one of claims 1 to 6, wherein the second sensor is a new sensor or a sensor with factory settings. [8] Method according to one of claims 1 to 6, wherein the second sensor is any sensor, wherein the counter reading is used to detect whether the sensor needs to be overwritten with configuration data. [9] Method according to one of the preceding claims, wherein the MAC address of the second sensor is replaced with the MAC address of the first sensor. [10] Method according to one of the preceding claims, wherein in step g) “saving the configuration of the first sensor” this configuration is saved as a target configuration and after a sensor replacement the target configuration is loaded into the second sensor. [11] Method according to one of the preceding claims, wherein the sensor sends a change in its configuration and, if necessary, the target configuration is updated. [12] Method according to one of the preceding claims, wherein the sensor is queried for a change in the configuration, in particular cyclically, and if necessary the target configuration is updated. [13] Method according to one of the preceding claims, wherein the configuration is continuously and historically saved. [14] Method according to the preceding claim, wherein a differential data backup is performed. [15] A computer program product comprising program instructions which, when executed on a computer device, cause the computer device to carry out a method according to any one of the preceding claims. [16] Network device (3, 4, 6, 7) comprising means for implementing a method according to any one of the preceding claims. [17] Measuring system (1) comprising at least a first sensor (2a-f), a second sensor (2a-f) and a network device (3, 4, 6, 7) according to the previous claim with a control service (12) which is designed to carry out a method according to one of the previous claims.

Images