Method for consistent data transmission

p0001The invention relates to a method for transmitting messages according to the preamble of claim 1.

p0002Such, operating according to the token passing principle method is known eg from H.-G. Goehring, F.-J. Kauffels, "Token Ring: Principles, Strategies, Perspectives", DATACOM-Verlag Lipinski, 1990, in particular section 2.4 known.

p0003There are a number ring based protocols that employ the token passing principle, known as token protocols. They were for various LAN bus standardized (IEEE802.4 / token bus, IEEE802.5 / Token Ring, ANSI X3T9.5 / FDDI). The methods are based on a token, a special bit pattern which is used for the bus access control. The token circulates in a logical or physical ring that is established between the individual subscribers.

p0004However, these protocols do not ensure data consistency in distributed systems with decentralized data storage in case of errors or failures of system components; ie when using this method is not guaranteed that all participants after failures or reconfigurations due to outages same level of information regarding own transmitted messages. but data consistency is the dominant requirement for the systems under consideration (comp. other versions). Furthermore, the protocols prove in transmitting messages short length as very inefficient (Token Ring: each message must complete token round cover until the next station is allowed to send; token bus: separate transmission and receipt of each message and each recipient ). In the systems considered is the same message generally transmitted to multiple recipients (multicast transmission). Existing token protocols allow only one unconfirmed multicast transmission; acknowledged transmission is only possible unicast (sent to only one recipient) and requires a separate confirmation phase. In addition to these fundamental problems more, protocol-specific disadvantages are present, for example, permutations of the sequence of messages transmitted or the lack of support for bus redundancy.

p0005This known ring-based methods can not meet the essential requirements that result in an application in industrial control systems.

p0006The DE-C2-40 10 266 known methods for secure information transfer, for example in the implementation of the Ethernet Network / Broadcast Token Bus (EN / BTB), the requirements also fulfilled not in full screen. The transmission is secured, but not consistent. So in this process permutations of the order as well as duplicates of messages during outages / reconfigurations are possible. All information is transmitted in the broadcast, this results in the use of modern computer technology to a relatively high computational load. EN / BTB requires programmable (intelligent) communication controller; Modern computers are equipped exclusively with but not intelligent controllers. EN / BTB does not support the use of standardized protocols.

p0007The typical structure of a control system, as well as the requirements for such a control system or to a fact-used transmission method is explained with reference to FIG. 1.

p0008<b>Fig. 1</b> schematically shows the structure of a control system comprising a plurality of computer components, such as front-end processor (VR) to the process connection, the master computer (LR) to process instrumentation and control basic functions, which are known as SCADA functions, workstation computer (BR) for process visualization and additional computers for editing optional secondary functions (SF). The computers are connected via a local area network (LAN), Ethernet typically coupled. To increase the availability of the overall system are important computer function (in the picture: VR and LR) executed and the LAN bus redundant. The computers operate on a respective locally held, continuously updated process image (decentralized data storage). Change data are sent as messages. Because of the distribution and redundancy of functions and data sets, complex data flows arising in the distributed system.

p0009The essential requirements for such control systems are high availability, short, guaranteed response times and consistency of data collections.

p0010Data consistency is a prerequisite for the proper operation of the control systems. It is trivial in the faultless case, but requires at precipitating / reconfigurations in the system-specific measures for the seamless continuation of the message exchange. This results in very high demands on the communication in distributed control systems; they include:<ul><li>Message exchange without loss, corruption, duplication and exchange of information (management consistency). Interchange refers to a sender's messages, the so-called FIFO order.</li><li>Messages to multiple recipients must be transmitted to all recipients or not (Atomaritätsprinzip).</li><li>Transmission of messages in each sequence identical to all recipients (total ordering of messages).</li><li>Avoiding Überholeffekten of origin information and derived information (causal ordering of messages).</li><li>Fast, deterministic transmission of messages. </li><li>Fast failure detection of computers and LAN bus through constant mutual surveillance.</li><li>In case of failure of computers automatic carve the same. From the message traffic</li><li>In case of failure of the LAN bus Automatic switching to redundant LAN.</li><li>Low LAN and computer-load of a communication.</li><li>Data exchange between different hardware and software computers.</li></ul>

