System and method for firmware update in safe fieldbus input / output devices

Abstract

The invention relates to a system and a method for securely updating firmware. The system comprises a safe fieldbus Input / Output device (302), which includes input / output modules, a communication module (102), and a processing unit (104). It is operable via a non-safe web interface (101). The system is characterized by at least one manually operable physical selector (111) and a two-step release process. This process requires a first release step, wherein the selector (111) is manually set to a predefined update setting, followed by a subsequent system initialization, in particular a power cycle. The processing unit (104) is configured to evaluate the setting of the selector (111) only during this initialization and, in response, to switch the device (302) from a safe operational state into an update state. A subsequent second release step comprises the reception of a release command via the web interface (101). The processing unit (104) initiates the firmware update only after the completion of both release steps.

Description

[0001] SYSTEM AND METHOD FOR FIRMWARE UPDATE IN SAFE FIELDBUS

[0002] INPUT / OUTPUT DEVICES

[0003] The present invention relates to a system for updating firmware in a safety fieldbus device, particularly a Safety Remote Input / Output (SRIO) device, according to the preamble of claim 1. The invention further relates to a method for updating firmware in such a device.

[0004] In modem automation systems, functionally safe fieldbus devices play a critical role. Such devices are not controllers themselves but act as distributed Input / Output (I / O) nodes. Their primary function is to safely acquire physical signals from sensors located in the field and to reliably transmit control commands from a higher-level programmable logic controller (PLC) to actuators. By doing so, they extend the safety chain of the central controller directly to the machine level, ensuring that safety-critical signals are processed with the required integrity.

[0005] The firmware of these safety gateways is critical for their operation, as it governs the reliable processing and transmission of all safety-related data. Therefore, updating this firmware, which may be necessary to correct faults or to expand functionality, requires special precautions. Any modification to the device's software can potentially compromise its certified safety integrity. An incorrect, corrupted, or maliciously altered firmware could render the safety function inoperable, leading to a loss of protection for personnel and machinery. Therefore, the update process itself must be exceptionally robust and secure to ensure that only a valid and intended update is performed at a moment when the controlled process is in a verifiably safe state.

[0006] EP 4 287 054 A1 is related to a Computer-implemented method for updating a safety software code providing a safety function to a computing hardware device comprising the following steps. Executing a host module by the computing hardware device, wherein a first environment and a second environment are operated in isolation from each other by the host module. A reception of an update package by a reception software operated in the first environment precedes a verification of a fulfilment of predefined update conditions by the update package by an update software operated in the second environment, including the verification of the fulfilment of the predefined update conditions. This ends in an inclusion of the update code element into the safety software code in the second environment by the update software.

[0007] US 11 ,429,720 B2 discloses a method and a system for updating the firmware of a control device, in particular a safety controller. In this method, an updating device, such as a computer, is used to retrieve device data from the control device. Based on this data and information about the new firmware, a signed device file is generated and transmitted to a central enabling device, typically a manufacturer's server. The enabling device performs an authorization check and, upon success, generates a device-specific activation code. This activation code is sent back to the updating device, which then initiates the firmware update process on the control device.

[0008] The disclosed method relies entirely on a remote, software-based authorization process. A disadvantage of this approach is its potential vulnerability to unauthorized remote access or malicious attacks. Should a user's network or updating device be compromised, an attacker could theoretically initiate an unauthorized firmware update without requiring physical access to the device. Furthermore, concerns regarding functional safety may arise, as an authorized user could trigger an update remotely at an operationally inappropriate moment, without being aware of the immediate physical state of the machine or plant controlled by the device. This could lead to potentially hazardous operational states, as the system lacks a verification that the on-site device is in a safe condition for an update. An additional drawback is the dependency on a constant and secure connection to an external manufacturer's server, which may not be available or desirable in all industrial environments.

[0009] It is therefore an object of the present invention to provide a system and method for updating firmware in a safety device that overcomes the aforementioned disadvantages. In particular, an object is to enhance security against unauthorized remote updates and to improve functional safety by ensuring that the update is initiated under safe on-site conditions, while also enabling a user to perform the update autonomously without dependency on an external entity.

[0010] With respect to the system, this object is achieved by the features of claim 1 . With respect to the method, the object is achieved by the features of claim 10. Advantageous embodiments and further developments of the invention are specified in the dependent claims.

