AUTOMATION SYSTEM

Description

[0001] The invention relates to an automation system.

[0002] This patent application claims priority from German patent application DE 10 2022 119 309.8.

[0003] In automation technology, network systems are often used in which the decentralized devices of a machine peripheral system, such as I / O modules, transmitters, drives, valves, and operator terminals, communicate with automation, engineering, or visualization systems. All bus devices are connected via a fieldbus, usually a serial fieldbus. Data exchange via the fieldbus is often carried out based on a hierarchical server-client access management in the form of datagrams, also known as telegrams.

[0004] The server units on the fieldbus, usually the control units, have bus access authorization and determine data transfer. The client units on the fieldbus, usually machine devices, do not have bus access authorization, meaning they may only acknowledge received telegrams or transmit telegrams upon request from the server units. The telegrams consist of control data and user data. The Ethernet standard is generally used as the protocol for controlling data exchange on the fieldbus. This standard allows telegrams with a length of up to 1500 bytes while simultaneously achieving high transmission speeds of up to 10 Gbit / s.

[0005] The fieldbus of the automation system is often designed as a ring structure in which the individual client units are connected to a line along the transmission path, with each bus participant connected to two neighbors and the first and last bus participants in the ring connected to the server unit.

[0006] A requirement for a server-client automation system, especially when used in manufacturing and process automation, is high fault tolerance. One fault in the automation system that must be able to survive without damage is the failure of the server unit.

[0007] Automation systems therefore often include an additional backup server unit. EP 3 072 262 B1 describes such an automation system with two identical server units. If one server unit fails, the other server unit can take over control of the automation system. However, implementing a redundant control system in an automation system with two identical server units is complex and costly. Depending on the machine controlled by the automation system, if the server unit fails, it may be sufficient to transfer the machine to a safe state instead of maintaining the machine's full functionality.

[0008] An automation system with the features of the first part of claim 1 is known from DE 10 2020 127 804 A1.

[0009] The object of the invention is to provide an automation system in which the failure of the server unit is reliably detected and the machine controlled by the automation system can then continue to operate with a reduced range of functions if necessary.

[0010] This object is achieved with an automation system according to claim 1. Preferred developments are specified in the dependent claims.

[0011] In an automation system, a plurality of bus devices are connected to one another via a fieldbus in order to exchange telegrams with a predetermined data structure between the bus devices. The bus devices comprise a main server unit, a standby server unit, and at least one client unit. In a normal operating mode, the main server unit and the client unit exchange normal telegrams with a predetermined user data structure. The standby server unit is designed to receive the normal telegrams exchanged between the main server unit and the client unit. The functionality of the main server unit is continuously monitored. If a failure event of the main server unit is detected, the standby server unit is designed to activate a failure operating mode, wherein in the failure operating mode the standby server unit and the client unit exchange failure telegrams.In the failure telegrams, the predefined payload structure of the normal telegrams is divided into relevant data elements and optional data elements. The standby server unit is designed to use the data values ​​of the relevant data elements of the currently available normal telegram for the relevant data elements of the first failure telegram and predefined default data values ​​for the optional data elements of the first failure telegram. Default data values ​​can, for example, be expected values ​​and can be specified by the operator.

[0012] Such a server-client automation system can achieve high fault tolerance, particularly when used in manufacturing and process automation. The failure of the main server unit is survived without damage, as the additional backup server unit takes over control of the automation system. However, a smaller server unit and / or a backup server unit with a simple or robust control program code can then be used as the backup server unit.

[0013] In the failover mode, the client unit can have a different range of functions than in the normal mode, with the range of functions of the client unit in the failover mode preferably providing a secured state for the client unit. For the failover mode, less input data is generally required from the machine's sensors than for the normal mode. Furthermore, the output data set for the machine's actuators is also reduced in the failover mode.

[0014] The control program code of the backup server unit differs at least in part from the control program code of the main server unit. This prevents a programming error in the control task of the main server unit from causing the backup server unit to also fail if the main server unit fails. The control program code on the main server unit can then be easily replaced.

[0015] The backup server unit has a repository with a plurality of failover operating modes. Upon activation of the failover operating mode, the backup server unit is configured to select the failover operating mode from the plurality of failover operating modes based on the data values ​​of the relevant data elements of the currently present normal telegram and / or status information continuously transmitted from the main server unit to the backup server unit. In this way, the optimal failover operating mode for the client unit can be quickly determined depending on the operating state of the client unit.

[0016] If the backup server unit detects that the main server unit has recovered functionality after the main server unit has failed, the backup server unit is designed to transmit the relevant data elements of the failure telegrams to the main server unit. To reactivate normal operating mode, the main server unit is preferably designed to use the data values ​​of the relevant data elements of the last failure telegram transmitted by the backup server unit for a first normal telegram. This enables a reliable resumption of normal operation of the client unit.

[0017] Furthermore, the backup server unit can be designed to assume a failure of the main server unit in the event of a predetermined deviation in the behavior and / or from the normal state of the main server unit. This allows the failure of the main server unit to be detected early. To prevent dangerous situations, the backup server unit takes over operations and ensures a safe state.

