Safety network for safety PLCs of industrial plants

Abstract

A secure PLC network employs multi-PLC authentication of a programming application before allowing the application to reprogram any PLC on the secure network. Each PLC on the secure network is equipped with authentication capabilities that detect attempts to reprogram the PLC and issue an authentication challenge that requires the programming application to process a work proof. The authentication challenge is also sent to other PLCs on the secure network along with the response from the programming application for verification purposes. The other PLCs process the authentication challenge and check the acceptability of the response from the programming application. If a majority of the PLCs on the secure network determine that the response from the programming application is correct, the programming application is authenticated and can proceed with reprogramming. This group authentication requires a malicious application to simultaneously hijack multiple PLCs on the secure network before reprogramming any of them, a highly unlikely outcome.

Description

[0001] Cross Reference to Related Applications

[0002] This patent application claims priority to U.S. Provisional Application No. 62 / 955,776, filed December 31, 2019, entitled “Secure Network of Safety PLCs for Industrial Plants,” and is incorporated herein by reference. TECHNICAL FIELD

[0003] The present disclosure relates to safety systems for industrial plants, and more particularly, to methods and systems for implementing a network of safety PLCs for industrial plants that provide improved protection against cyber attacks and other cyber security threats. BACKGROUND

[0004] Modern industrial plants employ automation processes to improve efficiency and reliability, and limit interaction between plant personnel and process machinery and equipment for safety reasons. The latter is especially important in plants that handle hazardous materials, such as oil and gas refineries, chemical plants, nuclear power plants, etc. Process automation often takes the form of PLCs (programmable logic controllers) and the like that are used to monitor and control plant machinery and equipment and related processes.

[0005] In addition to process PLCs, many modern industrial plants also employ safety systems as an added layer of protection in the event of process PLC failure or malfunction. Rather than controlling any plant processes, safety systems typically operate to ensure that certain safety measures are performed, such as shutting off power, venting gases, activating sprinklers, etc., when the process PLC fails or can no longer properly control the process. Such safety systems not only help protect plant personnel, but also help protect the environment and the plant itself from catastrophic damage.

[0006] Most industrial safety systems employ the same or similar type of PLCs as the process PLCs, except that the safety PLCs are programmed to perform specific safety functions, rather than process control functions. These safety PLCs, like the process PLCs, can be reprogrammed or updated from time to time with new program code as needed by authorized programming applications. However, if a malicious application is able to access the safety PLCs (e.g., via a man-in-the-middle attack or other type of cyber attack), the malicious application can change the programming of the safety PLCs. A compromised safety PLC will no longer be able to respond as originally intended, thereby significantly increasing the risk or danger that the plant will experience an accident or other industrial disaster.

[0007] Accordingly, while there have been many developments in industrial safety systems, it is readily appreciated that there is still a need for continued improvements. SUMMARY

[0008] The present disclosure relates to systems and methods for implementing a secure network of safety PLCs for an industrial plant. The network of safety PLCs employs multi-PLC authentication of a programming application before allowing the application to reprogram any safety PLC on the secure network. Each safety PLC on the secure network is equipped with authentication capabilities that detect an attempt to reprogram the safety PLC and issue an authentication challenge that requires the programming application to process or otherwise resolve a proof-of-work (PoW). The safety PLC then transmits the authentication challenge and a response provided by the programming application for verification purposes to other safety PLCs on the secure network. The other safety PLCs process the authentication challenge and check the acceptability of the response from the programming application. If a majority of the safety PLCs on the secure network determine that the response from the programming application is correct, the programming application is authenticated and allowed to reprogram. This group authentication would force a malicious application to simultaneously hijack multiple safety PLCs on the secure network, which is at most a low feasibility event, in order to reprogram any one safety PLC.

[0009] In general, in one aspect, embodiments of the present disclosure relate to a safety system for an industrial plant. The system includes, among other things, a secure network in the industrial plant and a plurality of safety programmable logic controllers (PLCs) coupled to communicate with each other over the secure network, each safety PLC operable to perform one or more safety functions related to equipment in the industrial plant. Each safety PLC is operable to initiate multi-PLC authentication of a programming application in response to a request by the programming application to download PLC programming to the safety PLC.