[0011] The invention relates to a system for updating firmware, the system comprising:

[0012] • a safe fieldbus Input / Output device, in particular a safe remote input / output (SRIO) device, configured to enable communication between a fieldbus and safely connected sensors and / or actuators; and

[0013] • a non-safe web interface configured for user interaction with the device;

[0014] • wherein the device comprises: o input and / or output modules for connecting the sensors and / or actuators; o a communication module configured to handle data transfer for firmware updates; o a processing unit configured to manage the operation of the device; and characterised in that the system comprises at least one non-safe manually operable physical selector connected to the device; wherein the system is configured to implement a two-step release process for safely initiating a firmware update, said process requiring:

[0015] • a first release step, comprising the manual setting of the at least one physical selector to a predefined update setting and a subsequent system initialization; wherein the processing unit is configured to evaluate the setting of the selector during said initialization and, only if the selector is set to the predefined update setting, to switch the device from a safe operational state into an update state; and

[0016] • a subsequent second release step, comprising the reception of a release command using the web interface;

[0017] • wherein the processing unit is configured to initiate the firmware update only upon completion of both the first step and the subsequent second release step.

[0018] In other words, the invention creates a robust security architecture that establishes a deliberate, physical, on-site action as a mandatory prerequisite for any software-based update initiation. This effectively prevents unauthorized or accidental remote updates and significantly enhances the functional safety of the overall system.

[0019] A preferred aspect of this process is that, after the initialization, the selector is newly read, preferably only a single time, preferably during the boot-up sequence of the device. Preferably the non-safe manually operable physical selector, in particular DIP and / or rotary switches, are otherwise used for addressing the device.

[0020] The invention achieves this through a novel two-step release process that fundamentally redefines the security architecture for firmware updates. The first advantage of this process lies in its robust protection against unauthorized remote access. By mandating a first release step that requires a physical, manual setting of a selector on the device itself, the system creates an "air-gapped" authorization that cannot be bypassed by software means alone. This physical interaction acts as a gatekeeper, ensuring that the device only enters its special, update-receptive state after a deliberate on-site action and initialization, in particular by performing a device initialization, preferably power cycle. Consequently, even if a network or a remote user interface were to be compromised, a malicious actor would be unable to initiate a firmware update, as the device would remain in its secure operational state, unresponsive to any unauthorized update commands. This procedural safeguard provides a superior level of security compared to purely softwarebased or remote verification systems.

[0021] A second, equally important advantage of the two-step release process lies in the significant improvement of functional safety and user autonomy. The mandatory physical interaction ensures that an operator must be present at the device to enable an update, allowing them to first verify that the controlled machine or plant is in a safe condition. This prevents an authorized but remote user from inadvertently initiating an update during a critical or unsafe operational phase. Furthermore, because the security is ensured by the robust procedural design itself, the invention eliminates the dependency on an external manufacturer's server for verification. This empowers the user to perform necessary updates autonomously, reliably, and securely, even in isolated industrial environments without external network access. A key inventive aspect is that this high level of procedural safety is achieved using non-safety-rated components for the user interaction, such as a standard physical selector and a standard web interface, thus providing a cost- effective and elegant solution to a critical safety problem.

[0022] According to a preferred embodiment, the system initialization is triggered by a power cycle of the safe fieldbus device. The power cycle represents an unambiguous, conscious confirmation by the operator, which prevents the update state from being activated accidentally. In an advantageous development, the system is configured to perform the firmware update without requiring communication with or verification from an external manufacturer server. This provides the advantage of complete autonomy, making the system ideal for use in isolated or highly secure network environments.

[0023] Preferably, the at least one non-safe physical selector is further configured to set the safe operational state of the device, in particular after another system initialization, and wherein the predefined update setting is distinct from any setting used for the safe operational state. This dual functionality of the selector enables an efficient and cost- effective hardware design.

[0024] Perferably, the safe operational state is controlled by a safe programmable logic controller, PLC, application.

[0025] According to a further embodiment, the non-safe web interface is embodied as an Internet of Things, loT, core interface and / or a Representational State Transfer, REST, Application Programming Interface, API. This allows for flexible and standardized integration with modem, higher-level management systems.