[0018] The invention is explained in more detail with reference to the accompanying figures. Herein: Fig. 1 schematic diagram of an automation system with two server units; Fig. 2 schematic diagram of the structure of an automation system with two server units and a fieldbus designed as a ring structure; Fig. 3A a normal operating mode in which Fig. 2 automation system shown; Fig. 3B a failure mode in which Fig. 2 automation system shown; and Fig. 4 a flow chart when changing between normal operating mode and failure operating mode in which Fig. 1 automation system shown.

[0019] In the following, machines are defined as devices equipped with at least one drive system. The term "machine" also includes systems that are arranged and controlled in such a way that they function as a unified whole.

[0020] In industrial automation, networks are used to connect distributed field devices at a sensor / actuator level to a control level. Automation systems, also called fieldbus systems, typically have a fieldbus to which the bus devices are connected. Various fieldbus concepts can be used, differing in terms of the connection structure, fieldbus access, and fieldbus protocol.

[0021] The fieldbus protocol defines how data exchange between the bus devices on the fieldbus is to be carried out. The fieldbus protocol determines the rules and formats for the communication behavior of the bus devices. The message structure defined by the fieldbus protocol contains all information important for data exchange, such as the sender and recipient, message type, message size, and checksum for verifying error-free transmission. This information is prepended to the payload in the message as control data (header) and / or appended to the payload in the message as a trailer.

[0022] The Ethernet protocol is often used as the basic protocol in fieldbuses. The Ethernet protocol divides the data to be transmitted into so-called frames, the structure of which is defined in the IEEE 802.3 standard. The actual Ethernet frame is preceded by a preamble and a start bit, the so-called Start Frame Delimiter (SFD). This is followed by the actual Ethernet telegram. The Ethernet telegram consists of a header, a payload block, and a trailer.

[0023] The header begins with a 6-byte field for the destination address, followed by another 6-byte field containing the source address. This can be followed by another 6-byte field, the so-called tag field, with additional control data in the header, which primarily contains prioritization information. The header concludes with a 2-byte field, the so-called type field, which provides information about the fieldbus protocol used to process the data in the payload block.

[0024] The payload block following the header can be up to 1500 bytes long, although various Ethernet protocol extensions may allow larger data blocks. The payload block can be terminated by the so-called PAD (Padding Bits) field to guarantee the specified minimum length of the Ethernet frame.

[0025] The payload block is followed by the trailer, which contains a 6-byte field with a checksum. When an Ethernet telegram is created, a CRC calculation is performed on the bit sequence, and the checksum is appended to the payload block. The receiver performs the same calculation after receiving the data. If the received checksum does not match the checksum it calculated itself, the receiver assumes a faulty transmission. The Ethernet telegram is then discarded.

[0026] The use of the Ethernet standard in industrial automation makes it possible to provide real-time solutions, in particular. Examples of real-time fieldbus systems based on the Ethernet standard include PROFINET, EtherCAT, Powerlink, and SERCOS III. The fieldbus protocol used is indicated as a Type field in the header of the Ethernet frame. However, instead of the Ethernet standard, other fieldbus protocols, such as CANopen, Interbus, or Profibus, can also be used in automation systems.

[0027] Automation systems are typically operated with a server-client structure. The server units in the automation system are the active bus devices and have bus access authorization to determine telegram traffic on the fieldbus. The server units form the control level in the automation system. The client units are passive bus devices that do not have bus access authorization and are only allowed to transmit data upon request from the server units. The client units are typically machine peripherals, such as I / O devices, valves, drives, and measuring transducers.

[0028] Automation systems with a server-client structure are often designed so that the individual client units are linked to a chain via the transmission medium, with each client unit connected to two neighbors, and the first and last client units in the chain are connected to the server unit, resulting in a ring structure. Data transmission in the form of telegrams on the fieldbus then occurs in one direction, starting from the server unit to the first neighboring client unit, from there to the next, to the last client unit, and then back to the server unit.

[0029] In automation systems, control is typically implemented such that the server unit preferably performs control tasks cyclically to generate output data for the client unit based on input data from client units. One execution of the control task corresponds to one control process cycle.

[0030] After the control process cycle has been completed, the server unit sends the output data generated from the input data from the client units as telegrams over the fieldbus. In a fieldbus design using a ring structure, the client units then extract the output data assigned to the respective client unit from the telegrams as the telegrams pass through the client unit in order to use the output data to execute a local client unit process. The data determined in the local client unit process is then entered by the client unit into designated areas in the telegrams circulating on the fieldbus. The server unit then uses the transmitted data as input data for the next control process cycle.

[0031] A requirement for a server-client automation system, especially when used in manufacturing and process automation, is high fault tolerance. One fault in the automation system that must be overcome without damage is the failure of the server unit. Therefore, the automation system is provided with at least two server units, with one serving as the main server unit and the other as the backup server unit. If the main server unit fails, the backup server unit can then take over control of the automation system.

[0032] The automation system is designed so that, in normal operating mode, the main server unit exchanges standard telegrams with a predefined payload structure with the client units. The backup server unit receives the standard telegrams exchanged between the main server unit and the client units. The functionality of the main server unit is continuously monitored.