[0010] According to any one or more of the preceding embodiments, each safety PLC is operable to initiate the multi-PLC authentication by: issuing an authentication challenge to the programming application, receiving a response to the authentication challenge from the programming application, providing the authentication challenge and the response from the programming application to other safety PLCs coupled to communicate over the secure network for verification, receiving verification results from the other safety PLCs coupled to communicate over the secure network, and allowing the programming application to download the PLC programming to the safety PLC if a minimum number of the safety PLCs coupled to communicate over the secure network have verified that the response from the programming application is acceptable.

[0011] According to any one or more of the preceding embodiments, the minimum number of safety PLCs is a majority of the safety PLCs coupled to communicate over the secure network.

[0012] According to any one or more of the preceding embodiments, each of the secure PLCs is further operable to verify the response to the authentication challenge from the programming application and provide a verification result to other secure PLCs coupled to communicate over the secure network.

[0013] According to any one or more of the preceding embodiments, the authentication challenge takes the form of a PoW related to a function of the programming application, and each of the secure PLCs is further operable to select the PoW from a predefined list of PoWs for the programming application stored in each of the secure PLCs.

[0014] In general, in another aspect, embodiments of the present disclosure relate to a secure PLC for an industrial plant. The secure PLC includes, among other things, a processor and a network interface connected to the processor, the network interface allowing the secure PLC to communicate with other secure PLCs in the industrial plant over a secure network. The secure PLC also includes a storage device connected to the processor, the storage device storing computer-readable instructions thereon that, when executed by the processor, cause the processor to initiate a multi-PLC authentication of a programming application in response to a request by the programming application to download PLC programming to the secure PLC.

[0015] According to any one or more of the preceding embodiments, the computer-readable instructions cause the processor to initiate the multi-PLC authentication by issuing an authentication challenge to the programming application, receiving a response to the authentication challenge from the programming application, providing the authentication challenge and the response from the programming application to the other secure PLCs over the secure network for verification, receiving verification results from the other secure PLCs over the secure network, and allowing the programming application to download the PLC programming to the secure PLC if a minimum number of the secure PLCs have communicated over the secure network that the response from the programming application is acceptable.

[0016] According to any one or more of the preceding embodiments, the secure PLC is a master secure PLC, and the computer-readable instructions further cause the processor to count the verification results received from the other secure PLCs and issue an accept command over the secure network if the minimum number of the secure PLCs have communicated over the secure network that the response from the programming application is acceptable.

[0017] According to any one or more of the preceding embodiments, the minimum number of the secure PLCs is a majority of the secure PLCs coupled to communicate over the secure network.

[0018] According to any one or more of the preceding embodiments, the computer-readable instructions further cause the processor to verify the response to the authentication challenge from the programming application and provide a verification result to other secure PLCs coupled to communicate over the secure network.

[0019] According to any one or more of the preceding embodiments, the authentication challenge takes the form of a PoW related to a function of the programming application, and the computer-readable instructions further cause the processor to select the PoW from a predefined list of PoWs for the programming application stored in the secure PLC.

[0020] In general, in another aspect, embodiments of the present disclosure relate to a method of securing a safety network of an industrial plant. The method includes, among other things, providing a plurality of secure PLCs coupled to communicate with each other over the safety network; and initiating a multi-PLC authentication of a programming application in response to a request received from the programming application to download PLC programming to a secure PLC of the plurality of secure PLCs, where initiating the multi-PLC authentication includes issuing an authentication challenge to the programming application.

[0021] According to any one or more of the preceding embodiments, initiating the multi-PLC authentication further includes receiving a response to the authentication challenge from the programming application, providing the authentication challenge and the response from the programming application to the other secure PLCs over the safety network for verification, receiving verification results from the other secure PLCs over the safety network, and allowing the programming application to download the PLC programming to the secure PLC if a minimum number of secure PLCs have communicated over the safety network that the response from the programming application is acceptable.

[0022] According to any one or more of the preceding embodiments, the secure PLC is a master secure PLC, the method further includes counting the verification results received from the other secure PLCs, and issuing an accept command over the safety network if the minimum number of secure PLCs have communicated over the safety network that the response from the programming application is acceptable.

[0023] According to any one or more of the preceding embodiments, the minimum number of secure PLCs is a majority of the secure PLCs coupled to communicate over the safety network.