[0026] The preferred inclusion of an loT core interface for user interaction facilitates remote management and control of the firmware update process, enhancing the convenience and efficiency of maintaining the SRIO devices. The loT core offers a user-friendly interface, allowing users to easily initiate firmware updates and monitor the progress in real-time.

[0027] Another advantageous embodiment provides that the physical selector comprises a plurality of individual switches, in particular a DIP switch or a group of dip switches, and wherein the predefined update setting is a specific combination of the individual switch positions, representing a multi-digit value. This functions like a "combination lock," offering higher security against inadvertent actuation than a simple on / off switch.

[0028] Furthermore, it may be provided that the at least one non-safe physical selector is selected from the group consisting of a DIP switch, a set of DIP switches, and / or a rotary switch or a set of rotary switches. The use of these industrially proven components ensures the reliability of the manual release mechanism. The preferred set of DIP and / or rotary switches designed to set the SRIO device into an update state provides a simple and reliable manual method to initiate the firmware update process, which can be crucial in scenarios where remote access is compromised or unavailable. It provides a simple and reliable means for operators to manually initiate the firmware update process, ensuring that the device is ready to receive new firmware without the need for complex software commands or specialized tools.

[0029] According to a preferred embodiment the system is configured to activate the update state by selecting predefined positions of the DIP and / or rotary switches, in particular three DIP and / or rotary switches. For example by setting the DIP and / or rotary switches to the value ‘999’ to activate the update state.

[0030] According to a further embodiment, the safe fieldbus device further comprises a visual indicator, in particular an LED, configured to signal to a user when the device is in the update state. This feature provides a clear and unambiguous indication to the on-site operator that the device is no longer in its safe operational mode and is ready to receive an update, thereby preventing confusion and enhancing procedural safety.

[0031] Preferably, the device further comprises a power supply module integrated with the communication module to ensure a stable power delivery during the firmware update process. This minimizes the risk of update-related failures. The integration of the communication module with the power supply module ensures a stable power delivery during the firmware update process, reducing the risk of update failures due to power fluctuations.

[0032] According to another preferred embodiment, during the safe operational state, the safe fieldbus device is configured to communicate with a programmable logic controller, PLC, via the fieldbus to operate as a distributed I / O node under the control of a safe application running on the PLC, said communication comprising the exchange of safety-related data between the device and the PLC. This describes the seamless integration of the device into standard industrial safety architectures.

[0033] Furthermore, according to a preferred embodiment, the processing unit is a microcontroller module. Preferably, the system's microcontroller module efficiently coordinates the update process across input and output modules, minimizing disruption to the Safe Fieldbus- Device’s (SRIO device's) operation.

[0034] By managing the update process efficiently, the microcontroller module minimizes the risk of errors or conflicts that could arise from simultaneous updates to multiple modules, enhancing the reliability of the system.

[0035] During a preferred embodiment of the update, the processing unit, preferably embodied as a microcontroller module, efficiently coordinates the update process across the input and output modules. To minimize process downtime, the method may further comprise maintaining at least a subset of input and output modules in a safe or operational state while another part of the device is being updated.

[0036] The invention further relates to a method for updating firmware in a safe fieldbus device, in particular using a previously mentioned system, the device being configured to enable safe communication between a fieldbus and safely connected sensors and / or actuators, and being in communication with a non-safe web interface, the method comprising the steps of (in a preferred sequence): a) performing a first, physical release step, said step comprising: i. manually setting at least one non-safe, manually operable physical selector on the device to a predefined update setting; and ii. performing a system initialization of the device, in particular a power cycle, thereby causing the device's processing unit to evaluate the setting of the selector and, in response to detecting the predefined update setting, to switch the device from its safe operational state into an update state; b) performing a subsequent second, software-based release step, said step comprising receiving a release command from the non-safe web interface; and c) initiating, by the processing unit, the firmware update only upon successful completion of both the first and the second release steps.

[0037] This method establishes an inherently safe and auditable workflow for firmware updates. Preferably, the method further comprises providing feedback to a user via the non-safety- rated web interface regarding the status of the firmware update process. This enhances transparency and allows for real-time monitoring. In an advantageous embodiment of the method, the step of initiating the firmware update comprises coordinating the update process by maintaining at least a subset of input and output modules in a safe or operational state while an update of another part of the device is performed. This minimizes operational downtime and maintains critical safety functions.