p0011Data consistency comprises the first four requirements for message transfer. Issues related to the management consistency caused by transmission errors or failures of bus or receiver. The Atomaritätsprinzip is affected by the failure of the source of information itself. An exchange of messages (total and causal order) occurs in indeterministischem time behavior in the system, eg for reconfigurations or message repetition due to outages or transmission faults.

p0012In distributed computer systems, especially when using the UNIX operating system, the client / server approach is used for data exchange. This concept is tailored to a centralized data storage and systems without specific real-time requirements, it does not meet the above requirements. Required communication is by the producer / consumer principle (producer / consumer principle). The standard TCP / IP, UDP / IP or ISO / OSI protocols are aligned to the client / server concept, their properties are not the problem described adequately. Nevertheless, their use for reasons of cost and for communication between computers of different types is necessary.

p0013The conventional use of these protocols - with implementation of communication links between distributed processes in accordance with a predefined by the application structure (logical point-to-point connections) - has serious disadvantages. This applies particularly to the prevailing, connection-oriented TCP / IP protocol or in a similar way for ISO / OSI protocols. The following reasons can be cited:<ul><li>Single transmission of messages leads using conventional non-intelligent communications controllers to high transfer costs (context switch and protocol processing in the host). To reduce the computer and LAN load a batch transmission of messages with combined time / quantity control is necessary.</li><li>The Informationsselektierung, ie the choice of transferring to the recipients to messages occurs at the transmitting end in standardized protocols. The transmitter performs each recipient an update list, this leads to additional computational load.</li><li>Standardized protocols allow only directed a confirmed transmission. This results in the considered systems to a multiplier effect for packing and transferring messages: In larger control systems each message is repeatedly packaged and transmitted over the bus. With redundant transmitter has been executed in addition to the transmission to the receivers each connection is to synchronize separately with the slave computer.</li><li>Automatic monitoring of communication connections is not part of the TCP specification, and thus not present in each protocol version. The configuration of the monitoring cycle (default: 2 hours) is also not possible for each protocol version.</li><li>In mutual monitoring of the computers over disconnection in case of error (timeout) adjusting the timer to the specific time requirements is not possible for all protocol versions. TCP / IP requires a minimum period of 100s up to being disconnected, the setting of smaller values ​​is not standards compliant. As a solution for mutual monitoring remains only an additional (redundant) confirmation mechanism at the application level with appropriate overhead.</li><li>Due to the directional transmission results in an enormous joint effort in the system. Each computer to be coupled to each other. With redundant LAN bus connections via both buses are to operate. For example, a mid-control system, consisting of 8 computers and redundant LAN bus requires 2x8x7 = 112 full duplex and 224 half-duplex links.</li><li>The system structure is programmed into the software and parameterized (semantics: "Send message <i>at</i>"" Receive message <i>from</i>"). The implementation proves to be complicated, especially the error processing.</li><li>Because of the structure depending on the software itself repercussions arise in case of failure by the necessary producer / consumer principle.</li><li>Standardized protocols do not allow automatic switching to a redundant bus in case of failure of the LAN bus.</li><li>Failures / reconfigurations in the system lead to loss of data in the log buffers. This requires additional buffering of the transmitted data at the application level.</li><li>Data consistency requires multiphase transmission concepts. These are expensive to implement (high time and effort messages) and require the control of the timing of the transfer. TCP acknowledgments can not be evaluated for the realization of 2-phase concept, it is an additional confirmation mechanism at the application level necessary.</li><li>Total and causal ordering of messages requires in conventional use of standardized protocols expensive measures, such as message histories.</li></ul>

p0014So Standardized communication protocols do not meet with the conventional use of the requirements to control systems.

p0015Proceeding from this, the present invention seeks to provide a method for consistent messaging that meets the above requirements, with the simultaneous application of standardized communication protocols.

p0016This object is achieved in a method according to the preamble of claim 1 by its characterizing features.

p0017The inventive process is in three basic variants are realized, namely a called first variant Ring Multicast (R-MC) process and a called second variant datagram multicast (D-MC) method, which in turn - depending on the access method - two versions (D-MC / Z, D-MC / S) is realized.

p0018The process variants - hereinafter also briefly referred to as process - contain partly different, partly corresponding features as indicated in claim 1 and described below.