[0024] According to any one or more of the preceding embodiments, initiating the multi-PLC authentication includes verifying the response to the authentication challenge from the programming application, and providing the verification results to the other secure PLCs over the safety network.

[0025] According to any one or more of the preceding embodiments, the authentication challenge takes the form of a PoW related to a function of the programming application, and initiating the multi-PLC authentication further includes selecting the PoW from a predefined list of PoWs for the programming application stored in the secure PLC. BRIEF DESCRIPTION OF DRAWINGS

[0026] A more detailed description of the disclosure briefly outlined above can be obtained by reference to the various embodiments, some of which are illustrated in the drawings. While these drawings depict selected embodiments of the disclosure, these drawings are not to be considered as limiting its scope, as the disclosure can admit to other equally effective embodiments.

[0027] Figure 1 is a schematic diagram illustrating an industrial plant having a safety network with a safety PLC according to an embodiment of the disclosure;

[0028] Figure 2 is a block diagram illustrating an exemplary architecture of a safety PLC according to an embodiment of the disclosure;

[0029] Figure 3 is a flowchart illustrating a method of authenticating a programming application by a target safety PLC according to an embodiment of the disclosure;

[0030] Figure 4 is a flowchart illustrating a method of authenticating a programming application by another safety PLC according to an embodiment of the disclosure; and

[0031] Figure 5 is a flowchart illustrating a method of authenticating a programming application by a master safety PLC according to an embodiment of the disclosure.

[0032] Where possible, the same reference numbers will be used throughout the drawings to refer to the same or like elements. However, elements disclosed in one embodiment can be beneficially used in other embodiments without specific recitation. DETAILED DESCRIPTION

[0033] Reference is now made to Figure 1 , a block diagram illustrating an exemplary industrial plant 100 having a safety system 101 therein according to an embodiment of the disclosure. As can be seen, the exemplary industrial plant 100 has at least two device communication networks, including a process control network 102 and a safety network 104. These networks 102, 104 can be wired networks (e.g., Ethernet, HART, etc.), wireless networks (e.g., Wi-Fi, Bluetooth, etc.), or a combination of wired and wireless networks. In general, the process control network 102 is used to monitor and control plant machinery and equipment, and can be accessed by any device authorized to do so, while the safety network 104 is generally only accessible by safety devices, and is typically physically isolated (by an “airgap”) or logically isolated, or both, from non-safety devices for safety purposes.

[0034] A number of process PLCs (for economy, only one of which is shown here at 106) can be connected to the process control network 102, either directly or as part of a Supervisory Control and Data Acquisition (SCADA) system 108. A number of safety PLCs 110 (for economy, only three of which are shown here at 110-1, 110-2, and 110-n) can likewise be connected to the process control network 102 as well as to the safety network 104. Each of the safety PLCs 110 has a unique identification on the process control network 102 and the safety network 104, such as safety PLC-1, safety PLC-2, safety PLC-n, etc., which is known to (e.g., stored within) each of the other safety PLCs 110. These safety PLCs 110 and the safety network 104 together comprise at least a portion of a safety system 101 of the industrial plant 100. Note also that while the industrial plant 100 uses PLCs in this example, other types of microprocessor-based control devices, such as remote terminal units (RTUs), can also be used with embodiments of the present disclosure.

[0035] In general operation, each process PLC 106 monitors one or more operating parameters of certain equipment in the industrial plant 100, such as a boiler 112. The operating parameters are provided to each process PLC 106 by one or more sensors, such as a temperature sensor 114 and a pressure sensor 116, installed on or near the equipment. Based on these operating parameters, each process PLC 106 can change or adjust certain operating aspects of the equipment, such as opening or closing an inflow valve, thereby reducing or increasing fluid flow to or from the equipment, etc., to achieve or maintain certain process goals.

[0036] The safety PLCs 110 also monitor one or more operating parameters of certain equipment in the industrial plant 100, but for safety goals rather than process goals. In the example shown, safety PLC-1 monitors one or more operating parameters of the boiler 112 via a temperature sensor 118 and a pressure sensor 120 installed on or near the boiler 112. Based on these operating parameters, safety PLC-1 can perform certain safety functions for the boiler 112, such as closing or opening an outflow valve, thereby reducing or increasing fluid flow to or from the boiler 112, etc., to prevent a boiler malfunction. Figure 1