[0038] Furthermore, the method preferably comprises the steps of: validating a received firmware update package before initiating the firmware update; and performing a postupdate validation after the update is completed. This ensures the integrity of the installed firmware.

[0039] To ensure the integrity and compatibility of the update, the firmware update is preferably performed using a structured update package. This package is designed to be robust and may include a CRC container header for overall file validation, a container header with detailed metadata such as version and product type, a compatibility list to verify suitability for the target device, and the actual binaries containing the firmware update files. Before the firmware is written to memory, the method includes a step of validating this received package. After the update process is complete, a post-update validation is performed to ensure a successful installation. In other words, the firmware update is performed using a firmware update package structured to include one or more elements from the group consisting of: a CRC container header, a container header with metadata, a compatibility list, and binaries. Such a structure enables robust error checking and compatibility verification.

[0040] Moreover, it may be provided that the firmware update is preferably transferred using protocols selected from the group consisting of PROFINET / PROFIsafe and HTTP / JSON, allowing for secure and interoperable data transfer.

[0041] In a further embodiment, the method further comprises activating a visual indicator on the safe fieldbus device to signal that the device has entered the update-receptive state. This step ensures the operator has clear, physical confirmation of the device's status before proceeding with software-based interactions.

[0042] A further embodiment of the method specifies that the step of initiating the firmware update further comprises selecting a firmware update file via the non-safe web interface, transferring the selected file to the safe fieldbus device, and transmitting a start command from the web interface to the device. This defines the workflow after the device has been physically prepared. Once the update state is set, a user on the host side, which itself is non-safe, can select and load the appropriate file. The protocol for this transfer is secured to ensure data integrity. The final start command from the host side then serves as the last confirmation to begin the update process.

[0043] To improve transparency, the method preferably includes providing feedback to a user via the web interface regarding the status of the update process, allowing for real-time monitoring.

[0044] Preferably the system is configured to perform a firmware version check, receive and validate a firmware update package, execute the update, and perform post-update validation to ensure successful installation.

[0045] The preferred integration of both Fieldbus safety protocol-Stacks (like Profinet / Profisafe, Ethern / IO CipSafety, FSOE for e.g.) and / or HTTP(s) / JSON protocols in the communication module provides versatility in firmware update methods, allowing for compatibility with a wide range of network configurations and ensuring secure data transfer in industrial environments.

[0046] The method preferably includes feedback mechanisms that provide continuous updates to the user, ensuring transparency and visibility into the firmware update process.

[0047] In a preferred embodiment the method comprises the steps in a preferred sequence: c. transferring the firmware update package through the communication module, d. validating the update package and initiating the update process, e. providing feedback to the user throughout the update process, f. performing post-update validation to ensure successful installation.

[0048] In a further embodiment, the method further comprises an update package being structured to include a CRC container header, a container header with detailed metadata, a compatibility list, an ARID list, a binary header, and / or binaries containing the firmware update files. The inclusion of a CRC container header in the update package ensures data integrity by enabling the detection of any corruption that occur during the transfer of the firmware update, thus preventing the installation of potentially harmful or non-functional firmware.

[0049] The detailed metadata within the container header allows for precise identification and verification of the firmware update package, ensuring compatibility with the SRIO device and reducing the risk of installing incorrect or outdated firmware.

[0050] The structured update package with a compatibility list and APID list provides a systematic approach to firmware updates, allowing for targeted updates to specific modules or functionalities within the SRIO device, which can minimize the risk of incompatibility issues post-update.

[0051] In a further preferred embodiment, the method further comprises update process including a feedback loop to confirm receipt and installation of the update.

[0052] Moreover, the method further may comprise an update package being received and validated using: PROFINET / PROFIsafe, Ethernet I IP Cipsafety, EtherCats / FSOE and / or HTTP(s) / JSON; MQTT(s); OPCUA protocols for secure data transfer.

[0053] The use of PROFINET / PROFIsafe and HTTP / JSON protocols for receiving and validating the update package ensures secure data transfer, protecting the SRIO device from potential cyber threats and unauthorized access during the update process.

[0054] BRIEF DESCRIPTION OF DRAWINGS

[0055] The present disclosure is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements. Embodiments of the application will now be described with reference to the attached drawings:

[0056] Figure 1 schematic system architecture according to the invention

[0057] Figure 2 schematic update container

[0058] Figure 3 schematic update interaction process

