EP3326101B1 - Method and system for firmware-updating a control device for process control - Google Patents

Description

description

The invention relates generally to automation technology, and in particular to a method and a system for updating the firmware of a control device for process control.

In automation technology, control devices are used to control machines and systems, which are connected to the respective machine or system via sensors and actuators, whereby the sensors and actuators are usually connected to inputs and outputs of the control device via I / O modules . Today the control devices are usually designed as programmable logic controllers (PLC) which can be programmed with a control application that can be executed by a microprocessor of the control device.

In particular, to control safety-relevant processes, that is to say of operations that pose a risk to man or machine, safety controls are used which must meet specified safety requirements. A firmware update in the form of an update may be required to correct errors or to expand the functions of a safety controller. The firmware typically includes operating software for the control device, as well as software, also referred to as a loader, for loading the operating software, and can also include an operating program for a programmable IC, such as an FPGA (Field-Programmable Gate Array), which forms the microprocessor for executing the control application. In order to meet the safety requirements placed on a safety controller, such a firmware update cannot be carried out by the user without further ado. A firmware update can be carried out by the device manufacturer in compliance with the safety requirements, which, however, is associated with a high level of logistics and costs, especially in the case of control devices that are already installed in the field.

Out EP 1 532 494 B1 a method for uploading a new operating program to a safety controller is known, with a download and release device integrated in the safety controller for accepting a new operating program, and with the integrated release device allowing or preventing the acceptance of the new operating program as a function of release information. US patent application US2008 / 052698 is further state of the art.

The invention is based on the object of showing a way in which a method for updating the firmware of a control device, in particular a safety controller, can be simplified and / or improved.

A core concept of the invention consists in providing a device-specific authorization check for the implementation of a firmware update by the manufacturer and, if the authorization check is successful, provide a device-specific activation code to carry out the firmware update, for which purpose a release device is provided by the manufacturer and an update device that can be connected to a control device is provided by the user.

In this way, firmware updates can advantageously be carried out under the complete control of the manufacturer, the logistical and cost outlay required for this being able to be considerably reduced, and in addition, firmware updates that have been carried out can be traced for each device. In particular, a secure firmware update under control and long-term archiving by the manufacturer can be made possible.

The technical problem mentioned above is achieved on the one hand by the features of claim 1.

According to this, a method for updating the firmware of a control device for process control with at least one control module is provided, wherein the control module is assigned a firmware stored in a system memory of the control device. According to the method, a firmware file with new firmware contained therein for the at least one control module is first provided in an update device that can be connected to the control device. This can be done in any suitable manner, for example by loading from a data carrier or by Internet downloading from a website of the manufacturer of the control device. The control device is designed in particular as a safety control for fail-safe control of a safety-critical process.

The method also provides that the update device retrieves first device data from the control device, which is stored in the control device, generates a signed device file as a function of this first device data and as a function of information identifying the new firmware, and generates the signed device -Transfer file to a central release facility. This can take place, for example, in response to a user input entered at the update device, with the user input optionally also being able to select the firmware to be newly installed. To generate the signed device file, a digital signature can be generated in a manner known per se with the aid of a secret signature key, which enables the central release device to check the integrity of the signed device file by means of an associated verification key. In the simplest case, the signed device file includes the first device data and the information that identifies the new firmware, as well as a digital signature generated for this data.

The signed device file received is checked by the central release device and an activation code is generated and transmitted back to the update device only if the check is successful, the activation code being second device data and a unique one Includes identification information. The unique identification information can advantageously be provided as a GUID (Globally Unique Identifier) and is used to track firmware updates that have been carried out.

After receiving the activation code, the update device carries out a consistency check of the first device data, as a function of which the signed device file was generated, and of the second device data contained in the received activation code. Alternatively, the method can provide for a renewed retrieval of the first device data stored in the control device by the update device, in which case the update device performs a consistency check of the newly retrieved first device data and the second device data contained in the received activation code.

The communication between the update device and the central release device can preferably take place via a direct communication connection, for example a wired Internet connection. However, the data can also be transmitted between the update device and the central release device in any other suitable manner, for example by e-mail data exchange or via a radio network. In principle, data exchange using a separate data carrier would also be conceivable.

A renewed retrieval of the first device data can in particular be advantageously provided if the data exchange takes place offline, ie not by means of an existing communication connection, since in In this case, the first device data may have changed since the previous retrieval.