[0037] ​The other safety PLCs 110 operate in a similar manner to the safety PLC-1 with respect to the other equipment in the industrial plant 100. At times, these safety PLCs 110 can need to update their programming for various reasons. To this end, a PLC programming system 122 having a PLC programming application 124 thereon is provided on the process control network 102. The PLC programming application 124 includes programming protocols and specific functionality for updating the programming of the safety PLCs 110. For example, the programming application 124 can include a specific compiler that can compile program code into executable logic for exclusive operation on the safety PLCs 110. The programming application 124 can also include a process that is able to run the same executable logic that is downloaded to and run by the safety PLCs 110. Within the scope of the present disclosure, these protocols and functionality can be commercially off-the-shelf components, or they can be specifically developed for a particular factory safety system application. The programming application 124 can then be used to manually and / or automatically compile and download executable logic to the safety PLCs 110 to update their programming as needed.

[0038] According to embodiments of the present disclosure, each of the safety PLCs 110 is equipped with authentication capabilities that check the PLC programming application 124 before accepting executable logic from the PLC programming application 124. More specifically, each of the safety PLCs 110 requires the programming application 124 to process or otherwise resolve an authentication challenge within a specified time period in order for the safety PLC 110 to accept executable logic from the programming application 124. The safety PLC 110 then sends the authentication challenge and the response provided by the programming application 124 to the other safety PLCs 110 on the safety network 104 for verification. Thereafter, the other safety PLCs 110 process the authentication challenge and check the response from the programming application 124. If a majority of the safety PLCs 110 on the safety network 104 determine that the response from the programming application 124 is correct or acceptable, then the programming application is verified and the safety PLCs 110 accept the executable logic.

[0039] The authentication challenge can take any form known to those skilled in the art that can be used to authenticate the programming application 124. For example, the authentication challenge can involve a legitimate function on the programming application 124, such as compiling a certain piece of program code, or performing a certain computational process that a legitimate programming application 124 would be able to perform, and providing a result or output thereof. In some embodiments, the authentication challenge can take the form of a request for a proof-of-work (PoW), which is a piece of computational processing that is generally difficult to complete, but once completed, is relatively easy to verify by reversing the work from the result or output.

[0040] In some embodiments, the majority is determined by dividing the total number of secure PLCs 110 on the secure network 104 by 2 and adding 1. That is, M = N / 2 + 1, where M is the majority and N is the total number of secure PLCs 110 on the secure network 104. If the total number of secure PLCs 110, N, is odd, then the quotient can be rounded up to the next whole number. In this way, a malicious application would need to compromise multiple secure PLCs 110 on the secure network 104 at the same time before executable logic could be downloaded to any one of the secure PLCs 110. In some embodiments, if a secure PLC 110 on the secure network 104 fails to provide verification or otherwise respond within a specified time period, that secure PLC is not counted in determining the majority (i.e., subtract the unresponsive secure PLC from the total number of secure PLCs, N). In other embodiments, unresponsive secure PLCs 110 are counted as negative values in determining the majority (i.e., a response to an authentication challenge from the programming application 124 is deemed incorrect or unacceptable).

[0041] In some embodiments, while each secure PLC 110 receives verification results from other secure PLCs 110 on the secure network 104, one of the secure PLCs 110 can be randomly designated as the master secure PLC for purposes of counting the verification results. The random designation can occur periodically, or can occur each time an attempt to program or reprogram any secure PLC 110 on the secure network 104 is detected. The designated master secure PLC then counts the verification results from all secure PLCs 110 on the secure network 104 and issues an accept command or a reject command to all secure PLCs 110 on the secure network 104. The secure PLCs 110 on the secure network 104 then accept or reject the reprogramming attempt accordingly.

[0042] Figure 2 is a block diagram illustrating an exemplary secure PLC 110 according to embodiments of the present disclosure. In one embodiment, the secure PLC 110 includes a bus 202 or other communication pathway for communicating data within the control system and a CPU 204, which can be any suitable microprocessor or microcontroller coupled to the bus 202 for processing information. The secure PLC 110 can also include a main memory 206, such as a random access memory (RAM) or other dynamic storage device coupled to the bus 202 for storing computer readable instructions to be executed by the CPU 204. The main memory 206 can also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the CPU 204.