[0059] Figure 4 higher resolution of Fig. 3 without reference numbers

[0060] Figure 5 safety fieldbus device. Figure 1 shows a system architecture according to the invention with components and their interactions highlighted. Figure 1 provides a visual representation of a system designed for updating firmware in a safe fieldbus device 302, in particular a safe remote input / output (SRIO) device. The diagram includes the following components:

[0061] A non-safe web interface 101 , depicted as an loT Core / Visualizer on a laptop, represents the interface for a user 301 to monitor and control the firmware update process. In a preferred embodiment, the non-safe web interface 101 is an Internet of Things, loT, core interface, a Representational State Transfer, REST, Application Programming Interface, API, or in particular a VHIB platform.

[0062] The Communication Module 102 illustrates the means through which data transfer occurs. It is configured to provide a communication link to a fieldbus for operational data via a fieldbus connection 109, for example PROFINET / PROFIsafe, and to the non-safe web interface 101 for firmware updates via a connection to the web interface 110, for example HTTP / JSON.

[0063] The Power Supply Module 103 is shown providing the necessary power to the system components; this is essential for the stable operation of the firmware updating process. A processing unit 104, preferably embodied as a microcontroller module, is centrally located, representing its role in managing the operations of the input and output modules.

[0064] Multiple Input Modules 105 are connected to sensors 107, signifying how sensory data is integrated into the function of the safe fieldbus device 302. Multiple Output Modules 106 are connected to actuators 108, showcasing the system's ability to control mechanical components or systems.

[0065] At least one non-safe manually operable physical selector 111 , for example a set of DIP Switches, is included. This selector is a central component of the two-step release process for safely initiating a firmware update. In a preferred embodiment, the safe fieldbus device 302 further comprises a visual indicator, in particular an LED, configured to signal to a user when the device is in the update state. The diagram also indicates the safety relevance, with dashed lines demarcating the safety-relevant parts within the system. Overall, the figure demonstrates a complex system involving various hardware and software components that work in concert to facilitate secure and reliable firmware updates.

[0066] Figure 2 shows details of a structured update container, illustrating the organization of update data according to the invention. The diagram illustrates the hierarchical organization of a firmware update package. At the top level, the CRC Container Header 201 encompasses the entire update package structure, ensuring overall integrity with a CRC of the output file 235. The Container Header 202 contains metadata such as a boot cookie 203, a header version 204, a title 205, a vendor 206, a creation date 207, and a product type 208. This header also includes the number of compatibility list entries 209 and the compatibility list CRC 210, the number of APID list entries 211 and the APID list CRC 212, as well as the number of binaries 213 and their corresponding header CRC 214. The Compatibility List 215 includes multiple software compatibility entries 216, 217, 218 to check firmware compatibility. The APID List 219 contains APID entries 220, 221 , 222 detailing identifiers for the update. The Binary Header 223 outlines the structure for the Binaries 234. This structure includes details for a first binary file, File 0, such as binary type 224, binary name 225, start address 226, binary size 227, and binary CRC 228. This structure is repeated for a second binary file, File 1 , as indicated by reference signs for its binary type 236, binary name 237, start address 238, binary size 239, and binary CRC 240, and for subsequent binary files up to File n, as indicated by reference signs for its binary type 229, binary name 230, start address 231 , binary size 232, and binary CRC 233.

[0067] Figure 3 shows outlines of the update interaction process, describing the steps from user initiation to update confirmation. This flowchart illustrates the two-step release process. The process begins with the first, physical release step, where the user 301 performs the manual setting of the physical selector 111 to a predefined update setting 303, for example by setting the selector to the preferred value ‘999’. This action is followed by a mandatory system initialization, in particular a power cycle 304. In a preferred embodiment, after the initialization, the selector 111 is newly read, preferably only a single time during the boot-up sequence, to ensure the device enters the update state only after this deliberate action. Subsequently, the second, software-based release step is performed, wherein the user sends a release command, for example a firmware update request 305, via the web interface 101 , receiving a feedback of the request 306. Once the update is initiated, Start Update 307, a request loop 311 may query the status, receiving feedback that the update image has been received 314. The process concludes when the user returns the physical selector 111 to a predefined operational setting 316, for example the value ‘000’, and performs another power cycle 317 to switch the device back into its safe operational state.