Only if the consistency check is successful does the update device update the firmware of the control device with the new firmware. To carry out the firmware update of the control device, the method advantageously provides that the update device first transmits the new firmware as a firmware file to the control device and then transmits a device-specific update command to the control device to initiate the update, the control device in response to the received update command, the firmware of the control module stored in the system memory is automatically updated with the firmware contained in the received firmware file, the firmware stored in the system memory preferably being overwritten with the new firmware. For this purpose, the firmware file transmitted by the update device can initially be temporarily stored, with the intermediate storage being able to take place, for example, in a parameterization memory of the control device. The system memory and / or the parameterization memory are preferably designed as overwritable memory, for example as a flash memory or as an EEPROM.

The use of a device-specific update command advantageously achieves additional clone protection, ie the update process is not Can be freely transferred to other controls without logging by the manufacturer.

The firmware file advantageously also includes security information, the control device executing a consistency check of the security information and only allowing the firmware update to proceed if the consistency check is successful. The security information can in particular include a check value, for example in the form of a CRC value (CRC: Cyclic Redundancy Check), with the aid of which errors that have occurred during the storage or transmission of the firmware file can be recognized.

In an advantageous embodiment, the control device can have several, i. at least two control modules. A separate firmware can advantageously be provided for each of the control modules. Accordingly, the firmware file can include a new firmware for each of the at least two control modules. Provision can also be made for the firmware of the at least two control modules to be updated separately, the firmware file in this case only comprising new firmware for one of the at least two control modules.

The unique identification information contained in the activation code is particularly advantageously transmitted from the update device to the control device and stored in the control device. In this way, firmware updates carried out on the control device can advantageously be traced.

The central release device particularly advantageously checks for update authorization, with release information being retrieved from a product lifecycle management database in particular as a function of the device-specific information contained in the received signed device file.

For this purpose, significant stored data or features are retrieved from the product lifecycle management database and checked against the signed device file received, taking into account device-specific features such as device type, hardware production status and / or the last available firmware version.

In order to be able to carry out the check for update authorization by the central release device and in order to be able to carry out the consistency check of the first and second device data by the update device, the first and / or second device data preferably include a device type, a hardware version and / or a serial number of the control device and / or information on at least one firmware currently being executed by the control device.

The consistency check of the first and second device data includes in particular a comparison of the data contained in each case, in particular device-specific information such as the serial number, in order to check whether the received activation code was created for the control device for which a firmware update is to be carried out.

In order to enable the manufacturer to fully track firmware updates that have been carried out successfully, it is particularly advantageous for the update device to transmit a confirmation message to the central release device when the firmware update has been carried out successfully, with the central release device in response the successful implementation of the firmware update is logged on the received confirmation message, wherein in particular a log entry comprising the unique identification information is stored in the product lifecycle management database. A history of the firmware updates that have taken place can also advantageously be created for verification purposes in the sense of a required life cycle management.

To apply the firmware update, the control device must be restarted. The confirmation message is correspondingly transmitted from the update device to the central release device after a restart has taken place.

When the control device is restarted, a self-test of the control device is preferably carried out. Such a self-test is also known as a POST (Power-On Self-Test). The steps typically performed in a POST are known per se and are therefore not explained in more detail here.

If the control device comprises several control modules, it is advantageously provided that the control device, after updating the firmware of the at least one control module stored in the system memory, performs a compatibility test of the firmware assigned to the different control modules, the control device changing to a safe operating state upon detection of an incompatibility. This check can be provided as part of the POST, the control device changing to a safe operating state even if another error or another incompatibility is detected.

To increase security, the method can advantageously provide for error-proof and / or encrypted data transmission. This relates to the transfer of the signed device file from the update device to the central release device, the transfer of the activation code from the central release device to the update device, the transfer of the device-specific update command from the update device the control device and / or the transmission of the unique identification information contained in the activation code from the update device to the control device.

The technical problem mentioned above is also achieved by a system according to claim 12.

A system according to the invention for updating the firmware of a control device accordingly comprises a control device for process control with at least one Control module, wherein firmware stored in a system memory of the control device is assigned to the control module, an update device that can be connected to the control device, and a central enabling device, the update device being designed to transfer first device data stored in the control device from the control device to generate a signed device file as a function of the first device data and as a function of information identifying new firmware, to transmit the signed device file to the central release device, from the central release device in response to the signed one sent Device file to receive an activation code, a consistency check of the first device data, depending on which the signed device file was generated, and the second device data contained in the received activation code or the first device stored in the control device to retrieve the data from the control device again and to carry out a consistency check of the newly retrieved first device data and of the second device data contained in the received activation code, and if the consistency check is successful, to update the firmware of the control device with the new firmware, and the release device is designed to to check a signed device file received by the update device, to generate an activation code if the check is successful, which includes second device data and unique identification information, and to transmit the activation code to the update device in response to the received signed device file .