[0043] The safety PLC 110 can also include read only memory (ROM) 208 or other static storage devices coupled to the bus 202 for storing static information and instructions for the CPU 204. A computer readable storage device 210, such as a non-volatile memory (e.g., flash memory) or a magnetic disk, can be coupled to the bus 202 for storing information and instructions for the CPU 204. The CPU 204 can also be coupled via the bus 202 to an equipment interface 212 for allowing the safety PLC 110 to communicate with plant equipment (e.g., the boiler 112) connected thereto. A sensor interface 214 can be coupled to the bus 202 for allowing the safety PLC 110 to communicate with various plant sensors (e.g., the sensors 118, 120) installed on or near the plant equipment. A network interface 216 can be coupled to the bus 202 for allowing the safety PLC 110 to communicate with a plant network (e.g., the networks 102, 104), etc.

[0044] The term "computer readable instructions" used above refers to any instructions that can be executed by the CPU 204 and / or other components. Similarly, the term "computer readable medium" refers to any storage medium that can be used to store computer readable instructions. Such media can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as the storage device 210. Volatile media includes dynamic memory, such as the main memory 206. Transmission media includes coaxial cables, copper wire, and fiber optics, including the wires that comprise the bus 202. Transmission can also take the form of electromagnetic waves, acoustic waves, or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer readable media can include, for example, magnetic media, optical media, memory chips, and any other medium that a device can read.

[0045] The security function 220, or computer readable instructions thereof, can also reside on or be downloaded to the storage device 210. The security function 220 can then be executed by the CPU 204 and other components to automatically detect abnormal operating parameters of the plant equipment (e.g., the boiler 112) and initiate one or more safety actions. To protect the security function 220 from being altered by a malicious application, an application authentication module 222, or computer readable instructions thereof, can also reside on or be downloaded to the storage device 210. The application authentication module 222 detects attempts to program or reprogram the security PLC 110 and applies multi-PLC verification to check the programming application. Such an application authentication module 222 can be written using any suitable software development environment, in any suitable computer programming language known to those skilled in the art. Examples of suitable programming languages include IEC 61131-3, C, C++, C#, Python, Java, Perl, and the like.

[0046] The application authentication module 222 can include or have access to one or more authentication challenges, as indicated at 224, for testing the programming application. In some embodiments, the authentication challenges 224 can take the form of proof-of-work (PoW) requests that require the programming application to perform some computational challenge. As previously noted, such PoW requests are generally difficult to solve, but once solved, are relatively easy to verify by reversing the work. Suitable proofs-of-work can be developed using IEC 61131-3 function blocks or structured text (which are standard programming languages specified for programmable logic controllers). For illustrative purposes, an example proof-of-work is specified in Figure 2 as Function A, Function B, Function C, etc., along with the inputs to each proof-of-work.

[0047] The application authentication module 222 can also include or have access to verification results from each security PLC 110 on the security network 104. As previously noted, the application authentication module 222 employs multi-PLC verification to test the programming application. This requires the application authentication module 222 to send the proof-of-work to each security PLC 110 on the security network 104 along with the response from the programming application for verification. Each security PLC 110 processes the proof-of-work against the response from the programming application and sends the results to the other security PLCs 110 on the security network 104. In the example of Figure 2 the verification results are listed according to the unique identification of each security PLC and whether the security PLC determined that the response from the programming application was acceptable.

[0048] Reference is now made to Figure 3According to embodiments of the present disclosure, a flowchart showing the method 300 can be used with a safety PLC for checking a PLC programming application. The method generally starts at block 302 when the safety PLC detects a request or attempt by a programming application to download PLC programming, typically in the form of executable logic, i.e., a safety PLC. At block 304, the safety PLC selects and sends an authentication challenge, such as a proof-of-work request, to the programming application along with any information needed to process the authentication challenge, such as the input to the proof-of-work. At block 306, the safety PLC receives a response to the authentication challenge from the programming application, and at block 308, the safety PLC verifies the response to the authentication challenge.