p0019In the process of ring-Multicast (R-MC), a token for the message transport, for controlling the transmission and access for mutual monitoring of the computers is used (data token).

p0020In the process datagram multicast with access controlled message transmission (D-MC / Z) is a token to control the transmission access, to exchange confirmation and order information as well as for mutual monitoring used (control token). The communication itself is performed in token possession in physical Broadcast or Multicast with datagrams.

p0021In the process datagram multicast with spontaneous communication (D-MC / S) is a token to exchange confirmation and order information as well as for mutual monitoring used (control token). The communication takes place spontaneously, regardless of the position of the token, the physical Broadcast or Multicast with datagrams.

p0022The process D-MC / Z and D-MC / S are also referred to as a datagram method or datagram-oriented method. Acknowledgment, sequence and status information are summarized below under the term control information.

p0023In the process of ring-Multicast (R-MC) is a logical multicast concept. The datagram-oriented method (D-MC) can be realized both in the physical as well as multi-in broadcast. The following is not a distinction between multicast and broadcast, there is the more general term of multicast used.

p0024Advantageous embodiments of the method result from subclaims and the following description of the invention.

p0025The process variants are in their basic structure similar and thus equivalent, as each of the process meets all the requirements to transport messages without restriction. In addition, each of the methods has characteristic properties in comparison with the other. These features come at a process-realization, ie to carry under specific conditions; they are explained in the following process description. The methods of the invention are not bound to any standard. An advantageous embodiment is possible on the basis of standardized LAN bus systems and communication protocols. Existing sub-functions can be used, for example, CRC checksum of standardized protocols and collision detection with automatic repetition when using an Ethernet LAN (IEEE802.3). Standardized protocols are used in a problem-specific manner. This makes it possible to fulfill the requirements to control systems and to use the principle advantages of standardized protocols, while avoiding the problem described points. An implementation based on standardized protocols will be described in an exemplary embodiment.

p0026The method Ring Multicast (R-MC) is a pure ring concept. The token is used for message transmission, the control of the bus access, the sequencing of the message sequence and mutual monitoring. The token length is dynamically adapted to the current volume of messages. The transfer of the token can be carried unconfirmed, since each participant can be checked by monitoring the next token reception circulating the token (implicit acknowledgment mechanism in the ring). The method Ring Multicast is tailored to small and medium control systems. According to an advantageous embodiment Headlines in blocks in token transferable.

p0027The datagram-oriented method (D-MC) messages are transmitted in the physical multicast. According to an advantageous embodiment, messages are grouped together in blocks and transmitted as datagrams. The datagram transmission itself is unconfirmed. The token is used to transfer control information, ie confirmations and order information to the transmitted message blocks and mutual monitoring. About the control token a confirmed transmission of message blocks is implemented, there is a mechanism with a negative acknowledgment to the application: Rendered message blocks are marked as sent from the sender in the token, the other participants consider the preservation of the message blocks and contribute non-receipt a negative acknowledgment in token. In this case, the sender must retransmit.

p0028When the controlled-access method (D-MC / Z) is passed the token in the token. In the process of spontaneous transmission (D-MC / S), all stations at any time authorized to transmit, regardless of the current position of the control token.

p0029The datagram method aimed at large control systems with high data volumes. Due to the transfer in the physical multicast results in comparison to the ring multicast concept (R-MC), a reduction of the transmitting and bus load. The token comprises only control information, ie the length and the turnaround time can be reduced. Furthermore, the communication load is highly asymmetrical in the considered systems. All process data is performed on the host computer and transmitted by it to the other computer. The datagram-oriented methods are adapted to these stressful situations. Only participants with existing transmission data through a multicast transmission. At very high data volumes (D-MC / S) are more datagram transmissions possible during a token circulation in the process of spontaneous transmission.

p0030All three alternatives guarantee data consistency in case of errors in the distributed system. This property is based upon compliance of the token position with the transmission status of messages in the system. In the process of ring-multicast transmission status messages is reflected directly by the token. The datagram-oriented method of transmission level is represented by the run in the token control information messages transmitted block (s): Transferred messages blocks from the transmitter for Token-receipt registered with their ID in the token, released by the receiver until token obtaining this identifier, ie the token to the current transmission state in this process reflects.