An essential aspect of the invention can be seen in the fact that a corresponding traceability of firmware updates carried out is made possible both by the manufacturer and on the respective control device.

For this purpose, the control device is advantageously designed to store the unique identification information contained in the activation code received from the update device. Furthermore, the update device is advantageously designed to transmit a confirmation message to the central release device when the firmware update has been carried out successfully, and the central release device is advantageously designed to successfully execute the firmware in response to the received confirmation message -To log updates, in particular a log entry comprising the unique identification information being stored in a product lifecycle management database.

The functionality of the update device is preferably the responsibility of the device manufacturer. The device manufacturer can particularly advantageously provide software, also referred to below as a download tool, which the user can install on a conventional computer which has a communication interface for communication with a control device in order to form the update device.

The above-mentioned technical problem is accordingly also achieved by a digital storage medium according to claim 14.

According to this, a digital storage medium is provided with instructions stored thereon, which are designed to carry out method steps when they are carried out on a computer, comprising: a) calling up first device data stored in a control device connected to the computer, b) generating a signed device File as a function of the first device data and as a function of information which identifies a newly provided firmware, c) transferring the signed device file to a central release device, d) receiving an activation code from the central release device in response to the sent signed device file, the activation code comprising second device data and unique identification information, e) performing a consistency check of the first device data retrieved in step a) and the second device data contained in the activation code received, or retrieving the data in the control again device stored first device data and performing a consistency check of the retrieved first device data and the second device data contained in the received activation code, and f) effecting, only if the consistency check is successful, an update of the firmware of the control device with the new firmware.

Fig. 1

eine schematische Darstellung einer bevorzugten Ausführungsform eines Systems zur Firmware-Aktualisierung,

Fig. 2

ein schematisches Ablaufdiagramm einer ersten Phase einer Firmware-Aktualisierung, und

Fig. 3

ein schematisches Ablaufdiagramm einer zweiten Phase einer Firmware-Aktualisierung.

The invention is described below by way of example using preferred embodiments and with reference to accompanying drawings. The same reference symbols denote the same or similar parts in the drawings. Show it:

Fig. 1

a schematic representation of a preferred embodiment of a system for firmware update,

Fig. 2

a schematic flow diagram of a first phase of a firmware update, and

Fig. 3

a schematic flow diagram of a second phase of a firmware update.

In Fig. 1 is an exemplary system 10 for updating the firmware of a control device 100 designed as a safety controller, which is used, for example, in automation technology. In the exemplary embodiment shown, the control device 100 is connected via an interface 141 to a communication network 300 and via this to process devices 210 and 220. The communication network 300 can be designed, for example, as a PROFINET communication network. PROFINET (Process Field Network) is an open Industrial Ethernet standard used in the field of automation. However, any other suitable communication network, such as a fieldbus, can also be used.

In the exemplary embodiment shown, the control device 100 comprises a control unit 110 with two control modules 112 and 114. Furthermore, the control 100 comprises an internal system memory 120 connected to the control unit 110, but not externally can be accessed. The firmware is stored here, for example, in the form of a composite file, a so-called container file, which is unpacked and put into operation when the system is started. Furthermore, a parameterization memory 130 is provided in the controller 100 which contains the configuration of the controller, the application program and, if necessary, further application-specific data. A firmware update is possible, for example, in that a new firmware container is stored in the parameterization memory via the communication interface 142 of the controller 100 and then a command to the controller 100 starts a procedure which puts the new firmware into operation with this container.

In the exemplary embodiment shown, the control device 100 can be connected for this purpose via a communication link 310 to a computer 400 on which a software tool provided by the manufacturer of the control device 100, hereinafter referred to as a download tool and in Fig. 1 referred to as DLT for short, is installed.

The interface 142 can be designed, for example, as a USB interface or as an Ethernet interface.

The computer 400 is preferably connected to a manufacturer server 500 via the Internet 320, the manufacturer server 500 comprising a central release device. A data transfer between the download tool and the central release facility can take place via the Internet can also be done in other ways. In the exemplary embodiment shown, the manufacturer server 500 is also connected to a product lifecycle management database 510, hereinafter also referred to as PLM-DB for short.

