Abstract:
A highly reliable industrial control system is produced by opening multiple connections on a connected messaging network running a standard serial protocol. The two connections are used to transmit redundant data and include a reply message to the message producer. Errors in the messages or media failure may be detected using standard error detection codes, retry counters and deadman timers. Comparison of the data of the two messages can reveal other types of failure not apparent by these former techniques.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of provisional application No. 60/171,439 filed on Dec. 22, 1999. 
    
    
     STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
     BACKGROUND OF THE INVENTION 
     The present invention relates to industrial controllers used for real-time control of industrial processes, and in particular to high-reliability industrial controllers appropriate for use in devices intended to protect human life and health. “High reliability” refers generally to systems that guard against the propagation of erroneous data or signals by detecting error or fault conditions and signaling their occurrence and/or entering into a predetermined fault state. High reliability systems may be distinguished from high availability systems, however, the present invention may be useful in both such systems and therefore, as used herein, high reliability should not be considered to exclude high availability systems. 
     Industrial controllers are special purpose computers used in controlling industrial processes. Under the direction of a stored control program, an industrial controller examines a series of inputs reflecting the status of the controlled process and changes a series of outputs controlling the industrial process. The inputs and outputs may be binary, that is, on or off, or analog, providing a value within a continuous range. The inputs may be obtained from sensors attached to the controlled equipment and the outputs may be signals to actuators on the controlled equipment. 
     “Safety systems” are systems intended to ensure the safety of humans working in the environment of an industrial process. Such systems may include the electronics associated with emergency stop buttons, interlock switches and machine lockouts. Traditionally, safety systems have been implemented by a set of circuits wholly separate from the industrial control system used to control the industrial process with which the safety system is associated. Such safety systems are “hard-wired” from switches and relays, some of which may be specialized “safety relays” allowing comparison of redundant signals and providing internal checking of conditions such as welded or stuck contacts. Safety systems may use switches with dual contacts providing an early indication of contact failure, and multiple contacts may be wired to actuators so that the actuators are energized only if multiple contacts close. 
     Hard-wired safety systems have proven inadequate, as the complexity of industrial processes has increased. This is in part because of the cost of installing and wiring relays and in part because of the difficulty of troubleshooting and maintaining the “program” implemented by the safety system in which the logic can only be changed by rewiring physical relays and switches. 
     For this reason, there is considerable interest in implementing safety systems using industrial controllers. Such controllers are easier to program and have reduced installation costs because of their use of a high-speed serial communication network eliminating long runs of point-to-point wiring. 
     Unfortunately, high-speed serial communication networks commonly used in industrial control are not sufficiently reliable for safety systems. For this reason, efforts have been undertaken to develop a “safety network” being a high-speed serial communication network providing greater certainty in the transmission of data. Currently proposed safety networks are incompatible with the protocols widely used in industrial control. Accordingly, if these new safety networks are adopted, existing industrial controller hardware and standard technologies may be unusable, imposing high costs on existing and new factories. Such costs may detrimentally postpone wide scale adoption of advanced safety technology. 
     What is needed is a safety network that is compatible with conventional industrial controller networks and components. Ideally such a safety network would work with a wide variety of different standard communication protocols and would allow the mixing of standard industrial control components and safety system components without compromising reliability. 
     BRIEF SUMMARY OF THE INVENTION 
     The present invention provides high reliability communications over standard control networks by opening redundant “connections” under the connected messaging protocols of such standard networks and by adopting an echoing of messages sent that reveals to both message producers and message consumers failure of either connection. Dual connections thus serve in lieu of dual media traditionally used in such systems making the imposition of high reliability possible with existing network media. 
     Specifically, the present invention provides a method of establishing high reliability communication among components of an industrial controller some of which receive control signals from a controlled process, the components communicating over a standard network. The method includes the steps of establishing at least two redundant logical message producers associated with a given received control signal and opening a logical connection between each of the two logical message producers and two corresponding logical message consumers. Data, including a given received control signal, is transmitted on the connections from the logical message producers to the logical message consumers and after receipt of uncorrupted data at each logical message consumer, transmitting reply data including the given received control signal on the connection to the logical message producers. The logical message producers respond to an absence of an uncorrupted receipt of a transmission of reply data by entering a predetermined safety state. 
     Thus it is one object of the invention to provide for high reliability communications under standard connected messaging communications protocols. The redundant connections and reply messages provide resistance to undetected message corruption. 
     The uncorrupted reply data may be compared between the two logical message producers which may be responding to a failure of the reply data to match by causing the logical message producers to enter the predetermined safety state. 
     Thus it is another object of the invention to provide an indication to upstream devices of communications failure using a standard network, such as is normally realized in high reliability systems by complex wire routings from output to inputs. 
     Determining whether data is uncorrupted may use a cyclic redundancy code incorporated into the data and a function of the received control signal and/or a message sequence count to indicate a relative order of messages holding the transmitted data. 
     Thus it is another object of the invention to provide more sophisticated signal loss detection that may be provided with standard wiring to discrete relays but that is suitable for network use. 
     The method may include comparing uncorrupted messages at the two logical message consumers and responding to a failure to match by causing the logical message consumers to enter the predetermined safety state. 
     Thus it is another object of the invention to detect failures that are not manifest in the network transmission process or that arise outside of the transmission process from failure of input or output devices. 
     The two logical message producers and/or the two logical consumers may be in a single physical device having one physical connection to a standard serial network or the two logical message producers and two logical message consumers may each be in separate physical devices each having two physical connections to a standard serial network. 
     Thus it is another object of the invention to provide a high reliability communications system that is largely indifferent to the hardware used to implement the producers and consumers. 
     The method may include the step of transmitting a signal to the two logical message consumers instructing them to enter a predetermined safety state. 
     It is therefore another object of the invention to provide for a general broadcast of detected failure so that components of the system may react appropriately even if the failure is not directly detectable at those components. 
     The method may include the step of responding at the logical message consumers to an absence of an uncorrupted receipt of the data subsequent within a periodic interval by entering a predetermined safety state. 
     Thus it is another object of the invention to provide for an indication of media failure such as would affect both connections on a network without producing erroneous or mismatched redundant messages. 
     The foregoing and other objects and advantages of the invention will appear from the following description. In the description, reference is made to the accompanying drawings, which form a part hereof, and in which there is shown by way of illustration a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention, however, and reference must be made to the claims herein for interpreting the scope of the invention. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a perspective view of a simplified industrial controller using a standard serial communication network linking a central controller with remote input and output circuits and with a remote configuration terminal, such as may be used in the present invention; 
     FIG. 2 is a schematic block diagram of the control system of FIG. 1 showing redundant wiring from an input switch to the input circuit of FIG. 1, the input circuits having redundant components such as may process the signals from the input switch to send signals over the communication network to the controller of FIG. 1, the controller having redundant processors to send signals over the communications network to the output circuit of FIG. 1, the output circuit having redundant components to provide outputs to an actuator; 
     FIG. 3 is a fragmentary view similar to FIG. 2, showing an alternative configuration of the input circuit of FIG. 2 using conventional control input circuits without redundant components; 
     FIG. 4 is a fragmentary view similar to FIG. 2, showing an alternative configuration of the output circuit of FIG. 2 using conventional control output circuits without redundant components; 
     FIG. 5 is a representational view of the dual communication protocols provided by the present invention in which data is first encoded with a safety protocol and then with a network protocol to be compatible with the serial network; 
     FIG. 6 is a schematic representation of a data word transmitted over the standard serial network showing the embedding of safety formatting data with I/O data within the formatting provided by the standard serial network; 
     FIG. 7 is a graphical representation having time on the vertical axis and distance along the network on the horizontal axis, showing transmission of configuration messages to the input circuit, the controller and the output circuit, forming the foundation of the safety protocol of the present invention; 
     FIG. 8 is a figure similar to that of FIG. 7 showing the transmission of messages after the configuration process during a start-up and run-time phase of the network; 
     FIG. 9 is a block diagram of the industrial controller of FIG. 1 showing the division of communications between the input circuit, the controller and the output circuit into producer-consumer pairs such as provides redundant communication over a single network and the varied topologies of the implementations of FIGS. 2,  3  and  4 ; 
     FIG. 10 is a flow chart showing the principle stages of the safety protocol of initialization, start-up, and run-time; 
     FIG. 11 is a figure similar to that of FIG. 7 showing normal protocol operation under the safety protocol of the present invention during run-time; 
     FIG. 12 is a figure similar to FIG. 11 showing protocol operation with a corrupted producer message; 
     FIG. 13 is a figure similar to FIG. 11 showing protocol operation with a lost producer message; 
     FIG. 14 is a figure similar to FIG. 11 showing protocol operation with a corrupted acknowledgement message from the consumer; 
     FIG. 15 is a figure similar to FIG. 11 showing protocol operation with a lost consumer acknowledgement message; 
     FIG. 16 is a figure similar to FIG. 11 showing protocol operation with disruption of the connection between the producer and consumer; 
     FIG. 17 is a flow chart of a program executed by the producers of FIG. 9 in implementing the safety protocol; and 
     FIG. 18 is a flow chart of a program executed by the consumers of FIG. 9 in implementing the safety protocol of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The present invention can be part of a “safety system” used to protect human life and limb in the industrial environment. Nevertheless, the term “safety” as used herein is not a representation that the present invention will make an industrial process safe or that other systems will produce unsafe operation. Safety in an industrial process depends on a wide variety of factors outside of the scope of the present invention including: design of the safety system, installation and maintenance of the components of the safety system, and the cooperation and training of individuals using the safety system. Although the present invention is intended to be highly reliable, all physical systems are susceptible to failure and provision must be made for such failure. 
     Referring now to FIG. 1, an industrial control system  10  for implementing a safety system with the present invention includes a controller  12  communicating on a serial network  15  with remote input module  14  and remote output module  16 . The network  15  may be a standard and commonly available high-speed serial network including but not limited to: Ethernet, DeviceNet, ControlNet, Firewire or FieldBus. The network  15  may optionally include a bridge  17  translating between different of the above standard or other protocols. As will be understood from the following, the present invention may be easily adapted to bridge applications. 
     Input module  14  may accept input signals  18  (on like-designated lines) which are communicated over the network  15  to the industrial controller  12 . At the industrial controller  12  the signals  18  may be processed under a control program implementing a safety system (such as a machine lock-out or emergency stop) and further signals sent to the output module  16  which may produce output signals  20  (on like-designated lines) to an actuator  22 . 
     The input signals  18  may come from a switch  19  which may be any of a variety of devices producing safety input signals including but not limited to emergency stop switches, interlock switches, light curtains and other proximity detectors. The actuator  22  may be a relay, solenoid, motor, enunciator, lamp or other device implementing a safety function. 
     Also connected to the network  15  is a standard computer, which may be used as a configuration terminal  24  whose purposes will be described below. 
     Redundant System Hardware 
     Referring now to FIG. 2, the switch  19  may produce redundant signals  18   a  and  18   b  where signal  18   a  is, for example, from a first contact within the switch  19 , and signal  18   b  is from a second independent contact within switch  19 . The contacts may have the same logic (as shown) both being normally open (e.g., closed with actuation of a pushbutton  26 ) or may be inverted logic with one contact normally open and one contact normally closed. In either case, redundant signals  18   a  and  18   b  are generated so as to provide for higher reliability in the determining the state of the switch  19 . 
     The input module  14  may include redundant interface circuitry  28   a  receiving signal  18   a  and interface circuitry  28   b  receiving signal  18   b.  Alternatively, but not shown, interface circuitry  28   a  and  28   b  may each receive both signals  18   a  and  18   b  (for internal comparison) or may receive signals  18   a  and  18   b  from a single contact. The contacts, in generating signals  18   a  and  18   b,  may each be provided with a separate voltage from the input circuitry  28   a  and  28   b  or from a common voltage source (not shown). Other redundant variations on these wiring systems, known in the art, may also be used. 
     Each of the interface circuitry  28   a  and  28   b  may in turn provide signals to associated microcontrollers  30   a  and  30   b.  Microcontrollers  30   a  and  30   b  provide a computer processor, memory and a stored program for executing safety protocol programs as will be described below. Alternatively, or in addition, the safety protocol may be executed by safety protocol circuits  32  with which microcontrollers  30   a  and  30   b  communicate. In this case, the safety protocol circuits  28   a  and  28   b  may be application-specific integrated circuits (ASIC). As it is well known in the art to implement protocols through hardware or software or combinations of each, the term “protocol device” as used herein and in the claims should be understood to embrace generally any combination of software and hardware components implementing the indicated functions. 
     The microcontrollers  30   a  and  30   b  may communicate with each other through an internal bus  34  to compare signals  18   a  and  18   b  as will be described. 
     Microcontrollers  30   a  and  30   b  or safety protocol circuits  28   a  and  28   b  in turn connect to standard network protocol circuits  36   a  and  36   b  of a type well known in the art for handling the low level protocol of the standard network  15 . Typically, the standard network protocol circuits  36   a  and  36   b  are implemented by an ASIC whose implementation represents considerable development time and which cannot be easily modified. 
     The standard network protocol circuits  36   a  and  36   b  transmits signals from the input module  14  on the network  15  to be received at the controller  12  through a similar standard network protocol circuits  38   a  and  38   b.  These signals are processed by the standard network protocol circuit  38  and provided to redundant safety protocol circuits  40   a  and  40   b,  being similar to safety protocol circuits  32   a  and  32   b  described before. These safety protocol circuits  40   a  and  40   b  communicate with processors  42   a  and  42   b,  respectively, which include separate memory systems and control programs according to well-known redundancy techniques and which intercommunicate on internal bus  34 ′. Output signals generated by the processors  42   a  and  42   b  may be communicated back through the safety protocol circuits  40   a  and  40   b  to implement the safety protocol, as will be described below (or alternatively, the safety protocol may be handled by the processor  42   a  and  42   b ), and the output signals communicated to the standard network protocol circuits  38   a  and  38   b  for transmission again on network  15  to output module  16 . 
     Output module  16  may receive output data through a standard network protocol circuits  44   a  and  44   b  being similar to standard network protocol circuits  36   a  and  36   b  and  38   a  and  38   b.  The standard network protocol circuits  44   a  and  44   b  provide the data to safety protocol circuits  46   a  and  46   b,  which in turn provide them to redundant controllers  48   a  and  48   b.  As before, alternatively, the safety protocol may be handled by the controllers  48   a  and  48   b  instead. The controllers  48   a  and  48   b  communicate by internal bus  34 ″ and in turn provide signals to output interface circuits  50   a  and  50   b  which provide the output signals  20   a  and  20   b.  The output signals may be connected to the actuator  22  so that outputs must be enabled for the actuator  22  to be powered. In this sense, a default safety state is produced (of no power to the actuator  22 ) if there is an inconsistency between the signals received by processors  48   a  and  48   b.  A change in the wiring to parallel configurations could create a safety state where the actuator is actuated unless both signals received by processors  48   a  and  48   b  are not enabled. 
     Alternatively, and as will be described, a safety state may be enforced by a safety state signal transmitted from the controller  12  or the input module  14  to the microcontrollers  48   a  and  48   b  of output module  16 , the latter which may respond by producing outputs to output interface circuits  50   a  and  50   b  determined by stored values of desired safety states programmed through the configuration terminal  24  as will be described further below. 
     A bridge circuit  17  per the present invention could use the basic structure shown in the input module  14  but replacing the interface circuitry  28   a  and  28   b  of input module  14  with network protocol circuits  38   a  and  38   b  and safety protocol circuits of  40   a  and  40   b  (where the network protocol circuits  38  and  36  are for different protocols, thereby allowing seamless transmission of safety data per the techniques described below). 
     An alternative embodiment contemplated by the present invention allows direct communication between the input module  14  and the output module  16  without the intervening controller  12  or for systems without controllers  12 . In this case, network protocol circuits  36  communicate directly with network protocol circuits  44 . 
     Referring now to FIG. 3, specialized redundant input module  14 , in the present invention, may be replaced with two standard input modules  14   a  and  14   b,  input module  14   a  holding the equivalent of previously described interface circuitry  28   a,  microcontroller  30   a,  safety protocol circuit  32   a  and standard network protocol circuit  36   a;  and input module  14   b  holding the equivalent of interface circuitry  28   b,  microcontroller  30   b,  safety protocol circuit  32   b,  and standard network protocol circuit  36   b.  In this case, the operation of safety protocol circuits  32   a  and  32   b  are implemented in the firmware of the microcontrollers  30   a  and  30   b  and effected via messages communicated on the network  15  rather than the internal bus  34 . 
     Likewise, referring to FIG. 4, the redundancy of output module  16  may be implemented by separate output circuits  16   a  and  16   b,  output module  16   a  including the equivalent of standard network protocol circuit  44 , safety protocol circuit  46   a,  microcontroller  48   a,  and output interface circuit  50   a,  with output module  16   b  including the equivalents of standard network protocol circuit  44  as  44 ′, safety protocol circuit  46   b,  microcontroller  48   b,  and output interface circuit  50   b.  As will be described below, the present invention provides a protocol that is indifferent to the exact parsing of the safety components among physical devices having addresses on the network  15 . 
     Referring now to FIGS. 5 and 2, the operation of the safety protocol circuits  32  and standard network protocol circuits  36  in the input circuit is to embed input data  52  from lines  18   b  within a safety-network protocol  54  implemented both as additional data attached to messages sent on network  15  and in the management of that data as will be described. The safety-network protocol  54  is in turn encapsulated in the standard network protocol  56  for seamless transmission on the network  15 . 
     The Safety Network Protocol 
     Referring now to FIGS. 5 and 2, the operation of the safety protocol circuits  32 ,  40  and  46  in conjunction with the standard network protocol circuits  36 ,  38  and  44  is to embed I/O data  52  (e.g., from lines  18   b ) within a safety-network protocol  54  implemented both as additional data attached to I/O data  52  sent on network  15  and in the management of the particulars of transmission of that I/O data  52 . The safety-network protocol  54  is in turn encapsulated in the standard network protocol  56  for seamless transmission on the network  15 . 
     The data encapsulated in the safety-network protocol  54  and standard network protocol  56  can then be received (e.g., by the controller  12 ) and extracted through the successive operation of the standard network protocol circuits  36 ,  38  and  44  and the safety protocol circuits  32 ,  40  and  46  to provide the I/O data  52  in its basic state. Note that FIG. 5 is only symbolic of the process and that the safety-network protocol  54  is not simply an encapsulation of the data  52  within for example safety data headers but rather the safety protocol includes timing constraints that may be executed in sequence with the standard network protocol  56  so that the safety-network protocol  54  may operate within the standard network protocol  56  without modification of the network  15  or standard network protocol circuits  36 ,  38  and  44 . 
     This dual level encapsulation and de-encapsulation is performed for each transmission of I/O data  52  on the network  15  that requires a high level of reliability commensurate with safety systems. For non-safety system data, the standard network protocol  56  may be used alone without the safety-network protocol  54  for communication with non-safety elements of the industrial control system  10 . Because all data transmitted on the network  15  is embedded in the standard network protocol  56 , the safety-network protocol  54  will work seamlessly with a variety of networks  15  providing they have data transmission capacity suitable for the I/O data  52  and sufficient in capacity to accept some added safety error detection data  58  of the safety-network protocol  54  as will be described. 
     Safety Message Formatting 
     Referring now to FIG. 6, a first aspect of the safety-network protocol  54  is that the I/O data  52  is attached to safety error detection data  58  to form a safety message  60  that forms the data provided to the standard network protocol circuits  36 ,  38  and  44  to produce a network message  61 . The safety error detection data  58  may include a sequence count indicating the local order in which the safety message  60  is transmitted with respect to earlier transmissions of safety messages. The sequence count is normally limited in range (0-3) as it is intended, as will be described, to detect the loss of only a single message. 
     Also appended to the I/O data  52  and part of the safety error detection data  58  is a cyclic redundancy code (CRC) selected in the preferred embodiment to be twelve-bits. The cyclic redundancy code is functionally generated from the I/O data  52  and the sequence count so that an error in the transmission of either of those data elements can be detected when the CRC is recalculated by the receiving device and doesn&#39;t match. As is understood in the art, a twelve bit error code will allow the detection of errors with odd numbers of bit errors, all two-bit errors, all burst errors up to twelve bits and 99.951% of burst errors larger than twelve bits, for up to two-thousand and forty seven bits of data of the safety message  60 . 
     The safety message  60  is embedded in the network headers and footers  62  and  64 , which vary depending on the standard network protocol  56  of the network  15 . Depending on the network  15 , the network header and footer  62  and  64  may include a CRC code and sequence count and other similar safety error detection data  58  operating redundantly with the safety error detection data  58 . Nevertheless, the safety message  60  includes its own safety error detection data  58  so as to be wholly network-independent to the degree possible. 
     Connected Messaging 
     As mentioned above, the safety error detection data  58  forms only part of the safety-network protocol  54 . The safety-network protocol  54  also includes a configuration step that ensures proper communication under a connected messaging scheme. Referring now to FIG. 9, the communications between the controller  12 , input module  14  (or input modules  14   a  and  14   b ) and the output module  16  (or output module  16   a  and  16   b ) may provide a connected messaging system. As is understood in the art, connected messaging involves opening a connection between pairs of logical devices one that acts as a “producers” of a message and one that acts as a “consumers” of the message. The process of opening the connection reserves bandwidth of the network and reserves necessary processing and buffering resources at the producer and consumer to ensure that data of the connection will be reliably transmitted and received. 
     The connected messaging protocol may be implemented as part of the safety network protocol  54  or as part of the standard network protocol  56 , the latter option limiting somewhat the types of standard networks  15  that may be used. Some standard network protocols that support connected messaging are DeviceNet and Control Net, Ethernet, and ATM. 
     Referring now to FIG. 9, under a connected messaging protocol, the input module  14  provides two producers  80  opening two connections with two consumers  82  of the controller  12 , one for each of the signals  18   a  and  18   b.  As a practical matter, these two connections mean that two separate network messages  61  will be sent over the network  15  thus decreasing the chance of loss of both messages. 
     For the implementation of FIG. 3 with separate input module  14   a  and  14   b,  two producers  80  are also provided. Even though the producers  80  are now in different devices (having different addresses on the network  15 ), the operation of the control program implementing the safety system, above the connection level, need not changed by these changes in implementations. Connected messaging thus makes the safety system largely indifferent to topologies as providing for a natural redundancy over a single network, or multiple links 
     Controller  12  likewise includes two producers  80  exchanging data with consumers  82  either in a single output module  16  per FIG. 2 or in separate output module  16   a  and  16   b  per the embodiment of FIG.  4 . Two arrows are shown between each producer  80  and consumer  82  indicating the paring of each message with an acknowledgment message under the safety protocol  54  as will be described below, per FIG.  9 . 
     The bridge circuit  17 , not shown in FIG. 9, but as described above, would implement four consumers and four producers (two for each network side) as will be understood to those of ordinary skill in the art. 
     Safety Configuration Data and Protocol 
     Referring now to FIG. 10, the safety protocol more generally includes an initialization state, of which the first step is developing configuration data as indicated by process block  66 . 
     The configuration process involves developing configuration data at the configuration terminal  24  and ensuring that accurate copies of that configuration data are at each of the input module  14 , the controller  12 , and the output module  16 . The configuration data is unique to each connection, provides essential components of the safety protocol, and identifies intercommunicating parties so as to reduce the possibility of improper connections injecting spurious data into the safety system. This is particularly important in allowing mixing of systems components observing the safety network protocol  54  with standard components observing only the standard network protocol. Devices may support multiple connections, in which case multiple configuration data specific to each connection will be used. 
     Generally, the configuration data include data uniquely identifying the particular device of the input module  14 , the controller  12 , and the output module  16  holding the configuration data, and particularly the serial number of that device. The serial number is a unique and immutable part of the physical devices and thus together with an internal address of the logical devices within the physical device (which may establish independent connections) the serial number provides each connection with a unique identity eliminating the possibility of crossed connections between different devices once the configuration data is properly disseminated. To augment the serial number, the configuration data may also include a vendor identification number, a device code, a product code, major revision, minor revision, as well as network data including the logical, physical address of the device, all known in the art and identifying the particular device. Similarly, the configuration data within a device may include the serial number of the device to which it is connected. 
     As mentioned, the connection data may also include data necessary for the implementation of the other aspects of the safety protocol as are yet to be described, including variables of “periodic time interval”, “reply timer interval”, “filter count”, and “retry limit”. The configuration data also includes the safety state to which the device will revert in the case of network error and a list of related I/O points indicating other I/O points (related to other connections), which should revert to the safety state if the present connection has an error. This later feature allows selective and intelligent disabling of the safety system upon a communication error as will be described. As will be evident from context, some of this data is dependent on the devices and the system programmer must develop some. 
     Referring to FIG. 7, configuration data held within the configuration terminal  24  is sent to each of the input module  14 , the controller  12 , and the output module  16  as messages  66   a,    66   b  and  66   c.    
     The receiving input module  14 , the controller  12 , and the output module  16  store the configuration and respond with the same configuration message but changed to a one&#39;s complement form (being simply a different binary coding (the inversion)) of the configuration data received. This one&#39;s complement message is returned by messages  66   d,    66   e,  and  66   f  from the respective input module  14 , the controller  12 , and the output module  16 . If the configurations of messages  66   a,    66   b  and  66   c  exactly match (after complementing) configuration data of messages  66   d,    66   e  and  66   f,  the configuration was successful. 
     The configuration data may be shown to a human operator for confirmation. If the operator finds that the configuration is correct, the configuration is applied as indicated by process  68  shown in FIG.  10  through messages  68   a,    68   b  and  68   c  from the configuration terminal  24  to the respective input module  14 , the controller  12 , and the output module  16 . The devices must acknowledge these messages via messages  68   d,    68   e  and  68   f  within a predetermined time interval or the configuration will be cleared and no configuration will be considered to have occurred. The configuration data of messages  66  and  68  may be sent using only the standard network protocol  56 . 
     Once the configuration is complete, the safety protocol enters a start-up phase shown generally in FIGS. 8 and 10. During the start-up phase, the necessary safety connections are established and the configuration data is used to verify that the connections expected are those which are in fact made. The purpose of the start-up portion of the configuration is to prevent erroneous connections from being opened between: (1) devices in the safety system and other erroneous devices in the safety system, and (2) devices in the safety system and other devices not in the safety system in a mixed system. 
     In this start-up process, indicated by process block  70  of FIG. 10, the connections are confirmed from the controller  12  to the input module  14  and the output module  16 . In particular, the producers  80  in controller  12  (shown in FIG. 9) send out open connection messages  70   a  and  70   b  to the input module  14  and the output module  16 , respectively. The appropriate consumers  82  respond with connection acknowledgment message  70   c  and  70   d,  respectively. The producers  80  in controller  12  and input module  14  then send the configuration data to the consumer  82  in the controller  12  as indicated by messages  70   e  and  70   f.  The controller&#39;s consumers  82  check to see that the configuration data matches their configuration data and then send acknowledgment messages  70   f  and  70   g  acknowledging that match. At messages  72   a  and  72   b,  conventional I/O data may then commence to be sent. 
     Referring again to FIG. 10, the data  72   a  and  72   b  will be transmitted according to the portions of the safety protocol indicated by process blocks  72  involving formation of the safety message  60  incorporating safety error detection data  58  into the network message  61  as has been described above, and according to message handling protocols  74  operating independent of and in conjunction with the content of the safety message  60  which will now be discussed. 
     Message Handling Safety Protocols 
     (1) Normal Transmission 
     Referring generally to FIGS. 10 and 11, the message handling protocols  74  provide for message time measurements and respond to errors in the safety error detection data  58  during run-time. These message-handling protocols  74  are implemented in the safety protocol circuits  32 ,  40  and  46  or may be implemented in software and are different for producers and consumers. 
     Referring now to FIGS. 11 and 17 for a normal, run-time transmission, the producer  80  upon run-time will send safety messages  84  (encapsulated in the standard network message  61  per safety message  60  as has been described above) to the consumer  82  per FIG.  11 . This sending is indicated generally in FIG.  17 . Immediately prior to sending the message  84 , a periodic timer is started per process block  89  and a reply timer is started at the moment the message  84  is transmitted per process block  91 . The periodic timer interval  86  is longer than the reply timer interval  88  as set in the configuration process described above. 
     Referring now to FIGS. 9,  11  and  18 , the consumer  82  prior to receiving the message  84  is continually checking to see if the periodic time interval  86 ′ of its own periodic timer (started at the consumer&#39;s receipt of the last message  84 ) has expired as indicated in decision block  92 . The periodic timer value  86 ′ is generally greater than the periodic timer value  86 . 
     If the periodic timer has expired, a failure is indicated and the program proceeds to process block  134 , a safety state, as will be described below. 
     If timer value  86  has not expired, then at decision block  90 , the consumer  82  checks to see if the message  84  has arrived. If no message  84  has arrived the program proceeds back to decision block  92  to again check if the periodic timer  86  has expired. 
     Assuming that a message  84  has arrived prior to expiration of the periodic timer  86 , then the program proceeds to decision block  112  to check the CRC of the message  84 . 
     Assuming that the CRC is correct, the program proceeds to decision block  96  and checks to make sure that the sequence count is one greater than the sequence count of the last message received. 
     If the sequence count is correct, then the program proceeds to process block  94  and the periodic timer  86  is reset. At process block  95 , the data is applied, for example, to an output or to update variables, and then at process block  98 , an acknowledgement message  100  is returned to the producer  80 . 
     Referring again to FIG. 17, the producer  80  receiving the acknowledge message at decision block  102 , proceeds to decision block  106  to determine if the periodic timer  86  has expired. 
     Assuming that the periodic timer has not expired, the program proceeds to decision block  124  to check the CRC of the acknowledgement message  100 . The cyclic redundancy code should match the data of the safety message  60  transmitted. 
     Again, assuming that the CRC is correct, the program proceeds to decision block  125  to determine whether the sequence count of the acknowledgment message  100  matches that of the message  84  that was sent. 
     If so, then at decision block  127 , the data sent in message  84  is compared to the data of the acknowledgement message  100 . If there is a match, then the program proceeds to decision block  129  where it loops until the periodic timer has expired, and then proceeds to process block  110  to prepare a new message  84 . 
     This process is repeated for multiple transmissions of safety messages  84  and acknowledgement messages  100 . 
     (2) Message Received but Corrupted 
     Referring now to FIG. 11 in one potential error the safety message  84  is corrupted for example by electromagnetic interference  85 . In this case a message is received at the consumer  82 , as indicated by FIG. 18 per process block  90 , within the periodic timer value  86 ′ as measured by process block  92  however there is an error in the CRC data as determined by decision block  112 . In this case, the program proceeds to process block  114  and no action is taken and in particular no acknowledgement message  100  is returned. 
     Referring to FIG. 17, in this case there will be no acknowledgment message  100  received by the producer  80  at process block  102 . The program proceeds to decision block  116  to determine if the periodic time interval  86  has expired. If so, the failure is indicated and the program proceeds to the safety state of process block  126 . 
     If the periodic timer interval  86  has not expired, the program will proceed to decision block  118  to see if the shorter reply timer interval  88  has expired. If not, the program will loop back to process block  102 . If so, the program will proceed to process block  120  to check if the retry limit has been exceeded. Initially this may not be the case and the program will proceed to process block  122  and a repeat message  84 ′ having the same sequence count will be sent at process block  84 , as also indicated by FIG.  12 . If the retry limit has been exceeded, the program proceeds to the safety state  126 . 
     This repeat message  84 ′ will be received at the consumer  82  as indicated by process block  90  of FIG.  18  and assuming that it is correct it and that it has arrived within the periodic timer interval  86 ′ based on the previous non-erroneous message, this message  84 ′ results in the sending of an acknowledgment message  100  at process block  98  per the steps described above. 
     Typically, if only one missed transmission has occurred, the acknowledgment message  100  will occur within the periodic timer interval  86  of the producer and messages will be continued to be exchanged normally as has been previously described with respect to FIG.  11 . 
     (3) Message Not Received 
     Referring now to FIG. 13, in the previous example, the safety message  84  arrived at the consumer  82  to be detected, albeit with errors. It is possible that the safety message  84  will not arrive at the consumer  82  either as a result of such extreme interference that it is not recognizable as a message under low level network protocols, or as a result of component failures between the producer and the consumer of an intermittent nature. Under this situation, the producer  80  sends the message  84  but the consumer does not receive a message at process block  90  of FIG.  18 . 
     The “no action” block  114  of FIG. 18 of the consumer (as described above) is thus not encountered but the result is in any case the same: the consumer  82  takes no action. 
     Thus, as described previously with respect to FIG. 12 at the expiration of the reply timer at the producer  80 , the producer  80  will produce a second message  84 ′ which if received will result in an acknowledgment message  100  initiating a string of normal communications. 
     (4) Acknowledgment Message Received but Corrupted 
     Referring now to FIG. 14 the safety message  84  may successfully reach the consumer  82  with no errors but the acknowledgement message  100  may have errors introduced by electromagnetic interference  85 . In this case the producer  80  reacts as shown in FIG. 17 by decision block  106  to detect a receipt of an acknowledgment message  100  within the periodic timer interval  86 . But there is an error in the data of the acknowledgment message  100 . 
     If the CRC is correct as determined by decision block  124  and it is the sequence count that is wrong per process block  124 , then the program enters the safety state  126  in which outputs and inputs of the consumer  82  are set to a predefined safety state of the configuration data. The predefined safety state, as was previously provided as part of the configuration data defines that state (outputs and internal state) to which the device will revert in the case of network error. The safety state may be communicated with the list of related I/O points indicating other I/O points (related to other connections), which should revert to the safety state if the present connection has an error. This list was also provided as part of the configuration data described above. The safety state and list of related I/O points may be designated by the system programmer based on the particular application of the control system and states and related groupings of devices that will best provide for failure of individual devices or connections. 
     Similarly, if the sequence count is correct but the acknowledgement data does not match per decision block  127 , the program proceeds to the safety state  126 . If the consumer  82  is the controller  12  messages may be sent to other I/O devices, indicated in the configuration data signaling them to move to the safety state as well. 
     Assuming at process block  124  that the CRC code does not match the safety message  60 . indicating a corruption in the safety message rather than an erroneous duplicate message, the program proceeds to decision block  118  to see if the reply timer has expired as described above. When the reply timer expires the program proceeds to process block  120  as described above and checks the retry counter to see if the retry limit has been exceeded. If so, the program proceeds to the safety state  126  however often this will not have occurred and the program proceeds to process block  122  and a retry message  84 ′ is prepared as indicated in FIG.  14 . 
     Assuming this retry message evokes a non-corrupted acknowledgment message  100 ′ communication continues in normal fashion. 
     (5) Acknowledgment Message Not Received 
     Referring now to FIG. 15 it is possible that the acknowledgment message  100  is lost completely either through interference or temporary communication failure. In that case, as has been previously described, a duplicate message  84  will be sent from the producer  80  however the sequence count will be identical to the sequence count of a message  84  previously received by the consumer  82 . In this case as shown in FIG. 18 at process block  112  the CRC will be correct but as tested at subsequent decision block  96  the sequence code will be wrong. The program, in this case, proceeds to process block  130  to check if the sequence code is one less than that expected. If not the program proceeds to the safety state  134 . If so, however, the consumer  82  must conclude that the acknowledgment message  100  was lost and an acknowledgment of the previous message is sent again by the consumer at process block  132 . 
     (6) No Messages Received 
     Finally as shown in FIG. 15 the producer may be unable to connect with the consumer within the periodic interval  86 ′ of the consumer. In that case the program proceeds to the safety state  134  directly from decision block  92  as shown in FIG.  18 . 
     The above description has been that of a preferred embodiment of the present invention, it will occur to those that practice the art that many modifications may be made without departing from the spirit and scope of the invention. In order to apprise the public of the various embodiments that may fall within the scope of the invention, the following claims are made.