[0049] At block 310, the safety PLC shares the authentication challenge and the verification it performed with other safety PLCs on the safety network. In some embodiments, the safety PLC can share the authentication challenge by sending an identifier for the authentication challenge, such as a reference number, to the other safety PLCs on the safety network along with any information needed to process the authentication challenge. At block 312, the safety PLC also shares the response to the authentication challenge received from the programming application for verification purposes. At block 314, the safety PLC receives verification results from the other safety PLCs on the safety network, and at block 316, the safety PLC tallies the verification results and shares the tally with the other safety PLCs on the safety network.

[0050] At block 318, it is determined whether the tally from block 316 shows that the number of acceptable results is greater than or equal to a minimum threshold. In some embodiments, the minimum threshold is a majority of the number of safety PLCs on the safety network. In some embodiments, the minimum threshold is a majority of the safety PLCs on the safety network that responded within a specified time period. If the determination is no, then at block 320, the safety PLC rejects the PLC programming from the programming application. If the determination is yes, then at block 322, the safety PLC accepts the PLC programming from the programming application.

[0051] In some embodiments, rather than performing the tally at block 316 and evaluating the tally results at block 318, the safety PLC can wait for a randomly designated master safety PLC to perform the tally and send an accept command or a reject command to the safety PLC. As previously mentioned, the random designation of a master safety PLC can occur periodically or can occur each time an attempt is made to program or reprogram any safety PLC on the safety network.

[0052] Note that the method 300 in FIG. 3 is from the perspective of a safety PLC that is intended to be reprogrammed. Now looking at FIG. 4, a flowchart showing the method 400 can be used with a safety PLC that is intended to program or reprogram other safety PLCs on a safety network. The method generally starts at block 402 when the safety PLC detects a request or attempt by a programming application to download PLC programming, typically in the form of executable logic, i.e., a safety PLC. At block 404, the safety PLC selects and sends an authentication challenge, such as a proof-of-work request, to the programming application along with any information needed to process the authentication challenge, such as the input to the proof-of-work. At block 406, the safety PLC receives a response to the authentication challenge from the programming application, and at block 408, the safety PLC verifies the response to the authentication challenge. Figure 3 Figure 4 ​, which is a flowchart illustrating a method 400 that can be used with other non-targeted secure PLCs on a secure network for checking a PLC programming application according to embodiments of the present disclosure. The method 400 generally starts at block 402, where the other secure PLCs receive an authentication challenge or information identifying an authentication challenge and its verification result from a targeted secure PLC on the secure network. In some embodiments, the authentication challenge takes the form of a proof-of-work as described above. At block 404, the secure PLCs also receive from the targeted secure PLC a response to the authentication challenge provided by the programming application. At block 406, the secure PLCs process the authentication challenge and verify the response of the programming application, and at block 408, each secure PLC shares its verification result with the other secure PLCs on the secure network.

[0053] Figure 5 , which is a flowchart illustrating a method 500 that can be used with a master secure PLC on a secure network for checking a PLC programming application according to embodiments of the present disclosure. The method 500 is similar to the method 400 in Figure 4 , in that it generally starts at block 502, where the secure PLC securely receives an authentication challenge or information identifying an authentication challenge and its verification result from a targeted secure PLC on the secure network. Again, the authentication challenge can take the form of a proof-of-work as described above. At block 504, the master secure PLC also receives from the targeted secure PLC a response to the authentication challenge provided by the programming application. At block 506, the master secure PLC processes the authentication challenge and verifies the response of the programming application, and at block 508, the master secure PLC shares its verification result with the other secure PLCs on the secure network.

[0054] In some embodiments, the targeted secure PLC can also be designated as the master secure PLC. In such embodiments, the targeted master secure PLC can use the method 300 of Figure 3 in combination with the method 500 of Figure 5 .

[0055] In addition to the foregoing, at block 510, the master safety PLC also counts the validation results from the safety PLCs on the safety network. Thereafter, the master safety PLC determines whether the count shows that the number of acceptable results is greater than or equal to a minimum threshold at block 512. In some embodiments, the minimum threshold is a majority of the number of safety PLCs on the safety network. In some embodiments, the minimum threshold is a majority of the safety PLCs on the safety network that responded within a specified time period. If determined to be no, then at block 514, the master safety PLC issues a command to all of the safety PLCs on the safety network to reject the PLC programming from the programming application. If determined to be yes, then at block 516, the master safety PLC issues a command to all of the safety PLCs on the safety network to accept the PLC programming from the programming application.

