Firmware updates for modular node components

Abstract

The present invention relates to a method for changing, in particular for updating, the firmware of a front-end station of a modular node, the method comprising the transmission of a compatibility check routine stored in the front-end station, the transmission of the compatibility check routine from the front-end station to a computer connected to the front-end station, wherein a first firmware is non-volatilely stored in the front-end station, the method further comprising a check, performed when the check routine executed in the computer is applied, of whether a second firmware is compatible with the front-end station, when the check indicates that the second firmware is compatible with the front-end station, the method further comprising replacing the first firmware in the front-end station by the second firmware, the present invention further relating to a front-end station configured accordingly.

Description

Technical Field

[0001] The present invention relates to a modular node, and in particular to a front-end station of a modular node, wherein the node has one or more input / output modules (I / O modules) connected in series to the front-end station and / or is configured as a field bus node. Background Art

[0002] If the manufacturer of the system components provides a firmware update, it must be transferred to the individual components of the system so that the previously used firmware can be replaced there. Here, it must be ensured that the new firmware is compatible with the operating environment and in particular with the respective components.

[0003] In this regard, document EP1688840B1 proposes that the front-end station extracts compatibility information from the firmware data transmitted to the front-end station and compares the firmware data with the working environment. If incompatibility is confirmed, the front-end station will refuse to execute the update and send back a corresponding error report. Summary of the invention

[0004] The object of the present invention is to improve the prior art.

[0005] The method according to the present invention includes the transmission of a compatibility check routine stored in a front-end station, the transmission of the compatibility check routine from the front-end station to a computer connected to the front-end station, the first firmware being stored non-volatilely in the front-end station, the method also including a check on whether the second firmware is compatible with the front-end station when the check routine implemented in the computer is applied, and, when the check indicates that the second firmware is compatible with the front-end station, replacing the first firmware in the front-end station with the second firmware.

[0006] The compatibility of the firmware is therefore not checked in the head end station but in the computer, and it is nevertheless ensured that the check is carried out by a routine provided for this purpose.

[0007] Here, the term "front-end station" as used in the present description and the claims refers to a component of a modular node, whose task is to make data and / or services of input / output modules connected in series to the front-end station available (for example, via a field bus connected to the front-end station). In addition, the term "transmission" as used in the present description and the claims refers in particular to the transmission of data from the front-end station (transmitter) to the computer (receiver) via a wired transmission path (for example, LAN) or a wireless transmission path (for example, WLAN) by means of electrical signals. The term "computer" as used in the present description and the claims refers in particular to a commercially available PC (desktop) or a commercially available mobile device (laptop, tablet, smartphone, etc.), the PC / mobile device having an interface for receiving data and a processor, the processor being configured to process instructions of a check routine and at least in the case of incompatibility, refusing replacement and / or indicating the incompatibility to the user.

[0008] Furthermore, the term "compatibility check routine" as used within the scope of the present description and claims refers in particular to an instruction sequence that can be implemented by a processor, which determines whether the second firmware is compatible with the hardware of the front-end station. For example, the "compatibility check routine" can ascertain whether the hardware configuration of the front-end station matches the hardware configuration determined as compatible by the second firmware. The "compatibility check routine" can furthermore check the compatibility of the second firmware with (the firmware of) a module connected in series to the front-end station. For example, the second firmware can include an updated protocol for operating a local bus (i.e., for operating a bus that connects the module to the front-end station). In order to thereby achieve interoperability of the front-end station with the module, the compatibility check routine can be used, if necessary, to introduce a coordinated update of the individual components, such as an update of the front-end station and the modules arranged in sequence simultaneously (or in a specific order).

[0009] In addition, the concept of "firmware" used in the present specification and claims refers in particular to a group of instruction sequences stored in the non-volatile memory of the front-end station (and, if necessary, the module). Although the execution of the instruction sequence by the user can be adapted to the usage scenario with the help of a parameter group, it cannot be changed by the user and can only be replaced with other instruction sequences. Here, the concept of "replacement" used in the present specification and claims refers in particular to partially or completely covering the instruction sequence group with other instruction sequences. In addition, the concept of "firmware" used in the present specification and claims refers in particular to an instruction sequence set according to the requirements of the hardware of the front-end station (and, if necessary, the module), that is, an instruction sequence whose execution directly (that is, without the need for the addition of software) changes the state of the hardware (of the front-end station or module).

[0010] Furthermore, the term “compatible” as used within the scope of the present description and the claims describes in particular firmware which can be run without errors and does not (significantly) restrict the scope of functions of the head station or the fieldbus node.