[0033] If a failure of the main server unit is detected, the backup server unit activates a failure mode of operation in which the backup server unit and the client units exchange failure telegrams.

[0034] The failure of the main server unit can result in mechanical damage to the machine, for example, if electronically coupled axes collide, destroying parts of the machine. To mitigate this situation, the backup server unit takes over operation of the machine in the event of a failure of the main server unit, with the backup server unit transferring the machine to a safe state in failover mode.

[0035] The failover mode can involve a controlled shutdown of the machine, for example, by ramping down the coupled axes. However, a failover mode with a reduced range of functions can also be implemented. For example, a stirrer in a machine can continue to rotate at a constant speed to prevent materials from sticking together.

[0036] For the failover mode, less input data is generally required from the machine's sensors than for the normal mode. Furthermore, the output data set for the machine's actuators may also be reduced in the failover mode.

[0037] In the failure telegrams output by the standby server unit to the fieldbus in the failure operating mode, the predefined user data structure of the normal telegrams is divided into relevant data elements and optional data elements, whereby the standby server unit is designed to use the data values ​​of the relevant data elements of the currently available normal telegram for the relevant data elements of the first failure telegram and predefined default data values ​​for the optional data elements of the first failure telegram.

[0038] It is also advantageous if the backup server unit is programmed differently than the main server unit. This prevents a programming error in the control task of the main server unit from causing the backup server unit to also fail if the main server unit fails. The backup server unit then has a different control program code than the main server unit, i.e., the control program code of the backup server unit is not the same, or at least partially the same, as the control program code running on the main server unit. The control program code on the main server unit can therefore be easily swapped.

[0039] If the control program code of the main server unit crashes, the backup server unit physically rescues the machine. The control program code on the backup server unit is also leaner and less complex than that of the main server unit. Furthermore, the control program code of the backup server unit is designed for exceptional security and undergoes extensive testing to ensure that the backup server unit's failover mode operates reliably and error-free.

[0040] The control program code on the backup server unit can have a repository with a plurality of failover operating modes in order to be able to respond to the different situations in which the backup server unit is to assume control of the machine with a suitable failover operating mode. The backup server unit is then designed so that, upon activation of the failover operating mode, the failover operating mode is selected from the plurality of failover operating modes based on the data values ​​of the relevant data elements of the currently present normal telegram and / or status information continuously transmitted from the main server unit to the backup server unit.

[0041] In normal operating mode, the control program code on the backup server unit continuously retrieves payload data from the main server unit to take over the machine in its current state in the event of a failure and execute the failover mode. To perform the synchronization process, the backup server unit is designed to receive the normal telegrams with the specified payload data structure exchanged between the main server unit and the client units in normal operating mode.

[0042] If the main server unit fails in failover mode, the fieldbus continues to receive the failover telegrams from the backup server unit. This ensures that telegram traffic on the fieldbus is only ever operated by a maximum of one server unit—i.e., the main server unit in normal mode and the backup server unit in failover mode.

[0043] The backup server unit assumes control of telegram traffic in the event of a main server unit failure. Events that are considered a main server unit failure, and for which the backup server unit then activates the failover mode, can be external events and / or internal events related to the main server unit.

[0044] The external processes can be detected by the backup server unit itself, meaning no assistance from the main server unit is required. The main server unit can, for example, fail completely due to a physical defect or a program crash caused by a programming error. If the main server unit no longer sends a normal telegram, the backup server unit detects this and starts the failure mode. The backup server unit can, for example, also monitor a temperature range of the main server unit in order to detect a failure of an air conditioning system in a control cabinet of the main server unit, which is then classified as a failure of the main server unit. It must always be ensured that the main server unit is actually switched off, so that the backup server unit and the main server unit are reliably prevented from simultaneously exercising control over the telegram traffic.

[0045] The internal processes for triggering the fallback operating mode by the backup server unit require the main server unit to transmit information itself, which is then used to trigger the fallback operating mode of the backup server unit. Such internal processes that trigger the sending of fallback information to the backup server unit can be defined in the control program code of the main server unit. The control program code of the main server unit can trigger, for example, in the event of a cycle time violation or if the jitter is higher than expected, and then send fallback information to the backup server unit.

[0046] It is also possible for the backup server unit to be triggered by a self-diagnosis of the main server unit. Such an internal event detected by the main server unit's self-diagnosis, which triggers the sending of failure information to the backup server unit, could be a fan failure. The so-called SMART system integrated into a hard drive of the main server unit, which monitors the hard drive's reliability and service life, can also be used, for example, to determine whether a failure event has occurred in the main server unit. Furthermore, an assessment of the main server unit's resource utilization may be too high, for example, because the RAM is more than 95% utilized or the hard drive is more than 95% full, thus triggering the backup server unit's failure mode by the main server unit.

[0047] Figur 1 shows the basic structure of an automation system with two server units. The automation system has a fieldbus 1, which can be a transmission path, for example, an electrical cable, a fiber optic cable, or even a radio link. A main server unit 2, a backup server unit 3, and client units 5 of a machine are connected to the fieldbus 1 as bus participants. The main server unit 2, the backup server unit 3, and the client units 5 of the machine can be connected directly to the transmission path of the fieldbus 1 or via an intermediate interface module.