[0056] In the foregoing, various embodiments have been described. However, the scope of the disclosure is not limited to the embodiments specifically described. Rather, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments can achieve advantages over other possible solutions or existing technologies, whether or not a given embodiment achieves an advantage is not limiting of the scope of the disclosure. Thus, the foregoing aspects, features, embodiments and advantages are merely illustrative and are not required unless expressly recited in a claim.

[0057] Various embodiments disclosed herein can be implemented as a system, method, or computer program product. Accordingly, aspects can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects can take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

[0058] Any combination of one or more computer readable medium can be utilized. The computer readable medium can be a non-transitory computer readable medium. A non-transitory computer readable medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of non-transitory computer readable medium can include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. Program code embodied on a computer readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0059] Computer program code for carrying out operations for aspects of the present disclosure can be written in any combination of one or more programming languages. Moreover, such computer program code can execute using a single computer system or by multiple computer systems communicating with one another, e.g., using a local area network (LAN), a wide area network (WAN), the Internet, etc. While various features are described in terms of flowcharts, and / or block diagrams, it should be appreciated that various features can be implemented, or implemented differently, using computer program code in accordance with the teachings of the present disclosure. Generally, computer program code is provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the computer program code, when executed, can implement the functions or acts specified in the flowcharts and / or block diagrams.

[0060] The flow and block diagrams in the drawings illustrate the architecture, functionality, and / or operations of possible implementations of various embodiments of the present disclosure. In this regard, each block in the flow and block diagrams can represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0061] It is to be understood that the above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. Although the present disclosure describes specific examples, it should be recognized that the systems and methods of the present disclosure are not limited to the examples described herein, but can be practiced with modification and alteration within the scope of the appended claims. Accordingly, the specification and drawings are to be regarded as illustrative in nature and not as restrictive. The scope of the disclosure should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. A safety system (101) for an industrial plant (100), comprising: a safety network (104) in the industrial plant (100); a plurality of safety programmable logic controllers, PLCs (110), coupled to communicate with each other over the safety network (104), each safety PLC (110) operable to perform one or more safety functions related to its own respective equipment in the industrial plant (100); wherein each safety PLC (110) is operable to initiate a multi-PLC authentication of a programming application in response to a request by the programming application to download PLC programming to the safety PLC (110), wherein each safety PLC (110) is operable to initiate the multi-PLC authentication by: issuing an authentication challenge to the programming application; receiving a response to the authentication challenge from the programming application; providing the authentication challenge and the response from the programming application to other safety PLCs (110) of the plurality of safety PLCs coupled to communicate over the safety network (104) for verification; receiving verification results from the other safety PLCs (110) coupled to communicate over the safety network (104); and allowing the programming application to download the PLC programming to the safety PLC (110) if a minimum number of safety PLCs (110) of the plurality of safety PLCs coupled to communicate over the safety network (104) have verified that the response from the programming application is acceptable.

2. The safety system (101) of claim 1, wherein, the minimum number of safety PLCs (110) is a majority of the plurality of safety PLCs (110) coupled to communicate over the safety network (104), the majority being determined by dividing a total number of safety PLCs (110) on the safety network (104) by 2 and adding 1.

3. The safety system (101 ) according to claim 1 or 2, wherein each safety PLC (110) is further operable to verify the response from the programming application to the authentication challenge and provide verification results to the other safety PLCs (110) coupled to communicate over the safety network (104).

4. The safety system (101) according to claim 1 or 2, wherein the authentication challenge takes the form of a proof-of-work, PoW, related to a function of the programming application.

5. The safety system (101) of claim 4, wherein, each safety PLC (110) is further operable to select the PoW from a predefined list of PoWs of the programming application stored in each safety PLC (110).