• Durch das Download-Tool werden von der Sicherheitssteuerung 100 Gerätedaten abgefragt, die den Typ, die Seriennummer und Angaben zum aktuellen Hardware- und Firmware-Stand enthalten.
• Durch das Download-Tool wird die Version der zu aktualisierenden Firmware ergänzt, gegen Verfälschung und Manipulation gesichert und als Gerätesignatur-File gespeichert.
• Das Gerätesignatur-File wird über E-Mail oder vorteilhafterweise über direkte Internet-Kommunikation an den Hersteller-Server 500 übermittelt.
• Beim Hersteller wird die Berechtigung für das Update geprüft, wobei dies vorteilhafterweise über einen auf dem Hersteller-Server 500 ablaufenden, als Freischaltgenerator ausgebildeten Server-Dienst erfolgt.
• Zur Prüfung der Berechtigung wird beim Hersteller die PLM-DB 510 abgefragt und die Konsistenz und Plausibilität der übermittelten Daten geprüft sowie die in der PLM-DB 510 enthaltene HW-Version auf eine Berechtigung für ein Update herangezogen.
• Sofern eine Update-Berechtigung vorliegt, wird ein abgesicherter gerätespezifischer Freischaltcode in Form einer Datei generiert, wobei diese einen einzigartigen Code enthält, der zur Nachverfolgbarkeit dient.
• Der Freischaltcode enthält Daten zum Gerätetyp, der Seriennummer, der Hardware-Version und einen Code zur Nachverfolgbarkeit.
• Der Freischaltcode ist gegen Verfälschung und Manipulation gesichert und wird über E-Mail oder vorzugsweise direkte Internet-Kommunikation an den Anwender des Download-Tools übermittelt
• Das Download-Tool liest einerseits die Firmware-Update-Datei in Form eines sicheren Firmware-Containers mit enthaltener Geräte- und Versionskennung ein, als auch den vom Hersteller generierten Freischaltcode.
• Das Download-Tool überprüft die Konsistenz der Daten von der Steuereinrichtung 100 mit den Daten im Freischaltcode und gibt den Download des sicheren Firmware-Containers auf die Steuereinrichtung 100 frei oder sperrt ihn.
• Nach erfolgtem Transfer der Firmware-Update-Datei auf die Steuereinrichtung 100 und einer Konsistenzprüfung auf der Steuereinrichtung 100 wird die Programmierung inklusive einer Gegenprüfung auf der Steuereinrichtung 100 ausgeführt.
• Zur Einleitung der Programmierung wird ein abgesichertes Programmierkommando verwendet.
• Sofern die Übertragung des Firmware-Containers oder dessen Programmierung nicht korrekt verlief, wird der Anwender informiert und das Gerät verbleibt im eigensicheren Zustand.
• In diesem Zustand ist eine erneute Programmierung notwendig und möglich.
• Der Anwender der Steuerung erhält eine Firmware-Update-Datei zugeschickt oder kann sich diese alternativ vom Hersteller über das Internet laden; dies bedeutet, dass die Firmware-Update-Datei nicht personalisiert ist.
• Die Firmware-Update-Datei ist eine sichere Container-Datei, die vom Hersteller generiert und durch einen Kopfdatensatz, auch als Header bezeichnet, zusätzlich gegen Datenverfälschung oder Daten-Manipulation gesichert wird.
• Die Firmware-Update-Datei enthält Firmware-Komponenten für beide Steuermodule der sicheren Steuerung 100 und gegebenenfalls weitere Komponenten, vorteilhaft zum Beispiel FPGA-Konfiguration und Firmware-Loader, die gemeinsam einen Freigabeprozess nach IEC 61508 durchlaufen haben und zertifiziert sind.
• Der Anwender startet das Download-Tool, liest die Firmware-Update-Datei und verbindet sich mit der Steuereinrichtung 100.
• Das Download-Tool generiert aus den Daten der Steuereinrichtung 100 und der Firmware-Update-Datei eine Signatur-Datei, in der Update-relevante Daten enthalten sind, wie zum Beispiel Seriennummer, Hardware-Version, vorhandene Firmware-Version und neue Firmware-Version.
• Die Signatur-Datei wird dem Hersteller übermittelt, zum Beispiel per E-Mail oder direkte Internet-Kommunikation.
• Der Hersteller generiert nach Prüfung der Update-Fähigkeit einen Freischaltcode in Form einer abgesicherten Datei und übermittelt diese dem Anwender, zum Beispiel per E-Mail oder vorteilhafterweise per direkter Internet-Kommunikation.
• Der Anwender liest den Freischaltcode zusammen mit der Firmware-Update-Datei in das Download-Tool ein und das Download-Tool prüft die Konsistenz des Freischaltcodes.
• Bei positiver Prüfung wird die Firmware-Update-Datei als sicherer Container auf die angeschlossene Steuereinrichtung 100 transferiert und dort auf Konsistenz des Containers geprüft, wobei insbesondere eine Prüfung des Headers erfolgt.
• Danach erfolgt die Programmierung in den Systemspeicher 120 und ein weiteres Rücklesen.
• Das Ergebnis des Transfers, der Programmierung und der Überprüfungen werden vom Download-Tool für den Anwender angezeigt und ein Update-Protokoll generiert.
• Nach der kompletten Programmierung muss das Gerät neu gestartet werden.
• Beim Anlauf der programmierten Firmware findet eine weitere Konsistenzprüfung statt, dabei überprüft der Firmware-Loader die Prüfsumme der zu ladenden Firmware.
• Nach dem Start der beiden diversitären Firmware-Komponenten erfolgt eine Prüfung, ob die FW-Versionen zueinander passen.