p0031In token continuous, incremented by each sender sequence number is entered. The token is used for fault detection and localization. Given the coincidence of token position and transmission status can be reconstructed exactly in case of failure on the identification of the last valid token position and the current transmission status of each participant. This enables the seamless continuation of the transmission while maintaining the leadership consistency. The Atomaritätsprinzip is due to the annular transfer of useful and control data, ie the transmission of only a receiver satisfies in principle. Because of Serialisierungseffekts the token respect of transmitted messages (R-MC) or the control information transmitted message blocks (D-MC), the message transfer with FIFO order, sporty and causal order.

p0032Defects participants are automatically divided, the message transport occurs at the application level and in case of failure without reaction. In another embodiment, an automatic bus switching are provided with interference in the communication system and to maintain data consistency. Advantageous embodiments of the fault tolerance measures are explained in reference to an embodiment.

p0033By the use of a token protocol, the methods have a stable and predictable timing. This also applies to the process D-MC / S, which operates collision-prone. The number of transmissions per token rotation is limited in this method, for example, 20% of maximum load in carrying out the process on the basis of an Ethernet LAN. Significant delays due to collisions are avoided.

p0034The methods of the invention allow a confirmed multicast transmission. This, and the use of a combined procedure for mutual monitoring and the exchange of messages, acknowledgments, and order information as well as the block transmission of messages leading to a significant reduction in the LAN and computer load, the protocol complexity and implementation effort compared to existing concepts.

p0035The three methods of the invention are described in greater detail with reference to embodiments.

<b>Embodiments of the procedures</b>

p0036The embodiments were implemented as communication systems in a distributed computer system. The systems are based on the standard UDP / IP protocol. UDP / IP connectionless, it allows unconfirmed transmission of datagrams in the Union, multicast and broadcast. As bus system an Ethernet LAN (IEEE802.3) is used. The underlying standardized hardware and software includes automatic safeguards against data corruption (CRC checksum) and collision handling. When detected collisions automatic frame repetition occurs. For these reasons, collisions or errors due to corrupted data will not be further considered.

p0037The exchanged information units have, depending on the amount of data greatly different lengths (ranging from 10Byte to 30KB). Large units of information to be fragmented by the underlying network and protocol layers, that is divided into smaller units to be transmitted. Each fragment is expanded with protocol-specific information. In order to create a unified, independent of the length of the information units and of the underlying protocol and network layers transmission mechanism, and for the treatment of loss of individual fragments of larger pieces of information, a block-oriented transmission mechanism was implemented as part of an advantageous embodiment. The information exchanged are transmitted as contiguous blocks, the block transfer works atomically. In case of faulty transmission or loss of block fragments a block of information is completely discarded.

p0038The following description will be made separately for the ring-to-multicast method, and for the datagram method. The latter are similar, they are described together, any differences are pointed at respective location.

p0039Reference is made to the following drawing figures with respect:<dl id="dl0001" compact="compact"><dt>Fig. 1</dt><dd>Construction of a control system,</dd><dt>FIGS. 2A to 2F</dt><dd>Transmission sequence when Ring Multicast (R-MC) process,</dd><dt>Fig. 3</dt><dd>Data token structure at R-MC,</dd><dt>FIGS. 4A-4F</dt><dd>Transmission sequence when datagram oriented process with access controlled transmission (D-MC / Z)</dd><dt>Fig. 5A to 5F</dt><dd>Transmission sequence when datagram oriented method with spontaneous transmission (D-MC / S)</dd><dt>Fig. 6</dt><dd>Control token structure in D-MC,</dd><dt>Fig. 7</dt><dd>News Block building at D-MC.</dd></dl>

p0040The explanation of the embodiments are each divided into a description of the timing, explanations of protocol properties and a description of the exchanged information units. The general description is given for a distributed system consisting of three participants (T1-T3). The timing is shown in several stages (AF).

<b>1. Ring Multicast (R-MC)</b>

<b>1.1 Description</b>