[0011] In addition, when a verification routine executed in the computer is applied, the method is capable of verifying whether the second firmware is compatible with all input / output modules connected in series to the front-end station, and sending a warning in the computer when the verification indicates that the second firmware is not compatible with all input / output modules connected in series to the front-end station.

[0012] For example, the warning may be used to indicate to a user that the firmware of one, more than one, or all of the input / output modules must be updated in order to be able to continue using the modular node.

[0013] Preferably, the modular node connected to the input / output module connects the field device to the field bus via a local bus controlled by a front end station.

[0014] Here, the term "local bus" as used in the present description and the claims refers in particular to a bus via which input / output modules (only) connected in series to a headend station are connected to each other and to the headend station (at the signaling level). Here, the term "field device" as used in the present description and the claims refers in particular to sensors and / or actuators connected to (e.g. connected to) an input / output module (at the signaling level).

[0015] Preferably, the replacement of the first firmware in the front-end station by the second firmware also includes the replacement of the verification routine.

[0016] For example, the new test routine may accept more or other firmware versions as compatible (compared to the replaced test routine), or take into account aspects of the test that were not taken into account by the replaced test routine.

[0017] Furthermore, the method can include a request for first data of the front-end station, in particular a serial number from which a hardware state of the front-end station can be derived, by a check routine executed in a computer, and a comparison of the first data with second data with respect to a second firmware, wherein the second data indicate with which hardware state the second firmware is compatible.

[0018] Furthermore, the method can include requesting third data from the front-end station by means of a check routine executed in the computer, with the aid of which the update program stored in the front-end station can be determined, and comparing the third data with fourth data, wherein the fourth data indicates which firmware can be installed by means of the update program stored in the front-end station.

[0019] Furthermore, when comparison of the third data with the fourth data indicates that the second firmware cannot be installed by the update program in the front end station, the method may have a feature of replacing the update program with the update program capable of installing the second firmware in the front end station.

[0020] For example, the replacement of the update program may be triggered by replacing the first firmware in the front-end station (eg, with the third firmware).

[0021] Preferably, the compatibility checking routine is executed in a browser of a computer. The compatibility checking routine (or a component of the compatibility checking routine) may be written, for example, in HTML and / or JavaScript.

[0022] According to the present invention, a front-end station may include, for example, an HTTP server, which is configured to transmit a compatibility check routine stored in the front-end station from the front-end station to a computer connected to the front-end station, wherein the first firmware is non-volatilely stored in the front-end station, and the HTTP server is also configured to trigger replacement of the first firmware by the second firmware in response to receiving data embodying the second firmware.

[0023] It goes without saying that the head-end station according to the invention can be configured to execute (the steps of) the method according to the invention and that the method according to the invention can be carried out using the head-end station according to the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The invention will be explained below in a detailed description of embodiments, with reference to the following drawings:

[0025] Figure 1 shows a fieldbus system;

[0026] Figure 2 showing a fieldbus node and a fieldbus device connected to the fieldbus node;

[0027] Figure 3 showing a fieldbus node and a computer connected to the fieldbus node; and

[0028] Figure 4 A flow chart showing a process for updating a headend station;

[0029] Figure 5 A flow chart showing a firmware upgrade triggered by a user.

[0030] Here, the same reference numerals are used for the same or functionally similar elements in the figures. DETAILED DESCRIPTION

[0031] Figure 1 The block diagram of the fieldbus system 10 is shown. The fieldbus system 10 comprises a superior control unit 20, and a plurality of modular fieldbus nodes 100 are connected to the superior control unit 20 via a fieldbus 30. The superior control unit 20 can be used for both monitoring and regulating devices (not shown in the figure) controlled by the fieldbus system 10. When the superior control unit 20 monitors a device, the superior control unit 20 can periodically or aperiodically receive status data from the fieldbus node 100, and when the state of the device (substantially) deviates from the expected / permitted state or state range, the status data describes the state of the device and generates an error signal or an alarm signal. When the superior control unit 20 (not only monitors, but also) regulates the device, the superior control unit 20 can periodically or aperiodically receive status data from the fieldbus node 100, and refer to the status data to determine the control data transmitted to the fieldbus node 100.

[0032] Figure 2 An exemplary modular fieldbus node 100 is shown, which comprises a front-end station 110 and two input / output modules 120, 130 connected in series to the front-end station 110, to which field devices 140, 150, 160, 170, such as sensors and actuators, are connected. During operation, the input / output modules 120, 130 read in sensor signals via inputs and generate status data from the sensor signals, which are transmitted to the front-end station 110 via a local bus 180. The front-end station 110 can process the status data locally and / or forward the status data (if necessary in a modified form) to a superordinate control unit 20. The superordinate control unit 20 (or the front-end station 110 in the case of local processing) can then generate control data with reference to the status data.

