Method for updating system program in automation system
By executing control programs in two subsystems of the automation system and keeping processing instances synchronized, the problem of system stopping during system software update is solved, and system updates and redundant operation without stop time are achieved.
Patent Information
- Application Number
- CN202411772118.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-12-05
- Filing Date
- 2024-12-04
- Publication Date
- 2025-06-06
AI Technical Summary
In automated systems, updates to system software often require the system to be stopped, resulting in a temporary loss of reliability, especially in redundant systems, which can interfere with customer expectations.
The system program update is achieved by executing control programs in two subsystems of the automation system and using synchronization lines to maintain synchronization of processing instances. The specific steps include providing a second processing example in the first subsystem and the second subsystem, loading an updated version of the system program, and updating it through the status information of the first control program and the second control program.
The system programs are updated in the automation system without causing the system to stop, ensuring the redundant operation of the automation system during the update period and avoiding temporary loss of reliability.
Smart Images

Figure CN120104154A_ABST
Abstract
Description
Technical Field
[0001] The invention relates to a method for updating a system program in an automation system, a computer program product and an automation system. Background Art
[0002] Redundant systems are often used in automation environments. The possible downtime of automation equipment (also referred to here as "technical equipment") should therefore be reduced. However, downtime is not only caused by failures of existing automation systems. Necessary maintenance work also often leads to system downtime. One type of such maintenance work is the updating of system software (hereinafter also referred to as "firmware" or "FW" or "system program"), which is necessary to correct faults or to retrofit new functions. This usually forces the automation system to be stopped. Especially in the case of redundant automation systems, this is disruptive and contradicts the customer's expectations.
[0003] In the widely used automation system S7 4xxH of Siemens, the system software can be updated without interrupting the control of the automation system. However, the automation system temporarily leaves redundant operation for this purpose. From the customer's point of view, reliability is temporarily lost and this also contradicts the customer's expectations. Summary of the invention
[0004] Against this background, the object of the present invention is to provide an improved approach when updating in an automation system.
[0005] According to a first aspect, a method for updating a system program in an automation system is provided, the method comprising the steps of:
[0006] a) executing a first control program installed on a first system program at a first process instance in a first subsystem of the automation system, and executing a second control program installed on a second system program at a first process instance in a second subsystem of the automation system, wherein the respective first process instances of the first subsystem and the second subsystem are synchronized with one another via a synchronization line, wherein the first process instance of the first subsystem controls the technical system and, if the first process instance of the first subsystem fails, the first process instance of the second subsystem takes over control,
[0007] b) providing a second processing instance in each of the first subsystem and the second subsystem, loading updated versions of the first system program and the second system program onto the corresponding second processing instance, and starting the corresponding second processing instance in parallel with step a), wherein the third control program is installed on the updated version of the first system program and the fourth control program is installed on the updated version of the second system program, and
[0008] c) updating the third control program based on the storage image of all status information of the first control program, and updating the fourth control program based on the storage image of all status information of the second control program.
[0009] Advantageously, an update of, in particular, the firmware can be carried out in such a way that, on the one hand, virtually no downtime of the automation system results and, on the other hand, redundant operation of the automation system is also ensured during the update.
[0010] An update of a system program refers in particular to an update of the firmware. In the present case, a "system program" refers in particular to an operating system, for example, an operating system of a programmable logic controller. On the other hand, a "control program" is a user-specific software (application) installed on the system program.
[0011] The first system program and the second system program preferably have a consistent source code. Likewise, updated versions of the first system program and the second system program preferably have a consistent source code. In an updated version, for example, errors may have been corrected or functions may have been added compared to an old version. The first system program and the second system program or their respective updated versions can also be implemented as different instances of the same software. The first control program, the second control program, the third control program, and the fourth control program preferably have a consistent source code.
[0012] The first control program and the second control program executed in step a) each have a thread (also called "active carrier") and input variables and output variables stored in the (possibly virtualized) working memory of the corresponding first processing instance. For example, the output variable of the first control program can represent an output voltage output to the technical device. After the third and fourth control programs have been installed in step b), these control programs are started on the corresponding second processing instance, but they have not yet been executed. The start-up results in the generation of corresponding data structures in the (possibly virtualized) working memory of the corresponding second processing instance. However, since the third and fourth control programs have not yet been executed, the corresponding threads remain at the starting point. In the data update process according to step c), state information is transmitted. That is, the state of the corresponding thread and the values of the corresponding input variables and output variables are transmitted in the form of copies from the first control program to the third control program and from the second control program to the fourth control program. Therefore, after the transmission process, the third control program as a whole is in the same state as the first control program before the transmission. Similarly, the fourth control program as a whole is in the same state as the second control program before the transmission. From this point in time, therefore, the second program and the fourth program are each able to control the technical device when these programs are executed by the respective second processing instance.
[0013] The first subsystem and the second subsystem are preferably physically (and not just virtually) different systems. In particular, the first subsystem and the second subsystem have different hardware. The first subsystem and the second subsystem are preferably spaced apart from one another, and more precisely such that an expected physical damage event caused by an external influence (e.g. a fire) may not affect both subsystems and / or may not propagate between the two subsystems. In particular, the subsystems may be in different fire zones. This ensures a high level of fail-safety.
[0014] In some embodiments, the first subsystem and the second subsystem can be implemented near the executed technical system or in the cloud or in different clouds. In the latter case, the first subsystem and the second subsystem are connected to the technical system using highly available data lines.
[0015] In the present case, a "processing instance" is preferably understood to be a unit consisting of (physical or virtualized) hardware (e.g. a CPU, a working memory and / or interfaces). First, a corresponding system program (as an operating system) is installed here. A corresponding control program is in turn installed on the corresponding system program. The processing instance executes the system program and the control program and generates corresponding outputs (in particular to the technical system, e.g. control signals on actuators) as a function of inputs (in particular from the technical system, e.g. in the form of sensor measurements).
[0016] The first subsystem and the second subsystem can be connected to the technical system via a (physical or virtualized) bus, such as Ethernet or a fieldbus. In particular, there is a connection to sensors of the technical system, which provide the above-mentioned inputs. In addition, there is a connection to actuators of the technical system, which provide the above-mentioned outputs.
[0017] Technical systems are, for example, tunnel systems, rail systems, production systems, process engineering systems, transport systems, ships and the like.
[0018] The synchronization line is, for example, a bus which has, in particular, an optical waveguide.
[0019] According to one embodiment, before the updating in step c), if the execution of the first control program and the second control program is involved, the corresponding first processing instances in the first subsystem and the second subsystem are suspended.
[0020] In other words, the first processing instances are in a dead time, i.e. they do not generate any changes in their outputs (i.e. do not change the execution of the technical system for a short time) during the update according to step c). Due to the high data transmission speeds within the corresponding subsystems, this dead time may only last a few milliseconds. Advantageously, there is no subsequent catch-up phase. Such a catch-up phase is necessary, for example, in the case of post-operation, as described in EP 2 667 269 A1.
[0021] The control of the technical system is taken over by the second processing instance of the first or second subsystem directly after the completion of the updating process according to step c), wherein the second processing instance of the other subsystem is each redundant, i.e., in the event of a fault or failure, the second processing instance takes over. Accordingly, the first processing instance is also no longer running after step c), but remains in a so-called idle mode or is completely switched off.
[0022] According to a further embodiment, execution of the first (or third) control program on the first (or second) processing instance in the first subsystem is implemented to follow execution of the second (or fourth) control program on the first (or second) processing instance in the second subsystem.
[0023] In principle, the post-operation is described, for example, in EP 2 657 797 A1. This ensures that both subsystems always have the same internal state even at different points in time. This allows the use of slow communication connections compared to data processing in the processing instance.
[0024] The first processing instance of synchronizing the first subsystem and the second subsystem according to step a) can include:
[0025] transmitting a process input value of a first processing instance of a first subsystem, and
[0026] transmitting a release of a first processing instance of the first subsystem, the release indicating which processing steps of the first control program have been processed,
[0027] The second control program is synchronized according to the transmitted process input parameters and the release.
[0028] The use of process input values and releases is described, for example, in EP 2 657 797 A1 and is a simple way of presenting a second subsystem running behind a first subsystem. The release ensures that the second subsystem running behind runs through the same "thread mountain" as the first subsystem running ahead. This also means that the "thread switch" occurs at the same point in the control program. However, in the present case, synchronization can also be achieved in other ways. However, it is important to preferably ensure a so-called bumpless failover. Downtimes of the controlled technical system are thereby avoided.
[0029] After step c) the following step d) can be performed:
[0030] An updated third control program and a fourth control program are executed on the updated versions of the first system program and the second system program on the corresponding second processing instances in the first subsystem and the second subsystem, wherein the second processing instances of the first subsystem and the second subsystem are synchronized with each other via a synchronization line, wherein if the second processing instance of the first (or: the first or second) subsystem fails, the second processing instance of the first (or: the first or second) subsystem controls the technical system and the second processing instance of the second (or: the respective other) subsystem takes over control.
[0031] The second processing instance of synchronizing the first subsystem and the second subsystem according to step d) can include:
[0032] transmitting a process input value of a second processing instance of the first subsystem, and
[0033] transmitting a release of a second processing instance of the first subsystem, the release indicating which processing steps of the third control program have been processed,
[0034] The fourth control program is synchronized according to the transmitted process input parameters and the release.
[0035] According to a further embodiment, the respective second processing instance is started according to step b) as a function of configuration data, which contain information about the configuration of the technical system.
[0036] According to a further embodiment, the control programs to be installed in step b) are each stored in the first subsystem and in the second subsystem (or in an associated cloud storage).
[0037] In particular, the interface of the second process instance can thereby be configured for the technical system before the update process according to step c) is started. The configuration data can contain in particular information about connected sensors and actuators of the technical system. Whenever a technical system is mentioned, this refers in particular to peripherals from the perspective of the automation system, that is to say to components of the technical system (such as, for example, sensors and actuators) with which the automation system or the first system and the second subsystem (there again the first process instance or the second process instance) communicate.
[0038] According to a further embodiment, after starting the corresponding second process instance according to step b), the passive connection of the first process instance of the second subsystem is interrupted and subsequently the started second process instance of the first subsystem establishes a passive connection to the technical system.
[0039] In this case, a "passive" connection is a connection in which the peripheral device or technical system ignores the output and characterizes the input as invalid. In contrast, an "active" connection is a connection in which the peripheral device transmits the output to the actuator and characterizes the input value as valid.
[0040] According to a further embodiment, (in particular directly) after the updating according to step c), the second processing instance of the first subsystem establishes an active connection to the technical system and the second processing instance of the second subsystem establishes a passive connection to the technical system.
[0041] This in turn provides a redundant automation system.
[0042] According to further embodiments, the first subsystem and the second subsystem each have a hypervisor that provides the first processing instance and the second processing instance.
[0043] Thereby, a plurality of processing instances can be easily provided and the plurality of processing instances can share system resources.
[0044] According to further embodiments, the first subsystem and the second subsystem each have a programmable logic controller, a power supply and / or an interface to a technical system.
[0045] This advantageously results in subsystems that are independent of one another.
[0046] According to a second aspect, there is provided a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to implement the above method.
[0047] The computer program product, for example a computer program device, can be provided or supplied, for example, as a storage medium, for example a memory card, a USB stick, a CD-ROM, a DVD, or in the form of a downloadable file from a server in a network. This can be achieved, for example, by transmitting a corresponding file with the computer program product or the computer program device in a wireless communication network. In this case, a "computer" can also include a plurality of (possibly physically separated) computing devices (for example a programmable logic controller).
[0048] According to a third aspect, there is provided an automation system having:
[0049] a first subsystem having a first process instance, the first process instance being configured to control a first control program installed on a first system program in order to thereby control the technical system,
[0050] a second subsystem having a first process instance, the first process instance being configured to execute a second control program installed on the second system program so as to thereby control the technical system if the first process instance of the first subsystem fails,
[0051] a synchronization circuit configured to synchronize respective first processing instances of the first subsystem and the second subsystem with each other,
[0052] wherein each of the first subsystem and the second subsystem is configured to provide a second processing instance and has an interface, via which updated versions of the first system program and the second system program can be loaded onto the corresponding second processing instance, and the third control program can be installed on the updated version of the first system program, and the fourth control program can be installed on the updated version of the second system program, and
[0053] The first subsystem and the second subsystem are configured to update the third control program according to the storage image of all status information of the first control program, and to update the fourth control program according to the storage image of all status information of the second control program.
[0054] The interface capable of loading updated versions of the first system program and the second system program onto the corresponding second processing instances can be implemented as any known data interface, for example, a port.
[0055] The exemplary embodiments and features described for the proposed method apply correspondingly to the proposed automation system and computer program product.
[0056] Other possible embodiments of the present invention also include the features described above or below with respect to the embodiment or the combination of the embodiments not explicitly mentioned. Here, those skilled in the art can also add individual aspects as improvements or supplements to the corresponding basic form of the present invention.
[0057] Further advantageous embodiments and aspects of the invention are subject matter of the dependent claims and of the embodiments of the invention described below.In addition, the invention is explained in more detail below based on preferred embodiments and with reference to the drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0058] Figure 1 An exemplary automation system is shown in preparation for a firmware update in redundant operation;
[0059] Figure 2 Shown in Figure 1 The loading of the new FW version after the state shown in ; and
[0060] Figure 3 Shown in Figure 2 Transition of a passive peripheral device connection after the state shown in;
[0061] Figure 4 Shown in Figure 3 Updates after the status shown in ;
[0062] Figure 5 Shown in Figure 4 Takeover of peripheral devices after the state shown in;
[0063] Figure 6 Shows the situation after FW is updated; and
[0064] Figure 7 Show according to Figures 1 to 6 Flowchart of the method. DETAILED DESCRIPTION
[0065] In the figures, identical or functionally identical elements are provided with the same reference symbols unless otherwise indicated.
[0066] Figure 1 In the initial state of the method, a redundant automation system 10 is shown, which consists of a first subsystem 100 and a second subsystem 200. The subsystems 100, 200 can be in the form of separate racks (referred to herein as "rack 1" and "rack 2"), each of which includes a programmable logic controller (not shown in further detail), power connections and interfaces to peripheral devices 400.
[0067] The two subsystems 100, 200 preferably feature hypervisors 102, 202, which virtualize the hardware (processors, memory, interfaces, etc.). Here, multiple instances of the system program (FW) can be executed in parallel on the same hardware. In this example, these instances are the first and second processing instances H-CPU 1a, H-CPU 1b on hypervisor 102 (subsystem 100) and the first and second processing instances H-CPU 2a, H-CPU 2b on hypervisor 202 (subsystem 200).
[0068] The two subsystems 100, 200 are connected to one another via synchronization lines 300, 302, which can be implemented as optical waveguides. Peripheral devices 400 (also referred to as "technical systems" in this case) are attached to the two subsystems 100, 200 via a bus 500. Solid lines represent active connections and dashed lines represent passive connections (for the PROFINET fieldbus, primary application relationships or backup application relationships - "AR").
[0069] A first control program 106 or a second control program 206 is installed on the first processing instance H-CPU 1a, H-CPU 2a of the first and second subsystems 100, 200, respectively, on the system program FW there, wherein the programs 106, 206 can have a consistent source code. The system program FW is presented as a runtime system, while the control programs 106, 206 are configured on the user side and are suitable for executing the application of the technical system 400 in the desired manner.
[0070] In both subsystems 100, 200, the current configuration of the automation system 10, in particular the technical system 400, is stored on a memory in the form of configuration files 104, 204. The memory can also contain a copy of a control program 106, 206, in particular as an executable file.
[0071] Before the update process, the two subsystems 100, 200 are running in redundant operation with FW version ABC. The peripheral device or technical system 400 is executed by the control program 106 or the processing instance H-CPU 1a or receives data (e.g., measurement data) from it. The synchronization of the two subsystems 100, 200 or the processing instance H-CPU 1a, H-CPU 2a is performed, for example, according to the method described in EP 2 657 797A1, wherein the processing instance H-CPU 1a is the leading instance and the processing instance H-CPU 2a is the following running instance. If the subsystem 100 fails, the subsystem 200 takes over in the sense of a bumpless failover. That is, the control program 206 of the processing instance H-CPU 2a takes over the control of the technical system 400 from there.
[0072] In a first step S1 (see Figure 2 and Figure 7 ), the new FW version AEF is loaded onto the second processing instance H-CPU 1b in the first subsystem 100 and the second processing instance H-CPU 2b in the second subsystem 200, wherein the new FW version AEF is provided via the corresponding interface 108 or 208 (e.g. Ethernet interface, USB interface or similar interface) of the subsystems 100, 200. In some embodiments, only the processing instances H-CPU 1b and 2b can be provided when a FW update is to be processed or the initial commissioning of the automation system 10 is immediately provided.
[0073] In the second step S2 (see Figure 3 and Figure 7 ), the two process instances H-CPU 1b and H-CPU 2b start with a new FW version AEF. The step-up of the two process instances H-CPU 1b and H-CPU 2b is performed based on the currently available configuration file 104 or 204. The third control program 116 and the fourth control program 216 are installed and started on the new FW version AEF of the process instance H-CPU 1b or H-CPU 2b based on the configuration file 104 or 204.
[0074] After the processing instances H-CPU 1b and H-CPU 2b are powered on, the processing instance H-CPU 2a performs step S3 (see Figure 3 and Figure 7) to invalidate its passive connection (standby AR) to the peripheral device 400. The new passive connection (in Figure 3 The dotted line in FIG. 1 is established by the processing instance H-CPU 1b. At this time, the two processing instances H-CPU 1b and 2b never process any control program of the control programs 116 and 216.
[0075] In step S4, the control programs 116, 216 are updated on the processing instances H-CPU 1b and H-CPU 2b in parallel on the two subsystems 100, 200. This is done based on the memory images of the control programs 106, 206 on the processing instances H-CPU 1a and 2a. That is, the update process is performed locally. The processing instances H-CPU 1a and 1b or 2a and 2b each perform this update process in the same system state.
[0076] For the update process, the memory images of the processing instances H-CPU 1a and H-CPU 2a are transferred to the processing instances H-CPU 1b or 2b (in Figure 4 ), and the processing on the processing instances 1a and 2a once again enters a downtime related to the current state of the control program 106, 206, that is, the process is not controlled. In contrast, in the updating method according to EP 2 667 269 A1, the leading processing instance continues to run directly after the storage image is created. However, in this case, because the two updating processes are each carried out locally in the subsystem 100 or 200, the transmission of the storage image itself hardly requires any time. Here, this is basically a copy of the memory content. Therefore, the downtime during the transmission of the storage image to the processing instance H-CPU 1b and 2b is acceptable (in the range of milliseconds).
[0077] The advantages of this approach include that there is no catch-up phase required in the solution described in EP 2 667 269 A1 in the two local update processes. This catch-up phase is difficult to implement in different versions of the system program. In this method, the old FW or the new FW is active. Therefore, the newer FW does not have to support synchronous operation with the old FW and thus becomes simpler.
[0078] Immediately after the update process, the active peripheral connections are switched to the processing instance H-CPU 1b ( Figure 7 Step S5 in Figure 5). As a result, the process instance H-CPU 1b now has access to the peripheral device 400. The process instances H-CPUs 1b and 2b are now running in redundant mode, for example, as described in EP 2 657 797 A1. The process instances H-CPUs 1a and 2a are terminated and are now inactive.
[0079] In step S6 ( Figure 6 and Figure 7 ), preferably, passive peripheral devices are connected ( Figure 6 ) is rebuilt by the processing instance H-CPU 2b. As a result, the peripheral device 400 is once again redundantly connected to the two subsystems 100, 200. The automation system 10 now operates in redundant mode with the firmware version AEF. In a similar manner, further firmware updates can now be performed using the processing instances H-CPUs 1a and 2a.
[0080] Although the invention has been described with reference to exemplary embodiments, the invention can be modified in many ways.
Claims
1. A method for updating a system program (FW ABC) in an automation system (10), the method comprising the following steps: a) executing a first control program (106) installed on a first system program (FW ABC) on a first processing instance (H-CPU 1a) in a first subsystem (100) of the automation system (10), and executing a second control program (206) installed on a second system program (FWA.BC) on a first processing instance (H-CPU 2a) in a second subsystem (200) of the automation system (10), wherein: The respective first processing instances (H-CPU 1a, H-CPU 1b) of the first subsystem and the second subsystem (100, 200) are synchronized with one another via synchronization lines (300, 302), wherein the first processing instance (H-CPU 1a) of the first subsystem (100) controls the technical system (400) and, if the first processing instance (H-CPU 1a) of the first subsystem (100) fails, the first processing instance (H-CPU 1b) of the second subsystem (200) takes over control, b) providing a second processing instance (H-CPU 1b, H-CPU 2b) in each of the first subsystem and the second subsystem (100, 200), loading (S1) the updated versions (FW AEF) of the first system program and the second system program on the corresponding second processing instance (H-CPU 1b, H-CPU 2b), and starting (S2) the corresponding second processing instance (H-CPU 1b, H-CPU 2b) in parallel with step a), wherein a third control program (116) is installed on the updated version (FW AEF) of the first system program and a fourth control program (216) is installed on the updated version (FW AEF) of the second system program, and c) updating (S4) the third control program (116) according to the storage image of all status information of the first control program (106), and updating the fourth control program (216) according to the storage image of all status information of the second control program (206).
2. The method according to claim 1, It is characterized in that Prior to the updating in step c), the corresponding first processing instances (H-CPU 1a, H-CPU 2a) in the first subsystem and the second subsystem (100, 200) are stopped as far as the execution of the first control program and the second control program (106, 206) is concerned.
3. The method according to claim 1 or 2, It is characterized in that Execution of the second control program (206) on the first processing instance (H-CPU 2a) in the second subsystem (200) is implemented to follow execution of the first control program (106) on the first processing instance (H-CPU 1a) in the first subsystem (100).
4. The method according to any one of claims 1 to 3, It is characterized in that The synchronization of the first processing instances (H-CPU 1a, H-CPU 1b) of the first subsystem and the second subsystem (100, 200) according to step a) comprises: transmitting a process input value of a first processing instance (H-CPU 1a) of said first subsystem (100), and transmitting a release of a first processing instance (H-CPU 1a) of the first subsystem (100), the release indicating which processing steps of the first control program (106) have been processed, The second control program is synchronized according to the transmitted process input parameters and the release (106).
5. The method according to any one of claims 1 to 4, It is characterized in that According to step b), the corresponding second processing instance (H-CPU 1b, H-CPU 2b) is started based on configuration data (104, 204), the configuration data containing information about the configuration of the technical system (400), and / or wherein: The configuration data and / or the control program (116, 216) to be installed in step b) are each stored in the first subsystem and in the second subsystem (100, 200).
6. The method according to any one of claims 1 to 5, It is characterized in that After starting the corresponding second processing instance (H-CPU 1b, H-CPU 2b) according to step b), the passive connection of the first processing instance (H-CPU 2a) of the second subsystem (200) is interrupted and the started second processing instance (H-CPU 1b) of the first subsystem (100) subsequently establishes (S3) a passive connection to the technical system (400).
7. The method according to any one of claims 1 to 6, It is characterized in that After updating according to step c), the second processing instance (H-CPU 1b) of the first subsystem (100) establishes an active connection to the technical system (400), and the second processing instance (H-CPU 1b) of the second subsystem (200) establishes (S5, S6) a passive connection to the technical system.
8. The method according to any one of claims 1 to 7, It is characterized in that The first subsystem and the second subsystem (100, 200) each include a hypervisor (102, 202) that provides the first processing instance and the second processing instance (H-CPU 1a, H-CPU 1b, H-CPU 2a, H-CPU 2b).
9. The method according to any one of claims 1 to 8, It is characterized in that The first and second subsystems (100, 200) each comprise a programmable logic controller, a power supply and / or an interface (500) to the technical system (400).
10. A computer program product comprising instructions, which, when a computer executes the program, cause the computer to perform the method according to any one of claims 1 to 9.
11. An automated system (10), comprising: a first subsystem (100) having a first processing instance (H-CPU 1a) configured to execute a first control program (106) installed on a first system program (FW ABC) and thereby control a technical system (400), a second subsystem (200) having a first processing instance (H-CPU 2a) configured to execute a second control program (206) installed on a second system program (FW ABC) and thereby control the technical system (400) in the event of a failure of the first processing instance (H-CPU 1a) of the first subsystem (100), a synchronization line (300, 302) configured to synchronize the respective first processing instances (H-CPU 1a, H-CPU 2a) of the first subsystem and the second subsystem (100, 200) with each other, The first subsystem and the second subsystem (100, 200) are each configured to provide a second processing instance (H-CPU 1b, H-CPU 2b) and have an interface (108, 208), through which an updated version (FW AEF) of the first system program and the second system program (FW ABC) can be loaded onto the corresponding second processing instance (H-CPU 1b, H-CPU 2b) and a third control program (116) can be installed onto the updated version (FWA.EF) of the first system program and a fourth control program (216) can be installed onto the updated version (FWA.EF) of the second system program, and The first subsystem and the second subsystem (100, 200) are configured to update the third control program (116) according to a storage image of all status information of the first control program (106), and to update the fourth control program (216) according to a storage image of all status information of the second control program (206).
Citation Information
Patent Citations
Method for operating a redundant automation system
EP2657797A1
Method for operating a redundant automation system
EP2667269A1