p0041<b>FIGS. 2A to 2F</b> show the timing of the transfer is no fault on the method Ring Multicast (R-MC). Initial state is the circulation of an empty data token T (<b>FIG. 2<i>A</i></b>). Participants T1 has to be transmitted messages N1, he enters them in the token is received in the token and passes the token T to the successor T2 further (<b>FIG. 2<i>B</i></b>). The successor T2 holds messages N2 ready for transmission. It copies upon receipt of the token T its contents in a local receive buffer, adds its own transmission data N2 to the token end and reaches the token (<b>FIG. 2<i>C</i></b>). After the passing of the token are selected from the local copy of the token messages for the application (in Example messages N1 subscriber T1). For participants T3 the procedure is similar to T2 (<b>FIG. 2<i>D</i></b>). After one complete revolution of the token T subscriber deletes T1 their own messages N1 from the token, copies the token content in the local receive buffer, adds new data N1 'the token end to, presents the token to station T2 on and selects messages of other participants (<b>FIG. 2<i>e</i></b>). Participants T2 handles the token T analogous to subscriber T1, in the example he has no more messages to send (<b>FIG. 2<i>F</i></b>).

p0042Each participant can Token owned news arbitrary number and length in token Enter (variable token length).

<b>1.2 Method Cross characteristics (all three concepts)</b>

p0043Based on the concept Ring Multicast can explain some cross-process features, which also apply to the datagram concepts explained below:<ul><li>A ring-structure can be initiated by each subscriber.</li><li>Stations must first be integrated into the ring, to participate in the message exchange can. For this purpose, a registration of the newly integrated station with its predecessor is necessary.</li><li>The transfer of all information units are block-oriented.</li><li>The token will be sent to all participants with equal frequency, ie, there is no higher priority for certain participants.</li><li>Information analysis of the states of followers and LAN bus is transferred asynchronously to the token.</li><li>Information rerecording a participant is transferred asynchronously to the token.</li><li>Each station monitors its successor, defective stations are divided from its predecessor. The reconfiguration is carried out without affecting the data consistency.</li><li>Should the bus an automatic switchover to the redundant bus. The reconfiguration is carried out without affecting the data consistency.</li></ul>

<b>1.3 protocol properties: R-MC</b>

p0044<ul><li>Comparisons "method General properties".</li><li>Payload will ring out in the system (directed transfer of the data token).</li><li>The data token has variable length.</li><li>Each participant may own messages in the token register with token receipt.</li><li>There is no selected station in the system during the reconfiguration is the station with the last valid data token temporarily to Ringmaster.</li><li>Collision-free data traffic in normal operation.</li><li>Reception data is selected and released by the token passing.</li></ul>

<b>1.4 Exchanged information units</b>

p0045In addition to the previously discussed data token further information units are used, which are needed for error handling and the integration of new participants, as will be explained in more detail below. The units of information are listed below.

Data token

p0046Contains the messages to be transmitted, according to each participant in the ring.

LinkCheck request

p0047Request a ring participant to his successor to the subscriber and bus monitoring.

LinkCheck Acknowledge

p0048Answer a ring participant on a link check request.

Init token

p0049Does the system state information and the sequence number of the sender. The sender divides his successor with the local system status information and applies the same as ringmaster.

Configuration Token

p0050Does the system state information and the sequence number of the ring master. The ring master informs the other ring participants a modified ring configuration (after re-recording of a subscriber or failures).

Enter Request

p0051Participants will initialize ring or be included as a ring participants. Information is sent from the participants willing to receive them at the desired predecessor.

Leave token

p0052Participants shall inform the other that he wants to leave the ring.

p0053All information is transmitted unconfirmed. Token Information is passed to all participants in the ring. The other pieces of information are exchanged between two participants, the transfer is performed asynchronously to the token.

<b>1.5 Block Structure</b>

p0054<b>Fig. 3</b> exemplifies the structure of the data token for the process of ring-Multicast (R-MC). The header is in accordance with the inventive procedures detailing how token length, the block sequence number of the token and the block type (here: data token) followed by the data areas of each ring subscriber, each variable length. Each data field includes a subscriber-specific header by specifying the subscriber and the data field length and follow the news of this participant. The message in turn consist of a header and the data itself. The message header consists of a selector for message identification and the indication of the message length.

p0055The registered in Fig. 3 in the data areas participant names K, K + 1, and so on until K-1 are to be understood that K is any subscriber, eg subscriber T2 (see FIG. FIGS. 2A-2F) may be, in which case the subscriber K + 1 of the participants is T3, and participants K-1 of the participants is T1. In data token thus are in this example, in the last place the data of the subscriber T1.