[0048] The fieldbus 1 of the automation system can be designed as a ring structure in which the individual client units 5 of the machine are connected to a line along the transmission path, with each client unit 5 being connected to two neighbors and the first client unit 5-1 and the n-th client unit 5-N in the ring being connected to the main server unit 2 and the backup server unit 3, respectively.

[0049] In order to switch between the main server unit 2 and the backup server unit 3 with little additional hardware effort, the main server unit 2 and the backup server unit 3 are connected via a distributor 4 (see Fig. 2 ) is connected to the fieldbus 1, which is designed as a ring structure.

[0050] Fig. 2 schematically shows the possible structure of such an automation system. The automation system comprises a main server unit 2 and a backup server unit 3, a distributor 4, and a plurality of client units 5, numbered as first client units 5-1, second client unit 5-2, ..., X-th client unit 5-X, ..., 5-N, where X is an integer equal to or greater than 1 to N, where N is the total number of client units.

[0051] The main server unit 2 and the backup server unit 3 have the same basic structure, but are different units. The main server unit 2 has a transmitting / receiving device of the main server unit 20, which comprises a first transmitting unit TX 201 and a first receiving unit RX 202. The main server unit 2 also contains a control device of the main server unit 21, which is connected to the transmitting / receiving device of the main server unit 20 via a data connection of the main server unit 22. The backup server unit 3 has a transmitting / receiving device of the backup server unit 30, which comprises a second transmitting unit TX 301 and a second receiving unit RX 302. Furthermore, the replacement server unit 3 contains a control device of the replacement server unit 31, which is connected to the transmitting / receiving device of the replacement server unit 30 via a data connection of the replacement server unit 32.

[0052] The distributor 4 has a main server transceiver 40, which includes a third transmitting unit TX 401 and a third receiving unit RX 402, a backup server transceiver 41, which includes a fourth transmitting unit TX 411 and a fourth receiving unit RX 412, and a client transceiver 42, which includes a fifth transmitting unit TX 421 and a fifth receiving unit RX 422. Furthermore, a switching device 43 is provided, which is connected to the main server transceiver 40, the backup server transceiver 41, and the client transceiver 42 via an internal data connection of the distributor 4.

[0053] The main server unit 2, the backup server unit 3 and the distributors 4 are in Fig. 2 designed as separate components. However, it is also possible to integrate the replacement server unit 3 and the distributor 4 into a single component, with the control device of the replacement server unit 31 and the switching device 43 of the distributor 4 then being directly connected to each other via an internal data connection (not shown).

[0054] The fieldbus 1 of the automation system comprises a client fieldbus 6. The client fieldbus 6 has two unidirectional communication paths, designated as the first communication path 61 and the second communication path 62. The client fieldbus 6 serially connects the distributor 4 and the first client units 5-1, the second client unit 5-2, ..., and the nth client unit 5-N. The distributor 4 is connected to the first communication path 61 as a telegram decoupling point via the fifth transmitting unit TX 421 of the client transmitting / receiving device 42, and to the second communication path 62 as a telegram coupling point via the fifth receiving unit RX 422 of the client transmitting / receiving device 42.

[0055] The transmitting / receiving device of the main server unit 20 is connected to the main server transmitting / receiving device 40 of the distributor 4 via a main data bus 7. The first transmitting unit TX 201 of the transmitting / receiving device of the main server unit 20 is connected to the third receiving unit RX 402 of the main server transmitting / receiving device 40 of the distributor 4 via a first unidirectional communication path 71. Furthermore, the first receiving unit RX 202 of the transmitting / receiving device of the main server unit 20 is connected to the third transmitting unit TX 401 of the main server transmitting / receiving device 40 of the distributor 4 via a second unidirectional communication path 72.

[0056] The transmitting / receiving device of the backup server unit 30 is connected to the backup server transmitting / receiving device 41 of the distributor 4 via a backup data bus 8. The second receiving unit RX 302 of the transmitting / receiving device of the backup server unit 30 is connected to the fourth transmitting unit TX 412 of the backup server transmitting / receiving device 41 of the distributor 4 via a third unidirectional communication path 81. Furthermore, the second transmitting unit TX 301 of the transmitting / receiving device of the backup server unit 30 is connected to the receiving unit RX 411 of the backup server transmitting / receiving device 41 of the distributor 4 via a fourth unidirectional communication path 82.

[0057] The main data bus 7 and the backup data bus 8 can each be designed as a branch of the client field bus 6, which connects the distributor 4 in a ring shape successively to the first client unit 5-1, the second client unit 5-2, ..., the nth client unit 5-N and then again to the distributor 4, wherein the first communication path 61 and the second communication path 62 of the client field bus 6 are operated in opposite directions.

[0058] The first client unit 5-1, the second client unit 5-2, ..., and the nth client unit 5-N all have the same structure. The structure of a client unit 5 is explained as an example. Viewed from the distributor 4, the client unit 5 has a first transmitting / receiving device 50 for connecting to a previous bus subscriber and a second transmitting / receiving device 51 for connecting to the next bus subscriber.