[0033] The control data generated by the superordinate control unit 20 can then be transmitted to the (same or) one (other) headend station 110 via the fieldbus 30. The control data transmitted to the headend station 110 (or generated by the headend station 110) are then forwarded / transmitted (if necessary in a modified form) to the input / output modules 120, 130. The input / output modules 120, 130 receive the control data and send control signals corresponding to the control data to the outputs to which the actuators are connected. In this case, the data communication between the components of the fieldbus system 10, the mapping of sensor signals to status data and the mapping of control data to control signals can be adapted to different usage scenarios by configuring the fieldbus node 100.

[0034] For this purpose, several or all components of the fieldbus system 10 are equipped with firmware that makes it possible to receive and store configuration data sets and to perform signal / data processing with reference to the configuration data sets. However, the possibilities for adaptation are therefore limited to changes that can be achieved by changing the configuration data sets, whereas changes beyond this limit require replacement of the firmware of the components of the fieldbus system 10. Such a replacement can, for example, serve to eliminate errors or generally improve the firmware, so that an update (upgrade) of the firmware accompanies the replacement. Of course, the reverse is also possible, i.e., the firmware is replaced by an earlier version, for example, because not all components of the fieldbus system 10 have newer versions available, and for example, components with newer firmware versions cannot (or only to a limited extent) operate together with components with non-updated versions.

[0035] like Figure 3 As shown, the replacement of the firmware of the front-end station 110 includes a computer 40 connected to the front-end station 110. Here, the computer 40 connected to the front-end station 110 can be a computer 40 that is (temporarily) connected to the front-end station 110 (e.g., via a TCP connection) specifically for the update, or a computer 40 that is (continuously) part of the fieldbus system 10, such as the superordinate control unit 20. In order to execute the replacement routine, the computer 40 can establish a connection with the front-end station 110 and request a compatibility check routine stored in the front-end station 110. Figure 4 As shown, in response to the query in step 200 , the front-end station 110 can transmit a compatibility check routine to the computer 40 connected to the front-end station 110 .

[0036] like Figure 5 As shown, the computer 40 may be equipped with a browser, and the user of the computer 40 can navigate to the IP address of the front-end station 110 by means of the browser, wherein the HTTP server of the front-end station 110 can transmit the data stored for upgrading the firmware (e.g., data in the form of HTML and / or JavaScript). The aforementioned data can be interpreted and executed in the browser of the front-end station 110, thereby providing a user interface to the user, and the user can control the update of the firmware by means of the user interface. Here, when the input / output modules 120, 130 also have firmware that can be updated by the front-end station 110, the user can select the device to be updated (i.e., the front-end station 110 and / or one or more input / output modules 120, 130 connected in series to the front-end station) and distribute the firmware data to each selected device (the firmware data is provided by the manufacturer of each device and downloaded to the computer 40 via the Internet, for example).

[0037] Conversely, when the input / output modules 120, 130 do not have firmware or have firmware that cannot be updated by the front-end station 110, it can also be provided that the user only needs to select a firmware data (the one firmware data is then automatically assigned to the front-end station 110 due to lack of alternative selections). After extracting information about the firmware version from the assigned firmware data and analyzing the data stored in the front-end station 110, including information about the hardware of the front-end station 110 and / or information about the hardware of the input / output modules 120, 130, the inspection routine (e.g., JavaScript program) executed in the browser can be based on Figure 4 Step 210 checks whether the firmware version is compatible with the hardware version of the front-end station 110, or whether it is compatible with the hardware of the input / output modules 120, 130. For example, the data stored in the front-end station 110 may include one or more serial numbers, from which the hardware status of the front-end station 110 and / or the input / output modules 120, 130 can be derived.

[0038] When the verification indicates that the firmware is compatible with the front-end station 110, Figure 4 As shown in step 220 in the embodiment, the firmware in the front-end station 110 is replaced by another firmware. Here, when the inspection shows that the firmware and the hardware are compatible with each other, it is possible to Figure 5 As shown, the firmware upgrade is triggered by the user. If the user triggers the firmware upgrade, the firmware data is transmitted from the computer 40 to the front-end station 110 and the firmware data is installed by the update program at the front-end station 110. The replacement of the firmware by the second firmware in the front-end station may also include the replacement of the inspection routine. That is, when replacing the firmware, the data stored in the front-end station 110, which has been transmitted to the computer 40 and executed in the browser of the computer 40, can be overwritten.