p0056are not drawn by underlying protocol and network layers added information (for fragmentation partly multiple): Ethernet, IP and UDP headers.

p0057All information units are block-oriented exchanged between protocol layers.

p0058Init and Configuration token containing system status information in the data portion. In the asynchronous information units in the data area is the identification of the sender or the data area is empty, ie, it is provided only the block header.

<b>2. Datagram Multicast (MC D / Z and D-MC / S)</b>

p0059The datagram-oriented method (D-MC) data transmission in physical multicast the datagram services of the UDP / IP protocol is. Modern operating systems allow addition to the transmission in the physical multicast the triage of frames received by hardware mechanisms.

p0060The datagram transfer occurs block-oriented and unconfirmed. To realize a secure transmission, the definition of a uniform order of receipt, and for mutual monitoring a control ring between the individual communication subscribers is established. In the process datagram multicast with access controlled transmission (D-MC / Z), the multicast transmission of user data only in possession of the control token. In the process of spontaneous transmission (D-MC / S) carried out user data transmission and exchange of the control token asynchronously, ie the transmission of a message block is possible at any time.

p0061A message block may include a message of any length and number.

<b>2.1 Description of the method</b>

p0062The timing of the transmission of the datagram-oriented process with access controlled transmission (D-MC / Z) is in the <b>FIGS. 4A-4F</b> shown. Initial state was the circulation of a blank check token T. subscriber T1 has to be transmitted messages N1 (<b>Fig. 4<i>A</i></b>). He leads the token is received, the datagram transmission in multicast through and transmits the control information K1 of the transmitted message block in a control field in a token (<b>Fig. 4<i>B</i></b>). The control panel includes the identification of the sender, a transmitter-related sequence number, and a global sequence number, which is assigned to the message blocks. The token puts forward a global sequence number with them. This is from the respective token owners increased for each transmitted message block associated with the transmission source sequence number and registered together with these in the control panel. By assigning the global sequence number all message blocks are provided with a unique and continuous identification. This identifier allows for a standardized order of reception of transmitted message blocks.

p0063Then the token to the successor T2 is passed (<b>Fig. 4<i>C</i></b>). The receiver stations leave messages received blocks first in the receive buffers without releasing it for use. The successor to T2 also holds messages N2 is ready for transmission, it transmits this token in obtaining the multicast (<b>Fig. 4<i>D</i></b>) And carries the token identifier K2 of the message block N2, a control panel. Subsequently, it checks whether the transmitted control token as a labeled message blocks (K1) in the receive buffer are present. If this is the case, received message blocks (N1) are rated according to the global sequence number and released for processing (<b>Fig. 4<i>e</i></b>). If a labeled in the control token as transmitted message block is not received, a negative acknowledgment is entered in the control panel of the message block, the sender has to perform the transfer again. In addition, checks the owner of the control token if its own transmission data of the last token cycle received from all participants. If so, the data block in the transmission buffer and the entry in the control token is removed. If not (negative acknowledgment in the control panel), the transmission with the old sequence number is performed again. The global sequence number is also retained. This is necessary to detect at the receiving end duplicates and release redelivered message blocks with the correct order for the application.

p0064The sequence of processing is performed for the subscriber T3 and during further rounds analogous to the above description (<b>Fig. 4<i>F</i></b>).

p0065The assignment of a global sequence number to message blocks and their assignment via the token guarantees the total order of the message blocks and the message contained therein. The causal sequence of blocks and messages also results from the annular transfer of control information (Sequentialisierungseffekt).

p0066The <b>Fig. 5A to 5F</b> show the timing of the transfer in the process of spontaneous transmission (D-MC / S). Send willing participants, in the image T2, send their messages N2 spontaneously in multicast, asynchronous to the circulating control token (<b>Fig. 5<i>A</i>.<i>B</i></b>). Upon receipt of the control token participants T2 transmits the control information K2 of the transmitted message block N2 in a control field in a token (<b>Fig. 5<i>C</i></b>). The structure and the sequence of processing of received message blocks and the control token is identical to the procedure with access controlled transmission (D-MC / Z). After token processing this is passed on to the successor T3. Other asynchronous transfers of message blocks by any participant are possible at any time (<b>Fig. 5<i>C</i></b>).