[0059] The first transmitting / receiving device 50 of the client unit 5 comprises a sixth transmitting unit TX 501 and a sixth receiving unit RX 502, wherein the sixth transmitting unit TX 501 of the first transmitting / receiving device 50 is connected to the second communication path 62 and the sixth receiving unit RX 502 of the first transmitting / receiving device 50 is connected to the first communication path 61.

[0060] The second transmitting / receiving device 51 of the client unit 5 comprises a seventh transmitting unit TX 511 and a seventh receiving unit RX 512, wherein the seventh transmitting unit TX 511 of the second transmitting / receiving device 51 is connected to the first communication path 61 and the seventh receiving unit RX 512 of the second transmitting / receiving device 51 is connected to the second communication path 62. A processing device 52 is connected between the first transmitting / receiving device 50 and the second transmitting / receiving device 51 and is connected to the client unit 5 via an internal data connection 53.

[0061] The processing unit 52 of the client unit 5 is designed to process telegrams exchanged between the first transmitting / receiving device 50 and the second transmitting / receiving device 51 via the internal data connection 53 of the client unit 5. Telegram processing occurs during the telegram pass on the first communication path 61 of the additional fieldbus 6.

[0062] The fifth transmitting unit TX 421 of the client transmitting / receiving device 42 of the distributor 4 on the first communication path 61 of the further fieldbus 6 serves as a telegram decoupling point. On the first communication path 61 of the further fieldbus 6, the telegram passes successively through the connected first client unit 5-1, second client unit 5-2, ..., nth client unit 5-N. The processing unit 52 of the client units, which is connected between the sixth receiving unit RX 502 of the first transmitting / receiving device 50 and the sixth transmitting unit TX 501 of the second transmitting / receiving device 51, processes the telegram as it passes through the client unit.

[0063] After the telegram has passed through the nth client unit 5-N and been processed, the processed telegram is fed back via the second communication path 62 of the client fieldbus 6 to the fifth receiving unit RX 422 of the client transceiver device 42 of the distributor 4, which serves as the telegram coupling point. The processed telegram then passes through the client units on the second communication path 62 in reverse order, i.e., the nth client unit 5-N, ..., the second client unit 5-2, and the first client unit 5-1, whereby the telegram is only amplified but not processed by the processing unit 52 of the Xth client unit 5-X.

[0064] In normal operating mode, the automation system is controlled by the main server unit 2. In failover mode, control is taken over by the backup server unit 3. Within the scope of a control task, the control device of the respective server unit—in normal operating mode, the control device of the main server unit 21, and in backup operating mode, the control device of the backup server unit 31—generates telegrams.

[0065] The control device of the main server unit 21 is designed to generate normal telegrams, each comprising a control data block, which can be divided into a header section and a trailer section, and a payload block. The control device of the backup server unit 31 is designed to generate failover telegrams, each comprising a control data block that is identical to the control data block of the normal telegrams, but comprising a payload block that is modified compared to the payload block of the normal telegrams.

[0066] In the failure telegrams, the specified payload structure of the normal telegrams is divided into relevant data elements and optional data elements, whereby the replacement server unit 3 is designed to use the data values ​​of the relevant data elements of the currently available normal telegram for the relevant data elements of the first failure telegram and the specified default data values ​​for the optional data elements of the first failure telegram.

[0067] In normal operating mode, the transmitting / receiving device of the main server unit 20 transmits the normal telegrams via the main data bus 7 to the main server transmitting / receiving device 40 of the distributor 4. A normal operating mode switching rule defined in the switching device 43 of the distributor 4 then forwards normal telegrams received from the main server transmitting / receiving device 40 to the client transmitting / receiving device 42 in order to output the normal telegrams on the first communication path 61 of the client fieldbus 6.

[0068] Furthermore, in normal operating mode, the switching device 43 of the distributor 4 routes the processed normal telegrams received from the client transmitting / receiving device 42 on the second communication path 62 of the client fieldbus 6 to the main server transmitting / receiving device 40 of the distributor 4 using the normal operating mode switching rule. The main server transmitting / receiving device 40 of the distributor 4 then sends the processed normal telegrams via the main data bus 7 to the transmitting / receiving device of the main server unit 20.

[0069] In addition, the normal operating mode switching rule defined in the switching device 43 of the distributor 4 routes normal telegrams received from the main server transceiver 40 and processed normal telegrams received from the client transceiver 42 to the standby server transceiver 41 of the distributor 4. The standby server transceiver 41 of the distributor 4 then sends the normal telegrams via the standby data bus 8 to the transceiver of the standby server unit 303.

[0070] Fig. 3A shows the described normal operating mode in the automation system Fig. 2 , where the normal telegram transmission direction in the communication paths is indicated by arrows.

[0071] Fig. 3B shows the described failure operating mode in the automation system Fig. 2 , where the failure telegram transmission direction in the communication paths is indicated by arrows.

[0072] In a failover mode, the failover mode switching rule defined in the switching device 43 of the distributor 4 forwards failure telegrams received from the standby server transmitting / receiving device 41 to the client transmitting / receiving device 42. Furthermore, the switching device 43 of the distributor 4 forwards processed, feedback-generated failure telegrams received from the client transmitting / receiving device 42 to the standby server transmitting / receiving device 41. The standby server transmitting / receiving device 41 of the distributor 4 then sends the failure telegrams via the standby data bus 8 to the transmitting / receiving device of the standby server unit 30.3