[0068] Figure 4 shows a more detailed view of the update interaction process of Figure 3. The process flowchart begins with the user 301 setting the physical selector 111 , in particular DIP switches, on the safe fieldbus device 302 to a predefined value, preferably ‘999’, and performing a system initialization 304, in particular a power cycle. A firmware update request 305 is sent from the web interface, here designated as an loT Core 402. In a preferred embodiment, once the update state is set, a user on the host side can select an update file, load the file to the device, and then transmit the firmware update request 305 to start the update. Preferably the microcontroller module 104 interacts with the communication module 102 to receive and validate the firmware update package. The entire process is preferably coordinated by the microcontroller module 104. The request is initiated, Update Request Initialization 412, followed by a validation check 413. The process preferably includes a feedback mechanism 414 and confirmation of update image reception 415. Upon completion, post-update validation 417 is conducted, and the process finishes with a completion confirmation 418 to the web interface.

[0069] Figure 5 shows an example of a safe fieldbus device with different ports for Inputs and outputs, a physical selector embodied as three rotary switches, power supplies, Fieldbus and loT Connectors, and an HMI Part for signaling different information to the user. REFERENCE NUMERAL LIST

[0070] 1 System

[0071] 101 Non-safe web interface (e.g., loT Core / Visualizer)

[0072] 102 Communication Module

[0073] 103 Power Supply Module

[0074] 104 Processing unit (e.g., Microcontroller Module)

[0075] 105 Input Modules

[0076] 106 Output Modules

[0077] 107 Sensors

[0078] 108 Actuators

[0079] 109 Fieldbus connection (e.g., PROFINET / PROFIsafe)

[0080] 110 Connection to web interface (e.g., HTTP / JSON)

[0081] 111 Non-safe manually operable physical selector (e.g., DIP Switches)

[0082] 201 CRC Container Header

[0083] 202 Container Header

[0084] 203 Bootcookie

[0085] 204 Header Version

[0086] 205 Title

[0087] 206 Vendor

[0088] 207 Creation Date

[0089] 208 Product Type

[0090] 209 Number of Compatibility List Entries

[0091] 210 Compatibility List CRC

[0092] 211 Number of APID List Entries

[0093] 212 APID List CRC

[0094] 213 Number of Binaries

[0095] 214 Binary Header CRC

[0096] 215 Compatibility List

[0097] 216 Software Compatibility Entry 0

[0098] 217 Software Compatibility Entry 1

[0099] 218 Software Compatibility Entry n

[0100] 219 APID List

[0101] 220 APID Entry 0

[0102] 221 APID Entry 1 222 APID Entry n

[0103] 223 Binary Header

[0104] 224 Binary Type File 0

[0105] 225 Binary Name File 0

[0106] 226 Start Address File 0

[0107] 227 Binary Size File 0

[0108] 228 Binary CRC File 0

[0109] 229 Binary Type File n

[0110] 230 Binary Name File n

[0111] 231 Start Address File n

[0112] 232 Binary Size File n

[0113] 233 Binary CRC File n

[0114] 234 Binaries

[0115] 235 CRC of Output File

[0116] 236 Binary Type File 1

[0117] 237 Binary Name File 1

[0118] 238 Start Address File 1

[0119] 239 Binary Size File 1

[0120] 240 Binary CRC File 1

[0121] 301 User

[0122] 302 Safe fieldbus device

[0123] 303 Manual setting of physical selector to predefined update setting

[0124] 304 System initialization (e.g., Power Cycle)

[0125] 305 Release command (e.g., Firmware Update request)

[0126] 306 Feedback of Firmware Request

[0127] 307 Start Update

[0128] 311 Request Loop Until Update Initiated

[0129] 314 Feedback: Update Image Received

[0130] 316 Manual setting of physical selector to predefined operational setting

[0131] 317 Perform Power Cycle

[0132] 402 Non-safe web interface (e.g., loT Core)

[0133] 412 Update Request Initialization

[0134] 413 Update Validation Check

[0135] 414 Feedback Mechanism 415 Update Image Reception

[0136] 417 Post-Update Validation

[0137] 418 Completion Confirmation

Claims