p0067The release received message blocks takes place as in the controlled-access method in token-owned (<b>Fig. 5 <i>D</i>. <i>e</i>. <i>F</i></b>). The mechanisms for controlling the message sequence are also identical with those of the controlled-access method.

<b>2.2 protocol properties: D-MC / Z</b>

p0068<ul><li>Comparisons "method General properties".</li><li>Control information will ring out in the system (directional transmission of control token).</li><li>The control token has variable length.</li><li>The transmission authorization is controlled by the token. Each participant may send in token obtaining own message blocks as datagrams, and enter it in the token.</li><li>There is no selected station in the system during the reconfiguration is the station with the last valid control token temporarily to Ringmaster.</li><li>Collision-free data traffic in normal operation.</li><li>During the last token circulation received data blocks are sorted in the token is received and released to the application.</li><li>Data are transmitted in broadcast or multicast. </li><li>Confirmations, order information, system status information and bus access procurement are performed in the token.</li><li>The reception confirmation is in blocks. This is possible because it is ensured through the mechanisms of the block transfer that information units of any length are only transmitted in full (in case of loss of individual fragments blocks are completely discarded).</li></ul>

<b>2.3 protocol properties: D-MC / S</b>

p0069<ul><li>Comparisons "method General properties".</li><li>Control information will ring out in the system (directed transfer of the token).</li><li>The control token has variable length.</li><li>All stations are for transmitting user data (datagrams) authorized to transmit at any time. In token receipt last token cycle sent message blocks are entered in the token.</li><li>There is no selected station in the system during the reconfiguration is the station with the last valid control token temporarily to Ringmaster.</li><li>During the last token circulation received data blocks are sorted in the token is received and released to the application.</li><li>Data are transmitted in broadcast or multicast.</li><li>Confirmations, order information and system status information are performed in the token.</li><li>During a token circulation multiple transfers of data blocks are possible.</li><li>The reception confirmation is in blocks. This is possible because it is ensured through the mechanisms of the block transfer that information units of any length are only transmitted in full (in case of loss of individual fragments blocks are completely discarded).</li></ul>

<b>2.4 Exchanged information units</b>

(D-MC / Z and D-MC / S)

p0070In addition to the already explained message block (datagram) and control tokens are still used more pieces of information that are needed for error handling and the integration of new participants, as will be explained in more detail below. The units of information are listed below. The exchanged information is identical for both datagram method.

News block

p0071Contains the messages to be transmitted a ring-subscriber.

Control token

p0072Where the control information (confirmation, sequence and status information), according to each participant in the ring.

LinkCheck request:

p0073Request a ring participant to his successor to the subscriber and bus monitoring.

LinkCheck Acknowledge

p0074Answer a ring participant on a link check request.

Init token

p0075Does the system state information and the sequence number of the sender. The sender divides his successor with the local system status information and applies the same as ringmaster.

Configuration Token

p0076Does the system state information and the sequence number of the ring master. The ring master informs the other ring participants a modified ring configuration (after re-recording of a subscriber or failures).

Enter Request

p0077Participants will initialize ring or be included as a ring participants. Information is sent from the participants willing to receive them at the desired predecessor.

Leave token

p0078Participants shall inform the other that he wants to leave the ring.

<b>2.5 Block Structure</b>

p0079<b>Fig. 6</b> exemplarily shows the design of the control token for the datagram-oriented method (D-MC). The header according to the inventive method with information token length, the global sequence number, the block sequence number of the token and the block type (here: control token) followed by the control areas of each ring subscriber, each variable length. Each control area includes a subscriber-specific header by specifying the operator and the control area length and below the check boxes to the messages sent blocks of this participant. Each transmitted message block is associated with a control panel in the control token. A control panel consists of the details of the sender, the subscriber-specific sequence number and the global sequence number of the message block.

p0080The exemplary structure of a message block by the datagram-oriented method (D-MC) is in <b>Fig. 7</b> shown. The block header by specifying the block length, the identification of the sender, the block sequence number and block type (here: message block) followed by the message sender. These in turn consist of a header and the data itself. The message header consists of a selector for message identification and the indication of the message length.

p0081are not drawn by underlying protocol and network layers added information (for fragmentation partly multiple): Ethernet, IP and UDP headers.

p0082All information units are block-oriented exchanged between protocol layers.