[0073] The distributor 4 thus ensures that, regardless of whether the telegrams in the automation system are generated by the main server unit 2 or the backup server unit 3, the telegrams circulate in the data bus and are processed by all client units connected to the client fieldbus 6.

[0074] The reconfiguration of the telegram transmission when switching from the main server unit 2 to the backup server unit 3 in the event of a failure of the main server unit 2 is carried out automatically in real time.

[0075] Fig.4 shows a flow chart when changing between normal operating mode and failure operating mode in which Fig. 1 The automation system shown here is assumed below that the Ethernet protocol is used on fieldbus 1, with data exchange with the telegrams in the client units 5 taking place in a through-flow manner. However, other fieldbus concepts can in principle be used for telegram traffic.

[0076] In normal operating mode, the main server unit 2 cyclically performs control tasks to generate output data for the client units 5 based on input data from the client units 5. After completion of a control process cycle, the main server unit 2 sends the output data generated based on input data from the client units 5 as normal telegrams on the fieldbus 1 to the client units 5. The normal telegrams generated by the main server unit 2 each have a payload structure 100.

[0077] The client units 5 extract the output data assigned to the respective client unit 5 from the normal telegrams sent on fieldbus 1 by the main server unit 2 in order to execute a local client unit process with the output data. The data determined in the local client unit process is then entered by the client unit 5 into designated areas in the normal telegrams circulating on fieldbus 1 and transmitted back to the main server unit 2. The main server unit 2 then uses the transmitted data as input data for the next control process cycle.

[0078] In normal operating mode, a synchronization step S is also executed, with which all normal telegrams of the normal telegram traffic are continuously mirrored to the backup server unit 3. The backup server unit 3 receives all normal telegrams exchanged between the main server unit 2 and the client units 5 with the specified payload structure 100.

[0079] Furthermore, in normal operating mode, a monitoring step Ü is continuously executed to determine a failure of the main server unit 2. The assessment of whether a failure has occurred is carried out in an assessment step B by the backup server unit 3. Events that are assessed as a failure of the main server unit 2 by the backup server unit 3 in the assessment step B can be external events and / or internal events related to the main server unit 2.

[0080] The external events for triggering the failover operating mode are determined by the backup server unit 3 in evaluation step B without the assistance of the main server unit 2. For internal events for triggering the failover operating mode, the main server unit 2 transmits information that is then used by the backup server unit 3 in evaluation step B to trigger a failover operating mode of the backup server unit 3.

[0081] In the case of the main server unit 2, not only a failure but also the current state of the control task can be monitored in the monitoring step Ü and then evaluated in the evaluation step B by the backup server unit 3.

[0082] If in the evaluation step B the failure operating mode is triggered due to an external or internal process without the control of the telegram traffic by the main server unit 2 being interrupted, the normal operating mode of the main server unit 2 is switched off in order to prevent the main server unit 2 from accessing the fieldbus 1 in addition to the standby server unit 3.

[0083] If a failure of the main server unit 2 is detected by the backup server unit 3 in an evaluation step B, the backup server unit 3 executes a data reduction step D. In the data reduction step D, the backup server unit 3 generates another payload structure 101, which contains the relevant data elements of the payload structure 100 of the normal telegrams necessary for a failure operating mode. The other optional data elements of the payload structure 100 of the normal telegrams are discarded.

[0084] The data reduction, which determines the relevant data elements of the payload structure 100 of the normal telegrams in the further payload structure 101, is performed by the standby server unit 3. The standby server unit 3 determines which data elements of the payload structure 100 of the normal telegrams are relevant data elements and which data elements are optional data elements. In an initialization process, the standby server unit 3 is informed in advance for various states of the control task which data elements in the payload structure 100 of the normal telegrams are relevant data elements and which data elements are optional data elements.

[0085] The state of the control task and thus of the machine on which the control task is executed can be determined by the replacement server unit 3 within the scope of the data reduction step D on the basis of the data values ​​of the relevant data elements of the currently available normal telegram.

[0086] However, it is also possible for the state of the control task to be continuously written by the main server unit 2 into the payload structure 100 of the normal telegrams and transmitted to the standby server unit 3 with the mirrored normal telegrams of the normal telegram traffic. The state of the control task can be stored as a data element, for example, in the form of a numerical value or an enumeration, in the payload structure 100 of the normal telegrams. In this case, the standby server unit 3 can easily determine the state of the control task and thus of the machine on which the control task is executed.

[0087] Furthermore, the state of the control task of standby server unit 3 can also be determined within the scope of the data reduction step D on the basis of a combination of an evaluation of the data values ​​of the relevant data elements of the currently present normal telegram and the state information continuously transmitted from the main server unit 2 to the standby server unit 3.

[0088] Based on the state of the control task determined by the backup server unit 3 during the data reduction step D, a failure operating mode is selected from a plurality of failure operating modes from a repository 310 during a selection step A.