A preferred firmware update process is outlined below.

• The download tool requests device data from the safety controller 100 that contain the type, serial number and information on the current hardware and firmware version.
• The version of the firmware to be updated is supplemented by the download tool, secured against falsification and manipulation and saved as a device signature file.
• The device signature file is transmitted to the manufacturer server 500 via e-mail or advantageously via direct Internet communication.
• The authorization for the update is checked at the manufacturer, this advantageously taking place via a server service that runs on the manufacturer server 500 and is designed as an activation generator.
• To check the authorization, the PLM-DB 510 is queried from the manufacturer and the consistency and plausibility of the transmitted data is checked and the HW version contained in the PLM-DB 510 is used for authorization for an update.
• If there is an update authorization, a secured device-specific activation code is generated in the form of a file, which contains a unique code that is used for traceability.
• The activation code contains data on the device type, serial number, hardware version and a code for traceability.
• The activation code is secured against falsification and manipulation and is transmitted to the user of the download tool via e-mail or preferably direct Internet communication
• On the one hand, the download tool reads in the firmware update file in the form of a secure firmware container with the device and version identification it contains, as well as the activation code generated by the manufacturer.
• The download tool checks the consistency of the data from the control device 100 with the data in the activation code and enables or disables the download of the secure firmware container to the control device 100.
• After the firmware update file has been transferred to the control device 100 and a consistency check has been carried out on the control device 100, the programming including a counter check is carried out on the control device 100.
• A secured programming command is used to initiate programming.
• If the transfer of the firmware container or its programming did not proceed correctly, the user is informed and the device remains in the intrinsically safe state.
• In this state a new programming is necessary and possible.
• The user of the control receives a firmware update file or can alternatively download it from the manufacturer via the Internet; this means that the firmware update file is not personalized.
• The firmware update file is a secure container file that is generated by the manufacturer and is additionally protected against data corruption or data manipulation by a header data record, also known as a header.
• The firmware update file contains firmware components for both control modules of the safe controller 100 and possibly further components, advantageously for example FPGA configuration and firmware loader, which have jointly gone through an approval process according to IEC 61508 and are certified.
• The user starts the download tool, reads the firmware update file and connects to the control device 100.
• The download tool generates a signature file from the data of the control device 100 and the firmware update file, which contains update-relevant data, such as serial number, hardware version, existing firmware version and new firmware version .
• The signature file is sent to the manufacturer, for example by e-mail or direct Internet communication.
• After checking the update capability, the manufacturer generates an activation code in the form of a secured file and transmits this to the user, for example by e-mail or advantageously by direct Internet communication.
• The user reads the activation code together with the firmware update file into the download tool and the download tool checks the consistency of the activation code.
• If the check is positive, the firmware update file is transferred as a secure container to the connected control device 100 and there the consistency of the container checked, the header being checked in particular.
• This is followed by programming in the system memory 120 and a further reading back.
• The result of the transfer, the programming and the checks are displayed by the download tool for the user and an update log is generated.
• After the complete programming, the device must be restarted.
• When the programmed firmware is started up, another consistency check takes place; the firmware loader checks the checksum of the firmware to be loaded.
• After the two diverse firmware components have started, a check is made to determine whether the firmware versions match.