p0083Init and Configuration token containing system status information in the data portion. The other asynchronous information units are constructed in accordance with the message block. Depending on the type of the information unit is in the data area, the identification of the sender or the data area is empty, ie, it is provided only the block header.

<b>3. Processing of faults / failures</b>

p0084The fault tolerance mechanisms for detection, localization and treatment of errors / failures in the system with respect to the safeguarding of data consistency and an uninterrupted system operation is of fundamental importance. The core feature of the process described is the compliance of the token object (monitoring) and the level of information of the individual participants. This allows the exact reconstruction of the level of information in case of failure and ensures data consistency.

p0085The measures for detection, localization and treatment of errors (error processing) are explained in reference to an embodiment; they are the same for all three methods of the invention.

p0086There are the following requirements for the error processing:<ul><li>Errors / failures are to detect and locate.</li><li>Failed computer should be excluded, when the bus transfer to the redundant bus is continuing.</li><li>The modified system status information is consistently transmitted to all (intact) participants.</li><li>The traffic is continuing by the subscriber with the data or control token last valid.</li><li>The error processing must be carried out quickly and maintain data consistency.</li></ul>

p0087Due to the unacknowledged transfer of information any errors or failures in the system lead to a loss of the token. A loss is recognized Timeout (token timeout). The error processing for a detected token loss is divided into several phases:<ul><li>LinkCheck phase,</li><li>Init token phase,</li><li>Configuration token phase.</li></ul>

p0088Participants who have encountered an error (token timeout) check the condition of the successor or the LAN bus by a link check request is transmitted to the successor. This is answered by intact followers with a link check-Acknowledge. On successful LinkCheck an init token is sent to the followers what these prompts in turn to consider the successor. If not successful LinkCheck the changed system status information (after several attempts) spun off the defective successor, entered in the init token. The init token is transmitted in this case, to the successor of the divested participant. This applies to simple errors in the system. When multiple errors init token is transmitted to the next intact nodes in the ring. The transfer of Init token principle precedes the Link Check stage.

p0089The init token phase serves the determination of the ring-subscriber with the last valid data or control token (Ringmaster). The Ringmaster is not statically fixed subscriber, he is temporarily in the event of an error, ie determined depending on the current transmission status. The Ringmaster is after error processing continues transmission of data or control token. To determine the Ringmaster the data or control token is provided with a sequence number, which is increased by each participant during the send process. While error processing is entered by each participant while sending an init token in this, the sequence number of the last sent data or control token, ie every participant "advertises" as possible Ringmaster. If an init token with a smaller sequence number received in the local sequence number of the last sent data or control token, so the received Init token is rejected, it will be an init token with its sequence number transmitted further. If a received Init tokens greater than the local sequence number, it will be further transferred (with possibly modified configuration). As a result of this algorithm only the init token Ringmaster remains. The Ringmaster recognizes itself as such through the complete cycle of its Init token. In Init token Ringmaster for a complete revolution is the current system configuration included (outsourced participants are removed from the list of active hosts). The ring master transmits in the subsequent phase this configuration with a configuration token to the other participants. After a successful round of configuration token of the data exchange will be continued by the Ringmaster with its data or control token. Information of an outsourced operator is removed from the respective predecessor in the Data or control token. This ensures that messages from all intact participants are received.

p0090If during error processing more errors occur, this is recognized by a token timeout. The error processing is restarted. The multiphase error processing with Init and Configuration token also allows tolerating multiple faults.

p0091The method described above for determining the temporary Ring Masters can be divided into the following characteristics:<ul><li>a) A Participant which has detected an error (token timeout) sent an init token with the sequence number of the last sent data or control token,</li><li>b) a participant who receives an init token, sent an init token with a sequence number, which is formed from the maximum value of the sequence number of the last sent data token and the sequence number of the obtained Init token,</li><li>c) a member who previously sent an init token and a token init with a sequence number obtained, which is smaller than the sequence number of the last shipped Init token, discards the received Init token,</li><li>d) a member who previously sent an init token and an Init token with a sequence number obtained, which is identical to the sequence number of the last shipped Init token (data or control token), recognizes himself as ringmaster, transmits the changed system configuration ring to all participants and then continues transmitting the data or control token last valid.</li></ul>