[0089] For the selected failover operating mode, an assigned set of default values ​​is used to replace the optional data elements in the failover telegrams discarded by the standby server unit 3. In failover operating mode, the standby server unit 3 generally uses fewer of the machine's sensors and actuators, for example, to enable the use of a smaller server unit and / or a simple or robust control program code. The default values ​​make it possible to integrate machine sensors or actuators into the process image in failover operating mode that are not used by the standby server unit 3. The failover telegrams provided by the standby server unit 3 must also have the same telegram length as the normal telegrams in order to execute telegram traffic on fieldbus 1.

[0090] In the failover operating mode, control is then taken over by the standby server unit 3. As part of a standby control process E, the standby server unit 3 generates failover telegrams. In the first failover telegram, the data values ​​of the relevant data elements of the currently available normal telegram are used for the relevant data elements, and predefined default data values ​​are used for the optional data elements. The failover telegrams thus comprise the additional payload structure 101 and a default data structure 102. Additionally, the failover telegrams can also contain an additional data structure 103 with data elements for local results of the failover operating mode.

[0091] The client units 5 extract the output data assigned to the respective client unit 5 from the further payload structure 101 and, if applicable, the further data structure 103 from the failure telegrams sent on the fieldbus 1 by the standby server unit 3 in order to execute a local client unit process with the output data. The data determined in the local client unit process is then entered by the client units 5 into designated areas in the failure telegrams circulating on the fieldbus 1 and transmitted back to the standby server unit 3. The standby server unit 3 then uses the transmitted data as input data for the next failure control process cycle.

[0092] In parallel to controlling the machine in the failure operating mode, the backup server unit 3 also monitors in an availability step V whether the main server unit 2 is ready for operation again and additionally signals that the normal operating mode for the machine can be resumed.

[0093] If the standby server unit 3 determines the operational readiness of the main server unit 2 in the availability step V, the standby server unit 3 then continuously transmits the relevant data elements of the further payload structure 101 of the failure telegrams to the main server unit 2 in a handover step H, even if the main server unit 2 is not available.

[0094] If the main server unit 2 also signals that normal operating mode for the machine can be resumed, a restart step R is then executed by the main server unit 2. The restart step R can be initiated externally, for example by the operating personnel. Alternatively, the restart step R can also be triggered internally, for example by the backup server unit 3. Normal operating mode is then resumed by the main server unit 2. In the payload structure 100 of the first normal telegram, further default values ​​specified for the main server unit 2 and / or the last known data values ​​from normal operating mode can be used for the optional data elements of the default data structure 102 of the failure telegrams.

[0095] As a concrete example, a 2-axis machine is considered whose first and second axes are coupled via software. The two axes would mechanically destroy each other if they were not coordinated at all times. In the event of a failure of the main server unit 2, the backup server unit 3 can then, for example, shut down the machine in failover mode.

[0096] The selection of the failure operating mode is made via a "simple state" status information, which is continuously delivered as part of the normal telegrams from the main server unit 2 to the standby server unit 3 during the synchronization step S.

[0097] If a failure of the main server unit 2 is detected by the backup server unit 3 during the monitoring step U and the evaluation step B, the backup server unit 3 then discards irrelevant values, such as the machine's temperature values, in the data reduction step D. The data reduction retains, as an additional payload structure, the "simple state" status information and all relevant values ​​regarding the axes, coupling state, velocity, and position.

[0098] Subsequently, in selection step A, repository 310 is scanned for a suitable failure mode. The "Simple State" status information has the value "Production," and the relevant values ​​are "the first and second axes are coupled" and "the first axis has a position between 100 and 200." From repository 310, the "Uncouple and Power Off" mode is selected as the failure mode for standby server unit 3.

[0099] Since temperature measured values ​​and temperature control values ​​of the cooling elements are no longer relevant in the "decouple and switch off" failure mode, default values ​​"0" are used instead in the process images of the failure telegrams, which are stored in repository 310 for the "decouple and switch off" failure mode.

[0100] If, in the selection step A for determining the appropriate failure operating mode, the "Simple State" state information has the value "Production" and the relevant values ​​are "the first and second axes are not coupled" and "the first axis has a position between 100-200", then the "brake-and-power-off" operation mode is determined from the repository 310 as the failure operating mode for the standby server unit 3.

[0101] In the "brake and switch off" failure mode, the cooling elements in the failure telegrams are set to a specified temperature with a fixed default value, which is stored in the repository 310 under the "brake and switch off" failure mode, but are no longer regulated.

[0102] However, if the "Simple State" status information has the value "Waiting for Production" during selection step A for determining the appropriate failure mode, the "Simple Switch-Off" mode is selected from repository 310 as the failure mode. The relevant values ​​for the two axes or their positions are not taken into account. As with the "Decouple and Switch-Off" failure mode, temperature values ​​are not considered in the "Simple Switch-Off" failure mode, i.e., they are assigned the default value 0.

[0103] In the event of a failure of the main server unit 2, many processes cannot simply be shut down, but must be brought into a safe operating state that prevents the machine from being destroyed. An example of this is a concrete plant where the reactor must be kept in stirring mode at all times, as the reactor would become unusable after the concrete hardens.