6. A safety PLC (110) for an industrial plant (100), comprising: a processor; a network interface connected to the processor, the network interface allowing the safety PLC (110) to communicate with other safety PLCs (110) of a plurality of safety PLCs in the industrial plant (100) over a safety network (104), each safety PLC (110) operable to perform one or more safety functions related to its own respective equipment in the industrial plant (100); and a memory connected to the processor, the memory storing a plurality of safety functions related to the safety PLC (110) and a plurality of safety functions related to other safety PLCs (110) of the plurality of safety PLCs in the industrial plant (100), each safety function of the plurality of safety functions being executable by the safety PLC (110) and each safety function of the plurality of safety functions being executable by the other safety PLCs (110) of the plurality of safety PLCs. a storage device connected to the processor, the storage device storing computer readable instructions thereon that, when executed by the processor, cause the processor to initiate multi-PLC authentication of the programming application in response to a request by the programming application to download PLC programming to the secure PLC (110), wherein the computer readable instructions cause the processor to initiate multi-PLC authentication by: issuing an authentication challenge to the programming application; receiving a response to the authentication challenge from the programming application; providing the authentication challenge and the response from the programming application to the other secure PLCs (110) over the secure network (104) for verification; receiving verification results from the other secure PLCs (110) over the secure network (104); and allowing the programming application to download the PLC programming to the secure PLC (110) if a minimum number of secure PLCs (110) of the plurality of secure PLCs (110) have communicated over the secure network (104) that the response from the programming application is acceptable.

7. The safety PLC (110) according to claim 6, wherein the secure PLC (110) is a master secure PLC, and the computer readable instructions further cause the processor to count the verification results received from the other secure PLCs (110) and to issue an accept command over the secure network (104) if the minimum number of secure PLCs (110) have communicated over the secure network (104) that the response from the programming application is acceptable.

8. The secure PLC (110) according to claim 6 or 7, wherein the minimum number of secure PLCs (110) is a majority of the plurality of secure PLCs (110) coupled to communicate over the secure network (104), the majority being determined by dividing the total number of secure PLCs (110) on the secure network (104) by 2 and adding 1.

9. The secure PLC (110) according to claim 6 or 7, wherein the computer readable instructions further cause the processor to verify the response from the programming application to the authentication challenge and to provide the verification results to the other secure PLCs over the secure network (104).

10. The secure PLC (110) according to claim 6 or 7, wherein the authentication challenge takes the form of a proof-of-work (PoW) related to a function of the programming application.

11. The secure PLC (110) of claim 10, wherein, the computer readable instructions further cause the processor to select the PoW from a predefined list of PoWs of the programming application stored in the secure PLC (110).

12. A method of securing a secure network (104) of an industrial plant (100), comprising: providing a plurality of secure PLCs (110) coupled to communicate with each other over the secure network (104), each secure PLC (110) operable to perform one or more secure functions related to its own respective equipment in the industrial plant (100); and in response to receiving a request from a programming application to download PLC programming to a secure PLC (110) of the plurality of secure PLCs (110), initiating multi-PLC authentication of the programming application; wherein initiating multi-PLC authentication includes issuing an authentication challenge to the programming application, wherein initiating multi-PLC authentication further includes: receiving a response to the authentication challenge from the programming application; providing the authentication challenge and the response from the programming application to other secure PLCs (110) in the plurality of secure PLCs (110) over the secure network (104) for verification; receiving verification results from the other secure PLCs (110) over the secure network (104); and allowing the programming application to download the PLC programming to the secure PLCs (110) if a minimum number of secure PLCs (110) in the plurality of secure PLCs (110) have communicated over the secure network (104) that the response from the programming application is acceptable.

13. The method of claim 12, wherein, the secure PLC (110) is a master secure PLC, the method further includes counting the verification results received from the other secure PLCs (110), and issuing an accept command over the secure network (104) if the minimum number of secure PLCs (110) have communicated over the secure network (104) that the response from the programming application is acceptable.

14. The method of claim 12 or 13, wherein, the minimum number of secure PLCs (110) is a majority of the plurality of secure PLCs (110) coupled to communicate over the secure network (104), the majority being determined by dividing the total number of secure PLCs (110) on the secure network (104) by 2 and adding 1.

15. The method of claim 12 or 13, wherein, initiating multi-PLC authentication includes verifying the response from the programming application to the authentication challenge, and providing the verification results to the other secure PLCs (110) over the secure network (104).

16. The method of claim 12 or 13, wherein, the authentication challenge is in the form of a proof-of-work (PoW) related to a function of the programming application.

17. The method of claim 16, wherein, initiating multi-PLC authentication further includes selecting the PoW from a predefined list of PoWs for the programming application stored in the secure PLC (110).

Images