CLAIMS1 . A system for updating firmware, the system comprising:• a safe fieldbus Input / Output device (302), in particular a safe remote input / output (SRIO) device, configured to enable communication between a fieldbus and safely connected sensors (107) and / or actuators (108); and• a non-safe web interface (101 ) configured for user interaction with the device (302);• wherein the device (302) comprises: o input and / or output modules for connecting the sensors (107) and / or actuators (108) o a communication module (102) configured to handle data transfer for firmware updates; o a processing unit (104) configured to manage the operation of the device (302); and characterised in that the system comprises at least one non-safe manually operable physical selector (111) connected to the device (302); wherein the system is configured to implement a two-step release process for safely initiating a firmware update, said process requiring:• a first release step, comprising the manual setting of the at least one physical selector (111 ) to a predefined update setting and a subsequent system initialization; wherein the processing unit (104) is configured to evaluate the setting of the selector (111) during said initialization and, only if the selector is set to the predefined update setting, to switch the device (302) from a safe operational state into an update state; and• a subsequent second release step, comprising the reception of a release command using the web interface (101 );• wherein the processing unit (104) is configured to initiate the firmware update only upon completion of both the first step and the subsequent second release step.

2. The system of claim 1 , wherein the system initialization is triggered by a power cycle of the safe fieldbus device (302).

3. The system of claim 1 or 2, wherein the safe operational state is controlled by a safe programmable logic controller, PLC, application.

4. The system of any of the preceding claims, wherein the at least one non-safe physical selector (111 ) is further configured to set the safe operational state of the device (302), in particular after another system initialization, and wherein the predefined update setting is distinct from any setting used for the safe operational state.

5. The system of any of the preceding claims, wherein the non-safe web interface (101 ) is embodied as an Internet of Things, loT, core interface and / or a Representational State Transfer, REST, Application Programming Interface, API.

6. The system of any of the preceding claims, wherein the physical selector (111 ) comprises a plurality of individual switches, in particular a DIP switch and / or rotary switches, and wherein the predefined update setting is a specific combination of the individual switch positions, representing a multi-digit value.

7. The system of any of the preceding claims, wherein the at least one non-safe physical selector (111 ) is selected from the group consisting of a DIP switch, a set of DIP switches, a rotary switch and / or a group of rotary switches.

8. The system of any of the preceding claims, wherein the evice (302) further comprises a visual indicator, in particular an LED, configured to signal to a user when the device is in the update state.

9. The system of any of the preceding claims, wherein, during the safe operational state, the safe fieldbus device (302) is configured to communicate with a programmable logic controller, PLC, via the fieldbus to operate as a distributed I / O node under the control of a safe application running on the PLC, said communication comprising the exchange of safety-related data between the device (302) and the PLC.

10. A method for updating firmware in a safe fieldbus device (302), in particular using a system of any of claims 1 to 9, the device being configured to enable safe communication between a fieldbus and safely connected sensors (107) and / or actuators (108), and being in communication with a non-safe web interface (101), the method comprising the steps of: a) performing a first, physical release step, said step comprising: i. manually setting at least one non-safe, manually operable physical selector (111 ) on the device to a predefined update setting; and11. performing a system initialization of the device (302), in particular a power cycle, thereby causing the device's processing unit (104) to evaluate the setting of the selector (111 ) and, in response to detecting the predefined update setting, to switch the device from its safe operational state into an update state; b) performing a subsequent second, software-based release step, said step comprising receiving a release command from the non-safe web interface (101 ); and c) initiating, by the processing unit (104), the firmware update only upon successful completion of both the first and the second release steps.11 . The method of claim 10, further comprising providing feedback to a user via the non-safety-rated web interface (101) regarding the status of the firmware update process.

12. The method of any of claims 10 or 11 , wherein the step of initiating the firmware update comprises coordinating the update process by maintaining at least a subset of input and output modules (106) in a safe or operational state while an update of another part of the device (302) is performed.

13. The method of any of claims 10 to 12, further comprising the steps of:- validating a received firmware update package before initiating the firmware update; and- performing a post-update validation after the update is completed.

14. The method of any of claims 10 to 13, wherein the firmware update is performed using a firmware update package structured to include one or more elements from the group consisting of: a CRC container header (201 ), a container header with metadata (202), a compatibility list (215), and binaries (234).

15. The method of any of claims 10 to 14, wherein the firmware update is transferred using protocols selected from the group consisting of PROFINET / PROFIsafe and HTTP / JSON.

Images