[0104] In normal operating mode, backup server unit 3 receives all normal telegrams exchanged between main server unit 2 and client units 5 in the concrete plant. If backup server unit 3 detects a failure of main server unit 2 in monitoring step Ü and evaluation step B, backup server unit 3 performs a data reduction step D, in which all measured values ​​from the concrete plant are discarded, except for the fill level.

[0105] Only one failover operating mode, "emergency operation," is then provided for the concrete plant. In fallback control process E, the fallback server unit 3 regulates the agitator to a constant speed when the reactor fill level is "not empty." Furthermore, all valves are closed and the operating mode is set to "Manual." An alarm is also triggered indicating the "Manual" operating mode.

[0106] It is also conceivable that the backup server unit 3, in failure mode, allows a machine to continue production in a suboptimal manner, for example, with lower throughput or higher scrap, because technologically highly sensitive control algorithms can only be executed on the main server unit 2, possibly also because special hardware is required for this. Thus, the main server unit 2 can execute machine control based on machine learning. However, the backup server unit 3 then forgoes machine learning and only performs traditional machine control. Reference symbol

[0107] Fieldbus Main server unit Backup server unit Distributor Client unit (of a machine) Further fieldbus Main data bus Backup data bus 5-1 first client unit 5-2 second client unit 5-X Xth client unit 5-N last client unit 20 Transmitting / receiving device of the main server unit 21 Control device of the main server unit 22 Data connection of the main server unit 30 Transmitting / receiving device of the backup server unit 31 Control device of the backup server unit 32 Data connection of the backup server unit 40 Main server transmitting / receiving device 41 Backup server transmitting / receiving unit 42 Client transmitting / receiving device 43 Switching device 44 Data connection of the distributor 50 first transmitting / receiving device 51 second transmitting / receiving device 52 Processing device 53 internal Data connection of the client unit 61 first communication path 62 second communication path 71 first unidirectional communication path 72 second unidirectionalCommunication path 81 third unidirectional communication path 82 fourth unidirectional communication path 100 payload structure 101 further payload structure 102 default data structure 103 further data structure 201 first transmitting unit TX 202 first receiving unit RX 301 second transmitting unit TX 302 second receiving unit RX 310 repository 401 third transmitting unit TX 402 third receiving unit RX 411 fourth transmitting unit TX 412 fourth receiving unit RX 421 fifth transmitting unit TX 422 fifth receiving unit RX 501 sixth transmitting unit TX 502 sixth receiving unit RX 511 seventh transmitting unit TX 512 seventh receiving unit RX S synchronization step Ü monitoring step A selection step B evaluation step D data reduction step E substitute control process V availability step R Restart step H Handover step

Claims

1. An automation system comprising a plurality of bus subscribers which are connected to one another via a field bus (1) in order to exchange telegrams having a predetermined data structure between the bus subscribers, wherein the plurality of bus subscribers comprises a main server unit (2), a substitute server unit (3) and at least one client unit (5), wherein in a normal operating mode, the main server unit (2) and the client unit (5) exchange normal telegrams having a predetermined user data structure, wherein the substitute server unit (3) is embodied to receive the normal telegrams exchanged between the main server unit (2) and the client unit (5), wherein the functionality of the main server unit (2) is continuously monitored and then, if a failure event of the main server unit (2) is detected, the substitute server unit (3) is embodied to activate a failure operating mode, wherein in failure operating mode, the substitute server unit (3) and the client unit (5) exchange failure telegrams, characterized in that in the failure telegrams, the predetermined user data structure of the normal telegrams is divided up into relevant data elements and optional data elements, and the substitute server unit (3) is embodied to use the data values of the relevant data elements of the currently present normal telegram for the relevant data elements of the first failure telegram and predetermined default data values for the optional data elements of the first failure telegram.

2. The automation system according to claim 1, wherein the client unit (5) comprises a modified functional scope in the failure operating mode compared to the normal operating mode.

3. The automation system according to claim 2, wherein the functional scope of the client unit (5) provides a secured state of the client unit (5) in the failure operating mode.

4. The automation system according to any one of claims 1 to 3, wherein a control program code of the substitute server unit (3) differs at least in parts from a control program code of the main server unit (2).

5. The automation system according to any one of claims 1 to 4, wherein the substitute server unit (3) comprises a repository (310) having a plurality of failure operating modes, wherein the substitute server unit (3) is embodied to select the failure operating mode from the plurality of failure operating modes based on the data values of the relevant data elements of the currently present normal telegram and / or of a status information continuously transmitted from the main server unit (2) to the substitute server unit (3) upon activation of the failure operating mode.

6. The automation system according to any one of claims 1 to 5, wherein, when the substitute server unit (3) detects a restoration of operability of the main server unit (2) after the failure of the main server unit (2), the substitute server unit (3) is embodied to transmit the relevant data elements of the failure telegrams to the main server unit (2).

7. The automation system according to claim 6, wherein for reactivating the normal operating mode, the main server unit (2) is embodied to use the data values of the relevant data elements of the last failure telegram transmitted by the substitute server unit (3) for a first normal telegram.

8. The automation system according to any one of claims 1 to 7, wherein the substitute server unit (3) is embodied to assume a failure of the main server unit (2) in the event of a predetermined deviation in behavior and / or from the normal state of the main server unit (2).