A preferred sequence of a firmware update is shown again in detail as a flow chart in FIG Figures 2 and 3 shown, where Fig. 2 a first phase and Fig. 3 shows a second phase.

In the Fig. 2 Phase 1 shown comprises the following steps.

In step 600 the firmware file is read from the local file system by the download tool on the update device 400. In step 605 the control device 100 is identified by a data query, for this purpose the update device 400 transmits a corresponding request 607 to the control device 100, which in response to this query in step 610 sends the first device data which are transmitted to the update device 400 in step 612. In the exemplary embodiment shown, it is provided that the device data received by the control device 100 are displayed to the user in step 615. The device data are transmitted to the manufacturer in a secure manner with the header data of the firmware update file, a corresponding signature file being generated for this purpose in step 620 and sent to the manufacturer server 500 in step 625. The signature file transmitted to the manufacturer server 500 in step 627 is checked in step 630 by a release device contained in the manufacturer server 500. The manufacturer server 500 compares the authorization with the PLM-DB 510. If the authorization check is successful, the manufacturer server 500 generates a secured activation code in step 635, for example in the form of an activation file, which comprises a backup and a unique code as a tracking ID. In step 640 the manufacturer server 500 sends the activation code to the update device 400. The activation code transmitted in step 642 is received by the update device 400 and, in response to the receipt of the activation code transmitted in step 642, the update device 400 executes The illustrated embodiment in step 645 again interrogates the first device data from the control device 100, for this purpose the update device 400 transmits a corresponding request 647 to the control device 100, which sends the first device data in response to this request in step 650 which are transmitted to the update device 400 in step 652. That on The download tool running in the update device 400 checks in step 655 the consistency of the device and activation code and, if the consistency check is successful, carries out the data transfer in step 660. For this purpose, the firmware update file is transmitted to the control device 100 in step 662 and is initially temporarily stored there in step 665. The parameterization memory 130 or another suitable, also volatile, memory can be used for intermediate storage. In step 667, confirmation of the storage is transmitted to the update device 400. In step 670 there is a consistency check of the firmware update file for formal correctness, the result of the check being transmitted to the update device 400 in step 672. If the consistency check is successful, the update device 400 then sends a device-specific update command to the control device 100 in step 675, whereby the result of the consistency check is preferably displayed to the user and the user is also informed about the execution of the update, ie the programming or overwriting of the system memory 120 of the new firmware, additionally confirmed by an entry. In response to receiving the update command transmitted in step 677, the controller 100 executes the firmware update in step 680 and stores the unique tracking ID. In step 682, the control device 100 transmits to the update device 400 the information as to whether the update, ie the overwriting of the system memory, was carried out successfully, the update result being displayed to the user in step 685. After the firmware update has taken place, the control device 100 goes into a wait state for reset in step 690, ie to a restart of the control device 100, it also being possible for an automatic implementation of a reset to be provided.

In the Fig. 3 Phase 2 shown includes the following steps.

After the control device 100 has been restarted, it first carries out a self-test in step 700, with the package compatibility of the firmware assigned to the control modules 112 and 114 being checked in particular, whereby these can be present as diverse firmware components.

If an error is detected in step 705 when performing the self-test, the control device 100 assumes a safe state in step 710. The measures required to achieve a safe state are known per se and are therefore not explained in more detail here.

If no error is detected, the control device 100 changes over to normal operation in step 720. The download tool in the update device 400 establishes a connection to the control device 100 in step 725, connection inquiries 727 being transmitted to the control device 100, preferably cyclically, until the control device 100 responds in step 730 and the connection request 727 in Step 732 answered.

In step 735 the download tool queries the updated device data, with the update facility for this purpose 400 transmits a corresponding request 737 to the control device 100, which, in response to this request in step 740, causes device data to be sent, which are transmitted to the update device 400 in step 742. In step 745 the download tool displays the requested device data for the operator, possibly with an error message. A confirmation of the update is securely transmitted to the manufacturer server 500 in step 750. In response to the update confirmation transmitted in step 752, the manufacturer server 500 logs or stores the confirmation in the PLM-DB 510 in step 755. A confirmation of the logging that has taken place is transmitted in step 757 to the update device 400 and the user is informed in step 760 of the completion of the process via a corresponding display.