[0039] Likewise, the update program stored in the front-end station 110 may be replaced when the firmware is upgraded. Thus, the firmware update can be completed step by step, for example, in two (or more) stages. For example, it may happen that the target firmware is compatible but cannot be processed by the current firmware or the current update program stored in the front-end station 110. In this case, one or more firmware updates may have to be performed until the target firmware can be installed. It may also happen that the target firmware is compatible but cannot be processed by the inspection routine currently stored in the front-end station 110. In this case, one or more firmware updates may also have to be performed until the target firmware is released by the inspection routine.

[0040] Reference numerals list

[0041] 10 Fieldbus systems

[0042] 20 Control unit

[0043] 30 Fieldbus

[0044] 40 Computer

[0045] 100 (fieldbus) nodes

[0046] 110 Front-end Station

[0047] 120 Input / Output Modules

[0048] 130 Input / Output Module

[0049] 140 Field equipment

[0050] 150 Field devices

[0051] 160 Field equipment

[0052] 170 Field equipment

[0053] 180 Local Bus

[0054] 200 process steps

[0055] 210 Process Steps

[0056] 220 Process Steps

Claims

1. A method for updating the firmware of a front-end station (110) of a modular node (100), the method comprising: Transmitting a compatibility check routine stored in a front-end station (110), wherein the compatibility check routine is transmitted from the front-end station (110) to a computer (40) connected to the front-end station (110), wherein the first firmware is non-volatilely stored in the front-end station (110); testing whether the second firmware is compatible with the front end station (110) using a testing routine executed in the computer (40); as well as When the checking indicates that the second firmware is compatible with the front end station (110), the first firmware in the front end station (110) is replaced by the second firmware.

2. The method according to claim 1, wherein: The modular node (100) has one or more input / output modules (120, 130), namely I / O modules, which are serially connected to a front-end station (110) and / or is configured as a field bus node.

3. The method of claim 2, wherein the second firmware is checked to see if it is compatible with all input / output modules (120, 130) serially connected to the front-end station (110) using a check routine executed in the computer (40); and When the check shows that the second firmware is not compatible with all the input / output modules (120, 130) serially connected to the front-end station (110), a warning is sent on the computer (40).

4. The method according to claim 2, wherein: The modular node (100) connects field devices (140, 150, 160, 170) connected to input / output modules (120, 130) to a field bus (30) by means of a local bus (180) controlled by a front-end station (110).

5. The method according to claim 3, wherein: The modular node (100) connects field devices (140, 150, 160, 170) connected to input / output modules (120, 130) to a field bus (30) by means of a local bus (180) controlled by a front-end station (110).

6. The method according to any one of claims 1 to 5, wherein: The replacement of the first firmware in the front-end station (110) by the second firmware also includes the replacement of the inspection routine.

7. The method according to any one of claims 1 to 5, further comprising: By requesting first data of the front-end station (110) through a test routine executed in the computer (40), the hardware status of the front-end station (110) can be derived from the first data; and The first data is compared with the second data with respect to the second firmware, wherein, The second data indicates with which hardware state the second firmware is compatible.

8. The method according to any one of claims 1 to 5, further comprising: By means of a check routine executed in the computer (40), third data are requested from the front-end station (110), by means of which the update program stored in the front-end station (110) can be determined; and Compare the third data with the fourth data, wherein, The fourth data indicates which firmware can be installed by the update program stored in the front-end station (110).

9. The method according to claim 8, further comprising: When the comparison of the third data and the fourth data indicates that the second firmware cannot be installed by the update program in the front end station (110), the update program is replaced by an update program capable of installing the second firmware in the front end station (110).

10. The method according to claim 9, wherein: The replacement of the update program is triggered by replacing the first firmware in the front-end station (110) with the third firmware.

11. The method according to any one of claims 1 to 5, wherein: The compatibility check routine is implemented in a browser of the computer (40).

12. The method according to claim 11, wherein: The compatibility checking routine is written in HTML or JavaScript.

13. The method according to claim 7, wherein: The first data is a serial number.

14. A front-end station (110) having an HTTP server, wherein the HTTP server is configured to transmit a compatibility check routine stored in the front-end station (110) from the front-end station (110) to a computer (40) connected to the front-end station (110), wherein a first firmware is non-volatilely stored in the front-end station (110), the check routine is executed in the computer (40) and is used to check whether a second firmware is compatible with the front-end station (110), and when the check indicates that the second firmware is compatible with the front-end station (110), the first firmware is replaced by the second firmware, and the HTTP server is also configured to trigger the replacement of the first firmware by the second firmware in response to receiving data embodying the second firmware.

Images