The following table shows an example of the structure of a firmware update file, i.e. the secure firmware container: component content description Container header 1. File name of the container, ie the firmware update file Name of the firmware update file, the file is thus secured against renaming (pos. 1 is part of pos. 6); unique numeric device identifier; Version of the firmware update file; Number of subsequent components, for example in the case of several, also diverse control modules 2. Device ID 3. Version number 4. Number of components included 5. Component header 1: a) destination (e.g. control module 1 or control module 2) Ensuring the correct target of the programming and verification of the contained image; b) Type of image (loader, operating software, or FPGA program) Determination of the position in the firmware update file Size including image header; c) Offset address in the firmware update file d) Size in the firmware update file Destination address in read-only memory; Protection against corruption of the header or the component e) destination address f) checksum over the complete Component (incl. Header) 6. Component header 2 ... n further component headers according to the number in pos. 4 7. Header checksum over pos. 1 to 4 and all component headers Check sum over pos. 1-6 (all component headers) Firmware image 1 1. Image header (Magic Number 1, checksum, size, address information) Information for the firmware loader 2. Firmware image 1 the firmware image to be loaded 1 Firmware image ... 1. Image header ... Information for the firmware loader 2. Firmware image ... the other firmware images to be loaded ... Firmware image n 1. Image header n Information for the firmware loader 2. FW image n the firmware image to be loaded n

It should be noted that in the example shown in the table, the firmware to be updated, also referred to as firmware image, operating software, software used to load operating software and called a loader, as well as software for programming an FPGA (Field- Programmable gate array) trained processor can include FPGA program used.

The method described advantageously provides a distributed comparison and release device outside the safety controller. This implements a secured consent principle, whereby the consent or the comparison and the responsibility lies first with the manufacturer, the release of the programming is the responsibility of the download tool or, in the last instance, the Operator. The download tool itself is the responsibility of the manufacturer. Encryption of the firmware update file is advantageous, but not absolutely necessary, since all steps are preferably secured by a confidential checksum method. By implementing the important comparison and approval steps outside of the firmware, the algorithm used can be easily adapted, particularly advantageously, if necessary, without having to make changes to the firmware. The method can in principle be interrupted after the first query of the device data, but it is advantageous to run one after the other online. The programming is subject to the approval of the operator and is initiated by a secured programming command. The unique code, which is part of the activation and was generated by the manufacturer, is stored in the PLM database 510 and non-volatile on the control device 100, this preferably being part of the programming command. This code can be used to track which activation was used for the firmware update, whereby the code is stored by the manufacturer and in the device, which results in a double chain of evidence. The unique code is advantageously implemented using a GUID (Globally Unique Identifier). Furthermore, possible interruptions in communication due to timeouts are monitored and also logged by the manufacturer, with interrupted updates being advantageously compared between the PLM-DB 510 and the user, with the information required for this being available.

Claims (14)

1. A method for updating firmware of a control device (100) for process control which comprises at least one control module (112, 114), wherein the control module (112, 114) has associated therewith firmware stored in a system memory (120) of the control device (100), the method comprising the steps of:

   a) providing a firmware file with a new firmware contained therein for the at least one control module in an updating device (400) that is connectable to the control device (100);

   b) retrieving, by the updating device (400), first device data stored in the control device (100);

   c) generating, by the updating device (400), a signed device file depending on the first device data and depending on an information item identifying the new firmware;

   d) transmitting the signed device file from the updating device (400) to a central enabling device (500);

   e) checking the received signed device file by the central enabling device (500);

   f) generating an activation code, by the central enabling device (500), and transmitting the activation code from the central enabling device (500) to the updating device (400) only if the check of the received signed device file by the central enabling device (500) is successful, wherein the activation code comprises second device data and a unique identification information item;

   g) performing a consistency check on the first device data retrieved in step b) and on the second device data contained in the received activation code, by the updating device (400); or
   again retrieving the first device data stored in the control device (100), by the updating device (400), and performing a consistency check on the again retrieved first device data and on the second device data contained in the received activation code, by the updating device (400); and

   h) only if the consistency check is successful, performing an update of the firmware of the control device (100) using the new firmware, by the updating device (400).
2. The method as claimed in claim 1, wherein the performing of an update of the firmware of the control device (100) comprises the steps of:

   - transferring the new firmware from the updating device (400) to the control device (100) in the form of a firmware file;

   - transmitting a device-specific update command from the updating device (400) to the control device (100); and

   - in response to the received update command, updating the firmware of the control module (112, 114) stored in the system memory (120) with the firmware contained in the received firmware file.
3. The method as claimed in any one of the preceding claims, wherein the firmware file comprises protection information, and wherein the control device (100) performs a consistency check on the protection information and only allows the firmware update to continue if the consistency check is successful.
4. The method as claimed in any one of the preceding claims, wherein the firmware file includes a new firmware for at least two control modules (112, 114).
5. The method as claimed in any one of the preceding claims, wherein the unique identification information item contained in the activation code is transmitted from the updating device (400) to the control device (100) and is stored in the control device (100).
6. The method as claimed in any one of the preceding claims, wherein the first and/or second device data include a device type, a hardware version, and/or a serial number of the control device, and/or information about at least one firmware currently executed on the control device.
7. The method as claimed in any one of the preceding claims, wherein an update authorization check is performed by the central enabling device (500), by retrieving authorization information from a product life cycle management database (510) on the basis of device-specific information contained in the received signed device file.
8. The method as claimed in any one of the preceding claims, wherein, once the firmware update has been successfully performed, the updating device (400) transmits an acknowledgment message to the central enabling device (500), wherein in response to the received acknowledgment message the central enabling device logs successful completion of the firmware update, in particular by storing a log entry containing the unique identification information item in the product life cycle management database (510).
9. The method as claimed in any one of the preceding claims, wherein, once the firmware of the at least one control module (112, 114) stored in the system memory (120) has been updated, the control device (100) performs a check for compatibility of the firmware associated with different control modules, and if an incompatibility is detected, the control device (100) changes into a safe operating state.
10. The method as claimed in any one of the preceding claims, wherein the control device (100) is configured as a safety control device for failsafe control of a safety-critical process.
11. The method as claimed in any one of the preceding claims, wherein

    - the transmitting of the signed device file from the updating device (400) to a central enabling device (500), and/or

    - the transmitting of the activation code from the central enabling device (500) to the updating device (400), and/or

    - the transmitting of the device-specific updating command from the updating device (400) to the control device (100), and/or

    - the transmitting of the unique identification information item contained in the activation code from the updating device (400) to the control device (100) is performed in failsafe and/or encrypted manner.
12. A system (10) for updating firmware of a control device (100), comprising:

    - a control device (100) for process control comprising at least one control module (112, 114), wherein the control module (112, 114) has associated therewith a firmware stored in a system memory (120) of the control device (100);

    - an updating device (400) connectable to the control device (100); and

    - a central enabling device (500);

    wherein the updating device (400) is adapted:

    a) to retrieve, from the control device (100), first device data stored in the control device (100);

    b) to generate a signed device file depending on the first device data and depending on an information item identifying a new firmware;

    c) to transmit the signed device file to the central enabling device (500);

    d) to receive an activation code from the central enabling device (500) in response to the transmitted signed device file;

    e) to perform a consistency check on the first device data retrieved in step a) and on second device data contained in the received activation code, or to again retrieve the first device data stored in the control device (100) from the control device (100) and to perform a consistency check on the again retrieved first device data and on second device data contained in the received activation code; and

    f) if the consistency check is successful, to effect update of the firmware of the control device (100) using the new firmware;

    and wherein the enabling device (500) is adapted:

    a) to check a signed device file received from the updating device (400);

    b) if the check is successful, to generate an activation code comprising second device data and a unique identification information item; and

    c) to transmit the activation code to the updating device (400) in response to the received signed device file.
13. The system as claimed in claim 12, wherein

    - the control device is adapted to store the unique identification information item contained in the activation code received from the updating device (400) ;

    - the updating device (400) is adapted to transmit an acknowledgment message to the central enabling device (500) when the firmware updating has been performed successfully; and

    - the central enabling device is adapted, in response to the received acknowledgment message, to log successful completion of the firmware update, in particular by storing a log entry containing the unique identification information item in the product life cycle management database (510).
14. A digital storage medium with instructions stored thereon, which when executed on a computer (400) are adapted to perform the following method steps:

    a) retrieving first device data stored in a control device (100) connected to the computer (400);

    b) generating a signed device file depending on the first device data and depending on information identifying a newly provided firmware;

    c) transmitting the signed device file to a central enabling device (500);

    d) receiving an activation code from the central enabling device (500) in response to the transmitted signed device file, the activation code comprising second device data and a unique identification information item;

    e) performing a consistency check on the first device data retrieved in step a) and on the second device data contained in the received activation code, or again retrieving the first device data stored in the control device and performing a consistency check on the again retrieved first device data and the second device data contained in the received activation code; and

    f) only if the consistency check is successful, effecting update of the firmware of the control device (100) using the new firmware.

Images